Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 16 23:03
    umarcor labeled #1892
  • Oct 16 23:03
    umarcor labeled #1892
  • Oct 16 22:31
    umarcor milestoned #1880
  • Oct 16 22:31
    umarcor closed #1880
  • Oct 16 22:31
    umarcor commented #1880
  • Oct 16 22:03
    umarcor labeled #1893
  • Oct 16 22:03
    umarcor labeled #1893
  • Oct 16 22:03
    umarcor commented #1893
  • Oct 16 15:16
    umarcor milestoned #1894
  • Oct 16 15:16
    umarcor labeled #1894
  • Oct 16 14:56
    JulianKemmerer commented #1894
  • Oct 16 11:35

    github-actions[bot] on nightly

    trans.adb: increased maximum id… testsuite/gna: add a test for #… (compare)

  • Oct 16 11:20
    abyszuk commented #1893
  • Oct 16 11:00
    tgingold closed #1894
  • Oct 16 11:00

    tgingold on master

    trans.adb: increased maximum id… testsuite/gna: add a test for #… (compare)

  • Oct 16 10:01
    tgingold commented #1893
  • Oct 16 09:47
    abyszuk commented #1893
  • Oct 16 09:43
    abyszuk commented #1893
  • Oct 16 09:41
    abyszuk commented #1893
  • Oct 16 09:40
    abyszuk edited #1893
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]
ditiris
@ditiris:matrix.org
[m]
is there something else i need to do in order to bind the component?
Martin
@hackfin
@ditiris:matrix.org, you might just post a snippet/gist somewhere containing the instancing of the component and contents of the .cf. I'm assuming you kept consistency with the option flags for library and project.
Hard to tell without seeing the source..
svenn71
@svenn71
Some of the primitives are not available as hdl
Julien FAUCHER
@suzizecat

Hey there !
I have a design which produce a lot of

../../src/ieee/v93/numeric_std-body.vhdl:1336:7:@0ms:(assertion warning): NUMERIC_STD."<=": metavalue detected, returning FALSE

While I know what produces it (uninitialized values), I would like to know which function produced it.
I wanted to trigger this warning as an error using --warn-error and check the backtrace, but it seems that this option does'nt exists for simulation time (-r command). Could you confirm this ?
As I run ghdl through cocotb, I don't have control over the actual command, I can only add parameters.

eine
@eine
@suzizecat are you using -r --warn-error ENTITY or -r ENTITY --warn-error?
Julien FAUCHER
@suzizecat
The second one, most probably
I (cocotb) run
/opt/ghdl/bin/ghdl -r   --workdir=sim_build -Psim_build --work=work ENTITY --vpi=/home/jfaucher/.local/lib/python3.8/site-packages/cocotb/libs/libcocotbvpi_ghdl.so --warn-error
eine
@eine
I'm not sure, but it might be the other way (an argument for the elaboration).
tgingold
@tgingold
--backtrace-severity=LEVEL display a backtrace for assertions ?
Julien FAUCHER
@suzizecat
@tgingold Well, the issue is that ghdl consider as unknown argument --warn-error in this context
Colin Marquardt
@cmarqu
@suzizecat It looks like you have set SIM_ARGS somewhere in your own Makefile: https://github.com/cocotb/cocotb/blob/master/cocotb/share/makefiles/simulators/Makefile.ghdl#L79