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 FPGA 项目全生命周期与版本/交付管理主线 ① 设计 RTL / IP 配置 SDC 约束 / 引脚分配 .qsf / .qpf 工程文件 版本标识:Git commit ② 构建 Analysis & Synthesis Fitter / STA / Assembler .sof / .pof / .rbf 版本标识:构建号 + 日志 ③ 验证 时序报告核对 板级功能测试 测试记录 / 问题单 版本标识:测试用例版本 ④ 交付 固件归档 / 发布说明 升级包 / 校验值 现场追溯记录 版本标识:发布标签 验证/交付发现的问题回流到设计,触发新版本 版本管理支撑 Git 分支策略 · 版本号规则 · Quartus 版本锁定 · IP 版本记录 · 约束文件同源管理 每次构建生成唯一构建号,绑定 commit、Quartus 版本、器件型号与编译日志 交付管理支撑 交付物清单 · 发布审批 · 固件校验(CRC/哈希)· 现场升级记录 · 版本追溯矩阵 从现场固件反查源码提交、编译日志、测试报告,形成闭环

常见痛点:为什么“能跑”不等于“能交付”

第一个高频痛点是环境漂移。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