Power-Up Low-Power Verification

By Adam Sherer
When facing low-power verification in the SoC world, everyone could use a few power-ups just like Nintendo’s little plumber, Mario. Sure, Mario could run and jump through a lot of terrain, but when he hit some new challenges he could rely on some new tools and techniques to get him through.

Completing your first SoC with a single power control module (PCM) and domain is like that first Mario world. You probably built a directed test and simulated the design with the power format examining the output waveforms. Along the way you may have discovered errors in control timing, signal connection, inadequate retention, and more. Perhaps you even wrote an assertion to formally prove the PCM. A nice power-up, but still this is a relatively tame project.

Your next SoC has four PCMs, three power shut-offs and one voltage scaled at three levels. As you start to roam around this new SoC, it seems like just a bigger version of the first one. In the first SoC you had two power states and now you have nine. Nine is the summation of the power states for the three PSO PCMs (two states each) and the voltage-scaled PCM (three states). Sure, like the plumber you have a time constraint but you’re skilled now so working faster with your debug knowledge should be enough. Unless there is some hidden factor you haven’t seen.

What you missed is that the power states grow arithmetically but the power modes grow geometrically. Where you had only two possible models in the first chip, now you have 24. The reason is that the modes represent a combination of the states so you have to multiply them: 2 x 2 x 2 x 3. To make matters worse, you know that some of those modes are illegal so now you have to verify that each legal mode operates properly and that the system doesn’t allow itself to enter the illegal modes.

This is where we need to power up with a verification plan and some UVM sequences. The verification plan codifies the legal and illegal modes and enables us to use coverage to measure when we have tested each mode. Because the modes may need complex, multi-cycle signaling to set-up in simulation, applying UVM transaction sequences can make the testbench development more efficient. Now that the SoC is verified in each mode, we will likely want to make sure that the specified arcs between each mode are properly verified. This verification of the power control state-machine may take more cycles to run than we can practically achieve with simulation, so a power-up to hardware-based acceleration makes sense.

Throughout each of these new steps in low-power verification, we have debug to help identify the source of errors so that they can be fixed. If that’s what we were doing post-processing debug, we probably needed a few simulation runs to get the right set of probes to find those bugs. With our new SoC and its additional PCMs, those cycles are longer, taxing our debug efficiency. The last power-up we need is interactive debug, so we can set break-points close to our errors and use the full data available in the simulator to visualize the power format and signal data to find the erroneous code quickly.

As you move into more complex power-aware SoCs, consider adding some low-power verification power-ups to your toolbox. Each one addresses a specific class of bugs presented when there are multiple PCMs. Removing those bugs quickly and easily will improve the quality of your power-aware devices and may even power-up Mario, should his application be running on that device!

—Adam Sherer is verification product management director at Cadence.