vivado 创建实施约束
创建实施约束
在您有了一个合成的网表之后，您可以将它与XDC文件一起加载到内存中，或者Tcl脚本已启用以进行实现。当加载XDC以便验证和更正任何不能应用的约束。在某些情况下，合成网表中的对象名称与精心设计。如果是这种情况，则必须使用更正的名称，并将它们保存在仅实现的XDC文件中。在该工具能够正确加载所有XDC文件后，您可以运行时序分析，以便：
•添加缺失的约束，如输入和输出延迟。
•添加定时例外，如假路径、多周期路径和最小/最大延迟限制。
•识别由于设计中的长路径而导致的大型违规行为，并更正RTL描述。
您可以使用与合成期间相同的基本约束，并创建第二个XDC文件来存储所有特定于实施的新约束。您可以选择保存物理和配置单独的XDC文件中的约束。基于网表的XDC迭代如图45所示。
约束和对象查询
包含基于某些物理信息的对象查询的设计约束决不能依赖取决于Vivado P&R命令输入的物理约束，并且仅依赖于物理约束否则当重新加载实现后DCP时，这些约束将显得无效。此要求来自于网表所在的DCP加载序列先读取，然后读取约束和物理数据库。代替使用物理信息，您应该修改查询以依赖于其他设计对象属性（NAME，REF_NAME，…）。
依赖于放置信息的非推荐约束示例（特性LOC）：
set_false_path-来自[get_cells-quiet-hier-filter｛REF_NAME=~FD*&&LOC=~BLI_*}]
调整合成逻辑复制的约束
在合成过程中，一些寄存器被复制以提高设计性能。用户XDC约束不被合成引擎修改为包括复制的细胞。如果时间约束附加到Vivado Synthesis复制的对象，复制的单元格为并不总是被XDC约束所覆盖，这取决于约束的编写方式以后可能会影响结果的执行质量。使用Vivado Synthesis时，get_cells和get_pins命令提供了一种机制以自动包括复制的对象。例如，set_false_path–from[get_cells–hierarchy*rx_reg]可以是重写如下，以便在实现过程中也安全地包括复制的对象：
命令行选项-includereplicated_objects依赖于属性在已复制对象上设置的ORIG_CELL_NAME。以下查询命令返回具有复制细胞的原始细胞：
get_cells-includereplicated_objects*rx_reg
get_cells-includereplicated_objects[get_cells-hier-filter｛NAME=~*rx_reg}]
get_cells-层次结构-筛选器｛NAME=~*rx_reg||ORIG_CELL_NAME=~*rx_reg}
-filter选项始终在生成对象集合之后应用。不建议使用当筛选表达式引用-includereplicated_objects时，使用-filter到属性NAME。在这种情况下，复制的对象在返回时不会返回与为NAME指定的模式不匹配。例如，以下语法不返回与*reg_replica*匹配的已复制对象：
get_cells-includereplicated_objects-filter｛NAME=~*rx_reg｝
AMD建议运行方法检查（report_Methodology）并审查XDCV-1和XDCV-2检查消息。
在继续实施之前，您必须验证您的设计不包括任何重大时间违规。位置和路线工具可以修复最合理的时间冲突，但是它们无法解决使定时关闭不可能的基本设计问题。
使用黑匣子调整合成约束
当使用上下文外（OOC）合成模式时，OOC模块（IP/BD/DFx/…）为推断为顶层内部的一个黑框。这意味着OOC内部的网表对象顶级约束无法访问模块。这可能需要顶级用于合成的约束与用于实现的约束不同。在项目中模式下，这可以通过创建用于合成的特定XDC文件并设置属性来完成
USED_IN_SYNTHESIS=TRUE&USED_IN_IMPLEMENTATION=FALSE。顶级XDC实现的USED_IN_SYNTHESIS应为FALSE。从黑匣子中可以访问的唯一对象是输入和输出端口。这限制了顶层在引用黑框时可以指定的时间约束类型。OOC综合的顶级约束的一些限制是：
•OOC模块内部生成的自动派生时钟不能重命名。
•OOC模块内部定义的时钟名称不能被引用。传播到的时钟
OOC模块的输出是基于连接到的端口的网络命名的模块，而不是根据模块内部的名称，即使时钟在模块XDC。
•如果顶层约束需要指OOC模块输出的时钟，则应使用诸如'get_clocks-of_objects[get_pins之类的查询<MODULE_oc_OUTPUT_CLOCK_PORT>]'。