EDA工具的比较.doc

EDA后端工具比较 最近部门一直在考虑关于后端工具的选择，大半年了，synopsys和cadence两家的技术支持不停的来做技术讲座，都说自家的工具好。 最近一周，cadence的售前又来做技术讲座，顺便再次分析了自家软件的好处，使得我开始对synopsys的工具有点怀疑了。 好在今天终于看到了一片不错的文章，详细、客观的分析了2家公司的后端工具优劣，因此转贴到这里，以备参考。 起个唬人的名字而已，无意挑起Synopsys和Cadence的战争，恐怕没有热闹可看。 最近看到水木MeTech上关于Astro和Encounter的讨论，回想起自己的数字后端历程，有了写个工具回忆录的冲动。我从01年开始用SE（Silicon Ensemble），02年进入Apollo，随后进入Astro，07年转投SoC Encounter，每个工具都有大规模芯片的流片经历，几个工具总体来说各有千秋和Bug。 SE是骨灰级鼻祖，把持了古老的IC时代，如今基本已寿终正寝了。但对于古老工艺下的设计，它却是唯一选择，因为工艺库对其他工具可能没有相应支 持，与其绞尽脑汁去考虑库的转化，不如花点功夫学习下SE。SE菜单简单明了，已经包含了现在数字后端设计流程的绝大多数概念，但支持的工艺和规 模都很有限，非EDA古玩爱好者就不要考虑了。 Apollo可以看作SE时代的终结者，虽然伴随着它官司不断，但不妨碍它成为PR工具的历史精品。第一眼看到Apollo，你肯定会吐血，为什么？菜单选 项浩如烟海，菜单下面有子菜单，选项下面有子选项，显示器小点可能会连对话框都看不全。但是Apollo的layout视图很舒服，手工操作支持的很好， Milkway Database也非常方便好用，如今也已经退出历史舞台了 Astro是Apollo的升级版，SoC Encounter可以看作是SE的取代产品，虽然IC Compiler是Astro的下一代取代产品，但目前数字后端设计工具的主流还是 Astro和Encounter。至于性能孰优孰劣，两家公司都有堆成山的BenchMark说明自己牛X。我个人的使用感受是，同时期release的两个工具的速度和 memory使用相差不大，即使有差异，这也不是我们IC设计者最关注的方面。芯片最终PR结果的差异往往来自于设计本身的特点，以及工具的使用策略 。对于使用者来说，与其花精力给两个工具做比较，不如多花点时间了解设计本身的特点，掌握什么样版图能满足你的性能要求，从原理出发去调整流 程和组合选项。无论Manual上说的如何天花乱坠，都不要给工具寄托太大希望，The tool is just a tool，根据需求灵活使用是关键。EDA工具日新月 异，后端工程师想不被淘汰，想随着时间增值，只能指望多掌握些原理上的东西。 忽悠到此为止，下面来点适合工程师口味的，稍有点技术含量的。Astro和Encounter推荐的设计流程基本一致，所以两者之间的迁移不会很困难，那就 简单介绍下Astro和Encounter在使用上的差别比较。 1）Astro使用的database是Milkway，是二进制格式的，而Encounter的数据格式是ASCII的。所以Astro的文件size小，利于拷贝移动，而Encounter支 持在数据库中直接修改文件，方便更新和操作，但是文件size大，移动和复制时可能造成某些相对路径指向的文件丢失。 2）Astro一个进程可以打开多个cell，命令行不占用Terminal，而Encounter一个进程只能打开一个cell，命令行占用Terminal。 3）Astro在timing分析时不能直接调用PT等signoff工具，而Encounter使用分析时-signoff选项就能自动调用signoff的STA和其他工具。 4）如果想Fill poly，Astro中可以直接加dummy poly，而Encounter工具本身只能支持到Metal 1的fill，不支持poly的fill，需要自己想办法解决。 5）Placement之后，CTS之后，routing之后的工具参数都会有些变化，Astro大多数需要自己设置，而Encounter通过-preCTS, -postCTS, -postRouting可以自动配置。 6）为了LVS加IO text时，Astro有命令可以很方便的加，而Encounter必须自己想办法。 7）在设计早期加入metal fill对timing和设计的影响，Astro中没有方便的选项设置，而Encounter在从一直开始就能设置。 8）Astro能读入GDS，支持CEL view，Encounter不支持读入GDS，所以在Encounter中永远无法看到真正的版图，所以对于手动fix DRC，Astro