请问下面的一条STA分析路径

Syn2012

大家好!

现在对PR网表进行STA 分析.分析路径如下:感觉该路径有问题:

先说下路径特点,此路径为在scan shift测试模式下的hold分析路径，路径起点为dft compiler工具插入的LOCKUP单元，终点为下一个scan FF 的测试端口TI端.且在scan模式下我只定义了一个clock，名字为ClkAtpg，周期为100ns。

****************************************
Report : timing
    -path_type full
    -delay_type min
    -max_paths 1
Design : HM182_top
Version: D-2009.12-SP3-1
Date   : Sat Jul  6 16:33:12 2013
****************************************

  Startpoint: uHM182_core/uScuTop/uPM/LOCKUP
               (negative level-sensitive latch clocked by ClkAtpg')
  Endpoint: uHM182_core/uScuTop/uScu/uEtStorageSync/SYNCREG0_reg
               (rising edge-triggered flip-flop clocked by ClkAtpg)
  Path Group: ClkAtpg
  Path Type: min
  Min Clock Paths Derating Factor : 1.0000
  Max Clock Paths Derating Factor : 1.0000

  Point                                                   Incr       Path
  ------------------------------------------------------------------------------
  clock ClkAtpg' (fall edge)                            0.0000     0.0000
  clock network delay (propagated)                      2.6582     2.6582
  uHM182_core/uScuTop/uPM/LOCKUP/GN (LATNHD1X_HV)
                                                        0.0000     2.6582 f
  uHM182_core/uScuTop/uPM/LOCKUP/Q (LATNHD1X_HV)
                                                        0.2435 &   2.9017 f
  uHM182_core/uScuTop/uPM/test_so2 (PM)
                                                        0.0000 &   2.9017 f
  uHM182_core/uScuTop/uScu/test_si2 (Scu)              0.0000 &   2.9017 f
  uHM182_core/uScuTop/uScu/uEtStorageSync/test_si1 (ClockSync29)
                                                        0.0000 &   2.9017 f
  uHM182_core/uScuTop/uScu/uEtStorageSync/FE_OFCC1827_n19/Z (BUFHD1X_HV)
                                                        0.1310 &   3.0327 f
  uHM182_core/uScuTop/uScu/uEtStorageSync/SYNCREG0_reg/TI (FFSDRHD1X_HV)
                                                        0.0001 &   3.0328 f
  data arrival time                                                3.0328

  clock ClkAtpg (rise edge)                             0.0000     0.0000
  clock network delay (propagated)                      3.4066     3.4066
  clock reconvergence pessimism                        -0.0001     3.4066
  clock uncertainty                                     0.3000     3.7066
  uHM182_core/uScuTop/uScu/uEtStorageSync/SYNCREG0_reg/CK (FFSDRHD1X_HV)
                                                                   3.7066 r
  library hold time                                    -0.1395     3.5671
  data required time                                               3.5671
  ------------------------------------------------------------------------------
  data required time                                               3.5671
  data arrival time                                               -3.0328
  ------------------------------------------------------------------------------
  slack (VIOLATED)                                                -0.5343

对于此路径，有几点不明白的地方：
（1）首先，该路径的起点时钟(negative level-sensitive latch clocked by ClkAtpg')，这里的ClkAtpg'表示什么意思？为什么出现这个“'”，与我定义的ClkAtpg是什么关系？
（2）当时针周期为100ns时，起点时许单元LOCKUP的负沿时刻应该为50ns,为什么这个地方起点时刻还是0ns。

按照我的理解，DFTCompiler工具在插入扫描链时在不同的模块之间通常会插入一些LOCKUP单元，其主要目的是保证hold的时序更不易违背。但是从该路径报出来的结果看，好像无此体现？

请问这是为什么？

希望高手来关注讨论下！谢谢！

william_liwei

回复 1# Syn2012


    1. ‘ 是反沿的意思

    看起来scan cts 没做好，这个hold 是clock skew 引起的啊

Syn2012

2#willam_liwei

请问为什么会出现这个反沿？由于起点latch和终点dff为不同的模块，所以scan模式下存在skew应该很正常吧！正是为消除不同模块间存在skew对hold的影响，所以scan chain插入了lockup来改善hold时序的影响。不知道我这样理解对不对？

Syn2012

求救啊！

AveryYoung

你这是pr后的sta吧？因为你的sdc中加了propogated的约束，同时你的始终是定义在Atp端。
在始终定一点的前面是不是又个反相器？所以会有符号： ‘

第二个问题，我建议你能不能把部分代码贴出来，才能分析下。
还有就是clock skew差了点，CTS没做好。

tanghaihua

个人理解：
              1、根据报告知这是cts后的时序报告，ClkAtpg'应该是cts后插入时钟网络中的某一invclk的输出，与ClkAtpg反相；
              2、第二个问题，注意看timing_report的start_point和end_point说明。

Syn2012

感谢

tanghaihua

我的问题已解决。主要是因为设计上有很多自己设计的isolation单元。这些cell在时序分析时需要特殊处理。而在primetime时序分析时设置的case不全，导致时钟乱串，经过对full_clock_expaned分析，发现需要对时钟上的一些Mux需要设置case。

Syn2012

感谢

AveryYoung

我的问题已解决。主要是因为设计上有很多自己设计的isolation单元。这些cell在时序分析时需要特殊处理。而在primetime时序分析时设置的case不全，导致时钟乱串，经过对full_clock_expaned分析，发现需要对时钟上的一些Mux需要设置case。

我在scan模式下，只定义了一个时钟，且该时钟定义在端口上，所以应该不存在反相问题。

DemoYe

Syn2012 发表于 2013-7-8 17:53
感谢

我的问题已解决。主要是因为设计上有很多自己设计的isolation单元。这些cell在时序分析时需要特殊处 ...

isolation单元需要如何特殊处理啊？学习一下