Subject: DirectC proposal: Issues to discuss at today meeting
From: Francoise Martinolle (fm@cadence.com)
Date: Thu Nov 07 2002 - 07:21:05 PST
I generally agree with points 1 through 10, but I have some questions
except for :
point #2. In Andrzej's proposal, C functions execute in zero time ( are non
blocking).
Do we think that there is a user requirement for C functions
to wait? May be
testbenches need that? Once we allow C to call SV tasks, the
C function could
potentially wait if the SV task suspends. This can very much
complicate the
implementation of a directC function because the simulator
kernel will have to
make the assumption that the directC function may wait and
create a thread to
call the C code.
I am really questioning whether or not someone knows of a
real requirement to
allow C functions to wait and or to call SV tasks and functions?
point #10: copy-in, copy out rule.
Issue 10.1: I generally agree with this statement but I
want to note that there are some
issues to sort out when the data to copy
is pretty large and of large and does not
fit into a C type. Do we then pass a
pointer to a value? How does the C
code knows how big is the value?
Issue 10.2: do we want to allow the caller to specify that
onecan pass a parameter by reference
with for example : myfunc(ref arr) on the
SV side?
The major issues I have, reside with the allowed data types for C functions
and the SV/C data type
layout compatibility. Points 11 through 17 are trying to define the data
types allowed for C functions.
Some of the points have contradictory statements with respect to the data
types they allow.
Point 11 only allows basic data types, while 12, 14, 16 allow more data types.
These points can be grouped into a single requirement which list all the
data types allowed for formal
arguments of C functions.
point #11: Formal arguments data types and return type of the C function
In Andrezj proposal, only the following data types are allowed:
. only the new SV basic types such as int,
real, byte, type and short,
. the SV scalars data types of bit or logic type
. the new SV primitive types: pointer and string
Issue 11.1: some SV types seem to be missing: long,
longint, char,
enumeration types, shortreal, void, time,
Issue 11.2: What about the Verilog 2001 data types: reg,
integer?
Issue 11.3: what is the data type "type"?
Issue 11.4: What about vectors and arrays of bit or logic
types
(2 state bit vectors or 4 state bit
vectors and arrays
The data type restrictions do not allow to
pass simulation
objects such as nets, regs and vars.
Issue 11.5: Passing generic C pointers and strings (pointer
to C like string)
Passing pointers from C to SV and store
them in SV variables. This allows to
pass large values by reference rather than
copying large values but it
requires that we take care of critical
features such as:
i) save/restart capability if pointer
memory is allocated by the
C code
ii) Such variables of pointer type need to
have different simulation
semantics than regular SV variables.
iii) such pointer memory is owned by the C
code and the simulator
may crash on an invalid pointer. These
pointers can only
be dereferenced by the C code.
iv) we loose the type pointer information
when passing back a pointer from SV to C
since it is a generic pointer.
point #12 Data types correspondence between SV and C
SV with its new data types appears to have everything it
needs to represent C data objects
however Andrzej argues that there is much compatibility
between SV and C data types.
Issue 12.1: SV/C Data type compatibility
i) There are some new data types defined in SV.
There should be some
level of layout compatibility between SV and C.
At least the basic C-like
data types should be made entirely compatible
with C.
ii) For the 4 state or 2 state logic types, there
should be some definition of
implicit conversion of data and C data type
mapping from SV to C and
vice versa.
iii) The biggest compatibility problem arises with
SV structures and C structures.
Do we allow them to be passed to C functions?
SV structures can contain
fields of any type and a mix of C-like types
and SV types and even C like
pointers or SV pointers fields.
In theory, some rules can be defined for
mapping SV structures to
equivalent C structures; but what do we do if
a SV structure contains a
pointer? The SV 3.0 LRM seems to indicate that
unpacked structure have
a layout compatibility with the C structure.
Does the Cblend interface
allowed it? We should be able to get input
from the co-design team.
iv) what about SV unions?
If SV defines unions, structures,
enumerations, which are fundamental
C types, it would look strange if there is no
compatibility with C.
Issue 12.2 How this implicit /automatic conversion of data types
and values is
performed should be clearly defined.
The way of doing it may be to automatically derive
the C function definition
from the SV external function declaration.
point #13: Complex data types: layout of SV structs and 2-4 state vectors
Andrejz proposal indicates that layout of C structs should
be the same as the layout on C
but he does not allow SV structures to be passed to C.
Having C-like data structures on the SV side and to
directly pass objects of that type
to a C function is one fundamental building block that we
can use to provide more general
communication capabilities (e.g. FIFOs, testbench, packet
modeling) between the C and
the SV side.
Issue 13.1: Andrejz 's statement seems to be in
contradiction with point 12
where it is said that there is no common
types between SV and C other
than the basic arithmetic types.
Issue 13.2: The SV 3.0 LRM page 10-11 says that an unpacked
structure has an
implementation dependent packing, normally
matching the C compiler.
This seems to indicate the willingness to
have SV unpacked structures be
layout compatible with C structures.
Issue 13.3: Andrezj's proposal says that we should not
specify the layout of 2-4state
vectors as they can be platform dependent.
The simulator layout may not be specified
but there should be some data
conversion definition between SV 2/4 state
vectors and some C data type.
A conversion can be defined to show SV
4state vectors as ab vector pairs
in C (similar to how VPI interprets the
value of a 4 state vector).
The C code can be isolated from layout
differences on the SV side by
clearly defined conventions for
transforming the value from SV to C.
If we go with the scheme that actual
arguments of a C function are copy-in,
copy-out, that conversion can itself take
place from SV before it calls the C
function.
Issue 13.4: are structures passed by copy or reference?
point #14: Additional data types for formal and return types: packed 1 dim
vectors of type bit/logic
and unpacked 1 dim arrays of packed 1 dim vectors of bit/logic
Issue 14.1 same as 13.1. It looks like that the
proposal is to broaden the data
types allowed.
Issue 14.2 what about arrays? why not allowing
multi-dimensional arrays or memories
Issue 14.3: are vectors/arrays passed by copy? May
be too large to fit in a C data type
Issue 14.4: return type conflicting with point 17
point #15: normalization to [n:0]
Issue 15.1: I don't quite understand the sentence.
what is the layout in C of an
argument which data
type in SV is a vector defined as
[1:8] or defined as [8:1]
C array index starts at 0, what
would be arr(0) referring to in the cases
of bit [1:8] v and bit [8:1] v?
Issue 15.2: in case of arrays, vectors, what order do the
parameter indices
comes out in C? How are they received?
point #16: size of packed dimension or unpacked dimension or both dimension
may be open
Issue 16.1: what would be the C data type for such a
formal argument?
Issue 16.2: How are they passed to C?
Issue 16.3: allowing open arrays can lead to
accidental out-of-range
references if these arrays can be
larger than a single word. And if they
are restricted to small C scalar
types, the flexibility is pretty limited.
Issue 16.4: How are unpacked open arrays laid out on
the C side?
point #17: Functions can only return logic, bit, bit [n:1] where n <=32
Issue 17.1: very restrictive, what about the other SV
types: real, short, pointer, string...
Issue 17.2: In case of vectors where n > 32, or
arrays, How is the value returned?
Who allocates memory? How long is
the returned value valid for?
This archive was generated by hypermail 2b28 : Thu Nov 07 2002 - 07:21:45 PST