仲裁器输出不稳定
Output of arbiter not stable
我刚发现这个问题。
假设我使用仲裁器来仲裁来自多个并行事务启动器的总线驱动程序的输出。总线和启动器使用 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
如果此总线上的客户端无法在同一周期内响应但在下一个周期内响应，
这个client驱动的out.ready实际上对应的是时钟2中的in(1) NOT in(0).
如果in(0)和in(1)在同一个时钟周期内有效，我希望仲裁器选择in(0)，但如果in(1)在in(0)之前有效，则仲裁器一直选择 in(1) 直到 in(1) 被触发。
在这种情况下，LockingArbiter、RRArbiter 都具有相同的行为，高优先级输入总是可以在低优先级输入被锁定之前抢占低优先级输入（当 count == 1 时，根本没有锁定）。
我有点将这种不稳定的输出视为 Arbiter 的一个类似错误的问题。
有解决办法吗？
一个 "needsHold" 参数被添加到所有仲裁器以启用此保持要求。默认情况下禁用此功能。这由提交 18ecaf8de4a5 包含在 Chisel 中。
我刚发现这个问题。
假设我使用仲裁器来仲裁来自多个并行事务启动器的总线驱动程序的输出。总线和启动器使用 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 如果此总线上的客户端无法在同一周期内响应但在下一个周期内响应， 这个client驱动的out.ready实际上对应的是时钟2中的in(1) NOT in(0).
如果in(0)和in(1)在同一个时钟周期内有效，我希望仲裁器选择in(0)，但如果in(1)在in(0)之前有效，则仲裁器一直选择 in(1) 直到 in(1) 被触发。
在这种情况下，LockingArbiter、RRArbiter 都具有相同的行为，高优先级输入总是可以在低优先级输入被锁定之前抢占低优先级输入（当 count == 1 时，根本没有锁定）。
我有点将这种不稳定的输出视为 Arbiter 的一个类似错误的问题。 有解决办法吗？
一个 "needsHold" 参数被添加到所有仲裁器以启用此保持要求。默认情况下禁用此功能。这由提交 18ecaf8de4a5 包含在 Chisel 中。