Subject: RE: SCE-MI Clock Control: Request for Clarification
From: Bojsen, Per (bojsen@zaiqtech.com)
Date: Thu Jan 29 2004 - 08:02:44 PST
Hi John,
thanks a lot for taking time to answer all these questions.
It relieves me that you confirm my understanding :-)
> What we've seen in general is that posedge control of don't care duty
> cycle clocks is generally adequate for all needs (i.e. the need for
> negedge control is rare) and you can do it with no performance hit
> in uclock:cclock ratios.
Right, our experience confirms this as well.
> johnS:
> CclockedEnabled is, by definition, combinatorially related to the
> ReadyForCclock's. Therefore, combinatorially deriving ReadyForCclock
> from CclockEnabled is generally a bad idea and could result in
> a combinatorial loop.
Ok, lets disregard the combinatorial case. You say CclockEnabled
is related combinatorially to ReadyForCclock (which I agree with).
Then we can conclude that regardless of how ReadyForCclock is
deasserted, if it is deasserted after CclockEnabled is asserted,
it will cause CclockEnabled to deassert again and the controlled
clock to stop right there. If you looked closely enough you
would see a glitch on CclockEnabled, but that would be OK.
Ok, I see no problem here. Thanks for clarifying this.
Per
This archive was generated by hypermail 2b28 : Thu Jan 29 2004 - 08:06:33 PST