This is the second part of my discussion with Paul Traynar, Apache’s PowerArtist guru. The first part discussed sequential reduction capabilities. Part I was here.
There are two big challenges with doing power analysis at the RTL level. Firstly, how do you get an accurate enough model of what the design will dissipate given that you only have RTL and not gates or anything even more accurate. And secondly, what vectors do you use since you probably just have a lot of functional verification vectors and not a carefully hand-crafted set of a few vectors that exercise the design just right.
The reason that this is important is that underdesigning the power grid or choosing a package that cannot cope with the power will lead to reliability issues. On the other hand, overdesigning the power grid or choosing an unnecessarily expensive package affects the competitiveness of chip or the final system.
PowerArtist contains two approaches that address these issues.
The first is PowerArtist Calibration and Estimator or PACE. This analyzes similar designs and looks as factors such as net capacitance, which library cells are used, how the clock-tree is implemented. There is a bit of a chicken and egg problem the first time through with a new process or a new design style, although usually data from earlier nodes can be used with some judicious scaling.
PACE turns out to be surprisingly accurate, with an accuracy at RTL within about 15% of post-gate physical design with parasitics.
The second approach in PowerArtist is the RTL Power Model or RPM. This is a reduction of the design to the critical factors that can then be used in a tool like RedHawk to analyze the power grid, package selection and perhaps even PCB noise issues. The challenge is to get vectors that represent realistic worst-case scenarios. This has to be done by using information in the RTL to identify power critical situations.
RPM is generated using whatever vectors exist. By examining how the vectors interact with the design it is possible to reduce the number of vectors to just a few critical ones that get the circuit into a critical state. For example, analyzing peak power in the presence of high average power (which tends to drain the decaps) or finding vectors that have very high changes in current when, for example, large parts of the design come out of clock-gating and start to toggle. The RPM captures how the circuit behaves during these critical periods which can then be used to stress other parts of the design and ensure reliability.
While Paul was over from UK he also recorded an educast on Power Budgeting Using RTL Power Models.Share this post via: