Basic Questions

 Difference between report_timing and timeDesign commands ?

        There can be a difference in the report_timing and timeDesign reports if you have used setAnalysisMode -checkType hold before saving the design or before running the report_timing and timeDesign commands.

If setAnalysisMode -checkType is set to hold, the report_timing command applies this setting and generates the timing report in the hold mode. However, the timeDesign command does not use the setAnalysisMode -checkType hold setting and switches to the setup mode once the timeDesign command is called. The analysis mode will be switched back to the hold mode once timeDesign is done. However, you can use the -hold option with timeDesign to generate the hold report with the timeDesign command.

Difference between clock buffer and normal buffer ?

A buffer is an element which produces an output signal, which is of the same value as the input signal.

Clock buffers are designed specifically to have specific properties that are supposed for clock tree distribution. When compared to normal buffers, clock buffers have 

• equal rise and equal fall times

• less delays variations with PVT and OCV

Usually in soc’s clock routing is done in higher metal layers as compared to signal routing . So to provide easier access to clock pins from these layers, clock buffers may have pins in higher metal layers. For normal buffers the pins are expected to be in lower metal layers only.

Clock buffers are balanced in other words rise and fall times of clock buffers are nearly equal, the reason behind this is that if the clock buffers are not balanced there will be duty cycle distortion in the clock tree, which can lead to pulse width violations. Compare to normal buffers, clock buffers have high drive strength, due to this it can drive long nets and can have higher fanouts. This help clock buffers and hence to have overall delays.

What is difference between set_disable_timing and set_false_path ?

Set_disable_timing is generally useful to disable a particular arcs within the cell. Set_disable_timing and set_false_path both restrict the timing analysis of a particular path but the difference is that with set_false_path still the path delay will be calculated but will not be reported where as set_disable_timing will remove the timing path from analysis.

How timing of other groups will be affected when input/output delay is changed ?

If set_input_delay and set_output_delay is reduced it will improve in2reg and reg2out timing. It will not have any impact on reg2reg timing. Output delay is subtracted from the clock period and you have to meet reg2out path in remaining time. If output delay is less, you get more time to meet reg2out path. Similar thing is applicable for input delay.

If a timing path is not reported in a prime time what could be the cause or how you will debug that path?

If a intended timing path is not shown in prime time, this could be due to constraint problem. Either the path is unconstrained (which anyways will be shown in timing shell) or due to some applied exception which is blocking the path from being reported. In such scenario analyze_path command can be used which identifies timing exception and constraints on a particular timing path (cause of blockage).

How would you check for your constraints coverage for a big design?

Many designs have numerous and vast set of constraints. In a multi-mode multi-corner design it is very hard to find the constraint coverage, it means whether you have covered your design with full set of constraints or not. report_analysis_coverage command is used to check the coverage of constraints. This command basically check whether your end point (or timing arc) is tested or not. The end point is tested for the following checks setup and hold, min_pulse_width, min_period, clock_gating_check etc. PT generates a detailed report giving the list of tested and untested checks. with this report one can easily debug on the constraint part.

How max_transition violations are fixed?

max_tran is a highest priority drc check. If the trans is bad (or more) then it will lead to large delays and also will impact the dynamic (switching) power. Usually clock nets should have minimum transition values. Trans violation can be fixed by buffering the net, Up-sizing the driver cell, decreasing the spacing between cells or decreasing the wire length.

How you will find the virtual clock period corresponding to the input/output ports (which need to be constrained) when external design parameters (connected block info) are not known?

When external I/O info is not available specially for the clock, then in this case the fanout of input port can be traced (upto level 1 flop) for endpoint. After getting the info of connected flop to the port, the clock information of flop can be easily obtained and the same clock period can be used as period of virtual clock to constraint the input port.

How Synthesis results will change when max_transition value is changed. (as compared to the original runs)

When max_trans value is changed with respect to the original value, this will impact the synthesis results like switching power, delay. max_transition time signifies the time which a signal takes to change its state. A slow input transition time (more time) will slow the rate at which the cell’s transistors can change state logic 1 to logic 0 (or logic 0 to logic 1), thereby increasing the delay of the logic gate. Also if the transition time is more then it means the time for which both the transistors turn-on is also more which leads to more switching power. so synthesis results mainly delay and power will change accordingly.

What should be done if you are seeing big violations in timing reports after synthesis. or in other words how to fix timing violations after synthesis.

Generally after synthesis one should check the timing reports (pre-sta reports). If you are seeing a big setup violations then,

• One should look for the missing constraints (if-any) like multi-cycle path, false path etc.
• Its always recommended to start the synthesis with high-Vt (HVT) cells so as to reduce the leakage power. If you are able to close the timing with the HVT cells then its ok otherwise open LVT cells during synthesis, this will help in reducing the timing violation.
• Another method is creating path groups. We can create path groups and assign weightage to those path so that tool will try to fix them separately.
• Specify critical range: If we don't specify critical range, it works only on WNS but if critical range is specified then it works on all path which are below the specified range and it reduces TNS also.
• Enable boundary optimization, but it optimize area also.
• Try incremental compile (with high effort).
• Enable register retiming: Register retiming is the process by which the tool moves registers through combinational gates to improve timing.
• Pipeling.
• Remove area constraints (if any).

How Wire-load delay model (WLM) works.

A wire-load model is what the synthesis tool uses to estimate wire characteristics (e.g. interconnect delay) in the absence of physical layout data. For a wire with a given fanout, the wire-load model specifies the capacitance, resistance, and area of the wire.

What you generally check when synthesis is over.

When synthesis is over one should check for the QoR report, which will give a snapshot of various timing details, area info, power info etc. Ideally there will be different detailed reports generated for area (sequential/combinational count), timing (clock group wise TNS, WNS) and power. There are some sanity checks also which should be performed in the generated netlist like modal coverage, no-clock/multi-clock report etc to check the correctness of netlist.

What are timing loops?

When you have the timing path from output to input again through some combinational cells, then it creates a timing loop.

How to break a timing loop?

Using set_disable_timing, or manually doing disconnect and connect.

What are different timing arcs in a Flop ?

D--> CLK and CLK --> Q

What happens to a flop when you have the D --> Q defined as timing arc?

The flop will work as a computational cell, Probably as a buffer.

What is ground bounce effect ?

The noise produced by simultaneously switching output buffers. Then due to this it cant properly discharge through vss. It will change the voltage levels of power/ground nodes and is so-called “Ground Bounce Effect”.

IO port delays

How to include propagated clock latency in the IO port delays through set_input_delay or set_output_delay? 

Problem : 

I have IO ports constrained using real clocks that clock both IOs and the core. I want clock tree synthesis (CTS) propagated clock latency to be included in the IO port delays asserted through set_input_delay or set_output_delay. I am using "set_global timing_io_use_clock_network_latency always", but still, the propagated core clock latency is not added to the IO delays.

Why is this happening and how can I correct this?

Solution :

• Normally, when a clock is propagated, any asserted network latency associated with it through the set_clock_latency, SDC constraint is ignored. 
• If you constrain the IOs with a core clock that is propagated, you should first use "set_global timing_io_use_clock_network_latency always", which will cause the asserted clock network latency set through set_clock_latency for the IOs to be used even after CTS.
• To include the propagated clock latency (due to CTS) in the IO port delays, you should also use the -reference_pin option with the set_input_delay and set_output_delay commands. This ties the network latency used for the IO to the propagated latency of some flop's clock pin in the core.

                set_input_delay -reference_pin <ff_clock_pin_name> value pin

Example:

In the following timing report, the clock propagation time at clock pin BLK/BR2/CK is 0.345.

+-----------------------------------------------------------------------------------------------------------+

|    Instance    |   Arc             |       Cell        |    Delay      |      Arrival time   |    Required time  |

|-----------------+--------------+---------------+--------------+-------------------+----------------------|

|                      | tclk ^            |                     |                     |                  0.000 |                 -9.448 |

| CG/BC1       | A ^ -> Y ^    |     BUFX2   |          0.093  |                  0.093 |                 -9.355 |

| TC1              | A ^ -> Y ^    |     BUFX2   |           0.100 |                  0.193 |                 -9.255 |

| CG1              | B ^ -> Y ^    |  AND2X4   |           0.075 |                  0.268 |                 -9.180 |

| BLK/blkint   | A ^ -> Y ^    |     BUFX2   |          0.077 |                   0.345 |                 -9.103 |

| BLK/BR2     | CK ^             | DFFHQX1 |          0.000 |                   0.345 |                 -9.103 |

+-----------------------------------------------------------------------------------------------------------+

• Here, you have created a clock named WAVE on the tclk port. Because the CK pin of BLK/BR2 is the leaf pin in the fanout cone of the clock source WAVE, this can be used as a reference pin to set the input delay of '0' on the ports tin and tin2 using the following command:

                set_input_delay 0 -reference_pin BLK/BR2/CK -clock WAVE {tin tin2}

• Now, when you do report_timing on the port tin, you should be able to see the propagated clock latency of the BLK/BR2/CK pin getting accounted as the "Network Insertion Delay" component of "Beginpoint Arrival Time" at tin port.

                report_timing -from tin

Path 1: MET Setup Check with Pin TR1/BR1/CK

Endpoint: TR1/BR1/D (v) checked with leading edge of 'WAVE'

Beginpoint: tin (v) triggered by leading edge of 'WAVE'

Other End Arrival Time          0.194

- Setup                                     0.190

+ Phase Shift                          10.000

- Uncertainty                            0.123

= Required Time                      9.880

- Arrival Time                          0.544

= Slack Time                            9.336

       Clock Rise Edge                  0.000

       + Input Delay                       0.000

       + Network Insertion Delay   0.345    # The arrival time at BLK/BR2/CK pin gets accounted here

        = Beginpoint Arrival Time   0.345

+-------------------------------------------------------------------------------------------------------------+

|      Instance       |       Arc       |      Cell      |    Delay    |    Arrival time   |  Required time |

|-------------------+--------------+-------------+------------+-------------------+-------------------|

|                          | tin v            |                   |                 |                 0.345 |                9.682 |

| TU1                 | A v -> Y v   |   BUFX2   |       0.105 |                 0.451 |                9.787 |

Note: This global is "not" for virtual clocks.

Asserted network latency = latency specified using the set_clock_latency SDC constraint

Propagated clock latency = latency due to actual CTS insertion delays

What is a virtual clock ?

•  What is a virtual clock and why are virtual clocks used in the SDC file?

A virtual clock is a clock that exists but is not associated with any pin or port of the design. It is used as a reference in timing analysis to specify the input and output delays relative to a clock.

The following is an example where virtual clock is applicable:

• The design under analysis gets its clock from CK_DRIVER1, but the clock driving the input port OBJ_IN is CLK_IN.
• How can I specify the IO constraint on the input port OBJ_IN in such cases? The same issue occurs on the output port OBJ_OUT.
• To handle such cases, a virtual clock can be defined with no specification of the source port or pin. In the example (diagram), the virtual clock is defined for CK_DRIVER1 and  CK_DRIVER2.
• A TCLCMD-1142 warning message will also be issued when a virtual clock is created. If the intent is to create a virtual clock, this warning can be ignored. However, if a virtual clock was not expected, edit the create_clock constraint in the SDC file to include the clock source information to avoid this warning message.

•  create_clock -name VIRTUAL_ CK_DRIVER1 -period 10 -waveform {2 8}

**WARN: (TCLCMD-1142): Virtual clock 'VIRTUAL_ CK_DRIVER1 ' is being created with no source objects.

• create_clock -name VIRTUAL_ CK_DRIVER2 -period 8 -waveform {0 4}

**WARN: (TCLCMD-1142): Virtual clock 'VIRTUAL_ CK_DRIVER2  is being created with no source objects.

•  create_clock -name CLK_IN -period 10 [get_ports CLK_IN]

Having defined these virtual clocks, the IO constraints can be specified relative to this virtual clock.

•  set_input_delay -clock VIRTUAL_ CK_DRIVER1 -max 2.7 [get_ports OBJ_IN]
•  set_output_delay -clock VIRTUAL_ CK_DRIVER2 -max 4.5 [get_ports OBJ_OUT]
• The use of virtual clocks is just one approach to constrain the inputs and outputs. You may choose other methods to constrain the IOs as well.
• The virtual clocks are always considered ideal. Therefore, when clocks are put into propagated mode to calculate the actual delays through the clock network, these virtual clocks cannot be propagated and will issue the following warning message:

•  set_propagated_clock [all_clocks]

**WARN: (TCLCMD-986): Clock waveform 'VIRTUAL_ CK_DRIVER1' cannot be propagated as this is a virtual clock.

Logic Synthesis

            Synthesis:

                 It is a process of converting RTL (synthesizable verilog code) to specific gate level netlist                  (includes nets.cells & their connectivity) 

Goals of synthesis:

• To get gate level netlist
• Inserting clock gates
• Logic optimization
• Inserting DFT logic
• Logic equivalence between RTL and netlist should be maintained

           Inputs required:

• Tech related :
• .tf file (physical aware synthesis)
• Floorplan def (physical aware synthesis)
• .lib file
• Design related
• .v file
• .SDC file

Synthesis flow

• Reading the design,
• Setting constraints,
• Optimizing the design
• Analyzing the results &
• Saving the design database.

Synthesis Overview (script.tcl)

Synthesis include the following main tasks: reading in the design, setting constraints, optimizing the design, analyzing the results and saving the design database. These tasks are described below.

*******Reading in the design:analysing and elaborating**********

*Analyse command performs the following tasks:

1.Read the HDL source and checks it for syntactical errors

2.Creates HDL library objects in an HDL independent intermediate format and saves the intermediate files in a specified location. If the analyse reports errors, they must be fixed and the design reanalysed before continuing

*Elaboration command (elaborate) does 

Translation: RTL code is translated to technology independent representation(GTECH). The converted logic is available in boolean equation form.

Check the elaboration reports carefully to see the number, the type of memory elements, unresolved references exist in our design.

At this point, if the elaboration completed successfully, the design is represented in GTECH format, which is an internal, equation-based, technology-independent design format.

********Constraining the design**************************

The next task is to set the design constraints.Constraints are the instructions that the designer gives to tool. They define what the synthesis tool can or cannot do with the design or how the tool behaves.

2 types of design constraints:

###Design Rule Constraints#######

Design rules constraints are implicit constraints which means that they are defined by the ASIC vendor in the technology library. By specifying the technology library that synthesize tool should use.

*Maximum transition time: Longest time allowed for a driving pin of a net to change its logic value

*Maximum fanout: Maximum fanout for a driving pin

*Maximum (and minimum) capacitance: The maximum (and minimum) total capacitive load that an output pin can drive. The total capacitance comprises of load pin capacitance and interconnect capacitances.

*Cell degradation: Some technology libraries contain cell degradation tables. The cell  degradation tables list the maximum capacitance that can be driven by a cell as a function of the transition times at the inputs of the cell.

###Optimization Constraints####

Optimization constraints are explicit constraints set by the designer. They describe the design goals (area and timing). As per that constraints tool need to perform synthesis.

*System clock definition & clock delays: Clock constraints are the most important constraints in your ASIC design. The clock signal is the synchronization signal that controls the operation of the system. The clock signal also defines the timing requirements for all paths in the design. Most of the other timing constraints are related to the clock signal.

*Multicycle paths: A multicycle path is an exception to the default single cycle timing requirement of paths. That is, on a multicycle path the signal requires more than a single clock cycle to propagate from the path startpoint to the path endpoint.

*Input and output delays: Input and output delays constrain external path delays at the boundaries of a design. Input delay is used to model the path delay from external inputs to the first registers in the design. Output delay constraint the path from the last register to the outputs of the design.

*Minimum and maximum path delays: Minimum and maximum path delays allow constraining paths individually and setting specific timing constraints on those paths.

*Input transition and output load capacitance: These constraints can be used to constrain the input slew rate and output capacitance on input and output pins.

*False paths: A false path is a path that cannot propagate a signal. For example, a path that is not activated by any combination of inputs is a false path.

Note that synthesis tool tries to meet both design rule and optimization constraints but design rule constraints always have precedence over the optimization constraints. This means that tool can violate optimization constraints if necessary to avoid violating design rule constraints.

**********Optimizing the Design**********

The optimization step finally translates the HDL description into gate-level netlist using the cells available in the technology library. The optimization is done in several phases. In each optimization phase different optimization techniques are applied according to the design constraints. 

Synthesize tool performs optimizations on three levels: architectural, logic-level, and gate-level.

######Architectural Optimizations#########

Architectural optimizations are high-level optimizations which are performed on the HDL description level. These optimizations include tasks such as:

#Arithmetic Optimizations: Arithmetic optimization uses the rules of algebra to improve the implementation of the design. That is, synthesis tool may rearrange the operations in arithmetic expressions according to the constraints to minimize the area or timing.

#Resource Sharing: Resource sharing tries to reduce the amount of hardware by sharing hardware resources with multiple operators in your HDL description. For example, single adder component may be shared with multiple addition operators in the HDL code. Without resource sharing each operator in your code will result as a separate HW component in the final circuitry.

#Selecting DesignWare Implementations: Selecting a DesignWare implementation means that the implementation selection of a particular resource is left to the synthesis tool. For example, the Basic IP Library contains two implementations (ripple and carry-lookahead) for the +-operator (the DesignWare Foundation Library provides more implementations for the '+' and other operators). When selecting DesignWare implementation, Tool considers all available implementations and makes it selection according to your constraints.

At this point, the design is represented by GTECH library parts (i.e. generic, technology-independent netlist).

########Logic-level Optimizations########

Logic-level optimizations are performed on GTECH netlist and consists of two processes: structuring and flattening.

#Structuring: Structuring evaluates the design equations represented by the GTECH netlist and tries by using Boolean algebra to factor out common subexpressions in these equations. The subexpressions that have been identified and factored out can then be shared between the equations. For example, Before Structuring After Structuring

P = ax + ay + c 

P = aI + c

Q = x + y + z 

Q = I + z

I = x + y

Structuring is usually recommended for designs with regular structured logic.

#Flattening: Flattening tries to convert logic into two-level, Sum-of-Products representation. Flattening produces fast logic (by minimizing the levels of logic between the inputs and outputs) at the expense of the area increase. Flattening is recommended for designs containing unstructured or random logic.

########Gate-level Optimizations########

Gate-level optimizations work on the technology-independent netlist and maps it to the library cells to produce a technology-specific gate-level netlist. Gate-level optimizations include the following processes:

1.Mapping: Mapping to the technology library and performing incremental optimization

syn_map command maps the specified design to the cells described in the supplied technology library and performs logic optimization

The 3 main steps performed in syn_map command are:

a.Technology independent Boolean optimization (Optimization): Boolean equation is optimized using SoP or PoS optimization methods.

b.Technology mapping: Technology independent boolean logic equations are mapped to technology dependent library logic gates based on design constraints, library of available technology gates.  This produces optimized gate level representation which is generally represented in verilog.

c.Technology-dependent gate optimization (IOPT ): The final optimization Genus performs is incremental optimization. Optimizations performed during IOPT improve timing and area and fix DRC violations.

Optimizations performed during this phase include multibit cell mapping, incremental clock gating, incremental retiming, tie cell insertion, and assign removal.

syn_opt command is used for optimization.

2.Delay Optimization: Delay optimization fixes the timing violations introduced by mapping phase.

3.Design Rule Fixing: Design rule fixing fixes the design rule violations in the design. Basically this means that the tool inserts buffers or resizes existing cells. Note that design rule fixing phase is allowed to break timing constraints.

4.Area Optimization: Area optimization is the last step that Design Compiler performs on the design. During this phase, only those optimizations that don't break design rules or timing constraints are allowed.

Congestion Analysis

 

Congestion Analysis

• As the Technology advances, millions of transistors can be packed onto the surface of a chip
• Thus the increased circuit density introduces additional Congestion
• Intuitively speaking, Congestion in a layout means too many nets are routed in local regions
• This causes detoured nets and un-routable nets in Detailed Routing
  
  
• Congestion Analysis
  • Routing Congestion Analysis
    
    • Congestion in general referred to Routing Congestion
    • Routing congestion is the difference between supplied and available tracks
    • A track is nothing but a routing resource which fills the entire Core
    
    
  • Placement Congestion Analysis
    • Placement Congestion is due to overlap of Standard Cells, it is called Over lapping rather than called as Congestion
    • Overlapping issue can be fixed by aligning cells to the Placement Grid by legalization

• In recent years, several congestion estimation and removal methods have been proposed
• They fall into two categories: Congestion estimation and removal during global routing stage, and Congestion estimation and removal during Placement stage
• To estimate Congestion, tool does Initial/ Global Routing
• Congestion reports are generated after each Routing stages which shows the difference between supplied and demanded Tracks or G-cells
• Overflow = Routing Demand - Routing Supply (0% otherwise)
• Usually starts the initial Target Utilization with 65% to 70%
• 7/3 in a 2D congestion map : There are 7 routes that are passing through a particular edge of a Global Route Cell (GRC), but there are only 3 routing tracks available. There is an overflow of 4.

Causes for Routing Congestion Missing Placement Blockages Inefficient floorplan Improper macro placement and macro channels (Placing macros in the middle of floorplan etc.) Floorplan the macros without giving routing space for interconnection between macros High Cell Density (High local utilization) If your design had more number of AOI/OAI cells you will see this congestion issue Placement of standard cells near macros High pin density on one edge of block Too many buffers added for optimization No proper logic optimization Very Robust Power network High via density due to dense power mesh Crisscross IO pin alignment is also a problem Module splitting

---

Congestion Fixes

Add placement blockages in channels and around macro corners Review the macro placement Reduce local cell density using density screens Reordering scan chain to reduce congestion Congestion driven placement with high effort Continue the iterations until good congestion results Density screen is applied to limit the density of standard cells in an area to reduce congestion due high pin density

---

• Routing congestion, results when too many routes need to go through an area with insufficient “routing tracks” to accommodate them 
  
• Two major categories: Global Congestion and Local Congestion
• Global Congestion: This occurs when there are a lot of chip-level or inter block wires that need to cross an area
• Local Congestion: This occurs when the floor plan has macros and other routing blockages that are too close together to get enough routes through to connect to the macros.

---

Congestion Profiles

Sanity Checks

 Sanity Checks :

To ensure that the input received from the library team and synthesis team is correct or not. If we are not doing these checks then it creates problems in later stages of design.

Basically, we are checking following input files: and make sure that these files are complete and not erroneous.

•         Design/netlist checks
•          SDC checks
•          Library checks

Design checks: Check if current design is consistent or not. It checks the quality of netlist and identifies:

•        Floating pins : unconnected pins
•        Multidriven nets :

o   Multi-driven nets can be created in the RTL by introducing drivers of same or different signal strengths. However, driving a net with multiple signals are not considered as good design practice. This could lead to a failure in post silicon verification as the driver strengths can potentially get heavily altered due to manufacturing defects.

o   Many EDA tools do not allow multi-driven nets in the design, and the designers are expected to remove all multi-driven nets from the design.

•          Undriven input ports
•          Unloaded outputs
•          Unconstrained pins
•          Pin mismatch counts between an instance and its reference
•          Tristate buses with non-tristate drivers
•          Wire loops across hierarchies
•         Constant hierarchical pins :

o   Constant hierarchical pins are generally not a problem, but they are still worth investigating.

o   When RC propagates constants across hierarchical boundaries, it will tie the pin to 1'b0.  The other side of that hierarchical pin will have nothing attached to it.  It effectively becomes an unused hierarchical pin, but RC, by default, will tie it off so it is not undriven.

o   What we need to do, is to run "check_design -constant" and look at any constant hierarchical pins have a fanout greater than 0.  A fanout of 0 means that it is an unused hier pin, which is not an issue.

o   In this case, some of the JTAG_MODULE pins are tied off, which I expect, and all the rest of a fanout of 0 are not a problem here.

ICC command: check_design

SDC Checks : If any unconstrained paths exist in the design then PNR tool will not optimize that path, so these checks are used to report unconstrained paths

•        Checks whether the clock is reaching to all the clock pin of the flip-flop.
•         Check if multiple clock are driving same registers
•         Check unconstrained endpoints
•         Port missing input/output delay.
•         Port missing slew/load constraints.

ICC command: check_timing

Library checks: It validate the library i.e. it checks the consistency between logical and physical libraries. It checks the qualities of both libraries. This library checks shows

•         Name of the library
•         Library type & its version
•         Units of time
•         Capacitance
•         Leakage power
•         Current
•         Number of cells missing
•         Number of metal or pins missing in the physical and logical library.

ICC command : check_library