Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 17:54
    umarcor labeled #1923
  • 17:54
    umarcor labeled #1923
  • 17:54
    umarcor labeled #1923
  • 17:54
    umarcor labeled #1923
  • 17:53
    umarcor commented #1923
  • 17:52
    umarcor commented #1923
  • 17:45
    tgingold commented #1923
  • 12:35
    NicoPy commented #1923
  • 10:50
    NicoPy commented #1923
  • 09:17
    emard commented #1926
  • Nov 29 21:41

    github-actions[bot] on nightly

    synth/elab-vhdl_expr: handle sl… testsuite/synth: add a test for… (compare)

  • Nov 29 20:23
    emard commented #1926
  • Nov 29 20:18
    umarcor commented #1926
  • Nov 29 20:17
    emard commented #1926
  • Nov 29 20:16
    umarcor milestoned #1926
  • Nov 29 20:15
    tgingold commented #1922
  • Nov 29 20:14
    tgingold commented #1926
  • Nov 29 20:13
    tgingold closed #1926
  • Nov 29 20:13

    tgingold on master

    synth/elab-vhdl_expr: handle sl… testsuite/synth: add a test for… (compare)

  • Nov 29 20:10

    github-actions[bot] on nightly

    elab-vhdl_insts.adb: do not try… elab-vhdl_objtypes.adb: add an … synth memories: also accept con… and 1 more (compare)

Unai Martinez-Corral
@umarcor
@tgingold, in the last meeting I was discussing with @marlonjames about the requirement of function bodies to exist at elaboration time. There are two constraints:
  • If a subprogram has a foreign attribute, the foreign body must exist. This was discussed in ghdl/ghdl#793 and we all agree that's something the tools might require.
  • A subprogram needs to have a VHDL body, even if a foreign attribute is declared. This is something we all agree not to make sense, and which might be an oversight. However, we could not find where in the LRM is that specified, nor did I find any issue in the ghdl repo where we discussed it explicitly. I know we have discussed it either there or in this chat, tho. Can you or anyone provide a hint?
tgingold
@tgingold
I don't think it was discussed in an issue, so probably in a forum.
According to the LRM, every subprogram must have a body. Foreign or not.
Unai Martinez-Corral
@umarcor
Thanks, so maybe it was in a private conversation and the search is not working there :laughing:
Kaleb Barrett
@ktbarrett

all those software tools for verification are already written in VHDL and customised for the standard interfaces. We should not reimplement that in Python nor do bit-banging through indirect cosimulation interfaces.

Well, this is kind of the entire point of cocotb. Write testbenches in Python instead of VHDL or (System)Verilog. I could see implementing drivers/monitors in VHDL or SystemVerilog and controlling them from a cocotb test as a (very) useful optimization and to cover cases where the VPI isn't sufficient (tri-state drivers), but that would require a lot of tooling because I would like something like that to be automated. One of the things people like about cocotb is not having to write any VHDL/(System)Verilog for the testbench, or even write a top at all. And I don't see how that precludes implementing the same functionality in cocotb to handle the cases where moving the implementation to HDL is not possible or just too time consuming to be useful.

You might be interested in pybfms which is similar to this. IIRC it uses VPI system tasks to enable communication between cocotb and Verilog BFMs.

I'm not familiar enough with cocotb+verilator or cocotb+iverilog yet

That reminds me of one more task to reach maturity: Mature the GHDL and Verilator VPI/VHPI interfaces so cocotb will work with them.

Unai Martinez-Corral
@umarcor

but that would require a lot of tooling because I would like something like that to be automated.

A verification component is a black-box with a software API on one side and a hardware interface on the other. Adding an VC between the HDL interface and the software procedure is the most automated and transparent solution for the users. They should not write any code in any case, just their application specific software procedure. The question is whether VCs need to be written in HDL only, in Python only, or half HDL half Python. I believe it needs to be the last one. We can request developers to know both languages, even though users won't. Currently, developers need to know VPI/VHPI although users do not.

I agree it would require tooling, but not more than it required to automate the usage of HDL only VCs or Python only VCs. That is a library management issue we have in the EDA industry, not specific in this case.

You might be interested in pybfms which is similar to this. IIRC it uses VPI system tasks to enable communication between cocotb and Verilog BFMs.

Yeah, that's kind of the idea. Anyway, we first need to solve how to call VHDL subprograms from a foreign language, which is not defined yet. That's part of the VHDPI discussion, but it might not get into the first revision.

In ghdl-cosim there is an example of the opposite: using a VHDL protected type with foreign attributes for exposing a C API in VHDL. The idea is the same: get a handle of the class/object from the other language and call the methods as the software API of the "standard interface".

Mature the GHDL and Verilator VPI/VHPI interfaces so cocotb will work with them.

This is my priority with GHDL. I need to get to implement some changes myself so I can actually start fixing things and not just annoying Tristan with bug reports and requests.

Patrick Lehmann
@Paebbels

In the last days, I did a lot of enhancements for pyVHDLModel which is used by pyVHDLParser and also GHDL. The VHDL language model is the basis for the dom namespace in pyGHDL.

I think until end of the week I can finalize a first pretty-printing demonstrator, which parses a VHDL file with GHDL's libghdl, uses GHDL's Python bindings and transforms GHDL's internal data structure (IIR) to a Python-based document object model (DOM) that represents a VHDL file with instances of classes and references (points) among them.

The pretty-printer example emits the translated object model to text. From there it should be easy to provide other output formats like JSON or YAML (if needed).
Of cause, users can use the object model in there own libraries or tools based on GHDL's Python API.

Even if my own project pyVHDLParser is not as advanced and working like GHDL, it's till planned to have a second source besides parsing via libghdl to create a object model using pyVHDLModel as a common interface.

What is it good for?
We can now think about generating documentation - especially in Python based tools like Sphinx - from VHDL code parsed by libghdl. What I can do so far is:

  • list entities, architectures, packages, package bodies, contexts and configurations
  • list generics (constants) for entities
  • list ports (signals) for entities
  • list declared items in architectures (packages will follow soon)
    • constants
    • signals
    • types
    • subtypes
    • functions (procedures will follow soon)
  • list constraints in e.g. port/generic declarations
  • parse expressions in e.g. range expressions like std_logic_vector(BITS - 1 downto 0)

Example output (pretty printed DOM):

Document 'testsuite\pyunit\SimpleEntity.vhdl':
  Entities:
  - entity1
    Generics:
      - bits : in positive
    Ports:
      - clock : in std_logic
      - reset : in std_logic
      - q : out std_logic_vector(bits - 1 downto 0)
  Architectures:
  - behav
  Packages:
  PackageBodies:
  Configurations:
  Contexts:
In an upcoming PR, I'll provide a cli/DOM.py which can be called with a VHDL file as parameter to call the pretty-printing example code.
xiretza
@xiretza:xiretza.xyz
[m]
is there a good reason why ghdl is only tested on windows, and thus GCC isn't tested at all?
Unai Martinez-Corral
@umarcor
@xiretza:xiretza.xyz that is not correct. Do you mean just the last test I added?
xiretza
@xiretza:xiretza.xyz
[m]
...actually, nevermind, the build jobs on linux also run tests, but for windows building and testing are separate jobs. intersting.
Unai Martinez-Corral
@umarcor
Yes. That is because of performance reasons.
xiretza
@xiretza:xiretza.xyz
[m]
ah, just the usual job setup overhead (fetching containers, fetching repo, etc) or is there something else?
Unai Martinez-Corral
@umarcor

When using containers, we do:

  1. Compile on a build container.
  2. Create a run container with the compiled artifacts.
  3. Run the full testsuite in the run container.
  4. If successful, push.

That's all in a single step (TASK=... ./scripts/ci-run.sh -c).

ah, just the usual job setup overhead (fetching containers, fetching repo, etc) or is there something else?

The opposite. Containers are fast. Windows is slow.

Very specially, disk access is very slow.
So, because GHDL's test suites are based on hundreds/thousands of small files, there is a huge penalty when 1) using Windows and 2) using LLVM backend.
We split windows tests to separated jobs so that we could run the Windows LLVM synthesis and the Windows LLVM vests isolated (in parallel) to others.
Also, on GNU/Linux, we use containers for isolating the build environment and the run environment. We want to ensure that we don't run the testsuites in an environment "contaminated" by build dependencies. On Windows, we don't have containers, so we cannot do that. That's why we need separated jobs/matrices for builds and tests.
Unai Martinez-Corral
@umarcor
Last, but not least, keep https://github.com/ghdl/docker in mind. There is automatic triggering setup. For each succesful CI run in GHDL master, all backends are tested on multiple versions of Debian, Ubuntu, Fedora, Centos, Arch Linux... https://github.com/ghdl/docker/actions/runs/948300552
We try to keep testing the 2 latest versions of each distro.
With regard to GCC, we pick the versions (9.1.0, 8.2.0, 9.2.0, 8.4.0, 9.3.0) quite arbitrarily. Hence, please, feel free to propose updates/enhancements :wink:
xiretza
@xiretza:xiretza.xyz
[m]
I see, it's quite involved and has become even more so since I last messed with it ;)
Unai Martinez-Corral
@umarcor
Yeah, must acknowledge that :smile:
However, please ask. Don't go mad trying to understand it alone. It's not worth the effort.
Let us know what part of CI/testing you want to know about, and I'll point you to the relevant sources.
Unai Martinez-Corral
@umarcor
@Paebbels, good morning! I found that the raise PrettyPrintException(pyGHDL.dom.formatting.prettyprint.PrettyPrintException: Unhandled constraint kind for signal 'rs2'. crash I was getting was because https://github.com/ghdl/ghdl/blob/master/pyGHDL/cli/DOM.py#L56. The prettyPrint call should be moved to L52-L53, so that it does not try to use it in case there was some exception.
Other than that, Tristan fixed the internal crash when analysing "too many" files at the same time: ghdl/ghdl@47e9f0b
This is going nice and fast :rocket:
Julien FAUCHER
@suzizecat
Hey there ! Is it expected to not have the library std.env under Windows with GHDL 0.37 (might be too outdated ?)
It is the ghdl version currently embedded in TerosHDL.
xiretza
@xiretza:xiretza.xyz
[m]
you are using VHDL 2008 (--std=08), right? std.env doesn't exist in earlier versions of the standard.
Julien FAUCHER
@suzizecat
Oh
I'm in 93c
(BTW, it's not a version bundled in teros, scratch this remark)
It works with a more up to date version of GHDL (and Xcelium, for that matter) are you sure it's not supposed to be here before VHDL 2008 ?
xiretza
@xiretza:xiretza.xyz
[m]
pretty sure, yes. I don't have older LRMs on hand right now, but nickg/nvc#41 seems to suggest it should not exist in VHDL <2008
ah, 93c implies -frelaxed, maybe newer GHDL versions allow using std.env in older VHDL versions when that option is set
eine
@eine
If that last comment from @xiretza:xiretza.xyz is correct, it might make sense for it to be available in latest version but not in 0.37. I think that the IEEE and std libraries changed since 0.37. I would need to check it, but v0.37 is from Feb 2020, so just a couple of months after the IEEE 2019 libs were open sourced. I think that Tristan might have backported those during 2020.
Carlos Alberto Ruiz Naranjo
@qarlosalberto
@suzizecat are you using the project manager with GHDL simulator?
(in TerosHDL)
Julien FAUCHER
@suzizecat
Yep as I might have missed how to bring up rusthdl (?)
Patrick Lehmann
@Paebbels
Here some updates on pyGHDL.dom:
  • It passes with some limitations 97% of the testcases (8940 out of 9142).
    The full report can be seen here: https://paebbels.github.io/extended-tests/
  • The 9100 tested files are from OSVVM, UVVM, VUnit, PoC-Library, neorv32, microwatt, ghdl (testsuite/bugreports), ghdl-yosys-plugin, ghdl-cosim)
    • Reported syntax errors are marked as xpassed, because this is not an issue of the translation from GHDL's IIR to pyGHDL.dom
Patrick Lehmann
@Paebbels
Current limitations are:
  • No translation of configurations except for the configuration name ⇒ almost empty DOM object.
  • No translation of configuration specifications except for the configuration name ⇒ almost empty DOM object.
  • No translation for items that declare multiple names at once (e.g. signal sig1, sig2, sig3 : bit; - will be handled soon).
  • IIR node Array_Subtype_Definition - will be handled soon.
  • Handling of AttributeSpecification is incomplete - needs help from @tgingold.
  • Handling of generics (declaration and mapping) in package instantiations.
  • Handling of UseClauses in contexts - will be handled soon.
  • No translation of file open in file object declarations yet.
  • No translation of statements until now.
  • No translation of procedure and function bodies - needs help from @tgingold.
eine
@eine
:tada::tada::tada:
:rocket:
Patrick Lehmann
@Paebbels
Further planned features:
  • Add an reference in each ModelEntity (model class) to the corresponding IIR node.
  • Add an SourcecodePosition in each ModelEntity (model class) to the corresponding IIR node's position.
    Note: implement with lazy loading.
Patrick Lehmann
@Paebbels
Do we also need pytest-meta as a plugin?
Patrick Lehmann
@Paebbels
yes
Patrick Lehmann
@Paebbels
Have you seen, I implemented position on some classes?
eine
@eine
Really busy atm :sob:
ditiris
@ditiris:matrix.org
[m]
I'm new to ghdl and am probably doing something stupid. I'm trying to simulate something with an ISERDESE2. I've compiled my Vivado libraries and included the path to the unisim-0bj08.cf file with the -P switch, but I get a warning for component not bound: instance "instane_name" of component "iserdese2" is not bound [-Wbinding]