企业官网建设流程全解析

去年做的一个项目，需求听起来有点拧巴：专业视频源只给了DisplayPort输出，后端的采集设备却只认HDMI输入。甲方还要求插上就亮，不能用外置转接头，因为转接头要么延迟感人，要么在长时间跑批时直接黑屏。和这种HDMI与DisplayPort混搭的需求打交道多了你就会发现，视频接口转换这件事，靠物理转接头只是治标，真正干净的做法是在FPGA里做一个多协议视频接口转换桥。而要用FPGA同时驾驭这两种高速串行视频协议，Xilinx Video PHY Controller基本是绕不开的一环。这篇文章就把我实际调通HDMI和DP互转的方案、踩过的坑、以及那些文档里很少明说的经验一次性讲清楚，适合正在做视频接口桥接、FPGA图像采集或显示驱动的工程师参考。

1. 为什么非要折腾HDMI与DP混搭：需求场景与方案全貌

1.1 从实际项目说起：DP信号进、HDMI信号出的尴尬

先说个真实场景。我们当时给一台医疗设备做视频采集板卡，前端是某品牌的工业相机，只有DisplayPort输出，主控板上的图像处理芯片却只有HDMI输入接口。甲方一开始想省事，直接用一根MiniDP转HDMI的线，结果图像是出来了，但颜色偶尔偏绿，隔一段时间还会花一帧。拆开转接线看了下，里面就是一个很被动的电平转换芯片，对时钟和信号的恢复能力极差，稍微有点线损就暴露了。

后来换成了FPGA方案，思路变成：在板子上把DP信号收进来，FPGA内部做协议解析和时序重建，再从HDMI TX接口发出去。这样一来，DP转HDMI不再是“物理上把引脚掰过去”，而是真正做了一次协议层的转换。反向需求也有，比如一些老的HDMI切换台要接进DP接口的监视器，就得做HDMI转DP。还有更常见的场景是高速视频采集卡既要支持HDMI输入又要支持DP输入，希望同一块板卡能自动识别接口协议，而不是准备两套板卡。

这些需求放到一起，本质就是一句话：让同一套硬件和逻辑同时兼容HDMI、DisplayPort两种协议，并且能按需切换方向。FPGA天然适合干这个，因为它有可重配置的高速收发器，也就是GT Transceiver，再加上Xilinx Video PHY Controller这套底层配置IP，就能把物理层的差异屏蔽掉，把精力集中在协议转换逻辑上。

1.2 Video PHY Controller在多协议方案中的角色

很多第一次接触Video PHY Controller的同学容易有一个误解：以为这个IP本身就能实现HDMI转DP。其实不是。Video PHY Controller在Xilinx这套体系里的定位是高速收发器的物理层配置和状态管理模块，它管的是GT的差分收发、时钟恢复、通道绑定、加解扰这些底层事，而上层的HDMI/DP协议解析、AUX/DDC通道通信、视频时序打包，都需要额外的协议IP或者自己写逻辑。

可以把Video PHY Controller理解成一个“万能插座适配器”。插座本身不关心你插的是HDMI插头还是DP插头，它只负责把电引进来、把地和屏蔽处理好。但真正决定“电”变成“画面”的，是插头那边的设备和后端用电器之间的沟通协议。

在Xilinx生态里，DisplayPort IP和HDMI IP内部都会实例化一个Video PHY Controller。如果你只是做一个单一协议的接法，直接调这两个IP就够了，不用手动碰Video PHY Controller。但一旦要做HDMI与DP混搭，也就是同一个板卡可能一会儿跑DP输入、一会儿跑HDMI输入，或者同时跑DP RX和HDMI TX，我会推荐把Video PHY Controller单独拉出来，用“External PHY”模式让协议IP和物理层解耦，这样换协议时只需要重新配置PHY，协议IP和上层数据通路能保持稳定。

1.3 方案架构总览：物理层、链路层、协议转换层

完整的视频接口转换方案，我会习惯性拆成三层来看：

• 物理层：由GT Transceiver加Video PHY Controller组成，负责把板子上的差分串行信号变成并行数据，同时做时钟恢复、通道对齐和纠错。
• 链路层：对于DP来说就是Link Training、AUX通道管理、MST/SST拓扑；对于HDMI 2.1 FRL来说也有类似的Training机制；HDMI 2.0及以下的TMDS模式则主要处理TMDS字符对齐。
• 协议转换层：在FPGA逻辑或嵌入式处理器里完成视频流从DP的“包格式”到HDMI的“流格式”转换，包括像素格式重映射、时序参数计算、音频元数据抽取和注入。

最常见的数据通路是DP RX到HDMI TX，也就是把一路DisplayPort输入变成HDMI输出。此时DP RX链路层负责和上游显卡做Link Training，训练完成后拿到视频流，经过一个FIFO做时钟域转换，再到HDMI TX侧按照HDMI时序重新打包发送。反向HDMI转DP同理，只是HDMI侧没有复杂的Link Training，DP侧要和下游显示器完成训练。

下表是我常用的一种混搭组合参考：

这个表格看着简单，真正落地时每个格子背后都是一整套IP组合和调试工具链。我自己做过最折腾的选项就是第一行的DP RX转HDMI TX，因为要把DP的eDP/HBR3高带宽收下来，再按HDMI的TMDS或FRL发出去，两个协议之间的时钟域和像素格式差异，需要花大功夫去对。

2. Video PHY Controller的协议适配机制与工程选择

2.1 GT Transceiver是如何同时兼容HDMI和DP的

GT Transceiver本身是一个通用的高速串行收发器，它的发送器和接收器都支持从几百Mbps到十几Gbps的线速率。DisplayPort和HDMI在物理层上的共同点是：都是用交流耦合的差分对传数据，每对线上都有清晰的时钟恢复机制。区别主要在于通道数量和编码方式。

DisplayPort用1/2/4根主链路lane传输数据，每根lane都跑同样的线速率，HBR2是5.4Gbps，HBR3是8.1Gbps。链路训练时会先通过AUX通道读取对端能力，然后广播到所有lane上，用相同的速率和对齐方式传数据。GT Transceiver的通道绑定功能正好可以处理多lane对齐，Video PHY Controller会根据DP IP训练出来的参数，把GT设置到对应的速率和编码模式。

HDMI则要分两种情况。传统HDMI 2.0及以下用的是TMDS编码，3根数据lane加一根像素时钟lane，每根数据lane跑10bit编码后的串行数据，速率等于像素时钟乘以10。GT Transceiver处理这种模式时，通常把三根数据lane当作三个独立的串行通道，时钟lane则单独处理，或者利用某种方式把时钟信息嵌进去。HDMI 2.1则引入了FRL模式，完全抛弃了TMDS，变成3或4根lane、每根lane跑3/6/8/10/12Gbps的对称串行链路，并且有类似DP的Training机制。这时候Xilinx Video PHY Controller就更有用武之地了，因为FRL和DP在物理特性上靠得更近。

2.2 IP配置要点：连线速率、通道数、参考时钟

配置Video PHY Controller时，最核心的几项是协议选择、lane数量、目标线速率和参考时钟来源。官方手册里这些参数都有，但工程里最容易出问题的就是参考时钟和速率档位的搭配。

以一个DP RX转HDMI TX的方案为例，DP侧如果是DisplayPort 1.4的HBR3，4 lane，每lane 8.1Gbps，那Video PHY Controller给GT用的参考时钟通常是135MHz，因为8.1Gbps正好是135MHz乘以60，GT内部的PLL可以锁定到这个整数倍关系。HDMI侧如果做4K60 4:4:4的HDMI 2.0 TMDS输出，像素时钟594MHz，TMDS串行速率是5.94Gbps，那么TX侧的参考时钟推荐值是148.5MHz或者594MHz除以某个系数。同一个Video PHY Controller管理两个方向时，就要特别小心两边的QPLL是否冲突，因为一个QPLL只能锁定在一个频带上。

我建议把两边的参考时钟分开走，用独立的差分晶振或者可编程时钟芯片供给，避免共用一个PLL导致切换协议时重新锁定时间太长。协议切换时间在实际产品里很关键，如果PLL锁定要几百毫秒，用户会明显感觉到黑屏时间太长。选时钟芯片时，我比较常用SI5338或LMK系列，能动态调频，配合FPGA配置在初始化时把频率切到目标值。

2.3 不同器件家族的差异与选型建议

Xilinx的Video PHY Controller在不同器件家族上支持能力不一样。老的7系列里，GTX和GTH都能跑HDMI和DP，但DP 1.4 HBR3的8.1Gbps对GTX来说比较吃力，最好用Kintex-7和Virtex-7的GTH；UltraScale+系列里GTH和GTY都是主力，GTH可以覆盖到16Gbps以上，跑DP 1.4 FRL都够用。Zynq UltraScale+的优势是FPGA逻辑旁边还带ARM核，可以直接在上面跑Linux和DP协议栈，省掉外部主控。

做实际选型时，我一般会从三个维度考虑：线速率余量、逻辑资源、还有外部接口数量。如果只是做一路DP转HDMI，Artix-7 UltraScale+级别的器件就够。如果要做四路混搭，比如同时处理两路DP输入和两路HDMI输出，那GT数量、GT位置、还有参考时钟输入的分布就变得很关键。很多板卡最后被迫选更贵的封装，不是因为逻辑不够，而是因为GT通道在封装上不够，或差分对分配导致布线困难。

还有一点容易被忽略：Video PHY Controller对Transceiver的复位时序要求很严格。官方IP会生成一套复位逻辑，如果你在图里同时例化了多个Video PHY Controller，要注意它们共享的gt_rxresetfsm等信号不能随意拼接。我在多个项目里都遇到过链路间歇性断开，最后发现是复位信号的异步释放顺序不对。所以选型时也要考虑IP的复位管理，尽量让协议IP自己管理PHY的复位，不要用自己拍脑袋写的复位状态机去强行覆盖。

3. 动手实现HDMI转DP与DP转HDMI的完整流程

3.1 创建Video PHY IP并配置物理层参数

在Vivado里做这套方案，我通常推荐直接用IP Integrator，而不是纯HDL，因为IPI里能直观看到DisplayPort IP、HDMI IP和Video PHY Controller之间的连接关系。如果确实想纯代码控制，也可以，但需要手动把AXI4-Lite配置端口和状态端口连好，工作量会大不少。

先创建一个Video PHY Controller IP。在IP Catalog里搜video_phy_controller，双击后先选择Protocol。这里要注意，这个IP的Protocol选项有DisplayPort、HDMI、SATA、PCIe等，选DisplayPort还是HDMI取决于当前物理通道用在哪一侧。我的建议是：在混搭方案里，为每个方向单独例化一个Video PHY Controller，这样DP RX侧配成DisplayPort模式，HDMI TX侧配成HDMI模式，逻辑清晰，也不容易把配置搞混。

典型的Vivado TCL命令大致是这样：

create_ip -name video_phy_controller -vendor xilinx.com -library ip -version 2.2 -module_name vphy_dp_rx set_property -dict [list \ CONFIG.C_Protocol {DisplayPort} \ CONFIG.C_LanEs {4} \ CONFIG.C_RefClkFreq {135} \ CONFIG.C_LineRate {8.1} \ ] [get_ips vphy_dp_rx]

然后配置另一侧的Video PHY Controller为HDMI模式，注意HDMI TMDS模式的通道和时钟通道分配。HDMI 2.0 TMDS是3 lanes data + 1 lane clock，Video PHY内部会把GT的两个channel配对使用。如果是HDMI 2.1 FRL，则是3或4 lanes，和DP很像。下表总结了常用配置组合：

配置完后，生成IP，然后检查example design。Video PHY Controller的example design里通常有GT loopback测试和眼图扫描逻辑，非常推荐先跑一遍，确认物理层稳定后再接上层协议IP。

3.2 连接GT参考时钟和约束

IP配置完，真正让FPGA跑到硬件上，还需要把GT的参考时钟引脚、收发差分引脚和板卡原理图对好。这里最容易犯的错误是只关注数据集，忘了约束参考时钟。GT参考时钟通常从专用引脚进来，经过IBUFDS_GTE4缓冲后给到QPLL或CPLL。在做约束时，除了要约束PACKAGE_PIN，还要把参考时钟创建成primary clock，否则工具可能推断出不确定的时钟域。

一个基本约束范例如下：

set_property PACKAGE_PIN AD4 [get_ports refclk_p] set_property PACKAGE_PIN AD5 [get_ports refclk_n] set_property IOSTANDARD LVDS [get_ports refclk_p] set_property IOSTANDARD LVDS [get_ports refclk_n] create_clock -name refclk -period 7.407 [get_ports refclk_p]

上面period按135MHz算，是7.407ns。如果是148.5MHz，则是6.734ns。这个值一定不能写错，写错了后面时序分析全是垃圾。

约束做完后，还要把GT通道的引脚约束一并写好，比如gt_rxp、gt_rxn、gt_txp、gt_txn。这些引脚在器件封装上有固定位置，可以通过Vivado的Device视图查看，也可以从示例工程的XDC里抄。实际项目中，GT引脚往往由原理图工程师和PCB工程师先定好，FPGA工程师要做的就是确保IP的lane分配和实际连接顺序一致。尤其要注意，GT的lane顺序不一定和协议IP的lane顺序一一对应，可能需要在IP配置里做“lane mapping”反转。

3.3 例化协议IP并实现转换逻辑

物理层准备好后，就轮到DisplayPort IP和HDMI IP。DP IP有RX和TX两种模式，HDMI IP也同理。在混搭方案里，我们通常把DP IP配置为RX，把HDMI IP配置为TX，中间通过Video Stream接口连接。

在IPI里你会看到类似这样的连接：DP RX IP的video out接到一个AXI4-Stream FIFO，再接到HDMI TX IP的video in。音频和辅助数据通道分开走，但也要做好跨时钟域处理。DP RX IP输出的视频流是带AXI4-Stream sideband信号的，里面包含了行场同步、数据使能、像素数据。HDMI TX IP输入也是类似的协议，但两者在像素格式上可能有差异，比如DP RX出来的是RGB 8bpc，而HDMI TX IP期待的是YUV422或RGB，这时中间就得加一个像素格式转换模块。

我一般会在中间加一个颜色空间转换和时序生成模块。比如DP RX输出的时序是自由运行的，需要根据HDMI TX的像素时钟要求重新打拍；HDMI TX对blank周期、HPD信号时序有严格要求，不能直接把DP信号硬塞进去。最稳妥的做法是先用一个异步FIFO做缓冲，FIFO深度至少能容纳两行数据，避免行切换时因为带宽波动产生撕裂。

音频部分的转换也容易踩坑。DP的音频是通过secondary data packet传的，HDMI则通过audio infoframe和audio sample packet传。如果只是传视频，很多工程直接忽略音频。但真实项目中常有音频需求，比如视频会议终端。此时需要用到Xilinx的Audio/Video IP或者自己解析DP音频包、再封装成HDMI音频格式。这个工作量不容小觑，建议把它纳入项目排期，不要只当“加个IP”就完了。

3.4 生成example design与硬件在环调试

第一次接触这套IP组合时，强烈建议不要直接上自己的顶层，先把DP IP和HDMI IP自带的example design跑起来。每个Xilinx视频IP的example design里都有一套完整的测试平台和连接约束，能让你在板子上看到彩条输出，或者通过IBERT测GT眼图。先跑通example design，再逐步替换成自己的数据通路，排查问题会容易得多。

硬件在环时，我习惯先用IBERT IP在GT回环模式下测试物理层误码率。把DP TX和DP RX用一根短环回线连上，或者GT内部做near-end PCS loopback，看误码率是否为零。确认无误后，再接外部设备做端到端测试。如果外部设备无输出，先用逻辑分析仪抓AUX/DDC通道，确认Link Training是否完成、EDID是否读到了。这套顺序我至今都认为是最快的定位方法。

4. 接口信号定义、电路设计与PCB布局的踩坑记录

4.1 HDMI接口信号定义和DP接口信号定义速查

做FPGA调试时，手上最好有一张接口信号对照表，省得每次翻规范。HDMI接口最常用的是TYPE-A，19 pin，关键信号包括：

• TMDS Data2+/2-、Data1+/1-、Data0+/0-：三组数据差分对
• TMDS Clock+/Clock-：像素时钟差分对
• CEC：消费电子控制
• DDC SCL/SDA：I2C通道，用于读EDID
• HPD：热插拔检测
• 5V Power：源端给Sink供电

DisplayPort接口常用的是标准DP和MiniDP，关键信号包括：

• Main Link Lane0~Lane3 +/-：主链路差分对
• AUX CH +/-
• HPD
• DP_PWR：可以从Source输出电源给Sink

HDMI和DP在物理上的相似点是都有HPD和DDC/AUX通道，区别在于DP的辅助通道是差分对，而HDMI的DDC是普通I2C单端信号。做混搭板卡时，这两套信号不能直接短接，必须经过协议IP或者电平转换芯片。很多人直接把DP的AUX接到HDMI的DDC上，结果两边都傻眼。

4.2 电路设计中最容易出问题的几个点

先讲AC耦合电容。DP主链路要求每根lane在Source侧放置AC耦合电容，典型值是0.1uF或0.22uF。HDMI TMDS模式通常是不需要AC耦合的，但HDMI 2.1 FRL模式又需要AC耦合。所以做混搭板卡时，最稳的做法是每一路高速线都预留AC耦合电容位置，根据协议选择贴不贴。我在一个项目里为了节省空间，把DP和HDMI的高速线复用到同一对GT引脚，然后通过模拟开关切换，结果告诉我很痛苦：高速模拟开关的带宽和回波损耗在这个速率下很难做好，最后被迫改成两套独立通道，只共享参考时钟。所以如果你不需要协议切换时共用物理接口，就别硬省。

然后是HPD和5V。HDMI的HPD是Sink端用一个上拉电阻到5V，Source检测这个引脚的电平来判断连接状态。DP的HPD则是一个低电平有效的中断线，DP Source通过检测HPD脉冲来触发Link Training。混搭板卡中，如果DP RX和HDMI RX使用不同的HPD策略，必须分别在电路里处理好，不能共用一个电阻网络。

还有一个很经典的坑：HDMI的DDC通道和DP的AUX通道都是用来读EDID的，但电气特性和协议完全不同。Xilinx的DP IP内部自带AUX控制器，会通过Video PHY Controller配置GT的sideband通道来收发AUX数据。HDMI IP则通过其DDC接口访问外部I2C，通常需要外接I2C缓冲器。一个比较容易忽略的点是，HDMI DDC上需要有上拉电阻，很多FPGA开发板没有默认贴上，导致读不到显示器EDID，进而Link Training失败、黑屏无声。我在调试时第一反应都是先量DDC的SCL/SDA波形。

4.3 关于MiniDP转HDMI和无输出问题的排查思路

热词里出现了“ThinkPad X1 Carbon Gen8 HDMI无输出”和“minidp转hdmi”，这两个和我们的FPGA调试场景其实关系很近。很多FPGA板卡验收时会被客户拿笔记本接HDMI测试，笔记本HDMI无输出，第一反应是板卡有问题。但实际情况里，有相当一部分是笔记本端DisplayPort源固件和HDMI转接芯片兼容性差导致的。NVIDIA当年出过DisplayPort Firmware Updater，就是因为部分显卡在连接某些高分辨率DP显示器时黑屏，需要更新DP固件才能解决。在FPGA测试环境中，如果DP源端固件版本有问题，FPGA侧DP RX会一直在Link Training失败，这时候怎么改FPGA逻辑都没用，必须先让源端更新固件。

MiniDP转HDMI转接头也有同样问题。很多转接头只是简单把MiniDP引脚拉出来，没有做协议转换，遇到纯DP的FPGA板卡自然不行。有的转接头虽然能做转换，但HPD时序处理粗糙，会导致显示器和源端互相认为对方没插好。所以我建议在FPGA混搭项目验收阶段，准备至少两台不同厂商的DP源设备和HDMI显示器，排除单一设备兼容性问题。

另外还要说下RK3576这类SoC平台HDMI适配和Xilinx方案的联系。热词里有“rk3576 android14插上hdmi线后就没媒体声音”，这类问题在Xilinx FPGA里也会有，只是表现不同。SoC适配HDMI时，PHY配置、音频时钟恢复、infoframe格式都是常见坑；FPGA里做HDMI TX时，如果音频时钟没有被正确映射到HDMI的N/CTS参数上，可能出现“视频正常但音频没有”或者“音频延迟越来越大”的现象。排查思路是一致的：先用示波器看TMDS通道的数据包，确认Audio infoframe和Audio sample packet是否正确发出，再检查音频采样率与像素时钟的比值是否合理。

5. 协议转换中的软件与固件配合：从Link Training到Firmware

5.1 为什么要关注DisplayPort Firmware Updater

很多硬件工程师看到软件工程师跑来说“需要更新一下DisplayPort固件”时，第一反应是不耐烦。但做DP相关项目多了，你会慢慢意识到，DP这条链路的稳定性不只是硬件物理层决定的，还严重依赖源端和Sink端的固件配合。NVIDIA DisplayPort Firmware Updater就是一个典型工具，它解决的是部分显卡在输出DP信号时，因固件中Link Training参数不对导致黑屏、闪屏、无法唤醒的问题。

在FPGA方案里，如果你的DP RX IP作为Sink连接了某些显卡，遇到链路训练不稳定，不要只查自己的GT和PHY配置，也可以先看看显卡、笔记本是否有新的DP固件更新。尤其像ThinkPad这类笔记本，HDMI输出口经常内部走的是DP信号再转换成HDMI，显卡固件和转换芯片固件都可能影响输出。我曾经调试一块板卡，DP RX始终训练不到HBR3，降级到HBR2才稳定。查了很久，最后发现是源端固件的限制，而不是FPGA侧问题。所以我把这条经验放在前面：先确认源端能力，再折腾自己的PHY。

5.2 Link Training与视频时序重映射的软件流程

DP的Link Training分成两个阶段：Clock Recovery和Channel Equalization。Video PHY Controller会通过GT的CDR状态上报接收端是否锁定了发送端时钟，DP IP在此基础上完成AUX通道的配置写入。FPGA里的软件，也就是MicroBlaze或Zynq ARM核上跑的程序，主要负责控制状态机，读取DP IP的状态寄存器，然后根据下游HDMI TX的EDID信息决定输出分辨率。

一个常见工程误区是：把DP Sink的EDID直接写死成4K60，然后把HDMI TX的输出也设成4K60，却忽略了源端显卡可能因为某种原因只训练到了HBR2，带宽不够传4K60。此时需要软件动态降低输出分辨率或者色彩深度。比如检测到DP链路带宽不足时，把HDMI TX从4K60 4:4:4降为4K60 4:2:0，或者降到1440p。这种动态协商在FPGA方案里完全可行，但要在软件上做一套“能力协商”逻辑。

整条链路的时序转换，可以看成一个FIFO的读写信誉问题。DP RX侧输出的像素时钟由DP链路恢复出来，HDMI TX侧则由本地参考时钟生成。两侧频率不可能完全一致，所以必须做帧率转换，最常用的是frame buffer或pixel FIFO。软件上要监测FIFO的水位，如果持续偏高，就微调HDMI TX的像素时钟或者丢帧策略。我在实现时使用了一个可编程的PLL芯片作为HDMI TX时钟源，软件根据FIFO水位微调PLL频率，实际跑下来画面非常稳定，没有撕裂。

5.3 从RK3576适配HDMI看多平台共性问题

之前在另一个项目里调试过RK3576平台的HDMI输出，遇到的问题和Xilinx FPGA方案高度类似。RK3576跑Android 14，插上HDMI线后图像正常但媒体声音没了，这个问题表面上是audio policy配置错误，但深挖下去，是HDMI PHY的音频时钟恢复没有正确使能。Android系统的AudioFlinger检测不到HDMI sink支持音频，或者Audio InfoFrame里没有正确设置音频格式，自然就没有声音。

拿这个经验反观Xilinx方案，HDMI TX IP的音频配置也要格外注意。Xilinx HDMI IP可以通过AXI4-Lite接口配置audio infoframe，如果忘了使能音频会话，或者N/CTS的值不对，HDMI sink端可能直接不开声音。调试时最好用HDMI分析仪看数据包，而不是只靠显示器喇叭判断。RK3576适配HDMI时还有一个常见问题是热插拔检测和HDCP key烧写，这两个坑在FPGA方案里也会出现。做商用量产项目时，HDCP可能绕不过去，一旦开启HDCP，PHY的稳定性和密钥存储都会成为新的风险点。

从这些不同平台的经验来看，无论你用Xilinx Video PHY Controller还是RK3576内置HDMI PHY，都要优先保证物理层的可靠连接，再谈协议层的音视频数据，最后才是上层软件的行为。很多人一上来就抓软件问题，往往走偏。

6. 实测验证、性能分析与经验总结

6.1 用常见分辨率和色深验证转换链路

调通之后，不要急着测一堆高规格参数，先把最常规的分辨率矩阵跑一遍，确保每个档位都稳定。我自己的测试矩阵通常是这样：

跑矩阵时，每一档至少连续播放10分钟测试视频，同时切换画面场景，观察是否有花屏、黑闪、撕裂。重点测试HPD热插拔：在播放中拔掉DP线再插回去，看FPGA侧能否自动重新Link Training并恢复显示。几乎每个项目都会在热插拔上出问题，所以这个测试不能省略。

音频验证同样重要。可以用HDMI分析仪抓取Audio InfoFrame和Audio Sample Packet，确认声道数、采样率、封装格式正确。如果只靠显示器听声音，很多细节是听不出来的。

6.2 信号完整性测试和眼图观察

视频接口转换项目做到最后，瓶颈往往在物理层信号完整性。Video PHY Controller配置对了，协议栈也正常了，但板子一跑高速就容易误码，这时候就要回到眼图测试。Xilinx的IBERT IP可以很方便地观察GT收发眼的张开程度。正常情况下，DP 8.1Gbps的眼高应该有几百mV，眼宽至少0.4UI；如果眼图糊成一团，就要检查阻抗匹配、AC耦合电容、连接器质量、PCB走线过孔数量。

我的实际经验是：DP和HDMI的差分对走线最好做到等长，误差控制在5mil以内，过孔尽量少。层叠上要和参考地平面连续，不要在高速线下方掏空地层。有一块板子刚开始DP RX跑HBR2没问题，HBR3就报误码，后来查PCB发现有一根lane多打了一个过孔，导致阻抗突变，去掉过孔后问题消失。这类问题用逻辑分析仪是查不出来的，只能靠信号完整性测试。

如果板卡已经定型，没法改PCB，可以尝试在GT的RX端调整均衡器参数。Video PHY Controller通过AXI4-Lite可以调整RX均衡器的boost档位和DFE参数。把这部分做成软件可调，在量产时针对不同线缆长度做一次自动校准，能显著提高兼容性。这也是为什么我推荐把Video PHY Controller独立出来的原因——物理层参数调整不应该混在协议IP内部，否则协议升级时很难维护。

6.3 个人经验和后续扩展

最后说几点我做这类多协议视频项目的个人心得。

一是不要把Video PHY Controller当成一个“黑盒IP”拿过来就用。一定要花时间看它的example design和仿真波形，理解GT复位状态机、QPLL/CPLL选择逻辑、以及lane对齐的触发条件。很多疑难问题都出在时序细节上，比如RXCDR锁定信号和协议IP使能之间的先后关系。二是多准备几个版本的Vivado，同一个IP在不同工具版本下的默认配置可能有差异，升级工具链后要重新跑一遍仿真。之前遇到过Vivado从2020.1升到2022.2后，DP IP的Link Training行为变化，导致老固件不兼容。

后续如果要扩展，可以考虑用Versal的硬核视频处理模块或者集成HDMI/DP硬核的MPSoC，能大大减少GT资源和逻辑占用。但在那之前，用Xilinx Video PHY Controller先把物理层吃透，绝对不亏。这套混搭方案做熟练之后，无论来的是HDMI转DP、DP转HDMI，还是四路视频矩阵，底层思路都是一样的：物理层用Video PHY Controller管好，协议层用IP管好，应用层用软件管好。把这三点抓住，视频接口的混搭问题就解决了一大半。