FPGA 和数字 IC 的时序优化，可以沿着一条主线理解：先确认约束正确，再分析关键路径，最后选择 RTL、架构或物理实现层面的优化方法。 优化时还要同时考虑面积、功耗、吞吐量和延迟。
下面将"数字 IC"主要按标准单元 ASIC 设计讨论。
1．先理解 Setup 和 Hold 分别在限制什么
典型同步路径是：
发送寄存器 → 组合逻辑 → 布线 → 接收寄存器
| 检查项 | 检查的本质 | 常见修复方向 |
|---|---|---|
| Setup，建立时间 | 数据是否在捕获边沿前足够早地到达 | 减少逻辑或布线延迟、增加流水线 |
| Hold，保持时间 | 新数据是否过早到达，破坏当前采样 | 增加最小数据延迟、改善时钟偏斜 |
| Recovery / Removal | 异步复位等控制信号的释放是否满足要求 | 规范复位释放、检查同步与时钟关系 |
| 最小脉宽 | 时钟或控制脉冲是否足够宽 | 检查时钟波形、门控和时钟生成方式 |
对同一时钟、同沿、单周期寄存器路径 ，令时钟偏斜
\(S=t_{\text{capture clock}}-t_{\text{launch clock}}\)，可以用以下简化模型理解：
\ Slack_{\\text{setup}} =T+S-t_{CQ,\\max}-t_{data,\\max}-t_{setup}-U_{setup} \\\ Slack_{\\text{hold}} =t_{CQ,\\min}+t_{data,\\min}-S-t_{hold}-U_{hold} \\
其中，\(t_{data}\) 包括组合逻辑和布线延迟，\(U\) 表示相应的不确定度。
由此可以直接看出：
- 降低频率通常有助于 Setup，对上述 Hold 检查通常没有直接帮助。
- 接收时钟晚到，即正偏斜，有利于 Setup，但会压缩 Hold 裕量。
- 数据路径变快后，Setup 可能改善，Hold 可能恶化。
实际 STA 还会考虑时钟边沿关系、工艺变化和公共时钟路径悲观修正等因素，应以工具报告为准。AMD 时序裕量分析
2．看到违例后，先把报告读明白
不要只看一个 WNS 数字。至少检查以下内容：
| 报告信息 | 需要判断的问题 |
|---|---|
| Startpoint / Endpoint | 是寄存器间、输入到寄存器，还是寄存器到输出？ |
| Launch / Capture Clock | 时钟关系和捕获边沿是否符合设计意图？ |
| Requirement | 路径实际有多少时间预算？是否异常苛刻？ |
| Cell / Logic Delay | 是否存在深层逻辑、长进位链或复杂选择逻辑？ |
| Net Delay | 是否存在高扇出、长距离连接或拥塞绕线？ |
| Clock Skew / Uncertainty | 时钟路径是否消耗了过多裕量？ |
| 违例路径分布 | 是少数局部路径，还是整片区域、整个时钟域的问题？ |
Vivado 中常用指标的含义：
- WNS：最大延迟分析中最差的 slack。
- TNS：按每个终点的最差违例汇总的负 slack。
- WHS / THS：最小延迟分析中对应的最差值和汇总值。
- Failing Endpoints：违例终点数量。
WNS 反映最差程度，TNS 和违例终点数反映影响范围。 综合后的布线延迟主要是估计值，最终判断需要看实现、布线后的结果。AMD 时序收敛指南、UG906 指标定义
3．约束检查应当放在优化之前
约束定义了工具要满足的外部条件，重点检查：
- 时钟：主时钟、生成时钟、周期、相位、波形及其相互关系。
- I/O：依据外部器件和板级时序，完整设置最大、最小输入输出延迟。
- 不确定度：正确描述抖动和设计裕量。
- 例外：每条 False Path、Multicycle Path 都有明确的功能依据。
- 覆盖范围：不存在未经解释的无时钟路径和未约束终点。
几个容易混淆的点：
不同频率不代表异步；相同频率也不代表同步。 关键在于时钟之间是否存在可保证的相位关系。
False Path 只改变分析范围。 CDC 仍需要同步器、握手或异步 FIFO 等正确结构；多位总线不能简单逐位接两级寄存器后就认为数据一致。
Multicycle Path 必须符合真实采样行为。 "数据变化很慢"本身不足以证明它是多周期路径。同波形、同相位时钟下，常见配置是 Setup 为 \(N\)、Hold 为 \(N-1\)；跨频率或相移时钟需要重新检查边沿关系。AMD UG903 多周期约束说明
4．RTL 和架构优化，核心是减少每一级实际承担的工作
| 方法 | 适用情况 | 主要代价或注意事项 |
|---|---|---|
| 增加流水线 | 单周期组合路径过长 | 增加周期延迟、寄存器和时钟负载 |
| 寄存器重定时 Retiming | 相邻流水级工作量不均衡 | 受复位、使能、层次和保护属性限制 |
| 平衡运算树 | 多操作数加法、比较、归约 | 检查位宽、截断和数值语义 |
| 并行计算、预计算 | 串行依赖过深 | 增加面积和功耗 |
| 缩减位宽 | 不必要的宽运算、宽比较、宽 MUX | 必须证明数值范围和精度 |
| 优化选择与译码 | 深层优先级链、大型多路选择器 | 保留原有优先级和非法输入行为 |
| 复制驱动、局部译码 | 高扇出控制或数据信号 | 增加资源，需要避免重新合并 |
例如，四个数求和时，可以比较串行结构
\(((a+b)+c)+d\) 与平衡结构 \((a+b)+(c+d)\) 的实现结果。综合器可能已经完成平衡，最终应检查综合网表，不能仅凭 RTL 写法推断电路层数。
增加流水线时，还要检查三个问题：
- 是否切在真正的长路径中间？ 在组合逻辑两端额外加寄存器，不一定缩短原关键路径。
- 数据和控制是否对齐？
valid、地址、模式、标签等需要对应延迟。 - 吞吐量是否保持？ 流水线延迟增加，不代表每周期接收数据的能力下降；反馈环路则可能限制流水化。
反压接口还应检查 ready 等组合控制链，必要时使用寄存器切片或弹性缓冲。AMD 也强调，流水化必须同步处理新增延迟对其余设计的影响。AMD 流水线设计说明
5．FPGA 优化要结合器件的固定资源结构
FPGA 上除了逻辑层级，还要重点关注专用资源映射和连接距离：
- DSP：检查乘法、乘加是否映射到合适的 DSP，以及内部寄存器是否有效使用。
- BRAM / URAM：合理使用输出寄存器，避免存储器输出后紧接深层组合逻辑。
- LUT / Carry Chain：检查算术和选择逻辑的实际映射，比较实现后的结果。
- 高扇出网络：按模块或物理区域复制驱动，减少跨区域连接。
- 布局与拥塞：检查局部密度、资源分布、跨 SLR 总线和绕线情况。
- 控制集与复位：减少不必要的控制组合；允许时可通过复位有效标志管理数据通路状态。
- 优化限制属性 ：检查
DONT_TOUCH、KEEP、调试标记是否妨碍复制、合并或重定时。
高扇出优化并非复制越多越好：过度复制可能增加控制集、面积和功耗，应比较物理实现结果。AMD 高扇出网络优化说明
6．数字 IC 还可以从标准单元和时钟树层面优化
| 优化手段 | 作用 | 需要同时检查的代价 |
|---|---|---|
| 单元尺寸调整 | 改善关键节点驱动能力 | 输入电容、面积、动态功耗 |
| 阈值电压替换 | 在速度和漏电之间调整 | 漏电及其他路径的裕量 |
| 插入 Buffer、复制驱动 | 改善长线或高扇出网络 | 面积、功耗、拥塞 |
| 逻辑重构、引脚交换 | 改善关键时序弧或逻辑结构 | 等价性及实际延迟收益 |
| 布局、宏单元与布线调整 | 缩短距离、改善寄生参数 | 拥塞和其他路径变化 |
| CTS 与 Useful Skew | 调整时钟到达时间分配 | 相邻路径的 Setup / Hold |
这些操作需要结合路径负载和物理结果判断。例如，放大一个单元虽然增强了输出驱动，但也增加了前级负载，不一定改善整条路径。OpenROAD 的时序修复流程也将尺寸调整、缓冲、复制和阈值电压替换等作为不同优化动作。OpenROAD 单元与时序优化文档
ASIC 最终还需要在规定的**多模式、多角条件（MCMM）**下检查，并纳入寄生参数、串扰和工艺变化等因素，避免一个场景改善、另一个场景恶化。Synopsys PrimeTime 时序签核说明
7．Hold 修复应单独分析
Hold 违例常见原因包括数据路径太短、时钟偏斜较大，以及不正确的时钟或例外约束。
- FPGA：通常由实现工具通过布线和物理优化增加必要延迟，异常大的违例应先检查约束和时钟结构。
- ASIC：常用延迟单元、Buffer 或其他物理调整增加最小数据延迟，同时检查 Setup 是否被破坏。
RTL 中随意串反相器可能被综合消除；仿真的 #delay 也不能作为硬件修复方式。流程中应持续监控 Setup 和 Hold，尤其是在时钟树和布线确定之后。OpenROAD Setup / Hold 修复说明
8．实际工程可以按这个顺序推进
- 固定基线：保存 RTL、约束、工具设置、利用率和时序报告。
- 确认分析可信：检查时钟、I/O、例外、未约束路径及 CDC。
- 按根因归类：区分逻辑延迟、布线延迟、时钟问题和约束问题。
- 选择对应手段：逻辑深就重构或流水化；布线长就改善扇出、距离和拥塞。
- 检查功能与接口：确认精度、复位、流水延迟、吞吐量和反压行为。
- 比较实现结果：同时看 WNS、TNS、Hold、面积、功耗和拥塞。
- 完成最终验证：以约束完整、目标条件覆盖充分的布线后 STA 结果作为时序收敛依据。
最值得养成的习惯是：每次优化前，先用报告说明"时间花在哪里"；每次优化后，再验证"收益来自哪里、代价是什么"。