Verification Tut Austin 032207 Tutorial

Copyright Notice
Copyright XtremeEDA Corporation 2007. All document files and content ("the data") are copyright XtremeEDA corporation or made available under license.
Data may not be reproduced, republished, stored, distributed, transmitted, altered or resold except as stated below: Documents may be downloaded and used for the purpose of review only Where specific authorization is given in connection with specific documents
SystemVerilog for Verification

SVUG 2007 Tutorial Hans van der Schoot, Ph.D.
hvdschoot@xtreme-eda.com
The data is provided "AS IS" without warranty of any kind. XtremeEDA may make improvements or changes to data.
Copyright XtremeEDA Corp. 2007
Agenda
SystemVerilog for Verification Primer Evolution of verification methodology and languages
Toward the SystemVerilog IEEE 1800 standard
Agenda (2)
Verification features of SystemVerilog cont'd
Constrained Random Stimulus Generation Intelligent Automated Self Checking Total Coverage Analysis Coverage Driven Verification (CDV)
Verification features of SystemVerilog

New Data Types Object Oriented Programming (OOP) Data Hiding Arrays and Queues Interfaces and modports Clocking and Program Blocks
Where to go from here
Verification Methodology
Verification success is not based on language alone Methodology is key to effective verification An effective methodology must address the main
verification challenges:
Productivity Quality
for Verification
Coverage Driven Verification (CDV) coupled with
constrained-random stimulus generation is becoming the prevalent verification methodology
Why SystemVerilog?
A variety of languages are available to implement a
HDL-Based Verification
HDLs like Verilog or VHDL were created for describing
verification environment
Hardware description languages (HDLs) Modern software programming languages
Notably Object Oriented Programming (OOP) languages
H/W and concentrate on low level bits and bytes Advantages:

Easy to manipulate bits and bytes Design and verification in a single language Disadvantages: Tedious to model high level transactions (e.g. packets) Maintenance of tens of thousands of lines of code Do not facilitate verification abstraction and re-use
Lack of higher level programming constructs
Hardware verification languages (HVLs) Let's briefly review each en route to SystemVerilog
OOP-Based Verification
Common programming languages like C++ or Java
HVL-Based Verification
HVLs like OpenVera or e incorporate the advantages of
were created for S/W at higher abstraction levels Advantages:

Easy to model high level transactions, objects Facilitate re-use, maintainability and readability Disadvantages: Languages not developed with H/W in mind
No notion of timing and concurrency Challenging to interface into various simulators
both HDLs and popular S/W programming languages Advantages:

Easy to operate at low and higher levels of abstraction Facilitate re-use, maintainability and readability Specialized advanced verification features Disadvantages: Created as testbench add-ons to HDLs
Multiple toolsets may impact simulation performance
More difficult to debug environment related problems Many engineers need to learn new language
Engineers need to learn a new, proprietary language

10
The SystemVerilog Language

A unified HDVL Superset of Verilog (IEEE 1364) Many of the desirable features of HVLs and modern S/W programming languages
OOP semantics including parameterized classes Constrained randomization, sequence generation Functional coverage Assertions
Data Types
SystemVerilog is somewhat strongly typed language Type checking of user-defined types such as enums, structs Flexibility of underlying bit-level representation of numerical values SystemVerilog also adds Two-state logic Strings (real ones !) Dynamic data types (classes) Different event types Several kinds of arrays (including queues)
And more
Direct interface to foreign programming languages
IEEE standard with broad industry support !

11
12
SystemVerilog Two-State Logic

SystemVerilog adds two state logic Valid states are 0 and 1 Uses less memory Table of commonly used data types:
Two-state
bit int longint shortint byte
xs and zs become 0 when converting from 4-state New SV types shown in bold
Enumerations
Enumerated types represent distinct states or values Useful for example for defining FSM states Enumerations are (somewhat) type-safe Implicit conversion to underlying numeric type Cannot assign from numeric type to enumeration Static and dynamic casting available though
typedef enum {COLOUR_RED, COLOUR_GREEN, COLOUR_YELLOW} colour; typedef enum {COLOUR_RED, COLOUR_GREEN, COLOUR_YELLOW} colour; typedef enum {FRUIT_APPLE, FRUIT_ORANGE, FRUIT_BANANA} fruit; typedef enum {FRUIT_APPLE, FRUIT_ORANGE, FRUIT_BANANA} fruit; colour colour fruit fruit int int c = COLOUR_GREEN; c = COLOUR_GREEN; f = FRUIT_ORANGE; f = FRUIT_ORANGE; i = c + 1; i = c + 1; c = f; c = f; c = i; c = i; c = colour'(i); c = colour'(i); // OK, result is COLOUR_GREEN // OK, result is COLOUR_GREEN Must be of type // OK, result is 1+1 = 2 colour to assign // OK, result is 1+1 = 2 // ILLEGAL // ILLEGAL // ILLEGAL // ILLEGAL // OK: explicit cast to COLOUR_YELLOW // OK: explicit cast to COLOUR_YELLOW
14
Four-state
logic/reg integer time
Width
variable 32 64 16 8
New types except bit default to signed, but can be byte unsigned a; declared unsigned byte unsigned a;
13
Enumerations (2)
Typically, use typedef to name the resulting type
typedef enum {COLOUR_RED, COLOUR_GREEN, COLOUR_YELLOW} colour; typedef enum {COLOUR_RED, COLOUR_GREEN, COLOUR_YELLOW} colour;
Structs
Similar to C structs and VHDL records Composite data type Can be used to enforce strong type-checking
typedef struct { typedef struct { byte address; byte address; } Address8; } Address8; typedef struct { typedef struct { bit [0:31] address; bit [0:31] address; } Address32; } Address32; byte smalladdress; byte smalladdress; bit [0:31] wideaddress; bit [0:31] wideaddress; Address8 narrow_addr; Address8 narrow_addr; Address32 wide_addr; Address32 wide_addr; wideaddress = smalladdress; // no error! wideaddress = smalladdress; // no error! wide_addr = narrow_addr; // compile error wide_addr = narrow_addr; // compile error
One cannot use the same constant in two definitions

typedef enum {RED, GREEN, YELLOW, ORANGE } colour; typedef enum {RED, GREEN, YELLOW, ORANGE } colour; typedef enum {APPLE, ORANGE, BANANA } fruit; // ERROR: ORANGE redefined!! typedef enum {APPLE, ORANGE, BANANA } fruit; // ERROR: ORANGE redefined!!
Several built-in methods for enumerations provided: To return the number of enum values, and their names To return the first, last, next or previous enum value
Packed arrays of different sizes are assignment-compatible!
Unpacked struct acts as wrapper to force strong type checking
15
16
Object Oriented Programming

Verification effort is increasing exponentially with
Classes
Used to represent dynamic data objects E.g. network packets, processor instructions Can be created and destroyed dynamically Can be parameterized like modules Encapsulate model behavior Properties hold data values Methods implement processing Provide an object-oriented inheritance paradigm Reuse = Encapsulation + Inheritance + Polymorphism Not the same as structs
design complexity
Verification environments required with the sophistication of a complex software system OOP originated in the software world to better enable Code reuse Modeling of large systems Verilog-95/2001 lacked OOP capabilities SystemVerilog introduces OOP to Verilog
17
18
Class Members
Class properties can be of any type, and can be
Basic Class Definition

//Typical ATM cell definition //Typical ATM cell definition class atm_cell; class atm_cell; bit [3:0] gfc; bit [3:0] gfc; rand byte vpi; rand byte vpi; bit [15:0] vci; bit [15:0] vci; bit [2:0] pti; bit [2:0] pti; bit clp; bit clp; bit [7:0] hec; bit [7:0] hec; rand byte payload[]; //random sized list rand byte payload[]; //random sized list constraint my_constraints {{ // constraint group constraint my_constraints // constraint group vpi >> 128;} vpi 128;} covergroup my_covergroup {{ covergroup my_covergroup coverpoint gfc;} coverpoint gfc;} local task compute_hec; local task compute_hec; hec == ...; hec ...; endtask endtask endclass endclass // coverage group // coverage group // private method // private method // body of task // body of task Methods: Tasks and functions
conveniently randomized within OOP framework Class methods implement behavior by operating on the properties
Are automatic by default (i.e. re-entrant) As in Verilog:
Functions return a value, and cannot block Tasks can include time consuming statements
Properties: data items of any type except wires (nets)
Void functions give task-like calling syntax Can pass arguments by reference Can specify default argument values
19
20
Class Constructors
SystemVerilog does not require complex memory
Class Constructors (2)

Users may define their own constructors Useful for initializing properties
Especially other class-type properties
allocation/de-allocation Creation of an object is straightforward and garbage collection is implicit and automatic
Helps prevent memory leaks Constructors are a mechanism for creating and
Default or parent constructor is overridden by
defining a function new, omitting a return value

There may be arguments to new
class atm_cell; class atm_cell; ... ... function new(bit [7:0] payload[]); function new(bit [7:0] payload[]); gfc = vpi = vci = pti = clp = 0; gfc = vpi = vci = pti = clp = 0; this.payload == payload; this.payload payload; compute_hec(); compute_hec(); endfunction endfunction ... ... endclass endclass
initializing an instance of a class

Every class has a built-in new function
atm_cell cell = new; atm_cell cell = new; //"new" is the SystemVerilog Constructor //"new" is the SystemVerilog Constructor
this is the built-in reference to the current class
21
22
Class Instances and Handles

Class instance, or object, is referenced through its handle Handle is a type-safe pointer Initial value is null until an instance is constructed Handles can be compared for equality and null Handles can be assigned handle of same or derived type
class atm_cell; class atm_cell; ... ... endclass endclass atm_cell cell1; // Class handle, initially null atm_cell cell1; // Class handle, initially null atm_cell cell2 == new; // Allocate storage via constructor atm_cell cell2 new; // Allocate storage via constructor atm_cell cell3; // Class handle, initially null atm_cell cell3; // Class handle, initially null cell3 == cell2; cell3 cell2; // cell3s handle now points to cell2 // cell3s handle now points to cell2
Data Hiding
Allows separation of the public interface from private
implementation
Users only need to be concerned with how to use an object, not how it is implemented Promotes re-use Three categories: public Visible outside the class (default) protected Visible only to subclasses of the class local Visible only inside the class
23
24
Data Hiding (2)

Example
class transaction; class transaction; int A; // This field is publicly accessible int A; // This field is publicly accessible local int B; // This field is only accessible within the class local int B; // This field is only accessible within the class protected int C; // This field accessible in this class and its subclasses protected int C; // This field accessible in this class and its subclasses function bit compare(transaction trans_to_compare); function bit compare(transaction trans_to_compare); compare == (this.B == trans_to_compare.B); compare (this.B == trans_to_compare.B); endfunction endfunction endclass endclass module test; module test; transaction tr == new; transaction tr new; initial begin initial begin tr.B == 76; tr.B 76; end end endmodule endmodule
Arrays and Queues

SystemVerilog offers various different kinds of arrays Packed vs. unpacked arrays Multi-dimensional arrays Dynamic arrays Associative arrays Queues
Within the same class, references to local variables in other instances is permitted
// Error, cannot access field BB from outside the class // Error, cannot access field from outside the class
25
26
Arrays
Packed arrays packed refers to vector width dimension Accessed as single vector or as array elements
bit [3:0] vctr; bit [3:0] vctr; vctr == i[10:7]; vctr i[10:7]; // Packed array of bits // Packed array of bits // 4-bit part select // 4-bit part select
Multi-Dimensional Arrays
Multiple unpacked and packed dimensions allowed Can be declared in stages with user defined types Dimension indexing order:
Unpacked before packed Left before right
Unpacked arrays unpacked refers to actual array dimension Can be of any data type (incl. classes, events, ) Can slice multiple contiguous elements at once
byte foo1 [0:255]; byte foo1 [0:255]; byte foo2 [256]; byte foo2 [256]; foo2[20:10] == foo1[10:0]; foo2[20:10] foo1[10:0];
//Multi Dimensional array of 20*10*5*4*8 bits //Multi Dimensional array of 20*10*5*4*8 bits
packed unpacked
bit [3:0][7:0] multi_dim [1:20][1:10][1:5]; bit [3:0][7:0] multi_dim [1:20][1:10][1:5];

unpacked packed
multi_dim[19][9][5][2][7:4] == 4'hf; multi_dim[19][9][5][2][7:4] 4'hf;
// Unpacked array of bytes // Unpacked array of bytes // [size] is the same as [0:size1] // [size] is the same as [0:size1] // Copying slice of array // Copying slice of array
27
28
Dynamic Arrays
Dynamic arrays are unpacked arrays that are
Associative Arrays
Associative arrays are unpacked arrays that
sized or re-sized only at run-time Use the new[]() operator to size or re-size
Each array element is initialized to
Corresponding value from optional array argument Its default value if an initial value is not so provided
int mem []; int mem []; mem == new[64]; mem new[64]; mem == new[128](mem); mem new[128](mem); mem == new[32](mem); mem new[32](mem); // Declare dynamic array // Declare dynamic array // Create dynamic array (of all 0s) // Create dynamic array (of all 0s) // Grow array preserving content // Grow array preserving content // Shrink array discarding surplus // Shrink array discarding surplus
implement look-up tables, sparse lists Array index type can be any integral data type
Serves as look-up key and imposes ordering More indexing options: classes, user defined types
int lu_table_int [int]; // Array of integers indexed by integer int lu_table_int [int]; // Array of integers indexed by integer int lu_table_string [string]; int lu_table_string [string]; // Array of integers indexed by string // Array of integers indexed by string event lu_table_class [MyClass]; // Array of events indexed by class MyClass event lu_table_class [MyClass]; // Array of events indexed by class MyClass
int mem_cpy []; int mem_cpy []; mem_cpy = new[mem.size()](mem); // Using built-in method size() mem_cpy = new[mem.size()](mem); // Using built-in method size() mem.delete(); // Using built-in method delete() mem.delete(); // Using built-in method delete()
Variety of built-in associative array methods: To delete elements, to query index existence, or first/last/next/previous index, etc.
29
30
Queues
Queues are variable-size unpacked arrays that
Array/Queue Utilities
More built-in methods for arrays and queues Locator (search) methods - return a queue
min, max, unique, find, find_first, find_last, unique_index, find_index, find_first_index, find_last_index
resize automatically Access to any queue element in constant time

Index ranges from 0 to $ (first to last)
int q1 [$]; int q1 [$]; int q2 [$:16]; int q2 [$:16]; byte q3 [$] == {2'h00, 2'hff}; byte q3 [$] {2'h00, 2'hff}; // Queue of integers (unbounded) // Queue of integers (unbounded) // Queue of maximum 16 integers // Queue of maximum 16 integers // Initialized queue of bytes // Initialized queue of bytes
Ordering Methods
sort, rsort, reverse, shuffle
Reduction Methods
sum, product, and, or, xor
Variety of built-in queue methods: To insert/delete elements, to push/pop elements, to query size, etc.
31
32
Interfaces
Provide an abstract encapsulation of communication
Using Interfaces
A module can be declared using interfaces to
between blocks
In simple terms, a bundling of port signals
interface bus_a (input clock); interface bus_a (input clock); logic [7:0] address; logic [7:0] address; logic [31:0] data; logic [31:0] data; bit valid; bit valid; bit rd_wr; bit rd_wr; endinterface endinterface
represent its portlist

interface bus_b (input clock); interface bus_b (input clock); logic [7:0] addr, data; logic [7:0] addr, data; bit [1:0] valid; bit [1:0] valid; endinterface endinterface module foo(bus_b b, input clk); module foo(bus_b b, input clk); ... ... endmodule endmodule
bus_b
foo
clk
They can be instantiated like a module

module top; module top; bus_b bb(clock); bus_b bb(clock); foo foo1(.b(bb), .clk(clock)); foo foo1(.b(bb), .clk(clock)); endmodule endmodule
Can take ports just like modules (incl. interfaces!) Can be used with modports to specify signal direction Can be used with clocking blocks to specify timing
bus_b
foo
clk top
33
34
Modports
An interface can have multiple (client) viewpoints Master/slave, transmitter/receiver, active/passive These can be specified using modports
All signal names in a interface bus_b (input clock); interface bus_b (input clock); modport must be logic [7:0] addr, data; logic [7:0] addr, data; declared in the interface bit bit [1:0] mode; [1:0] mode; bit ready; bit ready; modport master (input ready, output addr, data, mode); modport master (input ready, output addr, data, mode); modport slave (input addr, data, mode, output ready); modport slave (input addr, data, mode, output ready); endinterface endinterface
Modports (2)
Modports can easily stipulate signal directionality
between modules
module top; module top; bus_b bb(...); // instantiate the interface bus_b bb(...); // instantiate the interface foo foo1(.b1(bb.master)); foo foo1(.b1(bb.master)); bar bar1(.b1(bb.slave)); bar bar1(.b1(bb.slave)); endmodule endmodule Both foo and bar must have the appropriate interface types defined in their portlist
The basic interface signals have no direction
ready addr data valid
bus_b
master
35
slave
The I/O direction has arbitrarily been displayed with inputs pointing right
bar
top
foo
b1
36
Clocking Blocks
Specify synchronization characteristics of the design
Clocking Blocks (2)

Can be declared inside interface, module or program Has static lifetime and scope Can be used to set directions in a modport
module M1(ck, enin, din, enout, dout); module M1(ck, enin, din, enout, dout); input ck, enin; input ck, enin; input [31:0] din; input [31:0] din; output enout; output enout; output [31:0] dout; output [31:0] dout; clocking sd @(posedge ck); clocking sd @(posedge ck); input #2ns enin, din; input #2ns enin, din; output #3ns enout, dout; output #3ns enout, dout; endclocking endclocking reg [7:0] sab; reg [7:0] sab; initial begin initial begin sab = sd.din[7:0]; sab = sd.din[7:0]; end end endmodule endmodule
Encapsulate signals synchronous to a given clock Make their timing explicit Offer a clean way to drive and sample signals Decouple synchronization and timing aspects from structural and functional aspects of environment Features: Clock specification Input skew, output skew Cycle delay (##)
Can use either or both edges of clock
Signals will be sampled 2ns before posedge ck Signals will be driven 3ns after posedge ck
37
38
Other Interface Features

Interfaces can be parameterized just like modules A task or function can be declared in an interface Interface-level access then calls task through interface Interfaces can be declared as virtual interfaces Help separate abstract class transactor; class transactor; virtual bus_b bus_if; virtual bus_b bus_if; models from actual signals
Handles to concrete interfaces
Program Blocks
Intended to encapsulate testbench functionality Form the heart of the test flow Help decouple DUT from testbench code Cannot instantiate a module, interface or other program block
Are always leaves in the hierarchy
Cannot access inside a program block from outside

Testbench can access DUT but not vice versa
Recommended usage within OOP framework

Promote code reuse
task new (( virtual bus_b bus_if ); task new virtual bus_b bus_if ); this.bus_if == bus_if; this.bus_if bus_if; ... ... endtask bus_b bb(...); endtask bus_b bb(...); ... ... ... initial begin ... initial begin endclass transactor = new( bb ); endclass transactor = new( bb ); ... ...
Always blocks not permitted Execute in reactive scheduler region

39
40
Stimulus Generation
Viewing the entire state space of a DUT
Directed Testing Approach

One could decide on which states are most important
and interesting for verification success, then:

Write one testcase per state, or set of states Manually direct the simulation to desired state(s), and then perform checking
cpu_driver.write(16'h000A,16'h1234); // manually select values to program cpu_driver.write(16'h000A,16'h1234); // manually select values to program cpu_driver.write(16'h000B,16'h4321); // DUT registers cpu_driver.write(16'h000B,16'h4321); // DUT registers ... ... #40; #40; // assert a signal to cause an interrupt dut.some_condition == 1'b1; dut.some_condition 1'b1; // assert a signal to cause an interrupt #100; #100; if (dut.intA != 1'b1) // verify interrupt occurred some time later if (dut.intA != 1'b1) // verify interrupt occurred some time later $fatal("Interrupt NOT asserted at time %0t", $time); $fatal("Interrupt NOT asserted at time %0t", $time);
What is the most effective way to verify this space?
41
42
Directed Testing Approach (2)

This approach generally requires many tests to
Random Generation
SystemVerilog enables automated generation of
achieve high coverage

Tedious to write and maintain Requires much effort
Each test will produce the exact same results every time it is run
random data
Productivity increase by automatically generating random values for variables Quality increase due to exploring outside of the expected failure scenarios of the DUT
using the $random function permits a reduction in tests. One test can be run with many seeds to try interesting combinations
cpu_gen.write_reg($random, $random); cpu_gen.write_reg($random, $random); data_gen[4].send_transaction(atm_cell, $random); data_gen[4].send_transaction(atm_cell, $random);
43
44
Random Generation (2)

This approach reduces the number of tests required Greater reliance on automation
Constrained-Random Generation
Random generation alone is not sufficient Need a mechanism to constrain generated values Constraints are essential to drive meaningful data
into a design
Input data objects:
Different packet sizes, valid address ranges,
Each test will produce different results for each seed used
Topology and configuration:

Operation mode, number of active channels,
Constraints can also guide tests to interesting DUT Issue: Lack of control over generated values Tests could be sending illegal or invalid data
states
45
46
Constrained-Random Generation (2)

SystemVerilog has a built-in constraint language Declarative style reduces manual effort required to generate valid and interesting stimulus Each object can have rules that a constraint solver
Random Variables
Need to declare which variables can be randomly
generated before applying constraints Class variables can be declared random using the rand and randc type-modifier keywords
rand Each generated value is uniformly distributed over all possible combinations randc Cycles through all values in a random permutation of declared range (random cyclic)
class packet; class packet; rand byte src; rand byte src; // each value has 1/256 probability // each value has 1/256 probability randc byte dest; // each new value has 1/(256-n) probability randc byte dest; // each new value has 1/(256-n) probability // where nn is the ## times this field has // where is the times this field has // been generated. nn rolls over at 255 // been generated. rolls over at 255 endclass endclass
must adhere to at generation time

All constraints acting on a property must be satisfied
class packet; class packet; rand byte header; rand byte header; rand byte trailer; rand byte trailer; constraint default_constraints {{ constraint default_constraints header inside {[100:200]}; header inside {[100:200]}; trailer inside {[201:255]}; trailer inside {[201:255]}; }} endclass endclass
//random value in range 100-200 //random value in range 100-200 //random value in range 201-255 //random value in range 201-255
47
48
The randomize() Function

Calling randomize() causes new values to be
Constraints
Values for random variables can be controlled
selected for all random variables in an object Function returns a success indication
class packet; class packet; rand byte src; rand byte src; rand byte dest; rand byte dest; rand byte payload [10]; rand byte payload [10]; endclass endclass packet p1 == new; packet p1 new; initial begin initial begin if (p1.randomize() == 1) $display("Success"); if (p1.randomize() == 1) $display("Success"); else $display("Randomize failed"); else $display("Randomize failed"); end end
through constraint expressions These are declared within constraint blocks

Are named class members like properties and methods
class packet; class packet; rand logic [7:0] src; rand logic [7:0] src; rand logic [7:0] dest; rand logic [7:0] dest; The name "my_constraints" can be used to enable/disable a constraint group by the constraint_mode() method. constraint my_constraints {{ constraint my_constraints // constraint expression src[1:0] == 2'b00; src[1:0] == 2'b00; // constraint expression ... // always set src[1:0] to 00 ... // always set src[1:0] to }} endclass endclass
Additional randomization features available

Different types of constraints exist

49
50
Constraints: Simple and Implication

Random variables can be constrained to a specific
Constraints: Iterative
Use foreach to constrain individual elements within
value, range of values or series of values

class packet; class packet; ... ... constraint my_constraints {{ constraint my_constraints // constrain to specific value src[1:0] == 2'b00; src[1:0] == 2'b00; // constrain to specific value dest inside {[0:128]}; dest inside {[0:128]}; // constrain within aa range // constrain within range payload >= 8'd250; // can use <, >, <=, >= payload >= 8'd250; // can use <, >, <=, >= }} endclass endclass
arrays or queues
class packet; class packet; ... ... rand logic [7:0] payload[8]; rand logic [7:0] payload[8]; constraint packet_payload {{ constraint packet_payload foreach (payload[i]) foreach (payload[i]) payload[i] inside {0,10,20,30}; payload[i] inside {0,10,20,30}; } } endclass endclass // iterate through each payload item // iterate through each payload item // constrain each item to aa list of // constrain each item to list of // values // values
Constraining by implication ( or if else)

class packet; class packet; ... ... constraint dest_range {{ constraint dest_range (dest_type == low) -> dest inside {[0:127]}; (dest_type == low) -> dest inside {[0:127]}; if (dest_type == high) dest inside {[128:255]}; if (dest_type == high) dest inside {[128:255]}; }} endclass endclass
In these constrainst the value of dest_type constrains the value of dest and the value of dest constrains the value of dest_type (bidirectional)
51
52
Constraints: Other Types

Weighted distribution Ordering Function calls
class packet; class packet; rand byte src; rand byte src; rand byte dest; rand byte dest; rand byte payload[]; rand byte payload[]; constraint packet_size { constraint packet_size { src dist { src dist { [0:2] :/ 1, [0:2] :/ 1, [11:100] := 22 [11:100] := }} solve dest before src; solve dest before src; src == fetch_src(); src == fetch_src(); }}
In-line Constraints
Random variables can be further constrained in-line
using randomize() with

typedef enum {low, high} desttype; typedef enum {low, high} desttype; class packet; class packet; rand desttype dest_type; rand desttype dest_type; rand byte src; rand byte src; rand byte dest; rand byte dest; constraint dest_range { constraint dest_range { (dest_type == low) -> (dest inside [0:15]); (dest_type == low) -> (dest inside [0:15]); (dest_typte == high) -> (dest inside [16:127]); (dest_typte == high) -> (dest inside [16:127]); } } endclass endclass packet p1 = new; packet p1 = new; initial begin initial begin p1.randomize() with {src <= 20 && src >= 10;}; p1.randomize() with {src <= 20 && src >= 10;}; p1.randomize() with {dest_type == low;}; p1.randomize() with {dest_type == low;}; end end
// weighted ratio of 1/3-1/3-1/3 // weighted ratio of 1/3-1/3-1/3 // weighted ratio of 1/3-1/3-1/3 // weighted ratio of 1/3-1/3-1/3 // ordering constraint // ordering constraint // function call in constraint // function call in constraint
These constraints are applied in addition to dest_range constraint group within the packet
function byte fetch_src(); ... endfunction function byte fetch_src(); ... endfunction endclass endclass
53
54
Random Stability
Highly desirable in verification Repeatable simulation results for any given seed Changes to one area of testbench have minimal overall impact on results Enforced by SystemVerilog standard: Every thread and object gets its own PRNG Sequence of random values returned by a thread or object is independent of other threads or objects Enables more precise control through manually
Intelligent Automated Self-Checking

A checking scheme is needed to confirm a DUT meets
design intent, i.e. its specification

Checks should be independent of test cases Checks should be intelligent Two different categories of checks Data checks: End-to-end transaction level Temporal assertions: Time-consuming protocol
seeding of objects
Requires some form of seed management
55
56
Data Checking
Established checking method is to compare expected
Scoreboarding
2.) The transfer function applies necessary transformations to the transaction and stores it in the scoreboard 1.) Transactions are driven into the design and passed to a transfer function (may or may not be part of the scoreboard)
vs. actual DUT responses to input stimulus

Single (or multiple) input stimulus items System msg
DUT
stim
Interrupt RAM read
Multiple responses triggered on a variety of interfaces
Transfer Function
Scoreboard
4.) Mismatches might be errored packets
Referred to as scoreboarding Transfer function to compute expected data

Can be pin accurate, even cycle accurate May use reference model (TLM)
3.) Monitor passes received transactions to the scoreboard to compare with expected results
Generator/Driver object
Monitor
Comparison function determines storage structure

E.g. to handle different data orderings
DUT
object
57
58
SystemVerilog Assertions (SVA)

Temporal assertions verify correct behavior of a DUT
Temporal Assertion Example

Verify that some signal A always causes some
over time Typically perform signal level checking

Correct bus protocol (req grant delay, sequencing) Correct error responses (interrupts flagged appropriately) Certain conditions should never occur Assertions launched whenever a trigger event occurs If another trigger occurs before completion of the assertion, another evaluation thread is spawned in parallel
signal B to rise n clock cycles later

// Pseudo-code // Pseudo-code my_assertion: whenever rise(A); wait n*clock; expect rise(B); my_assertion: whenever rise(A); wait n*clock; expect rise(B);
A B
my_assertion clock occurrence
Thread spawned
60
59
Assertion Example: Video Stream

Application: Processing of video stream Data is 8-bit (R,G,B) triplet Control is:
FS: High for one clock at start of frame LS: High for one clock at start of line PX: High to indicate valid pixel (pixels need not be contiguous)
Assertion Example: Video Stream (2)

Rule: Only one of FS, LS, PX is high at any one time
property video_rule1; property video_rule1; @(posedge CLK) $onehot0({FS,LS,PX}); @(posedge CLK) $onehot0({FS,LS,PX}); endproperty endproperty Several assertion system functions available
Rule: FS must be followed at some point by LS (no PX)

property video_ls_follows_fs; property video_ls_follows_fs; @(posedge CLK) FS |=> (LS or (~|{FS,LS,PX} [*1:$] ##1 LS); @(posedge CLK) FS |=> (LS or (~|{FS,LS,PX} [*1:$] ##1 LS); endproperty endproperty
Other rules: Only one of FS, LS and PX can be high at any time FS must be followed by LS, with no PX in between
Rule: LS must be followed at some point by PX (no FS)

property video_px_follows_ls; property video_px_follows_ls; @(posedge CLK) LS |=> (PX or (~|{FS,LS,PX} [*1:$] ##1 PX); @(posedge CLK) LS |=> (PX or (~|{FS,LS,PX} [*1:$] ##1 PX); endproperty endproperty
61
62
Assertion Example: Video Stream (3)

To use the properties created, they must be invoked
VIDEO_ONEHOT: assert property (video_rule1); VIDEO_ONEHOT: assert property (video_rule1); VIDEO_FS_EVT_LS: assert property (video_ls_follows_fs); VIDEO_FS_EVT_LS: assert property (video_ls_follows_fs); VIDEO_LS_EVT_PS: assert property (video_px_follows_ls) else $fatal("Some message"); VIDEO_LS_EVT_PS: assert property (video_px_follows_ls) else $fatal("Some message");
Total Coverage Analysis

Aids in evaluating verification progress What % of verification objectives have been met? Have we done enough?
Understanding what is not covered (the holes), and why
Deterministic way for managers to gauge tape out date

These are all declarative assertions and will be launched on every occurrence of a (posedge CLK)
Give the assertion a user-defined name
Can use either assert, assume or cover
Is a feedback mechanism only Cannot ensure completeness of verification (intent) Use to steer verification efforts to untested areas
Achieve verification closure more effectively
Reduces number of simulation cycles and overall wasted effort

63
64
Coverage Feedback
Functional Coverage
Ties verification goals to design intent User-defined based on specification
No RTL code = no coverage vs. no RTL code = no errors Goal
rand byte a, b, c; rand byte a, b, c; covergroup cg; // Define the coverage group covergroup cg; // Define the coverage group coverpoint a { coverpoint a { bins corner_cases = { [0:63], 65, 66, 67 }; bins corner_cases = { [0:63], 65, 66, 67 }; bins high_values = { [161:$] }; // $ = max value of a bins high_values = { [161:$] }; // $ = max value of a bins others[] = default;} // catch-all bin bins others[] = default;} // catch-all bin coverpoint bb {{ coverpoint ignore_bins ignore_vals {{ [250:255] }; // ignore values 250..255 ignore_bins ignore_vals [250:255] }; // ignore values 250..255 illegal_bins bad_vals { 0,5,11,13 };} // run-time errors for 0,5 ... illegal_bins bad_vals { 0,5,11,13 };} // run-time errors for 0,5 ... coverpoint c { coverpoint c { bins fixed [10] = [0:10];} // bin 10 contains <9,10> bins fixed [10] = [0:10];} // bin 10 contains <9,10> endgroup endgroup cg == new(); cg new(); ... ... cg.sample(); cg.sample(); // create the coverage group // create the coverage group // trigger coverage collection // trigger coverage collection
66
With coverage feedback
% Coverage
Without coverage feedback
Time
65
Coverage Driven Verification
Coverage Driven Verification Process

Project Planning Session with Key Team Members Verification/Coverage Plan CDV Environment
Control random directed
The CDV process flow

1. Determine features to cover from all sources 2. Specify coverage goals in coverage plan
What to cover? When to cover it? How much to cover? Analyze remaining coverage holes
Add constraints
3. 4. 5. 6.
Create supporting verification environment Run simulations and generate coverage reports Review coverage reports Create new tests to target any coverage holes
coverage coverage reports reports Simulate constrained constrained random test random test
Adjust constraints within tests to reach uncovered areas
67
68
Typical CDV Environment

scoreboard
mon mon mon RX mon mon mon mon mon
More SystemVerilog Features

Additional operators, operator overloading Streaming operators (packing/unpacking data) Additional procedural statements foreach loops, finish blocks, fork/join additions Inter-process communication and synchronization Fork/join, named events, semaphores, mailboxes Packages New file I/O capabilities Direct Programming Interface (DPI) And more
transactions
gen gen gen gen
DUT
assertions top
functional coverage
testcase
69
70
Summary
SystemVerilog for Verification Primer Evolution of verification methodology and languages Verification features of SystemVerilog
New Data Types Object Oriented Programming (OOP) Data Hiding Arrays and Queues Interfaces and Modports Clocking and Program Blocks
Summary (2)
Verification features of SystemVerilog cont'd
Constrained Random Stimulus Generation Intelligent Automated Self Checking Total Coverage Analysis Coverage Driven Verification (CDV)
71
72
Where To Go From Here

XtremeEDA is a professional services firm
specializing in
Verification Planning, Architecture and Implementation Design For Test (DFT) Training
Where To Go From Here
Skilled in a wide range of languages and tools Strong focus on methodology, beyond language Consultants are methodology experts with ability to contrast various techniques and explain best practices Instructors are active consultants with years of verification and teaching experience
73
74
For More Information

XtremeEDA Corporation www.xtreme-eda.com info@xtreme-eda.com 1 800 586 0280 (toll-free) 1 613 254 9685
Thank You for Attending
75
76

Verification Tut Austin 032207 Tutorial

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Verification Tut Austin 032207 Tutorial

Uploaded by

Copyright:

Available Formats

Copyright Notice

SystemVerilog for Verification

Copyright XtremeEDA Corp. 2007

Verification features of SystemVerilog

Where to go from here

Copyright XtremeEDA Corp. 2007

Copyright XtremeEDA Corp. 2007

Coverage Driven Verification (CDV) coupled with

constrained-random stimulus generation is becoming the prevalent verification methodology

Copyright XtremeEDA Corp. 2007

H/W and concentrate on low level bits and bytes Advantages:

Copyright XtremeEDA Corp. 2007

Copyright XtremeEDA Corp. 2007

were created for S/W at higher abstraction levels Advantages:

both HDLs and popular S/W programming languages Advantages:

Engineers need to learn a new, proprietary language

The SystemVerilog Language

IEEE standard with broad industry support !

SystemVerilog Two-State Logic

Copyright XtremeEDA Corp. 2007

One cannot use the same constant in two definitions

Packed arrays of different sizes are assignment-compatible!

Unpacked struct acts as wrapper to force strong type checking

Copyright XtremeEDA Corp. 2007

Copyright XtremeEDA Corp. 2007

Object Oriented Programming

Copyright XtremeEDA Corp. 2007

Copyright XtremeEDA Corp. 2007

Basic Class Definition

Properties: data items of any type except wires (nets)

Copyright XtremeEDA Corp. 2007

Class Constructors (2)

Default or parent constructor is overridden by

defining a function new, omitting a return value

initializing an instance of a class

this is the built-in reference to the current class

Copyright XtremeEDA Corp. 2007

Class Instances and Handles

Copyright XtremeEDA Corp. 2007

Copyright XtremeEDA Corp. 2007

Data Hiding (2)

Arrays and Queues

Copyright XtremeEDA Corp. 2007

Copyright XtremeEDA Corp. 2007

bit [3:0][7:0] multi_dim [1:20][1:10][1:5]; bit [3:0][7:0] multi_dim [1:20][1:10][1:5];

multi_dim[19][9][5][2][7:4] == 4'hf; multi_dim[19][9][5][2][7:4] 4'hf;

resize automatically Access to any queue element in constant time

Copyright XtremeEDA Corp. 2007

Copyright XtremeEDA Corp. 2007

represent its portlist

They can be instantiated like a module

The basic interface signals have no direction

ready addr data valid

ready addr data valid

ready addr data valid

ready addr data valid

Copyright XtremeEDA Corp. 2007

Clocking Blocks (2)

Can use either or both edges of clock

Other Interface Features

Cannot access inside a program block from outside

Recommended usage within OOP framework

Always blocks not permitted Execute in reactive scheduler region