STA : Quality of constraints validation at Block and Fullchip level

 In the semiconductor industry, meeting stringent timing requirements is of paramount importance for successful design implementation. Static Timing Analysis (STA) is a vital technique used to verify and validate design constraints, ensuring proper functionality and optimal performance. Validating the quality of constraints is essential, as they decide design quality, performance, and faster time-to-market. With designs growing larger and intricate, extending parallel STA analysis is necessary at both the Block level as well FullChip level, accounting for inter-block interactions and global timing considerations. This article explores the challenges and best practices of validating constraints at both levels, highlighting common issues and proposing potential solutions. By addressing these aspects, the primary aim is to streamline the design process and create robust, high-performance digital designs.

Importance of Design Constraints

• For any ASIC chip, design constraints are crucial in driving the functionality of the chip. Incorrect or in-adequate definition of constraints can lead to inconsistencies between the STA signoff tool and the actual functionality of the chip after post-silicon validation
• Since a sanity check of the quality of constraints is critical and significantly impacts the overall time-to-market of any chip, it is strongly recommended to thoroughly perform sanity checks on constraint quality as a part of the timing closure activity
• constraints validation is carried out in conjunction with STA design closure using STA signoff tools such as PTSI (Synopsys) and Tempus (Cadence)
• Nowadays, most PNR tools also offer features to check constraints in the early stages of design closure; however, signoff STA should be done as a part of the final timing closure
• check_timing is main command used to validate the constraints correctness. it  identifies and reports all possible issues in the design, however, the main category to check the check_timing report is no_clock (non-clocked sequential clock pins) and unconstrained endpoints.
• lets discuss each point with mode detail:

No_clock pins / unclocked registers

• The STA/PNR tool can identify the clock pin by checking the “clock” attribute from the timing models (db). For all identified clock pins, the tool checks whether any clock is reaching them or not. If a clock is not reached, the pin is reported as a non_clock pin. 
• To find the reason for a pin being non-clock, the first step is to trace the fan-in cone for the given clock pin. Generally, each tool has its fan-in/fan-out tracing commands. For example, ICC2(Synopsys) has the all_fanin command. The all_fanin command returns either a startpoint (clock pin of any cell) or a port.
• Below are common examples of ‘no clock’ pin warnings and their possible root causes. 

Definition of clock pin is missing

• If fan-in is any port, the first thing to check is whether that port is a clock port or a data port. If it is a clock port, there should be any clock defined on that port. The clock information can be found from the sdc file or using a tool command such as report_clock. 
• At the block level, it is possible that the clock is missing on a given clock port. If the clock is missing at the block level, that port can be treated as a signal port and no clock is built from these ports.
• Solution: From FullChip database, the clock can be further traced using the fan-in tracing and based on FullChip database, the clock can be defined at the block level.

• As seen in the snap above, suppose the CK pin in block C is reported as a non-clock pin. In the block level, there is no clock defined on port P3. As suggested, by looking at the connectivity of the FullChip database, the clock definition similar to the FullChip port “P” needs to be defined at the P3 pin of block C.

FullChip: Clock connectivity is broken due to incomplete netlist

• For the initial FullChip integration, it is possible that the flow block may have a shell/incomplete netlist. This can cause broken connectivity from the input pin to the output pin, which restricts clock propagation.

Undriven inputs pins

• While generating a manual eco using the connect/disconnect command in the clock path, it is possible that sometime any clock cell’s input pin remains floating, which can break the connectivity from the main clock source to the clock sink pin. To detect the undriven input pins, there are other alternative commands available in the PNR/Signoff tools such as check_design.
• Undriven pins can also cause issues in physical verification at a later stage in the physical design flow, but it is always better to have a sanity check during the PNR/early stage of the design cycle.

• As shown in the image above, the undriven input pin A inside block B is causing the clock not to propagate in block C. The CK pin inside block C is reported as an un-clocked pin.

Fanin cone stops at TIE pins

• For the unused flops such as spare flops in design, the respective clock pins are tied high or low using the TIE cells. These kinds of flops that are not expected to be reached, can be waived. There are a few designs where the clock pin is directly connected to the VDD/VSS. In this case, you need to check the case_value attribute of the clock pin. If a flop’s clock pin has either 0 or 1 case value, it can be ignored.

• As shown in the image above, for the non-clock pin CK of block C, the fan-in cone is stopped at a TIE cell. The CK pin is connected to the TIE cell, and is not expected to have a clock, hence, it can be ignored.
• A common example of this case is all clock pins of spare flops.

Clock propagation restricted due to mode setting on a few cells

• If a fan-in cone contains sequential cells, its current mode should be based on the design functional/test mode. If any mode is disabled, for the current active mode, you need to understand the clock propagation based on the active arcs.

• Consider the above case where the IP2 CLK pin was reported as non-clocked in the functional mode. On tracing the fan-in cone, it was noticed that the fan-in cone reported TEST_CK pin and one internal direction pin (*checkpin) of IP1. On reporting the current operating mode for IP1 (using report_mode -nosplit <IP1> ), it is observed that the IP is operating in the functional mode, hence, the TEST_CK pin can be ignored. For the internal pin, the clock is being generated inside the IP1, hence, you need to define the clock on the CKOUT pin of IP1.

Clock propagation restricted due to case analysis on few cells

• While tracing the fan-in cone, any cell having a case_analysis value can cause the clock not to propagate from the clock definition to sink pins. If there are redundant clocks from the test mode which are defined in the functional mode, this can be waived for such scenarios, as non-clock pins are already clocked in the test mode.

• Consider the above case where the flop’s CK pin is reported as non-clock. While tracing the fan-in cone, the clock port is returned, that means the clock is not restricted because of connectivity issues (Also, this can be double confirmed by checking the “clocks” attribute on the sink pin). To understand the issue further for all the fan-in cone cells, use the reported disable_timing as in the example below:
• Report_disable_timing -nosplit [all_fanin -to <sink_pin> -only_cells]
• The above command reported few disabled arcs for the “clock-gate” shown in the image above. Now, to understand all arcs for this cell and check which all arcs are disabled, you can use the following command:
• Total arcs (using command: report_lib -timing_arcs [get_libs <lib_name>] <cell_name> -nos)
• 
  
  
• Thus, for this cell, a total of nine types of arcs exist in lib. To get all the disabled arcs info, the below command is used (report_disable_timing -nos <clock-gate cell>):

• The above-mentioned are all the disabled arcs along with the reason for the same. It is noted from the reason that due to a constant case value on pin “i0”, phy→o arcs are disabled.

Unconstrained endpoints

• This check warns about unconstrained timing endpoints and identifies timing endpoints which are not constrained for maximum delay(setup). 
• Below are some common issues reported as unconstrained endpoints and their possible root causes.

Unconstrained endpoint due to no_clock on endpoint/startpoint

• As shown in the images below, if one of the start points and/or endpoints clock is missing, the endpoint will be reported as unconstrained. If non-clock reason is known/expected, such unconstrained pins can be ignored/waived.

Incomplete IO constraints

• Incomplete IO constraints can also produce unconstrained endpoints. For example, as shown in the image below, the missing “set_input_delay” constrained on the data path causes the D pin of flop1 to be unconstrained endpoint. As the D pin is unconstrained, the path from the data port to D pin will not be optimized properly and it can cause timing issue at the FullChip level.

Unconstrained endpoint due to False path

• As shown in the image below, if the false path is applied between Flop1’s Q pin to Flop2’s D pin, the D pin will be reported as Unconstrained endpoint. You need to check if the applied false path is expected or not, if expected, such unconstrained endpoints can be waived.

Once no_clock and unconstrained_endpoint is resolved , majority of constraints validation done. below are other important checks.

• Timing loop (combinational loops)   : if output of any combo cell is connected to input of any combo cell withing same timing path.
• clock pins receiving multiple clocks : it coukd be due to missing case analysis on any max selection line

I have mentioned the general issues faced while constraints validation. let me know if you have faced any other challange in constraints validation and it was resolved.

if you likes the post, share your feedback and share the post  with your friends/colleagues.