Scan Design-Rule Checking (DRC)

Chapter 4 · Section 4.3 · Scan Insertion & DRC

Project thread — with the chains stitched (4.2), scan DRC gates the design before ATPG. 4.5 runs DRC on the FSM and fixes a violation before generating patterns.

1. Why Should I Learn This?

Scan DRC is the gate that decides whether ATPG's patterns will be valid — pass it and coverage is trustworthy; ignore it and coverage is fiction.

• Scan DRC verifies scannability on the scan-inserted netlist, before ATPG.
• Rules: controllable clocks, inactive async resets, latches, no loops, no bus contention, chain integrity.
• Each violation → a downstream failure: can't clock, corrupted capture, X, wrong golden response.
• ATPG trusts the DRC-clean model — so DRC must pass (or be knowingly handled) before patterns.

2. Real Silicon Story — the waived DRC that poisoned the patterns

Under schedule pressure, a team hit a scan DRC violation — an uncontrolled clock on one block — and, to 'keep moving,' waived it without fixing the root cause. ATPG ran, reported high coverage, and everyone moved on.

On silicon, that block's patterns failed en masse with golden mismatches. The reason: because the clock was uncontrolled, ATPG's model of how that logic captures was wrong, so the golden responses it computed didn't match what the silicon actually did — the 'high coverage' was computed against a fictional capture behavior. The patterns weren't detecting faults; they were comparing silicon to a wrong answer.

The fix was to make the clock controllable (test-controllable gating / OCC — 4.4), re-run DRC clean, and regenerate patterns against the correct model. Lesson: ATPG trusts the DRC-clean model absolutely — a waived/uncleared DRC violation doesn't just lose a little coverage, it can make the tool compute wrong golden responses and produce patterns that don't match silicon. DRC must be clean (or violations genuinely handled) before you trust any coverage.

3. Factory Perspective — scan DRC through each lens

• What the test engineer sees: the DRC report as the go/no-go gate — patterns aren't trustworthy until DRC is clean (or violations knowingly handled).
• What the yield engineer sees: that golden-mismatch fails from a bad DRC model look like a yield/defect problem but are a model problem — rule it out before blaming silicon.
• What the RTL/DV engineer sees: that DRC violations trace to their clocks/resets/latches (4.1/4.4) — the root-cause fix is in RTL, not a tool setting.
• What management cares about: that waiving DRC to save time can poison patterns and cause silicon re-tests / respins — a false economy with a direct DPPM/schedule risk (1.5).

4. Concept — the rules, the report, and why the gate is absolute

Scan DRC checks (on the scan-inserted gate netlist):

• Clock rules: every scan cell's clock is controllable at capture; no uncontrolled/gated clocks; clock reaches the cell; no clock-as-data / data-as-clock hazards. Violation → can't shift/capture → untestable or wrong golden.
• Async set/reset rules: async set/reset is inactive and controllable during shift and capture. Violation → reset fires → corrupts state/capture.
• Latch rules: latches are transparent/controllable in test. Violation → uncontrollable state / X.
• Combinational-loop rules: no uncontrolled feedback loops. Violation → un-analyzable / X.
• Bus/tristate rules: no contention/float in test. Violation → X / contention.
• Scan-chain trace/integrity: the chain traces and shifts correctly (the tool's model of the 3.3 flush).

The DRC report:

• Classifies each violation with a code and location, and marks the design DRC-clean or not.
• Each entry is a specific downstream risk, not a cosmetic warning.

Why the gate is absolute — ATPG trusts the DRC model:

• ATPG's pattern generation and its golden-response computation assume the netlist obeys the DRC (controllable clocks, inactive resets, no X sources).
• If a violation stands, ATPG may fail, or — far more dangerous — silently compute the wrong golden response (or one full of X), producing patterns that mismatch silicon → lost coverage or false fails (the story).
• Therefore DRC must pass, or each violation must be explicitly understood and handled/waived with knowledge of its consequence — never blindly.

DRC (this lesson) vs DFT lint (4.1):

• DFT lint: RTL-level, early, advisory — catches scan-hostility cheaply (shift-left).
• Scan DRC: gate-netlist, in the ATPG tool, the hard gate — patterns depend on it.

Each violation class has a concrete downstream consequence:

5. Mental Model — a pre-flight checklist before takeoff

Scan DRC is the pilot's pre-flight checklist — run before the flight (ATPG), because in the air it's too late.

• Each item — controls free (clocks controllable), brakes released (resets inactive), instruments reading true (no X), doors sealed (no bus float) — maps to a specific catastrophe if skipped.
• The flight plan (ATPG patterns and golden responses) is computed assuming the checklist passed — if a control was actually stuck (a violation), the plan is based on a false picture of the aircraft, and you'll discover it dangerously, in flight (golden mismatches on silicon).
• Waiving an item to save time is exactly the wrong instinct — a checklist item exists because skipping it has bitten someone. You either fix it or knowingly, formally accept a specific, understood risk — never ignore it.

Run the checklist to clean before you build the flight plan; ATPG trusts the checklist absolutely.

6. Working Example — a DRC report and its consequences

Read a representative DRC report and what each violation would cause:

# Scan DRC report — REPRESENTATIVE, SIMPLIFIED, tool-neutral (run on the scan-inserted netlist, PRE-ATPG):
  RULE  CLOCK_CONTROL   VIOLATION  U_pll/clk_div : clock not controllable at capture
        -> ATPG can't deterministically capture these flops -> untestable OR wrong golden  [FIX: OCC / test clock, 4.4]
  RULE  ASYNC_RESET     VIOLATION  U_ctl/arst_n  : async reset active during scan
        -> reset can fire in shift/capture -> corrupts state -> bad patterns              [FIX: gate reset in test, 4.4]
  RULE  LATCH_TRANSP    VIOLATION  U_dp/q_lat    : latch not transparent/controllable in test
        -> uncontrollable state / X source                                               [FIX: flop or test-transparent, 4.4]
  RULE  BUS_CONTENTION  PASS
  RULE  COMB_LOOP       PASS
  RULE  CHAIN_TRACE     PASS       (3 chains traced, integrity model OK)
  STATUS: DRC NOT CLEAN (3 violations) -> DO NOT trust ATPG coverage until fixed or knowingly handled.

# Why a violation poisons ATPG — REPRESENTATIVE:
  ATPG computes the GOLDEN (good-machine) response ASSUMING the DRC model (controllable clock, inactive reset, no X).
  If the clock is actually UNCONTROLLED, the real capture differs from ATPG's model
   -> ATPG's golden response is WRONG -> silicon (correct) mismatches golden -> mass 'fails' that are NOT defects.
  -> Coverage reported against a wrong model is FICTION. Fix DRC, re-run, THEN trust coverage.

7. Industry Flow — DRC gates insertion from ATPG

Scan DRC sits exactly between scan insertion and ATPG, as a hard gate:

8. Debugging Session — high coverage in the tool, mass fails on silicon

9. Common Mistakes

• Waiving DRC to save time. A violation means ATPG's model is wrong → wrong golden / mass fails — fix it.
• Trusting coverage on a violated model. Coverage scored against wrong golden responses is fiction.
• Confusing chain integrity with DRC-clean. Integrity (3.3) checks shift; DRC also checks capture/clock/reset/X.
• Treating DRC as cosmetic warnings. Each violation is a specific downstream failure, not a lint nit.
• Fixing DRC only in the tool. Root causes live in RTL/clocking (4.1/4.4) — fix them there.

10. Industry Best Practices

• Make scan DRC a hard gate — no ATPG on a not-clean netlist.
• Root-cause violations in RTL/test-mode (4.1/4.4), not tool waivers.
• Handle unavoidable violations explicitly (e.g. masking) with a known coverage cost — never blindly.
• Re-run DRC after any netlist/clocking change — it's cheap insurance against wrong golden responses.
• Distinguish DRC-clean from chain-integrity — you need both.

11. Senior Engineer Thinking

• Beginner: "DRC has a violation but coverage looks fine — waive it and move on."
• Senior: "A DRC violation says ATPG's model is wrong — so the golden responses it computes are wrong, and 'high coverage' is fiction that will mass-fail on silicon. I root-cause the uncontrolled clock/reset (4.4), get DRC clean, and regenerate patterns. I never blindly waive — I either fix it or handle it explicitly with a known cost."

The senior treats DRC as a statement about model validity, not a nuisance — clean it before trusting coverage.

12. Silicon Impact

Scan DRC is the integrity gate of the whole structural-test flow, and misunderstanding it produces some of the most expensive, confusing failures in DFT. Its job is to guarantee the netlist actually behaves the way ATPG will assume it behaves — controllable clocks, inactive resets, no X sources, working chains — because ATPG computes every pattern's golden response by simulating that assumed model. That makes the gate absolute: a violation isn't a lost fault or two — it can invalidate the golden responses for an entire block, so the tool reports high coverage while silicon mass-fails on golden mismatches that are not defects at all (the story). The most dangerous move in the flow is blindly waiving a DRC violation to save schedule — it converts a known, fixable problem into poisoned patterns and silicon re-tests or respins, a spectacular false economy with a direct DPPM/schedule hit (1.5). The right discipline is to root-cause violations back to RTL/clocking (4.1/4.4) — an uncontrollable clock, an active async reset, a latch, a loop, bus contention — clean DRC, and only then trust coverage; any violation that genuinely must remain is handled explicitly (e.g. masking) with a known cost. For the RTL/DV engineer, the message is that DRC violations are your design's clock/reset/latch issues surfacing, and clearing them early (via DFT lint, 4.1) keeps this hard gate uneventful — which is exactly what 4.5's FSM insertion aims for: DRC clean before ATPG.

13. Engineering Checklist

• Ran scan DRC on the scan-inserted netlist before ATPG.
• Achieved DRC clean (or explicitly handled each remaining violation with a known cost).
• Root-caused violations in RTL/test-mode (clocks/resets/latches — 4.1/4.4), not tool waivers.
• Confirmed both DRC-clean and chain integrity (3.3).
• Re-ran DRC after any netlist/clocking change before trusting new coverage.

14. Try Yourself

1. List the scan DRC categories (clock, async reset, latch, comb loop, bus, chain trace) and one violation each.
2. For an uncontrolled clock violation, explain how ATPG's golden response becomes wrong.
3. Read a small DRC report: which entries would cause mass golden mismatches on silicon?
4. Contrast chain integrity (3.3) with DRC-clean — why you need both.
5. Argue why blindly waiving a DRC violation is dangerous, and what explicit handling (e.g. masking) means.

Reasoning is tool-neutral. Real DRC runs in the ATPG/scan tool on the gate netlist; fixes are in RTL/test-mode (4.4). No paid tool required to reason about the gate.

15. Interview Perspective

• Weak: "Scan DRC checks that the design can be scanned."
• Good: "It checks controllable clocks, inactive resets, no latches/loops/X, and chain integrity before ATPG."
• Senior: "Scan DRC is the hard gate the ATPG tool runs on the scan-inserted netlist to verify scannability before generating patterns — controllable clocks at capture, async resets inactive in scan, latches transparent, no combinational loops or bus contention (X sources), and chain trace/integrity. The reason it's absolute is that ATPG computes golden responses assuming the DRC-clean model — so a standing violation (say an uncontrolled clock) makes ATPG's golden responses wrong, and silicon mass-mismatches them: 'high coverage' that's fiction and fails on the tester. So I root-cause violations in RTL/test-mode (4.4), get DRC clean, and regenerate — I never blindly waive, because a waived violation poisons the patterns."

16. Interview / Review Questions

17. Key Takeaways

• Scan DRC is the checks the ATPG/scan tool runs on the scan-inserted netlist to verify scannability — the hard gate before ATPG.
• Rules cover controllable clocks (at capture), inactive async resets (in shift/capture), transparent/controllable latches, no combinational loops, no bus contention, and chain trace/integrity — and each violation maps to a specific downstream failure.
• ATPG trusts the DRC-clean model to compute golden responses, so a standing violation makes ATPG build patterns on a wrong model → wrong golden / X / lost coverage / mass false fails on silicon; reported coverage becomes fiction.
• Therefore scan DRC must be clean (or each violation explicitly, knowingly handled — e.g. masking, with a known cost) before trusting coverage — blindly waiving a violation is one of the most dangerous moves in the flow.
• Root-cause violations in RTL/test-mode (clocks/resets/latches — 4.1/4.4), and note DRC-clean ≠ chain-integrity — you need both. Next: 4.4 — uncontrolled clocks, resets & latches (the fixes).

18. Quick Revision

Scan DRC — the hard gate before ATPG. The ATPG/scan tool checks the scan-inserted netlist for scannability: controllable clocks (at capture), async resets inactive in scan, latches transparent/controllable, no comb loops, no bus contention, chain trace/integrity. Each violation = a specific downstream failure. ATPG TRUSTS the DRC-clean model to compute golden responses → a standing/waived violation → wrong golden / X / mass false fails on silicon → coverage is fiction. So DRC must be clean (or explicitly handled, e.g. masking) before trusting coverage; never blindly waive. Root-cause in RTL/test-mode (4.1/4.4). DRC-clean ≠ chain-integrity (need both). Next: 4.4 — uncontrolled clocks, resets & latches.