Subject: [sv-bc] RE: [sv-ec] LRM-193 through LRM-195
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Thu Jan 29 2004 - 17:53:42 PST
David,
I think we are getting closer... please see below.
-----Original Message-----
From: David W. Smith [mailto:dwsmith@Synopsys.COM]
Sent: Thursday, January 29, 2004 5:02 PM
To: Warmke, Doug; 'dwsmith@synopsys.com'; sv-bc@eda.org; sv-ec@eda.org
Subject: RE: [sv-ec] LRM-193 through LRM-195
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.
DOUG: So my assumed answer on 3 was incorrect.
i.e. the imported symbol would be found before the symbol visible in the
outer instance hierarchy scope.
Given that I was wrong, of course my suggestion to modify the LRM is
confusing and should be dropped :)
This all seems pretty clear from the description of packages and the
search rules in 18.3. What is missing?
DOUG: I think the thing that is confusing me is a mix-up of
compilation-unit scope with importing scope.
When I say "importing scope", I mean the scope that references/uses the
imported identifier,
thus bringing it into real existence in that scope. In this example,
the compilation scope is
the scope in which the import declaration lives, not the imported
symbols themselves.
The symbols in the imported package are not used nor declared in the
compilation-unit scope,
thus in essence they don't exist in that scope if you only consider the
rules in 18.2.
That is the confusing part. With my new (hopefully enlightened)
understanding, I would propose
that we emend the 2nd rule in section 18.3 to state that when the
compilation unit is searched
for identifiers, we also mean identifiers made available through package
import declarations.
What say?
Thanks,
Doug
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 - 18:07:28 PST