cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
user123random
Adventurer
Adventurer
618 Views
Registered: ‎05-02-2017

AXI arvalid signal


I have question about AXI arvalid signal used for interfacing with DDR axi controller in Zynq.

if I do not remove i_axi_arready , I will have deadlock issue.
If I remove i_axi_arready , I will have issue arising from DDR periodic mechanism such as auto-refresh.

What could I do ?

Someone told me the following which I do not understand:

VALID signal needs to be set (initially) independent of READY signal, and then only ever adjusted if !(VALID && !READY)

 

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

    // AXI specification: A3.3.1 Dependencies between channel handshake signal
    // the VALID signal of the AXI interface sending information must not be dependent on
    // the READY signal of the AXI interface receiving that information
    // this is to prevent deadlock
    // since AXI slave could waits for i_axi_arvalid to be true before setting o_axi_arready true.
    // Note: VALID cannot be dependent upon READY, but READY can be dependent upon VALID
    //       VALID signal needs to be set (initially) independent of READY signal,
    //       and then only ever adjusted if !(VALID && !READY)
    else o_axi_arvalid <= /*i_axi_arready &&*/ (!cache_is_full);
end 

 

0 Kudos
Reply
6 Replies
richardhead
Scholar
Scholar
600 Views
Registered: ‎08-01-2012

This is correct. it is ILLEGAL to assert valid based on the ready signal, because this can lead to deadlock. You may de-assert valid when ready is asserted. but ready MAY depend on valid. To this end, is is legal to connect ready directly to valid. This is true for ALL AXI channels.
Also, once valid is asserted, it MUST be kept asserted until ready is asserted.

You need to forget about the DDR backend, and simply think about the AXI channels. It is the DDR cotrollers problem when it is ready to recieve address requests. You simply send them when you want/can.
It also may be in your interest to think about pipelineing. It is fairly common to send several read requests before they are completed. This is down to the DDR controller how many address requests it can store in its pipeline.

0 Kudos
Reply
user123random
Adventurer
Adventurer
484 Views
Registered: ‎05-02-2017

Now, I have modified the code to satisfy AXI4 requirements, but I am not sure how many more AXI4 bugs I have.

So, should I use Xilinx AXI VIP to verify my AXI4 bus protocol correctness ?

0 Kudos
Reply
dpaul24
Scholar
Scholar
482 Views
Registered: ‎08-07-2014

@user123random,

If you have one, YES!

------------FPGA enthusiast------------
Consider giving "Kudos" if you like my answer. Please mark my post "Accept as solution" if my answer has solved your problem

0 Kudos
Reply
user123random
Adventurer
Adventurer
478 Views
Registered: ‎05-02-2017

wait, How is AXI Protocol Checker different compared to AXI Verification IP ?

0 Kudos
Reply
richardhead
Scholar
Scholar
465 Views
Registered: ‎08-01-2012

@user123random 

A protocol checker will ensure you're not breaking any rules - eg. de-asserting valid before ready, ID is stable for the whole transaction, not doing a read/write over a 4k boundary etc. From the looks of the docs, its simply a version of the SVA provided by ARM that will work on chip. It is passive code.

The AXI VIP will be a superset that also contains drivers to generate master transactions to test your slave devices, plus slave BFMs that can receive data from a master. These are active modules

dpaul24
Scholar
Scholar
445 Views
Registered: ‎08-07-2014

@user123random,

Regarding VIP/Checker from Xilinx, you might go through the discussion here.

https://forums.xilinx.com/t5/Embedded-Development-Tools/What-are-the-possible-reasons-of-AXI-Lite-wrintings-hang/m-p/1072286#M52230

------------FPGA enthusiast------------
Consider giving "Kudos" if you like my answer. Please mark my post "Accept as solution" if my answer has solved your problem