Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 03 20:10

    tgingold on master

    vhdl-sem.adb: fix incorrect che… testsuite/gna: add a test for c… (compare)

  • Dec 03 08:14
    szhou888 commented #1922
  • Dec 03 06:52
    tgingold commented #1923
  • Dec 02 21:35
    Godhart commented #1927
  • Dec 02 21:29
    umarcor commented #1927
  • Dec 02 21:03
    Godhart commented #1927
  • Dec 02 19:29
    umarcor commented #1927
  • Dec 02 19:07
    Godhart opened #1927
  • Dec 02 18:19
    NicoPy commented #1923
  • Dec 01 20:41
    cmarqu commented #506
  • Dec 01 17:28
    tgingold commented #1923
  • Dec 01 16:57
    umarcor commented #1923
  • Dec 01 16:03
    NicoPy commented #1923
  • Dec 01 15:55
    NicoPy commented #1923
  • Nov 30 17:54
    umarcor labeled #1923
  • Nov 30 17:54
    umarcor labeled #1923
  • Nov 30 17:54
    umarcor labeled #1923
  • Nov 30 17:54
    umarcor labeled #1923
  • Nov 30 17:53
    umarcor commented #1923
  • Nov 30 17:52
    umarcor commented #1923
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.

Julien FAUCHER
@suzizecat
Oooh
I’ll test it out, then
eine
@eine
The point is that you cannot decide it at runtime. You need to decide it previously.
As @cmarqu and @ktbarrett, do not be mislead by the Makefile plumbing in cocotb. That is helpful for some users but misleading for others. Try to understand the stages:
  1. Build a shared lib with cocotb's VPI or VHPI interface
  2. pass it to GHDL
  3. Start the simulation with GHDL in charge
  4. Let GHDL call the vpi (shared lib) which loads Python and cocotb internally
  5. cocotb sets the callbacks by interpreting Python and passing arguments to the shared library
  6. GHDL goes forward and executes the callbacks when necessary (which go back to the Python definitions)
Julien FAUCHER
@suzizecat
Indeed, my issue wasn’t with cocotb, but rather with the possibility of using --warn-error at simulation time
eine
@eine
The point is that you need to understand how do cocotb makefiles allow you to pass the arguments at analysis/elaboration time.
It's not cocotb itself, but the plumbing.
Julien FAUCHER
@suzizecat
Indeed, but no point trying to figure it out if GHDL doesn’t allows it altogether :wink:
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

Patrick Lehmann
@Paebbels
Maybe you want to give a :thumbsup: or comment when you use GHDL with CI: https://www.linkedin.com/posts/plc2-gmbh_vivado-riviera-plc2-activity-6818806650049183744-71oY
Martin
@hackfin
I don't do linkedin, but GHDL has been used for CI/verification here for a quite a few complex projects (JPEG encoder SoC). Back then nobody took interest though. Always: thumbs up.
Unai Martinez-Corral
@umarcor
@tgingold, it is theoretically possible to call a foreign function from VHDL for synthesis, isn't it?
The use case is, e.g., generating some values to be used in the generic map of a PLL instantiation. icestorm and prjtrellis provide icepll and ecppll, respectively.
So, I'm thinking about wrapping the call to those tools as VHPIDIRECT functions which returns an struct (record) with the parameters for the instantiation.
I know that top-level generics or code-generation of packages is the most used solution. But I wonder if reusable utilities provided as a VHDL package can help keeping the complexity local.
Unai Martinez-Corral
@umarcor

https://twitter.com/unaimarcor/status/1415928619659145216

Open Source VHDL Design Explorer (OSVDE) is a PoC for showcasing the capabilities of the abstract language model provided by pyVHDLModel and pyGHDL. It's a tkinter GUI for exploring VHDL repos/projects.
Kudos to @Paebbels and Tristan Gingold! :heart_eyes:
See https://umarcor.github.io/osvb/apis/project.html#open-source-vhdl-design-explorer-osvde

pyOSVDE.gif
Carlos Alberto Ruiz Naranjo
@qarlosalberto
really nice! <3
tgingold
@tgingold
@umarcor Yes it is, but I am not sure it is currently supported.
Unai Martinez-Corral
@umarcor
:thumbsup:
svenn71
@svenn71
why is it an error if yosys-ghdl-plugin infers a latch during synth in yosys?