Hello, I've implemented a camera link deserializer interface based on a virtex 4 FPGA (using ML402 development board). I'm using the LVDS 2.5 V inputs of the board and a cable with one end open. The module works fine when i use a short cable. However, my application needs to use a long cable (with a discontinuity) which doesn't work so fine. The thing is that I guess there is a match problem in the board reception side, because when i represent the eye diagram of the incoming signals (once it's converted to LVTTL) and the long cable is used, it's really bad. I know that it is possible to use this long cable because it works with a generic frame grabber. I've tried using the DCI (Digital Control impedance) of the FPGA, LVDS_EXT standard... but i don't reach a solution... If someone could have some experience in this field... Thank very much in advace !
Camera link interface
Started by ●May 15, 2008
Reply by ●May 15, 20082008-05-15
On 15 May=FDs, 04:41, Crhono...@gmail.com wrote:> Hello, > > I've implemented a camera link deserializer interface based on a > virtex 4 FPGA (using ML402 development board). I'm using the LVDS 2.5 > V inputs of the board and a cable with one end open. > > The module works fine when i use a short cable. However, my > application needs to use a long cable (with a discontinuity) which > doesn't work so fine. The thing is that I guess there is a match > problem in the board reception side, because when i represent the eye > diagram of the incoming signals (once it's converted to LVTTL) and the > long cable is used, it's really bad. > > I know that it is possible to use this long cable because it works > with a generic frame grabber. > I've tried using the DCI (Digital Control impedance) of the FPGA, > LVDS_EXT standard... but i don't reach a solution... > > If someone could have some experience in this field... > > Thank very much in advace !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.
Reply by ●May 15, 20082008-05-15
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.
Reply by ●May 15, 20082008-05-15
Have you instantiated the differential input buffers (IBUFDS) with the diffterm generic set to true?
Reply by ●May 15, 20082008-05-15
On May 15, 7:41=A0pm, Crhono...@gmail.com wrote:> Hello, > > I've implemented a camera link deserializer interface based on a > virtex 4 FPGA (using ML402 development board). I'm using the LVDS 2.5 > V inputs of the board and a cable with one end open. > > The module works fine when i use a short cable. However, my > application needs to use a long cable (with a discontinuity) which > doesn't work so fine. The thing is that I guess there is a match > problem in the board reception side, because when i represent the eye > diagram of the incoming signals (once it's converted to LVTTL) and the > long cable is used, it's really bad. > > I know that it is possible to use this long cable because it works > with a generic frame grabber. > I've tried using the DCI (Digital Control impedance) of the FPGA, > LVDS_EXT standard... but i don't reach a solution... > > If someone could have some experience in this field... > > Thank very much in advace !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
Reply by ●May 15, 20082008-05-15
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<0>" LOC = "AC20" ; # X0NEG NET "cam2_in<1>" LOC = "AB20" ; # X0POS NET "cam2_in<2>" LOC = "AD21" ; # X1NEG NET "cam2_in<3>" LOC = "AE21" ; # X1POS NET "cam2_in<4>" LOC = "AD20" ; # X2NEG NET "cam2_in<5>" LOC = "AE20" ; # X2POS NET "cam2_in<6>" LOC = "AC19" ; # CLKNEG NET "cam2_in<7>" LOC = "AD19" ; # CLKPOS NET "cam2_in<8>" LOC = "AB18" ; # X3NEG NET "cam2_in<9>" 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 <Crhonos04@gmail.com> wrote in message news:aaab7574-dcb3-49ce-a927-9ecb5926d1a0@34g2000hsf.googlegroups.com...> Hello, > > I've implemented a camera link deserializer interface based on a > virtex 4 FPGA (using ML402 development board). I'm using the LVDS 2.5 > V inputs of the board and a cable with one end open. > > The module works fine when i use a short cable. However, my > application needs to use a long cable (with a discontinuity) which > doesn't work so fine. The thing is that I guess there is a match > problem in the board reception side, because when i represent the eye > diagram of the incoming signals (once it's converted to LVTTL) and the > long cable is used, it's really bad. > > I know that it is possible to use this long cable because it works > with a generic frame grabber. > I've tried using the DCI (Digital Control impedance) of the FPGA, > LVDS_EXT standard... but i don't reach a solution... > > If someone could have some experience in this field... > > Thank very much in advace !
Reply by ●May 16, 20082008-05-16
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 Crhonos04@gmail.com wrote:> Hello, > > I've implemented a camera link deserializer interface based on a > virtex 4 FPGA (using ML402 development board). I'm using the LVDS 2.5 > V inputs of the board and a cable with one end open. > > The module works fine when i use a short cable. However, my > application needs to use a long cable (with a discontinuity) which > doesn't work so fine. The thing is that I guess there is a match > problem in the board reception side, because when i represent the eye > diagram of the incoming signals (once it's converted to LVTTL) and the > long cable is used, it's really bad. > > I know that it is possible to use this long cable because it works > with a generic frame grabber. > I've tried using the DCI (Digital Control impedance) of the FPGA, > LVDS_EXT standard... but i don't reach a solution... > > If someone could have some experience in this field... > > Thank very much in advace !
Reply by ●May 16, 20082008-05-16
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
Reply by ●May 16, 20082008-05-16
> 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 cablesI'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.> idest? Brad Smallridge AiVision
Reply by ●May 17, 20082008-05-17
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? JPiqueras.M@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
