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

The reasons for the rule is written this way is because in the
most general case where the variable type is a type parameter
you will not know until elaboration time whether a named select
is legal for the variable. 

In cases were you do know at parse time that a named select is 
legal, like the one you gave, it is of course legal to give an
error message at parse time. In fact if the second import that 
makes it illegal were removed, so it was legal, it would be legal
to import the wild card import at parse time. You only need to
delay the resolution when type parameters or forward typedefs 
are involved.  

> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
> Sent: Friday, August 17, 2007 3:07 PM
> To: Mark Hartoog
> Cc: SV_BC List; sv-ec@eda.org
> Subject: Re: [sv-ec] Proposed rules for name binding
> 
> So this isn't an error until elaboration time?  An 
> implementation must permit this to compile?
> 
> Gord.
> 
> Mark Hartoog wrote:
> > 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
> >>
> >>
> 
> --
> --------------------------------------------------------------------
> 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.