cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Observer
Observer
411 Views
Registered: ‎06-06-2019

Testing AXI4 Lite Slave

I'm looking for a way to test a custom IP block which has an AXI4 Lite Interface:

image.png

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:

image.png

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.

0 Kudos
5 Replies
Highlighted
Scholar
Scholar
386 Views
Registered: ‎05-21-2015

@jboehler,

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.

Dan

0 Kudos
Highlighted
Observer
Observer
280 Views
Registered: ‎06-06-2019

Just as an update on how I solved this problem: I used the code from here:

https://github.com/frobino/axi_custom_ip_tb/blob/master/led_controller_1.0/hdl/testbench.vhd

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)

0 Kudos
Highlighted
Scholar
Scholar
270 Views
Registered: ‎05-21-2015

@jboehler,

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.

Dan

0 Kudos
Highlighted
Observer
Observer
247 Views
Registered: ‎06-06-2019

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.

 

0 Kudos
Highlighted
Scholar
Scholar
235 Views
Registered: ‎05-21-2015

@jboehler,

Got it.

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:

  1. A user modifying Microblaze user software, only to discover the design locks up on any unaligned access to the user core.  It's reasonable to believe Zynq cores would lock up as well, I just haven't yet seen reports of it.  Apparent location of the bug?  Microblaze user software.  Actual bug location?  Custom user core.
  2. DMA interactions with user cores.  Apparent location of the bug?  The DMA that hangs without completing the task.  Actual bug location?  Custom user core.
  3. Designs that lock up when interacting with custom IP, when the interconnect is arranged in a multiple address multiple device configuration.  Apparent location of the bug?  The interconnect that was just reconfigured for faster performance.  Actual bug location?  The custom user core as before.

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.

Dan

Tags (1)
0 Kudos