OSVVM on Aldec, Mentor, GHDL, and working towards Cadence

February 20, 2016 in OS-VVM in general

OSVVM 2016.01 Tested On
Some may think that OSVVM only works on a particular simulator. Not so. I test OSVVM on the latest release of Aldec ActiveHDL, Aldec RivieraPro, Mentor QuestaSim, and GHDL that I have installed. 2016.01 was tested and passes all regressions on:
Aldec ActiveHDL 10.2
Aldec RivieraPro 2015.02
Mentor QuestaSim 10.4d
GHDL 0.33

Beyond OSVVM 2016.01
Any minor bugs that are found will be fixed on the GitHub site first. To get the latest see: https://github.com/JimLewis/OSVVM

Working Towards Cadence
OSVVM is for all simulators. So for any simulator for which people report bugs, I will try to create work arounds.

On that theme, we have a number of people who have been reporting issues with Cadence simulators. As a result, I have created a Dev_Cadence branch to work around as many of the issues encountered by Cadence simulators as possible. So far I have fixes for everything that I have seen recorded. Sometimes this may mean reduced capability. But nothing of any significance yet.

See Dev_Cadence.md for the list of changes. A direct link to the Dev_Cadence branch is here: https://github.com/JimLewis/OSVVM/tree/Dev_Cadence

I do not have a copy of the Cadence tools at this time, so please let me know the next set of issues you encounter, and I will get them incorporated into the branch. You can directly email me at jim at synthworks dot com. You can also message me through osvvm.org. You can submit issues against the branch on GitHub (preferred as it is easier for me to track and close).

OSVVM on GitHub, OSVVM Training in Germany, and other OSVVM Training Datess

February 10, 2016 in Announcement, Event, OS-VVM in general

OSVVM on GitHub
OSVVM is now on GitHub. You can find releases there. I will be putting bug patches there first before formally releasing them on OSVVM.org. Long term I also plan on putting tool specific branches as needed (such as for Cadence).

https://github.com/JimLewis/OSVVM

OSVVM Training in Germany
In conjunction with PLC2, we will be offering OSVVM training in Germany. See the matrix below for the first two dates in Freiburg, Germany.

OSVVM Training 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.

February 29 – March 4 Freiburg, Germany Enroll with PLC2
March 28 – April 1 and April 11-15 online class Enroll with SynthWorks
April 25-29 Stockholm, Sweden Enroll with FirstEDA
May 9-13 Freiburg, Germany Enroll with PLC2
May 23-27 and June 13-17 online class Enroll with SynthWorks
July 25-29 and August 8-12 online class Enroll with SynthWorks
September 12-16 Bracknell, UK Enroll with FirstEDA

Announcing OSVVM™ release 2016.01

January 26, 2016 in Announcement, OS-VVM in general

2016.01
Fixed a bug in AlertLogPkg that kept more than 32 AlertLogIDs from being used.
Updated CoveragePkg, MemoryPkg, and TextUtilPkg for GHDL (function purity and indexing objects of type line)

2015.06 (released previously, but not announced)
Added MemoryPkg to easily implement sparse data structures used in memory models.
In AlertLogPkg, added AffirmIf, added PASSED log level.
In CoveragePkg, implemented mirroring for WriteBin and WriteCovHoles

 

Upcoming OSVVM Events

October 18, 2015 in Event

OSVVM Presentation in Copenhagen
IDA is hosting an OSVVM presentation on 9 November 2015 from 18:30 til 20:30.  For details see:  http://ida.dk/event/316127

OSVVM and Error Reporting
DVCon Europe in Munich, Germany.  See:  DVCon-Europe Program

OSVVM World Tour Training 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.

November 16-20 Copenhagen, Denmark Enroll with FirstEDA
November 30 – December 4 and December 14-18 online class Enroll with SynthWorks
January 11-15 and January 25-29 online class Enroll with SynthWorks
February 1-5 Bracknell, UK Enroll with FirstEDA

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

OSVVM Webinar (June 25th) and Classes

June 22, 2015 in Event, Functional Coverage, OS-VVM in general, Randomization

Webinar OSVVM for VHDL Testbenches. Thursday June 25, 2015
Open Source VHDL Verification Methodology (OSVVM) is a comprehensive, advanced VHDL verification methodology. Like UVM, OSVVM is a library of free, open-source code (packages). OSVVM uses this library to implement functional coverage, constrained random tests, and Intelligent Coverage random tests with a conciseness, simplicity and capability that rivals other verification languages.

In 2015, OSVVM added comprehensive error and message reporting (January, 2015.01) and memory modeling (June, 2015.06). With this expanded capability, this presentation
takes a look at the big picture methodology progressing transactions to randomization to functional coverage to intelligent coverage to alerts (error reporting) and logs (message reporting) to memory modeling.

Worried about keeping up with the latest trends in verification? With Intelligent Coverage, OSVVM has a portable, VHDL-based, intelligent testbench solution built into the library. While Accellera is still working on their Intelligent testbench based portable stimulus solution (in the Portable Stimulus Working Group -PSWG), for OSVVM it is already here. Best of all, OSVVM is free and works in any VHDL simulator that support a minimal amount of VHDL-2008.

Europe Session 3-4 pm CEST 6-7 am PDT 9-10 am EDT Enroll with Aldec
US Session 10-11 am PDT 1-2 pm EDT 7-8 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 20-24 and August 3-7 online class Enroll with SynthWorks
September 14-18 Bracknell, UK Enroll with FirstEDA
September 21-25 and October 5-9 online class Enroll with SynthWorks
October 26-30 Portland, OR (Tigard/Tualatin) Enroll with SynthWorks
November 9-13 Copenhagen, Denmark Enroll with FirstEDA
November 16-20 and November 30 – December 4 online class Enroll with SynthWorks

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

DAC OSVVM Birds of Feather Meeting

May 28, 2015 in Uncategorized

Coming to DAC?

I will be hosting an OSVVM birds of feather (BOF) / community meeting. The meeting is intended to provide the opportunity to learn more and discus future directions of OSVVM.

It is on Tuesday evening June 9 from 7 pm to 8:30 pm in Room 300

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

Alerts

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

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
begin
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.