WP_Term Object
(
    [term_id] => 34
    [name] => Ansys, Inc.
    [slug] => ansys-inc
    [term_group] => 0
    [term_taxonomy_id] => 34
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 261
    [filter] => raw
    [cat_ID] => 34
    [category_count] => 261
    [category_description] => 
    [cat_name] => Ansys, Inc.
    [category_nicename] => ansys-inc
    [category_parent] => 157
)
            
3dic banner 800x100
WP_Term Object
(
    [term_id] => 34
    [name] => Ansys, Inc.
    [slug] => ansys-inc
    [term_group] => 0
    [term_taxonomy_id] => 34
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 261
    [filter] => raw
    [cat_ID] => 34
    [category_count] => 261
    [category_description] => 
    [cat_name] => Ansys, Inc.
    [category_nicename] => ansys-inc
    [category_parent] => 157
)

Early RTL Power Analysis and Reduction

Early RTL Power Analysis and Reduction
by Daniel Payne on 03-26-2014 at 4:48 pm

Power analysis and reduction for SoC designs is a popular topic because of our consumer electronics dominated economy, and the need to operate devices on a battery source for the maximum time before a recharge. Just from my desk I can see multiple battery-powered devices: Laptop, tablet, smart phone, e-book reader, bluetooth headset and a bluetooth mouse.

In my design flow I could wait until the RTL code was complete, synthesis finished and just run power analysis on the gate-level netlist, however it would be difficult to re-factor my RTL code to get any power reduction because of time-to-market pressures. An improved design flow would be one that accounted for power analysis and reduction at an early stage, like RTL entry. Apache/ANSYS is one EDA company focused on this challenge, so I viewed their 35 minute online educast today.

You can say that designers are faced with a Power Gap because the features that we want to include in our designs can quickly overcome the capabilities of our battery or specifications.

An RTL-based power flow allows early design trade-offs, can simulate 1 Million instances in a few minutes, and can be readily debugged. Comparing a gate-level to RTL level power analysis one customer design took about 22 hours for gate-level power analysis, while the same RTL power analysis required only 22 minutes, quite the speed up in time to get results.

Analyzing power at the RTL level is quicker to debug, as the below diagram shows that the Adder is a source for greatest power usage on the left side, while the right side is a confusing mass of gates at the instance level.

The specific EDA tool from Apache is called PowerArtist and it has three main features:

  • RTL Power Analysis

    • Average or time-based
    • Power-critical vector selection
    • Regressions with a TCL interface
  • RTL Power Reduction

    • Clock, memory or logic
    • Analysis-driven automation
    • Interactive power debugging
  • RTL links with Physical

    • Physical-driven RTL power accuracy (PACE)
    • RTL-driven power grid integrity (RPM)

The steps in a design-for-power methodology include:

[LIST=1]

  • Perform design trade-offs
  • Profile activity for power
  • Check your power versus the budget
  • Debug your power hotspots
  • Automatically reduce power
  • Monitor your power across regressions

    Using this 6 step methodology STMicroelectronics was able to realize a 32% reduction in idle power on their ARM core based subsystem, verify that the power numbers at RTL were within 15% of a post-placed netlist, and optimize their power grid using power integrity patterns.

    When using PowerArtist the tool inputs are: RTL Code (VHDL, Verilog, SystemVerilog), clock definitions, input waveform activity, a capacitance model, power domain definitions in UPF or CPF, and power models in Liberty format.

    Power accuracy at the RTL level is ensured by doing a calibration step called PACE (Power Artist Calibration and Estimation) that starts with a post-layout design and then creates RTL power models.

    Power reduction first starts during your interactive debug process that shows both graphically and numerically which RTL blocks are consuming the most power with each set of stimulus. Once you know which blocks consume the most power you can begin to make manual decisions on RTL trade-offs to reduce power. A second approach is to allow automated techniques to change the RTL code creating a lower power version.


    Graphical Power Debug Environment

    Using the analysis from PowerArtist you can expect that a handful of RTL changes will account for about 50% of your power savings, and that with the next 100 RTL changes you achieve about 99% of your power savings. Algorithms in PowerArtist also work on sequential power reduction. You can even create custom power reports by using Tcl scripts.

    RTL power regressions are another technique for you to track the power estimations over design time. You could run power regressions daily for your block-level and weekly at chip-level to monitor power changes so that no power increases suddenly appear.

    Three tools from Apache are used in an RTL-driven power integrity flow: PowerArtist to analyze power over millions of cycles, RedHawkto analyze power-grid using a few dozen worst-case cycles, and finally Sentinel SIwave for signal integrity analysis across the package design.

    Apache/ANSYS has engineered a collection of EDA tools that enable power analysis and optimization starting at RTL development, and continuing into the package design. Starting power analysis at the earliest time in your design process will allow for the largest power reductions, instead of waiting for gate-level analysis. View the full 35 minute educast here.

    lang: en_US

    Share this post via:

  • Comments

    There are no comments yet.

    You must register or log in to view/post comments.