Chisel3 - util - Arbiter

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不能输出。