Reset connectivity checks in complex low power architectures

Deepak Mahajan, Saloni Raina, Khushboo Gupta (Freescale Semiconductor, India Pvt Ltd.)

With the growing advancement in semiconductor technology, there has been a drift towards the requirement of power conservation which typically involves techniques like clock gating, power gating, dynamic frequency scaling (DFS), dynamic voltage scaling (DVS) etc. This led to the introduction of various power saving modes, a.k.a. low power modes wherein some parts of the chip, which are not currently in use can be put to sleep or completely shut off to reduce the power consumption. Earlier such modes were limited, but now we have multiple advanced low power modes with increased configurability, which has led to an increased complexity in the verification/validation process. To cater for these advanced modes, the SoC is usually divided into multiple power domains, which can be selectively powered on/off depending upon the application requirements. But, the reset connectivity to these domains may vary for every module, thus making it difficult to be verified. Though there are various available tools which are used industry wide for the low power verification process, but even these have some limitations which may lead to design bugs getting missed in the verification cycle. In this article we are explaining the checks that should be done to catch such power domain related reset connectivity issues.

Let us consider a SOC which is divided into 3 different power domains – PD0, PD1, PD2 as shown below.

  1. PD0 is the always on domain, which is supposed to be powered up always and includes blocks like clocking (Fail safe clock – Usually Internal RC Oscillator), reset and boot handling, real time clock and watchdog timer.
  2. PD1 is the switchable domain which can be selectively powered on/ off in the advanced low power modes through software configurations.
  3. PD2 is the maximum power consuming domain and is always powered off in every low power mode.

Fig.1

Let us consider 3 primary low power modes –

  1. Full power with configurable clock gating.
  2. Low power mode (LPM) with PD2 power gated.
  3. Least power mode (Standby) with PD1/PD2 power gated.

Clock gating mode is a very basic power saving mode where the clock to the core and some modules can be gated selectively to reduce the power consumption and no power gating is involved in this mode. Even though this helps reduce the dynamic power consumption, there is still leakage current in the form of static power dissipation. To reduce this leakage current LPM mode was introduced, where PD2 is completely powered off, thereby leading to a tremendous reduction in power consumption as a complete power domain is switched off. There can be one core (or multiple) in PD1/PD0 depending upon the application use case of LPM mode for code execution and peripheral programming. There can be further subdivisions of this LPM mode, where the available IP’s in PD1/PD0 can be selectively clock gated to further reduce power consumption. The least power consumption mode is the standby mode, where only PD0 is powered on and can have current consumption of as low as a few uA’s.

Now, in any SoC there can be many reset domains depending upon the boot protocol and clocking protocol requirements and the IP specifications (early/delayed/synchronous/asynchronous/functional/destructive etc depending on requirements). When it comes to low power, power domains also come into picture on top of the reset domains for reset connectivity of IP’s. This increases the chances of issues in reset connectivity and increases the complexity for verifying such architectures.

Typical example of power reset connectivity issues:

Fig.2. Incorrect power domain reset connectivity.

In Fig 2, we can see that:

  • In PD1 domain, logic 1 is working on PD0 domain reset which might cause issues on exit from standby modes where PD1 logic was powered down. On exit through a non-reset source the PD0 domain doesn’t get a reset due to which logic 1 in PD1 domain will remain in unknown state and might cause logic corruption on exit.

  • In PD2 domain, logic 1 is working on PD1 reset and might cause issues on exit from LPM modes where PD2 is powered down but PD1 is functional. On exit through a non-reset source the Logic 1 in PD2 will not get reset and hence will be in unknown state.

Fig.3. Correct reset connectivity

In Fig 3, each power domain is getting it’s respective reset from correct power domain ruling out any reset connectivity issue.

While verification/validation of such complex architectures, following reset connectivity checks are important. All the checks mentioned below should be performed on flops working on all the reset inputs to the IP’s:

  1. Full power mode:
    • The reset values of all registers (PD0/PD1/PD2) should be checked.
    • Atleast 1 register should be selected from each reset domain, and read-write access should be performed on these registers.
    • In clock gating modes (full power mode) like stop/halt, all modules (PD2, PD1 and PD0) should retain their register values and memory contents. So, after wakeup from any non-reset source, all the registers should be read back if their values are retained. If the wakeup is via reset then, all the registers which are working on this reset should be checked for reset values and all other should be checked for their retained values.
  2. LPM modes:
    • During LPM mode, read-write access should be performed on all the registers in PD1/PD0 domains. Accesses to PD2 registers should revert back with proper error response depending upon the SoC specifications.
    • PD2 is power gated and hence every flop in PD2 should get a reset on exiting LPM mode to bring the logic in a known state. So all registers in PD2 must be read back for reset values and read-write access should be performed. This is to ensure that no reset from power domain PD0/PD1 is connected to PD2 flop.
    • If exit from LPM mode is via any non-reset source then the flops in PD1 and PD0 domains should retain their values. If exit is via reset then flops in PD0/PD1 domains working on that reset should be checked for reset values and others should be checked for their retained values.
    • All signals coming from OFF to ON domain (PD2 to PD1/PD0 with respect to this article) must be isolated while entering LPM mode before power gating to avoid any logic corruption in ON domains. So if there is any such signal from PD2 which is getting latched in any register in PD1/PD0, it should be checked for the isolated value.
  3. Lowest power mode (Standby)
    • PD1/PD2 domain is power gated, so all flops in PD1/PD2 domain must get a reset on exit from standby mode.
    • If exit from standby is via a non-reset source then the flops in PD1/PD2 domain should be checked for their reset values and flops in PD0 should be checked for their retained values.
    • If exit from standby is via a reset source, then flops in PD0 which are working on this reset should be checked for reset values and others need to be checked for their retained values.
    • There could be some logic in off-domain that needs to be retained on exit from standby mode, hence this should be latched in always-on domain. So after exit from standby mode, retention of this logic should be checked. For example boot vector of core, pad states for some critical functionalities etc.

Even though we are using tools like CPF (Common Power Format)/CLP (Conformal Low Power) that are available for testing the above requirements of Retention, Isolation and Power Domain Checks, there are a few limitations of these tools:

  1. Most of static checks cover the OFF → ON domain checks (isolations checks, level shifter checks in multiple voltage domains) but there are no checks available for ON → OFF domain crossing.
  2. There can be lacs of warnings (isolation/level shifters missing) from static low power checks, which may or may not actually be a design issue. A lot of effort goes into actually identifying the valid issues from all the warnings.
  3. Even if you are running dynamic power aware simulation using tools like CPF, these issues can be caught only if you have correct patterns for checking these scenarios.

These limitations may lead to a design bug left unnoticed during the Pre-Si phase, which is not acceptable. We can perform above mentioned low power register access checks to rule out any of the below mentioned issues:

  1. Flops in PD2 domain getting PD0/PD1 power domain reset.
  2. Flops in PD1 domain getting PD0 power domain reset.
  3. Non resettable flops in PD0/PD1/PD2.
  4. Clocking issues in Full power/LPM/Standby modes.
  5. Synchronous reset requirement for any IP.

The above checks can be run on both Verification as well as Pre-Si Emulation platform. Emulation platform will have an upper hand over simulations owing to its better speed, thereby saving the run time. This can improve the overall verification/validation reset connectivity testing in an automated and hassle-free fashion.

References:

×
Semiconductor IP