Re: [sv-ac] call to vote on Mantis 1668

Hi Manisha:

The Clause 16 changes for 1668 are independent of 1549.

The Annex F changes for 1668 are critically dependent on 1549.  This
is because the push function must be applied after the flattening
algorithm that is the main subject of the Annex F changes in 1549.

Both 1549 and 1668 rely on the local variable declaration syntax.
1549 uses this to achieve proper scoping of local variable names in
the flattened sequences and properties.  1668 relies additionally on
this syntax to provide the correct positioning of the declaration
assignments prior to application of the push function.

The only places that the Annex F changes for 1668 are "nearby" the
changes for 1549 are the ones marked "consistent with 1549".  You will
have seen my mail to Lisa about the coloring.  In those changes, the
blue shows the additions from 1549 and the purple shows the additions
that are unique to 1668.  I have high confidence that the blue in
these changes is stable.

J.H.


> X-MimeOLE: Produced By Microsoft Exchange V6.5
> Content-class: urn:content-classes:message
> Date: Thu, 20 Sep 2007 11:11:18 -0700
> X-MS-Has-Attach: 
> X-MS-TNEF-Correlator: 
> Thread-Topic: [sv-ac] call to vote on Mantis 1668
> Thread-Index: Acf5yEix7Y8DQXZ8Q6WUgFjarH9MHwB3GifgAAL721A=
> From: "Kulshrestha, Manisha" <Manisha_Kulshrestha@mentor.com>
> Cc: <sv-ac@eda.org>
> X-OriginalArrivalTime: 20 Sep 2007 18:11:23.0737 (UTC) FILETIME=[A743CC90:01C7FBB1]
> 
> Hi John,
> 
> Could you please clarify if this proposal has dependencies on 1549. If
> yes, what are those dependencies ? Is it possible to write this proposal
> without the changes proposed in 1549 ? Since we have not voted on 1549
> yet, probably some of the language will change in 1549 by the time it
> gets approved.
> 
> Thanks.
> Manisha
> 
> -----Original Message-----
> From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
> Behalf Of Lisa Piper
> Sent: Thursday, September 20, 2007 11:23 PM
> To: john.havlicek@freescale.com
> Cc: sv-ac@server.eda.org
> Subject: RE: [sv-ac] call to vote on Mantis 1668
> 
> Hi John,
> 
> I have some questions:
> 
> 1668-formal-semantics.pdf:
> 1. the coloring needs to be reviewed. Specifically there appears to be
> very little purple and LOTS of blue. I think all of the ""local variable
> declaration" form" should be purple if you stick to the current coloring
> scheme at the beginning. There are entire sections that are blue that I
> suspect should be purple. Since new text is normally blue, I suggest
> putting 1549 dependencies in purple and keeping all 1668 additions in
> blue. Also, minimize 1549 references to de-couple this as much as
> possible, though it is likely that this will not make sense to the
> editor until 1549 is also approved.=20
> 
> 1668-2007-09-03.pdf:
> 1. Why did you choose to say that local variables have no initial
> default versus a default that is based on their type? Otherwise, I
> assume the local variable types are treated like types in properties and
> sequences (e.g. bit casting to the specified type)
> 
> 2. It is not clear to me when local variable declaration assignments
> occur. It states that the Preponed value of that timestep is used. In
> the example shown, is this the Preponed value relative to clk1 and clk2
> for the two copies of the local variable? But exactly when is the
> assignment made? For example, what happens if I say:
> 
> 	property p;
> 	logic v =3D e1;
> 	(@(posedge clk1) (1, v =3D e2) ##0 (a =3D=3D v)[*1:$] |-> b)
> 	and
> 	(@(posedge clk2) (1, v =3D e3) ##0 c[*1:$] |-> d =3D=3D v)
> 	;
> 	endproperty
> 
> Lisa
> 
> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of John
> Havlicek
> Sent: Monday, September 17, 2007 9:10 PM
> To: sv-ac@eda-stds.org
> Subject: [sv-ac] call to vote on Mantis 1668
> 
> Hi Folks:
> 
> This is the call to vote on Mantis 1668, as discussed in
> our last meeting.
> 
> The documents that are being voted on are 1668-2007-09-03.pdf
> and 1668-formal-semantics.pdf on Mantis.
> 
> Please vote if you are eligible.  See the details below.
> 
> Best regards,
> 
> J.H.
> 
> ------------------------------------------------------------------------
> --------------
> 
> Ballot on Mantis 1668=20
> 
> - Called on 2007-09-17, final ballots due by 2007-09-24 T 23:59-07:00.
> 
> 
>  v[xxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx-xx] Doron Bustan (Intel)
>  v[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-x] Eduard Cerny (Synopsys)    =20
>  n[-------x-xxx---------x-x-xxx-x---x] Surrendra Dudani (Synopsys)
>  v[-xxxxxxxxx-xx-xxxxx-xxx-xxx-------] Yaniv Fais (Freescale)
>  t[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] John Havlicek (Freescale - Chair)
>  v[xxxxxxxxxxxxxxxxrxxxxxxxxxxxxx-xxx] Dmitry Korchemny (Intel -
> Co-Chair)
>  v[-xxx-x--xx--xxxxx----------xx-xxxx] Manisha Kulshrestha (Mentor
> Graphics)
>  n[---------------xxxxx-------x-xx-x-] Jiang Long (Mentor Graphics)
>  n[-------x--xxx.....................] Joseph Lu (Altera)
>  v[xxxx..............................] Johan Martensson (Jasper)
>  n[------------x--x-xx--xx-xxxxxxx-x-] Hillel Miller (Freescale)
>  v[xxxxxxxxxxxxxxx-xxxxxxxx-xxxxxxxxx] Lisa Piper (Cadence)
>  v[xxxxxx-x-xxxxx-x..................] Erik Seligman (Intel)
>  n[--------xxxx-----xxxx-xx----------] Tej Singh (Mentor Graphics)
>  v[--xxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxx] Bassam Tabbara (Synopsys)
>  v[xxxxxxxx-xxxxxxxxxx...............] Tom Thatcher (Sun Microsystems)
>    |---------------------------------- attendance on 2007-09-11
>  |------------------------------------ voting eligibility for this
> ballot
> |------------------------------------- email ballots received
> 
> 
> 	Legend:
> 		x =3D attended
> 		- =3D missed
> 		r =3D represented
> 		. =3D not yet a member
> 		v =3D valid voter (2 out of last 3)
> 		n =3D not valid voter
>                 t =3D chair eligible to vote only to make or break a tie
> 
> --=20
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 
> 
> --=20
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 
> 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.