https://mp.weixin.qq.com/s/7Y23gV6yPvtmvKHTo2I8mw
?
基于ReadyValid接口实现的多入单出仲裁器。
?
参考链接：
https://github.com/freechipsproject/chisel3/blob/master/src/main/scala/chisel3/util/Arbiter.scala
?
?
1. ArbiterIO
?
?
?
ArbiterIO包含如下接口：
a. in
?
Arbiter的n个输入接口，每个接口都是ReadyValid接口；Flipped把方向反过来，是因为仲裁器是输入接口的Consumer；
?
b. out
?
仲裁器的输出接口（ReadyValid接口），因为仲裁器是这个接口的Producer，所以不需要使用Flipped调转反向；
?
c. chosen
?
指示选择的输出是哪一个输入接口的；
?
?
2. ArbiterCtrl
?
?
?
?
这是一个优先级发生器。requests中的请求按顺序优先级由高到低。
?
?
?
可以看到后面的请求，收到前面请求状态的约束，如果前面的请求状态为真，则后面的请求会被忽略。
?
3. Arbiter
?
Hardware module that is used to sequence n producers into 1 consumer. Priority is given to lower producer.
?
?
?
?
a. 输入输出接口
?
?
?
?
b. 输出数据
?
?
?
io.chosen/io.out.bits是一对，作为一个整体研究。这里对io.chosen/io.out.bits进行了n次连接，后面的连接具有更高的优先级，第一次的连接（连接到第n-1个输入）为默认连接。
?
把这些连接摊平，即如下：
?
?
?
c. 输入使能
?
?
?
?
某个Producer要想通过ReadyValid接口输出，需要与其相连的Consumer把Ready置位。也就是说，仲裁器通过把某一个输入口的Ready为置位，来授权该输入口传输数据。
?
这里，先把io.in中的n个输入，一一与grant中的n个授权位组成n个元组。然后遍历这些元组，一一决定是否对每个输入的ready置位，而允许其传输数据。
?
io.out.ready的意思为仲裁器的Consumer已经准备好了接收，这是一个总的开关。
?
grant用来决定是否授权某个输入口传输。这只是个结果，生成grant的逻辑实现了仲裁的算法。
?
d. 授权（grant）
?
?
?
grant是使用ArbiterCtrl来实现，这个是基本的严格优先级（strict priority）逻辑，小号优先。
?
根据ArbiterCtrl的实现，in(0)对应的grant总是为true，所以他总是有授权的。
?
e. 开始输出
?
?
?
?
!grant.last是把前面n-1个输入口的valid相或，再或上第n个输入口的valid，就是把所有的输入口的valid相或。
?
所以，只要输入口有一个想要传输数据，则整个仲裁器即想要传输数据。
?
请注意这里是想要，只是说明自己可以传输，但是否开始传输也取决于仲裁器的下游Consumer是否准备好，而把io.out.ready置位。
?
f. n个输入的优先级
?
优先级体现在哪里？在多个输入口的Producer同时把Valid置位，表明有数据要传输给仲裁器时，哪一个输入口获得授权。
?
这个体现在grant的算法里，从ArbiterCtrl的实现逻辑看，in(0)总是有授权，而后面的输入口的授权，依次取决于前面所有输入口的valid是否置位，如果置位，则该输入口的授权即被取消，而导致这个输入口的ready不能被置位。亦即这个输入口的Producer不能输出。
