Forty open bugs, two weeks to tape-out, one designer who can fix perhaps fifteen. The bug database lists them in the order they were filed, half marked "high" by whoever found them. Fixing the first fifteen on the list would be easy and would leave the router able to lose packets. Triage decides which fifteen.
How do you prioritise bugs?
The obvious orders are first come first served, or the finder's own severity label. Finders rate bugs by how hard they were to find or how alarming the waveform looked; neither measures what the bug does to a product. Triage needs a common scale and a few separate questions, answered by people who know the use cases.
Question | Levels (typical) | Why it matters |
|---|---|---|
Severity: what happens? | Critical (data corruption, hang, security) · Major (feature broken) · Minor (degraded) · Cosmetic | The consequence if it is met |
Likelihood: how often does real use meet it? | Common path · Specific configuration · Rare corner · Unreachable in supported use | Severity times likelihood is risk |
Detectability: does anyone notice? | Loud (crash, error flag) · Silent (wrong data, lost throughput) | Silent bugs are worse: they escape and corrupt |
Workaround: can it be avoided? | None · Software sequence · Configuration · Documentation | A good workaround lowers urgency |
Priority comes from all four together, decided in a regular triage meeting with design, verification, software and architecture, so the scale means the same thing for every bug.
Bug | Severity | Likelihood | Detectable? | Workaround | Priority |
|---|---|---|---|---|---|
BUG_2 FIFO count wrong on push and pop together | Critical: corruption | Common under streaming | Silent | None | Fix now |
BUG_24 back-to-back packet misrouted | Critical: misrouting | Common | Silent | Insert gaps (costly) | Fix now |
BUG_20 sleeps mid-packet | Critical: corruption | Needs idle mid-packet | Silent | Disable low power | Fix now or workaround |
BUG_5 round-robin stuck | Major: starvation | Under contention | Silent (only latency) | None | Fix now |
BUG_13 no out_err for high priority | Major: errors unreported | Bad CRCs on high priority | Silent | None | Fix |
BUG_19 one clear clears all | Minor: statistics lost | When software clears | Visible in statistics | Read all before clearing | Workaround and erratum |
BUG_18 no pslverr for unmapped | Minor | Only buggy software | Silent | None needed in correct software | Fix if cheap |
The two most dangerous properties appear together in the top rows: high severity and silent. A loud bug finds itself; a silent one ships.
One scale, applied in triage, not by the finder alone.
Duplicates merged, root causes linked: ten failures can be one bug (lesson 13.5).
"Not a bug" and "won't fix" recorded with reasons, reviewed at sign-off.
Bugs in the testbench tracked too: they cost time and hide design bugs (lesson 13.6).
Re-triage when facts change: a new use case can turn a minor bug critical.
Practice | Purpose |
|---|---|
Regular cross-functional triage meetings | Consistent priorities, informed by use cases |
Severity definitions written down | Labels comparable across finders and projects |
Open bugs by severity in sign-off criteria (lesson 14.2) | No critical bug left open without a decision |
A team (illustrative) let finders set severity. Assertion failures were usually filed as critical because they halted the regression; a silent throughput bug found by a performance monitor was filed as minor because "everything still passes". At tape-out the critical list was mostly fixed testbench noise, and the throughput bug, the one customers would have measured, was still open.
BUG_2 silently corrupts packet data on a common path with no workaround; BUG_19 loses statistics only when software clears counters and has a simple software workaround.
Finders judge by how alarming the failure looked or how hard it was to find; severity depends on use cases and consequences that triage brings together.
Triage each bug by severity, likelihood, detectability and workaround.
Silent, high-severity bugs on common paths come first.
Use one written scale in a cross-functional meeting; record every decision for sign-off.