Design Compiler REPs看不懂？看这一篇就够了！

前言：

预综合完成后，如何check dc REPs是IC设计人员必须具备的专业技能。Synopsys 综合工具会按照不同的类别生成许多的.rpt文件供设计人员check，比如Check_timing.rpt是用来检查约束是不是有漏掉的port，这里不一一列举，重点说明一下xxx.timing.rpt。

下面的内容是取自：DC report_timing 报告分析（STA）_北方爷们的博客-CSDN博客

       每一个path都有专属的slack，slack值可以是正，0或者负。某一个path拥有最坏的slack的话则称之为 critical path

       critical path拥有最大的负slack值。若是所有的path都没有时序违规，则slack都是正数，此时最小的那个slack则是critical path。

        负数critical paths意味着某一组的path都是critical path。

路径可以被分组(group)来得到各自的时序分析，时序报告。

【时序报告】示例
Startpoint: I_RISC_CORE/I_INSTRN_LAT/Instrn_1_reg_27_
　　　　　　 (rising edge-triggered flip-flop clocked by SYS_2x_CLK)
Endpoint: I_RISC_CORE/I_ALU/Zro_Flag_reg
　　　　　　 (rising edge-triggered flip-flop clocked by SYS_2x_CLK)
Path Group: SYS_2x_CLK
Path Type: max

Point                                                 Incr                Path
----------------------------------------------------------------------------------
clock SYS_2x_CLK (rise edge)                          0.00                0.00
clock network delay (propagated)                      0.51                0.51
I_RISC_CORE/I_INSTRN_LAT/Instrn_1_reg_27_/CP (senrq1) 0.00                0.51 r
I_RISC_CORE/I_INSTRN_LAT/Instrn_1_reg_27_/Q (senrq1)  0.62                1.13 f
I_RISC_CORE/I_INSTRN_LAT/Instrn_1[27] (INSTRN_LAT)    0.00                1.13 f
I_RISC_CORE/I_ALU/ALU_OP[3] (ALU)                     0.00                1.13 f
I_RISC_CORE/I_ALU/U288/ZN (nr03d0)                    0.36 *              1.49 r
I_RISC_CORE/I_ALU/U261/ZN (nd03d0)                    0.94 *              2.43 f
I_RISC_CORE/I_ALU/U307/ZN (invbd2)                    0.35 *              2.78 r
I_RISC_CORE/I_ALU/U343/Z (an02d1)                     0.16 *              2.93 r
I_RISC_CORE/I_ALU/U344/ZN (nr02d0)                    0.11 *              3.04 f
I_RISC_CORE/I_ALU/U348/ZN (nd03d0)                    0.28 *              3.32 r
I_RISC_CORE/I_ALU/U355/ZN (nr03d0)                    0.29 *              3.60 f
I_RISC_CORE/I_ALU/U38/Z (an02d1)                      0.15 *              3.75 f
I_RISC_CORE/I_ALU/U40/Z (an02d1)                      0.12 *              3.87 f
I_RISC_CORE/I_ALU/U48/ZN (nd02d1)                     0.06 *              3.93 r
I_RISC_CORE/I_ALU/U27/ZN (nd02d1)                     0.06 *              3.99 f
I_RISC_CORE/I_ALU/Zro_Flag_reg/D (secrq4)             0.00 *              3.99 f
data arrival time                                                         3.99


clock SYS_2x_CLK (rise edge)                          4.00                4.00
clock network delay (propagated)                      0.47                4.47
clock uncertainty                                    -0.10                4.37
I_RISC_CORE/I_ALU/Zro_Flag_reg/CP (secrq4)            0.00                4.37 r
library setup time                                   -0.37                4.00
data required time                                                        4.00
--------------------------------------------------------------------------------
data required time                                                        4.00
data arrival time 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　-3.99
-------------------------------------------------------------------------------
slack (MET) 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　0.01

        报告开始显示了路径的起点，路径终点，路径组名和路径检测的类型。此例中，路径检测类型path type为max，意味着最大的延时或者setup check，若是min则是最小的延时或者hold check。

        data arrival time 下面的 clock SYS_2x_CLK 这里表示clk的period，如果为异步report，这里则会为max_delay约束：

        同时，报告也显示了从起点到终点之间的一个个点的延时值。纵列有三个标识， Point， Incr和 Path，分别表示了路径中的各个点，此点所需要的延时和从起点一直累积到此点的延时值。（一般是6列：point、fanout扇出值、trans传输延时、incr器件延时、path、attributes延时类型）

r/f 对齐的是path列

星号(*)表示了使用了SDF文件中的延时值，r和f表示 上升或者下降沿。

这里解释一下什么是SDF：

标准延迟文件SDF：主要包含了网表中所有器件的延迟信息，用于时序仿真；通常情况下，在仿真过程中会使用由PT报出的sdf，因为PT会结合后端工具，生成延迟更为精确的sdf文件。

路径由source reg的CP端开始，到object的D端结束。表中的data arrival time表示了从载入时钟沿到终点数据到达所经历的时间。

再用required time减去arrival time 则得到了slack值。

上述报告中的 clock net delay （propagated）指clock tree 延迟。

例子中显示的slack非常小，意味着时序约束很勉强的达到要求。若是负数则需要改变设计来修复此violation，例如使用速度更快的LVT（替换掉SVT）。

反过来说，若是slack值相当大，则说明了此路径还有很多优化的机会。例如换成更小更慢的driver来减少面积，或者更高阈值的driver来减少leakage power。

博主在blog中还对一个例子进行了详细的解释：

timing 报告有四个主要部分：

第一部分【路径信息部分】

主要报告了：工作条件operateing condition；

                      使用的工艺库：ssc_core_slow；

                     时序路径的起点和终点：data1，u4

                     路径所属的时钟组：clk

                     报告的信息是作建立或保持的检查：max，

                     所用的线负载模型

第二部分【路径延迟部分】

       这个路径延迟部分是DC计算得到的实际延迟信息；命令执行后，对于下图中的路径，得到的一些路径信息，有了单元名称（point），通过该单元的延时（Incr）,经过这个单元后路径的总延时等信息：

如上图中所示：

路径的起点是上一级D触发器的的CP端。

input external delay:(由于上一级D触发器的翻转(路径的起点也就这里)、芯片外部组合逻辑而经历的)输入延时约束（set_input_delay），通俗的说就是IO约束加的延时,可以看出这个延时是1ns;

”r”表示上升延时，”f”表示下降延时

clock network delay(idle):时钟信号从芯片的端口到内部第一个寄存器的延时是0.5ns；

Data1(in):芯片输入端口到芯片内部真正数据输入端之间的线延时，是0.04ns。（可以认为是管脚的延时）

U2/y : 这里，前面0.12表示u2这个器件的翻转/传输延时，意思是从这个器件的数据输入端（包括连线），到输出端y的延时是0.12ns。后面的1.66的意思是从路径起点到u2的y输出的延时是1.66ns.

…

最后u4/D：这里就是终点了，D触发器的数据输入端；当然终点也可能是芯片的输出端口。

报告中，小数点后默认的位数是二，如果要增加有效数(字)，在用report_timing命令时，加上命令选项“-significant_digits"。报告中，Inc:是连线延迟和其后面的单元延迟相加的结果。如要分别报告连线延迟和单元延迟，在使用report_timing命令时，加上命令选项"-input_pins"。

第三部分【路径timing 要求部分】

  这里要注意几点比较重要：

      【1】clock（rise edge）为2.0，这是capture clk的 T period = 2，因为分析的是setup， 所以 capture clk 的时间为2。

      【2】0. 06从库中查出的DFF的建立时间，- 在这里理解为减。值2.17为2.23-0.06

      【3】这里rpt的是setup的timing，所以rpt的是capture clk的path timing。

这里我计划详细说明一下，其实最根本的还是要理解setup time和hold time的原理：

我们有看到clock uncertainty 这里是 减去 0.27，回忆一下setup 分析T data 和 T capture clk要满足的关系：Tcap + Tskew > T data + T clk_launch，这里不就是调整的是Tskew嘛，懂了吗？

set_clock_uncertainty -setup 0.27 [get_clock clk]

path margin ：

有的report这里还有path margin 选项，原理一样的，区别是path margin可以松可以紧，怎么理解可以松可以紧呢？就是T skew可以通过sdc设置大小。

set_path_margin -/+2.0 -setup -from [get_ports xxx] -to [get_ports xxx]  

比如：

设置：

再次report path timing： 

 可以看到path margin变为了0.5，Tskew 变大了。

这里的 -表示放松，+表示收紧。 

clock network delay：

是不是还有看到clock network delay（ideal/propagated），这是啥？这是时钟信号从port上进来走到DFF/CP上的时间，即clock的latency。

ideal是指理想情况下clk tree没有delay，propagated是指由于tree balance引入的delay

set_clock_latency -rise 0.5 [get_clock clk]

第四部分【timing总结部分】

       进行时间比较。数据要求2.17ns前到达（也就是数据延时要求不得大于2.17ns），DC经过计算得到实际到达时间是2.15ns，因此时序满足要求，也就是met，而不是时序违规（violation）。时间冗余(Timing margin)，又称slack，如果为正数或‘0’，表示满足时间目标。如果为负数，表示没有满足时间目标。这时，设计违反了约束(constraint violation)。

check & debug

在预综合结束后，我们可以启动dc_shell来report某一个path的timing情况，dc_shell的相关命令后续我会专门整理blog来梳理。

这里只说一个report_timing,同时需要说明的是dc_shell命令的help命令是 man xxx

我们check timing一方面是check 设计的时序violation，另一方面也要关注sdc下的是否合理。

比如在上面的报告中， 外部的input delay为22 ns，对于时钟周期为30 ns的设计，显然是太大了，一般input/output delay 设置T*0.6。

       设计中，关键路径通过6个缓冲器，需要考虑这些缓冲器是否真的需要；OR单元的延迟为10. 72ns，似乎有问题。

       关键路径通过四个层次划分模块，从模块u_proc，经模块u_proc/u_dcl，经模块u_proc/u_ctl，到模块u_int。前面我们说过，DC在对整个电路做综合时，必须保留path的hier，因此，逻辑综合不能穿越模块边界，相邻模块的组合逻辑并不能合并。这4个层次划分模块使得DC不能充分使用组合电路的优化算法对电路进行时序优化，是否考虑需要进行模块的重新划分。

查看分组优化结果：

主要是查看路径分组之后，路径的时序情况是什么样的。