In axicb_mst_switch.sv module, a protocol violation may occur because of channel signals assignment. The master interface drives its output based on round robin granting, but in some situation described below, address and other fields change while they shouldn't:
Next masked request is granted to master 0, but it's not yet active and master 1 yes. Thus, non-masked request channel is driven, for instance master 1.
Next cycle master 0 becomes active so master interface drives its, and no more master 1.
Slave agent not ready on first cycle see AVALID/WALID asserted but ADDRESS / ALEN / WDATA (...) change.
One solution could be to rework the arbiter or its control.
Another one could be to store the grant value and block it as long as a slave is not active (preferred).
A protocol checker needs to be put in place to first catch the bug, then ensure the fix is correct.
This will be harmless in most situation but is out-of-spec. This bug concerns only crossbar configuration without CDC, buffer or pipeline on output slave path.
In
axicb_mst_switch.sv
module, a protocol violation may occur because of channel signals assignment. The master interface drives its output based on round robin granting, but in some situation described below, address and other fields change while they shouldn't:One solution could be to rework the arbiter or its control.
Another one could be to store the grant value and block it as long as a slave is not active (preferred).
A protocol checker needs to be put in place to first catch the bug, then ensure the fix is correct.
This will be harmless in most situation but is out-of-spec. This bug concerns only crossbar configuration without CDC, buffer or pipeline on output slave path.