缩小半导体工艺尺寸能走多远?

特约撰稿 莫大康 推动半导体业进步有两个轮子，一个是工艺尺寸缩小，另一个是硅片直径增大，而且总是尺寸缩小为先。由半导体工艺路线图看，2013年应该进入14纳米节点，观察近期的报道，似乎已无异议，而且仍是英特尔挑起大樑。尽管摩尔定律快“寿终正寝”的声音已不容置辩，但是14nm的步伐仍按期走来，原因究竟是什么? 传统光刻技术与日俱进 当尺寸缩小到22/20nm时，传统的光刻技术已无能力，必须采用辅助的两次图形曝光技术。 提高光刻的分辨率有3个途径：缩短曝光波长、增大镜头数值孔径NA以及减少k1。显然，缩短波长是最主要的，而且方便易行。目前市场的193nmArF光源是首选，再加入浸液式技术等，实际上达到了28nm，几乎已是极限(需要OPC等技术的帮助)。 所以Fabless公司NVIDIA的CEO黄仁勋多次呼吁工艺制程在22/20nm时的成本一定相比28nm高。其理由是当工艺尺寸缩小到22/20nm时，传统的光刻技术已无能为力，必须采用辅助的两次图形曝光技术(DP)。从原理上讲，DP技术易于理解，甚至可以3次，或者4次。但是这样带来两个大问题，一个是光刻加掩模的成本迅速上升，另一个是工艺的循环周期延长。所以业界心知肚明，在下一代光刻技术EUV尚未到来之际，采用DP是不得已而为之，实际上在技术上的可行性并不是问题，更多的是要从经济层面做出取舍的决定。 193nm光刻技术在计算的光刻技术辅助下，包含两项关键的创新，一个是同时带OPC(光学图形修正)的两次图形曝光技术，另一个是采用一种倒转的光刻技术来改善困难的布局复制，可以在局部区域达到最佳化。 因此可以相信，传统的193nm浸液式光刻技术加上两次图形曝光技术(DP)，甚至4次，从分辨率上在2015年时有可能达到10nm，这取决于业界对于成本上升等的容忍度。 7nm还是5nm 除了工艺尺寸缩小之外，产业尚有多条路可供选择，如450mm硅片、TSV 3D封装等。 何时能够达到7nm或者5nm，截至今日尚无人能够回答，因为EUV何时进入也不清楚。乐观的估计可能在2015年或2016年。如果真能如愿，可能从10nm开始就采用EUV技术，一直走到5nm。但是目前业界比较谨慎，通俗一点的说法仍是两条腿走路。在今年的Semicon West上各厂家的反应也是如此。Nikon正努力延伸193nm的浸液式技术，甚至包含450mm硅片而ASML由于获得英特尔、三星及台积电的支持，正加快NXE 3300B实用机型的发货。 据说已经有6台NXE 3100 EUV设备在客户处使用，累积产出硅片已达44000片。另外，下一代EUV设备NXE 3300B已开始安装调试，计划2013年共发货5台，另有11台NXE 3300B的订单在手及7台订单在讨论中。 ASML正在准备450mm光刻机，它是客户共同投资计划中的一部分。公司有信心将3台EUV的营收落实在2013年的销售额之中。 ASML在2013年展览会的演讲中详细描绘了业界期待已久的EUV光源路线图，近期Cymer公司已推出了专为ASML光刻机配置的40W极紫外(EUV)光源，工作周期高达每小时30片，并计划在2014年时NXE 3300B中的光源升级达到50W，相当于43WPH水平。而100W光源可能要等到2015年或2016年，相当于73WPH。至于何时出现250W EUV光源，至少目前无法预测，除非等到100W光源成功，并有出彩的表现。500W光源写进路线图中是容易的，但是未来能否实现还是个问题。 只要实现73WPH，可以认为EUVL已达到量产水平，因为与多次曝光技术相比，它的成本在下降。在10nm节点以下如果继续釆用MP多次曝光技术，则可能需要4x甚至8x的图形成像技术。 因为从理论上讲，硅晶格大小约0.5nm，通常大于10个晶格尺寸，即约5nm时，才可能有好的硅器件功能，所以可以认为5nm是工艺尺寸的最终极限。预测在2024年以后半导体产业可能发生革命性变化，电荷不再是传输信息的唯一载体，同时计算架构也可能发生革命。 另外，ASML、IMEC及Applied Materials等共同协作，认为采用EUV技术有可能达到小于7nm，由于EUV技术同样也可采用DP两次图形曝光技术来提高分辨率。 随着半导体产业的继续发展，之后的每一个工艺节点进步都要付出极大的代价，要求达到财务平衡的芯片产出数量巨大。现在市场上已很难找出几种能相容的产品，因此未来产业面临的经济层面压力会越来越大。然而除了尺寸缩小之外，产业尚有多条路可供选择，如450mm硅片、TSV 3D封装，FinFET结构与III-V族作沟道材料等，此外还有应用商店。而站在客户立场，他们并非知道芯片的内部构造，仅是需要价廉、实用，而又方便使用的电子终端产品。

首先声明，是zz的，我对原文的观点是：分布式系统的规范不是那么容易搞出来的。所以OPC-DA暂时是不可替代的，OPC-XMLDA是跨防火墙的新技术，但是实时性差一点。这篇文章的出处是另一篇批评opc的文章的评论。（原文的链接是http://blog.cechinamag.com/sup_zoux/9284/message.aspx#3648，被评论的文章标题是OPC——资本和崇洋豢养的病态协议）zz文章如下：

楼主似乎对OPC相当的熟悉，但似乎又不是很懂OPC。

首先OPC是一种协议，OPC协议里只是定义了接口，OPC的不好是由于他建立在了DCOM的基础之上，大多数的诟病来源于DCOM本身而不是OPC协议本身，至少这篇文章对OPC的不满也几乎都来源于DCOM。那么楼主更应该骂微软，或是OPC基金会妥协与微软，而不是OPC协议本身。楼主是希望把OPC协议制定成为像modbus之类的协议，还是提出要建立一套分布式框架替代DCOM呢。这两者完全不是一个层面上的东西。如果是前者，我劝楼主应该站在更高的层次上，而不是盲目的准备去做无用功，如果是后者本人倒是颇感兴趣，本人才疏学浅，分布式框架只知道DCOM 、Cobra 、JMI、.Net Remoting、SOAP。其中JMI和.Net Remoting目前还是依赖于平台，而Cobra则是看起来很美，SOAP像是以后的发展方向，目前OPC 3.0协议已经是基于SOAP的了，性能问题导致他还不能大规模推广。

第二，OPC协议存在也有不少年头了，站在现在的观点对一个陈旧的东西妄加批评似乎有点过分和小肚鸡肠。就像我们不能现在说DDE是一种多么简陋的IPC技术啊，毕竟他是一个时代的产物，在OPC产生的年代，windows上的主流技术难道不是DCOM吗，除非一开始就脱离微软。

第三，“资本和崇洋豢养”这个词显得楼主太过于愤青，如果说用OPC就是“资本和崇洋豢养”，那么我们绝大多数用电脑的人都是“资本和崇洋豢养”，因为我们用的windows、linux、unix、solaris都是洋人给我们的，假如有一天真的有一种真正好的替代OPC的协议产生我第一个支持，如果目前还没有出来，还是希望楼主遵循“多谈些问题，少谈些主义”的原则，真正的能够为中国的自动化协议做些贡献。

最后送给楼主一句话，“师夷长技以治夷”，治夷之前是师夷而不是鄙夷

原文如下：

OPC——资本和崇洋豢养的病态协议

虽然目前大部分的厂商均支持OPC协议，并将其视为开放的标准。我曾长期从事实时数据库研发，并对OPC协议有深入研究。到目前为止，除了悲哀，只有一席不得不说的话。OPC真的很先进么？对于过去还一直靠编写串口协议研发非标产品的一些同仁来说，似乎刚刚感受到其带来的优点，为了接项目而编写一些OPC接口等等，也许感觉其神秘而高不可攀。其实，OPC就是基于微软DCOM技术的一套接口定义而已，在其设计的时候并没有考虑诸多工控必须的硬件条件因素，仅仅是将微软DCOM技术原封不动地搬到了工控领域而已。这几年，每年都有一些同仁公司联系SUPCON SOFT，希望能够获得解决OPC接口的问题，作为OPC基金会的首批会员和国内OPC基金会的倡导者，SUPCON对OPC十分了解，拥有大量可以开发OPC接口的程序员。但这并不意味着SUPCON会承接这些接口问题的服务。作为一个企业，其专业性在于提供自己专业的产品和核心价值所在的服务，而非其它。但这也从另一个侧面看出国人对OPC接口的误解和盲从。OPC真的很美么？从其应用至今，OPC带来的痛大过其带来的利益。DCOM是一套依赖微软技术极深的服务，仅一个OPC,就限制了目前工控领域 *** 作系统的多样性。这也没什么，如果处于爱国，中国还真没有可圈可点的 *** 作系统。但OPC的问题是在太多了：

※安全性配置复杂：对于对 *** 作系统并不专业的工控人员，OPC的安全性配置已经过于专业和复杂了。这导致了好多实例中，OPC都不是通过系统启动后自激活的，而是需要有交互式用户去登录，这给系统带来了极大的不安全性。即每次系统重启都可能需要人为干预。虽然经过合理的DCOM配置可以避免，但不幸的是大部分工控从业同仁对此并不掌握；

※远程激活困难：如果两台计算机不再一个带有强烈微软技术特色的“域”里的时候，远程激活OPC就是一个噩梦，在很多项目上，仅这个配置就另很多工程人员痛心疾首。知道大部分项目中不同域之间的激活是怎么做到的吗？呵呵，好多同仁选择了两台机器通过相同的用户名和密码登录来破坏安全性；另一些掌握一些编程技术的同仁则通过在一台计算机中保存另一台计算机的用户名和密码；这些安全因患之所以不能排除，原因就是该死的OPC协议，这个吸附在微软的DCOM技术上的毒瘤；

※开发复杂：虽然笔者对DCOM技术掌握得较为熟练，但至今还能回忆起年轻时学习DCOM编程的黑暗日子，DCOM是一种经过一段时间痛苦，然后顿悟，发现原来所有写DCOM教材的人都在故弄玄虚，人为增加复杂度。同时,DCOM的内存管理和调用技术，往往需要较多经验，使本来容易的通讯开发，变得焦灼不堪。所以才有目前很多业界同仁委托其它公司开发OPC接口的事情；

※跨平台困难：连跨微软的多个 *** 作系统，都会有些小问题，能在Linux和UNIX上使用OPC的人，更是寥寥；我至今只是闻名，未尝亲见这类高人；

那么为什么这么一个诟病甚多的协议会成为今天普遍接的标准呢？原因有二，一是时机，二是资本。当工业以太网时代还出于鸿蒙初开，各大自动化厂商还在为未来的总线争论得喋喋不休得时候，微软，这个 *** 作系统的厂商，利用一种基于自己 *** 作系统的分布式技术，在DCOM仿佛能够解决一切分布式问题的丧失理智的时代，推出了一种民不见经传的OLE for Process Control，没有引起任何一个自动化厂商的足够重视，而正是因为这种低调的入场，加上各大自动化厂商惯常的保守和对工业以太网技术发展前景的短视，OPC成长了起来。谁会将一个 *** 作系统的厂商作为竞争对手呢？所以，OPC的开始是比较顺畅的。另一个强有力的吹鼓手是微软，他并没有鼓吹OPC无所不能，但它过分地鼓吹了DCOM，最终这种资本运作带来了浮躁，大家索性都不再研究其他开放的工业以太网传输协议了，OPC就是万能灵丹。历史再不断重演，今天的我们，又要被IBM等厂商所谓的SOA和Web2.0技术蒙住双眼。

另一个原因，就是崇洋，曾几何时，洋东西好得不得了，我还记得当时曾经定义一个内部的基于TCP数据传输协议，就有保守派在我耳边喋喋不休：协议这东西都是国外大公司制定得，如何如何神奇，如何如何专业，总之，中国人连制定一个企业的TCP传输协议的能力都没有了。不过最终证明，不但能够制定，只要对工业数据传输得需求把握得好，中国人可以制定出一样优秀得开放数据传输协议。但问题似乎总是出现：你制定了，谁拥护啊？你制定了，好吧，虽然是开放式协议，为啥是你A公司制定，不是我B公司制定？国人的问题多得不得了。中国目前也出了十多家有一定规模的自动化厂商，有没有成立一个多个企业的标准委员会，讨论一下国有开放标准？没有！这就是现实。我们不还以被美国仪器仪表协会承认而自豪么？我们不还为了能够达到欧洲标准而欣慰么？所以，在这样的土壤上，本土的种子难得开花结果。

其实，最适合工业使用的以太网数据交互协议，绝对不是OPC，而应该是一种基于TCP/IP的，平台无关传输协议。这种协议得制定，只要兼顾了实时值、历史值、主动变化通知，考虑了批量数据读写和并发连接，考虑了不同设备处理速度得不同，就会变得即鲁棒又实用。而我们国人完全有能力制定自己的开放协议！

我深深的知道，问题虽然明显，但明天早晨，我仍然必须接受这个洋品牌和洋标准充斥的世界。OPC虽然不好，但未来5年恐怕还会被趋之若骛。我的力量虽有限，但有幸的是我在一家民族自动化企业就职，还可以一点点地身体力行以尽绵薄，希望国内业界同仁达成共识，有朝一日，可以共同推动由中国人制定的开放工业以太网实时数据传输标准，到那个时候，这个自动化的行业，才能因开放的标准而变得简单高效，四通八达。就脱离微软。

半导体opc工程师岗位职责：

1.根据工作计划、项目目标和要求，指导OPC技术开发。

2.组织实施与OPC和光刻模拟技术相关的重点项目研发，进行技术攻关。

3.撰写并提交技术报告、工作报告，并归档。

4.协助其他模块和集成工程师，解决重点工艺难题。

5.解决紧急出现的重大工艺难题。

6.对相关人员进行OPC和光刻模拟前沿技术培训。

任职资格：

1.本科以上学历，物理学、光学、微电子学、计算机科学相关专业。

2.十年以上相关工作经验。

3.精通OPC技术开发的流程和规则，精通OPC模型建立、OPC菜单建立及OPC验证流程；精通Synopsys、Mentor或Brion等OPC相关EDA软件；熟悉Linux系统及软件编程。

深入理解各个工艺技术节点所需的OPC解决方案及其对应的光刻技术，如RBOPC，MBOPC，RBAF，PW OPC，PW LRC，HSF，DPT，DFM，Immersion等。

4.深刻理解OPC在图形化工艺中的作用和影响，精通光学成像原理，熟悉OPC相关光刻材料及设备。

5.熟悉半导体器件物理基础知识，熟悉工艺集成基础知识和流程及相关工艺模块（如刻蚀等），熟悉版图设计和tapeout。

---