Showing results for 
Show  only  | Search instead for 
Did you mean: 

AXI Basics 2 - Simulating AXI interfaces with the AXI Verification IP (AXI VIP)

8 10 7,902

Introduction to the AXI Verification IP (AXI VIP)

The Xilinx AXI Verification IP (AXI VIP) is an IP which allows the users to simulate AXI4 and AXI4-Lite. It can also be used as a AXI protocol checker.

This IP is only a simulation IP and will not be synthesized (it will be replaced with wires in the path-though configuration).

The AXI VIP core can be used for the following:

  • Generating master AXI commands and write payload
  • Generating slave AXI read payload and write responses
  • Checking the protocol compliance of AXI transactions

It supports 5 different configurations:

  • AXI master VIP
  • AXI pass-through VIP without memory model
  • AXI pass-through VIP with memory model
  • AXI slave VIP without memory model
  • AXI slave VIP with memory model

The AXI VIP core is documented in (PG267) and the APIs for the VIP are documented in the ZIP file you can download from this link.

AXI VIP example designs

An example design for the AXI VIP is provided in Vivado.

To generate the example design for the AXI VIP, you just need to follow these steps:

  1. Open a new project in Vivado 2019.2 and click IP Catalog.
  2. Search for the AXI Verification IP. Double-click it, configure the IP, and generate the IP.
  3. Right-click the IP and choose "Open IP Example Design"


The example design for the AXI VIP includes 3 AXI VIPs: one configured as master, one configured as pass-through and one configured as slave.



Multiple test benches are included in the project to use different combinations of the AXI VIPs:



Note: All of the test bench files are written in SystemVerilog. To enjoy all of the features of the AXI VIP, this IP should be included in a SystemVerilog test bench.

Analyzing AXI interface transactions

A useful feature in the Vivado simulation is the protocol instances which can be added to the waveform to see the signals at a transaction level.

I will go through the steps for the sim_basic_mst_active_pt_mem__slv_passive simulation set.

To use this simulation set, right click on it in the source window and click Make Active.




This simulation set only uses the Master AXI VIP and the pass-through AXI VIP (which is acting as a slave with a memory level).

We can run the simulation by clicking on Run Simulation from the Flow Navigator.

A waveform will be opened by default with only the clock and reset signals.




We will add the AXI interface between the Master AXI VIP and the pass-through AXI VIP.

In the Scope window, find and select the Master AXI VIP (axi_vip_mst) under DUT > ex_design. The Objects window will then show all of the ports of the IP. Find the M_AXI interface object and click Add to Wave Window.




You will then be able to see the AXI transactions in the Waveform window:



We can see that between the beginning and the simulation time 1us, both Read and Write transactions have happened.

We can expand the M_AXI interface in the waveform window to see more details about these transactions:




The numbers on the channels correspond to the transaction numbers. We can see that 5 Read transactions are happening on the Read channels (purple) and 4 transactions are happening on the Write channels.

if you click on a specific transaction, you can see how the transaction is happening. For example, if we click on the first transaction on the write channels, we can see that this transaction is a burst transaction:

  1. The transaction starts by setting the address on the Write Address Channel
  2. Then a burst of data is sent on the Write Data channel
  3. Finally, the slave responds if the write was successful on the Write Response Channel




Tags (1)

Just a note for users of older Vivado versions: The 'interface object' M_AXI did not show up for me (Along with some other signals) during the simulation on Vivado 2018.1

However, using 2019.2, I was able to view this M_AXI object


Hi @aqua-proj 

Yes. I thought I added that this was supposed to be followed in 2019.2 because this feature is not available in previous versions


It's unfortunate that so many users would use the AXI VIP to verify that an AXI core is protocol compliant.   The VIP doesn't do that.  Instead the VIP exercises the core to give you a feel good that the core is protocol compliant.

As an example, here are some bugs that the VIP has missed or would miss.

1. It misses a dropped write packet (the trace ends in a steady state)


Apparently, the VIP suite doesn't check to see how well a core handles backpressure.  (BVALID high and BREADY low in this case.)  This bug was present in any IP packager generate slave core  from 2016.3.  The IP packager core was since partially fixed, since this bug was gone by 2018.3.

2. It misses dropped read packets.  As before, the trace ends in a steady state.


This bug remains present in the code generated by Xilinx's IP packager as of 2019.2.  Again, the VIP suite doesn't seem to check backpressure--in this case by seeing what would happen if RVALID && !RREADY.

3. It doesn't test whether or not your core will properly register a transaction ID before returning it


This bug is found in the IP packager generated AXI (full) slave demonstration core.  It's present on both read and write cores.

4. It doesn't check to see if your core is responsive to WLAST & !WVALID


You might notice that because WLAST was high for one clock cycle, the slave core in this instance dropped WREADY as a result.  This design is now forever hung.  This bug was also present on the AXI full demonstration core.  Intel's demonstration core suffers from this one as well.

5. It doesn't check to make certain you aren't waiting on xREADY before setting a return valid.


Since the VIP doesn't check what a core does in backpressure, it would miss the fact that this Xilinx AXI ethernet-lite core checked for S_AXI_RREADY instead of (!S_AXI_RVALID || S_AXI_RREADY).  This core would fail in the presence of any backpressure.

Here's another bug from the forum just today: a user built an AXI master that would set AWVALID and then wait for AWREADY before setting WVALID.


Not sure if the VIP suite would've caught that or not.

What the AXI VIP suite does do, however, is provide a stimulus that you can use to get a feel good regarding how well your core performs.  This might be useful to just get a trace.  If you want to guarantee actual standards compliance, you will need a  .



HI @dgisselq 

There is 2 different things to see here. What the AXI VIP can generate and what the AXI VIP can verify.

If the AXI VIP is used as a path-through, then it should give an error for all the cases you mentioned. So in a large system, with the correct stimuli (assuming this is reproducible in simulation) the AXI VIP will be able to detect the errors you mentioned.

But you are right, you will not be able to see the error in the use cases you mentioned using only the AXI VIP.

With that said, using the AXI VIP is a good start and help me find errors in multiple custom IPs


I am enjoying the learning from these blog posts.  However, when I attempt to run the simulation, Vivado displays the 'Run Simulation' dialog (with Background and Cancel buttons) but then immediately shows a 'Unable to Open File' dialog above the Run Simulation dialog.  The Unable to Open File dialog contains the message...

Unable to open file '' because file does not have read permission.  Would you like to open the directly instead?

And contains an 'Open Directly' and 'Cancel' button.  Clicking the 'Open Directory' button just gives me another dialog that says 'A background task is running.  Please wait until it completes and try again.  Clicking the 'Cancel' button cancels the simulation.  How do I get around this, please?


Hi @engrpetero 

I am not sure what could be the issue. Is this happening with the example design? Maybe you do not have the full access to the installation folder of Vivado?

I would recommend you to open a topic in the Simulation board, hopefully one simulation expert can help


I have seen the read permission issue also.


The problem "Unable to open file '" only happens if the target language is VHDL. Using Verilog, the simulation works as shown in the example above.


Hi @engrpetero

Check whether you pass the correct hierarchy path of IF to the new function. According to my observation, hierarchy path should contain the name you gave to the instance of the wrapper module in the testbench. (not the name of the wrapper module)


This is great. I wish I had known about this blog a couple of months ago.

I have put considerable effort into adapting the VIP into a reusable AXI/AXI-STREAMING BFM that can use the protocol checker. I sure wish the Xilinx example designs were easier to use (especially the one for the VIP). I think that is what we really want--a BFM that can optionally check the correctness of the protocol. If there was something along these lines provided by Xilinx, I would happily adopt it.