Constraint Validation & Linting

Timing constraints — clocks, generated clocks, I/O delays, exceptions, OCV and MCMM setup

Constraint Validation & Linting

Writing constraints is only half the job. The other half is checking them. Constraints can be wrong in quiet ways. A missing clock leaves paths untimed. A typo in an object name silently disables nothing or, worse, disables a real path. A conflicting exception cancels a check you needed. These mistakes do not crash the tool. They just let the chip pass when it should not. Validation is the act of checking your constraints for completeness and correctness. Linting is the automated part of that check. SDC is the format the constraints live in. SDC is the timing constraint format that compliant tools read. We never expand the letters; we say SDC. This chapter lays out what to validate, how to find unconstrained endpoints, missing clocks, and conflicting exceptions, and a validation workflow you can follow as a routine.

A constraint file is code. Like any code it can have bugs. But timing bugs are sneaky. A normal software bug throws an error. A constraint bug often stays silent. The tool simply does less checking than you intended, and reports everything as fine. Consider a missing clock. A clock is the heartbeat that times paths. If you forget to create a clock on some source, every path driven by it is untimed. The tool sees no clock, so it has no period to check against. Those paths report no violations because they are never checked. The design looks clean. In silicon those paths may fail. Now consider a stray exception. An exception tells the tool to ignore or relax a path. A false path is one to ignore. If a false path is written too broadly, it can switch off real paths you needed timed. Again, no error. The check just disappears. Validation exists to catch these silent gaps before they reach the chip.

Finding Unconstrained Endpoints

An endpoint is where a path ends, usually a flip-flop data pin or an output port. A flip-flop is a one-bit memory updated by a clock. An unconstrained endpoint is one with no clock or no timing requirement. It is a hole in your coverage. The tool cannot check a path to an endpoint it has no timing for.

The first validation task is to find these holes. Most tools can report endpoints that have no clock reaching them. They can also report input and output ports with no delay set. An output port with no output delay has no requirement to meet. A path to it is effectively ignored. So you ask the tool to list every endpoint that lacks a constraint. The goal is full coverage. Every register should be clocked. Every input port should have an input delay. Every output port should have an output delay, unless you have a deliberate reason to leave it open. When the unconstrained list comes back empty, you know every path has something to check against.

# illustrative — names vary by tool
# list registers with no clock and ports with no delay
report_unconstrained_endpoints
report_ports -unconstrained

A worked example shows the payoff. A block has 1,284 registers. The check reports 7 with no clock. Those 7 sit behind a clock source you forgot to create. Without the check they would silently pass. After you create the missing clock, the report comes back clean, and all 1,284 are now timed. Seven hidden holes closed with one fix.

Finding Missing and Misdefined Clocks

Clocks are the foundation. If a clock is missing or wrong, everything built on it is wrong. So clock checks come early in validation. There are a few things to check. First, every clock source should have a clock. Walk the list of clock pins and confirm each one is named in a create_clock or a generated-clock definition. A generated clock is one derived from another clock, such as a divided clock. If a source has no definition, paths it drives are untimed. Second, clock periods and waveforms should be sane. A period of zero or a waveform with no high time is a sign of a typo. The duty cycle should match the real clock. Recall that the waveform sets halfcycle and latch timing, so a wrong waveform mistimes many paths quietly. Third, clock relationships should be intended. When two clocks interact, the tool times paths between them unless told otherwise. If two clocks are unrelated, you must say so, or the tool times a path that can never be met. Validation reviews which clock pairs are treated as related and confirms that matches the design.

# standard SDC — portable across compliant tools
# a clean clock with an explicit waveform leaves no ambiguity
create_clock -name ref_clk -period 7.13 -waveform {0 3.57} [get_ports ref_clk]

A worked example: a design has 9 clock sources. The check finds 8 with definitions and 1 without. The undefined one feeds a small status block. Those status registers were never timed. You add the missing create_clock , and the next run times them properly, revealing two real violations that had been hidden all along.

Finding Conflicting and Redundant Exceptions

Exceptions are powerful and easy to misuse. The main ones are false paths, multicycle paths, and min/max delays. A multicycle path is allowed more than one period. When exceptions overlap, they can conflict. Validation must untangle them. A conflict happens when two exceptions cover the same path with different intent. One says false path, another says multicycle. The tool must pick one. The priority rules decide, but the result may not be what you wanted. So you ask the tool to report exceptions that overlap, and you confirm the winner is correct. A redundant exception is one that does nothing. It points at a path that does not exist, or duplicates another. Redundancy is not dangerous, but it is clutter. It often hides a typo. A false path that matches no objects usually means a misspelled name. So the tool's report of ineffective exceptions is a great way to catch typos.

# illustrative — names vary by tool
# surface exceptions that overlap or match nothing
report_exceptions -overlapping
report_exceptions -ineffective

A worked example shows the trap. A false path is meant to cover one clock pair. A multicycle of 2 is also written on a path inside that same pair. The two overlap. The false path wins by priority, so the multicycle never applies. The designer thought the path got 2 cycles; really it was ignored. The overlap report exposes the clash, and the designer narrows the false path so both rules do what they meant.

A Validation Workflow and Checklist

Validation works best as a routine, run the same way every time. Here is a workflow in plain language, not a set of problems to solve, just steps to follow. Start with clocks, because everything rests on them. Confirm every clock source has a definition. Check each period and waveform for sanity. Review which clock pairs are treated as related and confirm that is intended. Fix any missing or wrong clock before moving on, since later checks depend on correct clocks. Next, check coverage. Ask the tool for unconstrained endpoints and undelayed ports. Every register should have a clock. Every input and output port should have a delay, unless deliberately left open. Resolve each item on the list until it is empty or every remaining entry is a known, justified exception. Then check exceptions. Report overlapping exceptions and confirm the winning rule is the one you wanted. Report ineffective exceptions and treat each as a possible typo. Report over-broad false paths and tighten any that catch more than intended. Each exception should do exactly one clear job. Finally, do a sanity review of the whole picture. Run a broad timing report and scan for paths with strange budgets, like a path that gets far more or less time than expected. An odd budget often points back to a clock or exception mistake. Re-run the full validation after any constraint change, because a fix in one place can open a hole in another.

A compact checklist, in prose, captures the routine. Are all clocks defined with sane periods and correct waveforms? Are clock relationships intended? Are all registers clocked? Do all input and output ports have delays, except where deliberately open? Do any exceptions overlap, and is the winner correct? Do any exceptions match nothing, hinting at a typo? Are any false paths broader than

intended? Does any path show a budget that does not make sense? Running through these questions every time turns validation from a one-off scramble into a dependable habit.

Interview Q&A

clock or a stray false path does not crash the tool; it just makes the tool check less than you intended. The design reports clean while real paths go unchecked, so the failure only shows up in silicon. Validation exists to surface these quiet gaps.

like a register data pin or an output port. An unconstrained one has no clock or no timing requirement, so paths to it are never checked. You find them by asking the tool to report registers with no clock and ports with no delay, then closing each gap.

that each period is non-zero and correct, and that the waveform's duty cycle matches the real clock. Review which clock pairs are treated as related and confirm that is intended. Wrong clocks mistime everything built on them, so these checks come first.

intent, such as a false path and a multicycle on the same path. The tool picks one by priority, and the result may not be what you wanted. You report overlapping exceptions and confirm the winning rule is the correct one.

so it does nothing. The most common cause is a typo in an object name. So a report of ineffective exceptions is a good way to catch misspelled names that would otherwise leave a path unconstrained or a rule unapplied.

on them. Then check coverage by finding unconstrained endpoints and undelayed ports. Then check exceptions for overlap, ineffectiveness, and over-broad scope. Finally do a sanity review of path budgets, and re-run the whole flow after any constraint change.

Key Takeaways

• Constraint bugs are usually silent, making the tool check less than intended while the design still reports clean, so validation catches the quiet gaps.
• Unconstrained endpoints are coverage holes; find every register with no clock and every port with no delay, then close them.
• Clock checks come first because a missing or misdefined clock mistimes everything built on it; confirm definitions, periods, waveforms, and relationships.
• Exceptions must be untangled: overlapping ones can cancel a needed check, and ineffective ones usually signal a typo in an object name.

• Run validation as a repeatable routine of clocks, coverage, exceptions, and a sanity review, and re-run it after every constraint change.