cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
524 Views
Registered: ‎05-02-2017

AXI Protocol Checker IP reports errors on AXI_ERRS_RID and AXI_AUXM_RCAM_OVERFLOW

 

AXI Protocol Checker IP reports errors on AXI_ERRS_RID and AXI_AUXM_RCAM_OVERFLOW which are pc_status bits 59 and 78 respectively.

My AXI code is located at here (need to uncomment code block lines 107 to line 199 as well as line 374)

Could anyone advise ?

 

AXI Protocol Checker IP reports errors on AXI_ERRS_RID and AXI_AUXM_RCAM_OVERFLOW.png

0 Kudos
6 Replies
Highlighted
Xilinx Employee
Xilinx Employee
381 Views
Registered: ‎10-04-2016

Re: AXI Protocol Checker IP reports errors on AXI_ERRS_RID and AXI_AUXM_RCAM_OVERFLOW

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.

Regards,

Deanna

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Adventurer
Adventurer
367 Views
Registered: ‎05-02-2017

Re: AXI Protocol Checker IP reports errors on AXI_ERRS_RID and AXI_AUXM_RCAM_OVERFLOW

 

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.



 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
309 Views
Registered: ‎10-04-2016

Re: AXI Protocol Checker IP reports errors on AXI_ERRS_RID and AXI_AUXM_RCAM_OVERFLOW

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.

Regards,

Deanna

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
Adventurer
Adventurer
259 Views
Registered: ‎05-02-2017

Re: AXI Protocol Checker IP reports errors on AXI_ERRS_RID and AXI_AUXM_RCAM_OVERFLOW


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:


VtLXuAW

 

0 Kudos
Highlighted
Adventurer
Adventurer
121 Views
Registered: ‎05-02-2017

Re: AXI Protocol Checker IP reports errors on AXI_ERRS_RID and AXI_AUXM_RCAM_OVERFLOW

 

For the attached AXI master, how do I guarantee AW* payloads are sent first, followed by W* payloads without violating AXI protocol (a master must not wait for AWREADY to be asserted before driving WVALID) ?

 

 

always @(posedge clk) 
begin
	if(reset) 
	begin 
		o_axi_wvalid <= 0;
	end

	else if(!(o_axi_wvalid && !i_axi_wready))
	begin
		// Note that both o_axi_awsize , o_axi_awlen are of hardware constants, so no multiply hardware
		// since this is for testing, WDATA just uses some values up to the total size of the write address space
		// see https://i.imgur.com/LBO9pQz.png in which AW* payloads are sent first, followed by W* payloads
		// Note: a master must not wait for AWREADY to be asserted before driving WVALID
		o_axi_wvalid <= (o_axi_wlast) ? 0 : 
						(o_axi_wdata < (o_axi_awsize*o_axi_awlen)) && o_axi_awvalid; 
	end
end

 

 

 

 
LBO9pQz

0 Kudos
Highlighted
Adventurer
Adventurer
95 Views
Registered: ‎05-02-2017

Re: AXI Protocol Checker IP reports errors on AXI_ERRS_RID and AXI_AUXM_RCAM_OVERFLOW


In the pc_status error bit location , is it bit #32 because in the following simulation waveform, BVALID is never asserted high during the time when pc_status error bit #32 is asserted ?


oVlqJUe

0 Kudos