SystemVerilog Meets C++: Re-use of Existing C/C++ Models

Just Got Easier

John Aynsley
Doulos
[email protected]

Abstract- The OVM and VMM methodologies each provide relatively simple coding guidelines tried-and-tested with current
powerful, flexible and intuitive frameworks for the construction simulator releases. As a consequence, we are forced down the line of
of SystemVerilog verification environments. However, many addressing practical issues of simulator support for the DPI and the
SystemVerilog users also have models written in C, C++, or procedural interface between SystemVerilog and SystemC.
sometimes SystemC. Furthermore, the emergence of the
SystemC TLM-1 and TLM-2.0 transaction-level modeling The DPI supports simple function calls between SystemVerilog and
standards is having an impact on communication styles within C. Simulation tool vendors also offer the facility of mixed-language
SystemVerlog verification environments. This paper offers simulation, such as the ability to instantiate a SystemC module from
practical guidance on using the SystemVerilog Direct a top-level SystemVerilog module. But mixed-language instantiation
Programming Interface (DPI) to integrate existing C, C++ and alone is insufficient to address the issue of building procedural
SystemC code into an OVM- or VMM-based SystemVerilog interfaces between the languages. Tool vendors offer proprietary
testbench without jeopardizing portability from one simulator to (non-standard) solutions to the problem of making object-oriented
another. This is achieved by presenting a set of simple, robust method calls (that is, calling class member functions as opposed to
guidelines for creating portable DPI code. global functions) between SystemVerilog and C++ and of passing
transactions between SystemVerilog and SystemC. Anyone wishing
to use these facilities is force to chose between “selling their soul” to
1. Introduction the EDA vendor in the sense of getting locked into a proprietary
solution, or of investigating and using a restricted set of features that
The requirement to call a C/C++ reference model from a form the “lowest common denominator” between tools. We take the
SystemVerilog test bench is not uncommon. A contemporary latter approach in this paper.
SystemVerilog test bench would typically be based on either the
OVM or the VMM functional verification methodology or 1.2 Transaction-Level Modeling
sometimes on a homebrew variant of these. One of the tasks
performed by such a test bench is to compare the actual behavior of The SystemC community has developed the TLM-1.0 and TLM-2.0
the design-under-test (DUT) against the behavior of a functional standards for Transaction Level Modeling in the context of
reference model, which might originally have been coded in C, C++, architectural exploration and creating so-called virtual platform
or SystemC. A C/C++ algorithm or reference model would models of a hardware platform for early software execution.
necessarily be untimed, but a SystemC model could include timing Meanwhile, for functional verification, SystemVerilog test benches
information. written to the OVM or VMM standards also make use of transaction-
level modeling (TLM) for internal communication. This means using
Against this backdrop, the question of how to call a C/C++ or function calls to pass around objects that encapsulate the attributes of
SystemC reference model from a SystemVerilog test bench is a transaction. The transactions themselves are specific to the
frequently raised. Unfortunately, although each of the above- interfaces or protocols being modeled. In order to exploit this
mentioned languages is defined by a formal standard, the interface commonality between the domains of modeling and verification
between the languages is not standardized with the same precision as OVM has adopted the TLM-1.0 standard for communication and the
the languages themselves. In principle, the SystemVerilog Direct latest version of VMM has added internal communication features
Programming Interface (DPI) permits procedural function calls inspired by TLM-2.0. In this paper, we look to develop an approach
between SystemVerilog and C. In practice, differences between to communication between SystemVerilog and C/SystemC that is
implementations and the lack of any standard support for calls consistent and interoperable with these TLM standards.
between SystemVerilog and SystemC mean that any solution needs
to be tool-dependent. OVM and VMM test benches are transaction-oriented. On the other
hand, although C/C++ reference models can also be transaction-
1.1 Portability oriented, they will sometimes be completely untimed or may perform
some transformation on an entire dataset without having any regard
The goal of this paper is to present a very practical answer to the for how and when that data is presented in the hardware
question of how to use the SystemVerilog DPI to communicate implementation or the test bench. For example, a reference model for
between an OVM or VMM SystemVerilog test bench and a C/C++, an FFT may transform a dataset from the time domain to the
or SystemC reference model in a way that is, as far as possible, frequency domain. Integrating such a reference model into a test
portable between simulators. The intent is to provide a solution that bench requires that the mismatch between transaction-by-transaction
actually works, today! To this end, we endeavor to offer a set of processing and batch processing be addressed. There may also be

Copyright © 2010 by Doulos. 1

differences in the degree of pipelining present in the design-under- be read from an external file. Thus it may be necessary for the
test and the reference model. Although the solution to many of these scoreboard to collect a set of incoming transaction and then pass
issues will be application-specific, in this paper we pick out some them to the reference model for batch processing. Theoretically this
specific aspects concerning communication across the buffering could occur on the SystemVerilog or the C side of the DPI,
SystemVerilog/C interface using the DPI. In particular, we look at but for practical reasons explained below we found it most
the choice between using simple function calls versus TLM-style straightforward to batch the data on the C side.
interfaces, and how to synchronize communication across the DPI.
4. Transactions in TLM-1.0 and TLM-2.0
2. Goals and Assumptions
The Open SystemC Initiative (OSCI) TLM-1.0 and TLM-2.0
The goals and assumptions of this work are as follows: standards define semantics for passing transactions as function
arguments and for managing the lifetimes of transaction objects.
i. There exists a test bench coded in SystemVerilog using These standards can inform our decisions concerning the best way to
OVM or VMM. pass information between SystemVerilog and C. In particular, the
solution we chose should be consistent with the use of the TLM
ii. There exists an untimed reference model coded in C, C++ standards on either the SystemVerilog or SystemC sides of the DPI
or SystemC to be called from the test bench. (Timed interface.
SystemC models are also considered as an extension.)
4.1 OVM and TLM-1.0
iii. The SystemVerilog DPI is to be used to communicate
between SystemVerilog and the reference model OVM communication is based on TLM-1.0. The most significant
aspect of TLM-1.0-style communication is that each transaction is
iv. The goal is to achieve portability between simulators by strictly unidirectional. This is referred to as “effective pass-by-
using features that have relatively mature and robust value”, implying that although the C++ implementation does not
implementations in all simulators. literally use pass-by-value in every case (sometimes pass-by-
reference is used), the transaction object should not be modified by
v. The simulators in question are the production releases of the target. To use a metaphor, TLM-1.0 transactions are thrown over-
SystemVerilog simulators from Cadence, Mentor and the-wall from initiator to target, and any communication in the
Synopsys current as of November 2009. reverse direction requires a separate transaction. Some TLM-1.0
users have chosen to pass pointers to data within the transaction
vi. The goal of portability is to be achieved by creating a object for simulation efficiency, but agree that any attempt to access
simple and robust set of guidelines that can be easily shared memory using these pointers is outside the scope of the TLM
followed interface (i.e. entirely the user’s responsibility).

In TLM-1.0, the semantics of blocking transport are to send one

3. Test Bench and Reference Model unidirectional request transaction from initiator to target, and to
receive one unidirectional response transaction back on return. This
A SystemVerilog test bench typically exercises an RTL model of a is fundamentally different from blocking transport in TLM-2.0 where
Design-Under-Test (DUT) by pin wiggling, that is, by making low a single transaction object carries both request and response.
level assignments to individual Verilog wires with more-or-less
precise timing (the timing could be accurate to the picosecond or In OVM, the TLM-1.0 request/response semantics are particularly
merely clock-cycle-accurate). In the OVM and VMM evident in the interface between the ovm_sequencer and the
methodologies, the pin wiggling is usually encapsulated within ovm_driver. The sequencer sends a request to a driver. The driver
driver and monitor components that communicate with the rest of the implements the transaction by communicating with lower levels of
test bench using transactions. In VMM this is termed the command the protocol stack, perhaps by wiggling pins, then when it is done
layer, in which transactions are simple and atomic. These atomic sends a response back to the sequencer.
transactions are generated from higher layers of the test bench which
combine these atomic transactions into more complex higher-level 4.2 VMM and TLM-2.0
transactions according to the details of the interface or protocol being
modeled. VMM communication is based on the vmm_channel, and version 1.2
of the VMM library adds TLM-2.0-style interfaces. Both
In OVM and VMM, transactions may be sent to a so-called vmm_channel and TLM-2.0 are based on the idea that transaction
scoreboard which collects functional coverage information and objects are passed by reference, and the lifetime of a transaction
checks for functional correctness. It is within the scoreboard that a object may extend across multiple function calls. VMM permits a
test bench may need to invoke a reference model to calculate the transaction to remain in a vmm_channel while it is worked on by the
expected values of the DUT or to analyze the actual values generated target, and the target is permitted to modify the state of the
by the DUT. The scoreboard is typically expected to receive both transaction object in order to return a response back to the initiator.
stimulus sent to the DUT and the actual response from the DUT The target must explicitly signal the completion of the transaction
transaction-by-transaction at some appropriate abstraction level. back to the initiator. VMM and TLM-2.0 are quite similar in these
respects.
As observed in the introduction, a C/C++ reference model may not
be structured to receive transactions one-by-one. Rather, the TLM-2.0 provides two transport interfaces: blocking (b_transport)
programming interface to the reference model may consist of a single and non-blocking (nb_transport). With b_transport, the entire
function call that carries with it an entire dataset, or the dataset may transaction is completed within a single method call. With

Copyright © 2010 by Doulos. 2

nb_transport, the progress of a transaction may be described using
multiple nb_transport method calls going back-and-forth between
initiator and target. // SystemVerilog
export “DPI-C” task my_task;
4.3 Consequences for the DPI task my_task;
#10;
For our purposes, the practical consequence of the above discussion endtask
is that any communication between a SystemVerilog test bench and a
C reference model should be clearly structured into a request and a // C
response (however those may be implemented), and the lifetime and { my_task(); }
completion of the transaction need to be explicitly considered. A
request is passed from SystemVerilog to C, and a response returned
back to SystemVerilog. DPI calls can have input, output, and inout arguments, and a return
value in the case of a function, all of which support a limited set of
The easiest case is that of an untimed C/C++ reference model which data types.
is called with a dataset, does some calculation, and returns the
answer from the very same function call. In this case request, An imported DPI task/function can call an exported DPI/task
response, and completion occur in a single function call. The request function, and in the case of a task, that exported task is permitted to
and response do not need to be represented as explicit transaction execute timing controls (delays or waits). Thus a nested call to a DPI
objects, as will be explained below. The important thing is that the export from a DPI import can suspend the execution of a
distinction between request and response is kept clear, and the SystemVerilog process.
completion time is well-defined.
A DPI import that calls a DPI export or that makes PLI or VPI calls
In the case that transactions need to batched to build a dataset for the must be declared as a context import. This declaration ensures that
C/++ reference model, this should be done on the C-side of the the compiler passes information concerning the SystemVerilog
interface. context, that is, the location in the SystemVerilog module hierarchy,
through the DPI. In the absence of context information, a C function
Things get a lot more complicated if the reference model is a is obliged to call svSetScope() to set the SystemVerilog context.
SystemC module that provides a blocking interface, because we can
get caught up in issues of synchronization between the A principle feature of the DPI is that DPI calls have the same
SystemVerilog and SystemC schedulers. Whatever, the SystemC semantics as regular SystemVerilog task/function calls when viewed
target needs to send a response back to the SystemVerilog initiator from SystemVerilog. Moreover, DPI calls are transparent when
when it is ready, and once more we need to design the interface such viewed from the SystemVerilog side. This means that DPI
that we have a very clear idea of when the transaction is complete. task/function arguments use the native SystemVerilog data format,
and that nested import -> export call chains that pass SystemVerilog
arguments back into SystemVerilog through an intervening C
5. Using the DPI with C function will be indistinguishable from native SystemVerilog calls
that have the same functionality. This makes the DPI very
Here we give a brief overview of the DPI just to highlight the
straightforward to use from the SystemVerilog side.
pertinent aspects.
From the C side, things are a little more complicated. Although
The standard SystemVerilog DPI permits function calls between
simple scalar data types have a common representation between
SystemVerilog and C, that is, C functions may be called from
SystemVerilog and C, the internal representation of more
SystemVerilog, and SystemVerilog tasks and functions may be
complicated types is simulator-specific. Thus although
called from C.
SystemVerilog data items of more complex types (such as nested
structs and arrays) are guaranteed to pass through the DPI
5.1 Features of the DPI transparently, their C representations are not in general expected to
be portable between tools.
In order to call a C function from SystemVerilog, the SystemVerilog
code must have an import declaration which specifies the name, Generally, small data types have portable representations when
return type, and arguments of the C function. For example passed as DPI arguments. Small data types include bit, byte, int,
logic, string, and enums (by passing the integral type associated with
the enum). Logic vectors, that is, packed arrays of type logic, have a
// SystemVerilog canonical representation in which the two bits that represent the
import “DPI-C” function int my_func(string s);
value 0,1,Z,X are split across two separate words using the natural
initial word length of the host. The DPI offers a standardized C
i = my_func(“Hello world\n”); programming interface to access and manipulate this canonical
representation, with the effect that passing logic vectors as DPI
// C arguments is portable provided that the standard API is used on the C
int my_func( const char* s); side.

5.2 Practical DPI Restrictions

In order to call a SystemVerilog task or function from C, the
SystemVerilog code must have an export declaration which specifies In principle, nested user-defined structs and arrays composed of the
only the name of the task/function. For example above-mentioned small data types may be passed as DPI arguments.

Copyright © 2010 by Doulos. 3

In practice, we found that this capability was not fully supported by between the simulator implementations, and was thus more
all current simulators. productive. This same philosophy is taken throughout.

In principle, the DPI offers the ability to pass so-called open array 5.4 DPI Guidelines: SystemVerilog-to-C++
argument in which the size of the array is left unspecified on the
SystemVerilog side, and provides a C programming interface to The standard SystemVerilog DPI, i.e. “DPI-C”, only supports
manipulate such open arrays on the C side. Again, we found that not function calls between SystemVerilog and C. However it is very
all current simulators provide robust support for this facility. straightforward to make C++ calls simply by forcing the C++
compiler to use C linkage for both imported and exported functions
Aside from current tool limitations, the DPI also has some inherent as follows:
limitations in the sense that it does not permit SystemVerilog class
objects to be passed as DPI arguments, and does not permit
SystemVerilog class methods or C++ class member functions to be // C++
called directly through the DPI in either direction. #include "svdpi.h"

5.3 DPI Guidelines: SystemVerilog-to-C extern "C"

int imported_function_called_from_SystemVerilog() { … }
We were able to create simple, robust, portable DPI code to extern “C”
communicate between SystemVerilog and C by adhering to the int exported_function_called_from_CPP();
following guidelines:

i. Pass only small types as DPI arguments, that is, do not pass The only caveat is that the DPI does not permit C++ member
user-defined structs, open arrays, or multi-dimensional functions (methods) to be called.
arrays
DPI code such as this can be made portable across all current
ii. Logic vectors, i.e. packed arrays of type logic, may be simulators. All simulators provide the standard DPI header
passed as DPI arguments and accessed using the standard “svdpi.h”.
C API with the proviso that conditional compilation may
be necessary to pick out the appropriate class properties in
a portable way. Some simulators refer to the two words of 6. Calling an Untimed C/C++ Reference Model
the canonical representation using class properties .a and .b
while others use .aval and .bval. For example: In this section we explore the issues involved in calling an untimed
reference model from an OVM or VMM SystemVerilog test bench
using a Fast Fourier Transform (FFT) algorithm as an example. The
// SystemVerilog test bench passes around transactions that each represent a single 16-
#include "svdpi.h" bit sample in the time domain. The intent is to use the FFT reference
model to convert a set of samples from the time domain to the
int print ( svLogicVecVal* v ) { frequency domain for analysis. The samples are collected by the
int i; scoreboard as the test bench executes, a batch of samples is sent to
for (i = 0; i < 8; i++) { the FFT reference algorithm, and the scoreboard logs the results of
#ifdef CADENCE the analysis. The transaction stream in the test bench actually
printf("%d%d", v->a % 2, v->b % 2);
consists of multiple interleaved sample streams, where each
v->a = v->a >> 1;
v->b = v->b >> 1; individual sample is tagged with a stream number.
#else
printf("%d%d", v->aval % 2, v->bval % 2); The FFT algorithm is primarily coded in C but makes occasional use
v->aval = v->aval >> 1; of C++ features such as stream I/O, so it was necessary to use a C++
v->bval = v->bval >> 1; compiler and to force the compiler to use C linkage for the DPI
#endif functions as described above.
}
printf("\n");
In the original C++ program, the main() function initialized the
}
dataset to be transformed by reading the data from an external text
file. We replaced this with two DPI functions, one to initialize the
state of the arrays used during the FFT transform, and another to pass
iii. In order to pass structs across the DPI, break them down
individual samples from the SystemVerilog test bench to the C++
into small arguments and re-assemble the struct on the C
model:
side if desired.

iv. Declare any imported tasks as context tasks. // SystemVerilog

import "DPI-C" function void initialize_fft(input int n_points);
It should be noted that not all current simulators suffer from the same import "DPI-C" function void transfer_sample(
limitations, and it was found that each simulator had its own input logic [3:0] tag, logic signed [15:0] data);
idiosyncrasies; none were without fault. However, the explicit goal
of this paper was to find a simple, robust, portable approach that // C++
works with all simulators. We found that the chosen approach #include "svdpi.h"
shielded us from having to struggle with the detailed differences extern "C"
void initialize_fft(int n_points);

Copyright © 2010 by Doulos. 4

 extern "C" vendors, Cadence and Mentor, both support an extended version of
void transfer_sample(svLogicVecVal* tag, svLogicVecVal* data); the DPI called “DPI-SC” aimed at overcoming this restriction.
Synopsys achieves similar functionality by extending the capability
of “DPI-C” and by offering the TLI, or Transaction-Level Interface.
In keeping with the guidelines described above, only small types are
passed through the DPI. Passing logic vectors is straightforward If “DPI-SC” were used to make direct SystemC interface method
provided that conditional compilation is used on the C side for calls from SystemVerilog, it may well be necessary to modify the
portability, again as described above. argument types of the method calls, for two reasons. Firstly,
SystemC methods often pass transaction objects, which is not
As an alternative approach, we investigated batching the data on the possible with the DPI. Secondly, we may want to restrict the DPI
SystemVerilog side and passing the entire dataset across the DPI in a arguments to small types for portability. As a consequence, it is not
single function call, but this approach was fraught with practical necessarily desirable to make direct SystemC interface method calls
difficulties. We attempted to pass a multi-dimensional array as a DPI from SystemVerilog, and in general a better approach may be to
argument, but trying to unravel the differences between the simulator instantiate the original target SystemC module from a wrapper
implementations proved to be an unproductive use of time: module on the SystemC side, where that wrapper adheres to our
guidelines for portable DPI use.
Simulator 1 required a single level of pointer indirection in
the C API As a further practical difficulty, although “DPI-SC” is supported by
both Cadence and Mentor, there are differences of detail between the
Simulator 2 required a second level of pointer indirection two implementations that would restrict portability when making
in the same supposedly standard C API class method calls. (However, the mutual implementation of calls to
global C++ functions seems more robust, as described below.)
Simulator 3 just crashed
7.1 Timing across SystemVerilog and SystemC
The samples are batched on the C side of the DPI (i.e. stored in a
static array variable between DPI calls), and the FFT algorithm DPI calls from SystemVerilog run in the context of the
called when the dataset associated with each sample stream is full. SystemVerilog scheduler, and C functions are intrinsically non-
Both of the DPI calls are necessarily non-blocking, that is, the C++ blocking; a DPI call can only suspend execution by making a call
code executes immediately in the context of the calling back to a DPI task exported from SystemVerilog. But SystemVerilog
SystemVerilog process with no simulation time passing. and SystemC each have their own schedulers, and there is no
standard programming interface for controlling the interactions
In terms of the earlier discussion concerning TLM, the call to between those schedulers. Specifically, a DPI call from
transfer_sample() passes a request from the test bench to the SystemVerilog to SystemC must not block, or at least if it does call
reference model using input arguments. Although not necessary for sc_core::wait(), the code cannot be expected to be portable.
this particular example, it is very straightforward to pass a response
on return from the DPI function call by using inout or output Calling into SystemC models from SystemVerilog is simplest if the
arguments or the function return value. Using our approach of only SystemC models are untimed. In that case we can use the same
passing small types, the distinction between request and response can paradigm as for any untimed C++ model, that is, a DPI call from
be kept very clean. This approach works fine when called from an SystemVerilog passes a request to an untimed model, and a response
OVM or a VMM driver or scoreboard. is passed back on return from that or from a subsequent DPI call.

Using this approach, it was possible to use precisely the same DPI 7.2 DPI Guidelines: SV-to-SC, untimed, one instance
calls and C++ code with an OVM test bench and simulators from
Cadence and Mentor, and with a VMM test bench and the Synopsys We were able to create simple, robust, portable DPI code to
simulator. While this study was limited to the methodology/vendor communicate between SystemVerilog and a single instance of an
combinations as stated, this same approach should work successfully untimed SystemC module by adhering to the following guidelines (in
with other combinations. addition to those given above):

7. Using the DPI with SystemC i. Use “DPI-C”, not “DPI-SC”

All current simulators support mixed-language designs, and ii. Use “DPI-C” imports only, not exports.
specifically permit SystemC modules to be instantiated directly from
SystemVerilog. All simulators support the ability to make pin-level iii. Cadence, and only Cadence, requires a dummy
connections across languages, but unfortunately there is no standard SystemVerilog module stub corresponding to the SystemC
for procedural communication between SystemVerilog and SystemC module:
aside from the DPI.
// SystemVerilog
The native SystemVerilog DPI does not explicitly support SystemC. `ifdef NCSC
However, it is possible to use the standard DPI with SystemC in the module scwrap ()
sense that SystemC is just another C++ application. (* integer foreign = "SystemC"; *);
endmodule
`endif
SystemC modules typically provide a procedural interface either by
implementing a SystemC interface or by offering a SystemC export.
Using this procedural interface requires the ability to make C++
method calls, which is not possible using the standard DPI. Two

Copyright © 2010 by Doulos. 5

 iv. Put the SystemC module class definition in a header file static std::vector<scwrap*> instance;
named module_name.h and any member function static int count;
definitions in a file module_name.cpp int id;
};
v. Define any static variables or static members in the
module_name.cpp file, not in the header file.
The module constructor populates the vector of instance pointers:
vi. Include the following conditional compilation directives in
the module_name.cpp file for any SystemC module:
// C++
scwrap::scwrap(sc_module_name n)
: sc_module(n)
// SystemC {
#ifdef CADENCE m_scmod = new scmod("m_scmod");
NCSC_MODULE_EXPORT( module_name ); id = ++count;
#endif
instance[id] = this;
#ifdef MENTOR }
SC_MODULE_EXPORT( module_name );
#endif
The DPI function can now use the id member to send calls to the
correct target instance:
vii. Avoid intrusive changes to the original SystemC module
by instantiating it from a SystemC wrapper module that
implements the DPI funtionality. // C++
extern "C"
viii. Within the wrapper module, create a static data member void entry(int id, unsigned char cmd, int addr, int* data)
that stores a pointer to the C++ module instance this, and {
initialize the pointer from the constructor. This technique bus_t tx;
only works for a single module instance. tx.cmd = cmd;
tx.addr = addr;
ix. Have the C side DPI function assemble a transaction from tx.data = *data;
scwrap::instance[id]->m_scmod->execute( &tx );
its arguments as necessary, pass the transaction to the *data = tx.data;
corresponding method of the SystemC wrapper, and set }
any output arguments on return:
extern "C"
const char* get_path(int id)
// C++ {
scwrap* scwrap::instance = 0; // Static member return scwrap::instance[id]->name();
}
extern "C"
void entry(unsigned char cmd, int addr, int* data)
{ On the SystemVerilog side, the id is passed to the DPI call in order
bus_t tx; to differentiate between the SystemC module instances. A get_path()
tx.cmd = cmd;
tx.addr = addr;
DPI function is provided so that the SystemVerilog test bench can
tx.data = *data; identify which id corresponds to which instance. The test bench can
scwrap::instance->execute( &tx ); maintain a mapping between hierarchical paths and ids to make DPI
*data = tx.data; calls more convenient:
}

// SystemVerilog
import "DPI-C" function void entry(
input int id, input byte cmd, input int addr, inout int data);
7.3 DPI Guidelines: SV-to-SC, multiple instances import "DPI-C" function string get_path(input int id);

The above approach can easily be extended to handle multiple int path_to_id[string];
instances of the same SystemC module. Instead of having a single …
instance pointer in the wrapper pointing to the module itself, have a virtual function void end_of_elaboration;
vector of pointers: path_to_id[get_path(1)] = 1;
path_to_id[get_path(2)] = 2;
endfunction
// SystemC
class scwrap: public sc_module
{ Unfortunately, differences between simulator implementations cause
public: portability issues again. The SystemC name() method returns the
scwrap(sc_module_name n); hierarchical path in a different format in each case! Conditional
compilation can be used to patch up the differences:
scmod* m_scmod;

Copyright © 2010 by Doulos. 6

 // SystemC
// SystemVerilog #ifdef CADENCE
`ifdef CADENCE #define NCSC_INCLUDE_TASK_CALLS
id = path_to_id["top.m_hier.m_scwrap_1"]; #define CDN_OR_MEN
`endif #endif
`ifdef MENTOR
id = path_to_id["/top/m_hier/m_scwrap_1"]; #ifdef MENTOR
`endif #define MTI_BIND_SC_MEMBER_FUNCTION
`ifdef SYNOPSYS #include "sc_dpiheader.h"
id = path_to_id["top_m_hier_m_scwrap_1"]; #define CDN_OR_MEN
`endif #endif
entry(id, tx.cmd, tx.addr, tx.data);
// In module constructor
#ifdef MENTOR
SC_DPI_REGISTER_CPP_FUNCTION(entry);
What can one say? SC_DPI_REGISTER_CPP_FUNCTION(get_path);
#endif
Using this approach, with minor use of conditional compilation it
was possible once again to use precisely the same DPI calls and C++ // At file scope
code with an OVM test bench and simulators from Cadence and #ifdef CADENCE
Mentor, and with a VMM test bench and the Synopsys simulator. NCSC_REGISTER_DPI(entry)
NCSC_REGISTER_DPI(get_path)
#endif
7.4 DPI Guidelines: Timed SystemC Models
As mentioned at the outside, one premise of this paper was the In order to call a DPI export function from C++, we need to set the
requirement to integrate untimed reference models into a SystemVerilog scope. The programming interface to achieve this
SystemVerilog test bench. However, as an extension, we now (svGetScope, svSetScope) is part of the SystemVerilog language
consider timed SystemC models. standard. The scope can be determined from within the DPI import
function, and then used subsequently for the return call to the DPI
It is increasingly the case that timed SystemC models conform to the export:
OSCI TLM-2.0 standard. As described above, TLM-2.0 supports
both blocking and non-blocking transport interfaces for processing
regular transactions. Even models that do not conform to the TLM- // C++
2.0 standard typically use these same concepts. static svScope calling_scope;

To handle a timed SystemC model, because the DPI call itself must // DPI import
not be blocked by the SystemC scheduler (as discussed above), the extern "C"
response may need to be returned at a later time using a separate DPI void entry(int id, char cmd, int addr, int* data) {
call from SystemC to SystemVerilog. Hence we require both DPI …
calling_scope = svGetScope();
imports and DPI exports between SystemVerilog and SystemC.
}
The approach we have adopted is to use two DPI calls, a DPI import …
function that sends a request to the SystemC model (by passing small {
types as function arguments), and a DPI export function that sends a svSetScope(calling_scope);
response back to the SystemVerilog test bench at a later time (again
by passing small types as function arguments). Both can be simple // Call to DPI export
non-blocking function calls. This mechanism has similarities with tx_done(id, tx->cmd, tx->addr, tx->data);
}
the TLM-2.0 non-blocking interface, and like that interface, is able to
support multiple simultaneous pipelined transactions. However, our
approach does not require that either the SystemVerilog or the
SystemC model be TLM-2.0-compliant. In order to deal with multiple outstanding transactions, the SystemC
wrapper module maintains a pool of SystemC threads. Incoming
As a purely practical matter, linking SystemVerilog and SystemC transactions are allocated to the next free thread, and a thread
applications with function calls in both directions seems best handled remains tied to a transaction instance until the response has been
by switching to “DPI-SC” for Cadence and Mentor, while “DPI-C” returned to the SystemVerilog test bench and the transaction
is sufficient for Synopsys. As mentioned above, currently there are completed. The thread can then be returned to the pool and reused.
portability issues when making SystemC method calls using “DPI- Each thread has an associated event which, when notified, causes the
SC”, but the implementation of global C++ function calls through the thread to resume and process a new incoming transaction.
“DPI-SC” interface (or “DPI-C” for Synopsys) seem to be robust for
all simulators. Synopsys users also have the option of using the TLI, Each incoming transaction is handled by the SystemC wrapper as
but a premise of this paper is the desire to create portable code and to follows:
minimize reliance on vendor-specific features.
i. Assemble a new transaction object from the DPI arguments
To call global C++ functions at “DPI-SC” imports requires the use of ii. Associate the transaction object with the next free thread
vendor-specific function registration macros as follows: iii. Notify an event to cause the thread to resume

Each SystemC thread executes the following loop:

Copyright © 2010 by Doulos. 7

 It is true that the lowest common denominator between DPI
i. Wait for an event notification implementations uncovered by this work is substantially below the
ii. Call the blocking method of the SystemC module instance full level of capability of any of the individual simulators considered,
to implement the functionality requested by the test bench and also true that this level will change over time as vendors improve
iii. On return from the blocking method call the DPI export, their implementations. Users must make their own decision
unpacking any response attributes from the transaction and concerning the value of portability between simulators versus
passing them as DPI arguments exploiting the full capabilities of their chosen vendor.
iv. Delete the transaction object
8.1 Summary of the Common Approach
On the SystemVerilog side, the implementation of the DPI export
method can handle the response as follows: i. Pass only small types and logic vectors as DPI arguments,
that is, do not pass user-defined structs, open arrays, or
i. Check the response attributes passed as arguments multi-dimensional arrays
ii. Use the id argument to tie up with the request, for example
by executing a Verilog event trigger ->done_ev[id] ii. For untimed reference models (C/C++ or SystemC), use
iii. The transactor that generated the request can either block “DPI-C” imports only, that is, do not use DPI exports or
waiting for the response or can generate several pipelined “DPI-SC”
transactions without waiting
iii. For SystemC reference models, use a SystemC wrapper
There are some key points to note from the above: the actual DPI module that can assemble or convert function arguments
calls are all non-blocking; the blocking method of the target SystemC and re-direct incoming DPI calls to the appropriate
module is called from a SystemC thread in the wrapper; a thread pool SystemC module instance
is needed to support multiple pipelined transactions; and an id
argument is used to map global DPI calls to the module hierarchy iv. Have the DPI calls identify the target SystemC module
(see the description of multiple instances above). instance using an id argument

On the SystemVerilog side, the lifetime of each transaction will v. For timed SystemC models, use “DPI-SC” (Cadence and
extend beyond the call to the DPI import. Hence it is essential that Mentor) or “DPI-C” (Synopsys)
the test bench creates a new transaction object per transaction rather
than reusing the same object, which may still be “alive”. (This is vi. For timed SystemC models, have the SystemC wrapper
considered good practice anyway in both OVM and VMM.) The DPI maintain a pool of SystemC threads to call any blocking
export call that indicates the completion of the transaction is SystemC method
necessarily a global function call, rather than being a class method
call to the OVM component or VMM transactor that initiated the vii. For timed SystemC models, have the SystemC wrapper
transaction, so the programmer must contrive some mechanism to call a DPI export on completion of the transaction
communicate between the incoming DPI call and the initiator, based
on the id argument that is common to the outgoing and incoming viii. Have all DPI calls in either direction be non-blocking
DPI calls. From the SystemVerilog side, the incoming DPI export
call is effectively asynchronous with respect to the operation of the ix. Use conditional compilation as necessary to handle
test bench. The initiating component/transactor can either suspend differences in directives, headers, macro names, and
until it is notified of the completion of the transaction, or can hierarchical path names between simulators
continue to generate new transactions.

Garbage collection needs to be considered. Garbage collection in 8.2 Example Files

SystemVerilog is implicit, but on the C++ side the lifetime of
transaction objects needs to be carefully thought through such that
objects can be either deleted or re-used when they die. Example files to accompany this paper can be downloaded from
www.doulos.com/knowhow/systemverilog/
Once again, with this approach it was possible to use precisely the
same C++ code with an OVM test bench and simulators from 9. References
Cadence and Mentor, and with a VMM test bench and the Synopsys
simulator. On the SystemVerilog side, the DPI calls differed only in [1] IEEE Std 1800-2005 “IEEE Standard for SystemVerilog – Unified
that Cadence and Mentor used “DPI-SC” and Synopsys “DPI-C”. Hardware Design, Specification, and Verification Language,”

8. Conclusions [2] IEEE Std 1666-2005 “IEEE Standard SystemC Language Reference
Manual”
We set out to find a way of using the SystemVerilog DPI to call [3] OSCI TLM-2.0 Language Reference Manual, version JA32, 2009
C/C++ and SystemC reference models in a way that was simple,
robust, and portable between simulators. On the whole, the results [4] Bergeron, Cerny, Hunter and Nightingale. 2005 Verification Methodology
were very positive. We found an approach by which we were able to Manual for SystemVerilog. Springer ISBN-10: 0-387-25538-9
create a single body of C/C++ or SystemC code that is portable
between all current simulators, albeit by imposing some restrictions [5] VMM Standard Library User Guide, Version 1.2, November 2009
on the DPI features used.
[6] OVM Class Reference, Version 2.0.2, June 2009

Copyright © 2010 by Doulos. 8

Copyright © 2010 by Doulos. 9