--- Quote Start ---
Ah thanks, that's good to know. Routing a 4-pin active crystal oscillator's 12MHz output to both the FPGA and the MCU was indeed what I meant.
About the FPGA's PLL: Does sending a 12MHz clock signal to the FPGA and using the PLL to multiply it by 4 for internal use has any disadvantage versus sending a signal already at 48MHz to the FPGA? As far as I've read, using a PLL to multiply the input clock only uses the PLL subsystem as far as resources, and I didn't see anything that would suggest: "If you can input a signal already at the frequency you need, do it instead of using a PLL".
--- Quote End ---
If the external clock signal is of reasonable quality (reasonably low jitter, close to 50/50 duty cycle) then just buffering it and using it internal to the FPGA is acceptable. If there is excessive jitter, or the duty cycle is very low, then running it into a PLL to 'clean it up' is probably a better choice.
From a future-proof point of view, running even a good input clock into the PLL, and generating the same output frequency (for now) is not unreasonable, if the PLL would never be used otherwise. Sometime later when you decide to change the internal frequency (due to a functional upgrade, for example) having have run the clock thru a PLL will have proven to be a very useful bit of foresight.
So I would use the PLL, even if for now it is not absolutely necessary. It may be of some benefit in the future.
Honored Contributor
