Subject: Re: [sv-cc] sv-cc 2 sv-ec: extern/export requirements
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Tue Jan 28 2003 - 08:41:59 PST
> Joao,
>
> below you have stated that "'pure' function must not have inout or output arguments.".
> This has not been stated until now (or my simple mind has overlooked this). I would
> like to know and understand the rationale behind this limitation.
Yes, this restriction has been added recently; it simply skipped our attention
earlier. Perhaps another wording could be used:
"Only non-void a function with no output or inout arguments may be specified
as 'pure'."
Let me put it simply: it would be pointless to specify a function as 'pure'
without that restriction.
An ability to have output or inout ports will defy the rationale for the qualifier
'pure'.
The sole rationale for the qualifier 'pure' was to let compiler know that a call
of 'pure' function may be safely eliminated if its result is not needed or
the previous result for the same values of input arguments is available somehow
and may be re-used without need to re-calculate.
Note, however, that the presence of output (or inout) arguments would mean
that they would have to be re-assigned, even though the assigned values
are assumed to be the same. The actual arguments could have changed in the
meantime. Therefore the compiler cannot eliminate otherwise redundant a call.
> Also, if I remind properly the proposed extern syntax permits to rename the SV function/task
> to another name on the C side of the interface. I did miss this in your requirements ...
>
> -Michael
There is an apparent need to specify C alias for an exported SV function; not all
SV names are legal C names (escaped names, for example), and the same SV function,
though for different instances, may be exported several times, thus requiring different
global C names.
It seems to be no such obvious need for SV alias for an external C function, specified
in the external declaration. Just a taste for symmetry?
Andrzej
>
> Joao Geada wrote:
>
> > 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
> > ==============================================================================
>
> --
>
> NOTE: The content of this message may contain personal views
> which are not neccessarily the views of Motorola, unless specifically stated.
>
> ___________________________________________________
> | |
> _ | Michael Rohleder Tel: +49-89-92103-259 | _
> / )| Software Technologist Fax: +49-89-92103-680 |( \
> / / | Motorola, Semiconductor Products, System Design | \ \
> _( (_ | _ Schatzbogen 7, D-81829 Munich, Germany _ | _) )_
> (((\ \>|_/ > < \_|</ /)))
> (\\\\ \_/ / mailto:Michael.Rohleder@motorola.com \ \_/ ////)
> \ /_______________________________________________\ /
> \ _/ \_ /
> / / \ \
>
> The information contained in this email has been classified as:
> Motorola General Business Information (x)
> Motorola Internal Use Only ( )
> Motorola Confidential Proprietary ( )
>
>
> *** This note may contain Motorola Confidential Proprietary or
> Motorola Internal Use Only Information and is intended to be
> reviewed by only the individual or organization named above.
> If you are not the intended recipient or an authorized representative
> of the intended recipient, you are hereby notified that any review,
> dissemination or copying of this email and its attachments, if any,
> or the information contained herein is prohibited. If you have received
> this email in error, please immediately notify the sender by
> return email and delete this email from your system.
> Thank you! ***
>
>
> --------------77F8ED182FAB97346FBBC8FA
> Content-Type: text/x-vcard; charset=us-ascii;
> name="michael.rohleder.vcf"
> Content-Transfer-Encoding: 7bit
> Content-Description: Card for Michael Rohleder
> Content-Disposition: attachment;
> filename="michael.rohleder.vcf"
>
> begin:vcard
> n:Rohleder;Michael
> tel;fax:++49-89-92103-680
> tel;work:++49-89-92103-259
> x-mozilla-html:FALSE
> org:Motorola Semiconductor Products Sector;System Design Methodology
> version:2.1
> email;internet:Michael.Rohleder@motorola.com
> title:Software Technologist
> adr;quoted-printable:;;Motorola=0D=0ASemiconductor Products Sector=0D=0ASchatzbogen 7=0D=0AD-81829 Muenchen=0D=0A =0D=0A;Munich;;D-81829;Germany
> note;quoted-printable:<FONT size=3D1 color=3D#FF0000>=0D=0A***This note may contain Motorola Confidential Proprietary or Motorola Internal Use Only=0D=0AInformation and is intended to be reviewed by only the individual or organization named above. If=0D=0Ayou are not the intended recipient or an authorized representative of=0D=0Athe intended recipient, you are hereby notified that any review, dissemination or copying of this=0D=0Aemail and its attachments, if any, or the information contained herein is prohibited. If you have=0D=0Areceived this email in error, please immediately notify the=0D=0Asender by return email and delete this email from your system. Thank you!***=0D=0A</FONT>=0D=0A=0D=0A
> fn:Michael Rohleder
> end:vcard
>
> --------------77F8ED182FAB97346FBBC8FA--
>
>
>
This archive was generated by hypermail 2b28 : Tue Jan 28 2003 - 08:42:31 PST