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

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


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

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

>So what you've written is illegal code;
>we could argue about the error message(s); but let's move on.

Yes, I said that some part of it was illegal.  The question was which part.
Knowing what were errors under your suggested interpretation is actually
important.  The problem is that while interpretation (2) is fully specified
by Gord's simple description, (3) is not.  There are multiple different ways
that the "shadowing interactions" could be resolved, each resulting in a
slightly different interpretation.  Each of them has different problems,
and none is clearly "more correct".  This extra complexity is one of the
problems of (3).  And without knowing what variation you were suggesting,
it was difficult to discuss its problems.

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.

Steven Sharp
sharp@cadence.com