Re: [sv-cc] Polls on extern/export and representation of SV data types

Subject: Re: [sv-cc] Polls on extern/export and representation of SV data types
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Sat Mar 08 2003 - 13:46:01 PST

Hi all,

first I would like to thank Francoise, Doug, John, Joao and Andrzej for the very good discussions on all these topics. It took me
some time to read it, but I enjoyed everything said; and basically agree to most of your statements. Good work! Thanks a lot.
Also thanks to Doug for explaining finally ILFC (InterLanguage Function Calls), this finally saved while reading the gnarly thread
[is there also a german/bavarian translation ... ;-)].

Best regards,
-Michael

Swapnajit Mittra wrote:

> Please send your comment (Y/N/A) on the following two items as
> we discussed in the last meeting:
>
> 1. Poll on acceptance of Joao's modified extern/export proposal.
> http://www.eda.org/sv-cc/hm/0920.html

Abstain.

I very much like the overall proposal and basically most points within, but would like to see some changes in the two following
areas:

 - I dislike that it is prohibited to have multiple extern declarations at $root level; this is a big inconvinience and I still
don't understand the reasoning why it is such a big problem to permit this.
 - I would strongly request that it is _also_ permitted to 'export' a function from the $root level by fully qualifying its path.
This is hindering reuse, because otherwise I would have to touch the Verilog code of someone else when I want to export only
function declared within this code. Not nice.
   The current way of exporting functions is O.K., but extending it to permit also this would also be important.

Also, IMHO it is still not completely clear on how the context is defined for _exported_ functions; a lot of very useful discussions
went into the aspect of external functions, but this is also important. I believe the rule of thumb here should be that calling an
exported function from an external function should behave exactly and (use the same context) as if the external function is an SV
function and calls the exported (SV) function.

My vote would be clearly yes, when solving all these issues (or explaining why it is such a problem)

P.S.
 - I am against permitting to export class member functions. Until we support classes, this is too dangerous.
 - I am very unsure about external function calls during elaboration; if we really want to have this I would rather go for an
additional attribute like 'pure' that explicitely requests this
 - I think we need two more service functions to retrieve the place where an external function is declared and called; this is
needed for error handling. I am unsure whether PLI can already provide all this information after some of these discussions.

> 2. Poll on agreement on SV-CC's opinion on the SV LRM language
> issue. Andrzej's comment on this is at:
> http://www.eda.org/sv-cc/hm/0908.html

Yes. with the exception of the part about 'representation of unpacked arrays of =packed= types'. For this part I abstain.

I still have concerns that this might break the object/source code compatibility, which I believe is an important aspect.
Unfortunately I am unsure I can deliver a better proposal ... at least not now!

> The deadline is Saturday 3/8.
>
> The eligible members for sending their comments are:
>
> Francoise Martinole
> Stuart Swan
> John Amouroux
> John Stickley
> Doug Warmke
> Michael Rohleder
> Kevin Cameron
> Bassam Tabbara
> Joao Gaeda
> Andrzej Litwiniuk
>
> --
> Swapnajit Mittra
> Project VeriPage ::: http://www.angelfire.com/ca/verilog
>
> ________________________________________________________________
> Sign Up for Juno Platinum Internet Access Today
> Only $9.95 per month!
> Visit www.juno.com 

--

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 : Sat Mar 08 2003 - 13:46:40 PST