適用場景：

對于一些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

優化前后結果對比：

可以看到，在加了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階段的數據對比：

審核編輯：劉清