innovus中path group 的策略和应用（下）

BPG（basic path group）和PG（path group）的异同

INVS默认使用了BPG，但是基于SDC理论下PG（path group）也是天然存在，两者在数据库里边有各自存在的方式，也可以共融共生中，通过其中的异同，看到INVS的一些有趣的处理。

BPG （basic path group）timeDesign报告简析

如果用户没有在SDC里边使用任何的group_path命令，INVS默认就会是使用BGP进行分组（PS：这点和S家的有区别）。
用户在导入数据库后，通过timeDesign就可以看到类似下面的分组关系：

【图1】timeDesign summary

这个分组表达了BGP的基本理念，但是注意，这里的数量有些许差异：

(default – reg2reg – reg2cgate) - all = (125024+787+479) - 125882 = 408。

所有BGP的path总量竟然要比all 要多！
这个是因为：all 是基于EP的path核算，一个EP点就对应1，如果某个EP有路径展开，譬如：FF1 -> FF0 和 INPUT -> FF0 ，这样在default里边就会再出现以FF0为EP的path。这里称为：EP展开

为了验证这个理论，尝试做一下IO的set_false_path操作，然后再用timeDesign

【图2】disable IO timing

【图3】timeDesign summary with IO timing disable

这里的default=0说明所有的EP都没有二次展开，可以明确的看到：

reg2reg + reg2cgate = 125024 + 787 = all = 125811

PS：无论用户是否通过group_path调整分组，timeDesign的all的值是不会发生变化的。可以利用这个信息，查看用户EP展开路径的数量：

EP展开路径 = all – [user_group_path_count_sum | BGP_path_count_sum]

BPG和PG（path group）的兼容

虽然INVS拥有自己独创的BGP，但是在兼容传统SDC的大前提下，INVS当然也支持了用户自定义的path group。
通过下图理解BPG和PG的关系：

【图4】BPG/PG with INVS DB

可以看到，通过group_path命令定义PG的优先级是大于BPG的，任何时候用户使用了group_path 命令，那么原始的BGP就会被完全替代，（PS：两个系统只能居其一，不能同时存在）。无论用户的group path定义是否完备，都可以让INVS从BPG进入到PG系统：

譬如下例：这里用户只使用了group_path 定义了一个组

【图5】timeDesign with user PG

可以看到，由于用户定义的组没有timing path，所以整个系统的path都归集为了default，此时，系统已经切换到PG了。
尽管如此，用户依然可以通过all path数量来评估自己的EP展开问题，这个和BPG是一样的，无论是在那个系统，all的信息是一致的，INVS的底层逻辑其实并没有发生改变。
但是，如果用户定义的分组很多，这个在做place_opt_design的时候，INVS采用了更多的iteration进行收敛，这个和INVS基于BGP EP 的优化方式是类似的不同，只不过分组变多会直接导致iteration变多。也会简介导致时序收敛的问题。

【图6】datapath optimization per-HEPG

工具会把所有的HEPG （high effort path group）在这里描述一下TNS/WNS，同时，后续的正常修复也是集中在HEPG组的（如Active Path Group行所示），所以HEPG越多，工具的考虑就会越多。
PS：这里注意，default带了一个 * ，其实他也是一个high effort组，

report_timing对BPG和 PG 的支持

由于BPG是系统默认的分组方式，INVS把BPG设定为为隐性的（implicit），而把用户使用group_path的分组定义为显性的（explicit）。无论是那个系统，data path optimization的工作方式是没有区别的，甚至在timeDesign的时候也是看不出来区别的。
但是对于report_timing命令系统，INVS处理还是略有不同：

BGP下的report_timing 命令使用

report_timing 后面跟的-group选项，需要制定的是显性组（explicit），如果这里用户使用了BPG的隐性组（implicit），工具返回错误：

【图7】BPG下，report_timing不能指定的非default组

那这里问题来了，数据库里的group都去哪里了。

INVS使用了BPG和PG里边都有的一个公共组：default 巧妙的处理了这个问题：

【图8】BGP下defaut组的形态

可以看到，在BPG下，所有的path对应于report_timing的path_group都回归到了default。可以视为对隐性组的一个简单管理方法。

但是，这里还有一个点需要探究：

INVS用户都知道，一个timing path里边会有很多属性，如果在BPG下，report_timing借用了default组，那么这个属性何去何从呢？

如果是使用-path_group 指定 default组，这个会返回设计里边所有的timing path
如果用户去query这个某个path的path_group_name属性，这个会立刻现实类似S家的策略：所有的EP都是基于clock domain的，同时你也可以看到S家里边熟悉的异步和clock gating 组，譬如下面的统计结果

【图9】BGP按照clock domain进行隐性分组

所以这个时候，用户又可以用上述的path_group进行report_timing 报告了，尽管你在get_path_group得不到上述的组。INVS这里有一次巧妙地利用了implicit的语境。

report_timing -path_group CLK_1

这个可以被是为BPG的隐形福利，这种处理方式较为方便用户在使用BPG的时候查验数据。

PG下的report_timing 命令使用

PG下，由于用户都是使用了SDC标准的group_path命令，这个时候所有定义的组，在data path optimization和report_timing下都是完全统一的，这里就不做过多的赘述了。

BPG对实现人员的启发

INVS的BPG对于multi-clock per FF给出了比较好的解决方法。相较而言，后端工具更善于对单纯的数据进行分析和优化，过于复杂的环境处理的结果，经测试明显会变差不少，并且runtime 和area都变得更差一点。

譬如下面的示例：

【图10】设计里的timing path举例

FF0-> FF1/2/3 三条路径都比较critical，直接的感官印象就是到FF1/2/3的timing 很差，如果只是简单的基于FF1/2/3 三个EP分别做组，其实是不利于优化的
因为INVS每一次对HEPG的优化都会把common path和local path推进一次，但是这两类path是会互相牵制的。所以，简单的单分组，并不能很好的解决这类问题。

用户还是需要顺应工具的特点进行约束规划，从而得到自己期望的结果。