Archive for 2007

UPF is a way to represent the Power Intent of a design. It directs all the tools in the flow to interpret the Power Intent in the same way. Before we jump into the details of UPF, let’s try to understand what we mean by Power Intent.

Typically for any design implementing any of the Advanced Low Power Techniques, we need to ask or have answer to the following questions:-

(a) What techniques are used to reduce power in the design?
Example: Multi-Voltage, Multi-Supply, Back-Bias, DVFS, AVFS etc.

(b) How is the design partitioned with respect to Voltage ?
Example: Core has 3 Voltages and IO has one Voltage

(c) Is there any block, whose power will be shut-down when block is not operational ?

(d) Does technology support these techniques?

(e) Are special cells such Level Shifter, Isolation Cell, Switches …. etc available in the library ?

(f) Is the architecture chosen for Power Gating, Coarse-Grain or Fine-Grain ?

(g) Is the power source internal to chip via on-chip variable regulator or an external regulator?

(h) What’s the expected Wake-Up time ? What’s the expected Ramp up Time ?

and so on.

Answers to these questions in a standard format such as UPF is the Power Intent of the design. Based on this information provided via UPF, various tools in the flow are going to make the appropriate implementation/verification decisions.

In my next post, let’s take a sample design and see how the verification tool will interpret this information.

So far my posts have dealt with various power reduction techniques used by designers as well as some of the challenges faced using these techniques in the design flow.

Most of the complexity in using these techniques comes from the fact that we need to interpret virtual logical/physical power structures, since most of them are not specified in the RTL.

The implementation tools need to interpret these logical/physical structures based on the RTL and some tool specific commands. This leads to complicating verification flow in general. Can we prevent this additional complexity by adding these structures explicitly in the RTL ? That is the question!

All These days power intent/requirements are typically captured through a combination of:

(a) RTL
(b) TCL based tool specific commands
(c) Library model in Liberty Format
(d) Design Constraints file (SDC)
(e) Verilog Simulation models
(f) Customized Routines such as PLI’s for verification
(g) User Driven customized Assertions …..etc

If you look at the above list, the power intent/specification is available at many sources. There could be duplicates/redundant ones, which could lead to passing different set of information to verification/implementation tools. I think in the best interest of designing chips efficiently, power intent should be kept seperate from functional intent.

Fortunately, now we have a way to express the power intent through standards such as the Unified Power Format. I will try to take you through the complete flow from RTL to GDS implementation/verification using UPF, in my next few posts.

Briefly, the general idea of UPF is to keep your design Power Intent separate from the Functional Intent and to let each tool in the flow understand the power requirements through this format. Keep in mind that any Power Intent file is only representing your design’s power-related definitions. By itself, it will not guarantee an optimal low power design.

Guys jump in and let me know if you want to hear something in specific to UPF you are challenged with, while planning for your next chip.

Could not write much for last few weeks and would like to complete the IR-Drop series with few good articles today.

These days I am hearing lot of questions/concerns about UPF,its usage and how the whole design flow is going to look like with UPF. Planning to start a UPF tutorial running for 4-5 posts to go over the complete design flow using UPF.

Here are few more interesting articles on IR Drop management:

(1) Use both static and dynamic analysis early and late in the design flow

(2) Emphasis on early Rail Analysis

(3) Establish IR drop limits based on its Impact to timing

I apologize for not writing as often as I would like, Was quite busy with multiple design flow related activities. Bear with my busy schedule for the next few weeks.

Important points to consider when determining your methodology for power rail analysis include:

(a) Use static IR analysis to generate robust power rails.
(b) Use dynamic IR analysis to optimize the insertion of de-coupling capacitance.
(c) Use static IR analysis to optimize power switch sizes to minimize IR drop.
(d) Use dynamic IR power-up analysis to optimize power switch sizes to control power-up ramp time.
(e) Use both static and dynamic analysis early and late in the design flow.
(f) Establish IR drop limits based on understanding how IR drop can affect timing.
(g) Try to optimize for decoupling capacitors early in the flow, since this requires major change in the design infrastructure

Here is a link to one good paper discussing about Sleep Transistor Sizing

Sleep Transistor Sizing

Most common issue faced in any Low Power Design is how can we minimize noise coupling between different rails and between cells in the same power domain. I am planning on discussing these in my next 2 posts.

Power and Ground Noise can degrade timing and can lead to functional failures. Most commonly used method is to insert decoupling capacitors to minimize the IR-Drop issues. Insertion of these Decap cells can be more challenging in a Power Gated design than a normal design. One of the reason for this being more challenging is “In Rush current management“.

In any power gated design one of the main requirement is to make sure that block that’s being shut-down wakes up as quickly as possible, without impacting the functionality of the other alive blocks. But this requires a very well managed In-Rush current circuitry. Now the question is , how come this impacts Decap Insertion?

If we remember, one of the most common methodology to minimize Current Surge during wakeup is

(1) Hook up the switches in Daisy Chain fashion
(2) Hook up the switches in buffered fashion
(3) Hook up the switches in Star Topology….etc

Now main goal in the daisy-chain topology is to sequentially charge the power gated block to reduce the current surge. However the current required to turn on the first switch of each chain can cause significant noise and voltage drop to the neighbouring cells. So one of the basic thing we need to follow is insert Decap’s next to switch cells, which is the main source of noise during wake-up.

But blindly inserting lots of decap’s in a power gated design has its own implication, which I will try to cover in my next post.

I was in discussion with a designer other day on “Impact on performance of the design if the voltage range is not choosen correctly”, today I am going elaborate a bit on this topic.

While designing the system with DVFS techniques, we need to look at the impact of temperature inversion on the performance of the design.While selecting the voltages and frequencies for the design, one must consider the range such that delay/voltage consistently either increase or decrease. What this means is we must always operate above the temperature inversion point.

Especially in low power UDSM process combined use of reduced VDD and High Threshold voltage may greatly modify the temperature sensitiveness of the design. Due to this worst case timing is no longer guaranteed at highest temperature.So in order to guarantee the correct behaviour of the design, one has to verify the design at various PVT conditions. This leads to increase in the total turn around time.

In a nutshell, Normally delay increases with increase in temperature, but below a certain voltage, this relationship inverts and delay starts to decrease with increase in temperature. This is a function of threshold voltage(Threshold voltage and carrier mobility are temperature dependent). Due to this threshold voltage dependence, we have observed that non-critcal paths suddenly become critical.

Having said this as soon as Voltage/Delay relate randomly Voltage Scaling becomes a nightmare to implement and verify

Note: If both threshold voltage and carrier mobility monotonically decrease with increase in temperature, Operating Voltages(range) defines the performance of the design.

I Forgot to add the syntax of Modelling Isolation cells. Thanks Sampath for reminding me on this. Here is one way to model ISOLATION cells

cell (isolation_cell) {
cell_leakage_power : 2.382 ;

pg_pin(VSS) {
voltage_name : VSS;
pg_type : primary_ground;
}
pg_pin(VDD) {
voltage_name : VDD;
pg_type : primary_power;
}
pin(data_in) {
direction : input;
capacitance : 0.001867;
rise_capacitance : 0.001234;
fall_capacitance : 0.004567;
}
pin(isolation_enable) {
direction : input;
capacitance : 0.007890;
rise_capacitance : 0.001234;
fall_capacitance : 0.005678;
isolation_cell_enable_pin : true;
}
pin(clamped_data) {
direction : output;
max_capacitance : 0.09876;
function : “(data_in+isolation_enable)”;
timing() {
related_pin : “isolation_enable”;
timing_sense : positive_unate;
…….
}
….
}

I was in Boston last week attending SNUG and got a chance to interact with many designers and one of the key concerns raised were in understanding the Voltage scaling approach . Planning to take a quick tour on this topic in my next few posts

There are various voltage scaling approaches that are in use today

Static Voltage Scaling: Different blocks in the design will be operating at different fixed supply voltages

Multi-level Voltage Scaling: An extension to static voltage scaling where in different blocks are switched between two or more voltage levels.

Dynamic Voltage and Frequency Scaling : An extension to Multi-Level Voltage Scaling Voltage levels are dynamically varied as per the work-load of the block

Adaptive Voltage Scaling : An extension to  DVFS and its a closed loop representation of the above method. Power Controller block within the design adopts itself dynamically to varying work-loads.

DVFS example: Here is an outline of tasks that will be executed within a design to scale voltage and frequency dynamically, controller first decides the minimum clock speed that meets the workload requirements. It then determines the lowest supply voltage that will support that clock speed. Given below is an example of a sequence thats followed  if the target frequency is higher than the current frequency

– Controller monitors the variance in work-load
– Controller detects variation in work-load and programs the device to operate at different voltage
– Block under question continues operating at the current clock frequency until the voltage settles to the new value
– Controller then programs the desired pre-determined clock frequency

Varying clocks and voltages during operation is  a new methodology in the design and leads to many challenges in the design process

– Identifying the optimal combination of Voltage/Frequency
– How to model the timing behavior
– Clock and Power Supply locking times.

I have been post-poning explaining about the library requirements for quite sometime. Today let me explain little bit on library modelling of special cells such as

(1) Level Shifter
(2) Isolation Cell
(3) Retention flop
(4) Always On Cell
(5) Switch

Most important information to note here is, these special cells may have multiple power pins and hence we have to describe these models with pg_pin so that the timing arc’s are w.r.t to these power and ground pins as well

(1) Level Shifter:

cell (low2high_ls) {
level_shifter_type : LH;
pg_pin(VSS) {
voltage_name : VSS;
pg_type : primary_ground;
}
pg_pin(VDD) {
voltage_name : VDD;
pg_type : primary_power;
std_cell_main_rail : true;
}
pg_pin(VDDL) {
voltage_name : VDDL;
pg_type : primary_power;
}
  is_level_shifter : true;
  pin(I)  {
    direction : input;
    capacitance : 0.0034;
    rise_capacitance : 0.0032;
    fall_capacitance : 0.0034;
input_signal_level : VDDL;
related_power_pin : VDDL;
related_ground_pin : VSS;
  }
¼br>   pin(Z)  {
    direction : output;
output_signal_level : VDD;
related_power_pin : VDD;
related_ground_pin : VSS;
…..
}

(3) Retention Flop:

cell (retention_flop) {
pg_pin(VDD) {
voltage_name : VDD;
pg_type : primary_power;
}
pg_pin (VDD_retain) {
voltage_name : VDD_retain;
pg_type : backup_power;
}
pg_pin(VSS) {
voltage_name : VSS;
pg_type : primary_ground;
}

……..

cell_footprint : “retention_flop” ;
  power_gating_cell : “retention_flop” ;
  ff(“IQ”,”IQN”) {
    next_state : “((D !SE) + (SE SI)) (wakeup !sleep)”;
    clocked_on : “CP”;
  }
pin(wakeup)  {
always_on : true;
    direction : input;
    capacitance : 0.0012;
    rise_capacitance : 0.0012;
    fall_capacitance : 0.0012;
    power_gating_pin (“power_pin_1″, 1);
……

}

(4) Always on Buffer:
cell (always_on_buffer) {
always_on : true;
pg_pin(VDD) {
voltage_name : VDD;
pg_type : primary_power;
}
pg_pin (VDD_retain) {
voltage_name : VDD_retain;
pg_type : backup_power;
}
pg_pin(VSS) {
voltage_name : VSS;
pg_type : primary_ground;
}
……….
}

(5) Switch Cell:
cell (header_switch) {
switch_cell_type : coarse_grain;
pg_pin(VDD) {
voltage_name : VDD;
pg_type : primary_power;
direction : input;
}
pg_pin(VDD_internal) {
voltage_name : VDD_internal;
pg_type : internal_power;
switch_function : “sleepin”;
pg_function : “VDD”;
direction : output;
}
pg_pin(VSS) {
voltage_name : VSS;
pg_type : primary_ground;
direction : input;
}

……

pin(sleepin)  {
switch_pin : true;
always_on : true;
    direction : input;
    capacitance : 0.0046;
    rise_capacitance : 0.0046;
    fall_capacitance : 0.0046;
  }

pin(sleepout)  {
power_down_function : “!VDD + VSS”;
    direction : output;
    max_capacitance : 0.1694;
    function : “sleepin”;

…..

}

If the required attributes highlighted in the above .lib model is present, most of the tools will be able to identify them as special cells and optimize them accordingly.

Last week, we saw on how to simulate retention flops using $functions as well as using adhoc methods to simulate similar behaviour. We have been hearing a lot about power standards helping us in solving this problem. Here is how UPF can help us in simulating this behaviour

set_retention gated_retention -domain IGATED_DOMAIN -retention_power_net VDD -retention_ground_net VSS

set_retention_control gated_retention -domain IGATED_DOMAIN -save_signal {power_sequence/save high} -restore_signal {power_sequence/restore high}

map_retention_cell gated_retention -domain IGATED_DOMAIN -lib_cell RETENTION_FLOP

Waveform given below shows snap-shot of the simulation behaviour