仲裁器的输出不稳定

Question

我刚刚发现了这个问题。

假设我使用Arbiter来仲裁来自多个并行事务启动器的总线驱动程序的输出。总线和启动器使用DecoupledIO。众所周知，仲裁者在（1）中优先于（0）。考虑到这种情况：

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实际上对应于（1）NOT in（0）in clock 2。

我希望仲裁器在（0）中选择如果在（0）和在（1）中在同一时钟周期变为有效，但如果在（1）中在（0）之前变为有效，则仲裁器继续选择在（1）中直到（1）被解雇。

在这种情况下，LockingArbiter，RRArbiter都具有相同的行为，在较低的输入被锁定之前，较高优先级的输入总是可以抢占较低优先级的输入（当count == 1时，根本没有锁定。）

我有点看到这种不稳定的输出是像Arbiter这样的bug问题。 有解决办法吗？

Answer 1

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