Archive for August, 2010

There seem to be some confusion about types of checks that need to be performed on a Low Power Design. In the Low Power static check world, following 3 types of analysis can be done on a design, in addition to various other checks.

(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.

How do we minimize or reduce area in a Low Power Design, especially when it come down to using special cells such as isolation cells, level shifter cells…etc

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!

We are so much used to having explicit supply nets and ports in the design as well as in UPF,  its hard to visualize how a hardware logic designer would code the UPF using supply sets.   For those of you who are not familiar with supply sets, here is a quick preview of the same

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.