1. 签核与交付总览

在 FPGA 项目里,“设计做完”与“工程可交付”是两件不同的事。前者通常指功能仿真通过、时序收敛、板级验证完成;后者则要求工程在指定 Quartus 版本下可复现编译、约束完整、文档齐备、签核记录可追溯,并且接收方能够独立完成一次干净的编译与下载。签核与交付的核心,就是把“我这边能跑”变成“任何人拿到都能跑,并且知道为什么这样跑”。

本节先建立一张全局地图:从设计冻结开始,经过若干签核节点,最终形成交付包。后续章节会分别展开每个节点的检查项、工具操作与常见问题。

一、完整流程:从设计冻结到交付

一个典型的 Quartus 工程交付流程可以划分为五个阶段:设计冻结、工程整理、签核验证、交付打包、接收确认。设计冻结不是“不再改代码”,而是指 RTL 功能基线、引脚分配、时钟约束和 IP 配置已经确定,后续变更必须走变更记录。工程整理阶段要清理中间文件、统一路径、确认 Quartus 版本与器件型号。签核验证阶段按节点逐项检查,每个节点有明确的通过条件和责任人。交付打包阶段生成交付物清单并归档。接收确认阶段由接收方在干净环境中复现编译,确认无缺失文件、无绝对路径依赖、无版本不匹配。

Quartus 工程签核与交付总览 设计冻结 → 工程整理 → 签核验证 → 交付打包 → 接收确认 设计冻结 RTL基线 / 引脚 / 约束 工程整理 清理 / 路径 / 版本 签核验证 节点检查 / 记录 交付打包 清单 / 归档 接收 确认 签核节点(Gate) G1 设计冻结签核 RTL 版本锁定 引脚/时钟约束确认 G2 编译签核 全编译无 Error 时序报告已审阅 G3 板级签核 下载/回读验证 关键信号实测 G4 交付签核 交付物清单核对 接收方复现通过 交付物清单(核心项) 工程源文件 • .qpf / .qsf 工程与设置 • RTL 源码(.v/.sv/.vhd) • IP 文件(.ip/.qip) • SDC 时序约束 • 引脚分配与管脚约束 • 顶层文件与参数说明 编译与验证产物 • 全编译日志(.rpt) • 时序分析报告(STA) • 资源利用率报告 • 编程文件(.sof/.pof) • 仿真波形与测试平台 • 板级测试记录 文档与签核记录 • 设计说明与框图 • 引脚定义表 • 时钟与复位说明 • 签核检查表(G1~G4) • 变更记录 • 已知问题与限制 角色职责:设计者负责源文件与约束;验证者负责编译与时序签核;项目负责人负责交付物完整性与接收确认。

二、签核节点的定义与通过条件

签核节点不是形式上的“签字”,而是有明确输入、检查动作和通过判据的质量门。以下四个节点是大多数 Quartus 工程交付的最小集合。

G1 设计冻结签核。输入是 RTL 代码、引脚分配、时钟约束和 IP 配置。检查动作包括:确认顶层实体与工程设置一致;确认所有时钟已写入 SDC 并完成 create_clock 定义;确认引脚分配与原理图或板卡定义一致;确认 IP 版本与 Quartus 版本兼容。通过判据是:RTL 编译无语法错误,约束文件可被 Quartus 正常读取,引脚无冲突。责任人通常是设计者,评审人可以是项目负责人或系统工程师。

G2 编译签核。输入是冻结后的工程。检查动作是执行一次完整编译(Processing → Start Compilation),并逐项审阅 Compilation Report 中的关键页面:Fitter 的引脚分配结果、Timing Analyzer 的 Setup/Hold/Recovery/Removal 余量、Resource Utilization 的 Logic Elements 与 Memory 占用。通过判据是:无 Error;时序约束全部满足,或对未满足项有明确的豁免说明与风险评估;资源占用留有余量,通常建议不超过器件资源的 80%。责任人通常是验证者或独立编译人。

G3 板级签核。输入是 .sof 或 .pof 编程文件与目标板卡。检查动作包括:通过 Quartus Programmer 下载并回读 ID;用 SignalTap 或外部仪器观测关键信号;验证复位、时钟锁定、接口通信等基本功能。通过判据是:下载成功、回读 ID 一致、关键功能实测符合设计说明。责任人通常是板级测试工程师。

G4 交付签核。输入是整理后的交付包。检查动作是:在另一台机器或干净目录中解压交付包,用指定 Quartus 版本打开 .qpf 并执行全编译;核对交付物清单逐项存在;确认无绝对路径、无本地缓存依赖。通过判据是:接收方独立编译成功,且编译结果与交付记录一致。责任人通常是项目负责人与接收方代表。

三、交付物清单与组织方式

交付物不是越多越好,而是“接收方需要的都在,且没有多余干扰”。建议按以下目录结构组织:

project_delivery/
├── 01_source/          # RTL、IP、SDC、qsf、qpf
├── 02_build/           # 编译脚本、版本说明、编译日志
├── 03_output/          # sof/pof、时序报告、资源报告
├── 04_doc/             # 设计说明、引脚表、签核检查表
└── 05_record/          # 变更记录、已知问题、板级测试记录

其中,01_source 必须包含 .qpf 与 .qsf,且 .qsf 中不应出现本机绝对路径。若工程使用了 Qsys/Platform Designer 生成的 IP,应同时交付 .qsys 与生成的 .qip,避免接收方无法重新生成。SDC 文件应独立存放并在 .qsf 中通过 set_global_assignment -name SDC_FILE 引用,而不是把约束散落在多处。

交付前建议执行一次“干净目录编译”:把 01_source 复制到新目录,删除 db/、incremental_db/、output_files/ 等中间目录,再用相同 Quartus 版本打开工程并全编译。这一步能暴露绝大多数路径依赖和缺失文件问题。

四、角色职责与协作边界

签核与交付涉及四类角色:设计者、验证者、板级测试工程师、项目负责人。设计者负责源文件、约束和 IP 配置的正确性,并在 G1 前完成自检。验证者负责独立编译、时序审阅和 G2 签核,不应由设计者自己签自己的编译结果。板级测试工程师负责 G3,关注下载、回读和实测功能。项目负责人负责 G4,核对交付物清单、组织接收方复现,并保存签核记录。

一个常见的误区是“设计者兼验证者”。在资源紧张时这可以理解,但至少应做到:编译环境与开发环境分离,使用不同的 Quartus 安装或不同的机器;编译前清理中间文件;签核记录中注明“自签”并说明补偿措施。否则,交付质量完全依赖个人记忆,风险不可控。

五、一个可复用的签核检查表示例

下表给出 G1~G4 的最小检查项,可直接作为交付包的 04_doc/signoff_checklist.md 内容。表中“判据”列是客观可验证的条件,避免“看起来没问题”这类主观描述。

节点 检查项 判据 责任人
G1 顶层实体与工程设置一致 Settings → General 中 Top-level entity 与 RTL 顶层名相同 设计者
G1 时钟约束完整 SDC 中每个输入时钟均有 create_clock,周期与板卡一致 设计者
G1 引脚分配无冲突 Pin Planner 中无红色冲突标记,未使用引脚已设为三态或接地 设计者
G2 全编译无 Error Compilation Report 中 Error 数为 0 验证者
G2 时序余量达标 Setup/Hold 最差余量 ≥ 0,或豁免项有书面说明 验证者
G2 资源占用合理 LE 与 Memory 占用 ≤ 80%,留有修改余量 验证者
G3 下载与回读 Programmer 下载成功,回读 ID 与器件一致 板级测试
G3 关键功能实测 复位、时钟锁定、接口通信符合设计说明 板级测试
G4 交付物齐全 按清单逐项核对,无缺失 项目负责人
G4 干净目录复现 接收方独立全编译成功,结果与记录一致 接收方
签核记录应包含日期、Quartus 版本、器件型号、编译日志摘要和签核人。缺少版本信息的签核记录,在半年后几乎无法复现,等同于没有签核。