- Отметить как новое
- Закладка
- Подписаться
- Отключить
- Подписка на RSS-канал
- Выделить
- Печать
- Сообщить о недопустимом содержимом
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?Ссылка скопирована
- Отметить как новое
- Закладка
- Подписаться
- Отключить
- Подписка на RSS-канал
- Выделить
- Печать
- Сообщить о недопустимом содержимом
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- Отметить как новое
- Закладка
- Подписаться
- Отключить
- Подписка на RSS-канал
- Выделить
- Печать
- Сообщить о недопустимом содержимом
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...)
- Отметить как новое
- Закладка
- Подписаться
- Отключить
- Подписка на RSS-канал
- Выделить
- Печать
- Сообщить о недопустимом содержимом
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.- Отметить как новое
- Закладка
- Подписаться
- Отключить
- Подписка на RSS-канал
- Выделить
- Печать
- Сообщить о недопустимом содержимом
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.- Отметить как новое
- Закладка
- Подписаться
- Отключить
- Подписка на RSS-канал
- Выделить
- Печать
- Сообщить о недопустимом содержимом
--- 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.
- Отметить как новое
- Закладка
- Подписаться
- Отключить
- Подписка на RSS-канал
- Выделить
- Печать
- Сообщить о недопустимом содержимом
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.
- Отметить как новое
- Закладка
- Подписаться
- Отключить
- Подписка на RSS-канал
- Выделить
- Печать
- Сообщить о недопустимом содержимом
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.
- Подписка на RSS-канал
- Отметить тему как новую
- Отметить тему как прочитанную
- Выполнить отслеживание данной Тема для текущего пользователя
- Закладка
- Подписаться
- Страница в формате печати