Detecting Redundant or Missing Isolation: Expanded Case Study

Extended case study

A regression tied to Detecting Redundant or Missing Isolation appears after power-intent or PMU sequence updates.

Background

Previous baseline was stable. New low-power behavior improved one mode but introduced unstable corner behavior in transition-heavy tests.

Symptoms observed

• Missing-isolation high-severity findings and redundant-cell area/timing overhead eliminated before low-power signoff freeze. worsens under stressed transition sequences

• same testcase can pass in functional mode but fail in power-aware mode

• teams disagree whether issue is intent, RTL, firmware, or checker noise

Investigation timeline

1. Hour 0: freeze test seed, intent revision, RTL commit, and PMU configuration tags.

2. Hour 1: collect transition timeline and assertion failures around first symptom.

3. Hour 2: classify failure mode and narrow candidate boundaries.

4. Hour 3: create smallest reproducer with explicit phase and crossing visibility.

5. Hour 4: apply one reversible fix and rerun focused LPV tests.

6. Hour 5: run broader regression subset for blast-radius confidence.

7. Hour 6: publish closure packet and update guardrail checks.

Root cause

Root cause traced to Detecting Redundant or Missing Isolation: Missing isolation is dangerous because it permits unknowns or unsafe logic levels to leak into live domains, but redundant isolation is also costly: extra cells increase area, delay, dynamic power, and debug complexity.

Fix and validation

• audit crossings against intent and actual placement

• add crossing-specific assertions for OFF windows

• prove no redundant clamps degrade functional paths

Lessons learned

• Treat low-power boundaries as protocol contracts, not optional hints.

• Prefer bounded fixes over multi-axis edits during triage.

• Convert each escaped bug class into a lasting guardrail.

CASE STUDY - Detecting Redundant or Missing Isolation
escape risk / debug latency / closure confidence trend

Low-power verification deep dive

Boundary correctness depends on timing: isolate and shift at the right crossings and right phases.

Concept diagram

BOUNDARY SAFETY VIEW

domain crossing -> level-shift requirement -> isolation control -> OFF/ON transition behavior

Metric graph

BOUNDARY BUG CLASSES

missing isolation      █████
late isolation         ████
LS misdirection        ███

Metrics and artifacts to collect

• cross-domain boundary inventory

• clamp-value correctness report

• LS direction and threshold checks

• missing or redundant boundary action list

Mini case study

A boundary bug escaped unit tests until domain-off traffic stress revealed late isolation enable timing.

Debug branches

• Map each crossing to expected LS and isolation behavior.

• Verify enable timing against collapse and restore edges.

• Check clamp safety for protocol-facing signals.

Senior review question

Ask: what exact low-power transition boundary failed first, and which artifact proves the closure claim reproducibly?

Key takeaways

• Tie each LPV claim to a concrete transition boundary and one proving artifact.

• Prefer minimal reversible fixes with explicit owner and rollback criteria.

Common pitfalls

• Treating power-aware failures as random before boundary classification.

• Waiving X-prop failures before proving impact and root cause.

• Declaring closure without deterministic replay across key modes.

Principal LPV review addendum

Detecting Redundant or Missing Isolation should be reviewed as a transition integrity system, not just isolated checks.

Use Missing-isolation high-severity findings and redundant-cell area/timing overhead eliminated before low-power signoff freeze. as alarm and Risk-ranked crossing ledger showing missing, justified-exempt, and redundant isolation candidates with closure action and waiver evidence. as proof.

Isolation and level-shifting quality is measured at crossing correctness, clamp safety, and timing of control intent. Closure quality comes from reproducible evidence and explicit owners.