Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • May 23 08:51
    gncemre23 commented #2065
  • May 22 18:00

    github-actions[bot] on nightly

    synth/elab-vhdl_values: use a p… vhdl-canon: remove unused canon… synth-vhdl_expr: avoid a memocy… and 6 more (compare)

  • May 22 17:21

    tgingold on master

    synth/elab-vhdl_values: use a p… vhdl-canon: remove unused canon… synth-vhdl_expr: avoid a memocy… and 6 more (compare)

  • May 22 11:10
    Paebbels commented #2065
  • May 22 11:01
    Paebbels commented #2065
  • May 22 11:00
    gncemre23 commented #2065
  • May 22 04:08
    tgingold commented #2065
  • May 22 04:08
    tgingold reopened #2065
  • May 21 17:00
    Paebbels commented #2065
  • May 21 16:13
    gncemre23 closed #2065
  • May 21 16:12
    gncemre23 commented #2065
  • May 21 15:22
    gncemre23 edited #2065
  • May 21 15:06
    umarcor labeled #2065
  • May 21 15:06
    umarcor labeled #2065
  • May 21 15:03
    gncemre23 opened #2065
  • May 20 22:56
    umarcor opened #2064
  • May 18 17:58

    github-actions[bot] on nightly

    elab-vhdl_context: remove cur_s… synth-vhdl_stmts: add comments … synth-vhdl_stmts: avoid a crash… and 1 more (compare)

  • May 18 17:17
    umarcor milestoned #2063
  • May 18 17:16
    tgingold closed #2063
  • May 18 17:16

    tgingold on master

    elab-vhdl_context: remove cur_s… synth-vhdl_stmts: add comments … synth-vhdl_stmts: avoid a crash… and 1 more (compare)

Farmadupe
@Farmadupe
So this is just a small attempt to see if it's possible to work around those flaws, but also in a minimal effort, minimal maintenance way
Kamyar Mohajerani
@kammoh
Is there any way to get width of array signal from GHDL, in addition to signal names (e.g. signals dumbed in a GHW waveform)? I'm trying to add automatic generation of gtkwave savefiles to Xeda. So far, I'm using --write-wave-opt (and --read-wave-opt) to get the list of signals to go in the gtkw file. This works fine for non-array (single-bit or integer) signals (and pretty easy to get it working in Python, using pyvcd). But gtkwave only displays element(0) of an array (e.g. SLV) if the bits are not added individually to the GTKW save-file (seems also crashing with fst dumps).
So I need the width of signals and ports. This information is obviously available to GHDL, and should be easy to give to the user, but so far, I've not found any such feature. I also tried --disp-tree=port which displays the full hierarchy including process names, etc., but nothing about signal widths.
tgingold
@tgingold
The ghw files contain the width of all types. Maybe you can also extend --write-wave-opt, or add comments in vcd files for skiped signals.
Kamyar Mohajerani
@kammoh
Yes extending —write-wave-opt With width information would be great. It could also be added as a “comment”, maybe on the line following (or preceding) the signal name, to keep backward compatibility with current read-wave-opt or any other tool/flows possibly using this feature.
Julien FAUCHER
@suzizecat
@Farmadupe if you are working with VHDL and looking for a language server, may I suggest you looking into TerosHDL ? It works fairly well with VHDL IMHO (including on Windows).
Alastair M. Robinson
@robinsonb5
Hi, is there a known performance issue with large arrays of compound data? I'm attempting to get the PC Engine retro core buildable with Yosys and friends, and hit a problem with this file: https://github.com/mist-devel/TurboGrafx16_FPGA/blob/master/rtl/HUC6280/HUC6280_MC.vhd - the large arrays of MicroInstr_r take many minutes to process with ghdl -a. If I flatten the data to a simple 42-bit-wide std_logic_vector the file analyzes in a fraction of a second.
std-max
@std-max
What is your backend ?
ghdl backend* ?
Alastair M. Robinson
@robinsonb5
This is ghdl from the current oss-cad-suite, so GHDL 3.0.0-dev (2.0.0.r140.g89a364a5.dirty) [Dunoon edition]
Compiled with GNAT Version: 9.3.0
llvm code generator
std-max
@std-max
Have you tried something like:
constant slv_constant : specific_record_t := ('xxxxx' .... );
constant M_TAB1: MicroInst_t := (others => slv_constant);
(specify a constraint after MicroInst_t)
Alastair M. Robinson
@robinsonb5
OK just tried what you suggested, and it's pretty much instant.
std-max
@std-max
So maybe it's due to the processing as your constant declaration are quite large
Alastair M. Robinson
@robinsonb5
Yes, I think so. The processing time definitely isn't growing linearly, though.
I tried with just the M_TAB1 array, the whole thing takes 6 min 44 seconds to process with ghdl -a on my machine.
std-max
@std-max
It is written in the documentation that 'analyze' is faster with mcode than with GCC and LLVM for large file, I dont know the reason why
Alastair M. Robinson
@robinsonb5
If I process just the first half it takes 1 minute 20. The first quarter takes just 11 seconds!
And as I say, if I flatten the whole thing so that each entry is just a 42-bit-wide std_logic_vector it processes in a fraction of a second.
std-max
@std-max
oh ok I have misunderstood the part about flattening array
that's strange
Alastair M. Robinson
@robinsonb5
I'm glad someone else thinks it's strange! Thanks - if it's not a known issue I guess I should file a bug for it.
std-max
@std-max
I'm testing it with another backend
It is immediate with ghdl_mcode
std-max
@std-max
It takes 1.67s with ghdl_gcc
(both results for parsing only M_TAB1)
So I think the problem is related to LLVM IR, @tgingold will know for sure :D
Alastair M. Robinson
@robinsonb5
Very interesting - thanks for looking into it.
tgingold
@tgingold
Yes, ghdl creates a huge function build the aggregate, and llvm struggles on it. Can you create an issue, I will try to fix it.
Alastair M. Robinson
@robinsonb5
Certainly - I'll do that now...
Alastair M. Robinson
@robinsonb5
Done - issue no 2051. Do let me know if there's anything else I can do to help.
pepijndevos
@pepijndevos:matrix.org
[m]
uhoh ../../src/ieee2008/numeric_std-body.vhdl:3147:41:error: no overloaded function found matching 'minimum'
I get a ton of errors like that when using the yosys synthesis plugin, but not when just simulating
pepijndevos
@pepijndevos:matrix.org
[m]
also works fine with --synth
yolo I'm just going to make a verilog netlist and use that because LiteX doesn't support VHDL that well anyway
uhhhh this doesn't look like valid verilog n17_o <= std_logic_vector(abs $signed(steps));
pepijndevos
@pepijndevos:matrix.org
[m]
looks like it's because of the abs function
tgingold
@tgingold
Please open issues. For the abs, it should be easy to fix.
T. Meissner
@tmeissner
Mhm, I have strange things happen with PSL assertions during simulation. The behaviour of them depends on each other. If I comment out a failing assertion, suddenly another assertion triggers, which wasn't triggered before and is definitily correct
Another thing I have is a simulation which fails with a NULL pointer access if I use the --wave option.
ghdl -r --std=08 spit --wave=spit.ghw
./spit:error: NULL access dereferenced
in process .spit(sim).datadirectiong(1).spimastersg(3).i_spimastere@spimastere(rtl).P8
make: *** [Makefile:75: spi] Error 255
But that error only occurs in Github CI using ghdl/vunit:llvm docker image
Even stranger is that the PSL errors don't occur in that docker image :confused:
T. Meissner
@tmeissner
I have to investigate deeper before I possibly file an issue.
Unai Martinez-Corral
@umarcor

@Farmadupe @Paebbels at first, the LSP server and the clients were all located in repo ghdl-language-server. Then, the server (Python) was moved to repo ghdl, while the client (vscode-client) was left in ghdl-language-server. Some months later, the emacs-client example was contributed to ghdl-language-server. There were also attempts to add a vim client/config, but I don't remember if that went into the repo.
Later, the Python code in ghdl was reworked and renamed to pyGHDL.

So, today, the LSP server is part of pyGHDL and the ghdl-language-server contains either clients or configurations required by various editors/IDEs. @Paebbels as for what the clients/configurations do, for instance, VSCode supports snippets, which are not part of the language server per se: https://github.com/ghdl/ghdl-language-server/tree/master/vscode-client/snippets. Actually, the snippets engine is rather limited for VHDL, but it's there.

Overall, the README of ghdl-language-server might be misleading. @abyszuk brought the attention some months ago: umarcor/umarcor#2

@Farmadupe I use the VSCode client/extension on Windows, but I do it with the Remote - Containers extension. Therefore, the ghdl-ls server is not executed on windows, but inside the container.
VSCode does not like MSYS2 much, so I did not really put much effort into running ghdl-ls natively.
@Paebbels, did you use/try ghdl-ls with PyCharm?
Unai Martinez-Corral
@umarcor
@kammoh have a look at https://umarcor.github.io/osvb/notebook/fpconv.html. Sources: https://github.com/umarcor/osvb/tree/main/fpconv. I don't remember if the text says anything about the VPI example, but you can read the C source.
The idea of that "fixed-point coversion" is: Can I record all the values that one specific signal has during a simulation and compute statistics on them (maximum, minimum, mean, modal...). My purpose is to record "reals" and then decide the "best" fixed-point format for them. Nonetheless, the "article" is a discussion about different solutions: using waveforms and post-processing, using VHDL monitors and writing to files/CSVs (either in VHDL or using VHPIDIRECT), using VPI/VHPI...
The VPI approach is interesting, but it does not allow "dynamically" walking through the hierarchy. I.e., you need to know the names of the signals you want to record in advance. You cannot query the simulator about the hierarchy.
Conversely, the waveform approach allows you to dynamically explore the data, at the cost of having all of it saved in the first place.
Unai Martinez-Corral
@umarcor
So, I wondered if "custom waveform writers" could be attached to GHDL (I can't find the issue/discussion now...). That is somehow similar to VPI, but using GHDL's internal API. GHDL's internal API has access to all the data, but the caveat is it's not really an API (it's not documented).
I thought about sigrok-cli and Pulseview. The "protocol decoders" written in Python are so interesting! https://sigrok.org/wiki/Protocol_decoders
Unfortunately, sigrok-cli cannot handle multi-bit signals efficiently. It is optimised for single-bit 2-value serial signals. See https://umarcor.github.io/osvb/notebook/sigrok.html.
Last year, pyVHDLModel came into play. pyVHDLModel is a Python API that can be plugged to pyGHDL (see pyGHDL.dom). It allows to throw a bunch of VHDL sources, dynamically analyse the design (instantiated components, ports, types, size, etc.) and make decisions before running the simulation. Therefore, you can have your own Python code to dynamically decide which signals to save to the waveform. Technically, you need to generate the wave-opt file (https://ghdl.github.io/ghdl/using/Simulation.html#cmdoption-ghdl-read-wave-opt).
At the moment, pyGHDL.dom does not provide a complete elaboration of the design. Therefore, depending of the complexity of your types, sizes might not be completely resolved. However, it is valuable to know whether there is demand for such features/use cases.
Unai Martinez-Corral
@umarcor
@tmeissner can you please check the version of GHDL and VUnit? Container images ghdl/vunit:* should not be very different from other ghdl/ghdl^:* images, or the ones from hdl/containers. Actually, both ghdl/vunit:* and hdl/containers do reuse the pre-built content from ghdl/ghdl:*