目录
implementation 过程把一个【逻辑网表(logical netlist)和约束(constraints)】转换为一个【完成布局(place)和布线(route)的设计】。
1 综合前的准备
Vivado高层次设计流程:
Markdown将文本转换为 HTML。
1.1 Vivado Implementation 子过程
Opt Design
:优化逻辑设计,使其更容易适合目标Xilinx器件。Power Opt Design(可选)
:优化设计元素,以降低目标Xilinx器件的功率需求。Place Design
:将设计完成在目标Xilinx器件上的布局。Post-Place Power Opt Design (可选)
:额外的优化,以减少布局后的功率。Post-Place Phys Opt Design(可选)
:基于位置估计时序用于优化逻辑和布局,包括复制具有高扇出的驱动以减少扇出。Route Design
:完成目标设计在对应器件上的布线。Post-Route Phys Opt Design(可选)
:用实际的线路延迟来优化逻辑、布局以及布线。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 逻辑优化约束
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