Per,
Bojsen, Per wrote:
> Hi John,
>
> > One of the things I outlined below is that I think we want to
> > keep ReadyForCclockNegEdge for the benefit of the fastest clock.
> > Also, if we ever want to restore a "just in time" clock control
> > mode (as alternative to "emergency brake") it will
> > be good to have these signals still there. (See more discussion
> > below.)
>
> Hmm, it doesn't make sense to me to keep something for the benefit
> of a feature we have decided to deprecate in favor of a different
> one just in case we decide to flip-flop on our decision :-) If
> there is a chance we would want to restore `just in time' I would
> think we should think about not getting rid of it in the first
> place or, conversely, we should make sure that the new behavior
> is really what we want so we don't need to go back later.
>
> So the argument for keeping negedge clock control as distinct from
> posedge clock control should be based on features that we decide
> we cannot live without.
johnS:
Yes I agree. This was my coy way of leading into the
fact that I'm having second thoughts about removing just-in-time.
I hate to be obstructionist and I hate to do it "just-in-time"
for Brian's deadline but I am having some concerns here.
Perhaps we can solicit opinions of others.
Happily, reading further below, I see you've been thinking about
this as well.
More below ...
>
> In thinking about my proposal of combining the two ready for
> cclock signals into one versus the `emergency brake' proposal,
> I'm coming to the conclusion that they have identical behavior
> with respect to the clock waveforms in the case where the implicit
> 1/1 cclock has the same frequency as uclock. I'd like to find out
> what if anything I'm overlooking.
>
> Here is why I think they are identical. All cclock edges that
> the user cares about fall on rising edges of uclock. At any given
> time, when a ready for cclock signal (posedge or negedge) is
> deasserted, the earliest time that the clocks will stop will be at
> the next rising edge of uclock because that is the earliest time
> any cclock edge the user cares about can occur. On the other hand,
> the latest time the clocks will stop is also at the next rising
> edge of uclock due to the implicit 1/1 cclock which has an edge
> the user cares about at each rising edge of uclock. So in this
> scenario, no matter which ready for cclock (posedge or negedge)
> is deasserted by the application, the cclocks will always stop at
> the same time, i.e., at the next rising edge of uclock. Similarly,
> I believe the cclocks will always restart at the same time again
> once the ready for cclock signal is asserted again.
>
> Let me know if I am missing something here. But if the above is
> true, then one will get the same behavior with my proposed scheme
> where the ReadyForCclockNegEdge is deprecated although still
> functional, but where it is simply and'ed with the ReadyForCclock
> signal and this combined signal determine clock control. What I
> am saying here certainly applies to the example you sent out.
johnS:
Yeah, I think your arguments are basically right for 1:1
cclock running at same rate as uclock.
But, given this renewed discussion about reinstanting "just in time"
it may be moot except for the specific case of fastest cclock with
1:1 ratio to uclock.
More below ...
>
> Now, when the 1/1 cclock runs slower than uclock, there could be
> a difference between my proposed scheme and yours in that in my
> proposal clocks would still stop at the next rising edge of uclock
> whereas in your scheme they may not if there are no `care' edges
> on the next rising edge of uclock. Is this correct, by the way?
> If this is correct, then we need to see if this difference is
> important or not. Certainly, in terms of cycle stamp time there
> is no difference.
>
> While `just in time' is a bit more complicated to implement and
> possibly a bit harder to comprehend, I do see the advantages of
> this scheme over the `stop now' or `emergency brake' mechanism.
> As I recall it, the only reason for introducing `emergency brake'
> was the ambiguity in cycle stamps on output messages in certain
> scenarios. If we could fix this, then I wouldn't mind retaining
> the `just in time' mechanism.
>
> Interestingly enough, one can get `emergency brake' semantics in
> a `just in time' system by controlling a 1/1 cclock instead of
> whatever clock the transactor uses. BTW, this was the motivation
> for my proposal to reserve clock ID 0 for the implicit 1/1 cclock.
>
johnS:
Per, now I don't feel so bad about my 11 th hour 2nd thoughts.
You've framed this argument quite nicely and in fact, your point
about being able to easily get "emegency brake" semantics from
"just in time" but not vice versa is excellent.
> In summary, I think my immediate stop proposal is (almost) identical
> to your `emergency brake' proposal except for the status of
> ReadyForCclockNegEdge. Of course, I may be wrong on one or more
> subtle points :-)
johnS:
How about you and I jointly and quickly make a proposal to
re-instate "just in time" but solve the cyclestamp issue and
still meet Brian's deadline ?
-- johnS
<eom>
>
> 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 ________________________________________________________________Received on Wed Nov 10 10:30:21 2004
This archive was generated by hypermail 2.1.8 : Wed Nov 10 2004 - 10:30:29 PST