System-level design

Making Power Intent Specification Easy

24. April 2018, 21:05 Uhr | Tom Anderson, Marketing Consultant, Amiq EDA

Fortsetzung des Artikels von Teil 1

Power Intent Specification

Recognizing the need for a standard format for to specify power intent, the industry spawned two working groups. The Silicon Integration Initiative (Si2) defined Common Power Format (CPF) and Accellera defined Unified Power Format (UPF), now standardized IEEE Std. 1801-2015. Though they differ in some details, all power intent formats are intended to clearly document aspects of low-power design and to provide the information necessary for automated tools in the design and verification process.

An IEEE Std. 1801 or CPF specification is a file distinct from the RTL design description. This is deliberate in order to separate the intent from the implementation and potentially allow a single power intent file to be used with multiple variations of the design. However, this means that it is very easy for the two descriptions to get out of synchronization as the design evolves. Module and signal renames as well as changes in the design hierarchy can render the power intent file outdated and cause verification errors.

Defining power intent with its own unique, purpose-defined format makes it independent of the particular design and verification languages in use. Again, this offers the opportunity to reuse a file, or at least a good portion of it, across multiple projects. The downside is adding yet one more entry to the long list of languages and formats for SoC development teams to learn. Perhaps for this reason, adoption of UPF has been slower than expected in some companies and industry segments.

IDE to the Rescue

An integrated development environment (IDE) for SoC design and verification can provide a great deal of support for learning and using power intent specifications. Code can be analyzed in context, reflecting the structure of the specific languages and formats being used. A compiler runs behind the scenes all the time, processing the source code every time the engineers make a change and building an internal database of the design and the complete verification environment. A typical IDE can accomplish a wide range of very useful tasks, including:

  • Performing syntactic checks on the code
  • Performing static analysis checks on the code
  • Highlighting and formatting the code
  • Compiling or interpreting the code
  • Linking to a simulator for debug

IDEs work equally well for any combination of programming languages, HDLs, dedicated verification languages such as e, the verification-related features of SystemVerilog, and power intent formats. With this knowledge compiled and available, the IDE can perform a much broader range of analysis and even offer suggestions to the designers and verification engineers as they enter or debug their code.

Intuitive Visualization

Perhaps the most obvious help that the IDE can provide in writing and verifying any sort of design or verification code, including a power intent file, is visualization. The IDE offers several views, including source code editor, hierarchy browser, and schematic. It is easy to navigate among these screens while following a signal or an element in the hierarchy. Color coding is frequently used as a way to visually link common elements across multiple views.

Figure 1 shows an example specifically relevant to low-power design. The IDE has read in the power intent specification as well as the other design and verification files and has determined the power domains. Each domain has a unique color that is shown in both the hierarchy browser and schematic views. This screenshot and the others that appear in the following examples are from the Design and Verification Tools (DVT) Eclipse IDE from AMIQ EDA.

Figure 1: The IDE uses colors to visualize power domains.
Figure 1: The IDE uses colors to visualize power domains.

In this example, most of the design is in the “PDcore” power domain, which is shown in green. The UART block can be turned off independently if not needed; the “PDuart” domain is colored red. A third domain (“PDsmc”) is purple in the browser, but at a level of hierarchy not currently displayed in the schematic view. Expanding down into the SMC block would show the lower-level blocks in the PDsmc domain in purple as expected.

  1. Making Power Intent Specification Easy
  2. Power Intent Specification
  3. Interactive Development

Verwandte Artikel