Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jan 20 08:07
    Astiolo commented #1954
  • Jan 20 06:39
    tgingold commented #1954
  • Jan 20 06:37
    tgingold closed #1953
  • Jan 20 06:37
    tgingold commented #1953
  • Jan 20 00:57
    Astiolo commented #1954
  • Jan 19 23:34
    umarcor commented #1954
  • Jan 19 23:29
    Astiolo opened #1954
  • Jan 19 16:00
    Scafir opened #1953
  • Jan 18 19:52
    tgingold commented #1952
  • Jan 18 19:40
    seijikun commented #1952
  • Jan 18 17:17
    tgingold commented #1952
  • Jan 18 15:47
    seijikun commented #1952
  • Jan 18 15:33
    umarcor commented #1952
  • Jan 18 15:04
    seijikun commented #1952
  • Jan 18 14:56
    seijikun commented #1952
  • Jan 18 14:53
    Paebbels labeled #1952
  • Jan 18 14:53
    Paebbels labeled #1952
  • Jan 18 14:53
    Paebbels commented #1952
  • Jan 18 13:56
    seijikun edited #1952
  • Jan 18 13:35
    seijikun edited #1952
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?
I am trying to teach qflow some vhdl, so I translated the benchmark map9v3.v to vhdl with iverilog -tvhdl unmodified
xiretza
@xiretza:xiretza.xyz
[m]
svenn71
@svenn71
thanks a lot. should I punish myself for not searching the issues before asking?
eine
@eine
We don't enforce people damaging themselves for spurious reasons :tongue:
svenn71
@svenn71
I now got motivated by the quick response to my question and will refrain from using internet search in the future
eine
@eine
Overall, this is a very low traffic room, so as long as you don't abuse I personally like direct human interaction from time to time :smile:
Julien FAUCHER
@suzizecat
I might have asked this before but, is GHDL able to output an indexer-like output ? (some kind of list of all identifiers in the code with their position and the fact that an identifier in a given place is a definition or a reference)
Julien FAUCHER
@suzizecat
(I just saw pyGHDL which should be my lifesaver here)
Just a note about the language server, you might not know about and be interested in pygls which is great to build language server based upon LSP
Unai Martinez-Corral
@umarcor
@suzizecat what are "all identifiers" for you?
absolutely anything? generics, ports, constants, signals, instantiations, processes, blocks, etc.?
pyGHDL.dom is meant for that. The minimal example for printing entities, generics and ports only is https://github.com/vhdl/pyVHDLModel#list-all-entities-with-generics-and-ports
pyVHDLModel will allow to retrieve any identifier, but it is not 100% ready yet. So, the answer to your question depends on how deep you want to dive.
Julien FAUCHER
@suzizecat
@umarcor that would be "as much as possible" . I'm currently working on a system verilog language server that take the Verible indexer output and provide all the go-to definition/references stuff. I would like to get as much identifiers as possible to have a cross-language LS as much exhaustive as possible.
Unai Martinez-Corral
@umarcor
Then, I'm not sure you want to use pyGHDL.dom. Maybe you want to look at pyGHDL.lsp. Both of them use libghdl, but the API is different.
Julien FAUCHER
@suzizecat
I'll have a look, thanks !
Unai Martinez-Corral
@umarcor
@suzizecat see https://ghdl.github.io/extended-tests/. That is the result of running ghdl-dom pretty -f FILENAME.vhd on all the sources of GHDL, OSVVM, UVVM, VUnit, PoC, microwatt and NEORV32. In the "Captured stdout call" you can see the identifiers that were properly parsed and printed.