Syncing a SelectIO serdes module?

[Pack34]

I'm working with a camera module and have run into a bit of a snafu.

I'm attempting to use the built-in SelectIO core generator to parse LVDS data from a sensor. This data begins streaming after a horizontal pulse from the sensor. The issue is that there's an almost random amount of LVDS clocks that occur after the horizontal pulse is seen by the FPGA.

What would be the best way to sync this? Would it be as simple as creating a second serdes module, not selecting the serialization option and using that to read in the start byte? This could then reset the SelectIO core that I'm using to parse in the data?

[MosherIV]

Hi, I am surprised no one else with more experience with Serdes has not answered

The issue is that there's an almost random amount of LVDS clocks that occur after the horizontal pulse is seen by the FPGA

Bear in mind that serdes is not raw data being clocked. Since there is no seperate clock line, the data itself needs to generate clocking pulses, the data is re-encoded so that there are always pulses (to generate clocking pulses). I think serdes converts 8 bit data into 12 bits. This needs to be done to avoid 0x00 and 0xff which will have no pulses.

You really need to have a full understanding of the serdes protocol at the hardware level, then you need an understanding of the protocol that is runnung over serdes.

[Pack34]

The exact format that I'm working with is:

Data is being transmitted out of the sensor over LVDS using four lanes.
Each lane streams data out for each fourth pixel in a 12-bit format.

Each line of data is framed by a horizontal pulse.
Each frame of data is framed by a vertical pulse.

Unfortunately the precise amount of LVDS clocks from the sensor is not entirely consistent from line to line and frame to frame. It's always +/- 3 LVDS clocks.

I have the auto-generated code configured such that it'll output this data in parallel.

The issue is the +/- clocks between that horizontal pulse and the framing byte.

What I'm thinking about doing is instantiating a second module and setting that to a data width of 1 and then bringing that out of reset on a horizontal pulse. Then letting it run until the 0xFF framing byte is read-in. Then using this as a flag to enable the primary serdes module so that we're always synced.

Could something like this work? Or could it be too simple?

What I'm thinking about doing is holding that SerDes module in a reset state and then instantiating a second one that's only connected to the first lane and the clock.

[dmills]

Are we talking IOSERDES or GTx?

It does not sound like your data is 8b10 or 64b66 or such which is what you would normally expect if using a GTx, so I guess you are using an IOSERDES (Rate less then about 1.2Gb/s)?

I am not really clear what another serdes buys you, presumably you have some unique code that appears on lane 1 for "start active video" and another for "end active video" and are simply looking to tweak the word alignment to suit? Sounds like a job for a sequence detector and barrel shifter.

I think the problem with your idea is that a data width of 1 means that your logic looking for the framing will have to run at line rate, and that nearly never works, far better to sort it out in a parallel domain, maybe use a deserialisation factor of say 16, which then means your 0xff frame start flag should always fit into the first word out of the serdes if the random shift is only 3 bits.
You can then find that byte and use it to configure the starting phase of a gearbox to get you your 12 bit words.

The trancever serdes often have some of this built in, and often have the inherent ability to shift word alignment, but the availability of that depends on the part and I cannot recall if an IOSERDES can do this.

Regards, Dan.

[Pack34]

The issue is alignment of bit0 of the data to bit0 of the output of the serdes. I was thinking of having it setup to watch the individual bits and then enable the SelectIO module at the proper time.

However, I think the cleanest method is likely to reset the module whenever I see a line framing pulse and then bitwise assigning the bits into a buffer after they show-up as the 24-bit vector. Increment down the list and then start tossing the bits into the correct bucket in a new buffer.

Similar to waiting for a start flag in firmware when processing a UART, reading the data into a buffer, and then memcpy that buffer into a mirror for processing.

[NorthGuy]

It has a BITSLIP pin to align bits.

Concerning additional 1:1 channel - if it is slow enough that you can read it without ISERDES, why do you need ISERDES in the first place? How fast is it?

[hamster_nz]

For the most part, high speed per-pin Select I/O SERDES on Xilinx devices is only useful if the send and receiver are deriving their timing from the same clock.

If your source sensor is sending data at 500Mb/s +/- 50ppm, and your FPGA's IO clock is 500MHz but a different +/- 50ppm, then you are doing it wrong. Have the FPGA generate the sensor's clock, or connect the sensors clock to your FPGA's clocking infrastructure.

You cannot implement line-speed Clock Data Recovery using a SERDES, even if you are using a CDR friendly coding scheme. At best you will end up clocking your FPGA design faster, and then need a Data Enable Strobe to identify which cycles have active data. Regenerating a nearly-jitter-free pixel clock for video data or an I2S clock for audio data is not simple, (and maybe not even possible).

Differences in relative phase at the IO pins can be trimmed out using IDELAY and ODELAY primatives, or by adjusting the phase in the clocking infrastructure (MMCM or PLL). You can detect phase dynamically by having two SERDES modules sampling the same pin but at different phases (effectively sampling at 2x), and trimming the phase so the "dodgy samples" (the ones that occur on the rising/falling edges of the data bits) are all seen in one SERDES, thus ensuring that the other SERDES is seeing clean samples taken within the eye.

The only other way is to oversample the data (at 3x or 4x faster than the data rate), and then identify the transitions yourself and follow as the relative phase creeps this way or that. This technique tops out at about 300 or 400Mb/s per pin (due to the 1.2Gb/s max for a SERDES), and is extremely expensive in area, power, time and complexity. It also cannot work if you have sparse transitions in your data stream (i.e long runs of zeros or ones), which could be likely for sampled video data.

[nctnico]

I'm working with a camera module and have run into a bit of a snafu.

I'm attempting to use the built-in SelectIO core generator to parse LVDS data from a sensor. This data begins streaming after a horizontal pulse from the sensor. The issue is that there's an almost random amount of LVDS clocks that occur after the horizontal pulse is seen by the FPGA.

What would be the best way to sync this? Would it be as simple as creating a second serdes module, not selecting the serialization option and using that to read in the start byte? This could then reset the SelectIO core that I'm using to parse in the data?

Bitslip is your friend. You have to analyse the data and if it is not correct then you need to assert the bitslip pin which delays the input stream one input clock cycle. Repeat until the data makes sense.

[kony]

... Have the FPGA generate the sensor's clock, or connect the sensors clock to your FPGA's clocking infrastructure ...

Not that I have too much expirience with highspeed serial intefraces, however suggesting sourcing the clock from FPGA fabric for a highspeed data converter (be it image sensor or otherwise) is asking for a trouble. Dedicated clock synthetiser will have much better jitter performance, which will reflect into higher SNR of the converter due to smaller sampling aperture jitter. I don't really recall any occasion where the data converter had separatelly clocked I/O interface with clock being provided externally, decoupled from the converter sampling clock itself. In the other direction however, plenty of times.

[hamster_nz]

... Have the FPGA generate the sensor's clock, or connect the sensors clock to your FPGA's clocking infrastructure ...

Not that I have too much expirience with highspeed serial intefraces, however suggesting sourcing the clock from FPGA fabric for a highspeed data converter (be it image sensor or otherwise) is asking for a trouble. Dedicated clock synthetiser will have much better jitter performance, which will reflect into higher SNR of the converter due to smaller sampling aperture jitter. I don't really recall any occasion where the data converter had separatelly clocked I/O interface with clock being provided externally, decoupled from the converter sampling clock itself. In the other direction however, plenty of times.

It was more a general comment on using SERDES, and which particular configuration works for you depends on your needs.

Example 1- HDMI
Source provides clock, sink receives clock and uses that (after a PLL) to sample the data.

Example 2 - DDR DRAM
Clock is supplied to SDRAM DIMMs from the memory controller

Example 3 - OV7670 image sensor.
FPGA can supply the clock (XCLK) to the sensor
parallel data is supplied back to FPGA along with the pixel clock (PCLK).

In all three cases the timing is referenced back to the single clock source, so you only have to worry about relative phase issues, not frequency differences.

...and just to throw a spanner in the works, https://www.xilinx.com/support/documentation/application_notes/xapp589-VCXO.pdf - All Digital VCXO Replacement for Gigabit Transceiver Applications, where a local reference clock is 'adjusted' to match the incoming clock rate. (however this has little to do with SERDES blocks)