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

Hi John,

When it comes to the default, I do indeed have an implicit
interpretation that no shadowing can happen rather a (multiple decl.)
compile error -- it seems "natural" to me given it's the default (not so
of course for other clocking blocks).
 
Thx for bringing that assumption of mine out -- you're right it's not
really THAT clear, and not sure if covered in LRM somewhere.

Thx.
-Bassam.

--
Dr. Bassam Tabbara
Synopsys, Inc.
(650) 584-1973

-----Original Message-----
From: John Havlicek [mailto:john.havlicek@freescale.com] 
Sent: Thursday, March 02, 2006 1:50 PM
To: Bassam.Tabbara@synopsys.COM
Cc: 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:

If you allow an unnamed default clocking block with declared items
inside, then I think it still needs to be clarified how the namespaces
work.  For example, can there be an item named "p" declared in the
unnamed default clocking block and also an item named "p" declared in
the enclosing context?  If so, then the shadowing rules need to be clear
for references to "p" 
both inside and outside the clocking block.

This stuff might be clear to others, but I don't recall seeing it
written down.  

Best regards,

John H.


> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
> Content-class: urn:content-classes:message
> Date: Thu, 2 Mar 2006 13:35:05 -0800
> Thread-Topic: [sv-ac] Need clarification from EC on #1325 (currently 
> in SV-AC bin)
> Thread-Index: AcY+O+W8BG2MBp9DT+yR5vDi8DF0nwABG+nQ
> From: "Bassam Tabbara" <Bassam.Tabbara@synopsys.com>
> Cc: <Mehdi.Mohtashemi@synopsys.com>, <sv-ac@eda.org>
> X-OriginalArrivalTime: 02 Mar 2006 21:35:08.0270 (UTC) 
> FILETIME=[2D6F40E0:01C63E41]
> 
> 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]=20
> 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=20
> > 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
>