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
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
--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.
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.
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.
ghdl backend* ?
(specify a constraint after MicroInst_t)
I tried with just the M_TAB1 array, the whole thing takes 6 min 44 seconds to process with ghdl -a on my machine.
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.
that's strange
It is immediate with ghdl_mcode
(both results for parsing only M_TAB1)
So I think the problem is related to LLVM IR, @tgingold will know for sure :D
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
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));
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:
@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?
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?
@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 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.
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.
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.
@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:*