適用場(chǎng)景：

對(duì)于一些Timing比較Critical的Path，如果發(fā)現(xiàn)上面有一些Multi-bit Flip Flop(MBFF)，那么可以考慮用這種方式來(lái)修復(fù)。

比如Startpoint是一個(gè)MBFF，從它開(kāi)始的很多Path都有Setup的違反，那么可能就是由于它被MBFF給Merge了，使得它通過(guò)Useful skew來(lái)解Timing就不是那么的靈活。

因此可以對(duì)Startpoint來(lái)設(shè)置禁用MBFF merge來(lái)解決，可能因此很多Path的Setup違反都被解決了。但是如果只用這種方式的話，Timing不一定會(huì)有所改善，可以再搭配Path Group + Path margin(Innovus里面叫slack adjustment)來(lái)優(yōu)化。

如果一個(gè)模塊或者子模塊里面的很多Path都有上面的問(wèn)題，Timing都比較Critical，那么可以對(duì)它們來(lái)應(yīng)用Path Group + Weight的方式來(lái)修復(fù)，如果它們中很多Startpoint/Endpoint又出現(xiàn)在MBFF里面，那么可以再禁用它們的MBFF merge。

可以在Merge之前的Design database（比如Floorplan的DB）中抓出它們的名字，然后去設(shè)置Disable MBFF merge，為了不對(duì)功耗有太大的影響，設(shè)置的Cell越精確越好（比如抓取所屬的最小的子模塊里面的sequential cell），可以統(tǒng)計(jì)一下它們的數(shù)目，不要太大了。

提示：當(dāng)然，如果你對(duì)功耗的要求不是很高的話，甚至可以完全不用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

優(yōu)化前后結(jié)果對(duì)比：

可以看到，在加了Path Group以及Weight和Path margin之后，Timing改善了很多，在Disable了791個(gè)特定Register之后，Timing又得到了進(jìn)一步的改善，TNS已經(jīng)降低為了原來(lái)的1/3，WNS也是如此。

且MBFF的Ratio并未降低太多，Power與原來(lái)的相比變化不大，甚至還稍微低一點(diǎn)。

因此這兩種方式對(duì)于解決Timing問(wèn)題都是可以的，額外使用Disable MBFF的方案對(duì)于Timing會(huì)更有幫助。

注意：經(jīng)過(guò)實(shí)驗(yàn)發(fā)現(xiàn)，僅僅Disable 一些指定的MBFF，不搭配Path Group + Weight + Path margin的話，Timing改善可能不大，甚至可能會(huì)出現(xiàn)Timing變差的情況，因此最好一起使用。

如下是Place階段的數(shù)據(jù)對(duì)比：

審核編輯：劉清