Subject: Re: When to Cycle Stamp?
From: Stickley, John (john_stickley@mentorg.com)
Date: Fri Feb 27 2004 - 08:17:22 PST
Per,
Points well taken.
Our preference, and, I believe our current implementation
is at the time of grant (i.e. data movement) rather than request.
This does make the implementation a bit easier because it does
not require it to mark a timestamp immediately even if it
is not ready to grant the message. If I'm notmistaken, I
don't think we latch the output data. We let the source
hold it until the grant (which it is required to do anyway).
This saves gates. Timestamping at the time of request
would require extra latching of data that is otherwise
unecessary.
What we do is opposite what you suggest below. But I think either
is valid as long as different implementations are consistent.
Since it does not matter, I would err on the side of ease
of implementation. But I recognize that your implementation
may be different than ours so you may have a different opinion !
-- johnS
Bojsen, Per wrote:
> Hi,
>
> as I was thinking about the time-ordering issues we were
> discussing at yesterday's meeting I realized that it is
> not clear to me exactly when a message is cycle stamped.
> I have been assuming that the cycle stamp is derived from
> a (possibly implicit) 64-bit counter running off the
> implicit 1/1 clock. So is the value for the CycleStamp()
> method of the SceMiMessageData object taken from this
> counter
>
> a) at the time when TransmitReady is asserted on
> the output port,
>
> b) when the message moves (ReceiveReady and TransmitReady
> asserted), or
>
> c) some other time?
>
> The spec does not say much about this. My guess and
> preference is a. Note, this is an issue even when the
> BFM stops the cclocks before asserting TransmitReady since
> if it is using a very slow clock, due to just-in-time,
> several/many 1/1 cclock periods could pass before the
> cclocks actually stop.
>
> Per
>
--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 ________________________________________________________________
This archive was generated by hypermail 2b28 : Fri Feb 27 2004 - 08:22:13 PST