--- Quote Start ---
The image you've attached is too small - can't make anything out.
What did you expect? You don't say...
Adding a 12MHz second source will not allow you to maintain a 10.519MHz output clock should inclk0 glitch/fail. The PLL only caters for one set of multiplication/division factors per clock output. So, if you need to maintain that frequency you need to provide a second 10.519MHz source.
You could generate a second output on c1 based on multiplication/division factors to suit 12MHz -> 10.519MHz. You could then use the PLL's 'activeclock' output to determine which clock is selected. Your logic would then be clocked by c0 or c1 as appropriate - which would need some careful design consideration. More likely you'll have to drive two blocks of logic - one from c0, one from c1 - and select which block's output signals to use based on 'activeclock' which would reflect the presence (or not) of your primary clock.
Cheers,
Alex
--- Quote End ---
Thank you Alex. This is very helpful. Sorry about the double thread posting previously. I had submitted a thread, and it still wasn't showing up an hour later, so I created a new one with a different browser. I guess it finally decided to show up.
I modified the PLL block to add a second 10.519 MHz input instead of the 12 MHz. I noticed a few problems:
1. If I kept with the 12 MHz, the closest I can get with a multiplier and divider is *50/57, which results in a 10.5263 MHz output. Over the course of a full line, that could be a significant difference compared to 10.519 MHz.
2. 10.519 MHz is a very non-standard oscillator output. I couldn't find any of Digi-Key or Mouser. Even programmable ones don't have fine enough adjustment steps to create what I need. Unfortunately, I'm stuck with the pixel clock of the camera since it's already selected. I'm going to keep hunting for one or possibly a multiple of this frequency that can easily be divided down.
3. If I somehow am able to input an actual 10.519 MHz clock on the second input, how do I deal with phase alignment between c1 (clocked off inclk1 10.519 MHz) and the camera data that is synchronous to the inclk0 clock (which could be glitching hence the need for the second clock input). Do I need to somehow measure the phase delay between inclk1 and inclk0 when things are running normally and then compensate for that---basically adding delay to the data when inclk1 is active? The phase delay from inclk0 seems like it'd be taken care of by the source synchronous mode, but I could be misunderstanding how that works.
FYI. I tried to attach a different view of the original output from simulation. I don't know if it will appear any better.
http://www.alteraforum.com/forum/attachment.php?attachmentid=12017&stc=1 Thanks again,
Matt
Honored Contributor
