vivado使用那些事之优化时序利用implemention实现策略
Vivado Implementation 参数
一、怎么打开GUI设置界面
TOOLS -> settings
再点击左边的Implemention
这是Xilinx Vivado设计套件中Implementation（实现）阶段的参数设置界面。实现阶段是将综合后的网表映射到具体 FPGA 器件资源、进行布局布线并最终生成比特流的关键步骤。
从上往下看
二、Constraints（约束设置）
- Default constraint set:
constrs_1 (active)- 指定实现阶段使用的默认约束集。约束文件（XDC）定义了时序约束（时钟频率、I/O 延迟）、引脚分配（pinout）、物理约束（区域约束、Pblock）等。
constrs_1是 Vivado 默认创建的约束集名称，(active)表示当前激活使用。- 你可以为不同的实现策略创建不同的约束集，通过下拉菜单切换。
三、Report Options（报告选项）
控制实现过程中自动生成哪些报告。
Strategy（报告策略）下拉菜单
| 策略 | 说明 |
|---|---|
| Vivado Implementation Default Reports | 默认报告集，通常只生成最基本的实现报告（如利用率、时序摘要），适合快速迭代。 |
| UltraFast Design Methodology Reports | 遵循 Xilinx UltraFast 设计方法学的完整报告集，会生成更详细的检查报告（如 DRC、方法论检查、时序分析），推荐用于正式项目验收。 |
| Performance Explore Reports | 侧重性能探索的详细报告，包含更多时序、拥塞、资源分析，适合在优化性能阶段使用。 |
| Timing Closure Reports | 专注于时序收敛的报告集，生成大量时序相关报告，帮助诊断 setup/hold 违例。 |
| No Reports | 不自动生成任何报告，仅保留日志，适合脚本化批量运行且不关心中间报告的场景。 |
>关键点：报告策略只影响输出的.rpt文件数量和详细程度，不改变布局布线的算法和结果。
四、Options（选项）
1. Incremental implementation（增量实现）
- 允许基于上一次实现结果进行增量编译，只重新处理变更的部分，大幅缩短编译时间。
2. Strategy（实现策略）
决定布局布线阶段使用什么算法、优化目标和搜索策略，直接影响实现结果。
| 策略名称 | 核心特点 |
|---|---|
| Vivado Implementation Defaults | 默认平衡策略，兼顾时序、面积和运行时间。 |
| Performance_Explore | 探索多种布局方案以追求最佳性能，编译时间较长。 |
| Performance_ExplorePostRoutePhysOpt | 在布线后额外进行物理优化，进一步提升时序。 |
| Performance_ExploreWithRemap | 包含重映射优化，尝试不同的逻辑映射方案。 |
| Performance_WLBlockPlacement | 优化线长（Wirelength），适合模块间连线复杂的设计。 |
| Performance_WLBlockPlacementFanoutOpt | 在优化线长的同时重点优化高扇出网络。 |
| Performance_EarlyBlockPlacement | 优先处理关键模块的初始布局。 |
| Performance_NetDelay_high | 侧重减少网络延迟，适合高速接口。 |
| Performance_NetDelay_low | 侧重低延迟优化，资源开销较小。 |
| Performance_Retiming | 启用重定时优化，移动寄存器位置以改善时序。 |
| Performance_ExtraTimingOpt | 额外的时序优化，编译时间更长。 |
| Performance_RefinePlacement | 精细化布局优化，适合接近收敛时的微调。 |
| Performance_SpreadSLLs | 针对 SLR（Super Logic Region）跨 die 设计的优化。 |
>关键点：实现策略直接改变布局布线算法，最终得到的最大时钟频率、资源利用率、编译运行时间都会发生变化。
3. 子步骤展开项
实现流程由多个子步骤串联而成，每个子步骤通常都有tcl.pre和tcl.post脚本钩子：
- Design Initialization (init_design)：设计初始化，加载网表和约束，进行初步的 DRC 检查。
- Opt Design (opt_design)：逻辑优化阶段。
is_enabled：是否启用该步骤的开关。tcl.pre/tcl.post：在该步骤前/后自动执行的 Tcl 脚本钩子，可用于自定义流程（如插入调试逻辑、导出中间文件、修改约束等）。
类似地，实现流程还包含（图中未完全显示）：
- Place Design：布局阶段
- Phys Opt Design：物理优化
- Route Design：布线阶段
- Write Bitstream：生成比特流
五、Report Options Strategy vs Options Strategy 的区别
| Report Options > Strategy | Options > Strategy | |
|---|---|---|
| 本质 | 报告策略— 决定"输出什么" | 实现策略— 决定"怎么做" |
| 影响对象 | 只影响生成的报告文件种类和数量 | 直接影响布局布线算法和优化方向 |
| 是否改变实现结果 | ❌ 不影响时序、资源、功耗 | ✅ 直接改变时序、资源、运行时间 |
| 类比 | 像"打印设置"（单面/双面、彩印/黑白） | 像"驾驶模式"（经济/运动/舒适） |
>一句话总结：Report Options Strategy 决定"跑完后给你看什么报告"；Options Strategy 决定"用什么样的算法把你的设计布进芯片里"。
两者是正交的：你可以用Performance_Explore实现策略追求最高性能，同时选No Reports来节省报告生成时间；也可以用默认实现策略，但选Timing Closure Reports来详细分析时序。
六、使用建议
| 场景 | 推荐设置 |
|---|---|
| 日常调试、快速编译 | Strategy: Default；Report: No Reports 或 Default |
| 首次时序收敛 | Strategy: Performance_Explore；Report: Timing Closure Reports |
| 最终版本验证 | Strategy: 根据需求选择；Report: UltraFast Design Methodology Reports |
| 大型设计迭代 | 启用 Incremental Implementation，搭配 Default Reports |
| 高扇出/复杂连线设计 | Strategy: Performance_WLBlockPlacementFanoutOpt |
| 跨 SLR 的 7 系列/UltraScale+ 设计 | Strategy: Performance_SpreadSLLs |
七、Tcl 脚本钩子示例
你可以在tcl.pre或tcl.post中编写自定义脚本，例如：
# opt_design 之前执行的脚本 (tcl.pre) puts "Starting custom pre-opt script..." report_utilization -file pre_opt_utilization.rpt