VUnit / vunit

VUnit is a unit testing framework for VHDL/SystemVerilog
http://vunit.github.io/
Other
739 stars 263 forks source link

VUnit is not aware of the libraries added via the simulator config #218

Closed KevinKes closed 7 years ago

KevinKes commented 7 years ago

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?

joshrsmith commented 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).

kraigher commented 7 years ago

@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:

  1. 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.

  2. We can add a public method of library names to ignore when issuing a missing reference warning like with external libraries.

  3. 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.

KevinKes commented 7 years ago

@kraigher Yes, that is indeed my only problem.

Regarding the actions you propose:

  1. Getting the simulator prefix from VUnit works only if the relative path is exactly known and the same for all developers / build PCs.
  2. Not issuing a warning for a list of libraries seems fine to me
  3. In my opinion the best option, and can be implemented quite easily I think. I was thinking about adding a few lines to ModelSimInterface.setup_library_mapping
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.

kraigher commented 7 years ago

I think method 3 is reasonable to implement for both ModelSim, RivieraPro and Active-HDL.

kraigher commented 7 years ago

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