Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
Объявления
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.
21615 Обсуждение

Aligning a derived PLL clock with an external clock

Altera_Forum
Почетный участник II
2 264Просмотр.

Hello, 

 

previously i asked (http://www.alteraforum.com/forum/showthread.php?t=5439) about using a PLL to synchronize two clocks and received some excellent advice. 

 

My original question: 

 

 

--- Quote Start ---  

I have a 120 MHz external clock entering the FPGA (Stratix II). Part of the interface in the FPGA must work at the 120 MHz, but most of it (including a Nios CPU) works at 60 MHz. The 60 MHz clock is generated by dividing the main 120 MHz clock using a PLL. 

 

Can I use the zero-delay feature of the PLL to make sure that the rising edges of the two clocks are aligned, so that I can safely move signals between the two domains without synchronizing in a 2-stage DFF? (assuming the speed difference is not a problem). 

--- Quote End ---  

 

 

What I want to know now is how I can phase-align the derived 60MHz clock to the incoming 120MHz clock? 

 

The reason I need this is that I have a synchronous external interface that works at 120MHz and comes with a clock. I want my whole design to work at 60, to save power. But I don't want two separate clock domains - so if I could just phase-align my internal 60MHz clock to the external 120MHz clock, I can have a single domain. 

 

I suppose this is possible with an enhanced PLL and its zero-delay feature. Is this a common practice?
0 баллов
7 Ответы
Altera_Forum
Почетный участник II
1 046Просмотр.

option 1: use PLL to generate the 60MHz in phase with PLL 120 input 

 

option 2: use PLL to generate 60/120 at same phase from 120 input. 

 

In either case you are a winner, clocks will be related and synchronised 

and you wouldn't need any extra domain crossing work to worry about
Altera_Forum
Почетный участник II
1 046Просмотр.

Zero delay changes the compensation of the PLL, but all outputs of the PLL get the same compensation. So whether you do zero delay or normal compensation, your 60MHz and 120Mhz can pass data without problem. (So probably go back to the default of Normal...)

Altera_Forum
Почетный участник II
1 046Просмотр.

Thanks.  

Could you recommend a way to actually test that the generated clock is in phase with the incoming external clock? Just shoving them to pins and looking with a scope doesn't sound promising, as the internal routing will get in the way and may create phase-shifts.
Altera_Forum
Почетный участник II
1 046Просмотр.

Yes and no. There's no real way to tap into the core and see the clocks(I've seen people wanting to measure PLL jitter inside the part, for whatever reasons, and it just wasn't possible, as bringing the clocks out through I/O buffers and what not adds jitter). 

Note that in this case you do want the internal routing differences, since they're valid on transfers. It's really just differences in the output buffer you don't want. I would just bring them out to adjacent I/O and see what the difference is. 

And of course they're is going to be some difference, the questions is if timing analysis handles this. It does, and I have to say, almost every design I get has multiple clocks coming out of PLLs and they safely pass data back and forth as if they were synchronous.
Altera_Forum
Почетный участник II
1 046Просмотр.

 

--- Quote Start ---  

 

And of course they're is going to be some difference, the questions is if timing analysis handles this. It does, and I have to say, almost every design I get has multiple clocks coming out of PLLs and they safely pass data back and forth as if they were synchronous. 

--- Quote End ---  

 

 

I would worry less if the two clocks came out of the PLL. The troubling issue is that one of the clocks is external, and I'm not sure the timing analyzer knows how to handle this correctly. I need to know the real phase-misalignment between the input and the PLL output, as even a few nanoseconds are important in this case.
Altera_Forum
Почетный участник II
1 046Просмотр.

I was confused about your question, thinking it's an internal clock. If it's external, then it's just regular I/O timing. All delays in the FPGA are accounted for(PLL delays, compensation, etc.). If the external clock is 120MHz and the internal clock is 60MHz, then you might have a larger window to work with, I don't know. Bottom line is you need to constrain your I/O, just like any other project, and if you meet timing it will work.

Altera_Forum
Почетный участник II
1 046Просмотр.

I don't really see where or what the problem is. 

 

I can input 120MHz to PLL and produce 120MHz, 60MHz & 40MHz & 30MHz & 20MHz & 10MHz ...etc all with the PLL phase output for each set to same value(in degrees or picosec). The compiler will tell you how much accuracy it achieved. 

 

In a project of mine I did that with an external clk of 20.48MHz and produced a catalogue of other synchronised clks(204.8, 102.4, 51.2,20.48,10.24) without problem. 

 

I have to trust the PLL unless proved otherwise, just like I trust an AND function will be AND.
Ответить