Xilinx DCM_ADV 280MHz no lock

Hi,

I am trying to generate a serial bit clock for a Camera Link interface and I am having trouble going from 40MHz to 280MHz. I am committing two DCMs for this task, one using the FX output to go from 40 to 140 MHz (7/2), and another DCM using 2X output to go from 140 to 280. The FX output locks OK and the divided output looks OK on the scope. The 2X lock output seems to lock intermitently, trying to get to high, and the 2X divided output is "fuzzy".

I probably need some sort of timing restraint or perhaps I don't understand what Xilinx is doing with this auto_callibration on the dcm_adv wizard. Can somebody help me out. Here is the code:

library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL;

library UNISIM; use UNISIM.VComponents.all;

entity top is port( sys_rst_in : in std_logic; gpio_exp_hdr2 : in std_logic_vector( 7 downto 6); -- HDR2 diff gpio : out std_logic_vector(3 downto 0) ); -- LEDs end top;

architecture Behavioral of top is

signal reset : std_logic; signal cam1_xclk : std_logic;

signal test_counter_1 : std_logic_vector( 9 downto 0); signal test_counter_2 : std_logic_vector( 9 downto 0); signal test_counter_3 : std_logic_vector( 9 downto 0);

signal cam1_clk7xdiv2 : std_logic; signal cam1_lock7xdiv2 : std_logic; signal cam1_clk7x : std_logic; signal cam1_lock7x : std_logic;

component dcmfx2 port( clkin_n_in : in std_logic; clkin_p_in : in std_logic; rst_in : in std_logic; clkfx_out : out std_logic; clkin_ibufgds_out : out std_logic; clk0_out : out std_logic; locked_out : out std_logic ); end component;

component dcm_140_280 port( CLKIN_IN : in std_logic; RST_IN : in std_logic; CLK0_OUT : out std_logic; CLK2X_OUT : out std_logic; LOCKED_OUT : out std_logic ); end component;

begin

cam1_dcmfx2 : dcmfx2 port map( clkin_n_in => gpio_exp_hdr2(6), -- 40 MHz clkin_p_in => gpio_exp_hdr2(7), -- Differential pair rst_in => reset, clkfx_out => cam1_clk7xdiv2, -- 140MHz clkin_ibufgds_out => open, clk0_out => cam1_xclk, -- 40 MHz locked_out => cam1_lock7xdiv2 );

cam1_dcm_140_280: dcm_140_280 port map( CLKIN_IN => cam1_clk7xdiv2, -- 140 MHz RST_IN => reset, CLK0_OUT => open, CLK2X_OUT => cam1_clk7x, -- 280 MHz LOCKED_OUT => cam1_lock7x );

reset

Reply to
Brad Smallridge
Loading thread data ...

"Brad Smallridge" schrieb im Newsbeitrag news: snipped-for-privacy@corp.supernews.com...

Hi Btad,

What device are you using? In spartan3 -4 I have seen DCM fail somewhere about at 270MHz, but I think most other devices should actually go up to 280

but for 280 cameralink there is no need for 280 Mhz at all you can implement it all by 140MHz clock using both clock edges

Antti

Reply to
Antti Lukats

I am not familiar with the CLKFX outputs of the DCM, but...

When a DCM is locking, it is not guaranteed to generate a stable clock; the output clock is only guaranteed to be stable once the LOCKED output goes high. Since you are cascading two DCMs, the second DCM is trying to attain lock on the output of the first DCM. But, right after reset, the second DCM is seeing an unstable clock. Once a DCM fails to lock properly (due to an unstable input clock), it will not try again until its reset is asserted.

Therefore, I think you need to hold the second DCM in reset until the first DCM locks (this is mentioned in several app-notes). In fact, it is a good idea to delay the deassertion of RESET on the second DCM until a few clocks after the first DCM locks (an SRL is useful for doing this.

Doing this will probably fix your problem.

Avrum

I

for

understand

Can

Reply to
Avrum

ds099 for Spartan3 / jitter-calculator for Virtex2: The FX-output of first DCM's output will have a worst-case-jitter of

740ps
formatting link
whereas only 300ps are allowed for CLKIN of 2nd DCM's input !

Cheers Jochen

Reply to
Jochen

Wow. That's it exactly. I inverted the first DCM lock and fed it to the second DCM reset and all the clocks scope good now. I'll play around with adding a delay, as you suggested, later.

Thank you ever so much.

Brad Smallridge aivison.com

Reply to
Brad Smallridge

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.