数字IC设计避坑指南：为什么477条net的DRV问题无法修复？解析don‘t touch hierarchy的影响

原创

于 2026-02-26 20:24:37 发布 · 267 阅读

数字IC设计避坑指南：为什么477条net的DRV问题无法修复？解析don't touch hierarchy的影响

在数字IC后端实现的深水区，工程师们常常会遭遇一种令人困惑的局面：时序优化工具（如Cadence Innovus）在place_opt_design或optDesign阶段报告了大量无法修复的DRV（Design Rule Violation）违规，其中相当一部分（例如477条）的失败原因被标记为“term is inside don’t touch hierarchy”。这个看似简单的log信息背后，隐藏着物理实现流程中约束管理与工具行为交互的复杂逻辑。对于追求设计收敛和性能极致的团队而言，理解这477条net为何“动弹不得”，远比盲目地尝试各种优化命令更为重要。

本文将从一个真实的工程场景切入，深入剖析don't touch约束层级如何成为DRV修复的“隐形墙”。我们不仅会解释其背后的物理实现原理，更会提供一套识别、诊断和解除无效约束的实用策略。与那些只介绍命令用法的常规教程不同，我们将聚焦于特定错误类型的根因分析，帮助中高级工程师建立系统性的问题排查思维，从而在项目后期避免陷入被动，确保设计能够按时、高质量地tapeout。

1. 理解DRV修复机制与“don't touch”的冲突

在深入案例之前，我们首先需要建立两个核心概念的基础认知：DRV修复的常用手段与**don't touch约束的设计意图**。这两者在后端流程中的相遇，往往就是问题产生的起点。

DRV通常指代设计规则检查，在后端实现中特指max transition（最大转换时间）、max capacitance（最大负载电容） 和 max fanout（最大扇出） 这三类与物理特性强相关的约束。其中，max transition违规最为常见，它意味着信号在net上的上升/下降时间过长，可能引起时序计算不准确、功耗增加甚至功能故障。

工具修复max transition违规，主要依赖两种基本操作：

Upsize Driver：增大驱动单元的尺寸（例如，将驱动反相器从最小尺寸换为更大尺寸的版本），以提供更强的驱动能力。
Insert Buffer：在负载过重的net上插入缓冲器（Buffer），将长线分割为多段，每段由独立的单元驱动，从而降低单一线网的负载。

这两种操作本质上都是对网表（netlist）的修改——增加、删除或替换标准单元（standard cell）。

而**don't touch** 约束（或其变体size_only）则是一种设计保护机制。它被施加在特定的设计对象（instance, net, hierarchy）上，明确告知优化工具：“此对象的结构或属性不得更改”。设置don't touch的常见原因包括：

关键路径保护：防止工具对已经手动优化或极其敏感的路径进行可能劣化时序的改动。
模拟模块或IP隔离：保护模拟电路、存储器（Memory）、PLL等定制化模块的完整性。
工程变更指令（ECO）预留：为后续的ECO操作预留特定的单元或网络。
避免工具过度优化：防止工具在某些区域进行无休止的、可能带来负面效果的迭代。

当一条存在max transition违规的net，其驱动端（driver）或负载端（load）的单元被标记为don't touch时，修复操作就陷入了逻辑死锁。工具无法替换（upsize）一个被声明为“不可触碰”的驱动单元，也无法在一条连接着“不可触碰”单元的net上自由地插入Buffer，因为插入Buffer意味着修改了该net的拓扑结构，这可能被视为对其连接单元的“触碰”。