DFT(Design for Testability可测性设计)

DFT(Design for Testability可测性设计)

在芯片设计时预先插入测试结构,以便后期能有效测试芯片有没有坏。

芯片一旦制造出来,你不能打开看内部电路对不对,只能从外部“输入→输出”测试。
但芯片内部很复杂,很多逻辑你根本测不到,所以我们提前设计“可测性结构”。

常用技术:

  • Scan Chain(扫描链)
  • BIST(内建自测电路)
  • Test Point Insertion(插入测试点)

一、fault model

Fault model(故障模型)” 是芯片测试(DFT)**和**数字系统设计中非常核心的概念之一。

它的本质是:用抽象的方法模拟电路在制造或运行过程中可能出现的典型故障,方便我们设计测试用例来检测这些故障。

现代芯片结构复杂,不可能穷举所有电路状态来检测是否有错误。 所以我们要 “预设”一组常见的故障模式,然后针对这些模式来设计测试。

这就像体检时,我们先预设常见疾病,做对应项目,而不是把身体拆开来看。

常见的 Fault Models(故障模型)有:

模型名称简称模拟的故障类型举例
Stuck-at FaultSAF节点永久卡住在 0 或 1(制造缺陷)某个导线断了,总是 0,不随输入变
Transition FaultTF节点电平变化太慢(时序缺陷)电压没能在时钟周期内翻转,功能错
Bridging FaultBF两根导线意外连在一起信号线短路,两条线输出一样
Open FaultOF节点悬空(焊接缺陷)某个连线没焊好,不导通
Delay FaultDF路径延迟过大导致时序失败电路逻辑对但输出太慢
Stuck-open FaultSOFCMOS 中的晶体管没完全导通或断开在模拟电路和异步电路中较常见

Fault Model 的用途?

在 DFT(Design for Testability)中,我们用 fault models 来:

  1. 设计测试向量(Test Patterns)
  2. 进行自动故障模拟(Fault Simulation)
  3. 评估测试覆盖率(Fault Coverage)
  4. 优化扫描链和测试结构设计

二、MBIST 内建存储器自测试

Memory Built-In Self Test(内建存储器自测试)

MBIST 是专门用于自动测试芯片内部存储器(如 SRAM、ROM、Cache)是否存在故障的一种内建自测试机制。

现代芯片(SoC、微处理器、ASIC)中常包含大量嵌入式存储器,比如:

  • 寄存器堆
  • L1/L2 缓存
  • 控制表
  • 数据缓冲区

这些 RAM/ROM 区域由于面积大、工艺敏感,非常容易出错(bitflip、开短路、耦合等)

但你又无法像测试逻辑那样“输入输出都能看”,所以必须 内建一个小电路帮我们测试它们,这就是 MBIST。

MBIST 通常包含以下模块:

模块作用
BIST Controller控制测试流程启动、停止
Address Generator自动生成地址序列,遍历整个 memory
Data Generator自动生成测试数据模式(如 10101010、0000、1111 等)
Comparator比较写入值和读出值是否一致
Status Register记录测试是否通过,哪一位出错等信息

MBIST 通常内建这些内存测试算法:

名称说明
March C / March C-最常用,遍历内存时使用读写操作组合
March B / March A更复杂,能检测更多类型的耦合故障
Checkerboard / GalPat检测特定位相互影响的问题
Walking 1/0检查每一位是否能独立翻转

这些算法可以发现:

  • Stuck-at fault(卡住)
  • Transition fault(翻转错误)
  • Coupling fault(某个位影响另一个位)

三、SCAN扫描测试结构

SCAN 是一种将芯片内部的触发器(Flip-Flops)连接成一条或多条“扫描链”,以便通过外部端口读写内部状态,从而实现结构级测试的方法。

为什么要用 SCAN?

  1. 芯片内部的触发器、逻辑路径平时是“看不到、碰不到”的;
  2. 如果只有外部引脚做测试,覆盖率很低;
  3. 有了 SCAN,我们可以:
    • 控制每个触发器的输入(可控性 controllability
    • 观察每个触发器的输出(可观测性 observability

具体怎么实现

核心做法:给每个 D 触发器前面加一个 2:1 多路选择器(MUX)

让它可以在“功能模式”与“测试模式”之间切换输入来源。

Scan Chain 的工作流程(3个阶段)

步骤1:RTL 级插入 scan-ready DFF

你在设计时,用带有 scan_in / scan_enable 的特殊触发器:

module scan_dff (
  input clk,
  input scan_enable,
  input d, scan_in,
  output reg q
);
always @(posedge clk) begin
  q <= scan_enable ? scan_in : d;
end
endmodule

步骤2:综合(Synthesis)支持 scan insertion

  • 工具如 Synopsys Design Compiler / Cadence Genus 可自动插入 scan;
  • 支持“scan_def”或“scan_chain setup”语法;

步骤3:DFT 工具连接扫描链

  • 使用 DFT 插件(如 DFTAdvisor)连接所有 scan_dff;
  • 决定使用几条链(单链 or 多链);
  • 自动生成 scan_in / scan_out 的 pin 映射。

步骤4:生成 ATPG 向量

  • 使用 TetraMAX / FastScan 等工具;
  • 针对 stuck-at fault / transition fault 生成测试向量;
  • 输出 scan 向量文件(.vec、.stil),用于芯片测试或仿真。

BIST

USER RANDOM LOGIC

memory macro

io pad

other hard macro(analog/phy)

fault model 抽象缺陷行为,构造对应的缺陷测试方法

<think>我们正在处理一个关于物理设计(PR)工具在导入scan chain定义文件(scandef)进行scan reorder时遇到报错的问题。报错信息是“cell not found in db”,用户怀疑是scandef与网表版本不一致导致。 首先,我们需要理解这个问题的背景。在物理设计流程中,scan chain reorder是一个常见的步骤,它通过重新排列scan chain中的cell顺序来优化时序和布线。scandef文件通常包含scan chain的结构信息,包括scan cell的实例名和连接关系。PR工具会读取这个文件,并根据当前的布局布线情况调整顺序。 报错“cell not found in db”意味着在PR工具使用的数据库(db)中找不到scandef文件中指定的某个cell。db库通常是由逻辑综合和布局布线工具生成的,包含了设计中的标准单元、宏单元等信息。 可能导致这个问题的原因包括: 1. 版本不一致:scandef文件可能是从旧版网表生成的,而当前PR工具使用的是新版网表,导致部分cell名称或类型发生变化。 2. 命名差异:scandef文件中的cell命名方式与PR工具中使用的命名方式不一致(例如,大小写、转义字符等)。 3. 设计修改:在网表更新过程中,有些cell被删除或重命名,而scandef文件没有相应更新。 4. 库文件问题:PR工具加载的db库不完整,缺少某些cell的定义。 5. 文件损坏:scandef文件或db库文件在传输或生成过程中损坏。 其中,用户提到的scandef与网表版本不一致是一个常见原因。但我们需要进一步分析。 解决步骤建议: 1. 确认scandef和网表的版本:检查生成scandef的网表版本与当前PR工具使用的网表版本是否一致。如果不一致,需要重新生成scandef(使用当前网表)。 2. 检查cell命名:在scandef中找一个报错的cell名称,然后在当前网表中搜索,看是否能找到。注意转义字符(例如,斜杠、中括号等)可能被不同工具处理方式不同。 3. 检查db库:确认PR工具加载的db库是否正确且完整,是否包含该cell。可以尝试在db库中直接查找该cell。 4. 查看工具日志:检查PR工具加载scandef和db库时的日志,看是否有警告或错误信息。 5. 重新生成scandef:如果确认是版本问题,使用当前网表重新生成scandef文件。 如果问题仍然存在,可能需要检查流程中其他步骤,比如库的版本是否匹配,或者是否在流程中修改了网表但没有更新scandef。 引用说明:在回答中,我们引用了用户提供的信息,即报错信息“cell not found in db”以及用户怀疑的版本不一致问题。由于用户没有提供具体的引用来源,我们不会在回答中标注引用标识。 根据用户的问题,我们生成以下相关问题: §§相关问题§§ 1. 如何确认scandef文件和网表版本的一致性? 2. 在PR工具中,如何检查db库是否包含特定的cell? 3. 重新生成scandef文件的常用方法是什么? 4. 除了版本不一致,还有哪些原因会导致“cell not found in db”错误? 5. 如何避免在物理设计流程中出现scandef与网表版本不一致的问题?</think>### 问题分析 报错"cell not found in db"在PR工具导入scandef进行scan reorder时,**确实可能是scandef与网表版本不一致导致的**,但同时也存在其他潜在原因。以下是系统性的排查方向: --- ### 关键原因分析 1. **版本不一致(最常见)** - 若scandef是从旧版网表生成的,而PR工具加载的是新版网表,cell命名或层次结构可能已变更(如优化后cell被删除/重命名)。 - **验证方法**:对比scandef中的缺失cell名称与当前网表中的实际cell名称是否匹配。 2. **库文件问题** - **DB库不完整**:PR工具加载的.db库未包含scandef中引用的cell类型(如特殊扫描单元)。 - **库版本冲突**:scandef引用的cell来自旧工艺库,但PR工具加载了新工艺库。 3. **文件解析错误** - Scandef文件中的cell名称包含特殊字符(如`\`, `[ ]`, `$`),导致解析失败。 - 文件编码或格式错误(如DOS/UNIX换行符不兼容)。 4. **设计层次差异** - Scandef可能基于扁平化网表生成,但当前设计包含层次化模块(或反之),导致路径不匹配。 --- ### 解决步骤 1. **版本一致性检查** - 重新生成scandef:使用当前网表通过DFT工具(如Tessent/Genus)输出最新scandef。 - 确认网表与DB库版本匹配:检查PR工具加载的.db库是否与综合/布局阶段一致。 2. **Cell名称验证** ```tcl # 在PR工具中执行:检查缺失cell是否存在 report_lib_cell <missing_cell_name> # 在网表中搜索cell grep "missing_cell_name" current_netlist.v ``` 3. **特殊字符处理** - 检查scandef中cell名称的转义符(如`\/`需改为`/`),或使用工具选项保留原始命名: ```tcl set_scandef_options -keep_original_names true ``` 4. **库文件验证** - 确保所有参考库(.db)已正确加载且包含扫描单元: ```tcl report_library -all ``` 5. **日志分析** - 检查PR工具日志中cell的完整路径,确认层次结构是否对齐。 --- ### 预防措施 - **流程自动化**:在网表更新后,自动触发scandef重新生成。 - **版本控制**:对网表、scandef、DB库使用相同版本标签(如Git tag)。 - **工具选项**:启用`-strict_scan_chain_check`(若支持)提前暴露兼容性问题。 > **引用说明**:在物理实现流程中,scandef与网表版本同步是避免扫描链错误的关键实践[^1]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值