Subject: RE: SCE-MI Clock Control: Request for Clarification
From: Bojsen, Per (bojsen@zaiqtech.com)
Date: Thu Feb 05 2004 - 17:15:39 PST
Hi,
I had the action from the last ITC meeting to turn my clock
control questions into proposals for changes to the SCE-MI
standard text. I have embedded the proposals below.
Everything prefixed with `>' is the original text of my
request for clarification email which I have kept for
context.
> 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.
I propose adding a NOTE with the following text to p. 30 at the
end of Section 5.1.4.3 Don't care duty cycle:
NOTE---The intent of the don't care duty cycle is to relax the
requirement that each edge of a controlled clock must coincide
with a rising edge of uclock. A controlled clock with a posedge
active don't care duty cycle, i.e., with DutyHi given as 0, is
not required to have its falling edge coincide with a rising
edge of uclock. Similarly, a controlled clock with a negedge
active don't care duty cycle, i.e., with DutyLo given as 0, is
not required to have its rising edge coincide with a rising
edge of uclock. Hence, the don't care duty cycle enables
controlled clocks to be the same frequency of the uclock.
Conversely, the maximum possible frequency of a non-don't care
duty cycle controlled clock is 1/2 the frequency of the uclock.
Since the implicit 1/1 controlled clock is specified to have
posedge active don't care duty cycle, it may be as fast as
uclock.
> 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?
I propose adding a NOTE with the following text to p. 28 after
the fourth paragraph from the bottom:
NOTE---Only a lower bound on the frequency of uclock is specified.
This lower bound is the frequency of a 1/1 controlled clock. The frequency
of uclock is constrained by the requirement that every
rising edge of the 1/1 controlled clock must coincide with a rising
edge of uclock. This implies that implementation is allowed to
set the uclock frequency to any positive integer multiple of the frequency
of a 1/1 controlled clock, i.e., it is allowed to be faster.
> 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.
I propose to add the above NOTE at the bottom of p. 31.
> 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.
I propose to change the third paragraph from the bottom of p. 34 to:
Support for explicit negedge control is needed for transactors
that use the negedge of a controlled clock as the active edge.
Transactors that do not care about controlling negedges (such
as the one shown in Figure A.1) need to tie this signal high.
> 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?
I propose to change the fourth paragraph from the top of p. 34 to:
If this input to one of the SceMiClockControl instances associated
with a given controlled clock is deasserted, the next posedge of
that cclock is disabled. In reacting to a ReadyForCclock of a slower
clock, the infrastructure shall not prematurely disable any edges of
other faster clocks that occur prior to the last possible uclock
preceding the edge to be disabled. In other words, that edge is
disabled "just in time" to allow faster clock activity to proceed
until the last moment possible. Once the edge is finally disabled,
all edges of all controlled clocks are also disabled.
These changes are subtle but involve clarifying that *all* edges
are disabled, not just posedges.
> 6) This is the same as 5 but for ReadyForCclockNegEdge.
I propose to change the 7th paragraph from the top (4th paragraph
from the bottom) of p. 34 to:
Similarly, for negedge control, if this input to one of the
SceMiClockControl instances associated with a given controlled
clock is deasserted, the next negedge of that clock shall be
disabled. In reacting to a ReadyForCclockNegEdge of a slower
clock, the infrastructure shall not prematurely disable any edges
of other faster clocks that occur prior to the last possible
uclock preceding the edge to be disabled. In other words, that
edge is disabled "just in time" to allow faster clock activity
to proceed until the last moment possible. Once the edge is
finally disabled, all edges of all controlled clocks are also
disabled.
These changes are subtle but involve clarifying that *all* edges
are disabled, not just negedges.
> 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?
No change needed for this one. I have tabled the issue.
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 : Thu Feb 05 2004 - 17:19:35 PST