OSVVM™ 2014.07 Preview and Questions

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?