Re: [sv-cc] FW: [sv-bc] External Functions and Tasks proposal


Subject: Re: [sv-cc] FW: [sv-bc] External Functions and Tasks proposal
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Fri Mar 14 2003 - 11:21:07 PST


I can live with replacing any of the two keywords (extern,export) in our proposal with adequate other keywords, as long as we keep
our actual semantics and are in line with other semantics defined by SV. When there are conflicts and we have better keywords, then
we should use them. If there are no better ones, there is no reason to change. I am unsure we currently have better ones ...

On the other side, we have come up with a proposal. When we are constantly changing our proposal because there are changes in other
committees, we are in a real deadlock situation. It will become a moving target ... Why don't we just sync'up about this particular
issue and come up with a common proposal?

-Michael

"Warmke, Doug" wrote:

> Joao, others,Please see the forwarded proposal from Peter Flake that appeared on SV-BC.He is saying that the "external" keyword
> truly should have prototype semantics.This is not in matching with our requirements for external functions, which westated should
> be semantically equivalent to a true function declaration.(i.e. they stand in for a C function which would normally be declared in
> SVat that particular declarative scope)I think our usage of the term "extern" is too much in conflict with theprototype-oriented
> usage required by the other committees.As a result, I reluctantly think we should go back to usingthe keyword "import" instead of
> "extern" for describing external functions.And probably we should use the term "imported function" whenever wecurrently use the
> term "exported function".Given the deadline situation, please send comments soon(!)Thanks and regards,Doug
> -----Original Message-----
> From: Peter Flake [mailto:Peter.Flake@synopsys.com]
> Sent: Friday, March 14, 2003 7:27 AM
> To: sv-bc@server.eda.org
> Cc: Arturo Salz
> Subject: [sv-bc] External Functions and Tasks proposal
>
> ADD to draft 3 new section 10.6
>
> 5.8 External tasks and functions
>
> Some tools require each module to be analyzed separately. If the module uses tasks or functions declared in $root, the names and
> argument types need to be visible to the analysis to allow checking. However it is important that each analysis does not create
> its own copy of the task or function.
>
> SystemVerilog allows the existence elsewhere of a task or function name and prototype to be declared using the extern keyword.
> For example
> extern function int func1(int I);
>
> If this external declaration is in $root, the same name can be declared with the same prototype more than once.
>
> A declarations of a task or function prototype requires a matching declaration (with the same arguments) somewhere else ,
> otherwise there is an elaboration error. For example:
> function int func1(int I);
> return I;
> endfunction
>
> If the prototype is in the $root scope, the task or function must be declared in the $root scope.
>
> If the prototype is in an interface, the task or function must be declared in one of the modules connected to an instance of that
> interface.
>
> If the prototype is a class, the task or function must be declared as an out-of-body method (see section 11.20).
>
>

--

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! ***




This archive was generated by hypermail 2b28 : Fri Mar 14 2003 - 11:22:48 PST