1. 绪论

1.1 从“跑得通”到“跑得快”——时序收敛的困境

各位同学好，我是老张。做数字后端十几年了，我最大的感受就是：时序收敛这件事，越来越像一门玄学。

早些年，工艺还在180nm、130nm的时候，时序收敛基本就是“算算线延迟，调调buffer”。那时候的芯片，门数少，频率低，走线也简单。你只要把约束写清楚，工具基本能给你一个八九不离十的结果。

但现在呢？7nm、5nm甚至3nm工艺下，情况完全变了。

为什么会这样？说白了，有三大原因：

• 互连线延迟占比飙升——以前门延迟占大头，现在线延迟占了70%以上。你想想看，线延迟不再是“算出来的”，而是“猜出来的”。因为制造过程中的随机性、温度、电压波动，都会让实际延迟和模型差一大截。
• 设计规模爆炸式增长——一个SoC动辄几十亿门，几万个宏单元。工具跑一次PR就要好几天。你改一个约束，重新跑一遍，三天过去了。这种迭代速度，根本跟不上项目节奏。
• 低功耗要求越来越苛刻——多电压域、电源关断、动态电压频率调整……这些技术让时序路径变得极其复杂。我见过一个项目，光电压域就有十几个，跨域路径的时序分析简直让人头大。

嗯，这里要注意：很多人以为时序收敛只是“工具的事”。其实不是。工具只是你的助手，真正决定收敛速度的，是你的设计方法学。

1.2 拥塞——那个被忽视的“隐形杀手”

聊到拥塞，我得先讲个故事。

几年前我接手一个AI加速器项目。前端团队拍着胸脯说：“时序约束没问题，我们已经在RTL级验证过了。”结果呢？PR跑完，setup violation一大堆。我一看，不是时序约束的问题，是拥塞。

芯片中间区域，走线密度超过了90%。工具为了绕开拥塞区域，不得不把信号线绕远路。这一绕，延迟直接翻倍。时序自然就崩了。

拥塞为什么是“隐形杀手”？因为它不会直接报错。工具不会告诉你“这里太挤了，时序会出问题”。它只会默默地绕线，然后给你一堆时序违例。你查来查去，以为是约束没写对，其实是物理实现出了问题。

拥塞的典型表现有哪些？我列几个常见的：

• 局部走线密度过高——比如某个区域走线利用率超过85%，工具就会开始绕路
• 宏单元（macro）摆放不合理——宏单元之间留的通道太窄，信号线挤不过去
• 标准单元密度失衡——某些区域cell堆得太密，导致绕线资源不足
• 电源网络占用过多走线层——特别是高层金属被电源/地线占满，信号线只能走低层

你想想看，如果一条关键路径上的信号线，因为拥塞被迫绕了3倍的距离，那它的延迟会变成多少？嗯，基本就是线性增长。这种情况下，你就算把buffer尺寸调到最大，也救不回来。

1.3 拥塞与时序的“相爱相杀”

拥塞和时序之间，其实是一种恶性循环。

我画了一张图，帮你理解这个关系：

你看，这个循环一旦形成，就很难打破。你为了修时序，插了更多buffer，结果单元密度增加，拥塞更严重。工具为了绕开拥塞，又把线绕得更远，延迟反而更大。最后你发现，时序违例越修越多。

我曾经在一个项目中，花了整整两周时间修一条关键路径。每次插buffer，时序好一点点，但拥塞就恶化一点点。最后我实在没办法，把那个区域的几个宏单元重新摆了一下，拥塞降下来了，时序反而自动收敛了。嗯，这就是典型的“治本”思路。

1.4 课程目标：从“被动修”到“主动防”

这门课的目标，就是帮你建立一套拥塞驱动的时序收敛方法学。

说白了，就是让你在设计的早期阶段，就能预判到哪些地方会出拥塞问题，从而提前规避。而不是等到PR跑完了，看到一堆时序违例，再去被动地修。

具体来说，这门课会覆盖以下内容：

章节	核心内容	实战价值
第2章	拥塞的物理根源与量化指标	学会读懂拥塞报告，定位问题区域
第3章	拥塞对时序路径的影响机制	理解拥塞如何转化为延迟增量
第4章	Floorplan阶段的拥塞预防策略	从源头避免拥塞，减少后期迭代
第5章	拥塞驱动的时序优化技术	在拥塞约束下高效修复时序
第6章	实战案例：从拥塞到收敛的全流程	完整走一遍项目中的典型场景

1.5 学习路径建议

这门课适合有一定后端基础的同学。如果你刚入行，建议先补一下STA和PR的基础知识。

我个人习惯的学习路径是这样的：

1. 先看第2章——搞清楚拥塞到底是什么，怎么量化。这是基础中的基础。
2. 再看第3章——理解拥塞和时序之间的定量关系。这部分会涉及一些公式，但别怕，我会用实际案例讲清楚。
3. 然后看第4章和第5章——这两章是核心方法论。建议边看边在工具里实操，效果最好。
4. 最后看第6章——实战案例。我会把之前项目中的真实数据拿出来，一步步带你走一遍。

好了，绪论就到这里。记住一句话：拥塞是时序收敛的根因，解决拥塞就是解决时序问题。接下来的章节，我会带你一步步深入这个主题。

可可精品资料库