关于PT的问题，求解？
在encounter里面时序完全正常，但是到了PT里面有四个VIOLATED路径，和pad相关的，这个是咋回事?
PT里面的路径延时如下：
encounter里面相同的路径打印（有没有办法打印出于PT路径一样的格式）：
详细的路径：
比较两者好像在PAD之前就是差很多。
下面是我的PT文件
PT时用到的sdc文件
现在试过在encounter里面把slack设成0.7（继续调大的话会DRC出错），相比之前效果好一点，但slack还是很大。
各种可能
建议先比较同一路径PT和encounter的timing report，看看哪里不同
encounter里面能打印出完整的路径吗/? 我用 report_timing -from -to 打印出上面的路径只有三个器件，
如果encounter连个完整的路径都report不出来，还能在业界混吗?！
出来的路径如果不一样的话，增加-through强迫encounter打出与PT一样的路径
如果encounter说指定的路径没有约束的话，就说明SDC不一致
多谢，我在首页把路径贴出来了，能麻烦帮我看下吗? 我感觉pad之前encounter和PT的延时就不一样了，
试了下 貌似 -through打进去，路径也不会添加，是不是encounter版本太旧的缘故?
需要：
1） encounter 里面report_timing 时，加上 -path_typefull_clock
2） 详细的sdc
估计是sdc的问题。encounter中报的uncertainty 0.2 在PT的报告中都没看到。
sdc文件加进去了，full_type路径也答应出来了。为甚么encounter的时序报告里面，require time 和 arrival time的路径会一致的呢,,,,,,,
我把PT里面的uncertainty remove了，在sdc文件是有uncertainty 0.2，但是在PT（第37行）里面设置了 remove uncertainty，这个影响大吗?
加入了 path_type full之后，看到的那个文件 怎么感觉跟一开始的延时数都不一样。 并且我加了 check_type host。
那个uncertainty不是造成这个问题的原因。呵呵，只是想提醒小编检查一下sdc文件，不仅是PT的，还要检查encounter里用的。看了你最新的报告，发现encounter的报告中，capture路径上QI00300的delay为0，而在PT中这个cell的delay为1.61。能解释一下吗?
FF的clock path（clk-->reg/H02）出的问题，自己安装下面的思路去检查原因，
1）在PT里面，为什么network latency 没有了?
2）在encounter里，为什么前3个cell的延迟为0?
3）为什么前后两次encounter报的clock path延迟不一样?
为啥encounter两次打印出来的路径延时 是不一样的。如果按照下面的不是不能满足slack的要求了吗。我重新report也是这个结果额。
小弟刚开始用pt，很不熟悉，多谢哈。
FF的clock path（clk-->reg/H02）出的问题，自己安装下面的思路去检查原因，
1）在PT里面，为什么network latency 没有了?
2）在encounter里，为什么前3个cell的延迟为0?
3）为什么前后两次encounter报的clock path延迟不一样?
1）这个是不是因为我在PT里面 设置了 set extract_model_with_clock_latency_arcs true的缘故，其他好像没什么相关，PT的sdc文件里面 clock latency 是0.2 的
2)在encounter中 我把一个时钟选择器设为no_propagate了，所以选择器就没延时了，，但为什么PAD没延时就搞不懂了。
3）clock path 是同一次的，就是加了path_type full出现的结果，但没列clk buf 和列了clk buf的结果咋差那么大。
**************
我在PT的SDC中开启了 set driving cell，效果好了一些，但还是有VIOLATION
SDC里面简略报告和详细报告不一样，一个是有的，但一个是没的。，我也不知道为什么会这样。
是不是 就是因为在encounter里面 clk的那个PAD没有延时，导致的?
encounter 设置的问题? 我的sdc文件好像没设置过让时钟理想化的啊
你在encounter中，建立完时钟树后，请用 reset_clock_latency [get_clocks iCLK]，把你之前设置的network latency给去掉。然后，set_propagated_clock [all_clocks] 。因为这时的network latency已经可以计算出来了。
还有用reportAnalysisMode看看clock_Propagation 那项是不是 sdcContrl。
PS: 呃，我这能猜的都猜完了。还不行的话，请小编把你在encounter中用的sdc也贴出来吧。这帖子看得我好揪心，有种越陷越深的感觉。O(∩_∩)O哈哈~
谢谢哈，非常感谢~ 我试试看行不行，
有結果了嗎? 還有即使長完clock tree, 也應該還要考慮jitter效應的uncertainty在裡面..
是你说的那个原因，设置set_propagated_clock之后，时钟PAD的输入延时加进去了，PT和encounter时序有点小差别，但两个都满足了。多谢多谢~
恩，有了，是19楼说的那个原因 ，因为没设置set_propagated_clock的缘故。