max/markdowned-datasheets
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

add USB_PD_R3.2

Browse source
This commit is contained in:
0m.ax 2026-08-23 15:14:35 +02:00
parent 920097c3ad
commit a1c36ccc90
192 changed files with 13006 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

212
USB_PD_R3.2/01-introduction.md Normal file
View file

@ -0,0 +1,212 @@
<!-- page 21 -->
# Chapter 1. Introduction
USB Power Delivery (PD) is a power transfer standard that allows USB cables and connectors to deliver higher
power levels (up to 240W) for a wide range of devices, including laptops, tablets, smartphones, and peripherals.
In addition to power delivery, USB PD supports data protocol negotiations over USB-C, thus making it a versatile
solution for both power and data configurations.
Key features of USB PD:
- Negotiable power output – Supports negotiating power up to 240W (48V/5A) to power high-demand devices
like laptops, monitors, and gaming consoles.
- Renegotiable power – Powered devices and power sources renegotiate power levels to deliver optimal power
based on a particular Device's immediate requirements.
- Bidirectional power – Devices can both provide and consume power, enabling features like Host charging
(e.g., powering a laptop from an external monitor).
- Unified connector – Uses the USB-C connector that supports both power and data transfer through a single
cable.
- Data protocol Negotiation – USB PD allows a Device to Connect using the default USB2/USB3 data connection or switch to alternate data modes, enabling USB-C to support additional protocols such as DisplayPort,
USB4, and Thunderbolt 3 for video output and high-speed data transfer.
In summary, USB PD maximizes the potential of USB-C by providing both flexible power delivery and data protocol
negotiations, thus making it a universal solution for modern devices.
## 1.1. Cable and Connectors
The USB Power Delivery specification assumes the use of certified USB cables and associated detection mechanisms as defined in [USB-C].
## 1.2. Operational Overview
A USB PD connection is based on the underlying USB-C standard and roles as defined in [USB-C]. The Source
Port provides power, and the Sink Port consumes power. Each connection has one Source and one Sink, which
are established during the initial connection.
At the point of Attachment, the Source Port functions as both the Downstream Facing Port (DFP) and the VCONN
Source, while the Sink Port functions as the Upstream Facing Port (UFP).
Power roles (Source/Sink), data roles (DFP/UFP), and the VCONN Source role can be swapped independently
during a connection. These role swaps depend on whether the ports support Dual-Role Power (DRP) or Dual-Role
Data (DRD) Capabilities. Ports with dual-role Capabilities can switch between providing and consuming power or
acting as the data Host or Device, depending on the Negotiation.
## 1.3. USB PD Roles
### 1.3.1. Source Port
The Source Port is typically associated with devices like chargers, power banks, notebooks, and docks that power
other devices and provide the power in a USB PD connection. The Source defaults to being the DFP at initial connection. It supplies power to a Connected Sink Port and is responsible for initiating power negotiations to determine
the appropriate voltage and current levels needed by the connection.
<!-- page 22 -->
### 1.3.2. Sink Port
The Sink Port is the power-consuming Port in a USB PD connection and is typically associated with devices like
smartphones, tablets, notebooks, and peripherals that rely on an external power Source to charge. The Sink defaults
to being the UFP at initial connection. It draws power from a Connected Source Port and participates in power
Negotiation to ensure it receives the appropriate voltage and current levels.
### 1.3.3. Downstream Facing Port (DFP)
The Downstream Facing Port (DFP) is the Port in a USB-C connection associated with the USB Host role. It is the
Initiator in Data Role negotiations and handles most downstream data communications. See [USB2] and [USB3]
for more information about Downstream ports.
### 1.3.4. Upstream Facing Port (UFP)
The Upstream Facing Port (UFP) is the Port in a USB-C connection that is associated with the USB Peripheral role.
It is the Responder in Data Role Negotiation and handles most upstream data communication. See [USB2] and
[USB3] for more information about Upstream ports.
### 1.3.5. Dual-Role Power (DRP) Ports
Dual-Role Power Ports can operate as either a Source or a Sink and swap between the two Power Roles as needed.
### 1.3.6. Dual-Role Data (DRD) Ports
Dual-Role Data Ports have the ability to operate as either a DFP or a UFP and to swap between the two Data
Roles. Products can be Dual-Role Data Ports without being Dual-Role Power Ports. This means that they can switch
logically between DFP and UFP Data Roles, even if they are Source-only or Sink-only for power.
### 1.3.7. VCONN Source
The VCONN Source is the Port that provides power to Cable Plugs. The VCONN Source is typically the Downstream
Facing Port (DFP) and supplies power to enable Active Cable circuitry and support cable identification and management in USB PD connections. To commuunicate with Cable Plugs, a Port must be the VCONN Source. For more
information about a USB Type-C Source Port's requirements regarding VCONN, see [USB-C].
### 1.3.8. Cable Plugs
In the context of USB PD, Cable Plug refers to embedded USB PD communication-capable circuitry within a cable,
plug, or accessory that is typically associated with a single plug end of a cable or a captive plug on a Device. This
circuitry consists of the embedded electronic marker (e-marker) chip and/or any active circuitry within the Cable.
Cable Plugs are powered when VCONN is present but are generally not aware of the status of the Contract between
the two Connected ports. They do not initiate communication and only respond to messages that are addressed
to them.
The Source or Sink communicates with the Cable Plug circuitry to retrieve information about the Attached cable
or accessory, such as current-carrying capability or supported data rates, or to direct the plug to enter a specific
data Mode.
## 1.4. Power Delivery Operational Contracts
A PD Source and Sink will be in one of three Contracts:
<!-- page 23 -->
- Default Contract – A non-Negotiated power Contract established at the initial connection, as defined in [USBC], withadefault voltageof5V. The Sink mightdraw uptotheadvertised USB-C current. The Sourceremains
in the Default Contract until the Sink disconnects or both ports Negotiate and establish an Explicit Contract.
- Explicit Contract – The State of the Source and Sink after any PD Power Negotiation has taken place. This
is the normal operational State for PD and must be entered before other USB PD messaging can occur.
A Source offers power contracts to a Sink using USB PD messaging, and the Sink requests a Contract,
which is then accepted by the Source. Data connections and modes other than USB2 and USB3 might be
established in an Explicit Contract.
- Implicit Contract – A transitory power Contract that follows a Power Role Swap or Fast Role Swap. The
available voltage, similar to a Default Contract, is 5V, with current defined by the advertised USB-C current.
The Source in an Implicit Contract will immediately Negotiate with the Sink to establish an Explicit Contract.
All data connections and modes are maintained during an Implicit Contract.
## 1.5. Source and Sink Operation in USB PD
In a USB PD connection, the Source and Sink engage in a series of Message exchanges to Negotiate power
contracts, data roles, and Mode implementation (such as Alternate Mode or USB4 Mode). This process ensures
both ports operate with compatible power levels and functional Capabilities.
### 1.5.1. General Source-to-Sink Initial Interaction
1. Initial Connection (Attach) – Defined by [USB-C].
- The Source asserts Rp (pull-up resistor or pull-up current) on the CC line, and the Sink asserts Rd (pulldown resistor) to establish the connection.
- The Source provides a Default Contract at the advertised Rp current at 5V upon connection.
2. Power Discovery.
- The Source advertises its available power options through its Source Capabilities. These messages
define voltage (e.g., 5V, 9V, 15V, 20V) and current levels the Source can supply.
3. Power Negotiation and Explicit Contract. The Sink requests the preferred power option based on its requirements.
- The Source accepts the Request to establish the Explicit Contract.
- The Source then indicates that it is supplying the agreed power level.
- Once the Explicit Contract is established, both ports enter a stable power State and might establish a
Data Role change or Mode Entry.
4. Data Role and Mode Entry.
- When a role change is desired, the Source and Sink exchange Data Role messages to determine the
DFP (Downstream Facing Port) and UFP (Upstream Facing Port) roles.
- The Source might Request the Sink to send capability information and to confirm data Mode compatibility.
- The Source might initiate USB4 Mode Entry, if supported.
- The Source can initiate Alternate Mode Entry by asking the Sink to Advertise its supported modes.
- If a compatible Alternate Mode is found (e.g., DisplayPort), the Source requests to enter the Mode.
5. Ongoing Communication and Role Swaps
<!-- page 24 -->
- During the connection, the Source and Sink can continue to exchange Control and Data messages to
renegotiate power levels, switch roles, etc.
- Both ports can perform a Power Role Swap, where the Source becomes the Sink, and vice versa.
- A Data Role Swap can also occur, changing which Port acts as the DFP (Host) or UFP (Peripheral)
for data transfer.
## 1.6. Common PD Device Types
USB PD devices fall into a few general categories, such as:
- Dedicated power sources – wall chargers (bricks), power banks, etc.
- Host systems – computers (desktop, portable), mobile phones, tablets, etc.
- Peripherals – mice, keyboards, displays, hard drives, cameras, speakers, headsets, etc.
- Data routers – hubs, docks.
Some devices can be combinations such as a display/dock or cameras that can function as a Host or Device. With
USB PD, these can also be power Sources or power Sinks, or both, depending on what they are Attached to. For
example, a Host computer can be a power Sink and be charged when Connected to a wall Charger, but it might
then be a power Source to a downstream Peripheral such as a hard drive.
## 1.7. USB-PD Architectural Overview
This section describes the logical architecture of the USB Power Delivery (USB PD) specification. The architecture
overview presented here is conceptual and not intended to prescribe a specific implementation. Rather, it provides
a high-level framework that is referenced throughout this specification.
USB PD defines a bus protocol specifying voltage levels, current limits, Signaling, timing, and other interface parameters that are Negotiated between two ports. It does not define how these requirements must be implemented
in a particular Device. Implementation details are left to the product designer and are outside the scope of this
specification.
At a high level, USB PD is structured as a hierarchy of control layers, where each layer communicates with its
adjacent layers. From lowest to highest, these layers are:
- `Device Policy Manager`: Coordinates USB PD behavior across the Device by managing one or more ports
based on the Device's overall power and data Policy.
- `Policy Engine`: Enforces local power and data Policy for an individual Port.
- `Protocol Layer`: Constructs and interprets USB PD messages exchanged between ports.
- `Physical Layer`: Handles bit-level transmission and reception on the physical connector and performs error
detection on messages using a CRC mechanism.
- `USB-C Port Control`: Provides mechanisms to execute USB-C State machines and informing the other
layers of Attach/Detach events, plug orientation, and set and detect Type-C current advertisements.
Each Port includes its own USB-C Port Control, Physical Layer, Protocol Layer, and Policy Engine. The Device
Policy Manager is a single entity that manages all ports within the Device.
USB PD operates over a USB-C connector; as such, the State machines defined in [USB-C] reside within or closely
interact with the USB PD control layers. Similarly, voltage and current control for power delivery interface tightly with
these layers. Figure 1.1 illustrates these architectural elements.
<!-- page 25 -->
**Figure 1.1. USB PD Capable Device High Level Architecture**
![Figure 1.1. USB PD Capable Device High Level Architecture](01-introduction/figure-1.1.png)

BIN
USB_PD_R3.2/01-introduction/figure-1.1.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 43 KiB

367
USB_PD_R3.2/02-glossary-and-info.md Normal file
View file

@ -0,0 +1,367 @@
<!-- page 26 -->
# Chapter 2. Glossary and Info
## 2.1. Conventions
### 2.1.1. Precedence
If there is a conflict between text, figures, and tables, the precedence is tables, figures, and then text.
### 2.1.2. Keywords
The following keywords differentiate between the various levels of a requirement and the applicable options.
**Table 2.1. Keywords**
| Keyword | Definition |
|---|---|
| Deprecated | Indicates a feature, supported in previous releases of the specification, which is no longer supported. |
| Discard / Discards / Discarded | Indicates that a Packet, when received, is thrown away by either the PHY Layer or the Protocol Layer. |
| Dynamic | Indicates a field or behavior that is not static and is allowed to change. |
| Ignore / Ignores / Ignored | Indicates a Message or Message field which, when received, results in no special action by the receiver.A Message with an Ignored field is processed normally except for any actions relating to the Ignored field. |
| Informative | Content provided to improve comprehension; not an implementation requirement. |
| Invalid | When used in relation to a Packet, indicates that the Packet's usage or fields fall outside of the defined specification usage.<br><br>When used in relation to an Explicit Contract, indicates that a previously established Explicit Contract can no longer be maintained by the Source.<br><br>When used in relation to individual K-codes or K-code sequences, indicates that the received Signaling falls outside of the defined specification.<br><br>When used in relation to a Message Field, indicates that a disallowed value was received.<br><br>Invalid usages, fields, K-codes, and values might change in future revisions of this specification. |
| May / May Not | Indicates a choice with no implied preference. |
| N/A | Indicates that a field or value is not applicable and has no defined value and is not to be checked or used by the recipient. |
| Optional | Describes features not mandated by this specification. If a PDUSB Device implements an Optional feature, then all Required parts of the feature Shall be implemented. |
| Reserved | Indicates bits, bytes, words, fields, and code values that might be used by future revisions of this specification. Reserved bits, bytes, words, or fields are set to zero by the sender and are ignored by the receiver. |
| Required | Describes a feature or behavior mandated by this specification; something that Shall be implemented. |
| Shall | Equivalent keywords indicating a mandatory requirement. Designers are mandated to implement all such requirements to ensure interoperability with other compliant devices. |
| Shall Not | Inverse of Shall indicating non-compliant operation. |
| Should | Indicates a flexibility of choice with a preferred alternative; equivalent to the phrase "it is recommended that…". |
| Should Not | Inverse of Should; equivalent to the phrase "it is recommended that implementations do not…". |
| Static | Indicates a field or behavior that never changes. |
| Valid | Inverse of Invalid indicating either a Packet or Signaling that fall within the defined specification or an Explicit Contract that can be maintained by the Source. |
<!-- page 27 -->
### 2.1.3. Numbering
Numbers that are immediately followed by a lowercase "b" (e.g., 01b) are binary values. Numbers that are immediately followed by an uppercase "B" are byte values. Numbers that are immediately followed by a lowercase "h" (e.g., 3Ah) or are preceded by "0x" (e.g., 0xFF00) are hexadecimal values. Numbers that do not contain any letters are decimal values.
## 2.2. Related Documents
Document references listed in Table 2.2 are inclusive of all approved and published ECNs and Errata.
**Table 2.2. Document References**
| Bookmark Reference | Title |
|---|---|
| [DPTC] | DisplayPort Alt Mode on USB Type-C Standard www.vesa.org. |
| [IEC 60950-1] | IEC 60950-1 Information technology equipment – Safety – Part 1: General requirements: Amendment 1:2009, Amendment 2:2013. www.iec.ch. |
| [IEC 60958-1] | IEC 60958-1 Digital Audio Interface Part:1 General. www.iec.ch. |
| [IEC 62368-1] | IEC 62368-1 Audio/Video, information, and communication technology equipment – Part 1: Safety requirements. www.iec.ch. |
| [ISO 3166] | ISO 3166 international Standard for country codes and codes for their subdivisions. www.iso.org/iso/home/standards/country_codes.htm. |
| [TBT3] | See [USB4] for Thunderbolt 3 Device operation www.usb.org/documents. |
| [UCSI] | USB Type-C Connector System Software Interface (UCSI) Specification www.usb.org/documents. |
| [USB2] | Universal Serial Bus 2.0 Specification, www.usb.org/documents. |
| [USB3] | Universal Serial Bus 3.2 Specification www.usb.org/documents. |
| [USB-C] | Universal Serial Bus Type-C Cable and Connector Specification, www.usb.org/documents. |
| [USB4] | Universal Serial Bus 4 Specification (USB4), www.usb.org/documents. |
| [USB BC] | Universal Serial Bus Battery Charging Specification plus Errata (referred to in this document as the Battery Charging specification). www.usb.org/documents. |
| [PD] | Universal Serial Bus Power Deliver Specification, Revsion 3.2 Version 1.2. www.usb.org/documents. |
| [PD2] | Universal Serial Bus Power Deliver Specification, Revsion 2.0 Version 1.3. www.usb.org/documents. |
| [PDSSR] | PDUSB Status Reporting and Device States, Revision 1.1. www.usb.org/documents. |
| [PDFU] | Universal Serial Bus Power Delivery Firmware Update Specification, Revision 1.0. www.usb.org/documents. |
| [USBC Auth] | Universal Serial Bus Type-C Authentication Specification, www.usb.org/documents. |
| [USBPD Compliance] | USB Power Delivery Compliance Test Specification, www.usb.org/documents. |
| [PDUSB] | PDUSB Status Reporting and Device States, Revision 1.1. www.usb.org/documents. |
## 2.3. Terms and Abbreviations
This section defines terms used throughout this document. For additional terms that pertain to the Universal Serial Bus, see Table 2.3 in the [USB2], [USB3], [USB-C] and [USB BC] specifications.
**Table 2.3. Terms and Abbreviations**
| Term | Description |
|---|---|
| AC Supply / AC Supplied | Refers to the main AC power Source typically provided to the wall and often referred to as "mains" or "wall mains". |
<!-- page 28 -->
| Term | Description |
|---|---|
| Active Cable | A cable with a USB Type-C plug on each end that incorporates data bus signal conditioning circuits. The cable supports the Structured VDM Discover Identity Command to expose its characteristics in addition to other Structured VDM Commands (Electronically Marked Cable see [USB-C]). |
| Active Cable VDO | VDO defining the Capabilities of an Active Cable. |
| Active Mode | A Mode which has been through the Mode Entry process but not the Mode Exit process. |
| Adjustable Voltage Supply (AVS) | A power supply whose output voltage can be adjusted to an operating voltage within its Advertised range inside an APDO. |
| Advertise | An offer for power made by a Source in the Source_Capabilities/EPR_Source_Capabilities Message (e.g., a PDO or APDO). |
| Alternate Mode | Operation defined by a Vendor or Standard's organization, which is associated with a SVID. The definition of Alternate Modes is outside the scope of USB-IF specifications. Entry to and exit from the Alternate Mode uses the Mode Entry and Mode Exit processes. |
| Alternate Mode Adapter (AMA) | A Device which supports Alternate Modes. |
| Alternate Mode Controller (AMC) | A Host that supports connection to AMAs. |
| Assured Capacity Port | Assured Capacity Port – As defined in [USB-C]. Assured Capacity Ports can be either Managed Capability Ports or Guaranteed Capability Ports. |
| Atomic Message Sequence (AMS) | A fixed sequence of Messages that must complete before other messages are allowed to be sent. |
| Attach / Attached / Attachment | Mechanical joining of the Port Pair by a connector. |
| Augmented Power Data Object (APDO) | Data Object used to expose a Source Port's or Sink Port's power Capabilities as part of a Source_Capabilities/EPR_Source_Capabilities or Sink_Capabilities/EPR_Sink_Capabilities Message respectively. A PPS Data Object, SPR AVS Data Object and EPR AVS Data Object are defined. |
| Battery | A power storage Device residing behind a Port that can either be a Source or Sink of power. |
| Battery Slot | A physical location where a Hot Swappable Battery can be installed. A Battery Slot might or might not have a Hot Swappable Battery present in a Battery Slot at any given time. |
| Battery Supply | A power supply that directly applies the output of a Battery to VBUS. This is exposed by the Battery Supply PDO. |
| Bi-phase Mark Coding (BMC) | Modification of Manchester coding where each zero has one transition and a one has two transitions (see [IEC 60958-1]). |
| Built-In Self-Test (BIST) | Power Delivery testing mechanism for the PHY Layer. |
| BIST Data Object (BDO) | Data Object used by BIST Messages. |
| BIST Mode | A BIST receiver or transmitter test Mode enabled by a BIST Message. |
| BIST Carrier Mode | A BIST Mode in which the PHY Layer sends out a BMC encoded continuous string of alternating "1"s and "0"s. |
| BIST Test Data Mode | A BIST Mode in which the PHY Layer sends out a GoodCRC Message and then enters a test Mode where it sends no further Messages, except GoodCRC Messages, in response to received Messages. |
| BIST Shared Capacity Test Mode | A BIST Mode applicable only to a Shared Capacity Group of Ports where the maximum Source Capabilities are always offered on every Port, regardless of the availability of shared power i.e., all shared power management is disabled. |
| Cable Capabilities | Capabilities offered by a Cable Plug. |
| Cable Discovered | USB Power Delivery Ports that have exchanged a Message and a GoodCRC Message response with a Cable Plug or a VPD using the USB Power Delivery protocol so that both the Port and the Cable Plug know that each is PD Capable and which Revision they each support. |
| Cable Discovery | See Cable Discovered. |
| Cable Plug | Term used to describe a PD Capable element in a Multi-Drop system addressed by SOP' Packets/ SOP'' Packets. Logically the Cable Plug is associated with a USB Type-C plug at one end of the cable. In a practical implementation, the electronics might reside anywhere in the cable. |
| Cable Reset | This is initiated by Cable Reset Signaling from the DFP. It restores the Cable Plugs to their default, power up condition and resets the PD communications engine in the cable to its default State. It does not reset the Port Partners. |
| Cable VDO | VDO returned by the Cable Plug containing Cable Capabilities. |
| Capabilities | Features supported by a product. These can include, for example, power levels supplied/ needed, cable type, Battery support or [USB4] support. |
<!-- page 29 -->
| Term | Description |
|---|---|
| Capabilities Mismatch | Indication from the Sink that the Source's Advertised Capabilities don't match the Sink's needs. |
| Configuration Channel (CC) | Single wire used by the BMC PHY Layer Signaling Scheme (see [USB-C]). |
| Cert Stat VDO | The Cert Stat VDO contains the XID assigned by USB-IF to the product before certification in binary format. |
| Charge-Through Accessory | A USB accessory that is designed to allow a Source to be Connected through the accessory to charge a system to which it is Attached. Most common use is to allow a single Port USB Host to support a USB Device while being charged through the accessory from and external Source. |
| Chunk | A 26 byte or less portion of a Data Block. Data Blocks can be sent either as a single Message or as a series of Chunks. |
| Chunked Extended Message | Extended Message which has been broken up into Chunks. |
| Chunking | The process of breaking up a Data Block larger than 26 bytes into two or more Chunks. |
| Chunking Layer | Part of the Protocol Layer responsible for Chunking. |
| Cold Socket | A Port that does not apply power on VBUS until a Sink is Attached. |
| Collision Avoidance | Mechanisms to prevent simultaneous communication by the Source, Sink and Cable Plug on CC. |
| Command | Request and response pair defined as part of a Structured Vendor Defined Message. |
| Connected / Connect | USB Power Delivery ports that have exchanged a Message and a GoodCRC Message response using the USB Power Delivery protocol so that both Port Partners know that each is PD Capable. |
| Constant Voltage (CV) | A Constant Voltage feature of a PPS Source. The PPS Source output voltage remains constant as the load changes up to its Current Limit. |
| Continuous BIST Mode | The BIST Mode where the Port or Cable Plug being tested sends a continuous stream of test data. |
| Contract | An agreement on both power level and direction between a Port Pair. A Contract could be explicitly Negotiated between the Port Pair or could be an implicit power level defined by the current State. While operating in Power Delivery Mode there will always be either an Explicit Contract or Implicit Contract in place. The Contract can only be altered in the case of a Negotiation/Re-Negotiation, Power Role Swap, Fast Role Swap, Hard Reset, Error Recovery or failure of the Source. |
| Control Message | A Control Message is defined as a Message with the Number of Data Objects field in the Message Header is set to zero. The Control Message consists only of a Message Header and a CRC. |
| Cyclic Redundancy Check (CRC) | An error-detecting code used to determine if a block of data has been corrupted. |
| Current Limit (CL) | A current limiting feature of a PPS Source. When a Sink operating in PPS Mode attempts to draw more current from the Source than the requested Current Limit value, the Source reduces its output voltage so the current it supplies remains at or below the requested value.<br><br>Note: Current Limit is not supported by SPR AVS and EPR AVS Sources. |
| Data Block | An Extended Message Payload data unit. This is distinct from a Data Object used by a Data Message which is always a 32-bit object. |
| Data Message | A Data Message consists of a Message Header followed by one or more Data Objects. Data Messages are easily identifiable because the Number of Data Objects field in the Message Header is always a non-zero value. |
| Data Object | A Data Message Payload data unit. This 32-bit object contains information specific to different types of Data Message. For example Power, Request, BIST, and Vendor Data Objects are defined. |
| Data Reset | Process which resets USB Communication. |
| Data Role | A Port Partner will be in one of two Data Roles; either DFP (USB Host) or UFP (USB Device). |
| Data Role Swap | Process of exchanging the Data Roles between Port Partners. |
| Dead Battery | A Device has a Dead Battery when the Battery in a Device is unable to power its functions. |
| Default Contract | An agreement on current at 5V is reached between a Port Pair based on Type-C current [USB-C]. |
| Detach / Detached | Mechanical unjoining of the Port Pair by removal of the cable. |
| Device | When in upper cased (Device), refers to a USB Device (Peripheral or Hub). When lower cased (device), it refers to any USB product, either USB Device or USB Host. |
| Device Policy | Policy applied across multiple Ports in a Source or Sink. |
| Device Policy Manager (DPM) | Module running in a Source or Sink that applies Device Policy to each Port in the Device, as Local Policy, via the Policy Engine. |
| DFP VDO | VDO returned by the DFP containing Capabilities. |
<!-- page 30 -->
| Term | Description |
|---|---|
| Differential Non-Linearity (DNL) | The difference between an ideal LSB step, and the real observable LSB step. A DNL of 0 indicates that the step is ideal. |
| Discovery Process | Command sequence using Structured Vendor Defined Messages resulting in identification of the Port Partner and Cable Plug, and their supported SVIDs and Alternate Modes. |
| Downstream Facing Port (DFP) | Indicates the Port's position in the USB topology which typically corresponds to a USB Host root Port or Hub downstream Port as defined in [USB-C]. At connection, the Port defaults to operation as the Source and as a USB Host (when USB Communication is supported). |
| Dual-Role Data (DRD) | Capability of operating as either a DFP or UFP. |
| Dual-Role Power (DRP) | Capability of operating as either a Source or Sink. |
| **Dynamic** Power Supply (DPS) | A Source that offers a guaranteed power and offers a maximum power when conditions are right. Conditions may include low enough internal temperature, ambient temperature, etc. The maximum power capability is not guaranteed and may be revoked by the Source. |
| End of Packet (EOP) | K-code marker used to delineate the end of a Packet. |
| Extended Power Range (EPR) | Extends the power range from a maximum of 100W (SPR) to a maximum of 240W (EPR). When operating in the EPR Mode, only EPR specific Messages (the EPR_Source_Capabilities Message and the EPR_Request Message) are used to Negotiate Explicit Contracts. |
| EPR AVS | A power supply operating in EPR Mode whose output voltage can be adjusted to an operating voltage within its Advertised range through an APDO. |
| EPR AVS Mode | A EPR Source, currently operating in an EPR AVS Contract, is said to be operating in EPR AVS Mode. |
| EPR Cable | A cable which is rated to operate in both SPR Mode and EPR Mode. |
| EPR Capabilities | The EPR Capabilities Messages (EPR_Source_Capabilities and EPR_Sink_Capabilities) are Extended Messages with the first seven positions filled with the same SPR PDOs and APDOs returned by the SPR Capabilities Messages (Source_Capabilities and Sink_Capabilities) followed by the EPR PDOs and APDOs starting in the eighth position. |
| EPR Capable | A product which has the ability to operate in EPR Mode. |
| EPR Mode | A Power Delivery Mode of operation where maximum allowable voltage is 48V. The Sink complies to the requirements of [IEC 62368-1] for operation with a PS3 Source. The Source complies to the requirements of [IEC 62368-1] for operation with a PS3 Sink. The cable complies with [IEC 62368-1]. Entry into the EPR Mode requires that an EPR Source is Attached to an EPR Sink with an EPR Cable. The EPR Source will only enter the EPR Mode when requested to do so by the Sink and it has determined it is Attached to an EPR Sink with an EPR Capable cable.<br><br>Only the EPR_Source_Capabilities and the EPR_Request Messages are allowed to Negotiate EPR Explicit Contracts. The SPR Mode Messages (Source_Capabilities and Request) are not allowed to be used while in EPR Mode. |
| EPR PDO / EPR APDO | Fixed Supply PDO that offers either 28V, 36V or 48V.<br><br>Adjustable Voltage Supply (AVS) APDO whose Maximum voltage is the highest Fixed Supply PDO voltage in the EPR_Source_Capabilities Message and no more than 240W. |
| EPR Sink | A Sink that supports both SPR Mode and EPR Mode. |
| EPR Source | A Source that supports both SPR Mode and EPR Mode. |
| Error Recovery | Port enters the ErrorRecovery State as defined in [USB-C]. |
| Explicit Contract | An agreement reached between a Port Pair as a result of the Power Delivery Negotiation process. An Explicit Contract is established (or continued) when a Source sends an Accept Message in response to a Request Message sent by a Sink followed by a PS_RDY Message sent by the Source to indicate that the power supply is ready. This corresponds to the PE_SRC_Ready State for a Source Policy Engine and the PE_SNK_Ready State for a Source Policy Engine. The Explicit Contract can be altered through the Re-Negotiation process. |
| Extended Capabilities | An Extended Message containing Capabilities information. |
| Extended Control Message | An Extended Message containing control information only. |
| Extended Message | A Message containing Data Blocks. The Extended Message is defined by the Extended field in the Message Header being set to one and contains an Extended Message Header immediately following the Message Header. |
| Extended Message Header | Every Extended Message contains a 16-bit Extended Message Header immediately following the Message Header containing information about the Data Block and any Chunking being applied. |
<!-- page 31 -->
| Term | Description |
|---|---|
| External Power Supply (EPS) | An AC Supplied Device that is only used to provide power as a Source (e.g. Power Brick). |
| External Supply | Power supply external to the Device. This could be powered from the wall or from any other power Source. |
| Fast Role Swap (FRS) | Process of exchanging the Source and Sink Power Roles between Port Partners rapidly due to the disconnection of an External Power Supply. |
| First Explicit Contract | The Explicit Contract that immediately follows an Attach, power on Hard Reset, Power Role Swap or Fast Role Swap event. |
| Fixed Battery | A Battery that is not easily removed or replaced by an end user e.g., requires a special tool to access or is soldered in. |
| Fixed Supply | A well-regulated fixed voltage power supply with a narrow variablility as described in a Fixed Supply PDO. |
| Frame | Generic term referring to an atomic communication transmitted by PD such as a Packet, Test Frame or Signaling. |
| Guaranteed Capability Port | A Guaranteed Capability Port is always capable of delivering its Port Maximum PDP and indicates this by setting its Port Present PDP to be the same as its Port Maximum PDP except when limited by the cable's Capabilities. This is a **Static** capability. |
| Hard Reset | This is initiated by Hard Reset Signaling from either Port Partner. It restores VBUS to USB Default Operation and resets the PD communications engine to its default State in both Port Partners as well as in any Attached Cable Plugs. It restores both Port Partners to their default Data Roles and returns the VCONN Source to the Source Port. A DRP Source Port operating as a Source will continue to operate as a Source. |
| Host | See USB Host. |
| Hot Swappable Battery | A Battery that is easily accessible for a user to remove or change for another Battery. |
| Hub | A USB Device that provides additional connections to the USB. |
| ID Header VDO | The VDO in a Discover Identity Command immediately following the VDM Header. The ID Header VDO contains information corresponding to the Power Delivery Product. |
| Idle | Condition on CC where there are no signal transitions within a given time window. |
| Implicit Contract | An agreement on power levels between a Port Pair which occurs, not because of the Power Delivery Negotiation process, but because of a Power Role Swap or Fast Role Swap. Implicit Contracts are transitory since the Port Pair is required to immediately Negotiate an Explicit Contract after the Power Role Swap. An Implicit Contract **Shall** be limited to Type-C current [USB-C]. |
| Initial Sink | Sink at the start of a Power Role Swap or Fast Role Swap which transitions to being the New Source. |
| Initial Source | Source at the start of a Power Role Swap or Fast Role Swap which transitions to being the New Sink. |
| Initiator | The initial sender of a Command Request in the form of a query. |
| Invariant PDOs | A Source Port that offers Invariant PDOs will always Advertise the same PDOs except when limited by the cable. |
| IoC | The Negotiated operating current. |
| IR Drop | The voltage drop across the cable and connectors between the Source and the Sink as defined in [USB-C]. It is a function of the resistance of the ground and power wire in the cable plus the contact resistance in the connectors times the current flowing over the path. |
| K-code | Special symbols provided by the 4b5b coding scheme. K-codes are used to signal Hard Reset and Cable Reset and delineate Packet boundaries. |
| Local Policy | Every PD Capable Device has its own Policy, called the Local Policy that is executed by its Policy Engine to control its power delivery behavior. The Local Policy at any given time might be the default Policy, hard coded or modified by changes in operating parameters or one provided by the system USB Host or some combination of these. The Local Policy Optionally can be changed by a System Policy Manager. |
| LPS | Limited Power Supply as defined in [IEC 62368-1]. |
| LSB | An abbreviation for Least Significant Bit. |
| Managed Capability Port | A Managed Capability Port can have its Port Present PDP set to a different value than its Port Maximum PDP. Its Port Present PDP value can be dynamic and change during normal operation. |
| Message | The Packet Payload consisting of a Message Header for Control Messages and a Message Header and data for Data Messages and Extended Messages. |
<!-- page 32 -->
| Term | Description |
|---|---|
| Message Header | Every Message starts with a 16-bit Message Header containing basic information about the Message and the PD Port's Capabilities. |
| Modal Operation | Operation where there are one or more Active Data Mode. Modal Operation ends when there are no longer any Active Data Modes. |
| Mode | Mode is a general term used to describe a particular type of operation of a given Device. Examples of modes are: Alternate Mode, EPR Mode, SPR Mode. |
| Mode Entry | Process to start operation in a particular Mode. |
| Mode Exit | Process to end operation in a particular Mode. |
| Multi-Drop | PD is a Multi-Drop system sharing the Power Delivery communication channel between the Port Partners and the cable. |
| Negotiate / Negotiated / Negotiation | The PD process whereby the Source Advertises its Capabilities, the Sink requests one of the Advertised Capabilities, and the Source acknowledges the Request, alters its output to satisfy the request and informs the Sink. The result of the Negotiation is an Explicit Contract. |
| New Sink | Sink at the end of a Power Role Swap or Fast Role Swap which has transition from being the Initial Source. |
| New Source | Source at the end of a Power Role Swap or Fast Role Swap which has transition from being the Initial Sink. |
| Packet | One entire unit of PD communication including a Preamble, SOP*, Payload, CRC and EOP. |
| Passive Cable | Cable with a USB plug on each end at least one of which is a Cable Plug supporting SOP' that does not incorporate data bus signal conditioning circuits. Supports the Structured VDM Discover Identity to determine its characteristics (Electronically Marked Cable see [USB-C]).<br><br>Note: This specification does not discuss Passive Cables that are not Electronically Marked. |
| Passive Cable VDO | VDO defining the Capabilities of a Passive Cable. |
| Payload | Data content of a Packet, provided to/from the Protocol Layer. |
| PD | USB Power Delivery. |
| PD Capable | A Port that supports USB Power Delivery. |
| PD Power (PDP) | The output power of a Source or input power of a Sink. |
| PD SID | Standard ID allocated to this specification by the USB Implementer's Forum. |
| PDP Rating | The PDP Rating is the Manufacturer declared PDP. The Source Port PDP Rating is the Port Maximum PDP and the Sink Port PDP Rating is the maximum PDP the Sink can utilize. |
| PDUSB | USB Device Port or USB Host Port that is both PD Capable and capable of USB Communication. See also PDUSB Host, PDUSB Device and PDUSB Hub. |
| PDUSB Device | A USB Device with a PD Capable UFP. A PDUSB Device is only addressed by SOP Packets. |
| PDUSB Host | A USB Host which is PD Capable on at least one of its DFPs. |
| PDUSB Hub | A Port expander USB Device with a UFP and one or more DFPs which is PD Capable on at least one of its Ports. A self-powered PDUSB Hub is treated as a USB Type-C Multi-Port Charger. |
| PDUSB Peripheral | A USB Device with a PD Capable UFP which is not a PDUSB Hub. A PDUSB Peripheral is only addressed by SOP Packets. |
| Peripheral | A physical entity that is Attached to a USB cable and is currently operating as a USB Device. |
| PHY Layer | The Physical Layer responsible for sending and receiving Messages across the USB Type-C CC wire between a Port Pair. |
| Policy | Policy is defined by the product maker and sets the behavior of PD Capable parts of the system and defines the Capabilities it Advertises, requests made to (re)Negotiate power and the responses made to requests received. |
| Policy Engine (PE) | The Policy Engine interprets the Device Policy Manager's input to implement Policy for a given Port and directs the Protocol Layer to send appropriate Messages. |
| Port | An interface typically exposed through a receptacle, or via a plug on the end of a hard-wired captive cable. USB Power Delivery defines the interaction between a Port Pair. |
| Port Pair | Two Attached PD Capable Ports. |
| Port Partner | A Contract is Negotiated between a Port Pair Connected by a USB cable. These ports are known as Port Partners. |
| Power Conductor | The wire that delivers power from the Source to Sink. For example, USB's VBUS. |
<!-- page 33 -->
| Term | Description |
|---|---|
| Power Data Object (PDO) | Data Object used to expose a Source Port's or Sink Port's power Capabilities as part of a Source_Capabilities / EPR_Source_Capabilities or Sink_Capabilities / EPR_Sink_Capabilities Message respectively. Fixed Supply, Variable Supply and Battery Supply Power Data Objects are defined; SPR Mode uses all four while EPR Mode uses only Fixed Supply and AVS PDOs. |
| Power Delivery Mode | Operation after a Contract has initially been established between a Port Pair. This Mode persists during normal Power Delivery operation, including after a Power Delivery Mode. Power Delivery Mode can only be exited by Detaching the Ports, applying a Hard Reset or by the Source removing power (except when the Initial Source removes power from VBUS during the Power Role Swap procedure). |
| Power Role | A Port Partner will be in one of two Power Roles; either Source or Sink. |
| Power Role Swap | Process of exchanging the Source and Sink Power Roles between Port Partners. |
| Power Rules | Define voltages and current ranges that are offered by compliant USB Power Delivery Sources and used by a USB Power Delivery Sink for a given value of PDP Rating. |
| PPS Mode | An SPR Source, currently operating as a Programmable Power Supply, is said to be operating in PPS Mode. |
| Preamble | Start of a transmission which is used to enable the receiver to lock onto the carrier. The Preamble consists of a 64-bit sequence of alternating 0s and 1s starting with a "0" and ending with a "1" which is not 4b5b encoded. |
| Product ID (PID) | 16-bit unsigned value assigned by the vendor for a product. |
| Product Type | Product categorization returned as part of the Discover Identity Command. |
| Product Type VDO | VDO identifying a certain Product Type in the ID Header VDO of a Discover Identity Command. |
| Product VDO | The Product VDO contains identity information relating to the product. |
| Programmable Power Supply (PPS) | A power supply, operating in SPR Mode, whose output voltage can be programmatically adjusted in small increments over its Advertised range and has a programmable output current fold back.The Capabilities are exposed by the SPR Programmable Power Supply APDO. |
| Protocol Error | An Unexpected Message during an Atomic Message Sequence. A Protocol Error during an AMS will result in either a Soft Reset or a Hard Reset. |
| Protocol Layer | The entity that forms the Messages used to communicate information between Port Partners. |
| PS1 / PS2 / PS3 | Classification of electrical power as defined in [IEC 62368-1]. |
| Power Sinking Device (PSD) | Sink which draws power but has no other USB or Alternate Mode communication function e.g., a power bank. |
| Ra | Prior to application of VCONN, a powered cable applies a pull-down resistor Ra on its VCONN pin. |
| Rd | Pull-down resistor on the USB Type-C CC wire used to indicate that the Port is a Sink [USB-C]. |
| Re-Attach | Attach of the Port Pair by a cable after a previous Detach. |
| Re-Negotiate / Re-Negotiated / Re-Negotiation | A process wherein one of the Port Partners wants to alter the Negotiated Contract. |
| Request | Message used by a Sink Port to Negotiate a Contract; refers to either a Request/EPR_Request Message. |
| Request Data Object (RDO) | Data Object used by a Sink Port to Negotiate a Contract as a part of a Request/EPR_Request Message. |
| Responder | The receiver of a Command Request sent by an Initiator that replies with a Command response. |
| Revision | Major release of the USB Power Delivery specification. Each Revision will have variousVersions associated with it. |
| Revision 1.0 | **Deprecated** major Revision of the USB Power Delivery Specification. |
| Revision 2.0 | Superseded major Revision of the USB Power Delivery Specification as defined in [PD2], with which this specification is compatible. |
| Revision 3.x | Current major Revisions of the USB Power Delivery Specification. |
| Rp | Pull-up resistor on the USB Type-C CC wire used to indicate that the Port is a Source (see [USB-C]). |
| Shared Capacity Port | As defined in [USB-C]. Shared Capacity Ports can only be Managed Capability Ports |
| Signaling | Physical mechanism of transmitting bits. |
| Sink | The Port consuming power from VBUS; most commonly a USB Device. |
| Sink/Source | A Sink with the additional capability to function as a Source. This corresponds to a Dual-Role Power Port with Rd asserted on its CC wire. |
<!-- page 34 -->
| Term | Description |
|---|---|
| Sink Capabilities | Capabilities wanted by a Sink. |
| Sink Port | Port operating as a Sink. |
| Sink Standby | During Sink Standby the Sink reduces its current draw to minimum current. |
| Sink with Accessory Support | A Sink that can source VCONN, but does not source VBUS [USB-C]. |
| Soft Reset | A process that resets the PD communications engine to its default State. |
| Start of Packet (SOP) | K-code marker used to delineate the start of a Packet. |
| SOP Communication | Communication using SOP Packets also implies that an AMS is being followed. |
| SOP Packet | A Power Delivery Packet which starts with an SOP. |
| SOP' Communication | Communication with a Cable Plug using SOP' Packets, also implies that an AMS is being followed. |
| SOP' Packet | Any Power Delivery Packet which starts with an SOP' used to communicate with a Cable Plug. |
| SOP'' Communication | Communication with a Cable Plug using SOP'' Packets, also implies that an AMS is being followed. |
| SOP'' Packet | Any Power Delivery Packet which starts with an SOP'' used to communicate with a Cable Plug when SOP' Packets are being used to communicate with the other Cable Plug. |
| SOP' | K-code marker used for communication between a Port and a Cable Plug. See also SOP. |
| SOP'' | K-code marker used for communication between a Port and a Cable Plug. See also SOP. |
| SOP* | Used to generically refer to K-code markers: SOP, SOP' and SOP''. See also SOP. |
| SOP* Communication | Communication using SOP* Packets, also implies an AMS is being followed. |
| SOP* Packet | A term referring to any Power Delivery Packet starting with either SOP, SOP', or SOP''. |
| Source | The Port supplying power over VBUS. |
| Source/Sink | A Source with the additional capability to act as a Sink. This corresponds to a Dual-Role Power Port with Rp asserted on its CC wire. |
| Source Capabilities | Capabilities offered by a Source. |
| Source Port | Port operating as a Source. |
| Standard Power Range (SPR) | Only the Source_Capabilities and the Request Messages are allowed to Negotiate SPR Explicit Contracts. The EPR Messages (the EPR_Source_Capabilities Message and the EPR_Request Message) are not allowed to be used while in SPR Mode. |
| SPR AVS | An SPR Source whose output voltage can be adjusted to an operating voltage within its Advertised range as exposed by the SPR AVS APDO. |
| SPR AVS Mode | A SPR Source, currently operating in an SPR AVS Contract, is said to be operating in SPR AVS Mode. |
| SPR Capabilities | An SPR Capabilities Message (Source_Capabilities Message or Sink_Capabilities Message) has at least one Power Data Object for 5V followed by up to 6 additional Power Data Objects. |
| SPR Contract | Explicit Contract Negotiated, in SPR Mode, based on SPR PDOs and APDOs. |
| SPR Mode | The classic Mode of PD operation where Explicit Contracts are Negotiated using SPR PDOs and APDOs. |
| SPR PDO / SPR APDO | A PDO offered in SPR Mode. |
| PPS Mode | A power supply, currently operating in a PPS Contract, is said to be operating in PPS Mode. |
| SPR Sink | A Sink which only supports SPR Mode and does not support EPR Mode. |
| SPR Source | A Source which only supports SPR Mode and does not support EPR Mode. |
| Standard ID (SID) | 16-bit unsigned value assigned by the USB-IF to a given industry standards organization's specification. |
| Standard or Vendor ID (SVID) | Generic term referring to either a VID or a SID. SVID is used in place of the phrase "Standard or Vendor ID." |
| State | PD State machine State. |
| Structured Vendor Defined Message (SVDM) | A Vendor Defined Message where the contents and usage of bits 14...0 of the VDM Header are defined by this specification. |
| SVDM Header | The VDM Header for a Structured Vendor Defined Message. |
| Swap Standby | During Swap Standby the Source does not drive VBUS and the Sink's current draw does not exceed a minimum current. |
<!-- page 35 -->
| Term | Description |
|---|---|
| System Policy | Overall System Policy generated by the system, broken up into the policies required by each Port Pair to affect the System Policy. It is programmatically fed to the individual devices for consumption by their Policy Engines. |
| System Policy Manager (SPM) | Module running on the USB Host. It applies the System Policy through communication with PD Capable Sinks and Sources that are also Connected to the USB Host via USB. |
| Test Frame | Frame consisting of a Preamble, SOP*, followed by test data. |
| Test Pattern | Continuous stream of test data in a given sequence . |
| Tester | The Tester is assumed to be a piece of test equipment that manages the BIST testing process of a PD UUT. |
| Upstream Facing Port (UFP) | Indicates the Port's position in the USB topology typically a Port on a Device as defined in [USB-C]. At connection, the Port defaults to operation as a USB Device (when USB Communication is supported) and as a Sink. |
| UFP VDO | VDO returned by the UFP containing Capabilities. |
| Unit Interval (UI) | The time to transmit a single data bit on the wire. |
| Unchunked | See Unchunked Extended Message. |
| Unchunked Extended Message | Extended Message that has been transmitted whole without using Chunking. |
| Unexpected Message | Message that a Port supports but has been received in an incorrect State. |
| Unit Under Test (UUT) | The PD Device that is being tested by the Tester and responds to the initiation of a particular BIST test sequence. |
| Unrecognized Message | Message that a Port does not understand e.g., a Message using a **Reserved** Message type, a Message defined by a higher specification Revision than the Revision this Port supports, or an Unstructured Vendor Defined Message for which the VID is not recognized. |
| Unstructured Vendor Defined Message (UVDM) | A Vendor Defined Message where the contents of bits 14...0 of the VDM Header are undefined. |
| UVDM Header | The VDM Header for an Unstructured Vendor Defined Message. |
| Unsupported Message | Message that a Port recognizes but does not support. This is a Message defined by the specification, but which is not supported by this Port. |
| USB Attached State | Synonymous with the [USB2] and [USB3] definition of the Attached State |
| USB Communication | Transfer of USB data Packets as defined in [USB2] and [USB3]. |
| USB Default Operation | Operation of a Port at Attach or after a Hard Reset where the DFP Source applies 5V on VBUS and the UFP Sink is operating at 5V as defined in [USB2], [USB3], [USB-C] or [USB BC]. |
| USB Device | Either a Hub or a Peripheral Device as defined in [USB2], [USB3] and [USB4]. |
| USB Host | The system where the USB Host controller is installed as defined in [USB2], [USB3] and [USB4]. |
| USB Powered State | Synonymous with the [USB2] and [USB3] definition of the powered State. |
| USB Safe State | State of the USB Type-C connector when there are pins to be re-purposed (see [USB-C]) so they are not damaged by and do not cause damage to their Port Partner. |
| USB Type-A | Term used to refer to any A plug or receptacle including USB Micro-A plugs and USB Standard- A plugs and receptacles. USB Micro-AB receptacles are assumed to be a combination of USB Type-A and USB Type-B. |
| USB Type-B | Terms used to refer to any B-plug or receptacle including USB Mini-B plugs, USB Micro-B plugs, and USB Standard-B plugs and receptacles, including the PD and non-PD versions. USB Micro-AB receptacles are assumed to be a combination of USB Type-A and USB Type-B. |
| USB Type-C / USB-C | Term used to refer to the USB Type-C connector plug, or receptacle as defined in [USB-C]. |
| USB Type-C Multi-Port Charger | A product that exposes multiple USB Type-C Source Ports for the purpose of charging multiple Connected USB Devices as defined in [USB-C]. |
| USB-C Port Control | Module in a PD Capable Device which controls Attach/Detach and either detects or sets the Rp value and contains the USB Type-C State machines. |
| USB4 Mode | Device is operating in a Mode as defined in [USB4]. |
| Variable Supply | A power supply that has an output voltage that varies beyond the Fixed Supply range. This is exposed by the Variable Supply PDO. |
| VBUS | The VBUS wire delivers power from a Source to a Sink. |
<!-- page 36 -->
| Term | Description |
|---|---|
| VCONN | Once the connection between USB Host and Device is established, the CC pin (CC1 or CC2) in the receptacle that is not Connected via the CC wire through the standard cable is re-purposed to Source VCONN to power circuits in a Cable Plug, VCONN Powered Accessory or VCONN Powered USB Device (see [USB-C]). |
| VCONN Powered Accessory (VPA) | An accessory that is powered from VCONN to operate in an Alternate Mode (see [USB-C]). |
| VCONN Powered USB Charge Through Device (CT-VPD) | A CT-VPD is a VPD with an additional Port for connecting a Source (e.g., a Charger) as defined in [USB-C]. |
| VCONN Powered USB Device (VPD) | A captive cable USB Device that can be powered by either VCONN or VBUS as defined in [USB-C]. The term VPD refers to either a VPD or a CT-VPD with no Charger Connected. |
| VCONN Source | The USB Type-C Port responsible for sourcing VCONN. |
| VCONN Swap | Process of exchanging the VCONN Source between Port Partners. |
| Vendor Defined Message (VDM) | PD Data Message defined for vendor/standards usage. These are further partitioned into Structured Vendor Defined Messages, where Commands are defined in this specification, and Unstructured Vendor Defined Messages which are entirely vendor defined. |
| VDM Header | The first Data Object following the Message Header in a Vendor Defined Message. |
| VDO | See Vendor Data Object. |
| Vendor Data Object | Data Object used to send Vendor specific information as part of a Message. |
| Vendor Defined Extended Message (VDEM) | PD Extended Message defined for vendor/standards usage. A VDEM does not define any structure and Messages can be created in any manner that the vendor chooses. |
| Vendor ID (VID) | 16-bit unsigned value assigned by the USB-IF to a given Vendor. |
| Version | A minor release of the USB Power Delivery specification associated with a particular Revision. Version numbers are also defined in VDMs. |
| VI | Same as power (i.e., voltage × current = power) |

337
USB_PD_R3.2/03-port-power-requirements.md Normal file
View file

@ -0,0 +1,337 @@
<!-- page 37 -->
# Chapter 3. Port Power Requirements
## 3.1. Introduction
Power Requirements define voltages and current ranges that are offered by compliant USB Power Delivery Source Ports and used by compliant USB Power Delivery Sink Ports. Power Requirements enable a collection of interoperable power sources to function with a variety of powered devices in a standard and compliant ecosystem. Power Requirements are generally defined based on a Port's PDP Rating and the Source PDPs (Port Guaranteed PDP, Port Maximum PDP, Port Present PDP) described in Section 6.4.10. The Source Port PDP Rating is the Port Maximum PDP described in Section 6.4.10 and the Sink Port PDP Rating is the maximum PDP the Sink can utilize described in Section 6.5.16. The PDP Rating of a product with multiple Source ports is the highest Port Maximum PDP from the individual Source Ports.
Note: All of the Power Requirements defined in this chapter are for each individual Port.
## 3.2. Source Port Power Requirements
A Source Port is defined as a Guaranteed Capability Port or a Managed Capability Port. For all of the defined requirements, the Capabilities a Source exposes are based on the Port Maximum PDP, or if power constrained, the Port Present PDP.
### 3.2.1. General Source Port Requirements
The following are general Requirements for every Source Port.
1. The Maximum current for a Fixed or Variable PDO is based on the Port Present PDP (x/voltage). The Maximum current **May** be RoundUp or RoundDown to the nearest 10mA.
2. A Source **Shall Not** Advertise a current for a Fixed PDO that would result in the maximum power for that PDO (Voltage × Maximum Current) > maximum power of a higher voltage Fixed PDO.
3. Maximum power for Battery PDOs **Shall** be ≤ PDP Rating and the value can be rounded down.
4. The Maximum current for the SPR Programmable Power Supply (PPS) APDO **Shall** be as defined in Table 3.4.
a. Note: When the PPS Power Limited bit is set in the PPS APDO, the output current is as defined in Table 3.4. However, the Programmable Power Supply **May** limit its output current so that the product of its actual output voltage times the output current does not exceed the Port Present PDP.
b. If a 9V Prog, 15V Prog or 20V Prog Programmable Power Supply APDO is advertised, the maximum current **Shall** be RoundDown (x/Prog Voltage) to the nearest 50mA. When the PPS Power Limited bit is clear, the Source **Shall** provide this current at Maximum Voltage.
5. The first Source Capabilities, when in a Default or Implicit Contract, **Shall** set the Maximum Current of the 5V Fixed PDO ≥ the USB Type-C Current advertised by Rp.
6. The special case of a Source offering no capabilities (0mA or 0W) is described in Section 7.9.1.5.
### 3.2.2. Guaranteed Capability Port
A Guaranteed Capability Port is a Port that, with the exception of a fault condition or a Cable power rating limitation, is always able to provide the Port Maximum PDP. Simple wall chargers, self-powered docks, displays, etc. are typically Guaranteed Capability Ports.
<!-- page 38 -->
The following Requirements apply to a Guaranteed Capability Port:
1. A Guaranteed Capability Source Port **Shall** set Port Guaranteed PDP = Port Maximum PDP.
2. A Guaranteed Capability Source Port **Shall** set Port Present PDP = Port Maximum PDP except when
a. Port Maximum PDP > 60W and the cable VBUS Current Handling Capability = 3A. In this case, the Port **Shall** set Port Present PDP = 60W.
b. Port Maximum PDP > 100W (EPR Capable) and the Cable is not EPR Capable. In this case, the Port **Shall** set the Port Present PDP ≤ 100W. Note: Margin to 100W (e.g. 95W) is allowed and may be required to comply with safety standards. The actual Port Present PDP is product specific but should be as close to 100W as possible.
### 3.2.3. Managed Capability Port
A Managed Capability Port is a Port that may be constrained such that it does not always provide the Port Maximum PDP. Generally, these types of ports are on products where providing power is not the main function or they are Shared Capacity Ports where power is shared across multiple ports. Portable computers, mobile phones, tablets, shared-capacity docks and displays, etc. are typically Managed Capability Ports.
The following Requirements apply to a Managed Capability Port:
1. A Source **Shall** set Port Guaranteed PDP ≤ Port Maximum PDP.
2. A Source **Shall** set Port Present PDP ≤ Port Maximum PDP.
3. A Source **Shall** provide the PDO/APDOs required for its Port Present PDP as shown in Table 3.2.
4. A Managed Capability Source Port **Shall** limit Port Present PDP when
a. Port Present PDP would be > 60W but the cable VBUS Current Handling Capability = 3A. In this case, the Port **Shall** set Port Present PDP = 60W.
b. Port Present PDP would be > 100W (EPR Capable) and the Cable is not EPR Capable. In this case, the Port **Shall** set the Port Present PDP ≤ 100W.
Note: Margin to 100W is allowed (e.g. 95W) to prevent actual power delivered due to voltage variation to be > 100W. The actual Port Present PDP is product specific but should be as close to 100W as possible.
5. A Source **May** offer Source Capabilities with power less than the Port Present PDP. However, when the Attached Sink has set Mismatch in the Request RDO, the Source **Shall** provide Source Capabilities equivalent to the minimum of either the Source Port Present PDP or the maximum sinking capacity of the Attached Sink found in either Sink Capabilities (PDO) or Extended Sink Capabilities (PDP).
### 3.2.4. Source Voltage and Current Requirements
The following are minimum Requirements for Source Port voltages and currents:
1. The voltages and minimum currents an SPR Source **Shall** support based on the Port Maximum PDP are defined in Table 3.1.
2. The voltages and minimum currents an SPR Source **Shall** support based on the Port Present PDP are defined in Table 3.2.
3. Each SPR PDO and APDO **Shall** only be available if it were required for the Port Maximum PDP as shown in Table 3.1.
<!-- page 39 -->
Figure 3.1 shows the **Required** voltage and minimum current for each SPR Fixed PDO based on Port Maximum PDP that is described in Table 3.1.
**Figure 3.1. SPR Required Source Power Rule Illustration for Fixed PDOs**
![Figure 3.1. SPR Required Source Power Rule Illustration for Fixed PDOs](03-port-power-requirements/figure-3.1.png)
**Table 3.1. SPR Source Voltages and Minimum Currents based on Port Maximum PDP**
| Port Maximum PDP Rating (W) | 5V Fixed (A) | 9V Fixed (A) | 15V Fixed (A) | 20V Fixed (A) | SPR AVS² (A) |
|---|---|---|---|---|---|
| 0.5 ≤ x ≤ 15 | PDP÷5 | - | - | - | - |
| 15 < x ≤ 27 | 3 | PDP÷9 | - | - | - |
| 27 < x ≤ 45 | 3 | 3 | PDP÷15 | - | Max Voltage =15V<br>Max Current (9-15V) = 15V Fixed PDO Max Current |
| 45 < x ≤ 100 | 3 | 3 | 3 | PDP÷20¹ | Max Voltage = 20V<br>Max Current (9-15V) = 15V Fixed PDO Max Current<br>Max Current (15-20V) = 20V Fixed PDO Max Current |
1. Currents > 3A assume the Cable VBUS Current Carrying Capability is capable of the Port Maximum PDP. When it is not, Port Present PDP is limited by the cable. Refer to Table 3.2 for this case.
2. The Sink is allowed to Request up to the 20V Fixed Supply Max Current when the requested voltage from the AVS APDO is 15.0V.
3. '-' indicates PDO or APDO is not allowed.
<!-- page 40 -->
**Table 3.2. SPR Voltages and Minimum Currents when Port Present PDP < Port Maximum PDP**
| Port Present PDP (W) | 5V Fixed (A) | 9V Fixed (A) | 15V Fixed (A) | 20V Fixed (A) | SPR AVS³,⁴ (A) |
|---|---|---|---|---|---|
| 0.5≤ x ≤ 15 | PDP÷5 | PDP÷9³ | PDP÷15³ | PDP÷20³ | Max Voltage = Max Fixed PDO Voltage¹ |
| 15 < x ≤ 27 | 3 | PDP÷9 | PDP÷15 | PDP÷20 | Max Current (9-15V) = 15V Fixed PDO Max Current<br>Max Current (15-20V) = 20V Fixed PDO Max Current |
| 27 < x ≤ 45 | 3 | 3 | PDP÷15 | PDP÷20 | Max Current (9-15V) = 15V Fixed PDO Max Current<br>Max Current (15-20V) = 20V Fixed PDO Max Current |
| 45 < x ≤ 100³ | 3 | 3 | 3 | PDP÷20 | Max Current (9-15V) = 15V Fixed PDO Max Current<br>Max Current (15-20V) = 20V Fixed PDO Max Current |
1. SPR AVS APDO **Shall** only be available if the 15V Fixed PDO is available.
2. > 60W Port Present PDP requires a 5A cable.
3. This PDO and/or APDO is optional for Port Present PDP ≤ 15W.
4. The Sink is allowed to Request up to the 20V Fixed Supply Max Current when the requested voltage from the AVS APDO is 15.0V
The minimum **Required** Source Capabilities described in Table 3.1 and Table 3.2 can be generalized based on the Port Present PDP by:
- 5V, 9V, and 15V SPR Fixed PDOs
- PDO Maximum Current = Minimum( 3A, Port Present PDP ÷ Fixed PDO Voltage )
- 20V SPR Fixed PDO
- PDO Maximum Current = Minimum( Cable Rating, Port Present PDP ÷ Fixed PDO Voltage )
- SPR AVS
- 9V to 15V maximum current = 15V Fixed PDO Maximum Current
- 15V to 20V maximum Current = 20V Fixed PDO Maximum Current
Table 3.3 shows examples of the SPR Source Capabilities = advertised based on Port Present PDP from Table 3.2.
**Table 3.3. Examples of Required SPR Source Capabilities when Port Present PDP < Port Maximum PDP**
| Port Maximum PDP (W) | Cable Rating (A) | Port Present PDP (W) | Offers: 5V Fixed (A) | Offers: 9V Fixed (A) | Offers: 15V Fixed (A) | Offers: 20V Fixed (A) | Offers: SPR AVS (A) |
|---|---|---|---|---|---|---|---|
| 80 | 5 | 65 | 3 | 3 | 3 | 3.25 | 9V - 15V: 3<br>15V - 20V: 3.25 |
| 80 | 5 | 40 | 3 | 3 | 2.67 | 2 | 9V - 15V: 2.67<br>15V - 20V: 2 |
| 80 | 3 | 40 | 3 | 3 | 2.67 | 2 | 9V - 15V: 2.67<br>15V - 20V: 2 |
| 80 | 5 | 20 | 3 | 2.22 | 1.33 | 1 | 9V - 15V: 1.33<br>15V - 20V: 1 |
| 80 | 3 | 20 | 3 | 2.22 | 1.33 | 1 | 9V - 15V: 1.33<br>15V - 20V: 1 |
| 40 | 5 | 20 | 3 | 2.22 | 1.33 | Not offered | 9V - 15V: 1.33 |
<!-- page 41 -->
| Port Maximum PDP (W) | Cable Rating (A) | Port Present PDP (W) | 5V Fixed (A) | 9V Fixed (A) | 15V Fixed (A) | 20V Fixed (A) | SPR AVS (A) |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 40 | 3 | 20 | 3 | 2.22 | 1.33 | Not offered | 9V - 15V: 1.33 |
| 80 | 3 | 15 | 3 | 1.67<sup>1</sup> | 1<sup>1</sup> | 0.75<sup>1</sup> | 9V - 15V: 1<sup>1</sup><br>15V - 20V: 0.75<sup>2</sup> |
| 40 | 3 | 15 | 3 | 1.67<sup>1</sup> | 1<sup>1</sup> | Not offered | 9V - 15V: 1<sup>1</sup> |
1. This Capability is **Optional** at this Port Present PDP and **May** be offered at this Port Present PDP if the Fixed 15V PDO is offered.
2. This Capability is **Optional** at this Port Present PDP and **May** be offered at this Port Present PDP if the Fixed 20V PDO is offered.
### 3.2.5. Optional Source Voltage/Currents
#### 3.2.5.1. Fixed, Variable and Battery Supply
In addition to the voltages and currents specified in Section 3.2.4, an SPR Source **May** Optionally supply additional voltages and increased currents.
While allowed, the use of **Optional** voltages and currents is strongly discouraged to avoid user confusion. **Optional** voltages or currents allow Sinks that might perform differently with a Source with an **Optional** voltage or current than with a Source with an equivalent Port Maximum PDP but without the **Optional** voltage or current.
The following are Requirements apply to **Optional** Fixed, Variable, and Battery PDOs:
1. A Source **Shall Not** Advertise an optional Fixed PDO voltage > 9V.
2. A Source **Shall** only Advertise a Variable or Battery PDO with a Maximum Voltage ≤ the highest offered Fixed PDO voltage with allowed variance (≤ 1.05 × Fixed PDO Voltage)
3. A Source **Shall Not** Advertise an optional Fixed PDO voltage > the highest **Required** Fixed Voltage PDO in Table 3.1.
4. A Source **May** offer a Variable PDO, a Battery PDO, or a higher Maximum Current in a Fixed PDO than that found in Table 3.1 and Table 3.2. The following Requirements apply:
a. A Source **Shall** not Advertise a Maximum Current for a Fixed PDO > the current defined by the Port Present PDP in Table 3.1 and Table 3.2.
b. A Source **Shall Not** Advertise a Maximum Current for a Fixed PDO that would result in the maximum power for that PDO exceeding the maximum power of the next higher voltage required Fixed PDO (5V, 9V, 15V, or 20V) as specified in Table 3.1 and Table 3.2.
c. A Source **Shall Not** Advertise a Maximum Current for a Variable PDO that would result in the maximum power for that PDO (Maximum Voltage × Maximum Current) exceeding the maximum power (1.05 × Voltage × Maximum Current) of the next higher voltage required Fixed PDO (5V, 9V, 15V, or 20V) as specified in Table 3.1 and Table 3.2. The 1.05 factor accounts for the ±5% voltage tolerance of Fixed PDOs.
d. A Source **Shall Not** Advertise a Maximum Power for a Battery PDO that would result in the maximum power for that PDO exceeding the maximum power (1.05 × Voltage × Maximum Current) of the next higher voltage required Fixed PDO (5V, 9V, 15V, or 20V) as specified in Table 3.1 and Table 3.2. The 1.05 factor accounts for the ±5% voltage tolerance of Fixed PDOs.
5. EPR Capable Sources **Shall Not** implement optional Fixed PDOs.
6. An EPR Capable Source **Shall** only implement a Variable or Battery PDO as an SPR PDO. SPR Variable and Battery PDOs are allowed in EPR Mode.
<!-- page 42 -->
#### 3.2.5.2. SPR Programmable Power Supply (PPS)
Programmable Power Supply (PPS) is **Optional**. When included, the voltages and currents a PPS **Shall** support are as defined in Table 3.4.
**Table 3.4. SPR PPS APDOs based on the Port Maximum PDP**
| Port Maximum PDP (W) | Prog Voltage = 9V<sup>3,4</sup> (A) | Prog Voltage = 15V<sup>3,4</sup> (A) | Prog Voltage = 20V<sup>3,4</sup> (A) |
| --- | --- | --- | --- |
| x ≤ 15 | - | - | - |
| 15 < x < 27 | PDP÷9<sup>1</sup> | - | - |
| 27 | 3 | - | - |
| 27 < x < 45 | 3<sup>2</sup> | PDP÷15<sup>1</sup> | - |
| 45 | - | 3 | - |
| 45 < x < 60 | - | 3<sup>2</sup> | PDP÷20<sup>1</sup> |
| 60 | - | - | 3 |
| 60 < x < 100 | - | - | PDP÷20<sup>1</sup> |
| 100 | - | - | 5 |
1. The PPS APDOs Maximum Current field **Shall** Advertise RoundDown( PDP ÷ Prog Voltage ) to the nearest 50mA.
2. The PPS APDOs Maximum Current field **Shall** Advertise at least 3A. When the cable VBUS Current Handling Capability = 5A, the Maximum Current field **May** Advertise up to RoundDown( PDP ÷ Prog Voltage ) to the nearest 50mA.
3. See Table 4.2 for the voltage ranges defined for the PPS Prog APDOs.
4. Applies to PPS APDOs regardless of value of the PPS Power Limited bit.
5. '-' indicates APDO is not allowed.
#### 3.2.5.3. Extended Power Range (EPR)
Support of EPR Mode is **Optional**. An EPR Capable Port has a Port Maximum PDP > 100W and ≤ 240W.
Table 3.5 and Table 3.6 define the requirements for EPR Source Ports.
The following Requirements apply to an EPR Capable Source Port (EPR Source Port):
1. An EPR Source Port **May** operate in either SPR Mode or EPR Mode when providing power ≤ 100W.
2. An EPR Source Port **May** be implemented as a Managed Capability Port or Guaranteed Capability Port.
3. An EPR Source Port, operating in SPR Mode, **May** Advertise the SPR 20V Fixed PDO with < 5A (< 100W) to avoid potentially violating external safety regulations. This value should be as close as possible to 100W if not otherwise limited by Port Present PDP.
4. When operating in EPR Mode, an EPR Source Port with a Port Present PDP ≥ 100W **Shall** offer 5A in the 20V Fixed PDO.
5. When the Attached cable is not an EPR Capable cable, an EPR Capable Source **Shall** only operate in SPR Mode.
6. When in EPR Mode, an EPR Source Port that supports PPS **Shall** offer the SPR Fixed 20V PDO and PPS 20V Prog APDO at the Port Present PDP, up to 100W.
7. An EPR Source Port in an EPR AVS Contract **Shall** stay within the power offered in the PDP Field from the EPR AVS APDO defined in Table 6.16 and **Shall** Reject any Request whose operating current exceeds (PDP ÷ requested voltage) or 5A.
Figure 3.3 shows the definition of the valid operating range for an EPR Source operating in an AVS Explicit Contract based on the PDP Field.
<!-- page 43 -->
Figure 3.2 combined with Figure 3.1 shows the minimum current that an EPR Source **Shall** support at each EPR Fixed PDO for a given Port Maximum PDP.
**Figure 3.2. EPR Source Power Rule Illustration for Fixed PDOs**
![Figure 3.2. EPR Source Power Rule Illustration for Fixed PDOs](03-port-power-requirements/figure-3.2.png)
**Table 3.5. EPR Source Capabilities based on the Port Maximum PDP**
| Port Maximum PDP (W) | 28V Fixed (A) | 36V Fixed (A) | 48V Fixed (A) | EPR AVS<sup>2</sup> (A) |
| --- | --- | --- | --- | --- |
| 100 < x ≤ 140 | PDP÷28 | - | - | Max Voltage = 28V<br>Available Current (15-28V) = PDP ÷ AVS voltage (maximum of 5A) |
| 140 < x ≤ 180 | 5 | PDP÷36 | - | Max Voltage = 36V<br>Available Current (15-36V) = PDP ÷ AVS voltage (maximum of 5A) |
| 180 < x ≤ 240 | 5 | 5 | PDP÷48 | Max Voltage = 48V<br>Available Current (15-48V) = PDP ÷ AVS voltage (maximum of 5A) |
1. '-' indicates PDO or APDO is not allowed.
2. The current available for a given AVS voltage is as indicated in this column. The current defined here is describing the top edge of the **Valid** Operating Region as illustrated in Figure 3.3. The AVS APDO does not have a Maximum Current field, so the maximum current is calculated from the Port Present PDP.
<!-- page 44 -->
**Table 3.6. EPR Source Capabilities when Port Present PDP < Port Maximum PDP**
| Port Present PDP (W) | 28V Fixed<sup>1</sup> (A) | 36V Fixed<sup>1</sup> (A) | 48V Fixed<sup>1</sup> (A) | EPR AVS (A) |
| --- | --- | --- | --- | --- |
| 7.5 < x ≤ 27 | PDP÷28<sup>2</sup> | PDP÷36<sup>2</sup> | PDP÷48<sup>2</sup> | Max Voltage = Max Fixed PDO Voltage<sup>3</sup><br>Available Current = PDP ÷ AVS Voltage (maximum of 5A) |
| 27 < x ≤ 45 | PDP÷28 | PDP÷36<sup>2</sup> | PDP÷48<sup>2</sup> | Max Voltage = Max Fixed PDO Voltage<sup>3</sup><br>Available Current = PDP ÷ AVS Voltage (maximum of 5A) |
| 45 < x ≤ 60 | PDP÷28 | PDP÷36 | PDP÷48<sup>2</sup> | Max Voltage = Max Fixed PDO Voltage<sup>3</sup><br>Available Current = PDP ÷ AVS Voltage (maximum of 5A) |
| 60 < x ≤ 75 | PDP÷28 | PDP÷36 | PDP÷48 | Max Voltage = Max Fixed PDO Voltage<sup>3</sup><br>Available Current = PDP ÷ AVS Voltage (maximum of 5A) |
| 75 < x ≤ 100 | PDP÷28 | PDP÷36 | PDP÷48 | Max Voltage = Max Fixed PDO Voltage<sup>3</sup><br>Available Current = PDP ÷ AVS Voltage (maximum of 5A) |
| 100 < x ≤ 140 | PDP÷28 | PDP÷36 | PDP÷48 | Max Voltage = Max Fixed PDO Voltage<sup>3</sup><br>Available Current = PDP ÷ AVS Voltage (maximum of 5A) |
| 140 < x ≤ 180 | 5 | PDP÷36 | PDP÷48 | Max Voltage = Max Fixed PDO Voltage<sup>3</sup><br>Available Current = PDP ÷ AVS Voltage (maximum of 5A) |
| 180 < x ≤ 240 | 5 | 5 | PDP÷48 | Max Voltage = Max Fixed PDO Voltage<sup>3</sup><br>Available Current = PDP ÷ AVS Voltage (maximum of 5A) |
1. Each EPR Fixed PDO is only available if it were required for the Port Maximum PDP as shown in Table 3.5.
2. This PDO is **Optional** for this Port Present PDP.
3. This APDO is **Required** when an EPR Fixed PDO is offered.
EPR Source Capabilities described in Table 3.5 and Table 3.6 can be generalized based on the Port Present PDP by:
- For each Fixed PDO
- PDO Maximum Current = Minimum( 5A, PDP ÷ Fixed PDO Voltage )
- 48V Fixed PDO is not allowed if Port Maximum PDP ≤ 180W and otherwise optional if Port Present PDP ≤ 60W.
- 36V Fixed PDO is not allowed if Port Maximum PDP ≤ 140W and otherwise optional if Port Present PDP ≤ 45W.
- 28V Fixed PDO is optional if Port Present PDP ≤ 27W.
- EPR AVS
- PDO Maximum Voltage = Maximum offered Fixed PDO Voltage
- PDO Minimum Voltage = 15V
- PDO PDP = Port Present PDP
Table 3.7 shows examples of the SPR Source Capabilities = advertised based on Port Present PDP from Table 3.2.
**Table 3.7. Examples of EPR Source Capabilities when Port Present PDP <Port Maximum PDP**
| Port Maximum PDP (W) | Port Present PDP (W) | 28V Fixed(A) | 36V Fixed(A) | 48V Fixed(A) | EPR AVS max Voltage (V) and Power (W) |
| --- | --- | --- | --- | --- | --- |
| 200 | 108 | 3.86 | 3 | 2.25 | 48V@108W |
| 160 | 108 | 3.86 | 3 | Not offered | 36V@108W |
| 120 | 108 | 3.86 | Not offered | Not offered | 28V@108W |
| 200 | 72 | 2.57 | 2 | 1.5 | 48V@72W |
| 160 | 72 | 2.57 | 2 | Not offered | 36V@72W |
| 120 | 72 | 2.57 | Not offered | Not offered | 28V@72W |
| 200 | 36 | 1.29 | 1<sup>1</sup> | 0.75<sup>1</sup> | 48V@36W<sup>1</sup> |
| 160 | 36 | 1.29 | 1<sup>1</sup> | Not offered | 36V@36W<sup>1</sup> |
<!-- page 45 -->
| Port Maximum PDP (W) | Port Present PDP (W) | Offers | | | |
| --- | --- | --- | --- | --- | --- |
| | | 28V Fixed(A) | 36V Fixed(A) | 48V Fixed(A) | EPR AVS max Voltage (V) and Power (W) |
| 120 | 36 | 1.29 | Not offered | Not offered | 28V@36W |
1. These Capabilities are not required but may be offered at this Port Present PDP.
**Figure 3.3. Valid EPR AVS Operating Region**
![Figure 3.3. Valid EPR AVS Operating Region](03-port-power-requirements/figure-3.3.png)
## 3.3. Dynamic Power Supply (DPS)
The Source power Requirements defined in Section 3.2.4 and Section 3.2.5 **Shall** apply to a DPS Port, together with the following additional Requirements:
1. A DPS Port **Shall** guarantee tDpsColdStart at Maximum PDP provided the following conditions are met:
a. The unit is starting from a cold start. This means the components inside the unit are at ambient temperature, and the ambient temperature **Should** be around 25°C.
b. The Source Port is not sourced by an internal Battery, per the Source Inputs Field of the Source Capabilities Extended Message.
c. No other events arise that may require the Source to send New Source Capabilities (e.g. a new Request from the Sink).
2. The Source **Should** not send updated Source Capabilities within tDpsRegular or tDpsColdStart, with the following exceptions:
a. If the Source just entered its First Explicit Contract with the Sink, it **May** send an updated Source Capabilities Message, provided the Sink sets the Capability Mismatch bit, and the Source can increase the power offered.
b. The updated Source Capabilities are due to sharing power with another Port when the Source is a shared capability Port.
<!-- page 46 -->
c. Events arise that may require the Source to send New Source Capabilities (e.g. a new Request from the Sink).
d. Parameters other than the temperature affect the Source Capabilities.
**Figure 3.4. Example of a DPS temperature profile**
![Figure 3.4. Example of a DPS temperature profile](03-port-power-requirements/figure-3.4.png)
A DPS Source uses Alert Message, Status Message, and Source Info Message fields to inform a Sink about changes in its Capabilities. See Section 7.14 and Section 7.26 for additional details on requirements for these fields.
## 3.4. Sink Power Requirements
### 3.4.1. Sink Power Rule Considerations
The Sink Power Requirements are designed to ensure the best possible user experience when a given Sink is powered by a compliant Source that only supplies the **Required** voltages and currents.
Sinks are designed to use Sources with a matching or higher PDP Rating. The Sink Power Requirements are based on the following considerations:
- Low power Sources (e.g., 5V) are expected to be very common and will be used with Sinks designed for a higher PDP.
- Optimizing the user experience when Sources with a higher PDP Rating are used with low power Sinks.
<!-- page 47 -->
- Preventing Sinks that only function well (or at all) when using **Optional** voltages and currents.
### 3.4.2. Sink Requirements
The following Requirements apply to Sink RDO:
1. A Sink **Shall** set RDO Operational Current or RDO Maximum Power to result in power ≤ Sink Maximum PDP.
2. A Sink **Should** set Capabilities Mismatch when the voltage, current, or power being offered in Source Capabilities is insufficient for optimal operation or charging. A Sink **Shall** not set Capabilities Mismatch otherwise.
3. A Sink **Shall** set RDO Operational Current or Maximum Current as RoundDown to the nearest 10mA for Fixed/Variable/AVS PDO/APDO Supplies and 50mA for PPS APDO.
4. A Sink without a Battery **Shall** set Maximum Power for a Battery Supply RDO to ≤ Sink Operational PDP.
5. A Sink requiring no power from the Source, **Shall** send the 5V RDO with Operational Current set to 0mA.
The following Requirements apply to Sink Capabilities:
1. A Sink **Shall Not** Advertise Fixed PDO maximum voltages and currents that exceed the Sink_Capabilities_Extended Message SPR Sink Maximum PDP when in SPR Mode and EPR Sink Maximum PDP when in EPR Mode.
2. A Sink **Shall Not** Advertise Variable PDO maximum voltages and currents that exceed the Sink_Capabilities_Extended Message SPR Sink Maximum PDP when in SPR Mode and EPR Sink Maximum PDP when in EPR Mode.
3. A Sink **Shall Not** Advertise a Battery PDO maximum allowable power that exceeds the Sink_Capabilities_Extended Message SPR Sink Maximum PDP when in SPR Mode and EPR Sink Maximum PDP when in EPR Mode.
4. A Sink **Shall Not** Advertise a PPS APDO maximum allowable power that exceeds the Sink_Capabilities_Extended Message SPR Sink Maximum PDP when in SPR Mode and EPR Sink Maximum PDP when in EPR Mode.
5. A Sink **Shall Not** Advertise an AVS APDO maximum allowable power that exceeds the Sink_Capabilities_Extended Message SPR Sink Maximum PDP when in SPR Mode and EPR Sink Maximum PDP when in EPR Mode.
## 3.5. Sink with Acessory Support
The following Requirement applies to a Sink with Accessory Support:
1. When sourcing VCONN, a Sink with Accessory Support is considered a Source even though VBUS is not supplied. The Sink with Accessory Support **Shall** offer a single 5V PDO with the Maximum Current field set to 0mA for the purpose of allowing a VPA to enter an Alternate Mode.
## 3.6. PDUSB Device Requirements
A PDUSB Device **Shall** comply with the requirements defined in [PDUSB].

BIN
USB_PD_R3.2/03-port-power-requirements/figure-3.1.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 88 KiB

BIN
USB_PD_R3.2/03-port-power-requirements/figure-3.2.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 85 KiB

BIN
USB_PD_R3.2/03-port-power-requirements/figure-3.3.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 39 KiB

BIN
USB_PD_R3.2/03-port-power-requirements/figure-3.4.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 109 KiB

937
USB_PD_R3.2/04-power-delivery-electrical-requirements.md Normal file
View file

@ -0,0 +1,937 @@
<!-- page 48 -->
# Chapter 4. Power Delivery Electrical Requirements
Throughout this chapter, certain functionally equivalent electrical parameters are identified by different names depending on the Contract type (Fixed, AVS, PPS etc.), though their behavior is consistent across Contract type. To standardize terminology and reduce redundancy, the following table defines a set of aliases mapped to specific variables. The aliases will be used throughout this chapter and will collectively refer to each of the parameters it is aliasing. For example, any figure using the `vNew` alias represents an equivalent figure for `vSrcNew`, `vAvsNew`, and `vPpsNew`. The alias will not be used where the behavior does not apply to all aliased parameters.
**Table 4.1. Universal Aliases for PDO or APDO Variables**
| Alias | Fixed PDO Parameter | AVS APDO Parameter | PPS APDO Parameter |
| --- | --- | --- | --- |
| `iSlewNeg` | `iLoadReleaseRate` | `iLoadReleaseRate` | `iLoadReleaseRate` or `iPpsCLLoadReleaseRate` |
| `iSlewPos` | `iLoadStepRate` | `iLoadStepRate` | `iLoadStepRate` or `iPpsCLLoadStepRate` |
| `tSrcTransLarge` | -- | `tAvsSrcTransLarge` | `tPpsSrcTransLarge` |
| `tSrcTransSmall` | -- | `tAvsSrcTransSmall` | `tPpsSrcTransSmall` |
| `tTransient` | `tSrcTransient` | `tAvsTransient` | `tPpsTransient` |
| `vMaxVoltage` | -- | `vAvsMaxVoltage` | `vPpsMaxVoltage` |
| `vMinVoltage` | -- | `vAvsMinVoltage` | `vPpsMinVoltage` |
| `vNew` | `vSrcNew` | `vAvsNew` | `vPpsNew` |
| `vSlewNeg` | `vSrcSlewNeg` | `vAvsSlewNeg` | `vPpsSlewNeg` |
| `vSlewPos` | `vSrcSlewPos` | `vAvsSlewPos` | `vPpsSlewPos` |
| `vSmallStep` | | `vAvsSmallStep` | `vPpsSmallStep` |
| `vStep` | -- | `vAvsStep` | `vPpsStep` |
| `vValid` | `vSrcValid` | `vAvsValid` | `vPpsValid` |
## 4.1. Source Requirements
### 4.1.1. Behavioral Aspects
A USB PD Source is a device that supplies power over a USB connection using the USB Power Delivery protocol. It advertises available voltage and current levels, negotiates power contracts with Sinks, and adjusts its output accordingly. In addition to being a USB Type-C Source and following all [USB-C] defined behaviors, a USB PD Source must meet all requirements defined in this chapter.
### 4.1.2. Source Bulk Capacitance
The Source bulk capacitance consists of C1 and C2 as shown in. The switch (or Ohmic Interconnect) usually consists of one or two MOSFETs and **May** be part of the circuit implemented by the Source to control its VBUS Output Voltage Limit (OVL) as described in. The capacitance might be a single capacitor, a capacitor bank or distributed capacitance. If the power supply is dedicated to a single Port, the minimum bulk capacitance is defined as `cSrcBulk`. If the power supply is shared across multiple ports, the bulk capacitance is defined as `cSrcBulkShared`.
The Source bulk capacitance is allowed to change for a newly Negotiated power level. The capacitance change **Shall** occur before the Source is ready to operate at the new power level. During a Power Role Swap, the Initial Source **Shall** transition to Swap Standby before operating as the New Sink. Any change in bulk capacitance required to complete the Power Role Swap **Shall** occur during Swap Standby.
<!-- page 49 -->
**Figure 4.1. Placement of Source Bulk Capacitance**
![Placement of Source Bulk Capacitance](04-power-delivery-electrical-requirements/figure-4.1.png)
#### 4.1.2.1. Source PDOs or APDOs
Consistent with the Power Data Objects discussed in Section 6.4.1.3, the power supply PDO or APDO that are available as a Source in a USB Power Delivery System are:
- The Fixed Supply PDO exposes well-regulated fixed voltage power supplies. A Source **Shall** support at least one Fixed Supply PDO providing `vSafe5V`. The output voltage of a Fixed Supply **Shall** remain within the range defined by the relative tolerance `vSrcNew` and the absolute band `vSrcValid` as listed in Table 4.6 and described in Section 4.1.2.1.1
- The Variable Supply (non-Battery) PDO exposes less well-regulated Sources. The output voltage of a Variable Supply (non-Battery) **Shall** remain within the absolute maximum output voltage and the absolute minimum output voltage exposed in the Variable Supply PDO.
- The Battery Supply PDO exposes Batteries that can be Connected directly as a Source to VBUS. The output voltage of a Battery Supply **Shall** remain within the absolute maximum output voltage and the absolute minimum output exposed in the Battery Supply PDO.
- The Programmable Power Supply (PPS) and Adjustable Voltage Source (AVS) Augmented Power Data Object (APDO) expose a Source with an output voltage that can be adjusted programmatically over a defined range.
- For AVS, the output voltage **Shall** remain within a range defined by the relative tolerance `vAvsNew`, and the absolute band `vAvsValid`.
- For PPS, the output voltage **Shall** remain within a range defined by the relative tolerance `vPpsNew` and the absolute band `vPpsValid`. These limits are applicable as long as Operating Mode Flag (OMF) is 0. See Section 4.1.3.2.2 for OMF information.
##### 4.1.2.1.1. Voltage Regulation
This section applies to the Source while operating in any of the PDOs discussed on Section 4.1.2.1.
After a voltage transition is complete (i.e., after `tSrcReady`, `tSrcTransSmall` or `tSrcTransLarge` ) and during static load conditions, the Source output voltage **Shall** remain within the `vNew` or `vSafe5V` limits as applicable. The ranges defined by `vNew` and `vSafe5V` account for DC regulation accuracy, line regulation, load regulation, and output ripple.
During transient load conditions (defined by `iSlewPos` or `iSlewNeg`), the Source output voltage **Shall Not** go beyond
<!-- page 50 -->
the range specified by `vValid`. The amount of time the Source output voltage can be in the band between either `vNew` or `vSafe5V` and `vValid` **Shall Not** exceed `tTransient`. Refer to Table 4.6 for the output voltage tolerance specifications. Figure 4.2 illustrates the application of `vNew` and `vValid` after the voltage transition is complete.
The `vNew` and `vValid` limits **Shall Not** apply to VBUS during the VBUS discharge and switchover that occurs during a Fast Role Swap as described in Chapter 10.
**Figure 4.2. Application of vNew and vValid limits after tSrcReady or tSrcTransSmall or tSrcTransLarge**
![Application of vNew and vValid limits after tSrcReady or tSrcTransSmall or tSrcTransLarge](04-power-delivery-electrical-requirements/figure-4.2.png)
The Source output voltage **Shall** be measured at the connector receptacle. The stability of the Source is left to the discretion of the implementer; however, the design **Shall** account for the possibility that the Sink **May** introduce any load transient inside the constraints of the Contract, provided that the slew rate is between `iSlewPos` and `iSlewNeg`. The transient behavior of the load current is defined in Section 4.2.6.
In some systems it might be necessary to design the Source to compensate for the voltage drop between the output stage of the power supply electronics and the receptacle contact. The determination of whether compensation is necessary is left to the discretion of the Source implementation.
### 4.1.3. Source Transitions
#### 4.1.3.1. Fixed Voltage Transitions
The Source **Shall** transition VBUS from the starting voltage to the new voltage in a controlled manner. Figure 4.3 and Figure 4.4 illustrate the transition process for positive and negative fixed voltage transitions respectively. The following statements **Shall** be observed for fixed voltage transitions:
- The Negotiated new voltage (e.g., 5V, 9V, 15V, …) defines the nominal value for `vSrcNew`.
- During the positive transition the Source **Shall** be able to supply the Sink Standby current and the transient current to charge the total bulk capacitance on VBUS.
<!-- page 51 -->
- The slew rate of the positive transition **Shall Not** exceed `vSrcSlewPos` and the slew rate for a negative transition **Shall Not** exceed `vSrcSlewNeg`.
- The transitioning Source output voltage **Shall** settle within `vSrcNew` by `tSrcSettle`.
- The Source **Shall** be able to supply the Negotiated power level at the new voltage by `tSrcReady`.
- Voltage transitions follow these rules:
- The positive voltage transition **Shall** remain above `vSrcValid` (min) of the previous Explicit Contract and below `vSrcValid` (max) of the new Explicit Contract.
- The negative voltage transition **Shall** remain below `vSrcValid` (max) of the previous Contract and above `vSrcValid` (min) of the new Explicit Contract.
- The starting time, t0, in Figure 4.3 starts `tSrcTransition` after the last bit of the EOP of the `GoodCRC` Message has been received by the Source.
- Negative transitions to `vSafe0V` do not have the same requirements illustrated in Figure 4.4. See Section 4.1.5.5.
**Figure 4.3. Transition Envelope for Positive Voltage Transitions**
![Transition Envelope for Positive Voltage Transitions](04-power-delivery-electrical-requirements/figure-4.3.png)
<!-- page 52 -->
**Figure 4.4. Transition Envelope for Negative Voltage Transitions**
![Transition Envelope for Negative Voltage Transitions](04-power-delivery-electrical-requirements/figure-4.4.png)
#### 4.1.3.2. AVS/PPS Transitions
##### 4.1.3.2.1. Voltage Transitions
When in AVS or PPS Mode, the Source **Shall** transition VBUS over the defined voltage range in a controlled manner. The output voltage in the RDO defines the nominal value of the output voltage after completing a voltage transition. The following statements **Shall** be observed by an AVS Source and by a PPS Source when not in Current Limit (CL) Mode (see Section 4.1.3.2.2 ):
- Settle within the limits defined by `vNew` by `tSrcTransSmall` for steps smaller than or equal to `vSmallStep`.
- Settle within limits defined by `vNew` by `tSrcTransLarge` for steps larger than `vSmallStep`.
- Overshoot and undershoot **Shall not** exceed `vValid`.
- The voltage **May** change in a step-wise or linear manner and the slew rate of either type of change **Shall Not** exceed `vSlewPos` for voltage increases or `vSlewNeg` for voltage decreases.
- The nominal requested voltage equates to an integer number of LSB changes, which are defined as `vStep`.
- If an increase in voltage is requested, then the new voltage **Shall** be greater than or equal to the current voltage. See Section 4.1.3.2.6 for more details.
- If a decrease in voltage is requested, then the new voltage **Shall** be less than or equal to the current voltage. See Section 4.1.3.2.6 for more details.
- The voltage range is defined by the parameters `vMinVoltage` and `vMaxVoltage`, corresponding to the Minimum Voltage and Maximum Voltage fields of the respective APDOs. Table 4.2 and Table 4.3 show the valid voltage ranges for PPS and SPR AVS.
<!-- page 53 -->
**Table 4.2. SPR Programmable Power Supply (PPS) Voltage Ranges**
| Fixed Nominal Voltage | 9V Prog | 15V Prog | 20V Prog |
| --- | --- | --- | --- |
| Maximum Voltage | 11V | 16V | 21V |
| Minimum Voltage | 5V | 5V | 5V |
**Table 4.3. SPR Adjustable Voltage Supply (AVS) Voltage Ranges**
| AVS Voltage Range | 15V | 20V |
| --- | --- | --- |
| Maximum Voltage | 15V | 20V |
| Minimum Voltage | 9V | 9V |
Table 4.4 show the valid voltage ranges for EPR AVS.
**Table 4.4. EPR Adjustable Voltage Supply (AVS) Voltage Ranges**
| AVS Voltage Range | 28V | 36V | 48V |
| --- | --- | --- | --- |
| Maximum Voltage | 28V | 36V | 48V |
| Minimum Voltage | 15V | 15V | 15V |
Figure 4.5 illustrates the output voltage behavior of PPS and an AVS Source in response to positive and negative voltage change requests.
**Figure 4.5. PPS/AVS Voltage Transitions**
![PPS/AVS Voltage Transitions](04-power-delivery-electrical-requirements/figure-4.5.png)
While in PPS Mode and in the specific case of CL operation (see Section 4.1.3.2.2 ), the voltage might not change to a new requested level, since in this Mode it is the current that is being controlled by the Source (e.g., when the
<!-- page 54 -->
Sink is directly charging a Battery from VBUS). Note: the Source cannot rely on checking the voltage on VBUS to determine when its power supply is ready to send a `PS_RDY` Message.
If the Sink negotiates for a new PDO or APDO, then the transition between the current PDO or APDO and the new PDO or APDO **Shall** occur as described in Section 4.5.
Section 4.1.4 lists transitions that are exempt from the `vSlewNeg` and `vSlewPos` limits.
See Section 4.1.3.2.5 for output voltage ripple limits.
See Section 4.1.3.2.6 for output voltage and current DNL step adjustments.
##### 4.1.3.2.2. PPS Operation in Current Limit (CL) Mode
The Programmable Power Supply operating in PPS Mode Current Limit (CL) Mode **Shall** observe the following:
- If the Sink attempts to draw current exceeding the Operating Current specified in the RDO, the Source **Shall** limit its output to a level within the tolerance defined by `iPpsCLNew`.
- The programming step size for the Operating Current is `iPpsCLStep`, and whenever a new current is requested, the settling time is `tPpsCLProgramSettle`.
- The Current Limit programmability ranges from `iPpsCLMin` and the Maximum Current value in the PPS APDO.
- A Source which receives a Request for current below `iPpsCLMin` **Should** reject the Request.
- A Source that accepts a Request for current below `iPpsCLMin` **Shall** set its Current Limit at 1A.
- A PPS Source that is operating in Current Limit **Shall Not** change its set-point in a manner that exceeds `iPpsCLLoadStepRate` or `iPpsCLLoadReleaseRate`.
- If during CL Mode, the output voltage drops below `vPpsShutdown` the Source **May** send a Hard Reset and **Shall** discharge VBUS to `vSafe0V`, then resume USB Default Operation at `vSafe5V`.
- The Source **Shall Not** shut down or otherwise disrupt the available output power while in Current Limit Mode unless another protection mechanism as outlined in Section 4.1.5 is engaged to protect the Source from damage.
The response of a PPS to a load change depends on the Operating Mode of the PPS and the magnitude of the load change. These dependencies lead to one of four possible responses of a PPS to any load change as shown in. They are differentiated by the value of the PPS Status OMF (see Section 6.5.13), in the initial and final State of the load change.
**Table 4.5. PPS Status**
| OMF Initial | OMF Final | Operation |
| --- | --- | --- |
| 0 | 0 | Output Voltage maintained, transient range allowed as shown in insert Figure 4.6 |
| 0 | 1 | At the end of the transient, the feedback loop of the Source controls the VBUS Current, as opposed to the voltage, which is determined by the Sink (usually by the Sink's Battery).<br><br>The Current **Shall** settle within `iPpsCLNew` by `tPpsCVCLTransient`. During the transient itself the Current is allowed to be within `iPpsCVCLTransient`. |
| 1 | 0 | At the end of the transient, the feedback loop of the Source controls the VBUS Voltage, as opposed to the current.<br><br>During the transient the voltage **Shall** stay within `vPpsCLCVTransient`. After `tPpsCLCVTransient` the VBUS voltage **Shall** be within `vPpsNew`. |
| 1 | 1 | Output Current maintained. The transient range allowed is extended by `iPpsCLTransient`, and the settling time is `tPpsCLSettle`. After this period the allowed range is `iPpsCLNew`. |
<!-- page 55 -->
The relationship between PPS programmable output voltage and PPS programmable Current Limit is as shown in. The transition between the Constant Voltage Mode and the Current Limit Mode occurs between points a and b. The PPS Status OMF **Shall** be set or cleared within this region. When VBUS falls below the APDO Minimum Voltage (point c), the Source is allowed to disconnect.
**Figure 4.6. PPS Programmable Voltage and Current Limit**
![PPS Programmable Voltage and Current Limit](04-power-delivery-electrical-requirements/figure-4.6.png)
##### 4.1.3.2.3. PPS Operation in Constant Power
The tolerances along the Constant Power Curve **Shall Not** extend into the Guaranteed Capability Area shown in Figure 4.7 as the region inside the dashed line defined by PPS APDO Minimum Voltage (max), `vPpsNew` (min), and `iPpsCLNew` (min).
<!-- page 56 -->
**Figure 4.7. PPS Constant Power**
![PPS Constant Power](04-power-delivery-electrical-requirements/figure-4.7.png)
In the example above, the section between points a and b represents the constant power area of the CV/CL curve.
##### 4.1.3.2.4. Adjustable Voltage Supply Source Current
Unless otherwise noted, AVS **Shall** follow the same requirements as a Fixed Supply.
The maximum operating current the AVS shall supply is determined as follows:
- For SPR AVS APDOs, the maximum operating current is defined in the Maximum Current field of the 15V AVS APDO and the 20V AVS APDO in the SPR Source_Capabilities Message.
- For EPR AVS APDOs, the maximum operating current is calculated as the lower of the ((PDP field value) ÷ (Output Voltage)) or 5A whichever is lower. See Table 3.5.
##### 4.1.3.2.5. Source AVS/PPS Ripple
The AVS/PPS output voltage ripple is expected to exceed the magnitude of one or more LSB as shown in the Figure 4.8.
<!-- page 57 -->
**Figure 4.8. Expected PPS Ripple Relative to an LSB**
![Expected PPS Ripple Relative to an LSB](04-power-delivery-electrical-requirements/figure-4.8.png)
##### 4.1.3.2.6. Source DNL Tolerance
The PPS voltage and current discrete LSB steps have a DNL tolerance as shown in Figure 4.9. In absolute terms the step size of the LSB for both voltage and current is defined by vPpsStep / vAvsStep for voltage and iPpsCLStep for current. Several examples of Valid LSB steps are shown in Figure 4.9:
- The upper end of the DNL error (+1 LSB) shows the case where one step is effectively skipped.
- The lower end of the DNL error (-1 LSB) shows the case where the voltage or current set-point remained the same.
The ideal DNL is 0 LSB where the voltage or current step is exactly equal to the defined LSB step size.
The intent of DNL is to guarantee that changes to the voltage/current have the correct directionality, and that the maximum step size is clearly defined.
Note: The Source Should avoid scenarios where multiple consecutive steps have errors close to the Maximum and Minimum DNL.
<!-- page 58 -->
**Figure 4.9. Allowed DNL Errors and Tolerance of Voltage and Current in AVS/PPS Mode**
![Allowed DNL Errors and Tolerance of Voltage and Current in AVS/PPS Mode](04-power-delivery-electrical-requirements/figure-4.9.png)
### 4.1.4. Non-application of VBUS Slew Rate Limits
Scenarios where vSrcSlewPos and vPpsSlewPos VBUS slew rate limits do not apply and VBUS May transition faster than specified are as follows:
- When first applying VBUS after an Attach.
- When applying VBUS as part of a Power Role Swap to Source Power Role.
- When increasing VBUS from vSafe0V to vSafe5V during a Hard Reset.
- During a Fast Role Swap when the Initial Sink applies VBUS.
- When discharging VBUS to vSafe0V during a Hard Reset.
<!-- page 59 -->
- When discharging VBUS to vSafe0V as part of a Power Role Swap to Sink Power Role.
- When discharging VBUS to vSafe0V after a Detach.
- During a Fast Role Swap when the VBUS power Source Connected to the Hub UFP stops sourcing power.
### 4.1.5. Robust Source Operation
#### 4.1.5.1. Output Over-Current Protection
A Source **Shall** implement Over-Current Protection (OCP) in accordance with the applicable safety standards. The over-current protection May be dynamic depending on the Contract established with the Sink, but it **Shall Not** activate if the current being drawn is valid per the current Contract.
A Source Should attempt to send Hard Reset Signaling when OCP engages followed by an Alert Message indicating an OCP event when an Explicit Contract has been established. The over-current protection response May engage at either the Port or system level. Systems or ports that have engaged over-current protection Should attempt to resume USB Default Operation.
The Source **Shall** renegotiate with the Sink after choosing to resume USB Default Operation. The decision of how to renegotiate after an over-current event is left to the discretion of the Source implementation.
During the over-current response and subsequent system or Port shutdown, all affected Source ports operating with VBUS greater than vSafe5V **Shall** discharge VBUS to vSafe5V within tSafe5V and vSafe0V within tSafe0V.
#### 4.1.5.2. Output Over-Voltage Protection
Over-voltage protection (OVP) is left to the Source implementation to meet any applicable safety or reliability standards. Any OVP **Shall** account for vNew and vValid when establishing the threshold for OVP, irrespective of the type of Contract that is established with the Sink.
#### 4.1.5.3. Over-Temperature Protection
A Source Should implement Over-Temperature Protection (OTP) to prevent damage from temperature that exceeds the thermal capability of the Source. The definition of thermal capability and the monitoring locations used to trigger the OTP are left to the discretion of the Source implementation.
In order to avoid reaching an OTP event, a Source May proactively reduce the available power being offered to the Sink, even though this might be lower than the Source would be expected to offer during normal thermal operating conditions. Prior to reducing power, the Source Should generate an Alert Message indicating an Operating Condition Change and set the Temperature Status bit in the SOP Status Message to Warning (10b).
A Source Should attempt to send Hard Reset Signaling when OTP engages followed by an Alert Message indicating an OTP event once an Explicit Contract has been established. The OTP response May engage at either the Port or system level. Systems or ports that have engaged OTP Should attempt to resume USB Default Operation and May latch off to protect the Port or system.
The Source **Shall** renegotiate with the Sink after choosing to resume USB Default Operation. The decision of how to renegotiate after an over-temperature event is left to the discretion of the Source implementation.
During the OTP and subsequent system or Port shutdown, all affected Source ports operating with VBUS greater than vSafe5V **Shall** discharge VBUS to vSafe5V within tSafe5V and vSafe0V within tSafe0V.
#### 4.1.5.4. vSafe5V Externally Applied to Ports Supplying vSafe5V
A Power Delivery Source **Shall** be tolerant of vSafe5V being present on VBUS when simultaneously applying power to VBUS. Normal USB PD communication **Shall** be supported when this vSafe5V to vSafe5V connection exists.
<!-- page 60 -->
#### 4.1.5.5. Detach
A USB Detach is detected electrically using CC detection on the USB Type-C connector. When the Source is Detached, the Source **Shall** transition to vSafe0V within tSafe0V from when the Detach event occurred. During the transition to vSafe0V, the VBUS voltage **Shall** be below vSafe5V (max) within tSafe5V from when the Detach event occurred and **Shall Not** exceed vSafe5V max after this time.
Note: A USB-PD transmission by the Source during a disconnect event will delay disconnect detection by the Source.
### 4.1.6. Source Peak Current Operation
A Source that has the Fixed Supply PDO or AVS APDO Peak Current bits set **Shall** be designed to support one of the overload Capabilities defined in Table 6.18 respectively. The overload conditions are bound in magnitude, duration and duty cycle. When overload conditions occur, the Source is allowed the range of vSrcPeak (instead of vNew ) relative to the nominal value. See Figure 4.10. Note: A Source operating in PPS Mode cannot support peak currents, due to the CL requirements.
**Figure 4.10. Source Peak Current Overload**
![Source Peak Current Overload](04-power-delivery-electrical-requirements/figure-4.10.png)
Each overload period **Shall** be followed by a period of reduced current draw such that the rolling average current over the Overload Period field value with the specified Duty Cycle field value (see Section 6.4.1.3.13 ) **Shall Not** exceed the Negotiated current. This is calculated as:
Period of reduced current = (1 - (value in Duty Cycle field ÷100)) × value in Overload Period field
The Source May send a New Source_Capabilities Message with the Fixed Supply PDO or AVS APDO Peak Current bits set to `00b` to prohibit overload operation even if an overload capability was previously Negotiated with the Sink.
### 4.1.7. Source Capabilities Extended Parameters
Implementers can choose to make available certain characteristics of a Source Port as a set of Static and/or dynamic parameters to improve interoperability between external power sources and portable computing devices. The complete list of reportable Static parameters is described in full in. The following section offers additional details on some specific electrical parameters.
<!-- page 61 -->
#### 4.1.7.1. Load Step Slew Rate
The default load step slew rate is established at 150mA/µs. A Source **Shall** meet the following requirements under the load step reported in the Source_Capabilities_Extended Message:
- The Source **Shall** maintain VBUS regulation within the vValid range.
- The noise on the CC line **Shall** remain below vNoiseIdle and vNoiseActive.
Test conditions require a change in both positive and negative load steps from 1Hz to 5000Hz, up to the Advertised Load Step Magnitude of the full load output including from both 10 mA and 10% initial load. The Source **Shall** ensure that PD Communications meet the transmit and receive masks as specified in Section 5.3.4.1 and Section 5.3.4.2 under all load conditions.
#### 4.1.7.2. Load Step Magnitude
The default load step magnitude rate **Shall** be 25% of IoC. The Source May report higher capability, tolerating a load step of 90% of IoC.
#### 4.1.7.3. Holdup Time Field
The Holdup Time field **Shall** return a numeric value of the number of milliseconds the output voltage stays in regulation upon a short interruption of the AC Supply.
An AC Supplied Source **Shall** report its holdup time in this field. The holdup time is measured with the load at rated maximum, with the AC Supply at 115VAC rms and 60Hz (or at 230VAC rms and 50Hz for a Source that does not support 115VAC AC Supply). The reported time describes the minimum length of time from the last completed AC Supply input cycle (zero-degree phase angle) until when the output voltage decays below vSrcValid (min). A Source is recommended to support a minimum of 3ms and is preferred to support over 10 milliseconds holdup time (equivalent to a half cycle drop from the AC Supply). See Figure 4.11.
**Figure 4.11. Holdup Time Measurement**
![Holdup Time Measurement](04-power-delivery-electrical-requirements/figure-4.11.png)
#### 4.1.7.4. Compliance Field
An SPR Source claiming LPS, PS1 or PS2 compliance (see [IEC 60950-1] and [IEC 62368-1]) **Shall** report its Capabilities in the Compliance field.
#### 4.1.7.5. Batteries
The Number of Batteries/Battery Slots field **Shall** report the number of Batteries the Source supports. The Source **Shall** independently report the number of Hot Swappable Batteries and the number of Fixed Batteries.
<!-- page 62 -->
## 4.2. Sink Requirements
### 4.2.1. Behavioral Aspects
A USB PD Sink is a Device that receives power over a USB connection using the USB Power Delivery protocol. It monitors available power from the Source, requests specific voltage and current levels, and manages its power consumption based on the Negotiated Contract. In addition to being a USB Type-C Sink and following all [USB-C] defined behaviors, a USB PD Sink must meet all requirements defined in this chapter.
### 4.2.2. Sink Bulk Capacitance
The Sink bulk capacitance consists of C3 and C4 as shown in Figure 4.12. The Ohmic Interconnect might consist of PCB traces for power distribution or power switching devices. The Ohmic Interconnect is expected to be part of an input Over-Voltage Protection (Sink OVP) circuit implemented by the Sink as described in Section 4.1.5.2 to protect against excessive VBUS input voltage. A Sink **Shall** implement OVP and **Shall Not** rely on the Source output voltage limit for its input OVP. The capacitance might be a single capacitor, a capacitor bank or distributed capacitance.
**Figure 4.12. Placement of Sink Bulk Capacitance**
![Placement of Sink Bulk Capacitance](04-power-delivery-electrical-requirements/figure-4.12.png)
The total Sink bulk capacitance Connected to VBUS **Shall** not exceed cSnkBulk or cSnkBulkPd limits. The capacitance value May be changed at any time, provided the change:
- does not cause a transient current on VBUS that violates the maximum allowed current of the present Contract;
- does not cause iSnkStdby to be exceeded during positive load transitions;
- Guarantees the rate of change of currents stays below iLoadStepRate.
Capacitance beyond the cSnkBulk or cSnkBulkPd limit is permitted provided it is isolated from VBUS through current-limiting circuitry as described in [USB3]. The Sink **Shall** discharge this additional capacitance and **Shall** remove it in the event of a disconnect, Hard Reset, Fast Role Swap, or Power Role Swap. Since the additional capacitance might create a slow VBUS discharge on a disconnect, care must be taken to meet the requirements detailed in Section 4.2.9.1 and in [USB-C] to detect a disconnect event.
During a Power Role Swap, the Default Sink **Shall** transition to Swap Standby before operating as the New Source.
<!-- page 63 -->
Any change in bulk capacitance required to complete the Power Role Swap **Shall** occur during Swap Standby.
### 4.2.3. Sink Standby
The Sink **Shall** transition to Sink Standby before these transitions:
- a positive voltage transition of any Fixed Supply PDO
- a positive voltage transition larger than vSmallStep while in AVS Mode
- a positive voltage transition larger than vSmallStep while in PPS Mode.
A Sink is not required to transition to Sink Standby for these transitions:
- when operating within the Negotiated PPS APDO
- negative voltage transitions (ramp rate limited by vSlewNeg )
- PPS voltage transition smaller or equal to vSmallStep
- AVS voltage transition smaller or equal to vSmallStep.
During Sink Standby, the Sink **Shall** reduce the current drawn to iSnkStdby. This allows the Source to manage the voltage transition as well as supply sufficient operating current to the Sink to maintain PD operation during the transition. The Sink **Shall** complete this transition to Sink Standby within tSnkStdby after evaluating the Accept Message from the Source. The transition when returning to Sink operation from Sink Standby **Shall** be completed within tSnkNewPower. See Section 4.5 for details.
### 4.2.4. Suspend Power Consumption
When the Source has set its USB Suspend Supported flag (see Section 6.4.2.1.8), a Sink **Shall** go to the lowest power State during USB suspend. The lowest power State **Shall** be pSnkSusp or lower for a PDUSB Peripheral and pHubSusp or lower for a PDUSB Hub. There is no requirement for the Source voltage to be changed during USB suspend.
### 4.2.5. Zero Negotiated Power
When a Sink requests zero current as part of a power Negotiation with a Source, the Sink **Shall** go to the lowest power State ( pSnkSusp or lower) where it can still communicate using PD Signaling.
### 4.2.6. Transient Load Behavior
The rate of change of any shift in Sink load current during normal operation **Shall Not** exceed iSlewPos (for load steps) and iSlewNeg (for load releases) as measured at the Sink receptacle.
The Sink's operating current **Shall Not** change faster than the value reported in the Source's Voltage Regulation bit field (see Table 6.50) and **Shall** ensure that PD Communications meet the transmit and receive masks as specified in Section 5.3.4.1 and.
### 4.2.7. Considerations for Current Limit in PPS Mode
Prior to operating the PPS in Current Limit, the Sink **Shall** program the PPS Operating Voltage to the lowest practical level that satisfies the Sink load requirement. Doing so will minimize the inrush current that occurs when the transition to Current Limit occurs.
When requesting a new Current Limit, the Sink **Shall Not** Request a magnitude change that exceeds iPpsCLLoadStep.
<!-- page 64 -->
### 4.2.8. Sink Peak Current Operation
Sinks **Shall** only make use of a Source overload capability as indicated in the Fixed Supply PDO or AVS APDO
Peak Current (see Section 6.4.1.3.13 ). Sinks **Shall** manage thermal aspects of the overload event by not exceeding
the average Negotiated output of a Fixed Supply or AVS that supports Peak Current operation.
Sinks that depend on the Peak Current capability for enhanced system performance **Shall** also function correctly
when Attached to a Source that does not offer the Peak Current capability or when the Peak Current capability has
been inhibited by the Source.
### 4.2.9. Robust Sink Operation
#### 4.2.9.1. Sink Bulk Capacitance Discharge at Detach
When a Sink is Detached from a Source, the Sink **Shall** continue to draw power from its input bulk capacitance.
VBUS **Shall** discharge to vSafe5V or below within tSafe5V of the Detach event. This safe Sink requirement **Shall**
apply to all Sinks operating with a Negotiated VBUS level greater than vSafe5V and **Shall** apply during all low power
and high-power operating modes of the Sink.
If the Detach is detected during a Sink low power State, such as USB Suspend, the Sink can then draw as much
power as needed from its bulk capacitance since a Source is no longer Attached. In order to achieve a successful
Detach detect based on VBUS voltage level droop, the Sink power consumption **Shall** be high enough so that
VBUS will decay below vSrcValid (min) such that the disconnect is detected and the Sink VBUS pin is discharged
to vSafe5V within tSafe5V after the Source bulk capacitance is removed due to the Detach. Once adequate VBUS
droop has been achieved, a discharge circuit can be enabled to meet the safe Sink requirement.
To illustrate the point, the following set of Sink conditions will not meet the safe Sink requirement without additional
discharge circuitry:
- Negotiated VBUS = 20V.
- Maximum allowable supplied VBUS voltage = 21.55V.
- Maximum bulk capacitance = 30µF.
- Power consumption at Detach = 12.5mW.
When the Detach occurs (hence removal of the Source bulk capacitance), the 12.5mW power consumption will
draw down the VBUS voltage from the worst-case maximum level of 21.55V to 17V in approximately 205ms. At this
point, with VBUS well below vSrcValid (min) an approximate 100mW discharge circuit can be enabled to increase
the rate of Sink bulk capacitance discharge and meet the safe Sink requirement. The power level of the discharge
circuit is dependent on how much time is left to discharge the remaining voltage on the Sink bulk capacitance. If a
Sink has the ability to detect the Detach in a different manner and in much less time than tSafe5V, then this different
manner of detection can be used to enable a discharge circuit, allowing even lower power dissipation during low
power modes such as USB Suspend.
In most applications, the safe Sink requirement will limit the maximum Sink bulk capacitance well below the
cSnkBulkPd limit. A Detach occurring during Sink high power operating modes must quickly discharge the Sink bulk
capacitance to vSafe5V or lower as long as the Sink continues to draw adequate power until VBUS has decayed
to vSafe5V or lower.
#### 4.2.9.2. Sink Over-Current Protection
A Sink **May** be required to implement its own internal current protection mechanism to protect against internal and
external VBUS current faults in accordance with the applicable safety standards.
<!-- page 65 -->
#### 4.2.9.3. Sink Over-Voltage Protection
A Sink **Shall** implement input Over-Voltage Protection (OVP) to prevent damage from input voltage that exceeds
the voltage handling capability of the Sink, in accordance with applicable safety standards. The definition of voltage
handling capability is left to the discretion of the Sink implementation. The over-voltage response of a Sink **Shall
Not** interfere with normal PD operation and **Shall** account for vNew, or vValid as determined by the Negotiated
VBUS value. An SPR Sink **Should** tolerate input voltages as high as vSprMax. All Sinks **Shall** meet applicable
safety requirements.
A Sink **Should** attempt to send Hard Reset Signaling when OVP engages followed by an Alert Message indicating
an OVP event once an Explicit Contract has been established. The OVP response **May** engage at either the Port
or system level. Systems or ports that have engaged OVP **Shall** resume USB Default Operation when the Source
has re-established vSafe5V on VBUS. The Sink **Shall** be able to renegotiate with the Source after resuming USB
Default Operation.
The Sink **Should** prevent continual system or Port cycling if OVP continues to engage after initially resuming either
USB Default Operation or renegotiation. Latching off the Port or system is an acceptable response to recurring over-
voltage.
#### 4.2.9.4. Sink Over-Temperature Protection
A Sink **Shall** implement Over-Temperature Protection (OTP) in order to comply with applicable safety standards.
The definition of thermal capability and the monitoring locations used to trigger the over-temperature protection are
left to the discretion of the Sink implementation.
## 4.3. Dual Role Ports
A Dual-Role Power Port in either the Source role or Sink role **Shall** support Swap Standby, which is required for a
Power Role Swap. Note: During a Power Role Swap, the USB connection **Shall Not** reset even though vSafe5V
is no longer present on VBUS.
### 4.3.1. Swap Standby for the Initial Source
Swap Standby starts for the Source after the Source power supply has discharged the bulk capacitance on VBUS
to vSafe0V as part of the Power Role Swap transition. It ends after the New Source sends a PS_RDY Message.
While in Swap Standby:
- The Source **Shall Not** drive VBUS, which is therefore expected to remain at vSafe0V.
- The New Sink **Shall Not** draw more than iSnkSwapStdby as the New Source turns on VBUS.
- The Dual-Role Power Port **Shall** be configured as a Sink.
- The PS_RDY Message associated with the Source being in Swap Standby **Shall** be sent after the VBUS
drive is removed.
- The transition time from Swap Standby to being the New Sink **Shall** be no more than tNewSnk.
### 4.3.2. Swap Standby for the Initial Sink
Swap Standby starts for the Sink after evaluating the Accept Message from the Source or sending an Accept Mes-
sage to the Source during a Power Role Swap. It ends once the New Source reaches vSafe5V. While in Swap
Standby:
- The Sink's current draw **Shall Not** exceed iSnkSwapStdby from VBUS.
<!-- page 66 -->
- The Dual-Role Power Port **Shall** be configured as a Source after VBUS has been discharged to vSafe0V
by the existing Initial Source.
- The time for the Sink to transition to Swap Standby **Shall** be no more than tSnkSwapStdby.
- When in Swap Standby, the Sink has relinquished its Power Role as Sink and will prepare to become the
New Source. The transition time from Swap Standby to New Source **Shall** be no more than tNewSrc.
### 4.3.3. Power Role Swap Sequence
In Figure 4.13, a PR_Swap Message has been sent by either the Sink or the Source. See Chapter 10 for a Fast
Role Swap (FRS) Sequence.
The Power Role Swap will follow the same sequence irrespective of which Port partner makes the Request:
- Once the Port Partner accepts the Request, and a GoodCRC Message is sent in return, the PSSourceOff
Timer is started.
- The Sink has tSnkStdby to reduce the current consumption to iSnkSwapStdby.
- Once tSrcTransition elapses, the Source has tSrcSwapStdby to discharge VBUS.
- The Initial Source **Shall** transition the termination from Rp to Rd before sending PS_RDY Message.
- After the Initial Source sends a PS_RDY Message it initiates the PSSourceOn Timer.
- The New Source has tSrcTransOn to turn on VBUS and transition to vSafe5V. During this time the New Sink
**Shall** limit its current to iSnkSwapStdby.
- Once the PS_RDY Message is sent by the New Source, the Sink can start taking the Type-C Current defined
by Rp. New Contract negotiations can now take place.
<!-- page 67 -->
**Figure 4.13. Transition Diagram for a Power Role Swap**
![Figure 4.13. Transition Diagram for a Power Role Swap](04-power-delivery-electrical-requirements/figure-4.13.png)
## 4.4. Response to Hard Resets
Hard Reset Signaling indicates a communication failure has occurred. The Source is subject to the following requirements:
- **Shall** drive VBUS to vSafe0V.
- These actions start tPSHardReset after the last bit of the Hard Reset Signaling has been received from the
Sink or sent by the Source. The Source **Shall** take into consideration that the Sink **May** have cSnkBulkPd
present until VBUS drops below vSafe0V.
- The Source **Shall** meet both tSafe5V and tSafe0V relative to the start of the voltage transition.
- After establishing the vSafe0V voltage condition on VBUS, the Source **Shall** wait tSrcRecover before re-
applying VCONN and restoring VBUS to vSafe5V.
The Port Partner that drives VCONN is subject to the following requirements:
- **Shall** stop driving VCONN.
<!-- page 68 -->
- If the Source was driving VCONN, then Rp **Shall** be removed from the CC line.
- If the Sink was driving VCONN, Rd **Shall** be added to the CC line.
- VCONN will meet tVCONNDischarge relative to the start of the voltage transition as shown in Figure 4.14
due to the discharge circuitry in the CablePlug. VCONN **Shall** meet tVCONNOn relative to VBUS reaching
vSafe5V.
- tVCONNOn and tVCONNDischarge are defined in [USB-C].
**Figure 4.14. Source VBUS and VCONN Response to Hard Reset**
![Figure 4.14. Source VBUS and VCONN Response to Hard Reset](04-power-delivery-electrical-requirements/figure-4.14.png)
The USB connection **May** reset during a Hard Reset since the VBUS voltage will be less than vSafe5V for an
extended period of time.
Device operation during and after a Hard Reset is defined as follows:
- Self-powered devices **Should Not** disconnect from USB during a Hard Reset.
- Self-powered devices operating at more than vSafe5V **May Not** maintain full functionality after a Hard Reset.
- Bus powered devices will disconnect from USB during a Hard Reset due to the loss of their power Source.
### 4.4.1. Hard Reset Sequence
The Hard Reset transition diagram is shown in. The sequence is the same irrespective of which Port Partner started
it.
- Once the Hard Reset is initiated tPSHardReset starts. The Sink has tSnkHardResetPrepare, where the
current Contract is still guaranteed.
<!-- page 69 -->
- Once tPSHardReset elapses, the Source has tSafe0V to drive the VBUS voltage to vSafe0V or lower. At
this point the Sink **Shall Not** draw more than iSafe0mA.
- After tSrcRecover the Source applies power to VBUS. The transition to vSafe5V **Shall** occur within tSrc-
TurnOn, and initially the current will be limited to Type-C Current until a new explicit Contract is established.
**Figure 4.15. Transition diagram for a Hard Reset**
![Figure 4.15. Transition diagram for a Hard Reset](04-power-delivery-electrical-requirements/figure-4.15.png)
## 4.5. Transitions
The following sections illustrate the power supply's response to common Negotiation events, including transitions
initiated by a Request Message, as well as Power Role Swaps and Hard Reset scenarios.
### 4.5.1. Fixed and AVS transitions
The examples of PDO or APDO changes below illustrate the most common voltage and current transition requests.
In all the following examples, the Sink has previously sent a Request Message to the Source. The figures group the
common cases; each title states the applicable voltage/current change. These examples illustrate typical successful
transitions but are not to scale.
The timing parameters that **Shall** be followed are listed in Table 4.6, Table 4.7, and Table 4.8.
#### 4.5.1.1. Large-step voltage increases (Fixed or AVS)
This diagram applies to fixed voltage transitions and AVS transitions where the voltage is increasing and the voltage
change > vSmallStep. In these cases, the Sink **Shall** reduce the VBUS current to iSnkStdby as specified below.
<!-- page 70 -->
The sequence for these types of transitions is as follows:
- The Source Policy Engine sends an Accept Message.
- The PSTransitionTimer starts immediately after the Sink completes sending the GoodCRC Message.
- tSrcTransition, tSnkStdby, and tSrcTransReq / tAvsSrcTransLarge also start at this point.
- The Sink **Should** reduce the current to no more than iSnkStdby within tSnkStdby. It **Shall** be reduced to
iSnkStdby before the end of the minimum value of tSrcTransition expires.
- Once tSrcTransition elapses, the Source **May** start increasing the voltage. It **Shall** reach vNew and begin
sending a PS_RDY Message before:
- tSrcTransReq expires for transitions to a PDO.
- tAvsSrcTransLarge expires for transitions to an AVS APDO.
- The Sink acknowledges the PS_RDY Message with a GoodCRC Message and **May** increase its current up
to the newly Negotiated value at any time, provided the required slew rate is not exceeded.
**Figure 4.16. Transition Diagram for Large-step voltage increase (Fixed or AVS > vSmallStep)**
![Figure 4.16. Transition Diagram for Large-step voltage increase (Fixed or AVS > vSmallStep)](04-power-delivery-electrical-requirements/figure-4.16.png)
<!-- page 71 -->
#### 4.5.1.2. Small-step voltage increases (AVS)
Figure 4.17 applies to AVS transitions where the voltage is increasing and the voltage change ≤ vSmallStep. In
these cases, the Sink can maintain the maximum current through the transition.
The sequence for these types of transitions is as follows:
- The Source Policy Engine sends an Accept Message.
- The PSTransitionTimer starts immediately after the Sink completes sending the GoodCRC Message.
- There is no requirement for the Sink to reduce the current during the transition period.
- The Source **May** immediately start increasing the voltage. It **Shall** reach vNew and send a PS_RDY Message
before tSrcTransSmall expires.
- The Sink acknowledges the PS_RDY Message with a GoodCRC Message and **May** increase its current up
to the newly Negotiated value at any time, provided the required slew rate is not exceeded.
**Figure 4.17. Transition Diagram for Small-step voltage increase (AVS ≤ vSmallStep), current unchanged or increased**
![Figure 4.17. Transition Diagram for Small-step voltage increase (AVS ≤ vSmallStep), current unchanged or increased](04-power-delivery-electrical-requirements/figure-4.17.png)
Figure 4.18 applies to AVS transitions where the voltage is increasing and the voltage change ≤ vSmallStep with
a decrease in current.
The sequence for these types of transitions is as follows:
<!-- page 72 -->
- The Source Policy Engine sends an Accept Message.
- The `PSTransitionTimer` starts immediately after the Sink completes sending the GoodCRC Message.
- The Sink has `tSnkNewPower` to reduce the VBUS current to a maximum of $I_{NEW}$.
- The Source **Shall** reach `vNew` and send a `PS_RDY` Message before `tSrcTransSmall` expires.
- The Source **Shall** wait `tSnkNewPower` before changing any current limit protection related to $I_{NEW}$.
- The Sink acknowledges the `PS_RDY` Message with a GoodCRC Message.
**Figure 4.18. Transition Diagram for Small-step voltage increase (AVS ≤ vSmallStep), current decreased**
![Transition Diagram for Small-step voltage increase (AVS ≤ vSmallStep), current decreased](04-power-delivery-electrical-requirements/figure-4.18.png)
#### 4.5.1.3. Unchanged or decreased voltage transitions (current unchanged, increased, or decreased)
The process for these transitions depends on whether the voltage is unchanged or decreased, and whether the current is increased, decreased, or unchanged.
- The Source Policy Engine sends an Accept Message.
- The `PSTransitionTimer` starts immediately after the Sink completes sending the GoodCRC Message.
- There is no requirement for the Sink to reduce the current during the transition period.
<!-- page 73 -->
- The Source **Shall** wait `tSrcTransition` before starting to decrease the voltage or updating any current protection thresholds as needed.
- Once `tSrcTransition` elapses, the Source **May** start decreasing the voltage. It **Shall** reach `vNew` and begin sending a `PS_RDY` Message before:
- `tSrcTransReq` expires for transitions to a PDO.
- `tAvsSrcTransLarge` expires for transition to an AVS APDO and the voltage change is > `vSmallStep`.
- The Sink acknowledges the `PS_RDY` Message with a GoodCRC Message and **May** increase its current up to the newly Negotiated value at any time, as long as the required slew rate is not exceeded.
**Figure 4.19. Transition Diagram for voltage unchanged or decreased with current unchanged or increased**
![Transition Diagram for voltage unchanged or decreased with current unchanged or increased](04-power-delivery-electrical-requirements/figure-4.19.png)
If the current needs to be decreased, the previous sequence shall be followed with one difference as shown in Figure 4.20:
- The Sink **Should** reduce the current to a value that is less than or equal to the newly Negotiated value ($I_{NEW}$) within `tSnkNewPower`. It **Shall** reach $I_{NEW}$ before the minimum value of `tSrcTransition` expires.
<!-- page 74 -->
**Figure 4.20. Transition Diagram for voltage unchanged or decreased with current decreased**
![Transition Diagram for voltage unchanged or decreased with current decreased](04-power-delivery-electrical-requirements/figure-4.20.png)
### 4.5.2. PPS voltage or current changes
#### 4.5.2.1. PPS voltage transitions (CV Mode)
This sequence is valid for any PPS voltage transition (while in CV Mode), and any small AVS transition that is `vAvsSmallStep` or smaller.
Compared with transitions that use fixed voltage contracts, the process of starting the voltage transition can begin immediately after the Sink acknowledges the Accept Message with a GoodCRC Message. Additionally, the Sink can operate at any current level, up to the maximum value defined by the Contract. Figure 4.21 shows the sequence when the voltage is increased and Figure 4.22 shows the sequence when it is decreased.
<!-- page 75 -->
**Figure 4.21. Transition Diagram for PPS voltage increase (CV Mode)**
![Transition Diagram for PPS voltage increase (CV Mode)](04-power-delivery-electrical-requirements/figure-4.21.png)
<!-- page 76 -->
**Figure 4.22. Transition Diagram for PPS voltage decrease (CV Mode)**
![Transition Diagram for PPS voltage decrease (CV Mode)](04-power-delivery-electrical-requirements/figure-4.22.png)
#### 4.5.2.2. PPS current transitions (CL Mode)
In PPS, the Sink can Request a change in current while operating in Current Limit (CL) Mode. In this scenario, the Source is controlling the VBUS current instead of the VBUS voltage. The VBUS voltage can take any value between `vPpsMinVoltage`, and the Output Voltage value used in the PPS Request Data Object. Figure 4.23 shows the transition for changing current in PPS.
<!-- page 77 -->
**Figure 4.23. Transition Diagram for PPS current increase (CL Mode)**
![Transition Diagram for PPS current increase (CL Mode)](04-power-delivery-electrical-requirements/figure-4.23.png)
**Figure 4.24. Transition Diagram for PPS current decrease (CL Mode)**
![Transition Diagram for PPS current decrease (CL Mode)](04-power-delivery-electrical-requirements/figure-4.24.png)
<!-- page 78 -->
## 4.6. VCONN Power Cycle
When performing a VCONN Power Cycle during a Data Reset, the following steps **Shall** be followed:
- Following the last bit of the GoodCRC Message acknowledging the Accept Message, the initial VCONN Source **Shall** turn off VCONN and ensure it is below [USB-C] `vRaReconnect` within `tVCONNZero`.
- When VCONN is below `vRaReconnect`, the initial VCONN Source **Shall** send a `PS_RDY` Message. Note: for a Data Reset requested by the UFP, if the UFP was not sourcing VCONN, it **Shall** send the `PS_RDY` Message.
- The new VCONN Source **Shall** wait `tVCONNReapplied` following the last bit of the GoodCRC Message acknowledging the `PS_RDY` Message before sourcing VCONN. The new VCONN **Shall** ensure VCONN is within `vVCONNValid` (see [USB-C]) within `tVCONNValid`.
Figure 4.25 illustrates the VCONN Power Cycle process.
**Figure 4.25. Data Reset VCONN Power Cycle**
![Data Reset VCONN Power Cycle](04-power-delivery-electrical-requirements/figure-4.25.png)
## 4.7. Electrical Parameters
### 4.7.1. Source Electrical Parameters
The Source Electrical Parameters that **Shall** be followed are specified in Table 4.6.
<!-- page 79 -->
**Table 4.6. Source Electrical Parameters**
| Parameter Name | | Min Value | Nom Value | Max Value | Unit | Description |
|---|---|---|---|---|---|---|
| `cSrcBulk` | | 10 | | | µF | Source bulk capacitance when a Port is powered from a dedicated supply. |
| `cSrcBulkShared` | | 120 | | | µF | Source bulk capacitance when a Port is powered from a shared supply.[^1] |
| `DNL` | | -1 | 0 | +1 | LSB | Differential Non-Linearity Deviation between ideal analog values corresponding to adjacent input digital values |
| `iPpsCLMin` | | | 1 | | A | PPS Minimum Current Limit setting. |
| `iPpsCLNew` | ≤ 3A | -150 | | 150 | mA | Current Limit Accuracy 1A ≤ Operating Current ≤ 3A |
| `iPpsCLNew` | > 3A | -5 | | 5 | % | Current Limit Accuracy Operating current > 3A |
| `iPpsCLStep` | | | 50 | | mA | PPS Current Limit programming step size (1 LSB). |
| `iPpsCLLoadReleaseRate` | | -150 | | | mA/µs | Maximum load decrease slew rate during Current Limit setpoint changes. |
| `iPpsCLLoadStepRate` | | | | 150 | mA/µs | Maximum load increase slew rate during Current Limit setpoint changes. |
| `iPpsCLTransient` | Load increase | | | New load + 100 | mA | Allowed output current overshoot when a load increase occurs while in CL Mode. |
| `iPpsCLTransient` | Load decrease | New load – 100 | | | mA | Allowed output current undershoot when a load decrease occurs while in CL Mode. |
| `iPpsCVCLTransient` | | `iPpsCLNew` - 100 | | New load + 500 | mA | CV to CL transient current bounds. See Section 4.1.3.2.2. |
| `tAvsTransient` | | | | 5 | ms | The maximum time for the AVS to be between `vAvsNew` and `vAvsValid` in response to a load transient. |
| `tAvsSrcTransLarge` | | 0 | | 700 | ms | The time the AVS set-point **Shall** transition between requested voltages for steps larger than `vAvsSmallStep`. |
| `tAvsSrcTransSmall` | | 0 | | 50 | ms | The time the AVS set-point **Shall** transition between requested voltages for steps smaller than `vAvsSmallStep`. |
| `tNewSnk` | | | | 15 | ms | Time allowed for an Initial Source in Swap Standby to transition to New Sink operation. |
| `tPpsCLCVTransient` | | | | 275 | ms | CL to CV transient voltage settling time. |
| `tPpsCLProgramSettle` | | | | 250 | ms | PPS Current Limit programming settling time. |
<!-- page 80 -->
| Parameter Name | | Min Value | Nom Value | Max Value | Unit | Description |
| --- | --- | --- | --- | --- | --- | --- |
| tPpsCLSettle | | | | 250 | ms | CL load transient current settling time. |
| tPpsCVCLTransient | | | | 250 | ms | CV to CL transient settling time. |
| tPpsSrcTransLarge | | 0 | | 275 | ms | The time the Programmable Power Supply's set-point **Shall** transition between requested voltages for steps larger than vPpsSmallStep. |
| tPpsSrcTransSmall | | 0 | | 25 | ms | The time the Programmable Power Supply's set-point **Shall** transition between requested voltages for steps less than or equal to vPpsSmallStep. |
| tPpsTransient | Target load ≥ 60mA | | | 5 | ms | The maximum time for the Programmable Power Supply to be between vPpsNew and vPpsValid in response to a load transient when target load is greater than or equal to 60mA. |
| tPpsTransient | Target load < 60mA | | | 150 | ms | The maximum time for the Programmable Power Supply to be between vPpsNew and vPpsValid in response to a load transient when target load is less than 60mA. |
| tSrcReady | SPR Mode | | | 285 | ms | Time from positive/negative transition start (t0) to when the Source is ready to provide the newly Negotiated power level. Applies only to SPR Mode voltage transitions. |
| tSrcReady | EPR Mode | | | 720 | ms | Time from positive/negative transition start (t0) to when the Source is ready to provide the newly Negotiated power level. Applies to EPR Mode voltage transitions and any voltage transition that either begins or ends in EPR Mode. |
| tSrcRecover | SPR Mode | 0.66 | | 1.0 | s | Time allotted for the Source to recover. |
| tSrcRecover | EPR Mode | 1.085 | | 1.425 | s | Time allotted for the Source to recover. |
| tSrcSettle | SPR Mode | | | 275 | ms | Time from positive/negative transition start (t0) to when the transitioning voltage is within the range vSrcNew. Applies only to SPR Mode voltage transitions. |
| tSrcSettle | EPR Mode | | | 700 | ms | Time from positive/negative transition start (t0) to when the transitioning voltage is within the range vAvsNew. Applies to EPR Mode voltage transitions and any voltage transition that either begins or ends in EPR Mode. |
| tSrcSwapStdby | | | | 650 | ms | The maximum time for the Source to transition to Swap Standby. |
<!-- page 81 -->
| Parameter Name | | Min Value | Nom Value | Max Value | Unit | Description |
| --- | --- | --- | --- | --- | --- | --- |
| tSrcTransient | | | | 5 | ms | The maximum time for the Source output voltage to be between vSrcNew and vSrcValid in response to a load transient when target load is greater than or equal to 60mA. |
| tSrcTransient | | | | 150 | ms | The maximum time for the Source output voltage to be between vSrcNew and vSrcValid in response to a load transient when target load is less than 60mA. |
| tSrcTransition | | 25 | | 35 | ms | The time the Source **Shall** wait before transitioning the power supply to ensure that the Sink has sufficient time to prepare (does not apply to transitions within the same PPS or AVS APDO). |
| tSrcTransOff | | | | 690 | ms | Time from the last bit of the GoodCRC Message acknowledging the Accept Message in response to the PR_Swap Message until the PS_RDY Message must be started. Applies only to SPR Mode voltage transitions. |
| tSrcTransOn | | | | 280 | ms | Time from the last bit of the GoodCRC Message acknowledging the PS_RDY Message sent by the New Source, in response to the PR_Swap Message until the PS_RDY Message must be started. |
| tSrcTransReq | SPR Mode | | | 325 | ms | Time from the last bit of the GoodCRC Message acknowledging the Accept Message in response to the Request Message until the PS_RDY Message must be started. Applies only to SPR Mode voltage transitions. |
| tSrcTransReq | EPR Mode | | | 760 | ms | Time from the last bit of the GoodCRC Message acknowledging the Accept Message in response to the Request Message until the PS_RDY Message must be started. Applies to EPR Mode voltage transitions and any voltage transition that either begins or ends in EPR Mode. |
| tSrcTurnOn | | | | 275 | ms | Transition time from vSafe0V to vSafe5V. |
| tReducePowerAlert | | 2000 | | 2400 | ms | Time between an alert and the New Source Capabilities when reducing Port Present PDP. |
| tDpsColdStart | | 15 | | | minute | Time for a DPS Source to maintain Port Present PDP = Port Maximum PDP after a cold start before thermal limiting. |
| tDpsRegular | | 1 | | | minute | Time between New Source Capabilities for a DPS Source due to thermal limiting. |
<!-- page 82 -->
| Parameter Name | | Min Value | Nom Value | Max Value | Unit | Description |
| --- | --- | --- | --- | --- | --- | --- |
| vAvsMaxVoltage | | APDO Max Voltage×0.95 | | APDO Max Voltage×1.05 | V | Maximum Voltage Field in the AVS APDO. |
| vAvsMinVoltage | | APDO Min Voltage×0.95 | | APDO Min Voltage×1.05 | V | Minimum Voltage Field in the AVS APDO. |
| vAvsNew | | RDO Output Voltage×0.95 | RDO Output Voltage | RDO Output Voltage×1.05 | V | Adjustable RDO Output Voltage measured at the Source receptacle. |
| vAvsSlewNeg | | | | -30 | mV/µs | AVS maximum slew rate for negative voltage changes. |
| vAvsSlewPos | | | | 30 | mV/µs | AVS maximum slew rate for positive voltage changes. |
| vAvsSmallStep | | -1.0 | | 1.0 | V | AVS step size defined as a small step relative to the previous vAvsNew. |
| vAvsStep | | | 100 | | mV | AVS voltage programming step size. |
| vAvsValid | | -0.5 | | 0.5 | V | The range in addition to vAvsNew which the AVS output is considered **Valid** during and after a transition as well as in response to a transient load condition. |
| vPpsCLCVTransient | | Operating Voltage×0.95 – 0.1V | | Operating Voltage×1.05 + 0.1V | V | CL to CV load transient voltage bounds. |
| vPpsMaxVoltage | | APDO Max Voltage×0.95 | | APDO Max Voltage×1.05 | V | Maximum Voltage Field in the Programmable Power Supply APDO. |
| vPpsMinVoltage | | APDO Min Voltage×0.95 | | APDO Min Voltage×1.05 | V | Minimum Voltage Field in the Programmable Power Supply APDO. |
| vPpsNew | | RDO Output Voltage×0.95 | RDO Output Voltage | RDO Output Voltage×1.05 | V | Programmable RDO Output Voltage measured at the Source receptacle. |
| vPpsShutdown | | APDO Minimum Voltage×0.85 | | APDO Minimum Voltage×0.95 | V | The voltage at which the PPS shuts down when operating in CL. |
| vPpsSlewNeg | | | | -30 | mV/µs | Programmable Power Supply maximum slew rate for negative voltage changes |
| vPpsSlewPos | | | | 30 | mV/µs | Programmable Power Supply maximum slew rate for positive voltage changes |
| vPpsSmallStep | | -500 | | 500 | mV | PPS Step size defined as a small step relative to the previous vPpsNew. |
| vPpsStep | | | 20 | | mV | PPS voltage programming step size (1 LSB). |
| vPpsValid | | -0.1 | | 0.1 | V | The range in addition to vPpsNew which the Programmable Power Supply output is considered **Valid** in response to a load step. |
| vSrcNeg | | | | -0.3 | V | Most negative voltage allowed during transition. |
| vSrcNew | Fixed Supply | PDO Voltage×0.95 | PDO Voltage | PDO Voltage×1.05 | V | Fixed Supply output measured at the Source receptacle. |
<!-- page 83 -->
| Parameter Name | | Min Value | Nom Value | Max Value | Unit | Description |
| --- | --- | --- | --- | --- | --- | --- |
| vSrcNew | Variable Supply | PDO Minimum Voltage | | PDO Maximum Voltage | V | Variable Supply output measured at the Source receptacle. |
| vSrcNew | Battery Supply | PDO Minimum Voltage | | PDO Maximum Voltage | V | Battery Supply output measured at the Source receptacle. |
| vSrcPeak | | PDO Voltage×0.90 | | PDO Voltage×1.05 | V | The range that a Fixed Supply or EPR AVS in Peak Current operation is allowed when overload conditions occur. |
| vSrcSlewNeg | | | | -30 | mV/µs | Maximum slew rate allowed for negative voltage transitions. Limits current based on a 3 A connector rating and maximum Sink bulk capacitance of 100 µF. |
| vSrcSlewPos | | | | 30 | mV/µs | Maximum slew rate allowed for positive voltage transitions. Limits current based on a 3 A connector rating and maximum Sink bulk capacitance of 100 µF. |
| vSrcValid | | -0.5 | | 0.5 | V | The range in addition to vSrcNew which a newly Negotiated voltage is considered **Valid** during and after a transition as well as in response to a transient load condition. This range also applies to vSafe5V. |
### 4.7.2. Sink Electrical Parameters
The Sink Electrical Parameters that **Shall** be followed are specified in Table 4.7.
**Table 4.7. Sink Electrical Parameters**
| Parameter Name | Min Value | Nom Value | Max Value | Unit | Description |
| --- | --- | --- | --- | --- | --- |
| cSnkBulk | | | See [USB3] | | Sink bulk capacitance on VBUS at Attach and during FRS after the Initial Source stops sourcing and prior to establishing the First Explicit Contract. |
| cSnkBulkPd | | | 100 | µF | Bulk Capacitance that a Sink is allowed to present on VBUS after a successful Negotiation. |
| iLoadReleaseRate | -150 | | | mA/ µs | Load release di/dt. |
| iLoadStepRate | | | 150 | mA/ µs | Load step di/dt. |
| iPpsCLLoadStep | -500 | | 500 | mA | Maximum Current set-point change while operating in CL Mode. |
| iSafe0mA | | | 1.0 | mA | Maximum current a Sink is allowed to draw when VBUS is driven to vSafe0V. |
| iSnkStdby | | | 500 | mA | Maximum current during voltage transition. |
| iSnkSwapStdby | | | 2.5 | mA | Maximum current a Sink can draw during Swap Standby. Ideally this current is very near to 0 mA largely influenced by Port leakage current. |
| pHubSusp | | | 125 | mW | Suspend power consumption for a Hub. 25mW + 25mW per downstream Port for up to 4 ports. |
| pSnkSusp | | | 25 | mW | Suspend power consumption for a Peripheral Device. |
| tNewSrc | | | 275 | ms | Maximum time allowed for an Initial Sink in Swap Standby to transition to New Source operation. |
<!-- page 84 -->
| Parameter Name | Min Value | Nom Value | Max Value | Unit | Description |
| --- | --- | --- | --- | --- | --- |
| tSnkHardResetPrepare | | | 15 | ms | Time allotted for the Sink power electronics to prepare for a Hard Reset. |
| tSnkNewPower | | | 15 | ms | Maximum transition time between power levels. |
| tSnkRecover | | | 150 | ms | Time for the Sink to resume USB Default Operation. |
| tSnkStdby | | | 15 | ms | Time to transition to Sink Standby from Sink. |
| tSnkSwapStdby | | | 15 | ms | Maximum time for the Sink to transition to Swap Standby. |
| vSprMax | | | 24 | V | A Sink **Should** tolerate this VBUS voltage without damage. |
1. If more bypass capacitance than cSnkBulk (max) or cSnkBulkPd (max) is required in the Device, then the Device **Shall** incorporate some form of VBUS surge current limiting as described in [USB3].
### 4.7.3. Common Electrical Parameters
Electrical Parameters that are common to both the Source and the Sink that **Shall** be followed are specified in Table 4.8.
**Table 4.8. Common Source/Sink Electrical Parameters**
| Parameter Name | Min Value | Nom Value | Max Value | Unit | Description |
| --- | --- | --- | --- | --- | --- |
| tSafe0V | | | 650 | ms | Time to reach vSafe0V (max). |
| tSafe5V | | | 275 | ms | Time to reach vSafe5V (max). |
| tVCONNReapplied | 10 | | 20 | ms | When the UFP is the VCONN Source: time from the last bit of the GoodCRC Message acknowledging the PS_RDY Message until VCONN is within vVCONNValid (see [USBC]). When the DFP is the VCONN Source: time from when VCONN drops below vRaReconnect. |
| tVCONNValid | 0 | | 5 | ms | Time from tVCONNReapplied until VCONN is within vVCONNValid (see [USB-C]). |
| tVCONNZero | | | 125 | ms | Time from the last bit of the GoodCRC acknowledging the Accept Message in response to the Data_Reset Message until VCONN is below vRaReconnect (see [USB-C]). |
| vSafe0V | 0 | | 0.8 | V | Safe operating voltage at "zero volts". |
| vSafe5V | 4.75 | | 5.5 | V | Safe operating voltage at 5V. See [USB2] and [USB3] for allowable VBUS voltage range. |
1. tVCONNStable (See [USB-C]) still applies.

BIN
USB_PD_R3.2/04-power-delivery-electrical-requirements/figure-4.1.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 36 KiB

BIN
USB_PD_R3.2/04-power-delivery-electrical-requirements/figure-4.10.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 38 KiB

BIN
USB_PD_R3.2/04-power-delivery-electrical-requirements/figure-4.11.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 39 KiB

BIN
USB_PD_R3.2/04-power-delivery-electrical-requirements/figure-4.12.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 35 KiB

BIN
USB_PD_R3.2/04-power-delivery-electrical-requirements/figure-4.13.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 114 KiB

BIN
USB_PD_R3.2/04-power-delivery-electrical-requirements/figure-4.14.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 98 KiB

BIN
USB_PD_R3.2/04-power-delivery-electrical-requirements/figure-4.15.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 56 KiB

BIN
USB_PD_R3.2/04-power-delivery-electrical-requirements/figure-4.16.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 66 KiB

BIN
USB_PD_R3.2/04-power-delivery-electrical-requirements/figure-4.17.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 47 KiB

BIN
USB_PD_R3.2/04-power-delivery-electrical-requirements/figure-4.18.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 48 KiB

BIN
USB_PD_R3.2/04-power-delivery-electrical-requirements/figure-4.19.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 51 KiB

BIN
USB_PD_R3.2/04-power-delivery-electrical-requirements/figure-4.2.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 61 KiB

BIN
USB_PD_R3.2/04-power-delivery-electrical-requirements/figure-4.20.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 49 KiB

BIN
USB_PD_R3.2/04-power-delivery-electrical-requirements/figure-4.21.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 40 KiB

BIN
USB_PD_R3.2/04-power-delivery-electrical-requirements/figure-4.22.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 40 KiB

BIN
USB_PD_R3.2/04-power-delivery-electrical-requirements/figure-4.23.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 46 KiB

BIN
USB_PD_R3.2/04-power-delivery-electrical-requirements/figure-4.24.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 46 KiB

BIN
USB_PD_R3.2/04-power-delivery-electrical-requirements/figure-4.25.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 52 KiB

BIN
USB_PD_R3.2/04-power-delivery-electrical-requirements/figure-4.3.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 50 KiB

BIN
USB_PD_R3.2/04-power-delivery-electrical-requirements/figure-4.4.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 49 KiB

BIN
USB_PD_R3.2/04-power-delivery-electrical-requirements/figure-4.5.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 14 KiB

BIN
USB_PD_R3.2/04-power-delivery-electrical-requirements/figure-4.6.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 60 KiB

BIN
USB_PD_R3.2/04-power-delivery-electrical-requirements/figure-4.7.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 47 KiB

BIN
USB_PD_R3.2/04-power-delivery-electrical-requirements/figure-4.8.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 33 KiB

BIN
USB_PD_R3.2/04-power-delivery-electrical-requirements/figure-4.9.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 40 KiB

687
USB_PD_R3.2/05-pd-communications-physical-layer.md Normal file
View file

@ -0,0 +1,687 @@
<!-- page 85 -->
# Chapter 5. PD Communications Physical Layer
## 5.1. Overview
The Physical Layer (PHY Layer) defines the Signaling technology for USB Power Delivery. This chapter defines the electrical requirements and parameters of the PHY Layer to ensure interoperability between PDUSB Devices.
The USB PD PHY Layer consists of a BMC transmitter and receiver that communicate across a single signal wire (CC) along with terminations for DC biasing. All BMC communication is half-duplex. The PHY Layer uses DC biasing for Collision Avoidance to minimize communication errors on the channel, indicate Power Role, and establish Implicit contracts.
The transmitter performs the following functions:
- Receive Packet data from the Protocol Layer.
- Calculate and append a CRC.
- Encode the Packet data including the CRC (i.e., the Payload).
- Transmit the Packet (Preamble, SOP*, Payload, CRC and EOP) across the channel using Bi-phase Mark Coding (BMC) over CC.
The receiver performs the following functions:
- Recover the clock and signal.
- Detect the SOP*.
- Decode the received data including the CRC.
- Detect the EOP and validate the CRC:
- If the CRC is **Valid**, deliver the Packet data to the Protocol Layer.
- If the CRC is **Invalid**, flush the received data.
## 5.2. Signaling Through DC Biasing
The DC biasing Signaling is implemented using Rp pullups and/or Rd pulldowns as defined in [USB-C].
### 5.2.1. Power Role Indication
[USB-C] defines the usage of Rp and Rd as the Power Role indicator. Rp indicates the Source and Rd indicates the Sink. USB PD allows the roles to be swapped between the Source and Sink. This is done by changing from Rp to Rd when changing from a Source to a Sink and changing from Rd to Rp when changing from a Sink to a Source. The Device Policy Manager (DPM) informs the PHY Layer when the CC termination needs to be changed from an Rp pullup to an Rd pulldown or vice versa. The PHY simply applies the requested CC termination.
### 5.2.2. Collision Avoidance
When a USB PD Explicit Contract is established, the Rp value presented by the Source is no longer needed to determine [USB-C] Type-C current. The value of Rp is then repurposed to indicate CC bus communications avail-
<!-- page 86 -->
ability. To avoid collisions, the Source controls who may communicate on CC. CC Collision Avoidance is achieved by the following:
1. During the Default or Implicit Contract, the Rp resistor value is used to specify [USB-C] Type-C Current and **Shall** not be used for Collision Avoidance.
2. The Protocol Layer of a Sink **Shall** Request from the PHY Layer the value of Rp the Source Port Partner is presenting to determine if it may initiate a transmission.
3. The Source **Shall** present Rp=`SinkTxNG` to claim control of the CC bus, and the Source **Shall** present Rp=`SinkTxOk` to release control of the CC bus. Table 5.1 shows the Rp values the Source **Shall** use. See Section 7.2 for Protocol Layer use of `SinkTxNG` and `SinkTxOk` for Collision Avoidance.
4. The PHY Layer **Shall** monitor the channel for data transmission and only initiate transmissions when the CC bus is Idle (see Section 5.2.2.1).
5. The CC bus Idle condition **Shall** be checked immediately prior to transmission.
6. Transmission **Shall** only start if the CC bus Idle condition is present, and if the conditions detailed in Section 5.3.4.9 are met.
7. If transmission cannot be initiated due to the CC bus not being Idle, the Packet **Shall** be discarded and the PHY Layer **Shall** signal to the Protocol Layer as soon as CC becomes Idle that the Message has been discarded.
**Table 5.1. Rp values used for Collision Avoidance**
| Parameter Name | [USB-C] Source Rp | Description<sup>1</sup> |
|---|---|---|
| `SinkTxNG` | 1.5A@5V | Sink Transmit "No Go"<br>• The Sink is not allowed to start an AMS.<br>• The Source is allowed to start an AMS. |
| `SinkTxOK` | 3A@5V | Sink Transmit "OK"<br>• The Sink is allowed to start an AMS.<br>• The Source is not allowed to start an AMS. |
1. See Section 7.2.
#### 5.2.2.1. Definition of Idle
BMC Collision Avoidance is performed by the detection of signal transitions at the receiver. Detection is active when `nTransitionCount` transitions occur at the receiver within a time window of `tTransitionWindow`. After waiting `tTransitionWindow` without detecting `nTransitionCount` transitions the CC bus **Shall** be declared Idle.
Refer to Section 5.3.4.9 for details of when transmissions **May** start.
## 5.3. BMC Signaling
This section describes how Message packets are formed and sent by the transmitter, and decoded by the receiver.
### 5.3.1. Transmission
The PHY Layer will make a transmission upon Request from the Protocol Layer. The Protocol Layer **May** Request several types of transmissions:
- Start of Packet Sequences (see Section 5.3.1.1.3). Note: the alias, SOP*, refers to any of these.
<!-- page 87 -->
- SOP Message
- SOP' Message
- SOP'' Message
- SOP'_Debug Message
- SOP"_Debug Message
- Hard Reset
- Cable Reset
#### 5.3.1.1. Packet Formation
The following rules apply to Packet formation.
1. The Packet format is shown in Figure 5.1. The Packet format **Shall** consist of
a. a Preamble,
b. an SOP* (see Section 5.3.1.1.3),
c. Packet data including the Message Header (4b5b encoded),
d. a CRC (4b5b encoded) (see Section 5.3.1.1.4),
e. and an EOP (see Section 5.3.1.1.5).
2. Once 4b/5b encoded, the entire Packet **Shall** be transmitted using BMC over CC.
The Protocol Layer delivers the Payload data bytes, and specifies which SOP* sequence to use.
Figure 6.2 shows how Message packets are constructed. The PHY layer forms the Packet from the given Payload as shown in the Figure 5.1 and outlined in following steps:
1. Example GoodCRC Message data from the Protocol Layer.
2. Calculates and adds the CRC value to the Message.
3. The calculated CRC value is reformatted into LSB first order.
4. Bytes are reformatted into nibble order.
5. The data is encoded (4b5b) and then packetized with the Preamble and the selected SOP*.
<!-- page 88 -->
**Figure 5.1. Transmit Packet Format**
![Figure 5.1. Transmit Packet Format](05-pd-communications-physical-layer/figure-5.1.png)
<!-- page 89 -->
##### 5.3.1.1.1. Preamble
The Preamble is used to alert the receiver to wake and begin receiving. Preamble formation is defined by the following:
1. The Preamble **Shall** consist of a 64-bit sequence of alternating 0s and 1s, starting with a "0" and ending with a "1".
2. The Preamble **Shall Not** be 4b/5b encoded.
3. The Preamble **Shall** be BMC encoded.
##### 5.3.1.1.2. Symbol Encoding
Except for the Preamble, all data in the Packet is encoded with a 4b5b line code. This encodes 4-bit data to 5-bit symbols for transmission and decodes 5-bit symbols to 4-bit data for consumption by the receiver. The following rules apply to encoding.
1. Any K-code is already a 5b value and **Shall** not be encoded further.
2. The header and data **Shall** be 4b5b encoded.
3. The 5b code values in Table 5.2 **Shall** be used for K-codes and 4b data.
**Table 5.2. K-codes and 4b5b symbol encoding**
| Symbol Name | 4b Upper or Lower Nibble<br>$d_7d_6d_5d_4$ or $d_3d_2d_1d_0$ | 5b Symbol<br>$b_4b_3b_2b_1b_0$ | Description |
|---|---|---|---|
| 0 | `0000` | `11110` | hex data 0 |
| 1 | `0001` | `01001` | hex data 1 |
| 2 | `0010` | `10100` | hex data 2 |
| 3 | `0011` | `10101` | hex data 3 |
| 4 | `0100` | `01010` | hex data 4 |
| 5 | `0101` | `01011` | hex data 5 |
| 6 | `0110` | `01110` | hex data 6 |
| 7 | `0111` | `01111` | hex data 7 |
| 8 | `1000` | `10010` | hex data 8 |
| 9 | `1001` | `10011` | hex data 9 |
| A | `1010` | `10110` | hex data A |
| B | `1011` | `10111` | hex data B |
| C | `1100` | `11010` | hex data C |
| D | `1101` | `11011` | hex data D |
| E | `1110` | `11100` | hex data E |
| F | `1111` | `11101` | hex data F |
| Sync-1 | K-code | `11000` | Start synch #1 |
| Sync-2 | K-code | `10001` | Start synch #2 |
| RST-1 | K-code | `00111` | Hard Reset #1 |
| RST-2 | K-code | `11001` | Hard Reset #2 |
| EOP | K-code | `01101` | EOP End of Packet |
| | Error | `00000` | **Shall Not** be used |
| | Error | `00001` | **Shall Not** be used |
| | Error | `00010` | **Shall Not** be used |
| | Error | `00011` | **Shall Not** be used |
| | Error | `00100` | **Shall Not** be used |
| | Error | `00101` | **Shall Not** be used |
| Sync-3 | K-code | `00110` | Start synch #3 |
| | Error | `01000` | **Shall Not** be used |
| | Error | `01100` | **Shall Not** be used |
| | Error | `10000` | **Shall Not** be used |
| | Error | `11111` | **Shall Not** be used |
<!-- page 90 -->
##### 5.3.1.1.3. Start of Packet Sequences (SOP*)
Different SOP* sequences are used depending on the target receiver. A receiver will ignore some SOP* sequences. For example, a Cable Plug will ignore an incoming Message that uses the SOP sequence.
When the Protocol Layer requests a transmission it also specifies which SOP* sequence to use.
**Table 5.3. K-codes for SOP\* Sequences**
| SOP* Sequence | K-code1 | K-code2 | K-code3 | K-code4 |
|---|---|---|---|---|
| SOP | Sync-1 | Sync-1 | Sync-1 | Sync-2 |
| SOP' | Sync-1 | Sync-1 | Sync-3 | Sync-3 |
| SOP" | Sync-1 | Sync-3 | Sync-1 | Sync-3 |
| SOP'_Debug | Sync-1 | RST-2 | RST-2 | Sync-3 |
| SOP''_Debug | Sync-1 | RST-2 | Sync-3 | Sync-2 |
##### 5.3.1.1.4. CRC
A CRC-32 (32-bit) calculated value is used to validate a Message. CRC-32 protects the data integrity of the Message. The CRC-32 requirements as defined as follows:
1. The CRC-32 **Shall** be calculated for all bytes of the Payload except for the Preamble, SOP*, and EOP.
2. The CRC-32 polynomial **Shall** be = `04C1_1DB7h`.
3. The CRC-32 Initial value **Shall** be = `FFFF_FFFFh`.
4. The CRC-32 calculation **Shall** begin at byte 0, bit 0 and continue to bit 7 of each byte of the Packet.
5. The remainder of CRC-32 **Shall** be complemented.
6. The residual of CRC-32 **Shall** be `C704 DD7Bh`.
Note: The CRC implementation is identical to the one used in [USB3].
##### 5.3.1.1.5. End-Of-Packet (EOP)
1. The EOP **Shall** be a single EOP K-code as defined in Figure 5.1.
2. The EOP **Shall** mark the end of the CRC calculation and **Shall** not be included in the CRC calculation.
#### 5.3.1.2. Resets
A Hard Reset or Cable Reset transmission is sent upon Request from the Protocol Layer and does not include any Payload data. The format of a Hard Reset or a Cable Reset transmission is defined in Figure 5.2. The K-codes transmitted for each is shown in Table 5.4.
<!-- page 91 -->
**Figure 5.2. Line Format for Hard Reset and Cable**
![Figure 5.2. Line Format for Hard Reset and Cable](05-pd-communications-physical-layer/figure-5.2.png)
**Table 5.4. K-codes for Resets**
| Name | K-code1 | K-code2 | K-code3 | K-code4 |
|---|---|---|---|---|
| Hard Reset | RST-1 | RST-1 | RST-1 | RST-2 |
| Cable Reset | RST-1 | Sync-1 | RST-1 | Sync-3 |
##### 5.3.1.2.1. Hard Reset
When the Protocol Layer requests a Hard Reset, the procedure for sending a Hard Reset is as follows:
- If the PHY Layer is currently sending a Message, the Message **Shall** be interrupted by sending an EOP K-code and discarding the rest of the Message.
- If CC is not Idle, the PHY **Shall** wait for it to become Idle (see Section 5.2.2.1).
- The PHY **Shall** wait `tInterFrameGap` after the CC bus becomes Idle and send the Hard Reset Signaling.
- The transmitter **Shall** disable the channel (i.e., stop sending and receiving), reset the PHY Layer and inform the Protocol Layer that the PHY Layer has been reset.
- The PHY shall re-enable the channel when requested by the Protocol Layer.
### 5.3.2. Reception
The following describes the Message reception:
1. When enabled, the PHY Layer **Shall** be able to receive Hard Resets.
2. The Protocol Layer **Shall** inform the PHY Layer which SOP* sequences to receive, and whether or not to receive Cable Resets.
3. The PHY Layer **Shall** detect an incoming transmission and decode the symbols starting with K-code1
<!-- page 92 -->
4. The PHY shall report what is received to the Protocol Layer as necessary.
5. If the Protocol Layer has not configured the PHY Layer to process the SOP* type for the incoming transmission, then the PHY Layer **Shall** ignore the incoming transmission.
6. Otherwise, any time the PHY Layer receives a transmission it **Shall** inform the Protocol Layer of the type of Frame received (Hard Reset, Cable Reset, or SOP* type) and provide the Payload data (if any).
The PHY Layer decodes the Packet as shown in Figure 5.3 and outlined in following steps:
1. The incoming transmission arrives as Symbols.
2. The data is 4b5b decoded into nibbles.
3. The nibble data is formatted into bytes.
4. Arriving bytes are passed through the CRC calculation (until an EOP Idle condition is detected).
5. If CRC is correct, the SOP* type and Payload data are passed to the Protocol Layer .
<!-- page 93 -->
**Figure 5.3. Receive Packet Interpretation.**
![Figure 5.3. Receive Packet Interpretation.](05-pd-communications-physical-layer/figure-5.3.png)
<!-- page 94 -->
#### 5.3.2.1. Preamble
The Preamble may be used to wake the receiver. The receiver may process as much or as little of the Preamble as necessary to allow it to decode the received K codes.
#### 5.3.2.2. Ordered Sets (K-codes)
The K-codes following the Preamble form an Ordered Set. The following rules are used:
1. The PHY Layer **Shall** decode the K-codes and compare to a list of ordered sets to determine whether to continue processing or ignore the rest of the transmission. The two kinds of ordered sets are SOP* sequences listed in Table 5.3 and Reset sequences listed in Table 5.4.
2. The PHY Layer **Shall** report the detected ordered set to the Protocol Layer, unless it has been configured to ignore that ordered set.
3. The receiver **Shall** search for all four K-codes.
4. When the receiver finds all four K-codes in the correct place, it **Shall** interpret this as a **Valid** ordered set.
a. When the receiver finds three out of four K-codes in the correct place, it **May** interpret this as a **Valid** ordered set.
b. The receiver **Should** ensure that all four K-codes are **Valid** to avoid ambiguity in detection (see Table 5.5).
**Table 5.5. Validation of Ordered Sets**
| | 1st code | 2nd code | 3rd code | 4th code |
|---|---|---|---|---|
| **Valid**[^1] | Corrupt | K-code | K-code | K-code |
| **Valid**[^1] | K-code | Corrupt | K-code | K-code |
| **Valid**[^1] | K-code | K-code | Corrupt | K-code |
| **Valid**[^1] | K-code | K-code | K-code | Corrupt |
| **Valid**[^2] (perfect) | K-code | K-code | K-code | K-code |
| **Invalid** (example) | K-code | Corrupt | K-code | Corrupt |
[^1]: **May** be interpreted as a **Valid** ordered set.
[^2]: **Shall** be interpreted as a **Valid** ordered set.
#### 5.3.2.3. Payload Processing
The following requirements apply to processing the Payload:
1. After detecting an SOP* sequence which has been configured to process, the PHY Layer **Shall** decode the trailing 5b symbols until it detects the EOP K-code or the CC-line becomes Idle (see Section 5.2.2.1). The PHY Layer **Shall** monitor for invalid 5b symbols during this step.
2. After the EOP is detected, the PHY Layer **Shall** decode each 5b symbol of the Payload into a 4b nibble, and then form the nibbles into bytes.
3. The CRC-residual **Shall** be checked with the Payload data. The EOP is excluded from the CRC check.
4. If the CRC is not good or any error was detected while decoding the 5b symbols or the CC-line became Idle before an EOP was detected, the whole transmission **Shall** be **Discarded**.
5. If the CRC is good, the SOP* and the decoded data are passed to the Protocol Layer.
<!-- page 95 -->
### 5.3.3. Electrical Characteristics for Transmission and Reception
This section describes how the bit values are translated into electrical signals on the CC wire.
Bi-phase Mark Coding (BMC) is the PHY Layer Signaling Scheme for carrying USB Power Delivery Messages.
Bi-phase Mark Coding is a Version of Manchester coding (see [IEC 60958-1]). In BMC, there is a transition at the start of every bit time (UI) and there is a second transition in the middle of the UI when a 1 is transmitted. BMC is effectively DC balanced, (each 1 is DC balanced and two successive zeros are DC balanced, regardless of the number of intervening 1's). It has bounded disparity (limited to 1 bit over an arbitrary Packet, so a very low DC level).
Figure 5.4 illustrates Bi-phase Mark Coding. This example shows the transition from a Preamble to the Sync-1 K-codes of the SOP Ordered Set at the start of a Message.
Note: Other K-codes can occur after the Preamble for Signaling such as Hard Reset and Cable Reset.
**Figure 5.4. BMC Example**
![Figure 5.4. BMC Example](05-pd-communications-physical-layer/figure-5.4.png)
### 5.3.4. Encoding and Signaling
BMC uses DC coupled baseband Signaling on CC. Figure 5.5 shows a block diagram for a Transmitter and Figure 5.6 shows a block diagram for the corresponding Receiver.
**Figure 5.5. BMC Transmitter Block Diagram**
![Figure 5.5. BMC Transmitter Block Diagram](05-pd-communications-physical-layer/figure-5.5.png)
<!-- page 96 -->
**Figure 5.6. BMC Receiver Block Diagram**
![Figure 5.6. BMC Receiver Block Diagram](05-pd-communications-physical-layer/figure-5.6.png)
The following requirements apply to the transmitting and receiving of the signal:
1. The USB PD baseband signal **Shall** be driven on the CC wire with a level vSwing by a slew-rate limited tristate driver (see min rise/fall time in Section 5.5.2). This slew rate limiting reduces coupling to adjacent signal wires and can be performed with driver design or an RC filter at the driver output. See Figure 5.7.
2. When sending the Preamble, the transmitter **Shall** start by transmitting a low level. The transmitter **May** vary the start of the Preamble by tStartDrivemin.
3. The receiver **Shall** tolerate the loss of the first edge.
4. The transmitter **Shall** terminate the final bit of the Frame by a trailing edge to help ensure that the receiver clocks the final bit. If the trailing edge results in the transmitter driving CC low. See Figure 5.8 and Figure 5.8.
5. The transmitter **Shall** continue to drive CC low for tHoldLowBMC and **Should** release CC to high impedance as soon as possible after min tHoldLowBMC and **Shall** release CC by max tEndDriveBMC.
6. If the trailing edge results in the transmitter driving CC high (i.e., the final half-UI of the Frame is low, see Figure 5.10 and Figure 5.11):
a. The transmitter **Shall** continue to drive CC high for 1 UI.
b. Then the transmitter **Shall** drive CC low for tHoldLowBMC and **Should** release CC to high impedance as soon as possible after min tHoldLowBMC and **Shall** release CC by max tEndDriveBMC.
Figure 5.9, Figure 5.10, and Figure 5.11 also show the tInterFrameGap before the next Packet. Beyond the tInterFrameGap, there is no requirement to maintain a timing phase relationship between back-to-back Packets.
**Figure 5.7. BMC Encoded Start of Preamble**
![Figure 5.7. BMC Encoded Start of Preamble](05-pd-communications-physical-layer/figure-5.7.png)
<!-- page 97 -->
**Figure 5.8. Transmitting or Receiving BMC Encoded Frame Terminated by Zero with High-to-Low Last Transition**
![Figure 5.8. Transmitting or Receiving BMC Encoded Frame Terminated by Zero with High-to-Low Last Transition](05-pd-communications-physical-layer/figure-5.8.png)
**Figure 5.9. Transmitting or Receiving BMC Encoded Frame Terminated by One with High-to-Low Last Transition**
![Figure 5.9. Transmitting or Receiving BMC Encoded Frame Terminated by One with High-to-Low Last Transition](05-pd-communications-physical-layer/figure-5.9.png)
**Figure 5.10. Transmitting or Receiving BMC Encoded Frame Terminated by Zero with Low-to-High Last Transition**
![Figure 5.10. Transmitting or Receiving BMC Encoded Frame Terminated by Zero with Low-to-High Last Transition](05-pd-communications-physical-layer/figure-5.10.png)
<!-- page 98 -->
**Figure 5.11. Transmitting or Receiving BMC Encoded Frame Terminated by One with High-to-Low Last Transition**
![Figure 5.11. Transmitting or Receiving BMC Encoded Frame Terminated by One with High-to-Low Last Transition](05-pd-communications-physical-layer/figure-5.11.png)
#### 5.3.4.1. Transmit Mask
The transmit mask rules are defined by the following:
1. The transmitted signal **Shall Not** violate the masks defined in Figure 5.12, Figure 5.13, Table 5.6 and Table 5.7 at the output of a load equivalent to the cable model and receiver load model described in Section 5.3.4.3.
2. The masks apply to the full range of Rp/Rd values as defined in [USB-C].
3. The transmitted signal **Shall** have a rise time ≤tRise and is enforced by the Tx inner masks.
4. The transmitted signal **Shall** have a fall time ≤tFall and is enforced by the Tx inner masks.
5. The measurement of the transmit mask **Shall** not include ground offset when current is flowing in the cable and is measured at the connector.
<!-- page 99 -->
**Figure 5.12. BMC Tx 'ONE' Mask.**
![Figure 5.12. BMC Tx 'ONE' Mask.](05-pd-communications-physical-layer/figure-5.12.png)
**Figure 5.13. BMC Tx 'ZERO' Mask.**
![Figure 5.13. BMC Tx 'ZERO' Mask.](05-pd-communications-physical-layer/figure-5.13.png)
<!-- page 100 -->
**Table 5.6. BMC Tx Mask Definition, X Values**
| Parameter Name | Value | Unit | Description |
|---|---|---|---|
| X1Tx | 0.015 | UI | Left Edge of Mask see Figure 5.12 and Figure 5.13 |
| X2Tx | 0.07 | UI | see Figure 5.12 and Figure 5.13 |
| X3Tx | 0.15 | UI | see Figure 5.12 and Figure 5.13 |
| X4Tx | 0.25 | UI | see Figure 5.12 and Figure 5.13 |
| X5Tx | 0.35 | UI | see Figure 5.12 |
| X6Tx | 0.43 | UI | see Figure 5.12 |
| X7Tx | 0.485 | UI | see Figure 5.12 |
| X8Tx | 0.515 | UI | see Figure 5.12 |
| X9Tx | 0.57 | UI | see Figure 5.12 |
| X10Tx | 0.65 | UI | see Figure 5.12 |
| X11Tx | 0.75 | UI | see Figure 5.12 |
| X12Tx | 0.85 | UI | see Figure 5.12 and Figure 5.13 |
| X13Tx | 0.93 | UI | see Figure 5.12 and Figure 5.13 |
| X14Tx | 0.985 | UI | Right Edge of Mask see Figure 5.12 and Figure 5.13 |
**Table 5.7. BMC Tx Mask Definition, Y Values**
| Parameter Name | Value | Unit | Description |
|---|---|---|---|
| Y1Tx | -0.075 | V | Lower bound of outer mask see Figure 5.12 and Figure 5.13 |
| Y2Tx | 0.075 | V | Lower bound of inner mask see Figure 5.12 and Figure 5.13 |
| Y3Tx | 0.15 | V | see Figure 5.12 and Figure 5.13 |
| Y4Tx | 0.325 | V | see Figure 5.12 and Figure 5.13 |
| Y5Tx | 0.5625 | V | Inner mask vertical midpoint see Figure 5.12 and Figure 5.13 |
| Y6Tx | 0.8 | V | see Figure 5.12 and Figure 5.13 |
| Y7Tx | 0.975 | V | see Figure 5.12 and Figure 5.13 |
| Y8Tx | 1.04 | V | see Figure 5.12 and Figure 5.13 |
| Y9Tx | 1.2 | V | Upper bound of outer mask see Figure 5.12 and Figure 5.13 |
#### 5.3.4.2. Receive Masks
The receive mask requirements are defined by the following:
1. When acting as a Source, a Port **Shall** be capable of receiving a signal that complies with the receive mask defined in vNoiseActive between power neutral and Source offsets. Figure 5.14, Figure 5.15 and Table 5.8. The Source Rx mask is bounded by sweeping a Tx mask compliant signal, with added vNoiseActive between power neutral and Source offsets.
2. When acting as a Sink, a Port **Shall** be capable of receiving a signal that complies with the mask defined in Figure 5.16, Figure 5.17, Table 5.8, and vNoiseActive between power neutral and Sink offsets. The Sink
<!-- page 101 -->
Rx mask is bounded by sweeping a Tx mask compliant signal, with added `vNoiseActive` between power
neutral and Sink offsets.
3. When power neutral (neither sinking nor sourcing), a Port **Shall** be capable of receiving a signal that complies with the mask defined in Figure 5.18, Figure 5.19 and Table 5.8.
4. Cable Plugs **Shall** meet the receiver requirements for both a Source and a Sink during any transmission using the BMC Signaling Scheme.
5. The receiver sensitivity **Shall** be set such that the receiver does not treat noise on an un-driven signal path as an incoming signal. Signal amplitudes below `vNoiseIdle` max **Shall** be treated as noise when BMC is Idle.
6. The receiver **Shall** tolerate the loss of the first edge
The parameters used in the masks are specified to be appropriate to either edge triggered or oversampling receiver implementations.
The masks are defined for 'ONE' and 'ZERO' separately as BMC enforces a transition at the midpoint of the Unit Interval while a 'ONE' is transmitted.
The Rx masks are defined to bound the Rx noise after the Rx bandwidth limiting filter with the time constant `tRxFilter` has been applied.
The boundaries of Rx outer mask, `Y1Rx` and `Y5Rx`, are specified according to `vSwing` max and accommodate half of `vNoiseActive` from cable noise coupling and the signal offset `vIRDropGNDC` due to the ground offset when current is flowing in the cable.
The vertical dimension of the Rx inner mask, `Y4Rx` - `Y2Rx`, for power neutral is derived by reducing the vertical dimension of the Tx inner mask, `Y7Tx` - `Y3Tx`, at time location `X3Tx` by `vNoiseActive` to account for cable noise coupling. The received signal is composed of a waveform compliant to the Tx mask plus `vNoiseActive`.
The vertical dimension of the Rx inner mask for sourcing power is derived by reducing the vertical dimension of the Tx inner mask by `vNoiseActive` and `vIRDropGNDC` to account for both cable noise coupling and signal DC offset.
The received signal is composed of a waveform compliant to the Tx mask plus the maximum value of `vNoiseActive` plus `vIRDropGNDC` where the `vIRDropGNDC` value transitions between the minimum and the maximum values as allowed in this spec.
The vertical dimension of the Rx inner mask for sinking power is derived by reducing the vertical dimension of the Tx inner mask by `vNoiseActive` max and `vIRDropGNDC` max for account for both cable noise coupling and signal DC offset. The received signal is composed of a waveform compliant to the Tx mask plus the maximum value of `vNoiseActive` plus `vIRDropGNDC` where the `vIRDropGNDC` value transitions between the minimum and the maximum values as allowed in this spec.
The center line of the Rx inner mask, `Y3Rx`, is at half of the nominal `vSwing` for power neutral, and is shifted up by half of `vIRDropGNDC` max for sourcing power and is shifted down by half of `vIRDropGNDC` max for sinking power.
<!-- page 102 -->
**Figure 5.14. BMC Rx 'ONE' Mask when Sourcing Power**
![BMC Rx 'ONE' Mask when Sourcing Power](05-pd-communications-physical-layer/figure-5.14.png)
**Figure 5.15. BMC Rx 'ZERO' Mask when Sourcing Power**
![BMC Rx 'ZERO' Mask when Sourcing Power](05-pd-communications-physical-layer/figure-5.15.png)
<!-- page 103 -->
**Figure 5.16. BMC Rx 'ONE' Mask when Sinking Power**
![BMC Rx 'ONE' Mask when Sinking Power](05-pd-communications-physical-layer/figure-5.16.png)
**Figure 5.17. BMC Rx 'ZERO' Mask when Sinking Power**
![BMC Rx 'ZERO' Mask when Sinking Power](05-pd-communications-physical-layer/figure-5.17.png)
<!-- page 104 -->
**Figure 5.18. BMC Rx 'ONE' Mask when Power Neutral**
![BMC Rx 'ONE' Mask when Power Neutral](05-pd-communications-physical-layer/figure-5.18.png)
**Figure 5.19. BMC Rx 'ZERO' Mask when Power Neutral**
![BMC Rx 'ZERO' Mask when Power Neutral](05-pd-communications-physical-layer/figure-5.19.png)
**Table 5.8. BMC Rx Mask Definition**
| Parameter Name | Value | Unit | Description |
|---|---|---|---|
| `X1Rx` | 0.07 | UI | Left Edge of Mask<br>see Figure 5.14 through Figure 5.19 |
| `X2Rx` | 0.15 | UI | Top Edge of Mask<br>see Figure 5.14 through Figure 5.19 |
| `X3Rx` | 0.35 | UI | see Figure 5.14 through Figure 5.19 |
| `X4Rx` | 0.43 | UI | see Figure 5.14 through Figure 5.19 |
| `X5Rx` | 0.57 | UI | see Figure 5.14 through Figure 5.19 |
| `X6Rx` | 0.65 | UI | see Figure 5.14 through Figure 5.19 |
| `X7Rx` | 0.85 | UI | see Figure 5.14 through Figure 5.19 |
| `X8Rx` | 0.93 | UI | see Figure 5.14 through Figure 5.19 |
| `Y1Rx` | -0.3325 | V | Lower bound of Outer Mask<br>see Figure 5.14 through Figure 5.19 |
| `Y2Rx` | `Y3Rx` – 0.205 when sourcing power¹ or sinking power¹.<br>`Y3Rx` – 0.33 when power neutral¹. | V | Lower Bound of Inner Mask<br>see Figure 5.14 through Figure 5.19 |
| `Y3Rx` | 0.6875 Sourcing Power¹.<br>0.5625 Power Neutral¹.<br>0.4375 Sinking Power¹. | V | Center line of Inner Mask<br>see Figure 5.14 through Figure 5.19 |
| `Y4Rx` | `Y3Rx` + 0.205 when sourcing power¹ or sinking power¹.<br>`Y3Rx` + 0.33 when power neutral¹. | V | Upper bound of Inner mask<br>see Figure 5.14 through Figure 5.19 |
| `Y5Rx` | 1.5325 | V | Upper bound of the Outer mask<br>see Figure 5.14 through Figure 5.19 |
1. The position of the center line of the Inner Mask is dependent on whether the receiver is Sourcing or Sinking power or is Power Neutral (see earlier in this section).
<!-- page 105 -->
#### 5.3.4.3. Transmit Load Model
The transmit load requirements are defined by the following:
1. The transmitter load model **Shall** be equivalent to the circuit outlined in Figure 5.20 for a Source and Figure 5.21 for a Sink. It is formed by the concatenation of a cable load model and a receiver load model. See [USB-C] for details of the `Rp` and `Rd` resistors.
The parameters `zCable_CC`, `tCableDelay_CC` and `cCablePlug_CC` are defined in [USB-C].
The transmitter system components `rOutput` and `cShunt` are illustrated for **Informative** purposes, and do not form part of the transmitter load model. See Section 5.5.2 for a description of the transmitter system design.
The transmitter load model assumes that there are no other return currents on the ground path.
2. The value of the modeled cable inductance, `La`, (in nH) **Shall** be calculated from the following formula:
$La = tCableDelay\_CC_{max} \times zCable\_CC_{min}$
where `tCableDelay_CC` is the modeled signal propagation delay through the cable, and `zCable_CC` is the modeled cable impedance.
The modeled cable inductance is 640nH for a cable with `zCable_CC`min = 32Ω and `tCableDelay_CC`max = 20ns.
3. The value of the modeled cable capacitance, `Ca`, (in pF) **Shall** be calculated from the following formula:
$Ca = tCableDelay\_CC_{max} \div zCable\_CC_{min}$
<!-- page 106 -->
The modeled cable capacitance is `Ca` = 625pF for a cable with `zCable_CC`min = 32Ω and `tCableDelay_CC`max = 20ns. Therefore, `Ca` ÷ 2 = 312.5pF.
4. `cCablePlug_CC` models the capacitance of the plug at each end of the cable. `cReceiver` models the capacitance of the receiver and `rBmcRx` models the receiver input impedance.
. The maximum values **Shall** be used in each case.
**Figure 5.20. Transmitter Load Model for BMC Tx from a Source**
![Transmitter Load Model for BMC Tx from a Source](05-pd-communications-physical-layer/figure-5.20.png)
**Figure 5.21. Transmitter Load Model for BMC Tx from a Sink**
![Transmitter Load Model for BMC Tx from a Sink](05-pd-communications-physical-layer/figure-5.21.png)
#### 5.3.4.4. Cable Plug Transceivers.
The BMC Signaling Scheme is suitable for use in Multi-Drop configurations containing multiple BMC transceivers
Connected to the CC wire. Cable Plugs with transceivers on the CC are such a case.
Figure 5.22 illustrates a typical Multi-Drop configuration with two DRPs and cable transceivers.
<!-- page 107 -->
**Figure 5.22. Example Multi-Drop Configuration showing two DRPs and two Cable Transceivers**
![Example Multi-Drop Configuration showing two DRPs and two Cable Transceivers](05-pd-communications-physical-layer/figure-5.22.png)
The following requirements apply to Cable Plug transceivers:
1. The Cable Plug transceiver **Shall** obey all the electrical characteristics specified in this section except for those relating to capacitance.
2. The maximum capacitance allowed for the Cable Plug transceiver on the CC wire, when not driving the line, **Shall** be `cCablePlug_CC` as defined in [USB-C].
3. There are no constraints as to the distance of the Cable Plug transceiver from the end of the wire. The Cable Plug transceiver(s) **May** be located anywhere along the cable including the plugs.
4. The Cable Plug transceiver **Shall** account for any ground offset based on its location.
5. The Cable Plug transceiver shall not add significant reflections.
#### 5.3.4.5. Transceiver with VCONN Source Capability
It is possible to have a configuration at Attach where one or both Ports can be a VCONN Source. An example of a
VCONN sourcing capable DFP Attached to a UFP without VCONN sourcing capability is shown in Figure 5.23.
1. The capacitance on the CC pin for a Port that is able to supply VCONN but is not actively supplying VCONN **Shall** still meet the `cReceiver` requirements when not transmitting.
**Figure 5.23. Example Multi-Drop Configuration showing a DFP and UFP with a VCONN Source**
![Example Multi-Drop Configuration showing a DFP and UFP with a VCONN Source](05-pd-communications-physical-layer/figure-5.23.png)
<!-- page 108 -->
#### 5.3.4.6. Capacitance when not transmitting
The following rules apply for capacitance when not transmitting:
1. `cReceiver` is the capacitance that a DFP or UFP **Shall** present on the CC line when the DFP or UFP's receiver is not transmitting on the line.
2. The transmitter **May** have more capacitance than `cReceiver` while driving the CC line, but **Shall** meet the waveform mask requirements.
3. Once transmission is complete, the transmitter **Shall** disengage capacitance in excess of `cReceiver` from the CC wire within `tInterFrameGap`.
#### 5.3.4.7. Source Output Impedance
Source output impedance `zDriver` is determined by the driver resistance and the shunt capacitance of the Source
and is hence a frequency dependent term. `zDriver` impacts the noise ingression in the cable. It is specified such
that the noise at the Receiver is bounded.
`zDriver` is defined by the following equation:
$zDriver = rOutput \div (1 + s \times rOutput \times cShunt)$
**Figure 5.24. Transmitter diagram illustrating zDriver**
![Transmitter diagram illustrating zDriver](05-pd-communications-physical-layer/figure-5.24.png)
1. `cShunt` **Shall Not** cause a violation of `cReceiver` when not transmitting.
#### 5.3.4.8. Bit Rate Drift
Limits on the drift in `fBitRate` are set to help low-complexity receiver implementations.
`fBitRate` is the reciprocal of the average bit duration from the previous 32 bits at a given portion of the Packet.
1. The change in `fBitRate` during a Packet **Shall** be less than `pBitRate`.
2. The reference bit rate (refBitRate) is the average `fBitRate` over the last 32 bits of the *Preamble*. `fBitRate` throughout the Packet, including the EOP, **Shall** be within `pBitRate` of refBitRate. `pBitRate` is expressed as a percentage:
$pBitRate = |fBitRate - refBitRate| \div refBitRate \times 100\%$
3. The transmitter **Shall** have the same `pBitRate` for all Packet types. The BIST Carrier Mode and Bit Stream signals are continuous signals without a Payload.
4. When checking `pBitRate` any set of 1044 bits (20 bit SOP followed by 1024 PRBS bits) within a continuous signal **May** be considered as the part of the Packet following the Preamble and the 32 preceding bits considered to be the last 32 bits of the Preamble used to compute refBitRate.
<!-- page 109 -->
#### 5.3.4.9. Inter-Frame Gap
Figure 5.26, "Inter-Frame Gap Timings" illustrates the inter-Frame gap timings.
**Figure 5.25. Inter-Frame Gap Timings**
![Inter-Frame Gap Timings](05-pd-communications-physical-layer/figure-5.25.png)
Inter-Frame Gap timings are governed by:
1. The transmitter **Shall** drive the CC bus for no longer than `tEndDriveBMC` after transmitting the final bit of the Frame.
2. Before starting to transmit the next Frame's Preamble the transmitter of the next Frame **Shall** ensure that it waits for `tInterFrameGap` after either:
a. Transmitting the previous Frame, for example sending the next Message in an AMS immediately after having sent a GoodCRC Message, or
b. Receiving the previous Frame, for example when responding to a received Message with a GoodCRC Message, or
c. Observing an Idle condition on CC (see Section 5.2.2). In this case the Port is waiting to initiate an AMS observes Idle (see Section 5.2.2.1) and then waits `tInterFrameGap` before transmitting the Frame. See also Section 5.2.2 for details on when an AMS can be initiated.
d. The transmitter of the next Frame **May** vary the start of the Preamble by `tStartDrive` (see Section 5.3.4).
Also see Section 5.3.4 for figures detailing the timings relating to transmitting, receiving, and observing Idle in relating to Frames.
#### 5.3.4.10. Shorting of Transmitter Output
A Transmitter in a Port or Cable Plug **Shall** tolerate having its output be shorted to ground for `tFRSwapTx` (max). This is due to the potential for Fast Role Swap to be signaled by the Receiver while the Transmitter is in the process of transmitting (see: Chapter 10, Fast Role Swap (FRS) for details).
## 5.4. Built in Self-Test (BIST)
The following sections define BIST functionality which **Shall** be supported.
### 5.4.1. BIST Carrier Mode
In BIST Carrier Mode, the PHY Layer **Shall** send out a BMC encoded continuous string of alternating "1"s and "0"s. This enables the measurement of power supply noise and frequency drift. The Protocol Layer tells the PHY when to enter and exit this Mode.
Note: This transmission is a purely a sequence of alternating bits and **Shall Not** be formatted as a Packet. See also Section 6.4.3.
<!-- page 110 -->
## 5.5. PD Communications Physical Layer Parameters
### 5.5.1. BMC Common Parameters
The electrical requirements specified in Table 5.9 **Shall** apply to both the transmitter and receiver.
**Table 5.9. BMC Common Requirements**
| Parameter Name | Min Value | Nom Value | Max Value | Unit | Description |
|---|---|---|---|---|---|
| `fBitRate` | 270 | 300 | 330 | Kbps | Bit Rate |
| `tUnitInterval` | 3.03 | | 3.70 | µs | Unit Interval$^1$ (= 1÷`fBitRate`) |
1. Denotes the time to transmit an unencoded data bit, not the shortest high or low times on the wire after encoding with BMC. A single data bit cell has duration of 1UI, but a data bit cell with value 1 will contain a centrally placed 01 or 10 transition in addition to the transition at the start of the cell.
### 5.5.2. BMC Transmitter Parameters
The transmitter **Shall** meet the specifications defined in Table 5.10.
**Table 5.10. BMC Transmitter Parameters**
| Parameter Name | Min Value | Nom Value | Max Value | Unit | Description |
|---|---|---|---|---|---|
| `pBitRate` | | | 0.25 | % | Maximum difference between the bit-rate during the part of the Packet following the Preamble and the reference bit-rate. The reference bit rate is the average bit rate of the last 32 bits of the Preamble. |
| `tEndDriveBMC` | | | 23 | µs | Time to cease driving the line after the end of the last bit of the Frame. Min value is limited by `tHoldLowBMC`. |
| `tFall` | 300 | | | ns | Fall Time. 10% and 90% amplitude points when unloaded. |
| `tHoldLowBMC` | 1 | | | µs | Time to cease driving the line after the final high-to-low transition. Max value is limited by `tEndDriveBMC`. |
| `tInterFrameGap` | 25 | | | µs | Time from the end of last bit of a Frame until the start of the first bit of the next Preamble. |
| `tRise` | 300 | | | ns | Rise time. 10% and 90% amplitude points when unloaded. |
| `tStartDrive` | -1 | | 1 | µs | Time before the start of the first bit of the Preamble when the transmitter **Shall** start driving the line. |
| `vSwing` | 1.05 | 1.125 | 1.2 | V | Voltage Swing. Applies to both no load condition and loaded condition specified in Section 5.3.4.3". |
| `zDriver` | 33 | | 75 | Ω | Transmitter output impedance at the Nyquist frequency of [USB2] low speed (750 kHz) while the Source is driving the CC line. |
### 5.5.3. BMC Receiver Parameters
The receiver **Shall** meet the specifications defined in Table 5.11.
<!-- page 111 -->
**Table 5.11. BMC Receiver Parameters**
| Parameter Name | Min Value | Nom Value | Max Value | Unit | Description |
|---|---|---|---|---|---|
| `cReceiver` | 200 | | 600 | pF | CC receiver capacitance. The DFP or UFP system **Shall** have capacitance within this range when not transmitting on the line. |
| `nBER` | | | 10-6 | | Bit error rate, S/N = 25 dB |
| `nTransitionCount` | 3 | | | | Number of transitions to be detected to declare CC bus non-Idle. |
| `tRxFilter` | 100 | | | ns | Rx bandwidth limiting filter (digital or analog). Time constant of a single pole filter to limit broad-band noise ingression$^1$. |
| `tTransitionWindow` | 12 | | 20 | µs | Time window for detecting non-Idle |
| `vIRDropGNDC` | | | 250 | mV | Cable Ground IR Drop as specified in [USB-C]. |
| `vNoiseActive` | | | 165 | mV | Peak-to-peak noise from VBUS, [USB2]and SBU lines after the Rx band- width limiting filter with the time constant `tRxFilter` has been applied. |
| `vNoiseIdle` | | | 300 | mV | Peak-to-peak noise from VBUS, [USB2] and SBU lines after the Rx band- width limiting filter with the time constant `tRxFilter` has been applied. |
| `rBmcRx` | 1 | | | MΩ | Receiver Input Resistance |
1. Broad-band noise ingression is due to coupling in the cable interconnect.

BIN
USB_PD_R3.2/05-pd-communications-physical-layer/figure-5.1.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 393 KiB

BIN
USB_PD_R3.2/05-pd-communications-physical-layer/figure-5.10.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 40 KiB

BIN
USB_PD_R3.2/05-pd-communications-physical-layer/figure-5.11.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 44 KiB

BIN
USB_PD_R3.2/05-pd-communications-physical-layer/figure-5.12.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 82 KiB

BIN
USB_PD_R3.2/05-pd-communications-physical-layer/figure-5.13.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 69 KiB

BIN
USB_PD_R3.2/05-pd-communications-physical-layer/figure-5.14.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 52 KiB

BIN
USB_PD_R3.2/05-pd-communications-physical-layer/figure-5.15.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 43 KiB

BIN
USB_PD_R3.2/05-pd-communications-physical-layer/figure-5.16.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 48 KiB

BIN
USB_PD_R3.2/05-pd-communications-physical-layer/figure-5.17.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 48 KiB

BIN
USB_PD_R3.2/05-pd-communications-physical-layer/figure-5.18.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 62 KiB

BIN
USB_PD_R3.2/05-pd-communications-physical-layer/figure-5.19.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 51 KiB

BIN
USB_PD_R3.2/05-pd-communications-physical-layer/figure-5.2.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 26 KiB

BIN
USB_PD_R3.2/05-pd-communications-physical-layer/figure-5.20.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 38 KiB

BIN
USB_PD_R3.2/05-pd-communications-physical-layer/figure-5.21.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 36 KiB

BIN
USB_PD_R3.2/05-pd-communications-physical-layer/figure-5.22.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 57 KiB

BIN
USB_PD_R3.2/05-pd-communications-physical-layer/figure-5.23.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 49 KiB

BIN
USB_PD_R3.2/05-pd-communications-physical-layer/figure-5.24.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 29 KiB

BIN
USB_PD_R3.2/05-pd-communications-physical-layer/figure-5.25.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 15 KiB

BIN
USB_PD_R3.2/05-pd-communications-physical-layer/figure-5.3.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 407 KiB

BIN
USB_PD_R3.2/05-pd-communications-physical-layer/figure-5.4.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 29 KiB

BIN
USB_PD_R3.2/05-pd-communications-physical-layer/figure-5.5.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 17 KiB

BIN
USB_PD_R3.2/05-pd-communications-physical-layer/figure-5.6.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 23 KiB

BIN
USB_PD_R3.2/05-pd-communications-physical-layer/figure-5.7.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 32 KiB

BIN
USB_PD_R3.2/05-pd-communications-physical-layer/figure-5.8.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 45 KiB

BIN
USB_PD_R3.2/05-pd-communications-physical-layer/figure-5.9.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 45 KiB

2310
USB_PD_R3.2/06-pd-communications-protocol-message-definitions.md Normal file
View file

File diff suppressed because it is too large Load diff

BIN
USB_PD_R3.2/06-pd-communications-protocol-message-definitions/figure-6.1.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 114 KiB

BIN
USB_PD_R3.2/06-pd-communications-protocol-message-definitions/figure-6.2.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 36 KiB

BIN
USB_PD_R3.2/06-pd-communications-protocol-message-definitions/figure-6.3.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 19 KiB

BIN
USB_PD_R3.2/06-pd-communications-protocol-message-definitions/figure-6.4.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 11 KiB

BIN
USB_PD_R3.2/06-pd-communications-protocol-message-definitions/figure-6.5.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 62 KiB

BIN
USB_PD_R3.2/06-pd-communications-protocol-message-definitions/figure-6.6.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 87 KiB

BIN
USB_PD_R3.2/06-pd-communications-protocol-message-definitions/figure-6.7.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 23 KiB

BIN
USB_PD_R3.2/06-pd-communications-protocol-message-definitions/figure-6.8.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 34 KiB

BIN
USB_PD_R3.2/06-pd-communications-protocol-message-definitions/figure-6.9.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 25 KiB

1731
USB_PD_R3.2/07-pd-communications-protocol-message-usage.md Normal file
View file

File diff suppressed because it is too large Load diff

BIN
USB_PD_R3.2/07-pd-communications-protocol-message-usage/figure-7.1.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 95 KiB

BIN
USB_PD_R3.2/07-pd-communications-protocol-message-usage/figure-7.2.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 170 KiB

BIN
USB_PD_R3.2/07-pd-communications-protocol-message-usage/figure-7.3.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 264 KiB

317
USB_PD_R3.2/08-vendor-defined-message-usage-and-alternate-modes.md Normal file
View file

@ -0,0 +1,317 @@
<!-- page 241 -->
# Chapter 8. Vendor Defined Message Usage and Alternate Modes
## 8.1. Overview
This chapter describes Vendor-Defined Message (VDM) usage and Alternate Modes. VDMs allow devices to discover information from Connected Ports and Cable Plugs, and they enable Modal Operation. Additionally, VDMs can support proprietary, vendor-defined functions. Vendor-Defined Messages include Data Messages with Message Type set to Vendor_Defined and Extended Messages with Message Type set to Vendor_Defined_Extended.
## 8.2. Alternate Modes
A Device **May** support multiple Alternate Modes with one or more active at any point in time. Any interactions between them are the responsibility of the Standard or Vendor. Where there are multiple Active Modes at the same time Modal Operation **Shall** start on entry to the first Alternate Mode.
A DR_Swap Message **Shall Not** be sent during Modal Operation between the Port Partners (see Section 6.3.9).
## 8.3. General VDM Rules
VDMs **Shall Not** be used for direct power Negotiation. They **May** however, be used to alter Local Policy, affecting what is offered or consumed via the normal PD messages. VDMs **Should Not** be used where the PD Specification provides equivalent functionality, e.g., authentication or firmware update.
The following sections use the terms Initiator and Responder to identify messaging roles that participants take on relative to each other for the duration of a VDM AMS. These roles are independent of Power Capabilities, Power Role, or Data Role. The Initiator is the Port sending the initial Command Request and the Responder is the Port replying with the Command response. See: Section 8.7.
During Default Contract or Implicit Contract, Ports **Shall Not** Initiate VDMs, and Ports and Cables **Shall Ignore** any VDMs received, with the exception of Discover Identity on SOP'. See Section 8.6.1.2 for rules related to SOP' Discover Identity.
## 8.4. Unstructured VDM Rules
The following rules apply to the use of Unstructured VDMs:
- Unstructured VDMs **May** be used with SOP* Packets.
- Prior to establishing an Explicit Contract, Unstructured VDMs **Shall Not** be sent and **Shall** be **Ignored** if received.
- Only the DFP **Shall** be an Initiator of Unstructured VDMs.
- Only the UFP or a Cable Plug **Shall** be a Responder to an Unstructured VDM.
- A Port **Shall Not** initiate an Unstructured VDM AMS except during Modal Operation, where the SVID of the Unstructured VDMs is one corresponding to an Active Mode.
- When a DFP or UFP does not support Unstructured VDMs or does not recognize the VID, it **Shall** Respond with a Not_Supported Message.
<!-- page 242 -->
## 8.5. Structured VDM Rules
The following rules apply to the use of Structured VDM messages:
- Either Port **May** Initiate a Structured VDM AMS, except that the UFP **Shall Not** Initiate Enter Mode or Exit Mode commands
- A Cable Plug **Shall Not** Initiate a Structured VDM AMS.
- When a Port does not support Structured VDMs, it **Shall** Respond to any received Structured VDMs with Not_Supported Message.
- When a Cable Plug does not support Structured VDMs, any Structured VDMs received **Shall** be **Ignored**.
- When using any of the SVID-Specific Commands in the Structured VDM Header (Command field, values 16 - 31), the Responder **Shall** NAK VDMs where the Command is not recognized for the SVID.
- A Responder that supports Structured VDMs **Shall** NAK a Structured VDM with an SVID that it does not recognize.
### 8.5.1. Structured VDM Version
To ensure interoperability with existing USB PD products, USB PD products **Shall** support every Structured VDM Version number starting from Version 1.0.
On receipt of a VDM Header with a higher Version number than it supports, a Responder **Shall** respond using the highest Version number that the Responder supports. On receipt of a VDM Header with a lower Version number than it supports, a Responder **Shall** respond using the same Version number it received.
The Structured VDM Version (Major)/Structured VDM Version (Minor) fields of the Discover Identity Commands sent and received during the Section 8.7.1 **Shall** be used to determine the highest common Structured VDM Versions supported by the Port Partners or by the Port Partner and the Cable Plugs, respectively. After discovering the common Structured VDM Version for the Port Partner or Cable Plugs, each Port Partner **Shall** continue to use this Structured VDM Version when Initiating Structured VDMs until Detach, Hard Reset, or Error Recovery occurs.
### 8.5.2. Object Position
The Object Position field **Shall** be used by the Enter Mode and Exit Mode Commands. The Discover Modes Command returns a list of 0-6 VDOs, each of which describe an Alternate Mode. The value in Object Position field is an index into that list that indicates which VDO (e.g., Alternate Mode) in the list the Enter Mode and Exit Mode Command refers to. The Object Position **Shall** start with one for the first Alternate Mode entries in the list.
### 8.5.3. SVID
The content of the Mode VDOs for an Alternate Mode **Shall** be defined by the standard or vendor associated with the SVID. The Mode VDOs' content **May** be as simple as a numeric value or as complex as a bit-mapped description of Capabilities of the Alternate Mode. In all cases, the Discover Modes Responder is responsible for interpreting the VDOs to know whether or not it supports the Alternate Mode at the Object Position.
## 8.6. Command Usage
Ports use sequences of Structured VDM commands to discover, manage, and raise events associated with Alternate Modes.
In general, a Structured VDM AMS consists of a Command Request and a Command response (ACK, NAK or BUSY). A Structured VDM AMS is deemed to be completed (and if applicable, the transition to the requested functionality is made) when the Responder's Command response has been successfully transmitted.
<!-- page 243 -->
The Attention AMS is an exception to this Request/response flow. See Section 8.6.6.
Table 8.1 details the responses a Responder **May** issue to each Command Request. Responses not listed for a given Command **Shall Not** be sent by a Responder. An Initiator that receives a NAK response **Should** take that response as an indication not to retry that particular Command REQ.
**Table 8.1. Commands and Responses**
| Command | Allowed Response | Reference |
| --- | --- | --- |
| Discover Identity | ACK, NAK, BUSY | Section 8.6.1 |
| Discover SVIDs | ACK, NAK, BUSY | Section 8.6.2 |
| Discover Modes | ACK, NAK, BUSY | Section 8.6.3 |
| Enter Mode | ACK, NAK | Section 8.6.4 |
| Exit Mode | ACK, NAK | Section 8.6.5 |
| Attention | None | Section 8.6.6 |
All Ports that support Modal Operation **Shall** support the Discover Identity, Discover SVIDs, the Discover Modes, the Enter Mode and Exit Mode Commands.
The Responder **Shall** respond with:
- ACK if it recognizes the SVID and is able to process it at the expected time.
- NAK if any of the following are true:
- It does not recognize the SVID.
- It does not support the Command with respect to the SVID.
- It recognizes the SVID but cannot process the Command Request.
- A VDO in the Command Request contains a field which is **Invalid**.
- Structured VDMs are supported, but the Structured VDM Command Request is an Unrecognized Message.
- BUSY if it recognizes the SVID and the Command but cannot process the Command Request at the present time.
The Initiator **Shall** wait `tVDMBusy` after a "Responder BUSY" response is received before retrying the Command Request.
The ACK, NAK or BUSY response **Shall** contain the same SVID as the Command Request.
The Responder **Shall** respond to:
- Enter Mode requests within `tVDMEnterMode`.
- Exit Mode requests within `tVDMExitMode`.
- Other requests within `tVDMReceiverResponse`.
An Initiator not receiving a response within the expected allotted time **Shall** generate a timeout and return to either the PE_SRC_Ready or PE_SNK_Ready State (as appropriate):
- Enter Mode requests within `tVDMWaitModeEntry`.
- Exit Mode requests within `tVDMWaitModeExit`.
<!-- page 244 -->
- Other requests within `tVDMSenderResponse`.
### 8.6.1. Discover Identity
#### 8.6.1.1. SOP Use
The Discover Identity Command, sent to the Port Partner, enables a Port to identify its Port Partner and determine its suitability for [USB4] or Alternate Mode entry, among other Capabilities.
The following products **Shall** respond with a Discover Identity Command ACK in response to a Discover Identity Command Request sent to SOP:
- A PD-Capable UFP that supports Modal Operation.
- A PD-Capable product that has multiple DFPs.
- A PD-Capable [USB4] product.
#### 8.6.1.2. SOP' Usage
The Discover Identity Command that is sent to SOP', enables a Port to identify a cable and determine its suitability for [USB4] or Alternate Mode entry, similarly to SOP use with respect to the Port Partner.
Additionally, the Discover Identity Command sent to SOP', enables a Port to, among other things:
- Determine whether a cable or VPD is PD-Capable.
- Establish a Specification Revision level with the cable.
- Determine the cable's maximum supported VBUS voltage and current.
- Determine whether the cable supports EPR.
A PD-Capable Cable Plug or VPD **Shall** support the Discover Identity Command.
##### 8.6.1.2.1. PD Capability
A Port that communicates with Cable Plug(s) **Shall** use the following process to determine whether a given Cable Plug or VPD is PD Capable before communicating with the Cable Plug(s)
- The Initial Source/VCONN Source **Shall** initiate a Discover Identity REQ Message to SOP' during Default Contract. The Cable Plug and Sink/UFP will power up independently after the Port sources VBUS and VCONN, and either target might be ready for PD Communication first. The Source/VCONN Source **May** initiate additional SOP' Discover Identity REQ messages until it receives a valid GoodCRC Message, subject to the limits described below.
Note: A Cable Plug or VPD will not be ready for PD Communication until `tVCONNStable` after VCONN has been applied (see [USB-C]).
- Prior to the initial power Contract, the initial VCONN Source **May** continue to send SOP' Discover Identity REQ until the Initial Source receives a GoodCRC, up to a maximum of `nDiscoverIdentityCount` times. While doing this, the Port must continue to send Source Capabilities at the times required by `SourceCapabilityTimer`.
- If a Port that communicates with the Cable Plug(s) enters an Explicit Contract before receiving a GoodCRC Message for SOP' Discover Identity, it **Shall** continue to send SOP' Discover Identity REQ up to a maximum
<!-- page 245 -->
of `nDiscoverIdentityCount` times at a rate defined by the `DiscoverIdentityTimer`, while the Port is VCONN Source.
- If the Cable Plug or VPD does not respond with a GoodCRC Message before `nDiscoverIdentityCount` expires, the Port **Shall** consider the Cable Plug or VPD not to be PD Capable, and the Port **Shall Not** send any further messages to SOP or SOP' until a Detach, Hard Reset, or Error Recovery happens.
- If a Cable Plug does not respond to a Revision 3.x Discover Identity REQ with a Discover Identity ACK or BUSY, the VCONN Source **May** repeat the Discover Identity REQ using PD Revision 2.0 before establishing that the Cable Plug is not PD Capable, until `nDiscoverIdentityCount` expires.
- If a Port does not receive a GoodCRC Message for an SOP' Discover Identity REQ, it **Shall** not send an SOP' Soft Reset, because the Cable or VPD **May** Not be PD Capable.
- If the Cable Plug or VPD responds to a Discover Identity REQ with a GoodCRC Message and a Discover Identity ACK or BUSY, the initiating Port **Shall** consider the Responder to be PD Capable.
See Figure 9.76 and Figure 9.93.
Note: If a Port becomes VCONN Source via a VCONN Swap, it **Shall** issue an SOP' and/or SOP'' Soft Reset Message before otherwise communicating with the Cable Plug(s). If a Cable Plug responds to this Soft Reset with a GoodCRC Message, the Port **May** consider the Responder to be PD Capable. See Section 7.1.1.
During Implicit Contract, the VCONN Source **May** Initiate SOP' Discover Identity, subject to the rules in this section.
This process is closely linked to the process for establishing a common Specification Revision with a Cable Plug. The Port **Shall** reset its PD Capability determination whenever it resets its Specification Revision determination. (See Section 6.1.3.)
##### 8.6.1.2.2. Maximum Voltage and Current Capability
Standard USB Type-C cable assemblies are rated for PD voltages higher than `vSafe5V` and current levels of at least 3A (See [USB-C]). The Source **Shall** limit maximum Capabilities it offers so as not to exceed the Capabilities of the type of cabling detected, using the process described here.
The Cable VDO, returned as part of the Discover Identity ACK, specifies the maximum current and voltage values that the Responder supports. A Source capable of offering more than 3A **Shall** discover the Attached cable via the SOP' Discover Identity Command and limit its Source Capabilities based on the maximum current supported by the cable. (Section 8.6.1).
##### 8.6.1.2.3. Cable EPR Capability
The Cable VDO specifies whether or not the cable is EPR-capable. An EPR Source **Shall** discover the Attached cable via the SOP' Discover Identity Command and limit its Source Capabilities based on the cable's EPR support. (See Section 7.30.1.
Any additional VDOs received by the Initiator **Shall** be **Ignored**.
### 8.6.2. Discover SVIDs
A Responder that does not support any SVIDs **Shall** return a NAK.
If the Responder supports 12 or more SVIDs, then the Initiator **Shall** repeat the Discover SVIDs REQ until the Responder responds with a Discover SVIDs ACK ending either with a SVID value of `0x0000` in the last part of the last VDO or with a VDO containing two SVIDs with values of `0x0000`. Each Discover SVID ACK Message, other than the one containing the terminating `0x0000` SVID, **Shall** convey 12 SVIDs. The Responder **Shall** restart the list of SVIDs each time a Discover Identity Command Request is received from the Initiator.
<!-- page 246 -->
#### 8.6.2.1. SOP' Usage
Note: Since a Cable Plug does not retry Messages if the GoodCRC Message from the Initiator becomes corrupted the Cable Plug will consider the Discover SVIDs Command ACK unsent and will send the same list of SVIDs again.
### 8.6.3. Discover Modes
A Responder that does not support any Modes **Shall** return a NAK.
### 8.6.4. Enter Mode Command
A Device **May** support multiple Modes with one or more active at any point in time. Any interactions between them are the responsibility of the relevant Standards or Vendors. Where there are multiple Active Modes at the same time Modal Operation **Shall** start on entry to the first Alternate Mode.
On receiving an Enter Mode Command Request, the Responder **Shall** respond with either an ACK or a NAK response. The Responder is not allowed to return a BUSY response. The value in the Object Position field of the Enter Mode Command response **Shall** contain the same value as the received Enter Mode Command Request.
Before entering an Alternate Mode, by sending the Enter Mode Command Request that requires the reconfiguring of any pins on entry to that Alternate Mode, the Initiator **Shall** ensure that those pins being reconfigured are placed into the USB Safe State. Before entering an Alternate Mode that requires the reconfiguring of any pins, the Responder **Shall** ensure that those pins being reconfigured are placed into either USB operation or the USB Safe State.
If the Responder responds to the Enter Mode Command Request with an ACK, the Responder **Shall** enter the Alternate Mode before sending the ACK. The Initiator **Shall** enter the Alternate Mode on reception of the ACK. Successful transmission of the Message confirms to the Responder that the Initiator will enter an Active Mode.
If the Responder responds to the Enter Mode Command Request with a NAK, the Alternate Mode is not entered. If not presently in Modal Operation, the Initiator **Shall** return to USB operation. If not presently in Modal Operation, the Responder **Shall** remain in either USB operation or the USB Safe State.
If the Initiator fails to receive a response within `tVDMWaitModeEntry` it **Shall Not** enter the Alternate Mode but return to USB operation.
Figure 8.1 shows the sequence of events during the transition between USB operation and entering an Alternate Mode. It illustrates when the Responder's Alternate Mode changes and when the Initiator's Alternate Mode changes. Figure 8.2 illustrates that when the Responder returns a NAK the transition to an Alternate Mode does not take place and the Responder and Initiator remain in their default USB roles.
<!-- page 247 -->
**Figure 8.1. Successful Enter Mode sequence**
![Figure 8.1. Successful Enter Mode sequence](08-vendor-defined-message-usage-and-alternate-modes/figure-8.1.png)
<!-- page 248 -->
**Figure 8.2. Unsuccessful Enter Mode sequence due to NAK**
![Figure 8.2. Unsuccessful Enter Mode sequence due to NAK](08-vendor-defined-message-usage-and-alternate-modes/figure-8.2.png)
### 8.6.5. Exit Mode Command
Only the DFP **Shall** initiate the Exit Mode Process.
The Responder **Shall** exit its Active Mode before sending the response Message. The Initiator **Shall** exit its Active Mode when it receives the ACK. The Responder **Shall Not** return a BUSY acknowledgment and **Shall** only return a NAK acknowledgment to a Request not containing an Active Mode (i.e., **Invalid** object position). An Initiator which fails to receive an ACK within `tVDMWaitModeExit` or receives a NAK or BUSY response **Shall** exit its Active Mode.
Figure 8.3, "Exit Mode sequence" shows the sequence of events during the transition between exiting an Active Mode and USB operation. It illustrates when the Responder's Alternate Mode changes and when the Initiator's Alternate Mode changes.
<!-- page 249 -->
**Figure 8.3. Exit Mode sequence**
![Figure 8.3. Exit Mode sequence](08-vendor-defined-message-usage-and-alternate-modes/figure-8.3.png)
### 8.6.6. Attention
An Initiator **May** use the `Attention` Command to notify the Responder that it requires service.
A Structured VDM `Attention` AMS consists of a Command Request but no Command response. A Structured VDM `Attention` AMS is deemed to be completed when the `GoodCRC` Message has been successfully received by the Initiator in reply to its `Attention` Command Request.
<!-- page 250 -->
**Figure 8.4. Attention Command Request/response sequence**
![Figure 8.4. Attention Command Request/response sequence](08-vendor-defined-message-usage-and-alternate-modes/figure-8.4.png)
If Structured VDMs are supported, then no response **Shall** be made to an `Attention` Command.
If Structured VDMs are supported, but the Structured VDM `Attention` Command Request is an Unrecognized Message it **Shall** be **Ignored** (see Table 8.1).
## 8.7. Command Processes
### 8.7.1. Discovery Process
The Discovery Process has several phases. A Port **Shall** complete the Discovery Process to the extent that it requires the information contained in each Message for its normal operation. However, in each phase, if the Responder does not respond with `GoodCRC` Message or responds with an SVDM of Command Type NAK, or with a `Not_Supported` Message, the Initiator **Shall Not** proceed to a phase of discovery contingent on the expected SVDM ACK.
#### 8.7.1.1. Port Partner Discovery
1. The Initiator issues a `Discover Identity` REQ to determine the Responder's basic properties and Alternate Mode support. The Responder responds with `Discover Identity` ACK.
2. If the `Discover Identity` ACK sets Modal Operation Supported = 1 in the ID Header VDO, the Responder supports at least one Alternate Mode. The Initiator issues `Discover SVIDs` REQ to determine the list of SVIDs the Responder supports. If the Responder supports six or more SVIDs, the Initiator might issue multiple `Discover SVIDs` REQs.
3. The Initiator sends a `Discover Modes` REQ for any SVID supported by the Responder, and the Responder responds with a `Discover Modes` ACK containing Mode-specific information. The Initiator **May** initiate a `Discover Modes` REQ for any or all of the Responder's supported SVIDs.
<!-- page 251 -->
#### 8.7.1.2. Cable Plug Discovery
The Discovery Process with the Cable Plug as Responder is substantially similar to that with the Port Partner as Responder, with the following differences:
- The Initiator must be the VCONN Source to communicate with the Cable Plugs. (See Section 7.13.)
- The Initiator **Shall Not** send discovery SVDM REQs to the Cable Plug at SOP''. The Initiator **Shall** consider any responses to discovery SVDM REQs from the Cable Plug at SOP' to apply to the Cable Plug at SOP''.
- The Initial Source/VCONN Source, if it communicates with the Cable Plug, **Shall** Initiate `Discover Identity` REQ to SOP' prior to the Initial Contract. (See Section 8.6.1.2.1).
### 8.7.2. Entering Alternate Modes
The result of the Discovery Process is that both the Initiator and Responder identify the Modes they mutually support. The Initiator (DFP), upon finding a suitable Alternate Mode, uses the `Enter Mode` Command to enable the Alternate Mode. Once the Alternate Mode is entered, the Device **Shall** remain in that Active Mode until the `Exit Mode` Command is successful (see Section 8.6.5 ).
A DFP **May** Initiate the `Enter Mode` Process with a Responder after it has successfully completed the Discovery Process with that Responder, subject to the specification of the Alternate Mode.
The Alternate Mode entry process with a Cable Plug as Responder is substantially similar to that with the Port Partner as Responder, with the following differences:
- The Initiator must be the VCONN Source to communicate with the Cable Plugs. (See Section 7.13.)
- The specification for each Alternate Mode determines whether the DFP must complete the Enter Mode process on SOP' and SOP'' and the timing of those processes relative to the Enter Mode process on SOP.
### 8.7.3. Exiting Alternate Modes
The Responder (UFP or Cable Plug) and Initiator continue using the Active Mode until the Active Mode is exited. Upon exiting an Alternate Mode, a Port or Cable Plug **Shall** exit any State entered via that Alternate Mode, including via Unstructured VDMs.
In a managed termination, using the `Exit Mode` Command, the Active Mode **Shall** be exited in a controlled manner as described in Section 8.6.5 .
An unmanaged termination is triggered by one of the following conditions:
- Data Reset
- Hard Reset
- Error Recovery
- Detach
Upon an unmanaged termination, the Ports **Shall** exit all Active Modes but **Shall Not** transition through USB Safe State; the Cable Plugs **Shall** exit all Active Modes. The Cable Plugs **Shall** Exit any Active Modes upon a Cable Reset.
Upon either type of termination, each Port **Shall** return to USB operation as defined in [USB-C] following an exit from an Alternate Mode.
The overall Message flow is illustrated in Figure 8.5, "Enter/Exit Mode Process".
<!-- page 252 -->
**Figure 8.5. Enter/Exit Mode Process**
![Figure 8.5. Enter/Exit Mode Process](08-vendor-defined-message-usage-and-alternate-modes/figure-8.5.png)
<!-- page 253 -->
The Initiator **Shall** return to USB Operation within `tVDMExitMode` of a disconnect, of Hard Reset Signaling being detected or Error Recovery.
The Responder **Shall** return to either USB operation or USB Safe State within `tVDMExitMode` of a disconnect, of Hard Reset Signaling being detected or Error Recovery.

BIN
USB_PD_R3.2/08-vendor-defined-message-usage-and-alternate-modes/figure-8.1.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 84 KiB

BIN
USB_PD_R3.2/08-vendor-defined-message-usage-and-alternate-modes/figure-8.2.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 78 KiB

BIN
USB_PD_R3.2/08-vendor-defined-message-usage-and-alternate-modes/figure-8.3.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 79 KiB

BIN
USB_PD_R3.2/08-vendor-defined-message-usage-and-alternate-modes/figure-8.4.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 55 KiB

BIN
USB_PD_R3.2/08-vendor-defined-message-usage-and-alternate-modes/figure-8.5.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 203 KiB

4467
USB_PD_R3.2/09-state-machine-diagrams.md Normal file
View file

File diff suppressed because it is too large Load diff

BIN
USB_PD_R3.2/09-state-machine-diagrams/figure-9.1.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 56 KiB

BIN
USB_PD_R3.2/09-state-machine-diagrams/figure-9.10.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 331 KiB

BIN
USB_PD_R3.2/09-state-machine-diagrams/figure-9.100.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 154 KiB

BIN
USB_PD_R3.2/09-state-machine-diagrams/figure-9.101.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 147 KiB

BIN
USB_PD_R3.2/09-state-machine-diagrams/figure-9.102.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 278 KiB

BIN
USB_PD_R3.2/09-state-machine-diagrams/figure-9.11.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 337 KiB

BIN
USB_PD_R3.2/09-state-machine-diagrams/figure-9.12.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 56 KiB

BIN
USB_PD_R3.2/09-state-machine-diagrams/figure-9.13.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 31 KiB

BIN
USB_PD_R3.2/09-state-machine-diagrams/figure-9.14.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 42 KiB

BIN
USB_PD_R3.2/09-state-machine-diagrams/figure-9.15.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 53 KiB

BIN
USB_PD_R3.2/09-state-machine-diagrams/figure-9.16.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 192 KiB

BIN
USB_PD_R3.2/09-state-machine-diagrams/figure-9.17.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 748 KiB

BIN
USB_PD_R3.2/09-state-machine-diagrams/figure-9.18.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 641 KiB

BIN
USB_PD_R3.2/09-state-machine-diagrams/figure-9.19.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 293 KiB

BIN
USB_PD_R3.2/09-state-machine-diagrams/figure-9.2.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 31 KiB

BIN
USB_PD_R3.2/09-state-machine-diagrams/figure-9.20.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 289 KiB

BIN
USB_PD_R3.2/09-state-machine-diagrams/figure-9.21.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 264 KiB

BIN
USB_PD_R3.2/09-state-machine-diagrams/figure-9.22.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 251 KiB

BIN
USB_PD_R3.2/09-state-machine-diagrams/figure-9.23.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 193 KiB

Some files were not shown because too many files have changed in this diff Show more