How to unlink/unset libraries without deleting them?

[KrzysztofZyla]

I have a simple example that looks like this:

workdir/ ├── Scripts ├── dir_a/ │ ├── dut.pro │ └── dut.vhd ├── dir_b/ │ ├── dut.pro │ └── dut.vhd └── run.do

Both "dut.pro" files have the same content:

library DutLib
analyze ./dut.vhd
simulate e

Both "dut.vhd" only print "A" or "B".

Macro "run.do":

source ./Scripts/StartUp.tcl

SetLibraryDirectory ./dir_a
build ./dir_a/dut.pro

SetLibraryDirectory ./dir_b
build ./dir_b/dut.pro

My intention was to create library "DutLib" for A in dir_a and "DutLib" for B in dir_b. I'm running Riviera-PRO from workdir. Results are as expected but it seems that in both cases the same library is used:

library DutLib (...)/workdir/dir_a/VHDL_LIBS/tool_ver

I thought that "SetLibraryDirectory ./dir_b" will make the second "build" command create the library in dir_b, but it seems that library names stored in variables like ::osvvm::LibraryList have priority over this. I don't want to delete the library in dir_a so procedures like "RemoveAllLibraries" don't solve the problem. My WA is to use below commands in "run.do":

if {[info exists ::osvvm::VhdlWorkingLibrary]} {
   unset ::osvvm::VhdlWorkingLibrary
}
if {[info exists ::osvvm::LibraryList]} {
   unset ::osvvm::LibraryList
}
if {[info exists ::osvvm::LibraryDirectoryList]} {
   unset ::osvvm::LibraryDirectoryList
}

Is there a simpler way/command to "unlink" libraries without deleting them?

[JimLewis]

There is not currently an UnlinkLibrary, UnlinkLibraryDirectory, or UnlinkLibraries that would handle this. These may be interesting to add. I would need to think about the use model.

If you change your simulation directory (cd), it automatically unlinks the libraries.

I need to think about what makes sense and what does not. It would not make sense to add UnlinkLibrar* if the test case results from the two separate projects were to collide with each other.

[JimLewis]

There is StartUp that will reload / reinitialize all of OSVVM scripting.

[KrzysztofZyla]

I have changed my macro "run.do" to:

source ./Scripts/StartUp.tcl

SetLibraryDirectory ./dir_a
build ./dir_a/dut.pro

source ./Scripts/StartUp.tcl

SetLibraryDirectory ./dir_b
build ./dir_b/dut.pro

and used

OSVVM Script Version:  2023.07

Still have the same problem. In both cases ("A" and "B") the same library is used:

.../dir_a/VHDL_LIBS/RivieraPRO/dutlib

(wanted "A" in dir_a and "B" in dir_b)

[JimLewis]

If I have the OSVVM libraries mapped to a separate directory, then simply unsetting the variables is not sufficient. Instead, library and/or library directory need to be considered and just those libraries removed from the list.

It would be easy to add an UnlinkLibrary and UnlinkLibraryDirectory that simply removes the libraries from the variables, but is that enough? Some simulator's perhaps the one(s) you are working with remember the libraries within their tool settings. What happens then when you map DutLib again and the tool already has a mapping for DutLib, is it going to be an issue?

I think to be safe, the OSVVM Unlink also needs to unmap each library. This too can be done. I will look at this when I look at some other items that are getting close to the top of my action list.

[JimLewis]

How are you managing the results files and keeping the results for dir_a and dir_b separate? If the test cases are named the same and the test suites are named the same, then you have a name conflict WRT your results files and they overwrite each other.

In the OSVVM library, we put separate test harnesses in separate libraries and separate test suites. This allows them to all have the same named test harness without having any conflicts. The results files are kept in a directory named ./results//.html. So we have library osvvm_TbAxi4 and a library osvvm_TbAxi4_VTI. This supports two very similar components whose main difference is how it connects to the test harness. By doing this, we are able to use the same test cases to test each variant of the verification component.

[JimLewis]

It would be easy enough to add a UnsetLibraryVars or give new libraries precedence over old ones. However, I suspect what really should have been done was to produce an error message if a library had two different mappings.

In fact, when I run a simulation in RivieraPRO, and I do vmap/amap of a library to the EXACT same library it is already mapped to, much to my chagrin, I get the message: ELBREAD: Warning: ELBREAD_0056 Library 'lib_memio' containing package 'MemIOPkg' referenced in the package 'MemIOTbPkg' has been remapped.

So RivieraPRO at least thinks of remapping libraries is a big enough concern that it issues a message - even when it is not change the library at all (a chase that I think is wrong).

[JimLewis]

I am trying to understand the methodology behind your question.

Why are you using the same library names for testbenches in different directories?

[KrzysztofZyla]

Why are you using the same library names for testbenches in different directories?

This problem occurred when I was checking the compatibility of Riviera-PRO and OSVVM scripts. I'm running a group of small "test" designs rather than "real" projects. The results overwrite each other but this is not an issue as I check the current one and move to the next case. On the other hand using (unintentionally) the same libraries for all cases may lead to incorrect results ( e.g. current "top" had compilation errors, but simulation will go on as previous "top" will be used). I found out that closing and opening Riviera-PRO between running test cases solves the problem. So I was thinking of an unlink or similar option to do it from the script level.

[JimLewis]

For the 2023.09 release (coming soon), I have made the procedure UnsetLibraryVars visible. You can use that when you intend to replace one LibraryDirectory with another.

It is possible too that we could change the current policy of do not change the mapping to change the mapping, but issue a warning.