# Create multiple clocks on FPGA or create clock dividers

I am thinking in a design and I have a doubt about clocking. What is better? Do I create different clocks or create clock enables and only use one? What is the best option in terms of resources? What is more reusable?

Thanks!

• Why do you need several clocks? How are they different (Phase/Frequency?)? Clock enables are normally the source of a lot of troubles..... You need to explain your application more in details – Botnic Dec 13 '16 at 10:26

There are different reasons why someone wants/needs to have different clocks in a design. Most of the time I try to keep all my design running with the same clock.

When working with several clocks, we talk about different clock domains. Each signal has its home clock domain. These clock domains are needed by the routing tools to find a layout that meets the timing (= maximum acceptable delay).

If a signal crosses from one clock domain to the other, it is highly recommended to use some crossing logic in order to avoid problems like metastability. Most of the time this is done by FIFOs or Dual-port-BRAM. (More informations about this topic can be found here: http://www.gstitt.ece.ufl.edu/courses/spring11/eel4712/lectures/metastability/EEIOL_2007DEC24_EDA_TA_01.pdf)

Often external interfaces are driven by theire own clocks. In this cases we can not avoid having different clock domains. Use the interface clock to sample the data and maybe do some preprocessing and then migrate the data to the system clock.

Clock Enables: In FPGA designs, clock enables lead to gated clocks and should be avoided by all means. Clocks are routed on special nets. These clock infrastructure takes care of delivering the clock signal to each gate at the same time. After adding logic into the clock path (for example an enable) the clock signal will be routed on normal signal paths. The place-and-route process will have a hard time to make sure, all timing requirements are still met. Better than enabling the clock, would be to make an ENABLE entry to your logic. The clock stays untouched, but the logic knows if it has to react or not. In VHDL this would look something like this:

enable_example: process(clk_C)
begin
if rising_edge(clk_C) then
if enable_DI = '1' then
end if;
end if;
end process enable_example;


Resources: In therms of resources we need to specify a little bit what kind of resources. There are mainly 3 types of resources we could talk about:

1. Time: Running everything with the highest clock makes your design easy to read and understand but may lead to bad timing. High frequencys allow only short routing and logic propagation delays. The lower your clock, the better the chance of achieveing timing constraints.
2. FPGA Resources: Modern FPGAs have enough clock nets that you don't need to worry about running out of nets in most cases. But crossing clock domains may need quite some space (FIFO in BRAM or different logic).
3. Energy: (I don't have enough knowledge to give a good answer to this)
• Thanks for your response! It was very useful! Sometines I used the same as your VHDL code snippet, and my enable signal/variable was obtained with a counter of clock cycles . For example if I have a clock of 1MHz, I count 1000 times to put my enable signal to 1 and then the logic will be executed with a 1kHz frequency. So, as I understood, is better to add that code snippet than two clocks: 1MHz and 1KHz. – ferdepe Dec 14 '16 at 11:47
• Yes. Specially with such low frequencies. Your PLL will not be able to produce 1kHz. Timing issues will not be a problem either. – Botnic Dec 15 '16 at 14:58

Using clock enables and making the data rate independent from the FPGA-clock is more efficient in terms of resources.

If you have different clock-domains, you will need a lot of clock-domain-crossing-IP (depending on how many connection points there are). This will typically be FIFOs. On the faster side of the queue, flow-control is needed anyway.

The circuitry for glitch resistent enables is typically present on each FPGA register, so make use of it. Using a standard like Avalon ST fosters good design practices. The wiring for valid- and rdy-signaling uses additional routing resources but will have less impact than a bunch of FIFOs.

There is one notable exception: If your design interfaces to off-chip logic with synchronous data transfer (like an ADC that gives a value on every clock), then it is common to have a little island of your design running on that external clock. Keep that island as small as possible and insert a FIFO to adapt to FPGAs clock domain.