Subject: [sv-ec] Re: [sv-cc] RE: sv-cc 2 sv-ec: extern/export requirements
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Tue Jan 28 2003 - 16:25:39 PST
> From: "David W. Smith" <david.smith@synopsys.com>
>
> Thanks,
> I have posted this to the Extension proposals for SV-EC as EXT_20
> (http://www.eda.org/sv-ec/Extensions.html). Once you get the proposal
> defined I will post it here as well.
[ Issue AI-44 relates to extern declarations ]
> The SV-EC will then review both this and the Handles, make editorial and
> other corrections, add to the LRM, and get concurrence from SV-CC that it
> meets the requirements.
>
> Regards
> David
If possible I'd like to add a requiremnent/wish that the syntax for extern
functions matches C syntax as much as possible so that the same header
files can be used for SV and C/C++. The last project I worked on that used
C & Verilog had seperate headers and it's a pain keeping them in sync.
E.g. if you run the SV version of the header through cpp you can define
things like "context","pure","inout" etc. to be null, so any extra info
for SV should be defined in a way that can be considered as a macro
definition in C. Similarly it would be nice if the extern definitions
for existing C libraries where directly usable (after going through cpp).
Regards,
Kev.
> David W. Smith
> Synopsys Scientist
>
> Synopsys, Inc.
> Synopsys Technology Park
> 2025 NW Cornelius Pass Road
> Hillsboro, OR 97124
>
> Voice: 503.547.6467
> Main: 503.547.6000
> FAX: 503.547.6906
> Email: david.smith@synopsys.com
> http://www.synopsys.com
>
>
>
> -----Original Message-----
> From: Joao Geada [mailto:joao@Synopsys.COM]
> Sent: Monday, January 27, 2003 3:07 PM
> To: David Smith
> Cc: sv-cc; Andrzej I Litwiniuk; Ghassan Khoory
> Subject: sv-cc 2 sv-ec: extern/export requirements
>
>
> David,
>
> please find below the requirements from sv-cc for extern and export
> declarations. Note that these are just the requirements, without the
> proposed syntax, or LRM description. I'll send the sv-cc LRM extensions
> proposal for these items once we have reached a proposal in sv-cc that is
> fully consistent with the current LRM.
>
> Joao
>
>
> 1. export declarations:
>
> - means to declare that a SV function is to be made accessible to a foreign
>
> programming language (eg C);
> - specifying a function as exported does not change its semantics nor usage
> - must allow an optional identifier to be used in the foreign code;
> by default foreign name and SV name will be identical
> - must provide full hierarchical path identifying a unique instance (unless
> $root scope function)
> ## Note that tasks may not be exported; therefore there is no need for
> redundant
> keyword "function"; similarly there is no need for repeating function
> result types and argument specification. However such redundancy may be
> desirable for language consistency.
>
> 2. extern declarations:
>
> - means to declare that a SV visible function is to be provided by
> a foreign programming language (eg C) (ie function's body is foreign)
> - must provide function result type and directions and types of formal
> arguments; the syntax should be as close as possible to the syntax
> for SV function declarations;
> note that DirectC extends the syntax for specifying types of formal
> arguments
> by allowing unsized ranges, denoted by '[]'.
> - in SV syntax, invocation of the functions declared as extern must be
> identical to invocation of any other normally declared SV function
> - additionally provide further information about the function.
> Specifically,
> as SV compiler will not have visibility into the implementation of the
> function, it needs to know:
> i) whether the function is 'pure', meaning all invocations with same
> arguments result in the same output values and have no side effects
> whatsoever; 'pure' function must not have inout or output arguments.
> ii) whether the function needs to be aware of its context (such as
> current
> instance)
> iii) whether the function will make use of any other SV API such that
> it
> may access (read or write) signals other than those being passed
> through the function's argument list.
>
> Actually, we plan to bundle ii) and iii) together, they are also
> mutually exclusive with i); therefore there are 3 possible
> combinations:
> 1) default 2) 'pure' 3) 'context' denoting (ii)+(iii)
>
> ## - optional: identifier representing the foreign function name. Only for
> symmetry with export declaration, but this is not required by sv-cc.
>
>
> 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
> ============================================================================
> ==
>
>
>
This archive was generated by hypermail 2b28 : Tue Jan 28 2003 - 16:26:32 PST