作者：Yin Chaowen，AMD工程师；文章来源：AMD 开发者社区
DESCRIPTION｜问题描述
Vivado 的 Design Timing Summary 会分别为 setup、hold 和 pulse width 报告一项 Worst slack（WNS / WHS / WPWS）、一项 Total slack（TNS / THS / TPWS），以及 Total Failing Endpoints。在某些设计中，把 report_clock_interaction 的 setup / hold 行逐行相加，会得到一个比 Summary 更负、端点数也更多的结果。
这通常是预期行为：分解报告与 Summary 使用了不同的聚合单位。同一端点只要出现在多个分解行中，手工相加就会重复计数。TPWS 使用相同的端点规则，但其自然的按时钟分解能够与 Summary 精确相加；只有把同一引脚上的多种 pulse-width 检查手工相加时才会多算。
SOLUTION｜计算规则与对账
一个统一规则：TNS、THS 与 TPWS 完全相同
每个 Total 都只统计失败端点。
对每个端点收集其全部 slack，只保留该端点自己的单个最差值；若该值小于 0，则计入 Total，并且该端点在 Total Failing Endpoints 中只计一次。
Total = Σ失败端点 e min(slacke) · Failing Endpoints = 不同失败端点的数量
- 一个端点无论参与多少条路径、时钟关系或检查类型，都只按自己的最差 slack 贡献一次。
- slack 大于或等于 0 的端点对 Total 的贡献为 0。
为什么分解报告逐行求和会重复计数
因此，对 TNS / THS 而言，分解行之和总是等于或比 Summary 更负；只有不存在跨行共享端点时二者才相等。TPWS 的自然 Intra-Clock 分解不具备这种共享条件，因此通常能直接相加。
Example 1｜THS：50 个共享端点的实测设计
匿名化设计案例的 Design Timing Summary 报告 THS = -59.178 ns，52 个失败端点。把 Clock Interaction 中 5 个 hold 违例时钟对直接相加，则得到 -(55.002 + 3.953 + 4.151 + 3.771 + 0.026) = -66.903 ns，明显更负。
图 1 匿名化设计案例的 Design Timing Summary：Setup 满足，Hold 为 THS -59.178 ns / 52 个失败端点，Pulse Width 满足。
对账结果：THS = -(55.002 + 4.151 + 0.026) = -59.179 ≈ -59.178 ns；失败端点 = 50 + 1 + 1 = 52。手工行和重复计算了 50 个共享端点及另一个共享端点。
图 2 同一设计的 Clock Interaction hold 行。每行对时钟关系本身是正确的；问题只出现在把共享端点所在的多行直接相加。
该结果在 Vivado 2025.1、器件 7a50t 上复现。共享端点的常见成因是同一时钟复用器输出上定义了两个生成时钟，见文末 Appendix。
Example 2｜TNS：端点跨两个时钟对的最小复现
最小设计包含 8 个 cap 端点。它们分别由 clkA 与 clkB 发出、由 clkC 捕获，因此每个 cap[i] 同时属于 clkA→clkC 和 clkB→clkC 两个时钟对。Design Timing Summary 报告 TNS = -14.280 ns，16 个失败端点。
图 3 最小复现的 Design Timing Summary：Setup 为 TNS -14.280 ns / 16 个失败端点；同一面板也给出 Example 3 的 TPWS 数据。
精确对账：-20.816 + 6.536 = -14.280 ns；24 - 8 = 16 个端点。这与 THS 示例是同一个机制。
图 4 Clock Interaction 的三行 setup TNS：每行 8 个端点；clkA 与 clkB 两行共享同一批 cap 端点。
Example 3｜TPWS：同一规则，但自然分解不会产生行和不一致
同一最小设计的 Design Timing Summary 报告 TPWS = -22.400 ns，32 个失败端点。每个时钟引脚同时有 Min Period、Low Pulse Width 与 High Pulse Width 三种负 slack；Summary 只保留该引脚自己的最差检查。
图 5 report_pulse_width 中同一引脚的三类失败检查。Summary 仅保留最差的 Min Period -0.700。
端点对账：32 个引脚 × -0.700 ns = -22.400 ns，精确等于 Design Timing Summary。
TPWS 的自然分解位于 Timing Summary 的 Intra-Clock 表中。一个时钟引脚只属于一个时钟，因此不会跨该表的多个时钟行共享：
分解对账：-5.600 - 5.600 - 11.200 = -22.400 ns；8 + 8 + 16 = 32。自然的按时钟分解与 Summary 完全一致，没有重复计数。
