1. FRL流控它到底在控什么HDMI 2.1真正让人兴奋的不只是把带宽从18Gbps干到48Gbps而是它彻底换了一套传输机制从TMDS换成了FRLFixed Rate Link固定速率链路。很多人看到“FRL流控”这几个字就直接懵了——FRL不是固定速率吗固定速率还需要什么流控这其实是把“流控”理解窄了。在HDMI 2.1里流控不是我们熟悉的PCIe那种基于credit的带宽分配而是一整套保证数据在固定速率链路上稳定传输的机制包括链路训练、加扰同步、FEC校验、数据岛通道划分等核心载体就是流控帧。这篇文章试图把这套机制讲透FRL流控为什么存在、流控帧怎么工作、链路训练时发生了什么、遇到黑屏闪屏怎么排查。我尽量用工程师之间聊天的方式讲不做教科书式罗列适合做HDMI 2.1源端或显示端开发的同行也适合做电竞显示器、高清矩阵、采集卡、VR头显的硬件工程师参考。TMDS时代其实很省心像素时钟和TMDS clock绑定信号是连续的、带clock的接收端恢复数据相对轻松。但到了8K60或者4K120这种场景18Gbps打不住了必须往上提。FRL的做法是去掉独立的像素时钟通道把clock信息嵌入数据流用更高的线速率最高每通道12Gbps配合3条或4条通道跑出48Gbps总带宽。省掉了时钟通道代价就是接收端必须自己恢复时钟和字节边界这个“恢复”动作就离不开流控帧。所以FRL流控的本质是两部分一是确保物理链路训练无误让收发双方在速率、通道数、FEC配置上达成一致二是在正式传输时通过周期性插入的流控帧含加扰种子同步、FEC校验块维持链路的符号锁和错误率在可接受范围。你不能把它理解成“动态调整带宽”的流控它不是那个逻辑它是“静态速率、动态守护”的流控。1.1 HDMI 2.1 FRL在整体架构中的位置先画个大框架。HDMI 2.1的接口协议栈分几层物理层PHY差分信号对最高12Gbps/lane3或4条lane。链路层FRL packetize机制负责把数据封装成固定长度的帧加上scrambling、FEC。传输层对应HDMI 2.1的data island、video payload、audio payload以及MSA、ACR这些辅助信息。应用层EDID、HDCP、动态HDR元数据、eARC等。FRL流控主要工作在物理层和链路层交界地带。物理层处理差分信号、均衡、时钟恢复链路层处理成帧、加扰、FEC——这正是流控帧发挥作用的地方。有人问FRL的四条lane不是并行跑吗为什么还要搞“帧”这个概念原因是虽然lane是并行的但每一条lane都是独立串行链路彼此之间没有公共时钟。接收端必须先从每条lane上恢复出串行时钟再从数据流里找到字符边界然后才是所以对齐到一个统一的帧结构上。这个过程没有预设的时钟做参考只能靠数据本身的自描述信息——这就是FRL把数据组织成帧、并按帧格式插入同步信号的根本原因。一个FSFlow Status/FEC流控帧的存在就好比在一条没有路标的高速公路上给每辆车都装上GPS和编队灯车队多lane成员之间靠“编队灯”对齐标记知道谁在哪个位置路况监控FEC负责查有没有车掉队出错而领航车LTPS训练序列首先跑一遍确认整个车队能按这个速度巡航。1.2 为什么FRL需要流控帧而不是沿用时钟通道我见过不少从DisplayPort转过来做HDMI的工程师会习惯性拿DP的lane training概念去套FRL然后发现对不上。DP的training也是基于link training pattern但它的流控更多靠symbol级机制FRL则把很多东西显式做成了“帧”。TMDS的老方案是单独的clock lane像素数据通过三个数据通道并行传。接收端直接用clock恢复数据简单粗暴但限制了速率。HDMI 2.1为了上48Gbps不可能再用3.12GHz的TMDS clock太高了。FRL的方案是去掉clock lane省出来的四根线可以都跑数据这也是4 lane的由来把时钟信息通过内嵌的加扰机制传。自同步加扰self-synchronizing scrambler是核心发送端用LFSR把数据打乱后发出接收端用同样的多项式从接收到的数据流反推加扰种子达到自动同步。这个加扰种子不是随时发而是在每帧固定的位置通过固定格式头来同步。这个“固定在特定位置出现的同步数据块”就是我们说的流控帧。流控帧的“流控”两个字还体现在它承载链路状态反馈比如接收端可以报告错误计数、请求重新训练、通知FEC处理结果的返回状态。虽然是单向HDMI传输源到显示设备但通过CEC/eARC或链路的RMRepeated/Monitor机制其实是有反向信息通道的。可以说FRL流控帧的角色就是把原来TMDS时钟通道的职责数字化、帧化、嵌入数据流同时额外承担纠错和状态管理。2. 流控帧与链路训练机制详解FRL流控帧不是传输起来才有的而是从链路训练那一刻就开始全程参与。HDMI 2.1源端在上电、分辨率切换、HDCP重握手等场景下会发起一次FRL Link Training。这个训练过程分为几个阶段每个阶段用的训练序列叫LTPSLink Training Pattern Sequence编号从LTPS1到LTPS7。2.1 链路训练阶段LTPS1到LTPS7都在干什么训练的目标很简单源端要知道接收端sink支持几条lane、跑多高速率、要不要开DSC、FEC配置是什么。这些信息从哪里来主要来自两个地方一是初始化时读sink的EDID里HDMI Forum Vendor Specific Data BlockHF-VSDB的FRL configuration字段二是训练过程本身通过LTPS在物理链路上验证。LTPS1固定字符重复用于接收端锁定串行数据和恢复位时钟。这个阶段发送的pattern通常是对所有lane发送同一固定数据接收端可以用它来做CDR时钟数据恢复和SQ信号质量评估。LTPS2开始加扰的数据用于字节同步。数据是LFSR加扰后的固定pattern接收端可以靠这个pattern做字对齐。因为数据是加扰的所以频谱更接近真实数据。LTPS3加入FEC的周期性数据。到了这个阶段链路层开始在这些pattern上计算并附加RS奇偶校验字节接收端可以确认FEC能否工作。这个阶段会用到RS残差评估如果误码太高后面会有link rate降级。LTPS4-7更具体的速率/通道测试用scrambled data FEC的组合方式看链路在特定配置下的持久稳定性。值得说明的是LTPS本身不是流控帧的正式结构但训练过程中每一步都定义了严格的时序和状态切换条件一旦某一步的时间窗超过阈值就会宣告训练失败可能回退到较低速率或者TMDS模式。很多时候HDMI 2.1源端接到老显示器能出画面但只能跑TMDS就是这个原因。2.2 加扰与帧对齐流控帧的“起始标记”FRL正式传输时数据以固定长度的帧为单位组织。每个帧大约是多少具体和lane速度有关。帧结构里有帧头含同步字段、数据区包含视频/音频/辅助数据、以及可选的FEC校验区。同步的关键在帧头。我做过一次抓包发现帧头的字节模式是有特征的FRL paket头有一个3字节的header我们称之为HB0/HB1/HB其中包含了PBpacket type等字段。同步的作用是接收端确认当前读到的字节就是帧边界然后按既定的帧长逐帧数下去同时跟踪加扰种子。自同步加扰通常用的是帧同步加扰frame sync scrambler发送端在每个帧边界重新初始化LFSR种子并把种子通过帧头里显式或隐式的方式告知接收端。HDMI 2.1的FRL加扰多项式是标准的多项式我记得是1 x^14 x^15它让数据流在接收端即使连续遇到长串的0或1也不会丢失位同步。这一点在长距离传输或低质量线缆上非常重要因为长连字符会导致CDR电路失去参考边沿。实际操作中判断加扰是否同步的方法是检查帧头校验或CRC。如果帧头连续出错很多说明加扰种子没齐接收端会重新开始搜索帧边界这个状态会反映为log里的“scrambler sync loss”计数。这个计数的调法是很有用的诊断信号。2.3 FEC与流控开销FRL的FEC用的是Reed-Solomon码具体有两种配置RS(245,223)和RS(255,223)。RS(245,223)的意思是每245个字节里有223个数据字节22个奇偶校验字节RS(255,223)就是255字节块里有32个校验字节。它最多可以纠正在一个块里的多个错误符号RS码是符号级纠错一个符号通常是一个字节。FEC的引入解决了FRL一个非常头痛的问题高速串行链路上瞬态误码是随机的但如果不用FEC随机误码会直接导致视频画面撕裂、黑白闪或者CRC错误。而很多消费级线材在有压力的情况下比如靠近电源线、弯折状态误码率会显著上升FEC就像是一个兜底的安全网。代价是什么带宽开销。FEC平均占约9%~12%有效载荷所以在计算HDMI 2.1实际可用带宽时不能简单拿链路总带宽乘以利用率还要减去FEC开销。比如4 lane每lane 12Gbps时物理层总码率48Gbps但有效载荷大约48Gbps × (223/245) ≈ 43.7Gbps再扣除其他的数据岛开销实际能用于视频流的带宽在40Gbps上下。这也是为什么某些8K60或者高刷4K场景要开DSC因为即使48Gbps配上FEC开销之后也紧张。从流控角度看FEC其实承担了“减少重传/重训”的任务。HDMI没有复杂的ARQ重传机制错误不能回退重传只能通过FEC当场纠正。一旦误码超过FEC纠错上限接收端只能丢掉整个块或者报错链路可能需要重新训练。所以FEC是FR流控体系里实质性保障可靠性的一环。很多工程师在调链路稳定性时第一个看的指标就是FEC符号错误计数的变化趋势。3. 实操拆解一次真实的FRL流控过程光讲协议不够劲我拿一个实际项目来演示怎么调试FRL流控。这是一个HDMI 2.1显示端sink的bring-up项目主控是某个主流SoC接的是HDMI 2.1信号源一台8K播放器。调试工具是泰克的高清协议分析仪加示波器。注意没有协议分析仪也能做很多事后面我会讲。3.1 用协议分析仪抓取链路训练阶段协议分析仪接在源和sink之间它会旁路抓取所有信号并解码。上电后不要急着播放视频先保持信号源输出正常但sink端可以关掉主通道方便观察训练时序。我在抓的过程中关注四个关键节点源端是否发起Link Training分析仪上会看到Source发出LTPS1这通常发生在热插拔检测HPD从低拉高之后的几十毫秒内。训练序列的推进LTPS1 - LTPS2 - LTPS3 是否按顺序出现每一段的持续时间是否在协议规定的时间窗口内。配置协商分析仪抓到的FRL configuration字大概在HF-VSDB或训练后的状态字里会显示最终锁定的是3 lane还是4 lane速率是6Gbps、8Gbps、10Gbps还是12Gbps。是否启用FEC和DSC如果sink的EDID里声明了DSC支持源端可能在训练完成后发送DSC的picture parameter setPPS此时看分析仪解码出来的video stream是否带DSC压缩标记。第一次上电时我们发现训练停在LTPS2没有进入LTPS3后面就一直在重复训练。这说明接收端在字节同步之后FEC相关配置协商出了问题。查sink的驱动log发现FEC capability bit没有正确上报源端认为sink不支持FEC于是降级到无FEC模式但sink的硬件FEC模块又被强制开启两边不匹配导致链路一直无法稳定。这个案例的教训是FEC capability的握手是FRL流控里最容易被忽略但又最关键的步骤。sink端必须在训练过程中准确报出自己的FEC支持情况不能想当然地认为“我硬件支持就一定能开”。如果源端检测到协议不一致会不停重训。3.2 没有分析仪怎么从状态日志和寄存器判断流控状态很多做板子的环境没有几万块的协议分析仪但有SoC的调试串口或者I2C寄存器访问能力。这种情况下判断FRL流控正常与否主要靠三大类日志链路状态寄存器SoC的HDMI RX或TX一般都会暴露当前链路状态LINK_READY、SCRAMBLER_LOCKED、SYMBOL_LOCKED、FEC_LOCKED之类这些位组合起来能快速定位问题。错误计数器FEC错误计数RS error count、CRC错误计数、字节错误计数。如果错误计数在跑几分钟内从0变成几千那基本能判定物理链路有压力测试没过。训练次数和时间戳看训练是从哪个LTPS开始的失败后是重训还是降级每次耗时多少。正常链路应该在100ms内完成。有一次我们在调试时发现画面偶尔闪一下然后要等一两秒才恢复。查寄存器发现FEC_LOCKED经常失锁但数据分析下来误码率并不高。后来定位到是sink端FEC clock和主视频clock不同步导致即使PHY收到了正确的数据FEC模块也偶尔算错校验位自己把自己搞失锁。解决方法是把FEC clock的时钟源从全局时钟改为随lane恢复时钟问题就消失了。这类问题不看寄存器很难抓到。3.3 实操记录DSC开启后的流控参数变化另一个实测场景是验证DSC对FRL的影响。当带宽需要超过phys限额比如4K120 10bit 4:4:4时源端会开启DSC压缩此时FRL的链路层参数其实是保持不变的lane数、速率、FEC配置不变但实际传输的视频流payload显著减少。我记录过一次对比测量参数未开DSC开启DSC链路lane数44每lane速率12Gbps12GbpsFEC配置RS(245,223)RS(245,223)视频流带宽占用约39Gbps约28Gbps数据岛可用带宽减少明显增加帧间隔可变性较小更充裕容易保持稳定这个对比告诉我们DSC开了以后链路数据总量下降留给流控帧和FEC校验的裕量更大。理论上误码容限会更好。所以有些时候当链路margin一般时开DSC反而能提升稳定性——不是因为DSC本身能纠错而是它降低了对物理层带宽的压力。当然DSC也有代价画质损失尽管很难感知、DSC需要收发双方都支持、HDCP模式下DSC的处理有额外复杂度。所以在设计时不能单纯为了降低链路负担就无脑开DSC。4. 常见问题与排查技巧实录FRL流控的坑我在不同项目里踩过不少。下面这几个是高频问题做个速查表搞HDMI 2.1调试的同行可以直接抄作业。4.1 黑屏、闪屏、间歇性失锁怎么定位是物理层还是链路层这是最常见的现象画面随机黑一下几百ms或闪一下。先不要急着怀疑是流控帧配置错了按以下顺序排查看接收端FEC_LOCKED状态如果FEC状态正常、错误计数是零或极低那问题可能在视频时钟恢复或者GPU时序不在FRL流控链路。看SCRAMBLER_LOCKED状态如果SCRAMBLER锁不住多半是PHY的符合同步出了问题常见原因是信号质量太差——线缆过长、转接头太多、PCB走线完成性差、电源纹波大。如果用示波器测量眼图注意FRL的高速信号眼图闭合会比TMDS更明显。HDMI 2.1的STQSource Test Quality对信号上升时间和抖动要求都很严。我见过一个案子同一个源端接三块不同sink板子只有一块闪屏后来发现是sink端PHY的RX均衡EQ参数没调对对特定频率衰减的补偿不够。如果上面都没问题再考虑链路层重训条件。有些SoC在检测到HDCP repeater状态变化时会强制重新训练表现为闪屏后能恢复但总是在HDCP握手时出现。这种就属于HDCP callback的时序问题不是FRL本身的锅。4.2 FEC错误计数持续增长但画面不闪是坏了还是正常FEC错误计数不是零才是“好的”。RS码本来就是为了容忍一定误码设计的所以计数有一点是很正常的。判断标准是增长速率。我习惯这样看正常稳定链路FEC错误计数一般几小时只增加几十个如果一分钟内增加几百上千说明物理链路处在边缘状态虽然暂时FEC纠还能兜住但系统的鲁棒性很差任何温度漂移、线缆微动都可能导致失锁。这种场景优先换线材测试然后检查连接器焊接、地回路、是否有外部干扰源。另一个容易忽略的FEC错误计数可能是sink端误报。硬件实现时如果RS译码器的输入时钟偶尔抖一下可能导致相邻数据被错算成一个坏符号但实际上物理层没有真正错误。所以我们调bug时不光看FEC count也要对照PHY层的raw bit error count。如果raw错误很少但FEC count很高优先怀疑SoC自身时钟或供电问题。4.3 车机/工业场景下的长线FRL流控问题工业显示、车载、KVM场景里用户特别喜欢用长线什么5米、10米、15米都敢接。FRL跑12Gbps时常规无源铜线超过3米就开始吃紧。我见过有人用2米的DVI线转HDMI 2.1去跑4K120结果怎么都点不亮训练一直失败。这种情况的核心问题不是流控帧不对而是物理层没给接收端足够的均衡机会。FRL训练时LTPS2/3阶段接收端会在一定范围内扫描EQ参数如果线缆衰减太大可能超出扫描范围导致信号质量检错训练失败。处理方向有这几个用合格的HDMI 2.1认证线缆印有Ultra High Speed HDMI Cable, 带QR码。加有源光缆AOC或者带redriver的信号中继器。在符合规范的前提下尝试降低每lane速率比如12Gbps降到8Gbps用4条lane跑总带宽32Gbps也能覆盖4K120或8K30。确保PCB端对端插损预算留足。很多商用主板上的HDMI接口都是从大芯片直接引出没有加保护/驱动长线压力下很容易翻车。实际测过一根标称“HDMI 2.1”但实际没有认证的线长度标着3米跑4Lane 8Gbps都勉强。后来还发现是里面有一根信号线的焊接点虚焊。这里提醒一句排查任何HDMI问题换线应该排在测试列表第一项劣质线材制造的问题比协议层问题多一个数量级。4.4 训练失败导致回退到TMDS模式很多HDMI 2.1显示器接老显卡时默认走TMDS模式。但如果你接的是HDMI 2.1信号源源端会自动尝试FRL训练失败后尝试多轮最终回退到TMDS。表现为能显示4K60但不能显示4K120/8K。这种情况特别容易和“显卡不支持”“线材不行”混淆。分辨方法在源端的显卡面板里看连接模式或者抓取EDID里HF-VSDB的FRL_Supported字段。如果HF-VSDB声明sink支持FRL但训练始终失败大概率是物理链路或PHY配置问题如果HF-VSDB根本不放FRL字段说明sink端固件没启用FRL能力只看line失败是无解的。我还见过一个EDA工具把FRL配置的寄存器数值写反了导致sink宣称最大速率12Gbps但实际PHY只有6Gbps能力。这种问题光看协议抓包看不到只能从寄存器层面排查真的是坑。5. 工具选型与设计避坑建议最后聊点实战层面的东西做HDMI 2.1产品时工具和测试方案怎么选设计上怎么减少流控相关的问题。5.1 常用工具协议分析仪、示波器、EDID工具调试FRL核心工具就三类协议分析仪泰克、是德、Keysight都有HDMI 2.1分析方案。主要用途是抓LTPS序列、FRL packetize过程、HDCP交互。预算有限的团队可以先用源端/接收端SoC的log模式不一定要马上买分析仪。示波器首推是德或者泰克的实时示波器带宽至少12GHz如果测12Gbps信号眼图对应的高压差分探头。测HDMI 2.1的STQ测试对带宽和固有抖动都有硬性要求低端示波器测出来的眼图不具备参考价值。不过如果是调试PHY EQ参数不需要做全协议一致性测试一台8GHz示波器也基本够用。EDID工具和HDMI信号源调试sink时一个可靠的HDMI 2.1信号源很关键最好支持多速率输出、强制FRL或TMDS切换、DSC开关。调试source时一台支持HDMI 2.1的显示器加上EDID模拟器可以自由定义sink能力验证源端在不同配置下的训练策略。EDID模拟器推荐带HF-VSDB编辑能力的否则没法模拟各种FRL参数组合。5.2 设计阶段如何减少FRL流控问题设计阶段提早做三件事可以避免很多bring-up期间的苦第一保证PHY参考时钟质量。FRL的serdes对参考时钟抖动非常敏感。用独立晶振或低抖动PLL不要把GPU核心电压域的时钟直接引来当refclk。参考时钟的抖动过大会出现训练偶尔成功、偶尔失败、FEC错误计数忽高忽低的症状看起来像链不稳定其实根源不在link。第二PCB走线做等长匹配。FRL的四条lane之间skew控制很关键。HDMI 2.1规范对lane-to-lane skew有明确要求如果layout不满足可能出现“3条lane lock成功1条lane始终锁不上”的现象。这在协议分析仪上看起来像训练阶段卡在LTPS4但实际根源在PCB物理层。第三留好调试接口。设计板子的时候至少把HDMI PHY的状态寄存器、FEC计数寄存器、中断脚引出到测试点或调试串口。量产后的返修机台很多时候就是看这几个寄存器定位的不然只能盲猜。5.3 一个容易被忽略的细节FRL训练超时时间FRL训练有一个总超时时间窗源端在这个窗口内如果没收到sink的确认就会放弃当前配置重新协商或回退到TMDS。这个时间粒度在协议里有规定但很多SoC的实现会把它做得比较保守比如窗口设置得较短导致一些慢速的sink芯片来不及响应。如果你在调试中偶尔看到训练失败但失败间隔没有规律尝试增加源端或sink端的训练超时容忍度。有些SoC的驱动里有一个“negotiation timeout”参数把它调大一点能解决一部分“时不时的黑闪”“唤醒时偶尔没输出”的毛病。这不是通过修改协议实现的是在驱动层放宽容限属于标准的工程优化手段。另外HPD信号处理也要留意当sink拉低HPD后重新拉高时源端通常会在重新读取EDID后触发一次完整重训。有些系统里HPD瞬间的电平抖动时长不足规范要求会导致源端误判触发意外重训表现为偶尔黑屏后立即恢复。可以在HPD网络加一个RC滤波时间常数按规范设定很多“偶尔闪一下”就是这么解决的。FRL流控的整个体系说穿了就是在没有独立时钟、没有重传机制的约束下如何把一条高速单向链路做得足够稳。理解了这一点再看LTPS、加扰、FEC、数据岛这些细节就容易串起来了。我这些年做HDMI相关产品最大的体会是遇到问题先别急着怀疑协议层从信号质量、线缆、电源、参考时钟这些物理基础上排查往往比死磕协议分析仪更高效。但如果物理层都干净那就得老老实实把流控帧的每个字段弄懂因为在这种链路上设计上的小疏忽最后都会以某种诡异的方式在训练过程中暴露出来。