Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 13 16:24
    eine synchronize #557
  • Dec 13 16:21
    eine commented #557
  • Dec 13 16:20
    eine synchronize #557
  • Dec 13 16:06
    eine review_requested #557
  • Dec 13 15:58
    dstadelm review_requested #557
  • Dec 12 20:57
    nfrancque commented #577
  • Dec 11 22:53
    bradleyharden commented #604
  • Dec 09 16:18
    dstadelm synchronize #557
  • Dec 09 14:47
    eine commented #588
  • Dec 09 14:04
    dstadelm synchronize #557
  • Dec 09 14:00
    dstadelm commented #588
  • Dec 09 08:45
    umarcor commented #603
  • Dec 09 07:07
    abaebae closed #605
  • Dec 09 07:07
    abaebae commented #605
  • Dec 08 21:58
    umarcor synchronize #606
  • Dec 08 20:53
    umarcor synchronize #606
  • Dec 08 20:47
    umarcor edited #581
  • Dec 08 20:47
    umarcor synchronize #581
  • Dec 07 18:35
    eine commented #604
  • Dec 07 18:23
    alexg-k commented #604
Bradley Harden
@bradleyharden

BTW, how did you solved licensing issues? Are you just adding a license file to the container? Or are you using a remote license server?

We already use a licensing server. All I had to do was copy the environment variable.

1138-4EB
@1138-4EB

Still, I want to generally decouple the VUnit version from the simulator version.

You can achieve this building a base image bradley/questa:10.5 and a "featured" image bradley/questa:10.5-vunit, which includes Python, colorama and, optionally, VUnit (recursive).

Bradley Harden
@bradleyharden

Is there no way to mount the installer when building, so you don't have to copy it?

"First generation" OCI image building tools don't allow it. However, I think that "second generation" tools, such as buildkit, might support it. Anyway, you can achieve it with a temporal container:

  • Write a script that installs QuestaSim and the builds a tarball for distribution.
  • Execute the script in a container and copy the tarball to your host.
  • Add/copy the tarball in the Dockerfile.

Since you are binding QuestaSim sources when running the container, there is no copying.

Alternatively, you might want to ENABLE_BUILDKIT=1. I don't know if it will make a difference, tho.

This is essentially what I was thinking. Although I had planned to commit to first container rather than create a tarball and copy it in. Either way, it's more manually than I would like, but I suppose you only have to do it once.

T. Meissner
@tmeissner
We have a similar approach at work. Our base image is based on Debian base image + Python3 (as we always use Py3) and some tools every project needs (make and stuff)
Then our simulator images are based on this image
on top, we will maybe have images which add vunit or such libraries
A problem, which we have, is our network isn't connected to the internet, we have our own "docker hub"
1138-4EB
@1138-4EB
Thanks for the references about X forwarding. I was going to suggest x11docker, which helps setting up the Xauthority and other files. The standard solution is to execute an X server on the remote host, let the container use it and use SSH or xpra on your client.
Unfortunately, I think that podman is not supported by x11docker yet.
T. Meissner
@tmeissner
But, what should I do when I want to build projects like symbiyosys which need a lot of additional projects available during building? :(
Bradley Harden
@bradleyharden
Ack, I just noticed the time. I've spent too much of today on this. Thanks for the feedback @1138-4EB and @tmeissner. It sounds like I'm on the right track
T. Meissner
@tmeissner
I fear I have to download all these dependencies before in an online session, transfer them in the internal network, and build the image there
Bradley Harden
@bradleyharden
I'll review #324 and see if it will work for me
1138-4EB
@1138-4EB

But, what should I do when I want to build projects like symbiyosys which need a lot of additional projects available during building? :(

@tmeissner, Can't you build them "outside", then export and import?

@bradleyharden, see you!
T. Meissner
@tmeissner
Is there any way to export?
Another possbile way would be to build outside and only copy the resulting executables in the internal network
The point is that, if you are allowed to copy executables from outside, you should also be allowed to copy an image as a tarball.
kraigher
@kraigher
At my work we just have VUnit as a git submodule in the project repo. Thus it is checked out along with the project files.
There is no need to install VUnit, you can just set the PYTHONPATH
1138-4EB
@1138-4EB
@kraigher, I think that adding VUnit as a submodule is not enough. colorama needs to be installed too, isn't it?
kraigher
@kraigher
Yes sure colorama needs to be there
But that is a very stable dependency, it can be added to the docker image
Felix N
@felixn
Hi all, any plans for a new release yet? Currently, the documentation on vunit.github.io does not match the version released on PyPI.
For example:
https://vunit.github.io/py/vunit.html#library
vs
>>> import vunit
>>> vunit.version()
'4.2.0'
>>> vunit.ui.library.Library()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: module 'vunit.ui' has no attribute 'library'
1138-4EB
@1138-4EB
@felixn, yes. We already talked about it a couple of weeks ago, and we could release a new version now. What is preventing me from doing that is that some users reported that master crashes on some simulator and they went back to v4.2.0. If we can have at least a user report that master is good in each of Active, Riviera and ModelSim, we can publish. Do you have access to any of those?
Felix N
@felixn
Only ModelSim, I can verify tomorrow. Any specific tests, or just the normal acceptance tests?
1138-4EB
@1138-4EB
The blaming changes were related to vhdl/data_types/src/types.vhd, so running any of the examples should trigger it. py38-acceptance-modelsim should be more than enough.
Felix N
@felixn
Will do!
1138-4EB
@1138-4EB
This is the previously "report": October 28, 2019 5:08 PM
This line might need to be fixed: https://github.com/VUnit/vunit/blob/master/vunit/vhdl/data_types/src/types.vhd#L33 from (0 to integer'high) to (0 to integer'high-1). in case ModelSim crashes, you can try changing that.
Felix N
@felixn
:thumbsup:
1138-4EB
@1138-4EB

Currently, the documentation on vunit.github.io does not match the version released on PyPI.

Although both the sources of the docs and the sources of the site are versioned (in git), GitHub Pages does only serve the latest commit of a single branch. We can address this in multiple ways:

Currently, users can:

  • Clone the tags from vunit/vunit and execute tox -e py38-docs to get the docs that correspond with their installed version. The output is located in .tox/py37-docs/tmp/docsbuild/.
  • Download a version from vunit/vunit.github.io as a tarball. However, they need to search which commits were pushed after the release and before relevant changes were introduced.
We might address tagging vunit.github.io when tags are pushed to vunit/vunit in #536. See https://github.com/VUnit/vunit/pull/536/files#diff-d9e8161f95fdd9b8e476fd456f35a9a2R58-R74. However, due to the wide range of possibilities, I'd like to hear any thoughts. An issue/PR to explain current options in the docs is welcome too.
Lars Asplund
@LarsAsplund
I can test Active-HDL and Riviera-Pro tomorrow. I did fix one error but I haven't run the complete test suite.
Nathanael Huffman
@nathanaelhuffman
@jjarmagost There are certainly improvement opportunities for the process I'm about to describe, but it's working well for us. At work, what we did to solve the Altera/Intel IP thing was build a really small shim that sub-classes VUnit, added an "add_qsys()" method, and generally also hooks into the compile and clean functionality of vunit. During a compile, we call all of the Quartus tools to generate the systems in simulation mode, call another Quartus tool to make a combined simulation and then write a small .tcl file that calls the msim_setup.tcl (generated by Quartus) and (we're using VHDL flow) also puts each of the top-level files into correctly named libraries since the msim_setup.tcl seems to insist on putting the top of qsys systems into work instead of libraries with the same names which is what their synthesis does, and we run the msim_setup.tcl to compile all of the stuff. We then scrape the libraries from the msim_setup.tcl and pass those to vunit as "external_libraries" so it doesn't choke when trying to compile. We also maintain a small file database that tracks the sha-hash of the qsys and re-generates as necessary, this probably could have been integrated into VUnit's database but it was easier to figure out without doing that. If clean is called, we blow away all of our generated stuff and the stuff msim_setup.tcl created. I can't post the code, but I'll try to put a better how-to here in chat tomorrow that will cover more of the gotchas. It was kind of a pain to figure out, but now that it's working, we just add the .qsys files in our run.py and we're off to the races, changes force regeneration etc.
jjarmagost
@jjarmagost
@nathanaelhuffman Thanks for the message, Nathanael (or probably Nate?). It's interesting to hear how other people are doing their stuff. Coming from a Linux background, really all that's necessary is to set up a Make project for the IP models, but I can't in good conscience force Make onto my Windows using coworkers. :-) I'm currently looking at a Python-based Make called "doit". Then the flow would be to call "doit" at the beginning of run.py and it would always ensure that all the IP models are up to date before we even get into VUnit. (Just to let you know, you're probably reinventing the wheel a little bit because doit keeps track of dependencies by storing a hash of the files. MD5 I think instead of SHA, but anyway...) Thanks for your message!
@nathanaelhuffman Rereading my last post, I wanted to be more clear. The last part was just saying, "you might be interested in checking out many of the off-the-shelf build automation tools that keep track of file dependencies and automatically build just the pieces that need to be updated." doit is just one of the many.
@nathanaelhuffman … but it's certainly fun to build your own, too. I get it. :-)
maierchr
@maierchr
Hi there, I am using the add_vivado_ip function for a block level simulation. Now I ad the DDR4 core and model to the block. Unfortunately the simulation stop working. This is caused by two file_types in the generated compile_order.txt: SystemVerilog (Xilinx DDR4 IF) and ELF (for some Microblaze uC in the DDR4) used in the DDR4 files .
The SystemVerilog issue could be solved by adding "SystemVerilog" in vivado.py line 100 (at the first look).
The ELF file handling seems to be more complex.
Does anybody has an idea?
Emad Alhasab
@elhasab

@maierchr I have the same issue with filters that add coefficient and memory initialization files.
an easy (and ugly) workaround is to check and skip those files in vivado/vivado.py, for example (in my case):

for line in ifile.readlines():
             library_name, file_type, file_name = line.strip().split(",", 2)
+            if file_type in ("Memory Initialization Files", "Coefficient Files"):
+                continue
             assert file_type in ("Verilog", "VHDL", "Verilog Header")
             libraries.add(library_name)

I wonder if someone have a proper solution for this problem.

Nathanael Huffman
@nathanaelhuffman
@jjarmagost I think it also depends on your workflows and how much IP and qsys systems you're using. When we first started, we used to just compile the device libraries but as Quartus has come to rely more on individual qsys files for significant amounts of IP, and our designs that we want to simulate begin to include multiple qsys systems in some cases it was nicer to build the tooling so that the user just needs to think about including qsys files in the simulation and all of the background work is done by the tool. Multiple qsys systems get kind of tricky since you need to make a combined simulation script. Rather than figure out all of that I wanted to use the msim_setup.tcl generated when you make-ip-sim-script. Maybe I'm missing a more simple solution, but it would seem like using something like doit still requires one to generate all of the simulation models and have them compiled by modelsim and added to vunit as external dependencies would still be required no? With our system we do a vu.add_qsys_system('<qsys_file_name>') in our run.py for as many systems/ip as are required for the given testbench and the external files get refreshed as needed and compiled into externally managed libraries (from vunit perspective) and the sim "just works". I am interested if I'm not understanding your proposed flow, or if I've missed an obviously simpler way to do integrate with Quartus IP, my example use case is some testbench files, some plain vhdl logic files instantiated by the testbench, and 2 custom qsys systems, also instantiated by the testbench.
1138-4EB
@1138-4EB
@nathanaelhuffman, you said that you could not publish the code. Did you mean any of it or just because of the IP cores? If possible, I'd be interested on having a look at add_qsys_system, even if a full working example is not available.
Dominic
@abaebae
Hi, I tried to use the VUNIT_TEST_OUTPUT_PATH_MARGIN option to reduce the path length. The paths are shortened, but Riviera has a problem with the shortened path. It runs in loop and does not recover. Using VUNIT_SHORT_TEST_OUTPUT_PATHS works fine.
1138-4EB
@1138-4EB
@abaebae, that sounds like a possible bug, but I am not familiar with those options. Would you mind opening an issue? Just C&P your message. That will allow us to better track a fix.
Dominic
@abaebae
@1138-4EB, sure see #605 .
Dominic
@abaebae
How can I change the output of a check_equal from a binary format to hex?
Lars Asplund
@LarsAsplund
@abaebae You can't. The idea is that it should be fairly easy to convert to hex since the binary format is divided into nibbles.