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)

Jim Lewis
@JimLewis
@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.

Kaleb Barrett
@ktbarrett
@LarsAsplund I think most SW projects today give people a grace period where deprecation warnings are given before the feature is removed. Of course, the release cycle on those projects is far more frequent than VHDL language releases. In this case it doesn't seem to be breaking anything by leaving it in and deprecating it? Bad ideas can always cause warnings. Unless it totally broken and impeding progress, removal isn't strictly necessary. Non-essential removals should come after the community has reacted to deprecation status or after some amount of time that is agreed upon beforehand. For example, when Python does deprecations-pending-removals, they tell users exactly what release the feature will be removed in and what to use instead. If you don't compensate in time, it's your fault. Maybe if VHDL had a shorter development cycle (3 years like C++?), language could be added about how tools should handle deprecations and could state features are deprecated for 1 language revision and removed in the next, which gives users a pre-determined amount of time to react.
Jim Lewis
@JimLewis
@umarcor They were REMOVED! in VHDL-2000. They were added in VHDL-1993, so they are only legal for that version and no other.

Adding them in not a simple matter of moving them from the deprecated list to the supported list. It will take going though the current revision, clarifying every usage of shared variable in the LRM to indicate it refers to a shared variable of a protected type. Then going back to the VHDL-1993 revision and reviewing the text for shared variables and all the restrictions of their usage by VHDL-1993 and restoring that to the LRM with edits to clarify that they are for shared variables of an ordinary type.

Without compelling use models, I don't see the point.

Jim Lewis
@JimLewis

@Kaleb - When VHDL added shared variables of an ordinary type, it was noted that they were a temporary feature and would be replaced in the next revision.

At this point, it is 21 years after the feature was removed. :)

Unai Martinez-Corral
@umarcor

@JimLewis, I'm not arguing that they were or were not removed. I'm showing a counterexample of:

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.

A simulator which supports VHDL 2008 and only VHDL 2008 cannot handle RTL 00. RTL 00 cannot be "compiled for 2008", but it needs to be some 2008-compat mode.

Because it is not possible for a VHDL simulator to support the latest revision and only the latest revision, we should have an specific explanation/section in the LRM for that.

Alternatively, if we expect the simulator to handle RTL 00 specific constructs as a warning when using 2008, then we are explicitly requiring any simulator to support all previous revisions (not only one).
Jim Lewis
@JimLewis
What is RTL 00? I know of 1076.6-1999 and 1076.6-2004 (worked on both).
Unai Martinez-Corral
@umarcor
RTL is "VHDL code written in 2000, when using shared variables of ordinary type was legal".
Jim Lewis
@JimLewis
You should use RTL 93. Shared variables were deprecated and removed by VHDL-2000
There are other correct ways to create memories without using shared variables as illuminated in my paper.
Unai Martinez-Corral
@umarcor
It's irrelevant, in the sense that this is a discussion from a logic (philosophical) perspective. Specific versions and features are just an example to illustrate the conflict.
Jim Lewis
@JimLewis
It is relevant. You are propagating a myth that shared variables were supported for more than 7 years.
Unai Martinez-Corral
@umarcor
Not at all. I'm propagating that shared variables were officially supported at some time. Even if it was one month.
I came when they were deprecated already and I have always avoided their usage, so I have no need for them at all.
However, I am claiming that VHDL is not completely backwards compatible and older sources cannot be analysed using a modern revision of the language. That holds almost correct, but not completely true.
Jim Lewis
@JimLewis
On the same note, Xilinx promoted std_logic_arith - it may still be in their documentation. Should we be considering that for standardization too? It is already in the IEEE library.
How do we get FPGA vendors more vested in the standards process?
Unai Martinez-Corral
@umarcor
I don't think so. I think that neither of the features we are discussing about should be introduced in the standard. Conversely, I believe it is time to strongly deprecate (aka remove) them. Strong deprecation means making it explicitly that backwards compatibility is not an strict feature of the VHDL language any more.

How do we get FPGA vendors more vested in the standards process?

I want users involved in the funding of GHDL and VASG. Vendors will come/join if they want. Vendor involvement (or the lack of) is what drove us to the current state.

Jim Lewis
@JimLewis
Why do you say strongly deprecate (aka remove). Shared variables were deprecated and removed in VHDL-2000.
So perhaps I have overstated VHDL's backward compatibility. Shared variables and file IO are not backward compatible.
Brian Padalino
@bpadalino
from a synthesis/inferring standpoint, what should xilinx do for a dual port bram with dual clocks since it shouldn't use a shared variable on an ordinary type ?
d3jones-metrics
@d3jones-metrics
What's not backward compatible with file I/O? (Yes, the syntax changed slightly from 87 to 93, and more options were added in 08)
Lars Asplund
@LarsAsplund
@ktbarrett I wasn't thinking about shared variables of unprotected type but more generally that removing stuff should be a topic on our agenda. Python can serve as an example of a language that remove stuff regularly. They surely move faster than HDL standards but note that it's easier to move fast if you travel lightly. I would love to see a standardization process that could be quicker. A lot is happening in our industry with the open source movement and that happens fast. I think VHDL would be in a better position if we could somehow match that pace. Let's try to find another thing that we could consider for removal. Shared variables is a very infected topic. What about buffer? Can we live without it?
Jim Lewis
@JimLewis
@d3jones-metrics the syntax change you mentioned
@LarsAsplund We have been working on changing the LRM to LaTex for how long now?
Jim Lewis
@JimLewis
On @LarsAsplund note, to get the standard moving faster we need to,
1) Review: https://gitlab.com/IEEE-P1076/VHDL-Issues/-/issues
2) Vote up issues you are interested in.
3) Vote down issues you think we should not do
4) Assist with the conversion of the LRM to LaTeX.
If we had 3 to 5 more helpers on LaTex, that effort would complete faster.
If we had 3 to 5 more people reviewing, commenting, and voting on issues that would help build momentum and draw others to do the same.
IEEE PARs (Project Authorization Requests) only last 4 years now. When we have enough activity, I will request a PAR. After 2019, I feel reluctant as the work stalled in the editing process and I was left to answer weekly questions from DASC and IEEE because PAR had expired and we had to get two extensions (both with the threat of this is the last extension).
Brian Padalino
@bpadalino
@JimLewis thanks
Kaleb Barrett
@ktbarrett
@LarsAsplund I have never seen buffer used in the couple MLoC I've seen, and synthesizers have recommended against it in the past. It's easy enough to replace by refactoring anything that require state into entities with local state. It's probably safe to remove.
d3jones-metrics
@d3jones-metrics
Is there any reason for linkage ports?
I've seen more buffer than linkage.
Patrick Lehmann
@Paebbels
linkage is used by JTAG boundary scan if I'm right
Lars Asplund
@LarsAsplund

@JimLewis Don't get me wrong. I know that there is a small group that does most of the work continuously year after year. You're putting in an amazing amount of work and should have credit for that. Then there are others, like myself, that comes around a few times during a release cycle, typically focusing on only one thing at any time and maybe throwing in a few comments and thumbs on other issues but not following them to the end. I can only speak for myself but in general and especially in a situation like this I find it easier to focus on tiny and relatively simple improvements where I can engage, prepare the change, get the thumbs up, have the change merged and then pull back. My work-in-progress limit is rather low and when I hit that limit I actively avoid getting engage in any more. I'm a bit hesitant to comment on the situation since I'm not the one doing the hours and not involved enough to see the project from the inside. I will still share an outsider observation, hopefully not stepping on too many toes. There are over many open issues and all closed issued seems to be rejected issues or duplicates. I found at least some where there seem to be some sort of consensus and many thumbs up. What prevents those issues from being closed and merged? Is it the ongoing LaTex work? Some formal IEEE process? To few thumbs?

When I said moving faster I was really meaning continuously moving. If there is a continuous, possibly slow, flow of merged items we're always in a position to do an improved release of the standard. I'm not saying IEEE is ready for that though.

@Paebbels @ktbarrett @d3jones-metrics In the not to distant past everyone was using buffer so I'm sure there is a lot of code hanging around but as you said it should be simple to change. I never seen linkage in the wild. I know that I tried it way back but computer said no. Never implemented JTAG though.