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
>