You are in:  Design | EDA and IP


Read The Magazine

Issue: 16 - 22 Dec, 2009
Get Electronics Weekly

Debugging power-aware semiconductor designs

Monday 29 June 2009 10:47

Emerging power format standards allow one power definition to be used throughout design, verification and implementation.

But they also increase complexity in verification and debugging. This article describes issues engineers face in debugging power-aware designs and the requirements for a solution.

For years, designers would implement power management directly in the gate-level netlist. But it is usually too late and too expensive to redesign issues found there. To verify power behaviour earlier, engineers began modelling power management in the RTL code. However, this is becoming impractical as power management is required on more modules, and the required power modes and transitions are growing quickly.

As a result, two standards have emerged for expression of power intent: the Common Power Format (CPF) and the Unified Power Format (UPF) both use TCL side files that allow engineers to describe the power “design”, such as: creating and managing power domains, specifying isolation and retention, setting up level shifters, and defining power-­related rules.

Debug challenge

The challenge for debugging in a power-aware design is that the root causes of bugs could reside not only in the RTL but also in the power intent files. 

For example, an “X” in a waveform during power-aware simulation can mean “power off”, or it could be a bug caused by structural errors such as missing isolation cells, or control sequence errors such as an incorrect save and restore sequence. 

A simple “X” value in the waveform does not provide any indication of where it is from or what might cause it. Engineers need to trace back in both the RTL source and the power intent files to locate the root cause.

For example, in figure 1, after investigation of the power intent and RTL source code, the “XX” values found on signals B and C which reside in a “power on” block are caused by a lack of isolation cells for signal A from the driving “power off” block which propagates the “XX” value to signals B and C. 

Design automation tools

Design automation tools help engineers save time by automating tasks that are either too complex to do manually, or that require so much tedious, detailed, or repetitive work that they take time away from more valuable work. Debug is not impossible without automation, but it is extremely time consuming.

Debug automation shortens the time required to fix bugs by helping engineers quickly visualise, trace and understand complex logic.

The foundation of a solution for power-aware debug is automation that bridges the gap between RTL and CPF/UPF so that engineers can freely trace behavior without regard for where it was specified.

The first requirement is visualisation of power domains and power states/modes so the behaviour of power modes or states can be easily grasped. A special view for UPF/CPF can help reveal power intent such as switch, retention, isolation and level shifter rules.

The second requirement is that power intent must be annotated on the traditional RTL, schematic and waveform views so that it can be correlated to design blocks for comprehension of which blocks belong to which power domains and which signals are retention or level shifters to a power domain.

Cross-probing

Support for cross-probing between the UPF/CPF power view and the RTL, schematic and waveform views lets engineers locate design or power objects in any other view.

Taking this further requires debug automation that can automatically process the combined intent of the RTL and the CPF/UPF to speed the process of locating, isolating, and understanding the root cause of design behaviour.

This would include:

  • Automatically locating the root cause of a bad value in either the RTL or CPF/UPF code.
  • Automatically locating drivers and loads in CPF/UPF as well as RTL.
  • Unrolling paths through different power domains and easily identify retention, isolation or level shifter signals in the unrolled paths.

Isolating the signals driven by CPF/UPF so that debugging can be directed to trace into the CPF/UPF.Although the complexity of designs increases when power requirements are specified using the CPF and UPF standards, debug automation techniques are advancing to help engineers keep ahead of the comprehension curve.

Putting the visualisation and tracing of these formats on the same plane with HDLs is the foundation and the minimum requirement for productive debug automation for power-aware designs.

Bindesh Patel and Amanda Hsiao are technical marketing managers at SpringSoft

Recommend this article

View the ElectronicsWeekly.com topic zones:

Electronics Weekly Zone - PowerElectronics Weekly Zone - Test & Measurement


 

Sign-up for the ElectronicsWeekly.com newsletters:

Electronics Weekly newsletters

Resources

Most Viewed

Blog roll