三部分：表頭/launch path /capture path
1.表頭
1）
-
工具版本信息：如示例中的18.10-p001，對某個具體項目timing signoff 工具的版本最好保證一致；
-
操作系統信息：這一項無關緊要。
-
生產日期：這一項還是有看一下的必要，避免低級錯誤，哼哧哼哧debug 了半天，結果report 看錯了的事情是時有發生的。
-
設計：確定是你的設計。
-
命令：確定report 的時候都加了哪些option, 因為極有可能原始腳本不是你自己寫的。
2）
-
Timing path 的起點和驅動時鍾及時鍾的有效沿：示例中分別為my_start_point, clk, 上升沿。
-
Timing path 的終點和驅動時鍾及時鍾的有效沿：示例中分別為my_end_point, clk, 上升沿。
-
Timing path 所在的path group：示例中為clk, 大多數工具默認會為每一個clock 定義一個path group，用戶可以根據需求自定義path group, 如無用戶自定義的path group 某條path 會被歸為該path endpoint 驅動時鍾對應的group.
-
Analysis View：STA 中一個view = 一組具有相同PVT 的std/macro cell + 一個RC corner, 要確定當前View 是否正確。
-
Other end arrival time: capture path 的delay。
- Setup: 從capture 寄存器對應的std cell lib 中查表得到。
- Phase shift: 如果沒有MCP ( multi cycle path ) 設置， 該值即為單個clock 的周期。
- CPPR: 在考慮OCV 的STA 分析中，會分別對launch clock path 跟capture clock path 設不同的derate 值，如setup check: launch clock path 會設一個late 的derate, capture clock path 會設一個early 的derate. 而對於同一段path 在實際中不可能會有不同方向的variation 所以為了剔除悲觀度，工具會將common path 上的這部分影響減除即CPPR; 對於0 沿check ( 如hold check) 除了Variation, CPPR 還會減除common path 上SI 的影響。這也是為什么common path 越長越好的原因。
- Uncertainty: 該值來自SDC, 通常signoff uncertainty = foundry requirest margin + PLL jitter + IR-drop modeling.
- Required time: 在此時間內到達時序即能滿足 = clock period + capture clock path delay + CPPR - Setup - Uncertainty.
- Arrival time: launch data 實際到達時間 = launch clock path delay + data path delay.
- slack: 最終檢驗值，為正該path pass 為負該path 違規 = required time - arrival time.
2.
check RC 的反標：在Tempus 的report 中有一列 "Arc annotation" 會標明每一條net RC 的來歷，如果RC 來自SPEF, 則值為SPEF. 如果有net 沒有正確反標，首先要找出未反標的原因。如果所有net 都已正確反標，再進行下一步
check clock skew: 可分別從launch clock path 跟cpature clock path 中得到到start point clock pin 的clock network delay 和到endpoint clock pin 的clock network delay， 如果skew 過大需要找后端確認是有意為之還是給了一版垃圾數據，至於『大』的定義每家公司每個項目都有自己衡量的標准，有的人認為12已經算大了，但有的人認為18才是真的大，所以請根據自己的需求定義大。如果clock skew 也正常
check derate: std cell 是否有用AOCV, 如果有check derate 的值是否合理，Depth 的值是否合理，是否對net 有設flat OCV, 如果有分別check launch 跟capture path 的derate 值是否合理
check cross talk 引入的delta delay: 先看clock path 上的SI, 如果有較大較多的SI 要去找后端確認，clock path 的SI 要盡量修掉；再看data path 上的SI, 最好把大於某個值的SI 對應的net 都抓出來在layout 上看一下，然后再確定fix 的方向
check clock common point: 確認時鍾分叉點，是不是時鍾分叉太早，如果common path 非常短需要跟后端確認是否可以做長。
如果以上都合理，就需要詳細check 每一級的cell 跟net delay, 最好在layout 上把該條path highlight 出來，先check 是否有cell 堆疊的情況尤其是buffer 跟inverter 的堆疊，如果有，需要找后端確認；再check delay 較大的某些cell 的輸入transition 跟fanout 是否合理，如果transition 太大需要確認是由於前一級的驅動能力太弱還是輸入net 太長造成的，如果fanout 太大需要找后端確認；再check delay 大的net, 在layout 上量一下該net 的距離，對於什么類型的cell 能驅動多長的net 自己心里要有數，而這個數是由對所用工藝研究得到的，如果某個cell 驅動了超出其能力所及的net 如果不能通過cell swap 解決，就找后端。
