Subject: [sv-bc] RE: [sv-ec] LRM-193 through LRM-195
From: David W. Smith (dwsmith@synopsys.com)
Date: Thu Jan 29 2004 - 17:02:02 PST
Doug,
I agree with your interpretation of 1 and 2. Let me see if the search rules in 18.3 apply to 3.
1. The nested scope is searched to see if the identifier f is declared. It is not.
2. The compilation-unit scope is searched to see if the identifier f is declared. The declaration for f from the package is
visible due to the import and, therefore, it will be found and will be used as the declaration for f.
3. If the compilation-unit scope did not include the package import then the search would continue through the instance
hieararchy and f would be found from top.
This all seems pretty clear from the description of packages and the search rules in 18.3. What is missing?
The use of an import makes the names declared within the package available for resolution of the declaration of an identifier. This
is what was discussed and what I think is described by the addition I suggested in the LRM change.
Your suggested change I think confuses the issue since it adds something new to the discussion "visible in an outer scope through
name resolution rules". I think the name resolution rules are an integral part of the determination of where a name is declared
from. Your description, I think, is inconsistent with how 18.3 was meant to be applied (at least in the existing document).
Seems like there was more to this discussion and change than first appeared.
Regards
David
-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Warmke, Doug
Sent: Thursday, January 29, 2004 4:15 PM
To: 'dwsmith@synopsys.com'; sv-bc@eda.org; sv-ec@eda.org
Subject: RE: [sv-ec] LRM-193 through LRM-195
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 - 17:20:24 PST