Clock Enables and Power

Hi Jon, You could try using the Xilinx Power Estimator tool. I'm not sure that you're right that several separate clocks are better than a clock enabled design. Here's my reasoning. A major part of the power consumption is the energy used when a flip-flop changes state, so this is the same for both designs. So, the only difference between the two methods is the difference in power to charge and discharge the global clock networks for the former case, and the power to charge and discharge the clock enable signals in the latter case. I doubt that there's much difference. Why not try the power estimator and report back? cheers, Syms.

Actually, it may be the other way around. Driving the global nets is likely to take more power than driving the inputs of the FFs. By having multiple clocks, multiple sets of clock lines will require more power vs. the extra power of driving the FF inputs. I guess it may depend on the relative speeds of the clocks.

Which will take more power, a x N x F1 or (b + a x N) x F2 where a is the power coefficient for a FF input only, N is the number of FFs enabled at the lower speed and F1 is the high speed clock frequency; b is the power coefficient for driving a clock line and F2 is the low speed clock? Another way to express this is

A F2

- * N ------- B F1 - F2

Or the breakeven point would be

B * F2 N = -------------- A * (F1 - F2)

If N is greater than this, the enabled FFs will use more power. If N is less than this, the enabled FFs will use less power.

Obviously it is not a simple choice, but depends on several aspects of your design and the FPGA. The design will even affect A and B somewhat since FFs in more columns will require more column lines to be driven. I am not sure the calculator will consider all these effects. But the timing analyzer will. Too bad they can't combine the timing analysis with power estimation. I think their is a lot more design info available in the timing analyzer that could be used to calculate power consumption.

Expanding on this, there was data posted not long ago here, about the relative power of a 'true clock net', vs a signal used as clock. ISTR someone from Altera also mentioned a tool /floorplan approach, that trys to pack logic onto physical clock branches/stubs, and so avoids driving un-used clock lines. Would suit a stable design, and one where the saving was worth the effort

It is also good to see IC vendors starting to quote Clock power figures for Enabled and Disabled counters - that gives a feel for ratios of .CLK and .Q power capacitances. They could easily add this to the power estimator/post route analyser. Probably just needs customer demand.... :)

-jg

Clock Enables vs multiple clocks is a trade-off. If you are not concerned about power, then a single low0skew global clock and a "sloppier" network of CEs requires the least amount of thinking. Multiple derived clocks mean that you have to think about clock transfer from one clock domain to the next, you may have to use multiple PLL/DLL/DCMs.

In the extreme case, the use of CE will always save power. Think of a design with 10 flip-flops clocked at 200 MHs, the remaining 500 flip-flops clocked at 1 MHz. It sure would reduce power when the fast clock is only routed to the 10 flip-flops and the remaining 500 get that a slow clock (vs 200 MHz all over the chip, plus a1 MHz CE signal to most flip-flops)

Peter Alfke

Indeed, your customer/boss/well-being is almost always far better served by the

How about battery operation where power consumption is critical? (It turns into battery life.)

On the high speed/performance end, it might save a bit of heat. Going from X watts to X-2 might be critical. (Look at the games modern CPUs are doing to balance heat and performance.)

That reminds me of another issue. When you use a single clock with clock enables, you have to produce timing constraints to allow the enabled parts of the circuit to be routed with lesser constraints. But this is one part of the design process that is prone to error and has no method of verification that I am aware of. Of course some would say that you only need to "pay careful attention" to the timing constraints, but you can make that argument about *any* part of the design process. The point is that if you use separate clocks, the timing constraints are very simple and much harder to mess up. With a single clock and multiple clock enables, the timing constraints are not so simple and very easy to make mistakes.

What is really needed is a method of verification of timing constraints, just like we have verification of other aspects of the design process.

Hey Rick, Very true! The only exception could be that bit in the multi-clock design where the signals travel from one clock domain to another. If you go the 'enabled' route you need only worry about getting that enable correct. The multi-clock route could have a lot of places where signals cross domains, each needing attention in the timing constraints, both delay and skew. So, I'm a convert to the 'enabled' way. I use that circuit you stuck on here a few months back (ta very much!) to generate my enables, and I have a Perl script to work out the MAXDELAYs from the two clock rates, net delays and Tckos, Ticks. I've found that the NET "CLK_EN" TNM=FFS "CLK_EN_FFS"; is pretty reliable these days, especially if you use the 'direct_enable' directive in Synplify. It would be even nicer if you could group stuff into timing groups in the source code, but that's not really there yet. Which makes me think, why isn't easy timing constraints part of the RTL HDL languages? cheers, Syms.

Good question.

Recently I've been planing how to incorporate timing constraints in Confluence. Because Confluence has implicit clock enables, I think there is opportunity for semi-automated timing constraints. For example, designers would only have to place constraints on multi-cycle enables; the tools would then automatically determine which paths are multi-cycle. And since clock domains are also implicit, it should be farily straight forward to issue warnings on unconstrained false-paths.

Regards, Tom

-- Launchbird Design System, Inc. http: