做FPGA高速接口这一年多，SRIO（Serial RapidIO）是我觉得最值得花时间啃的一块硬骨头。不少朋友在群里问我，SRIO回环测试到底怎么搭、时序报红怎么查、IP核配置那么多选项到底怎么选。这期就把我实际调试SRIO的经验完整复盘一遍，从协议基础到回环测试代码，再到时序优化的具体手法，全部摊开来讲。
1. 为什么是SRIO：和PCIe、Aurora、以太网放在一起怎么选
先说结论：如果你在多个DSP、FPGA之间要传大量数据，且对延迟和实时性有硬要求，SRIO几乎是绕不开的选择。我这几年经手的项目，从雷达信号处理到图像采集传输，片间通信首选就是它。
拿它跟另外几个常见高速接口做对比：
| 接口 | 典型速率 | 协议开销 | 应用场景 | 实现难度 |
|---|---|---|---|---|
| SRIO Gen2 | 5Gbps/lane | 低（事务层精简） | 多处理器互联、基带板卡内部通信 | 中高 |
| PCIe Gen3 | 8Gbps/lane | 中（TLP开销不小） | CPU与外设、GPU互联 | 高 |
| Aurora | 最高10Gbps+ | 极低（纯通道协议） | 无协议要求的裸数据传输 | 低 |
| 以太网 | 10G/25G | 高（TCP/IP栈开销） | 跨设备、长距离传输 | 中 |
这里要注意一个最常见的选型误区：很多人看Aurora延迟低、实现简单，就直接拿来传关键业务数据。Aurora本质上只保证物理层和链路层的可靠传输，没有事务层的概念，你需要在FPGA内部自己定义包格式、自己做重传机制、自己处理多节点寻址。而SRIO把这些都定义好了，load/store、消息传递、全局共享存储，协议栈替你把大部分脏活累活干了。
我做个比喻：Aurora像一条专用高速公路，路况好但你得自己配车队和调度中心；SRIO像成熟的高速铁路网，车次、信号、调度规则都定死了，你要做的只是把货物装上车。
SRIO的协议栈也值得先理清楚，后面做时序优化时你会反复跟它打交道：
- 逻辑层：定义了读写事务、消息、维护操作，以及包格式。回环测试中主要操作的就是这一层，通过发起NREAD/NWRITE事务来验证链路。
- 传输层：负责路由和寻址，里面有device ID的概念，类似MAC地址。多设备互联时，这部分决定了包能不能到达正确的目标。
- 物理层：包含串行链路训练、8B/10B编解码、时钟恢复。我们说的时序优化，一大半落在这层。
理解这个分层很关键。很多新手报时序问题时，拿了一堆物理层的报告来找我，但真正的问题出在逻辑层的缓冲配置上；也有人反过来，链路没训练成功，还在死磕逻辑层的代码——层级定位错了，后面全白搭。
2. SRIO IP核配置细节：每个选项背后的取舍逻辑
我用Xilinx家的SRIO Gen2 IP核做例子，其他厂商的虽然界面不同，但核心概念是相通的。配置界面里有几个关键区域，每个选项都不是随便填的。
2.1 物理层配置
链路宽度选择上，项目用4x还是1x/2x，不是越高越好。4x链路带宽当然大，但PCB走线压力、功耗、FPGA引脚资源占用都是成倍增加。我的经验是：板级互联首选4x，板内短距离传输2x足够；如果只是调试验证，1x就能跑通协议，先把链路折腾起来再说。
线速率方面，Gen2标准支持1.25G、2.5G、3.125G、5G等几个档位。5G是SRIO Gen2最常见的工作点，包括TI的C6678 DSP、Xilinx的很多FPGA都支持。但这里有个坑：5G速率下，信号完整性（SI）要求明显提高，PCB板材、连接器、走线长度都会影响链路稳定性。如果PCB设计水平一般，不如先从3.125G跑起。
参考时钟这里值得多写几句。SRIO IP核的参考时钟频率，跟线速率有一一对应关系：
| 线速率 | 参考时钟频率 | 内部PLL倍频关系 |
|---|---|---|
| 1.25G | 62.5MHz 或 125MHz | 1.25G = refclk × 20 |
| 2.5G | 125MHz | 2.5G = refclk × 20 |
| 3.125G | 125MHz | 3.125G = refclk × 25 |
| 5G | 125MHz 或 156.25MHz | 5G = refclk × 40 |
我碰到过一种情况，有人把125MHz参考时钟用在了需要156.25MHz的配置上，结果IP核初始化一直失败，报的错误还很隐蔽，不看综合报告根本发现不了。参考时钟的jitter性能也要重视，SRIO协议对参考时钟的jitter有严格要求，如果使用普通的板载晶振而不是专用的时钟芯片，碰到偶发性的链路训练失败概率会高很多。
2.2 事务层配置
Buffer深度是个容易被低估的选项。SRIO协议本身有流控机制，接收端的buffer满了会通过物理层的buffer status信息通知对端暂停发送。理论上buffer小也能工作，但吞吐量会掉得很难看。我实测过：同样在5G 4x链路上，接收buffer从32个包增加到128个包，实际吞吐提升了将近20%。原因很简单，协议一直在处理暂停/恢复的流控包，有效数据占比自然就低了。
对于需要高吞吐、低延迟的应用，我建议接收buffer开大一些，发送buffer保持默认即可。发送端一般不需要很深的缓冲，因为数据往往是FPGA内部逻辑主动发起写入的，你可以通过逻辑自己控制发送节奏。
门铃（doorbell）机制也建议打开。门铃是SRIO消息传递的一种轻量级形式，对端发来一个门铃事务时，接收端会置一个中断标志。在回环测试里，门铃常被用来做“数据发送完成”的握手信号——对端收到完数据后发一个门铃回来，发送端就知道上一次传输已经结束了。
2.3 高级选项
IP核生成时，还能选是否包含共享存储单元、是否使能虚拟通道等。调试阶段这些先关掉，减少不必要的逻辑复杂性。特别是虚拟通道，需要额外的缓冲区资源，还会引入额外的时序路径，实际项目用到的场景不多。
Vivado的IP配置界面右上角会实时显示当前配置的资源占用和时钟结构，我习惯先把配置导出成文件存档，再去生成IP核。这样后面如果配置需要调整，对比差异时非常清晰，不用凭记忆回溯之前选了哪些选项。
3. 回环测试全流程：从链路训练到数据校验
回环测试是SRIO接口调试的第一步，目的是在不依赖外部设备的情况下，验证FPGA内部的物理层、链路层和事务层是否正常工作。
3.1 选择合适的回环方式
SRIO IP核支持多个回环模式，不同模式的测试意义不同：
- 硬件回环（Hardware Loopback）：外部用线缆或PCB走线把发送端差分信号直接连到接收端。这种模式最接近真实链路，把GTX的TX和RX都验证了，包括PCB走线、连接器、焊盘这些物理链路因素。板级调试完成之后，我建议把这一步作为必测项。
- 近端PMA回环（Near-End PMA Loopback）：在FPGA内部，信号从发送器输出前直接环回到接收器的模拟前端。不经过物理外部走线，主要验证GTX的收发器本身。
- 远端PCS回环（Far-End PCS Loopback）：在PCS层做回环，信号经过编解码逻辑但不出FPGA。
调试顺序上，我每次都是先PMA回环、再PCS回环、再外部硬件回环。这样出了问题能快速定位是GTX收发器本身有毛病，还是PCB链路有问题。
3.2 初始化与链路训练：最容易被卡住的一关
链路训练这个阶段，新手最容易卡住。SRIO物理层有完整的状态机：无训练→训练A→训练B→链路OK。IP核会输出链路初始化状态信号，比如port_initialized拉高才代表链路完全建立。
我碰到过一个典型场景：外部回环线缆都接好了，port_initialized一直不拉高。排查了很久，最后发现是GTX的参考时钟没有完全稳定就复位了收发器——硬件复位信号和时钟稳定标志之间的先后顺序没有对。后来在逻辑里加了时钟锁定检测，等gt_rxresetdone和gt_txresetdone都拉高之后再释放复位，问题马上就解决了。
这里记录一下我实际用的初始化顺序：
1. 等待参考时钟稳定（通过时钟芯片的LOCK输出或MMCM/PLL锁定信号） 2. 复位SRIO IP核 3. 等待gt_rxresetdone、gt_txresetdone拉高 4. 再等待port_initialized拉高 5. 发起维护事务读取对端设备ID寄存器，验证链路可用第5步很关键，这是正式读写之前的一次“握手”，能提前暴露很多问题。维护事务是SRIO协议里专门用来做配置和状态读取的，不需要复杂的应用逻辑，IP核的原语接口里就有寄存器读写端口。
3.3 回环测试的Verilog代码骨架
核心思路是：应用逻辑发起一个NWRITE事务，把数据写入FPGA自己的接收端，然后通过接收端接口把数据读回来，再做比对。因为是从自己发到自己收，调试起来很方便。
// 简化版SRIO回环测试逻辑框架 module srio_loopback_test ( input wire clk, // 用户时钟 input wire rst_n, output reg test_done, output reg [31:0] error_count ); // SRIO IP核的AXI4-Stream接口信号 wire s_axis_tvalid; wire s_axis_tready; wire [63:0] s_axis_tdata; wire [7:0] s_axis_tkeep; wire s_axis_tlast; wire s_axis_tuser; wire m_axis_tvalid; wire m_axis_tready; wire [63:0] m_axis_tdata; wire [7:0] m_axis_tkeep; wire m_axis_tlast; wire m_axis_tuser; // 发送数据生成模块 reg [63:0] tx_data; reg tx_valid; reg tx_last; always @(posedge clk or negedge rst_n) begin if (!rst_n) begin tx_data <= 64'd0; tx_valid <= 1'b0; end else if (s_axis_tready && tx_valid) begin tx_data <= tx_data + 64'd1; if (tx_data == 64'hFFFF_FFFF_FFFF_FFFE) begin tx_valid <= 1'b0; end end else if (test_start) begin tx_valid <= 1'b1; tx_data <= 64'd0; end end // 接收数据校验模块 reg [63:0] expected_data; always @(posedge clk or negedge rst_n) begin if (!rst_n) begin expected_data <= 64'd0; error_count <= 32'd0; end else if (m_axis_tvalid && m_axis_tready) begin if (m_axis_tdata != expected_data) begin error_count <= error_count + 1'b1; end expected_data <= m_axis_tdata + 64'd1; end end // 发送完成与测试完成标志 always @(posedge clk or negedge rst_n) begin if (!rst_n) begin test_done <= 1'b0; end else if (tx_last && s_axis_tready && s_axis_tvalid) begin test_done <= 1'b1; end end endmodule写这段逻辑的时候，有几个细节要注意：
AXI4-Stream的tready和tvalid握手时序必须严格按协议来：tvalid拉高之后不能因为tready为低就拉低，否则属于协议违规。SRIO IP核的用户接口基本都遵循AXI4-Stream，这个点错了协议层会直接报错。
tlast是包结束标志，SRIO的事务包通常以tlast标记边界。如果配置了tuser信号（里面包含了事务类型、目标地址等信息），需要跟tdata同一个时钟周期对齐拉高。
数据校验如果只是单纯比较，碰到两个设备初始化时的对齐问题，可能整包数据都错位了还在那里傻等。我通常在包头发一个特定的模式，比如固定值+包序号，接收端先同步包头，再逐字节校验数据体，这样能快速定位是整包开始位置错了，还是数据内容错了。
3.4 常见的回环测试失败现象
| 现象 | 可能原因 | 排查方法 |
|---|---|---|
| port_initialized一直为低 | 参考时钟不稳、复位出错、GTX初始化失败 | 检查resetdone信号、时钟锁定、逻辑复位时序 |
| 链路OK但读不到数据 | 目标地址配置错误、对齐没建立 | 检查维护事务读寄存器、对照地址映射 |
| 数据大量出错 | 编解码失步、PPM偏差、信号完整性差 | 改用PRBS模式测试物理层误码率 |
| 偶发错误（跑几分钟才错一次） | 参考时钟jitter偏大、电源纹波 | 检查clocking wizard配置、电源质量 |
PRBS测试值得单独说。SRIO IP核内部集成了PRBS生成和校验逻辑，不用写任何应用代码就能测物理层误码率。我每次回环测试之前，都会先用PRBS模式跑半小时以上，确认误码率为零，再去做业务数据回环。这样可以先把物理层问题排除掉，后续逻辑层出错时能更快定位。
4. 时序优化方法论：从时序报告反推布线布局
SRIO接口的时序优化，是我在实际调试中花时间最多的地方。很多人以为SRIO这么高速的接口，时序问题一定出在GTX收发器本身的TX/RX路径上——这个理解对了一半。实际上，真正让我调到头大的，往往是用户逻辑和IP核之间的接口时序，以及多时钟域之间的交互。
4.1 GTX收发器自身的时钟结构
GTX收发器的时钟结构要搞清楚：每个GTX channel内部有独立的TX和RX时钟域，分别由各自的PLL驱动。TX的并行时钟频率取决于线速率和FPGA内部数据位宽：
并行时钟频率 = 线速率 / 内部数据位宽以5G线速率、内部32bit位宽为例：
并行时钟频率 = 5000Mbps / 32bit = 156.25MHz如果你的用户逻辑工作在156.25MHz这个频率上，时序就比较好收敛。但很多时候IP核配置出来的内部数据位宽是64bit，并行时钟就成了78.125MHz，这时用户逻辑如果还是按156.25MHz去跑，就要做跨时钟域（CDC）处理。
4.2 用户逻辑的频率匹配和跨时钟域
SRIO IP核的AXI4-Stream接口，时钟频率是user_clk，由IP核内部根据线速率自动生成。我在一个项目里遇到过这样的情况：逻辑工程师习惯了把所有模块都跑在200MHz的全局时钟下，SRIO的user_clk是125MHz，两个时钟域之间直接用同一个FIFO读写，结果偶发丢包。
解决思路是：在用户逻辑和SRIO IP核之间，插入一个异步FIFO做缓存和时钟域转换。数据写入侧用用户全局时钟，读出侧用SRIO的user_clk，FIFO本身处理了跨时钟域的同步问题。
这里还有一个经验：FIFO的深度不要只按一包数据的大小来算。SRIO的接收端可能会背靠背收到多包数据（特别是做了多包合并、一个大事务拆成多个包），如果FIFO深度不够，数据会溢出。我按最大突发长度 × 2来设置FIFO深度，留出足够余量。
4.3 时序报告的解读方法
Vivado综合实现后，时序报告里高频出现三类违例，每种的处理思路完全不同：
第一类是SRIO IP核内部的时序违例。这类问题很少见，但一旦出现，多半是IP核例化时某个时钟没有正确连接。检查IP核的输入时钟是否和约束一致，比如IP核要求GT_REFCLK是125MHz，你的约束文件却写成了150MHz，后端布局布线就会产生错误路径。这种几乎无解，只能改正约束后重新实现。
第二类是用户逻辑到SRIO接口的跨时钟路径违例。这是最常见的。user_clk是125MHz，用户逻辑跑在250MHz，两边直连的话，路径延迟可能会超过一个user_clk周期。处理方法有三个，从简单到复杂依次是：
- 加流水寄存器（Pipeline Register），打断长路径。
- 异步FIFO隔离时钟域。
- 调整综合属性，把关键路径上某些逻辑块复制多份，提升布线自由度。
第三类是复位网络的时序违例。SRIO IP核的复位信号有自己的时序要求，最好跟IP核的user_clk同步后再释放。有些偷懒的做法是把异步复位直接接到IP核上，复位信号释放时如果刚好落在时钟上升沿附近，可能引发亚稳态，链路初始化行为就变得不确定。复位释放同步器的结构很简单：
// 复位同步释放模块 module reset_sync ( input wire clk, input wire rst_n_in, output reg rst_n_out ); reg rst_n_r1; always @(posedge clk or negedge rst_n_in) begin if (!rst_n_in) rst_n_r1 <= 1'b0; else rst_n_r1 <= 1'b1; end always @(posedge clk or negedge rst_n_in) begin if (!rst_n_in) begin rst_n_out <= 1'b0; end else begin rst_n_out <= rst_n_r1; end end endmodule这个两级触发器结构的延迟非常小，但对亚稳态的抑制效果立竿见影。我一直建议，凡是连到IP核上的任何控制信号，只要来自异步时钟域，一律先过两级触发器同步再说。
4.4 多die FPGA的约束技巧
现在我们用的很多高端FPGA是multi-die架构，比如Xilinx的VU9P，内部有4个die通过die-to-die接口互联。SRIO这种高速接口逻辑落在哪个die上，直接决定了时序能不能收敛。
关键技巧是：约束文件里用Pblock把SRIO IP核连同它的GTX收发器约束在同一个die上。如果IP核的逻辑分散在两个die之间，die-to-die互联路径的延迟是片内的好几倍，时序很难跑收敛。
我在一个项目上就吃过这个亏。6G SRIO接口的资源自动布局时被分散到两个die上，时序报告里少了大概0.3ns的裕量，怎么优化都收不回来。后来用Pblock手动指定了位置，时序一次通过。这个经验对使用Xilinx VU/UP系列、Intel的Agilex等multi-die架构的FPGA工程师特别有用。
Pblock约束写法如下：
create_pblock pblock_srio add_cells_to_pblock [get_pblocks pblock_srio] [get_cells -hier -filter {NAME =~ *srio_inst*}] resize_pblock [get_pblocks pblock_srio] -add SLICE_X*Y*具体坐标要根据你工程里GTX的物理位置来定，在某个die范围内画一块区域把SRIO逻辑框进去即可。约束完后重新布局布线，看时序报告确认所有逻辑都在目标die内。
4.5 一个实战时序优化案例
在这个项目里，SRIO用户时钟125MHz，数据位宽64bit，逻辑要同时处理两路独立的4K图像数据流。图像数据速率接近物理极限，导致s_axis_tvalid到tdata这条路径经常报时序违例。
一开始我把s_axis上的信号直接接到图像处理模块的输出端，时序报告中该路径WNS（Worst Negative Slack）是-0.2ns。这个负数看着不大，但高速接口的时序余量本来是越宽裕越好，任何温度和电压波动都可能把-0.2ns变成-0.5ns，导致实际误码。
处理方法分两步：
第一步，在图像模块和SRIO IP核之间插入一个小的寄存器组，把发送数据先打拍到SRIO IP核的时钟域内。
第二步，把图像模块中产生这些数据的那段组合逻辑做了拆分，原来一个时钟周期内完成的运算拆成两个周期，多出一级流水。
优化后WNS从-0.2ns变成+0.35ns，整个设计稳定不少。这个案例说明一个高频场景：SRIO吞吐高，用户逻辑常常以接近接口速率在跑，这时候用户逻辑本身的时序设计才是难点。组合逻辑能拆就拆，寄存器能加就加，不要怕那一两个周期的延迟——对高速数据流来说，延迟1-2个周期完全无所谓，稳定不出错才是第一优先级。
5. 实测中的高频问题与排查策略
最后把这几个月来被问得最多的、以及我自己实测中反复踩过的坑集中写一下。每个问题都是真实场景，希望能帮大家少走弯路。
5.1 链路能训练成功，但吞吐量上不去
这种问题隐蔽性很强。直观上看，链路训练通过了，数据收发也正常，但吞吐量就是只有理论值的60%-70%。
我在一个4x 5G链路上跑出了2.1Gbps的实际吞吐，理论上应该是5Gbps × 4 = 20Gbps，怎么算都不对。排查思路是：
- 检查NWRITE请求的突发长度——如果每包只有64字节，包头和协议开销占比太大，吞吐自然上不去。建议单包数据长度提到256字节以上。
- 检查接收端FIFO的读速率——接收FIFO读得太慢，流控频繁触发，吞吐就下降。看看接收侧逻辑是不是有其他地方在处理数据时卡顿。
- 检查是否有大量写响应（Response）占用了带宽——在不需要确认的场景，可以用NWRITE_with_response关闭响应，省去一半控制报文。
我的经验是，大多数吞吐上不去的情况，把单包长度加长、关闭不必要的响应机制之后，吞吐马上就能提升不少。
5.2 外部回环线缆的连接顺序
外部回环测试时，很多人直接拿一根SMA线缆把TX和RX连起来，结果链路死活起不来。
原因在于：SRIO是差分对，TX由TXP/TXN组成，RX由RXP/RXN组成。外部连接时，一定要交叉连接——TXP接RXN，TXN接RXP。因为FPGA内部的接收端通常是反相处理的，直接同相连的话，差分信号的极性反了，8B/10B解码必然失败。
这个坑我见过好几个同事踩过。括线缆标签看不清的情况下，最靠谱的办法是用IP核的gt_rxbyteisaligned信号来辅助判断——连对了这个信号会拉高，连反了怎么训练都过不去。
5.3 参考时钟相位噪声的影响
SRIO对参考时钟的质量要求，比很多人想象中高得多。我做过一次对比实验：同一个SRIO IP核，用普通晶振做参考时钟时，链路偶尔出现误码；换成专用的低抖动时钟芯片（比如TI的LMK系列），同样的PCB和逻辑，跑48小时零误码。
数据上，SRIO Gen2的5G速率要求参考时钟的随机抖动一般控制在1ps RMS以内。普通晶振出厂规格可能标称3-5ps RMS，实际工作时还会更差。如果PCB布线时参考时钟没有单独包地隔离，或者和数字信号靠得太近，抖动还会进一步恶化。建议参考时钟电路要远离高速数字信号，时钟芯片输出经过RC滤波后再送GTX的REFCLK引脚。
5.4 LVDS接口和SRIO同时使用时，IO Bank分配混乱
在资源紧张的时候，人容易把片内所有接口混排，LVDS、SRIO、DDR接口挤在一个区域。我在一个项目里就遇到过：LVDS采集接口占用了靠近GTX的IO Bank，导致SRIO的参考时钟输入和GTX收发器之间的走线被迫绕了很远，时序余量掉了将近0.4ns。
如果板上资源和引脚允许，建议把高速串行接口和并行LVDS接口分配在距离足够远的IO Bank。实在分配不开，就要在综合阶段手动设置区域约束，让两种接口的逻辑不要相互穿插。
5.5 FPGA和DSP之间的SRIO互联，常见的对齐问题
SRIO在FPGA-DSP互联场景中的应用非常多。TI的C6678 DSP和Xilinx FPGA之间的SRIO互联，我反复调过多次。几乎所有初次联调的人都会碰到同一个问题：设备ID没对齐。
SRIO协议规定，每个设备有唯一的device ID。FPGA侧发送的请求包里带有目标设备ID，DSP侧接收时要检查这个ID是否和自己配置的一致。如果DSP的boot配置里把device ID设成了0x01，FPGA一直往0x00发数据，链路层通信正常但数据永远到不了DSP。看起来像是链路有问题，实际上只是ID映射没配。
排查方法很简单：用维护事务读取对端的device ID寄存器，确认双方看到的ID一致后再跑业务。这里写个小技巧，FPGA侧SRIO IP核通常有寄存器访问接口，可以直接通过IP核自带的配置端口发起维护读，不需要额外写逻辑代码。
5.6 复位亚稳态的修复记录
最后聊一个最容易被忽视的问题——复位。热词里都提到了“fpga复位信号亚稳态”，可见这是高频痛点。
SRIO IP核的复位信号有几个不同的用途：gt_reset（GTX收发器复位）、port_reset（链路层复位）、user_reset（用户接口复位）。这些复位信号不是随便拉一下就行的，它们之间有严格的时序关系。
我在一个项目里出现了一个诡异现象：回环测试偶尔在一上电的前几秒报错，之后恢复正常。后来抓了信号发现是gt_reset释放后，用户逻辑的复位信号在异步时钟域下被释放，和user_clk的上升沿撞在一起，进入了亚稳态，导致最初几个控制信号处于不定态。
最直接的修复方式就是前面提到的复位同步释放结构，所有的复位信号，经过两级触发器同步到各自的目标时钟域之后，再接到功能模块上。这个代码一共就十几行，但解决的是看似不可捉摸的偶发问题。
回环测试完成的判断标准
写完这么多，最后说说怎么才算一次成功的回环测试。不仅仅是test_done拉高、error_count保持为零就够了。
我给自己定的标准是：
- PRBS模式跑30分钟以上，误码率为零。
- 业务数据回环跑完预设的所有测试包，error_count始终为零。
- 用ILA（集成逻辑分析仪）抓到完整的链路初始化过程，确认port_initialized在所有条件下都能正常拉高。
- 断电重启、温度循环之后重复测试，结果稳定。
可能有人觉得PRBS跑30分钟太浪费时间，但高速接口的偶发错误本来就很难复现，跑长一点能提前暴露电源和时钟质量问题。我在一个项目里就是靠长时间的PRBS测试，发现了一个电容选型错误导致的电源纹波问题，问题发现时整板还没拿去烤机，改起来成本要低得多。
SRIO接口的调试就是这样，问题往往不太直观。协议本身不复杂，复杂的是把物理层、链路层、事务层、用户逻辑层层打通，还要让时序收敛到稳定状态。希望这篇复盘能让大家少走一段弯路。如果有其他SRIO相关的坑，也欢迎来交流。
