Challenges in static verification of low-power architecture

by Abhishek Mahajan, Sorabh Sachdeva and Vikramjeet Singh, Freescale Semiconductor , TechOnline India - December 14, 2011

As the semiconductor industry moves towards lower technologies, engineers must find new ways of manage unexpected low-power issues. Despite the relentless efforts of implementation engineers and EDA vendors, some issues may still get through and make their way to silicon. We provide examples of such issues and intelligent solutions for them.

As the semiconductor industry moves towards lower technologies, engineers need to find state of the art methodologies to manage unexpected low power issues.  However, despite relentless efforts of implementation engineers and EDA vendors, some issues may still skip through and make their way to silicon.

We provide examples of such issues and intelligent solutions for them. These solutions are implemented by smartly exploiting the basic capabilities of different design implementation and verification tools to catch intricate issues.

Our first two cases describe how a seemingly logically equivalent design may not be actually equivalent on silicon and how this may lead to disastrous results at a stage where reverting to design synthesis is not an option. Our third case exemplifies a design which will get a quick signoff from a static low power verification engineer but will lead the chip to the verge of burn-out.

To understand our first two cases, we will see how, at present, equivalence checking is done for the cases that we are describing.

While doing equivalence checking for signoff purposes, we bypass isolation cell to disable its fanin logic cone by constraining isolation enable pins of isolation cells to 1 or 0 depending on functionality of isolation cells. This is a major point of concern because by doing this we are neglecting a highly error prone issue and masking an important check which can lead to drastic results. Later we will see how it may lead to cases where a seeming equivalent design may not be equivalent on silicon.


Case 1

Consider a design having 4 different modules and 2 power domains (Figure 1, below)


Figure 2, below, is the comprehensive view of the design:



At the RTL stage, the design shows a signal path from switchable domain (PD2) to always on domain (PD3) and a feed-through signal path between two always on domains (PD1 & PD3) which is further connected to reset pin of a flop in PD3. During RTL synthesis, to preclude propagation of Z, each crossing from a switchable domain to always on domain will be guarded by isolation cell. We can see that the feed-through path is buffered through PD2 and hence an isolation cell will be inserted on the reset path of the flop as shown below in Figure 3. 


As discussed earlier, In RTL Equivalence checking and Netlist isolation enable signal of isolation cell will be constrained in a fashion so as to disable the logic of isolation cell.

Now consider the following case of the same design.


In this case, the design has entered standby mode and therefore switchable domain (PD2) will be turned off and all isolation cells will be enabled. We can see in Figure 4, above,  that “logic 0” is forced by both the isolation cells in the PD3. If we carefully analyze the situation we see that the design has been corrupted by the insertion of the isolation cell. We can see that in Standby mode, Output of the isolation cell (in RED) has forced “logic 0” on the reset path of flop whereas, according to the design, logic at reset paths should be driven by PD1 which is an always on domain and hence reset path can dynamically change its value even in when PD2 is off.


Case 2

Consider a design having 3 different modules and 2 power domains (Figure 5, below)


Figure 6, below, shows comprehensive view of the design in consideration.



Here, in the RTL stage, a signal is going from a switchable domain (PD2) to an always on domain (PD1). During RTL synthesis inverter pairs were added at the time of optimization. Since effective logic remained same even after addition of inverter pair we did not have any issue. Now we know that since signal is crossing from switchable domain (PD2) to always on domain (PD1) insertion of isolation cell is imperative to preclude propagation of Z in PD1. Insertion of isolation cell will be just inside PD1 which, effectively, would be between the two inverters of the inverter pair and substantiates to following scenario shown below in Figure 7.


Now consider the same design in standby mode i.e. when PD2 is off.  When the design enters standby mode, the isolation cell is enabled by asserting “iso_en” signal from isolation enable module.  With the triggering of the isolation cell a constant (say “logic 0”) will be propagated from the output of the isolation cell to PD1. The value of constant i.e. whether “logic 0” or “logic 1” should be propagated to PD1 is taken by designers and accordingly an isolation cell is used. In our case we have assumed that “logic 0” was required. During the standby stage, “logic 0” is forced by the isolation cell but because of the inverter added during optimization, “logic 1” reaches the logic in PD1, which will corrupt the design as shown below in Figure 8.



In this case, the concern is that the inverted value of the desired output will be fed to always domain (PD1). This problem will not be caught while doing equivalence checks as the isolation cell is bypassed by constraining enable of the isolation cell.

Before looking at how to rectify these problems we will consider our third case.

Case 3

Consider the following design having a switchable domain and an always on domain. First let us understand the architecture of the design. The design is powered through ballast, which in turn acts as an input source to a voltage regulator. For STDBY mode, the voltage regulator acts as a primary source of power but in RUN mode, since high current is required as both STDBY and ALWAYS ON domains are active, the ballast acts as the primary source. Note that to substantiate this activity, the enable signal of the power switch will be the same as the signal at the base of the ballast that enables it.

Now we will delve into the challenges that exist in such architecture. If the design has multiple power domains, then any crossing existing in the design from an always on power domain to a switchable power domain is not considered a power violation in the chip. Ideally such crossings can exist in the design and these crossings are ignored for formal power verification as they are perfectly legal but there can be certain cases where such a crossing can indeed lead to a power related failure in the chip. Such a scenario is illustrated in Figure 9, below.

* Please note that the diamond shapes sitting above and below the NMOS in PAD represent some transistor logic implementation (typical CMOS transistor logic)


Here an always on signal is fed to a cell (PAD) that runs on the switchable supply. Now this switchable power supply is provided to the chip through an external / internal ballast transistor. When the base of the transistor is enabled then the switchable power supply is up, otherwise it is shutoff. There is a large capacitor sitting outside the chip to control fluctuations in the voltage level of the supply.

The problem here is that there is an ESD diode that is present between the signal pin and the switchable power supply in the PAD. So if the power supply of the PAD is turned off by switching the ballast.transistor base off, then there still exists a leakage path from the always on signal through the ESD diode and finally through the capacitor to ground. The effect is that the external capacitor begins to charge if the signal value 1 is propagated from always on domain. This has the effect of trying to drive the switchable power supply net high, and thus causing a huge current dissipation through the diode thereby destroying the diode as well as the driver in the always on domain.

Since we have understood the problems thoroughly, we will look into the ways of catching such tedious scenarios during the design cycle and more importantly at a stage where we are able to rectify them with quick turn-around time.

We have a common methodology for our first 2 cases. Both of these scenarios can be caught during Gate-Level Simulation (GLS) but GLS is done at the final stages of the design cycle and therefore that is neither a useful nor sustainable solution. So we need a way to catch this issue then and there so that we can rectify immediately and preclude any such scenario later. We realized the importance and capabilities of Common Power Format (CPF) and intended to exploit them while doing Logical Equivalence Checking.

If we carefully analyze the above two cases we see that the problem was not caught because isolation enable is constrained while doing equivalence check so if we can find out a way where we do not constrain the isolation enable and find some other way to bypass the isolation cell logic then our problem will be resolved. Common Power Format (CPF), which has exhaustive definition of all the power domains, voltage levels and power modes of design, can be used to rescue us.

While doing equivalence checks we will follow these steps:

   * Read the design
   * Read Common Power Format file
   * Execute equivalence checks

While modeling the RTL of the design, an equivalence checking tool will be aware of the domain crossing because it has corresponding information from power modes defined in CPF and will therefore add an isolation cell, only if required, and will connect isolation enable of the cell to control signal mentioned in CPF file. After the RTL modeling is complete, equivalence checks between RTL and Netlist will be executed and any false isolation cells that were inserted during synthesis will be caught.

Hence by using this methodology we will be able to catch unexpected errors much earlier in the design and save a lot of engineering effort.

For our third case, we have to realize on Full Chip Analog Simulation as such a scenario cannot be caught by static power verification tools. The designer must see that such a case does not exist by design. Please note that this scenario is only valid if the ballast emitter is connected to the switchable power supply net. If the ballast emitter is connected to the always on power net, and all current to the switchable domain has to pass through the power switch, then there would not be any concern for leakage as the switchable supply net would then be perfectly tri-stated.

For now, there is no way to catch this but we are working with our EDA vendors on this issue. If you have any thoughts on this we will be happy to share our research work with you.


About the authors: 

Abhishek Mahajan is a Senior Design Engineer, Freescale Semiconductor, and can be reached at


Sorabh Sachdeva is a Senior Design Engineer, Freescale Semiconductor, and can be reached at

Vikramjeet Singh is a Design Engineer, Freescale Semiconductor, and can be reached at


blog comments powered by Disqus