Subject: SCE-MI Clock Control: Request for Clarification
From: Bojsen, Per (bojsen@zaiqtech.com)
Date: Fri Dec 12 2003 - 18:05:41 PST
Hi,
this was originally sent to Brian and Duaine and Brian asked me to
forward it to the mailing list. Hopefully the list is up now.
I would like to have my understanding of certain aspects of SCE-MI
clock control confirmed. Please correct anything in the following
that you find is wrong:
1) On p. 34 in the section describing parameters and IOs of the
SceMiClockControl macro under the description of the
ReadyForClock and ReadyForClockNegEdge it is stated that the
corresponding edge of the controlled clock must coincide with
a rising edge of uclock. It is also stated that for don't
care duty cycle cclocks, the ReadyFor* signal corresponding to the
edge the user does not care about is constant 0.
So, it follows, that any cclock with non-don't care duty cycle,
both its edges must coincide with a rising edge of uclock. This
implies that the highest possible frequency of a 1/1 cclock with
a non-don't care duty cycle (e.g., 50/50) is 1/2 the uclock
frequency, right?
However, if the duty cycle is don't care, then the frequency can
be the same as the uclock frequency in the best case? This is
stated as a goal (but not a requirement) on p. 28 in the last line
of the 4th paragraph from the bottom.
2) The actual frequency of the 1/1 cclock relative to uclock is
implementation defined, right? As long as the SCE-MI requirements
are fulfilled, of course. The SCE-MI requirements define a
maximum possible frequency but an implementation may choose a
lower frequency if it wants to, right?
3) In Figure 13 on p. 32, the 1/1 cclock frequency is 1/2 the uclock
frequency. The 1/1 cclock is not shown. It would be nice to
show it in the figure as well, especially since it contrasts the
goal on p. 28. A note explaining why the 1/1 cclock in this
example must be slowed down would also be nice (and there is
actually room on the page to do so :-) Here is a proposal for
the text of such a note:
NOTE--The 1/1 cclock in Figure 13 has a frequency that is 1/2
the frequency of uclock. This is a consequence of the duty
cycle and phase requirements of cclocks cclock2 through cclock5
and the SCE-MI requirement that both edges of a cclock with
a non-don't care duty cycle must coincide with some rising
edge of uclock.
4) On p. 34, the second paragraph under ReadyForCclockNegEdge tries
to motivate the need for the capability to disable negative
edges. However I am unable to decipher what the first sentence
of this paragraph is saying :-) How is it that transactor logic
that only cares about controlling posedge clocks could or could
not inadvertently disable the next negedge of any clock when it
only intends to disable the next posedge of a clock? And how
does this motivate the need for explicit negedge control?
Why not simply state that negedge control is provided for
transactors that use the negedge as the active edge of some
clock (or both edges)? I am wondering if I am missing something
here.
5) Also on p. 34, it is stated that ReadyForCclock disables the
positive edge of the cclock being controlled, but not only that,
it also disables the *posedge* of all other cclocks "just in time".
So far so good. But why only the *posedges* of the other cclocks?
Will it not stop all cclocks right before the edge of the cclock
being controlled would have occurred? Won't that disable the
negedge of any cclock whose next edge is a negedge? Perhaps
my confusion is due to equating `disabling of edges' with stopping
the cclocks?
6) This is the same as 5 but for ReadyForCclockNegEdge.
7) This is a subtle issue. If ReadyForClock is deasserted after
CclockEnabled is asserted, e.g., through a combinatorial mechanism,
then will the cclock have the next rising edge disabled (forcing
CclockEnabled to deassert again since the edge is now to be
disabled) or will the cclock have the rising edge *following* the
next rising edge disabled?
I think that's it for now regarding clock control.
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 archive was generated by hypermail 2b28 : Mon Jan 05 2004 - 07:32:14 PST