RTL Power Reduction Triathlon

Unless you’ve just come out of a week-long coma, you’ve been watching at least part of the Olympic Games in London. The years of training, the drama of competition, the thrill of victory… (you know the rest). Some contests come down to the smallest of margins to define who wins gold. The recent women’s triathlon is one such case. After a 500-meter swim, a 43-kilometer bike ride and a 10-kilometer run that went on for nearly two hours, the margin of victory for Switzerland’s Nicola Spirig came down to millimeters of advantage and a time difference not measurable by traditional Olympic timekeeping methods.

Now that’s close. We have such drama in EDA as well. At the recent Design Automation Conference in San Francisco, the lead story on John Cooley’s popular “Cheesy Must See List” declared a three-way tie for RTL power reduction. This recurrence of “three” is noteworthy. What’s the connection between the Olympic Triathlon and RTL power reduction? Read on…

A popular misconception is that RTL power reduction means just that—finding all methods to reduce power at RTL. This is not the case, and those who believe it is will likely not find themselves on the podium for the next SoC competition. Sure, RTL power reduction is a critical component of meeting power budget and winning the gold. It is a necessary, but not sufficient condition for success. By now you should be wondering what the other two pieces are. They are RTL power estimation and power verification.

Without a good map, compass or GPS gadget it is unlikely you will navigate effectively to the finish line in a long race through the wilderness. The same is true of power reduction. Without a good baseline of your design’s current power consumption, it’s hard to prioritize all the methods available for power reduction. The big picture matters, and solid, reliable, consistent power estimation will give you the GPS coordinates you need to find the best path to market. Sophisticated RTL power reduction techniques will present you with hundreds, perhaps thousands of options. Which ones are the most fruitful to pursue? A good power estimator will answer that question for you.

And what of verification? Why is that important? Power intent is now captured in (two) standard formats—CPF and UPF. As an editorial comment, I will say that this is one example of choice being a hindrance and not a benefit. Regardless, highly complex power intent is captured in one (or both) of these formats. Power domains are defined, and power management techniques are specified so that downstream tools can automatically implement the intended power management scheme.

What if there is an error in the power intent? What if your “golden” CPF or UPF isn’t golden at all, but a major source of implementation errors? If found during a two-to-three week place and route run, this isn’t a pretty picture. Power estimation also is affected by bad CPF/UPF. Accurate RTL power estimation is not possible in designs with multi-voltage and power domains without good CPF or UPF.

So RTL power optimization is a triathlon all its own. Estimation, verification and reduction. You need all three to be a winner. Find a vendor who can support the entire process, and you may win gold during your next SoC design.