The PMBus Specification Working Group has released the PMBus 1.3 specification proposal for adopter review. The updated specification adds features and improves performance of PMBus 1.2 and adds AVS Bus (Part III). If the Working Group achieves its goals, the new specification will complete its review process and be approved in early 2014 and announced at APEC in Fort Worth.

Changes to Parts I and II

There are four enhancements to Part I and II of the PMBus 1.2 specification:

1. 1MHz Bus Speed
2. Floating Point Data Format
3. Relative Voltage Thresholds
4. Global Process Call

1MHz Bus Speed

The faster bus gives a 2.5x communication improvement that is backwards compatible with 100kHz and 400kHz PMBus devices. The Open Drain architecture was not changed, but the required pull down current was increased to 20mA. Ultimately the pull down current is related to the bus capacitance and timing specifications. When using the newer 1.3 devices at 400kHz the pull down current from the 1.2 specifications will be adequate.

Floating Point Data Format

Floating Point is IEEE 754 Half Precision (16 bit). When implemented, all PMBus commands will use Floating Point. The goal was to create a consistent format (all commands) that is easy to convert to data types used by programmers. Programmers will typically use 32 bit floats, and conversion from half precision to single precision is simply mapping bits, a truncation/rounding operation, or extending zeros. Floating point also supports NaN and ±Inf. NaN indicates a slave could not deliver a meaningful value, eliminating the need to NACK a request.

Floating Point is more machine efficient, easier to work with in code, and industry standardized. Programmers will no longer have to deal with multiple standards from different vendors.  Floating Point is unambiguous and deterministic.

Relative Voltage Thresholds

Most existing firmware converts percentages (margin, fault high/low) to absolute values. Relative Voltage Thresholds allows firmware to program all output voltage related values in percent of the output voltage. When the output voltage is changed, the thresholds will automatically scale based on their value. This also speeds up transactions that move the output voltage.

Global Process Call (GPC)

GPC is an enhancement of Alert Response Address and uses a new framing, e.g. different than read/write word, etc. It also relies on the “bit dominance” protocol of PMBus. Bit dominance is an industry terminology describing an open-drain bus, such that any slave that asserts a zero by pulling the open-drain data line low wins arbitration. PMBus 1.2 uses “bit dominance” to arbitrate addresses. The new GPC protocol uses “bit dominance” to find “important information.”

Similar to ARA, GPC issues a command that all slaves understand, and all slaves try to reply. In the simple configuration, each slave tries to reply, and bit dominance determines which slave wins. When a slave looses, it tries again. Because each slave will only answer once, the GPC command will return data from all slaves with the “important information” coming first. This command is used to get information from all slaves in a priority order.

A second configuration of GPC only allows one slave to reply. This configuration, called Group Mode, is used to find the largest, smallest, or most important information in a power system. Examples are: highest current or temperature.

A third configuration of GPC is used to query status using a mask. This is used to find the most critical fault in the power system.

New Part III

The proposed specification contains a whole new Part III for AVSBus (Adaptive Voltage Scaling). The purpose of AVS is to enable an ASIC, FPGA, or Processor to change the voltage of its supply by sending commands to a POL (Point of Load Converter). In addition, AVS provides for reading back voltage and current of the POL. The AVS algorithm used is typically a proprietary control loop implemented by the system designer. The purpose of AVS is to achieve the highest performance while using the least energy. AVSBus is a communication protocol standard to enable AVS in a system.

The AVSBus is best understood as a SPI bus without Chip Select (CS). The protocol uses Start and CRC sub-frames that allows a slave (POL) to discover the beginning and end of frames without CS.

There are three wires: AVS_Clock, AVS_MData, AVS_SData. Data is issued on the bus when on the rising edge, and clocked into an internal register on the falling edge. All frames are 32 bits out, followed by 32 bits in. When transactions are issued back to back, the bus operates on a 4 byte protocol with return data delayed by 32 bits. At full clock speed of 50MHz, the transaction rate for changing voltage is 640ns. All data values are 16 bit.

Note: The three wire AVSBus does not replace the 3 wire PMBus: it is an additional three wires used solely for AVS that connects between an ASIC/CPU/FPGA and a POL/Manager. PMBus connects between a POL/Manager and a Board Controller or external configuration/debug tool.

AVS returns status data with each transaction indicating ALERT and VGOOD. The ALERT indicates an over-current or other malfunction. VGOOD indicates that a requested voltage change is complete. To reduce power, the ASIC or FPGA can issue a voltage command, stop the clock, and watch for an asynchronous clock transaction on the AVS_SData line indicating VGOOD. It can then start the clock and issue a new transaction. The purpose of VGOOD is to allow the fastest possible voltage change transaction with confirmation.

With these features, several types of feedback can be used:

1. Change State

   1. Set voltage
   2. Confirm voltage
   3. Change ASIC/FPGA operating state

2. Servo A

   1. Set voltage
   2. Read current
   3. Choose new voltage
   4. Go to 1

3. Servo B

   1. Set voltage
   2. Measure ASIC/FPGA operating parameter
   3. Choose new voltage
   4. Go to 1

AVS is sometimes confused with DVS (Dynamic Voltage Scaling) or DVFS (Dynamic Voltage Frequency Scaling). While there is disagreement over terminology, I associate DVS/DVFS with discrete operating states, not with feedback. The AVS Bus is capable of DVS/DVFS in two ways:

1. ASIC/FPGA has a table and issues discrete values to AVSBus
2. POL Vendor adds MFR (extensions) to the AVSBus command set to choose settings from a table

PMBus AVSBus

AVSBus is designed to work with PMBus. There is a new PMBus command that determines whether PMBus or AVSBus commands are in control of the POL output voltage. There is also a new command V_{OUT_MIN}, to complement V_OUT__MAX. The purpose of V_{OUT_MIN} is to prevent the ASIC/FPGA from setting a value that is below the operating capability of itself. Essentially, it prevents the ASIC/FPGA from losing control of its rail voltage.

Because there can be more subtle problems than total control loss, there is an AVSBus command to send the POL to a nominal state. The purpose is if the ASIC/FPGA reads an ALERT from the AVSBus or has an internal operation problem, it can immediately set all its rails to a state that is guaranteed to operate while it makes decisions on how to react to the problem, or to inform another system that there is a problem. This prevents the ASIC/FPGA from getting into so much trouble that it can’t meet its quality of service agreement.