An Introduction to

SystemVerilog
This Presentation will…

 Define what is “SystemVerilog”

 Provide an overview of the major features
in “SystemVerilog”
 How it’s different from other languages

Prime goal is to make you understand the

significance of SystemVerilog
References
Websources:
1. www.systemverilog.org
2. www.asic-world.com/systemverilog/index.html
3. http://svug.org/

Books :
1. Writing Testbenches using SystemVerilog
- Janick Bergeron
2. Verification Methodology Manual
- Janick Bergeron
3. SystemVerilog For Verification
- Chris Spear
What is SystemVerilog?
What is SystemVerilog?
 SystemVerilog is a hardware description and Verification
language(HDVL)
 SystemVerilog is an extensive set of enhancements to IEEE
1364 Verilog-2001 standards
 It has features inherited from Verilog HDL,VHDL,C,C++
 Adds extended features to verilog
What is SystemVerilog?

 System verilog is the superset of verilog

 It supports all features of verilog plus add on features
 It’s a super verilog
 additional features of system verilog will be discussed
Why SystemVerilog ?
Why SystemVerilog?

Constrained Randomization Easy c model integration

OOP support New data types ie,logic

System Verilog
Assertions Coverage support

Narrow gap b/w design & verification engineer

SystemVerilog Intent

Verilog
Verilog SystemVerilog
System Verilog

 Design entry  Module level design

 Module level verification  Gate level simulations
 System level verification
 Unified language to span almost
the entire SoC design flow
Relaxed data type rules
Verilog
Verilog SystemVerilog
System Verilog

 Strict about usage of wire  Logic data type can be used so

& reg data type no need to worry about reg & wire
 Variable types are 4 state  2 state data type added – 0, 1
– 0,1,X,Z state
 2 state variable can be used in
test benches,where X,Z are not
required
 2 state variable in RTL model
may enable simulators to be more
efficient
Memory Management
Verilog
Verilog SystemVerilog
System Verilog

 Memories in verilog are  Memories are dynamic in

static in nature nature

Example :-reg[7:0] X[0:127];  Allocated at runtime

128 bytes of memory  Better memory management
ie,queues
Example:Logic[3:0] length[$];
an empty queue with an
unbounded size of logic data
type
Complexity
Verilog
Verilog SystemVerilog
System Verilog

 For complex designs  Less RTL & verification code

large number of RTL code is
 Less code hence less no. of bugs
required
 Increase in verification  Readable
code to test these designs  Higher level of abstraction due to
 Extra time algorithmic nature(inherited from
C++)
Hardware specific procedures
Verilog
Verilog SystemVerilog
System Verilog

It uses the “always” It uses three new procedures

procedure to represent
 always_ff - sequential logic
 Sequential logic
 always_comb - combinational
 Combinational logic logic
 Latched logic  always_latch - latched logic
Port connections
Verilog
Verilog SystemVerilog
System Verilog

 Ports are connected  Ports are connected using

using either named Design DUT(.*);which means
instance or positional connect all port to variables or
instance nets with the same name as the
ports
Synthesis support
Verilog
Verilog SystemVerilog
System Verilog

Extensive support for  Synthesis tool support

verilog-2001 in simulation for system verilog is
and synthesis limited

“This is a major drawback which is restricting people

to accept SystemVerilog as a Design language”
SystemVerilog Concepts
System Verilog Concepts
Data types :
reg r; // 4-state Verilog-2001
Bit subs
logic w; // 4-valued logic, see below
allowed
bit b; // 2-state bit 0 or 1

integer i; // 4-state, 32-bits, signed Verilog-2001

byte b8; // 8 bit signed integer
int i; // 2-state, 32-bit signed integer
shortint s;// 2-state, 16-bit signed integer
longint l; // 2-state, 64-bit signed integer

Explicit 2-state variables allow compiler

optimizations to improve performance

logic is has single driver (procedural assignments or a

continuous assignment), can replace reg and single driver wire.
(Equivalent to “std_ulogic” in VHDL)
System Verilog Concepts
Fork/join
Initial
Begin
Clk =0;
fork
#5
Fork
#5 a = 0;
#10 b = 0;
Clk becomes 1
join Join at t=15
Clk= 1;
end
System Verilog Concepts
Fork/join_any
Initial
Begin
Clk =0;
fork
#5
Fork
#5 a = 0;
#10 b = 0;
Clk becomes 1
Join_any Join_any at t=10
Clk= 1;
end
System Verilog Concepts
Fork/join_none
Initial
Begin
Clk =0;
fork
#5
Fork
#5 a = 0;
#10 b = 0;
Clk becomes 1
Join_none at t=5
Join_none
Clk= 1;
end
System Verilog Concepts

Final block

 Executes at the end of simulation

 It can not have delays
 Used in verification to print simulation results, such
as error report, code coverage reports
System Verilog Concepts
Tasks & Functions

 No begin end required

 Return can be used in task
 Function return values can have a “void return
type”
 Functions can have any number of inputs,outputs
and inouts including none
System Verilog Concepts
DPI(Direct Programming interface )

 DPI’s are used to call C, C++, System C functions

 System verilog has a built in C interface
 Simple to used as compared to PLI’s
 Values can be passed directly
System Verilog Concepts
DPI(Direct Programming interface )

 Imported functions

• System verilog calls the C functions

 Exported functions

• C calls the system verilog function

 Both sides of DPI are fully independent

• System verilog does not analyze the C-code

• C complier does not have to analyze the system
verilog code
System Verilog Concepts

Top SystemVerilog Testbench Constructs

 Queue  Covergroup
 Mailbox  Program
 Fork/join  Virtual interface
 Class  Clocking Block
 Constraint  modports
Verification Targeted Capabilities
Verification environment

Checks
Checks Testbench
Testbench Verification
Verification
correctness
correctness Environment
Creates Environment
Creates
stimulus
stimulus
Identifies
Identifies
Executes Test Self Check transactions
transactions
Executes
transactions
transactions
Transactor Checker Observes
Observes
Supplies
Supplies data
data data
data
to
to the
the DUT
DUT from
from DUT
DUT
Driver Assertions Monitor

DUT
Verification targeted capabilities
Verilog
Verilog SystemVerilog
System Verilog

 File I/o All verilog features

 Random number  Constrained random number
generation generation
 Fork/join  Classes
 Initial block  Fork/join_any,fork/join_none
 Task & functions  Final block
 PLI  Task & function enhancements
 DPI
OOP Concepts
What is OOP?

classes encapsulation

OOP

polymorphism inheritance
What is OOP?

 OOP is object oriented programming

 Classes form the base of OOP programming
 Encapsulation - OOP binds data & function together
 Inheritance –extend the functionality of existing objects
 Polymorphism – wait until runtime to bind data with
functions
What is OOP?

 OOP breaks a testbench into blocks that work together to

accomplish the verification goal
 Why OOP

• Highly abstract system level modelling

• Classes are intended for verification
• Classes are easily reused and extended
• Data security
• Classes are dynamic in nature
• Easy debugging, one class at a time
Why not C++

Why system
Verilog?

Why Not C++?

Why not C++

C++
C++ SystemVerilog
System Verilog

 No relation to  Superset of Verilog

verilog
 RTL/Verification language
 Interface is required
 Assertion language
to interact with Verilog
 Constraint language
 Code coverage language
Inheritance

 Inheritance is to reuse the existing code

 Inheritance allows to add new

• Data members(properties)
• New Methods

 Inheritance is to share code between classes

Inheritance

Advantages

• Common code can be grouped into one class

• No need to modify the existing classes
• Add new features to existing class by means
of new derived classes
• Easy debug & easy to maintain the code base
Randomization
Randomization
Why Randomization ?

• Random generation of stimulus

• Random setting of parameters
• Hard-to-reach corner cases can be reached
Randomization

Shift from directed to random

Directed
Directed Random
Random

 Detect the expected bugs  Detects unexpected bugs (corner

cases)
 Time consuming
 Tremendously reduce the efforts
Randomization

 Constrained Randomization
 Improves the result
 Speed-up the bug finding process
 More interesting cases can be achieved within the
constrained boundary
Assertions
Assertion

 Used primarily to validate the behaviour of a design

 An assertion is a statement about a designs intended
behaviour
 In-line assertions are best added by design engineers
 Interface assertions are best added by verification engineers
 An assertion’s sole purpose is to ensure consistency between
the designer’s intention and design implementation
 It increases the bug detection possibility during RTL design
phase
Crux
Crux
SystemVerilog

 Is a unified language (HDVL)

 Reduce the design cycle
 Verify that designs are functionally correct
 Greatly increase the ability to model huge designs
 Incorporates the capability of Vera & powerful
assertion constructs
 Bridges the gap between Hardware design engineer
and verification engineer
Verification with
SystemVerilog
This Presentation is…

 Focused on “SystemVerilog” Testbench constructs

 It’s a platform for open discussion on “SystemVerilog”

References
Websources:
1. www.systemverilog.org
3. http://svug.org/

Books :
1. Writing Testbenches using SystemVerilog
- Janick Bergeron
2. Verification Methodology Manual
- Janick Bergeron
3. SystemVerilog For Verification
- Chris Spear
We will discuss…

Top SystemVerilog Testbench Constructs

 Queue  Covergroup
 Mailbox  Program
 Fork/join  Interface
 Semaphore  Clocking Block
 Constraint  modports
Queue…

 Data storage array [$]

• Variable size array with automatic sizing
• Searching, sorting and insertion methods
Mailbox

 Fifo with flow control

• passes data between two processes
• put() – stimgen calls put() to pass data to bfm
• get() – bfm calls get() to retrieve data from
stimgen
stimgen bfm

mailbox
put() get()
Mailbox

mailbox
mailbox mbx;
mbx;
mbx
mbx == new();
new();//
// allocate
allocate mailbox
mailbox
mbx.put(data);
mbx.put(data); //
// Put
Put data
data object
object into
into mailbox
mailbox
mbx.get(data);
mbx.get(data); //// data
data will
will be
be updated
updated with
with data
data from
from FIFO
FIFO
success
success == mbx.try_get(ref
mbx.try_get(ref data);
data); // // Non-blocking
Non-blocking version
version
mbx.peek(data);
mbx.peek(data); //
// Look
Look but
but don’t
don’t remove
remove
count
count == mbx.num();
mbx.num(); //
// Number
Number of
of elements
elements in
in mailbox
mailbox
Fork/join
Fork/join
Initial
Begin
Clk =0;
fork
#5
Fork
#5 a = 0;
#10 b = 0;
Clk becomes 1
join Join at t=15
Clk= 1;
end
Fork/join
Fork/join_any
Initial
Begin
Clk =0;
fork
#5
Fork
#5 a = 0;
#10 b = 0;
Clk becomes 1
Join_any Join_any at t=10
Clk= 1;
end
Fork/join
Fork/join_none
Initial
Begin
Clk =0;
fork
#5
Fork
#5 a = 0;
#10 b = 0;
Clk becomes 1
Join_none at t=5
Join_none
Clk= 1;
end
Semaphore

 Used for Synchronization

• Variable number of keys can be put and removed
• controlled access to a shared object
• think of two people wanting to drive the same car –
the key is a semaphore
Constraint
 Control randomization
• Values for random variable can be controlled through
constraint expressions
• These are declared within constraint block
Class
Class packet
packet ;;
rand
rand logic
logic [7:0]
[7:0] src;
src;
rand
rand logic
logic [7:0]
[7:0] dest;
dest;
Constraint
Constraint my_constraints
my_constraints {{
src[1:0]
src[1:0] ==
== 2’b00;
2’b00; //
// constraint
constraint expression
expression
……………
…………… //
// always
always set
set src[1:0]
src[1:0] to
to 00
}}
endclass:packet
endclass:packet
Covergroup

 Captures results from a random simulation

 Encapsulates the coverage specification
• bins
• transitions

Covergroup
Covergroup check
check @(posedge
@(posedge top.valid
top.valid );
);
coverpoint
coverpoint global;
global;
coverpoint
coverpoint top.test;
top.test;
endgroup:check
endgroup:check
………………
………………
check
check chk
chk == new();
new();
Program Block
 Benefits:
• Encapsulates the testbench
• Separates the testbench from the DUT
• Provides an entry point for execution
• Creates a scope to encapsulate program-wide data
 Functionality:
• Can be instantiated in any hierarchical location
Typically at the top level
• Ports can be connected in the same manner as any
other module
• Executes in the SV reactive region
Program Block
The testbench (program) runs separately
from design (module)
• Triggered by clock
• Samples just before clock edge, drives just after clock

clock

Design
Testbench
Sampl Drive
e output
inputs s
Interface

 bundling of port signals

• provide an abstract encapsulation of communication
between blocks
• Directional information (modports)
• Timing (clocking blocks)
• Functionality (routines,assertions)

device1 interface device2

Interface

Interface:An example

Interface
Interface bus_a
bus_a (input
(input clock);
clock);
logic
logic [7:0]
[7:0] address;
address;
logic
logic [31:0]
[31:0] data
data ;;
bit
bit valid
valid ;;
bit
bit rd_wr
rd_wr ;;
Endinterface:
Endinterface: bus_a
bus_a
Clocking Block

 Specify synchronization characteristics of the

design
 Offer a clean way to drive and sample signals
 Features
• Clock specification
• Input skew,output skew
• Cycle delay (##)
Clocking Block

 Can be declared inside interface,module or

program
Clocking Block
Module
Module M1(ck,
M1(ck, enin,
enin, din,
din, enout,
enout, dout);
dout);
input
input ck,enin;
ck,enin;
input
input [31:0]
[31:0] din
din ;;
output
output enout
enout ;;
output
output [31:0]
[31:0] dout
dout ;;
Signals will be sampled
clocking
clocking sd
sd @(posedge
@(posedge ck);
ck);
2ns before posedge ck
input
input #2ns
#2ns ein,din
ein,din ;;
output
output #3ns
#3ns enout,
enout, dout;
dout;
endclocking:sd Signals will be driven
endclocking:sd
3ns after posedge ck
reg
reg [7:0]
[7:0] sab
sab ;;
initial
initial begin
begin
sab
sab == sd.din[7:0];
sd.din[7:0];
end
end
endmodule:M1
endmodule:M1
Modports
 An interface can have multiple viewpoints
• Master/Slave, Transmitter/Receiver
 These can be specified using modports

All signal names

Interface
in a modport must
Interface bus_b
bus_b (input
(input clock);
clock);
be declared in the
logic
logic [7:0]
[7:0] addr,data;
addr,data;
interface
logic
logic [1:0]
[1:0] mode
mode ;;
bit
bit ready
ready ;;
modport
modport master
master (input
(input ready,output
ready,output addr,data,mode)
addr,data,mode) ;;
modport
modport slave
slave (input
(input addr,data,mode,output
addr,data,mode,output ready)
ready) ;;
endinterface:
endinterface: bus_b
bus_b
Conclusion

 Some of SystemVerilog Testbench constructs were

discussed
 But still a long way to go……..
Thank you