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

Patch 1 #10

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

Patch 1 #10

wants to merge 5 commits into from

Conversation

norbertbonnici
Copy link

Added missing library and constant declarations

Norbert Bonnici added 5 commits January 23, 2020 16:15
Variables required
Crash on accessing attributes of a generic in packages.
Work around is to access attribute of a constant created from the generic.
@eine
Copy link
Contributor

eine commented Jan 23, 2020

@norbertbonnici, thanks for opening this PR! Overall, it looks good, but I think that additional tests should be added, instead of putting them all together. This is because simulators/tools that do not support a single feature might crash during analysis, making it impossible to test other features.

Can you please create several sources, similar to tb_matching_operator_*gt*.vhd? So tb_generics_in_packages_integer.vhd, tb_generics_in_packages_std_logic.vhd, tb_generics_in_packages_std_logic_vector.vhd, etc.

Also, 98ec125 seems like a fix for some simulator having partial support (it feels like ghdl/ghdl#1063 (comment)). I think that the test should not include it. Optionally, we can have a test with it and another one without it.

By the same token, 4c6369c should be two separate tests.

Overall, note that the purpose of this repository is to test the compliance of certain tools with the standard. The fact that we are using GHDL (or any other simulator) in the CI job should not affect the tests. That's why 'fixes' should be separated. Some other tool might work without the fix but not with it.

@norbertbonnici
Copy link
Author

@norbertbonnici, thanks for opening this PR! Overall, it looks good, but I think that additional tests should be added, instead of putting them all together. This is because simulators/tools that do not support a single feature might crash during analysis, making it impossible to test other features.

Can you please create several sources, similar to tb_matching_operator_*gt*.vhd? So tb_generics_in_packages_integer.vhd, tb_generics_in_packages_std_logic.vhd, tb_generics_in_packages_std_logic_vector.vhd, etc.

Yes of course! I will have a look at the LRM and see what is required.

Also, 98ec125 seems like a fix for some simulator having partial support (it feels like ghdl/ghdl#1063 (comment)). I think that the test should not include it. Optionally, we can have a test with it and another one without it.

Is this a GHDL or a vunit issue? I think I had similar issues with vunit and modelsim yesterday.

By the same token, 4c6369c should be two separate tests.

Overall, note that the purpose of this repository is to test the compliance of certain tools with the standard. The fact that we are using GHDL (or any other simulator) in the CI job should not affect the tests. That's why 'fixes' should be separated. Some other tool might work without the fix but not with it.

Gotcha!

@eine
Copy link
Contributor

eine commented Jan 24, 2020

Yes of course! I will have a look at the LRM and see what is required.

Note that, unlike VHDL 2019 (which contains ~60 modifications/features), VHDL 2008 was a major rewrite of the standard. This is to say that you could go mad if you tried to write tests for all the possible cases! Hence, the approach we suggest is for users to take the testbenches they already have and extract MWEs for them, rather than writing "complete" artificial tests from scratch. This is an interesting approach because it lets us know which features do we prioritise as a community.

Also, 98ec125 seems like a fix for some simulator having partial support (it feels like ghdl/ghdl#1063 (comment)). I think that the test should not include it. Optionally, we can have a test with it and another one without it.

Is this a GHDL or a vunit issue? I think I had similar issues with vunit and modelsim yesterday.

I am pretty sure this is NOT an issue with VUnit, because VUnit's check functions/procedures are essentially wrappers around VHDL assertions. You can see in ghdl/ghdl#1063 that the underlying issue was GHDL not guessing the type of the literal. However, when Tristan fixed it, both syntaxes work. Hence, in this case, I believe that both simulators (GHDL or ModelSim/QuestaSim) should accept both syntaxes. That's why we should have two tests. Anyway, I'm pinging @Paebbels and @LarsAsplund here for confirmation.

@bpadalino
Copy link
Contributor

This is a really old PR - does it still apply?

@umarcor
Copy link
Member

umarcor commented Feb 25, 2023

@bpadalino I think it does. It needs refactoring, as discussed above, but the additional tests introduced in this PR are not covered in the master|main branch yet.

@bpadalino
Copy link
Contributor

@norbertbonnici Are you willing to resurrect this PR, or do you want someone else to adapt it for you?

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.

4 participants