Subject: [sv-cc] RE: a few comments/issues import, packages.
From: Francoise Martinolle (fm@cadence.com)
Date: Tue Jan 20 2004 - 08:52:19 PST
Regarding my issue of iterating over the compilation units. VPI does not
have an iteration to traverse the compilation units. Either we add it in
VPI or the sentence in 18.3 needs to be removed. Someone needs to explain
why this sentence was put in.
Yes it is true that a VPI application can infer the actual dependent units
by iterating over the imported items.
The dependent units are different from the compilation units.
A compilation unit is a set of source files which are compiled together.
VPI does not provide access to this.
At 11:10 AM 1/20/2004 -0500, Joao Geada wrote:
>Francoise:
>
>I agree with the first point and will update this in the next rev.
>
>As for the second issue: a dependency between a module and a package
>(whether the implicit compilation unit package
>or an explicit package) exists *ONLY* if the module uses (ie imports,
>explicitly or implicitly) a symbol from that package.
>Therefore, iterating over all imports automatically gives you the
>dependency you are looking for.
>Unless I misunderstood your requirements, I believe that the iterator you
>were looking for is, thus, already present in the
>spec.
>
>Joao
>==============================================================================
>Joao Geada, PhD Principal Engineer Verif Tech Group
>Synopsys, Inc TEL: (508) 263-8083
>377 Simarano Drive, Suite 300, FAX: (508) 263-8069
>Marlboro, MA 01752, USA
>==============================================================================
>
>-----Original Message-----
>From: Francoise Martinolle [mailto:fm@cadence.com]
>Sent: Tuesday, January 20, 2004 11:00 AM
>To: Joao.Geada@synopsys.COM; Sv-Cc
>Cc: Tapati Basu; Avinash G Mani; Charles Dawson
>Subject: a few comments/issues import, packages.
>
>Issues/questions:
>
>30.1 Instance diagram
>vpiUnit: bool
>The note uses the term compilation unit in an inappropriate manner.
>A $unit package is a compilation unit scope which contains all the global
>declarations.
>
>a package is not a compilation unit.
>
>In section 18.3 in the SV 3.1a LRM:
>I found the following definitions:
>18.3 Compilation unit support
>SystemVerilog supports separate compilation using compiled units. The
>following terms and definitions are
>provided:
>— compilation unit: a collection of one or more SystemVerilog source files
>compiled together
>— compilation-unit scope: a scope that is local to the compilation unit.
>It contains all declarations that lie outside
>of any other scope
>— $unit: the name used to explicitly access the identifiers in the
>compilation-unit scope
>
>
>
>I suggest to change note 4:
>4. Compilation units are represented as packages that have a vpiUnit
>property set to TRUE. Such implicitly declared packages shall have
>implementation dependent names.
> to say:
>4. Compilation unit scopes are packages that have a vpiUnit property set
>to TRUE. Such implicitly declared packages shall have implementation
>dependent names.
>
>Secondly in section 18.3, there is a sentence that PLI should provide
>iteration over the compilation units.
>Access to the items in a compilation-unit scope can be accessed using the
>PLI, which must
>provide an iterator to traverse all the compilation units.
>However in the VPI proposal we have no way to access all the compilation
>units.
>Would'nt we want to know where a compilation unit started and ended
>(source files)?
>The current proposal allows to iterate over packages and find all the
>implicit packages, but from a module you cannot find out the compilation
>units it depends upon.
>There is an import iteration which returns the items which are made
>directly visible inside a module but that is not sufficient. We should
>have an additional iteration to return the dependent units.
>
This archive was generated by hypermail 2b28 : Tue Jan 20 2004 - 08:56:25 PST