@rafaelnp Hmmm, so in by GHDL install directory under lib/ghdl/ieee/v08, for example, I see .o files for all the compiled VHDL files, not a single .cf. Maybe when GHDL is compiled on linux it is different, but I use Windows.
One problem I see with your path is the GHDL exe is not there. My path has C:\ghdl\ghdl-0.36-mingw64-llvm\bin
You should either build/install the non-gpl version, or alternatively download IEEE libs yourself. You can retrieve them from IEEE GitLab repo, or from https://github.com/ghdl/ghdl/tree/master/libraries.
@GlenNicholls, some years ago GHDL was distributed as a Debian package, but because it included non-free IEEE libs it was removed. Then, Tristan wrote openieee to allow a roughly functional package of GHDL + libs to be distributed through Debian repos. Now that IEEE libs are open source, openieee should not be required. Hence, I wonder:
- How did @rafaelnp install that variant of GHDL?
- Why was the GPL flavoured build of GHDL not removed from the releases/CI during these last months?
Regarding the second question, I'll ping @tgingold.
some years ago GHDL was distributed as a Debian package, but because it included non-free IEEE libs it was removed. Then, Tristan wrote openieee to allow a roughly functional package of GHDL + libs to be distributed through Debian repos. Now that IEEE libs are open source, openieee should not be required.
Ahhh okay, I see. Probably explains why I had so many difficulties with GHDL a few years ago when I first tried to use it. Thanks for the history!
@eine My first message contained the error on Arch Linux, the one below is from Ubuntu, similar, but not the same:
=== Command output: ===
/usr/bin/ghdl-mcode:warning: library ieee does not exists for v08
/usr/local/lib/python3.7/dist-packages/vunit/vhdl/string_ops/src/string_ops.vhd:9:9: cannot find resource library "ieee"
/usr/local/lib/python3.7/dist-packages/vunit/vhdl/string_ops/src/string_ops.vhd:10:10: unit "std_logic_1164" not found in library "ieee"
Compile failed
A colleague of mine is trying to use
--export-json to get started with rust_hdl. I have done neither before, so I'm having trouble helping him. VUnit is choking on the vendor libraries. Their location is called out in the modelsim.ini file, and there are no complaints when simulating the design. But when he tried to --export-json, VUnit says it can't find the libraries.
Any thoughts? Is this a possible bug? Or is he not doing something right?
Wait, maybe that makes sense. There are no source files for the pre-compiled vendor libs, so it doesn't make sense for them to be included, right?
@eine @GlenNicholls I was able to find the root cause, as pointed by @eine. I downloaded the ghdl source code, compiled and installed and added it to the
$PATH, and now it works. I compared both package contents (Arch and Ubuntu) to the manually installed files, and there are binary (*.o) and VHDL files missing. Thanks for your help. :)
@all does anyone have any public resources for combining multiple verification components in a single BFM? I have a large design I'm currently verifying and the testbench is getting pretty ugly with all of VC's and message passing. I've got AXI master/slaves, AXI stream, UART, AXI GPIO, and memory and I would like to package this in a single BFM to make it easier to maintain. Unfortunately, the component I'm working with will be used in an even larger design so I'm trying to find a reasonable way to put this in a single BFM such that it can be directly instantiated later without copying/pasting so much code. I checked tsfpga and it doesn't look like they have anything like this and searching GitHub isn't yielding anything.
Is there a way from a VHDL testbench to retrieve the information provided by Python
add_config? I'm looking to retrieve the name so I can pass it to the file_handler parameters. I've checked the documentation but the only information that I've found that could be extracted from the runner are output_path and tb_path
@all Nice voting for https://forums.xilinx.com/t5/Simulation-and-Verification/Add-support-for-VUnit/td-p/1098552. We're
they had 12 years time to implement 2008 and it still is not
Still, praying is free (as in free beer).
But I’m very glad to have Questa at work.
do you think they work on the tools for free? :D
how do you think they are paid?
with revenue from sold chips
and who pays for the chips? yes, you, the vivado user
it is 100% not free
so they don't have to improve
which is stupid
and I don't have the money for modelsim tbh
but tbh, no chip manufacturer procides even halfways decent devtools lol
there is no chip manufactuer that provides a proper ide that is not eclipse based or absolute garbage in any other way lol