Exception Precedence and Pitfalls

A real constraint file has many exceptions, written by different people over months. Sooner or later two or more of them apply to the same path. STA then has to decide which one wins, and the result is not always what the person who wrote the last command expected. This article shows the order of precedence, tests it with the tool, and lists the pitfalls that cause most wrong exceptions: commands that are too wide, a multicycle path without its hold command, and exceptions that no longer match anything.

9 min read | Intermediate

What You'll Learn

• Name the order in which exceptions override each other
• Predict the result when two exceptions apply to the same path
• Explain why a specific exception beats a general one
• Review a constraint file for the most common exception mistakes

Which Exception Wins

When more than one exception applies to a path, the stronger kind is used. The order, from strongest to weakest, is:

1. set_false_path: the path is not checked at all.
2. set_max_delay and set_min_delay: a fixed delay budget replaces the clock-based check.
3. set_multicycle_path: the capture edge moves by whole cycles.
4. No exception: the default one-cycle check.

Here are two tests on the path from _7_ to _6_ of the demo circuit. The first combines a multicycle path with a false path:

set_multicycle_path 2 -setup -from [get_pins _7_/CLK] -to [get_pins _6_/D]
set_false_path -from [get_pins _7_/CLK] -to [get_pins _6_/D]

The result is No paths found for this path. The false path wins completely, for setup and hold, and the multicycle command has no effect. The second test combines the multicycle path with a max delay:

set_multicycle_path 2 -setup -from [get_pins _7_/CLK] -to [get_pins _6_/D]
set_max_delay 0.6 -from [get_pins _7_/CLK] -to [get_pins _6_/D]

max_delay/setup group clk
_6_/D (sky130_fd_sc_hd__dfxtp_1)        0.4826    0.4323    0.0502 (MET)

min_delay/hold group clk
_6_/D (sky130_fd_sc_hd__dfxtp_1)        1.9417    0.3657   -1.5759 (VIOLATED)

For setup, the max delay of 0.6 ns is used. The required time is 0.6 - 0.1174 = 0.4826 ns and the slack is 0.0502 ns. The setup multiplier of the multicycle path was ignored. But the hold check is still affected by the multicycle path, because the max delay only replaces the setup check: the hold edge moved to 2.0 ns and the hold slack is -1.5759 ns. A combination of exceptions can therefore do different things for setup and hold. Always read the report for both checks.

Specific Beats General

There is a second rule. When two exceptions of the same kind apply, the one that names more specific points is used. A command with a pin pair beats a command with a clock, and a command with a pin beats one with a clock or the whole design. A test shows it. A multicycle path of 2 is set for all paths that start at the clock, and one of 3 for the path from _7_ to _6_:

set_multicycle_path 2 -setup -from [get_clocks clk]
set_multicycle_path 3 -setup -from [get_pins _7_/CLK] -to [get_pins _6_/D]

For the path from _7_ to _6_, the setup capture edge is at 6.0 ns, which is the multiplier of 3. The setup slack is 5.4502 ns. If the numbers are swapped, so that the clock command has 3 and the pin command has 2, the pin command wins again, and the setup slack is 3.4502 ns. The order in which the commands are written does not matter here. It is the specificity that counts.

Common Pitfalls

• A false path that is too wide. It overrides all other exceptions on the paths it covers, and removes them from the checks. A -through on a shared gate can remove paths that you never thought of, as the article about false paths showed.
• A multicycle setup without the hold command. The hold check is moved by one cycle, and the result is a hold violation of about one period.
• An exception that matches nothing. If the pins in the command do not exist, or the netlist has changed names, the command does nothing and gives only a warning. The path stays under the default rule, and often you do not notice.
• An old exception that is no longer valid. A false path that was right for the last version of the design may remove a real path in the next one.
• The same exception written twice with different values. One of them wins, and the other one gives a false feeling of control.

Reviewing a Constraint File

A review of the exceptions takes little time and finds most of the problems:

• Make a list of all the exceptions with the reason. An exception without a reason is a candidate for removal.
• For each one, report the path that it is meant for and check that the report has the check type, the edge and the slack that you expect.
• Run check_setup -verbose and look for unconstrained endpoints and unclocked pins that are new.
• Count the paths or endpoints before and after each exception, and make sure that the change is the one you expect.

The order of the commands in the file does not decide which exception wins. But keep related commands together, such as the setup and the hold command of a multicycle path, so that a reader sees both.

Common Mistakes

set_multicycle_path 2 -setup -from [get_pins _7_/CLK] -to [get_pins _6_/D]
set_max_delay 0.6 -from [get_pins _7_/CLK] -to [get_pins _6_/D]