Subject: RE: [sv-bc] RE: [sv-ec] LRM-193 through LRM-195
From: David W. Smith (david.smith@synopsys.com)
Date: Fri Feb 06 2004 - 12:07:07 PST
Hi Francoise,
At the end of last weeks meeting I indicated that I would spend some time considering both the issue of hierarchical reference and
the statement that an explicit import acts just like a local declaration. In looking back over the discussions we had in the working
group and discussing it, further with some of the Synopsys people, I have come to the same conclusion you have that both of these
statements are misleading and confusing.
The ways to reference an identifier that is declared in a package are to use an explicit reference (p::a), an explicit import
(import p::a), or a wildcard import with local usage (import p::*). Trying to use a hierarchical reference has all kinds of problems
associated with it (it confuses where the identifier storage actually lives, is inconsistent with how other identifiers used within
a scope but defined outside of the scope are referenced, etc...).
The statement about having an explicit import working just like a local declaration is also clearly incorrect. The intent here, as I
remember, was to try to indicate that a variable from an explicit import is treated the same as a local declaration for the purposes
of resolving an identifier's declaration and for conflict if the identifier is locally declared. This statement is not required
since the rest of the paragraph defines this.
So, my proposal, which is attached, is to delete both sentences. I do not believe this changes the intent or agreement we had on how
the import statement works and just removes confusing statements.
If there is no dissent then I will include it in the Draft 5 changes.
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: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Francoise Martinolle
Sent: Monday, February 02, 2004 9:25 AM
To: Warmke, Doug; 'Steven Sharp'; David.Smith@Synopsys.COM; sv-bc@eda.org; sv-ec@eda.org
Subject: Re: [sv-bc] RE: [sv-ec] LRM-193 through LRM-195
I think the base of the problems we have is the fact that we state that an
imported declaration is equivalent to a local declaration. That should be
removed from the LRM.
The result of an import clause should only be to allow direct visibility of
the imported declaration. That means that you can use simple reference to
items declared in the package. It should not mean that the imported items
become local declarations of the importing module.
If we change this then we don't have the problems Steve and I mentioned in
earlier emails with regards to the effect of a import clause and also name
resolution rules become cleaner and not dependent on wether or nor a
declaration was really imported.
Francoise
'
At 05:34 PM 1/30/2004 -0800, Warmke, Doug wrote:
>Steven,
>
>Here is the original example 3) from Francoise's email:
>
>package p
>function f (input i);
>begin
> $display("package p");
> f =1;
>end
>endfunction
>endpackage
>
>
>module top
>function f(input i)
>begin
> $display ("top.f");
> f = 0;
>end
>endfunction
>
> mid m1 ();
>endmodule
>
>import p::*;
>module mid;
> bot b1();
>endmodule
>
>module bot
>reg r;
>initial
> r = f(); // which f is referenced?
>endmodule
>
>
>Note that module mid doesn't "import p::*;".
>That declaration is associated with the current compilation unit,
>not module mid. If module mid referred to any items within package
>p, then those particular items would be imported into module mid's
>scope (not the compilation unit's scope). As the code stands in
>the example, module mid imports nothing from package p.
>module bot, however, does import function f from package p,
>based on the name resolution rules in section 18.3.
>
>My proposal to David is to clarify those rules as follows.
>
>CURRENT:
>When an identifier is referenced within a scope, SystemVerilog follows the
>Verilog name search rules:
>- First, the nested scope is searched (1364-2001 12.6) (including nested
>module declarations)
>- Next, the compilation-unit scope is searched
>- Finally, the instance hierarchy is searched (1364-2001 12.5))
>
>PROPOSED:
>When an identifier is referenced within a scope, SystemVerilog follows the
>Verilog name search rules:
>- First, the nested scope is searched (1364-2001 12.6) (including nested
>module declarations)
>- Next, the compilation-unit scope is searched, including any symbols made
>available through
> package import declarations.
>- Finally, the instance hierarchy is searched (1364-2001 12.5))
>
>David - Will you agree to this clarifying text?
>You didn't respond to the suggestion in my earlier mail.
>
>Steven - please see below for a couple more embedded comments...
>
> > -----Original Message-----
> > From: Steven Sharp [mailto:sharp@cadence.com]
> >
> > >If module bot is in a separate compilation unit, and no import p::*
> > >was in effect inside that compilation unit, then f() would resolve
> > >to top.f(). No chance to even detect the f() in package p.
> >
> > But module mid did import p::*, and thus f() could have been imported
> > into module mid. If f() is imported into module mid, would it not
> > appear in the symbol table of module mid and be available for
> > resolution
>DOUG: But f() is not imported into module mid, as explained above.
>
> > by the upward search? If so, then Arturo is wrong about the
> > "heisenberg"
> > property of pulling in the declaration. You could tell whether it had
> > been done or not, even without any references. So it has to
> > be defined.
> >
> > BTW, I am having a problem with this whole module vs. compilation unit
> > thing. You have implied that if any module in a compilation unit has
> > a reference to a package object, then it is pulled into the
> > compilation
> > unit. But surely it is pulled into a module, not a compilation unit.
>DOUG: I had the same confusion. But that is not the case.
>Symbols are never pulled into compilation unit (or any other scope)
>simply by merit of an import statement. They are only ever pulled into
>a scope if they are actually made use of in that scope.
>
> > Why should pulling it into one module affect whether it gets pulled
> > into another module in the same compilation unit? Suppose I compile a
> > module that has no references to the package object, so I
> > don't add the
> > name to that module's symbol table. Then later in the same
> > file, there
> > is another module that does reference the package object. Are you
> > suggesting that I have to go back to the earlier module (which I am
> > already done compiling) and add the package object to its
> > symbol table,
> > just because some other unrelated module referenced it? If so, why?
>DOUG: Definitely not the case (thank goodness).
>So the main issue is moot.
>
>Regarding your earlier mail about a user deleting a use-site of an imported
>symbol from a scope, and thus affecting upwards name resolution:
>What you wrote is true. However, it is also true with normal symbols
>that get deleted from upward scopes. The search results are different
>when such a deletion occurs, and may resolve to other homographs of
>that symbol further up the hierarchy. (Or be totally unresolved and
>thus an error).
>
>Regards,
>Doug
>
>
> >
> > Steven Sharp
> > sharp@cadence.com
> >
This archive was generated by hypermail 2b28 : Fri Feb 06 2004 - 12:14:06 PST