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)
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)
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)
tgingold on master
elab-vhdl_context: remove cur_s… synth-vhdl_stmts: add comments … synth-vhdl_stmts: avoid a crash… and 1 more (compare)
--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).--disp-tree=port
which displays the full hierarchy including process names, etc., but nothing about signal widths.
—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.
../../src/ieee2008/numeric_std-body.vhdl:3147:41:error: no overloaded function found matching 'minimum'
n17_o <= std_logic_vector(abs $signed(steps));
--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
ghdl/vunit:llvm
docker image
@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
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:*