Hi! I've got a problem with a generic procedure.
procedure convert_to_type generic (type t)
parameter (constant s : in string; variable v : out t) is
begin
v := t'value(s);
end procedure;
procedure parse(constant s : in string) is
type value_t is (V1, V2, V3, V4);
procedure convert_to_value is new convert_to_type generic map (t => value_t);
variable v : value_t;
begin
convert_to_value("V1", v);
end procedure;Modelsim reports the following error Attribute "value" requires a scalar type mark prefix.
Is there a way to tell VHDL that the t type is going to be a scalar ? Or any tricks to overcome this issue ?
(I know I could have used directly value_t'value(v) but in my code, it's more complex that this MWE)
Thanks
@std-max Unfortunately not in VHDL 2008. on the convert_to_type procedure, type t could be literally any type - scalar, composite or access. So t'value cannot be used because it would be illegal for composite or access types. VHDL 2019 fixes this by allowing you to specify types to be scalar or composite (or just anything).
For example:
procedure some_proc generic( type t is array(natural range<>) of (type is <>) )Here, you are specifying that the type must be array of a scalar type.
Hi, I have a question about multiple processes driving an array of records in VHDL-2008, would you mind taking a look ? https://stackoverflow.com/questions/69428650/multiple-processes-driving-an-array-of-records-in-vhdl-2008
Care to vote on linkedin: For a VHDL Verification methodology, is it ok to use constructs that have been deprecated and removed from the language?
https://www.linkedin.com/feed/update/urn:li:activity:6850469284003610624/
https://www.linkedin.com/feed/update/urn:li:activity:6850469284003610624/
What are your all feelings about deprecating features in general? I Think it would be healthy to also consider removing things for which there exists preferred alternatives. It will reduce the maintenance burden and keep the language more clean. Can you think of features which you think VHDL can live without?
I still dont really understand why they were removed. There is/was code that already used the feature - Xilinx now use it to infer different behaviours for BRAM (to get write-before read behaviour). I still dont understand how a protected type is any "safer" - they are still affected by process compile order for the method calls.
Afaik, all tools support the old shared variables and the new by default. You need to flick a compiler switch to turn on the strictness.
As for using them in an existing methodology, you have to then hope that the tool vendors dont flick the switch, and suddenly change the behaviour of your code.
Afaik, all tools support the old shared variables and the new by default. You need to flick a compiler switch to turn on the strictness.
As for using them in an existing methodology, you have to then hope that the tool vendors dont flick the switch, and suddenly change the behaviour of your code.
You can't really deprecate a feature. There is plenty of legacy code that uses the deprecated feature that customers will always want supported.
defparam has been deprecated in SystemVerilog for a while, but no vendor dares remove support for it. So the maintenance burden never goes away.
VHDL seems to be much cleaner in this regard - I have not seen too many people use shared variables, but @trickyhead_gitlab just gave us an example...
@d3jones-metrics IIRC, older versions of Vivado would actually throw an error when code was set to 2008 and shared variables were not protected type (which is odd as protected types are not supported for synthesis) - but later versions now only throw a warning. I assume this was from compaints from customers with old code they wanted to upgrade, but need the inference of write-before-read behaviour. It doesnt help that all of their inference examples use shared variables.
IMHO, the problem is that mixing multiple revisions of the standard is undefined, yet many users rely on it. Officially, it is easy to say "just the latest revision is valid", as previous documents are (should be) explicitly marked red by IEEE. In practice, 1993 is still used because several big vendors do not provide acceptable support the language and users are not aware of the risks involved in mixing revisions. We had a discussion about it recently ghdl/ghdl#1875, since a user thought that GHDL's
frelaxed was meant for mixing revisions.
We might want to discuss about ghdl/ghdl#980 in the VASG, since that is the only public discussion related to this topic I am aware about.
The motto that VHDL is backwards compatible back to 87 is nice, but it is not true anymore. We might want to acknowledge it in the LRM.
@d3jones-metrics I think you might misunderstand what "deprecated" means. It does not mean removed. It tends to mean it remains, but is discouraged in some way. Perhaps it prints a frowny face every time you use. Or perhaps it reports to the same entity that kills kittens when you use
from module import * in Python.
Going further, shared variables of an ordinary type are special - when they were added the LRM noted they were a temporary feature and would be replaced in the next revision - and that indeed did happen.
Adding numeric_std_unsigned was also a value add to the language - since it has consistent subprograms WRT numeric_std.
What is the value of supporting shared variables of an ordinary type? For the uses I have seen, there is a better use model using either protected types or something else - see my linked in post: https://www.linkedin.com/pulse/vhdl-shared-variables-protected-types-memory-modeling-jim-lewis/
What that did was allow people who were using the old package to keep using it and at the same time get the upgraded version.
numeric_std_unsigned was only added, IMO, because people were continuing to use, and refused to migrate away from std_logic_unsigned. Again, this is basically the same reason that std_logic_textio was added to the standard
Currently in the LRM, the word share variable is often used in the context of its usage with a protected type. So to re-add shared variables of an ordinary is a non-trivial, time consuming change - that is potentially error prone. Not something I would be personally willing to take on.
I like
numeric_std_unsigned in RTL code and would require it in a design team - not to intentionally use it, however, my concern is that it is easy for someone to mistakenly use > with std_logic_vector. This can result in RTL and GATE implementation mismatches. This is a subtle bug that is hard to find - even with an experienced review team. However, if one were to include numeric_std_unsigned then > always has a consistent meaning in both RTL and GATE - and it is easy to review for - did they include the package or not. Hence, using numeric_std_unsigned makes something that is a design bug into a methodology mistake.
@trickyhead_gitlab Do you have a use model where you want to use shared variables of an ordinary type?
@umarcor There is no longer a reason for a user to use multiple versions of the language. The reason VHDL-93 was used is that historically was the subset of the language used for RTL. Hence, it was a lint tool that made sure you did not introduce something the synthesis tool could not handle. However, you should be able to compile 93 RTL code in 2008 and have it work the same way.
A simulator that only supports one version would work fine. Even with the lint check. First compile the RTL for 93 as a lint check. Then compile it for 2008 and simulate it with other 2008 code.
@bpadalino And from UVVM using shared variables of an ordinary type, suppressing the error messages, and telling their community that this is a proper thing to do. Then claiming that implementing verification component interfaces is hard to do in any other way - when there are methodologies such as VUnit and OSVVM (as well as other private methodologies) that do not use shared variables of an ordinary type. We will see. They have a new release coming up in October - maybe they fixed it.
@JimLewis, how to simulate an IP core using shared variables of an ordinary type with a verification framework using VHDL 2008 (or 2019) features?
That's the most common use case we find in GHDL (using VUnit, OSVVM...).
That's the most common use case we find in GHDL (using VUnit, OSVVM...).
- It's not possible to compile the framework using 93.
- It's not possible to compile the IP using strict 2008.
Therefore: - Linting or synthesis using strict 93 is possible.
- For simulation, non-strict 2008 is required, where non-strict means "analyse some constructs as if it was not 2008 but an earlier revision".
A simulator with strict 2008 support cannot handle that use case; it forces the IP to be updated.
@umarcor Asking is always ok. However, speaking for myself as an individual, I would neither vote in favor of such a proposal nor work on it. There are more high value items to work on then supporting things that should have never been done. I would argue that none of the code that uses these constructs was written before VHDL-2000 when it became illegal. Simulators have always at a minimum warned that such an item was illegal. Perhaps using the word
warning was a little to subtle for people - maybe they should have used suppressed warning
@umarcor You keep saying strict 2008. Lets make a small correction. It was 1076-2000/2002 that made shared variables of a ordinary type illegal. So anything that is strict 2000, does not allow it. It was the prior version (1076-1993) where they were added and it was noted that they were added as a temporary feature.