DCM和DLL使用帶來的思考

一直以為DCM和DLL說得都是一個(gè)東西，使用了才知道Xilinx的時(shí)鐘管理策略還真得蠻多的，雖說基本的原理上都有點(diǎn)大同小異。

 　　圖1

　　先說DCM，字面上理解就是數(shù)字時(shí)鐘管理單元，主要完成時(shí)鐘的同步、移相、分頻、倍頻和去抖動(dòng)等。而DLL是數(shù)字延遲鎖相環(huán)的意思，是通過長的延時(shí)線達(dá)到對時(shí)鐘偏移量的調(diào)節(jié)，而這個(gè)調(diào)節(jié)是通過比對反饋回來的時(shí)鐘信號實(shí)現(xiàn)同步輸出的。DCM實(shí)際上不止DLL結(jié)構(gòu)這么簡單，它還包括了DFSDPSDSS等組件。官方的說法如下：

　　The digital clock manager (DCM) component implements a clock delay locked loop (DLL), a digital frequency synthesizer (DFS), digital phase shifter (DPS), and a digital spread spectrum (DSS).

　　Xilinx早期的Virtex器件不提供DCM資源，只有CLKDLL，這個(gè)CLKDLL實(shí)現(xiàn)的時(shí)鐘輸出相對單一，但是基本的時(shí)鐘偏斜的優(yōu)化效果還是可以達(dá)到的。簡單的插入語言模板進(jìn)行例化就可以了。需要注意的是時(shí)鐘反饋信號CLKFB不能夠直接和時(shí)鐘輸出CLK0連接，必須讓CLK0先BUFG一下?？梢匀缦逻M(jìn)行例化(不使用的時(shí)鐘可以空著)：

　　CLKDLL #(

　　.CLKDV_DIVIDE(2.0), // Divide by: 1.5,2.0,2.5,3.0,4.0,5.0,8.0 or 16.0

　　.DUTY_CYCLE_CORRECTION("TRUE"), // Duty cycle correction, TRUE or FALSE

　　.FACTORY_JF(16'hC080), // FACTORY JF Values

　　.STARTUP_WAIT("FALSE") // Delay config DONE until DLL LOCK, TRUE/FALSE

　　)

　　CLKDLL_inst (

　　.CLK0(clk0), // 0 degree DLL CLK output

　　.CLK180(clk180), // 180 degree DLL CLK output

　　.CLK270(clk270), // 270 degree DLL CLK output

　　.CLK2X(clk2x), // 2X DLL CLK output

　　.CLK90(clk90), // 90 degree DLL CLK output

　　.CLKDV(clkdv), // Divided DLL CLK out (CLKDV_DIVIDE)

　　.LOCKED(locked), // DLL LOCK status output

　　.CLKFB(clk00), // DLL clock feedback

　　.CLKIN(clk), // Clock input (from IBUFG, BUFG or DLL)

　　.RST(!rst_n) // DLL asynchronous reset input

　　); 　// BUFG : In order to incorporate this function into the design,

　　// Verilog : the following instance declaration needs to be placed

　　// instance : in the body of the design code. The instance name

　　// declaration : (BUFG_inst) and/or the port declarations within the

　　// code : parenthesis may be changed to properly reference and

　　// : connect this function to the design. All inputs

　　// : and outputs must be connected.

　　// <-----Cut code below this line---->

　　// BUFG: Global Clock Buffer (source by an internal signal)

　　// All FPGAs

　　// Xilinx HDL Language Template, version 9.1i

　　BUFG BUFG_inst (

　　.O(clk00), // Clock buffer output

　　.I(clk0) // Clock buffer input

　　);

　　// End of BUFG_inst instantiation

　　黃色：clk00 綠色：clkdv(2分頻時(shí)鐘)

　　

圖2黃色：clk00 綠色：clk0(BUFG前)

　　圖3

　　黃色：clk00 綠色：clk2x(2倍頻時(shí)鐘)

　　圖4

　　黃色：clk00 綠色：clk90(90度相移)　　

　　圖5

　　黃色：clk00 綠色：clk180(180度相移)

　　圖6

　　圖7

　　對于時(shí)鐘偏斜的改善也是顯而易見的，原先的clock path skew/delay(也即clock network latency)一般在1到2ns，現(xiàn)在都在-0.5ns到0ns。至于為什么這個(gè)skew值可以是負(fù)值呢?特權(quán)同學(xué)看了很多資料，都只是輕描淡寫的說DLL是通過外部的反饋時(shí)鐘，然后調(diào)節(jié)內(nèi)部的延時(shí)實(shí)現(xiàn)最終的skew的減小。從clock skew的定義來看，時(shí)鐘從輸入到各個(gè)寄存器的延時(shí)不可能是負(fù)數(shù)的，惟一的可能是經(jīng)過DLL后的時(shí)鐘被整個(gè)的延時(shí)了大約1個(gè)時(shí)鐘周期，從而達(dá)到下一個(gè)時(shí)鐘沿和上一個(gè)時(shí)鐘沿對齊的效果，那么這個(gè)clock skew為負(fù)值就不難解釋了。

　　特權(quán)同學(xué)也特意從上電開始捕獲了DLL輸出時(shí)鐘(引到了輸出PAD上，這個(gè)延時(shí)也不小)，和時(shí)鐘的輸入(FPGA的輸入PAD)做了對比。發(fā)現(xiàn)確確實(shí)實(shí)有那么一個(gè)相位的調(diào)整過程。而且這個(gè)相位的調(diào)整是在DLL輸出開始時(shí)，輸出時(shí)鐘滯后輸入時(shí)鐘將近270度，如圖9所示;圖10捕獲到了更為明顯的相位調(diào)整，即從中線左側(cè)到右側(cè)的變化。正常穩(wěn)定后的輸出如圖11和圖12所示，相位依然滯后而不是負(fù)值那是因?yàn)槲宜东@的這個(gè)輸出時(shí)鐘是拉到了PAD上的緣故，延時(shí)大了一些也在所難免。綠色為輸入時(shí)鐘，黃色為DLL輸出時(shí)鐘引到PAD上。　　

　　圖8 上電的整體信號捕獲

　　圖9 產(chǎn)生DLL輸出時(shí)鐘

　　圖10 明顯的相位調(diào)整

　　圖11 穩(wěn)定的輸出時(shí)鐘

 　　圖12