不开玩笑做过几个大芯片项目之后你会对“层次化”这个词有生理反应。数字IC后端做到5nm、3nm这个节点动辄上百亿晶体管、数亿个标准单元扁平原生流程Flat Flow单次布局布线不仅跑不动时序收敛和物理实现复杂度也根本压不住。这个时候层次化Hierarchical Flow就成了唯一可行的路把大设计按功能模块拆成一个个Sub-System、再往下切成Block每个模块分头做物理实现最后在顶层拼装验收。这套流程里block partition模块划分和pin assignment引脚分配是最容易在项目中期爆炸的两个环节——拆得好后端收敛顺利拆得糙后面都是返工地狱。这篇文章把这两个环节的系统性细节摊开讲清楚从划分思路到引脚分配的具体操作再到后期时序收敛和常见问题排查全部是流片级项目的实操经验总结适合数字IC物理设计工程师、后端新人以及想理解Hierarchical流程的架构师、前端同事参考。1. 层次化流程的整体思路与Sub-System定位1.1 什么是层次化设计流程层次化Hierarchical Flow简单说就是把一个大芯片拆成多个独立实现、最后再逐级往上集成的物理设计流程。和扁平化流程把全芯片几千万个单元一次性摆进布局布线工具里不同层次化流程在RTL阶段或综合阶段之后就把设计按层级切割成若干个子模块每个子模块单独做floorplan、布局、时钟树综合、布线、签核最后在顶层把各模块的结果摆好、连好做最终时序收敛。理解这个概念有一个关键点层次化不只是“工具跑得动”的权宜之计它本身也是一个芯片架构决策。拆分的粒度、边界、接口关系会反过来影响前端RTL架构、DFT方案甚至封装方案。所以项目初期后端工程师就必须介入跟架构师一起定SoC顶层的物理划分。1.2 Sub-System在层级中的定位Sub-System是介于SoC顶层和普通Block之间的一个层级。举个例子一颗移动SoC芯片可能有CPU Sub-System、GPU Sub-System、多媒体/ISP Sub-System、NPU/AI加速器Sub-System、Modem基带Sub-System等。每个Sub-System内部还有好几个Block比如CPU Sub-System下还有CPU core cluster、L2 Cache、中断控制器等。Sub-System的定位决定了三点它是独立的电压域/电源域单位。不同的Sub-System经常工作在不同电压或频率下电源分配网络PDN设计按Sub-System划分。它是物理尺寸适配的单位。每个Sub-System的面积、长宽比、pin数量、单元密度都相对可控可以单独floorplan并优化。它是复用和验证的边界。IP尽可能以Sub-System为单位复用验证环境也按照Sub-System建好抽象层。在实操中我强烈建议在项目早期就明确一个“典型Sub-System”的面积规模和pin数量范围制定统一的划分标准。比如定义一个Sub-System面积不应超过2到3平方毫米、接口pin数不超过2000根等这样后面拆block时有章可循不会出现一个Sub-System里塞了10个功能模块、另一个Sub-System只有零头的情况。2. block partition细节盘点从架构意图到物理约束2.1 划分原则时序、物理与复用三个维度的平衡block partition是整个Hierarchical Flow中最考验后端工程师功力的一步。拆得不够单个block仍然太大、工具跑不动拆得太碎顶层连接关系和引脚分配复杂度飙升、时序更难收敛。一个可落地的block划分原则要同时看三个维度时序维度切割位置尽量选在时序裕量充裕的地方。理想切割点是“寄存器到寄存器”的接口路径上因为这种路径可以靠顶部接口时序约束input delay/output delay精确建模。绝对避免把组合逻辑云切开——即某个组合逻辑链路的输入端在A block输出端落在B block这种切法会让接口时序异常复杂而且后期ECO工程变更极难传播。物理维度每个block的面积利用率utilization、形状系数aspect ratio、宏单元分布要均匀。有些伙伴切block只按功能边界切切完后发现一个block里塞了三个大型SRAM另一个block几乎全是逻辑标准单元两者密度差异巨大floorplan和电源电压降IR drop分析时都会出问题。复用维度一个核心问题——这个模块以后还要不要升级要不要在其他项目中复用如果答案是肯定的那么在划分时就要留出接口一致性和物理边界的余地不能只盯着当前项目的需求。2.2 面积预估和pin密度评估的两条经验曲线做过几个项目后我总结出两个在partition审阅阶段非常实用的评估指标一是面积均衡度二是pin密度。面积均衡度很好算每个block物理面积除以总可用面积求标准差标准差异常大的划分策略是危险信号。实践中我希望一个Sub-System下各block面积的变异系数标准差/平均值控制在30%以内。超过这个值大概率会出现某一个block面积过大、floorplan跑不动另一个block面积太小、顶层连接浪费资源的情况。pin密度更值得细看。pin density的定义是block边界的pin数量除以对应边界的可用周长。一个block如果只有两条边出pin一条边密集地拥着七八百根线、另一条边只有十几根这个pin分配策略基本上在后面绕线阶段是要爆的。经验规律是单边pin密度控制在每微米0.05到0.1根线左右是相对安全的超过这个值就要开始考虑加pin层、调整pin方向或者重新思考这个block的划分边界。2.3 时钟与复位网络在划分时就被决定block partition还必须考虑时钟网络的边界。这里有实际教训某项目前期划分时把时钟控制器clock gating cell放在顶层把下游寄存器放在下层block当时觉得没什么——反正都是标准单元放在哪里都行。但到了时钟树综合CTS阶段就麻烦了顶层时钟单元跟下层block内部的clock sink穿过层次边界CTS工具对跨block时钟路径的延迟计算和correlation精度都很吃力clock skew根本收敛不了。正确的做法是在划分阶段明确每个block的时钟入口和出口。推荐把大部分clock gating、clock buffer下放到block内部block只保留一个到几个干净的时钟输入端口顶层不做过多的时钟逻辑。类似地复位网络也尽量在block内部生成局部复位同步逻辑避免异步复位穿越block边界的时序分析复杂度。2.4 功耗域与隔离逻辑的归属在现代低功耗设计中功耗域划分直接影响block partition。策略上把同一个电压域的单元尽量放在同一个block里这样电压域管理power switch cell、isolation cell、level shifter都集中在block内部来实现避免跨block的电源管理信号弯曲绕线。我曾经见过一个激进的做法一个掉电block和常开block共享一个物理区域只是通过电源开关单元物理隔开。这种设计虽然节省了面积但是给后端的IR drop分析和物理验证特别是ESD/闩锁检查带来了巨大的工作量。我个人的经验是如果项目周期紧张宁可多花一点面积把电压域边界捋清楚也不要为了省面积把电源域物理边界搞得很模糊。省下来的验证时间远比那一点面积值钱。2.5 划分粒度的五个经验阈值最后给出我在多个项目里验证过的划分粒度参考值直接拿来当启动值用是可以的参数经验阈值超过后建议动作block内标准单元数超过500万到800万个实例继续下切或调整partition边界block面积超过3到4平方毫米视工艺节点重新评估floorplan或拆分单block pin数超过1500到2000根信号pin检查信号分组、增加pin层或调整方向interface timing slack超过负裕量难以收敛重新审视切割位置是否穿过关键路径顶层剩余逻辑超过总逻辑量的8%到10%顶层逻辑太厚建议多切或调整颗粒度这个表不是硬性指标不同工艺节点和项目类型会有差异但方向是一致的让每个block的规模在可控范围内让顶层的“剩余工作”尽量少让每个block的物理实现可以独立完成。3. pin assignment实操细节引脚分配的完整方法论3.1 pin的类型与位置规划策略pin assignment引脚分配在所有后端环节里看起来最简单但坑最多。一个block的pin分配需要处理的pin类型包括信号pin数据、地址、控制信号数量最多时序相关时钟pin时钟网络的入口复位pin异步复位/置位信号Scan接口pinDFT扫描链的输入输出通常要跟前后级block对齐Power/Ground pin电源地PG在抽象化处理时也要占用资源规划顺序上我习惯先处理时钟和复位pin再处理scan和特殊信号最后安排普通数据信号。时钟pin的位置要优先靠近该block内部时钟树的平衡中心复位pin尽量靠近复位逻辑位置scan pin则要尽量贴合DFT chain的进出方向减少扫描链在block内部的绕转。有一个非常容易犯的错误是把大量数据pin均匀分布在所有边上看似很“平衡”实际上完全忽略了内部宏单元的位置。比如block底部有一排记忆体宏单元结果你把大量数据pin集中在底部导致从pin到宏单元的走线穿过大半个block拥塞直线上升。正确做法是pin assignment之前先结合floorplan图和宏单元位置把“pin到第一级sink的距离”作为权重离得近的边多放离得远的边少放。3.2 pin方向和布局的时序驱动决策pin direction是pin assignment中被严重低估的参数。一个block的引脚可以朝东出输出信号走向右方相邻block、可以往西出、也可以双向。错误方向的pin会导致信号在顶层绕一大圈再从对面出去白白多走几百微米线时序和功耗同时恶化。好的做法是把pin direction和顶层布图规划top floorplan联动起来看。比如top floorplan里A block在左边、B block在右边两者之间有大量总线连接那么A block的右侧pin和B block的左侧pin就应该是高密度区A block左侧保持低pin密度。这个决策必须在partition完成后、pin assignment开始前就有一个顶层连接示意图否则等每个block各自assign完pin、在顶层集成时才发现连接关系混乱返工成本极高。实操中我推荐至少做三轮pin assignment迭代第一轮基于top floorplan连接关系的初分配。不追求精确位置先把pin的归属边、方向、大致区域定下来。第二轮结合block内单元分布的细化调整。打开floorplan把每个宏单元、大扇出单元的位置纳入考虑把pin尽量调整到它们附近。第三轮基于绕线拥塞热图的微调。在初步布局布线trial route之后把pin区域的congestion热图调出来对热点区域的pin间距、pin层进行散布调整。3.3 pin层选择与扇出优化pin的层选择对可布线性影响很大。现代后端工具支持在多个金属层上放置pin但不同层的绕线资源、方向、间距规则都不一样。经验策略是数据pin优先放在中间信号层比如M3/M4/M5避免占用顶层厚金属M7/M8以上的电源地绕线资源电源地pin不能省尤其在低层金属上要留足PG pin的位置如果是超大pin数的block用两到三个金属层交替分配pin降低单层拥塞扇出优化是另一个实战细节。一个数据pin连接多个逻辑单元其扇出数fanout过高会导致该pin到内部sink的走线延迟很大直接影响时序。在后端实现时我会要求pin assignment完成后检查所有输入pin的等效扇出对大于某个阈值比如30的pin在block边界附近加buffer tree来驱动。至于为什么要放在block边界而不是block内部中央原因是这样切割后的抽象模型ILM或ETM能够更精确地建模这部分负载顶层的时序评估会更接近真实情况。3.4 pin assignment的检查清单实操中我习惯用下面这份检查清单来审阅pin assignment结果每次都能挑出问题是否有冗余pin有些信号在源端和目的端其实可以通过绕线调整合并但被assign成两个独立pin白白增加顶层绕线资源时钟pin是否与时钟树平衡中心靠近时钟pin如果离时钟树太远顶层时钟延迟会有很大差异同方向pin密度是否均匀有没有某一小段边界集中了上百根pin而旁边几十微米一根pin都没有信号方向与顶层连接图是否一致有没有pin方向分配错误导致信号要绕远路scan接口pin是否与DFT链前后级block对齐是否有足够的PG pin预留特别是在电流密度需求大的block周围是否考虑后期ECO预留位置经验是在高改动概率的区域留10%到15%的pin空位置这个清单每次review都能用是花了几次late change的代价换来的。别偷懒跳过。4. 顶层集成与跨block时序收敛策略4.1 顶层抽象模型的选型与精度权衡block各自实现完成后顶层如何对待这些block是决定流程成败的关键。根据抽象模型的不同顶层对下层block的感知粒度也不一样常见的有三种ILMInterface Logic Model、ETMExtracted Timing Model和FRAMFull Register Abstract Model。ILM保留接口附近的逻辑单元和寄存器精确度最高最适合对接时序要求极其严格的跨block路径。代价是ILM的尺寸不小顶层跑loading会变重。ETM把block内部逻辑压缩成带有时序约束的黑盒模型大小小得多精度略低但完全够用于大部分顶层时序收敛。FRAM一般用于功耗、面积等物理特性评估。我个人的选型经验是对CPU、GPU的高频子系统使用ILM因为这些模块的接口时序既严苛又密集对一般的IP block、外设总线等使用ETM就够了抽模型时注意覆盖所有接口时序模式对保守估计、全局平面图调整等中间阶段先用ETM快速迭代4.2 接口时序约束的设定与guard band接口约束interface timing constraint是Hierarchical Flow里最容易出问题的环节。每个block在独立实现时其输入输出端口都有一个由前端或顶层集成提供的set_input_delay/set_output_delay约束。这个约束如果过松block内部可能做得非常“松懈”但真正集成到顶层时跨block路径根本没有那么多裕量直接导致顶层时序失败如果过紧block内部为了满足不可能达到的接口时序付出了大量面积和功耗代价。处理这个问题我的做法有三步第一步从顶层脚本抽取“真实”的接口路径延迟用PrimeTime/Tempus在顶层初步跑一遍得到每个block实际的接口到达时间和需求时间反推生成block级约束而不是用前端拍脑袋给的粗略值。第二步给接口约束留合理的guard band通常推荐在每级block接口上额外加30到50皮秒的裕量。如果你对抽象的精度没信心保守一点留到80到100皮秒也不要为了追求“没有额外裕量”的极致而牺牲收敛时间。第三步在顶层集成阶段重新跑一次全芯片时序用真实的block内部时序模型校准之前的guard band合理性。4.3 跨block路径的时序优化手段跨block路径是层次化流程中时序收敛的痛点。所谓跨block路径就是一个信号从A block的寄存器出发经过A的输出pin穿过顶层绕线进入B block的输入pin最终到达B block里的寄存器。这条路径被拆成了三段分别在三个不同的实现过程中被优化任何一个环节出现问题整条路径都不满足时序。优化手段按作用范围排序pin位置和方向精确化这是成本最低的优化。保证A block的输出pin和B block的输入pin尽量靠近、方向对应直接降低顶层绕线长度。顶层缓冲器插入buffer insertion在顶层较长的跨block连接上插入buffer把一个大延迟拆成两段可均衡的延迟。推荐用top-down方式实现这些buffer方便控制层次边界。下游block的输入延迟修正当发现某个跨block路径因上游延迟过大而违反时序时可仅调整下游block的input delay约束并做incremental实现而不必重做整个block。这是层次化流程最划算的ECO手段。register retiming / pipelining如果上述手段都无效这条路径需要前端参与在跨block接口插入寄存器。做好跨功能团队沟通别自己默默改RTL。4.4 顶层与block的一致性验证层次化流程最大的暗坑是“每个block独立看起来都对凑到一起就是不对”。所以顶层集成后的一致性验证consistency check不能省。我重点检查三块逻辑一致性顶层连接关系是否与netlist一致有无漏连、错连的信号。物理一致性各block的边界坐标、方向、大小是否与顶层floorplan完全对得上有没有一个block的边缘被另一个block的pin架到头上。时序一致性block内部时序与抽象模型时序之间的correlation抽一个block做全量对比看看接口路径的差别是否在预定义范围内。这块工作量不小但每次做都能挡掉若干个低级事故。不要因为“工具都是自动的”就跳过工具自动不等于结果正确。5. 常见问题与排查技巧实录5.1 经典问题速查表把我在多个项目里踩过的坑整理成一张速查表按问题现象、根因、解决方案分组问题现象根因分析解决方案单个block内部时序好顶层集成后跨block负slack接口约束偏松、抽象模型不精确反推真实接口延迟重生成约束加guard bandpin区域拥塞严重trial route后congestion热点集中在边界pin密度分配不均衡、pin层选择不当重新迭代pin assignment在热点区域疏散pin、增加pin层block内部CTS完成后clock skew超标时钟入口位置远离时钟树平衡中心调整时钟pin位置或将时钟gating cell下放到block内部顶层绕线时发现A block pin和B block pin方向相反pin direction未结合顶层floorplan连接关系前期先画连接示意图再assign pin方向某block面积利用率极低、周边大量空白partition时面积预估偏差过大调整block边界并入相邻小模块或重新划分ILM/ETM模型和block全量时序对比差异超过预期模型抽取条件不对、边界约束不一致重新确认模型状态和约束检查时钟定义一致性5.2 三个记忆深刻的实战案例第一个案例是接口约束过松引发的连锁返工。有一个NPU Sub-Systemblock独立实现时所有路径slack为正看起来极其健康。结果顶层集成一跑跨block的接口路径全线翻红最差的一条负了200多皮秒。排查下来发现block级input/output delay还是项目早期前端给的非常宽松的估计值与真实顶层路径偏差巨大。后来花了两次ECO迭代才救回来。这次经验让我把“反推接口约束”变成了流程的固定环节每个block在做signoff之前必须先跑一次顶层初步实现来校准边界约束绝不允许直接套用早期估计值。第二个案例是pin分配过于平均、导致信号绕路。某个interface block信号很多当时图省事选了四边均匀出pin看起来清清楚楚结果顶层floorplan里这个block三面都被大模块包围只有一侧有实际数据交互需求。那些从其他三面出去的pin在顶层全部要绕过block本身才能到达目的地顶层绕线长度多了将近40%。后来把pin assignment改为顶层连接关系驱动绕线长度立刻降回来顶层时序也从勉强收敛变成宽裕收敛。第三个案例是复用模块的pin assignment冲突。一个从旧项目继承下来的IP blockpin位置和间距都是旧版floorplan的产物。在新项目里这个block的电源地需求更大了但旧版pin assignment没有预留足够的PG pin位导致电源网络在边界处拥挤。我们用了两个办法解一是把该block周围几个pin层都打开让部分信号pin改走高层金属把低层金属让给PG pin二是在floorplan里给该block多留了30微米的margin让PG pin在边界外散开。这个教训告诉我复用模块的pin assignment在项目启动时就要重新审一遍不要想当然“以前能用现在也能用”。5.3 绕开调试陷阱的三条实用建议第一善用“最短路径优先”原则排查跨block时序问题。当一条跨block路径slack为负时先不要急于改约束、加buffer而是在工具中把这条路径的布线路径高亮出来计算一下pin到pin的实际走线长度。如果长度远超两block中心点的直线距离问题大概率在pin位置或绕线改约束没用如果走线长度正常但还是不满足时序再考虑delay和skew的问题。第二对所有跨block接口做统一的命名规范。不同团队负责不同block时如果信号命名风格不一顶层的自动化检查脚本很难写全。我建议在项目初期定义一套“接口信号命名位置文档”的三方约定前端RTL实现、后端物理实现、顶层集成验证都用同一套文档来对齐。这个文档比任何脚本都值钱。第三保留一个“简化版顶层时序模型”。在项目初期流程尚未定型时我习惯维护一个不包含任何ILM/ETM抽象、直接把所有block当成黑盒且只建模接口路径的简化顶层时序模型。它跑得很快可以用来快速试错、验证接口约束变化对整个芯片的影响方向。等到流程成熟了再把它替换成完整抽象模型。这种“快进快出”的调试手段能大幅缩短顶层时序收敛的迭代周期。6. block partition和pin assignment工具链选型解析6.1 主流EDA工具在层次化流程中的分工数字IC后端层次化流程涉及的工具链主要由综合、物理实现、静态时序分析三部分组成。综合阶段通常用Design CompilerSynopsys或GenusCadence完成逻辑综合可以根据层次化划分生成具有清晰层级结构的门级网表。物理实现阶段用ICC2/Fusion CompilerSynopsys或InnovusCadence这两套工具都原生支持Hierarchical Flow能做block级floorplan、place、CTS、route以及顶层集成的chiplets级物理排布。时序签核以PrimeTimeSynopsys和TempusCadence为主负责抽象模型生成、全芯片时序收敛以及ECO时序验证。工具选型的核心评估标准不是单个工具的功能列表而是跟你团队的既有流程和项目特点的匹配度。比如你所在的团队在Innovus生态里积累了大量的floorplan和CTS脚本那就尽量不要跨工具切换因为迁移脚本和重新优化CTS recipe的时间成本远高于工具本身功能的微小差异。6.2 工具相关参数设置与抽象模型生成要点在生成抽象模型ILM/ETM时有几点参数设置直接决定模型精度时钟端口定义必须完整。如果模型里缺了一个时钟定义顶层对该时钟的路径分析会全部失效。接口时序约束的max/min必须同时抽取。很多工具默认只抽setupmax分析的数据如果忽略holdmin分析跨block路径在真实硅片上可能会有可靠性问题。对于异步跨时钟域路径在模型生成时要在顶层设置false path或约束说明否则模型会把不存在的时序路径当成违规来报。针对时钟门控单元ILM模式下尽量保留网表单元以支持近似的时钟门控检查。6.3 流程自动化脚本建议层次化流程中自动化脚本的核心作用是“一致性”而非“花哨”。建议至少实现三个脚本一个自动生成block级约束的脚本从顶层时序结果中反推每个block的input/output delay并输出为SDC文件。这个脚本应该可以一键运行不允许手动复制粘贴数据。一个自动检查pin assignment合规性的脚本比对pin density上限、PG pin预留、时钟pin位置等规则输出告警。一个自动对比抽象模型与full-netlist时序的脚本当block更新后自动跑一次相关性检查提前发现抽象模型失真的情况。写这三个脚本并不复杂用一个成熟的Perl/TCL/SDC解析库在项目开始后两周内就能完成第一版。但它们的价值非常大这些脚本让整个流程从“靠人review”变成“靠工具检查人review”大幅降低了低级错误的概率。7. 总结与个人经验分享写了这么多最后分享几点我在多个流片项目里沉淀下来的体会。第一block partition和pin assignment从来不是“某一个工程师的活”它们是跨角色协作的接口。前端架构师、DFT工程师、后端工程师、封装工程师在项目早期就应该坐在一起把划分边界和pin计划敲定。越早对齐后期返工越少。第二“简单但可预测”优于“精致但不可控”。很多时候我们会在pin assignment上追求极致的时序最优导致方案非常复杂、后期稍微改一个信号就要动一堆pin。我后来慢慢学会给方案留出容错空间哪怕时序上稍微次优一两个百分点也要保证方案的稳定性和可维护性。第三流程文档比技术本身更容易被低估。每个项目结束后把partition决策的原因、pin assignment的版图截图、遇到的问题和解决办法沉淀成文档。这些文档在下一个项目里会变成最宝贵的启动资产。技术会过时踩坑的经验不会。希望这篇关于数字IC后端层次化流程中block partition和pin assignment的盘点能对正在做或准备做Hierarchical Flow的你有帮助。遇到具体问题欢迎私下沟通一起把坑填平。