跨时钟域的约束

挂在天边的鱼

回复 10# xiongdigc


    没有用vivado，vivado只支持7系的片子，虽然现在有用到7系的片子，但是不多，就没有更换，而且vivado现在其实还处于一个测试版本阶段，让喜欢尝鲜的人去折腾吧，等稳定了，再升级

diyangguang

跨时钟域信号需要在设计上自己保证功能的正确。
约束上，如果你不将两个时钟设定为异步时钟，他们会互相检查的
set false path from A to B and from B to A
or
set async group

这是正解

haitaox

1.如果两个时钟是完全异步的，那么xilinx是不会分析这两条时钟路径的。
2.如果两个时钟频率不同，但是由同一个时钟产生的，即存在相位关系，xilinx会分析这两条时钟路径。

3.跨时钟域的处理一般分为两种，单bit和多bit
3.1.单bit，源时钟域的信号宽度要足够长，大于目的时钟源时钟周期的2倍。目的时钟源用寄存器打两拍，用来消除亚稳态。如果两个时钟域有相位关系，那么需要用多周期的方法约束，multi-cycle和false-path均可。
3.2.多bit，简单的方法是用fifo做时钟隔离，这样简单高效，但是浪费资源。这样就不用再附加其他约束。如果是握手或者使能的方式，异步采样，就需要约束从源时钟域到目的时钟域的时间，可以用from-to datapathonly的方式

xduryan

回复 1# 挂在天边的鱼


     最近我也在看时序约束方面的资料，具体是xilinx的ug612,；我说的这个问题我说说目前我个人的理解。
    跨时钟域首先要看这两个时钟域有无相关性，若有，比方说从一个dcm出来的两个时钟，它们是自相关的，无需加约束，因为dcm的输入时钟已经有一个period约束了，ise会自动为dcm输出时钟衍生出新的period约束；若无相关性，那就是异步时钟，可以用maxdelay，用tig的情况是你确定这条路径不影响时序分析的时候。
     仅仅知道这么多 谢谢 具体参考xilinx文档

挂在天边的鱼

回复 13# haitaox


    如果两个时钟信号是从一个DCM出来，只需要约束输入时钟即可，对于衍生时钟XILINX会自动生成时钟约束。
    如果两个完全异步的时钟，从目前项目中的情况来看，xilinx还是对跨时钟域的部分进行了分析，并尽量满足目标时钟域的时序收敛。

挂在天边的鱼

回复 14# xduryan


有相关性的确实不用约束,xilinx会自动进行约束，但是有些相关时钟之间的跨时钟域信号，我们其实不关心信号到来的时间，也可以主动约束tig或者maxdelay，这样可以给其它逻辑更大的布局布线的空间。
不相关的时钟，用tig或者maxdelay约束就行了，我前面在一个项目上实验了maxdelay和tig，从静态时序分析的结果来看(只看了各个时钟域下面的最差路径)，差别不大。不过tig或者maxdelay约束的越完全，时序裕量就越大(这个测试的不是很完全，大概是这么个趋势)。
所以对跨时钟域的信号或者不关心的路径，最好都进行tig约束。而其它的路径约束、位置约束等，添加的越少，工具越容易通过，当然必要的路径还是都要有的；

haitaox

回复 15# 挂在天边的鱼


    两个完全异步的时钟，比如一个是本地晶振的时钟，另一个是解串恢复的时钟。xilinx是不会分析的这两条时钟时钟的跨时钟域部分的。

lcxi2727

回复 16# 挂在天边的鱼


   FIFO independent clock (BLOCK RAM) 下，双时钟域150M进125M出（进出逻辑关系由FIFO两边两个时域的控制逻辑分别独立控制，行为级功能验证通过），两个时钟由MMCM分别产生。布局布线静态时序出错（FIFO内部）。

请教下，根据FIFO文档，应该对FIFO的wr_pntr做maxdelay和TIG约束？或者是直接把时钟域TIG？
Slack (setup path):    -0.001ns (requirement - (data path - clock path skew + uncertainty))
   Source:               MT/FIFO_I3/U0/xst_fifo_generator/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gcx.clkx/wr_pntr_gc_0 (FF)
   Destination:          MT/FIFO_I3/U0/xst_fifo_generator/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gcx.clkx/gsync_stage[1].rd_stg_inst/Q_0 (FF)

Requirement:          1.334ns
   Data Path Delay:      0.732ns (Levels of Logic = 0)
   Clock Path Skew:      -0.416ns (3.815 - 4.231)
   Source Clock:         clk_150M rising at 6.666ns
   Destination Clock:    clk_125M rising at 8.000ns
   Clock Uncertainty:    0.187ns

lcxi2727

虽然自己解决了，居然一天没浏览记录，这么经典的问题。I服了U

glace12123

跨时钟域处理，必须由自己来保证时序的正确性，约束上就设置为false path。