Innovative Ideas for Predictable Success
      Volume 3, Issue 1


Technology Update Technology Update
IP Timing Constraints that Meet Basic Design Requirements
         Greatly Simplify SoC Integration

In the concluding half of his discussion of timing constraints, Michael Robinson of Synopsys Professional Services covers timing checks, reuse guidelines for block-level constraints and the special case of allowing multiple clocks per register.

Read part one

Find Unexercised Timing Checks
After checking maturity, constraint quality and whether the IP is fully constrained, you need to find out whether timing checks are active. Unexercised timing checks do not necessarily indicate a problem, but you need to find out why they are not exercised.

Using an STA tool like Synopsys' PrimeTime®, generate a report showing information about the coverage of timing checks in the design. In PrimeTime, use the report_analysis_coverage command. In addition to showing the number and percentage of results that meet and violate constraints, the report shows untested checks such as setup/hold checks that have been overridden by a command such as set_false_path. The timing checks are either specified by the user (e.g. set_output_delay) or the vendor (e.g. the setup check for a register).

There may be valid reasons why setup or hold checks are not being analyzed (e.g. a design setup for functional mode analysis might result in the report shown in Figure 1).

Figure 1: Example timing report

For functional analysis, often the scan enable input is set to a constant using the set_case_analysis command, thus forcing the scan inputs of each flip-flop to behave as if they are tied to a constant value. In such cases, it is often useful to be more specific about the checks required (e.g. running report_analysis_coverage with the option -exclude_untested {constant_disable} removes untested paths from the analysis report).

PrimeTime's distributed multi-scenario analysis feature enables you to perform several analysis runs to verify all of a design's modes and operating corners in parallel. It is possible to merge the runs using Perl.

Check Timing Exception Validity
"Ignored timing exceptions" are those entered by the user but not accepted by PrimeTime – e.g. because an exception may be out of date relative to the design and should have been removed, because a multi-cycle path exception specifies single-cycle values, or for another reason

They may not cause problems directly, but multiple exception-setting commands with overlapping path specifications can make it difficult to understand the scope of each command. Large numbers of ignored exceptions can increase memory usage and analysis runtime, so correct them by changing the path specifications or removing the exception-setting commands.

The PrimeTime command report_exceptions -ignored lists ignored exceptions. Figure 2 shows an example report. The transform_exceptions command can transform the current set of exceptions into a simpler set of equivalent exception-setting commands. You can also use this command to get information about the exceptions that apply to a particular path or group of related paths.

Figure 2: Example for report exceptions

In PrimeTime, the report_timing command has an option, -exceptions, which reports user-entered timing exceptions such as false paths, multi-cycle paths, and min/max delays, which are valid for the reported timing path.

Make Sure Constraints Work with Your Tools
Synopsys synthesis and timing analysis tools accept general timing commands using Tcl syntax. In addition to using these commands to synthesize and analyze a design, the tools can generate Synopsys Design Constraints (SDC) descriptions for other tools and read SDC descriptions from/to other tools. SDC is a standard format used to specify design intent, including timing and area constraints.

It is important to ensure all tools in your flow interpret the SDC in the same manner (e.g. while SDC 1.6 supports command options such as <rise/fall>_<from/to>, specific tools may not support this). Additionally, different tools may have slight variations of interpreting SDC commands (e.g. some synthesis tools will add all the values of any set_clock_latency specified on the clock tree while PrimeTimeand Design Compiler® will take the last value specified in the transitive fan in of the clock pin).

Get Real
Next, make sure the block constraints are realistic by examining standard timing reports. You need not look for small violations that could be fixed by using a better synthesis methodology (e.g. up to 10% of the clock period). Rather, find gross violations that may miss timing by a large percentage or even more than a clock cycle. Such violations indicate the constraints are most likely incorrect or the design is unsuitable for the intended task.

Perform this check with the IP implementation team or, even better, with your STA experts as well. If you identify an actual timing problem, you must fix the block design. If the timing problem isn't real, typically a timing exception (false or multi-cycle path) needs to be added to the constraint file. Unfortunately, you can spend a considerable amount of time analyzing timing reports, understanding the timing problems, and generating new constraints or a new implementation to meet timing.

Supply the IP implementation people with an example of the block in a typical SoC environment to act as a reference design with constraints and reports. While the obvious areas of concern are the gross violations, it can also help to perform sanity checks against passing paths. It is often necessary to review both failing and passing paths because a number of misunderstandings or mistakes can happen while developing the constraints. Someone may have specified an incorrect false path, for example, or the IP integrator might set an IO delay parameter with the wrong sign. A common mistake is using a positive value for the min output delay when a negative value is actually required.

Another type of misunderstanding occurs when the person writing the block-level constraints assumes an offset in the waveform definition of one clock with respect to another, but at SoC level the waveform definition is the same and the offset is introduced by a source latency, modifying the behavior of multi-cycle path (MCP) multipliers between these two clocks.

Other mistakes occur when IP constraints wrongly contain an MCP -hold 1 that opens the valid arrival window. Block designers, might more easily identify a problem if they see a hold check with a positive slack of about a cycle rather than understanding what MCP -hold 1 between a core clock and an interface clock means.

Teams spending time on getting golden timing constraints at the start of the SoC implementation flow can implement higher-quality chips with greater confidence, better predictability, and likely in much less time.

Dealing with Multiple Clocks per Register
All of the checks described so far (including those in the previous article in this series) work best when only a single clock is allowed to propagate to a register. However, a true value for the PrimeTime variable timing_enable_multiple_clocks_per_reg enables analysis of multiple clocks that reach a register clock pin. When true (the default), PrimeTime simultaneously analyzes all clocks reaching the register. When false, it selects a random clock for analysis from among all clocks reaching the register clock pin.

When timing_enable_multiple_clocks_per_reg is true, take extra care in running the constraint checks. 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 doesn't warn about these cases.

Additionally, check that all the register groups receive the correct clocks. If a subsystem can be clocked by clk and clk_div_2, for example, all the registers in the subsystem should show these cases as multiple driven clocks.

Further, it is a good practice to run the checks described in these articles 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.

Addressing Signoff Requirements
In addition to checking that the IP timing constraints work correctly both standalone and within the SoC during the RTL design phase, it is equally important to ensure the IP constraints are compatible with the back-end design team's signoff environment.

Using the example of multiple clocks, some signoff environments may not allow timing constraints that apply multiple clocks on a single register. If the IP constraints require the use of an unsupported feature such as this, rewriting these constraints is a demanding task.

IP Constraints Reuse
Applying reuse techniques when developing block timing constraints help promote successful integration of the constraints into an STA environment. Typically, IP design blocks have three different sets of constraints:

  • Synthesis and timing environment constraints (e.g. set_ideal_net, operating conditions, STA setup variables)
  • IP-level constraints (e.g. clocks, input delay, output delay)
  • Timing exceptions

To help IP providers and SoC integration teams, split these different constraints into separate files rather than using a single file. Table 1 shows which type of constraints go into each. IP providers can use this technique to hide specific IP information, such as synthesis constraints, that SoC implementation teams may not need. Multiple files allow SoC implementation teams to focus more easily on the parts required to manage implementation. Timing exceptions are mandatory, for example, while IP-level constraints are for reference, and synthesis constraints can be ignored.

That the IP-level constraints are for reference purposes may seem strange, but consider the example of an input delay for the IP at the block level. This constraint may change when moved to the top level. At the block level, typically the input delay relates to a particular virtual clock. At the SoC level, the constraint may remain unchanged as the IP input pin is connected to a primary input port on the SoC level. (The actual delay value may change to allow for pad delays, etc., but the syntax set_input_delay relevant to a virtual clock would remain unchanged.) Alternatively, the pin may now be driven by a register at the SoC level, eliminating the need for an input delay.

Another example to consider is a clock constraint, which remains a clock at the SoC level. However, the create_clock or create_generated_clock constraint will probably be applied to a different pin in the design. At the SoC level, typically the clock is applied to the driving pin rather than an IP's hierarchical input pin. It is also quite possible that the clock name will change between the top level and the IP block level. If this is the case, you may need to modify the IP-level constraints as well as the timing exceptions.

In addition to using multiple constraint files to promote reuse, IP providers must take care on the syntax and coding of the constraints. Wherever possible, they should be written to have valid start- and end-points, especially at the top level of the design. Consider the example of a false path specified from one of the IP input ports relevant to the clock named sys_clk. Typically, the constraint is defined as set_false_path –from [get_port <input port>] –to [get_clocks sys_ clk]. However, at the SoC level the input port is not a port; it is a hierarchical pin. To avoid this issue, write the constraint as follows:

set_false_path –from [get_clocks virtual_sys_clk]
–through [get_ports_pins <input_port>] –to
[get_clocks sys_clk]

Even with this version of the constraint, SoC integrators must still modify the constraint so that the correct launch clock and capture clock is used.

An alternative method uses the get_ports_pins procedure to deal with the fact that at the top level the constraint needs to be applied to a port, while at the IP block level the constraint needs to be applied to a pin.

When applying the constraints at the IP level, the get_ports_pins command returns the same result as [get_ports input_port]. To apply the constraints from the top level first, set the current_instance to the correct hierarchical level, e.g., hierarchical/instance/path1. Then get_ports_pins returns the pin [current_instance]/input_port, i.e., hierarchical/instance/path1/input_port. The following script implements this alternative method:

if {[get_object_name [current_design]] ==
“top_level_design”} {
   set CMD_PORT_PIN “get_pins”
   set FROM_THROUGH “-through”
   set THROUGH_TO “-through”

} else {
   set CMD_PORT_PIN “get_ports”
   set FROM_THROUGH “-from”
   set THROUGH_TO “-to”

The constraint can then be written as:

set_false_path ${FROM_THROUGH} [${CMD_PORT_PIN} \

which equates to:

set_false_path –through [get_pins
hier/instance/path1/input_port_pin] or set_false_path –
from [get_ports input_port_pin]

depending on whether the constraints are being applied at the top level or the IP level.

Changing Constraints for Different Uses
You can specify constraints differently for PrimeTime or an implementation environment. For example, PrimeTime supports some constraints that the implementation tools do not support, as shown in the following constraints:

if {$synopsys_program_name == “pt_shell” ||
   $synopsys_program_name == “primetime”} {
set_false_path -from [get_clocks virtual_sys_clk] \
   -rise_through [get_pins path/pin_name] \
   –to [get_clocks capture_sys_clk]
} else {
# paths through path/pin_name need to be ignored
set_multicycle_path 2 –setup -from [get_clocks virtual_sys_clk] \
    -through [get_pins path/pin_name] –to \
   [get_clocks capture_sys_clk]
set_multicycle_path 0 –hold -from [get_clocks virtual_sys_clk] \
   -rise_through [get_pins path/pin_name] \
   –to [get_clocks capture_sys_clk]

While these constraints are not an exact equivalent of the PrimeTime constraints, it might suffice to do additional relaxation of the –fall_through paths if they are not critical. If the paths are critical, they can be over-constrained within Design Compiler, IC Compiler, Physical Compiler®, JupiterXT™, and Astro™ by removing the timing exception as follows:

if {$synopsys_program_name == “pt_shell” ||
   $synopsys_program_name == “primetime”}
set_false_path -from [get_clocks virtual_sys_clk] \
   -rise_through [get_pins path/pin_name] \
   –to [get_clocks capture_sys_clk]
} else {

Constraints may also need to be changed for different design modes, as shown here:

if {$test_mode = = 1} {
   create_clock TESTCLK -period …
   set_case_analysis 1 [get_ports TEST_MODE]
} else {
   create_clock CLK -period …
   set_case_analysis 0 [get_ports TEST_MODE]

Ensure Constraint Quality
High-quality timing constraints are crucial to the successful use of IP in SoCs and to overall design productivity. Depending on the maturity of the IP, you are likely to find IP constraints of varying degrees of completeness and accuracy. Without a way to evaluate the quality of IP constraints, you may need to fix the constraints late in the design flow, causing an undesirable and unpredictable impact on the tapeout schedule.

Using the techniques described in this article, you can determine whether IP is fully constrained, whether the timing values are accurate, and whether or not the timing exceptions are valid. In addition to these automated evaluations, check the constraints manually to determine whether they will successfully meet the SoC's design requirements.

©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

"Teams spending time on getting golden timing constraints at the start of the SoC implementation flow can implement higher-quality chips with greater confidence, better predictability, and likely in much less time."