仲裁者产出不稳定

Question

我刚刚发现了这个问题。

假设我使用一个仲裁器来仲裁来自多个并行事务发起者的总线驱动程序的输出。总线和发起者使用DecoupledIO。众所周知，仲裁者在(0)中优先于(1)。考虑到本案：

clock 1: in(0).valid = 0, in(1).valid = 1  -> out === in(1) out.valid = 1  out.ready = 0
clock 2: in(1).valid = 1, in(1).valid = 1  -> out === in(0) out.valid = 1  out.ready = 1

因此，时钟1和2都有bus.valid === 1，如果此总线上的客户端不能在同一周期内响应，但在下一个周期，由该客户端驱动的out.ready实际上对应于时钟2中的in(1)而不是in(0)。

如果in(0)和in(1)在同一个时钟周期中有效，则期望仲裁者在(0)中选择in(0)，但如果in(1)在in(0)之前有效，则仲裁者一直选择in(1)，直到in(1)被触发为止。

在这种情况下，LockingArbiter和RRArbiter都有相同的行为，高优先级的输入总是在较低的输入被锁定之前抢占较低的优先级(当计数== 1时，根本没有锁)。

我把这个不稳定的输出看作是一个类似bug的仲裁问题。有办法解决这个问题吗？

Answer 1

将"needsHold“参数添加到所有仲裁器中，以启用此持有要求。默认情况下，此功能被禁用。这是由提交18ecaf8de4a5在Chisel中包含的。