---
title: "What does the PHY do, and what does the link layer do?"
topic: "PHY and link layer"
answer: "The PHY decides how bits look on the wire. It sets the voltages, the line code and where the clock comes from. The link layer decides what the bits mean. It marks where a frame starts, who it’s for and whether it arrived intact. Either one can change while the other stays."
url: "https://nearfieldnotes.com/notes/phy-link/"
site: "Near Field Notes"
author: "Michael Walker"
note: 14
family: "Signal integrity"
published: "2026-11-04"
revised: "2026-11-04"
revision: 1
video: "https://nearfieldnotes.com/videos/phy-link/"
---

Note 14 · [Signal integrity](https://nearfieldnotes.com/families/si/) · Rev 1 · [Watch the video · 1:58](https://nearfieldnotes.com/videos/phy-link/)

PHY and link layer

# What does the PHY do, and what does the link layer do?

**Short answer:** The PHY decides how bits look on the wire. It sets the voltages, the line code and where the clock comes from. The link layer decides what the bits mean. It marks where a frame starts, who it’s for and whether it arrived intact. Either one can change while the other stays.

HDMI 2.1 shows the split. In its FRL mode, the old clock pair becomes a fourth data lane, and the clock rides inside the data, much as DisplayPort has done since its 2006 spec.

The figure sweeps the four pairs on a Rockchip RK3588 board through the old TMDS mode, then FRL.

**Note 14’s opening figure: HDMI 2.1, before and after FRL.** A Rockchip RK3588 driving an Amphenol HDMI receptacle

![Note 14’s opening figure: HDMI 2.1, before and after FRL](https://nearfieldnotes.com/notes/phy-link/fig-opening.png)

*What the figure shows:* A Rockchip RK3588 on a piece of board, with four differential pairs running to an HDMI receptacle. Below, the four pairs' signals bit by bit. In the old TMDS mode, three pairs carry data and the fourth carries a clock that completes one cycle every 10 bits. In HDMI 2.1's FRL mode, after link training, all four carry data: the clock pair has become lane 3, and the clock rides inside the data.

Drawn one bit per step. The TMDS lanes carry real TMDS code, and its clock completes one cycle for every 10-bit character. FRL’s 16b/18b code isn’t public, so its lanes show scrambled bits. FRL runs each lane at a fixed 3 to 12 Gb/s.

## Two layers

*Layer 1 and layer 2*

Every wired link splits its job in two. The physical layer, or PHY, moves raw bits. It sets the voltages, the [line code](https://nearfieldnotes.com/glossary/#g-line-code) that turns bits into levels, and how the far end finds the clock. The data link layer above it gathers the bits into frames, addresses them and checks them for errors.

The start of an Ethernet frame shows both. On 10BASE-T, every bit is an edge in the middle of its slot, rising for a 1 and falling for a 0, so the edges carry the clock as well. The link layer then reads 10101011 as the start of a frame.

**Fig. 14: The two layers.**

![Fig. 14: The two layers](https://nearfieldnotes.com/notes/phy-link/fig-14.png)

*What the figure shows:* Figure 14: the two layers on one Ethernet frame. Top, the PHY: 10BASE-T's Manchester code for the end of the preamble, the start frame delimiter 10101011 and the first bits of an address. Each 1 is a rising edge in the middle of its bit and each 0 a falling one, so the edges also give the clock. Below, the link layer: the frame's fields, Start 8 bytes, To 6, From 6, Type 2, Data 46 to 1500 and Check 4.

10BASE-T’s Manchester code for the last bits of the preamble, the start frame delimiter and the first bits of an address. Start is the 7-byte preamble and the delimiter.

## Ethernet, in two chips

*MAC, then PHY*

Ethernet often gives each layer a chip of its own. The MAC, the link layer, sits inside the processor and builds each frame. It hands the frame over RGMII to a separate PHY chip, which drives four twisted pairs through the jack’s transformers.

RGMII comes with a classic bring-up bug. Its clock has to arrive 1.5 to 2 ns after its data, and someone has to add that delay. The PHY can add it, or the MAC, or a longer trace.

**Fig. 14b: MAC and PHY.**

![Fig. 14b: MAC and PHY](https://nearfieldnotes.com/notes/phy-link/fig-14b.png)

*What the figure shows:* Figure 14b: a Rockchip RK3588 processor, a Realtek RTL8211F gigabit PHY chip and a HanRun HR911130A RJ45 jack on a piece of board. Twelve RGMII lines run from the processor's MAC to the PHY, and four differential pairs run from the PHY to the jack.

Rendered at the parts’ datasheet sizes, with the traces routed for the picture. RGMII is purple and the four pairs are blue.

## One frame, four PHYs

*1980 to now*

The frame the MAC builds has kept its fields since September 1980. They are the destination, source, type, data and a 32-bit check. The IEEE project for 800 Gb/s Ethernet committed to keeping them.

The PHY under it has been replaced again and again. 10BASE-T sends Manchester code. 100BASE-TX steps between three levels. Gigabit sends five levels on all four pairs, both ways at once, and 10GBASE-T sends sixteen at 800 Mbaud, with error correction on top.

**Fig. 14c: Four Ethernet PHYs.**

![Fig. 14c: Four Ethernet PHYs](https://nearfieldnotes.com/notes/phy-link/fig-14c.png)

*What the figure shows:* Figure 14c: the same Ethernet frame on four PHYs, 24 symbols of each. 10BASE-T, 10 Mb/s: Manchester code on 2 pairs, 1.2 µs shown. 100BASE-TX, 100 Mb/s: MLT-3, three levels at 125 Mbaud on 2 pairs, 192 ns. 1000BASE-T, 1 Gb/s: PAM-5, five levels at 125 Mbaud on each of 4 pairs, 192 ns. 10GBASE-T, 10 Gb/s: PAM-16, sixteen levels at 800 Mbaud on each of 4 pairs, 30 ns.

24 symbols of each, so each row runs to its own time scale. 10BASE-T and 100BASE-TX come from the real encoders. The PAM rows stand for scrambled data.

## Ethernet

*IEEE 802.3*

Gigabit needs all four pairs, A to D, but autonegotiation and 100 Mb/s use only A and B. So a cable with a break in pair C or D still agrees on 1 Gb/s, then fails to link.

**Fig. 14d: Downshift.**

![Fig. 14d: Downshift](https://nearfieldnotes.com/notes/phy-link/fig-14d.png)

*What the figure shows:* Figure 14d: downshift. Four pairs, A to D, run from a gigabit PHY to its jack, and pair C is broken. Autonegotiation uses only pairs A and B, so it still agrees on 1 Gb/s. 1 Gb/s needs all four pairs and fails. A PHY that downshifts then falls back to 100 Mb/s, which uses pairs A and B, and links.

TI’s DP83867 falls back after 4 failed tries by default. Linux then logs that a downshift occurred and asks you to check the cabling.

Ethernet

### One frame since 1980, under every speed

**Field marks.** A small square PHY chip near an RJ45 jack, with RGMII on one side and four pairs on the other. The RTL8211F is a 5 mm QFN with 40 pads.

**Look-alike.** 10BASE-T, hiding in every faster port. Autonegotiation speaks in bursts of its old link pulses, which a 10BASE-T port reads as its own.

**Range.** 10 Mb/s to 10 Gb/s on twisted pairs, and 800 Gb/s on the same frame. Frames run from 64 to 1518 bytes, or 1522 with a VLAN tag. The CRC-32 came from AUTODIN II, a US military network.

**Habitat.** Any board with an RJ45 jack. Some gigabit PHYs, such as TI’s DP83867 and Marvell’s 88E1512, can downshift. Not every one can.

## One PHY, a choice of link layers

*Combo PHYs*

Some chips turn it around, with one PHY and a choice of link layers on top. Each of the Rockchip RK3568’s three SerDes lanes can be one of two or three interfaces, and the board picks which.

It’s one job per lane. A board that uses lane 2 for PCIe gives up SATA and SGMII on it.

**Fig. 14e: The RK3568’s lanes.**

![Fig. 14e: The RK3568’s lanes](https://nearfieldnotes.com/notes/phy-link/fig-14e.png)

*What the figure shows:* Figure 14e: the Rockchip RK3568's three combo PHY lanes. Lane 0 can be USB 3.0 or SATA. Lane 1 can be USB 3.0, SATA or SGMII networking. Lane 2 can be PCIe 2.1, SATA or SGMII. Each lane does one job, shown filled.

From Rockchip’s RK3568 datasheet, as quoted in the review of its Linux driver. Filled: one way a board might set the three lanes.

It works because those PHYs are close cousins. USB 3.0 shares PCIe 2.0’s signaling. Both run at 5 Gb/s, with the same 8b/10b code carrying the clock. Intel’s PIPE spec, begun for PCIe in 2002, now gives one PHY interface for PCIe, SATA, USB, DisplayPort and USB4.

8b/10b turns each byte into one of a set of 10-bit codes, chosen to keep the line balanced and full of edges for the clock. The byte 4Ah becomes 0101010101.

**Fig. 14f: 8b/10b.**

![Fig. 14f: 8b/10b](https://nearfieldnotes.com/notes/phy-link/fig-14f.png)

*What the figure shows:* Figure 14f: 8b/10b, the code USB 3.0 and PCIe 2.0 share. The byte 4Ah, 01001010, becomes the 10-bit code 0101010101. Below, four bytes as 40 bits on the wire at 5 Gb/s, 8 ns in all.

Real 8b/10b from the PHY_link encoder, starting at negative running disparity. 4Ah is the code D10.2.

## MIPI CSI-2

*One link layer, two PHYs*

The reverse happens too, with one link layer on different PHYs. A phone camera’s CSI-2 link can run on a D-PHY, which sends its clock on a lane of its own, or on a C-PHY, which uses three wires per lane at three levels and builds the clock in.

**Fig. 14g: MIPI CSI-2.**

![Fig. 14g: MIPI CSI-2](https://nearfieldnotes.com/notes/phy-link/fig-14g.png)

*What the figure shows:* Figure 14g: a MIPI CSI-2 camera module after the Raspberry Pi Camera Module 3, with its flat ribbon. Beside it, the two PHYs CSI-2 can run on. D-PHY sends a clock on a lane of its own beside its data lanes. C-PHY uses three wires per lane, each at high, mid or low, and changes state every symbol, so the clock is in the data.

A C-PHY trio changes state every symbol, so every symbol brings a clock edge. It packs 16 bits into 7 symbols. The module follows the Raspberry Pi Camera Module 3.

MIPI CSI-2

### A camera link on two kinds of wire

**Field marks.** A flat ribbon from a camera module to the board, 15 ways wide on the Raspberry Pi Camera Module 3.

**Look-alike.** D-PHY since version 3.5, which can also build its clock into the data and free its clock lane.

**Range.** One AMD D-PHY core runs up to four data lanes at 80 to 3200 Mb/s, with a 10 Mb/s low-power mode. C-PHY carries about 2.28 bits per symbol, or 3.56 in its newer mode that packs 32 bits into 9 symbols.

**Habitat.** Between image sensors and processors in phones, and in cars over A-PHY, up to 15 m.

## Bluetooth LE

*Three PHYs, one link*

A radio link can even change PHY while it runs. Bluetooth LE has three. LE 1M is the original. LE 2M is twice as fast, and LE Coded spends 2 or 8 symbols on every bit to reach farther.

**Fig. 14h: Bluetooth LE’s PHYs.**

![Fig. 14h: Bluetooth LE’s PHYs](https://nearfieldnotes.com/notes/phy-link/fig-14h.png)

*What the figure shows:* Figure 14h: Bluetooth LE's PHYs. LE 2M sends 2 Mb/s, one byte in 4 µs, and must hear −70 dBm. LE 1M sends 1 Mb/s, 8 µs a byte, −70 dBm. LE Coded with S=2 sends 500 kb/s, 16 µs a byte, and must hear −75 dBm. LE Coded with S=8 sends 125 kb/s, 64 µs a byte, and must hear −82 dBm.

Rates and required receiver sensitivities from the Bluetooth Core 5.4 spec. Air time is a byte’s 8 bits at each rate.

Bluetooth LE

### Three PHYs, switched on a live link

**Field marks.** Three link-layer messages, LL_PHY_REQ, LL_PHY_RSP and LL_PHY_UPDATE_IND, that move a live connection to a new PHY.

**Look-alike.** LE 1M and LE Coded share one modulation at 1 Msym/s. Only the coding differs.

**Range.** 2 Mb/s on LE 2M down to 125 kb/s on LE Coded with S=8, which must hear signals 12 dB weaker than the uncoded PHYs need.

**Habitat.** Every LE radio. LE 1M is required and LE Coded is optional. LE 2M and LE Coded both arrived in Bluetooth 5.0.

## CAN

*The wire picks who talks*

On CAN, the PHY even settles who may talk. A transceiver drives the bus for a 0 and lets it rest for a 1, so when two nodes send at once, the bus shows the 0.

Each node reads the bus back as it sends its ID. One that sends a 1 and reads a 0 has lost, and goes quiet. The lowest ID wins, and its frame carries on untouched.

**Fig. 14i: CAN arbitration.**

![Fig. 14i: CAN arbitration](https://nearfieldnotes.com/notes/phy-link/fig-14i.png)

*What the figure shows:* Figure 14i: an NXP TJA1051 CAN transceiver on a piece of board, its CANH and CANL lines leaving as a pair. Below, three nodes start a frame at once, with IDs 0x65A, 0x659 and 0x6F0. The bus carries a 0 whenever any node sends one. 0x6F0 sends a 1 against a 0 at the fourth ID bit and drops out, then 0x65A at the tenth. 0x659, the lowest ID, wins. On the wires, a 0 drives CANH to 3.5 V and CANL to 1.5 V, and a 1 leaves both at 2.5 V.

Three nodes start at once. Voltages are the TJA1051’s typical outputs at 5 V. A 0 is called dominant and a 1 recessive.

CAN

### A bus where 0 always wins

**Field marks.** An 8-pin transceiver such as NXP’s TJA1051 on two lines, CANH and CANL. Both rest at 2.5 V for a 1 and spread to 3.5 and 1.5 V for a 0.

**Look-alike.** CAN FD, which fights for the bus the same way at up to 1 Mb/s, then speeds up for the data.

**Range.** Classic CAN runs at up to 1 Mb/s. The TJA1051 takes CAN FD’s data phase to 5 Mb/s, with up to 64 bytes a frame.

**Habitat.** Cars and machines. The transceiver is only the analog end of the PHY. The controller does the bit timing and the link layer, and resends a frame after an error by itself.

## HDMI

*DVI with sound*

HDMI began as DVI. HDMI 1.0, final in December 2002, kept DVI’s TMDS PHY. That’s three data pairs and a clock pair, each line pulled up to 3.3 V through 50 Ω at the screen. Its link layer added sound, in packets fitted into the gaps between lines and frames.

**Fig. 14j: HDMI’s gaps.**

![Fig. 14j: HDMI’s gaps](https://nearfieldnotes.com/notes/phy-link/fig-14j.png)

*What the figure shows:* Figure 14j: one video frame as HDMI sends it, not to scale. The picture fills most of it. Blanking gaps run before each line and before each frame. HDMI puts audio and info packets into those gaps, where DVI sends only sync codes. Below, one line on a TMDS channel: sync codes, a packet, more sync, then pixels.

Not to scale. The bars stand for any picture.

HDMI

### DVI’s wires, with sound and packets on top

**Field marks.** A 19-pin Type A receptacle with its lower corners cut. The Amphenol part in the opening figure is 15 mm wide.

**Look-alike.** DVI, which shares its TMDS. A wire-only adapter works, and the source just leaves the packets out.

**Range.** TMDS on three data pairs and a clock. FRL on 3 or 4 lanes at 3 to 12 Gb/s each, 48 Gb/s in all. HDMI 2.2, published in 2025, takes FRL to 96 Gb/s.

**Habitat.** TVs, monitors, consoles and laptops, and boards like the RK3588’s.

## DisplayPort

*On four kinds of wire*

DisplayPort started from a link with no clock wire. It has 1, 2 or 4 lanes that carry the clock in the data, AC-coupled at 400 mV by default, and a slow side channel, AUX, for setup. It has since run on PHYs that aren’t its own.

**Fig. 14k: DisplayPort’s routes.**

![Fig. 14k: DisplayPort’s routes](https://nearfieldnotes.com/notes/phy-link/fig-14k.png)

*What the figure shows:* Figure 14k: four ways DisplayPort reaches a screen. On a DisplayPort cable, 1, 2 or 4 lanes with the clock in the data. Through a DP++ port and an HDMI adapter: the adapter pulls pin 13 high, the source sends TMDS, and the adapter shifts it to HDMI's levels. Over USB-C in DisplayPort Alt Mode, real DisplayPort lanes on the cable's fast pairs. Over USB4, no DisplayPort on the cable at all: a DP-in adapter wraps it in USB4 packets and a DP-out adapter unwraps it at the far end.

USB4 drops DisplayPort’s stuffing symbols and error-correction parity at one end and rebuilds them at the other. USB-C’s Alt Mode can’t do DP++.

DisplayPort

### A link layer that rides other PHYs

**Field marks.** A 20-pin receptacle with one corner cut. The Molex 47272 is 16.1 mm wide.

**Look-alike.** Thunderbolt 3, whose PHY DisplayPort 2.0 borrowed. VESA later aligned DisplayPort 2.1 with USB4’s PHY.

**Range.** From 1.62 Gb/s a lane with 8b/10b up to 20 Gb/s with DP 2.0’s 128b/132b. A basic DP++ adapter tops out at 165 MHz, single-link DVI’s limit.

**Habitat.** PC monitors, laptop panels as eDP, and USB-C and USB4 docks.

## Back to HDMI 2.1

*Lanes alike, wires apart*

FRL brought HDMI close to DisplayPort in structure. It has up to four lanes with the clock in the data, a few fixed rates, link training and Reed-Solomon error correction.

Its wires stayed HDMI’s. The sink still pulls each line up to 3.3 V, where DisplayPort couples through capacitors. They are close enough for one PHY to do both. The RK3588’s Samsung-designed PHY drives either HDMI 2.1 at up to 12 Gb/s a lane or a laptop panel’s eDP, picked by its driver each time it powers on.

**Fig. 14l: The wires.**

![Fig. 14l: The wires](https://nearfieldnotes.com/notes/phy-link/fig-14l.png)

*What the figure shows:* Figure 14l: one pair of each, as schematics. HDMI's sink pulls each line up to 3.3 V through 50 Ω, in TMDS and in FRL, and the source drives current down through it. DisplayPort puts a capacitor in series on each line, and its source swings 400 mV by default.

Simplified. HDMI’s terminations from the DVI 1.0 spec and TI’s TMDS1204 datasheet, DisplayPort’s swing from VESA. An FRL source may also be AC-coupled if it adds resistors to set HDMI’s levels.

## Side by side

*Every link on this page*

**Figure: PHYs and link layers.**

| Link | PHY | Code | Rate | Clock |
|---|---|---|---|---|
| Ethernet | 10BASE-T | Manchester | 10 Mb/s on 2 pairs | In the data |
| Ethernet | 100BASE-TX | 4B5B, then MLT-3 | 125 Mbaud on 2 pairs | In the data |
| Ethernet | 1000BASE-T | PAM-5 | 250 Mb/s on each of 4 pairs | In the data |
| Ethernet | 10GBASE-T | PAM-16 with LDPC | 800 Mbaud on each of 4 pairs | In the data |
| USB 3.0 | SuperSpeed | 8b/10b | 5 Gb/s | In the data |
| PCIe 2.0 | Gen 2 | 8b/10b | 5 Gb/s | In the data |
| MIPI CSI-2 | D-PHY | Bits on each lane | Up to 3.2 Gb/s a lane in one core | Its own lane |
| MIPI CSI-2 | C-PHY | 16 bits in 7 symbols | About 2.28 bits a symbol | In the data |
| Bluetooth LE | LE 1M, LE 2M, LE Coded | None, or 2 or 8 symbols a bit | 125 kb/s to 2 Mb/s | In the data |
| CAN | ISO 11898-2 | A stuff bit after 5 equal bits | 1 Mb/s, CAN FD data to 5 Mb/s | On the edges |
| HDMI, DVI | TMDS | 8 bits to 10 | Up to 1.65 Gb/s a pair on one DVI link | Its own pair |
| HDMI 2.1 | FRL | 16b/18b | 3 to 12 Gb/s on 3 or 4 lanes | In the data |
| DisplayPort | Main link | 8b/10b | 1.62, 2.7, 5.4 or 8.1 Gb/s a lane | In the data |
| DisplayPort 2.x | UHBR | 128b/132b | 10, 13.5 or 20 Gb/s a lane | In the data |
| DisplayPort | USB4’s, tunneled | USB4 packets | Shares the USB4 link | USB4’s |

Rates are per lane or pair where a link has several. Every entry is sourced below.

Read the two layers apart and the odd cases add up. Ethernet keeps one frame on ever faster PHYs. One PHY serves several link layers. DisplayPort’s link layer rides whichever PHY reaches the screen.

#### Conditions

- **Method:** No simulation. Each waveform is the bits or symbols that PHY sends, from the PHY_link project’s encoders.
- **Exact codes:** 10BASE-T’s Manchester, 100BASE-TX’s 4B5B, scrambler and MLT-3, DVI’s TMDS, 8b/10b, CAN arbitration and C-PHY’s wire states
- **Levels only:** 1000BASE-T’s PAM-5, 10GBASE-T’s PAM-16 and HDMI’s FRL, as scrambled data
- **Renders:** Blender, with parts at their datasheet sizes: Rockchip RK3588, Amphenol 10029449-111RLF, Realtek RTL8211F, HanRun HR911130A, NXP TJA1051T/3 and a module after the Raspberry Pi Camera Module 3. Traces are routed for the picture.
- **Claims:** Each one checked against its source in the project’s research notes, with datasheet values from NXP, Microchip and the DVI 1.0 spec

Drawn from specs and datasheets. Nothing on this page was measured.

#### Limits

- The waveforms are ideal symbols with smooth edges, not what arrives after a cable.
- HDMI’s spec isn’t public. Its packets in the gaps are described from a Sony patent, and FRL from test-equipment and IP vendors.
- Downshift is a vendor feature. Realtek’s datasheet doesn’t mention it, though Linux supports it on the RTL8211F.
- The RK3588’s combo PHY drives HDMI or eDP. Its external DisplayPort comes from a different PHY.
- The D-PHY rates are one vendor’s core, not the spec’s limits.

#### Files

- sim/linecodes.py The encoders behind every waveform
- render/scene.py The renders
- refs/research.md 57 checked claims and their sources
- anim/hook.py The video these figures come from

#### Sources

- [ITU-T X.200, the OSI reference model](https://www.itu.int/rec/T-REC-X.200-199407-I)
- [IEEE 802.3 overview, D. Law](https://www.ieee802.org/misc-docs/GlobeCom2009/IEEE_802d3_Law.pdf)
- [Linux, PHY abstraction layer and RGMII delays](https://docs.kernel.org/networking/phy.html)
- [DEC, Intel and Xerox, the Ethernet Blue Book, 1980](http://www.bitsavers.org/pdf/xerox/ethernet/Ethernet_Rev1.0_Sep1980.pdf)
- [IEEE P802.3df objectives, 800 Gb/s](https://ieee802.org/3/df/proj_doc/objectives_P802d3df_220317.pdf)
- [Microchip AN1120, Ethernet theory of operation](https://ww1.microchip.com/downloads/en/AppNotes/01120a.pdf)
- [DiMinico and Kish, 1000BASE-T and 10GBASE-T cabling](https://www.ieee802.org/3/an/public/material/diminico_IWCS.PDF)
- [Ethernet Alliance, 10GBASE-T](http://www.ethernetalliance.org/wp-content/uploads/2011/10/static_page_files_127_10GBASE_T2.pdf)
- [TI, DP83867 datasheet](https://www.ti.com/lit/ds/symlink/dp83867ir.pdf)
- [RK3568 combo PHY lanes, from Rockchip’s datasheet](https://lkml.iu.edu/hypermail/linux/kernel/2112.1/04346.html)
- [Intel, PIPE specification 7.1](https://cdrdv2-public.intel.com/643108/643108_PIPE_Arch_Spec_Rev_7_1.pdf)
- [Teledyne LeCroy, SuperSpeed USB design](https://cdn.teledynelecroy.com/files/appnotes/superspeed_design_verification_usb3.0.pdf)
- [MIPI, CSI-2](https://www.mipi.org/specifications/csi-2), [C-PHY](https://www.mipi.org/specifications/c-phy) and [D-PHY](https://www.mipi.org/specifications/d-phy)
- [AMD, PG202 MIPI D-PHY core](https://docs.amd.com/r/en-US/pg202-mipi-dphy/Features)
- [Bluetooth Core 5.4, LE physical layer](https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-54/out/en/low-energy-controller/physical-layer-specification.html)
- [Bosch, CAN specification 2.0](https://www.nxp.com/docs/en/reference-manual/BCANPSV2.pdf)
- [NXP, TJA1051 datasheet](https://www.nxp.com/docs/en/data-sheet/TJA1051.pdf)
- [CAN in Automation, CAN FD](https://www.can-cia.org/can-knowledge/can-fd-the-basic-idea)
- [DDWG, DVI 1.0 specification](https://www.fpga4fun.com/files/dvi_spec-V1_0.pdf)
- [HDMI Founders, HDMI 1.0 release, 2002](https://hdmi.org/press/bodydetails/79)
- [Sony, US8854434B2, HDMI data islands](https://patents.google.com/patent/US8854434B2/en)
- [TI SLLA633, HDMI 2.1 FRL lanes](https://www.ti.com/lit/an/slla633/slla633.pdf)
- [HDMI Licensing Administrator, HDMI 2.2 specification overview, 2025](https://www.hdmi.org/download/savefile?fileKey=Marketing%2FHDMI-2-2-Specification-Overview-20250625.pdf)
- [TI, TMDS1204 datasheet](https://www.ti.com/lit/ds/symlink/tmds1204.pdf)
- [VESA, DisplayPort technical overview](https://www.vesa.org/wp-content/uploads/2011/01/ICCE-Presentation-on-VESA-DisplayPort.pdf)
- [VESA, DisplayPort 1.3 overview, HBR3, 2014](https://www.displayport.org/wp-content/uploads/2014/09/DP-1.3-Overview-for-VESA-v1.pdf)
- [VESA, DisplayPort 2.0 release](https://vesa.org/press/vesa-publishes-displayport-2-0-video-standard-enabling-support-for-beyond-8k-resolutions-higher-refresh-rates-for-4k-hdr-and-virtual-reality-applications/)
- [TI, SN75DP130 datasheet, DP++ detection](https://www.ti.com/lit/ds/symlink/sn75dp130.pdf)
- [VESA, DisplayPort Alt Mode](https://www.vesa.org/wp-content/uploads/2016/10/USB-DevDays-DisplayPort-Alternate-Mode-2016-final4.pdf)
- [USB4 specification 2.0](https://www.usb.org/document-library/usb4tm-specification)
- [Linux, RK3588 HDMI and eDP combo PHY driver](https://github.com/torvalds/linux/blob/master/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c)

What should the next note be? [Ask for one](https://nearfieldnotes.com/#ask-for-a-note)

---

Source: https://nearfieldnotes.com/notes/phy-link/

Cite as: Michael Walker, “PHY and link layer”, Near Field Notes, Note 14, Rev 1, 4 Nov 2026. https://nearfieldnotes.com/notes/phy-link/

Figures: free to reuse under CC BY 4.0 (https://nearfieldnotes.com/license/). Each one's image is linked under its name. Credit Michael Walker, Near Field Notes, and link the figure: this address plus #fig- and its number, like https://nearfieldnotes.com/notes/phy-link/#fig-14.
