OSVVM 2026.08

In July, I went to the FPGA Conference Europe. The 2026.08 release has been inspired by presentations I did, presentations done by my colleagues at PLC2 (Patrick and Adrien) and Aldec (Michal), and by hall way discussions. I came back from the FPGA Conference Europe energized and ready.

OSVVM release 2026.08 adds the following

• Updated Requirements Settings
• Multi-line Alert, Log, LogHeader, PrintLine, PrintHeader, …
• Updated Settings Methodology for OsvvmSettingsPkg
• Compile time selection of MemoryPkg storage policy
• format: a version of to_string that handles inconsistencies
• SetExpectedAlertCount, IncrementExpectedAlertCount
• Status: STOPLIMIT
• Status Tracking with ExpectedStatus and KnownStatus
• HTML’ized Transcript Files
• Known Breaking Changes

Updated Requirements Settings
At the conference, one of the papers I presented was on OSVVM’s requirements tracking capability. OSVVM’s requirements tracking capability is built on top of OSVVM’s Alert and coverage capabilities. One of the things you will find in this update is additional settings (in OsvvmSettingsPkg) to configure OSVVM’s requirements tracking capability. Documentation for these is in the OSVVM Settings User Guide.

Multi-line Alert, Log, LogHeader, PrintLine, PrintHeader, …
In a hall way discussion I was asked, “does OSVVM handle multi-line Alerts, Logs, and headers?” With 2026.08, now it does. With this capability comes line wrapping at either the end of the Alert/Log prefix or for wider printing, indented some from the left column. You can find more about multiline in Alert, Log, and LogHeader in the AlertLogPkg User Guide. You can find more about PrintLine and PrintHeader in TranscriptPkg user guide.

Updated Settings Methodology for OsvvmSettingsPkg
A user settings package in VHDL can be a maddening feature to maintain over time. Create a copy of the default package (OsvvmSettingsPkg_default.vhd), make changes, and use it. However, as soon as the developers of the library say, “A new setting was added”, your old setting file breaks because it does not have that constant in it.

2026.08 introduces a methodology where a settings file (OsvvmSettingsPkg_local.vset) specifies only the values that need to change. The remaining values retain their default values. This way when there is an update, if a new feature does not need to be changed, there is nothing to update.

The format of the settings file is “VARIABLE_NAME: Value”. The following makes it so that AlertIfDiff, AffirmIfFilesMatch, and AffirmIfTranscriptsMatch ignore spaces, ignore blank lines, and prints time without a decimal point.

ALERT_LOG_IGNORE_SPACES: TRUE
ALERT_LOG_IGNORE_EMPTY_LINES: TRUE
ALERT_LOG_DIGITS_FOR_TIME_FRACTION: 0
OSVVM_PREFIX_X_MARKS_THE_SPOT: "%%x "


For details see the OSVVM Settings User Guide.

Compile time selection of MemoryPkg storage policy
At the conference Adrien Weilan (PLC2) presented a paper on “big design” – a reference design that uses the OSVVM Axi4Memory verification component (VC). OSVVM’s memory model stores std_logic_vector values as type integer. With VHDL-2019, type integer is now 64 bits, where previously it was 32 bits. To ensure all bits of type integer are used, the OSVVM 2026.05 release added automatic detection for 32 and 64 bit integers and updated the storage policy algorithm accordingly.

OSVVM supports two storage policies UX01 (previously named X) and 01 (previously named NoX). The characters in the names U, X, 0, and 1 refer to std_ulogic values supported in the policy. As a result, the UX01 policy is more precise in that it models U and X as well as 0 and 1. The 01 policy reduces memory usage by half if the number of bits in your memory exceed 1/2 the number of bits of type integer.

There are three instances of MemoryGenericPkg: MemoryPkg_UX01, MemoryPkg_01, and MemoryPkg. The Axi4Memory uses MemoryPkg. By default MemoryPkg uses the policy UX01. With 2026.08, if the Tcl setting variable $::osvvm::UseMemoryPkg01 is true then policy 01 is used. See OSVVM Settings User guide for how to change this setting.

format: a version of to_string that handles inconsistencies
When testing OSVVM’s utility library, transcript outputs are compared with a previous version. If they match, the test passes. Ideally we can do this across different simulators – unfortunately with to_string this is not always possible.

For integer, when a test is checking integer’high, it will miscompare if one implementation uses 32 bit integers and another uses 64 bit integers. As a result, format for integer, prints integer’high and integer’low when one of the bounds value is used, otherwise, it prints the integer value.

For real, format prints real’high, real’low, prints in fixed point when the value is not too big or too small, and otherwise it prints an exponentiated value with a specified number of digits.

For time, format allows the time units and fraction digits to be specified. Fraction digits are important as printing 1234 ps in ns requires fractions. The number of fraction values printed by to_string differs for different simulators.

SetExpectedAlertCount, IncrementExpectedAlertCount
Prior to 2026.08, OSVVM provided expected alert counts as a negative value passed in the ExternalErrors parameter of EndOfTestReports. 2026.08 formally allows a test case to SetExpectedAlertCount and IncrementExpectedAlertCount at any point in the simulation. This allows each test segment to indicate how many errors it generates independently of the other parts of the test case. For more details see the AlertLogPkg User Guide.

Status Tracking with ExpectedStatus and KnownStatus
Some tests test error handling features by provoking them. Test status of FAILED is expected. As a result, the test case should only PASS if status FAILED and a matching error count is received. ExpectedStatus allows the scripts to express this to the report generators.

Sometimes a test case fails, but there is currently nothing we can do about it. This is the purpose of KnownStatus. In 2026.01, OSVVM started reporting VHDL-2019 Assert Counts with Alerts. One of the simulators does not accurately record the Assert counts. As a result, it fails due to the counts being incorrect. OSVVM uses KnownStatus with this. The build report still reports it as a failure, however, the reports also includes “Untracked Failures” (Errors not tracked with KnownStatus) and “Changes in Tracked Test Cases” (Known Status does not match actual status).

Status: STOPLIMIT
When a test ends due to a reaching an alert stop count, the status returned is now STOPLIMIT. STOPLIMIT tests should never pass unless a STOPLIMIT error is expected. If a normal check for PASS/FAIL were done, it is possible the test case could pass due to expected errors.

HTML’ized Transcript Files
Log files have been HTML’ized for some time now. Errors and failures in the HTML files are shown in red, making them easy to find. This same behavior now done for the Transcript files (output of TranscriptOpen).

If a test was run with a transcript file open and mirroring off, the information in the Transcript file is not included in the log output. If mirroring is off, the HTML’ized transcript file intends to include by reference (using an HTML frame) in the HTML’ized Transcript log file. However, a constant was added to control this feature and its value is set wrong. To add this capability you need to create an OsvvmSettingsPkg_local.vset with the following:

OSVVM_PREFIX_X_MARKS_THE_SPOT: "%%x "


Known Breaking Changes
Spacing of Alert and Log output has been updated. In addition to spacing changes, the time value now has a decimal point. As a result, checks of the transcript files will fail – unless the settings are changed to ignore spaces and not to use the decimal point (see Updated Settings Methodology above).

——————————————————————————————————————————-
No AI tools were injured in the production of this release.