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)

Richard Head
@trickyhead_gitlab
But its that NOTE thats wrong
I just raise an issue on Issues, but might have missunderstood
Patrick Lehmann
@Paebbels
from a technically side, I see no reason why this is there. Moreover, the note it not normative it must be somewhere in the text too.
Richard Head
@trickyhead_gitlab
Heres another Question - does the LRM require that code compiled to different LRM standards work together (barring explicit non-backwards compatible elements - '87 files, '93 shared variables etc). For example, should a package compiled in 2002 or 2008 be fully compatible with a file compiled in 2019? Or is that a tool question? Is it a case that the only guaranteee is that if all files are compiled to the same LRM standard?
d3jones
@d3jones
I have the same question. There is at least one place where 87 is not compatible with 93:
  • In 87, character is defined over USASCII, so character'pos(character'right) is 127.
  • In 93: character is defined over ISO8859-1 so character'pos(character'right) is 255.
    If we separately compile two architectures, one in 87 and one in 93 and elaborate them into a single design, what is expected?
d3jones
@d3jones
(It also means that 87 users cannot read raw binary files by treating them as file of character.)
Richard Head
@trickyhead_gitlab
@d3jones Reading a file of char is a hack that vendors allow to work. IIRC, Xilinx simulator used to put some arbitrary header on any file that wasnt a text file. Im not sure theres any guarantees that writing a file of arbitrary type in one tool can be read in another tool.
d3jones
@d3jones
True, it 's a hack. It is unfortunate that neither Verilog nor VHDL provides a way to read binary files.
Patrick Lehmann
@Paebbels
From IEEE perspective there is only one Standard and that's the currently active standard.
In GHDL, you can't mix different versions.
Aldec, Siemens and Xilinx support mixing language versions.
Some even allow forbidden syntax and features in newer language revisions ...)
1 reply
Richard Head
@trickyhead_gitlab
So any failure or erroneous error is a tool problem and not something that needs to be questioned of the LRM
Patrick Lehmann
@Paebbels
The LRM doesn't consider compatibility issues between versions.
Jim Lewis
@JimLewis
@d3jones I would say for all things that are manipulating characters, there is no reason not to be using VHDL-2008. WRT VHDL-87 to VHDL-93, shouldn't they read the same if the characters represent a position number less than 128? If they require reading of a character > 128, VHDL-87 would neither be able to write it nor read it, so a later version is their only option.
@d3jones The 1076 WG would welcome your proposal for reading and writing binary files the correct way. We use gitlab issues for proposals. See: https://gitlab.com/IEEE-P1076/VHDL-Issues/-/issues
d3jones
@d3jones
Commercial users often have design/verification IP from multiple vendors. If the IP is encrypted then customer cannot modify it. I may not actually have a choice as to which language version(s) I need to use.
Jim Lewis
@JimLewis
@d3jones There was a standard 1076.6-1999 and 1076.6-2004 for RTL coding styles. 1999 was written for IP developers. If you are compliant to the standard, then your model will synthesize on all tools ( Since the standard was written to be what tools currently supported). I think VHDL-93 is one of those expectations for Synthesis. So I would say that any design/verification IP that is not at least VHDL-93 is not worth using.
I think the big backward compatibility issue with VHDL-87 to 93 is textio - not just character but also how file identifiers were created.
@d3jones Have you seen any vendors distributing IP that is only supported by VHDL-87?
Richard Head
@trickyhead_gitlab
@JimLewis Were 1076.6-1999 and 1076.6-2004 ever adopted? I thought they were withdrawn? Doesnt it also require a vendor to sign up to compliance to those standards?
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).