我刚刚发现了这个问题。
假设我使用仲裁器来仲裁来自多个并行事务启动器的总线驱动程序的输出。总线和启动器使用 DecoupledIO。众所周知，Arbiter 优先于 in(0) 而不是 in(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 实际上对应于 in(1) NOT in( 0) 在时钟 2 中。
如果 in(0) 和 in(1) 在同一时钟周期内有效，我希望仲裁器选择 in(0)，但如果 in(1) 在 in(0) 之前变为有效，则仲裁器继续选择 in(1 ) 直到 in(1) 被触发。
在这种情况下，LockingArbiter、RRArbiter 都具有相同的行为，即较高优先级的输入总是可以在较低优先级的输入被锁定之前抢占较低优先级的输入（当 count == 1 时，根本没有锁定）。
我有点将这种不稳定的输出视为 Arbiter 的类似错误的问题。有解决办法吗？