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

From: Eduard Cerny <Eduard.Cerny_at_.....>
Date: Thu Mar 02 2006 - 19:28:27 PST
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
> > 
> 
Received on Thu Mar 2 19:28:37 2006

This archive was generated by hypermail 2.1.8 : Thu Mar 02 2006 - 19:29:36 PST