Abstract:
A system and a method are provided for implementing a power-saving sleep mode in a synchronous circuit core having multiple clock domains including primary and secondary clock domains. The primary clock domain has states of awake, asleep, doze, and waking. The doze and waking states are transient states between the awake and asleep states. One or more secondary clock domains each have states of secondary awake and secondary asleep. The doze and waking states are used to eliminate race conditions between the primary and secondary clock domains. If the core has two or more secondary clock domains, the secondary clock domains each have an additional state of sleep-pending. The sleep-pending state is a transient state between the secondary awake and secondary asleep states. One or more synchronization logics are coupled between the primary and secondary clock domains.

Description:
BACKGROUND OF THE INVENTION  
         [0001]    1. Field of the Invention  
           [0002]    The invention relates generally to a power-saving technique in a digital circuit and, more particularly, to a power-saving technique in a synchronous digital core design having multiple clock domains.  
           [0003]    2. Description of the Related Art  
           [0004]    Many modern synchronous circuits or system designs implement a mode called a “sleep mode,” which is a power-saving mode that the designs enter when they are essentially idle. Sleep mode is becoming increasingly common in “System On a Chip” (SOC) designs. SOCs are so named because they typically have one or more processors, one or more memory interfaces, and interfaces to various Input/Output (I/O) busses all on the same chip. SOCs are usually created out of “core” designs that are “stitched” together to make the SOC. For example, an SOC may have a plurality of cores such as a processor core, a memory core, an Ethernet core, a PCI core, serial port core, etc. Due to the large amount of functions on the single chip, power conservation is important. Also, because there are many different functions on a single chip, much of the time one or more of the individual core functions will be idle.  
           [0005]    When a core is “idle” and is therefore not processing any transactions, many of that core&#39;s latches are still consuming power because they are still being clocked. Some of these latches may feed downstream combinational logic causing those combinational gates to switch and also consume power needlessly. The solution has been for the core to go into sleep mode when it has been idle for some programmable amount of time. While a core is in sleep mode, the clocks to all or most of its latches are gated off so that the core consumes almost no power. A core may decide on its own to enter sleep mode, but typically it makes a request to the SOC to go to sleep via a signal called SLEEP_REQ. If the SOC supports sleep mode and that mode is enabled for the particular core, the system will return a SLEEP_ACK signal to the core. The SLEEP_ACK signal (or sometimes a negative active SLEEP_N signal) has traditionally been used by the core to directly gate the clocks inside the core. If the SOC never activates the SLEEP_ACK signal in response to a SLEEP_REQ, then the core will not enter sleep mode. Because there is often a performance penalty for “waking up” from sleep mode, cores typically have programmable counters that make them wait to assert SLEEP_REQ only if they have been idle for some reasonable programmable time.  
           [0006]    Once a core is in sleep mode, it will “wake up” when it determines that it is no longer idle. The conditions that cause a core to wake up are specific to each design but they are typically things like a bus transaction whose destination is that core, or an interrupt arriving, etc. When the core detects a wake up event, it will deassert SLEEP_REQ and the SOC will in turn deassert SLEEP_ACK. The clocks will start running again and the core can process the wake up event. While in sleep mode, the core design must take care not to gate the clocks of any part of the design that needs to detect wake-up conditions or any part of the design that must respond to stimulus while the core is in sleep mode. For example, a decode logic cannot typically be gated. Also, the core may have to be able to retry transactions that are destined for it while it is asserting the SLEEP_REQ signal and after it deasserts the SLEEP_REQ signal but before the SLEEP_ACK signal deactivates taking it out of sleep mode.  
           [0007]    Cores with single clock domains can switch in and out of sleep mode without difficulty. Implementing sleep mode becomes more complex when a core has multiple clock domains. In this case, the process must be carefully controlled so that going to sleep mode is a process that must complete in all clock domains before the wake-up process can begin. One of the clock domains in a multiple clock domain core is the one that is asserting the SLEEP_REQ to the SOC and is receiving the SLEEP_ACK signal back. This clock domain is called a primary clock domain, whereas the other clock domain(s) are called secondary clock domains. There are several different architectures where implementing sleep mode becomes problematic.  
           [0008]    There is a first case where only the primary clock domain receives a wake-up event, i.e., there are no wake-up events that can come from secondary clock domain(s). This first case, for example, includes a one-way I/O core such as a PCI, which takes transactions from a local bus running off of a local clock and runs those transactions on the PCI bus using a PCI clock. In this example, the local bus is in the primary clock domain, whereas the PCI bus is in the secondary clock domain. The primary clock domain decides when to sleep and when to wake up.  
           [0009]    The first problem faced is that the SLEEP_ACK signal is a primary clock domain signal and must be synchronized to the secondary domains before being able to be used there. But just synchronizing the SLEEP_ACK signal to the secondary domains and using the synchronized versions to gate the clocks in those domains creates many race conditions and problems. When SLEEP_ACK is deasserted in the primary clock domain, it may still be asserted in one or more secondary clock domains. Thus, the primary clock domain cannot look only at its own SLEEP_ACK to know when it can safely communicate with the secondary clock domains.  
           [0010]    At first glance, the simple solution to this problem is to feed the synchronized SLEEP_ACK back from the secondary clock domains (synchronized again) to the primary clock domain so that the primary clock domain can “see” when the secondary clock domains are really awake. So when the primary clock domain sees its own SLEEP_ACK deasserted, it simply waits until all of the other domains also have an inactive SLEEP_ACK. However, there are race conditions that cause this solution not to work. If the SLEEP_REQ is permitted to assert for a brief period of time (e.g., a small number of primary clocks) and then quickly deassert due to a wake-up event, the SLEEP_ACK signal could be asserted for a short period of time.  
           [0011]    This is problematic when it is sent to other clock domains. The primary clock domain may see its own SLEEP_ACK assert and then deassert before the synchronized versions of the secondary SLEEP_ACK signals have gotten a chance to ever assert in the primary domain. This way, the primary domain will see those domains as being awake just because the SLEEP_ACK pulse has not gotten through the synchronization logic and back yet. This may cause the primary clock domain to start talking to a secondary clock domain just as it is briefly going to sleep. Some SLEEP_ACK pulses may be so short in the primary clock domain that they do not even show up in a secondary domain. Even if they do show up, their synchronized version back to the primary clock domain may not show up. This fact prevents the primary clock domain from even waiting for the secondary clock domains to assert and then deassert their synchronized version of SLEEP_ACK signals.  
           [0012]    Furthermore, there are more difficult and general situations where there are not only multiple clock domains but idle and wake-up events can happen from more than one clock domain. A two clock domain example of this situation could be a PCI bridge that forwards transactions in two directions: (1) from the local bus to PCI and (2) from PCI to the local bus. Each side of the bridge operates on a different clock. When such a bridge core is in a sleep mode, a transaction arriving from either side of the bridge should cause the core to wake up.  
           [0013]    Making this scenario work is not straightforward due to the race conditions discussed above as well as other race conditions that arise due to the fact that both sides can now initiate wake-up events. An example of one of these other race conditions is as follows: Assume that the local side is the primary clock domain, which means that SLEEP_REQ is asserted in that domain and that SLEEP_ACK is received in that domain. In this case, the primary clock domain can decide to assert SLEEP_REQ because it believes that the primary and secondary clock domains have both been idle for some time. But any information that the primary clock domain has about the secondary clock domain is delayed due to the synchronization interface. Therefore, the secondary clock domain may actually have gone non-idle due to a transaction arriving around the time that the primary clock domain asserts SLEEP_REQ. This will cause the SLEEP_ACK signal to arrive and put the core to sleep right in the middle of processing a transaction. There are other race conditions involved in waking up. If the secondary clock domain detects a transaction destined for the core, it will wake up and deassert its IDLE signal. That IDLE signal will cross the synchronization logic and eventually cause the core to deassert SLEEP_REQ and SLEEP_ACK will deassert. The secondary clock domain cannot start talking to the primary clock domain as soon as it deasserts its idle signal. Likewise, the primary clock domain cannot start talking to the secondary clock domain as soon as it sees SLEEP_ACK deassert. All of these race conditions occur because different clock domains are making decisions based on information, some of which is current and some of which is not current due to the synchronization delay.  
           [0014]    Therefore, a need exists for implementing a power-saving sleep mode in a synchronous design having multiple clock domains without the aforementioned problems including various race conditions.  
         SUMMARY OF THE INVENTION  
         [0015]    The present invention provides a system and a method for implementing a power-saving sleep mode in a synchronous circuit core. The synchronous circuit core includes a sleep controller, a primary clock domain coupled to the sleep controller, one or more secondary clock domains, and one or more synchronization logics coupled between the primary and secondary clock domains. The primary clock domain has a primary-side idle timer and states of awake, asleep, doze, and waking. The doze and waking states are transient states between the awake and asleep states. The one or more secondary clock domains each have a secondary-side idle timer and states of secondary awake and secondary asleep. The doze and waking states are used to eliminate race conditions between the primary and secondary clock domains. If the core has two or more secondary clock domains, the secondary clock domains each have an additional state of sleep-pending. The sleep-pending state is a transient state between the secondary awake and secondary asleep states. The one or more synchronization logics are coupled between the primary and secondary clock domains. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0016]    For a more complete understanding of the present invention and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:  
         [0017]    [0017]FIG. 1 is a block diagram illustrating a synchronous design core having multiple clock domains;  
         [0018]    [0018]FIG. 2 is a state diagram illustrating the operation of a primary clock domain of FIG. 1;  
         [0019]    [0019]FIG. 3 is a state diagram illustrating the operation of a secondary clock domain of FIG. 1 when there is only one secondary clock domain; and  
         [0020]    [0020]FIG. 4 is a state diagram illustrating the operation of a secondary clock domain of FIG. 1 when there are two or more secondary clock domains. 
     
    
     DETAILED DESCRIPTION  
       [0021]    In the following discussion, numerous specific details are set forth to provide a thorough understanding of the present invention. However, it will be apparent to those skilled in the art that the present invention may be practiced without such specific details. In other instances, well-known elements have been illustrated in schematic or block diagram form in order not to obscure the present invention in unnecessary detail.  
         [0022]    It is further noted that, unless indicated otherwise, all functions described herein may be performed in either hardware or software, or some combination thereof. In a preferred embodiment, however, the functions are performed by integrated circuits that are coded to perform such functions, unless indicated otherwise.  
         [0023]    Referring to FIG. 1 of the drawings, the reference numeral  100  generally designates a synchronous digital system. A core  102  generally represents any one core of many cores in the synchronous digital system. The core  102  comprises a sleep controller  104 , a primary clock domain  106  having a primary-side idle timer  108 , a synchronization logic (SYNC)  110 , and a secondary clock domain  112  having a secondary-side idle timer  114 . Note that, for the sake of simplicity, the core  102  shows only one secondary clock domains  112 . Note that the core  102  can be any type of synchronous core including a process core, a memory core, a PCI core, etc.  
         [0024]    The primary-side idle timer  108  receives signals from both the primary and secondary clock domains  106  and  112  in order to determine whether both the domains  106  and  112  have been idle for a programmable period of time. Preferably, the primary-side and secondary-side idle timers  108  and  114  are implemented with counters. In that case, such counters determine whether both the domains  106  and  112  have been idle for a programmable number of clocks.  
         [0025]    The sleep controller  104  is coupled to the primary clock domain  106  for receiving a SLEEP_REQ signal from the primary clock domain  106  and sending a SLEEP_ACK signal via a connection  120  to the primary clock domain  106 . The primary clock domain  106  is coupled to the secondary clock domain  112  through the SYNC  110 . The primary clock domain  106  and the secondary clock domain  112  contain the primary-side and secondary-side idle timers  108  and  114 , respectively. Typically, the secondary-side idle timer  114  is at least an order of magnitude smaller than the primary-side idle timer  108 . The primary clock domain  106  receives a SLEEP_ACK signal via a connection  122  from the sleep controller  104  and sends it to the secondary clock domain  112  through the SYNC  110 . The primary clock domain  106  sends the SLEEP_ACK signal to the SYNC  110  via a connection  124 . The SYNC  110  synchronizes the SLEEP_ACK signal to the secondary clock domain  112 . The version of SLEEP_ACK synchronized to the secondary clock domain is called SLEEP_ACK_SEC. The SYNC  110  sends the SLEEP_ACK_SEC signal to the secondary clock domain  112  via a connection  126 .  
         [0026]    The secondary clock domain  112  sends SEC_AWAKE, SEC_ASLEEP, or SEC_IDLE signal via a connection  128  depending on the situation in which the secondary clock domain  112  is. The SEC_AWAKE signal indicates that the secondary clock domain  112  is in an AWAKE state. The SEC_ASLEEP signal indicates that the secondary clock domain  112  is in an ASLEEP state. The SEC_IDLE signal indicates that the secondary clock domain  112  is idle. The SYNC  110  synchronizes these signals to the primary clock domain and generates SEC_AWAKE_SYNC, SEC_ASLEEP_SYNC, and SEC_IDLE_SYNC signals. Any one of these signals will be transmitted via a connection  130 .  
         [0027]    The secondary-side idle timer  114  is used to cover the largest possible round trip synchronization delay from the secondary clock domain to the primary clock domain and back. In order words, the secondary-side idle timer  114  ensures that the secondary clock domain  112  has been idle for long enough so that there are not newly arrived transactions into the secondary clock domain that are not being taken into account in the primary clock domain  106  due to the synchronization delay. The relative size of the secondary-side idle timer  114  to that of the primary-side idle timer  108  depends on the relative clock frequencies between the primary and secondary clock domains.  
         [0028]    Now referring to FIG. 2, a state diagram  200  illustrates the operation of a primary clock domain of FIG. 1. Note that the state diagram  200  describes the operation of the primary clock domain interacting with a single secondary clock domain. However, this is compatible with, and applicable to, the general case (as shown in FIG. 1) of the primary clock domain interacting with two or more secondary clock domains in a single core. This is shown below in relation to FIG. 4.  
         [0029]    The state diagram  200  generally comprises four states: AWAKE  202 , ASLEEP  204 , DOZE  206 , and WAKING  208 . The primary clock domain therefore is put in any one of these four states at a given point in time. The primary clock domain cannot transition from the AWAKE state  202  to the ASLEEP state  204  without going through the DOZE state  206 . Likewise, the primary clock domain cannot transition from the ASLEEP state  204  to the AWAKE state  202  without going through the WAKING state  208 . In the DOZE state  206 , the primary clock domain can transition either to the ASLEEP state  204  or back to the AWAKE state  202 .  
         [0030]    As shown in FIG. 1, the primary clock domain contains an idle timer for detecting when the core has been idle for the programmable number of clocks. Such an idle timer receives an IDLE signal from both the primary and secondary clock domains. Inevitably, therefore, the IDLE signal from the secondary clock domain is delayed relative to its state in the secondary clock domain. When the primary clock domain determines that the core has been idle for the programmable number of clocks, it asserts a SLEEP_REQ signal. If the core goes non-idle (as seen in the primary clock domain) before the SLEEP_ACK signal has arrived, the core will deassert the SLEEP_REQ signal. If SLEEP_ACK arrives while SLEEP_REQ is deasserted, it will be ignored (i.e., it will deassert shortly). When the SLEEP_ACK signal asserts and the SLEEP_REQ signal is still asserted, the primary clock domain transitions to the DOZE state  206 .  
         [0031]    In the DOZE state  206 , the core may or may not enter a sleep mode (i.e., may or may not transition to the ASLEEP state  204 ) depending on the answer from the secondary clock domain. While in the DOZE state  206 , the primary clock domain will simply hold off any wake-up events via “retries” or “wait states” or any other suitable means. It is vital to keep the primary clock domain idle while waiting to see if the secondary clock domain is still idle. Clocks are enabled (i.e., not gated) in the DOZE state  206 . After entering the DOZE state  206 , the primary clock domain simply waits for an indication from the secondary clock domain. While in the DOZE state  206 , the primary clock domain will not go to the AWAKE state  202  in response to primary clock domain wake-up events. The primary clock domain will not deassert SLEEP_REQ in response to wake up events (i.e., in response to the primary-side idle timer becoming not expired). In other words, while in the DOZE state  206 , the primary clock domain stays in the DOZE state  206  until it gets an indication from the secondary clock domain. In short, the primary clock domain has no say at this point, because decision control has been passed to the secondary clock domain in the DOZE state  206 . It is the secondary clock domain that decides whether the core should enter sleep mode or not.  
         [0032]    The equation for the SLEEP_REQ signal in Verilog™ hardware description language (HDL) is as follows: 
         SLEEP_REQ =AWAKE &amp; IDLE_TIMER_EXPIRED|DOZE|ASLEEP 
         [0033]    (Verilog™ HDL is a well-known hardware description language used to design and document electronic systems. Verilog™ HDL allows designers to design at various levels of abstraction.) This equation indicates that the primary clock domain asserts the SLEEP_REQ signal when (1) the primary clock domain is in the AWAKE state  202  and the idle timer in the primary clock domain has expired; or (2) the primary clock domain is in the DOZE state  206 ; or (3) the primary clock domain is in the ASLEEP state  204 . Therefore, nothing will cause SLEEP_REQ to deassert while the primary clock domain is in the DOZE state  206  or the ASLEEP state  204 .  
         [0034]    In FIG. 3, a state diagram  300  illustrates the operation of a secondary clock domain of FIG. 1 when there is only one secondary clock domain. The state diagram  300  generally comprises two states: AWAKE  302  and ASLEEP  304 .  
         [0035]    As shown in FIG. 1, the secondary clock domain has a small idle timer (e.g., the secondary-side idle timer  114 ) of its own just to cover the largest possible round trip synchronization delay from the secondary clock domain to the primary clock domain and back. The SLEEP_ACK signal is sent to the secondary clock domain through the synchronization logic (e.g., SYNC  110 ). When the SLEEP_ACK_SEC signal (i.e., the version of SLEEP_ACK synchronized to the secondary clock domain) arrives asserted in the secondary clock domain, the secondary clock domain either goes to the ASLEEP state  304  or remains in the AWAKE state  302  depending on whether the secondary-side idle timer (e.g., the secondary-side idle timer  114  of FIG. 1) indicates that the secondary clock domain has been idle for the required number of clocks. The secondary-side idle timer ensures that, after the primary clock domain asserted SLEEP_REQ, the secondary clock domain did not go non-idle for a brief period of time (and possibly queued a transaction over to the primary clock domain or initiated a transaction) and then become idle by the time SLEEP_ACK_SEC arrives in the secondary clock domain.  
         [0036]    The primary clock domain asserted SLEEP_REQ because it saw that the secondary clock domain has been idle. The secondary clock domain idle timer (e.g., the secondary-side idle timer  114 ) ensures that the secondary clock domain has been idle continuously since the primary clock domain received SLEEP_ACK (with SLEEP_REQ asserted) and the secondary clock domain received an active SLEEP_ACK_SEC signal. If the secondary clock domain idle timer is still expired when the SLEEP_ACK signal arrives in the secondary clock domain, the secondary clock domain transitions to the ASLEEP state  304  and sends a pulse indication to the primary clock domain called SEC_ASLEEP. SEC_ASLEEP indicates that the core is going to sleep. (Note that there is a standard synchronization circuit called a mailbox, which guarantees that a single clock pulse sent from one clock domain is received as a single clock pulse in another clock domain regardless of the relative frequencies and phases of the two clocks. The details of this circuit are outside the scope of the present invention, and therefore will not be explained herein.)  
         [0037]    The indication that the core is going to sleep causes the primary clock domain to transition from the DOZE state  206  to the ASLEEP state  204  and now both domains are in the ASLEEP state (i.e., both  204  and  304 ). Clocks are disabled (gated) in the primary clock domain when the primary clock domain is in the ASLEEP state  204 . Similarly, clocks are disabled (gated) in the secondary clock domain when the secondary clock domain is in the ASLEEP state  304 . Once the primary clock domain is in the ASLEEP state  204 , it is certain that the secondary clock domain is also in the ASLEEP state  304 . If, on the other hand, when the SLEEP_ACK_SEC signal arrives in the secondary domain, the secondary clock domain idle timer is no longer expired—indicating that a transaction has arrived to the secondary clock domain while the SLEEP_ACK signal was on its way from the primary clock domain—the secondary clock domain will stay in the AWAKE state  304  and send an indication to the primary clock domain called SEC_AWAKE. That indication (i.e., SEC_AWAKE) causes the primary clock domain to transition from the DOZE state  206  to the AWAKE state  202 . In that case, the core never enters sleep mode, and no clocks were ever gated.  
         [0038]    Once the primary clock domain goes to the AWAKE state  202 , it will deassert SLEEP_REQ. The primary-side idle timer will no longer be expired, because the same condition that caused the SEC_AWAKE indication will also reset the primary-side idle timer. The deassertion of SLEEP_REQ will cause SLEEP_ACK to deassert and eventually cause SLEEP_ACK_SEC to deassert. Note that the secondary clock domain idle timer (e.g., the secondary-side idle timer  114  of FIG. 1) cannot be permitted to expire while SLEEP_ACK_SEC is asserted (i.e., it must be held in its maximum value) to prevent the secondary clock domain state machine from transitioning from the AWAKE state  302  to the ASLEEP state  304  after the secondary clock domain has already indicated SEC_AWAKE due to the subsequent expiration of that secondary-side idle timer.  
         [0039]    Once the core is asleep, it can be woken up by wake-up events on either clock domain. Waking up, as going to sleep, is also carefully controlled to avoid race conditions and inconsistencies. The secondary clock domain state machine will not exit the ASLEEP state  304  until SLEEP_ACK_SEC is removed. It will forward, however, non-idle indications (due to incoming traffic) up to the primary clock domain as usual so that the primary clock domain can initiate the wake-up sequence. While the secondary clock domain is in the ASLEEP state  304 , it retries or otherwise holds off the incoming traffic.  
         [0040]    In the first case where wake-up events are initiated by the secondary clock domain by deasserting the secondary clock domain idle indication due to incoming traffic to that domain, the primary clock domain will (after the synchronization delay) see that the secondary clock domain is no longer idle and transition to the WAKING state. In the WAKING state, SLEEP_REQ is deasserted, and clocks on the primary clock domain are re-enabled. Incoming traffic to the primary clock domain is, however, still retried or otherwise held off because it is not certain that traffic can be handled by the secondary clock domain. SLEEP_ACK will immediately or eventually deassert in response to the deassertion of SLEEP_REQ. The deassertion of SLEEP_ACK will eventually be seen by the secondary clock domain as the deassertion of SLEEP_ACK_SEC. When the secondary clock domain sees SLEEP_ACK_SEC deassert, it transitions from the ASLEEP state  304  to the AWAKE state  302 , thereby enabling the clocks of the secondary clock domain. The secondary clock domain can now process incoming transactions. The secondary clock domain knows that the primary clock domain can handle the transactions because the primary clock domain is in the WAKING  208  or AWAKE  202  state when SLEEP_ACK_SEC is deasserted so its clocks are enabled.  
         [0041]    The primary clock domain waits for a signal called SLEEP_ACK_SEC_SYNC to deassert before it exits from the WAKING state  208  to the AWAKE state  202 . SLEEP_ACK_SEC_SYNC is the SLEEP_ACK_SEC signal synchronized to the primary clock domain. This handshake prevents the primary clock domain from sending traffic to the secondary clock domain before it is certain that the clocks are enabled there. This mechanism does not have short pulse race conditions seen in prior art configurations, because the primary clock domain will never be looking for SLEEP_ACK_SEC_SYNC to be deasserted except in cases where it is already asserted.  
         [0042]    In the second case where the wake-up events occur in the primary clock domain, the primary clock domain transitions to the WAKING state  208 . This deasserts SLEEP_REQ, and the deassertion of SLEEP_REQ causes the deassertion of SLEEP_ACK. Eventually, SLEEP_ACK_SEC deasserts and takes the secondary clock domain to the AWAKE state  302  and then eventually SLEEP_ACK_SEC_SYNC deasserts in the primary clock domain. The deassertion of SLEEP_ACK_SEC_SYNC causes the primary clock domain to transition to the AWAKE state  202 .  
         [0043]    In a special implementation of this second case, the secondary clock domain is basically a slave to the primary clock domain and thus does not initiate wake-up events. In this case, the primary clock domain goes to the DOZE state  206  when it has asserted SLEEP_REQ and simply waits for the SLEEP_ACK_SEC_SYNC to arrive asserted in the primary clock domain before going to the ASLEEP state  204 . This prevents the short pulses on the SLEEP_ACK and SLEEP_ACK_SEC signals that cause race conditions. There is no need for the SEC_ASLEEP and the SEC_AWAKE indications. Then when the primary clock signal detects a wake-up event, it goes to the WAKING state until the SLEEP_ACK_SEC_SYNC deasserts. Accordingly, going to sleep and waking up is staged and controlled so no race conditions occur.  
         [0044]    In FIG. 4, a state diagram  400  illustrates the operation of a secondary clock domain of FIG. 1 when there are two or more secondary clock domains. The state diagram  400  generally comprises three states: AWAKE  402 , ASLEEP  404 , and SLEEP_PENDING  406 . As mentioned above, the state diagram  400  illustrates the very general case where there are multiple secondary clock domains, some or all of which can initiate wake-up events.  
         [0045]    Upon detecting that the core has been idle for some time, the primary clock domain asserts SLEEP_REQ and goes to the DOZE state  206  when the SLEEP_ACK signal arrives as before. But now, the core cannot enter the sleep mode until all of the secondary domains indicate that they can go to sleep. The secondary clock domain state machine needs the additional state SLEEP_PENDING  406 . Secondary clock domain n goes to the SLEEP_PENDING state  406  when the SLEEP_ACK_SEC[n] signal asserts and the secondary idle timer in that secondary clock domain has expired, where n indicates the number of the secondary domain. Upon the arrival of the SLEEP_ACK_SEC[n] signal, it is requested of each secondary clock domain that, since the core has requested to go to the sleep mode, each secondary clock domain sends the SEC_ASLEEP[n] signal, if its secondary-side idle timer has expired. SEC_ASLEEP[n] indicates that the corresponding secondary clock domain is in the SLEEP_PENDING state  406  and is able to go to the ASLEEP state  404  (not that it has gone to the ASLEEP state already). Additionally, upon arrival of the SLEEP_ACK_SEC[n], it is requested that, if its secondary-side idle timer has not expired, each secondary clock domain send the SEC_AWAKE[n] signal and remain in the SLEEP_AWAKE state  402  until the SLEEP_ACK_SEC[n] signal deasserts. The secondary clock domain N idle timer must be disabled from expiring when SLEEP_ACK_SEC[n] is active to prevent a later transition to the SLEEP_PENDING state  406  after the SEC_AWAKE[n] indication has been given.  
         [0046]    Clocks are enabled in the SLEEP_PENDING state  406 . If a secondary clock domain sent the SEC_ASLEEP[n] indication, it must retry or otherwise block incoming traffic while in the SLEEP_PENDING state  406  so that it will be guaranteed to still be idle if the primary clock decides to put the core to sleep. If a secondary clock domain sent the SEC_AWAKE[n] indication, then it has begun processing something already so it remains in the AWAKE state and just continues to process the traffic. There is no concern that the core will be put to sleep in the middle of processing this traffic, because the primary clock domain will see the SEC_AWAKE[n] signal and will cancel the sleep sequence, which has not yet gated any clocks. The primary clock domain gathers all of the responses (i.e., votes) from all of the secondary clock domains that can initiate wake-up events via their IDLE signals. If all of them have sent the SEC_ASLEEP indication, then the primary clock domain transitions to the ASLEEP state  204  and sends a broadcast CORE_ASLEEP indication back to the secondary domains. When they receive that signal synchronized to their respective domains (CORE_ASLEEP_SEC[n]), they transition from the SLEEP_PENDING state  406  to the ASLEEP state  404 .  
         [0047]    If, however, one or more of the secondary clock domains sent the SEC_AWAKE signal (meaning that their respective secondary clock domain idle timer is no longer expired), then the primary clock domain enters the WAKING state  208  and deasserts the SLEEP_REQ. This will cause the SLEEP_ACK to deassert. When the SLEEP_ACK_SEC[n] signal deasserts to each secondary clock domain, those domains that are in the SLEEP_PENDING state  406  will transition from the SLEEP_PENDING  406  to the AWAKE state  402 . When the primary clock domain sees that all of the SLEEP_ACK_SEC_SYNC[n] signals have asserted, it transitions from WAKING  208  to AWAKE  202 .  
         [0048]    It will be understood from the foregoing description that various modifications and changes may be made in the preferred embodiment of the present invention without departing from its true spirit. This description is intended for purposes of illustration only and should not be construed in a limiting sense. The scope of this invention should be limited only by the language of the following claims.