markdowned-datasheets/USB_PD_R3.2/05-pd-communications-physical-layer.md

<!-- 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.