Is it possible to have too much of a good thing? It might depend on the thing. Take vitamins, fresh air, and good schools, for instance. We definitely can’t have too much of these. On the other hand, consider beer, government, and spouses. Fewer is definitely better. But what about design automation and power efficiency? We can probably all agree that these are both good things. But can we have too much?

Perhaps the answer depends on the context. Take beer, for example. If your context is the moment at hand, clearly you can’t have too much. Running out is a calamity. But if your context extends to the next 24 hours, your answer might be different—especially the next morning. So much for beer. Could the same thing be true of design automation or power efficiency? To paraphrase Ben Franklin, a microwatt saved is a microwatt earned. If you can save 10 microwatts, that’s better than saving only 9, isn’t it? If the savings are “earned” automatically, what’s not to like?

Recent advances in design automation have made it rather easy to save power. The use of gate-level and now register-transfer-level (RTL) power optimizers has placed industrial-strength power optimization within the reach of all RTL designers. And it’s pretty easy to use. Load the RTL, set a few switches, run the optimizer, and voila: New functionally equivalent, but more power-efficient RTL code appears. Way cool!

Or is it? A deeper look uncovers some potentially inconvenient truths. For instance, not all power reductions are created equal. Some changes are minimally intrusive and easy to make, but they result in significant power savings. Other changes are more involved but reduce power only minimally. And what about clock-gating-induced clock skew? A few gated clocks are no big deal for a good clock tree synthesizer (CTS) to deskew. Throw a few hundred in, however, and the CTS problem becomes much more difficult—as measured by requiring a whole lot more time and effort to reach timing closure.

If you have unlimited time to close timing on a power-limited design, hey, you’re in good shape. But who has that? Most design teams have limited amounts of time and resources to complete the physical design and close timing independent of whatever netlist is thrown over the wall to them.

The deeper look at clock gating reveals the familiar law of diminishing returns—as in you do a little bit of clock gating and get a lot of power reduction. Do some more and you’ll get more reduction. If you go for it all and do a LOT of clock gating, though, you only get a modest incremental reduction. Now, with tremendous numbers of gated clocks, the design closure team is pulling out its hair trying to close timing. The team members have even begun to send you hate mail.

What’s a good engineer to do? Your project’s goals are to hit a power specification by a target date. With the power reductions causing back-end schedule slippages, however, the project may be in danger. Fortunately, the law of diminishing returns also provides the answer: Implement only those clock-gating opportunities that provide sufficient “bang for the buck.” Opportunities that don’t provide sufficient return with respect to power reduction should be ignored, thereby preventing the back-end designers from exploring all of the special symbols in their e-mails. The key is to precisely evaluate how much power reduction occurs with each opportunity and avoid passing too many clock-gated nets to the physical design team. Such discretion may not get you love letters. But it should enable you to hoist a celebratory brew with the whole team for a successful project.

With designers facing ever-increasing complexity with ever-decreasing schedules, it certainly seems that more design automation is better. But maybe clock gating is more like beer than vitamins. It seems like a good idea at the time, but the latent effects of too much are painful. Even worse, you don’t find out until later that you shouldn’t have opened that last bottle.