setup&hold同时违背的情况

如上图所示，是比较典型的STA分析路径。今天面试的时候，被问到对于这样的一条path，是否存在setup&hold 同时violation的情况。
当时考虑了下，没有想出来。回来回忆，面试官提示要考虑derate的情况，考虑derate的话：
对于setup 而言 max launch delay + max data path delay <= min capture delay -setup + T ①
对于hold 而言 min launch time + min data path delay >= max capture delay +hold②
对于上面的两个公式，我想是不是存在一种这样的情况，就是我的clock tree buffer的级数比较的多，但是组合逻辑路径又比较的小，导致这个时候clock path的延时占据了主要的位置，也就是launch delay和capture delay占据的份额大
可以举个例子，考虑到derate的影响，导致 max launch delay=3nsmin launch time=2ns
max capture delay=3ns max capture delay=2ns
然后有T=1nssetup=0.04 hold=0.03max data path delay=0.8min data path delay=0.6
对于①式 有 3+0.8<=2-0.04+1出现了setup vio
对于②式 有 2+0.6 >= 3+0.03 出现了hold vio
----------------------------------------
不知道这样理解对不对，或者说会不会出现这样的情况?
或者说还有什么其他的情况会同时出现setup&hold vio?

这个问题涛哥在http://bbs.eetop.cn/thread-316442-1-1.html 后端设计FAQ说提到过。
4楼APR中有这么一句话：
hold timing violation与setup violation同时存在，工具无法做了。这种情况多半是SDC的问题，很少是真的，除非那是一个非常特殊的IO timing
面试官提示derate的影响，指的是考虑ocv的影响这一种情况。
但事实上还有很多情况会出现同时出现setup和holdviolation，我遇到过的有：
1.IO path（涛哥提到过）
2.错误SDC（涛哥提到过）
3.ocv（你这个问题中的）
4.clock之间的check
5.data path在setup corner下很长，但在hold corner下很短
6.reg2ram的path, ram的lib setup time和lib hold time都很大
7.有些跨domain的path
……
情况很多

Core出现此问题：慢Corner下时钟路径OCV范围过大
IO出现此问题：快Corner和慢Corener延时差距过大

好的谢谢2# 3#的讲解 后端这个东西还是要有更多经验方面的积累啊

时钟分叉过早，引起setup & hold 同时vio 的可能性比较大，
当然这些的前提都是时钟频率过高，导致setup & hold 没有窗口，
可以想象，掐着hold 去修，如果时钟周期足够长是不会有setup问题的