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

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）不同。信号最后到达CriticalPath终点的时间為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的networkdelay，所以本来1个时脉週期后（6ns）要抓取资料就变成了6+2=8ns后抓取资料，也就是RequiredTime（RT）变成8ns。但因為我们的时脉规格有0.5ns的不确定性（clockuncertainty），以最坏状况考量，时脉提早了0.5ns到，则RT变為8-0.5=7.5ns。再考量元件库中定义的Setup Time0.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，时序规格不符合也无所谓。实际製作晶片时，这当然是不允许的。

布局完成后之时序报告

在布局完成后，元件摆放的位置已经固定，元件间的绕线及其连线延迟（InterconnectDelay）也就可以大致上预估出来。此时估计的连线延迟会比合成时的Wire LoadModel準确许多。以Astro这个布局与绕线软体来说，布局时的绕线预估叫做VirtualRoute（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（SourceLatency + NetworkLatency）。接下来信号走到S3.B3_reg_4_的资料输出端点Q，花费了0.5307ns，也就是在2.5307ns时到达此节点。继续往下走，信号会经由绕线接到S4.mult_123.B3_reg_4_ASTipoInst106（通常这种名字的元件是佈局与绕线软体在做时序最佳化时加入的缓衝器或反相器）这个元件的输入端点A，花费了0.0294ns，也就是在2.5602ns时到达此节点。这段绕线软体会给予一个辨识的名称，就是所谓的NetName，各位可以在报告最右边的栏位查询到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)

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

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

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

总结

本文对STA在实际IC设计流程中的应用举一范例说明，希望各位在具有实际数据的范例导引下，能对STA的应用有更深一步的认识。(设计服务组/陈麒旭)