PMBus and AVSBus Telemetry and Fault Logging

Separate fast voltage control from power management #

An AI accelerator rail can have three control paths that operate at very different time scales. AVSBus carries fast point-to-point voltage requests from the load. PMBus configures and observes the regulator from a board-management controller. Hardware comparators, enable pins and fault lines must still protect the rail when either serial link or its firmware is unavailable.

That separation is the first design decision. Do not route every event through the BMC merely because the regulator exposes telemetry, and do not treat an AVSBus response as a persistent service record. The released architecture must name which path commands voltage, which path collects evidence and which path acts without software.

The PMBus organization currently identifies PMBus revision 1.5 and AVSBus revision 2.0 as the latest published specifications. Current, orderable controllers can implement earlier revisions: TI's active TPS53676, for example, documents PMBus 1.3.1 and AVSBus as defined in PMBus 1.3.1 Part III. Freeze the revision and supported command set from the exact controller data sheet; a current standard revision does not upgrade installed silicon.

The official PMBus FAQ describes AVSBus as a fast interface for processors, ASICs and FPGAs to control supply voltage, with operation up to 50 MHz and some converter monitoring. It describes PMBus as a complete power-management protocol built on SMBus transport and a defined command language. In production terms, AVSBus belongs to the workload-voltage loop; PMBus belongs to configuration, telemetry, status and service. They are complementary, not interchangeable.

Define a telemetry contract before writing the dashboard #

The host should not discover a regulator by trying every command. PMBus compliance does not mean that every standard command is implemented. The PMBus FAQ requires a compliant device to support at least one non-manufacturer- specific command and to handle accepted or unsupported commands according to the specification. A portable BMC therefore needs a per-device capability table, not a generic assumption.

For each rail, define the following before firmware integration:

TI's TPS53676 exposes voltage, current, input/output power, temperature and fault status through PMBus. Its data sheet also documents per-phase current, combined telemetry/status reads and min/max registers for several measured quantities. Those functions are useful for commissioning and trend capture, but firmware must record what a read represents: PAGE selection, PHASE selection, averaging window and the moment at which the value was sampled.

Use polling for trends, not immediate protection. A 100 ms dashboard interval cannot explain a microsecond overcurrent event, and a successful READ_VOUT does not prove high-bandwidth ripple or load-step compliance. Correlate PMBus data with oscilloscope measurements at the remote-sense point during qualification. The focused GPU load-step guide defines that faster electrical evidence boundary.

Treat SMBALERT and status reads as a recovery protocol #

An alert line is useful only when the recovery sequence is specified. The PMBus FAQ identifies SMBALERT# as optional, so the schematic, controller data sheet and BMC design must agree on whether it exists, how it is pulled up, which devices share it and how the host identifies the source. Polling remains necessary when a selected device or operating mode does not provide the alert.

A robust handler follows an ordered evidence path:

1. Timestamp the interrupt or poll-detected transition before clearing it. 2. Identify the responding address and PAGE without changing operating state. 3. Read STATUS_WORD and the relevant subordinate and manufacturer-specific status registers. 4. Capture related voltage, current, temperature, power and phase data while they are still available. 5. Copy persistent device logs, if implemented, into a BMC-owned record. 6. Execute the platform's latch, retry or shutdown policy. 7. Clear only the status that has been copied and attributed.

Do not start with CLEAR_FAULTS. Clearing first can erase the only clue that an overtemperature warning preceded an overcurrent shutdown. Likewise, a shared SMBALERT# without an address map and arbitration plan can leave firmware searching the bus while the input supply is collapsing. The PMBus organization notes that no central authority assigns device addresses; the board owner must prevent conflicts.

Preserve the first fault through brownout #

Status bits, peak registers and black-box logs are different evidence classes. A status register reports the present or latched condition. A peak register can retain an extreme value without its full sequence. A black-box recorder stores the measurements around the event in nonvolatile memory. The BOM and firmware requirements must use the correct term.

ADI's LTM2987 is a current 16-channel PMBus power-system manager that monitors, sequences and supervises rails and automatically writes fault logs to internal EEPROM. ADI's AN-155 explains the underlying workflow for its PSM family: a circular RAM telemetry buffer is frozen after a fault, copied to EEPROM, then read and decoded by a BMC or tool. The record includes the fault cause, time state, peak voltage/current/temperature values and multiple telemetry loops. The host must read and re-enable logging; otherwise one old record can block the next capture.

Design hold-up for evidence, not only for load ride-through. The supervisor, regulator housekeeping supply, EEPROM-write path and BMC interface need enough energy or independent standby power to finish the required record. If the converter loses bias before nonvolatile storage completes, the system should at least retain a hardware latch or upstream event code that identifies the first trip.

The production log schema should include board serial number and revision, controller OPN, configuration checksum, firmware version, PMBus address/PAGE, fault source, raw status bytes, decoded values, BMC time, boot count and the action taken. Preserve raw data with the decoded message so a later decoder can correct an interpretation error without losing the original evidence.

Choose parts by evidence depth, not interface labels #

Current parts illustrate three different roles. They are not drop-in alternatives and do not imply compatibility with a particular accelerator.

These examples also show why “same PMBus” is not a substitution rationale. Different devices expose different standard and manufacturer-specific commands, formats, PAGE/PHASE behavior, NVM models, tools and fault-retention depth. A controller change can require BMC firmware, production programming, telemetry calibration and service-tool updates even when the bus wires remain identical.

Separate production writes from field diagnostics #

The service interface should be readable without making every rail setting writable. Define which bootloader, fixture or signed maintenance image may alter limits and NVM; keep the normal BMC on a read-mostly policy. The PMBus FAQ lists WP as an optional hardware write-protect input, but availability and protected command scope are device-specific. Confirm the exact implementation instead of assuming that a populated WP pin locks every manufacturer command.

Before enabling a write, verify the board identity, controller OPN, current configuration checksum and expected tool/firmware revision. Record the old and new images, reason, operator or automation identity and power-cycle result. A field update must also define recovery from an interrupted NVM write. If the device cannot guarantee an atomic update, use a board state that keeps the load disabled until checksum and limits are proven. This prevents a useful telemetry port from becoming an untracked way to change startup voltage, current limit or fault response.

Validate faults as end-to-end test cases #

Build the fault matrix before board qualification. Inject each condition at a controlled energy level and verify the electrical response, device registers, persistent record and service message together.

Test alert storms and simultaneous faults. A single UV event can create UV, power-good, communication and temperature consequences across several rails. The log should preserve the initiating event and causal order rather than presenting every later bit as an independent root cause. Also test a stuck-low alert line, duplicate address, bus lockup and BMC reset while the power manager continues operating.

Release the digital power configuration as part of the BOM #

The RFQ and AVL package should request more than the controller marking:

• complete controller or manager OPN, package, grade and carrier suffix;
• programmed versus blank state and approved power-stage pairing;
• PMBus and AVSBus revision, implemented command/capability table and data

formats;

• every address strap, PAGE/PHASE map, pull-up voltage and alert connection;
• configuration source, tool and version, binary image, checksum, write-protect

policy and production programming owner;

• telemetry gains, offsets, sensor locations, filters, poll cadence and

calibration report;

• fault masks, thresholds, retry/latch behavior, persistent-log capacity,

write-completion requirement and read/clear/re-arm sequence;

• BMC decoder/version, event schema and qualification fault-injection report.

Group those artifacts with the controller, stages, sensors and housekeeping supply. A replacement that fits the footprint but changes the data format or manufacturer-specific status map is a firmware and service-tool change. The multiphase controller and smart-power-stage guide defines the electrical pairing; this article defines the management and evidence contract that must travel with it.

Conclusion #

PMBus and AVSBus solve different problems. Use AVSBus for the load's fast, documented voltage-control path; use PMBus for configuration, calibrated telemetry, status and service access; keep immediate protection autonomous in hardware. Then design a first-fault chain that timestamps the event, captures related status before clearing, survives brownout and hands a raw, versioned record to the BMC.

Select parts by their exact command set, telemetry semantics and persistence model—not by an interface logo. Releasing those details with the controller OPN, programmed image and fault-injection evidence gives engineering a debuggable rail and purchasing an RFQ boundary that a superficially compatible substitute cannot silently weaken.

Official references #

• PMBus current specifications: PMBus revision 1.5 and AVSBus revision 2.0
• PMBus official FAQ: protocol scope, AVSBus speed, addressing and optional SMBALERT#
• TI TPS53676 active product page, data sheet and ordering information
• Renesas ISL68137 active AVSBus controller and ISL68137IRAZ-T orderable details
• ADI LTM2987 current product page, Rev. C data sheet and production order codes
• ADI AN-155: Fault Log Decoding with Linduino PSM