2. 开发环境搭建：Vivado/Quartus安装、仿真工具配置、版本控制(Git)设置、项目目录结构规划
说实话，很多做FPGA的朋友，尤其是刚入行的，往往把精力全放在写代码上。环境搭建？随便装个软件就开干。嗯，我当年也是这样。结果呢？项目做到一半，仿真跑不起来，版本乱成一锅粥，目录结构更是惨不忍睹。后来我花了整整两天时间，才把一套标准化的环境搭好。今天我就把这套经验，原原本本讲给你听。
核心观点：开发环境不是「能用就行」，而是「高效、可复现、可协作」。一个好的环境，能帮你省下至少30%的调试时间。
2.1 工具链选择：Vivado vs Quartus
先聊工具。目前主流的两大FPGA厂商，Xilinx（现在叫AMD）和Intel（原Altera），各自有自家的IDE。Vivado对应Xilinx，Quartus对应Intel。我个人习惯是，如果项目用Xilinx的芯片，就用Vivado；用Intel的，就用Quartus。听起来像废话？其实不是。有些团队为了省钱，用盗版或者老版本，结果踩坑无数。
我在项目中遇到过一件事：一个同事用Vivado 2018.2编译一个高速SerDes设计，结果时序一直不过。折腾了两周，最后发现是工具版本的一个已知bug，升级到2019.1就解决了。所以我的建议是：尽量用最新稳定版，至少是近两年内的版本。
| 工具 | 适用芯片 | 推荐版本 | 安装包大小 |
|---|---|---|---|
| Vivado | Xilinx 7系列、UltraScale、Versal | 2023.1 或 2024.1 | 约50-80GB（含器件库） |
| Quartus Prime | Intel Cyclone、Arria、Stratix | 23.3 或 24.1 | 约30-60GB（含器件库） |
小技巧：安装时，如果硬盘空间紧张，可以只安装目标芯片对应的器件库。比如你只用Xilinx的Kintex-7，那就只勾选7系列库，能省下30GB空间。
2.2 仿真工具配置
仿真，是FPGA开发中最重要的一环。没有之一。你想想看，代码写完了直接上板？那叫赌博。我见过太多人，仿真随便跑一下就急着综合，结果上板后信号乱飞，查错查到崩溃。
常用的仿真工具有三种：
- Vivado自带的xsim：免费，集成度高，但功能有限。适合小模块验证。
- ModelSim/QuestaSim：业界标准，功能强大，支持Tcl脚本自动化。我主力用这个。
- Verilator：开源，速度快，适合大型系统级仿真。但只支持Verilog/SV，不支持VHDL。
我个人习惯是：小模块用xsim快速验证，系统级仿真用QuestaSim。为什么？因为QuestaSim的波形查看、断点调试、覆盖率分析，比xsim强太多了。有一次我调试一个PLL锁定问题，xsim死活看不出毛刺，换到QuestaSim，一跑就抓到问题——原来是复位信号没同步。
注意：ModelSim和QuestaSim虽然是一家公司的产品，但QuestaSim是高端版，支持SystemVerilog的断言和覆盖率。如果你做高频交易系统，建议直接用QuestaSim。别省那点钱，时间更值钱。
配置仿真环境时，我建议你写一个sim_setup.tcl脚本，把编译库、仿真参数、波形保存都自动化。比如：
# sim_setup.tcl
vlib work
vmap work work
# 编译设计文件
vlog -sv -work work ../src/top.sv
vlog -sv -work work ../src/fifo.sv
vlog -sv -work work ../tb/tb_top.sv
# 启动仿真
vsim -voptargs="+acc" -t 1ps work.tb_top
# 添加波形
add wave -r /*
run 10 us嗯，这样每次改完代码，只需要跑一句vsim -do sim_setup.tcl，就能自动完成所有步骤。省心。
2.3 版本控制：Git设置
说到版本控制，很多FPGA工程师的第一反应是：「FPGA又不是软件，要什么Git？」错。大错特错。我见过一个项目，三个人同时改一个.v文件，最后用U盘拷来拷去，版本号从v1到v20，谁改了什么完全不知道。结果呢？一个bug修了三次，每次都是「修复了之前修复的bug」。
Git不是软件工程师的专利。FPGA项目同样需要。我的做法是：
- 创建仓库：在项目根目录执行
git init。 - 写.gitignore：忽略编译产物、仿真缓存、IP核生成文件等。比如：
# .gitignore
*.log
*.jou
*.str
*.wdb
*.vcd
*.fsdb
xsim.dir/
.cache/
.ip_cache/
*.rpt
*.bit
*.mcs关键点：只跟踪源码（.v/.sv/.vhd）、约束文件（.xdc/.sdc）、脚本（.tcl/.py）、文档（.md/.pdf）。不要跟踪任何编译生成的文件。否则仓库会变得巨大无比，而且每次编译都会产生大量无意义的变更。
我在项目中遇到过一个问题：一个同事把整个Vivado工程目录都提交了，包括几十GB的IP核缓存。结果git clone一次要半小时，而且每次综合后，那些缓存文件都会变化，导致git status永远有未跟踪文件。后来我帮他重写了.gitignore，仓库从50GB降到了200MB。
另外，我建议用分支管理。比如：
main：稳定版本，只合入经过验证的代码。dev：日常开发分支。feature/xxx：新功能分支，比如feature/10g_mac。fix/xxx：bug修复分支。
提交信息要写清楚。别写「fix bug」这种废话。要写「修复FIFO空标志在跨时钟域时的亚稳态问题」。这样三个月后回头看，你还能知道当时改了啥。
2.4 项目目录结构规划
目录结构，看似小事，实则大事。一个混乱的目录，会让你找文件找到怀疑人生。我见过最夸张的，一个项目所有文件全放在根目录，包括.v、.xdc、.bit、.pdf、.docx、.exe……嗯，你没看错，连exe都有。
我的标准目录结构是这样的：
project_name/
├── docs/ # 文档：需求、架构、接口定义
│ ├── spec.md
│ └── interface.xlsx
├── src/ # 源码
│ ├── rtl/ # 设计代码
│ │ ├── top.sv
│ │ ├── fifo.sv
│ │ └── pll_wrapper.v
│ ├── tb/ # 测试平台
│ │ ├── tb_top.sv
│ │ └── tb_fifo.sv
│ └── ip/ # IP核（Xilinx/Intel IP）
│ ├── clk_wiz_0/
│ └── fifo_generator_0/
├── constr/ # 约束文件
│ ├── top.xdc # 时序约束
│ └── pin.xdc # 引脚分配
├── scripts/ # 脚本
│ ├── sim_setup.tcl
│ ├── synth.tcl
│ └── run_all.py
├── sim/ # 仿真输出（不提交到Git）
│ ├── work/
│ └── waves/
├── build/ # 综合/实现结果（不提交到Git）
│ ├── synth/
│ └── impl/
├── .gitignore
└── README.md为什么这么分？说白了，就是关注点分离。源码归源码，约束归约束，脚本归脚本。你找东西的时候，一眼就能定位。而且，这种结构对团队协作特别友好——不同的人可以同时改不同目录，不会冲突。
我的习惯：每个模块的源码，文件名和模块名保持一致。比如fifo.sv里就是module fifo。这样用grep搜模块名时，能直接定位到文件。别小看这个习惯，项目大了以后，找文件能快很多。
2.5 本章知识体系
下面这张图，是我画的一个知识体系结构。你可以把它当作本章的「地图」。看完这张图，你就知道环境搭建这件事，到底覆盖了哪些方面。
这张图把本章的四个核心模块串起来了。工具链是基础，仿真工具是验证手段，Git是协作保障，目录结构是组织方式。四者缺一不可。
最后提醒一句：环境搭建这件事，别想着「以后再说」。我见过太多项目，前期图省事，后期花十倍时间填坑。花半天时间，把环境搭好、目录建好、Git配好，后面几个月你会感谢自己的。
公众号:蓝海资料掘金营，微信deep3321