ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

7系列FPGA上SGMII物理层协同调试全指南

7系列FPGA上SGMII物理层协同调试全指南 1. 为什么SGMII在7系列FPGA上不是“开箱即用”而是个需要亲手调教的精密仪器你拿到一块Xilinx 7系列开发板比如KC705或VC707上面标着“支持千兆以太网”心里想着“Vivado里拖个IP核点几下生成比特流插上网线就能ping通了吧”——我第一次也是这么想的。结果是IP核能生成综合能通过实现也能跑完但一上电PHY芯片没反应示波器上看GTX TX差分对根本没波形或者勉强有波形但MAC层收不到任何帧rx_bad_frame计数器一路狂涨。折腾三天后才明白SGMII在7系列FPGA上根本不是“配置好IP就能用”的功能模块而是一套需要你亲手校准、反复验证、甚至要对着PHY芯片手册逐字比对的物理层精密协同系统。核心原因在于SGMIISerial 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走线长度匹配误差是否超过50psPHY的RESET_N信号释放时机是否比GTXGTRESET晚了200nsTX_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支持GTXGTP/GTX/GTH而Spartan-7和Zynq-7000系列除Zynq UltraScale外不支持GTX它们用的是GTP其SGMII实现方式完全不同。如果你误选了XC7S50Spartan-7却按Kintex-7的教程配置GTXVivado会报错[Common 17-55] get_cells could not find cells matching...因为根本不存在GTX原语。正确的做法是打开Vivado新建工程在“Default Part”页面不要凭记忆输入型号而是点击“Browse”按钮在弹出的器件库中展开“7 Series FPGAs”然后根据你的开发板手册精确找到对应的Part Number例如KC705是xc7k325tffg676-2VC707是xc7vx485tffg1157-2。选错器件后续所有工作都是空中楼阁。其次工程类型必须选“RTL Project”绝对不要选“IP Catalog Project”或“Block Design Project”作为起点。原因很简单Block DesignBD虽然图形化方便但它会自动生成大量隐藏的约束和时钟网络对于SGMII这种需要精细控制时钟域的场景这些自动生成的约束往往是冲突的根源。我曾遇到一个案例BD里自动生成的clk_wiz_0IP其输出时钟被Vivado错误地分配给了GTX的TXUSRCLK2导致TX侧时钟域混乱TXRESETDONE永远不置位。而RTL Project则让你从一张白纸开始所有约束都由你亲手书写可控性极高。2.2 约束文件XDCSGMII的生命线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.0VGTX要求。在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成败的只有以下七个端口名方向功能调试关键点GTREFCLK输入125MHz差分参考时钟必须接在GTX Bank的专用REFCLK引脚上抖动1.5psTXUSRCLK/RXUSRCLK输入用户逻辑时钟125MHz必须由GTX内部PLL生成不能外接TXRESET/RXRESET输入发送/接收复位必须在GTRESET之后至少10us再释放否则TXRESETDONE/RXRESETDONE永不置位TXOUTCLK/RXOUTCLK输出GTX内部时钟125MHzTXOUTCLK应驱动TX侧逻辑RXOUTCLK应驱动RX侧逻辑二者相位关系影响对齐TXDATA/RXDATA输入/输出20位并行数据总线SGMII使用TXDATA[15:0]16位和TXDATA[19:16]4位控制其中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 20h0; end else begin // 高4位控制信号TX_EN1, TX_ER0, COL0 // 低16位8b/10b编码后的数据每个字节编码为2个10位码 txdata[19:16] {tx_en, tx_er, col, 1b0}; // 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侧是否启用弹性缓冲。如果设为AUTOIP核会根据TXUSRCLK和TXOUTCLK的相位差自动调整缓冲区深度。但如果你的PCB设计导致这两个时钟相位差过大10nsAUTO模式就会失效TX_BUFFER_OVERFLOW信号会被置位TX数据流中断。而这个信号在IP核的GUI界面里是不可见的你只能在生成的IP核源代码里找到gtxe2_channel_inst实例下的TX_BUFFER_OVERFLOW端口然后手动将其引出到顶层再用ILAIntegrated 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的PCSPhysical Coding Sublayer层的工作。Vivado的SGMII IP核内置了8b/10b编解码器但它的行为是固定的。例如当TXDATA[19:16]为4b0001时IP核会自动插入/K28.5/控制字符。但如果你的MAC逻辑发送了一个非法的控制组合如4b1111IP核会静默丢弃该字节导致帧丢失而你却看不到任何错误标志。为了彻底掌控我推荐在顶层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) 4b0000: encoded encode_data(din); // 数据字节 4b0001: encoded 10b0011110101; // /K28.5/ 4b0010: encoded 10b1100001010; // /K28.1/ default: encoded 10b1001010100; // /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之间的“对话”是通过一个名为MDIOManagement Data Input/Output的两线串行总线来完成的。这个总线就是FPGA和PHY的“普通话”。4.1 MDIO总线一根线上的“外交谈判”MDIO总线由两根信号线组成MDCManagement Data Clock和MDIOManagement Data I/O。MDC是由FPGAMAC产生的时钟频率通常为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固定为01OP为操作码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的三态1bz、输出1b0和输入1b1模式。2. 帧生成状态机Frame Generation FSM它负责将一个32位的管理帧按照严格的时序一位一位地发送出去。关键点在于Start字段01必须在MDC的第一个上升沿之前就准备好OP字段必须在第二个上升沿采样以此类推。任何一位的延迟都会导致整个帧被PHY丢弃。3. 错误检测与重试状态机Error Detection Retry FSMMDIO总线极易受噪声干扰。一个常见的错误是PHY在Turnaround期间未能及时驱动MDIO导致FPGA读到一个无效的16hFFFF。此时控制器不应立即报错而应启动一个重试计数器Retry Counter最多重试3次。如果3次都失败则判定PHY未连接或损坏。下面是一个MDIO写操作的Verilog伪代码片段展示了其时序的严苛性// 写操作发送32-bit frame always (posedge mdc_clk) begin if (rst) begin mdio_state IDLE; mdio_out 1b1; // 默认高电平上拉 mdio_oe 1b0; // 默认高阻 end else begin case (mdio_state) IDLE: begin if (wr_req) begin // 开始发送拉低MDIOstart bit 0 mdio_out 1b0; mdio_oe 1b1; bit_cnt 0; mdio_state SEND_START; end end SEND_START: begin // 第一个bit是Start的0 if (bit_cnt 0) begin mdio_out 1b0; bit_cnt bit_cnt 1; end else if (bit_cnt 1) begin // 第二个bit是Start的1 mdio_out 1b1; bit_cnt bit_cnt 1; mdio_state SEND_OP; end end // ... 后续状态机处理OP, ADDR, REG, TURNAROUND, DATA endcase end end4.3 PHY初始化序列一场不容出错的“开机仪式”当FPGA上电后它必须执行一套标准的PHY初始化序列才能让PHY进入SGMII模式并开始工作。这个序列就是PHY芯片的“开机仪式”任何一步出错整个以太网链路就无法建立。以最常用的Marvell 88E1111为例其标准初始化流程如下复位PHY拉低RESET_N引脚至少10ms然后释放。此时PHY内部寄存器被清零。等待PHY就绪读取PHY的Basic Status Register地址0x01。当Bit 5 (Link Status) 和 Bit 2 (Auto-negotiation Complete) 都为0时表示PHY已从复位中恢复可以接受MDIO命令。配置SGMII模式向Extended Status Register地址0x11写入0x0001启用SGMII模式。配置速度与双工向Control Register地址0x00写入0x9000强制设置为1000Mbps全双工模式Bit 131,Bit 81禁用自协商Bit 120。启动配置向Control Register地址0x00写入0x8000触发一次软件复位Software Reset使上述配置生效。验证链接再次读取Basic Status Register地址0x01检查Bit 2 (Auto-negotiation Complete) 是否为1Bit 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.3UIUnit 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信号的源。如果没有专用的BERTBit Error Rate Tester你可以用另一块已知正常的FPGA开发板将其TX接到被测板的RX上形成一个“FPGA-to-FPGA”的回环测试。如果此时被测板的RX_LOSS_OF_SIGNAL为0RX_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 CDRClock Data Recovery环路的参数。默认值是为理想信道设计的对于有损耗的PCB走线需要手动放宽其带宽。5.2 ILAIntegrated Logic Analyzer数字层的“侦探”当示波器告诉你物理层没问题时问题就一定出在数字逻辑层。ILA是Vivado内置的逻辑分析仪它能将FPGA内部的任意信号实时捕获并上传到PC上显示。对于SG
返回列表