Case 02 - Power / Telemetry

Rack/Server Power Tree and PMBus Telemetry Plan

A platform-facing power architecture note for high-current accelerator systems: rack input assumptions, board-level protection, VRM transient behavior, PMBus observability, BMC fault response, and debug closure.

Public-reference note

This is not a real rack/server customer incident. Its method is grounded in verified power-tree and sequencing work, SmartVID/PMBus, DCDC loop/compensation, synchronized measurement, RCA, ECO, and validation checklists.

Power Tree

Every rail should have a role, a dependency, a limit, and a witness.

The power tree is written as an integration artifact, not just a schematic view. It ties each conversion stage to sequence timing, protection behavior, telemetry, validation tests, and field triage.

Stage	Design question	Validation evidence	Debug witness
Rack feed	What input voltage, redundancy, inrush, and fault containment assumptions does the node inherit?	Input tolerance, hot-swap behavior, brownout ride-through, eFuse threshold review.	Input voltage/current telemetry, power shelf status, BMC event timestamp.
Intermediate bus	Can the board isolate downstream faults without losing observability?	OCP/OVP/OTP trip tests, retry policy, bulk capacitance and SOA review.	Fault latch, retry counter, rail-good transitions, thermal sensor trend.
GPU core rail	Can the VRM handle accelerator load steps without false trips or link side effects?	Transient capture, loop stability, phase current balance, load-line behavior.	PMBus voltage/current, oscilloscope trigger, workload phase marker.
Aux rails	Do management, retimer, memory, and housekeeping rails sequence before dependent resets release?	Power-up/down timing, reset dependency, marginal delay tests.	State-machine log, rail-good map, retimer/endpoint status registers.

Debug Scenario

GPU stress triggers brownout-like behavior, but the platform only logs a generic power fault.

This is a classic boundary problem: the visible event may be a BMC power fault, a host workload crash, a PCIe retrain, or a thermal throttle. The power engineer must show whether the rail actually drooped, whether protection policy was too aggressive, whether telemetry sampled too slowly, or whether the observed event was secondary.

Closure starts when the timeline becomes unambiguous: workload phase, rail waveform, PMBus sample, BMC event, host log, thermal state, and protection latch all point to the same mechanism.

Telemetry Plan

PMBus should support root cause, not just dashboarding.

Sampling

Use fast capture for events and slower polling for trend.

Separate PMBus trend data from oscilloscope-grade transient evidence. Track sampling interval, aliasing risk, and event latch timing.

Severity

Classify faults by service action.

Distinguish recoverable warning, performance derating, protective shutdown, hardware replace, and supplier FA escalation.

Correlation

Share IDs across logs.

Use a correlation ID that ties BMC event, PMBus register snapshot, host log, workload phase, and lab capture together.

Fault Response

The response table is part of the hardware design.

Event	Immediate response	Evidence to preserve	Design feedback
Transient undervoltage	Latch warning, avoid blind retry until rail and workload phase are recorded.	Waveform, PMBus snapshot, load marker, phase current balance.	Compensation, bulk/decap, load-line, OCP blanking, layout parasitic review.
Overcurrent trip	Shut down affected domain, keep BMC alive, preserve fault registers.	Trip threshold, rail current, temperature, retry counter, module identity.	Protection threshold, inrush profile, module variance, supplier screen.
Thermal derating	Reduce power target, flag thermal policy event, keep fabric logs aligned.	Sensor map, inlet temp, flow/fan state, hotspot estimate, throttle reason.	Sensor placement, cold-plate contact, airflow, derating policy.