8.3 持续集成与设计数据管理

8.3 持续集成与设计数据管理

本节摘要：持续集成把"跑全流程、看指标、修问题"从随机行为变成每晚例行的体检；设计数据管理则保证任何时候都能回答"这份网表是谁、在什么输入下、用什么工具版本生成的"。本节给出夜间回归的完整方案（任务编排、指标采集、失败处理），讲清设计数据版本管理的最小可行制度，以及一套让团队节奏不被破坏的红线纪律。这是全册的收束：制度让算法的战斗力可持续。

夜间回归：把体检变成例行公事

没有回归制度的项目，质量信息是随机的：有人某天跑了全流程，发现时序崩了，然后全队救火三天。有回归制度的项目，质量信息是每日更新的：每晚全流程自动跑一遍，早晨看板告诉你裕量趋势与新增违例——问题在出现后的二十四小时内被看见，而不是三周后。一套夜间回归的最小组成有四件。触发与编排：版本库有提交即触发（或定时触发），任务按依赖图调度——综合依赖 RTL 与约束、布局依赖综合、签核依赖布局，图调度器保证并行任务不互相等待、失败任务不污染下游。算力池：回归负载与 7.2 节的弹性算力天然契合——每晚几百个工具作业，跑完释放。指标采集：每个作业结束时抽取关键指标（各阶段 WNS 与 TNS、面积、功耗、违例计数、运行时长）写入指标库，报告文件本身另行归档。看板与通知：晨会看趋势曲线（裕量是否在收敛、面积是否在膨胀），失败清单即时推送到责任人的通道。

回归方案的规模参数给个数量级：中型项目的夜间回归每晚运行几百到几千个工具作业，覆盖全部工艺角、全部主要设计分区、加上几百个端到端的测试用例；跑一轮从两小时到八小时不等——这也是为什么算力弹性与编排效率是回归制度的两大命门。回归的红绿语义必须严肃：红（失败）的处置优先级高于一切新任务，"先修红再开新"是纪律而不建议——红着不放的回归制度才能保护主干，一旦"红着继续开发"被默许，回归就退化成装饰品。

失败处理：回归制度的核心动作

回归的价值不在"跑"，而在失败之后的流程。失败分类的第一刀是环境失败与真实失败：工具崩溃、机器故障、数据缺失是环境失败，重跑或修环境即可，不进设计问题清单；指标越界、检查不过、流程报错才是真实失败，必须归因。归因的第二刀是本次引入与历史遗留：拿本次提交与前次绿版本的差异（RTL diff、约束 diff、脚本 diff）做嫌疑排查，二分法（对半回退提交重跑）能在几轮内锁定肇事提交。制度上要求每条真实失败绑定责任人、根因分类（RTL 问题、约束问题、脚本问题、工具问题）与解决时限——失败数据本身是流程改进的原料：某类失败反复出现，说明该处的检查或自动化缺位，补上之后同类失败应绝迹。回归制度成熟度的标志，恰恰是失败率的下降曲线，而不是每天跑多少作业。

设计数据管理：可溯源是底线

设计数据的管理问题可以浓缩成一句话：任何一份产物，都要能回答它的出身。这份网表是谁提交的 RTL、配上哪个版本的约束与脚本、用哪个版本的工具跑出来的？答不出来，调试、复现、审计、交接全部无从谈起。最小可行制度有三层。第一层，输入版本化：RTL、约束、脚本、IP 清单全部在版本管理里，流程启动时记录各仓库的确切版本号（提交哈希），与产物绑定存储。第二层，产物不可变：每次流程运行产出独立的产物目录，目录一旦生成就不再修改——要改就是新一轮运行的新目录；这样任何历史产物永远可回溯、可复验（这对签核审计尤其重要）。第三层，工具环境定格：工具版本、补丁、许可配置、机器环境（或容器镜像）记录在案——工具升级是流程事件，要有独立的验证轮次，不允许"顺手升级"。

一次流程运行的血缘记录（最小字段集）

run_id:        R-2026-0906-014        // 运行唯一号
inputs:        rtl@8a3f2c1  sdc@b7e91d0  scripts@4c2f8aa
tool_env:      syn@V2025.3  pnr@V2025.2  container@sha256:9f3e
params:        corners=[ss 0.72V -40C, ff 0.88V 125C]
outputs:       netlist/  report/  log/   (不可变目录)
metrics:       wns=-0.08  tns=-1.2  area=4.82mm2  power=1.31W
status:        PASS(时序) / 2条 DRC 转单
溯源查询:      任何产物目录 反查 run_id 即得全链
​

数据的引力与团队的记忆

数据管理做到位之后，会自然长出两种复利。横向复利：数据引力（呼应 7.2 节）——完整的指标历史与产物血缘让"历史方案对比"变得便宜，新项目的起点不是白纸而是历史分布（同类设计的面积功耗先验、常见违例模式清单）。纵向复利：团队记忆——每次 tapeout 后的复盘（哪些检查漏了、哪些约束错了、哪些脚本坑了人）沉淀成检查清单与自动化规则，团队的成熟度由此代际累积。反之，没有数据制度的团队每两三年"重新踩一遍同样的坑"，复盘无从谈起。全册至此收束：第 1 章的问题链从"手工画不完了"出发，途经综合、物理实现、签核、制造、验证、AI，最终落在这个朴素的结论上——把数十亿晶体管的设计自动化，靠的是算法；把自动化可持续地做下去，靠的是制度。两者都是工程师的作品。

一个启动建议给正在搭第一套回归的小团队：不要追求一步到位的全流程回归，先让"综合加时序估算"这一段每晚自动跑起来，指标只收三个数（WNS 估计、面积、脚本错误数）。两周后团队会自然长出对趋势的依赖，再逐段接入物理实现与签核。回归制度的生命线是"每天都跑、每天有人看"，规模可以慢慢长大——反过来，一上来就搭豪华流水线却三天两头断跑的团队，制度死得更快。

本节要点回顾

• 回归是每日体检：编排、算力、指标、看板四件套，让问题在二十四小时内被看见。
• 红绿语义严肃：先修红再开新，回归红着还能开发时它已经是装饰品。
• 失败两刀：先分环境与真实，再用差异排查与二分定位肇事提交。
• 失败率是成熟度指标：同类失败反复出现即自动化缺位，修复后应绝迹。
• 可溯源三件套：输入版本化、产物不可变、工具环境定格，产物永远能答出身。
• 两种复利：数据引力给历史先验，团队记忆让坑只踩一次——制度是全册的最终落点。