Implementing 18-bit lvds serializer in CPLD

[Altera_Forum]

Hello, 

 Maybe this is a beginners question. I do not yet have a lot of experience using CPLDs. They are a bit more limited than FPGAs.   I was wondering if it is feasible to implement an 18-bit LVDS deserializer on a low cost FLASH CPLD. For a projet I need the deserializer and some simple glue logic. It would be perfect if this could be implemented in an all-in-one chip like one out of the MAX family.   However, I am not sure about the clock recovery part. This probably needs a PLL of some sort. Can this be done in a MAX?  Thanks in advance for any help.  Ronald

[Altera_Forum]

Altera has announced a MAX V DPLL feature about two years ago, but there's apparently no software support until now. 

http://www.alteraforum.com/forum/showthread.php?t=27399  So I won't rely on it for the time being. At lower data rates, oversampling may be able to recover the clock.

[Altera_Forum]

Quite a pity. It would have been a beautiful solution. So what about the low cost FPGAs? Is it possible there? The solution would have a higher component count, but it might still be interesting.  

Or does Altera already have FLASH FPGAs?  How complicated is it to implement such a deserializer for 25Mhz parallel out? Do they have affordable IP for this?

[Altera_Forum]

What's the intended bit rate? Low cost FPGA (Cyclone series) neither have a decicated clock recovery hardware, but CDR can be implemented for medium bit rates utilizing PLL dynamic phase shift or oversampling with multiphase clocks. 

 MAX II/V is the only Flash FPGA available from Altera. It's named CPLD according to the low logic element count , but actually using SRAM FPGA technology.  P.S: I assume the bit rate is 450 MHz, 18*25 MHz?

[Altera_Forum]

--- Quote Start ---  What's the intended bit rate? Low cost FPGA (Cyclone series) neither have a decicated clock recovery hardware, but CDR can be implemented for medium bit rates utilizing PLL dynamic phase shift or oversampling with multiphase clocks.  MAX II/V is the only Flash FPGA available from Altera. It's named CPLD according to the low logic element count , but actually using SRAM FPGA technology.  P.S: I assume the bit rate is 450 MHz, 18*25 MHz?  --- Quote End ---    Yes, no that you mention it. This is the bitrate. I never thought of it that way. I guess the last time I looked at this was before I had my morning coffee. It is an image sensor interface. The image sensor runs om 25Mhz, but it has an internal PLL to generate the bit clock. This does mean that the working clock is quite high for a low cost part.  I might still get away with using a lower clock rate (eg. 14.7Mhz), but the resulting bit clock will still be rather high.   What is considered to be a medium bit rate?

[Altera_Forum]

450 MHz is feasible as Cyclone LVDS clock rate, but it's a bit high for "software" clock recovery. It might work, but I didn't yet implement CDR at higher bit rates than 240 MHz. The standard configuration, fully supported by Quartus IP would feed the word clock to the Cyclone PLL and generate the fast clock by frequency multiplying, without clock recovery. I don't know if transmitting the word clock is feasible for your application?

[Altera_Forum]

Again, Good one! I don't even need to recover the clock I can actually get an optional shift clock line to take it from. So theoretically that simplifies things a lot. 

 Only thing I would need to have is:  - An LVDS input (or combine 2 single ended inputs?) - A decoder, which is probably something in between of UART and SPI.   Is there a standard on how the encoding is usually done? I mean, number and level of start bits and stop bits? Or is this device specific? This particular image sensor has one start bit (1) and one stop bit (0).

[Altera_Forum]

Preferably we would use the word clock (25 MHz) to synchronize the deserializer. A 450 MHz clock would be above acceptable Cyclone clock tree frequencies. The LVDS receiver uses 225 MHz and DDIO registers internally. 

 The 25 MHz word clock must be nevertheless transmitted with low jitter, so you should use differential pairs and dedicated LVDS receivers for clock and data lines.  Synchronizing on start bit isn't a standard feature of the deserializer block but basically possible by additional logic.

[Altera_Forum]

--- Quote Start ---  Preferably we would use the word clock (25 MHz) to synchronize the deserializer. A 450 MHz clock would be above acceptable Cyclone clock tree frequencies. The LVDS receiver uses 225 MHz and DDIO registers internally.  The 25 MHz word clock must be nevertheless transmitted with low jitter, so you should use differential pairs and dedicated LVDS receivers for clock and data lines.  Synchronizing on start bit isn't a standard feature of the deserializer block but basically possible by additional logic.  --- Quote End ---    Hmm, that introduces another challenge. I would have to convert the sensor clock to LVDS. That's probably possible through some converter. I will look into that.   Do you know which part is the most low cost part that will accept an LVDS clock of 450Mhz? This is probably already high end, right?

[Altera_Forum]

Cyclone FPGAs are specified to support 450 MHz input clock, but restriction related to IO standards might apply.  

 I can still hardly imagine that a high-speed serial interface device uses 450 MHz clock output without good cause. None of the popular serial interface standards is exposing a bit rate clock output.

[Altera_Forum]

I took another look at the datasheets. The image sensor datasheet gives very little detail. They refer to the SerDes chip DS92LV18 or DS92LV16. The latter I do not understand because there is 18 bits of data. Probably this is a typo. Both are rather large and rather expensive, so I prefer not to use them.  

However, the datasheet does give the following information. There is both a refclk (word clock) and a bit clock. The refclk is single ended. The bit clock is LVDS. In the image sensor application example they do not use the bitclk. Clock recovery from the data is used instead.  I am a bit puzzled as to why a bit clock could not be used. If I were to transmit the data 10101010101010, this would give the same electrical result as the bit clk. So the deserializer input must be able to handle such a fast signal anyhow.

[Altera_Forum]

The problem is matching the edges of the clock signal to the stable points in the data stream.

[Altera_Forum]

Aha, so you would need a PLL anyway. I am not sure how to proceed now. The simplest way would be to use the sensors parallel output. Als this is a stereovision camera I would need to synchronize two parallel datastreams into one wider stream. This is probably easier to do low cost than using the serial data. It only limits the cable length considerably. 

 Does a Cyclone specified for 275Mhz also take signals up to 275Mhz on the pins? In that case I might still be able to run it at half speed.