Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 21 20:18

    eine on master

    docs/about: fixed typo from "GD… (compare)

  • May 21 20:18
    eine closed #832
  • May 21 20:18
    eine milestoned #832
  • May 21 20:18
    eine labeled #832
  • May 21 20:18
    eine labeled #832
  • May 21 14:08
    std-max commented #824
  • May 21 13:40
    przemech reopened #832
  • May 21 13:39
    przemech closed #832
  • May 21 12:51
    przemech opened #832
  • May 20 08:09
    asicnet commented #808
  • May 20 08:07
    asicnet commented #808
  • May 20 08:04
    asicnet commented #808
  • May 20 07:42
    sibeov commented #741
  • May 19 19:10
    bewimm synchronize #799
  • May 19 17:08
    sibeov commented #741
  • May 18 13:01
    sudden6 edited #831
  • May 18 12:59
    sudden6 opened #831
  • May 18 04:54

    LarsAsplund on issue-833-type-generic-dict

    WIP: Added generic type support… (compare)

  • May 17 11:28
    umarcor ready_for_review #827
  • May 17 11:28
    umarcor edited #827
Unai Martinez-Corral
@umarcor
It might sound stupid, but remove vunit_out or use --clean, just in case.
Aaron Panella
@a-panella
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 :)
Unai Martinez-Corral
@umarcor
I can reproduce the:
1: no declaration for "osvvm"
OSVVM.ScoreboardGenericPkg generic map(
^
Unai Martinez-Corral
@umarcor
Oh my! @a-panella, you are instantiating the package below the entity declaration! Therefore the scope is empty! Of course it cannot see OSVVM, neither vunit_lib, nor IEEE.. nothing at all!
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()
Unai Martinez-Corral
@umarcor
Before you say anything, do not feel ashamed at all. That's a very very very common mistake we all do.
Aaron Panella
@a-panella
@umarcor RIP, thanks for noticing that, I will move it in my tb
Unai Martinez-Corral
@umarcor

Note that you then might need to make it visible below, in order to use it in the architecture:

use work.ScoreBoardPkg_myslv;

Actually, you can change the name back to the original.

Aaron Panella
@a-panella
Yeah okay that is the dumbest thing I've done iin a while, sorry for wasting your time with it
Unai Martinez-Corral
@umarcor
It's ok. It was little time, and it served as an excuse for you to read and try OSVB (even though it was not necessary in the end) :laughing:
Aaron Panella
@a-panella
Actually I wasn't aware of OSVB until you posted it yesterday, I will look into, it looks very useful :)
Unai Martinez-Corral
@umarcor
It's basically a place for gathering proofs of concept and examples about how to combine VUnit, OSVVM, cocotb, UVVM and SVUnit. Not a project per se, but a trigger for the frameworks/methodologies to work together.
Feel free to reach if you have further issues combining VUnit and OSVVM.
Aaron Panella
@a-panella
thanks, I will
deepnlights
@deepnlights
image.png
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?
Dominic
@abaebae
@deepnlights if you generate the file via Riviera-Pro Gui just use the option Save to Macro.... This will generate a wave.do file VUnit can source
Jim Lewis
@JimLewis
@a-panella @umarcor This is why I put package instances in a separate file by themselves - even though they are short. They are a design unit and they require their own set of package references.
deepnlights
@deepnlights
@abaebae It's working. I appreciate for your help!
dpaul
@dpaul24
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?
Lars Asplund
@LarsAsplund
@dpaul24 You can read more about mocking here: http://vunit.github.io/logging/user_guide.html#mocking
dpaul
@dpaul24
@LarsAsplund Thank you!
dpaul
@dpaul24
@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.
Unai Martinez-Corral
@umarcor
@dpaul24 you need to quote the test name in the CLI. Otherwise, the terminal (bash, powershell) is splitting the args, before reaching the tool (Python, VUnit).
py run.py '<library_name_set>.<testbench_name_set>.<test-case-name_set>' -v
That's annoying but standard terminal/shell behaviour.
dpaul
@dpaul24
@umarcor Ah ha! I got it now, thank you.
Either use no blank spaces or use quotes "....".
Lars Asplund
@LarsAsplund
@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.
Carlos Alberto Ruiz Naranjo
@qarlosalberto
is it possible to pass a dictionary as generic from run.py to ModelSim test?
Unai Martinez-Corral
@umarcor
@qarlosalberto check the json4vhdl example

You can pass the dictionary as string or as the path to a file. Optionally, you can encode the string:

TB.get_tests("stringified*")[0].set_generic("tb_cfg", JSON_STR)
TB.get_tests("b16encoded stringified*")[0].set_generic("tb_cfg", b16encode(JSON_STR))
TB.get_tests("JSON file*")[0].set_generic("tb_cfg", JSON_FILE)
TB.get_tests("b16encoded JSON file*")[0].set_generic("tb_cfg", b16encode(str(TEST_PATH / JSON_FILE)))

You only need one of those. The four of them are used in the example for illustration.

Carlos Alberto Ruiz Naranjo
@qarlosalberto
thanks!! :)
Unai Martinez-Corral
@umarcor
Encoding the strings allows working around the limitations that some simulators have when parsing non-trivial strings.
Hence, regardless of using JSON and JSON-for-VHDL, it is some to keep in mind.
Carlos Alberto Ruiz Naranjo
@qarlosalberto
it's a very useful example :D
dpaul
@dpaul24

Q> While running simulation using ModelSim, I am always getting the warning: " Warning: There is an 'U'|'X'|'W'|'Z'|'-' in an arithmetic operand, the result will be 'X'(es)." and I want to get rid of this warning. How can I do it?

What I did and is not working>

  1. In my run.py, I have added the following which fails to take effect...
    vu_prj.set_sim_option("modelsim.init_files.after_load", ["turn_off_some_warnings.do"])
    vu_prj.set_sim_option("modelsim.init_files.before_run", ["turn_off_some_warnings.do"])
  2. I have also tried using vu_prj.set_sim_option("disable_ieee_warnings", True, allow_empty=True) and this also fails to work.

Is there any other things I can try out from run.py?

Note that if I run the DO file turn_off_some_warnings.do at the ModelSim prompt before the run -all command then I get what I want to have.
Carlos Alberto Ruiz Naranjo
@qarlosalberto
ui.set_sim_option("modelsim.init_files.after_load", ["modelsim.do"])
works for me
Lars Asplund
@LarsAsplund
@dpaul24 You're using allow_empty=True. Is that because it didn't find any testbenches? Note that the sim option only applies to testbenches added before the sim option was set.
dpaul
@dpaul24

ui.set_sim_option("modelsim.init_files.after_load", ["modelsim.do"])

Well I am loading a waveform file, vu_prj.set_sim_option('modelsim.init_files.after_load', ["vunit_wave.do"]) and it works, so I am more confused why another DO is not taking effect correctly.

@dpaul24 You're using allow_empty=True. Is that because it didn't find any testbenches? Note that the sim option only applies to testbenches added before the sim option was set.

Well I did not give it much thought, I just think it would be safe to use the TRUE setting. btw - All my TBs are loaded I use vu_prj.set_sim_option("disable_ieee_warnings", True, allow_empty=True)