Archive for 2009

Sorry guys, got tied up with many projects and could not blog for almost 4 weeks.

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.

Isolation cells are used in almost all power gated designs.  Given below are some tips about these cells, this information is based on my experience working with various designers.

 (1) Output signal isolation is usually a better choice than the input isolation .

(2) Input isolation is reasonable on designs that have controllable independent power domains

(3) If custom isolation cells are not available, regular cells such as (AND/NOR) can be used, but we need to make sure that these cells are kept alive all the time.

(4) Isolation cells impacts timing and area and hence should be used and analyzed properly. It should be inserted as early as possible in the design cycle to account for area/timing penalty.

(5) If feed through paths exist in the power down domain, its not necessary to isolate these nets , but need to be kept alive

(6) Isolation cells should be placed close to boundary and interface nets should be protected all the time and should not be buffered if its residing in a domain, whose power characteristics is different from source/sink domain

(7) Some logic cells such as XOR gates, should be avoided at the interface logic so as to prevent any accidental sneak paths

(8) Check the isolation states to make sure, parking at one value “1” or “0” does not lead to any sneaky paths

(9) Its preferable to use enable level shifter instead of LS+ISO cells .

(10) Last but not the least, make sure to write the isolation policy in UPF at the right interface. Its not practical and reasonable to write isolation policy both at the sink/source simultaneously.

Lets discuss about the placement of these cells and AON’ness of these cells in the next post.

My apologies for changing the title of my previous post. I realized that most of the optimization challenges are primarily due to the design requirements not UPF requirements. UPF is just a medium to define power intent, similar to verilog defining the logic intent of the design.

continuing on the same topic, few more reasons, which makes optimization challenging are

1. Isolation cells, isolating off/on blocks need to be placed closer to source if the isolation cell used is a single rail cell and its residing domain is different than the source/sink domain. This ensures that the signal is isolated properly to reach the sink. Scenario changes if the isolation cells used are dual rail isolation cell. 
2. During scan mode, all the special cells should be directly controllable and observable . This puts restriction on how tools can handle scan chain. This can also lead to scan chain re-ordering locally.
3. Global signal distribution need to be power aware.. This leads to proper usage of AON buffers and regular buffers depending on how the global signal traverses.
4. Physically each power domain/island/voltage area can restrict the routing of the signals, which might lead to taking  longer route to reach destination. Due to these longer routes, more buffers/inverters/logic may be required to fix transition/timing/si requirements.

I quite often get this question, my design used to work fine , P&R tools did not have any issues and was routed clean and so was LVS . But the same design, targeted towards reducing power leads to undesirable results and not at all clean?

Now lets look at some of the challenges faced by the optimization tools, when power domains are introduced through UPF? Other thing to keep in mind is power is no longer an after thought process anymore, designs need to be well architected up-front to avoid certain issues stated above!

(1) Physical optimization during placement is constrained to ensure that cells in a power domain are placed inside the island(voltage area). This requires hard exclusive region constraints applied to the cells in the power domain during the placement and physical aware optimization process. It also requires tools to keep track of logical hierarchies as netlist is being modified, all the physical optimization need to align itself with the logical hierarchies and insert the new cells in the respective hierarchies, else we end up having AON cells in dead region and vice-versa

(2) New cells created during re-structuring logic or local buffering in a power domain must be assigned to the power island and constrained to ensure that they are placed inside the respective island.

(3) Short feed-through paths in a power island should be protected from buffer insertion during design optimization and design-rule fixing to maintain wire connection(inserting buffers and the entry point of the island and exit point of the island). Long feed-through paths that need repeaters must be buffered by always-on buffers so that the feed-through paths are functional while the island is powered down.

(4) Special cells such as Level Shifter/Isolation Cells….etc, have their respective places physically(pre-defined) to avoid electrical issues and should be honored through out the optimization process.

…more in my next post.

Continuing on the same topic, here are are some thoughts on the insertion criteria

if planning for decoupling cap in the power planning stage, a good strategy would be, to add as many decoupling cap as possible in the permanent power network at the positions close to the switch cells for maximum effectiveness and to minimize its impact on wakeup latency and rush current.  If possible integrating the decoupling cap into the switch cell will simplify the decoupling cap cell  insertion to a greater extent. The maximum capacitance of the decoupling cap on the permanent power network is constrained by the leakage and area penalties.

To fix dynamic IR-drop violations in post-layout stage, it is recommended to add decoupling cap to the permanent power network close to the violation spots, if the violations are related to the permanent power network. Rest of the violations can be fixed by adding decoupling cap to the virtual power network closer to the hot-spots.

Hearing many concerns on topics related to power gated design and its relation to decoupling capacitor to reduce IR-Drop issues. Thought of writing a paragraph on this topic.

Power gated designs requires addition of decoupling capacitor  to power network to resolve dynamic IR-drop issues.  Decoupling cap insertion becomes more challenging in the power-gated designs compared to normal designs. Besides the issues of high leakage power in the de-caps , de-caps added to the virtual power network has significant impact on the wakeup latency and in-rush current.  Larger the decoupling capacitance, Larger the in-rush charge current and longer time to wakeup. On the other hand, de-caps, inserted in the permanent power network, does not affect the wakeup latency and in-rush current. Therefore, optimization of de-cap insertion in the power-gating design should not only minimize total capacitance of the de-caps but we should also consider adding some capacitance to the virtual power network while meeting the dynamic IR-drop target.

This year at DAC its once again “Low Power is one of the biggest challenges ”

Here is a link explaining a bit on Low Power at DAC “Low Power and DAC”

Recently found some interesting information on how to write proper level shifter rule, when designer does not want to insert LS in one particular direction.

For example say, we don’t want tools to insert High to Low LS. If we go by traditional approach as given below

set_level_shifter -domain LOW -applies_to outputs -rule low_to_high -location parent L2HLS_rule

Will the above rule ensure that no H2L LS are inserted? Probably not.

Now lets get into little more details on how the optimization tool looks at the above rule

one important thing to note here is that, set_level_shifter UPF command is a soft-constraint and LS insertion and optimization is done based on the PST table along with some information from set_level_shifter command.

First tool looks at the PST table and then decides, we need LS as source and sink voltage differ. Now the “set_level_shifter” command says that we need L2H LS on all the outputs of domain “LOW” and its location should be parent.  Based on the set_level_shifter command it decides that L2H LS need to be inserted at the parent of “LOW” domain.  Since there is no rule on inputs and PST says that voltage differ at the input level as well, it goes ahead and insert LS on inputs as well. This is not what we wanted, we wanted only L2H LS and no H2L LS, but tool inserted both H2L and L2H LS.

To accomplish only L2H LS, we need to have rules defined as below

set_level_shifter -domain LOW -applies_to outputs -rule low_to_high -location parent L2HLS_rule

set_level_shifter -domain LOW -applies_to inputs -rule high_to_low –no_shift L2HLS no_H2LLS_rule

To make it more explicit, we can also include

set_level_shifter -domain HIGH -applies_to outputs -rule high_to_low –no_shift no_H2L_LS_HIGH_rule

Quite often I am seeing, different switch cells are used in parallel(controlled turn-on) to shut-down

power to a block. If someone need to write an UPF, it would  look something like this

create_power_switch gprs_sw_0
  -domain GPRs/GPRS
  -input_supply_port {in GPRs/VDDG}
  -output_supply_port {out GPRs/VDDGS}
  -control_port {gprs_sd PwrCtrl/gprs_sd}
  -on_state {sw_0_on_state in {!gprs_sd}}

create_power_switch gprs_sw_1
  -domain GPRs/GPRS
  -input_supply_port {in GPRs/VDDG}
  -output_supply_port {out GPRs/VDDGS}
  -control_port {gprs_sd PwrCtrl/gprs_sd}
  -on_state {sw_1_on_state in {!gprs_sd}}

If you look at the above there are multiple drivers for the supply net “GPRs/VDDGS”, this would result

in an error if the supply net is not created using the UPF command

create_supply_net  VDDGS  -domain GPRs/GPRS -resolve parallel

Syntax of the above command is

create_supply_net net_name
[-domain domain_name][-reuse]
[-resolve <unresolved | one_hot | parallel | parallel_one_hot>]

Working on hierarchical UPF flows these days, its quite interesting to observe how tools optimize PST hierarchically and also on how to constrain/write UPF for lower level blocks.

There are quite a few challenges in terms of UPF with respect to

(a) Location of special cells such as LS/ISO/ELS…etc

(b) Depending on whether location is parent/self, physical implementation is going to be different for each of these strategies

(c) How to assemble blocks at the top level and finally analyze the power intent.