Subject: RE: DirectC: C layer
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Sun Dec 15 2002 - 10:20:11 PST
Joao, others,
The current C-side proposal for arrays of known dimensions
has a pretty big drawback that was detailed last week by
John Amouroux. It seems that no one else is picking up
on this limitation.
Namely, it is difficult and unwieldy to provide a common C
function that can self-parameterize to process array
arguments of well-known but different lengths. (i.e.
non-open array args, with different lengths specified
at different call sites)
Currently the only way to do that is to pass an extra integer
argument (or two or three) to indicate the length of the
array arguments.
That is not *terrible*, but it is somewhat clumsy.
On the other hand, I don't see a more natural technique.
The only thing I can think of is to provide handle-based
access to both open arrays and arrays of known size.
I guess we would need to extend the declaration syntax
for extern functions that use known-size arrays but would
like to use handle-based access. But then we are back to
giving the user a choice between direct and abstract modes,
in violation of our vote for proposal c) (no redundancy).
I would really appreciate it if you could address this problem
in the proposal for the C-side. At the least, it would be nice
to make a sub-section regarding "parameterizing C functions
for arrays of different lengths", and acknowledge that the user
will have to control this functionality through the use of
extra integer input arguments.
Thanks and regards,
Doug
-----Original Message-----
From: Joao.Geada@synopsys.com
To: Francoise Martinolle
Cc: Andrzej Litwiniuk; sv-cc@server.eda.org; lawrence@cadence.com;
sharp@cadence.com; Joao Geada
nt: 12/12/2002 11:16 AM
Subject: Re: DirectC: C layer
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 : Sun Dec 15 2002 - 10:20:36 PST