0% found this document useful (0 votes)
48 views

SystemVerilog Part I

Uploaded by

Laith Qasem
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
48 views

SystemVerilog Part I

Uploaded by

Laith Qasem
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 74

ENCS5337: Chip Design Verification

Spring 2023/2024

SystemVerilog Part I

Dr. Ayman Hroub


Outline
 Introduction
 Data Types
 Operators
 Procedural Statements and Procedural Blocks
 Design and Verification Building Blocks

2
What is SystemVerilog?
 SystemVerilog is a unified hardware specification,
description (design) and verification language.

 SystemVerilog is an extension of Verilog.

 SystemVerilog can be divided based on its roles,


o SystemVerilog for design is an extension of Verilog-2005
o SystemVerilog for verification.

3
History
 It is Verilog-2001 extension

 Contains hundreds of enhancements and extensions to Verilog

 In 2005, became an IEEE standard.

 Officially superseded Verilog in 2009

 Updated with more features in 2012, 2017, and 2023

4
SV Verilog-2001 Extensions
 Added data types and relaxation of rules on existing data types
 Higher abstraction-level modeling features
 Language enhancements for synthesis
 Interfaces to model communication between design blocks
 Language features to enable verification methodologies
 Assertions, constrained randomization, functional coverage
 Lightweight interface to C/C++ programs

5
Outline
 Introduction
 Data Types
 Operators
 Procedural Statements and Procedural Blocks
 Design and Verification Building Blocks

6
What is a Datatype
 A datatype is a set of values (2-state or 4-state) that can be used
to declare data objects or to define user-defined data types.

 All Verilog datatypes except real have 4-state values: (0, 1, Z,


X).
 4-state logic is essential for gate-level modeling and for
initialization at RTL

 Howeover, simulating everything in 4-state logic can add


significant performance overhead.

7
SystemVerilog 2-State Datatype
 SystemVerilog adds 2-state value types based on bit:
 Has values 0 and 1 only.
 Direct replacements for reg, logic or integer.
 Greater efficiency at higher-abstraction level modeling (RTL).
 SystemVerilog defines the following predefined bit types of various
widths

8
SystemVerilog Real Data Type

 SystemVerilog also defines a 32-bit


floating-point type, shortreal, to
complement the 64-bit Verilog real type.

9
System Verilog Logic DataType
 logic defines that the variable or net is a 4-state data type.
 Initial value is x
 It can be driven in both procedural blocks and assign statements
 Cannot have multiple drivers

10
System Verilog Bit DataType
 2-state data type (0,1)

 Initial value is 0

 bit is not signed by default

 It is useful in the cases where not all 4 values are needed. This helps
to reduce the simulation time and the required memory

 When a 4-state value is converted to a 2-state value, any


unknown or high impedance bits shall be converted to zeros

11
Integer Data Types
 There are two data types of integers:
o 2-state types can take only 0 , 1 values.
o 4-state types can take 0 , 1 , X , Z values.
 Integer types can be signed or unsigned, which can change
the result of a arithmetic operation.
 $bits(var) is a system task that returns the number of bits
in var
 signed and unsigned can be defined explicitly, e.g.,
reg unsigned var1;
shortint signed var2;
(4-state) Data Type description (2-state) Data Type description
logic shortint 16-bit signed integer
reg User defined vector types int 32-bit signed integer
wire longint 64-bit signed integer
integer 32-bit signed integer byte 8-bit signed integer
12
Outline
 Introduction
 Data Types
 Operators
 Procedural Statements and Procedural Blocks
 Design and Verification Building Blocks

13
Assignment Operators (1)
 Operators that join an operation along with a
blocking assignment to the first operand of
the operator.
 Assignment operators are blocking
assignments.
 Therefore, they are suitable for use only in:
– RTL combinational logic
– Temporary variables in RTL sequential code
– Testbench and stimulus.

14
Assignment Operators (2)

15
Pre- and Post-Increment/Decrement Operators

 Pre-form (++a, --a) adds or subtracts and then


uses new value.
 Post-form (a++, a--) uses a value and then adds or
subtracts.

16
SV Operators Associativity and Precedence

17
Strings

 The string data type in SystemVerilog is an


ordered collection of characters (ASCII
characters).

string myString = “Welcome to HW DV Course”;


$display (“%s”, myString);
$display (“%s”, myString[0]);

18
SystemVerilog String Operators

19
SystemVerilog String Methods

20
Enumeration
 An enumerated type declares a set of integral named
constants, i.e., it defines a set of named values

 In the absence of a data type declaration, the default data


type shall be int

 E.g., enum {red, yellow, green} light1, light2;

// silver=4, gold=5
enum {bronze=3, silver, gold} medal;
enum {a=0, b=7, c, d=8} alphabet;//error

21
Defining New data types as Enumerated Types

 A type name can be given so that the same type can be


used in many places.
 e.g., typedef enum {NO, YES} boolean;
boolean myvar; // named type

22
Some Enumerated Types Methods
 first()returns the value of the first member of the enumeration.
 last() returns the value of the last member of the enumeration.
 next() returns the Nth next enumeration value
 prev() returns the Nth previous enumeration value
 num() returns the number of elements in the given enumeration

23
Structures
 A structure represents a collection of data types that can
be referenced as a whole, or the individual data types
that make up the structure can be referenced by name.

// named structure type


typedef struct
{ bit [7:0] opcode; bit [23:0] addr;}
instruction;
instruction IR; // define variable
IR.opcode = 8;

24
Outline
 Introduction
 Data Types
 Operators
 Procedural Statements and Procedural
Blocks
 Design and Verification Building Blocks

25
for Loop

26
foreach Loop
 This loop iterates over all the elements of an
array
 Loop variable characteristics:
– Does not have to be declared.
– is read only.
– Only visible inside loop.
 Use multiple loop variables for multidimensional
arrays.
– Equivalent to nested loops.
 Useful for initializing and array processing.
27
foreach Loop (cont.)

28
while Loop
 The while loop executes a group of statements
until expression becomes false.

 expression is checked at the beginning.

29
do...while Loop
 The expression is checked after statements
execute.
 The statement block executes at least once.
 This makes certain loop functions easier to
create.

30
break and continue
 SystemVerilog adds the break and continue
keywords to control execution of loop
statements.
 break
 Terminates the execution of loop immediately.
 Usually under conditional control.
 continue
 Jumps to the next iteration of a loop.
 Usually under conditional control.
 Also used in for, while, repeat and do-
while loops
31
break and continue (Cont.)

32
always_comb
 It is specialized procedural block for modeling
combinational logic

 Implied, complete sensitivity list.

 Any variable assigned in an always_comb


cannot be assigned by another procedure.

 Cannot contain further blocking timing or event


control.
33
always_comb (cont.)
 Automatically executed once at time 0 without
waiting for an event.
 After all initial and always blocks have executed.
 Ensures outputs are consistent with inputs.

 Tools may issue warnings if the block does not


infer combinational logic.

34
always_comb (cont.)

35
always_comb vs. always@*
always@* always_comb
 Can include timing and  Cannot contain any timing or
additional event controls. event controls.

 Can assign to variables which  Cannot assign to variables


are assigned elsewhere. which are assigned elsewhere.

 Triggered at time 0 with other  Automatically triggered at time


blocks only if event on 0 after always and initial
sensitivity list. blocks.

36
always_latch
 It is a specialized procedural block for modeling
latched logic.

 Implied, complete sensitivity list.

 Variables assigned in an always_latch cannot


be assigned by another procedure.

 Cannot contain further block timing or event


control.
37
always_latch (Cont.)
 Automatically executed once at time 0 without
waiting for an event:
 After all initial and always blocks have executed.
 Ensuring outputs are consistent with inputs.
 Tools can issue warnings if the block does not
infer latched logic.

38
always_latch (Cont.)

39
always flip-flop(always_ff)
 It is a specialized procedural block for modeling
registered logic.
 Variables assigned in always_ff cannot be
assigned by another procedure.
 Contains one and only one event control.
 Cannot contain any block timing.
 Tools may issue warnings if the block does not
infer registered logic.

40
always flip-flop(always_ff)

41
Outline
 Introduction
 Data Types
 Operators
 Procedural Statements and Procedural Blocks
 Design and Verification Building Blocks

42
Design Elements
 module, program, interface, checker, package,
primitive and config (configuration) are called
design elements in a SystemVerilog.

 These elements are primary building blocks used to


model a design and verification environment.

43
Module
 The basic building block in SystemVerilog is the module
 Modules are used to represent design blocks.

 The module is enclosed between the keywords module


and endmodule.

 Modules are primarily used to represent design blocks,


but can also serve as containers for verification code
and interconnections between verification blocks and
design blocks.

44
Module Example

45
Packages

 New design element similar to a module:


– Must be compiled separately.
– Must be compiled before elements that
reference the package.
 They contain declarations to be shared
between elements:
– Types, variables, subroutines...

46
Package Example

47
Importing a Package

 Explicit – specifically named. Allows to reference selected


package declarations

 Implicit – all using wildcard (*)

 Or directly access a declaration using the resolution


operator (::):
 Does not require import.

48
Explicit Import
 An explicit import only imports the symbols specifically
referenced by the import.

 It directly loads declaration into the design element as if it was


declared in the design element.

 Declaration must be unique in the current scope:


 Compilation error if local and other explicitly imported declarations have
same name.

49
Wildcard Import
 A wildcard import allows all identifiers declared within a
package to be imported provided the identifier is not otherwise
defined in the importing scope.

 Local or explicitly imported declarations can override wildcard


imported declarations.

 Package declarations still visible through resolved name.

50
Wildcard Import Example

51
Program Block
 A program is very similar to a module, but intended for
testbench code.

 Program blocks have special features and restrictions for


testbench use.

 In particular, a program cannot instantiate hierarchy.


– Programs are leaf elements.
– Must be instantiated in a module.

52
Program Block (Cont.)
 The program is usually declared in a separate file, compiled
separately and then instantiated in a module or interface.

 In a verification methodology using programs, all testbench


code would be contained in programs, and all design
(synthesizable) code in modules.

 By using programs only for verification code and modules


or interfaces only for design code, race conditions between
design and testbench can be reduced

53
Program Example

54
Allowed Constructs in Program

55
final Procedural Block
 It is a procedural block that executes once at the end of
simulation:
 After explicit or implicit call to $finish.
 Cannot invoke scheduler (no scheduled assignments or
delays).
 Can be used to calculate and display simulation statistics.

56
Not Allowed Constructs in Program
 As a general rule, constructs that clearly represent design
rather than verification are not allowed.

57
Interfaces
 The interface encapsulates the communication between
design blocks, and between design and verification blocks

 It is a construct representing a bundle of defined wires. In


other words, it is a separately declared and named group of
signals.

 All connections associated with a specific interface are


declared and maintained in one place.

 Normally used to represent the signals which comprise a


single instance of a protocol interface between a DUT and a
testbench.

58
Interfaces (Cont.)
 The interface is created in a separate file and must be
compiled separately by the simulator.

 A useful abstraction used during testbench definition, avoiding


the need to replicate declarations for each member signal
along the way.

 The interface is instantiated in a design and can be connected


to interface ports of other instantiated modules, interfaces and
programs

59
Interfaces (Cont.)

60
Interfaces: Motivation
 One Verilog hierarchical connection between and a CPU and
memory modules requires 5 declarations:
 Two port declarations in modules mem and cpu
 Signal declaration in top
 Signal added to each instantiation of mem and cpu
 Problem: Creating and maintaining multiple connections is tedious.

61
Example: Without Interface

62
Example: With Interface

63
More Facts on Interfaces
 A SystemVerilog interface is declared as a design element like a module.

 It can be instantiated in a module, like a module instantiation, but the


interface name is also used as port type in module declarations to create
interface ports

 Interfaces can also contain module-like features for defining signal


relationships:
– Continuous assignments, tasks, functions, initial/always blocks, etc.
– Can further instantiate interfaces.

 Cannot declare or instantiate module-specific items: Modules, primitives,


specify blocks, and configurations.

 Interfaces can instantiate other interfaces to create nested interface


structures
64
Access Interface Items

65
Interface Ports

 An interface can have its own ports:


– Connected like any module port.
– Used to share an external signal.

66
modport
 To restrict interface access within a module, there are
modport lists with directions declared within the interface.

 The keyword modport indicates that the directions are


declared as if inside the module.

 Modports create different views of an interface.


– Specify a subset of interface signals accessible to a module.
– Specify direction information for those signals.
 We can specify a modport view for a specific module in two
ways:
– In the module declaration.
– In the module instantiation.

67
Modport (Cont.)
 An interface can have any number of modports, and each defines a
different view of the interface contents

 A module can specify which modport to use in its port list declaration

68
Modport (Cont.)
 The interface mod_if declares the following modports:

 ▪ Modport master which defines signals a and b as input and


signals c and d as output.

 Modport slave which defines signals a and b as output and


signals c and d as input.

 Modport subset which defines signal a as output and b as


input. Any connections to the interface via modport subset
would not be able to access signals c or d.

69
Selecting the Interface Modport by Qualifying the
Module Port Interface Type
 An interface modport can be selected using the module
declaration port of interface type.

70
Selecting the Interface Modport (Cont.)
 busmaster declares interface port mbus:
 Type is mod_if
 Modport is master
 busslave declares interface port sbus:
 Type is mod_if
 Modport is slave
 testbench instantiates interface and modules as before.

71
Selecting the Interface Modport by Qualifying the
Module Port Interface Binding
 An interface modport can be selected during the port mapping
of module instantiation.

72
Interface Methods
 A sub-routine defined within an interface is called an
interface method.

 We can declare tasks as part of the interface

 These tasks are accessible to any module connected to


the interface

73
Interface Methods Example

74

You might also like