Page loading . . .

 You are at: The item(s) you requested.Sunday, September 25, 2016
Evaluate IP Timing Constraints Before Use in SOC Designs  
Contributor: Synopsys, Inc.
 Printer friendly
 E-Mail Item URL

July 1, 2006 -- When combining intellectual property (IP) blocks from various sources, you must have a complete, high-quality set of timing constraints for efficient SoC timing closure and signoff. Otherwise, IP integration problems can cause long delays. Quality checks on inputs such as the IP netlist, back-annotated information, and the timing constraints themselves help assure that your full-chip integration will go smoothly.

There are several types of quality checks for timing constraints that have proven effective in minimizing IP integration issues. For IP developed by another group or company, the top-level SoC implementation team may not have the detailed IP knowledge required to develop timing constraints for the IP. If you work with IP as part of an SoC implementation team, you have to use timing constraints from the IP providers, and these constraints vary greatly in their quality.

The task of integrating IP timing constraints into the overall SoC timing environment has been often overlooked, even though a lot of effort has gone into determining best practices for integrating the IP itself. The industry is now catching up by developing standards for delivering IP constraints, including the creation of the Design Constraint Description Language. Along with the constraint description language, this standard encompasses a constraint dictionary and a constraint conceptual model, all intended for the prescription, representation, and preservation of design intent throughout the design cycle. (For more information, see

This article intends to augment the standards efforts by providing best practices for evaluating the quality and completeness of IP constraints. These practices are derived from the experience of Synopsys design consultants on dozens of SoCs and apply to any design environment. The specific STA commands used to illustrate the methods are PrimeTime® commands. The main goal of the practices covered here is to answer four critical questions:
  • Is the IP fully constrained?
  • Are timing exceptions valid?
  • Are the constraints realistic?
  • Are the constraints suitable for all the tools in the flow?

If you get satisfactory results from these checks on the IP in a stand-alone context, the SoC integration team has a good chance of successfully performing STA on the integrated IP within the SoC environment. After performing these checks, however, you still need to evaluate the constraints manually to know whether they are acceptable or not.

Understanding IP implementation constraints

When evaluating IP constraints, consider issues such as the following.
  • For clocks:
    • What is the implementation priority (speed, area, power)? Typically, the higher the implementation speed, the more care you have to take to ensure that the design is achievable. When using a 90-nm process, for example, typically a clock frequency of 800 MHz poses more problems than a clock frequency of 300 MHz. Of course, this consideration depends on the design and the complexity of both the IP and exceptions. The focus should be on the IPs that are considered critical for ASIC devices, especially in the case of high-speed external memory interfaces.
    • Have all the clock domains been defined? Defining all clock domains is essential to ensure that you can implement all design modes at the correct frequencies. Remember that the fastest clock frequency may not be the most critical one. Additionally, you must have all the clock information to ensure that you can build the clock tree correctly.
    • Does the IP require one or more internally generated or gated clocks? If so, does the IP design consolidate all generated clocks into a separate module at the top level of the hierarchy? The answers to these questions indicate the type of clock gating you should check for. Differences can occur in the timing for non-integrated clock gating cells between the signoff timing tool (such as PrimeTime) and the implementation timing tool (such as DesignTime™) unless care is taken. To ensure consistency, you may need to turn the checks on some cells on or off as appropriate for different tools.
    • Which clocks are synchronous and which asynchronous?
    • Which clocks need to be balanced during clock tree synthesis (CTS)?
    • Does the module contain any asynchronous input signals?
    • Has metastability protection been used?
    • Does the design use positive- and negative-edge flip-flops?
    • What are the potential effects of an asymmetric clock source and clock jitter?
    • Is the worst-case duty cycle modeled for timing analysis and synthesis?
    • Is the duty cycle documented?
    • Are positive-edge-triggered flip-flops in a different module than negative-edge-triggered flip-flops?
    • Have you considered all the timing exceptions?
      • Multicycle paths?
      • False paths?
      • Combinational paths (max / min delays)?
  • For resets:
    • Does the design contain an internally generated conditional reset? If so, is this conditional reset generated within a separate top-level module?
    • Are all flip-flops reset in the same fashion (e.g., asynchronous active-low)? Be careful to ensure consistent implementation and signoff environments. For asynchronous resets, you may need to set the synthesis variable enable_recovery_removal_arcs, in order to enable the compile, report_timing, and report_constraint commands to accept recovery or removal arcs specified in the library.
    • Does each clock domain have an independent reset line?
    • Do all bidirectional pins get set to input mode during reset?
    • Is the operation of the module predictable when the reset is removed?
  • For test modes:
    • Have all the test mode constraints been developed?
      • HSBIST, SWBIST, scan shift, scan capture, etc.?
      • Is at-speed testing needed? If so, for which clocks?

Checking constraint quality

High quality IP will have a complete set of constraints that fully constrain the design in an optimum manner for STA. Syntax checks are important, but the constraints’ contents are more important. Using a fast quality-assurance check in a stand-alone context for the IP (Figure 1), you can quickly determine whether you are getting the quality you need.

Figure 1. Flow for checking IP constraints quality.

While it is possible to automate the checking of input file syntax and whether these files can be parsed correctly, you need manual evaluations to ensure that the contents of the constraints are reliable. Fortunately, you can heavily script this process to minimize the time required.

If these checks find that the IP constraints are not of sufficient quality, you need to either reject the IP (send it back to the IP implementation team) or incorporate additional risk into the project plan. If you see severe problems, you usually have good cause for rejecting the constraints. You might regard less severe problems as anomalies that allow design work to continue while the implementation team clears up the IP issues. Any problem increases project risk and should be accounted for in project planning. Experience has shown that an SoC implementation team can spend many person-months cleaning up incomplete constraints. The scope of this clean-up task is unpredictable and can be dramatic because you often find the problems serially rather than in parallel.

Note that the following quality checks work best when only a single clock is allowed to propagate to a register. The last part of this article provides information on dealing with multiple-clock cases.

IP fully constrained?

Checking for a full set of constraints is important because paths that are not completely or correctly constrained will not, by default, appear in timing violation reports. As a result, you may overlook a violating path—only because it is not constrained.

You can perform many checks for constraint completeness automatically. PrimeTime, for example, incorporates a check_timing command for this purpose. Once you ensure that the constraints (clock definitions, I/O delays, and timing exceptions) are well defined, review the output of the check_timing command in detail. Moreover, once you have resolved any problems, run the check_timing command again if the constraints change significantly. These are the most important constraint issues to check:
  • Undefined clocking—This problem can occur in the absence of a clock signal propagating to a register clock pin. Unclocked registers create STA problems because you cannot perform setup or hold checks for register clock pins that are not driven by a clock.
  • Undefined input arrival times—When timing a path from an input port with no clocked-input external delay, an STA tool typically creates an imaginary default clock so that the inputs are constrained. 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.
  • Unconstrained endpoints—This error may mean that a pin has no setup or hold check. That is, no constraint exists for that pin. Using PrimeTime, you can determine whether there is a timing check on a pin for a particular cell by running report_lib library_name -timing_arc cell_name. Alternatively, unconstrained endpoints may occur because the endpoint clock is not reaching the appropriate pin. To find out with PrimeTime, check the undefined-clocks messages in the check_timing reports. You can investigate the problem further using the report_tranitive_fanout –clock_tree command. In addition, do a report_timing to the relevant endpoint to see if the startpoint and endpoint are unconstrained. Note that STA does not check undefined output ports for timing violations. Usually, the lack of such definitions represent an oversight in the constraints, and the relevant port needs a set_output_delay constraint.

Because you may encounter major difficulties trying to correct these issues within the SoC implementation team, the best approach is to refer any issues that come up to the IP team. You also need to update the project plan to account for any additional risk associated with the quality of the constraints.

When using the check_timing command, bear in mind that it checks for many different types of issues, and not all are done 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 }

Another methodology for checking unconstrained paths is to set timing_report_unconstrained_paths true.

This variable specifies whether PrimeTime searches for unconstrained paths when you use the report_timing or get_timing_paths commands. During constraints debugging it can be useful to report unconstrained paths.

Timing checks active?

Next you need to find out whether any of the timing checks are unexercised and, if so, why. The PrimeTime command report_analysis_coverage generates a report showing information about the coverage of timing checks in the design.

There may be valid reasons why setup or hold checks are not being analyzed. For functional analysis, for example, often the scan enable is set to a constant using the set_case_analysis command. This practice forces the scan inputs of each flip-flop to behave as if they where tied to a constant value. In such cases, you might find it useful to be more specific about the checks required. For example, running the report_analysis_coverage with the option -exclude_untested {constant_disable} removes untested paths, due to constants, from the analysis report.

Timing exceptions valid?

Checking the validity of timing exceptions is the next step in checking the quality of the IP constraints. Timing exceptions may be invalid for several reasons:
  • The exception is out of date relative to the design and should have been removed.
  • An exception path has an invalid startpoint or endpoint.
  • A multicycle path exception specifies single-cycle values.
  • There is no path between the exception specifiers.
  • The exception is set on an unconstrained path.
  • The exception is overridden by a higher-precedence exception.
  • The exception is overridden because of mode analysis.
  • The exception is overridden due to exclusive clock groups.

The STA tool typically ignores such invalid timing exceptions, and they may not cause problems directly. However, multiple exception-setting commands with overlapping path specifications can make it difficult to understand the scope of each command. More importantly, large numbers of ignored exceptions can increase memory usage and analysis runtime, so they should be corrected by changing the path specifications or removing the exception-setting commands.

Constraints suit all the tools?

Synthesis and timing analysis tools typically accept general timing commands using Tcl syntax. In addition to using these commands to synthesize and analyze a design, the tools may generate other types of constraints descriptions for other tools. Synopsys tools, for example, use Synopsys Design Constraints (SDC) descriptions to specify design intent, including timing and area constraints. While all Synopsys tools read valid SDC 1.4 syntax, tools do have differences in the way they handle SDC. For example, while Design Compiler supports all the command options specified in the SDC1.4 specification, the tool does not support any _ options in any timing commands, because these options are not standard SDC1.4 specification.

To determine whether your IP constraints suit every tool in the flow, a syntax checker should be written. This is easily done utilizing a Perl script. Synopsys’ SolvNet online support site ( has several articles that detail the different constraints syntax across the Synopsys platforms.

Constraints realistic?

You can check standard timing reports to make sure IP constraints are realistic. You need not worry about small violations that could be fixed by using a better synthesis methodology. Rather, look for gross violations that miss timing by a large percentage or even more than a clock cycle. Such violations indicate that the constraints are most likely incorrect or the design is not suitable for the intended task.

The IP implementation team can carry out this check, preferably with support from STA experts. You need to identify whether a timing problem is real. If so, the IP design needs to be fixed. If not, you need to add a timing exception (false or multi-cycle path) to the constraint file.

Checking multiple clocks per register

As mentioned earlier, all of the checks described in the previous sections work best when only a single clock is allowed to propagate to a register. You can allow multiple clocks, however. In PrimeTime you enable (or disable) the analysis of multiple clocks that reach a register clock pin with the variable timing_enable_multiple_clocks_per_reg. When true (the default), the tool analyzes all clocks reaching the register simultaneously. When false, the tools usually select the clock that was generated last as the source clock for the register. Note, this is different from the behavior of the Synthesis tool and hence this not a recommended design practice.

You must take extra care in running the constraint checks when timing_enable_multiple_clocks_per_reg is true. Specifically, when running the check_timing command with the multiple_clock option, you must turn off timing_enable_multiple_clocks_per_reg (default is on). Otherwise PrimeTime assumes that having multiple clocks per flop is correct and does not warn about these cases. Check that all the register groups receive the correct clocks. If a subsystem has the option of being clocked by clk and clk_div_2, for example, all the registers in the subsystem should show these cases as multiple driven clocks.

In addition, it is a good practice to run the checks described in the previous sections on each set of synchronous clock domains individually. This practice makes it possible to check that registers are clocked by the relevant clocks. You can check each set of synchronous clock domains individually by defining which groups of clocks are active (set_active_clock) for the current analysis.

To do all the evaluations described here, you may spend a considerable amount of time analyzing timing reports, understanding the timing problems, and generating new constraints or a new implementation to meet timing. But by spending the time to get golden timing constraints at the start of the SoC implementation flow, you can implement higher-quality chips with greater confidence, better predictability, and often in much less time.

By Michael Robinson

Michael is a Senior Design Consultant for 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.

Synopsys, the Synopsys logo and PrimeTime are registered trademarks and DesignTime is a trademark of Synopsys, Inc. Any other trademarks or registered trademarks mentioned in this article are the intellectual property of their respective owners.

Go to the Synopsys, Inc. website to learn more.

Keywords: SOCcentral, Synopsys, timing analysis, verification, intellectual property, IP, cores,
488/19400 7/1/2006 21156 21156
Add a comment or evaluation (anonymous postings will be deleted)

Designer's Mall

Copyright 2002 - 2004 Tech Pro Communications, P.O. Box 1801, Merrimack, NH 03054
 Search site for:
    Search Options

Subscribe to SOCcentral's
SOC Explorer
and receive news, article, whitepaper, and product updates bi-weekly.


Verification Contortions

Dr. Lauro Rizzatti
Verification Consultant
Rizzatti, LLC

Real Talk

Drilling Down on the Internet of Things

Ramesh Dewangan
VP Product Strategy
Real Intent, Inc.

SOCcentral Job Search

SOC Design
ASIC Design
ASIC Verification
FPGA Design
DSP Design
Analog Design
Digital Design
Mixed-Signal Design
RF Design
EDA Tool Development

IC Packaging
PCB Design
RTOS Development
RTL Design
SystemC Design
SystemVerilog Design
Verilog Design
VHDL Design

Post a Job
Only $100 for 30 days

Special Topics/Feature Articles
3D Integrated Circuits
Analog & Mixed-Signal Design
Design for Manufacturing
Design for Test
ESL Design
Floorplanning & Layout
Formal Verification/OVM/UVM/VMM
Logic & Physical Synthesis
Low-Power Design
On-Chip Interconnect
Selecting & Integrating IP
Signal Integrity
Timing Analysis & Closure
Transaction Level Modeling (TLM)
Design Center
Tutorials, Whitepapers & App Notes
Archived Webcasts


Sponsorship/Advertising Information

The Home Port  EDA/EDA Tools  FPGAs/PLDs/CPLDs  Intellectual Property  Electronic System Level Design  Special Topics/Feature Articles  Vendor & Organization Directory
News  Major RSS Feeds  Articles Online  Tutorials, White Papers, etc.  Webcasts  Online Resources  Software   Tech Books   Conferences & Seminars  About
Copyright 2003-2013  Tech Pro Communications   1209 Colts Circle    Lawrenceville, NJ 08648    Phone: 609-477-6308
1  1.171875