[sv-cc] RE: sv-cc 2 sv-ec: extern/export requirements


Subject: [sv-cc] RE: sv-cc 2 sv-ec: extern/export requirements
From: David W. Smith (david.smith@synopsys.com)
Date: Tue Jan 28 2003 - 15:39:25 PST


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.

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

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 - 15:39:06 PST