Xilinx Aurora 8B/10B IP核配置、仿真与上板避坑指南

简介：一份聚焦Xilinx Aurora 8B/10B IP核的PDF技术资料，面向具备FPGA基础、正在使用GTX高速收发器进行串行通信设计与调试的工程师及学生。内容围绕IP核参数配置、接口速度与数据宽度选择、错误检测模式设置展开，重点解析官方文档中较易混淆的GTX引脚选择、时钟及数据/控制/校验信号连接，并说明仿真平台搭建、编解码与错误检测验证，以及为实际工程修改源码和约束文件的思路。资源包共1个PDF文件，大小约8.74MB，便于集中查阅和随工程对照。已有3748人学习，反映其在Aurora协议入门与工程落地方面具有一定参考价值。读者可从中获得IP核配置要点、GTX引脚与约束处理线索、仿真验证方法及源码适配方向，尤其适合厘清高速串口模块从协议理解到联调排错的衔接关系，可作为设计、验证和调试阶段的辅助参考。

1. 一份 Aurora 8B/10B 实践手册：从协议到引脚的断层怎么补

Xilinx Aurora 8B/10B IP核 用起来有一种典型的割裂感：协议手册讲的是 8B/10B 编码、游程、K 码、数据帧结构，Vivado 里给你的是几百个参数和一堆tx_src_rdy_n之类的端口，中间那层“为什么这么配、引脚为什么只能接这几根”没人讲清楚。这份《Xilinx Aurora 8B_10B IP核详解和仿真.pdf》就是来补这层的：它把 IP 核的配置项逐条对应到实际电路参数，专门拆了 GTX 引脚选择这种最容易混淆的地方，也把官方例子工程怎么改造成自用工程、仿真怎么跑通写成了可照着做的步骤。适合已经写过 Verilog、接惯了 UART／SPI／DDR 这类接口，但第一次碰 GT 收发器和 Aurora 链路的人。它不教你写 Verilog，它教你别在 GT 上反复翻车。

2. 8B/10B 编码与 Aurora 帧结构：先看懂 IP 在做什么

2.1 8B/10B 编码解决的是物理层的两个硬需求

高速串行链路里，接收端要从数据流里把时钟恢复出来（CDR），这就要求数据流不能长时间没有跳变；同时链路两端通常是交流耦合，变压器不允许有直流分量长期单向累积。8B/10B 就是为这两个需求服务的：每 8 bit 数据映射成 10 bit 符号，把 5B/6B 和 3B/4B 两张映射表拼起来用，并维护一个叫“运行不一致”（Running Disparity）的状态，保证发出去的 0 和 1 总数长期接近各半。结果就是直流平衡，最长游程被压到 5 个同极性位以内，CDR 不会失锁。

这张映射表不是随便列的。每个 8 bit 值对应两个候选 10 bit 码（RD- 和 RD+），选哪个由当前的运行不一致决定。解码端也能靠同样的规则反推，所以一次单 bit 翻转不会让整帧数据全部错位，最多错一个符号。这一点对后面理解soft_err和hard_err的区别很关键：前者是可检测可恢复的编码错误，后者是链路已经不可用的硬错误。

另外 8B/10B 里留了一批不在数据映射表里的码字，叫 K 码（控制字符）。K 码不承载用户数据，只承载链路语义：链路初始化、时钟补偿、错误通告。K28.5 是其中最特殊的一个，它在任意字节边界上都不会其他数据的拼接结果重复出现，所以被拿来做逗号检测，接收端靠它把 10 bit 的符号边界对齐到正确的字节边界上。这份资料里对 K 码的说明比官方文档更贴近实际调试——官方文档给的是码表，它给的是“你在波形里看到一串错位数据时，先去看 comma 对齐有没有成功”。

2.2 Aurora 帧结构：数据帧和通道帧是两套东西

Aurora 8B/10B 在 8B/10B 之上又包了一层帧。理解这层帧，才能理解 IP 的端口为什么长这样。

链路空闲或做管理动作时，走的是通道帧（Channel Frame），携带的是通道初始化、时钟补偿、通道错误这些信息，用户数据不参与。真正传用户数据走数据帧（Data Frame），结构大致是：起始字符对 SCP 打头，中间是用户负载，末尾用结束字符 ECC 收尾。SCP 里包含逗号字符，接收端一看到它就开始重新对齐帧边界，所以每一帧都是自同步的，丢一帧不会污染后面的帧。

这里有个容易忽略的细节：Aurora 的帧不是固定长度的。负载长度由 IP 在发送时决定，接收端靠 SCP 和 ECC 之间的符号计数来界定，所以两侧的帧长配置不一致时，表现出来的往往不是“报错”，而是“数据看着对、但每隔几帧错一段”——这类现象在仿真阶段极难发现，只有跑长包对拍才会暴露出来。

还有一个更隐蔽的坑：链路初始化阶段，两个方向是各自独立的。A 侧channel_up拉高不代表 B 侧也拉高了，只代表 A 侧认为自己收到了足够的初始化序列。所以做板级联调时，两侧的channel_up必须分别观测，不能只看一端就下结论。

2.3 从协议映射到端口：哪些信号必须接、哪些可以悬空

把协议映射到 IP 端口上，新手最容易犯的错是“端口全接上再说”，结果接了一堆不该接的，反而把reset_pb或power_down拉错了电平。下面这张表是这类工程里最常打交道的端口，按“必须正确接”和“可以按需处理”分两类。

这张表的价值在于“必须”和“可以”的分界。很多人把power_down、gt_pwrdown、loopback全都悬空，综合工具给个默认值 0 看似没事，但某些器件上悬空输入会被综合成不确定态，上板后表现为“仿真好好的，一上板就 channel_up 起不来”，查半天查不出原因。资料里对这几个控制脚的处理写得很明确：不用的控制脚要显式赋 0，不要指望默认值。

握手这块要单独说一句。Aurora 的*_src_rdy_n和*_dst_rdy_n是低有效、半握手的组合逻辑，发送方拉低src_rdy_n表示“我有数据”，接收方拉低dst_rdy_n表示“我能收”，两者同时为低的那个user_clk上升沿数据才真正被吞掉。这套握手的时序要求比 AXI-Stream 松，但也意味着你不能用 AXI 那套 valid/ready 的思路直接套，否则会出现“数据发了一半对方没接”的丢包。仿真波形里如果看到tx_src_rdy_n拉低后数据保持不变、tx_dst_rdy_n迟迟不拉低，基本就是接收侧 FIFO 满了或者 IP 内部在等时钟补偿。

3. IP 核配置实操：线速率、位宽与 GT 选型的对应关系

3.1 在 Vivado 里把 IP 配起来的实际流程

Aurora 8B/10B IP 的参数不是一个个填进去就完事的，它们之间有强耦合：线速率、参考时钟频率、数据位宽、lane 数这四个参数互相约束，改一个另外三个往往要跟着改。稳妥的做法是先定物理约束（板上 GT 参考时钟是多少、用几个 lane），再反推 IP 参数，而不是先在 IP 里点一通再去找引脚。

我一般用 Tcl 脚本建 IP，好处是参数留痕、能版本管理、换项目时改几行就能复用。下面这段是常见写法：

# 创建 Aurora 8B/10B IP 实例 create_ip -name aurora_8b10b -vendor xilinx.com -library ip -module_name aurora_8b10b_0 # 一次性配置核心参数，注意参数名随 IP 版本可能变化 set_property -dict [list \ CONFIG.C_NUM_OF_LANES {4} \ CONFIG.C_LINE_RATE {3.125} \ CONFIG.C_REFCLK_FREQUENCY {156.25} \ CONFIG.C_INIT_CLK {100} \ CONFIG.C_DATA_WIDTH {32} \ CONFIG.C_INTERFACE {Framing}\ CONFIG.C_USE_BYTESWAP {false} \ CONFIG.C_USE_DRP {false} \ CONFIG.C_USE_SCSIM {true} \ ] [get_ips aurora_8b10b_0] # 生成 IP 输出产物 generate_target all [get_ips aurora_8b10b_0]

逻辑说明：C_NUM_OF_LANES决定用几条 GT lane，直接绑定到物理 Quad 里连续的通道；C_LINE_RATE是单条 lane 的线速率，单位 Gbps，必须和板上参考时钟、GT 的 PLL 分频比能对上；C_REFCLK_FREQUENCY是参考时钟频率，单位 MHz，写错了 IP 内部会报“参考时钟频率与线速率不匹配”的 DRC；C_DATA_WIDTH是用户侧每周期数据宽度，4 lane × 32 bit 意味着tx_data是 128 bit 位宽；C_INTERFACE选 Framing 还是 Streaming 决定端口长什么样，Streaming 没有帧开销但也没有帧边界，工程量测时更依赖对拍；C_USE_SCSIM打开后仿真模型体积小很多，跑仿真的时间能降一个数量级，但功能覆盖不完全，上板前建议再跑一次完整模型。

参数说明：如果 IP 版本里没有C_USE_SCSIM这个名字，找工程里的C_USE_SIM_MODEL或 IP 属性编辑器里的 “Simulation Model” 下拉项，含义一致。C_USE_BYTESWAP在 8B/10B 里很容易被忽略——打开后每个字节在发给 GT 之前会做字节序交换，如果用户侧数据是按小端拼的，打开和关闭两种配置下解出来的值会整个反过来，这是第 5 章要单独讲的一个坑。

3.2 线速率、位宽、参考时钟三者的换算关系

这三个参数不是独立的，必须满足下面的关系：

线速率(Gbps) = 参考时钟频率(MHz) × (GT 内部倍频比) / 1000 用户数据位宽 = lane 数 × 每 lane 每周期字节数 × 8 有效吞吐 = 线速率 × (8/10) × lane 数

举个例子：4 lane、单 lane 3.125 Gbps、每 lane 4 字节宽，那么tx_data是 128 bit，用户侧时钟user_clk约 78.125 MHz，理论有效吞吐约 10 Gbps（扣掉 8B/10B 的 20% 编码开销）。C_REFCLK_FREQUENCY填 156.25 时，GT 内部要倍频到 3.125 Gbps，倍频比 20，这在 GT 可接受的范围内；如果板上参考时钟是 100 MHz，那要么改线速率，要么换分频配置，不能硬填 100。

表里最后一列的“接错不报错但收发不通”是最要命的一类，因为综合、实现、时序都能过，上板就是不通，没有报错信息可查。

3.3 GTX 引脚选择：为什么这里是翻车重灾区

GT 收发器的引脚不是随便挑的。每个 FPGA 里 GT 按 Quad 分组，每个 Quad 有独立的专用参考时钟输入引脚（MGTREFCLK），一个 Quad 里的 4 条 lane 只能共用一对参考时钟。Aurora IP 里配置的 lane 数决定了要占用几个 Quad、具体哪几条 lane，而这个选择在 IP 配置阶段就必须定死，因为 XDC 里的引脚约束、时钟约束都是按这个配置写死的。

新手最常见的流程是“先建 IP、跑通实现、再去分配引脚”，在普通 IO 上这么干没问题，在 GT 上直接翻车：IP 里随机选了个 X0Y0 通道，但硬件板子上 X0Y0 的参考时钟晶振没贴、或者那对差分线拉到了别的器件，改 XDC 也救不回来，只能回去重新配 IP、重新生成、重新综合，一轮就是半小时起步。

稳妥顺序是反过来的：先看原理图确认哪几个 Quad 的参考时钟已经布好、哪几条 lane 的差分对引到了连接器，再回 IP 里选 lane 位置，最后写 XDC。XDC 里和 GT 相关的约束主要是三块：

# 1. 参考时钟差分对引脚，必须落在所选 Quad 的专用 MGTREFCLK 上 set_property PACKAGE_PIN AB12 [get_ports gt_refclk_p] set_property PACKAGE_PIN AB13 [get_ports gt_refclk_n] set_property IOSTANDARD DIFF_SSTL12 [get_ports {gt_refclk_p gt_refclk_n}] # 2. GT 参考时钟的周期约束，频率必须和 IP 配置里的 C_REFCLK_FREQUENCY 一致 create_clock -period 6.400 -name gt_refclk [get_ports gt_refclk_p] # 3. GT 收发链路的差分对，按 Bank/Quad 顺序写，不能跨 Quad 乱配 set_property PACKAGE_PIN AC1 [get_ports gt_tx_p[0]] set_property PACKAGE_PIN AC2 [get_ports gt_tx_n[0]] # ... 其余 lane 依此类推

逻辑说明：第一段把参考时钟绑到专用引脚上，MGTREFCLK 引脚在器件里是硬连线到对应 Quad 的时钟网络的，绑到普通 IO 上综合不一定报错，但实现阶段布线会失败；第二段-period 6.400对应 156.25 MHz，这个值必须和 IP 里填的C_REFCLK_FREQUENCY严格一致，差一点时序分析就不准；第三段按 lane 顺序列差分对，注意gt_tx_p[0]到gt_tx_p[3]必须落在同一个 Quad 的连续通道上，跨 Quad 时 GT 内部的共享时钟资源会对不上。

参数说明：PACKAGE_PIN的取值必须从板级原理图或器件 pinout 文件里查，不能凭经验猜。不同封装的 GT 引脚编号完全不同，同一个型号不同速度等级也可能不一样。写 XDC 时建议把 GT 约束单独放一个文件（比如gt_pins.xdc），和用户逻辑的 IO 约束分开，换板子时只改这一个文件。

4. 跑通官方例子仿真：从仿真到改激励的完整流程

4.1 官方例子工程的目录结构

Aurora IP 生成之后，Vivado 会自动附带一套例子设计（Example Design），在 IP 右键菜单里能直接打开。这套例子的目录结构大致是：

• 顶层*_exdes.v：把 IP 核、帧生成器、帧校验器、时钟模块拼在一起
• *_support.v：IP 的封装层，处理复位同步、时钟缓冲等
• frame_gen/frame_check：一对数据源和校验器，负责产生固定模式的数据并核对
• clock_module：产生init_clk、复位等辅助信号
• 仿真用的 testbench：顶层激励，驱动参考时钟、复位，跑一段时间后看channel_up

这套例子的价值不在于“能跑”，而在于它演示了正确的复位顺序和握手接法。我一般不会直接在例子工程上改业务逻辑，而是把它当作参考实现，把*_support.v和顶层拼接方式抄到自己的工程里，帧生成器和校验器换成自己的模块。

4.2 跑通仿真的完整命令流

用 Vivado 自带仿真器跑一遍，命令行方式比 GUI 更适合反复迭代。下面这段是常见的批处理流程：

# 在工程目录下用批处理模式打开 Vivado 并跑仿真 vivado -mode batch -source run_sim.tcl -log sim.log -journal sim.jou

配套的run_sim.tcl大致长这样：

# 打开已有工程 open_project ./aurora_demo.xpr # 把仿真顶层设成例子工程自带的 testbench set_property top aurora_8b10b_0_exdes_tb [get_filesets sim_1] set_property top_lib xil_defaultlib [get_filesets sim_1] # 指定仿真器为 Vivado 自带 xsim，跑 200us launch_simulation -simset sim_1 -mode behavioral run 200us # 把关键信号拉出来看，方便后面批处理分析 add_wave /aurora_8b10b_0_exdes_tb/u_exdes/channel_up add_wave /aurora_8b10b_0_exdes_tb/u_exdes/lane_up add_wave /aurora_8b10b_0_exdes_tb/u_exdes/frame_err

逻辑说明：第一步用 batch 模式启动避免 GUI 卡住，-source指定脚本；第二步切顶层 testbench，例子工程默认可能把 exdes 顶层当仿真顶层，那样channel_up没有激励驱动，跑了也是全 0；第三步run 200us是关键，Aurora 链路初始化要发若干轮初始化序列，仿真时间太短根本看不到channel_up拉高，很多人跑 10us 看没起来就以为配置错了，其实是时间不够；第四步把关键信号加到波形里，批处理模式下这些波形会存到sim_1/behav/xsim目录下，可以用脚本解析。

参数说明：run的时间要按线速率和 lane 数估算。链路初始化大致需要几百个user_clk周期量级，4 lane、78 MHz 的user_clk下，初始化在 10us 以内能完成，但加上复位释放、时钟稳定的时间，跑 100us 到 200us 比较稳。如果开了C_USE_SCSIM，仿真速度能快 5 到 10 倍，但初始化行为可能被简化，建议先用 SCsim 快速迭代逻辑，最后用完整模型跑一次确认。

4.3 改测试激励：从固定模式换成自己的数据生成与校验

例子工程自带的帧生成器发的是固定递增模式，验证不了复杂场景。把它换成自己的数据源，核心是把tx_data、tx_src_rdy_n的驱动逻辑从frame_gen里剥出来。下面是一段最常见的改法，用一个计数器产生递增数据，并配上 CRC 校验：

// 自定义发送激励：递增计数 + 简单累加和校验 always @(posedge user_clk) begin if (!reset_pb) begin tx_data <= 128'd0; tx_src_rdy_n <= 1'b1; // 高有效复位期间不发送 tx_char_is_k <= 16'd0; // 不手工发 K 码 send_cnt <= 32'd0; end else if (channel_up && !tx_dst_rdy_n && tx_src_rdy_n == 1'b0) begin // 上一次握手成功，推进数据 send_cnt <= send_cnt + 1'b1; tx_data <= {96'd0, send_cnt}; tx_src_rdy_n <= (send_cnt == 32'd1023) ? 1'b1 : 1'b0; end else if (channel_up && tx_src_rdy_n == 1'b1) begin // 通道就绪后启动第一拍发送 tx_src_rdy_n <= 1'b0; tx_data <= {96'd0, send_cnt}; end end

逻辑说明：tx_src_rdy_n是低有效，复位期间必须为高，否则会在链路还没起来时把数据推给 IP，IP 内部 FIFO 满了之后行为未定义；握手成功的判定是“我方src_rdy_n为低且对方dst_rdy_n为低”，两个条件同时成立的那个时钟沿数据才被接收；发送 1024 个数据后主动撤回src_rdy_n，模拟一次突发结束，方便观察接收侧 ECC 收尾行为。

参数说明：tx_char_is_k全 0 表示所有字节都按用户数据发，如果业务里需要嵌入自定义 K 码（比如做带内信令），把对应 bit 置 1 并把该字节填成合法 K 码值，非法 K 码会被接收端判成soft_err。{96'd0, send_cnt}是高 96 位补 0、低 32 位放计数，实际工程里按C_DATA_WIDTH调整补零位数。

接收侧对照的校验逻辑建议单独写一个模块，不要塞进发送模块里，否则仿真波形会很难读。校验模块里要做的三件事：用rx_src_rdy_n和rx_dst_rdy_n做握手、把rx_data和期望值比对、把soft_err和frame_err累计到寄存器里。三个信号都要看，只看数据不看错误标志的话，偶发的编码错误会被漏掉。

5. 避坑与排查：五个最容易卡住的地方

5.1 channel_up 一直为低，波形里 lane_up 也是 0

现象：仿真跑了 1 ms，channel_up始终是低电平，lane_up逐位看全是 0，tx_data在发但接收侧毫无反应。

原因：最常见的是参考时钟没进来。GT 的参考时钟必须走专用差分引脚，如果 XDC 里绑到了普通 IO，或者create_clock的周期和 IP 里填的C_REFCLK_FREQUENCY对不上，GT 的 PLL 根本锁不住，后续所有初始化都无从谈起。第二常见的是reset_pb的复位宽度不够——Aurora 要求复位至少保持若干个init_clk周期，短复位会导致初始化状态机没走完就被打断。

解决：先看 GT 的gt_pll_lock之类的状态输出（不同 IP 版本信号名不同，找 PLL 相关的 lock），锁不住就是参考时钟的问题；锁住了但lane_up不起来，检查两侧的线速率、lane 数、C_USE_BYTESWAP配置是否一致，任何一侧配错都会导致初始化序列对不上。复位宽度按 IP 文档要求，我一般给init_clk的 64 个周期以上。

5.2 仿真跑得极慢，跑一晚上还没出结果

现象：完整模型下仿真速度是每秒几个微秒，想跑 1 ms 验证长时间稳定性，结果跑了一晚上没跑完。

原因：Aurora 的完整仿真模型里包含了 GT 的模拟行为模型，内部有大量小步长迭代，速度天然慢。如果再把C_USE_SCSIM关掉、仿真精度设成默认值，慢上加慢。

解决：迭代阶段开C_USE_SCSIM，把仿真精度设成typical，跑通功能后再用完整模型跑一次短时间确认；长时间稳定性验证不要靠仿真，靠上板跑 IBERT 或内建误码测试。另一个提速手段是把run拆成多段，中间加restart前先save_wave_config，避免一次跑完再回头找波形。

5.3 综合通过、实现报 GT 引脚冲突

现象：综合没报错，implementation 阶段报 “GT location conflict” 或者 “MGTREFCLK pin not available”，怎么改 XDC 都不行。

原因：IP 里选的 lane 位置和 XDC 里写的PACKAGE_PIN不在同一个 Quad，或者 IP 配置的 lane 数和 XDC 里列的差分对数量不一致。GT 的引脚是硬资源，IP 配置阶段就把位置定死了，XDC 只能约束不能改。

解决：回到 IP 配置界面看 “GT Selection” 那一页，确认 lane 位置，然后按这个位置去改 XDC；如果硬件板子已经定了、IP 配置改不了，那就只能在 IP 里重新选一个能对上的位置，重新生成、重新综合。这也是为什么第 3 章强调先看原理图再配 IP——顺序反了，这个坑必然踩一次。

5.4 收到的数据整体错位或高低字节颠倒

现象：仿真里rx_data有数据，但和发送值对不上，看起来像是每个 32 位字内部字节顺序反了，或者整体偏移了一个字节。

原因：两个可能。一是C_USE_BYTESWAP配置和用户侧数据拼接方式不匹配，打开时 IP 会在发给 GT 前做字节序交换，用户侧按小端拼就会对不上；二是C_DATA_WIDTH配的是每 lane 字节数，用户侧按 bit 数理解，导致tx_data的位拼接顺序搞错。

解决：先关掉C_USE_BYTESWAP跑一遍，如果对上了就是字节序问题；关掉还不对，就把一个已知值（比如32'h12345678）从发送端打进去，在接收端波形里看它变成什么样，反推错位规律。这类问题不要靠猜，靠一个已知值对拍最快。

5.5 上板后链路偶发断开，soft_err 计数缓慢增长

现象：板级跑起来channel_up能拉高，但跑几小时后channel_up掉一次又自己恢复，soft_err计数器缓慢增长。

原因：信号完整性余量不足。GT 的均衡（equalization）和预加重（pre-emphasis）参数是按理想信道调的，实际板子上走线损耗、连接器阻抗不连续、参考时钟相位噪声都会吃掉眼图余量，表现为偶发的编码错误，被 8B/10B 检出来记成soft_err。

解决：用 IBERT 扫一遍眼图，看眼高眼宽还有多少余量；余量不足就调 GT 的 TX 预加重和 RX 均衡参数，或者降线速率跑。soft_err持续增长但channel_up不掉，说明链路还能纠错，但已经在边缘，这种状态不能当作“正常工作”交付。

6. 从仿真到上板：约束、复位与时序的收尾检查链

仿真跑通只是拿到入场券，上板能不能稳定跑，取决于三件事有没有做扎实：复位顺序、时序约束、眼图余量。

复位顺序排第一。Aurora 的复位不是简单拉一下reset_pb就完事，正确顺序是：先让gt_pwrdown和power_down保持有效，等参考时钟稳定后释放，再释放reset_pb，最后等channel_up拉高才允许用户逻辑往tx_data上推数据。顺序搞反的典型现象是“第一次上电能通，热重启就不通”，因为热重启时 GT 的 PLL 还没重新锁住，reset_pb已经释放了，初始化状态机跑在错误的时钟上。

时序约束排第二。user_clk是 IP 输出的，用户逻辑如果直接用user_clk采样自己的寄存器，需要给这条时钟加create_generated_clock或者至少create_clock，否则时序分析器不知道这条时钟的存在，跨时钟域路径全部按默认处理，报出来的时序全是假的。下面这段是常见的补法：

# user_clk 由 IP 内部 MMCM 产生，需要显式声明 create_clock -period 12.800 -name user_clk [get_pins aurora_8b10b_0/inst/user_clk_out] # 用户逻辑里跨到 init_clk 域的路径，明确设为异步 set_false_path -from [get_clocks init_clk] -to [get_clocks user_clk] set_false_path -from [get_clocks user_clk] -to [get_clocks init_clk]

逻辑说明：-period 12.800对应 78.125 MHz，这个值要从 IP 实际输出的user_clk频率反推，不能拍脑袋填；set_false_path只对真正的异步跨域路径用，用了之后时序分析器不再检查这条路径，所以必须确认跨域逻辑本身有同步器，否则等于把问题藏起来。

参数说明：如果工程里user_clk的频率随配置变化，建议在 Tcl 里用变量算周期，避免换配置时忘了改约束。set_false_path的方向要写全，只写一个方向等于只豁免了一半路径。

眼图余量排第三，也是上板后最容易被忽略的一步。仿真里信道是理想的，上板后走线损耗、连接器、过孔都会吃掉余量，soft_err缓慢增长就是余量不足的信号。收尾阶段一定要用 IBERT 或者内建的误码测试跑一轮，看眼高眼宽还有多少 dB 余量，再决定要不要调 GT 的预加重和均衡参数。我一般会把这一步写进交付检查清单，不跑完不签字。

血泪教训是早期一个项目，仿真跑了一周一切正常，上板后白天跑没事、晚上机房温度降下来就偶发断链，查了三天才发现是 GT 预加重按常温调的，低温下器件参数漂移把余量吃没了。从那以后我每次上板前都强制走一遍“复位顺序核对 → user_clk 约束补全 → IBERT 扫眼图”这条链，哪怕工期再紧也不跳步。希望帮到你。

本文还有配套的精品资源，点击获取