Static Timing Analysis

Static timing analysis, usually called STA, checks whether signals can travel through combinational logic and routing fast enough between registers. It is “static” because it analyzes paths mathematically rather than simulating every input pattern.

Learning Objectives

You will learn to:

• explain setup and hold timing;
• read the meaning of slack;
• identify critical paths;
• understand why timing closure is separate from functional simulation.

The Register-to-Register Path

Most synchronous timing checks look like this:

The data launched by the source register must arrive at the destination register early enough before the next active clock edge.

Setup Time

Setup time is the minimum time data must be stable before the destination clock edge.

available time = clock period - setup time - clock uncertainty
required data path delay must be less than available time

If the data arrives too late, setup timing fails.

Hold Time

Hold time is the minimum time data must remain stable after the destination clock edge. Hold failures often involve paths that are too fast or clock skew problems.

title "Illustrative setup and hold window"
time start=0 end=10 unit=ns divisions=10

CLK: square label="destination clock" low=0 high=1 duty=50 cycles=1 unit=logic color=#2563eb
D_OK: step label="data stable before edge" low=0 high=1 at=3 unit=logic color=#16a34a
D_LATE: step label="late data would violate setup" low=0 high=1 at=4.8 unit=logic color=#dc2626

marker SETUP at=4.5 label="setup window"
marker EDGE at=5 label="capture edge"
marker HOLD at=5.5 label="hold window"

This waveform is explanatory; the timing report gives device-specific numbers.

Slack

Slack tells you margin.

Example:

required arrival: 10.000 ns
actual arrival:    8.700 ns
slack:             1.300 ns

The path passes with 1.3 ns margin.

Critical Path

The critical path is the path with the worst slack. It limits the maximum clock frequency. Common causes:

• too much combinational logic between registers;
• long routing distance;
• high-fanout control signals;
• unregistered module boundaries;
• wide arithmetic without pipelining.

Worked Example: Frequency from Slack

Suppose your design targets 100 MHz, so the period is 10 ns. A path has actual delay 12 ns.

slack = 10 ns - 12 ns = -2 ns

The design cannot safely run at 100 MHz. You can:

• reduce logic depth;
• pipeline the path;
• use dedicated carry/DSP resources;
• relax the clock only if the requirement allows;
• floorplan or adjust placement only after the RTL is sensible.

Common Mistakes

• Assuming simulation proves timing.
• Ignoring timing warnings because hardware “seems to work.”
• Forgetting to constrain generated clocks.
• Adding false paths without a real timing reason.
• Treating maximum frequency as a fixed property of HDL rather than implementation.

Summary

Static timing analysis proves whether registered paths meet clock requirements. Setup checks catch late data. Hold checks catch data changing too soon. Slack tells margin. Negative slack means the bitstream may behave unpredictably even if functional simulation passed.

Next: Clocks, Resets, and PLLs.

Further Reading

• Vendor timing analyzer user guides
• AMD UltraFast Design Methodology Guide
• Intel Timing Analyzer Cookbook
• FPGA design texts on synchronous timing

Mind Map