YCbCr422 Pixel Data transmit

Hi

Any idea of transmitting 8bit data YCbCr422 cam (parallel port) with 400fps @640x480 pixels from FPGA (Board 1) to other FPGA (Board 2)

(without serdes)

Gil

This is ~1Gbps. Thus, interfaces similar to 1Gpbs interfaces make senses. 8b + 1b valid + 1b clock @ 125MHz, or 4b + 1b valid + 1b clock @ 250MHz make the most sense.

Hi,

From one FPGA to another... maybe with an LVDS interface.

* Low count of lines (one pair at least)
* many FPGAs come with an LVDS interface included

Klaus

As mentioned above, it's essencially an issue regarded to the selection of the electric standard. The suited strategy is strongly dependent on the distance between boards, as well the kind of physical connection (Cable, Backplane, etc...).

Hi

Thanks for quick reply,
The configuration is going to be back to back or 3~5 cm cable.
I was thinking of LVDS interface with 4xbit, 1xclk port @250Mhz .

In that case what are the design guidelines do i need to take into account? ( like jitter?, phase delay? Etc..)

Any idea of reference design?

Thanks
Gil

nsgil85 said:

The configuration is going to be back to back or 3~5 cm cable.
I was thinking of LVDS interface with 4xbit, 1xclk port @250Mhz .

Click to expand...

I would probably transmit the 4 LVDS data lines as DDR using an LVDS clock of 125 MHz, besides the lower clock frequency sent across your twisted pair ribbon cable you'll also have the added benefit of having an easy way of determining the phase of the data for upper or lower nibble of the original 8-bit data.

In that case what are the design guidelines do i need to take into account? ( like jitter?, phase delay? Etc..)

Any idea of reference design?

Click to expand...

I would recommend that you keep the trace lengths from the FPGA(s) to the connector(s) matched to within .1 UI of the bit times. So for your 250 MHz bit times you'll want to make sure all the traces are routed with something less than 100 mil differences between all the LVDS pairs on each side of the interface between the connectors and FPGAs.

Since you're sending a clock with the data it's a source synchronous interface, so unless you've got really poor jitter performance for your source clock that shouldn't be an issue. The phase delay is taken care of by keeping within that 100 mil routing difference. Unless you've picked an FPGA that has slow I/O where 250 MHz on the I/O is only just achievable instead of a modern part that can have I/O running nearly (or over 1Gbps) then 250MHz bit rate will leave the data eye with lots of slop (even with the .1 UI slop in the routing).

- - - Updated - - -

I just noticed you already have boards, so you might want to check the design files from the vendor of the board to see if they at least somewhat matched the trace lengths on the lines between the FPGA and the connector you plan on using. Most likely they are probably within the 100 mil difference.

I hope the board designer connected (at least one of) the signals of the receiving device into a dedicated clock...

Also, if you have enough interconnecting signals between the devices and the PCB routing is less then ideal - you can widen the bus and lower the clock frequency.

You can look at RGMII as a reference design. It has an additional bit of data to send a little more sideband information. You might be able to use or modify an existing core if you don't want to write your own. You may also want to add the valid/error bit as the extra lane anyways.

The two most important things are to get the IO to the correct pins, and then to ensure differential pair routing on the PCBs and the cable.

Having FPGAs on both ends gives you several tools for clock/data alignment. This makes trace length matching a "nice to have", but not a requirement.

The main hurdle for this 125 DDR design is getting the clock edges to the center of the data eye. This can be done on both devices in multiple ways. Both devices have PLLs to shift the clock 90deg, as well as input/output delays. I prefer making the transmitter as simple as possible because the receive side normally needs to correct for some of its own internals anyways.

(i'm not sure if you have any other connections between the FPGAs. you may want to add low speed links like i2c to allow more flexibility)