建立时间和保持时间（setup time 和 hold time）

建立时间和保持时间贯穿了整个时序分析过程。只要涉及到同步时序电路，那么必然有上升沿、下降沿采样，那么无法避免setup-time 和 hold-time这两个概念。

1. 什么是setup-time 和 hold-time
不论是在输入，输出或是寄存器-寄存器之间，只要设计到时钟上升沿/下降沿的采样，就会提到setup time 和 hold time。这两个指标说明器件本身不是理想的（时延等），正是这个不理想的特性，限制了工作时钟等。

Setup time is the minimum amount of time the data signal should be held steady before the clock event so that the data is reliably sampled by the clock. This applies to synchronous input signals to the flip-flop.

Hold time is the minimum amount of time the data signal should be held steady after the clock event so that the data are reliably sampled. This applies to synchronous input signals to the flip-flop.

上文是维基百科中的解释，这里很清楚的解释了这两个概念，但是不够具体化。也就是说，这里并没有提及这个值到底等于多少。Xilinx 文档UG612 Page65提到了这两个等式

Setup Time = Data Path Delay + Synchronous Element Setup Time - Clock Path Skew

Hold Time = Clock Path Skew + Synchronous Element Hold Time - Data Path Delay

这两个等式告诉我们的是需求值，Setup Time是时钟上升沿之前的数据所需要的（最小）有效时间，Hold Time是时钟上升沿之后的数据所需要的（最小）有效时间。 Synchronous Element Setup Time 和 Synchronous Element Hold Time可以看作是触发器的固有属性。那么，如何理解这两个式子呢？以setup time为例，hold time具有同样的性质。

首先回到维基百科的解释，其中涉及到data signal 和 clock event，这两个到底指的是什么？对于一个触发器来说，对与直接输入到其内部的clock_in和data_in来说，这个建立时间是 Synchronous Element Setup Time 。这表明了该触发器的属性。回到UG612定义的式子，这应该用下图来解释。

data signal :data

clock event: clk event

那么对于这一种情况，data 和clk延时候到达触发器内部，所以setup Time发生了变化。有Setup Time = Synchronous Element Setup Time + Data Path Delay - Clock Path Skew

2. 如何理解Slack
再谈一个Xilinx公司的术语：Slack。Slack的中文意思是“松弛的”，可以简单的理解为设计余量。即如果slack是正数，那么设计满足要求，否则不满足要求。对于setup time的slack，有

Slack = Requirement - (Data Path - Clock Path Skew + Clock Uncertainty)

Slack = Requirement - (Clock Path Skew + Clock Uncertainty - Data Path)

这里Data Path = Data Path Delay + Synchronous Element Setup Time。而Clock Uncertainty正如其字面意思，时钟不可能完美，时钟的不确定性会使得slack变小，这是符合我们感知的。

这里最值得注意的是Requirement，UG612中的各种 ‘require’把我彻底绕晕了好几次。这里的Requirement来源于约束，即这个设计中能提供的数据在时钟沿之前有效时间的值是多少。而“Data Path - Clock Path Skew ”实际上就是上节中提到的Setup time，这是一个最小值，如果大于这个最小值，那么slack大于0，对应的就是满足要求了。这里没有考虑Clock Uncertainty，Clock Uncertainty如下图所示，带来的影响总是不好的，所以最终的slack还要剪掉这个值。

下图是一个时序图示例，clk和data对应的是节1图中的信号，clk_in和data_in是到达触发器内部的信号。clk和data之间的相位关系表明requirement为一个时钟周期。setup margin是在这一个例子中的slack，由于时钟的不确定性，这个setup margin还需要减去一个clock uncertainty。

Slack: -0.865ns (requirement - (clock arrival + clock path + data path + uncertainty))
Source: OutD_7 (FF)
Destination: OutD<7> (PAD)
Source Clock: clock3_std_bufg rising at 0.000ns
Requirement: 3.000ns
Data Path Delay: 3.405ns (Levels of Logic = 1)
Clock Path Delay: 0.280ns (Levels of Logic = 3)
Clock Uncertainty: 0.180ns