Regarding breaking IEEE library, it has something to do with how VUnit adds its own OSVVM version to the "work" lib.
VUnit does never add OSVVM, or any other resource to the "work" lib. If that is happening, it's a misconfiguration or a bug.
VUnit's add_osvvm adds OSVVM to library OSVVM.
The vunit_osvvm script from OSVB (https://github.com/umarcor/osvb/blob/main/AXI4Stream/test/osvvm/vunit_osvvm.py) adds resources to libraries OSVVM, OSVVM_Common and OSVVM_AXI4.
By definition, a library named "work" cannot be used. Even though some vendors/simulators support it, it should never be done.
no, I read what you wrote in OSVB, I removed add_osvvm and instead had this:
So, let's step back. What do you want to achieve? Tell something such as "I am want to compile OSVVM's core and use the Scoreboard in a VUnit testbench", or "I want to compile OSVVMLibraries and use OSVVM's AXI VCs".
Or are you taking an OSVVM testbench as a foundation?
Don't worry about the
run.py or how to install/build VUnit/OSVVM. I just need the testbench file.
As Jim commented, I've been lately looking into the details of how to combine OSVVMLibraries and VUnit. There are some corner cases, but your use case should be supported already. Since the Scoreboards are part of OSVVM's core, you don't need to download OSVVM on your own, nor use OSVB's scripts. Just using VUnit's
add_osvvm alone should suffice. Nevertheless, I'm willing to understand what's the problem you are hitting.
Hold on a sec! This was merged after v4.6.0! VUnit/vunit@3a81795
Maybe that's causing your problem. Check the commit SHA of the VUnit version you are using. It needs to be from the last 7 days. If it's 9 days old, it's too old.
Maybe that's causing your problem. Check the commit SHA of the VUnit version you are using. It needs to be from the last 7 days. If it's 9 days old, it's too old.
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
library OSVVM ;
context osvvm.OsvvmContext ;
library vunit_lib;
context vunit_lib.vunit_context;
entity mwe_tb is
generic (runner_cfg : string);
end entity mwe_tb;
-- Error: tb_mwe.vhd:16:1: no declaration for "osvvm"
-- package ScoreBoardPkg_slv is new
-- OSVVM.ScoreboardGenericPkg generic map(
-- ExpectedType => std_logic_vector,
-- ActualType => std_logic_vector,
-- Match => std_match,
-- expected_to_string => to_hstring,
-- actual_to_string => to_hstring
-- );
-- Error: tb_mwe.vhd: failed to find a primary design unit 'scoreboardgenericpkg' in library 'lib'
package ScoreBoardPkg_slv is new
work.ScoreboardGenericPkg generic map(
ExpectedType => std_logic_vector,
ActualType => std_logic_vector,
Match => std_match,
expected_to_string => to_hstring,
actual_to_string => to_hstring
);
architecture tb of mwe_tb is
begin
main_proc : process begin
test_runner_setup(runner, runner_cfg);
if run("test1") then
--noop
end if;
test_runner_cleanup(runner);
end process;
test_runner_watchdog(runner, 1 ms);
end tb;
--clean did not improve anything, but maybe you can see in the MWE above if I've done anything really silly :)
Just reorder the content in your testbench file:
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
library OSVVM ;
context osvvm.OsvvmContext ;
package ScoreBoardPkg_myslv is new
OSVVM.ScoreboardGenericPkg generic map(
ExpectedType => std_logic_vector,
ActualType => std_logic_vector,
Match => std_match,
expected_to_string => to_hstring,
actual_to_string => to_hstring
);
library vunit_lib;
context vunit_lib.vunit_context;
entity mwe_tb is
generic (runner_cfg : string);
end entity mwe_tb;
architecture tb of mwe_tb is
begin
main_proc : process begin
test_runner_setup(runner, runner_cfg);
if run("test1") then
--noop
end if;
test_runner_cleanup(runner);
end process;
test_runner_watchdog(runner, 1 ms);
end tb;
This is the run script I used:
#!/usr/bin/env python3
from pathlib import Path
from vunit import VUnit
ROOT = Path(__file__).parent
VU = VUnit.from_argv()
VU.add_osvvm()
VU.add_library("lib").add_source_files([ROOT / "tb_apanella.vhd"])
VU.main()
Feel free to reach if you have further issues combining VUnit and OSVVM.
I think VUnit doesn't support .awc file under using Riviera-PRO simualtion tool.
Does anyone know how to load waveform file using Riviera-PRO?
I am trying to run the /VUnit/vunit/blob/master/vunit/vhdl/verification_components/test/tb_axi_lite_master.vhd (I have my own master instantiated in the TB) and I am always getting a failure due to "core_pkg.vhd line 84". It has something to do with the mock() and unmock() procedures. Commenting them out but that does not help. Where can I gain some extra insight regarding these mock() and unmock() so that I can understand the failure better?
@dpaul24 You can read more about mocking here: http://vunit.github.io/logging/user_guide.html#mocking
@umarcor @LarsAsplund > From what I have learnt up to now, multiple test-cases can be defined inside a VUnit TB using the run() procedure. The string depicting the test-case name inside the run("...") should not contain blank spaces, e.g. run("Test_single_write") is the correct way. In such a situation if the command py run.py <library_name_set>.<testbench_name_set>.<test-case-name_set> -v can be used to run selective test-cases. However if some uses run("Test single write"), using blank spaces within the string, then run.py will ignore that particular test-case.
Can anyone of your please confirm the above?
I mean VUnit will not throw an error when run("Test single write") is used, but if blank spaces is used within the string, then that particular test-case cannot be selectively run.
py run.py '<library_name_set>.<testbench_name_set>.<test-case-name_set>' -v
That's annoying but standard terminal/shell behaviour.
Either use no blank spaces or use quotes "....".
@dpaul24 In the early days of VUnit, prior to the first public release, we had internal discussions about test case naming. Whether we should have arbitrary strings or restrict ourselves to identifier naming rules. SW unit test frameworks typically have identifier rules so there is a familarity with that. However, in the typical unit testing framework the test case is represented by a method or a function in which case naming is limited. To allow naming strategies that are very verbose, for example those promoted by BDD, we decided to go for an approach that allows for natural language naming. Some people still prefer identifier naming but VUnit doesn't impose such restrictions.
cool, I have seen this post: https://vunit.github.io/blog/2017_06_03_enable_your_simulator_to_handle_complex_top_level_generics.html