认真check,run脚本不是新手着急的事

如果在设计初期,特别是作为新手第一次接触design compiler,急切地按下./run,自然会陷入虚妄

Fix掉所有语法和路径设置Error,悠哉地冲杯咖啡,看着服务器上快速跳动的字符,成就感陡起,仿佛自己做一颗伟大的芯片,贡献科技进步。

工具一直run到夜里9点,发条朋友圈“加班中,要好好努力!”。

实际上,今天的输出实在是不忍直视。

在之前的两篇文章,谈到设计仿真的两个阶段debugregression

仿真初期,设计和测试平台还不稳定,验证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命令

推荐阅读

  • Exceptions,数字后端设计中出现的高频词
  • 浅谈数字IC验证中的面向对象编程(抽象基类和继承)
  • 如何综合(synthesis)ASIC设计?

想了解更多内容,欢迎关注芯片数字实验室专栏,由于工具,你可以专注在更重要的事情上。