Clock gating is the most common low power saving technique in use for a long time.  Latch based clock gating logic is typically used to avoid any glitches even during entry and exit from/to sleep mode.  In a power gated design , usually we stop the clock at in-active phase before retaining states and entering sleep mode and same for wake up mode.  Here one of the main challenge is the validity of the enable signal at wakeup, which is typically provided by the restored states in the registers propagating through cloud of logic to the clock gating latches, which stay open during in-active phase.

In a power gated design, where retention registers are not used, this propagation mechanism may not work and we might have to use some kind of state retention for the clock gating latches, which retains the clock gating state when powered down. In one of the design, this is incorporated using retention latch(similar to retention flop) inside the latch based clock gating cell.

It may not be required to use these special cells if retention registers happen to exist in the design, which controls the clock enable signal state. Its also not required if some logic is built in to ensure controllability of the clock during inactive phase while entering and exiting the hibernation mode.

Monday, March 29, 2010
11:00 AM – 12:30 PM

MA1 Tutorial : Implementation

PrimeRail and IC Compiler: In-Design Rail Analysis for Faster Power Network Design Closure

MA2 User – Constraints and Power Challenges in Verification : Verification

Formal Methods to Verify the Power Manager for an Embedded Multiprocessor Cluster

Monday, March 29, 2010
1:45 PM – 3:15 PM

MB3 Tutorial : AMS

HSIMplus CircuitCheck for Low Power Transistor Level Error Detection

Power Correlation with Silicon – A PrimeTime PX Evaluation

Tuesday, March 30, 2010
10:15 AM – 11:45 AM

TA1 User –

Reusable UPF for Multi-Voltage Design & Handling Analog Macros in Power Subsystem

TA2 Tutorial : Verification

Low Power Verification

Tuesday, March 30, 2010
1:00 PM – 2:30 PM

TB1 User – Implementation

LeSa Lowers Leakage

Tuesday, March 30, 2010
2:50 PM – 4:50 PM

Clock Power Reduction-Analysis Metrics and Power Reduction Techniques

Low Power Multi-Voltage Design Implementation Methodology using the IEEE 1801 (UPF) Standard

Wednesday, March 31, 2010
10:15 AM – 11:45 AM

WA1 Tutorial : Implementation

Energy Efficient Processor Implementation with Synopsys’ Eclypse Low Power Solution

WB5 Tutorial : IP

Extreme Low-Power Datapath Design with DesignWare minPower Components

Recently based on some silicon debugging, we realized verification did not cover some aspect of the power down function that lead to chip failure. Later realized that, this is  being mentioned some where in VMM LP manual, thought of sharing this here.

MOS transistors are dependent on their gate-source voltage difference to determine whether they are “on” or “off”, also known as “conducting” or “non-conducting”. This mechanism is used in power gating. The Gate voltage is such that the transistor is non-conducting. This is done by issuing logic “1” to the Gate, which charges it up to the Vdd level of the driver. In general, this is the same voltage level as the power switch. The gate-source difference kicks in to turn the transistor off. However, when the Vdd of the power gating signal’s driver “dips”, the off island makes an “on” excursion and come back. On the other side, the power gate can also become more resistive. Similarly, an on island with a footer can suddenly become more resistive or make an on excursion.

This phenomena is quite dangerous, as it will lead to a current spike and a further collapse of rails. Although the profile looks like a power integrity issue and may well be caused by bad implementation of the power grid, frequently the cause is an over-scheduling of power state changes instead of staggering them in time. This in turn causes fluctuations in the power supply. The Power Management Unit must take the stability of the power supplies into account before moving rails in voltage value.

Will talk on the verification plan for this scenario in my next post.

Output signal isolation method is usually a preferred choice than the input isolation method as former leads to fewer isolation cells and gives better control over how the enable signal can be  propagated to the isolation logic. 

Input isolation will be a better choice if there are very few independent domains. In such situation isolation enable signal management is very straight-forward.  Here number of power domain is not the main component, its the sequence in which they are powered down and up. In this case isolation cell is only required when the power island is active. During the power down period, the power island is no longer functional and no power is supplied to the island. Therefore, neither the floating inputs nor the input transient state matters to the power island, which is overall good from total power perspective.

For this method, probably regular standard cells (NAND and NOR) can be used as isolation cells rather than requiring a custom cell.

I know we spend so much time in writing power intent of a design and validating whether its correct or not. In that process on a recent project, I did some analysis on how some of the intent generation can be pseudo automated.

Used the MV static checker, MVRC to auto generate some policies based on the xover analysis and it helped quite a bit and was amazed at how fast I was able to generate these constraints from MVRC.

For example, on one of the design, finding out what need to be isolated and excluded from isolation was not a trivial task due to multi-fanout nature of the ports/pins. Looked at the xover analysis within MVRC and used this feature to auto-generate some of the isolation policies. It was less than 30 lines of TCL code within MVRC, which made my life easier in generating some part of power intent.

just an example on what I did within MVRC

set f1 [open ${source_island}_${dest_island}.xover w]
set xs [get_crossovers -source $source_island -dest $dest_island]
foreach x $xs {
    set src_port  [get_crossover_info -object $x -boundary_source]
    set src_port [regsub -all {\{} $src_port {}]
    set src_port [regsub -all {\}} $src_port {}]
    lappend src_ports_list $src_port }}
}

if {$src_ports_list!=""} {puts $f1 "set_isolation ${source_island}_${dest_island}_ISO -domain ${source_island} -isolation_power_net $domain_vdd_net -isolation_ground_net VSS -clamp_value 0 -elements \"$src_ports_list\""}

This may not be complete, but idea is very similar to one given above.

We can debate on whether should a sign-off MV tool be used for this or not?

Happy Holidays.