注：这是08年的发帖，两个工具都已经演化为IC Compiler和Encounter Design Implementation。由于Synopsys在08年推出了新的router, zroute, 所以P&R的结果要优于EDI，但是DRC的问题也多一些，如果是就floorplanning,还是EDI要好些。（这些比较参见eetop）
发信人: freelife (陪你一起老), 信区: METech
标 题: 【原创】Astro--倚天屠龙--Encounter发信站: 水木社区 (Wed Mar 26 09:15:26 2008), 站内
起个唬人的名字而已，无意挑起Synopsys和Cadence的战争，恐怕没有热闹可看。
最近看到水木MeTech上关于Astro和Encounter的讨论，回想起自己的数字后端历程，有了写个工具回忆录的冲动。我从01年开始用SE（Silicon Ensemble），02年进入Apollo，随后进入Astro，07年转投SoC Encounter，每个工具都有大规模芯片的流片经历，几个工具总体来说各有千秋和Bug。
SE是骨灰级鼻祖，把持了古老的IC时代，如今基本已寿终正寝了。但对于古老工艺下的设计，它却是唯一选择，因为工艺库对其他工具可能没有相应支持，与其绞尽脑汁去考虑库的转化，不如花点功夫学习下SE。SE菜单简单明了，已经包含了现在数字后端设计流程的绝大多数概念，但支持的工艺和规模都很有限，非EDA古玩爱好者就不要考虑了。
Apollo可以看作SE时代的终结者，虽然伴随着它官司不断，但不妨碍它成为P&R工具的历史精品。第一眼看到Apollo，你肯定会吐血，为什么？菜单选项浩如烟海，菜单下面有子菜单，选项下面有子选项，显示器小点可能会连对话框都看不全。但是Apollo的layout视图很舒服，手工操作支持的很好，Milkway Database也非常方便好用，如今也已经退出历史舞台了
Astro是Apollo的升级版，SoC Encounter可以看作是SE的取代产品，虽然IC Compiler是Astro的下一代取代产品，但目前数字后端设计工具的主流还是Astro和Encounter。至于性能孰优孰劣，两家公司都有堆成山的BenchMark说明自己牛X。我个人的使用感受是，同时期release的两个工具的速度和memory使用相差不大，即使有差异，这也不是我们IC设计者最关注的方面。芯片最终P&R结果的差异往往来自于设计本身的特点，以及工具的使用策略。
对于使用者来说，与其花精力给两个工具做比较，不如多花点时间了解设计本身的特点，掌握什么样版图能满足你的性能要求，从原理出发去调整流程和组合选项。无论Manual上说的如何天花乱坠，都不要给工具寄托太大希望，The tool is just a tool，根据需求灵活使
用是关键。EDA工具日新月异，后端工程师想不被淘汰，想随着时间增值，只能指望多掌握些原理上的东西。
对于使用者来说，与其花精力给两个工具做比较，不如多花点时间了解设计本身的特点，掌握什么样版图能满足你的性能要求，从原理出发去调整流程和组合选项。无论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更胜一筹，Encounter就必须借助ICFB了。
9）如果版图中需要手动拉线，Astro中Customer wire的命令没有Encounter的智能，不能自动识别伸缩，换层和打孔。
10）为hard block做Macro padding时，Astro能根据block的pin的多少调整padding，而Encounter没有该功能的支持，需要使用者自己脚本解决。
11）对于Hierarcical Methodology的支持，Astro/JupiterXT和Encounter相比略逊一筹，Encounter的Partition功能比较强大，而且可以自动产生block-level的工作环境和数据。
12）对于通过脚本加soft blockage, Astro可以轻松实现，而Encounter只支持图形化操作，脚本实现比较麻烦。
13）Calibre的强大有目共睹，但Astro没有提供Calibre的接口，不能读入Calibre DRC的结果，Encounter可以直接读入Calibre的运行结果。
14）对于memory的自动摆放，Encounter比Astro/JupiterXT更规则些，更利于使用者在此基础上调整。Encounter的relative floorplan很强大，对于几百个block的摆放很有效率。
15）Astro的Online DRC很少出现false violation, 而Encounter的Online DRC常常会有False Violation，容易造成误导，不利于快速检查。
16）Power network的自动synthesis, Astro/JupiterXT的结果差强人意，Encounter的template功能非常强大，当然这一功能都只能用于快速的overview，不推荐做为最终的powerplan。
17）Astro中把某个命令运行log重定向到一个文件使用”>”就可以，而Encounter很多命令不支持这种简单的重定向。
18）对于CTS的查看和debug，Astro查看和修改的工具速度比较慢，不太好使用，Encounter查看和调试时钟树比较容易些，配合Design Brower工具使用起来很方便。
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更胜一筹，Encounter就必须借助ICFB了。
9）如果版图中需要手动拉线，Astro中Customer wire的命令没有Encounter的智能，不能自动识别伸缩，换层和打孔。
10）为hard block做Macro padding时，Astro能根据block的pin的多少调整padding，而Encounter没有该功能的支持，需要使用者自己脚本解决。
11）对于Hierarcical Methodology的支持，Astro/JupiterXT和Encounter相比略逊一筹，Encounter的Partition功能比较强大，而且可以自动产生block-level的工作环境和数据。
12）对于通过脚本加soft blockage, Astro可以轻松实现，而Encounter只支持图形化操作，脚本实现比较麻烦。
13）Calibre的强大有目共睹，但Astro没有提供Calibre的接口，不能读入Calibre DRC的结果，Encounter可以直接读入Calibre的运行结果。
14）对于memory的自动摆放，Encounter比Astro/JupiterXT更规则些，更利于使用者在此基础上调整。Encounter的relative floorplan很强大，对于几百个block的摆放很有效率。
15）Astro的Online DRC很少出现false violation, 而Encounter的Online DRC常常会有False Violation，容易造成误导，不利于快速检查。
16）Power network的自动synthesis, Astro/JupiterXT的结果差强人意，Encounter的template功能非常强大，当然这一功能都只能用于快速的overview，不推荐做为最终的powerplan。
17）Astro中把某个命令运行log重定向到一个文件使用”>”就可以，而Encounter很多命令不支持这种简单的重定向。
18）对于CTS的查看和debug，Astro查看和修改的工具速度比较慢，不太好使用，Encounter查看和调试时钟树比较容易些，配合Design Brower工具使用起来很方便。
就想到这些了，以后有空再补充。当然两个工具都是Bug多多，相信各位都深有体会。
抛砖引玉，如有雷同，纯属缘份。
抛砖引玉，如有雷同，纯属缘份。