TimeQuest就一定要搞定——取值为负数的建立时间
0赞在前面的一篇文章中，给出了建立时间检查的基本公式：
1）寄存器-寄存器（Register-to-Register）路径检查：
Clock Setup Slack = Data Required Time – Data Arrival Time
Data Arrival Time = Launch Edge + Clock Network Delay Source Register +μtco + Register-to-Register Delay
Data Required Time = Clock Arrival Time – μtsu – Setup Uncertainty
Clock Arrival Time = Latch Edge + Clock Network Delay to Destination Register
2）输入引脚-寄存器（Pin-to-Register）路径检查：
Clock Setup Slack Time = Data Required Time – Data Arrival Time
Data Arrival Time = Launch Edge + Clock Network Delay to Source Register + Input Maximum Delay of Pin + Pin-to-Register Delay
Data Required Time = Clock Arrival Time – μtsu
Clock Arrival Time = Latch Edge + Clock Network Delay to Destination Register
3) 寄存器-输出引脚（Register-to-Pin）路径检查：
Clock Setup Slack Time = Data Required Time – Data Arrival Time
Data Arrival Time = Launch Edge + Clock Network Delay to Source Register + μtco + Register-to-Pin Delay
Data Required Time = Clock Arrival Time – Output Maximum Delay of Pin
Clock Arrival Time = Latch Edge + Clock Network Delay to Destination Register
在前两组公式中，Data Required Time计算公式的第二项都是 -uTsu。
但是在TimeQuest中对两级级联寄存器的时序分析中，执行report_timing -from [get_ports data_in] -to [get_registers reg1] -setup -npaths 1 -panel_name "Report Timing"却得到了如下图所示的结果，请注意图中Data Required Time的第三行中reg1的uTsu取值：
在Incr一列中，reg1的uTsu取值为0.036ns，在计算公式中作为正数值计入了Data Required Time的结果中。
发现这一现象以后，经过分析，我认为有两种可能：
1. 计算公式正确，但是TimeQuest计算错误。
2. 计算公式正确，uTsu的真实取值是负数，在上图中负负为正，TimeQuest计算正确。
我一直倾向于后一种可能，毕竟TimeQuest是Altera的一个招牌工具，这样明显的错误早就该解决了。但是从Setup时间的定义上看，uTsu又不可能是负值。
后一种可能虽然更合理，但是又没有充足的证据证明这一点，这一数据是Altera给定的，原值是正是负无从知晓，在help里查也没查到，所以我一直对于TimeQuest存有怀疑。
直到今天，我偶然想起前些天计算一个输出引脚的建立时间余量时，在同样的位置看到过一个取值为负的数据。这样看来，Incr一列中，不是只能有正数值，也可以有负数值。
如果这个负值是我指定的，在Incr一列中出现负值就不奇怪了；但是我很清楚地记得，没有什么特殊条件导致我会在时序约束中采用负值。那么，这个负号应该是TimeQuest在计算中刻意加入的。负号可以加入，自然也可以去除，上图中uTsu的负号就可能是TimeQuest去除的。
下面，让我们通过输出引脚的建立时间检查（公式3）来证明一下：
仍然以两级级联寄存器为例，计算公式重写如下：
3) 寄存器-输出引脚（Register-to-Pin）路径检查：
Clock Setup Slack Time = Data Required Time – Data Arrival Time
Data Arrival Time = Launch Edge + Clock Network Delay to Source Register + μtco + Register-to-Pin Delay
Data Required Time = Clock Arrival Time – Output Maximum Delay of Pin
Clock Arrival Time = Latch Edge + Clock Network Delay to Destination Register
Data Required Time中第二项是可以人为指定的。我们通过set_output_delay -add_delay -max -clock clk_in 2.000 [get_ports data_out]来指定Output Maximum Delay of Pin的取值为2ns。
执行TimeQuest建立时间检查命令report_timing -from [get_registers reg2] -to [get_ports data_out] -setup -npaths 1 -panel_name "Report Timing"。得到如下图所示的结果：
可以看到，我们在时序约束中指定的输出引脚延时2ns被作为负数加入了Data Required Time的计算公式中。这样一来，TimeQuest的计算和上面的计算公式就一致了。
同理，在reg1的建立时间余量计算中，uTsu原本是负值，经过计算公式中的一次负号变换，就作为正数加入了Data Required Time的计算公式中。
这样看来，在Altera的器件中，uTsu是作为负值提供给TimeQuest进行计算的。这一负值是器件本身的特性，还是为了补偿计算误差的需要有意加入的，还需要进一步的考证。
相关链接：
could anybody give me a clear picture of negative setup and negative hold ?
Negative setup and Negative hold
Negative setup time and postive hold time?
Method of HDL simulation considering hard macro core with negative setup/hold time
上午给Altera发了一个Service Request，下午就得到了回复：
但是这个回复没有解决我的疑惑，还要继续问：
隔了一个周末，正当我为自己是否说错了话而忐忑时，回复出来了。
感谢Roger，TimeQuest在这一点上是没错的。负的建立时间是特定时序模型的特点，模型在器件上不同的位置具有不同的特征参数。负的建立时间和寄存器靠近引脚有关。我们不必关心，交给工具去处理好了。
