VERIFICATION USING

SYSTEM VERILOG
SUBJECT CODE:BVL701
Dr Jalaja S
Associate Professor
Dept of VDT, BIT, Bangalore
 COURSE LEARNING OBJECTIVES:
▪ Understand methods and techniques to verify the functionality of
digital electronic systems using System Verilog.
▪ Learn the System Verilog Language for Digital System Verification.
▪ To develop the ability to create structured and modular
testbenches for verifying digital designs
▪ Use Constrained Random Tests for Verification
▪ To understand and utilize the concepts of functional coverage
▪ Module-1
▪ Introduction to System Verilog:
▪ System Verilog standards, Key System Verilog enhancements for hardware design.
Advantages of System Verilog over Verilog, [Text2: 1.1.1, 1.1.2,1.2]
▪ Data Types: Verilog data types, System Verilog data types, 2 - State Data types, Bit,
byte, shortint, int, longint. 4 - State data types. Logic, Enumerated data types, User
Defined data types, Struct data types, Strings, Packages, Type Conversion: Dynamic
casting, Static Casting, Memories: Arrays, Dynamic Arrays, Multidimensional Arrays,
Packed Arrays, Associative Arrays, Queues, Array Methods. [Text2: 3.3.1, 3.3.2,
3.3.3, 3.3.4, 4.1,4.2, 5.1, 5.7, 2.1, 3.9.1.3.9.2] [Text 1: 2.4, 2.5,2.6, 2.8]
▪ Module-2
▪ Connecting the Test Bench and Design: Separating the Test Bench and Design,
The Interface Construct, Stimulus Timing, Interface Driving and Sampling, System
Verilog Assertions.
[Text 1: 5.2,5.3, 5.4,5.5, 5.9]
▪ Procedural Statements and Routines: Procedural Statements, Tasks, Functions
and Void Functions, Task and Function Overview, Routine Arguments, Returning
from a Routine, Local Data Storage, Time Values. [Text1: 3.2, 3.3, 3.4,3.5, 3.6, 3.7,3.8]
▪ Module-3
▪ Randomization: Introduction, Randomization in System Verilog, Constraint Details,
Solution Probabilities, Valid Constraints, InLine Constraints, Random Number
Functions, Common Randomization Problems, Random Control, Random Number
Generators. [Text1: 6.1,6.3,6.4, 6.5, 6.6, 6.7,6.8, 6.9,6.11, 6.14, 6.15]
▪ Module-4
▪ Functional Coverage: Introduction, Coverage Types, Functional Coverage
Strategies , Anatomy of a Cover Group, Triggering a Cover Group, Data Sampling,
Cross Coverage, Coverage Options, Parameterized Cover Groups
[Text1: 9.1,9.2, 9.3, 9.6, 9.7,9.8, 9.9,9.10]
▪ Module-5
▪ COMPLETE DESIGN MODEL USING SYSTEM VERILOG- CASE STUDY: System
Verilog ATM Example, Data Abstraction, Interface Encapsulation, Design Top Level
Squat, Receivers and Transmitters, Test Bench for ATM. [Text2: 11.1,11.2, 11.3, 11.4,
11.5, 11.6]
 PRACTICAL COMPONENT OF IPCC
Sl.NO Experiments
1 Develop mux2x1 verilog code in design.sv and develop Test bench for mux2x1 in testbench.sv
with different inputs at various times.
2 Write a program to demonstrate two-state and four-state data types.
3 Write a program to demonstrate push_front, pop_front, push_back and pop_back with respect
to Queues.
4 Design a full adder using the interface construct to model inter-module communication.
5 Create a program to highlight the difference between rand and randc constructs in constrained
randomization.
6 Build a 4-bit adder and verify its functionality using a structured verification environment.
7 Design a UART module using SystemVerilog:
a. Develop the transmitter logic
b. Implement the receiver logic
c. Create a top-level testbench to verify UART operation
8 Design, simulate, and analyze functional coverage to ensure thorough verification of a given
design.
9 Design and simulate a verification test that exercises multiple sequences.
10 Create and simulate a configurable Universal Verification Methodology (UVM) test
environment.
COURSE OUTCOMES (COURSE SKILL SET):
▪ At the end of the course the student will be able to:
▪ Understand and explain the principles and methodologies used in verifying
the functionality of digital systems.
▪ Apply the System Verilog concepts to verify the complex digital circuits.
▪ Develop and implement constrained random testbenches using System
Verilog
▪ Analyze verification quality using functional coverage metrics and implement
cover groups
▪ Analyze real-world verification scenarios and apply System Verilog
methodologies
 TEXT BOOKS:
▪ Chris Spear, “System Verilog for Verification – A guide
to learning the Test bench language features”, Springer
Publications Second Edition, 2010.

▪ Stuart Sutherland, Simon Davidmann, Peter Flake,

“System Verilog for Design- A guide to using system
Verilog for Hardware design and modelling”, Springer
Publications Second Edition, 2006
REFERENCE BOOK:
▪ Writing Testbenches using SystemVerilog - Janick
Bergeron
▪ SystemVerilog golden reference guide-A concise guide to
System Verilog Doulos ,IEEE Standard-1800- 2009, Version
5.0,ISBN: 0-9547345-9-9, 2012.
▪ Step-by-Step Functional Verification with System Verilog
and OVM, SasanIman, Hansen Brown Publishing
Company,ISBN-13: 978-0-9816-5621-2, 2008.
▪ Verification Methodology Manual - Janick Bergeron
9/17/2025 9
 SYSTEM VERILOG STANDARDS
▪ IEEE Standard: System Verilog is standardized as IEEE 1800
(first released in 2005, updated in later revisions like IEEE 1800-
2009, IEEE 1800-2012, and IEEE 1800-2017).
▪ Origin: It began as an extension to Verilog (IEEE 1364) to
address design and verification gaps.
▪ Unified Language: Combines hardware description language
(HDL) features for design and hardware verification language
(HVL) features for testbenches.
▪ Purpose: Created to improve productivity, code reusability, and
verification capabilities for complex digital systems.
EVOLUTION OF SYSTEM VERILOG
KEY SYSTEM VERILOG ENHANCEMENTS FOR HARDWARE DESIGN
System Verilog adds several features to Verilog to improve coding
efficiency, maintainability, and readability:

Data Types
logic (replaces reg and wire confusion)

User-defined typedef

Enumerated types (enum)

Structures (struct) and unions (union)

2-state (bit) and 4-state (logic) types

CONT..
▪ Procedural Blocks
▪ always_comb (for combinational logic)

▪ always_ff (for sequential logic)

▪ always_latch (for latch-based designs)

▪ Interfaces
▪ Encapsulates multiple signals into a single block to simplify
module connections.
CONT..
▪ Enhanced Operators and Constructs
▪ Packed/unpacked arrays
▪ Multidimensional arrays
▪ Enhanced case statements (unique case, priority case)
▪ Parameterized classes and modules

▪ Assertions (SVA)
▪ Immediate and concurrent assertions for design verification.

▪ Randomization
▪ Built-in random number generation for constrained random testing.
ADVANTAGES OF SYSTEM VERILOG OVER VERILOG
Feature Verilog System Verilog
Rich types (logic, bit, enum, struct,
Data Types Limited (reg, wire)
etc.)
Procedural always_ff, always_comb,
always (ambiguous)
Blocks always_latch for clarity
Design &
Primarily design Unified design + verification
Verification
Interfaces Not supported Supported (simplifies connectivity)
OOP Support No Yes (class-based verification)
Assertions No Yes (SystemVerilog Assertions)
Yes (constrained random
Randomization No
generation)
Reusability Limited High (OOP, parameterization)
 SCHEMATIC VS HDL
Schematic HDL
✓ Good for multiple data flow
✓ Flexible & parameterisable
✓ Give overview picture
✓ Excellent input to optimisation & synthesis
✓ Relate directly to hardware
✓ Direct mapping to algorithms
✓ Don’t need good programming skills
✓ Excellent for datapaths
✓ High information density
✓ Easy to handle electronically (only needing a
✓ Easy back annotations
text editor)
✓ Useful for mixed analogue/digital

✕ Not good for algorithms

✕ Serial representation
✕ Not good for datapaths
✕ May not show overall picture
✕ Poor interface to optimiser
✕ Need good programming skills
✕ Poor interface to synthesis software
✕ Divorce from physical hardware
✕ Difficult to reuse
✕ Difficult to parameterise
 SYSTEM VERILOG HDL
◆ Similar to C language to describe/specify hardware
◆ Description can be at different levels:
• Behavioural level
• Register-Transfer Level (RTL)
• Gate Level
◆ Not only a specification language, also with associated
simulation environment
◆ Easier to learn and “lighter weight” than its competition: VHDL
◆ Very popular with chip designers
 HDL TO GATES
❖Simulation
▪ Inputs applied to circuit
▪ Outputs checked for correctness
▪ Millions of dollars saved by debugging in simulation instead of hardware
❖Synthesis
▪ Transforms HDL code into a netlist describing the hardware (i.e., a list of
gates and the wires connecting them)
❖Physical design
▪ Placement, routing, chip layout, …… – not considered in this module
SYSTEM VERILOG: MODULE DECLARATION
❖ Two types of Modules:
▪ Behavioral: describe what a module does
▪ Structural: describe how it is built from simpler modules

❖ module/endmodule: required to begin/end module

❖ example: name of the module
 SYSTEM VERILOG: BEHAVIOURAL DESCRIPTION

synthesis

simulation

Based on: “Digital Design and Computer Architecture (RISC-V Edition)”

by Sarah Harris and David Harris (H&H),
 SYSTEM VERILOG: SYNTAX
❖ Case sensitive
▪ e.g.: reset and Reset are not the same signal.
❖ No names that start with numbers
▪ e.g.: 2mux is an invalid name
❖ Whitespace ignored
❖ Comments:
▪ // single line comment
▪ /* multiline
▪ comment */

Based on: “Digital Design and Computer Architecture (RISC-V Edition)”

by Sarah Harris and David Harris (H&H),
System Verilog: Structural Description

Behavioural Structural
▪ MODULE AND_TB;
▪ LOGIC A,B,C,Y;
▪ AND3 AN1(a,b,c,y);
▪ Initial begin
▪ A=1,B=1; #10;

▪ $FINISH;
▪ END
▪ ENDMODULE
▪ Step-by-Step Process
▪ 1. Compile the Design and Testbench
▪ Use ncvlog to compile .sv (SystemVerilog) files:
▪ bash
▪ ncvlog -sv design.sv -mess
▪ ncvlog -sv testbench.sv -mess
▪ -sv tells ncvlog that the files are SystemVerilog.
▪ You can add other flags like +access+r to enable full signal access during simulation.
▪ 2. Elaborate the Design
▪ Use ncelab to elaborate the top-level module (usually your testbench module):
▪ bash
▪ ncelab -access +r testbench
▪ Replace testbench with the name of your top-level module if different.
▪ 3. Simulate the Design
▪ Use ncsim to simulate the elaborated design:
▪ bash
▪ ncsim testbench -gui
 SYSTEM VERILOG: BITWISE OPERATORS

Based on: “Digital Design and Computer Architecture (RISC-V Edition)”

by Sarah Harris and David Harris (H&H),
 SYSYTEMVERILOG: REDUCTION OPERATORS

Based on: “Digital Design and Computer Architecture (RISC-V Edition)”

by Sarah Harris and David Harris (H&H),
SYSTEM VERILOG: CONDITIONAL ASSIGNMENT
SYSTEM VERILOG: INTERNAL SIGNALS
 SYSTEM VERILOG: PRECEDENCE OF OPERATORS

Highest

Lowest
Based on: “Digital Design and Computer Architecture (RISC-V Edition)”
by Sarah Harris and David Harris (H&H),
 SYSTEM VERILOG: NUMBER FORMAT
Format: N'Bvalue
N = number of bits, B = base
N'B is optional but recommended (default is decimal)

Number # Bits Base Decimal Stored

Equivalent

3'b101 3 binary 5 101

'b11 unsized binary 3 00…0011
8'b11 8 binary 3 00000011
8'b1010_1011 8 binary 171 10101011
3'd6 3 decimal 6 110
6'o42 6 octal 34 100010
8'hAB 8 hexadecimal 171 10101011
42 Unsized decimal 42 00…0101010
Based on: “Digital Design and Computer Architecture (RISC-V Edition)”
by Sarah Harris and David Harris (H&H),
SYSTEM VERILOG: BIT MANIPULATIONS (1)

❖If y is a 12-bit signal, the above statement produces:

❖ Underscores (_) are used for formatting only to make it

easier to read. System Verilog ignores them.
 SYSTEM VERILOG: BIT MANIPULATIONS (2)

Based on: “Digital Design and Computer Architecture (RISC-V Edition)”

by Sarah Harris and David Harris (H&H),
 SYSTEM VERILOG: FLOATING OUTPUT Z

❖Note that Verilator does not handle floating output Z

Based on: “Digital Design and Computer Architecture (RISC-V Edition)”
by Sarah Harris and David Harris (H&H),
 SYSTEM VERILOG: DELAYS

❖ Delays are for simulation only! They do not determine

the delay of your hardware.
❖ Verilator simulator ignores delays – it is cycle
accurate without timing.

Based on: “Digital Design and Computer Architecture (RISC-V Edition)”

by Sarah Harris and David Harris (H&H),
 SYSTEM VERILOG: SEQUENTIAL LOGIC
❖ System Verilog uses idioms (or special keywords or groups of words)
to describe latches, flip-flops and FSMs
❖ Other coding styles may simulate correctly but produce incorrect
hardware
❖ GENERAL STRUCTURE:

❖ Whenever the event in sensitivity list occurs,

statement is executed

Based on: “Digital Design and Computer Architecture (RISC-V Edition)”

by Sarah Harris and David Harris (H&H),
 SYSTEM VERILOG: D FLIP-FLOP

Based on: “Digital Design and Computer Architecture (RISC-V Edition)”

by Sarah Harris and David Harris (H&H),
 System Verilog: Resettable D Flip-Flop
Asynchronous reset Synchronous reset

Based on: “Digital Design and Computer Architecture (RISC-V Edition)”

by Sarah Harris and David Harris (H&H),
 COMBINATIONAL LOGIC USING ALWAYS

This hardware could be described with assign statements using fewer lines
of code, so it’s better to use assign statements in this case.
Based on: “Digital Design and Computer Architecture (RISC-V Edition)”
by Sarah Harris and David Harris (H&H),
What is System Verilog?
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 System Verilog ?
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 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 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 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 System Verilog

❑ For complex designs ❑ Less RTL & verification code

large number of RTL code is
required ❑ Less code hence less no. of bugs

❑ 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 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 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 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”
VERIFICATION GUIDELINES
▪ Introduction
■ Functional Coverage
▪ The Verification Process
■ Testbench Components
▪ The Verification Plan
■ Layered Testbench
▪ The Verification Methodology
Manual ■ Building a Layered Testbench

▪ Basic Testbench Functionality ■ Simulation Environment Phases

▪ Directed Testing ■ Maximum Code Reuse

▪ Methodology Basics ■ Testbench Performance
▪ Constrained-Random Stimulus

▪ What Should You Randomize?

55
WHAT IS VERIFICATION
▪ Process of demonstrating functional correctness of a design.
▪ Process that ensures specification is preserved in the
implementation.
▪ Different from validation and testing
– Validation ensures that product/design satisfied user needs
– Testing ensures that product is manufactured correctly

56
WHAT IF WE DON’T VERIFY?
▪ Is it possible to guarantee a design without verification?
– Incorrect/Insufficient Specifications
– Misinterpretation of specifications
– Misunderstanding between designers
– Missed cases
– Protocol non-conformance
▪ Implications on the final system
– Incorrect interaction between IPs/Cores
– Conflict in accessing shared resources
– Deadlock and arbitration
– Priority conflicts in exception handling
57
THE IMPORTANCE OF VERIFICATION
▪ 70% of design effort goes in verification
▪ Bug escapes to silicon can be costly including re-spin
– 50% reason for re-spins are because of bugs. Hence
the need to find all bugs early
▪ Ever increasing complexity of designs makes this
harder
▪ Hence Verification is always on critical path for any
product design
▪ Verification time can be reduced by
– Parallelism
– Abstraction
– Automation 58
VERIFICATION SPACE
▪ What to Verify?
– Functional Verification
– Timing Verification
– Performance Verification
▪ How to Verify?
– Simulation based Verification
– Emulation/FPGA based Verification
– Formal Verification
– Semi-Formal Verification
– HW/SW Co- Verification
59
WHAT IS A VERIFICATION PLAN?
▪ Verification plan is the specification document for verification
effort
– Design specification is the golden reference
– Mechanism to ensure all essential features are verified as
needed
▪ What to verify ?
– Features and under what conditions to verify them
▪ How to verify ?
– What methodologies to use
– Formal, Checking, Coverage etc.
– What should be - Stimulus, Checkers, Coverage
▪ Priority for features to be verified
60
– Schedules should be extractable from a detailed plan
VERIFICATION APPROACHES
▪ Black-Box
▪ Verification without knowledge of design implementation.
▪ Lack of visibility and observability.
▪ Tests are independent of implementation.
▪ Impractical in todays designs.
▪ White Box
▪ Intimate knowledge of design implementation
▪ Full visibility and observability
▪ Tests are tied to a specific implementation
▪ Grey Box
▪ Compromise between above approaches
61
LEVELS OF VERIFICATION
▪ Each level of Verification will be
suited for a specific objective
– Lower levels have better
controllability and visibility
▪ Block level Verification helps
designs to be verified
independently and in parallel
▪ System Level Verification
focuses more on interactions

62
 DIRECTED VS RANDOM TESTING DIRECTED
▪ Can only cover Constrained Random
scenarios thought  High ramp up time to build smart
through planning test generators
▪ High maintenance cost  Need to identify and implement
▪ Works good when Functional Coverage
condition space is finite  Deep User control. Complex Test
▪ No need of extensive generator
coverage coding  Best balance between engineer
time and compute time
 Can have static and dynamic
(during test run) randomness
63
DIRECTED VS. RANDOM TESTING

64
 DIRECTED TESTING
▪Hardware specification and verification plan with a list of tests.

▪Write a stimulus vectors based on DUT

▪Design complexity increases testing time is also increasing

DIRECTED TEST COVERAGE
DIRECTED TEST COVERAGE
▪ Above fig shows the total design space and the features that get
covered by directed testcases.
▪ In this space are many features, some of which have bugs.
▪ Need to write tests that cover all the features and find the bugs.
VERIFICATION METHODOLOGY BASICS
Constrained-random stimulus
▪„

▪ „Functional coverage „
▪ Layered testbench using transactors „
▪ Common testbench for all tests
▪ „Test-specific code kept separate from testbench
VERIFICATION METHODOLOGY BASICS
▪ Random stimulus is crucial for exercising complex designs.
▪ A directed test finds the bugs you expect to be in the design, while a
random test can find bugs you never anticipated
CONSTRAINT RANDOM TEST PROGRESS
▪ When the simulator to generate the stimulus, don’t want
totally random values. use the System Verilog language to
describe the format of the stimulus (“address is 32-bits,
opcode is X, Y, or Z, length < 32 bytes”),
▪ The simulator picks values that meet the constraints.
▪ Constraining the random values to become relevant stimuli.
▪ These values are sent into the design, and also into a high-
level model that predicts what the result should be.
▪ The design’s actual output is compared with the predicted
output.
CONSTRAINT RANDOM TEST PROGRESS
CONSTRAINT RANDOM TEST PROGRESS
▪ Every test you create shares this common testbench, as
opposed to directed tests where each is written from
scratch.
▪ Each random test contains a few dozen lines of code to
constrain the stimulus in a certain direction and cause
any desired exceptions, such as creating a protocol
violation. The result is that your single constrained-
random testbench is now finding bugs faster than the
many directed ones.
▪ As the rate of discovery begins to drop off, you can
create new random constraints to explore new areas.
The last few bugs may only be found with directed
tests, but the vast majority of bugs will be found with
random tests.
CONSTRAINED –RANDOM STIMULUS

Figure: Coverage convergence

CONSTRAINED –RANDOM STIMULUS
▪ Start at the upper left with basic constrained-random tests.
▪ Run them with many different seeds.
▪ When you look at the functional coverage reports, find the
holes, where there are gaps.
▪ Now you make minimal code changes, perhaps with new
constraints, or injecting errors or delays into the DUT.
▪ Spend most of your time in this outer loop, only writing
directed tests for the few features that are very unlikely to be
reached by random tests.
 WHAT SHOULD YOU RANDOMIZE
When you think of randomizing the stimulus to a design, the
first thing that you might think of is the data fields. This stimulus
is the easiest to create – just call $random. need to think
broadly about all design input, such as the following.
▪ Device configuration
▪ Environment configuration
▪ Input data
▪ Protocol exceptions
▪ Delays
▪ Errors and violations.
FEEDBACK FROM FUNCTIONAL COVERAGE TO STIMULUS
TEST BENCH COMPONENTS
Test bench Environment

▪ In simulation, the test bench wraps around the DUT , just as a

hardware.
▪ Both the test bench and tester provide stimulus and capture
responses.
▪The difference between them is that your test bench needs to work
over a wide range of levels of abstraction.
DATA TYPES IN SYSTEM VERILOG
WHY SYSTEM VERILOG

•Gains in productivity/maintainability/thoroughness
• Recall graphs of directed versus random testing.
•Automatic generation and direction of stimulus
•Functional Coverage
•Higher level RTL
•Required for complex designs
TOOLS SUPPORT FOR SYSTEM VERILOG
THE LOGIC DATA TYPE

logic is has single driver (procedural assignments or a continuous

assignment), can replace reg and single driver wire. (Equivalent to
“std_ulogic” in VHDL)
EXAMPLE LOGIC DATE TYPE
TWO-STATE TYPES
TWO-STATE TYPES
TWO-STATE TYPES CONTD..
TWO STATE DATA TYPES EXAMPLE
FIXED-SIZE ARRAYS
▪ System Verilog offers several flavors of arrays beyond
the single-dimension.
▪ fixed-size Verilog-1995 arrays.
▪ Many enhancements have been made to these classic
arrays.
 DECLARING AND INITIALIZING FIXED-SIZE ARRAY
▪ Verilog requires that the low and high array limits must be given in the
declaration.
▪ Almost all arrays use a low index of 0, so System Verilog lets you use the
shortcut of just giving the array size, similar to C:
Example: Declaring fixed-size arrays
int lo_hi[0:15]; // 16 ints [0]..[15]
int c style[16]; // 16 ints [0]..[15]
Example : Declaring and using multidimensional arrays
int array2 [0:7][0:3]; // Verbose declaration
int array3 [8][4]; // Compact declaration
array2[7][3] = 1; // Set last array element
UNPACKED ARRAY DECLARATION
 THE ARRAY LITERAL
▪ we can initialize an array using an array literal that is an
apostrophe and curly braces.
▪ We can set some or all elements at once. You can replicate values
by putting a count before the curly braces.

▪ Example: Initializing an array

int ascend[4] = ’{0,1,2,3}; // Initialize 4 elements
int decend[5];
int md[2][3] = ’{’{0,1,2}, ’{3,4,5}};
descend = ’{4,3,2,1,0}; // Set 5 elements
descend[0:2] = ’{5,6,7}; // Set first 3 elements
ascend = ’{4{8}}; // Four values of 8
BASIC ARRAY OPERATIONS — FOR AND FOREACH
MULTIDIMENSIONAL ARRAY
BASIC ARRAY OPERATIONS – COPY AND COMPARE
 BIT AND ARRAY SUBSCRIPTS

In the above Example prints the first array element (binary 101),
its lowest bit (1), and the next two higher bits (binary 10).
ARRAY OPERATIONS EXERCISE
UNPACKED ARRAY EXAMPLE
 PACKED ARRAYS
▪ For some data types, you may want both to access the
entire value and also divide it into smaller elements.
▪ For example, you may have a 32-bit register that
sometimes you want to treat as four 8-bit values and at
other times as a single.
▪ Unsigned value. A System Verilog packed array is
treated as both an array and a single value.
▪ It is stored as a contiguous set of bits with no unused
space, unlike an unpacked array.
PACKED ARRAYS
DECLARATION FOR MIXED PACKED/UNPACKED ARRAY
PACKED ARRAYS EXAMPLE
PACKED AND UNPACKED EXERCISE
PACKED AND UNPACKED EXERCISE
 DYNAMIC ARRAYS
▪A dynamic array is declared with empty word
subscripts [].
▪ This means
▪ that you do not want to give an array size at compile
time; instead, you specify it at run-time.
▪ The array is initially empty, so you must call the new[]
operator to allocate space, passing in the number of
entries in the square brackets.
▪ If you pass the name of an array to the new[] operator,
the values are copied into the new elements.
DYNAMIC ARRAYS
DYNAMIC ARRAYS
DYNAMIC ARRAYS
USING DYNAMIC ARRAYS
ARRAY METHODS
ARRAY REDUCTION METHODS
ARRAY LOCATOR METHODS
ARRAY LOCATOR
ARRAY LOCATOR
ARRAY SORTING AND ORDERING
QUEUES IN SYSTEM VERILOG
QUEUE OPERATIONS
QUEUES EXERCISE
 ASSOCIATIVE ARRAY
▪ Dynamic arrays are good if you want to occasionally
create a large array, but what if you want something
really huge? Perhaps you are modeling a processor that
has a multi-gigabyte address range. During a typical test,
▪ The processor may only touch a few hundred or
thousand memory locations containing executable code
and data.
▪ So allocating and initializing gigabytes of storage is
wasteful.
▪ System Verilog offers associative arrays that store entries
in a sparse matrix.
 ASSOCIATIVE ARRAY
▪ This means that while you can address a very large address
space,
▪ System Verilog only allocates memory for an element when
you write to it.
▪ In the following picture, the associative array holds the
values 0:3, 42, 1000,
▪ 4521, and 200,000. The memory used to store these is far
less than would be
▪ needed to store a fixed or dynamic array with 200,000
entries.
ASSOCIATIVE ARRAY
ASSOCIATIVE ARRAY
ASSOCIATIVE ARRAY
ASSOCIATIVE ARRAY CONTD..
CHOOSING STORAGE TYPE
CHOOSING STORAGE TYPE
CHOOSING STORAGE TYPE
CREATING NEW TYPES WITH TYPEDEF

▪ we can create new types using the typedef statement.

▪ For example, we may have an ALU that can be configured
at compile-time to use on 8, 16, 24, or 32-bit operands.
▪ In Verilog you would define a macro for the operand width
and another for the type.
USER-DEFINED TYPE-MACRO IN VERILOG

// Old Verilog style

`define OPSIZE 8
`define OPREG reg [`OPSIZE-1:0]
`OPREG op_a, op_b;

we are not really creating a new type; we are just performing text
substitution. In System Verilog you create a new type.
 USER-DEFINED TYPE IN SYSTEM VERILOG
// New SystemVerilog style
parameter OPSIZE = 8;
typedef reg [OPSIZE-1:0] opreg_t;
opreg_t op_a, op_b;

Definition of uint
typedef bit [31:0] uint; // 32-bit unsigned 2-state
typedef int unsigned uint; // Equivalent definition
CREATING NEW TYPES WITH TYPEDEF
CREATING USER-DEFINED STRUCTURES
CREATING A SINGLE PIXEL TYPE

▪ struct {bit [7:0] r, g, b;} pixel;

The problem with the above declaration is that it creates a

single pixel of this type. To be able to share pixels using
ports and routines, you should create a new type instead.

typedef struct {bit [7:0] r, g, b;} pixel_s;

pixel_s my_pixel;

Use the suffix “_s” when declaring a struct. This makes

it easier for you to share and reuse code.
TYPEDEF AND STRUCTURES EXERCISE
TYPEDEF AND STRUCTURES EXERCISE
 PACKED STRUCTURES
▪ System Verilog allows you more control in how data is laid out in
memory by using packed structures.
▪ A packed structure is stored as a contiguous set of bits with
no unused space.
▪ The struct for a pixel, shown below, used three data
values, so it is stored in three long words, even though it only
needs three bytes. You can specify that it should be packed
into the smallest possible space.

EX: typedef struct packed {bit [7:0] r, g, b;} pixel_p_s;

pixel_p_s my_pixel;
PACKED STRUCTURES
PACKAGES
 ENUM DATA TYPE
▪ An enumerated type defines a set of named values. The simplest enumerated
type declaration contains a list of constant names and one or more variables.
module enum_datatype;

//declaration
enum { red, green, blue, yellow, white, black } Colors;

//display members of Colors

initial begin
Colors = Colors.first;
for(int i=0;i<6;i++) begin
$display("Colors :: Value of %0s \t is = %0d",Colors.name,Colors);
Colors = Colors.next;
end
end

endmodule
 ENUM METHODS
Method Description
returns the value of the first member of the
first()
enumeration
returns the value of the last member of the
last()
enumeration
returns the value of next member of the
next()
enumeration
returns the value of next Nth member of the
next(N)
enumeration
returns the value of previous member of the
prev()
enumeration
returns the value of previous Nth member of
prev(N)
the enumeration
returns the number of elements in the given
num()
enumeration
returns the string representation of the given
name()
enumeration value
module enum_datatype;

//declaration
enum { red=0, green, blue=4, yellow, white=10, black } Colors;

//display members of Colors

initial begin
Colors = Colors.first;
for(int i=0;i<6;i++) begin
$display("Colors :: Value of %0s \t is =
%0d",Colors.name,Colors);
Colors = Colors.next;
end
end

endmodule
module enum_datatype;
//declaration
enum { red=0, green=1, blue=4, yellow, white=5, black=6
} Colors;

initial begin
Colors = Colors.first;
for(int i=0;i<6;i++)
$display("Colors :: Value of %0s is =
%0d",Colors.name(),Colors);
end
endmodule
 Example shows declaring new data types using the enumerated type
module enum_datatype;
//declaration
typedef enum {GOOD, BAD} pkt_type;
pkt_type pkt_a;
pkt_type pkt_b;

initial begin
pkt_a = GOOD;
pkt_b=BAD;

if(pkt_a == GOOD)
$display("pkt_a is GOOD packet");
else
$display("pkt_a is BAD packet");

if(pkt_b == GOOD)
$display("pkt_b is GOOD packet");
else
$display("pkt_b is BAD packet");
end
endmodule
ENUMERATED TYPES
ENUMERATED TYPES
ENUMERATED TYPES
ROUTINES FOR ENUMERATED TYPES

▪ System Verilog provides several functions for stepping through

enumerated types.
▪ first returns first member of the enumeration.
▪ last returns last member of the enumeration.
▪ next returns the next element of the enumeration.
▪ next(N) returns the Nth next element.
▪ prev returns the previous element of the enumeration.
▪ prev(N) returns the Nth previous element.
ROUTINES FOR ENUMERATED TYPES
STEPPING THROUGH ALL ENUMERATED MEMBERS
EXAMPLE OF USAGE IN TESTBENCH
CONVERTING TO/FROM ENUM TYPES
CONVERTING TO/FROM ENUM TYPES
CONSTANTS IN SYSTEM VERILOG

System Verilog also supports the const modifier that allows

you to make a variable that can be initialized in the declaration
but not written by procedural code. The value of colon is
initialized when the initial block is entered.
STRINGS IN SYSTEM VERILOG
▪ Index : 0 1 2 3 4 5 6 7 8 ...
▪ Chars : A M I S e m i c ...
▪ s.substr(3,7)
▪ s[3] = " " (space)
▪ s[4] = "S"
▪ s[5] = "e"
▪ s[6] = "m"
▪ s[7] = "i“
▪ s.len() = 17
▪ s.len() - 13 = 17 - 13 = 4
▪ s.substr(4)
▪ 0:A 1:M 2:I 3:␣ 4:S 5:e 6:m 7:i 8:c 9:o
▪ 10:n 11:d 12:u 13:c 14:t 15:o 16:r
▪ s.substr(4) = "Semiconductor“
▪ s.substr(16) 16 = "r"
COVERAGE
▪ What is Coverage?
– Coverage is the metric of completeness of verification
▪ Why coverage?
– Verification is based on samples
▪ Cannot run all possible tests (2n) to cover full space
▪ Need to know that all areas of the design have been
verified
▪ Quality of a test suite is not a measure of it’s size
– Solution:
▪ Coverage Analysis
System Verilog 9/17/2025 179
COVERAGE (2)
▪ Coverage Goals
▪ Measure the quality of a test suite
▪ Tell a verification engineer when to stop! – Achieve 100%
▪ Coverage Metrics
▪ Systematically created list of verification tasks
▪ Check that each task has been covered during verification
▪ Supplement verification plan by pointing to untested areas
▪ Help create/better regression suites
▪ Forms of Coverage
▪ Structural (Code)
▪ Functional coverage
System Verilog 9/17/2025 180
CODE COVERAGE
▪ Statement
▪ Has each statement of the source code been executed?
▪ Branch
▪ Has each control structure been evaluated to both true and
false?
▪ Example: if, case, while, repeat, forever, for, loop
▪ Condition
▪ Has each Boolean sub-expression evaluated both to true and
false?
▪ Extension of Branch coverage for conditional expressions

System Verilog 9/17/2025 181

FUNCTIONAL COVERAGE
▪ Covers the functionality of the DUT
▪ Define functional coverage metrics in the verification plan
▪ Functional Coverage is derived from design specification –
DUT Inputs
▪ Are all input operations injected?
▪ DUT Outputs/functions
▪ Are all responses seen from every output port?
▪ DUT internals –
▪ Are all interested design events being verified?
▪ – e.g. FIFO full, arbitration mechanisms etc.

System Verilog 9/17/2025 182

 CODE COVERAGE (2)
▪ Expression – Counts the no. of times an expression on the
RHS of an assignment statement is executed – Example: x
<= a xor (not b);
▪ Toggle – counts each time a logic node transitions from
one state to another – Standard – covers 0->1 and 1->0
transitions – Extended – covers 0<->1, z<->1 and z<->0
transitions
▪ FSM – counts state reachability and transitions – State
coverage and FSM Arc coverage

System Verilog 9/17/2025 183

COVERAGE DRIVEN VERIFICATION
▪ Coverage Analysis Functional Coverage Code Coverage
Interpretation Low Still lot of verification to do Low High
Muti-cycle scenarios, corner cases, cross- correlations still
to be covered High Low Verification plan and/or functional
coverage metrics inadequate. Possibility of duplicate/dead
code High High High confidence in verification quality

System Verilog 9/17/2025 184

DIFFERENCE BETWEEN VERILOG AND SYSTEM VERILOG
Sl.No. VERILOG SYSTEMVERILOG
SystemVerilog is a combination of both Hardware
01. Verilog is a Hardware Description Language (HDL). Description Language (HDL) and Hardware Verification
Language (HVL).
Verilog language is used to structure and model System Verilog language is used to model, design,
02.
electronic systems. simulate, test and implement electronic system.
03. It supports structured paradigm. It supports structured and object oriented paradigm.
04. Verilog is based on module level testbench. System Verilog is based on class level testbench.
05. It is standardized as IEEE 1364. It is standardized as IEEE 1800-2012.
Verilog is influenced by C language and Fortran System Verilog is based on Verilog, VHDL and c++
06.
programming language. programming language.
07. It has file extension .v or .vh It has file extension .sv or .svh
It supports various datatypes like enum, union, struct,
08. It supports Wire and Reg datatype.
string, class.
09. It is based on hierarchy of modules. It is based on classes.
It was began in 1983 as proprietary language for It was originally intended as an extension to Verilog in
10.
hardware modelling. the year 2005.
1. System Verilog Data Types
enum – enumerated types
2-State Data Types
typedef enum {RED, GREEN, BLUE} color_t;
bit – 1-bit, 0 or 1 color_t c;
c = RED;
bit b;
b = 1;
struct – user-defined composite type

byte – 8-bit signed integer typedef struct {

int id;
shortint – 16-bit signed integer logic valid;
} packet_t;
int – 32-bit signed integer
packet_t pkt;
longint – 64-bit signed integer pkt.id = 5;
pkt.valid = 1;
4-State Data Types

logic – can hold 0, 1, X, Z string – sequence of characters

logic l; package – collection of types, parameters, functions

l = 1'bx;
 3. Memories and Arrays
2. Type Conversion
Fixed-size array
Dynamic casting
int arr[5];
class Base; endclass
class Derived extends Base; endclass
Dynamic array
Base b;
Derived d;
int darr[];
d = Derived::cast(b); // dynamic cast
darr = new[10]; // allocate size

Static casting
Multidimensional array
d = Derived'(b); // static cast
int matrix[3][3];
Packed array – bits packed for slicing

bit [7:0] packed_arr;

Associative array – indexed by keys

int assoc_arr[string];
assoc_arr["Alice"] = 10;

Queue – FIFO structure

int q[$];
q.push_back(5);
q.push_front(10);
int val = q.pop_front();

Array Methods: push_back, pop_back, insert, delete, size, sort, etc.