AXI crossbar DV - Top-level preliminary version of AXI scoreboard

[jayalp]

The AXI crossbar will only be verified at top-level for the 1st stage of the project with a preliminary version of the SCB and usage of an open source AXI agent/VIP (potential sources: https://github.com/antmicro/axi-vip, which has been forked from https://github.com/SymbiFlow/axi-vip, also https://github.com/taichi-ishitani/tvip-axi/tree/master... -> need further seach).

• First we need to find a reliable open source UVM AXI agent/VIP. This agent will be used at block-level later, but we can already start to use it at top level.
• Then we need to add this AXI agent into our top DV env (initial top env PR) for each AXI interface we want to monitor with binds.
• Then create a simple scoreboard (reusable if possible at block level where we'll extend its features later).
• Instantiate this SCB and connect the TLM ports to all the AXI monitors.
• Make sure the SCB is able to check in/out AXI transactions against each other and check if the AXI transactions have been routed properly.

[KolosKoblasz-Semify]

Here is this fresh VIP: link which was committed 2 weeks ago.
Pros: It has protocol checker assertions
Cons: The Author didn't set under what kind of License he publishes the source code. So it is not Apache 2.0, but may be if we ask him he can change that.

[KolosKoblasz-Semify]

The tvip-axi probably will work for us, these are the cons I've found so far:

1. It uses two subrepos: tvip-common and tue. I'm not sure how we handle subrepo vendoring
2. I haven't found any assertions which could indicate protocol violations during simulation. Did search all 3 repos.

[martin-velay]

@KolosKoblasz-Semify
I have requested the License update to Apache 2.0 to the owner of the AXI VIP. He has done the update for us

[csabakiss-semify]

Do you have arm developer account? I think the SVA based protocol checkers are free, but you need to register.
https://developer.arm.com/downloads/view/BP063

[martin-velay]

@csabakiss-semify, I have an account yes, and I can download the assertions from your link thanks.
I don't really know how we can manage the usage of it as they are under ARM license. Of course, we cannot open source this, but I think we can still use it locally. That's probably a point I need to discuss internally.

Caution

Please do not push any of the ARM code on our Mocha repository, as our directory will become open-source eventually.

[marnovandermaas]

Can we have an open source set of assertions like https://github.com/wendigp/Development-of-AXI4-Verification-IP-VIP-using-UVM/blob/main/assertions/axi_assertions.sv
And then add a guide on how to optionally include the proprietary Arm assertions?
As Martin says it is important that our repository is fully open source so we cannot include proprietary code in it, and it would be nice if there is at least some basic functionality to check the bus in the open source world without requiring to use the proprietary ones.

[martin-velay]

Thanks Marno for the pointer, I also heard about that one https://github.com/axi-security/eXpect which comes from some Zurich ETH students and might be a complement. If we feel it might be used, we can probably ask if they can change the license to Apache 2.0.

[csabakiss-semify]

Hi Everyone,

I have gone through the AXI XBAR design and the referenced 2 VIPs.

First of all I have some general questions:
• What does top level verification mean in this context? The stimuli are generated by the CVA6 and the connected slave and only passive VIP instances and corresponding scoreboard are required?
• Which repository shall I integrate the AXI VIPs and scoreboards?
One more comment: on the Mocha block diagram 4 slaves are connected to the south side of the crossbar, but in the design the SRAM and the Tile crossbar is connected.

In terms of the VIPs, let's start with the https://github.com/wendigp/Development-of-AXI4-Verification-IP-VIP-using-UVM/tree/main:
• This is a well structured VIP with some limitations
• The transaction delays shall be controlled from the test sequence instead of the transaction item
• In case of on-the-fly reset, the driver would fail to recover
• I can see only one test, when only 1 master and 1 one slave are connected to each other, so there could be issues in case of multiple agent instances (workaround is to instantiate multiple VIP envs)
• Reordering is not supported by the slave agent. (Reordering, when the read transactions overtake each other, because for example a slave is faster than the other one.
Do we want to support reordering?
• It provides a scoreboard, which is more a memory model, so it checks if the written data can be read back.

The second VIP is this one https://github.com/taichi-ishitani/tvip-axi/tree/master:
• This VIP provides much more features (transaction delays, reordering)
• It is not very well structured, for example I do not like to use parametrized classes, because in case of reuse, there could be issues.
• Also there are multiple classes in the same file, which does not hurt, and probably there would be no issue in import order.
• The VIP is sensitive only the negative edge of the reset. If you start a test with default 1'b0 reset and release it (which is more realistic), then this VIP does not come out from reset.
• All of the above mentioned issues can be handled, but this is not something developing on top of the existing one.

My lst topic is the protocol checkers:
• Do we need formal proof on the SVAs? Not all protocol checkers are formal friendly.

[martin-velay]

Hi @csabakiss-semify,

That's a good starting point, thanks for your analysis. I have numbered the items to avoid confusion.

1. General questions:
   1.1. At top level, as you said, we can only expect passive VIP on the interfaces and connected to a scoreboard. We don't need more than that, except maybe some assertions, the detailed DV will take place at block level. As per of the first stage of the project we wanted to check that the system works in general, mostly at top level. That's why we have decided to perform those preliminary checks at the top level. Don't you think it makes sense?
   1.2. You can create the VIP at this location: hw/dv/axip_vip, for the inside files organization usually we do it more or less in a flat way (example), but feel free to make a better proposal.
   1.3. The current design is incomplete and still under construction, eventually it'll look like the diagram.
2. Existing VIP analysis:
   2.1. @marnovandermaas, do we need to support reordering?
   2.2. I would also prefer to avoid parametrized classes and avoid of having multiple class in one file.
   2.3. The reset on the fly management in OpenTitan is not really robust, that's something we need to change. If you have some inputs on this aspect, I'd be happy to discuss and agree on the approach we want to take for Mocha. Indeed, that's a very important aspect and often a pitfall.
   2.4. About those 2 VIP sources, I would say that we don't need to take them as such, as they don't look that good, I would prefer to build our own solution. But we can still use some pieces if they are here and help us saving time. WDYT?
3. Formal:
   3.1. I wouldn't say that we need formal, but if some aspects are easier to verify with formal then we should take that way. We need to take the most effective and with the most guarantee IMO.
   3.2. But as mentioned before we'll bind the protocol checker assertions for the dynamic simulations. The current plan would be to add a define or a control knob to enable protocol checking based on ARM assertions (NOT "bind" by default). As by default we should be fully open source compliant, so we'll support some open source assertions. We will add a README note explaining that people can download ARM assertions from this link and add them into a particular directory.

I hope I have answered all your concerns, we can have a call today if you want to. You can also answer here if you prefer.

[csabakiss-semify]

Hi @martin-velay,
I think a meeting makes perfect sense and then we can capture what we agreed here.

[martin-velay]

@csabakiss-semify, could you add a comment to explain what this PR #391 will cover once merged.

[csabakiss-semify]

PR #391 will cover a passive AXI UVM monitor which is integrated to the top level DV environment and connected to the AXI XBAR AXI ports. There will be a scoreboard that checks whether the AXI transactions are routed as per the address map and the transactions attributes are consistent on the manager and subordinate side.