什么情况下，一条path既有setup violation，又有hold violation？

抛砖引玉，请大家讨论。
1. 同一条路径，在同样的PVT条件下，setup和hold违例应该是不会出现在同一个寄存器的D端的。
如果是不同PVT条件下，同一条路径，则setup和hold完全可能出现在同一个寄存器的D端。因为PVT条件会影响路径延时。
2. edaboard有相关讨论，但也不太深入。连接如下：
http://www.edaboard.com/thread208395.html

我觉得吧，应该不太有可能吧，setup violation是说数据走的太慢了，hold violation是说数据走的太快了，那么既有setup violation又有hold violation，是不是可以这样理解，数据即太快又太慢?

您好，但是我想，setupslack和hold slack公式中并不是只有组合逻辑的delay一项，还有很多因素，比如skew，Tsetup,Thold，周期T,OCV问题。
这个貌似是一个面试题

时钟jitter过大?

可以具体解释下吗?

xingyun妹妹研究深入啊，这种情况完全可以出现，但是我不知道为什么，研究过没搞懂

2楼回复正解

一般在clock gate的检查时，会出现这样的path。工艺越细，SS corner 和 FF corner下cell的delay偏差越大。由于是高频时钟setup要求路径尽量短，但是路径短了之后，放到FF corner下hold check就过不去了。或者出现小编说的setup和hold同时不过。
要是面试时真有人这么问我，我倒是想问问他，出现这样情况了，他会如何解决。hold和setup他想保哪个。
=======================================================
自己挖的坑，自己来填。O(∩_∩)O~
说保hold，这样的回答是对的，传统思路就是保hold然后setup降频。在面试时，算是一个中规中矩的回答。
但是我想说，如果不允许降频，你又会怎么办呢?
分享一下我们家当时做出的不一样决定。在我们的案例中，有个800M的clock gate路径，同时出现了hold和setup的violation。如果保hold，setup势必要降频，而我们的降频无法做到从800M降频到750M，要降频就是直接降到了400M。而一旦降到400M，不要说性能了，功能都错了。因为对于送入芯片的数据根本处理不过来。这样一来，即使保住了hold，也是个废品。所以当时我们分析了整个产品，不单纯是我们自己设计的芯片，查看板上其他芯片的文档。发现有个芯片工作温度最低是0度，而不是我们的-40度，于是首先调整了我们自己分析hold的corner，换成0度的库分析，hold violation减少了一些，但还是violation。接着又从客户那边了解到，实际使用时，会给产品进行一段时间的预热，所以我们大胆的把分析hold的corner调整到了TT下，hold check是过去的。然后我们对工艺厂这些年生产我们芯片时的良率进行了分析，得出结论是，他家的Process大概率不在FF上，可以用TT分析。最后，我们保证了SS corner下的setup，用TT corner下的hold check代替了传统FF corner下的hold check。
PS：
我相信，理论指导实践，但思维不是死的。分享自己的经历给大家，让这论坛里有不一样的声音。

这还用问 肯定是保hold的啊！

显然hold啊，hold有问题就废了，setup有问题可以降频

我认为就算是同一个PVT也是有可能同时存在setup和hold voilation的，如果频率过高，还有uncertainty ocv noise等等，很容易出现的。

您好，关于你说的同一个pvt，在uncertainty 不合理，T（周期）足够小，ocv_derate影响比较大的情况下，还有skew的情况下，还有lib 的Tsetup和Tck_q不那么合理的情况下，甚至有si影响的情况下，我感觉在同一个pvt下是可以出现同一个endpoint （reg的D端）上setup hold 同时有violation的情况的。
下面举个栗子来验证一下是不是这样的：
比如：在wc pvt下，考虑ocv，hold违约时：derate值（setup和hold的derate一样）是 da和db（da<1,db=1）。作用于clock path 和data path 上。
da*(Tlaunch +Tck_q + Tdata) -(db*Tcapture+Tuncertainty_h + Thold) + crpr <0;
其中Tlaunch 和Tcapture都是在wc的lib分析
在这个hold 有violation的基础上，假设setup 也有violation,
T+da*Tcapture -[db*(Tlaunch +Tck_q + Tdata)+Tuncertainty_s +Tsetup] +crpr <0;
假设不考虑fast slew 和slow slew的影响，ocv只体现在derate 上。则分析用得lib cell 一样都是wc下面的，即两式子中的Tlaunch 和Tcapture 和crpr Tck_q Tdata 相同。
当setup和hold同时有vio时候，上面两个不等式同时满足。
分析后得到（化简消去了Tlaunch分析）：
-da*(Tunc_s+Tsetup) + da*da *(T+da*Tcapture) + (Tcapture+Tunc_h+Thold) +2crpr<0;
da*da*T +(da*da*da+1)*Tcapture + (Tunc_h+Thold)+2crpr< da*(Tunc_s+Tsetup);
其中 da<1,db=1;
下面可以分析了：
<1>当Tunc_s+Tsetup 非常大的时候，即uncetrtainty设置不合理或者lib cell 的Tsetup很大的时候，貌似可以满足。（Tunc_s是setup的uncertainty同理Tunc_h是hold的）;
<2>当不等式左边很小的时候，即：
T很小即：设计很高频。
(da*da*da+1)*Tcapture 很小，即：当da小于1，并且Tcap很短。
Tunc_h+Thold很小，即 Tunc_h很小。
2crpr很小即：common path很短。
其实公式里Tcapture也可以消去，然后按Tlaunch分析，不想再化简了，有兴趣的可以试试。可以判断跟skew有无关系。还有si的影响也没分析......
经过上面分析，这些因素可以导致同时发生setup hold violation。
个人意见，有什么错误和没想到的，请大神们指点。

对于给定的PVT下，hold一定是可以清掉的，只要在data path上加buffer得到足够的delay就可以了，结果是setup变得更加难看而已。

我的意思是想分析甚至人为制造一种情况，在某些变量的影响下，会出现setup和hold同时违约。甚至在真正出现问题时候，怎么分析解决。当然在同一个pvt下面，hold violation可以优先clean，也可以优先把setup violation clean,但是另一个总会变得更差。我不知道我分析的对不对，请指正一下。这些因素设置的不合理是不是可能造成这种情况。

请问，在考虑OCV的情况下，你们一般是将timing derate值只乘到clock path上吗?那Tsetup和Thold,在setup =0.9RT-1.0AT，Tsetup和Thold应该乘以0.9还是1.0?

我同意您的结论，在同样的PVT条件下，如果出现极端的clock uncertainty，inter chip的OCV，以及小的Tperiod，那么setup time和hold time violation可能出现在同一个DFF的D端。不知道其他人有什么看法?
1. 你写的2个红色不等式（hold vio和setup vio），二者中有不同的变量，Tuncertainty_h，Thold，Tperiod，Tuncertainty_s，Tsetup , 人为地调整它们的大小，显然可以让两个不等式同时成立。但是，例子中通过论证合并不等式成立来说明2个不等式同时成立的做法有待商榷。比如，a1<b1, 且a2<b2，则a1+a2<b1+b2，但不能反推。
2. 1中说到可以调整Tperiod(Tp)，Thold(Th)和Tsetup(Ts)的大小让2个不等式同时成立。但是注意应满足Tp>=Th+Ts。否则，不管在数据路径或者时钟路径上增加延迟都不能同时保证setup time和hold time满足要求。

一般情况下，只将timing derate值乘到clock path上，Tsetup和Thold保持不变。

有，data path太长，max和min delay差值很大，可能同时出现setup和hold问题

有两种可能的情况：
1)时钟路径过长，ocv效应过大；
2）路径上的crosstalk过大，对setup和hold都有影响。

有两种可能的情况：
1)时钟路径过长，ocv效应过大；
2）路径上的crosstalk过大，对setup和hold都有影响。

学习了，太好了。