AXI arvalid signal issue

[promach]

Waiting for BRESP simply wasts potential time on the interface. Imagine some high speed interface (say 25G ethernet). Waiting a couple hundred clocks for a BRESP could lose you a few packets.

This is based on the assumption that AXI master does not need sequential data processing in the case of BRESP returns NACK.

What if the mentioned AXI master is a CPU or any other sequential computation units ?
Even 1 single missing calculation or wrong operand value fed into the CPU would result in incorrect final output answer.

 

[TrickyDicky]

That is no longer an AXI question. Thats a Design question.

 

[promach]

How do I eliminate pc_status error bit 32 in the AXI slave code ?



By the way, there is another pc_status error bit 80.
I have already tried to increase MAXWBURSTS parameter as suggested in the description column, but it is still not eliminated.

 

[vGoodtimes]

you probably have some dropped/duplicated transactions. Over time, the queue will fail and things based on the queue will fail.

 

[promach]

you probably have some dropped/duplicated transactions.

How is this related to pc_status error bits 32 or 80 ?

 

[vGoodtimes]

looking at the diagram again, it looks like there is a few cycles of latency between when something happens and when something changes in that status. it looks like the value changes a total of three times. I can't see the first value, but it is probably all 0's. the next value looks like bit 80 is set. the final value has both set.

I notice that awready is asserted while awvalid is 'X'. Perhaps this error condition results in an issue with the simulation aspects of this checker.

 

[promach]

If I assert reset at t = 0 instead of few clock cycles later, then all pc_status error bits are cleared (no AXI violations).

Something is still not correct because hardware reset signal is not designed to be asserted at t = 0

 

[vGoodtimes]

ok, I'd look at fixing the reset situation. perhaps assert reset for a longer amount of time and remove the reset not on a clock edge of either direction.

 

[promach]

the problem is not about the duration of reset signal, instead it is about how the AXI slave axi_awready signal responds to delayed reset signal

The assertion of axi_awready as well as axi_arready together with the unknown X nature of axi_awvalid as well as axi_arvalid before reset is asserted at t = 25ns might have just triggered the AXI protocol violation bits in pc_status signal

---

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
clk = 0;
//reset = 0;
 
//@(posedge clk);
//@(posedge clk);
//@(posedge clk);
 
reset = 1;
 
@(posedge clk);
@(posedge clk);
 
reset = 0;

---