RE: [sv-bc] Copy of Packages_Sep_V8.pdf


Subject: RE: [sv-bc] Copy of Packages_Sep_V8.pdf
From: David W. Smith (david.smith@synopsys.com)
Date: Tue Nov 04 2003 - 10:57:19 PST


Hi Adam,
Please see the comments below. Good questions and I hope some of the
responses help.

Regards
David

-----Original Message-----
From: Adam Krolnik [mailto:krolnik@lsil.com]
Sent: Tuesday, November 04, 2003 9:28 AM
To: David W. Smith
Cc: sv-bc@eda.org; sv-ec@eda.org
Subject: Re: [sv-bc] Copy of Packages_Sep_V8.pdf

Hello;

Questions about the packages proposal...

o Could the difference between $root and $unit be elaborated? It is not
   clear how having one of the two ($root or $unit) creates an ambiguity.
   Also, Section 18.10 speaks about $root

DWS: $root is used purely for the purpose of accessing the top of the
instance tree. As you point out 18.10 is the only place in the LRM that now
uses $root. It was felt that providing the ability to unambiguously access
the top of the instance tree is a useful concept. $unit is used to access
either a package (no upward search and in a completely different name space
from everything else) or the implicit package within the unit of
compilation. There are no instances only declarations within packages so
using $root would not be appropriate.

o Why does $unit require '::' as a separator, while $root (and other
hierarchical
   references) use '.' ?

DWS: Since the $unit is accessing the same items as are in a package using
the package separator makes a lot more sense than using a hierarchical
reference. This is is a reference to a package and, as I indicated in the
previous comment, does not follow the Verilog upward search rules so is not
a hierarchical reference.

o Have you considered the ability to rename a conflicting symbol so that a
package
   can be used? This provides the capability to fix conflicts instead of
having
   to build a complete wrapper around one or more packages. See Eiffel as an
   example of renaming symbols that are in conflict.

DWS: I believe the committee did consider this and it could be added at some
future date.

o I see that both parameters and local parameters can be part of a package.
Can
   any parameters be overridden by defparams? Is there a need for both?
DWS: The discussion was that parameters in certain contexts could be
considered local parameter which cannot be overridden. I believe this is
being worked on in one of the committees.

o Why is an anonymous program introduced for packages?
DWS: This was decided before I got involved and I will let someone else
respond.

o In defining a unit of compilation as a collection of files, should there
not be some
   tie in to configurations as defined by 1364-2001? One should at least say
   that a library is a unit of compilation.
DWS: There was much discussion about this. Clearly that could be a way of
defining compilation units. We felt that not tieing it explicitely to
libraries would be less restrictive at this point.

    THanks.

    Adam Krolnik
    Verification Mgr.
    LSI Logic Corp.
    Plano TX. 75074
    Co-author "Assertion Based Design"



This archive was generated by hypermail 2b28 : Tue Nov 04 2003 - 11:02:23 PST