QoR in Synthesis and Debugs
Post synthesis QoR contains the following highlighted points, which needs to be checked to ensure good quality netlist.
-
- Netlist quality checks
Below are certain checks that, should be fulfilled post-synthesis to ensure netlist qualifications before it is delivered for physical implementation.
- 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}
- 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}
- 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
- 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
- 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}
- 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
- 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
- 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.
- 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:
- As latches are level triggers and can change the output at an active level of the clock. 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.
