A structural run on the first version reports eight findings, and they are not equally important. Three describe defects that must be fixed, one describes a situation that can be accepted with written evidence, and four describe things that are fine as they are. Classification is the skill of telling those apart quickly and writing the verdict down so nobody re-argues it next week. Read the report below, decide each finding's fate yourself, and only then compare with the answer key.
Classify in severity order, not in report order. Errors first, because they block everything downstream; then warnings, because they split into fixes and waivers; then informational notes, which should each trace to an intended structure or leave the report as noise. Every verdict names an owner and a next action — fix with a date, waive with evidence, or accept with a reason. A verdict without an owner is a finding that will be open again at the next gate.
Severity | Default verdict | What changes the default |
|---|---|---|
Error | Fix the design | Almost nothing: an error describes an unsafe structure, and structures are only made safe by changing them |
Warning | Fix, or waive with evidence | A written protocol argument plus demonstration, joint approval, scope, and expiry (see the waiver lessons) |
Informational / low | Accept with a reason, or hand off | Only if the note points at a real downstream action, such as an implementation attribute |
The listing below is a fabricated, clearly illustrative generic structural report for peri_top at its first revision. It uses generic rule categories only — the way the course describes structural analysis throughout — and its severities are teaching labels, not tool output. Classify all eight findings before scrolling to the key.
illustrative generic structural report: peri_top, revision C
setup: clk_eng 100 MHz, clk_cfg ~37 MHz, asynchronous clocks, reset rst_n_async
F1 [error] pulse crossing without pulse qualifier
eng_event (clk_eng) -> ev_a/ev_b (clk_cfg): single-cycle pulse into a
plain two-flop synchroniser; event may be missed entirely.
F2 [error] multi-bit crossing without protocol
eng_count[3:0] (clk_eng) -> st_a/st_b (clk_cfg): per-bit synchronisers
with no Gray, handshake, or qualifier; torn samples possible.
F3 [error] asynchronous reset release
clk_cfg flops (ev_a, ev_b, st_a, st_b, cfg_thresh_q) release straight
from rst_n_async with no reset synchroniser; recovery/removal risk.
F4 [warning] unsynchronised capture without recorded qualifier
cfg_thresh_q[3:0] (clk_cfg) sampled by eng_thresh (clk_eng) with no
synchroniser and no attached stability argument.
F5 [info] reset synchroniser present, no violation
u_rst_eng: asynchronous assert, two-flop synchronous release in clk_eng.
F6 [info] synchroniser outputs have no shared downstream combine
ev_b and status_cfg feed disjoint enables; no reconvergence flagged.
F7 [info] test-only observation tap outside functional scope
scan observation of eng_count active in test mode only.
F8 [low] synchroniser identification for implementation
ev/st synchroniser flops carry no keep attribute for synthesis.The same three questions the methodology sections repeat: is every error owned by a fix, does every warning end in either a fix or a waiver with the full evidence template, and does every informational note trace to something intended rather than something unexamined? Notice what the report does not contain: no reconvergence finding (F6 confirms the negative) and no complaint about u_rst_eng (F5 confirms the one correct structure). Confirming the negatives matters — it tells the reviewer the analysis actually saw the design rather than pattern-matching blindly.
F1 and F2 carry live, changing signals — a pulse and a free-running counter — so no argument can make the capture safe without changing the structure. F4 carries a value that is stable while it is sampled, so a stability argument with proof can make the acceptance safe without changing the structure.
They record that the analysis examined those structures and found them sound — the reset synchroniser exists, the synchroniser outputs do not reconverge. At the gate, confirmed negatives are evidence too: they show coverage rather than silence.
Compare your verdicts with the key below. Each row gives the verdict, the one-line reason, and the owner who carries the next action into the fix lesson or the waiver.
Finding | Verdict | Reason | Owner |
|---|---|---|---|
F1: pulse without qualifier | Fix | A one-cycle engine pulse into a 27 ns destination can fall between edges; only a pulse scheme (toggle, stretch, handshake) survives the phase | Engine owner |
F2: multi-bit without protocol | Fix | Four independent synchronisers resolve independently, so the sampled word can mix old and new bits — a torn value the design never produced | Engine owner |
F3: asynchronous reset release | Fix | Release straight from the asynchronous input risks recovery and removal failures and partial release across the domain | Reset owner |
F4: threshold capture | Waive with evidence | Quasi-static by construction (made true by a run handshake in the fix lesson): needs the written protocol argument, assertion or simulation proof, constraint reference, and owner with expiry — written in the signoff lesson | Integration owner |
F5: reset synchroniser sound | Accept | Asynchronous assert with two-flop synchronous release is exactly the required structure; recorded as a confirmed negative | Reset owner |
F6: no reconvergence | Accept | Disjoint enables with no shared combine; recorded so the gate can see the check ran | Engine owner |
F7: test-only tap | Accept out of scope | Functional analysis does not cover test mode; needs its own test-mode statement, not a functional fix | DFT contact |
F8: keep attribute missing | Accept with handoff action | Not an RTL defect; the synchroniser inventory handed to implementation must mark these flops untouchable | Implementation owner |
Three fixes, one waiver, four acceptances: that is the whole report disposed of, with nothing waived to go green and nothing silently dropped. The fixes land in the next lesson; the waiver is written in full in the signoff lesson.
Extend it: change one assumption — the threshold is now rewritten by software once a second while the engine runs — and reclassify F4. Write down which verdict changes, what new evidence or fix the new verdict needs, and which owner picks it up. This is the expiry drill: a design change re-opens a settled finding.