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

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.

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:
http://www.synthworks.com/public_vhdl_courses.htm#VHDL_Test_Bench_Training

VHDL Functional Coverage is more capable than SystemVerilog

July 1, 2013 in Functional Coverage, OS-VVM in general

When writing functional coverage it is important to be able to capture all the details of a model. With item (aka point) coverage, both VHDL and SystemVerilog do a good job. However with cross coverage, if the model requires more than a simple Cartesian product, SystemVerilog falls short. OSVVM, on the other hand, offers a rich cross coverage capability.

Post continues at SynthWorks OSVVM Blog

Creating a VHDL-2002 Version of the OSVVM packages

May 6, 2013 in OS-VVM in general

Most simulators support VHDL-2008 now and we have stopped providing VHDL-2002 packages.  If your simulator does not support VHDL-2008, you can create VHDL-2002 version of the packages by using the following steps.

1. Convert the VHDL-2008 packages to VHDL-2002
To create VHDL-2002 versions, uncomment the following library and use clauses in the files: SortListPkg_int.vhd, RandomBasePkg.vhd, RandomPkg.vhd, and CoveragePkg.vhd:


library ieee_proposed ;
use ieee_proposed.standard_additions.all ;
use ieee_proposed.standard_textio_additions.all ;
use ieee_proposed.numeric_std_additions.all ;

Note that at some point in time, it may be necessary to use VHDL-2008 constructs. At that point in time, the above packages will not be available to uncomment and you will be need to use an older revision of the package.

2. Create library IEEE_PROPOSED
You will need an IEEE_PROPOSED library with the following files compiled into it: standard_additions_c.vhdl, standard_textio_additions_c.vhdl, env_c.vhdl, and numeric_std_additions.vhdl.   You can get the files from www.vhdl.org/fphdl/.

3. Compiling the Packages
Turn on the VHDL-2002 compile switch.  Create a library named OSVVM.  Compile the files, SortListPkg_int.vhd, RandomBasePkg.vhd, RandomPkg.vhd, and CoveragePkg.vhd into the OSVVM library.

4. Running the Demo Programs
If you use a demo program (such as Demo_Rand.vhd) that references std.env.stop you will need to change the reference to ieee_proposed.env.stop.

 

For a pdf copy of this see the downloads page.

Using OSVVM for DVB-S2 IP Core Validation

May 2, 2013 in Functional Coverage, OS-VVM in general, Randomization

Hi,

My name is Matthias Alles, I’m CEO and co-founder of Creonic, a Germany-based IP core provider in the field of communications. In this blog post I will show how we are using intelligent coverage provided by OSVVM for validation of our IP cores. I will use the DVB-S2 standard as an example IP core. DVB-S2 is the de-facto standard for satellite communications, e.g., for broadcasting HDTV signals.

The Creonic DVB-S2 IP core performs forward error correction as defined within the standard, i.e. LDPC and BCH decoding. Forward error correction is a technique to correct errors that occur during storage or transmission of digital data.  Before data transmission one adds redundant parity information to the payload information. Payload information plus parity information is denoted as code block. During transmission multiple bits of the code block can flip as they are disturbed for instance by clouds or rain. The receiver exploits the parity information to decode the original payload information.

DVB-S2 defines about 50 configurations that have to be supported by such an IP core. These configurations define parameters like code block size and amount of parity information. In order to achieve functional coverage during validation of a DVB-S2 IP core one obviously has to go through all the configurations. For each configuration, multiple blocks must be tested.

A straight forward approach is to go through all cases in a linear order, i.e., first we test let’s say 1000 code blocks for configuration 1, then 1000 blocks for configuration 2, and so on until all configurations were covered with at least 1000 blocks.

for configuration in 1 to 52 loop
    — Configure IP core now
     for block in 0 to 999 loop
        –- Write block of configuration to the IP core now
    end loop;
end loop;

The drawback of this approach is that is doesn’t reflect how a DVB-S2 system works. In reality, the system is adaptive at run-time to the current signal-to-noise ratio one achieves while communicating with the satellite. These conditions can change quickly, for instance consider a cloud or even rain that suddenly disturbs your transmission. A more realistic scenario is that the single configurations switch randomly and we want our IP core test reflect this when changing the configuration from one block to another. We use the CoveragePkg with a two-dimensional coverage variable to fulfill this requirement:

constant NUM_BLOCKS : natural := 1000; — number of different blocks per configuration
constant AT_LEAST   : natural := 10;   — how often to test each block

shared variable v_cover_cfg_blk : CovPType; — the coverage variable

variable v_cov_current : integer_vector(0 to 1);
variable v_cov_current_cfg : natural;
variable v_cov_current_blk : natural;

-– Generate two-dimensional coverage matrix: (configuration x block)
v_cover_cfg_blk.AddCross(AT_LEAST, GenBin(1, 52), GenBin(0, NUM_BLOCKS – 1));

– Check whether we achieved functional coverage
while not v_cov_cfg_blk.IsCovered loop

    — Get the point in the coverage matrix we are supposed to test next
    v_cov_current := v_cover_cfg_blk.RandCovPoint;
    v_cov_current_cfg := v_cov_current(0); — index 0 is for the configuration
    v_cov_current_blk := v_cov_current(1); — index 1 is for the block

    –
    — Now configure IP core with configuration v_cov_current_cfg and
    — write block v_cov_current_blk.
    –

    — Tell the coverage model that this (configuration x block) combination was exercised
    v_cov_current.ICover(v_cov_current);
end loop;

With just a few lines of code we ensure that we have tested all NUM_BLOCKS blocks for all configurations AT_LEAST number of times.

For the real IP core validation things are a bit more complicated. Not all of the 52 configurations are valid, but we have holes that are not allowed. We deal with this fact during definition of the coverage matrix.

v_cover_cfg_blk.AddCross(AT_LEAST, GenBin(1, 28) & GenBin(33, 52), GenBin(0, NUM_BLOCKS – 1));

With this assignment we exclude the configurations 29 to 32 from the coverage matrix such that we will never exercise the IP core with these invalid configurations.

At Creonic we have used OSVVM for more than one year now and have made it an integral part of our verification plan. The intelligent coverage saves us a significant amount of validation time. The fact that it is open source allowed us to contribute to the code and we are happy to see that our contributions became part of the new 2013.04 release.

Happy coding!
Matthias