Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Feb 03 02:13

    umarcor on keep-compiling

    ci: use the built-in '--keep-co… (compare)

  • Feb 03 02:12

    umarcor on cosim

    cosim/dpi-ffi: add 'vhdpi_ghdl.… cosim/dpi-ffi: add VHDPI_Test (compare)

  • Feb 03 01:56

    umarcor on cosim

    WIP setenv (compare)

  • Feb 03 01:55

    umarcor on main

    cosim/dpi-ffi/ghdl-vffi/test: a… (compare)

  • Feb 03 01:54

    umarcor on cosim

    (compare)

  • Feb 03 01:52

    umarcor on main

    WIP envvars (compare)

  • Feb 03 01:50

    umarcor on cosim

    WIP envvars (compare)

  • Feb 02 23:13

    umarcor on master

    (compare)

  • Feb 02 23:13

    umarcor on main

    (compare)

  • Feb 02 23:13

    umarcor on cosim

    (compare)

  • Feb 02 23:10

    umarcor on master

    cosim/dpi-ffi: create subdir 'g… cosim/dpi-ffi: fix compilation … cosim/dpi-ffi/ghd-vffi: use VUn… and 2 more (compare)

  • Feb 02 22:58

    umarcor on cosim

    ci: add workflow CoSim cosim/dpi-ffi: add README (compare)

  • Feb 02 22:45

    umarcor on cosim

    ci: add workflow CoSim cosim/dpi-ffi: add README (compare)

  • Feb 02 22:43

    umarcor on cosim

    cosim/dpi-ffi: create subdir 'g… cosim/dpi-ffi: fix compilation … cosim/dpi-ffi/ghd-vffi: use VUn… and 2 more (compare)

  • Oct 05 2021 13:29

    umarcor on top-subtype

    (compare)

  • Oct 05 2021 13:28

    umarcor on master

    2008: ad tb_top_generic_subtype cosim: add ref to aguinet/drago… (compare)

  • Sep 24 2021 20:07

    umarcor on top-subtype

    2008: ad tb_top_generic_subtype (compare)

  • Sep 24 2021 19:59

    umarcor on top-subtype

    2008: ad tb_top_generic_subtype (compare)

  • Sep 24 2021 19:54

    umarcor on top-subtype

    2008: ad tb_top_generic_subtype (compare)

  • Sep 23 2021 01:45

    umarcor on style

    (compare)

std-max
@std-max
oh that makes sense now, thank you
Richard Head
@trickyhead_gitlab
The above should be supported in ActiveHDL 13.0
std-max
@std-max
I dont have it unfortunately. don't you have any tips to convert a string to a generic enumeration value ?
Richard Head
@trickyhead_gitlab
unfortunately not. But Im wondering why you you need the procedure at all, what is wrong with simply: v := value_t'value("V1");
Patrick Lehmann
@Paebbels
I wonder if v := v'subtype'value("V1") could work as every object has a 'subtype, right?
Jim Lewis
@JimLewis
@Paebbels Same problem - don't know the type is scalar
dalex78
@dalex78
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
Richard Head
@trickyhead_gitlab
@dalex78 answered
dalex78
@dalex78
Thank you, very clear answer
Jim Lewis
@JimLewis
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/
d3jones-metrics
@d3jones-metrics
Which features have been deprecated to date?
Jim Lewis
@JimLewis
In 1993, shared variables were added that used ordinary types. In 2000/2002 they were deprecated and removed. They were replaced by today's shared variables of a protected type.
Lars Asplund
@LarsAsplund
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?
Richard Head
@trickyhead_gitlab
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.
d3jones-metrics
@d3jones-metrics
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...
Richard Head
@trickyhead_gitlab
@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.
Unai Martinez-Corral
@umarcor
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.
Kaleb Barrett
@ktbarrett
@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.
Jim Lewis
@JimLewis
WRT IEEE, there is one revision, the current balloted revision - VHDL-2019.
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.
Richard Head
@trickyhead_gitlab
maybe we could just propose shared variables can be any type? In the same way 2008 gave in to std_logic_unsigned and added numeric_std_unsigned and also rolled std_logic_textio into the standard?
Unai Martinez-Corral
@umarcor

WRT IEEE, there is one revision, the current balloted revision - VHDL-2019.

@JimLewis that is ignored by the majority of the industry, and neither IEEE nor VASG can do anything to fix that in the short or mid term. We might acknowledge it, at least.

Jim Lewis
@JimLewis
Adding textio support for std_logic_vector, unsigned, signed, ufixed, sfixed, and float were a value add to the language.
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/
Richard Head
@trickyhead_gitlab
std_logic_textio is nothing more than an empty package in 2008 and purely there for backward compatibility with code that used it in previous standardards. The actual textioIO was added to the packages that defined the types
Jim Lewis
@JimLewis
Yes. And?
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.
Richard Head
@trickyhead_gitlab
Im trying to ask - why was this put in to maintain backwards compatability with non-standard code, yet doing the same with non protected type shared variables is an issue?
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
Jim Lewis
@JimLewis
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.
Jim Lewis
@JimLewis
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?
Brian Padalino
@bpadalino
this all stemmed from vivado inferring dual port bram and using a shared variable to do it?
Jim Lewis
@JimLewis

@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.
Brian Padalino
@bpadalino
i see .. i haven't seen/used UVVM .. interesting they make such extensive use of it
Unai Martinez-Corral
@umarcor
@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...).
  • 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.
Jim Lewis
@JimLewis
@umarcor strict2008 sounds appropriate.
Unai Martinez-Corral
@umarcor
@JimLewis, then maybe it is legit to ask shared variables of ordinary type to be introduced in the LRM again, since they need to be supported anyway by any strict2008 simulator.
Jim Lewis
@JimLewis
@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.
Jim Lewis
@JimLewis

@umarcor

how to simulate an IP core using shared variables of an ordinary type with a verification framework using VHDL 2008 (or 2019) features?

What is the use model for this? If they want to use strict2008, then they should fix their code, right?
Lars Asplund
@LarsAsplund
@ktbarrett With "deprecate" I actually meant "remove" but there could also be an intermediate step where a warning is issued. I've used that myself for VUnit. What I'm challenging is the idea that because someone might be using an old feature it has to maintained. Dependency on old features make progress harder and in worst case it prevents progress. I also think we need to recognize that companies not willing to take the cost of updating their code base when adopting a new standard translate to additional unpaid time for the maintainers of VHDL. If you really can't change your code you can always stick with the old standard or keep that code separate from the rest.
Unai Martinez-Corral
@umarcor

What is the use model for this? If they want to use strict2008, then they should fix their code, right?

@JimLewis, unless the code was bought from a third-party and there is no budget for having it updated/fixed.

I keep saying "strict 2008" because I believe that the usage of shared variables of an ordinary type should be an error, not a warning. In order to allow it, the strictness needs to be relaxed. Some might argue that it is not an error in 2008 and 2019. That might be correct. However, as Lars is suggesting, at some point a deprecated and "illegal" feature should be removed. If deprecated features are not removed, the LRM needs to account for backwards compatibility exceptions.