Digital Design and Verification using System Verilog.

System Verilog● Evolution

– Verilog-95: IEEE Standard 1364-1995

– Verilog-2001: IEEE Standard 1364-2001

– Verilog-2005: IEEE Standard 1364-2005

– System Verilog: IEEE Standard p1800-2005● For RTL Design specification System Verilog is almost similar to Verilog

2005 with a few minor extensions such as addition of– logic– always_ff, always_comb

● For Verification purpose, System Verilog brings in additional capabilities such as

– Object Oriented Programming– Capability of constrained random stimulus generation– Assertions– Verification Coverage support such as Cover groups, cover properties etc..,– New data types such as strings– New thread synchronization mechanisms such as mailboxes and semaphores

– Latest System Verilog standard is 1800-2012.

Simulation process● Compile, Elaborate and Simulate● Event based simulation.

– Compute the change in the output values and state of the design when ever there is a change in the value at input.

● Simulation time: The time value maintained by the simulator to model the actual time it would take for the system description being simulated.

● Simulation time slot: Encompasses all simulation activity that is processed in the event regions for each simulation time.– All simulation activity for a particular simulation time is executed until no further

simulation activity remains for that time slot, that is, without advancing the simulation time.

– Execution of simulation events within a time slot may require multiple iterations through the simulation event regions for that same time slot.

Verilog-2001 Event Regions● Active Region – Execute in any order

– Blocking Assignments

– Evaluate RHS of NBAs

– Continuous Assignments

– $display

● Inactive Region– #0 Blocking Assignments

● Non-Bloacking Assignment Region– Update the LHS of a NBA statement

● Monitor/Postponed Region– Execute $monitor, $strobe and other PLI calls

● $monitor: used to monitor the changes in the signal list and print them in the format we want whenever there is a change in that signal.

● $strobe: used to prints its arguments arguments at the end of the time-slot in which the $strobe call was executed.

● Scope simulation induced race conditions due to the arbitrary execution order in Active Region

● This is the reason to follow some RTL coding guidelines.

Coding Guidelines

1.Sequential Logic: Use Non-Blocking Assignments.

2.Latches: Use Non-Blocking Assignments.

3.Combi Logic coded using an always block: Use a Blocking Assignment.

4.Mixed Sequential and Combi. Logic in same always block: Use Non-Blocking Assignment.

5.Never Mix blocking and Non-blocking assignments in the same always blocks

6.Never make assigments to the same variable from multiple always block – this will create multiple drivers on it.

7.Always use $strobe to print out the variables that are assigned using non-blocking assignments.

8. Never make #0 procedural assignments.

System Verilog-2005 Event Regions

● SystemVerilog time slot is divided into 17 ordered regions:– 9 ordered regions for execution of SystemVerilog

statements.

– 8 ordered regions for execution of PLI code.

● The new regions were specifically designed to prevent races between RTL code and the new verification constructs.

Example Design-1

A simple setup to drive stimulus and observe outputs.

Example Design-2

● Directed Testbenches: Try to linearly cover the input space by directed explicit input specification are the simplest, fastest and easiest way of writing testbenchs.

● But writing directed testbenches such as this is not efficient, as the input space and the state space of the design easily blows up in practical designs.

● It is very easy to miss bugs in if we do verification just by writing directed testbenches

● Since the test writer can't think of all possible potential bug scenarios and there are chances that bugs in the design will escape.

● A faster way – Constrained Random Verification (CRV)● In a CRV method, Test writer specifies set of specification

and constraints, and the TestBench automatically creates solution space and picks up scenarios from the solution space.

● Reduces manual effort and code for individual tests.– As the scenarios are generated automatically by the TestBench

● In Directed verification, some of the tests exercise similar logic.

● If we can measure which parts of the logic are exercised in a CRV environment we could cover a large portion of the solution space quickly.

● For measuring which part of input space is covered, we need to monitor the coverage of a test bench.

System Verilog Language Constructs

● DATA TYPES

List of System Verilog Language Constructs

● Strings● User Defined and enumerated data types● Fixed Arrays/Dynamic Arrays/Associative Arrays● Queues● Linked lists● Non-Blocking Events, Mering events, wait_order ● Semaphores● Mailboxes

Program Block

● An alternative to the module construct used in RTL coding– Multiple Program blocks can be instantiated with ports connected to

other modules/program blocks in the top level TB file.

– Ensure that there are no race conditions between the RTL and the test bench.

– Executes in the “Reactive event region” to avoid races.

– Does not allow always block, only initial blocks are allowed.

– Each program block can be exited by calling $exit system task – Unlike $finish, $exit waits for all the pending events to complete before exiting the simulation.

● The “final” Procedural statement.

fork-join

Interface

● Useful to group functionally related ports in to an interface in the test bench code.

● Example

-------------------------------------

bit clk;

wire read_en_1;

wire [7:0] addr, data;

mem MEM_INST(.clk(clk), .read_en(read_en),.addr(addr),.data(data));

tb_driver DRV_INST(.clk(clk), .read_en(read_en),.addr(addr),.data(data));

---------------------------------------

● Using interfaces

-----------------------------------------interface mem_intf #(parameter BW = 8)(input clk);

logic read_en;

logic [BW -1 :0] addr,data;

modport mem(input read_en, addr, output data);

modport tb_driver(output read_en, addr, input data);

endinterface :mem_intf

mem_intf read_bus_if(clk);

mem MEM_INST(read_bus_if);

tb_driver DRV_INST (read_bus_if);

–------------------------------------------------------------

● Inside the modules, the individual nets can be referred to as <interface_name>.net_name

Example read_bus_if.read_en

Generating Random Stimulus

● Verilog has $random task that returns a 32-bit signed random number from a uniform didtribution when called.

● Need methods to – Constrain the range and the distribution of the Random

variables

– Ability to apply dynamic constraing

– Reproducibility – manual seeding

● $urandom, $urandom_range.

Doing Constrained Randomization

● Uses OOPs features of the System Verilog language.

● Define a new class for the data item we want to randomize

● Declare the data item we want to randomize as 'rand' data type

● Use a constraint block to limit the range of values that a random variable may take.

● class rand_cl;

rand bit [7:0] data;

constraint limit_c { 40<data < 94;}

endclass ● 'rand' type variables are uniformy distributed

varaibles in the given constraint range.● 'randc' randomly cyclicly iterates over the range

till all the valid values are covered.

● class C

int seed = 1;

rand int mean;

rand int std_deviation;

rand int value;

function int gaussian_dist();

return $dist_normal( seed, mean, std_deviation );

endfunction

constraint c_parameters {

mean == 100;

std_deviation == 20;

}

constraint c_value { value == gaussian_dist(); }

endclass