Re: [sv-ac] reminder to vote on mantis 1550

From: John Havlicek <john.havlicek_at_.....>
Date: Wed Jan 24 2007 - 17:42:22 PST
Hillel & Ed:

I think there are several things going on here.

First, based on 9.3.1, I think that the declaration assignments for
static variables execute as part of 

   initialize the values of all nets and variables

Then the initialization events are scheduled into the time 0 slot.
This does not mean that any assignments from an initial block are
performed yet.  

Then, assuming that there is some event, we execute the time 0 slot.

Then the preponed region of the time 0 slot is executed.

Thus, the declaration assignments for static variables will influence
the preponed values in the time 0 slot.

If $sampled refers to a static variable with declaration
assignment, then I think that in the time 0 slot the value from 
the declaration assignment should be used rather than the default 
initial value for the type of the variable.  

The statement in the proposal that $sampled returns the default intial
value (presumably of the type) of its argument in the time 0 slot
could therefore be inconsistent with the statement that $sampled
returns the preponed value of its argument in the current time slot,
and should probably either be removed or clarified.

I think that according to 9.3.1, assignments in an initial block will
be scheduled for the active region of the time 0 slot.  These
assignments do not, I believe, affect the preponed values in the time
0 slot.  If we consider $sampled always to return the preponed value,
then initial block assignments will not affect $sampled in the time 0
slot.

Hillel, are you asking for the defintion of $sampled to be influenced
by initial block assignments in the time 0 slot?  If so, then the
definition of $sampled needs to be changed to distinguish the time 0
slot from all the other time slots.  I would like to see a strong
rationale for such an inconsistency, one that explains, e.g., why
static variables with declaration assignments cannot be used.

Best regards,

John H.

> Content-class: urn:content-classes:message
> X-MimeOLE: Produced By Microsoft Exchange V6.5
> X-OriginalArrivalTime: 24 Jan 2007 18:30:41.0689 (UTC) FILETIME=[C0BB0090:01C73FE5]
> Date: Wed, 24 Jan 2007 11:30:36 -0700
> X-MS-Has-Attach: 
> X-MS-TNEF-Correlator: 
> Thread-Topic: [sv-ac] reminder to vote on mantis 1550
> Thread-Index: Acc/JcA24JDBTV1VQc2QjprTXfKfWwAlgkfgAAIJ6XAAA6aw4AAEm8jwAAAfAlA=
> From: "Miller Hillel-R53776" <r53776@freescale.com>
> 
> This is a multi-part message in MIME format.
> 
> ------_=_NextPart_001_01C73FE5.C5169280
> Content-Type: text/plain;
> 	charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
> 
> Still what is wrong with the proposal to use the value after
> initialization at time 0? Where does this break consistency?
> 
> ________________________________
> 
> From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com]=20
> Sent: Wednesday, January 24, 2007 8:27 PM
> To: Miller Hillel-R53776; Eduard Cerny; Havlicek John-r8aaau;
> sv-ac@eda-stds.org
> Subject: RE: [sv-ac] reminder to vote on mantis 1550
> 
> 
> Hi Hillel,
> =20
> apart from the uesr initialization, what is really the problem with the
> current definition? Yes, it can happen when there is a clocking event at
> time 0, or if you have $past with longer number of clocks to go back,
> etc.
> =20
> Best regards,
> ed
> =20
> PS the forced initialization can be a feature of a tool, not the LRM.
> =20
> 
> 
> ________________________________
> 
> 	From: Miller Hillel-R53776 [mailto:r53776@freescale.com]=20
> 	Sent: Wednesday, January 24, 2007 1:14 PM
> 	To: Eduard Cerny; Havlicek John-r8aaau; sv-ac@eda-stds.org
> 	Subject: RE: [sv-ac] reminder to vote on mantis 1550
> =09
> =09
> 	Ed,
> 	=20
> 	What $ functions use $sampled values which are to be before time
> 0?
> 	=20
> 	Does this happen when there is a "clocking event" at time zero?=20
> 	=20
> 	Why can't we take the route of using the values after
> initialization as the $sampled value in the first preponed region at
> time 0? What does this break?
> 	=20
> 	There also needs to be away to allow the user to control the
> initialization of the $functions at time Zero. This could be needed if a
> counter example is produced by a formal tool that needs to be replayed
> in simulation. If the $sampled at the first preponed region is from the
> time 0 initilization stage then this is doable.
> 	=20
> 	Thanks
> 	Hillel
> 	=20
> 	=20
> 	=20
> ________________________________
> 
> 	From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com]=20
> 	Sent: Wednesday, January 24, 2007 4:31 PM
> 	To: Miller Hillel-R53776; Havlicek John-r8aaau;
> sv-ac@eda-stds.org
> 	Subject: RE: [sv-ac] reminder to vote on mantis 1550
> =09
> =09
> 	Hello Hillel,
> 	But the functions use $sampled values which are to be before
> time 0. Hence the initialization to the default value of the type. What
> else would you suggest?ed
> 	=20
> 
> 
> ________________________________
> 
> 		From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org]
> On Behalf Of Miller Hillel-R53776
> 		Sent: Wednesday, January 24, 2007 8:53 AM
> 		To: Havlicek John-r8aaau; sv-ac@eda-stds.org
> 		Subject: RE: [sv-ac] reminder to vote on mantis 1550
> 	=09
> 	=09
> 
> 		Hi,
> 
> 		I vote no even though I am not elligible. The reason is
> that it is not clear what the intialized values are of the $ functions.
> 
> 		The current schedular code shows an initialization
> process, before going into the first preponed area (see below). This
> means that the initial value of an expression is determined by its
> initilization at time slot 0 and not by its default type value as
> specified in the proposal.
> 
> 		execute_simulation {
> 
> 		T =3D 0;
> 
> 		initialize the values of all nets and variables;
> 
> 		schedule all initialization events into time 0 slot;
> 
> 		while (some time slot is nonempty) {
> 
> 		move to the next future nonempty time slot and set T;=20
> 
> 		execute_time_slot (T);
> 
> 		}
> 
> 		}
> 
> 		Hillel Miller>
> 
> 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Wed Jan 24 17:42:48 2007

This archive was generated by hypermail 2.1.8 : Wed Jan 24 2007 - 17:43:04 PST