14.x PlanAhead – PlanAhead工具应用的约束似乎与我的UCF文件中的约束不匹配

描述

PlanAhead工具应用的约束似乎与我的UCF文件中的约束不匹配。

我注意到的一些事情是：

• 在MAP，PAR或BitGen期间，发出错误或警告，说明需要约束。 UCF文件包含有问题的约束。
• 发送到Synthesis和Implementation的UCF文件的大小比添加到项目的UCF文件大得多。
• 应用于对象的属性值与约束文件中传递的值不匹配。
• 当我打开Elaborated，Synthesized或Implemented设计时，我收到有关特定约束的警告或错误。但是，似乎已经应用了约束。
• 在实现我的设计时，我收到有关特定约束的警告或错误。但是，相同的UCF和设计文件在Project Navigator或ISE命令行流中成功完成。

为什么约束会改变？

PlanAhead约束系统使用什么过程来处理UCF约束？

在UCF文件中输入的通配符会发生什么？

解

当PlanAhead项目包含基于UCF的约束文件时，约束首先被读入PlanAhead工具并应用于开放式设计。

当综合运行或实现运行开始时，已读入PlanAhead工具的约束将写入运行目录中的新约束文件（例如，my_project_name / my_project_name.runs / synth_1）。

在可能的情况下，在“运行”约束文件中写入的约束将与它们来自原始约束文件中的行相关联。导致“运行”约束文件与原始约束文件不同的一些事情是：

• PlanAhead工具每行写出一个约束。 UCF格式允许使用分隔约束的管道字符将多个约束应用于一行上的单个对象。 PlanAhead工具将读取约束线并将其写入多行。
• 示例：原始UCF行：

 NET CLK_N LOC =“K22”| DIFF_TERM =“TRUE”| IOSTANDARD =“LVDS_25”; 

• 这可以通过PlanAhead工具更改为：

 NET“CLK_N”DIFF_TERM =“TRUE”; 
 NET“CLK_N”IOSTANDARD = LVDS_25; 
 NET“CLK_N”LOC = K22; 

• PlanAhead工具不会处理通配符。
• 如果约束中包含通配符，PlanAhead工具将尝试将约束应用于与通配符名称匹配的每个网络/实例。如果使用通配符表示大量网络或实例，则生成的UCF的大小可能比原始UCF大得多。
• 当在名称中间使用通配符时，PlanAhead工具将替换网络名称。例如：

 NET“my_net / module_1。*。new / last_module” 

其中NET name属性将在Synthesis过程之后替换为与前一个实例匹配的所有名称。

但是，如果名称在匹配模式的开头或结尾包含通配符，则不会发生此问题：

 NET“* my_net / module_1_new / last_module *” 

• PlanAhead工具不像ISE工具那样自由地通过对象传播约束。例如，引脚位置约束应放在I / O端口上。在ISE中，如果引脚位置约束放置在连接到驱动另一个连接到I / O端口的网络的缓冲区的网络上，则MAP能够通过缓冲区将LOC约束传播到所需的I / O端口。 PlanAhead工具不会尝试执行此传播。
• 由于某种原因（例如黑盒装或加密模块），PlanAhead工具无法找到受约束的网络或对象，并且约束将在“运行”UCF中删除。
• PlanAhead工具中的DRC检查与ISE Design Suite中的检查不匹配。例如，经常看到这个问题，位置和I / O STANDARD约束的不同排列应用于差分对I / O端口。 PlanAhead工具错误地确定某些组合无效并删除了约束。 （这些不正确的设计规则检查已修复或计划在找到时进行修复）。
• 如果不理解约束，则应将它们原样传递给“运行”UCF文件。然而，存在一些问题，即不理解的约束被简单地删除。

正如上面的几个案例中所提到的，PlanAhead工具正确识别约束的许多问题已在发现的地方得到纠正。但是，其他问题是由于与约束处理和设计数据库结构相关的PlanAhead和ISE工具之间的根本区别。在PlanAhead工具中首次使用UCF约束文件时，用户应仔细阅读约束DRC警告，严重警告和错误，并将写入运行目录的约束文件与原始约束进行比较。

如果用户想要简单地将原始UCF约束传递给实现工具而不是以图形方式查看PlanAhead工具中的约束交互（例如，查看或操纵引脚规划或设计视图中的约束），则可以删除或禁用UCF文件在活动约束集中，使用实现项目设置中的Translate （NGDBUILD）下的更多选项字段中的-uc开关直接传递给NGDBUILD。