Subject: [sv-bc] RE: [sv-ec] LRM-193 through LRM-195
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Thu Jan 29 2004 - 16:14:38 PST
David,
Let me see if I can apply the newly clarified LRM-194 to Francoise's
examples.
If I am wrong about some of these, perhaps a little further
clarification may be needed.
(Also: The modified sentence in Section 18.2.1 seems to be a run-on
sentence. Please
see my suggestion at the end of this mail for how to fix it.)
1) If we can refer to the imported items by hierarchical names relative
to the importing module (I don't know if you can, clarification is
expected in SV LRM, I think that the pakcages imported items can only
have hierarchical package scoped names)
Then suppose one of the sub-instances of the importing module has a
hierarchical name reference to a declared item in package p,
if the effect of the wildcard import is that only referenced items are
imported, then the hierarchical reference top.c is undefined; if the
effect of the wildcard import is that all items are imported regardless
of their use, then top.c is defined.
ex:
package p
reg c = 0;
endpackage
import p::*;
module top
bot u1();
endmodule
module bot;
reg r = top.c; // where c is being imported through package p and is now
a declaration inside module top
endmodule
DOUG THINKS:
Example 1) is illegal, since c is not used or declared in the importing
scope, "top".
2) a $dumpvars is supposed to dump all the variables in the module, I
assume that this would also apply to imported items.
import p::*
module top
initial
$dumpvars(top);
endmodule
DOUG THINKS:
Example 2) is legal. The $dumpvars will show nothing, however.
There are no items declared in module top, and there are no items
in package p that are used in the scope.
3) there is a non standard VXL rule for function look up which NC
supports; the behaviour of the wildcard import would have some
implication on the resolution of the function declaration.
VXL allows to have simple reference to function in lower instances when
the function is declared in a higher level module containing this
instance.
Depending on the behaviour of import p::*, you would either get p::f
function or top.f function
in the following example.
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
DOUG THINKS:
This is a good question. I think further clarification is in order
here.
In the absence of top.f(), f() would be imported from package p,
since it is used in scope bot, and the import p::*; statement is
in effect for the rest of the compilation unit (including module bot).
In the absence of the import p::*; statement, function f() would be
found by upwards name resolution rules. (This doesn't seem to
be a particularity of NC or VXL; it's standard upwards name resolution
as far as I can tell).
My thought is that top.f() takes the day, since the LRM says that any
locally declared identifier will be preferred over a candidate imported
identifier. top.f() is in the spirit of this rule, but not the letter,
since it
is not locally declared in module bot.
If this thought is correct, I would suggest rewording the LRM something
like the following:
Section 18.2.1:
A wildcard import makes each identifier within the package a candidate
for import. Each such identifier is imported only when it is referenced
in the importing scope. However, if the identifier is declared in the
scope, explicitly imported into the scope, or visible in an outer scope
through name resolution rules, it is not imported into the scope. it is
neither declared nor explicitly imported into the scope. Similarly, a
wildcard import of an identifier is overridden by a subsequent
declaration of the same identifier in the same scope. If the same
identifier is wildcard imported into a scope from two different
packages, the identifier shall be undefined within that scope and result
in an error if the identifier is used.
Regards,
Doug
-----Original Message-----
From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On
Behalf Of David W. Smith
Sent: Thursday, January 29, 2004 3:09 PM
To: sv-bc@server.eda.org; sv-ec@server.eda.org
Subject: [sv-ec] LRM-193 through LRM-195
Greetings,
I have added LRM-193 through LRM-195 to be added in Draft 4 (which Stu
is currently working on). These are relatively small changes that I
wanted to bring to your attention.
1. Section 5.5 still referred to "process" statement that existed
in 3.0. This is removed in LRM-193.
2. Section 18.2.1 had some confusion about when names from a
package exist in the name space they are imported in to. This is
clarified in LRM-194 according to the original discussions we had in the
packages working group.
3. Section 12.8, Table 12-2 had the two option descriptions
reversed (implying that on was off and off was on). This is fixed in
LRM-195.
If anyone has any problem with these fixes, please let me know as soon
as possible. They appeared to be simple fixes.
Regards
David
This archive was generated by hypermail 2b28 : Thu Jan 29 2004 - 16:27:35 PST