System-Level Functional Verification and Power Analysis

With DAC and other events during May and June, I am only now wrapping up stuff I wanted to write about from EDPS in Monterey. Cadence's T.C.Lin presented about the importance of system-level power and ended up with a recipe of how to do it.

I won't bother to tell you why low power is important. You can insert your own paragraph here. Extra points if you mention both battery-powered devices and datacenters.

First, there is no one power. At a minimum there are:

• Peak power consumption (power delivery net must support)
• Maximum instantaneous difference in power (power supply noise, etc.)
• Maximum average power consumption (can be thermal issue)
• Average power consumption (battery life)
• Stand-by power consumption (battery life when nothing is happening)

Of course, at some level, the ideal is to reduce all of these. Primary approaches to doing so are clock gating, power gating, low-power libraries, DVFS. IEEE 1801 (a.k.a. UPF) is the way a lot of this is expressed, but also the coarse grained application is typically under software control, so verification cannot be done on the hardware in isolation. One challenge is that it is not clear where to look. Deep analysis requires long sequences to be run, more than might be needed for functional verification. The sequence needs to be long enough to cover enough "normal" behavior that the average power levels are meaningful, and also long enough that somewhere in the sequence peak power and, anomalously, high power for medium-length periods all show up. For example, it goes without saying that you can't measure peak power if your vectors don't happen to include the behavior that causes it.

So the recipe needs to leverage tools that work at the system level (which includes the software load) such as virtual platforms:

• Allow power management software and application software to run with the design to create real scenarios
• Controllability—let users specify run condition and environment for low-power operation
• Observability—provide full visibility of system behavior (design states, control signal values, etc.)

For functional verification:

• Mimic low-power control and circuitry behavior at system level
• Mimic power shutoff, isolation, retention
• Randomize flip flop and memory between power shutoff and restart (so that the state is not accidentally retained when it would not be in the real hardware)
• Be able to dynamically configure trigger conditions with low-power objects
• Self-checking of power intent, with error reporting on violations
• Record and report low-power control activity during tests

Power analysis takes time, not least because it is not always obvious which parts of a long sequence of operations (such as booting Android) are going to be the most problematic (peak vectors, peak power over a period maybe causing thermal issues, and so on). The power needs to be measured in the hardware, but with the software impact figured in. To deal with this:

• Do power analysis at a coarse level for a long period of time to identify areas of special interest
• Then do fine-grained power analysis on these windows
• Repeat the detailed analysis (you won't have to completely rerun the test)
• Hot spot analysis, combining physical information with power to determine where on the chip the most power is consumed
• Analysis tool needs to generate different files for different purposes
  
  • saif file for long time window for average power calculation
  • vcd/fsdb/sst2 for short peak power window for IR-drop and power noise analysis
• Both RTL and gate-level power analysis will be required

Next: CDNLive India

Previous: 200mm Fabs Awaken