Making sure subtle bugs do not escape in low power designs.
By Himanshu Bhatt and Shreedhar Ramachandra
Isolation, retention, and power switches are some of the important functionalities of power-aware designs that use some of the common low power techniques (e.g.) power shutoff, multi-voltage and advanced techniques (e.g.) DVFS, Low VDD standby, and biasing. The strategies for isolation, retention, and level shifter are specified in the power format file. In dynamic low power verification, the simulator reads the power format file during RTL elaboration and evaluates the isolation and retention information in preparation for the simulation test. The aim is to make sure that the sequences for shut down, isolation, and retention are accurate. Another important aspect of a dynamic simulation is the usage of the techniques such as assertions for low power sequences, correct clamp value for isolation, save/restore handling with reset, power-on handling, multi-rail macro handling, and coverage of the power states. “X-propagation” is another important aspect of power aware simulations to ensure that RTL behavior matches with that of gate level simulation (GLS) and the functional bugs related to this can be detected much ahead in the design cycle. Having an efficient power aware debug tool is as important as having an accurate power aware simulator to enable the design and verification engineers to be able to root cause the simulation failures and fix them.
In today’s context, the pace of low power design, the market and cost of silicon failure do not allow the electronics industry a similar “baking” time for the power-aware design so using the capabilities of a power aware simulator coupled with an intuitive and powerful debug is essential to ensure that subtle bugs do not escape silicon.
Power management verification requirements
Low Power verification requirements are as follows:
Figure 1: Power management verification requirements
Power aware simulation and debug
PAVE: Power Aware Verification Environment (PAVE) is an infrastructure that enables accessing the UPF objects, monitors low power events, and writes power-aware assertions. It uses the powerful UPF query commands to query the power intent and UPF bind_checker command to bind the checker modules to the UPF objects like power domains, power switch, isolation strategy, and retention strategy. User can use the PAVE infrastructure to write custom assertions for scenarios like “clock parked high” when “reset is low” etc.
Figure 2: PAVE infrastructure
Figure 3: Custom assertion scenario to check that the clock should not be parked low during save and restore operations
X-Prop: Power Aware Simulation relies on X propagation to show the effects of power. Using this, designers can find bugs related to a missing isolation cell, any enable signal (e.g. isolation enable), which is not active and would cause the isolation cell to malfunction.
Figure 4: Finding low power bugs by propagating X
There could be scenarios based on the “RTL coding style” used which may cause the “X” to escape thereby leading to a bug in the design (which may be caught later, if running GLS). Running GLS is both time consuming and performance intensive. The “X-Prop” technology helps to mimic a GLS like behavior at the RTL level itself. The figure below illustrates this.
Figure 5: Synopsys VCS NLP with X-Prop technology
Power-On Reset Assertions: Missing resets on power-up can lead to design failures. Also, resets are required to have a minimum pulse width.
An accurate power aware simulator, such as VCS NLP, provides a mechanism to catch such reset related issues, using the “-power=assert_reset_sequence” compile-time option to enable the power-on reset assertions.
Figure 6: Power-On reset scenario
The simulator will flag these assertions when the power aware test is run:
Custom Supply Net Resolution: The supply nets defined in the user UPF could have different resolution methods based on the user requirements. The most common ones are “parallel” and “one hot”. However, there could be scenarios wherein the user wants to specify his own custom resolution function in order to resolve the drivers. The figure below illustrates this.
Figure 7: Different supply net resolution methods
VCS NLP also provides a capability to users to define their own custom resolution function in a package and use the same in UPF.
Analyzed UPF Compare Flow: Some designers who perform equivalence checking between the RTL and synthesized netlist feel the need to have synergy between the various tools used in the low power flow. The analyzed UPF flow is an example of this. In this flow, the power aware simulator creates a “UPF_*” database after reading the UPF. The equivalence checker then uses this database to perform low power equivalence checking between the RTL and the synthesized netlist. The UPF output from the power aware simulator has all the effective elements of isolation strategies in elements. Therefore, the low power equivalence checker does minimal source/sink analysis/tracing. However, for the case of heterogeneous fanouts, the equivalence checker still needs to do some tracing. This helps in avoiding false equivalence (the diagram below illustrates this flow).
Figure 8: UPF consistency between simulation and synthesis
Figure 9: Conversion of input UPF to output UPF for consumption by equivalence checker
Power Aware Debug: Debugging power aware designs is a big challenge. Using a power aware debugger which is exhaustive in features and is tightly integrated with the power aware simulator is highly desirable. The figure below denotes some of the features and capabilities of such a debug tool.
Figure 10: Power Aware debug using Verdi
Conclusions
Power aware simulation poses multiple challenges. Using a powerful and accurate power aware simulator with the capabilities of PAVE, X-Prop, Power-On reset assertions, Custom supply net resolution and analyzed UPF compare flow in conjunction to native integration with a power aware debug tool helps to boost the verification sign off confidence ensuring a “shift-left” and making sure that subtle bugs do not escape into silicon. You can learn more about power aware simulation here.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
In fig 7, the custom resolved one is the actual one_ hot driven resolution. The one which is specified as one_hot_driven supply net depicts one of the parallel_resolution case.