CDC电路在CP SCAN测试的时候会不会造成扫描连不能测试？

发现目前一颗产品有几个CDC的DFF，就似xxx_ff1,xxx_ff2这种，我都把它做到chain里面了，但是在CP调试的时候发现这几个DFF会fail在好多pattern中，例如我有1000个pattern，他会fail 其中某100多个，导致我只能MASK这条chain测试，大家有木有遇到过这种情况？

另外说明下：我这个在PT和SCAN后仿真都是过的，也就是说这种DFF的timing path在shift和capture模式下都是clean的。。。。。，那会是神马原因导致的呢？ 设计margin不够？
timing lib、不准？

scan的mode有没有遗漏？如果没有遗漏并且timing都是clean的，按理不会出现这种情况吧，难道真是工艺或库有些问题？

mode有遗漏啥意思？ 我也是第一次遇到这种情况，困惑了好久。
问题是其他大部分chain都是ok的，就是其中1、2条chain出现有问题。

后仿过了应该没问题才对，检查一下pt的约束吧

看过这几条timing path了，tree都走的很平，我怀疑是不是timing lib不准确导致的

CP的时候测SCAN pattern啊

yep，统计了一大部分发现都是相关的几个CDC的DFF

其实我觉得在dc scan的时候，这些CDC DFF都在一个时钟域里面，timing也不复杂，如果timing都是clean的，按理不会出问题啊，不明白.....不过不要轻易怀疑库的问题吧，检查一下约束什么的，是不是STA的时候约束有什么问题
另外再问一下，CP是什么意思，学习一下，以前没听到过这个缩写~~

有没有把CDC两边generate的clock设成false path了？

没有，SCAN的时候只有一个clock，而且都是balance的

CP就是 晶圆级测试

不过楼主这个只在一片上的情形还是很多片都是这样？

测了好多片都差不多啊

看来可能是多片，如果仅仅一片上出现这个问题，他不会问这个问题

请问你在scan mode下面，hold timing sign off的标准是什么？工艺是什么水平？

uncertainty hold是10ns。。。。。，。18的工艺啊。。。。。

神呀，10ns的hold timing uncertainty，对于SCAN mode，几乎全是背靠背的scan shift path，你们得插多少delay cell修的hold timing啊？