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

Again, I love the idea of protected variables.

We (1364) created protected parameters by introducing a new type
(localparam).

In my opinion the industry would have been better served if the P1800
committee had introduced a protection qualifier for variables, rather
than delivering protection based on whether the variable is declared in
a block with a name or without a name.

Note that a model that has a task called from a block that has no name
will have a well defined hierarchical path, and all of its variables
will be accessible to a waveform tool; but will loose this path and
visibility if one adds a variable declaration to that block.  Other
invocations of this task will continue to be visible:

module M;
  always @(posedge clock ) begin
      t(a,b,c);
  end
endmodule

versus

module N;
   always @(posedge clock ) begin
	integer i;
      t(a,b,c);
  end
endmodule

versus

module O;
   always @(posedge clock ) begin: blk
	integer i;
      t(a,b,c);
  end
endmodule

The first module will properly dump M.a, M.b and M.c; but the second
module will not;  The third module, where the user gave the block a
name, will properly dump the information about the task (as O.blk.a,
O.blk.b and O.blk.c) in a way that the data is accessible by the
waveform tool in a simulator independent way.

I have the notion that I am perhaps wasting everyone's time by
continuing this discussion, as the concrete around the standard is
nearly dry; likely this is as it is.  *sigh*

-mac



-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Stuart Sutherland
Sent: Thursday, August 11, 2005 2:21 PM
To: sv-bc@eda.org
Subject: RE: [sv-bc] Is an unnamed block with declarations a scope?


I like the fact that any tool-created name for an unnamed block will be
unique for different tools.  From a designer's perspective, the value I
see
of variables declared in unnamed blocks is that there is no
predictable--or
at least consistent--hierarchical path to that variable.  This means
some
other engineer cannot unwisely tweak the values of my local variables.
This
level of protection can be important for IP models or other code where
users
of the model should not have full access to everything inside the model.
Granted, we now have encryption added to the P1364 base standard, but
that
was not there when local variables were added to the SV 3.0 some 3+
years
ago.  Encryption may be overkill for some situations, as well, where
local
variables with no standard hierarchy path gives a more fine-grain level
of
protection.

I do expect tools to create a hierarchy path for purposes of displaying
these local variables, but I think that path should not be standardized.
I
am glad to give up the ability to compare dump files on these local
variables for the protection if offers.  The same situation is true for
local variables declared as part of a for-loop--it is local to the loop,
and
cannot be messed with (or messed up) outside the loop using a
hierarchical
path name (for that matter, the same is true for variables declared in a
UDP
when the UDP is instantiated without an instance name).

Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
stuart@sutherland-hdl.com
+1-503-692-0898
  

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On 
> Behalf Of Steven Sharp
> Sent: Thursday, August 11, 2005 12:10 PM
> To: gordonv@model.com; mcnamara@cadence.com; Mark.Hartoog@synopsys.com
> Cc: Brad.Pierce@synopsys.com; sv-bc@eda.org
> Subject: RE: [sv-bc] Is an unnamed block with declarations a scope?
> 
> 
> >From: "Mark Hartoog" <Mark.Hartoog@synopsys.com>
> 
> >A related issue to this is the naming of unnamed scopes. Even if you
> >cannot use heirachical names to access variables in unnamed blocks,
> >they still might appear in dump files and wave form displays, where
> >they need to be given a unique name. I think this can be accomplished
> >by just making up names for the unnamed scopes, similar to what is
> >done for unnamed generate blocks. I'm not sure it is an important
> >issue to standardize that naming convention across tools. 
> 
> It could be handy for things like tools that compare dump files with
> each other.  The value is the same as for unnamed generate blocks.
> It is not a huge benefit, but then the cost of defining a standard
> name is essentially zero, so the benefit/cost ratio is high.
> 
> Steven Sharp
> sharp@cadence.com
> 
> 
>