企业官网建设流程全解析

简介：本资源是一份面向数字电路验证工程师与IC测试初学者的Mentor MBIST工具系统性学习总结，聚焦于内置自测试（BIST）在嵌入式存储器（如SRAM、ROM）故障检测中的工程实践。内容覆盖MBIST添加必要性、存储器类型特性、典型四模块结构（TPG/CUT/RA/DM）、适用场景判断、优缺点权衡、常见故障类型（永久性/逻辑/物理等）、核心算法（LFSR/PRNG）、Mbistarchitect脚本生成方法、ATPG语法要点、BIST变量机制及ROM/SRAM库文件格式等12个关键技术模块，并附有完整目录与实操脚本示例。资源为单个319KB Word文档（.docx），结构清晰、术语规范、图文结合，便于快速查阅与工程复用。目前已有1443人学习下载，适合需深入理解MBIST集成原理、调试流程与工具链使用的中初级芯片验证人员。

1. MBIST 到底是什么：芯片里那个“自己体检”的医生

你有没有想过，一块刚流片回来的芯片，还没接上任何测试仪，它自己就能悄悄检查一遍内部成百上千个存储单元——有没有漏电、有没有短路、有没有读写失灵？这不是科幻，而是 MBIST（Memory Built-In Self-Test）干的事。打个比方：如果芯片是一栋智能大楼，逻辑电路是电梯、消防、照明系统，那内存（SRAM/ROM）就是整栋楼的档案室和员工工位。而 MBIST 就是嵌在档案室墙里的“自检巡更员”：不靠保安（外部ATE设备）挨个敲门查岗，它自带手电筒、登记本和报警器，通电即启动，5毫秒内扫完全部工位，发现异常立刻拉响内部警报。

为什么这个“自检员”越来越不能少？因为现代芯片里，内存占面积常超40%——它不再是配角，而是故障高发区。灰尘颗粒、工艺波动、电压抖动，都可能让某个存储单元“装死”或“说胡话”。等芯片焊到板子上再测？晚了。MBIST 把测试能力“缝进”芯片设计里，让每一块芯片出厂前都自带“健康码”。它不是锦上添花的功能，而是数字世界里，对可靠性最朴素也最硬核的承诺。搞懂 MBIST，等于看懂了芯片如何在无人监督时，依然守住自己的底线。

2. 为什么非得用 MBIST：当内存测试从“送检”变成“自首”

2.1 内存测试的困局：为什么传统方法越来越力不从心？

想象一下，你要检查一栋有1024个抽屉的档案柜（比如一个 1K×32 的 SRAM）。传统ATE（自动测试设备）怎么做？用探针一根根接上地址线、数据线、控制线，发指令：“打开第0号抽屉，放一张‘0’字纸；再打开，看纸还在不在……” 这种方式叫“外部激励+外部观测”，问题很现实：

• 速度卡脖子：ATE 设备跑 100MHz 已是高端配置，但你的芯片目标频率是 500MHz。用慢速设备测高速内存？就像用自行车测F1赛车的刹车——测不出真实工况下的时序违例。
• 引脚不够用：一个大型 SoC 可能集成上百个内存块，每个都要独立接线？PCB 上根本布不下那么多测试通道，成本和复杂度直接爆炸。
• 物理不可达：有些内存深埋在芯片核心，连探针都够不着。就像大楼地下室的保险柜，你总不能为每次检查都拆墙。

MBIST 的破局点就在这里：它把“测试生成器”和“结果分析器”直接做进芯片内部，紧贴内存外围。测试信号不走芯片引脚，只在硅片内部小范围流转——路径极短、延迟可控、完全匹配芯片真实工作频率。这叫“实速测试”（At-Speed Testing）：内存怎么跑，MBIST 就怎么测。

提示：实速测试不是“跑得快就行”，而是要求测试向量的建立时间（setup time）和保持时间（hold time）必须严格满足内存时序约束。MBIST 控制器会精确插入 wait 周期，模拟真实读写节拍，这是它区别于简单“写0读0”的关键。

2.2 MBIST 的核心价值：不只是测，更是“可预测、可诊断、可集成”

MBIST 不是简单地多加几行代码，它带来的是测试范式的升级：

• 可预测性：用确定性算法（如 March 算法）遍历所有易出错模式。例如，“邻居错误”要求测试时让相邻单元互为干扰源，MBIST 能按预设 pattern 精确构造这种场景，而随机测试大概率漏掉。
• 可诊断性：当测试失败，MBIST 不只报“某块内存坏了”，还能定位到具体地址、甚至区分是“写0失败”还是“0→1转换失败”。这依赖内置的比较器（Comparator）和地址跟踪逻辑，把故障映射回物理位置。
• 可集成性：MBIST 模块通过标准接口（如 MUX 选择）与主系统共存。正常工作时，内存听 CPU 指挥；测试时，BIST 控制器接管总线。整个过程对上层软件透明，无需修改驱动或固件。

这三点叠加，让 MBIST 成为 DFT（Design for Testability，可测性设计）的基石。它把“测试”从制造端的负担，变成了设计阶段就植入的基因。

2.3 MBIST 的典型结构：四个模块，各司其职

MBIST 不是一个黑盒子，而是一个分工明确的小团队，围绕内存部署：

+---------------------+ | Test Pattern | ← 生成测试地址、数据、控制信号序列 | Generator (TPG) | （如 LFSR 或计数器） +----------+--------+ | +----------v--------+ +---------------------+ | Memory Under |<--->| Response Analyzer | ← 采集读出数据，与预期比对 | Test (MUT) | | (RA) | 发现差异即触发失败标志 | (e.g., SRAM) | +----------+--------+ +----------+--------+ | | v +----------v--------+ +---------------------+ | BIST Controller |←----| Diagnostic Module | ← 记录失败地址、类型，支持 | (FSM + Logic) | | (DM) | 故障分类（短路/转换/耦合） +---------------------+ +---------------------+

• TPG（测试图形生成器）：不是乱发数据，而是按算法步进。比如 MarchC+ 算法，会严格按“写0→读0→写1→读1→写0→读0…”的14步流程执行，每一步的地址、数据、控制信号都由 TPG 精确输出。
• MUT（被测内存）：MBIST 的服务对象。它的端口（地址A、数据D/Q、使能CEN/WEN/OEN、时钟CLK）被 BIST 控制器直接驱动，绕过系统总线。
• RA（响应分析器）：核心是“比较器”。它把内存实际读出的数据（Q）和 TPG 当前期望的数据（Expected Data）做异或（XOR）。只要有一个 bit 不同，就输出失败脉冲（fail pulse），并锁存当前地址。
• DM（诊断模块）：更高级的“故障翻译官”。它不仅记录 fail 地址，还结合失败时的测试步骤（是写操作失败？还是读操作失败？），推断故障类型。例如：连续多个地址在“写1后读0”失败，大概率是“对1短路”。

这个结构清晰表明：MBIST 是硬件电路，不是软件程序。它综合进 RTL 后，成为芯片不可分割的一部分。

2.4 MBIST 的适用场景：不是所有内存都值得加，但关键处必须加

MBIST 的引入需要权衡面积开销（通常增加 1~3%）和设计复杂度。所以它不是“越多越好”，而是“该上则上”。以下四类场景，MBIST 几乎是刚需：

• 中大型嵌入式内存：单块容量 ≥ 64Kbit。小内存（如 256×8）用简单扫描即可，大内存必须靠结构化算法覆盖所有耦合关系。
• IP 核形式复用的内存：比如 ARM 的 Standard Cell RAM IP。IP 提供方已预留 BIST 接口（bist_mode, bist_start），下游集成时只需例化控制器，省去重复开发。
• 对测试时间极度敏感的系统：如汽车电子 ECU，产线每秒都在烧钱。MBIST 将内存测试从秒级压缩到毫秒级，单颗芯片测试时间减少 90% 以上。
• 多内存共存的 SoC：一颗芯片含 20 个 SRAM + 5 个 ROM。MBIST 支持“分时复用”——一个控制器轮询多个内存，或“分布式”——每个内存配专属轻量控制器，避免总线争用。

反过来说，如果内存是纯只读、内容固定（如 Boot ROM）、且生命周期内永不更新，MBIST 的价值会降低，此时可考虑更轻量的 CRC 校验方案。

3. MBIST 和相近概念的区别：别把“体检员”当成“医生”或“保安”

3.1 易混点一：MBIST vs. LBIST（Logic BIST）

• 为什么混：名字像、都带 BIST、都用于芯片自测。
• 怎么区分：
  • MBIST 专治“记忆病”：只针对存储类电路（SRAM/ROM/DRAM 控制器），测试目标是存储单元的物理缺陷（短路、浮空、转换慢）。
  • LBIST 专治“逻辑病”：针对组合逻辑和时序逻辑（如 ALU、状态机），用伪随机向量（LFSR 生成）激发电路，捕获输出响应（MISR 压缩），检测门级故障（如 stuck-at-0/1）。
  • 关键区别：MBIST 的测试 pattern 是确定性、结构化的（March 算法），因为内存故障有明确物理模型；LBIST 的 pattern 是伪随机、统计性的，因为逻辑故障模式太复杂，穷举不现实。一个芯片可以同时有 MBIST（测内存）和 LBIST（测CPU核），它们是互补关系，不是替代关系。

3.2 易混点二：MBIST vs. Scan Chain（扫描链）

• 为什么混：两者都是 DFT 技术，都用来提升可测性。
• 怎么区分：
  • Scan Chain 是“体检通道”：它把寄存器（Flip-Flop）串联成一条长移位寄存器，在测试模式下，能直接“灌入”任意输入、“读出”任意内部状态。但它不生成测试向量，也不分析结果，只是提供了一条“高速公路”。
  • MBIST 是“体检套餐”：它自带“向量生成器（TPG）”、“被测对象（MUT）”、“结果分析器（RA）”，是一套闭环系统。Scan Chain 可以用来把 MBIST 的配置参数（如算法选择、地址范围）加载进去，但 MBIST 本身不依赖 scan。
  • 形象比喻：Scan Chain 是医院的“静脉注射通道”，能快速给全身输药；MBIST 是一套“全自动CT机”，自己摆姿势、自己拍片、自己出报告。你可以用通道给CT机供电，但不能用通道代替CT机。

3.3 易混点三：MBIST vs. Software-Based Memory Test（软件内存测试）

• 为什么混：都能测内存，工程师常用软件跑 memtest。
• 怎么区分：
  • 软件测试是“用户态体检”：运行在 CPU 上，通过指令读写内存。它能发现大部分功能错误（如地址译码错），但无法检测物理缺陷。例如：一个单元“对地短路”，软件写1读出来是0，看似正常（因为读操作没触发短路电流），但实际已失效；MBIST 的专用电路能施加特定电压/时序，暴露这类隐患。
  • MBIST 是“硬件态体检”：绕过 CPU 和总线协议，直接驱动内存端口。它能控制信号上升沿/下降沿的精确时刻，满足 nanosecond 级时序要求，这是软件永远做不到的。
  • 致命短板：软件测试无法在芯片未启动（pre-silicon）或 bootloader 未运行时工作；MBIST 在上电复位后即可启动，是真正的“零时刻守护者”。

3.4 易混点四：MBIST Controller vs. Memory Controller

• 为什么混：名字都带“Controller”，都和内存打交道。
• 怎么区分：
  • Memory Controller 是“管家”：负责管理内存的日常事务——地址映射、时序调度（tRCD/tRP）、刷新（DRAM）、ECC 校验。它是系统正常运行的必需模块。
  • MBIST Controller 是“特检组”：只在测试模式下激活，临时接管内存控制权。它发出的信号不遵循 JEDEC 标准，而是为故障激发定制（如连续写相同值、快速翻转地址）。测试结束，它立刻交权，不留痕迹。
  • 设计隔离：两者在 RTL 中是完全独立的模块，通过 MUX 选择谁驱动内存端口。一个健壮的设计，会确保 MBIST 激活时，Memory Controller 处于高阻态，避免信号冲突。

注意：混淆这两者会导致灾难性设计错误。曾有某项目将 MBIST 控制器误接为常驻主控，导致芯片启动后内存无法被 CPU 访问——因为“特检组”一直霸占着岗位。

4. MBIST 的核心算法：为什么不是“写0读0”那么简单？

4.1 内存故障的物理本质：四种错误，对应四种“考题”

MBIST 算法的设计，直指内存单元的物理缺陷模型。理解这四种错误，就理解了所有算法的出发点：

可见，“写0读0”只能抓出最粗浅的短路错误。真正的 MBIST 算法，是精心编排的“故障挖掘机”，每一步都针对一种物理机制。

4.2 March 算法家族：用“行走路线”覆盖所有陷阱

March 算法是 MBIST 的黄金标准，名字源于其像“行军”一样遍历地址空间。核心思想：对每个地址，执行一组写-读操作，并在读之前确保该地址已被正确写入；同时，利用地址递增/递减的顺序，自然构造出耦合所需的“邻居干扰”。

以March C+（文中提到的14步算法）为例，分解其逻辑：

Step 1: write 0s (to initial) // 全写0，清场 Step 2: read 0s , write 1s, read1s // 对每个地址：读0→写1→读1（测转换0→1） Step 3: read 1s , write 0s, read0s // 对每个地址：读1→写0→读0（测转换1→0） Step 4: read 0s , write 1s, read1s // 再次：读0→写1→读1（强化耦合） Step 5: read 1s , write 0s, read0s // 再次：读1→写0→读0（强化耦合） Step 6: read 0s // 最终全读0，确认无残留

• 为什么有效？

  • 步骤2中，当地址i被写1时，地址i+1还是0（因顺序执行），这就形成了“0-1”邻居对，暴露耦合错误。
  • 步骤3中，地址i被写0，而i+1刚被写1（步骤2末尾），又形成“1-0”对。
  • 多轮重复（步骤4-5）确保即使弱耦合也能被捕捉。

• 实速关键：所有read和write操作间的wait，都对应一个真实的时钟周期。工具（如 Mbistarchitect）会根据.atpg文件中定义的clock CLK high和wait语义，自动生成符合时序的 RTL，确保read操作发生在write之后的下一个时钟边沿。

4.3 算法选择指南：没有最好，只有最合适

不同 March 变体覆盖的故障集不同，选择需权衡覆盖率与测试时间：

提示：不要盲目追求高覆盖率算法。March C+ 比 March A 多花 3.5 倍时间。对消费电子芯片，March B 通常是性价比最优解；对安全关键系统，则必须用 March C+ 或更高。

5. 从理论到实践：用 Mentor Mbistarchitect 生成你的第一个 MBIST

5.1 输入基石：.atpg文件——用代码描述内存的“身份证”

MBIST 工具不是黑箱，它需要一份精确的内存规格说明书，这就是.atpg文件。它用声明式语法，告诉工具：“这个内存长什么样，怎么读，怎么写”。以文中的 SRAM 为例：

model SPRAM_512X32 (Q,CLK,CEN,WEN,A,D,OEN) ( bist_definition ( address A(array=8:0;); // 地址总线：9位（0-511） data_in D(array=31:0;); // 输入数据：32位 data_out Q(array=31:0;); // 输出数据：32位 clock CLK high; // 时钟：上升沿有效 chip_enable CEN low; // 片选：低电平有效 write_enable WEN low; // 写使能：低电平有效 dont_touch OEN high; // 输出使能：始终高（不参与测试） tech = smic18; // 工艺节点：SMIC 180nm address_size = 9; // 地址宽度 data_size = 32; // 数据宽度 read_write_port ( // 定义读写端口时序 write_cycle ( // 写周期：4步 change A; // 地址变化 change D; // 数据变化 assert CEN; // 拉低片选 assert WEN; // 拉低写使能 wait; // 等待1个时钟（建立时间） ) read_cycle ( // 读周期：5步 change A; // 地址变化 assert CEN; // 拉低片选 wait; wait; // 两个等待（tACC, tOE） expect Q move; // 期望Q输出变化（比较器采样点） ) ) ) )

• 关键参数解读：
  • array=8:0表示地址总线是 9-bit，索引从 0 到 511，对应 512 个单元。
  • assert CEN low告诉工具：CEN 信号的有效电平是低，因此assert CEN意味着输出 0。
  • wait是时序锚点：每个wait生成一个时钟周期，change和assert都在wait前完成，确保信号在时钟边沿稳定。
  • expect Q move是比较器的触发点，工具会在此刻采样 Q，并与 TPG 生成的期望值比对。

没有这份精准的.atpg，Mbistarchitect 就像没有地图的建筑师——建出来的 MBIST 控制器，可能根本驱动不了你的内存。

5.2 工具实战：六步生成可综合的 MBIST RTL

Mbistarchitect 是 Mentor DFT 流程的入口。它不写代码，而是根据.atpg自动生成三类 HDL 文件。以下是标准流程（基于文中的sram8kb.atpg）：

步骤1：创建工程并加载模型

mkdir project && cd project cp ../atpg/sram8kb.atpg ./ mbistarchitect # 启动图形界面 # 在GUI中：File → Load Library → 选择 sram8kb.atpg # Memory → Add Models → 选择 sram8kb

步骤2：配置核心参数

# 设置算法（选 March C+） setup mbist algorithms MarchC+ # 启用压缩（减少测试响应数据量） setup observation scheme -compress setup mbist compressor -localcomparator # 指定输出文件路径（关键！避免覆盖） set design name controller -module sram8kb_bist set file naming -bist_model ./rtl/sram8kb_bist.v set file naming -connected_model ./rtl/sram8kb_bist_con.v set file naming -testbench ./tb/sram8kb_bist_tb.v

步骤3：运行综合

run # 工具开始分析时序、生成RTL、插入MUX

步骤4：保存成果

save bist -verilog -script -replace # 生成Verilog + Tcl脚本 exit -discard

步骤5：理解输出文件

生成的三个文件各司其职：

• sram8kb_bist.v：MBIST 控制器核心，含 TPG、FSM、比较器。例化时需连接A,D,Q,CEN,WEN,CLK等。
• sram8kb_bist_con.v：连接模块，实现 BIST 与 Memory 的 MUX 选择。它包含关键信号bist_mode（高电平启用BIST）和bist_start（脉冲启动测试）。
• sram8kb_bist_tb.v：测试平台，含initial begin ... $display("PASS") end，可直接仿真验证。

步骤6：集成到顶层

// 顶层模块中，例化连接模块 sram8kb_bist_con uut ( .A(A), .D(D), .Q(Q), .CEN(CEN), .WEN(WEN), .CLK(CLK), .bist_mode(top_bist_mode), // 来自测试控制逻辑 .bist_start(top_bist_start) // 来自测试控制逻辑 ); // Memory 实例保持不变，但端口被 MUX 驱动 sram8kb mem_inst ( .A(uut.A_mux), .D(uut.D_mux), .Q(uut.Q_mux), .CEN(uut.CEN_mux), .WEN(uut.WEN_mux), .CLK(CLK) );

注意：sram8kb_bist_con.v中的 MUX 逻辑是关键。它确保当bist_mode==1时，内存端口完全由 BIST 控制器驱动；bist_mode==0时，端口由系统总线驱动。任何 MUX 设计错误，都会导致测试时总线冲突。

5.3 常见翻车现场：那些让 MBIST “测了等于没测”的坑

• 坑一：.atpg中wait数量与实际时序不符
  例：.atpg写wait; wait;（2个周期），但内存实际tACC需要 3 个周期。结果：expect Q move在数据未稳定时采样，必然失败。
  对策：用 STA（静态时序分析）反标.atpg，或在read_cycle中显式增加wait。

• 坑二：dont_touch信号被误用
  文中OEN设为dont_touch high，意思是“测试时 OEN 始终为高，不参与控制”。但如果内存实际需要 OEN 低才能输出，expect Q move就永远等不到有效数据。
  对策：dont_touch只用于真正不参与测试的信号（如调试口）。所有影响读写的信号，必须在read_cycle/write_cycle中明确定义。

• 坑三：地址范围配置错误
  .atpg中address_size = 11（2048个地址），但 RTL 中 memory 实例化为2048x32，而顶层连接时地址线只连了 10-bit（0-1023）。结果：BIST 访问地址 1024~2047 时，地址线高位悬空，行为不可预测。
  对策：生成.atpg前，用脚本校验address_size与 RTL 中 memory 的depth严格一致。

6. 什么时候该用 MBIST，什么时候该果断放弃？

6.1 用 MBIST 的黄金时刻：当“不可测”成为最大风险

MBIST 的价值，从来不是在实验室里跑通一个 demo，而是在真实量产和应用中，化解那些“测不出来就无法交付”的绝境。以下是三个血泪经验换来的判断标尺：

场景一：芯片已流片，但 ATE 测试良率暴跌至 60%

某公司一款通信基带芯片，量产初期良率骤降。ATE 测试显示大量内存块报“读写失败”，但工程师用示波器抓取信号，发现所有时序（tRCD/tRP）都完美达标。问题卡在瓶颈：ATE 设备无法在 800MHz 下稳定生成测试向量，导致内存实际工作在亚稳态边缘，而 ATE 的“慢速扫描”恰好避开了这个雷区。

解决方案：紧急在 mask revision 中加入 MBIST。用 March C+ 算法，在芯片内部以 800MHz 实速运行。结果：MBIST 精准定位出 3 个晶圆批次的工艺偏移点——某些区域的晶体管阈值电压集体漂移，导致转换时间超标。这个结论，ATE 永远给不出。

从那以后，我每次 tape-out 前，都强制走一遍 MBIST 仿真：用ncsim加-input参数注入工艺角（ff/ss/tt），观察 MBIST 是否在所有角下都能通过。哪怕多花两天，也比流片后百万损失强。

场景二：客户要求“开机即自检”，且不允许外挂测试设备

某工业 PLC 模块，客户合同明确：“设备上电 100ms 内，必须完成全部内存自检并上报状态。若失败，LED 红灯常亮，禁止进入运行模式。” 这意味着：

• 不能依赖 Bootloader（启动耗时 > 500ms）；
• 不能外接 JTAG（客户现场无调试器）；
• 不能牺牲实时性（自检不能抢占控制任务）。

解决方案：采用 Mentor 的BIST-IN-Place模式。MBIST 控制器在 reset 释放后，由硬件 FSM 自动启动，全程不消耗 CPU 周期。测试结果通过专用 status 寄存器暴露，主控只需读一次即可。整个流程 85ms 完成，完美履约。

场景三：SoC 集成 37 个异构内存，手工测试脚本维护崩溃

某 AI 加速芯片，集成 SRAM（L1/L2）、ROM（微码）、TCM（紧耦合内存）、NOC 缓存等 37 个内存块，大小从 4KB 到 2MB 不等，接口协议各异（AXI/AHB/Custom）。原先用 Python 脚本生成 ATE 向量，但每次新增一个内存，就要重写脚本、重调时序、重跑仿真，平均耗时 3 天/块。

解决方案：建立统一.atpg库，为每类内存（ARM SRAM IP / Custom ROM）编写标准化模板。用 Makefile 驱动 Mbistarchitect 批量生成：

# Makefile 片段 all: sram_bist rom_bist tcm_bist sram_bist: mbistarchitect -bistgen -dofile sram.do -logfile sram.log -nogui rom_bist: mbistarchitect -bistgen -dofile rom.do -logfile rom.log -nogui tcm_bist: mbistarchitect -bistgen -dofile tcm.do -logfile tcm.log -nogui

新内存加入，只需复制模板、改两行参数（address_size,data_size），make tcm_bist一键生成全部 RTL 和脚本。维护时间从 3 天/块降至 15 分钟/块。

6.2 该放弃 MBIST 的清醒时刻：当投入远大于收益

MBIST 不是银弹。以下三种情况，强行上 MBIST 可能是技术上的“自我感动”：

• 超小内存（< 1Kbit）且无安全要求：例如一个 256×8 的配置寄存器 SRAM。用 4 行 Verilog 的扫描链（scan-in → write → scan-out → compare）即可覆盖所有 stuck-at 故障，面积开销 < 50 门，而 MBIST 控制器至少 2000 门。此时，MBIST 是杀鸡用牛刀。

• 内存内容动态加密，且密钥不落地：某安全芯片，所有 SRAM 存储区均受硬件加解密引擎保护，密钥由 TRNG 实时生成，不存于任何非易失介质。MBIST 的测试向量（明文0/1）会被加密引擎扭曲，导致expect Q move永远失败。此时，应与加解密模块协同设计，提供“测试模式 bypass”路径，而非硬塞 MBIST。

• 芯片已定型，且无 BIST 引脚预留：某成熟产品迭代，仅升级工艺（28nm→12nm），但封装和引脚定义冻结。MBIST 需要至少 2 个专用引脚（bist_mode,bist_done）用于外部触发和状态反馈。若引脚已满，强行复用现有信号（如借用 JTAG TCK）会破坏标准协议，导致产线测试设备无法识别。此时，应接受“无 MBIST”，加强 ATE 测试覆盖率，而非冒险改版。

希望帮到你。

本文还有配套的精品资源，点击获取