Timing Constraints 101: From create_clock to false path

1. Why You Must Write Constraints

Tools “don’t know” your clock by default — without constraints, timing analysis has no reference and reports are meaningless. Constraints tell the tool: which signals are clocks, their frequency, and when data is valid, so the tool can optimize and report real timing margins.

2. Four Core Commands

• create_clock: define the primary clock (port/pin), specify period and waveform;
• create_generated_clock: describe clocks after MMCM/PLL division/multiplication so the tool understands phase relationships;
• set_input_delay / set_output_delay: tell the tool the arrival/output timing windows of interface data — key to external timing (ADC/DDR) correctness;
• set_false_path / set_multicycle_path: declare paths that need no timing analysis (async signals, static config) or paths spanning multiple cycles, to avoid false violations and over-optimization.

3. Reading Timing Reports

Focus on three values: WNS (worst negative slack — the globally tightest path), TNS (total negative slack — path count), WHS (hold slack). Fix order: WNS first, then TNS; timing before area.

4. Two High-Frequency Pitfalls

1° Missing constraints: intermittent board errors with all-green simulation — 80% of the time it’s missing interface constraints; 2° Ungrouped clock domains: clocks of different frequencies should be separated into clock groups, otherwise the tool reports a flood of false violations.