SVTB

1
SystemVerilog Testbench Constructs
The new version of VCS has implemented some of the SystemVerilog

testbench constructs. As testbench constructs they must be in a
program block (see Program Blocks on page 1-18).
Enabling Use of SystemVerilog Testbench Constructs

You enable the use of SystemVerilog testbench constructs with the
-sverilog compile-time option.

1-1
VCS MX Flow for SVTB

The VCS MX use model now includes the use model for
SystemVerilog NTB. This is a Limited Customer availability (LCA)
feature in NTB (SV) and requires a separate license. Please contact
your Synopsys AC for a license key. The most important part is
analyzing the SystemVerilog source code You can do this as follows:
vlogan -sverilog <ntb options> <SV source code files>
As the use of vlogan indicates, SystemVerilog files are treated like

Verilog files in the VCS MX flow. You can also specify other NTB
options:
For example:
vlogan -sverilog
tb.sv
or
vlogan -sverilog
-f tb.list
Combined UUM Flow

Analyze Verilog, VHDL and SystemVerilog source code files in a
bottom-up approach. Use vhdlan for VHDL files, vlogan for Verilog
files and vlogan -sverilog for SystemVerilog files. Use the following
steps:
Analyze all Verilog source files.
Analyze all VHDL source files in bottom-up order.
Compile the design and testbench files using -ntb option to create
a simv.
Run the simv.

1-2
For example:
vlogan -sverilog cpu.v tb.sv tb_util.sv
vhdlan mypackage.vhd
vhdlan tb_wrapper.vhd
Use vcs during compile to create the simulation executable:

vcs module[|entity|config]_name <other VCS opts>
Finally, run the simulation:

simv
A VHDL-Top
First, analyze VHDL, Verilog and SystemVerilog source code files in
a bottom-up approach. Use vhdlan for VHDL files, vlogan for Verilog
files and vlogan -sverilog for SystemVerilog files.
For example:
vlogan -sverilog tb.sv tb_util.sv
vhdlan mypackage.vhd
vhdlan tb_wrapper.vhd
vhdlan cpu.vhd top.vhd
Example:
scs -mhdl design_cfg
or
scs -mhdl TOP

1-3

scsim
Verilog-Top
The first steps are identical to a Verilog-top flow. Analyze all source
files in bottom-up order.
Example:
vlogan
vhdlan
vhdlan
vhdlan
-sverilog tb.sv tb_util.sv

mypackage.vhd
tb_wrapper.vhd
cpu.vhd
Use vcs during the elaboration step to create the simulation

executable:
vcs -mhdl top.v <other VCS opts>

simv
Options For Compiling and Simulating SystemVerilog

Testbench Constructs
Compile-Time Options
The following compile-time options, used for both Verilog and
SystemVerilog code have been tested with SystemVerilog testbench
code:

1-4
-f filename
+define+macro_name=value
+incdir+directory_name
+libext+ext
-y directory_name
-timescale=time_unit/time_precision
Runtime Options
There are runtime options that were developed for OpenVera
testbenches that also work with SystemVerilog testbenches.
+ntb_random_seed=integer
Sets the seed value used by the top level random number
generator at the start of simulation. This option does not work for
the Verilog $random(seed) system function.
+ntb_solver_mode=1|2
Specifies the constraint solver mode for the randomize()
method:
1
The solver spends more pre-processing time in analyzing the
constraints, during the first call to randomize() on each class.
Subsequent calls to randomize() on that class are very fast.
2
The solver does minimal pre-processing, and analyzes the
constraint in each call to randomize(). Default is 2.
The randomize() method is described in Randomize Methods
on page 1-84.

1-5
+ntb_enable_solver_trace=0|1|2
Specifies the debugging mode when VCS executes the
randomize() method:
0
Disables tracing.
1
Enables tracing. This is the default.
2
Enables tracing with more verbose messages.
The randomize() method is described in Randomize Methods
on page 1-84.
+ntb_enable_solver_trace_on_failure[=0|1|2]
Enables a mode that displays trace information only when the
constraint solver fails to compute a solution, usually due to
inconsistent constraints.
0
Disables tracing.
1
Enables tracing. This is the default. This argument is the default
argument when you enter this option without an argument.
2
Enables tracing with more verbose messages and the analysis
narrows down to the smallest set of inconsistent constraints,
thus aiding the debugging process. This option with the 2
argument is the default condition when you dont enter this
option.

1-6
Compile Time or Runtime Options

-cm_dir directory_path_name
As a compile-time or runtime option, specifies an alternative name

and location for the default simv.vdb directory, VCS automatically
adds the extension .vdb to the directory name if not specified.
-cm_name filename
As a compile-time or runtime option, specifies an alternative test

name instead of the default name. The default test name is "test".
The string Data Type

The string data type is an LCA feature.
VCS has implemented the string SystemVerilog data type. The
following is the syntax for declaring this data type:
string variable_name [=initial_value];
String Manipulation Methods

SystemVerilog has the following methods for manipulating strings:
len()
Returns the number of characters in a string.
string string_name = "xyz";
int int1 = string_name.len;

1-7
getc()
Returns the numerically specified character in the string.
bit1=string_name.getc(0);
If variable string_name has a value of xyz, then this method returns

the ASCII code for the number 0 character to bit1, the x character.
putc()
Replaces a specified character with another value or character. This
method takes two arguments, the first is the number of the characters
in the string, the second is a value or another string variable. If the
second argument is a string value, the specified character is replaced
with the first character of the string argument.
string string1 = "abc";
string string2 = "xyz";
initial
begin
$display ("string1 is \"%s\"",string1);
string1.putc(0,42);
string1.putc(1,string2);
end
endmodule
The $display system tasks display the following:

string1 is "abc"
string1 is "*bc"
string1 is "*xc"

1-8
toupper()
Returns a string with the lower case characters converted to upper
case.
string string1 = "abc";
string string2 = string1.toupper;
initial
begin
$display("string1 is \"%s\"",string1);
$display("string2 is \"%s\"",string2);
end

string1 is "abc"
string2 is "ABC"
tolower()
Similar to the toupper method, this method returns a string with the
upper case characters converted to lower case.
compare() and icompare()
Compares strings and returns 0 if they match, and a value less than
0 or more than zero, depending on the order of the strings, if they
dont match. The icompare method doesnt see a difference between
upper case and lower case.
string
string
string
string
string1
string2
string3
string4
=
=
=
=
"abc";
"abc";
"xyz";
"ABC";
initial
begin
if (string1.compare(string2) == 0)

1-9
$display("string1 matches string2");

if (string1.compare(string3) != 0)
$display("string1 does not match string3");
if (string1.compare(string4) != 0)
if (string1.icompare(string4) == 0)
$display("string1 matches string4 except for case");
else
$display("string1 does not match string4");
end

string1 matches string2
string1 does not match string3
string1 matches string4 except for case
substr()
Returns a substring of the specified string. The arguments specify
the numbers of the characters in the specified string that begin and
end the substring.
string string1 = "abcdefgh";
string string2;
initial
begin
string2 = string1.substr(1,5);
$display("string2 = %s",string2);
end
The $display system task displays the following:

string2 = bcdef
String Conversion Methods

SystemVerilog has the following methods for converting strings:
1-10
atoi( ) atohex( ) atooct( ) and atobin( )

Returns the integer corresponding to either the ASCII decimal,
hexadecimal, octal, or binary representation of the string.
string string1 = "10";
reg [63:0] r1;
initial
begin
$monitor("r1 = %0d at %0t",r1,$time);
#10 r1 = string1.atoi;
#10 r1 = string1.atohex;
#10 r1 = string1.atooct;
#10 r1 = string1.atobin;
end
The $monitor system task display the following:

r1
r1
r1
r1
r1
=
=
=
=
=
x at 0
10 at 10
16 at 20
8 at 30
2 at 40
atoreal()
Returns a real number that is the decimal value of a string.
module m;
real r1;
string string1 = "1235/x0090";
initial
begin
r1 = string1.atoreal;
$display("r1 = 0%f",r1);
end
endmodule

1-11
The $display system task displays:

r1 = 1235.000000
itoa()
Stores the ASCII decimal representation of an integer in a string.
reg [63:0] r1 = 456;
string string1;
initial
begin
string1.itoa(123);
if (string1 == "123")
$display("string1 %s",string1);
string1.itoa(r1);
if (string1 == "456")
$display("string1 %s",string1);
end
The $display system tasks display:

string1 123
hextoa()
hextoa(arg) returns the ASCII hexadecimal representation of the arg.
octtoa()
octtoa(arg) returns the ASCII octal representation of the arg.
bintoa()
bintoa(arg) returns the ASCII binary representation of the arg.
realtoa()
1-12
realtoa(arg) returns the ASCII real representation of the arg.

The following program explains the usage of these string methods.
program test();
string s;
real r;
logic [11:0] h = 'hfa1;
reg [11:0] o = 'o172;
bit [5:0] b = 'b101010;
task t1();
$display("-----Start of Program ----------------");
s.hextoa(h);
$display("Ascii of hex value 'hfa1 is %s",s);
s.octtoa(o);
$display("Ascii of octal value 'o172 is %s",s);
s.bintoa(b);
$display("Ascii of binary value 'b101010 is %s",s);
s = "12.3456";
r = s.atoreal;
$display("Real value of ascii string \"12.3456\" is
%f", r);
s = "";
s.realtoa(r);
$display("Ascii of real value 12.3456 is %s",s);
$display("-------- End of Program ----------------");
endtask
initial
t1();
endprogram

1-13
The output of this program is:

start of Program -------------------Ascii of hex value 'hfa1 is fa1
Ascii of octal value 'o172 is 172
Ascii of binary value 'b101010 is 101010
Real value of ascii string "12.3456" is 12.345600
Ascii of real value 12.3456 is 12.3456
-------- End of Program ----------------------
Predefined String Methods

SystemVerilog provides several class methods to match patterns
within strings.
search()
The search() method searches for a pattern in the string and returns
the index number to the beginning of the pattern. If the pattern is not
found, then the function returns -1. The syntax is:
integer string_variable.search(string pattern);
Here, the argument must be a string.

The following example illustrates the usage of the search( ) class
method.
integer i;
string str = "SystemVerilog supports search( ) method";
i = str.search("supports");
printf("%d \n", i);
This example assigns the index 14 to integer i and prints out 14.
match()

1-14
The match() method processes a regular expression pattern match.

It returns 1 if the pattern is found else, it returns 0 if the pattern is not
found. The syntax is:
integer string_variable.match(string pattern);
Here, the pattern must be a regular Perl expression.

The following example illustrates the usage of the match() class
method.
integer i;
string str;
str = "SystemVerilog supports match( ) method";
i = str.match("mat");
This example assigns the value 1 to integer i because the pattern

mat exists within the string str.
prematch()
The prematch() method returns the string that is located just before
the string found by the last match() function call. The syntax is:
string string_variable.prematch();
The following example illustrates the usage of the prematch() class

method.
integer i;
string str, str1;
str = "SystemVerilog supports prematch( ) method";
i = str.match("supports");
str1 = str.prematch();
This example assigns the value SystemVerilog to string str1.

postmatch()
1-15
The postmatch() method returns the string that is located just after
the string found by the last match() function call. The syntax is:
string string_variable.postmatch();
The following example illustrates the usage of postmatch() class

method.
integer i;
string str, str1;
str = "SystemVerilog supports postmatch( ) method";
i = str.match("postmatch( )");
str1 = str.postmatch();
This example assigns the value method to string str1.

thismatch()
The thismatch() method returns the matched string, based on the
result of the last match() function call. The syntax is:
string string_variable.thismatch();
The following example illustrates the usage of the thismatch() class

method.
integer i;
string str, str1;
str = "SystemVerilog supports thismatch( ) method";
i = str.match("thismatch");
str1 = str.thismatch();
This example assigns the value thismatch to string str1.

backref()
The backref() method returns the matched patterns, based on the
last match() function call. The syntax is:

1-16
function string string_variable.backref(integer index);
Here, index is the integer number of the Perl expression being

matched. Indexing starts at 0.
This function matches a string with Perl expressions specified in a
second string.
The following example illustrates the usage of the backref() function
call.
integer i;
string str, patt, str1, str2;
str = "1234 is a number."
patt = "([0-9]+) ([a-zA-Z .]+)";
i = str.match(patt);
str1 = str.backref(0);
str2 = str.backref(1);
This example checks the Perl expressions given by string patt with
string str. It assigns the value 1234 to string str1 because of the
match to the expression [0-9]+. It assigns the value is a number.
to string str2 because of the match to the expression [a-zA-Z .]+.
Any number of additional Perl expressions can be listed in the patt
definition, and then called using sequential index numbers with the
backref() function.

1-17
Program Blocks
A program block contains the testbench for a design. In the default
implementation of SystemVerilog testbench constructs, all these
constructs must be in one program block. Multiple program blocks is
an LCA feature.
Requiring these constructs in a program block help to distinguish
between the code that is the testbench and the code that is the design.
Program blocks begin with the keyword program, followed by a name
for the program, followed by an optional port connection list, followed
by a semi colon (;). Program blocks end with the keyword
endprogram, for example:
program prog (input clk,output logic [31:0] data, output
logic ctrl);
logic dynamic_array [];
logic assoc_array[*];
int intqueue [$] = {1,2,3};
class classA;
function void vfunc(input in1, output out1);
.
.
.
endfunction
.
.
.
endclass
semaphore sem1 =new (2);
mailbox mbx1 = new();
reg [7:0] reg1;
covergroup cg1 @(posedge clk);

1-18
cp1: coverpoint reg1;

.
.
.
endgroup
endprogram
bit clk = 0;
logic [31:0] data;
logic ctrl;
module clkmod;
.
.
.
prog prog1 (clk,data,ctrl); // instance of the program
.
.
.
endmodule
In many ways a program definition resembles a module definition and

a program instance is similar to a leaf module instance but with special
execution semantics.
A program block can contain the following:
data type declarations including initial values. Dynamic arrays,

associative arrays, and queues are implemented for program
blocks.
user-defined tasks and functions
initial blocks for procedural code (but not always blocks)
final block (please refer Final Blocks for more details)
class definitions
semaphores
1-19
mailboxes
concurrent assertions
coverage groups
When VCS executes all the statements in the initial blocks in a

program, simulation comes to and end.
Final Blocks
The final block is Limited Customer availability (LCA) feature in NTB
(SV) and requires a separate license. Please contact your Synopsys
AC for a license key.
A final block executes in the last simulation time step. The following
example contains a final block:
`timescale 1ns/1ns
module test;
logic l1, l2;
initial
begin
#10 l1=0;
#10 l1=1;
#10 l1=0;
#10 l1=1;
#10 $finish;
end
always @ (posedge l1)
$display("l1 = %0b at %0t",l1,$time);
final$display(" simulation ends at %0t",$time);
endmodule

1-20
l1 = 1 at 20
l1 = 1 at 40
simulation ends at 50
The final block executes in the last simulation time step at time 50.
A final block is the opposite of an initial block in that an initial block
begins execution in the first simulation time step and a final block
executes in the last simulation time step. Apart from the execution
time there are other important differences in a final block. A final
block is like a user-defined function call in that it executes in zero
simulation time and cannot contain the following:
delay specifications
event controls
nonblocking assignment statements
wait statements
user-defined task enabling statements when the user-defined

task contains delay specifications, event controls, wait
statements, or nonblocking assignment statements
Multiple Program Support

The Multiple program block is Limited Customer availability (LCA)
feature in NTB (SV) and requires a separate license. Please contact
your Synopsys AC for a license key.

1-21
Multiple programs support enables multiple testbenches to run in

parallel. Use this when testbenches model standalone components
for example, Verification IP (or work from a previous project). Because
components are independent, direct communication between them
except through signals is undesirable. For example, a UART and CPU
model would communicate only through their respective interfaces,
and not through the testbench. Thus, multiple programs modeling
standalone components allows usage without having knowledge of
the code given, or requiring modifications to your own testbench
Arrays
Dynamic Arrays
Dynamic arrays are unpacked arrays with a size that can be set or
changed during simulation. The syntax for a dynamic array is as
follows:
data_type name [];
The empty brackets specify a dynamic array.

The currently supported data types for dynamic arrays are as follows:
bit
int
time
logic
longint
string

1-22
reg
shortint
class
byte
integer
enum
The new[ ] Built-In Function

The new[] built-in function is for specifying a new size for a dynamic
array and optionally specifying another array whose values are
assigned the dynamic array. Its syntax is as follows:
array_identifier = new[size] (source_array);
The optional (source_array) argument specifies another array

(dynamic or fixed-size) whose values VCS assigns to the dynamic
array. If you dont specify the (source_array) argument, VCS
initializes the elements of the newly allocated array to their default
value.
The optional (source_array) argument must have the same data
type as the array on the left-hand side, but it need not have the same
size. If the size of (source_array) is less than the size of the new
array, VCS initializes the extra elements to their default values. If the
size of (source_array) is greater than the size of the new array,
VCS ignores the additional elements.
program prog;
.
.
.
bit bitDA1 [];
bit bitDA2 [];
bit bitDA3 [];
bit bitSA1 [100];
logic logicDA [];
.
.
.
initial
begin
bitDA1 = new[100];
bitDA2 = new[100] (bitDA2);
bitDA3 = new[100] (bitSA1);

1-23
logicDA = new[100];
end
.
.
.
endprogram
The size() Method

The size method returns the current size of a dynamic array. You
can use this method with the new[] built-in function, for example:
bitDA3 = new[bitDA1.size] (bitDA1);
The delete() Method

The delete method sets a dynamic arrays size to 0 (zero). It clears
out the dynamic array.
bitDA1 = new[3];
$display("bitDA1 after sizing, now size =
%0d",bitDA1.size);
bitDA1.delete;
$display("bitDA1 after sizing, now size =
%0d",bitDA1.size);
VCS displays from this code:

bitDA1 after sizing, now size = 3
bitDA1 after sizing, now size = 0

1-24
Assignments to and from Dynamic Arrays

You can assign a dynamic array to and from a fixed-size array, queue,
or another dynamic array, provided they are of equivalent data types,
for example:
logic lFA1[2];
logic lDA1[];
initial
begin
$display("lDA1 size
lFA1[1]=1;
lFA1[0]=0;
lDA1=lFA1;
$display("lDA1[1] =
$display("lDA1[0] =
$display("lDA1 size
end
endprogram
= %0d",lDA1.size);
%0d", lDA1[1]);
%0d", lDA1[0]);
= %0d",lDA1.size);
VCS displays:
lDA1 size = 0lDA1[1] = 1
lDA1[0] = 0
lDA1 size = 2
When you assign a fixed-size array to a dynamic array, the dynamic

arrays size changes to the size of the fixed-size array. This is also
true when you assign a dynamic array with a specified size to another
dynamic array, for example:
logic lDA1[];
logic lDA2[];
initial
begin
lDA1=new[2];
$display("lDA2 size = %0d",lDA2.size);
lDA1[1]=1;

1-25
lDA1[0]=0;
lDA2=lDA1;
$display("lDA2[1] = %0d", lDA2[1]);
$display("lDA2[0] = %0d", lDA2[0]);
$display("lDA2 size = %0d",lDA2.size);
end
endprogram
This code displays the following:

lDA2 size
lDA2[1] =
lDA2[0] =
lDA2 size
= 0
1
0
= 2
You can assign a dynamic array to a fixed-size array, provided that

they are of equivalent data type and that the current size of the
dynamic array matches the size of the fixed-size array.
Associative Arrays
An associative array has a lookup table for the elements of its declared
data type. Its index is a data type which serves as the lookup key for
the table. This index data type also establishes an order for the
elements.
The syntax for declaring an associative array is as follows:
data_type array_id [index_type];
data_type array_id [* | string];
Where:
data_type
Is the data type of the associative array.

1-26
array_id
Is the name of the associative array.

index_type
Specifies the type of index. Only two types are currently
implemented. They are as follows:
*
Specifies a wildcard index.
string
Specifies a string index.
Wildcard Indexes
You can enter the wildcard character as the index.
data_type array_id [*];
Using the wildcard character permits entering any integral data type
as the index. Integral data types represent an integer (shortint,
int, longint, byte, bit, logic, reg, integer, and also packed
structs, packed unions, and enum.
program m;
bit [2:0] AA1[*];
int int1;
logic [7:0] log1;
initial begin
int1 = 27;
log1 = 42;
AA1[456] = 3'b101;
AA1[int1] = 3'b000;
AA1[log1] = 3'b111;
end
endprogram
// index is 27
// index is 42

1-27
String Indexes
A string index specifies that you can index the array with a string. You
specify a string index with the keyword string.
program p;
logic [7:0] a[string];
string string_variable;
initial begin
a["sa"] = 8;
a["bb"] = 15;
a["ec"] = 29;
a["d"] = 32;
a["e"] = 45;
a[string_variable] = 1;
end
endprogram
Associative Array Assignments and Arguments

You can only assign an associative array to another associative array
with a equivalent data type. Similarly, you can only pass an
associative array as an argument to another associative array with a
equivalent data type.
Associative Array Methods

There are methods for analyzing and manipulating associative
arrays.
num
Returns the number of entries in the array.

1-28
delete
Removes all entries from an array. If you specify an index, this
method removes the entry specified by the index.
exists
Returns a 1 if the specified entry exists.
first
Assigns the value of the smallest or alphabetically first entry in
the array. Returns 0 if the array is empty and returns 1 if the array
contains a value.
last
Assigns the value of the largest or alphabetically last entry in the
array. Returns 0 if the array is empty and returns 1 if the array
contains a value.
next
Finds the entry whose index is greater than the given index. If
there is a next entry, the index variable is assigned the index of
the next entry, and the function returns 1. Otherwise, variable is
unchanged, and the function returns 0
prev
Finds the entry whose index is smaller than the given index. If
there is a previous entry, the index variable is assigned the index
of the previous entry, and the function returns 1. Otherwise,
variable is unchanged, and the function returns 0.
The following example shows how to use these methods.
program p;
logic [7:0] a[string];
string s_index;
initial begin
a["sa"] = 8;
a["bb"] = 15;
a["ec"] = 29;
a["d"] = 32;

1-29
a["e"] = 45;
$display("number of entries = %0d",a.num);
if(a.exists("sa"))
$display("string \"sa\" is in a");
if(a.first(s_index))
begin
$display("the first entry is
\"%s\"",s_index);
do
$display("%s :
%0d",s_index,a[s_index]);
while (a.next(s_index));
end
if(a.last(s_index))
begin
$display("the last entry is
\"%s\"",s_index);
do
$display("%s :
%0d",s_index,a[s_index]);
while (a.prev(s_index));
end
a.delete;
$display("number of entries = %0d",a.num);
end
endprogram
VCS displays the following:

number of entries = 5
string "sa" is in a
the first entry is "bb"
bb : 15
d : 32
e : 45
ec : 29
sa : 8
the last entry is "sa"
sa : 8
ec : 29

1-30
e : 45
d : 32
bb : 15
number of entries = 0
Queues
A queue is an ordered collection of variables with the same data type.
The length of the queue changes during simulation. You can read any
variable in the queue, and insert a value anywhere in the queue.
The variables in the queue are its elements. Each element in the
queue has a number: 0 is the number of the first, you can specify the
last element with the $ (dollar sign) symbol. The following are some
examples of queue declarations:
logic logque [$];
This is a queue of elements with the logic data type.
int intque [$] = {1,2,3};
This is a queue of elements with the int data type. These
elements are initialized 1, 2, and 3.
string strque [$] = {"first","second","third","fourth"};
This is a queue of elements with the string data type. These
elements are initialized "first", "second", "third", and
"fourth".
You assign the elements to a variable using the element number, for
example:
string s1, s2, s3, s4;
initial
begin
s1=strque[0];
s2=strque[1];

1-31
s3=strque[2];
s4=strque[3];
$display("s1=%s s2=%s s3=%s s4=%s",s1,s2,s3,s4);
.
.
.
end

s1=first s2=second s3=third s4=fourth
You also assign values to the elements using the element number,
for example:
int intque [$] = {1,2,3};
initial
begin
intque[0]=4;
intque[1]=5;
intque[2]=6;
$display("intque[0]=%0d intque[1]=%0d intque[2]=%0d",
intque[0],intque[1],intque[2]);
.
.
.
end

intque[0]=4 intque[1]=5 intque[2]=6
Concatenation operations, for adding elements, are not yet

supported, for example:
intque = {0,intque};
intque = {intque, 4};

1-32
Removing elements from a queue are not yet supported, for example:
strque = strque [1:$];
intque = intque[0:$-1];
Queue Methods
There are the following built-in methods for queues:
size
Returns the size of a queue.
program prog;
int intque [$] = {1,2,3};
initial
begin
for (int i = 0; i < intque.size; i++)
$display(intque[i]);
end
endprogram
insert
Inserts new elements into the queue. This method takes two
arguments: the first is the number of the element, the second is
the new value.
program prog;
string strque [$] = {"first","second","third","forth"};
initial
begin
for (int i = 0; i < strque.size; i++)
$write(strque[i]," ");
$display(" ");
strque.insert(1,"next");
strque.insert(2,"somewhere");
for (int i = 0; i < strque.size; i++)

1-33
$display(" ");
end
endprogram

first second third forth
first next somewhere second third forth
delete
Removes an element from the queue, specified by element
number. If you dont specify an element number, this method
deletes all elements in the queue.
string strque [$] = {"first","second","third"};
initial
begin
for (int i =0; i<strque.size; i++)
$display(" ");
strque.delete(1);
end
The system tasks display the following:

first second third
first third
pop_front
Removes and returns the first element of the queue.
string s1;
initial
begin
$write("the elements of strque are ");
1-34
$display("\ns1 before pop contains %s ",s1);
s1 = strque.pop_front;
$display("s1 after pop contains %s ",s1);
$write("the elements of strque are ");
end

the elements of strque are first second third
s1 before pop contains
s1 after pop contains first
the elements of strque are second third
string s1;
initial
begin
$display(" ");
s1 = strque.pop_front;
end

first second third
second third
pop_back
Removes and returns the last element in the queue.
program prog;
string s1;
initial
begin

1-35
$write("the elements of strque are

$display("\ns1 before pop contains
s1 = strque.pop_back;
$display("s1 after pop contains %s
$write("the elements of strque are
end
endprogram
");
%s ",s1);
",s1);
");

the elements of strque are first second third
s1 before pop contains
s1 after pop contains third
the elements of strque are first second
push_front and push_back

Add elements to the front and back of the queue.
int intque [$] = {1,2,3};
initial
begin
for( int i = 0; i < intque.size; i++)
$write(intque[i]," ");
intque.push_front(0);
intque.push_back(4);
$write(" \n");
for( int i = 0; i < intque.size; i++)
$write(intque[i]," ");
end

1
0
2
1

1-36
3
2
The foreach Loop

A foreach loop iterates through an array. Its argument is any kind
of array and the loop variables designate the indexes of the array.
The following is an elementary example of the use of this construct:
module test;
bit [11:10][9:8][7:0] bit_array1;
initial
begin
foreach (bit_array1[dim1,dim2])
bit_array1 [dim1][dim2]=dim1*dim2;
foreach (bit_array1[dim1, dim2])
$display("bit_array1[%1d][%1d]=%0d",
dim1,dim2,bit_array1[dim1][dim2]);
end
endmodule
The bit data type array named bit_array1 has three dimensions.
The first foreach loop iterates through the first two dimensions
11:10 and 9:8, to assign 8-bit values to these elements.
The second foreach loop displays the deposited values.
bit_array1
bit_array1
bit_array1
bit_array1
[11][9]=99
[11][8]=88
[10][9]=90
[10][8]=80
The foreach loop also works with other types of arrays, such as this
example of a string array:
module test;
string words [2];

1-37
initial
begin
words [1] = "verification";
words [0] = "simulation";
foreach (words [j])
$display("string element number %1b",j,
"contains \"",words[j],"\"");
end
endmodule

string element number 0 contains "simulation"
string element number 1 contains "verification"
The foreach loop also works with queues and dynamic and
associative arrays. The following is an example with a dynamic
array:
program test;
integer fixed_int_array[3] = {0, 1, 2};
integer dynamic_int_array[];
initial
begin
dynamic_int_array=new[3](fixed_int_array);
foreach (dynamic_int_array[dim1])
$display("dynamic_int_array [%1d]=%0d",
dim1,dynamic_int_array[dim1]);
end
endprogram

dynamic_int_array [0]=0

1-38
The following is an example with an associative array:

program test;
bit [2:0] assoc_array1 [*];
initial
begin
assoc_array1[0]=3'b000;
foreach (assoc_array1[dim1])
$display("assoc_array1 [%1d]=%0d",
dim1,assoc_array1[dim1]);
end
endprogram

assoc_array1 [0]=0
assoc_array1 [1]=1
assoc_array1 [7]=7
Array Aggregates (Reduction/Manipulation) Methods in

Constraints
SystemVerilog includes a set of array reduction methods which allow
declarations of complex constraints for arrays and queues in a
compact and flexible format.
The following is the syntax for these methods:
function array_or_expression_type method
(array_type iterator = item)
The array aggregate expression is a valid part of a constraint

expression and can be used any place that a variable can be used,
with the exception of solve-before constraints.

1-39
List of Aggregate Methods

Table 1-1
Method
Description
sum()
Performs addition and returns sum of array elements
product()
Performs multiplication, and returns product of array

elements
and()
Performs bitwise AND operation, and returns bit-wise AND

of array elements.
or()
Performs bitwise OR operation, and returns bit-wise OR of

array elements
xor()
Performs logical XOR operation, and returns logical XOR

of all array elements.
The following code is an example of the aggregate method, sum() in

an inline constraint block:
program test;
class myclass;
rand int b[2:0];
int a[3:0] = {2,4,6,8};
function void post_randomize();
if((b[0] == 28) && (b[2] == 28))
$display("test Passed");
else
$display("test Failed");
endfunction
endclass
myclass mc = new;
initial begin
int i;
i = mc.randomize() with { foreach (b [j]) b[j] ==
a.sum(temp) with (a[temp.index] + 2);};

1-40
if(i)
$display("Randomization Success");
else
$display("Randomization Fails");
end
endprogram
Notes
1. Empty array - If the array over which the aggregate operation is
defined has size 0, then the behavior is as follows:
- array.sum(): The expression is substituted by 0.
- array.product(): The expression is substituted by 1.
For all other aggregate methods there is a runtime error if
reference to the aggregate operation is in an ON constraint block.
2. Array types - The array aggregate methods and the foreach loop
support the fixed size array, dynamic array, associative array, and
SmartQ types of arrays in every context.
Unsupported features in Array aggregates:

Using virtual interfaces to refer to variables inside array
constraints.
Array aggregates of SV style (and, xor, or, etc.)
Array aggregates outside constraint blocks (and, xor, or, etc).
Array aggregates with usage as follows: array.cum with (item ==

item.index).

1-41
Classes
The user-defined data type, class, is composed of data members of
valid SystemVerilog data types (known as properties) and tasks or
functions (known as methods) for manipulating the data members.
The properties and methods, taken together, define the contents and
capabilities of a class instance (also referred to as an object). Use
the class and endclass keywords to declare a class.
class B;
int q = 3;
function int send (int a);
send = a * 2;
endfunction
task show();
$display("q = %0d", q);
endtask
endclass
In the above example, the members of class B are the property, q,

and the methods send() and show().
Note:
- See Class Packet Example on page 1-68 for a more complex
example of a class declaration. The name of the class is
Packet.
- Unpacked unions inside classes are not yet supported. Packed
unions and packed and unpacked structures inside classes are
supported.
class myclass;
typedef struct packed{ int int1;
logic [7:0] log1;

1-42
} struct1;
struct1 mystruct;
typedef struct packed { int intt1; logic [31:0] logg1; }
pstruct1;
typedef union packed {
pstruct1 u_pstruct1;
} p_union1;
endclass
Creating an Instance (object) of a Class

A class declaration is the template from which objects are created.
When a class is constructed the object is built using all the properties
and methods from the class declaration.
To create an object (that is, an instance) of a declared class, there
are two steps. First, declare a handle to the class (a handle is a
reference to the class instance, or object):
class_name handle_name;
Then, call the new() class method:

handle_name = new();
The following example expands on the above example to show how

to create an instance of class B.
program P;
class B;
int q = 3;

1-43

send = a * 2;
endfunction
task show();
endtask
endclass
initial begin
B b1; //declare handle, b1
b1 = new; //create an object by calling new
end
endprogram
The above two steps can be merged into one for instantiating a class
at the time of declaration:
class_name
handle_name = new();
For example:
B b1 = new;
The new() method of the class is a method which is part of every

class. It has a default implementation which simply allocates memory
for the object and returns a handle to the object.
Constructors
You can declare your own new() method. In such a case, the prototype
that you must follow is:
function new([arguments]);
// body of method
endfunction
Use this syntax when using the user-defined constructor:

1-44
handle_name = new([arguments]);
Arguments are optional.

Below is an example of a user-defined constructor:
program P;
class B; //declare class
integer command;
function new(integer inCommand = 1);
command = inCommand;
$display("command = %d", command);
endfunction
endclass
endprogram
When called, new() will print the value passed to it as the value of
command.
When a class property has been initialized in its declaration, the
user-defined new() constructor can be used to override the initialized
value. The following example is a variant of the first example in this
section.
program P;
class A;
int q = 3; //q is initialized to 3
function new();
q = 4; //constructor overrides & assigns 4
endfunction
endclass
A a1;
initial
begin
a1 = new;
$display("The value of q is %0d.", a1.q);
end
endprogram
1-45

The value of q is 4.
If a property is not initialized by the constructor, it is implicitly

initialized, just like any other variable, with the default value of its data
type.
Assignment, Re-naming and Copying

Consider the following:
class Packet;
...
endclass
Packet p1;
Packet p1; creates a variable, p1, that can hold the handle of an
object of class Packet. The initial default value of p1 is null. The
object does not yet exist, and p1 does not contain an actual handle,
until an instance of type Packet is created as shown below:
p1 = new(); //if no arguments are being passed, () can be
//omitted. e.g., p1=new;
Another variable of type Packet can be declared and assigned the

handle, p1 to it as shown below:
Packet p2;
p2 = p1;
In this case, there is still only one object. This single object can be
referred to with either variable, p1 or p2.

1-46
Now consider the following, assuming p1 and p2 have been declared

and p1 has been instantiated:
p2 = new p1;
The handle p2 now points to a shallow copy of the object referenced

by p1. Shallow copying creates a new object consisting of all
properties from the source object. Objects are not copied, only their
handles. That is, a shallow copy is a duplication of members, including
handles, of an objects first level constituents in the hierarchy.
However, an object referenced by a copied handle is not, itself,
copied. That is, an object contained within an object is not copied,
only the referential handle.
Static Properties
The static keyword is used to identify a class property that is shared
with all instances of the class. A static property is not unique to a
single object (that is, all objects of the same type share the property).
A static variable is initialized once.
Syntax
static data_type variable;
Example
program test;
class Parcel;
static int count = 2;
function new();
count++;
endfunction
endclass

1-47
initial begin
Parcel pk1 = new;
Parcel pk2 = new;
Parcel pk3 = new;
$display("%d Parcel",
pk3.count);
pk2.count);
pk1.count);
end
endprogram
Output
5 Parcel
5 Parcel
5 Parcel
In the above example, every time an object of type Parcel is created,

the new() function is invoked and the static variable count is
incremented. The final value of count is 5. If count is declared as
non-static, the output of the above program is:
3 Parcel
3 Parcel
3 Parcel
Global Constant Class Properties

The const keyword is used to designate a class property as
read-only. Class objects are dynamic objects, therefore either global
or instance properties can be designated const. At present, only
global constants are supported.
When declared, a global constant class property includes an initial
value. Consider the following example:
//global_const.sv
program test;

1-48
class Xvdata_Class;
const int pi = 31412;//const variable
endclass
Xvdata_Class data;
initial begin
data = new();
data.pi = 42; //illegal and will generate
//compile time error
end
endprogram
The line, data.pi=42, is not valid and yields the following compile
time error message:
Error-[IUCV] Invalid use of 'const' variable
Variable 'pi' declared as 'const' cannot be used
in this context
"global_const.sv", 17: data.pi = 42;
Method Declarations: Out of Class Body Declarations

The following example demonstrates the usage of scope resolution
for:
Declaring class function outside class
Accessing class enum label in inline constraint block
Declaring constraint block out of class and also accessing class

enum label inside that block
program prog;
typedef enum {X, Y} A;
class C;
typedef enum {S1,S2,S3,S4} E; //enum declared inside class

1-49
rand A a1;
rand E e1;
extern function f1();
constraint c;
endclass
//out of class body method declared with the help of ::
//operator
function C::f1();
int i;
$display("Accessing enum label in constraint block
through :: operator");
repeat (5)
begin
i = this.randomize();
if(i)
$display("e1 = %s", this.e1.name);
else
$display("Randomization Failed");
end
// accessing enum label through :: operator in out
// of class body method
$display("Accessing enum label in function block
through :: operator");
i = this.randomize with {e1 != C::S2;};
if(i)
$display("e1 = %s", this.e1.name);
else
endfunction
// out of block constraint declaration accessing enum label
// through :: operator
constraint C::c { a1 == X; e1 inside {C::S1,C::S2,C::S3}; }
C c1
= new;
initial begin
c1.f1();

1-50
// creating object of class C
end
endprogram
The Output of this program is

Accessing enum label in constraint block through :: operator
e1 = S1
e1 = S2
e1 = S3
e1 = S1
e1 = S1
Accessing enum label in function block through :: operator
e1 = S3
Class Extensions
Subclasses and Inheritance
SystemVerilogs OOP implementation provides the capability of
inheriting all the properties and methods from a base class, and
extending its capabilities within a subclass. This concept is called
inheritance. Additional properties and methods can be added to this
new subclass.
For example, suppose we want to create a linked list for a class
Packet. One solution would be to extend Packet, creating a new
subclass that inherits the members of the parent class (see Class
Packet Example on page 68 for class Packet declaration).
class LinkedPacket extends Packet;
LinkedPacket next;
function LinkedPacket get_next();
get_next = next;
endfunction

1-51
endclass
Now, all of the methods and properties of Packet are part of

LinkedPacket - as if they were defined in LinkedPacket - and
LinkedPacket has additional properties and methods. We can also
override the parents methods, changing their definitions.
Abstract classes
A group of classes can be created that are all derived from a
common abstract base class. For example, we might start with a
common base class of type BasePacket that sets out the structure of
packets but is incomplete; it would never be instantiated. It is
abstract. From this base class, a number of useful subclasses can
be derived: Ethernet packets, token ring packets, GPSS packets,
satellite packets. Each of these packets might look very similar, all
needing the same set of methods, but they would vary significantly
in terms of their internal details.We start by creating the base class
that sets out the prototype for these subclasses. Since it will not be
instantiated, the base class is made abstract by declaring the class
as virtual:
virtual class BasePacket;
By themselves, abstract classes are not tremendously interesting,

but, these classes can also have virtual methods. Virtual methods
provide prototypes for subroutines, all of the information generally
found on the first line of a method declaration: the encapsulation
criteria, the type and number of arguments, and the return type if it is
needed. When a virtual method is overridden, the prototype must be
followed exactly:
virtual class BasePacket;
virtual function integer send(bit[31:0] data);

1-52
endfunction
endclass
class EtherPacket extends BasePacket;
function integer send(bit[31:0] data)
// body of the function
...
endfunction
endclass
EtherPacket is now a class that can be instantiated.

If a subclass which is extended from an abstract class is to be
instantiated, then all virtual methods defined in the abstract class must
have bodies either derived from the abstract class, or provided in the
subclass. For example:
program P;
virtual class Base;
virtual task print(string s);
$display("Base::print() called from %s", s);
endtask
extern virtual function string className();
endclass
class Derived extends Base;
function string className();
return "Derived";
endfunction
endclass
Derived d = new;
initial #1 d.print("");
endprogram

1-53
Methods of non-abstract classes can also be declared virtual. In this

case, the method must have a body, since the class, and its
subclasses, must be able to be instantiated. It should be noted that
once a method is declared as virtual, it is forever virtual. Therefore,
the keyword does not need to be used in the redefinition of a virtual
method in a subclass.
Polymorphism
The ability to call a variety of functions using the exact same interface
is called polymorphism.
Suppose we have a class called Packet. Packet has a task called
display(). All the derived classes of Packet will also have a display()
task, but the base version of display() does not satisfy the needs of
the derived classes. In such a case we want the derived class to
implement its own version of the display() task to be called.
To achieve polymorphism the base class must be abstract (defined
using the virtual identifier) and the method(s) of the class must be
defined as virtual. The abstract class (see page 52 for definition of
abstract class) serves as a template for the construction of derived
classes.
virtual class Packet;
extern virtual task display();
endclass
The above code snippet defines an abstract class, Packet. Within

Packet the virtual task, display(), has been defined. display() serves
as a prototype for all classes derived from Packet. Any class which
derives from Packet() must implement the display() task. Note that
the prototype is enforced for each derived task (that is, must keep the
same arguments, etc.).

1-54
class MyPacket extends Packet;

task display();
$display("This is the display within
MyPacket");
endtask
endclass
class YourPacket extends Packet;
task display();
$display("This is the display within
YourPacket");
endtask
endclass
This example illustrates how the two classes derived from Packet
implement their own specific version of the display() method.
All derived classes can be referenced by a base class object. When
a derived class is referenced by the base class, the base class can
access the virtual methods within the derived class through the
handle of the base class.
program polymorphism;
//include class declarations of Packet, MyPacket
//and YourPacket here
MyPacket mp;
YourPacket yp;
Packet p; //abstract base class
initial
begin
mp = new;
yp = new;
p = mp; // mp referenced by p
p.display();// calls display in MyPacket
p = yp;
p.display();// calls display in YourPacket
end
endprogram
Output:

1-55
This is the display within MyPacket

This is the display within YourPacket
This is a typical, albeit small, example of polymorphism at work.
Scope Resolution Operator ::

Scope resolution operator allows you to access user defined class
types as shown in the following example:
program p;
class A;
typedef enum {red,yellow,blue} color;
typedef byte MYBYTE;
endclass
A::MYBYTE b1 = 8'hff;
//declaring b1 of class byte type
A::color c1;
//declaring c1 of class enum type
initial begin
$display("%h",b1);
$display("%0d",c1.first);
$display("%0d",c1.next);
end
endprogram
The Output of the program is:

ff
0
1

1-56
super keyword
The super keyword is used from within a derived class to refer to
properties of the parent class. It is necessary to use super when the
property of the derived class has been overridden, and cannot be
accessed directly.
program sample;
class Base;
integer p;
virtual task display();
$display("\nBase: p=%0d", p);
endtask
endclass
class Extended extends Base;
integer q;
task display();
super.display(); //refer to Base "display()"
$display("\nExtended: q=%0d\n", q);
endtask
endclass
Base b1;
Extended e1;
initial begin
b1 = new; // b1 points to instantiated object of Base
e1 = new; // e1 points to object of Extended
b1.p = 1; //property "p" of Base initialized to 1
b1.display(); //will print out "Base: p=1"
e1.p = 2; //"p" of Base is now 2
e1.q = 3; //"q" of Extended initialized to 3
e1.display(); //prints "Base: p=2 Extended: q=3"
end
endprogram
Output of the above program is:

Base: p=1

1-57
Base: p=2
Extended: q=3
In the above example, the method, display() defined in Extended

calls display(), which is defined in the super class, Base. This is
achieved by using the super keyword.
The property may be a member declared a level up or a member
inherited by the class one level up. Only one level of super is
supported.
When using the super keyword within the constructor, new, it must
be the first statement executed in the constructor. This is to ensure
the initialization of the superclass prior to the initialization of the
subclass.
Casting
$cast enables you to assign values to variables that might not
ordinarily be valid because of differing data type.
The following example involves casting a base class handle (b2),
which actually holds an extended class-handle (e1), at runtime back
into an extended class-handle (e2).
program sample;
class Base;
integer p;
$write("\nBase: p=%0d\n", p);
endtask
endclass
class Extended extends Base;
1-58
integer q;
super.display();
$write("Extended: q=%0d\n", q);
endtask
endclass
Base b1 = new(), b2;
Extended e1 = new(), e2;
initial begin
b1.p = 1;
$write("Shows the original base property p\n");
b1.display(); // Just shows base property
e1.p = 2;
e1.q = 3;
$write("Shows the new value of the base property, p,
and value of the extended property, q\n");
e1.display(); // Shows base and extended properties
// Have the base handle b2 point to the extended object
b2 = e1;
$write("The base handle b2 is pointing to the
Extended object\n");
b2.display(); // Calls Extended.display
// Try to assign extended object in b2 to extended handle e2
$write("Using $cast to assign b2 to e2\n");
if ($cast(e2, b2))
e2.display(); // Calls Extended.display
else
$write("cast_assign of b2 to e2
failed\n");
end
endprogram

Shows the base property p, which is originally 1
Base: p=1

1-59
Shows new value of the base property, p, and value of the

extended property, q
Base: p=2
Extended: q=3
The base handle b2 is pointing to the Extended object
Base: p=2
Extended: q=3
Using $cast to assign b2 to e2
Base: p=2
Extended: q=3
In the current implementation, there is a restriction related to the

casting of enumerated types. $cast() into an enum-type destination
issues a NYI error in case the type of the source does not match that
of the destination.
$cast(enum1, int1)
= int
// NYI, destination = enum, source
The following case is supported as long as enum1 and enum2 are of

same base enum-type:
$cast(enum1, enum2)
Enumerated types can, however, be cast into any other non-enum

types (that is, they can be used as the source argument in $cast()
without any restrictions:
$cast(int1, enum1) // supported, destination non-enum
(int)

1-60
Chaining Constructors
To understand the relational use of the terms base and super as
employed to refer to classes, consider the following code fragment:
class ClassA;
...
endclass
class Class_a extends ClassA;
...
endclass
class class_ab extends Class_a;
...
endclass
class Class_b extends ClassA;
...
endclass
Both Class_a and Class_b are extended from ClassA using the
extends keyword, making ClassA the base class for these two
subclasses. Class_ab extends from Class_a, making Class_a the
base class for the subclass, Class_ab. Both ClassA and Class_a are
super classes since they each have subclasses extended from them.

1-61
Figure 1-1
Base and Sub Classes
ClassA
Class_a
Class_ab
Base Class
Subclass
Class_b
When a subclass is instantiated, the constructor of the extended

super class is implicitly called. If that class, in turn, has a super class,
it will implicitly call the constructor of that class. This will continue up
the hierarchy until no further super classes exist. In Figure 1-2,

1-62
Figure 1-2
Chaining Constructors
ClassA
Class_a
Class_ab
Base Class
Subclass
Class_b
when Class_ab is instantiated, the new constructor for Class_a is

called. In turn, the new constructor for ClassA is called. Since
ClassA is the last super class in the chain, an object of Class_ab is
then created. When Class_b is instantiated, the new constructor for
ClassA is called and an object of Class_b is created.
This process is called chaining constructors.
If the initialization method of the super-class requires arguments,
you have two choices. If you want to always supply the same
arguments, you can specify them at the time you extend the class:
class EtherPacket extends Packet(5);

1-63
This will pass 5 to the new() routine associated with Packet.

A more general approach is to use the super keyword to call the
superclass constructor.
function new();
super.new(5);
endfunction
If included, the call to super() must be the first executable statement

(that is, not a declaration) in the constructor.
Accessing Class Members

Properties
A property declaration may be preceded by one of these keywords:
local
protected
The default protection level for class members is public. Global

access is permitted via class_name.member.
In contrast, a member designated as local is one that is only visible
from within the class itself.
A protected class property (or method) has all of the characteristics
of a local member, except that it can be inherited, and is visible to
subclasses.

1-64
Accessing Properties
A property of an object can be accessed using the dot operator (.).
The handle name for the object precedes the dot, followed by the
qualifying property name (for example, address, command).
instance_name.property_name
Methods
Tasks or functions, known as methods, can be designated as
local, public, or protected. They are public by default.
Accessing Object Methods
An objects methods can be accessed using the dot operator (.). The
handle for the object precedes the dot, followed by the method.
program access_object_method;
class B;
int q = 3;
send = a * 2;
endfunction
task show();
endtask
endclass
initial begin
B b1;
//declare handle
b1 = new; // instantiate
b1.show(); //access show() of object b.1
$display("value returned by b1.send() = %0d",
b1.send(4));//access send()of object b.1
end
endprogram

1-65
Output of program
q = 3
value returned by b1.send() = 8
this keyword
The this keyword is used to unambiguously refer to properties or
methods of the current instance. For example, the following
declaration is a common way to write an initialization task:
program P;
class Demo;
integer x;
task new (integer x);
this.x = x;
endtask
endclass
endprogram
The x is now both a property of the class and an argument to the task
new(). In the task new(), an unqualified reference to x will be resolved
by looking at the innermost scope, in this case the subroutine
argument declaration. To access the instance property, we qualify it
with this to refer to the current instance.

1-66
The following is another, complete, example.

program P;
class Demo;
integer x=4;
function integer send(integer x);
this.x = x*3;
endfunction
task show();
$display("The value of x in the object of
type Demo is = %d", send(this.x));
endtask
endclass
intial begin
integer x=5;
Demo D =new;
D.show();
$display("The value of the global variable x is
%0d", x);
end
endprogram

The value of x in the object of type Demo is = 12
The value of the global variable x is =5

1-67
Class Packet Example

class Packet;
bit [3:0] command; //property declarations
bit [40:0] address;
bit [4:0] master_id;
integer time_requested;
integer time_issued;
integer status;
function new(); // initialization
command = 0;
address = 41b0;
master_id = 5bx;
endfunction
task clean(); //method declaration
command = 0;
address = 0;
master_id = 5bx;
endtask
task issue_request(int delay); //method
// declaration send request to bus
endtask
function integer current_status(); //method
// declaration
current_status = status;
endfunction
endclass
Unpacked Structures in Classes

The following code examples shows an unpacked structure in a
class:
program test;
1-68
class myclass;
.
.
.
typedef struct { int int1;
logic [7:0] log1;
} struct1;
struct1 mystruct1;
.
.
.
endclass
endprogram

1-69
Random Constraints
SystemVerilog has constructs for the random testing of a design and
a means of constraining the random testing to find hard to reach
corner cases.
Note:
To enable the new constraint features, use the -ntb_opts
new_constraints compile-time option.
Random Variables
You need variables to which VCS assigns random values. There are
two types of random variables and two different keywords to begin
their declarations:
rand
Specifies a standard random variable
randc
Specifies a random-cyclic variable.
The following is an example of a standard random variable
declaration:
rand bit [7:0] randbit1;
Variable randbit1 has eight bits so its possible values range from
0 to 255. The chances that VCS assigns any of these values is
precisely 1/256.
The following is an example of a random-cyclic variable declaration:
randc bit [1:0] randc1;

1-70
Variable randc1 has two bits so its possible values range from 3 to
0. VCS derives a random order, or permutation, of all the possible
values, and assigns the values in the permutation in a sequence.
If VCS assigns a value of 3, it wont assign 3 again until it first assigns
2, 1, and 0 (in no particular order), and after it assigns the permutation,
it derives the next permutation, beginning with any of the possible
values.
If this were a standard random variable, after VCS assigns the 3 value,
there is a 1/4 chance that VCS assigns the 3 again, but because it is
a random-cyclic variable, after VCS assigns the 3, there is no chance
that 3 will also be the next assigned value.
Random variables can only be declared in a class.
class Bus;
rand bit [15:0] addr;
rand bit [15:0] data;
.
.
.
endclass
Constraint Blocks
Constraints are specified in a constraint block. A constraint block can
be declared in the same class in which the random variables are
declared as well as in a class extended from the base class in which
the random variable is defined (see page 61 for definition of base
class) A constraint block begins with the keyword constraint.
program prog;

1-71
class myclass;
rand logic [1:0] log1,log2,log3;
randc logic [1:0] log4;
constraint c1 {log1 > 0;}
constraint c2 {log2 < 3;}
endclass
myclass mc = new;
initial
repeat (10)
if(mc.randomize()==1)
$display("log1 = %0d log2=%0d log3=%0d
log4=%0d",mc.log1, mc.log2,
mc.log3, mc.log4);
endprogram
In this program block class myclass contains the following:
Declarations for standard random variables, with the logic data

type and two bits, named log1, log2, and log3.
A declaration for cyclic-random variable, with the logic data type

and two bits, named log4.
Constraint c1 which says that the random values of log1 must be

greater than 0.
Constraint c2 which says that the random values of log2 must be

less than 3.
The randomize() method is described in Randomize Methods on

page 1-84.
log1 = 1 log2=1 log3=1 log4=2

1-72
log1
log1
log1
log1
log1
log1
log1
log1
log1
=
=
=
=
=
=
=
=
=
1
2
1
3
3
3
1
2
1
log2=2
log2=0
log2=1
log2=2
log2=2
log2=1
log2=1
log2=0
log2=0
log3=0
log3=1
log3=1
log3=1
log3=3
log3=0
log3=1
log3=2
log3=2
log4=0
log4=1
log4=3
log4=0
log4=3
log4=2
log4=1
log4=3
log4=0
The possible values of all the random variables range from 3 to 0,

but the values of log1 are never 0, and the values of log2 are never
greater than 3. VCS can assign the same value to log3 over again,
but never assigns the same value to log4 over again until it has cycled
through all the other legal values.
By means of in-line constraints, a constraint block can be declared
for random variables declared in a class while calling the randomize()
method on that class object. (See section entitled In-line
Constraints on page 92).
program test;
class base;
rand int r_a;
endclass
base b = new;
initial begin
int ret;
ret = b.randomize with {r_a > 0; r_a <= 10;} ;
// where my declaration {r_a >0 ; r_a <= 10; }
// is now a constraint block
if(ret == 1)
$display("Randomization success");
else
end
endprogram

1-73
External Declaration
You can declare a constraint block outside of a class declaration.
program prog1;
class cl1;
rand integer rint1, rint2, rint3;
constraint constr1;
endclass
constraint cl1::constr1 { rint1 < rint2; rint2 < rint3; }
endprogram
Inheritance
Constraints follow the same rules of inheritance as class variables,
tasks, and functions.
class myclass;
rand logic [1:0] log1,log2,log3;
randc logic [1:0] log4;
constraint c1 {log1 > 0;}
endclass
class myclass2 extends myclass;
endclass
myclass2 mc = new;
The keyword extends specifies that class myclass2 inherits from

class myclass and then can change constraint c2, specifying that it
must be less than 2, instead of less than 3.

1-74
Set Membership
You can use the inside operator to specify a set of possible values
that VCS randomly applies to the random variable.
program prog;
class myclass;
rand int int1;
constraint c1 {int1 inside {1, [5:7], [105:107]};}
endclass
myclass mc = new;
initial
repeat (10)
if(mc.randomize()==1)
$display("int1=%0d",mc.int1);
endprogram
Constraint c1 specifies that the possible values for int1 are as follows:
a range beginning with 5 and ending with 7
a range beginning with 105 and ending with 107

int1=1
int1=7
int1=5
int1=107
int1=106
int1=5
int1=5
int1=6
int1=107
int1=1

1-75
All these values are equally probable.

In the following example, the inside operator is used to specify
possible values in an integer array:
program test;
class pkt;
integer bills[0:8] = { 1, 2, 5, 10, 20, 50, 100, 500,
1000 };
rand integer v;
constraint c4 { v inside bills; }
endclass
int result;
pkt Pkt=new();
initial
begin
repeat (10) begin
result = Pkt.randomize();
$display("v is %d\n",Pkt.v);
end
end
endprogram

v
v
v
v
v
v
v
v
is
is
is
is
is
is
is
is

1-76
1
100
1000
500
10
1
20
1
Weighted Distribution
You can use the dist operator to specify a set of values or ranges
of values, where you give each value or range of values a weight,
and the higher the weight, the more likely VCS is to assign that value
to the random variable.
If we modify the previous example as follows:
program prog;
class myclass;
rand int int1;
constraint c1 {int1 dist {[1:2] := 1, [6:7] :/ 5, 9
:=10};}
endclass
myclass mc = new;
int stats [1:9];
int i;
initial begin
for(i = 1; i < 10; i++) stats[i] = 0;
repeat (1700)
if(mc.randomize()==1) begin
stats[mc.int1]++;
//$display("int1=%0d",mc.int1);
end
for(i = 1; i < 10; i++)
$display("stats[%d] = %d", i, stats[i]);
end
endprogram
constraint c1 in class myclass is now:

constraint c1 {int1 dist {[1:2] := 1, [6:7] :/ 5, 9
:=10};}
Constraint C1 now specifies the possible values of int1 are as follows:

1-77
A range of 1 to 2, each value in this range has a weight of 1. The

:= operator, when applied to a range, specifies applying the
weight to each value in the range.
A range of 6 to 7 with a weight of 5. The :/ operator specifies

applying the weight to the range as a whole.
9 with a weight of 10, which is twice as much as the weight for 6.
The repeat loop repeats 1700 times so that we have a large enough
sample. The following table shows the various values of int1 during
simulation:
value of int
number of times int has this value
1
2
3
4
5
6
7
8
9
105
98
0
0
0
248
251
0
998
fraction of the simulation time
1/17
1/17
2.5/17
2.5/17
10/17
Implications
An implication is an expression that must be true before VCS applies
the constraint.
program prog;
class Bus;
randc bit randcvar;
bit norandvar;

1-78
constraint c1 { (norandvar == 1) -> (randcvar ==

0);}
endclass
Bus bus = new;
initial
begin
bus.norandvar = 0;
#5 bus.norandvar = 1;
#5 $finish;
end
initial
repeat (15)
#1 if (bus.randomize() ==1)
$display("randcvar = %0b norandvar = %0b at %0t",
bus.randcvar, bus.norandvar,$time);
endprogram
In constraint c1, when variable norandvar has a 1 value (the

implication expression), VCS constrains random variable randcvar to
0. The -> token is the implication operator.
randcvar
randcvar
randcvar
randcvar
randcvar
randcvar
randcvar
randcvar
randcvar
randcvar
randcvar
randcvar
=
=
=
=
=
=
=
=
=
=
=
=
0
1
0
1
0
0
0
0
0
1
0
0
norandvar
norandvar
norandvar
norandvar
norandvar
norandvar
norandvar
norandvar
norandvar
norandvar
norandvar
norandvar
=
=
=
=
=
=
=
=
=
=
=
=
0
0
0
0
1
1
1
1
1
0
0
0
at
at
at
at
at
at
at
at
at
at
at
at
1
2
3
4
5
6
7
8
9
10
11
12

1-79
randcvar = 0 norandvar = 0 at 13
randcvar = 1 norandvar = 0 at 14
When variable norandvar is 0, random-cyclic variable randcvar is

either 0 or 1. When variable norandvar is 1, random-cyclic variable
randcvar is always 0.
if else Constraints
An alternative to an implication constraint is the if else constraint.
The if else constraint allows a constraint or constraint set on the
else condition.
program prog;
class Bus;
randc bit [2:0] randcvar;
bit norandvar;
constraint c1 { if (norandvar == 1)
randcvar == 0;
else
randcvar inside {[1:3]};}
endclass
Bus bus = new;
initial
begin
bus.norandvar = 0;
#5 $finish;
end
initial
repeat (15)
#1 if (bus.randomize() ==1)

1-80
$display("randcvar = %0d norandvar = %0b at %0t",

bus.randcvar, bus.norandvar,$time);
endprogram
constraint c1 { if (norandvar == 1)
randcvar == 0;
else
randcvar inside {[1:3]};}
Constraint c1 specifies that when variable norandvar has the 1 value,

VCS constrains random-cyclic variable randcvar to 0, and when
norandvar doesnt have the 1 value, in other words when it has the
0 value, VCS constrains random-cyclic variable randcvar to 1, 2, or 3.
randcvar
randcvar
randcvar
randcvar
randcvar
randcvar
randcvar
randcvar
randcvar
randcvar
randcvar
randcvar
randcvar
randcvar
=
=
=
=
=
=
=
=
=
=
=
=
=
=
1
2
3
3
0
0
0
0
0
1
2
3
3
2
norandvar
norandvar
norandvar
norandvar
norandvar
norandvar
norandvar
norandvar
norandvar
norandvar
norandvar
norandvar
norandvar
norandvar
=
=
=
=
=
=
=
=
=
=
=
=
=
=
0
0
0
0
1
1
1
1
1
0
0
0
0
0
at
at
at
at
at
at
at
at
at
at
at
at
at
at
1
2
3
4
5
6
7
8
9
10
11
12
13
14
When norandvar is 1, VCS always assigns 0 to randcvar.

1-81
Global Constraints
Constraint expressions involving random variables from other objects
are called global constraints.
program prog;
class myclass;
rand bit [7:0] randvar;
endclass
class myextclass extends myclass;
rand myclass left = new;
rand myclass right = new;
constraint c1 {left.randvar <= randvar;
right.randvar <= randvar;}
endclass
endprogram
In this example, class myextclass extends class myclass. In class

myextclass are two randomized objects (or instances) of class
myclass. They are named left and right and are randomized because
they are declared with the rand keyword.
Constraint C1 specifies that the version of randvar in the left object
must be less than or equal to randvar in myclass. Similarly the version
of randvar in the right object must be less than or equal to randvar in
myclass.

1-82
Constraint c1 is a global constraint because it refers to a variable in

myclass.
Variable Ordering
In an implication like the following:
constraint c1 { select -> data == 0;}
The select variable implies that data is 0, in this case, when select
is 1, data is 0.
The default behavior is for the constraint solver to solve for both
select and data at the same time. Sometimes you can assist the
constraint solver by telling it to solve for one variable first. You can
do this with another constraint block that specifies the order in which
the constraint solver solves the variables:
constraint c1 { select -> data == 0;}
constraint c2 ( solve select before data;}
Note:
Ordering also changes the distribution of values.
Static Constraint Blocks

The keyword static preceding the keyword constraint, makes a
constraint block static, and calls to the constraint_mode()
method occur to all instances of the constraint in all instances of the
constraints class.
static constraint c1 { data1 < data2;}

1-83
Randomize Methods
randomize()
Variables in an object are randomized using the randomize() class
method. Every class has a built-in randomize() method.
randomize()
Generates random values for active random variables, subject to
active constraints, in a specified instance of a class. This method
returns a 1 if VCS generates these random values, otherwise it
returns 0. Examples of the use of this method appear frequently
in previous code examples.
pre_randomize() and post_randomize()

Every class contains built-in pre_randomize() and post_randomize()
tasks, that are automatically called by randomize() before and after
it computes new random values.
You may override the pre_randomize() method in any class to perform
initialization and set pre-conditions before the object is randomized.
Also, you may override the post_randomize() method in any class to
perform cleanup, print diagnostics, and check post-conditions after
the object is randomized.
The following example involves a case where the pre_randomize()
method is used to instantiate and initialize the rand dynamic array,
payload[], before randomize() is called. The post_randomize()
method is used to display the size of the payload[] after randomize()
is called. program test;
class size;
rand bit [7:0] s; //random variable s

1-84
constraint con_size {
s > 0;
s < 50;
}
endclass
class Pkt;
integer header[7];
rand bit [7:0] payload[];
size sz;
function void pre_randomize();
/* Randomize the sz.s variable and instantiate
the dynamic array. */
integer res;
sz = new();
res = sz.randomize(); /* calling randomize()
on object sz of class size. Randomizes rand
variable s (constrained to >0 and <50 */
if(res==0)
else
begin
if((sz.s>0) && (sz.s<50))/* check for
size between 0 and 50*/
payload = new[sz.s];/* the new[] operator
allocates storage and initializes the
rand variable s in sz*/
else
$display("Failed to generate proper
size");
end
//end of outer else block
endfunction
function void post_randomize();
/* display size of payload dynamic array using
the size() built-in method*/
$display("payload.size = %d", payload.size);
endfunction
endclass
Pkt pkt;

1-85
integer success,i;
initial begin
pkt = new(); //instantiate pkt
for (int j = 0; j < 5; j++)
begin
success = pkt.randomize(); /*calling randomize
on object of class packet*/
if(success==0)
else
$display("Randomization Succeeded");
end // end of for loop
end // end of initial block
endprogram
The output of the program is:

payload.size =
12
Randomization Succeeded
payload.size =
17
payload.size =
8
payload.size =
40
payload.size =
10
Controlling Constraints
The predefined constraint_mode() method can be used either as a
task or a function. The constraint_mode() task controls whether a
constraint is active or inactive. The predefined constraint_mode()
function reports the current ON/OFF value for the specified variable.
All constraints are initially active.

1-86
Syntax:
task object[.constraint_identifier]::constraint_mode
(bit ON | OFF);
or
function int
object.constraint_identifier::constraint_mode();
In the following example, there are two constraint blocks defined in

a class, bus. The constraint_mode() method, when used as a task,
turns on and off the word_align and addr_range constraints.
constraint_mode() is also being used as a function to report the ON/
OFF value of the two constraints.
define N 5
program test;
class bus;
constraint word_align {addr[0] == 1'b0;}
constraint addr_range{addr >= 0 && addr <= 15;}
endclass
task generateRandomAddresses(integer how_many);
integer i;
for(i = 1; i <= how_many; i++) begin
bb.randomize();
$display("bb.addr = %d",bb.addr);
end
endtask
bus bb = new;
initial begin
// By default all constraints are ON
if (bb.word_align.constraint_mode() &&
bb.addr_range.constraint_mode())
begin
$display("======both constraints ON ======");
end

1-87
else
$display("Error with constraint_mode");
generateRandomAddresses(`N);
// turn OFF "word_align" constraint in "bb"
bb.word_align.constraint_mode(0);
$display("=========one constraint ON =======");
// turn OFF all constraints in "bb"
bb.constraint_mode(0);
$display("=========both constraints OFF =======");
// turn ON "addr_range" constraint in "bb"
bb.addr_range.constraint_mode(1);
$display("=========one constraint ON =======");
// turn ON all constraint in "bb"
bb.constraint_mode(1);
$display("=========both constraints ON =======");
end
endprogram
Output of the above program:
=========both constraints ON =======
bb.addr =
14
bb.addr =
2
bb.addr =
4
bb.addr =
8
bb.addr =
2
=========one constraint ON =======
bb.addr =
2
bb.addr =
9
bb.addr =
9
bb.addr =
9
bb.addr =
3
=========both constraints OFF =======
bb.addr = 44051

1-88
bb.addr = 36593
bb.addr = 19491
bb.addr = 6853
bb.addr = 48017
=========one constraint ON =======
bb.addr =
11
bb.addr =
8
bb.addr =
15
bb.addr =
7
bb.addr =
4
=========both constraints ON =======
bb.addr =
2
bb.addr =
10
bb.addr =
12
bb.addr =
10
bb.addr =
8
Disabling Random Variables

SystemVerilog provides the predefined rand_mode() method to
control whether a random variable is active or inactive. Initially, all
random variables are active.
The rand_mode() method can be used either as a task or a function.
The rand_mode() task specifies whether or not the random variable
is ON or OFF.
task object[.randvar_identifier]::rand_mode(bit ON |
OFF);
where ON is 1 and OFF is 0.

As a function, rand_mode() reports the current value (ON or OFF) of
the specified variable.
Syntax:

1-89
function int object.randvar_identifier::rand_mode();
rand_mode() returns -1 if the specified variable does not exist within

the class hierarchy or it exists but is not declared as rand or randc.
In the following example, there are two random variables defined in
a class, bus. The rand_mode() method, when used as a task, turns
on and off the random variables, addr and data. rand_mode() is
also being used as a function to report on the value (ON or OFF) of
the two random variables.
`define N 5
program test;
class bus;
rand bit [31:0] data;
constraint CC { data > 0; addr > 0; addr < 255; data
< 512;}
endclass
task generateRandomAddresses(integer how_many);
integer i;
for(i = 1; i <= how_many; i++) begin
bb.randomize();
$display("bb.addr = %d,, bb.data =
%d",bb.addr,bb.data);
end
endtask
bus bb = new;
initial begin
// By default all random variables are ON
if (bb.addr.rand_mode() && bb.data.rand_mode())
begin
$display("======both random variables ON
======");
end
else
$display("Error with rand_mode");
1-90
// turn OFF "data" random variable in "bb"
bb.data.rand_mode(0);
$display("======one random variable ON ======");
// turn OFF all random variables in "bb"
bb.rand_mode(0);
$display("======both random variables OFF======");
// turn ON "data" constraint in "bb"
bb.data.rand_mode(1);
$display("======one random variable ON========");
// turn ON all random variable in "bb"
bb.rand_mode(1);
$display("======both random variables ON ======");
end
endprogram
Output of the above program:

======both random variables ON =======
bb.addr =
88,, bb.data =
12
bb.addr =
49,, bb.data =
381
bb.addr =
185,, bb.data =
5
bb.addr =
212,, bb.data =
486
bb.addr =
49,, bb.data =
219
=======one random variable ON ========
bb.addr =
3,, bb.data =
219
bb.addr =
130,, bb.data =
219
bb.addr =
26,, bb.data =
219
bb.addr =
90,, bb.data =
219
bb.addr =
121,, bb.data =
219
======both random variables OFF=======
bb.addr =
121,, bb.data =
219

1-91
bb.addr =
121,, bb.data =
219
bb.addr =
121,, bb.data =
219
bb.addr =
121,, bb.data =
219
bb.addr =
121,, bb.data =
219
========one random variable ON========
bb.addr =
121,, bb.data =
456
bb.addr =
121,, bb.data =
511
bb.addr =
121,, bb.data =
67
bb.addr =
121,, bb.data =
316
bb.addr =
121,, bb.data =
405
======both random variables ON =======
bb.addr =
18,, bb.data =
491
bb.addr =
231,, bb.data =
113
bb.addr =
118,, bb.data =
230
bb.addr =
46,, bb.data =
96
bb.addr =
155,, bb.data =
298
In-line Constraints
You can use the randomize() method and the with construct to
declare in-line constraints outside of the class for the random
variables, at the point where you call the randomize() method.
program prog;
class Bus;
rand bit [2:0]
endclass
bitrand1;
Bus bus = new;

task inline (Bus bus);
int int1;

1-92
repeat (10)
begin
int1 = bus.randomize() with {bitrand1[1:0] ==
2'b00;};
if (int1 ==1) $display("bitrand1 = %0b",
bus.bitrand1);
end
endtask
initial
inline(bus);
endprogram
The $display system task displays the following

bitrand1
bitrand1
bitrand1
bitrand1
bitrand1
bitrand1
bitrand1
bitrand1
bitrand1
bitrand1
=
=
=
=
=
=
=
=
=
=
100
100
100
0
100
100
0
100
100
0
Random Number Generation

SystemVerilog includes a number of system functions to work with
random numbers. Some of these are:
$urandom()
The system function $urandom() generates pseudorandom numbers.
It returns an unsigned 32-bit number every time this function is called.
The syntax is:
1-93
$urandom( seed )
The seed is an optional argument that determines the sequence of

the random number that are generated. It could also be an
expression. The same sequence is always generated for the same
seed.
The following program explains the usage of $urandom().
program test();
bit [7:0] a,b,c,d;
initial begin
$display("Generation of random number with seed 3 :");
a = $urandom(3);
b = $urandom();
c = $urandom();
d = $urandom();
$display("a = %0d,b= %0d, c = %0d, d = %0d",a,b,c,d);
a = $urandom(4);
b = $urandom();
c = $urandom();
d = $urandom();
a = $urandom(3);
b = $urandom();
c = $urandom();
d = $urandom();
end
endprogram

Generation of random number with seed 3 :

1-94
a = 229,b=
Generation
a = 228,b=
Generation
a = 229,b=
175, c = 7, d = 99
of random number with seed 4 :
15, c = 254, d = 230
of random number with seed 3 :
175, c = 7, d = 99
$urandom_range()
The system function $urandom_range() generates random numbers
within a certain range. The syntax is:
$urandom_range( unsigned int maxval, unsigned int minval)
The function returns an unsigned integer between maxval and minval

(inclusive of them). If one of the arguments is omitted, then the
function will return an unsigned integer between the argument
specified and zero.
The following program explains the usage of $urandom_range().
program test();
logic [3:0] a,a1;
bit [2:0] b;
initial begin
a = 10; a1 = 3;
$display("Generating random numbers with urandom_range
with expressions in range");
//generating value of b between 7 and 3
b = $urandom_range((a-a1), a1); //expressions as
args to urandom_range
$display("value of b generated with range %0d and
%0d is %0d",a-a1,a1,b);
//generating value of b between 3 and 7
b = $urandom_range(a1,(a-a1));
%0d is %0d",a1,a-a1,b);

1-95
$srandom(2);
// changing the seed for thread
//generating value of b between 0 and 7 (omitting

one of the range value)
b = $urandom_range(a-a1);
%0d is %0d",0,a-a1,b);
end
endprogram

Generating random numbers with urandom_range with
expressions in range
value of b generated with range 7 and 3 is 6
$srandom()
You can use the system function $srandom() to manually set the seed
for random number generation. The syntax is:
$srandom(seed)
Providing the same seed ensures that the same set of random values
are generated by the random number generator.
The following program demonstrates that the same random numbers
are generated for the same seed.
program test;
logic [3:0]
a, b;
initial begin
$display("Setting the seed as 2 through srandom");
$srandom(2);

1-96
repeat (2)
begin
a = $urandom();
b = $urandom();
$display("a = %0d, b = %0d", a, b);
end
// end of repeat block
$display("Changing the seed as 1 through srandom");
$srandom(1);
repeat (2)
begin
a = $urandom();
b = $urandom();
$display("a = %0d, b = %0d", a, b);
end
$display("Setting the seed once again to 2 through
srandom");
$srandom(2);
repeat (2)
begin
a = $urandom();
b = $urandom();
$display("a = %0d, b = %0d", a, b);
end
end
// end of initial block
endprogram

Setting the seed as 2 through srandom
a = 8, b = 3
a = 14, b = 3
Changing the seed as 1 through srandom
a = 12, b = 13
a = 15, b = 9
Setting the seed once again to 2 through srandom
a = 8, b = 3
a = 14, b = 3

1-97
Seeding for Randomization

The srandom() method initializes the current Random Number
Generator (RNG) of objects or threads using the value of the seed.
The following example involves using srandom() to initialize the RNG
for an object using a real variable as the seed.
program test;
class A;
rand logic [7:0] x;
endclass
real r = 1;
A a;
int d1,d2,d3,d4;
initial begin
a = new;
a.srandom(r);//the r is the seed for RNG of a
d1 = a.randomize();
if(d1 == 1) //if randomize() is successful
d2 = a.x; //assign value of the variable x in a to d2
a.srandom(r+1);
d1 = a.randomize();
if(d1 == 1)
d3 = a.x;
a.srandom(r);
d1 = a.randomize();
if(d1 == 1)
d4 = a.x;
if((d2 == d4) && (d2 != d3))
$display("test passed");
else
$display("test failed");
end
endprogram

1-98

test passed
randcase Statements
The randcase construct specifies a block of statements with
corresponding weights attached to them. Weights can be any
expression. When a randcase statement occurs, one of the statement
with weights is executed at random. If the weight is an expression,
then it is evaluated each time the randcase statement is executed. If
the weight is zero, then that branch is not executed. The randcase
statements can be nested.
program test;
int a= 2;
logic [3:0] b;
//variables to keep count of how many time a particular case
//is executed in randcase
int count_2,count_c;
function f1();
randcase
a+3
10
: count_2++; // simple add expression as weight

: count_c++; // constant used as weight
endcase
endfunction
initial begin
repeat (15)
f1();
$display("Number of times a+3 called is %0d", count_2);

1-99
$display("Number of times constant called is %0d",

count_c);
end
endprogram

Number of times a+3 called is 5
Number of times constant called is 10
This example defines a randcase block of two statements with

different weights (one as an expression and another as an integer).
The probability that any single statement will be selected for execution
is determined by the formula weight/total_weight. Therefore, in this
example, the probability of the first statement being executed is 0.33,
and the second statement is 0.66.
Random Sequence Generation

Note:
Random sequence generation is an LCA feature.
SystemVerilogs sequence generation allows you to specify the
syntax of valid sequences using BNF-like notation. Random
sequences are ideal for generating streams of instructions for which
it is easier to specify the syntax of valid streams than the constraints
on specific values.
This section includes the following:
RSG Overview
Production Declaration
Production Controls

1-100
RSG Overview
The syntax for programming languages is often expressed in Backus
Naur Form (BNF) or some derivative thereof. Parser generators use
this BNF to define the language to be parsed. However, it is possible
to reverse the process. Instead of using the BNF to check that
existing code fits the correct syntax, the BNF can be used to
assemble code fragments into syntactically correct code. The result
is the generation of pseudo-random sequences of text, ranging from
sequences of characters to syntactically and semantically correct
assembly language programs.
SystemVerilogs implementation of a stream generator, the RSG, is
defined by a set of rules and productions encapsulated in a
randsequence block.
The general syntax to define a RSG code block is:
randsequence ([production_identifier])
production {production}
endsequence
Note:Nesting of randsequence blocks is not supported

When the randsequence block is executed, random production
definitions are selected and streamed together to generate a random
stream. How these definitions are generated is determined by the
base elements included in the block.
Any RSG code block is comprised of production definitions. Native
Testbench also provides weights, production controls, and
production system functions to enhance production usage. Each of
these RSG components is discussed in detail in subsequent
sections.

1-101
Production Declaration
A language is defined in BNF by a set of production definitions. The
syntax to define a production is:
[function_datatype] production_identifier
[(tf_port_list)]:rs_rule{|rs_rule};
production_identifier
Is the reference name of the production definition.
tf_port_list
task/function port list.
rs_rule
The syntax for rs_rule is:
rs_production_list [:= weight_specification
[rs_code_block]]
rs_production_list
The syntax for rs_production_list is:
rs_prod{rs_prod} | rand join [(expression)]
production_item production_item {production_item}
weight_specification
The syntax for weight_specification is:
integral_number | ps_identifier | (expression)
(see also Weights for Randomization on page 1-105)

rs_code_block
The syntax for rs_code_block is:

1-102
{{data_declaration}{statement_or_null}}
The following table provides the syntax for the non-terminals within
rs_production_list, weight_specification, and rs_code_block, and the
non-terminals therein.
non-terminal
Syntax
rs_prod
production_item |rs_code_block | rs_if_else |rs_repeat |

rs_case
rs_code_block
rs_if_else
{{data_declaration}}{statement_or_null}}
if(expression) product_item [else production_item]
see also if-else Statements on page 1-106
repeat(expression) production_item
see also repeat Loops on page 1-108
case(expression) rs_case_item {rs_case_item} endcase
see also case Statements on page 1-107
expression{,expression} : production_item | default [:]
production_item;
see also case Statements on page 1-107
production_identifier[(list_of_arguments)]
rs_repeat
rs_case
re_case_item
production_item
A randsequence block is made up of one or more productions,

yielding a production list.
Productions are made up of terminals and non-terminals, as seen in
the above syntax description. A terminal is an indivisible code
element. It needs no further definition beyond the code block
associated with it. A non-terminal is an intermediate variable defined
in terms of other terminals and non-terminals. If a production item is
defined using non-terminals, those non-terminals must then be
defined in terms of other non-terminals and terminals using the
production definition construct. Ultimately, every non-terminal has to
be broken down into its base terminal elements.

1-103
Multiple production items specified in a production list can be

separated by white space or by the or operator (|). Production items
separated by white space indicate that the items are streamed
together in sequence. Production items separated by the | operator
force a random choice, which is made every time the production is
called.
The following is an example of a program including a randsequence
block.
program p;
initial begin
randsequence()
main : repeat (10) TOP;
TOP: RJ {$display("");};
RJ: rand join (1.0) S1 S2 S3;
S1 : A B;
S2 : C D;
S3 : E F G;
A : {$write ("A");};
B : {$write ("B");};
C : {$write ("C");};
D : {$write ("D");};
E : {$write ("E");};
F : {$write ("F");};
G : {$write ("G");};
endsequence
end
endprogram
Production Controls
SystemVerilog provides several mechanisms that can be used to
control productions: weights for randomization, if-else statements,
case statements, and repeat loops.

1-104
This section includes:
Weights for Randomization
if-else Statements
case Statements
repeat Loops
break Statement
Weights for Randomization

Weights can be assigned to production items to change the
probability that they are selected when the randsequence block is
called.
Syntax
rs_production_list[:= weight_specification [rs_code_block] ]
weight_specification
The syntax for weight_specification is:
integral_number | ps_identifier | (expression)
The expression can be any valid SystemVerilog expression that

returns a non-negative integer. Function calls can be made within
the expression, but the expression must return a numeric value,
or else a simulation error is generated.
Assigning weights to a production item affects the probability that it
is selected when the randsequence block is called. Weight should
only be assigned when a selection is forced with the | operator. The

1-105
weight for each production item is evaluated when its production

definition is executed. This allows you to change the weights
dynamically throughout a sequence of calls to the same production.
if-else Statements
A production can be conditionally referenced using an if-else
statement.
The syntax to declare an if-else statement within a production
definition is:
if(expression) product_item [else production_item]
expression
Can be any valid SystemVerilog expression that evaluates to a
boolean value.
If the conditional evaluates to true, the first production item is selected.
If it evaluates to false, the second production item is selected. The
else statement can be omitted. If it is omitted, a false evaluation
ignores the entire if statement. The following is an example of a
production definition with an if-else statement.
assembly_block : if (nestingLevel > 10) seq_block else
any_block;
This example defines the production assembly_block. If the

variable nestingLevel is greater than 10, the production item
seq_block is selected. If nestingLevel is less than or equal to
10, any_block is selected.

1-106
case Statements
A general selection mechanism is provided by the case statement.
The syntax to declare a case statement within a production definition
is:
case(expression)
rs_case_item {rs_case_item}
endcase
expression
Is evaluated. The value of the expression is successively
checked, in the order listed, against each rs_case_item. The
production corresponding to the first matching case found is
executed, and control is passed to the production definition
whose name is in the case item with the matching case
expression. If other matches exist, they are not executed. If no
case item value matches the evaluated primary expression and
there is no default case, nothing happens.
rs_case_item
Can be any valid SystemVerilog expression or comma-separated
list of expressions. Expressions separated by commas allow
multiple expressions to share the same statement block. The
syntax is:
expression{,expression}: production_item | default [:]
production_item;
A case statement must have at least one case item aside from the
default case, which is optional. The default case must be the last
item in a case statement. The following is an example of a production
definition using a case statement:

1-107
repeat Loops
The repeat loop is used to loop over a production a specified number
of times.
The syntax to declare a repeat loop within a production definition is:
repeat(express) production_item
expression
Can be any valid SystemVerilog expression that evaluates to a
non-negative integer, including functions that return a numeric
value.
The expression is evaluated when the production definition is
executed. The value specifies how many times the corresponding
production item is executed. The following is an example of a
production definition using a repeat loop.
randsequence()
...
seq_block : repeat (random() ) integer_instruction;
...
endsequence
This example defines the production seq_block, which repeats the

production item integer_instruction a random number of
times, depending on the value returned by the random() system
function.
break Statement
The break statement is used to terminate a randsequence block.

1-108
Syntax
break;
A break statement can be executed from within an rs_code_block

within a production definition. When a break statement is executed,
the randsequence block terminates immediately and control is
passed to the first line of code after the randsequence block. The
following is an example of a production definition using a break
statement.
return Statement
The return statement is used to interrupt the execution of the current
production. After the current production is aborted, the execution
continues on the next item in the production from which the call is
made.
Syntax
return;
The return statement passes control to the next production item in

the production from which the call is made without executing any
code in between. The following is an example of a production
definition using a return statement:

1-109
Aspect Oriented Extensions

The Aspect oriented extensions is a Limited Customer availability
(LCA) feature in NTB(SV) and requires a separate license. Please
contact your Synopsys AC for a license key.
Aspect-Oriented Programming (AOP) methodology complements
the OOP methodology using a construct called aspect or an
aspect-oriented extension (AOE) that can affect the behavior of a
class or multiple classes. In AOP methodology, the terms aspect
and aspect-oriented extension are used interchangeably.
Aspect oriented extensions in SV allow testbench engineers to
design testcase more efficiently, using fewer lines of code.
AOP addresses issues or concerns that prove difficult to solve when
using Object-Oriented Programming (OOP) to write
constrained-random testbenches.
Such concerns include:
1. Context-sensitive behavior.
2. Unanticipated extensions.
3. Multi-object protocols.
In AOP these issues are termed cross-cutting concerns as they cut
across the typical divisions of responsibility in a given programming
model.
In OOP, the natural unit of modularity is the class. Some of the cross
cutting concerns, such as "Multi-object protocols" , cut across
multiple classes and are not easy to solve using the OOP
1-110
methodology. AOP is a way of modularizing such cross-cutting

concerns. AOP extends the functionality of existing OOP derived
classes and uses the notion of aspect as a natural unit of modularity.
Behavior that affects multiple classes can be encapsulated in
aspects to form reusable modules. As potential benefits of AOP are
achieved better in a language where an aspect unit can affect
behavior of multiple classes and therefore can modularize the
behavior that affects multiple classes, AOP ability in SV language is
currently limited in the sense that an aspect extension affects the
behavior of only a single class. It is useful nonetheless, enabling test
engineers to design code that efficiently addresses concerns
"Context-sensitive behavior" and "Unanticipated extensions".
AOP is used in conjunction with object-oriented programming. By
compartmentalizing code containing aspects, cross-cutting concerns
become easy to deal with. Aspects of a system can be changed,
inserted or removed at compile time, and become reusable.
It is important to understand that the overall verification environment
should be assembled using OOP to retain encapsulation and
protection. NTB's Aspect-Oriented Extensions should be used only
for constrained-random test specifications with the aim of minimizing
code.
SVs Aspect-Oriented Extensions should not be used to:
Code base classes and class libraries
Debug, trace or monitor unknown or inaccessible classes
Insert new code to fix an existing problem
For information on the creation and refinement of verification

testbenches, see the Reference Verification Methodology User
Guide.

1-111
Aspect-Oriented Extensions in SV
In SV, AOP is supported by a set of directives and constructs that
need to be processed before compilation. Therefore, an SV program
with these Aspect oriented directives and constructs would need to
be processed as per the definition of these directives and constructs
in SV to generate an equivalent SV program that is devoid of aspect
extensions, and consists of traditional SV. Conceptually, AOP is
implemented as pre-compilation expansion of code.
This chapter explains how AOE in SV are directives to SV compiler
as to how the pre-compilation expansion of code needs to be
performed.
In SV, an aspect extension for a class can be defined in any scope
where the class is visible, except for within another aspect extension.
That is, aspect extensions can not be nested.
An aspect oriented extension in SV is defined using a new top-level
extends directive. Terms aspect and extends directive have been
used interchangeably throughout the document. Normally, a class is
extended through derivation, but an extends directive defines
modifications to a pre-existing class by doing in-place extension of
the class. in-place extension modifies the definition of a class by
adding new member fields and member methods, and changing the
behavior of earlier defined class methods, without creating any new
subclasse(s). That is, SVs Aspect-Oriented Extensions change the
original class definition without creating subclasses. These changes
affect all instances of the original class that was extended by AOEs.

1-112
An extends directive for a class defines a scope in SV language.

Within this scope exist the items that modify the class definition.
These items within an extends directive for a class can be divided
into the following three categories.
Introduction
Declaration of a new property, or the definition of a new method,
a new constraint, or a new coverage group within the extends
directive scope adds (or introduces) the new symbol into the
original class definition as a new member. Such declaration/
definition is called an introduction.
Advice
An advice is a construct to specify code that affects the behavior
of a member method of the class by weaving the specified code
into the member method definition. This is explained in more
detail later. The advice item is said to be an advice to the affected
member method.
Hide list:
Some items within an extends directive, such as a virtual method
introduction, or an advice to virtual method may not be
permissible within the extends directive scope depending upon
the hide permissions at the place where the item is defined. A
hide list is a construct whose placement and arguments within
the extends directive scope controls the hide permissions. There
could be multiple hide lists within an extends directive.

1-113
Processing of AOE as a Precompilation Expansion

As a precompilation expansion, AOE code is processed by VCS to
modify the class definitions that it extends as per the directives in
AOE.
A symbol is a valid identifier in a program. Classes and class
methods are symbols that can be affected by AOE. AOE code is
processed which involves adding of introductions and weaving of
advices in and around the affected symbols. Weaving is performed
before actual compilation (and thereby before symbol resolution),
therefore, under certain conditions, introduced symbols with the
same identifier as some already visible symbol, can hide the already
visible symbols. This is explained in more detail in Section , hide_list
details, on page 1-139. The preprocessed input program, now
devoid of AOE, is then compiled.

1-114
Syntax:
extends_directive ::=
extends extends_identifier
(class_identifier)[dominate_list];
extends_item_list
endextends
dominate_list ::=
dominates(extends_identifier
{,extends_identifier});
extends_item_list ::=
extends_item {extends_item}
extends_item ::=
class_item
| advice
| hide_list
class_item ::=
class_property
| class_method
| class_constraint
| class_coverage
| enum_defn
advice ::= placement procedure
placement ::=
before
| after
| around
procedure ::=
| optional_method_specifiers task
task_identifier(list_of_task_proto_formals);
| optional_method_specifiers function
function_type
function_identifier(list_of_function_proto_formals)
endfunction
advice_code ::= [stmt] {stmt}

1-115
stmt ::= statement

| proceed ;
hide_list ::=
hide([hide_item {,hide_item}]);
hide_item ::=
// Empty
| virtuals
| rules
The symbols in boldface are keywords and their syntax are as

follows:
extends_identifier
Name of the aspect extension.
class_identifier
Name of the class that is being extended by the extends directive.
dominate_list
Specifies extensions that are dominated by the current directive.
Domination defines the precedence between code woven by
multiple extensions into the same scope. One extension can
dominate one or more of the other extensions. In such a case, you
must use a comma-separated list of extends identifiers.
dominates(extends_identifier
{,extends_identifier});
A dominated extension is assigned lower precedence than an

extension that dominates it. Precedence among aspects extensions
of a class determines the order in which introductions defined in the

1-116
aspects are added to the class definition. It also determines the order
in which advices defined in the aspects are woven into the class
method definitions thus affecting the behavior of a class method.
Rules for determination of precedence among aspects are explained
later in Precedence on page 1-125.
class_property
Refers to an item that can be parsed as a property of a class.
class_method
Refers to an item that can be parsed as a class method.
class_constraint
Refers to an item that can be parsed as a class constraint.
class_coverage
Refers to an item that can be parsed as a coverage_group in a
class.
advice_code
Specifies to a block of statements.
statement
Is an SV statement.
procedure_prototype
A full prototype of the target procedure. Prototypes enable the advice
code to reference the formal arguments of the procedure.

1-117
opt_method_specifiers
Refers to a combination of protection level specifier (local, or
protected), virtual method specifier (virtual), and the static method
specifier (static) for the method.
task_identifier
Name of the task.
function_identifier
Name of the function.
function_type
Data type of the return value of the function.
list_of_task_proto_formals
List of formal arguments to the task.
list_of_function_proto_formals
List of formal arguments to the function.
placement
Specifies the position at which the advice code within the advice is
woven into the target method definition. Target method is either the
class method, or some other new method that was created as part of
the process of weaving, which is a part of pre-compilation expansion
of code. The overall details of the process of weaving are explained
in Pre-compilation Expansion details. The placement element could
1-118
be any of the keywords, before, after, or around, and the advices

with these placement elements are referred to as before advice, after
advice and around advice, respectively.
proceed statement
The proceed keyword specifies an SV statement that can be used
within advice code. A proceed statement is valid only within an
around block and only a single proceed statement can be used
inside the advice code block of an around advice. It cannot be used
in a before advice block or an after advice block. The proceed
statement is optional.
hide_list
Specifies the permission(s) for introductions to hide a symbol, and/
or permission(s) for advices to modify local and protected methods.
It is explained in detail in Section , hide_list details, on page 1-139.
Weaving advice into the target method

The target method is either the class method, or some other new
method that was created as part of the process of weaving.
Weaving of all advices in the input program comprises several
steps of weaving of an advice into the target method. Weaving of an
advice into its target method involves the following.
A new method is created with the same method prototype as the
target method and with the advice code block as the code block of
the new method. This method is referred to as the advice method.

1-119
The following table shows the rest of the steps involved in weaving
of the advice for each type of placement element (before, after, and
around).
Table 1-2
Placement Elements
Element
Description
before
Inserts a new method-call statement

that calls an advice method. The
statement is inserted as the first
statement to be executed before any
other statements.
after
Creates a new method A with the target

method prototype, with its first
statement being a call to the target
method. Second statement with A is a
new method call statement that calls
the advice method. All the instances
in the input program where the target
method is called are replaced by newly
created method calls to A. A is
replaced as the new target method.
around
All the instances in the input program

where the target method is called are
replaced by newly created method calls
to the advice method.
Within an extends directive, you can specify only one advice can be
specified for a given placement element and a given method. For
example, an extends directive may contain a maximum of one
before, one after, and one around advice each for a class method
Packet::foo of a class Packet, but it may not contain two before
advices for the Packet::foo.
Target method:
task myTask();
$display("Executing original code\n");
endtask

1-120
Advice:
before task myTask ();
$display("Before in aoe1\n");
endtask
Weaving of the advice in the target method yields the following.

task myTask();
mytask_before();
endtask
task mytask_before ();
endtask
Note that the SV language does not impose any restrictions on the
names of newly created methods during pre-compilation expansion,
such as mytask_before . Compilers can adopt any naming
conventions such methods that are created as a result of the
weaving process.
Example 1-1
Target method:
task myTask();
endtask
Advice:
after task myTask ();
endtask

1-121

task myTask_newTarget();
myTask();
myTask_after();
endtask
task myTask();
endtask
task myTask_after ();
$display("After in aoe1\n");
endtask
As a result of weaving, all the method calls to myTask() in the input

program code are replaced by method calls to myTask_newTarget().
Also, myTask_newTarget replaces myTask as the target method for
myTask().
Target method:
task myTask();
endtask
Advice:
around task myTask ();
$display("Around in aoe1\n");
endtask

1-122

task myTask_around();
endtask
task myTask();
endtask

program code are replaced by method calls to myTask_around().
Also, myTask_around() replaces myTask() as the target method for
myTask().
During weaving of an around advice that contains a proceed
statement, the proceed statement is replaced by a method call to the
target method.
Example 1-2
Target method:
task myTask();
endtask
Advice:
around task myTask ();
proceed;
endtask

1-123
Weaving of the advice in the target method yields:

task myTask_around();
myTask();
endtask
task myTask();
endtask

program code are replaced by method calls to myTask_around().
The proceed statement in the around code is replaced with a call to
the target method myTask(). Also, myTask_around replaces myTask
as the target method for myTask().
Pre-compilation Expansion details

Pre-compilation expansion of a program containing AOE code is
done in the following order:
1. Preprocessing and parsing of all input code.
2. Identification of the symbols, such as methods and classes
affected by extensions.
3. The precedence order of aspect extensions (and thereby
introductions and advices) for each class is established.
4. Addition of introductions to their respective classes as class
members in their order of precedence. Whether an introduction
can or can not override or hide a symbol with the same name that
is visible in the scope of the original class definition, is dependent
on certain rules related to the hide_list parameter. For a detailed
explanation, see hide_list details on page 1-139.

1-124
5. Weaving of all advices in the input program are weaved into their
respective class methods as per the precedence order.
These steps are described in more detail in the following sections.
Precedence
Precedence is specified through the dominate_list (see
dominate_list on page 1-116) There is no default precedence
across files; if precedence is not specified, the tool is free to weave
code in any order. Within a file, dominance established by
dominate_lists always overrides precedence established by the
order in which extends directives are coded. Only when the
precedence is not established after analyzing the dominate lists of
directives, is the order of coding used to define the order of
precedence.
Within an extends directive there is an inherent precedence between
advices. Advices that are defined later in the directive have higher
precedence that those defined earlier.
Precedence does not change the order between adding of
introductions and weaving of advices in the code. Precedence
defines the order in which introductions to a class are added to the
class, and the order in which advices to methods belonging to a
class are woven into the class methods.
Example 1-3
// Beginnning of file Input.vr
program top ;
initial begin
packet p;
p = new();
p.send();
end
endprogram

1-125
class packet;
...
// Other member fields/methods
...
task send();
$display("Sending data\n");
endtask
endclass
extends aspect_1(packet) dominates (aspect_2, aspect_3);
after task send();
// Advice 1
$display("Aspect_1: send advice after\n");
endtask
endextends
extends aspect_2(packet);
after task send() ;
// Advice 2
endtask
endextends
around task send();
$display("Aspect_3:
proceed;
$display("Aspect_3:
endtask
before task send();
$display("Aspect_3:
endtask
endextends
// Advice 3
Begin send advice around\n");
End send advice around\n");
// Advice 4
send advice before\n");
// End of file Input.vr
In Example 1-3, multiple aspect extensions for a class named packet

are defined in a single SV file. As specified in the dominating list of
aspect_1, aspect_1 dominates both aspect_2 and aspect_3. As per
the dominating lists of the aspect extensions, there is no precedence
order established between aspect_2 and aspect_3, and since

1-126
aspect_3 is coded later in Input.vr than aspect_2, aspect_3 has

higher precedence than aspect_2. Therefore, the precedence of
these aspect extensions in the decreasing order of precedence is:
{aspect_1, aspect_3, aspect_2}
This implies that the advice(s) within aspect_2 have lower
precedence than advice(s) within aspect_3, and advice(s) within
aspect_3 have lower precedence than advice(s) within aspect_1.
Therefore, advice 2 has lower precedence than advice 3 and advice
4. Both advice 3 and advice 4 have lower precedence than advice 1.
Between advice 3 and advice 4, advice 4 has higher precedence as
it is defined later than advice 3. That puts the order of advices in the
increasing order of precedence as:
{2, 3, 4, 1}.
Adding of Introductions
Target scope refers to the scope of the class definition that is being
extended by an aspect. Introductions in an aspect are appended as
new members at the end of its target scope. If an extension A has
precedence over extension B, the symbols introduced by A are
appended first.
Within an aspect extension, symbols introduced by the extension are
appended to the target scope in the order they appear in the
extension.
There are certain rules according to which an introduction symbol
with the same identifier name as a symbol that is visible in the target
scope, may or may not be allowed as an introduction. These rules
are discussed later in the chapter.

1-127
Weaving of advices
An input program may contain several aspect extensions for any or
each of the different class definitions in the program. Weaving of
advices needs to be carried out for each class method for which an
advice is specified.
Weaving of advices in the input program consists of weaving of
advices into each such class method. Weaving of advices into a
class method A is unrelated to weaving of advices into a different
class method B, and therefore weaving of advices to various class
methods can be done in any ordering of the class methods.
For weaving of advices into a class method, all the advices
pertaining to the class method are identified and ordered in the order
of increasing precedence in a list L. This is the order in which these
advices are woven into the class method thereby affecting the
run-time behavior of the method. The advices in list L are woven in
the class method as per the following steps. Target method is
initialized to the class method.
a. Advice A that has the lowest precedence in L is woven into the
target method as explained earlier. Note that the target method
may either be the class method or some other method newly
created during the weaving process.
b. Advice A is deleted from list L.
c. The next advice on list L is woven into the target method. This
continues until all the advices on the list have been woven into
list L.
It would become apparent from the example provided later in this
section how the order of precedence of advices for a class method
affects how advices are woven into their target method and thus the
relative order of execution of advice code blocks. Before and after
advices within an aspect to a target method are unrelated to each
1-128
other in the sense that their relative precedence to each other does
not affect their relative order of execution when a method call to the
target method is executed. The before advices code block executes
before the target method code block, and the after advice code block
executes after the target method code block. When an around
advice is used with a before or after advice in the same aspect, code
weaving depends upon their precedence with respect to each other.
Depending upon the precedence of the around advice with respect
to other advices in the aspect for the same target method, the around
advice either may be woven before all or some of the other advices,
or may be woven after all of the other advices.
As an example, weaving of advices 1, 2, 3, 4 specified in aspect
extensions in Example 1-3 leads to the expansion of code in the
following manner. Advices are woven in the order of increasing
precedence {2, 3, 4, 1} as explained earlier.
Example 1-4
program top ;
packet p;
p = new();
p.send_Created_a();
endprogram
class packet;
...
...
task send();
p$display("Sending data\n);
endtask
task send_Created_a();
send();
send_after_Created_b();
endtask
task send_after_Created_b();

1-129

endtask
endclass
after task send();
// Advice 1
endtask
endextends
around task send();
// Advice 3
$display("Aspect_3: Begin send advice around\n");
proceed;
$display("Aspect_3: End send advice around\n");
endtask
before task send();
// Advice 4
$display("Aspect_3: send advice before\n");
endtask
endextends
// End of file Input.sv
This Example 1-4 shows what the input program looks like after
weaving advice 2 into the class method. Two new methods
send_Created_a and send_after_Created_b are created in the
process and the instances of method call to the target method
packet::send are modified, such that the code block from advice 2
executes after the code block of the target method packet::send.
Example 1-5
program top;
packet p;
p = new();
p.send_around_Created_c();
endprogram
class packet;
...

1-130
...
task send();
$display("Sending data\n);
endtask
send();
endtask
endtask
task send_around_Created_c();
send_Created_a();
endtask
endclass
after task send();
// Advice 1
endtask
endextends
before task send();
// Advice 4
endtask
endextends
weaving advice 3 into the class method. A new method
send_around_Created_c is created in this step and the instances of
method call to the target method packet::send_Created_a are
modified, such that the code block from advice 3 executes around
the code block of method packet::send_Created_a. Also note that
the proceed statement from the advice code block is replaced by a

1-131
call to send_Created_a. At the end of this step,

send_around_Created_c becomes the new target method for
weaving of further advices to packet::send.
Example 1-6
program top;
packet p;
p = new();
p.send_around_Created_c();
endprogram
class packet;
...
...
task send();
endtask
send();
endtask
endtask
send_before_Created_d();
send_after_Created_a();
endtask
task send_before_Created_d();
endtask
endclass
after task send();
// Advice 1

1-132
endtask
endextends
weaving advice 4 into the class method. A new method
send_before_Created_d is created in this step and a call to it is
added as the first statement in the target method
packet::send_around_Created_c. Also note that the outcome would
have been different if advice 4 (before advice) was defined earlier
than advice 3 (around advice) within aspect_3, as that would have
affected the order of precedence of advice 3 and advice. In that
scenario the advice 3 (around advice) would have weaved around
the code block from advice 4 (before advice), unlike the current
outcome.
Example 1-7
program top;
packet p;
p = new();
p.send_Created_f();
endprogram
class packet;
...
...
task send();
endtask
send();
send_Created_b();
endtask

1-133

endtask
send_before_Created_d();
send_after_Created_a();
endtask
task send_before_Created_d();
endtask
task send_after_Created_e();
endtask
task send_Created_f();
send_around_Created_c();
send_after_Created_e()
endtask
endclass
This Example 1-7 shows the input program after weaving of all four
advices {2, 3, 4, 1}. New methods send_after_Created_e and
send_Created_f are created in the last step of weaving and the
instances of method call to packet::send_around_Created_c were
replaced by method call to packet::send_Created_f.
When executed, output of this program is:
Aspect_3: send advice before
Aspect_3: Begin send advice around
Sending data
Aspect_2: send advice after
Aspect_3: End send advice around
Aspect_1: send advice after
Examples of code containing around advice

1-134
// Begin file input.vr

program top;
foo f;
f = new();
f.myTask();
endprogram
class foo;
int i;
task myTask();
endtask
endclass
extends aoe1 (foo) dominates(aoe2);
around task myTask();
proceed;
$display("around in aoe1\n");
endtask
endextends
extends aoe2 (foo);
proceed;
$display("around in aoe2\n");
endtask
endextends
// End file input.sv
When aoe1 dominates aoe2, as in func1, the output when the

program is executed is:
Executing original code
around in aoe2
around in aoe1
Example 1-8
// Begin file input.vr
program top;
foo f;

1-135
f = new();
f.myTask();
endprogram
class foo;
int i;
task myTask();
printf("Executing original code\n");
endtask
endclass
extends aoe1 (foo);
proceed;
printf("around in aoe1\n");
endtask
endextends
extends aoe2 (foo) dominates (aoe1);
proceed;
printf("around in aoe2\n");
endtask
endextends
// End file input.sv
On the other hand, when aoe2 dominates aoe1 as in this Example

1-8, the output is:
Executing original code
around in aoe1
around in aoe2
Symbol resolution details:

As introductions and advices defined within extends directives are
pre-processed as a pre-compilation expansion of the input program,
the pre-processing occurs earlier than final symbol resolution stage
within a compiler. Therefore, it possible for AOE code to reference
symbols that were added to the original class definition using AOEs.

1-136
Because advices are woven after introductions have been added to

the class definitions, advices can be specified for introduced
member methods and can reference introduced symbols.
An advice to a class method can access and modify the member
fields and methods of the class object to which the class method
belongs. An advice to a class function can access and modify the
variable that stores the return value of the function.
Furthermore, members of the original class definition can also
reference symbols introduced by aspect extensions using the extern
declarations (?). Extern declarations can also be used to reference
symbols introduced by an aspect extension to a class in some other
aspect extension code that extends the same class.
An introduction that has the same identifier as a symbol that is
already defined in the target scope as a member property or member
method is not permitted.
Examples:
Example 1-9
// Begin file example.vr
program top;
packet p;
p = new();
p.foo();
endprogram
class packet;
task foo(integer x); //Formal argument is "x"
$display("x=%0d\n", x);
endtask
endclass
extends myaspect(packet);
// Make packet::foo always print: "x=99"

1-137
before task foo(integer x);

x = 99;
//force every call to foo to use x=99
endtask
endextends
// End file example.sv
The extends directive in Example 1-9 sets the x parameter inside the
foo() task to 99 before the original code inside of foo() executes.
Actual argument to foo() is not affected, and is not set unless
passed-by-reference using ref.
Example 1-10
// Begin file example.sv
program top ;
packet p;
p = new();
$display(Output is: %d\n, p.bar());
endprogram
class packet ;
function integer bar();
bar = 5;
$display(Point 1: Value = %d\n, bar);
endfunction
endclass
after function integer bar();
bar = bar + 1;
// Stmt A
endfunction
endextends
An advice to a function can access and modify the variable that

stores the return value of the function as shown in Example 1-10, in
this example a call to packet::bar returns 6 instead of 5 as the final
return value is set by the Stmt A in the advice code block.

1-138
When executed, the output of the program code is:

Point 1: Value = 5
Point 2: Value = 5
Point 3: Value = 6
Output is: 6
hide_list details
The hide_list item of an extends_directive specifies the
permission(s) for introductions to hide symbols, and/or advice to
modify local and protected methods. By default, an introduction does
not have permission to hide symbols that were previously visible in
the target scope, and it is an error for an extension to introduce a
symbol that hides a global or super-class symbol.
The hide_list option contains a comma-separated list of options such
as:
The virtuals option permits the hiding (that is, overriding) of

virtual methods defined in a super class. Virtual methods are the
only symbols that may be hidden; global, and file-local tasks and
functions may not be hidden. Furthermore, all introduced
methods must have the same virtual modifier as their overridden
super-class and overriding sub-class methods.
The rules option permits the extension to suspend access rules

and to specify advice that changes protected and local virtual
methods; by default, extensions cannot change protected and
local virtual methods.
An empty option list removes all permissions, that is, it resets

permissions to default.
In Example 1-11, the print method introduced by the extends
directive hides the print method in the super class.

1-139
Example 1-11
class pbase;
virtual task print();
$display("Im pbase\n");
endtask
endclass
class packet extends pbase;
task foo();
$display(); //Call the print task
endtask
endclass
hide(virtuals); // Allows permissions to
// hide pbase::print task
virtual task print();
$display("Im packet\n);
endtask
endextends
As explained earlier, there are two types of hide permissions:

a. Permission to hide virtual methods defined in a super class
(option virtuals) is referred to as virtuals-permission. An aspect
item is either an introduction, an advice, or a hide list within an
aspect. If at an aspect item within an aspect, such permission
is granted, then the virtuals-permission is said to be on or the
status of virtuals-permission is said to be on at that aspect item
and at all the aspect items following that, until a hide list that
forfeits the permission is encountered. If virtuals-permission is
not on or the status of virtuals-permission is not on at an aspect
item, then the virtuals-permission at that item is said to be off
or the status of virtuals-permission at that item is said to be off

1-140
b. Permission to suspend access rules and to specify advice that

changes protected and local virtual methods (option "rules") is
referred to as rules-permission. If within an aspect, at an aspect
item, such permission is granted, then the rules-permission is
said to be on or the status of rules-permission is said to be on
at that aspect item and at all the aspect items following that,
until a hide list that forfeits the permission is encountered. If
rules-permission is not on or the status of rules-permission is
not on at an aspect item, then the rules-permission at that item
is said to be off or the status of rules-permission at that item is
said to be off.
Permission for one of the above types of hide permissions does not
affect the other. Status of rules-permission and hide-permission
varies with the position of an aspect item within the aspect. Multiple
hide_list(s) may appear in the extension. In an aspect, whether an
introduction or an advice that can be affected by hide permissions is
permitted to be defined at a given position within the aspect
extension is determined by the status of the relevant hide permission
at the position. A hide_list at a given position in an aspect can
change the status of rules-permission and/or virtuals-permission at
that position and all following aspect items until any hide permission
status is changed again in that aspect using hide_list.
Example 1-12 illustrates how the two hide permissions can change
at different aspect items within an aspect extension.
Example 1-12
class pbase;
virtual task print1();
$display("pbase::print1\n");
endtask
$display("pbase::print2\n");
endtask
endclass

1-141
class packet extends pbase;

task foo();
$display();
endtask
local virtual task rules-test();
$display("Rules-permission example\n");
endtask
endclass
// At this point within the myaspect scope,
// virtuals-permission and rules-permission are both off.
hide(virtuals); // Grants virtuals-permission
// virtuals-permission is on at this point within aspect,
// and therefore can define print1 method introduction.
$display("packet::print1\n);
endtask
hide(); // virtuals-permission is forfieted
hide(rules); // Grants rules-permission
// Following advice permitted as rules-permission is on
before local virtual task rules-test();
$display("Advice to Rules-permission example\n");
endtask
hide(virtuals); // Grants virtuals-permission
// virtuals-permission is on at this point within aspect,
// and therefore can define print2 method introduction.
$display("packet::print2\n);
endtask
endextends
Examples
Introducing new members into a class:

1-142
Example 1-13 is shows how AOE can be used to introduce new

members into a class definition. myaspect adds a new property,
constraint, coverage group, and method to the packet class.
Example 1-13
class packet;
rand bit[31:0]...
...
endclass
integer sending_port;
constraint con2 {
hdr_len == 4;
}
coverage_group cov2 @(posedge CLOCK);
coverpoint sending_port;
endgroup
task print_sender();
$display("Sending port = %0d\n", sending_port);
endtask
endextends
As mentioned earlier, new members that are introduced should not

have the same name as a symbol that is already defined in the class
scope. So, AOE defined in the manner shown in Example 1-14 will
is not allowed, as the aspect myaspect defines x as one of the
introductions when the symbol x is already defined in class foo.
Example 1-14 : Non permissible introduction

class foo;
rand integer myfield;
integer x;
...
endclass
extends myaspect(foo);
integer x ;

1-143
constraint con1 {
myfield == 4;
}
endextends
Examples of advice code

In Example 1-15, the extends directive adds advices to the
packet::send method.
Example 1-15 :
program test;
packet p;
p = new();
p.send();
endprogram
class packet;
task send();
endtask
endclass
before task send();
$display("Before sending packet\n");
endtask
after task send();
$display("After sending packet\n");
endtask
endextends
When Example 1-15 is executed, the output is:

Before sending packet
Sending data
After sending packet

1-144
In Example 1-16, extends directive myaspect adds advice to turn off

constraint c1 before each call to the foo::pre_randomize method.
Example 1-16 :
class foo;
constraint c1 {
myfield == 4;
}
endclass
before task pre_randomize();
constraint_mode(OFF, "c1")
endtask
endextends
In Example 1-15, extends directive myaspect adds advice to set a

property named valid to 0 after each call to the foo::post_randomize
method.
Example 1-17 :
class foo;
integer valid;
constraint c1 {
myfield == 4;
}
endclass
after task post_randomize();
valid = 0;
endtask
endextends
Example 1-17 shows an aspect extension that defines an around

advice for the class method packet::send. When the code in example
is compiled and run, the around advice code is executed instead of
original packet::send code.

1-145
Example 1-18
program test;
packet p;
p = new();
p.setLen(5000);
p.send();
p.setLen(10000);
p.send();
endprogram
class packet;
integer len;
task setLen( integer i);
len = i;
}
task send();
endtask
endclass
around task send();
if (len < 8000){
proceed;
}
else{
$display("Dropping packet\n");
}
endtask
endextends
This Example 1-18 also demonstrates how the around advice code
can reference properties such as len in the packet object p. When
executed the output of the above example is,
Sending data
Dropping packet

1-146
Interprocess Synchronization and Communication

Semaphores
SystemVerilog semaphores are not signal devices. They are buckets
that contain keys, where competing resources, such as different initial
blocks in a program, require keys from the bucket to continue
processing.
program prog;
semaphore sem1 = new(2);
initial
begin:initial1
#1 sem1.get(1);
$display("initial1 takes 1 key at %0t", $time);
#6 sem1.put(1);
$display("initial1 returns 1 key at %0t",$time);
#1 sem1.get(1);
$display("initial1 takes 1 key at %0t", $time);
end
initial
begin:initial2
#5 sem1.get(2);
$display("
#5 sem1.put(1);
$display("
inital2 takes 2 keys at %0t",$time);

inital2 returns 1 key at %0t",$time);
end
endprogram
In this program there are two initial blocks, labeled by the label on
their begin-end blocks, initial1 and intital2.

1-147
The program has a semaphore named sem1 that starts with two keys,
as specified with the semaphore keyword and new() method.
If it were not for initial2, initial1 would do the following:
1. Take a key at simulation time 1 (using the get method).
2. Return a key at time 7 (using the put method).
3. Take a key again at time 8 (using the get method).
If it were not for initial1, initial2 would do the following:
1. Take two keys at simulation time 5 (using the get method).
2. Return one key at time 10 (using the put method).
However both initial blocks contend for a limited number of keys that
they need in order to finish executing, in taking keys that the other
needs, they interrupt each others processing. The $display system
tasks display the following:
initial1 takes 1 key at 1
initial1 returns 1 key at 7
inital2 takes 2 keys at 7
inital2 returns 1 key at 12
The initial block initial2 could be rewritten to use the try_get method
to see if a certain number of keys are available, for example:
initial
begin:initial2
#5 if(sem1.try_get(2))
begin
sem1.get(2);
$display("inital2 takes 2 keys at %0t",$time);
end

1-148
#5 sem1.put(1);
$display("inital2 returns 1 key at %0t",$time);
end
endprogram
In the revised initial2, at simulation time 5, the try_get method

checks to see if there are two keys in sem1. There arent, because
initial1 took one. At time 10 the put method returns a key to sem1.
Actually the get and put methods only decrement and increment a
counter for the keys, there are no keys themselves, so initial2 can
increment the key count without having previously decrementing this
count.
initial1 returns 1 key at 7
inital2 returns 1 key at 10
Semaphore Methods
Semaphores have the following built-in methods:
new (number_of_keys)
You use this method with the semaphore keyword. It specifies
the initial number of keys in the semaphore.
put(number_of_keys)
Increments the number of keys in the semaphore.

1-149
get(number_of_keys)
Decrements the number of keys in the semaphore. If there arent
the specified number of keys in the semaphore, VCS halts
simulation of the process (initial block, task, etc.) until there the
put method in another process increments the number of keys
to the sufficient number.
try_get (number_of_keys)
Decrements the number of keys in the semaphore. If there arent
the specified number of keys in the semaphore, this method
returns a 0. If the semaphore has the specified number of keys,
this method returns 1. After returning the value, VCS executes
the next statement.
Mailboxes
Mailboxes are FIFO containers for messages that are expressions.
Note:The SystemVerilog 3.1a LRM specifies that you can specify a
maximum number of messages that a mailbox can hold, but this
feature isnt implemented yet.
program prog;
mailbox mbx = new ();
int i,j;
int k = 10;
initial
begin
repeat(3)
begin
#5 mbx.put(k);
i = mbx.num();
$display("No. of msgs in mbx = %0d at %0t",i,$time);
k = k + 1;

1-150
end
i = mbx.num();
repeat (3)
begin
#5 $display("No. of msgs in mbx = %0d j = %0d at
%0t",i,j,$time);
mbx.get(j);
i = mbx.num();
end
end
endprogram
This program declares a mailbox named mbx with the mailbox

keyword and the new() method.
The initial block does the following:
1. Executes a repeat loop three times which does the following:
a. Puts the value of k in the mailbox.
b. Assigns the number of messages in the mailbox to i.
c. Increments the value of k.
2. Execute another repeat loop three times that does the following:
a. Displays the number of messages in the mailbox, the value of
j, and the simulation time.
b. Assigns the first expression in the mailbox to j.
c. Assigns the number of messages to i.
No.
No.
No.
No.
No.
No.
of
of
of
of
of
of
msgs
msgs
msgs
msgs
msgs
msgs
in
in
in
in
in
in
mbx
mbx
mbx
mbx
mbx
mbx
=
=
=
=
=
=
1
2
3
3
2
1
at 5
at 10
at 15
j = 0 at 20
j = 10 at 25
j = 11 at 30

1-151
Mailbox Methods
Mailboxes use the following methods:
new()
Along with the mailbox keyword, declares a new mailbox. You
cannot yet specify the maximum number of messages with this
method.
num()
Returns the number of messages in the mailbox.
put(expression)
Puts another message in the mailbox.
get(variable)
Assigns the value of the first message to the variable. VCS
removes the first message so that the next message becomes
the first method. If the mailbox is empty, VCS suspends simulation
of the process (initial block, task, etc.) until a put method put a
message in the mailbox.
try_get(variable)
Assigns the value of the first message to the variable. If the
mailbox is empty, this method returns the 0 value. If the message
is available, this method returns a non-zero value. After returning
the value, VCS executes the next statement.
peek(variable)
Assigns the value of the first message to the variable without
removing the message. If the mailbox is empty, VCS suspends
simulation of the process (initial block, task, etc.) until a put
method put a message in the mailbox.

1-152
try_peek(variable)
Assigns the value of the first message to the variable without
removing the message. If the mailbox is empty, this method
returns the 0 value. If the message is available, this method
returns a non-zero value. After returning the value, VCS executes
the next statement.
Events
SystemVerilog has a number of extensions to named events. These
extensions are as follows:
Waiting for an Event
Persistent Trigger
Merging Events
Reclaiming Named Events
Event Comparison
Waiting for an Event

You can enter a hierarchical name for a named event in an event
control.
`timescale 1ns/1ns
program prog;
task t1;
event evt1;
#5 -> evt1;
endtask

1-153
initial
t1;
initial
@(t1.evt1) $display("t1.evt1 happened at %0t",$time);
endprogram

t1.evt1 happened at 5
Persistent Trigger
The triggered property persists on a named event throughout the
time step when it is triggered, preventing a race condition, for
example, when a named event is triggered and is evaluated in an
event control during the same time step.
program prog;
event evt1,evt2;
initial
-> evt1;
initial
begin
wait (evt1.triggered);
$display("evt1 triggered");
end
initial
fork
-> evt2;
begin
wait (evt2.triggered);
$display("evt2 occurred");

1-154
end
join
endprogram

evt1 triggered
evt2 occurred
Merging Events
You can assign a SystemVerilog named event to another named
event. When you do, they alias each other and when VCS executes
a line calling for the triggering of one of these events, VCS triggers
both named events.
program prog;
event evt1, evt2, evt3;
initial
begin
evt2 = evt3;
evt1 = evt3;
#2 -> evt1;
end
// this is an alias
// this is an alias
initial
#1 @ (evt1) $display("evt1 triggerred");
initial
initial
endprogram

1-155

evt1 triggerred
evt2 triggerred
evt3 triggerred
IMPORTANT:
When you merge events, the merger takes effect only in
subsequent event controls or wait statements.
In this example, the merging occurred at time 0, the event controls
at time 1, and the triggering of the events at time 2.
Reclaiming Named Events

When you assign the null keyword to a named event, that named
event no longer can synchronize anything. In an event control it might
block forever or not at all. In a wait statement, it is as if the named
event were undefined, and triggering the named event causes no
simulation events.
program prog;
event evt1;
initial
begin
evt1 = null;
#5 -> evt1;
end
initial
#1 @(evt1) $display("evt1 triggered");
initial
begin
#5 wait (evt1.triggered);

1-156
$display("evt1 occurred");
end
endprogram
The $display system tasks do not display anything.
Event Comparison
You can use the equality and inequality operators to see if named
events are aliased to each other or have been assigned the null value,
for example:
program prog;
event evt1, evt2, evt3;
initial
begin
evt1 = evt2;
if (evt1 == evt2)
$display("evt1
if (evt1 === evt2)
$display("evt1
if (evt1 != evt3)
$display("evt1
if (evt3 != null)
$display("evt3
end
endprogram
== evt2");
=== evt2");
!= evt3");
!= null");

evt1
evt1
evt1
evt3
== evt2
=== evt2
!= evt3
!= null

1-157
In comparing named events, the case equality operator === works

the same as the equality operator ==, and the case inequality operator
!== works the same as the inequality operator !=.
Clocking Blocks
A clocking block encapsulates a group of signals that are sampled or
synchronized by a common clock. It defines the timing behavior of
those signals with respect to the associated clock. Consequently,
timing and synchronization details for these signals is separate from
the structural, functional, and procedural elements of the testbench.
This enables synchronous events, input sampling, and synchronous
drives to be written without explicitly using clocks or specifying timing.
Clocking blocks can be declared inside a program block or inside an
interface.
Clocking Block Declaration

The syntax for declaring a clocking block is:
clocking clocking_identifier @clocking_event;
[default clocking_dir clocking_skew [clocking_dir
clocking_skew];]
{clocking_dir [clocking_skew][clocking_dir
[clocking_skew]]signal_identifier [=
hierarchical_identifier]
{,signal_identifier [= hierarchical_identfier]};}
endclocking[: clocking_identifier]
clocking_identifier
Name of the clocking block being declared.

1-158
clocking_event
Event that acts as the clock for the clocking block (for example:
posedge, negedge of a clocking signal):
@(posedge clk)
or
@(clk)
Note:
Program signals cannot be used inside a clocking event
expression.
clocking_dir
Direction of the signal: input, output or inout. If you specify more
than one clocking_dir, they must be in the order input...output:
input clocking_skew output clocking_skew
The inout signal cannot be used in the declaration of a default

skew. Also, if the clocking_dir of a clocking block signal is inout,
you cannot specify a clocking_skew. For example:
inout #1 d; //results in a syntax error
inout d;
//is fine

1-159
clocking_skew
Determines how long before the synchronized edge the signal is
sampled, or how long after the synchronized edge the signal is
driven. A clocking_skew can consist of an edge identifier and a
delay control, just an edge identifier, or just the delay control. The
edge identifiers are posedge and negedge. The edge can be
specified only if the clocking event is a singular clock (that is, a
simple edge of a single signal like @(posedge clk), @(clk),
@(negedge top.clk), etc.).The delay control is introduced by "#"
followed by the delay value. The following are examples of legal
clocking_skews:
input #0 i1;
output negedge #2 i2;
input #1 output #2;
Note:
Time literals (e.g., #10ns and #2ns) are not supported in this
release.
The skew for an input signal is implicitly negative (that is, sampling
occurs before the clock event). The skew for an output signal is
implicitly positive (that is, the signal is driven after the clock event).
Note:
#1step is the default input skew unless otherwise specified.
However, an explicit #1step skew is not yet supported.
signal_identifier
Identifies a signal in the scope enclosing the clocking block
declaration, and declares the name of a signal in the clocking
block. Unless a hierarchical_expression is used, both the signal
and the clocking_item names shall be the same. For example:

1-160
input #1 i1;
where i1 is the signal_identifier.

Note:
A clocking block signal can only be connected to a scalar, vector,
packed array, integer or real variable. Program signals are not
allowed in clocking block signal declarations.
hierarchical_identifier
Hierarchical path to the signal being assigned to the
signal_identifier. For example:
input negedge #2 i
= top.i2;
where i2 is defined in a module top.

Note:
see page 182 of the System Verilog LRM 3.1a for a formal
definition of the syntax for declaring the clocking block.
Note:
Slices and concatenations are not yet implemented
A single skew can be declared for the entire clocking block. For
example:
default input #10;
You can override default skews when you declare a signal.

The following example includes a clocking block embedded in a
program:
`timescale 1ns/1ns
module top;

1-161
reg out3;
reg out1;
reg clk = 0;
p1 p(out3,clk,out1);
assign out1 = out3;
initial forever begin
clk = 0;
#10;
clk = 1;
#10;
end
endmodule
program p1(output reg out3,input logic clk,input reg in );
clocking cb @(posedge clk);

output #3 out2 = out3; //CB output signal
input #0 out1 = in;
endclocking
initial
#200 $finish;
initial begin
$display($time,,,cb.out1);
cb.out2 <= 0;
//driving output at "0" time
@(cb.out1);
//sampling input for change
#100;
cb.out2 <= 1;
//driving o/p at posedge of clk
@(cb.out1);

1-162
end
endprogram

0 x
30 0
130 0
150 1
Input and Output Skews

The skew for input and inout signals determines how long before
clocking_event the signal is sampled. The skew for output and inout
signals determines how long after the clock_event the signal is driven.
Figure 1-3
Driving and sampling on the negative edge of the clock
input signal
sampled here
output signal
driven here
Clock
input skew output skew
For more details see section 15.3 of the SystemVerilog LRM 3.1a.

1-163
Hierarchical Expressions
Every signal in a clocking block is associated with a program port or
a cross module reference.
As described when defining hierarchical_identifier, the hierarchical
path is assigned to the defined in the clocking block.
clocking cb2 @ (negedge clk);
input #0 b = top.q;
endclocking
Below is an example of the hierarchical_identifier as a program port:

program p1(output reg out3,input logic clk,input reg in );
output #3 out2 = out3;//out3 and in = program ports
input #0 out1 = in;
endclocking
endprogram
Signals in Multiple Clocking Blocks

The signals (clocks, input, outputs, or inouts) associated with one
clocking block can be associated with any other clocking blocks. For
example:
program test( input bit clk_1, input bit clk_2,
input reg [15:0] data );
default clocking data @(posedge clk_1);
input data;
endclocking
clocking address @(posedge clk_2);
input data;

1-164
endclocking
Clocking blocks that use the same clock can share the same
synchronization event. For example:
program test( input bit clk_1, input reg [15:0] address,
input reg [15:0] data );
default clocking data @(posedge clk_1);
input data;
endclocking
clocking address @(posedge clk_1);
input address;
endclocking
Clocking Block Scope and Lifetime

Signals associated with a clocking block can be accessed by using
a dot (.) operator. For example:
clocking CB_1 @(posedge clk_1);
input data;
input address;
endclocking
CB_1.data;
CB_1.address;
The scope of a clocking block is local to its enclosing module,

interface, or program. Clocking blocks cannot be nested. They cannot
be declared inside packages, functions, tasks, and outside all
declarations in a compilation unit. The lifetime of a clocking block is
static.

1-165
Clocking Block Events

The clocking_identifier can be used to refer to the clocking_event of
a clocking block. For example:
clocking cb1 @(posedge clk);
input #0 i1;
input negedge #2 address;
endclocking
The clocking event of the cb1 clocking block can be used to wait for
that particular event:
@(cb1);
Therefore, @(cb1) is equivalent to @(posedge clk).
Default Clocking Blocks

One clocking block can be specified as the default clocking block for
all cycle delay operations within a given module, program, or
interface.
Syntax:
default clocking clocking_identifier
or
clocking_declaration ::==
[default] clocking [clocking_identifier] clocking_event;
endclocking
clocking_identifier
Name of a clocking block.

1-166
Note:
You can specify only one default clocking block in a program,
module, or interface. VCS issues a compilation error if you specify
more than one default clocking block.
For example:
program test( input bit clk, input reg [15:0] data );
default clocking bus @(posedge clk);
input data;
endclocking
initial begin
## 5;
if ( bus.data == 10 )
## 1;
else
##2;
end
endprogram
Cycle Delays
Cycle delays can be used to postpone or delay the execution by a
specified number of clock cycles or clocking events. The term cycle
refers to the clock associated with the default clocking block.The ##
operator is used to specify cycle delay.
Syntax:
## integral_number | integer | (expression)
expression

1-167
Any SystemVerilog expression that evaluates to a positive integer

value.
For example:
## 2;
## (x+1);
Note:
VCS issues a compilation error if you use a cycle delay without
specifying a default clocking block for the current module,
interface, or program.
Input Sampling
All inputs and inouts of a clocking block are sampled at the
clocking_event for that block. The following is skew related behavior
involving regions:
When the skew is #0, the signal value in the Observed region
corresponds to the value sampled.
When the skew is not #0, then the signal value at the Postponed
region of the timestep skew time-units prior to the clocking event
When the skew is #1step, the signal value in the Preponed region
The last sampled value of signal replaces the signal when the signal
appears in an expression.
Note:
See section 14.3 of the SystemVerilog LRM 3.1a for definitions of
Observed, Postponed and Preponed regions.

1-168
Synchronous Events
The event control operator, @, is used for explicit synchronization.
This operator causes a process to wait for a particular event (that is,
signal value change, or a clocking event) to occur.
Syntax
@ (expression);
expression
denotes clocking block input or inout, or a slice, which may include
dynamic indices. The dynamic indices are evaluated when
@(expression) executes.
For examples, see pages 189-190 of the SystemVerilog LRM3.1a
Synchronous Drives
The output (or inout) signals defined in a clocking block are used to
drive values onto their corresponding signals in the DUT at a specified
time. That is, the corresponding signal changes value at the indicated
clocking event as indicated by the output skew.
Note: For the syntax for specifying a synchronous drive, see section
15.14 of the SystemVerilog LRM 3.1a.
Consider the following clocking block and synchronous drives:
clocking cb1 @(posedge clk);
default output #2;
input #2 output #0 a = a1;
output b = b1;
endclocking

1-169
initial
begin
@ (cb1); //synchronising with clocking event
cb1.a <= 0; //drive at first posedge
cb1.b <= 0;
//drive after skew on first posedge
##2 cb1.a <= 1;
##1 cb1.b <= 1; //drive after 3 clock cycles
end
The expression cb1.a (and cb1.b) is referred to as the

clockvar_expression in the SystemVerilog LRM 3.1a (see page 190).
Note:Synchronous drives with a blocking cycle delay is supported.
However, a synchronous drive with an intra cycle delay is not yet
supported.
Drive Value Resolution

When the same net is an output from multiple clocking blocks, then
the net is driven to its resolved signal value. When the same variable
is an output from multiple clocking blocks, then the last drive
determines the value of the variable.
Clocking Blocks in SystemVerilog Assertions

You can enter a clocking block as a clock signal for an assertion,
property, or sequence. When you do the clocking event in the clocking
block becomes the clock signal. The following is an example of a
clocking block in an assertion:
clocking ck1 @(posedge clk) ;
.
.
.
endclocking

1-170
sequence seq ;
@(ck1) a ##1 b ;
endsequence
A: assert property (@(ck1) a ##1 b) ;
N: assert property (seq) ;
In this example the clocking block named ck1 is specified a the clock
signal in the sequence and the two assertions. The clocking event in
the clocking block, posedge clk, becomes the clock signal.
Sequences and Properties in Clocking Blocks

You can enter sequences and properties in a clocking block and then
use them in an assertion. When you do, the clocking event for the
clocking block becomes the clock signal for the sequence or property.
The following is an example of a property in a clocking block:
clocking ck1 @(posedge clk) ;
property prop1;
a ##1 b ;
endproperty
endclocking
A: assert property (ck1.prop1) ;
Here property prop1 is declared in the clocking block named ck1. The
clock signal for the property is posedge clk. You enter the property
in an assertion by specifying the clocking block and then the property.

1-171
SystemVerilog Assertions Expect Statements

SystemVerilog assertions expect statements differ from assert,
assume, and cover statements in the following ways:
expect statements must appear in a SystemVerilog programs,

whereas assert, assume, and cover statements can appear in
modules, interfaces, and programs.
You can declare sequences and properties and use them as

building blocks for assert, assume, and cover statements, but
this is not true for expect statements. expect statements dont
have sequences, neither explicitly or implicitly. expect
statements have properties, but properties are not explicitly
declared with the property keyword.
Note:
- assert, assume, and cover statements cannot appear in
clocking blocks.
- assert, assume, and cover statements can appear in
programs on an early availability basis.
In an expect statement you specify a clock signal and have the
option of specifying an edge for clocking events and delays, just like
assert and cover statements, but these are not followed by a
sequence, instead there is just a clock delay and an expression. There
are action blocks that execute based on the truth or falsity of the
expression. The clock delay can be a range of clocking events, and
VCS evaluates the expression throughout that range. You can specify
that the clock delay and evaluation of the expression must repeat a
number of times (you cant both have a range of clocking events and
also use repetition).

1-172
The following is an example of an expect statement:

e1: expect (@(posedge clk) ##1 in1 && in2)
begin
.
// statements VCS executes
.
// if in1 && in2 is true
.
end
else
begin
.
// Statements VCS executes
.
// if in1 && in2 is false
.
end
Where:
e1:
Is an instance name for the expect statement. You can use any
unique name you want, followed by a colon (:).
expect
The expect keyword.

(@(posedge clk) ##1 in1 && in2)
Is the property of the expect statement. Such properties are

enclosed in parentheses. This property is the following:
@(posedge clk)
the clock signal is clk, the clocking event is a rising edge
(posedge) on clk. Using the posedge keyword means that it,
with the clock signal, are an expression and so are also
enclosed in parentheses.
##1
Is a clock delay. It specifies waiting for one clocking event, then

evaluating the expression.
in1 && in2
Is an expression. If true, VCS executes the first action block

1-173
called the success block. if false VCS executes the second

action blockafter the keyword else, called the failure block.
Here is another example of an expect statement. This one calls for
evaluating the expression after a range of clocking events.
e2: expect (@(posedge clk) ##[1:9] in1 && in2)
begin
.
.
.
end
else
begin
.
.
.
end
This expression calls for evaluation the expression after 1, 2, 3, 4, 5,

6, 7, 8, and 9 clocking events, a range of clocking events from 1 to 9.
Here is another example of an expect statement. This one calls for
evaluating the expression to be true a number of times after the clock
delay.
e3: expect (@(posedge clk) ##1 in1 && in2 [*5])
begin
.
.
.
end
else
begin
.
.
.
end

1-174
[*] is the consecutive repeat operator. This expect statement calls

for waiting a clock delay and then seeing if the expression is true, and
doing both of these things five times in a row.
Note:
You can use the [*] consecutive repeat operator when you
specify a range of clocking events such as ##[1:9].
The following is a code example that uses expect statements:
module test;
logic log1,log2,clk;
initial
begin
log1=0;
log2=0;
clk=0;
#33 log1=1;
#27 log2=1;
#120 $finish;
end
always
#5 clk=~clk;
tbpb tbpb1(log1, log2, clk);
endmodule
program tbpb (input in1, input in2, input clk);
bit bit1;
initial
begin
e1: expect (@(posedge clk) ##1 in1 && in2)
begin
bit1=1;
$display("success at %0t in %m\n",$time);
end
1-175
else
begin
bit1=0;
$display("failure at %0t in %m\n",$time);
end
e2: expect (@(posedge clk) ##[1:9] in1 && in2)
begin
bit1=1;
end
else
begin
bit1=0;
end
e3: expect (@(posedge clk) ##1 in1 && in2 [*5])
begin
bit1=1;
end
else
begin
bit1=0;
end
end
endprogram
The program block includes an elementary clocking block, specifying

a clocking event on the rising edge of clk, and no skew for signals in1
and in2.
The $display system tasks in the failure and success action blocks
display the following:
failure at 15 in test.tbpb1.e1
success at 65 in test.tbpb1.e2

1-176
success at 125 in test.tbpb1.e3
Virtual Interfaces
A Virtual Interface (VI) allows a variable to be a reference to an actual
instance of an interface. VCS classifies such a variable with the Virtual
Interface data type. Here is an example:
interface SBus;
logic req, grant;
endinterface
module m;
SBus sbus1();
SBus sbus2();
.
.
.
endmodule
program P;
virtual SBus bus;
initial
begin
bus = m.sbus1;
// setting the reference to a real

// instance of Sbus
$display(bus.grant); // displaying m.sbus1.grant
bus.req <= 1; // setting m.sbus1.req to 1
#1 bus = m.sbus2;
bus.req <= 1;
end
endprogram

1-177
Scope of Support
VCS supports virtual interface declarations in the following locations:
program blocks and classes (including any named sub-scope)
tasks or functions inside program blocks or classes (including any

named sub-scope).
Variables with the virtual interface data type can be either of the
following:
SystemVerilog class members.
Program, task, or function arguments.
You cannot declare a virtual interface in a module or interface

definition.
Virtual Interface Modports

If only a subset of Interface data members is bundled into a modport,
a variable can be declared as virtual Interface_name.modport_name:
Example.
interface SBus;
logic req, grant;
modport REQ(input req);
endinterface
program P;
virtual Sbus.REQ sb;
The semantic meaning is the same as in the example above with the
difference that sb is now a reference only to a portion of Sbus and

1-178
writing assignments are subject to modport direction enforcement so

that, for example, sb.req = 1" would become illegal now (violates
input direction of the modport REQ).
Driving a Net Using a Virtual Interface

There are two ways of driving interface nets from a testbench. These
are:
Via clocking block:

interface intf(input bit clk);
wire w1;
clocking cb @ (posedge clk);
output w1;
endclocking
endinterface
By including a driver updated by a continuous assignment from a

variable within the interface
interface intf;
wire w1;
reg r1;
assign w1 = r1;
endinterface
This example demonstrates driving an interface net in a design.
Virtual Interface Modports and Clocking Blocks

You can reference an interface clocking block signal directly by using
dot notation. The clocking information can be sent to the testbench
only through modport if interface is having modports. The following
example demonstrates this.

1-179
interface intf(input clk);

int d;
default input #2 output #2;
inout d;
endclocking
modport CB(clocking cb); //synchronous testbench modport
modport master(inout d); //asynchronous testbench modport
endinterface
module top;
bit clk;
always #5 clk = ~clk;
intf INTF(clk);
tb TB(INTF);
endmodule
program tb(intf.CB ckb); //CB type modport is used to pass
//clocking information with interface signals
virtual intf.CB x = ckb;
initial
#200 $finish;
initial begin
x.cb.d <= 1; @(x.cb.d); $display($time,,x.cb.d);
x.cb.d <= 2; @(x.cb.d); $display($time,,x.cb.d);
//x.d <= 3;
illegal as signal not visible via
//CB modport
end
endprogram
The output of this example is:

15
25

1-180
1
2
In the above example, if the modport passed to the testbench is of

asynchronous type intf.master then the program will be:
program tb(intf.master ckb);
virtual intf.master x = ckb;
initial begin
x.d <= 1;
x.d <= 2;
end
endprogram
@(x.d); $display($time,,x.d);
@(x.d); $display($time,,x.d);
The output of this example is:

0
0
1
2
Since clocking information is not passed through modport, the values

are driven irrespective of clock.
Clocking Block
Similarly to modport, a clocking block inside interface instance can
be referred to by a virtual variable:
interface SyncBus(input bit clk);
wire w;
output w;
endclocking
endinterface
....
program P;
virtual SyncBus vi;
...
initial vi.cb.w <= 1;

1-181
...
endprogram
In this case the assignment executes in accordance with the clocking

block semantics.
Event Expression/Structure
Consider SyncBus as defined in the section Clocking Block .
task wait_on_expr(virtual SyncBus vi1, virtual SyncBus vi2);
@(posedge (vi1.a & vi2.a))
$display(vi1.b, vi2.b);
endtask
There is a principal difference between Vera and SV in that the @

operator can have an operand that is a complex expression. We
support all event expression that involve virtual interface variables.
Structures inside an interface can also be referred to by means of a
virtual interface.
Null Comparison
We support:
Comparison of vi variable with NULL.
Runtime error if uninitialized virtual interface is used

begin
virtual I vi;
vi.data <= 1;
end
NULL assignment

1-182
virtual vi = 0;
Not Yet Implemented
Named type that involves virtual interface

- typedef struct {reg rl; virtual I ii} T;
- typedef virtual I T;
Comparison of vi variables
By definition, vi1 == vi2 iff they refer to the same instance of an
interface (or both NULL).
VI variables defined in the design.
Coverage
The VCS implementation of SystemVerilog supports the
covergroup construct. Covergroups are specified by the user. They
allow the system to monitor values and transitions for variables and
signals. They also enable cross coverage between variables and
signals.
VCS collects all the coverage data during simulation and generates
a database. VCS provides a tool to read the database and generate
text or HTML reports.

1-183
The covergroup Construct

The covergroup construct specifies the set of cover points of
interest, crosses of these cover points and the clocking event that
tells VCS when to sample these cover points during simulation.
program prog;
bit clk = 0;
enum {red, blue, yellow} colors;
colors my_color;
cp1 : coverpoint my_color;
endgroup
cg1 cg1_1 = new;
initial
repeat (15)
#5 clk = ~clk;
initial
begin
#40 my_color = blue;
#23 my_color = yellow;
end
endprogram
This program contains the following:
The enumerated data type colors, with members named red, blue,
and yellow (whose default values are 0, 1, and 2).
A variable of type colors called my_color
A covergroup named cg1 that specifies the following:

1-184
- the clocking event that is the rising edge on signal clk.

- the coverage point that is to monitor the values of the variable
my_color. The identifier of the coverage point, for hierarchical
name purposes, is cp1.
an instantiation of covergroup cg1 using the new method.
A covergroup can be defined inside a class. Furthermore there can

be multiple covergroups in a class.
The following is an example of declaring a covergroup inside a class.
program P;
class MyClass;
int m_a;
covergroup Cov @(posedge clk);
coverpoint m_a;
endgroup
function new();
Cov = new;
endfunction
endclass
endprogram
Defining a Coverage Point

In a coverage point definition you can specify the following:
bins for value ranges
bins for value transitions
bins for illegal coverage point values

1-185
Bins for Value Ranges

You use the curly braces { } and the bins keyword to specify the
bins for a coverage point, for example:
covergroup cg1 @ (posedge clk);
coverpoint data
{
bins some_name [] = {[1:20]};
}
endgroup
In coverage point data:
The keyword bins specifies one or more bins for coverage data.
The name some_name is an identifier for all the bins. It is the root
bin name.
The empty square brackets [] specifies there will be a separate

bin for each value in the specified range.
The range of value follows the equal sign = and is in the nested
set of curly braces { }. This range is 1 through 20. The range is
always specified as lowest_value:highest_value.
Coverage point data will have 20 bins, the first named some_name_1
and the last named some_name_20.
You can specify different bins for different value ranges, for example:
coverpoint data
{
bins first_ten = {[1:10]};
bins second_ten = {[11:20]};
}

1-186
Here the coverage information about when the coverage point data
has the values 1 to 10 is in the bin named first_ten, and the information
about when data has the values from 11 to 20 is in the bin named
second_ten.
You can specify a default bin with the default keyword, for example:
coverpoint data
{
bins bin1 = {[1:5]};
bins bin2 = {[6:10]};
bins bin3 = default;
}
In this example coverage information about when data has the values
1-10 is in bins bin1 and bin2, information about all other values is in
bin3.
You can specify a list of value ranges for example:
coverpoint data
{
bins bin1 = {[0:3],5,7,[9:10]};
bins bin2 = {4,6,8};
bins bin3 = default;
}
Here the information about when data is 0, 1, 2, 3, 5, 7, 9, and 10 is

in bin1, the information about when data is 4, 6, and 8 is in bin2, and
the information about when data has any other value is in bin3.
When you instantiate the covergroup, you can make the covergroup
a generic covergroup and then pass integers to specify value ranges
in the new method, for example:
covergroup cg1 (int low, int high) @ (posedge clk);
coverpoint data

1-187
{
bins bin1 = {[low:high]};
}
endgroup
cg1 cg1_1 = new(0,10);
// 0 is the low value

// 10 is the high value
// of the range
Bins for Value Transitions

In a transition bin you can specify a list of sequences for the
coverpoint. Each sequence is a set of value transitions, for example:
coverpoint data
{
bins from0 = (0=>1),(0=>2),(0=>3);
bins tran1234 = (1=>2=>3=>4);
bins bindef = default;
}
In this example, coverage information for the sequences 0 to 1, 0 to

2, or 0 to 3 is in the bin named from0. Coverage information about
when data transitions occurred from 1 to 2 and then 3 and then 4 is
in bin tran1234.
You can use range lists to specify more than one starting value and
more than one ending value, for example:
bins from1and5to6and7 = (1,5=>6,7);
Is the equivalent of:

bins from1and5to6and7 = (1=>6, 1=>7, 5=>6, 5=>7);
You can use the repetition [*] operator, for example:

1-188
bin fivetimes3 = (3 [*5]);

bin fivetimes3 = (3=>3=>3=>3=>3);
You can specify a range of repetitions, for example:

bin fivetimes4 = (4 [*3:5]);

bin threetofivetimes4 = (4=>4=>4,4=>4=>4=>4,4=>4=>4=>4=>4);
Specifying Illegal Coverage Point Values

Instead of specifying a bin with the bins keyword, use the
illegal_bins keyword to specify values or transitions that are
illegal.
coverpoint data
{
illegal_bins badvals = {7,11,13};
illegal_bins badtrans = (5=>6,6=>5);
bins bindef = default;
}
VCS displays an error message when the coverage point reaches

these values or makes these transitions.

1-189
Defining Cross Coverage

Cross coverage is when there are two coverage points that you want
VCS to compare to see if all the possible combinations of the possible
values of the two coverage points occurred during simulation.
Consider the following example:
program prog;
bit clk;
bit [1:0] bit1,bit2;
bit1: coverpoint bit1;
bit2: coverpoint bit2;
bit1Xbit2: cross bit1, bit2;
endgroup
cg1 cg1_1 = new;
initial
begin
clk = 0;
repeat (200)
begin
bit1 = $random();
bit2 = $random();
#5 clk = ~clk;
#5 clk = ~clk;
end
end
endprogram
In covergroup cg1 there are two coverpoints labeled bit1 and bit2. In
addition, there is the following:
1. the bit1Xbit2 identifier for the cross.

1-190
2. The cross keyword, specifying the coverpoints to be crossed.

Both coverpoints are two-bit signals. The four possible values of each
are 0 through 3. There are 16 possible combinations of values.
The prog.txt file for this code contains the following:
Automatically Generated Cross Bins
bit1
bit2
# hits
at least
=======================================================
auto[0]
auto[0]
10
1
auto[0]
auto[1]
13
1
auto[0]
auto[2]
12
1
auto[0]
auto[3]
5
1
auto[1]
auto[0]
12
1
auto[1]
auto[1]
18
1
auto[1]
auto[2]
10
1
auto[1]
auto[3]
13
1
auto[2]
auto[0]
19
1
auto[2]
auto[1]
16
1
auto[2]
auto[2]
17
1
auto[2]
auto[3]
6
1
auto[3]
auto[0]
6
1
auto[3]
auto[1]
15
1
auto[3]
auto[2]
16
1
auto[3]
auto[3]
12
1
=======================================================
There are 16 cross coverage bins, one for each possible combination.
Defining Cross Coverage Bins

The binsof construct supplies the coverage bins for the expression
argument, which can be either a coverpoint or a coverpoint bin.
cp1 : coverpoint bit1
{

1-191
bins lowcp1vals = {[0:7]};

bins hicp1vals = {[8:15]};
}
{
bins lowcp2vals = {[0:7]};
bins hicp2vals = {[8:15]};
}
cp1Xcp2 : cross cp1, cp2
{
bins bin1 = binsof(cp1) intersect {[0:7]};
bins bin2 = binsof(cp1.hicp1vals) ||
binsof(cp2.hicp2vals);
bins bin3 = binsof(cp1) intersect {[0:1]} &&
binsof(cp2) intersect {[0:3]};
}
endgroup
In this example, the respective cross coverage bins, bin1, bin2, and
bin3 receive data whenever the corresponding right hand side binsof
expressions are satisfied. For example, bin1 receives data when
any bin of cp1 whose value range overlaps with the range [0:7]
receives data. In this case bin1 receive data whenever bin
lowcp1vals of coverpoint cp1 receives data.
Similarly, cross bin, bin2 receives data whenever either bin
hicp1vals, of coverpoint cp1, receives data, or bin hicp2vals, of
cover point cp2, receives data. Cross bin, bin3 receives data if any
bin of cover point cp1, whose value range overlaps with the range
[0:1], receives data, and, for the same sample event occurrence, any
bin of cover point cp2, whose value range overlaps with the range
[0:3], also receives data. In this example, cross bin bin3 receives
data when bin lowcp1vals, of cover point cp1, receives data, and
bin lowcp2vals, of cover point cp2, also receives data.

1-192
If none of the user-defined cross bins match, then VCS automatically

creates an auto cross bin to store the hit count for each unique
combination of the cover point bins.
Coverage Options
You can specify options for the coverage of a covergroup with the
type_option.option=argument keyword and argument for
specifying options, for example:
covergroup cg2 @(negedge clk);
type_option.weight = 3;
type_option.goal = 99;
type_option.comment = "Comment for cg2";
cp3 : coverpoint bit3;
endgroup
These options specify the following:

type_option.weight = integer;
Specifies the weight of the covergroup when calculating the
overall coverage. Specify an unsigned integer. The default weight
value is 1.
type_option.goal = integer;
Specifies the target goal of the covergroup. Specify an integer
between 0 and 100. The default goal is 90.
Note:
Coverage number is a percentage. If all bins of a covergroup
are covered, then the coverage number for that covergroup is
100%.

1-193
type_option.comment = "string";
A comment in the report on the covergroup.
You can also apply these option to coverage points, for example:
{
type_option.weight = 333;
type_option.goal = 50;
type_option.comment = "Comment for bit1";
}
endgroup
You can also apply these options to instances using the

instance_name.option.option_name=argument keyword
and argument, for example:
endgroup
cg1 cg1_1 = new;
initial
begin
cg1_1.option.weight = 10;
cg1_1.option.goal = 75;
.
.
.
end
Instance specific options are procedural statements in an initial block.

There are additional options that are just for instances:

1-194
instance_name.option.at_least=integer
Specifies the minimum number of hits in a bin for VCS to consider
the bin covered.
instance_name.option.auto_bin_max=integer
Specifies the maximum number of bins for a coverage point when
you dont define the bins for a coverage point.
instance_name.option.detect_overlap=boolean
The boolean argument is 1 or 0. When boolean is 1, VCS
displays a warning message when there is an overlap between
the range list or transitions list of two bins for the coverage point.
instance_name.option.name[=string]
This option is used to specify a name for the covergroup instance.
If a name is not specified, a name is automatically generated.
instance_name.option.per_instance=boolean
The boolean argument is 1 or 0. When boolean is 1, VCS keeps
track of coverage data for the instance.
Predefined Coverage Methods

SystemVerilog provides a set of predefined covergroup methods
described in this section. These predefined methods can be invoked
on an instance of a covergroup. They follow the same syntax as
invoking class functions and tasks on an object.
Predefined Coverage Group Functions

The predefined methods supported at this time are:
get_coverage()
get_inst_coverage()
1-195
set_inst_name(string)
sample()
stop()
start()
get_coverage()
Calculates the coverage number for the covergroup type (see
page 193 for definition). Return type: real.
Below is an example of using get_coverage() to calculate the
coverage number of a covergroup:
program test();
reg clk = 0;
reg [2:0] var = 3'b001;
class A;
covergroup covType @(clk); //covergroup, covType, defined
//in class A,
cp1: coverpoint var {
bins s0 = {[ 0 : 2]} ;
bins s1 = { 3 };
bins s2 = { 4 };
bins s3 = { 5 };
bins s4 = { 6 };
bins s5 = { 7 };
}
endgroup
function new;
covType = new(); //instantiate the embedded covergroup
endfunction
endclass
A A_inst;
initial begin

1-196
repeat (10) begin

#5 clk = ~clk;
var = var + 1;
/* get_coverage() calculates the number of the embedded
covergroup covType as a whole */
$display("var=%b coverage=%f\n", var,
A_inst.covType.get_coverage());
end
end
initial
A_inst = new();
endprogram
Output of program:
var=010 coverage=0.000000
See the get_coverage(), stop(), start() example on page 201 for

another example of using the get_coverage() function.

1-197
get_inst_coverage()
Calculates the coverage number for coverage information related
to the covergroup instance. Return type: real.
program test();
reg clk = 0;
reg [2:0] var = 3'b001;
covergroup covType (input integer param1) @(clk);
bins s0 = { [ 0 : param1] } ;
bins s1 = { 3 };
bins s2 = { 4 };
bins s3 = { 5 };
}
endgroup
covType cov1;
initial begin
repeat (5) begin
#5 clk = ~clk;
var = var + 1;
$display("var=%b coverage=%f\n", var,
cov1.get_inst_coverage());
end
end
initial
cov1 = new(2);
endprogram
The output of the program is:

var=010 coverage=-1.000000

1-198
set_inst_name(string)
The instance name is set to string. Return type: void.
In the example below, cov1 is the name of an instance that is of type
covType, declared as such (covType cov1; cov1 = new(2);).
The name is changed to new_cov1 after calling
set_inst_name("new_cov1").
program test();
reg clk = 0;
reg [2:0] var = 3'b001;
bins s0 = { [ 0 : param1] } ;
bins s1 = { 3 };
}
endgroup
covType cov1;
initial
begin
cov1 = new(2);
$display("Original instance name is %s\n",
cov1.option.name);
cov1.set_inst_name("new_cov1");//change instance name
$display("Instance name after calling set_inst_name()
is %s\n", cov1.option.name);
end
endprogram
Output of the program is:

1-199
Original instance name is cov1

Instance name after calling set_inst_name() is new_cov1
sample()
sample() triggers sampling of the covergroup instance. Return
void.
program test();
reg clk = 0;
reg [2:0] var = 3'b001;
covergroup covType ();
bins s0 = { 0 };
bins s1 = { 1 };
bins s2 = { 2 };
bins s3 = { 3 };
bins s4 = { 4 };
bins s5 = { 5 };
bins s6 = { 6 };
bins s7 = { 7 };
}
endgroup
covType cov1;
initial
cov1 = new();
initial begin
repeat (10) begin
#10 clk = ~clk;
var = var + 1;
end
end
initial begin
repeat (40) begin
#3 cov1.sample();
end
end
1-200
endprogram
stop()
When called, collecting of coverage information is stopped for that
instance. Return type: void. See the get_coverage(), stop(), start()
example on page 201.
start()
When called, collecting of coverage information resumes for that
instance. Return type: void. See the get_coverage(), stop(), start()
example on page 201.
get_coverage(), stop(), start() example
program test();
reg clk = 0;
reg [2:0] var = 3'b001;
bins s0 = { [ 0 : param1] } ;
bins s1 = { 3 };
bins s2 = { 4 };
bins s3 = { 5 };
bins s4 = { 6 };
bins s5 = { 7 };
}
endgroup
covType cov1;
initial begin
repeat (10) begin
#5 clk = ~clk;
var = var + 1;
$display("var=%b covergae=%f\n", var,
cov1.get_coverage());
end

1-201
end
initial
begin
cov1 = new(2);
cov1.stop();
cov1.option.weight = 5;
#30 cov1.start();
end
endprogram
OUTPUT:
var=010 covergae=0.000000

1-202
Unified Coverage Reporting

The db based coverage reporting has been replaced by the Unified
Report Generator (URG). The URG generates combined reports for
all types of coverage information. The reports may be viewed through
through an overall summary "dashboard" for the entire design/
testbench.
The format of the text report generated by the URG is enhanced and
different from the text report that used to be generated by the vcs
-cov_report command line options. Any scripts that use these old
command line options now need to be modified to use the URG
options.
The functional coverage database files and their location have been
changed. The coverage database is written to a top-level coverage
directory. By default this directory name is simv.vdb. In general its
name comes from the name of the executable file, with the .vdb
extension. The reporting tool shipped with VCS version 2006.06
cannot read coverage databases generated using previous versions
of VCS. Similarly, the reporting tool shipped with VCS 2006.06
versions cannot read coverage databases generated using VCS
2006.06.
The Coverage Report

During simulation VCS creates a default database directory simv.vdb.
For the code example above, VCS writes the simv.vdb directory in
the current directory. This directory contains the coverage database
and all the information VCS needs to write a coverage report. There
are two types of coverage reports:

1-203
an ASCII text file
an HTML file
The ASCII Text File

The command to instruct VCS to generate a coverage report in ASCII
format is:
urg -dir simv.vdb -format text
The -format text option instructs VCS to generate, text reports

(dashboard.txt, grpinfo.txt, tests.txt and groups.txt) in a separate
directory called urgReport. The ASCII coverage report grpinfo.txt for
the previous code example is as follows:
Group : cg1_SHAPE_0
==========================================================
Group : cg1_SHAPE_0
==========================================================
Score
Weight Goal
100.00 1
100
---------------------------------------------------------Samples for Group : cg1_SHAPE_0
Variable
Expected
Covered
Percent
Goal
Weight
Total
3
3
100.00
cp1
3
3
100.00
100
1
---------------------------------------------------------Summary for variable cp1
Expected Covered Percent
User Defined Bins
3
3
100.00
User Defined Bins for cp1

1-204
Bins name
auto_yellow
auto_blue
auto_red
count at least
2
1
2
1
4
1
The report begins with a summary of the coverage for the

covershapes created. There is 100% coverage, meaning that VCS
saw all possible values for the coverage point(s) in the covergroup.
For coverage point cp1, the report says the following:
The coverage point, in this case variable my_color, reached all its
possible values.
There were no user defined bins.
VCS created bins for the coverage point named auto_blue,

auto_red, and auto_yellow, all named after the members of the
enumerated type colors, blue, red, and yellow.
There were four hits for bin auto_red, this means that during
simulation, there were four clocking events (rising edge on signal
clk) where VCS detected that the value of the variable my_color
was red.
There were two hits for bins auto_blue and auto_yellow.

1-205
The HTML File

The command to instruct VCS to generate a coverage report in HTML
format is:
urg -dir simv.vdb
This command instructs VCS to generate, coverage reports

(dashboard.html, grp0.html, tests.html and groups.html) in the
directory urgReports. The HTML coverage report grp0.html for the
previous code example is as follows:
The report has links to other .html reports. Click on them to see the
appropriate information.
Please refer to the Unified Report generator for more details

1-206
Persistent Storage of Coverage Data and

Post-Processing Tools
Unified Coverage Directory and Database Control
A coverage directory named simv.vdb contains all the testbench
functional coverage data. This is different from previous versions of
VCS, where the coverage database files were stored by default in the
current working directory or the path specified by
coverage_database_filename. For your reference, VCS
associates a logical test name with the coverage data that is
generated by a simulation. VCS assigns a default test name; you can
override this name by using the
coverage_set_test_database_name task.
$coverage_set_test_database_name
("test_name"[,"dir_name"]);
VCS avoids overwriting existing database file names by generating

unique non-clashing test names for consecutive tests.
For example, if the coverage data is to be saved to a test name called
pci_test, and a database with that test name already exists in the
coverage directory simv.vdb, then VCS automatically generates the
new name pci_test_gen1 for the next simulation run. The following
table explains the unique name generation scheme details.

1-207
Table 1-3
Unique Name Generation Scheme

Test Name
Database
pci_test
Database for the first testbench run.
pci_test_gen_1
Database for the second testbench run
pci_test_gen_2
Database for the 3rd testbench run
pci_test_gen_n
Database for the nth testbench run
You can disable this method of ensuring database backup and force
VCS MX to always overwrite an existing coverage database. To do
this, use the following system task::
$coverage_backup_database_file (flag );
The value of flag can be:
OFF for disabling database backup.
ON for enabling database backup.
In order to not save the coverage data to a database file (for example,
if there is a verification error), use the following system task:
$coverage_save_database (flag );
The value of flag can be:
OFF for disabling database backup.
ON for enabling database backup.

1-208
Loading Coverage Data

Both cumulative coverage data and instance-specific coverage data
can be loaded. The loading of coverage data from a previous VCS
run implies that the bin hits from the previous VCS run to this run are
to be added.
Loading Cumulative Coverage Data
The cumulative coverage data can be loaded either for all coverage
groups, or for a specific coverage group. To load the cumulative
coverage data for all coverage groups, use the following syntax:
$coverage_load_cumulative_data("test_name"[, "dir_name"]);
In this task, "dir_name" is optional. If you do not specify a "dir_name",

by default, simv.vdb is taken as the directory containing the database.
The above task directs VCS to find the cumulative coverage data for
all coverage groups found in the specified database file and to load
this data if a coverage group with the appropriate name and definition
exists in this VCS run.
To load the cumulative coverage data for just a single coverage
group, use the following syntax:
$coverage_load_cumulative_cg_data("test_name",
"covergroup_name"[, "dir_name"]);


1-209
In the Example 1-1, below, there is a SystemVerilog class MyClass

with an embedded covergroup covType. VCS finds the cumulative
coverage data for the covergroup MyClass:covType in the database
file Run1 and loads it into the covType embedded coverage group
in MyClass.
Example 1-19
class MyClass;
integer m_e;
covergroup covType @m_e;
cp1 : coverpoint m_e;
endgroup
endclass
...
$coverage_load_cumulative_cg_data("Run1", "MyClass::covType");
Loading Instance Coverage Data

The coverage data can be loaded for a specific coverage instance.
To load the coverage data for a standalone coverage instance, use
the following syntax:
$covgLoadInstFromDbTest
(coverage_instance,"test_name"[, "dir_name"]);

To load the coverage data for an embedded coverage instance, use
the following syntax:
$covgLoadInstFromDbTest
(class_object.cov_group_name,"test_name"[, "dir_name"]);


1-210
The commands above direct VCS to find the coverage data for the
specified instance name in the database, and load it into the coverage
instance.
In the Example 1-2, there is a SystemVerilog class MyClass with an
embedded covergroup covType. Two objects obj1 and obj2 are
instantiated, each with the embedded covergroup covType. VCS
will find the coverage information for the coverage instance
obj1:covType from the database file Run1, and load this coverage
data into the newly instantiated obj1 object. Note that the object
obj2 will not be affected as part of this load operation.
Example 1-20
class MyClass;
integer m_e;
covergroup covType @m_e;
cp1 : coverpoint m_e;
endgroup
endclass
...
MyClass obj1 = new;
$covgLoadInstFromDbTest(obj1,"Run1");
MyClass obj2 = new;
Note:
The compile time or runtime options -cm_dir and -cm_name will
over write the calls to coverage_set_test_database_name
and loading coverage data tasks.
-cm_dir directory_path_name
As a compile-time or runtime option, specifies an alternative name

and location for the default simv.vdb directory, VCS automatically
adds the extension .vdb to the directory name if not specified.

1-211
-cm_name filename
As a compile-time or runtime option, specifies an alternative test

name instead of the default name. The default test name is "test".
VCS NTB (SV) Memory Profiler

The VCS NTB(SV) memory profiler is a Limited Customer availability
(LCA) feature in NTB(SV) and requires a separate license. Please
contact your Synopsys AC for a license key.
VCS has been enhanced to support profiling of memory consumed
by the following dynamic data types:
associative Array
dynamic Array
smart Queue
string
event
class
Use Model
The $vcsmemprof() task can be called from the CLI or the UCLI
interface. The syntax for $vcsmemprof() is as follows:
$vcsmemprof("filename", "w|a+");

1-212
filename
Name of the file where the memory profiler dumps the report.
w | a+
w and a+ designate the mode in which the file is opened. Specify
w for writing and a+ for appending to an existing file.
UCLI Interface
Compile-time
The dynamic memory profiler is enabled only if you specify +dmprof
on the VCS compile-time command line:
vcs -ntb -sverilog +dmprof dut_filename.v testbench_filename.sv \
[-debug | -debug_all]
Note:
Use the -sverilog compile-time option is used when compiling
SystemVerilog code.
Runtime
At runtime, invoke $vcsmemprof() from the UCLI command line
prompt as follows:
simv -ucli //Invokes the ucli prompt
ucli>call {$vcsmemprof("memprof.txt", "w|a+")}
CLI Interface
Compile-time
The dynamic memory profiler is enabled only if you specify +dmprof
on the VCS compile-time command line:

1-213
vcs -ntb -sverilog +dmprof dut_filename.v testbench_filename.sv \

[-debug | -debug_all]
Note:
Use the -sverilog compile-time option is used when compiling
SystemVerilog code.
Runtime
At runtime, when you invoke $vcsmemprof() from the CLI command
line prompt you can make the call to $vcsmemprof() at any point
during the simulation:
simv -s //Invokes the cli prompt
cli_0>$vcsmemprof("memprof.txt", "w|a+")
The memory profiler reports the memory consumed by all the active
instances of the different dynamic data types. As noted above, the
memory profiler report is dumped in the filename specified in the
$vcsmemprof() call.
Incremental Profiling
Each invocation of $vcsmemprof() appends the profiler data to the
user specified file. The time at which the call is made is also reported.
This enables you to narrow down the search for any memory issue.
Only Active Memory Reported

The memory profiler reports only memory actively held at the current
simulation time instant by the dynamic data types.
Consider the following OpenVera program:
task t1() {

1-214
integer arr1[*];
arr1 = new[500];
delay(5);
}
task t2() {
integer arr2[*];
arr2 = new[500];
delay(10);
}
program main {
fork
{
t1();
}
{
t2();
}
join all
}
In this program, if $vcsmemprof() is called between 0 and 4 ns, then

both arr1 and arr2 are active. If the call is made between 5 and
10 ns, then only arr2 is active and after 10 ns, neither is active.
VCS NTB (SV) Dynamic Memory Profile Report

The profile report includes the following sections.
1. Top level view
Reports the total dynamic memory consumed in all the SV
programs and that consumed in all the SV modules in the
system.
2. Module View
Reports the dynamic memory consumed in each SV module in
the system.
1-215
3. Program View
Reports the dynamic memory consumed in each SV program in
the system.
4. Program To Construct View
a. Task-Function-Thread section
Reports the total dynamic memory in each active task, function
and thread in this module/program.
b. Class Section
Reports the total dynamic memory consumed in each class in
this module/program.
c. Dynamic data Section
Reports the total memory consumed in each of dynamic
testbench data types - associative arrays, dynamic arrays,
queues, events, strings, in the module/program.
5. Module To Construct View:
Same as Program To Construct View.

1-216
The Direct Programming Interface (DPI)

The Direct Programming Interface (DPI) is a Limited Customer
availability (LCA) feature in NTB (SV) and requires a separate license.
Please contact your Synopsys AC for a license key.
The DPI is an interface between SystemVerilog and another
language such as C. Using DPI you can directly call a function in the
other language.
Note:
Currently DPI is implemented only for the C/C++ languages.
Import Functions - SystemVerilog calling C/C++

The import task/functions are C/C++ functions that can be called
from the SystemVerilog code. You must declare them before you can
use them. After you declare an import function, you can call it like any
procedural statement in your SystemVerilog code.
Import tasks and functions can have 0 or more formal input, output,
and inout arguments. Import functions can either return a value or be
defined as void, while import tasks never return a value.
Import functions can have the properties context or pure while the
import tasks can have the property context only.
Syntax:
Declaration :
import "DPI" [cname =] [pure] function type name (args);
import "DPI" [cname =] [pure][context] task name (args);

1-217
Example:
import "DPI" context task c_task(input int addr);
program top;
initial c_task(1000);
endprogram
#include <svdpi.h>
void c_task(int addr) {
...
}
vcs -sverilog top.sv c_task.c
Export Functions- C/C++ Calling SystemVerilog

The export tasks/functions are SystemVerilog tasks/functions that
can be called from C/C++ languages. You must declare them before
you can use them. Export function declarations are allowed only in
the scope in which the function is defined and only one declaration
per function is allowed in a given scope.
The export functions and tasks have the same restrictions on
argument types and return values as the import functions.
Syntax:
Declaration :
export "DPI" [cname =] function name (args);
export "DPI" [cname =] task name (args);

1-218
Example:
import "DPI" task c_test(int addr);
export "DPI" task sv_add;
function int sv_add(input int a, input int b);
sv_add = a+b;
endtask
#include <svdpi.h>
extern void sv_add(int, int);
void c_task(int addr) {
...
sv_add(addr, 10);
...
}
vcs -sverilog top.sv c_task.c
Note:
You can export all SystemVerilog functions except class member
functions.
Limitations
In the current implementation of the DPI, import and export functions
are supported with some restrictions on the following data types:
Unpacked structs/unions, byte, shortint, longint, and shortreal.
Unpacked arrays of the above types
Include Files
The SystemVerilog 3.1a LRM defines the C layer for the DPI. The
C-layer of the DPI provides two include files:

1-219
The main include file, $VCS_HOME/lib/svdpi.h, is defined in the

SystemVerilog 3.1 standard and defines the canonical
representation, all basic types, and all interface functions.The file
also provides function headers and defines a number of helper
macros and constants. See section D.9.1 of the SystemVerilog
3.1 LRM.
The following functions are not implemented:
svGetNameFromScope
svAckDisabledState
svGetCallerInfo
svIsDisabledState
The second include file, $VCS_HOME/lib/svdpi_src.h, defines

only the actual representation of packed arrays and its contents
are unique to VCS.

1-220
Time Consuming Blocking Tasks

When SystemVerilog calls a C import task, this task can then call
blocking (context) SystemVerilog tasks. This is particularly useful if
the C code must call a read/write task in a SystemVerilog BFM
model.
Note that the C task must be initially called from SystemVerilog using
an import task call. For example, the following C code contains a test
that calls the SystemVerilog apb_write task as needed to issue
writes on an APB bus.
#include<svdpi.h>
extern void abp_write(int, int);
void c_test(int base) {
int addr, data;
for(addr=base; addr<base+5; addr++) {
data = addr * 100;
apb_write(addr, data);
printf("C_TEST: APB_Write : addr = 0x%8x, data = 0x%8x\n",
addr, data);
}
}

1-221
SystemVerilog File
This SV code calls C_test(), which then calls the blocking APB_Write
task in SystemVerilog. The APB_Write task has a simple semaphore
to ensure unique access.
import "DPI" context task c_test(input int base_addr);
program top;
semaphore bus_sem = new(1);
export "DPI" task apb_write;
task apb_write(input int addr, data);
bus_sem.get(1);
#10 $display("VLOG : APB Write : Addr = %x, Data = %x
", addr, data);
#10 ifc.addr <= addr;
#10 ifc.data <= data;
bus_sem.put(1);
endtask
initial begin
fork
c_test(32'h1000);
c_test(32'h2000);
join
end
endprogram
The VCS command line compiles the files.

vcs -sverilog top.sv c_test.c -R

1-222

SVTB

Uploaded by

Copyright:

Available Formats

SVTB

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SVTB

Uploaded by

Copyright:

Available Formats

What are the steps to analyze SystemVerilog, Verilog and VHDL files?

What are the steps to analyze SystemVerilog, Verilog and VHDL files?

What options can be used when compiling and simulating SystemVerilog testbench constructs?

What options can be used when compiling and simulating SystemVerilog testbench constructs?

1

SystemVerilog Testbench Constructs

The new version of VCS has implemented some of the SystemVerilog

Enabling Use of SystemVerilog Testbench Constructs

SystemVerilog Testbench Constructs

VCS MX Flow for SVTB

As the use of vlogan indicates, SystemVerilog files are treated like

Combined UUM Flow

Analyze all Verilog source files.

Analyze all VHDL source files in bottom-up order.

Run the simv.

SystemVerilog Testbench Constructs

Use vcs during compile to create the simulation executable:

Finally, run the simulation:

SystemVerilog Testbench Constructs

Finally, run the simulation:

-sverilog tb.sv tb_util.sv

Use vcs during the elaboration step to create the simulation

Finally, run the simulation:

Options For Compiling and Simulating SystemVerilog

SystemVerilog Testbench Constructs

SystemVerilog Testbench Constructs

SystemVerilog Testbench Constructs

Compile Time or Runtime Options

As a compile-time or runtime option, specifies an alternative name

As a compile-time or runtime option, specifies an alternative test

The string Data Type

String Manipulation Methods

SystemVerilog Testbench Constructs

If variable string_name has a value of xyz, then this method returns

The $display system tasks display the following:

SystemVerilog Testbench Constructs

The $display system tasks display the following:

SystemVerilog Testbench Constructs

$display("string1 matches string2");

The $display system tasks display the following:

The $display system task displays the following:

String Conversion Methods

atoi( ) atohex( ) atooct( ) and atobin( )

The $monitor system task display the following:

SystemVerilog Testbench Constructs

The $display system task displays:

The $display system tasks display:

realtoa(arg) returns the ASCII real representation of the arg.

SystemVerilog Testbench Constructs

The output of this program is:

Predefined String Methods

Here, the argument must be a string.

SystemVerilog Testbench Constructs

The match() method processes a regular expression pattern match.

Here, the pattern must be a regular Perl expression.

This example assigns the value 1 to integer i because the pattern

The following example illustrates the usage of the prematch() class

This example assigns the value SystemVerilog to string str1.