Implementation Methods and Applications of Multi-bit (Part 2)

Continuing from the last time, the implementation methods and applications of Multi-bit (Part 1), without further ado, ICer GO!

In-place MBFF Implementation

Compared to the MBFF encapsulation based solely on logical connections, if we consider the actual layout, there is a physical-aware in-place MBFF encapsulation implementation. This approach can be applied in common synthesis flows like DCT/DCG/genus_PLE. Compared to in-compile, the greatest advantage of this in-place MBFF encapsulation is its physical awareness. For example, the following schematic:

It can be seen that the tool encapsulates nearby SBFFs into MBFFs. In simple terms, the tool is more cautious (strict) when encapsulating MBFFs, and correspondingly, the encapsulation ratio of MBFFs naturally decreases.

Taking DCT as an example, it provides an in-place MBFF implementation method: a method for MBFF encapsulation based on synthesis results. The specific implementation method is as follows:

set_multibit_options -mode none
compile_ultra -gate_clock -scan -spg
identify_register_banks
source MBFF_SCR
compile_ultra -gate_clock -scan -incremental -spg

Compared to in-compile, two points need to be noted here:

Skip the MBFF encapsulation step in the compile command
Run the compile command in spg mode
Use the command identify_register_banks based on synthesis results to complete the in-place body swap of MBFFs. The effect is shown in the figure below:PS: The coordinates of the encapsulated MBFF are in the middle position of the original SBFF.
After MBFF optimization, further incremental optimization needs to be performed using compile -incremental to mitigate the QoR impact brought by MBFF.

This in-place MBFF replacement has the following benefits:

Effective MBFF replacement based on actual physical layout situations:

Compared to conventional MBFF, it considers the influence of physical layout, allowing targeted MBFF encapsulation, which is very helpful for the final physical implementation.
Traditional in-compile MBFF encapsulation first performs encapsulation and then optimization, which may lead to optimization limitations.

Selectable encapsulation methods based on WNS can effectively control the impact of MBFF encapsulation on WNS.

In summary, if the in-place method is used for MBFF optimization, the layout results must be passed to the backend layout tools. Therefore, SYN and APR need to work together, and the process for S company is as follows:

# SYN flow:
dc_shell> set hdlin_infer_multibit never|default_none
dc_shell> compile_ultra -gate_clock -scan -spg
dc_shell> identify_register_banks  
dc_shell> compile_ultra -gate_clock -scan -incremental -spg
dc_shell> write_file -format ddc -hierarchy top.ddc

# APR flow:
icc_shell> create_mw_lib ...
icc_shell> read_ddc
icc_shell> ......
icc_shell> place_opt_design -spg ......

It can be seen that S company tightly links this information through the SPG flow. Therefore, if users use the in-place MBFF process, they need to use the SPG process to complete the effective transmission of this information. Compared to the traditional in-compile MBFF process, the challenges of MBFF for APR implementation will be reduced.

MBFF Encapsulation in the APR Stage

From the above description, it can be seen that synthesis can effectively handle the implementation of MBFF encapsulation. Correspondingly, based on the principles of MBFF encapsulation, in addition to the aforementioned SPG MBFF process, the APR stage can also encapsulate MBFF independently to achieve PPA optimization.Commonly seen APR tools in the market are S company’s ICC/ICC2 and C company’s Innovus, both of which can encapsulate MBFF, and the principles are similar. The specific description is as follows:

ICC flow

Based on the breakdown of the place step, it can be divided into three methods:

Flow1: SPG flow, refer to the aforementioned in-place MBFF encapsulation method.
Flow2: coarse placement MBFF flow

icc_shell> create_mw_lib ...
icc_shell> read_verilog
icc_shell> ......
icc_shell> set_banking_guidance_strategy \
		-input_map_file MBFF_map.file \
		-register_group_file MBFF_reg_grp.rpt \
		-output_file MBFF_assembly.tcl
icc_shell> create_placement ...... 
icc_shell> source ./MBFF_assembly.tcl
icc_shell> place_opt_design -skip_initial_placement ......

First configure the MBFF application strategy, then create a coarse layout. At this time, the tool will build the MBFF encapsulation method based on the coarse layout results, which is similar to the in-place MBFF encapsulation process. Then the user will read in the exported file MBFF_assembly.tcl to complete the MBFF encapsulation action. Finally, use place_opt_design for incremental optimization to complete the MBFF encapsulation implementation. The two input files mentioned above:MBFF_map.file and MBFF_reg_grp.rpt are exported by the DC tool using the command write_multibit_guidance_files to guide ICC’s MBFF encapsulation method.

Flow3: place_opt MBFF flow

icc_shell> place_opt 
icc_shell> set_banking_guidance_strategy \
		-input_map_file MBFF_map.file \
		-output_file MBFF_assembly.tcl
icc_shell> create_banking_guidance
icc_shell> source MBFF_assembly.tcl
icc_shell> psynopt

Based on the SBFF netlist, complete the normal place_opt, and then perform MBFF encapsulation based on the physical layout results, and finally do another incremental optimization to complete the MBFF optimization implementation process. As shown in the example below:

INVS flow

Compared to S company’s multiple process choices, C company’s process is relatively simple, which also aligns with the consistent styles of the two companies; S company is detailed and considerate, while C company is direct and efficient.Aside from encapsulating (merging) MBFF, C company also supports splitting MBFF, which only requires direct configuration during the place stage.

invs_shell> setOptMode \
		-multiBitFlopOpt {true| false | mergeOnly | splitOnly} \
		-multiBitFlopOptIgnoreSDC {true | false}

Where:

multiBitFlopOpt==true:  timing_driven MBFF encapsulation and splitting
multiBitFlopOpt==false: prohibits MBFF operations, existing MBFF in the database are unaffected
multiBitFlopOpt==mergeOnly: performs MBFF encapsulation under timing_driven
multiBitFlopOpt==splitOnly: performs MBFF splitting under timing_driven

Any stage that sets the setOptMode configuration, any stage using place_opt_design | optDesign commands will perform corresponding optimizations based on this setting. This option will also be fully saved in the invs database.In any optimized database of invs, the command reportMultiBitFFs -statistics can be used to generate statistical reports on the MBFF replacement results:This evaluation system is somewhat similar to DC, but for expressing the MBFF replacement ratio, it uses Bit Per Flop: on average, the number of FF bits that a single FF can bear. The higher this value, the higher the MBFF replacement ratio, and vice versa.Invs also provides a pin map report file (PS: this needs to be exported in the invs session), the command is:dumpMultiBitFlopMappingFile. This can generate:

The details of the MBFF encapsulation (merging) and splitting actions;
The correspondence between the original SBFF (D/Q) and MBFF (D*/Q*) pin mapping.

MBFF Naming

Based on the above MBFF implementation methods and processes, the generation of MBFF is usually divided into four types:

DC in-compile encapsulated MBFF
DC in-place encapsulated MBFF
ICC in-place encapsulated MBFF
Invs in-place encapsulated MBFF

The examples provided in the manual are as follows:

However, tests have shown that the encapsulation methods are similar to the following:This naming method may pose certain challenges for formal mapping, so caution is advised.

The second and third methods are both in-place methods and use tool-exported commands for MBFF encapsulation. If the naming is not very user-friendly, users can adjust scripts to maintain naming, which is more user-friendly for subsequent work.

The default mode simply connects the FF names with “_”.

The fourth type is that invs performs encapsulation in the in-place step, and users cannot intervene in naming.

Invs’s method is relatively user-friendly; it uses CDN_MBIT as the indication for MBFF, and each SBFF is indicated with MB. This naming rule is easier to understand, and formal differentiation is also easier. As the saying goes, simplicity is straightforward; it seems that invs is confident in its handling by not allowing users to intervene in naming.

Process Overview and Recommendations

Based on the above statements, there is a comprehensive understanding of the optimization methods for MBFF. Here are some specific data for reference:

DCT adopts the in-place MBFF encapsulation process:

invs based on netlist, performs the MBFF encapsulation process

invs based on DCT in-place netlist, performs the MBFF encapsulation process

Combining the above results and the characteristics of each process, here are some suggestions and recommendations:

MBFF can be encapsulated and implemented in three steps: RTL, SYN, APR
The synthesis stage usually only performs encapsulation, not splitting.
The APR stage needs to encapsulate and split based on timing, relying on timing-driven.
MBFF encapsulation has a serious dependence on SBFF layout: this aligns with the purpose of timing-driven.

Based on this, here are two recommended flows for everyone to choose from:

SYN-APR MBFF flow

SYN opens the MBFF optimization process.
APR needs to load the initial placement DEF or ddc outputted by SYN.
APR uses the place_opt command with skip_initial_placement to complete the MBFF APR implementation.

APR MBFF flow

Based on SBFF synthesis data, implement MBFF during the APR place_opt stage.
In timing-driven mode, the tool can automatically implement subsequent MBFF encapsulation and splitting operations.

【Key Points】

The MBFF process runs through the entire design implementation, and the ultimate service object is still APR and timing analysis. By understanding its process, suitable solutions can be made for one’s own design, effectively utilizing its advantages, and allowing MBFF to assist in design implementation.

References

Synopsys Design Compiler® User Guide Synopsys Multibit Register Synthesis and Physical Implementation Application Note Ai Si Kao Backend Implementation Exploration of Multi-Bit FF in Chip Design Ai Si Kao Backend Implementation Implementation Methods and Applications of Multi-bit (Part 1)

If you like the article, please like and follow!

Welcome to join the knowledge community of the author, recent hot topics:

CTS
PAD ring planning
eBook share: tech_file and design rule
PT tips
LVS naming conversion and physical cell handling
Calibre GDS operation
……