USB-PD: Protocol Layer explainedMarch 27, 2013
After my previous post regarding the Power Delivery PHY, it’s now time to introduce the Protocol Layer (PL).
The PL communicates with the lower PHY layer and with the upper Policy Engine and it is responsible to form the messages used to communicate information between a pair of USB-PD ports.
It receives inputs from the Policy Engine indicating which messages to send and indicates the responses back to the Policy Engine. But it is responsible to form Capabilities messages, requests and acknowledgements and ping packets. It implements counters for packet numbering and dedicated timer for timeouts.
The basic protocol uses a push model where the Provider pushes it capabilities to the Consumer that in turn responds with a request based on the offering. However, the Consumer may asynchronously request the Provider’s present capabilities and may select another voltage/current.
The PL architecture is based on timers, state machines and counters, see the picture, and it’s a pure digital implementation. Below a brief description of each block.
The messages are composed by an header (2 bytes) and a payload of data objects (from 0 to 7 chunk of data, 4 byte each). Two kind of messages are defined:
- Control Message: only the header (2 bytes)
- Data message: header and 1-7 data objects (6-30 bytes)
Control messages are used to signal errors, CRC acknowledge, ping, acceptance or rejection, wait request and soft reset command.
Data messages are used to exchange information and capabilities, to negotiate power profiles and to perform specific tests of compliance.
The details of message coding is fully described on the USB-PD specifications.
The PL shall implement specific timers to check timeouts or to schedule events. The protocol distinguishes the following typologies:
- TimeOut Timers, to check the ACK (CRC OK) after a transmission, the response messages if requested, errors or activities in test mode (BIST)
- Activity Timers, to send from the Source periodically a ping message over VBUS and to check at the Sink side the absence of this message
- Capability Timers, to send periodically a message with Capabilities info in particular conditions and to check the request message timing after a wait request
- Power Supply Timers to verify the new power profile transition timing and timeouts in swap mode sequencing
- NoResponse Timer, used by the Policy Engine to monitor the partner answer timeout. In case of expiration, an Hard Reset is issued
- tBISTMode Timer, used to monitor the time to enter in test mode
- BISTStart Timer, minimun time before start sending messages in test mode by the tester
The USB-PD specification doesn’t enter in implementation details. The timing requested range from ten of us to seconds.
A USB-PD port should implement a 4 counters:
- MessageID Counter [0:7], a rolling counter used to detect duplicate messages. This value is used for the MessageID field in the header of each transmitted message.
- Retry Counter [0:2], used to track the number of transmission timeouts. In case of max retry failure, a soft reset shall be issued
- Hard Reset Counter [0:2], used to count the number of hard reset request without response.
- Capabilities Counter [0:50], used to track the number of Capabilities messages sent by the Source since last hard reset. Optional
- BIST Error Counter [0:216-1], to count the number of tx and rx errors during test procedures.
The protocol behaviour of the Protocol Layer is fully described in the specifications with three state machines:
- PL message Transmission
- PL message Reception
- Hard Reset
The Message Transmission and Reception state machines manage the send and receive sequencing behaviour of the block, including the communication with the Policy Engine and the PHY layer and the interaction with the dedicated and specific timers and counters.
The hard Reset state machine performs reset sequencing of the system in case of request coming from the physical layer or from the Policy Engine.