False Paths

Part II · Module 20 · Chapter 20.5 · False Paths

Timing analysis is structural: it finds every path the netlist contains and checks it. Some of those paths cannot actually occur — a configuration signal that is static once the chip is running, two states that are mutually exclusive, a test mode never active in normal operation.

A false path tells the tool to stop checking one. It is the most useful exception and by a wide margin the most dangerous.

1. The declaration

set_false_path -from [get_ports cfg_mode] -to [get_cells u_core]

Do not analyse any path from cfg_mode into u_core. The tool removes them from consideration entirely — not relaxed, not given more time. Gone.

-from and -to take collections, so everything from Module 18 applies, including the empty-match failure from 18.8. A false path whose -from matched nothing silently does nothing, which is at least the safe direction of that mistake.

2. Why it is the dangerous one

Every other constraint in this module can be checked for presence. Chapter 20.8's review can say "this port has no input delay", because the absence is detectable.

A false path cannot be checked that way, because a wrong one looks exactly like a right one. The path is simply not in the report.

3. What the claim actually is

Writing a false path asserts one of these:

• "This signal is static during operation." True for configuration straps set before the core starts; false if software can change the mode at run time.
• "These two states are mutually exclusive." True if the logic genuinely cannot produce both; this is the hardest one to be sure of.
• "This path exists only in a mode we do not time." True for test paths, provided that mode really is never active in mission mode.
• "This crossing is handled by a synchroniser." Common and usually correct — though Chapter 20.7 is often the better instrument for whole clock domains.

Each is a statement about behaviour, which the netlist alone cannot confirm. Somebody knows it, and the constraint is where that knowledge gets recorded — or lost.

4. Recording the reason

Here is the difficulty: real SDC has no -reason option. set_false_path takes -from, -to, -through and similar — there is nowhere to put the justification.

The practical answer is a project wrapper: an ordinary Tcl procedure that demands a reason, records it, and then calls the real command. Because a .sdc file is Tcl (Chapter 20.1), this is available to you with no tool support at all.

proc false_path {from to why} {
    if {[string trim $why] eq ""} {
        error "a false path needs a reason" {} {SDC NOREASON}
    }
    set ::sdc::reason $why
    set_false_path -from $from -to $to
}

Used:

false_path [get_ports cfg_mode] [get_cells u_core] \
    {cfg_mode is static after reset; software sets it before the core runs}

=== two false paths, one justified ===
    from cfg_mode     to u_core     reason: cfg_mode is static after reset; software sets it before the core runs
    from reset_n      to u_core     reason: <NONE GIVEN>

And the part that matters — it refuses:

=== the wrapper refuses an unjustified one ===
    1 / a false path needs a reason

5. What makes a reason good

Not "false path" or "timing fix" or "waived". A reason has to let somebody re-derive the decision in two years:

The test: could a reviewer who was not there decide whether this is still true? If the design changes — software gains the ability to switch mode at run time — a good reason makes it obvious that the exception is now wrong. A weak one makes it invisible.

6. Scope it as narrowly as you can

# too broad: everything from this port to anywhere
set_false_path -from [get_ports cfg_mode]

# narrower: only into the block where the claim holds
set_false_path -from [get_ports cfg_mode] -to [get_cells u_core]

The first excludes every path from that port, including paths into blocks whose behaviour you never considered. The second excludes exactly what you reasoned about.

An over-broad exception is how a false path that was correct when written becomes wrong when the design grows — the new logic inherits an exclusion nobody intended. Say -from and -to, not just -from.

7. Reviewing them

Because each is a claim, the set of false paths is a document, and it should be read as one. Chapter 20.8 checks the mechanical part — that each has a reason — and the rest is human:

• How many are there? A handful is normal. Dozens suggests something structural is being papered over.
• Does each reason still hold? This is a review item at every milestone, not a one-off.
• Could any be a clock group instead? A whole asynchronous domain is better expressed as Chapter 20.7's set_clock_groups than as many individual false paths.
• Could any be a multicycle instead? If the path is real but has more than one cycle, Chapter 20.6 keeps it analysed rather than removing it.

That last point is the most useful instinct to build: a false path removes a path from analysis; a multicycle relaxes it. Prefer relaxing. An exception that keeps the path under analysis will still catch it if it gets much worse; one that removes it never will again.

8. Exercises

Exercise 1. What does a false path do to a path — relax it or remove it?

Exercise 2. Why can a completeness check not find a wrong false path?

Exercise 3. Name two claims a false path might be asserting.

Exercise 4. Real SDC has no -reason. How do you record one so a script can check it?

Exercise 5. Why is a wrapper better than a comment?

Exercise 6. What is wrong with set_false_path -from [get_ports cfg_mode] on its own?

Exercise 7. A path is real but has three cycles to complete. False path or multicycle? Why?