Cannot use externally compiled OSVVM as external library

[as266]

Hi,
I am unable to use an externally compiled version of OSVVM as an external library. This includes the base osvvm library, but also other OSVVM libraries that are not distributed with VUnit (specifically the osvvm_axi4 library).

When running the run.py script it seems to successfully add the external libraries, but then errors when it comes to compile the testbench that uses the library:
COMP96 ERROR COMP96_0059: "Library "osvvm" not found."

This only seems to be a problem with OSVVM libraries; other external libraries work fine. This error also disappears if vu.add_osvvm() is used instead of trying to use the external library, but a similar error is still present for other OSVVM external libraries:
COMP96 ERROR COMP96_0059: "Library "osvvm_axi4" not found."
Including both add_osvvm() and the external library predictably results in a name clash when run.py is run:
ValueError: Library osvvm already exists

I am using:

• python 3.6.9
• vunit-hdl 4.5.0
• Riviera-PRO 2020.10

[LarsAsplund]

Can you provide the part of your run script adding OSVVM?

[as266]

@LarsAsplund

script_path = Path(__file__).parent.resolve()
osvvm_lib_path = script_path / ".." / "OSVVM"

vu = VUnit.from_argv()

vu.add_external_library("osvvm", osvvm_lib_path)
vu.add_external_library("osvvm_axi4", osvvm_lib_path)
vu.add_external_library("osvvm_common", osvvm_lib_path)
vu.add_external_library("osvvm_uart", osvvm_lib_path)

where osvvm_lib_path is the path to the directory containing the .mgf/.lib library files.

[as266]

It seems that the vmap command is failing for the OSVVM libraries and for some reason requires the filename of the .lib file to be included in the library path, not just the directory. This is not possible with VUnit, as if you try you get the following error:
ValueError: External library must be a directory.

I should probably also mention that I am using the OsvvmLibraries repository version 2021.02, and compiling using the OsvvmLibraries.pro script in that repository.

[as266]

The physical_name parameter of the vmap/amap command in Riviera-PRO requires either:

1. The path to the directory of the .lib file, where the file has the same name as the containing directory with the .lib extension
2. The path to the .lib file itself, with or without the .lib extension, the lib file and the directory name do not have to match

VUnit supports only 1), whereas OSVVM when compiled using the included scripts requires 2).

[JimLewis]

@LarsAsplund
OSVVM has will address this.

Intention

OSVVM intends for the VHDL libraries to be in subdirectories with the library name as part of the directory name.

What the simulator does

In Riviera-PRO, it appears when the intended library directory name is of the form "library.lib" it decides this is instead a file name.

OSVVM Resolution

I am in the process of testing a modification that drops the ".lib" extension from library directories. I should be pushing it to the dev branch shortly.

[LarsAsplund]

@JimLewis Great!

@as266 An option is also to compile everything from source

from glob import glob

osvvm = vu.add_library("osvvm")
osvvm_common = vu.add_library("osvvm_common")
osvvm_uart = vu.add_library("osvvm_uart")
osvvm_axi4 = vu.add_library("osvvm_axi4")

# Can't compile all OSVVM files since some depends on simulator. This compile everything except Cadence related files
osvvm_files = [file for file in glob("path/to/osvvm/*.vhd") if not file.endswith("_c.vhd")]
osvvm.add_source_files(osvvm_files)

# The rest are straight-forward
osvvm_uart.add_source_files("path/to/uart/src/*.vhd")
osvvm_common.add_source_files("path/to/common/src/*.vhd")
osvvm_axi4.add_source_files("path/to/axi/**/src/*.vhd")

When I update VUnit to latest OSVVM you can remove manual OSVVM compilation and just do add_osvvm() for that

[umarcor]

@LarsAsplund I tried that approach in https://github.com/umarcor/osvb/blob/main/AXI4Stream/test/osvvm/run.py.

• As far as compiling OSVVM sources is related, it works.
• It is incompatible with add_verification_components, because it depends on the internal com and osvvm. Maybe we should make the dependency optional, or skip it if the user adds the library before.
• I'm not sure about *_c.vhd being a sensible solution for filtering Cadence related sources. There are some *_Aldec.vhd which can be filtered using such approach; however, after discussing it with @Paebbels, we think that *_c.vhd might correspond to "constant packages", because Cadence does not support generic packages yet. I.e., it is not an explicit identifier for Cadence.
• Some of the .pro files do include others. For instance, the AXI4 library contains sources from multiple subdirs. That info needs to be manually read and understood by users.

A solution that involves reading .pro files is not straightforward, because multiple TCL features are used and we don't want to require a TCL interpreter in VUnit. However, I believe it would be sensible to have some script in OSVVM or pyEDAA.ProjectModel that translates the pro files to a different representation which is more friendly to read in VUnit. This is something I'm discussing with @Paebbels, since we need it in GHDL too. See #765.

[LarsAsplund]

@umarcor What happens if we have the latest OSVVM as a submodule and that is included with add_osvvm or add_verification_components and then just the rest are compiled manually. Wouldn't that work?

[umarcor]

@LarsAsplund, see #767.

[umarcor]

According to OSVVM/OsvvmLibraries#8, this should be fixed in the next OSVVM release. Let's keep this issue open in order to remember bumping the submodule.

[umarcor]

OSVVM 2021.10 was released. @JimLewis @as266 can you please confirm that both this issue and OSVVM/OsvvmLibraries#8 can be closed?

[JimLewis]

.lib extension is gone in 2021.10, however, I have not tested with VUnit.

[as266]

@umarcor, OsvvmLibraries release 2021.10 has fixed this issue