Innovative Ideas for Predictable Success
      Volume 3, Issue 1


Technology Update Technology Update
Better Quality IP Timing Constraints Ensure Predictable
         Chip Integration

Design productivity depends on smooth IP integration, and that requires good timing constraints. Thus rating constraint quality helps predict productivity breakdowns, says Michael Robinson, Senior Design Consultant, Synopsys Professional Services. This article – the first of two – describes quality checks and techniques for qualifying constraints with the Synopsys PrimeTime timing signoff tool.

The industry works hard to determine best practices for IP integration, but often overlooks the effort involved in integrating stand-alone block-level timing constraints into the chip-level timing environment. Inadequate timing constraints can curb productivity for any type of design methodology. To support predictable timing closure and signoff, a team needs a complete high-quality set of constraints. Specifically, the static timing analysis (STA) solution used must get correct input data (netlist, constraints, back-annotated information). Quality checks help to ensure this.

Poor quality IP constraints affect SoC design productivity because they can cause wasted design iterations and delay schedules for many months. These delays are unpredictable. To improve productivity, teams must be able to measure the effects of methodology enhancements – uncertainties about IP constraints make this extremely difficult.

Work is underway to develop standards for delivering IP timing constraints, including the creation of a standard Design Constraint Description Language. This standard encompasses a constraint dictionary and conceptual model, intended for prescribing, representing, and preserving design intent throughout the design cycle. (see and Additionally, VSIA is an open organization developing SoC, IP, and reuse standards to enhance SoC design productivity. (see

Synopsys Professional Services has developed a number of checks to examine whether the IP is fully constrained, the quality of timing values, and the validity of timing exceptions. A team performing these checks on the IP satisfactorily in a stand-alone context has a good chance of successfully performing STA on the integrated IP in the SoC environment.

IP Maturity Implies Quality
The first step in performing an IP quality check is evaluating the IP's maturity. This can be crucial for planning purposes: it isn't unusual for problems integrating complex IP into complex designs to delay projects for as long as six months. The more mature the IP, the higher the probability that most integration issues will have been resolved. Hence, the constraints and documentation should be of higher quality and less risk would be associated with the IP.

Note that the VSIA Alliance Quality IP Metric (QIP) 2.0 makes this evaluation much easier. The QIP consists of spreadsheets that IP providers fill out. The spreadsheets provide yes/no questions covering such topics as documentation, ease of integration, design quality and verification quality. The resulting metrics should reflect the quality of the IP block, as well as the vendor's design and verification practices. (Download these spreadsheets free at

Table 1 provides a checklist to consider when evaluating the maturity of incoming IP. The results paint a rough picture of how much risk is associated with including a specific IP in the SoC. These checks become much more important if the IP is completely new to the team.

Table 1

In general, the more questions checked off, the more likely it is that the IP will work right out of the box. In addition to providing the basis for an overall estimate of IP maturity, some of the items imply a number of specific qualifications and further actions. It is worth noting a few of the more important considerations…

If the design team has used the IP before, but the clock speed or process has changed, it is worth running an initial synthesis and STA analysis step early to ensure the IP can function at the required speed. Check other constraints such as area and power to ensure they can be met. For less mature IP (Table 2), elaboration logs from previous synthesis runs may contain useful information (e.g. they enable discovery of the type of reset structure the design uses).

Table 2

Note: References to tool invocations apply to PrimeTime commands and functions.

Has the design team run check_timing on the IP? If so, carefully consider the use of the IP, as this check is the minimum required to ensure the constraints are reasonable and complete. If not, it should be the first check the implementation team performs.

The design does not necessarily have to meet timing during the first default run. If a default synthesis methodology gives timing within 10 to 20 percent of the clock period, more advanced synthesis may achieve timing closure but is unlikely to close timing if the default methodology shows large violations (unless the first run had obvious problems such as leaving a high-fanout net unsynthesized).

IP Implementation Issues
It's also useful to consider implementation-specific issues for IP constraints relating clocks, resets and test modes (Tables 3 through 5). Typically, more care is required for higher implementation speeds. This consideration depends on the design and the complexity of both the IP and exceptions. A team should focus on the IP blocks it considers critical, especially with high-speed external memory interfaces.

Table 3

Table 4

Table 5

Sometimes generated clocks fan out only to an output port, where it is necessary to create yet another generated clock for constraint integration. All clocks (master, generated at clock divider, generated at interface) are synchronous. Generally, the designer must balance clock divider flops with the other flops. This isn't the CTS tools' default behavior, so it's useful to know if any clock dividing registers should be balanced with the rest of the registers instead of being part of the clock tree. The designer typically declares these as stop pins within the CTS stage.

Clocks that fan out to data pins may also need to different handling by the CTS stage, perhaps by marking certain pins as exclude pins. So it is useful to know if clock signals fan out to data pins (in addition to fanning out to the clock pins).

A team must define all clock domains to ensure it can implement all design modes at the correct frequencies. Remember there can be cases where the fastest clock frequency isn't the most critical. It is also necessary to have all the clock information to ensure the designer builds the clock tree correctly.

If the IP requires internally generated or gated clocks, it is necessary to see what type of clock gating is involved. Differences can occur in the timing for non-integrated clock gating cells between the signoff timing tool and the implementation timing tool unless the designer is careful. Some cells may need their checks turned off or turned on as appropriate within the different tools to ensure consistency.

For resets, take care to make the implementation and signoff environments consistent. For asynchronous resets, the variable enable_recovery_removal_arcs may need setting.

Constraints Optimized for STA
One measure of IP quality is the completeness of the constraints required to fully constrain the design in an optimum manner for STA. Paths that are not completely or correctly constrained will by default not appear in timing violation reports, so violating paths may be overlooked and thus risk timing and even functional failures in silicon.

The constraints' contents are more important than syntax checks. To determine whether the contents of the constraints are of sufficient quality, run a fast quality-assurance check in a stand-alone context for the IP. Checking of input-file syntax and whether these files can be parsed correctly may be automated, but manual evaluations are needed to ensure that the contents of the constraints are reliable. Fortunately, scripting this process minimizes the time required.

PrimeTime has a check_timing command to check whether IP is fully constrained. Once the constraints (clock definitions, I/O delays, and timing exceptions) are well defined, review the output of the check_timing command in detail. If the constraints change significantly when resolving problems, run the check_timing command again.

The check_timing command checks for many different types of issues – not all of them by default. The following form of the command covers the issues that are useful for typical IP checks:

check_timing –verbose -include { latency_override clock_crossing }

This command checks for many different issues. One of the most important is undefined clocking, an error indicating either multiple clocks or no clock to a register clock pin. (Note that a register in this context means a sequential device such as a latch, flip-flop, RAM, ROM, etc.) Clock pins driven by multiple clocks typically occur in designs that have a mux clock without the selection pin being constrained. Unclocked registers create STA problems because setup or hold checks can‘t be performed for a register clock pin that isn't driven by a clock.

Another issue, undefined input arrival times, occurs when timing a path from an input port without a clocked-input external delay (i.e., set_input_delay –clock …). In such cases, PrimeTime creates an imaginary default clock to constrain the inputs. This default clock causes the clocks along the paths driven by the input ports to become related. Usually undefined arrival times represent oversights in the constraints, and the relevant port needs a correct set_input_delay constraint.

A third issue is unconstrained endpoints, errors that usually indicate a lack of setup or hold checks on the analyzed pin. That is, no constraint exists for that pin. To determine whether there is a timing check on a pin for a particular cell, run report_lib library_name -timing_arc cell_name. Alternatively, this error may indicate that the endpoint clock is not reaching the appropriate pin. To find out, check the undefined clocks messages in the check_timing reports. Further investigation of the problem is possible using the report_transitive_fanout –clock_tree command. In addition, do a report_timing –to the relevant endpoint to see if the startpoint and endpoint are unconstrained. STA does not check undefined output ports for timing violations. Usually, the lack of such definitions represents an oversight in the constraints, and the relevant port needs a set_output_delay constraint.

For more information about finding the root cause of unconstrained paths please refer to SolvNet Doc Id: 902136 - Why Am I Getting Unconstrained Paths?

Additional Completeness Checks
If all input and output ports are constrained and all clock pins receive a clock, regard the design as completely constrained. Additional checks may still be useful. For example, checking for partial input delay determines whether any port has a partially defined input delay. This problem occurs when set_input_delay -min is applied on a port, but the equivalent max delay is not set.

To find clock latency specification conflicts, check for clock source latency override. If clock source latency exists for a clock and its port (source pin), ignore the source latency for the clock object. If input_delay is set on a clock port which also has source latency specified, the input_delay is ignored as source latency.

Another issue, combinational feedback loops, is inherently complex for a timing analysis tool to handle. After identifying such a loop, PrimeTime, by default, disables one of the loop's timing arcs (‘static loop breaking'). In some cases, this prevents real paths from being reported because the paths are broken by the disabled arcs used to break the loops. Enabling dynamic loop breaking ensures that no timing arc is disabled to break a loop and all valid paths of the design are reported. However, avoid combinational feedback.

A check for latch fan-out issues results in a warning if a level-sensitive latch fans out to itself. If the timing requirements are unclear for a latch that fans out to a latch of the same clock, an information message is given.

Checking for generated clock networks finds problems in the structure of the generated clock network logic. As a result, accurately calculating the source latency for the generated clock is impossible.

A good way to analyze the synchronous/asynchronous relationship between clock domains is to run a check for paths crossing clock domain boundaries. This check looks at clock interactions when there are multiple clock domains. If a clock launches one or more paths that are captured by other clocks, the interaction generates an entry in the clock crossing report. If all paths between two clocks are false paths or they are exclusive/asynchronous clocks, the path is marked by *. If only part of a path is set as false paths or exclusive/asynchronous clocks, the path is marked by #. The graphical interface of PrimeTime enables the user to look at the clock relationships more clearly,

A check for unmapped logic detects generic (unmapped) cells in the design. The timing of paths through generic cells is inaccurate because generic cells have zero delay. Because members of an SoC team could encounter major difficulties trying to correct these issues by themselves, any such issues that come up in IP development need to be addressed by the IP team. Update the SoC project plan to account for any additional risk associated with the quality of the incoming IP timing constraints.

Another methodology for checking unconstrained paths is to set timing_report_unconstrained_ paths true. This variable specifies whether PrimeTime searches for unconstrained paths when using the report_timing or et_timing_paths commands. During constraints debugging, this methodology can be useful for generating reports of unconstrained paths.

The evaluations of constraint quality presented here are aimed at predicting how well a piece of IP will work when integrated into an SoC. Knowing whether an IP's timing constraints meet quality standards ensure sufficient time is allocated for timing constraint development in the SoC project schedule, or better constraints to be obtained from the IP developers.

The second article provides many additional quality evaluations and covers special cases such IP that has multiple clocks per register or multiple constraint files.

Author Biography
Michael Robinson is a Senior Design Consultant with Synopsys Professional Services. He has more than 18 years experience in IC design and EDA tool development with a specific focus on behavioral, logic synthesis and static timing analysis. Prior to joining Synopsys, he worked as a design engineer on multiple ASIC design projects with Philips.

©2010 Synopsys, Inc. Synopsys and the Synopsys logo are registered trademarks of Synopsys, Inc. All other company and product names mentioned herein may be trademarks or registered trademarks of their respective owners and should be treated as such.

Having read this article, will you take a moment to let us know how informative the article was to you.
Exceptionally informative (I emailed the article to a friend)
Very informative
Somewhat informative
Not at all informative

Register Buttom

Email this article

- VSI Alliance Quality IP Metric
- "Reusable timing constraints for efficient SoC STA environment integration", Mario Vergara-Escobar, Ericsson AB, SNUG Europe 2005.

"The first step in performing an IP quality check is evaluating the IP's maturity."