[IM15]Re: When to Cycle Stamp?

Per,

I think Duaine's proposal of "emergency brake" stoppage semantics
rather than "just-in-time" may make this whole issue moot.

Let's discuss in tomorrow's meeting.

-- johnS

Bojsen, Per wrote:
> Hi John,
>
> I have attached a PDF with some waveforms intended to show and example
> where a BFM is controlling a slow cclock. It is practicing good/sane
> clock control and deasserting ReadyForCclock before trying to send
> its output message. In this example, it asserts ReceiveReady a few
> uclock cycles after deasserting ReadyForCclock. However, due to
> just-in-time the slow cclock (and the other cclocks) are not actually
> stopped yet. Once ReceiveReady is asserted, TransmitReady is expected
> to assert some time later. I have tried to show with shading how it
> might happen any number of uclock cycles later. Depending on when it
> happens, the cycle stamp counter will have different values.
>
> Now, if cycle stamping is to be done when the message is *transferred*,
> this example seems to indicate that the cycle stamp value for this
> particular setup can vary from run to run and from SCE-MI implementation
> to SCE-MI implementation.
>
> John, you said a couple of weeks ago:
>
> > It seems that there should always be a static number
> > of fast cclocks preceding a given slow cclock edge (since
> > SCE-MI requires clock port ratios to be observed) that
> > will not vary from simulation to simulation so I don't
> > think there's an issue there.
> >
> > However, there is a more sinister issue. An ill behaved
> > transactor, i.e. one that does not stop the clock upon
> > assertion of MsgOutputTransmitReady, can introduce
> > an element of non-determinsim. This is because it
> > will not be clear how many cclocks can elapse before
> > the infrastructure can finally take the transaction.
> >
> > Only when this happens can you see varying cyclestamps
> > from run to run. But then, one can argue that if there
> > is non-determinsim in the system, you'd like the cyclestamps
> > to reflect that. In fact, we relied on this feature
> > heavily to debug non-deterministic applications. It
> > turned out to be quite easy to figure out where non-
> > determinsm first creeps into the simulation by logging
> > the cyclestamps from run to run. This turned out to
> > be useful to isolate which transactors were not "playing
> > by the rules".
>
> This seems to contradict my example. Is there something I'm missing
> that makes my example invalid?
>
> BTW, if my example is valid, a way for a transactor to work around this
> behavior is to control a fast cclock rather than a slow one. This is
> the motivation for my proposal to define the clock ID 0 as the clock ID
> of the implicit 1/1 cclock so that BFMs can control it.
>
> Thanks,
> Per
>
> --
> Per Bojsen Email: <bojsen@zaiqtech.com>
> Zaiq Technologies, Inc. WWW: http://www.zaiqtech.com
> 78 Dragon Ct. Tel: 781 721 8229
> Woburn, MA 01801 Fax: 781 932 7488
>
>
>

-- 
This email may contain material that is confidential, privileged
and/or attorney work product for the sole use of the intended
recipient.  Any review, reliance or distribution by others or
forwarding without express permission        /\
is strictly prohibited. If you are     /\   |  \
not the intended recipient please     |  \ /   |
contact the sender and delete        /    \     \
all copies.                      /\_/  K2  \_    \_
______________________________/\/            \     \
John Stickley                   \             \     \
Principal Engineer               \             \________________
Mentor Graphics - MED             \_
17 E. Cedar Place                   \   john_stickley@mentor.com
Ramsey, NJ  07446                    \     Phone: (201) 818-2585
________________________________________________________________