【vivado UG学习】Implementation策略学习

implementation 过程把一个【逻辑网表(logical netlist)和约束(constraints)】转换为一个【完成布局（place）和布线(route)的设计】。

1 综合前的准备

Vivado高层次设计流程：

Markdown将文本转换为 HTML。

1.1 Vivado Implementation 子过程

1. Opt Design:优化逻辑设计，使其更容易适合目标Xilinx器件。
2. Power Opt Design(可选)：优化设计元素，以降低目标Xilinx器件的功率需求。
3. Place Design:将设计完成在目标Xilinx器件上的布局。
4. Post-Place Power Opt Design (可选)：额外的优化，以减少布局后的功率。
5. Post-Place Phys Opt Design(可选)：基于位置估计时序用于优化逻辑和布局，包括复制具有高扇出的驱动以减少扇出。
6. Route Design：完成目标设计在对应器件上的布线。
7. Post-Route Phys Opt Design(可选)：用实际的线路延迟来优化逻辑、布局以及布线。
8. Write Bitstream：为Xilinx器件配置生成bit流。通常，位流的生成是在实现之后。

1.2 管理Implementation

1.2.1 工程模式和非工程模式

• 导入之前综合后的网表文件，支持的格式:

  • Structural Verilog
  • Structural SystemVerilog
  • EDIF
  • Xilinx NGC
  • Synthesized Design Checkpoint (DCP)

  *UltraScale器件不支持 NGC。
  *IP核使用XCI文件而不是DCP文件，这确保IP输出产品在设计流程的所有阶段都得到一致的使用。
  *如果时RTL文件，Vivado会自动先完成综合。

1.4 用约束引导Implementation

1.4.1 物理约束和时序约束

两种类型的约束：物理（physical）约束核时序（timing）约束：

• 物理约束：定义了逻辑设计对象和设备资源之间的关系，如

  • 引脚布局
  • 各单元的绝对或相对位置，包括块RAM、DSP、LUT和触发器。
  • 预布局（Floorplanning）约束，指定单元在器件中的区域。
  • 器件配置。

• 时序约束：定义了设计的频率要求，采用标准SDC编写。
  在没有时间限制的情况下，Vivado只针对线路长度和布线拥塞优化设计，不评估或改善设计的性能。

*不支持UCF格式的约束文件。

1.4.4 约束集

约束集是可应用于项目模式中的设计的约束文件列表，该集合包含XDC或Tcl文件中获取的设计约束。

合法的约束集结构：

• 一个约束集有多个约束文件。
• 约束集物理约束和时序约束时分开的。
• 一个主约束文件。
• 新的约束文件可以更改之前的约束。
• 多个约束集。

建议：按功能将约束分离到不同的约束文件中，以(a)使约束策略更清晰，(b)便于目标时间安排和实施更改。
多个约束集
一个项目可以有多个约束集，这样就可以按不同约束进行implementation。
也可以用一个约束集给Synthesis，一个约束集给implementation。这样可以在综合，实现，和仿真时应用不同的约束。
多个约束集的好处：

• 给相同的工程设定不同的器件，不同的器件需要不一样的物理和时序约束。
• 执行what-if设计探索。使用约束集来探索floorplanning和over-constraining设计的各种场景。
• 管理约束改变，用一个独立的约束文件覆盖主约束。

技巧：要验证时序约束，请在synthesis后的设计上运行report_timing_summary。在implementation之前修复有问题的约束!

1.4.5 约束中也可以添加关于属性的描述

1.5 用Checkpoints保存设计快照（snapshots）

Checkpoint文件(.dcp)用来保存设计流程中某个关键节点的物理数据库，这个数据库存储了布局和布线的关键信息，一个checkpoint就是一个关键运行节点的快照。
.dcp文件包含：

• 当前的网表，包含implementation过程中所有的优化。
• 设计约束。
• implementation的结果。

dcp文件可以被其他流程用Tcl命令使用，但是不能被修改。
重要：在项目模式下，Vivado设计工具会随着设计的进展自动保存和恢复检查点。在非项目模式下，您必须在设计流程的适当阶段保存检查点，否则，进程将丢失。

写checkpoint文件：write_checkpoint
读checkpoint文件：open_checkpoint

2 Implementing the Design

非项目模式下implementation的Tcl脚本：

• opt_design
• power_opt_design
• place_design
• phys_opt_design
• route_design
• write_bitstream

项目模式：
主菜单Flow->creat run->implementation可以创建新的implementation

Name：implementation的名字。
Synth Name：将要生成(或已经生成)要实现的implementation网表的Synthesis。
Constraints Set：约束集。

2.2.3 设计运行的相关设置

设置窗口可以进行设置。

2.3 自定义implementation的策略

2.3.2 定义策略

策略是为了解决synthesis和implementation中问题而提前定义的方法。

• 策略是为Vivado Implementation功能而在预先的配置集中定义的。
• 策略与不同的工具和版本相关。
• 每个发行的Vivado设计环境包含了版本特定的策略。

技巧:不可以改变内置的策略，但是可以复制，修改然后保存为自定义的策略。

2.3.4 查看，复制和修改策略

区域4中➕号可以创建新策略。
区域4中的copy符号可以复制当前策略，并保存在自定义策略列表。

自定义策略存储路径：C:\Users<username>\AppData\Roaming\Xilinx\Vivado\strategies

将策略文件复制到 /Vivado//strategies 就可以使用这个策略。

2.10 逻辑优化（Logic Optimization）

逻辑优化确保进行placement之前是最高效的逻辑设计。它执行网表连接性检查对潜在的设计问题提出警告，比如多驱动的nets，无驱动的inputs，逻辑优化也执行block RAM的功耗优化。

通常，设计连接错误会延续到逻辑优化步骤，从而导致设计流程失败。在implementation之前用DRC 报告确保有效的连接是很有必要的。

逻辑优化会跳过DONT_TOUCH属性为TRUE的cells和nets。

2.10.2 Opt Design: -Directives指令说明

逻辑优化的指令列表:

• Explore:运行多重优化。
• ExploreArea：强调减少组合逻辑的多重优化。
• AddRemap：运行默认的逻辑优化，并进行LUT重新映射以减少逻辑级别。
• ExploreSequentialArea：运行强调减少寄存器和相关组合逻辑的多重逻辑优化。
• RuntimeOptimized：运行最少的逻辑优化，以设计性能换取运行时间。
• NoBramPowerOpt：运行所有默认的优化除了 block RAM 功耗优化。
• ExploreWithRemap：在Explore的基础上假设Remap优化。
• Default：以默认设置运行opt_design。

-debug_log和-verbose

• -debug_log查看更多的优化结果细节。
• -verbose查看所有的执行的逻辑优化。

2.10.3 逻辑优化约束

1. DONT_TOUCH

• 防止对应的nets或cells进行优化。
• 约束的cells保证边界不被优化，但内部可能仍然会进行优化，常数仍然可以跨边界传递。为了防止层次内不被优化，使用get_nets的-segments选项将DONT_TOUCH属性应用到所有nets。
• 对于MARK_DEBUG为TRUE的nets，工具会自动将DONT_TOUCH属性置为TRUE。
• 在极少数情况下，DONT_TOUCH可能限制太大，可能会阻止诸如constant propagation、 sweep或remap等优化，从而导致更困难的时序收敛。在这种情况下，可以将DONT_TOUCH设置为FALSE，同时保持MARK_DEBUG为TRUE。这样做的风险是可能会被优化掉。

2.10 Power Optimization

2.10.1 时钟使能（CEs）

Vivado在7系列中运用丰富的时钟使能进行功耗优化。这些工具创建精细的时钟门控，或逻辑门控信号，消除寄存器中不必要的切换活动。
此外，在触发器级，CEs实际上是对时钟进行使能而不是触发器的D输入和反馈Q输出。这增加了CE输入的性能，而且也降低了时钟功率。

2.10.2 智能门控时钟

根据功耗决定是否添加门控时钟。对于block RAMs根据是否有数据输入或输出添加门控时钟。

2.11 Placement

Vivado Design Suite placer将网表中的cells放置到器件中的特定位置。

Vivado placer同时优化设计布局：

• Timing slack: 将cells放置在关键时间路径中以最小化负松弛。
• Wirelength（线长）: 总体布局是为了尽量减少连接的总长度。
• Congestion（拥塞）: 该Vivado placer监测pin密度和分散cells，以减少潜在的路由拥塞。

2.11.2 设计规则检查

在开始布局之前，Vivado实现运行设计规则检查(drc)，包括用户从report_drc选择的drc，以及Vivado placer内部的内置drc。内部drc检查非法放置，如没有LOC约束的内存IP单元和具有冲突iostandard的I/O bank。

2.11.3 时钟和I/O布局

规则检查之后开始，时钟和I/O单元同时放置因为它们通常通过特定于目标Xilinx器件的复杂放置规则相互关联。

placer布局的目标

• I/O口及其相关的逻辑。
• 全局和本地时钟缓冲器。
• 时钟管理器 (MMCMs and PLLs)。
• Gigabit 收发器(GT)单元。

布置不确定的逻辑。比如LOC属性和Pblock赋值。

当时钟和I/O布局失败的原因：

• 由冲突的约束引起的时钟树问题。
• 时钟树问题太复杂了。
• RAM和DSP块放置与其他约束冲突，如pblock。
• 资源过度使用。
• 不符合I/O bank的要求和规则。

技巧：首先使用place_ports来运行时钟和I/O放置步骤。然后运行place_design。如果端口放置失败，则将放置位置保存到内存中，以便进行故障分析。

2.11.5 Place Design:-directives指令说明

类型以及对应有益处的设计类型：

• BlockPlacement：多block RAM, DSP块的设计。
• ExtraNetDelay：多长距离net连接和对许多不同的模块扇出的nets。
• SpreadLogic：容易造成拥塞的高连接性设计。
• ExtraPostPlacementOpt：所有设计类型。
• SSI：分区以缓解拥塞或提高时序。

可选的指令：

• -Explore：强调细节布局和布局后优化。
• -WLDrivenBlockPlacement: 根据线长完成RAM和DSP块的放置。强调时序驱动布局以最小化块之间的距离，可以提高RAM和DSP块的时序。
• -EarlyBlockPlacement:根据时序完成RAM和DSP块的放置。放置过程的早期确定RAM和DSP块位置是在，并用作锚放置剩余的逻辑。
• -ExtraNetDelay_high: 增加高扇出以及长距离nets预估的延时，这个指令可以改善关键路径的计时，在place_design之后满足时序，但在route_design过程由于过于乐观的估计延迟导致不满足时序要求。ExtraNetDelay_high适用于最悲观水平。
• -ExtraNetDelay_low: 与ExtraNetDelay_high一样，但是ExtraNetDelay_low应用最乐观水平。
• -SSI_SpreadLogic_high: 在整个SSI器件中分散分布逻辑，以避免造成拥塞区域。支持两个分散级别:高和低。SpreadLogic_high达到分散的最高水平。
• -SSI_SpreadLogic_low: SpreadLogic_low实现最小的分散级别。
• -AltSpreadLogic_high: 在整个设备中分散分布逻辑，以避免产生拥塞区域。支持三个分散级别:高、中、低。AltSpreadLogic_high实现了最高级别的分散。
• -AltSpreadLogic_medium: 中等级别的分散。
• -AltSpreadLogic_low: 低级别的分散。
• -ExtraPostPlacementOpt: 尽量布局后优化
• -ExtraTimingOpt: 在后期阶段使用一个可选的算术集用于时序驱动的布局。
• -SSI_SpreadSLLs: Partition across SLRs并且为高连通性区域分配额外的区域。
• -SSI_BalanceSLLs: Partition across SLRs当试图平衡SLLs与SLRs时。
• -SSI_BalanceSLRs: Partition across SLRs以平衡cells与SLRs。
• -SSI_HighUtilSLRs: 迫使placer尝试在每个SLR中把逻辑更紧密地放在一起。
• -RuntimeOptimized: 运行更少的迭代次数，以更低的设计性能换取更快的运行时间。
• -Quick: 更快的运行时间。
• -Default: 使用默认设置运行place_design。

其他的选项:

• -unplace: unplace选项将在设计中没有固定位置的所有单元和所有端口进行unplace。
• -no_timing_driven: 关闭所有的时序约束。这使得基于导线长度的放置更快。
• -timing_summary: 放置之后，估计的时序摘要将输出到日志文件。
• -verbose：查看cells和I/O布局的更多细节。
• -post_place_opt: 放置后优化是一种放置优化，它可能以额外的运行时间为代价提高关键路径的时序。
• -fanout_opt: 在可选的扇出优化阶段，placer可以复制驱动高扇出网(fanout > 1000, Slack < 2.0 ns)的寄存器，或者使用专用块负载(BRAM, FIFO, URAM, DSP)的寄存器，这些块负载被放置得很远(Slack < 0.5 ns)。
• -no_bufg_opt: 该placer在global routing tracks上路由高扇出net节省布线资源。

2.14 Physical Optimization

物理优化对设计的负松弛路径进行时序驱动优化。物理优化有post-place和post-route两种操作方式。

在post-place模式下，基于cells布局的时序估计进行优化。物理优化会根据逻辑优化和cells布局的需要自动合并网表的变化。

在post-route模式下，根据实际路由延迟进行优化。除了在逻辑更改和放置cells上自动更新网表外，物理优化还会根据需要自动更新路由。

路径后物理优化最有效地用于有一些失败路径的设计。在WNS<-0.200 ns或超过200个失败端点的设计上使用post-route物理优化会导致长时间运行，而对QOR几乎没有改善。

在post-place模式中，整体物理优化更加积极，因为在post-place模式中有更多的逻辑优化机会。在post-route模式下，物理优化往往更加保守，以避免干扰时间封闭的路由。在运行之前，物理优化检查设计的路由状态，以确定使用哪种模式，post-place或post-route。

如果设计没有负松弛，并且要求进行基于时间的优化选项的物理优化，则命令会在不执行优化的情况下迅速退出。为了平衡运行时和设计性能，物理优化不会自动尝试优化设计中的所有失败路径。只有前几个百分比的失败路径被考虑进行优化。因此，在设计中可以使用多次连续的物理优化来逐步减少失败路径的数量。

2.14.4 Post-Place Phys Opt Design: -directive指令说明

指令为phys_opt_design命令提供了不同的行为模式。一次只能指定一个指令，并且指令选项与其他选项不兼容。下面描述了可用的指令。

• Explore: 在多个优化过程中运行不同的算法，包括对非常高的扇出net的复制，最后一个阶段称为关键路径优化，其中物理优化的子集在【所有端点时钟的顶级关键路径】上运行，而不考虑冗余。
• ExploreWithHoldFix: 在多个优化过程中运行不同的算法，包括hold violation
  fixing和复制高扇出nets。
  技巧：Hold-Fixing只修复保持时间高于某个阈值的问题。这是因为router不可以修复任何低于阈值的保持松弛违例。
• AggressiveExplore: 类似于Explore，但有不同的优化算法和更激进的目标。
• AlternateReplication: 使用不同的算法执行关键cell复制。
• AggressiveFanoutOpt: 用不同的算法进行扇出相关的优化，目标更激进。
• AddRetime: 执行默认的phys_opt_design流程并添加寄存器重定时。
• AlternateFlowWithRetiming: 执行更积极的复制和DSP和block RAM优化，并启用寄存器重定时。
• Default: 使用默认设置运行phys_opt_design。

2.13 Routing

Vivado router在完成布局的设计上执行布线，并在完成布线的设计上执行优化以解决保持时间问题。

Vivado router从一个完成布局的设计开始，并试图路由所有的nets。它可以从未路由、部分路由或完全路由的已布局的设计开始。

对于部分路由设计，Vivado router使用现有路由作为起点，而不是从头开始。对于全路由设计，router检查是否时序违例，并尝试重新对关键部分进行布线以满足时序。

注意：重布线过程通常被称为“rip-up and re-route”。

router提供对整个设计布线或者单独的nets和pins进行布线的选项。

当对整个设计进行布线，这个过程时时序优先的，基于时序约束自动估计时间裕量。

对单独的nets和pins进行布线有两种模式：

• 交互router模式
• Auto-Delay模式

交互router模式使用快速、轻量级的时间模型以在交互式会话中获得更大的响应能力。由于估计的延迟是悲观的，因此牺牲了一些延迟精度。在此模式下，时间限制将被忽略，但有几个选择会影响布线：

• 基于资源的布线(默认)：布线器从可用的布线资源中进行选择，从而获得最快的运行时间。
• 最小延迟(-delay选项)：布线器尝试从可用布线资源中获得最小的可能延迟。
• 延迟驱动(-max_delay和-min_delay选项)：根据最大延迟、最小延迟或两者同时指定定时要求。布线器尝试以满足指定要求的延迟来对nets进行布线。

在Auto-Delay模式下，布线器运行基于时序约束的自动时间裕量计算的时序驱动过程，但与默认过程不同的是，只有指定的nets或pins被布线。这种模式用于在布线设计的其余部分之前布线关键的nets或pins。这包括setup-critical、hold-critical或两者兼有的nets或pins。在包含大量布线的设计中，自动延迟模式并不适用于单独的net。应该使用交互式路由。

当对许多单独的nets或pins进行布线时，为获得最佳结果，对这些问题分别进行优先排序和布线。这避免了对关键路径资源的争用。

布线需要一次初始化的“运行时点击”，即使在nets和pins的布线时也是如此。初始化时间随着设计的大小和器件的大小而增加。布线器不需要重新初始化，除非设计被关闭并重新打开。

2.13.5 Route Design：-directive指令说明

当对整个设计进行布线时，指令为route_design命令提供了不同的行为模式。一次只能指定一个指令。指令选项与大多数其他选项不兼容，以防止冲突的优化。以下指令可用：

• Explore: 允许布线器在初始布线之后探索不同的关键路径位置。
• NoTimingRelaxation: 防止布线器放松时序要求来完成布线。如果布线器在满足时间限制方面有困难，它就会花费更长的时间来尝试满足最初的时序约束。
• MoreGlobalIterations: 在所有阶段(而不是最后阶段)使用详细的时序分析，并运行更多的全局迭代，即使时序只提高了一点点。
• HigherDelayCost: 调整布线器的成本功能，以强调迭代的延迟，允许在运行时间上进行权衡，以获得更好的性能。
• RuntimeOptimized: 运行最少的迭代，以更低的设计性能换取更快的运行时间。
• AlternateCLBRouting: 选择需要额外运行时间但可能有助于解决布线拥塞的备选布线算法。
• Quick: 绝对的，最快的运行时间，非时间驱动，执行合规设计所需的最低要求。
• Default: 使用默认设置运行route_design。

参考文献

UG904:Vivado Design Suite User Guide: Implementation