02-05-2020 12:04 AM - edited 02-05-2020 12:04 AM
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
02-05-2020 12:38 AM - edited 02-05-2020 12:39 AM
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.
02-06-2020 01:21 AM
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 ?
02-06-2020 01:23 AM
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
02-06-2020 01:34 AM
wait, How is AXI Protocol Checker different compared to AXI Verification IP ?
02-06-2020 02:25 AM
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
02-06-2020 03:16 AM
Regarding VIP/Checker from Xilinx, you might go through the discussion here.
------------FPGA enthusiast------------
Consider giving "Kudos" if you like my answer. Please mark my post "Accept as solution" if my answer has solved your problem