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

As I said, this is just a first draft.

This text that is in rule 6:

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.

should have also been in rule 7. 

> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
> Sent: Friday, August 17, 2007 2:35 PM
> To: Mark Hartoog
> Cc: SV_BC List
> Subject: 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.