FPGA 专家 43：CI/CD——让每次提交都被机器验证

本文是 fpga/ 专家层第 46 篇。地基是 入门 49 Git 与可复现工程；上板环节见 专家 39 自动化测试，发布环节见 专题 04 量产。

一、流水线全景

push/PR ┬─► lint/规则（秒级）
        ├─► 仿真回归（多 seed/覆盖率，附波形）
        ├─► CDC/RDC/DRC
        ├─► 综合（资源/警告基线 diff）
        └─► 实现（时序门禁，夜间/全器件矩阵）
                    │ 全绿
                    ▼
        比特流制品(.bit + commit/工具/约束元数据) ──签名──► 制品库
                    │ release tag
                    ▼
        自动刷板 → BIST/冒烟 → 灰度/A-B → 现场版本可回读

二、门禁：硬红线 vs 趋势告警

硬门禁（红）	趋势门禁（告警）
WNS/WHS < 0、未约束路径	WNS 较基线退化超阈值
仿真 fail、lint error	资源利用率环比上涨
黑盒/多驱动、利用率超限	新增警告/拥塞加剧

三、可复现构建的支柱

固定工具版本（容器）+ 脚本化（tcl/quartus_sh）+ 从 .xci 重建 IP + 环境归一；版本注入：commit hash / dirty / 约束 hash → 上电可读寄存器。

四、基础设施现实

• 自托管大内存构建机（8–32GB/job），浮动 license 限并发，夜间排队；
• PR 轻量、夜间全量；IP OOC 与增量结果缓存；
• 构建产物大，定清理与制品保留策略；容器做构建、真机做刷板；
• 流水线即代码（GitLab CI/Jenkins/GitHub Actions+self-hosted runner），报告摘要化+趋势化。

五、与发布闭环

制品带签名与元数据入库；现场走 A-B 灰度；设备版本回查制品库 → 任何板子都能追溯到确切提交，实现"源码—比特流—现场"三点一线。

六、流水线工程细节：阶段、制品与加速策略

FPGA CI/CD 与软件 CI 最大的区别是单次验证昂贵：一次完整实现以十分钟到小时计，许可证和计算资源有限，板级测试还要排队。流水线设计的核心，是用阶段分层、制品化和结果缓存，让“每次提交快速得到与其风险匹配的反馈”，而不是所有改动都付全量成本。

阶段分层（快→慢、便宜→贵）：①提交级检查（秒~分钟）：HDL lint、编码规范、约束文件 diff 检查、文件清单/依赖完整性、YAML/工程脚本校验，甚至可以做成 pre-commit 钩子。②仿真回归（分钟~十几分钟）：单元/模块仿真、cocotb 随机、覆盖率收集，并行分片执行；这是承担功能反馈的主力层。③结构验证（分钟级）：CDC/RDC、X-prop、综合前 DRC。④综合（十几分钟）：网表级 lint、资源估算、初步 WNS、严重警告。⑤实现（数十分钟~数小时）：完整布局布线 + STA 全模式、功耗分析、生成比特流。⑥板级（异步排队）：调度远程 Lab 的板卡，烧录、BIST、冒烟、性能基线（见 专家 39）。每层失败即停，下层不浪费资源；PR 页面显示“当前提交验证到了哪一层”。

制品（artifact）管理：每一层的输出都要版本化、可追溯。仿真层归档日志、覆盖率数据库、失败波形环形缓冲；综合/实现层归档资源报告、时序报告（各时钟域 WNS/TNS）、警告清单、比特流与工程检查点；板级归档串口全量日志、BIST 结果、性能计数、板卡序列号与环境。命名以“流水线 ID + commit hash + 配置矩阵项”为键，保留策略按磁盘滚动。比特流作为一等制品进入制品库，元数据包含工具版本、约束 hash、IP 版本、git 信息，现场版本寄存器能反查到这次构建（见 20 比特流烧录与四方版本一致 manifest/门禁）。

加速策略是流水线可行性的关键：①分片与并行——仿真按用例分发到多机，综合/实现可按器件/配置矩阵并行。②增量与缓存——第三方 IP 和稳定模块预构建为锁定版本网表；综合结果按“源文件 + 参数 + 工具版本”哈希缓存（注意脏缓存风险，缓存键必须含约束和 IP 版本）。③智能选层——根据 diff 决定风险层级：只改文档/仿真文件不触发实现；改了时钟/约束/顶层接口则强制全量 + 板级；用文件依赖图自动推导需要重跑的仿真集。④夜间全量 + 提交轻量——PR 只跑快速层和受影响测试，夜间/合并前跑完整实现与多 seed。⑤资源池化——综合用带弹性的构建机（容器化工具链），板级用远程 Lab 调度器，避免专人专机。

配置矩阵也要流水线化：多器件型号/速度档、多板型、多 IP 配置（含 trace-on 调试构建，见 专家 45）应参数化为一次定义、矩阵展开，每个矩阵项独立报告，避免“主器件绿了就以为全绿”。

七、门禁体系：硬红线、趋势告警与例外治理

门禁（gate）决定什么状态的代码可以合并、什么状态的比特流可以发布。没有清晰的门禁哲学，CI 要么变成虚设（红灯随便合），要么变成瓶颈（任何抖动都阻塞全队）。成熟做法是把判据分成硬红线、趋势告警、信息观测三类，并为每类指定处置人和例外流程。

硬红线（blocking）：功能仿真失败（确定失配，非 flaky）；CDC/RDC 检查有未豁免违规；任一时钟域/模式建立或保持时序违例；资源超片；BIST 失败；比特流生成失败。这类问题由机器直接阻断合并/发布，没有“先合了明天修”的选项——红线一旦可以被人情绕过，整套体系很快失效。硬红线的判据必须稳定可复现，因此 flaky 测试绝不能作为红线，要先隔离治理。

趋势告警（non-blocking but visible）：资源周环比增长超过阈值；时序裕量显著收窄（仍为正但低于团队安全线）；警告数量增加、覆盖率下降；综合/实现时长异常；功耗逼近预算；性能基线（吞吐/延迟直方图）退化。趋势类问题不阻断当前 PR，但自动在合并页评论、@模块 owner，并在趋势看板累积——两次告警无回应可升级为红线评审。这样防止“每次只恶化一点点”的温水煮青蛙，这在长周期 FPGA 项目里是资源/时序末期爆雷的主要形式。

信息观测：覆盖率明细、利用率、各阶段时长、板卡利用率和队列时间等，只记录展示，供改进决策，不产生情绪压力（否则团队会开始刷指标）。

例外（waiver/exception）治理：有时必须带已知问题推进（客户现场紧急、某器件档已 EOL 不再维护）。例外要有：书面理由、影响范围、有效期和自动到期、批准人（技术负责人/质量）、补偿措施（限制部署板型、加监控、排期偿还）。CI 系统里例外不是注释掉检查，而是带元数据的豁免记录，到期自动恢复拦截；时序例外、CDC 豁免尤其要与 专家 40 的签核清单联动。定期审计存量豁免，防止临时例外变成永久架构。

质量指标的诚实性也靠门禁维护：覆盖率只升不降可以是软目标，但不能诱导写无断言的空转测试——因此覆盖率门禁要配合断言密度/变异测试抽查；资源/时序数字必须来自发布配置（trace-off、优化开启），不能用调试配置的报告充当发布证据。门禁配置文件本身入库、走 review，任何人改红线阈值都有审计记录。

八、可复现构建：工具链、IP 与容器化

“在我机器上能收敛”在 FPGA 项目里不是笑话而是日常：综合结果对工具小版本、环境变量、许可证服务器、文件修改时间乃至构建机 CPU 数量都可能敏感。可复现构建是硬件 CI 的地基——没有它，红灯无法信任、现场版本无法重建、签核证据站不住脚。

工具链固定：厂商工具的大版本、小版本、补丁/更新包全部钉死，团队统一升级（升级本身作为一个带全量回归的变更评审）；第三方 IP 版本锁定进清单（BOM of IP），IP 仓库按版本不可变存放；仿真器、cocotb/Python、交叉编译器同样固定。构建第一步先打印全部版本指纹并写入报告，版本不符直接失败。

环境容器化/镜像化：把工具链、依赖、脚本、许可证客户端封装进不可变镜像（容器或完整构建虚拟机镜像），CI 只在批准的镜像里跑构建，开发者本地用同一镜像；镜像本身版本化，镜像更新走评审 + 全量验证。这样“工具安装差异”这类问题从根上消失。注意厂商老工具对新 OS/容器的兼容坑（glibc、USB 驱动、许可证守护进程），通常用固定老基线 OS 的 VM 镜像最稳。

工程源的确定性：工程文件（哪些源文件、什么参数、什么约束）应由脚本/声明式配置生成，而不是依赖 GUI 里手工点出的二进制工程文件——GUI 工程文件 diff 不可读、易含绝对路径和本地状态。约束、顶层、IP 参数全部文本化入库；构建脚本不依赖未声明的环境（相对路径、固定工作目录、时区/locale 固定）；时间戳类字段（比特流里的构建时间）可以注入但要与 git 信息分离，避免“每次构建二进制都不同”掩盖真正的差异。

可复现性的验证级别要现实：FPGA 工具通常不能保证比特流逐位可复现（布局布线含启发式和并行），因此分两层承诺——结果级可复现（同一源码 + 同一镜像：时序结论一致、资源数一致、功能/BIST 一致）是必须达到的；比特流级可复现（hash 逐位相同）只有工具明确支持确定性模式时才承诺。发布记录保存能重现结果级构建的全部输入；现场任何版本都能从 git 标签 + 镜像版本重建。

九、发布工程与现场回流：灰度、回滚与质量数据闭环

CI 的终点不是“绿灯”，而是安全地把比特流送到现场，并让现场的真实表现回流成下一轮改进。FPGA 发布工程有自己的硬约束：升级意味着重配置（秒级业务中断或需多板滚动）、失败可能导致设备变砖、现场设备物理分散。

发布制品与升级安全：发布的比特流带完整元数据（版本、兼容硬件版本、所需 Shell/固件版本、CRC/签名）；设备端实现 A/B 双分区（或主备 Flash）：新镜像写备用区、校验通过后切启动指针、上电健康检查失败自动回滚旧版（与 专家 41 的可维护性预留一致）。升级流程支持批量、分阶段、可中断恢复；升级前自动检查硬件/固件兼容矩阵。密钥签名保证只接受授权镜像。配套的软件/驱动/固件作为同一发布单元测试版本兼容性。

灰度发布策略：先在实验室机架和内部设备（canary）跑 24~72 小时，含 BIST、压力和业务混合；再小比例现场设备（按地区/客户/板型分批），逐步扩大；每批之间看关键指标：BIST 通过率、误码率、链路 flap、温度功耗、性能计数、复位/重配次数、业务错误率。指标恶化超过阈值自动暂停推广并告警；具备远程停止和回滚能力是灰度的前提，没有回滚通道就不要做灰度。

现场回流数据是 FPGA 项目最容易缺失的一环：设备上报版本寄存器、健康遥测、trace 摘要（见 专家 45），汇聚后按版本切片对比——新版本的误码率是否上升、某时钟域是否有复位恢复异常、温度分布是否变化。现场发现的问题转成回归用例（先在仿真/板级 CI 复现，再修复），形成“现场→用例→门禁”的闭环；errata 数据库按版本登记已知问题和规避方法（与 05 原型到硅后衔接 pre/post-silicon 协同/errata 的 errata 闭环一致）。

发布纪律：发布制品只能由流水线从受保护分支产生，禁止工程师本地比特流出厂；发布记录（谁批准、灰度批次、回滚记录、现场版本分布）可审计；紧急热修复也要走完整门禁（可压缩等待时间但不省略时序/BIST 红线），事后补回归。长期看，现场版本分布要可观测——“客户跑的到底是哪版”必须一键可查，这是一切现场支持的前提。

十、典型坑与 FPGA CI/CD 落地清单

典型坑：把软件 CI 节奏硬套给 FPGA（每次提交全量实现，队列堵死，大家开始忽略红灯）；没有制品库，现场比特流来源不明；工具版本漂移导致“同一代码结果不同”；GUI 工程文件入库且不可 diff；flaky 板级测试进硬红线，红灯公信力崩溃；只看平均不看门禁趋势，末期资源时序双爆；调试版报告当发布证据；无回滚设计就远程升级；现场版本不可见、问题无法回流；CI 脚本本身无评审无人维护，成为神秘黑盒。

落地清单（按成熟度阶段）：

1. 版本控制卫生：RTL/约束/测试/工程生成脚本/CI 配置全部入库；大文件（IP、镜像）走制品库；保护主干。
2. 提交级门禁：lint、规范、文件完整性、CDC 快检，5 分钟内反馈。
3. 仿真回归：自检测试用例 + 参数化 + 多 seed + 覆盖率，可分片并行，失败归档可重放。
4. 可复现构建：钉死工具/IP 版本、容器或 VM 镜像、声明式工程生成、构建指纹入报告。
5. 实现级门禁：全时钟域/全模式 STA、资源、功耗阈值，结果级可复现，趋势看板。
6. 板级阶段：远程 Lab 池 + 调度器 + BIST/冒烟/性能基线，异步回写 PR。
7. 门禁分层：硬红线/趋势告警/信息三级，豁免有期限可审计。
8. 制品与追溯：比特流签名入库、元数据完整、现场版本寄存器可反查构建。
9. 安全发布：A/B 分区、健康检查自动回滚、兼容矩阵、灰度批次、暂停阈值。
10. 现场闭环：遥测按版本对比、问题转回归用例、errata 登记、现场版本分布可观测。
11. 体系维护：CI 配置走 review，流水线自身的时长/成功率/ flaky 率被度量和持续优化。 十一项分阶段推进比一步到位更现实：先让主干始终可构建、仿真可信，再上实现门禁和板级，最后闭环到灰度发布——每一步都让团队立刻受益，体系才有生命力。

十一、FPGA CI 的度量体系：用数据驱动改进

流水线一旦运转，就应用数据评估它是否真的在帮团队，而不是只看“绿灯/红灯”。对 FPGA 流程最有价值的度量分四类。反馈速度类：各阶段耗时（lint、仿真、综合、实现、板级排队）、从提交到各层结果的前置时间、排队等待时间占比。硬件流水线的墙钟时间常被板卡排队和许可证等待主导，光优化脚本没用，要靠增加板池、夜间全量、风险分层来解决。

质量类：逃逸缺陷率（通过流水线但在板级/现场发现的问题）、各阶段拦截缺陷分布（如果大量缺陷要到板级才发现，说明仿真和结构检查不足）、时序/资源告警的趋势、现场返回与版本的关联。逃逸率是最有说服力的指标——它直接回答“我们的红灯值不值得信任”。稳定性类：flaky 率、基础设施失败率、板卡 BIST 失败分布、重试率；flaky 必须按 专家 39 的方法分类治理并公开趋势，否则红灯公信力持续衰减。资产健康类：仿真覆盖率及其变化、构建缓存命中率、制品库增长、板池利用率。

度量的正确用法是驱动少数几个改进实验：比如数据显示综合阶段占提交反馈的大头，就投资增量/缓存和智能选层；板级排队时间长，就扩充板池或把冒烟与长测拆分；缺陷大量在 CDC，就把 CDC 检查前移到提交级并加强评审。错误用法是把覆盖率、时长变成个人 KPI——那只会催生无断言测试、选择性跳过用例和数据造假。度量看板服务团队改进，不服务考核，这是它保持有效的前提。

十二、渐进落地：没有自动化基础的团队怎么起步

很多 FPGA 团队起点是：工程师本地综合、U 盘拷贝比特流、靠 IM 通知集成。一步到位建全套硬件 CI 会因投入大、见效慢而失败。可行路径是按“立刻见效”的顺序小步推进。

第 0 步：版本控制与可脚本化构建。所有 RTL、约束、测试、工程生成脚本入库，消灭“只有某人电脑上能生成工程”的状态；一条命令完成全新构建。这是后续一切的前提，通常一两周即可见效（至少实现不会再丢）。第 1 步：最小自动检查。在提交或合并时自动跑 lint 和一组核心仿真冒烟（几分钟内），失败即阻断；先不追求覆盖率，追求“主干始终可综合、冒烟全绿”的确定性。

第 2 步：仿真回归与归档。把全部自检测试用例纳入定时运行（初期可以只是夜间），失败邮件/消息自动到人，波形和日志随失败归档；引入固定 seed 与多 seed。第 3 步：自动实现与时序门禁。夜间完整布局布线，产出资源/时序趋势，先做趋势告警，稳定后再把硬时序违例设为合并红线。第 4 步：一块共享板开始的板级自动化。不必先建板池：一块固定板卡 + 网络电源 + 远程 JTAG + 自动烧录 BIST，就能把“冒烟上板”做成夜间任务，验证整条技术链路后再扩成板池和调度。

第 5 步：制品库与版本追溯，比特流元数据与现场版本寄存器打通（见 20 比特流烧录与四方版本一致 manifest/门禁）。第 6 步：安全发布（A/B 与灰度）。每一步只解决一个痛点、每步都在一两个迭代内产生可见收益，团队才有动力继续。整个过程中最重要的组织动作是：指定流水线负责人（维护脚本、治理 flaky、运营度量），并让主干质量成为团队共识而不是某个人的额外负担。

十三、FPGA CI 与 ASIC/软件流程的差异要点

借鉴成熟领域经验时要避免生搬硬套。与软件 CI 相比：构建时间从分钟级变成小时级，无法每次 push 全量；制品是与具体器件/板型绑定的二进制而非可随处运行的包，且不可逐位复现；测试需要稀缺物理硬件且结果受物理条件影响；因此必须分层验证、智能选层、异步板级阶段，把“快速反馈”和“完整签核”解耦成两条节奏。

与ASIC 验证流程相比：FPGA 的优势是综合快、可反复上真实板、工具内建时序收敛和部分原型验证，因此可以承担更高的迭代频率、把更多验证放到真实速度；但 FPGA 团队通常人手更少、验证形式化程度低，容易把 ASIC 行业的重型方法学（全量约束随机、完整覆盖率签字）整体跳过。正确姿态是取其中性价比最高的部分——自检测试台、功能覆盖意识、CDC/RDC 结构检查、签核纪律（见 专家 40），用软件 CI 的自动化节奏运行，而不是照搬组织形式。

与传统硬件发布相比：把一次性的“投板前检查”变成持续的趋势管理（资源、时序、功耗每次合入都被度量），把“老师傅最后验收”变成机器门禁，把现场版本从不可追溯变成制品—版本—遥测闭环。FPGA CI/CD 的本质，是用软件的节奏管理硬件的刚性约束：分层付出验证成本、让每次变更得到与其风险匹配的证据、并让证据从提交一直延伸到现场。理解了它与两个邻居的差异，才不会在“像软件一样每天发布”和“硬件只能慢慢验收”这两个错误极端之间摇摆。

十四、把 CI/CD 推广到硬件团队：组织与文化。工具和流水线只是表层，真正难的是让团队改变工作方式：从“集成周集中救火”转向“主干始终健康”。这需要几个组织动作：明确流水线的所有权（不是 IT 兼管，而是有工程师对红灯响应、脚本维护、度量改进负责）；把红灯当停线事件——主干红了，新功能合入暂停，全员先修复，让“绿”始终值得信任；代码评审同时看 RTL 和测试（新功能必须带自检测试用例才能合并）；新人入职第一周就在流水线上提交和修复问题，把自动化当默认环境而非额外负担。管理者要为验证和基础设施投入时间预算——没有“专门腾时间做 CI”，它就会永远让位于功能开发，然后以集成期数倍的时间偿还。对跨地域团队，流水线还是最可靠的协作者：不同站点的子团队面向同一条主干、同一套门禁工作，集成冲突在每天的自动构建中持续暴露。最终衡量成功的不是流水线多复杂，而是三件朴素的事：主干是否任何时刻都可以构建并发布；一个缺陷从引入到被自动拦截平均经过多久；现场版本是否都能精确追溯到一次绿色构建。做到这三点，FPGA 团队才算真正拥有了持续交付能力。

工具链的现实补充：自建全套 CI 对小团队是过重负担，可以先用托管式 Git 平台的流水线 + 容器化构建节点起步，板级阶段先放一块受控的共享板（见 专家 39），跑通“提交即出比特流并自动 BIST”的最小闭环后，再按痛点逐步加缓存、矩阵、板池和灰度。关键是每一步都让团队立刻尝到甜头：更少的集成冲突、更可信的主干、现场问题可追溯。工具会换、平台会变，但“变更自动获得与其风险匹配的证据”这条原则不会变。

结语：FPGA CI/CD 的终点不是一条炫目的流水线，而是一种状态——主干任何时刻可构建、可发布、可追溯；每次变更都自动获得与其风险匹配的证据；现场跑的每个比特流都能回到一次绿色构建和一整套时序、仿真、BIST 记录。当质量由机器而非意志力保证，硬件团队才真正具备了高频迭代的底气。

对团队管理者的最后提醒：不要用“大家最近很忙、质量问题以后再说”推迟基础设施投入，因为硬件缺陷的修复成本随阶段指数增长——提交前一条 lint 警告是几分钟，板级调试是几天，现场返修是几十倍的代价。把流水线、BIST、版本追溯当成产品代码同等优先级来排期，是 FPGA 团队工程成熟度最直接的体现，也是让新人能快速产出、老人不被反复救火耗尽的根本机制。

总结

FPGA CI/CD 用"PR 快检（lint/仿真）、夜间全量（综合实现/多角点）、硬时序门禁+基线趋势告警、制品化签名比特流、自动刷板冒烟"把个人工程纪律变成团队流水线，前提是容器化可复现构建和大内存自托管 runner。