Multi-bit Flip Flop(MBFF)修复技巧

适用场景：

对于一些Timing比较Critical的Path，如果发现上面有一些Multi-bit Flip Flop(MBFF)，那么可以考虑用这种方式来修复。

比如Startpoint是一个MBFF，从它开始的很多Path都有Setup的违反，那么可能就是由于它被MBFF给Merge了，使得它通过Useful skew来解Timing就不是那么的灵活。

因此可以对Startpoint来设置禁用MBFF merge来解决，可能因此很多Path的Setup违反都被解决了。但是如果只用这种方式的话，Timing不一定会有所改善，可以再搭配Path Group + Path margin(Innovus里面叫slack adjustment)来优化。

如果一个模块或者子模块里面的很多Path都有上面的问题，Timing都比较Critical，那么可以对它们来应用Path Group + Weight的方式来修复，如果它们中很多Startpoint/Endpoint又出现在MBFF里面，那么可以再禁用它们的MBFF merge。

可以在Merge之前的Design database（比如Floorplan的DB）中抓出它们的名字，然后去设置Disable MBFF merge，为了不对功耗有太大的影响，设置的Cell越精确越好（比如抓取所属的最小的子模块里面的sequential cell），可以统计一下它们的数目，不要太大了。

提示：当然，如果你对功耗的要求不是很高的话，甚至可以完全不用MBFF的功能。

[DEV]ilmView 4> redirect disable_mbff_regs.rpt {foreach_in_collection cell [get_cells aaa/bbb/ccc/sub_d/* -filter "is_sequential"] {puts "[get_object_name $cell]"}}

[DEV]ilmView 5> sizeof_collection [get_cells aaa/bbb/ccc/sub_d/* -filter "is_sequential"]

791

优化前后结果对比：

Run	WNS/TNS/FEP	Power	MBFF ratio
Default	-100ps/-1.584ns/216	122.585mW	70.443%
Default + disable MBFF + Path Group + Weight + Path margin	-29ps/-0.573ns/137	122.408mW	70.103%
Default + Path Group + Weight + Path margin	-57ps/-0.876ns/162	122.949mW	70.242%

可以看到，在加了Path Group以及Weight和Path margin之后，Timing改善了很多，在Disable了791个特定Register之后，Timing又得到了进一步的改善，TNS已经降低为了原来的1/3，WNS也是如此。

且MBFF的Ratio并未降低太多，Power与原来的相比变化不大，甚至还稍微低一点。

因此这两种方式对于解决Timing问题都是可以的，额外使用Disable MBFF的方案对于Timing会更有帮助。

注意：经过实验发现，仅仅Disable 一些指定的MBFF，不搭配Path Group + Weight + Path margin的话，Timing改善可能不大，甚至可能会出现Timing变差的情况，因此最好一起使用。

如下是Place阶段的数据对比：

Run	WNS/TNS/FEP
Default	-59ps/-16.176ns/1289
Default + Disable MBFF	-61ps/-22.452ns/1329

审核编辑：刘清