In stream_xbar module, when flush_i is asserted, ready_o[31] remains unset (not set to 0). about common_cells HOT 7 OPEN

Hi @niwis,
is this a bug or there is a problem in my understanding?

from common_cells.

Hi @hayat10x, according to the signal description, valid_i should be deasserted during flush_i. Is this the case in your counterexample?

Also, note that flush_i only resets the internal state of the round-robin arbiter. If this is misleading, feel free to propose a different solution.

from common_cells.

yes, valid_i is deasserted in the case when flush_i is asserted.
I wrote the assumption for flush_i as follows:

assmp5_flush_i:  // flush should only be asserted if there is no active valid_i
assume property(flush_i |->  valid_i == 0 );

from common_cells.

could you share a waveform? Also, to clarify, flush_i only resets the internal state of the round-robin arbiter, which determines which input is being served in the following cycles.

from common_cells.

So when the internal state of the arbiter is reset, won't it affect ready_o?
Here is the waveform where you can see that valid_i = 0, and all other ready_o indexes are flushed except ready_o[31].

from common_cells.

@hayat10x we would need more visibility to debug this. could you share a reproducible testbench or a data format containing all internal signals?
Adding @thommythomaso to the discussion

from common_cells.

Hi @niwis, I apologize for the delayed response. Unfortunately, access to the JasperGold license has been discontinued. I will provide all the internal signals once it becomes available again. Thanks

from common_cells.