先说句实话没跑过三层金属工艺的物理设计很难体会M3只有一层能走通全芯片是什么感受。VLSI CAD里的 Layout-3 Mapping听起来像一个工具选项但它实际上是一整条从门级网表到物理版图的映射流水线把综合后的逻辑电路逐层映射到只有 Metal1、Metal2、Metal3 三层布线资源的硅片上。这类任务常出现在模拟/数字混合芯片的数字控制逻辑、自研单元库验证流片以及教学科研用的完整前后端流程里。它的特点是面积不大、规则不少、约束很硬和动辄七八层金属的主流数字后端流程完全不同。本文把我从数据准备、资源分配、布局布线到 DRC/LVS 验证的完整做法整理出来每一步都讲清楚为什么这么做给准备上手或正在被三层金属工艺折磨的同行一份可复用的操作参考。1. 到底映射的是什么Layout-3 Mapping 的职责边界先给这个任务下一个明确的定义避免后面越聊越模糊。Layout-3 Mapping指的是在 VLSI CAD 物理设计环节里将一个已经综合完成的门级网表映射到只提供三层金属互连的工艺版图上的全过程。这里的映射不是简单地把单元摆放一下、把线拉通而是包含四个层面的对应关系任何一个层面没做对最终 GDS 都过不了物理验证。1.1 四个层面的映射对象第一层是逻辑映射门级网表里每个逻辑门要在标准单元库中找到对应的物理实现单元比如一个 2 输入与非门映射到库里的 NAND2X1 单元。这个环节在逻辑综合时就已经完成但物理设计阶段还要再核对一遍因为综合库和物理库经常存在版本差异。第二层是端口映射每个标准单元内部有电源、地、输入、输出 pin端口映射就是把这些逻辑端口对准到版图上标准单元的实际物理位置同时要保证这些 pin 所在的金属层和布线资源层匹配否则后续路由根本找不到连接点。第三层是连线映射网表里每一条逻辑 net要变成一组由金属多边形和过孔组成的几何线网。这条线网可以穿过 M1、M2、M3也可以在不同层之间通过 VIA 转换。连线映射会直接决定时序、功耗和信号完整性。第四层是资源映射在三层金属工艺里每一层金属都要承担特定角色例如 M1 负责单元内部互连M3 负责长距离走线和电源分配。资源映射做得好不好决定了整个版图的拥塞度和可布通性。这四个映射并不是按顺序执行完就结束的它们之间会来回迭代。一个很常见的场景是布线阶段发现局部拥塞过高只能回头调整标准单元的摆放方向或者把某个宏单元挪个位置这时端口映射和连线映射都要跟着改。1.2 为什么物理设计也叫 Mapping而不是简单叫 PR很多同事刚接触这个名词时会问不就跑一遍 placement 和 routing 吗为什么要叫 mapping我的理解是PR 工具默认你拥有完整的布线资源工具可以在所有金属层之间自由切换但三层金属工艺的资源紧张程度完全不是一个概念。在 Layout-3 场景下你在真正执行 PR 之前就必须先定死 M1、M2、M3 各自的功能角色。比如 M3 只走南北方向的长距离信号和电源条带M2 只做东西方向的短距离绕线M1 贴近单元边界做相邻互连。各层的角色一旦确定工具能使用的路由资源就等同于是半固定的。这时候布线的本质就是在这些约束下把一个逻辑图映射到物理空间更像是一种定向映射而不是自由排列组合。我用一个生活化的类比一个有大量积木和一个只有三块隔板的抽屉前者你可以随心所欲分格放东西后者你得先在脑子里想好哪块隔板用来分大件、哪块用来分小件再开始往里面装。三层金属 Mapping 就是后一种情况。1.3 适用场景与不适用场景在项目启动前先判断一下自己是不是真的要做 Layout-3 Mapping能避免后面很多无用功。适用场景包括中小规模数字模块比如几万门到十几万门的数字控制逻辑模拟/数字混合芯片里的数字子系统这类芯片主工艺往往只有三层金属自研标准单元库的流程验证高校和实验室的完整前后端流程教学。不适用场景也很明确大规模 SoC几百万门以上三层金属的资源几乎不可能完成布线硬跑只会得到一张拥塞破表的版图对工作频率要求很高的模块三层金属的寄生效应对时序影响太大通常需要额外做大量屏蔽和尺寸调整成本划不来。判断方式很简单先打开库文件里的 metal 层定义数一下可用的 signal metal 层有几层。如果只有三层那恭喜你进入这篇文章的主题如果六层以上直接走标准数字后端的流程更合适。2. 三层金属的资源分配策略先定规矩再动手Layout-3 Mapping 和主流数字后端的最大区别在于它有一个布线主导的资源规划阶段。这一步不是工具的自动功能而是设计师必须在跑流程之前手动完成的关键决策。很多新手上来就直接 import netlist 开始 place结果跑到一半发现 M3 全被信号占了电源和时钟根本没地方走只能全部推倒重来。2.1 每层金属的人设定位我通常把三层金属的角色分成三类单元内部层、绕线层、干线层。这个定位不是拍脑袋定的而是根据标准单元的实现方式和 pin 出口位置推导出来的。M1 通常是标准单元内部完成电源/地线连接以及单元内部门间互连的主要层次。标准单元的 pin 口一般也设计在 M1这样相邻单元之间可以用最短的 M1 拼接完成信号传递。M1 还承担单元行内的电源 rail横向贯穿整个 row。M2 主要做东西走向的短中距离绕线。它的用途是解决 pin 口错位、局部信号跨越单元行、以及在 M1 实在走不通时提供额外的横向通道。M2 尽量不走长线因为长线会导致大量过孔占用而且对拥塞影响很大。M3 是芯片中唯一的干线层。南北走向的长距离信号、电源条带、时钟主干、复位网络几乎全部压在这一层。M3 在 Layout-3 项目里的地位相当于高速公路之于城市交通。它的使用率必须被严格监控。每一层金属之间通过 VIA 连接V12 连接 M1 和 M2V23 连接 M2 和 M3。V23 过孔数量通常比 V12 少因为跨层穿透需要同时占三层金属的空间在拥塞区域会非常挤。2.2 各层使用率的目标区间经过几次项目迭代我总结了一套相对可靠的使用率控制目标。M1 使用率尽量保持在 70% 以下M2 保持在 50% 以下M3 保持在 25% 到 30% 以下。这组数字的核心逻辑是给后续的工程变更和 DRC 修复留出足够余量。如果 M1 超过 70%通常说明标准单元选的密度过大或者库的 pin 出入口设计不适合这个项目需要调整库选项。M2 超过 50%说明绕线出现明显阻塞要考虑调整摆放方向或者加大行间距。M3 一旦超过 30%整个芯片的干线资源就濒临枯竭任何一根关键 net 的改版都会引发连锁拥塞。这些控制目标可以通过 tool 的 congestion report 来验证。在全局布线阶段结束后先看各层 metal 的 utilization 饼图再决定是否返工。我在实际项目中见过因为 M3 使用率冲到 40% 导致后面 LVS 修都修不动的案例所以这个比例的监控建议做成硬性检查点。2.3 电源网络的最小代价设计三层金属工艺的电源网络设计是很多项目翻车的高发区。核心矛盾在于M1 虽然有横向电源 rail但承载能力有限M2 如果用来走电源信号绕线通道会迅速被吃掉而 M3 是唯一能做大尺度电源分配的长线层。因此电源网络必须优先占用 M3并且用 M2 做短距离的电源连条M1 继续承担标准单元内部的 rails。我的做法是在 M3 上按固定 pitch 拉纵向电源条带每 8 个 site 拉一条宽度约 5um 的 stripestripe 的间距满足工艺 DRC 的最小间距要求。M1 的横向 rails 和 M3 的纵向 stripes 之间靠 M2 的短连条搭桥。电源网络的 IR drop 预算是整个芯片供电电压的 3% 以内超过这个值就要加宽 stripe 或者加密 stripe 数量。以常见电源电压 1.8V 为例IR drop 预算就是 54mV。这 54mV 要分摊到每个供电网络的每个节点如果某个区块的电压降接近 30mV 以上就得马上调整电源拓扑。三层金属工艺里调整电源网络的成本很高因为 M3 同时要承担时钟和其他长信号改一步动全身。所以我的经验是电源网络设计尽量放在 Floorplan 阶段就定死而不是等布线阶段发现问题再去补。刚开始做 Layout-3 项目的团队最容易犯的错误就是电源网络设计得过晚、过窄最后芯片里到处是 IR drop 热点。3. 数据准备把映射输入整理成工具链能读懂的东西有了资源规划的思路下一步就是把所有输入数据准备到位。这一步很枯燥但也是后面所有工作的地基。数据没整理干净后面每个步骤都会报一些莫名其妙的错排查起来非常浪费时间。3.1 需要准备的文件清单首先是门级网表。这是逻辑综合的输出通常是一份 Verilog 格式的文件里面都是标准单元的实例化。文件里不能有未映射的黑盒也不能有 always 块、assign 语句必须全部是标准单元。其次是标准单元库文件。至少需要三部分库的抽象描述文件里面包含每个单元的尺寸、pin 坐标、pin 方向和 metal 层信息库的完整版图文件用于最终 GDS merge 和数据交付库的 LVS 网表用于物理验证时的晶体管级比对。然后是工艺设计规则文件。抽象描述和 DRC 规则文件规定了最小线宽、最小间距、金属密度等参数。这个文件决定了你最终能不能跑出干净的 DRC。最后是约束文件。虽然三层金属 Mapping 通常不像大规模芯片那样有几百条复杂约束但基本的时钟周期、最大电容、最大扇出这些还是要写上布局布线工具会在流程中使用这些约束做优化。3.2 数据一致性三查拿到这些文件之后我建议先花半小时做一次数据一致性检查比后面埋着头跑流程省时间得多。一查实例与单元名用脚本把门级网表里所有实例的单元名提取出来和库目录里单元的合法名称做差集比对。差集不为空说明网表里有未映射或命名不匹配的单元这时候就要去查综合脚本里的库映射配置。二查 pin 名对应把每个标准单元的 pin 名列表与抽象文件里定义的 pin 名列表做比对。如果某个单元在网表里叫 Q但抽象文件里叫 QN 或 YN说明源库和目标库版本不一致。实际项目中我遇到过库更新之后同样的功能单元 pin 名从 Q 改成了 Q2网表没同步更新结果一排全是 pin not found 错误。三查版图单元是否存在把物理库 GDS 里的顶层单元名导出来和抽象文件里的单元名做比对。这一步是防止抽象文件里存在但 GDS 里缺失的幽灵单元这种单元在流程中期才会暴露问题处理起来非常麻烦。3.3 网表与物理库命名版本对齐三层金属 Mapping 项目很常见的一个现象是同一个功能单元逻辑库和物理库的命名规则不同。例如逻辑库里叫 NAND2X1物理库里叫 NAND2_X1_Y1。这种不一致不会在流程开头报错但会在 LVS 阶段引起大面积 mismatch。解决方法是做一个单元映射表把逻辑库单元名映射到物理库单元名然后在导入网表之前统一替换。这个映射表可以用脚本来维护也可以用库专门提供的映射文件。我习惯的做法是先自动生成一份全量映射草表再人工抽查关键单元比如时序关键路径上出现的单元确保映射无误后再导入。数据准备阶段的另一个容易忽略的点是必须确认门级网表里不含任何来自其他工艺库的单元比如模拟器件、压焊盘等。如果混入了后面物理验证会非常痛苦。保险起见在导网表时做一次白名单检查只允许目标标准单元库的单元进入物理设计流程。4. 实战映射过程Floorplan 到 GDS 的完整流水线数据准备好之后就可以进入正式的映射流程。这一节我按照实际操作顺序从面积估算、布局规划、标准单元摆放、时钟树综合、布线映射到物理验证完整走一遍。每一步都会给出具体的参数思路和检查要点。4.1 面积估算与利用率设定面积估算不是简单把每个单元的面积加起来还需要考虑布线通道、电源网络、时钟树和可能的冗余空间。我的方法是先统计网表里所有标准单元的总面积然后除以目标利用率得到初始核心面积。Le Corbusier 的建筑设计里有句话叫留白即设计芯片版图也是这样。四层以上金属的工艺利用率可以挑战 75% 到 80%但三层金属工艺我会把初始利用率定在 60% 上下宁可面积放宽一点也不要让布线资源太紧张。原因后来在项目里得到了验证60% 利用率下布线资源还有充分余量DRC violations 数量很少把利用率提到 70%拥塞热图立刻出现了好几个红色区域。面积估算时可以参照这个式子核心面积 单元总面积 / 利用率。假设单元总面积是 3 万平方微米利用率定 60%则核心面积就是 5 万平方微米。再在这个基础上加 10% 到 15% 的时钟树和电源网络余量最终确定芯片核心区域的尺寸。这个估算过程中我还会考虑 IO 和 pad 的布局。如果 pad 限制在芯片四周那么核心区域的长宽比就要和 pad 数量匹配。平面形状拉得太长会给 M3 纵向走线带来压力过于方正则可能导致 IO 连不到核心区。4.2 Floorplan 硬约束与电源网络落位Floorplan 阶段的第一步在芯片四周画好 IO ring宽度根据 IO 单元和 ESD 结构确定这个区域不参与标准单元摆放。第二步在芯片内部划分出模拟区、数字区、以及必要的 guard ring 隔离区。第三步把确定的电源条带方案落实到 Floorplan 上。M3 电源条带在 Floorplan 阶段就要画好不能等到布线阶段。原因是布线工具在后续过程中会优先避开已有金属的区域电源条带的存在会影响信号线的走向选择。条带画完之后我还习惯在上下两侧加一条独立的 M3 宽线作为地环与 IO ring 连接这样整个芯片的地回路会比较短。Floorplan 阶段还需要确定标准单元摆放的方向。为了让同一行内的 M1 电源 rail 可以共用标准单元行内的单元必须统一朝向。相邻行之间则可以选择背靠背或者面对面这个选择会影响行间距和 pin 访问难度。对于模拟/数字混合设计的模块我一般会在模拟部分周围设置 hard blockage阻止数字标准单元填充进去。因为模拟单元对周围环境更敏感数字单元的开关噪声通过衬底和金属层耦合过去会影响模拟性能。虽然这占用了一些面积但在三层金属工艺中这种隔离是很有必要的。4.3 标准单元摆放把逻辑映射到物理行Placement 阶段要实现的核心目标是把网表里的每个单元放到物理行中的一个合法位置。合法性包含单元宽度是 site 宽度的整数倍、单元所在的行使单元高度与行高一致、单元之间的最小间距满足规则、电源/地 pin 连接正确。标准单元摆放完成后最值得花时间看的是拥塞热图。工具会通过 estimate congestion 的方式提前预测每个区域的布线拥塞程度超过 45% 到 50% 的区域标成红色就需要人工干预。干预手段通常有把红色区域周边的高密度单元打散或者把某些宏单元换个位置也可以调整行间距给布线留空间。我会额外注意凹槽形状的边角区域。Floorplan 如果出现了非矩形边界或者内部挖空标准单元摆进去后常常在凹槽边缘形成大量不可布线区域。处理办法是添加 block把这些区域禁止摆放标准单元宁可损失一点面积也不要制造布线死角。单元摆放的方向也需要检查。三层金属工艺中 pin 口大多在 M1同向摆放可以让相邻单元的 pin 口自然对齐减少 M2 绕线。如果工具因为密度原因自动翻转了一些单元要重点检查翻转位置附近是否有东西向 M2 拥堵的迹象。4.4 时钟树三层金属工艺下的特殊映射技巧时钟树综合在主流数字流程里是一个工具自动完成的步骤但在 Layout-3 Mapping 里必须额外关注。因为芯片没有专门的时钟金属层时钟网络只能挤在 M3 或 M2 上这直接影响信号线的可用资源。我的策略是把时钟树分成两类局部短距离时钟允许走 M2跨区域的时钟主干统一走 M3。时钟树综合的时候给时钟单元设置一个额外的 cap 约束余量让时钟树层级尽量不要超过 3 层。层级越深时钟 buffer 数量越多越容易造成 M2/M3 资源挤占。时钟 skew 的预算按工艺节点来定例如 0.18um 工艺、1.8V 电源下我会把 skew 目标压在 50ps 以内。如果时钟树太深导致 skew 超标不要盲目加大 buffer size先考虑调整时钟拓扑布局尽量让时钟源到每个寄存器的物理距离均匀。时钟网络的金属分配建议和电源网络错开。比如电源 stripe 在 M3 上走南北时钟主干就尽量在 M3 上走东西向的局部短段减少长距离并行降低串扰风险。如果实在避免不了在两个长距离并行信号之间加一条接地线做隔离。4.5 布线映射全局布线到详细布线布线映射是整个 Mapping 过程的核心环节它的目标是让每一条逻辑 net 都变成物理互连同时满足所有 DRC 规则。布线分两步全局布线先把布线资源划分成网格为每条 net 分配一个粗粒度的路径详细布线再在粗路径里逐格填充具体的金属多边形。在全局布线阶段我会先把特殊 net 单独锁定电源、时钟、复位、以及芯片的 IO 时钟。这些 net 不允许布线工具随意调整必须走预定的 M3 通道。锁定顺序很重要先锁特殊 net再让工具自由处理普通信号这样整体效果最稳定。详细布线阶段要关注的是过孔数量。三层金属工艺下面一条长 net 往往需要在 M3 走一段然后通过 V23 跳到 M2 绕一下再跳回 M3。这个过程中过孔电阻会累加到 net 的寄生参数里。如果一条 net 上的过孔数量超过预期时序开销就会明显增加我通常会在关键路径上检查过孔统计。对关键信号走线我还会做屏蔽处理在敏感信号两侧各放一条地线减少相邻信号串扰。但屏蔽的代价很大三层金属下加速走线资源消耗所以只对 3% 以内的关键 net 做屏蔽其他信号靠拉大间距来解决。4.6 物理验证与 GDS 输出布线完成后进入物理验证阶段。DRC 检查是第一步把版图与工艺设计规则逐条比对输出违规清单。违规类型主要包括最小宽度、最小间距、天线效应和金属密度。每一类违规的修复方式不同这里需要结合具体工艺规则来分析。LVS 检查是第二步它把版图中提取出来的晶体管级连接关系与原理图网表进行比对。LVS 通过的标准是你声明的连接关系必须与物理版图一致。LVS 报出的常见问题包括缺失连接、短路、开路、以及 pin 位置标签不匹配。物理验证全部通过后就可以输出 GDS。输出前建议做一次层次化 merge把标准单元 GDS 和顶层版图合并成最终交付文件。合并时注意单元名和层映射的一致性避免交付后被发现层号错位。GDS 输出后我还会做一次逆向抽查选择几条关键 net比如时钟、复位、关键数据路径在 GDS 上手工追踪一遍确认它的物理走线和预期一致。这一步虽耗时但能发现工具在高级优化中自动做的意外变化。5. 三层金属 Mapping 的事故高发段与排查流程跑通了只是第一步真正让设计师加班的是各种反直觉的异常现象。下面几个坑都是我实际踩过的按出现频率排列希望你能提前避开。5.1 利用率才 64%怎么拥塞就爆了第一次承担类似任务时我按传统数字流程的经验把利用率定在 65%以为很保守。没想到的是布线阶段全局布线报告里出现了好几块红色拥塞区域仔细一看都是和 M3 电源条带相邻的通道。根因在于三层金属工艺中M3 的可用通道本来就比三四层金属工艺少。电源条带占用 M3 后其两侧的区域自然形成禁区相当于实际可用布线资源比纸面上少了一大截。我给利用率降到 58% 以后拥塞问题才逐渐缓解。建议在三层金属项目里把电源网络占用的 M3 面积直接扣除后再计算有效利用率不要只看整体的利用率数字。如果一个区域的拥塞预测超过 45%先确认附近是不是有电源条带或时钟主干路过如果是就把该区域的单元密度降一些。5.2 M3 长走线引发的天线效应天线效应是三层金属工艺里最容易忽略的 DRC 违例。当一根 M3 长走线直接连到某个 MOS 管的栅极时这根长走线在工艺制造过程中就像一根天线收集了太多电荷可能击穿栅氧化层。在一次项目的 DRC 报告里出现过几十处 antenna violation全部都集中在 M3 长信号上。修复方式有几种在长走线中间加跳线把一部分金属改到 M2 或 M1切断天线段或者在靠近输入栅极的位置加一个反偏二极管。第一种更干净但会引入过孔第二种需要库里有对应器件不是所有工艺都支持。我的经验是布线前先预估哪些 net 会比较长这些 net 在详细布线时主动插入 M2 跳线。与其等 DRC 报告出来再修不如在一开始就让工具打开 antenna 修复选项。修复选项会限制工程师的自由度但可以大幅减少后期 iterations。5.3 LVS 认不出子单元映射的最后一公里坍塌比较痛苦的一种情况是DRC 全清布线的逻辑连接也看着没问题但 LVS 报告一大堆 mismatch。排查下来发现LVS 的 runset 把某些标准单元当成了同构不同名的单元或者因为 pin 标签缺失导致提取出来的连接完全偏离预期。这类问题根因通常有两个一是标准单元库中的 top cell 没有打上足够的 TEXT label提取器找不到 pin 的正确位置二是 LVS rule 文件里的单元映射表没有覆盖所有单元。建议在跑正式 LVS 之前先做一次纯 pin 核对把版图内的 label 和网表里的 pin 列表做一次交差比对。发现问题就及时补 label而不是直接去修 wiring。修一个缺失 label 可能只要一分钟但因 label 缺失引发的连锁 mismatch可能让人抓狂几个小时。5.4 金属密度不足与 dummy fill 的寄生变化大部分工艺都有金属密度的上下限要求。三层金属工艺中M1 因为标准单元密集密度通常不是问题但 M3 走线少密度经常不足或者反过来说电源条带占满某块区域以后密度过高。密度不足就需要填充 dummy metal也就是在空白区域补上悬浮的金属块。问题在于填充物会改变周围信号的寄生电容让本来干净的走线多出一些容性负载。三层金属工艺尤其敏感因为 M3 和 M2 之间距离近dummy 填充会影响上下两层之间的耦合。我的做法是优先让工具用最小尺寸的 dummy block 填充并且在关键 net 周围设置 keep-out 区域禁止填充 dummy避免关键路径上多出意料之外的寄生电容。这个操作要谨慎用多了会影响整体密度达标效率。密度修复完成后再看一遍关键 net 的时序报告确认没有明显的退化。6. 让映射可追踪Checkpoint 与回归脚本Layout-3 Mapping 的流程涉及多次迭代每次改 Floorplan、调 power stripe、换单元位置都可能引入新的问题。为了不让项目进入改了这里又坏那里的失控状态我习惯在每个阶段设置 checkpoint并做一份检查清单。这份清单不仅帮我控制质量也方便和团队沟通进度。6.1 映射阶段的 Checkpoint 清单我在项目里维护了一张表每个阶段完成后逐项核对。表格的内容不复杂但非常实用阶段检查项通过标准数据准备网表实例数与库单元实例数一致无黑盒Floorplan电源条带位置无 DRC 违规IR drop 估算在 3% 以内Placement单元密度全局拥塞无红色区域CTSskew 报告关键时钟 skew 在预算内Routing过孔/金属利用率M3 使用率小于目标值无拥塞热点DRC违规数所有类别可接受无天线违例LVSmatch 率连接关系完全一致GDS层信息与工艺映射一致单元无缺失这张表我会在每个迭代版本都更新团队讨论时直接看表就知道卡在哪一步。很多问题其实在早期就埋下了比如 Floorplan 阶段电源条带位置不佳到 Routing 阶段才暴露浪费一整轮优化时间。6.2 一个小脚本netlist 与 DEF 实例数核对数据一致性检查阶段我会写几个简单的核对脚本。下面这个脚本用最朴素的方式比较门级网表和版图 DEF 文件里的实例数量能快速发现网表和物理库之间的映射错位。import re def count_instances(filename): count 0 with open(filename, r, encodingutf-8, errorsignore) as f: for line in f: line line.strip() if re.search(r\bINST\b, line) or re.search(r^[A-Za-z0-9_]\(, line): # 这里只是一个占位逻辑实际要按工具格式解析 count 1 return count netlist_count count_instances(design_gate.v) def_count count_instances(design.def) print(fnetlist instances: {netlist_count}) print(fDEF instances: {def_count}) if netlist_count ! def_count: print(MISMATCH: 实例数不一致请检查单元映射) else: print(实例数一致)实际工程里这一步通常直接用 EDA 平台自带的数据检查功能更准确不过脚本的价值在于可以离线跑、可以接进 CI、还能在数据导入之前就发现问题。把脚本保存下来每个新版本进来先跑一遍能省下不少沟通成本。6.3 把映射结果写进日志最后一个习惯可能听起来不太技术但我还是要重点推荐给每个版本的 Mapping 结果建立一份简短的日志记录。记录内容包括输入网表版本、库文件版本、Floorplan 版本、各阶段的关键数字、修改了哪些约束、以及 DRC/LVS 的通过情况。有一次项目进行到一半进度被迫中断两周后重新启动如果没有日志帮助我几乎不可能回忆起当时选择了哪套电源条带参数。写日志不需要写长文章每版写十行左右就够重点是让接下来的人能够顺利接着做。三层金属 Mapping 迭代频繁靠记忆是撑不住的这大概是我在这个项目里获得的最宝贵经验。最后再分享一个小技巧在 GDS 交付前给关键 M3 net 打上 TEXT label比如 clock、reset、以及几条关键数据通路。这样下次改版或者出故障时可以最快速度在版图浏览器里定位到对应网络省去在几千条 net 里逐个排查的时间。这个动作几乎不增加成本但在后期调试里的回报极高。