[dv,sram] add axi_sram verification plan and tag architecture spec by tchilikov-semify · Pull Request #667 · lowRISC/mocha

tchilikov-semify · 2026-07-10T15:44:07Z

No description provided.

martin-velay

I have some comments, and also I'd like to know if you feel it was a bad experience to create a vPlan based on DVPlan? I think you are among th 1st to do the full exercise (except myself) and I need to get feedback 😃

tchilikov-semify · 2026-07-14T14:59:31Z

Thanks for the feedback, @martin-velay 😃

Regarding DVPlan: I found that the flow and working with the tool was actually quite nice and polished (so far).
I was very fond of the ability to start with a CSV and convert to an HJSON after the fact.

One pain point I have though, is the spec annotation capabilities. A random generated tag means that each time the spec is updated and changed, all of the tags would be re-generated. This would make updating the vplans a bit of a nightmare, since all of the tags would have to be re-mapped.

I think a solution to this could be a per-line / per-sentence hash. This way, the hash only changes if the contents of the line change.

Of course, this sounds simple but it would introduce edge cases (white spaces, punctuation, etc).

I have yet to re-generate or re-map anything, but I anticipate that this would be tedious as it currently stands.

Other than this, it was quite straight-forward!

I plan to map the actual SV testcases with a comment to the tags as well.

martin-velay · 2026-07-14T15:31:08Z

Thanks for the feedback, @martin-velay 😃

Regarding DVPlan: I found that the flow and working with the tool was actually quite nice and polished (so far). I was very fond of the ability to start with a CSV and convert to an HJSON after the fact.

One pain point I have though, is the spec annotation capabilities. A random generated tag means that each time the spec is updated and changed, all of the tags would be re-generated. This would make updating the vplans a bit of a nightmare, since all of the tags would have to be re-mapped.

I think a solution to this could be a per-line / per-sentence hash. This way, the hash only changes if the contents of the line change.

Of course, this sounds simple but it would introduce edge cases (white spaces, punctuation, etc).

I have yet to re-generate or re-map anything, but I anticipate that this would be tedious as it currently stands.

Other than this, it was quite straight-forward!

I plan to map the actual SV testcases with a comment to the tags as well.

Thanks @tchilikov-semify for the feedback.
You could try to update the spec locally and run again the tagging script, I think only the new untagged lines will get a new tag, the others should remain the same. But if a given line change its content, the tag won't be updated and it's up to the approvers to flag that the vPlan should be updated. This is maybe flaky and we also were thinking about having short hashes instead. I am unsure if we have an opened issues but I think that's something to explore further.

marnovandermaas

I've left some reviews on the initial commits (the vplan I'll leave to @martin-velay

martin-velay · 2026-08-11T09:38:05Z

+<!-- BEGIN generated memory map -->
+| Base address | Top address | Reserved   | Function      |


The missing tags here don't cause any trouble to DVPlan?

martin-velay · 2026-08-11T09:42:23Z

+It needs to support AXI4 protocol including:<!-- mcykq8 -->
+- Bursts, where the last signal must be indicated correctly.<!-- o02amt -->
+- Response must have the same AXI4 ID as the request<!-- 4t4cew -->
+- Atomic support is *excluded*. An atomic accesses should return an error.<!-- bsi4rc -->


This is not covered in the vPlan, we should add it?

martin-velay · 2026-08-11T09:56:10Z


    # Subparser for gen_memory_map
    map_parser = subparsers.add_parser(
        "gen-memory-map", help="Generate a svg file with the memory map."


Need to be removed from here too?

And also need to delete the file itself doc/img/memmap.svg from the repo?

martin-velay · 2026-08-11T09:57:11Z

+                    }
+                    multiple_outstanding_transactions:
+                    {
+                        reference: mcykq8


Suggested change

reference: mcykq8

Reference: mcykq8

DVPlan will understand, but it's more to have a consistent file. If you prefer you can also change them all in lowercase everywhere (not only for "Reference")

martin-velay · 2026-08-11T10:00:41Z

+                        Node_Type: metric
+                        Priority: 1
+                        Comment: Transaction should be dropped cleanly. The next transaction after an in-flight reset should still be accepted as normal. Would be good to clarification on the expected state of SRAM after a reset (i.e if a reset comes in during a 2-beat capability write)
+                    },


Extra comma?

martin-velay · 2026-08-11T10:01:47Z

+                    }
+                    subword_read_clears_tag:
+                    {
+                        Reference: raa5pw


Also add 832lpx to avoid to have a hole

martin-velay · 2026-08-11T10:02:59Z

+            {
+                Description: Address decode through the real mocha AXI crossbar. Only the SRAM aperture (SRAMBase=0x10000000, 128 KiB) returns OKAY; every other address returns DECERR (the xbar has no default master port; non-SRAM device ports carry axi_err_slv). The scoreboard is decode-aware: in-aperture it checks data/tag, out-of-aperture it expects DECERR and flags any OKAY as a decode bug.
+                Node_Type: section_title
+                sram_reachable:


No "Reference", maybe to lhfz6r?

martin-velay · 2026-08-11T10:03:19Z

+                    Priority: 3
+                    Comment: AXI4 forbids a burst from crossing a 4 KB boundary, so a compliant master can't issue such a burst. axi_sram itself does not range-check (mem_err_i=0; it masks the address and would silently wrap), so range enforcement rests entirely on the AXI driver being compliant.
+                }
+                sram_boundary:


Same, no "Reference", maybe to lhfz6r?

martin-velay · 2026-08-11T10:07:29Z

+| 0x00080000   | 0x00087fff  | 32.0 kiB   | ROM           |<!-- tm13gh -->
+| 0x10000000   | 0x1001ffff  | 128.0 kiB  | SRAM          |<!-- lhfz6r -->
+| 0x20000000   | 0x2000ffff  | 64.0 kiB   | DEBUG_MODULE  |<!-- sgfpp0 -->
+| 0x20010000   | 0x2001ffff  | 64.0 kiB   | MAILBOX       |<!-- z1bwrt -->
+| 0x20020000   | 0x2002ffff  | 64.0 kiB   | DV_SW_IFC     |<!-- u122px -->
+| 0x30000000   | 0x30007fff  | 32.0 kiB   | ETHERNET      |<!-- 2z3zns -->
+| 0x40000000   | 0x4000ffff  | 64.0 kiB   | GPIO          |<!-- l5wm3d -->
+| 0x40020000   | 0x4002ffff  | 64.0 kiB   | CLKMGR        |<!-- zuyj1v -->
+| 0x40030000   | 0x4003ffff  | 64.0 kiB   | RSTMGR        |<!-- n2dywn -->
+| 0x40040000   | 0x4004ffff  | 64.0 kiB   | POWER_MANAGER |<!-- vtnnyw -->
+| 0x40050000   | 0x4005ffff  | 64.0 kiB   | ROM_CTRL      |<!-- ov4jpa -->
+| 0x40060000   | 0x4006ffff  | 64.0 kiB   | ENTROPY_SRC   |<!-- s8gkf4 -->
+| 0x41000000   | 0x4100ffff  | 64.0 kiB   | UART          |<!-- heoi9y -->
+| 0x42000000   | 0x4200ffff  | 64.0 kiB   | I2C           |<!-- 94u3qu -->
+| 0x43000000   | 0x4300ffff  | 64.0 kiB   | SPI_DEVICE    |<!-- vniczf -->
+| 0x44000000   | 0x4400ffff  | 64.0 kiB   | TIMER         |<!-- gjk3vu -->
+| 0x45000000   | 0x4500ffff  | 64.0 kiB   | SPI_HOST      |<!-- jkyz51 -->
+| 0x48000000   | 0x4c004003  | 64.0 MiB   | PLIC          |<!-- pfftm1 -->
+| 0x80000000   | 0xbf7fffff  | 1016.0 MiB | DRAM          |<!-- 04smz7 -->


I think none of these tags are in the vPlan, if nothing should be verified now add _x

martin-velay · 2026-08-11T10:09:46Z

+                        Reference: rrni5j
+                        Description: DUT is reset during an AXI burst
+                        Node_Type: metric
+                        Priority: 1


Just a little note, I am usure it's done on purpose, the priority 0 is the highest one. Bu you can keep it as it is if you like.

tchilikov-semify requested review from marnovandermaas and martin-velay July 10, 2026 15:44

martin-velay reviewed Jul 14, 2026

View reviewed changes

tchilikov-semify force-pushed the axi_vplan branch from 59c77a5 to f588fc4 Compare July 14, 2026 13:58

tchilikov-semify force-pushed the axi_vplan branch from 5ca16c0 to d7e5e65 Compare July 15, 2026 11:09

tchilikov-semify force-pushed the axi_vplan branch 2 times, most recently from e4af936 to 3fba033 Compare August 3, 2026 12:15

tchilikov-semify requested a review from martin-velay August 3, 2026 12:17

marnovandermaas reviewed Aug 7, 2026

View reviewed changes

Comment thread util/artefacts.py

Comment thread util/rdlgenerator.py Outdated

Comment thread doc/ref/arch.md Outdated

tchilikov-semify added 3 commits August 10, 2026 13:20

[util] update rdlgenerator to output memory map in markdown

95cf30c

[arch] tag architecture spec

06fdbb5

[arch] update mocha spec

8020410

tchilikov-semify force-pushed the axi_vplan branch from 3fba033 to e7efcf5 Compare August 10, 2026 12:20

[sram] add sram verification plan

4f6c554

tchilikov-semify force-pushed the axi_vplan branch from e7efcf5 to 4f6c554 Compare August 11, 2026 10:05

martin-velay reviewed Aug 11, 2026

View reviewed changes

		<!-- BEGIN generated memory map -->
		\| Base address \| Top address \| Reserved \| Function \|

Uh oh!

Conversation

tchilikov-semify commented Jul 10, 2026

Uh oh!

martin-velay 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!

tchilikov-semify commented Jul 14, 2026

Uh oh!

martin-velay commented Jul 14, 2026

Uh oh!

marnovandermaas left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants