FPGA视音频光端机工程：一芯光纤同时跑视频音频的完整实现

简介：基于现场可编程门阵列（FPGA）的视音频光端机完整工程代码，适合FPGA开发工程师、视频监控系统集成人员与通信设备研发者参考，用于解决长距离多路视音频信号实时传输和系统集成问题。代码经实际部署验证并成功商业化，覆盖多路模拟视频输入适配、多路音频编解码、电话接口、以太网通信及开关量控制等核心功能，内部模块划分清晰，接口约束、时钟配置与编译脚本一并提供，可直接作为二次开发或产品改版的基础。资源共198个文件，以HDL源码、Xilinx工程约束与工程文件、综合映射报告、配置固化文件（bit/bin/mcs）为主，压缩包约1.4MB，体量紧凑但目录结构完整，适合快速导入仿真与上板调试。已有491人学习下载，对正在设计光纤视音频传输链路或研究多协议集成的开发者，这套代码既能提供稳定的功能框架，也能给出芯片级排错思路，尤其适合搭建监控级视音频光端机原型。

1. 视音频光端机代码：这套FPGA工程能让你一芯光纤同时跑视音频

某次现场活动，机位在舞台最里面，导播间在距离两百米外的音控室。HDMI 线最长只能拉十几米，用网络延长器又怕延迟和兼容性问题。最后换上基于 FPGA 的视音频光端机代码：发送端把摄像机输出的视频和音频打成数据帧，混入 RS232 控制通道，用一根单模光纤送到接收端，画面和声音几乎零延迟。这套代码不是常见的上位机或单片机程序，而是一整个可综合、可上板的 FPGA 工程，覆盖从视频输入采集、音频嵌入、帧复用、8B/10B 编码到高速收发器输出光信号的完整链路。适合准备做长距离视音频传输设备的硬件工程师，也适合想把 FPGA 高速串行接口彻底弄明白的开发者。下面按架构设计、核心模块、踩坑记录和改造方法四个部分拆开讲。

2. 系统架构与目录结构：一条光纤里怎么装下视频、音频和辅助数据

2.1 三层架构：物理层、链路层、业务层各管什么

这个工程在顶层划分上很有代表性，把整个系统拆成业务层、链路层、物理层三层。业务层负责用户能感知的内容：视频像素流、音频采样、辅助控制字符。它完全不关心数据是怎么变成光信号的，只负责在合适的时钟沿把数据送到下一层的接口上。链路层解决数据和物理传输之间的问题，包括 8B/10B 编码、帧同步、空闲码插入、错误检测。物理层直接面对光模块和 FPGA 的高速收发器，负责并串转换、时钟恢复、CDR 均衡等。

三层之间用固定位宽的接口连接。业务层向链路层提供 28 位并行总线，其中高 4 位是类型标识，低 24 位是有效负载。链路层把 28 位包拆成三个 8 位字节，分别做 8B/10B 编码，最终交给物理层。这么分层最直接的收益是「可替换性」：如果临时更换光模块，或者从一路光口扩成两路，物理层的收发器配置要改，但业务层和链路层几乎不用动。反过来，如果要把视频格式从 RGB 改成 YCbCr，只需要改业务层，链路层照常工作。

分层也带来一个明显代价：层与层之间要处理时钟域，稍不注意就会引入亚稳态。这个工程的做法是层与层之间尽量用同步 FIFO，把绝大多数逻辑统一到主时钟域；只有物理层与链路层之间才真正存在异步时钟，那个口子上用异步 FIFO 加两级同步器。通信设备里标准做法是让每层各管各的时钟，但这个工程为了调试方便，选择牺牲一点布局灵活性，换来明确的时序关系。对光端机这种数据流向固定的场景，这种取舍是合理的。

2.2 工程目录结构：每个文件负责什么

拿到这个工程，第一件事先看目录。src/tx 和 src/rx 分别放发送端和接收端逻辑，这样的划分比按模块堆在一堆更容易维护，因为光端机本质上是两个方向的对称设计，改接收端时不会误碰发送端代码。

fpga_av_oltx/ ├── src/ │ ├── tx/ │ │ ├── video_capture.v │ │ ├── audio_embed.v │ │ ├── mux_frame.v │ │ ├── encoder_8b10b.v │ │ └── gig_tx.v │ └── rx/ │ ├── gig_rx.v │ ├── decoder_8b10b.v │ ├── demux_frame.v │ └── video_output.v ├── ip/ # 时钟向导、高速收发器IP ├── sim/ │ └── tb_top.sv ├── constraints/ │ ├── top.xdc │ └── timing_ddr.xdc └── scripts/ └── build.tcl

发送端的 video_capture.v 负责把外部并行视频数据和数据使能信号打拍对齐，并拼上同步标志。audio_embed.v 把来自 I2S 或 PDM 接口的音频采样打包，按「行消隐」的时机插入到视频流空隙。mux_frame.v 是组帧核心，决定当前总线上传的是视频包、音频包还是空闲同步包。encoder_8b10b.v 实现查表式 8B/10B 编码，保证直流平衡和时钟恢复。gig_tx.v 是高速收发器发送端的封装，对外只暴露极简的复位和使能接口。

接收端对应的模块是 gig_rx.v、decoder_8b10b.v、demux_frame.v 和 video_output.v，逻辑上正好是发送端的逆过程。video_output.v 除了恢复视频和音频之外，还要按原来的时序输出数据，所以里面放了一个输出 FIFO 和一套场同步信号生成器。

sim 目录里只有一个 tb_top.sv 测试平台，它不是给各个模块单独喂激励，而是通过一个参数化的链路模型把发送端和接收端串起来，中间可以注入误码、插入毛刺、模拟频差，这样在综合之前就能把整条数据通路跑通。这个平台的价值在实际排错时特别明显——上板后遇到问题，先回到 tb_top 复现，比拿示波器戳引脚快得多。

constraints 目录下分两个 xdc 文件：top.xdc 里面是管脚位置和电平标准；timing_ddr.xdc 名字带 DDR，实际是约束工程内部跨时钟域的同步逻辑，尤其是异步 FIFO 读写指针路径。新手喜欢把所有约束塞进一个文件，工具也认，但后期维护会发疯。这个工程拆开是很好的习惯。scripts/build.tcl 负责自动化编译，在 CI 里调用综合、布局布线，并生成时序报告。脚本里有两个关键参数：FPGA 器件型号、工具版本路径。因为不同版本工具工程数据库格式有差异，脚本会先清理中间文件再重建，避免旧缓存干扰。

2.3 关键接口与时序关系：发送端和接收端怎么握手

业务层和链路层之间的主要接口可以整理成一张表：

这个接口设计的核心是 video_de 对齐问题。video_data 和 video_de 必须在 video_clk 的上升沿同时被链路层看到，任何一方提前或延后半拍，都会被当成不同像素。因此 video_capture 里用了与数据路径完全相同的打拍级数来做 de 延迟，这不是随手习惯，而是经过时序检查的强制要求。audio_data 与 video_clk 本来是异步来源，audio_embed 模块内部先做一个异步 FIFO，把音频采样跨到视频像素域，再等待行消隐窗口插入。这里不能直接把音频信号接到组帧器，否则组合逻辑会稳定地输出竞争值。

tx_frame_vld 是链路层的写请求，跟 tx_frame_out 同步变化。mux_frame 在每个时钟周期更新 frame_vld，不产生毛刺。为了让接收端能定位帧边界，链路层每帧开头会插入一个或多个同步码字，这样即使发生误码，接收端也能在若干时钟周期内重新锁定。

3. 核心模块拆解：一行视频流水线如何变成一束激光

3.1 视频输入采集：让并行视频数据稳稳进入内部逻辑

发送端最前面的 video_capture.v 做的事情可以概括成一句话：外部视频源的数据是自由运行的，而内部组帧逻辑需要对齐的、带使能的数据，问题在怎么用打拍解决。

module video_capture #( parameter DW = 24 )( input wire rst_n, input wire video_clk, input wire [DW-1:0] video_data, input wire video_de, output reg [DW:0] mux_wr_data, output reg mux_wr_en ); reg [DW-1:0] data_buf; reg de_dly1; reg de_dly2; always @(posedge video_clk or negedge rst_n) begin if (!rst_n) begin data_buf <= {DW{1'b0}}; de_dly1 <= 1'b0; de_dly2 <= 1'b0; end else begin data_buf <= video_data; de_dly1 <= video_de; de_dly2 <= de_dly1; end end assign mux_wr_data = {data_buf, de_dly2}; assign mux_wr_en = de_dly2; endmodule

为什么要把 de 打两拍？因为 data_buf 是 video_data 打一拍后的结果，de 信号如果只打一拍，与 data_buf 对齐的是「最新的 de」而不是「当时的 de」。这里使用两个触发器 de_dly1 和 de_dly2，让 de 比数据晚一个时钟，正好和 data_buf 同一拍。mux_wr_data 的最高位就是 de_dly2，等于把数据有效标志内嵌进码字，下游组帧器看到最高位为 1 就认为当前是视频像素。

参数 DW 在工程中使用 24，对应 4:4:4 RGB。如果改成 10 位或 12 位采样，需要同步调整下游的帧格式以及收发器线速率。有一个容易翻车的地方：如果视频源不是像素时钟同步输出，而是突发 burst，必须在 video_capture 中加一个小 FIFO 做缓冲。这个工程假设视频源来自常见的 HDMI 转换芯片或 SDI 接收芯片，它们输出的视频数据和 de 天然与像素时钟对齐，所以省掉 FIFO。用寄存器直接采样时，一定要做 setup/hold 时序检查，像素时钟超过 200MHz 就要改用 IOB 寄存器或原语来采集，否则会采到毛刺。

3.2 音频嵌入与时分复用组帧：数据怎么排进同一个容器

音频采样率 48kHz，每采样 16bit，一秒钟约 1.5Mbit 数据量。相比之下，1080p60 的像素数据率是 1.5Gbit 以上。如果把音频单独占一条通道，浪费光纤带宽。合理的做法是把音频采样分割成若干小包，插进视频行消隐的间隙里。audio_embed.v 先完成时钟域转换，再交给 mux_frame.v 复用。

mux_frame.v 的核心逻辑是每个时钟周期决定当前总线上放什么内容，优先级是视频包优先、音频包次之、最后是空闲同步包。

module mux_frame #( parameter PAYLOAD_BITS = 28, parameter AUDIO_CH = 4 )( input wire clk, input wire rst_n, input wire [PAYLOAD_BITS-1:0] video_in, input wire video_vld, input wire [15:0] audio_in, input wire audio_vld, output reg [PAYLOAD_BITS-1:0] frame_out, output reg frame_vld ); localparam ID_VIDEO = 4'd1; localparam ID_AUDIO = 4'd2; localparam ID_SYNC = 4'd3; reg [15:0] audio_fifo [0:7]; reg [2:0] audio_wr, audio_rd; always @(posedge clk or negedge rst_n) begin if (!rst_n) begin audio_wr <= 0; audio_rd <= 0; frame_out <= 0; frame_vld <= 0; end else begin if (audio_vld) begin audio_fifo[audio_wr] <= audio_in; audio_wr <= audio_wr + 1'b1; end if (video_vld) begin frame_out <= {ID_VIDEO, video_in[PAYLOAD_BITS-5:0]}; frame_vld <= 1'b1; end else if (audio_wr != audio_rd) begin frame_out <= {ID_AUDIO, audio_fifo[audio_rd]}; frame_vld <= 1'b1; audio_rd <= audio_rd + 1'b1; end else begin frame_out <= {ID_SYNC, {PAYLOAD_BITS-4{1'b0}}}; frame_vld <= 1'b1; end end end endmodule

优先逻辑里，video_vld 是真正的「是否传视频」标志。空闲时不发空包，而是发 ID_SYNC 同步包，并让 frame_vld 保持有效，这样接收端在看不到视频和音频时仍能通过同步包维持时钟恢复和帧对齐。audio_wr 和 audio_rd 构成一个 8 深度环形 FIFO，这里隐含一个假设：音频包写入频率远低于视频行消隐出现的频率，FIFO 不会溢满。如果音频通道数增加到 8 路或采样率升到 192kHz，FIFO 深度要相应提高，否则会丢音频。

ID 字段只用了 4 位，视频和音频各占一种码型，还剩下很多组合。例如需要传时间戳或 Tally 信号时，加一个 ID_AUX 即可。但注意，加码型时接收端解帧的优先级和路由必须同步更新，否则旧帧格式的解码结果会错位。

3.3 8B/10B 编码与并串转换：信号上光纤前的最后工序

8B/10B 编码的意义在于让串行数据流里不出现连续的 0 或 1，接收端才能从数据里恢复时钟。这个工程没有重新发明编码算法，而是用查表法把输入字节映射成 10 位码字。查表法在 FPGA 里非常高效，综合后就是几个 LUT 和 MUX，延时稳定。

wire [9:0] code_a, code_b, code_c; encoder_8b10b u_enc_a ( .clk(clk), .din(frame_out[7:0]), .dout(code_a) ); encoder_8b10b u_enc_b ( .clk(clk), .din(frame_out[15:8]), .dout(code_b) ); encoder_8b10b u_enc_c ( .clk(clk), .din(frame_out[23:16]), .dout(code_c) );

三路编码并行的原因是单路 8B/10B 码表最大吞吐约 1Gbps，不能满足 3G 以上视频速率。工程把 28 位包拆成低 24 位有效数据，每 8 位一组编码成 10 位，共 30 位，再通过高速收发器的并行输入端口发送。注意 frame_out 是高 4 位 ID 在前，低 24 位在后，编码时只编低 24 位，ID 不参与编码，因为接收端解帧时不需要 ID 的直流平衡保证，这样可以减少一次查表延时。

线速率的计算对理解工程非常关键。以 1080p60 4:2:2 视频为例：像素数据率 148.5M 像素/秒，每像素 20 位，原始速率 2.97Gbps；加上音频、同步和管理开销，再乘 8B/10B 的 10/8 系数，线速率取 3.75Gbps 是常见选择。这个值由 GTP/GTX 的线速率选项直接生成，参考时钟取 150MHz，PLL 倍频 25。如果把视频换成 4K60，原始速率接近 12Gbps，单条 GTH 线速率不够，就必须用多条通道并联，mux_frame 的并行度也要同步扩大。

3.4 接收端反向处理：时钟恢复、解码、解帧

接收端的高速收发器先做 CDR，从恢复的串行比特流中提取时钟和数据，再按 10 位对齐解出编码码字。这里最容易忽略的是字节对齐问题——8B/10B 码流没有明确字节界线，收发器通过查找特殊 K 码（如 K28.5）来对齐。工程的 gig_rx.v 启用了接收端的 comma alignment 功能，解帧器只要发现 ID_SYNC 就重置帧计数器，避免码字错位。

之后 decoder_8b10b 按码表恢复数据，demux_frame 根据 ID 把数据分别送到视频 FIFO、音频 FIFO 和辅助输出。由于收发器恢复时钟与本地视频时钟存在 PPM 级差异，这两个 FIFO 都设计为异步 FIFO。工程里视频 FIFO 深度设为最小两帧，用来容忍源端和输出端场同步频率的微小漂移。如果检测到上溢或下溢，就直接丢掉当前帧并等待下一个同步头，宁可丢一帧也不输出撕裂画面。

4. 避坑与排查：从丢帧到花屏，四个高频问题一次说清

4.1 现象：光纤接上后接收端偶发无图，重新上电又恢复

第一次遇到这个问题时，第一反应是光模块没插紧或者光纤损耗大，但换光模块还是复现。后来用示波器看恢复时钟，发现无图时时钟抖动明显偏大，同时发送端光模块温度升高后光功率下降。这就是典型的光模块温度特性导致链路劣化：激光器发光效率随温度升高而下降，如果没有自动光功率控制，光信号到接收端会低于灵敏度门限。

解决分两步。第一步在发送端读光模块的 DAC 温度寄存器，用 PID 调整激光器偏置电流，保证光功率恒定；第二步在接收端把 CDR 的均衡模式从手动改成自适应，以补偿不同光纤长度的衰减。改完做老化测试，连续 48 小时没有掉链。日常排查时，如果看到接收端指示灯闪烁但没锁住，优先用光功率计看接收光功率是否在模块灵敏度范围内，再查发送端温度补偿。

4.2 现象：综合时序全绿，上板跑几分钟出现单比特错码

这个问题最气人，因为工具反馈一切正常。根因在跨时钟域约束缺失。发送端里像素时钟、组帧时钟、编码器输出时钟是三个独立时钟域，它们之间通过 FIFO 交换数据。工具默认把所有时钟当同步时钟处理，会优化跨时钟路径，但这种优化依赖静态时序分析的假设，实际工作时跨时钟路径上存在亚稳态风险。

解决方法是列出真正的异步时钟域，对所有异步 FIFO 中的同步器路径添加 set_max_delay 约束，并保证每个同步器是两级触发器结构。

set_max_delay -datapath_only 3 [get_cells -hier -filter {NAME =~ *sync_ff*}]

这条命令把异步同步器路径上的组合延迟限制在 3ns 以内。加上约束后重新跑布局布线，工具会开始诚实报告真实路径，红灯可能变多，但这才是真实时序。上板跑 24 小时压测后，误码彻底消失。经验是听「时钟是异步所以不用约束」这种说法，正式因为它猜不出来，才需要显式告诉工具哪些路径是异步的、哪些是同步的。

4.3 现象：图像正常但音频伴随「噼啪」爆音

爆音的直接听感是偶发咔嚓声，换上耳机更明显。用逻辑分析仪抓音频输出数据，发现某一段采样值重复或跳变。原因在于音频采样和视频帧之间没有严格对齐：发送端在行消隐里插音频包时，如果行消隐窗口因为场同步抖动而变短，一个完整音频包可能被拆成两段，接收端解包时只读取半个包。

针对性解决是给音频通道加「包完整性」检查。发送端把每个音频包加上长度字段和 CRC，接收端解帧时若检测到长度不符就丢弃整个包，并保持上一次的音频输出电平，避免重复采样。这个工程后来又把音频 FIFO 改成双缓冲，让读写时钟彻底分离，才从根上解决时域碎片化。如果你也遇到爆音，先检查音频时钟和视频时钟是否同源，不同源时必须用异步 FIFO，绝不能靠行消隐时序硬扛。

4.4 现象：仿真正确但上板显示色彩条纹滚动

这个问题经常被归为玄学，其实是复位域交叉。仿真里一个全局复位信号能同时在所有寄存器生效，但真实器件中，同一个 rst_n 到达不同触发器的布线长度不同，导致部分模块先退出复位、部分后退出。若某模块先启动开始写总线，而接收模块还没复位完成，总线上出现半高电平，表现出来就是条纹滚动。

解决办法是给每个时钟域都做一个独立的复位同步器，用同步后的复位去触发该域逻辑。具体做法是两级寄存器级联，复位释放时与时钟上升沿对齐。这里强调一点：复位同步器的来源不能是按键或 DIP 开关，必须经过去抖；若使用 MMCM/PLL，则等待 locked 信号有效后再释放复位。改完这处，色彩条纹再没出现过。从仿真转上板时，先检查复位、再检查时钟探测器是否起振，能省一半调试时间。

5. 二次开发：从 1080p 到 4K、从单路到多路，怎么改不翻车

5.1 分辨率升级：把像素时钟、数据位宽和线速率一起改

以 720p 升级到 1080p 为例：像素时钟从 74.25MHz 提高为 148.5MHz，video_capture 的 DW 从 20 改 24，mux_frame 的 PAYLOAD_BITS 从 24 改成 28，编码器并联路数同步调整。线速率跟着带宽公式走：LineRate = PixelRate x BitsPerPixel / 8 x 10 / LaneCount。所以不能只改一个参数，必须通盘检查。改完先编译，看资源报告里 LUT 和 FF 是否增长剧烈，如果 FF 占用超过 60%，要考虑换更大芯片或降低位宽冗余。

5.2 增加第二路视频通道：ID 扩展和带宽预算

多路复用时，把 mux_frame 中的 ID_VIDEO 拆成 ID_VIDEO0 和 ID_VIDEO1，各自绑定不同的数据来源；接收端解帧时按 ID 路由到对应的 FIFO。同时把空闲同步包周期缩短，给第二路视频让出时隙。如果两路视频加起来需要的吞吐量超过当前线速率，有两条路：一是提高收发器线速率，比如从 3.75Gbps 升到 6Gbps；二是用波分复用，把不同视频放到不同光波长上，那是成本更高的方案。对四路 SD-SDI 的场景，用一条 GTH 线速率的时分复用就足够。

5.3 验证流程：改动之后必做的三项检查

每次改完工程，都会强制走一遍完整链路仿真、时序收敛、光纤回环测试。链路仿真用 tb_top 把发送端和接收端串起来，注入白噪声和频率偏移；时序收敛用 build.tcl 自动跑，看 setup/hold 裕量是否大于 100ps；回环测试用短光纤把 TX 和 RX 直连，发 PRBS 伪随机码流，统计误码率，再接入真实视频源验证图像和音频。这套流程虽然啰嗦，但能过滤掉九成低级错误。从那以后我每次改完工程都强制走这三步，不再相信「只改一个参数不会出问题」的侥幸心理。希望帮到你。

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