CN1784609B - 开发半导体集成电路测试程序的方法和构造 - Google Patents

Abstract

本发明描述了一种用于例如自动测试装置(ATE)等的使用面向对象结构的半导体测试系统的测试程序。本发明提供一种以通用面向对象结构(例如，C++对象和类)来描述测试系统资源、测试系统配置、模块配置测试序列、测试计划、测试条件、测试模式和计时信息的方法。特定而言，程序开发的模块性适用于开发开放式架构半导体测试系统的测试程序。

Description

开发半导体集成电路测试程序的方法和构造 

技术领域

本发明涉及对集成电路(IC)的测试，特别涉及开发一种用于自动半导体测试装置(ATE)的测试程序。 

背景技术

对相关申请案的交叉参考 

本申请案主张以下申请案的权利：2003年2月14日提出的申请案第60/447,839号，题为“Method and Structure to Develop a Test Program forSemiconductor Integrated Circuits”；2003年2月24日提出的申请案第60/449,622号，题为“Method and Apparatus for Testing Integrated Circuits”；2003年3月31日提出的申请案第10/404,002号，题为“Test emulator，testmodule emulator，and record medium storing programs therein”；以及2003年3月31日提出的美国申请案第10/403,817号，题为“Test Apparatus and TestMethod”。本申请案还与其同时申请的美国申请案第10/772,327号相关，其题为“Me thod and Apparatus for Testing Integrated Circuits”，此申请案主张2003年2月24日提出的题为“Method and Apparatus for Testing IntegratedCircuits”的申请案第60/449,622号之权利。 

如今，测试机制造商使用其自身的专有语言来开发用于半导体测试系统(测试机)的测试程序。例如，由Advantest Corporation制造的机器利用测试描述语言(Test Description Language，TDL)，而Credence Systems提供其自身的波形发生语言(Waveform Generation Language，WGL)。为了克服这种专属性程度，IC和测试机制造商试图通过开发IEEE标准1450-标准测试接口语言(STIL)-来找到共同点。然而，STIL是一种用于定义插针、测试命令、计时等的高度专用语言。此外，运行STIL的测试工程师仍需将STIL转译成测试机所要求的特定制造商专有语言。因此，STTL仅起到一种尽管不是高度专用但却仍然通常不为程序设计人员所知的中间语言的作用。 

因此，需要开发一种能够以通用语言来编写测试程序的方法。而且，此方法应该可以允许易于开发用于开放式架构测试系统的测试程序。 

发明内容

本申请案描述了使用面向对象的结构，例如，C++对象和类(class)进行测试程序的开发。特定而言，此方法适用于开发用于开放式架构测试机的测试程序，例如转让给本发明受让人的美国申请案第60/449,622、 10/404,002和10/403,817中所描述的开放式架构测试机。 

本发明提供一种以通用面向对象结构开发测试程序的方法，所述测试程序用于测试半导体测试系统中的半导体集成电路(IC)，该方法包括： 

以通用面向对象结构描述测试系统资源、测试系统配置和模块配置，用以开发测试半导体测试系统上IC的测试程序，其中描述测试系统资源、测试系统配置和模块配置包括： 

指定一模块连接启用器的一输入端口； 

指定一个运行主机操作系统的系统控制器，用于控制至少一个现场控制器；以及 

指定一个现场控制器，用于控制至少一个测式模块，其中每个测试模块包括供货商提供的硬件组件和软件组件，用来向所述半导体集成电路施加一个测试，其中软件组件之一的每个供货商专用软件模块包括了用于产生测试模式对象的特定模块编译器； 

以通用面向对象结构描述测试序列，用以开发测试半导体测试系统上IC的测试程序； 

以通用面向对象结构描述测试计划，用以开发测试半导体测试系统上IC的测试程序； 

以通用面向对象结构描述测试条件，用以开发测试半导体测试系统上IC的测试程序； 

以通用面向对象结构描述测试模式，用以开发测试半导体测试系统上IC的测试程序； 

以通用面向对象结构描述测试模式的计时，用以开发测试半导体测试系统上IC的测试程序；以及 

根据描述该测试系统资源、该测试系统配置、该模块配置、该测试序列、该测试计划、该测试条件、该测试模式及该测试模式的计时的该通用面向对象结构，编译该测试程序的计算机可执行码，其中该特定模块编译器编译一模式源文件成为加载至供货商硬件的一特定模块格式， 

其中所述测试系统将所述现场控制器在所述输入端口耦接到模块连接启用器，且所述模块连接启用器将所述现场控制器耦接到至少一个测试模块。 

本发明一实施例提供一种以通用面向对象(例如C/C++)结构来描述测试系统资源、测试系统配置、模块配置、测试序列、测试计划、测试条件、测试模式(test pattern)和计时信息来开发测试程序的方法，用于测试位于半导体测试系统(例如自动测试装置(ATE))上的被测元件(例如一IC)。含有这些描述的文件储存在存储器，即，测试系统或使用这些文件的相关装置可存取的计算机可读媒体中。 

对测试系统资源的描述可包括：指定资源类型，其中资源类型与向该IC提供测试的至少一个测试模块相关联；指定与该资源类型相关联的参数类型；以及指定该参数类型的一个参数。 

对测试系统配置的描述可包括：指定用于控制至少一个测试模块的现场控制器(site controller)，其中每个测试模块向IC施加一个测试；以及指定模块连接启用器(enabler)的输入端口。测试系统在指定的输入端口将现场控制器耦接到模块连接启用器，且模块连接启用器将现场控制器耦接到测试模块。模块连接启用器可用一个开关矩阵(switch matrix)实现。 

对模块配置的描述可包括：指定一模块标识符以指定模块类型；指定可执行码以控制由模块标识符所指定的模块类型的测试模块；以及指定与测试模块相关联的资源类型。可执行码可采用动态链接库的形式。 

对模块配置的描述还可涉及：用户指定一插槽标识符以指定模块连接启用器的输出端口，其中测试系统将测试模块耦接至模块连接启用器的输出端口，并且模块连接启用器将测试模块耦接到相应的现场控制器。用户还可以指定一供货商标识符以识别测试模块的供应者，并且指定与资源类型有关的可利用资源单元的最大数量的标识符。资源类型可为(例如)数字测试机插针和资源单元测试机通道。或者，测试机通道资源单元还可以对应于下列资源类型，例如：模拟测试机插针、RF测试机插针、电源插针、数字化器插针和任意波形发生插针。还可以提供一个与禁用资源单元相关的指示器。指示为禁用的资源单元可以表示测试模块的缺陷资源单元。 

对测试条件的描述可包括：指定至少一个测试条件组；指定一包括至少一个变量的规约集(specification set)；以及指定一选择器(selector)以选择由一个变量绑定(bind)的表达式。测试条件组与用于规约集的选择器的关联(association)定义一测试条件。 

对测试序列的描述可包括指定可施加各种测试的顺序(或流程)。 

对测试模式的描述可以包括指定测试模式、相关电压和电流位准、信号值中变换、相应的上升和下降时间和相关计时。 

本发明一实施例还包括对前报头(preheatedr)文件的使用。编译一个前报头文件以便为与测试实体(test entity)相关的类创建一个报头文件。前报头包括：一参数块，其指定用于设定测试实体至少一个属性的参数；以及一模板(template block)，其指定为测试实体类由编译器插入测试实体类报头文件的源码。报头文件可为C++报头文件。举例来说，测试实体可为一测试，测试实体类可为一测试类。举例来说，参数可与模式清单和测试条件有关。 

本发明一实施例的模式编译器包括至少一个特定模块的模式编译器(module-specific pattern compiler)和一个目标文件管理器(object filemanager)，所述目标文件管理器用于引导各个特定模块编译器来编译模式源文件的相应特定模块部分和通用部分。通用部分包括所有特定模块编译器可存取的信息。编译器的输出包括至少一个特定模块的模式数据部分。特定模块的模式加载器从相应的特定模块模式数据部分载入相应的测试模块特定模块的模式数据以用于执行。 

附图说明

图1说明一习知测试机架构。 

图2说明根据本发明一实施例的测试机架构。 

图3说明根据本发明一实施例的测试机软件架构。 

图4说明根据本发明一实施例的测试程序编译器。 

图5说明从根据本发明一实施例的单一测试类如何产生不同的测试实例(instance)。 

图6说明根据本发明一实施例的模式编译器。 

图7说明根据本发明一实施例的有序模式树的范例。 

图8说明根据本发明一实施例的另一有序模式树的范例。 

图9说明根据本发明一实施例的测试程序所需的文件之间的关系。 

图10说明根据本发明一实施例的波形发生。 

图11说明根据本发明一实施例的用于计时的映射。 

图12说明根据本发明一实施例的用于计时的另一映射。 

具体实施方式

本发明大体上是依据同一受让人提交的美国申请案第60/449,622、10/404,002和10/403,817号中所公开的开放式架构测试系统来描述的。然而，熟悉本专业的技术人员将认识到，本发明的测试程序开发系统和方法的实施例不但可应用于开放式测试机架构，而且也可应用于固定测试机架构。 

对开放式架构测试系统的描述可见于与本申请案同时提交的题为“Method and Apparatus for Testing Integrated Circuits”的美国专利申请案第号该申请案主张由相同受让人提交的美国申请案第60/449,622号的权利。 

图1说明一习知测试机的通用化架构，其展示如何产生信号和如何将信号应用于被测元件(DUT)。每个DUT输入插针连接到一个应用测试数据的驱动器2，而每个DUT输出插针连接到一个比较器4。在大多数状况下，使用三态驱动器-比较器使得每个测试机插针(通道)即可充当输入插针，也可充当输出插针。专用于一单一DUT的测试机插针共同形成一测试现场，其与相关联的定义数据速率的相关计时发生器6、波形发生器8、模式存储器10、计时数据存储器12、波形存储器数据14和组块16协同工作。 

图2说明一根据本发明一实施例的系统架构100。系统控制器(SysC) 102被耦接到多个现场控制器(SiteCs)104。系统控制器还可以被耦接到网络以便存取文件。通过一模块连接启用器106耦接每个现场控制器以便控制位于测试现场110的一或多个测试模块108。模块连接启用器106允许对连接的硬件模块108进行重新配置并且还充当用于数据传送(用于载入模式数据、收集响应数据、提供控制等等)的总线。可能的硬件实现包括专用连接、开关连接、总线连接、环形连接和星形接。例如，模块连接启用器106可藉由开关矩阵来实现。每个测试现场110与一个DUT 112相关联，该DUT 112藉由一负载板114连接到相应现场的模块。在一实施例中，可将一个单一现场控制器连接到多个DUT现场。 

系统控制器102充当总系统管理器。其协调现场控制器的行为，管理系统级并行测试策略，且另外提供处理器/探测器(handler/probe)控制以及系统级数据记录和错误处理支持。根据操作设定，系统控制器102可部署在独立于现场控制器104的操作的CPU上。或者，系统控制器102和现场控制器104可共用一个通用CPU。类似地，可将每个现场控制器104部署在其自身的专用CPU(中央处理器)上，或将其作为同一CPU内的独立进程或线程。 

系统架构可概念性地看作图2中所展示的分布式系统，其中应理解：单个系统组件还可以看作是集成的、单片的系统的逻辑组件而并非必须是分布式系统的物理组件。 

图3说明根据本发明一实施例的软件架构200。软件架构200表示一分布式操作系统，其具有用于系统控制器220、至少一个现场控制器240和至少一个模块260的元件，这些元件对应于相关的硬件系统元件102、104、108。除了模块260之外，架构200还包括一用于软件模块仿真280的相应元件。 

作为一种例示性的选择，此平台的开发环境可基于Microsoft Windows。使用此架构的还在程序和支持的便携性方面具有附带益处(例如，现场维护工程师可连接一运行该测试机操作系统的膝上型电脑以便执行高级诊断)。然而，对于大型计算密集型的运算操作(例如，测试模式编译)，可将相关软件设计成能够独立运行的实体从而允许跨分布式平台的作业调度。因此，用于批量作业的相关软件工具能够在多个平台类型上运行。 

作为一种例示性的选择，可采用ANSI/ISO标准C++作为软件的本机语言。当然，存在许多可允许第三方以其自身选择的替代性语言集成入该系统的选项(以便提供位于标称C++接口上的一个层(layer))。 

图3说明根据名义源(nominal source)组织(或作为子系统集体开发)的元件的阴影表示，其包括：测试机操作系统290、用户组件292(例如，用户提供的用于测试目的的组件)、系统组件294(例如，作为基本连接和通信提供的软件基础结构)、模块开发组件296(例如，模块开发商提供的)、和外部组件298(例如，由模块开发商以外的外部源提供的)。 

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

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

系统组件294包括：系统工具226、通信库230、测试类244、底板驱动器250、HW底板261、仿真框架281、底板仿真282、和负载板仿真286。 

模块开发组件296包括：模块命令执行实现248、模块硬件263、和模块仿真284。 

外部组件298包括外部工具225。 

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

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

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

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

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

现场控制器240中具有用户测试计划242、用户测试类243、标准测试类244、标准接口245、现场控制器框架类246、模块高准位命令接口(即，预定模块准位接口)247、模块命令执行实现248、底板通信库249、和底板驱动器250。较佳的是，大多数测试功能由现场控制器104/240处理，因此允许测试现场110独立操作。 

测试计划242由用户编写。测试计划可直接由采用面向对象结构的标准计算机语言如编写，如C++，或以更高级别测试程序语言描述以便产生C++代码，然后可将其编译为可执行的测试程序。对于测试程序开发，本发明一实施例采用受让人的创造性的测试程序语言(TPL)编译器。参看图4，测试程序编译器400部分充当一代码发生器，其包括一转译器部分402，用于将描述测试和相关参数的测试程序开发者源文件404转译成面向对象的结构(例如C++代码)。而编译器部分406将代码编译且链接入可执行代码(例如DLLs)以便产生可由测试机系统来执行的测试程序。尽管将TPL代码发生器/转译器应用于测试系统是新颖的，但是请注意，代码发生器在相关技术领域中是已知的。 

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

输入测试程序编译器400的源码包括一测试计划描述文件，其指定用于测试计划的对象以及彼此之间的关系。将此文件转译成可以以标准接口实现形式在现场控制器上执行的C++代码，其可表示为iTestPlan。此代码被装入一个Windows动态链接库(DLL)，该DLL可被载入现场控制器。生成测试程序DLL以使其具有标准已知进入点，现场控制器软件可使用此标准已知进入点来生成并返回其所包含的TestPlan对象。现场控制器软件将测试程序DLL载入其进程空间并使用进入点中的一个来创建测试计划对象的一个实例(instance)。一旦测试计划对象被创建，则现场控制器软件随后可执行该测试计划。 

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

可在模块级接口247的帮助下实现某些框架对象的工作，以便与模块进行通信。现场控制器框架类有效地起到作为局部操作系统接口支持每一个现场控制器的功用。 

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

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

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

所有的测试类型都提供某些虚拟方法(virtual method)的缺省实现(例如：init()，preExec()，和postExec())。这些方法变为测试工程师越过(override)缺省行为和设定任何测试专用参数的进入点。但是，在测试计划中还可以使用定制的测试类。 

通过提供用来为该测试的某一特定实例指定可能的选项，测试类允许用户对类行为进行配置。例如，功能测试(Functional Test)可采用参数PList和TestConditions来分别规定将要执行的模式列表(Pattern List)，和测试的级别(Level)与计时(Timing)条件。为这些参数规定不同的值(借助测试计划描述文件中不同“测试”模块的使用)，使用户能够创建功能测试的不同实例。图5说明如何从单一测试类得到不同的测试实例。这些类可在面向对象结构如C++中直接被编程，或被设计为允许一测试程序编译器由测试计划文件中取得对测试的描述和参数并生成对应的C++代码，该代码可被编译和链接以便生成测试程序。可采用模板库(Template Library)作为通用算法和数据结构的通用库。该库对于测试机的用户是可见的，这样，例如，用户可以修改测试类的实现，以便创建用户定义的测试类。 

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

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

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

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

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

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

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

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

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

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

通过将此开放式架构作为技术背景，本发明的测试程序开发系统进一步描述如下。下文中的章节A是对描述使用测试程序的测试环境的规则的描述；章节B描述测试程序开发的方法和规则；章节C指定用于开发测试计划和如何定义测试程序主构造的方法和规则；章节D描述如何在开放式架构测试系统上运行测试程序；章节E描述测试模式的方法和规则；章节F描述了用于描述测试模式的计时的规则；且章节G描述整体测试机运算操作的规则。 

A.组件 

测试环境包括一组文件，其指定了建立测试机并使其预备运行一组测试的必要条件。较佳的是，测试环境包括用于以下各项的文件： 

1.测试机资源定义：用于开放式架构测试系统中可利用的测试机资源的类型的规约，以及和此资源的支持参数。 

2.测试机配置：用于现场控制器、现场和相应的映射的规约。 

3.模块配置：用于每个现场中的硬件模块规约。 

4.插针描述：用于命名DUT插针，例如信号插针、电源，和描述插针组。 

5.插口：用于DUT插针到测试机插针分配的规约。 

6.插针选项：用于插针的特殊选项或模式的规约。 

7.模式列表：用于测试模式及其序列的规约。 

8.模式：用于测试向量的规约。 

在上述各项中，1-3项是由具有来自CMD(配置管理数据库)的信息的ICF(安装和配置文件)建立，并且可由熟知位置获得；而4-8是用户规定的。本章提供对上述1-6项的描述；7-8项在章节E中更详细地进行描述。较佳的是使用特定方法和规则来开发这些组件；在此部分将藉由一些范例来描述这些方法和规则。 

A1.资源定义(Resource Definition) 

每个硬件模块提供一或多种用于测试系统的硬件资源(简称为资源)。测试机资源定义较佳用于声明(declare)可利用的资源类型的一组资源名称，和与每个特定资源类型相关的一组参数名称和类型。例如，资源名称dpin用于表示数字测试机插针。这些资源具有下列参数，例如VIL(用于输入低电压)、VEH(用于输入高电压)、VOL(用于输出低电压)、VOH(用于输出高电压)等等。资源定义文件将具有扩展名″.rsc″。下文展示了一例示性资源定义，其含有一些测试机资源： 

# 

#File Resources.rsc 

# 

Version 0.1.2； 

ResourceDefs 

{ 

   #digital pins 

   dpin 

   { 

      #Low and High voltages for input pins 

      Voltage VIL，VIH； 

      #Low and High voltages for output pins 

      Voltage VOL，VOH； 

   } 

   #power supplies 

   dps 

   { 

      # 

      #PRE_WAIT specifies the time to wait after voltage 

      #    reached its final value to start pattern 

      #    generation.The actual time that the system 

      #    will wait is a small system specified range: 

      #    PRE_WAIT-delta＜＝actual＜＝PRE_WAIT+delta 

      # 

      #PRE_WAIT_MIN is a minimum amount to wait after voltage 

      #    reached its final value to start pattem generation. 

      #    It is a system specified range: 

      #    PRE_WAIT_MIN＜＝actual＜＝PRE_WAIT_MIN+delta 

      # 

      #POST_WAIT specifies the time to wait after pattem 

      #    generation ends to shut down the power.The actual 

      #    time that the system will wait is a small system 

      #    defined range: 

     #    POST_WAIT-delta＜＝actual＜＝POST_WAIT+delta 

     # 

     #POST_WAIT_MIN specifies the time to wait after pattern 

     #    generation ends to shut down the power.The actual 

     #    time that the system will wait is a small system 

     #    defined range: 

     #    POST_WAIT_MIN＜＝actual＜＝ 

POST_WAIT_MIN+delta 

     # 

     Time PRE_WAIT； 

     Time PRE_WAIT_MIN； 

     Time POST_WAIT； 

     Time POST_WAIT_MIN； 

     #The voltage. 

     Voltage VCC； 

   } 

 } 

注意资源参数(例如电压(Voltage)或时间(Time))的类型较佳为一标准工程单位(standard engineering unit)。提出不同参数说明的供应特殊目的资源的供货商应该提供其自身的资源定义文件。 

资源定义的构造 

下文根据本发明的较佳实施例给出资源定义文件的构造： 

          resource-file: 

              version-info resource-defs 

          version-info: 

              Version version-identifer； 

          resource-defs: 

              ResourceDefs{resource-def-list} 

          resource-def-list: 

              resource-def 

              resource-def-list resource-def 

          resource-def: 

              resource-name{resource-params-decl-list} 

          resource-params-decl-list: 

              resource-params-decl 

              resource-params-decl-list resource-params-decl 

          resource-params-decl: 

              elementary-type-name resource-param-name-list； 

          resource-param-name-list: 

              resource-param-name 

              resource-param-name-list，resource-param-name 

上文未定义的非终端符指定如下： 

1.version-identifier(版本标识符)：来自集合[0-9a-zA-Z.]的一或多个字符的序列。其表示版本号。 

2.resource-name(资源名称)：来自集合[a-zA-Z_0-9]的一或多个字符的序列，不是以数字开头。其表示资源名称，例如dpin或dps。 

3.elementary-type-name(基本类型名称)：来自集合[a-zA-Z_0-9]的一或多个字符的序列，不是以数字开头。其表示基本类型的名称，例如电压(cf.)。 

4.resource-param-name(资源参数名称)：来自集合[a-zA-Z_0-9]的一或多个字符的序列，不是以数字开头。其表示资源参数名称，例如VIL。 

A2.测试机配置 

测试机配置是一组规则，其较佳用于列举特定系统配置中的现场控制器和现场控制器到开关矩阵输入端口的连接。在本发明一实施例的架构中，可将单一现场控制器连接到单一开关矩阵输入端口。因此，在此上下文中，开关矩阵连接充当系统中现场控制器的隐含标识符(implicit identifyier)(也可能是其它配置)。下文是典型测试机配置的一个范例： 

# 

#Tester Configuration，Sys.cfg 

# 

Version 1.2.5； 

SysConfig 

{  

   # 

   #The first field is the hostname of the Site Controller machine； 

   #it can be specified as either a dotted-decimal IP address or a 

   #domain-qualified hostname. 

   # 

   #The second field is the switch matrix input port number，which 

   #implicitly serves as the identifier for the Site Controller 

   #connected to it. 

   # 

   zeus.olympus.deities.org    2； 

   127.0.0.2                      4； 

   127.0.0.0                      1；#SITEC-1 

   127.0.0.3                      3； 

} 

特定测试台系统的系统配置为系统简档(system profile)的一部分，且可作为系统配置文件Sys.cfg来获得。应注意，在一实施例中，连接到端口1(在上述范例中为“127.0.0.0”)的现场控制器可享有特殊状态，其中其单独配置开关矩阵。此“特殊”现场控制器将被称为SITEC-1。还应该注意到，此范例中的现场控制器地址是一个IP地址，因为现场控制器可藉由内部网络连接到系统控制器。相反地，系统控制器可连接到外部网络以便存取文件，例如模式数据(pattern data)。 

测试机配置的构造 

下文根据本发明一实施例给出系统配置文件的构造： 

system-config-file: 

    version-info system-config 

version-info: 

    Version version-identifer； 

system-config: 

    SysConfig{site-controller-connection-list} 

site-controller-connection-list: 

    site-controller-connection 

    site-controller-connection-list site-controller-connection 

site-controller-connection: 

    site-controller-hostname input-port； 

site-controller-hostname: 

    ip-address 

    domain-qualified-hostname 

ip-address: 

    octet.octet.octet.octet 

domain-qualified-hostname: 

    name 

    domain-qualified-hostname.name 

上文未定义的非终极符指定如下： 

1.version-identifier(版本标识符)：来自集合[0-9a-zA-Z.]的一或多个字符的序列。其表示版本号。 

2.octet(八位位组)：一从0到255的非负整数(十进制记数法)。 

3.name(名称)：来自集合[a-zA-Z_0-9]的一或多个字符的序列，不是以数字开头。其表示限定域主机名中的名称片段。 

4.input-port(输入端口)：一个以十进制记数法表示的非负整数。 

A3.模块配置 

模块配置允许对测试机物理配置进行说明，例如系统框架(SYSTEMchassis)中每个模块的物理位置和类型。测试机总线配置的动态性质使此成为必要，动态性质允许将测试机总线地址映射到物理插槽位置。此信息允许在系统启动时间内发生的硬件发现程序使系统配置生效。开关矩阵的每 个输出端口定义一个物理插槽，其较佳被一单一硬件模块占据。下面根据本发明一实施例展示了在文件Modules.cfg中指定的模块配置的一个范例： 

# 

#Module Configuration File，Modules.cfg 

# 

Version 0.0.1； 

ModuleConfig 

{ 

   # 

   #A configuration definition which provides information about 

   #the module type that is attached to slots 1-12 and 32-48. 

   #Note that a module might provide more than 

   #a single type of resource. 

   # 

   Slot 1-12，32-48                 #Switch matrix output ports 

                                    #which use the configuration 

                                    #defined below. 

   { 

    VendorID 1；                 #defined vendor code. 

    ModuleID 1；                 #Vendor-defined id code. 

    ModuleDriver mod1.dll；    #Module software. 

    # 

    #Resource named dpin specifies channels 

    #for digital data.The name dpin is not 

    #a keyword.It is simply the name of a hardware 

    #resource，and is obtained from the resource 

    #definition file. 

    # 

    Resource dpin 

    { 

       MaxAvailable 32；    #Resource units 1..32. 

    } 

    Resource analog 

    { 

       MaxAvailable 16；       #Resource units 1..16. 

       Disabled     1-8；   #Disabled resources 1..8. 

                               #So，enabled ones are 9..16. 

    } 

  } 

  # 

  #A configuration definition which provides information about 

  #the module type that is attached to slots 16-30，50，and 61-64. 

  # 

  Slot 16-30，50，61-64 

  { 

      Resource dpin 

      { 

         MaxAvailable 32；          #Max available resource units. 

         Disabled     3，30-32；    #Disabled resources. 

      } 

      ModuleDriver    ″module two.dll″； 

    VendorID    2； 

    ModuleID    2； 

 } 

 # 

 #A configuration definition，which provides information about 

 #the module type that is attached to slots 65-66. 

 # 

 Slot 65-66 

 { 

      ModuleID           4；    #DPS module with 8 supplies. 

      ModuleDriver       mod4.dll； 

      VendorID           1； 

      # 

      #Resource type dps specifying resource units for a 

      #Device Power Supply 

      # 

      Resource dps 

      { 

         MaxAvailable 4； 

         Disabled     1； 

     } 

   } 

 } 

如前文所提及，在一实施例中，插槽表示可连接硬件模块的连接器，例如开关矩阵的输出端口。每个配置定义提供关于可连接到一或多个插槽的模块的信息。配置定义中所指定的供货商lD(VendorID)是与一供货商相关联的独特ID。模块lD表示此供货商所提供的模块的类型。在一个测试机配置中可存在相同模块lD(ModuleID)的若干实例。模块驱动器表示用于运行该模块的供货商供应的DLL。最后，资源表示藉由此模块来运行的单元，且提供资源类型的名称；资源名称从资源定义文件获得。 

上述范例描述了处于一个模块配置文件中的三个配置块。在一实现中，第一配置块、插槽1-12和32-48藉由供货商1所制造的模块来运行。此供 货商向该模块提供标识符″1″以表示此模块类型，并提供模块驱动器库以控制该模块。此模块可以提供两个类型的资源单元，一个由资源名称″dpin″来指定，其中资源单元(即，“通道”)总量较佳为32，所有的资源单元均可用；而另一个由资源名称″analog"来指定，其中资源单元总量较佳为16，其中仅9到16个可用。以类似于第一配置的方式来指定第二和第三配置块。 

注意，允许将通道指示为“禁用”可实现在其它方面仍具有功能性的模块上识别缺陷资源单元。注意，配置块可具有一或多个插槽标识符。当区块具有多于一单一插槽标识符时，则称该标识插槽被“克隆”。 

ICM(安装配置管理系统)(藉由用户提供的测试台专用信息)将模块配置文件(Modules.cfg)作为系统简档的一部分被建立，且可在熟知位置获得。对测试系统而言，ICM可为一局部的实用程序，例如，被置于系统控制器上，或置于系统控制器所连接的网络上的其它位置。ICM管理CMD(配置管理数据库)，且通常在对系统配置进行硬件改变时被更新。ICM允许用户配置系统，例如现场控制器和模块。CMD是一个储存这些配置的数据库。对于实际的测试机配置/操作，ICM生成配置文件，例如模块配置，和其它文件，并且将其及相关文件，例如特定模块DLL，复制到测试机上。 

模块配置构造 

下面是根据较佳实施例的模块配置构造： 

fle-contents: 

    version-info module-config-def 

version-info: 

    Version version-identifier； 

module-config-def: 

    ModuleConfig{slot-entry-list} 

slot-entry-list: 

    slot-entry 

    slot-entry-list slot-entry 

slot-entry: 

    Slot positive-integer-list{slot-info} 

slot-info: 

    required-config-list 

required-config-list: 

    required-config 

    required-config-list required-config 

required-config: 

    VendorID id-code； 

    ModuleID id-code； 

    ModuleDriver file-name； 

    Resource resource-name{max-spec disabled-spec_opt} 

max-spec: 

    MaxAvailable positive-integer； 

disabled-spec: 

    Disabled poitive-integer-list； 

positive-integer-list: 

    positive-integer-list-entry 

    positive-integer-list，positive-integer-list-entry 

positive-integer-list-entry: 

    positive-integer 

    positive-integer-number-range 

positive-integer-number-range: 

   positive-integer-pos-integer 

上文未定义的非终端符描述如下： 

1.version-identifier：来自集合[0-9a-zA-Z.]的一或多个字符的序列，其中首字符必须来自集合[0-9]。 

2.positive-integer：来自集合[0-9]的一或多个字符的序列，非以0开头、 

3.id-code：来自集合[a-zA-Z_0-9]的一或多个字符的序列。 

4.resource-name：来自集合[a-zA-Z_0-9]的一或多个字符的序列，其中首字符必须来自集合[a-zA-Z]。 

支持注释；注释以′#′字符开始。且延伸到此行结束。 

A4.插针描述 

使用插针描述(Pin Description)文件来描述DUT插针描述。用户在插针描述文件中获得对DUT插针的描述，文件扩展名为.pin。此纯文本文件至少包括下列各项：DUT插针名称列表；和所命名插针组的初始定义，其利用所定义的DUT插针名(称之为“初始”是因为随后可通过编程对其修改或增加等等)。 

此数据说明与测试计划描述的分离允许DUT插针定义的普遍再使用，且允许模式编译器从插针描述文件获得插针名(需要插针名来解析用于向量规约的对插针名的参考)，而不会使程序局限于特定测试计划。 

下面展示了例示性插针描述文件： 

# 

#Pin description file，myDUT.pin. 

# 

#Note that this implicitly imports the resource 

#configuration file，Resources.rsc. 

# 

Version 1.1.3a； 

PinDescription 

{ 

   Resource dpin 

   { 

      A0； 

      A1； 

      A2； 

      A3； 

      A4； 

      #This syntax expands to the names″ABUS[1]″ and″ABUS[2]″ 

      ABUS[1:2]； 

      A5； 

      BBUS[1:8]； 

      DIR； 

      CLK； 

      Group Grp1 

      { 

         DIR，CLK，A0，A1，A2，A3，A4，BBUS[1:4] 

      } 

    Group Grp2 

    { 

       A5， 

       # 

       #The following line will expand to 

       #″DIR，A1，A2，A4，A5，BBUS[2]″: 

       # 

       Grp1-CLK-A0-A3-BBUS[1]-BBUS[3:4]+A5， 

       BBUS[5:8] 

    } 

  } 

  Resource dps 

  { 

     vcc1； 

     vcc2； 

     vcc3； 

     Group PSG 

     { 

        vcc1，vcc2 

      } 

   } 

} 

注意DUT插针和插针组定义封装于资源类型块内，以允许编译器将插针和插针组定义与可允许的用于级别(Level)等的参数设置相互关联。 

应注意关于插针描述的下列各点： 

1.插针组和插针共享相同的名称空间且具有全程作用范围(globalscope)(即，测试计划)。对这些名称全程作用域的一个结果是插针和插针组不能使用重复名称，即使在处于不同资源块声明时。 

2.插针描述文件需要至少一个资源定义。 

3.在每个资源边界(resource boundary)中应该义至少一个插针名。 

4.要求插针和组名称在资源边界内是唯一的。 

5.可以为两个或两个以上资源定义相同的插针或组名称。然而，忽略相同资源内出现的重复。 

6.在组定义中出现的所有插针名和组名称应该已经在该资源内被定义。 

7.如果给出组定义，则该组定义应该具有至少一个插针名或组名称(即，组定义不能为空)。 

8.插针组定义可包括对先前定义的插针组的参考。 

9.插针组定义可包括集合运算(set operation)，例如对先前定义的插针和/或插针组的添加和减少。 

插针描述的构造 

下面给出了根据本发明较佳实施例的插针描述的构造： 

pin-description-file: 

    version-info pin-description 

version-info: 

    Version version-identifer； 

pin-description: 

    PinDescription{resource-pins-def-listt} 

resource-pins-def-list: 

    resource-pins-def 

    resource-pins-def-list resource-pins-def 

resource-pins-def: 

    Resource resource-name{pin-or-pin-group-def-list} 

pin-or-pin-group-def-list: 

    pin-or-pin-group-def 

    pin-or-pin-group-def-list pin-or-pin-group-def 

pindef-or-pin-groupdef: 

    pin-def； 

    pin-group-def 

pin-def: 

    pin-name 

    pin-name[index:index] 

pin-group-def: 

    Group pin-group-name{pin-group-def-item-list} 

pin-group-def-item-list: 

    pin-def 

    pin-group-def-item-list，pin-def 

上文未定义的非终端符指定如下： 

1.version-identifier：来自集合[0-9a-zA-Z.]的一或多个字符的序列。其表 示版本号。 

2.resource-name：来自集合[a-zA-Z_0-9]的一或多个字符的序列，不是以数字开头。其表示资源的名称，例如dpin或dps。 

3.pin-name：来自集合[a-zA-Z_0-9]的一或多个字符的序列，不是以数字开头。其表示插针A0的名称。 

4.pin-group-name：来自集合[a-zA-Z_0-9]的一或多个字符的序列，不是以数字开头。其表示插针组ABUS的名称。 

5.index：一非负整数。其表示一组相关插针的下限或上限。 

A5.插口(socket) 

插口指定DUT插针名与物理测试机插针(通道)赋值之间的映射(在模块配置文件中定义物理测试机通道数量)。注意可使用不同插口来支持不同DUT封包和不同负载板配置，等等。对于多DUT系统，DUT/通道分配的插口定义可支持一基本插口到多个现场的“克隆”。然而，不同插口(即，同一逻辑插针的不同物理映射)应该考虑到现场模块划分(partition)。因此，除了向测试机通道分配提供DUT插针之外，插口还可有效地定义现场划分。因此，插口文件可获得对若干单个现场插口的定义。下面展示了定义三个DUT现场的例示性插口文件： 

Version 1.1.3 

SocketDef 

{ 

   DUTType Pentium3 

   { 

     PinDescription dutP3.pin；#The pin description fie for Pentium3 

     DUT 2#Uses the full-specification syntax 

     { 

       SiteController 1；#Switch Matrix input port 

Resource dpin 

{ 

   # 

   #The CLK pin is assigned to resource dpin， 

   #slot 2，resource unit(channel)13. 

   # 

   CLK    2.13； 

   # 

   #The DIR pin is assigned to resource dpin， 

   #slot 5，resource unit 15. 

   DIR    5.15； 

   # 

   #The following statement will be expanded to 

   #    BBUS[7]  5.4 

   #    BBUS[6]  5.5 

   #    BBUS[5]  5.6 

   # 

   #So for example，the pin sequence BBUS[7]，BBUS[6]， 

   #BBUS[5] is assigned to the same slot 5，and to 

   #resource units 4，5 and 6 respectively. 

   # 

   BBUS[7:5]    5.[4:6]； 

   BBUS[1:4]    7.[21:18]； 

   BBUS[8]      9.16； 

} 

Resource dps 

{ 

   # 

   #The V1 pin is assigned to resource dps， 

   #slot 1，resource unit(channel)1. 

   # 

   VCC1 1.1； 

   # 

    #The VCC2 pin is assigned to resource dps， 

    #slot 1，resource unit(channel)2. 

    # 

    VCC2 1.2； 

  } 

}#EndDUT2 

DUT 1 # This is″cloned″from DUT 2 above 

{ 

  SiteController 1；#Same Site Controller as for DUT 2 

  Resource dpin 

  { 

     SlotOffset 1；    #Offset value for slots 

  } 

  Resource dps 

  { 

     SlotOffset 10；#Offset value for slots 

  } 

  # 

  #The offset syntax above indicates that the slot/resource 

  #unit assignments are″cloned″from the first DUT defined 

  #for this DUTType，i.e.，DUT 2，with the slots offset by 

  #the SlotOffset values. 

  # 

  #Looking at the definition of dpin resource units for 

  #DUT 2，CLK is bound to slot 2.Hence，for the present 

  #DUT，CLK is bound to slot 2+1＝3. 

  # 

  #Some oft he new bindings in effect due to the offset 

  #assignments are shown in the table below: 

  # 

  #--------------------------------------------------- 

  #    Pin    Resource    RUnit    Slot 

  #--------------------------------------------------- 

      #       CLK       dpin       13       2+1 

＝3 

      #       DIR       dpin       15       5+1 

＝6 

      #       BBUS[8]   dpin       16       9+1＝10 

      #       VCC1      dps        1        1+10＝11 

      #       VCC2      dps        2        1+10＝11 

      # 

    }#End DUT 1 

   }#End DUTType Pentium3 

   DUTType 74LS245 

   { 

      PinDescription dutLS.pin； 

      DUT 3 disabled # This DUT site is disabled，and will be ignored 

      { 

      } 

    }#End DUTType 74LS245 

  }#End SocketDef 

应注意关于插口文件的下列各点： 

1.插口文件(Socket file)使用来自模块配置文件和用户的特定DUT类型插针描述文件两者的信息(参看前文的具体范例中对PinDescription的规约说明)。插口文件编译器可隐含地获得模块配置信息。插口文件编译器为模式编译器的子部分，其读取和分析插口DUT名称以用于测试机通道映射，并且读取和分析模块配置和插针描述文件以建立测试机插针到模式编译器所用的DUT插针的映射。 

2.每个DUT类型需要至少一个DUT现场定义，且其必须使用完整规约语法，与SlotOffset语法相对。如果为相同DUT类型提供一个以上的DUT现场定义，则第一个必须使用完整规约语法(full specification syntax)。 

3.每个随后DUT现场定义(用于相同DUT类型)可以使用完整说明语法或SlotOffset语法中的任一者，但是不能同时使用两者。此允许单个现场 偏离标准模式(例如由于不工作的通道)。 

4.相对于为该DUT类型定义的第一现场(其使用完整说明语法)来定义从SlotOffset语法得出的绑定(binding)。 

5.DUT现场不需要以实际物理顺序来声明。允许以下情形：从该模式得到第一(物理)现场。 

要求DUT现场ID在整个插口上(即，在这里所定义的所有DUT类型上)是唯一的。 

7.每个DUT现场定义要求至少一个资源定义。 

8.必须结合模块配置来使用现场定义以便确定测试配置是单现场/单DUT还是单现场/多DUT。 

9.在所有情形中，插口文件应该指定一DUT通道映射集，其与插针描述文件和模块配置文件一致。 

10.在某些情形中，需要允许插口定义指定一或多个DUT通道脱离测试机(例如，藉由将所分配的物理通道指定为具有特殊ID″0.0″的物理通道)。在此情形中，可在测试程序中使用和引用这些DUT通道。这些通道上的操作将导致系统告警(但不是错误)。 

插口构造 

下面描述了根据本发明较佳实施例的模块配置构造： 

socket-file: 

    version-info socket-def 

version-info: 

    Version version-identifer； 

socket-def: 

    SocketDef{device-specific-socket-def-list} 

device-specific-socket-def-list: 

    device-specific-socket-def 

    device-specific-socket-def-list device-specific-socket-def 

device-specific-socket-def: 

    DUTType DUT-type-name{pin-description-file dut-info-list} 

pin-description-file: 

    PinDesc pin-description-file-name； 

dut-info-list: 

    dut-info 

    dut-info-list dut-info 

dut-info: 

    DUT dut-id{site-controller-input-port resource-info-list} 

site-controller-input-port: 

    SiteController switch-matrix-input-port-number； 

resource-info-list: 

    resource-info 

    resource-info-list resource-info 

resource-info: 

    Resource resource-name{resource-item-unit-assignment-list} 

resource-item-unit-assignment-list: 

    resource-item-unit-assignment 

    resource-item-unit-assignment-list resource-item-unit-assignment 

resource-item-unit-assignment: 

    resource-item-name slot-number.resource-unit； 

    resource-item-name[resource-item-index]slot-number.resource- 

unit-index； 

    resource-item-name[resource-item-index-range] 

        slot-number.[resource-unit-index-range]； 

    resource-item-index-range: 

        resource-item-index:resource-item-index 

resource-unit-index-range: 

   resource-unit-index:resource-unit-index 

上文未定义的非终端符指定如下： 

1.version-identifier：来自集合[0-9a-zA-Z.]的一或多个字符的序列。其表示版本号。 

2.DUT-type-name：来自集合[0-9a-zA-Z.]的一或多个字符的序列，其中首字符不能来自集合[0-9]。其表示DUT类型，例如Pentium3。 

3.pin-description-file-name：文件的简名，不包括其目录名，但是包括所有扩展名。文件名为主机操作系统可识别的语法，并且如果放入引号中则允许空格和其它字符。 

4.switch-matrix-input-port-number：以十进制记数法表示的非负整数，用于表示连接到现场控制器的输入端口的端口数量。 

5.dut-id：以十进制记数法表示的非负整数，用于识别DUT的实例。 

6.resource-name：来自集合[0-9a-zA-Z.]的一或多个字符的序列，其中首字符不能为数字。其表示资源文件中所定义的资源的名称。 

7.resource-item-name：来自集合[0-9a-zA-Z.]的一或多个字符的序列，其中首字符不能为数字。其表示资源单位的名称，例如插针或插针组。 

8.resource-item-index：以十进制记数法表示的非负整数，其表示一组资源项的特定成员。当在resource-item-index-range中时，其表示资源项组 邻近序列的下限或上限。 

9.resource-unit-index：以十进制记数法表示的非负整数，其表示一组资源单元(通道)的特定成员。当在resource-unit-index-range的中时，其表示资源单位组的下限或上限。 

A6.插针(Pins) 

注意到，除了物理通道映射的逻辑插针名(如插口所提供)之外，可使用若干属性来指定测试机资源。例如，选项可用于定义通道的特定硬件配置，其可为测试专用、供货商专用、和/或测试系统专用。这些将使用插针模式选项(Pin Mode Options)来描述，且经由插针模式选项文件获得。 

插针模式选项(Pin Mode Options)定义将支持测试机通道的特殊选项或模式的配置。例如，可将其用于选择和配置通道多路复用(multiplexing)。插针模式选项较佳的是仅用作测试计划初始化流程的部分，因为其可能要求有意义的通道配置。插针选项语法支持供货商定义的选项。下文展示了一个范例： 

PinModeOptions 

{ 

   clock    IN   double； 

   a0       OUT     single； 

}； 

测试环境配置 

如前文所指出，资源定义文件(Resources.rsc)、系统配置文件(Sys.cfg)和模块配置文件(Modules.cfg)较佳的是可在“熟知”位置获得。此“熟知”位置为系统环境变量Tester_ACTIVE_CONFIGS的值所指定的目录。例如，如果Tester_ACTIVE_CONFIGS的值为目录F:\Tester_SYS\configs，则系统预期存在下列文件： 

F:\Tester_SYS\configs\Resources.rsc 

F:\Tester_SYS\configs\Sys.cfg 

F:\Tester_SYS\configs\Modules.cfg 

在安装过程中，存在于主计算机上的安装和配置管理系统(ICM)将较佳 地设定Tester_ACTIVE_CONFIGS的值。ICM每次建立上述文件之一的新版本时，其将该新版本放置在Tester_ACTIVE_CONFIGS所指定的位置。注意到，除了上述三个文件之外，例如模拟配置文件等其它系统配置文件也放置在Tester_ACTIVE_CONFIGS所指出的位置。 

B.测试程序开发规则 

测试机系统的两个面向终端用户的组件之一为测试环境。另一组件为藉由测试机而变为终端用户(即，测试工程师和测试类开发人员)可利用的编程程序。 

编程环境的基本组件为测试计划。测试计划使用测试类(其为对测试接口所指示的测试的不同实现)，其实现测试数据和用于特定测试类型的代码的分离。 

计划可为直接编写成C++测试程序，或以测试计划描述文件来描述，测试程序生成器(Test Program Generator)(转译器402)对其进行处理以产生面向对象的代码，例如C++代码。随后可将生成的C++代码编译成可执行测试程序。用户在测试计划描述文件中指定生成(populating)测试类实例所要求的数据，例如，级别、计时等等。 

测试程序包括一组用户书写文件，其指定对元件运行测试的细节。本发明的一实施例包括允许用户使用C++结构来书写这些文件的多组规则。 

根据本发明该实施例的要求之一为遵循开放式架构测试系统的模块性。模块开发允许用户书写涉及测试的不同方面的单个组件，并且随后允许将这些组件混合并以各种方式匹配以产生完整的测试程序。根据本发明较佳实施例的测试程序包括如下的一组文件： 

files*.usrv for user variables and constants； 

files*.spec for specification sets； 

files*.lvl for levels； 

files*.tim for timings； 

files*.tcg for test condition groups； 

files*.bdefs for bin definitions； 

files*.ph for a pre-header，files for custom functions and test classes. 

files*.ctyp for custom types； 

files*.cvar for custom variables；and 

files*.tpl for test plans. 

上述文件扩展名是为了便于文件分类而建议使用的惯常作法。单一测试程序较佳地包括一单一测试计划文件和其引入的文件。“引入”表示具有如下数据的其它文件，这些数据既不是引入器直接引用(指定引入的文件)也不是藉由引入器所直接引用的其它文件引入。测试计划文件可定义全程符、流程和其中的其它此等对象，或者其可从其它文件引入此信息。这些规则允许任何前述组件处于其自身单个文件中，或直接内联入测试计划文件。注意测试计划在概念上类似于C-语言main()函数。 

测试程序特征 

用户变量和常量(User Variables and Constants)， 

规约集(Specification Set)， 

级别(Levels)， 

计时(Timing)， 

测试条件(Test Conditions)， 

箱定义(Bin Definition) 

前报头(Pre-Headers)， 

自定义类型(Custom Types)， 

自定义变量(Custom Variables)， 

测试计划(Test Plan) 

测试程序标识符较佳地以大小写字母开头，且随后可具有任何数量的字母、数字或下划线(_)字符。其具有在下列描述中所提供的若干关键字。在此文献中，这些关键字在视觉上以使用黑体字型(例如Version)的代码来识别。保留关键字且较佳的是不被用作标识符。存在若干特殊符号，例如{，}、(，)、：，和下文描述的其它符号。 

测试对象的确立 

测试描述文件的引入使引入文件能够表示藉由此引入文件获得的对象的名称。此允许引入文件引用由该引入文件所命名的对象。考虑到引入插针描述文件xxx.pin的插口文件aaa.soc。可存在另一个也引入xxx.pin的bbb.soc文件。然而，这些引入均不会导致由xxx.pin所描述的对象的出现。其仅仅是对已经假设存在的引用对象。 

出现以下问题：这些对象何时出现？此为测试计划文件本质上不同之处。在类似于C的语言中，其可以是其中具有main()例行程序的文件。测试计划文件中的“引入”语句将确立(elaborate)这些对象，也就是说，导致出现这些对象。下文所示的测试计划mickey.tpl导致确立xxx.pin和aaa.soc中 的对象。 

#File for Mickey’s TestPlan 

Version 3.4.5； 

# 

#These import statements will actually cause the 

#objects to come into existence: 

# 

Import xxx.pin；#Elaborates pin and pin-group objects 

Import aaa.soc；#Elaborates site socket map objects 

#Other imports as necessary 

Flow Flow1 

{ 

} 

测试计划中xxx.pin的引入导致确立xxx.pin中所声明的所有插针和插针组对象。此描述如下：“确立文件xxx.pin”。测试计划不需要直接引入所需确立的所有文件。如果下列两个语句中的任一个为真，则藉由文件y引入文件x： 

1.y具有命名x的引入语句；或 

2.x藉由z引入，且y具有命名z的引入语句。 

在编译测试程序时，将在由测试计划所引入的文件中确立所有对象。将由测试计划所引入的该组文件拓扑分类以产生确立文件的顺序。将由测试计划所引入的该组文件称为测试计划的引入闭包(import closure)。如果测试计划的引入闭包不能被拓扑分类，则必定存在一引入循环。这种情形是错误的且将被编译器拒绝。 

用户变量和常量 

将使用用户变量和常量来定义全程符变量和常量。常量为其值在编译时间被约束且不能改变的对象。举例而言，最大整数值可为一常量。在另一方面，与变量绑定的表达式在运行时间可藉由API来改变。 

整数， 

无符号整数， 

双精度(Double)， 

字符串， 

以伏特计的电压(V)， 

以伏特每秒计的电压摆动(VPS)， 

以安培计的电流(A)， 

以瓦计的功率(W)， 

以秒计的时间(S)， 

以米计的长度(M)， 

以赫兹计的频率(Hz)， 

以欧姆计的电阻(Ohm)，和 

以法拉计的电容(F)。 

Integer(整数)、UnsignedInteger(无符号整数)、Double(双精度)和String(字符串)等类型被称为基本类型(Basci Type)。基本类型不具有测量单位。不是基本类型的初等类型为双精度，其具有相关测量单位和标度。定标符号为通用工程定标符号： 

p(微微)表示10-12，例如pF(法拉) 

n(毫微)表示10-9，例如nS(毫微秒) 

u(微)表示10-6，例如uS(微秒) 

m(毫)表示10-3，例如mV(毫安培) 

k(千)表示10+3，例如kOhm(千欧姆) 

M(兆)表示10+6，例如MHz(兆赫兹) 

G(十亿)表示10+9，例如GHz(十亿赫兹) 

具有用户变量和常量的独立文件将具有扩展名.usrv。下文为具有一些全程符常量的文件的范例。具有一些变量的文件的范例稍后给出。 

#------------------------------------------------------- 

#File limits.usrv 

#------------------------------------------------------- 

Version 1.0.0； 

# 

#This User Vars collection declaration declares a set of 

#globally available variables and constants. 

# 

UserVars 

{ 

   #Some constant Integer globals used in various places. 

   Const Integer    MaxInteger＝2147483647； 

   Const Integer    MinInteger＝-2147483648； 

   #Smallest value such that 1.0+Epsilon！＝1.0 

   Const Double Epsilon＝2.2204460492503131e-016； 

   #Some important constants related to Double 

   Const Double MaxDouble＝1.7976931348623158e+308； 

   Const Double MinDouble＝-MaxDouble； 

   Const Double ZeroPlus＝2.2250738585072014e-308； 

   Const Double ZeroMinus＝-ZeroPlus； 

} 

上文声明的该组UserVar被看作是′＝′左边的变量的定义。因此，较佳的是单独出现变量或常量定义，且应该将其初始化。 

如上文所提及，常量一旦被定义则不应改变。与常量绑定的表达式可涉及先前定义的常量和文字值。反之，变量可经由API改变。与变量绑定的表达式可涉及先前定义的变量、常量和文字值。 

每个变量与一个在运行时间保持的表达式对象绑定。此提供在运行时间内改变与变量相关的表达式的能力，且随后可重新评估所有变量。表达式对象为变量或常量定义右侧的解析形式(parsed form)。在一实施例中，没有为在运行时间内改变的常量提供任何程序。其值较佳的是在编译时间被固定。 

测试计划引入闭包(import closure)中可存在任何数量的这些具有全程符的文件。尽管前述全程符文件是一组数字界限，但是此处是一组使用工程测量单位的工程全程符，和一些随机用户变量： 

#---------------------------------------------------------- 

#File myvars.usrv 

#---------------------------------------------------------- 

Version 0.1； 

# 

#This declares a UserVars collection of some engineering 

#globals. 

# 

UserVars MyVars 

{ 

   #Engineering quantities. 

   Const Voltage VInLow＝0.0；         #0 Volts 

   Const Voltage VInHigh＝5.0；        #5 Volts 

   Const Voltage VOutLow＝400.0mV；       #400 milliVolts 

   Const Voltage VOutHigh＝5.1；          #5.1 Volts 

   Const Time DeltaT＝2.0E-9；         #2 nanoseconds 

   Const Time ClkTick＝1.0ns；         #1 nanosecond 

   Const Resistance R10＝10.0 kOhms；  #10 kilo Ohms 

   #Some variables are declared below. 

   Current ILow＝1.0mA；               #1 milliAmp 

   Current IHigh＝2.0mA；              #2 milliAmp 

   Power PLow＝ILow*VInLow；           #Low power value 

   Power PHigh＝IHigh*VInHigh；      #High power value 

   # 

   #An array of low values for all A bus pins. 

   #The vil for A0 will be in ABusVil[0]，for A1 

   #in ABusVil[1]，and so on. 

   # 

   Voltage ABusVil[8]＝{1.0，1.2，Others＝1.5}； 

} 

编译器较佳的是检验单位和类型是否匹配。注意到，由于电压乘以电流产生功率，因此将编译上文PLow和PHigh的等式。然而，通常不编译如下的语句： 

# 

#Does not compile because a Current and a Voltage cannot be added 

#to yield a Power. 

# 

Power Pxxx＝IHigh+VInHigh； 

编译器将允许特定自动类型转换： 

Power Pxxx＝2；   #Set the power to 2.0 watts 

Integer Y＝3.6；  #Y gets assigned 3 

Power Pyyy＝Y；   #Pyyy gets assigned 3.0 watts 

Double Z＝Pyyy；  #Pyyy gets converted to a unitless Double 

还允许显式类型转换成Double(双精度)、UnsignedInteger(无符号整数)和Integer(整数)。 

Power Pxxx＝3.5； 

#Explicit type conversion is allowed，but not required. 

#X becomes3.5 

Double  X＝Double(Pxxx)；   #X becomes 3.5 

Integer Y＝Integer(Pxxx)；  #Y becomes 3 

藉由转换成中间基本类型，还可在无关类型之间转换： 

Power Pxxx＝3.5； 

#Explicit type conversion is required. 

Length L＝Double(Pxxx)；#L becomes 3.5 meters 

Voltage V＝Integer(Pxxx)；#V becomes 3.0 Volts. 

TestPlan对象提供UserVars类，其为一包括名称及其相关表达式、值和类型的集合。用户变量可加入Default User Variables Collection(默认用户变量集合)，或加入Named User Variables Collection(命名的用户变量集合)。上文范例中的UserVars声明(其不具有指定的名称)加入该default(默认)集合。然而，其可能显明地将一集合命名如下： 

#Declare X and Y in the MyVars UserVars collection. 

UserVars MyVars 

{ 

   Integer X＝2.0； 

   # 

   #Refers to the above X，and to the globally 

   #available MaxInteger from the default 

   #UserVars collection. 

   # 

   Integer Y＝MaxInteger-X； 

} 

#Declare X，Y1 and Y2 in the YourVars UserVars collection. 

UserVars YourVars 

{ 

   Integer X＝3.0； 

   #Refers to the X from MyVars. 

   Integer Y1＝MaxInteger-MyVars.X； 

   #Refers to the X declared above. 

   Integer Y2＝MaxInteger-X； 

} 

#More variables being added to the MyVars collection 

UserVars MyVars 

{ 

   # 

   #Refers to X and Y from th earlier declaration 

   #of MyVars. 

   # 

   Integer Z＝X+Y； 

} 

UserVars集合中的名称解析如下进行： 

如果名称是限定的(qualified)，即，名称包括用点分开的两个部分，则 变量来自一命名的用户变量集合，其藉由点之前的片段来命名。因此，上文的MyVars.X表示MyVars集合中的X。名称″_UserVars″可用于显明地表示默认用户变量集合。 

如果名称不是限定的，并且在当前集合中存在相同名称的常量或变量，则该名称解析成该常量或变量。 

否则，名称解析成默认用户变量集合中的常量或变量。 

对UserVars集合中定义块的评估可被看作从第一个定义到最后一个定义相继地发生。这可能会要求在使用前定义每个变量。 

此外，一个UserVars集合可能具有若干定义块，其中每个定义块定义若干变量。所有这些定义块可被看作以测试计划中声明的顺序来评估，且随后同样以声明顺序来检验每个区块的变量。 

最后，可存在若干UserVars集合，其中的每一个定义若干定义块上的变量。所有的变量再次可被看作是以声明顺序来初始化。因此，在上文的范例中，评估顺序将为：MyVars.X、MyVars.Y、YourVars.X、YourVars.Y1、YourVars.Y2、MyVars.Z。 

当UserVars集合使用来自另一集合的变量时，其较佳的是仅使用变量的原始值。集合之间不存在相关信息。因此，基于相关性的重新评估可被限制到一单一集合。 

每个用户变量集合表示C++UserVars类的一个实例。将C++UserVars类的默认对象命名为″_UserVars″。没有被命名的UserVars声明中的变量来自默认用户变量集合，且被添加到此默认对象。将命名用户变量集合中的变量添加到具有该名称的C++UserVars类的一个对象中。在上文的范例中，″MyVars″C++对象将以具有变量X、Y和Z结束。 

用户变量的C++ 

将用户变量作为n-元组的集合来实现，其中w-元组具有名称字符串、const/var布尔值、作为枚举值的类型和作为表达式树的表达式。名称的表达式可通过一个调用来设定： 

enum ElemenaryType{UnsignedIntegerT，IntegerT， 

                   DoubleT，VoltageT，...}； 

Status setExpression(const String& name， 

                   const bool isConst， 

                   const elementaryType， 

                   const Expression& expression)； 

类型Expression是对应于赋值右侧的文本的解析形式。存在一个全程 可获得的UserVars的实例。例如，藉由下文所示的该组调用来实现limits.usrv(cf.page)中的这组用户变量： 

_UserVars.setExpression(“MaxInteger”，true，IntegerT， 

                           Expression(2147483647))； 

_UserVars.setExpression(“MinInteger”，true，IntegerT， 

                           Expression(-2147483648))； 

_UserVars.setExpression(“Epsilon”，true，DoubleT， 

                           Expression(2.2204460492503131e-016))； 

_UserVars.setExpression(“MaxDouble”，true，DoubleT， 

                           Expression(1.7976931348623158e+308))； 

_UserVars.setExpression(“MinDouble”，true，DoubleT， 

                           Expression(“-MaxDouble”))； 

_UserVars.setExpression(“ZeroPlus”，true，DoubleT， 

                           Expression(2.2250738585072014e-308))； 

_UserVars.setExpression(“ZeroMinus”，true，DoubleT， 

                           Expression(“-ZeroPlus”))； 

下文是可以为myvars.usrv中所声明的变量执行的C++语句： 

myVars.setExpression(“VInLoW”，ture，VoltageT， 

                       Expression(0.0))； 

myVars.setExpression(“VInHigh”，true，Voltaget， 

                       Expression(5.0))； 

myVars.setExpression(“DeltaT”，true，TimeT， 

                       Expression(2.0E-9))； 

myVars.setExpression(“ClkTick”，true，TimeT， 

                       Expression(1.0E-9))； 

myVars.setExpression(“R10”，true，ResistanceT， 

                       Expression(10.0E+3))； 

myVars.setExPression(“ILow”，false，CurrentT， 

                       Expression(1.0E-3))； 

myVars.setExpression(“IHigh”，false，CurrentT， 

                       Expression(2.0E-3))； 

myVars.setexpression(“PLow”，false，PowerT， 

                       Expression(“ILow*VInLow”))； 

myVars.setExpression(“PHigh”，false，PowerT， 

                       Expression(“IHigh*VInHigh”))； 

myVars.setExpression(“ABusVil[0]”，false，VoltageT， 

                       Expression(1.0))； 

myVars.setExpression(“ABusVil[1]”，false，VoltageT， 

                       Expression(1.2))； 

myVars.setExpression(“ABusVil[2]”，false，VoltageT， 

                       Expression(1.5))； 

myVars.setExpression(“ABusVil[3]”，false，VoltageT， 

                       Expression(1.5))； 

myVars.setExpression(“ABusVil[4]”，false，VoltageT， 

                       Expression(1.5))； 

myVars.setExpression(“ABusVil[5]”，false，VoltageT， 

                       Expression(1.5))； 

myVars.setExpression(“ABusVil[6]”，false，VoltageT， 

                       Expression(1.5))；  

myVars.setExpression(“ABusVil[7]”，false，VoltageT， 

                       Expression(1.5))； 

在上文的代码中，Expression类较佳的是具有表示表达式解析形式的构造函数。表达式具有若干构造函数(constructor)，包括一个采用字符串文字并对其进行解析的构造函数，和另一个采用字符串文字以便仅用作字符串文字的构造函数。这些藉由附加参数来加以区分，上文为了可读性目的而没有指定这些附加参数。 

默认用户变量集合中的用户变量将藉由类UserVars的_UserVars对象来管理。命名用户变量集合Xxx中的用户变量将藉由名为Xxx的UserVars对象来管理。 

UserVars的运行时间API 

包括这些名称和表达式的C++UserVars类导出一个应用程序编程接口(API)以便在运行时间评估并修改这些值。对与UserVars相关的表达式的修改还提出了以下问题：何时重新评估UserVars以及该评估将产生何种影响。 

首先考虑何时就引发作为改变结果的对UserVars重新评估的问题。如果其在改变对表达式时立即被引发，则用户将不能在引发重新评估之前进行一系列的相关改变。因此，藉由用户的显式调用引发重新评估。 

其次可考虑重新评估的影响。存在三种根据较佳实施例可获得的重新评估： 

UserVars Collection Re-evaluation(UserVars集合重新评估)是局限于单一UserVars集合的重新评估。此操作的语义是再次重新评估此集合的所有变量。 

UserVars Targeted Re-evaluation(目标UserVars重新评估)是局限于对与单一名称绑定的表达式的改变的重新评估。仅考虑此特定改变，此将允许用户改变单一名称的表达式，并且导致对集合重新评估的发生。 

User Vars Global Re-evaluation(UserVars全程符重新评估)是对所有UserVars集合的重新评估。此基本上引发以声明顺序对所有UserVars集合的重新评估并且成本极高。 

所有上述重新评估在重新评估UserVars之后将重新评估相关对象，例如级别、计时等等。相关对象将具有一个脏位(dirty bit)，表示其需要重新评估。每当UserVars集合在程序上变化时，其还将设定所有相关对象上的脏位。此将引发对相关对象的重新评估。 

总而言之，命名UserVars集合有助于容纳重新评估影响问题。重新评估通常局限于单一集合。使用UserVars的一种简单方式是仅使用默认UserVars集合。以此方式，对于所有UserVars都可发生进行改变的连锁效应。可藉由具有若干命名UserVars集合来限制此连锁效应。 

多个集合可引用来自彼此的变量，但是与变量绑定的值在使用时是受约束的。在UserVars集合之间不具有相关性。 

随于每个初等类型Xxx(无符号整数、电流、电压、等等)，一种方法可获得以下值： 

Status getXxxValue(const String& name，Xxx& value)const； 

注意不存在直接设定值的方法，其是通过用于设定表达式的调用，之 后藉由reevaluateCollection()的调用来完成。 

获得和设定表达式的方法。setExpression()调用还可用于定义到目前为止尚未被定义的新变量。 

enum elementaryType 

{ 

   UnsignedIntegerT，IntegerT，DoubleT，VoltageT，... 

}； 

Status getExpression(const String& name， 

                        Expression& expression)const； 

Status setExpression(const String& name， 

                        const bool isConst， 

                        const elementaryType， 

                        const Expression& expression)； 

如果表达式产生循环相关性，则setExpression()调用有可能失败。举例而言，如果进行下列两个调用，则第二个调用将由于循环相关性故障而失败。 

setExpression(″X″，true，MegerT， Expression(″Y+1″))； 

setExpression(″Y″，true，MegerT，Expression(″X+1″))； 

这是因为与名称绑定的值为方程式而不是赋值。当变量的值改变时，提供重新评估所有直接和间接相关名称的方法。例如上述对的方程式导致不允许的循环相关性。 

注意此API通常不支持未经请求的重新评估。对setExpression()的调用可能不会自动导致重新评估该变量和依赖于该变量的所有其它变量。与所有变量绑定的值将保持不变，直到发生对reevaluateCollection()(见下)的调用。 

一种确定特定名称是否是常量的方法： 

Status getIsConst(const String& name，bool& isConst)； 

一种获得类型enum ElementaryType的方法： 

    enum ElementaryType 

    { 

       UnsignedIntegerT，IntegerT，DoubleT，VoltageT，... 

    }； 

    Status getType(const String& name， 

                    ElementaryType& elementaryType)const； 

UserVars集合重新评估方法： 

Status reevaluateCollection()； 

这些类将保持与所有变量相关的方程式及其相关性。当调用此方法时，将重新评估所有的变量。 

UserVars目标重新评估方法： 

          Status reevaluateTargeted(const String& var)； 

这些类将保持与所有变量相关的方程式及其相关性。当调用此方法时，将重新评估所命名的变量及其所有相关变量。 

UserVars全程符重新评估方法： 

          static Status reevaluateAHCollections()； 

这些类将保持与所有变量相关的方程式及其相关性。当调用此方法时，以未指定的顺序在所有UserVars集合上调用reevaluateCollection()。 

一种确定是否定义一特定名称的方法： 

Status getIsDefined(const String& name，bool& isDefined)const； 

一种确定当前定义的所有用户变量的方法： 

          Status getNames(StringList& names)const； 

一种删除当前定义的变量的方法： 

          Status deleteName(const String& name)； 

如果该名称用于涉及其它变量的表达式，则此操作将失败。 

一种获得一列依赖于特定变量或常量的变量和常量的方法： 

Status getDependents(const String& name，StringList& dependents)； 

规约集 

规约集用于提供可采用基于选择器的值的变量集合。例如，考虑到下列规约集，其使用选择器Minnie、Mickey、Goofy和Daisy： 

#---------------------------------------------------------- 

#File Aaa.spec 

#---------------------------------------------------------- 

Version 1.0； 

Import Limits.usrv； 

SpecificationSet Aaa(Minnie，Mickey，Googy，Daisy) 

{ 

   Double xxx＝1.0，2.0，3.0，4.0； 

   Integer yyy＝10，20，30，40； 

   Integer zzz＝MaxInteger-xxx， 

                 MaxInteger-xxx-1， 

                 MaxInteger-xxx-2， 

                 MaxInteger-xxx； 

   #The following declaration associates a single 

   #value，which will be chosen regardless of the 

   #selector.It is equivalent to: 

   #  Integer www＝yyy+zzz，yyy+zzz，yyy+zzz，yyy+zzz 

   Integer www＝yyy+zzz； 

} 

上述具有择器Goofy的规约集将进行下列关联： 

xxx＝3.0； 

yyy＝30； 

zzz＝MaxInteger-xxx-2； 

www＝yyy+zzz 

下文将在描述了测试(Test)时论述设定规约集上的选择器的操作。 

句法上讲，规约集是一列选择器(上述范例中的Minnie、Mickey、Goofy和Daisy)，连同一列变量定义(上述范例中的xxx、yyy、zzz和www)。变量的定义涉及一列表达式，其与选择器的列表一样长或包括单一表达式。 

可将规约集概念性地看作表达式的矩阵，其列为选择器，行为变量，且其入口为表达式。特定选择器(列)将每个变量(行)与特定表达式(入口)绑定。如果列表具有单一表达式，则其表示一行，其中表达式重复与 选择器数量相同的次数。 

规约集可出现在两个独立的上下文中。其可在一.spec文件中独立地声明，在此状况下，其如上文所示而出现。这些是被命名的规约集。否则，可在一个测试条件组(Test Condition Group)中声明局部规约集(localspecification sets)。在此声明中，不为规约集将提供名称。其将为局部规约集，仅对封入的测试条件组具有意义。 

命名的规约集可以仿照命名用户变量集合(named user variablescollection)。可将上述规约集制成名为Aaa的UserVars集合，其将具有用于xxx[Minnie]、xxx[Mickey]、xxx[Goofy]、xxx[Daisy]、yyy[Minnie]等的表达式。当在测试的上下文中选择一特定选择器(比如，Mickey)时，可从变量名称和规约集名称获得xxx、yyy和zzz的值。 

测试条件组可具有最多一个规约集，其或者为局部规约集，或者为对所命名的规约集的引用。局部规约集仅出现在测试条件组中，且不具有显明指定的名称。此种规约集具有一隐含名称，其藉由封入的测试条件组的名称定义。为了解析可显现若干规约集和若干UserVars集合的点之处的测试条件组中名称，采用下列规则： 

1.如果名称是限定的，则其必须可在命名的用户变量集合中被解析。 

2.如果名称不是限定的，则该名称可在局部规约集(如果其在测试条件组条件中被声明)中解析或在命名的规约集(如果在测试条件组中引用一个命名的规约集)中解析。 

3.如果未藉由较早规则解析名称，则在默认用户变量集合中对其进行解析。 

为了说明这些规则，考虑下列使用测试条件组(稍后将详细说明)的范例。 

Version 1.2.3； 

Import limits.usry；#Picks up the limits UserVars file above. 

Import aaa.spec；   #Picks up the Specification Set AAA above. 

TestConditionGroup TCG1 

{ 

   SpecificationSet(Min，Max，Typ) 

   { 

      vcc＝4.9，5.1，5.0； 

   } 

   #Rule 1：Resolution in a named user variables collection. 

   #A reference to MyVars.VInLow refers to VInLow from MyVars. 

   #Rule 2：Resolution in a local specification set. 

   #A reference to“vcc”here will resolve in the context 

   #of the local specification set above. 

   #Rule 3：Resolution in default user variables collection. 

   #A reference to“MaxInteger”here will resolve to limits.usrv. 

   #Error：Resolution of xxx 

   #A reference to xxx does not resolve because it is neither in 

   #the local specification set，nor in limits.usrv. 

   #Error：Resolution of Aaa.xxx 

   #Looks for a named UserVars collection named Aaa.The named 

   #specification set does not qualify. 

} 

TestConditionGroup TCG2 

{ 

   SpecificationSet Aaa；#References the imported specification set 

   #Rule 1：Resolution in a named user variables collection. 

   #A reference to MyVars.VInLow refers to VInLow from MyVars. 

   #Rule 2：Resolution in a named specification set. 

   #A reference to“xxx”here will resolve in the context 

   #of the local specification set Aaa above. 

   # Rule 3：Resolution in default user variables collection. 

   #A reference to“MaxInteger”here will resolve to limits.usrv. 

   #Error：Resolution of vcc 

   #A reference to vcc does not resolve because it is neither in 

   #the named specification set Aaa，nor in limits.usrv. 

   #Error：Resolution of Aaa.xxx 

   #Looks for a named UserVars collection named Aaa.The named 

   #specification set does not qualify. 

} 

规约集中的对名称的解析(上文的规则)要求在要求名称解析时启用该组的一个选择器。藉由指定一个选择器可在测试中引用测试条件组的这一事实可实施此操作。 

规约集的C++ 

使用上述规则，可藉由C++规约集类实现规约集。除了用于选择器的额外的字符串参数之外，规约集类具有与UserVars类基本上相同的API。因此，对此API不进行详细描述。 

所有命名的规约集较佳地与该名称的C++对象相关联。测试条件组上下文中的局部规约集将具有对该测试条件组来说是唯一的名称。在其中定义局部规约集的测试条件组上下文之外引用该局部规约集的变量是非法的。 

级别 

级别用于指定插针和插针组的参数。其为下列形式的声明的集合； 

<in-or-pin-group-name> 

{ 

  <pin-param-1>＝xxx； 

  <in-param-2>＝yyy； 

} 

此声明指定所命名的插针或插针组的各个参数的设定。例如，此语句可用于设定InputPins(输入插针)组中所有插针的VIL值，如下文范例中所示： 

#---------------------------------------------------------- 

#File pentiumlevels.lvl 

#---------------------------------------------------------- 

Version 1.0； 

Import pentium3resources.rsc； 

Import pentium3pins.pin； 

Levels Pentium3Levels 

{ 

   # 

   #Specifies pin-parameters for various pins and 

   #pin groups using globals and values from 

   #the specification set. 

   #     

   #The order of specification is significant. 

#Pin parameters will be set in order from 

#first to last in this Levels section，and 

#from first to last for each pin or pin-group 

#subsection. 

# 

#From the imported pin description file pentium3pins.pin， 

#the InPins group is in the“dpin”resource.From the 

#imported resource definition file pentium3resources.rsc， 

#the“dps”resource has parameters named VIL and VIH. 

# 

InPins{VIL＝v_il；VIH＝v_ih+1.0；} 

#The following statement requires a delay of 10 uS after 

#the call to set the InPins levels.Actual delay will be 

#a small system defined range around 10.0E-6: 

#    10.0E-6-delta＜＝actual＜＝10.0E-6+delta 

Delay 10.0E-6； 

# 

#For the OutPins，the levels for the parameters 

#VOL and VOH are specified. 

# 

OutPins{VOL＝v_ol/2.0；VOH＝v_oh；} 

#The clock pin will have special values. 

Clock{VOL＝0.0；VOH＝v_ih/2.0；} 

#A Delay of 10 uS afterthe call to setClock levels. 

#This is a minimum delay，that is guaranteed to be for 

#at least 10.0 uS，though it may be a little more: 

#    10.0E-6＜＝actual＜＝10.0E-6+delta 

MinDelay 10.0 uS； 

  # 

  #The PowerPins group is in the“dps”resource.Pins of this 

  #pin group have special parameters: 

  #PRE_WAIT specifies the time to wait after voltage 

  #   reached its final value to start pattern 

  #   generation.Actual wait time will be a small 

  #   system defined range around PRE_WAIT(see) 

  #POST_WAIT specifies the time to wait after pattern 

  #   generation ends to shut down the power.Actual 

  #   wait time will be a small system defined range 

  #   around PRE_WAIT(see). 

  # 

  PowerPins 

  { 

    PRE_WAIT＝10.0ms； 

    POST_WAIT＝10.0ms； 

    #VCC reaches its final value of 2.0 V from its 

    #present value in a ramp with a Voltage Slew Rate 

    #of±.01 Volts per Second. 

    VCC＝Slew(0.01，2.0V)； 

  } 

} 

Levels Pentium4Levels 

{ 

  #... 

} 

如上文所见，每个级别块较佳地由大量级别项组成，其中每一个指定一插针或插针组的参数。每个级别块可指定大量的资源参数。设定这些级别值的运行时间语义如下： 

级别块的级别项以声明顺序进行。出现在一个以上级别块中的任何插针将被多次处理。应该以规约顺序保持并应用单一参数的多个规约值。 

以指定级别块中资源参数的顺序来处理级别块中的这些参数。 

延迟(Delay)语句导致设定级别的处理在设定下一组级别之前暂停大 约所指示的持续时间。实际等待时间可处于大约为指定延迟的较小系统定义范围内。因此，如果延迟为t秒，则实际延迟将满足： 

t-Δt＜＝实际等待＜＝t+Δt 

延迟语句将级别规约划分成大量子序列，其中每一个将要求独立的测试条件存储器设定以进行处理。 

MinDelay(最小延迟)语句导致设定级别的程序在设定下一组级别之前暂停至少指定的持续时间。实际等待时间可处于较小系统定义的范围内，其具有指定最小延迟的最小值。因此，如果最小延迟为t秒，则实际延迟将满足： 

t＜＝实际等待＜＝t+Δt 

MinDelay语句将级别规约划分成若干子序列，其中每一个子序列将要求独立的测试条件存储器设定以进行处理。 

每个插针或插针组名称在插针描述文件(suffix.pin)中的一个资源中被精确地指定，且因此具有在资源文件(suffix.rsc)中指定的一个特定组的可行资源参数。所有命名的参数必须来自这组可行资源参数，且必须为与用于设定其值的表达式相同的初等类型。关于资源参数名称和类型的信息来自资源文件。 

资源文件Resources.rsc被隐式引入，并提供具有标准资源参数的名称和类型的测试机，例如dpin和dps。 

向资源参数分配可使用UserVars的表达式和来自命名的规约集或当前可见局部规约集的值。 

Dps插针资源具有特殊参数PRE_WAIT和POST_WAIT。PRE_WAIT参数指定从功率插针到达其目的电压到开始时间模式产生所需经历的时间。POST_WAIT参数指定从时间模式产生停止到功率插针切断时需经历的时间。 

Dps插针还指定电压参数如何达到其终值。和其他插针参数一样，仅藉由一方程式就可进行此种指定。在此情形下，若硬件允许则可达到此值。其还可以使用Slew(转换)语句来指定。Slew语句指定电源电压以指定绝对电压转换速率(Voltage Slew Rate)由一匀变(ramp)的初始值达到其终值。 

级别的C++ 

藉由上述规则，可书写支持下列操作的C++级别对象： 

There is an operation 

                       Status setParameter(const String& pinOrPinGroupName， 

                                              const String& parameterName， 

                                              ElementaryType elementaryType， 

                                              const Expression& Expression)； 

此操作使一表达式与插针或插针组的参数相绑定。举例而言，藉由以下设定dpin.InPins VIH值： 

setParameter(″InPins″，″VIH″，VoltageT， 

                Expression(″v_ih+1.0″)； 

将为级别对象中的所有声明多次调用此操作。 

There is an operation 

                      Status assignLevels(const String& selector)； 

其将检查并发布所有的预定模块级接口以便以规约顺序分配所有的参数级别，如前述。选择器参数用于根据前文指定的规则在表达式中解析名称。 

测试条件组 

测试条件组子语言封装对规约、计时和级别的描述。通常使用参数来指定计时对象。参数可用于计时以指定各种脉冲的前导沿和拖尾沿。类似地，可藉由指定各个电压级别的的最大、最小和典型值来对级别进行参数化。测试条件组(TCG)对象对规约和基于这些规约的调谐和级别的实例化进行汇总。 

TestConditionGroup(测试条件组)声明包括一可选的SpecificationSet(规约集)。该规约集声明可为内联(且未命名的)局部规约集，或者其可为对在其它地方声明的命名的规约集的引用。TCG声明中的可选规约集声明后接至少一个级别或计时声明。其可具有处于任何顺序的级别和计时两者。然而，不允许具有一个以上的级别和计时声明。在句法上实施这些限制。 

TCG中的规约集声明类似于独立声明的规约集，不同之处在于其没有名称。其名称隐含地为封入的TCG的名称。计时声明包括来自指定计时文件的计时对象的单一声明。下面是具有测试条件组的文件的范例： 

#---------------------------------------------------------- 

#File myTestConditionGroups.tcg 

#---------------------------------------------------------- 

Version 0.1； 

Import pentiumlevels.lvl； 

Import edges.spec； 

Import timing 1.tim； 

Import timing2.tim； 

TestConditionGroup TCG1 

{ 

   #This Local SpecificationSet uses user-defined selectors 

   #“min”，“max”and“typ”.Any number of selectors with any 

   #user defined names is allowed. 

   # 

   #The specification set specifies a table giving values for 

   #variables that can be used in expressions to initialize 

   #timings and levels.The specification set below defines 

   #values for variables as per the following table: 

   #       min         max        typ 

   #  v_c     2.9        3.1        3.0 

   #  v_ih vInHigh+0.0 vInHigh+0.2 vInHigh+0.1 

   #  v_il vInLow+0.0 vInLow+0.2 vInLow+0.1 

   #... 

   #A reference such as“vInHigh”must be previously defmed 

   #in a block of UserVars. 

   # 

   #Thus，if the“max”selector was selected in a functional 

   #test，then the“max”column of values would be bound to 

   #the variables，setting v_cc to 3.1，v_ih to vInHigh+2.0 

   #and so on. 

   #     

   #Note that this is a local specification set，and has no 

   #name. 

   SpecificationSet(min，max，typ) 

   { 

      #Minimum，Maximum and Typical specifications for 

      #voltages. 

      Voltage v_cc＝2.9，3.1，3.0； 

      Voltage v_ih＝vInHigh+0.0， 

                     vInHigh+0.2， 

                    vInHigh+0.1； 

    Voltage v_il＝vInLow+0.0， 

                    vInLow+0.2， 

                    vInLow+0.1； 

    #Minimum，Maximum and Typical specifications for 

    #leading and trailing timing edges.The base 

    #value of 1.0E-6 uS corresponds to 1 picosecond， 

    #andis given as an example of using scientific 

    #notation for numbers along with units. 

    Timet_le＝1.0E-6 uS， 

                1.0E-6uS+4.0*DeltaT， 

                1.0E-6uS+2.0*DeltaT； 

    Time t_te＝30ns， 

                30ns+4.0*DeltaT， 

                30na+2.0*DeltaT； 

    } 

    #Refers to the Pentium3Levels imported earlier.It 

    #is one of possibly many levels objects that have been 

    #imported from the above file. 

    Levels Pentium3Levels； 

    #Refers to file timing1.tim containing the single 

    #timing Timing1.The filename should be quoted if 

    #it has whitespace characters in it. 

    Timings Timing1； 

} 

#Another test condition group 

TestConditionGroup TCG2 

{ 

   #ClockAndDataEdgesSpecs is a specification set which 

   #is available in the edges.specs file.Assume it has 

  #the following declaration: 

  #  SpecificationSet ClockAndDataEdgesSpecs(min，max，typ) 

  #  { 

  #     Time clock_le＝10.00uS，10.02uS，10.01uS； 

  #     Time clock_te＝20.00uS，20.02uS，20.01uS； 

  #     Time data_le＝10.0uS，10.2uS，10.1uS； 

  #     Time data_te＝30.0uS，30.2uS，30.1uS； 

  #  } 

  #A SpecificationSet reference to this named set is below: 

  SpecificationSet ClockAndDataEdgesSpecs； 

  #An inlined levels declaration.Since the associated 

  #specification set(above)does not have variables such 

  #as VInLow，VInHigh，VOutLow and VOutHigh，they must 

  #resolve in the default UserVars collection. 

  Levels 

  { 

    InPins{VIL＝VInLow；VIH＝VInHigh+1.0；} 

    OutPins{VOL＝VOutLow/2.0；VOH＝VOutHigh；} 

  } 

  #This Timing is from the file“timing2.tim”.The timings 

  #will need the leading and trailing edge timings for clock 

  #and data as specified in the above specification set. 

  Timings Timing2； 

} 

在上文的范例中，测试条件组TCG1描述具有三个选择器的规约集，这些三个选择器的名称为″min″、″typ″和″max″。可存在任何数量的不同选择器。在规约集的主体中，使用三联值(triple)初使化将变量v_il、v_ih、t_le和t_te，并与选择器对应。因此在上述范例中，具有选择器″min″的TCG1的实例(instantce)将绑定具有第一数值(vInputLow+0.0)的变量v_il。需要再次强调的是：规约集的选择器是用户定义的且可允许任何数量。唯一的要求是： 

规约集的选择器是唯一标识符。 

规约集中所指定的每个值与一个阵列的值相关，该阵列的值具有与该组选择器完全相同数量的元素。选取第i个选择器将导致每个值与其相关值 向量的第i个值绑定。 

在TCG中的规约集之后，可存在一个级别声明(Levels declaration)或计时声明(Timings declaration)或两者都存在。级别声明用于设定各个插针参数的级别。在规约集中识别的变量将用于设定这些级别，并允许基于用于初始化TCG的选择器将插针参数的不同实际值动态绑定。 

举例来说，考虑启用选择器″min″的测试。参照给出的规约集Pentium3Levels，InPins组中插针的插针参数″VIH″将藉由以下声明被初始化为表达式(v_ih+1.0)： 

InPins{VIL＝v_il；VIH＝v_ih+1.0；} 

当启用选择器″min″时，此解析成(VInHigh+0.0+1.0)。类似地，可基于规约集变量的所选值来初始化计时对象。不必具有计时和级别声明两者。任一者都可单独存在，或以任何顺序同时存在，如以下范例所说明： 

#---------------------------------------------------------- 

#File LevelsOnlyAndTimingsOnly.tcg 

#---------------------------------------------------------- 

Version 0.1； 

#A Levels-only Test Condition Group. 

TestConditionGroup LevelsOnlyTCG 

{ 

   SpecificationSet(Min，Max，Typ) 

   { 

      Voltage v_il＝0.0，0.2，0.1； 

      Voltage v_ih＝3.9，4.1，4.0； 

   } 

   #An inlined levels declaration Since the associated 

  #specification set(above)does not have variables such 

  #as VInLow，VInHigh，VOutLow and VOutHigh，they must 

  #resolve in the default UserVars collection. 

  Levels 

  { 

    InPins{VIL＝v_il；VIH＝v_ih+1.0；} 

    OutPins{VOL＝v_il/2.0；VOH＝v_ih；} 

  } 

} 

#A Timings-only Test Condition Group 

TestConditionGroup TimingsOnlyTCG 

{ 

    SpecificationSet(Min，Max，Typ) 

   { 

           Time t_le＝0.9E-3，1.1E-3，1.0E-3； 

   } 

   Timings Timing2； 

} 

然而，注意到一个TCG中不应该具有一个以上的计时和一个以上的级别。因此，总而言之，应存在至少一个计时或级别，且每一种最多具有一个。 

测试条件 

TestCondition(测试条件)对象将TCG约束到特定选择器。一旦如前述声明一个TCG，则可能声明如下TestCondition对象： 

TestCondition TCMin 

{ 

   TestConditionGroup＝TCG1； 

   Selector＝min； 

} 

    TestCondition TCTyp 

    { 

        TestConditionGroup＝TCG1； 

        Selector＝typ； 

    } 

    TestCondition TCMax 

    { 

        TestConditionGroup＝TCG1； 

        Selector＝max； 

     } 

These Test Conditions would be instantiated in a Test Plan as follows: 

     # 

     #Declare a FunctionalTest“MyFunctionalTest”that refers to three 

     #Test Condition Group instances. 

     # 

     Test FunctionalTest MyFunctionalTest 

     { 

         #Specify the Pattern List 

         PList＝pat1 Alist； 

         #Any number of TestConditions can be specified: 

         TestCondition＝TCMin； 

         TestCondition＝TCMax； 

         TestCondition＝TCTyp； 

     } 

TCG(测试条件组)中的名称解析 

上文论述了测试条件组中的名称解析。然而，有必要重申这些规则且下文再次给出： 

1.如果名称是限定的(cf.page)，则其必须可在命名的用户变量集合中被解析。 

2.如果名称不是限定的，则该名称可在局部规约集(如果其在测试条件组条件中被声明)中解析或在命名的规约集(如果在测试条件组中引用一个命名的规约集)中解析。 

3.如果未藉由较早规则解析名称，则在默认用户变量集合中对其进行解析。 

TCG运行时间 

测试条件组具有下列运行时间语义： 

测试(例如，FunctionalTest)将使用一例示TestCondition来引用一具 有来自其SpecificationSet的特定选择器的TCG。此选择器将使该规约集中的每个变量关联与所选选择器相关的其值。此变量与其值的绑定随后将用于确定级别和计时。 

较佳地以在级别块中的出现顺序相继地设定TestConditionGroup(测试条件组)中的参数级别。因此，在Pentium3Levels块中，设定参数级别的顺序如下：(notation:<resource-name>.<resource-parameter>)： 

InputPins.VIL， 

InputPins.VIH， 

OutputPins.VIL， 

OutputPins.VIH， 

Clock.VOL， 

Clock.VOH. 

此排序顺序使测试记录器(test writer)能够控制电源的显式功率排序。此外，如果级别项出现两次，为一插针命名相同的插针参数，则该插针参数被设定两次。这也可能程序性地发生。 

如果藉由例如下列转换语句来设定参数： 

VCC＝SIew(0.01，2.0V)； 

其意味着VCC将在电压转换速率为±0.01伏特每秒的斜面中从其出现值达到其终值2.0伏特。 

也可将规约集变量传递到TCG中的计时对象。随后将基于所选变量来初始化计时对象。此机制可用于，例如，藉由指定波形的前导沿和拖尾沿来自定义计时对象。 

TCG的C++ 

藉由上述规则，可以C++测试条件组类声明测试条件组，并如下对其进行初始化： 

调用TestConditionGroup(测试条件组)元函数 

Status setSpecificationSet(SpecificationSet*pSpecificationSet)； 

其将设定TestConditionGroup的规约集。此既可以是局部规约集，也以是命名的规约集，或是空值(如果不存在)。 

调用TestConditionGroup(测试条件组)元函数 

Status setLevels(Levels*pLevels)； 

其将设定TestConditionGroup的级别对象。此既可以是局部声明级别对象，或是外部声明级别对象，或是空值(如果不存在)。 

调用TestConditionGroup(测试条件组)元函数 

Status setTimings(Timings*pTimings)； 

其将设定TestConditionGroup的计时对象。此可为外部声明计时对象或为空值(如果不存在)。 

箱定义(Bin definition) 

箱定义类定义箱，其是汇总测试许多DUT的结果的计数集合。在测试DUT过程中，可将DUT设定为任何箱，例如，以便指示特定测试的结果。 随着测试的进行，可将该DUT设定为另一个箱。该DUT最终被设定的箱是测试结束时的最后一个这样的设定。在此DUT的测试结束时使用于此最终箱的计数器递增。具有箱定义的独立文件应该具有后缀.bdefs。 

箱定义较佳是分级的。例如，在最外面的级别，可以存在具有名为Pass和Fail的两个箱的PassFailBin。接着可能存在若干HardBin，其中的一些映射到Pass bin(合格箱)，而其它映射到Fail bin(不合格箱)。HardBin被称作是PassFailBin的细分(refinement)。最后，可存在大量的SoftBin，其为HardBin的改进，其中许多映射到相同的Hardbin。下文是说明箱层级的范例： 

#---------------------------------------------------------- 

#File pentiumbins.bdefs 

#---------------------------------------------------------- 

Version 1.2.3； 

BinDefs 

{ 

  #The HardBins are an outermost level of 

  #bins.They are not a refinement of any other 

  #bins. 

  BinGroup HardBins 

  { 

   “3GHzPass”:    “DUTs passing 3GHz”； 

   “2.8GHzPass”:“DUTs passing 2.8GHz”； 

   “3GHzFail”:    “DUTs failing 3GHz”； 

   “2.8GHzFail”:“DUTs failing 2.8GHz”； 

    LeakageFail:“DUTs failing leakage”； 

  } 

  #The SoftBins are a next level of refinement. 

  #SoftBins are a refinement of HardBins. 

  BinGroup SoftBins:HardBins 

  { 

   “3GHzAllPass”: 

        “Good DUTs at 3GHz”，“3GHzPass”； 

   “3GHzCacheFail”: 

        “Cache Fails at 3GHz”，“3GHzFail”； 

   “3GHzSBFTFail”: 

        “SBFT Fails at 3GHz”，“3GHzFail”； 

   “3GHzLeakage”: 

        “Leakages at 3GHz”，LeakageFail； 

   “2.8GHzAllPass”: 

        “Good DUTs at 2.8GHz”，“2.8GHzPass”； 

   “2.8GHzCacheFail”: 

        “Cache Fails at 2.8GHz”，“2.8GHzFail”； 

   “2.8GHzSBFTFail”: 

        “SBFT Fails at 2.8GHz”，“2.8GHzFail”； 

   “2.8GHzLeakage”: 

        “Leakages at 2.8GHz”，LeakageFail； 

 } 

} 

在上文的范例中，最基本的箱是BinGroup HardBin。如果一些其它BinGroup是X的细分，则称BinGroup X是一组基本箱。因此，BinGroupHardBin是一组基本箱，因为BinGroup SoftBin是HardBin的细分。SoftBin的箱称为leafbin。如果其它BinGroup不是Y的细分，则称BinGroup Y是一组leafbin。 

其中具有单一BinGroup Z的BinDefs块的退化情况(degenerate case)将使Z成为一组最基本箱，以及一组leafbin。BinGroup名称在范围上是全程的。可存在任何数量的BinDefs块，但是声明的BinGroup必须是有区别的的。允许来自BinDefs块的inGroup是来自另一BinDefs块的BinGroup的细分。因此，在上文的范例中，SoftBin可位于来自HardBin的独立BinDefs块中。然而，强烈建议存在一个具有为了可读性而具有所有BinGroup都被定义的单一BinDefs块 

藉由添加另一BinGroup，现在可扩展上述层级以便对合格(passed)和不合格(failed)的DUT进行计数。 

#---------------------------------------------------------- 

#File pentiumbins.bdefs 

#---------------------------------------------------------- 

Version 1.2.3； 

BinDefs 

{ 

  #The PassFailBins are an outermost level of 

  #bins.They are not a refinement of any other 

  #bins. 

  BinGroup PassFailBins 

  { 

    Pass:“Count of passing DUTS.”； 

    Fail:“Count of failing DUTS.”； 

  } 

  #The HardBins are a next level of refinement. 

  #HardBins are a refinement of the PassFailBins， 

  #as indicated by“HardBins:PassFailBins”. 

  BinGroup HardBins:PassFailBins 

  { 

   “3GHzPass”:    “DUTs passing 3GHz”，  Pass； 

   “2.8GHzPass”:“DUTs passing 2.8GHz”，  Pass； 

   “3GHzFail”:    “DUTs failing 3GHz”，  Fail； 

   “2.8GHzFail”:“DUTs failing 2.8GHz”，  Fail； 

    LeakageFail:  “DUTs failing leakage”， Fail； 

  } 

  #The SoftBins are a next level of refinement. 

  #SoftBins are a refinement of HardBins. 

  BinGroup SoftBins:HardBins 

  { 

   “3GHzAllPass”: 

   “Good DUTs at 3GHz”，“3GHzPass”； 

   “3GHzCacheFail”: 

        “Cache Fails at 3GHz”，“3GHzFail”； 

   “3GHzSBFTFail”: 

        “SBFT Fails at 3GHz”，“3GHzFail”； 

  “3GHzLeakage”: 

       “Leakages at 3GHz”，LeakageFail； 

  “2.8GHzAllPass”: 

       “Good DUTs at 2.8GHz”，“2.8GHzPass”； 

  “2.8GHzCacheFail”: 

       “Cache Fails at 2.8GHz”，“2.8GHzFail”； 

  “2.8GHzSBFTFail”: 

       “SBFT Fails at 2.8GHz”，  “2.8GHzFail”； 

  “2.8GHzLeakage”: 

       “Leakages at 2.8GHz”，LeakageFail； 

 } 

} 

此时，最基本箱是BinGroup PassFailBin。其通常不是任何箱的细分。BinGroup HardBin是PassFailBin的细分并且也是基本箱。SoftBin是HardBin的细分并且是一组leafbin。上述范例在层级中仅具有三个BinGroup。下文是一个更为复杂的层级： 

BinDefs 

{ 

    #A group of most base bins 

  BinGroup A{...} 

    #A group ofbase bins that is a refinement of A 

  BinGroup Ax:A{...} 

    #A group of leaf bins that is a refinement of Ax 

  BinGroup Axx:Ax{...} 

    #A group of base bins that is a refinement of A 

  BinGroup Ay:A{...} 

    #A group of leaf bins that is a refinement of Ay 

  BinGroup Ayy:Ay{...} 

    #A group of most base bins 

  BinGroup B{...} 

    #A group of leaf bins that is a refinement of B 

  BinGroup Bx:B{...} 

} 

在此范例中，Ax和Ay是A的细分，Axx是Ax的细分并且Ayy是Ay的细分。此范例还提供BinGroup B和Bx，其中Bx是B的细分。具有名为PassFailBin、HardBin和SoftBin的上述BinDefs声明将被用作此部分的连续范例。 

BinGroup中的每个箱具有： 

1.一个名称，其为标识符或字符串文字。 

2.一个描述，其描述此箱概述的内容。 

3.并且如果此箱是处于细分BinGroup中，则作为该箱的细分的箱的名称还称为基本箱。 

PassFailBin中的两个箱命名为″Pass″和″Fail″。HardBin中的五个箱命名为″3GHzPass″、″2.8GHzPass″、″3GHzFail″、″2.8GHzFail″、″LeakageFail″。箱名称可为文字串或标识符。在BinGroup中，箱名称必须是唯一的，但是可在BinGroup之间重复。然而，BinGroup名称在范围上是全程的，且在测试计划上必须是唯一的。 

在五个HardBin中，箱″3GHzPass″和″2.8GHzPass″两者都映射到PassFailBin“合格”箱。其余的HardBin映射到PassFailBin的“不合格”箱。 

最后，存在五个SoftBin。在3GHz对于SBFT(软性箱功能测试)和高速缓存(Cache)的两个不合格映射到″3GHzFail″ HardBin。类似地，在2.8GHz对于SBFT和高速缓存(Cache)的两个不合格映射到″2.8GHzFail″ HardBin。由于泄漏(Leakage)造成的两个不合格映射到相同的″LeakageFail″ HardBin，与其发生的速度无关。例如，最粗略的测试(最外级别)是DUT通过测试还是失败。细分是，例如，DUT对特定频率(例如，3GHz)的测试还是通过还是失败，等等。 

箱是以下文将描述的Test Plan Flowltem(测试计划流程项)分配给DUT。测试计划流程项具有一结果子句(Result Clause)，其中测试计划描述动作和变换作为从执行的测试返回特定结果的结果而发生。在此点处可能发生SetBin语句： 

#A FlowItem Result clause.It is described later. 

Result 0 

{ 

   #Action to be taken on getting a 0 back from 

   #executing a test 

   #Set the bin to SoftBin.“3GHZPass”expressing that the 

   #DUT was excellent. 

   SetBin SoffBins.“3GHzPass”； 

} 

在对DUT运行测试期间可执行许多SetBin语句。当测试最终完成时，运行时间将为该DUT且为所有其细分所设定的最终箱递增计数器。考虑在测试期间执行下列SetBin语句的DUT： 

SetBin SoftBins.″3GHzSBFTFail″； 

SetBin SoftBins.″2.8GHzAllPass″； 

此DUT通过3GHz快速缓冲和渗漏测试，但是没有通过SBFT测试，且因此被分配给″3GHzSBFTFail″箱。随后在2.8GHz下测试，通过所有测试。从而，最终箱赋值被设定为″2.8GHzAllPass″箱，其为SoftBin之组。此最终赋值将使下列箱的计数器递增： 

1.SoftBin″2.8GHzAllPass″ 

2.其为HardBin″2.8GhzPass″的改良 

3.其为PassFailBin″Pass″的细分 

当完成测试时，运行时间将使DUT最终箱赋值的计数器和所有其它箱(此DUT最终箱赋值是其细分)的计数器递增。 

仅在leafbin上允许SetBin语句。设定基本箱是非法的。上述计数器递增语义确保： 

1.如果该箱是leafbin，则其为在测试DUT结束时为此箱执行的SetBin语句的次数。 

2.如果该箱是base bin(基本箱)，则其为此作为其细分的箱的计数器的总和。 

因此，在上述范例中，在SetBin语句仅允许SoftBin。HardBin.″LeakageFail″的计数器是  SoftBins.″3GHzLeakageFail″和SoftBins.″2.8GHzLeakageFail″的计数器的总和。下文是关于箱定义的一些规则： 

1.BinDefinition(箱定义)声明由若干BinGroup(箱组)声明构成。 

2.每个BinGroup声明具有一个名称，其为一个可选BinGroup名称的细分，后接一个箱声明块。 

3.箱声明包括一个名称，后接一个描述，可选地后接一基本箱(此箱是其细分)的名称。 

4.箱名称可以是字符串文字或Id。空字符串不应该是有效的箱名称。箱名称在BinGroup声明中的名称中应该是唯一的，但是在其它BinGroup声明中可使用相同的名称。 

5.如果BinGroup声明Xxx是另一BinGroup声明Yyy的细分，则Xxx中所有的箱声明必须声明来自Yyy的基础箱的名称。因此，SoftBin中的每个箱声明是HardBin的箱的细分，因为SoftBin被声明为是HardBin的细分。 

6.不是另一BinGroup声明(例如PassFailBin)的细分的BinGroup声明将较佳地具有不声明基本箱的Bin声明。 

箱Bbb具有一基础(bases)集，其为整个箱集(Bbb是其细分)。其通常定义如下： 

1.如果Aaa是Bbb的基本箱，则Aaa处于Bbb的基础组中。 

2.Aaa的任何基础也处在于Bbb的基础组中。 

BinGroup名称在TestPlan中是全程的。 

箱名称对于BinGroup是局部的。 

SetBin语句仅对于leaf bin是允许的。 

箱定义的C++ 

藉由上述规则，可为BinDefs声明中的每个BinGroup声明构造一个对象类型BinGroup。类BinGroup将具有一个子类LeafBinGroup。这些两个类的操作大体上相同，不同之处在于BinGroup::incrementBin是C++保护的操作，而LeafBinGroup::incrementBin是C++公开操作。 

下文是一个默认构造函数，构造一个BinGroup或LeafBinGroup，其不是任何其它BinGroup的细分。 

构造函数： 

BinGroup(BinGroup& baseBinGroup)； 

LeafBinGroup(BinGroup& baseBinGroup)； 

其构造一个作为给定baseBinGroup(基础箱组)的细分的BinGroup。 

一种方法 

Status addBin(const String& binName， 

                const String& description 

                const String& baseBinName)； 

用于定义箱及其描述。如果其是最基础箱，则baseBinName参数必须是空字符。 

使箱计数器递增的方法： 

Status incrementBin(const String& binName)； 

此操作将使此箱和作为此箱基础的所有箱的计数器递增。此操作在类BinGroup中是受保护的，而在类LeafBinGroup中是公开的。 

重设箱计数器的方法 

Status resetBin(const String& binName)； 

此操作将重设此箱和作为此箱基础的所有箱的计数器。 

获得关于箱信息的方法： 

             Methods to get information about a bin: 

Status getBinDescription(const String& binName， 

              String& description)； 

Status getBaseBin(const String& binName， 

           BinGroup*pBaseBinGroup， 

           String& baseBinName)； 

Status getBinValue(const String& binName， 

           unsigned int& value)； 

将提供迭代器(Iterator)以获得所有当前定义的箱名称。 

TestPlan状态将包括BinGroup成员的数量，每个BinGroup声明具有一个数量。上述BinDefinition(箱定义)的C++如下： 

 //TestPlan constructor 

 TestPlan::TestPlan() 

 :m_PassFailBins()，//Default Constructor 

 m_HardBins(&m_PassFailBins)， 

 m_SoftBins(&m_HardBins) 

{} 

//Bin initializations 

m_PassFailBins.addBin(“Pass”，“Count of passing DUTS.”，“”)； 

m_PassFailBins.addBin(“Fail”，“Count of failing DUTS.”，“”)； 

m_HardBins.addBin(“3GHzPass”，“Duts passing 3GHz”，“Pass”)； 

TestPlan的状态包括m_pCurrentBinGroup，其被初始化成未定义的BinGroup(空值)和m_currentBin未定义的箱名称(空字符串)。每次执行SetBin语句时，藉由以下调用将m_pCurrentBinGroup变为所指示的命名的BinGroup并且将m_currentBin变为该组中所命名的箱: 

//Translation of:SetBin SoftBins.“3GHzAllPass”； 

pTestPlan-＞setBin(“SoftBins”，“3GHzAllPass”)； 

When the test plan completes execution，it will call 

m_pCurrentBinGroup-＞incrermentBin(m_currentBin)； 

导致此箱和其所有基础箱使其计数器递增。 

当确立测试计划时，重置BinGroup计数器，但在每次运行测试时不对其进行重新初始化。可藉由对BinGroup::resetBin的显式调用来重设计数器。 

C.测试计划 

测试计划可被看作是测试程序的主构造。测试计划可引入文件，以及定义类似结构内联。因此，有可能引入给出一些全程符定义以及声明附加内联全程符的文件。 

C1.测试计划流程(flow)和Flowltem(流程项) 

测试计划的关键元件之一是流程。流程封装有一个有限态机器。其包括若干流程项，其运行IFlowable对象并且随后转换到另一流程项。运行 IFlowable涉及运行可实现IFlowable接口的对象。实现IFlowable接口的典型对象为测试(Test)和流程(Flow)本身。 

因此，流程具有流程项，其运行测试和其它流程，并且随后转换到另一流程项。其还提供对来自运行IFlowable的各种返回结果调用用户自定义例行程序的机会。因此，流程通常具有下列形式： 

# 

#FlowTest1 implements a finite state machine for the 

#Min，Typ and Max flavors of MyFuuctionalTest1.On 

#success it tests Test1Min，Test1typ，Test1Max 

#and then returns to its caller with 0 as a successful 

#status.On failure，it returns 1 as a failing status. 

# 

#Assume that the tests MyFunctionalTest1Min，...all 

#return a Result of 0(Pass)，1 and 2(for a couple 

#of levels of failure). 

#            Result 0    Result 1        Result 2 

# Test1Min   Test1Typ    return 1    return 1 

# Test1Typ   Test1Max    return 1    return 1 

    #Test1Max    return 0  return 1  return 1 

    # 

    Flow FlowTest1 

    {     

       FlowItem FlowTest1_Min MyFunctionalTest1Min 

       { 

          Result 0 

          { 

             Property PassFail＝“Pass”； 

             IncrementCounters PassCount； 

             GoTo FlowTestl_Typ； 

          } 

          Result 1 

         { 

             Property PassFail＝“Fail”； 

             IncrementCounters FailCount； 

             Return 1； 

         } 

         #This result block will be executed if 

         #MyFunctionalTest1Min returns any of 

         #2，5，6，7，-6，-5 or-4 

         Result 2，5:7，-6:-4 

         { 

            Property PassFail＝“Fail”； 

            IncrementCounters FailCount； 

            Return 1； 

         } 

    } 

    FlowItem FlowTest1_Typ{...} 

    FlowItem FlowTest1_Max{...} 

 } 

流程FlowTest1的操作如下： 

1.以执行流程项FlowTest1_Min开始。 

2.FlowTest1_Min运行一个功能测试，MyFunctionalTest1Min。在下文展示完整测试计划时提供此测试的细节。 

3.从运行此测试可预期获得9个结果，0、1、2、5、6、7、-6、-5或-4。最初两个结果子句分别处理0和1，而第三个处理所有其余的结果值。 

4.如果发生结果″0″(合格)，则FlowTest1_Min将使计数器PassCounter递增。随后将转换到新的FlowItems FlowTest1_Typ。 

5.如果发生结果″1″或结果″2″，则FlowTest1_Min将使计数器FailCounter递增，且从该流程返回。 

6.FlowTest1_Typ将以相同的方式操作，并且成功后调用FlowTest1_Max。 

7.FlowTest1_Max将以相同的方式动作，并且成功后以成功结果(″0″)从FlowTest1返回。 

因此，在成功运行行后，FlowTest1将元件运行Test1的最小、典型和最大版本的，并且随后返回。FlowTest2将以类似方式操作。 

上述流程基本描述了具有状态和转换的有限态机器。FlowItems基本上是状态，其将执行下列： 

1.执行IFlowable(其可能为可藉由上述规则以C++来实现的先前定义的流、或测试、或用户定义的流程)。 

2.对IFlowable的执行返回一个数字结果。基于该结果，发生特定动作(更新一些计数器)，并且随后发生以下两者中的一个： 

a.流程向调用程序返回一数字结果。 

b.流程藉由转换到另一状态(FlowItem)而继续。 

因此，FlowItem具有下列组件： 

FlowItem具有一名称。 

FlowItem具有一待执行的IFlowable。 

FlowItem具有一数字或结果子句。 

FlowItem的每个结果子句提供动作(action)并且以转换结束，且与一或多个结果值结束。 

在FlowItem中，这些项在句法上如下: 

FlowItem<name><IFlowable to be executed> 

{ 

   Result<one or more result values> 

   { 

      <actions for these result values> 

      <transition for these result values> 

   } 

   Result<one or more other result values> 

   { 

   } 

} 

待执行的IFlowable可为测试(Test)或用户定义的IFlowable，或流程(Flow)。结果的动作可为下列中的任一者： 

特性动作(Property Action)，其用于将GUI工具所使用的字符串定值实体设定为属性结果。在上述FlowTest1范例中，此可以看作： 

Property PassFail＝″Pass″； 

特性基本上是与结果子句相关联的命名的字符串或整数定值实体。可存在任何数量的特性，并且其较佳地藉由工具来使用，例如GUI，用户将使用GUI来显示与此结果相关的信息。其不会影响测试的实际结果或测试的流程。 

计数器动作(Counters Action)，其用于使一些数量的计数器递增。在上述实例中，此可看作： 

IncrementCounters PassCount； 

例行程序调用动作(Routine Call Action)，其用于调用任意或用户例行程序。稍后将对此进行论述。 

最后，流程项具有一转换，其可为GoTo语句以传送另一Flowltem的控制，或为返回语句以传送返回调用程序(调用流程，或启动测试计划的系统例行程序)的控制。 

预定义流程 

流程对象的典型用途是定义测试的序列。随后将此序列作为测试计划服务器(TPS)中发生的事件的结果来执行，即，执行测试计划事件。每个现场控制器上的测试计划服务器执行使用者测试计划。然而，还响应于其它事件来执行流程对象。括号中的名称是用于将流程分配给这些事件的名称。 

1.系统载入流程(SysLoadFlow)。当将测试计划载入一或多个现场控制器时执行此流程。在将测试计划实际载入任何现场控制器之前执行该流 程。此流程允许测试计划开发人员定义应该从系统控制器发起的动作。这些动作包括模式文件的广播载入、校准动作等等。 

2.现场载入流程(SiteLoadFlow)。在已经将测试计划载入现场并初始化之后，在现场控制器上执行此流程。此允许发生任何特定现场初始化。 

3.批开始/结束流程(LotStartFlow/LotEndFlow)。当测试计划服务器发现新批(lot)开始时，在现场控制器上执行这些流程。此通常用于制造环境以便藉由特定批信息来注释数据记录流。 

4.DUT变化流程(DutChangeFlow)。当现场控制器的DUT信息变化时在该现场控制器上执行此流程。同样，此通常用于制造环境以便更新数据记录流。 

5.测试计划开始/结束流程(TestPlanStartFlow/TestPlanEndFlow)。当指示测试计划服务器开始执行当前测试流程时以及当该流程的执行结束时，在现场控制器上执行这些流程。 

6.测试开始/结束流程(TestStartFlow/TestEndFlow)。当测试流程开始运行新的测试时以及当该测试的执行结束时，在现场控制器上执行这些流程。 

7.测试流程(TestFlow)。此流程是当测试计划服务器接收到“执行测试计划”消息时执行的主流程对象。 

注意，如果用户在用户测试计划中定义一流程(其非测试流程或其它预定义流程之一)，则执行该流程的较佳方式是将其包括在这些预定义流程之一的转换状态中。 

测试计划范例 

在下文的范例中，连同描述流程所实现的有限态机器的注释一起给出流程。作为转换矩阵给出有限态机器。矩阵的行对应于FlowItem，而列对应于结果。矩阵的行的入口指示当返回结果是列中所指定的值时被转换以形成行的FlowItem的FlowItem。 

下文展示了具有三个流程FlowTest1，FlowTest2和FlowMain的测试计划。FlowTest1如前述动作。其运行每个″min″、″typ″和″max″配置中名为MyFunctionalTest1的测试。类似地，FlowTest2将运行每个这些配置中的MyFunctionalTest2。最后，FlowMain将运行FlowTest1和FlowTest2。在每个这些流程的开头提供有限态机器变换矩阵。 

#---------------------------------------------------------- 

#File mySimpleTestPlan.tpl 

#---------------------------------------------------------- 

Version 0.1； 

Import xxx.pin；    #Pins 

#Constants and variables giving limiting values. 

Import limits.usrv； 

#Import test condition groups 

Import myTestConditionGroups.tcg； 

#Import some bin definitions. 

Import bins.bdef； 

#---------------------------------------------------------- 

#Start of the test plan 

#---------------------------------------------------------- 

TestPlan Sample； 

#This block defines Pattern Lists file-qualified names and 

#Pattern List variables that are used in Test declarations. 

#Patter list variables are deferred till customization is 

#examined. 

PListDefs 

{ 

  #File qualified pattern list names 

  pl1A.plist:patlAlist， 

  pl2A.plist:pat2AList 

} 

#The socket for the tests in this test plan (this is not imported， 

#but resolved at activation time): 

SocketDef＝mytest.soc； 

#Declare some user variables inline 

UserVars 

{ 

   #String name for current test 

     String CurrentTest＝″MyTest"； 

  } 

 TestCondition TC1Min 

  { 

     TestConditionGroup＝TCG1； 

     Selector＝min； 

  } 

  TestCondition TC1Typ 

  { 

     TestConditionGroup＝TCG1； 

   Selector＝typ； 

  } 

  TestCondition TC1Max 

  { 

    TestConditionGroup＝TCG1； 

    Selector＝max； 

  } 

  #Likewise for TC2Min，TC2Typ，TC2Max... 

  # 

  #Declare a FunctionalTest.″FunctionalTest″referrs to a C++ 

  #test class that runs the test，and returns a 0，1 or 2 as 

  #a Result.The Test Condition Group TCG1 is selected with 

  #the ″min″selector by referring to the TC1Min TestCondition. 

  # 

  Test FunctionalTest MyFunctionalTest1Min 

  { 

    PListParam＝pat1AList； 

     TestConditionParam＝TC1Min； 

 } 

 #Another FunctionalTest selecting TCG1 with″typ″ 

 Test FunctionalTest MyFunctionalTest1Typ 

 { 

   PListParam＝pat1AList； 

   TestConditionParam＝TC1Typ； 

 } 

 #Another FunctionalTest selecting TCG1 with″max″ 

 Test FunctionalTest MyFunctionalTest1Max 

 { 

   PListParam＝pat1AList； 

   TestConditionParam＝TC1Max； 

 } 

 #Now select TCG2 with″min″ 

 Test FunctionalTest MyFunctionalTest2Min 

 { 

   PListParam＝pat2AList； 

   TestConditionParam＝TC2Min； 

 } 

 #Likewise for TCG2 with″typ″and TCG2 with″max″ 

 Test FunctionalTest MyFunctionalTest2Typ 

 { 

   PListParam＝pat1AList； 

   TestConditionParam＝TC2Typ； 

 } 

 Test FunctionalTest MyFunctionalTest2Max 

 { 

   PListParam＝pat1AList； 

   TestConditionParam＝TC2Max； 

} 

# 

#At this time the following Test objects have been defined 

#    MyFunctionalTest1Min 

#    MyFunctionalTest1Typ 

#    MyFunctionalTest1Max 

#    MyFunctionalTest2Min 

#    MyFunctionalTest2Typ 

#    MyFunctionalTest2Max 

# 

# 

#Counters are variables that are incremented during the 

#execution of a test.They are UnsignedIntegers that are 

#initialized to zero. 

# 

Counters{PassCount，FailCount} 

# 

#Flowscan now be presented.A Flow is an object that 

#essentially represents a finite state machine which 

#can execute“Flowables”，and transition to other flowables based 

#on the Result returned from executing a Flowable.A Flow can also 

#call another flow. 

# 

#A Flow consists of a number of FlowItems and transitions 

#between them.FlowItems have names which are unique in 

#the enclosing Flow，execute a“Flowable”object，and then 

#transition to another FlowItem in the same enclosing Flow. 

# 

#Flowable objects include Tests and other Flows.When 

#a Flowable object executes，it returns a numeric Result 

#which is used by the FlowItem to transition to another 

#FlowItem.As a result of this，botb Tests and Flows 

#terminate by returning a numeric Result value. 

# 

#FlowTest1 implements a finite state machine for the 

#Min，Typ and Max flavors of MyFunctionalTest1.On 

#success it tests Test1Min，Test1Typ，Test1Max 

#and then returns to its caller with 0 as a successful 

#Result.On failure，it returns 1 as a failing Result. 

# 

#Assume that the tests MyFunctionalTest1Min，...all 

#return a Result of 0(Pass)，1 and 2(for a couple 

#of levels of failure).The Transition Matrix of the 

#finite state machine implemented by FlowTest1 is: 

#---------------------------------------------------------- 

#                     Result 0    Result 1    Result 2 

#---------------------------------------------------------- 

#  FlowTest1_Min    FlowTest1_Typ   return 1 return 1 

#  FlowTest1_Typ  FlowTest1_Max       return 1     return 1 

#  FlowTest1_Max      return 0    return 1 return 1 

# 

#where the IFlowables run by each FlowItem are: 

#    FlowItem    IFlowable that is run 

#    FlowTest1_Min  MyFunctionalTest1Min 

#    FlowTest1_Typ  MyFunctionalTest1Typ 

#    FlowTest1_Max    MyFunctionalTest1Max 

# 

Flow FlowTest1 

{ 

   FlowItem FlowTest1_Min MyFunctionalTest1Min 

   { 

      Result 0 

      { 

         Property PassFail＝″Pass″； 

         IncrementCounters PassCount； 

    GoTo FlowTest1_Typ； 

  } 

  Result 1，2 

  { 

  Property PassFail＝″Fail″； 

    IncrementCounters FailCount； 

    Return 1； 

  } 

} 

FlowItem FlowTest1_Typ MyFunctionalTest1Typ 

{ 

    Result 0 

    { 

      Property PassFail＝″Pass″； 

      IncrementCounters PassCount； 

      GoTo FlowTest1_Max； 

    } 

    Result 1，2 

    { 

      Property PassFail＝″Fail″； 

      IncrementCounters FajlCount； 

      Return 1； 

    } 

} 

#Likewise for FlowTest1_Max 

FlowItem FlowTest1_Max MyFunctionalTest1Max 

{ 

    Result 0 

    { 

       Property PassFail＝″Pass″； 

       IncrementCounters PassCount； 

    Return 0； 

  } 

  Result 1，2 

  { 

    Property PassFail＝″Fail″； 

    IncrementCounters FailCount； 

    Return 1； 

  } 

 } 

} 

# 

#FlowTest2 is similar to FlowTestl.It implements a 

#finite state machine for the Min，Typ and Max flavors 

#of MyFunctionalTest2.On success it tests Test2Min， 

#Test2Typ，Test2Max and then returns to its caller with 

#0 as a successful Result. On failure，it returns 1 as 

#a failing Result. 

# 

#Assume that the tests MyFunctionalTest2Min，...all 

#return a Result of 0(Pass)，1 and 2(for a couple 

#of levels of failure).The Transition Matrix of the 

#finite state machine implemented by FlowTest2 is: 

#---------------------------------------------------------- 

#    Result0    Result 1    Result2 

#---------------------------------------------------------- 

#FlowTest2_Min  FlowTest2_Typ  return 1 return 1 

#FlowTest2_Typ  FlowTest2_Max    return 1  return 1 

#  FlowTest2_Max    return 0    return 1 return 1 

# 

#Where the IFlowables run by each FlowItem are: 

#    FlowItem    IFlowable that is run 

#    FlowTest2_Min  MyFunctionalTest2Min 

#    FlowTest2_Typ  MyFunctionalTest2Typ 

#    FlowTest2_Max    MyFunctionalTest2Max 

# 

Flow FlowTest2 

{ 

  #... 

} 

# 

#Now the FlowMain，the main test flow，can be presented.It 

#implements a funite state machine that calls FlowTest1 

#and FlowTest2 as below: 

#---------------------------------------------------------- 

#    Result0    Result 1 

#---------------------------------------------------------- 

#FlowMain_1  FlowMain_2  return 1 

#FlowMain_2  return 0  return 1 

# 

#Where the IFlowables tun by each FlowItem are: 

#    FlowItem    IFlowable that is run 

#    FlowMain_1    FlowTest1 

#    FlowMain_2    FlowTest2 

Flow FlowMain 

{ 

   #The first declared flow is the initial flow to be 

   #executed.It goes to FlowMain_2 on success，and 

   #returns 1 on failure. 

   FlowItem FlowMain_1 FlowTest1 

  { 

      Result 0 

     { 

         Property PassFail＝″Pass″； 

    IncrementCounters PassCount； 

    GoTo FlowMain_2； 

  } 

  Result 1 

  { 

    #Sorry...FlowTest1 failed 

    Property PassFail＝″Fail″； 

    IncrementCounters FailCount； 

    #Add to the rifht soft bin 

    SetBin SoftBins.“3GHzSBFTFail”； 

    Return 1； 

  } 

} 

FlowItem FlowMain_2 FlowTest2 

{ 

  Result 0 

  { 

    #All passed！ 

    Property PassFail＝″Pass″； 

    IncrementCounters PassCount； 

    #Add to the right soft bin 

    SetBin SoftBins.“3GHzAllPass”； 

    Return 0； 

      } 

  ResuIt 1 

  { 

        #FlowTest1 passed，but FlowTest2 failed 

        Property PassFail＝″Fail″； 

       IncrementCounters FailCount； 

       #Add to the right soft bin 

       SetBin SoftBins.“3GHzCacheFail”； 

       Return 1； 

     } 

   } 

 } 

 TestFlow＝FlowMain； 

以较佳顺序如下构造上述测试计划： 

1.首先，提供一版本号。此数字用于确保与编译器版本兼容。 

2.随后，声明若干引入。这些是具有声明的各种文件，需要这些文件来解析用于测试计划的名称。 

3.接着，声明测试计划名称，随后是测试计划的内联声明。 

4.接着声明一组PListDef。这些包括文件限定的名称，用于命名来自所命名文件的GlobalP列表。其还包括模式列表变量。模式列表变量是可以在执行时间以自定义Flowable来初始化的变量。其提供一种将测试与实际模式列表的绑定延迟到运行时间的方法。 

5.接着，声明一组UserVar。这些包括字符串。 

6.随后声明一些计数器，以确定合格和不合格测试的数量。计数器仅仅是初始化为零并且以IncrementCounter语句递增的变量。其不同于上文描述的箱(Bin)，这些箱的语义是在DUT测试结束时仅递增当前设定的箱。 

7.接着，声明一系列测试条件。这些中的每一者指定一测试条件组和一选择器。在此范例中，测试条件组来自mytestconditionsgroups.tcg。然而，其可能已经内联于测试计划中。 

8.接着，声明一系列Flowable或Test。此每一者都是已知的测试FunctionalTest，其选择模式列表和测试条件。因此，举例而言，MyFunctionalTest1Max选择测试条件TclMax和一个模式列表。 

9.此后，声明三个流程FlowTest1、FlowTest2和FlowMain。流程运行Flowable。Flowable包括测试(例如MyFunctionalTest1Max)和其它流程(例如，FlowTest1和FlowTest2)。FlowTest1和FlowTest2中的每一个分别运行通过最小、典型和最大版本的Test1和Test2。流程FlowMain调用先前声明的流程，FlowTest1接着FlowTest2。 

10.最后，将TestFlow事件分配给FlowMain流程。因此，当用户选择执行此计划时，流程FlowMain是将藉由此测试计划来执行的流程。 

流程的C++ 

藉由上述规则，除了流程本身，可以为大多数元素完成C++实现。 

FlowItem的C++ 

用于表示FlowItem的C++类可具有下列接口： 

一个操作 

Status setFlowable(IFlowable*pIFlowable)； 

其将设定将为此FlowItem执行的IFlowable。 

一旦FlowItem从执行此IFlowable所需的该组调用返回，则视结果值而定需要使一列计数器递增。为此，FlowItem需要具有待递增的计数器的向量。此藉由以下调用来初始化： 

Status setCounterRefs(unsigned int result， 

                CounterRefList counterRefs)； 

调用此可在FlowItem中建立计数器引用的向量，因此一旦IFlowable的执行结束则使其递增。例如，语句 

IncrementCounters A，B，C； 

将较佳地如下使用上述调用： 

//Somewhere earlier 

CounterRefList counters； 

//Code for Result clause 

//Result 2，3{...} 

//of flowObject. 

counters.reset()； 

counters.add(&A)； 

counters.add(&B)； 

counters.add(&C)； 

flowObject.setCounterRefs(2，counters)； 

flowObject.setCounterRefs(3，counters)； 

使用名为counters的临时CounterRefList对象。最初，调用counters.reset()，接着调用大量counters.add()以便建立计数器列表。此随后用于建立待为结果值2和3更新的计数器地址向量。 

该FlowItem随后可能需要根据特定结果转换到另一FlowItem： 

Status setTransition(unsigned int result，FlowItem*pFlowItem)； 

在一特定结果子句处理许多结果值的情况下，将自然需要执行若干个这种调用。 

该FlowItem可能需要返回一结果。此藉由以下来完成： 

Status setReturnResult(unsigned int result， 

                   unsigned int returnResult)； 

例如，对于先前范例中的FlowItem FirstFlowItem，将调用上述语句，其中值″2″用于“结果”而值″1″用于“返回结果(returnResult)”。 

最后，Flowltem需要一个操作来执行： 

Status execute(unsigned int& result，Flowltem*pNextFlowItem)； 

此操作将执行IFlowable，随后更新所指示的计数器，并且接着向下一个流程项返回一个结果(Result)或者一个指示符(pointer)。如果这个指示符是NULL，则结果是返回值。 

将要为流程项FlowMain_1生成的代码如下： 

FlowItem FlowMain_1； 

FlowItem FlowMain_2； 

CounterRefList counters； 

FlowMain_1.setFlowable(FlowTest1)； 

//Result 0 

counters.reset()； 

counters.add(&PassCount)； 

FlowMain_1.setCounterRefs(0，counters)； 

FlowMain_1.setTransition(0，&FlowMain_2)； 

//Result 1 

counters.reset()； 

counters.add(&FailCount)； 

FlowMain_1.setCounterRefs(1，counters)； 

//The following call from ITestPlan will set the 

//current bin group and bin name. 

pTestPlan-＞setBin(“SoftBins”，“3GHzSBFTFail”)； 

FlowMain_1.setReturnResult(1，1)； 

上文生成的代码设置FlowMain_1以便运行IFlowable“FlowTest1”，并且随后对其进行设置以使每个结果的适当列的计数器递增，并最终采取必要的动作。在结果“0”的情况下的必要的动作是转换成FlowMain_1，而在结果″1″的情况下的必要的动作是返回。 

C2.TestPlan(测试计划)中的计数器支持 

计数器是被初始化成零的变量，并且在测试运行期间的各点处可藉由IncrementCounter语句来递增。其不同于Bin(箱)，Bin仅在测试结束时被递增。此外，箱是分级的而计数器是简单变量。因此，与箱相比，计数器是更为简单且更多受到限制的程序。 

在TestPlan中可藉助计数器类的一个成员来支持计数器，该成员保持一个呈无符号整数的命名计数器的集合。在此类中将藉助计数器声明来定义对象。当测试开始时，计数器不会被自动重设，从而允许TestPlan在测试许多DUT时积聚计数。将提供重设、递增和询问计数器值的方法。此实现对装箱的另一选择，以便确定作为运行测试结果的计数。 

TestPlan较佳地含有一个成员变量，m_modifiedCounters，其为藉由对DUT运行测试而被修改的计数器的集合。在测试开始时将此集合初始化成空集。在各个建立IncrementCounters调用之处，将生成代码以便将命名的计数器添加到m_modifiedCounters成员。因此，此成员将在对DUT执行测试期间被修改的所有计数器积聚在一起。 

流程对象的C++ 

一旦创建所有的Flowltem，则可将该流程对象创建为一个C++对象，如下文所示： 

添加Flowltem的操作 

Status addFlowItem(FlowItem*pFlowItem，bool isInitalFlowItem) 

其将所指示的Flowltem添加到该流程中。如果此为该流程的初始Flowltem，则将布尔值(boolean)设定为真(True)。 

执行流程的操作 

Status executeFlow(unsigned int& result)； 

当流程返回时，作为执行该流程的结果，此较佳的是也返回。此动作开始执行具有初始Flowltem的流程。只要当前Flowltem返回一待执行的下一个Flowltem，则将持续执行Flowltem。当当前Flowltem返回一个Result时，则此操作以该Result结束。 

因而，为流程生成的C++代码具有对addFlowItem()的若干重复调用以便将Flowltem添加到该流程。当选择测试计划中的此流程以用于执行时，发生executeFlow()操作。 

C3.测试类 

通常，程序代码的大部分是用于装置测试的数据，且其余部分是测试程序的代码，其实现测试方法。此数据具有DUT依赖性(例如，电源条件、信号电压条件、计时条件等等)。测试代码包括将指定元件条件加载到ATE硬件的方法，还包括所需的用于实现用户指定的目标(例如，数据登录等)的方法。 

如上文所解释，为了增加测试代码的复用性，这些代码应该独立于任何元件专用数据(例如，插针名称、激励数据，等等)或元件测试专用数据(例如，DC单元的条件、测量插针、目标插针数量、模式文件名称、模式程序地址，等等)。如果测试代码是由这些类型的数据编译，则测试代码的 复用性将降低。因此，使测试代码可以从外部获得任何元件专用数据或元件测试专用数据，例如在代码执行时间期间输入。 

在开放式架构测试系统中，一个作为ITest接口执行实现的测试类实现特定类型测试的测试数据与代码(和由此产生的代码的复用性)的分离。这种测试类可被看作是其独立实例的“模板”，其彼此不同之处只是以元件专用和/或元件测试专用数据为基础。在测试计划文件中指定测试类。每个测试类通常执行特定类型的元件测试或元件测试的设置。例如，较佳地藉由独立测试类来执行功能性、AC和DC测试。但是，自定义测试类也可以用于测试计划。 

测试类允许用户藉由提供用于指定该测试特定实例的选项来配置类行为。例如，功能性测试将采用参数PList和TestConditions来分别指定用于执行的模式列表以及该测试的级别和计时条件。为这些参数指定不同的值(通过在测试计划描述文件中使用不同的“测试”块)允许用户创建功能性测试的不同实例。图5展示如何从单一测试类504产生不同测试实例502。 

这些类应该被设计以便允许编译器400从测试计划文件获得对测试及其参数的描述并且生成正确的C++代码，此C++代码可被编译和链接以便生成测试程序。可将测试类实例添加到描述测试流程的对象以便创建元件测试的复杂执行序列。 

C4.从Itest和IFlowable的推导 

如上文所述，从ITest获得测试类。藉由上述规则，可在执行ITest接口的C++类中执行这些测试类。除了指定用于ITest接口的方法之外，这些类提供测试专用智能和指定元件测试的特定类所需的逻辑。测试类还执行IFlowable接口。因此，可将测试类的实例用于Flowltem以便运行测试。 

用户化 

提供用户化机制以使用户能够调用C函数并且开发其自身的执行Itest和IFlowable接口的类。 

内省能力 

如果能够关于其方法和签名对测试类对象进行询问，则能够证实可以获得适当参数以便包括在所生成的源代码中。这种特征对于转译阶段中的错误检测和确认将极为有效。如果测试工程师在参数名称或这些参数的变元数量(或可能是类型)中出错，则转译阶段可能捕捉到这些错误并且在转译时间提供有意义的错误讯息而不是等待来自C++编译器的编译时间错误讯息。此对测试工程师来说更为有用。 

内省表示要求对象探测其自身并且返回关于其属性和方法的信息。一些语言，例如Java，提供此能力以作为该语言的部分。其它语言，例如VisualBasic，对试图使用该语言的对象时间这种要求。C++不提供此特征。 

此方法还很适合于提供默认参数值以及对可选参数的指示。此外，如果是作为所有测试类的执行实现的部分来提供此能力，则GUI应用程序还可使用此信息来建立对话和其它用户接口元件，从而有助于工程师有效使用这些类。 

在本发明一实施例中，藉由以下机制来补偿这些复杂性，该机制提供一种允许测试类开发者在单一基于文本的源文件(每种测试类)中完全指定该测试类的公共方法/属性，开发者已指定这些公共方法/属性为参数化测试类所要求的公共方法/属性。 

较佳是单一源：我们不希望对测试类的参数化接口的描述处于一个文件而C++接口描述处于另一独立(报头)文件中并且随后负担保持两个源同步的需要。为此，将“基于文本”的描述嵌入该测试类的前报头文件中，编译器将该前报头文件用于受限内省以及用于生成该测试类的C++报头。所生成的C++报头文件是用于最终编译测试类C++代码的C++报头文件。 

前报头 

我们熟知报头在C++中的使用。但是，因为C++难以解析和读取，所以本发明一实施例定义了一种语法，其允许编译器创建可被测试类开发者用作报头的C++输出。根据此实施例，测试类开发者编写一个前报头，编译器400将其作为报头文件输出，允许相应测试类或其它测试实体的可见性。 

下列范例说明根据本发明较佳实施例的测试类前报头文件的概念。藉由测试FuncTest1考虑下列来自源文件的摘录： 

TestCondition TC1 

{ 

    TestConditionGroup＝TCG1；#Previously defined TCG for Levels 

    Selector＝min； 

} 

TestCondition TC2 

{ 

    TestConditionGroup＝TCG2；#Previously defined TCG for Timing 

    Selector＝min； 

} 

Test FunctionalTest FuncTest1 

{ 

    PListParam＝patList1；    #Previously defined pattern list 

    TestConditionParam＝TC1； 

    TestConditionParam＝TC2； 

} 

编译器需要知道FunctionalTest所承担的内容以便确定上述FuncTest1的声明是否合法。不是将FunctionalTest的知识装入编译器，而是可以在前报头中指定FunctionalTest所承担的定义。 

假设FunctionalTest是一个具有基类Test1和Test2且具有成员PList和一系列TestCondition的C++类。编译器需要知道FunctionalTest的成员的类型以便承认上述FuncTest1的声明是合法的。 

此外，为了生成FuncTest1的C++对象声明，需要构造类FunctionalTest的C++报头。此要求编译器还知道FunctionalTest类的基类、其成员的名称和其它这类信息。 

本发明一实施例的前报头子语言向编译器提供其承认声明的合法性和生成对应于声明的C++报头和对象声明所需的信息。 

注意到，FunctionalTest是一个简单类型(就参数化而言)，且因此将使用较为简单的对参数化的描述。因此，可以如下编写支持上述参数化的前报头FunctionalTest.ph(假设基础测试类Test1和Test2可获得这些前报头)： 

1  Version 1.0； 

2  # 

3  #Parameterization specification pre-header for FunctionalTest 

4  # 

5  Import Test1.ph；    #For base class Test1 

6  Import Test2.ph；    #Forbase class Test2 

7  TestClass＝FunctionalTest；#The name of this test class 

8  PublicBases＝Test1，Test2；#List of public base classes 

9  #The parameters list or“parameter block”: 

10 Parameters 

11 { 

12    #The following declaration specifies that a FunctionalTest has 

13    #  -aparameter of type PList 

14    #  -[represented by C++ type Tester::PatternTree] 

15    #  -stored in a member named m_pPatList 

16    #  -a function to set it named setPatternTree. 

17    #  -a parameter description for the GUI to use as a tool tip 

18    PList PListParam 

19    { 

20    Cardinality＝1； 

21    Attribute＝m_pPatList； 

22    SetFunction＝setPatternTree； 

23    Description＝“The PList parameter for a FunctionalTest”； 

24    } 

25    # 

26    #The following declaration specifies that a FunctionalTest has 

27    #  -1 or more parameters of type TestCondition 

28    #  -[represented by C++ type Tester::TestCondition] 

29    #  -stored in a member named m_testCondnsArray 

30    #  -a function to set it named addTestCondition. 

31    #  -a parameter description for the GUI to use as a tool tip 

32    #The[implement]clause causes the translation phase of to 

33    #generate a default implementation of this function. 

34    # 

35    TestCondition TestConditionParam 

36    { 

37    Cardinality＝1-n； 

38    Attribute＝m_testCondnsArray； 

39    SetFunction＝addTestCondition[Implement]； 

40    Description＝“The TestCondition parameter for a 

   FunctionalTest”； 

41    } 

42  } 

43  # 

44  #The section below is part of the Pre-Header which is an escape 

45  #into C++ code.This will be referred to as a“template block” 

46  # 

47  #Everything in this section will be reproduced verbatim in the 

48  #generated header file，except for“$Class”，“$Inc”， 

49  #“$ParamAryTypes”，“$ParamAttrs”，“$ParamFns”and“$ParamImpls”. 

50  # 

51  #Note that no comments beginning with the‘#’character are supported 

52  #within the following section. 

53  # 

54   CPlusPlusBegin 

55   $Inc 

56  namespace 

57  { 

58  class $Class 

59  { 

60  //Array types for parameters storage: 

61  $ParamAryTypes 

62  public: 

63    virtual void preExec()； 

64    virtual void exec()； 

65    virtual void postExec()； 

66    $ParamFns 

67    ... 

68  private: 

69    double m_someVar； 

70    $ParamAttrs 

71    ... 

72  }； 

73  ... 

74  $ParamImpls 

75  }//End namespace 

76  CPlusPlusEnd 

参数化测试类的C++ 

在编译器处理前报头文件时，其建立编译器变量的值，例如$Inc、$Class、$ParamAryTypes等等。这使得其随后可以藉由逐字生成上述C++代码并在编译器变量$Inc、$Class等等的值中指示的位置处扩展来创建下列C++报头。对于FunctionalTest.ph，其为FunctionalTest类创建下列C++报头文件FunctionalTest.h： 

1  #line 7″./FunctionalTest.ph″ 

2  #include<ITest.h> 

3  #line 5″./FunctionalTest.ph″ 

4  #include<Test1.h> 

5  #line 6″./FunctionalTest.ph″ 

6  #include<Test2.h> 

7  #line 55″./FunctionalTest.ph″ 

8  #include<vector> 

9  #line 55″./FunctionalTest.ph″ 

10 #include<Levels.h> 

11 #line 55″./FunctionalTest.ph″ 

12 #include<TestCondnGrp.h> 

13  ... 

14  #line 56″./FunctionalTest.ph″ 

15  namespace 

16  { 

17  #line 7″./FunctionalTest.ph″ 

18  class FunctionalTest:public ITest， 

19  #line 8″./FunctionalTest.ph″ 

20                             public Test1， 

21  #line 8″./EunctionalTest.ph″ 

22                              public Test2 

23  #line 59″./FunctionalTest.ph″ 

24  { 

25  //Array types for parameters storage: 

26  #line 61″./FunctionalTest.ph″ 

27  public: 

28  #line 37″/FunctionalTest.ph″ 

29      typedef std::vector<Tester::TestCondition＊> 

    TestConditionPtrsAry_t； 

30  #line 62″./FunctionalTest.ph″ 

31  public: 

32    virtual void preExec()； 

33    virtual void exec()； 

34    virtual void postExec()； 

35  public: 

36  #line 7″./FunctionalTest.ph″ 

37    void setName(OFCString &name)；#Automatic for all tests 

38  #line 22″./FunctionalTest.ph″ 

39    void setPatternTree(PatternTree＊)； 

40  #line 23″./FunctionalTest.ph″ 

41    String getPListParamDescription() const； 

42  #line 39″./FunctionalTest.ph″ 

43    void addTestCondition(TestCondition＊)； 

44  #line 40″./FunctionalTest.ph″ 

45    void getTestConditionParamDescription() const； 

46  #line 67″./FunctionalTest.ph″ 

47    ... 

48  private: 

49     double m_someVar； 

50  #line 70″./FunctionalTest.ph″ 

51  private: 

52  #line 7″./FunctionalTest.ph″ 

53     OFCString m_name；#Automatic for all tests 

54  #line 21″./FunctionalTest.ph″ 

55     Tester::PatternTree＊m_pPatList； 

56  #line 38″./FunctionalTest.ph″ 

57     TestConditionPtrsAry_t m_testCondnsArray； 

58  #line 71″./FunctionalTest.ph″ 

59      ... 

60  }； 

61  ... 

62  #line 7″./FunctionalTest.ph″ 

63  inline void 

64  #line 7″./FunctionalTest.ph″ 

65  FunctionalTest::setName(OFCString &name) 

66  #line 74″./FunctionalTest.h″ 

67  { 

68     m_name＝name； 

69     return； 

70  } 

71  #line 39″./FunctionalTest.ph″ 

72  inline void 

73  #line 39″./FunctionalTest.ph″ 

74  FunctionalTest::addTestCondition(TestCondition＊arg) 

75  #line 74″./FunctionalTest.ph″ 

76  { 

77     m_testCondnsArray.push_back(arg)； 

78     return； 

79  } 

80  #line 23″./FunctionalTest.ph″ 

81 inline void 

82 Tester::String FunctionalTest::getPListParamDescription() 

83 { 

84  return“The PList parameter for a FunctionalTest”； 

85  } 

86  #line 40″./FunctionalTest.ph″ 

87  inline void 

88  Tester::String FunctionalTest::getTestConditionParamDescription() 

89  { 

90  return“The TestCondition parameter for a FunctionalTest”； 

91  } 

92  #line 75″./FunctionalTest.ph″ 

93  }//Endnamespace 

如前述，此前报头使编译器能够检验FunctionalTest声明的有效性以便成生其代码并生成其可能需要的C++报头。 

作为一范例，考虑到上文给出的FunctionalTest声明，下文为方便起见将其复制： 

Test FunctionalTest FuncTest1 

{ 

   PListParam＝patList1；    #Previously defined pattern list 

   TestConditionParam＝TC1； 

   TestConditionParam＝TC2； 

} 

上文给出了将由编译器为此生成的C++报头。编译器将生成下列代码以用于上述FunctionalTest构造： 

FunctionalTest FuncTest1； 

FuncTest1.setName(″FuncTest1″)； 

FuncTest1.setPatternTree(&patList1)； 

FuncTest1.addTestCondition(&TC1)； 

FuncTest1.addTestCondition(&TC2)； 

还注意到为了描述函数而生成的名称。命名为Xxx的每个参数与下列成员函数相关： 

Status getXxxDescription()const； 

其返回具有对GUI可使用的工具技巧的描述的字符串。 

其它前报头特征 

前报头支持一些其它用户定义的枚举以作为附加类型。此允许GUI提供可用于设定特定参数值的可能选择的下拉列表。此外，前报头提供一个特征以便关联可被看作一个表格的大量参数。例如，将一系列“特性”作为用于名称的一系列字符串和一系列用于这些值的整数的相关集合来执行是便利的。执行此特征的简单方法是使用一系列自定义类型(下文将论述)。然而，这要求用户编写一个即将使用的自定义类型前报头。在下列范例中说明了所有的这些特征： 

#---------------------------------------------------------- 

#File FooBarTest.ph 

# 

#Parameterization specification pre-header for 

#custom test class FoobarTest 

#---------------------------------------------------------- 

Version 1.0； 

Import Test1.ph；            #For base class Test1 

TestClass＝FoobarTest； #The name of this test class 

PublicBases＝Test1；#List of public base classes 

#The parameters list: 

Parameters 

{ 

    #An enumerated type 

    Enum WishyWashy＝Yes，Perhaps，Possibly，Maybe，MaybeNot，No； 

    #Define a WishyWashy parameter. 

    WishyWashy WW 

    { 

       Cardinality＝1； 

       Attribute＝m_ww； 

       SetFunction＝setWw； 

       Description＝“The WW parameter for a Foobar Test”； 

} 

#This class has an array of name-number pairs that is 

#interpreted in the class. 

ParamGroup 

{ 

   Cardinality＝0-n； 

   #The Name field in this array is: 

   #  -of type String 

   #  -[represented by C++ type Tester::String] 

   #  -stored in a member named m_NameArray 

   #  -a function to set it named addName. 

   #  -a parameter description for the GUI to use as a tool tip 

   String Name 

   { 

       Attribute＝m_NameArray； 

       SetFunction＝addName； 

       Description＝“A Name with a Value”； 

   } 

   #The Number field in this array is: 

   #  -of type Integer 

  #  -[represented by C++type int] 

  #  -stored in a member named m_NumberArray 

  #  -a function to set it named addNumber. 

  #  -a parameter description for the GUI to use as a tool tip 

  Integer Number 

  { 

     Attribute＝m_NumberArray； 

     SetFunction＝addNumber； 

     Description＝“The value of the Name”； 

  } 

} 

# The following declaration specifies that a FunctionalTest has 

#  -a parameter of type PList 

#  -[represented by C++ type Tester::PatternTree] 

#  -stored in a member named m_pPatList 

#  -a function to set it named setPattern Tree. 

#  -a parameter description for the GUI to use as a tool tip 

PList PListParam 

{ 

  Cardinality＝1； 

  Attribute＝m_pPatList； 

  SetFunction＝setPatternTree； 

  Description＝“The PList parameter for a FunctionalTest”； 

} 

# 

#The following declaration specifies that a FunctionalTest has 

#  -1 or more parameters of type TestCondition 

#  -[represented by C++ type Tester::TestCondition] 

#  -stored in a member named m_testCondnsArray 

#  -a function to set it named addTestCondition. 

#The[implement]clause causes the translation phase of to 

#generate a default implementation of this function. 

      # 

      TestCondition TestConditionParam 

      { 

         Cardinality＝1-n； 

         Attribute＝m_testCondnsArray； 

         SetFunction＝addTestCondition[Implement]； 

         Description＝“The TestCondition parameter for a 

  FunctionalTest”； 

     } 

  } 

CPlusPlusBegin 

$Inc 

namespace 

{ 

class$Class 

{ 

//Array types for parameters storage: 

$ParamAryTypes 

public: 

      virtual void preExec()； 

      virtual void exec()； 

      virtual void postExec()； 

      $ParamFns 

      //... 

private: 

      double m_someVar； 

      $ParamAttrs 

      //... 

}； 

//... 

$ParamImpls 

}//End namespace 

CPlusPlusEnd 

必须注意到，自定义类型名称数量对可能已经被声明，并且该自定义类型的单一阵列参数可能已经被使用以便具有与上述ParamGroup的参数相同的效果。上文提出的技术是简便的，其避免了声明自定义类型的必要。 

C5.自定义函数声明 

当发生流程转换时，此允许用户调用自定义函数。藉由前报头声明自定义函数，如下： 

#---------------------------------------------------------- 

#File MyFunctions.ph 

# 

#Parameterization specification pre-header for MyFunctions 

#---------------------------------------------------------- 

Version 1.0； 

Functions＝MyFunctions；#The name of this group of functions 

#Declare the following C++ function in the 

#MyFunctions namespace to determine the minimum 

#of two values. 

#   //Return the minimum of x，y 

#   double MyRoutines::Min 

#            (ITestPlan*pITestPlan，int& x，int& y)； 

Integer Min(Integer x，Integer y)； 

#Declare the following C++ function in the 

#UserRoutines namespace to return the average of 

#an array. 

#   //Return the average of the array 

#   double MyRoutines::Avg 

#            (ITestPlan*pITestPlan，double*a，const int a_size)； 

#The C++ function will be called with a and a’Length 

Double Avg(Double a[])； 

#Declare the following C++ function in the 

#UserRoutines namespace to print the dut id 

#and a message 

#  //Return the average of the array 

#  double MyRoutines::Print 

#           (ITestPlan*pITestPlan，String*msg，unsigned int& dutId)； 

#The C++ function will be called with a and a’Length 

Void Print(String msg，UnsignedInteger dutId)； 

通常，需要为上述声明提供一个C++部分，因为编译器将以标准方式扩展这些声明。用户当然需要负责这些函数的C++实现。注意到，所有上述函数将可能采用ITestPlan指示符作为隐式第一参数。此指示符允许函数编写人员存取TestPlan中状态S。例如，函数编写人员可使用ITestPlan接口来存取当前流程、该流程中的当前Flowltem、当前结果子句、UserVars的值和其它这类信息。可将特定测试机定义的函数用于文件Functions.ph中： 

Version 1.2.3； 

# 

#File Functions.ph 

# 

Functions＝Functions；#The name of this group of functions 

#Declare the following C++ function in the 

#Functions namespace 

#Returns the ID of the current DUT being tested by the 

#caller. 

UnsignedInteger GetDUTID()； 

自定义函数声明的C++ 

由编译器生成的用于上述MyFunctions的C++代码将仅声明MyFunctions名称空间中的一些函数： 

namespace MyFunctions 

{ 

   double Min(ITestPlan*pITestPlan，int& x，int& y)； 

   double Avg(ITestPlan*pITestPlan，double*a，const int a_size)； 

   void Print(ITestPlan*pITestPlan，char*Msg，unsigned int dutID)； 

} 

可从一个流程调用这些函数。 

C6.自定义Flowables 

还可能创建一个前报头，其使用前报头来执行C++IFlowable。此使用户能够定义可在Flowltem中运行的自定义Flowable。下文展示了用户定义的Flowable MyFlowable的前报头： 

#---------------------------------------------------------- 

#File MyFlowable.ph 

# 

#Parameterization specification pre-header for MyFlowable 

#---------------------------------------------------------- 

Version 1.2.4； 

FlowableClass＝MyFlowable；  #The name of this custom class 

#The parameters list: 

Parameters 

{ 

   #The following declaration specifies that a MyFlowable has 

   #-1 optional parameter Int1 of type Integer 

#  -[represented by C++type int] 

#  -stored in a member named m_int1Val 

#  -a function to set it named setInt1Val. 

Integer Int1 

{ 

    Cardinality＝0-1； 

    Attribute＝m_int1Val； 

    SetFunction＝setInt1Val； 

} 

#The following declaration specifies that a MyFlowable has 

#  -1 mandatory parameter Int2 of type Integer 

#  -[represented by C++type int] 

#  -stored in a member named m_int2Val 

#  -a function to set it named setInt2Val. 

Integer Int2 

{ 

    Cardinality＝1； 

    Attribute＝m_int2Val； 

    SetFunction＝setInt2Val； 

} 

#The following declaration specifies that a MyFlowable has 

#  -one or more parameters of type String 

#  -[represented by C++type Tester::String] 

#  -stored in a member named m_stringArrVal 

#  -a function to set it named addStringVal. 

String StringItem 

{     

    Cardinality＝1-n； 

    Attribute＝m_stringArrVal； 

    SetFunction＝addStringVal； 

} 

#The following declaration specifies that a MyFlowable has 

   #  -A single PList parameter 

   #  -[represented by the C++ type Tester::PList] 

   #  -stored in a member named m_plist 

   #  -a function to set it named setPListParam 

   PList PListParam 

   { 

        Cardinality＝1； 

        Attribute＝m_plist； 

        SetFunction＝setPListParam； 

   } 

} 

# 

#The section below is part of the Pre-Header which is an escape 

#into C++ code. 

# 

#Everything in this section will be reproduced verbatim in the 

#generated header file，except for“$Class”，“$Inc”， 

#“$ParamAryTypes”，“$ParamAttrs”，“$ParamFns”and“$ParamImpls”. 

# 

#Note that no comments beginning with the‘#’character are supported 

#within the following section. 

# 

CPlusPlusBegin 

$Inc 

namespace 

{ 

class $Class 

{ 

//Array types for parameters storage: 

$ParamAryTypes 

public: 

    virtual void preExec()； 

    virtual void exec()； 

    virtual void postExec()； 

    $ParamFns 

    //... 

private: 

    double m_someVar； 

    $ParamAttrs 

    //... 

}； 

//... 

$ParamImpls 

}//End namespace 

CPlusPlusEnd 

存在若干执行IFlowable接口的类。这些类包括： 

1.用于程序加载的流程，其将检验是否可在当前测试机配置内执行一个测试计划。 

2.用于模式加载的流程，其将加载特定模式和模式列表。 

3.用于初始化的流程，其将使硬件和软件置于已知状态，加载全程符变量，并且执行其它初始化和确认函数。 

4.其它通常有效的流程。 

C7.自定义类型 

上文对测试类参数化的论述仅考虑已知类型的测试类参数，即，基础类型和测试机定义的类型，例如PLists和TestConditions。对于用户灵活性，提供类型可扩展性是重要的，借此可创建和使用类型(其对编译器而言是先验未知的)。将在自定义类型中定义自定义类型(CT)。其可用于定义与C-语言结构体(也称为简单旧数据类型或POD，其与C++中同名类型完全不同)对应的类型以及与用于函数签名的C-语言类型定义(typedef)对应的类型。具有用户类型的独立文件将具有扩展名.ctyp。此处是根据本发明较佳实施例的用户类型声明的一个范例： 

#---------------------------------------------------------- 

#File MyCustomTypes.ctyp 

#---------------------------------------------------------- 

Version 1.0.0； 

CustomTypes   { 

  #A structured Plain-Old-Data type 

  Pod Foo 

  { 

     String     S1；  #String is a standard type 

     Integer I1；  #...and so is Integer 

     String     S2； 

  } 

  #Another structured type using Foo 

  Pod Bar 

  { 

     Foo        Foo1； 

     String     S1； 

     Foo        Foo2； 

  } 

  #     

  #A pointer to a function. 

  #     Return type:Integer 

  #     Parameters:Integer，Integer 

  # 

  Routine BinaryOp(Integer，Integer)Returns Integer； 

  # 

  #Another pointer to a function. 

  #    Return type:  Void 

  #    Parameter:Integer 

    # 

    Routine UnaryOp(Integer)Returns Void； 

    # 

    #A pointer to a function that takes 

    #no parameters and does not return a value. 

    # 

    Routine NullaryOp() Returns Void； 

} 

自定义类型的C++ 

上文提出的CustomTypes声明将由编译器转译成下列C++代码： 

namespace CustomTypes 

{ 

   struct Foo 

   { 

      Tester::String    S1； 

      int               I1； 

      Tester::String    S2 

  }； 

  struct Bar 

  { 

      Foo               Foo1； 

      Tester::String    S1； 

      Foo               Foo2； 

  }； 

  typedef int(*BinaryOp)(int&，int&)； 

  typedef void(*UnaryOp)(int)； 

  typedef void(*NullaryOp)()； 

} 

可将这些类型的对象作为参数传到测试类，如下文所示。 

将自定义类型用作测试类参数 

考虑其中用户具有到文本的扩展的情况下，其需要藉由(除了模式列 表和测试条件之外)其它类对象以及在含有自定义类型的文件(即.ctyp文件)中定义的任意(即，用户定义的)对象来初始化。例如，假设用户希望使用在文件MyTestCTs.ctyp中定义的CT： 

#File MyTesetCTs.ctyp 

Version 1.0； 

CustomTypes 

{ 

   Pod Foo 

   { 

     String name； 

     PList patternList； 

   } 

   Pod Bar 

   { 

     Foo    someFoo； 

     Double dVal； 

   } 

   Routine BinaryOp(Integer，Integer)return Integer； 

} 

用户使用上述类型所需做的就是在其测试类前报头中引入上述文件。由于编译器解译如此定义的CT，因此当其处理测试类前报头时应该可以获得Foo和Bar定义。此外，编译器定义分别对应于上述类型Foo和Bar的两种C-语言结构体，结构体Foo和和结构体Bar，其定义被置于文件myTestCTs.h中。myTestCTs.ctt的引入语句导致文件myTestCTs.h to be#include-d(包括在)所生成的测试类C++报头中。下列范例说明了此过程。首先，考虑测试计划中测试的声明(为了简洁，已经省略了模式列表和测试条件的声明)： 

Import MyFunctions.ph； 

Import MyCustomTypes.ctyp； 

#The CustomVars block defines variables of the Custom 

#types defined earlier. 

CustomVars 

{ 

   Bar bar1＝ 

   { 

      {″This is a Foo″，somePatList}，    #someFoo 

      3.14159                               #dVal 

   } 

   # 

   #A function object that is a binary operator. 

   #The name on the right hand side of the assignment 

   #is a routine declared in MyFunctions，for which， 

   #of course，the user has to provide an implementation. 

   # 

   BinaryOp bop1＝MyFunctions.Min； 

} 

Test MyFancyTest MyTest1 

{ 

  BarParam＝bar1； 

  BinaryOpParam＝bop1； 

} 

在上文的范例中，在测试计划中包括一个CustomVars块。具有用户化变量的独立文件将具有扩展名.cvar。用户将编写MyFancyTest的前报头，其如下支持上述参数化(为了简洁，已省略了模式列表和测试条件的参数 化声明)： 

#---------------------------------------------------------- 

#File MyFancyTest.ph 

# 

#Parameterization specification pre-header for MyFancyTest 

#---------------------------------------------------------- 

Version 1.0.2； 

Import MyCustomTypes.ctyp；      #For CTs used in MyFancyTest 

Import FunctionalTest.ph；    #For base class FunctionalTest 

TestClass＝MyFancyTest；      #The name of this test class 

PublicBases＝FunctionalTest； #List of public base classes 

#The parameters list: 

Parameters 

{ 

  #The following declaration specifies that a MyFancyTest has 

  #  -an optional array of parameters of custom type Bar 

  #  -[represented by C++ type CustomTypes::Bar] 

  #  -stored in a member named m_barsArray 

  #  -a function to set it named addBarParam. 

  #An implementation will be generated for addBarParam. 

  Bar BarParam 

  { 

      Cardinality＝0-n； 

      Attribute＝m_barsArray； 

      SetFunction＝addBarParam[Implement]； 

  } 

  #The following declaration specifies that a MyFancyTest has 

    #  -an optional parameter of custom type BinaryOp 

    #  -[represented by C++ type CustomTypes::BinaryOp] 

    #  -stored in a member named m_binaryOp 

    #  -a function to set it named setBinaryOpParam. 

    #An implementation will be generated for setBinaryOpParam. 

    BinaryOp BinaryOpParam 

    { 

       Cardinality＝0-1； 

       Attribute＝m_binaryOp； 

       SetFunction＝setBinaryOpParam[Implement]； 

    } 

 } 

 CPlusPlusBegin 

 $Inc 

 namespace 

 { 

 class $Class 

 { 

 $ParamAryTypes 

 public: 

    virtual void preExec()； 

    virtual void exec()； 

    virtual void postExec()； 

    $ParamFns 

    //... 

 private: 

    double m_someVar； 

    $ParamAttrs 

    //... 

 }； 

//... 

$ParamImpls 

}//End namespace 

CPlusPlusEnd 

使用自定义类型的自定义测试类的C++ 

最后，一旦编译器已处理了此前报头文件，则其将为MyFancyTest类MyFancyTest.h创建下列C++报头文件： 

#include<MyCustomTypes.b> 

#include<ITest.h> 

#include<FunctionalTest.h> 

namespace 

{ 

class MyFancyTest:public ITest， 

                      public FunctionalTest 

{ 

public: 

    typedef std::vector<CustomTypes::Bar＊>BarAry_t； 

public: 

    virtual void preExec()； 

    virtual void exec()； 

    virtual void postExec()； 

public: 

    void setName(OFCString&name)；#Automatic for all tests 

    void setPatternTree(PatternTree*)； 

    void addTestCondition(TestCondition*)； 

    void addBarParam(CustomTypes::Bar＊)； 

    void setBinaryOpParam(CustomTypes::BinaryOp＊)； 

private: 

    double m_someVar； 

private: 

    OFCString m_name；#Automatic for all tests 

    PattemTree*m_pPatList； 

    TestConditionPtrsAry_t m_testCondnsArray； 

    BarAry_t m_barsArray； 

    BinaryOp＊m_binaryOp； 

}；//End class MyFancyTest 

inline void 

MyFancyTest::addBarParam(CustomTypes::Bar＊arg) 

{ 

    m_barsArray.push_back(arg)； 

    return； 

 } 

 inline void 

 MyFancyTest::setBinaryOpParam(CustomTypes::BinaryOp＊arg) 

 { 

    m_binaryOp＝arg； 

    return； 

 } 

 }//End namespace 

C8.参数化 

如前述，测试类前报头，自定义Flowable类或自定义函数定义，经由参数化规约部分来将受限内省提供到类/函数中。编译器使用此部分来生成类/函数的参数化接口(并生成类/函数报头本身)。对于测试类和Flowable类，还使用此部分来随后生成测试计划代码中的调用以初始化该类的实例。应注意到下列关于前报头和相应声明的点： 

1.较佳地在前报头中指定每个测试或自定义Flowable类定义。前报头中的参数块较佳是可指定这种类的参数列表的唯一位置。(因此，作为推论，测试的“标准”参数，例如模式列表和测试条件规约，还需要包括在前报头的参数块中；此允许一致地处理所有参数，标准和CT)。 

2.测试或Flowable类的前报头中定义为不可选(即，具有非零基数)的所有参数应该在该类的实例的测试块或Flowable块声明中被初始化。 

3.用于Test/Flowable块中参数初始化的对象应该是先前已经被定义。 

4.重置指示符$Class、$Inc、$ParamAryTypes、$ParamFns、$ParamAttrs和SparamImpls必须出现在前报头用户代码部分内的确切位置，用户希望在生成的类报头文件中相应生成的代码插入该位置。这些应该刚好出现一次，因为为每一者生成特定代码。 

5.前报头参数块中参数规约的名称(例如，上文范例中的PListParam、TestConditionParam或BarParam)是将用于该类的实例的声明中的参数名称。 

6.下文是用于参数规约的描述符的语义： 

a.基数：此指示将支持的此类型参数的数量。下文是一实施例中可能的值： 

i.1：此参数是强制性的并且应该刚好指定一次。此参数将保持为对该参数类型的对象的指示符。 

ii.0-1：此参数是可选的；如果被指定，则其必须仅被指定一次。此参数将保持为该参数类型的对象的指示符。 

iii.1-n：此参数是强制性的。此外，可为此参数指定多个值。这些值将以规约的顺序被存储。 

iv.0-n：此参数是可选的。可为此参数指定多个值。这些值将以规约的顺序被存储。 

注意到，对于()和()之上，所有指定值将被存储在一个STL向量 中，建模在该参数类型的指示符上。将在由$ParamAryTypes指示的点处定义并嵌入此向量的类型 

b.属性：将用作此类型参数值(多个参数值)的存储的C++变量的名称。该名称将被逐字复制成C++类的私有数据成员，且必须符合C+ +标识符的要求。注意到，此属性的类型为： 

i.如果仅允许单一值，则为该参数类型的指示符； 

ii.如果允许多个值(参见()之上)，则为STL向量 ，建模在该参数类型的指示符上。 

注意到，属性保持对由测试计划创建和组装的对象的参考，而不拥有这些对象。对象的使用期通常藉由测试计划自身来管理。 

c：SetFunction：用于设定此参数值的函数的名称。应该注意下列各点： 

i.该名称将被逐字复制，因而必须符合C++语言要求。 

ii.该函数的存取级别通常是公开。 

iii.返回类型通常是空。 

iv.该函数通常仅采用类型指示符到参数类型的单一变元。 

注意到，通常单独地设定一个值；即，对于允许指定多个值的参数，测试计划中生成的代码将重复地调用此函数，为每个指定的值调用一次，每一个将被添加到STL向量(如上文所述)。 

函数名成后面的可选关键字“[implement])”指示将获得此函数的平常实现(trivial implementation)，作为类报头(在由$ParamImpls所指示的点处嵌入)中的内联方法。或者，用户负责提供该函数的实现。 

d.描述(Description)：作为工具技巧的字符串文字，在此参数的运行时间修改期间，GUI工具将使用其来提供帮助。在名为Xxx的参数的自定义类中生成的C++成员函数将为 

string getXxxDescription() const； 

该函数将返回指定字符串。 

藉由用户化的测试计划范例 

下文展示藉由一些用户化来建立的测试计划范例： 

#---------------------------------------------------------- 

#File MyCustomizedTestPlan.tpl 

#---------------------------------------------------------- 

Version 0.1； 

# 

#Imports asbefore... 

# The following import is implicit，but can be explicitly 

# provided. 

Import FunctionalTest.ph； 

# Import for MyFlowables，MyFunctions and Functions 

Import MyFlowables.ph； 

Import MyFunctions.ph； 

Import Functions.ph； 

#---------------------------------------------------------- 

# Start of the test plan 

#---------------------------------------------------------- 

TestPlan Sample； 

# This block defines Pattern Lists file-qualified names and 

# Pattern List variables that are used in Test declarations. 

# The file-qualified names refer to pattern lists in the named 

# files.The variables refer to String variables which will 

# hold the pattern list names at run time.User defined Flowable 

# objects could set the values of these variables through an 

# API. 

PListDefs 

{ 

    # File qualified pattern list names 

    pl1A.plist:pat1Alist， 

    pl2A.plist:pat2AList， 

    # Pattern list variables 

    plistXxx， 

    plistYyy， 

    plistZzz 

} 

#SocketDef，UserVars declaration as before... 

#Declarations of TestConditions TC1Min，TC1Typ，TC1Max， 

#TC2Min，TC2Typ，TC2Max as before... 

# 

#Declare a FunctionalTest.“FunctionalTest”refers to a C++ 

#test class that runs the test，and returns a 0，1 or 2 as 

#a Result.The Test Condition Group TCG1 is selected with 

#the″min″selector by referring to the TC1Min TestCondition. 

# 

#Note that compiler can compile this because of the imported 

#FunctionalTest.ph file. 

# 

Test FunctionalTest MyFunctionalTest1Min 

{ 

   PListParam＝pat1AList； 

   TestConditionParam＝TC1Min； 

} 

# 

#Additional FuncionalTest declarations for the following，as before 

#    MyFunctionalTest1Typ 

#    MyFunctionalTest1Max 

#    MyFunctionalTest2Min 

#    MyFunctionalTest2Typ 

#    MyFunctionalTest2Max 

# 

#Here is a declaration of MyFlowable.It uses a PatternList variable 

#plistXxx which is initialized by the flowable prior to use here. 

# 

#Compiler can compile this because of the imported MyFlowables.ph file: 

Flowable MyFlowable MyFlowable1 

{ 

    Int1＝10； 

    Int2＝20； 

    StringItem＝“Hello World”； 

    PListParam＝plistXxx； 

} 

#Counters for PassCount and FailCount as before... 

#Flows as before.Flows FlowTest1 and FlowTest2 are 

#unchanged from the previous example. 

Flow FlowTest1 

{ 

    #... 

} 

Flow FlowTest2 

{ 

    #... 

} 

# 

#Now FlowMain，a main flow，can be presented.It 

#implements a finite state machine that calls FlowTest1 

#and FlowTest2 as below: 

#------------------------------------ 

#    Result 0    Result 1 

#------------------------------------ 

#  FlowMain_1  FlowMain_2  return 1 

#  FlowMain_2  FlowMain_3  return 1 

#  FlowMain_3  FlowMain_4  return 1 

#  FlowMain_4  FlowMain_5  return 1 

#  FlowMain_5  return 0    return 1 

# 

#Where the IFlowables run by each FlowItem are: 

#------------------------------------ 

#     FlowItem        IFlowable that is run 

#------------------------------------ 

#     FlowMain_1      MyFlowable1 

#     FlowMain_2      DatalogStartFlow 

#     FlowMain_3      FlowTest1 

#     FlowMain_4      FlowTest2 

#     FlowMain_5      DatalogStopFlow 

# 

Flow FlowMain 

{ 

  # 

  # The first declared flow is the initial flow to be 

  # executed.It goes to FlowMain_InitializationFlow 

  # on success，and returns 1 on failure. 

  # 

  FlowItem FlowMain_1 MyFlowable1 

  { 

     Result 0 

     { 

         Property PassFail＝″Pass″； 

         IncrementCounters PassCount； 

         # A user function call 

         MyFunctions.Print(“Passed MyFlowable1”， 

                            Functions.GetDUTID())； 

         GoTo FlowMain_2； 

     } 

     Result 1 

     { 

         Property PassFail＝″Fail″； 

         InerementCounters FailCount； 

         # A user function call 

         MyFunctions.Print(“Failed MyFlowable1”， 

                      Functions.GetDUTID())； 

    SetBin SoftBins.“3GHzLeakage”； 

    Return 1； 

  } 

} 

# 

#Goes to FlowMain_3 on success 

#and returns 1 on failure. 

# 

FlowItem FlowMain_2 DatalogStartFlow 

{ 

  Result 0 

  { 

    Property PassFail＝″Pass″； 

    IncrementCounters PassCount； 

    #A user function call 

    MyFunctions.Print(“Passed DatalogStartFlow”， 

                        Functions.GetDUTID())； 

    GoTo FlowMain_3； 

  } 

  Result 1 

  { 

    Property PassFail＝″Fail″； 

    IncrementCounters FailCount； 

    MyFunctions.Print(“Failed DatalogStartFlow”， 

                      Functions.GetDUTID())； 

    Return 1； 

  } 

} 

#This FlowItem calls the previously defined FlowTest1 

FlowItem FlowMain_3 FlowTest1 

{ 

   Result 0 

  { 

     Property PassFail＝″Pass″； 

     IncrementCounters PassCount； 

     #A user function call 

     MyFunctions.Print(“Passed FlowTest1”， 

                    Functions.GetDUTID())； 

     GoTo FlowMain_4； 

  } 

  Result 1 

  { 

     Property PassFail＝″Fail″； 

     IncrementCounters FailCount； 

     #Auser function call 

     MyFunctions.Print(“Failed FlowTest1”， 

                       Functions.GetDUTID())； 

     SetBin SofBins.“3GHzCacheFail”； 

     Return 1； 

  } 

} 

#This FlowItem calls the previously defined FlowTest2 

FlowItem FlowMain_4 FlowTest2 

{ 

   Result 0 

   { 

     Property PassFail＝″Pass″； 

     IncrementCounters PassCount； 

     #A user function call 

     MyFunctions.Print(“Passed FlowTest2”， 

                        Functions.GetDUTID())； 

     GoTo FlowMain_5； 

    } 

    Result 1 

    { 

       #FlowTest1 passed，but FlowTest2 failed 

       Property PassFail＝″Fail″； 

       IncrementCounters FailCount； 

       #A user function call 

       MyFunctions.Print(“Failed FlowTest2”， 

                          Functions.GetDUTID())； 

       SetBin SoftBins.“3GHzSBFTFail”； 

       Return 1； 

    } 

  } 

  FlowItem FlowMain_5 DatalogStopFlow 

  { 

    Result 0 

    { 

       #All Passed！ 

       Property PassFail＝″Pass″； 

       IncrementCounters PassCount； 

       #A user function call 

       MyFunctions.Print(“Passed all！”， 

                          Functions.GetDUTID())； 

       SetBin SoftBins.“3GHzAllPass”； 

       Return 0； 

    } 

    Result 1 

    { 

       #FlowTest1 and FlowTest2 passed， 

       #but DatalogStopFlow failed 

       Property PassFail＝″Fail″； 

      IncrementCounters FailCount； 

      #Auser function call 

      MyFunctions.Print(“Failed DatalogStopFlow”， 

                          Functions.GetDUTID())； 

      Return 1； 

    } 

  } 

} 

关于上述代码，需要注意下列各点： 

1.这里的PListDefs部分具有一些PList名称并且还具有一些PList变量。PList名称是在测试中可直接使用的名称。PList变量是在测试中可使用的变量，并且其值在运行时间藉由自定义Flowable中的代码而约束到实际PLists。 

2.PListDefs部分是可选的。如果不存在，则将由编译器从各个测试声明中推断其内容。如果存在，则其必须声明所有使用的测试的PList参数，尽管其可能声明更多的内容。 

3.可利用运行时间API来将值分配给PList变量。TestPlan类将具有函数： 

Status SetPListVariable(const Tester::String& varName， 

const Tester::String& fileQualifiedPListName)； 

Flowable能够使用上述函数将PListVariable约束到特定PList。 

4.可刚好在转换之前在Flowltem中调用用户函数和函数，其为到另一Flowltem的控制转移，或返回。 

用户函数调用的C++ 

除了在流程中启用自定义函数调用之外，已经为上文提出的各种用户化技术展示了将由编译器生成的C++代码。较佳地由每个流程的IUserCalls成员来处理Flowltem中的用户函数调用。每个流程较佳具有一个接口IuserCalls成员，其导出单一虚拟成员函数，如下文所示： 

class IUserCalls 

{ 

public: 

   virtual void exec(const String& flowItemName， 

                        unsigned int result)＝0； 

}； 

当遇到具有用户函数调用的流程时，该流程在一个类的实例中得以组 装，该类执行上述接口。例如，在该范例中的FlowMain中，将以下列类的实例来组装该流程： 

class FlowMain_UserCalls:public IUserCalls 

{     

public: 

   virtual void exec(const String& flowItemName， 

                        unsigned int result) 

   { 

      if(flowItemName＝“FlowMain_1”) 

      { 

         //... 

      }else if(flowItemName＝“FlowMain_2”) 

      { 

         //... 

      }else if(flowItemName＝“FlowMain_3”) 

      { 

         switch(result) 

         { 

         case 0: 

             MyFunctions::Print(“Passed FlowTest1”， 

                                     Functions::GetDUTID())； 

             return； 

         case 1: 

             MyFunctions::Print(“Failed FlowTest1”， 

                                   Functions::GetDUTID())； 

             return； 

         default: 

        return； 

      } 

    } 

    else if (FlowItemName＝“FlowMain_4”) 

    { 

      //... 

    } 

    else if(flowItemName＝“FlowMain_5”) 

    {     

      //... 

    } 

  } 

}； 

Flowltem::execute()操作知道流程项的名称。在其将指示符返回下一流程之前，其将调用IUserCalls::exec()以便封入流程、传递其自身的流程项名称和当前结果的值。此将导致上述代码被执行，启用所需的用户定义函数。 

C9.测试程序编译 

如上文所解释，测试计划描述文件指定用于测试计划的对象及其彼此之间的关系。在一实施例中，此文件被转译成将以标准接口ItestPlan的实现的形式在现场控制器上执行的C++代码。可将此代码封装入Windows动态链接库(DLL)中，其可被加载到现场控制器。生成测试程序DLL以使其具有标准已知进入点，现场控制器软件可使用该进入点生成并返回其所含有的TestPlan对象。 

来自测试计划描述的构造 

从测试计划描述变换到ITestPlan实现的过程是藉由测试程序编译器400来完成。此过程以两个阶段发生：转译和编译。 

在转译阶段402，编译器400处理测试计划文件(及其引入的其它文件)以及用于测试计划的所有测试类型的前报头。在此阶段，其创建测试计划对象的C++代码和所遇到的测试类型的C++报头，连同所有其它支持文件，例如MSVC++(Microsoft Visual C++)工作区和项目文件、DLL“样板”代码等等。编译器400将文件和线路定向(line directive)嵌入生成的代码中以确保编译时间错误讯息回头查阅描述文件中的适当位置而不是指向生成的代码。 

编译阶段发生在已经创建必要的文件之后，在编译阶段，调用标准编译器404，例如MSVC++编译器，以便编译文件并将其链接入DLL。 

编译器采用有效测试计划文件(及所有相关文件)作为输入，并必要 地生成由测试计划文件中的“引入”定向所表示的TestPlan文件和所有其它文件。此外，其生成一MSVC++“方案”以便建立测试计划DLL。例如，如果主文件(MyTestPlan.tpl)包括Timingl.tim以纳入计时信息，则编译器将创建下列文件(以及其它文件)： 

MyTestPlan.h 

MyTestPlan.cpp 

Timingl.cpp 

MyTestPlan.sln(MSVC++“Solution”file) 

MyTestPlan.vcproj(MSVC++“Project”file) 

在创建(或更新)所有文件之后，编译器调用MSVC++应用程序，指定其创建的“方案”并建立DLL。任何错误和/或警告都会展示给用户。 

如果用户在建立测试计划之后改变Timing1.tim，则用户随后可调用编译器，向其传递MyTestPlan.tpl。编译器将(藉由时标信息)承认主测试计划文件没有被改变，从而不会重新创建MyTestPlan.h/.cpp。然而，在处理主测试计划文件时，将发现Timing.tim文件已经被改变。因此，将重新创建Timing1.cpp文件并调用MSVC++应用程序以便重建DLL。此避免重新编译MyTestPlan.cpp，而是仅编译Timing1.cpp和重新链接DLL。对于花费大量时间来编译的较大测试计划，此方法在删减重新编译和重新链接时间时尤其有效。 

D.运行测试程序 

现场控制器软件将测试程序DLL加载到其进程空间并调用DLL内的“工厂”函数以便创建测试计划对象的实例。一旦创建测试计划对象，则现场控制器软件随后可执行测试计划或以任何其它必须的方式与其相互作用。 

非交互式建立 

对于大多数C++软件开发者，在Windows环境中建立应用程序(或DLL、或库等等)意味着提出开发环境(MS Visual C++、Borland C++或类似环境)、编辑代码、以及(通常)按下一个按钮以便建立该产品。 

本发明一实施例的测试环境将具有类似组的行为。测试计划开发者需要编辑代码并建立其测试计划。然而，测试机不要求测试计划开发者提出C++开发环境以产生所得测试计划DLL。 

为了实现此过程，本发明采用了非交互式建立的概念。非交互式建立定义为以非交互式模式使用MS VIsual C++的建立。注意到，此仍然允许交互式使用其它工具来管理这种建立。唯一的含义是非交互式使用VisualC++。 

假设环境 

对用户环境进行了特定假设。该等假设为： 

1.测试计划开发者将根据上述方法和规则开发其测试计划。 

2.测试计划开发者可能不具有专家级的C++知识。 

3.测试计划开发者可存取命令行工具或GUI工具以便将文件(多个文件)转换成测试计划DLL。 

不藉由按钮来建立应用程序 

以VIsual Studio工作非交互式地要求下列两种途径之一。第一(且最简单的)途径是使用命令行接口。第二(且更复杂的)途径是使用自动化(Automation)接口。此部分描述了所有两种途径。 

创建项目 

为了非交互式使用Visual Studio，应该以含有一或多个有效项目的工作方案开始。不幸的是，此是通过命令行或自动化途径都无法实现的一个任务。两种方法都不能提供用于项目创建的机制。但是，可以从模板创建用于Visual Studio的项目和方案。因此，如果给出开始的项目名称和模板，则可创建用于Visual Studio的方案/项目。 

生成项目(Populating the Project) 

因为命令行不支持向所产生的项目添加新文件，因此使用Visual Studio自动化模型来向所产生的项目添加新文件。提供两种Visual Studio宏命令来将新的和现有文件添加到项目中。使用活动脚本引擎(例如，VBScript、JScript、ActivePerl、ActivePython等)的外部脚本可使用类似代码来执行相同任务。因此，我们的代码生成工具能够创建新的文件，并且使用自动化模型将其添加到现有Visual Studio项目。在创建文件之后，若必要则可藉由工具来对其进行更新。 

建立项目 

一旦将方案和项目置于适当位置，则存在若干选项以便非交互式使用Visual Studio来建立测试计划。最简单的选项是从命令行调用测试计划。这种命令行看起来类似于： 

devenv solutionFile/build solutionCfg 

其中solutionFile(方案文件)是Visual Studio方案文件，而solutionCfg是可应用于方案内项目的特定配置。另一方案是将Visual Studio对象模型用于自动化。此允许对建立和配置程序的细晶(finer grain)控制。如上文所述，其包含一列Perl脚本以便从命令行建立一个项目。此程序读取一个配置文件，其指定待建立的项目和配置(以及关于这些项目的其它信息)，并且使用自动化模型来建立所有这些项目和配置(以及关于这些项目的其它信息)。注意$msdev对象在此脚本中的使用，例如，如何在脚本中使用自动化对象。 

调试程序支持 

为了使测试类开发者能够检验和调试其工作，其需要存取一个调试程序，该调试程序允许测试类开发者中断入现场控制器并单步调试其代码。 由于编译器生成的代码是藉由MSVC++编译的C++，因此可使用MSVC++调试程序来调试测试类实现。注意到，此特征仅对测试类开发者或其他直接以C++工作的人有意义。将向想要调试或单步调试测试程序的操作的测试工程师提供其它机制，而不需要直接引用生成的C++代码。 

系统软件环境 

此部分描述用于测试机的通用软件环境：用户测试计划所要求的文件的位置、指定这些文件的替代位置的机制、和指定测试计划和模块控制软件的位置的方法。 

测试计划所要求的环境 

可藉由例如由环境配置文件所指定的“环境”变量来配置测试计划所要求的系统标准位置以及用于下列各项的搜索路径的运行时间配置： 

1.模式列表 

2.模式 

3.计时数据，以及 

4.测试类DLL 

这些是文本文件，具有简单语法，例如： 

Tester_PATOBJ_PATH＝″patterns\data；D:\projects\SC23\patterns\data″ 

具有在文本文件中定义的而不是通过本地支持OS的环境变量来定义的这种“环境”的优势在于：实现不受到支持OS的环境变量所具有的共同限制条件的限制，例如，最大字符串长度等等。下列“环境”(设置)变量将用于上文列举的实体： 

模式列表：Tester_PATLIST_PATH. 

模式对象文件：esterJPATOBJJPATH. 

模式源文件：Tester_PATSRC_PATH(请了解，此文件是可选的) 

计时数据文件：Tester_TMING_PATH. 

测试类DLL：Tester TEST CLASS LIBPATH. 

为了支持特定情况同时保持有效的默认行为，提供三个级别的配置。以递增的先后顺序来对此进行描述：首先，系统环境设置文件$Tester_INSTALLATION_ROOT\cfg\setups\Setup.env将指定“环境”变量的默认值。如果不能利用其它配置机制，则将需要此文件。通常，其可以被在系统上运行的所有测试计划利用。在安装期间，藉由安装和配置管理(ICM)系统来创建此文件，以来自安装程序的输入来为上文提及的三个变量分配默认值。(注意：除了上述三个变量的系统默认值，此文件还将包括特定其它测试机“环境”变量的系统默认值，如下列子部分所描述。) 

其次，用户可将环境设置文件指定为测试计划的运行时间变元。此运 行时间配置中的变量6优先于默认定义。 

最后，测试计划可使用专用块来指定用于其执行的环境变量。测试计划中定义的变量将优先于默认系统文件或用户定义的文件中的变量。 

通常，应该通过上述机制之一来定义所有必要的变量。如果未定义变量，则将发生运行时间错误。 

其它环境设置 

除了用户测试计划所需的“环境”变量之外，测试环境还需要下列两个“环境”变量： 

1.Tester_TEST_PLAN_LIBPATH：此指定系统控制器将用于寻找应该加载的用户测试计划DLL的搜索路径。注意到：相同搜索路径还可以用于寻找用户插针描述和插口文件。在ICM的安装时间中指定的此变量的默认值藉由该ICM存储在文件$Tester_INSTALLATION_ROOT\cfg\setups\Setup.env中。 

2.Tester_MODULE_LIBPATH：此指定系统将用于加载供货商提供的硬件模块控制软件DLL的搜索路径。从配置管理数据库(CMD)提取的此信息还藉由ICM存储在文件$Tester_INSTALLATION_ROOT\cfg\setups\Setup.env中。 

注意到，尽管用户能够覆写在Tester_TEST_PLAN_LIBPATH变量的Setup.env文件中给出的值，但是除非用户想要显式地改变供货商提供的硬件模块控制软件DLL地搜索路径，否则不应该改变在Tester_MODULE_LIBPATH的Setup.env文件中给出的值。 

搜索路径规约语义 

关于指定搜索路径的“环境”变量，应注意下列各点： 

1.每一个应该是分号(″；″)间隔开的目录名的列表，系统将搜索该列表以寻找特定类型的参考文件。 

2.在初始系统检查这个“环境”变量的值之后，用户对该变量的值的任何改变(例如，藉由编辑环境配置文件)只有在用户显式地“通知”系统这样做的必要性时才会被该系统记录。 

3.搜索路径中的相对路径名将被解释为相对于相关环境变量的特定设定(其提供定义根目录的功能性)，由于相对于“当前工作目录”(CWD)的路径可能导致模糊结果，因为分布式环境(例如测试机做工作的环境)中的CWD观念可能不是用户直观希望的环境。此相关环境变量(其指定搜索路径中所有相对路径名将相对于其而被假设的根目录)是″Tester_INSTALLATION_ROOT″变量，其给出用户系统上测试机安装的最高级(即″根目录″)目录的位置。 

4.目录入口含有集合[V:*？″ 

|；]中的字符；注意到，除了分号(″；″)之外，此集合中的所有其它字符在Windows文件名称都是非法的。分号(″；″)不应用于搜索路径入口，因为其是用于区别搜索路径中的入口。注意到，路径名可以具有嵌入的空格，但是紧接着路径名之前或之后出现(即，在路径名中的第一个非空格字符之前和最后一个非空格字符之后)的所有空格将 不会被看作是路径名的部分，且将会被忽略。 

5.将以搜索路径目录在定义中出现的顺序来搜索这些搜索路径目录。文件的首次出现将为一个选择。 

E.测试模式 

极大组测试模式文件的有效管理、处理和加载是本发明一实施例的框架的重要结构方面。分级的模式列表的观点被看作是提供易处理的概念化和终端用户使用系统使用该系统的简易性。 

藉由测试向量，测试系统可利用对DUT的激励。通常可将向量分类成相续(或线性)、扫描或算法模式生成器(APG)产生的。在本发明一实施例的系统中，按照在测试时间应用的模式来组织测试向量。由用户测试程序中的模式对象来表示模式。在该系统中，以模式列表组织模式，其由模式列表对象来纲领性地表示。模式列表对象表示模式的有序列表或其它模式列表。以列表组件中声明顺序按时定序。注意到，如果仅需一种单一模式时，则其需要封入列表本身。 

用户测试程序中的模式列表对象与磁盘上的模式列表文件相关联，该模式列表文件含有模式列表的实际定义。因此，藉由相关磁盘文件(下文将对此进行进一步的描述)的内容对此进行动态确定。 

模式列表的定义向模式列表提供显式名称，并且藉由文件名关联性来识别模式有序列表和/或其它模式列表。其还提供执行选项的规约，将在描述模式对象之后对此进行详细描述，因为选项可应用于模式列表和模式两者。模式列表应该遵循下列规则： 

file-contents: 

     version-info global-pattern-list-definitions 

version-info: 

     Version version-identifier； 

global-pattern-list-definitions: 

     global-pattern-list-definition 

     global-pattern-list-definitions global-pattern-list-definition 

global-pattern-list-definition: 

    global-pattern-list-declaration{list-block} 

global-pattern-list-declaration: 

    GlobalPList pattern-list-name options_opt

list-block: 

    list-entry 

    list-block list-entry 

list-entry: 

    pattern-entry； 

    pattern-list-entry； 

    global-pattern-list-definition； 

    local-pattern-list-definition； 

pattern-entry: 

    Patpattern-name options_opt

pattern-list-entry: 

    PList pattern-list-reference options_opt

pattern-list-reference: 

    pattern-llist-qualiffed-name 

    file-name’:’pattern-list-qualified-name 

pattern-list-qualified-name: 

    pattern-list-name 

    pattern-list-qualified-name‘ .’pattern-list-name 

local-pattern-list-definition: 

    local-pattern-list-declaration{list-block} 

local-pattern-list-declaration: 

    LocalPList pattern-list-name options_opt

 options: 

    option 

    options option 

option: 

    [option-definition] 

option-definition: 

    option-name option-parameters_opt

option-parameters: 

    option-parameter 

    option-parameters‘，’option-parameter 

下文是对上文所使用的未定义非终结符的描述： 

1.version-identifier：来自集合[0-9.]的一或多个字符的序列，其中首字符必须是数字。 

2.name：来自集合[a-zA-Z_0-9]的一或多个字符的序列，其中首字符必须是来自集合[a-zA-Z]。 

3.pattern-list-name：来自集合[a-zA-Z_0-9]的一或多个字符的序列，其中首字符必须是来自集合[a-zA-Z] 

4.file-name：有效Windows文件名(如果文件名中存在任何空格，则必须以双引号封入)。注意到，此应该是一个简单文件名，即，其不应该具有目录组件。pattern-list-referenc(模式列表引用)可以是对相同文件中模式列表的内部引用，或者是对另一文件中模式列表的的外部引用。需要藉由文件名来限定外部引用。 

5.option-name：来自集合[a-zA-Z_0-9]的一或多个字符的序列，其中首字符必须是来自集合[a-zA-Z]。 

6.option-parameter：来自集合[a-zA-Z_0-9]的一或多个字符的序列。 

模式列表文件支持注释，其意味着可被模式列表文件解析器忽略。注释以′#′字符开始，并且延伸到此行结束。 

E1.模式列表规则 

模式列表的静态或编译时间规则支配名称的声明和解析。呈模式列表语言的名称藉由global-pattern-list-definitions(全程模式列表定义)和local-pattern-list-definitions(局部模式列表定义)来声明。其被pattern-list-references(模式列表引用)引用。下文是支配这些声明和引用的一些规则。 

1.global-pattern-list-definition(全程模式列表定义)或local-pattern-list-defmition(局部模式列表定义)声明模式列表的名称。pattern-list-reference(模式列表引用)声明所声明的模式列表的名称。全程模式列表的名称是全程已知的。局部模式列表的名称仅在其被声明的列表块中是已知的。在该列表块中，其可被无限定的直接引用。在更深层次的嵌套声明中，限定的名称将需要引用局部模式列表。 

2.局部模式列表名称在封入模式列表的领域中是已知的，而全程模式列表名称在该系统领域是已知的。例如： 

GlobalPListG1 

{ 

   LocalPList L1 

   { 

      LocalPList L2 

      { 

      } 

      GlobalPList G2 

      { 

      } 

      PList L2；    #OK.Name L2 is known in this scope 

      PListG2       #OK.Name G2 is global 

   } 

   PList L2；       #Error.Name L2 is not known here. 

   PList L1.L2；    #OK.Name L1 is known here.L2 is known by 

                    #    qualification. 

   PList G1.L1.L2； #OK.Qualification by G1is not needed but 

                    #is allowed. 

   PList G2；       #OK.Name G2 is global 

 } 

3.全程模式列表可以最外级在模式列表文件中被定义，或者可被定义为嵌套在封入模式列表中。但是，嵌套只是一种便利。其概念性定义为处于文件中最外级的全程模式列表。嵌套全程模式列表语义上等效于相同名称的最外(非嵌套)全程模式列表。因此，例如： 

          GlobalPList G1 

          { 

            GlobalPList G2... 

          } 

is semantically equivalent to: 

          GlobalPList G1 

          { 

            PList G2；#References G2 

          } 

          GlobalPList G2... 

4.一致地命名所有全程模式列表。 

    GlobalPList G1 

    { 

      #Note that this is as if declared at the outermost level 

      #with a reference to it right here. 

      GlobalPList G2 

      { 

      } 

    } 

    #This declaration will be an error in this or any other file， 

    #as the name G2 is already taken. 

    GlobalPList G2#Error.Global name G2 is taken. 

    { 

    } 

5.局部模式列表通常使其定义嵌套在封入的模式列表中，其还确定局部模式列表的名称范围。局部模式列表在其封入模式列表中被一致地命名。局部模式列表在句法上不允许出现在模式列表文件的最外级。 

  GiobalPList G1 

  { 

    LocalPList L1 

    { 

    } 

    LocalPList L2 

    { 

       LocalPList L1#OK.No local name L1 is declared 

directly 

               #in the enclosing scope defined by L2. 

       { 

       } 

       PList L1；  #OK.Refers to L1 declared in L2 

       PList G1.L1；#OK.Refers to L1 declared in G1. 

    } 

    #Error.Redeclaring name L1 when the enclosing scope 

    #defined by G1 already has an L1 declared in it. 

    LocalPList L1； 

    { 

    } 

  } 

6.每个模式列表文件含有一或多个全程模式列表的定义。此直接遵循语法。最外级是global-pattern-list-definition，且必须存在其中的至少一个。 

7.pattern-name(模式名称)是对模式的引用，遵循Pat关键字。其引用藉由向模式名称串联一个后缀.pat而获得名称的模式文件中的模式。该文件表示将沿着为模式定义的搜索路径而获得的文件。 

8.pattern-list-reference(模式列表引用)是对遵循PList关键字的模式列表的引用。该引用包括一个可选文件名，接着是一个限定模式列表名称，其只是由点间隔开的名称列表。因此，例如，下文可以是一个pattern-list-referrence： 

PList foo.plist:G1.L1.L2.L3； 

引用一个嵌套在L2中的局部模式列表L3，其中L2嵌套在L1中，而L1嵌套在全程模式列表G1中，全程模式列表G1处于文件foo.plist中。 

上述名称中最左端的名称片段必须被解析成一个全程模式列表或一个局部模式列表，从引用点可见该局部模式列表。 

对pattern-list-reference(模式列表引用)的名称解析如下进行： 

1.每个名称片段解析成一个在其之前的前缀内容中所声明的名称。 

2.如果存在文件限定，则最左端名称片段解析成一个在命名文件中声明的全程模式列表。 

3.如果不存在文件限定，则最左端名称可以解析成一个处于封入范围内的局部模式列表，并且如果此未成功则解析成一个处于下一个封入范围内的局部模式列表，以此类推，直到一个处于封入全程符范围内的局部模式列表。 

4.需要将搜索范围限制在最接近的封入全程符范围内以便使全程符范围的语义保持如同在模式列表文件最外级处所声明的一样。如果嵌套全程符范围在最外级(等效地)按原文声明，则名称解析搜索将在检查其范围后终止。 

5.如果先前步骤没有对引用进行解析，则可将最左端名称片段解析成此相同文件内的全程模式列表。 

6.如果先前步骤没有对引用进行解析，则可将最左端名称片段解析成一个全程模式列表，其在该文件中藉由将.plist后缀添加到最左端名称片段而得以命名。 

7.如果先前步骤没有对引用进行解析，则该引用是错误的。 

如上文所提及，上述规则指示最左端名称片段被解析成一个从引用点可见的局部模式列表或一个全程模式列表。 

下文的范例说明这些观念中的一些。 

GlobalPlist G1 

{ 

    PList G3；#OK.Refers to a pattern list later in this file. 

    PList G4；#OK.Refers to a pattern list in file“G4.plist” 

    #OK.Refers to G1 in the file“my_plists.plist”. 

    PList my_plists.plist:G1； 

    #OK.Refers to a pattern list in file“my_plists.plist”. 

The 

    #qualified name refers to a local pattern list named L2 

declared 

    #in the scope of a local pattern list named L1 declared in 

the 

    #scope of a global pattern list named G1. 

    PList my_plists.plist:G1.L1.L2； 

    LocalPList L1 

    { 

        LocalPList L2 

        { 

        } 

      } 

      PList L1；#OK.Refers to L1 declared in the 

            #enclosing scope of G1 

    } 

    GlobalPlist G2 

    { 

      LocalPList L2 

      { 

      } 

      GlobalPList G3 

      { 

    LocalPList L3 

  { 

  } 

  PList L1；#Error.No L1 declared in this or any enclosing 

        #scope； 

  #Error.The name L2 is not deelared in this scope.Also 

  #though L2 is declared in the enclosing scope，this scope 

  #is global，and so no further enclosing scope is examined. 

  # 

  #Contrast with reference to name L2 in LocalPList L3 below. 

  PList L2； 

  PList G1.L1；#OK.Refers to L1 in G1. 

     #Error.G3 is not really nested inside G1.Since G3 

     #is global，it is really declared at an outermost level， 

     #and so G1.G3 is meaningless. 

     PList G2.G3.L3； 

  } 

  LocalPList L3 

  { 

     #OK.Refers to G2.L2.The enclosing global scope is G2 

     #and the nameL2 is declared in G2. 

     PList L2； 

  } 

} 

要求所有模式列表文件名和模式文件名称在使用其的测试计划之间保持唯一。 

模式列表引用可称为在相同文件中引用之前或之后定义的模式列表。 

不允许递归和共同递归模式列表定义。尽管模式列表文件语法中不存在阻止用户创建这些定义的任何物体，但是当解析器检测到这些条件时，其将标记一个错误。注意到，存在一些与检测这些条件相关的成本。如果用户可假设确保输入空间不含共同递归定义，则其将能够切断检验。 

GlobalPList G1 

{ 

  LocalPList L2 

  { 

    LocalPList L3 

    { 

       #Error.L2 runs L3 which runs L2. 

       #This is a recursive reference to L2 

      PList L2； 

      PList G2； 

    } 

  } 

} 

GlobalPList G2 

{ 

  #Error.G1.L2 runs L3 which runs G2 which runs G1.L2. 

  #This is a mutually recursive reference to G1.L2. 

  PList G1.L2； 

 } 

模式和模式列表的句法描述允许在其上指定选项。通常，选项是供货商特定的。语法允许任何模式或模式列表具有大量特定选项，每个选项具有大量参数。其中描述了大多数供货商将承认的一些支持选项。 

在定义模式执行序列之后，描述模式树的动态(即，执行)。 

E2.模式 

图6说明根据本发明一实施例的模式编译器602和模式加载器604。在模式源文件606中可获得用户定义的模式内容，模式源文件606是一个纯文本文件。模式编译器负责将源文件编译成适用于加载到测试机硬件上的特定模块格式；此后一个文件将被称为模式对象文件。下文是通用属性： 

1.用户不可以创建模式对象；但是用户通常处理模式列表，其为其它模式列表和/或模式的集合。模式列表对象创建、拥有和保持其中所含有的模式对象，同时如果必要则使用户可存取这些模式对象。 

2.在测试计划中对模式进行唯一地命名，即测试计划中没有两个模式可以具有相同名称。一个模式的名称不同于包含该模式的文件的名称。模式文件名称是用于在模式列表文件表示一个模式的模式文件名称，而该模式的实际名称是在模式文件中定义。 

在本发明一实施例中，单一DUT(被测元件)通常可被连接到来自不同供货商的测试机模块。此具有整个模式编译-加载-执行链的含义。在此部分描述了主要的测试机模块。 

E3.模式编译 

因此，模式编译器602需要将特定现场配置作为目标(按照所使用的特定供货商数字模块)。对于此论述的其余部分，术语“模块”将被用于表示(例如)数字模块。为了允许来自不同供货商的模块608可以集成入该系统，较佳地采用下列程序： 

1.每个模块供货商将负责提供以可动态加载库或可独立执行形式的其自身的特定模块模式编译器610。此编译器库/可执行将提供(至少)熟知的compile()函数，其采用下列各项作为变元： 

a.一系列(一或多个)式源文件路径名； 

b.插针描述文件名； 

c.插口文件名； 

d.指定编译对象目的文件的可选目录路径名； 

e.字符串名称/值对的可选阵列，其允许(其他供货商可以忽略的)任何特定供货商参数的规约。 

2.模式源文件将容纳两个不同类型的部分： 

a.一个“共用”部分，其含有所有编译器都可存取(但不必使用)的信息；以及 

b.一或多个可选的特定供货商部分，每一个藉由唯一供货商代码来识别特定供货商编译器可使用的信息。 

3.供货商编译器不会直接创建模式对象文件。而是，测试机将提供藉由对象文件管理器(OFM)614管理的模式对象“元文件”612，其为模式编译器的部分。模式编译器可以位于充当系统控制器的计算机上，或者为脱机，例如位于系统控制器所连接的网络上。实际上，作为抽象术语的“模式对象文件”是此对象元文件。对象元文件将相同于模式源文件来命名，其中以对象文件扩展名置换源文件扩展名。OFM将提供应用程序规划接口(API)来读取和编写此文件。对象元文件将具有用于存储下列各项的条款： 

a.共用报头格式信息， 

b.特定模块报头格式信息，其包括识别相应模块和该模块模式数据的位置的信息。 

c.特定模块模式数据，其按照模块供货商所要求来组织，并且能够由这些模块供货商来解译。 

OFM API将允许模块供货商编译器将特定模块报头格式信息和数据编写入对象元文件。注意到，此对象元文件规划允许模式数据以每个模块为基础进行组织，即使在目标现场中两个或两个以上的模块相同的情况下也是这样。 

注意到，模式编译器可能需要附加的供货商提供的配置格式信息以便实现特定模块硬件加载信息的生成，其可利用有效数据通信，例如直接存储器存取(DMA)。 

E4.模块的模式加载 

每个模块供货商将负责在通用程序之后提供其自身的模式加载机制615。模块608的模式对象元文件612将特定模块数据存储在不同部分616。供货商实现将使用OFM API来从模式对象元文件存取相关特定模块部分。测试机框架将负责调用每个模块的加载方法，从而将特定模块数据加载到来自元文件适当部分的模块上。 

E5.模式文件 

有可能使每个编译器供货商为模式指定完全不同的纯文本格式，实际上，其在大多数情况下的确是必要的。但是，在基于循环的测试环境中跨模块的相干和相同语义对于各个向量是必要的，通常对于此测试环境，不但需要而且必需存在用于模式文件的共享、通用化语法。此共享语法是将为模式源文件中的“共用”部分指定的语法。实际上，对于大多数情况，可以预想“共用”部分是模式文件中将需要的唯一部分(除了报头格式信息之外)，且每个供货商编译器仅对该部分起作用。此部分提出用于所有编译器都能够解译的模式文件的规则。模式文件将如下被组织： 

file_contents    : 

                   version_info pattern_definitions 

versiot_info     : 

          Version version-identifier′；′ 

pattern_definitions    : 

          pattern_definition 

          pattern_definitions pattern_definition 

pattern_definition    : 

          main_header′{′moin_section′}′ 

          main_header′{′main_section vendor_sections′}′ 

          subr_header′{′ subr_section′}′ 

          subr_header′{′subr_section vendor_sections′}′ 

main_header    : 

             MainPattern identifier 

main_section    : 

             CommonSection′{′common_contents 

main_section_domains′}′ 

common_contents  : 

             timing_reference timing_map_reference 

timing_reference  : 

             Timing file-name′；′ 

timing_map_reference  : 

                TimingMap file-name′；′ 

main_section_domains  : 

                main_section_domains main_section_domain 

                main_section_domain 

main_section_domain    : 

                Domain domain_name′{′main_section_contents′}′ 

domain_name    : 

                identifer 

main_section_contents  : 

                main_section_contents main_section_content 

                main_section_content 

 main_section_content  : 

                label_spec main_pattern_spec 

                main_pattern_spec 

label_spec    : 

                label ′:′ 

label    : 

                identifier 

 main_pattern_spec  : 

                main_operation capture_mask_flag′{′ 

vectors_and_waveforms′}′ 

main_operation    :/*empty*/ 

                common_operation 

                jal_op 

                jsr_op 

                jsrc_op 

                jsc_op 

                exit_op 

 common_operation  : 

                idxi_op 

                idxin_op 

                jec_op 

                jech_op 

              jff_op 

              jffi_op 

              jni_op 

              ldin_op 

              nop_op 

              pause_op 

              sndc_op 

              sndt_op 

              stfi_op 

              sti_op 

              stps_op 

              wait_op 

/* 

* Instructions specific to the MAIN Patterns 

*/ 

jsr_op     : 

           JSR identifier 

jsrc_op    : 

           JSRC identifier 

jsc_op     : 

           JSC identifier 

jal_op     : 

           JAL identifier 

exit_op    : 

           EXIT 

/* 

* Instructions common to both MAIN and SUBR Patterns 

/* 

idxi_op    : 

           IDXI 24-bit number 

idxin_op   : 

           IDXIn index-register 

jec_op     : 

           JEC identifier 

jech_op        : 

               JECH identifier 

iff_op         : 

               JFF identifer 

iffi_op        : 

               JFFI identifier 

jni_op         : 

               JNI identifier 

ldin_op        : 

               LDIN index-register 

nop_op         : 

               NOP 

pause-op       : 

               PAUSE 

sndc_op        : 

               SNDC 8-bit number 

sndt_op        : 

               SNDT 8-bit number 

stfi_op        : 

               STFI 24-bit number 

sti_op         : 

               STI 24-bit number 

stps_op        : 

               STPS 

wait_op        : 

               WAIT 

capture_masl_flag   :/*empty*/ 

               capture_mask_flag CTV 

               capture_mask_flag MTV 

               capture_mask_flag MATCH 

  vectors_and_waveforms  :  /*empty*/ 

               vectors_and_waveforms vector 

               vectors_and_waveforms waveform 

vector          : 

                 vector_declaration′{′vector_data′}′ 

vector_declaration  : 

                Vector 

                V 

vector data       : 

                vector_datum 

                vector_data vector_datum 

vector_datum    : 

                pin_name′＝′vector-value′；′ 

                pin_name′＝′identifier′；′ 

waveform           : 

                waveform_declaration′{′waveform_data′}′ 

waveform_declaration  : 

                Waveform 

                W 

waveform_data    : 

                waveform_datum 

                waveform_data waveform_datum 

waveform_datum    : 

                waveform-table-pin-group-name′＝′identifier′；′ 

pin_name          : 

                identifier 

vendor_sections    : 

                vendor_sections vendor_section{} 

                vendor_section{} 

vendor_section    : 

                VendorSection′{′vendor_section_contents′}′ 

subr_header       : 

                SubrPattern 

subr_section      : 

                CommonSection′{′common_contents 

source_selection_table subr_section_domains′}′ 

               CommonSection′{′common_contents 

subr_section_domains′}′ 

subr_ection_domains: 

               subr_section_domains subr_section_domain 

               subr_section_domain 

sub_ection_domain: 

               Domain domain_name′{′subr_section_contents′}′ 

source_selection_table : 

               SourceSelectionTable′{′source_selector_definitions′}′ 

source_selector_definitions: 

                source_selector_definitioins source_selector_definition 

                  source_selector_definition 

source_selector_definition: 

                  SourceSelector source_selector_name′{′ 

source_mappings′}′ 

source_selector_name    : 

                identifier 

source_mappings     : 

                source_mappings source_mapping 

                source_mapping 

source_mapping     : 

                pin_name′＝′source′；′ 

source          : 

                 MAIN 

           INVERT_MAIN 

           SUBR 

           INVERT_SUBR 

subr_section_contents : 

                 subr_section_contents subr_section_content 

                subr_section_content 

subr_section_content : 

                 label_spec subr_pattern_spec 

                 subr_pattern_spec 

    subr_pattern_spec    : 

                    subr_operation capture_mask_flag′{′ 

    vectors_and_waveforms′}′ 

    subr_operation    :/*empty*/ 

                    common_operation 

                    rtn_op 

                    stss_op 

    /*     

    *Instructions specific to the SUBR Patterns 

    */ 

    rtn_op          : 

                    RTN   

    stss_op         : 

                    STSS identifier 

下文是对上文所使用的未定义非终结符的描述： 

1.version-identifier：来自集合[0-9.]的一或多个字符的序列，其中首字符必须是数字。 

2.identifier：来自集合[a-zA-Z_0-9]的一或多个字符的序列。其中首字符必须是来自集合[a-zA-Z-]。 

3.vendor-section-contents：仅对特定供货商编译器有意义的任意文本。 

4.file-name：有效的Windows文件名(如果文件名中包含任何空格，则必须被封入双引号。)注意到，此必须是简单文件名，即，其不应该具有目录组件。 

5.waveform-table-pin-group-name：来自集合[a-zA-Z_0-9]的一或多个字符的序列，其中首字符必须是来自集合[a-zA-Z]。此变量在其它地方被声明并且保持该组插针所共用的波形表的名称。 

6.24-bit number：最大高达16777215的有效十进制数。 

7.8-bit number：最大高达256的有效十进制数。 

8.index-register：有效十进制数。在模块的一个实施例中，此可具有值[1-8]。 

9.vector：此类似于STIL中的向量语句。注意到，此表示信号名称和信号组名称，使得编译器必须可以存取插针描述文件。 

10.waveform-time-reference：来自集合[a-2A-Z_0-9]的一或多个字符的序列，其中首字符必须是来自集合[a-zA-Z]。 

模式文件将支持注释，这些注释必须被模式文件编译器忽略。注释将以′#′字符开头，并且延伸到该行结束。 

关于模式文件的报头和“共用”部分的构造，必须注意下列各点： 

1.模式名称项指定将与模式文件所包含的数据的模式对象相关的名称。此可转入相应模式对象元文件中的报头。 

2.waveforrm-time-reference(波形时间参考)是特定waveform-and-timing(波形和计时)定义的名称，其将在模式文件的外部于计时文件中被定义。模式文件中waveform-time-reference的规约将约束所有随后向量的特定名称(对于波形和计时)，直到遇到另一waveform-time-reference。 

3.子程序调用的操作码(例如JSK.和JSRC)是一个字符串，其应该是先前在相同模式文件中遇到的特定模式标签(pattern-spec label)，或者是外部定义的子程序模式中的特定模式标签。此操作码将最终被解析以用于加载/处理子程序的目的。要求在系统.之间子程序调用操作码的标签是唯一的。 

注意到，waveform-time-reference名称可以是句法上正确的任何名称，因为特定硬件含义，waveform-time-reference名称，可能需要局限于先前已知的、定义明确的集合(为了附加可读取性，其可被用户可选的映射到用户选择的名称，存在于可选文件中映射)。 

还注意到，模式和waveform-time-reference源文件应该向连接到物理测试机通道的所有DUT通道提供初始配置数据。如果为任何DUT通道省略随后数据，则模式编译器将“填充”模式数据以保持从初始等级的输出。 

模式文件范例 

主模式源文件的简单范例将有助于说明该用法。 

# 

#Filenarne:good1.pat 

# 

Version 1.0； 

#---------------------------------------------------------- 

#Main Pattern definition: 

#---------------------------------------------------------- 

MainPattern good1 

{ 

  CommonSection 

  { 

   MacroDef    defaufaultDataVal    (XXXXXXXX) 

   MacroDef    nopInstr        (NOP) 

   MacroDef    label1          (Label1:) 

   MacroDef    jniInst         (JNI) 

   #---------------------------------------------------------- 

   #Timing Specifications 

   #---------------------------------------------------------- 

     Timing″productionTiming.tim″； 

     TimingMap″productionTimingOpenSTARMap.tmap″； 

   #---------------------------------------------------------- 

   #  Default Domain Cycles 

   #---------------------------------------------------------- 

   Domain default 

   { 

    #---------------------------------------------------------- 

    #label:instruction{Vector/Waveform Data} 

    #---------------------------------------------------------- 

         NOP    {V{DATA＝$defaultDataVal；CLK＝1；}W 

 {DATA＝wfs1；CLK＝wfs1；}} 

         JAL myAPG  {V{DATA＝00000000；}} 

         JSC mySCAN  {V{DATA＝10101010；}} 

         JSRC mySubroutine{V{DATA＝01010101；}} 

         JSR myAPG  {V{DATA＝00110011；}} 

         STI  100{} 

  labZero:NOP    {V{DATA＝00000011；}} 

         JNI labZero  {V{DATA＝11111100；}} 

         IDXI 3000  {V{DATA＝10101010；}} 

         IDXIn 3    {V{DATA＝01010101；}} 

  $label1 NOP    {V{DATA＝$defaultDataVal；}} 

          IDXI 2000{V{DATA＝10101010；}} 

          NOP     {} 

          EXIT    {V{DATA＝LLHHLLHH；}} 

  } 

    } 

 } 

下文将描述说明子程序模式源文件的另一范例。 

    #---------------------------------------------------------- 

    #Subroutine Pattern mySubrPat1 definition: 

    #---------------------------------------------------------- 

    SubrPattern mySubrPat1 

    { 

     CommonSection 

     { 

      #---------------------------------------------------------- 

      #Timing Specifications 

      #---------------------------------------------------------- 

Timing ″productionTiming.tim″； 

TimingMap ″productionTimingOpenSTARMap.tmap″； 

#---------------------------------------------------------- 

#  Source Selection Specifications 

#---------------------------------------------------------- 

  SourceSelectionTable 

  { 

 SourceSelector SrcSelDef 

   { 

       DATA＝SUBR； CLK＝SUBR； DATA＝SUBR； 

     } 

     SourceSelector SrcSelOne 

     { 

       DATA＝MAIN； CLK＝MAIN； 

     } 

  } 

  #---------------------------------------------------------- 

  # Default Domain Cycles 

  #---------------------------------------------------------- 

  Domain default 

  { 

  #---------------------------------------------------------- 

  #label:  instruction  { Vector and Waveform Data setups } 

  #---------------------------------------------------------- 

       STI   100 { Vector { DATA＝00000000； } } 

       IDXI  3000 {Vector {DATA＝00001111； } } 

       IDXIn 3   { Vector { DATA＝00110011； } } 

$label1 NOP     { Vector { DATA＝LLHHLLHH； } } 

     NOP    { Vector { DATA＝LLXXXXXX； } } 

     NOP    { Vector { DATA＝LLHHXXXX； } } 

     JNI Label1  { Vector { DATA＝LIHHLLHH； } } 

     STSS SrcSelOne { Vector { DATA＝LHLHLHLH； } } 

        RTN    {Vector{DATA＝LLXXXXXX；}} 

      } 

    } 

  } 

来自模式源文件中主报头和共用部分的摘要信息被存储在对象元文件的主报头中。摘要包含快速提取通常所需的信息以便辅助地址的预加载解析，或辅助数据记录。由于共用部分的语义对于所有编译器完全相同，因此编译器能够提供相同摘要格式信息，并且编写元文件的第一编译器将存储此格式信息。下文是将要被存储的信息： 

1.模式源文件名。 

2.源文件中所声明的模式类型。 

3.来自源文件的版本信息。 

4.模式源文件共用部分所使用的所有波形和计时名称的列表。 

5.所有子程序参考到模式源文件共用部分向量地址的映射(相对)。 

6.所有标签参考到模式源文件共用部分向量地址的映射(相对)。 

7.通用簿记格式信息：向量计数、指令计数等等。 

开放式架构测试系统要求模式和模式列表文件两者具有显式和不同的扩展名。对于模式文件，此应用于纯文本源和编译对象文件两者。用户可将此看作一个便利以快速视觉识别目录列表中的文件类型，等等，以及以扩展名为基础产生关联性。模式列表文件解析器将希望文件名具有这些扩展名： 

纯文本模式源文件：.pat 

编译模式对象元文件：.pobj 

模式列表文件：.plst 

用户可藉由测试机环境变量或设置选项来覆写这些默认值。 

测试机将需要下列“环境”变量的定义，这些“环境”变量用于下列各项中所描述的至少一个环境配置文件的文件搜索路径： 

Tester_PATLIST_PATH：用于模式列表文件。 

Tester_PATSRC_PATH：用于模式源文件(可选)。 

Tester_PATOBJ_PATH：用于模式对象元文件。 

注意到，如果没有定义可选环境/设置变量Tester_PATSRC_JPATH，则假设其相同于Tester_PATOBJ_PATH。通常，不定义Tester_PATSRC_PATH比以与Tester PATOBJ PATH相同的值进行对其进行定义更为有效。 

E6.软件表示 

用户不创建模式对象；而是，用户通常以模式列表对象对其进行处理，模式列表对象为其它模式列表和/或模式的集合。模式列表对象创建、拥有和保持其中所含有的模式对象，同时使用户可对其进行存取。用户测试程序中的模式列表对象与磁盘上的模式列表文件相关。模式列表的定义为模 式列表提供显式名称，并且藉由文件名关联性来识别模式的有序列表和/或其它模式列表。此部分描述模式列表和模式的软件表示，作为序言以便理解其如何在测试机框架中被操作。 

模式列表关联性 

测试系统(并且，扩展到其中的测试计划)中的单一测试现场可与多个最高级模式列表相关联。但是，在任何给定时间，仅存在单一的测试计划执行文本。由于最高级模式列表定义其所(分级地)表示的模式的执行序列，因此有效执行文本使对应于当前选择的最高级模式列表的执行文本。注意到，此非意味着每次只能将包含在单一模式列表中的模式载入硬件；而是，需要载入硬件以产生可行执行序列的模式集合必须总是所有当前载入模式的子集。 

模式树 

直观地，认识到表示最高级模式列表的一种方式是藉由一些类型的数型数据结构。图7说明本发明的一个有序模式树的实施例，假设模式列表A是最高级模式列表。 

模式树信息内容 

将在模式树的每个节点存储下列信息： 

1.与该节点相关的实体(模式列表或模式)的名称。 

2.定义源的类型。对于叶(模式节点)，此总是模式文件；对于中间(模式列表)节点，此将为“最高级文件”(用于最高级模式列表定义)或“嵌入文件中”(对于嵌套模式列表定义)。 

3.与该节点相关的磁盘上的最后一次修改时标。 

下列附加格式信息仅存储在中间(模式列表)节点中： 

1.设定在由该节点所表示的模式列表对象上的执行选项(如果存在)——即，其对象选项。 

2.设定在由该节点所表示的模式列表定义内的每个子段引用上的执行选项(如果存在)——即，其每个子段的引用选项。 

因此，从根目录到中间节点的唯一路径上出现的节点的集合，以及其中出现这些节点的序列，含有确定由该节点所表示的组合的、有效的执行选项所需的所有信息。模式的执行选项藉由其直接母本的有效执行选项结合其直接母本可能具有的用于其的引用选项来确定。 

此处应注意，尽管模式列表解析器处于创建模式树的过程中，但是特定执行选项可能要求只是作为字符串的值的初始存储，因为其使用的文本可能随后才会被解析。此选项的一个范例是“掩码(mask)”选项，其指定插针掩码信息；模式列表不与插口信息相关联，且因而，插针掩码选项(插针和组名称)作为字符串而被存储，以便在加载前被解析。 

下列附加格式信息将仅存储在叶(模式)节点中： 

1.对该模式所调用的子程序的所有(可能过渡性)参考，包括外部和内部两者，组织成一个执行数。 

当然，所有模式节点可附加地存取——和可能选择来高速缓存——对 象元文件共用报头中可获得的所有模式文件摘要信息。 

处理模式列表修改 

对模式列表内容的改变概念上会影响对该模式列表的所有声明。将使用下列规则(其适当地施加到模式对象以及模式列表对象)来管理这写改变： 

1.对磁盘上模式列表文件内容的改变将藉由测试系统仅在正于该模式列表上(或在引用该模式列表的任何其它模式列表上)执行的load()命令上传播。换句话说，软件中的模式列表层级总会反映当前加载在硬件上的模式列表层级。 

2.用户能够设定一个模式，该模式将消除在加载时间期间进行的检测以使模式列表与其磁盘文件源同步；此将实现生产模式的更快/更安全的运行。 

模式树导航 

与测试现场相关的最高级模式列表(并且扩展到该现场的测试计划)具有公共(全局)范围。系统提供API以便导航表示最高级模式列表的模式树，从而用户能够存取个别节点和子树。 

E7.模式列表动态特性 

上文描述了模式列表的静态规则。下文将展现对模式列表动态(执行)规则的描述。 

模式树对通用模式管理具有关键作用。例如，模式加载序列的起点是对当前与该现场或测试计划相关的模式树上load()方法的调用。但是，模式树不会孤立地运行。将使用完全初始化模式树来创建下列两个框架对象： 

1.最高级模式列表定义该模式的模式执行序列。其描述如何从对应于该最高级模式列表的模式树产生这种执行序列。例如，对应于图7中所示的模式树A的模式执行序列是{q，s，t，q，r，q，u，u，v}。模式执行序列概念上是一个有序列表，其反映由模式树所描述的执行序列。框架建立并且保持模式执行序列中模式树节点和相应入口之间的任何必要的导航链接。 

2.模式集合(Pattern Set)，其仅为模式树中所有唯一模式(包括子程序)的列表。因此，此为将用于确定应加载到硬件上的个别模式的列表。框架建立并且保持该模式集合中的模式树节点和相应入口之间的任何必要的导航链接。图7中模式树的模式集合是(q，s，t，r，u，v)(假设模式列表A中没有一个模式含有任何子程序调用)： 

注意到，模式执行序列和模式集合两者可能总是从模式树产生；但是，只要是可行的，在初始构造之后对其进行高速缓存总是有意义的。 

模式列表执行选项 

如上文所述，每个模式列表声明(在其定义之前)或模式列表模式引用入口可后接大量执行选项。模式列表执行选项修改模式列表的运行时间执行。为了实现以后的扩展，模式编译器的模式列表文件解析器仅将这些选项的名称(及可选值)作为字符串来处理，以便藉由适当的特定版本来处理。测试机规定一组选项及其解释，如下文所述。但是，供货商可扩展 该组选项。为了实现对选项语法的解析时间确认，模式列表文件解析器将读取特定版本的信息文件。这种信息文件还和用于指定一个特定版本是否完全支持执行选项的规约。 

对于支持一组执行选项的版本，下列通用规则将支配其使用。为了理解这些规则，将分级的模式列表/模式集合可视化成一个有序树是有用的。 

1.在模式列表定义(即，在文件中的“local-pattern-list-declaration、global-pattern-list-declaration”产生)上设定的固有选项实际上是用户测试程序中相应模式列表对象上的直接选项设定。因此，其应用到对该模式列表对象的所有引用，并且称为对象选项。 

2.在对模式列表/模式(即，在文件中的“pattern-entry(模式入口)”和“pattern-list-entry(模式列表入口)”)上设定的引用选项将选项的范围限制到层级中的特定路径——从树的根目录通向所述引用的路径(以模式列表/模式的声明顺序建立)。因此，这些是对特定对象引用(而非对对象本身)的选项，并且称为引用选项。 

3.对集合层级中任何列表/模式的有效选项设定(以模式列表/模式的声明顺序建立)是沿着从树的根目录到该列表/模式路径所遇到的对象和引用选项的组合。特定组合机制(例如，集合并(set union)、集合交集(setintersection)或任何其它冲突解决算法)是选项本身的性质。 

注意到，上述规则的结果——和不存在在模式文件中的模式定义上设定执行选项的程序的事实——是不存在可设定施加到对一个模式所有引用的选项的直接规则。实现此结果的机制是使用单一模式模式列表。 

测试机指定一个特定组的模式列表执行选项，其修改测试机的丛发行为，并且修改测试机的执行序列。 

当将模式列表的执行序列提交给硬件时，硬件产生一个丛发。丛发是硬件直接对模式序列的执行，不会涉及任何软件。丛发中断(BurstDiscontinuity)是执行序列中的一个位置，在此位置一个先前丛发终止且一个新的丛发开始。 

模式管理软件的一个目标是向硬件提供其产生丛发所需的执行序列。藉由默认，模式树产生一个执行序列，如果将其提交给硬件则会导致单一丛发。但是。可藉由对模式列表上选项的使用来修改此行为。因此，选项结果的使用能够导致丛发中断。 

此外，用户有时会需要在每个模式或每个丛发之前运行一个序言或后记模式。此修改了待提交给硬件的执行序列。 

在创建或修改模式执行序列对象期间，框架使必须确定且(如需要)报告的所有信息插入从指定的执行选项与模式树所体现的特定执行序列的组合所得的模式丛发。在此同时，可能需要调查系统中模块的硬件性能。例如，一个硬件执行范例允许四个用于插针掩码的存储配置，其中两个(0和3)用于默认屏蔽(支持掩码Tliis向量，MTV)和未屏蔽的运行。因此，允许用户具有两个不同的全程符插针掩码配置，而不会中断丛发模式。 

注意到，如果模块供货商不支持硬件中的模式列表执行范例，则供货 商对模式执行序列的处理将导致对执行序列中所有模式的个别执行。在Site-Compatible和Site-Heterogeneous系统两者中，现场的丛发能力将受到“最小公分母”的限制。测试机提供特定默认组的选项，并且下文描述了其参数。藉由下列陈述指定每个选项： 

其为固有(即，与具有全程符或全程符关键字的定义相关)还是引用的(即，与具有Pat或PList关键字的引用相关)。固有选项应用在定义点和每个引用处，但是引用选项仅应用在与其相关的引用之处。 

此外，如果假设将选项递归地应用于所有静态(句法上)或动态(语义上藉由参考)嵌套的模式或模式列表，则称选项是藉由子段继承。 

下文是选项的列表。每个适应供货商将特定地解释这些选项。 

1.Mask<pin/pin group> 

当应用于GlobalPList，LocalPList时是固有的， 

当应用于PList，Pat时是引用的。 

由子段继承。 

此模式列表总是具有由所指示的禁用插针或插针组表示的插针的比较电路。有时，可能从丛发中断产生硬件限制。 

2.BurstOff 

当应用于GlobalPList，LocalPList时是固有的， 

当应用于PList，Pat时是引用的。 

不被子段继承。 

此模式列表将总是以非丛发模式执行。此选项非藉由子段继承，但是BurstOffDeep选项(下文)藉由子段继承。 

3.BurstOffDeep 

当应用于GlobalPList，LocalPList时是固有的， 

当应用于PList，Pat时是引用的。 

由子段继承。 

此模式列表将总是以非丛发模式执行。此选项藉由子段继承，但是BurstOff选项(上文)非藉由子段继承。注意到，BurstOffDeep选项不会藉由子段切断。 

4.PreBurst<pattern> 

当应用于GlobalPList，LocalPList时是固有的， 

仅由不具有指定丛发选项的子段节点继承。 

所指示的模式将被放在此模式列表内所有丛发的前面。PreBurst模式刚好发生在由于此模式列表节点而开始的每个丛发之前。当已经处于一个具有相同模式的PreBurst选项中时，则不应用该选项。 

5.PostBurst<pattern> 

当应用于GlobalPList，LocalPList时是固有的， 

仅由不具有指定丛发选项的子段节点继承。 

所指示的模式将被放在此模式列表内所有丛发之后。PostBurst模式刚好发生在由于此模式列表节点而开始的每个丛发之后。当已经处于一个具 有相同模式的PostBurst丛发选项中时，不应用此选项。 

6.PrePattern<pattern> 

当应用于GlobalPList，LocalPList时是固有的， 

不被子段继承。 

所指示的模式被放在此模式列表内有所模式之前。 

7.PostPattern<pattern> 

当应用于GlobalPList，LocalPList时是固有的， 

不被子段继承。 

所指示的模式将被放在此模式列表内所有模式之后。 

8.Alpg<alpg object name> 

当应用于GlobalPList，LocalPList时是固有的。 

不被子段继承。 

所命名的ALPG对象存储相关信息，例如慢速APG记录设定、读取等待时间、直接数据记录、地址扰频、数据倒置、数据发生器等等。 

9.StartPattern<pattern> 

当应用于GlobalPList，LocalPList时是固有的， 

不被子段继承。 

该模式列表将在其执行序列中首次出现StartPattern时开始执行。 

10.StopPattern<pattern> 

当应用于GlobalPList，LocalPList时是固有的， 

不被子段继承。 

该模式列表将在其执行序列中首次出现StopPatter时停止执行。 

11.StartAddr<vector offset or label> 

当应用于GlobalPList，LocalPList时是固有的， 

不被子段继承。 

此必须伴随StartPattern选项。模式列表将在其执行序列中首次出现StartPattern时在StartAddr处开始执行。 

12.StopAddr<vector offset or label> 

当应用于GlobalPList，LocalPList时是固有的， 

不被子段继承。 

此必须伴随StopPattern选项。该模式列表将在其执行序列中首次出现StopPattern停止执行。 

13.EnableCompare_StartPattern<pattern> 

当应用于GlobalPList，LocalPList时是固有的， 

不被子段继承。 

模式比较将在首次出现所指示的模式时开始。 

14.EnableCompare_StartAddr，EnableCompare_StartCycle 

当应用于GlobalPList，LocalPList时是固有的， 

不被子段继承。 

此必须伴随EnabelCompare_StartPattern。指示其中将开始模式比较的模式内的地址或循环。 

15.EnableCompare_StopPattern<pattern> 

当应用于GlobalPList，LocalPList时是固有的， 

不被子段继承。 

模式比较将在首次出现所指示的模式时结束。 

16.EnableCompare_StopAddr，EnableCompare_StopCycle 

当应用于GlobalPList，LocalPList时是固有的， 

不被子段继承。 

此必须伴随EnableCompare_StopPattern。指示其中将结束模式比较的模式模式内的地址或循环。 

17.Skip(跳转) 

当应用于PList，Pat时是引用的。 

不被子段继承。 

导致模式或由模式列表所支配的整个子序列发生跳转。此还将导致此模式列表子树根目录处的所有选项发生跳转。如同此模式子树不存在以用于执行目的。 

模式列表丛发控制 

如前述，当将模式列表的执行序列提交给硬件时，该硬件产生模式序列的丛发，而不会涉及到任何软件。丛发中断是执行序列中的一个位置，在该位置终止一个先前丛发而开始一个新的丛发。PreBurst、PostBurst、BurstOff和BurstOffDeep选项控制发生丛发中断的位置，如上文选项列表中所描述。PreBurst和PostBurst选项确定遵循下文所描述的特定附加规则的丛发中断： 

1.当母列表(parent list)具有PreBurst和PostBurst丛发选项而嵌套列表(nested list)具有相同相应选项时，不存在丛发中断，并且不会应用嵌套列表的PreBurst和PostBurst选项。仅将单一丛发应用于母列表的PreBurst和PostBurst。 

2.注意到，当嵌套列表不具有丛发选项时，其等效于具有与这些选项所描述的母列表相同的PreBurst和PostBurst选项。因此，不具有丛发选项的嵌套列表不会导致丛发中断。 

3.如果不应用上文的规则1并且存在从母列表开始到嵌套列表开始的模式执行序列的基值(contribution)，则在嵌套列表的开始处将存在一个丛发中断。在这种情况下，母列表的PreBurst和PostBurst将应用于母列表模式执行序列的此基值。嵌套列表的PreBurst和PostBurst应用于嵌套列表。 

4.如果不应用上文的规则1并且存在从嵌套列表末端到母列表末端的模式执行序列的基值，则在嵌套列表的末端将存在一个丛发中断。在这种情况下，母列表的PreBurst和PostBurst将应用于母列表模式执行序列的此基值。嵌套列表的PreBurst和PostBurst将应用于嵌套列表。 

5.如果不应用规则1并且不存在来自母列表而非嵌套列表的模式执行序列的基值，则不应用母列表的PreBurst和PostBurst。仅存在应用嵌套列表的PreBurst和PostBurst的单一丛发。 

下文是说明选项对执行序列的影响的一些范例。为了简洁，假设在单一文件中指定所有模式列表。 

例1：  BurstOff的使用 

此范例说明BurstOff和PreBurst。特别强调地是，BurstOff导致模式以一个模式长的丛发单独运行。因而，仍然应用PreBurst选项。输入模式列表如下： 

Global A [BurstOff][PreBurst pat_z] 

{ 

   Pat  q； 

   PList B； 

   Pat  r； 

   Pat  s；     

   Global C 

   { 

     Pat  t； 

     PList D； 

   }； 

   PList D； 

   PList E； 

}； 

Global B 

{     

   Pat a； 

   Pat b； 

}； 

Global D [BurstOff] 

{ 

   Patc； 

   Patd； 

}； 

GlobalE 

{ 

   Pat e； 

}； 

可在图8中表示以A为根目录的树。 

下文是用于此模式的执行序列。|字符指示丛发中断。此模式列表以10个丛发执行，第一个具有模式z和q，而最后一个具有模式e： 

zq|ab|zr|zs|t|c|d|c|d|e 

注意关于此执行序列的下列各项： 

1.由于A上的BurstOff选项不被B继承，因此B中的模式a和b作为一个丛发来运作。 

2.由于A上的BurstOff选项不被B继承，因此藉由B产生的丛发中的a和b不会放在z之后。 

3.仅对于由于直接a(即，模式q、r和s)而被执行的模式才会发生以z为前缀。由于A具有A具有BurstOff选项，单独地执行这些模式，如同在仅有一个模式长的丛发中一样。BurstOff要求模式在一个模式长的丛发中单独地运行。因而，仍应用PreBurst和PostBurst选项。 

4.模式列表D具有一个固有BurstOff选项，其导致其子段c和d被单独执行。其不继承来自A的PreBurst z。 

范例2：BurstOffDeep的使用 

此范例说明BurstOffDeep选项。BurstOffDeep在模式列表定义期间影响嵌套定义和引用的列表。但是，PreBurst和PostBurst选项不被嵌套和引用的列表继承。该范例使用相同于范例1中的模式A、B、C、D、E，但是选项不同： 

5.定义A的选项，[BurstOffDeep]，[PreBurst z]，[PostBurst y]。 

6.任何其它节点不具有其它选项。 

执行序列如下。如前述：|字符指示丛发中断： 

zqy|a|b|zry|zsy|t|c|d|c|d|e。 

关于此执行序列应注意下列各项： 

1.PreBurst和PostBurst不被B、C、D、E继承。 

2.BurstOffDeep被B、C、D和E继承。 

范例3：PreBurst和PostBurst抑制 

现在假设考虑到范例1的模式列表树，其中选项为： 

1.定义A的选项：[PreBurst x][PostBurst y] 

2.定义C的选项{PreBurst x][PostBurst z] 

3.不存在任何其它节点上的其它选项。 

执行序列将为： 

x q a b r s t c d c d e y 

″t c d″子序列不是″x t c d z″的原因如下： 

1.第一个x被禁止，因为其等价于与当前有效丛发相关的预丛发选项x。 

2.最后一个z被禁止，因为PostBurst z未继承给D，并且不存在从z可附加的C生成的模式。 

范例4：Skip(跳转)的使用 

此范例说明Skip(跳转)选项对嵌套定义和所引用列表的影响。该范例使用与范例1中相同的模式A、B、C、D、E，但是选项不同： 

1.定义A的选项：[跳转]，[PreBurst z]，[PostBurst y] 

2.引用r的选项：[跳转] 

3.定义C的选项：[跳转] 

该执行序列是一个无中断的单一丛发，如下： 

z q a b s c d e y 

关于此执行序列应注意下列各项： 

1.跳转r和C的节点。 

2.完全不存在丛发中断。 

范例5：掩码的使用 

此范例说明掩码选项对模式以及模式列表定义和引用的影响。该范例使用与范例1中相同的模式A、B、C、D、E，但是选项不同： 

1.定义A的选项：[mask pin1_pin2]，[PreBurst z] 

2.引用B的选项：[maskpin3] 

3.定义B的选项：[mask pin4] 

4.引用e的选项：[mask pin5] 

5.不存在任何节点上的其它选项。 

名称″pin1_pin2″指定一个屏蔽Pin1和Pin2的组。名称″pin3″、″pin4″和″pin5″分别指定屏蔽Pin3、Pin4和Pin5的组。下文提供执行序列，其中|指示丛发中断。每个模式下方的数字指示在模式执行期间被屏蔽的插针。 

z  q  a  b  z  r  z  s  t  c  d  c  d  |  e 

1  1  1  1  1  1  1  1  1  1  1  1  1     1 

2  2  2  2  2  2  2  2  2  2  2  2  2     2 

         3  3                             5 

         4  4 

关于此执行序列应注意下列各项： 

1.供货商的硬件在无丛发中断的情况下仅能容纳2个掩码块。直到执行e，两个掩码块是插针{1，2}和插针{1，2，3，4}。当模式e携带不同的掩码块插针{1，2，5}而到达时，硬件要求一个丛发中断。 

范例6：继承选项和引用的使用 

此范例说明：当引用定义时，不应用定义处的继承选项。考虑下列范例： 

    GlobalA 

    { 

       Global B[BurstOffDeep] 

       { 

       Global C 

       { 

       }； 

       }； 

    PListC； 

    }； 

    GlobalD 

    { 

       PListC； 

    }； 

C在其被定义时继承BurstOffDeep选项。但是，其并非固有选项，且因此在其所有两个引用点处不将其应用到C。 

范例7：具有嵌套列表的PreBurst和PostBurst 

考虑下列范例： 

GlobalPList A[PreBurst x][PostBurst y] 

{ 

  Pat p1； 

  LocalPList B[PreBurst x][PostBurst y] 

  { 

    Pat p2； 

  } 

         LocalPList C 

         { 

           Pat p3； 

          } 

          LocalPList D[PreBurst x][PostBurst z] 

          { 

            Pat p4； 

          } 

          LocalPList E[PreBurst w][PostBurst y] 

          { 

            Pat p5； 

          } 

           Pat p6； 

} 

执行序列是： 

x p1 p2 p3 y | x p4 z | w p5 y | x p6 y 

1.模式p2与p1具有相同的丛发，因为嵌套列表的PreBurst和PostBurst选项被指定为与母体相同。模式p3还处于相同丛发中，因为这些选项与母选项相同地被继承。这些选项在其余嵌套列表中具有至少一个不同成员，引起丛发中断的产生。 

计时(Timing) 

用户主要藉由使用模式文件定义测试设置从而与系统相互作用。计时文件用于描述这些模式的计时。此文件要求其它系统文件(例如，Pin、SpecSelector)以便解析基础定义。此外，用于解析计时定义中所使用的各个变量的Spec-Selector和Global定义被封入一个复合TestConditionGroup对象。而更高级别文件，例如测试计划文件，使用此TestConditionGroup实例。 

测试计划文件含有对TestConditionGroup对象的引用。模式源文件在TitningMap对象中引用WaveformSelector组件。计时对象本身引用插针对象。计时对象还可能可选地引用由一个SpecSelector对象所调变的变量。图9中说明了这些关系。 

模式列表中的模式对象指定WaveformSelector对象的名称使用一组模式字符。还应该注意，在该模式中指定了Tuning Map文件。如果此映射没有被改变，则不需要对模式进行编译。 

Version 1.0； 

MainPattern 

{ 

   CommonSection 

   { 

      Timing＝myGalxy.tim； 

      TimingMap＝myGalxyMap.tmap； 

      Domain default 

     { 

        NOP V{SIG＝1；CLK＝1；DATA＝L；}W{SIG＝wfs1； 

              FASTCLK＝wfs1；} 

        NOP  W{SIG＝wfs2；} 

          NOP  V{SIG＝L；} 

        NOP  V{SIG＝0；} 

     }     

   } 

 } 

TestConditionGroup文件对象引入计时对象以便使用并且引入TimingMap对象以便使用。每个测试使用TimingCondition实例，该范例获自该实例的TestConditionGroup对象。因此，支持相同组波形表格的多个计时对象可被存储在测试机框架中并且如果需要则可被交换。类似的，多个测试计划文件能够共享一个共用TestConditionGroup对象。 

测试计划描述文件的一个范例说明了下列计时对象的用法。 

Import patlist1.plist； 

Import tim1.tim； 

Import tim2.tim； 

Import tmap1.tmap； 

TestConditionGroup tim1 prod 

{ 

   SpecSet＝prodTmgSpec(min，max，typ) 

   { 

       period＝10ns，15ns，12ns； 

    } 

  Timings 

    { 

       Timing＝tim1； 

       TimingMap＝tmap1； 

    } 

  } 

  TestConditionGroup tim2_prod 

  { 

    SpecSet＝prodTmgSpec(min，max，typ) 

    { 

        period＝10ns，15ns，12ns； 

    } 

    Timings 

    { 

    Timing＝tim2； 

       TimingMap＝tmap1； 

    } 

 } 

 TestCondition tim1_prod_typ 

 { 

     TestConditionGroup＝tim1_prod； 

   Selector＝typ； 

 } 

 TestCondition tim2_prod_max 

 { 

     TestConditionGroup＝tim2_prod； 

   Selector＝max； 

 } 

Test FunctionalTest MyFunctionalTestSlow 

{ 

   PListParam＝patlist1； 

   TestConditionParam＝tim1_prod_typ； 

} 

Test FunctionalTest MyFunctionalTestFast 

{ 

   PListParam＝patList1； 

   TestConditionParam＝tim2_prod_max； 

} 

″tim1″和″tim2″是使用上文所定义的不同计时对象的测试计划内的两个测试。计时对象以每个插针为基础定义各种波形。计时文件和计时映射文件中所使用的插针需要在插针定义文件中被适当地定义。 

计时对象可使用SpedficationSet对象来定义波形对象中的值。尽管计时对象可包括用于各种属性的固定(hard-coded)值，但是用户通常使用变量来对各种属性进行赋值。而这些变量可能取决于SpedficationSet对象。下文说明了此用法的范例。 

Version 1.0； 

Timing basic_functional 

{ 

  Pin SIG 

  { 

    WaveformTable wfs1 

    { 

       {1{U@t_le；D@t_te D；Z@45ns；}} 

   }； 

}； 

  Pin CLK 

  { 

    WaveformTable wfs1 

    { 

       {0{U@20ns；D@40ns；}}； 

    }； 

  }； 

} 

定义边缘布置的变量U@t_le在其它地方被定义并且取决于一个规约集。如下文所示定义SpecSelector。 

SpecificationSet prodTmgSpec(min，max，typ) 

{ 

   t_le＝10ns，14ns，12ns； 

   t_te＝30ns，34ns，32ns； 

} 

下列范例中说明了藉由改变spec对所用计时的改变。 

TestCondition prodTmp_typ 

{ 

    TestConditionGroup＝prodTmgSpec； 

  specSelector＝typ； 

} 

TestConditionGroup prodTmp_max 

{ 

    TestConditionGroup＝prodTmgspec； 

   SpecSelector＝max； 

}； 

F2.映射到测试机的计时组件 

计时″typ″和″max″使用SpecSelector中的典型/最大规约。测试机模块的 两个组件直接涉及波形及其相关计时的生成。两个模块是模式生成器(PG)和讯框处理器(FP)。图10中展示了一个简化方块图，其说明藉由开放式架构测试系统架构中的讯框处理器进行的波形格式化和计时生成。下文给出了对波形生成的简要描述。 

模式生成器1002生成一个计时集，其被模块中的所有插针所共用。此计时集被称为全程计时集(GTS)。存在三个可建立模式生成器的模式。这些三个模式影响可用于描述GTS的二进制位的数量。此外，这些设定还影响用于选择库以及获取此向量(CTV)和屏蔽此向量(MTV)二进制位是否被设定的二进制位的数量。为了指示测试机获取此向量的结果，用户在模式文件中使用CTV标记。类似地，用户在模式中使用MTV标记来指示测试机屏蔽当前向量的结果。此在下文表格1中得以说明。模式生成器1002还负责波形字符(WFC)的生成。WFC在每个插针的基础上生成。测试机模块使用固定数量的位来描述WFC。 

表格1 

GTS位	库中的GTS	GTS库	CTV	MTV
					8位	256	4	否	否
7位	128	8	是	否
					6位	64	16	是	是

测试机模块为每个插针提供一个讯框处理器1004。每个讯框处理器含有一个计时集扰频器(TSS)1006，在此范例中其具有高达1024的总深度。TSS 1006可能被划分成大量库1008，取决于上文所描述并且在图10中说明的模式生成器的模式，其中使用了16个库，每个库具有64个入口。提供TSS从而允许为每个插针定义波形表格的能力中具有更多的灵活性。在″FP″模式中，TSS使用2个二进制位输出一个计时集。因此，TSS将为每个插针生成总共四个不同的物理计时集。这些计时集被称为局部计时集(LTS)。 

讯框处理器1004将LTS和WFC组合并且在波形存储器1012和计时存储器1014中建入指数1010。在″FP″模式中，将5-二进制位值分裂成LTS所生成的2个二进制位和WFC所生成的3个二进制位。因此，物理波形存储器和计时存储器的深度是每个插针32深(deep)，尽管可使用4个物理计时集的最大值。波形存储器含有形成波形的启用的计时边缘。从计时存储器获得启用边缘的计时值。因此，讯框处理器对波形进行格式化。 

映射方法 

该方法是以每个插针为基础将所有WaveforniTable块映射到测试机中 的LTS。如果测试机硬件支持4个LTS，则用户可定义最大4个WaveformTable块。每个WavefortnTable块可具有测试机数字模块的最大n个波形定义。 

Timing-Map文件提供提供在Timing-Map块中所定义的逻辑波形选择器到开放式架构测试系统中该模块的WaveformTable的映射。在这种情况下，测试机支持高达256个逻辑波形选择器。在开放式架构测试系统中，逻辑波形选择器直接映射到GTS。模式编译器依赖于Timing-Map和计时块两者从而能够编译模式文件。但是，如果计时块WaveformTable中的波形字符没有被改变或Timing-Map块中的WaveformSelector映射没有被改变，则不需要对模式进行重新编译。 

使用此映射方法的范例 

为了说明映射入测试机数字模块，作出下列假设：讯框处理器被设定成FP模式；且设定CTV和MTV二进制位使得GTS二进制位的总数量为6而计时库选择器二进制位的总数量为4。 

将计时块中所定义的每个WaveformTable映射到计时文件中的不同LTS。此是以每个插针为基础来完成。因此，将WaveformTable seq1映射到LTS1。在″SIG″插针的情况下，用完所有8个可能的波形入口。但是，″CLK″插针要求单一波形入口并且因此用完波形存储器(WFT)和波形计时存储器(WTM)中的单一行。 

图11中说明了″SIG″插针的最初2个物理波形的映射。由于此WaveformTable映射两个需要独立边缘配置的波形字符，因此以在波形存储器(WFT)1112和波形计时存储器(WTM)1114中定位两个入口而结束。波形的形状存储被存储在WFM中而计时细节被存储在WTM中。模块的一个范例共具有6个计时边缘T1、T2、T3、T4、T5和T6。这些直接映射到计时块边缘资源部分内的波形中所定义的事件E1、E2、...。如果在计时块中定义多于6个事件且此用于上述模块，则将导致错误。 

在图11的范例中，第一个波形字符″0″使用计时边缘T1来编程″ForceDown″或″D″事件，其时间10ns发生入该循环。计时边缘T2还用于在时间30ns生成″Force Down″或″D″事件。最后，将计时边缘T3用于在时间45ns生成″Force Off”或″Z″事件。 

第二个波形字符″1″使用计时边缘T1来编程″Force Up″或″U″事件，其在时间10ns发生入该循环。计时边缘T2还用于在时间30ns生成″ForceDown″或″D″时间。最后，将计时边缘T3用于在时间45ns生成″Force Off″或″Z″事件。 

以此方式，将WFC映射入讯框处理器的WFM存储器和WTM存储器。下文的表格2说明了用于插针″SIG″的LTS1的波形存储器WFM的最终设置。 

表格2 

Index	(WFC)	T1Set	T1ReSet	T2Set	T2ReSet	T2Drel	T2Dret	EXPH	EXPHZ	T3Set	T3ReSet	T3Drel	T3Dret	T4Drel	T4Dret	EDPL	EXPHZ
																		0	0		1		1								1
1	1	1			1								1
																		2	d		1	1									1
3	u	1			1								1
																		4	L															1
5	H							1
																		6	m															1
7	n							1

下文的表格3说明了用于插针″SIG″的LTS1的波形计时存储器WTM的最终设置。 

表格3 

Ixnde

()  W  F  C

T 1

T 2

E X P H

T 3

T 4

E X P L

0

0

10ns

30ns

45ns

1

1

10ns

30ns

45ns

2

d

12ns

32ns

42ns

3

u

12ns

32ns

42ns

4

L

17ns

5

H

17ns

6

m

15ns

7

n

15ns

″CLK″插针用完单一波形，且因此用于此插针的WFM和WFT极为简单。下文的表格4说明了用于″CLK″插针的LTS1的波形存储器WFM的最终设置。 

表格4 

Index

(WWFC)

T1Set

T1ReSet

T2Set

T2ReSet

T2Drel

T2Dret

EXPH

EXPHZ

T3Set

Tl3ReDre

T3Drel

T3Dret

T4Drel

T4Dret

EXPL

EXPHZ

0

1

1

1

1

2

3

4

5

6

7

下文的表格5中说明了LTS2的波形计时存储器WTM的最终设置。 

表格5 

Ixnde	()WFD	T1	T2	EXPH	T3	T4	EXPL
								0	1	20ns	40ns
1
								2
3
								4
5
								6
7

TimingMap块将WaveformSelector显式地映射到计时块的波形表格。对于测试机系统，此导致设定计时集扰频器(TSS)存储器。TSS基本上含有一个从GTS到保持该设定的LTS的映射。对于插针SIG的此范例的TSS设置将如下文的表格6所示。 

表格6 

GTS	LTS
		0(wfs1)	1
1(wfs2)	1
		2(wfs3)	2
3(wfs4)	1
		4(wfs5)	3
5(wfs6)	1
		.
N(wfs1)	1
		.
255

最后，在解析TSS和LTS设置映射之后，模式编译器可使用此信息藉由待使用的正确波形表格(LTS)和正确波形字符来编程该模式。因此，图11说明了仅考虑插针″SIG″的本示范性伪模式。注意到，此编译不依赖于计时块而是仅依赖于计时映射(Timing-Map)块。 

G.测试机运行 

此部分描述了测试机操作系统(TOS)的基本运行。此部分所考虑到的行 为是： 

系统初始化 

测试计划加载 

模式加载 

运行测试计划 

运行单个测试 

系统初始化 

为了在一个实施例中初始化系统，必须满足特定假设，且必须符合特定条件。下列子部分列举了这些特定假设和特定条件。 

先决条件 

相关系统软件组件的副本具有一个中央存储，其位置为系统控制器所知。此可位于系统控制器本身，或位于另一系统上，该另一系统具有网络安装式目录(或经由另一机制而被SYSC所知)——不管是何种机制，在系统可运行之前，系统控制器必须可利用所有软件。此软件包括： 

供货商硬件控制(即，模块软件)DLL， 

标准或用户测试类DLL，以及 

用户测试计划DLL 

在系统控制器上可获得系统模块配置文件。回忆可得，此文件允许用户指定测试机的物理配置，例如系统底盘中每个模块的物理位置和类型，以及模块软件DLL的名称。 

在系统控制器上可获得系统配置文件。回忆可得，此文件含有系统中现场控制器的列表，以及现场控制器主机名到开关矩阵(Switch Matrix)输入端口地址的映射。 

现场控制器具有一个称为现场配置管理器(SCM)运行的服务。此服务负责藉由称为“硬件发现(hardware discovery)”的进程来确定在每个插槽安装哪种硬件。其还负责参与藉由系统控制器执行的系统初始化进程。注意到，开关矩阵运行协议在一个实施例中指示单一现场控制器上的SCM，而开关矩阵输入端口连接地址1应该总是用于配置到模块的开关矩阵连接。回忆可得，此″专用″现场表示为SITEC-1。 

系统控制器负责向每个现场控制器的SCM提供其开关矩阵连接地址。 

每个现场控制器的SCM能够起动一个称作测试计划服务(TPS)的进程。每个现场控制器上的测试计划服务最终负责包含和执行用户测试计划(或在其中单一现场控制器对多个DUT运行测试的情况下为多个测试计划)。 

初始化阶段I：系统确认 

一旦满足上述假设和先决条件，则系统初始化首先藉由如下的系统确认步骤开始： 

1.系统控制器读取系统和模块配置文件以便初始化系统的用户指定视图。 

2.使用指定系统配置信息，系统控制器检验指定的现场控制器是活动的、可获取的并且准备就绪(即，具有SCM运行)。此检验步骤中的任何 错误将导致产生系统错误，并且导致初始化失败。 

3.系统控制器随后指示SITEC-1处的SCM服务配置开关矩阵以便存取所有硬件模块并且请求其执行硬件发现。 

4.SITEC-1处的SCM服务向所有可利用的模块插槽(已知硬件位置)轮询{vendor，hardware}元组并生成{vendor，hardware}元组到插槽的映射。总而言之，此轮询因此识别整个系统中所存在的整个组的{vendor，hardware，slot}结合。此轮询的结果被发送到系统控制器。 

5.系统控制器检验上述硬件发现步骤的结果是否匹配模块配置文件中的用户指定配置。此检验步骤中的任何错误将导致产生系统错误，并且导致初始化失败。 

6.系统控制器随后从熟知位置处的环境设置文件加载默认环境(例如，模块DLL、模式列表、模式、测试计划DLL、测试类DLL等的搜索路径)。 

7.系统控制器确保存在所有识别的模块软件。如果在系统控制器上不能获得一个识别的模块软件DLL，则从中央存储检索(如果可能)；否则，将发生系统错误且导致初始化失败。 

初始化阶段II：现场配置(可选) 

现场配置，或现场划分，涉及可用系统硬件模块到不同现场的软件级分配(即，用于服务多个DUT)。回忆可得，在插口文件中提供现场划分信息。 

测试机系统允许现场(再)划分作为测试计划加载(由于每个测试计划与一个特定插口相关联)的部分和作为独立用户可调用步骤来执行。在后一种情况下，用户藉由提供一个单独使用以划分系统的插口文件来启动现场划分。此在多DUT测试的情况下的系统初始化期间尤其有效，其中每个现场测试一个不同的DUT类型。但是，此步骤在初始化阶段是可选的，并且用户可选择不使其被执行，而是可选的以允许测试计划加载测试计划以便适当地划分系统。 

不管构件选择哪一种来实现现场划分(藉由独立调用或隐式地通过测试计划加载)，机制是相同的。下文描述了此机制。 

1.给定插口，系统控制器首先确定当前存在的系统划分是否与该插口兼容，或是否需要再划分。初始化期间的默认划分是其中所有可用模块都连接到SITEC-1的划分。只有需要再划分时才执行下列其余步骤。 

2.系统控制器相每个现场控制器SCM发送一个配置讯息以便藉由在新插口下为其启用的DUT现场的数量和识别码来对其自身进行重新配置。注意到，这是一个通用程序，并且处理其中现场控制器所控制的DUT现场的数量是1的情况。新的插口信息还被传送到该SCM。 

3.每个SCM停止运行TPS(如果存在的话)，并且开始新的TPS，以该新插口以及在新插口下为其启用的DUT现场的数量和识别码对其进行初始化。 

4.系统控制器确定哪个现场需要所需系统模块的哪一个子集。与此同时，其还为这些现场准备硬件插槽信息。对于每个现场，最终结果是插槽 对分配给该现场的模块DLL的列表。此特定现场列表将表示为现场模块DLL插槽列表(SITE-MDSL)。 

5.系统控制器向每个SCM提供适当SITE-MDSL以及必要的模块DLL。而每个SCM使新近启动的TPS可获得此信息。 

6.系统控制器随后请求SITEC-1配置开关矩阵以用于真确的现场到插槽连接，即，用于现场划分运行。 

7.现场1到n上的TPS加载在其ITE-MDSL中指定的DLL。这些DLL中的每一个具有一个名为initialize()的函数，其采用一系列插槽编号。TPS以该模块类型的适当插槽列表调用initialize()。此时的任何误操作将导致产生系统错误并且导致初始化失败。initialize()方法进行下列运作： 

a.基于标准接口IXXXModule创建具体类。例如，与数字模块相关的DLL将创建单一基于IpinModule的对象从而服务与其相关的每个插槽。 

b.基于接IResource创建具体类，模块中的每个″资源单元(resourceunit)″具有一个具体类。同样，对于数字模块，每个基于IpinModule的对象将为数字模块所占据的插槽集合中的所有插针创建基于ItesterPin的对象。 

8.现场1到n上的T PS随后在每个加载的模块DLL上调用getXXXModule()以便检索模块内容信息。 

9.对getXXXModule()的每个调用返回一个<VendorHWType>Module类对象作为IModule指示符(例如，AdvantestPinModule)。这种IModule指示符中的每一个被该TPS高速缓存，此使得框架/用户代码可利用这些IModule指示符。注意到，Imodule、Iresource等等的集合是持久的(至少对于TPS的使用期来说)。 

10.一旦完成上述步骤，则TPS开始在其分配(熟知)的端口上开始listen()。此向系统控制器发出TPS已“就绪”开始正常(即，现场划分)运行的信号。 

测试计划加载 

此部分描述将用户测试计划DLL加载到现场控制器(对于单一或多DUT测试)的步骤。 

一旦完成系统初始化(及可选的初始现场划分)，则可加载用户测试计划。如下进行用户测试计划在现场控制器上的加载： 

1.系统控制器首先将测试计划DLL加载入其自身的进程空间，向其询问相关的插口文件及其DUT类型标识符。此信息用于识别运行此测试计划的现场，以及由此识别将加载测试计划的现场控制器。 

2.系统控制器随后使用与测试计划相关的插口信息来启动上文概述的再划分进程。 

3.系统控制器提取来自测试计划DLL的测试计划所使用的测试类DLL的列表，并且一旦系统控制器证实TPS就绪以开始正常(即，现场划分)运行，则将测试类DLL并且最终将测试计划DLL本身发送到适当TPS。 

4.TPS调用LoadLibrary()以便将其加载入进程空间。其在DLL上调用 一个熟知的函数以便创建数量与其服务的现场(即，DUT)数量相等的TestPlan对象。 

5.TPS藉由必要的测试机框架对象来初始化TestPlan对象。在初始化期间，TPS将用于TestPlan对象所使用的测试类的适当DLL加载入进程空间，并且创建测试类实例。 

6.TPS设置到系统控制器的通信通道/从系统控制器到TestPlan对象的通信通道。 

7.系统控制器与TPS通信，并且为TestPlan对象建立其代理服务器。 

此推断出用户测试计划在现场控制器上的成功加载。 

运行测试计划 

根据预定流程逻辑(flow logic)执行测试计划中所有测试的方法如下： 

1.用户应用程序将Run TestPlan讯息发送到TPS。TPS向所有连接的应用程序发送一个ExecutingTestPlan讯息。TPS随后在测试计划上调用execute()。 

2.使用位于现场控制器上的多个线程(每个DUT使用一个线程)来执行以单一现场控制器进行的对多个DUT的测试。每个线程运行相同TestPlan对象的一个不同的、独立实例。因为，在此情况下可能跨DUT共享模块控制软件DLL，因此要求用于硬件通信的模块命令采用DUT标识符参数。 

3.TestPlan对象在其集合内的每个测试上循环执行(或者，命令其流程对象根据流程逻辑处理每个测试)，调用preExec()、execute()和postExec()。 

4.在执行每个测试时，向所有连接的应用程序发送回状态讯息。 

执行单一测试 

用户可能会希望执行测试计划中的单一测试而非所有测试。对于单一测试执行，方法如下： 

1.用户应用程序将RunTest讯息传输到TPS；该TPS向所有连接的应用程序发送一个ExecutingTest讯息。TPS随后在测试计划上调用executeTest()，指定测试运行。 

2.测试计划对象藉由在该测试对象上调用preExec()、execute()和PostExec()来执行指定的测试。 

3.在执行测试时，其将状态讯息发回所有连接的应用程序。 

尽管已经结合特定实施例描述了本发明，但是，熟悉本相关领域的人员应能理解到，这些已揭露的实施例的各种可能的修改及组合可能还是能使用的，然而其仍然是利用了如下的相同的基础结构及方法。本发明不受到上文说明性细节的限制，而是应根据权利要求书的范围来理解本发明。 

Claims (24)

1.一种以通用面向对象结构开发测试程序的方法，所述测试程序用于测试半导体测试系统中的IC，该方法包括：

以通用面向对象结构描述测试系统资源、测试系统配置和模块配置，用以开发测试半导体测试系统上IC的测试程序，其中描述测试系统资源、测试系统配置和模块配置包括：

指定一模块连接启用器的一输入端口；

指定一个运行主机操作系统的系统控制器，用于控制至少一个现场控制器；以及

指定一个现场控制器，用于控制至少一个测式模块，其中每个测试模块包括供货商提供的硬件组件和软件组件，用来向所述IC施加一个测试，其中软件组件之一的每个供货商专用软件模块包括了用于产生测试模式对象的特定模块编译器；

以通用面向对象结构描述测试序列，用以开发测试半导体测试系统上IC的测试程序；

以通用面向对象结构描述测试计划，用以开发测试半导体测试系统上IC的测试程序；

以通用面向对象结构描述测试条件，用以开发测试半导体测试系统上IC的测试程序；

以通用面向对象结构描述测试模式，用以开发测试半导体测试系统上IC的测试程序；

以通用面向对象结构描述测试模式的计时，用以开发测试半导体测试系统上IC的测试程序；以及

根据描述该测试系统资源、该测试系统配置、该模块配置、该测试序列、该测试计划、该测试条件、该测试模式及该测试模式的计时的该通用面向对象结构，编译该测试程序的计算机可执行码，其中该特定模块编译器编译一模式源文件成为加载至供货商硬件的一特定模块格式，

其中所述测试系统将所述现场控制器在所述输入端口耦接到模块连接启用器，且所述模块连接启用器将所述现场控制器耦接到至少一个测试模块。

2.根据权利要求1的以通用面向对象结构开发测试程序的方法，其中所述对测试系统资源的描述包括：

指定一资源类型，其中所述资源类型与向所述IC提供测试的至少一个测试模块相关联；

指定与所述资源类型相关联的一参数类型；以及

指定所述参数类型的一个参数。

3.根据权利要求1的以通用面向对象结构开发测试程序的方法，其中所述模块连接启用器是一个开关矩阵。

4.根据权利要求1的以通用面向对象结构开发测试程序的方法，其中对模块配置的描述包括：

指定一模块标识符以便指定一模块类型；

指定可执行码以控制由所述模块标识符指定模块类型的一测试模块，所述测试模块用于向所述IC施加一测试；以及

指定与所述测试模块相关联的一资源类型。

5.根据权利要求4的以通用面向对象结构开发测试程序的方法，该方法还包括：指定一插槽标识符以指定一模块连接启用器的一输出端口，其中所述测试系统将所述测试模块耦接至模块连接启用器的输出端口，并且所述模块连接启用器将所述测试模块耦接到相应的现场控制器。

6.根据权利要求5的以通用面向对象结构开发测试程序的方法，其中所述模块连接启用器是一个开关矩阵。

7.根据权利要求4的以通用面向对象结构开发测试程序的方法，其中所述可执行码是一个动态链接库。

8.根据权利要求4的以通用面向对象结构开发测试程序的方法，还包括指定一供货商标识符以识别测试模块的提供者。

9.根据权利要求4的以通用面向对象结构开发测试程序的方法，还包括指定与所述资源类型相关的可利用资源单元最大数量的一标识符。

10.根据权利要求4的以通用面向对象结构开发测试程序的方法，其中所述资源类型为数字测试机插针且与所述资源类型相关的资源单元为测试机通道。

11.根据权利要求4的以通用面向对象结构开发测试程序的方法，其中所述资源类型为模拟测试机插针且与所述资源类型相关的资源单元为测试机通道。

12.根据权利要求4的以通用面向对象结构开发测试程序的方法，其中所述资源类型为RF测试机插针且与所述资源类型相关的资源单元为测试机通道。

13.根据权利要求4的以通用面向对象结构开发测试程序的方法，其中所述资源类型为电源插针且与所述资源类型相关的资源单元为测试机通道。

14.根据权利要求4的以通用面向对象结构开发测试程序的方法，其中所述资源类型为数字化器插针且与所述资源类型相关的资源单元为测试机通道。

15.根据权利要求4的以通用面向对象结构开发测试程序的方法，其中所述资源类型为任意波形发生插针且与所述资源类型相关的资源单元为测试机通道。

16.根据权利要求4的以通用面向对象结构开发测试程序的方法，其中所述资源类型与资源单元相关，且该方法还包括指定与禁用的资源单元相关的一指示器。

17.根据权利要求16的以通用面向对象结构开发测试程序的方法，其中指示为禁用的资源单元表示所述测试模块的缺陷资源单元。

18.根据权利要求1的以通用面向对象结构开发测试程序的方法，其中对测试条件的描述包括：指定至少一测试条件组。

19.根据权利要求18的以通用面向对象结构开发测试程序的方法，其中对测试条件的描述还包括：

指定包括至少一个变量的至少一个规约集；以及

指定一选择器以便选择由一变量所绑定的表达式。

20.根据权利要求19的以通用面向对象结构开发测试程序的方法，其中所述测试条件组与用于至少一个规约集的选择器的关联定义一测试条件。

21.根据权利要求20的以通用面向对象结构开发测试程序的方法，其中所述测试条件是一个对象。

22.根据权利要求1的以通用面向对象结构开发测试程序的方法，其中对测试序列的描述包括指定：

执行一流程或测试的结果；

基于所述结果的动作；以及

基于所述结果至另一流程或测试的转换。

23.根据权利要求1的以通用面向对象结构开发测试程序的方法，其中该面向对象结构为C/C++结构。

24.一种测试IC的测试系统，该测试系统包括：

一个现场控制器，

多个测式模块，每个测试模块包括供货商专用的硬件组件和软件组件，软件组件包括了特定模块编译器，该特定模块编译器编译一模式源文件成为加载至供货商专用硬件的一特定模块格式，

一个模块连接启用器，把该现场控制器连接到每个测试模块，

该测试模块适用于执行一个测试程序，该测试程序是由下述步骤进行开发：

指定该模块连接启用器的一输入端口；

指定一个运行主机操作系统的系统控制器，用于控制该现场控制

器；以及

指定该现场控制器，用于控制至少一个测式模块，

以通用面向对象结构描述测试序列，用以开发测试半导体测试系统上IC的测试程序；

以通用面向对象结构描述测试计划，用以开发测试半导体测试系统上IC的测试程序；

以通用面向对象结构描述测试条件，用以开发测试半导体测试系统上IC的测试程序；

以通用面向对象结构描述测试模式，用以开发测试半导体测试系统上IC的测试程序；

以通用面向对象结构描述测试模式的计时，用以开发测试半导体测试系统上IC的测试程序；以及

根据描述该测试系统的资源、该测试系统的配置、该测试模块的配置、该测试序列、该测试计划、该测试条件、该测试模式及该测试模式的计时的该通用面向对象结构，编译该测试程序的计算机可执行码。

Images