08-17-2010 10:14 AM
We have a design, originally implemented on a VP50, which interfaces to 4 off TI ADS5271, 8 channel lvds output AtoD converters. In essence the design was based on xapp774 with additional phase control of the dcms based on xapp268.
(Whilst we could have reworked along the lines of xapp866 we have currently chosen to at least bring up the legacy code with suitable modifications to reflect Virtex-5 architecture.)
Each block of 8 channels has its own bitclock (lclk) and frame clock (adclk). Each lclk is taken as the input to a DCM to generate a global clock that is used for the ddr i/o and subsequent serial to parallel conversion stages for a given block of 8 channels. The lclk inputs, in order to balance trace lengths and signal skew on the pcb, are brought onto the chip through normal i/o buffers adjacent to the data input pins and adclk (hence do not use dedicated routing to the dcm). The dcm is supported by a phase alignment scheme where the incoming lclk is also sampled at the i/o pin and the internal routing delay compensated for by this aligment scheme. Thats what is supposed to happen.
What appears to be happening at the moment is that the DCMs in the Virtex-5 are failing to lock to the incoming lclk at frequencies below about 180MHz though the data sheet indicates that 120MHz should be the minimum operation frequency (in high frequency mode). When we drive the ADCs with anything below about 33MHz (which gives an lclk of 200MHz) the DCM does not indicate lock even if hard reset. It also does not appear to be generating the ctlclk (a div by 3 or 4 on the input clock. Without reloading we can switch between say 167MHz and 240MHz and reset the DCM in between. In all case it locks at the higher freqency but not at the lower.
Attached code for the dcm instantiation:
DCM_ADV DCM_INST (
/*synthesis CLKFX_DIVIDE = 2 CLKFX_MULTIPLY = 1 DUTY_CYCLE_CORRECTION = "TRUE"
DFS_FREQUENCY_MODE = "HIGH" CLKOUT_PHASE_SHIFT = "VARIABLE" PHASE_SHIFT = -255
CLKDV_DIVIDE = "3.0" DLL_FREQUENCY_MODE = "HIGH" CLKIN_DIVIDE_BY_2 = "FALSE" */ // Synplicity attributes
/*synthesis attribute CLKFX_DIVIDE of DCM_INST "4" */ // XST attributes
/*synthesis attribute CLKFX_MULTIPLY of DCM_INST "2" */
/*synthesis attribute DUTY_CYCLE_CORRECTION of DCM_INST TRUE */
/*synthesis attribute DFS_FREQUENCY_MODE of DCM_INST HIGH */
/*synthesis attribute CLKOUT_PHASE_SHIFT of DCM_INST VARIABLE_CENTER */
/*synthesis attribute PHASE_SHIFT of DCM_INST "-255" */
/*synthesis attribute CLKDV_DIVIDE of DCM_INST "3" */
/*synthesis attribute CLKIN_DIVIDE_BY_2 of DCM_INST FALSE */
/*synthesis attribute DLL_FREQUENCY_MODE of DCM_INST HIGH */ ;
BUFG rxclk_bufg (.I(rxclkdcm), .O(rxclk) ) ;
08-22-2010 10:32 PM
This may be the result of the clock Jitter. Please check the clock Jitter. Too much Jitter will also make the DCM can not Lock.
I advice you to use the internal PLL to try this again. It may be helpful.
I didn't check your settings. But I advice you to use the Instantiation Template:
.CLKDV_DIVIDE(2.0), // Divide by: 1.5,2.0,2.5,3.0,3.5,4.0,4.5,5.0,5.5,6.0,6.5
//7.0,7.5,8.0,9.0,10.0,11.0,12.0,13.0,14.0,15.0 or 16.0
.CLKFX_DIVIDE(1), // Can be any integer from 1 to 32
.CLKFX_MULTIPLY(4), // Can be any integer from 2 to 32
.CLKIN_DIVIDE_BY_2("FALSE"), // TRUE/FALSE to enable CLKIN divide by two feature
.CLKIN_PERIOD(10.0), // Specify period of input clock in ns from 1.25 to 1000.00
.CLKOUT_PHASE_SHIFT("NONE"), // Specify phase shift mode of NONE, FIXED,
// VARIABLE_POSITIVE, VARIABLE_CENTER or DIRECT
.CLK_FEEDBACK("1X"), // Specify clock feedback of NONE or 1X
.DCM_PERFORMANCE_MODE("MAX_SPEED"), // Can be MAX_SPEED or MAX_RANGE
.DESKEW_ADJUST("SYSTEM_SYNCHRONOUS"), // SOURCE_SYNCHRONOUS, SYSTEM_SYNCHRONOUS or
// an integer from 0 to 15
.DFS_FREQUENCY_MODE("LOW"), // HIGH or LOW frequency mode for frequency synthesis
.DLL_FREQUENCY_MODE("LOW"), // LOW, HIGH, or HIGH_SER frequency mode for DLL
.DUTY_CYCLE_CORRECTION("TRUE"), // Duty cycle correction, "TRUE"/"FALSE"
.FACTORY_JF(16’hf0f0), // FACTORY JF value suggested to be set to 16’hf0f0
.PHASE_SHIFT(0), // Amount of fixed phase shift from -255 to 1023
.SIM_DEVICE("VIRTEX5"), // Set target device, "VIRTEX4" or "VIRTEX5"
.STARTUP_WAIT("FALSE") // Delay configuration DONE until DCM LOCK, "TRUE"/"FALSE"
) DCM_ADV_inst (
.CLK0(CLK0), // 0 degree DCM CLK output
.CLK180(CLK180), // 180 degree DCM CLK output
.CLK270(CLK270), // 270 degree DCM CLK output
.CLK2X(CLK2X), // 2X DCM CLK output
.CLK2X180(CLK2X180), // 2X, 180 degree DCM CLK out
.CLK90(CLK90), // 90 degree DCM CLK output
.CLKDV(CLKDV), // Divided DCM CLK out (CLKDV_DIVIDE)
.CLKFX(CLKFX), // DCM CLK synthesis out (M/D)
.CLKFX180(CLKFX180), // 180 degree CLK synthesis out
.DO(DO), // 16-bit data output for Dynamic Reconfiguration Port (DRP)
.DRDY(DRDY), // Ready output signal from the DRP
.LOCKED(LOCKED), // DCM LOCK status output
.PSDONE(PSDONE), // Dynamic phase adjust done output
.CLKFB(CLKFB), // DCM clock feedback
.CLKIN(CLKIN), // Clock input (from IBUFG, BUFG or DCM)
.DADDR(DADDR), // 7-bit address for the DRP
.DCLK(DCLK), // Clock for the DRP
.DEN(DEN), // Enable input for the DRP
.DI(DI), // 16-bit data input for the DRP
.DWE(DWE), // Active high allows for writing configuration memory
.PSCLK(PSCLK), // Dynamic phase adjust clock input
.PSEN(PSEN), // Dynamic phase adjust enable input
.PSINCDEC(PSINCDEC), // Dynamic phase adjust increment/decrement
.RST(RST) // DCM asynchronous reset input
09-11-2010 04:27 AM
(sorry for the delay in replying but we were investigating other aspects of the design)
We have tried inserting plls into each of the lclk paths and see no apparent difference.The pll shows as having locked (viewed with chipscope) and removes the reset from the dcm but the dcm never shows lock (at 125.25MHz).
We have used the full dcm template and again no difference.
Our original 20.875MHz sample clock is derived in a VP50 from a Pletronics 167MHz lvds oscillator via a divide by 4 using a DCM in the VP50 and using the CLKDV (div by 2) output. It is then distributed via a global clock mux buffer to 8 outputs (lvds) each of which drives one of 8 LX220Ts. In the LX220T each clock is input via a global diff clock input and global clock buffer and distributed to internal logic and 4 off sample clock outputs to the TI ADCs . (The TI ADCs have a pll that produces a x6 clock ie 125.25MHz from the incoming sample clock).
Precisely the same circuit is used at 41.75MHz other than the fact that the CLK0 output of the DCM in the VP50 is selected by the global clock mux buffer (rather than the CLKDV). When running at this higher freqency the DCM in the LX220T locks. We would have expected that the jitter, if this were the cause, would be proprtionally the same as it uses essentially the same source path so are still finding it difficult to unuderstand this difference in behaviour at the two frequencies (?)
We have also tried inserting a jitter filter pll _before_ the global clock buffer in the LX220Ts output path (to the ADC) to try to reduce any jitter that may have been on the original distributed clock ... but again see no difference.
09-26-2010 04:00 AM
The Possible reasons for DCM not locking might be due to one of the below reasons
Also http://www.xilinx.com/support/troubleshoot/clocking_debug.htm link helps for debugging
11-12-2010 01:54 AM
I use the DCM for the first time and i find a big problem. my goal is to have a frequency that is tow times faster than the input frequency, knowing that it may take a value between 2MHz and 200MHz. Can i use the dcm (condition on CLKIN)?
Can someone help me
11-12-2010 02:39 AM
You should start a new thread. Combining topics is confusing for everyone involved.
-- Bob Elkind
05-15-2011 07:31 AM - edited 05-15-2011 08:15 AM
Can you give me the XAPP866?
Already answered in one of your three duplicate posts.
Please refrain from duplicate posting.
Please use the website's search facility, it would have provided your answer.
-- Bob Elkind