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.

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>

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

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

rswarbrick

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

rswarbrick

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

rswarbrick

One specific question: Is there a good reason to use dv_base_agent for the IP? It's designed to a very specific OpenTitan shape, as chosen by the DV lead at the time.

It's also actively against my design for this agent. If someone more important than me mandates that we use the class, I guess we have to. If not, I'd prefer we didn't.

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

+  parameter int  UserWidth = 1,
+  parameter uvm_pkg::uvm_active_passive_enum IsActive = uvm_pkg::UVM_ACTIVE,
+  parameter string InstId   = "axi_mgr",   // names the published axi_agent_cfg
+  parameter string CfgScope = "*"          // config_db publish scope glob


Is this design following a pattern for which you have a reference? I'm slightly surprised that you don't set things in the config db from the testbench, rather than the interface that gets instantiated.

Yes! The intent of this file is perhaps quite unclear from the perspective of this PR... Its purpose is to take the shape of the AXI peripherals used in mocha. In our agent, the AXI bus is represented by 5 interfaces, which map to the channels. In mocha, the AXI devices have ports which are represented by 2 interfaces, basically inputs and outputs (req and resp). This interface bridges the two.

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

+  // clear, the payload is randomised instead: still meaningless, but defined.
+  //
+  // Defaults set, so an idle channel drives X.
+  bit drive_x_when_idle = 1'b1;


I'm repeating myself here, but I think this should be set by calling a setter on the agent, which calls a setter on each of the drivers.

Note that you wrote earlier that the agent config just contained a list of virtual interfaces. I wasn't convinced. I'm still not :-)

Yes perhaps an agent wide config permeated into the configs... You were right in this regard. 😉

For my understanding, are you proposing that the agent reads this config and then calls the setters of the drivers, rather than passing the config directly to the drivers? This value is a genuine agent-wide knob, so I think it should live in the config. Is this what you had in mind?

tchilikov-semify · 2026-08-25T17:39:36Z

One specific question: Is there a good reason to use dv_base_agent for the IP? It's designed to a very specific OpenTitan shape, as chosen by the DV lead at the time.

It's also actively against my design for this agent. If someone more important than me mandates that we use the class, I guess we have to. If not, I'd prefer we didn't.

Honestly - its not strictly needed. This was a suggestion from an internal review that Martin did with Claude, which he told me to implement if it seems fitting. I thought it was fitting, since I saw that other mocha TBs use the dv base classes, but honestly I don't have a strong opinion on this (and honestly, I think the less dependencies an independent agent has, the better).

Shall I remove it?

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.

tchilikov-semify · 2026-08-26T14:52:53Z

Hey @rswarbrick - thanks for the in depth review again! It seems this PR is starting to come together 😄 I think I've addressed most of your comments. There's still 1 or 2 open questions, but I've re-triggered another review. Thanks!

tchilikov-semify requested review from marnovandermaas, martin-velay and rswarbrick July 22, 2026 11:29

tchilikov-semify mentioned this pull request Jul 22, 2026

Axi4 passive vip #391

Closed

tchilikov-semify requested a review from thommythomaso July 22, 2026 11:38

tchilikov-semify force-pushed the axi_driver_pr_new branch 3 times, most recently from 01fb3d1 to 3863316 Compare July 22, 2026 12:23

rswarbrick reviewed Jul 22, 2026

View reviewed changes

rswarbrick and others added 8 commits July 22, 2026 14:40

[dv,axi] Implement items for AXI write transactions

b59c688

[dv,axi] Define an item type to control how we accept responses

76a5434

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>

[dv,axi] Implement drivers for the Manager side of write channels

0ab815d

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>

[dv,axi] Implement drivers for the Manager side of read channels

eeea7ec

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

[dv,axi] Define item and monitor for resets on each AXI interface

8676709

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

rswarbrick reviewed Jul 22, 2026

View reviewed changes

tchilikov-semify force-pushed the axi_driver_pr_new branch from 3863316 to 0d44df6 Compare July 22, 2026 14:10

tchilikov-semify force-pushed the axi_driver_pr_new branch 9 times, most recently from a5c0dab to 6550b3a Compare July 23, 2026 09:27

[dv,axi] Allow axi_agent to connect to the register layer

ad294d5

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>

tchilikov-semify force-pushed the axi_driver_pr_new branch 4 times, most recently from c90d65e to b5b685e Compare August 17, 2026 15:12

tchilikov-semify requested a review from rswarbrick August 18, 2026 07:44

rswarbrick reviewed Aug 21, 2026

View reviewed changes

Comment thread hw/ip/dv/axi_agent/seq_lib/axi_mgr_write_listed_data_seq.svh Outdated

Comment thread hw/ip/dv/axi_agent/seq_lib/axi_mgr_write_listed_data_seq.svh Outdated

rswarbrick reviewed Aug 21, 2026

View reviewed changes

[dv,axi] fix axi handshaking for beat sampling on multi-beat traffic

389a8b6

tchilikov-semify force-pushed the axi_driver_pr_new branch from b5b685e to 34e89c4 Compare August 25, 2026 12:37

tchilikov-semify force-pushed the axi_driver_pr_new branch from 34e89c4 to 70f76a5 Compare August 25, 2026 17:55

tchilikov-semify linked an issue Aug 26, 2026 that may be closed by this pull request

AXI crossbar DV - Top-level AXI monitor to feed the scoreboard #168

Open

tchilikov-semify added 8 commits August 26, 2026 15:49

[dv,axi] add multi-beat transaction support to driver

d0af522

[dv,axi] add clk_rst_if to axi interfaces

b25fc41

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

[dv,axi] add axi_widths_pkg for shared signal widths

52631c5

[dv,axi] add monitor to AXI agent

adfcf0b

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

[dv,axi] use dv_base for vip

fc13127

[dv,axi] add axi_vip wrapper to agent

c2cba86

[dv,axi] add knob for x-injection on idle bus

fc968b7

[dv,top] integrate AXI4 monitors in top tb

da139c9

tchilikov-semify force-pushed the axi_driver_pr_new branch from 70f76a5 to da139c9 Compare August 26, 2026 14:49

tchilikov-semify requested a review from rswarbrick August 26, 2026 14:53

Uh oh!

Conversation

tchilikov-semify commented Jul 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rswarbrick left a comment

Choose a reason for hiding this comment

Uh oh!

tchilikov-semify commented Jul 22, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

tchilikov-semify commented Jul 22, 2026

Uh oh!

tchilikov-semify commented Aug 12, 2026

Uh oh!

rswarbrick left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rswarbrick left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

rswarbrick left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rswarbrick left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rswarbrick left a comment

Choose a reason for hiding this comment

Uh oh!

rswarbrick Aug 21, 2026

Choose a reason for hiding this comment

Uh oh!

tchilikov-semify Aug 25, 2026

tchilikov-semify commented Jul 22, 2026 •

edited

Loading

tchilikov-semify Aug 26, 2026 •

edited

Loading

tchilikov-semify commented Aug 25, 2026 •

edited

Loading