OSVVM 2024.03 Release
OSVVM 2024.03 updates can be summarized as:
- Settings/Configuration Updates
- Xilinx Update
- OSVVM Issues Resolved
- Added Verification Components
- Minor Updates
OSVVM 2024.03a addresses an issue introduced in 2024.03 which calls EndSimulation when a simulation finishes with a TCL error code. This allows VHDL files to be closed that were not properly closed when the simulator exited. Unfortunately this also closes waveform windows. 2024.03a does not do this behavior if you are running interactively (see SetInteractiveMode in scripting). It still does EndSimulation if you are running regressions. If you run simulate from the simulator command line (vs from within a pro script), it automatically puts you in interactive mode.
Settings/Configuration Updates
From release to release, OSVVM goal is to add to our verification capabilities while maintaining backward compatibility. Sometimes this has meant maintaining the current default settings when new values would be better. 2024.03 release introduces a settings package that will allow us to either maintain backward compatibility or use the newer recommended settings.
This led to the introduction of two packages, OsvvmScriptSettingsPkg and OsvvmSettingsPkg, to help configure OSVVM. These packages use deferred constants which are set in the package bodies. The package bodies are in a separate files and are intended to be compiled last. This allows the settings to be changed without triggering a recompile of the whole OSVVM library. More details on how these work toward the end of this post.
Briefly the following has changed due to settings in OsvvmSettingsPkg_default.vhd:
- Randomization InitSeed now uses NewSeedMethods. Randomizations are likely to produce different results due to different initial seed value.
- Intelligent Coverage uses weight mode REMAIN rather than AT_LEAST. Randomization done using CoveragePkg is likely to change due to different randomization weights.
- Alerts and Log now by default justify the message, print time first, and right justify the time value with a field width of 9.
- WriteScoreboardYaml uses a base name rather than the whole file name.
- Alert and Coverage name settings
What if I want the older settings
The first four of these can be changed by creating a OsvvmSettingsLocal.tcl (in the OsvvmLibraries/Scripts directory) with the following in it. A template for OsvvmSettingsLocal is in the file OsvvmSettingsLocal_example.tcl.
namespace eval ::osvvm {
variable OsvvmVersionCompatibility "2023"
}
Alternately the settings can be edited by copying OsvvmSettingsPkg_default.vhd to OsvvmSettingsPkg_local.vhd and making the desired changes.
Any of these changes need to be made before compiling (building) the OsvvmLibraries.
Randomization InitSeed now uses NewSeedMethods
As a result, randomizations are likely to produce different results due to a different initial seed value.
Some time back, OSVVM addressed an issue where similar seeds resulted in the first value randomized to be the same. It turns out, this is a “feature” of ieee.math_real.uniform. After the first value, the values are different. To address this, OSVVM updated the hash function and internally does a randomization to further change the seed. However, to avoid changing simulation results, OSVVM added a UseNewSeedMethods parameter which historically was set to FALSE. As a result, to use the new seed methods, this parameter must be set to TRUE.
In release 2024.03, InitSeed has been updated as follows:
procedure InitSeed ( S : string ; UseNewSeedMethods : boolean := RANDOM_USE_NEW_SEED_METHODS ) ;
procedure InitSeed ( I : integer ; UseNewSeedMethods : boolean := RANDOM_USE_NEW_SEED_METHODS ) ;
In addition, OsvvmSettingsPkg_default.vhd sets RANDOM_USE_NEW_SEED_METHODS as follows:
constant RANDOM_USE_NEW_SEED_METHODS : boolean := IfElse(OSVVM_SETTINGS_REVISION >= "2024", TRUE, FALSE) ;
As a result, for release 2024.03 and beyond, TRUE is the default for the UseNewSeedMethods parameter.
If you just want to change this parameter, copy OsvvmSettingsPkg_default.vhd to OsvvmSettingsPkg_local.vhd and make the following change to RANDOM_USE_NEW_SEED_METHODS.
constant RANDOM_USE_NEW_SEED_METHODS : boolean := FALSE;
Intelligent Coverage uses weight mode REMAIN rather than AT_LEAST
Randomization done using CoveragePkg is likely to change due to different randomization weights.
The weight mode AT_LEAST uses the coverage goals as the randomization weight and was the original mode added for CoveragePkg. REMAIN mode sets the randomization weight to (coverage goal – current coverage). Weight mode REMAIN was added at a later date and provides a better balanced simulation. As a result, the historic default for this settings is AT_LEAST.
In release 2024.03, the default weight mode is specified in OsvvmSettingsPkg_default.vhd by:
constant COVERAGE_DEFAULT_WEIGHT_MODE : string := IfElse(OSVVM_SETTINGS_REVISION >= "2024", string'("REMAIN"), "AT_LEAST") ;
If you just want to change this parameter, copy OsvvmSettingsPkg_default.vhd to OsvvmSettingsPkg_local.vhd and make the following change to RANDOM_USE_NEW_SEED_METHODS.
constant COVERAGE_DEFAULT_WEIGHT_MODE : string := "REMAIN" ;
Alerts and Log now by default justify the message, print time first, and right justify the time value with a field width of 9.
Historically, the messages printed by Alert and Log were not justified and time was printed last. Eventually I saw the benefit of aligning the whole message by printing time first – thanks to Markus Ferringer for this.
Release 2024.03 changes the default so the entire message is justified, time is printed first, and time is right justified by 9. To just change this behavior, copy OsvvmSettingsPkg_default.vhd to OsvvmSettingsPkg_local.vhd and make the following changes:
constant ALERT_LOG_JUSTIFY_ENABLE : boolean := FALSE ;
constant ALERT_LOG_WRITE_TIME_FIRST : boolean := FALSE ;
constant ALERT_LOG_TIME_JUSTIFY_AMOUNT : integer := 0 ;
WriteScoreboardYaml now uses a base name rather than the whole file name
Historically WriteScoreboardYaml required specification of the whole file name. In addition, it required that file to have naming of the following format
Release 2024.03 changes the default so only the BaseName needs to be specified. To just change this behavior back to the historic settings, copy OsvvmSettingsPkg_default.vhd to OsvvmSettingsPkg_local.vhd and make the following changes:
constant SCOREBOARD_YAML_IS_BASE_FILE_NAME : boolean := FALSE ;
Alert and Coverage Settings
AlertLogPkg and CoveragePkg have considerable configuration capability. The 2024.03 release allows all of these options to be set by constants in OsvvmSettingsPkg. All string valued options can now only be set via the constants. See the user guide for SetAlertLogOptions and SetReportOptions for which constants are associated with which parameters.
SetAlertLogOptions and SetReportOptions (CoveragePkg) are still supported to change the options for a given test except all of the string valued options deprecated. If the deprecated parameters are used, they are ignored and produce warnings. The procedure SetOsvvmGlobalOptions was deprecated and removed.
Xilinx Update
Numerous packages in the OSVVM library were updated to allow the packages to work with Xilinx release 2023.02. Scripts were updated to improve support for XSIM. Sometimes a special customized package was used for Xilinx. Compile scripts (such as osvvm.pro) were updated to choose the customized packages for Xilinx.
At this point, our private test cases for the OSVVM utility library (library osvvm) work well. However most of the OSVVM verification component tests fail. We have handed off all of the failing test cases to Xilinx. Hopefully the issues will be addressed in a future release.
OSVVM Issues Resolved
- Updated AlertLogID NewID to address issue when the calls to NewID for MemoryPkg, CoveragePkg, or ScoreboardPkg used the same name as a name used for an existing AlertLogID. Issue caused simulator to crash during EndOfTestReports.
- Updated SafeResize to have an ID and improved error message. All OSVVM VC that use SafeResize were updated. Addresses OSVVM Issue from https://osvvm.org/forums/topic/alert-error-in-default
- Scripts: Fixed issue due to simulator ending in an error and not closing a file open by VHDL
Added Verification Components
- Added SPI Verification Component by Guy Eschemann
- Added VideoBus Verification Component Created by Louis Adriaens
Minor Updates
- ResizePkg: Added function SafeResize with an AlertLogID parameter – see issues resolved
- Updated All OSVVM VC to use SafeResize(AlertLogID, …)
- Updated all OSVVM VC that used a shared variable of type ModelParametersPType to use the ModelParametersIDType singleton parameter that is now in the transaction interface (record).
- AlertLogPkg: AffirmIfTranscriptsMatch and AffirmIfEqual for type boolean
- RandomPkg: Added overloading function SetRandomSalt to return the type of its input parameter
- MemoryPkg: Added aliases for Write to MemWrite and Read to MemRead
- Scripts: Added command OpenBuildHtml to open the HTML build summary report (for Siemens and Aldec)
- Common.FifoFillPkg_Slv: Added PopBurstVector that returns a count value for the size of its slv_vector or integer_vector parameters
- Common.AddressBusTransactionPkg: Added SetModelOptions for a parameter of type time.
How to Select Package Bodies for OsvvmScriptSettingsPkg and OsvvmSettingsPkg
For the OsvvmScriptSettingsPkg, if osvvm.pro finds OsvvmScriptSettingsPkg_local.vhd in the OsvvmSettingsDirectory directory, it will analyze it. Otherwise, osvvm.pro will try to generate OsvvmScriptSettingsPkg_generated.vhd in the OsvvmSettingsDirectory and then analyze it. If the generation fails, it will analyze OsvvmScriptSettingsPkg_Default.vhd in OsvvmLibraries/osvvm. The intention is that the generated file is suitable for most applications and the local file will override it if it is not.
For the OsvvmSettingsPkg, if osvvm.pro finds OsvvmSettingsPkg_local.vhd in the OsvvmSettingsDirectory directory, it will analyze it. Otherwise, osvvm.pro will analyze OsvvmSettingsPkg_Default.vhd in OsvvmLibraries/osvvm. The intention is that the Default file is suitable for most applications and the local file will override it if it is not.
The If SettingsAreRelativeToSimulationDirectory is false (default), then the OsvvmSettingsBaseDirectory will be relative to $OsvvmLibraries/osvvm, otherwise, the OsvvmSettingsBaseDirectory will be relative to the CurrentSimulationDirectory (the directory of the simulator when a build started). The OsvvmSettingsDirectory will be the file join of OsvvmSettingsBaseDirectory and OsvvmSettingsSubDirectory. Per tcl file join, if OsvvmSettingsSubDirectory contains an absolute path, then OsvvmSettingsBaseDirectory is ignored, and the absolute path in OsvvmSettingsSubDirectory is used.
The variables SettingsAreRelativeToSimulationDirectory and OsvvmSettingsSubDirectory get their initial value in OsvvmSettingsDefault.tcl and can be overridden in the OsvvmSettingsLocal.tcl (if present). OsvvmSettingsLocal.tcl deprecates the LocalScriptsDefaults.tcl (from previous revisions). To maintain backward compatibility, LocalScriptsDefaults.tcl is supported if OsvvmSettingsLocal.tcl is not used.
If you are using multiple simulators, then you will want to either
- Set the variable SettingsAreRelativeToSimulationDirectory to true (in OsvvmSettingsLocal.tcl) and have a separate simulation directory for each simulator or
- Set the variable OsvvmSettingsSubDirectory so that it has a different path for each simulator (by appending ${ToolNameVersion} onto the end of the name)