标签：
注意，clock skew只提到了path delay，但是实际上对于destination synchronous element 和source synchronous element而言，时钟的相位可能是不一样的。这一点表现出了时钟的相位和clock skew是独立的两个概念。在前文的OFFSET中，相位的表现为clock arrival time。
上图是一个clock skew的例子，可以看到两个触发器的时钟不是同相的，但是计算clock skew的时候没有必要考虑。以DCM的输出作为参考，源同步元素的路径延时为0.852+0.860+0.639 = 2.351，目的同步元素的路径时延为0.860 + 0.860 + 0.639 = 2.359。故clock skew = 0.008 。
不同情况下，Clock Uncertainty 的计算方式是不一样的，譬如DCM时钟下
Clock Uncertainty = [√(INPUT_JITTER2 + SYSTEM_JITTER2) + DCM_Discrete_Jitter]/2 + DCM_Phase_Error
SYSTEM JITTER定义了整个系统的jitter，受到了电源噪声、板级噪声和系统任何外部jitter的影响。对于clock uncertainty和clock jitter来说，好像并没有什么太值得注意的地方。
Clock Domains
clock domain 的具体定义是什么我并不是特别清楚，我是这样考虑的。对于同步时序电路来说，不可避免的有时钟的存在，比较简单的就是所有的触发器都采用了一个时钟。那么可以认为整个设计中的路径都处于这个时钟的覆盖下，如下图，这两个触发器之间的路径是受到这一个时钟的时钟周期约束的。这种情况称为single clock domain。
但是对于大多数设计来说，情况并不是这样的，譬如DCM可以分出不同相位的时钟。如下图，此时两个触发器的时钟不是一样的，而这两个触发器之间的数据路径连接了这两个时钟。什么是时钟域？域即是区域，时钟的区域，在我看来就是时钟覆盖的范围。下图中触发器之间的路径，一端属于clk20，一端属于clk20_90g，横跨了两个时钟域。注意这两个时钟是一个DCM产生的，时钟相关，因此XST能够对其进行分析。本节内容不谈跨时钟域的问题。
时序报告举例
Slack (setup path): 13.292ns (requirement - (data path - clock path skew + uncertainty))
Source: IntC_2 (FF)
Destination: XorB_2 (FF)
Requirement: 15.000ns
Data Path Delay: 2.594ns (Levels of Logic = 1)
Clock Path Skew: -0.086ns
Source Clock: clk0 falling at 10.000ns
Destination Clock: clk90 rising at 25.000ns
Clock Uncertainty: 0.200ns
以上图为例，计算slack。Requirement取决于两个触发器时钟的相对相位关系。注意到第一个触发器在下降沿采样，第二个触发器相移为90，时钟周期为20ns。结合前文的setup和OFFSET提及的相关概念。这是很好理解的。和OFFSET约束不同的是，OFFSET主要是受到外部信号的相对关系影响，Period则基本取决于设计。通过分析可知，限制最小时钟周期的影响因素在于data path。data path包括了布线延时和逻辑延时。了解到这一点，对之后代码编写是由帮助的。譬如，不能有太复杂的逻辑。（这是因为FPGA的LUT结构输入有限，以4输入为例，逻辑复杂需要LUT级联，那么自然会影响到逻辑延时）
Clock Skew , Clock uncertainly 和 Period
标签：
原文地址：http://www.cnblogs.com/sea-wind/p/4729444.html
