02-06-2020 06:44 PM - edited 02-07-2020 12:30 AM
02-12-2020 03:52 PM
Hi @user123random ,
I think the AXI_ERRS_RID error is correct.
When ARVALID asserts <0,1>, the ARID value is <1,1>.
When RVALID asserts <0,1>, the RID value is <0,0>.
The RID should match the value of the ARID of the read command it is responding to. It looks like the slave is not driving RID to the correct value.
02-12-2020 06:09 PM - edited 02-13-2020 01:53 AM
In AXI slave (bram_axi_controller.v) :
assign o_axi_rid = 0;
In AXI Master (address_generator.v) :
assign o_axi_arid = 0;
I suppose that the problem does not lie at how the rid and arid signals are driven, rather it is how the VALID and READY signals logic are handled.
Please correct me if wrong
I have two conflicting pieces of advices :
As long as the master can hold RREADY high, which most masters can do, then the master doesn't need a skid buffer. (The same is true of BREADY)
The 50% loss comes from the fact that it takes a clock to set ARREADY high after any transaction completes We are not allowed to set ARREADY combinatorially (This is in the slave now) If we were to set ARREADY combinatorially, we might set it to ARREADY = (!RVALID || RREADY);
But because ARREADY *must* be registered as per spec, it takes a clock to capture the stall During that clock, either data can come in and get kept some where (a.k.a. skid buffer), or we have to make certain ARREADY is already low (50% throughput)
A skid buffer lets you be optimistically wrong for one cycle in a row.
when something should be combinatorial, but must be registered, it's nice to be able to be optimistic. but registering might make you wrong once in a row. conceptually, to be safe you have to "look before you leap". that is not ideal.
It is better to say "leap" and then be able to be wrong once (in a row) as long as you aren't wrong twice in a row.
02-13-2020 01:41 PM
Hi @user123random ,
You're right: I was looking at the wrong signal when comparing ARID and RID.
If you are seeing weird errors from the Protocol Checker, double check your clocks and resets in simulation. Most Xilinx IP require a minimum of 16 clocks in reset. Failure to adhere to this can cause unpredictable errors.
I'm not following the question about the advice you are receiving. They seem to be specific to the way your master is implemented. From an AXI Protocol standpoint, you don't have to take a clock to set ARREADY after a transaction completes.
02-15-2020 11:10 PM - edited 02-15-2020 11:11 PM
However I still do not see how a skid buffer will solve this issue
and why would AXI slave require skid buffer as well ?
Note the first and the last highlighted signals in the waveform screenshot below: