Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 05 13:29

    umarcor on top-subtype

    (compare)

  • Oct 05 13:28

    umarcor on master

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

  • Sep 24 20:07

    umarcor on top-subtype

    2008: ad tb_top_generic_subtype (compare)

  • Sep 24 19:59

    umarcor on top-subtype

    2008: ad tb_top_generic_subtype (compare)

  • Sep 24 19:54

    umarcor on top-subtype

    2008: ad tb_top_generic_subtype (compare)

  • Sep 23 01:45

    umarcor on style

    (compare)

  • Sep 23 01:44

    umarcor on run_08

    (compare)

  • Sep 21 23:02

    umarcor on merge-support

    (compare)

  • Sep 21 22:59

    umarcor on master

    merge run_support.py into run.py (compare)

  • Sep 21 22:51

    umarcor on merge-support

    merge run_support.py into run.py (compare)

  • Sep 21 22:34

    umarcor on master

    style deprecate Travis (compare)

  • Sep 21 22:10

    umarcor on style

    test (compare)

  • Sep 21 21:51

    umarcor on style

    deprecate Travis TMP -k (compare)

  • Sep 21 21:47

    umarcor on style

    style deprecate Travis TMP -k (compare)

  • Sep 21 21:32

    umarcor on style

    pathlib support (compare)

  • Sep 21 21:18

    umarcor on runner-string

    (compare)

  • Sep 21 21:18

    umarcor on style

    pathlib (compare)

  • Sep 21 21:12

    umarcor on style

    style (compare)

  • Sep 21 19:48

    umarcor on master

    vhdl_2008: style use type 'string' for top-level… (compare)

  • Sep 21 19:34

    umarcor on runner-string

    use type 'string' for top-level… (compare)

Jim Lewis
@JimLewis
@trickyhead_gitlab Yes and no. No because 1999 documented the current state of what synthesis tools did support. Hence, if a model were compliant, then it would work. OTOH, 2004 is irrelevant as it tried to push vendors in a direction and they did not do it. Sad state synthesis tools are in as a result - attributes that are annoyingly similar, yet different - making you think you are correct when you are not.
Patrick Lehmann
@Paebbels

Doesnt it also require a vendor to sign up to compliance to those standards?

For VHDL, there is no compliance enforced as for e.g. USB. So vendors can call their tools to support VHDL with whatever they implement. If we had a compliance rule, all tools would now support VHDL-2019 !

d3jones
@d3jones
I haven't seen any VHDL87 IP, but that doesn't mean it doesn't exist.
So far here are the semantic incompatibilities between versions that I am aware of, all from 87 to 93:
  • Character set
  • Array bounds for shift and concatenation operators
    By "semantic incompatibility" I mean "places where, even if you analyze using the correct language, you will be unable to elaborate without risking surprising behavior".
    The addition of e.g. std.env package is not a semantic incompatibility: it is not visible when analyzing in 93 mode, but is visible when analyzing in 2008 mode, so code in each language will not be surprised by any behavior.
The width of integer was also standardized to 64 bits later on. However, integer being exactly 32 bits was never guaranteed, so legacy 1993 code observing integer being not a 32-bit type should not be surprising.
tgingold
@tgingold
The real problems are more with std_logic_1164!
d3jones
@d3jones
Are there differences there? I took a look but didn't see any. I did see that std_logic_1164, numeric_std and std.standard are inconsistent with bounds of vector results:
  • std.standard operators return bounds of left operand.
  • std_logic_1164 operators return (1 to N)
  • numeric_std operators return (N-1 downto 0)
    Did I miss anything?
tgingold
@tgingold
In vhdl-2008, std_ulogic_vector and std_logic_vector are the same type.
Richard Head
@trickyhead_gitlab
@d3jones while they may differ between packages, they don't differ between language version afaik.
Lars Asplund
@LarsAsplund
@Paebbels Cloned pyVHDLParser to have my first look. It doesn't seem to find LibraryReference in VHDLModel. What am I missing?
Patrick Lehmann
@Paebbels
@LarsAsplund the dependencies in pyVHDLParser are not locked (it's ≥ some version).
Due to the heavy work on pyGHDL.dom, the pyVHDLModel has advanced a lot:
  • lot's of new features compared to the version used by pyVHDLParser
  • due to misconceptions in the initial phase of pyVHDLModel, some class/property names needed changes for clarification.
If you want access to pyVHDLModel, the best way is currently using pyGHDL with libghdl as a backend, because the underlaying GHDL parser routines are way more complete.
I need to finish circa 10 more bugs in pyGHDL.dom (then I would consider this work a major breakthrough) and go back to pyVHDLParser for needed adaptions.
Are you interested more in the VHDLModel or the Python only approach of pyVHDLParser (note: the algorithms are quite complex)
Lars Asplund
@LarsAsplund
@Paebbels I'm more interested in trying out the parser. For example, using the parser in a VUnit preprocessor to transform VHDL-202x features, not supported in any simulator, into VHDL-2008 equivalents such that we can be more hands on with features being suggested.
Patrick Lehmann
@Paebbels
Is this legal VHDL?
  1. constant b : bit_vector(0 to 0) := a(integer range 0 to 0);
  2. constant c: integer_vector(2+3);
@LarsAsplund maybe we should have a Zoom meeting and discus the current state of the project and how it can help you with your goals.
Lars Asplund
@LarsAsplund
@Paebbels I'm not in a great hurry so maybe I should just await those fixes. I'm on the road this week (partly with poor network connection). Let's get in touch next week to see what the status is then.
Patrick Lehmann
@Paebbels
@LarsAsplund sounds good to me.
Unai Martinez-Corral
@umarcor
@LarsAsplund, @Paebbels please count me in for the meeting.
Lars Asplund
@LarsAsplund
@umarcor Counting
Jim Lewis
@JimLewis
1076 Meeting today. @Paebbels are you going to make that?
Patrick Lehmann
@Paebbels
Yes :)
nobodywasishere
@nobodywasishere:eowyn.net
[m]
Are non-members allowed at the meeting?
nobodywasishere
@nobodywasishere:eowyn.net
[m]
I see it starts in a few minutes, so I may be too late. That's okay
Unai Martinez-Corral
@umarcor
@nobodywasishere:eowyn.net the link to the meetings is typically not public before the meeting. Sometimes it's sent to the mailing list. Typically, we use a private link which all the members of the workgroup have access to.
However, that is mostly meant to avoid spam and (ro)bots. Being a member of the workgroup is free, and we want both experienced users and newcomers to participate. VHDL is a pilot project for applying Open Source development practices in IEEE projects. We are pushing in that direction as hard as we can.
All you need is be willing to help with the language somehow: providing use cases, asking for capabilities, replying to other members' suggestions, converting the LRM to LaTeX, reviewing the conversion, helping keep the website updated...
So, what is your interest? What do you want to get from the workgroup and what do you want to provide? Let me know and I will point you to the adequate references so that you don't miss the next meetings (it's once every two weeks on average, next scheduled on July 15th at 11AM PST, 20:00 CET).
Kaleb Barrett
@ktbarrett

I felt this rant was slightly off-topic so I'm posting it here instead.
Responding to https://gitlab.com/IEEE-P1076/VHDL-Issues/-/issues/69#note_617375903

VHDL does have something that resembles a class, protected types.

If you want my opinion, I don't really like the implementation of protected types. I don't think there was a good reason to add another incompatible set of call semantics just to achieve data encapsulation. Protected types could have simply been regular old types (and any type, not just record types) that with the keyword protected made the existing interfaces package-private. Functions ("methods") on those types could be defined in the package that could access the implementation's interface, and users would only have access to those "public" functions. However, users could extend the interface by providing overloads for those protected types in other scopes, like they could for regular types. Class-based OO and method dispatching is old-school, has an inherent expression problem, and doesn't really jive with the Ada-derived type system that VHDL has.

VUnit does have two variants of some APIs, implemented both as you commented (for <2008) and using protected types (for >=2008).

I think this proves my point about the multiple types of call semantics. Imagine instead having something akin to an ifdef "turn on" encapsulation by conditionally adding the protected keyword if the language version is >= 2008.

nobodywasishere
@nobodywasishere:eowyn.net
[m]
@umarcor: Thank you for the information! There are quite a few things I think I could do. Currently so far the main things I've done for VHDL as a language are VHDLref and
VHDLproc, which I'm still working on.
Unai Martinez-Corral
@umarcor
@nobodywasishere:eowyn.net, please let me know your e-mail, desired first and last name, and your GitLab username. You can open a private conversation with me here, or you can find my e-mail in any of my commits. Then, I will use that data for adding you to the e-mail reflector, to the TWIKI and to the GitLab organisation.
nobodywasishere
@nobodywasishere:eowyn.net
[m]
@umarcor: thank you!
Unai Martinez-Corral
@umarcor
The organisation is actually https://gitlab.com/IEEE-P1076. You should be able to see several repositories already, since those are public, and you can already participate in https://gitlab.com/IEEE-P1076/VHDL-Issues/-/issues (which is probably the most interesting resource for you at the moment).
Find the entrypoint to all the resources in https://ieee-p1076.gitlab.io/
Patrick Lehmann
@Paebbels

Repost from @LarsAsplund

Let's see if we can have a LinkedIn survey with any statistical significance https://www.linkedin.com/posts/plc2-gmbh_vhdl-osvvm-fpga-ugcPost-6817744189200076800-OUeX

ktbarrett
@ktbarrett:matrix.org
[m]
Hmmm, I dont see SV/UVM listed. I have a feeling "others" might get pretty large. Is that the point?
Lars Asplund
@LarsAsplund
@ktbarrett:matrix.org Actually it would be expected that anything in others is under represented. If you option isn't there people tend not to bother. Surveys tend to be very biased for all kinds of reasons. For example, this was shared in the VUnit chat and in the OSVVM chat but I don't think there is such a UVVM chat so that would make it under represented. The post is done in connection to the FPGA conference where OSVVM and UVVM is presented. That would favour them. The post has OSVVM hashtagged which means a wider spread in that community. The list goes on forever. These are the kinds of objections I've had against the ever quoted Wilson study and the reason why I got interested in mining GitHub to avoid at least some biases. Nevertheless, I'm a bit interested in statistics and thought it would be an interesting experiment to see where this goes if we managed to get a number of votes that would give some level of statistical significance.
Patrick Lehmann
@Paebbels
LinkedIn allows only 4 answers :(
Colin Marquardt
@cmarqu
Oh, that's a very... limiting limitation.
Richard Head
@trickyhead_gitlab

Question re: VHDL 2019. With the following generic specification:

generic (
  type designated_subtype; -- any type
  type access_type is access designated_subtype -- an access type
 );

Would it be required that both types here be mapped to existing types, or can the access type here be left "open" as it is a fully defined type once designated_subtype is assigned? for example, this is effectively the example given in 6.5.3.3

generic map (
 designated_subtype => string,
 access_type => line
 );

Would it also be legal to do the following:

generic map (
 designated_subtype => string
 );

Now access_type is a fully defined type that exists only within the same region as the generic. It is NOT type lineas this was not mapped.

I cannot find anything in 6.5.7.2 that appears to require the type be assigned an actual type.

Jim Lewis
@JimLewis

@trickyhead_gitlab I think maybe the other way around may be allowed. From type line, you can find its designated_subtype using attributes.

However, without mapping type line, access_type would then have to be a unique type and if you wanted anything in the package to have a parameter or return value that is type access_type, then its type will not be known outside the package.

BTW have you found a tool that has implemented this yet? Hopefully in October.
Richard Head
@trickyhead_gitlab
@JimLewis No - I provided a test case to Aldec as I requested the feature.
An idea I have likely matches exactly what you said - if the user provides the access type, they can return a value in a known type. If they do not care about the access type, it remains a unique type, used internally only
I requested generic array types and generic access types. I actually want a generic access type of a generic array type (with the base type discoverable via 'element)
In most of my imagined use cases, the access type is not required externally, but its nice to have for completness
GlenNicholls
@GlenNicholls
Richard Head
@trickyhead_gitlab

@JimLewis Actually, LRM says this:

It is an error if no such actual is specified for a given formal generic type (either because the formal generic is unassociated or because the actual is open).

So I guess they cannot be left unconnected (and maybe its worth filing a ticket)

Patrick Lehmann
@Paebbels
@trickyhead_gitlab the problem with VHDL is types are equal if the name of a type is equal.

When you define this:

type line1 is access string;
type line2 is access string;

you get 2 incompatible types.

Thus you need to handover the access type to the protected type, entity or package as a generic type, so you can use it internally as access type or extract from it it's designated type.