Low-power debugging made easy

By Himanshu Bhatt and Nishant Patel |  No Comments  |  Posted: February 6, 2019
Topics/Categories: EDA - Verification  |  Tags: , ,  | Organizations:

UPF provides a useful way to describe the power-management strategies that should be applied to a design, but using it introduces a number of challenges during low-power debugging.

The increasing complexity of power-aware SoC architectures makes it important to find efficient ways to debug their low-power elements. UPF provides a useful way to describe the power-management strategies that should be applied to a design, but using it introduces a number of challenges during low-power debugging.

During design, the elaboration of the design’s functionality should go hand in hand with the development of the power-management strategy and its expression in UPF, but it is likely that the schedules for these related efforts will differ. The result is that the design and its related UPF files almost always need cleaning up once they are brought together.

When it comes to verifying the low-power aspects of a design, it can take a long time, especially when working at gate level, to bring up a power-aware simulation. Most of the issues in the UPF files are related to their syntax, accuracy and/or completeness. This can create a lot of X states, which are time consuming to debug in simulation, usually taking multiple iterations to complete.

During prototyping, it takes a lot of effort to debug power related issues. And during implementation, there are often UPF-related or multi-voltage cell-related errors that also take multiple iterations to clean up.

Figure 1 shows one way to address these issues, using a low-power static verification methodology that spans from RTL to signoff.

New use models for low-power static checks

Figure 1 New use models for low-power static checks

The methodology is based on the premise that addressing static low-power checks early in the verification process can save weeks of effort later. Figure 2 illustrates this.

Using static low-power verification upfront

Figure 2 Using static low-power verification upfront

In one user case study, the low-power verification issues broke down as follows:

  • 35% – insufficient UPF intent e.g. missing CSN, missing retention elements, objects not found
  • 20% – UPF syntax issues e.g. generate block naming, handling of wildcards
  • 20% – inconsistent UPF intent e.g. gaps between signoff UPF and DV/Sim UPF
  • 15% – not meeting prerequisites for simulation e.g. missing libs, search_path incorrect, different models, missing DB
  • 10% – others

In this case, the users claim that applying static low-power verification up front saved four weeks from their low-power verification schedule. 

Bringing static low-power verification earlier in the debug process also creates an opportunity to apply predictive checks. Some of these are detailed in Figure 3.

Catching low-power bugs earlier in the design with predictive checks

Figure 3 Catching low-power bugs earlier in the design with predictive checks

Figure 4 gives an example of a predictive check that can reveal a UPF issue, which otherwise would need to be debugged at the simulation stage.

Predictive checks at RTL level

Figure 4 Predictive checks at RTL level

Multi-rail macros (MRMs) have more than one primary power pin. One of the pins can be connected to the primary supply of the power domain, but the remaining supplies must be connected explicitly using the connect_supply_net UPF command. Not doing so results in a simulation issue that can be a time-consuming, iterative process to find and fix, especially if there are multiple MRM cells. A low-power static checker can flag this issue “predictively”, so it can be fixed upfront to save hours of debug simulation time.

Low-power design also demands rigorous thinking about how the various functions and blocks within an SoC will move in and out of low-power states, and how these transitions will interact. One way to express these transitions is in a power state table (PST). Debugging these PSTs is a big challenge for design and verification engineers, which becomes even more complex when the design calls for PSTs to be merged. Figure 5 lists some of the new debug capabilities in Synopsys VC LP that address the PST debug issue.

PST analysis and debug functions

Figure 5 PST analysis and debug functions

Figure 6, below, shows how these commands can reveal PST issues such as illegal combinations of states

Complex PST debug

Figure 6 Complex PST debug

The static low-power verification debug techniques described here should both speed up the verification of low-power SoC designs, as well as making the verification robust enough to prevent subtle bugs escaping into silicon. To learn more about Synopsys VC LP, visit here.

Author

Himanshu Bhatt is a senior staff applications engineer with the low-power verification team in the verification group at Synopsys. He has more than 18 years of experience spanning the EDA and semiconductor industries, including ASIC design and verification using various verification methodologies such as eRM, UVM, CPF, UPF, formal, equivalence checking. He is currently working as a low power verification specialist to help designers define and refine their low power verification flow.

Nishant Patel is a senior applications engineer II for the low power verification team in the verification group at Synopsys. Patel has more than eight years’ experience in the EDA and semiconductor industries, including ASIC design and verification experience using various verification methodologies such as CPF, UPF, and equivalence checking. He has worked as an SoC power architect and completed end-to-end power signoff for two chips during his design  career. He is currently working as a low power verification specialist and driving VC LP growth in North America.

Company info

Synopsys Corporate Headquarters
690 East Middlefield Road
Mountain View, CA 94043
(650) 584-5000
(800) 541-7737
 www.synopsys.com

Comments are closed.

PLATINUM SPONSORS

Synopsys Cadence Design Systems Siemens EDA
View All Sponsors