Creating test bench for AXI bus

UVM
1

I have to create test bench to my project which contains AXI bus.

I start to write the interface and the transaction for write and read. I read the following blog: Redirecting…

According this blog the interface should be:

interface vgm_axi_interface(input bit ACLK, input bit ARESETn);
  logic [3:0] AWID;
  logic [31:0] AWADDR;
  logic [3:0] AWLEN;
  logic AWVALID;
  logic AWREADY;


  logic [3:0] WID;
  logic [31:0] WDATA;
  logic WLAST;
  logic WVALID;
  logic WREADY;

  logic [3:0] BID;
  logic [1:0] BRESP;
  logic BVALID;
  logic BREADY;
endinterface

What about all the other signals (for example ARBURST,ARLOCK,ARCACHE,ARPROT,ARQOS,ARREGION)? There are many more signal according the specification of AXI4.

In addition are the following properties in the transaction are enough for write transaction?

typedef enum bit [3:0] { LENGTH_[1:16] } length_e;


class sequence_item extends uvm_sequence_item;
  rand bit [3:0] id;
  rand bit [31:0] address;
  rand length_e length;
  rand transfer transfers[];
  rand int unsigned delay;
endclass


class transfer extends uvm_sequence_item;
  rand bit[31:0] data;
  rand int unsigned delay;
endclass
2

The “other” signals are control signals on the interface, and they do not need to be captured in the transaction. Only the data content should be modeled in the transaction, with variables that you can generate declared as rand, and variables that are sampled from the interface not declared as rand. It is the responsibility of your driver and monitor to use the control signals in the interface to abide by the protocol and timing.

Since you’re asking specifically if your bare-bones sequence item is OK to model a write, it appears OK to me. The transfer class need not derive from uvm_sequence_item (uvm_object is OK). Fill in the rest such as constraints and methods to work with an object of this, and try it out in simulation.

3

In reply to manning999:

You wrote that the “other” signals do not need to be captured in the transaction, but shouldn’t them be appear in the Interface?

In addition why shouldn’t I add the signal of the size (AWSIZE for example) to the interface, and also a propery of size in the transaction?

4

By data content, I meant information such as address, length/size, data, type, etc. Upon further review, your short list of the other signals actually can be captured in the transaction (e.g. ARQOS - I assume Quality of Service - would be a quantity that should be stored in the transaction). I’m not very familiar with AXI, but I was trying to make general points applicable to any bus protocol.

All signals should be included in the interface, along with specified parameters. Signals that represent quantities should be modeled in the transaction. Signals strictly for controlling the protocol and timing should be used by the driver/monitor, and do not need to be included in the transaction model.

Sorry for being unclear previously.

5

In reply to manning999:

All transactions should be extended from uvm_sequence_item since they will be generated by sequences. There is no justification for extending from uvm_object.

Also, the transaction should encapsulate both the data as long as the transfer qualifiers (including timing, error generation, etc.). The reason for this is to allow the test developer to control these qualifiers on a per-transaction basis and generate more effective tests.