SystemVerilog data types
are the sole data types that can cross the boundary between SystemVerilog and a
foreign language in either direction (i.e., when an imported function is called
from SystemVerilog code or an exported SystemVerilog function is called from a
foreign code). It is not possible to import the data types or directly use the
type syntax from another language. With some restrictions
and with some notational extensions, most SystemVerilog data types are allowed
in DPI.
A rich subset of
SystemVerilog data types is allowed for formal arguments of import and export
functions, although with some restrictions and with some notational extensions.
Function result types are restricted to
small values, however (see Section 26.4.5).
DPI consists of two
separate layers: the SystemVerilog layer and a foreign language layer. The
SystemVerilog layer does not depend on which programming language is actually
used as the foreign language. Although different programming languages can be
supported and used with the intact SystemVerilog layer, SystemVerilog 3.1
defines a foreign language layer only for the C programming language.
Nevertheless, SystemVerilog code shall look identical and its semantics shall
be unchanged for any foreign language layer. Different
foreign languages will require, of course, that the SystemVerilog
implementation shall use the appropriate function call protocol, argument
passing and linking mechanisms. This shall be, however, transparent to
SystemVerilog users. SystemVerilog 3.1 requires only that its implementation
shall support C protocols and linkage.
Every function imported to
SystemVerilog must eventually resolve to a global symbol. Similarly, every
function exported from SystemVerilog defines a global symbol. Thus the
functions imported to and exported from SystemVerilog have their own global
name space of linkage names, different from
$root name space. Global names of imported and exported functions must be
unique (no overloading is allowed ) and shall
follow C conventions for naming; specifically, such names must start with a
letter or underscore, and may be followed by alphanumeric characters or
underscores. Exported and imported functions, however, may be declared with
local SystemVerilog names. Import and export declarations allow users to
specify a global name for a function in addition to its declared name. Should a global name clash with a SystemVerilog keyword or a
reserved name, it shall take the form of an escaped identifier. The leading
backslash (\) character and the trailing whitespace
will be stripped off by the SystemVerilog tool to create the linkage
identifier. Note that after this stripping, the
linkage identifier so formed has to comply with the normal rules for C
identifier construction. If a global name is not explicitly given, it
will be the same as the SystemVerilog function name. Example:
export
"DPI" foo_plus = function
\foo+ ; // "foo+"
exported as "foo_plus"
export
"DPI" function foo; // "foo" exported under
its own name
import
"DPI" init_1 = function void \init[1]
(); // "init_1" is a global name the linkage name
import
"DPI" \begin = function void \init[2]
(); // "begin" is a linkage name
With some restrictions and with
notational extensions, all SystemVerilog data types are allowed for formal
arguments of imported functions.
A rich subset of
SystemVerilog data types is allowed for formal arguments of import and export
functions. Generally, C compatible types, packed types and user defined types
built of types from these two categories can be used for formal arguments of
DPI functions. The set of permitted types is defined inductively.
The following
SystemVerilog types are the only permitted types for formal arguments of import
and export functions:
—
void,
byte, shortint, int, longint, real, shortreal, handle,
and string
—
scalar values
of type bit and logic
—
packed
one dimensional arrays of type bit and logic
Note however,
that every packed type, whatever is its structure, is eventually equivalent to
a packed one dimensional array. Therefore practically all packed types are
supported, although their internal structure (individual fields of structs, multiple dimensions of arrays) will be transparent
and irrelevant.
—
enumeration
types interpreted as the type associated with that enumeration
—
types
constructed from the supported types with the help of the constructs:
—
struct
—
unpacked
array
—
typedef
The following
caveats apply for the types permitted in DPI:
—
Enumerated data
types are not supported directly. Instead, an enumerated data type is
interpreted as the type associated with that enumerated type.
—
SystemVerilog
does not specify the actual memory representation of packed structures or any
arrays, packed or unpacked. Unpacked structures have an
implementation-dependent packing, normally matching the C compiler.