Subject: [sv-bc] RE: [sv-ec] LRM-193 through LRM-195
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Fri Jan 30 2004 - 17:34:43 PST
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 Jan 30 2004 - 17:47:39 PST