Camera link interface

Hi,

What is the length of your cable? Do you know the impedance of your cable? Mismatch can also accur because of the cable. As an example I have used LVDS signaling through a 3m. cable with 100 Mbps successfully.

Also I must say that I was also unsuccessful through a 5m. cable with a very bad one which includes several connectors and a long solid flat cable in it.

Have you instantiated the differential input buffers (IBUFDS) with the diffterm generic set to true?

I think the length and the bps is the key factor, i am now doing the saming work, could you send me you codes for reference? thanks a lot.

Best Regards,

Wicky

I have camera link working at 40MHz, a 2 meter cable, VHDL code using the ISERDES Xilinx primitives, a ML402 with a daughter board of my own design that had matched length traces.

I did not use Digital Control Impedance.

What do you mean "one end open"?

Setting up the ISERDES,the terminated IOBs, and your DCMs are all critical:

from UCF file: # CAMERA LINK 2 INPUT NET "cam2_in" LOC = "AC20" ; # X0NEG NET "cam2_in" LOC = "AB20" ; # X0POS NET "cam2_in" LOC = "AD21" ; # X1NEG NET "cam2_in" LOC = "AE21" ; # X1POS NET "cam2_in" LOC = "AD20" ; # X2NEG NET "cam2_in" LOC = "AE20" ; # X2POS NET "cam2_in" LOC = "AC19" ; # CLKNEG NET "cam2_in" LOC = "AD19" ; # CLKPOS NET "cam2_in" LOC = "AB18" ; # X3NEG NET "cam2_in" LOC = "AC18" ; # X3POS

from VHDL:

attribute DIFF_TERM : boolean; attribute DIFF_TERM of cam2_x0_ibufd_inst:label is true; attribute DIFF_TERM of cam2_x1_ibufd_inst:label is true; attribute DIFF_TERM of cam2_x2_ibufd_inst:label is true; attribute DIFF_TERM of cam2_x3_ibufd_inst:label is true; attribute DIFF_TERM of cam2_xclk_ibufd_inst:label is true; attribute DIFF_TERM of serial_from_cam2_IBUFDS:label is true;

cam2_xclk_ibufd_inst : IBUFDS port map ( O => cam2_xclk, I => cam2_in(7), IB => cam2_in(6) );

cam2_x0_ibufd_inst : IBUFDS port map ( O => cam2_x0, I => cam2_in(1), IB => cam2_in(0) );

cam2_x1_ibufd_inst : IBUFDS port map ( O => cam2_x1, I => cam2_in(3), IB => cam2_in(2) );

cam2_x2_ibufd_inst : IBUFDS port map ( O => cam2_x2, I => cam2_in(5), IB => cam2_in(4) );

cam2_x3_ibufd_inst : IBUFDS port map ( O => cam2_x3, I => cam2_in(9), IB => cam2_in(8) );

iserdes_master : ISERDES generic map ( BITSLIP_ENABLE => FALSE, -- TRUE FALSE DATA_RATE => "SDR", -- DDR SDR DATA_WIDTH => 7, -- DDR 4,6,8,10 SDR 2,3,4,5,6,7,8 INIT_Q1 => '0', INIT_Q2 => '0', INIT_Q3 => '0', INIT_Q4 => '0', INTERFACE_TYPE => "MEMORY", -- model - "MEMORY" or "NETWORKING" IOBDELAY => "NONE", -- delay chain "NONE","IBUF","IFD","BOTH" IOBDELAY_TYPE => "DEFAULT", -- tap delay "DEFAULT", "FIXED","VARIABLE" IOBDELAY_VALUE => 0, -- initial tap delay 0 to 63 NUM_CE => 1, -- clock enables 1,2 SERDES_MODE => "MASTER", -- "MASTER" or "SLAVE" SRVAL_Q1 => '0', SRVAL_Q2 => '0', SRVAL_Q3 => '0', SRVAL_Q4 => '0') port map ( O => open, Q1 => dout(0), Q2 => dout(1), Q3 => dout(2), Q4 => dout(3), Q5 => dout(4), Q6 => dout(5), SHIFTOUT1 => shift1, SHIFTOUT2 => shift2, BITSLIP => '0', CE1 => '1', CE2 => '1', CLK => fclk, CLKDIV => xclk, D => din, DLYCE => dlyce, DLYINC => dlyinc, DLYRST => dlyrst, OCLK => oclk, REV => '0', SHIFTIN1 => '0', SHIFTIN2 => '0', SR => reset );

iserdes_slave : ISERDES generic map ( BITSLIP_ENABLE => FALSE, -- TRUE FALSE DATA_RATE => "SDR", -- DDR SDR DATA_WIDTH => 7, -- DDR 4,6,8,10 SDR 2,3,4,5,6,7,8 INIT_Q1 => '0', INIT_Q2 => '0', INIT_Q3 => '0', INIT_Q4 => '0', INTERFACE_TYPE => "MEMORY", -- model - "MEMORY" or "NETWORKING" IOBDELAY => "NONE", -- delay chain "NONE","IBUF","IFD","BOTH" IOBDELAY_TYPE => "DEFAULT", -- tap delay "DEFAULT", "FIXED","VARIABLE" IOBDELAY_VALUE => 0, -- initial tap delay 0 to 63 NUM_CE => 1, -- clock enables 1,2 SERDES_MODE => "SLAVE", -- "MASTER" or "SLAVE" SRVAL_Q1 => '0', SRVAL_Q2 => '0', SRVAL_Q3 => '0', SRVAL_Q4 => '0') port map ( O => open, Q1 => open, Q2 => open, Q3 => dout(6), Q4 => dout(7), Q5 => dout(8), Q6 => dout(9), SHIFTOUT1 => open, SHIFTOUT2 => open, BITSLIP => '0', CE1 => '1', CE2 => '1', CLK => fclk, CLKDIV => xclk, D => '0', DLYCE => dlyce, DLYINC => dlyinc, DLYRST => dlyrst, OCLK => oclk, REV => '0', SHIFTIN1 => shift1, SHIFTIN2 => shift2, SR => reset );

Brad Smallridge AiVision

We need data...

You have told us nothing about speed, length (long doesn't count), type/specs of cable, etc..........

I've transmitted 400mbps over 5m using 3M MDR cable assemblies, driven by an FPGA. I've received up to 300mbps, FPGA's on both ends, Xilinx (tx) and Altera (rx)--this is evidence that two foes can play nice together :)

Rob

snipped-for-privacy@gmail.com wrote:

First of all, thank you for your answers.

I answer some of your questions:

- cam_clk = 40 MHz

- Data rate = (about) 378 Mbps [30 fps; frame size 1024 x 1024; 12 bit digitalization]

- My ucf and vhdl is the same that Brad's one (but without ISERDES)

About the cable, is 5 meters in length. The problem is that there is an intermediate sub-D connector which is joining two 2.5 m cables, id est, the cable consists in a camera link connector - a sub-D female - a sub-D male - pins to FPGA board. I really know that this is not the most suitable for high frequency signals, but the thing is that this cable works when the receiver is a frame grabber or a board using the NI deserializer chip.

Once the input signals are received by the FPGA, they're wrong, so...if there's a problem I guess it's a mismatch or something like that. Anyway I'm not an expert...if you have more ideas...

Thank you, Chronos

I'm not sure you can daisy chain Camera Link Cables like this. Are you doing that for the frame grabber set up? There was something about the Camera Link spec that made me think that you can't connect them like other cables, besides the fact they don't have male/female connectors. Your signals maybe mirrored.

?

Brad Smallridge AiVision

Are you sure you are doing a Camera Link interface? The interface is a

7x interface. So, a 40MHz clock would yield each lane running at 280MHz. I'm a little confused why you say your running at 378Mbps.

You said your receiver worked with the short cable but now with the longer one. It could be a few things but I would analyze the timing on your receiver to assure yourself you have the best skew margin. Some National receivers have de-skew technology. Most of the higher end FPGA's can implement this, too. My guess is that V4 has the power to do so.

Another thought, shy don't you just buy a 5m camera link cable and see if your problems go away. Why are you using two 2.5m cables?

snipped-for-privacy@gmail.com wrote:

Yes, I'm using a camera link interface. I'm generating a 140 MHz clock (3.5 x 40 MHz) and using both rising and falling edges to achieve the desired 280 MHz clock.

378 Mbps is the camera data rate, id est, it sends 30 fps (each frame is 1024 x 1024 pixels of size and each pixel is digitized with 12 bits).

A bad skew could be the problem, I think i'll try to implement de-skew on the v4 (I don't know how yet) and if it doesn't work i'll use a pre- fpga stage using the ni receiver...

I have to use the described cable because my application needs to pass through two walls and needs to have two discontinuities (in order to fit the mechanical and optical subsystems)

Yes i'm using a camera link interface. I generating a 140 MHz clock (3.5 x 40 MHz) and using both rising and falling edges to achieve the desired 280 MHz clock.

My camera is sending 30 fpgs (each frame is 1024 x 1024 pixels of size and each pixel is 12 bits digitized).

A bad skew could be the problem, i think i'll try to use the v4 de- skew features (i don't know how yet) and it doesn't work i'll use a pre-fpga stage including the ni receiver (which works fine)...

I have to use the described cable because in my application such cable must pass through two walls (and it's not possible to change it in order to fit the mechanical and optical subsystems).

Thank you for your answer