Card A — Definitions that make transients testable

• Load profile Document Iavg, Ipk, di/dt, and burst envelope Ton/Toff (duty + repetition).
• Droop The worst-case dip from Vnom to Vmin during an event. Specify a maximum: ΔVdroop ≤ ΔVmax.
• Recovery Time to return into an allowed band (e.g., ±x%) after the dip: trec ≤ Tmax.
• PG threshold A rail only “fails” when voltage crosses a defined threshold under defined timing rules.
• Blanking A short window after enable/mode switch where PG/UV is intentionally ignored.
• Debounce A condition must persist for a minimum time before it is treated as a fault.

Card B — Back-calculating PoL direction from the load event

• High di/dt (sharp edges): prioritize tight local high-frequency decoupling and short current loops; consider architectures with stronger transient response.
• Long Ton (wide pulses): bulk energy and thermal rise dominate; confirm droop over the full pulse width, not only the first microseconds.
• Tight ΔVmax (small droop allowed): routing IR drop and measurement point definition become critical; remote sense may be required.
• Frequent “intermittent” trips: first verify PG blanking/debounce vs the measured transient waveform before redesigning hardware.
• Multi-rail coupling: a large rail droop can pull shared nodes and cause secondary rails to violate thresholds; specify event timing per rail priority.

Local decoupling has two roles: high-frequency capacitors support the initial edge (ESL/ESR-limited), while bulk capacitance supports longer Ton energy. Control-loop recovery primarily governs the tail back into spec.

Card C — Symptom mapping (what readers see vs what to check)

• Reset or brownout only during bursts: check Vmin at the true load node, confirm ΔVdroop and trec, then align PG threshold/blanking to the event window.
• Alarm storm with “good-looking” bench voltage: verify probe point and bandwidth; confirm debounce and sampling strategy are not converting short dips into persistent faults.
• Performance drift without obvious faults: verify bias/drive rails under temperature and duty changes; confirm the rail does not sag inside a “pass” PG window.

Compare — Centralized vs distributed PoLs (rail-delivery view)

• Centralized Fewer converters and easier service access, but long delivery paths can add IR drop and enlarge current loops.
• Distributed PoLs placed near loads reduce delivery impedance and improve effective transient performance at the load node.
• Multiphase reduces per-phase stress, spreads heat, and can improve transient response; phase interleaving also reduces bus ripple current.
• Limit: multiphase does not fix incorrect measurement points, PG policy mismatch, or long-line IR drop without proper sensing.

Selection criteria — When remote sense / Kelvin is worth it

• Long trace + high current: delivery IR drop is non-negligible relative to tolerance or droop budget.
• Tight rail accuracy: the rail must be regulated where it matters (the load node), not at the converter pins.
• PG/UV decisions must reflect the load node: false trips happen when PG monitors a “good” point while the load droops.
• Intermittent burst failures: remote sense helps separate “converter performance” from “delivery impedance” root causes.

Remote sense must be treated as a controlled measurement loop (clean Kelvin routing, defined sense point, and stable compensation). It is a precision tool, not a universal default.

Card A — The sequencing toolkit (what each piece controls)

• EN chain Defines who is allowed to start and under which entry conditions (input OK, monitoring rails OK, timers OK).
• PG cascade Defines when a rail is stable and how that stability gates the next rail or the RUN state.
• Soft-start / inrush Shapes ramp energy to avoid input sag and cross-rail coupling that causes “intermittent” failures.

Card B — Sequencing checklist (order, conditions, and fallback actions)

Intermittent boot failures typically come from a mismatch between real transient behavior and PG decision logic. Align blanking, debounce, and window thresholds to the measured droop/recovery defined in H2-3.

Card C — Engineering-grade PG rules (blanking, debounce, window, DAG)

• Blanking: ignore PG transitions during soft-start and during defined mode-switch windows.
• Debounce: require continuous violation for a minimum time before declaring PG fail.
• Window monitoring: treat a rail as valid only inside a defined range (UV + OV) after blanking.
• DAG dependencies: express gating as a dependency graph (no cycles). Example: RUN depends on {A rails OK} AND {core rails OK}.
• Fallback actions: define whether a violation triggers retry, foldback, or latch-off per rail priority.

Card A — Telemetry that supports decisions (not just numbers)

• Define the use Each channel must be tagged as display, protection, control, or trend.
• Align the node Measure where decisions are made (load node for droop/PG, power-stage node for stress/thermal).
• Match bandwidth If the event is fast, telemetry needs either sufficient bandwidth or a peak/flag capture path.
• Calibrate wisely Production calibration should focus on what is feasible at scale: offset/gain trimming and basic temperature compensation.

Card B — Error source → symptom → corrective action (power-rail focused)

Card C — What to measure (I/V/T) and where the point matters

• Current: measure where the rail current actually flows; document the method (shunt / DCR / estimate) and the dominant drift term.
• Voltage: if PG/UV decisions must reflect the load, define and measure the load node (not only converter output).
• Temperature: use at least one meaningful hotspot proxy (power stage / inductor) and one board hotspot reference for trend.

Card A — From “readouts” to a control model

• Identity Every rail must have a stable Rail_ID that maps to Node_ID + PMBus address + page.
• Acquisition Use polling for slow variables and ALERT for short-window faults; combine them in a hybrid schedule.
• Limits Treat thresholds as a policy: limit + hysteresis + debounce + rate checks.
• Logging Record only power-domain evidence: timestamp + Rail_ID + fault_code + pre/post snapshots.

Card B — PMBus telemetry field template (minimal but usable)

Keep the template small and consistent. Add only fields that change decisions; avoid “register dumps” that cannot be interpreted in the field.

Card C — Polling vs ALERT, and thresholds that do not chatter

• Polling fits trends: temperature rise, average current, slow drift. Use a stable period and do not over-sample what cannot change quickly.
• ALERT fits short windows: UV/OV/OC/OT events, PG violations, and bring-up transitions where waiting for the next poll risks missing evidence.
• Hybrid strategy: low-rate background polling + event-driven ALERT + temporary “bring-up boost” polling during RAMP/VERIFY states.
• Threshold policy: always pair limit with hysteresis and debounce. Add rate checks only when the distinction between a slow drift and a short transient matters.

Card A — Ripple budgeting by rail type (power-side rules)

• Bias / analog Tight ripple budgets and stricter measurement discipline; define the rail’s decision node (where ripple is evaluated).
• Digital Wider ripple tolerance but watch shared-bus current pulsation and cross-rail coupling during bursts.
• Aux Budget is use-driven; avoid over-tight limits that create false alarms without improving system outcomes.
• Budget format: define bandwidth, node, and acceptance window. A ripple limit without measurement definition is not enforceable.

Card B — Sync planning: synchronized, interleaved, or intentionally offset

• Synchronized: noise energy concentrates at predictable frequencies; easier to validate and to correlate to threshold behavior.
• Interleaving (multiphase): phase offsets reduce summed ripple current and flatten the shared-bus pulsation envelope.
• Intentional offset: avoids coherent stacking, but increases the risk of slow beat envelopes when frequencies are close.
• Rule: avoid “nearly the same but not aligned” switching frequencies across converters that feed sensitive rails or share a bus segment.

Card C — Measurement pitfalls that create false ripple conclusions

• Probe loop Long ground leads and large loops inject artifacts. Use short ground or differential probing where possible.
• Bandwidth Unbounded bandwidth inflates readings by capturing high-frequency components that are outside the intended spec.
• Node definition Output capacitor pins reveal converter behavior; remote load node reveals delivered-rail behavior. They are not interchangeable.
• Interpretation A “big ripple” at the wrong node may not correlate to faults; always match the measurement node to the decision node.

Card A — Derating model: from temperature to enforceable limits

• Choose the control temperature Use a meaningful hotspot proxy (power stage / inductor) and document it as T_hotspot.
• Define limit outputs Derating should produce an explicit I_limit or P_limit per rail group (not just warnings).
• Use staged behavior Prefer a staged policy: DERATE → FOLDBACK → SHUTDOWN/LATCH as temperature rises.
• Avoid chatter Add hysteresis, a minimum hold time, and rate limits so the loop does not oscillate.

Card B — PoL thermal path: controllable items that actually move temperature

• Copper and vias: widen the heat spread under the power stage and inductor; treat thermal vias as a heat path, not decoration.
• Interface quality: pads and contact pressure determine whether heat reaches the intended sink; poor interfaces look like “random” derating.
• Airflow sensitivity: a rail that is stable in free airflow can fail when the flow is reduced or blocked; plan for obstruction cases.
• Load distribution: multiphase and parallel rails can share stress; phase-shedding should be temperature-aware to avoid local hotspots.

Card C — Closing the loop with telemetry (policy-driven actions)

• Temp → power limit When T_hotspot crosses a stage boundary, update I_limit/P_limit and record a snapshot.
• Power limit → behavior Apply limits through rail behavior: foldback, phase-shedding, or reduced soft-start slope.
• Time constants Temperature is a slow variable; decisions must use hold time and hysteresis to avoid rapid toggling.
• Mode-aware Bring-up and steady-state can use different limits; high temperature can trigger slower ramps or delayed enable of optional rails.

Checklist — Thermal closure validation (what proves it is done)

• Thermal sense points: T_hotspot location matches the stressed component (power stage / inductor), and T_board is recorded for context.
• Sustained load: test duration is long enough to reach a stable plateau (not only short bursts).
• Worst environment: high ambient, reduced airflow, and airflow blockage are included as explicit cases.
• Input corners: validate at input voltage extremes and during multi-rail high-load overlap.
• Loop stability: no oscillation between derate states; hysteresis and hold time prevent chatter.
• Evidence: each state transition produces a power-domain snapshot (temperature + limit + action + rail status).

Card A — Protection types and action modes (choose behavior, not just thresholds)

• Protections OCP, OVP, UVP, OTP are the basic trip sources. The operational result depends on the action mode.
• Hiccup Periodic restart attempts; useful for transient overloads, risky for repeated failures (can form a reset storm).
• Foldback Limits output to a survivable level; supports degraded operation while reducing stress.
• Latch-off Hard stop after severe or repeated faults; prevents repeated stress and uncontrolled retries.

Card B — False trips: where “faults” come from when nothing is actually broken

• PG threshold mismatch: droop/recovery is normal, but PG timing and windows are too strict for the measured envelope.
• Load steps and burst edges: short transients exceed static limits; without debounce/hysteresis, limits trigger incorrectly.
• Telemetry delay: the event happens faster than the reporting chain; decisions based on stale samples cause misclassification.
• Aliasing / filter mismatch: slow envelopes appear from sampling and filtering, producing periodic “fault” signatures.
• IR drop at the wrong node: sensing at a converter node while decisions are made at the load node leads to apparent UV.

Card C — Fault policy tree (Fault → Detect → Action → Recover)

A stable recovery plan needs three parameters: retry_count, backoff/cool-down, and latch conditions. Without them, repeated faults can produce reset storms.