Semiconductor Devices Call for Power-Aware Debug
Power-aware debug allows engineers to understand a design's power intent and track down any bug
By By Bindesh Patel, SpringSoft USA
Power-format standards like the Common Power Format (CPF) or Unified Power Format (UPF) have evolved as a means of dealing with the power concerns confronting today's sophisticated semiconductor designs in a more structured fashion. Both standards use TCL side files, which allow the engineer to describe the power "design." These formats, for example, allow users to specify power domains, isolation nodes, retention nodes, level-shifters, and other power-related rules. Power-format standards allow one power definition to be used throughout the design, verification, and implementation stages of the cycle. On the flip side, they also increase the complexity associated with debugging designs that are verified using this power intent files. Effectively addressing such complexity requires a debug platform that can expedite the comprehension and of power-related errors. But which debug platform and what capabilities should it feature?
Challenges Ahead
In order to better evaluate viable debug platforms, it's necessary to first take a step back and examine the key challenges in debugging a power-aware design: comprehension of power intent in unfamiliar CPF and UPF code and debugging power-related errors. The basic problem is this: Many system-on-a-chip (SoC) designs now include a range of power-saving features that must be verified for proper operation by the verification engineer. But what happens when a power-related error is found during design verification? Debugging the design is the obvious next step. Unfortunately, it's not nearly as straightforward of a process as it may sound.
To begin with, the verification engineer faces difficulty in simply comprehending the power intent in the CPF and UPF code. CPF and UPF specifications are often written by system- or chip-level engineers. Comprehension of this code is key to understand how it may have impacted the design (and verification). A sub-block of a hierarchical RTL design, for example, can have multiple power domains—each with different rules for power on and off. Each power domain requires different rules for retention cells, level shifters, and isolation cells. As a result, the all-on functionality with which RTL engineers are familiar may behave differently during power-aware simulations. This possibility makes it all the more crucial that they comprehensively understand the "power intent" related to their blocks.
The verification engineer also faces an arduous challenge when it comes to finding the root cause of a bug. Conceivably, it could be caused by RTL functions or the behavior defined in the power specification code (UPF or CPF). As an example, consider an 'X' value in a waveform during power-aware simulation. The value could mean "power off," but it could also be a bug caused by structural errors like missing isolation cells or control sequence errors (e.g., an incorrect save and restore sequence). Thus, a simple "X" value in the waveform doesn't provide any indication of where it came from or its cause. To locate the root cause, the engineer has to trace the "X" back to both the RTL source code and power-intent files.
Power-Aware Debug Requirements
A debug platform that incorporates sophisticated automation technologies and open architectures can be effectively used to deal with the challenges of debugging power-aware designs. In general, the solution should expedite the comprehension of power intent. It should then automate the process of tracing, visualizing, and analyzing the source of power-related errors. While no one solution is ideal for everyone, there are a few criteria that can help simplify the decision-making process.
To ensure that the RTL engineer can fully comprehend the power-intent code, the solution should—at a minimum—allow the engineer to ascertain the power domains and power-domain modes related to the blocks on which he or she is working. Additionally, the solution should ideally offer the following functionality:


