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

-- On May 18 2005 at 13:34, Rich, Dave sent a message:
 > To: mac@verisity.com, gordon_vreugdenhil@mentor.com, sv-bc@eda.org
 > Subject: "RE: [sv-bc] Naming of unnamed sequential blocks"
 >
 > They were thinking that there are times that you don't want others to
 > have access to locally declared variables, and other languages get along
 > fine without having to name locally declared blocks.
 > 
 > When you use the PLI, you use iterators instead of accessing the blocks
 > by name.

 So, if the idea is that it is useful to hide variables, wouldn't you
 want to hide them from the PLI also? Hence no need to know their
 name.

 The right way (IMHO) to enable the declaration of hidden variables
 would be a qualifier on the variable definition:

 local reg [31:0] mypasswd; // local means no PLI or hierarchial access

 Then one doesn't also get the unuseful rules of scope applied. (you
 can only refer to variables declared in a block by statements
 contained in the block). Also one could declare these hidden
 variables at module scope; one can not do this (except, weirdly, in a
 constat generate block...)

 As it is, what happens if there are named blocks with variable
 declarations in the unnamed block that has a declaration? What is the
 path to those variables?

 module foo;
 ...
 always @(a or b or c) begin // no name so I can have a local variable
    reg [31:0] mysecret; // magically hidden name because begin is not
			 // named
    mysecret = $random;
    fork
      begin : f1
        wait #1000 disable f2;
      end
      begin : f2
        reg [3:0] channel;
	pid = $random(0,5);
	data = fetch_data(pid, mysecret);
	disable f1;
      end
    join
 end

 is it foo.f2.channel, or foo.unamed_block1.f2.channel??  Or are these
 also hidden?  That would be a change because in 1364 these would be
 foo.f2.channel


 > > -----Original Message-----
 > > From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
 > > Michael McNamara
 > > Sent: Tuesday, May 17, 2005 8:50 PM
 > > To: Vreugdenhil, Gordon
 > > Cc: SV_BC List
 > > Subject: RE: [sv-bc] Naming of unnamed sequential blocks
 > > 
 > > 
 > > Wow.  I would rather that P1800 undo allowing unnamed blocks to
 > > contain declarations.  What were they thinking...
 > > 
 > > If we can't undo that bit of oversight, then I would go for following
 > > the convention of generate.
 > > 
 > > -- On May 17 2005 at 16:31, Gordon Vreugdenhil sent a message:
 > >  > To: sv-bc@eda.org
 > >  > Subject: "[sv-bc] Naming of unnamed sequential blocks"
 > >  > P1800 allows sequential unnamed blocks to have declarations.  There
 > >  > is no naming convention specified for pli access meaning that
 > vendors
 > >  > will almost certainly do varying things.  For unnamed generate
 > blocks,
 > >  > 1364-2005 defines an "external name" format and rules for naming
 > >  > each unnamed block.  Do other people think that we should follow
 > >  > the same kind of naming convention for sequential blocks?  I think
 > >  > we should.  If others agree, we might want to at least brainstorm
 > >  > about some variants to the "external name" rules for sequential
 > >  > blocks.
 > >  >
 > >  > Gord.
 > >  > --
 > >  >
 > --------------------------------------------------------------------
 > >  > Gordon Vreugdenhil,  Staff Engineer               503-685-0808
 > >  > Model Technology (Mentor Graphics)                gordonv@model.com
 > >  >
 >