Library Characterization Tidbits: Did Your Search for Constraints Fail?

29 Jun 2020 • 4 minute read

Hello there!

How have you been? Hope all is well.

In this tidbit, I'm sharing troubleshooting information with you. While using the Cadence^® Liberate^TM Characterization solution or the Liberate Variety^TM statistical characterization solution, have you encountered a situation where the search for constraints failed to return results within the specified range of arcs and then the related cell was marked as failed?

Praveen Patel, Product Engineering Director at Cadence for Liberate Characterization Portfolio, shares that this could have possibly happened due to one of the following reasons:

Reason #1: If the 'glitch' metric was used, then the glitch tolerance might be excessively tight. Due to this, the bisection search might fail to identify the real search bounds for both passing and failing windows. So, check the glitch settings you have set and adjust the values of the following parameters: constraint_glitch_peak, constraint_glitch_peak_internal, and constraint_glitch_peak_max.

It is also possible that there is a large inherent glitch on the probe node for the searched constraint. An inherent glitch refers to a glitch that occurs due to switching of the related pin. Note that this glitch is not caused by the race conditions between the pin and the related pin. A large inherent glitch can itself violate the constraint_glitch_peak settings, resulting in no valid search window for the bisection. In this case, you might want to pad the glitch tolerance with an inherent glitch peak voltage using the constraint_glitch_peak_mode parameter.

When constraint_glitch_peak_mode is enabled, that is, set to 1 or 2, do use the constraint_glitch_peak_report_inherent parameter to request a report in the log file of all measured inherent glitches.

Reason #2: It is possible that you had set a large final state threshold value using the constraint_check_final_state_threshold parameter. When a 'delay' metric is used for constraint characterization, additional criteria to check the final state of internal probes, other wires/nets, and output could be applied based on the constraint_check_final_state parameter. At this time, the upper and lower bound on the probes (wire/nets) are determined by the constraint_check_final_state_threshold parameter. If the probe node voltage is between the lower and upper bound, then the final state of this node is considered unstable and the related bisection search is marked as failed. To avoid this issue, you can try setting constraint_check_final_state_threshold to a smaller value.

Reason #3: The constraint_search_bound value might be too small. It is possible that you need a larger search bound. You can roughly calculate and set an appropriate constraint_search_bound value as shown below:

2 x (expected-largest-delay + maximum (max-input-slew, expected-largest-transition))

In addition, ascertain that the sim_duration value is large enough to accommodate the set constraint_search_bound.

If the reasons given above, do not apply to your case, Praveen has explained four more possible reasons in his troubleshooting article published on the Cadence Support portal. Check if any of those help you in resolving the problem. If not, then do contact your Cadence support representatives. They will surely assist if more is needed beyond this self-help article.

I’m signing off for now. As always, take care and stay safe!

~Abha Rawat

Related Resources

About Library Characterization Tidbits

Library Characterization Tidbits is a blog series aimed at providing insight into the useful software and documentation enhancements in the LIBERATE release. In addition, this series would broadcast the voices of different bloggers and experts, who would share their knowledge and experience about all the tools in Liberate Characterization Portfolio. To receive notifications about the new blogs in this series, click Subscribe and submit your email ID in the Subscriptions box.