LarsAsplund on master
Fixes #874 (compare)
LarsAsplund on master
Enable VHDL-2019 for Active-HDL… (compare)
Questa itself seems to not needed any linux packages in addition
Note that this might be not the same on Fedora containers: https://github.com/eine/hwd-ide/wiki/Continuous-Integration-(CI)#modelsimquestasim-inside-fedoralatest
Anyway, I also suggest the same approach as @tmeissner: to install in a clean container and then tar the installation directory: https://github.com/mviereck/x11docker/issues/201#issuecomment-558990580
Oh, I didn't know, that Mentor installer has an option to generate a batch installer?
It does. But, AFAIK, you do need to run the GUI installer in order to generate it. Hence, it's does not solve the issue if you cannot run the GUI in the first place.
I have never tried to install Questa on Windows. I made the container for my own usage, targeting Linux. However, there are others in my group who primarily use Windows. I wanted to see how easy it would be to adapt my container workflow for them.
@bradleyharden, I meant to start with flexlm only. Forget about Questasim, for now, as it is unrelated. You should be able to execute lmutil on Windows (on the host) and check the connection to the server. Then execute lmutil in any container (just extract it on the host and mount/bind it in the container).
python run.py -v lib.tb_example.all Compiling into vunit_lib: ../../../usr/lib/python3.8/site-packages/vunit/vhdl/string_ops/src/string_ops.vhd failed === Command used: === /usr/bin/ghdl -a --workdir=/home/dev/tmp/vunit_out/ghdl/libraries/vunit_lib --work=vunit_lib --std=08 -P/home/dev/tmp/vunit_out/ghdl/libraries/vunit_lib -P/home/dev/tmp/vunit_out/ghdl/libraries/lib /usr/lib/python3.8/site-packages/vunit/vhdl/string_ops/src/string_ops.vhd === Command output: === /usr/lib/python3.8/site-packages/vunit/vhdl/string_ops/src/string_ops.vhd:12:10: unit "numeric_std" not found in library "ieee" /usr/lib/python3.8/site-packages/vunit/vhdl/string_ops/src/string_ops.vhd:99:22: no declaration for "unsigned" ... /usr/lib/python3.8/site-packages/vunit/vhdl/string_ops/src/string_ops.vhd:118:14: package "string_ops" was not analysed /usr/bin/ghdl: compilation error
bin/directory in your path? Is
<ghdl install folder>/lib/ghdl/ieee? It looks like your install works correctly to me since it doesn't complain about calling ghdl. Not sure if this helps, but I also add
vu.set_compile_option('ghdl.a_flags', ['--ieee=synopsys', '-frelaxed-rules'])to my run.py
@GlenNicholls Thanks for your reply. I added the line you suggested, no difference.
Listing the ghdl package files, I found:
/usr/bin/ghdl ... /usr/lib/ghdl/ieee/v08/ieee-obj08.cf /usr/lib/ghdl/ieee/v87/ieee-obj87.cf /usr/lib/ghdl/ieee/v93/ieee-obj93.cf ... /usr/lib/ghdl/src/openieee/math_real-body.vhdl /usr/lib/ghdl/src/openieee/math_real.vhdl /usr/lib/ghdl/src/openieee/upf-body.vhdl /usr/lib/ghdl/src/openieee/upf.vhdl /usr/lib/ghdl/src/openieee/v08/std_logic_1164-body.vhdl /usr/lib/ghdl/src/openieee/v08/std_logic_1164.vhdl /usr/lib/ghdl/src/openieee/v87/numeric_bit-body.vhdl /usr/lib/ghdl/src/openieee/v87/numeric_bit.vhdl /usr/lib/ghdl/src/openieee/v87/numeric_std-body.vhdl /usr/lib/ghdl/src/openieee/v87/numeric_std.vhdl /usr/lib/ghdl/src/openieee/v87/std_logic_1164-body.vhdl /usr/lib/ghdl/src/openieee/v87/std_logic_1164.vhdl /usr/lib/ghdl/src/openieee/v93/numeric_bit-body.vhdl /usr/lib/ghdl/src/openieee/v93/numeric_bit.vhdl /usr/lib/ghdl/src/openieee/v93/numeric_std-body.vhdl /usr/lib/ghdl/src/openieee/v93/numeric_std.vhdl /usr/lib/ghdl/src/openieee/v93/std_logic_1164-body.vhdl /usr/lib/ghdl/src/openieee/v93/std_logic_1164.vhdl /usr/lib/ghdl/synopsys/v87/ieee-obj87.cf /usr/lib/ghdl/synopsys/v93/ieee-obj93.cf
The Ghdl version is
0.37 and VUnit is
4.4.0. My $PATH is
/usr/bin:/usr/games:/home/dev/bin:/usr/local/sbin:/usr/local/bin:/usr/lib/jvm/default/bin:/home/dev/.local/bin. Is there maybe an undocumented configuration or dependency?
@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
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!
=== 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
--export-jsonto 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.inifile, and there are no complaints when simulating the design. But when he tried to
--export-json, VUnit says it can't find the libraries.
$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. :)
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