8 min
The MIPI I3C® protocol is continuing to find use in a wide range of digital control and sensing applications. In this article, we focus on how I3C can be used as a physical layer for enabling the Management Component Transport Protocol (MCTP), which is published by the DMTF standards organization. The MCTP specification is integral to many computer and server architectures because it defines how a system management controller can communicate with managed devices such as PCIe add-in cards and disk drives. With the recent addition of a binding mechanism to I3C, a lot of engineers are currently investigating how to design MCTP over I3C and how to test it.
The MCTP protocol is a byte-aligned messaging system that rides on top of an existing physical layer and/or communications protocol. This is why it is referred to as a transport layer – it only defines the bytes constituting a (management and control) message, and it does not define the way the bytes are transmitted. This concept is illustrated visually in Figure 1.
In the above figure, the grey sections are the typical header and footer sections of an underlying physical layer such as PCI Express (PCIe). The orange and green sections are the payload bytes defined by MCTP. To the underlying physical layer, the MCTP packets are just payload bytes, and they follow the same encoding and mapping schemes of the physical layer.
To explain this further, imagine a system motherboard containing a solid-state disk drive that is connected through a PCIe slot. The disk drive is a managed device in the context of MCTP. And, MCTP control messages can be transported between the CPU and the disk drive over the PCIe protocol itself. This is illustrated schematically in Figure 2.
Now, if you have ever used PCIe, you will know that this is a very high performance, high complexity bus, so it is better to use it for executing real mission-mode transfers (like reading large files from a disk drive) at maximum speed, instead of using it for system management. This is why in many practical implementations, the MCTP protocol often rides on other simpler physical layers such as the SMBus. And now with the recent I3C binding, the MCTP protocol happily rides on an I3C physical layer! See Figure 3.
In this section, we describe how MCTP writes (from a management controller to a managed device) and reads (from a managed device) are constructed over I3C.
From an I3C point of view, MCTP writes are essentially private writes. The controller simply creates a start condition on the I3C bus and then specifies the address of the I3C target device (which is the MCTP managed device) along with a write command. When the target device receives the address and the RnW bit set to zero, indicating a write message, it acknowledges to the controller (i.e. it sends an ACK response) that it is ready to receive the bytes. The controller then proceeds with sending its bytes. These bytes will contain some MCTP-specific structure as shown in Figure 1, but to the I3C bus, they are just payload bytes.
Figure 4 shows the MCTP packet encapsulation over I3C. As can be seen, the first byte is always fixed (containing some reserved bits and version information). The second byte contains a destination endpoint ID (EID), and so on. The definitions for these bytes are well-documented in the MCTP protocol specifications, so they are not repeated here. Note that after the MCTP packet is completed, the I3C protocol sends a Packet Error Code (PEC) byte, which is just required by the MCTP protocol to ensure robustness.
MCTP read messages are a little more complicated than writes, and this is primarily because managed devices might need some time to respond to read commands from a controller. Because of this, read operations often rely on the In-band Interrupt (IBI) feature of I3C. This is an innovative feature, and it allows a peripheral device (i.e. a managed device) to notify the controller when it wants to send data.
Imagine a controller is performing initial MCTP discovery and wants to know the MCTP version of the peripheral. In this case, the controller would send an MCTP control packet (i.e. the “Message Type” field in Figure 4 would be 0x00 which corresponds to an MCTP Control message) with a command called “GET MCTP Version Support”. The peripheral device would prepare the response bytes in its internal transmit buffer. Then, at its will and whenever it is ready to respond, it will issue an IBI request to the controller. After the controller receives the IBI request, it proceeds to initiate a private read message in order to retrieve the read bytes from the peripheral as per the I3C protocol.
The above read example is illustrated graphically in Figure 5. Note that the IBI request includes a mandatory data byte (MDB) with a value that is reserved for MCTP packets.
If IBI is not supported in the target device, then an alternative way of reading in MCTP is through polling. Simply stated, the controller keeps trying to read from a peripheral (by sending an I3C private read command for example) until the peripheral responds with an ACK and with read data.
No matter how read operations are performed (through IBI or polling), the encapsulation of the MCTP messages is always based on that of Figure 1.
The MCTP over I3C protocol includes other features such as support for hub devices and support for hot-plug devices. These features are beyond the scope of this article, but they are supported quite seamlessly by the I3C protocol! For example, when a hot-plug peripheral device is inserted into a live system, it can issue an I3C Hot-Join interrupt, and the controller will be able to recognize it and assign it a dynamic address.
The SV6E-X Mid-Frequency Digital Test Module is Introspect’s award-winning solution for testing and validating I3C interfaces and those derived from it. Naturally, it is able to support the MCTP protocol with ease. For example, to use the SV6E-X as a controller and to generate MCTP messages to a managed device under test, simply use a command like:
controllerDevice.doPrivateWrite(peripheralAddress, mctpPacketBytes)
Where the variable mctpPacketBytes is a Python list containing a sequence of bytes. These bytes are constructed according to the format in Figure 4.
Similarly, the SV6E-X can act as a peripheral for testing controller devices. In this case, performing a peripheral to controller MCTP message transfer can occur with the following code example:
targetDevice.setReadResponseBufferData(mctpPeripheralPacketBytes) targetParams1.ibiMandatoryByte = 0xAE targetDevice.update() targetDevice.requestIBI()
Finally, the SV6E-X can be used as a protocol analyzer and a real-time oscilloscope, and these features are all available for MCTP testing.
In this article, we described the MCTP protocol and how it is encapsulated over the MIPI I3C protocol. We illustrated how MCTP packet bytes can be formatted to create write messages from a controller to a peripheral, and we also showed how a peripheral can notify the controller when it is ready to send read data through in-band interrupts, so that the controller can issue private read messages to retrieve the data from the peripheral after. Finally, we introduced the SV6E-X Mid-Frequency Digital Test Module and showed how it naturally supports MCTP over I3C testing.
Have any questions about MCTP over I3C testing? Write to us at info@introspect.ca.
