Synthesis Methodology & Netlist Qualification

By Dhanyakumar Shah and Ashish Trapasiya (eInfochips)

Abstract

The main objective of this article is to explain synthesis flow and post-synthesis netlist quality checks. In ASIC flow, synthesis is the part of the front-end design, while the back-end design takes the synthesized netlist as an input. So, the synthesized netlist should meet all netlist quality checks to reduce multiple iterations, which reduces the turnaround time and efforts.

We will see the overview of various checks that are performed at the synthesis stage of the ASIC flow in this article. After reading this article, you will be able to answer the following questions: What is synthesis? Why do we need synthesis? What are the input and output of synthesis? What is synthesis flow? What are the checks performed to ensure the netlist quality?

Introduction

What is synthesis? Synthesis transforms the RTL code of design modules into a gate-level netlist. This stage performs logic, area, power optimization, and scan insertion. Various tools are available, which can be used to do synthesis such as Synopsys Design Compiler/Fusion Compiler and Cadence Genus.

Synthesis overview

Once the RTL of the design fulfills all criteria of RTL checks, then the next step is synthesis. Synthesis is the stage where the RTL code is converted into a gate-level netlist.

Synthesis is one of the important steps in chip designing flow as it allows us to visualize the design as it will appear after manufacturing. Here, designers review all reports and validate all required factors including timing, area, and power. Designers can make necessary changes (if required) before the creation process, which saves time, money, and effort.

The synthesis process can be divided into three stages:

1. Translation
2. Optimization
3. Mapping

^{Click to enlarge}

Figure.1 - Synthesis steps

Synthesis Inputs and Outputs

Input

1. Timing library (.lib or .db)
2. Physical Library (lef, Milkyway)
3. SDC
4. RTL
5. DEF (For Physical aware Synthesis)
6. TLU+(Synopsys), Qrc(cadence) file
7. UPF

Output

1. Netlist
2. UPF
3. SDC
4. DEF
5. Reports

Goal of Synthesis

1. Logic optimization with good QoR
2. Scan insertion (DFT)
3. Netlist generation
4. Logical equivalence check should be preserved between the RTL and netlist

Types of Synthesis

1. Logical Synthesis

Logical synthesis is a conventional synthesis, that processes the HDL (Verilog or VHDL) design and generates gate level netlist. During this process, the compiler optimizes the design based on predefined constraints.

2. Physical Aware Synthesis

Physical Aware synthesis requires additional floorplan DEF as an input. Floorplan DEF contains physical information like IO ports placements, macro placement information, blockages information and die area information. Additionally, we use RC co-efficient file as one of the inputs to compute a more accurate wire delay values compared to the WLM (Wire Load Model) method.

Advantages of Physical Aware synthesis:

1. Better PPA (Power, Performance, Area).
2. Better timing correlation with PNR.
3. Better turnaround time (reduces the number of iterations).

Synthesis Flow

Figure.2 - Synthesis flow

Synthesis input

1. LIB: The timing library (.lib) contains information related to the timing, power, and area of standard cells. It also contains different PVT characterizations of cells.
2. LEF: LEF represents the physical information of metal and via, standard cell, and macro.
3. RTL: It’s a descriptive code written in HDL format.
4. SDC: It represents the design constraint.
5. DEF: DEF file contains the placement information of macro, pre-placed cells, IO ports, block size, and blockages. Mainly used for the Physical Aware synthesis.
6. UPF: UPF file is required to describe the power intent of the design including the power domain, level shifter, isolation cell, and retention registers.

Elaboration

At this stage, it reads the RTL code, and this RTL code is converted into modules as per its logical hierarchy. Once it has all logical Boolean representation loaded, the tool maps logic with a technology-independent cell called the Gtech cell.

During elaboration, the tool checks whether the design is unique, if not, it stops the tool. Once the design becomes unique, the tool checks for unresolved references in the design. If it has linking issues, then an RTL correction is required, or you need to check if it is due to any missing libraries. After elaboration, it checks for timing loops in design. If you find any timing loop, you need to get RTL correction done by the designer.

Compile and optimization

After elaboration, in the compilation stage, the tool maps the Gtech cell with the actual cell (specific technology dependent) from the library. Actual cell mapping is dependent on the design constraints or user-specific constraints. Apart from this, the tool removes the registers with constant propagation/unloaded which are not required in the design. If these removed cells are required, then you need to provide feedback to the designer to get the correct RTL.

After elaboration and compilation, the tool performs optimizations based on user constraints to meet timing, area, and power requirements.

DFT

The Design for Testability (DFT) stage performs the scan insertion in the optimized design. After this stage, the design should fulfill the scan criteria and achieve the desired scan coverage.

Outputs

A qualified netlist with scan insertion and good QoR in terms of timing, power, and area. Other outputs are updated DEF, UPF, and SDC.

1. UPF: The output UPF is the updated version of the input UPF. At the synthesis stage, it performs logic optimization that introduces new power intents. So, we are generating UPF with this update after synthesis.
2. DEF: While performing Physical Aware synthesis, we also generate the DEF file, which contains macro and standard cell placement information. This DEF is directly used in physical implementation that, avoids placement of the cell from scratch, hence, we can save run time.
3. SDC: The output SDC is the updated version of the input SDC. At the synthesis stage, we use constraints provided by the designer. Additionally, we use certain local constraints to improve the overall QoR of design. Thus, the SDC with this update is generated after synthesis.

Netlist quality checks

Below are certain checks that, should be fulfilled post-synthesis to ensure netlist qualifications before it is delivered for physical implementation.

1. No Clocks:

In this check, we ensure that all the required clocks reach the sync points. Some major reasons for getting no clock violation in design are mentioned below:

• Clock definition missing: This is observed when clock creation is missing in the clock constraint file.
• RTL connectivity issue/Tie off: This type of no clock is observed when there is missing connectivity in between modules in the RTL or having direct tie-offs in the RTL.

Impact: Ideally, all the registers in the design should be clocked. If no clock issue is left in the design, then it will report unconstraint endpoints and can cause optimization issues on such paths.

Solution: To resolve the above-mentioned no clocks violation, we need to get the corrected RTL (from the designer) and clock constraints files with all the required clock definitions.

Command: check_timing -include {no_clock}

2. Unconstraint end-points:

This is due to the missing IO constraints, clock definitions, or due to some exceptions at the sequential cells or ports. Possible reasons are case constant, no arrival path, or false path.

Impact: If IO constraints are missing in the design, then the external launch time for the input path or the capture time for the output path will be missed. It can cause an incomplete timing check. If the path is expected to be false, it could lead to an incorrect timing check.

Solution: To resolve these problems, we need the correct constraint file (sdc), which defines all the required clocks used in the design, IO delays on all the required ports, verified false path, and case constants in design.

Command: check_timing -include {unconstrained_endpoints}

3. Timing:

In this check, the entire design is divided into timing paths. For each timing path, the delay is calculated and checks violation based on timing constraints (clock period, clock uncertainty, and setup time). The major reasons for having timing violations are- levels of logic, incorrect/missing constraints such as clock relations, clock exceptions, and incorrect uncertainty.

Impact: If a huge timing violation is reported at the synthesis, this violation will be difficult to fix at later stages (PNR/ECO), which also impacts the power and area.

Solution: The techniques used to resolve/reduce timing violations are user-defined path groups with appreciate weightage, by disabling selectively/entirely multibit banking in design, bound creation, using timing efforts high or incremental compilation. If we are performing Physical Aware synthesis, it is expected to have a good macro placement that improves timing violations.

Command: report_timing or report_qor

4. LEC:

This is one of the important checks that validate the correctness of the netlist concerning the RTL.

It is recommended to perform this check when there is an update in the RTL or netlist. Generally, in the synthesis LEC, a check is performed between the RTL vs synthesize netlist and synthesize netlist vs post scan netlist.

General issues due to which the LEC can fail are as follows:

• CSN Missing: The missing CSN (Connect Supply Net) can lead to LEC failure.
• Isolation cell mapping: When there is an issue with UPF constraint, then there could be a possibility of having different isolation cells, mapped in between the RTL and synthesize netlist, that may cause LEC failure.
• Undriven Nets: If we have undriven nets in the RTL, the synthesize tool will tie off these nets causing LEC failure. This can be resolved by getting the RTL fixed or if the undriven is expected, then you need to use undriven constraints to pass the LEC.

Constraint used (formality): set_constants <net_name> <0/1>

Impact: If the LEC is not clean then the equivalence is not maintained between the RTL and netlist which can lead to functionality failure.

EDA Tool: Formality from Synopsys, conformal from Cadence

5. Timing loop:

In the RTL, if in between combo logic, the output is again feed to the same input of combo logic that forms a logical loop, this loop is called the timing loop. We can get the timing loops due to RTL connectivity issues in design that, which can lead to meta-stable data, thus, we should avoid timing loops while netlist generation.

Impact: The path with timing loops will not have endpoints. If such loops are not broken then the path will not be correctly timed.

Solution: If we are getting timing loops that are expected to have then in such case, we need to use the constraint to break such timing loops. If such timing loops are not expected in design, then we need to get the updated RTL.

Command: check_timing -include {loops}

6. Empty module:

If the RTL module definitions don’t have any logical content such as wire, inputs, or outputs, then such modules are called empty modules. This check is performed before compilation.

By default, empty modules are removed during synthesis. If we want to preserve this empty module, we need to apply constraint (set_dont_touch) on that module before compilation.

Command: check_design

7. Removed Flop:

If the register is removed during compilation and optimization, then such flop is reported as removed flops. If the register is either unloaded or constant, then by default during compilation such flip flop is removed from the design.

If such flip flops are expected in design, then we need to use certain constraints to preserve this.

Command:

report_unloaded_registers

report_constant_registers

8. Floating pins and multidriven pins:

In the design there might be a possibility that a few of the pins are not connected to any element present in the design. Such pins are known as floating pins. While performing optimization, such floating pins cells might get optimized due to which there could be a breakdown in logic.

Multidriven nets are detected when there is more than one input connected to the same net from different modules. This is not accepted in design and you need to fix this issue. It requires RTL correction to resolve this issue.

9. Latches:

The latches are not expected in design and during compilation, the tool gives a warning if the design infers a latch. Below are a few reasons why a latch is not preferred in design:

1. As latches are level triggers and can change the output at an active level of the clock.
2. The latch output is stable only at an inactive level of the clock cycle, due to which the entire clock cycle is not utilized for timing check.

Note: Commands mentioned in this article are referred from Synopsys EDA tool (fusion compiler)

Conclusion

This article gives an introduction to the synthesis overview, synthesis flow, and the list of checks performed post-synthesis before it is delivered for physical implementation. It covers the in-depth explanation of each step performed during synthesis. This article also describes almost all the netlist quality checks in detail such as LEC (Logic Equivalence Checks), timing checks, and other QOR checks that qualify the netlist.

About the Authors

		Dhanyakumar Shah is a Senior Physical Design Engineer at eInfochips. He holds a Bachelor of Engineering degree in Electronics and Communication from A. D Patel institute of technology, Vallabh Vidyanagar, India. With over 5+ years of experience in lower technology nodes in ASIC design, he is an expert in synthesis, PnR, STA analysis, physical verification, and FEINT activities.
		Ashish Trapasiya is a senior physical design engineer. He holds a Bachelor of Engineering degree in electronics and communication from A. D. Patel institute of technology, Vallabh Vidyanagar, India. He has 5+ years of experience in ASIC design including Synthesis, place & route, static timing analysis, and physical verification on various technology nodes like 16nm, 7nm, and 5nm.

Reference

https://www.synopsys.com/glossary/what-is-physical-synthesis.html

https://fdocuments.in/document/advanced-asic-chip-synthesis-bhatnagar.html

If you wish to download a copy of this white paper, click here