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:44:48 PST
> From david.smith@synopsys.com Tue Jan 28 16:28:41 2003
>
> You have me confused Kevin. AI-44 is "Propose swapping [] and [*] for array
> and associative array declarations" and unrelated to extern/export. EXT-20
> is the extern/export as I stated in the email.
You can specify arrays with '[]' in C prototypes and extrnal definitions, but
C doesn't directly support associative arrays, so I'd rather have the C usage
of [] in SV and keep the [*] syntax for the associative arrays which you wouldn't
pass directly to a C routine.
Kev.
> You need to take up changes to the requirements in the SV-CC. The
> requirements were passed to SV-EC from SV-CC and need to be modified in
> SV-CC.
>
> Regards
> David
>
> 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: Kevin Cameron x3251 [mailto:Kevin.Cameron@nsc.com]
> Sent: Tuesday, January 28, 2003 4:26 PM
> To: sv-ec@eda.org; david.smith@Synopsys.COM
> Cc: sv-cc@eda.org
> Subject: Re: [sv-cc] RE: sv-cc 2 sv-ec: extern/export requirements
>
>
> > 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:45:37 PST