Subject: Re: [sv-cc] Polls on extern/export and representation of SV data types
From: Stickley, John (john_stickley@mentorg.com)
Date: Mon Mar 10 2003 - 11:38:21 PST
Team,
Joao Geada wrote:
> Doug,
>
> well, the rules already exist: basically, this effect can be obtained by excluding
> DPI func calls from the definition of constant_function_call and therefore from
> constant_expression (see page 247 on the SV3.1 draft 3 LRM)
>
> Strictly, there is no particular reason why "pure" DPI functions could not be
> used, but there is no way for the compiler to check whether a "pure" function
> is really pure or not.
> I am not religious about this, merely thought that this would be a useful
> constraint for compiler simplicity/safety, specifically to:
> a) avoid having to have the compiler support all the library loading mechanism(s)
> b) avoid having to have the compiler actually create all the data needed by DPI
> (note that prior to this there has been no requirement that the compiler maintain
> actual value datastructures and/or context hierarchies)
> c) (user) it is likely that user code will be making assumptions that it is running
> in a "simulator", rather than during the compilation stage. This may lead to
> invalid/incorrect usage of interfaces and even use of unavailable intefaces
> on the part of the user.
I don't feel terribly strongly one way over the other about
this either except again, I would tend to favor Joao's
opinion which, BTW, also happens to obey the Doug Warmke
"early restriction, later expansion" rule ! :-)
It might be OK to relax the rule for pure functions as
Joao suggests. In this case an application may have
to suffer the consequences of attempting to use
an impure function disguised as a pure function in the
declaration.
But then such consequences are at risk of occurring whether
non-compliant "pure" functions are called at elab time or run
time aren't they ?
As for context functions there are two approaches we can
consider:
1. Not allow calling of exported functions during elaboration
(what I think Joao favors)
2. Allowing them in a "use at your risk" mode. For example,
if svGetContextByName() returns an error or an invalid
context pointer, the application should assume that it
is attempting to call it at such a time that that elaboration
of the SV side has not yet occurred. Or, better yet
there would be a specific error indicating that.
It seems that, depending on what C environment is being
used, user's will clearly see where they get these errors
and where they don't.
Most likely calls of exported functions using default
context will never fail because, by the time they are
called from the surrounding extern function, that function's
module will have already been elaborated.
We really need to pay close attention to how these dynamics
work in a pure SV world and, again, not stray too far from
that.
3. Alternatively, perhaps it can be left up to the vendor to
guarantee that a given C environment such as SystemC would not
invoke "sc_main()" until it knows that SV environment
has been elaborated. In this case, all calls under sc_main()
could safely know that elaboration has already occurred
and that calls to exported functions at arbitrary contexts
is allowed.
>
> Joao
> ==============================================================================
> Joao Geada, PhD Principal Engineer Verif Tech Group
> Synopsys, Inc TEL: (508) 263-8083
> 344 Simarano Drive, Suite 300, FAX: (508) 263-8069
> Marlboro, MA 01752, USA
> ==============================================================================
>
>
> -----Original Message-----
> From: Warmke, Doug [mailto:doug_warmke@mentorg.com]
> Sent: Monday, March 10, 2003 1:26 PM
> To: 'Joao.Geada@synopsys.com'; 'sv-cc@server.eda.org'
> Subject: RE: [sv-cc] Polls on extern/export and representation of SV
> data types
>
>
> Joao,
>
> 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).
>
> 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.
>
> Thanks and regards,
> Doug
-- johnS
__
______ | \
______________________/ \__ / \
\ H Dome ___/ |
John Stickley E | a __ ___/ / \____
Principal Engineer l | l | \ /
Verification Solutions Group | f | \/ ____
Mentor Graphics Corp. - MED C \ -- / /
17 E. Cedar Place a \ __/ / /
Ramsey, NJ 07446 p | / ___/
| / /
mailto:John_Stickley@mentor.com \ /
Phone: (201)818-2585 \ /
---------
This archive was generated by hypermail 2b28 : Mon Mar 10 2003 - 11:43:12 PST