MBFF的优势和劣势

MBFF是把数个single bit FF（SBFF）被封装（banking/merge）到一个MBFF上，对时序优化有一些影响，具体见下：

面积优势

在std-cell构画的时候，进行逻辑共享，面积有明显提升

功耗优势：由于gate级别的整合，在面积提升的基础上，功耗也有明显收益

时序劣势：

下图示例了SBFF到MBFF的物理布局的转变

SBFF被封装成MBFF后，数据路径的终点会改变，可以变近（如上图FF2），也可能变远（如上图FF1），setup/hold会有变化

SBFF被封装成MBFF后，时钟路径的终点会整合，不能像SBFF对每个单独的SBFF的时钟路径灵活使用useful skew进行精细控制

虽然PPA的优化，MBFF二对一胜出，但是实际情况确实，在中后端几十年以来的timing_driven 实现策略确实这个天平不可忽略的重要因素。具体范例和冲突，本文后面也会单独讨论

MBFF的封装方式

基于MBFF的特性，在整个中后端设计流程中，用户可以在三个地方有选择的进行MBFF的封装操作

RTL阶段

综合阶段

APR阶段

RTL阶段的MBFF封装

基于中后端设计流程，MBFF的第一个入口是RTL，DC用户可以通过synopsys原语来知道DC对RTL相应的设计进行MBFF的构建。PS：并非显性地（explicit）在RTL中例化MBFF，这样会对设计人员带来很大的约束，也不利于后面的流程。

在DC的默认配置下，elaborate命令执行的时候，会对上述设计以及原语解析，会对应输出下列日志：

上述日志表达了两个意思：

使用原语的q0：synopsys infer_multibit "q0"，被封装成了MBFF。（当然需要满足前文所述的MBFF逻辑设计要求）

未使用原语的q1，并未被封装成了MBFF。（即便满足前文所述的MBFF逻辑设计要求）

这里S家也贴心的给中端工程师提供了一个配置供选择。

用户通过变量hdlin_infer_multibit来控制DC elaborate的对应操作。

这个变量有三个选项：

default_none：DC仅仅根据RTL里边的原语infer_multibit进行MBFF识别。如果没有碰到，就不转化MBFF。PS：这个是DC的默认设置。前提是RTL设计人员需要使用原语进行MBFF指定，否则In-compile MBFF flow无法实现MBFF的封装。具体细节见后续描述

default_all: DC根据RTL代码的逻辑连接关系，主动地去做MBFF的识别，无论是不是使用原语infer_multibit，DC都会根据逻辑连接关系，尽量进行MBFF的封装，除非DC遇到禁止MBFF封装的原语（后文会提供细节）。

never：DC工具忽略infer_multibit原语，也不主动去封装MBFF，所以，在elaborate命令下，不会有任何的MBFF封装动作发生

下图截取了三个不同配置下，elaborate命令的日志，MB列的结果有不同

S家为了配合上述变量的灵活使用，当hdlin_infer_multibit配置成default_all的时候，可以使用原语dont_infer_multibit进行排外处理：所有定义这个原语的寄存器，即便用户使用了 hdlin_infer_multibit=default_all的配置，elaborate的时候，也不会对dont_infer_multibit指定寄存器进行MBFF的封装。

如下图示例的q1，即便用户已经使用了default_all，这里在elaborate时，仍然没有发生MB的封装