Input Delays

Part II · Module 20 · Chapter 20.3 · Input Delays

Data arriving at a block's input did not appear there spontaneously. Something launched it — a flop in another block, a chip on the board — and that launch took time after its own clock edge.

An input delay tells timing analysis how much of the cycle was already used before the data reached you. Without it, the tool assumes zero.

1. What zero means

If you declare no input delay, the analysis does not treat the path as unconstrained. It treats the data as arriving at the clock edge, with the entire period available to get through your logic.

That is almost never true, and the error is in the optimistic direction: the report shows more slack than exists. A path that passes by 0.1 ns in the report, with a real upstream launch of 0.4 ns, is failing by 0.3 ns in silicon.

2. The declaration

set_input_delay 0.4 -clock core_clk [get_ports {d_in[0]}]

Read it as: relative to core_clk, this data arrives 0.4 into the cycle.

Three parts:

• The value — how much of the cycle the upstream path already consumed.
• -clock core_clk — which clock it is relative to. An input delay without a clock is meaningless, because "0.4 late" only means something against a cycle.
• The target — a collection, so Module 18 applies, including 18.8's silent empty case.

3. Applying it to a whole bus

A collection can hold the whole bus, so one command covers every bit:

set_input_delay [expr {$PERIOD * 0.20}] -clock core_clk [get_ports {d_in[*]}]

=== one budget for the whole bus ===
    d_in[0]      0.4
    d_in[1]      0.4
    d_in[2]      0.4
    d_in[3]      0.4

Four ports, one line. Add a bit to the bus and nothing changes.

Remember Chapter 20.1 §5: the bus pattern is braced, because [ is command substitution in Tcl. [get_ports d_in[*]] without braces tries to run a command.

4. Express it as a fraction of the period

This is the practice that separates a constraints file that ages well from one that quietly rots:

set PERIOD 2.0
set IN_FRAC 0.20
set_input_delay [expr {$PERIOD * $IN_FRAC}] -clock core_clk [get_ports {d_in[*]}]

The budget is now 20% of the cycle, which is what you actually meant.

5. Why that matters

foreach p {2.0 1.5 1.0} {
    puts [format "    period %.1f -> input budget %.2f (20%%), output budget %.2f (15%%)" \
        $p [expr {$p * 0.20}] [expr {$p * 0.15}]]
}

=== what the fraction means when the period changes ===
    period 2.0 -> input budget 0.40 (20%), output budget 0.30 (15%)
    period 1.5 -> input budget 0.30 (20%), output budget 0.22 (15%)
    period 1.0 -> input budget 0.20 (20%), output budget 0.15 (15%)

6. Where the number comes from

The value is not arbitrary. It is a budget negotiated between blocks, and it has three plausible sources:

• Measured from the upstream block's actual output delay, once it exists.
• Budgeted at the start of the project — the interface specification that says the sender gets 20% of the cycle and the receiver gets the rest.
• Specified by a component outside the chip, where the datasheet states the launch timing.

What matters is that the number is written down somewhere other than the SDC, and that both sides of the interface use the same one. An input delay of 0.4 at the receiver and an output delay of 0.3 at the sender means somebody has 0.1 ns that nobody owns.

7. Which ports need one

Every input except the clocks themselves. That is the rule, and it is checkable — which is what Chapter 20.8 does:

  ERROR   3 input port(s) with no input delay: ref_clk, reset_n, cfg_mode

A clock port does not need an input delay because it is not data; it is the reference everything else is measured against. Every other input does, including the ones that feel like they do not:

• Reset — usually asynchronous in assertion and synchronous in release, and the release path is timed.
• Configuration and mode pins — static in operation, but they still have a timing relationship at the moment they change. If they genuinely never change during operation, that is a false path with a reason recorded, not an omission.

Omission and exception are different things. An omitted constraint is silent; a declared exception is a claim somebody can review. Always prefer the second.

8. Exercises

Exercise 1. What does timing analysis assume about an input with no delay declared?

Exercise 2. Why is that error in the dangerous direction?

Exercise 3. Why must an input delay name a clock?

Exercise 4. Write one command that applies a 20% budget to every bit of d_in.

Exercise 5. The period changes from 2.0 to 1.0 and the input delay is the literal 0.4. What happened to the budget?

Exercise 6. Name three places the delay value can legitimately come from.

Exercise 7. A mode pin never changes during operation. Should it have an input delay?