CN100456043C

CN100456043C - 检测集成电路的方法和装置

Info

Publication number: CN100456043C
Application number: CNB2004800099204A
Authority: CN
Inventors: 安肯·拉马尼克; 马克·艾尔斯顿; 陈良力; 罗伯·萨乌尔
Original assignee: Advantest Corp
Current assignee: Advantest Corp
Priority date: 2003-02-14
Filing date: 2004-02-16
Publication date: 2009-01-28
Anticipated expiration: 2024-02-16
Also published as: CN1774642A

Abstract

本发明描述一种用于半导体测试系统的分布式操作系统，如自动化测试设备(ATE)。该操作系统包括一用于藉由一系统控制器实现对一个或多个现场控制器进行控制的主操作系统。一个或多个本地操作系统，每个都与一现场控制器相关联，藉由一相关联的现场控制器实现对一个或多个测试模块的控制。每个测试模块在一测试现场执行对一个对应的被测元件的测试。

Description

检测集成电路的方法和装置

技术领域

本发明涉及集成电路(IC)的测试，特别是涉及用于测试一个或多个IC的自动化测试设备(ATE)。

背景技术

本申请案主张以下申请案的优先权：2003年2月24日提出的申请案第60/449,622号，名称为“测试集成电路的方法与装置”；2003年2月14日提出的申请案第60/447,839号，名称为“为半导体集成电路开发测试程序的方法和结构”；2003年3月31日提出的美国申请案第10/404,002号，名称为“测试仿真器、测试模块仿真器、和其中的记录媒体存储程序”；2003年3月31日提出的美国申请案第10/403,817号，名称为“测试装置和测试方法”，上述所有申请在此全文并入以资参考。本申请还全文参考了同时提出的美国申请号10/772,434，名称为“为半导体集成电路开发测试程序的方法和结构”，该申请案主张2003年2月14日提出的申请案第60/447,839号、名称为“为半导体集成电路开发测试程序的方法和结构”的优先权。

芯片系统(system-on-a-chip，SOC)复杂程度的增加和同时存在的降低芯片测试成本的需求，促使IC制造商和测试机供货商重新考虑IC测试应该如何进行。根据行业研究，如果不进行重新设计，测试机的预计成本将在不远的将来显著增加。

测试设备成本高昂的主要原因在于习知测试机架构(architecture)的专用性。每个测试机制造商都拥有若干个测试机平台，其不仅在不同公司如Advantest、Teradyne和Agilent之间互不兼容，而且在平台之间也互不兼容，如Advantest公司制造的如T3300、T5500和T6600系列测试机。由于这些不兼容性的存在，每台测试机都要求其自身专用的、不能用于其他测试机的硬件和软件组件。此外，将测试程序(test program)由一台测试机转移到另一台测试机需要大量的转译工作，并且第三方解决方案也难以开发。即使为某一平台开发了第三方解决方案，其也不能在不同的平台上转移或再利用。由一个平台到另一个平台的转译过程通常是复杂且易于出错的，导致额外的努力、时间和测试成本增加。

测试机软件如操作系统和测试分析工具/应用程序在主计算机(hostcomputer)上运行。由于架构的专用性质，对于一台给定的测试机来说所有的硬件和软件都保持固定配置。为了测试IC，已经开发出了使用测试机能力的部分或全部的专用测试程序，其被用来定义测试数据、信号、波形和电流与电压准位，还被用来采集DUT(被测元件)(device under test)响应并确定DUT是否合格/不合格。

因为测试机应该能够测试多种不同的IC，硬件和软件组件都被设计为在一宽操作范围内工作。因此，测试机包含了许多在很多测试情况下不会使用的资源。同时，对于给定的IC，测试机可能提供不了适合于该IC最需要的资源。例如，可能会发现，一逻辑电路测试机可能适合于测试含有内置微处理器、大型内置DRAM和闪存(flash)、以及其他内核如PCI和USB等的复杂芯片系统A(SoC A)，但是对于不含有内置微处理器和大型内置DRAM/闪存却包括数模转换器(Digital/Analog Converters，DACs)和西格马-德耳塔转换器(Sigma-Delta converters)的特殊应用IC B(Application Specific Integrated Circuit B，ASIC B)的测试却是不够的。为了测试ASIC B，合适的测试机应该会需要模拟和混合信号测试单元更胜于对内置存储器测试的广泛支持。

因此，需要提供一种能够根据测试要求重新配置(reconfigured)的测试机。此外，还需要连接和使用其他供货商的设备与自动化测试设备结合使用。但是，由于习知的测试系统的专用性和每个供货商设备中数据格式(data format)的专有性，通常不可能即插即用另一供货商的设备。

发明内容

本发明实施例的开放架构测试系统(open architecture test system)允许使用第三方模块(third party modules)。该测试系统的硬件和软件框架包括标准接口(standard interface)，藉由这些标准接口能够使来自不同供货商的模块以即插即用的方式互动。这些模块可以是硬件，如功能单元(functional unit)、数字插针卡(digital pin card)、模拟卡(analogcard)、或设备电源(device power supply)；也可以是软件，如工具软件或实用程序，包括测试执行工具(test executive tool)、系统监测(systemmonitoring)或注册工具(licensing tool)，单元级别控制器(unit-levelcontroller)(例如：基本仪器、GPIB控制)、数据库、或用于控制其它设备的软件。

在一实施例中，该架构是一种Microsoft Windows操作系统下的分布式对象环境(distributed object environment)。测试机是一种模块化系统，具有模块控制软件(module control software)和一个背板通信库(backplane communications library)，其允许模块到模块的通信和控制器到模块的通信。这些模块包括，例如，数字模块(digital module)、设备电源(Device Power Supply，DPS)模块、任意波形发生器(ArbitraryWaveform Generator，AWG)模块、数字化仪模块(digitizer module)和专用应用软件(application specific software)。

在一实施例中，模块连接启用器(enabler)包括一可提供多模块连接和同步机构(synchronization mechanism)的开关矩阵网络(switch matrixnetwork)。当测试同一类型的多个DUT(被测元件)时，此开关矩阵网络还允许在多个控制器和测试现场之间共享公共测试数据(common test data)。

由于每个现场具有独立的现场控制器(site controllers)，所有测试现场都能够非同步运行。这样实际上有助于多个DUT测试。此种模块化和多现场组态还为系统提供可扩缩性(scalability)。在该系统的一实施例中，单一的控制器可以被组态为控制并测试多个DUT。

在硬件和软件层面都使用标准接口有助于即插即用(plug-and-play)或可替换模块(replaceable modules)概念的实现。在软件中，框架类(framework class)被用于模块的起动、激活、控制和监测。框架(framework)是一组可实现公共测试相关操作的类和方法。其包括用于下列各项的类(classes)：电源供电和插针电子仪定序(pin electronics sequencing)、设定电流/电压准位和计时条件、获取测量结果、控制测试流(test flow)，等等。框架还提供运行期服务(runtime service)和除错方法(debugging)。框架对象可以藉由执行根据本发明一实施例标准接口来工作。提供了一种基于C++的框架类的参考执行实例。用户还能够开发自己的专用框架类。

藉由背板通信库获得硬件-软件的连接和通信。借助基于C++语言的测试程序和C++之上的GUI测试程序层来存取的开放背板通信库(openbackplane communication library)为测试系统提供一通用用户接口。美国专利申请案第60/447,839号公开了使用C/C++构造生成测试程序的方法。通信库提供一种机制，以对用户应用程序和测试程序为透明的方式与现场控制器进行通信。本质上，背板通信库提供了试图在整个测试机背板进行通信的接口(在本文中，“背板”(backplane)是一个抽象概念，并不一定指实体硬件背板)，从而提供与连接到某一特定现场的模块进行通信所需要的功能。对这种库的使用使得模块供货商无需创建自身的驱动程序(如MS-Windows驱动程序)。这就使特定供货商的模块软件能够使用标准背板驱动软件与对应的硬件模块进行通信。在一实施例中，背板通信协议(backplane communications protocol)使用基于数据包(packet)的格式。

开放架构的一个优点在于它使整体的测试机使用得到了简化。它提供了一种开发第三方解决方案和重新利用这些解决方案而不需要较大改写的机制。对于许多给定的测试现场，能够根据需要来选定并使用合适的模块。因为模块是可更换的，所以每个测试现场都能够被重新组态(reconfiguration)以便实现对DUT的最佳测试。它还简化了平台间不兼容性的问题。所有这些简化使得工作强度的降低、周转时间加快并最终导致测试成本的降低。

本发明提供一种用于测试至少一个被测元件(DUT)的系统。该系统包括至少一个现场控制器，其用于控制至少一个测试模块以便对至少一个DUT执行至少一个测试(该测试可以是一个测试计划的构成部分)。一个系统控制器控制所述至少一个现场控制器。

测试模块接口对测试模块功能进行定义以便将现场控制器与第一测试模块连接，其中该测试模块接口可扩展以便将现场控制器与第二测试模块连接，非扩展测试模块接口不能够足以将现场控制器与第二测试模块连接。

该系统还包括一可扩展测试功能，如用户可定义测试类(user-definable test class)，其独立于专用DUT特性。测试就是对该可扩展测试功能的实现。

测试模块可利用测试机插针接口与DUT通信，其可独立于专用DUT特性。该测试模块接口可包括一测试模块接口类(test module interfaceclass)并且该测试机插针接口可包括一测试机插针接口类(tester pininterface class)。

本发明一实施例的分布式操作系统包括一个主操作系统(hostoperating system)和至少一个与每个现场控制器相关联的本地操作系统(local operating system)，其中该主操作系统能够藉由一系统控制器对至少一个现场控制器进行控制，至少一个现场控制器并不共享一个公共时钟，且该至少一个本地操作系统能够藉由一相关联的现场控制器对至少一个测试模块进行控制，该相关联的现场控制器控制至少一个测试模块以即插即用的方式和该相关联的现场控制器互动，其中至少一个测试模块对一个对应的被测元件执行测试。

该主操作系统可同步这些至少一个现场控制器的操作，仲裁该系统控制器和这些至少一个现场控制器之间的通信，并监测这些至少一个现场控制器的操作。现场控制器可监测与该现场控制器相关联的这些测试模块的操作。

主操作系统包括至少一个主接口，其用来与至少一个现场控制器进行通信。测试模块接口定义测试模块功能以便将现场控制器与第一测试模块连接，其中该测试模块接口可扩展以便将现场控制器连接到第二测试模块，非扩展的测试模块接口不能够足以将现场控制器连接到第二测试模块。

主操作系统可包括至少一个主框架类(host framework class)，其可采用标准计算机语言(例如：C/C++)开发，使用户能够开发专用应用程序类以便控制这些至少一个现场控制器。

每个本地操作系统可包括至少一个本地框架类(local frameworkclass)，其可采用标准计算机语言(C/C++)开发，使用户能够开发专用应用程序类以便控制这些至少一个测试模块。

每个现场控制器可控制的模块的数量是可缩放(scalable)的。与对应的现场控制器相关联的本地操作系统使现场控制器控制的测试模块的类型能够被重新组态。主操作系统使系统控制器控制的现场控制器的数量能够被缩放，并且使测试系统测试的DUT的数量能够被缩放。

仿真器(emulator)可模拟候选测试模块(candidate test module)在测试系统中的使用，以证实候选模块与测试系统兼容。

附图说明

图1所示为习知的测试机架构。

图2所示为根据本发明一实施例的系统架构。

图3所示为根据本发明一实施例的软件架构。

图4所示为对根据本发明一实施例的测试类的使用。

图5所示为根据本发明一实施例的测试机系统和不同供货商提供的模块资源之间互动的通用建模语言(UML)的示意图。

图6所示为由现场控制器维护的用于管理用户测试的现场控制器对象的实施例。

图7所示为在系统控制器一侧代表图6所示现场控制器对象的对象代理的实施例。

图8所示为根据本发明一实施例的测试环境。

具体实施方式

图1所示为习知的测试机通用的架构，显示了信号是如何生成并施加给待测元件(DUT)的。每一个DUT输入插针都连接到应用测试数据的驱动器2，同时每个DUT输出插针都连接到比较器4(comparator)。在大多数情况下，使用三态驱动器比较器(tri-state driver-comparators)，这样每个测试插针(通道)都既能够充当输入插针也能够充当输出插针使用。用于单独某个DUT的测试插针的集合形成一个测试现场(test site)，其与相关联的计时发生器6(timing generator)、波形发生器8(waveformgenerator)、模式存储器10(pattern memory)、计时数据存储器12(timingdata memory)、波形存储数据14(waveform memory data)和定义数据速率(data rate)的块16(block)协同工作。

图2所示为根据本发明一实施例的系统架构100。系统控制器(SysC)102耦接到多个现场控制器(SiteCs)104。系统控制器还可耦接接到一个网络以便存取相关文件。借助模块连接启用器106(module connection enabler)，每个现场控制器都被耦接以便控制一个或多个位于测试现场110的测试模块108(test module)。模块连接启用器106允许对已经连接的硬件模块108进行重新组态并且还被用作数据传输总线(用于加载模式数据(patterndata)、收集响应数据(response data)、提供控制，等等)。此外，借助该模块连接启用器，位于一个现场的模块可以存取在另一个现场的模块。模块连接启用器106允许不同的测试现场具有相同或不同的模块组态。换句话说，每个测试现场都可采用不同数量和类型的模块。可能的硬件实现包括专用连接、开关连接、总线连接、环形连接、和星形连接。例如，模块连接启用器106可由开关矩阵实现。每个测试现场110都与一个DUT 112相关联，该DUT 112藉由负载板114(loadboard)连接到对应现场的模块。在一实施例中，单一的现场控制器可连接到多个DUT现场。

系统控制器102充当总系统管理器。系统控制器102协调现场控制器的活动、管理系统级别的平行测试方案、并且还提供处理机/探测器控制以及系统级别的数据记录和错误处理支持。根据操作设定，系统控制器102能够被部署在一独立于现场控制器104的操作的CPU上。或者，普通CPU可由系统控制器102和现场控制器104共享。类似地，每个现场控制器104都能够被布署在其自身专用的CPU(中央处理单元)上，或是在同一CPU中作为一独立的进程或线程。

系统架构可从概念角度想象为图2所示的分布式系统，并且理解单个系统组件还可以被看作是一集成的、单片系统(monolithic system)，并且不一定是分布式系统的一个实体组件。

图3所示为根据本发明一实施例的软件架构200(softwarearchitecture)。软件构架200代表一个分布式操作系统，其具有用于系统控制器220、至少一个现场控制器240和至少一个模块260的元件，这些元件分别与相关的硬件系统元件102、104、108(hardware system elements)相对应。除模块260外，构架200还包括用来在软件中对应模块仿真器280(module emulation)的元件。

作为一示例性的选择，此种平台的开发环境可以基于MicrosoftWindows。使用此种构架在程序和支持便携中还具有附带好处(例如，现场维护工程师可以连接运行测试机操作系统的笔记本电脑以便执行进阶的诊断)。但是，对于运算量大的计算(如测试模式编码)(test patterncomplies)，可以将相关软件设计为能够独立运行以便允许跨分布式平台的作业调度的独立实体。这样用于批量作业(batch jobs)的相关软件工具就能够在多个平台类型上运行。

作为一示例性的选择，可以将ANSI/ISO标准C++作为软件的本机语言。当然，还有多种可选方案(为了提供标称C++接口之上的一个层次)使第三方能够将其自己选择的替换语言集成到系统中。

图3中示出了根据其额定源(nominal source)编制(或作为子系统集体开发)的元件的阴影(shading)，其包括测试机操作系统接口290(testeroperating system interface)、用户组件292(user components)(例如，用户提供的用于测试目的的细件)、系绕组件294(system components)(例如，作为基本连接和通信提供的软件基础结构)、模块开发组件296(moduledevelopment component s)(例如，模块开发商提供的)、和外部组件298(external components)(例如，由模块开发商以外的外部源提供的)。

从基于源的组织(source-based organization)一方面来说，测试机操作系统(Tester Operating System，TOS)接口290包括：系统控制器到现场控制器接口222、框架类224、现场控制器到模块的接口245、框架类246、预定的模块级别接口、背板通信库249、底盘插槽接口(interface，IF)262、负载板硬件接口264、背板仿真接口283、负载板仿真接口285、DUT仿真接口287、用于DUT的Verilog模型的Verilog程序语言接口(ProgrammingLanguage Interface，PLI)288和用于DUT的C++模型的C/C++语言支持289。

用户组件292包括：用户测试计划242(user test plan)、用户测试类243(user test classes)、硬件负载板265(hardware loadboard)、和DUT266、DUT Verilog模型293和DUT C/C++模型291。

系统组件294(system components)包括：系统工具226(system tools)、通信库230(communication library)、测试类244(test classes)、背板驱动器250(backplane driver)、硬件背板261(hardware(HW)backplane)、仿真框架281(simulation framework)、背板仿真282(backplane emulation)、和负载板仿真286(loadboard simulation)。

模块开发组件296(module-development components)包括：模块命令执行实例248(module commands implementation)、模块硬件263(modulehardware)、和模块仿真284(module emulation)。

外部组件298(external components)包括外部工具225(external tools)。系统控制器220(system controller)包括：连接现场控制器的接口222、框架类224、系统工具226、外部工具225、和通信库230。系统控制器软件是用户互动的一等控制点(primary point)。它提供了到本发明现场控制器的入口，提供了在多现场/DUT环境中现场控制器的同步，如本受让人的美国专利申请案第60/449,622号所述。在系统控制器上运行基于图形用户接口(Graphical User Interface，GUI)或其它方式的用户应用程序和工具。系统控制器还可作为所有测试计划相关信息的存储库，包括测试计划、测试模式和测试参数文件(test parameter files)。测试参数文件包含本发明一实施例的面向对象环境中用于测试类的参数化数据。

第三方开发商除标准系统工具226还能够提供其它工具(或作为标准系统工具226的替代)。系统控制器220上的标准接口222包括工具可使用以便存取测试机和测试对象的接口。工具(应用程序)225、226允许测试和测试机对象的互动和批量控制(batch control)。工具包括用来提供自动化能力的应用程序(例如，使用SECS/TSEM等)。

存在于系统控制器220上的通信库230提供一种以对用户应用程序和测试程序透明的方式与现场控制器240通信的机制。

存在于与系统控制器220相关联的存储器中的接口222为系统控制器上执行的框架对象提供开放接口。其中包括允许基于现场控制器的模块软件存取和取回模式数据的接口。其中还包括应用程序和工具可使用以存取测试机和测试对象以及脚本接口(scripting interface)的接口，脚本接口提供藉由脚本引擎(scripting engine)存取和操纵测试机和测试组件的能力。这样就形成了一种使互动、批量(batch)和远程应用程序执行其功能的共用机制。

与系统控制器220相关联的框架类224提供一种与上述这些对象互动的机制，提供一标准接口的参考执行实例。例如，本发明的现场控制器240提供一功能测试对象(functional test object)。该系统控制器框架类可提供一个对应的功能测试代理(functional test proxy)，作为功能测试对象的基于远程系统控制器的代理。这样标准功能测试接口就可以被系统控制器220上的工具所使用。系统、模块开发和接口组件294、296和290分别可被考虑为系统控制器和现场控制器之间分布的操作系统。框架类有效地提供与主系统控制器相关联的开放系统接口。其还构成为现场控制器提供入口的软件元件，并提供多现场/DUT环境中现场控制器的同步。因此本发明一实施例中这个层所提供之对象模型(object model)，其适合于操纵和存取现场控制器而不需要直接处理通信层(communication layer)。

现场控制器240(site controller)容纳有用户测试计划242(user testplan)、用户测试类243(user test classes)、标准测试类244(standardtest classes)、标准接口245(standard interfaces)、现场控制器框架类246(site controller framework classes)、模块高准位命令接口(即，预定模块准位接口)247(module high level command interface)、模块命令执行实例248(module command implementation)、背板通信库249(backplane communication library)、和背板驱动器250。大多数测试功能较佳由现场控制器104/240处理，因此允许测试现场110独立操作。

测试计划242由用户编写。测试计划可直接由标准计算机语言如C++编写，或以更高级别测试程序语言描述以便产生C++代码，然后可将其编译为可执行的测试程序。

测试计划利用框架类246和/或标准的或用户提供的与现场控制器相关联的测试类244创建测试对象，利用标准接口245对硬件进行组态，并定义测试计划流(test plan flow)。其还提供在测试计划执行期间所要求的任何附加逻辑(additional logic)。测试计划支持一些基本的服务并提供到下层对象服务的接口，如除错服务(debug service)(例如，断点)，还提供对下层框架和标准类的存取。

与现场控制器相关联的框架类246是一组类和方法，其执行共同的与测试相关的操作。现场控制器级别框架例如包括用于下列各项的类：电源供电和插针电子仪定序、设定电流/电压准位和计时条件、获取测量结果、控制测试流，等等。框架还提供运行期服务(runtime service)和除错方法。框架对象可以藉由标准接口来工作。例如，TesterPin(测试机插针)框架类的执行被标准化，以便执行测试类可以用来与硬件模块插针互动的通用测试机插针接口(general tester pin interface)。

某此框架对象可在模块级别接口247的帮助下进行工作，从而实现与模块的通信。现场控制器框架类有效地作为本地操作系统接口支持每一个现场控制器。

一般而言，超过百分之九十的程序代码(program code)是用于元件测试的数据，剩下百分之十的代码实现测试方法。元件测试数据取决于DUT的(例如：电源条件、信号电压条件、计时条件等)。测试代码包含将特定元件条件加载到自动化测试设备(Automatic Test Equipment，ATE)硬件的方法，并且还包含实现特定用户对象(如数据记录)所需要的方法。本发明一实施例的框架提供一种独立于硬件的测试和测试机模式，其允许用户执行DUT测试程序化的任务。

为了增加测试代码的可重复使用性，可使此种代码独立于任何元件专用数据(device-specific data)(例如：插针名称、激励数据(stimulusdata)等等)或任何元件测试专用数据(device-test-specific data)(例如：直流(DC)单元的条件、测量插针、目标插针的数量、模式文件的名称、模式程序的地址)。如果测试用代码是采用这些类型的数据编译的，那么该测试代码的可重复使用性就会下降。因此，根据本发明一实施例，测试代码可从外部获得任何元件专用数据或元件测试专用数据，如在代码执行时间期间输入。

在本发明一实施例中，一个测试类(Test Class)是一标准测试接口的建构，在这里用ITest表示，其实现测试数据与用于某一特定类型测试的代码(及由此产生的代码的可重复使用性)的分离。此种测试类可被看作是其自身分离实例的“模板(template)”，其仅在元件专用和/或元件测试专用数据的基础上互不相同。测试类在测试计划文件中规定。每个测试类典型地执行元件测试的专用类型或元件测试的设定。例如，本发明一实施例可提供ITest接口的专用执行，例如，FunctionalTest(功能测试)，作为DUT所有功能测试的基础类(base class)。它提供以下基本功能：设定测试条件、执行模式和根据失败选通(failed strobes)的存在确定测试状态。其他执行的类型包括交流(AC)和直流(DC)测试类、在这里用ACParametricTests和DCParametricTests表示。

所有的测试类型都提供某些虚方法(virtual method)的预设执行(default implementation)(例如：init() ，preExec()，和postExec())。这些方法成为测试工程师越过预设行为和设定任何测试专用参数的进入点。但是，测试计划中还可以使用定制的测试类(custom test classes)。

测试类允许用户藉由提供用于规定该测试的特定实例的选项的参数对类行为(class behavior)进行组态。例如，功能测试(Functional Test)可采用参数PList和TestConditions来分别规定将要执行的模式列表(Pattern List)和测试的级别(Level)和计时(Timing)条件。为这些参数规定不同的值(借助测试计划描述文件中不同“测试”模块的使用)，使用户能够生成功能测试的不同实例。图4说明如何从单一测试类产生不同的测试实例。可采用模板库(Template Library)作为通用算法和数据结构的通用库(general-purpose library)。该库对于测试机的用户是可见的，这样用户例如可以修改测试类的执行，以便创建用户定义的测试类。

对于用户开发的测试类，由于所有测试类都是来源于一单一测试接口(例如，Itset)，因此系统的一实施例支持将这种测试类集成入框架，从而该框架能够以与标准组的系统测试类相同的方式对其进行操作。用户可将额外的功能随意地并入其测试类，只要理解在其测试程序中必须使用自定义码(custom code)以便利用这些额外的功能。

每个测试现场110都专用于测试一或多个DUT 106，且藉由一组可配置的测试模块112来运行。每个测试模块112都是一个执行一项特定测试任务的实体。例如，测试模块112可以是DUT电源、插针卡、模拟卡等等。这种模块手段提供调试的灵活性和可配置性。

模块命令执行(Module Commands Implementation)类248可由模块硬件供货商提供，并且或者为硬件模块执行模块级接口(module-levelinterfaces)，或者提供标准接口的专用模块执行，这取决于供货商选定的命令执行方法。这些类的外部接口由预定的模块级接口要求和背板通信库要求而预先确定。这一层次还提供标准测试指令集(standard set of testcommands)的扩展，允许增加方法(功能)和数据元(data elements)。

背板通信库249(Backplane Communications Library)为整个背板的标准通信提供接口，从而提供与连接到测试现场的模块进行通信所必要的功能。这样就允许特定供货商模块软件能够使用背板驱动器250(BackplaneDriver)与对应的硬件模块通信。背板通信协议可采用基于数据包的格式。

测试机插针(Tester Pin)对象代表物理测试机通道(physical testerchannels)并来源于测试机插机接口，这里以ITesterPin表示。本发明一实施例的软件开发工具包(Software Development Kit，SDK)提供预设的ITesterPin执行，可被称为TesterPin，其依据预定的模块级接口IChannel执行。供货商如果能够依据IChannel执行他们的模块的功能，就可自由使用TesterPin；否则，他们必需提供ITesterPin的执行以便能够使用他们的模块工作。

本发明的测试机系统提供的标准模块接口(standard moduleinterface)在这里用IModule表示，其普遍地代表供货商的硬件模块。供货商为系统提供的特定模块软件可以是以可执行的形式提供，如动态链接库(Dynamic Link Libraries，DLL)。为供货商的每种模块类型提供的软件可以装于单一的一个动态链接库(DLL)中。每个这种的软件模块都负责提供用于模块接口命令的特定供货商的执行，其包括用于模块软件开发的应用程序接口(Application Programming Interface，API)。

模块接口命令存在两个方面：首先，他们被用于用户与系统中某一特定硬件模块的通信(间接地)；其次，他们提供可被第三方开发人员用来将自己的模块集成到现场控制器级框架中的接口。因此，框架提供的模块接口命令分为两种类型：

首先，最显而易见的是这些“命令”，其藉由框架接口显露给用户。因此，测试插针接口(ITesterPin)提供取得并设定级别和计时值的方法，而电源接口(IPowerSupply)提供例如供电(powering up)和断电(powcringdown)的方法。

此外，框架提供预定的模块级接口(module-level interface)的特定目录，其可被用于与模块的通信。这些都是框架类(例如：框架接口的“标准”执行)用来与供货商模块通信的接口。

但是，在第二方面，对模块级接口的使用是可选的。这样做的好处是供货商可以利用如ITesterPin和IPowerSupply等的类的执行，同时藉由执行模块级接口将重点放在发送到供货商硬件的特定消息的内容。但是，如果这些接口不适用于供货商，他们可以选择提供他们自己的框架接口的定制执行(例如：ITesterPin、IPowerSupply等的供货商执行)。于是，这些就会提供适合于他们的硬件的定制功能(custom funtionality)。

因此可以藉由两种不同手段实现特定模块供货商软件的集成：相关框架类和接口的定制执行(custom implementation)，或模块级接口特定目录的定制执行。

下面在图5中展示了两种方法的应用程序实例，图5是描述本发明实施例的测试机系统和供货商的模块互动的通用建模语言(UnivcrsalModeling Language，UML)类的示意图。

一个新的数字模块供货商，即第三方A(Third Party A，TPA)，提供软件模块用来与其硬件模块进行通信。该软件模块会执行标准接口IModule。这里将该模块对象称作TPAPinModule。供货商TPA能够藉由在其模块中实现相关的预定模块级接口(在此情况下为IChannel)来利用ITesterPin接口的标准系统执行，这里标记为TesterPin。由于TesterPin使用校准预定模块级接口如IChannel与模块进行通信，因此上述是可以做到的。因此，TPAPinModule仅通过创建并显露TesterPin对象就可以提供插针。

下面考虑这样一种情况：另一个供货商，即第三方B(Third Party B，TPB)，认为IChannel不能与其的硬件很好地工作。因此，TPB不仅需要提供他自己的IModule执行(TPBPinModule)，而且还需要提供ITesterPin接口TPBTesterPin的执行。

这种方案给予第三方开发人员在选择如何发开其硬件和支持软件方面极大的灵活性。尽管要求他们执行IModule接口，但是他们可以选择执行他们认为合适的模块级接口或执行对象，例如TesterPin。

事实上，供货商为了提供在ITesterPin接口中不被支持的扩展(extensions)，而可选择执行TesterPin。框架会向用户提供检索到某个对象的特定接口或执行指针的机制。这意味着当用户代码具有ITesterPin指针时，如果需要的话，框架就能够确定其是否指向TPBTesterPin对象。(注意这一特点可藉由标准C++运行时类型识别(Run Time TypeIdentification，RTTI)提供)。换言之，当测试计划访问(calls on)ITesterPin接口时，该接口可直接调用供货商的TesterPin类的测试机插针执行，其併入特定模块信息(例如：将被设定为提供特定DUT刺激物(stimulus)的寄存器地址)。

总之，尽管框架代码总使用ITesterPin接口，但是用户仍然能够根据需要自由利用模块供货商所提供之特定特点(specific features)和扩展(extensions)。换言之，模块供货商能够，例如，将方法(功能)增加到类的标准系统执行中。对于用户的折衷是利用特定供货商扩展使测试代码对其他供货商的模块的可用性下降。

在模块级中，系统100标称上具有两种操作模式。在线上操作模式(online mode)中，使用模块元件260(module elements)(例如：硬件元件)；而在脱机操作模式(offline mode)中，使用软件模块仿真280。

对于线上操作模式，模块元件260包括硬件背板261(HardWare，HW)、底盘插槽接口262(chassis slot interface)、模块硬件263(module hardware)、负载板硬件接口264(loadboard hardware interface)、硬件负载板265(hardware loadboard)、和待测元件(DUT)266。

对于脱机操作模式，软件模块仿真器280(module emulation insoftware)包括模拟框架281(simulation framework)、背板仿真器282(backplane emulation)、背板仿真接口283(backplane emulationinterface)、模块仿真器284(module emulation)、负载板仿真接口285(loadboard simulation interface)、负载板仿真器286(loadboardsimulation)、和待测元件仿真接口287(DUT simulation interface)。图中示出两个用于DUT仿真的模型。一个模型使用Verilog，包括Verilog程序语言接口288(Programming Language Interface，PLI)和待测元件Verilog模型293。一个模型使用C/C++，其包括C/C++语言支持289和待测元件C/C++模型291。注意该仿真可以在任何计算机上执行，例如个人电脑(Personal Computer，PC)。

在线上模式中，模块供货商提供物理硬件组件支持测试，如数字测试机通道(digital tester channels)、DUT电源、或DC测量单元(DCmeasurement units)。模块藉由底盘插槽接口262与硬件背板261连接。

对于脱机模式，基于PC或其他运行等同于系统控制器(SystemController)的环境，附加地承担所有提供现场控制器级框架和软件下层的运行时环境，以及仿真硬件。

背板仿真器282(backplane emulation)为物理背板261(physicalbackplane)提供软件代理(surrogate)。其藉由背板仿真接口283与(供货商提供的)模块仿真软件284(module emulation software)进行通信。

模块仿真软件284最好是由模块供货商提供，并且是典型地与模块263的特定供货商执行紧密捆绑。因此，在不同供货商提供的全部模块中，模块仿真软件会典型地在细节上有所不同。这种情况下，模块仿真允许供货商藉由软件模型(software model)(例如：模块仿真软件284)显露硬件功能，将仿真信号送至仿真负载板286，并接收和处理来自仿真负载板286的DUT响应信号，该仿真负载板286藉由待测元件仿真接口287连接到DUT模型软件291、293。在一些情况下，供货商可能会发现提供模块的简单功能仿真和避开对模块固件(module firmware)的仿真是有利的。模块仿真软件将仿真DUT对仿真模块仿真信号的响应与已知的好的DUT响应进行比较。根据这一比较结果，软件确定模块执行的测试是否符合需要的测试DUT的目标，并且帮助用户在线上物理测试机上的IC(物理DUT)上使用模块前对该模块进行除错。

负载板仿真接口285作为信号进出模块仿真层(module emulationlayer)和仿真负载板286(simulated loadboard)的通路。负载板模拟组件286(loadboard simulation component)支持元件插座映射和进出DUT仿真接口287的信号传播。

DUT仿真可以是本机代码仿真291(native code)(即，C/C++)，或是到目标被测元件293的功能模型的Verilog程序语言接口(ProgrammingLanguage Interface，PLI)。该模型藉由DUT仿真接口287与仿真负载板连接。

注意对这些层的整体控制是由仿真框架281(simulation framework)提供的。仿真框架响应已知仿真信号对仿真DUT进行测量。系统仿真的方法在美国专利案10/403,817号中公开。

通信和控制

通信和控制是藉由相关软件对象的管理实行的。较好的是，通信机制隐藏于系统控制器上的对象模型(object model)之后。该对象模型为在现场控制器上找到的类和对象提供一个代理(proxy)，并为应用程序开发(例如：IC元件测试)提供方便的编程模型(programming model)。这样使应用程序开发商(例如：自动化测试设备(ATE)系统用户)避免与应用程序和现场/系统控制器之间通信的细节相关的不必要的细节(unnecessarydetails)。

图6所示为现场控制器软件240(site controller software)中由现场控制器104维护的现场控制器对象的特定实施例。现场控制器对象包括CmdDispatcher 602、FunctionalTestMsgHandler 604和FunctionalTest606。接口包括IMsgHandler 608和ITest 610。

现场控制器软件240较佳包含应用程序存取可能会需要的所有功能类。这些类可以包括，例如，测试、模块、插针等等。由于用户测试和软件工具典型地驻留在不同的计算机上，消息会由系统控制器上的工具被发送到现场控制器上的服务器(server)。该服务器将调用命令调度(CommandDispatch)对象上的方法。

命令调度对象(CmdDispatcher)602维持报文处理程序(messagehandler)对象的映射(map)，其执行IMsgHandler接口608。图6所示为IMsgHandler、FunctionalTestMsgHandler 604的特定执行。CmdDispatcher对象602收到的报文(messages)包含要通信的对象的标识符(identifier)。该标识符在内部映射(internal map)中被找到，其解决特定的执行，在这里示出的是FunctionalTestMsgHandler对象604。

在本例中，IMsgHandler 608由单一方法handleMessage()构成。该方法较佳是作为单一执行类执行。在图中所示的情况中，FunctionalTestMsgHandler604将根据传入消息的确切性质将报文转发到六个方法之一。输入报文的报头(header)包含报文标识(id)，其允许报文处理程序决定如何解释以及向何处发送该报文。

在系统控制器102中对应的通信环境涉及系统控制器软件220的工具225、226部分。图7所示为系统控制器软件220中的系统控制器102上维护的工具对象(或系统控制器对象)的实施例，其与图6所示的现场控制器对象对应。该工具对象包括时象CmdDispatcher 702、FunctionalTestMsgHandler 704和FunctionalTestProxy 706。接口包括IMsgHandler 708、ITestClient710、和IDispatch 712。还包括实用应用程序714。

对于本例来说，此类CmdDispatcher 702、IMsgHandler 708、和FunctionalTestMsgHandler 704与图6中的相同。但是，没有使用FunctionalTest 606(或其他现场控制器类)的例示(instantiation)。取而代之的是，工具对象具有与现场控制器104上的每个对象通信的代理类(proxy classes)。因此，例如，工具对象包括取代FunctionalTest 606的类FunctionalTestProxy 706。类似地，在工具对象中的ITestClient 710与现场控制器对象中的ITest 610不同。总体上，在系统控制器102上运行的应用程序不会使用现场控制器104上提供的精确接口。在这种情况下，用ITestClient 710(即runTest())中的单一方法取代三个方法ITest610(即preExec()，execute()，和postExec())。此外，ITestClient 710较好的是双接口(dual interface)；即，它由IDispatch 712继承而来，IDispatch712作为Microsoft组件对象模型(Component Object Model，COM)执行。它提供使脚本引擎(scripting engine)能够存取执行该接口的对象。这就允许系统在Microsoft Windows平台上是可脚本编程(scriptable)的。

作为图6-7中所示实施例的操作实例，在系统控制器102(例如，在工具部分226、228中之一)上运行的应用程序可在测试计划242包括一个或多个FunctionalTest对象606的情况下，与现场控制器104进行通信。测试计划242在现场控制器104上的初始化期间，对应的测试计划对象被加载到现场控制器104，其构成TestPlanMessageHandler对象并用CmdDispatcher对象602将其注册。这样为报文处理程序赋予一个唯一标识(ID)。类似的操作也在构成测试计划242的其他TestPlan对象中发生。

系统控制器103上的应用程序(例如，在工具226、228中)将通信库230初始化，藉由通信信道(communication channel)连接到现场控制器104，并为TestPlan对象获得一个标识(ID)。该库构成一TestPlanProxy对象并用该标识(ID)将其初始化。在初始化期间，该代理对象确定其包含多少个测试以及这些测试的类型和标识(ID)。它为每种类型(这里仅有一种类型)加载适当的动态链接库(DLLs)并为它们构成代理对象(proxy objects)，利用他们的标识(ID)值将他们初始化。

接着测试代理对象(Test Proxy Objects)也进行初始化。为此测试代理对象构成适当的报文以便得到他们名称(利用其的ID值)并将其发送到位于现场控制器104的通信服务器(communication server)，现场控制器104将报文传递给CmdDispatcher 602。该对象在其内部映射中寻找目的标识(destination IDs)并将该报文传送到FunctionalTestMsgHandler对象604的handleMessage()方法。例如，如果该报文(message)是获得测试名称之请求，这些对象得到他们的相应的测试名称，并利用适当的名称串(appropriate name strings)回复(reply)应用程序的测试代理对象。

初始化完成后，应用程序可远程存取一TestPlan对象，并且通过该TestPlan对象存取所有两个测试对象。用户现在可按下应用程序上的，例如，“Run Test Plan(运行测试计划)”按钮。结果，应用程序调用测试计划代理对象(test plan proxy object)上的RunTestPlan()方法。该方法利用测试计划对象的目的标识(ID)构成RunTestPlan报文，并调用远程过程调用代理(Remote Procedure Call proxy，RPC proxy)的sendMessage()函数，该远程过程调用(RPC)代理将报文送到现场控制器。

现场控制器104上的通信服务器调用CmdDispatcher对象602上的handleMessage()方法，并向其传递测试计划对象的标识(ID)。CmdDispatcher对象602在其内部映射中寻找该标识(ID)，找到TestPlan对象的报文处理程序并调用该对象上的handleMessage()，而该对象调用TestPlan对象上的RunTestPlan()。应用程序采用类似的方法能够得到名字和测试对象的最后运行状态。

通信库的使用方法

以下是使用通信库230的一个例子。

通信库230较佳是一个静态库(static library)。应用程序能够藉由CommLibrary.h文件使用这种通信库。需要输出通信库类的应用程序应该具有预处理器定义(preprocessor definitions)如COMMLIBRARY_EXPORTS、COMMLIBRARY_FORCE_LINKAGE，其由除了包括上述包含之文件而定义。输入通信库的应用程序不需要定义任何预处理器定义。当通信库被用作服务器时，应用程序必需调用下面的CcmdDispatcher的静态函数：InitializeServerunsigned long portNo()。

此portNo是服务器应该正在收听的portNo。与服务器对应的命令调度器(command dispatcher)可以藉由调用以下静态函数而检索：在CCmdDispatcher类上的getServerCmdDispatcher。

当通信库被用作客户端时，应用程序应该调用以下CcmdDispatcher之静态函数：

InitializeClientconst OFCString serverAddress，

unsigned long serverPortNo，

CcmdDispatcher**pCmdDispatcher，

OFCString serverId)

该客户端必需连接serverAddress和ServerPortNo。该函数为了客户端和已经连接到该客户端的serverId，而初始化命令调度器指针(commanddispatcher pointer)。还有在较晚的时刻，该客户端可以借助调用静态函数getClientCmdDispatcher检索与serverId对应的命令调度器。

当通信库被编译时，该建构(build)已经被排除在文件ClientInterface.idl和ServerInterface.idl之外。较佳实施例采用为这些接口定义文件(interface definition files)已经创建的存根(stub)和代理文件(proxy files)，以便将代理(proxy)与存根执行文件(stubimplementation files)链接到同一库中。如此，服务器和客户端能够在同一地址空间中被例示。较好的地对接口定义文件和存根文件中进行如下改变，使作为服务器的通信库与客户端处于相同的地址空间。

接口定义文件的改变

以下是较佳加入每个接口定义文件中的命名空间声明(namespacedeclaration)。这样是为了避免代理执行函数(proxy implementationfunctions)和我们自己的接口函数的执行之间产生名称冲突(namecollision)。下面的命名空间声明被加入serverInterface.idl

cpp_quote(″#ifdef_cplusplus″)

cpp_quote(″namespace COMM_SERVER″)

cpp_quote(″{″)

cpp_quote(″#endif″)

cpp_quote(″}″)

改变存根执行文件(stub implementation file)中的函数以便调用我们自己的执行函数从而执行接口中所声明的函数，即，我们具有对应于在接口中声明的函数中的每一者的不同命名的函数。

为了避免函数调用中的冲突，较佳将执行函数的名称预定固定为“COMM_”串。因此将存根函数中的代码改变而调用“COMM_functionName”而非“functioname”。

为了使该方法能够生效，所有存在的函数类都应该还具有其自己的对应报文处理程序对象和代理类。所有报文处理程序对象都应该从通信库提供的IMsgHandler类中取得。IMsgHandle类是一个抽象类(abstractclass)。较好的是由报文处理程序的执行器负责为handleMessage、setObjectId、handleError提供一个定义。所有报文类型都应从1开始(0为handleErro保留)。函数类较好的是具有其自己的对应报文处理程序作为他们的成员变量(member variable)。在函数类的构造器(constructor)中，函数类应该藉由调用报文处理程序(message handler)提供的函数而利用报文处理程序将其自身注册。接下来报文处理程序对象(messagehandler object)应该藉由命令调度器(command dispatcher)而注册，此命令调度器调用其上的addMsgHandler函数，并以报文处理程序为参数(parameter)。此addMsgHandler函数会为报文处理程序和函数类分配一个标识(ID)。函数类的破坏器(destructor)应该将函数类标识(functionclass identifier)作为参数发送，从而调用命令调度器上的removeMsgHandler函数。代理类也应该遵循与上述的函数类相同的注册程序。

下面的CTestPlan类显示了依据本发明的较佳实施例的典型的函数类。

File：-TestPlan.h

Class CTestPlan

{

private：

unsigned long m_Id；

CTestPlanMsgHandler m_tplMsgHandler；

}

File：-TestPlan.cpp

extern CcmdDispatcher*g_pCmdDispatcher；

CTestPlan::CTestPlan

{

m_tplMsgHandler.setTestPlan(this)；

g_pCmdDispatcher.AddMsgHandler(&m_tplMsgHandler)

}

CTestPlan::～CTestPlan

{

g_pCmdDispatcher.removeMsgHandler(m_Id)

}

此g-pCmdDispatcher对象应藉由调用被通信动态链接库(DLL)显露的getCmdDispatcher()而初始化。下面的CTestPlanMsgHandler类显示了典型的报文处理程序(message handler)。

File：-TestPlanMsgHandler.h

Class CtestPlanMsgHandler：public IMsgHandler

{

public：

setTestPlan(CTestPlan*pTestPlan)；

setTestPlanProxy(CTestPlanProxy*pTestPlanProxy)；

void handleMessage(unsigned long msgType，

unsigned long senderId，

unsigned long senderMsgLen，

byte*pSenderMsg)

void handleSetName(unsigned long senderId，

unsigned long senderMsgLen，

byte*pSenderMsg)；

void handleGetName(unsigned long senderId，

unsigned long senderMsgLen，

byte*pSenderMsg)；

private：

CTestPlan m_pTestPlan；

CTestPlanProxy m_pTestPlanProxy；

typedef void(CFuncTestMsgHandler::*handlerFn)(unsigned long，

unsigned long，byte*)；

std::map<int，handlerFn>m_handlers；

}

File：-TestPlanMsgHandler.cpp

CTestPlanMsgHandler::CtestPlanMsgHandler

{

m_handlers[HandleError]＝handleError；

m_handlers[GetName]＝handleGetName；

m_handlers[SetName]＝handleSetName；

}

void

CTestPlanMsgHandler::handleMessage(unsigned long msgType，

unsigned long senderId，

unsigned long senderMsgLen，

byte*pSenderMsg)

{

if(msgType＝0)

{

handleError(senderId，senderMsgLen，pSenderMsg)；

}

else

{

handlerFn fn＝NULL；

hIter_t fIter；

fIter＝m_handlers.find(msgType)；

if(fIter＝m_handlers.end())

{

return；

}

fn＝fIter-＞second；

if(NULL！＝fn)

{

(this-＞*fn)(senderId，senderMsgLen，pSenderMsg)；

}

void

CTestPlanMsgHandler::handleSetName(unsigned long senderId，

unsigned long senderMsgLen，

byte*pSenderMsg)

{

if(m_pTestPlanProxy！＝NULL)

{

OFCString tplName＝ByteToString(senderMsgLen，

pSenderMsg)

m_pTplProxy-＞setName(tplName)；

}

void

CTestPlanMsgHandler::handleGetName(unsigned long senderId，

unsigned long senderMsgLen，

byte*pSenderMsg)

{

OFCString testName；

if(m_pTestPlan ！＝NULL)

{

unsigned long 1_destId

unsigned long 1_msgType；

unsigned long 1_senderId；

unsigned 1_senderMsgLen；

byte*1_senderMsg＝NULL；

if(m_pTestPlan-＞getName(testName)！＝true)

{

//If a failure has occurred Send error message

char*errorString＝“Error retrieving name”；

1_destId＝senderId；

1_msgType＝HandleError；

1_senderId＝m_Id；

1_senderMsgLen＝strlen(errorString)；

1_senderMsg＝StringToByte(errorString)；

sendMsg(1_destId，

1_msgType，

1_senderId，

1_senderMsgLen，

1_senderMsg)；

return；

}

1_destId＝senderId；

1_msgType＝SetName；

long 1_senderId＝m_Id；

1_senderMsgLen＝testName.length()；

1_senderMsg＝NULL；

StringToByte(testName，&1_senderMsg)；

sendMsg(1_destId，

1_msgType，

1_senderId，

1_senderMsgLen，

1_senderMsg)；

DELETE_BYTE(1_senderMsg)；

}

void

CTestPlanMsgHandler::handleError(unsigned long senderId，

unsigned long senderMsgLen，

byte*pSenderMsg)

{

OFCString errorString；

ByteToString(senderMsgLen，pSenderMsg，errorString)；

m_pTestPlanProxy-＞setError(errorString)；

}

以下CTestPlanProxy类显示了一个典型代理类的外部特征。

File：-TestPlanProxy.h

Class CTestPlanProxy

{

CTestPlanProxy(unsigned long serverId)；

～CTestPlanProxy()；

private：

CTestPlanProxy()；

unsigned long m_Id；

unsigned long m_serverId；

CTestPlanMsgHandler m_tplMsgHandler；

}

File：-TestPlanProxy.cpp

extern CcmdDispatcher*g_pCmdDispatcher；

CTestPlanProxy::CTestPlanProxy(unsigned long serverId)

{

m_serverId＝serverId；

m_tplMsgHandler.setTestPlanProxy(this)；

g_pCmdDispatcher.AddMsgHandler(&m_tplMsgHandler)

///initialize the proxy with its name.

unsigned long msgType；

unsigned long senderMsgLen；

byte*pSenderMsg＝NULL；

msgType＝GetName；

senderMsgLen＝0；

pSenderMsg＝NULL；

sendMsg(m_clientId，

msgType，

m_Id，

senderMsgLen，

pSenderMsg)；

//Check if the error string has been set by the message handler.

if(m_errorString.length()！＝0)

{

OFCString errorString＝m_errorString；

m_errorString＝″″；

throw exception(errorString.c_str())；

}

CTestPlanProxy::～CTestPlanProxy

{

g_pCmdDispatcher.removeMsgHandler(m_Id)

}

The g_pCmdDispatcher object should be initialized by calling

getCmdDispatcher().

此g-pCmdDispatcher对象应该藉由调用getCmdDispatcher()而被初始化。

系统组态和测试

图8是依据本发明一实施例的标称测试序列800(nominal testingsequence)。测试序列800包括在一测试环境804(test environment)中的模块的安装802(installation)，其包含测试准备806(testpreparation)和系统测试808(system testing)。最初，对新模块810(硬件或软件，或其组合)进行验证812(certification)(藉由一些可能基于供货商质量控制的外部程序)。安装802首先要求测试准备806，其包括对用于脱机模拟813(offline simulation)的硬件模块仿真(HW EmulationModule)的安装、对用于测试程序研发814(test program development)的模块源文件(module resource files)和接口(interface)的安装，和对用于模式编译816(pattern compilation)的专用模块模式编译器(modulespecific pattern complier)的安装。接着，藉由来自定标817(calibration)、诊诊断818(diagnostics)和组态

820(configuration)的输入来执行系统测试808(system testing)。接着，对新模块执行系统测试808，包括：(1)接口控制，(2)同步、定序和可重复性，(3)错误/警告处理，(4)多现场控制和(5)多工具模块控制。

以上所述，仅是本发明的较佳实施例而已，并非对本发明作任何形式上的限制，虽然本发明已以较佳实施例揭露如上，然而并非用以限定本发明，任何熟悉本专业的技术人员，在不脱离本发明技术方案范围内，当可利用上述揭示的技术内容作出些许的更动或修饰为等同变化的等效实施例，但是凡是未脱离本发明技术方案的内容，依据本发明的技术实质对以上实施例所作的任何简单修改、等同变化与修饰，均仍属于本发明技术方案的范围内。

Claims

1、一种用来测试至少一个被测元件(DUT)的半导体测试系统的分布式操作系统，其特征在于该操作系统包括：

一主操作系统，其藉由一系统控制器实现对至少一个现场控制器的控制；其中至少一个现场控制器并不共享一个公共时钟；和

至少一个本地操作系统，其与每个现场控制器关联，用于藉由一相关联的现场控制器实现对至少一个测试模块的控制，其中该相关联的现场控制器控制至少一个测试模块以即插即用的方式和该相关联的现场控制器互动，且其中至少一个测试模块对一个对应的被测元件执行测试。

2、根据权利要求1所述的分布式操作系统，其特征在于其中所述主操作系统将所述至少一个现场控制器的操作同步。

3、根据权利要求1所述的分布式操作系统，其特征在于其中所述主操作系统对所述系统控制器和所述至少一个现场控制器之间的通信进行仲裁。

4、根据权利要求1所述的分布式操作系统，其特征在于其中所述系统控制器对所述至少一个现场控制器的操作进行监测。

5、根据权利要求1所述的分布式操作系统，其特征在于其中一现场控制器对与所述现场控制器相关联的所述至少一个测试模块的操作进行监测。

6、根据权利要求1所述的分布式操作系统，其特征在于其中所述主操作系统包括至少一个主接口，其用来与所述至少一个现场控制器进行通信。

7、根据权利要求6所述的分布式操作系统，其特征在于其中所述至少一个主接口用于和与一现场控制器相关联的至少一个测试模块进行通信。

8、根据权利要求1所述的分布式操作系统，其特征在于其还包括一测试模块接口，该测试模块接口用来定义测试模块功能以便将一个现场控制器连接到一个第一测试模块，其中所述测试模块接口是可扩展的以便将所述现场控制器连接到一第二测试模块，未经扩展的测试模块接口不能够足以将所述现场控制器与所述第二测试模块连接。

9、根据权利要求1所述的分布式操作系统，其特征在于其中所述主操作系统包括至少一个主框架类。

10、根据权利要求9所述的分布式操作系统，其特征在于其中所述至少一个主框架类是采用标准计算机语言开发，以便使用户能够开发出用于控制所述至少一个现场控制器的专用应用程序类。

11、根据权利要求10所述的分布式操作系统，其特征在于其中所述标准计算机语言为C或C++语言。

12、根据权利要求1所述的分布式操作系统，其特征在于其中每个本地操作系统都包括至少一个本地框架类。

13、根据权利要求12所述的分布式操作系统，其特征在于其中所述的至少一个本地框架类是采用标准计算机语言开发，以便使用户能够开发出用于控制所述至少一个测试模块的专用应用程序类。

14、根据权利要求13所述的分布式操作系统，其特征在于其中所述标准计算机语言为C或C++语言。

15、根据权利要求1所述的分布式操作系统，其特征在于其中由每个现场控制器控制的所述模块的数量是可缩放的。

16、根据权利要求1所述的分布式操作系统，其特征在于其中与一对应的现场控制器相关联的所述本地操作系统使所述现场控制器控制的所述测试模块的类型能够被重新组态。

17、根据权利要求1所述的分布式操作系统，其特征在于其中所述主操作系统使所述系统控制器控制的所述现场控制器的数量能够被缩放。

18、根据权利要求1所述的分布式操作系统，其特征在于其中所述主操作系统使所述测试系统测试的所述DUT(被测元件)的数量能够被缩放。

19、根据权利要求1所述的分布式操作系统，其特征在于其中所述至少一个测试模块包括硬件和/或软件。

20.根据权利要求1所述的分布式操作系统，其特征在于还包括一仿真器，其用来模拟候选测试模块在测试系统中的使用，以便验证所述候选模块与所述测试系统兼容。

21、根据权利要求1所述的分布式操作系统，其特征在于其中位于一第一测试现场的第一组模块的组态与位于一第二测试现场的第二组模块的组态不同。

22、根据权利要求1所述的分布式操作系统，其特征在于一第一测试现场具有一用于测试一第一被测元件的第一组态，且一第二测试现场具有一用于测试一第二被测元件的第二组态，其中所述第一和第二测试现场可被重新组态以便共同形成一第三测试现场，替代地对一第三被测元件进行测试。

23、根据权利要求1所述的分布式操作系统，其特征在于其中一位于第一测试现场的第一模块能够存取一位于一第二现场的第二模块。

24、根据权利要求1所述的分布式操作系统，其特征在于还包括一通信库，其具有一组用于测试模块的预定功能和接口。