Subject: [sv-ec] FW: LRM-193 through LRM-195 (from Jonathan Bradford)
From: David W. Smith (dwsmith@synopsys.com)
Date: Wed Feb 04 2004 - 16:18:14 PST
Hello
I think there needs to be definition of where items referred to in the package
actually takes place. I assume not in the package itself, as that implies a
common memory (i.e. static), shared by all that refer to that item in the package.
I assume the example below was a single file forming a compilation unit ?
Do then the declarations inferred by the reference f() (or p::f()) occur where
the statement import p::* appears lexically in the compilation unit (after top
before mid) or at the top of the compilation unit or in the module or block where
p::f() reference takes place. I think it is the first of these three (lexical position
of import).
Is it also possible to then place import statements deeper in the design, i.e.
after a module declaration or in a named begin end block. Then when a later package
reference occurs, the item is inferred to be declared where the package was imported.
I am also worried by the ability to reference package items without package import
statements. The spec implies that only import pack::item; or import pack::*; but
there is nothing for import pack; on its own.
This would then indicate where package item declarations take place and also help
dependency generation.
Clarification on the above would be useful for interpreting the spec., as it seems
to have been interpreted in a number of ways.
Jonathan Bradford
-----Original Message-----
From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]On
Behalf Of Warmke, Doug
Sent: Saturday, 31 January, 2004 2:35 AM
To: 'Steven Sharp'; dwsmith@synopsys.com; sv-bc@server.eda.org;
sv-ec@server.eda.org
Subject: RE: [sv-ec] LRM-193 through LRM-195
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 : Wed Feb 04 2004 - 16:25:47 PST