Module3

Ch:3 Procedural Statements and

Routines
Ch4: Connecting test bench and DUT
 System Verilog Procedural Statements
• New Operators
– Increment and decrement operator
• Used the same way as C
for (i=0; i<=31; i++)
begin
…
end

• Post-increment/decrement and pre-increment/decrement

j=i++ j is assigned value of i and then i is incremented by 1

j=++i i is incremented by 1 and j is assigned value of i
j=i--; j is assigned value of i and then I is decremented by 1
j=-i; i is decremented by 1 and then j is assigned value of i

• May cause a race condition since ++ and -- operators behave as blocking assignments

2
System Verilog Procedural Statements
for loop variables are declared outside the loop in Verilog
• Concurrent loops interfere with each other

• always @(posedge clock) begin

• For( i=1; i<=1024; i=i+1)
• …
• end
• endmodule

– Enhanced for loops in SV:

– SystemVerilog allows the for loop variables to be declared
inside the loop
• Each variable is local and unique to the loop, hence same name
usage does not cause any interference
3
For loop in SV- allows declaration of variable inside ,
multiple variable initialization and multiple modifiers
 System Verilog Procedural Statements
• do…while loop
– A while loop in Verilog might not execute at all
• If the test of control values is false the first time the loop is encountered in the
execution flow

– SystemVerilog adds a do..while loop (similar to C)

• A do while loop executes atleast once
• Control of the loop is tested at the end of each pass of the loop
– All logic for setting the outputs of the loop can be placed inside the loop
– Makes code more concise and intuitive

do <statement or statement block>

while (<condition>);
5
break and continue statements
 System Verilog Procedural Statements
• break and continue:
• The execution of a break statement leads to the
end of the loop.
• break shall be used in all the loop constructs
(while, do-while, foreach, for, repeat and forever).
• Execution of continue statement leads to skip the
execution of statements followed by continue and
jump to next loop or iteration value
 Example for break statement
• module break_in_loop;
•
• initial begin
• $display("-----------------------------------------------------------------");
•
• for(int i=0;i<8;i++) begin
• $display("\tValue of i=%0d",i);
• if(i == 4) begin
• $display("\tCalling break,");
• break;
• end
• end
•
• $display("-----------------------------------------------------------------");
• end
• endmodule
• when the loop value equals 4, the break is called this leads to the end of the loop.
 Example for continue statement
• module continue_in_loop;
•
• initial begin
• $display("-----------------------------------------------------------------");
•
• for(int i=0;i<8;i++) begin
•
• if((i > 2) && (i < 7))begin
• $display("\t\tCalling continue,");
• continue;
• end
•
• $display("\t\tAfter Continue\t:: Value of i=%0d",i);
• end
•
• $display("-----------------------------------------------------------------");
•
• end
•
• Endmodule

• when ever the loop value is with in 3 to 6, continue statement will be executed, this leads to skip the execution of display
statement after the continue.
 Task and Function in SV
• A function is meant to do some processing on
the input and return a single value, whereas a
task is more general and can calculate multiple
result values and return them using output
and inout type arguments.
 Task and Function in SV

• Synthesizable Not Synthesizable

 Tasks and functions

• Tasks and Functions provide a means of splitting code

into small parts.
• A Task can contain a declaration of parameters, input
arguments, output arguments, in-out arguments,
registers, events, and zero or more behavioral
statements.
• Static tasks
• Static tasks share the same storage space for all task
calls.
• Automatic tasks
• Automatic tasks allocate unique, stacked storage for
each task call.
• Task declration can be as in verilog 1995/2001 or can
be declared as in C or C++. In SystemVerilog following
rules hold good for any Task declaration
• Default Port Direction : Any port is seen as input,
unless declared as other types. Following are port
types
• input : copy value in at beginning
• output : copy value out at end
• inout : copy in at beginning and out at end
• ref : pass reference
• Default Data TYpe : Unless declared, data types of ports
are of logic type.
• begin..end : There is no need to have begin, end, when
more then one statement is used.
• return : A task can be terminated before endtask, by usage
of return statement.
• Variables : Systemverilog allows to have local static, or local
dynamic variables.
• life time : SystemVerilog allows a task to static or
automatic.
• wire : Wire data type can not be used in port list;
 task arguments in parentheses

• module sv_task;
• int x;
•
• //task to add two integer numbers.
• task sum(input int a,b,output int c);
• c = a+b;
• endtask
•
• initial begin
• sum(10,5,x);
• $display("\tValue of x = %0d",x);
• end
• endmodule
task arguments in declarations and mentioning directions
• module sv_task;
• int x;
•
• //task to add two integer numbers.
• task sum;
• input int a,b;
• output int c;
• c = a+b;
• endtask
•
• initial begin
• sum(10,5,x);
• $display("\tValue of x = %0d",x);
• end
• endmodule
 Functions
• A Function can contain declarations of range,
returned type, parameters, input arguments,
registers, and events.
• A function without a range or return type
declaration returns a one-bit value
• Any expression can be used as a function call
argument
• Functions cannot contain any time-controlled
statements, and they cannot enable tasks
• Functions can return only one value
• Function declration can be as in verilog 1995/2001 or
can be declared as in C or C++. In SystemVerilog
following rules hold good for any Function declaration
• Default Port Direction : Any port is seen as input, unless
declared as other types. Following are port types
• input : copy value in at beginning
• output : copy value out at end
• inout : copy in at beginning and out at end
• ref : pass reference
• Default Data TYpe : Unless declared, data types of ports are
of logic type.
• begin..end : There is no need to have begin, end, when more
then one statement is used.
• return : A function can be terminated before endfunction, by
usage of return statement.
• Variables : Systemverilog allows to have local static, or local
dynamic variables.
• life time : SystemVerilog allows a function to be static or
automatic.
• Wire : Wire data type can not be used in port list;
• void : SystemVerilog allows functions to be declared as type void
 function arguments in parentheses

• module sv_function;
• int x;
• //function to add two integer numbers.
• function int sum(input int a,b);
• sum = a+b;
• endfunction
•
• initial begin
• x=sum(10,5);
• $display("\tValue of x = %0d",x);
• end
• endmodule
 function arguments in declarations and mentioning directions

• module sv_function;
• int x;
•
• //function to add two integer numbers.
• function int sum;
• input int a,b;
• sum = a+b;
• endfunction
• initial begin
• x=sum(10,5);
• $display("\tValue of x = %0d",x);
• end
• endmodule
 function with return value with the return keyword

• module sv_function;
• int x;
•
• //function to add two integer numbers.
• function int sum;
• input int a,b;
• return a+b;
• endfunction
•
• initial begin
• x=sum(10,5);
• $display("\tValue of x = %0d",x);
• end
• endmodule
 Void function

• module sv_function;
• int x;
• //void function to display current simulation time
• function void current_time;
• $display("\tCurrent simulation time is %0d",$time);
• endfunction
•
• initial begin
• #10;
• current_time();
• #20;
• current_time();
• end
 discarding function return value

• The function return value must be assigned to

a variable or used in an expression.
• Calling a function without return value
assigned to a variable can result in a warning
message. SystemVerilog void data type is used
to discard a function’s return value without
any warning message.
• module sv_function;
• int x;
• //function to add two integer numbers.
• function int sum;
• input int a,b;
• return a+b;
• endfunction
•
• initial begin
• $display("Calling function with void");
• void'(sum(10,5));
• end
• endmodule
 function call as an expression

• module sv_function;
• int x;
• //function to add two integer numbers.
• function int sum;
• input int a,b;
• return a+b;
• endfunction
• initial begin
• x = 10 + sum(10,5);
• $display("\tValue of x = %0d",x);
• end
• endmodule
SystemVerilog Tasks and Functions
• Tasks and Functions
– SystemVerilog functions and tasks do not require begin and end
statements
– SystemVerilog adds a return statement
– Void functions do not return a value
– Functions can have output and inout as formal arguments

task reset();
reset_l = 1’b0;
function int add2(int n);
#100
return n + 2;
reset_l = 1’b1;
endfunction
endtask

27
SystemVerilog Tasks and Functions
• Return Statement
– SystemVerilog adds a return statement
• If a return statement is executed that value is returned
else the last value assigned to the function name is the
return value
• A return statement can be used to exit a task or a
function
function int add_and_inc (input [31:0] a,b);
add_and_inc=a+b+1; Return has priority over
endfunction returning the value in the
function int add_and_inc (input [31:0] a,b); name of the function
add_and_inc=a+b;
return ++add_and_inc;
endfunction

28
SystemVerilog Tasks and Functions
• Void functions
– Void functions do not return a value
– Output and inout formal arguments allow a void
function to propagate changes to the scope
– A void function can be called like a task but must
adhere to the restriction of function contents

29
• typedef struct{
• logic valid;
• logic [7:0] check;
• logic [63:0] data;
• } packet_t;

• function void fill_packet (

• input logic[63:0] data_in, output packet_t data_out);
• data_out.data=data_in;
• endfunction
SystemVerilog Tasks and Functions
• Passing task/function arguments by name
– SystemVerilog can pass argument values to tasks
or functions using the names of formal arguments
• Reduces errors
– The arguments can be passed in any order
– Syntax for named argument passing is the same as
Verilog’s syntax for named port connections

31
• function int divide (input int numerator, denominator);
• if(denominator==0)
• begin
• return 0; always @(posedge clock)
• end result<=divide(b,a)
• else
• return numerator/denominator;
• endfunction

always @(posedge clock)

result<=divide(.deominator(
b),.numerator(a))
Connecting the Testbench and the Design
How do I connect my design to the testbench?

Testbench

Design Under
Driver
Test

.*Port, .Name,
?
Interfaces

33
 Connecting the Testbench and the Design
• One way to connect the testbench and the design is to use the
conventional verilog module ports convention

Verilog Connection Review

A_out_signal1 B_in_signal1

A_out_signal2 B_in_signal2
Module A Module B
A_in_signal1 B_out_signal1
A_in_signal2 B_out_signal2

module B (
module A (
input B_in_signal1,
input A_in_signal1,
input B_in_signal2
input A_in_signal2
output B_out_signal1,
output A_out_signal1,
output B_out_signal2,
output A_out_signal2,
);
);
…
…
endmodule
endmodule

34
 Connecting the Testbench and the Design
• Verilog connection review
– Verilog language connects modules together through module ports
A_out_signal1 conn1 B_in_signal1

A_out_signal2 conn2 B_in_signal2

Module A Module B
A_in_signal1 conn3 B_out_signal1
A_in_signal2 conn4 B_out_signal2

module top (
wire conn1,
wire conn2
wire conn3,
wire conn4,
);
A A_instance1(.A_out_signal1(conn1),
.A_out_signal2(conn2),
.A_in_signal1(conn3),
.A_in_signal2(conn4));
B B_instance1(.B_in_signal1(conn1),
.B_in_signal2(conn2),
.B_out_signal1(conn3),
.B_out_signal2(conn4));
endmodule
35
 Connecting the Testbench and the Design
Lets do another example:
Testbench

request [1:0] grant [1:0]

Arbiter
reset clk

module arb_port ( module test (

output logic [1:0] grant, input logic [1:0] grant,
input logic [1:0] request, output logic [1:0] request,
input logic reset, output logic reset,
input logic clk input logic clk
); );
… …
endmodule endmodule

36
 System Verilog: .*Port Connections
• Implicit .* port connections
 .* infers connections of all nets and ports of the same name
 For a connection to be inferred the name and the vector sizes
should be the same
 Types connected together should be compatible

module top
logic [1:0] grant,request;
logic clk, reset;
arb_port a1(.grant(grant), .request(request), .reset(reset), .clk(clk));
test t1(.grant(grant), .request(request), .reset(reset), .clk(clk));
…
endmodule

module top
logic [1:0]
grant,request;
logic clk, reset;
arb_port a1(.*);
test t1(.*);
…
endmodule .*Port Connections
37
 System Verilog: .Name Connections
• Implicit .name connections
 .name is an abbreviation of named port connections
 .name infers a connection of a net and port of the same
name and same vector sizes
 .name simplifies connections to module instances
 .name can be combined with named port connections

module top
logic [1:0] grant,request;
logic clk, reset;
arb_port a1(.grant, .request, .reset, .clk);
test t1(.grant, .request, .reset, .clk);
…
endmodule

38
 Downside of Verilog Connection Conventions
Why?
Verilog module port conventions are cumbersome
Lets change the name of a port request to request 1
module arb_port ( module test (
output logic [1:0] grant, input logic [1:0] grant,
input logic [1:0] request1, output logic [1:0] request1,
input logic reset, output logic reset,
input logic clk input logic clk
); );
… …
endmodule endmodule

• Need to change the port list of each module

• Need to change the port list of the connecting module
• Need to change the name in the instantiation of the modules
• Need to change the name everywhere in the hierarchy

What if you forget to change it in someplace?? --> Compilation error!!!!

39
Downside of Verilog Connection Conventions
Verilog connections become especially tedious
and cumbersome for large designs

Internal 10 Instruction Fetch 15 Master

Memory Processor

10 main bus
10

10 10
Test Generator Slave Processor
Number of ports

40
Disadvantages of Verilog Connection Conventions
• Disadvantage of Verilog Module Connections
 Declarations must be duplicated in multiple
modules
 Communication protocols must be duplicated in
several modules
 Risk of mismatched declarations
 A change in design specifications can require
modifications in multiple modules
Solution!!!!

SystemVerilog introduces a powerful new

port type called: Interface

41
 SystemVerilog Interfaces
• SystemVerilog Interfaces
 SystemVerilog adds a powerful new port type to Verilog, called an
interface.
 An interface allows a number of signals to be grouped together
and represented as a single port
 The declarations of the signals that make up the interface are
contained in a single location.
 Each module that uses these signals then has a single port of the
interface type, instead of many ports with the discrete signals.

Testbench Interface Arbiter

All the signals that are common between the major blocks
of the design are encapsulated in one location- the
interface declaration

42
 SystemVerilog Interfaces
Using an interface to simplify connections

Testbench Interface Arbiter

request [1:0]
interface arb_if (input bit clk);
logic [1:0] grant, request;
grant [1:0]
reset logic reset;
endinterface
Interface Declaration
clk
module top;
Interface bit clk;
always #5 clk=~clk;
arb_if arbif(clk);
arb a1(arbif);
test t1(arbif);
endmodule: top
Top module using a simple arbiter interface
43
 SystemVerilog Interfaces
• Using an interface to simplify connections
interface arb_if (input bit clk);
logic [1:0] grant, request;
logic reset;
endinterface
Interface Declaration

module test (arb_if arbif);

…
initial begin
@(posedge arbif.clk);
arbif.request<=2’b01;
$display (“@%0d: Drove req=01”, $time);
repeat(2) @(posedge arbif.clk);
if(arbif.grant!=2’b01)
$display (“@%0d: a1: grant !=2’b01”, $time);
$finish
end
endmodule: test
test module using a simple arbiter interface

44
 SystemVerilog Interfaces
• Connecting interfaces and ports
 Signals in an interface are referenced using the port name
<port_name>.<internal_interface_signal_name>

interface arb_if (input bit clk);

logic [1:0] grant, request;
logic reset;
endinterface
Interface Declaration

module top;
bit clk;
always #5 clk=~clk;
arb_if arbif(clk);
arb a1(.grant(arbif.grant),
.request(arbif.request),
.reset(arbif.reset),
.clk(arbif.clk));
test t1(arbif);
endmodule: top
Connecting the arbiter module using ports to the test module using an interface
45
 SystemVerilog Interfaces: modports
• Interface modports
 SystemVerilog interfaces provide a means to define different views of the
interface signal
 modport is an abbreviation for module port
 An interface can have any number of modport definitions
 The modport declaration only defines whether the connecting module
sees a signal as an input, output or bidirectional
 By specifying the port directions, modport provides access restrictions

interface arb_if (input bit clk); module arb (abf_if.DUT arbif);

logic [1:0] grant, request; …
logic reset; endmodule
modport TEST(output request,reset, 2. arbiter module with interface using modport
input grant, clk);
modport DUT(input request,reset, clk
output grant); module test (abf_if.TEST arbif);
endinterface …
1. Interface Declaration using modports endmodule
3. test module with interface using modports

46
 SystemVerilog Interfaces
• SystemVerilog interfaces overview
 SystemVerilog interfaces can contain functionality
► They are not just bundle of wires
► Discrete signal and ports for communications can be defined
in one location
► Communication protocols can be defined in the interface
► Protocol checking and other verification routines can be built
into the interface
 SystemVerilog also allows multiple views of the interface to be
defined
► For instance the data_bus signal can be defined to be an
input, output or bidirectional port
 SystemVerilog interfaces cannot contain design hierarchy
► cannot contain instances of modules
 SystemVerilog interfaces can be used as a module port
 SystemVerilog interfaces can contain modports
► modports allow modules to see interface differently

47
 System verilog modports-example code
• //Defining modport in interface
• interface intf();
•
• //declaring the signals
• logic [3:0] a;
• logic [3:0] b;
• logic [6:0] c;
•
• modport driver (output a, b, input c);
•
• endinterface
•
• //driving using modort
• //run task
• task run;
• vif.driver.a = 6;
• vif.driver.b = 4;
•
• $display("Value of a = %0d, b = %0d",vif.driver.a,vif.driver.b);
• #5;
• $display("Sum of a and b, c = %0d",vif.driver.c);
• $finish;
• Endtask

• Simulator output:
• Value of a = 6, b = 4 Sum of a and b, c = 10
 Example2

• //Defining modport in interface with the direction input

• interface intf();
•
• //declaring the signals
• logic [3:0] a;
• logic [3:0] b;
• logic [6:0] c;
•
• modport driver (input a, b, c);
•
• endinterface
•
• //driving using modport
• //run task
• task run;
• vif.driver.a = 6;
• vif.driver.b = 4;
•
• $display("Value of a = %0d, b = %0d",vif.driver.a,vif.driver.b);
• #5;
• $display("Sum of a and b, c = %0d",vif.driver.c);
• $finish;
• Endtask
• Simulation output:
• Error-[MPCBD] Modport port cannot be driven environment.sv, 18 $unit, "vif.driver.a" Port 'a' of modport 'driver' has been
restricted as an input port. Input ports cannot be driven.
 Stimulus Timing
• The timing between the testbench and the design should be
maintained
 Ensure driving and receiving synchronous signals at the proper time in
relation to the clock
 Driving a signal too late or sampling it too early can cause the
testbench to be off a cycle
 To ensure proper sampling and signaling the testbench should be
separate from the design
 The inputs should be driven just before the clock edge and outputs
should be sampled just after the clock edge

50
When test bench drives start signal first and then other signals, race occurs.
 Stimulus Timing
The timing between the testbench and the design
should be maintained to avoid race conditions

Tsetup

start start

write write

addr 42 addr 42

5a data 5a
data

10 10

Driving the signal too late Solution: Drive the signal

and sampling it too early Tsetup early to avoid race
causes the race condition condition
to occur

52
 Stimulus Timing: Clocking Blocks
• Controlling timing of synchronous signals by using Clocking
Blocks
 An interface may contain a clocking block to specify the timing of
synchronous signals relative to the clock
► Any signal in the clocking block is driven or sampled
synchronously, ensuring that the testbench interacts with the
signals at the right time
► Clocking block ensures that the testbench interacts with the signals
at the right time
► Clocking blocks are mainly used by testbenches
► An interface can contain multiple clocking blocks.
► Synthesis tools do not support clocking blocks.

53
System Verilog Testbench in Simulation
– When you are using interfaces with a clocking block:
• There is a 1-cycle delay from DUT output to testbench input
– “Virtual synchronizer” added to TB input
• No delay from testbench output to DUT input
default input #1step output #0;

clock

Design

Testbench

Drive inputs Sample

before outputs
clock at clock

54
 Stimulus Timing: Clocking Blocks
• Clocking Block reset
 Can be declared as @(posedge clk) request[1:0]
 An interface can use a clocking block to control timing grant[1:0]
► Directions are relative to program block clock
arb.sv
interface arb_if (input bit clk);
logic [1:0] grant, request;
logic reset; Declare the clocking block and
clocking cb @(posedge clk); indicate that the signals will be
output request active on positive edge of the
input grant clock
endclocking
modport TEST(clocking cb,output reset); Using the clocking block,
modport DUT(input request, reset, output grant); (request is output and grant is
input)
endinterface
Example of clocking block
arb_if arbif;
• Referencing signals in the Clocking Block arbif.cb.request<=2’b01;
if(arbif.cb.grant!=2’b01)
@arbif.cb
<my_interface.cb.signal_name>
Example of refrencing signals in the clocking blo

55
 Clocking Block: Signal Synchronization
• Synchronize to active clock edge specified in clocking block
@arbif.cb; // continue on clock edge from arb_if
repeat (3) @arbif.cb; // Wait for 3 posedges

• Synchronize to any edge of signal

@arbif.cb.grant; // continue on any edge of grant

@(posedge arbif.cb.grant); // continue on posedge
@(negedge arbif.cb.grant); // continue on negedge
wait (arbif.cb.grant==1); // wait for expression
// no delay if already true

• Wait for N clock cycles with ##n

##2 arbif.cb.request <= 0; // Wait 2 cycles

// then assign

56
Clocking Block: Synchronous Signal Access
• Clocking Block signals are referenced by pre-pending the clocking
block name to the signal:
All drives must use non-blocking assignment

arbif.cb.request <= 1; // drive

value = arbif.cb.grant; // sample

• Assignment will happen at next active clock edge

– Time will NOT advance unless you use #1 or ##1

interface arb_if (input bit clk);

logic grant, request, reset;
clocking cb @(posedge clk);
input grant;
output request;
endclocking
modport TB (clocking cb, output reset);
endinterface: arb_if
57
 Stimulus Timing: Clocking Blocks
• Clocking Blocks overview
 Use in the interface, just for testbench
 Benefits:
► Creates explicit synchronous timing domains
► Provides race-free operation if input skew > 0
► Your testbench will always drive the signals at the right time!
 Functionality:
► An interface can contain multiple clocking blocks
► There is one clock per clocking block.
► Default is “default input #1step output #0;”
– The 1 step delay specifies that signals be sampled in the
postpone region before any design activity
– Directions are with-respect-to the testbench

58
 Stimulus Timing: Timing Regions
• Timing Regions
 Race conditions are caused by mixing design and testbench events
during the same time slot
 SystemVerilog introduces division of time slots
► Active Region: Simulation of design code in modules
► Observed Region: Assertions evaluated after design executes
► Reactive Region: Execution of testbench
► Postpone Region: Sampling signals after all design activity

clock

data

REGION Active Observed Reactive Postpone

ACTIVITY design assertions testbench sample

Previous Current Next

59
 Timing Regions
• Interface Synchronization
– Use @ and wait signals to synchronize with the signals
• Interface Sample(delay in observing the output)
– Sample from the postpone region

‘timescale 1ns/1ns module arb(arb_if.DUT arbif)

program test (arb_if.TEST arbif); initial begin
initial begin arbif.grant=1;
$monitor(arbif.cb.grant); #12 arbif.grant=2;
#50 #18 arbif.grant=3;
end end
endprogram endmodule

Input is sampled just before the

clock edge
clk

DUT arb.grant 1 2 2 3

TEST arbif.cb.grant 1 2 2 3

10 20 30 40
60
 Timing Regions
• Interface Drive(no delay in driving)

mdule arb (arb_if.DUT arbif); ‘timescale 1ns/1ns

initial begin program test(arb_if.TEST arbif)
$monitor(arbif.request); initial begin
end arbif.cb.request<=3;
endprogram #12 arbif.cb.request<=2;
#18 arbif.cb.request<=1;
end
endmodule

Input is sampled just before the

clk clock edge

TEST arbif.cb.request 3 2 2 1

DUT arbif.request
3 2 1

10 20 30 40

61
 Program Block
• Program Block
• In order to avoid mixing of design and test bench events
during the same time, program block is used in SV.
 In Systemverilog the test bench code is in a program block
► Program block is similar to a module and can contain code and
variables and be instantiated in other modules
► A program cannot have hierarchy such as instances of modules or
interfaces
program test (arb_if.TEST arbif);
initial begin
@arbif.cb; Continue on active clock edge
repeat (3) arbif.cb; Wait for 3 active edges
@arbif.cb.grant; Continue on any edge
@(posedge arbif.cb.grant); Continue on positive edge
@(negedge arbif.cb.grant); Continue on negative edge
wait (arbif.cb.grant==1); Wait for expression to be true
@(posedge arbif.cb.grant or negedge arbif.reset); Wait for several signals
end
endprogram

62
 Program Block
• Create testbench program: test.sv
clk
reset
program test(arb_if.TB arbif); request
initial begin
// Asynch drive reset
arbif.reset <= 0; interface arb_if (input bit clk);
#15ns arbif.reset <= 1; logic grant, request, reset;
#35ns arbif.reset <= 0; clocking cb @(posedge clk);
ns! input grant;
// Synch drive request output request;
##1 arbif.cb.request <= 1; endclocking
##1 arbif.cb.request <= 0; modport TB (clocking cb,
wait (arbif.cb.grant == 1); output reset);
end endinterface: arb_if
endprogram

Wait 1 clock cycle

Common mistake: forgot “cb.” in signal reference Error: arbif.request not

visible via modport
63
 Program Block Overview
• Benefits:
 Separates the testbench from the DUT
 Reduces race conditions by running in separate region
 Provides an entry point for execution

• Functionality:
 Can be instantiated in any hierarchical location
► Typically at the top level
 Interfaces and ports can be connected in the same manner as
any other module
 Code goes in initial blocks & routines, no always blocks
 Executes in the Reactive region
 Implicit $finish when all initial blocks end in program

64
 Testbench Environment – Top Block
• Create top module Implicit port connections:
The syntax .* connect ports
and signals with same
names

module top; interface arb_if (input bit clk);

bit clk; …
arb_if arbif(.*); endinterface: arb_if
test t1 (.*);
arb d1 (.*); // Synchronous TB
program test(arb_if.TB arbif);
always #5 …
clk = !clk; endprogram
endmodule

module arb(arb_if.DUT arbif,

bit clk);
// Some logic here…
Generate clock in top module (Active
region)
endmodule
vs. program (Reactive) to prevent races.
Your design is tied tightly to the clock,
so they need to be in the same region.
65
 Top Level Scope
• SV introduces a compilation unit scope
referred as $unit.
• $unit contains a group of source files that are
compiled together.
• This scope is present outside the boundaries
of any primitive, module, macro module,
interface, program,package etc.
• Verilog-2001 adds a new wild card token, @*,
which represents a combinational logic
sensitivity list. The @* token adds to the
sensitivity list all nets and variables that are
read by the statements in the always block.