Rethinking Low Power Verification

The discussion of low power verification has been centered around design complexity growth multiplied (or exponentiated) by growth in adoption of low power design techniques. The main objectives seem clear – ensure that:

1. The specification for the low power intent is valid
2. The low power implementation matches the specification, and that its architecture, structure and behavior is valid
3. Mission-mode behavior matches the functional spec

Today, the prevalent low power verification solutions are comprised of multiple point tools and capabilities used in discrete parts of implementation and verification flows. We’ve talked about the importance of native low power integration in all simulation and debug methodologies, and how deploying powerful low power checking tools early in the design flow provides big benefits. However, observations on customer flows and preferences identify a consistent challenge:

• Design teams create and understand the low power architecture and intent, but don’t always have the time or resources to thoroughly verify the complex behaviors of a low power SoC or IP block.
• Verification teams are tasked with achieving tough verification goals and metrics, but sometimes do not have all of the necessary contextual information for the low power intent and the intended (but not always fully specified) interactions between LP and mission mode behavior.

There will always be a level of specification and conveying of intent that must be done by and between all of the engineers on a low power design project. However, the EDA tools and design methodologies must evolve to help solve this challenge. While there are certainly fundamental technology improvements that must be provided (such as equipping designer-focused static checking tools to have performance and capacity to handle entire SoCs—needed to address the first bullet above), there must also be a basic rethinking of how all of these technologies are put together, interact and will be used.

We introduced a new verification tool a few weeks ago, and while it represents a broad SoC verification solution in one product, it is also the first step in how we now think the challenging low power verification problem needs to be attacked. It is not sufficient to provide low power checkers, or support low power design intent. It’s imperative that these capabilities are ubiquitously part of an integrated, convergent and tightly-correlated verification product that spans the SoC design process, from specification and implementation, all the way to handoff to emulation and prototyping. Unified support and understanding of low power design intent (UPF) needs to be a native part of the entire product, from the static checking and formal verification, through simulation and debug, and potentially to IP and handoff to emulation. This support and understanding must be much more than at the feature or technology level; it must be domain- and context-sensitive, allowing LP problems to be found in much earlier contexts, and accurately addressed with feed-forward and feedback flows. This will allow verification teams to work with design teams on our second observed customer challenge above.

Finally, having one product designed to verify all of the ways that low power bugs may manifest (usually in mystifying and unrelated ways…) eliminates the need for customers to procure, deploy, integrate and learn various point tools, and then try to figure out how to debug across the tools and flows. Going forward, we’ll describe both obvious and non-obvious cross-domain low power problems, and how the re-thought approach of this new tool to low power verification can be a far better solution.