Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MC-1 PDF has mstatus as 64 bits and fields (like SIE) that shouldn't be present #105

Closed
james-ball-qualcomm opened this issue Oct 16, 2024 · 9 comments · Fixed by #140
Closed
Assignees

Comments

@james-ball-qualcomm
Copy link
Collaborator

image

@dhower-qc
Copy link
Collaborator

This is because the CRD generator is using the _64 arch definition. We need to create an architecture definition that corresponds to MC-1 and use that for generation.

@dhower-qc
Copy link
Collaborator

I've added a feature to create an architecture definition from a CRD. That fixes the length problem for, e.g., mstatus. However, things like SIE still show up because, while MC-1 mandates M-mode, it doesn't prohibit S-mode. How do you want to handle this?

@james-ball-qualcomm
Copy link
Collaborator Author

I like Ken's suggestion of showing all possible fields but making clear which ones are required for MC-1. Besides using colors like Ken suggested in the wavedroms, I'll also want to add the field descriptions to the Profiles and CRDs and then having some easy way to determine their presence would be useful since I'll either add that to the field descriptions or maybe have 2 lists (required for MC-1 vs. possible).

Hold on, the Profiles already show multiple profiles in one doc and I'd like the CRDs to have that too (just haven't done it yet). So, then the appendices would need to know what's possible for each profile/CRD in the spec which seems problematic. Any ideas?

@dhower-qc dhower-qc linked a pull request Oct 18, 2024 that will close this issue
@dhower-qc
Copy link
Collaborator

I can add colors to distinguish a field that is mandatory vs. optional (good idea @kdockser).

As for having multiple CRDs in the same document, we could generate the wavedrom for each CRD, compare them (they are just text), and display a single figure when they match and multiple when they don't.

@james-ball-qualcomm
Copy link
Collaborator Author

Sounds perfect.

@dhower-qc
Copy link
Collaborator

image

Look right?

@james-ball-qualcomm
Copy link
Collaborator Author

Cool. However, how are people supposed to know that red means not present (but defined in some ISA extension) and green means present in MC-1. Any possibility of making the red a pattern fill like below? Or make it grey matching the other grey (just with text in it vs. blank for existing grey) or change the other grey (the empty bit grey) to some other color?

image

@dhower-qc
Copy link
Collaborator

We are at the mercy of what wavedrom can render. There might be a way to import a color scheme, but you can see examples of the stock options here:

https://observablehq.com/collection/@drom/bitfield

@dhower-qc
Copy link
Collaborator

@kersten1, any insights on the wavedrom capabilities?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

2 participants