Subject: RE: [sv-cc] elaboration time calls of DPI functions
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Mon Mar 10 2003 - 17:09:57 PST
Andrzej,
Good points. Please see embedded responses.
Regards,
Doug
> -----Original Message-----
> From: Andrzej Litwiniuk [mailto:Andrzej.Litwiniuk@synopsys.com]
> Sent: Monday, March 10, 2003 5:01 PM
> To: Warmke, Doug
> Cc: sv-cc@eda.org
> Subject: Re: [sv-cc] elaboration time calls of DPI functions
>
>
> > DOUG:
> >
> > Not clear on why you feel so strongly about prohibiting extern
> > functions from being called at elab time. Mechanically, non-context
> > elab-time DPI functions should be easy enough to support, and
> > theoretically 100% safe (provided the user didn't do crazy
> stuff, as
> > they can always do almost anywhere).
>
>
> The boundaries between compilation, elaboration and
> simulation seem blurred. I see major issues with SV compiler
> calling a function intended as a part of a design (although
> interpreters may have no problems with it). External
> functions shall not be classified as "constant functions".
> Think about cross-compilation. (For example, VCS can run on
> 64-bit platform and yet generate a code to be run on 32-bit
> platform) External function may happen to be unexecutable
> from compiler or unavailable at compile time.
DOUG: Agreed. This is delving into implementation configurations,
and we need to stay out of that business if possible. It would
seem that disallowing any external function call at elaboration
time (or compilation time in some cases, have we have seen)
is a good idea for now.
There is another thought we had during internal discussions, related
to C object inclusion. In some simulators the user's object code
is loaded by dynamic object at elaboration time. There is a
chicken-and-egg syndrome developed at that point regarding using
external functions during elaboration: When during elaboration
should the dynamic object be loaded? Obviously before any call
to an external function. This kind of constraint may be difficult
to meet for some implementations, perhaps involving additional
passes through the already complicated elaboration required for
Verilog.
In a nutshell, you guys have convinced me to dump support for
calling external functions at elaboration time, so I withdraw
any (implicit) proposal I may have made in that regard. Does
anyone object to disallowing external functions of any kind
in the role of "constant function" in the LRM? If not,
please adjust my LRM edits accordingly, Andrzej.
>
>
> > My feeling is that if we disallow any external function
> > from being called at elab time, usability will decrease.
> Because it's
> > not clear to users exactly *when* elaboration is occuring. So a
> > function call at one site will produce a system error,
> whereas in at
> > another site it will be OK. Do we want to explicitly list
> out all call
> > sites that would be considered "elaboration time"?
> >
> > If we allow any non-context function to be called, the incidence of
> > users getting compile errors will decrease. I am open to
> restricting
> > to pure as well.
>
>
> The above makes me wondering, whether all external functions
> are "equal". (Most likely they are not.) Is it so that
> depending on a call site (a syntactical context of a call)
> and a property pure/context/default, a particular function is
> allowed or not?
DOUG: Seems to be they are not "equal".
Any external function from a call site mandating a
'constant function' should be disallowed.
>
>
> Regards,
> Andrzej
>
This archive was generated by hypermail 2b28 : Mon Mar 10 2003 - 17:11:08 PST