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

Two years ago, a previous article briefly introduced some basic knowledge of Multi-bit. For more details, please refer to: Exploring Multi-Bit FF in Chip Design. Based on this old article, there are still many technical details regarding MBFF (Multi-bit FF) that are worth learning and understanding again. Therefore, I will clarify the technical and process details related to MBFF more clearly here. Without further ado, ICer GO!

MBFF is a commonly used method in back-end design implementation. Here, we will discuss the advantages and usage strategies of MBFF in conjunction with the back-end process.

Advantages and Disadvantages of MBFF

MBFF packages several single bit FFs (SBFF) into one MBFF, which has some impact on timing optimization, as detailed below:

Area Advantage: When constructing std-cells, logical sharing leads to a significant area improvement.
Power Advantage: Due to gate-level integration, there is a noticeable benefit in power consumption based on the area improvement.
Timing Disadvantage: The following diagram illustrates the physical layout transition from SBFF to MBFF.

After SBFF is packaged into MBFF, the endpoint of the data path may change, potentially becoming closer (as shown in FF2) or farther (as shown in FF1), resulting in changes to setup/hold times.
After SBFF is packaged into MBFF, the clock path endpoints are integrated, and unlike SBFF, the clock paths for each individual SBFF cannot be flexibly controlled using useful skew. Although PPA optimization shows that MBFF wins two-to-one, the actual situation indeed reflects that the timing-driven implementation strategy in back-end design over the decades is an important factor that cannot be ignored. Specific examples and conflicts will be discussed later in this article.

MBFF Packaging Methods

Based on the characteristics of MBFF, users can choose to perform MBFF packaging operations at three stages in the entire back-end design process:

RTL Stage
Synthesis Stage
APR Stage

MBFF Packaging at RTL Stage

In the back-end design process, the first entry point for MBFF is RTL. DC users can use Synopsys primitives to know how DC constructs MBFF for the corresponding RTL design. Note: It is not explicitly instantiated in RTL, as this would impose significant constraints on designers and hinder subsequent processes.

RTL Specified MB Packaging Primitive: synopsys infer_multibit REG_NAME

Under the default configuration of DC, when the elaborate command is executed, it will parse the above design and primitives, corresponding to the output of the following logs:

The above logs express two meanings:

Using the primitive q0: synopsys infer_multibit "q0" has been packaged into MBFF. (Of course, it needs to meet the MBFF logic design requirements mentioned earlier.)
The unused primitive q1 has not been packaged into MBFF. (Even if it meets the MBFF logic design requirements mentioned earlier.)

Here, Synopsys also thoughtfully provides a configuration for mid-end engineers to choose. Users can control the corresponding operations of DC elaborate through the variable hdlin_infer_multibit.

This variable has three options:

default_none: DC only recognizes MBFF based on the primitive infer_multibit in RTL. If it does not encounter it, MBFF will not be converted. Note: This is the default setting of DC. The premise is that RTL designers need to use primitives to specify MBFF; otherwise, the In-compile MBFF flow cannot achieve MBFF packaging. Specific details will be described later.
default_all: DC actively recognizes MBFF based on the logical connection relationships in RTL code, regardless of whether the primitive infer_multibit is used. DC will try to package MBFF unless it encounters a primitive that prohibits MBFF packaging (details will be provided later).
never: The DC tool ignores the infer_multibit primitive and does not actively package MBFF, so no MBFF packaging actions will occur under the elaborate command.

The following diagram captures the logs of the elaborate command under three different configurations, showing different results in the MB column.

To facilitate the flexible use of the above variable, when hdlin_infer_multibit is configured to default_all, the primitive dont_infer_multibit can be used for exclusion processing: all registers defined with this primitive will not be packaged into MBFF during elaboration, even if the user has used the configuration hdlin_infer_multibit=default_all. The following diagram shows an example of q1, where even though the user has already used default_all, no MB packaging occurred during elaboration.

MBFF Packaging at Synthesis Stage

MBFF at RTL is specified through simple primitives (infer_multibit) or exclusion specifications (dont_infer_multibit). In addition to the elaborate stage performing unmapped-level MBFF packaging, the synthesis process mainly implements MBFF mapping through commands like compile. Regardless of whether RTL uses primitives to specify MBFF or uses hdlin_infer_multibit=default_all for MBFF recognition, any FF in the elaborate stage can only be packaged into MBFF through the compile command if it exists in the condition of MB==Y. For example, the q0_reg in the following diagram can only be potentially mapped to MBFF during the compile command execution.

In the compile step, there are usually two ways to implement MBFF mapping (mapped):

In-compile MBFF implementation: Based on the database form, use the compile command to directly implement MBFF mapping.
In-place MBFF implementation: Based on the physical layout data of DCT, package nearby FFs into MBFF (banking).

Both methods have their advantages and disadvantages. Let’s take a look at them together.

In-compile MBFF Implementation

The compile command configures MBFF implementation through the following command set_multibit_options to complete the transition from unmapped MBFF to real MBFF. Note: As the name suggests, this step also requires the target process library to support MBFF, as during elaboration, it is only a logic-based MBFF assessment; the final implementation still relies on the operations of the compile process library.

default: Restores all MBFF optimization configurations to default.
exclude_registers_with_timing_exceptions: When set to true, skips MBFF mapping for all registers with timing exceptions.
mode: MBFF mode selection, with the following four modes available:

none: Skips MBFF packaging in the compile command.
non_timing_driven: Regardless of timing, the tool attempts to perform MBFF as much as possible, resulting in the highest MBFF implementation rate.
timing_driven: Implements MBFF mapping in a timing-driven manner, ensuring that timing is guaranteed while optimizing area.
timing_only: Implements MBFF mapping solely in a timing-driven manner, optimizing timing but potentially not optimizing area.

ignore_timing_exception: When exclude_registers_with_timing_exceptions== true, this option allows MBFF mapping for specified types of timing exceptions, effectively refining the exclude_registers_with_timing_exceptions option. Currently, it supports five types: GROUP_PATH, FALSE_PATH, MULTI_CYCLE_PATH, MIN_DELAY, MAX_DELAY, etc. For example:

set_multibit_options 
	exclude_registers_with_timing_exceptions true 
	ignore_timing_exception FALSE_PATH

This skips MBFF mapping for all SBFFs with timing exceptions except for those with FALSE_PATH. In other words, SBFFs with FALSE_PATH will be packaged into MBFF.

critical_range: When the timing-driven mode is enabled, the timing range defined here is considered, similar to critical_range in group_path.
path_group: When the timing-driven mode is enabled, only the specified path_group is considered. If this option is not defined, all path_group will be considered. Therefore, a compile command implementing MBFF may look like the following:

dc_shell> set_multibit_options -mode timing_driven
dc_shell> compile_ultra -gate_clock -scan

After the compile ends, the command report_multibit_banking can be used to view the statistics of MBFF replacement results.

For MBFF replacement calculations, the following is set:

MBFF_cnt(n): The number of instances of MBFF with n-bit width.
SBFF_cnt: The number of instances of single-bit SBFF.
Total_bit_cnt: The total number of bits corresponding to all SBFFs and MBFFs calculated as SBFF. This is the total number of FFs when the database does not use the MBFF flow.
MBFF_ratio: The ratio of the number of all MBFFs to SBFFs. The higher this value, the more FFs are packaged into MBFF, resulting in greater area/power benefits.

Note: Due to the variety of MBFF types, including 2, 4, 8 bits, simply viewing the number of MBFF instances is not comprehensive.

To be continued…

Key Takeaways

MBFF contributes significantly to PPA and is now a standard delivery device for std-cells. Fully understanding the implementation methods and techniques of MBFF will provide great flexibility and controllability for the entire front-end and back-end design implementation, making it an essential skill for both designers and implementers in their work.

References

Synopsys Design Compiler® User Guide Synopsys Multibit Register Synthesis and Physical Implementation Application Note Aisikao Back-end Implementation Exploring Multi-Bit FF in Chip Design

If you like this article, please like and follow!

Welcome to join the author’s knowledge community, 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
……