Functional Coverage Options features

Dear Readers,

Functional Coverage is very important in Test Bench Design. It gives us a confidence on covered items listed on verification plan/items. Usually the goal of verification engineer is to ensure that the design behaves correctly in its real environment.

Here I would like to share some of the important feature of System Verilog Functional Coverage which helps engineer during verification activity.

Coverage Options available in System Verilog through which you can specify additional information in the cover group using provided options

1. Cover Group Comment - 'option.comment'
You can add a comment in to coverage report to make them easier while analysing:

covergroup CoverComment ;
option.comment = "Register Definition section 1.1";
coverpoint reg;
endgroup

In example, you could see the usage of 'option.comment' feature. This way you can make the coverage group easier for the analysis.

2. Per Instance Coverage - 'option.per_instance'
In your test bench, you might have instantiated coverage group multiple times. By default System Verilog collects all the coverage data from all the instances. You might have more than one generator and they might generate different streams of transaction. In this case you may want to see separate reports. Using this option you can keep track of coverage for each 88instance.

covergroup CoverPerInstance ;
coverpoint tr.byte_cnt;
option.per_instance = 1;
endgroup

3. Threshold using - 'option.at_least'
This feature is useful when you don't have sufficient visibility in to the design to gather robust coverage. There might be the cases where you just have an information of number of cycles that are needed for the transfers to cover required errors to get generated/simulated for defined cover point. Here you could set the option.at_leaset. For example if we know that we need 10 cycles to cover this particular cover point, you could define option.at_leaset = 10.

4. Control on Empty bins - option.cross_num_print_missing = 1000
System verilog coverage report by default shows only the bins with samples. But usually as a verification engineer our job is to verify all cover point that are listed in verification plan.

covergroup CoverCrossNumPrintMissing ;
ByteCnt : coverpoint tr.byte_cnt;
Length : coverpoint tr.length;
option.cross_num_print_missing = 1000;
endgroup

5. Coverage Goal - option.goal
In system verilog, coverage goal for a cover group or point is the level at which the group or point is considered fully covered.

covergroup CoverGoal ;
coverpoint tr.length;
option.goal = 80;
endgroup

These are the few important coverage option features which are very useful in defining/coding System Verilog Functional Coverage.

Get free daily email updates!

Follow us!

Sensitivity List

Formal Definition

A list of signals a process is sensitive to.

Simplified Syntax

(signal_name, signal_name, . . .)

Description

The sensitivity list is a compact way of specifying the set of signals, events on which may resume a process. A sensitivity list is specified right after the keyword process (Example 1).

The sensitivity list is equivalent to the wait on statement, which is the last statement of the process statement section.

Only static signal names, for which reading is permitted, may appear in the sensitivity list of a process, i.e. no function calls are allowed in the list.

Examples

Example 1

DFF : process (CLK,RST)
begin
  if RST = '1'
    then Q <= '0';
    elsif (CLK'event) and (CLK = '1')
     then Q <= D;
  end if;
end process DFF;
-- DFF : process
-- begin
-- if RST = '1'
-- then Q <= '0';
-- elsif (CLK'event) and (CLK = '1')
-- then Q <= D;
-- end if;
-- wait on RST, CLK;
-- end process DFF;

Here, the process is sensitive to the RST and CLK signals, i.e. an event on any of these signals will cause the process to resume. This process is equivalent to the one described in the comment section.

Important Notes

· A process with a sensitivity list may not contain any explicit wait statements. Also, if such a process statement is a parent of a procedure, then that procedure may not contain a wait statement as well.

Scalar Type

Formal Definition

Scalar type is a type whose values have no elements. Scalar types consist of enumeration types, integer types, physical types, and floating point types. Enumeration types and integer types are called discrete types. Integer types, floating point types, and physical types are called numeric types. All scalar types are ordered; that is, all relational operators are predefined for their values.

Syntax:

scalar_type_definition ::= enumeration_type_definition

                        | integer_type_definition

                        | floating_type_definition

                        | physical_type_definition

Description

The scalar type values cannot contain any composite elements. All values in a specific scalar type are ordered. Due to this feature all relational operators are predefined for those types. Also, each value of a discrete or physical type has a position number.

All numeric types (i.e. integer, floating point and physical) can be specified with a range which constrains the set of possible values.

Please refer to respective topics for more information on different scalar types (enumeration type, integer type, floating point type, physical type).

Signal Assignment

Formal Definition

A signal assignment statement modifies the projected output waveforms contained in the drivers of one or more signals

Simplified Syntax

signal_name <= [delay_mechanism ] waveform ;

signal_name <= [delay_mechanism ] waveform1 when condition1 else

      [delay_mechanism ] waveform2 when condition2 else

       . . .

      [delay_mechanism ] waveformn;

with selection select

    signal_name <= [delay_mechanism ] waveform1 when choice1,

      [delay_mechanism ] waveform2 when choice2,

      . . .

      [delay_mechanism ] waveformn when others;

Description

Signal assignment statement can appear inside a process or directly in an architecture. Accordingly, sequential signal assignment statements and concurrent signal assignment statements can be distinguished. The latter can be divided into simple concurrent signal assignment, conditional signal assignment and selected signal assignment.

The target signal can be either a name (simple, selected, indexed, or slice) or an aggregate.

All signal assignments can be delayed. See delay for details.

Sequential signal assignment

If a sequential signal assignment appears inside a process, it takes effect when the process suspends. If there are more than one assignments to the same signal in a process before suspension, then only the last one is valid. Regardless of the number of assignments to a signal in a process, there is always only one driver for each signal in a process (Example 1).

If a signal is assigned a value in a process and the signal is on the sensitivity list of this process, then a change of the value of this signal may cause reactivation of the process (Example 2).

Concurrent signal assignment

The concurrent signal assignment statements can appear inside an architecture. Concurrent signal assignments are activated whenever any of the signals in the associated waveforms change their value. Activation of a concurrent signal assignment is independent from other statements in given architecture and is performed concurrently to other active statements (Example 3). If there are multiple assignments to the same signal then multiple drivers will be created for it. In such a case, the type of the signal must be of the resolved type (seeresolution function).

Conditional signal assignment

Conditional signal assignment is a form of a concurrent signal assignment and plays the same role in architecture as the if then else construct inside processes. A signal is assigned a waveform if the Boolean condition supported after the when keyword is met. Otherwise, the next condition after the else clause is checked, etc. Conditions may overlap.

A conditional signal assignment must end with an unconditional else expression (Example 4).

Selected signal assignment

Selected signal assignment is a concurrent equivalent of a sequential case construct. All choices for the expression must be included, unless the others clause is used as the last choice (Example 5). Ranges and selections can be used as the choice (Example 6). It is not allowed for choices to overlap.

Examples:

Example 1

signal A, B, C, X, Y, Z : integer;
process (A, B, C)
begin
  X <= A + 1;
  Y <= A * B;
  Z <= C - X;
  Y <= B;
end process;

When this process is executed, signal assignment statements are performed sequentially, but the second assignment (Y <= A * B) will never be executed because only the last assignment to Y will be activated. Moreover, in the assignment to Z only the previous value of X will be used as the A + 1 assignment will take place when the process suspends.

Example 2

signal A, B, C, X, Y, Z : integer;
process (A, B, C)
begin
  X <= A + 1;
  Y <= A * B;
  Z <= C - X;
  B <= Z * C;
end process;

When the process is activated by an event on the signal C this will cause change on the signal B inside a process, which will in turn reactivate the process because B is in its sensitivity list.

Example 3

architecture Concurrent of HalfAdder is
begin
  Sum <= A xor B;
  Carry <= A and B;
end architecture Concurrent;

The above architecture specifies a half adder. Whenever A or B changes its value, both signal assignments will be activated concurrently and new values will be assigned to Sum and Carry.

Example 4

architecture Conditional of TriStateBuffer is
begin
  BufOut <= BufIn when Enable = '1'
    else 'Z';
end architecture Conditional;

The architecture specifies a tri-state buffer. The buffer output BufOut will be assigned the value of buffer input BufIn only when the Enable input is active high. In all other cases the output will be assigned high impedance state.

Example 5

architecture Concurrent of UniversalGate is
begin
  with Command select
     DataOut <= InA and InB when "000",
                InA or InB when "001",
                InA nand InB when "010",
                InA nor InB when "011",
                InA xor InB when "100",
                InA xnor InB when "101",
                'Z' when others;
end architecture Concurrent;

Architecture of UniversalGate is specified with a selected signal assignment. Depending on the value of the Command signal, the DataOut signal will be assigned value resulting from the logical operation of two inputs. If none of the specified codes appears, the output is set to high impedance.

Example 6

with IntCommand select
  MuxOut <= InA when 0 | 1,
            InB when 2 to 5,
            InC when 6,
            InD when 7,
            'Z' when others;

A specialized multiplexer is defined here with a selected signal assignment. Note that both range and selections can be used as a choice.

Important Notes

· Signal assignment statements are generally synthesizeable but delays are usually ignored.

· Choices in selected signal assignment are separated by colons.

· All signal assignments can be labeled for improved readability.

Signal Declaration

Formal Definition

Signal is an object with a past history of values. A signal may have multiple drivers, each with a current value and projected future values. The term signal refers to objects declared by signal declarations and port declarations.

Simplified Syntax

signal signal_name : type;

signal signal_name : type := initial_value;

Description

Signals are the primary objects describing a hardware system and are equivalent to "wires". They represent communication channels among concurrent statements of system's specification. Signals and associated mechanisms of VHDL (like signal assignment statements, resolution function, delays, etc.) are used to model inherent hardware features such as concurrency, inertial character of signal propagation, buses with multiple driving sources, etc. Each signal has a history of values and may have multiple drivers, each of which has a current value and projected future values. All signal parameters are accessible by means of signal attributes.

Signals can be explicitly declared in the declarative part of:

· package declaration; signals declared in a package are visible in all design entities using the package (through the use clause);

· architecture (see architecture); such signals are visible inside the architecture only;

· block (see block); the scope of such signals is limited to the block itself;

· subprogram (see function and procedure); such signals are visible in respective subprogram.

Moreover, a port declaration in an entity is an implicit signal declaration (example 1). A signal declared this way is visible in all architectures assigned to that entity.

A signal declaration contains one or more identifiers (i.e. more than one signal can be declared in one statement) and a subtype indicator. Each signal name is an identifier and creates one separate signal. The (sub)type in the signal declaration can be of any scalar or composite type. Optionally, it may have some constraints. File and access types are not allowed for signals. Some typical signal declarations are given in the Example 1, below.

A signal can be assigned an initial (default) value in its declaration. It the value is produced by an expression, it must be of the same type as the signal itself. If there is no expression given in the signal declaration, then the default value of the signal is the left bound of the specified type (see Example 2).

A signal may be declared with a signal_kind statement, which can be either a register or bus. Such signal must be of a resolved type. A register type signal retains its current value even when all its drivers are turned off. However, the signal_kind bus relies on the resolution function to supply a "no-drive" value (see resolution function for details)

Examples

Example 1

library IEEE;
use IEEE.Std_Logic_1164.all;
entity DataTransm is
  port (Data : Std_Logic_Vector(15 downto 0));
end entity DataTransm;
architecture ExDecl of DataTransm is
signal Temp : Std_Logic;
signal FlagC, FlagZ : Bit;
begin
  . . .

Each statement of the architecture ExDecl may use any of the four signals: Data (16-bit vector), declared as a port in the entity part (above the architecture section), Temp which is a single signal of the type Std_Logic and two one bit signals: FlagC and FlagZ. Note that the signals FlagC and FlagZ are declared together in the same line because they both are of the same type.

Example 2

type Four_VL is ('X','0','1','Z');
signal Sig1 : Four_VL;
signal Sig2 : Four_VL := 'X';
signal Sig3 : Four_VL := '0';

All three above listed signals are of the same type, but their default values are specified in different ways. Sig1 will be assigned the leftmost value of the type, i.e. 'X' (Leftmost item in the first line), Sig2 is explicitly assigned the same value. However, as this is the leftmost value of the signal type in this assignment, it is redundant and can be omitted. Finally, Sig3 is assigned the '0' value. Since '0' is not the leftmost value of the type, it has to be assigned explicitly to the signal.

Important Notes

· It is illegal to declare signals in a process or a subprogram (except as formal parameters).

· Each port specified in an entity is accessible as a signal in every architecture assigned to this entity and need not to be declared again.

· A signal may never be of a file or access type.

· Despite that value assignment to a signal is made with the '<=' symbol, it is not applicable to the default value listed in the signal declaration, where the ':=' symbol must be used.

· If a signal is to be driven by more than one source (i.e. it will be assigned values in more than one statement), it has to be declared as of resolved type (see resolution anddriver).

· The signal_kinds (register and bus) are not supported by synthesis tools.

Slice

Formal Definition

A one-dimensional array of a sequence of consecutive elements of another one-dimensional array.

Simplified Syntax

object_name ( discrete_range )

function_call ( discrete_range )

Description

The slice is a subarray of a one-dimensional array, from a single element up to complete array.

The prefix used for a slice is the name of the parent array.

The index used for a slice must fall in the range of the indexes of the parent array. Moreover, the direction of the slice indexes must be the same as the direction of indexes of parent array (either ascending or descending).

The slice is an object which can be used in the same way as its parent array: if the parent array is a signal, then any its slice is also a signal, etc.

If the discrete range of a slice is null then the slice is null as well.

Examples

Example 1

signal DataBus : Bit_Vector(31 downto 0); -- parent array
DataBus(31 downto 26) -- slice 1
DataBus(24 downto 24) -- slice 2
DataBus(24 downto 30) -- slice 3
DataBus(15 to 31) -- no slice - ERROR!

The first slice is a 6-element Subarray of the DataBus. The second slice contains one element. Slice 3 is a null slice (the range is null). Finally, the fourth example is an error due to different directions of the parent array and the slice.

Important Notes

· The direction of the parent array and its slice must match (i.e. in both cases either to or downto keyword must be used).

Standard Package

Definition:

The STANDARD package predefines a number of types, subtypes, and functions which are visible to all design units.

Description

The STANDARD package is a part of the Language Specification. It defines basic types, subtypes, and functions, together with operators available for each of the (sub)types defined. The operators are specified implicitly. Below is a complete list of declared types, together with their predefined operators.

Contents:

The STANDARD package declares following types:

· BOOLEAN (with predefined
operators "and", "or", "nand", "nor", "xor", "xnor", "not", "=", "/=", "<", "<=", ">", ">="),

· BIT (with predefined operators "and", "or", "nand", "nor", "xor", "xnor", "not", "=", "/=", "<", "<=", ">", ">="),

· CHARACTER (with predefined operators "=", "/=", "<", "<=", ">", ">="),

· SEVERITY_LEVEL (with predefined operators "=", "/=", "<", "<=", ">", ">="),

· INTEGER (with predefined operators "=", "/=", "<", "<=", ">", ">=", "+", "-", "abs", "*", "/", "mod", "rem", "**"),

· REAL (with predefined operators "=", "/=", "<", "<=", ">", ">=", "+", "-", "abs", "*", "/", "**"),

· TIME (with predefined operators "=", "/=", "<", "<=", ">", ">=", "+", "-", "abs", "*", "/"),

· STRING (with predefined operators "=", "/=", "<", "<=", ">", ">=", "&"),

· BIT_VECTOR (with predefined
operators "and", "or", "nand", "nor", "xor", "xnor", "not", "sll", "srl", "sla", "sra", "rol", "ror", "=", "/=", "<", "<=", ">", ">=", "&"),

· FILE_OPEN_KIND (with predefined operators "=", "/=", "<", "<=", ">", ">="),

· FILE_OPEN_STATUS (with predefined operators "=", "/=", "<", "<=", ">", ">="),

and three subtypes:

· DELAY_LENGTH (subtype of TIME),

· POSITIVE (subtype of INTEGER),

· NATURAL (subtype of INTEGER),

See Boolean, Bit, Character, Integer, Real, Physical Types, String, Bit_Vector and File for details on respective types.

Important Notes

· Use of the STANDARD package is implicitly assumed by every VHDL simulator and compiler and need not to be explicitly declared by the 'use' clause.

· The user may not modify the contents of the package.