Chisel3 - util - RRArbiter

https://mp.weixin.qq.com/s/GcNIFkHfa0gW0HKkKvHZEQ

 

 

循环优先级（Round Robin）仲裁器。

 

参考链接：

https://github.com/freechipsproject/chisel3/blob/master/src/main/scala/chisel3/util/Arbiter.scala

 

RRArbiter是一个仲裁器，只是使用RR的逻辑实现优先级。grant是优先级逻辑的结果，所以实现RRArbiter与严格优先级Arbiter的区别在于（仅在于）grant的生成逻辑不同。

 

1. RR优先级的两个层次

 

RR优先级的含义，包括两个层次：

 

a. 基于次序的优先级

 

小号输入口的优先级高于大号输入口；

 

b. 最高优先级是循环的

 

与严格优先级不同的是，RR逻辑中，最高优先级并不总是0，而是根据上一次选择的输入口而变化的。上一次选择的输入口的下一个输入口具有最高的优先级。

 

最高优先级并不是逐个向后轮换的，而是根据上一次选择的输入口可能产生跳变。因为最高优先级的输入口不一定被选择，也并不代表次优先级不能被选择。

 

2. 上一次轮到的输入口

 

要实现RR逻辑，需要记录上一次轮到的输入口，序号记为：lastGrant。

那么判断输入口是否轮过的逻辑为：i > lastGrant，为真则未轮过，为假则已轮过。

 

3. 忽略已经轮过的输入口

 

输入口的状态首先通过valid信号表达。判断某个输入口是否考虑的逻辑为：

(i > lastGrant) && io.in(i).valid；

 

4. 表达基于次序的优先级

 

基于次序的优先级的逻辑与Arbiter一样，如下（设Arbiter 输入口个数n = 4）：

 

​​

 

5. 引入未轮过的输入口

 

因为循环优先级的存在，输入口0并不总是最高优先级，其优先级还要低于未轮过的输入口，所以需要引入依赖未轮过的输入口。如下：

 

​​

 

这里选择把所有的接口都加上，那些已经轮过的输入口i > lastGrant为假，自动忽略其valid。未轮过的输入口i > lastGrant为真，则会依赖其valid信号。

 

6. 不适用于未轮过的输入口

 

不过这种方法，不适用于未轮过的输入口。

假设lastGrant = 1, 那序号为2的输入口也依赖于其自身的valid，也依赖于序号为3的valid。这是不合理的。

 

所以这个逻辑只适用于已轮过的输入口。

 

7. 分而治之

 

此时需要使用分治策略，为已轮过的和未轮过的输入口提供不同的逻辑。而两种接口的分野就在于i > lastGrant。

 

8. 未轮过的输入口使用的逻辑

 

未轮过的输入口的优先级只依赖于前一个未轮过的输入口，如果是第一个未轮过的输入口，则其优先级最高，不依赖于任何其他输入口。

 

把所有输入口都当做未轮过输入口，考虑基于次序的优先级，逻辑如下：

​​

 

若lastGrant = 1：

a. in(0)/in(1)为已轮过的输入口，使用已轮过输入口的逻辑；

b. in(2)为第一个未轮过输入口，其优先级最高，不依赖于其他输入口的valid（直接为true）；

c. in(3)为第二个未轮过输入口，依赖于in(2).valid，而不依赖于in(0)/in(1)；

 

9. 总结

 

总结下来，如果接口已轮过，则使用如下逻辑确定是否授权：

​​

 

如果接口未轮过，则使用如下逻辑确定授权：

​​

 

综合起来，如下：

​​

 

10. RRArbiter类

 

​​

RRArbiter类为LockingRRArbiter类的子类。

 

11. LockingRRArbiter类

 

这个类中实现RR的逻辑。

 

​​

 

a. lastGrant

 

lastGrant记录上一次选择的输入口。

 

b. grantMask

 

为每一个输入口生成一个：i > lastGrant 逻辑。

 

c. validMask

 

根据是否轮过，决定是否考虑该输入口的valid信号。为每个输入口生成一段 (i > lastGrant) && in(i).valid逻辑。

 

d. ctrl

 

1) 依次取出validMask中的元素：(0 until n).map(i => validMask(i))

2) 依次取出所有的valid信号：io.in.map(_.valid)

3) 把两个list连接起来：listA ++ listB

 

​​

 

4) 使用ArbiterCtrl连接每个元素，结果如下：

 

​​

 

e. grant

 

grant(i) = ctrl(i) && grantMask(i) || ctrl(n + i)

 

如下：

​​

 

f. choice

 

choice决定chosen, chosen决定io.out.valid和io.out.bits：

​​

 

choice的逻辑如下：

​​

 

如果还记得上一篇对循环when的解释：时间上后面执行的when先行判断，前面执行的when逐次为eslewhen/otherwise。

 

这里validMask的循环在后面执行，那么validMask的判断就在前面，validMask为假才会继续判断后面的valid信号。

 

这样就为未轮过的输入口提供了优先级。倒着来从大号到小号，是为了遵从基于次序的优先级。

 

值得注意的有两点：

1) 第一个循环从n-2到0，那n-1呢？

 

很简单，n-1已经作为默认值了。

 

2) 第二个循环从n-1到1，那0呢？

 

因为0 > lastGrant始终为false，所以validMask(0)始终为false。总是第一个进行结果已知的判断，干脆直接省略。

 

这是一个很有趣的地方。尽管0 > lastGrant始终为假，也就是说in(0)始终被当做已轮过的输入口，但却并未影响其基于次序的优先级和基于RR的优先级。为什么呢？

 

因为在设计已轮过和未轮过输入口的授权逻辑时，已经考虑到了这一点。