Under some narrow conditions, an X shows up when simulating multiple transactions that have multiple outputs that are writing to output queues at the same time:
Given two or more transactions that are both have work to do for overlapping periods of time (e.g., during scratchpad to output queue writeback)
An X will be generated when arbitrating between the two transactions
This is because the ready line of the ioArbiter is left unconnected. This gets realized as a connection to an uninitialized flip flop. In 2-state simulation (or in an FPGA or on an ASIC) this doesn't matter, but in 4-state simulation, this starts as an X and will be used to arbitrate between the two transactions only when both transactions are both valid (this rarely happens apparently).
It's a weird situation where either one or zero is fine, but X is not. :woman_shrugging:
This should still be fixed in DANA's Transaction Table nonetheless.
This may be worth filing an issue on Chisel3 as this is really a problem if you create an RRArbiter and don't connect it's ready line. This'll work in 2-state (kind of oddly) and in taped-out designs, but will barf in 4-state. It's not clear to me if 4-state simulation is even supposed to be consistent with 2-state simulation.
Under some narrow conditions, an
Xshows up when simulating multiple transactions that have multiple outputs that are writing to output queues at the same time:Xwill be generated when arbitrating between the two transactionsThis is because the
readyline of theioArbiteris left unconnected. This gets realized as a connection to an uninitialized flip flop. In 2-state simulation (or in an FPGA or on an ASIC) this doesn't matter, but in 4-state simulation, this starts as anXand will be used to arbitrate between the two transactions only when both transactions are both valid (this rarely happens apparently).It's a weird situation where either one or zero is fine, but
Xis not. :woman_shrugging:This should still be fixed in DANA's Transaction Table nonetheless.
This may be worth filing an issue on Chisel3 as this is really a problem if you create an
RRArbiterand don't connect it's ready line. This'll work in 2-state (kind of oddly) and in taped-out designs, but will barf in 4-state. It's not clear to me if 4-state simulation is even supposed to be consistent with 2-state simulation.