Subject: RE: [sv-cc] RE: a few comments/issues import, packages.
From: David W. Smith (David.Smith@synopsys.com)
Date: Tue Jan 20 2004 - 09:50:57 PST
A compilation unit is a scope. The desire was to have an iterator that can
iterate through these scopes. The way the scope is created is related to a
set of source files.
Regards
David
-----Original Message-----
From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of
Francoise Martinolle
Sent: Tuesday, January 20, 2004 8:52 AM
To: Joao.Geada@Synopsys.COM; Joao.Geada@Synopsys.COM; Sv-Cc
Cc: Tapati Basu; Avinash G Mani; Charles Dawson
Subject: [sv-cc] RE: a few comments/issues import, packages.
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 - 09:58:22 PST