11-22-2017 12:26 PM
I'm using the new Zynq-7000 Verification IP
I have created a custom component to interface between a AXI Master and AXI Slave.
I have simulated my custom component with the AXI VIP master and slave components; and it works fine.
I have now created a new simulation design with the following
AXI VIP Master -> MY IP -> AXI Smart Connect -> AXI HP0 (using the Zynq VIP)
I created a test bench using the AXI VIP master to command my component to to do a write to the Zynq OCM through AXI HP0; which completes successfully.
I then command my component to do a read from Zynq OCM; but it does not complete.
Using the wave form viewer I can see the Read Address Channel (RA) complete a transaction between the Smart Connect and the HP0. However, I don't get a read valid (RVALID).
I feel like I a missing a configuration step with the Zynq VIP -- but I am not sure what it is.
I have attached a screen shot of the waveform viewer; showing the AXI Smart Connect & AXI HP0 on the Zynq.
11-29-2017 01:15 PM
A few questions:
1. When you say that the write completes, do you see a BRESP come back from Zynq-7000 S_AXI_HP0?
2. Could you share your test bench code for the AXI VIP Master -> MY IP -> AXI Smart Connect -> AXI HP0 (using the Zynq VIP) case?
12-01-2017 04:32 PM - edited 12-03-2017 12:25 AM
Have you figured this out yet? I ran into this problem and realized if I issue sixteen address read requests then the Zynq VIP will start responding. I don't know if this is a bug or not. Writes seem to occur after one address write and one write.
I also get fatal errors in the simulation but if I click continue it will keep working...
Fatal: [xil_object] (axi_vip_pkg.axi_slv_rd_driver(C_AXI_PROTOCOL=1,C_AXI_WDATA_WIDTH=64,C_AXI_RDATA_WIDTH=64,C_AXI_WID_WIDTH=6,C_AXI_RID_WIDTH=6,C_AXI_HAS_REGION=0)::get_and_drive.GET_AND_DRIVE) 4115000 : Driver & Sequencer problem. Received reactive item when there are no commands in flight. Number of commands inflight ( 0) is not greater than 0.
After forcing it to continue I see a bunch of these.
Error: [xil_object] (axi_vip_pkg.axi_slv_rd_driver(C_AXI_PROTOCOL=1,C_AXI_WDATA_WIDTH=64,C_AXI_RDATA_WIDTH=64,C_AXI_WID_WIDTH=6,C_AXI_RID_WIDTH=6,C_AXI_HAS_REGION=0)::push_done_q) 4215001 : Number of pending commands is zero
Edit: Interestingly if I issue another address read after a few of the reads have come back the whole system glitches out again and I don't get the rest of the originally requested reads or any of my new reads.
Edit 2: If I issue another 16 reads after the previous 16 reads finish those do work...
Edit 3: Tried a few more things, I can't get an RVALID if I do one address read, however if I do two it responds to both address reads.
12-07-2017 05:37 PM
darkknight - i have not figured it out yet; but have finally been able to replicate what you have.
In my design i had to request my component to generate a 64x32bit read transfer (ARLEN=x3F) . On the other side of the AXI smart connect, this turned into two back-to-back AR channel request with ARLEN=xF (2x16x64bit burst)
The second ARREADY occurs at 27450ns; RVALID goes high at 28270ns (at least on this test)
12-08-2017 04:40 PM - edited 12-08-2017 04:49 PM
As far as I know this is a bug but I cannot confirm. I got my design working in hardware now (DDR3 -> HDMI frame buffer transfer) however the way I do my reads I just issue AR's until the interface stops letting me and issue AR's when the interface allows me to again, all my reads are sequential and a backlog of reads pile up for me in the read FIFO, I just assert RREADY when I want to take data to send out over HDMI.
As far as I'm concerned, It would be really silly if this happened in hardware.
02-06-2018 12:37 PM
Hello Xilinx Team, Please let us what is the status regarding this CR, when we can get the updated workaround. Is there any workaround available now. Is it possible to get explanation, what is going on wrong during these transactions.This is holding the progress on our project.
02-26-2018 04:35 AM
Any news on this ? I think I'm seeing this issue. I've upgraded to latest Vivado version (2017.4) but it made no difference. :-(
01-04-2019 07:56 AM
For anyone stumbling upon this topic, this issue is fixed since 2018.1 according to one of the Xilinx guys. I tried the read from S_AXI_HP0 in 2018.3 and it worked nicely.