You have seen how Digital Power allows rails to work as a team, and how tools enable configuration and debug. Now it is time to step back and look at how Digital Power fits into a system. In particular, how Digital Power integrates with Board Controllers defined by industry standards.

Why should we care about standards?

In the early 2000’s the telecom and server industries began a shift to standards based platforms to reduce cost. The idea was to allow different vendors to plug and play, especially in areas not defined by differentiation.

One driving force was PCI Industrial Computer Manufacturers Group (PICMG). PICMG supports Advanced Mezzanine Card, Advanced TCA, CompactPCI, and other hardware interfaces and standards. A second driving force was Intel and Hewlett Packard. Intel and HP were the driving force behind standards for managing server/communication boards that enable high availability solutions through definition of board controllers and interfaces.

These existing standards for managing server/communication boards include interfacing with I²C/SMBus/PMBus to provide control and telemetry of point of load converters (POL), temperature monitors, and fans, etc. Because the industry has a well-defined architecture that utilizes PMBus, and because Digital Power products use PMBus as the primary communication methodology, one should be aware of the standards and how Digital Power products fit into them.

Standards

There are two standards that define interfaces for managing power systems:

• Intelligent Platform Management Interface (IPMI)
• Hardware Platform Interface (HPI)

IPMI is rooted in the computer systems industry. HPI is rooted in the communications industry. In both cases, their respective industries began shifting from vertically integrated architectures to Commercial Off The Shelf (COTS) architectures, and both had to deal with high reliability/availability. Standards were developed to allow integration of products from different vendors, and both industries had to deal with platform management.

Ipmi

IPMI is a message based standard and its key defining attribute is that it is orthogonal to the main platform, in most cases an operating system. Communication takes place as side-band (shared network interface), or out-of-band (dedicated network interface). Side-band communication takes place via a Network Interface Controller (NIC).

Out-of-band communication takes place via a dedicated Local Area Network (LAN). The network performance of out-of-band communication is typically better due to a dedicated network that does not compete with general traffic. The purpose of IPMI communication independence is that it allows communication before the system starts or boots.

The IPMI standard is implemented in a Baseboard Management Controller (BMC), which manages communication with loads and the NIC or LAN. However, two BMC’s can also communicate with each other via an Intelligent Platform Management Bus/Bridge (IPMB), which is an enhanced form of Inter-Integrated Circuit Bus (I²C).

How does this relate to Digital Power?

The BMC has an I²C/SMBus/PMBus interface that can monitor Power Supplies, Fans, and other hardware. Figure 1 shows a typical block diagram.

 

 

The BMC communicates with Digital Power and other devices to support the IPMI feature set to provide:

• Telemetry
• Configuration
• Control
• Recovery
• Diagnostics

BMCs rely on the PMBus standard so that BMC firmware works across multiple Digital Power devices. Using Digital Power POLs and Managers simplifies integration with BMCs by minimizing custom firmware.

Hpi

HPI is an Application Programming Interface (API) for fault tolerant and high availability systems. HPI typically is implemented as a side-band interface. If you download the Release 1 code header file, you will notice it is a C header file. Release 2 also has a header file, and a Simple Network Management Protocol (SNMP) mapping. Release 3/4 has a header file, and a Telecommunications Computing Architecture (TCA) mapping. Release five maps to Advanced Telecommunications Computing Architecture (ATCA). Whereas IPMI is a message based standard, HPI is a programming standard.

HPI is based on a model of hardware and resources. These domain resources are accessible from the HPI. In this sense, HPI is a self-describing system. Figure 2 shows the architecture.

 

 

Like IPMI, HPI has access to Sensors, Controls, Voltages, and Power Management, including Hot Swap.

How does this relate to Digital Power?

Only indirectly. HPI works at the middleware layer of the software stack and has no direct control of hardware. It relies on lower layers to communicate with hardware, typically through an IPMI interface.

For example, HPI is used a lot in ATCA systems, so the mapping defines TCA objects such as resources in the chassis, shelf manager, and carrier managers. Ultimately these resources have some sort of board controller that supports I²C/SMBus/PMBus and that makes the connection to HPI. Some of the resources are even modeled on IPMI concepts.

It is common for an ATCA/HPI design to include an IPMI Management Controller (IPMC) to manage hardware/board, and the ATCA/HPI platform will include a resource for each IPMC entity. These resources all become part of the HPI defined hierarchal tree.

You can get a sense of how this works by looking at the Emerson ATCA Communication Server document “IPMI Sensor Event to HPI Event Mapping Reference Guide,” for the Centellis 3000 at Emerson Network Power.

In row 5, you will see that the +1.8V IPMI error threshold event maps directly to an HPI event and IPMI event.

A system that uses both standards would implement the HPI software API such that it would use IPMI communication to gain access to the loads via PMBus.

Value of PMBus

The PMBUS standard enables the IPMI and HPI standards by allowing implementations to work with multiple Digital Power devices that support the PMBus standard. This allows firmware implementations to be “qualified” once, and reused on new designs with different Digital Power devices.

Custom Code?

Should you use the standards? There is no easy answer to this question. Some industries have adopted the standard formally, some have adopted it informally, some have been influenced by it, and others have gone their own way. From a firmware perspective, even custom firmware can rely on the PMBus standard and enable firmware reuse. My advice is that as a minimum; spend a little time understanding IPMI and HPI to see what you can reuse, even if all you reuse are concepts. A lot can be learned by studying the architecture to see how problems were solved.

Wrapping up

Digital Power devices don’t exist in a vacuum. Industry standards and their implementations rely on PMBus so that firmware works with multiple devices: without code re-qualification. Standards reduce cost through reuse. Even if you don’t implement the standards, there is value in having a basic understanding of them and the problems they solve.

Glossary

IPMI – Intelligent Platform Management Interface
IPMB – Intelligent Platform Management Bus/Bridge
HPI – Hardware Platform Interface
SMBus – System Management Bus
PMBus – Power Management Bus
I²C – Inter Integrated Circuit Bus
NIC – Network Interface Controller
LAN – Local Area Network
BMC – Baseboard Management Controller
COTS – Commercial Off The Shelf
LPC – Low Pin Count Bus
PICMG – PCI Industrial Computer Manufacturers Group