2. Innovus设计数据库与拥塞相关对象

在 Innovus 中做拥塞分析，第一步不是急着跑 reportCongestion，而是先弄清楚“数据库里到底有哪些对象、它们之间是什么关系”。因为拥塞报告里的每一个数字，最终都能追溯到某个具体的 cell、pin、net、track 或 gcell。如果对数据库对象没有概念，看到报告里的 overflow 只能凭感觉猜，无法定位到真正的物理原因。

一、设计数据库的层次：从逻辑到物理

Innovus 的设计数据库（Design Database）可以理解为“逻辑设计 + 物理实现”的叠加。逻辑侧来自网表，物理侧来自 floorplan、placement 和 routing。两者通过 instance 与 cell 的映射绑定在一起。理解数据库，关键是分清下面几类对象：

  • Cell（单元）：库中定义的逻辑功能单元，如 INV、NAND2、DFF。它只有逻辑和时序信息，没有位置。
  • Instance（实例）：cell 在设计中一次具体的“使用”。instance 有名字、有位置、有朝向，是物理对象。拥塞分析中真正占面积、占布线资源的是 instance。
  • Pin（引脚）：cell 上的连接点，分输入、输出、电源地。instance 的 pin 有确定的坐标，是布线起点和终点。
  • Net（网络）：连接一组 pin 的逻辑线网。net 本身是逻辑概念，但它的布线实现会占用 track 资源。
  • Floorplan：芯片的物理边界、core 区域、IO 摆放、macro 位置、power ring 等，决定了哪些区域“可用”、哪些区域“被占”。
  • Placement：标准单元在 row 上的具体位置，决定了局部单元密度和 pin 分布。
  • Routing：net 在金属层上的实际走线，由 segment、via 组成，占用 track。

这七类对象不是并列的，而是层层嵌套：floorplan 划定空间，placement 把 instance 放进空间，routing 把 net 连起来，而 cell、pin、net 是贯穿始终的逻辑锚点。拥塞，本质上是“routing 需求”与“可用 track 供给”在某个局部区域上的矛盾。

二、拥塞分析的底层数据结构

Innovus 不会对每个 pin 逐一计算拥塞，而是把芯片切成网格来统计，这就是 gcell（grid cell）。gcell 是拥塞分析的基本空间单位，通常由 setPlaceMode -congGrid 或默认规则决定，常见尺寸在几微米到十几微米量级。每个 gcell 内部会统计：

  • 该区域内所有 net 的布线需求（demand），通常按层、按方向分别累计；
  • 该区域内可用的 track 数量（supply），由金属层数、track 间距、blockage、macro 遮挡共同决定；
  • overflow = demand − supply，正值表示拥塞，负值表示余量。

Track 是布线的最小“车道”。每一层金属有自己的 preferred direction（如 M1 水平、M2 垂直），track 就是沿该方向等间距排列的虚拟线。一个 gcell 在某层的可用 track 数，等于该 gcell 宽度除以 track pitch，再扣除 blockage 和 power 占用的部分。因此，拥塞报告里的 supply 不是固定值，它会随 floorplan、power plan、blockage 变化。

Layer 则决定了“往哪走”。低层（M1、M2）通常给标准单元内部和短连接，高层（M5 以上）给长线和跨模块连接。如果高层 track 被 macro 或 power stripe 大量占用，长线被迫下压到低层，低层立刻拥塞——这是先进工艺里非常典型的拥塞成因。

三、对象之间的依赖关系

把上面的对象串起来，可以得到一条清晰的因果链：floorplan 决定 macro 和 blockage 的位置 → 影响每个 gcell 的可用 track（supply）→ placement 决定 instance 和 pin 的分布 → 影响每个 gcell 的 net 需求（demand）→ routing 在 track 上实际落线 → 最终表现为 gcell 的 overflow。任何一个环节变化，拥塞图都会跟着变。

Innovus 拥塞相关对象与数据流 Cell（库单元） 逻辑/时序定义 Instance（实例） 位置/朝向/面积 Pin（引脚） 坐标/方向/层 Net（网络） 连接关系/线长 Floorplan 边界/Core/Macro/Blockage Placement Row/密度/局部聚集 Routing Segment/Via/金属层 Gcell（网格单元） 拥塞统计基本单位 Track（布线轨道） Supply 来源 / 方向 Layer（金属层） Preferred Direction Gcell Overflow = Demand − Supply 正值 → 拥塞热点；负值 → 布线余量 逻辑对象 物理实现 底层结构

四、用对象视角读拥塞报告

理解了对象关系，读报告就有了抓手。假设某设计在 M2 层出现一片 overflow，可以按下面的顺序排查：

  1. 看 floorplan：该区域是否有 macro 或 power stripe 占用了 M2 的 track，导致 supply 偏低。
  2. 看 placement：该区域是否标准单元密度过高，pin 密集，导致 demand 偏高。
  3. 看 net：是否有大量长线被迫走 M2，而不是走高层。
  4. 看 gcell 尺寸：如果 gcell 太大，热点会被平均掉；太小则统计噪声大。必要时用 setPlaceMode -congGrid 调整后重新评估。

下面是一段常用的拥塞查看命令示例，用于把 gcell 级别的 overflow 映射回具体对象：

# 查看整体拥塞分布
reportCongestion -overflow

# 查看指定区域的 gcell 拥塞详情
reportCongestion -gcell -area {100 200 300 400}

# 查看某条 net 的布线需求与经过的 gcell
reportCongestion -net my_net_name

# 高亮拥塞热点，便于在 GUI 中定位
highlightCongestion -overflow -layer M2
gcell 的 supply 不是常数。同一块区域，floorplan 调整前后、power plan 修改前后，supply 都会变。因此对比两次拥塞报告时，必须确认 gcell 划分和 layer 设置一致，否则数字没有可比性。

五、几个容易混淆的点

Cell 与 Instance 的区别：cell 是“类型”，instance 是“个体”。一个 NAND2 cell 可以在设计里出现上千次，对应上千个 instance。拥塞分析关心的是 instance 的位置和 pin 分布，而不是 cell 的逻辑功能。

Net 与 Routing 的区别：net 是逻辑连接，routing 是物理实现。一个 net 在 placement 阶段只有估算线长（HPWL），到了 routing 阶段才真正占用 track。拥塞分析在 placement 阶段用的是估算需求，在 routing 阶段用的是实际需求，两者会有偏差。

Track 与 Layer 的关系：track 属于某一层，方向由该层的 preferred direction 决定。M1 水平、M2 垂直是常见约定，但不同工艺可能不同。做拥塞分析前，先用 reportLayerInfo 确认每层的方向和 pitch，避免把方向搞反。

不要把 gcell overflow 直接等同于“布线一定失败”。overflow 是统计意义上的资源超支，router 可以通过绕线、换层、拆线等方式缓解。真正决定能否布通的是 detailed routing 结果。拥塞分析的价值在于提前发现高风险区域，而不是给出最终结论。

总结来说，Innovus 拥塞分析依赖的是一套“逻辑对象 + 物理对象 + 底层网格结构”的三层数据模型。Floorplan、placement、routing 决定物理现实，cell、instance、pin、net 提供逻辑锚点，gcell、track、layer 负责量化统计。把这三层关系理清，后面看拥塞图、调 floorplan、改 placement 时，才能知道每一步操作到底影响了哪个对象、哪份数据。

← 上一章 📖 返回目录 下一章 →