Closed KevinKes closed 7 years ago
This doesn't answer your problem, and in fact I think it suggests what you are trying to avoid.
I have taken the practice of assuming only libraries that are available with a simulator by default installation (ieee, std, etc) are available when setting up a project. Every project is then responsible for mapping their required libraries into their own simulation environment with no assumption of a pre-configured environment (other than the simulator tool is available).
This allows different projects with different library version dependencies to use the same base simulation environment, by pushing the work of "Bring your own dependencies" to all the projects that use the environment. Since I also version control my simulation library dependencies, getting the simulation environment for a project setup at build/simulation time is a straightforward process of mapping libraries in version control.
That said, even with this approach, I think your suggestion may still be important to consider. If there are libraries that have been mapped into the global library list of the simulator environment (whatever the reason), then VUnit should be able to find out about it, and not emit a warning if those global libraries are not explicitly added later (regardless if they are standard libraries such as ieee
or not).
@KevinKes So your problem is only that VUnit warns about missing library references? The library is still found when compiling?
There are multiple possible actions here where more than one can be performed:
We can add a method to the public API to ask for the simulator installation prefix which VUnit already knows about. This makes it easier for the run.py script to add installed libraries relrative to the installation prefix.
We can add a public method of library names to ignore when issuing a missing reference warning like with external libraries.
We can let the simulator interfaces automatically detect what libraries are already installed and automatically disable warnings for those.
I should also say that like @joshrsmith mentions it is good to not depend to much on the environment, ideally a verification script should be able to run from a freshly installed computer using just the contents of the version control repository to ensure reproducability.
@kraigher Yes, that is indeed my only problem.
Regarding the actions you propose:
for library_name in mapped_libraries:
library_dir = mapped_libraries[library]
project.add_library(library_name, library_dir, is_external=True)
I also agree with @joshrsmith about reproducability. In our situation we provide the (combined Vivado and ISE) precompiled xilinx libraries together with the modelsim installation in a zipfile. Each developer (or build PC) extracts these libraries into a convenient location and adepts the default modelsim.ini accordingly after the installation. With this approach we don't need to store the precompiled libraries itself in version control. Also Sigasi and VUnit both use the default modelsim.ini as a base, meaning we don't have to fiddle around with libraries and paths in the modelsim.ini for each project.
I think method 3 is reasonable to implement for both ModelSim, RivieraPro and Active-HDL.
I currently plan to make this feature non-default. That is that the user has to explicitly request to add the installed libraries. Default should be independence. I will probably add a public method such as add_simulator_builtin_libraries
The modelsim installation comes with pre compiled libraries (e.g. ieee, std, vital2000, etc) and it can also contain other pre compiled libraries (in my case all xilinx libs).
I don't like to use
add_external_library
from the VUnit api to make the simulator libraries known to VUnit, because then I don't like to duplicate the modelsim library administration by hand and synchronize all the paths on all build PCs.When not using the
add_external_library
, VUnit prints a warning in the console because it cannot find the depending library. This is not a big deal but it adds a lot of confusing warning messages to the console.I suggest that VUnit adds the known simulator libraries to the internal VUnit project. The
ModelSimInterface
already knows which simulator libraries are configured via the ini file. It seems that ModelSimInterface.setup_library_mapping can be updated to add the simulator libraries to the internal VUnit project.What do you think?