首页 | 新闻 | 新品 | 文库 | 方案 | 视频 | 下载 | 商城 | 开发板 | 数据中心 | 座谈新版 | 培训 | 工具 | 博客 | 论坛 | 百科 | GEC | 活动 | 主题月 | 电子展
返回列表 回复 发帖

FPGA时钟管理单元(DCM)结构及使用(下)

FPGA时钟管理单元(DCM)结构及使用(下)

使用DCM可以消除时钟Skew

   使用DCM可以消除时钟Skew。这个东西一直是我以前所没有想清楚的,时钟从DCM输出开始走线到寄存器,这段Skew的时间总是存在的,为什么用DCM就可以消除呢?直到有一天忽然豁然开朗,才明白其原委。对高手来说,也许是极为Easy的事情,但也许有些朋友并不一定了解,所以写出来和大家共享。

    为说明方便起见,我们将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的延迟时间。


对时钟Skew的进一步讨论

    最后,说一说时钟Skew的概念。时钟Skew实际上指的是时钟驱动不同的寄存器时,由于寄存器之间可能会隔得比较远,所以时钟到达不同的寄存器的时间可能会不一样,这个时间差称为时钟Skew。这种时钟Skew可以通过时钟树来解决,也就是使时钟布线形成一种树状结构,使得时钟到每一个寄存器的距离是一样的。很多FPGA芯片里就布了这样的时钟树结构。也就是说,在这种芯片里,时钟Skew基本上是不存在的。

说到这里,似乎有了一个矛盾,既然时钟Skew的问题用时钟树就解决了,那么为什么还需要DCM+BUFG来解决这个问题?另外,既然时钟Skew指的时时钟驱动不同寄存器之间的延时,那么上面所说的Clk_o到Clk_o_reg岂非不能称为时钟Skew?

    先说后一个问题。在一块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。

    由此,我们可以得出一个推论,从晶振出来的时钟作为FPGA的系统时钟时,我们可以不经过DCM,而直接接到BUFG上就可以,因为我们并不在意从Clkin到Clk_o_reg的这段延时。
返回列表