DCM和DLL使用帶來(lái)的思考
圖2黃色:clk00 綠色:clk0(BUFG前) 本文引用地址:http://www.ex-cimer.com/article/190536.htm
圖3
黃色:clk00 綠色:clk2x(2倍頻時(shí)鐘)
圖4
黃色:clk00 綠色:clk90(90度相移)
圖5
黃色:clk00 綠色:clk180(180度相移)
圖6
圖7
對(duì)于時(shí)鐘偏斜的改善也是顯而易見(jiàn)的,原先的clock path skew/delay(也即clock network latency)一般在1到2ns,現(xiàn)在都在-0.5ns到0ns。至于為什么這個(gè)skew值可以是負(fù)值呢?特權(quán)同學(xué)看了很多資料,都只是輕描淡寫(xiě)的說(shuō)DLL是通過(guò)外部的反饋時(shí)鐘,然后調(diào)節(jié)內(nèi)部的延時(shí)實(shí)現(xiàn)最終的skew的減小。從clock skew的定義來(lái)看,時(shí)鐘從輸入到各個(gè)寄存器的延時(shí)不可能是負(fù)數(shù)的,惟一的可能是經(jīng)過(guò)DLL后的時(shí)鐘被整個(gè)的延時(shí)了大約1個(gè)時(shí)鐘周期,從而達(dá)到下一個(gè)時(shí)鐘沿和上一個(gè)時(shí)鐘沿對(duì)齊的效果,那么這個(gè)clock skew為負(fù)值就不難解釋了。
特權(quán)同學(xué)也特意從上電開(kāi)始捕獲了DLL輸出時(shí)鐘(引到了輸出PAD上,這個(gè)延時(shí)也不小),和時(shí)鐘的輸入(FPGA的輸入PAD)做了對(duì)比。發(fā)現(xiàn)確確實(shí)實(shí)有那么一個(gè)相位的調(diào)整過(guò)程。而且這個(gè)相位的調(diào)整是在DLL輸出開(kāi)始時(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上?! ?/span>
圖8 上電的整體信號(hào)捕獲
圖9 產(chǎn)生DLL輸出時(shí)鐘
評(píng)論