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

Mark Hartoog wrote:
>>>> 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.  

Yes, that was what was brought up in the name resolution email
list and that I alluded to in my preamble.  There needs to
be some consideration for array manipulators but I think that
there are issues in that space in any case.  For example,
if you had "top.sum()" and there was a function "sum" in "top"
then you can't possibly preserve legacy behavior.

So we'll need to decide something about manipulators in any
case -- either give up pure legacy compliance in some edge
cases or require all potential manipulators to be biased
towards hierarchical resolution and only fall-back to the
manipulator resolution if no upwards resolution is found.
I think the latter would be a very bad idea; I'd prefer
to lose strict legacy compliance for the few cases at issue
with the manipulators.

> 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. 


That is essentially where I was going in the name resolution list --
if a name binds to something that could be a manipulator, that is
where it goes and otherwise you treat it hierarchically.  It is
the same as your interpretation for things that couldn't be a
manipulator and more constrained if the name could be a manipulator.
In the more constrained cases, I think that the tighter binding
will be more often what the user intended.


> 
> 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 

I disagree on this one.  My approach is that if there
is a visible "select" binding, it will always win.  An
implementation can/should warn but having to change
the interpretation of a binding back and forth between
select and hierarchical is, I think, a poor idea.  If
the user really intended this to be hierarchical, they
can say "blk.s.x".

>    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  

If you want to make this illegal, then we need to do that in
a completely consistent manner -- it is an error if a name
(bare identifier or hierarchical prefix) binds at parse time
to a visible identifier and the elaboration time binding
would conflict with that binding.

Such a restriction would deal with all sorts of deeply nested
constructs with nebulous bindings.  It would allow what I want --
early binding for selects -- and provide consistent invariants
for the users.

Another restatement of the rule would be that if a "select"
interpretation exists, a "hierarchical" interpretation cannot
bind to something different.

I think that I would be Ok with such a restriction.

Gord.

>    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.
-- 
--------------------------------------------------------------------
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.