企业官网建设流程全解析

1. 为什么SGMII在7系列FPGA上不是“开箱即用”，而是个需要亲手调教的精密仪器

你拿到一块Xilinx 7系列开发板，比如KC705或VC707，上面标着“支持千兆以太网”，心里想着：“Vivado里拖个IP核，点几下生成比特流，插上网线就能ping通了吧？”——我第一次也是这么想的。结果是：IP核能生成，综合能通过，实现也能跑完，但一上电，PHY芯片没反应，示波器上看GTX TX差分对根本没波形，或者勉强有波形，但MAC层收不到任何帧，rx_bad_frame计数器一路狂涨。折腾三天后才明白，SGMII在7系列FPGA上根本不是“配置好IP就能用”的功能模块，而是一套需要你亲手校准、反复验证、甚至要对着PHY芯片手册逐字比对的物理层精密协同系统。

核心原因在于：SGMII（Serial Gigabit Media Independent Interface）本身是个非标准协议。它既不是IEEE 802.3定义的正式物理层（如1000BASE-X），也不是纯粹的逻辑接口（如GMII）。它本质上是把GMII的8位并行数据+控制信号，用8b/10b编码后，塞进一条1.25Gbps的串行链路里，再通过GTX收发器传输。这个“塞”的过程，涉及时钟域转换、相位对齐、极性翻转、直流平衡、以及最关键的——与外部PHY芯片的电气与协议握手。Vivado里的SGMII IP核（通常是通过Gigabit Ethernet PCS/PMA or SGMII IP生成）只负责GTX侧的编码/解码和基本状态机，它不负责也不知晓你接的是Marvell 88E1111、TI DP83867还是Realtek RTL8211F，更不会自动适配不同PHY的复位时序、引脚极性、时钟延迟要求。这些，全得你来填。

这就解释了为什么网络上搜“vivado sgmii”出来的帖子，90%都在问“为什么RX_LOCK一直不拉高”、“为什么TX没有输出”、“为什么PHY寄存器读出来全是0”。因为问题不出在代码逻辑，而出在物理连接的每一个毫米级细节：GTX参考时钟的抖动是否超标？PCB走线长度匹配误差是否超过50ps？PHY的RESET_N信号释放时机是否比GTXGTRESET晚了200ns？TX_DISABLE引脚是高有效还是低有效？这些参数，Vivado IP核的GUI里一个都找不到，它们藏在PHY芯片的Datasheet第37页的Timing Diagram里，藏在你画的PCB Layout的Length Tuning Report里，也藏在你用示波器测出的REFCLK与TXOUTCLK的相位差里。

所以，“手把手教你配置”，本质是教你如何成为一个FPGA-PHY联合调试工程师。你需要同时理解GTX收发器的底层机制（PLL、QPLL、CPLL、RX/TX Buffer、Alignment Marker）、SGMII协议的编码规则（D/K字符、IDLE、/K28.5/）、以及PHY芯片的初始化流程（MDIO寄存器配置、自协商状态机）。这不是一个“点击生成”的任务，而是一个三重交叉验证的过程：逻辑仿真验证编码正确性，硬件实测验证电气信号完整性，系统联调验证协议握手可靠性。接下来，我们就从最基础、也最容易被忽略的第一步开始——环境与约束的准备。

2. Vivado工程创建与约束文件：那些被默认设置悄悄埋下的雷

很多人以为Vivado工程创建就是选个器件型号、点个“Create Project”，然后直接去IP Catalog里拖IP。这恰恰是踩坑的第一步。7系列FPGA的GTX收发器对时钟和I/O约束极其敏感，一个错误的create_clock命令，或者一行缺失的set_input_delay，就足以让整个SGMII链路在实现阶段（Implementation）就失败，或者更糟——实现成功，但上电后行为完全不可预测。

2.1 器件选择与工程模板的致命陷阱

首先，务必确认你的目标器件型号。7系列中，只有Artix-7、Kintex-7、Virtex-7支持GTX（GTP/GTX/GTH），而Spartan-7和Zynq-7000系列（除Zynq UltraScale+外）不支持GTX，它们用的是GTP，其SGMII实现方式完全不同。如果你误选了XC7S50（Spartan-7），却按Kintex-7的教程配置GTX，Vivado会报错[Common 17-55] 'get_cells' could not find cells matching...，因为根本不存在GTX原语。正确的做法是：打开Vivado，新建工程，在“Default Part”页面，不要凭记忆输入型号，而是点击“Browse”按钮，在弹出的器件库中，展开“7 Series FPGAs”，然后根据你的开发板手册，精确找到对应的Part Number，例如KC705是xc7k325tffg676-2，VC707是xc7vx485tffg1157-2。选错器件，后续所有工作都是空中楼阁。

其次，工程类型必须选“RTL Project”，绝对不要选“IP Catalog Project”或“Block Design Project”作为起点。原因很简单：Block Design（BD）虽然图形化方便，但它会自动生成大量隐藏的约束和时钟网络，对于SGMII这种需要精细控制时钟域的场景，这些自动生成的约束往往是冲突的根源。我曾遇到一个案例：BD里自动生成的clk_wiz_0IP，其输出时钟被Vivado错误地分配给了GTX的TXUSRCLK2，导致TX侧时钟域混乱，TXRESETDONE永远不置位。而RTL Project则让你从一张白纸开始，所有约束都由你亲手书写，可控性极高。

2.2 约束文件（XDC）：SGMII的生命线

SGMII的约束文件，绝不是简单地把引脚名映射到FPGA管脚号。它是一份物理层协议的法律文书，规定了信号何时有效、持续多久、相对于哪个时钟边沿采样。一份合格的SGMII XDC文件，必须包含以下四个核心部分：

第一，参考时钟（REFCLK）约束。这是最关键的一环。SGMII要求一个125MHz的差分参考时钟输入到GTX的GTREFCLK引脚。这个时钟的抖动（Jitter）必须小于1.5ps RMS，否则GTX PLL无法锁定。在XDC中，你不能只写：

create_clock -name refclk_p -period 8.0 -waveform {0 4} [get_ports {refclk_p}] create_clock -name refclk_n -period 8.0 -waveform {0 4} [get_ports {refclk_n}]

这只会告诉Vivado有一个8ns周期的时钟，但没告诉它这是GTX的参考源。正确写法是：

# 创建差分时钟，并指定为GTX参考时钟 create_clock -name refclk -period 8.0 -waveform {0 4} [get_ports {refclk_p}] # 将refclk_p/refclk_n绑定到具体的GTX Bank set_property PACKAGE_PIN H17 [get_ports {refclk_p}] set_property PACKAGE_PIN H16 [get_ports {refclk_n}] set_property IOSTANDARD DIFF_SSTL15 [get_ports {refclk_p refclk_n}] # 关键！将此时钟关联到GTX的GTREFCLK端口 set_property REFCLK_FREQUENCY 125.0 [get_cells {inst/gtxe2_channel_inst}]

其中inst/gtxe2_channel_inst是你在RTL中例化的GTX原语的实例名，必须与实际一致。漏掉REFCLK_FREQUENCY属性，Vivado在综合时会用默认值（通常是100MHz），导致GTX内部PLL配置错误。

第二，TX/RX差分对约束。SGMII使用一对差分线（如txp/txn,rxp/rxn）承载1.25Gbps数据。它们必须放在同一个GTX Bank内，并且Bank电压必须是1.0V（GTX要求）。在XDC中，不仅要指定管脚，还要强制Vivado进行长度匹配（Length Matching）：

# TX差分对 set_property PACKAGE_PIN AB14 [get_ports {txp}] set_property PACKAGE_PIN AB13 [get_ports {txn}] set_property IOSTANDARD DIFF_SSTL15 [get_ports {txp txn}] # RX差分对 set_property PACKAGE_PIN AC14 [get_ports {rxp}] set_property PACKAGE_PIN AC13 [get_ports {rxn}] set_property IOSTANDARD DIFF_SSTL15 [get_ports {rxp rxn}] # 强制长度匹配，误差<50ps（约对应3mm PCB走线） set_property DIFF_TERM_ADV TERM_100 [get_ports {txp txn rxp rxn}]

DIFF_TERM_ADV TERM_100启用了片内100欧姆终端电阻，这是GTX差分信号稳定传输的物理基础。没有它，信号反射会导致眼图闭合，RX_LOSS_OF_SIGNAL报警频发。

第三，用户时钟（USRCLK）约束。GTX内部有两个关键用户时钟：TXUSRCLK（驱动TX侧逻辑）和RXUSRCLK（驱动RX侧逻辑）。它们必须由GTX内部的PLL生成，且频率严格为125MHz。你不能用外部时钟源直接驱动它们。在XDC中，你需要约束这两个时钟的输出：

# 约束TXUSRCLK，它是GTX内部生成的，需从GTX原语的输出端口获取 create_clock -name txusrclk -period 8.0 -waveform {0 4} [get_pins {inst/gtxe2_channel_inst/TXUSRCLK}] # 同理约束RXUSRCLK create_clock -name rxusrclk -period 8.0 -waveform {0 4} [get_pins {inst/gtxe2_channel_inst/RXUSRCLK}]

注意，这里[get_pins {...}]的路径必须与你RTL中GTX实例的端口名完全一致。Vivado会自动识别这是由GTX生成的时钟，并在时序分析中将其视为衍生时钟。

第四，复位与控制信号约束。SGMII的TX_RESET和RX_RESET信号，必须满足GTX的复位时序要求：在GTRESET拉高后，至少等待GTRESET_TIME（通常为10us）才能释放TX/RX_RESET。这个时序不能靠Verilog里的#10000来模拟，必须用硬件电路（如RC延时电路）或专用复位IC来保证。在XDC中，你需要为这些信号添加输入/输出延迟约束：

# 对于来自PHY的RX_LOSS_OF_SIGNAL信号（输入） set_input_delay -clock rxusrclk -max 2.0 [get_ports {rx_loss_of_signal}] set_input_delay -clock rxusrclk -min 0.5 [get_ports {rx_loss_of_signal}] # 对于送往PHY的TX_DISABLE信号（输出） set_output_delay -clock txusrclk -max 3.0 [get_ports {tx_disable}] set_output_delay -clock txusrclk -min 0.8 [get_ports {tx_disable}]

这些数值（2.0ns, 0.5ns等）必须从PHY芯片的Datasheet中查找其Setup Time和Hold Time，然后根据你的PCB走线延迟进行修正。网上随便抄来的“-max 5.0”是无效的，它只会掩盖真正的时序问题。

提示：一个经验法则——所有与GTX相关的约束，都必须在XDC文件中显式声明。Vivado的“Auto Constraint”功能对高速串行接口完全不可靠，它生成的约束往往与物理事实相悖，是导致“实现变红”（Implementation Failed）的头号元凶。

3. GTX原语例化与SGMII IP核集成：从黑盒到透明的深度拆解

Vivado提供了两种方式来使用GTX：一种是直接例化底层原语GTXE2_CHANNEL，另一种是使用封装好的IP核（如“Gigabit Ethernet PCS/PMA or SGMII”）。很多新手会本能地选择后者，认为“IP核更简单”。但我的经验是：对于SGMII调试，必须从原语例化开始。IP核是一个高度封装的黑盒，它内部做了大量自动配置，当你遇到RX_NOT_LOCKED时，你根本不知道是RXBUFRESET没拉对，还是RXSYNCALL没触发，抑或是RXDISPERR计数器溢出了。而原语例化，则像给你一把手术刀，让你能精准地切开每一层，观察每一个信号。

3.1 GTXE2_CHANNEL原语：七个必须理解的核心端口

GTXE2_CHANNEL是7系列GTX收发器的最小功能单元。它的端口繁多，但真正决定SGMII成败的，只有以下七个：

其中，TXDATA和RXDATA的宽度是理解SGMII编码的关键。GTX原语默认工作在20-bit模式，这意味着它每周期接收/发送20位并行数据。SGMII协议将GMII的8位数据（TXD[7:0]）和3位控制（TX_EN,TX_ER,COL）打包成一个11位的“字节”，再通过8b/10b编码器变成10位，最后拼成20位总线。因此，在你的顶层RTL中，TXDATA的赋值逻辑必须是：

// GMII TX侧逻辑 always @(posedge txusrclk) begin if (tx_reset) begin txdata <= 20'h0; end else begin // 高4位：控制信号（TX_EN=1, TX_ER=0, COL=0） // 低16位：8b/10b编码后的数据（每个字节编码为2个10位码） txdata[19:16] <= {tx_en, tx_er, col, 1'b0}; // 4-bit control txdata[15:0] <= encoded_data; // 16-bit encoded data end end

而RXDATA的解析则相反：先从RXDATA[15:0]中提取两个10位码，解码成一个8位数据和一个控制位，再组合成GMII的RXD[7:0]和RX_DV。

3.2 SGMII IP核的“真相”：它只是原语的自动化包装

当你在Vivado IP Catalog中搜索“SGMII”，找到“Gigabit Ethernet PCS/PMA or SGMII”IP核时，它实际上是一个TCL脚本生成的、基于GTXE2_CHANNEL的封装。它内部已经为你完成了8b/10b编解码、弹性缓冲（Elastic Buffer）、时钟补偿（Clock Compensation）等复杂逻辑。它的优势是省去了手动编写编解码器的麻烦；劣势是，它把所有调试信息都封装在了IP核内部。

例如，IP核有一个关键参数叫TX_BUFFER_MODE，它决定了TX侧是否启用弹性缓冲。如果设为AUTO，IP核会根据TXUSRCLK和TXOUTCLK的相位差自动调整缓冲区深度。但如果你的PCB设计导致这两个时钟相位差过大（>10ns），AUTO模式就会失效，TX_BUFFER_OVERFLOW信号会被置位，TX数据流中断。而这个信号，在IP核的GUI界面里是不可见的，你只能在生成的IP核源代码里，找到gtxe2_channel_inst实例下的TX_BUFFER_OVERFLOW端口，然后手动将其引出到顶层，再用ILA（Integrated Logic Analyzer）抓取。

因此，我的建议是：先用原语例化跑通一个最简SGMII回环（Loopback），即把TXDATA直接连到RXDATA，绕过PHY，验证GTX本身的功能。一旦TXRESETDONE和RXRESETDONE都拉高，TXPHASEALIGN完成，RXSTATUS[2]（即RX_ALIGN_DONE）置位，说明GTX链路物理层已通。然后再将这个已验证的GTX原语，作为“黑盒”接入SGMII IP核，替换掉IP核内部的GTX实例。这样，你就拥有了一个“半定制”的IP核：既有IP核的便利性，又有原语的可调试性。

3.3 8b/10b编解码器：SGMII的“语言翻译官”

SGMII协议的核心，就是8b/10b编码。它把8位的数据字节（0x00-0xFF）和3位的控制字节（如/K28.5/表示帧起始），映射成10位的符号（Symbol），目的是保证传输线上直流平衡（0和1数量大致相等）和足够的跳变沿（便于时钟恢复）。这个过程，就是GTX的PCS（Physical Coding Sublayer）层的工作。

Vivado的SGMII IP核内置了8b/10b编解码器，但它的行为是固定的。例如，当TXDATA[19:16]为4'b0001时，IP核会自动插入/K28.5/控制字符。但如果你的MAC逻辑发送了一个非法的控制组合（如4'b1111），IP核会静默丢弃该字节，导致帧丢失，而你却看不到任何错误标志。

为了彻底掌控，我推荐在顶层RTL中，自己实现一个轻量级的8b/10b编码器。它只有几十行代码，却能让你在仿真中100%确定发送出去的每一个符号：

// 简化的8b/10b编码器（仅示意，完整版需查表） module sgmii_encoder ( input logic [7:0] din, input logic [3:0] ctrl, output logic [9:0] encoded ); always_comb begin case (ctrl) 4'b0000: encoded = encode_data(din); // 数据字节 4'b0001: encoded = 10'b0011110101; // /K28.5/ 4'b0010: encoded = 10'b1100001010; // /K28.1/ default: encoded = 10'b1001010100; // /K28.7/ endcase end endmodule

然后，将这个编码器的输出，直接驱动GTXE2_CHANNEL的TXDATA端口。这样，你在仿真波形里，就能清晰地看到/K28.5/、/K28.1/、/K28.7/这些控制字符是如何被插入到数据流中的，从而在硬件调试时，能快速判断问题是出在MAC逻辑（发送了错误的ctrl），还是出在GTX物理层（TXDATA没被正确采样）。

注意：自己写编码器的前提，是你已经完全理解了8b/10b的编码规则。Xilinx官方文档UG476《7 Series FPGAs GTX/GTH Transceivers User Guide》的Chapter 4详细列出了所有D字符和K字符的编码表。不要依赖网上的二手资料，必须以UG476为准。

4. PHY芯片协同与MDIO配置：让FPGA和PHY“说同一种话”

完成了FPGA侧的GTX配置，只是完成了50%的工作。剩下的50%，是让FPGA与外部PHY芯片建立可靠的通信。SGMII的“S”代表“Serial”，但它背后依然是一个完整的以太网物理层，需要PHY芯片来完成最终的电信号驱动（如将1.25Gbps的差分信号转换为RJ45网口的1000BASE-T信号）。而FPGA与PHY之间的“对话”，是通过一个名为MDIO（Management Data Input/Output）的两线串行总线来完成的。这个总线，就是FPGA和PHY的“普通话”。

4.1 MDIO总线：一根线上的“外交谈判”

MDIO总线由两根信号线组成：MDC（Management Data Clock）和MDIO（Management Data I/O）。MDC是由FPGA（MAC）产生的时钟，频率通常为2.5MHz（最大可达25MHz），用于同步数据传输。MDIO是一根双向、开漏（Open-Drain）的信号线，FPGA和PHY都可以驱动它，但必须通过一个上拉电阻（通常为4.7kΩ）连接到3.3V电源。

MDIO协议定义了一种标准的寄存器访问格式，称为Clause 22。每一次读写操作，都由一个32位的“管理帧”（Management Frame）构成：

[Start] [OP] [PHY Address] [Register Address] [Turnaround] [Data] 2-bit 2-bit 5-bit 5-bit 2-bit 16-bit

其中，Start固定为01，OP为操作码（00=写，01=读），PHY Address是PHY芯片的地址（通常为0x00或0x01，由PHY的ADDR引脚电平决定），Register Address是要访问的寄存器地址（如0x00是控制寄存器，0x01是状态寄存器），Turnaround是两个高阻态比特，用于让PHY从接收模式切换到发送模式，Data是16位的数据。

这个协议看似简单，但实操中充满了陷阱。最常见的问题是：PHY芯片的MDC引脚，对时钟上升沿和下降沿的采样要求不同。有些PHY（如Marvell 88E1111）要求在MDC的上升沿采样MDIO数据，而另一些（如TI DP83867）则要求在下降沿。如果你的FPGA MDIO控制器默认在上升沿采样，而PHY却在下降沿采样，那么你发送的所有命令都会被PHY当作乱码，PHY Status Register（地址0x01）读回来永远是0x0000，仿佛PHY根本不存在。

4.2 FPGA侧MDIO控制器：一个“慢工出细活”的模块

由于MDIO是低速总线（2.5MHz），你完全可以用纯逻辑（Pure Logic）来实现一个MDIO控制器，而不需要复杂的IP核。一个健壮的MDIO控制器，必须包含以下三个核心状态机：

1. 总线仲裁状态机（Bus Arbitration FSM）：因为MDIO是双向线，FPGA在发送数据时，必须确保PHY处于高阻态；而在读取数据时，又必须在Turnaround期间释放总线，让PHY能驱动MDIO。这个状态机负责在MDC的每个周期，精确地控制MDIO的三态（1'bz）、输出（1'b0）和输入（1'b1）模式。

2. 帧生成状态机（Frame Generation FSM）：它负责将一个32位的管理帧，按照严格的时序，一位一位地发送出去。关键点在于：Start字段（01）必须在MDC的第一个上升沿之前就准备好，OP字段必须在第二个上升沿采样，以此类推。任何一位的延迟，都会导致整个帧被PHY丢弃。

3. 错误检测与重试状态机（Error Detection & Retry FSM）：MDIO总线极易受噪声干扰。一个常见的错误是，PHY在Turnaround期间未能及时驱动MDIO，导致FPGA读到一个无效的16'hFFFF。此时，控制器不应立即报错，而应启动一个重试计数器（Retry Counter），最多重试3次。如果3次都失败，则判定PHY未连接或损坏。

下面是一个MDIO写操作的Verilog伪代码片段，展示了其时序的严苛性：

// 写操作：发送32-bit frame always @(posedge mdc_clk) begin if (rst) begin mdio_state <= IDLE; mdio_out <= 1'b1; // 默认高电平（上拉） mdio_oe <= 1'b0; // 默认高阻 end else begin case (mdio_state) IDLE: begin if (wr_req) begin // 开始发送，拉低MDIO（start bit '0'） mdio_out <= 1'b0; mdio_oe <= 1'b1; bit_cnt <= 0; mdio_state <= SEND_START; end end SEND_START: begin // 第一个bit是'Start'的'0' if (bit_cnt == 0) begin mdio_out <= 1'b0; bit_cnt <= bit_cnt + 1; end else if (bit_cnt == 1) begin // 第二个bit是'Start'的'1' mdio_out <= 1'b1; bit_cnt <= bit_cnt + 1; mdio_state <= SEND_OP; end end // ... 后续状态机处理OP, ADDR, REG, TURNAROUND, DATA endcase end end

4.3 PHY初始化序列：一场不容出错的“开机仪式”

当FPGA上电后，它必须执行一套标准的PHY初始化序列，才能让PHY进入SGMII模式并开始工作。这个序列，就是PHY芯片的“开机仪式”，任何一步出错，整个以太网链路就无法建立。

以最常用的Marvell 88E1111为例，其标准初始化流程如下：

1. 复位PHY：拉低RESET_N引脚至少10ms，然后释放。此时PHY内部寄存器被清零。
2. 等待PHY就绪：读取PHY的Basic Status Register（地址0x01）。当Bit 5 (Link Status) 和 Bit 2 (Auto-negotiation Complete) 都为0时，表示PHY已从复位中恢复，可以接受MDIO命令。
3. 配置SGMII模式：向Extended Status Register（地址0x11）写入0x0001，启用SGMII模式。
4. 配置速度与双工：向Control Register（地址0x00）写入0x9000，强制设置为1000Mbps全双工模式（Bit 13=1,Bit 8=1），禁用自协商（Bit 12=0）。
5. 启动配置：向Control Register（地址0x00）写入0x8000，触发一次软件复位（Software Reset），使上述配置生效。
6. 验证链接：再次读取Basic Status Register（地址0x01），检查Bit 2 (Auto-negotiation Complete) 是否为1，Bit 5 (Link Status) 是否为1。如果两者都为1，则SGMII链路已建立。

这个序列，必须严格按照时间顺序执行。例如，步骤1和步骤2之间，必须有至少100ms的延时；步骤4和步骤5之间，必须有至少1ms的延时。这些延时，不能靠#100000这样的仿真延时，而必须用一个基于MDC时钟的计数器来实现，以保证在真实硬件上的一致性。

经验之谈：在调试初期，强烈建议用一个独立的MDIO调试工具（如USB-MDIO适配器）先单独测试PHY。用它向PHY写入配置，然后读回寄存器，确认PHY本身是好的。这能帮你快速排除是FPGA逻辑问题，还是PHY硬件问题。很多“SGMII不通”的案例，最终发现是PHY芯片焊接虚焊，或者RESET_N引脚被拉死在低电平。

5. 硬件联调与信号完整性验证：用示波器和ILA解开最后的谜题

当你的Vivado工程综合、实现、生成比特流全部成功，并且烧录到FPGA后，一切看起来都很完美——TXRESETDONE和RXRESETDONE都拉高了，RXSTATUS[2]也置位了，MDIO读回的PHY状态寄存器显示Link Up。但当你用电脑ping开发板的IP地址时，却石沉大海，没有任何回应。这时，你就进入了SGMII调试的最后、也是最考验功力的阶段：硬件联调与信号完整性验证。

5.1 示波器：物理层的“X光机”

逻辑分析仪（ILA）能看到FPGA内部的数字信号，但它看不到PCB走线上的模拟波形。而SGMII的成败，最终取决于那几对微带线（Microstrip Line）上的1.25Gbps正弦波。这时，示波器就是你的“X光机”。

第一步，测量REFCLK。将示波器探头（必须是1GHz以上带宽，最好用差分探头）接到refclk_p和refclk_n上。你期望看到一个干净的125MHz正弦波，峰峰值（Vpp）在800mV左右，抖动（Jitter）小于1.5ps RMS。如果抖动超标，你会看到波形边缘模糊，GTX PLL会频繁失锁，TXRESETDONE会闪烁。解决方案是：检查REFCLK源（通常是晶振）的电源滤波电容是否足够（建议并联100nF + 10uF），以及REFCLK走线是否远离开关电源噪声源。

第二步，测量TX差分对。将差分探头跨接在txp和txn上。你期望看到一个清晰的1.25Gbps眼图（Eye Diagram），眼图张开度（Eye Height）大于200mV，眼图宽度（Eye Width）大于0.3UI（Unit Interval，即0.8ns）。如果眼图闭合，可能的原因有：

• PCB走线阻抗不匹配（非100欧姆差分阻抗）；
• 走线过长或存在stub（分支）；
• GTX的TX_PREEMPHASIS和TX_DIFF_SWING参数设置不当。

Vivado中，这些参数可以在GTX原语的属性中设置：

set_property TX_PREEMPHASIS 3 [get_cells {inst/gtxe2_channel_inst}] set_property TX_DIFF_SWING 3 [get_cells {inst/gtxe2_channel_inst}]

TX_PREEMPHASIS（预加重）用于补偿高频衰减，TX_DIFF_SWING（差分摆幅）用于调节信号幅度。它们的取值范围是0-3，需要根据你的PCB长度和材料进行实验性调整。

第三步，测量RX差分对。这是最难的一步，因为你需要一个能产生标准SGMII信号的源。如果没有专用的BERT（Bit Error Rate Tester），你可以用另一块已知正常的FPGA开发板，将其TX接到被测板的RX上，形成一个“FPGA-to-FPGA”的回环测试。如果此时被测板的RX_LOSS_OF_SIGNAL为0，RX_SYNC_STATUS为1，但RXDATA始终为0，那问题很可能出在GTX的RXCDR_CFG（时钟数据恢复配置）上。你需要在XDC中，为RXCDR_CFG添加一个更宽松的配置：

set_property RXCDR_CFG "0000000000000000000000000000000000000000000000000000000000000000" [get_cells {inst/gtxe2_channel_inst}]

这个64-bit的配置字，是GTX CDR（Clock Data Recovery）环路的参数。默认值是为理想信道设计的，对于有损耗的PCB走线，需要手动放宽其带宽。

5.2 ILA（Integrated Logic Analyzer）：数字层的“侦探”

当示波器告诉你物理层没问题时，问题就一定出在数字逻辑层。ILA是Vivado内置的逻辑分析仪，它能将FPGA内部的任意信号，实时捕获并上传到PC上显示。对于SG