Should I use an FPGA output for an MCU Clock?

Question

We are laying out a board that was designed ages ago, the main purpose of the update is for part obsolescence. The board has several PIC uC's on it as well as an FPGA. Each of the PIC's needs a clock and the system has a 20MHz CTS oscillator for this purpose. Is there any reason we shouldn't use the FPGA to generate these clock signals? The FPGA is replacing other digital logic on the board but I'm not sure if there are issues with clocks in particular.

Besides the fact that the uC's would need to come up after the FPGA was all done coming out of reset are there other reasons not to reduce parts count in this way? (And no I can't use the FPGA to replace the PIC's).

Answer 1

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.