-
-
Notifications
You must be signed in to change notification settings - Fork 80
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
VHPI: Add support for record types #728
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We have all the information necessary to determine the offset of indexed names when creating them. To simplify the process of determining the offset by pre-calculating them.
Back when prefixnames got added I forgot to add support for the prefix property itself. Add it now.
Add support for record elements. Convert the vhpi5 test to gold to make it easier to check recursive structures, and change the record definition to something a little more interesting.
Add support for the NumFields property of record types.
The other major type of prefixed names is selected names. Add support for them. In many ways they are simpler than indexed names, since we don't have to keep track of multiple indices. Getting/setting is not supported, but it will be addressed in the next commit.
Inhomogenous types are create scopes instead of signals. Additionally, inhomogenous arrays have nested scopes for their elements. Add the necessary machinery to determine the scope for a name/objDecl, and look up the signal at the final level. In the style of vhpi7, assign a value to each element of the test records, and try to change them. To avoid needing to repeat the same code while recursing through records, we just print out the values and check them against the golden output. We cheat a bit for multidimensional arrays because array properties are checked properly in vhpi7.
When cocotb tries to access an object with a name like `VHPI5.O.F`, it doesn't know whether O is a signal or a record. This ambiguity could be resolved by trying to look up the name like `:VHPI5:O.F` or `:VHPI5:O:F`, but cocotb can't determine which to use ahead of time. This is a limitation of cocotb, but probably not one which will ever get resolved. Add support for looking up record types by name, primarily to allow cocotb to access them.
nickg
approved these changes
Jun 22, 2023
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thanks.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds basic support for record types in VHPI. Unconstrained records are not supported, as record subtypes have the same issue that array subtypes did.