设计约束验证和确认的全新典範

多年来，电子设计自动化(EDA)工具已经变得相当成熟。它们在晶片製造各方面的设计和验证中发挥重要的作用。但目前仍然落后的领域是设计约束的确认。虽然晶片设计、功能验证、时序验证和製造已经高度自动化，但设计约束的编写和验证大部份还是繁複的人工作业。

目前，已经有软体可用来管理、验证甚至製作设计约束，协助设计师缩短设计週期，提高设计约束的品质。约束的改进意味着更高品质的硅晶片，特别是在90nm及更小的几何製程中(图1)。

约束确认的扩展之一是例外的产生。约束管理工具可以检查网表，并发现功能故障路径。工具必须用经验证的形式引擎确定这些路径，以证明这些路径可以被声明为故障路径。一旦这些路径被证实是故障路径，它们就可以从成本等式以及合成和实现工具的静态时序分析中去除。这样可以让最佳化引擎集中资源处理实际路径，带来更小、更快的设计。

当向更複杂的设计和更精细的几何尺寸发展时，自动化约束管理将成为主流，并引导设计自动化的新时代。为了充分利用这一功能，本文针对约束产生提出了一些建议。

图：今天的约束管理工具可对设计流程的所有阶段确认并产生约束。

建议的方法

‧製作的约束要覆盖设计环境的所有方面，如所有时脉、产生的时脉、介面时序和负载能力，以及像故障路径等时序例外等。通常约束文件是一个专案一个专案传下来的。如果确实是这种情况，每个约束必须匹配设计规格或新专案的系统级约束。该规格也必须被检查，并补充任何遗漏的约束。

‧利用约束确认工具验证约束的正确性和品质。品质检查应包括SDC语法检查、语法上正确但存在如错误睡眠模式等问题的SDC构造，以及约束或例外的重叠。与参与该专案的所有设计师共同了解被工具标示出来的任何约束问题，及其所带来的影响。

‧当使用自底向上的合成和/或实现流程时，需特别注意层次性约束。在顶层定义的任何故障路径、案例分析、多次迴圈路径等也必须在模组级反映出来。设计师必须对诸如同一路径在晶片级声明为故障路径但在模组级不是故障路径等约束检查其一致性。当具有时脉定义的顶层接脚，在只有一条create-clock语句描述之模组埠的扇入中还会产生另一个常见的问题。该问题通常是遗漏set_case_analysis语句引起的。在有上百甚至上千行SDC程式码的大型设计中，这种遗漏现象很容易发生。相对于手动方法，约束管理工具可以在很短的时间内发现这种问题。

‧了解名称更改可能导致约束文件和设计RTL或网表的失配。这些问题有一些(但不是全部)可以被合成和布局布线工具标示出来，但设计师不得不在报告文件中逐页搜索警告条目。这又是一项极耗人工的过程。而目前的约束验证工具可以使这一过程自动化，并向设计师提供彩色标注、通过或没通过等规则检查的反馈资讯。

‧使用除了能阅读和製作SDC约束外还能阅读和製作PSL声明的工具，以便架构模拟和形式约束确认之间的连桥接樑。

‧开发形式驱动的例外产生工具以提高硅晶片品质。一些工具可以从合成、实现或静态时序分析工具读取关键故障路径，以减少需要处理的时序路径数量。这称为关键故障路径(CFP)产生。

‧考虑使用与现有形式技术(如等效性检查、低功率和时脉域验证)整合的工具。这将使採纳和学习在设计团队中变得更容易。一些工具还提供到现有实现工具的链结，允许自动脚本产生和交叉检测分析。

不建议的方法

‧在製作如错误路径等时序例外时使用具有万用字元的鬆散条件。万用字元在展开时可能导致合成和实现工具速度极其缓慢。由万用字元设立的意外故障路径可能遮蔽真正的功能路径。由于这些路径在设计过程中没有被考虑到，在设计投片前问题不会暴露出来，因此有可能导致成本高昂的重新投片。约束管理工具可对万用字元产生的例外进行扩展和形式确认。

‧低估对已验证的形式引擎需求。产生的故障路径在允许合成或实现工具从成本等式中删除之前，必须被形式验证工具确认。‘黄金约束’可能只是对设计规格的快速解释。

‧费力地在报告文件的上千行程式码中查找约束警告。现代约束管理工具提供了成熟的图形化环境来识别约束问题，并提供反例(当确认失败时)和方便的除错功能。

‧在重複或重叠约束情况下，假设最后一次应用是正确的。要与设计师或系统架构师一起进行检查并找出真实的意图。约束管理工具可以标示出冲突，但只有靠用户自己才能验证哪条语句反映了晶片或环境的目标行为。在有疑问时，一定要仔细检查！