6.1 设计管理与协作


6.1 设计管理与协作

本节摘要:当代 SoC 的日历里,真正决定成败的往往是不是同一份 PDK、同一份约束、同一份签核责任表。设计管理从“共享目录里的最终版压缩包”升级为意图可追溯:每个决策带上下文、约束、验证状态和主人。本节用 PDK 兼容矩阵、签核分责和 ECO 窗口,把协作写成可执行纪律。

读前必看

阅读完本节,你应当能够:

  1. 说明为何 LEF 与 Liberty 版本脱钩会在硅上以 IO 失效的方式出现
  2. 建立一份最小的兼容矩阵:PDK、库、IP、约束
  3. 划分 DRC、LVS、STA、DFT 的关闭责任
  4. 规定 ECO 窗口:何时改 RTL,何时只改网表金属

一、从文件共享到意图图谱

原文写过一种死亡方式:前端用了带新 IO 单元的库,后端用了旧 LEF,单元顶层金属被错误摊平,高温下驱动能力掉下去。根因不是某一家工具,是元数据里没有“LEF 与 LIB 兼容矩阵”的自动校验。压缩包加邮件标题“请用此版做后端”,在百万门时代能混,在跨很多工艺文件、很多第三方核、每天产生海量日志的项目里会崩。

真正的管理是:时钟树策略、电源网格层、存储器编译参数,都要连到约束、验证状态、责任人。这不是把芯片项目塞进普通代码仓库就结束。PDK 是活契约:规则、器件模型、单元库、硬宏、波动统计之间互相咬。DRC 改了最小间距,可能逼单元库重做跳线,再逼所有依赖模块评估 ECO。

最小矩阵列:PDK 发行号、标准单元库号、IO 库号、存储器编译器号、每个硬核 GDS 号、SDC 与 UPF 号、DFT 规格号。签入流水线拒绝不在矩阵里的组合。人可以犯错,脚本应拒绝。

对象 脱钩症状 谁先发现
LEF 与 LIB 放置合法、时序模型是另一张脸 顶层 STA
网表与扫描定义 覆盖率假绿或链断 ATPG
UPF 与 RTL 低功耗仿真对不上 电源仿真
约束与时钟树 理想时钟绿、CTS 后红 后端
IP 文档与 RTL 寄存器地图软件写错 系统联调

⚠️ 常见坑:用日期当版本。“周二那包”在两个时区有三份。版本必须是不可变标识,构建可复现。
💡 关键直觉:你管理的不是文件,是意图与模型之间的兼容。

二、签核责任与日历

DRC 违例不能在邮件里无主。规则类别要有默认主人:天线、密度、间距、锁存相关。LVS 对不上,先分是层次摊平还是真连错。STA 违例按路径起点模块归属,跨模块路径归集成,不归“最后碰过网表的人”。DFT 覆盖缺口归 DFT 架构与模块主共同,因为不可测往往来自 RTL 锁存和时钟门控。

日历要有冻结点:RTL 冻结、扫描插入冻结、floorplan 冻结、金属冻结。冻结不是禁止改,是改的成本阶跃。金属冻结后只允许小 ECO。有人在冻结后改位宽,等于把船从水里吊回船台。

设计评审看证据不看自信:等价报告、覆盖率、MCMM 列表、EM 热点、已知例外清单。例外清单比绿报更重要。没有主人的假路径,评审应视为缺陷。

图:PDK 版本耦合

图:PDK 版本耦合

三、协作节奏

前端与后端的接口是网表、约束、不要碰的清单、时序预算。预算用数字:某模块出口最大延迟、时钟不确定性如何分摊。口头“你那边再挤一挤”会变成无限迭代。每日或每周的违例分类会:新增、复发、已归因。复发违例说明上一轮修复打到了错误层级。

远程协作时,数据库比波形截图重要。波形证明一次激励,数据库证明可复现。仿真农场的种子、工具小版本、许可都要记录。工具小版本升级能改启发式,网表结构可能变,等价必须重跑。

安全与出口管制也会进入管理:PDK 分发名单、网表是否可出园区。这不是附加行政,是和版本一样会让构建失败的约束。

问题:Git 够不够?

二进制数据库、库文件、GDS 往往要配套专用设计管理或大文件存储。Git 管 RTL、SDC、脚本很好;把 GDS 塞进普通仓库会让克隆变成灾难。分层存储,标识仍统一进矩阵。

问题:如何对待“紧急补丁”?

补丁也要进矩阵和等价。紧急只缩短评审人数,不缩短证据。没有等价的网表手改,是下一颗硅的定时炸弹。

四、把协作写成每日可执行的动作

早会只问三件事:矩阵哈希是否变、新增违例属于哪一层、冻结点是否被撞。哈希变了必须先说为什么,再说结果。违例归属当场指定主人,不允许“大家看看”。撞冻结要升级,而不是在聊天里悄悄改位宽。

发布流水线:RTL 提交触发 lint 与等价预备;网表提交触发扫描检查;物理数据库提交触发 DRC 快扫。失败的构建不能标“先用着”。人工覆盖门禁要留下名字,审计时能找到是谁放行了不兼容的 LEF。

知识传递用数据库快照,不用私有磁盘路径。新人第一周任务是复现上一份签核报告,而不是“熟悉一下代码”。复现失败说明文档或矩阵已经漂了,这是项目缺陷,不是新人能力问题。

供应商 IP 的更新窗口与内部冻结对齐。Foundry 发补丁 PDK 时,评估影响域再决定跟不跟。盲目跟会打乱矩阵;拒绝跟要记录风险。两种都比静默混用两套规则健康。

五、ECO 窗口的三种活

RTL ECO:功能还大,金属未冻,走完整等价与扫描。网表 ECO:功能小补,尽量同足迹替换。金属 ECO:只改线,功能几乎不能动。窗口写进日历,撞窗升级。聊天里改位宽属于撞窗。

紧急补丁缩短的是评审人数,不是证据种类。没有等价的手改,是下一颗硅的定时炸弹。补丁也要进矩阵哈希。发布说明写清补了什么路径、重跑了哪些报告。

供应商与 Foundry 补丁的影响域分析应在 48 小时内给出:动了规则还是模型还是外形。动外形等于换硬核。分析结论进矩阵,跟或不跟都记录风险,禁止静默混用。

六、复现即新人第一周

第一周任务是复现上一份签核命令。失败记项目缺陷。Git 管文本,大数据库分层存,标识仍进矩阵。紧急补丁保留等价。Foundry 补丁 48 小时内给出影响域:规则、模型还是外形。外形变动按换硬核处理。

早会三问:哈希、新违例层级、冻结撞击。门禁失败构建不得“先用着”。人工覆盖留名。新人复现上一份签核。文本进 Git,GDS 分层存,标识统一。ECO 三窗:RTL、网表、金属,撞窗升级。紧急缩短人数不缩短证据。Foundry 补丁 48 小时影响域:规则模型外形,外形按换硬核。例外无主当缺陷。工具小版本进矩阵,启发式静默升级要重跑等价。管理看起来像行政,失败时它以 IO 失效或扫描链断裂的方式出现在硅上。

案例:周二那包

前端“周二那包”和后端“周二那包”差了八小时两个时区,库版本不同。LVS 过了,高温 IO 不行,LEF 与 LIB 脱钩。从此矩阵拒收日期命名。新人复现签核失败,被当成能力问题,实际是工具小版本静默升级改了启发式。小版本进矩阵后,失败改记项目缺陷。金属冻结后有人在聊天改位宽,船吊回船台。ECO 窗口写成日历,撞窗升级。紧急补丁没跑等价,下一颗硅在同一处断裂。管理失败以电学症状出现,邮件语气再好也不导电。

再补一条出门检查:矩阵拒日期名;构建失败不得先用;新人复现任务存在;ECO 窗在日历;补丁影响域有记录。五样没有,集体心智还在压缩包。例外无主当缺陷。工具小版本进哈希。金属后改位宽撞窗。紧急不减证据。硅上 IO 失效要能追溯到哪一次脱钩,追溯不到说明矩阵仍是装饰。

问题:哪次构建必须拒绝?

日期命名拒绝。矩阵外的 LEF 与 LIB 组合拒绝。失败构建标先用着拒绝。金属冻结后改位宽不升级拒绝。补丁无等价拒绝。五拒写进流水线,不是写进作风手册。拒绝当时会得罪进度,不拒绝会在高温 IO 或断裂的扫描链上加倍偿还。新人复现失败记项目缺陷,能逼矩阵保持可执行。工具小版本不进哈希,启发式会在无人注意时改网表结构。管理课的肌肉是按按钮拒绝,而不是写长邮件解释为何应该拒绝。

管理肌肉是拒绝:日期名拒绝,矩阵外组合拒绝,失败构建先用拒绝,冻后改位宽不升级拒绝,无等价补丁拒绝。拒绝当时像耽误进度,不拒绝会在 IO 失效或链断裂上加倍还。新人复现失败记项目,能逼哈希可执行。小版本不进矩阵,网表会在无人注意时换脸。例外无主当缺陷。追溯不到脱钩点,矩阵只是墙上的装饰画。按钮拒绝比长邮件导电。

把拒绝写成按钮:五类构建直接失败。失败当时像耽误,成功时以没有高温 IO 事故来证明。复现任务、小版本进哈希、无主例外当缺陷,三件让矩阵从墙画变成门禁。导电的是按钮,不是语气。

门禁清单请写成脚本:日期名失败、组合不在矩阵失败、先用着失败、冻后改位宽未升级失败、无等价失败。五失败要在日志里看得见。看得见的拒绝,才能在事故后指出是哪一次本该失败却被放行。放行留名。复现失败记项目。矩阵从装饰变成门,靠的是失败码而不是海报。

失败码比海报重要。五类失败看得见,事故才能指到放行人。指不到人的矩阵,只是装饰。装饰不导电,失效却导电。

装饰不导电,失效导电。把这句放进早会第一屏。第一屏不是问候,是哈希。

要点串联

  • 兼容矩阵:PDK、库、IP、约束同生共死。
  • 不可变版本:拒绝日期风格的最终包。
  • 违例有主:按路径与规则类别归属,不按谁最后保存。
  • 冻结是成本阶跃:金属后只小 ECO。
  • 例外清单:评审的核心附件。
  • 可复现:工具小版本和种子也是输入。

金属后 ECO 只能动少数连线和缓冲,不能当第二轮架构。位宽、端口、宏尺寸在冻结后改,等于把船吊回船台。日历上要写清每一冻结点之后还允许哪一类补丁,聊天窗口里的“就改一比特”必须对照这张表。对不上就拒绝合入,而不是事后解释。冻结表比聊天记录优先。

下一节把这条纪律用到加速器:数据流、近存,以及用预测模型缩短放置与时序圈。


作者与出处
原作者: 灏天文库
来源:灏天文库
整理: 灏天文库整理
由灏天文库平台收录,内容或由平台用户上传,仅供学习交流
发布者: 作者: 灏天文库 转发
评论区 (0)
U