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
 > > 
 > > 
 > > 
 > 
 >