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

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On 
> Behalf Of Shalom.Bresticker@freescale.com
> Sent: Wednesday, May 18, 2005 10:12 PM
> To: Rich, Dave
> Cc: sv-bc@eda.org
> Subject: RE: [sv-bc] Naming of unnamed sequential blocks
> 
> True, but I think a primitive has no internals which are 
> accessible even if it is named.

The VPI can also access both a name and a fullname (hierarchical path) of a
primitive instance, whether there is an explicit instance name or not.
Further, a sequential user-defined primitive has an internal reg variable,
the value of which is accessible to the VPI, for each instance of the UDP,
whether it is named or unnamed.  In addition, the contents of the table in a
UDP is accessible to the PLI, though the table is associated with the UDP
definition, not an instance of the UDP.

I sent an earlier e-mail on this thread, but I do not think it made it
through the sv-bc reflector--at least the message never came back to me.  In
case no one else saw my earlier message, the highlights are:

- Local declarations in unnamed begin...end blocks have been around since
the very first draft of the Accellera 3.0 LRM (back when the entire LRM was
only about 50 pages).  These local variables should not be a surprise to
anyone working on the SV standard nearly 4 years later.

- Local declarations in unnamed begin...end blocks provide a way for
modelers to define a variable that user's cannot mess with.  E.g.: A user of
an IP model cannot use--or at least should be able to use--a hierarchical
path to reach in and modify local variables in unnamed blocks that are
within the IP model.  Of course, the P1364-2005 encryption gives even
greater protection to the contents of an IP model, but the P1364-2005
encryption did not exist 4 years ago, when local variables in unnamed blocks
were added in SystemVerilog.

- I would expect tools to provide a made-up path to local variables unnamed
begin...end blocks when the variables are displayed (such as in a waveform
display), but I would not want all tools to make up the same path name.
That would defeat the limited protection that not having a user-defined
hierarchy path provides.  I would expect that local variables declared as
part of a for-loop statement would be treated the same way--a made-up path
for display purposes, but not a standard path.

- IMHO, local variables in unnamed blocks should only have a name property
in the VPI.  They should not have a fullname property (a hierarchical path).
This gives the VPI similar access to the local variables as in the source
code.  The same should be the case for variables declared as part of a
for-loop statement.  The VPI should have access to a name property, but not
a fullname property.

Just my 2 cents worth...

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 Shalom.Bresticker@freescale.com
> Sent: Wednesday, May 18, 2005 10:12 PM
> To: Rich, Dave
> Cc: sv-bc@eda.org
> Subject: RE: [sv-bc] Naming of unnamed sequential blocks
> 
> True, but I think a primitive has no internals which are 
> accessible even if it is named.
> 
> Shalom
> 
> 
> On Wed, 18 May 2005, Rich, Dave wrote:
> 
> > I will mention that there is no standard for naming unnamed 
> primitive
> > instances, which have been around longer than generate.
> 
> -- 
> Shalom.Bresticker @freescale.com                     Tel: 
> +972 9  9522268
> Freescale Semiconductor Israel, Ltd.                 Fax: 
> +972 9  9522890
> POB 2208, Herzlia 46120, ISRAEL                     Cell: 
> +972 50 5441478
>   
> [ ]Freescale Internal Use Only      [ ]Freescale Confidential 
> Proprietary
> 
> 
>