For decades, the relationship between a power converter and the system around it was almost one-way: the load demanded power and the converter supplied it. Signalling was limited to an enable signal, a fault signal and, at most, a voltage setpoint.

In the AI rack, that model is no longer enough. As rack power grows towards 800 VDC distribution architectures (covered in The 800 VDC revolution), the data centre manager needs to know at all times how much power each conversion stage is delivering, how much thermal margin it has and whether there are any alarms. The converter stops being a passive element and becomes a managed node.

This note explains which protocols are involved in that management chain, where each one fits and which firmware capabilities a converter needs to integrate into it.

The management chain: from the data centre manager to the converter

No single protocol links the data centre manager to the converter. Management is organised in layers, and each layer uses a different standard:

For the converter manufacturer, the practical consequence is clear: the equipment must speak PMBus comprehensively and expose the information that the upper layers will translate into Redfish, either directly or through the shelf or rack controller.

PMBus: the converter’s own language

PMBus is the open digital communication standard for power supplies and converters. Its current published revision is 1.5. It defines a common set of commands to read measurements and status and to configure the equipment, for example:

• Measurements: READ_VIN, READ_IOUT, READ_POUT, READ_TEMPERATURE_1.
• Status and alarms: STATUS_WORD and the specific status registers (voltage, current, temperature).
• Configuration: warning and fault thresholds, and operating setpoints.

A converter with a complete, well-documented PMBus implementation simplifies integration: the rack controller can read its data without custom development.

Redfish: the facility view

Redfish is the DMTF standard for infrastructure management through a REST API with JSON data. For power it defines specific schemas, including PowerSubsystem, PowerSupply and PowerSupplyMetrics, as well as a generic sensor model.

The converter does not always need to implement Redfish itself. Typically, the shelf or rack controller collects the PMBus or Modbus data from each unit and publishes it in Redfish. What is essential is that the converter provides all the information those schemas expect: power, voltages, currents, temperatures, efficiency and status.

SCMI: where it really fits

Arm SCMI (System Control and Management Interface) is a standard, transport-independent interface between system software and the platform control firmware. Its natural scope is inside the compute node, not the link to the power supply. It defines protocols for discovery (Base), power domains, system power management, performance, clocks, sensors, reset, voltage and power capping (Powercap).

The Powercap protocol includes, among others, the POWERCAP_CAP_GET and POWERCAP_CAP_SET commands to read and set the power limit of a domain, and POWERCAP_MEASUREMENTS_GET to read average power. Version 4.0 of the specification, still in draft, adds Concurrent Power Limits (CPL) per domain and a telemetry protocol.

How does this relate to the converter? Power capping is executed by the silicon through SCMI, but the decision to cap depends on telemetry from the whole power chain, including the converter: if its thermal or power margin runs out, the manager can reduce compute consumption before the conversion stage operates outside its safe operating area.

Closed-loop thermal control

In liquid-cooled AI racks, thermal control is usually organised in two nested loops. The inner loop, in the coolant distribution unit (CDU), keeps the coolant temperature close to its setpoint by acting on pumps and valves. The outer loop, in the manager, adjusts that setpoint and the power limits according to the thermal telemetry from the racks.

To take part in the outer loop, the converter must publish the temperature of its power semiconductors, the temperature of its magnetic components and its instantaneous efficiency. With that data, the manager can decide whether there is margin for a transient increase in demand or whether power should be limited to protect the equipment’s reliability.

What the converter firmware must provide

• Complete PMBus telemetry: input and output voltage and current, power, internal temperatures and status registers.
• Interface to the rack controller in the protocol specified by the integrator, for example Modbus over RS-485 or CAN.
• Information compatible with the Redfish power model, published directly or through the controller.
• Configurable limits and derating, with event and alarm notification.
• Telemetry latency consistent with the control dynamics defined by the integrator.
• Controlled, traceable firmware updates.

References

• Arm — System Control and Management Interface (SCMI), specification DEN0056.
• DMTF — Redfish: PowerSubsystem, PowerSupply and PowerSupplyMetrics schemas.
• PMBus — Power Management Bus Specification, revision 1.5.
• Open Compute Project — Open Rack V3 specifications.