Enconter做完PR后用自身的工具做时序检查跟单独生成spef后导入PT做检查加过不同

RT，工具是encounter8.1，当我做完PR后用report_constraint检查时序错误的时候，工具出的report没有任何问题，但是里面却有一行乱码，就没太在意，但是当把spef文件生成出来后，再放到PT里做时序检查却有一个多个hold的错误，现在很头疼该怎么去处理，因为如果一个一个手动的加buff太难受了，想问问看大家遇到这样类似的问题了没?如果有是怎么去处理的~24小时等结果！谢谢~

乱码是啥?
EDI出的和PT出的是应该有差距的，差距越小越好。
考虑修正rc factor或者约束紧一点处理.

这个差距还是蛮大的，我encounter里的时序都没有出violated，但是pt里却报了很多的hold问题，而且最差的violated达到了-2.01，所以后来我把时钟频率改为了原来频率的70%去综合，然后做PR的时候又释放回原来的频率，可是还是没有改善，出现的hold的错误encounter不去优化处理，不知道小编说的加紧约束是具体指什么约束?我这个代码里没有分频涉及，只是一个主时钟，时钟的处理也就是set了一些latency、uncertainty、transition这些，不知道小编你的意思是把这些约束加紧吗?

约束有问题吧，差2ns，EDI还不给修
你把出错的路径分别在EDI和PT报出来，对比一下看看，然后分析下

请教一下小编，对于input delay和output delay是如何设置的呢，我看论坛里有前辈问过，但是自己还是不太理解，貌似这个也是靠一个经验值来综合的，想对于这个约束问问~谢谢啦

一般来说接口约束看你的系统要求吧，最好留点margin出来

还有一个问题是关于sdc的，小编你说在做CTS之前导入encounter里的sdc文件和做完CTS之后导入的sdc用于route的文件是不一样的吧?可能最不同的就是cts之后会使用set_propagated_clock吧，请问还有什么不同吗?对于latency和uncertainty、transition这些有需要修改的吗?他们的值会去变化吗?

sdc文件是否不同根据设计需要定，不能一概而论
CTS之后，时钟树产生了，工具是按照实际的clock tree的情况来分析了。

没错啊，我就在想如果CTS后时钟树已经生成了，那是不是set clock latency、set clock uncertainty、set clock transition这些相关数据也会改变呢?毕竟以前都是估计值，现在可以带入实际情况了

是啊，变成实际的了。看timing的时候工具就是用实际的数据了，你set的这些都没用了

那那些set留在里面也没什么影响吧?工具是不会理会的，而是用实际的，是这个理解对吧?

虽然工具有default的做法，但是用不用sdc的约束是可以控制的，建议你再查阅下UG看看
具体项目具体要求具体应对吧

上善若水，水善利万物而不争

没懂，啥意思?

估计你的sdc 在 hold 上设置有问题。

这个应该没什么问题吧?我在PR之前也基本按照这个sdc文件来跑的PT

理论上来说，enounter和ＰＴ用同一个sdc不会差这么大，还是需要把这条path报出来，看看具体差别在哪里?建议encounter也用spef-in的flow再报timing, 用-reportOnly的选项，摒除RC的因素。

这么大的差异，只能说encounter的setting可能有问题，没有和PT做correlation,要不然不会差的这么离谱。