Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
905 Views

48Mhz XTAL or 12MHz thru PLL x4?

My circuit already has a crystal that outputs a 12MHz signal to the MCU, which then PLL it to 48MHz internally for use. Since I also need 48MHz on the MAX 10 10M02 FPGA, I was wondering why not simply use the same crystal signal for both. 

 

First question is, can I use the same signal from the same crystal for both devices, the MCU and the FPGA? I can't see why not, but then again I'm still an Altera Pupil :oops: 

 

And if yes, are there any disadvantages in sending a 12MHz signal to the FPGA and PLL it x4 to the main clock versus sending a signal at already 48MHz?
0 Kudos
4 Replies
Altera_Forum
Honored Contributor I
84 Views

 

--- Quote Start ---  

My circuit already has a crystal that outputs a 12MHz signal to the MCU, which then PLL it to 48MHz internally for use. Since I also need 48MHz on the MAX 10 10M02 FPGA, I was wondering why not simply use the same crystal signal for both. 

 

First question is, can I use the same signal from the same crystal for both devices, the MCU and the FPGA? I can't see why not, but then again I'm still an Altera Pupil :oops: 

 

And if yes, are there any disadvantages in sending a 12MHz signal to the FPGA and PLL it x4 to the main clock versus sending a signal at already 48MHz? 

--- Quote End ---  

 

 

1) By 'crystal' I assume you mean a crystal oscillator (an active 4pin device that outputs an LVCMOS, for example, signal). If so, yes it would work. You could route the 48MHz signal to both the MCU and the FPGA. 

 

If you really mean a discrete 2pin passive crystal, the answer is NO. That will not work. 

 

2) Sending 12MHz to the FPGA and having it do 4X multiplication to 48MHZ, and then using that internal to the FPGA, and sending 12MHz signal to the MCU via a pin should work as well (the 12MHz could be a copy of the 12MHz input, or the 48MHz divided by four). Would just have to make sure the I/O levels are compatible. 

 

The one gotcha might be on reprogramming of the FPGA; the output to the MCU will likely be disabled during FPGA programming. So the MCU clock would disappear then. This may or may not be a problem, it depends on your application (ie, if the MCU is responsible for reprogramming the FPGA). 

 

So I suspect using a 12MHz external crystal oscillator, and sending the output to both the MCU and FPGA (where it then gets multiplied by 4X internally) is probably the best overall solution. A crystal oscillator can certainly drive two loads.
Altera_Forum
Honored Contributor I
84 Views

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".
Altera_Forum
Honored Contributor I
84 Views

 

--- 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.
Altera_Forum
Honored Contributor I
84 Views

That's great information. Thanks, I'll do that.

Reply