Subject: Re: DirectC proposal: Issues to discuss at today meeting
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Tue Nov 19 2002 - 08:50:36 PST
Hi,
Answers to Francoise's questions are interspersed below.
Andrzej
> Date: Thu, 07 Nov 2002 10:21:05 -0500
> To: sv-cc@eda.org
> From: Francoise Martinolle <fm@cadence.com>
> Subject: DirectC proposal: Issues to discuss at today meeting
>
>
> 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?
- reportedly Co-Design's customers use such feature (C calls V)
- yes, this will complicate the implementation of a directC function
call because of threads switching
- very likely it's merely (?) a matter of convenience; I suppose that each
example that uses ability to call SV from C may be rewritten to pure
0-time C function calls.
> 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?
This seems to be a misunderstanding, and apparently I'm at fault
for not expresssing my ideas clearly.
I tried very hard though unsuccessfully to make the team see both
sides (layers?) of the interface separately.
For the SV semantics the issue of passing SV data to C by value
or by reference simply does not exist. This is (should be!) transparent.
Therefore nowhere in the proposal the issue of the actual implementation
was addressed.
Issue 'pointer vs. value' will be relevant when we start discussing the 'outer
layer' of the interface, i.e. how C code may acccess it's formal arguments.
> 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?
Why shall we? This is implementation issue, not semantical (mind inouts!).
>
> 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.
Well, perhaps the way I presented it was clumsy. What I wanted to achieve
was to discuss the supported types in a stepwise manner, starting from
the simplest and obvious and gradually adding more complex/controversial.
So I don't see contradictions here.
> 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.
Yes, this is a better idea.
BTW, the whole "17 items" proposal was organized in a similar way,
by presenting piece by piece what shall be included in the interface.
So no statement "xxx is supported" should read "xxx and only xxx is supported".
> 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,
You're absolutely right. Somehow I missed them. Corrected.
> Issue 11.2: What about the Verilog 2001 data types: reg,
> integer?
Both are 4-value. The team decided to remove logic from (11), so I guess
this applies also to reg and integer.
> Issue 11.3: what is the data type "type"?
It's the proof of the lack of proofreading on my side.
> Issue 11.4: What about vectors and arrays of bit or logic
> types (2 state bit vectors or 4 state bit vectors and arrays
Both included in (14).
> The data type restrictions do not allow to pass simulation
> objects such as nets, regs and vars.
Regs and vars may be passed, not nets. ("reg" as a type? logic will do?)
> 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. [...] 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
Excellent point! Thanks! I missed it. Team work pays off :-)
Yes, this may be a problem.
In the revised proposal I'm shifting the burden to the programmer, who
will be responsible for correct handling the restored pointers in her/his
C code (some allpies for garbage collection employed on non-SV side).
SV implementation will only guarantee that save/restore will preserve
the original values.
> ii) Such variables of pointer type need to
> have different simulation semantics than regular SV variables.
Yes. See restrictions in (12).
> 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.
Right.
> iv) we loose the type pointer information
> when passing back a pointer from SV to C
> since it is a generic pointer.
Not really. We may use typedef to create different flavours of pointers.
> 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.
This is confusing. There is a lot of similarities between C and SV,
some types are shared by both languages, but not all.
> 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.
Right. I assumed (Mistake! This must be explicitly stated!)
that the representation of int, char, byte, shortint will be
that of C. Similarly, SV LRM should clearly map other basic
types (real, shortreal, realtime, time) onto C types.
> 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.
This is the real issue. It may and should be shifted to the second
layer of the interface (non-SV side).
> 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.
It shall be user's responsibility to provide a pair of semantically
equivalent definitions of types: one to be used in SV, the other one
to be used in C code.
Sometimes the same text can be interpreted both as a valid definition
is C and as a valid definition in SV, sometimes minor syntactical changes
may be required. SV compiler may help by generating the corresponding
C definitions for SV definitions used in the external declarations.
> Issue 12.2 How this implicit /automatic conversion of data types
> and values is
> performed should be clearly defined.
There will be no conversion at all.
> The way of doing it may be to automatically derive
> the C function definition
> from the SV external function declaration.
Indeed. VCS DirectC does it. I believe this is the way to go.
>
> 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.
Corrected. See (14) in the revised proposal.
> 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.
Indeed.
> 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.
Well, roughly speaking only ...
One may define by the induction the set of types common to both languages,
funded on the basic 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.
I meant =packed= structures/arrays, aka vectors.
BTW, the layout of unpacked structures =is= platform dependent
and SV simply refers to C implementation. "We'll do what C does."
> 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.
Yes. This is the bottom line.
> 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).
It's more complicated than that. Size of chunks of bits? Endianess?
Or, perhaps, each single bit (bit/reg/logic) in a separate byte? Etc, etc.
But yes, very likely we won't be able to avoid defining some layout
for the API. VCS DirectC had to do this even with the abstract access mode.
> 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.
It may be a performance killer; consider a large array of structs
with 4 state vectors inside ...
> Issue 13.4: are structures passed by copy or reference?
Wrong question for the SV layer of the interface. This is irrelevant.
> 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.
Exactly.
>
> Issue 14.2 what about arrays? why not allowing
> multi-dimensional arrays or memories
Well, originally they were allowed as actual arguments, if after linearization
they matched the 1-dimensional formal arg.
> 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
Again; not addressed her.
> 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?
The layout visible in C will be that of SV.
Technically speaking, an array is just a contiguous group of individual
elements. In C they will be always indexed 0 .. n-1.
The permutation (layout) defined by SV.
> Issue 15.2: in case of arrays, vectors, what order do the
> parameter indices
> comes out in C? How are they received?
Don't understand the question.
> 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?
Pointer to an array of "chunks of data".
If size is known, than an array of chunks will be used.
> Issue 16.2: How are they passed to C?
Again; not addressed her. (In VCS DirectC: by pointer in direct mode,
by a handle in abstract mode.)
> 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.
Yes. Additionally, there is an issue of masking, if not all bits
are used. But this is normal in C programs?
> Issue 16.4: How are unpacked open arrays laid out on
> the C side?
SV layout.
> 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...
Right. Another overlook. Corrected.
> 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?
That's why I proposed to restrict the size of 2-state vectors returned
as a function result.
Francoise, thank you for your very thorough analysis!
Andrzej
This archive was generated by hypermail 2b28 : Tue Nov 19 2002 - 08:51:15 PST