DFT设计中的不同阶段介绍
在DFT(Design for Test,可测试性设计)软件开发中,针对设计检测的完整流程通常包含Setup(设置)、Analysis(分析)、Insertion(插入)和Verification(验证)四个核心阶段。以下是各阶段的详细说明:
1. Setup(设置阶段)
核心任务:为后续分析、插入和验证搭建基础环境,包括设计加载、库文件读取、约束条件定义等。
具体操作:
- 设计加载:读取RTL代码或门级网表(如Verilog文件),指定顶层设计(Top Design)。
- 库文件读取:导入标准单元库、Tessent库或Mentor ATPG库,确保工具能识别设计中的元件。
- 约束条件定义:
- 设置时钟频率、扫描链配置(如扫描使能信号
scan_en
)。 - 定义电源域(Power Domain)和UPF(Unified Power Format)文件,管理多电压域设计。
- 添加输入约束(如固定扫描模式信号
scan_mode
为0或1)。
- 设置时钟频率、扫描链配置(如扫描使能信号
- 环境配置:设置设计层级(Chip/Sub-sys)、内存测试开关(
-mem_bist on/off
)等。
示例命令:
tcl
read_verilog top.v # 读取顶层设计 |
set_current_design top # 指定当前设计 |
read_cell_library std_cell.lib # 读取标准单元库 |
add_clock CLK -period 10ns # 定义时钟 |
add_input_constraints scan_en -C0 # 固定扫描使能信号为0 |
2. Analysis(分析阶段)
核心任务:检查设计是否符合DFT规则,识别潜在问题,并生成测试模式生成所需的模型。
具体操作:
- 设计规则检查(DRC):
- 验证扫描链连接性、时钟树结构、复位信号分布等。
- 检查不可控/不可观测点(如组合逻辑环、锁存器未扫描化)。
- 故障模型映射:将物理缺陷(如短路、断路)映射为逻辑故障模型(如固定故障、转换故障)。
- 测试点插入分析:确定需额外插入的测试点(Test Points)以提升故障覆盖率。
- 生成TCD(Tessent Core Description):为内存测试(MBIST)生成描述文件。
示例命令:
tcl
check_design_rules # 运行DRC检查 |
report_drc_violations # 报告违规项 |
analyze_drc_violation -fix # 尝试自动修复DRC问题 |
3. Insertion(插入阶段)
核心任务:在设计中插入DFT逻辑(如扫描链、MBIST控制器),实现可测试性增强。
具体操作:
- 扫描链插入:将普通寄存器替换为扫描触发器(Scan Flip-Flop),并连接成移位寄存器链。
- MBIST控制器插入:为内存(RAM/ROM)添加自测试逻辑,生成测试模式并比较结果。
- 边界扫描(JTAG)插入:在芯片引脚附近插入边界扫描单元,支持板级测试。
- 时钟/复位网络优化:确保测试模式下时钟树稳定,复位信号可控。
示例命令:
tcl
insert_scan -chain_count 4 # 插入4条扫描链 |
insert_mbist -memory all # 为所有内存插入MBIST控制器 |
elaborate_design # 展开设计,应用DFT插入 |
4. Verification(验证阶段)
核心任务:验证插入的DFT逻辑是否正确,确保测试模式能覆盖目标故障,且不影响功能模式。
具体操作:
- 功能仿真验证:
- 在测试模式(
scan_mode=1
)下运行仿真,检查扫描链移位、MBIST操作是否正确。 - 在功能模式(
scan_mode=0
)下验证设计功能未被破坏。
- 在测试模式(
- ATPG(Automatic Test Pattern Generation):
- 生成测试向量(Patterns),目标故障覆盖率通常需>95%。
- 优化向量以减少测试时间和成本(如合并相似向量)。
- 形式验证(Formal Verification):
- 对比插入DFT前后的网表,确保逻辑等价性。
- 时序收敛检查:
- 与后端团队协作,确保测试模式下时序满足要求(如Shift/Capture时序)。
示例命令:
tcl
run_atpg -coverage 95 # 生成覆盖率95%的测试向量 |
simulate -mode test # 运行测试模式仿真 |
verify_equivalence -golden original.v -revised dft_inserted.v # 形式验证 |
阶段间的关联与迭代
- Setup → Analysis:若DRC检查失败(如扫描链未连接),需返回Setup阶段调整约束。
- Insertion → Verification:若仿真发现MBIST控制器错误,需返回Insertion阶段修复逻辑。
- 全流程迭代:复杂设计可能需多次循环各阶段,直至满足覆盖率、时序和功能要求。
补充:量产支持阶段(Post-Silicon)
虽非设计阶段,但DFT工程师需参与:
- ATE调试:将测试向量适配至自动测试设备(ATE),优化测试程序。
- 良率分析:通过测试结果定位制造缺陷(如金属短路),反馈至工艺优化。
- 测试成本优化:减少冗余测试项(如CP阶段仅保留高价值测试),降低量产成本。
通过以上阶段,DFT软件工程师能系统化地提升芯片可测试性,确保高质量芯片交付。
讨论:Analysis阶段的DRC检测里面会有仿真检查操作吗
在DFT(Design for Test)软件的Analysis阶段中,DRC(Design Rule Check,设计规则检查)的核心目的是静态验证设计是否符合DFT规则,通常不直接包含动态仿真检查。但某些高级DRC工具或特定场景下,可能会结合轻量级仿真或形式化验证来增强检查能力。
1. 传统DRC的本质:静态检查
DRC的主要任务是通过静态分析(无需运行仿真)检查设计中的结构性和逻辑性违规,例如:
- 扫描链相关问题:
- 扫描触发器(Scan Flip-Flop)未正确连接。
- 扫描链存在断链(Broken Chain)或环路(Loop)。
- 扫描使能信号(
scan_en
)未驱动所有扫描单元。
- 时钟与复位问题:
- 测试模式下时钟树不稳定(如时钟门控未正确控制)。
- 复位信号在测试模式下不可控(导致扫描链无法初始化)。
- 不可测试逻辑:
- 组合逻辑环(Combinational Loop)导致测试模式锁死。
- 锁存器(Latch)未被扫描化,形成不可观测点。
- 内存测试问题:
- MBIST控制器未覆盖所有内存实例。
- 内存地址/数据总线存在冲突。
静态DRC的优势:速度快、资源占用低,适合大规模设计早期快速定位问题。
2. 仿真检查在DRC中的角色:有限但存在
虽然DRC以静态检查为主,但以下场景可能引入仿真或准仿真操作:
(1) 动态DRC(Dynamic DRC)
某些DFT工具(如Synopsys Tessent、Cadence JasperGold)提供动态DRC模式,通过:
- 模拟测试模式行为:在静态检查基础上,模拟扫描链移位、MBIST操作等动态过程,检测:
- 扫描链移位时数据冲突(如多驱动)。
- MBIST控制器与内存接口时序不匹配。
- 形式化验证辅助:结合形式化方法(Formal Verification)证明测试逻辑在所有可能输入下的正确性,例如:
- 验证
scan_en=1
时,所有扫描触发器确实进入移位模式。 - 验证MBIST控制器在测试完成后能正确释放内存控制权。
- 验证
(2) 仿真驱动的DRC(Simulation-Guided DRC)
在复杂设计(如多时钟域、低功耗设计)中,静态DRC可能漏检某些问题,此时会:
- 生成测试激励:通过DFT工具生成简化的测试向量(如扫描链移位序列),运行功能仿真。
- 监控关键信号:检查仿真波形中是否存在DRC违规(如扫描链数据未正确移位)。
- 示例流程:
tcl
# 生成扫描链移位测试向量
generate_patterns -type scan_shift -count 100
# 运行仿真并检查波形
simulate -patterns scan_shift.v -waveform scan_wave.vcd
# 分析波形中的违规(如数据冲突)
check_waveform -file scan_wave.vcd -rule "no_multi_drive"
(3) 特定工具的混合检查
- Synopsys Tessent:在
check_drc
命令中可通过-dynamic
选项启用动态检查。 - Cadence Modus:结合Incisive仿真器进行DRC+仿真联动验证。
- Mentor FastScan:在ATPG前运行仿真验证扫描链连接性。
3. 仿真检查的局限性
即使引入仿真,DRC阶段的仿真与后续Verification阶段的完整仿真仍有区别:
特性 | DRC中的仿真检查 | Verification阶段的仿真 |
---|---|---|
目的 | 快速定位结构性违规 | 验证测试模式功能正确性 |
激励复杂度 | 简化激励(如单周期扫描移位) | 完整ATPG向量或随机测试向量 |
覆盖率 | 针对特定规则(如无多驱动) | 故障覆盖率(Fault Coverage)目标 |
运行时间 | 短(秒~分钟级) | 长(小时~天级,依赖向量规模) |
4. 实际工程中的建议
- 优先静态DRC:在早期阶段(如RTL或门级网表阶段)运行静态DRC,快速过滤明显问题。
- 关键路径仿真:对静态DRC报告的疑似问题(如时钟冲突),针对性运行仿真验证。
- 形式化验证补充:对关键测试逻辑(如MBIST控制器)使用形式化方法证明正确性。
- 工具选项配置:根据设计复杂度选择是否启用动态DRC(如Tessent的
-dynamic
)。
总结
- 传统DRC****:静态检查为主,不依赖仿真,适合快速定位结构性问题。
- 仿真检查:在动态DRC或混合流程中作为补充,用于检测静态分析难以覆盖的动态行为(如数据冲突、时序违规)。
- 最佳实践:结合静态DRC的效率和仿真/形式化验证的准确性,形成分层验证策略。
附加:
【SOC 芯片设计 DFT 学习专栏 -- DFT DRC规则检查】-CSDN博客
DFT中的DRC检查详解及常见问题-CSDN博客