Methodology Checks and Signoff Criteria

Lesson 1 described a methodology as the set of rules that decide what is good enough and when a design may move forward. This lesson makes that concrete. It walks through the checks that a flow runs at each stage, lists the criteria a block must meet before it is signed off, and explains how exceptions to those criteria – waivers – are recorded and controlled.

The underlying idea is simple: a problem costs least to fix at the stage where it is introduced. An unconstrained path found after synthesis costs one line of SDC; the same path found after tape-out might cost a respin. The flow's job is to make sure each problem is found early.

Reading time: about 8 minutes.

9.1 Checks as stage gates

Let us consider the flow of lesson 2 with a gate at the end of every stage. A gate is a set of checks; the next stage starts only if they pass. In Makefile terms (lesson 4), the check is part of the recipe and its failure returns a non-zero status, so make stops. In CI terms (lesson 8), the same check can also be a gating job.

9.2 Checks on the inputs

Before synthesis, the checks look at what the designers wrote.

• RTL lint finds constructs that simulate one way and synthesise another, inferred latches, width mismatches, multiple drivers and similar problems. Lint tools apply a configurable rule set, and the project chooses which rules are errors.
• Clock domain crossing (CDC) analysis finds signals that pass between asynchronous clocks. At concept level, the tool identifies each crossing and checks that it uses a recognised synchronisation structure – for example a two-flop synchroniser for a single bit, or a handshake or asynchronous FIFO for a bus. An unsynchronised crossing can cause metastability failures that no static timing check will report, because the timing tool treats asynchronous clocks as unrelated.
• Constraint checks confirm that every clock is defined, IO delays exist on every port, and exceptions refer to objects that actually exist.
• Library checks, run when a library is installed (lesson 5), confirm that the views agree.

9.3 Checks after synthesis

After synthesis two families of checks are standard. Their names are similar across tools, though the exact options differ.

Design checks look at the netlist's structure: unresolved references (a module or cell that has no definition), unconnected inputs, outputs driving nothing, multiply driven nets, and combinational loops. In Synopsys tools and in Cadence Genus, the command is check_design.

Timing checks look at whether the design is fully constrained: registers with no clock, endpoints with no timing requirement (unconstrained endpoints), inputs without input delay, and timing loops. In Synopsys Design Compiler and PrimeTime the command is check_timing; Genus provides report_timing -lint; OpenSTA provides check_setup.

# OpenSTA / OpenROAD: report constraint problems before going further
check_setup -verbose

Why is this a gate rather than a report? An unconstrained endpoint has no slack, so it never appears in WNS or TNS. The QoR table of lesson 7 would look clean for a design in which part of the logic was never timed at all. Only an explicit check reveals it.

A further check at this point is logical equivalence checking (LEC): a formal tool proves that the synthesised netlist implements the same function as the RTL. It is repeated later between the RTL, or an earlier netlist, and the final netlist, because optimisation, scan insertion and ECOs all change the netlist.

9.4 Checks during implementation

In OpenROAD, for example, check_placement reports placement legality, and the detailed router reports remaining DRC violations; commercial tools have equivalent commands. The flow should parse these, as lesson 7 showed, and fail the stage when a limit is exceeded.

9.5 Signoff criteria

Signoff is the decision that a block is ready for tape-out. It is not a feeling; it is a checklist agreed at the start of the project, with a target for every item. The table shows the usual categories. The specific limits – which corners, what IR drop budget, what test coverage – are set by the project and the foundry, not by the flow.

Each row needs evidence that can be checked later: the report, the run directory it came from, and the versions it used (lesson 5). It is recommended that the flow collect these into one signoff summary per block, so that the review looks at a single document rather than at fifty log files.

9.6 Waivers and their governance

Occasionally a check reports a violation that is understood and accepted. A DRC error inside a third-party hard macro, for which the IP vendor has supplied a waiver, is a typical case; a lint warning on a deliberate coding construct is another. Such an accepted violation is recorded as a waiver.

A waiver is a risk decision, so it needs the same care as a design change. A minimal waiver record identifies exactly what is waived and why.

- id:        WV-0042
  check:     DRC
  rule:      M2.S.1                 # foundry rule name, as reported
  scope:     cell ip_pll_x1, instance u_pll only
  reason:    violation inside vendor PLL layout; vendor waiver ref. in record
  risk:      none expected per vendor; reviewed against current rule deck
  approved:  methodology lead, PD lead
  expires:   on any change to u_pll or the rule deck version

Several rules keep waivers under control.

• Narrow scope. A waiver names one rule and one object, never "all DRC in this region" or "all unconstrained endpoints". A wide waiver will eventually hide a real violation.
• Machine-matched. The flow applies waivers automatically by matching rule and object, and reports any waiver that no longer matches anything. An unused waiver might mean the problem was fixed – or that the object was renamed and the waiver is now hiding nothing while a new violation goes unseen.
• Version-controlled and reviewed. Waiver files live beside the design source in git (lesson 5), and every addition is reviewed by someone other than its author.
• Re-reviewed on change. A waiver is valid for a particular design and rule-deck version. When either changes, the waiver is reviewed again.

9.7 Interview questions

Why is an unconstrained endpoint dangerous even when WNS and TNS look clean? An unconstrained endpoint has no timing requirement, so it contributes nothing to WNS or TNS. The logic behind it is simply not timed; only a check such as check_timing or check_setup reports it.

What does check_design typically report? Structural netlist problems: unresolved references, unconnected or floating pins, multiply driven nets, outputs with no load, and combinational loops.

Name the main categories of signoff criteria. Timing (setup, hold, design rules, SI at all corners and modes), power integrity (IR drop and EM), physical (DRC, LVS, antenna, density), logical (LEC, CDC, low-power), and test (scan and coverage).

What should a waiver record contain? The check and rule, the exact object and scope, the reason, the risk assessment, the approvers, and the condition under which it expires or must be reviewed again.