Subject: Re: [sv-bc] Proposal for SV-BC75 declarations in unnamed blocks
From: Steven Sharp (sharp@cadence.com)
Date: Mon Mar 03 2003 - 14:54:46 PST
>> Even relative hierarchical references within the nested blocks are
>> forbidden?
>>
>Can you show by example what code you have a question with? I did not
>think 'relative' hierarchical references existed within a procedural block.
There are upward and downward hierarchical references in Verilog. For
example:
module top;
initial
begin : foo
reg r1;
bar.r2 = 0; // downward reference
begin : bar
reg r2;
end
begin : fubar
foo.r1 = 0; // upward reference
bar.r2 = 0; // upward then downward reference
top.bar.r2 = 1; // another upward then downward reference
r1 = 0; // upward reference, but not hierarchical name
end
end
endmodule
However, I think I understand the intent. Only variables declared directly
in the unnamed scope would be affected. They could be referenced inside
the unnamed scope by an "upward reference" that didn't use a hierarchical
name (normal nested scope rules). They could not be referenced by any
kind of hierarchical name.
The interesting issue is what happens when there is a named block inside
an unnamed block, and both have variables declared in them. I would expect
the variables in the named block to have the same hierarchical name as if
the unnamed block didn't have any variables in it (no name component for
the unnamed block). But this doesn't work with the idea that an actual
scope name could be generated for the unnamed block by the tool. Such a
scope name would have to be used in any hierarchical reference going through
it. For example:
module top;
initial
begin // no name
reg r1;
bar.r2 = 0; // downward reference legal
begin : bar
reg r2;
end
begin : fubar
top.r1 = 0; // upward reference ILLEGAL
bar.r2 = 0; // upward then downward reference legal
top.bar.r2 = 0; // this one is problematic
r1 = 0; // upward reference, but not hierarchical name so legal
end
end
endmodule
I would expect most of these to be legal, as noted. The paths don't
start outside the unnamed block and reference into it.
Normally I would expect top.bar.r2 to be legal. It would be legal in
Verilog now if the r1 declaration were removed. I don't see why adding
the r1 declaration, which doesn't change the actual hierarchy, would
make that illegal. But if the tool creates a generated name for the
unnamed block scope, then it becomes impossible to use top.bar.r2. The
name would have to be top.<generated_name>.bar.r2. This seems bad.
Adding a new variable declaration into a block shouldn't make all the
existing names in scopes inside that block change.
But the solution to various issues that I raised with variables that
don't have full path names was supposed to be the generation of these
scope names. Eliminate the generated names, and those problems come
back again.
Steven Sharp
sharp@cadence.com
This archive was generated by hypermail 2b28 : Mon Mar 03 2003 - 14:55:28 PST