PBA（Path Base Analysis）想说爱你不容易（静态时序分析基础篇）
在数字 IC 后端设计实现中, 我们常常能听到 GBA 和 PBA 这两个概念。特别是在 Timing signoff 最后阶段，碰到有 5ps 的 setup violation，而且很难 fix。这时候大家都会想到能不能 P 掉。这里说的 P 掉，就是指能不能报下 PBA 模式下是否还有 timing margin。今天吾爱 IC 社区的小编跟大家分享下这两个概念以及它们的应用场景。另外，吾爱 IC 微信技术交流群继续对各位开放，需要进群的朋友，可以加小编微信。
什么是 GBA?
GBA 的全称是（Graph Base Analysis）。Primetime 在计算 timing 时，默认是采用 GBA 模式来报 timing 的。以图 1 中 FF1 和 FF2 直接的组合逻辑为例，整条路径为 A–>Y–>B–>Y–>B–>Y–>A–>Z–>D(大家需要搞清楚 slew 和 transition 的区别联系)
图 1 slew propgation
Setup 分析：
对于或门 OR： 在计算 A–>Z 的 delay 时，会采用 B pin 的 transition 做为 input transition(slow slew)。
对于与非门 NAND: 在计算 B–>Z 的 delay 时，会采用 A pin transition 做为 input transition (slow slew)。
对于异或门 XOR: 在计算 B–>Z 的 delay 时，会采用 A pin 或者 B pin 的 transition 做为 input transition(两个 pin 均为 slow slew)。
对于与门 NAN: 在计算 A–>Z 的 delay 时，会采用 B pin 的 transition 做为 input transition（slow slew）。
Hold 分析：
对于或门 OR： 在计算 A–>Z 的 delay 时，会采用 A pin 的 transition 做为 input transition(fast slew)。
对于与非门 NAND: 在计算 B–>Z 的 delay 时，会采用 B pin transition 做为 input transition (fast slew)。
对于异或门 XOR: 在计算 B–>Z 的 delay 时，会采用 B pin 或者 A pin 的 transition 做为 input transition(两个 pin 均为 slow slew)。
对于与门 NAN: 在计算 A–>Z 的 delay 时，会采用 A pin 的 transition 做为 input transition（fast slew）。
所以，对于 setup 而言，GBA 模式下是将某个 standard cell 所有 input transition 中最大的 transition 值作为所有输入的 input transition 来计算 delay 值。而对于 hold 来说，则采用最小的 transition 值来计算 delay 值。
PBA (Path Base Analysis)
对于或门 OR： 在计算 A–>Z 的 delay 时，直接采用 A pin 的 transition 做为 input transition。
对于与非门 NAND: 在计算 B–>Z 的 delay 时，直接采用 B pin transition 做为 input transition 。
对于异或门 XOR: 在计算 B–>Z 的 delay 时，直接采用 B pin 的 transition 做为 input transition。
对于与门 NAN: 在计算 A–>Z 的 delay 时，直接采用 A pin 的 transition 做为 input transition。
所以基于 PBA 的 timing 计算模式，是根据实际 timing arc 上某个 pin 的 transition 值来计算 cell delay 的。
下面再结合一个具体的例子来分析下，以图 2 为例。其中 net delay 和 cell delay 均已标注，如 A pin 连接的 net，其 net_max_delay 为 2.5ns, net_min_delay 为 2.0ns。
图 2 简易电路示意图
图 3 和图 4 分别为 GBA 模式下延迟计算和 PBA 模式下延迟计算示例图。这个例子可以作为数字 IC 后端的笔试或者面试题目，希望各位能够弄清楚。通过这个例子能够得知，有的时候为什么 GBA 和 PBA 结果是一样的。所以在 PBA 下，并不是所有 path 的 timing 会变得更好（重新计算后）。
图 3 GBA 模式下各个路径延迟计算
图 4 PBA 模式下各个路径延迟计算
通过上面的计算，我们知道 A–> Y 的 delay 情况为：
Graph base analysis (Min, Max) : 7.25ns, 10.35ns
Path base analysis (Min, Max) : 7.55ns, 10.10ns
所以在 A–>Y 这段可以得出以下结论：
min_delay_in_GBA < min_delay_in_PBA
max_delay_in_GBA > max_delay_in_PBA
B –>Y 的 delay情况为：
Graph base analysis (Min, Max) : 7.75ns, 10.85ns
Path base analysis (Min, Max) : 7.75ns, 10.30ns
所以在 B–>Y 这段可以得出以下结论：
min_delay_in_GBA = min_delay_in_PBA
max_delay_in_GBA > max_delay_in_PBA
C–>Y 的 delay情况为：
Graph base analysis (Min, Max) : 7.05ns, 9.05ns
Path base analysis (Min, Max) : 7.25ns, 9.05ns
所以在 C–>Y 这段可以得出以下结论：
min_delay_in_GBA < min_delay_in_PBA
max_delay_in_GBA = max_delay_in_PBA
综上所述，我们可以做出如下归纳总结：
min_delay_in_GBA <= min_delay_in_PBAmax_delay_in_GBA >= max_delay_in_PBA
GBA（PBA）的利与弊
通过上面的例子，我们可以得知基于 GBA 的 timing 计算方式会比较悲观。而 PBA 模式下 timing 更真实。既然这样，很多人会想那直接用 PBA 来计算 timing 不是很好。理想是丰满的，现实是残酷的。因为 PBA 模式 timing 的计算方式相对复杂，所以 runtime 会比较久。在大规模的 design 当中，我们如果用 PBA 的模式来进行 timing signoff，势必会导致 run time 成几何指数上升（原来可能跑一个 corner 的 pt 只需要 6 个小时，用 pba 后 runtime 可能变成 26 小时）。
何时用 PBA
在跑完 Primetime 后，我们需要检查下计算 timing 的 slew propagation 是否是选用 worst_slew。命令如下：
pt_shell> printvar timing_slew_propagation_mode
timing_slew_propagation_mode = “worst_slew”
报 PBA 模式下的 timing 命令如下所示。值得注意的是 pba_mode 中 path 和 exhaustive 的区别，建议认真查看手册或者找男人去（Man，这个男人很给力哦）：
# default and recommended
set timing_slew_propagation_mode worst_slew
# recalculate timing path using PBA
report_timing –pba_mode path
get_timing_paths –pba_mode path
OR
report_timing –pba_mode exhaustive
get_timing_paths –pba_mode exhaustive
默认情况下，都是采用 GBA 方式来计算 timing 的。通过上面的介绍，我们也知道 GBA 计算方式简单，runtime 快，但相对悲观。
如果在 Timing signoff 最后阶段发现有 5ps 左右的 setup violation，而且已经优化到极致了（cell 均无法 upsize，clock tree 也没有做 manual eco 的可能性了）。此时，我们可以报下 PBA 模式下 setup 是否可以 meet。
之所以我们敢用 PBA 去看最 critical path 的 timing，主要是因为 setup margin 事先预留了（比如 clock_uncertainty, timing_derate 等），而且 gba 本身较悲观。另外也有项目 schedule 和 timing tradeoff 的考虑。
原文链接：PBA（Path Base Analysis）想说爱你不容易（静态时序分析基础篇）_IC拓荒者的博客-CSDN博客
网友评论