3. FPGA开发环境搭建与流程：Vivado/Vitis开发套件与工程管理

好，咱们直接进入正题。这一章我打算聊聊FPGA开发环境。说白了，就是你怎么把写好的代码，变成能在板子上跑起来的比特流。很多新手一上来就被Vivado的界面吓住了，其实没那么复杂。我带你走一遍，你就明白了。

3.1 开发套件选择：Vivado vs Vitis

先说说这两个工具的关系。Vivado是主力，负责RTL设计、仿真、综合、实现，最后生成比特流。Vitis呢？它更像是一个“上层应用”的开发环境，专门用来写ARM核上的C/C++代码，或者做AI推理加速。

我个人习惯是：纯逻辑设计用Vivado，涉及PS（处理系统）和PL（可编程逻辑）协同工作时，才打开Vitis。你想想看，如果只是写个简单的图像采集接口，开Vitis反而显得臃肿。

我的小技巧： 在Vivado里把硬件导出为XSA文件，再导入Vitis。这样两个工具各司其职，不会乱。

3.2 完整开发流程：从RTL到比特流

这个流程我走了不下百遍。每一步都有坑，我一个个说。

3.2.1 RTL设计

这是起点。用Verilog或VHDL写你的逻辑。我建议用Verilog，生态好，资料多。写代码时注意模块化，一个模块只干一件事。

// 一个简单的内窥镜图像采集接口
module camera_if (
    input  wire        clk,
    input  wire        rst_n,
    input  wire [7:0]  pixel_data,
    input  wire        pixel_valid,
    output reg  [15:0] frame_data,
    output reg         frame_valid
);
    // 这里写你的逻辑
endmodule

嗯，这里要注意：端口命名要规范。我见过有人把时钟叫“ck”，复位叫“rst”，结果三个月后自己都看不懂。我一般用“clk”、“rst_n”、“_valid”、“_data”这种后缀，一目了然。

3.2.2 仿真

仿真这一步，千万别省。我曾经有个项目，综合实现都没问题，上板子就是不出图像。查了三天，最后发现是仿真时没加复位信号，导致状态机卡死在初始态。从那以后，我每个模块都写一个独立的testbench。

// 简单的testbench
module tb_camera_if;
    reg         clk;
    reg         rst_n;
    reg  [7:0]  pixel_data;
    reg         pixel_valid;
    wire [15:0] frame_data;
    wire        frame_valid;

    camera_if uut (
        .clk(clk),
        .rst_n(rst_n),
        .pixel_data(pixel_data),
        .pixel_valid(pixel_valid),
        .frame_data(frame_data),
        .frame_valid(frame_valid)
    );

    initial begin
        clk = 0;
        forever #5 clk = ~clk;  // 100MHz时钟
    end

    initial begin
        // 测试流程
        rst_n = 0;
        #100 rst_n = 1;
        // 发送像素数据...
    end
endmodule
避坑指南： 我曾经在仿真时发现波形对，但上板子就错。后来发现是仿真用的时钟频率和实际板子不一样。记住：仿真环境要和实际硬件一致，包括时钟频率、复位时序。

3.2.3 综合

综合就是把RTL代码映射成FPGA内部的查找表和触发器。这一步，Vivado会给你一个资源利用率报告。我一般重点关注LUT和FF的使用率，如果超过70%，就要考虑优化了。

资源类型 使用量 可用量 利用率
LUT 1234 53200 2.32%
FF 567 106400 0.53%
BRAM 2 140 1.43%

你看这个表，利用率很低，说明设计很轻量。但如果你的设计里用了大量DSP单元做图像处理，那就要留意DSP48E1的使用率了。

3.2.4 实现

实现包括布局布线和时序优化。这一步最耗时，也最容易出问题。我建议你先跑一次默认策略，看看时序能不能收敛。如果不行，再调整约束或换实现策略。

为什么会时序不收敛？说白了，就是你的逻辑路径太长，或者时钟频率太高。内窥镜图像采集一般跑100MHz左右，只要代码写得规范，基本不会出问题。

3.2.5 生成比特流

最后一步，生成.bit文件。这一步Vivado会做一次完整的检查，包括DRC（设计规则检查）。如果DRC报错，千万别跳过。我见过有人DRC报“未连接时钟”还强行下载，结果板子直接冒烟。

重要： 每次生成比特流前，务必检查DRC报告。特别是时钟域交叉和未约束路径这两项。

3.3 我的工程管理技巧

做FPGA开发，工程管理比写代码更重要。我分享几个实用技巧。

3.3.1 目录结构

我习惯这样组织工程目录：

project/
├── rtl/          # 所有RTL源文件
├── sim/          # testbench和仿真脚本
├── constr/       # 时序约束文件(.xdc)
├── ip/           # 生成的IP核
├── xsa/          # 导出的硬件描述文件
├── bit/          # 生成的比特流
└── doc/          # 设计文档

这样分，找文件特别快。你想想看，如果所有文件都堆在根目录，三个月后你自己都找不到哪个是最终的版本。

3.3.2 版本控制

一定要用Git。我每个工程都初始化一个Git仓库，每次综合实现前都commit一次。这样如果改坏了，可以回滚。我曾经有一次优化时序，把整个状态机改乱了，幸好有Git，一键恢复。

3.3.3 约束文件管理

约束文件（.xdc）是灵魂。我建议一个时钟一个约束，不要把所有约束写在一个文件里。比如：

# clock.xdc
create_clock -period 10.000 -name clk_100m [get_ports clk]

# input_delay.xdc
set_input_delay -clock clk_100m -max 5.000 [get_ports pixel_data*]

这样分开写，后期调试时直接注释掉某个文件就行，不用在几百行约束里翻来翻去。

3.3.4 仿真脚本化

别每次都点Vivado的GUI跑仿真。写个Tcl脚本，一键运行。我常用的脚本：

# run_sim.tcl
open_project ./project.xpr
launch_simulation -mode behavioral
run all
close_sim

在命令行执行 vivado -mode tcl -source run_sim.tcl，就能自动跑仿真。省时省力。

我的习惯： 每次修改RTL后，先跑一遍仿真，再综合。如果仿真没过，绝不进行下一步。这个习惯帮我省了无数调试时间。

3.4 总结

这一章的内容其实就一句话：流程要规范，管理要细致。从RTL到比特流，每一步都有它的意义。别图快，别跳步。我见过太多人因为跳过仿真，最后在板子上花三天找bug。

下一章，我会讲内窥镜图像传感器的接口协议，包括MIPI和LVDS。到时候咱们再细聊。

← 上一章 📖 返回目录 下一章 →