AXI4 VIP development and integration by tchilikov-semify · Pull Request #688 · lowRISC/mocha

tchilikov-semify · 2026-07-22T11:29:50Z

This PR does a few things:

Pulls @rswarbrick's AXI driver from his Caliptra repository as a local copy and expands on its functionality with multi-beat support
Merges it with Csaba's AXI monitor from Axi4 passive vip #391, creating one unified agent for Active (manager) and Passive (monitor) modes
Applies various bug and compilation fixes to the agent
Integrates the agent in the top TB as a monitor on each port of the crossbar
creates an environment level scoreboard

This was tested with the top level CVA6-based test cases.

Will close issue #168

rswarbrick

Thank you very much for doing this (and getting my completely untested code working...)

Do you think you could cherry-pick the various fixes in "axi agent compilation fixes" to the commits that made the mistakes? Since we don't use squash merge in Mocha, this is a way to avoid putting Rupert's silly mistakes into the history :-)

tchilikov-semify · 2026-07-22T13:11:04Z

Thank you very much for doing this (and getting my completely untested code working...)

Do you think you could cherry-pick the various fixes in "axi agent compilation fixes" to the commits that made the mistakes? Since we don't use squash merge in Mocha, this is a way to avoid putting Rupert's silly mistakes into the history :-)

Hey Rupert,

Sure, I can merge the patches into your commits. This would also encompass the handshaking bugfix commit, for a total of two commits :)

This is the first step towards a simple AXI agent. It will only have to handle the subset of AXI that is in use in the blocks in question (which work by translating to TLUL, so they aren't doing anything particularly exciting). In this commit, we're just defining interfaces for the five channels (which are AW, W, B, AR and R). Co-authored-by: tchilikov-semify <christian.tchilikov@semify-eda.com>

The axi_read_request_item and axi_read_data_item classes are intended to be randomised (when a sequence wishes to send either read requests or data responses). The axi_read_item class can be used by a monitor that sees a read request and then one or more responses. Co-authored-by: tchilikov-semify <christian.tchilikov@semify-eda.com>

When the agent is representing an AXI Manager, this will be useful for the B and R channels. Co-authored-by: tchilikov-semify <christian.tchilikov@semify-eda.com>

These drive write requests (AW) and write data (W) and also drive the write response channel (B). Co-authored-by: tchilikov-semify <christian.tchilikov@semify-eda.com>

Co-authored-by: tchilikov-semify <christian.tchilikov@semify-eda.com>

For an example use-case, suppose you are reading with AR / R transfers. You send an AR transfer with some ARID that will have a burst with k beats. Now you want consume read data with that many (k) R transfers using the some ID. To do so: - Run k axi_mgr_read_data_seq sequences, calling on_response() after each finishes. - (In parallel) call wait_for_response() k times. The trick is that these sequences might respond with different IDs, but that doesn't matter: the sequences are just actings as tokens to allow *something* to come back.

tchilikov-semify · 2026-07-22T14:15:10Z

Hey @rswarbrick,
Thanks a lot for the in-depth review! I'll go through all of the comments and address them.

In the meanwhile, I've folded the old compilation bugfixes commit into the respective commits that you made, so the commit history should be clear of bugs now.

Co-authored-by: tchilikov-semify <christian.tchilikov@semify-eda.com>

tchilikov-semify · 2026-08-12T16:33:30Z

The AXI driver has been ran past the ARM axi4 protocol assertions using the axi_sram.sv of mocha as a DUT as a preliminary validity check. The driver exercised the majority of the testcases from #667 and the assertions did not fire or indicate incorrect behavior, suggesting correct functionality thus far.

To do so, we add a (pretty trivial) reg_adapter and a sequencer in a layered vseq that runs the resulting translated items. Co-authored-by: tchilikov-semify <christian.tchilikov@semify-eda.com>

Merge per-channel reset monitors into a unified reset monitor by introducing a shared clock and reset interface to the agent.

Add AXI transaction monitor which snoops the 5 channels and rebuilds AXI transactions, then broadcasts them. Monitor is built unconditionally.

rswarbrick

Here are some notes about the "fix axi handshaking" and "multi-beat transaction support" commits.

These both look really good: I like the code, and it's just some nitty notes about comments.

rswarbrick · 2026-08-21T11:26:15Z

+
+        // Drive rready and watch for the actual transfer. We track the value we drive in
+        // rather than reading it back from the clocking block, and we sample on that exact
+        // handshake edge. This is what makes the accept protocol-correct:


Nit: I think this is a stray hyphen. (Currently looks like "protocol-correct" is an adjective)

rswarbrick · 2026-08-21T11:29:45Z

-          @(m_vif.mgr_cb);
+          if (m_vif.mgr_cb.rvalid === 1'b1) begin
+            if (rready) break;  // rvalid && rready on this edge: beat transferred
+            delay++;            // counts the cycle just elapsed, including the first rvalid one


Nit: Probably better to phrase this as "count the ..." (to avoid it sounding like it's a number of counts)

rswarbrick · 2026-08-21T11:30:16Z

-        // When we get here, we have finished accepting a response and we are at the end of a cycle
-        // where rvalid and rready were asserted. Write a sequence item to represent the response
-        // that we have seen to our read_data_item output argument.
+        // The beat transferred on the edge that just finished: sample the value.


An edge is a zero-time event, so doesn't really "finish". Probably "just happened" would be better.

rswarbrick · 2026-08-21T11:31:04Z

+
+        // Drive bready and watch for the actual transfer. We track the value we drive in
+        // rather than reading it back from the clocking block, and we sample on that exact
+        // handshake edge. This is what makes the accept protocol-correct:


As with the read driver, I think this should drop the hyphen.

rswarbrick · 2026-08-21T11:31:45Z

-          @(m_vif.mgr_cb);
+          if (m_vif.mgr_cb.bvalid === 1'b1) begin
+            if (bready) break;  // bvalid && bready on this edge: response accepted
+            delay++;            // counts the cycle just elapsed, including the first bvalid one


As with the driver, I'd suggest "count" here.

rswarbrick · 2026-08-21T11:37:17Z

+//      the request illegal. The burst length comes from m_ar_req.m_len, so the sequence expects
+//      m_len + 1 beats.


Nit: I don't think the second half of the sentence follows from the first. I just checked the spec quickly for phrasing. How about "The m_len variable controls ARLEN and the burst has ARLEN+1 beats." ?

rswarbrick · 2026-08-21T11:38:42Z

+//      the request illegal. The burst length comes from m_ar_req.m_len, so the sequence expects
+//      m_len + 1 beats.
+//   - Optionally configure m_r_accept to control rready timing (see axi_mgr_read_data_seq). Its
+//      m_use_fixed_*/m_fixed_* pins are copied to every beat; unpinned fields are randomised


Nit: I don't think "pins" is the right noun here. Maybe just "values"?

rswarbrick · 2026-08-21T11:42:46Z

+  // response into the router. Spawned once per beat by body(); beat_num only names the seq.
+  extern local task accept_one_beat(int unsigned beat_num);
+
+  // Take n_beats responses for our AR's ID back out of the router, in beat order, appending each


I'm not sure what "AR" means here. I don't think that ARID splits up as "AR"+"ID".

rswarbrick · 2026-08-21T11:45:13Z

+               $sformatf({"m_read_beats already holds %0d beats. Has this sequence ",
+                          "been started twice?"}, m_read_beats.size()))
+  end
+  m_read_beats.delete();


I'd move this into the if block above: equivalent and it might make the code slightly more obvious.

rswarbrick · 2026-08-21T11:47:28Z

+  axi_mgr_read_data_seq r_seq =
+    axi_mgr_read_data_seq::type_id::create($sformatf("r_seq_%0d", beat_num));
+
+  r_seq.m_use_fixed_ready_without_valid_pct = m_r_accept.m_use_fixed_ready_without_valid_pct;


Could this have been done by clone()'ing m_r_accept?

rswarbrick

Two more minor notes about "add multi-beat transaction support"

rswarbrick · 2026-08-21T11:53:53Z

+
+// A subclass of axi_mgr_write_data_seq that sends a caller-supplied list of write data items, one
+// per beat, in order. Used for multi-beat write bursts. The beats are not randomised: each item is
+// driven verbatim as supplied, except WLAST.


This should probably be made more explicit. How about "... except that WLAST is asserted when driving the final item." ? (Phrasing it like this avoids it sounding like we're changing the contents of the item).

rswarbrick · 2026-08-21T11:55:17Z

+
+  extern function new(string name="");
+
+  // Overrides axi_mgr_write_data_seq::populate_item to "produce" each beat by copying the next


I'd stick to the imperative, so this could just be "Override".

rswarbrick

A minor note about error messages in "add clk_rst_if to axi interfaces". (I really like this change though!)

rswarbrick · 2026-08-21T11:58:57Z

 task axi_mgr_read_data_driver::run_phase(uvm_phase phase);
-  if (m_vif == null) begin
+  if (m_vif == null || m_clk_rst_vif == null) begin
    `uvm_fatal(get_full_name(), "Cannot drive interface: vif is null.")


Oh, I think this should probably now be something more like "Cannot run driver: either m_vif or m_clk_rst_vif is null."

rswarbrick · 2026-08-21T11:59:50Z

 task axi_mgr_read_request_driver::run_phase(uvm_phase phase);
-  if (m_vif == null) begin
+  if (m_vif == null || m_clk_rst_vif == null) begin
    `uvm_fatal(get_full_name(), "Cannot drive interface: vif is null.")


As with the read data driver, this probably needs to mention both interfaces.

rswarbrick · 2026-08-21T12:00:05Z

 task axi_mgr_write_data_driver::run_phase(uvm_phase phase);
-  if (m_vif == null) begin
+  if (m_vif == null || m_clk_rst_vif == null) begin
    `uvm_fatal(get_full_name(), "Cannot drive interface: vif is null.")


As with the read data driver, this probably needs to mention both interfaces.

rswarbrick · 2026-08-21T12:00:14Z

 task axi_mgr_write_request_driver::run_phase(uvm_phase phase);
-  if (m_vif == null) begin
+  if (m_vif == null || m_clk_rst_vif == null) begin
    `uvm_fatal(get_full_name(), "Cannot drive interface: vif is null.")


As with the read data driver, this probably needs to mention both interfaces.

rswarbrick · 2026-08-21T12:00:22Z

 task axi_mgr_write_response_driver::run_phase(uvm_phase phase);
-  if (m_vif == null) begin
+  if (m_vif == null || m_clk_rst_vif == null) begin
    `uvm_fatal(get_full_name(), "Cannot drive interface: vif is null.")


As with the read data driver, this probably needs to mention both interfaces.

rswarbrick

Some notes about the (excellent!) change that adds axi_widths_pkg. They're all about alignment: sorry - very boring.

rswarbrick · 2026-08-21T12:03:26Z


  bit         m_use_fixed_id;
-  bit [31:0]  m_fixed_id;
+  bit [AxiMaxIdWidth-1:0]  m_fixed_id;


I'm a big fan of this change, but could you realign the adjacent variables?

I think that's probably better than switching to e.g. bit m_use_fixed_id;, but either seems reasonable. It's just that "aligned to something that used to be there" is definitely not right!

rswarbrick · 2026-08-21T12:04:25Z

  // This is sent as AWID, whose width is configurable (and will be checked against the
  // corresponding width in the interface by the driver).
-  rand bit [31:0]                  m_id;
+  rand bit [AxiMaxIdWidth-1:0]                  m_id;


The alignment of the variables seems to have gone a bit wiggly in this file.

rswarbrick · 2026-08-21T12:04:55Z

  // This is sent as AWID, whose width is configurable (and will be checked against the
  // corresponding width in the interface by the driver).
-  rand bit [31:0]                  m_id;
+  rand bit [AxiMaxIdWidth-1:0]                  m_id;


As with axi_fixed_read_req_item, I think the alignment is a bit wrong in this file.

rswarbrick · 2026-08-21T12:05:41Z

+  wire [AxiMaxIdWidth-1:0]   rid;
+  wire [AxiMaxDataWidth-1:0] rdata;
+  wire [AxiRespWidth-1:0]    rresp;
  wire          rlast;


Could you indent rvalid, rready and rlast to match the other variables that have moved outwards?

rswarbrick · 2026-08-21T12:06:11Z

@@ -64,22 +65,22 @@ interface axi_read_data_if (input clk_i, input rst_ni);
  // these, but take masks into account for signals with configurable length and are also cleared on
  // reset.
  logic          rvalid_driven, rvalid_internal;


Could you indent the variables to line up in this block?

rswarbrick · 2026-08-21T12:09:56Z

  // Copies of the signals that are driven by mgr_cb (only used if if_mode == Host). The "*_driven"
  // signals are directly driven by the clocking block. The "*_internal" signals track these, but
  // take masks into account for signals with configurable length and are also cleared on reset.
  logic         awvalid_driven, awvalid_internal;
