Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 10:01
    Bonusbartus commented #880
  • Dec 07 18:05
    LarsAsplund reopened #880
  • Dec 07 18:04
    LarsAsplund labeled #877
  • Dec 07 18:04
    LarsAsplund commented #877
  • Dec 07 17:49
    tasgomes commented #877
  • Dec 07 17:14
    LarsAsplund commented #880
  • Dec 07 15:46
    LarsAsplund commented #877
  • Dec 07 15:12
    eine labeled #880
  • Dec 07 15:12
    Bonusbartus closed #880
  • Dec 07 15:12
    Bonusbartus commented #880
  • Dec 07 15:10
    tasgomes commented #877
  • Dec 07 15:09
    tasgomes commented #877
  • Dec 07 15:06
    LarsAsplund commented #877
  • Dec 07 15:02
    eine labeled #880
  • Dec 07 15:01
    LarsAsplund commented #880
  • Dec 07 14:56
    tasgomes commented #877
  • Dec 07 14:12
    LarsAsplund commented #877
  • Dec 07 10:13
    Bonusbartus opened #880
  • Dec 07 09:14
    tasgomes commented #877
  • Dec 07 07:51
    LarsAsplund commented #877
Bradley Harden
@bradleyharden
@tmeissner 😑
T. Meissner
@tmeissner
Yes, Questa is 64 bit
Modelsim has a 32 bit binary, We had to install 3 further 32 bit packages to run it
T. Meissner
@tmeissner
@NanooooK It's not easy to get the Dockerfiles out of our internal network, I hope you have patience ;)
NanooooK
@NanooooK
Don't worry there is no rush :)
Yatekii
@Yatekii
argh I wanna kms ... xilinx tooling is absolute garbage ...
I wanna use nice tools :(
eine
@eine

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).

Of course, you need two different lmutil artifacts: for Windows and for GNU/Linux.
Fortunately, you should find it everywhere: Xilinx, Altera, Lattice, Mathworks, Autodesk...
Lars Asplund
@LarsAsplund
@all For some reason I cannot give thumbs up on this one but if you agree please give it a try. https://forums.xilinx.com/t5/Simulation-and-Verification/Add-support-for-VUnit/td-p/1098552
Bradley Harden
@bradleyharden
I'd tried. Couldn't thumbs-up either
It must be one of these
Lars Asplund
@LarsAsplund
@all Logged out and in again. Now i works
Rafael Pereira
@rafaelnp
I am new to vunit, and starting by running on Linux the examples and I got this error using ghdl, could not find a solution elsewhere, any hints?
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
Lars Asplund
@LarsAsplund
@all Keep the kudos coming if you're interested. I think that showing market interest is the only way to get this working properly. We filed bug reports years ago but that didn't help.
image.png
T. Meissner
@tmeissner
Is this the same login as for the Xilinx website?
Lars Asplund
@LarsAsplund
yes
T. Meissner
@tmeissner
I will try to vote after I found my login credentials ;)
T. Meissner
@tmeissner
Voted :)
Carlos Alberto Ruiz Naranjo
@qarlosalberto
+1
NiJen
@NiJen
+1
Lars Asplund
@LarsAsplund
@NiJen @qarlosalberto @tmeissner Brilliant, now we have 7 votes. I think 25 would be sufficient to show great commercial interest
Tiago Gomes
@tasgomes
+1
GlenNicholls
@GlenNicholls
@LarsAsplund I was able to vote this morning. I had problems last night as well
GlenNicholls
@GlenNicholls
@rafaelnp Which version of GHDL are you using? Do you have the bin/ directory in your path? Is ieee defined under <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
Rafael Pereira
@rafaelnp

@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?

GlenNicholls
@GlenNicholls

@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

eine
@eine
@rafaelnp it seems that you installed the GPL variant of GHDL, which does not include regular IEEE libs, but a subset named openieee.
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
@GlenNicholls
@eine for my understanding, what is the differrence between the two versions of GHDL? Why does only the non-GPL variant of GHDL include the IEEE libs?
eine
@eine
For clarification: GHDL itself is always GPL, but IEEE libs are not. Until recently, IEEE libs were not open source. Now, they are available under Apache license.
@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.
eine
@eine
I think it is because <2008 versions of the standard. But I'm not sure.
Rafael Pereira
@rafaelnp
@eine Using pacman -S ghdl-mcode on Arch Linux and apt install ghdlon Ubuntu 19.10.
eine
@eine

@eine Using pacman -S ghdl-mcode on Arch Linux and apt install ghdlon Ubuntu 19.10.

And you get the same error when using VUnit in any of them?

GlenNicholls
@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.

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!

Rafael Pereira
@rafaelnp
@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
eine
@eine
@rafaelnp are you trying to execute one of VUnit's examples? Or your own?
Bradley Harden
@bradleyharden
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?
Rafael Pereira
@rafaelnp
@eine the examples from the user_guide.
@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. :)
GlenNicholls
@GlenNicholls
@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.
NanooooK
@NanooooK
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