Subject: C++ APIs for simulators
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Fri Jul 12 2002 - 15:30:04 PDT
[Just for discussion]
C++ incompatabilities across compilers arise from two features
a) Name Mangling
User function names are modified to include their
argument list types for overloading in an inconsistent
manner in the generated code.
b) Virtual Functions
The C++ objects contain references to "virtual functions"
which are implemented in a compiler dependent manner.
So if you want to use C++ for user code called from SystemVerilog
it needs to use a C bridging interface to avoid the name-mangling,
and avoid direct use of virtual functions back into the simulator
when the compilers are different.
The second level of incompatibility is that the internal data for
logic types differs between simulators. Which means that any
direct reference to simulator data needs to be through a "class"
interface supplied by the simulator vendor.
If the user code is compiled with the same compiler as the
simulator then C++ interfaces should be capable of being direct
as with C, e.g.:
SV:
extern "C++" integer MyFunc(reg &);
extern "C++" integer MyFunc(integer);
...
reg [12:0] data;
...
i = MyFunc(data); // Call C++ user code
C++:
#include "sv_types.h" // Vendor supplied
integer MyFunc(reg &dp)
if (dp.X()) return (-1);
if (dp.Z()) return (-2);
return dp;
}
The C++ include file "sv_types.h" would include class definitions
for the types "reg" and "integer" and their "methods" - in this
case the functions "X()" and "Z()" (which may be virtual) and a
method to convert reg to integer.
When the compilers are not the same the user code should not have
to change. This can be achieved by the compiler for SystemVerilog
generating it's own name-mangled version of the call in C, and
generating a C/C++ code snippet for compilation by the users
compiler, e.g.:
SV Name-Mangling (what the simulator actually calls):
MyFunc(reg &) -> SV__MyFunc__rr(void *)
MyFunc(integer) -> SV__MyFunc__i(integer)
C++ snippet to be compiled and linked with user code:
#define SV_NOT_NATIVE // Use portable interface
#include "sv_types.h" // Vendor supplied
integer MyFunc(reg &);
extern "C" integer SV__MyFunc__rr(void *a0) {
return MyFunc((reg *)a0);
}
integer MyFunc(integer);
extern "C" integer SV__MyFunc__rr(integer a0) {
return MyFunc(a0);
}
If this kind of approach is used then the CC committee needs to define
a generic/portable version of the "sv_types.h" include file with a set
of classes and the methods for the common simulator objects. Vendors
would supply support for the generic "sv_types.h", and optionally their
own "sv_types.h" for more direct access (using inlining and virtual
functions).
The name mangling scheme would be defined by the committee.
Kev.
-- National Semiconductor 2900 Semiconductor Drive, Mail Stop D3-500, Santa Clara, CA 95052-8090
This archive was generated by hypermail 2b28 : Fri Jul 12 2002 - 15:32:21 PDT