Subject: RE: [sv-cc] Polls on extern/export and representation of SV data types
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Mon Mar 10 2003 - 11:32:13 PST
Joao,
I think your reasoning is pretty good here.
Especially, I now agree (due to your (c) point)
that the most we should allow is "pure" functions
to be called at elaboration time.
Perhaps we can bring this up in the meeting tomorrow.
I'm glad to see that if we do decide to restrict
external function calls during elaboration, that it
will be relatively easy to unambiguously explain
this in the LRM.
Regards,
Doug
> -----Original Message-----
> From: Joao Geada [mailto:Joao.Geada@synopsys.com]
> Sent: Monday, March 10, 2003 11:07 AM
> To: Warmke, Doug; 'Joao.Geada@synopsys.com'; 'sv-cc@server.eda.org'
> Subject: RE: [sv-cc] Polls on extern/export and
> representation of SV data types
>
>
> 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.
>
> 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
>
This archive was generated by hypermail 2b28 : Mon Mar 10 2003 - 11:33:20 PST