企业官网建设流程全解析

1. 为什么我最终选择了Xilinx Video PHY Controller做混搭转换

先说结论：HDMI和DisplayPort虽然名字里都带个“视频接口”，但底层协议完全不是一回事。HDMI走的是TMDS（Transition Minimized Differential Signaling，最小化传输差分信号），而DisplayPort用的是基于包的微分组架构，主链路是带辅助通道的串行差分信号。你要是想把一个DisplayPort的显示器接到只有HDMI输出的设备上，或者反过来把HDMI信号源接到只有DisplayPort的显示器上，中间必须有协议转换，不能简单拿根线一插就完事。

在实际项目中，我遇到的需求比单纯的“转接头”复杂得多：一台设备需要同时支持HDMI和DisplayPort两种输出，但硬件上只有一个PHY通道，或者板卡面积/成本限制了只能布一种物理接口，却要在固件里同时实现对两种协议的兼容。这种情况下，靠传统的独立转换芯片（比如常见的HDMI转DP芯片）也能做，但问题在于：独立的转换芯片通常只支持固定方向的转换，而且灵活度很低，一旦协议版本升级或者需要兼容新的分辨率/刷新率组合，就得重新换芯片、改板子，非常被动。

Xilinx Video PHY Controller这个IP核则不同。它是Xilinx（现在的AMD Xilinx）针对UltraScale/UltraScale+系列FPGA提供的视频PHY层控制解决方案，底层基于GTH/GTY高速收发器。它能够在一个物理收发器上同时支持HDMI 2.0/1.4/1.3和DisplayPort 1.4/1.2/1.1等多种协议，而且切换协议不需要改硬件，只需要重新配置PHY层的参数并复位相关逻辑即可。

说白了，这套方案的核心价值就是：硬件不变，协议靠FPGA逻辑切换。 这种“一套硬件、多协议兼容”的架构，非常适合需要快速迭代、产品形态多样、对BOM成本敏感的场景。

这篇文章我会从Xilinx Video PHY Controller的架构原理讲起，再结合一个实际的HDMI转DisplayPort（以及反向）混合设计案例，把PHY层参数配置、协议切换的时序细节、常见坑点全部摊开讲清楚。适合正在做视频接口相关FPGA开发、或者准备评估Xilinx视频方案的工程师参考。如果你是刚接触这块的新人，我也会尽量把基础概念补齐，让你能跟上节奏。

2. Video PHY Controller到底是什么：架构与核心能力拆解

2.1 它的本质：把高速收发器封装成“可配置的视频PHY”

要理解Video PHY Controller，得先明白FPGA里高速收发器的角色。UltraScale+系列里的GTH/GTY收发器，本质上是支持从几百Mbps到几十Gbps的高速串行收发通道。它本身并不“认识”HDMI或DisplayPort协议，它只知道怎么完成串并转换、时钟恢复、均衡、加解扰这些底层物理层操作。而Video PHY Controller做的事情，就是把这些底层能力封装成一组针对视频协议定制的寄存器接口和控制逻辑，让上层的视频协议栈（比如Xilinx的HDMI 1.4/2.0 TX/RX IP、DP 1.4 TX/RX IP）可以直接调用，而不必直接跟收发器底层寄存器打交道。

用一个生活化的类比：GTH收发器就像一块还没有编程的万能芯片，什么都能做但需要用寄存器来告诉它怎么做；而Video PHY Controller相当于在它上面盖了一层“视频专用驱动程序”，你只要告诉它“现在要跑HDMI 2.0，4K@60Hz”，它就会自动把收发器的线路速率、时钟分频、预加重、接收均衡等参数调到合适的状态。

2.2 支持的协议和关键能力清单

根据官方文档（PG231），Video PHY Controller主要支持这几类协议模式：

• HDMI 2.0（最高18 Gbps，支持4K@60Hz 4:4:4/8bit，以及4:2:2/4:2:0）
• HDMI 1.4/1.3（最高10.2 Gbps，支持4K@30Hz）
• DisplayPort 1.4（最高每通道8.1 Gbps，HBR3模式，支持4K@120Hz或8K@60Hz）
• DisplayPort 1.2（最高每通道5.4 Gbps，HBR2模式，支持4K@60Hz）
• DisplayPort 1.1（最高每通道2.7 Gbps，HBR模式）

每个协议模式下，物理层需要关注的核心参数包括：

• 收发器参考时钟频率（常见的是27MHz的整数倍，因为HDMI的TMDS时钟基于27MHz的音频时钟体系，DP的链路速率也是27MHz派生的）
• 线路速率（Line Rate）
• 通道数量（HDMI固定为3个数据通道+1个时钟通道，DP则为1/2/4通道可选）
• 预加重和接收均衡系数（取决于PCB走线长度和信号质量）
• 极性翻转、差分摆幅等物理层参数

2.3 单PHY多协议切换的核心原理

混搭方案的关键在于：Video PHY Controller内部的收发器通道可以被重新映射和重新配置。以我使用的Xilinx KCU105开发板为例，板上有8个GTH收发器通道，逻辑上可以分成两组：一组给HDMI，一组给DP。但如果你的板子物理上只有一个HDMI连接器和一个DP连接器，且它们共用了同一组GTH通道——这就需要一个切换机制。

这个切换机制其实不复杂：在FPGA逻辑里，HDMI TX IP核和DP TX IP核共用同一个Video PHY Controller实例，通过一个GPIO或寄存器控制的“协议选择信号”，来决定当前实际驱动PHY的是哪套协议栈。切换时要做的事包括：

1. 把当前协议栈的TX/RX路径断开（把相关信号置为无效或复位）
2. 复位Video PHY Controller内部的收发器通道
3. 通过AXI4-Lite接口重新配置PHY层参数（线路速率、通道数、时钟分频等）
4. 重新初始化新的协议栈
5. 把新的协议栈的数据通路连接到PHY上

这个过程如果做成自动的，可以在几百毫秒内完成，对于开机时选择输出模式、或者热切换场景都足够快。但如果需要无缝切换（无黑屏），那就复杂了，需要额外的帧缓冲和仲裁逻辑，本文不展开。

3. 硬件设计层面的关键决策：共用PHY还是独立PHY

3.1 两种硬件拓扑的取舍

在开始写逻辑之前，硬件上得先想清楚：HDMI和DP的物理连接器是各自独立，还是共用同一组收发器通道。这两种方式带来的工作量天差地别。

• 独立PHY方式：HDMI用3个数据通道+1个时钟通道，DP用4个通道，总共至少需要8个GTH通道。优点是两种协议可以同时工作，互不影响；缺点是占用收发器资源多，而且大多数中低端FPGA（Artix-7、Kintex-7部分型号）的收发器数量有限，撑不起这种配置。
• 共用PHY方式：HDMI和DP共用同一组4个GTH通道（DP需要4个通道，HDMI只需要3个数据通道+1个时钟通道，所以4个通道够用），通过一个4选1或2选1的物理层切换开关来决定这4个收发器当前连接哪边的连接器。优点是省资源，缺点是同一时间只能输出一种协议，而且PCB布线需要特别注意差分对在不同连接器之间的走线分支和阻抗匹配。

我这次用的是共用PHY方式，因为目标设备是便携式视频转换盒，只需要单路输出，但需要兼容两种接口。4个GTH通道同时解决HDMI和DP，剩下的收发器资源还能留给其他功能。

3.2 PCB布线注意事项

共用PHY的差分走线分支是个坑，我踩过一次。因为GTH通道要同时接到HDMI连接器和DP连接器，PCB上就得从FPGA引脚先分出两条支路，分别连接到两个连接器。这就产生了一个阻抗不连续点，反射会严重影响信号完整性。

我的做法是：把GTH通道的差分对走线先走到一个靠近连接器区域的扇出点，然后从这个点尽量短地分叉到两个连接器。分叉点之后的走线越短越好，最好控制在5mm以内，同时通过增加AC耦合电容位置的一致性来减少匹配差异。另外，HDMI的TMDS时钟通道必须保持与其他数据通道的等长，否则会出现时序偏移。

如果你对信号质量要求更高，可以在分叉点附近放置0欧电阻或高速模拟开关（比如TI的TS3HDMI101这种专门做HDMI信号切换的芯片），用开关来选择当前信号走哪条支路，这样能彻底消除未选中支路的反射影响。不过这会增加BOM成本和PCB面积，需根据具体项目权衡。

3.3 参考时钟的分配策略

Video PHY Controller的GT参考时钟（GTREFCLK）要求精度和抖动都要满足协议规范。HDMI和DP的参考时钟体系虽然都以27MHz为基础，但具体倍频关系不同：

• HDMI 2.0的TMDS时钟范围从25MHz到600MHz，但PHY内部的串行器实际上是把TMDS时钟乘以10作为线路速率（例如HDMI 2.0 6Gbps模式，TMDS时钟600MHz，线路速率6Gbps）
• DP 1.4的链路速率是1.62/2.7/5.4/8.1Gbps，参考时钟通常是27MHz或100MHz，通过收发器内部的PLL锁相到目标速率

因此，如果你的硬件上只有一个晶振提供参考时钟，建议选择100MHz有源晶振，因为它在较高线路速率下的抖动性能更容易满足要求，而且DP HBR3模式通常用100MHz或者135MHz作为参考时钟。HDMI的PHY配置则需要通过QPLL或者CPLL把100MHz参考时钟倍频到所需的TMDS时钟频率。

我在设计中用了两个独立的参考时钟：一个100MHz给DP相关PHY，一个148.5MHz给HDMI相关PHY（因为4K@60Hz的TMDS时钟就是594MHz，而594MHz是148.5MHz的4倍，这样PLL倍频关系更简单）。但共用PHY时，两个参考时钟无法同时接入同一组GTH通道（GTH的QPLL只能选一个参考时钟源），所以最终方案是：用100MHz作为唯一参考时钟，HDMI所需的PLL倍频关系由Video PHY Controller内部的配置自动处理，实测稳定。

4. Vivado工程的搭建与IP配置细节

4.1 Video PHY Controller IP的配置参数详解

在Vivado中，Video PHY Controller的IP配置界面有几个关键参数需要仔细核对，否则后面调试会很痛苦。

• Protocol：选择你实际支持的协议。如果是混搭，需要在IP里同时勾选HDMI 2.0和DisplayPort 1.4协议。
• Line Rate：这个值决定了收发器的串行速率。HDMI 2.0模式下，最大线路速率是6Gbps（3个数据通道）；DP 1.4模式下，最大线路速率是8.1Gbps（4个通道）。但你不用为了支持8.1Gbps就全局设置成8.1Gbps，可以按实际分辨率需求配置。比如只需要4K@60Hz，HDMI用5.94Gbps即可，DP用HBR2（5.4Gbps）即可。
• Reference Clock：我选的是100MHz，因为DP HBR3要求参考时钟频率在100MHz到135MHz之间。如果你只做HDMI，也可以用148.5MHz。
• TX/RX usage：如果你的设备既要输入又要输出，需要分别勾选TX和RX路径。我这个转换器是单方向协议转换（HDMI信号源转DP输出），所以只用了TX路径，但Video PHY Controller的某些版本要求TX和RX都必须配置，你要留意版本差异。
• Number of Lanes：DP模式下可选1/2/4通道。为了兼容性好，我选了4通道，HDMI模式会自动只用3个数据通道+1个时钟通道。

下面是一个我在实际工程中使用的关键配置参考（基于Vivado 2022.2和PG231）：

注意：这些参数不是随便填的，必须和后续HDMI TX IP、DP TX IP中的参数保持一致，否则PHY层会报出线路速率不匹配的错误。

4.2 多协议IP的连接关系与共享逻辑

混搭的工程中，关键点在于：HDMI TX IP和DP TX IP虽然输出视频数据流的方式不同，但它们都通过Video PHY Controller提供的同一个物理通道发数据。具体的连接逻辑是：

1. HDMI TX IP把像素数据、音视频辅助数据编码成TMDS格式，并产生一个平行的“PHY接口信号”（包括tx_datain、tx_clk等）。
2. DP TX IP把像素流打包成DP微分组，产生另一个平行的“PHY接口信号”（包括tx_datain、tx_ctrl等）。
3. 在顶层模块里，根据协议选择信号，用MUX（多路选择器）把其中一个协议栈的PHY接口信号连接到Video PHY Controller的输入端口。

这个MUX不能随便用普通的组合逻辑，因为Video PHY Controller的输入端口是高速并行数据总线（频率在几十到几百MHz），直接用LUT做MUX会带来极大的时序风险。正确做法是使用FPGA内部的寄存器切片（Register Slice）或者专门的高速数据选择器IP。我个人习惯用Xilinx的axis_switch IP（仅用于并行数据通路），但更简洁的方式是把协议选择信号直接送到Video PHY Controller的“Protocol Select”端口，让它自己去处理内部的通道映射。

但这里有个坑：Video PHY Controller的协议切换（protocol switching）并不是所有版本都支持的。你要仔细看PG231里有没有关于“protocol switching”的描述。如果IP版本不支持，你必须在外部用逻辑实现复位和重配置流程，不能只靠一个切换信号就完成协议变更。我用的2022.2版本是支持动态协议切换的，但在切换前仍需进行完整的复位和重锁，否则收发器的PLL不会重新锁定到新的速率。

4.3 复位和初始化流程的硬性要求

这下到了最容易出问题的环节：复位时序。Video PHY Controller对复位顺序极其敏感，如果时序不对，GT通道经常会停在PLL未锁定或者弹性缓冲溢出/下溢的状态。

标准的复位流程应该是：

1. 确保所有参考时钟稳定，并将GTREFCLK接入GTH的QPLL。
2. 把Video PHY Controller的全部复位信号拉高至少16个时钟周期。
3. 等待QPLL_LOCK信号拉高，同时等待GTTXRESET/SET的状态变为复位完成。
4. 释放复位，等待PHY的txresetdone信号变高。
5. 此时才能启动HDMI或DP的协议栈IP，并把视频时钟切换到PHY的txclk上。

我在这步上吃过亏：当时图省事，把PHY复位和协议栈复位直接用同一个复位信号控制，结果每次上电有50%概率HDMI无输出，最终排查发现是GTH的TIEOUT引脚被错误配置，导致复位时GT参考时钟没有正确传递。后来严格按照Xilinx提供的复位时序配置，问题就消失了。

提示：如果你用AMD/Xilinx的HDMI或DP示例工程，建议直接用其生成的复位逻辑，别自己另写一套。这些示例工程经过大量验证，时序逻辑比你自己从头造的稳得多。

5. 实操过程：从HDMI转DP到DP转HDMI的完整流程

5.1 第一步：最小系统验证HDMI TX通路

我先不急着做混搭，而是先把HDMI TX通路调通，确认PHY层工作正常。使用Video PHY Controller + HDMI 1.4/2.0 TX IP的示例工程，在KCU105板上用HDMI线连接一块4K显示器，输出测试彩条。如果这个能通过，说明参考时钟、PHY配置、PCB走线都没问题。

具体输出参数我设置的是：1920x1080@60Hz，TMDS时钟148.5MHz，线路速率1.485Gbps。这个低速率模式最适合初步调试，即使信号质量有问题也容易通过显示器测试。

一旦彩条正常，我再用Video PHY Controller的“Scan”功能（Vivado的IBERT工具也能做）检查眼图。这里分享一个指标参考：HDMI 2.0的眼图余量通常要求超过0.2UI才算可靠，DP HBR2的余量要求则略宽松一些。如果眼图余量不足，优先调整TX预加重和差分电压摆幅，从默认值往上加一档试试。

5.2 第二步：单独验证DP TX通路

DP的调试比HDMI难一点，因为DP的AUX通道（辅助通道）也参与链路训练，如果AUX通信失败，显示器会一直没有任何响应。所以调试DP时，我通常先在SDK里跑一个小程序，通过AXI4-Lite接口直接访问Video PHY Controller的寄存器，检查DP PHY层的状态：

• 链路层是否检测到显示器（HPD信号）
• AUX通道是否有响应（读取DPCD寄存器0x00000，值为0x00表示DPCD版本1.0，0x03表示1.3等）
• 链路训练的最终结果是否成功（读取DPCD的0x00200和0x00201）

如果AUX能通但训练失败，大概率是线路速率不匹配或者通道数配置错误。我碰到过一次DP只有2通道能用，因为PCB上另外两条通道的走线太长了，导致信号衰减过大，高速率下训练失败。这就是为什么DP的通道数和信号完整性检查一定要提前做，不能等到了系统联调才发现。

5.3 第三步：实现HDMI→DP单向转换

当HDMI TX和DP TX都单独验证通过后，就可以把HDMI RX（接收外部HDMI信号源）和DP TX（输出到DP显示器）连接在一起，做一个纯HDMI到DP的转换器。这其实不涉及Video PHY Controller的混搭切换，只要你把HDMI RX的像素输出直接接到DP TX的像素输入，同时把音频数据从HDMI RX的Audio接口桥接到DP TX的Audio接口即可。

这个阶段的主要工作量在像素时钟的跨时钟域处理：HDMI RX输出的像素时钟（比如4K@60Hz的594MHz）和DP TX内部使用的像素时钟不一定同源，需要用帧缓冲或者FIFO来同步。如果分辨率较低（1080p），可以直接用一个简单的异步FIFO做缓冲，但分辨率高了之后，建议用Video Frame Buffer（VPSS）做一个完整的帧管理，避免FIFO溢出或者套用不正确的时序。

5.4 第四步：加入协议选择逻辑，变成混搭方案

混搭的关键就是那个“协议选择信号”。我设计里用一个全局寄存器（通过GPIO接口控制一个LED按键）来切换，按下就切到DP输出，再按就切到HDMI输出。

切换逻辑的伪码如下：

// 顶层模块中的协议选择 always @(posedge sys_clk) begin if (btn_debounced) begin protocol_sel <= ~protocol_sel; // 0: HDMI, 1: DP phy_reset = 1'b1; // 拉高PHY复位 // 等待 >16 cycles // 重新配置Video PHY Controller的协议寄存器 // 释放复位 // 启动对应的协议栈 end end

实际实现时，协议选择信号要同时驱动三个地方：

1. Video PHY Controller的控制寄存器（通过AXI4-Lite接口写入）
2. HDMI TX/DP TX IP的复位和使能逻辑
3. 输出连接器方向的ESD保护和阻抗切换开关

这里要注意的是，切换过程带黑屏和几毫秒到几百毫秒的延时是正常的，但如果你的产品要求无感知切换，那单PHY方案做不到，得加一个视频帧缓冲和输出仲裁器，但这就不是Video PHY Controller本身能解决的问题了。

5.5 实测数据：不同分辨率下的切换效果

我在实际测试中，用下面这套环境验证了混搭输出的稳定性和切换效果：

• FPGA：Xilinx UltraScale+ KCU105
• 输入：HDMI 2.0信号源（用一台Player播放4K测试视频）
• 输出1：HDMI 2.0显示器
• 输出2：DP 1.2显示器
• 视频格式：4K@60Hz 4:2:0，1080p@120Hz，以及4K@30Hz

黑屏时间的大部分开销来自两处：一是PHY的PLL重新锁定时间（大约需要100-200us，可忽略），二是协议栈重新初始化并等待显示器重新握手的时间（HDMI无独立握手协议，靠的是源端检测HPD和接收端EDID，相对快；DP需要完整的链路训练，如果训练不通过还要重试，耗时较长）。

如果你要优化黑屏时间，最有效的做法是：不要把Video PHY Controller的PLL彻底复位，而是保留PLL锁定在一个中间频率（比如2.7Gbps），切换时只改变参数，不重新锁相。但这不是所有系列都支持，需查手册。

6. 常见问题与排查技巧实录

6.1 HDMI输出无信号的十大排查路径

排查顺序比排查手段更重要。我按经验列出优先度从高到低的排查路径：

首先查HPD引脚状态。HDMI源端设备必须检测到接收端的HPD信号拉高，才会启动TMDS信号输出。这个引脚是输出端（RX端）的5V供电通过一个上拉/下拉结构实现的。很多自制的HDMI转接板上HPD悬空，导致源端永远认为没有接显示器。

其次是EDID读取。HDMI源端通过DDC（I2C）读取接收端的EDID，以确认支持的分辨率和音频格式。如果EDID没有正确连接到RX端的EEPROM里，或者I2C总线上有设备地址冲突，源端会退回到最低分辨率（通常是640x480或720p），甚至直接无输出。我在调HDMI时，始终在RX的I2C线上挂一个逻辑分析仪，看EDID的读取请求是否正常应答。

然后是TMDS时钟检测。如果源端输出但FPGA的RX PHY没有检测到有效的TMDS时钟，说明差分线连接有问题，或者RX端的终端电阻配置不对。用示波器测差分对，确认是否有掉电状态或共模电压异常。

最后才轮到FPGA内部逻辑检查。我见过很多新手的工程里，HDMI TX IP的复位一直没释放，但看起来好像处理了，因为时序图上没拉高复位信号。实际上Xilinx的HDMI IP复位是高有效还是低有效，具体要看版本和配置，别想当然。

6.2 DP链路训练失败的经典原因

DP的链路训练失败，几乎是调DP最常见也最让新手抓狂的问题。链路训练的失败往往没有直观的错误指示，除非你去读DPCD寄存器，否则你只看到显示器黑屏。

链路训练失败可以从几个方向排查：

• AUX通道异常：用逻辑分析仪抓AUX总线事务，如果物理层根本没有响应，那可能是AUX的差分信号极性反了，或者AUX通道在PCB上走线有问题。另外AUX的共模电压范围要求在0V到3.3V之间，超出范围会导致DP接收端无法解析AUX信号。
• 链路速率协商失败：源端和接收端分别支持的最高速率不一样，或者源端在读取DPCD后发现自己配置不了HBR2，就会降级到HBR或者是RBR。如果PHY层本身没有配置HBR2对应的时钟，协商就会失败。
• 通道数不匹配：接收端可能只支持2通道或1通道，但源端坚持4通道，就会训练失败。处理方式是让DP TX IP自动根据接收端能力选择通道数，不要把通道数写死。

排查链路训练问题时，我常用的手段是在SDK里写一个回环测试程序，让PHY层的TX直接发PRBS（伪随机码），RX接收并比对。这样能快速判断物理层是否正常，并把问题隔离到协议栈层。

6.3 一个典型的PCIe干扰导致HDMI画面闪烁案例

有一次调好的HDMI输出在播放视频时偶尔出现横向噪声条纹，我开始以为是FPGA内部的像素时钟抖动，后来发现是PCB布局问题：HDMI TMDS时钟线旁边走了一条PCIe时钟线，PCIe时钟的3.3V展频噪声耦合到了TMDS时钟上，产生了近端串扰。

解决办法是：把HDMI差分对和PCIe时钟线之间的间距从8mil加到25mil，同时把HDMI的时钟对和相邻数据对之间的间距也拉开，并在地层上做屏蔽。改版之后，横纹闪烁问题彻底消失。

这个案例想说明的是：混搭方案虽然逻辑上稳定，但物理层上如果FPGA引脚分配和PCB走线没有做好隔离，信号完整性问题会直接让你怀疑人生。建议在布局阶段就预留好差分对间距，避免后期改板。

6.4 热插拔导致的PHY锁死问题

Video PHY Controller在热插拔场景下有一个已知的容易出问题的点：HDMI或DP连接器插入瞬间，由于静电放电和瞬态电压冲击，可能导致GTH收发器的某些寄存器被意外改写，进而导致PLL失锁或者链路进入错误状态。

规避方法：

1. 在连接器端加入TVS管，尽量靠近连接器放置。
2. 在FPGA逻辑里，检测到HPD（或DP的HPD）拉高后，执行一次完整的PHY复位和重新初始化，而不是依赖硬件自动恢复。
3. 如果热插拔频率很高，建议在控制层加入一个“链路监控”机制：定期读取PHY的状态寄存器，如果发现锁定丢失或错误标志置位，就自动触发重新初始化。

这个机制我后来写在了固件里，运行了一个多月没再出现过锁死问题。

6.5 Vivado中常见的Video PHY Controller配置报错汇总

编译时最常见的报错大概有下面几种，我把典型的错误信息和处理方式整理成表：

遇到这类报错，不要盲目瞎改，最有效的做法是打开PG231中“Clock and Data Rate”那一节的表格，把参考时钟、线路速率、通道数和协议版本逐项填进去，检查是否能搭配。绝大多数报错都能在这个表格中找到答案。

6.6 动态切换时PLL重锁失败的解决记录

我之前在实现动态协议切换时，碰到一个罕见的问题：切换后GTH的QPLL有时无法重新锁定到新的线路速率。每次切换，QPLL_LOCK信号一直为低，导致协议栈初始化卡住。

排查发现，原因是VIDEO PHY Controller在切换协议时需要先释放QPLL的复位，但复位释放时机和协议配置写入的先后关系不对。在一个测试轮次里，我是在写协议配置之前释放了复位，这会导致QPLL在上一次速率上短暂锁定，然后再跑到新速率上去重新锁定。如果刚好遇到极端的温度变化，就会超过锁定的重试次数上限，导致锁死。

我的解决办法是：在切换协议之前，先把QPLL复位拉高，等参考时钟稳定后，先写协议配置，再释放QPLL复位。这个顺序在Xilinx官方文档里其实也有说明，但确实容易忽略。

7. 混搭方案的性能优化与扩展思路

7.1 降低视频延迟的取舍

如果你做的是视频转换器产品，延迟是很重要的指标。HDMI转DP的延迟主要来自视频像素数据的跨时钟域处理和缓冲。我测试过，直接用FIFO做缓冲，延迟在1-2行扫描时间内（1080p约10-20微秒）；如果用了帧缓冲（VPSS），延迟会增加到几毫秒至几十毫秒，取决于缓冲几帧。

大部分游戏或视频播放场景不敏感，但如果是做KVM（键盘/显示器/鼠标切换器）或者视频矩阵，延迟就要严格控制。建议在满足时序要求的前提下，能用FIFO就不上帧缓冲，能用两行就绝不用一帧。

7.2 支持更大分辨率的带宽评估

用Video PHY Controller做混搭时，通道数的上限由GTH/GTY收发器数量和引脚绑定决定。以KU115为例，有128个GTH通道，但并非所有通道都能同时跑最高速率，还要受限于功耗和散热。所以做8K@60Hz输出时，需要评估热预算，必要时加装散热片或者降低FPGA的IO电压。

如果你要支持HDMI 2.1（最高48Gbps，TMDS时钟1200MHz），Video PHY Controller本身不支持，需要改用GTY收发器搭配HBR3/8.1Gbps，同时外接TMDS重定时器芯片。要根据实际需求选型，别指望一个IP解决所有时代的问题。

7.3 音频通道的桥接处理

HDMI和DP都支持音频传输，但通道布局和容器格式差异很大。HDMI的音频数据与视频数据一起在TMDS通道传输，支持LPCM最高8通道/192kHz，而DP把音频数据打包成辅助数据包，默认支持最多8通道音频。

混搭方案里，HDMI RX提取出的音频数据需要重新打包成DP音频包（或者反过来）。这需要用到Xilinx的Audio Formatter IP来做I2S到DP音频格式的桥接。我实测中，直接用HDMI RX的I2S输出接DP TX的I2S输入是不行的，因为HDMI的音频时钟并非由I2S_LRCK频率直接映射到DP的音频时钟，必须经过一个音频时钟转换（Audio Clock Regeneration）。否则会出现声音变调或断音。

7.4 扩展到双向转换的可行性

如果你的终态目标是“一个接口既能HDMI输入又能DP输出，或者DP输入HDMI输出”，也就是双向转换器，Video PHY Controller也是支持的，但复杂度会大幅上升。核心问题是：TX和RX的物理通道需要在同一组GTH上复用，但HDMI RX需要3个数据+1个时钟的RX通道，HDMI TX需要3个数据+1个时钟的TX通道，DP RX/TX各自需要4个通道，总共至少4个收发器通道但每个通道的收发方向必须能独立配置。

在实际工程里，我推荐采用两个独立的Video PHY Controller，分别管TX和RX，这样协议切换和复位管理会更清晰。如果非要共用，务必确认GTH收发器支持双工模式，并且你的FPGA引脚分配满足同时连接的信号方向需求。

8. 工具链和调试建议

8.1 Vivado版本与IP版本选择

建议使用Vivado 2020.1以上版本。新版对Video PHY Controller的编译和仿真支持更完善，而且对GTH的仿真模型（对信号完整性分析）也有改进。2022.1之后，AMD/ Xilinx把Video PHY Controller更新到了一个新的命名空间，但底层变化不大，兼容性没问题。

如果项目已用了旧版本，除非有必需的新特性，否则我不建议为了一个IP升级整个工具链。因为升级带来的IP核版本冲突、时序收敛重写，成本往往超过收益。

8.2 调试环境搭建技巧

调试视频PHY层，必备工具有三样：示波器（至少2GHz带宽，用于测高速差分信号）、逻辑分析仪（至少支持AUX通道的I2C解码）和眼图仪（或支持眼图测量的示波器）。如果没有眼图仪，也可以用Xilinx IBERT工具，直接在Vivado硬件管理器里看眼图。

调试时一定要先在Vivado里启用IBERT的example design，把GTH通道的TX/RX都配置成回环模式，验证物理层是否可用。只有回环通了，你才能放心地往上叠协议栈。不要把协议栈问题当成物理层问题去解决，那会在错误的坑里浪费大量时间。

8.3 仿真与实测结合验证

Video PHY Controller的仿真模型在Vivado的IP仿真库里就有，但跑一次完整的HDMI转DP仿真，往往需要几百万个时钟周期，仿真时间很长。建议只做关键场景的仿真：链路训练过程、协议切换过程、以及热插拔事件，不仿真长时间视频流。这样既能验证控制逻辑，又不会让仿真跑几天。

实测时，我习惯先接一个最简单的显示器（比如1080p的普通显示器），跑通了再升级到4K高刷显示器，因为高分辨率显示器的链路训练协议更复杂，调试起来也更难。

9. 最后再分享点实践心得

我在这个项目里最大的体感是：别把Video PHY Controller当成一个“黑盒IP”来用，它本质上是一组高速收发器的控制封装。你得对GTH/GTY的底层行为有基本认知，比如PLL锁定原理、复位时序、弹性缓冲机制，否则遇到问题会非常被动。很多看起来是IP的bug，最后都是底层收发器配置或者PCB信号完整性的问题。

另外，如果你要量产，务必在硬件层留出足够的调试接口：在FPGA到HDMI/DP连接器之间放上可以切断的0欧电阻，在AUX通道上引出测试点，甚至在PCB上留出差分探针的焊盘。这些设计在样机阶段几乎不增加成本，但对调试效率和信号测试帮助巨大。

至于混搭方案本身，说实话，它更像是一个硬件复用策略而不是魔法。当你手里只有一组GTH通道，却能同时覆盖HDMI和DP两种接口需求时，整个板卡的面积、成本和功耗都会有显著改善。如果你也在规划类似的多协议视频接口产品，我希望这篇文章能帮你避开我踩过的那些坑。遇到Video PHY配置或者切换逻辑上的具体问题，欢迎在评论区留言，我们一起探讨。