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

I hope it is clear that block_item_declarations include typedefs,
enums, localparams and probably other data-related entities.  These
item_declarations have lifetimes governed by the block, whether it is
named or unnamed.   If it is unnamed, a unique (downright peculiar)
name will be invented for it.

But the labels on blocks are not data and have no lifetime to be
governed.  They exist to allow hierarchical access to the data
and other scopes declared in the block.  I claim that Named Block
Labels are NOT created local to the innermost scope.  Instead they
become a symbol at the level of the innermost NAMED scope and from
there they refer directly to their specific scope at a deeper level
of nesting in the (lifetime-governing) block structure.

The specific implementation would involve looking up the incipient
label in each of the parent (lifetime) scopes until you reach
one which is named.  If none of those scopes has a binding for the
name, then it is bound at the level of the named parent.  This leaves
just a few open sources where one of the intermediate scopes might
also define the name, thereby shadowing it in the inner scope.
If declarations and blocks can be interleaved, this might happen.
Or if locally defined functions are declared with the same name,
there would also be some confusion.  How serious do you think that
defect would be?

This rule's main advantage is that it gives equal weight to V2K's
goal that you name a block so you can access its contents, and to
SV's goal of making it easy to declare local variables.

---------------------------------------

Mac used a task invocation to bring up an additional issue:
Implicit wires must choose some scope to govern their lifetimes.

I cringe to suggest it, but implicit wires could belong to
the module, or wherever they would otherwise land if there
were no unnamed scopes.

Greg Jaxon




Greg Jaxon wrote:
> Gordon Vreugdenhil wrote:
> 
>> The three options I see are:
>>   1) unnamed block is always a real scope
>>   2) unnamed block is a real scope iff the block_item_declaration
>>      list is empty
>>   3) unnamed block is only a real scope for block_item_declaration
>>      list elements (i.e. other labels go into the nearest upwards
>>      named scope).
> 
> I was preparing a response outlining (3).  As you might guess, it
> gets messy.  There are two scope trees - one for data life times
> and one for hierarchical accessibility.  Fortunately one is a
> sub-tree of the other.  The named blocks merely offer a way
> to abbreviate one or more levels of naming in the full scope tree.
> The name collision rule they follow is a little unorthodox,
> but it is done is service to this dictum
> 
> P-1364 section 9.8.3 ends by saying:
>     The block names give a means of uniquely identifying
>     all variables at any simulation time.
> 
> Clearly SV is not backward compatible with this property.
> But just as clearly, those names exist to make variables
> accessible and we should do what is necessary to keep
> that function intact.
> 
> I second Mac's opinion that a declaration qualifier would be
> a better way to opt out of hierarchical accessibility.
> 
> Greg Jaxon
> 
> 
>