CycloneIII internal logic driving PLL

[Altera_Forum]

Hi, 

I have 2 LVDS inputs: Data/Strobe. To recover the clock I XOR the Data/Strobe signals from the LVDS receivers. I need to drive a PLL with this clock, but the Cyclone III Handbook Section 5 Table 5.2 says "Clock Control Blocks that have inputs driven with internal logic are not able to drive PLLs. Is there another way of doing this?:confused: :confused:    Regards   Terry

[Altera_Forum]

Hi Terry, 

 What you want to do is not directly supported by the CycloneIII PLLs - I don't think any other families support this either. The likely reason is to minimize jitter - using the dedicated clock input pins provide a direct low-jitter path to the input of the PLL. Feeding the input of the PLL from the core fabric would increase this, likely compromising the PLL performance.  Here's a possible work around: send the XOR-ed signal out of the device and then back in on an adjacent clock pin, which would then feed a PLL. Not ideal, but it should get you out of trouble.  Good luck.   Stephen

[Altera_Forum]

A better solution is probably synchronizing a PLL to the input signal utilizing the dynamic phase shift feature.

[Altera_Forum]

Can you direct me to an app note of using dynamic phase shift. All of the documentation talks about it, but doesn't give enough detailed info on the inputs to the PLL to implement it.

[Altera_Forum]

Have a look at the PLL User Guide for info on dynamic phase shifting: 

 http://www.altera.com/literature/ug/ug_altpll.pdf (http://www.altera.com/literature/ug/ug_altpll.pdf)  I couldn't find any specific examples on using this feature, so I would recommend putting together a simple simulation so you can determine how exactly it operates.  You would still need to provide an external clock to the PLL in order to use it with the dynamic phase shifting feature, though I am not sure how this would help you. Your original post mentions data / strobe signals, but not the availability of the original clock.  Another option maybe to over-sample the incoming datastream, depending upon the frequency. You would then use the over-sampled clock to drive your internal logic. I have seen this done when decoding Manchester Phase Encoded data. The key is to have a low frequency stream to start with, so the over-sampling frequency is manageable by the core logic.   Stephen

[Altera_Forum]

--- Quote Start ---  I couldn't find any specific examples on using this feature  --- Quote End ---    Yes, there are no reference designs yet. I wanted to mention an option (that's working for me well) rather than give a detail solution.  The original poster doesn't tell the data rate and the exact data format. The "XOR" point suggests something like manchester encoding. Obviously, the source clock isn't transmitted with the data, otherwise it won't need to be recovered. I assume however, that the transmitter as well as the receiver are using crystal clocks which a deviation below a few 100 ppm, similar to other communication stituations (Ethernet, USB etc.).  For medium speed (e.g. up to 50 MBPS), oversampling is clearly an alternative.

[Altera_Forum]

--- Quote Start ---  Can you direct me to an app note of using dynamic phase shift. All of the documentation talks about it, but doesn't give enough detailed info on the inputs to the PLL to implement it.  --- Quote End ---    As far as I know there's no Dynamic Phase shift [allignment] for Cyclone III. Maybe Source-Synchronous Compensation Mode can be used, but that is static.  Ton

[Altera_Forum]

There's no automatic alignment for LVDS receivers (DPA). But dynamic phase shift is a PLL option since Cyclone III, you can utilize it in user logic..

[Altera_Forum]

The Data/Strobe works like this: if the Data signal doesn't change state then the Strobe Signal changes state, therefore if you XOR them together you get a clock at 1/2 the data rate. This is a SMIA or Camera Link interface. My data rate is 96MHz and a I have a 48Mhz Osc going to the PLL. My recovered clock is the same frequency, so the dynamic phase shift should work. I haven't done this before so it should be interesting. I will connect a global clock output to a global clock input for Option B. Once this is working then I can use the AltLVDS_RX to deserialize the Data.:p  

 Thanks   Terry