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.
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"
Unfortunately, I think that podman is not supported by x11docker yet.
@bradleyharden, see you!
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.
There is no need to install VUnit, you can just set the PYTHONPATH
But that is a very stable dependency, it can be added to the docker image
For example:
https://vunit.github.io/py/vunit.html#library
vs
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'
@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?
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.
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:
- Add doc sources, the website as a tarball, and or a PDF, to the PyPI package.
- Add any of them to the GitHub Releases in vunit/vunit (which is currently empty except for the changelog that we copy manually, https://github.com/VUnit/vunit/releases).
- Tag specific commits in vunit/vunit.github.io after the tags we push to vunit/vunit.
- Add any of the artifacts to the GitHub Releases in vunit/vunit.github.io.
- Use a different theme or build tool for Sphinx that allows to handle multiple versions of the docs ala RTD. I'm currently working sporadically on this:
Currently, users can:
- Clone the tags from vunit/vunit and execute
tox -e py38-docsto 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.
@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.
@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. :-)
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?
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?
@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.
@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.
