简介基于FPGA的视音频光端机工程代码面向FPGA开发者和视音频传输系统设计人员可用于学习多路模拟视频输入、多路音频处理、电话接口、以太网及开关量控制等一体化传输方案。该工程源自商业项目集成度较高覆盖从模拟视频ADC采样与格式适配NTSC/PAL/SECAM、FPGA内部视频音频编解码到E1/T1电话、MAC层以太网帧处理以及继电器开关量控制的完整链路有助于理解复杂信号在光纤链路中的实时传输与同步设计。包内共198个文件压缩后约1.4MB包含Verilog/VHDL源码、Xilinx工程文件.xise/.prj、IP核配置.xco、约束文件.ucf、综合实现报告及生成比特流.bit/.mcs等目录结构贴近真实项目开发流程。已有491人学习下载适合希望参考成熟设计方案来搭建光端机原型、调试音视频同步或提升FPGA多接口设计能力的工程师。1. 光端机不只是「光电转换」一份 FPGA 视音频传输代码到底包含什么某个园区做监控改造摄像头和显示端隔了一公里多网线够不着只能上光端机。很多人以为光端机就是光模块加一个协议转换芯片拿到这份「视音频光端机代码」才发现真正干活的全是 FPGA 逻辑——并串转换、时钟恢复、行场同步、音频加嵌每一项都得在代码里显式处理。这份资源把一条完整的视音频光传输链路写成了可综合工程从视频采集、数据打包到高速收发器再到接收端还原出同步信号和音视频流属于那种「看着只是连接拆开全是时序」的项目。适合做安防传输、广电信号分配、工业视频回传的开发者拿来当基线工程二次开发也适合想搞懂 FPGA 高速链路设计的同学做参考。下面按架构、核心代码、跑通、排错、改造的顺序逐层拆开。2. 系统架构与数据流从摄像头到光纤这条链路上的完整通路2.1 光端机在整个链路中的角色光端机的本职是把视频、音频、低速数据打包成适合长距离光纤传输的串行码流。视频源可能是模拟摄像头经编码后输出的并行数字信号也可能是采集卡送来的 YUV/RGB 并行数据音频则是独立的 I2S 或模拟采样信号。它的核心要求是「透明」——对端看到的是和本地几乎一致的行场时序、同样的像素排列、连续不中断的音频采样点。具体到这个工程里传输方向是单向主链路加少量辅助数据分辨率覆盖 720p/1080p帧率常见 50/60 帧两种。FPGA 承担全部协议处理像素时钟域把视频行缓存下来打成带帧号行号的包插入音频段送入高速收发器转成串行差分信号接收端做完时钟恢复、字对齐再解包还原出行场同步信号。光模块只负责光电转换协议层面完全不参与所以想扩展通道、改分辨率、加密传私有数据都是在 FPGA 代码里动刀子。2.2 硬件平台构成与关键接口一套典型视音频光端机的板级构成如下部件典型接口代码里对应的角色视频输入并行 YUV/BT.112024bit 148.5MHzvid_capture模块采集按 DE 有效信号采样音频输入I2S44.1kHz/48kHzaudio_embed模块缓存并按帧插入消隐区FPGA中规模逻辑 高速收发器打包、解包、CRC、跨时钟域 FIFO光模块SFP/光收发一体模块收发电信号与光信号互转差分对直连收发器布线时最容易被忽略的是视频参考时钟和 FPGA 系统时钟不是同一个视频源有自己的像素时钟光模块发送侧又有一个固定频率的参考时钟常见 125MHz 或 156.25MHz两者频率不成整数倍。所以工程内部至少有「像素时钟域」「系统处理时钟域」「收发器恢复时钟域」三个区域跨域都靠异步 FIFO而不是在两个时钟域里直接操作同一个寄存器。2.3 发送链路数据流发送方向的处理可以看作一条五级流水采样、整行缓存、打包、过异步 FIFO、进收发器。像素时钟域先把视频行的有效像素写进行缓存 FIFO写完一行后通知打包状态机。状态机从系统时钟域读出行数据按下面格式组织[帧头 0xEB90] [帧号 16bit] [行号 12bit] [音频标记 4bit] [有效像素 N x 24bit] [CRC8]帧头和帧号用于接收端识别起点、检测丢帧行号解决乱序和丢行问题音频标记告诉接收端本行消隐段里是否夹带音频样点。这样每一行都是一个独立包接收端不必缓存整帧只要按行号重组即可对 DDR 带宽要求很低。1080p60 场景下每行有效像素 1920加上包头约 230 字节行频 67500 行/秒换算下来裸数据约 3.2Gbps这是选收发器 lane 速率下限的依据。2.4 接收链路数据流接收方向进来的是串行差分信号第一步不是解包而是等收发器完成 CDR 锁定和字对齐。FPGA 内嵌的 CDR 从数据流里恢复出采样时钟但由于串行比特流没有外部同步信号接收端必须靠包头里的特殊码型找到字节边界也就是字对齐。对齐之后数据进入解包状态机先识别帧头再校验 CRC。校验通过就按行号写入行缓存 FIFO等到 CRT 时序把整行数据读出重建 DE/HS/VS 三种同步信号。音频数据从解出来的包中单独切出先写进一个小容量 FIFO再由本地音频采样时钟读出恢复成连续 I2S 流。整个接收链路从宏观上看是一个「把包还原成时序」的过程和发送链路正好镜像。2.5 技术选型为什么是 FPGA 而不是专用芯片市面上有成熟的视音频传输专用芯片但它们的协议固定、通道数固定一旦想插入 RS232 数据、改自己私有加密规则、或者做成 4 路视频复用专用芯片就完全不可控。FPGA 的价值在于物理层收发器是硬核但协议层完全由 Verilog 决定改打包格式不用换芯片重新综合一次就能烧录验证。代价是代码里所有时序都得自己兜住——这也是这份源码最有参考价值的地方拿到手可以直接看一个成熟链路是怎么处理时钟域、怎么设计状态机、怎么做错误恢复的。3. 核心模块拆解一个视频帧从进入 FPGA 到输出的完整代码链路3.1 输入采集像素时钟域的同步与采样发送端第一个模块处理的是视频源进 FPGA 的边界。这里最容易犯的错是不做时序处理就把外部信号当普通信号采导致行场抖动。合格的做法是先打两拍同步再在 DE 有效时采数据同时检测 HS 上升沿作为行起始标志。module vid_capture #( parameter DATA_W 24 )( input wire pix_clk, input wire pix_rst_n, input wire [DATA_W-1:0] vid_data_in, input wire vid_de_in, input wire vid_vs_in, input wire vid_hs_in, output reg [DATA_W-1:0] vid_data_out, output reg vid_valid_out, output reg line_start_out ); reg hs_dly1, hs_dly2; reg hs_rise; always (posedge pix_clk or negedge pix_rst_n) begin if (!pix_rst_n) begin hs_dly1 1b0; hs_dly2 1b0; end else begin hs_dly1 vid_hs_in; hs_dly2 hs_dly1; end end assign hs_rise hs_dly2 ~hs_dly1; always (posedge pix_clk or negedge pix_rst_n) begin if (!pix_rst_n) begin vid_data_out {DATA_W{1b0}}; vid_valid_out 1b0; line_start_out 1b0; end else begin vid_data_out vid_de_in ? vid_data_in : vid_data_out; vid_valid_out vid_de_in; line_start_out hs_rise; end end endmodulevid_de_in是数据有效信号只在消隐区之外拉高vid_data_in在 DE 有效时才是有效像素。hs_dly2 ~hs_dly1是标准的上升沿检测写法用两拍打拍是为了避免亚稳态传播到状态机。line_start_out输出单个时钟周期的高电平脉冲后续打包状态机靠它知道「新的一行开始了」而不是靠数像素个数这样即使输入的行宽度有微小变化打包逻辑也能自适应。3.2 行打包状态机把像素变成带校验的包采集模块输出的像素要在系统时钟域组织成包。这里的关键点是像素时钟域写入行缓存系统时钟域读出发包所以行缓存必须用异步 FIFO 实现。打包状态机本身不复杂但每个状态转换条件都要清楚。module pkt_tx #( parameter DATA_W 24, parameter MAX_PIXELS 1920 )( input wire sys_clk, input wire sys_rst_n, input wire line_start_pulse, input wire [DATA_W-1:0] pixel_data, output reg [7:0] tx_byte, output reg tx_valid ); localparam ID_HEAD 3d1; localparam ID_PAYLOAD 3d2; localparam ID_CRC 3d3; localparam ID_WAIT 3d0; reg [2:0] state; reg [11:0] pixel_cnt; reg [7:0] crc_acc; reg [15:0] frame_id; reg [11:0] line_id; // 简化状态机主体仅列关键分支 always (posedge sys_clk or negedge sys_rst_n) begin if (!sys_rst_n) begin state ID_WAIT; tx_valid 1b0; pixel_cnt 12d0; crc_acc 8d0; end else begin case (state) ID_WAIT: begin tx_valid 1b0; if (line_start_pulse) begin state ID_HEAD; line_id line_id 1b1; end end ID_HEAD: begin // 发送帧头 0xEB90并启动 CRC tx_byte 8hEB; tx_valid 1b1; state ID_PAYLOAD; end ID_PAYLOAD: begin if (pixel_cnt MAX_PIXELS) begin state ID_CRC; end else begin pixel_cnt pixel_cnt 1b1; end end ID_CRC: begin tx_byte crc_acc; tx_valid 1b1; state ID_WAIT; end endcase end end endmodule实际工程里ID_HEAD会拆成连续几个周期把帧号、行号、音频标记逐个发出去代码看起来会更长但骨架就是这段。像素计数用pixel_cnt MAX_PIXELS判断行结束比等 DE 信号可靠因为 DE 在跨时钟域后边沿已经不可信crc_acc每字节累加CRC8 多项式在头部初始化收端校验不通过就把当前整行丢弃并报警。帧号和行号在这里由本地寄存器维护每帧开始时帧号加一行计数器在 VS 有效时清零。3.3 收发器接口封装把并行包送进串行链路高速收发器的代码部分最像「黑匣子」厂家 IP 例化之后对外暴露的通常是一组并行数据总线、字符使能和对齐状态信号。写应用层时不需要碰物理层细节但必须正确处理数据位宽和突发节奏。module gt_tx_wrapper #( parameter DATA_WIDTH 64, parameter K_CHAR 8hBC // K28.5, 用于对齐标志 )( input wire tx_clk, input wire [DATA_WIDTH-1:0] tx_data, input wire [DATA_WIDTH/8-1:0] tx_kchar, input wire tx_ready, output wire tx_diff_p, output wire tx_diff_n ); // 厂家原语例化8B/10B 编码由硬核完成 // tx_data 在 tx_ready 拉高时有效K 字符用于接收端字对齐 assign tx_kchar[0] (tx_data[7:0] K_CHAR); endmodule收发器发送侧通常在tx_ready为高时才采样并行数据否则数据会丢。接收侧则需要持续观察rx_byte_aligned信号只有字对齐完成后解包状态机才能启动。实际调试中出现花屏、斜纹九成问题都出在这一步要么字对齐没锁定要么锁定后并行数据位宽和打包字节流不匹配。回环自测是验证收发器的最快路径——把 TX 直接环到 RX跑 PRBS 码型先确认物理链路无误再上应用层协议错误定位范围一下子就缩小了。3.4 接收端解包与像素重建接收端解包状态机是发送端状态机的镜像差别在于多了对齐和校验先找0xEB90帧头再按帧号行号重组数据。帧号不连续时说明链路丢包接收端可以选择插黑帧或者保持上一帧画面取决于产品需求。module pkt_rx #( parameter MAX_PIXELS 1920 )( input wire rx_clk, input wire rx_rst_n, input wire [7:0] rx_byte, input wire rx_byte_valid, input wire rx_byte_aligned, output reg [23:0] pixel_out, output reg pix_valid, output reg hs_out, output reg vs_out ); reg [3:0] state; reg [15:0] exp_frame_id; reg [11:0] exp_line_id; always (posedge rx_clk or negedge rx_rst_n) begin if (!rx_rst_n) begin state 4d0; pix_valid 1b0; exp_frame_id 16d0; end else if (!rx_byte_aligned) begin // 字对齐未完成不进入解包 state 4d0; end else begin // 解包主状态机校验帧头比对行号然后搬运像素到输出 FIFO if (state 4d1 rx_byte 8hEB) begin state 4d2; // 收到帧头第一字节 end // 行号比对失败时强制重新同步 end end endmodule这种实现还有一个隐藏细节接收端输出 DE 不能简单用pix_valid代替因为行缓存 FIFO 读侧需要一个「先预读几个像素再拉高 DE」的过程否则生成的时序会有毛刺后级显示设备会丢行。做法是在 FIFO 读侧做水位检测水位超过整行的四分之一再开始输出保证读过程不中断。3.5 音频嵌入与抽取藏在消隐区的采样点音频不单独占一条传输通道而是按固定间隔塞进视频行消隐区这样复用的时候不必为音频多开一路收发器。发送端按每视频帧的采样率计算该塞多少个音频采样点比如 48kHz 音频在 60fps 视频下每帧 800 个样点均摊到每一行的包头之后。module audio_embed #( parameter AUDIO_SAMPLE_WIDTH 24, parameter AUDIO_PER_FRAME 800 )( input wire pix_clk, input wire aud_clk, input wire aud_rst_n, input wire [AUDIO_SAMPLE_WIDTH-1:0] aud_sample_in, output reg [AUDIO_SAMPLE_WIDTH-1:0] aud_sample_to_pkt, output reg aud_valid_to_pkt ); reg [15:0] aud_cnt; reg [15:0] aud_fifo_rd_addr; // 音频采样在 aud_clk 域写入 FIFOpix_clk 域按帧均匀读出 always (posedge pix_clk or negedge aud_rst_n) begin if (!aud_rst_n) begin aud_cnt 16d0; end else if (aud_cnt AUDIO_PER_FRAME) begin aud_cnt aud_cnt 1b1; aud_valid_to_pkt 1b1; end else begin aud_valid_to_pkt 1b0; end end endmodule这里跨了aud_clk和pix_clk两个时钟域音频 FIFO 必须设成异步读写作且读速率稍微留余量避免长时间运行后累积误差导致 FIFO 溢出或下溢。接收端抽取后同样过异步 FIFO再按本地音频时钟读出还原 I2S。爆音和卡顿基本都是这里出了问题后面排查章会专门讲。4. 工程结构跑通拿到源码后的仿真、上板与调整步骤4.1 拿到源码后先看目录这份源码的目录结构是典型的 FPGA 工程布局RTL 和仿真分开约束独立放在syn目录下。aoa_link/ ├── rtl/ │ ├── vid_capture.v # 视频输入采集 │ ├── pkt_tx.v # 发送端打包状态机 │ ├── pkt_rx.v # 接收端解包状态机 │ ├── gt_wrapper.v # 高速收发器封装 │ ├── audio_embed.v # 音频加嵌 │ ├── audio_extract.v # 音频抽取 │ ├── async_fifo_wrapper.v # 异步 FIFO 封装 │ └── aoa_link_top.v # 顶层连线时钟复位管理 ├── sim/ │ ├── tb_top.v # 顶层测试平台 │ ├── tb_vid_gen.v # 视频激励生成器 │ ├── tb_aud_gen.v # 音频激励生成器 │ └── run.do # 仿真脚本 ├── syn/ │ ├── clk.xdc # 时钟约束 │ ├── pin.xdc # 引脚约束 │ └── impl.tcl # 综合实现脚本 └── doc/ └── link_protocol.md # 协议帧格式说明顶层aoa_link_top.v只做实例化和连接不带任何业务逻辑这是判断一个 FPGA 工程是否规范的第一标准。时钟复位管理也放在顶层外部晶振进来先过 PLL 分频出像素时钟、系统时钟复位则用异步复位同步释放电路处理。仿真是测试重点run.do脚本把波形和断言全部配置好拿到工程第一件事是先跑仿真而不是直接上板。4.2 仿真测试怎么跑仿真平台里最核心的是测试断言不只看波形而是让 testbench 自动检查协议正确性。下面这段是tb_top.v的关键部分模拟 1080p60 输入并自动核对接收端输出。module tb_top; reg pix_clk; reg sys_clk; reg rst_n; // 时钟生成148.5MHz 像素时钟156.25MHz 系统时钟 initial begin pix_clk 0; sys_clk 0; rst_n 0; #100 rst_n 1; end always #3.367 pix_clk ~pix_clk; // 148.5MHz always #3.2 sys_clk ~sys_clk; // 156.25MHz // 视频激励循环产生连续帧每帧 1920x1080 tb_vid_gen u_vid_gen ( .pix_clk (pix_clk), .vid_data_out (vid_data), .vid_de_out (vid_de), .vid_vs_out (vid_vs), .vid_hs_out (vid_hs) ); // 顶层 DUT发送端 接收端直连模拟光纤回环 aoa_link_top u_dut ( .pix_clk (pix_clk), .sys_clk (sys_clk), .rst_n (rst_n), .vid_data_in (vid_data), .vid_de_in (vid_de), .vid_vs_in (vid_vs), .vid_hs_in (vid_hs), .txp (txp), .txn (txn), .rxp (txp), .rxn (txn) // 让 RTL 级直连 ); // 接收端输出校验 always (posedge pix_clk) begin if (rx_vs_out rx_de_out) begin if (rx_pixel_out ! expected_pixel) begin $error(Pixel mismatch at frame %0d line %0d, frame_cnt, line_cnt); end end end endmodule仿真时把收发器 IP 换成 RTL 直连模型txp/txn直接接到rxp/rxn跑的是纯逻辑功能验证不涉及模拟电路。注意#3.367和#3.2两个时钟周期故意设成不成整数倍就是为了让异步 FIFO 真正工作在跨时钟场景下很多只在仿真里暴露的丢数据问题就是这么被逼出来的。跑完仿真重点看三个统计值CRC 错误计数应该为 0、帧号连续无跳跃、音频 FIFO 水位在固定范围内波动。这三个指标同时达标逻辑功能才算过关。4.3 上板验证步骤与信号观察仿真通过只是第一步接着按下面的顺序上板每一步都有明确的通过标准。先烧一个只含收发器回环的 bit把 TX 差分对通过同轴跳线环到 RX跑 PRBS 误码测试确认物理层无误码。加载完整工程输入端接测试图案发生器不上摄像头观察接收端屏幕是否有彩色条纹图案正常滚动。用在线逻辑分析仪抓接收端关键信号确认字对齐锁定、解包状态机停留在预期状态。接真实摄像头和扬声器连续运行一小时统计 CRC 错误和音频卡顿次数。上板调试时在线逻辑分析仪的观察清单如下信号含义正常期望值rx_byte_aligned接收端字对齐状态常高rx_crc_err_cntCRC 错误计数长时间不增长pkt_rx_state解包状态机当前状态稳定在 payload 状态audio_fifo_level音频异步 FIFO 水位始终在深度的 20%~80%fifo_full/empty视频行缓存标志满/空不能长时间置位4.4 关键参数怎么改分辨率、帧率变了并不只是改一个数值。需要同步调整的参数形成一个联动关系参数位置1080p60720p60改错后果PIX_CLK_MHZ时钟约束148.574.25采集计数全部错乱MAX_PIXELSpkt_tx/pkt_rx19201280行长不匹配接收端黑屏FRAME_LINESVS 计数器1080720帧号错位AUDIO_PER_FRAMEaudio_embed800800音频抽帧比例错改参数时最容易翻车的是只改MAX_PIXELS忘记改时钟约束或者改了像素时钟但顶层 PLL 配置没同步更新。正确的改法是从时钟约束开始先确认目标分辨率对应的像素时钟频率更新 PLL 配置再回到 RTL 参数里面逐一同步。凡是和行长、帧长相关的参数发送端和接收端必须一起改最好把它们提取到同一个参数头文件里从源头避免两边不一致。5. 现场排查与避坑光端机联调中最常见的 5 个问题5.1 画面花屏、斜向滚动条纹现象接收端屏幕出现大量噪点或图像整体斜向滚动偶尔能看清局部轮廓但马上又乱掉。原因收发器接收侧字对齐没有锁定。光纤或者差分线质量差、收发器配置不对、8B/10B 编码后的字节边界找不到都会导致这种情况。斜向滚动特别典型说明字节流错位了固定字节数接收端把「半个像素」当成了完整像素输出。解决先回环排除物理层。断开远端设备把发射端差分对用短跳线直接环回接收端PRBS 误码率必须为 0。然后查rx_byte_aligned信号是否为高如果时高时低检查参考时钟是否干净、光模块的 LOS 信号是否抖动。最后确认收发器 IP 里 RX 数据位宽和pkt_rx模块期望的字节流宽度一致位宽不匹配是花屏最常见的隐性原因。5.2 黑屏但发送端状态机正常跑现象摄像头输入有信号发送端在线逻辑分析仪里能看到打包状态机在正常循环但接收端屏幕完全黑屏。原因很可能不是链路问题而是像素时钟域到系统时钟域的行缓存 FIFO 读侧「读空」。打包状态机开始读时行缓存根本没写满一行于是整包数据里有效像素只有一半接收端按完整行解码就失败了。解决给行缓存 FIFO 的读侧加水位判断。常见做法是设一个READ_THRESHOLD值取整行像素的 1/4水位达到阈值才允许打包状态机启动。调试时同时抓fifo_wr_count和fifo_rd_count确认启动读时写侧已经积累足够数据。这个坑在改分辨率后特别容易复发因为水位阈值是固定的行长变了但阈值没跟着变。5.3 音频周期性爆音、声音断断续续现象画面完全正常但扬声器每过一两秒就出现一声爆音或者在话音中段突然卡顿半拍。原因音视频时钟不同源。视频像素时钟来自视频源晶振音频采样时钟来自本地音频晶振两个频率标称值一样但实际存在微小偏差。长久运行后音频 FIFO 要么写满溢出丢采样点要么读空下溢重复旧采样点表现出来就是周期性爆音。解决音频 FIFO 做成异步读写读侧时钟用本地音频采样时钟写侧时钟用视频像素时钟——不能用同一个时钟覆盖两边。FIFO 深度至少大于一个视频帧对应音频样点数48kHz、60fps 时约为 800 个防止帧内抖动越过边界。上板验证时连续跑一小时用计数器统计 FIFO 上溢/下溢次数正常应为 0。注意这个计数器只能用测试模式统计交付版本里不要留这种计数器。5.4 改完分辨率后整个链路无画面现象把工程从 1080p 改成 720p重新综合上板后发送端设备正常、光模块亮但接收端不管怎么重启都是黑屏。原因多数是发送端和接收端的打包参数不同步。MAX_PIXELS改了但pkt_rx里对应的行宽阈值没改接收端状态机按旧行宽等像素永远等不到结束条件或者帧间隔时序变了接收端一直处于重新同步状态。解决把发送端和接收端共享的参数定义收敛到同一个头文件避免两处各自定义。改参数后先跑仿真用带断言的行计数器检查接收端line_len_ok标志。上板时在接收端加一个帧丢失计数器如果持续累计增加优先怀疑参数不同步而不是物理链路。5.5 长时间运行后误码率上升甚至断链现象设备上电前半小时一切正常之后偶发画面闪断再往后误码增多光模块 LOS 灯开始闪烁。原因热插拔、光纤接头污染、光模块温度漂移是三大元凶。光纤活动接头用了几百次后端面磨损插入损耗变大光模块工作温度升高后灵敏度下降有时单纯就是接头没插到位上电振动后松动。解决工程代码里做两件事。一是对光模块的 LOS 信号做消抖检测连续拉高超过一定时间就自动对收发器发起重新训练而不是一直处于损坏状态二是把收发器的接收均衡参数留出调节接口在调试时可改写寄存器值。上板前检查光纤端面清洁度和插入深度这属于积累经验教训后形成的条件反射。6. 二次开发先做四路复用与双向管理通道拿到这套单向链路代码后最常见的改造需求是扩展成四路视频复用同时加一条低速反向管理通道。拆解下来并不复杂核心思路是在帧头之后加一个CHANNEL_ID字段接收端解包后按通道号分发到四个独立输出 FIFO。改造点集中在三个模块。发送端pkt_tx增加 2bit 通道号参数每路视频通道独立例化一个打包模块由仲裁器轮询四路 FIFO 的非空状态接收端pkt_rx解出通道号后把像素写入对应通道的行缓存。这里多发带宽是关键约束四路 1080p60 需要约 12.8Gbps单 lane 收发器带宽不够做法是用两条 lane 或者降低子分辨率实际工程选择先将每路降成 1080p30 再打包。反向管理通道利用的则是收发器的双工特性。视音频正向光纤只走一路光反向可以在同一根光纤上叠加一路低速管理信号打包时每帧保留 8 字节冗余槽位专门承载 RS232 或网络调试数据接收端抽出来经 FIFO 转成串口。这个槽位不用额外带宽代价是每帧多 8 字节开销对视频码流完全没有感知影响。验证不能只在板子上跑一遍完事我会准备一张测试矩阵四路同时输入不同彩条图案反向管理通道同时收发数据连续运行 4 小时统计每路 CRC 错误和音频 FIFO 水位。之前一次改造里我忽略了反向数据和视频帧号的对齐结果视频正常、反向通道偶发乱码最后发现是槽位解析按字节对齐而不是按帧对齐导致的偏移。从那以后我每次改完链路都强制走一遍完整回环脚本先 PRBS 误码、再音视频同步、最后跑连续老化这套流程救了我很多次希望帮到你。本文还有配套的精品资源点击获取
