Re: [sv-bc] name resolution (some rules for consideration)

> Note that all unpacked arrays already permit a dot select

Yes, any expression (such as a function call or the result of an
overloaded operator) permits a dot select for the array manipulation
methods of 5.15 in IEEE Std 1800-2005, if the expression evaluates to an
unpacked array.

But, according to 5.15.2, even expressions that evaluate to *packed*
arrays permit a dot select, because the 'reverse' method could be
applied to them.  (Perhaps the 'shuffle' method could be applied to
them, too.)

-- Brad

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Mark
Hartoog
Sent: Monday, June 04, 2007 9:01 AM
To: Gordon Vreugdenhil; Mark Hartoog
Cc: SV_BC List
Subject: RE: [sv-bc] name resolution (some rules for consideration)

> >> 5) in a dotted name, if the first/next name binds to a declaration 
> >> that MAY
> >>     permit a dot select , no backtracking occurs.
> > 
> > This seems very unclear to me. When is this rule applied? When the 
> > dotted name is first parsed? Or at elaboration? At elaboration time 
> > you should know what the value of the type parameters are, so I'm 
> > guessing you are proposing to do this at parse time, which
> I think is
> > an unworkable idea.
> 
> Please explain -- why is the "unworkable"?  The "may" 
> contexts are pretty easy to define and there are no legacy issues in 
> such cases.

This is a slight modification of your legacy example:

       module top;
         integer x;
         child c();
       endmodule
       module child;
         integer top[5];
         initial top.x = 5;  // resolves to $root.top.x
       endmodule 

In System Verilog all unpacked arrays "permit a dot select."
You can write top.min for example. 

I would be ok with a rule that says that if first name in a dotted name
binds to a declaration at parse time that permits (or might permit)

a dot select, then it cannot bind to different variable, but it still
could bind to an instance or scope name. Note that all unpacked arrays
already permit a dot select and it is a distinct possibility that in the
future, variables and nets may permit a dot selects too. 

Example:

module top #(P = 0, Q =0);

struct { int x; } s;

generate
if (P == 0) begin : blk
   initial $display( s.x ); // could bind either way 
   if (Q == 0) begin : s
       int x;
   end : s
end : blk
if (P == 1) begin : blk
   initial $display( s.x ); // binds to module level variable
                            // or could be made illegal  
   struct { int x; } s;
end : blk
endgenerate
endmodule

This is in the sprit that identifiers only bind to visible variables at
parse time, but hierarchical names bind to scopes/instances that are not
yet visible at parse time.


> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com]
> Sent: Monday, June 04, 2007 6:45 AM
> To: Mark Hartoog
> Cc: SV_BC List
> Subject: Re: [sv-bc] name resolution (some rules for consideration)
> 
> 
> 
> Mark Hartoog wrote:
> > I have a few comments on this.
> > 
> >> 1. When a scope is finished its compilation, it is closed
> - no more
> >> symbol
> >>     introduction.  The only exception is that an elaboration time 
> >> "bind"
> >>     can introduce additional instance names and implicit net names 
> >> into
> >>     the target scope.
> > 
> > Clearly generate can also introduce new names into a scope also. 
> 
> Not really.  That was determined by the 2005 rules.  The name of a 
> generate block (even its implicit external name) is a name at the time

> of analysis *independent* of whether the block is elaborated.  So the 
> definition of the scope is still closed, the only thing that you don't

> know is whether a candidate name will actually exist (but you know all

> the candidates and whether the candidate denotes a scope).
> 
> 
> >> 2. within a method, an identifier reference is resolved by doing 
> >> searches
> >>     in the following order:
> >>        1. bind into the local scope (upwards to the method
> >> declaration)
> >>        1. bind into the local class
> >>        2. bind to any inherited names
> >>        3. bind following normal lexical/import/hierarchy 
> rules in the 
> >> parent
> >>           scope of the local class decl
> > 
> > The question is when can you do this. If the base class can be a 
> > forward typedef or a type parameter, you cannot do this until 
> > elaboration.
> 
> Right.  There are a couple of potential directions for 
> resolving this, but as I noted in my preamble, I know that 
> this is not a complete set of rules, but we have to start somewhere.
> 
> Unless you'd like to take a shot at writing up what you 
> believe are complete rules....
> 
> 
> >> 5) in a dotted name, if the first/next name binds to a declaration 
> >> that MAY
> >>     permit a dot select , no backtracking occurs.
> > 
> > This seems very unclear to me. When is this rule applied? When the 
> > dotted name is first parsed? Or at elaboration? At elaboration time 
> > you should know what the value of the type parameters are, so I'm 
> > guessing you are proposing to do this at parse time, which 
> I think is 
> > an unworkable idea.
> 
> Please explain -- why is the "unworkable"?  The "may" 
> contexts are pretty easy to define and there are no legacy 
> issues in such cases.
> 
> 
> > 
> >> 6) In a hierarchical name, once a "bit select" is matched 
> to a scope 
> >> that permits
> >>     a bit select, no backtracking
> >>
> >>     This means that once you've matched, for example, an arrayed 
> >> generate name
> >>     or an arrayed instance, you never backtrack upwards.
> > 
> > Why? Why do you allow any backtracking and forbid this backtracking?
> 
> 
> Steven and I are philosophically agreed that backtracking is 
> a bad idea.  We want to limit the context of backtracking to 
> only those cases that are necessary to preserve legacy behavior.
> 
> In addition, user's would almost certainly find that if an 
> arrayed instance had bounds [1:10] and they referenced index 
> 11, that an error would be expected, not a search up through 
> the context tree.
> 
> 
> >> 7) all class members are visible to the body of extern methods
> > 
> > This statement sounds fine, but the example after implies much more 
> > than this rule, and I disagree with the second example.
> 
> 
> Yes, that has come up in discussions already.  There is 
> disagreement on that and I've specifically asked for 
> suggestions about how to resolve the disagreement.  I've 
> received NO responses to that.
> In lieu of any feedback, I guess we'll just have to disagree.
> 
> Gord.
> --
> --------------------------------------------------------------------
> 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.



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