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

VHPI: Add support for record types #728

Merged
merged 7 commits into from
Jun 22, 2023
Merged

Conversation

Forty-Bot
Copy link
Contributor

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.

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.
Copy link
Owner

@nickg nickg left a comment

Choose a reason for hiding this comment

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

Looks good, thanks.

@nickg nickg merged commit a6340cd into nickg:master Jun 22, 2023
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.

2 participants