DFT模式下hold的修复
由于芯片时钟树长短不一，在插scan chain时将各个时钟树的FF都串在一条链上。DFT的hold违例主要就是各时钟树不平衡造成的，而且违反比较大。因低功耗的要求，不允许将各时钟树都做平，否则冗余的时钟树要消耗额外的功耗。这种情况下应该从哪里入手进行改善修复呢?期待回答！
注：由于MCMM下不允许动时钟树来修复DFT的hold，而其违例很大，因此直接修复效果有限！
自己顶一个！期待各位大牛能够给出有效的办法解决！
不同时钟下的FF在scan chain时，要加lockup latch
那是插入DFT时必要的一步
如果小编是因为同一时钟不平衡的话，比如要用到useful-skew，latch 也没用啊。
我曾经在所有FF旁先贴一delay cell来解决这个问题，不知道是否是行业常用办法?
(如果是后加，density导致很多放不下。）
这个问题可以写到FAQ或者考题中。
另外可以自己写script，重新调链的前后顺序，从理论上或许更好。
就不知道影响pattern覆盖率不?
根据你的描述，HOLD发生在SCAN模式下，两个CLOCK TREE 之间有timing path的HOLD 违例，这种情况在综合时，应该有LATCH加入。先检查这个LATCH，这个LATCH能借半个周期。
如果是同一个CLOCK的HOLD违例，先看CLOCK TREE为什么没有做平。
我曾经在所有FF旁先贴一delay cell 这个应该是你的设计有问题
有两点原因树没有做平。一个是功能模式下用到了useful skew，人为造成时钟树不平。另一个原因就是原时钟树很复杂，而DFT模式下却只有一个时钟，将功能模式下的时钟全部含括，有些时钟路径与功能模式下的不一致。Lockup latch是预防shift，而capture下不起作用。在DFT模式下有些sram的bypass电路也会产生因时钟树不平造成的hold违例。
的确，加lockup cell或者delay buffer都只能解决shift path的hold，小编先看下这种hold违例路径多不多，不多就让dft 工程师给mask掉；
一般这种难修的hold path的start point与end point出现在两个不同的function clock domain上，可以让dft工程师修改测试电路始终，分clock domain来做capture，从而这条path上startpoint与endpoint的capture时钟可以为异步。
现在发现在DFT的hold违例路径很多都是功能模式下的假路径或者异步关系路径，所以才显得很多。这些路径是否需要都修复?