Recovering 10-bit LVDS data and Embedded CLK

[Altera_Forum]

I'm trying to use the Cyclone III starter kit to implement a serial adapter board that has as input a single-channel continuous LVDS data stream with 12-bit words (10 bit data and start and stop bit for CLK recovery). Dedicated LVDS deserializer ICs from National Semiconductor lock onto the incoming data stream, recover the embedded CLK using the start and stop bits, and then provide a 10-bit parallel data output at each cycle.  

 It's not clear to me whether the ALTLVDS function can do this. It seems that I need to use a 12-bit deserialization factor and first generate at 12-bit parallel output at each cycle and then recover the CLK and actual data bits from this output. But I'm not sure whether this will work since the start and stop bits are just bits and are not a defined sync pattern.   I'm new to LVDS and Altera FPGAs and would very much appreciate any help and suggestions!

[Altera_Forum]

I don't think, that any Altera FPGA is able to decode National embedded clock LVDS without an additional reference clock. As a disadvantage compared to 8b/10b coding, the protocol depends on an additional sync channel. Altera is supporting 8b/10b encoding with Arria GX and various Stratix GX families 

 If the source synchronous reference clock is available, Stratix/Arria DPA feature would be able to adjust the receiver phase according to the embedded clock.

[Altera_Forum]

Thanks for the note. To put things in context, the incoming serial data stream (162Mbps) is from an imager, so I have a frame sync pattern that I can use as a flag. I was thinking of having some logic before the LVDS receiver that would enable the receiver once this sync pattern was detected. I was thinking of using an external PLL block (outside ALTLVDS megafunction) to provide the CLK for the LVDS drivers on the imager chip as well as the CLK for the sync detection logic and LVDS receiver, so all clocks are synchronous. The LVDS receiver is 1:12 (but real data is 10-bits) and the slow clock to latch the outputs is also provided by the PLL. 

 The above makes two assumptions. Once I define an I/O as LVDS it converts into a serial data stream so the logic used to detect the sync pattern assumes a single-channel input bit stream is available. The other assumption is that proper phase alignment of the CLK on the receive side with the incoming data stream is not critical since all clocks are synchronous.

[Altera_Forum]

162 Mbps sounds rather gentle.  

  --- Quote Start ---  The other assumption is that proper phase alignment of the CLK on the receive side with the incoming data stream is not critical since all clocks are synchronous.  --- Quote End ---   That's what I meant with availability of a source synchronous reference.   With reconfigurable PLLs in Cyclone III, your basically able to adjust a receiver PLL to incoming data without a dedicated DPA circuit. But you won't be able to track a shifting data phase.

[Altera_Forum]

Thanks again. I guess I won't be able to evaluate the effect of shifting data phase until I test the hardware implementation.  

 I'll try out the design using one external PLL in the Cyclone III starter kit that provides all the clocks and some logic to sync with the data stream along with an instantiation of ALTLVDS.