Subject: Re: DirectC: C layer
From: Joao.Geada@synopsys.com
Date: Thu Dec 12 2002 - 11:16:19 PST
Hi Francoise, Jay, Steve:
here are the answers to your issues:
1- propagation:
this was already fully defined, in the SV side of the DirectC interface, in
the 18 part proposal made by Andrzej (items: 3 in general, 10 and 10c specifically)
The summary of those points: propagation occurs *only* at the end of the directC
function call and *only* for output and inout arguments. This is consistent with
current Verilog & SV rules. Please also note that you have already voted
and accepted those particular points.
As long as the user's C code complies with the interface constraints (specifically
in this case the applicable restriction is that you cannot write to input args)
I do not believe there is any issue; as for the case where the user's C code does
not comply with the defined constraints: I do not believe it is meaningful to state
what the operation of the interface would be in the presence of user coding errors.
I have no issue with stating that input args have to be declared "const", but as
I pointed out in a previous email this still does not prevent a programmer from
writing to inappropriate locations.
2- dimensions of objects
Please remember that there *must* be a extern declaration for all directC
functions. That declaration must declare the types of all arguments.
If this declaration declares the port to be a fixed size type, is it really too
much to presume that the C coder knows these dimensions? I believe not. In fact,
this is a very common C and C++ idiom. (arrays are passed by reference and
if they are of fixed size, it is the programmers responsibility to remember the
size)
In the case of open arrays and vectors, the interface provides means to determine
what the size of the object passed in was, so again there is no issue here, IMHO..
3- Internal representation:
the whole idea is generally that internal representation is *deliberatly* left
unstated.
Please note that *you* have the flexibility to state that *for your simulator*
the canonical and internal representations are identical *and* you also have
the flexibility to make this so by always using copy-in and copy-out between
the internal representation and this canonical representation across the
direcC interface boundary. Your choice.
This approach would permit a naive implementation to support this interface
while not restricting other simulation teams from implementing the interface in
more interesting and higher performance ways.
And regardless of the approach, a user can use the "canonicalizing" routines
to make their code work with your simulator or anybody else's simulator that
satisfies this interface specification.
As a final point, I would once again like to restate the point I made at yesterday'
phone conference:
The DirectC interface does not, strictly, provide new *functionality* (The ability to
call C code from Verilog has existed in both PLI and VPI). What the DirectC interface
provides is a high-performance, high-convenience solution to this problem.
This has proved to be a very desirable and highly used approach.
In our suggestions for "enhancements" etc to this interface, please, PLEASE, lets
not forget these fundamental original requirements.
More directly, I do not believe it is worthwhile, for myself or this committee, to
consider any approach that violates either of these two prime requirements.
Joao
==============================================================================
Joao Geada, PhD Principal Engineer Verif Tech Group
Synopsys, Inc TEL: (508) 263-8083
154 Crane Meadow Road, Suite 300, FAX: (508) 263-8069
Marlboro, MA 01752, USA
==============================================================================
This archive was generated by hypermail 2b28 : Thu Dec 12 2002 - 11:17:04 PST