|
- UID
- 1029342
- 性别
- 男
|
多年来，电子设计自动化(EDA)工具已经变得相当成熟。目前，它们在芯片制造各方面的设计和验证中发挥着重要的作用，但设计约束(design constraint)的确认仍是其比较落后的一个领域。虽然芯片设计、功能验证、时序验证和制造已经高度自动化，但设计约束的编写和验证大部分还得依赖人工操作。
现在已经有软件可以用来管理、验证甚至创建设计约束，从而帮助设计师缩短设计周期，提高设计约束的质量。约束的改进意味着硅片可以达到更高质量，特别是在90nm及以下工艺尺寸的情况下。
约束确认的扩展之一是异常生成(exception generation)。约束管理工具可以检查网表，并发现功能故障路径。工具必须使用经过验证的形式引擎进行确认，以声明它们是故障路径。一旦被证实是故障路径，它们就可以从成本等式以及综合和实现工具的静态时序分析中去除。这样可以让优化引擎集中资源处理实际路径，有助于实现更小尺寸、更高性能和更低功耗的设计。当向更复杂的设计和更精细的几何尺寸发展时，自动化约束管理将成为主流，并引领设计自动化的新时代。为了充分利用这一功能，下面专门针对约束产生提出一些建议：
建议
• 创建的约束要覆盖设计环境的所有方面，例如所有时钟、生成的时钟、接口时序和负载能力以及诸如故障路径等时序异常等。通常约束文件是从一个项目到另一个项目这样传下来的。这样，每个约束必须匹配设计规范或新项目的系统级约束。因此，必须复查该规范，并添加遗漏的约束。
• 利用约束确认工具验证约束的正确性和质量。质量检查应包括SDC语法检查，语法上正确但存在像错误睡眠模式等问题的SDC构造，以及约束或异常的覆盖。同时，应和所有参与该项目的设计师一起去推定被工具标示的约束问题带来的影响。
• 当使用自底向上的综合和/或实现流程时，需要特别注意分层约束(hierarchical constraints)。在顶层定义的任何故障路径、案例分析、多次循环路径等也必须在模块级反映出来。设计师必须对诸如被声明为芯片级故障路径而在模块级却不是同一路径等约束不一致性进行检查。当具有时钟定义的顶层引脚在只有一条create-clock语句描述的模块端口的扇入中时还会发生另外一个常见的问题。该问题通常是遗漏set_case_analysis语句引起的。在有成百上千行SDC代码的大型设计中，这种遗漏现象很容易发生。而约束管理工具可以在相对人工方法短很多的时间内发现这种情况。
•.要注意，更改名称可导致约束文件和设计RTL或网表的失配。这些问题有一些(但不是全部)可以被综合和布局布线工具标示出来，但设计师不得不在报告文件中逐页搜索警告项。这又是一个极耗人工的过程。而目前的约束验证工具可以使这一过程自动化，并向设计师提供以彩色标示、通过或没通过规则检查的反馈信息。
• 使用不仅能阅读和创建SDC约束同时还能阅读和创建PSL断言的工具，以便架起仿真和形式约束确认之间的连接桥梁。
• 开发形式驱动的异常生成以提高硅片质量。一些工具可以从综合、实现或静态时序分析工具读取关键故障路径(CFP)来减少需要处理的时序路径数量。这叫做CFP生成。
• 考虑使用集成现有形式技术(如等效检查、低功率和时钟域验证)的工具。这样可以使其在设计团队内部更容易被采纳和学习。一些工具还提供到现有的允许自动脚本生成和交叉检测分析的实现工具的链接。
不建议
• 在创建诸如错误路径等时序异常时使用带通配符的松散条件。通配符在扩展时可能会导致综合和实现工具的速度极其缓慢。能够屏蔽真正功能路径的通配符将会造成意料之外的故障路径。由于这些路径在设计过程中没有被考虑到，在设计流片前问题不会暴露出来，因此有可能导致成本高昂的重新流片。而约束管理工具可以扩展和通过形式确认由通配符造成的异常。
• 低估对已验证的形式引擎的需求。必须经过形式校验的确认才允许综合或实现工具从成本等式中删除生成的故障路径。“黄金约束”或许只是对设计规范的快速解释。
•. 试图在报告文件的上千行代码中查找约束警告。因为现代约束管理工具已能提供完善的图形化环境来识别约束问题，并提供反例(当确认失败时)和简便的调试功能。
• 在重复或重叠约束的情况下，假想最后一次应用是正确的。要与设计师或系统架构师一起进行检查并找出真实的意图。约束管理工具可以标示出冲突，但只有用户自己才能核实哪条语句反映了芯片或环境的目标行为。在有疑问时，一定要仔细检查! |
|
