-
Notifications
You must be signed in to change notification settings - Fork 255
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Building VUnit's verification components and OSVVMLibraries at the same time #767
Comments
You could include OsvvmLibraries as a submodule. Can python execute foreign languages such as TCL? If so, then you could use the OSVVM compile scripts to build the libraries - although currently we are not auto-detecting Synopsys VCS, Cadence Xcelium, or Xilinx XSIM - so you would need to invoke them through their vendor specific startup. Note I am not saying you should do this, but if you did do this, I would be happy to collaborate and make adjustments so things come together. |
@JimLewis (re)using the This specific issue is about the conflicts because VUnit does have one version of OSVVM, which is a dependency of some of VUnit's libraries; and at the same time some users might want to use a different version of OSVVM. It is unrelated to how OSVVM libraries are built (OSVVM's scripts, GHDL's scripts or a plain VUnit run file); this is rather about what is done first and how to skip an internal step in VUnit's builtins management.
I do not have any objection to Option 1 (submoduling OSVVMLibraries instead of just OSVVM). If @LarsAsplund agrees with it, I'd be happy to see that collaboration. Lines 133 to 178 in da8eb0a
This collaboration scheme is interesting for other areas as well: report merging, passing a runner generic to OSVVM tests, etc.
That's so nice to hear! ❤️
So, I'm creating the following tests in OSVB:
NOTE: "Before" means using the OSVVM shipped with VUnit plus OSVVMLibraries retrieved "externally". Conversely, "After" means ignoring the OSVVM shipped with VUnit and using all externally retrieved OSVVMLibraries. |
@umarcor @JimLewis I would go with option 2 because we shouldn't create more dependencies than needed and OSVVM is the only real dependency, All other libraries, whether they are part of OSVVMLibraries, UVVM, UVM or something else, should be possible to use together with VUnit although they are not shipped together. That's why #754 needs to be fixed. I would also consider checking for new OSVVM releases in our CI as a reminder to bump to the latest version |
I added 10
Those are all equivalent. The target testbench is Currently:
Apart from all these VUnit based Python scripts, the same subdir contains a All the scripts are tested in CI: https://github.com/umarcor/osvb/actions/workflows/Test.yml
@LarsAsplund https://dependabot.com/ was an external service, which GitHub bought some months ago: https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/about-dependabot-version-updates. Adding a |
@umarcor Are you doing option 2 or 3 now? depandabot looks nice but if it doesn't support non-semver versioning we can always write a script manually that handles OSVVM's year.month[patch] |
@LarsAsplund, it's technically Option 3, because the |
@umarcor Well, it doesn't really matter that much. If it's already in OSVB we better keep that as the single source. As long as we have an example we can direct people to. |
It seems that dependabot does not support the functionality we need: dependabot/dependabot-core#1639. We'd better write our own script. I believe it should check all the submodules (OSVVM and JSON-for-VHDL). @Paebbels, does https://github.com/paebbels/pyversioning allow to parse/get data from submodules? |
The intension of pyVersioning is to extract version and meta information from:
to provide variables and templates, so these variables can be "printed" into files. One example is to gather:
to translate it into a C file, so it can be compiled and linked into a project. Another usecase is to write information to a VHDL oder *.mem file to it can be translated into a read-only AXI4-Lite register. In case of an Xilinx MPSoC, software can now print version information of the used PL firmware and even reject execution on a PL that doesn't offer matching interfaces based on the version number (semantic version). In addition, it is planned to also search submodules and other dependencies and integrate these information into the C or VHDL files. This would allow to see (and print) a Xilinx MPSoC what IP cores are used in what version/hash, ... In general, somewhen such information would be available and we could think about using that data for other purposes. So I think, pyVersioning is currently not offering what you ask for, but it would be in the scope. |
@LarsAsplund The |
FTR, in #946 (comment) @Blebowski reported using VUnit and NVC with OSVVM precompiled with NVC. In the context of this issue, that's equivalent to the "GHDL's vendor scripts" solution. |
This is an spin-off coming from #754. That issue is about using OSVVMLibraries in VUnit, after compiling them externally (using OSVVM's
.pro
files, GHDL's vendor scripts or any other solution). It also covers builting OSVVMLibraries in arun.py
script, while disabling (not building) VUnit's verification components. This one is a complementary issue to discuss how to actually build VUnit's verification components and OSVVMLibraries at the same time.@LarsAsplund, that's an interesting question. Yes, it needs to work, meaning it is technically possible and not complex to achieve for someone experienced with both VUnit and OSVVM. However, it is not easy to understand for an arbitrary newcomer.
.pro
files (tclsh).run.py
file (python).OSVVM's
.pro
files and VUnit'srun.py
file can handle OSVVM 2021.09, but GHDL's vendor scripts were not updated yet, so they require OSVVM 2021.06 (see ghdl/ghdl#1900). Therefore, the default CI in OSVB is using OSVVM 2021.06 at the moment: https://github.com/umarcor/osvb/tree/main/mods. In that context, mixing VUnit's OSVVM core (2021.09) with the submoduled OSVVMLibraries (2021.06) is likely to crash. Hence, I had to do several modifications:run.py
script to addVU.add_verification_components()
and not to add lib OSVVM manually.This is the set of changes compared to the previous test: https://github.com/umarcor/osvb/compare/bump-osvvm?expand=1
The CI result is the same using this approach or the previous one.
As of today, the maintenance and usage burden is as follows:
vunit/vhdl/osvvm
and keep_add_osvvm()
in sync with the exceptions (*_Aldec.vhd
,*_c.vhd
) in OSVVM.We can do better, in the sense of reducing our maintenance effort, and making it easier for users to consume VUnit and OSVVMLibraries together.
Option 1: let VUnit submodule OSVVMLibraries instead of OSVVM (avoiding 2). We can keep building OSVVMLibraries/osvvm alone in
_add_osvvm()
and maybe provide an additional_add_osvvm_libraries()
(which would avoid 3). The advantage of this approach is the ease of transition from the current codebase (just change the submodule and add a function to VUnit's API). It would also make the VUnit-OSVVM collaboration very explicit. However, the disadvantage is scalability: we cannot follow this approach with all third-party projects, nor recommend it as a general solution for companies to extend VUnit with their own libraries.Option 2: let VUnit check if library OSVVM was declared/added before executing
add_verification_components
. Users might use different approaches to actually install OSVVM:.pro
files (as reported by the OP), or GHDL's vendor scripts; then declare the libraries as external in VUnit.add_library
andadd_source_files
to declare all the OSVVM libraries retrieved/downloaded to any location. That is: https://github.com/umarcor/osvb/blob/6958c2281044d494bfa543069f2b9f1f8c1f089d/AXI4Stream/test/osvvm/run.py.Then,
add_verification_components
would be executed, which would not build the internal OSVVM, because it can see that the library name exists (either regular or external). The main advantage of this approach is that users can install any version of OSVVM they want; they can reuse a pre-compiled version, or they can build it per-script (as it is usual for VUnit's builtins). The main disadvantage is the same: users can install any version of OSVVM, which might not be compatible. However, I don't think this is critical, because VUnit does not have any strong dependency on any weird API feature of OSVVM; i.e. almost any OSVVM version should be valid for the random features required in VUnit.From a technical point of view, the content of the
run.py
in Option 2 would be the same as the content of_add_osvvm()
and_add_osvvm_libraries()
in Option 1. That means we can have Option 2 implemented as a VUnit example. That would keep the snippet close to the VUnit repo, but not part of vunit_hdl codebase.Option 3: the same as Option 2, but keeping the
run.py
snippet somewhere else (say OSVB or OSVVM), instead of the VUnit repo.Overall, note that this is a particular case because VUnit depends on some OSVVM features, but not all of them. Therefore, we need to have a fallback solution that builds OSVVM's core automatically for less experienced users, while we want to allow flexibility for intermediate and advanced users. That's why I think that Options 2 or 3 are desirable.
I can help testing the approaches in ghdl/extended-tests, here and in OSVVM's CI. Each of them would test a different solution.
/cc @JimLewis @Paebbels
The text was updated successfully, but these errors were encountered: