(a) Critique Check

    Power State Table is Golden here and design structure is validated for correctness based on this table. For example “ Compare the ISO/LS elements present in the design with the ISO/
LS requirement inferred by analyzing the PST”

(b) Power Intent Check

Design is validated as per the Power Intent provided by user, here Power State Is ignored and mostly user written rules/policies are considered while checking, design structure is validated against user written policies  for correctness.

(c) Low Power Architecture Checks

Here design is analyzed for any architectural failures with respect to the requirement specified in the power intent. For example: Checking Power Up and Power Down Sequences of various power domains, checking for reachability of control and clock paths to the design.

Here is one scenario, where in “especially on a final sign-off netlist, can we get rid of these or will there be any electrical violations due to this”

Again this is after considering all the physical requirements, since these special cells are inserted very early in the design cycle, should we be visiting them again before signing off? Just a thought!

Supply sets refers to collection of supply nets which substitutes a complete supply source, and can be used to power up an element of a design. Each of these supply nets provide a function such as power/ground/different well supplies….etc

There are predefined supply sets, which can be referred to by any supply set through a specific supply set handle such as primary/default_retention….etc.

Also any supply net explicitly created can be referred in any supply set and function of this supply net could be totally different in each supply sets where its referred. These supply sets can be referred easily by specifying chip_top/module_a/PD1.my_supply_set, which refers to supply set that’s available under the scope chip_top/module_a, belonging to power domain PD1.

One of the main advantage of supply set is that , initially it can be a place holder with just a function attribute ,which can be later modified/updated as and when more information is available.

for example:

Initially we can start with

create_supply_set my_supply_set –function {power} –function {ground}

later it can be updated to

create_supply_set my_supply_set –function {power VDD} –function {ground VSS} –update

Being involved with every phase of design cycle, I can imagine, how this can be mis-coded/mis-interpreted at different phase of design cycle. This could be a real nightmare to debug, if anything is either misinterpreted by the tool or mis-coded by designer.

will cover more on this topic later with examples.

Some interesting observation while running LVS on a power gated or a MV design. Here is quick preview on the problem description

As shown in the picture above if LVS is run on a Verilog netlist generated without bulk pin connections, bulk connections may not be correct from electrical perspective.

More on how typically designers handle this in my next post.

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.