Jim Lewis

[Jim Lewis]

Hi Jon,
The generate process/procedure can be passed the ID of the FIFO and then the information pushed into the FIFO.

The ID of the FIFO is much like a constant. It is being used as a reference into the data structure. The information is then pushed into the data structure. No pesky driver issues at all.

Looking forward the long term plan is to migrate to the DynamicArrayGenericPkg. This will allow there to be multiple consumers of the information. The beta of this package was released with 2026.05. The intent is for packet/burst information passed into the VC to be passed as a Dynamic Array into the VC and pushed into a scoreboard for the checker. The plan is to integrate the package into AxiStream some time before the end of 2026 – but also see my upcoming post about funding (that can accelerate tasks such as this).

Best Regards,
Jim

[Jim Lewis]

Hi Jon,
Which OSVVM VC are you using?

For AXI4 Manager, it writes a U to memory in locations when WSTRB is 0. The U will not be stored in memory. For reading, there is no indication the data is valid or not. Hence, if your burst FIFO is organized as words, you will need to exclude those bits from comparing to X”020100–“. The ‘-‘ is allowed with VHDL-2008. If your burst FIFO is organized as bytes, the unused bytes will not be in the FIFO. Of the FIFO handles words, no special handling is done for the first and last words to mark unused bytes – (AxiStream does do this though, not sure why similar logic was not added for AXI FULL reads – if you want to be able to do this, fill out an issue report on it.)

For AXI4 Memory, if WSTRB is 0, the byte will not be stored in memory. On reading, the value will be a U if it was not written by an operation previous to this one.

Best Regards,
Jim

[Jim Lewis]

Be sure to try setting the generic defaults via the component (if used) or entity (if component not used).

[Jim Lewis]

In VendorScripts_Questa (if version is 2025 or newer) or VendorScripts_Siemens, the generic switch is set by the following:

# -------------------------------------------------
proc vendor_generic {Name Value} {
  
  return "-g${Name}=${Value}"
}

According to the Questa command reference,

-g <Name>=<Value> …
(optional) Assigns a value to all specified VHDL generics and Verilog parameters that have
not received explicit values in generic maps, instantiations, or from defparams (such as toplevel
generics/parameters and generics/parameters that would otherwise receive their default
values).
. . . 
-G<Name>=<Value> …
(optional) Same as -g (see above) except that -G also overrides generics/parameters that
received explicit values in generic maps, instantiations, or from defparams.

OSVVM is using lower case g. If you want to override something set on the component, you can switch it to upper case G in the scripts. Perhaps OSVVM can make that a setting in the future.

Alternately you can change how you are giving the generic its default value. Rather than putting it in a generic map, specify it as the default on a component declaration (if using component instances) or on the entity declaration (if using entity instances). The lower case “-g” should override these.

Let me know how it goes.

Best Regards,
Jim

[Jim Lewis]

Hi Jerome,
I suspect that I agree.

It seems to be in:
* xMiiMacTransmitter.vhd (as you reported)
* xMiiPhyRxTransmitter.vhd
* xMiiPhyTxReceiver.vhd

Do you concur that all of these should be updated?

They pass all my tests – but only because they all have the same issue.

I have updated these and pushed them to the dev branch of OSVVM.

Best Regards,
Jim

[Jim Lewis]

Hi Dave,
Is get_component_name a function that has an optional boolean parameter and returns type string?
It would help to see its definition, however, I will make some guesses.

I have seen this issue before when the optional parameter is type integer, but never with type boolean.
With type integer, in this context, it is correct if “get_component_name(1)” returns either a string
or a character value. If the 1 is seen as the optional parameter, the function returns a string
value. If the 1 is not seen as the optional parameter, then the 1 is indexing the string
return value and the expression results in a character value. Some tools will report this as
an ambiguous expression – some will not see the index and will not report it.
For me, the LRM is complex in this area and I am not clear about the proper interpretation.

The error is valid if TRUE is not a valid parameter of get_component_name. In which case NVC is
trying to use the TRUE to index a string and hence the message.

OTOH, if TRUE is a parameter (optional or not) of get_component_name, it looks like NVC has a
bug and you should report it at https://github.com/nickg/nvc/issues. Nick is generally quick
about responding – and explaining why he thinks the message is correct or it is a bug.

Best Regards,
Jim

[Jim Lewis]

Hi Jon,
What is the value of TValid during that time? If you do a get and TValid is true, the VC will receive data.

To avoid these sort of things, I usually hold off calling Get until the DUT is out of reset.

Best Regards,
Jim

[Jim Lewis]

Hi Matthias,
XSIM seems to be a moving target. In 2024.2 similar things happened. Some of what worked in 2023.2 no longer worked. I was able to change things so they worked again – and many things that did not work previously started to work.

Best Regards,
Jim

[Jim Lewis]

Hi Jon
Is the generic at the top level of the testbench or is it at a lower level?

Best Regards,
Jim

[Jim Lewis]

Using a test reporter is the intended method to get this information in CI.

Ending with error codes has seemed to create more problems than it solves – particularly since some simulators eat the error codes and do not return them outside of their environment.

[Jim Lewis]

Hi Amine,
If you are still in Tcl, there are a number of variables you can check with the build status. Currently these are not documented, but they should be. Lets start here:

::osvvm::ReportBuildName – Name of Build
::osvvm::BuildStatus – PASSED / FAILED
::osvvm::TestCasesPassed
::osvvm::TestCasesFailed
::osvvm::TestCasesSkipped
::osvvm::ReportBuildErrorCode – 0 if passed. > 0 if errors
::osvvm::ReportAnalyzeErrorCount
::osvvm::ReportSimulateErrorCount

If you are not in Tcl, you will have to get them from either the Junit XML file. The Yaml file is unprocessed – ie: it provides individual test passed/failed, but not whether the entire build has passed or failed. Maybe OSVVM should be keeping a running count of these things so they are available in Tcl and then Yaml without the reporting.

The Tcl is becoming a project of its own. It is currently around 15K lines.

Best Regards,
Jim

[Jim Lewis]

Hi Amine,
CI will be running modelsim from the bash command line. And you can use:
vsim -c -do "exit -code [catch {source $OsvvmLibraries/Scripts/StartUp.tcl ; LinkLibraryDirectory ; build RunTest.pro}]

The “exit -code” is required to get the return status. What I return error on depends on what reporter I am using.

If I am using a JUnit reporter, if the build finished (independent of test case errors), I want the test case reporter to run, hence, I only stop if there was a build failure (and test JUnit report is either potentially corrupted or does not exist). You need this report to determine which test cases passed worked and which did not.

If instead your CI run displays the OSVVM build summary report (html), then when the build finishes, it has already run, and you can report any failure, including test case failures, as a failed build. Note this test case reporter is specific to OSVVM output and will detect things like the VHDL *.pro test case name – TestName Fred does not match the VHDL test case name – SetTestName( "Fred") ; – which indicates the wrong test architecture ran. This can happen if you are using multiple test architectures of TestCtrl and not using configurations.

Best Regards,
Jim

[Jim Lewis]

By failed, do you mean test case failed or the build process errored out for some reason? OSVVM has are controls for both of these.

From the OSVVM Settings User Guide, you will find that they are controlled by variables:

variable FailOnBuildErrors        "true"    ;# simulator command had errors
variable FailOnReportErrors       "false"   ;# yaml reports caused html failure
variable FailOnTestCaseErrors     "false"   ;# one or more test case(s) had errors

Change these settings in your OsvvmSettingsLocal.tcl. See the OSVVM Settings User Guide for details.

If you look at the proc build in OsvvmScriptsCore.tcl, you will find the following code at the end. This code shows how the variable settings work.

      #
      #  Wrap up with error handling via call backs
      #
      # Run Callbacks on Error after trying to produce all reports
      if {$BuildErrorCode != 0} {   
        CallbackOnError_Build $Path_Or_File $BuildErrMsg $LocalBuildErrorInfo 
      } 
      if {$AnalyzeErrorCount > 0 || $SimulateErrorCount > 0} {   
        CallbackOnError_Build $Path_Or_File "Failed with Analyze Errors: $AnalyzeErrorCount and/or Simulate Errors: $SimulateErrorCount" $LocalBuildErrorInfo 
      } 
      if {($ReportErrorCode != 0) || ($ScriptErrorCount != 0)} {  
        CallbackOnError_AfterBuildReports $LocalReportErrorInfo
      } 
      # Fail on Test Case Errors
      if {($::osvvm::BuildStatus ne "PASSED") && ($::osvvm::FailOnTestCaseErrors)} {
          error "Test finished with Test Case Errors"
      }
      # Fail on Report / Script Errors?
      if {($ReportYamlErrorCode != 0) || ($ReportErrorCode != 0) || ($Log2ErrorCode != 0) || ($ScriptErrorCount != 0)} {  
        # End Simulation with errors
        if {$::osvvm::FailOnReportErrors} {
          error "Test finished with either Report or Script (wave.do) errors."
        }
      } 

While these controls are enough to get the information to Tcl, it is sometimes not enough to get the errors signaled outside of your simulator – and signaled to your Continuous Integration tools. For example, if you are running Questa (or RivieraPRO) you need to run the simulation by doing:
vsim -c -do "exit -code [catch {source MyScript.tcl}]

I generally break out the steps as follows (I generally set OsvvmLibraries as an environment variable):
vsim -c -do "exit -code [catch {source $OsvvmLibraries/Scripts/StartUp.tcl ; LinkLibraryDirectory ; build RunTest.pro}]

If you are running another simulator and have to do something like this, please share what you did with the community.

[Jim Lewis]

Hi Veit,
Thanks for the issue reports. I have updated the names so they match. That said, since the test runner compiles and then runs the test case, the test case execution was still correct. I still hate it when the names do not match though.

You can also file issue reports like this on the VC’s issue page, such as for this one:
https://github.com/OSVVM/AXI4/issues

This will be fixed in the Dev branch as soon as I test and push it. It will be on the main branch in the next release.

Cheers,
Jim

[Jim Lewis]

Hi Jon,
Thanks for sticking with this one. Knowing which version of Questa you had made told me I needed to search harder in VendorScripts_Questa.tcl. I found the issue. It is fixed on Dev.

If you do not want to update to the Dev branch, you can edit the line in VendorScripts_Questa.tcl that says:
set SimulateOptions [concat $::VsimArgs -t $SimulateTimeUnits -lib ${LibraryName} ${LibraryUnit}_opt ${::osvvm::SecondSimulationTopLevel} {*}${args} -suppress 8683 -suppress 8684]

And remove the ${::osvvm::SecondSimulationTopLevel} so that it is now:
set SimulateOptions [concat $::VsimArgs -t $SimulateTimeUnits -lib ${LibraryName} ${LibraryUnit}_opt {*}${args} -suppress 8683 -suppress 8684]

Best Regards,
Jim

[Author]

Posts