Low Power Verification Shifting Left

I normally think of shift left as a way to move functional verification earlier in design, to compress the overall design cycle. But it can also make sense in other contexts, one particularly important example being power intent verification.

If you know anything about power intent, you know that it affects pretty much all aspects of design, from architecture through verification to PG netlist. If the power intent description (in UPF) isn’t correct and synchronized with the design at any of these stages, you can run into painful rework. At each handoff step you will carefully verify, but design and power intent both iterate and transform through the flow so keeping these aligned can become very time (and schedule) consuming.

One important step towards minimizing the impact is to ensure that interpretation is consistent across the design flow. UPF is a standard but that doesn’t guarantee all tools will interpret commands in exactly the same way, especially where the standard does not completely bound interpretation. Which means, like it or not, closure between synthesis, implementation and verification in mixed vendor flows is likely to be more difficult. Not to say you couldn’t also have problems of this kind in flows from a single vendor, but Synopsys have made special effort to maximize consistency in interpreting power intent across their toolset.

A second consideration is how you verify power intent and at what stage in the design. There are static and dynamic ways to verify this intent (VC LP, and VCS NLP power-aware simulation,). Each of these naturally excel at certain kinds of checks. You couldn’t meaningfully check in simulation that you are using the appropriate level shifters (LS) wherever you need LS, but you can in VC LP. Conversely you can’t check the correct ordering and sequencing of say a soft reset in VC LP, but you can in power-aware sims.

Naturally there are grey areas in this ideal division of techniques and those are starting to draw more attention as design and verification teams push to reduce their cycle times. Simulation is always going to be time-consuming on big designs; simply getting through power-on-reset takes time, before you can start checking detailed power behavior. As usual, the more bugs that can be flushed out before that time-consuming simulation starts, the more you can focus on finding difficult functional bugs. This is why we build smoke tests.

In low power verification this is not a second-order optimization. Power aware sims can take days, whereas a VC LP run can complete in an hour. For example, an incorrect isolation strategy could trigger X-propagation in simulation, which burns up not only run-time but also debug time. Improved static checking to trap at least some of these cases then becomes more than a signoff step – it optimizes the dynamic power verification flow. Hello shift left.

This grey area is ripe for checks. Some already provided by VC LP include checking whether a global clock or reset signal passes through a buffer (or other gate) in a switchable power domain; this can obviously lead to problems when that domain is off. Similarly, a signal controlling isolation between two domains but sourced in an unrelated switchable domain will never switch out of isolation while that domain is off. These are the kinds of problems that can waste simulation cycles. Synopsys tells me they continue to add more checks of this type to minimize these kinds of problems.

Another capability that I have always thought would be useful is to be able to check UPF independent of the RTL. After all, the RTL may not yet be ready or it may be rapidly changing; that shouldn’t mean that the power intent developer is stuck being able to write UPF but not check its validity. VC LP apparently provides this capability, allowing you to check your UPF standalone for completeness and correctness; given the power/state table definition, are all appropriate strategies defined, for isolation and level-shifters for example?

Prior to implementation, VC LP will run predictive checks for DC/ICC2, looking for potential synthesis or P&R issues, such as problems with incorrect or missing library cells and signal routing. And of course for low power signoff, it will run checks on the PG netlist looking for missing or incorrect connections by power/ground domains. Still the signoff value you ultimately need, but now adding capabilities for shifting low power verification left. You can learn more about VC LP HERE.