You are browsing the archive for OS-VVM in general.

Transcripts, Alerts, and Logs

April 7, 2015 in Alerts and Logs, OS-VVM in general

Transcripts, Alerts, and Logs are the focus of the 2015.01 and 2015.03. What are these all about?

Transcript Files

OSVVM’s transcript capability simplifies having different parts of a testbench print to a common transcript file. It does this by providing an internal file identifier (TranscriptFile), and subprograms for opening (TranscriptOpen) files, closing (TranscriptClose) files, printing (print and writeline), and checking if the file is open (IsTranscriptOpen).

Read more at: Testbench Transcripting


OSVVM’s AlertLogPkg simplifies and formalizes the signaling errors (at run time), counting errors, and reporting errors (summary at test completion). Indication of an error is done via a call to one of the Alert procedures (Alert, AlertIf, AlertIfNot, AlertIfEqual, AlertIfNotEqual, or AlertIfDiff). Alerts have the levels FAILURE, ERROR, or Warning. Each level is counted and tracked in an internal data structure. Within the data structure, each of these can be enabled or disabled. A test can be stopped if an alert value has been signaled too many times. Stop values for each counter can be set. At the end of a test, the procedure ReportAlerts prints a report that provides pass/fail and a count of the different alert values.

Read more at: Using Alerts


Logs provide a mechanism to conditionally print information. Verbosity control allows messages that are too detailed for normal testing to be printed when specifically enabled. Logs have the levels ALWAYS, DEBUG, FINAL, and INFO.

Read more at: Using Logs

Announcing OSVVM™ 2015.03

March 29, 2015 in Announcement, OS-VVM in general

OSVVM 2015.03 is a minor release that updates only AlertLogPkg. All other packages remain unchanged.

In AlertLogPkg, added AlertIfEqual, AlertIfNotEqual, and AlertIfDiff (file). Added ReadLogEnables to initialize LogEnables from a file. Added ReportNonZeroAlerts. Added PathTail to extract an instance name from MyEntity’PathName. Added ReportLogEnables and GetAlertLogName. See AlertLogPkg_User_Guide.pdf for details.

For hierarchy mode, AlertIfEqual, AlertIfNotEqual, and AlertIfDiff have the AlertLogID parameter first. Overloading was added for AlertIf and AlertIfNot to make these consistent. Now with multiple parameters, it is easier to remember that the AlertLogID parameter is first. The older AlertIf and AlertIfNot with the AlertLogID as the second parameter were kept for backward compatibility, but are considered bad practice to use in new code.

Added ParentID parameter to FindAlertLogID. This is necessary to correctly find an ID within an entity that is used more than once.

Bug fix: Updated GetAlertLogID to use the two parameter FindAlertLogID. Without this fix, Alerts with the same name incorrectly use the same AlertLogID.

Bug fix: Updated NewAlertLogRec (called by GetAlertLogID) so a new record gets Alert and Log enables based on its ParentID rather than the ALERTLOG_BASE_ID. Issue, if created an Comp1_AlertLogID, and disabled a level (such as WARNING), and then created a childID of Comp1_AlertLogID, WARNING would not be disabled in childID.

Bug fix: Updated ClearAlerts to correctly set stop counts (broke since it previously did not use named association). Without this fix, after calling ClearAlerts, a single FAILURE would not stop a simulation, however, a single WARNING would stop a simulation.

Since 2015.01 has known bugs, it has been deleted from the downloads page.

Announcing OSVVM™ 2015.01

February 5, 2015 in Announcement, OS-VVM in general

OSVVM 2015.01 is a major release that introduces AlertLogPkg. AlertLogPkg adds Alert and verbosity control procedures that are a powerful replacement for assert statements. All OSVVM packages have replaced asserts with alerts.

VHDL assert statements have a limited form of an alert and verbosity control. Through a simulator, you can set an assertion level that will stop a simulation. Through a simulator, you can turn off some assertions from printing. However, none of this capability can be configured in VHDL, and in addition, at the end of a test, there is no way to retrieve a count of the various assertions that have occurred.

The AlertLogPkg provides Alert and Log procedures that replace VHDL assert statements and gives VHDL direct access to enabling and disabling of features, retrieving alert counts, and set stop counts (limits). All of these features can be used in either a simple global mode or a hierarchy of alerts.

Similar to VHDL assert statements, Alerts have values FAILURE, ERROR, and WARNING. Each is counted and tracked in an internal data structure. Within the data structure, each of these can be enabled or disabled. A test can be stopped if an alert value has been signaled too many times. Stop values for each counter can be set. The default for FAILURE is 0 and ERROR and WARNING are integer’right. If all test errors are reported as an alert, at the end of the test, a report can be generated which provides pass/fail and a count of the different alert values.

What differentiates AlertLogPkg from other alert and verbosity filtering packages is hierarchical alerts. Hierarchical alerts allow alerts for each model and/or each source of alerts to be accumulated and reported separately. While the whole testbench will benefit from all models using alerts, a single model can effectively use either global or hierarchical alerts.

Logs provide a mechanism for verbosity control on printing. Through simulator settings, assert has this capability to a limited degree. Verbosity control allows messages (such as debug, DO254 final test reports, or info) that are too detailed for normal testing to be printed when specifically enabled.

OSVVM 2015.01 also introduces TranscriptPkg. TranscriptPkg provides a mechanism to share a transcript file across the entire testbench. TranscriptPkg provides a shared file, TranscriptFile, and procedures TranscriptOpen, TranscriptClose, print, and writeline. Print and WriteLine print to TranscriptFile when the transcript file is open, otherwise, print to std.textio.OUTPUT. AlertLogPkg uses TranscriptPkg for all of its printing. CoveragePkg uses TranscriptPkg for all of its printing that previously went to std.textio.OUTPUT.

OSVVM 2015.01 also introduces OsvvmGlobalPkg. OsvvmGlobalPkg provides a means to set global parameters for coverage models and the AlertLogPkg.

All of the OSVVM packages have detailed user guides in the doc directory of the release. OSVVM 2015.01 is available in the download area.

There are also other Alert and verbosity control packages available. By editing the package body of AlertLogPkg, OSVVM can be configured to use the other package. By interfacing to the separate packages via the package body, only the package body needs to be recompiled and not the entire OSVVM library.

OSVVM™ 2014.07a: Protected Types, Initialized Pointers, and Memory Leaks

December 16, 2014 in OS-VVM in general

I have just posted release 2014.07a. There are no new features in this release. It fixes memory leaks.

The first (and biggest) issue is in the deallocate procedure in CoveragePkg for CovPType. The Name of each coverage bin is never deallocated when deallocate is called. If you called deallocate during your testing process, the space allocated for the bin names was never given back. Hence, if you are currently calling deallocate in CoveragePkg, then you need this update. This issue is only in release 2014.07.

The next one is created by usage. If you declare a coverage model within a temporary object, such as a subprogram, before that subprogram exits, you must call deallocate on the coverage object. If you fail to do this, then there will be a memory leak. If you are using coverage models this way, you need this update. This issue is true about all releases of CoveragePkg since the coverage model, by necessity, is dynamically allocated.

The final ones I found are more subtle. They result from a collision of creating a coverage model within a temporary object and initializing pointers within a protected type. I took to initializing pointers so I could avoid having to do NULL checks. For example, in NamePkg, I did:
variable NamePtr : line := new string'("") ;
And then when I did a “Get” on the string value, I can skip the NULL check on NamePtr:
impure function Get return string is
return NamePtr.all ;
end function Get ;

Cool, but that means that the protected type needs a deallocate/destructor that only runs if you are never going to call a method on the protected type object again – such as a the end of a subprogram that declares an object of the protected type. Without something that happens automatically as the object is being destroyed, that is a hard use mode to remember. I instead added a check to return “” on NULL to Get. This issue is in revisions 2014.07 and 2014.01.

A testbench that declares a coverage object in an architecture or process, creates the coverage model, collects coverage while the test is running, and completes the simulation at some point (due to coverage closure or other condition) should not experience any issues with memory leaks.

So yes, put automatic garbage collection on my wish list for the next revision of the language.

OSVVM™ 2014.07 Preview and Questions

July 22, 2014 in Announcement, Functional Coverage, OS-VVM in general

Over the summer I have been working on the next set of revisions for OSVVM.

One of the new features allows a name to be specified for each bin. The name is specified in calls to AddBins and AddCross. If a name is present, calls to WriteBin will print it.

One motivation for a bin name is to correlate a requirement with it being tested (PASSED) or not tested (FAILED). Hence the output of WriteBin is now configurable and supports the following format:
{Prefix} [BinName] [PASSED|FAILED] [BinInfo] [Count]

The following report enables all fields and uses the defaults for the prefix and the Pass/Fail message:
%% State0 PASSED Bin:(0) Count = 1 AtLeast = 1
%% State1 PASSED Bin:(1) Count = 1 AtLeast = 1
%% State2 FAILED Bin:(2) Count = 0 AtLeast = 1
%% State3 FAILED Bin:(3) Count = 0 AtLeast = 1

Each call to WriteBin supports enabling or disabling each of these fields with the parameters shown below.

procedure WriteBin (
    WritePassFail   : CovOptionsType := COV_OPT_DEFAULT ;
    WriteBinInfo    : CovOptionsType := COV_OPT_DEFAULT ;
    WriteCount      : CovOptionsType := COV_OPT_DEFAULT ;
    WriteAnyIllegal : CovOptionsType := COV_OPT_DEFAULT ;
    WritePrefix     : string := "" ;
    PassName        : string := "" ;
    FailName        : string := ""
) ;

Using COV_OPT_DEFAULT and string value “” as defaults allows the defaults to be set independently from WriteBin.

Currently what I have implemented is a set of defaults for these statically set in the package. These can then be changed using the SetReportOptions method (same parameters as WriteBin). The default parameters can be overridden on each call to WriteBin – allowing printing of intermediate results that do not get observed by a requirements tracking tool.

The limitation to SetReportOptions is that it only sets the values for a single Coverage Model. Each coverage object will need its own settings. To get a consistent settings across a project, we need global settings.

Here are some choices:

  • 1: Use SetReportOptions to set global variables rather than local variables. An elegant implementation would use a local generic package for the settings and shared variables in CoveragePkg that are external to CovPType. Unfortunately this is elegant, but on the bleeding edge of support – it works in the most current release of simulators from Aldec and Mentor.
  • 2: Use SetReportOptions to set global variables rather than local variables. Do a brute force implementation that uses a dedicated package for handling the settings. The down side to this is that it requires the reference of a separate package, CovConfigPkg, to be able to change the settings within SetReportOptions or WriteBin. Of course, this can be mitigated some by providing a VHDL-2008 context declaration that includes it. This leaves more options as in 1 to 2 years from now, it would be nice to change to using the generic package.
  • 3: Initialize the report options using an initialization file (such as osvvm.ini). If the ini file is not set, then static settings will be used. Using an ini file could be powerful as it support a common setting for all tests in a design and simplify changing them to support a particular tool. It also allows changing the settings without recompiling the design. The ini file can either be set by a particular tool or manually edited by a user (with an initial file provided in the library).

I don’t see these options as necessarily being exclusive. For example, if we adopt 3, then we could also adopt either 1 or 2, or alternately use the ini file to initialize local settings and have SetReportOptions only change local objects (or never use it).

Currently I am leaning toward creating an ini file. I am thinking that SetReportOptions can be used to change local options – mainly because SetReportOptions is already implemented, however, I really can’t think of a use model where I would want to use SetReportOptions rather than just using WriteBin.

What do you think? Do you see other possibilities?

OSVVM™ Webinar and World Tour Dates

June 20, 2014 in Event, Functional Coverage, OS-VVM in general

Webinar Thursday June 26, 2014
OSVVM provides functional coverage and randomization utilities that layer on top of your transaction level modeling (tlm) based VHDL testbench. Using these you can create either basic Constrained Random tests or more advanced Intelligent Coverage based Random tests. This simplified approach allows you to utilize advanced randomization techniques when you need them and easily mix advanced randomization techniques with directed, algorithmic, and file-based test generation techniques. Best of all, OSVVM is free, works in all of Aldec and some other VHDL simulators.

Europe Session 3-4 pm CEST 6-7 am PDT 9-10 am EDT Enroll with Aldec
US Session 11 am-12 Noon PDT 2-3 pm EDT 8-9 pm CEST Enroll with Aldec

OSVVM World Tour Dates
VHDL Testbenches and Verification – OSVVM+ Boot Camp
Learn the latest VHDL verification techniques including transaction level modeling (tlm), self-checking, scoreboards, memory modeling, functional coverage, directed, algorithmic, constrained random, and intelligent testbench test generation. Create a VHDL testbench environment that is competitive with other verification languages, such as SystemVerilog or ‘e’. Our techniques work on VHDL simulators without additional licenses and are accessible to RTL engineers.

July 14-18 Munich, Germany Enroll with eVision Systems
July 21-25 Bracknell, UK Enroll with FirstEDA
August 18-22 and September 2-5 online class Enroll with SynthWorks
August 25-29 Portland, OR (Tigard/Tualatin) Enroll with SynthWorks
September 15-19 Gothenburg, Sweden Enroll with FirstEDA
October 20-24 Bracknell, UK Enroll with FirstEDA
October 27-31 and November 10-14 online class Enroll with SynthWorks
November 17-21 Baltimore, MD (BWI Area) Enroll with SynthWorks
December 1-5 and December 17-21 online class Enroll with SynthWorks

Presented by:
Jim Lewis, SynthWorks VHDL Training Expert, IEEE 1076 Working Group Chair, and OSVVM Chief Architect

My First Example with OS-VVM CoveragePkg

May 16, 2014 in Functional Coverage, OS-VVM in general

A Guest Blog from Alex Grove of FirstEDA

Here in Europe, I recently had the opportunity to work with Jim Lewis, OS-VVM Chief Architect and IEEE 1076 Working Group Chair, on the first Advanced VHDL Testbenches & Verification training course. This training, held in Bracknell, UK, was attended by engineers from several major European system companies who design and verify programmable devices (FPGAs). VHDL is by far the dominate language used by Europe’s system companies for the design and verification of FPGAs, however it is unclear to many how to enhance their verification with VHDL. What I have found is that experienced FPGA design engineers (including myself) are not utilising the VHDL language for verification.

Verification with VHDL

Jim Lewis introduces VHDL’s verification capabilities, including new VHDL 2008 features and the Open Source VHDL Verification Methodology (OSVVM). OSVVM provides a methodology for testbench development and verification packages that provide functional coverage and random value generation.

To demonstrate the use of the OSVVM functional coverage package ‘CoveragePkg’, I took a familiar Finite-state Machine (FSM) the IEEE 1149.1 TAP (Test Access Port) controller. This is a clever little state machine that I am rather fond of, having spent a lot of time working with it as part of my degree dissertation on Built-in Self Test (BIST).

So let’s take a look at our IEEE 1149.1 TAP FSM.

Post continues at Aldec Company Blog

Announcing OSVVM Release 2014.01

March 20, 2014 in Announcement, OS-VVM in general

OSVVM release 2014.01 is now available at OSVVM Downloads. Note that starting with this release, I have separated the examples from the release of the library.

Message handling is now handled by separate package, MessagePkg. MessagePkg must be compiled before CoveragePkg. Suggested compile order:

  • MessagePkg.vhd
  • SortListPkg_int.vhd
  • RandomBasePkg.vhd
  • RandomPkg.vhd
  • CoveragePkg.vhd

What’s new in CoveragePkg?

  • Merging of coverage databases.
  • Tracking last randomization.
  • Improved handling of overlapping count bins
  • Improved reporting on Aldec tools

What’s new in RandomPkg?

  • Added RandTime and RandReal (for sets of real numbers)
  • Added randomization of vectors: RandIntV, RandRealV, RandTimeV
  • Made sort, revsort from SortListPkg_int visible via aliases

OSVVM World Tour

March 19, 2014 in Event, OS-VVM in general

In conjunction with FirstEDA, I taught the first two European sessions of our OSVVM and Transaction Level Modeling (TLM) focused Advanced VHDL Testbenches and Verification class. We had attendees from many of the major European System Companies who design and verify programmable devices (FPGAs). The skill level of the delegates was impressive and made teaching one of my favorite classes just that much more fun.

Not only is VHDL dominant in Europe, but according to the 2012 Wilson Research Functional Verification Study, VHDL is the dominant FPGA design and verification language worldwide. See figures 3 and 5 of the study.

When combined with Transaction Level Modeling (TLM), OSVVM provides VHDL with an advanced verification methodology that is competitive if not superior to SystemVerilog and UVM. While OSVVM provides advanced features, such as constrained random (good), Intelligent Coverage based randomization (better), and functional coverage (essential for any randomization based methodology), verification is not just about advanced features – it is also about simplicity, readability and familiarity of the approach – not by just verification engineers, but also by RTL engineers.

Take the next step in your VHDL Verification methodology. Join us on the OSVVM world tour of our Advanced VHDL Testbenches and Verification class.

The class next dates are below. More dates will be announced shortly. Enrollment information or links are available at SynthWorks Class Schedule

  • Baltimore, Maryland April 7-11
  • UK April 28-May 2
  • Gothenburg, Sweden May 5-9
  • On-line May 12-16 and May 27-30
  • Munich Germany July 14-18
  • UK July 21-25

Webinar Recording: VHDL Intelligent Coverage using OSVVM

August 1, 2013 in Event, OS-VVM in general

Did you miss the SynthWorks and Aldec webinar on Intelligent Coverage and Open Source VHDL Verification Methodology (OSVVM)?

The slides and recorded webinar (on Aldec’s site) are now available. You may also be interested in reading our OSVVM Blog posts.

Looking to learn more about OSVVM and further advance your VHDL testbench skills, attend SynthWorks’ VHDL Testbenches and Verification class. In this class, we provide a super set of the OSVVM packages that facilitate transaction level modeling (tlm), self-checking, scoreboards, memory modeling, synchronization methods, functional coverage, and randomization. Our modeling approach is accessible by both verification and RTL designers.

We have instructor-led online classes coming up on September 3-6 and September 16-20. We have a public venue class session on August 19-23 in Portland, Oregon.  Class details and enrollment information are here: