FPGA LVDS with separate clock

[beetlejuice]

I am working on an application where I need to connect 4 Camera Chips to a central FPGA. The camera chips are MT9V034 devices and each has a Parallel output with a pixel clock of 26.6MHz, and also a LVDS output consisting of a single data channel and a separate clock at 320MHz. I have to get the camera video, from 4 camera boards to a central board with an FPGA 500mm from the camera boards. (Note the FPGA does not have dedicated SERDES inputs)

The first option is a simple ribbon cable from each camera with 11 signals (data, pclk, and horizontal and vertical syncs) to the FPGA board. This worries me because of EMC emissions from the ribbons.

The second, and much preferred option is to use the LVDS signals. So we have a single data channel with the pixel data and a separate clock channel operating at about 320MHz. This LVDS communication also worries me, primarily because I have no experience above 100MHz! So I'm hoping you more experienced engineers can offer some friendly advice.

Here are my options ...

1. Use 8 bit parallel data on a ribbon cable. As already mentioned the EMC bothers me and also its a lot of FPGA pins.

2. Ideally, I would connect the LVDS clock and data signals from the camera chip to the FPGA and simply clock in the data and convert back to parallel. However, I suspect that at this frequency - even though the transmission distance is just 500mm I'm going to have problems with the FPGA. (LVDS data and clock could be transmitted via a shielded multipair cable to there could be limited EMI and limited clock skew).

3. The MT9V034 documents suggest use of a DS92LV1212A deserialiser to receive the single data channel (without the lvds clock), and to auto recover the clock to recreate the parallel output. This is a potential solution but there is an unknown 'lock' time for the device to lock to the incoming data signal clock. Since my application will be capturing partial static images from the camera chip the at sporadic intervals, I am concerned that the DS92LV1212A wont be able to lock quickly enough each time that data is available to receive.

Any comments, advice or personal experience will be appreciated.

 

[barry]

Personally, I would prefer the parallel approach. With proper layout and cabling, I wouldn’t worry too much about EMC. Can your FPGA (which one?) even handle 320 MHz inputs?

 

[beetlejuice]

Personally, I would prefer the parallel approach. With proper layout and cabling, I wouldn’t worry too much about EMC. Can your FPGA (which one?) even handle 320 MHz inputs?

Hi Barry
Thanks for the reply.
I'm planning on using a Lattice ECP5 device (one without SERDES because of the Lattice Diamond licensing restriction). The ECP5 devices seem to specify a maximum external input frequency of 400MHz, so I'm expecting that the actual internal logic necessary for deserialising will be somewhat slower than this.

The parallel option, although technically far simpler, would require a 500mm ribbon cable with a 27MHz 8 bit data bus + VSync, HSync and Pixel Clock. Each signal should have a return ground alongside it so the ribbon becomes quite wide ( 26+ wires) and bulky, apart from the EMI issue. We would also need one ribbon for each of the 4 cameras. so that's a lot of bulky, noisy ribbon cable and it's not ideal.

 

[barry]

Your ribbon doesn't have to be "quite wide". There are a lot of very compact options out there. For example:

https://www.samtec.com/cables/high-speed/assemblies.

But, yeah, serial might be more elegant externally.

 

[ads-ee]

If the ECP5 can handle 400 MHz inputs then you shouldn't have an issue with 320 MHz inputs, the deserializer would be localized to the IO input either through placement constraints or by the place and route tools (if they are capable of doing a good job, with just the timing constraints)

In either case parallel or serial, you will need to use whatever support the ECP5 has to phase shift either the clock or data to capture the data using the source synchronous clock input.

If you use a deserializer then you will have the logic after the deserializer running at either 320MHz/data_bit_width or you run the data through an asynchronous FIFO.

 

[beetlejuice]

In either case parallel or serial, you will need to use whatever support the ECP5 has to phase shift either the clock or data to capture the data using the source synchronous clock input.

Assuming that I can keep the LVDS Data and LVDS Clock wire pairs the same length (which over just 500mm should not be too problematic) then isn't is possible just to use the source (lvds) clock, to clock the data bits into the FPGA and to also clock the serial to parallel logic, then that parallel output would feed into an asynchronous FIFO where it will exit in the system FPGA clock domain.

I have to do this on 4 separate camera inputs so I dont think I'll have the resources to have separate PLL for each LVDS Data/Clock pair input.

,

 

[barry]

i don’t think you need 4 PLLs. I don’t think you need ANY PLLs. Depending on your clock and data source you MAY need to adjust their relative phase, but this can be done by specifying input timing constraints.

 

[ads-ee]

You should look around the Lattice website and look for any app notes on source synchronous interfaces, or example designs that use a source synchronous interfaces. That would show you how to implement such interfaces in an ECP5.

 

[beetlejuice]

You should look around the Lattice website and look for any app notes on source synchronous interfaces, or example designs that use a source synchronous interfaces. That would show you how to implement such interfaces in an ECP5.

I've been doing exactly that. It seems that there is plenty of documentation for implementing high speed DDR interfaces but little for SDR. However I did find a piece tucked away in a document that explained exactly what I needed - a GIREG_RX.SCLK interface implemented in one of the PIO cells. Problem is that the maximum clock frequency is just 200MHz and I need 320MHz.

At this point I'm considering using a small low cost FPGA on the camera boards to bundle the 27MHz parallel output from the camera chip into a 3Channel Data + 81MHz clock LVDS transmission. I can easily link this to the main control board with standard off the shelf HDMI cables and not have too much concern for EMI, and of course the 81MHz data stream is far more manageable at the FPGA.

 

[barry]

Not sure why you’re so resistant to 4 parallel interfaces. It’s done all the time; why are you so concerned with EMI? Adding four FPGAs to the string just decreases reliability, adds complexity and cost and development time.

And i wouldn’t totally dismiss the serial interface yet. You could just write some code that implements the serial interface, and see if it compiles and meets timing.

 

[std_match]

Can you divide the clock to 160 MHz and use the DDR functionality in the FPGA?

 

[beetlejuice]

Can you divide the clock to 160 MHz and use the DDR functionality in the FPGA?

That's an interesting suggestion. The clock comes straight from the MY9V034 camera chip so would need an external high frequency divider or PLL, but it seems possible.

Not sure why you’re so resistant to 4 parallel interfaces. It’s done all the time; why are you so concerned with EMI? Adding four FPGAs to the string just decreases reliability, adds complexity and cost and development time.

And i wouldn’t totally dismiss the serial interface yet. You could just write some code that implements the serial interface, and see if it compiles and meets timing.

Why am I resistant to parallel interfaces? Its a good question, since this is the simple option.
I have experience with a previous, similar though faster, parallel design where a 150mm ribbon was radiating harmonics of a 74MHs clock, and it failed EMC testing. This design had alternating signal and grounds on the ribbon. I finally got it to scrape through EMC by tagging 47pf caps to ground on all the signal lines and clock. I realize that this is slower clock, but the ribbon lengths may be up to 500mm (actually through some mechanical changes this could be reduced to about 300mm).

Based on your comment I reviewed the parallel approach today. I have to route the parallel ribbon cable around some obstacles and a 30 - 40mm wide cable maybe problematic. So I considered a 34 way 0.5mm pitch FFC cable which could also carry other signals I need at the camera board, plus alternating grounds. It turn out that this FFC would be very easy to shield with Copper or Aluminium Tape. Its also very low cost - which is important in the project, and of course as you have pointed out - there is no extra FPGA and very little development.

At this stage I think I'll move forward with this parallel - FFC option and hope that I can keep the EMI in check.