RE: [sv-ac] Need clarification from EC on #1325 (currently in SV-AC bin)

Not just in generates: 

6.6 says, 

"In SystemVerilog, data can be declared in unnamed blocks as well as in
named blocks. These data are visible
to the unnamed block and any nested blocks below it. Hierarchical
references cannot be used to access these
data by name."

and 19.13(f) says,

"The block name space is introduced by named or unnamed blocks, the
specify, function, and task constructs. It unifies the definitions of
the named blocks, functions, tasks, parameters, named events, variable
type of declaration, and user-defined types within the enclosing
construct."

Shalom

> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On
> Behalf Of Eduard Cerny
> Sent: Friday, March 03, 2006 5:28 AM
> To: john.havlicek@freescale.com; Bassam.Tabbara@synopsys.com
> Cc: Mehdi.Mohtashemi@synopsys.com; sv-ac@eda.org
> Subject: RE: [sv-ac] Need clarification from EC on #1325
> (currently in SV-AC bin)
> 
> Hi,
> 
> in generates, unnamed for or if creates an internal label -
> name space.
> But you cannot then access it through xmr (or vpi?). I am not
> convinced
> that unnamed clocking  is a good idea.
> 
> ed
> 
> > -----Original Message-----
> > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On
> > Behalf Of John Havlicek
> > Sent: Thursday, March 02, 2006 7:12 PM
> > To: Bassam.Tabbara@synopsys.COM
> > Cc: Bassam.Tabbara@synopsys.COM; john.havlicek@freescale.com;
> > Bassam.Tabbara@synopsys.COM; Mehdi.Mohtashemi@synopsys.COM;
> > sv-ac@eda.org
> > Subject: Re: [sv-ac] Need clarification from EC on #1325
> > (currently in SV-AC bin)
> >
> > Hi Bassam:
> >
> > I imagined that if the items declared in unnamed blocks are
> treated
> > as though in the enclosing namespace, then the uniqueness
> > rules for names
> > there should apply.  Two declarations of the same name should
> probably
> > be an error.
> >
> > I'm not sure there is any precedent for this treatment in SV
> already.
> >
> > J.H.
> >
> > > X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
> > > Content-class: urn:content-classes:message
> > > Date: Thu, 2 Mar 2006 13:42:17 -0800
> > > Thread-Topic: [sv-ac] Need clarification from EC on #1325
> > (currently in SV-AC bin)
> > > Thread-Index: AcY+O+W8BG2MBp9DT+yR5vDi8DF0nwABG+nQAABCf4A=
> > > From: "Bassam Tabbara" <Bassam.Tabbara@synopsys.com>
> > > Cc: <Mehdi.Mohtashemi@synopsys.com>, <sv-ac@eda.org>
> > > X-OriginalArrivalTime: 02 Mar 2006 21:42:21.0635 (UTC)
> > FILETIME=[2FBD8130:01C63E42]
> > >
> > > Oops sorry for second email, just some more comments.=20
> > >
> > > - Option: "One could allow them and treat items declared
> > within them to
> > > be in the enclosing namespace"
> > >
> > > Worthy goal but makes it kinda problematic if we have more
> than one
> > > unnamed clocking block in enclosing scope, albeit a "last
> > declaration"
> > > type of semantic can be done ...
> > >
> > > - Option: "allow assertion statements (assert, cover,
> > assume) inside the
> > > clocking block"=20
> > >
> > > May open the door to allowing other procedural stmts within
> ...
> > >
> > > Thx.
> > > -Bassam.
> > >
> > > --
> > > Dr. Bassam Tabbara
> > > Synopsys, Inc.
> > > (650) 584-1973
> > >
> > > -----Original Message-----
> > > From: Bassam Tabbara=20
> > > Sent: Thursday, March 02, 2006 1:35 PM
> > > To: 'john.havlicek@freescale.com';
> Bassam.Tabbara@synopsys.COM
> > > Cc: Mehdi.Mohtashemi@synopsys.COM; sv-ac@eda.org
> > > Subject: RE: [sv-ac] Need clarification from EC on #1325
> > (currently in
> > > SV-AC bin)
> > >
> > > Hi John,
> > >
> > > Thx for listing the alternatives for EC to consider.
> > >
> > > About your last point on default clocking, my thinking is
> to allow
> > > unnamed versions because any reference outside (say to
> property p
> > > declared inside) does not need the name hierarchy prefix,
> it goes to
> > > default (by default :)).
> > >
> > > -Bassam.
> > >
> > > --
> > > Dr. Bassam Tabbara
> > > Synopsys, Inc.
> > > (650) 584-1973
> > >
> > > -----Original Message-----
> > > From: John Havlicek [mailto:john.havlicek@freescale.com]
> > > Sent: Thursday, March 02, 2006 12:57 PM
> > > To: Bassam.Tabbara@synopsys.COM
> > > Cc: Mehdi.Mohtashemi@synopsys.COM; sv-ac@eda.org
> > > Subject: Re: [sv-ac] Need clarification from EC on #1325
> > (currently in
> > > SV-AC bin)
> > >
> > > Hi Bassam:
> > >
> > > I just want to point out some other options for unnamed
> > clocking blocks.
> > > One could allow them and treat items declared within them
> > to be in the
> > > enclosing namespace.  From the point of view of declaration
> > of assertion
> > > items, this would allow the clocking block to group and
> > attach the clock
> > > without requiring the clocking block name when referencing
> > a declared
> > > item. =20
> > >
> > > Another possibility is to allow assertion statements
> (assert, cover,
> > > assume) inside the clocking block itself and allow them to
> > reference the
> > > declared items inside that clocking block, but not within
> > other unnamed
> > > clocking blocks.
> > >
> > > I see some advantages and disadvantages to both of these
> options.
> > > If others do not see clearly what the right thing to do is,
> > then your
> > > suggestion about making the unnamed clocking blocks illegal
> may be
> > > safest.
> > >
> > > By the way, a default clocking block can still have items
> declared
> > > within it, so allowing default clocking to be unnamed
> > leaves open the
> > > question.  I like being able to write a default clocking
> > with no items
> > > in it--in fact I'd like to be able to write=20
> > >
> > >    default clocking <event>;
> > >
> > > instead of=20
> > >
> > >    default clocking [name] <event>; endclocking
> > >
> > > One could say that default clocking can be unnamed provided
> > there are no
> > > items declared within.
> > >
> > > Best regards,
> > >
> > > John H.
> > >
> > > > X-Authentication-Warning: server.eda.org: majordom set
> > sender to=20
> > > > owner-sv-ac@eda.org using -f
> > > > X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
> > > > Content-class: urn:content-classes:message
> > > > Date: Thu, 2 Mar 2006 10:13:17 -0800
> > > > Thread-Topic: Need clarification from EC on #1325
> > (currently in SV-AC
> > > > bin)
> > > > Thread-Index: AcY+JPrOY/v4ADowSO+hBKxD7QX7TQ=3D=3D
> > > > From: "Bassam Tabbara" <Bassam.Tabbara@synopsys.com>
> > > > Cc: <sv-ac@eda.org>
> > > > X-OriginalArrivalTime: 02 Mar 2006 18:13:25.0598 (UTC)=20
> > > > FILETIME=3D[FFAE0FE0:01C63E24]
> > > > X-Virus-Status: Clean
> > > > Sender: owner-sv-ac@eda.org
> > > >=20
> > > > This is a multi-part message in MIME format.
> > > >=20
> > > > ------_=3D_NextPart_001_01C63E24.FFB64D8E
> > > > Content-Type: text/plain;
> > > > 	charset=3D"us-ascii"
> > > > Content-Transfer-Encoding: quoted-printable
> > > >=20
> > > > Hi Mehdi,
> > > > =3D20
> > > > On behalf of AC, can I request that you and EC look over
> > the following
> > >
> > > > item, even take it over ? -- currently in AC's bin,
> > assigned to me.
> > > > =3D20
> > > > ** In my opinion, if not default clocking then it's
> > illegal (unnamed
> > > > block) -- In fact, not sure now what purpose unnamed
> > clocking block=20
> > > > serves (except for default), so worthy of a clarification
> > in that=20
> > > > clause/section.
> > > >=20
> > > > Thx.
> > > > -Bassam.
> > > > =3D20
> > > > =3D3D=3D3D=3D3D
> > > > **Issue 1325: Clarify references to items declared in
> > unnamed clocking
> > >
> > > > blocks.=3D20 =3D20 A clocking block is not required to
> have a=20
> > > > clocking_identifier (i.e., name). If sequences or
> > properties are=20
> > > > declared within such a clocking block, they must be
> > instantiated=20
> > > > outside the clocking block in assertion statements in
> > order to be=20
> > > > evaluated. The LRM does not say how to reference such
> > declarations or=20
> > > > whether such references are illegal.
> > > >=20
> > > > For example, is the following legal?
> > > >=20
> > > >    module foo (...);
> > > >    ...
> > > >       clocking @(event);
> > > >           property p; ... endproperty
> > > >       endclocking
> > > >       a1 : assert property (p); // <<<<<<<<<<
> > > >   endmodule=3D20
> > > > =3D3D=3D3D
> > >
> >