ghdl/Lobby

xiretza

@xiretza:xiretza.xyz

you are using VHDL 2008 (--std=08), right? std.env doesn't exist in earlier versions of the standard.

Julien FAUCHER

@suzizecat

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?

eine

@eine

Do you mean https://pypi.org/project/pytest-metadata/ ?

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

Julien FAUCHER

@suzizecat

@cmarqu Indeed, the goal is actually to have the warnings treated as error.
My question was about the fact that it is (or not) allowed to use this option at run-time.

Colin Marquardt

@cmarqu

Maybe EXTRA_ARGS helps (which is behind GHDL_ARGS in that line)

Ah, I see. Worst case, just copy that Makefile.ghdl into your project.

COMPILE_ARGS would be another candidate to try.

Kaleb Barrett

@ktbarrett

@suzizecat The cocotb makefiles don't do anything special and aren't all that useful IMO. I'd just roll your own. The only important bit you need for cocotb is encapsulated in cocotb-config --lib-name-path vpi ghdl. And you will also need to set the MODULE environment variable at a minimum to find tests. See my crappy basic Makefile I threw together because I didn't feel like figuring out which of the 3 *_ARGS variables did the thing I needed it to.

tgingold

@tgingold

@suzizecat --warn-error is an option for the analysis, not for the simulation.

eine

@eine

@tgingold is that true for all the --warn-* options?

I would expect them to be "analysis and elaboration" options, so they need to be provided for -a and -e, and must be consistent (similar to --std or --frelaxed options).

tgingold

@tgingold

Yes, indeed, they are analysis and elaboration options. But not simulation

eine

@eine

Thanks!

Then, @suzizecat, my intuition in :point_up: July 2, 2021 5:42 PM was correct. You can use it before the entity if you are doing elab-run.

Julien FAUCHER

@suzizecat

@tgingold Thanks for the clarification !
@eine OK, but as @tgingold said, it won’t work at simulation time, hence it is of little use to me (in this context), unless I still missed something ?

eine

@eine

@suzizecat you should be able to provide the arguments used for analysis and elaboration. The build plumbing should not limit your in that regard.

Julien FAUCHER

@suzizecat

Yes, but my point is that the warning I want to backtrace is at simulation time

eine

@eine

The concept of cocotb is to build a shared library and provide it as an --vpi argument to GHDL. You also need a few envvars (two?) which the "embedded" python instance will use when running the cocotb testbench. Other than that, it's a regular HDL simulation, so you can use the regular GHDL commands.

Yes, but my point is that the warning I want to backtrace is at simulation time

I think that using the warn arguments for analysis and elaboration is not limited to those stages. You are telling GHDL that you want those features enabled.

Where communities thrive

People

Repo info

Activity