Multi Mode Multi Corner File
MMMC Configuration & Multi Mode Multi Corner File
What is MMMC ?
MMMC means Multi Mode Multi Corner. This file is used to analyze the design in different Modes and Corners. Because the chip after manufacture have to work properly for different temperatures, voltage, and while manufacturing there might be some process variations or in general it is called PVT (Process, Voltage and Temperature) . which leads to variation in delays (expected delays will not come). This MMMC file usually develop using TCL script to execute all the commands into the tool.
Let’s take a real time example: A chip is manufactured and implanted in a mobile. You must be using that mobile in you home. The room temperature of your home will be like 27 Deg C and mobile is working properly. But you planned a tour to Arizona deserts whether temperature is at 40 Deg C or to Alaska whether temperature is at sub zero or negative in winter and Desert will have 50 degrees temperature in summer. Your mobile should work for both of these temperature extremes right ?. Now a days, we are experiencing extreme temperatures all over the world depending on the seasons and due to global warming. So, make the mobile chips or any IC chips to work properly for all kind of temperatures extremes, we have to analyze the chip in different temperatures and and also with different voltages , process (manufacturing) variations. These variations are called PVT (Process, Voltage and Temperature). These PVT variations impact the delay in the designed chips, which leads to not to meet the timing constraints or the functional specifications of the chips and the chip will fail to function.
For MMMC flow to be verified or to run the simulation at various PVT corners and to analyze we need the PVT files and they are listed below:
- Timing Libraries (.libs)
- Timing constraints (.sdc)
- Cap tables or RC co-efficient files (Represents capacitance and resistances of nets)
MMMC File Flow Diagram
Note: Here, worst analysis view for setup and best analysis view for hold.
What is Corner?
Corners are a set of libraries characterized by process, voltage, and variation. Corers are not dependent on functional settings. They are meant to capture the manufacturing process, along with expected variations in voltage and temperature. Environment in which the chip will operate. This information can be carried by the timing libraries.
What is Mode?
A model is defined by clocks, supply voltages, timing constraints and libraries. It can also have annotation data, such as SDF or parasitic files. Many chips can have multiple modes such as functional modes, test mode, sleep mode. Each mode will have separate SDC files (Timing Constraints) such as functional mode, test mode, sleep mode
PVT Conditions (Corners)
Temperature: Best case, Worst case, Typical – 3 corners
Process for cells: Fast-Fast, Slow-Slow, Fast-Slow, Slow-Fast, Typical = 5 comers
Voltage: Best case, Worst case, Typical – 3 comers
Process for interconnect: Max G, Min C, Max RG, Min RC, Typical = 5 comers.
In MMMC flow, by using those files it is required to create multiple modes and corners to run the simulation and analyze. Different set of libraries are available for each technology nodes which are Typical, ss (Slow-Slow) and ff (Fast-Fast).
- Typical: will have moderate delays. Both PMOS and NMOS works normally.
- Slow-Slow :will have worst delays (Max delays). Both PMOS and NMOS works slow.
- Fast-Fast: will have best delays (Min delays). Both PMOS and NMOS works fast.
Likewise, for RC values also available, RC min, RC max, RC typical, C min, and C max.
Example: Consider a chip with four operating modes (Normal, Sleep, Scan Shift, Jtag). The chip is analyzed at three PVT corners (WC, BC, TYPICAL) and three parasitic interconnect corners (Typical, Min C, Min RC)
- Multi-Mode Multi-Corner file generates different analysis views based on different delay corners and constraints modes. Delay corners are defined in library sets and RC corners. There are various library set files based on voltage and temperature values (like SS,FF typical).
- The above set of files is needed to initiate all physical designs. Cadence and Synopsys tools have different file formats. There are some optional files that might be required especially for block-level PnR implementation.
- MMMC can optimize for all design metrics across all modes and corners concurrently. This is accomplished using a data structure called a virtual timing graph. To represent mode/corner scenarios, multiple virtual timing graphs are generated, and then stored as a single vector-based timing tree that simultaneously captures information for an unlimited number of mode/corner combinations.
- Tweaker-T1 holds a unique multi-mode, multi-corner (MMMC) data structure that helps you incorporate multiple timing scenarios simultaneously. The innovative MMMC data structure enables Tweaker-T1 to continuously make appropriate timing changes, based on each scenario, as soon as a cell is changed or moved. You can monitor the potential impacts of all scenarios, and decide what specific ECO action should be allowed. With assistance from the MMMC data structure, Tweaker-T1 is also capable of analyzing violation reports and focusing on bottlenecks spread throughout the design.
Commands For Multi Mode Multi Corner Structure ( Tweaker )
Match STA Environment:
Tweaker-T1’s capabilities are heavily linked with STA tools. Under this relationship, Tweaker’s database is designed to match STA environments; however, it covers all scenarios at the same time. To define each scenario, you start and end its corner definition with the begin_corner and end_corner commands, respectively. In between those two commands, you supply the corresponding library group, RC group, SDF group, Slack reports, and most importantly, the TWF files. By using each set of begin_corner and end_corner scenario definitions, Tweaker-T1 builds up the MMMC database that is essential to fix timing.
Aside from each of the mentioned files specified within each scenario, Tweaker-T1 also readily incorporates various timing analysis types into each scenario, such as single, bc_wc, and on_chip_variation. In the majority of cases, timing analyses reside in the on_chip_variation category, which can be further classified under Global OCV or Advanced OCV (AOCV).
The following subsections will focus on how to set up timing scenarios using Tweaker-T1 and correlate them to the STA environment.
Contents of a timing scenario:
In Example 1, notice that each scenario matches an STA environment in terms of specifying each corresponding library group name, RC group name, SDF group name, TWF file, and Slack reports. Using the -name option for the set_group command will prompt Tweaker-T1 to find all files previously defined with identical nametags. Therefore, the -name option allows you to group each set of related files when describing a timing scenario.
Example 1: A Basic Scenario # Beginning of a scenario begin_corner scenario_name set_group -lib -name library_group set_group -spef -name RC_group set_group -sdf -name SDF_group twfin -analysis_type on_chip_variation TWF_file slackin -mode func -analysis_type on_chip_variation report_file end_corner scenario_name # End of a scenario
Having listed the basic STA data correctly in each corner definition block, use the slackin and twfin commands to read both slack reports and TWF files. Addition usage details for these two commands will be available later in this chapter.
Example 2: Power ECO Scenario Definitions Only Require TWF Files (No Slack Report) # Beginning of a Power ECO scenario begin_corner scenario_name set_group -lib -name library_group set_group -spef -name RC_group set_group -sdf -name SDF_group twfin -analysis_type on_chip_variation TWF_file end_corner scenario_name # End of scenario for “Power ECO” Example 3: Contents of Each Scenario for “ECO Place” Operation # Beginning of a scenario for “ECO Place” begin_corner scenario_name set_group -lib -name library_group set_group -spef -name RC_group set_group -sdf -name SDF_group end_corner scenario_name # End of scenario for “ECO Place”
Additional Useful Commands for a Timing Scenario:
Besides the commands to specify basic STA data, there are a few commands and options that help construct detailed settings within a scenario. The first useful command, set_timing_derate, is used to determine the global OCV derate value. When implemented Tweaker-T1 simulates the STA environment based on this global derating factor. Additional command usage is listed in Table 1, and refer to Example 1 for a sample scenario with OCV derating. You must set derating values in advance – before the slack and twfin commands – and reset these values before the next scenario. Tweaker-T1 also supports LOCV/AOCV by reading through the “Derate” column of imported Slack reports that include the ECO path domain. The following is a list of ways to set timing derate values, arranged from highest to lowest priority.
1st Priority: Get derating values from the “Derate” column of STA Slack reports
2nd Priority: Get derating values from the header of each path in the STA Slack report
3rd Priority: Set derating values using the set_timing_derate command
The second useful command usage is enabling or disabling the -name or -inst options after set_group -lib (see Example 2 for application of this option). These options allow Tweaker to support Multi-VDD timing libraries for different modules within the same timing scenario (much like link_path_per_instance from PrimeTime). With the following command usage, you can easily construct and accurately match each scenario to the STA environment.
Table 1: The set_timing_derate Command Syntax Syntax set_timing_derate [-early | -late] [-clock | -data] [-cell_delay | -cell_check | -net_delay] value [get_lib_cells cell_pattern] Examples Pair 1: set_timing_derate -early 0.95 set_timing_derate -late 1.0 Pair 2: set_timing_derate -early 1.0 set_timing_derate -late 1.05 -data -cell_delay Pair 3: set_timing_derate -early 0.95 -clock set_timing_derate -late 1.05 -clock set_timing_derate -early 0.95 [ get_lib_cells PAD ]
Options -early | -late For launch path (launch clock path + launch data path) or capture path (capture clock path): -early: launch path -late: capture path For setup violations: -early: capture path -late: launch path -clock | -data Specifies which path segment to derate, since the launch path contains both clock and data paths. Otherwise, both segments are derated. -cell_delay | -cell_check | -net_delay Specifies cell delay, net delay, or cell timing check to derate a path’s segment. The segment will be derated based on all factors, unless otherwise specified. get_lib_cells cell_pattern Gets a collection of pattern matched cell names. If this command is used, the derate value is only applied to these cells. Each cell only has a single derate value within each timing scenario. Example 1: OCV Derating Scenario # Beginning of a scenario with OCV derating applied begin_corner scenario_name set_timing_derate -early 0.95 set_timing_derate -late 1.0 twfin -analysis_type on_chip_variation TWF_file slackin -mode func -analysis_type on_chip_variation report_file # reset back to default value set_timing_derate -early 1.0 set_timing_derate -late 1.0 end_corner scenario_name # End of a scenario with OCV derating applied Example 2: Applying Multi-VDD Timing Libraries for Different Modules in the Same Timing Scenario libin -timing_type best worst -name bc A_bc.lib libin -timing_type best worst -name bc_11v A_11vbc.lib … # Beginning of a scenario with MVDD assigned to module 11vModule begin_corner scenario_name set_group -lib -name bc set_group -lib -name bc_11v -inst 11vModule end_corner scenario_name # End of a scenario with MVDD assigned to module 11vModule
Default Scenario
If no scenario is established (that is, there is neither a beginning nor an end description within the TCL scripts), Tweaker creates a default scenario. In Tweaker’s default scenario, the initial group of timing libraries and RC files are used. Although Tweaker provides a default scenario, it is strongly recommended that you establish a scenario whenever possible.
Visit Silicon Synergy to know More
Explore our IC Design Courses in Analog IC Design, Digital Design & Verification
