发布时间 : 星期一 文章IC设计软件和简介更新完毕开始阅读101bc7cbda38376baf1fae87
Try Route的速度是很快的，我们主要是利用它的congestion信息。它相当于SE中的Global Route。[52RD.com] 6、 RC提取。[52RD.com]
RC提取共有两种模式：default model & detail model。[52RD.com] RC提取的结果存入database后做静态时序分析（STA）。[52RD.com] 7、优化。[52RD.com]
优化的方式有三种，一般主要使用“用def或pdef物理综合进行优化”和“IPO方式优化”两种。Cadence推荐使用的是IPO优化方式。当然有时也可调用PKS工具进行物理综合优化。在做优化的时候，最好是作一次优化，就作一次Route，接着做RC提取和Timing分析。如存在问题，则需继续进行优化。[52RD.com] 8、 POWER分析。[52RD.com]
IPO优化没问题后，即可转到下步操作——对电源环进行分析。如果分析结果存在很大问题，则必须从头去做综合等。此时，可用Soc Encounter工具菜单中的“POWER EDIT”对电源进行修改。它可以用仿真结果.VCD文件来做，也可以是纯静态的。[52RD.com] 9、运行partition。[52RD.com]
运行partition的作用有二：一是优化pin的位置，二是Timing Budgets。[52RD.com]
Partition运行完毕，可实现一个真正物理层次的划分。[52RD.com] 10、对有问题的BLOCK运行IPO。（simple block timing closure）[52RD.com]
此时的网表、def（pdef）都是partition完成后生成的。[52RD.com]
11、生成CLOCK TREE。[52RD.com]
一般用CTS生成。可trace整个clock tree。[52RD.com] 12、 Timing分析。[52RD.com] 此时可能要改动constrain。[52RD.com]
13、 Detail Route。（相当与SE中的WROUTE）[52RD.com] 14、 RC提取[52RD.com]
此时不能采用default model，τ胐etail model。[52RD.com] 15、 CELTIC。[52RD.com]
可用工具CELTIC进行信号完整性分析（SI）。它也有两种方式：fast model & self model，用self model时需提供database文件。[52RD.com] 16、 CHIP ASSEMBLY。[52RD.com]
需要rulefile。做整个chip层次化的clock tree。[52RD.com] 17、 Top Level Route。[52RD.com] 用Nanoroute工具做。[52RD.com] [52RD.com]
另：Complex Block Timing Closure[52RD.com]
BLOCK model 分三种：ILM model 、TLF & STAMP model 、ECHO model。[52RD.com]
前两种是对timing的，后一种是对SI的。对复杂BLOCK的优化，是用PKS工具，根据global route的信息进行优化的，它读入的是wroute的database
Astro与SoC Encounter对比
Astro： SOC-Encounter： 起个唬人的名字而已，无意挑起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工具日新月异，后端工程师想不被淘汰，想随着时间增值，只能指望多掌握些原理上的东西。
忽悠到此为止，下面来点适合工程师口味的，稍有点技术含量的。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的摆放很有效率。