Slip Ring Timing Issue, MAX10 PLL Problem

[Altera_Forum]

I'm working on the design of a rotating camera whose frame valid and pixel clock go through slip rings. We've found that there can be glitches ranging from 10 ns to 10 us on both signals. The processor peripheral that the camera interfaces to can not handle abnormal (dropped) clock signals, so the signals have to contact the exact number of pixels / line and lines / frame else the video will be corrupted. One thought was to have a small FPGA use a PLL to maintain the 10.519 MHz clock, even if the pixel clocked dropped out for 10 us. Since frame valid could also have glitches, we could just use the first rising edge on frame valid to start internal counting and just count the PLL's output clock to recreate frame valid and generate a line valid. (See clock recovery attachment) 

  I created a project based around a MAX10, added the ALTPLL, set up the PLL for source synchronous mode (so 10 bits of camera data would be phase synchronized with the PLL clock), and added a 12 MHz oscillator as a secondary clock that the PLL could use to (I hoped) generate the 10.519 MHz output if the PLL couldn't maintain lock for 10 us if the pixel clock went away. Unfortunately, when I simulated this, it behaved nothing like I expected. I don't know how well the simulation attachment will show up, but what I end up getting is just the inclk1 input on the PLL output all the time.     My assumptions are clearly wrong about what the PLL can do, so I'd appreciate any recommendations on the best way to solve this problem. Thanks in advance for the help.

[Altera_Forum]

The image you've attached is too small - can't make anything out. 

  --- Quote Start ---  Unfortunately, when I simulated this, it behaved nothing like I expected.  --- Quote End ---  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

[Altera_Forum]

--- 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

[Altera_Forum]

I think you need to consider over-sampling your data, with a much faster clock that won't drop out. 10.519MHz isn't a particularly fast data rate. 

 Sample the pixel data (and pixel clock) using a much faster clock - probably in excess of 50MHz (do you have such a clock available on your hardware?). Based on detecting edges on either pixel data or pixel clock, you will be able to maintain a counter - also driven from the faster clock - which you rely on to determine when to sample the pixel data. This way you're not dependent on the pixel clock. You'll need to come up with a suitable method of counting and determining when to sample the pixel data, for however long you need to deal with the loss of pixel clock. Depending on your source frequency the counter may not be an exact multiple of the pixel clock. You're likely to have to drop/add counts every n pixels (or similar). However, you can also continue to use transitions in the pixel data to help maintain the correct alignment of your counters with respect to the pixel data.  Cheers, Alex

[Altera_Forum]

--- Quote Start ---  I think you need to consider over-sampling your data, with a much faster clock that won't drop out. 10.519MHz isn't a particularly fast data rate.  Sample the pixel data (and pixel clock) using a much faster clock - probably in excess of 50MHz (do you have such a clock available on your hardware?). Based on detecting edges on either pixel data or pixel clock, you will be able to maintain a counter - also driven from the faster clock - which you rely on to determine when to sample the pixel data. This way you're not dependent on the pixel clock. You'll need to come up with a suitable method of counting and determining when to sample the pixel data, for however long you need to deal with the loss of pixel clock. Depending on your source frequency the counter may not be an exact multiple of the pixel clock. You're likely to have to drop/add counts every n pixels (or similar). However, you can also continue to use transitions in the pixel data to help maintain the correct alignment of your counters with respect to the pixel data.  Cheers, Alex  --- Quote End ---     Alex,  I got it working with your suggestion of sampling with a higher speed clock. Thanks for the great help!