==================================================== It looks pretty good to me! Reintroducing `just-in-time' opens up IM18 again. At least I'd like to have a brief discussion about it. The main reason for the proposal is to avoid having to instantiate a superfluous 1/1 ClockPort macro in testbenches that don't use that clock. Hmm, maybe those are not that common? Per =================================================== I've added explantory text for my waveform diagrams as discussed in the last meeting. Recall the decision was to go with diagram 2 to but to add clarification text about what uclock edges "clock enabled" assertions can occur on. I added additional overall explanatory text for the diagram as well. I'm still working on the revisions to the diagram that will illustrate "just-in-time" clock control semantics as well as proposed specification revisions for the same. But in the meantime this text is ready for review. I will forward the Frame doc. to Brian so he can easily incorporate it if all meets with everyone's approval. I've included this text as a text e-mail so we don't have reflector size limit issues. Once I have the modified waveforms, I'll send the .pdf with everything in it. Added text: ------------------------------- snip -------------------------------- Figure X shows an example of clock control for two fast clocks (clkfast, clkfast_negedge) that use don’t care duty cycle semantics and one slow clock (clkslow) that uses a 50/50 duty cycle. clkfast uses posedge active don’t care duty cycle and clkfast_negedge uses negedge active don’t care duty cycle. The effect of the 4 respective clock control signals ready_for_clkfast, ready_for_clkfast_negedge, ready_for_clk_slow, and ready_for_clk_slow_negedge can be seen. Deassertion of ready_for_clkfast prevents subsequent posedges of clkfast, negedges of clkfast_enabled, and all edges of clk_slow from occuring on subsequent posedges of uclock. Once re-asserted, all these edges are allowed to occur on the subsequent uclock posedge. Deassertion of ready_for_clkfast_negedge prevents subsequent posedges of clkfast, negedges of clkfast_enabled, and all edges of clk_slow from occuring on subsequent posedges of uclock. Once re-asserted, all these edges are allowed to occur on the subsequent uclock posedge where relevant. Note, that all of the clock enabled signals, clkfast_enabled, clkfast_negedge_enabled, clkslow_enabled, and clkslow_negedge_enabled are shown to transition on uclock posedges. The implementation can also choose to transition them on negedges. The only hard requirement is that their values can be sampled on the uclock posedge at which the associated controlled clock edge will occur. -- 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 ? ================================================================ > 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. 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. 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. 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 :-) =================================================== I've attached two new diagrams for the IM05 clock forms. In the first diagram (revised_clock_control_1.jpg) it is simply what I had before but with added reference lines so it is easier to see where clocks align around the 'ready_for_clk*' signal transitions. In the second diagram (revised_clock_control_2.jpg), I've implemented Per's request of showing assertions of 'clk*enabled' signals on posedges of uclock rather than negedges to avoid possibly misleading implementors. As it turns out, either is acceptable and compliant. The important thing is that a 'clk*enabled' signal can be sampled properly on the relevant posedge of a uclock. I elaborate on this a bit more in specific responses to Per's e-mail below. Please let me know which of the two you would prefer for the specification. ================================================== Per suggests that the enabled signals could be shown longer in the diagram. There was some discussion. Duaine thinks that the enable signals should be guaranteed valid only on the corresponding edge, with no duration after. Per suggests that we should simplify the clock control with only one control signal per clock, no separate pos-edge and neg-edge. Once the rfcclk is deasserted, on the next rising edge of uclock time is stopped. We need clarification as to what is the difference between that and the emergency break. He want to see justification for separte pe and ne control in the emergency brake model context. AI - Per and John to clarify choices by the next meeting I suppose the action is shared between John and me, but I was waiting for John's response to the 338 email as well as the suggestion about the clock control above. In any event, the contents of 338 and the above ought to be added to the web page. ============================================= I owe you a response to your email from 3 weeks ago about the clock control figure. > My intent here was to show controlled clocks with maximum possible > frequencies with respect to uclock. This is why clkfast and > clkfast_negedge use don't care duty cycle. > > In an optmimal implementation, because these are don't care > duty, it is possible for their inactive edges to coincide > with negedges of uclock which is what I show here. > > The 3rd clock, clkslow, naturally has edges scheduled > on posedges of uclock. I agree with all this. My comment was more directed at the fact that the *_enabled signals are shown as pulses that are half a uclock period wide which could easily confuse people looking at this and make them think they need a (at least) 2X uclock clock to generate these signals. Of course, in an efficient implementation these are not really synchronous signals, but I still think it make sense to show them as signals generated in the uclock domain. This would make clkfast_enabled and clkfast_negedge_enabled show as constant high except during the disabled periods while clkslow_negedge_enabled would have pulses that are 1 uclock period wide. What do you think? > This is indeed a case where negedge cclock control is not > redundant and should probably be kept. I think we ought to have a discussion as to what purpose keeping this serves. The simplest clock control mechanism would be to have one clock control signal that would stop all clocks immediately on the first rising edge of uclock at which this clock control signal is asserted. Given that we have already decided to drop the sliding stop mechanism, why not go all out to the simplest mechanism? This would have the greatest chance of being implemented the same by everybody. > No. In this case, the next edge that you "care" > about (i.e. "non-don't care" edge which is always scheduled on > a uclock posedge) of any clock will be disabled. > That is what emergency brake semantics mean. When a ready > for cclock is deasserted, the next scheduled edge that you > "care" about is disabled. OK, I think I'm finally getting it now. I'm assuming that the implicit 1/1 cclock is also taken into consideration here? That would be an important point that nails any amgiguity in the behavior. > The reason the next posedge of the clkfast_negedge is allowed > to occur in this example is because that is a don't care > edge that does not happen to be scheduled on a uclock posedge. OK. I'm assuming that it is actually up to the implementation whether it lets this don't care edge occur where you drew it or at some later time up until the falling edge of uclock just after ready_for_clkfast_negedge is asserted again. Do you agree? > BTW, a corrolary to don't care duty cycle clock edge control > is that the edge you don't care about is not controllable. > I.e. readyForCclock clkfast_negedge essentially has no effect > as does readyForcclockNegedge on clkfast. If we had only one clock control signal we would not have to describe this fine point. Sub-Issue 5. All other resolved Per, Bojsen, Per wrote: > Hi, > > I know I'm supposed to be on vacation, but I saw the diagram > and noticed a few things that I'd like to comment on before > the issue is closed. > > >>However, we can add the following diagram and text as an example of >>clock control. > > > The figure is good and shows some interesting cases. The > *_enabled signals are showed with their falling edges coinciding > with the falling edge of uclock, i.e., as if they require a > clock with 2X the uclock frequency to be generated if they are > generated synchronously. While I don't think this is in conflict > with the spec I think it is misleading. They ought to be drawn > as signals that are synchronous with uclock and generated by the > rising edge of the uclock. johnS: My intent here was to show controlled clocks with maximum possible frequencies with respect to uclock. This is why clkfast and clkfast_negedge use don't care duty cycle. In an optmimal implementation, because these are don't care duty, it is possible for their inactive edges to coincide with negedges of uclock which is what I show here. The 3rd clock, clkslow, naturally has edges scheduled on posedges of uclock. > > The example showing clock control of clkfast_negedge is > interesting as it shows that negedge clock control has not > become redundant. This was one of the areas where the original johnS: Yes, this is what I was trying to explain in the meeting last Thursday and asked the team to have a look at this proposal before discussing further. This is indeed a case where negedge cclock control is not redundant and should probably be kept. > new wording was ambiguous. The example shows that a rising > edge of clkfast_negedge is allowed to occur before the clock > stops. Since clkfast_negedge is the frequency of uclock this > doesn't quite resolve the ambiguities, though. Here is the > question: If clkfast_negedge had been a 4/1 clock for instance, > and the next falling edge of this clock occurs several uclock > periods later from the point when the ReadyForCclockNegEdge > signal for this clock is asserted, then I'm assuming all clocks > are allowed to run during this period. Specifically, an > active edge of any clock that occurs during this period will > be allowed to occur. Is this a correct interpretation johnS: No. In this case, the next edge that you "care" about (i.e. "non-don't care" edge which is always scheduled on a uclock posedge) of any clock will be disabled. That is what emergency brake semantics mean. When a ready for cclock is deasserted, the next scheduled edge that you "care" about is disabled. The reason the next posedge of the clkfast_negedge is allowed to occur in this example is because that is a don't care edge that does not happen to be scheduled on a uclock posedge. If the clock were any slower, its edges would always be scheduled on uclock posedges and therefore disabled upon deassertion of any readyForClock (or readyForCclockNegEdge). Hope this makes sense. It is, admittedly, a bit tricky. BTW, a corrolary to don't care duty cycle clock edge control is that the edge you don't care about is not controllable. I.e. readyForCclock clkfast_negedge essentially has no effect as does readyForcclockNegedge on clkfast. > > Thanks, > Per Bojsen > Zaiq Technologies > -- johnS 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.] ============================================== > 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. * Point #2: 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. > 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. * Point #3: 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 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.