0% found this document useful (0 votes)
31 views47 pages

SVV_Unit III_final

Uploaded by

Vandana Ch
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
31 views47 pages

SVV_Unit III_final

Uploaded by

Vandana Ch
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 47

Unit III

Procedural
Statements
Local Storage
When Verilog was created in the 1980 it's primary goal was
describing hardware
Because of this, all object in the language were statically allocated
 In a particular Routine Argument and local variable stored in fixed
location rather than pushing them on a stack like other programming
languages
 Software engineers where developed to the behavior of stack
based languages such as C where beaten by this bugs and were
Limited in their ability to create complex testbench where libraries of
Routine
Cont..
In SystemVerilog, local storage typically refers to variables that are local to a
specific module, task, function, or block.
These local variables are used for temporary storage and have a limited scope,
which helps in managing data and controlling the complexity of designs.
Module Variable
Task and Function Variables
Block and Scope variable
Static variable
Local Variables in Modules

module my_module; always @(posedge clk) begin


// Local variable // Use local variable
logic [7:0] local_var; local_var = local_var + 1;
end
initial begin endmodule
// Initialize local variable
local_var = 8'hFF;
end
Local Variables in Tasks and
Functions

module my_module;
// Local variable in module
logic [7:0] local_var;
initial begin
my_task();
end
task my_task; endmodule
// Local variable in task
logic [3:0] task_var;
begin
task_var = 4'hA;
// Do something with task_var
end
endtask
Local Variables in Functions
module my_module;
// Local variable in module initial begin
local_var = my_function();
logic [7:0] local_var;
end
endmodule
function logic [3:0] my_function;
// Local variable in function
logic [3:0] func_var;
begin
func_var = 4'hB;
my_function = func_var;
end
endfunction
Block Scope Variables
Block Scope Variables: Declared within procedural blocks or loops, accessible only
within that block or loop.
module my_module; initial begin
initial begin for (int i = 0; i < 10; i++) begin
// Local variable in initial block // Local variable in for loop
logic [7:0] loop_var;
logic [7:0] local_var; loop_var = i;
local_var = 8'hC3; end
end end
always @(posedge clk) begin endmodule
// Local variable in always block
logic [7:0] counter;
counter = counter + 1;
end
Static Variable
module my_module;
initial begin
task my_task; my_task();
// Static local variable in task my_task();
my_task();
static logic [3:0] static_var; end
endmodule
begin
static_var = static_var + 1;
$display("Static variable value: %0d", static_var);
end
endtask
Automatic Storage
Example
Initialization of Variables
Time Values
Time Units & Precision
The time unit and time precision declarations eliminate
this ambiguity by precisely specifying the values for every
module.
Time literals
System Verilog allows you to unambiguously specify a time
value plus units.
Your code can use delays such as 0.1ns or 20ps . Just
remember to use timeunit and timeprecision or ` timescale .
You can make your code even more time aware by using the
classic Verilog $timeformat(), $time , and $realtime system
tasks.
The four arguments to $timeformat are the scaling factor
(−9 for nanoseconds, −12 for picoseconds), the number of
digits to the right of the decimal point, a string to print after
the time value, and the minimum fi eld width.
example
Time and Variables
You can store time values in variables and use them in
calculations and delays.
The values are scaled and rounded according to the current
time scale and precision.
Variables of type time cannot hold fractional delays as they
are just 64-bit integers, so delays will be rounded. You
should use realtime variables if this is a problem.
Example
Connecting Test bench and
design
Steps need to verify a design
Generate stimulus
Capture Response
Determine Correctness and
Measure Progress
Introduction
The test bench wraps around the design sending in stimulus and capturing the design response.
The test bench forms the real world around the design mimicking the entire environment
Ex: a processor model needs to connect to various buses and devices which are modelled in the test bench
as bus functional model
In networking device connect to multiple input and output data streams that are modeled based on standard
protocols
A videos chip connect to buses that sends in commands, and then forms images that are written into
memory model
The test bench needs a higher level base to communicate with the design the very long ports and the error
prone pages of the connection
We need a robot way to describe the timing so that synchronous signals are always driven and sample that
the correct time and all interactions are free of the race around condition so common to very low models
2 Connecting Test bench and
design
2.1 Separating the test bench
and design
In an ideal world, all projects have two separate groups: one to create the design and one to verify it.
Each team has its own set of specialized skills, such as creating synthesizable RTL code, or figuring out
new ways to find bugs in the design.
These two groups each read the original design specification and make their own interpretations.
The designer has to create code that meets that specification, verification engineer is to create
scenarios where the design does not match its description.
Likewise, your testbench code is in a separate block from design code.
 However, using a module to hold the testbench often causes timing problems around driving and
sampling,
System Verilog introduces the program block to separate the testbench, both logically and temporally.
.
Cont..
As designs grow in complexity, the connections between the blocks increase. Two RTL blocks
may share dozens of signals, which must be listed in the correct order for them to communicate
properly
One mismatched or misplaced connection and the design will not work. If it is a subtle error,
such as swapping pins that only toggle occasionally, we may not notice the problem for some
time. Worse yet is when you add a new signal between two blocks.
Again, one wrong connection at any level and the design stops working. Or worse, the system
only fails intermittently!
 The solution is the interface, the SystemVerilog construct that represents a bundle of wires,
with intelligence such as synchronization, and functional code.
 An interface can be instantiated like a module but also connected to ports like a signal.
2.1.1 Communication Between
the Testbench and DUT
The next few sections show a testbench connected to an arbiter, using individual signals and again
using interfaces.
Here is a diagram of the top level design including a testbench, arbiter, clock generator, and the signals
that connect them .
2.1.2 Communication with Ports
Testbench using ports
Top-level netlist without an
interface
2.2 Interface Construct
Designs have become so complex that even the communication between blocks may need to be
separated out into separate entities.
To model this, SystemVerilog uses the interface construct that you can think of as an intelligent
bundle of wires.
They contain the connectivity, synchronization, and optionally, the functionality of the
communication between two or more blocks. They connect design blocks and/or testbenches.
2.2.1 Interface to Simplify
Connection
2.2.2 Connecting Interfaces and
Ports
Verilog-2001 legacy design with ports that cannot be changed to use an interface, we can just
connect the interface’s signals to the individual ports.
2.2.3 Grouping Signals in an
Interface Using Modports
 The previous example uses a point-to-
point connection scheme with no signal
directions in the interface.
 The original netlists using ports had this
information that the compiler uses to
check for wiring mistakes.
 The modport construct in an interface
lets you group signals and specify
directions. The MONITOR modport
allows you to connect a monitor
module.
Cont..
2.3 Stimulus Timing
The timing between the testbench and the design must be carefully orchestrated.
At a cycle level, we need to drive and receive the synchronous signals at the proper time in
relation to the clock. Drive too late or sample too early, and your testbench is off a cycle.
Even within a single time slot (for example, everything that happens at time 100 ns), mixing
design and testbench events can cause a race condition, such as when a signal is both read and
written at the same time.
Do we read the old value, or the one just written?
In Verilog, nonblocking assignments help when a test module drives the DUT, but the test could
not always be sure it sampled the last value driven by the design.
SystemVerilog has several constructs to help you control the timing of the communication.
2.3.1 Controlling Timing of
Synchronous Signals with a
Clocking Block
2.3.2Controlling Timing of
Synchronous Signals with a
Clocking Block
2.3.4 The Program Block and
Timing Regions
2.3.5 Main regions inside a
SystemVerilog time step
The Program Block and Timing
Regions
Interface Driving and Sampling
Interface Synchronization
we can use the Verilog @ and wait constructs to synchronize with the signals in a testbench. The following
code does not do anything useful except to show the various constructs.
Top-Level Scope
 SystemVerilog introduces the compilation unit, which is a group of source files that are compiled together.
 The scope outside the boundaries of any module, macromodule, interface, program, package, or primitive
is known as the compilation unit scope, also referred to as $unit.
 Anything such as a parameter defined in this scope is similar to a global because it can be seen by all
lower-level blocks.
 However, it is not truly global as the parameter cannot be seen during compilation of other files.
Program – Module Interactions
The program block can read and write all signals in modules, and can call routines in modules,
but a module has no visibility into a program.
This is because your testbench needs to see and control the design, but the design should not
depend on anything in the testbench
A program can call a routine in a module to perform various actions.
The routine can set values on internal signals, also known as “backdoor load.” Next, because the
current SystemVerilog standard does not define how to force signals from a program block, we
need to write a task in the design to do the force, and then call it from the program.
Thank you

You might also like