Electronic – Clock generation on FPGA pin

There are several advantages to this methodology that I can think of:

1. Clock Network - Firstly you only have one clock rather than three. This means that there is less competition for global and local clock routing resources. There are usually only a small number of low-skew clock trees, so minimising usage requirements can help routing.

2. ALM Restrictions - Depending on the structure of your ALMs/Logic Blocks, you may only be able to clock each block from a single clock - i.e. you can't have two registers on two different clock domains in the same block. If this is the case on your FPGA, then using only a single clock-enabled clock domain could allow logic to be more tightly packed in a design that has a high % of blocks used. Tighter packing can then lead to a higher chance of meeting timing as everything is closer together.

3. Clock Domain Transfer - Another important consideration is going between clocks. If you need to transfer data between the clock domains, then there are two options.

   If you have no reference between the clocks as would be the case if you divide the entire clock (you don't know which edge of the fast clock corresponds to the slow clock), then your transfer must be asynchronous which implies the additional headache of FIFOs for data, and synchroniser chains for control signals.

   On the other hand, if you use a clock enable to slow things down, you know exactly when the slow clock and fast clock are going to intersect - you know this by monitoring the clock enable signal. For example if you want to transfer data from your /10 domain to your /1 domain, then you don't need FIFOs to do it - you just say that the clock enable signal is also a valid signal. Because they are the same clock, no clock domain transfer is needed.

   It is possible to do domain transfers from PLL clocks if you can keep track of the clock edges - for example going from a /1 to a /2 and vice versa clock is easy because you can potentially compare the fast and slow clocks directly to synchronise. However this depends on the structure of the FPGA - some won't easily allow the clocks to be fed in to look up tables as data inputs.

4. Valuable Resources - In smaller FPGAs, PLLs are few and far between. For example Spartan-6 LX9 FPGAs if I recall correctly only have two PLL sites! Ideally you want to save these for things like external interfaces (LVDS, Memory, etc.) and not be using them for general clock division. Why use a valuable PLL for nothing but integer clock division when it is possible to do it in general logic.

   Furthermore, using clock enables, your division is simply a counter which can be implemented anywhere on the FPGA. PLLs on the other hand are located in specific areas. Say you need a local clock on one side of the chip, but the only free PLL is on the other side. You have to use not only a remote PLL, but also valuable global clock routing to get the clock all the way to the other side of the chip where it is used locally. If instead you build a counter for clock enables, it can be placed right next to the logic, thus reducing usage of valuable resources.

Those are just the reasons off the top of my head. I will try to thing of some more, and also I'll add in some "why is PLL favourable to CE" arguments as well.

In answer to your final point about timing. In practice, using a slow clock or a clock enabled fast clock doesn't affect routing too much. Really your designs should have all registers use the rising edge of a clock (or all use the falling edge) but not mix and match (except maybe in DDR I/O buffers). As a result, both clocks still have their sensitive edges at the same time. The fast clock has n times more, but the clock is not enabled, so these are ignored.

This means you can tell your timing analysis tool that either the clock is multi-cycle - i.e. only one of n cycles is valid - or you tell it that it is a slower clock with a narrow duty cycle. Both of these ways let the tool know that it can allow multiple fast clock periods of setup and hold time in its calculations (because the register values aren't going to change when the clock is not enabled).

You can drive the clocks from the FPGA if you want to reduce part count.

In general there are two downsides I can think of:

1. Clock jitter - the I/O pins of the FPGA will add jitter to the clock - this is basically where the clock edges aren't at exactly the right place and as a result the frequency varies by a small amount cycle to cycle (the average frequency is unchanged). However unless you are doing some super critical ADC/DAC/timing operation requiring sub picosecond accuracy, I doubt jitter is a concern. On a 20MHz MCU clock I can't see that this would cause a problem.

2. I/O Pin Requirements - you end up requiring more I/O pins from your FPGA to be used for clock distribution. If you have enough pins spare, that's fine, but make sure you test that your FPGA can feed a clock signal out of all pins you want to use. Some FPGAs have strict requirements on which pins can be used for clock signal output due to clock routing restrictions. Furthermore if you put your clock outputs on opposite sides of the FPGA you start to increase global clock network usage as the clock has to get to both sides of the chip. The easiest way to find out if this is an issue is to test-compile the design before sending the board off for manufacture.

Other than that, there are advantages to doing so:

1. Part Count - you need fewer clock distribution buffers or oscillators on your board. Sometimes you can daisy chain the clocks on MCUs if they can feed the clock back out again, but if not you would need to have either separate clock sources for each one which would increase part count. Using the FPGA as the distribution removes the need for discrete parts to do this.

2. Frequency Control - if you want to change the frequency of the MCU clock you can do the adjustments inside the FPGA (e.g. PLL to multiply/divide the frequency). That could be handy on a general purpose board where you might want to try out different designs. It would also allow different MCUs to run at different frequencies from just one oscillator.

There are possibly more as well, but that's what I can think of off the top of my head.

If you use the FPGA for this, then as I mention above, make sure to go over the design very carefully. Make sure that the I/O standards for the FPGA meet the requirements of the MCUs (and that you have the correct VCCIO voltage for the banks driving clock signals). Also make sure you test the FPGA firmware before you commit to manufacture. At the very least do a test compile to make sure that the design can be fit into the FPGA (both in clock resources and pin constraints) and meet the designs timing requirements.