1. 课程导入与体系总览
在 FPGA 项目里,Quartus 往往被当成一个“编译工具”:打开工程、点一下 Start Compilation、等进度条走完、下载到板子上能跑就算结束。但真正进入产品交付阶段后,问题几乎都不出在“能不能编译”,而是出在“这个版本到底对应哪份源码、哪套约束、哪块板卡、哪次测试记录”。同一块开发板上,A 同事烧录的 .sof 能跑,B 同事从 Git 拉下来的同一分支重新编译却时序不过;客户现场反馈的 bit 流无法复现,因为当时用的 Quartus 版本、器件型号、IP 参数都没有记录。这些现象背后,是版本管理与交付管理没有和设计流程绑定在一起。
本课程讨论的对象,是围绕 Intel/Altera Quartus Prime 的 FPGA 项目,从需求确认、RTL 设计、约束编写、综合布局布线、时序收敛、板级验证,一直到固件归档、发布、现场升级与追溯的完整链条。核心目标可以概括为三句话:让每一次编译都可复现,让每一个交付物都可追溯,让每一次变更都可评估。可复现,意味着给定一个版本标签,任何人用记录在案的 Quartus 版本、器件、IP 版本和约束文件,都能得到功能与时序一致的结果;可追溯,意味着从现场的一块板子上的固件,能反查到源码提交、编译日志、测试报告和发布审批;可评估,意味着任何一次改动都能判断它影响了哪些模块、哪些约束、哪些交付物。
全生命周期的四个阶段与关键产物
把 FPGA 项目拆开看,它并不是一条直线,而是“设计—构建—验证—交付”四个阶段循环推进。设计阶段产出 RTL、IP 配置、SDC 约束和引脚分配;构建阶段由 Quartus 完成综合、Fitter、时序分析和汇编,产出 .sof/.pof、.rbf、时序报告和资源报告;验证阶段在板级或仿真环境确认功能与时序,产出测试记录与问题单;交付阶段把固件、文档、版本说明和升级包整理发布,并保留归档。每个阶段的产物都必须带版本标识,否则链条就会断。
常见痛点:为什么“能跑”不等于“能交付”
第一个高频痛点是环境漂移。Quartus 不同版本对同一段 RTL 的综合结果可能不同,IP 核的默认参数也会随版本变化。如果工程里只写了“用 Quartus 编译”,没有锁定具体版本(例如 Quartus Prime Pro 23.4 或 Standard 21.1),半年后换一台机器重新编译,时序余量可能从 +0.3 ns 变成 −0.5 ns。解决办法是在工程根目录放一份环境说明文件,记录 Quartus 版本、器件型号(如 5CGXFC9D6F27C7)、IP 版本和操作系统,并在构建脚本里校验。
第二个痛点是约束与源码脱节。SDC 文件被单独放在某个共享盘,RTL 更新后约束没同步,导致时序分析基于旧时钟定义,报告看起来“全过”,实际板子上却出现亚稳态。约束文件必须和 RTL 放在同一个 Git 仓库、同一次提交里,任何时钟改动都要同时改 SDC 并重新跑 STA。
第三个痛点是交付物没有唯一标识。现场返回一块板子,上面烧的是三个月前的 .pof,但没人知道它对应哪次提交、哪份测试报告。解决方式是在构建时自动生成构建号(例如 20250612-1432-a3f9c1),把构建号写入固件版本寄存器,同时归档编译日志、时序报告和测试记录。这样从板子读出版本号,就能反查到全部信息。
2.3.20250612-1432-a3f9c1。主版本对应架构级变更,次版本对应功能增减,构建号由 CI 自动生成,保证全局唯一。整体框架:三条主线拧成一股绳
把上面的内容收拢,本课程后续章节会围绕三条主线展开。第一条是设计主线:RTL、IP、约束、引脚如何组织,工程文件如何做到可移植。第二条是版本主线:Git 分支怎么分、版本号怎么定、Quartus 工程如何与代码同源、构建如何自动化。第三条是交付主线:交付物清单包含什么、发布审批怎么走、固件如何校验、现场如何追溯。三条主线不是并列的,而是通过“构建号”这个纽带串在一起——设计产出源码提交,版本管理给提交打标签,构建产生带构建号的固件,交付把固件和记录一起发布。
下面给出一份可直接参考的最小交付物清单,适用于中小规模 FPGA 项目。字段可根据项目实际增减,但建议至少保留“版本标识”和“校验值”两列,否则追溯链条会断。
| 交付物 | 典型文件 | 版本标识 | 校验/说明 |
|---|---|---|---|
| 配置文件 | fpga_top.pof / .sof | 构建号 + 发布标签 | CRC32 或 SHA-256 |
| 升级文件 | fpga_top.rbf | 同构建号 | 与 .pof 同源编译 |
| 时序报告 | sta_summary.rpt | 同构建号 | 含 WNS/TNS 数值 |
| 资源报告 | fit_summary.rpt | 同构建号 | LE、RAM、DSP 占用 |
| 测试记录 | test_log_v2.3.xlsx | 测试用例版本 | 含测试人与日期 |
| 发布说明 | release_note.md | 发布标签 | 变更点与已知问题 |
一个可执行的开场动作
在进入后续章节之前,建议先对现有工程做一次“体检”,判断当前处于什么水平。检查项包括:工程是否纳入 Git;.qsf 中是否写死了绝对路径;SDC 是否与 RTL 同目录;是否有明确的 Quartus 版本记录;最近一次交付的固件能否反查到提交。如果这五项中有三项以上是否定的,说明版本与交付管理还停留在“人脑记忆”阶段,后续章节的收益会非常明显。
# 示例:检查工程是否包含绝对路径(Linux 环境)
grep -n "/home/\|/Users/\|C:\\\\" fpga_top.qsf
# 示例:查看当前提交与 Quartus 版本记录
git log -1 --oneline
cat environment.txt # 内容示例:Quartus Prime Pro 23.4 / 5CGXFC9D6F27C7