Re: [sv-bc] Named blocks conflicts with existing identifiers

Feldman, Yulik wrote:

> 
[...]
> [Yulik] No, I was referring to scope references. Simple identifiers
> representing references to variables obviously may not happen to be
> cross-hierarchical references, due to variable scope rules limiting
> their look-up to the local module. Still, it is not clear to me whether
> references to nets also have similar limitation to variables, since
> section 12.7 "Scope rules" doesn't refer to them explicitly. It would
> make sense that they do have similar restrictions, in which case the
> section language is not precise enough and should be fixed. If they
> don't have such restrictions (i.e. their look-up doesn't stop at module
> boundary), then the example you're asking for would be a reference to a
> net in parent module.

Nets should behave in the same manner as variables.  You are correct
in observing that 12.7 doesn't address nets.


> To conclude, since functions can be now detected in the parse stage, and
> given that you agree on my interpretation of references to nets, I see
> that one can distinguish between references that can be bound at parse
> stage and those that can't.
> 
> So, back to the original question, do you think it makes sense to have
> different look-up rules for the two categories of identifiers? I.e. when
> binding the simple identifiers at parse stage, to disregard the
> declarations that follow them in the scope (since they are not parsed
> yet), and while binding the hierarchical identifiers and scope
> references after the hierarchy is established, to consider those
> declarations (since they are now already parsed and are part of the
> scope)? Or, the rules should be the same for the both categories? If
> they should be the same, what the rules should be - should they consider
> the declarations-after-use or disregard them?

Unfortunately, due to legacy compatibility, I don't think that you
can make a single rule.  Scopes and variables/nets *do* resolve
differently in Verilog; changing that would definitely cause
existing customer designs to fail.  Nevertheless, we do need to
correct the existing rules and need to unify various aspects of
P1800 resolution with the 1364 rules.  Please feel free to
participate in the process when the committee begins to look
at this!

Gord.

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com