Seven of the eight findings are already disposed of: three fixed in RTL, four accepted with reasons. One remains — the threshold capture F4 — and it is the only finding in this capstone that may be waived rather than fixed. This lesson writes that waiver completely, walks the three-owner review checklist, reads the dashboard honestly, and states signoff in words a reviewer can check. The waiver template it follows is the course's standard one from the evidence lesson.
F4 is waivable for exactly one reason: the threshold is quasi-static by construction. The configuration domain accepts a write only while the engine is fully stopped, the run request cannot start until two quiet cycles after the last write, and the engine copies the threshold once per run at start and ignores writes while running — so the engine-side capture eng_thresh <= cfg_thresh_q never samples a changing value, whatever software does. That argument, plus the proof behind it, is the whole waiver:
Field | This waiver |
|---|---|
Finding reference | F4, |
Reason (protocol argument) | Quasi-static by construction: writes are accepted only while the engine is stopped (run request low and its synchronised acknowledge low), the run request waits two quiet cycles after a write, and the single capture per run happens at start, so the capture samples a value that has been stable for at least two configuration periods |
Evidence | Stability assertion (the threshold must not change while the engine runs, re-checked every regression; the runnable form is the capstone testbench monitor) plus the testbench's directed case: a write attempted while the engine runs is ignored and the threshold is unchanged |
Constraint reference | No timing exception is needed beyond the asynchronous clock relationship already recorded in the intent file: the threshold path is covered by the same asynchronous clock group, and the stability is carried by the run handshake and the assertion, not by a false path (intent file reference: clock relationship cpu/engine, revision D) |
Owner | Integration owner, jointly approved with the signoff owner |
Condition that invalidates it | Any RTL change to the threshold path or the run handshake, any change that lets the threshold be written while the engine runs, or any clocking change to either domain — whichever comes first re-opens F4 |
Notice what is not in the table: no promise about typical software behaviour, no reference to passing runs alone, no scope wider than this instance at this revision. The waiver policy admits quasi-static crossings and nothing else from this report — F1 to F3 describe live signals and could never have been argued this way.
The gate reads three checklists aloud — design, verification, signoff — with the evidence on screen, following the review checklists lesson. Each row below shows the capstone's answer and where the proof lives:
Owner | Check | Capstone answer |
|---|---|---|
Design | Every crossing has its intended structure; no logic before the first flop | Toggle, Gray, and two reset synchronisers confirmed against the fixed listing; threshold capture recorded as intended-direct with its waiver |
Design | Protocols match the data type | Pulse carried as toggle with 160 ns spacing against a 54 ns rule; monotonic counter carried as Gray; quasi-static threshold qualified in writing |
Verification | Protocol assertions written and passing | One-pulse-per-toggle, spacing, threshold-stability, and reset-release assertions in the regression list |
Verification | Dynamic checks cover the crossings | Capstone testbench green: reset-zero, no-torn-status, every launched event delivered, a write ignored while running — plus a deliberate spacing-violation run proving the check has teeth |
Signoff | Setup reviewed; every finding fixed or waived with evidence | Clocks, asynchronous relationship, and reset intent reviewed; 3 fixed, 1 waived with the full template, 4 accepted with reasons |
Signoff | Handoff package complete | Synchroniser inventory with keep attributes (answers F8) handed to implementation; test-only tap F7 noted for the test-mode statement |
Counts below are illustrative: a small project reads its dashboard the same way a large one does, by class and by status, never as a single percentage. Fixed and waived stay separate series — a waiver is accepted risk, not progress — following the tracking lesson. The arithmetic is the check: 3 fixed plus 1 waived plus 4 accepted accounts for all 8 findings, leaving 0 open.
Class | Before (revision C) | After (revision D) |
|---|---|---|
Defect-class findings open | 3 (F1, F2, F3) | 0 (all fixed in RTL) |
Waiver-candidate findings open | 1 (F4, unevidenced) | 0 (1 approved waiver, current revision) |
Informational / accepted | 4 (F5–F8, unreviewed) | 4 (accepted with reasons, owners recorded) |
Total findings accounted for | 8 | 8 (3 fixed + 1 waived + 4 accepted) |
Open items | 4 | 0 |
Peripheral peri_top, revision D, is signed off for CDC and RDC under the stated setup (100 MHz engine, ~37 MHz configuration, asynchronous relationship, single asynchronous reset input): every structural finding is fixed or carries a jointly approved waiver; the one waiver is evidenced, scoped to this revision, and names its invalidating condition; the clock, reset, and spacing assumptions are reviewed; and the protocol assertions plus the self-checking testbench run green at this revision. Any RTL, constraint, clocking, or software-protocol change re-opens the affected rows before the next gate. That is what “closed” means here — checkable by anyone, in about an hour, from the records above.
Because every verdict depends on it: the spacing proof needs both periods, the Gray proof needs the monotonic source, the waiver needs the configuration discipline. A signoff without its setup is a conclusion without its premises — unverifiable and untransferable.
No. The fourth readiness condition — dynamic checks run at this revision — is unmet, and it guards exactly the toggle fix. The statement must read “closed except the spacing proof”, with an owner and a date, until the assertion runs green.
Five questions this capstone prepares you for. The course's interview-prep section teaches how to answer them under pressure — framework first, numbers second, verdict last:
Interviewer question | The strong answer, in one line — revise in |
|---|---|
Why does the first version lose events? | A one-cycle engine pulse can sit between two 27 ns configuration edges and vanish; the toggle turns it into a level that waits to be sampled — Toggle Synchronizer |
Each status bit was synchronised — why is the word still wrong? | The bits resolve independently, so the word can mix old and new bits; Gray changes one bit per step so any sample is genuine — Bus Tearing |
What breaks when reset releases straight from the asynchronous input? | Recovery and removal failures plus partial release across the domain; release must be synchronised per domain — Reset Synchroniser Structure |
Defend the threshold waiver in thirty seconds. | Quasi-static by construction: writes are only accepted while the engine is stopped and the capture happens once per run; the assertion and the directed testbench case prove it; changes to the path, the run handshake, or either clock invalidate it — When to Waive |
Zero open findings the day before tape-out — are we done? | Only if reconciliation, waiver completeness, reviewed setup, and green dynamic checks all hold at this revision; otherwise name the missing quarter — Signoff Readiness |
Extend it: expire your own waiver on purpose. Pick one invalidating condition — say, software now rewrites the threshold once a second — and write the replacement plan: does F4 become a fix (and which protocol: handshake, Gray-safe register, or qualified re-capture?), what new assertions does the fix need, and how does the dashboard move? File it as a defect with an owner and a date, the way a real ECO would.