[sv-bc] Proposed rules for name binding

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.




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