原创 静态时序分析（Static Timing Analysis）基础及应用（2）

前言

      在制程进入深次微米世代之后，晶片（IC）设计的高复杂度及系统单晶片（SOC）设计方式兴起。此一趋势使得如何确保IC品质成为今日所有设计从业人员不得不面临之重大课题。静态时序分析（Static Timing Analysis简称STA）经由完整的分析方式判断IC是否能够在使用者指定的时序下正常工作，对确保IC品质之课题，提供一个不错的解决方案。在「静态时序分析（Static Timing Analysis）基础及应用（上）」一文中笔者以简单叙述及图例说明的方式，对STA的基础概念做了详尽的说明。接下来，就让我们藉由实际设计范例来瞭解STA在设计流程的应用。

设计范例说明

设计范例为一个32bit x 32bit的Pipeline乘法器，其架构如图一所示。Pipeline共分3级，电路之输出输入端皆有暂存器储存运算数值。

 

图一

依据Cell-based设计的方式，首先以硬体描述语言设计图一之电路。接下来实作此电路，进行合成（Synthesis）及布局与绕线（P&R）。并在实作的各步骤后进行静态时序分析，确认时序规格是否满足。实作及验证所用到的软体及设计资料库如下所示：

• 合成：Synopsys^TM Design Compiler
• 布局与绕线：Synopsys^TM Astro
•  设计资料库：Artisan^TM 0.18um Cell Library

在接下来的文章中，各位将会看到静态时序分析在实作过程中的应用。藉由实际产生的数据瞭解在不同实做步骤上时序分析的差异。

时序限制（Timing Constraint）

要作静态时序分析，首先要有时序限制。此设计范例的时序限制如下所述。（à后为设定时序限制之SDC指令）

1          时脉规格（Clock Specification）

1.1         週期：6ns à  create_clock -name "MY_CLOCK" -period 6 -waveform. {0 3} [get_ports {clk}]

1.2         Source Latency：1ns à  set_clock_latency -source 1 [get_clocks {MY_CLOCK}]

1.3         Network Latency：1ns à  set_clock_latency 1 [get_clocks {MY_CLOCK}]

1.4         Skew：0.5ns à  set_clock_uncertainty 0.5 [get_clocks {MY_CLOCK}]

2          周边状况（Boundary Condition）

2.1         输入延迟（Input Delay）：1.2ns à  set allin_except_CLK [remove_from_collection [all_inputs] [get_ports clk] ]
  set_input_delay $I_DELAY -clock MY_CLOCK $allin_except_CLK

2.2         输出延迟（Output Delay）：1.2ns à  set_output_delay $O_DELAY -clock MY_CLOCK [all_outputs]

2.3         输出负载（Output Loading）：0.5pF à  set_load $O_LOAD 0.5 [all_outputs]

3          时序例外（Timing Exception）：无

合成软体之时序报告

当Synopsys Design Compiler将电路合成完毕后，执行下面指令可以產生时序报告：

report_timing -path full -delay max -max_paths 10 -input_pins \
-nets -transition_time -capacitance > timing_syn.txt

时序报告会储存在timing_syn.txt此档案中。在档案的开头不远处，会列出此电路最有可能不符合时序规格的路径（Critical Path）。例如：

  Startpoint: S2/B2_reg_0_

                (rising edge-triggered flip-flop clocked by MY_CLOCK)

  Endpoint: S3/P3_reg_47_

              (rising edge-triggered flip-flop clocked by MY_CLOCK)

  Path Group: MY_CLOCK

  Path Type: max

在这个例子中，Critical Path的起点Flip-Flop是第2个Pipeline Stage内的B2暂存器的第0个位元，终点Flip-Flop则是第3个Pipeline Stage内的P3暂存器的第47个位元（图二）。

在Critical Path报告的下方会有Wire Load Model的资讯，此范例使用的是UMC18_Conservative Model。这个Model会以较悲观的方式预估连线的延迟时间（Interconnect Delay）。

 

图二

继续往下检视档案，你会看到Critical Path的详细时序资讯。例如：

Point                                  Fanout       Cap     Trans      Incr       Path

-------------------------------------------------------------------------------

clock MY_CLOCK (rise edge)                                           0.00      0.00

clock network delay (ideal)                                           2.00      2.00

S2/B2_reg_0_/CK (DFFHQX4)                                   0.00      0.00      2.00r

S2/B2_reg_0_/Q (DFFHQX4)                                     0.16     0.30      2.30r

S2/n36 (net)                               1         0.03               0.00      2.30r

S2/U10/A (BUFX20)                                             0.16     0.00      2.30r

S2/U10/Y (BUFX20)                                             0.23     0.21      2.51r

...

...

S3/add_106/U0_5_47/A (XNOR2X2)                              0.18      0.00      7.74f

S3/add_106/U0_5_47/Y (XNOR2X2)                              0.12      0.22      7.96f

S3/add_106/SUM[47] (net)                 1         0.01                0.00      7.96f

S3/add_106/SUM[47] (stage3_DW01_add_54_0)                            0.00      7.96f

S3/N94 (net)                                         0.01                 0.00      7.96f

S3/P3_reg_47_/D (DFFTRXL)                                    0.12      0.00       7.96f

data arrival time                                                                    7.96

clock MY_CLOCK (rise edge)                                             6.00       6.00

clock network delay (ideal)                                            2.00       8.00

clock uncertainty                                                       -0.50       7.50

S3/P3_reg_47_/CK (DFFTRXL)                                             0.00       7.50r

library setup time                                                      -0.28       7.22

data required time                                                                   7.22

--------------------------------------------------------------------------------

data required time                                                                   7.22

data arrival time                                                                   -7.96

--------------------------------------------------------------------------------

slack (VIOLATED)                                                                     -0.74

先由左往右看，第一个直行Point标示出路径中的节点，节点可以是元件的输出入端点，也可以是元件间的连线（Net）。第二个直行Fanout标示节点推动的元件个数。第三个直行Cap标示出节点推动的负载。第四个直行Trans标示出节点上信号的转换时间（Transition Time）。第五个直行Incr标示出节点造成的延迟时间。最后一个直行Path则是自路径起点到到此节点為止的总延迟时间。

再来我们由上往下检视Critical Path的时序资讯。

clock network delay (ideal)                                            2.00       2.00

此处的2ns的clock network delay是由我们给定的时序限制计算而来的，因為我们给定了各1ns的source latency及network latency，加起来共有2ns。

S2/B2_reg_0_/CK (DFFHQX4)                                   0.00       0.00       2.00 r

此行表示Critical Path的起点為S2 Instance下的B2_reg_0_这个instance的CK端点。由於有2ns的network delay，所以时脉信号到达此节点的时间為2ns（图三）。至於0ns的Transition Time则是因為我们没有在时脉规格中定义其数值，合成软体的会假设是一个0ns Transition Time的理想波形。最右边的r是因為这个Flip-Flop是正缘触发，所以以r表示。如果是f就是负缘触发。

  

图三

S2/B2_reg_0_/Q (DFFHQX4)                                    0.16       0.30       2.30 r

接著信号自起点开始向终点传递，这一行表示路径起点的Flip-Flop从CK端点到Q端点的时间延迟為0.3ns，且在此节点的Transition Time為0.16ns。所以信号到达此节点的时间為2+0.3=2.3ns（图四）。最右边显示r是因為Q端点从0变化到1时的延迟时间比1变化到0时的延迟时间还长，如果状况相反的话，最右边会标示f。以上数值是由元件库（Cell Library）裡的时序表（Timing Table）查出来的，其计算的方式请参照「静态时序分析（Static Timing Analysis）基础及应用（上）」。

S2/n36 (net)                               1         0.03                0.00       2.30 r

S2/U10/A (BUFX20)                                              0.16      0.00       2.30 r

这两行和上一行最右边的Path栏位都一样，这是因為其实它们是同一个节点，所以信号到达时间一样。仔细的读者这时候可能会有个疑问，Flip-Flop的Q输出端和后面Buffer的输入端A信号到达时间应该有一个连线延迟（Interconnect Delay）的差距吧？想法上是没错，但因為Design Compiler这个合成器将连线延迟的时间合併到元件延迟（Cell Dealy）的时间内计算，所以从时序报告中看不到延迟时间的资讯。也就是说，如果Point栏是net的话，各位只需去检视Fanout和Cap栏位即可。S2/n36这个net只有推动一个Buffer，其Fanout為1。负载则是Buffer的输入负载和预估连线负载的总和，其值為0.03pF。

 

图四

S2/U10/Y (BUFX20)                                              0.23      0.21       2.51 r

这一行是描述Buffer从输入端到输出端的时间延迟，其值为0.21，所以信号到达Buffer输出端的时间为2.3+0.21=2.51ns（图五）。

接下来是一堆类似的元件时序资讯，我们略过它们不讨论，直接跳到最后面几个元件。

S3/add_106/U0_5_47/A (XNOR2X2)                              0.18      0.00       7.74 f

S3/add_106/U0_5_47/Y (XNOR2X2)                              0.12      0.22       7.96 f

这是到Critical Path终点前的最后一个元件，信号到达的时间是7.96ns。各位可以看到最右边的标示已经变成f了，这表示信号由1变0的状况元件延迟时间较长。

S3/add_106/SUM[47] (net)                 1        0.01                 0.00       7.96 f

S3/add_106/SUM[47] (stage3_DW01_add_54_0)                            0.00       7.96 f

S3/N94 (net)                                          0.01                0.00       7.96 f

S3/P3_reg_47_/D (DFFTRXL)                                    0.12      0.00       7.96 f

data arrival time                                                                     7.96

这几行都是同一个节点的时序资讯，只是逻辑阶层（Logic Hierarchy）不同。信号最后到达Critical Path终点的时间为7.96ns（图六）。以上是Arrival Time（AT）的计算，接下来我们看Required Time（RT）的计算。

 

图五

  

图六

clock MY_CLOCK (rise edge)                                             6.00       6.00

clock network delay (ideal)                                            2.00       8.00

clock uncertainty                                                       -0.50       7.50

S3/P3_reg_47_/CK (DFFTRXL)                                             0.00       7.50 r

library setup time                                                      -0.28       7.22

data required time                                                                   7.22

Critical Path终点的Flip-Flop的时脉输入一样有2ns的network delay，所以本来1个时脉週期后（6ns）要抓取资料就变成了6+2=8ns后抓取资料，也就是Required Time（RT）变成8ns。但因为我们的时脉规格有0.5ns的不确定性（clock uncertainty），以最坏状况考量，时脉提早了0.5ns到，则RT变为8-0.5=7.5ns。再考量元件库中定义的Setup Time 0.28ns，RT就变为7.5-0.28=7.22ns（图七）。

  

图七

data required time                                                                   7.22

data arrival time                                                                   -7.96

--------------------------------------------------------------------------------

slack (VIOLATED)                                                                     -0.74

有了RT和AT就可以计算slack，这个例子的slack值是负的，也就是无法达到时序规格。由於我们只是要以实例说明STA，时序规格不符合也无所谓。实际製作晶片时，这当然是不允许的。

布局完成后之时序报告

在布局完成后，元件摆放的位置已经固定，元件间的绕线及其连线延迟（Interconnect Delay）也就可以大致上预估出来。此时估计的连线延迟会比合成时的Wire Load Model准确许多。以Astro这个布局与绕线软体来说，布局时的绕线预估叫做Virtual Route（VR）。VR会假设两个元件间以最短的可行距离去绕线。各位要注意的是「可行」两字，两元件间不见得所有区域都可以拿来做绕线，Astro的VR会自动避开这些区域。布局后的时序报告和合成时的很类似，也会先标示出Critical Path，然后紧接著是其时序资讯。

*   Start point : S3.B3_reg_4_/CK

*   ( Rising edge-triggered flipflop clocked by MY_CLOCK )

*   End point   : S4.out_reg_63_/D

*   ( Rising edge-triggered flipflop clocked by MY_CLOCK at CK )

*   Clock Group : MY_CLOCK

*   Delay Type  : Max

*   Slack       : -1.0682  (VIOLATED)

各位可以看到，此时的Critical Path和合成时的不一样。这是因为绕线预估不同，造成连线负载及连线延迟时间的估计值不一样，再加上佈局与绕线软体会对时序做最佳化，才会有如此结果。我们先来看看布局后Critical Path的时序资讯。

Port/Pin

Cap      Fanout  Trans.      Incr        Arri        Master/Net

---------------------------------------------------------------------------------

Rising edge of clock MY_CLOCK                  0.0000     0.0000

Clock Source delay                               1.0000     1.0000

Clock Network delay                              1.0000     2.0000

---------------------------------------------------------------------------------

S3.B3_reg_4_/CK

0.0000           0.0000                  2.0000 r    DFFTRX4

S3.B3_reg_4_/Q

0.1501   15      0.5663      0.5307      2.5307 r    B3[4]

S4.mult_123.B3_reg_4_ASTipoInst106/A

0.5839      0.0294      2.5602 r    BUFX1

S4.mult_123.B3_reg_4_ASTipoInst106/Y

0.0231   5       0.3842      0.3252      2.8853 r    S4.mult_123.B3_4_ASThfnNet53

...

...

S4.add_133.U155/A

0.3328      0.0006      8.0590 f    XNOR2X2

S4.add_133.U155/Y

0.0030   1       0.0894      0.2341      8.2931 f    S4.N109

S4.out_reg_63_/D

0.0895      0.0001      8.2932 f    DFFTRXL

---------------------------------------------------------------------------------

Rising edge of clock MY_CLOCK        6.0000      6.0000

Clock Source delay                   1.0000      7.0000

Clock Network delay                  1.0000      8.0000

Clock Skew                           0.5000      7.5000

Setup time                           0.2749      7.2251

---------------------------------------------------------------------------------

Required time                                    7.2251

Arrival time                                     8.2932

---------------------------------------------------------------------------------

Slack                                            -1.0682  (VIOLATED)

这份报告和合成时的报告格式略有差异。合成后报告的Point栏位此时拆成Port/Pin和Master/Net栏位。我们从最上面一列开始检视此报告，Critical Path的起点为S3.B3_reg_4_的CK时脉输入端点，其信号到达的时间为时脉规格所描述的2ns（Source Latency + Network Latency）。接下来信号走到S3.B3_reg_4_的资料输出端点Q，花费了0.5307ns，也就是在2.5307ns时到达此节点。继续往下走，信号会经由绕线接到S4.mult_123.B3_reg_4_ASTipoInst106（通常这种名字的元件是佈局与绕线软体在做时序最佳化时加入的缓衝器或反相器）这个元件的输入端点A，花费了0.0294ns，也就是在2.5602ns时到达此节点。这段绕线软体会给予一个辨识的名称，就是所谓的Net Name，各位可以在报告最右边的栏位查询到Net的资讯。在合成软体的报告中，由於Net的连线延迟被内涵在元件的延迟中，所以永远为零。在佈局与绕线软体的报告中，则会像这样清楚的列出连线的延迟。

报告的后半部和合成时候的报告一样，我们就不加赘述。由於slack值为负，在佈局之后，时序规格不符合的状况仍旧没有改变。

绕线完成后之时序报告

在绕线完成后，不但元件的位置已经固定，所有的绕线的大小形状也都已经确定。此时的时序报告会更接近实际晶片的时序特性。在理想的状况下，佈局后的VR预估应该和实际绕线一致。但事情通常没有这么简单，VR并没有考量到绕线壅塞的问题，实际绕线时可能在某些区域走了太多的绕线，会导致有些连线没办法沿著VR规划的路径走。此时佈局与绕线软体会强迫这些连线绕道通行，而这些绕道通行的连线，其连线距离一定会比VR规划的路径还要更长。这也意味著会有更多的连线负载，因此造成更多的连线延迟，导致时序上的特性变差。接下来，我们就来看看此范例绕线后的时序报告。

*   Start point : S2.A2_reg_9_/CK

*   ( Rising edge-triggered flipflop clocked by MY_CLOCK )

*   End point   : S3.P3_reg_32_/D

*   ( Rising edge-triggered flipflop clocked by MY_CLOCK at CK )

*   Clock Group : MY_CLOCK

*   Delay Type  : Max

*   Slack       : -0.2721  (VIOLATED)

*********************************************************************************

Port/Pin             Cap   Fanout     Trans.       Incr       Arri     Master/Net

---------------------------------------------------------------------------------

Rising edge of clock MY_CLOCK                    0.0000     0.0000

Clock Source delay                                 1.0000     1.0000

Clock Network delay  (propagated)                0.9998     1.9998

---------------------------------------------------------------------------------

S2.A2_reg_9_/CK                       0.1451     0.0000     1.9998 r         DFFHQX4

S2.A2_reg_9_/Q      0.0278      1     0.1576     0.3282     2.3280 r         A2[9]

...

S3.P3_reg_32_/D                       0.1001     0.0002     8.0062 f         DFFTRXL

---------------------------------------------------------------------------------

Rising edge of clock MY_CLOCK                   6.0000   6.0000

Clock Source delay                                1.0000    7.0000

Clock Network delay  (propagated)               0.9854    7.9854

Clock Skew                                          0.0000    7.9854

Setup time                                          0.2513    7.7341

---------------------------------------------------------------------------------

Required time                                               7.7341

Arrival time                                                8.0062

---------------------------------------------------------------------------------

Slack                                                      -0.2721  (VIOLATED)

各位可以看到，Critical Path又换了，原因和布局时的原因类似，一是绕线估算不一致，二是时序最佳化的影响。时序报告的格式和佈局后的报告一样，但内容有一重大的差异，就是时脉的资讯。在佈局之前，时脉的资讯是由时脉规格得来的，这只是一个预估值或称目标值。通常我们会在佈局后，合成时脉树（Clock Tree）来达到时脉规格。要完全百分之百达到时脉规格是件很不容易的事，所以通常绕线时的时脉资讯会和时脉规格定义的有些许差异，这会影响到静态时序分析的结果。

以上面的例子来说，Critical Path起点的Flip-Flop其Clock Network Delay（Latency）变为0.9998ns而不再是时脉规格中的1ns。而终点的Flip-Flop其Clock Network Delay（Latency）则变为0.9854ns，原来0.5ns的Clock Skew则被捨弃不用。如此，计算出来的slack值为-0.2721。很不幸，这仍然是一个负值，时序规格仍然无法达成。

比较布局和绕线后的slack值，各位会发现佈局时的时序特性比绕线后的时序特性优良，这和我们在本小节第一段的结论似乎有所抵触。造成这个现象的原因有二。首先，布局与绕线软体为避免绕线后的时序和布局后的时序差异太大，会在布局时用比较悲观的方式计算时序相关资讯。第二个原因则是在绕线时我们又做了很多最佳化的动作以求达到符合时序规格，所以时序特性比较好。不过，这个例子似乎无法用佈局绕线软体内建的最佳化功能来达到时序规格。必须再回到之前的合成步骤、硬体描述语言撰写步骤，甚至更早的架构规划步骤来修改。