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.Received on Fri Aug 17 15:07:29 2007
This archive was generated by hypermail 2.1.8 : Fri Aug 17 2007 - 15:07:36 PDT