[sv-bc] Re: [sv-ec] Proposed rules for name binding

Mark, how do you apply rule 7 in the following case:

   package p1;
     struct { int a } b;
   endpackage

   package p2;
     struct { int a } b;
   endpackage

   module top;
     import p1::*;
     initial b.a = 1;
     import p2::b;
   endmodule

By rule 7, you do NOT import "b" on the first reference.
But the second import explicitly imports b.  I don't
see a rule that says that this is illegal (which it
should be).

What if in p2 the name "b" is a static task (a scope) with
"a" being a named decl inside the task?  Does that impact
your answer?

What about if "b" is subsequently declared in "top"?

In my view, the b.a reference DOES import "b" immediately
and no further declaration or import of "b" is legal.  This
should purely be a compile time decision and should not
be delayed until design elaboration.

Gord.


Mark Hartoog wrote:
> Here is a first pass at a set of rules similar to the rules that Gord
> sent out. Some of these rules are essentially the same as the ones Gord
> proposed. Some are very different. I adopted most of Gord's
> anti-backtracking rules, except for the one about bit selects for
> instance arrays or names from unrolled generate blocks. I did not
> understand how that rule would be backwardly compatible with 1364. 
> 
> Notes on terminology: 
> 
> I am using the term Delayed Resolution Scope (DRS) for a scope where all
> simple identifiers cannot be resolved at parse time. These scopes
> include class methods and randomize with blocks. 
> 
> I am using the term Dotted Name for any name separated by dots. I use
> the term Named Select for dotted names that resolve to variables or nets
> that are structs, classes, interfaces or virtual interfaces. I use the
> term Hierarchical Name for a dotted name that resolves on the instance
> hierarchy. Of course part of a dotted name may be a hierarchical name
> and part may be a named select.
> 
> 1)  If a class and package of the same name are visible, then the scope
> resolution operator (<name>::) will resolve to the class name, except in
> an import statement, where it always resolves to the package.
> 
> 2) There is no backtracking in name resolution after a scope resolution
> operator.
> 
> 3) In hierarchical name resolution, if the next name resolves to a
> variable or net that permits a named select (struct, class, interface,
> virtual interface) then no backtracking will occur. This applies to the
> first name as well, but the first name has special rules discussed
> below.
> 
> 4)  All classes are delayed resolution scopes (DRS). Within a class
> method, scopes are searched for name resolution in the order below.
> Scopes marked DRS must be treated differently, which is described later:
>          1) The local class method scope (upwards to the method
> declaration)
>          2) The local class - DRS 
>          3) All base classes - DRS
>          4) Normal outer scopes - DRS. For an extern class method the
> outer scopes are the scopes of the actual method declaration, not the
> outer scopes of the class declaration.
> 
> 5) Simple identifiers in non-DRS
> 
> In a non-DRS scope, most simple identifiers must be declared before they
> are used. (An implicit net is an example of why it is only 'most' simple
> identifiers). These identifiers can be immediately resolved following
> normal System Verilog scope search rules including $unit. In a non-DRS
> it is an error if an identifier cannot be resolved (except for special
> cases like implicit nets).
> 
> 6) Simple identifiers in DRS
> 
> In a DRS simple identifiers that resolve in the local scope can be
> immediately resolved. For simple identifiers that can not be resolved in
> the local scope, we look for a candidate resolution in the outer scopes.
> The candidate may be in any outer scope, $unit or a package that is
> imported in some outer scope. There does not need to be a candidate. If
> the candidate is a wild card package import that has not yet been made,
> it is simply recorded as the candidate without importing the symbol.
> 
> At some later point, all delayed identifiers are resolved. They may new
> resolve locally in the DRS. If they do not resolve locally in the DRS,
> the only outer scope resolution allowed is the candidate identified at
> parse time. If there is no parse time candidate, it is an error. If the
> candidate was a wild card package import and it has not been imported,
> it must now be imported. If it can no longer be imported because of a
> conflicting symbol declaration or import in the outer scope, it is an
> error.
> 
> 7) Dotted names in non-DRS
> 
> At parse time in a non-DRS the first name of a dotted name is searched
> following the normal System Verilog scope search rules including $unit.
> If this resolves to a variable or net, this is recorded as the
> variable/net candidate. If the candidate is a wild card package import,
> it is recorded as the candidate, but it is not imported.
> 
> When the dotted name is resolved after elaboration, if there is a
> variable/net candidate for the first name, this is the only variable/net
> that is considered for resolution of the name. If the variable/net
> candidate does not permit named selects, then the name must resolve to a
> hierarchical path (making this an error would break backwards
> compatibility). If the variable/net candidate does permit named selects
> (struct, class, interface, virtual interface) then this variable is the
> only resolution that is considered (the name cannot resolve to a
> hierarchical path).  If the first name has no variable/net candidate,
> then the name must resolve to a hierarchical path.
> 
> 8) Dotted names in DRS
> 
> Dotted names in a DRS are handled in a similar manner, with one
> difference. If there is a candidate found for the first name outside of
> the DRS or if there is no candidate, then when dotted names are resolved
> after elaboration, there is another search of the local DRS for a local
> candidate. After this, the dotted name is handled the same as in a
> non-DRS. 
> 
> 9) Identifiers and Dotted Names in Bind Statements.
> 
> Identifiers and dotted names in bind statements are resolved during
> elaboration. Because the bind statement was not present in the target
> scope at parsing time, there cannot be a parse time candidate for a
> simple identifier or the first name of a dotted identifier. The bind
> statement is treated as if it appeared at the end of the target scope.
> Simple identifiers are resolved in the target scope and all enclosing
> scopes including $unit. (Note this means it could resolve to a name
> declared after the module in $unit.) If the name matches a wild card
> import, this import is made. 
> 
> For dotted names in bind statements, there can be no parse time
> candidate. At elaboration time a variable/net candidate is searched for
> following normal scope search rules, including $unit. Then the dotted
> name is processed like a dotted name in a non-DRS scope.
> 
> 10) Task, Function, Sequence and Property Names in non-DRS
> 
> In a non-DRS only the local module or generate block is searched for
> task, function, sequence and property names at parse time. If the name
> resolves to a wild card package import, that package import is made. The
> search does not include $unit. (This is mainly to improve backwards
> compatibility). If the name does not resolve, it is left to be resolved
> hierarchically at elaboration time.
> 
> 11) Task, Function, Sequence and Property Names in DRS
> 
> In a DRS the local DRS is searched at parse time for a resolution. If no
> local resolution is found, then the outer scopes are searched for a
> candidate resolution. If the candidate resolution is a wild card import,
> this is recorded as the candidate, but the wild card import is not made.
> 
> At elaboration time, unresolved task, function, sequence and property
> names are searched in the local DRS. If they are still unresolved and
> there is an outer scope candidate, that outer scope candidate is the
> resolution. If the outer scope candidate is a wild card import that now
> collides with a name declared in the import scope, it is an error. If
> the wild card import is not defined, then it is imported. If there is no
> outer scope candidate, then outer scopes up to $unit are searched for a
> resolution. If it is still not resolved, then you search for a
> hierarchical resolution. 
> 
> Note that I don't believe the current LRM allows sequence or property
> names in DRS.
> 
> 
> 
> 

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.