如果在设计初期，特别是作为新手第一次接触design compiler，急切地按下./run，自然会陷入虚妄：
Fix掉所有语法和路径设置Error，悠哉地冲杯咖啡，看着服务器上快速跳动的字符，成就感陡起，仿佛自己做一颗伟大的芯片，贡献科技进步。
工具一直run到夜里9点，发条朋友圈“加班中，要好好努力！”。
实际上，今天的输出实在是不忍直视。
在之前的两篇文章，谈到设计仿真的两个阶段debug和regression。
在仿真初期，设计和测试平台还不稳定，验证flow的debug能力要比仿真性能有更高的重要性。
在设计和测试平台稳定后，进行回归测试，验证flow的仿真性能要比debug能力有更高的重要性，在发现bug之后再开启某些debug能力。
在逻辑综合flow中每个公司都有一个./run就能跑完整个综合flow脚本，Synopsys也有一个Reference Methodology脚本。
和仿真流程一样，这种高度自动化的流程也是在综合流程后期，设计文件、库文件、设置文件和约束文件稳定之后才应该使用的。
作为一个新手，重视flow中check\_*命令，也许会更有收获。
以check\_timing命令为例，其用来检查设计中的约束问题，例如
undefined clocking `undefined`
input arrival times
undefined output constraints.
约束是对工具施加的设计需求，这些未定义的约束问题就会成设计需求的忽视，从而造成潜在的时序违例。
类似狗(eda tool)遛人（designer）的感觉吧
所以，在我们对工具施加新的约束，例如clock definitions,I/O delays和timing exceptions之后，就需要使用check\_timing命令，避免工具失去方向。
做芯片，不允许我们冒着被EDA工具“遛”的风险。
Information: Checking generated_clocks...
Information: Checking loops...
Information: Checking no_input_delay...
Information: Checking unconstrained_endpoints...
…
上述log，只是check\_timing的部分信息，更多内容可以深入了解check\_timing命令
推荐阅读
想了解更多内容，欢迎关注芯片数字实验室专栏，由于工具，你可以专注在更重要的事情上。
