A need for static and dynamic Low Power Verification

Deepak Mahajan, Gaurav Jain, Abhishek Mahajan, Freescale Semiconductor

With increasing complexities in power architecture and complex power domain partitioning, it is becoming imperative to drive functional and physical verification of these complex power logic hand in hand. However, despite relentless efforts of verification engineers, some issues may still skip through and make their way to silicon. To avoid silicon failures because of low power issues, engineers need to find state of the art methodologies to manage unexpected low power issues.

CPF (Common Power Format), a standard format that captures the power intent of the design is used by the verification engineers to catch low power related issues of the design. As shown in Fig 1(a), the design without CPF has only logical connectivity. But as soon as CPF is introduced as shown in Fig 1(b), power connectivity of design also comes in to the picture. All low power design must comply with the low power specifications defined inside the CPF and hence should use it as part of their design cycle.

Fig 1(a): Design state without CPF

Fig 1(b): Design state with CPF

To ensure that design is compliant with respect to low power constraints defined in CPF, both static and dynamic checks need to be performed using the common CPF.

At first, it seems either static verification or dynamic verification alone should be sufficient to catch all the low power related issues and there is no need to run both the checks. But in reality, this is not the case. Each of the static and dynamic low power verification has different scope of verification and the usage of either of them alone is not sufficient for robust verification of the design.

In this paper, we will discuss the need of carrying both static and dynamic low power checks using a common CPF.

Need for Static low power verification

Low power static verification checks help to verify correct implementation of low power design techniques using formal techniques (versus simulation) early in the design process. These static checks on RTL helps in finding the completeness of CPF upfront ensuring that CPF contains all the isolation and level shifter rules for power and voltage domain crossings. This would ensure that no low power cell is missed between two voltage or power domains. Static verification adds value by identifying bugs which are otherwise very difficult and time consuming to find in RTL simulations.

But there are certain issues that cannot be caught using static checks. Let us discuss few of such scenarios in detail.

Bad Logic restructuring during physical design implementation: -

Now consider a design having two power domains (Always-on and Switchable) and there is crossing from switchable domain to always-on domain as shown in Fig 2

Fig 2: Crossing from Switchable to Always on Domain

Isolation cell of logic_0 level was supposed to be inserted on this crossing. Now, the logic restructuring during timing optimization has happened on the crossing such that inverter pair is added on the net as shown in Fig 3

Fig 3: Logic restructuring on crossing from Switchable to Always on Domain

Now, when isolation cell of logic_0 type is inserted on this crossing as shown in fig 4, the design works fine during normal functional mode operation as the isolation cell is in bypass mode during this case. But when the design enters standby mode, the isolation cell is enabled by asserting “iso_en” signal. With the triggering of the isolation cell a constant (say “logic 0”) will be propagated from the output of the isolation cell to the always on domain. During the standby stage, “logic 0” is forced by the isolation cell but because of inverter which is added during optimization, “logic 1” reaches the logic in switchable domain, which will corrupt the functionality of the design.

Fig 4: Isolation cell present on restructured logic

Type of isolation cells:

Static low power check can help to identify the missing isolation cells at places where there is crossing from on to off domain. But it cannot ensure the type of isolation cell (logic_0 or logic_1 type), that needs to be present at that particular crossing.

Sequencing of the critical low power control signals:

Static verification checks can not verify the sequence in which critical low power signals can be asserted. The basic example of one such check is isolation assertion check which ensures isolation control signal is asserted before power is switched off and then power is switched back on before isolation control is de-asserted as shown in Fig 5.

Fig 5: Dependency of iso_en on power

Need for Dynamic low power verification

Low power dynamic low power checks help to verify the functionality of all the power-management elements. To achieve that, it uses a set of stimuli on:

  • DUT (Design under Test), that captures logical functionality of design
  • CPF (Common power Format), that captures power intent of the design

Stimulus is a combination of signals prepared on the basis of the power intent and the functionality for the DUT. According to the stimulus provided, some part of the RTL is switched off, while keeping some part at always on state. The simulator forces Xs, on the signals coming from shut-off domains to always-on domains in order to simulate their off state. If the desired functionality is not corrupted because of any of these Xs, the design is considered to be compliant from low power perspective,

But there are certain issues that cannot be caught using this method. These issues if left unattended can cause silicon failure. Let us discuss few of such scenarios in detail.

Missing Level Shifter:

Consider a design having two blocks working on two different power supplies (1.2V and 3.3V). There is a requirement of level shifter cell on signals crossing from 1.2V domain to 3.3V domain as shown in Fig 6. The Purpose of this cell is to shift the voltage from low to high.

Fig 6: Level shifter from 1.2V to 3.3V domain

Logically, the functionality of level shifter cell is similar to that of a buffer (i.e. output = input). So, in case a level shifter cell is missing at some place, the simulation tool will not flag any error but in reality it can cause crowbar currents and thus failure of silicon.

Missing isolation cells from test logic path: -

Consider a design having two different power domains as shown in Fig 7

  • Always on domain having supply PD_AO
  • Switchable domain having supply PD_SW

Fig 7: Isolation cell present on test logic

In standby mode, PD_SW will be turned off but PD_AO will be on. So, there will be need of isolation cell on every signal crossing from Switchable domain to Always on domain. Let us consider a flop (present in switchable domain), the output of which is connected to scan-in pin of flop (through some buffers) present in always on domain.

In case an isolation cell is missing on this crossing, the simulation tool will not flag any error because such paths are not checked in functional simulations. But since powered-off domains do not drive their outputs anymore, and their outputs become floating nodes, the unexpected signal value on crossing might cause high current consumption because of an inappropriate logic level, and may lead to silicon failure.

Wrong power connectivity of Analog block:

For a digital simulation tool, all the power nets are considered as same irrespective of the voltage level associated with that power net. So, in case some wrong power connectivity is done on Analog block, it may not be possible to catch it using simulation and silicon may fail because of this.

Conclusion:

The advent of power aware design with its reliance upon multiple power domains introduces additional opportunities for error. Both static and dynamic low power verification techniques are integral part of verification of any low power intended design. Completeness of the CPF can be verified by running the static low power checks on the RTL along with CPF. Once done, then this CPF should be used for RTL simulations, especially when the power management scheme is a very complex one.

×
Semiconductor IP