HDMI 系列3：HDMI 2.1 FRL 深度解析——Link Training 流程与 16b18b 编码原理

HDMI 2.1 FRL 深度解析：Link Training 流程与 16b18b 编码原理

一、引言

系列第一篇讲了 HDMI 为什么从 TMDS 换到 FRL，第二篇拆了 TMDS 的 8b→9b→10b 编码。这一篇进入 FRL 本体：Link Training（链路训练）流程和 16b18b 编码原理。

FRL（Fixed Rate Link）是 HDMI 2.1 的物理层革命：砍掉独立时钟线、4 条 Lane 并行、时钟嵌入数据、需要训练协商。代价是 HDMI 第一次有了"黑屏几秒才出画面"的握手过程；回报是 48 Gbps 的带宽和 8K/4K120 的可能性。

本文按 HDMI 2.1 规范（2017 年 11 月）Section 6.4.2（训练）、6.5.7/6.5.8（加扰与编码）、10.4（SCDC）逐节展开。

二、FRL 物理层：时钟没了，换成 4 条 Lane

TMDS 时代：3 数据通道 + 1 时钟通道。FRL 时代：TMDS 的 3 根数据通道变成 FRL Lane 0/1/2，原时钟通道变成 FRL Lane 3，时钟信息嵌入 16b18b 编码的数据流（规范 6.4 节）。

速率配置（Table 6-19）

• 3 Lane 模式只能跑 3/6 Gbps（Lane 3 禁用，两端保持默认差分端接）；
• 4 Lane 模式才能跑 8/10/12 Gbps；
• 编码从 TMDS 的 8b→10b 换成 16b18b（效率 88.9%），链路层的载荷仍是 TMDS 时代组织的 Tri-Byte 流（详见系列第二篇）。

为什么需要训练

时钟线一砍，接收端必须自己从数据流恢复时钟（CDR）；12 Gbps/lane 经过线缆后高频衰减、码间干扰严重；Source 不知道线缆好坏，不能预设参数。所以只能原地训练：发已知图案 → Sink 评估 → 通过 SCDC 反馈 → 循环到链路合格。这套思路和 DisplayPort 的 Link Training 同源，但实现细节完全不同（见第十一节对比）。

TMDS 模式永远不做 Link Training（规范 6.4.2 规定：TMDS 传输不使用 Link Training）。训练只属于 FRL。

三、全局流程：LTS 状态机

训练状态机定义于规范 Figure 6-15，共 6 个状态：

                ┌─────────────────────────────────────────────┐
                │          LTS:1  Read EDID                   │
                │  (读 HF-VSDB: Max_FRL_Rate / SCDC_Present)  │
                └─────────────────────┬───────────────────────┘
                                      │
                  Sink 支持 FRL 且 Source 发起 FRL 训练
                                      ▼
                ┌─────────────────────────────────────────────┐
                │          LTS:2  Prepare for FRL             │
                │  (Source 轮询 FLT_ready, 写 FRL_Rate)       │
                └─────────────────────┬───────────────────────┘
                                      ▼
                ┌─────────────────────────────────────────────┐
                │          LTS:3  Training in Progress        │
                │  (LTP 图案 + LTP_req/FLT_update 握手)        │
                └──────────────┬──────────────┬───────────────┘
                               │              │
                       训练失败/tFLT超时     Sink 请求换速率(0xF)
                               │              ▼
                               │      ┌──────────────────┐
                               │      │  LTS:4 Update    │
                               │      │  FRL_Rate        │
                               │      └────────┬─────────┘
                               │        有更低速率 → 回 LTS:3
                               │        无更低速率 → 回 LTS:L
                               ▼
                ┌─────────────────────────────────────────────┐
                │   LTS:L  Legacy TMDS (训练失败/不支持)      │
                └─────────────────────────────────────────────┘
                                      ▲
                                      │ 训练全部通过
                ┌─────────────────────┴───────────────────────┐
                │  LTS:P  FRL training passed                 │
                │  (发 Gap Character → FRL_start → 传视频)     │
                └─────────────────────────────────────────────┘

三个角色：

• Source（显卡/播放器）：发起训练、发图案、执行 Sink 请求、管超时
• Sink（电视/显示器）：检测信号质量，通过 SCDC 寄存器主动指挥训练（和 DP 最大的不同）
• SCDC（Status and Control Data Channel）：跑在 DDC 的 I2C 总线上（slave 地址 0x54），所有协商都走这里——HDMI 没有 DP 那种专用 AUX 通道（1 Mbps 曼彻斯特编码），只能复用 E-EDID 的 I2C，慢一个数量级，所以训练里 Source 要周期轮询状态位

四、LTS:1 与 LTS:2——先搞清楚对方是谁

LTS:1：读 EDID

Source 读 EDID 里的 HF-VSDB（HDMI Forum Vendor Specific Data Block），三个字段决定能否走 FRL：Max_FRL_Rate（4 bits，Sink 最高支持的 FRL 速率等级，0 = 不支持）、SCDC_Present（是否实现了 SCDC 寄存器组）、SCDC Sink Version（非 0 才有效）。

Max_FRL_Rate 是累积式的：值越大表示支持的范围越宽（规范 Table 10-6）：

判断逻辑一句话：Max_FRL_Rate > 0 且 SCDC_Present = 1 且 Sink Version ≠ 0 → 走 FRL（LTS:2）；否则走 TMDS（LTS:L）。

LTS:2：等 Sink 说"我准备好了"

Source 轮询 Status Flags 的 FLT_ready 位（0x40，Bit[5]）。Sink 上电后就置 1（“可以接受训练”）；若 Sink 检测到 TMDS 传输（FRL_Rate = 0 且字符锁定成功），退到 LTS:L。

Source 看到 FLT_ready = 1，做三件事：写 FRL_Rate（选速率和 Lane 数，0x31 [3:0]）、写 FFE_Levels（告知当前速率下可用 FFE 档位数，0x31 [7:4]）、所有 active Lane 的 TxFFE 设为默认档 TxFFE0，然后进 LTS:3。

FRL_Rate 编码（规范 Table 10-21），注意同时编码了"速率 + Lane 数"：

五、LTS:3——训练进行时（核心）

关键理解：HDMI 的训练是 Sink 主导的——Sink 不像 DP 那样用 ADJUST_REQUEST"建议"参数，而是直接指定每条 Lane 要什么训练图案，Source 只是执行者。

握手协议：LTP_req + FLT_update

Sink 侧（每轮循环）：

WHILE (1)
    FOR EACH active Lane x:
        编程 Ln(x)_LTP_req  ← 从 Table 6-32 选图案码（或特殊码）
    IF 任一 LTP_req 变了:
        置 FLT_update = 1    ← 通知 Source "有新要求"
    IF 所有 active Lane 的 LTP_req = 0:
        等 Source 清 FLT_update → EXIT to LTS:P  (训练完成)
    IF 检测到 TMDS 传输:
        EXIT to LTS:L
END WHILE

Source 侧（每轮循环）：

STEP 1: 启动 FLT Timer（单速率训练时限 tFLT = 200 ms）
        IF 计时器到 200 ms → EXIT to LTS:L（训练失败）

STEP 2: 轮询 FLT_update（≤ 2 ms 一次）
        IF FLT_update = 0 → 继续轮询
        IF FLT_update = 1 → 读 Ln(x)_LTP_req

        IF 所有 active Lane 的 LTP_req = 0        → EXIT to LTS:P  (训练完成)
        ELSE IF 所有 active Lane 的 LTP_req = 0xF  → EXIT to LTS:4  (换速率)
        ELSE:
            FOR EACH active Lane x:
                IF Ln(x)_LTP_req = 0xE   → 更新该 Lane 的 TxFFE 档位（升一档），继续发原图案
                ELSE IF LTP_req = 1..8   → 该 Lane 改发对应的训练图案
                ELSE                     → 继续发原图案
        Source 写 FLT_update = 1 清除（读到置位后 10 ms 内必须清）
        GOTO STEP 2

一句话概括：Sink 点菜（写 LTP_req）→ Sink 摇铃（置 FLT_update）→ Source 上菜（取 LTP_req → 换图案/调 FFE → 清 FLT_update）→ 循环，直到 Sink 把 LTP_req 全部写成 0（“不用再练了”）。

关键时序参数

对比 DP：DP 等待 100 μs 起步、重试 5-10 轮；HDMI 协商通道是慢速 I2C，节奏慢一两个数量级，但单速率训练最多 200 ms 必须出结果——DP 失败降速再训，HDMI 失败直接退回 TMDS（除非 Sink 主动请求换速率）。

训练完成与失败

• 完成：Sink 把所有 LTP_req 写成 0 → 双方进 LTS:P；
• 换速率：Sink 把所有 LTP_req 写成 0xF（特殊码，必须所有 active Lane 同时写）→ Source 进 LTS:4 选更低速率；
• 失败：FLT Timer 到 200 ms → Source 进 LTS:L 启动 TMDS。

LTP_req 是逐 Lane 独立的（Lane 0/1/2/3 各有自己的请求寄存器），Sink 可给不同 Lane 要不同图案——多 Lane 去偏移阶段特别有用。特殊码 0xE（调 FFE）和 0xF（换速率）例外：0xF 必须所有 Lane 同时写。

六、训练图案全景——Sink 到底在要什么

训练图案（Table 6-32）共 8 种 LTP + 2 个特殊码。前 4 种是裸比特流（不经过 16b18b 编码），后 4 种是 16b18b 编码的 LFSR 序列。

注意两者粒度差异：0xE 是逐 Lane 灵活的——Sink 可只针对质量不达标的一条 Lane 单独调 FFE；0xF 必须所有 Lane 同时写，因为换速率是整条链路行为，不能只降某几条 Lane。

逐个拆解

• LTP1/2（全 1/全 0）：没有任何跳变，让 Sink 校准接收端直流工作点——slicer 门限该放哪，等价于干净的 DC 参考。
• LTP3（Nyquist 交替）：每个 bit 翻转一次，等价于频率 = bit rate ÷ 2 的方波（12 Gbps 下 6 GHz），对 CDR 最理想，和 DP 的 TPS1 思路一样。规范里有个限定：当 FLT_no_timeout = 0（正常链路下 Sink 必须清 0）时，Source 应忽略 LTP3 请求。这字段只有测试设备能置 1，所以正常产品里 LTP3 实际用不上。原因推测：连续 0101… 产生 6 GHz 频谱尖峰（训练图案不加扰），干扰无线频段，所以限制给测试场景。
• LTP4（128×0 + 128×1）：TxFFE 一致性测试图案，规范用它测量 Source 在 De-emphasis only / Pre-shoot only / No FFE 三种模式下的 FFE 档位（Table 6-30 的 dB 指标）。
• LTP5-8（LFSR 序列）：训练主力。每个图案 = 4 个 SR 字符 + 4092 个加扰字符（Lane x 的 LFSR 16 bit 输出 → 16b18b 编码）。四个图案用四条 Lane 各自的 LFSR 种子（0xFFFF / 0xFFFE / 0xFFFD / 0xFFFC），Sink 靠区分"收到的是哪条 Lane 的序列"做 Lane 间去偏移；SR 在所有 active Lane 上同时发送，是跨 Lane 对齐的时间基准。加扰后频谱接近白噪声，均衡器能看到线缆全频段衰减，正好建立完整补偿曲线——等于把 DP 的 TPS2/3（EQ）+ TPS4（加扰抗 EMI）+ 逗号码对齐打包成了一套。

七、LTS:P——训练完成，链路就绪

这里有个很优雅的设计：链路不是直接传视频，而是先传一段"空数据"。

Source 侧：开始 FRL 传输，只发 Gap Character（填充字符），并带加扰 + Reed-Solomon FEC + Super Block 结构（规范 6.5.1.1 / 6.5.3 / 6.5.4）；继续轮询（≤ 2 ms）——看到 FRL_start = 1（Sink 说"可以收视频了"）就清掉并开始发正常音视频包；看到 FLT_update = 1（Sink 要求重训）就停止传输、清标志、回 LTS:3。

Sink 侧：检测到 FRL 传输（Gap + 加扰 + RS FEC + Super Block 结构）→ 置 FRL_start = 1。Sink 在进入 LTS:P 后 tFLT（200 ms）内必须置 FRL_start 或 FLT_update 二选一。

Gap 的意义：视频数据还没准备好时，Source 用 Gap 字符占满带宽，让 Sink 先锁定字符、完成 Lane 锁定、建立 RS FEC 同步——链路先"跑起来"再"装货"。这比 DP 的"训练图案 → 直接切视频"多了一层过渡。

Super Block 结构

FRL Packet（变长包，封装 Tri-Byte 流）
    ↓ 组装
502 个 FRL Character + 8 个 RS 校验字符 = 510 字符的 Character Block
    ↓ 4 个一组
Super Block = 2040 字符（4 Lane 模式，每 Lane 分摊 510 字符）
    ↓ 循环：SSB 伴随 32 个连续 Super Block，之后 1 个带 SR

• SSB（Start Super Block）：标志 Super Block 组开始；
• SR（Scrambler Reset）：重置加扰器种子，Sink 借此同步解扰。

两者 18-bit 编码里各含一个逗号码序列（0b00000001000 / 0b11111110111），正常数据流中永不出现，Sink 靠扫描做字符对齐；所有 active Lane 同时发，SSB/SR 后紧跟 FRL Map Character（Lane 0）。

Lane Lock 检测（规范 6.5.9）

4 Lane 模式：SSB 或 SR + 510 字符周期，连续重复 3 次 → 置 Lane 锁定位
3 Lane 模式：SSB 或 SR + 680 字符周期，连续重复 3 次 → 置 Lane 锁定位
连续 2 个 Super Block 周期没检测到 SR/SSB → 清锁定位

Lock 状态反映在 Status Flags 的 Ch0_Ln0_Locked、Ch1_Ln1_Locked、Ch2_Ln2_Locked、Lane3_Locked 位——排错时判断"链路是否真的建立"的第一手证据。

八、16b18b 编码原理——FRL 的物理层心脏

训练完成了，数据怎么变成信号发出去？答案是 16b18b 编码。它是 FRL 相对 TMDS 最核心的物理层变化，也是本文新增的重点。

8.1 为什么是 16b18b

16b18b 用更少的冗余实现同样的两个目标（压跳变、保 DC 平衡）——效率比 TMDS 高近 9 个百分点。在 12 Gbps/lane 的线速下，这 9 个百分点就是约 1 Gbps/lane 的有效带宽差距。

8.2 两级查表编码（规范 6.5.8）

16 bit 输入先拆成两段，分别查表编码，拼成 18 bit：

16-bit 输入 YXWVUTS_IHGFEDCBA
       │                │
       │ 低 9 位         │ 高 7 位
       ▼                ▼
   9b→10b 查表       7b→8b 查表
   (IHGFEDCBA)       (YXWVUTS)
       │                │
       ▼                ▼
  10-bit 子字符      8-bit 子字符
   abcdefghij        stuvwxyz
       └───────┬───────┘
               ▼
      18-bit FRL Character
      (abcdefghij_stuvwxyz，a 先发)

编码规则：

• 9b10b 表和 7b8b 表是规范附带的查表文件（HDMI_16b18b_Coding_v1.xlsx），Source 必须按表实现；
• 每个 Lane 独立维护 running disparity；
• 编码顺序：先用当前 RFD（Running Front Disparity）选 9b10b 码字 → 得到 RMD（Running Mid Disparity）→ 用 RMD 选 7b8b 码字 → 得到 RED（Running End Disparity，即下一个字符的 RFD）；
• 选码字的目标：让 RMD、RED 的绝对值最小——disparity 被"夹"在 ±1 或 ±3，长期直流接近零；
• 初始 RFD 由 Source 设为 +3 / +1 / -1 / -3 之一，链路启动后不再重置。

设计思路和 TMDS 的 8b→9b→10b 一脉相承（都是"编码 + 直流平衡"），但实现更精细：TMDS 用"差分 + 取反决策"，FRL 用"查表 + 双级 disparity 控制"。查表的好处是码字可以预先优化——表里的码字已经同时照顾了跳变密度和 DC 平衡，编码器只需要做查表决策。

8.3 特殊字符：SSB 和 SR（Table 6-62）

除了 16 bit 数据，FRL 还需要两种"带外"控制字符。它们不走 9b10b/7b8b 查表，而是按 RFD 直接查表：

两种字符的码字里各含一个逗号码序列（0b00000001000 / 0b11111110111）——这两个序列在正常 16b18b 数据流中永远不会出现，Sink 靠扫描它们完成字符对齐（找 18-bit 边界）。这等价于 TMDS/8b10b 里的 K 码（逗号码）角色。

SSB/SR 的调度：32 个 Super Block 发 SSB，接 1 个发 SR，循环。SR 出现的时刻是加扰 LFSR 重置的锚点——Sink 一旦在预期时刻没等到 SR，就知道链路出问题了（Lane Lock 检测就依赖这个）。

8.4 加扰 LFSR（规范 6.5.7.1）

16b18b 编码解决 DC 和跳变，但原始数据加扰解决 EMI——和 TMDS 2.0 的加扰同思路：

原始 16-bit 数据 → XOR 加扰（LFSR 伪随机序列）→ 加扰后 16-bit → 16b18b 编码 → 发送

• 每 Lane 独立 LFSR，每个 FRL 字符推进 16 个状态；
• SSB/SR 字符不加扰（它们是同步锚点，必须保持已知）；
• 种子值在 SR 字符期间加载：Lane 0 = 0xFFFF、Lane 1 = 0xFFFE、Lane 2 = 0xFFFD、Lane 3 = 0xFFFC——每条 Lane 的序列不同，Sink 借此区分 Lane（也是 LTP5-8 训练图案的种子来源）；
• 加扰后频谱接近白噪声，12 Gbps 的强辐射被"打散"，不再集中冲击无线频段。

8.5 和 TMDS 编码的对比

一句话：TMDS 是"算法编码"，FRL 是"查表编码 + 双级直流控制 + 内置加扰"——后者把信号完整性问题的解决从"计算"变成了"查表"，效率更高、行为更可预测。

九、SCDC 寄存器速查

训练的本质是双方通过 SCDC（I2C slave 地址 0x54）完成一轮轮"写→轮询→读→执行"。以下是与训练相关的全部寄存器。

9.1 Update Flags（0x10 / 0x11）——Sink 的"门铃"

训练协议里只有两个门铃重要：FLT_update（训练协商）和 FRL_start（训练完成）。Sink 置位后，Source 要么每 ≤ 2 ms 轮询，要么用 SCDC Read Request 机制让 Sink 主动拉响 I2C 读取。

9.2 Configuration（0x30 / 0x31）——Source 写入

0x30：Bit 0 RR_Enable（Source 支持 Read Request 时置 1，否则轮询）；Bit 1 FLT_no_retrain（仅测试设备可置 1；置 1 后 Sink 不在 LTS:P 重训，且不渲染音视频）。

0x31：[7:4] FFE_Levels（Source 支持的 TxFFE 档位数 - 1，随 FRL_Rate 更新）；[3:0] FRL_Rate（目标速率+Lane 数编码，见第四节表格）。

0x35（Source Test Configuration）：Bit 7 FRL_Max、Bit 6 DSC_FRL_Max（测试设备置 1 时，Source 按双方最大速率训练）；Bit 5 FLT_no_timeout（Source 不超时，LTP3 也才有效）；Bit 2 TxFFE_No_FFE、Bit 1 TxFFE_De_Emphasis_Only、Bit 0 TxFFE_Pre_Shoot_Only（Source 1 秒内进入对应测试模式）。

9.3 Status Flags（0x40）——Sink 状态回读

9.4 LTP_req（0x41 / 0x42）——Sink 的"点菜单"

0x41 [3:0] Ln0_LTP_req、0x41 [7:4] Ln1_LTP_req、0x42 [3:0] Ln2_LTP_req、0x42 [7:4] Ln3_LTP_req——各 Lane 请求的训练图案码（Table 6-32）。

9.5 FRL Character Error Counters（0x50-0x58）——链路健康仪表

训练后 Sink 持续统计每条 Lane 的 FRL 字符错误（16b18b 解码的 running disparity 超限即记一次错），每计数器 15 bit，分布在 0x50-0x58（含校验和）。Source 周期读它评估 BER——规范目标 10⁻¹⁰ 以下，并给了监测窗口（Table 6-63）：例如 10 Gbps × 4 Lane 时，2.5 秒内总错误 > 10 个，即说明链路 BER 可能超标。

十、链路维护与降级

运行中的重训

• Sink 请求重训（同速率）：置 FLT_update → Source 停止 FRL 传输、清标志 → 回 LTS:3 用原速率重新训练；
• Source 发起新 FRL 模式：建议先 AV mute → 停止 FRL 传输 → 回 LTS:2 重新准备。

常见触发：错误计数器超阈值、线缆被弯折/热漂移致信号劣化、Lane 解锁（连续 2 个 Super Block 周期找不到 SR/SSB）。

失败路径：一步一步退回 TMDS

训练失败（FLT Timer 200 ms 超时）或 Sink 请求换速率（全 0xF）
        ↓
LTS:4：Source 停发图案，TxFFE 复位到 TxFFE0，选更低带宽的 FRL_Rate
        ├─ 有更低速率（12→10→8→6→3 Gbps/lane 逐级降）→ 写新配置 → 回 LTS:3
        └─ 没有更低速率 或 Source 决定结束 → LTS:L → 启动 TMDS

和 DP 的降级策略对比

DP：Source 端内部计数（同一 ADJ_REQ 连续 5 次 / 累计 10 次 AUX Read / 驱动已到最大），自动降速率→减 Lane，再不行才放弃。

HDMI：Source 不自作主张——降不降、降到哪由 Sink 定（0xF 请求），Source 只负责挑选具体速率执行。而且没有"减 Lane 再训"的中间档：速率列表里 3/4 Lane 是绑定的（FRL_Rate 编码同时含 Lane 数），失败要么换下一档，要么直接回 TMDS。

十一、HDMI FRL Training vs DP Link Training 对比

架构差异总结：DP 的训练是"Source 主导、Sink 反馈、协议驱动自动收敛"；HDMI FRL 是"Sink 主导、Source 执行、协商通道走慢速 I2C"。后者像"点菜—上菜"的循环，前者像"自动巡航"。

十二、常见问题排查——分角色视角

Source 端（显卡/驱动开发者）

排查起点：“I2C 读写是否正常、轮询到了什么状态”。

• 训练根本不开始：查 EDID HF-VSDB——SCDC_Present 和 Max_FRL_Rate 都为 0 说明 Sink 不支持 FRL，走 TMDS 正常，不是 bug。
• 卡在 LTS:2：轮询 FLT_ready 读不到 1。查 Sink 上电、+5V、HPD——SCDC 寄存器在 +5V 缺失或 HPD 拉低 > 100 ms 时会全部清零（含 FLT_ready）。
• LTS:3 反复要同一图案：Sink 一直要 LTP5-8 却迟迟不写 0 收尾。多半是信号质量不够（12 Gbps 劣质线缆均衡器收敛不了），先降一档速率验证。
• FLT Timer 超时（200 ms）：抓 I2C 看 LTP_req 轨迹——从头到尾只有 LTP5 一种请求 → 物理层问题；Sink 发了 0xF 但 Source 没响应 → 查 LTS:4 降速率逻辑。
• 运行期频繁重训：读错误计数器。2.5 秒窗口（10 Gbps × 4）内错误 > 10 个说明 BER 超标，优先查线缆/连接器。

Sink 端（电视/显示器开发者）

排查起点：“LTP_req 写对没有、FLT_update 有没有按时置位”。

• FLT_ready 置不了 1：查 SCDC 使能后状态寄存器是否正确初始化；检测到 TMDS 传输时要回 LTS:L 并重新置 FLT_ready，别把状态机写死。
• LTP_req 更新了但 Source 不响应：检查 I2C 时序——FRL_Rate 写事务后 10 ms 内必须编程 LTP_req + 置 FLT_update，别超时限。
• LTP5-8 收到但 Lane 锁不上：查 Lane Lock 逻辑——SSB/SR + 510 字符周期重复 3 次才锁定（4 Lane），阈值别太严；确认在解 16b18b 后的字符流，而不是原始比特流。
• 训练收尾不了：写完 LTP_req = 0 要等 Source 清 FLT_update 才进 LTS:P；进 LTS:P 后 200 ms 内必须置 FRL_start 或 FLT_update，否则 Source 超时。

排查顺序

1. EDID 的 Max_FRL_Rate / SCDC_Present 是否支持 FRL
2. SCDC（0x54）能否正常读写、FLT_ready 是否置位
3. LTP_req 是否在 FRL_Rate 写后 10 ms 内编程、FLT_update 是否置位
4. 200 ms 超时直接回 TMDS——优先怀疑线缆质量

十三、总结

FRL Link Training 是 HDMI 2.1 里最"反 HDMI"的设计：一个以"即插即用"著称的接口，在高带宽需求下不得不向 DP 的架构模型靠拢——砍掉独立时钟、嵌入时钟、多 Lane 训练协商。区别在于 HDMI 把训练放到了慢速 I2C/SCDC 通道上，且把主导权交给了 Sink：

• Sink 主导 → 用 LTP_req 逐 Lane 点图案，用 FLT_update 摇铃，Source 只执行；
• 8 种训练图案 → LTP1/2 校准直流，LTP5-8（LFSR + SR）做均衡/字符锁定/Lane 去偏移；
• 严格时序 → 2 ms 轮询、10 ms 清铃、200 ms 单速率时限；
• 16b18b 编码 → 双表查表 + 双级直流控制（RFD/RMD/RED），效率 88.9%，比 TMDS 高近 9 个百分点；
• 失败必退路 → 要么 Sink 请求降速率（0xF），要么直接回 TMDS——没有 DP 那种细腻的逐级降级。

排 HDMI 2.1 黑屏/降级问题：先看 EDID 的 Max_FRL_Rate / SCDC_Present 支不支持 FRL，再抓 I2C 看 FLT_ready / FLT_update / LTP_req 走到哪一步，配合错误计数器和 Lane Lock 位定位是物理层还是状态机的问题。

HDMI 2.1 的 Training 是一个"借架构、留包袱"的设计——借 DP 的物理层思路突破带宽天花板，把协议层协商的复杂度留在了 SCDC 那根 100 kHz 量级的 I2C 总线上。