1149
指导设计。
三、阅读和欣赏（原加速器代码分析）。
3.1 加速器架构。
我们下午分析完了之后，就可以考虑，动动脑筋，如何把我们至芯的sobel 1702和我们的长整做个替换。
1150
指导设计。
三、阅读和欣赏（原加速器代码分析）。
3.1 加速器架构。
1151
指导设计。
三、阅读和欣赏（原加速器代码分析）。
3.1 加速器架构。
1152
指导设计。
三、阅读和欣赏（原加速器代码分析）。
3.1 加速器架构。
Bus_we。
1153
指导设计。
三、阅读和欣赏（原加速器代码分析）。
3.1 加速器架构。
Bus_we。
1154
指导设计。
三、阅读和欣赏（原加速器代码分析）。
3.1 加速器架构。
看一眼代码。
63行。
Sobel_gnt。
1155
指导设计。
三、阅读和欣赏（原加速器代码分析）。
3.1 加速器架构。
1156
指导设计。
三、阅读和欣赏（原加速器代码分析）。
3.1 加速器架构。
长整加速器里面，我们直接做了它的译码，我们直接写真值表了。
它这个直接做成逻辑了。
其它都一样。
现在就是对于我说的那三个信号，就是应答、选通、cyc，这个我解释一下。
先保存一下，下午接着做。
这个已经发给大家了。
Cycle，我已经解释了，在早期的嵌入式架构里面，就是CPU获得仲裁，或者是加速器获得仲裁，并不是100%地接管资源。
因为这个时候，加速器获得仲裁，接管资源以后，如果CPU真的被架空了，就不能产生被提速的效果。
1157
CPU还得有自己的资源。
多总线系统可以支持。
如果在单总线系统下面呢，CPU呢也不会完全没有事做。
它也是在按时间片划分的，它的时间片会多一些。
而CPU如果获得仲裁，当然它的时间片更多了。
加速器获得资源以后，CPU并不会无事可做，仲裁器仍然会给它一些时间片。
这个时间片呢，就是cycle。
所以说，用总线周期来做这种加速器的资源划分的时候，是加速器向仲裁器发出要求时间片的请求信号。
是cyc_o，是总线的时间片的请求。
1158
那么cyc_i就是它得到的当前的资源，就是总线时间片的划分，表明仲裁器给它划了时间片了，先让它可用。
所以说cyc_o是总线请求，cyc_i是总线的in，是仲裁的分配。
就相当我们长整的arb_res那个信号，那个是直接硬件就给它了，并不是100%按周期给它。
这个要理解成，如果加速器获得了仲裁，加速器可能没有100%地接管有些资源。
它虽然可以按全流水来做。
但是其间可能会有停顿的动作，仲裁器知道，仲裁器能够判别的话，它有没有访问哪些资源。
当某些资源给了它仲裁，它没有用到这些资源的时候，这些资源仍然可以给CPU用。
所以说这样更合理一些，也更复杂一些，这个设计。
