Openvera/Rvm To Systemverilog/Vmm Conversion: How To Avoid Death by A Thousand Cuts'

OpenVera/RVM to SystemVerilog/VMM Conversion:
How to Avoid ‘Death by a thousand cuts’
Venkata Chintapalli
Dan Steinberg
Integrated Device Technology
Venkata.Chintapalli@idt.com
Dan.Steinberg@idt.com
ABSTRACT
SystemVerilog (SV) has emerged as the leading Hardware Verification Language (HVL) for
verifying complex digital logic. On top of SV, is the popular Verification Methodology Manual
(VMM), which consists of methodology guidelines and a class library to simplify and
standardize the creation of verification infrastructure. Given the lure of SV, there is an
understandable desire to port existing testbenches written in other HVLs to SV. Since a large
portion of the testbench features in SV were donated from the OpenVera (OV) language, and
since VMM is based upon the earlier Reference Verification Methodology (RVM), it would
seem that porting an environment from OV/RVM to SV/VMM would be a simple endeavor. In
this paper, we set out to test this hypothesis by attempting such a conversion using proven
testbench and RTL code as a starting point.
Although OV and SV are similar, we quickly discovered that there are a multitude of syntactical
differences, and hence the feeling of "Death by a thousand cuts". For the purpose of this
exercise, and with the goal of helping others in similar situations, we have developed a
comprehensive Perl script to simplify the conversion process. In this paper, we present our
overall experience in successfully converting our testbench from OV/RVM to SV/VMM. We
describe the aspects of the conversion process that are automatically handled by our script as
well as those that must be handled manually. We also highlight potential pitfalls and
workarounds that we encountered during the conversion process.
Table of Contents
1. Introduction......................................................................................................................... 4
2. Motivation........................................................................................................................... 4
3. Project scope & tools .......................................................................................................... 4
4. Conversion details............................................................................................................... 5
4.1 Easily scriptable changes .................................................................................................... 5
4.2 Tougher-but-scriptable changes.......................................................................................... 6
4.3 Manual changes .................................................................................................................. 8
4.3.1 Shadow variables ............................................................................................................ 9
4.3.2 Default constraints .......................................................................................................... 9
4.3.3 Hierarchical references ................................................................................................... 9
4.3.4 Delay elements within functions..................................................................................... 9
4.3.5 Dynamic array dynamic_size attribute ......................................................................... 10
4.3.6 Program block............................................................................................................... 10
4.3.7 Interfaces....................................................................................................................... 10
4.3.8 Formatting with rvm_log .............................................................................................. 11
4.3.9 RVM Notification rvm_notify.wait_for_t() method ..................................................... 11
4.3.10 Miscellaneous changes ................................................................................................. 12
5. Automating the conversion process .................................................................................. 13
6. Potential Pitfalls................................................................................................................ 16
6.1.1 Complex pre-processor directives ................................................................................ 16
6.1.2 SV Function/Task arguments direction is sticky .......................................................... 17
6.1.3 Miscellaneous pitfalls ................................................................................................... 17
7. Conclusions....................................................................................................................... 17
8. References......................................................................................................................... 19
9. Appendix........................................................................................................................... 20
SNUG San Jose 2008 2 OpenVera/RVM to SV/VMM Conversion

List of Tables
Table 1: Easily scriptable example ................................................................................................. 6
Table 2: Tougher-but-scriptable example -- curly braces............................................................... 7
Table 3: Tougher-but-scriptable example -- constraints................................................................. 7
Table 4: Tougher-but-scriptable example -- defines, enums, and foreach ..................................... 8
Table 5: Manual example -- shadow variables ............................................................................... 9
Table 6: Manual example -- dynamic_size attribute .................................................................... 10
Table 7: Manual example -- Interfaces ......................................................................................... 11
Table 8: Manual example -- rvm_log format................................................................................ 11
Table 9: Manual example -- RVM notification and status methods............................................. 12
Table 10: Complex pre-processor directives ................................................................................ 17
Table 11: OV to SV Conversions ................................................................................................. 20
Table 12: RVM to VMM Conversions ......................................................................................... 26

1. Introduction
The methodologies, tools, and languages are continuously evolving in the field of functional
verification. Probably the most dramatic change in this field within the last several years has
been the introduction of the SystemVerilog (SV) language (standardized as IEEE 1800-2005).
SV is a superset of Verilog2001. It is a powerful object-orientated High-level Verification
Language (HVL) that, among other things, adds syntax to enable constrained-random testbench
development, as well as coverage-driven verification and assertion-based verification.
OpenVera (OV) is also an HVL that preceded SV. In fact, OV was donated to the committee
that developed SV, and so the two languages have very similar capabilities. VCS natively
supports OV simulations, and may be referred to as Native Test Bench (NTB).
Regardless of the type of design that is being verified, there are a lot of common tasks that need
to be performed. For this reason, the Reference Verification Methodology (RVM) was
developed by Synopsys. RVM consists of an extremely useful class library as well as a long list
of guidelines. Together, these lay the foundation for rapidly generating scalable and reusable
verification environments. The RVM framework is designed to work with OV.
The Verification Methodology Manual (VMM) was also developed by Synopsys. VMM also
consists of a class library and a set of guidelines that very much follow their RVM predecessor.
The main difference between the two is that VMM is designed to work with SV.
In this paper, we will explore what it takes to convert a testbench from OV/RVM to SV/VMM.
2. Motivation
A question that one may ask is, “Why convert an existing OV/RVM platform to SV/VMM”?
This is a reasonable question to ask, given that Synopsys continues to support the OV language
within VCS. In fact, it is our understanding that VCS supports co-simulation of OV with SV.
Accordingly, converting an existing platform in the immediate term is not necessarily critical.
When looking at the longer term view, however, it appears that such a conversion is quite
desirable. There are a number of reasons for this. The entire industry is moving to SV, and
VMM has been widely adopted. By switching over to the latest and greatest industry standards,
one can take advantage of the best-in-class tools and Verification IP (VIP). Although it’s not
necessarily the case now, in the long run SV environments should interoperate nicely among the
various tool vendors. Finally, we predict that the majority of new testbench development work
will gradually shift to SV, and OV development will eventually be phased out.
3. Project scope & tools

Given the motivation above, we decided to define the scope of our project. The plan was to
convert an existing OV/RVM testbench to SV/VMM. The goal was to be able to compile and
run a sample test case in the ported environment. For this case study, we decided to use the
“PCIe Stack RVM” testbench. This is a homegrown testbench that has been developed to verify
our PCI Express protocol stack. Since the Device Under Test (DUT), and the testbench have

already been proven, and are considered “golden”, this makes for an excellent testcase. The
testbench is composed of over 24,000 lines of OV/RVM code.
When we started planning out this task, we looked for existing tools that could help us get the
job done. Unfortunately, Synopsys doesn’t provide any such tool, although they did provide an
SV/OV language comparison document that helped. In our search, we only found one tool that
claimed to automate the conversion process. This was a commercial tool that would cost real
money. We were pretty sure that management would not be willing to pay for such a tool, so
this was deemed a non-option. Accordingly, we never evaluated this tool. Instead, we decided
that we would develop our own script to automate the conversion process, and use this script on
our own code to see how well it worked.
Given that Synopsys donated the OV language constructs to SV, and given that VMM is based
on RVM, we had hoped the conversion process would be trivial - say, something as easy as
search and replace ‘rvm’ with ‘vmm’. We decided to test out this hypothesis for ourselves.
4. Conversion details
We have categorized the types of conversions required from OV/RVM to SV/VMM into three
main categories. They are: easily scriptable changes, tougher-but-scriptable changes, and
manual changes. The types of conversions done in each of these categories are explained in
detail below. In addition, a table listing all the OV/RVM to SV/VMM conversions is listed in
the appendix. It contains a comprehensive list of conversions performed by the script and also
lists changes which are not practical to automate, and require manual modifications by the user.
Comments embedded in source code can be extremely valuable, especially when dealing with
inherited code. Source code that lacks embedded comments can lead to an enormous amount of
frustration. Accordingly, in developing our automated script, we felt it was critical to not lose
the existing comments during the conversion process. Currently, the script extracts all the
single-line (i.e., //) and multi-line (i.e., /* */) comments and saves them before performing any
conversions. The comments are transferred to the converted code in their exact location after the
conversion is complete.
4.1 Easily scriptable changes

Easily scriptable changes, as the name suggests, are conversions that are simple to automate, and
are automatically performed by the script. Most of these changes can be achieved with a simple
search and replace algorithm as shown the code example below. Some of the easily scriptable
changes include the following:
• File name suffix changes from .vr/.vrh Æ .sv/.svh
• Pre-processor directives, such as #include/#define Æ ìnclude/`define
• Keyword changes, such as: integer/bit Æ int/logic
• RVM to VMM macro changes, such as rvm_note Æ `vmm_note, etc.
• RVM to VMM Variable name changes, such as object_id Æ data_id, and
stop_after_n_errs Æ stop_after_n_errors
• RVM ‘_t’ suffix notation for blocking methods has been completely removed in VMM,
e.g. start_t/stop_t Æ start/stop

OV/RVM SV/VMM
#ifndef SOME_DEFINE ìfndef SOME_DEFINE
#define SOME_DEFINE `define SOME_DEFINE
#include "some_include.vh" ìnclude "some_include.svh"

/* /*
* Multi-Line Comment * Multi-Line Comment
*/ */
rvm_log log; // Single Line Comment vmm_log log; // Single Line Comment
integer i; int i;
i = urandom_range(1,100); i = $urandom_range(1,100);
rvm_verbose(log, psprintf("i=%0d",i)); `vmm_verbose(log, $psprintf("i=%0d",i));
#endif èndif
Table 1: Easily scriptable example
4.2 Tougher-but-scriptable changes

Tougher-but-scriptable changes, as the name suggests, are conversions that can be automated but
cannot be accomplished with a simple search and replace algorithm. Instead, such changes
require more complex analysis and processing of the source code. More details and several
examples are presented below.
One of the key syntactical differences between OV and SV is in the way scopes are coded. OV
uses open and close curly braces ‘{‘ and ‘}’ for most constructs. These are used for constructs
such as classes, tasks, functions, constraints, program blocks, if-else, for loops, etc. In SV,
however, these constructs follow along the lines of the traditional Verilog syntax. Instead of
curly braces, SV employs semicolons and begin/end keywords. For example, in SV the first
open curly brace of a class definition is changed to a semicolon, and the final curly brace of the
class is changed to the endclass keyword. A colon and an optional class identifier may be placed
after the endclass keyword. In order to make these types of changes, the script has to have the
intelligence to diligently track the current scope and level of nested indentation. To make things
even trickier, SV retains the usage of curly braces for constraint and concatenation constructs, so
clearly the script cannot blindly convert curly braces to begin and end. An example of this is
shown below.
One additional comment that should be made in order to fully understand the example below is
that constructors (i.e., new() class methods) in OV may be defined as tasks, whereas in SV they
must be defined as functions. The script automatically converts such tasks to functions.
OV/RVM SV/VMM

class my_xactor extends rvm_xactor { class my_xactor extends vmm_xactor;
integer min; int min;
integer max; int max;
rand integer val; rand int val;
rand bit choose_max; rand logic choose_max;
constraint c1 { constraint c1 {
if (choose_max) { if (choose_max) {
val == max; val == max;
} }
else { else {
val <= max; val <= max;
val >= min; val >= min;
} }
} }
// Constructor // Constructor
task new () { function new ();
min = 0; min = 0;
max = 100; max = 100;
} endfunction : new
} endclass : my_xactor
Table 2: Tougher-but-scriptable example -- curly braces

Even though the open and close curly braces for constraint blocks are unchanged from OV to
SV, there are still other constraint-related modifications that need to be handled. When
constraint ranges are used, the script must identify and place them within open and close square
brackets ‘[‘ and ‘]’. Constraint ranges may be defined using numbers, variables, hierarchical
references, or any combination of all three. Apart from constraint ranges, negated set
membership operator (! ... inside) and other conversions need to be handled by the script as
shown below.
OV/RVM SV/VMM
class my_xactor extends rvm_xactor { class my_xactor extends vmm_xactor;
//... //...
constraint c2 { constraint c2 {
{choose_max == 1'b1} => {val == max}; {choose_max == 1'b1} -> {val == max};
{choose_max == 1'b0} => {val in {min:(max-1)}}; {choose_max == 1'b0} -> {val inside {[min:(max-1)]}};
val !in {13,19}; !val inside {13,19};
val dist {min:/33, val dist {min:/33,
(min+1):(max-1):/33, [(min+1):(max-1)]:/33,
max:/33}; max:/33};
} }
} endclass : my_xactor
Table 3: Tougher-but-scriptable example -- constraints
Defined macros (e.g., #define X) in OV are slightly more straight forward than in SV. In SV,
macros are defined using a backtick (`), e.g. `define X. When a defined macro is later used, a

backtick must also be added to the start of the macro name. In OV, this extra step is not
necessary. When converting from OV to SV, the script must keep track of all previously defined
macros. Whenever it encounters a matching string, it must add the backtick.
Frequently, it’s desirable to define all macros in one file, and use them in several other files. In
this case, the order that the files are processed can become problematic. That is, if a macro is
encountered while processing one file, and later the macro definition is processed in a separate
file, this could result in the script not adding the required backtick. To avoid this problem, the
script reads in all input source files and creates a master list of all defined macros. Only then,
does the script begin to process each file in detail. In this manner, the order the files are read in
becomes irrelevant, and the conversion can be performed successfully.
Enumerated types have also changed slightly between OV and SV. In SV, in addition to adding
the typedef keyword, the enumerated name is moved to after the closing curly brace ‘}’. Another
thing that has changed slightly is the syntax of the foreach loops. Below is an example that
demonstrates the conversion of macro names, enumerated types, and the foreach construct.
OV/RVM SV/VMM
#define MAX_PKTS 100 `define MAX_PKTS 100
#define MAX_PKT_SIZE 1024 `define MAX_PKT_SIZE 1024
#define ARR_SIZE (MAX_PKTS*MAX_PKT_SIZE) `define ARR_SIZE (`MAX_PKTS*`MAX_PKT_SIZE)
enum bool { typedef enum {

FALSE=0, FALSE=0,
TRUE=1}; TRUE=1} bool;
task my_task (bool process_data, var integer data,) { task my_task (bool process_data, ref int data);
integer i, j, pkt_data[MAX_PKTS][MAX_PKT_SIZE]; int i, j, pkt_data[`MAX_PKTS][`MAX_PKT_SIZE];
if (process_data == TRUE) { if (process_data == TRUE) begin

// Process data using 'for' loops // Process data using 'for' loops
for (i=0;i<MAX_PKTS;i++) { for (i=0;i<`MAX_PKTS;i++) begin
for (j=0;j<MAX_PKT_SIZE;j++) { for (j=0;j<`MAX_PKT_SIZE;j++) begin
data = pkt_data[i][j]; data = pkt_data[i][j];
} end
} end
// Process data using 'foreach' loops // Process data using 'foreach' loops
foreach (pkt_data,i,*) { foreach (pkt_data[i,]) begin
foreach (pkt_data,*,j) { foreach (pkt_data[,j]) begin
data = pkt_data[i][j]; data = pkt_data[i][j];
} end
} end
} end
} endtask : my_task
Table 4: Tougher-but-scriptable example -- defines, enums, and foreach

4.3 Manual changes
Some aspects of the OV/RVM to SV/VMM conversion are extremely difficult or simply
impossible to automate. To properly convert these instances, a significant number of manual

changes by the user are required to get the environment to compile and run successfully.
Whenever the script detects that a manual change is required, it places an informational
<FIXME> message to inform the user. The following sections describe different types of
manual changes detected by the script and how to fix them.
4.3.1 Shadow variables

Shadow variables in OV are used to avoid race conditions when multiple child processes want to
use the parent’s variables independently. Shadow variables are not supported in SV, however
the desired result can be achieved using local variables and the keyword automatic. The code
snippet below demonstrates how to achieve equivalent functionality in SV without shadow
variables
OV/RVM SV/VMM
shadow integer i; int i;
for (i=0; i<MAX_NUM_PORTS;i++) { for (i=0; i<`MAX_NUM_PORTS;i++) begin
fork fork
{ automatic int local_copy_of_i = i;
my_monitor{i); begin
} my_monitor{local_copy_of_i);
join none end
} join_none
end
Table 5: Manual example -- shadow variables
4.3.2 Default constraints

In OV, you can specify default constraints for any particular random variable. Such constraints
are applied if no other non-default constraints are used for that variable. Default constraints are
not supported in the SV LRM, but VCS does support default constraints for SV. There are a
couple ways to achieve similar functionality and at the same time adhere to the SV LRM. One
way is to override the constraint in a derived class with same constraint name. Another
alternative is to disable the constraints using class’s built-in constraint_mode() method to turn
on/off the constraints.
4.3.3 Hierarchical references

In OV, hierarchical references are used to access variables from one hierarchy to another by
referring to variables from the top level object reference. In SV you need to use $root to access
elements outside of the top level module. At the time of writing this paper $root does not appear
to be very well supported in the current release version of VCS. As a work-around, we achieved
the same functionality by passing the top level handle to all the constructors which need to
access the variables from the top level reference.
4.3.4 Delay elements within functions

Delay elements which advance simulation (e.g., @(posedge my_intf.clk)) time are OK in OV
functions. In SV, however, functions are not allowed to advance time. OV functions which

contain calls to tasks or delay elements must be converted to SV tasks. Since tasks do not have
return values, the workaround is to pass the return value through an argument passed by
reference (type ref).
4.3.5 Dynamic array dynamic_size attribute

In OV when you pack a dynamic array (e.g., representing a packet payload), you also need to
specify the size of the array, using the dynamic_size attribute. In SV you need to specify a
constraint to achieve the same purpose as shown below.
OV/RVM SV/VMM
class pcie_tlp { class pcie_tlp;
rand int payload_len; rand int payload_len;
rand bit [31:0] payload [] dynamic_size payload_len; rand bit [31:0] payload [];
… …
} constraint payload_size {
payload.size == payload_len;
}
}
endclass : pcie_tlp
Table 6: Manual example -- dynamic_size attribute
4.3.6 Program block

The script converts the program keyword to program automatic to make sure it uses automatic
storage. This mechanism can avoid race conditions that used to be prevalent in Verilog tasks,
due to static storage. In SV, procedural code requires ‘initial begin … end’ or an always block.
In OV, procedural code could simply “float” inside the program block without the need for a
new scope. Accordingly, the script generates an informational <FIXME> message whenever it
detects a program block.
4.3.7 Interfaces
Of all manual changes, interfaces require the most significant changes when converting from OV
to SV. OV uses interfaces, ports and binds to connect to DUT which has been replaced with
flexible interfaces in SV. Although most changes here are manual, the script does help out
somewhat when converting the interface from OV to SV as shown below. In SV, one needs to
instantiate the interface at the top level module and pass the interface instance reference both to
the DUT and testbench. There is no longer a need to use dynamic binding using the ‘$’ sign
(e.g., my_intf.$my_signal). Instead, one may refer to all signals in the same way one refers to
variables inside a class using the object reference (e.g., my_intf.my_signal).
OV/RVM SV/VMM
interface my_intf { interface my_port;
input clk CLOCK hdl_node "top.clk"; logic clk;
input data_valid IN_EDGE IN_SKEW hdl_node "top.dut.data_valid"; logic data_valid;
output [31:0]data OUT_EDGE OUT_SKEW hdl_node "top.dut.data[31:0]"; logic [31:0] data;
// ... // ...

} endinterface : my_port
port my_port {
clk;
data_valid;
data;
}
bind my_port port0 {
clk my_intf.clk;
data_valid my_intf.data_valid;
data my_intf.data;
}
Table 7: Manual example -- Interfaces
4.3.8 Formatting with rvm_log

Formatting logs in RVM is performed by simply passing the format and prefix strings to the
format() method. In VMM, however, formatting must be done by passing an object of a class
that is extended from vmm_log_format to the set_format() method, as shown below.
OV/RVM SV/VMM
Program test { program automatic test;
… …
string log_format = "[%t] %N (%T): %M"; intial begin
string log_prefix = " "; rvm_log log = new("Test.vr","program");
rvm_log log = new("Test.vr","program"); my_log_format fmt = new();
… //pass class object extending from vmm_log_fomat
//directly pass the format and prefix string log.set_format(fmt);
log.format(string fmt, string prefix); …
… end
} endprogram: test
--------------------------------------------------------------------
class my_log_format extends vmm_log_format;
virtual function string format_msg(string name,
string instance,
string msg_type,
string severity,
ref string lines[$]);
$sformat(format_msg, "[%0t] %s (%s): ",
$time, name, msg_type);
foreach (lines [l] )
$sformat(format_msg, "%s %s", format_msg, lines[l]);
endfunction : format_msg
endclass : my_log_format
Table 8: Manual example -- rvm_log format
4.3.9 RVM Notification rvm_notify.wait_for_t() method

In RVM, the rvm_notify.wait_for_t() returns a status descriptor object. In VMM, however, the
equivalent method wait_for() does not return any status. Instead, one must use the
vmm_notify::status() function to retrieve any status descriptor attached to the indicated
notification, as shown below.

OV/RVM SV/VMM
// Block on event_id AND get status descriptor object // Wait for event
status_desc =xyz.notify.wait_for_t(event_id); status_desc =xyz.notify.wait_for_t(event_id);
// Get status descriptor object
status_desc = xyz.notify.status(event_id);
Table 9: Manual example -- RVM notification and status methods
4.3.10 Miscellaneous changes

Calling HDL tasks
OV uses the hdl_task keyword to connect to Verilog HDL tasks. Since Verilog tasks are a
subset of SV there is no need for the hdl_task keyword. In SV the HDL tasks can be called by
hierarchical reference.
Function/Tasks declarations without body

Function/Task declarations that have no body compile and run just fine in OV. In SV, however,
they result in compilation errors. To overcome these errors, one must place an empty body
‘begin end’ for all such functions/tasks.
Hierarchical reference to enumerations

OV supports hierarchical reference to enumerations. A simple example is:
this.notify.ONE_BLAST_TRIGGER. This is not supported in SV. Rather, one must use the
scope resolution operator (::) to refer to such enumerations, as in vmm_notify::BLAST.
Array initializations
OV supports initializing only a portion of the declared array. In SV, array initializations must
exactly match the declared array size.
Semaphores
OV uses static integers with alloc(), semaphore_get() and semaphore_put() methods to create
and use semaphores. SV, however, contains a built-in ‘sempahore’ class that provides get() and
put() methods that support mutual exclusion. Please refer to the appendix for an example.
Associative array ‘assoc_index’ handling

OV uses assoc_index to get indexes of elements inside an associative array. SV has different
types of built-in methods for handling associative arrays as compared to OV. Please refer to the
appendix for an example.
String methods
OV has much richer capabilities to process strings than SV. In OV, for example, we made heavy
use of the function string method match() to perform regular expression matching and backref()
to return matched patterns. SV has no such built-in equivalent functions. VMM supports similar
functionality in SV using DPI and these functions are called vmm_str_match() and
vmm_str_backref(). The regular expressions syntax between these string methods is slightly

different. OV supports Perl like regular expressions whereas VMM supports POSIX extended
regular expressions.
RVM callbacks
RVM uses register_callback(), shown below, to register any instances of callbacks extensions.
This method has been deprecated in favor of the append_callback() and prepend_callback()
methods. In converting from register_callback() to append_callback() one needs only to remove
the second argument in register_callback(), which is no longer needed. The declarations for
RVM and VMM are shown below:
RVM: virtual task register_callback(rvm_log_callbacks cb, bit prepend=0);
VMM: virtual function void append_callback(vmm_log_callbacks cb);
RVM reset_xactor() input

In RVM, the reset_xactor() method used to take an input argument of type integer. This has
been changed to use the enumerated type reset_e as shown below:
virtual task reset_xactor(integer rst_type); Æ virtual task reset_xactor(reset_e rst_type);
RVM next_transaction_t() method

The RVM method next_transaction_t() is deprecated. The RVM to VMM conversion that is
required to make this work properly is shown below:
cast_assign(pkt, this. next_transaction_t(this.channel)); Æ this.channel.get(pkt)
5. Automating the conversion process

The script that we have developed to automate the conversion process is called vera2sv. To
execute the script, simply enter the following command:
vera2sv <input file(s)>
The list of input OV files may contain wildcards, as in the following example:
vera2sv *.vr *.vrh
The script will automatically parse the input OV files, and generate the corresponding SV files.
It is advisable to convert source and header files at the same time so that the script will be aware
of all macro names defined in header files Currently, the script is able to detect and/or fix over
100 constructs. A complete list is located in the appendix. For constructs that the script can
detect, but are too complex to fix, a <FIXME> string is added to the output SV code. After the
conversion is complete, the user can easily search for this string and implement the manual
changes as needed.
The script automatically displays a detailed list of the issues it has detected and/or fixed, and
how many such instances it has encountered. This display is generated per-file (assuming
multiple files are processed) as well as on an overall basis. A sample output from our test case is
shown below.

================
Overall Stats:
================
--- Simple Search & Replace ---

Fixed 956 instance(s) of 'integer' -> 'int'
Fixed 1019 instance(s) of 'psprintf' -> '$psprintf'
Fixed 55 instance(s) of 'printf' -> '$write'
Fixed 31 instance(s) of 'fprintf' -> '$fwrite'
Fixed 8 instance(s) of 'fopen' -> '$fopen'
Fixed 2 instance(s) of 'feof' -> '$feof'
Fixed 2 instance(s) of 'exit' -> '$exit'
Fixed 181 instance(s) of '#ifdef' -> 'ìfdef'
Fixed 15 instance(s) of '#ifndef' -> 'ìfndef'
Fixed 19 instance(s) of '#else' -> 'èlse'
Fixed 196 instance(s) of '#endif' -> 'èndif'
Fixed 622 instance(s) of '#define' -> '`define'
Fixed 44 instance(s) of '#include' -> 'ìnclude'
Fixed 26 instance(s) of 'rvm_log' -> 'vmm_log'
Fixed 92 instance(s) of 'rvm_error' -> '`vmm_error'
Fixed 143 instance(s) of 'rvm_fatal' -> '`vmm_fatal'
Fixed 626 instance(s) of 'rvm_note' -> '`vmm_note'
Fixed 378 instance(s) of 'rvm_verbose' -> '`vmm_verbose'
Fixed 1 instance(s) of 'rvm_env' -> 'vmm_env'
Fixed 16 instance(s) of 'rvm_data' -> 'vmm_data'
Fixed 8 instance(s) of 'rvm_xactor' -> 'vmm_xactor'
Fixed 6 instance(s) of 'rvm_notify' -> 'vmm_notify'
Fixed 2 instance(s) of 'rvm_channel' -> '`vmm_channel'
Fixed 4 instance(s) of 'rvm_scheduler' -> 'vmm_scheduler'
Fixed 7 instance(s) of 'rvm_xactor_callbacks' -> 'vmm_xactor_callbacks'
Fixed 4 instance(s) of 'rvm_OO_callback' -> '`vmm_callback'
Fixed 2 instance(s) of 'program' -> 'program automatic'
Fixed 38 instance(s) of 'cast_assign' -> '$cast'
Fixed 57 instance(s) of 'var' -> 'ref'
Fixed 668 instance(s) of 'bit' -> 'logic'
Fixed 22 instance(s) of 'urandom_range' -> '$urandom_range'
Fixed 1 instance(s) of 'random' -> '$random'
Fixed 56 instance(s) of 'object_id' -> 'data_id'
Fixed 20 instance(s) of 'main_t' -> 'main'
Fixed 4 instance(s) of 'wait_if_stopped_t' -> 'wait_if_stopped'
Fixed 1 instance(s) of 'run_t' -> 'run'
Fixed 3 instance(s) of 'put_t' -> 'put'
Fixed 1 instance(s) of 'wait_for_t' -> 'wait_for'
Fixed 2 instance(s) of 'wait_for_end_t' -> 'wait_for_end'
Fixed 2 instance(s) of 'cfg_dut_t' -> 'cfg_dut'
Fixed 1 instance(s) of 'reset_dut_t' -> 'reset_dut'

Fixed 3 instance(s) of 'start_t' -> 'start'
Fixed 3 instance(s) of 'stop_t' -> 'stop'
Fixed 2 instance(s) of 'cleanup_t' -> 'cleanup'
Fixed 34 instance(s) of 'terminate' -> 'disable fork'
Fixed 1 instance(s) of 'stop_after_n_errs' -> 'stop_after_n_errors'
--- Procedural Constructs ---

Fixed 35 instance(s) of 'class'
Fixed 1 instance(s) of 'program'
Fixed 169 instance(s) of 'task'
Fixed 86 instance(s) of 'function'
Fixed 307 instance(s) of 'for'
Fixed 100 instance(s) of 'foreach'
Fixed 2 instance(s) of 'repeat {'
Fixed 91 instance(s) of 'while'
Fixed 100 instance(s) of 'case'
Fixed 874 instance(s) of 'if'
Fixed 328 instance(s) of 'else'
Fixed 245 instance(s) of generic scope: '{ ... }' -> 'begin ... end'
--- Misc ---

Fixed 1685 instance(s) of define names prefixed with `
Fixed 29 instance(s) of 'enum XYZ {A,B,C};' -> 'typedef enum {A,B,C} XYZ;'
Fixed 41 instance(s) of 'task new' -> 'function new'
Fixed 2 instance(s) of 'rvm'->'vmm' (not caught w/prior string searches)
Fixed 8 instance(s) of 'get_time(LO)' -> '$time'
Fixed 24 instance(s) of associative arrays [] -> [*]
Fixed 39 instance(s) of dynamic arrays [*] -> []
Fixed 12 instance(s) of 'include "rvm_std_lib.vrh"' -> 'include "vmm.sv"'
Removed 12 instance(s) of 'include "vera_defines.vrh"'
Fixed 12 instance(s) of include <xyz> -> include "xyz"
Fixed 19 instance(s) of include "xyz.vr" -> include "xyz.sv"
Fixed 1 instance(s) of include "xyz.vrh" -> include "xyz.svh"
Fixed 48 instance(s) of constraint ranges (added [] around ranges)
Fixed 8 instance(s) of constraint ranges within inside{...} (added [] around ranges)
Fixed 86 instance(s) of constraint: x in {...} -> x inside {...}
Fixed 17 instance(s) of constraint: x !in {...} -> !x inside {...}
Fixed 192 instance(s) of constraint implication operator: '=>' becomes '->'
Fixed 24 instance(s) of constraint_mode(ON/OFF, "constraint_name") ->
"constraint_name".constraint_mode(1/0);
Fixed 4 instance(s) of (Hierarchial) xyz.constraint_mode(ON/OFF, "constraint_name") ->
xyz."constraint_name".constraint_mode(1/0);
Fixed 24 instance(s) of 'default constraint' (Removed 'default' and added note)
Fixed 6 instance(s) of FAIL keyword used with randomize()
Fixed 15 instance(s) of cast_assign w/CHECK keyword
Detected 1 instance(s) of rvm_log.format -- Usage has changed in VMM

Detected 1 instance(s) of 'next_transaction_t()' -- Use 'get()' instead
Fixed 3 instance(s) of 'wait_child()' -> 'wait fork'
Fixed 3 instance(s) of notify.ONE_BLAST_TRIGGER -> vmm_notify::ONE_BLAST
Fixed 2 instance(s) of notify.ONE_SHOT_TRIGGER -> vmm_notify::ONE_SHOT
Fixed 1 instance(s) of notify.ON_OFF_TRIGGER -> vmm_notify::ON_OFF
Detected 1 instance(s) of assoc_index
Detected 7 instance(s) of 'shadow' keyword (Need to recode manually)
Fixed 131 instance(s) of task/function declaration only w/in class scope (add 'extern' prefix)
Fixed 1 instance(s) of task/function outside class scope (remove keywords 'local','protected', and
'virtual')
Fixed 4 instance(s) of 'task pre_randomize()' -> 'function void pre_randomize()'
Fixed 4 instance(s) of 'task post_randomize()' -> 'function void post_randomize()'
Fixed 1 instance(s) of 'task gen_cfg()' -> 'function void gen_cfg()'
Fixed 1 instance(s) of 'task build()' -> 'function void build()'
Fixed 1 instance(s) of 'task start_xactor()' -> 'function void start_xactor()'
Fixed 1 instance(s) of 'task stop_xactor()' -> 'function void stop_xactor()'
Fixed 16 instance(s) of 'task reset_xactor()' -> 'function void reset_xactor()'
Fixed 53 instance(s) of 'void = '
Fixed 35 instance(s) of 'join none' -> 'join_none'
Fixed 35 instance(s) of 'join any' -> 'join_any'
Fixed 2 instance(s) of 'join all' -> 'join'
Detected 8 instance(s) of 'return;' in non-void function
Added 1 reminder(s): procedural code w/in program block must be within 'initial begin ... end'
--- summary ---

Files processed: 25
Lines of code: 24226
Lines of code modified: 10009
Of particular interest were the overall results that we received from the script for our own test
case. Specifically, the script process 24,226 lines of source code across 25 files. The script
automatically modified 10,009 lines, or ~41.3% of the source code, and the entire conversion
was performed in 12 seconds!
6. Potential Pitfalls
In this section, we will describe some of the pitfalls which we stumbled upon during the
conversion process with our example test case, as well as some of the work-around solutions we
found.
6.1.1 Complex pre-processor directives

Complex pre-processor directives are supported in OV, but are not in SV. An example and a
work-around solution for creating a combinational define for the logical OR operation is shown
below. One can also create a similar workaround for logical AND operations.
OV/RVM SV/VMM

#if defined A || defined B // Create combinational defines that can be supported in
// A or B code here SV
#endif ìfdef A
`define A_OR_B
èndif
ìfdef B
`define A_OR_B
èndif
ìfdef A_OR_B
// A or B code here
èndif
Table 10: Complex pre-processor directives
6.1.2 SV Function/Task arguments direction is sticky

In OV function/task arguments are inputs (pass by value or reference), where as in SV arguments
may be inputs (pass by value or reference) or outputs. Argument direction and type in SV is
“sticky” (if not specified explicitly). Let’s take the following task as an example:
my_task(input reg A, ref reg B, reg C);
In SV, argument C will imply type ‘ref’ as the previous argument B is defined as ‘ref’.
Additionally, arguments B and C will be implicitly determined to be inputs, as the first argument
A is defined as an input. To avoid any unintended errors in your SV code it is recommended to
manually add the direction (input, output, or ref) to all arguments in all tasks and functions.
6.1.3 Miscellaneous pitfalls
Implicit variable ‘i’

In OV, the variable ‘i’ is implicitly declared and can be used as a looping variable in for and
other loop statements. SV does not support this implicit declaration of variable ‘i’.
Reserved keywords
The list of reserved keywords in SV is not identical to OV. We encountered one such example
with a variable we had declared ‘int type’. In OV, this was fine, but in SV this results in a
compile error. We simply modified our variable name to be ‘int pkt_type’, and were able to
work around the issue.
Constraint and variable names should not be identical

In OV the constraint and variable names may be identical, but in SV this results in a compile
error. A simple workaround is to prefix all such instances with ‘c_’ in front of them.
7. Conclusions
There is long-term value on converting an existing testbench from OV/RVM to SV/VMM. In
the course of this exercise, we were amazed at the sheer number of changes required to convert

an existing golden testbench. Although many of the changes are relatively easy, the quantity is
simply overwhelming. To simplify this process for us and for others, we developed a script to
automate as much of the process as possible. We are very pleased with the results of the script.
For our test environment, the script automatically modified over 10,000 lines of our source code
(or 41%). From that point, we were able to make the required manual modifications and
successfully bring up the converted environment in SV. We believe that the automation greatly
reduced our conversion effort from months to days. The most up-to-date version and
information related to the conversion script may be found at the following URL:
http://www.findthecat.com/vera2sv/

8. References
IEEE Std 1800TM-2005, IEEE Standard for SystemVerilog -- Unified Hardware Design,
Specification, and Verification Language.
SystemVerilog for Verification, Chris Spear, Springer 2006
Reference Verification Methodology User Guide, Synopsys
Verification Methodology Manual for SystemVerilog, Bergeron, Janick et. al, Springer 2005
OpenVera Language Reference Manual: Native Testbench, Synopsys.
“SystemVerilog/OpenVera Language Comparison”, Synopsys FAE
“Synopsys SystemVerilog Roadmap”, Synopsys FAE
Link to commercial solution to convert OpenVera to SV:
http://www.veriez.com/eztranslate.htm
9. Appendix
The tables below contain a comprehensive list of all OV/RVM to SV/VMM conversions
performed or detected by the script, including code snippets. The Remarks column indicates any
script or language related remarks. The last two columns ‘D’ (i.e., script ‘Detects’) and ‘F’ (i.e.,
script ‘Fixes’) indicates how the script handles the conversion. When D=’Y’ and F=’Y’, it
means that the script detects and fixes the conversion automatically. When D=’Y’ and F=’N’, it
means that the scripts detects that a conversion is required, but cannot perform the conversion.
For such instances, an informational <FIXME> comment is added to indicate that a manual
conversion is required. When D=’N’ and F=’N’, it means that the script neither detects nor fixes
the issue. Such instances are rare, and they need to be converted manually by the user.
Table 11: OV to SV Conversions

Type OpenVera SystemVerilog Remarks D F
File name conversions
Include files #include "file_name.vr" ìnclude "file_name.sv" changes .vr -> .sv Y Y
Header include files #include "file_name.vrh" ìnclude changes .vrh -> Y Y
"file_name.svh" .svh
Header include files #include "file_name.vh" ìnclude changes .vh -> Y Y
"file_name.svh" .svh
Vera specific include #include N/A Script Removes Y Y
files <vera_defines.vrh> these instances
Pre-processor directives
Conditional #ifndef _ABC_ ìfndef _ABC_ Y Y
compilation #define _ABC_ `define _ABC_
directives … …
#endif èndif
undef #undef _ABC_ ùndef _ABC_ Y Y
Defines handling across all files
Macro Definitions #define ABC 10 `define ABC 10 Script keeps a Y Y
integer xyz[ABC]; int xyz[ÀBC]; database of all
defines in all files
and prefixes all
macro instances
with a backtick'.
Data types
Enumerated types enum bool (FALSE, typedef enum {FALSE, Y Y
TURE}; TRUE} bool;
Integer integer (2-state and 'bX) integer (4-state) Script converts Y Y
int (2-state) integer -> int
cast_assign cast_assign(dest, to); $cast(dest, to); Y Y
array initialization integer src[5] = {0, 1, 2, int src[5] = '{0, 1, 2, 3, N N
3, 4}; 4};
multi-dimensional integer src[2][3] = {{0, 1, integer src[2][3] = '{'{0, N N
array initialization 2}, {4, 5, 6}}; 1, 2}, '{4, 5, 6}};
associative array <data_type> <data_type> Y Y
assoc_array[]; assoc_array[*];
dynamic array <data_type> <data_type> Y Y
dynamic_array[*]; dynamic_array[];
Procedural block
begin-end { begin Y Y
…….. …..
} end
class class Cxyz { class Cxyz; Y Y
… …
} endclass:Cxyz
task task txyz (arg) { task txyz (arg); Y Y
… …
} endtask: txyz;
function function fxyz (args) { function fxyz (args); Y Y
… …
} endfunction: fxyz;
program program pxyz { program automatic Y Y
… pxyz;
} …
endprogram: pxyz;
Selection Statements
If if (cond) { if (cond) begin Y Y
… …
} end
else if (cond1) { else if (cond1) begin
… …
} end
else { else begin
… …
} end
case case (cond) { case (cond) Y Y

1: { 1: begin
… ….
} end
default: { default: begin
… ….
} end
} endcase
Loop Statements
for for (i=0; i<X; i++) { for (int i=0; i<X;i++) Y Y
… begin
} …
end
while while (condition) { while (condition) begin Y Y
… …
} end
foreach (single foreach(src, i) { foreach(src[i]) begin Y Y
dimension) … …
} end

foreach (multiple foreach(tlp_types, i, *, *) foreach (tlp_types[i,,]) OpenVera Y Y
dimension) { begin supports multi-
foreach(tlp_types, *, j, foreach(tlp_types[,j,]) dimensional
*) { begin foreach loops in
tlp_types[i][j][MRD] == array constraints.
1; tlp_types[i][j][`MRD] ==
… 1;
} ...
} end
end
repeat repeat(delay) { repeat(delay) begin Y Y

… …
} end
do-while do { do begin Y Y
… …
} while (cond); end while (cond);
Jump Statements
return integer function Previous example not VCS gives Y N
my_func(a,b) { supported compile warning
if (a > 100) { for return
return; statement without
} expression for
... non-void
} functions.
Functions/Tasks
extern class A { class A { extern required for Y Y
task hello(a,b); extern task hello(a,b); task/function
} } prototypes inside
class scope, with
task A::hello(a,b) { task A::hello(a,b); bodies out of class
… … scope
} endtask
local/protected/virtua virtual task task MyClass::abc() In SV there is no Y Y
l MyClass::abc() need to keep
local/protected/virt
ual keywords
before
function/task
implemetation
new task new() { function new() { change new task Y Y
… … to new function
} endfunction: new
void void = func(args, …); void'(func(args, …)); script currently just Y Y
removes 'void ='
pre_randomize task pre_randomize() function void script converts Y Y
pre_randomize() task to function.
post_randomize task post_randomize() function void script converts Y Y
post_randomize() task to function.
Random constraints

constraint range := constraint set_range { constraint set_range { script adds square Y Y
m_n_value dist { m_n_value dist { brackets to ranges
low_val:high_val := [low_val:high_val] :=
weight weight
}; };
} }
Constraint range :/ constraint set_range { constraint set_range { script adds square Y Y
m_n_value dist { m_n_value dist { brackets to ranges
low_val:high_val :/ [low_val:high_val] :/
weight weight
}; };
} }
constraint_mode(wit void = void'(set_range.constra Note, script Y Y
hout hierarchy) constraint_mode(ON/OF int_mode(1/0)); removes 'void ='
F, "set_range"); for now and does
not add void'().
constraint_mode(wit void = void'(abc.xyz.set_range Note, script Y Y
h hierarchy) abc.xyz.constraint_mod .constraint_mode(1/0)); removes 'void ='
e(ON/OFF, "set_range"); for now and does
not add void'().
Implication operator constraint a_constr { constraint a_constr { Implication Y Y
{a==0} => {b == 1}; {a==0} -> {b == 1}; operator inside
... ... constraint blocks
} } is changed form
=> to ->
set membership constraint legal_mps { constraint legal_mps { Y Y
operator mps in {128, 256}; mps inside {128,
... 256};
} ...
}
Negated set constraint ds_port_tlps { constraint ds_port_tlps Y Y
membership tlp_type !in {CFGRD, {
operator CFGWR}; !tlp_type inside
... {CFGRD, CFGWR};
} ...
}
Constraint ranges constraint constraint Y Y
using variables interesting_payld_len { interesting_payld_len {
paylaod_len dist { paylaod_len dist {
0:/10, 0:/10,
1:10:/20, [1:10]:/20,
1:env.pcie_cfg.cfg_env. [1:env.pcie_cfg.cfg_env
mps/4:/30, .mps/4]:/30,
y:z:/40}; [y:z]:/40};
} }
Random Number System Functions
Random random() $random() Y Y
Srandom Srandom $srandom() Y Y
Urandom urandom() $urandom() Y Y
rand48 rand48() $rand48() Y Y

urand48 urand48() $urand48() Y Y
urandom_range urandom_range() $urandom_range() Y Y
random_range random_range $dist_uniform Y Y
rand_normal rand_normal $dist_normal Y Y
rand_poisson rand_poisson $dist_poisson Y Y
rand_exponential rand_exponential $dist_exponential Y Y
System Commands
stop() $stop() Y Y
exit(0) ; $exit() Y Y
get_time(LO) $time LO not supported, Y Y
script removes it.
os_command() $system() Y Y
File Access
fopen fopen $fopen Y Y
feof feof $feof Y Y
fclose fclose(file); $fclose(file); Y Y
ferror ferror $ferror Y Y
Keyword and Misc conversions
printf printf $write Y Y
psprintf psprintf $psprintf VCS supports Y Y

$psprintf. Script
currently converts
psprintf to
$psprintf.
Note: $swrite
servers similar
purpose but with
slightly modified
syntax.
sprintf sprintf $sformat Y Y
sscanf sscanf $sscanf Y Y
fprintf fprintf $fwrite Y Y
var var ref Y Y
join none join none join_none Y Y
join any join any join_any Y Y
join all join all join Y Y
terminate terminate; disable fork; Y Y
wait_child wait_child(); wait fork; Y Y
FAIL if (this.randomize() == if (this.randomize() == Y Y
FAIL) 0)
… …
CHECK if (cast_assign(dest, to, if ($cast(dest, to) == 0) remove CHECK Y Y
CHECK) == FAIL) begin CHECK is used
… ... for associative
arrays as well.
wait_var wait_var @ Y Y
breakpoint breakpoint() $stop() Y Y

vera_get_width vera_get_width $size Y Y
object_compare object_compare NA N N
object_print object_print NA N N
object_copy object_copy NA N N
finalize finalize NA N N
Manual Changes
System Commands get_time_unit() N/A Y N
System Commands get_systime N/A Y N
System Commands get_env() N/A Y N
System Commands get_cycle() N/A Y N
shadow shadow N/A Y N
semaphore static integer semaphore Y N
carm_access=alloc(SEM carm_access;
APHORE, 0,1,1); function new() {
…. …
semaphore_get(WAIT,c this.carm_access =
arm_access,1); new(1);
… }
semaphore_put(carm_a carm_access.get(1);
ccess, 1); …
carm_access.put(1);
default constraint default constraint Need to create Y N
<const_name> workaround in
SystemVerilog
assoc_index total_elements = total_elements = Y N
assoc_index(CHECK, knob_names.num();
knob_names);
program initial program pxyz { program automatic Initial begin … Y N
vmm_log log; pxyz; end' required in
… initial begin SV for any
log = new(); vmm_log log; procedural code
… … w/in the program
} log = new(); block.
end
endprogram: pxyz;
Delay drive @1 #1 Y N
construct
Expect construct @(delay) duv.q == data ; Not used Y N
dynamic_size class pcie_tlp { class pcie_tlp; dynamic_size is Y N
rand int payload_len; rand int payload_len; not supported by
rand bit [31:0] payload rand bit [31:0] payload SV
[] [];
dynamic_size …
payload_len; constraint
… payload_size {
} payload.size ==
payload_len;
}
}
endclass : pcie_tlp

Hierarchical env.pcie_cfg.cfg_env.en $root.test.env.pcie_cfg. SV hierarchical N N
reference _port[i] cfg_env.en_port[i] access using $root
is supported for
instances only.
function/task function integer function int Multiple default N N

argument default check_val(integer a = 1); check_val(int a); values to method
values in prototype arguments both at
and implementation prototype
declaration and at
the
implementation
are not allowed.
freadstr read_str = void'($fgets(read_str, freadstr is not N N

freadstr(file_handle, file_handle)); supported by SV
SILENT);
interface interface <intf_name> { interface change input and Y Y
input clk CLOCK; <intf_name>(input clk); output to logic and
input [7:0] a logic [7:0] a; remove hdl_node
INPUT_EDGE; logic b; and other defines.
output b OUTPUT logic c; Keep the clocking
EDGE OUTPUT_SKEW; …. net as an input to
inout c INPUT_EDGE endinterface the interfaces.
hdl_node "system.a"; :<intf_name>
…
}
Table 12: RVM to VMM Conversions

Type RVM VMM Remarks D F
File name conversions
RVM specific #include ìnclude "vmm.sv" Y Y
include files <rvm_std_lib.vrh>
Keyword and name change conversions
rvm_log vmm_log Y Y
rvm_error `vmm_error Y Y
rvm_fatal `vmm_fatal Y Y
rvm_warning `vmm_warning Y Y
rvm_note `vmm_note Y Y
rvm_trace `vmm_trace Y Y
rvm_debug `vmm_debug Y Y
rvm_verbose `vmm_verbose Y Y
rvm_env vmm_env Y Y
rvm_data vmm_data Y Y
rvm_xactor vmm_xactor Y Y
rvm_notify vmm_notify Y Y
rvm_broadcast vmm_broadcast Y Y
rvm_channel `vmm_channel Y Y

rvm_scheduler vmm_scheduler Y Y
rvm_atomic_gen `vmm_atomic_gen Y Y
rvm_xactor_callbacks vmm_xactor_callbacks Y Y
rvm_OO_callback `vmm_callback Y Y
rvm_scenario_gen `vmm_scenario_gen Y Y
notify configure this.EVENT_A = this.notify.configure(this notify configure Y N
this.notify.configure(*, .EVENT_A, does not allow *
TRIGGER_TYPE); TRIGGER_TYPE); as an argument in
SV
Hierarchical log.DEBUG_SEV vmm_log::DEBUG_SE Y Y
reference to enum V
labels
rvm_data object_id data_id name changed Y Y

from RVM to VMM
rvm_notify this.notify.ONE_BLAST_ vmm_notify::BLAST name changed Y Y
TRIGGER from RVM to VMM
this.notify.ONE_SHOT_ vmm_notify::ONE_SHO name changed Y Y
TRIGGER T from RVM to VMM
this.notify.ON_OFF_TRI vmm_notify::ON_OFF name changed Y Y
GGER from RVM to VMM
rvm_xactor methods main_t main _t notation Y Y
removed
wait_if_stopped_t wait_if_stopped _t notation Y Y
removed
put_t put _t notation Y Y
removed
wait_for_t wait_for _t notation Y Y
removed
Note: wait_for is
no longer
returning the
status transaction.
Instead we need
to use status
function.
cfg_dut_t cfg_dut _t notation Y Y
removed
reset_dut_t reset_dut _t notation Y Y
removed
start_t start _t notation Y Y
removed
wait_for_end_t wait_for_end _t notation Y Y
removed
stop_t stop _t notation Y Y
removed
cleanup_t cleanup _t notation Y Y
removed
run_t run _t notation Y Y
removed

activate_t activate _t notation Y
removed
stop_after_n_errs stop_after_n_errors name changed Y Y
from RVM to VMM
virtual task gen_cfg() virtual function void tasks which do not Y Y
gen_cfg() consume time are
converted to
functions returning
void.
virtual task build() virtual function void tasks which do not Y Y
build() consume time are
converted to
functions returning
void.
virtual task start_xactor() virtual function void tasks which do not Y Y
start_xactor() consume time are
converted to
functions returning
void.
virtual task stop_xactor() virtual function void tasks which do not Y Y
stop_xactor() consume time are
converted to
functions returning
void.
task function void tasks which do not Y Y
Ext_tlp_collector::reset_ Ext_tlp_collector::reset consume time are
xactor(integer rst_type = _xactor(reset_e converted to
0) rst_type = functions returning
vmm_xactor::SOFT_R void.
ST)
Manual Changes
rvm_log format this.log.format(env.log_f this.log.set_format(fmt); Y N
ormat,env.log_prefix);
rvm callbacks register_callback append_callback register_callback Y N
is deprecated
next_transaction_t cast_assign(tr[i],this.next this.in_chan[i][INT_TX]. Y N
_transaction_t(this.in_ch get(tr[i]);
an[i][INT_TX]));

Openvera/Rvm To Systemverilog/Vmm Conversion: How To Avoid Death by A Thousand Cuts'

Uploaded by

Copyright:

Available Formats

Openvera/Rvm To Systemverilog/Vmm Conversion: How To Avoid Death by A Thousand Cuts'

Uploaded by

Document Information

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

Openvera/Rvm To Systemverilog/Vmm Conversion: How To Avoid Death by A Thousand Cuts'

Uploaded by

Copyright:

Available Formats

OpenVera/RVM to SystemVerilog/VMM Conversion:

How to Avoid ‘Death by a thousand cuts’

Integrated Device Technology

SNUG San Jose 2008 2 OpenVera/RVM to SV/VMM Conversion

SNUG San Jose 2008 3 OpenVera/RVM to SV/VMM Conversion

3. Project scope & tools

SNUG San Jose 2008 4 OpenVera/RVM to SV/VMM Conversion

4.1 Easily scriptable changes

SNUG San Jose 2008 5 OpenVera/RVM to SV/VMM Conversion

#include "some_include.vh" `include "some_include.svh"

Table 1: Easily scriptable example

4.2 Tougher-but-scriptable changes

SNUG San Jose 2008 6 OpenVera/RVM to SV/VMM Conversion

Table 2: Tougher-but-scriptable example -- curly braces

Table 3: Tougher-but-scriptable example -- constraints

SNUG San Jose 2008 7 OpenVera/RVM to SV/VMM Conversion

enum bool { typedef enum {

if (process_data == TRUE) { if (process_data == TRUE) begin

Table 4: Tougher-but-scriptable example -- defines, enums, and foreach

SNUG San Jose 2008 8 OpenVera/RVM to SV/VMM Conversion

4.3.1 Shadow variables

Table 5: Manual example -- shadow variables

4.3.2 Default constraints

4.3.3 Hierarchical references

4.3.4 Delay elements within functions

SNUG San Jose 2008 9 OpenVera/RVM to SV/VMM Conversion

4.3.5 Dynamic array dynamic_size attribute

Table 6: Manual example -- dynamic_size attribute

4.3.6 Program block

SNUG San Jose 2008 10 OpenVera/RVM to SV/VMM Conversion

Table 7: Manual example -- Interfaces

4.3.8 Formatting with rvm_log

Table 8: Manual example -- rvm_log format

4.3.9 RVM Notification rvm_notify.wait_for_t() method

SNUG San Jose 2008 11 OpenVera/RVM to SV/VMM Conversion

Table 9: Manual example -- RVM notification and status methods

4.3.10 Miscellaneous changes

 Function/Tasks declarations without body

 Hierarchical reference to enumerations

 Associative array ‘assoc_index’ handling

SNUG San Jose 2008 12 OpenVera/RVM to SV/VMM Conversion

VMM: virtual function void append_callback(vmm_log_callbacks cb);

 RVM reset_xactor() input

 RVM next_transaction_t() method

5. Automating the conversion process

vera2sv <input file(s)>

vera2sv *.vr *.vrh

SNUG San Jose 2008 13 OpenVera/RVM to SV/VMM Conversion

--- Simple Search & Replace ---

SNUG San Jose 2008 14 OpenVera/RVM to SV/VMM Conversion

--- Procedural Constructs ---

--- Misc ---

SNUG San Jose 2008 15 OpenVera/RVM to SV/VMM Conversion

--- summary ---

6.1.1 Complex pre-processor directives

SNUG San Jose 2008 16 OpenVera/RVM to SV/VMM Conversion

Table 10: Complex pre-processor directives

6.1.2 SV Function/Task arguments direction is sticky

my_task(input reg A, ref reg B, reg C);

Function/Tasks declarations without body

Hierarchical reference to enumerations

Associative array ‘assoc_index’ handling

RVM reset_xactor() input

RVM next_transaction_t() method

vera2sv .vr .vrh

Implicit variable ‘i’

Constraint and variable names should not be identical