Methodology for effective hierarchical verification of low power designs Ramesh Rajagopalan Cisco Systems Inc, San Jose, Namit Gupta Synopsys Inc, Mountain View,

Authors Information 1) Ramesh Rajagopalan,Cisco Systems Inc, phone(408) Ramesh has been in the physical design field for over 19 years and he is currently a Technical Leader with Switching Silicon Group at Cisco. Physical design of Custom network switching ASICs and UltraSparc microprocessors form part of his experience. 2) Namit Gupta, Synopsys Inc, Namit Gupta is a Staff corporate application engineer at Synopsys Inc with responsibility for verification solutions. Gupta holds a bachelor’s degree in electronics from the Indian Institute of Technology, Delhi. Among Gupta’s interest areas are RTL design and verification, clock domain crossing, low power, design constraints, and ESL. Phone

Abstract With increasing demand to conserve power in ASICs, there is a need for advanced low power techniques right from architecture planning till implementation. This paper/poster provides methodology used by us to come up with efficient way to plan the power intent, do a quick check to ensure completeness and correctness, followed by verification and implementation. And during this process we faced challenges during the use of such methodology, and came up with techniques to overcome those for efficient implementation of low power design.

Motivation: “Correct by construction” methodology for a low power design technique Current size and complexity of SOC/ASIC designs dictate - use of advanced low power techniques to reduce power and - saving and restoring of critical design states. Use of multiple voltages in the design is one of the widely adopted low power technique. - Different parts of a chip might have different speed requirements. - A lower supply voltage reduces power consumption but also reduces speed. - To get maximum speed and lower power at the same time, only blocks that need to work at higher clock rates can operate with a higher supply voltage while the other blocks can operate with a lower voltage.

Significance of power intent description it is almost a necessity that from very beginning power intent is mostly clear. This is the main reason that power intent description has become integral part of RTL development. Power intent needs to be captured for various power domains, switches to turn on/off supplies, voltage levels of supplies, protection devices like level shifter, isolation Providing two or more supply voltages on a single chip introduces some complexities and costs. Additional device pins must be available to supply the chip voltages, and the power grid must distribute each of the voltage supplies separately to the appropriate blocks. Where a logic signal leaves one power domain and enters another, if the voltages are significantly different, a level-shifter cell is necessary to generate a signal with the proper voltage swing. A level shifter cell itself requires two power supplies that match the input and output supply voltages.

Power intent guides physical power grid implementation Using the power intent description, abstract power supply networks are defined, also called as “supply sets”. The most important step which needs careful planning is to define valid power states combinations Once supplies are defined explicitly using “create_supply_port” OR implicitly using “create_supply_set”, then valid supply states are defined next using “add_port_state” and “add_power_state”. This means defining when state will be “off”, “high_voltage”, “low_voltage” etc. the Power State Table (PST) describes all the possible power states of a design and is used as a “golden” reference by implementation tools and static verification checkers.

Why Static Verification? Static verification checks on Isolation and level shifters versus requirements implied by PST Missing/Incorrect/Redundant protection devices Is my micro-architecture correct? Island order checks on control/clock paths in the design w.r.t enables of protection elements Static verification Checks – to ensure that implementation is following the power intent What were assumptions made in our methodology and how we took care of gotchas PST is reference – What if there is a bug in PST? Once design is simulated with all legal states, power aware simulation can capture such issues How can I ensure my dynamic verification team covers all legal states and power shutdown during simulation? It is extremely important to plan low power specific coverage from start and track it till closure

Challenges : Use of PST in Hierarchical design verification  PST as used in subchips and in a hierarchical top level verification.  Need to merge PSTs to verify hierarchical design

Use of PST in Power-Aware verification A power state table is a collection of all possible power states for all input supply net/ports of a design. Given a PST, synthesis tool would implement the design in such a way that no LS/ISO/Logic violation could be found in the design. In a flatten design, theoretically level shifters and isolation cells can be inserted at anywhere in the design. Therefore, it is always possible to implement the design without any LS/ISO/Logic violations for a given PST. However, in a hierarchical flow, because some sub-blocks are not allowed to change, LS/ISO/Logic violations are impossible to resolve if they happen within fixed sub-blocks. Those errors can only be prevented by enforcing certain relationship among PSTs specified at different hierarchy. Assumptions we made for making it methodical  One PST at each scope  Only power state nominal values for state comparison  Merged PSTs reflects intersection of all legal states of all scope PSTs

Example of PST correctness need Consider following example, where there are 2 domains PD1 and PD2, where VDD1 is primary supply of PD1 and VDD2 is primary supply of PD2, as per specification below are the valid states If VDD1 and VDD2 is ON and OFF simultaneously, there is no need to for ISO cell But with VDD1 OFF and VDD2 ON, combination in PST can contradict this and bug will slip through ISO Cell BUG VDD1/ PD1 VDD2/ PD2

Challenges : Use of PST in Hierarchical design verification X X X Null PST Figure 1: Example of PST merging with disjoint set of supply signals Figure 2: PST Example of PST merging overlapping set of supply signals

Automatic assertions  Common assertions based on design + power intent User defined assertions  Any dedicated assertion using LP data  Depending on design/project need For example sequence of sleep signal with reset Goal is to increase confidence on the LP regression suite, like…  Ensure all PD have been switched on/off  Ensure all Multi-Rail Macros have been switched as expected…  Specific checks to workaround missing or inaccurate models Low Power Assertions

PST describes all valid combinations of voltage values This information is used by implementation tools to determine protection needs At runtime, simulator has accurate knowledge of state and voltage value of each net of the design…  Can report PST state changes  Can report when reaching an ‘illegal’ state Need for PST validation

Limitations and Future Work Assumptions we made for making it methodical  One PST at each scope  Only power state nominal values for state comparison  Merged PSTs reflects intersection of all legal states of all scope PSTs Future Work: PST verification is a very critical step and we need to fine tune the methodology to make it of signoff quality.