01-12-2021 08:14 AM
I need a little help with the Xilinx AXI4 Interconnect IP.
I’m running a simple simulation with my own testbench driving the AXI4 Interconnect IP.
The attached timing diagram screenshot shows that, for a write transaction, the IP receives
the address and data valid signals from the testbench and responds CORRECTLY with the
ready signals (ie, awready and wready).
However, the IP does not follow up with the assertion of the “bvalid” per the AXI4 protocol. The available Xilinx documentation in the public domain (eg, product/reference guides) does not provide sufficient detailed interface information (eg, timing diagrams) on the IP
to allow for further debug.
01-13-2021 07:37 AM
Help me understand what's going on here. Do you have: TESTBENCH -> Interconnect -> Custom IP? It would seem, therefore, that the custom IP isn't returning BVALID, and hence neither is the Interconnect. Right?
Also, why is the TESTBENCH sending two write words? Are you intending to send two write bursts of one beat each? If so, then why is AWVALID dropping before the second burst?
01-13-2021 09:04 AM
Please see the updated waveform file attached, which also shows the Interconnect <-> custom_ip timing (top half of the waveforms). As you can see, the handshakes on the custom_ip side appear to be working properly with the Interconnect receiving "bvalid" from the custom_ip. With one problem though - M15_AXI_wdata with the value 0x20 terminates 1 cycle befor M15_AXI_wvalid is asserted by the Interconnect.
BTW, the simulation is set up to write 1 word only (ie, burst length=1). I have parameters like awprot/awburst/awlock/awid/etc all set to 0. Hope that's ok.
01-13-2021 08:13 PM
I'm not sure I know the answer, but perhaps I can help you rule out another possibility: Xilinx requires that the AXI reset last at least 16 clocks. It should also *synchronously* release with the clock.
Perhaps that might help?
01-14-2021 10:03 AM
I'm not an AXI Expert but these Blogs may be useful
01-22-2021 07:51 AM
Hi @jcl ,
How are you handling the AXI ID signals between M15_AXI and your custom IP? If the M15_AXI is driving out a value on the AWID bits, the write response must return with the same value on the BID bits. Without this, the interconnect cannot route the response back to the appropriate SI.
Please refer to the AXI Interconnect PG059 for details about the usage of the ID bits for response routing.
01-22-2021 08:13 AM
01-22-2021 09:28 AM
I am aware of some subtle test bench bugs that can cause something like this. If you could share your test bench, I'd be happy to look for them.
I'm also familiar with common custom IP bugs. If you wish to share your custom IP, I'd be glad to check it for bugs as well.
01-22-2021 09:46 AM
Hi @dgisselq ,
Thank you. For reference, I also ran the simulation with the "custom_ip" replaced with a standard Xilinx RAM Controller IP. The behavior remained the same - ie, bvalid returned by the Controller correctly but did not get "forwarded" to the testbench by the AXI Interconnect.
Is there a way you can be reached via PM so I can share the material? You can also email me.
01-26-2021 10:59 AM
Hi @dgisselq ,
Some additional info that may be helpful in narrowing the scope of the problem (see attached waveform):
1) Waveform shows a AXI4 write transaction from AXI Interconnect M11 port to a Xilinx RAM Controller.
2) M11_AXI_bready (from Interconnect) goes "X" after the Controller sends back "bvalid" acknowledging the completion of the write transaction.
3) The "bvalid" does not get forwarded to the testbench <-> Interconnect interface.
4) As an experiment, I changed the awid to 0xB (matching M11 port) and observed that the Controller sent back the same value as expected.
5) Could the problem be related to how the awid/awlen/awlock/awprot/awuser/etc parameters should be set for a burst write of length 1? Currently they are statically set (see waveform).
6) Also take a look at the "wlast" signal.
The "bready" going "X" - right after "bvalid"=1 - might give a clue to this problem
01-27-2021 07:20 AM
Hi @jcl ,
You might try adding the AXI Protocol Checker IP to the SI input and the MI outputs you are using in your test. This IP can help to quickly identify protocol issues.
Your simulation is behaving rather strangely, which tends to suggest either a problem with resets not being held long enough or with the stimulus.
01-27-2021 01:37 PM