Overcoming Low Power Verification Challenges For Mixed-Signal SoC Designs

With increasing SoC complexity and advanced power-aware architectures, a robust low power verification methodology is important for signing off the design at different stages from RTL through netlist. For mixed-signal SoCs, the challenge is, there is no well-defined low power methodology, nor are the industry’s low power verification tools equipped to handle custom designs. This article proposes a robust methodology to effectively verify the low power intent and suggests a combination of static and dynamic low power verification for verifying mixed-signal SoCs.

Low power verification methodology
Isolation, retention, and power switches are the important functionalities of power-aware designs which use the common low power techniques like power shutoff, multi-voltage, and advanced techniques like Dynamic Voltage and Frequency Scaling (DVFS), Low VDD standby, and biasing. The strategies for isolation, retention, and level shifter are specified in the Unified Power Intent Format (UPF) file. In dynamic low power verification, the simulator reads the UPF file during RTL elaboration and evaluates the isolation and retention strategies 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 dynamic simulation is the use of 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.

Designers usually specify the power protection techniques in the RTL. There should not be a condition where the global signals (clock, reset, and test_enable) or control signals (isolation and power switch enable) cross from the source domain to the sink domain, and source domain ON condition is not a superset of the sink domain ON condition. If these conditions exist in the design, they can cause functional issues because when source is OFF, signal cannot reach its destination domain. It becomes an important step to verify the protection device library attributes and power details defined in the library and satisfy the domain crossing requirements defined in the specifications.

Designers also must verify the difference between the power specification and design consistency. The ever-increasing complexity of the SoC power architecture is forcing the specifications to have large number of power state tables (PSTs). Static tools employ certain merging principles to merge PSTs. Inconsistent or incomplete specification of the PSTs can lead to a merged PST which may not satisfy the actual low power intent. This may lead to incorrect verification results. Dynamic simulation techniques and manual debugging of multiple PSTs can be very time consuming and inaccurate. Static tools can help to check inconsistency among the given PSTs by combining multiple PSTs into a single merged PST. The user-defined power net specification may lead to some of the power related issues like leakage and over consumption (for example, the supply net associated to the node is ON for some multi-voltage state of legal state table, causing leakage in the path). Similarly, a node driven by an ON domain can cause the over consumption of power if it drives a node that is OFF. Some of these problems can be detected quickly by static verification tools in the early stages of the design.

For custom logic, the starting point is a schematic which gets converted into a gate level Verilog netlist. There are challenges associated with this netlist, as it contains transistors, resistors and analog components which cannot be understood by industry leading verification tools.

Figure 1: ASIC low power verification flow and methodology

Figure 1. illustrates the widely used low power verification methodology for ASIC based designs. The scope of this article is limited to the verification aspects for low power verification using dynamic verification and static verification.

Proposed methodology
The proposed methodology leverages the static and dynamic low power verification starting at the schematic to the netlist stage (schematic converted directly to netlist). Both static and dynamic low power verification tools are used at the netlist stage. Since custom designs do not go through synthesis, place and route flows, where some of the low power inconsistencies can be caught, a robust low power verification is extremely important. Low power verification tools give multiple false violations when there are cross-over signals, which either originate or terminate at transistor pins. These violations must be carefully reviewed and then waived accordingly after considering the detailed schematic. Custom library files must be generated (using a bottom up approach) wherein the IP level designs (.lib/.db) get loaded into the higher sub-system and finally at the full-chip level.   For dynamic low power verification, behavioral models must be created for the schematic. Custom assertions for isolation and power switches must also be created.

Essentially, there are two flows. One for the ASIC blocks, which is the standard flow, and the other for the custom blocks. The overall flow for these hybrid designs is a combination of both these flows. Figure 2. shows a typical mixed SoC hierarchy. The top level is an ASIC block which instantiates a sub-system which is all custom design. The subsystem instantiates two other custom blocks. The “black-box” UPF approach is used wherein for the lower level blocks, a .lib/.db is created and is loaded inside the upper level blocks.

Figure 2 : Hybrid design hierarchy

Figure 3: Custom blocks verification

The ASIC low power verification methodology is well established. Figure 3. shows the methodology to verify custom design blocks using both static and dynamic verification methodology. For dynamic low power simulation, a behavioral model (BMOD) is created by the schematic designer. The power aware simulator uses this BMOD along with the UPF to perform various low power dynamic checks and provides PST coverage. The schematic is converted to a Verilog gate level netlist and the static verification tool uses this netlist and the same UPF to perform static low power checks. Once the dynamic and static low power verification is signed off for each custom block, a .lib/.db is created for it. For all such custom design blocks, a .lib/.db is similarly created.

At the sub-system level, a sub-system level UPF is created and all the lower level .lib/.db which are referred to as custom macros are then loaded (using the black-box methodology).

Figure 4: Full chip verification

The top level in this hierarchy is an ASIC block. This ASIC block goes through the synthesis and place and route stages and a P&R netlist is generated along with the full chip UPF. Both static and dynamic verification is then run on the full chip P&R netlist with the loading of the .lib/.db of the sub-system custom block as shown in Figure 4.

Conclusion
As mixed-signal and adaptive computing platforms are gathering momentum, low power verification is becoming increasingly challenging. The biggest challenge faced is that industry tools for both dynamic and static verification is not tailor-made for these custom designs. The custom designs start from the schematic and written out into a netlist using certain tools. Power intent creation for these netlist designs is tricky as there is no defined methodology for low power verification of custom blocks. The combined Synopsys static and dynamic low power verification methodology for mixed-signal designs ensures that real life bugs do not escape to silicon.