在数字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_PBA
max_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。
秒杀数字后端实现中clock gating使能端setup violation问题
之所以我们敢用PBA去看最critical path的timing，主要是因为setup margin事先预留了（比如clock_uncertainty, timing_derate等），而且gba本身较悲观。另外也有项目schedule和timing tradeoff的考虑。
那么，如果在Timing signoff最后阶段发现有3ps左右的hold violation,你会怎么做？这个问题作为思考题，留给大家思考吧。
联系客服
