Jim Lewis

[Jim Lewis]

Hi Marvin,
What Avalon MM capability are you looking for? Basic access is easy – registers. The curious and clever pipelining modes looked challenging when I looked at the interface. If you could enumerate what you need, it may break it loose.

Currently I am tied up working on Questa scripts due to their decision to make numerous non-backward compatible changes and have different variants in different tool versions (Questa Classic vs QuestaOne). I think I will wrap up on that shortly.

If you would like Avalon MM prioritized, you could fund its development. Part of my concern is investing in an interface that Altera is gradually replacing with AXI – I was actually expecting them to do that more quickly.

Best Regards,
Jim

[Jim Lewis]

Hi Francois,
Look at package OsvvmLibraries/Common/src/StreamTransactionPkg.vhd and see StreamRecType.
Note that each type in there is either a special type from OSVVM’s ResolutionPkg (see OsvvmLibraries/osvvm)
or by creating a custom resolution function, as was done for the enumerated type, StreamOperationType,
that was defined in the package. Use what was done in this package as a template.

Note AddressBusTransactionPkg.vhd is very similar.

Best Regards,
Jim

[Jim Lewis]

Hi Francois,
The VC in the OSVVM library use either osvvm_common.StreamTransactionPkg.StreamRecType (for send and get type transactions – used by UART, AxiStream, xMii) or osvvm_common.AddressBusTransactionPkg.AddressBusRecType (for read and write type transactions – used by Axi4Manager, Axi4Memory, DpRam, WishboneManager, WishboneSubordinate).

You can access either one using
`
library osvvm_common ;
context osvvm_common.OsvvmCommonContext ;
`

A testbench for a counter may only need directive transactions, for which either record will work.
You can create your own record. Use those packages as an example if you like.

Best Regards,
Jim

[Jim Lewis]

If the CoverReport process is removed, then the “Stim” process can end with std.env.stop – which is typically how OSVVM ends the test cases.

-- Stimulus Generator
Stim: process
    variable RandA : RandomPType;
    variable RandB : RandomPType;
    variable allDone : boolean := false;
    variable nCycles : natural := 0;
begin
    SetTestName("tb_osvvm_comparator_VHDL");    
    SetLogEnable(INFO, TRUE);
    SetLogEnable(PASSED, TRUE);

    RandA.InitSeed(RandA'instance_name);
    RandB.InitSeed(RandB'instance_name);

    while not allDone and (NOW < 1 ms) loop
        A <= RandA.Randslv(0, 3,2);
        B <= RandB.Randslv(0, 3,2);
        wait for OP_DELAY;

        allDone := cp_A_B.isCovered;
        nCycles := nCycles + 1;
    end loop;

    wait for 1 ns;
    log("Number of simulation cycles = " & to_string(nCycles));
    AffirmIfEqual(CountCovHoles(cp_A_B), 0, "Coverage holes") ;

    EndOfTestReports(
      ReportAll => TRUE,
      ExternalErrors => (0, 0, 0),
      Stop => FALSE,
      TimeOut => FALSE
    );

    std.env.stop ;
    wait;
end process;

When the stimulus generation gets more complex than this, I will move the OSVVM runner stuff to separate process called “ControlProc”, but that is not necessary in a simple test case like this one.

[Jim Lewis]

One final thing to try. If you like the Alert/AffirmIf printing, you might also like the log printing better than the vhdl Report statement. In the “Stim” process you could change these to logs:

   log("Number of simulation cycles = " & to_string(nCycles));
    log("Coverage holes: " & to_string(CountCovHoles(cp_A_B)));

Logs have levels. These are level ALWAYS, which like report always print. You could give them a level and make them print only when enabled. But here ALWAYS is probably appropriate.

You could also make it a requirement that the Coverage holes is zero by doing the replacing the log for CountCovHoles with:

AffirmIfEqual(CountCovHoles(cp_A_B), 0, "Coverage holes") ;

AffirmIfEqual is a short hand for what you were doing with AffirmIf. Your AffirmIf could be updated as follows with AffirmIfEqual. This will add the word “Actual” before the first value, but otherwise, it is the same as your output.

AffirmIfEqual(A_less_B, expected_less, "A_less_B");

[Jim Lewis]

This step is recommended, but not required. Do it after you get the above running.

To get the HTML based Functional Coverage reports, you need to use the singleton rather than the older, deprecated shared variable approach.

This requires updating your architecture declarations, “InitCoverage”, “Sample”, and “CoverageReport” processes as follows. I would also recommend that you put your “InitCoverage” in the same process as “Sample”.

architecture Behavioral of tb_osvvm_comparator_VHDL is
------------------------------------------------------
--Coverage IDs
signal cp_A    : CoverageIDType;
signal cp_B    : CoverageIDType;
signal cp_A_B  : CoverageIDType;

begin

------------------------------------------------------
-- Coverage Bin Setup
InitCoverage: process
begin
    cp_A <= NewID("cp_A") ; 
    cp_B <= NewID("cp_B") ; 
    cp_A_B <= NewID("cp_A_B") ; 
    wait for 0 ns ; -- since cp_A, ... are signals 
    AddBins(cp_A, GenBin(0, 3));
    AddBins(cp_B, GenBin(0, 3));
    AddCross(cp_A_B, GenBin(0, 3), GenBin(0, 3));
    wait;
end process;

------------------------------------------------------
-- Sampling Coverage
Sample: process
begin
    loop
        wait on A, B;
        wait for 1 ns; -- not needed.  A and B are updated.  Output not necessarily stable, but not looking at it so OK.
        ICover(cp_A, to_integer(unsigned(A)));
        ICover(cp_B, to_integer(unsigned(B)));
        ICover(cp_A_B, (to_integer(unsigned(A)), to_integer(unsigned(B))));
    end loop;
end process;

------------------------------------------------------
-- Report Coverage
CoverReport: process
begin
    wait until STOP;
    report "A Coverage details";
    WriteBin(cp_A) ;
    report "B Coverage details";
    WriteBin(cp_B) ;
    report "AxB Coverage details";
    WriteBin(cp_A_B);
    report "Coverage holes: " & to_string(CountCovHoles(cp_A_B));
    ReportAlerts;
end process;

Note, I have not tested this code, so there may be some typos. Found one and fixed it WRT CountCovHoles.

Note that the “CoverReport” process is not really needed since now you have HTML reports that are much better than the text reports produced by WriteBin. The only thing that may be interesting is the report at the end of the “CoverReport” process. In the first step, I moved this to the end of the “Stim” process – this one also needs updated to:

    report "Coverage holes: " & to_string(CountCovHoles(cp_A_B));

[Jim Lewis]

This step is recommended, but not required. Do it after you get the above running.

While I SetTestName, SetLogEnable can be called concurrently, it is more normal to call them in the process that is controlling the overall test. Currently this is the “Stim” process but we will return to this:

Stim: process
    variable RandA : RandomPType;
    variable RandB : RandomPType;
    variable allDone : boolean := false;
    variable nCycles : natural := 0;
begin
    SetTestName("tb_osvvm_comparator_VHDL");    
    SetLogEnable(INFO, TRUE);
    SetLogEnable(PASSED, TRUE);

    RandA.InitSeed(RandA'instance_name);
    RandB.InitSeed(RandB'instance_name);

[Jim Lewis]

Thanks for posting your whole testbench as it makes the issue clear.

You are calling EndOfTestReports concurrently. So it runs at time 0 ns. You do not want it to run until your test case has finished. Same goes for WriteAlertYaml and WriteAlertSummaryYaml. However, you do not need to call these or ReportAlerts as they are all called by EndOfTestReports.

So a quick fix is to update your stimulus process as follows:

-- Stimulus Generator
Stim: process
    variable RandA : RandomPType;
    variable RandB : RandomPType;
    variable allDone : boolean := false;
    variable nCycles : natural := 0;
begin
    RandA.InitSeed(RandA'instance_name);
    RandB.InitSeed(RandB'instance_name);

    while not allDone and (NOW < 1 ms) loop
        A <= RandA.Randslv(0, 3,2);
        B <= RandB.Randslv(0, 3,2);
        wait for OP_DELAY;

        allDone := cp_A_B.isCovered;
        nCycles := nCycles + 1;
    end loop;

    wait for 1 ns;
    report "Number of simulation cycles = " & to_string(nCycles);
    report "Coverage holes: " & to_string(cp_A_B.CountCovHoles);

    EndOfTestReports(
      ReportAll => TRUE,
      ExternalErrors => (0, 0, 0),
      Stop => FALSE,
      TimeOut => FALSE
    );

    STOP <= true;
    wait;
end process;

Try that, that should get you running.

[Jim Lewis]

Hi Charlie,
What I suspect you are doing is that in the checker model you have created your requirements as follows:

Req1ID <= NewReqID("Req1", 1, ...) ; 
Req2ID <= NewReqID("Req2", 1, ...) ; 

When the build finishes with one or more tests that use this checker module is that the requirements are merged into the final report. However, that report also has the items that it merged together.

With the merged results, how should the requirements goal be tabulated? The default behavior (because of history) is to take the highest requirement level and use this as the total requirement goal. This requires that we merge the requirement specification into the merged requirements report. The other behavior is to sum the coverage goals from each test case to formulate the total goal for that requirement.

These behaviors are controlled by Tcl setting named USE_SUM_OF_GOALS. Its default is in Scripts/OsvvmSettingsDefault.tcl. You override it by creating an OsvvmSettingsLocal.tcl. See Documentation/OsvvmSettings_user_guide.pdf for details on what directory OsvvmSettingsLocal.tcl goes in.

You can also change the setting for a particular build by doing the following in your *.pro script:
set ::osvvm::USE_SUM_OF_GOALS "true"

If you want the requirements to be handled separately, you need to give them different names. If you are running with OSVVM scripts, you should already be setting the test name in the Control process of the test sequencer:

architecture T1 of TestCtrl is
 . . .
begin
  ControlProc : process 
  begin
    SetTestName("T1") ;  -- make sure this is done before any wait statements
    . . . 

Then in your checker model you can do:

wait for 0 ns ;   -- make sure TestName is set before reading it
Req1ID <= NewReqID(GetTestName & ".Req1", 1, ...) ; 
Req2ID <= NewReqID(GetTestName & ".Req2", 1, ...) ; 

This now will give you unique test requirements for each test case.

Note that by default, if a requirement in a given test case does not reach its goal, the test fails with an error.

Best Regards,
Jim

[Jim Lewis]

Hi Isaac,
I think Patrick’s solution will be the defacto solution for integration with VUnit. Particularly since he is working on generating reports too – really cool.

Before I talked to Patrick today, I worked on the script I mentioned above. For each OSVVM library, it will create a list of files associated with the library. Note the file list may be be different for different simulators since there are files with work arounds for particular simulator issues.

Run this by starting up your simulator with the OSVVM scripts, per the OSVVM Script_users_guide.pdf in the OsvvmLibraries/Documentation directory. For Questa, ModelSim or Riviera-PRO, all you do is:
source <path-to-OsvvmLibraries/OsvvmLibraries/Scripts/StartUp.tcl

Then do:
source $OsvvmLibraries/Scripts/VendorScripts_CompileList.tcl

And then run the OSVVM Scripts (takes only seconds):
build $OsvvmLibraries

You will find the scripts in files named: _.files.

You will find VendorScripts_CompileList.tcl on the dev branch of OsvvmLibraries.

Best Regards,
Jim

[Jim Lewis]

Hi Isaac,
From time to time, the OSVVM compile scripts are updated. It is hard to maintain more than one approach. The reason we developed the OSVVM scripts is to provide a better reporting mechanism. In addition the the ordinary JUnit reports, OSVVM does a more comprehensive Build summary. We also do test case summaries, functional coverage reports, requirements tracking, detailed alert reports, scoreboard reports, … and all of this is automatic.

The effortless way to work with another flow is to build OsvvmLibraries with the OSVVM pro scripts and then link the libraries into the other methodology. Unless you are editing things in the OsvvmLibraries, you can compile it once and use the library as a resource library.

The good thing about tcl is it is already there – either in the tool gui, or if you are running in Linux, it is available in the standard installs of the OS.

I don’t use VUnit, is there a compile script format for VUnit? The low level of OSVVM scripting, VendorScripts_***.tcl is adaptable and it should be easy to create one that generates VUnit compile scripts – rather than compiling the design.

Best Regards,
Jim

[Jim Lewis]

Hopefully I answered this in: https://osvvm.org/forums/topic/issues-with-ghdl-when-compiling-osvvm-packages

[Jim Lewis]

Are you running a current version of GHDL? Our github actions run with GHDL every day. See: https://github.com/OSVVM/OsvvmLibraries/actions

Did you use the directions in OsvvmLibraries/Documentation/Scripts_user_guide.pdf?

Here they are:
GHDL in Windows
~~~~~~~~~~~~~~~~

Initialize the OSVVM Script environment by doing:

   winpty tclsh
   source <path-to-OsvvmLibraries>/OsvvmLibraries/Scripts/StartUp.tcl

To simplify this, put source /OsvvmLibraries/Scripts/StartUp.tcl
in the .tclshrc file and add a windows short cut that does
C:\tools\msys64\mingw64.exe winpty tclsh.

GHDL in Linux
~~~~~~~~~~~~~~~~

Initialize the OSVVM Script environment by doing:

   rlwrap tclsh
   source <path-to-OsvvmLibraries>/OsvvmLibraries/Scripts/StartUp.tcl

To simplify this, put source /OsvvmLibraries/Scripts/StartUp.tcl
in the .tclshrc file and in bash add alias gsim=’rlwrap tclsh’ to your .bashrc.

Once you have done these, you build OsvvmLibraries by doing:

build $OsvvmLibraries/OsvvmLibraries.pro

Compiling the whole OsvvmLibraries in GHDL takes less than 60 seconds.

[Jim Lewis]

You need XSIM if you are using Xilinx’s encrypted IP. However XSIM is very slow.

GHDL and nvc both support OSVVM well – however they need a third party waveform viewer such as SURFER.

OSVVM is updated several times each year. Even if a simulator includes an OSVVM release, it may be out of date.

OSVVM is fast to compile the project. Just start the scripts and then build $OsvvmLibraries. For all simulators except XSIM this takes less than a minute

For more on running OSVVM scripts see OsvvmLibraries/documentation

[Jim Lewis]

You need OSVVM 2025.02 (or newer) and XSIM 2024.2

[Author]

Posts