Re: [sv-bc] Is an unnamed block with declarations a scope?

Steven Sharp wrote:
>>From: Greg Jaxon <Greg.Jaxon@synopsys.com>
> 
> 
>>Gord started this thread  by pointing out that if unnamed blocks
>>were "real scopes", this would change the meaning or legality of
>>certain V2K dusty decks.  The LRM's "Name spaces" section currently
>>has this backward-incompatible effect.  If cell names in SV suddenly
>>pick up new hierarchy layers with compiler-generated names, this is
>>going to be bad for many parts of the flow downstream of the SV tool.
> 
> 
> Nobody has seriously proposed this interpretation.  It is easy enough
> to recognize that that section's reference to "unnamed blocks" was
> intended to mean "unnamed blocks containing declarations."

Is a named block a "declaration"?  If you put a named block inside
an unnamed block, does the unnamed block become a "real scope" thereby
making the named block and its contents inaccessible via hierarchical
name?

>>>To make sure that everyone (including me) understands what you are
>>>saying, here is an example that illustrates what I think you said.
>>
>>I did mention that shadowing interactions would be the most confusing
>>aspect of the problem.
> 
> I was verifying that I understood what you meant, and providing an
> example to it clearer what you were talking about.

Your example also illustrates that this issue affects the
synthesizable subset.  I was just trying to blunt the "reductio
ad absurdum" thrust of the extreme example you used.

>>Notice that to treat the identifiers' /declarations/ similarly,
>>we need Gord's proposal (1): every declaration is local to the
>>innermost enclosing block, whether or not that block is named.
>>But we've already seen that (1) is not V2K-compatible.  So the
>>symmetry here is limited at best.
> 
> 
> This asymmetry already exists in Verilog: a variable declaration can
> only appear immediately inside a named scope, while a named block is
> not restricted this way.  Interpretation (2) simply requires the
> compiler to insert a scope where Verilog would require one, and not
> where it wouldn't.  It does not create any new asymmetry.

Right.  And the answer to my first question above is that the named
block does not convert its immediate parent block into a scope.

If you ever /do/ convert it into a scope - by, e.g., writing a
for loop with a local index variable around the named block,
or declaring some inconsequential temp variable - then the
name binding to the block will jump down into that scope
instead of staying up in the hierarchical naming tree as (3)
seems to suggest.

> Your later example implies a particular variation.  It has the problem
> that a name does not necessarily resolve to the closest textually nested
> declaration of that name.  This would be extremely confusing.

Perhaps I slipped.  I think the first level name in any reference
always resolves to the closest textually nested scope.  Disable
statements and ordinary expressions employ the same rule.

My answer to the "shadowing" problem goes like this:
    A) A locally declared name can always shadow a more global meaning.
       We could imagine a more restrictive rule to prevent some
       kinds of shadowing, but I'd resist.

    B) When a block name is to be bound in a scope global to the
       currently active scope, it must be unique in ALL the unnamed
       scopes up to and including the first named scope where it is
       finally bound.

Rule B means that at the point of declaration, the block's
name cannot also be hidden.  This simplifies the symbol table
insertion logic and prevents the blatant ambiguity in our
recent examples.

Rule B may look a bit more complicated at first.  But consider
the "rule" which someone inserting the first local declaration
in an unnamed block must obey.  Under (2), to do no harm, he must
make sure the block does not enclose any named hierarchy!  If it
does, (2) causes a silent change in meaning.  Whereas (3) yields
either no change in meaning, or else a clear "name collision" error.


Proposal 3, using rule B weaves together all the hierarchical
naming so that the unnamed scopes don't interfere as much.
This should lead to more stable results as unnamed scopes come
and go during editing.

We routinely hear from customers when something we do changes their
cell or wire names.  I expect they beat themselves up just as much
when a patch causes such side effects.

Greg Jaxon