|
EDA365欢迎您登录!
您需要 登录 才可以下载或查看,没有帐号?注册
x
DCM概述3 Q* c9 R6 Y% ~% C
6 P D/ b+ J4 y; gDCM内部是DLL(Delay Lock Loop(?)结构,对时钟偏移量的调节是通过长的延时线形成的。DCM的参数里有一个PHASESHIFT(相移),可以从0变到255。所以我们可以假设内部结构里从clkin到clk_1x之间应该有256根延时线(实际上,由于对不同频率的时钟都可以从0变到255,延时线的真正数目应该比这个大得多)。DCM总会把输入时钟clkin和反馈时钟clkfb相比较,如果它们的延时差不等于所设置的PHASESHIFT,DCM就会改变在clkin和clk_1x之间的延时线数目,直到相等为止。这个从不等到相等所花的时间,就是输出时钟锁定的时间,相等以后,lock_flag标识才会升高。% | c# K- R5 [& Y7 n
4 {) e, W1 u3 h
当DCM发现clkin和clkfb位相差不等于PHASESHIFT的时候,却去调节clk_1x和clkin之间延时,所以如果clk_1x和clkfb不相关的话,那就永远也不能锁定了。
; ~: ]- I. C- o! n0 S4 h) t2 d% g8 Q( G1 [1 e
如何使用DCM
/ V7 V+ h; V( l& d5 K: `8 t
7 _6 k$ j4 S. r/ o9 l+ ADCM一般和BUFG配合使用,要加上BUFG,应该是为了增强时钟的驱动能力。DCM的一般使用方法是,将其输出clk_1x接在BUFG的输入引脚上,BUFG的输出引脚反馈回来接在DCM的反馈时钟脚CLKFB上。另外,在FPGA里,只有BUFG的输出引脚接在时钟网络上,所以一般来说你可以不使用DCM,但你一定会使用BUFG。有些兄弟总喜欢直接将外部输入的时钟驱动内部的寄存器,其实这个时候虽然你没有明显地例化BUFG,但工具会自动给你加上的。
5 s5 W, g( |2 s8 V- r8 R. R5 U& s+ h, n( I. [6 U4 b/ T
使用DCM可以消除时钟skew
" [6 S$ q3 O5 a3 ]& u- l+ ]
, l$ @1 r1 A1 ~) G使用DCM可以消除时钟skew。这个东西一直是我以前所没有想清楚的,时钟从DCM输出开始走线到寄存器,这段skew的时间总是存在的,为什么用DCM就可以消除呢?直到有一天忽然豁然开朗,才明白其原委。对高手来说,也许是极为easy的事情,但也许有些朋友并不一定了解,所以写出来和大家共享。
& }5 b' n+ E# J
( f1 ?5 G+ e* f, z+ X% G/ u9 q o6 u为说明方便起见,我们将BUFG的输出引脚叫做clk_o,从clk_o走全局时钟布线到寄存器时叫做clk_o_reg,从clk_o走线到DCM的反馈引脚CLKFB上时叫clkfb,如图所示。实际上clk_o, clk_o_reg, clkfb全部是用导线连在一起的。所谓时钟skew,指的就是clk_o到clk_o_reg之间的延时。如果打开FPGA_Editor看底层的结构,就可以发现虽然DCM和BUFG离得很近,但是从clk_o到clkfb却绕了很长一段才走回来,从而导致从clk_o到clk_o_reg和clkfb的延时大致相等。总之就是clk_o_reg和clkfb的相位应该相等。所以当DCM调节clkin和clkfb的相位相等时,实际上就调节了clkin和clk_o_reg相等。而至于clk_1x和clk_o的相位必然是超前于clkin, clkfb, clk_o_reg的,而clk_1x和clk_o之间的延时就很明显,就是经过那个BUFG的延迟时间。. ?- @, B9 P% m- p* [. [
7 _( F% Y$ g! i ]) q$ J
对时钟skew的进一步讨论4 G' J* @, `# o# h. P
4 q: K! n- C- J9 T5 i
最后,说一说时钟skew的概念。时钟skew实际上指的是时钟驱动不同的寄存器时,由于寄存器之间可能会隔得比较远,所以时钟到达不同的寄存器的时间可能会不一样,这个时间差称为时钟skew。这种时钟skew可以通过时钟树来解决,也就是使时钟布线形成一种树状结构,使得时钟到每一个寄存器的距离是一样的。很多FPGA芯片里就布了这样的时钟树结构。也就是说,在这种芯片里,时钟skew基本上是不存在的。
! V* e- X( u( K9 Q# Y
9 K. x5 k( a# K说到这里,似乎有了一个矛盾,既然时钟skew的问题用时钟树就解决了,那么为什么还需要DCM+BUFG来解决这个问题?另外,既然时钟skew指的时时钟驱动不同寄存器之间的延时,那么上面所说的clk_o到clk_o_reg岂非不能称为时钟skew?
8 M# }2 I% z7 A0 p. R
9 {! w- n9 d3 j) W, k5 i$ p, L" D先说后一个问题。在一块FPGA内部,时钟skew问题确实已经被FPGA的时钟方案树解决,在这个前提下clk_o到clk_o_reg充其量只能叫做时钟延时,而不能称之为时钟skew。可惜的是FPGA的设计不可能永远只在内部做事情,它必然和外部交换数据。例如从外部传过来一个32位的数据以及随路时钟,数据和随路时钟之间满足建立保持时间关系(Setup Hold time),你如何将这32位的数据接收进来?如果你不使用DCM,直接将clkin接在BUFG的输入引脚上,那么从你的clk_o_reg就必然和clkin之间有个延时,那么你的clk_o_reg还能保持和进来的数据之间的建立保持关系吗?显然不能。相反,如果你采用了DCM,接上反馈时钟,那么clk_o_reg和clkin同相,就可以利用它去锁存进来的数据。可见,DCM+BUFG的方案就是为了解决这个问题。而这个时候clk_o到clk_o_reg的延时,我们可以看到做内部寄存器和其他芯片传过来的数据之间的时钟skew。6 Z, E; M- H c7 E& f9 D7 f/ K
- y1 S8 C# i9 V( X D2 X. Y由此,我们可以得出一个推论,从晶振出来的时钟作为FPGA的系统时钟时,我们可以不经过DCM,而直接接到BUFG上就可以,因为我们并不在意从clkin到clk_o_reg的这段延时。$ {% x) r) }8 B8 S; l4 d( b' q
|
|