Re: [sv-ac] mantis 1550

Hi Ed:

Can we have a clear statement somewhere in 17.7.3 that says that the
return values of all of the sampled value functions change only in the
postponed region?

Also, can we have a statement that update events due to changes in
sampled value functions are scheduled in the appropriate region of the
next time slot?  [It is still not clear to me that all these will go
to the active region -- maybe some will go, e.g., to the reactive
region.]

If the redundancy is the bottleneck, one could say something like, "It
follows from the scheduling semantics (Section 9) that <blah blah blah>."

Best regards,

John H.

> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
> Content-class: urn:content-classes:message
> Date: Thu, 2 Nov 2006 07:58:41 -0800
> Thread-Topic: [sv-ac] mantis 1550
> Thread-Index: Acb+j4hFCYP8sfsBR0avmxNqtXjgewABQSDgAADLaVA=
> From: "Eduard Cerny" <Eduard.Cerny@synopsys.com>
> X-OriginalArrivalTime: 02 Nov 2006 15:58:42.0631 (UTC) FILETIME=[C50FED70:01C6FE97]
> 
> That's what I had in mind and tried to explain.
> ed=20
> 
> > -----Original Message-----
> > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On=20
> > Behalf Of Rich, Dave
> > Sent: Thursday, November 02, 2006 10:53 AM
> > To: john.havlicek@freescale.com; sv-ac@eda-stds.org
> > Subject: RE: [sv-ac] mantis 1550
> >=20
> > I think the semantics of the return value of these function is no
> > different then the simple Verilog system function $time.=20
> >=20
> > You have to distinguish between the values returned by=20
> > references to the
> > function versus evaluation events scheduled by a processes waiting on
> > the event expression. This is somewhat harder to put into=20
> > words than to
> > actually implement it.
> >=20
> > I think it is OK to say that the value that will be returned by the
> > function is updated in the postponed region because no one=20
> > can schedule
> > a call in that region. You can also say that an update event is
> > scheduled for the active region of the next time slot.
> >=20
> > Dave
> >=20
> >=20
> > > -----Original Message-----
> > > From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org]
> > On
> > > Behalf Of John Havlicek
> > > Sent: Thursday, November 02, 2006 6:59 AM
> > > To: sv-ac@server.eda-stds.org
> > > Subject: [sv-ac] mantis 1550
> > >=20
> > > Hi Ed:
> > >=20
> > > In general, I like the semantics for $sampled and $past in your 1550
> > > proposal, but I have some concerns that make me vote "no" at this
> > > time.
> > >=20
> > > 1. I don't think we have yet clarified when the return=20
> > values of these
> > >    functions change.  You say that $sampled is stable throughout the
> > >    simulator timestep and that $past changes in the=20
> > postponed region.
> > >=20
> > >    Can the return value of $past really change in the postponed
> > region?
> > >=20
> > >    I think it is bad if there can be calls/references to any of the
> > >    sampled value functions between the point that the return value
> > >    of one changes and the point that the return value of another
> > >    changes in the same timestep.
> > >=20
> > > 2. A related question is that of the semantics of events that refer
> > >    to sampled value functions.  The intuition seems to be that the
> > >    return values of sampled value functions change "in between" the
> > >    simulation timesteps, so when do we schedule something like
> > >=20
> > >       @($sampled(p)) S1
> > >=20
> > >    when written in various contexts (e.g., in a module, in=20
> > a program)?
> > >=20
> > >=20
> > > 3. I would like to see $rose, $fell, and $stable defined in terms of
> > >    $sampled and $past.  I think this should be easy.
> > >=20
> > > We may need to get some SV-BC or other help with items 1 and 2.
> > >=20
> > > Best regards,
> > >=20
> > > John H.
> >=20
> >=20