Gated clocks and clock enables in FPGA and ASICS

Please correct me if I am wrong. I have generally read that for FPGA's gating the master clock is a bad design practice and that one should use master clock & clock enable whenever circuit needs a divided clock and use a PLL for multiplying the master clock.

Does the same principles apply to ASIC designs as well ?

What are the safe design practices when circuit needs a divided or multiplied clock ?

• I'm a bit confused, you're asking about gating clocks in one sentence and multiplying/dividing them in another as if they are the same thing. Which one are you really asking about?
– Tim
Jun 20, 2013 at 1:22
• I think hes asking what is the best practices for clock gating in designs with divided or multiplied clocks. Jun 20, 2013 at 1:29
• @trav1s: thanks for correcting me. Pardon my confusing question. I want to know what are safe design practices when one needs divided or multiplied clocks in FPGA and ASIC design ? Jun 20, 2013 at 8:07
• So the assumption is that the clocks are phase-locked, right? Then they are on the same clock domain. Its a good question... Jun 20, 2013 at 8:11
• @trav1s: Yes your assumption is correct. You can assume that we have only one master clock and that we need to derive new clocks from it having the same phase as master clock. Jun 20, 2013 at 8:15

To answer your question, the same guidelines do not apply to ASICs and gated clocks are used very often to reduce power consumption.

In FPGAs, clock signals have dedicated routing resources that ensure low skew delivery of the clocks to fairly large areas of circuitry. If you try to gate the clock then the output of the gate will probably be forced to use normal logic signal routing resources, which can introduce significant delays and cause large clock skews. FPGAs are designed with some assumptions about how logic design should be done, and one of those assumptions is that you use clock enable signals rather than gated clocks. For common FPGAs the power consumption is enormous anyway so there is little motivation to gate the clocks.

ASICs are a much different beast. When you design an ASIC you have complete control over the gates and wires. You can safely create a gated clock and make sure that the gated clock signal is distributed properly. This is a very common technique for minimizing power consumption. For example, look at a modern microcontroller and you will see that you can, in software, turn the clock signal on and off for large chunks of circuitry such as a UART. The downside is that ASIC designers must use very expensive and sophisticated timing analysis tools to get this right.

Short answer: Gated clocks are very bad.
Avoid using multiple clocks when you can (called clock domains).
Research and implement clock domain crossing when you can't.
Learn about synchronous clock domains(related clocks) and asynchronous clock domains.

You are correct, it is highly recommended to use a single clock, and then pass enable signals around in your design to components that should be turned off or on conditionally, rather than gate the clock. You can also use an enable signal like you suggested to run a section at effectively a lower clock speed - more on that later.

The idea is to minimize the number of clock domains, and minimize the number of clock domain crossings. This absolutely holds true for ASICs just as it does for FPGAs, and even discrete logic circuits.

When all logic is performed with the same clock (with no clock gates) all the logic updates at the same time (with tiny bit of delay called clock skew)

This is great, because you can be sure that all inputs to all of your registers have been properly set up with enough time to be valid for the next clock, and you know all of the register outputs will be valid after the clock occurs. This is the basics of a synchronous design.

When you have two related events that occur on different clocks, even if they are closely related (like a register reading from another register, but from a gated clock) there is a risk that the data can be corrupted when it is transferred. This is called meta-stability.

If you need more than one clock, carefully define what needs to happen on each clock domain, and device what the communication requirements are. Do you need to send data in both directions, or do you only need to send data from the faster clock to the slower clock? Or maybe the slower clock to the faster one? How much data do I need to send, and how often should I send it?

There is a cross clock domain solution for each one of these cases, and each solution is slightly different. Fortunately, you don't need to re-invent the wheel (although you will probably need to re-write it)

FPGA 4 fun has a great intro to this:
http://www.fpga4fun.com/CrossClockDomain.html

• It would seem like, in many cases, one should be able to fairly easily guarantee that two clock domains will never have an active clock edge anywhere near each other. For example, one could have one clock domain respond to the rising edge of a master clock, and have another clock domain respond to any falling edge of the master clock which occurs when a particular output from the first domain is set. The propagation-delay allowance when crossing between domains would be much less than within a domain, but other than that what problems would there be? Dec 18, 2013 at 21:43
• That's an example of synchronous clock domains, where the two clocks are related to each other. Then all you need is to-from constraints with the minimum time between valid edges, in this case half the period (if the clock has a 50% duty cycle) Dec 20, 2013 at 5:23
• I wonder why I don't hear of such an approach being used terribly often? I would think that in something like an ARM, having peripheral subsystems run off a clock which was anti-phase of the main clock would make it easier to refrain from clocking the bulk of a subsystem if it doesn't have anything useful to do and the main CPU doesn't want to talk to it. If e.g. a UART doesn't have anything going on, it shouldn't be necessary to clock most of its registers during each cycle. Simply clock an input-synchronizer on the same clock edges as the main CPU, and clock the UART on... Jan 20, 2015 at 21:03
• ...those anti-phase cycles where either the CPU wants to talk to the UART, the synchronizer's output has changed, or the UART knows something useful is happening. On a lot of chips clocking the UART adds noticeably to the power consumption; it would seem that gating the clock should make it possible to eliminate most of that cost with no penalty other than, perhaps, needing to add an extra wait state on register reads and/or writes. Jan 20, 2015 at 21:05