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

Mac, 

I believe Mark was mistaken is saying that unnamed blocks and automatics
can not be access form the VPI.

The protection is for referencing by name in the source text only. The
VPI has always be free to do almost whatever it wants as far as reading
and writing objects (encryption being an obvious exception).

A user should not be comparing unnamed objects between simulations
without naming the object. I don't think there is an expectation that
you should be able to compare things that don't have a name.

The only reason for generating a name in the PLI is when the target
application has no other means of representing an unnamed object

Dave

PS. Thanks for the updated SystemVerilog emacs mode!!





> -----Original Message-----
> From: Michael McNamara [mailto:mac@verisity.com]
> Sent: Thursday, May 19, 2005 8:29 AM
> To: stuart@sutherland-hdl.com
> Cc: Shalom.Bresticker@freescale.com; Rich, Dave; sv-bc@eda.org
> Subject: RE: [sv-bc] Naming of unnamed sequential blocks
> 
> 
> 
> Q1) Do we then prevent VPI write access to these variables in unnamed
> blocks? If not then this "protection" is rather incomplete.  If
> observability is also "messing with", one would presume that VPI
> read access should also be prevented.
> 
> Q2) Can one compare a waveform dumped from a design simulated with VCS
> to one dumped from NC to one dumped from MTI that has variables in
> unnamed blocks? Where in the VCD dump directory will these variables
> be declared?  How will third party dump libraries find these
> variables, if each vendor is free to give them different scope names,
> or no fullname?
> 
> S1) I stand by my assertion that if we want hidden variables, the way
> to do this is to add an attribute, much like "static", to the
> declaration.  Allowing declarations in an unnamed block is a very
> surprising and unintuitive way to get this "local" characteristic; and
> also does not address the need for module wide local variables.
> 
> To make my point very clear: As a principle of good language design,
> one should be able to look at the declaration of a thing and thereby
> know all of its characteristics.  We went a long way towards
> improving this in Verilog with the ANSI style declarations of ports
> and modules.  This having to consider the scope of a declaration in
> order to determine its hiddenness is a clear step backwards.
> 
> 
> -mac
> 
> 
> -- On May 19 2005 at 01:17, Stuart Sutherland sent a message:
>  > To: Shalom.Bresticker@freescale.com, Dave_Rich@mentor.com, sv-
> bc@eda.org
>  > Subject: "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
>  > >
>  > >
>  > >
>  >
>  >