IM05: Proposed text updates

Hi,

I have enclosed below updated text for IM05 that reflects the
decision to change the clock control mechanism to the `emergency
break' mechanism and summarizes the current status of this issue.

The numbers refer to the original 7 sub-issues that are described
here: http://www.eda.org/itc/open/IM05.txt. Below I include only
the proposals for changes or additions to the text. I've added
status in square brackets. Please review the updated text so that
we can make some progress on resolving this long-standing issue.

1) 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.

[The above has been accepted and incorporated into rev. 1.0.2
of the standard at the location specified (now p. 31)].

2) 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.

[Duaine countered with:]

We propose the following clarification be added to the specification
at the point that Per suggests

  "Every cclock edge must occur on a uclock edge".

All of the other properties follow from this fact and this statement
is clear and concise.

[This counter proposal has not yet been agreed upon. One problem
with this proposal is that it seems a little too restrictive for
the don't care edge of a don't care duty cycle. Presumably when
the user specifies a don't care duty cycle they are saying that
they don't care when the don't care edge of the clock falls so it
shouldn't be necessary to require that edge to coincide with a
uclock edge.]

3) I propose to add the [following] NOTE at the bottom of p. 31.

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.

[Duaine countered with:]

Making the suggested point at that location in the specification
takes away from the topic at that location which is multiclock
alignment. If there needs to be an example, it should be at the
point where uclock and clock relationships are being discussed.

[I am willing to take this one off the table and/or defer it to
an app note on sane clock control or similar tutorial.]

4) 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.

[This change has been accepted and has been incorporated at the
proposed location (now p. 35) in rev. 1.0.2 of the standard.]

5) [Updated text to reflect new `emergency brake' clock control
mechanism. The new text in John's resolution of IM18 in
http://www.eda.org/itc/hm/0241.html. Supercedes my original
change proposal.]

  If this input to one of the SceMiClockControl instances associated
  with a given controlled clock is deasserted, the next posedge of
  all cclocks are immediately disabled. Even in reacting to a
  ReadyForCclock deassertion of a slower clock, the infrastructure
  shall immediately disable not only the next posedge of that slower
  clock, but all posedges of all other faster clocks that occur
  prior to that posedge.

[Current status of sub-issue 5 is that my original rewording was
accepted before we decided to change the clock control mechanism
and the rewording has been incorporated into rev. 1.0.2 of the
standard.

John's proposed text above resolves issues IM18 and the cycle stamp
ambiguity in issue IM15. However, it does not quite address the
issue I originally raised as point 5 which I wanted a clarification
on. This is the fact that once the clocks are stopped then all
edges, not just posedges are disabled. I tried to incorporate
this in John's text above but found it difficult without significantly
obscuring the clarity of the text. I am now thinking that clarifying
my original issue may be better done in a note or an example. I am
thinking that it might be helpful to explain what disabling a clock
edge means in this context.]

6) [This the same as 5 but for ReadyForClockNegEdge. Updated text to
reflect new `emergency brake' clock control mechanism. The new text
in John's resolution of IM18 in http://www.eda.org/itc/hm/0241.html.
Supercedes my original change proposal.]

  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 all cclocks are
  immediately disabled. Even in reacting to a ReadyForCclockNegEdge
  deassertion of a slower clock, the infrastructure shall immediately
  disable not only the next negedge of that slower clock, but all
  negedges of all other faster clocks that occur prior to that
  negedge.

[Current status of sub-issue 5 is that my original rewording was
accepted before we decided to change the clock control mechanism
and the rewording has been incorporated into rev. 1.0.2 of the
standard.

I have the same comments as for point 5 above.]

7) [This issue has been tabled. No changes to the standard is
required for this one.]

Enjoy,
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