FRL协议基础：帧结构与编码方式
好，我们开始聊FRL协议的核心。说白了，固定速率链路（FRL）就是HDMI 2.1在物理层上用来高速传输数据的那套规矩。我个人习惯把它拆成两大部分来看：一是数据怎么打包成帧，二是这些比特怎么编码成能在线路上跑的符号。
2.1 FRL链路帧结构
FRL的链路层会把要传的视频、音频、辅助数据都塞进一个个固定长度的帧里。为什么非要固定长度？因为接收端的时钟恢复和同步需要稳定的参考点。
| 帧区间 | 长度（符号） | 主要内容 |
|---|---|---|
| 帧头（Header） | 12 | 特殊同步字符序列，用于帧锁定 |
| 数据区间（Data） | 可变（与速率相关） | 视频像素、音频包、InfoFrame等 |
| FEC区间 | 与数据区间长度相关 | 前向纠错校验码（RS纠错） |
你可能会问，怎么区分这些区间？嗯，全靠帧头那12个符号。它们是一组固定的、在正常数据里几乎不会出现的特殊序列。我在项目中遇到过接收端因为信号抖动，把错误的符号误判成帧头的情况，那叫一个痛苦。后来我建议设计时在硬件里加了个“连续锁定校验”，连续检测到3个以上有效帧头才确认锁定，误判率明显下来了。
2.2 编码方式：从比特到符号
FRL没有沿用传统HDMI的TMDS编码，而是换了一套更高效的映射方案。我个人觉得这个改动是HDMI 2.1能跑到48Gbps的关键之一。
- 未编码映射：直接取8比特数据映射到10比特符号，但保留了K码和D码的区分。这在FRL的帧头和控制字符里用得比较多。
- FRS符号：固定速率符号。发送端在每个链路时钟周期，往每条通道上压一个符号。3条通道就是3个符号，4条就是4个。
关键点：FRL不是每比特都编码，而是每8位数据块映射成一个10位符号。但跟8b/10b不同的是，FRL允许某些符号不经过编码直接传，用来节省开销。
2.3 编码表与特殊字符
说白了，FRL的编码表里除了数据符号，还留了一批控制符号。这些控制符号用来做帧起始、帧结束、以及链路训练时的握手。
调试小贴士：我建议做FRL调测时，先抓一下链路两端的FRS序列。如果看到接收侧反复收到“Bad Lane Alignment”或者“Frame Header Lock Lost”这类标记，十有八九是编码映射出现了位错误。我曾经在一条高损耗的PCB走线上折腾了两天，最后发现只是某个通道的预加重参数没调对导致符号误码率飙升。
为了让你有个直观印象，我把常用的几个特殊字符列一下：
| 符号名称 | 用途 | 典型场景 |
|---|---|---|
| K28.0（Header） | 帧头起始标记 | 帧同步 |
| K28.1（Scrambler Reset） | 扰码器复位 | 链路训练第一阶段 |
| K28.3（FEC Turnaround） | FEC区间结束标识 | FEC校验边界 |
注意：千万不要在常规数据流里使用与控制符号相同的10位码型，否则接收端会误触发状态机切换。我见过有人因为视频内容恰好跟K28.0的码型撞车，导致接收端频繁失锁，画面周期性黑屏。
2.4 FRL链路帧整体流程
讲到这里，给你看个总体的结构图。它把帧头、数据、FEC这三块串起来。接收端每次收到固定数量的符号后，先找帧头，找到后再按规则切分数据区间和FEC区间。
接收流程示例（3通道模式）：
1. 等待并检测帧头序列（12个FRS符号）
2. 锁定帧边界
3. 读取通道对齐标记（Lane Alignment Symbol）
4. 启动FEC解码器，准备接收数据区间
5. 接收完数据符号后，进入FEC区间，校验纠错
6. 输出有效数据给上层（视频/音频引擎）
为什么链路要有一个固定的帧头？说白了，就是给接收端一个“就在这里开始”的锚点。没有帧头，接收端在一堆连续比特流里根本不知道从哪开始解析数据。
2.5 本章小结
为了让你更直观地理解FRL协议在链路层到底怎么工作的，我特意画了一个结构图。这个图把从发送端到接收端的帧组成、编码映射，以及最终的数据恢复串联了起来。
嗯，这个图把刚才讲的内容串起来了。从发送端的帧头生成、数据映射、FEC编码，经过链路传输，再到接收端的帧锁定、通道对齐、符号解码和FEC纠错，每个环节缺一不可。