Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
16606 Discussions

How to properly connect PLL in Cyclone V?

Altera_Forum
Honored Contributor II
1,184 Views

In my project I have a camera (three of them, actually) connected to FPGA. They are all driven by an external clock (CLK_48M). I need to generate reset (CAMERA_RESET_N) and trigger (CAMERA_TRIGGER) signals for the camera. To finetune the timing (all cams have the same frequency, but may require different command signals phase) I use PLL that generates clock to drive the signals. To make things more complicated the internal logic that drives reset and trigger is in another clock domain (dotted lines). I connected PLL, fixed the problems that I saw and now I am wondering if I didn't overdesign a bit. 

 

Here is what I do. I assume PLL's RESET signal can be in any clock domain, so I don't do anything there. I need PLL's LOCKED signal in camera's clock domain, so I sync it by three chained registers. In Altera PLL reference manuals they say that it takes up to 100 us until PLL locks and it can generate pulses on LOCKED signal during that time, so I delay the signal more (it's synchronized now, so I use counter, 100 us is 4800 periods of 48MHz clock). When the counter reaches its value I release camera from reset. Trigger synchronization is straightforward (three chained registers). The last thing is that I need to know when the PLL is ready (and if it fails), so I synchronize cameras RESET_N to my main clock domain (dotted). 

 

There are three cameras, so I will do the LOCKED signal synchronization (to generate CAMERA_RESET_N) for each of them. Same with TRIGGER. The READY signal is generated only once (I pick any clock).  

 

Is this how I am supposed to do it?
0 Kudos
1 Reply
Altera_Forum
Honored Contributor II
382 Views

First and foremost, you need to do it in a way that works. You've clearly thought about the solution, it's very considered and thorough. Yes, synchronising signals and persisting them - especially when they take time to settle - is essential. There are plenty of ways to do this but they'll all fundamentally rely on counters. Providing you've the space in your device to do all this then fine (I don't see 'all this' being particularly big). 

 

Does it work? Does it fit? Does it meet timing? Answer those and you're heading in the right direction. 

 

Cheers, 

Alex
0 Kudos
Reply