- UID
- 1023166
- 性别
- 男
- 来自
- 燕山大学
|
作者:明导公司 Matthew Hogan
集成电路可靠性——新兴的竞争因素
可靠性验证正获得越来越多的关注。器件和导体愈加小巧,器件氧化层越来越薄,电源域的数量快速增长。数字内容的显著增加正渗透到汽车、医疗和通信领域对可靠性要求较高的应用中。
集成电路可靠性的技术和市场推动因素
最早的可靠性检查是对集成电路版图进行目测,确定哪些结构可能出问题,然后进行调整。这种方法不再奏效。设计工作量大,而且非常复杂,人工检查方法太不可靠。竞争环境要求设计人员根据仿真和经验,采用技术节点留出明显的余量,优化性能、占用空间和可靠性。
相比预防外部因素(例如静电放电)引起的重大故障,设计人员现在必须处理好更不易察觉的设备退化。与快速明显的硬故障不同,这些可靠性故障随着时间的推移而逐渐显现出来,通常难以预测。一旦某件产品被认为并不可靠,便可能很难改变市场对它的看法。
行业内目前正在更仔细地研究集成电路可靠性问题,以确定需要注意的方面并事先了解其对设计余量的影响。美国静电放电协会 (ESD Association) 撰写了一份关于静电放电检查的技术报告[1],旨在帮助行业做好更充分的准备来处理设计过程中常见的静电放电问题。Reliability Simulation Council 也在研究其它方法来提高集成电路设计的可靠性。
更换代工厂或改用不同的工艺节点可能有损专门方法的效率。在这些关键时候,一套严格完善的最佳操作方法对于维持生产力和推动力至关重要。
集成电路可靠性检查
重要的可靠性设计 (DFR) 问题包括:
时间相关介质击穿 (TDDB)
负偏压温度不稳定性 (NBTI)
热载流子注入 (HCI)
阈值电压偏移 (Vt)
电迁移 (EM)
电过应力 (EOS)
闩锁效应(Latch-up)
本文并不逐一详细解释这些机制。我们将讨论一种普遍的集成电路设计可靠性检查方法,并举例说明这种方法如何应用于 TDDB 和 NBTI。这种检查方法灵活,自动,还能以类似的方式进行其它检查。
传统方法
添加识别层
对于传统设计规则检查 (DRC) 工具,设计人员必须通过在版图上添加识别层,确定需要进行可靠性检查的实际位置。识别层用以确定需要通过具体检查来确认适当的 DFR 方法的实际区域,而不是将要实现的实际功能。
添加识别层是一个单调乏味且容易出错的手动过程。识别层也增加了 DRC 工作量(延长了整体周期时间),并且难以维护。由于存在这些缺点,识别层无法充分确保设计具备当今竞争市场所需的可靠性。
SPICE 仿真
一些可靠性检查需要了解电路中每个节点的电压。传统方法采用 SPICE 仿真,提供每个节点的电压和电流,因为电路由一系列支持对所有预期的工作模式进行仿真的向量推动。但是,SPICE 仿真特别耗时,需要大量的时间和洞察力来恰当地解释和评估产生的波形。为了确保充足的覆盖面,测试向量通常由自动覆盖工具产生。由于产生了众多向量,因此在依赖人工评估技术时很容易漏掉某个问题。
可升级的解决方案的特色
设计人员需要一个强大的可升级自动化物理验证 (PV) 解决方案,帮助各个经验水平的设计人员在设计中整合可靠性检查的最佳做法。
一款可升级的可靠性验证解决方案必须能够:
体现物理系统的特色,并按照一套定义明确的最佳方法或规则进行验证,
尽量避免完整模拟,以节省时间和计算资源,
让具有专长的工程师能够按照专业的可靠性设计方法来验证设计。
为了完成这些任务,可升级的可靠性验证工具需要一些对于物理验证过程来说新出现的关键功能:
通过网表的规则支持拓扑识别,确定需要检查的物理结构,
支持传递/连接的规则,从而在需要检查的结构之间建立特定关系,
能够评估应用于前两个工艺结果的物理规则,
能够与常用的物理验证流程相整合,简化信息交流过程。
桥接观点
可靠性检查的关键难题在于架起设计过程中逻辑观点与物理观点之间差异的桥梁。逻辑和模拟设计人员通常考虑原理图和 Verilog 描述。而物理(班图)设计人员则考虑几何结构、宽度、长度、特征间隔等等。他们使用的工具也会相应变化。可靠性检查需要结合这些观念,因此给这些工具和使用工具的工程师都带来了挑战。
对于许多可靠性检查而言,问题在于确定班图中的哪些地方需要检查。因为没有方法来缩小范围,大多数设计会产生大量误报。像识别层这样只以物理观点操作的解决方案很有限。更好的解决方案应该可以让设计人员现在网表里指定需要检查的区域,然后在版图中相应的区域进行必要的物理测量。
除了拓扑识别之外,设计人员还需要在整个设计过程中追踪逻辑和物理关系。例如,要检测因不正确的电压域交叉导致违反栅击穿电压限制的情况,设计人员必须能够在静态模式下向设计中的所有节点传递供应电压(以避免耗时的模拟)。之后,设计人员可以使用拓扑识别来消除原本拥有多个电源域连接的结构(例如电平转换电路),消除误报并且得到快速高效的结果。
实例:TDDB 检查演示
这种 TDDB 检查采用的是 Calibre® PERC™ 可靠性验证工具。图1显示的是电路包含 PMOS 和 NMOS 薄栅氧化层,它们通过直接和非直接连接为电源域 VDD2 和 VSS2 提供电源。非直接连接可能会贯穿另一个晶体管、二极管、电阻器或其它电路元件,成为设计审核阶段不易察觉的“缺失”路径,特别是当非直接路径贯穿的是设计层级不明显的情况下的其它地方的电路。子电路 (VDD/VSS) 本身的局部电源连接可以在更大规模的设计中看到。还必须对在其它方面已经得到验证的 IP 模块的外部连接进行评估。
图1:采用 Calibre PERC 的 TDDB 检查法:检查的是通过直接和非直接路径到 VDD2/VSS2 的薄栅氧器件。
为确定不安全的薄栅氧器件,设计人员对这个检查方法进行了定义(下面显示的是伪代码):
定义设计中的电源域。
定义哪些电源域对薄栅氧器件是“不安全”的。
定义薄栅氧MOS器件的类型和衬底类型。检查这些薄栅氧MOS器件中“source”、“drain”、“bulk”到电源域的连接性。
a. 评估直接和非直接路径。
b. 把那些连接到“不安全”电源域的薄栅氧MOS标识为错误。
复杂的系统通常存在多个电源域,这就需要通过复杂的设计规则来确定哪些电源域是安全的,以及什么条件下才是安全的。
验证MOS器件的bulk端的连接性对判断一个电路是否容易受到与电源域相关的可靠性问题的影响非常重要。图2显示的是,一个不当的bulk 端的连接是如何因为bulk电压的上升而让 PMOS 栅易受到 NBTI 的影响的。
图2:采用 Calibre PERC 的 TDDB 检查法:一个具有高压路径的薄栅氧 PMOS(型号:pmos_lv)可能会导致 NTBI 。
与现有的可靠性技术相比, Calibre PERC 这样的自动化可靠性验证工具可以保证现在的设计不仅能够被生产出来,而且性能在其整个生命周期中一直很稳定(表1)。
表1.不同的可靠性检查方法之间的对比
项目 | Calibre PERC 自动检查法
| 识别层
| 人工检查
| 规则覆盖率
| 超过90%
| 30%以下
| 10%以下
| 假错
| 无
| 很多
| 一直都有
| 工具集成
| Topology、LVS、DRC、R-extraction
| DRC + 手动标识
| 人工检查
| 工具质量
| Sign-off level
| 依赖性大
| 无法评估质量
| 可编程性
| 完全可编程
| 部分可编程
| 完全不可以
| 运行时间
| 分钟
| 分钟~小时
| 小时~天数
| 人为失误
| 无
| 有时有
| 一直都有
| 用户应用
| 自动
| 半自动
| 手动
|
运用新技术
我们看到了两种应用方式:自上而下和自下而上。
有了存档、维护和改进可靠性验证方法的集中式自上而下的方法(一般由某个 CAD 或 QA 部门掌握)后,这个部门应当(通过一个公共设计规则平台)在工具中采用新的可靠性检查,并向集成电路设计和验证人员推广配置好的工具。
自下而上的方法通常最初由小的设计小组开始采用这些新工具并结合自身的检查规则来提高他们验证任务的效率和有效性。在他们的成果发布后,会有更多的人需要这项新技术。在某个时间点,CAD 部门会加入进来提供支持,以减轻本地支持负担,并为所有用户提供统一的经验。
结论
集成电路的可靠性验证工作并非易事,但它正迅速变成一项至为关键的能力,能否创建出能够提供长期可靠性的成功集成电路产品便在此一举。为了做好这件事,您必须对这项工作给予明确的关注,并采用你认为最有效的工具。
参考
[1] EDA Tool Working Group, ESD Electronic Design Automation Checks, ESD TR18.0-01-11, 2011
链接
美国静电放电协会:http://www.esda.org/
Reliability Simulation Council:http://www.linkedin.com/groups/R ... uncil-4220058/about
Calibre PERC:http://www.mentor.com/perc
作者介绍
Matthew Hogan 是明导 (Mentor Graphics) 的一名 Calibre 营销工程师,拥有超过十五年的设计和现场经验,擅长处理当今先进设计方面的问题。他是电气与电子工程师协会 (IEEE) 的高级会员,也是美国计算机协会 (ACM) 的会员。他获得了皇家墨尔本理工大学 (Royal Melbourne Institute of Technology) 工程学学士学位,同时还获得了玛丽赫斯特大学 (Marylhurst University) 工商管理学硕士学位。他的电子邮箱地址:matthew_hogan@mentor.com 。 |
|