这个章节的目标很明确——基于工具placement阶段做的global route结果来做RC提取。做这步是为了后续的timing计算和分析做准备。

按照lab的要求，我们先打开Innovus的pr.inv这个database（做这个之前请退出innovus后再重新打开），命令如下：

restoreDesign ../saved/pr.inv.dat DTMF_CHIP

RC抽取GUI图形界面操作步骤：

延时计算

GUI图形界面操作步骤： Timing — Write SDF

由于place阶段时钟clock 还是ideal的，所以这里需要勾选ideal clock选项，而且我们这个阶段只需要分析setup，所以这里的Active View只需要选择dtmf_view_setup。

【思考题】为什么不需要要选dtmf_view_hold 做为Active View呢？

Place 阶段为什么只选 Setup View，不选 Hold View？

1. 问题背景

在 Innovus 的 Place 阶段进行时序分析时，通常需要勾选 Ideal Clock，并且 Active View 只选择 dtmf_view_setup，不选择 dtmf_view_hold。

原因是：Place 阶段还没有进行 CTS，时钟树尚未建立，此时时钟仍然是理想时钟。

Place 阶段：
clock = ideal clock
clock latency ≈ 0
clock skew ≈ 0

2. Setup 和 Hold 都依赖 Clock Skew

需要注意的是，setup 和 hold 都与 clock skew 有关。

Setup 检查

Setup 主要检查数据是否能在下一个时钟沿到来之前稳定。

简化公式为：

1	setup slack ≈ Tclk + capture_clk_delay - launch_clk_delay - data_delay - setup_time

其中：

1	capture_clk_delay - launch_clk_delay

与 clock skew 有关。

Hold 检查

Hold 主要检查数据是否不会太早到达下一级寄存器。

简化公式为：

1	hold slack ≈ launch_clk_delay + data_min_delay - capture_clk_delay - hold_time

其中：

1	launch_clk_delay - capture_clk_delay

也与 clock skew 有关。

所以不能简单理解为“setup 不依赖 skew，hold 依赖 skew”。更准确的说法是：

setup 和 hold 都依赖 clock skew，但 hold 对真实时钟树和最小路径延迟更加敏感。

3. 为什么 Place 阶段仍然可以分析 Setup？

虽然 Place 阶段 clock 还是 ideal，setup 结果不是最终 signoff 结果，但它仍然有较强参考价值。

因为 setup 违例通常主要来自：

组合逻辑级数太深
数据路径太长
单元摆放距离太远
单元驱动能力不足
线延迟较大

这些问题在 Place 阶段已经可以初步反映出来。

因此，Place 阶段分析 setup 的主要目的不是得到最终准确时序，而是提前发现长路径和布局不合理的问题，指导工具进行布局优化。

同时，工具可以通过设置：

1	clock uncertainty

为后续 CTS、clock skew 和工艺波动预留一定时序裕量。

4. 为什么 Place 阶段不建议选择 Hold View？

Hold 检查对真实时钟偏斜非常敏感，而 Place 阶段时钟树还没有建立。

此时工具无法准确知道：

真实 clock latency
真实 clock skew
真实时钟路径 RC
CTS 后的 launch/capture clock delay

如果在 Place 阶段就分析或修复 hold，可能会出现两种问题：

1 2	当前看到的 hold 违例可能是假的当前没有看到的 hold 违例，CTS 后可能又出现

如果过早把 dtmf_view_hold 作为 Active View，工具可能会为了修复不稳定的 hold 违例，提前插入 delay buffer。

这样可能导致：

面积增大
功耗增加
布线拥塞变严重
setup slack 变差
后续 CTS 后仍然需要重新修 hold

所以 Place 阶段通常不重点修 hold。

5. Hold 应该什么时候重点分析？

Hold 通常在 CTS 之后重点分析。

原因是 CTS 后时钟树已经建立，clock 从 ideal clock 变成 propagated clock，工具可以获得更接近真实情况的：

1
2
3

clock latency
clock skew
clock path delay

一般流程可以理解为：

Place 阶段：
主要分析 setup，优化长数据路径

CTS 阶段之后：
时钟树建立，开始重点检查 hold

Route / Post-route 阶段：
结合真实布线 RC，进一步修复 setup/hold

Signoff STA 阶段：
在多工况下最终检查 setup/hold 是否收敛

6. 思考题答案整理版

Place 阶段不需要选择 dtmf_view_hold 作为 Active View，主要是因为此时还没有进行 CTS，时钟树尚未建立，clock 仍然是 ideal clock，真实的 clock latency 和 clock skew 还无法准确获得。

虽然 setup 和 hold 都会受到 clock skew 的影响，但 setup 违例更多反映组合逻辑延迟、单元摆放距离和数据路径过长等问题，这些因素在 Place 阶段已经具有较强参考价值，因此可以通过 dtmf_view_setup 指导布局优化，并利用 clock uncertainty 预留一定裕量。

相比之下，hold 检查对真实时钟偏斜和最小数据路径延迟更加敏感。在 CTS 之前分析 hold 容易产生不准确的违例。如果过早选择 hold view，工具可能插入不必要的 delay buffer，导致面积、功耗和拥塞增加，还可能影响 setup 收敛。因此 Place 阶段主要选择 setup view，hold view 通常应在 CTS 之后、时钟树建立并变为 propagated clock 后再重点检查和修复。

7. 一句话总结

Setup 也依赖 clock skew，但 Place 阶段 setup 主要用于提前优化长数据路径；hold 更依赖 CTS 后的真实时钟树，所以 Place 阶段一般不重点分析和修复 hold。

LAB12-2 时序分析并生成时序报告

这个章节的学习目标很明确——学会分析时序timing并把violation path在layout上显示出来。

产生Timing报告的图形化界面操作步骤如下：

它的等效命令如下：

timeDesign -preCTS -pathReports -drvReports -slackReports -numPaths 50 -prefix DTMF_CHIP_preCTS -outDir timingReports

这里再教大家一招通过命令来获取工具对应的命令。

在你写出来的log下有个log.cmd这个文件，里面会记录下所有GUI界面操作对应的命令。

下面我们利用工具自带的图形化界面来教大家如何来分析debug时序情况，具体步骤如下;

Timing—- Debug Timing

采用默认设置，直接点OK，然后就会弹出如下结果窗口。

有了上述的结果后，我们可以利用这个图形化界面在layout上高亮出对应的timing path。之所以有这个操作，我们是想通过这个来看某条timing path在物理位置上是否存在兜来兜去的情况。

同样，我们也按照lab中的要求来报告下当前的hold time情况。

set_analysis_view -setup { dtmf_view_setup } -hold { dtmf_view_hold }

用同样的方法我们用工具自带的Timing debug来展示hold time的情况。