RE: [sv-bc] Naming of unnamed sequential blocks

Dave Rich wrote:
>But I disagree with the notion that the occurrence of declaring a
>variable in an unnamed block creates a scope. Consider a 'for' loop with
>a local declaration. I don't think users expect that to hide the nested
>named blocks in the 'for' loop.

I don't think anyone will agree with you on this.  Consider the
following code:

  begin: foo
    for (int i = 0; i < 10; i++)
      a[i] = 0;
    for (integer i = 0; i < 10; i++)
      b[i] = 0;
  end
  
If the implicit unnamed block for the for-loop is not a scope, then
what scopes are the two variables named i in?  They clearly are not in
scope foo, since there would then be two different variables named i in
scope foo.  They are clearly in two separate scopes nested inside the
scope foo.

Section 6.6 (draft 4) says:
"Note that in SystemVerilog, data can be declared in unnamed blocks as
well as in named blocks. This data is visible to the unnamed block and
any nested blocks below it."

That matches the usual definition of a scope.

Section 19.13 (draft 4) describes "name spaces", a sloppy term in the
LRM which mostly refers to something like a scope.  The 6th bullet says:
"The block name space is introduced by named or unnamed blocks, the specify, 
function, and task constructs. It unifies the definitions of the named blocks, 
functions, tasks, parameters, named events, variable type of declaration and 
user-defined types within the enclosing construct."

Note the mention of unnamed blocks here.

I don't think that you are really trying to say that these unnamed blocks
aren't scopes, in the accepted meaning of the term.  You are trying to
argue that these scopes affect hierarchical naming differently from other
scopes.  Unfortunately, there is nothing in the standard to describe such
rules, so the normal rules would apply.  Rules to get the kind of naming
that you want would be more complex and inconsistent with the existing
rules.  Such rules would potentially create other problems.

>It's too late to debate whether it was a good idea to allow variables to
>be declared in unnamed blocks. It will be in the IEEE-1800 standard. 

I have to agree with you on this part.  It was already debated a long
time ago, and the debate was settled on the basis that these unnamed
blocks would act like scopes with tool-generated names.  Changing that
behavior now would be a change to the standard, which could be brought
up in a ballot comment, which would open it up to debate again.

Steven Sharp
sharp@cadence.com