Jim Lewis

[Jim Lewis]

Hi Senthil,
This is now fixed on the dev branch of OsvvmLibraries on GitHub. You can get the dev branch by doing:

git clone --recursive --branch dev https://github.com/osvvm/OsvvmLibraries

Best Regards,
Jim

[Jim Lewis]

It is Simon doing the heavy lifting on the CoSimulation / C interface.

[Jim Lewis]

Hi Eamon,
Simon posted the blog post that hopefully answers your question. See: https://osvvm.org/archives/2830

Best Regards,
Jim

[Jim Lewis]

Hi Eamon,
Simon posted the blog post that hopefully answers your question. See: https://osvvm.org/archives/2830

Best Regards,
Jim

[Jim Lewis]

Hi Eamon,
I have asked Simon to post a response to this. Unfortunately the website is having some issues with Simon being able to post a response to it. Hopefully it will be resolved shortly.

Many apologies. We usually get these type of things answered within a day or two of the post.

Best Regards,
Jim

[Jim Lewis]

Hi Senthil,
I will have this fixed shortly on the dev branch.

Best Regards,
Jim

[Jim Lewis]

Hi Senthil
OutputHomeDirectory is not the correct variable to be setting.
Please use OutputBaseDirectory.

I have tested it with settings as follows. In both of these the results are in the $CurrentSimulationDirectory.
variable OutputBaseDirectory “”
variable OutputBaseDirectory “osvvm”

I have not tested it with other than these variations. I am testing it now, but have found at least one bug in the path. So for now you are limited to using either “” or “aDirectoryName”

Best Regards,
Jim

[Jim Lewis]

Hi Jon,
I recommend getting all of OsvvmLibraries. Then from the Script_user_guide.pdf, to start XSIM, do the following:

1.3.9 Xilinx XSIM
Using OSVVM in Xilinx XSIM is under development. So far, Xilinx seems to be able to
compile OSVVM utility library, however, we have not had any of our internal test cases
pass.
To run OSVVM scripts in XSIM, start Vivado and then run the StartXSIM using:
source <path-to-OsvvmLibraries>/OsvvmLibraries/Scripts/StartXSIM.tcl

Note that with XSIM 2024.2, OSVVM is working in XSIM. Since Vivado tools is such a large download,
I have not tested with a 2025 release yet. Soon.

Then Run the Demos (modified to just run AXI4):

1.4 Run the Demos
Do the following in your simulator command line:

build ../OsvvmLibraries
build ../OsvvmLibraries/AXI4/Axi4/RunDemoTests.pro

These will produce some reports, such as OsvvmLibraries_RunDemoTests.html. We will
discuss these in the next section, OSVVM Reports.

Best Regards,
Jim

[Jim Lewis]

Hi Senthil,
Settings have changed through time. What I say here pertains to the current release, 2025.06a. Typically I try to keep changes backward compatible – to the degree that they originally worked. Note that $OsvvmLibraries is a Tcl variable in the OSVVM Script environment (set by calling $OsvvmLibraries/Scripts/StartUp.tcl).

You will find a “how to” for OSVVM’s tcl and vhdl settings documented in OsvvmSettings_user_guide.pdf in OsvvmLibraries/Documentation. With respect to finding the settings files, it says:

6 OSVVM Settings Directory for VHDL and Script Settings
The OSVVM Settings Directory for VHDL and Script settings is found in the directory specified by joining the Tcl variables $SettingsRootDirectory, $SettingsDirectory, and $::osvvm::OsvvmSettingsSubDirectory.

The SettingsRootDirectory is $OsvvmLibraries. $OsvvmLibraries is the location of your OsvvmLibraries install. $OsvvmLibraries is a Tcl variable set by the scripts when started with $OsvvmLibraries/Scripts/StartUp.tcl.

The SettingsDirectory is determined by the first of the following found:
• Environment variable OSVVM_SETTINGS_DIR – (highest precedence)
• Directory $OsvvmLibraries/../OsvvmSettings
• Directory $OsvvmLibraries/osvvm for vhdl settings and $OsvvmLibraries/Scripts for script settings – (lowest precedence)

The OSVVM_SETTINGS_DIR variable can contain either an absolute path or a relative path. If OSVVM_SETTINGS_DIR contains an absolute path, then the path of $OsvvmLibraries in the join is ignored.

$::osvvm::OsvvmSettingsSubDirectory is set by OsvvmSettingsLocal.tcl. As a result, this value is “” for scripts (since OsvvmSettingsLocal.tcl has not been called yet). If multiple simulators are being used, set OsvvmSettingsSubDirectory as follows:
set OsvvmSettingsSubDirectory ${ToolName}

In past releases settings were in $OsvvmLibraries/Scripts or $OsvvmLibraries/osvvm (for VHDL settings). Having settings in the OsvvmLibraries directory structure caused Git to notice the changes. This is awkward if the project does not otherwise update OsvvmLibraries. The first fix to this was to offer an OsvvmSettings directory that is in the same directory that contains OsvvmLibraries. The OSVVM_SETTINGS_DIR was added for more flexibility WRT locations. Some of the decision for me is what needs to go on backups and what does not. Settings need to be backed up. Things already in Git do not.

Note here it references OsvvmSettingsLocal.tcl, as that is the current recommended file name for tcl settings. LocalScriptsDefault.tcl is the old name, but it is expected to be found in $OsvvmLibraries/Scripts and is only searched for if OsvvmSettingsLocal.tcl is not found. The code that selects these is:

# --------------------------------
# Load User settings
# Get Directory for User settings
variable ::osvvm::OsvvmUserSettingsDirectory [FindOsvvmSettingsDirectory "Scripts"]

# Settings Second:  OSVVM User/Project Customizations - not required 
if {[file exists ${::osvvm::OsvvmUserSettingsDirectory}/OsvvmSettingsLocal.tcl]} {
  # Found in OSVVM_SETTINGS_DIR
  source ${::osvvm::OsvvmUserSettingsDirectory}/OsvvmSettingsLocal.tcl
} elseif {[file exists ${::osvvm::OsvvmScriptDirectory}/OsvvmSettingsLocal.tcl]} {
  # Deprecated.  Found in Scripts Directory - backward compatible
  source ${::osvvm::OsvvmScriptDirectory}/OsvvmSettingsLocal.tcl
} elseif {[file exists ${::osvvm::OsvvmScriptDirectory}/LocalScriptDefaults.tcl]} {
  # Deprecated:  Uses old name - backward compatible
  source ${::osvvm::OsvvmScriptDirectory}/LocalScriptDefaults.tcl
}

I have noted that this section is real important and will move to the front of the user guide (section 2) in the next release.

Best Regards,
Jim

[Jim Lewis]

Hi Senthil,
The next thing to know is that every feature in OSVVM VC is tested. That is why our test suite has so many test cases. Test cases for AxiStream are in the directory, OsvvmLibraries/AXI4/AxiStream/TestCases. A search for UU finds that test cases that test this capability:

TbStream_ByteHandling1.vhd – tests using X”UU” and X”WW” in different positions of a send for single word transfers.
TbStream_ByteHandlingBurst1.vhd – tests using X”UU” and X”WW” in different positions of a SendBurst for burst transfers.

In short, it is nothing more than putting the X”UU” or X”WW” into the appropriate position:

Send(TRec, X”WW12UU34″) ; — A 32 bit word with TStrb = “0101” and TKeep = “1101”

Best Regards,
Jim

[Jim Lewis]

Hi Senthil
See OsvvmLibraries/Documentation/AxiStream_user_guide.pdf:

7.3 Setting and Checking TKeep and TStrb
On the AxiStream interface, a TStrb value that corresponds to a data value of ‘1’ indicates the value
contains valid data. A value of ‘0’ indicates it is a filler value. A TKeep value of ‘1’ indicates the value is
either valid data or a filler value that may not be dropped. A value of ‘0’ indicates the value may be
dropped by the interface.

Rather than supplying this sort of information as a value in the transaction call, the OSVVM
AxiStreamTransmitter VC uses a data value of X”UU” to indicate the data byte is to have TStrb = ‘0’ and
TKeep = ‘0’ and a data value of X”WW” to indicate the data byte is to have TStrb = ‘0’ and TKeep = ‘1’.
This applies to values supplied either via the Send transaction or via the BurstFifo for a SendBurst
transaction.

Similarly, in the AxiStreamReceiver VC, when TKeep = ‘0’, then the corresponding data byte will be X”UU”
and if TKeep = ‘1’ and TStrb = ‘0’, then the corresponding data byte will be X”WW”. If the transaction is
a GetBurst, and the BurstFIFO is configured to receive bytes, and the DropUndriven VC parameter is
TRUE, and the received byte is X”UU”, then it will be dropped (ie not put into the BurstFIFO).

Best Regards,
Jim

[Jim Lewis]

Hi Minteng,
When an ID has a value of -2**31 (-2147483648), it has not been initialized yet.
OSVVM VC, such as AxiStream, initialize the TransRec.BurstFifo signal at time 0 ns delta cycle 1, so it is not valid until time 0 ns delta cycle 2.

Are you working with an OSVVM VC or one of your own? If it is an OSVVM VC, time is either 0 ns or the VC does not support bursting and has not initialized the TransRec.BurstFifo as a result – (I just looked at the OSVVM UART which does not support bursting yet, but it seems to initialize BurstFifo anyway – a burst transaction can send many single word transfers on an interface).

If it is one of your own VC and it supports Burst operations, then TransRec.BurstFifo needs to be initialized at time 0 – preferably as soon as possible. See the OSVVM AxiStream transmitter for an example.

If time is actually 0 ns, then your statement,
wait until RST_N = '1' ;
seems like it is intended to find the end of reset – which should be well after time 0 ns.
My guess is that it is finding an X to 1 transition at time 0 ns.

The following should work. The now > 0 ns excludes the case where RST_N is initialized to 0, and is changed to a 1 at time 0 (which would not allow reset to happen).

wait until rising_edge(RST_N) and now > 0 ns ;  -- find reset changing from active to inactive

Best Regards,
Jim

[Jim Lewis]

Hi Remy,
Can you share exactly what you updated? Is it a particular OSVVM testbench or one of your own?

The test cases that do bursts as words will not work as they likely have dependencies on a specific size interface. The test cases that do bursts as bytes are expected to work though.

Best Regards,
Jim

[Jim Lewis]

Hi Hassan,
What version of OSVVM are you using? The current version is 2025.06a.
What simulator and version are you using?

> 1. When only the testbench code was compiled. Why did it say “failed”?

Perhaps you can share the log files with me so I can look at it. Ultimately I need a reproducer test case of this.
Also try puts $::errorInfo

Did you do the exact sequence as above or were there other builds before it?

> 2. How can one open the HTML report that shows details of the build and also the single test that was run?

You need to run the test case with build. So put the RunTest in a *.pro file.

> 3. Without changing the VHDL code, how can one cause the log and debug messages to be
> printed only for failing test but not when the test passes? I am referring to the
> terminal in which the test is running and not the HTML report or any other file generated
> with the transcript.

Ultimately you need to know a test case is going to fail – this may mean running it twice. Once observing that it failed and a second time rerunning it with a method to change the settings.

You can change the settings by:
1) Add a generic to TestCtrl that turns on info and debug messages.
2) Read the log enables from a file using ReadLogEnables. May not allow test wide settings.

I am looking for what is next and am open to suggestions. One thing I need to do is to make sure ReadLogEnables allows test wide settings – either independent of or matching the test case name. Another might be a mechanism to turn on mirroring.

[Jim Lewis]

Hi Nigel,
In the OSVVM 2024.09 and 2025.02 releases, the 2019 compile switch was turned on if the Questa release is greater than 2024.2. With the OSVVM 2025.04a release and beyond the 2019 switch it is turned back off again. So I recommend getting the newest release of OSVVM (2025.06a) and this problem is resolved.

In Questa, your issue is happening because OSVVM was compiled with 2019 and your project was compiled with a different version. So in Questa, when you turn on VHDL-2019, you must turn it on for your whole project. You should be able to compile other parts of your project with 2019 as the VHDL-2019 standard should be backward compatible with older versions.

If you do not want to change your OSVVM revision, simply add the following to either your scripts or to your OsvvmSettingsLocal.tcl file:
SetVHDLVersion 2008

So how did this happened? In 2024.2 release of Questa, Questa claimed 2019 support. So I tested the VHDL-2019 based RandomPkg2019.vhd package. It passed all of our regressions and worked fine on Questa 2024.2 and 2024.3. In 2025 releases, the Questa started flagging the VHDL-2019 code in RandomPkg2019.vhd as unsupported.

Best Regards,
Jim

[Author]

Posts