02-27-2020 01:23 AM
I'm looking for a way to test a custom IP block which has an AXI4 Lite Interface:
What I basically did was to let Vivado generate an AXI4 Lite peripheral with 128 registers and included that in my custom IP block. I would now like to write a testbench for my custom block and in order to test functionality I have to access the control registers which in the real system would get their data from the Zynq PS.
I googled and found that there is this Xilinx IP called AXI Verification IP which seems to do what I want. However, I'm not really able to get things working. So how do I manage to make this AXI Verification IP set some fixed values to my AXI peripheral? I was looking for some file where I could specify what has to be sent over the AXI interface, but when I include the Verification IP in my block desgin I get only this:
Can anybody help me out with this? As it is pretty obvious I'm quite new to this Zynq world and the learning curve seems to be quite steep for a beginner.
02-27-2020 04:14 AM
The learning curve is quite steep for a beginner? Not just a beginner, but apparently for Xilinx too since they couldn't get their demonstration IP right either.
I wouldn't trust any AXI-Lite verification that didn't use formal methods. I've just seen too many broken cores. This includes cores that have passed a Xilinx Verification IP test, whose users then come here to wonder why their core is still broken.
This AXI-Lite verification article discusses using an open source formal methods tool to verify whether or not a Verilog based core is protocol compliant. The properties are open source as well, so you should (mostly) be good there. The article also describes where the bugs are in Xilinx's demo cores, so it might help you there as well.
03-13-2020 04:20 AM
Just as an update on how I solved this problem: I used the code from here:
which implements an AXI master in a testbench. I didn't know that implementing an AXI master would be that easy. I worked perfectly for me (however, I messed up due to a stupid mistake in the beginning by incrementing my addresses in steps of one instead of four because I forgot that the addresses are addressing bytes and not 32 bit words)
03-13-2020 05:23 AM
Glad that's "working" for you.
Sadly, there's a whole lot of bus protocol requirements that VHDL master core is not going to test--to include most of the bugs Xilinx missed. For example, that master won't check backpressure (broken in the IP packager designs and elsewhere), concurrent writes and reads (broken in the AXI ethernet-lite core), the write address channel not being synchronized with the write data channel and more.
03-13-2020 07:31 AM
I guess for me it's "working" enough. Just to avoid confusion: I didn't really want to test any AXI related stuff since the AXI registers were generated by Vivado itself and I guess I have to trust that code anyway (and I used it several times before). I wanted to test the behaviour of my custom block (which contains the AXI registers as a subfile) and for that I just had to set some registers inside to some fixed values.
03-13-2020 08:45 AM
Just to avoid confusion, though, you should know that the AXI-lite design generated by Vivado has been broken since at least 2016. Xilinx hasn't listed the problems on any errata sheets, nor posted the problems anywhere, although you can find many references to these bugs if you search through the forums. Many customers have struggled to find the bugs when they've shown up, since they will likely appear when something changes elsewhere within your design. Some examples of problems customers have had include:
This issues aren't as uncommon as you might think. Someone just posted an issue with their design locking up earlier this week. If I were to estimate, I think I've seen about 2-5 forum issues related to the broken Vivado-generated AXI designs per week or so.
So ... you are welcome to use/modify the Vivado design if you want, just beware of what's likely to happen. Alternatively, you can try this logic instead. Your call.