Skip to content

[dv,sram] add axi_sram verification plan and tag architecture spec - #667

Open
tchilikov-semify wants to merge 4 commits into
lowRISC:mainfrom
tchilikov-semify:axi_vplan
Open

[dv,sram] add axi_sram verification plan and tag architecture spec#667
tchilikov-semify wants to merge 4 commits into
lowRISC:mainfrom
tchilikov-semify:axi_vplan

Conversation

@tchilikov-semify

Copy link
Copy Markdown
Collaborator

No description provided.

@martin-velay martin-velay left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 😃

Comment thread doc/ref/arch.md Outdated
Comment thread doc/ref/arch.md Outdated
Comment thread doc/ref/arch.md Outdated
Comment thread hw/top_chip/dv/axi_sram/axi_sram_vplan.hjson Outdated
Comment thread hw/top_chip/dv/axi_sram/axi_sram_vplan.hjson Outdated
Comment thread hw/top_chip/dv/axi_sram/axi_sram_vplan.hjson Outdated
Comment thread hw/top_chip/dv/axi_sram/axi_sram_vplan.hjson
Comment thread hw/top_chip/dv/axi_sram/axi_sram_vplan.hjson Outdated
Comment thread doc/ref/arch.md Outdated
Comment thread hw/top_chip/dv/axi_sram/axi_sram_vplan.hjson
@tchilikov-semify

Copy link
Copy Markdown
Collaborator Author

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

Copy link
Copy Markdown
Contributor

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 marnovandermaas left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment thread util/artefacts.py
# rdl: embed the memory map table into the architecture document
[
"util/rdlgenerator.py",
"embed-memory-map-md",

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would probably replace the image generation with the markdown generation here so we don't have two very similar processes in the codebase.

Comment thread util/rdlgenerator.py Outdated
MEMORY_MAP_MD_END = "<!-- END generated memory map -->"


def memory_map_table(rdljson: dict) -> list[str]:

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This dict doesn't have the sub-types. You can check you've done this correctly using mypy.

Comment thread doc/ref/arch.md Outdated
If a portion of the 128-bit aligned region is written it must clear the tag for the whole region including when a partial write strobe is used.<!-- 893tz4 -->

Reads that only read part of a 64-bit value are allowed from valid capability regions, but these should have their tag cleared.<!-- raa5pw -->
Reads that only read part of a 64-bit value are allowed from valid capability regions, but these reads should have their tag cleared in the response. These reads do not modify the state of the tag in memory.<!-- raa5pw -->

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Each sentence should have its own line.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants