|Figure 1: Power Delivery messaging comprises two types:|
Control and Data
|Figure 2: The multi-drop CC line facilitates|
sending targeted Power Delivery messages
|Figure 3: Control and data messages have the same format;|
only control messages have zero data objects
While most frames are targeted at either the UFP or DFP using SOP framing, some use SOP' or SOP" framing, enabling the host device to talk to the cable. Again, this happens only with E-marked cables.
|Figure 4: This table shows all of the different control message|
types defined in PD 2.0
|Figure 5: At present, PD 2.0 has only four types of data|
messages, with more expected in the future
Data messages, by definition, have at least one data object, each of which is 32 bits long and is transmitted immediately after the header. At present, only four data message types are defined in the standard (Figure 5). More defined data messages may be augmented to the next revision of the Power Delivery specification. In any case, there are a few scenarios in which data messages must be embedded into a PD packet, such as a device making a power request or reporting its capabilities to a host.
A PD 2.0 message header also contains information on the link partners' power roles. This field isn't used very much in practice because upper layers keep track of the devices' power roles. It becomes important, however, when you begin looking at protocol analyzer traces. Once devices start doing role swaps, things get confusing in a hurry.
Another important field is the MessageID field, which is 3 bits long with values from zero to seven. The value increments with each sequential message and is used like a tag in the SCSI protocol, allowing a responder to tie an acknowledgment back to a specific command. Every PD message requires a good-CRC response from the far end, with that good-CRC message having the same MessageID value as the command it acknowledges.
Next, we'll tie it all together with a look at how the Power Delivery protocol works in practice.