h1

USB-PD: Protocol Layer explained

March 27, 2013

After my previous post regarding the Power Delivery PHY, it’s now time to introduce the Protocol Layer (PL).USB-PD Stack 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.

UBS-PD PL

Messages

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.

Timers

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.

Counters

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.

State Machines

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.

Advertisements

One comment

  1. […] the architecture and to implement the digital blocks of the PHY and the upper layers, like the protocol layer. Waiting for the incoming silicon samples, at the moment the board v1.1 implements the analog parts […]



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s