You are browsing the archive for Announcement.

Announcing OSVVM™ 2016.11a

December 16, 2016 in Announcement, OS-VVM in general

2016.11a is a minor release. The only file that changed is VendorCovApiPkg_Aldec.vhd. There was a bug in one of the attributes that has been fixed and verified.

VendorCovApiPKg simplifies the connection between OSVVM functional coverage a vendor’s internal functional coverage database. The operation of the API is simple. Within OSVVM, all calls to create a functional coverage model (AddBins and AddCross) and record coverage (ICover) are forwarded to a simulator via VendorCovApiPkg. The simulator can use these calls to create an internal version of the functional coverage model and record the coverage.

VendorCovApiPkg_Aldec.vhd works with Riviera-PRO 2016.10. Aldec anticipates that the next release of Active-HDL will support VendorCovApiPkg_Aldec.vhd.

The heart of VendorCovApiPkg is covered in two pages of VendorCovApiPkg_user_guide.pdf.

OSVVM Webinar December 15 and Classes

December 13, 2016 in Announcement, Event, OS-VVM in general

Webinar From OSVVM to UCIS Database. Thursday December 15, 2016

When a simulator records functional coverage internally, it gains the ability to correlate the functional coverage with its verification planning tools and share that information with safety critical tools.

The 2016.11 release of Open Source VHDL Verification Methodology (OSVVM) adds an API to record OSVVM Functional Coverage directly into a simulator’s UCIS database.

This task has been on our todo list for quite some time. UCIS is complicated. Fortunately the engineers at Aldec were up to creating an initial implementation. Together we revised it.

Join OSVVM architect and VHDL trainer, Jim Lewis, and Aldec Software Product Manager, Radek Nawrot, for a presentation and demonstration of how to add this capability to your VHDL testbench.

Europe Session 3-4 pm CET 6-7 am PST 9-10 am EST Enroll with Aldec
US Session 11 am -12 noon PST 2-3 pm EST 8-9 pm CET Enroll with Aldec

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.

January 16-20 and January 30-February 3 Web Class Enroll with SynthWorks
February 20-25 Freiburg, Germany Enroll with PLC2
March 6-10 Nordic Region Enroll with FirstEDA
March 13-17 and March 27-31 Web Class Enroll with SynthWorks
April 17-21 and May 1-5 Web Class Enroll with SynthWorks
May 8-12 Freiburg, Germany Enroll with PLC2
May 22-26 Bracknell, UK Enroll with FirstEDA

Announcing OSVVM™ 2016.11

December 9, 2016 in Announcement, OS-VVM in general

New Capability Summary

  • Link OSVVM Functional Coverage to a simulator’s UCIS database
  • Data checking using scoreboards
  • Transaction interfaces using records
  • Testbench synchronization utility

This adds the packages VendorCovApiPkg, ScoreboardGenericPkg, TbUtilPkg, and ResolutionPkg.

Link OSVVM Functional Coverage to a Simulator’s UCIS Database

When a simulator records functional coverage it gains the ability the ability to correlate the functional coverage with its verification planning tools and share that information with safety critical tools.

The 2016.11 release adds an API to record OSVVM Functional Coverage a simulator’s UCIS database.

This task has been on our todo list for quite some time.   UCIS is complicated.   Fortunately the engineers at Aldec were up to creating an initial implementation.  Together we revised it.   Currently there are two packages in OSVVM:  VendorCovApiPkg.vhd (a nominal implementation which leaves OSVVM and the simulator disconnected) and VendorCovApiPkg_Aldec.vhd (which connects OSVVM Functional Coverage to Aldec simulators).

The operation of the API is simple. Within OSVVM, all calls to create a functional coverage model (AddBins and AddCross) and record coverage (ICover) are forwarded to a simulator via VendorCovApiPkg. The simulator can use these calls to create an internal version of the functional coverage model and record the coverage.

Now that we have an implementation pattern I look forward to working with other simulator vendors to integrate in their tools.  The heart of VendorCovApiPkg is covered in two pages of VendorCovApiPkg_user_guide.pdf.

I will be doing a webinar on December 15 titled, “From OSVVM VHDL Functional Coverage to UCIS-based database” with Aldec.   An announcement will follow shortly.

Data Checking Using Scoreboards

A scoreboard is a data structure used to simplify self-checking in an environment where inputs are closely related to outputs, such as in data transmission (serial ports, networking, …).   Scoreboards are particularly useful when data transmission has latency between the source and destination of the information.

I will be doing a more detailed blog on scoreboards at a later date.   For now you can consult the ScoreboardPkg_user_guide.pdf

Transaction Interfaces Using Records

Currently a record is the only VHDL abstraction that groups different types together.   The problem is, how, do we create a bidirectional transaction interface using records.    Do we use one record as inout or separate records for each direction of communication?

The OSVVM methodology is to use a single record whose elements use a resolution function that is defined in ResolutionPkg.   ResolutionPkg defines resolution functions and subtypes that apply the resolution functions to common VHDL types. The 2016.11 implementation of ResolutionPkg takes a step forward by introducing “maximum” style resolution functions that work well with the VHDL default initialization of type’left (and do not require any other initialization – such as would be required if you used std_logic or std_logic_vector).

I will be doing a more detailed blog on using records for transaction interfaces at a later date. For now you can consult ResolutionPkg_user_guide.pdf.

Testbench Synchronization Utility

To further simplify transaction level modeling, SynthWorks’ has released its TbUtilPkg into OSVVM.   This package provides synchronization and handshaking utilities for transaction interfaces and independently running processes.

I will be doing a more detailed blog on transaction and process syncrhonization at a later date.   For now you can consult TbUtilPkg_user_guide.pdf.

What is Really New?

ScoreboardPkg, ResolutionPkg, and TbUtilPkg have been used in SynthWorks’ classes for quite some time now. For students in our classes, these packages represent the latest evolutionary refinement of our methodology. To me, even though they had yet to be released in OSVVM, I have always considered these to be a fundamental part of the OSVVM methodology.

OSVVM™ Boot Camp

SynthWorks primary business is training. Our class, Advanced VHDL Testbenches and Verification – OSVVM™ Boot Camp will bring your team up to speed on using OSVVM. Follow this link to our current class schedule.

Getting the release

OSVVM release 2016.11 is available as a zip at OSVVM Downloads.

OSVVM release 2016.11 is available via git at OSVVM GitHub. Note the repository just moved to an organizational account so if you are already linking to the OSVVM github, be sure to update to the new links (the old ones will work for a short amount of time).

Spammers and Hackers, … Oh My

April 29, 2016 in Announcement

Yesterday myself and numerous others (perhaps all) received an email from Esther and Love via the OSVVM website. The email was generated by an account that they had. When I see something like this, I delete the account – which is exactly what I did yesterday.

I suspect these accounts were created using the normal channel of enrollment and not a hack (as they did nothing else damaging). We are looking into updating the account sign in process to make sure this does not happen again.

Jim

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

 

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

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