已解决：后端PR后PT分析难点问题，请高手现身，hold time, sdf,谢谢

我在PR后进行了PT分析，其中读入了PR产生的SDF文件，发现了hold有违背，路径是由输入端CMP0到内部一触发器（被时钟CKMEAS触发），感觉PR没有对这条路径进行优化修复，就是没有对输入端进来加一些buffer来增加延迟。看了astro中的timing report并没有报告这条路径有违反，是不是由于这个原因导致astro没有对输入端加buffer呢。该怎么处理呢?

另外，library hold time全部归为零了，实际上lib中是负值。为什么会是这样?

LZ， 你能把Astro的report也帖上来吗?（很难想象input_delay=0， 在propagated clock下， in2reg会没有hold违反！）

你好，上面的贴图中有report 报告。hold time是违反的。路径是由输入port CMP0都内部一reg, 就是你所说的in2reg，之间没有buffer等器件，所以没有路径延迟。那么我的疑问是：我在DC的脚本中已经加入了set_input_delay -clock CK -min 0 [all_inputs], 期望用来约束hold time。为什么PR中 astro没有对其进行hold修复，就是在reg数据端加些buffer，是不是astro分析不到输入端的时序信息（我试着让astro分析输入端到reg的timing，提示说找不到该路径）? 期待你的帮助，非常感谢！

呵呵， 目的错了吧， input_delay为0， 会让in2reg的setup很好看， hold一般会有问题， 特别是在propagated clock下。
我是很好奇， 你说这条in2reg在Astro下没hold问题?

上面已经说到了在astro找不到 in2reg 的路径，所以没有报in2reg 的时序。这也是我的疑惑之一。只是在PR后的PT中报出in2reg hold time 违反。能够看到in2reg之间的路径没有任何buffer，而时钟具有propagated属性。

我没有让input delay为0，我是让 input delay -min 0,我还设置了 -max的。setup time 分析时还是照着-max的那个最大值来分析。这样分析的setup time才是最悲观的。

1.你在astro中是否有设置set_propagated_clock.
2.你astro中的约束和pt的约束是否一致。比如astro中设置了set_false_path而PT中没有。
3.你的CKMEAS时钟定义是否在input port, 那个1ns的 network_latency是你的clock source latency吧?
你的report_timing加上这个选项我看看：-trans -cap -net -path full_clock_expanded
4.astro的报告也贴上来，否则不好对比。
另外，我没使用过astro，但是一般write_sdf都会有是否包含负延迟的一个选项，你看一下。

astro与pt分析hold time差异，非常之问题，请多多帮忙，谢谢


非常感谢。下面有一些问题，请你帮忙分析，多谢。
系统中要插入scan chain。之前做完DFT之后，产生了一个综合后的sdc。之后导入到astro。后来发现，实际上这一过程由于涉及到scan chain。还必须在时钟树综合之后load 进 关于scan chain的 sdc(要手动写)，之前缺少这个sdc。另一方面，原来在astro gui中Timing setup将disable 了ignore propagated clock选项，但是astro跑出来的时序分析中时钟始终没有propagated属性。后来加入了sdc "set_propagated_clock *" 的命令，astro报出的时序中时钟才有了propagated属性（这其中的原因是什么呢），见图一：

由于是scan flipflop，库里的hold time设计是负值。如图中红框处。

跑完astro，导出sdf文件去做sta, 在PT中报出同一路径，见图二：

此时，reg library hold time 显示为0，并没有像astro用的负值。为什么呢? 难道PT只会去找三个参数中的最大值吗，在下面的sdf中可以看到，如果PT去找最大值的话，肯定找到的就是0了。在这种情况下用0来分析hold time 要比用负值去分析来的更悲观。
同时arrive time的计算上也存在差别，那么这两种哪个更为精确呢? 或者还是以最终的STAR-RC导出的spef去做sta结果最精确，为最终的参考呢?
此时，我去查了下对应reg在sdf文件的参数，见图三：

这里的疑问是，astro导出的sdf，三个参数中，hold time中右边两个参数全为0，这是什么原因导致的?（然而，DC导出的sdf中这三个参数全为负值，感觉DC导出的sdf是正常的）

1.你在astro中是否有设置set_propagated_clock.
之前一直用astro timing setup对话框中将ignore propagated clock取消disable，astro时序报告中时钟始终是理想时钟（沿用DC导出的sdc）。最后在时钟综合完后在命令行加入set "set_propagated_clock *" 指令，astro报出来的时序中时钟具有了propagated属性。
2.你astro中的约束和pt的约束是否一致。比如astro中设置了set_false_path而PT中没有。
可能就是缺少了上面那条指令。
3.你的CKMEAS时钟定义是否在input port, 那个1ns的 network_latency是你的clock source latency吧?
是的，DC中定义的。
这里面最不解的是：
比较astro导出的sdf，和DC导出的sdf，见下：
对于同一个reg port,
DC.SDF: (HOLD (negedge E) (posedge CK) (-0.207:-0.118:-0.118))
astro.SDF: (HOLD (negedge E) (posedge CK) (-0.2395:0.0000:0.0000))
为什么astro导出的SDF右边都是零，和DC不一样，那些零值是怎么在astro中计算出来的呢，哪里的问题啊?
困惑中，急待帮助，谢谢！

因为sdf的格式为min:typ:max，可能你的sdf只写了min，所以typ和max是为0，你看一下应该有全部写的选项的。

在astro dump sdf的界面中没有找到该选项，

是不是astro本来就这样?

试试用astro导出spef格式的延时文件，给PT使用

1. 在astro CTSpostplace optimization之后报不出in2reg的时序，什么原因?
答：在timing setup中将include IO path 选中即可。对于之前没有找到in2reg的路径是由于在timing setup中没有选中include IO path。如果没有选中的话，astro便找不到这种路径便不会对这种路径进行优化。
2. PT读取pr导出的sdf，没有用负值来分析hold time，为什么，怎么办?
答：astro之后，在sdf中，timingcheck一栏，(HOLD (posedge DT) (posedge CLK) (-0.7883:0.0000:0.0000)，PT没有像astro中用那个负值-0.7883去分析hold time，而是用了0去分析hold时间。显然用0去分析hold time要比那个负值分析更加悲观。如果我们不期望这样悲观，可以通过设置让PT去读那个负值来分析。
当时只用了一个库，没有min和max库，所以之前set_opertation_conditions tt_5v_25c， 还有条语句读sdf的：read_sdf ./input/tango_fhv_digital.SDF 这样呢，pt在分析hold time时，默认是读用SDF中sdf_max，sdf中hold time格式：(sdf_min, sdf_typ, sdf_max)。所以读到的是0. 这是read_sdf这条语句默认的。 如果想让pt读到那个sdf_min, 里面对应的是负值该怎么办呢，把 -analysis_type bc_wc这句加到set_opertation_conditions 或者read_sdf 中，都可以是PT的分析模式进入min_max，只有进入该模式，PT在分析hold time的时候才可以读取那个sdf_min, 这样就读到了我想要的负值。

小编在PT之前做过DRC/LVS 以及encounter自带的时序分析工具的STA吗?