PBA（Path Base Analysis）想说爱你不容易（静态时序分析基础篇）

本文链接：https://blog.csdn.net/weixin_37584728/article/details/116974681

PBA（Path Base Analysis）想说爱你不容易（静态时序分析基础篇）

文章右侧广告为官方硬广告，与吾爱IC社区无关，用户勿点。点击进去后出现任何损失与社区无关。

在数字 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

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。

秒杀数字后端实现中 clock gating 使能端 setup violation 问题

数字芯片设计实现中修复 setup 违例的方法汇总

之所以我们敢用 PBA 去看最 critical path 的 timing，主要是因为 setup margin 事先预留了（比如 clock_uncertainty, timing_derate 等），而且 gba 本身较悲观。另外也有项目 schedule 和 timing tradeoff 的考虑。

那么，如果在 Timing signoff 最后阶段发现有 3ps 左右的 hold violation, 你会怎么做？这个问题作为思考题，留给大家思考吧。

原来电路最高工作频率是这么算出来的（STA 基础篇）

小编知识星球简介：

在这里，目前已经规划并正着手做的事情：

ICC/ICC2 lab 的编写
基于 ARM CPU 的后端实现流程
利用 ICC 中 CCD（Concurrent Clock Data）实现高性能模块的设计实现
其他内容待定

在这里，各位可以提问（支持匿名提问，提问从此不再害羞），小编会在 24 小时内给予解答（也可以发表你对某个知识点的看法，项目中遇到的难点，困惑或者职业发展规划等）。

反正它是一个缩减版的论坛，增强了大家的互动性。更为重要的是，微信有知识星球的小程序入口。星球二维码如下，可以扫描或者长按识别二维码进入。目前已经有九位星球成员，感谢这九位童鞋的支持！欢迎各位铁杆粉丝加入！

相关文章推荐（不看保证后悔）

一网打尽时钟树综合 Clock Skew

数字后端设计实现之时钟树综合实践篇

【惊呆了！】你居然还在用 flatten 方式进行 timing signoff

数字后端面试问答 No.16-18

合理的时钟结构能够加速 Timing 收敛（时钟树综合中级篇）

数字后端面试问答 No.13-15(每日三问)

【机密】从此没有难做的 floorplan(数字后端设计实现 floorplan 篇)

数字后端面试问答 No.10-12（每日三问）

数字后端面试问题 No.7-9(每日三问)

听说 Latch 可以高效修 hold 违例（Timing borrowing 及其应用）

15 天零基础入门到精通 python - 最全的视频教程

数字后端面试问答 No.4-6（每日三问）

IR Drop 分析之 Redhawk 分析流程

CRPR 能补偿 crosstalk 吗？

原来电路最高工作频率是这么算出来的（STA 基础篇）

数字后端面试问答 No.1-3（每日三问）

秒杀数字后端实现中 clock gating 使能端 setup violation 问题

教你轻松调 DCT 和 ICC 之间 Timing 与 Congestion 的一致性

数字芯片设计实现中修复 setup 违例的方法汇总

数字 IC 设计中 ECO 的那些事，其实并不是事！

Scan chain reordering 怎么用你知道吗？

如何评价数字后端设计中 floorplan 的好坏？

数字后端实现时 congestion 比较严重，你 hold 得住吗？

数字后端实现 place 过程进阶

Final netlist release 前，你应该做好哪些工作?

基于 Physical Aware 的动态功耗优化实现方案

深入浅出讲透 set_multicycle_path，从此彻底掌握它

【大师必备】最全的数字 IC 设计经典书籍电子版下载

你与数字后端大神的差距在这里，快来瞧瞧！

数字后端实现时 congestion 比较严重，你 hold 得住吗？

时钟树综合（clock tree synthesis）基础篇

【福利】数字 IC 后端各种 Userguide 下载

好了，今天的码字就到这里了，原创不容易，喜欢的可以帮忙转发和赞赏，你的转发和赞赏是我不断更新文章的动力。小编在此先谢过！与此同时，吾爱 IC 社区（52-ic.com）也正式上线了。吾爱 IC 社区（52-ic.com）是一个专业交流和分享数字 IC 设计与实现技术与经验的 IC 社区。如果大家在学习和工作中有碰到技术问题，欢迎在微信公众号给小编留言或者添加以下几种联系方式进行提问交流。