1

Introduction to Verification

Lecture 4

High-Level Modeling

Introduction to Verification

Outline

RTL-Thinking vs High-Level Thinking

Structure of High-Level Code
Object-Oriented Programming
Parallel Simulation Engine
Simulation Cycle

Introduction to Verification

RTL-Thinking vs High-Level Thinking

Why verification engineer must break the RTL Mindset?

Insufficient in writing testbenches that was never intended to implement

in hardware
Numerous guidelines have been imposed to obtain efficient
implementation
If RTL mindset is kept verification task becomes tedious and complicated

Introduction to Verification

RTL-Thinking vs High-Level Thinking

RTL Guidelines: Avoiding Undesirable Hardware Structures

To avoid
latches
set all outputs of
combinatorial blocks
to default values at
the beginning of the
block

To avoid
internal buses
do not assign
registers from
two separate always
blocks

To avoid tristate buffers

do not assign the
value Z (VHDL) or
1bz (Verilog)

Introduction to Verification

RTL-Thinking vs High-Level Thinking

RTL Guidelines: Maintaining the Simulation Behavior
All inputs must be listed in the sensitivity list of a
combinatorial block
The clock and synchronous reset must be in the
sensitivity list of a sequential block
Use a nonblocking assignment when assigning to a reg
intended to be inferred as a flip-flop

Introduction to Verification

RTL-Thinking vs High-Level Thinking

Example:

The example above shows a simple handshaking protocol

Introduction to Verification

RTL-Thinking vs High-Level Thinking

enum {,MAKE_REQ,
RELEASE, }
state, next_state;
always_comb

end

RELEASE: begin
req <=1b0;
if (!ack)
begin
next_state <=
next_state <= state;
;
end
case(state)

endcase

end
MAKE_REQ: begin
always_ff @(posedge
req <= 1b1;
clk)
begin
if
if rst state <= ;
(ack)next_sate else state <=
<= RELEASE;
next_state;
end

RTL Coding Style

always
begin

req <= 1;
wait (ack);
req <= 0;
wait
(!ack);

end

High-Level
Coding Style

Introduction to Verification

Coding Style
Synthesizable subset puts several constraints on your coding style
With no restrictions in high-level modeling, unmaintainable, fragile
and not portable code is easy to achieve
Must have discipline code will need to be modified
Assume an inexperienced audience

Introduction to Verification

Structure of High-Level Code

Structuring code is the process of allocating portions of the
functionality to different modules or entities
For maintainability reasons, high-level code is structured according to
functionality or need

10

Introduction to Verification

Structure of High-Level Code

RTL MODELS

TESTBENCHES

- structured according to
implementation needs

- structured according to functional

needs

- modules/entities are connected

together to provide the complete
functionality of the design

- implemented using high-level

SystemVerilog code and have no
restrictions

- structure of synthesizable code

and has a direct impact on the
ease of meeting timing
requirements

- SystemVerilog code can be

structured using task, function,
class, module, program, interface,
package or inheritance

11

Introduction to Verification

Structure of High-Level Code

Application of structuring principle
that enables to hide implementation
details and decouple the usage of a
function from its implementation

A technique for minimizing

interdependencies among modules by
defining a strict external
communication

Encapsulation
internal coding can be changed
without affecting the communication,
so long as the new implementation
supports the same (or upwards
compatible) external communication

Prevents a program from becoming so

interdependent that a small change
has massive ripple effects

12

Introduction to Verification

Encapsulation
Keep declarations as local as possible to avoid accidental interactions
with another portion of the code where the declaration is also visible
int i;
always
begin
for (i = 0; i < 32; i
= i + 1) begin
...
end
end
always
begin
for (i = 15; i >= 0;
i = i - 1) begin
...
end
end

always
begin
int i;
for (i
i + 1)
...
end
end
always
begin
int i;
for (i
i - 1)
...
end
end

= 0; i < 32; i =
begin

= 15; i >= 0; i =
begin

13

Introduction to Verification

Encapsulation
SystemVerilog tasks and functions can contain local variables
task send(input [7:0] data);
reg parity;
...
endtask
function [31:0] average (input [31:0] val1,
input [31:0] val2);
reg [32:0] sum;
sum = val1 + val2;
average = sum / 2;
endfunction

14

Introduction to Verification

Encapsulation
Local variables can be created while minimizing their scope and
potential undesirable interaction.
function bit eth_frame::compare(eth_frame to);
compare = 0;
...
if (this.data_len !== to.data_len) return;
begin
int i;
for (i = 0; i < this.data_len; i++) begin
if (this.data[i] !== to.data[i])
return;
end
end
...
compare = 1;
endfunction: compare

15

Introduction to Verification

Encapsulation
The scope of variables used solely as for-loop iterators can be further
reduced by declaring them within the loop statement, often
eliminating the need for a begin/end block
function bit eth_frame::compare(eth_frame to);
compare = 0;
...
if (this.data_len !== to.data_len) return;
for (int i = 0; i < this.data_len; i++) begin
if (this.data[i] !== to.data[i])
return;
end
...
compare = 1;
endfunction: compare

16

Introduction to Verification

Encapsulation: Useful Subprograms

SystemVerilog has classes, modules, programs, interfaces and
packages to encapsulate any declaration used in more than one
partition.
Functions should be packaged in a class and used via a local instance
- It is preferable to use classes to encapsulate shared declarations.
- The encapsulating class will be added to the $root name spaceand thus
should be carefully named to avoid collisions.

- Classes unlike modules, must be explicitly instantiated using the new

constructor.

static variables can replace global variables

17

Introduction to Verification

Encapsulation: Bus-Functional Models

Stimulus applied to the design under verification via complex waveforms and
protocols can be implemented using tasks, called bus-functional models.

drives and
samples low-level
signals according
to a predefined
protocol

tasks are available

to initiate a
transaction with
the specified data
values

18

Introduction to Verification

Encapsulation

By default, SystemVerilog arguments are passed by value when the task is called
and when it returns. At no other time can a value flow into or out of a task via its
interface.

class arbiter;
...
// This task will not work...
task request(output logic
bus_rq,
input logic bus_gt);
// The new value does not
"flow" out
bus_rq <= 1b1;
// And changes do not "flow"
in
wait bus_gt == 1b1;
endtask: request
...
endclass: arbiter

class arbiter;
task request(ref output logic
bus_rq,
ref input logic bus_gt);
// The new value will "flow" out
bus_rq <= 1b1;
// And changes will "flow" in
wait bus_gt == 1b1;
endtask: request
endclass: arbiter

19

Introduction to Verification

Object-oriented Programming (OOP)

The next evolutionary step in language design after structured
programming
Used to identify a methodology that makes use of (and a language that
supports) classes, inheritance and polymorphism
SystemVerilog is object-oriented

20

Introduction to Verification

OOP: Class
A user-defined data type
A collection of variables and subprograms that create object types
Consists of:
o data members (class properties)
o tasks and functions to access the data (methods)

21

Introduction to Verification

OOP: Class
What are objects?
o Objects are instances of a class

Everything can be modeled as objects:

o
o
o
o
o
o

Physical data types, such as packets, frames and cells

Processor instructions
Floating point valueswhich are not directly supported by SystemVerilog
Bus-functional models
A scoreboard
Testbenches

22

Introduction to Verification

OOP: Class

Data Members
consume memory
each data member is local to
each object instance
can be global as well

Methods
do not consume memory
are global to the class

23

Introduction to Verification

OOP: Class
A simple class declaration:
class C;
int x;
task set (int i);
x = i;
endtask
function int get;
return x;
endfunction
endclass

data member

methods

24

Introduction to Verification

OOP: Class
An object must be created to use the class:
C c1;
c1 = new;

or

C c1 = new;

Having created a class object, we can use the class methods to assign and
look at the data value, x:
initial
begin
c1.set(3);
$display("c1.x is %d", c1.get());
end

25

Introduction to Verification

OOP: Class
Not objects:
o Modules & interfaces
are hierarchical constructs, not data structures
cannot be assigned nor passed to tasks or functions as arguments
cannot be compared or used in expressions

o Packages- cannot be instantiated

26

Introduction to Verification

OOP: Inheritance
What if there is a class that does almost everything you need, but it is
missing only that one little feature, what will you do?

Traditional approach:
Make a copy of the useful code, call it something else, and make
the necessary modifications.
But with inheritance:
Your needs can be built upon existing classes by only specifying
the desired difference in behavior.

27

Introduction to Verification

OOP: Inheritance
parent or base class original class
derived class
o the new class inheriting from the base
o inherits the properties and methods of its parent or base class
o may add new properties and methods, or modify the inherited properties
and methods

In SystemVerilog the syntax for deriving or inheriting one class from

another is this:
class Derived extends BaseClass;
// New and overridden property and method declarations
endclass

28

Introduction to Verification

OOP: Inheritance
Consider the example of the class Register:
class ShiftRegister extends Register;
task shiftleft; data = data << 1; endtask
task shiftright; data = data >> 1; endtask
endclass

29

Introduction to Verification

OOP: Polymorphism
polymorphism means to have many forms
classes on different branches can be treated as if they were the same
class, when viewed as a common base class
the ability to request that the same operations be performed by a
wide range of different types of things
o you can ask many different objects to perform the same action

allows the redefining of methods for derived classes while enforcing a

common interface
o the 'virtual' identifier must be used when defining the base class and
method(s) within that class

30

Introduction to Verification

OOP: Polymorphism
Example: without virtual
class A ;
task disp ();
$display(" This is class A ");
endtask
endclass
class EA extends A ;
task disp ();
$display(" This is Extended class A ");
endtask
endclass

program main ;
EA my_ea;
A my_a;
initial
begin
my_a = new();
my_a.disp();
my_ea = new();
my_a = my_ea;
my_a.disp();
end
endprogram
RESULTS
This is class A
This is class A

31

Introduction to Verification

OOP: Polymorphism
Example: with virtual
class A ;
virtual task disp ();
$display(" This is class A ");
endtask
endclass
class EA extends A ;
task disp ();
$display(" This is Extended class A ");
endtask
endclass

program main ;
EA my_ea;
A my_a;
initial
begin
my_a = new();
my_a.disp();
my_ea = new();
my_a = my_ea;
my_a.disp();
end
endprogram
RESULTS
This is class A
This is Extended class A

32

Introduction to Verification

Parallel Simulation Engine

Why hasnt C/C++ been used as a hardware description language
lacks three fundamental concepts for hardware designs modeling

Connectivity, Time, and Concurrency

lacks three necessary features to support the verification productivity cycle

C++

Randomization, Constrainability,
Functional coverage measurement

33

Introduction to Verification

Parallel Simulation Engine

Features necessary to support the verification productivity cycle
-

Randomization

Constrainability

increases the probability that youll take a different path in

each test case
creates several constraints to ensure the correctness of your
random stimulus, known as valid constraints

Functional coverage
measurement

define the boundaries within which the randomization feature works

You can add weights so that certain sets of stimuli occur more often than
others, that is you can change the distribution function, and
you can use the current state of the design to change these weights and
consequently the constraints for the next state

complements the traditional code coverage by making sure all the

functionalities of the chip or system are fully verified
Coverage objects to make sure that the chip or system perform
defined coverage goals

34

Introduction to Verification

Parallel Simulation Engine

Fundamental concepts necessary to model hardware designs:
-

Connectivity

Time

Concurrency
-

the ability to describe a design using simple blocks then

connecting them together.
implemented by directly instantiating modules and interfaces
within modules, and connecting the pins of the modules and
interfaces to wires or registers
the ability to represent how the internal state of a design
evolves over time and to control its progression and rate
implemented by using timing control statements such as @
and wait
the ability to describe actions that occur at the same time,
independently of each other
implemented through separate always and initial blocks

35

Introduction to Verification

Parallel Simulation Engine

The Problems with Concurrency:
Concurrent systems are difficult
to describe

they proved much more difficult to

program

difficulty may originate from the

mindset imposed by the early Von
Neumann architecture still used in
todays processors, or by an innate
limitation of our intellect

Concurrent systems are described

using a hybrid approach

human beings are adept at

performing relatively complex tasks
in parallel

36

Introduction to Verification

Parallel Simulation Engine

Emulating Parallelism on a Sequential Processor

Concurrent threads must be executed on single processor machines

Multi-tasking operating systems are like simulators.
Simulators are time-sharing machine
Simulator do not have time slice limits
Processes simulate until they execute a timing statement

37

Introduction to Verification

The Simulation Cycle

Two kinds of concurrent threads:

Module thread
intended to model the design

All other threads are

module threads.

Program thread
intended to model the testbench
composed of:
- initial blocks, concurrent signal
assignments and forked threads
defined inside program blocks
- class methods instantiated in a
program block and invoked by a
program thread
include pass/fail action block in
properties.

38

Introduction to Verification

The Simulation Cycle

Sample
clocking blocks

Assign zero-delay
nonblocking values
1

Execute module
threads

Advance Time
Evaluate
assertions

3
If there is nothing left to be done at the current time,
there must be either:
1. A thread waiting for a specific amount of time
2. A nonblocking value to be assigned after a non-zero
delay

Execute program
threads

39

Introduction to Verification

Summary

RTL mindset leads to tedious and complicated verification task.

Coding Style- Always strive for maintainability.
High-level code is structured according to functionality or need for
maintainability reasons.

Object-oriented Programming (OOP) - define data type of a data structure and

types of operations (functions) that can be applied to the data structure.

Parallel Simulation Engine randomization, constrainability, functional

coverage measurement, connectivity, time and concurrency.
Simulation Cycle
o Module threads -model the design.
o Program threads-model the test bench.