数字ic后端设计从入门到精通9（含fusion compiler, tcl教学）setup time, hold time check lib/report详解
check lib
标准单元库中建立时间和保持时间约束的check格式
用于数字 IC 设计中的静态时序分析（STA）。它定义了如何用表格形式表达触发器等顺序单元在不同输入信号和时钟转换速率下的建立和保持时间。（对应工艺角的lib文件）
示例结构
pin (D) {
direction : input;
...
timing () {
related_pin : "CK";
timing_type : "setup_rising";
rise_constraint ("setuphold_template_3x3") {
index_1("0.4, 0.57, 0.84"); /* Data transition */
index_2("0.4, 0.57, 0.84"); /* Clock transition */
values( /* 0.4 0.57 0.84 */ \
/* 0.4 */ "0.063, 0.093, 0.112", \
/* 0.57 */ "0.526, 0.644, 0.824", \
/* 0.84 */ "0.720, 0.839, 0.930");
}
fall_constraint ("setuphold_template_3x3") {
index_1("0.4, 0.57, 0.84"); /* Data transition */
index_2("0.4, 0.57, 0.84"); /* Clock transition */
values( /* 0.4 0.57 0.84 */ \
/* 0.4 */ "0.762, 0.895, 0.969", \
/* 0.57 */ "0.804, 0.952, 0.166", \
/* 0.84 */ "0.159, 0.170, 0.245");
}
}
}
关键字与字段详解
1. pin (D)
- 含义：定义一个引脚（pin），这里是
D引脚。 - 作用：表示该段描述的是触发器的数据输入引脚。
2. direction : input;
- 含义：方向为输入。
- 作用：说明这个引脚是数据输入端口。
3. timing () { ... }
- 含义：这是一个 timing block，用来描述该引脚的时序行为。
- 作用：包含所有与时序检查相关的约束信息，比如 setup、hold、recovery、removal 等。
4. related_pin : "CK";
- 含义：相关引脚是
"CK"（通常指时钟引脚）。 - 作用：说明这些时序检查是相对于时钟引脚 CK 的。
5. timing_type : "setup_rising";
- 含义：这是“上升沿触发”的建立时间约束。
- 作用：指定该段描述的是 D 引脚相对于 CK 上升沿的建立时间要求。
常见类型：
setup_rising：建立时间（时钟上升沿）setup_falling：建立时间（时钟下降沿）hold_rising：保持时间（时钟上升沿）hold_falling：保持时间（时钟下降沿）
6. rise_constraint (...) 和 fall_constraint (...)
- 含义：
rise_constraint：当 D 引脚上的数据从低到高变化时使用的建立/保持时间表。fall_constraint：当 D 引脚上的数据从高到低变化时使用的建立/保持时间表。
- 作用：因为信号的上升和下降时间可能不同，所以需要分别建模。
7. ("setuphold_template_3x3")
- 含义：引用了一个名为
setuphold_template_3x3的模板。 - 作用：指定该约束使用哪种二维查找表模板。这里的“3x3”表示有三个输入维度值，形成一个 3 行 × 3 列的矩阵。
8. index_1(...) 和 index_2(...)
- 含义：
index_1：第一维索引，通常是数据引脚（constrained_pin）的转换时间（transition time）。index_2：第二维索引，通常是时钟引脚（related_pin）的转换时间。
- 作用：这两个参数构成了查找表的两个输入变量。
示例：
index_1("0.4, 0.57, 0.84"); // 数据引脚 D 的转换时间（ns）
index_2("0.4, 0.57, 0.84"); // 时钟引脚 CK 的转换时间（ns）
9. values(...)
- 含义：实际的时序数值，按二维表格方式组织。
- 作用：根据数据和时钟的转换时间查出对应的建立或保持时间。
示例：
values( /* 0.4 0.57 0.84 */ \
/* 0.4 */ "0.063, 0.093, 0.112", \
/* 0.57 */ "0.526, 0.644, 0.824", \
/* 0.84 */ "0.720, 0.839, 0.930");
这张表的意思是：
| D Transition \ CK Transition | 0.4 ns | 0.57 ns | 0.84 ns |
|---|---|---|---|
| 0.4 ns | 0.063 | 0.093 | 0.112 |
| 0.57 ns | 0.526 | 0.644 | 0.824 |
| 0.84 ns | 0.720 | 0.839 | 0.930 |
例如：
- 如果 D 转换时间为 0.4 ns，CK 转换时间为 0.84 ns，则 setup 时间是 0.112 ns
10. lu_table_template(setuphold_template_3x3)
- 含义：定义一个 lookup table 模板。
- 作用：统一规定了所有类似
setuphold_template_3x3类型的查找表结构。
lu_table_template(setuphold_template_3x3) {
variable_1 : constrained_pin_transition;
variable_2 : related_pin_transition;
index_1 ("1000, 1001, 1002");
index_2 ("1000, 1001, 1002");
}
variable_1：第一个变量是受约束引脚（如 D）的转换时间。variable_2：第二个变量是相关引脚（如 CK）的转换时间。index_1 / index_2：设定默认的索引值（用于工具内部映射）。
11. 注释部分
/* The constrained pin and the related pin can be in either order... */
- 含义：虽然这里变量 1 是 constrained_pin，但也可以反过来用。
- 作用：提醒设计者，这种映射方式在库中通常是一致的，但并非强制。
12. “嵌套循环”查找方式
Like in previous examples, the setup values in the table are specified like a nested loop...
- 含义：查找方式就像编程语言中的双重循环。
- 外层循环是
index_1（数据转换） - 内层循环是
index_2（时钟转换）
- 外层循环是
13. 非线性模型查找（Non-linear model lookup）
For lookup of the setup and hold constraint tables where the transition times do not correspond to the index values...
- 含义：如果实际的转换时间不正好落在 index 定义的点上，就需要使用插值法来估算。
- 作用：确保即使输入不是精确匹配也能得到合理的时间约束值。
14. 最后一段注释
Note that the rise_constraint and fall_constraint tables of the setup constraint refer to the constrained_pin.
The clock transition used is determined by the timing_type which specifies whether the cell is rising edge-triggered or falling edge-triggered.
- 含义：
rise_constraint和fall_constraint描述的是数据引脚本身的上升/下降边沿。- 使用哪个时钟边沿取决于
timing_type（如setup_rising表示使用上升沿）。
转换时间（transition time）
一、什么是 转换时间（Transition Time）？
转换时间（Transition Time） 又称为 上升/下降时间（rise/fall time），指的是信号从一个电压电平过渡到另一个电压电平所需的时间。
通常定义为：
- 从 10% 到 90% 的 VDD
- 或者 从 20% 到 80% 的 VDD
- 常见的是使用 50% 的 VDD 作为参考点
⚠️ 在标准单元库（如
.lib文件）中，转换时间通常以纳秒（ns）为单位表示。
二、两个关键术语
✅ 1. constrained_pin（受约束引脚）
- 指需要进行时序检查的引脚。
- 在建立时间和保持时间检查中，通常是数据输入引脚（例如 D 引脚）。
- 它的转换时间会影响建立/保持时间的需求。
✅ 2. related_pin（相关引脚）
- 指与时序检查相关的引脚。
- 通常是指时钟引脚（CK）。
- 它的转换时间也会影响建立/保持时间的需求。
三、index_1 和 index_2 的含义回顾
| 字段 | 含义 |
|---|---|
index_1(...) |
第一维索引，对应于 constrained_pin（如 D 引脚）的转换时间 |
index_2(...) |
第二维索引，对应于 related_pin（如 CK 引脚）的转换时间 |
这些索引构成了查找表的两个输入维度，用于查出对应的建立时间或保持时间值。
四、举例说明：转换时间如何影响建立时间
我们来看一个具体的例子：
rise_constraint ("setuphold_template_3x3") {
index_1("0.4, 0.57, 0.84"); // D 引脚的转换时间
index_2("0.4, 0.57, 0.84"); // CK 引脚的转换时间
values(
/* 0.4 */ "0.063, 0.093, 0.112", \
/* 0.57 */ "0.526, 0.644, 0.824", \
/* 0.84 */ "0.720, 0.839, 0.930");
}
表格结构如下：
| D 转换时间 \ CK 转换时间 | 0.4 ns | 0.57 ns | 0.84 ns |
|---|---|---|---|
| 0.4 ns | 0.063 | 0.093 | 0.112 |
| 0.57 ns | 0.526 | 0.644 | 0.824 |
| 0.84 ns | 0.720 | 0.839 | 0.930 |
示例分析：
- 如果 D 引脚的转换时间为 0.4 ns，而 CK 引脚的转换时间为 0.84 ns，则建立时间要求是 0.112 ns。
- 如果 D 引脚变慢（如 0.84 ns），意味着它驱动能力弱或负载大，则建立时间要求更严格（更高）——这里变成了 0.930 ns。
这说明：
- 数据引脚越慢，建立时间越大（需要数据更早稳定）；
- 时钟引脚越慢，建立时间也会增大（因为采样边沿变得“模糊”）；
五、为什么转换时间会影响建立和保持时间？
1. 数据引脚（constrained_pin）转换时间的影响
- 如果数据引脚转换时间较长（即信号变化缓慢），那么它的有效边沿到达触发器内部锁存点的时间会更晚。
- 这会导致建立时间增加，因为它需要更早地稳定下来才能被正确采样。
2. 时钟引脚（related_pin）转换时间的影响
- 如果时钟引脚转换时间较长，那么它的有效边沿（比如上升沿）会在较长时间内变化。
- 这会让触发器对数据的采样变得不确定，因此也需要更长的建立时间来确保数据已经稳定。
六、实际设计中的应用
✅ 静态时序分析（STA）工具（如 PrimeTime）会根据以下信息计算路径时序：
- 数据路径上的每个 cell 的输出转换时间（output transition）
- 时钟路径上的每个 buffer/inverter 的输出转换时间
- 根据标准单元库中提供的 setup/hold 查找表，查出具体数值
- 最终判断该路径是否满足时序要求（Slack >= 0）
七、总结表格
| 术语 | 英文 | 中文解释 | 作用 |
|---|---|---|---|
| constrained_pin | 受约束引脚 | 通常是数据输入引脚（如 D） | 用于进行时序检查的引脚 |
| related_pin | 相关引脚 | 通常是时钟引脚（如 CK） | 控制时序检查发生的条件 |
| transition time | 转换时间 | 信号从低电平到高电平或反之所需的时间 | 影响建立/保持时间的要求 |
| index_1 | 第一维索引 | 对应 constrained_pin 的转换时间 | 决定数据引脚的速度 |
| index_2 | 第二维索引 | 对应 related_pin 的转换时间 | 决定时钟引脚的速度 |
| lookup table | 查找表 | 包含不同转换时间组合下的 setup/hold 数值 | 工具查表获取精确时序参数 |
异步时序检查定义
一、整体背景
在数字电路设计中，有些控制信号是异步的，例如：
- 异步复位（asynchronous reset）
- 异步置位（asynchronous set）
这些信号具有比时钟更高优先级，一旦激活，会立即改变寄存器的输出值，而不依赖于时钟边沿。
但是当这些异步信号**释放（deasserted）**后，必须满足一定的时间约束，以确保系统能正确地回到由时钟驱动的状态。这就引入了：
- Recovery Time（恢复时间）
- Removal Time（移除时间）
此外，为了防止误触发，还需要对异步信号的**脉冲宽度（Pulse Width）**进行限制。
二、逐行详解异步检查
我们来逐行解析你提供的代码段，从顶层开始：
第一部分：异步引脚定义
pin(CDN) {
direction : input;
capacitance : 0.002236;
✅ 解释：
pin(CDN)：定义一个名为CDN的引脚（通常是“Clear Data Negative”，即低电平有效的异步清零信号）。direction : input;：该引脚是输入引脚。capacitance : 0.002236;：该引脚的输入电容为 0.002236 单位（可能是 pF 或 F，取决于库单位）。
第二部分：最小脉冲宽度检查（min_pulse_width）
timing() {
related_pin : "CDN";
timing_type : min_pulse_width;
fall_constraint(width_template_3x1) { /*low pulse check*/
index_1 ("0.032, 0.504, 0.788"); /* Input transition */
values ( /* 0.032 0.504 0.788 */ \
"0.034, 0.060, 0.377");
}
}
✅ 解释：
timing()：定义一个时序模型块。related_pin : "CDN";：这个检查与 CDN 引脚本身相关（不是与时钟）。timing_type : min_pulse_width;：这是一个最小脉冲宽度检查。fall_constraint(...)：表示这是对下降沿（即低电平持续时间）的脉冲宽度约束。width_template_3x1：查找表模板，第一维有 3 个转换时间，第二维只有一个（因为只关心一个边沿）。index_1 (...)：输入转换时间（transition time），用于查表。values(...)：每个输入转换时间对应的最小脉冲宽度要求。
作用说明：
由于 CDN 是低电平有效，所以这里只检查低脉冲宽度是否足够宽，否则可能无法正确清除数据。
第三部分：恢复时间检查（recovery_rising）
timing() {
related_pin : "CK";
timing_type : recovery_rising;
rise_constraint(recovery_template_3x3) { /* CDN rising */
index_1 ("0.032, 0.504, 0.788"); /* Data transition */
index_2 ("0.032, 0.504, 0.788"); /* Clock transition */
values( /* 0.032 0.504 0.788 */ \
/* 0.032 */ "-0.198, -0.122, 0.187", \
/* 0.504 */ "-0.268, -0.157, 0.124", \
/* 0.788 */ "-0.490, -0.219, -0.069");
}
}
✅ 解释：
related_pin : "CK";：该检查相对于时钟引脚 CK 进行。timing_type : recovery_rising;：这是一个恢复时间检查，针对 CDN 上升沿（即清零信号释放）。rise_constraint(...)：表示这是上升沿触发的检查。recovery_template_3x3：使用二维查找表模板，第一维是数据转换时间，第二维是时钟转换时间。index_1 (...)：数据路径上的转换时间。index_2 (...)：时钟路径上的转换时间。values(...)：不同组合下对应的 recovery 时间数值。
作用说明：
- 当 CDN 被释放（变为高电平）后，它必须在下一个时钟上升沿之前稳定一段时间，才能保证寄存器能重新被时钟采样控制。
- 数值可以是负数，表示即使 CDN 在时钟边沿之后才释放也是允许的（取决于工艺和设计）。
第四部分：移除时间检查（removal_rising）
timing() {
related_pin : "CP";
timing_type : removal_rising;
rise_constraint(removal_template_3x3) { /* CDN rising */
index_1 ("0.032, 0.504, 0.788"); /* Data transition */
index_2 ("0.032, 0.504, 0.788"); /* Clock transition */
values( /* 0.032 0.504 0.788 */ \
/* 0.032 */ "0.106, 0.167, 0.548", \
/* 0.504 */ "0.221, 0.381, 0.662", \
/* 0.788 */ "0.381, 0.456, 0.778");
}
}
✅ 解释：
related_pin : "CP";：该检查相对于另一个引脚 CP（CP指的是Clock Pulse，即时钟脉冲信号。它是由一系列离散的脉冲组成的信号，每个脉冲之间有固定的时间间隔。）。timing_type : removal_rising;：这是一个移除时间检查，针对 CDN 上升沿（即清零信号释放）。rise_constraint(...)：表示这是上升沿触发的检查。removal_template_3x3：使用二维查找表模板。index_1/2 (...)：同上，分别是数据和时钟转换时间。values(...)：对应组合下的 removal 时间。
作用说明：
- 移除时间是指 CDN 信号在时钟边沿之后仍需保持活动状态的时间，避免在采样过程中提前释放造成不确定行为。
- 它类似于 hold time，但适用于异步信号。
三、关键术语总结（按单词解释）
| 单词 | 中文含义 | 用途 |
|---|---|---|
pin(CDN) |
定义一个引脚 CDN | 描述异步清零引脚 |
direction : input; |
输入方向 | 表示该引脚是输入 |
capacitance |
电容 | 表示引脚负载特性 |
timing() |
时序信息块 | 定义一个时序约束 |
related_pin |
相关引脚 | 用于比较的参考引脚（如 CK） |
timing_type |
时序类型 | 表示当前约束类型 |
min_pulse_width |
最小脉冲宽度 | 检查信号高低电平持续时间 |
fall_constraint |
下降沿约束 | 针对低电平脉冲 |
rise_constraint |
上升沿约束 | 针对高电平脉冲 |
recovery_rising |
恢复时间（上升沿） | CDN 释放后，在时钟前要稳定的时间 |
removal_rising |
移除时间（上升沿） | CDN 释放前，在时钟后要保持的时间 |
index_1, index_2 |
查找表索引 | 分别表示数据和时钟的转换时间 |
values(...) |
数值表 | 不同转换时间组合下的约束值 |
四、同步 vs 异步检查对比总结
| 对比项 | 同步检查（Setup/Hold） | 异步检查（Recovery/Removal/PulseWidth） |
|---|---|---|
| 触发机制 | 数据通过时钟边沿采样 | 异步信号直接控制输出 |
| 检查对象 | 数据引脚 D | 控制引脚 CDN/SDN |
| 是否受时钟影响 | 是 | 否（激活时） |
| 检查时机 | 数据采样前后 | 异步信号释放前后 |
| 查找表维度 | 2D（data/clock） | 2D（data/clock） |
| 是否支持负值 | 是（尤其是 hold） | 是（尤其是 recovery） |
| 是否涉及脉冲宽度 | 否 | 是 |
| 典型应用场景 | 寄存器间传输 | 异步复位/置位控制 |
五、实际意义总结
- 异步信号虽然强大，但也容易引起亚稳态（metastability）或功能错误。
- 所以需要严格约束其释放时间和脉冲宽度。
- STA 工具（如 PrimeTime）会根据这些
.lib中的异步检查规则，自动分析异步路径是否满足时序要求。 - 如果不满足 recovery/removal 时间，可能导致寄存器无法正常工作，甚至导致芯片功能异常。
关于负边沿触发的触发器（flip-flop） 的 传播延迟（Propagation Delay） 信息
第一部分：整体背景介绍
原文：
Propagation Delay
The propagation delay of a sequential cell is from the active edge of the clock to a rising or falling edge on the output.
✅ 解释：
- Propagation Delay（传播延迟）：指从时钟的有效边沿（active edge）开始，到输出信号发生变化所需的时间。
- sequential cell（顺序单元）：如 D 触发器、寄存器等，其行为依赖于时钟。
- active edge of the clock（有效时钟边沿）：指的是上升沿（rising edge）或下降沿（falling edge），取决于触发器类型。
- rising/falling edge on the output（输出边沿）：输出 Q 在某个时钟边沿后会变为高电平或低电平。
第二部分：示例说明
原文：
Here is an example of a propagation delay arc for a negative edge-triggered flip-flop, from clock pin CKN to output Q. This is a non-unate timing arc as the active edge of the clock can cause either a rising or a falling edge on the output Q.
✅ 解释：
- negative edge-triggered flip-flop：负边沿触发的触发器，即在时钟下降沿采样数据。
- CKN：Clock Negative，表示这是一个负边沿触发的时钟引脚。
- propagation delay arc：表示从输入（时钟）到输出（Q）的延迟路径。
- non-unate timing arc：
- “non-unate” 表示输出变化方向不唯一；
- 即，同一个时钟边沿可能引起输出上升也可能引起下降，取决于当前输入数据。
第三部分：完整的 Timing Block 解析
我们来分析这一段：
timing() {
related_pin : "CKN";
timing_type : falling_edge;
timing_sense : non_unate;
✅ 逐词解释：
timing() { ... }
- 定义一个时序模型块（timing block），用于描述某条路径的延迟或约束。
related_pin : "CKN";
related_pin：表示这个 timing block 是相对于哪个引脚（pin）定义的。"CKN"：相关引脚是 CKN（负边沿触发的时钟引脚）。
timing_type : falling_edge;
timing_type：表示该时序弧的触发方式。falling_edge：这是一个负边沿触发的时钟路径。
timing_sense : non_unate;
timing_sense：表示这条路径对输出的影响是否具有单调性。non_unate：输出的变化方向不确定，可能是上升也可能是下降，取决于输入数据。
⏱️ 第四部分：cell_rise 和 rise_transition 延迟表
cell_rise(delay_template_3x3) {
index_1 ("0.1, 0.3, 0.7"); /* Clock transition */
index_2 ("0.16, 0.35, 1.43"); /* Output capacitance */
values ( /* 0.16 0.35 1.43 */ \
/* 0.1 */ "0.0513, 0.1537, 0.5280", \
/* 0.3 */ "0.1018, 0.2327, 0.6476", \
/* 0.7 */ "0.1334, 0.2973, 0.7252");
}
✅ 解释：
cell_rise(...)
cell_rise：表示当输出从低变高（rise）时的延迟值。- 这是一个查找表，用于计算不同条件下输出上升的延迟时间。
delay_template_3x3
- 这是一个二维查找表模板，第一维有 3 个值，第二维也有 3 个值。
- 表示延迟是两个变量的函数：输入转换时间和负载电容。
index_1 (...)
- 输入转换时间（input transition time）：时钟信号的上升/下降时间（这里是 CKN 下降时间）。
- 数值单位通常是 ns 或 ps（取决于库设定）。
index_2 (...)
- 输出负载电容（output capacitance）：连接到输出 Q 的负载大小，影响输出延迟。
values (...)
- 实际查表结果：每个输入转换时间和负载电容组合下的延迟值。
- 示例：
- 当 input transition = 0.1，load cap = 0.16 → delay = 0.0513
类似地还有：
rise_transition(...)
cell_fall(...)
fall_transition(...)
| 关键字 | 中文含义 | 用途 |
|---|---|---|
rise_transition(...) |
上升沿转换时间 | 描述输出从低变高的转换时间（slew） |
cell_fall(...) |
下降沿延迟 | 输出从高变低的延迟 |
fall_transition(...) |
下降沿转换时间 | 输出从高变低的转换时间 |
这些参数共同构成了完整的输出延迟模型。
第五部分：如何使用这些延迟表？
以 cell_rise(...) 为例：
假设你的设计中：
- 输入时钟 CKN 的下降沿转换时间为 0.3
- 输出 Q 的负载电容为 0.35
那么你可以查表得到：
cell_rise = 0.2327
这就是从 CKN 下降沿到 Q 上升沿的延迟时间。
工具（如 PrimeTime）会自动根据实际电路中的转换时间和负载电容进行插值计算。
第六部分：正边沿触发的例子
timing() {
related_pin : "CKP";
timing_type : rising_edge;
timing_sense : non_unate;
cell_rise(delay_template_3x3) {
...
}
}
✅ 解释：
CKP：Clock Positive，表示这是正边沿触发的时钟引脚。rising_edge：有效边沿是上升沿。- 其余结构与前面相同。
总结关键词对照表
| 英文词汇 | 中文含义 | 用途 |
|---|---|---|
timing() |
时序块 | 包含一条路径的时序信息 |
related_pin |
相关引脚 | 时钟或其他输入引脚 |
timing_type |
时序类型 | 如 rising_edge / falling_edge |
timing_sense |
路径影响 | unate / non_unate |
cell_rise |
上升延迟 | 输出从低变高的延迟 |
rise_transition |
上升转换时间 | 输出边沿斜率 |
cell_fall |
下降延迟 | 输出从高变低的延迟 |
fall_transition |
下降转换时间 | 输出边沿斜率 |
index_1 |
第一维度索引 | 输入转换时间 |
index_2 |
第二维度索引 | 输出负载电容 |
values(...) |
查找表数值 | 延迟或转换时间的具体值 |
delay_template_3x3 |
延迟模板 | 表示二维查找表的结构 |
check report
Setup Check 报告
第一部分：整体结构说明
这份报告是通过工具（如 Synopsys PrimeTime）运行以下命令后生成的：
report_timing -from UFF0 -to UFF1 -path_type full_clock -delay_type max
它展示了一条从 UFF0 到 UFF1 的关键路径，用于检查这条路径是否满足 setup time 的要求。
第二部分：逐行详解（按段落划分）
第一段：起点和终点信息
Startpoint: UFF0 (rising edge-triggered flip-flop clocked by CLKM)
Endpoint: UFF1 (rising edge-triggered flip flop clocked by CLKM)
Path Group: CLKM
Path Type: max
✅ 解释每个单词：
| 单词 | 含义 |
|---|---|
| Startpoint | 路径起点 |
| UFF0 | 实例名，是一个 D 触发器（flip-flop） |
| rising edge-triggered | 正边沿触发（在上升沿采样数据） |
| flip-flop / DFF | D 型触发器（Data Flip-Flop） |
| clocked by CLKM | 使用名为 CLKM 的时钟信号驱动 |
| Endpoint | 路径终点 |
| UFF1 | 另一个 D 触发器实例 |
| Path Group | 路径组，所有以 CLKM 为捕获时钟的路径属于这个组 |
| max | 最大延迟路径（用于 setup check） |
作用说明：
- 这条路径是从 UFF0 输出的数据，经过组合逻辑，被 UFF1 在下一个 CLKM 上升沿采样。
- 因为是 setup check，所以要分析最大路径延迟。
第二段：路径节点信息（Timing Path Details）
Point Incr Path
---------------------------------------------------------------
clock CLKM (rise edge) 0.00 0.00
clock network delay (ideal) 0.00 0.00
UFF0/CK (DFF ) 0.00 0.00 r
UFF0/Q (DFF ) <- 0.16 0.16 f
UNOR0/ZN (NR2 ) 0.04 0.20 r
UBUF4/Z (BUFF ) 0.05 0.26 r
UFF1/D (DFF ) 0.00 0.26 r
data arrival time 0.26
✅ 表头解释：
| 字段 | 含义 |
|---|---|
| Point | 当前路径上的节点或引脚 |
| Incr | 增量延迟（Incremental Delay） |
| Path | 累计延迟（Cumulative Delay） |
| r/f | 边沿类型：r = rising（上升），f = falling（下降） |
✅ 逐行解释：
| 行号 | 内容 | 解释 |
|---|---|---|
| 1 | clock CLKM (rise edge) |
CLKM 时钟的上升沿作为起点 |
| 2 | clock network delay (ideal) |
时钟网络延迟，这里设为理想（ideal），即 0ns |
| 3 | UFF0/CK |
数据路径从 UFF0 的时钟引脚开始 |
| 4 | UFF0/Q |
数据从 UFF0 的输出 Q 出来，延迟 0.16ns |
| 5 | UNOR0/ZN |
经过 NOR 门 UNOR0 的 ZN 引脚，增加 0.04ns |
| 6 | UBUF4/Z |
经过缓冲器 UBUF4 的 Z 引脚，增加 0.05ns |
| 7 | UFF1/D |
到达 UFF1 的 D 输入引脚，累计延迟 0.26ns |
| 8 | data arrival time |
数据到达时间 = 0.26ns |
注意：
- 所有延迟单位默认是 ns（纳秒）
<-表示从某个输出端口到下一级输入的连接
第三段：所需时间（Required Time）
clock CLKM (rise edge) 10.00 10.00
clock network delay (ideal) 0.00 10.00
clock uncertainty -0.30 9.70
UFF1/CK (DFF ) 9.70 r
library setup time -0.04 9.66
data required time 9.66
✅ 关键术语解释：
| 单词 | 含义 |
|---|---|
| clock CLKM (rise edge) | 下一个 CLKM 上升沿到来时间为 10.00ns |
| clock network delay | 时钟网络延迟仍为理想值 0ns |
| clock uncertainty | 时钟不确定性（通常包括 jitter 和 margin），这里减去 0.30ns |
| library setup time | 触发器 UFF1 的 setup 时间，需提前 0.04ns |
| data required time | 数据必须在此时间之前稳定才能满足 setup 要求 |
公式：
required_time = next_clock_edge + clock_network_delay - clock_uncertainty - setup_time
= 10.00 + 0.00 - 0.30 - 0.04 = 9.66 ns
第四段：Slack（松弛时间）
---------------------------------------------------------------
data required time 9.66
data arrival time -0.26
---------------------------------------------------------------
slack (MET) 9.41
✅ 解释：
| 单词 | 含义 |
|---|---|
| data required time | 数据必须在 9.66ns 前稳定 |
| data arrival time | 数据实际到达时间为 0.26ns |
| slack | 松弛时间 = required_time - arrival_time = 9.66 - 0.26 = 9.41ns |
| (MET) | 表示满足时序要求（No Violation） |
结论：
- Slack > 0 → Setup 要求满足 ✅
- 如果 slack < 0 → Setup Violation ❌
第五部分：总结与扩展概念
✅ Setup Check vs Hold Check
| 项目 | Setup Check | Hold Check |
|---|---|---|
| 目标 | 数据在时钟有效边沿前稳定 | 数据在时钟有效边沿后保持不变 |
| 分析路径 | 最长路径（max） | 最短路径（min） |
| slack 公式 | required_time - arrival_time | arrival_time - required_time |
| 问题表现 | 数据太慢 | 数据太快 |
| 工具设置 | -delay_type max |
-delay_type min |
第六部分：格式说明
1. .lib 文件（标准单元库）
- 是
.lib或.db格式 - 描述每个单元（cell）的时序特性（setup/hold、propagation delay、slew等）
- 是 STA 工具进行时序分析的基础数据
2. .v 文件（Verilog RTL 或网表）
- Verilog HDL 描述电路结构
- 包含模块定义、连线、实例化等信息
- 是 STA 工具加载设计的输入之一
3. .sdc 文件（Synopsys Design Constraints）
- 定义时钟、IO约束、例外路径等
- 是 STA 工具判断路径是否合规的关键依据
4. .rpt 文件（Timing Report）
- 文本格式
- 由 STA 工具（如 PrimeTime）生成
- 展示每条路径的详细时序分析结果
- 用于指导综合、布局布线优化
传播时钟（propagated clock） 的分析结果
一、整体结构说明
这份报告仍然是一个 setup check，用于检查数据是否在捕获触发器采样前足够早地稳定下来。它包括以下几个部分：
1. 路径基本信息（Header）
Startpoint: UFF0 ...
Endpoint: UFF1 ...
Path Group: CLKM
Path Type: max
表示这是一个从 UFF0 到 UFF1 的 setup 检查路径（max 表示最大延迟路径）
2. 数据路径详细信息（Data Arrival Path）
Point Incr Path Edge
---------------------------------------------------------------
clock CLKM (rise edge) 0.00 0.00
clock network delay (propagated) 0.11 0.11
UFF0/CK (DFF ) 0.00 0.11 r
UFF0/Q (DFF ) <- 0.14 0.26 f
UNOR0/ZN (NR2 ) 0.04 0.30 r
UBUF4/Z (BUFF ) 0.05 0.35 r
UFF1/D (DFF ) 0.00 0.35 r
data arrival time 0.35
显示了数据从发射边沿出发，经过组合逻辑到达捕获触发器 D 输入的路径和延迟。
3. 所需时间路径（Required Time Path）
clock CLKM (rise edge) 10.00 10.00
clock network delay (propagated) 0.12 10.12
clock uncertainty -0.30 9.82
UFF1/CK (DFF ) 9.82 r
library setup time -0.04 9.78
data required time 9.78
计算数据必须稳定的时间点（考虑 clock skew、uncertainty 和 setup time）
4. Slack（松弛时间）
data required time 9.78
data arrival time -0.35
---------------------------------------------------------------
slack (MET) 9.43
Slack = Required Time - Arrival Time = 9.78 - 0.35 = 9.43 ns ✅ 满足 setup 要求
二、术语解释（按字段）
| 字段 | 含义 |
|---|---|
| Incr | 增量延迟（Incremental Delay），表示当前节点相对于前一个节点增加的延迟 |
| Path | 累计延迟（Cumulative Delay），表示从起点开始到当前节点为止的总延迟 |
| Edge (r/f) | 边沿类型：r 表示上升沿（rising），f 表示下降沿（falling） |
| clock network delay (ideal) | 理想时钟网络延迟，即工具假设为 0ns |
| clock network delay (propagated) | 实际时钟网络延迟，工具已计算出真实值 |
| clock uncertainty | 时钟不确定性（裕量），包含抖动（jitter）和 margin |
| library setup time | 单元库中定义的 setup 时间（由工艺决定） |
| data arrival time | 数据到达捕获触发器输入端的时间 |
| data required time | 数据必须稳定的时间点 |
| slack | 松弛时间，正值表示满足时序，负值表示违例 |
三、与上一份报告的区别（Ideal vs Propagated Clock）
| 对比项 | 上一份报告（ideal clock） | 当前报告（propagated clock） |
|---|---|---|
| Clock Network Delay | 标记为 ideal，延迟为 0ns | 标记为 propagated，有实际延迟 |
| Launch Clock Delay | 0.00ns | 0.11ns（发射路径上的时钟延迟） |
| Capture Clock Delay | 0.00ns | 0.12ns（捕获路径上的时钟延迟） |
| Data Arrival Time | 0.26ns | 0.35ns（更晚到达） |
| Data Required Time | 9.66ns | 9.78ns（更早到来） |
| Slack | 9.41ns | 9.43ns（略有改善） |
| 意义 | 初步分析（不考虑 clock tree） | 更精确的分析（考虑 clock tree） |
为什么会有这些变化？
因为在理想时钟模型中：
- 工具假设所有触发器的时钟引脚同时接收到时钟信号（没有 clock skew）。
- 这是一种简化模型，适合早期设计阶段快速分析。
而在传播时钟模型中：
- 工具已经综合并插入了 clock buffer，构建了真实的 clock tree。
- 不同触发器的 CK 引脚接收到时钟的时间不同（clock skew 存在）。
- 因此，launch path 和 capture path 都增加了 clock network delay。
四、总结重点
| 内容 | 解释 |
|---|---|
clock network delay (ideal) |
表示未考虑真实 clock tree，延迟为 0 |
clock network delay (propagated) |
表示已考虑 clock tree，有实际延迟 |
r/f |
表示信号边沿方向（rising/falling） |
Path Type: max |
表示这是 setup check（最长路径） |
slack > 0 |
表示 setup check 满足要求 |
clock uncertainty |
包括 jitter + margin，用于保证时序鲁棒性 |
library setup time |
触发器需要的建立时间，来自标准单元库 .lib 文件 |
五、小结
这份报告是使用“真实时钟树”（propagated clock）进行的 setup check 分析，相比理想时钟模型更准确，考虑了 clock network delay 的影响。
整个 clock tree 的路径和延迟信息
将详细解释：
- 这份报告的格式语法
- 它与之前两份报告的区别
- clock buffer 延迟是如何计算的
- set_input_transition 命令的作用
一、整体结构说明
这份报告仍然是一个 setup check，用于检查从 UFF0 到 UFF1 的路径是否满足 setup 时间要求。但这次不同的是：时钟树被完整展开，你可以看到 clock buffers (UCKBUF0, UCKBUF1, UCKBUF2) 在路径上的延迟。
1. 路径基本信息（Header）
Startpoint: UFF0 (rising edge-triggered flip-flop clocked by CLKM)
Endpoint: UFF1 (rising edge-triggered flip-flop clocked by CLKM)
Path Group: CLKM
Path Type: max
表示这是一个从 UFF0 到 UFF1 的 setup 检查路径，使用最大路径延迟（max 表示最长路径）。
二、数据路径详细信息（Data Arrival Path）
Point Incr Path Edge
---------------------------------------------------------------
clock CLKM (rise edge) 0.00 0.00
clock source latency 0.00 0.00
CLKM (in) 0.00 0.00 r
UCKBUF0/C (CKB ) 0.06 0.06 r
UCKBUF1/C (CKB ) 0.06 0.11 r
UFF0/CK (DFF ) 0.00 0.11 r
UFF0/Q (DFF ) <- 0.14 0.26 f
UNOR0/ZN (NR2 ) 0.04 0.30 r
UBUF4/Z (BUFF ) 0.05 0.35 r
UFF1/D (DFF ) 0.00 0.35 r
data arrival time 0.35
这部分描述了数据从发射触发器 UFF0 出发，经过组合逻辑到达捕获触发器 UFF1 的 D 输入所经历的时间。
关键点：
- 时钟路径上增加了两个 buffer：
UCKBUF0和UCKBUF1 - 它们的延迟分别为 0.06ns 和 0.06ns
- 总共带来 0.11ns 的 clock network delay 到达 UFF0 的 CK 引脚
⏱️ 三、所需时间路径（Required Time Path）
clock CLKM (rise edge) 10.00 10.00
clock source latency 0.00 10.00
CLKM (in) 0.00 10.00 r
UCKBUF0/C (CKB ) 0.06 10.06 r
UCKBUF2/C (CKB ) 0.07 10.12 r
UFF1/CK (DFF ) 0.00 10.12 r
clock uncertainty -0.30 9.82
library setup time -0.04 9.78
data required time 9.78
这部分描述了捕获边沿到来的时间，并考虑了 clock skew、uncertainty 和 setup time。
关键点：
- 同样使用了
UCKBUF0，但另一分支用了UCKBUF2，延迟为 0.07ns - 总 clock network delay 是 0.12ns 到达 UFF1 的 CK 引脚
- 最终 required time = 10.12 - 0.30 - 0.04 = 9.78 ns
四、Slack（松弛时间）
data required time 9.78
data arrival time -0.35
---------------------------------------------------------------
slack (MET) 9.43
Slack = Required Time - Arrival Time = 9.78 - 0.35 = 9.43 ns ✅ 满足 setup 要求
五、这份报告和之前的区别
| 内容 | 上一份（propagated） | 当前报告（expanded clock paths） |
|---|---|---|
| Clock Network Delay | 只显示总 delay（launch=0.11, capture=0.12） | 显示每个 clock buffer 的 delay |
| Clock Tree 展开 | ❌ 不可见 | ✅ 显示所有 clock buffer |
| Clock Source Latency | 隐含 | 显示为 0.00 |
| Input Transition | 默认理想（slew=0） | 可以通过 set_input_transition 设置 |
| 更精确性 | ✅ 已考虑 clock skew | ✅ 更细粒度分析 clock tree 延迟 |
六、Clock Buffer 延迟是如何计算的？
延迟公式：
Cell Delay = f(input transition time, output load capacitance)
也就是说，一个 cell 的 delay 取决于：
- 输入转换时间（input transition / slew）
- 输出负载电容（output capacitance）
第一个 clock buffer (UCKBUF0) 的 delay 计算：
问题：它的 input transition 是多少？
答案：
- 如果没有指定，默认为 理想值（ideal），即 rise=0ns，fall=0ns。
- 如果指定了，则使用用户设置的值。
示例命令：
set_input_transition -rise 0.3 [get_ports CLKM]
set_input_transition -fall 0.45 [get_ports CLKM]
表示：
- CLKM 输入端口的 rise transition = 0.3 ns
- CLKM 输入端口的 fall transition = 0.45 ns
这样，UCKBUF0 的 delay 就会基于这些 transition 来计算。
七、总结
这份报告展示了完整的 clock tree 结构，包括每个 clock buffer 的延迟，使得时序分析更加精确。相比之前的 propagated 模式，它进一步揭示了 clock path 的内部细节，并允许用户通过 set_input_transition 控制 clock 树起点的 slew，从而影响整个 clock path 的延迟计算。
关于信号边沿（r/f）和 clock source latency 的概念
- 数据路径可以是上升沿也可以是下降沿
- 即使同一个触发器对（UFF0 → UFF1），也可能存在多个 timing paths（不同边沿组合）
- clock source latency 的定义及其作用
一、整体结构说明
这是一份新的 setup check 报告，检查从 UFF0 到 UFF1 的路径是否满足 setup 时间要求。它与之前的报告有以下关键区别：
| 特征 | 上一份报告 | 当前报告 |
|---|---|---|
| 数据路径终点 | UFF1/D 上升沿（r） | UFF1/D 下降沿（f） |
| 所需时间 | 9.78 ns | 9.79 ns |
| 到达时间 | 0.35 ns | 0.33 ns |
| Slack | 9.43 ns | 9.46 ns |
这表示：虽然路径不同（数据变化方向不同），但都满足 setup 要求，甚至当前路径 slack 更大。
二、详细字段解析
Header 部分
Startpoint: UFF0 ...
Endpoint: UFF1 ...
Path Group: CLKM
Path Type: max
表示这是一个最大延迟路径（max path），即 setup check。
数据路径（Data Arrival Path）
Point Incr Path Edge
---------------------------------------------------------------
clock CLKM (rise edge) 0.00 0.00
clock source latency 0.00 0.00
CLKM (in) 0.00 0.00 r
UCKBUF0/C (CKB ) 0.06 0.06 r
UCKBUF1/C (CKB ) 0.06 0.11 r
UFF0/CK (DFF ) 0.00 0.11 r
UFF0/Q (DFF ) <- 0.14 0.26 r
UNOR0/ZN (NR2 ) 0.02 0.28 f
UBUF4/Z (BUFF ) 0.06 0.33 f
UFF1/D (DFF ) 0.00 0.33 f
data arrival time 0.33
关键点：
- 本路径以 UFF0/Q 输出为上升沿（r） 开始；
- 经过逻辑门后，在 UNOR0/ZN 输出为下降沿（f）；
- 最终到达 UFF1/D 输入也为下降沿（f）；
- 总到达时间为 0.33ns
所需时间路径（Required Time Path）
clock CLKM (rise edge) 10.00 10.00
clock source latency 0.00 10.00
CLKM (in) 0.00 10.00 r
UCKBUF0/C (CKB ) 0.06 10.06 r
UCKBUF2/C (CKB ) 0.07 10.12 r
UFF1/CK (DFF ) 0.00 10.12 r
clock uncertainty -0.30 9.82
library setup time -0.03 9.79
data required time 9.79
关键点：
- 捕获边沿仍为 CLKM 的下一个周期（10ns）；
- 加上 clock network delay 后，实际到达 CK 引脚的时间为 10.12ns；
- 减去 library setup time（0.03ns），得到 required time = 9.79ns
Slack 计算
data required time 9.79
data arrival time -0.33
---------------------------------------------------------------
slack (MET) 9.46
Slack = Required Time - Arrival Time = 9.79 - 0.33 = 9.46 ns ✅ 满足 setup 要求
三、与上一份报告的区别
| 对比项 | 上一份报告 | 当前报告 |
|---|---|---|
| 数据路径终点边沿 | 上升沿（r） | 下降沿（f） |
| 到达时间 | 0.35 ns | 0.33 ns |
| setup time | 0.04 ns | 0.03 ns |
| required time | 9.78 ns | 9.79 ns |
| slack | 9.43 ns | 9.46 ns |
| 是否考虑 clock source latency | 是 | 是 |
| clock tree 是否展开 | 是 | 是 |
| 逻辑门延时变化 | UNOR0 延迟为 0.04ns | UNOR0 延迟为 0.02ns（因输入边沿不同） |
结论：
- 同样的触发器之间可能存在多条 timing paths，取决于数据在路径上的变化方向（r/f）；
- 不同的边沿组合会导致不同的组合逻辑延迟，进而影响最终 slack；
- 即使 setup time 不同，只要 slack > 0，路径就满足时序。
⚙️ 四、什么是 clock source latency？
Clock source latency（也称为 insertion delay）是指时钟从其源头传播到设计中的 clock definition point 所花费的时间。
示例图（Figure 8-3 中描述的场景）：
[外部时钟源] --> [时钟树部分] --> [设计入口 CLKM]
↑
└── clock source latency
应用场景举例：
- 如果这个模块是一个更大系统的一部分，那么 clock source latency 就是从芯片外的 PLL 到该模块的 CLKM 端口所经历的延迟。
- 它不包括模块内部的 clock tree（这部分由 clock network delay 表示）。
如何设置？
set_clock_latency -source 2.0 [get_clocks CLKM]
表示：
- CLKM 的 clock source latency 为 2.0ns
如果不设置，默认值为 0.0ns（即假设外部时钟源就在设计入口处）
五、总结
这份报告展示了从发射触发器到捕获触发器的不同 timing path（基于数据边沿变化），并明确指出了 clock source latency 的含义及其在时序分析中的作用。相比之前的报告，它强调了 setup check 可能存在多种路径组合，且每种路径的 slack 和延迟可能略有不同。