DFT Whiteboard Framework: Software / Programmer View

RTL / integration view

Explain RTL implications in every DFT tradeoff answer.

What teams feel

• Unexpected untestables

• clock/reset test-mode conflicts

RTL structure impact

• Scan hooks

• mode controls

• debug access gating

Tool interaction

• Synthesis transforms affecting scan paths

• clock-gating interaction

Mitigations

• DFT lint gates

• test-aware coding standards

• joint RTL/DFT reviews

RTL VIEW - DFT Whiteboard Framework
// mode logic changed -> recheck controllability and constraints

Layer touch points

DFT OWNERSHIP LAYERS - DFT Whiteboard Framework

layer              owns                         failure mode
----------------   --------------------------   -------------------------
rtl/architecture   scanability hooks            uncontrollable logic
atpg/constraints   legal pattern intent         aborts, low coverage
physical/clocking  chain route + test clocks    shift hold/timing escapes
tester/program     pattern apply integrity      false binning / bad fails
quality signoff    release criteria             escapes or schedule slip

DFT deep dive

Senior DFT interviews test tradeoff judgment under imperfect data.

Concept diagram

INTERVIEW ANSWER LOOP

state metric -> explain mechanism -> request evidence -> propose fix -> list regression

Metric graph

ANSWER QUALITY

mechanism clarity + ownership clarity + regression discipline

Reports and artifacts

• whiteboard rubric

• scenario scorecard

• trap checklist

• follow-up depth index

Mini case study

Candidate improved from tool-only answers to mechanism-first narratives by using metric->artifact->decision template.

Debug branches

• Always state assumptions

• Name cross-team owners

• Discuss risk and fallback plan

Senior review question

Ask: what evidence proves this DFT decision is safe for production?

Key takeaways

• State metric, lot/corner context, and pattern tag with every claim.

• Treat timing, power, and quality as one signoff problem.

Common pitfalls

• Chasing coverage without legality checks.

• Ignoring test-power side effects of pattern changes.

• Debugging silicon without reproducible tags.

Principal DFT review addendum

Strong DFT interviews follow a repeatable chain: architecture intent, controllability/observability, constraints, quality metrics, and debug loop.

Metric: interview answer structure quality, mechanism clarity, tradeoff articulation