（转）基于TimeQuest的reg2reg之Th分析

地址链接：http://blog.ednchina.com/ilove314/225140/message.aspx

 

本想测试一下Optimize hold timing相关选项对时序收敛的影响，无意中让我解决了一个之前没有太深入思考而又隐隐有些不解的困惑。

       因为时序分析不仅仅是Tsu需要达到要求，而且Th也要达到要求。因为在实际设计中往往是Tsu影响着Fmax，所以大家可能在时序分析时更倾向于盯着Tsu看。但是如果Th没有达到时序收敛对于一个设计来说时同样致命的。那么，Quartus II及其Time Quest对Th又是如何进行分析和优化呢？

       先说TimeQuest如何进行Th分析吧，对于IO的hold time分析，TimeQuest是根据我们添加的input min delay或者output min delay进行分析的。

 

因为我们同时也会添加input max delay以及output max delay参数，那么就是说我们限定了与FPGA接口的信号的最快最慢的时序延时，从而TimeQuest根据这些条件进行建立保持时间分析。

对于IO的时序分析，无非时pin2reg或者reg2pin的时序分析，但是还有一个reg2reg的时序分析时不需要我们添加别的时序约束的（除了时钟约束）。那么TimeQuest如何进行reg2reg的分析呢？以往特权同学也忽略了这一点，以为TimeQuest只产生一种时序路径，并利用这个唯一的时序路径延时参数进行reg2reg的建立保持时间分析。所以有时候也在疑惑这一种路径延时参数到底表示的是最快的还是最慢的延时参数呢？因为时序分析中大多时遇到Fmax达不到要求，相应的Tsu也就是关注的重点，那么姑且认为这唯一的路径参数代表的就是最快的路径参数吧。然后便想当然的以为在QII的哪些地方进行设置后可以让TQ分析这个最慢的路径，找来找去好像Optimize hold timing和Optimize fast-corner timing最像。但是资料翻来找去，发现这两个选项似乎是优化路径以达到Th要求。看来这个天真的想法并没有事实依据。

       其实TQ对于大多数的reg2reg路径是会有两条时序路径分析的，一条最快的用于Th分析，一条最慢的用于Tsu分析。特权同学在report timing选项里单选中一条路径进行分析时，就会产生该路径的两条不同的路径参数的slack分析。例如下面选择了计数器sapdiv_cnt[0]到sapdiv_cnt[0]路径，那么在Tsu分析报告里出现了两条路径，它们的slack差别也很大，正所谓最快和最慢的路径。

 

 

 

                                                                        

                                 

       Th的分析报告也同样的给出了两条路径。

  

 

                        

从上面4个路径的分析来看，Th和Tsu各自分析的两条路径其实是相同的两条路径。

如果时序分析里Th无法到达要求，那么大家可以考虑开启选项Optimize hold timing和Optimize fast-corner timing进行优化，本文就不详细讨论。