Subject: Re: [sv-bc] RE: [sv-ec] LRM-193 through LRM-195
From: Francoise Martinolle (fm@cadence.com)
Date: Mon Feb 02 2004 - 09:24:56 PST
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 : Mon Feb 02 2004 - 09:37:39 PST