原创 转认识的一个高手写的，65nm以下工艺注意事项

原文网址：http://bbs.eetop.cn/viewthread.php?tid=267120&highlight=65nm

非常感谢高手的jiancongwoo的分享

今天开这个话题，我会把需要注意的东西慢慢填上。
1. 后端工具的选择
  这个话题不帮任何一家EDA公司说话。
  现在用得最多的PR工具应该是 Encounter或者ICC，那么这两个工具在65nm以下的工艺上，哪家做得更好呢？
Encounter，现在最新的版本是9.1.XXX
ICC应该是 2010.03-SPXX
在2008年以前，应该来说Encounter做得比ICC好，Routing的质量比ICC好，在2009年以后，应该来说ICC做得比Encounter好。这里主要是指Placement， CTS，和Routing。
比如在40nm的Design中，ICC可以把线route得最短，Via的数目比Encounter做的要少。在同样的Via的数目时，ICC的Zroute用得DFM的Via比Encounter多，Jog的数目也少。这就是说ICC的Zroute在做DFM的时候比NanoRoute 有优势。
Icc vs. Encounter也有缺点，在Routing上，同一个Design，在DRC问题非常严重的时候，Encounter做Routing的时候会Route不出来，但是Icc能Routing出来，Routing出来的结果是爆多Short！！！！！
Cadence的Encounter能否赶上来，就看Cadence的了。

做Floorplan，这个嘛，ICC就Out了，反正我可不喜欢用ICC来做Floorplan，用Encounter做Floorplan，不管是Block或者是Fullchip比ICC好用。

在利用Inhouse的Scripts来做设计的时候，这个时候Encounter完全胜出，因为Encounter的那些db命令比ＩＣＣ好用多了。

关于做优化，　Encounter可以说是Out了。ICC在Placement， CTS，或者Routing的优化上应该来说都比Encounter做得好，毕竟ICC看到的Timing与从Pt看到的Timing，差别不是很大。

2. STA分析，分析的Corner的选择
    在65nm的时候开始出现了温度反转的问题。在65nm以上的工艺的时候，应该说是在同一个电压下面，高温跑得慢，低温跑得快，而在65nm的时候就出现了，高温跑的快，低温跑得慢的问题。
  以TSMC65nm的工艺为例：
  就Library来说
有TT 1.1V, SS 0.99V, FF1.21V
对于RC来说有
cworst rcworst typrc rcbest cbest这几个模型，
那么分析Setup跟Hold应该在那个下面分析呢？
最直接的那么就是在最糟糕的那个点跑Setup，然后呢最快的那个点跑Hold,这个做法不能说她是错的，但是也可以说不是很科学。

从数学统计的角度来说， 同一个批次的芯片，在生产出来后，跑得快，跑得慢，跟跑得正常的Die，在数学上应该满足正态分布。就是说大部分的芯片都是跑在TT这个Corener的，跑在FF跟跑在ＳＳ的毕竟是少数。
那么说，在设计芯片的时候，Designeer就应该在SS，FF，TT定义出3套SDC。
那么在SS，TT，FF，那个Check Setup，那个是Hold呢。
如果你不知道哦啊，那么就用组合数学的方法来做。
Library的Corner+ 不同的RC值来做，来分析结果。
比如在SS Corner下的Cworst这个Corner呢，我同时分析cwost cbest，发现在125C的时候， cworst的SetupViolation最多，那么就应该把这个Corner定义成Check Setup的主要Corner。
同理其他的也是这么分析。
一般来说在Function mode下，会在SS下check　setup&Hold， TT check Setup , FF  Check Hold。
在Scan Mode下，一般就是在TT下面Check Setup & Hold。 应为跑Scan的时候，没有变态到把芯片加热后在来测试。如果有人这么干，可以把这个人炒了 。因为有点“二”


3. RC corelation
这个问题，可能大部分人都没有去考虑过。
问大家一个问题，EDA抽取到的RC参数跟真实的值对比，误差是多少？ 抽到的RC参数是不真实的值乐观，还是悲观呢？
大家比较常用的RC抽取的工具有Synopsys的StarRC跟 Cadence公司的QRC。
这两个工具抽取RC的参数的原理基本差不多，一个用2.5D来抽取，1个用3D的来抽取。似乎Cadence的QRC抽取到底参数更加准确。
古语有云“过犹不及”。
实际上QRC抽到的RC参数跟真实的值相比，QRC抽到的参数更加悲观，意思是它抽到的参数“过”了。、
而StarRC抽到的参数是不“及”。

那么这里我有一个问题问大家，现在我就用StarRC的抽到的RC参数用PrimeTime来分析Timing，应该如何解决？？？

大家都该知道，抽取RC参数，是一个比较费时间的过程。那么对一个比较大的Design，做RC参数的提取，RunTime你们有要求吗？
QRC抽取慢，
StarRC抽取参数快一点。
如果让你们选择这个过程的EDA工具，你们会怎么去选择？

4. DFM
   这个问题是一个比较大的问题。
   第一个Metel的密度，这个问题就很简单了。大家都知道。 如果Metel的密度没有达到一定程度，在做CMP的时候，会打磨得不够平整，或者说Densitiy底的地方，打磨得正好了，Density高度地方 Metal就别磨没了。 所以每一次的Metal 密度有有一定的要求，在Routing完之后+Metal Fill 来把Metal密度增加上去，可以利用Calibre来Check每一层的Metal 密度。
第二,DFM Via 这个不说了，让工具去做吧。
第三, Fix CAA，通过spread wire来搞定。
弟四， 在GDS交付给Fouandary之后，其实还有文章可以做。对于Via Enclouse的Metal少的Via，可以在不违反DRC 规则上，可以增加Enclose的Metal，在Deck上做修改，这个是很有好处的，可以增加Yield。缺点是会影响到Timing。

OPC, 这个是跟光刻相关的东西，由于线宽越来越窄，Metal之间的距离约来越小， 本来两个没有连接关系的Metal就会链接上，或者有一根金属本来是连接上的，在被另外一个金属的影响下，就会断开。


TSMC定义了LPC(litho pattern correction,是不是这么叫有点忘记了) Hot-spot，从level -1 ~level -2.2, 在定义中level-1(necking & bridging) 的Hot-spot是致命的，一定要Fix掉，而level-2.1 ~level-2.3的可修可不修。 分析这种Hot-spot的过程叫CAA（Critical Area analysis)。
OPC(光学近似矫正)，这个是考虑Lithto到影响下，Fix掉Litho引起的Routing的问题，Encounter在Routing中可以做这个东西，开启这个功能后，直接的结果是Runtime & Timing都变烂了。事实上如果两个比较靠近的Net，如果它们之间的距离够宽，Level-1的Hot-spot就会不存在了，也就是说，这个问题完全可以在Routing Rule中把这个问题解决掉。事实上我们在一个65nm一下工艺的一个项目中压根就没有考虑OPC到问题，估计OPC问题Foundary已经解决了，是在Tech File定义这种Routing的Rule吧。对于这点，我不是很sure，希望有高手来解决一下这个疑问！！！


用来Check LPC问题的EDA工具是Cadence的PVS（具体名称忘记了，这个工具就是inshape，被Cadence买来了。）， Synopsys的工具叫primeYield-LPC. 还有有一个叫PrimeYield-CMP,这个下面会提到。

CMP的问题，每一层的金属的密度要达到一定的值，但是多大的值才是合适的呢？ 这个Foundary有提供，一般来说每一层金属在CMP之后跟标准的厚度比较，在300埃之内都是可以的，即+- 300埃。  在这里提一个问题，Metal厚度变化了，那么抽出来的RC也会变化，在这里的时候TIming该怎么去做。



20.10.2010添加
对于DFM设计来说，Routing是非常重要的，那么在跟Routing相关的DFM中，DFM做得好的评判标准是什么呢？
? Total Wire Length  -->要短
? Via Count  -->要少
? Number of Single Via -->要少
? Redundant Via Rate -->要多
? Wire Spreading --》Wire之间的距离要大
? Via Enclosure  --》要大
? Jog Count --》 要少
?
以上的几点是人脑+EDA tool才能做出来的。怎么做呢，看EDA Tools的userguide去， 可以提到的是能目前Routing做得最好的Routing工具是ICC Zroute，而且是2010.03以后的版本。 NanoRoute目前暂时落后，啥时候能赶上来，就看Cadence的了。


Calibre DRC+
DRC+是比DRC更加严格的Rule，这个要做吗？？大家考虑一下。

YRC
这个不要做


OCV vs AOCV
Pt能够利用Graph-Based和path-based的方法来分析Timing，较于后者，前者分析的方法更保守些，基本上大部分人分析TIming都是用Graph-Based的方法来Analsys timing.

OCV是利用统计学的原理得来的，OCV在Corver Lonth Timing Path 的变化的时候是比较好的，但是对于短的Path，还有些不足,那么是否有一种能够根据Path的长短来+ocv的方法呢？有点，AOCV就是这样子的一种方法。
AOCV有2种方式来考虑OCV到问题，一个是一句Path Level来+OCV, 另外一个是根据Distance来分析的, 依据Path level来+ocv，这个应该很好理解，下面就是有这么AOCV的File
==========================================
version: 1.0
object_type:            design
rf_type:                rise fall
delay_type:             net cell
derate_type:            late
object_spec:
depth:  1       2       3       5       7       9       19
distance:       500
table:  1.0632  1.0476  1.0405  1.0348  1.0314  1.0293  1.0264
===========================================

而对于用基于Path Location的来说，就要查2D的表格了。
====================================
version 1.0
object_type: design
rf_type: rise fall
delay_type: cell net
derate_type: early
object_spec: top
depth: 0 1 2 3
distance: 100 200
table: 0.87 0.93 0.95 0.96 \
         0.83 0.85 0.87 0.90
======================
200 |  0.87| 0.93| 0.95| 0.96
--------------------------------
100 | 0.83 |0.85 |0.87 |0.90
-----------------------------------
       |0      |1      |2     | 3

为了得到Location，就要让StarRC Dump出 每个Cell的Location，然后再Pt中，都SPEF或者ＳＢＰＦ的时候把Location load进去。
这样子就有一个问题了，为得到Location，StarRC Dump SPEF的速度变慢了，同时Pt在Load SPEF的时候也变慢了。然后Pt要根据这些Location，计算Net的长度，不停的进行计算。试问一下这样子的结果大家是否想要呢？ 事实上Location Base 的方法分析出来的值跟path level分析出来值没有什么差别。

在利用path level based的方法分析Timing的时候，这个东西是用在Clock上呢，还是用在 data path上呢？ 这个问题大家可以考虑考虑，或者有那个条件，可以试试，自己跑一下Timing分析，一切就知道啦。。。。。。。。。。。。。。。