JP3890079B1 - モジュール式試験システムにおける交換可能コンポーネントを制御するための方法及びシステム - Google Patents
モジュール式試験システムにおける交換可能コンポーネントを制御するための方法及びシステム Download PDFInfo
- Publication number
- JP3890079B1 JP3890079B1 JP2006519572A JP2006519572A JP3890079B1 JP 3890079 B1 JP3890079 B1 JP 3890079B1 JP 2006519572 A JP2006519572 A JP 2006519572A JP 2006519572 A JP2006519572 A JP 2006519572A JP 3890079 B1 JP3890079 B1 JP 3890079B1
- Authority
- JP
- Japan
- Prior art keywords
- module
- test
- vendor
- file
- resource
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
- G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
- G01R31/28—Testing of electronic circuits, e.g. by signal tracer
- G01R31/317—Testing of digital circuits
- G01R31/3181—Functional testing
- G01R31/319—Tester hardware, i.e. output processing circuits
- G01R31/31903—Tester hardware, i.e. output processing circuits tester configuration
- G01R31/31907—Modular tester, e.g. controlling and coordinating instruments in a bus based architecture
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
- G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
- G01R31/28—Testing of electronic circuits, e.g. by signal tracer
- G01R31/317—Testing of digital circuits
- G01R31/3181—Functional testing
- G01R31/3183—Generation of test inputs, e.g. test vectors, patterns or sequences
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
- G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
- G01R31/28—Testing of electronic circuits, e.g. by signal tracer
- G01R31/317—Testing of digital circuits
- G01R31/3181—Functional testing
- G01R31/3183—Generation of test inputs, e.g. test vectors, patterns or sequences
- G01R31/318307—Generation of test inputs, e.g. test vectors, patterns or sequences computer-aided, e.g. automatic test program generator [ATPG], program translations, test program debugging
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
- G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
- G01R31/28—Testing of electronic circuits, e.g. by signal tracer
- G01R31/317—Testing of digital circuits
- G01R31/3181—Functional testing
- G01R31/3183—Generation of test inputs, e.g. test vectors, patterns or sequences
- G01R31/318342—Generation of test inputs, e.g. test vectors, patterns or sequences by preliminary fault modelling, e.g. analysis, simulation
Landscapes
- Engineering & Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Tests Of Electronic Circuits (AREA)
- Test And Diagnosis Of Digital Computers (AREA)
- Testing Electric Properties And Detecting Electric Faults (AREA)
Abstract
Description
試験環境は、テスタをインストールし、それを1組の試験を実行するために準備するための必要な条件を指定する1組のファイルを含む。試験環境は、以下に記載されるもののためのファイルを含むことが好ましい。
1.テスタ資源定義:そのオープンアーキテクチャ試験システムにおいて利用することができるテスタ資源タイプ、及びそのような資源のためにサポートされるパラメータを指定するためのファイル。
2.テスタ構成:サイトコントローラ、サイト及び対応するマッピングを指定するためのファイル。
3.モジュール構成:各サイト内のハードウエアモジュールを指定するためのファイル。
4.ピン記述:信号ピン、電源のようなDUTピンを命名し、ピングループを記述するためのファイル。
5.ソケット:DUTピン‐テスタピンの割当てを指定するためのファイル。
6.ピンオプション:ピンのための特殊なオプション又はモードを指定するためのファイル。
7.パターンリスト:試験パターン及びそのシーケンスを指定するためのファイル。
8.パターン:試験ベクターを指定するためのファイル。
各ハードウエアモジュールは、試験システムによって用いるための1つ又は複数のタイプのハードウエア資源(略して資源)を提供する。テスタ資源定義は、利用可能な資源タイプのための1組の資源名、並びにそれぞれの特定の資源タイプに関連する1組のパラメータ名及びタイプを宣言するために用いられることが好ましい。たとえば、資源名dpinは、デジタルテスタピンを指すために用いられる。これらの資源は、VIL(入力低電圧用)、VIH(入力高電圧用)、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 pattern generation.
# It is a system specified range:
# PRE_WAIT_MIN <= actual <=
PRE_WAIT_MIN+delta
#
# POST_WAIT 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-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;
}
}
以下に与えられるのは、本発明の好ましい実施形態による資源定義ファイルのための構造である。
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.]からの1つ又は複数の文字を含む文字列。それはバージョン番号を表す。
2.resource-name:集合[a−zA−Z_0−9]からの1つ又は複数の文字を含む文字列であり、数字で始まらない。それはdpin又はdpsのような資源の名前を表す。
3.elemantary-type-name:集合[a−zA−Z_0−9]からの1つ又は複数の文字を含む文字列であり、数字で始まらない。それは、Voltage(cf.)のような基本タイプの名前を表す。
4.resource-param-name:集合[a−zA−Z_0−9]からの1つ又は複数の文字空なる文字列であり、数字で始まらない。それは、VILのような資源パラメータの名前を表す。
テスタ構成は、特定のシステム構成内のサイトコントローラ、及びサイトコントローラのスイッチマトリクス入力ポートへの接続を記載するために用いられることが好ましい1組の規則である。本発明の一実施形態のアーキテクチャでは、単一のサイトコントローラを単一のスイッチマトリクス入力ポートに接続することができる。したがって、この状況では、スイッチマトリクス接続は、システム内のサイトコントローラのための暗黙の識別子としての役割を果たす(他の構成も可能である)。以下は一般的なテスタ構成の一例である。
# 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;
}
以下に与えられるのは、本発明の一実施形態によるシステム構成ファイルのための構造である。
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.]からの1つ又は複数の文字を含む文字列。それはバージョン番号を表す。
2.octet:0〜255の負でない整数(10進表記)。
3.name:集合[a−zA−Z_0−9]からの1つ又は複数の文字を含む文字列であり、数字で始まらない。それは、ドメイン修飾されたホスト名内の名前部分を表す。
4.input-port:10進表記の負でない整数。
モジュール構成によって、テスタの物理的な構成、たとえばシステムシャーシ内の各モジュールの物理的な場所及びタイプを指定できる。これは、動的なテスタバス構成によって必要とされ、そのテスタバス構成によって、テスタバスアドレスを物理的なスロットの場所にマッピングできる。この情報は、システム構成の妥当性を検査するためにシステムブートアップ時に行われるハードウエア発見プロセスを可能にする。スイッチマトリクスの各出力ポートは物理的なスロットを定義し、そのスロットは単一のハードウエアモジュールによって占有されることが好ましい。以下に示されるのは、本発明の一実施形態による、ファイルModules.cfgにおいて指定されるモジュール構成の一例である。
# Module Configuration File, Modules.cfg
#
Version0.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.
#
Slot1-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
{
MaxAvailable32; # Resource units 1 .. 32.
}
Resource analog
{
MaxAvailablel6; # 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 slots16-30, 50, and 61-64.
#
# Slot 16-30, 50, 61-64
{
Resource dpin
{
MaxAvailable32; # 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
{
ModulelD 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;
}
}
}
以下は、好ましい実施形態によるモジュール構成構造である。
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-coiifig:
VendorID id-code ;
ModuleID id-code ;
ModuleDriver file-name ;
Resource resource-name {max-spec disabled specopt}
max-spec:
MaxAvailable positive-integer ;
disabled-spec:
Disabled positive-integer-list;
positive-integer-list:
positive-integer-list-entry
positive-integer-list , positive-integer-list-entry
positive- inte ger-list-entry:
positive-integer
positive-integer-number-range
positive-integer-number-range:
positive-integer - pos-integer
1.version-identifier:集合[0−9a−zA−Z.]からの1つ又は複数の文字を含む文字列。ただし、最初の文字は集合[0−9]から選択されなければならない。
2.positive-integer:集合[0−9]からの1つ又は複数の文字を含む文字列であり、0で始まらない。
3.id-code:集合[a−zA−Z_0−9]からの1つ又は複数の文字を含む文字列。
4.resource-name:集合[a−zA−Z_0−9]からの1つ又は複数の文字を含む文字列。ただし、第1の文字は集合[a−zA−Z]から選択されなければならない。
DUTピン記述はピン記述ファイルを用いて記述される。ユーザは、ピン記述ファイル内のDUTピンの記述を入手できようになり、その記述は拡張子.pinを有する。このプレーンテキストファイルは、少なくとも、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, Al, 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
}
}
}
1.ピングループ及びピンは同じ名前空間を共有し、グローバル(すなわち試験計画)範囲を有する。これらの名前をグローバル範囲にする結果の1つは、異なる資源ブロックにおいて宣言されるときでも、ピン及びピングループが重複した名前を使用することができないことである。
2.ピン記述ファイルにおいて少なくとも1つの資源定義が必要とされる。
3.各資源において少なくとも1つのピン名が定義されなければならない。
4.ピン及びピングループ名は資源境界内で固有であることが要求される。
5.2つ以上の資源のために同じピン又はグループ名を定義することができる。しかしながら、同じ資源内に同じものがある場合には無視される。
6.1つのグループ定義内に現れる全てのピン名及びグループ名はその資源内で既に定義されていなければならない。
7.もし与えられる場合には、グループ定義は少なくとも1つのピン名又はグループ名を持たなければならない(すなわち、グループ定義は空であることはできない)。
8.ピングループ定義は、予め定義されたピングループへの参照を含むことができる。
9.ピングループ定義は、予め定義されたピン及び/又はピングループの追加及び削除のような集合演算を含むことができる。
以下に与えられるのは、本発明の好ましい実施形態によるピン記述のための構造である。
version-info pin-description
version-info:
Version version-identifier;
pin-description:
PinDescription {resource-pins-def-list}
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.]からの1つ又は複数の文字を含む文字列。それはバージョン番号を表す。
2.resource-name:集合[a−zA−Z_0−9]からの1つ又は複数の文字を含む文字列であり、数字で始まらない。それはdpin又はdpsのような資源の名前を表す。
3.pin-name:集合[a−zA−Z_0−9]からの1つ又は複数の文字を含む文字列であり、数字で始まらない。それは、ピンA0の名前を表す。
4.pin-gourp-name:集合[a−zA−Z_0−9]からの1つ又は複数の文字を含む文字列であり、数字で始まらない。それは、ピングループABUSの名前を表す。
5.index:負でない整数。それは、関連するピンのグループの下限又は上限を表す。
ソケットは、DUTピン名と物理的なテスタピン(チャネル)割当てとの間のマッピングを指定する(物理的なテスタチャネル番号はモジュール構成ファイルにおいて定義される)。異なるソケットを用いて、異なるDUTパッケージ及び異なるロードボード構成等をサポートすることができることに留意されたい。マルチDUTシステムの場合、DUT/チャネル割当てのためのソケット定義は、基本ソケットの複数のサイトへの「クローニング」をサポートすることができる。しかしながら、異なるソケット(すなわち、同じ論理ピンのための異なる物理的なマッピング)はサイトモジュール区分を考慮すべきである。したがって、DUTピンをテスタチャネル割当てに与えることに加えて、ソケットは実効的にはサイト区分も定義する。こうして、ソケットファイルは、いくつかの個別のサイトソケットのための定義を含むことができる。以下に示されるのは、3つのDUTサイトを定義するソケットファイルのサンプルである。
SocketDef
{
DUTType CHIP3
{
PinDescription dutP3.pin; # The pin description file for CHIP3
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;
}
}# End DUT 2
DUT 1 # This is "cloned" from DUT 2 above
{
SiteController 1; # Same Site Controller as for DUT 2
Resource dpin
{
SIotOffset 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 of the 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 CHIP3
DUTType 74LS245
{
PinDescription dutLS.pin;
DUT 3 disabled # This DUT site is disabled, and will be ignored
{
・・・
}
}# End DUTType 74LS245
} # End SocketDef
1.ソケットファイルは、モジュール構成ファイル、及び所与のDUTタイプのためのユーザのピン記述ファイルの両方からの情報を用いる(上記の例のピン記述の場合の指定を参照されたい)。モジュール構成情報は、ソケットファイルコンパイラが暗黙のうちに利用することができる。ソケットファイルコンパイラは、パターンコンパイラの一部を構成し、ソケットDUT名からテスタチャネルへのマッピング、モジュール構成及びピン記述ファイルを読み出し、分析して、テスタピンのパターンコンパイラによって用いられるDUTピンへのマッピングを設定する。
2.DUTタイプ当たり少なくとも1つのDUTサイト定義が必要とされ、それは、SlotOffset構文ではなく、フルスペック構文を用いなければならない。同じDUTタイプに対して2つ以上のDUTサイト定義が与えられる場合には、第1のサイト定義はフルスペック構文を用いなければならない。
3.後続の各DUTサイト定義(同じDUTタイプ)は、フルスペック構文、SlotOffset構文のいずれかを用いることができるが、両方は用いることができない。これにより、個々のサイトが、標準パターンから逸脱できる(たとえば、動作不能のチャネルに起因する)。
4.SlotOffset構文から導出される結合は、そのDUTタイプのために定義される第1のサイト(フルスペック構文を用いる)に対して定義される。
5.DUTサイトは、実際の物理的な順序で宣言される必要はない。これにより、第1の(物理的な)サイトがそのパターンから逸脱する状況が許される。
6.DUTサイトIDは、ソケット全体にわたって(すなわち、その中で定義される全てのDUTタイプにわたって)固有であることが要求される。
7.DUTサイト定義毎に少なくとも1つの資源定義が必要とされる。
8.サイト定義を、モジュール構成とともに用いて、試験構成が単一サイト/単一DUTであるか、単一サイト/複数DUTであるかを判定しなければならない。
9.全ての場合に、ソケットファイルは、ピン記述ファイル及びモジュール構成ファイルと一致する1組のDUTチャネルマッピングを指定しなければならない。
10.場合によっては、1つ又は複数のDUTチャネルがテスタから切断されることをソケットが指定できるようにすることが望ましい(たとえば、割り当てられた物理チャネルを特殊なID「0.0」を有するチャネルと指定することによる)。この場合、試験プログラムの関連で、これらのDUTチャネルを使用し、参照することができる。そのようなチャネル上での動作の結果として、システム警告が生成される(ただし、エラーではない)。ロード時に、切断されたチャネルのためのパターンデータは破棄される。
以下は、本発明の好ましい実施形態によるモジュール構成のための構造である。
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.]からの1つ又は複数の文字を含む文字列。それはバージョン番号を表す。
2.DUT-type-name:集合[0−9a−zA−Z.]からの1つ又は複数の文字を含む文字列。ただし、最初の文字は集合[0−9]から選択されてはならない。それは、CHIP3のようなDUTのタイプを表す。
3.pin-description-file-name:ファイルの簡単な名前であり、そのディレクトリ名は含まないが、全ての拡張子を含む。そのファイル名は、ホストオペレーティングシステムによって認識される構文からなり、引用符に囲まれる場合には、空白及び他の文字が許される。
4.switch-matrix-input-port-number:10進表記の負でない整数であり、サイトコントローラに接続される入力ポートのポート数を表す。
5.dut-id:10進表記の負でない整数であり、DUTのインスタンスを特定する。
6.resource-name:集合[0−9a−zA−Z]からの1つ又は複数の文字を含む文字列であり、最初の文字は数字であってはならない。それは資源ファイルにおいて定義される資源の名前を表す。
7.resource-item-name:集合[0−9a−zA−Z]からの1つ又は複数の文字を含む文字列であり、最初の文字は数字であってはならない。それは、ピン又はピングループのような資源ユニットの名前を表す。
8.resource-item-index:10進表記の負でない整数であり、資源項目のグループのうちの特定のメンバを表す。resource-item-index-rangeの関連では、それは、資源項目グループの連続した文字列の下限又は上限を表す。
9.resource-unit-index:10進表記の負でない整数であり、資源ユニット(チャネル)のグループのうちの特定のメンバを表す。resource-unit-index-rangeの関連では、それは、資源ユニットグループの連続した文字列の下限又は上限を表す。
論理的なピン名を物理チャネルにマッピングすること(たとえばソケットによって提供される)に加えて、テスタ資源を指定するためにいくつかの属性を用いることができることに留意されたい。たとえば、試験固有、ベンダ固有、及び/又は試験システム固有の場合がある、チャネルのための特定のハードウエア構成を定義するために、複数のオプションを用いることができる。これらのオプションは、ピンモードオプションを用いて記述され、ピンモードオプションファイルを通して入手できる。
{
clock IN double;
a0 OUT single;
・・・
};
先に指摘されたように、資源定義ファイル(Resource.rsc)、システム構成ファイル(Sys.cfg)及びモジュール構成ファイル(Module.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
テスタシステムの2つの主なエンドユーザ向けコンポーネントのうちの1つが試験環境である。他のコンポーネントは、テスタがエンドユーザ(すなわち、試験技師及び試験クラス開発者)に提供するプログラミングファシリティである。
ユーザ変数及び定数のためのファイル*.usrv
仕様セットのためのファイル*.spec
レベルのためのファイル*.lvl
タイミングのためのファイル*.tim
試験条件グループのためのファイル*.tcg
ビン定義のためのファイル*.bdefs
カスタム関数及び試験クラス用のファイルプリヘッダのためのファイル*.ph
カスタムタイプのためのファイル*.ctyp
カスタム変数のためのファイル*.cvar
試験計画のためのファイル*.tpl
・ユーザ変数及び定数
・仕様セット
・レベル
・タイミング
・試験条件
・ビン定義
・プリヘッダ
・カスタムタイプ
・カスタム変数
・試験計画
試験記述ファイルをインポートすることにより、インポート用ファイルが、インポートされるファイルによって利用可能であるオブジェクトの名前を参照できる。これにより、インポート用ファイルは、インポートされるファイルによって命名されるオブジェクトを参照できる。ピン記述ファイルxxx.pinをインポートするソケットファイルaaa.socについて考える。同じくxxx.pinをインポートする別のbbb.socファイルも存在することができる。しかしながら、これらのインポートのいずれによっても、xxx.pinによって記述されるオブジェクトは発生しない。それらは、既に存在するものと仮定されるオブジェクトを参照するだけである。
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 Flow 1
{
・・・
}
1.yがxを命名するインポートステートメントを有する。又は、
2.xがzによってインポートされ、yがzを命名するインポートステートメントを有する。
ユーザ変数及び定数を用いて、グローバル変数及び定数が定義される。それらの定数は、その値がコンパイル時に固定され、変更することができないオブジェクトである。たとえば、最大整数値は定数になる。一方、変数に結び付けられる式は、APIを介して、実行時に変更することができる。
・整数
・符号なし整数
・ダブル
・ストリング
・ボルト単位の電圧(V)
・ボルト/秒単位の電圧スルー(VPS)
・アンペア単位の電流(A)
・ワット単位の電力(W)
・秒単位の時間(S)
・メートル単位の長さ(M)
・ヘルツ単位の周波数(Hz)
・オーム単位の抵抗(Ohm)
・ファラド単位の静電容量(F)
・pF(ピコファラド)の場合のような、10−12の場合のp(ピコ)
・nS(ナノ秒)の場合のような、10−9の場合のn(ナノ)
・uS(マイクロ秒)の場合のような、10−6の場合のu(マイクロ)
・mV(ミリアンペア)の場合のような、10−3の場合のm(ミリ)
・kOhm(キロオーム)の場合のような、10+3の場合のk(キロ)
・MHz(メガヘルツ)の場合のような、10+6の場合のM(メガ)
・GHz(ギガヘルツ)の場合のような、10+9の場合のG(ギガ)
# File limits.usrv
# --------------------------------------------------------
Version 1.0.0;
#
# This UserVars 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 Minlnteger = -2147483648;
# Smallest value such that 1.0 + Epsilon!= 1.0
Const Double Epsilon =2.2204460492503131 e-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;
}
# 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.0 mV; # 400 milliVolts
Const Voltage VOutHigh= 5.1; # 5.1 Volts
Const Time DeltaT = 2.0E-9; # 2 nanoseconds
Const TimeClkTick =1.0ns; # 1 nanosecond
Const Resistance R10 = 10.0 kOhms; # 10 kilo Ohms
# Some variables are declared below.
Current ILow = 1.0 mA; #1 milliAmp
Current IHigh = 2.0 mA; # 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], A1
# in ABusVil [1], so on.
#
Voltage ABusVil[8] ={1.0, 1.2, Others = 1.5};
}
# Does not compile because a Current and a Voltage cannot be added
# to yield a Power.
#
Power Pxxx = IHigh + VInHigh;
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
# Explicit type conversion is allowed, but not required.
# X becomes 3.5
Double X = Double (Pxxx); #X becomes 3.5
Integer Y = Integer (Pxxx); #Y becomes 3
# Explicit type conversion is required.
Length L = Double (Pxxx); #L becomes 3.5 meters
Voltage V = Integer (Pxxx); #V becomes 3.0 Volts.
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 the earlier declaration
# of MyVars.
#
Integer Z = X + Y;
}
名前が修飾されている、すなわち名前が点によって分離される2つの部分を含む場合には、変数は、その点の前にある部分によって名前を付けられる、名前付きユーザ変数コレクションからもたらされる。したがって、上記のMyVars.XはMyVarsコレクション内のXを指している。デフォルトユーザ変数コレクションを明示するために、名前「_UserVars」を用いることができる。
ユーザ変数は、nameストリング、const/varブーリアン、列挙された値としてのtype及びツリー表記としてのexpressionを有するn個組のコレクションとして実装される。1つの名前の式は、以下のコールによってセットすることができる。
DoubleT, VoltageT,...};
Status setExpression(const String& name,
const bool isConst,
const elementaryType,
const Expression& expression);
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") );
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[l]", 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(I .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));
これらの名前及び式を含むC++ UserVarsクラスは、アプリケーションプログラムインターフェース(API)をエクスポートし、実行時にこれらの値を評価し、変更する。UserVarsに関連する式の変更は、UserVarsがいつ再評価されるか、及びその評価の影響が何であるかという問題にも対処する。
{
UnsignedlntegerT, 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 ("Y", true, IntegerT, Expression("X+1"));
{
UnsignedIntegerT, IntegerT, DoubleT, VoltageT, ...
};
Status getType(const String& name,
ElementaryType& elementaryType) const;
・UserVars Global Re-evaluationメソッド。
・所与の変数又は定数に従属する変数及び定数のリストをゲットするためのメソッド。
仕様セットは、セレクタに基づいて値を取り込むことができる変数のコレクションを供給するために用いられる。たとえば、セレクタMinnie、Mickey、Goofy及びDaisyを用いる以下のSpecification Setについて考える。
# File Aaa. spec
# ---------------------------------------------------------
Version 1.0;
Import Limits.usrv;
SpecificationSet Aaa (Minnie, Mickey, Goofy, 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,
Maxlnteger - 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; }
}
yyy = 30;
zzz =MaxInteger - xxx - 2;
www = yyy + zzz;
1.その名前が修飾されている場合には、その名前は、名前付きユーザ変数コレクションにおいて分解されなければならない。
2.その名前が修飾されていない場合には、その名前は、その名前が試験条件グループにおいて宣言される場合にはローカル仕様セットにおいて、それが試験条件グループにおいて参照される場合には名前付き仕様セットにおいて分解される。
3.その名前が上記の規則によって分解されない場合には、その名前はデフォルトユーザ変数コレクションにおいて分解される。
Import limits. usrv; # 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++ SpecificationSetクラスによって実装されることができる。SpecificationSetクラスは基本的には、UserVarsクラスと同じAPIを有するが、セレクタのための余分なストリングパラメータがあることが異なる。したがって、このAPIは詳細には説明されない。
Levelは、ピン及びピングループのパラメータを指定するために用いられる。それは、以下の形の宣言のコレクションである。
{
<pin-param-1> = xxx;
<pin-param-2> = yyy;
...
}
# File CHIPlevels.lvl
# ------------------------------------------------------
Version 1.0;
Import CHIP3resources.rsc;
Import CHIP3pins.pin;
Levels CHIP3Levels
{
#
# 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 fileCHIP3pins.pin,
# the InPins group is in the "dpin" resource. From the
# imported resource definition file CHIP3resources.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 after the call to set Clock 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.0 ms;
POST_WAIT= 10.0 ms;
# 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.0 V);
}
}
Levels CHIP4Levels
{
# ...
}
上記の規則を用いて、以下の演算をサポートするC++ Levelsオブジェクトを書くことができる。
・以下の演算が行われる。
const String& parameterName,
ElementaryType elementaryType,
const Expression& Expression);
Expression("v_ih + 1.0");
・以下の演算が行われ、その演算は、先に説明されたように、全ての所定のモジュールレベルインターフェースをくまなく調べて、発行し、パラメータの全てのレベルを、指定された順序で割り当てられる。セレクタパラメータを用いて、先に指定された規則に従って、それらの式内の名前が分解される。
試験条件グループ部分言語は、仕様、タイミング及びレベルの記述を一緒にパッケージ化する。Timingオブジェクトは多くの場合に、複数のパラメータを用いて指定される。複数のパラメータを複数のタイミングにおいて用いて、種々のパルスの前縁及び後縁を指定することができる。同様に、Levelsは種々の電圧レベルの最大値、最小値及び典型値を指定することによりパラメータ化することができる。試験条件グループ(TCG)オブジェクトは、仕様と、これらの仕様に基づくTimings及びLevelsのインスタンシエーションとを一纏めにする。
# File myTestConditionGroups.tcg
# ---------------------------------------------------------
Version 0.1;
Import CHIPlevels.lvl;
Import edges.spec;
Importtimingl.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_cc 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"vlnHigh" must be previously defined
# in a blockof 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,
# and is given as an example of using scientific
# notation for numbers along with units.
Time t_le = 1.0E-6 uS,
1.0E-6 uS + 4.0 * DeltaT,
1.0E-6 uS + 2.0 * DeltaT;
Time t_te = 30ns,
30ns + 4.0 * DeltaT,
30ns + 2.0 * DeltaT;
}
# Refers to the CHIP3Levels imported earlier. It
# is one of possibly many levels objects that have been
# imported from the above file.
Levels CHIP3Levels;
# Refers to filetimingl.tim containing the single
# timing Timingl. The filename should be quoted if
# it has whitespace characters in it.
Timings Timing 1 ;
}
# Another test condition group
TestConditionGroup TCG2
{
# CIockAndDataEdgesSpecs is a specification set which
# is available in the edges.specs file. Assume it has
# the following declaration:
# Specification Set ClockAndDataEdgesSpecs (min, max, typ)
# {
# Time clock_le = 10.00 uS, 10.02 uS, 10.01 uS;
# Time clock_te = 20.00 uS, 20.02 uS, 20.01 uS;
# Timedata_le = 10.0 uS, 10.2 uS, 10.1 uS;
# Time data_te = 30.0 uS, 30.2 uS, 30.1 uS;
# }
# A Specification Set 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;
}
# 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;
Voltagev_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;
}
TestConditionオブジェクトは1つのTCGを特定のセレクタに結び付ける。一旦、TCGが先に示されるように宣言されたなら、以下に示されるように、TestConditionオブジェクトを宣言することができる。
{
TestConditionGroup = TCG1;
Selector = min;
}
TestCondition TCTyp .
{
TestConditionGroup = TCG1;
Selector = typ;
}
TestCondition TCMax
{
TestConditionGroup = TCG1;
Selector = max;
}
# Declare a FunctionalTest"MyFunctionaITest" that refers to three
# Test Condition Group instances.
#
Test FunctionalTest MyFunctionalTest
{
# Specify the Pattern List
PList = patlAlist;
# Any number of TestConditions can be specified:
TestCondition = TCMin;
TestCondition = TCMax;
TestCondition = TCTyp;
}
試験条件グループ内の名前の分解は先に説明された。しかしながら、これらの規則が繰返し述べられ、再び以下に与えられる。
1.その名前が修飾されている場合には(ページを参照されたい)、その名前は、名前付きユーザ変数コレクションにおいて分解されなければならない。
2.その名前が修飾されていない場合には、その名前は、その名前が試験条件グループにおいて宣言される場合にはローカル仕様セットにおいて、それが試験条件グループにおいて参照される場合には名前付き仕様セットにおいて分解される。
3.その名前が上記の規則によって分解されない場合には、その名前はデフォルトユーザ変数コレクションにおいて分解される。
試験条件グループは以下の実行時の意味を有する。
・InputPins.VIL
・InputPins.VIH
・OutputPins.VIL
・OutputPins.VIH
・Clock.VOL
・Clock.VOH
上記の規則を用いて、Test Condition GroupがC++ TestConditionGroupクラスにおいて宣言されることができ、それを以下のように初期化することができる。
Bin Definitionクラスはビン、すなわち、数多くのDUTを試験した結果を要約するカウンタのコレクションを定義する。1つのDUTを試験する過程において、そのDUTは、たとえば特定の試験の結果を指示するために、任意のビンにセットされることができる。試験が進められるとき、そのDUTは別のビンにセットされることができる。DUTが最終的にセットされるビンは、その試験の終了時の最後のそのような設定である。この最終的なビンのためのカウンタは、このDUTの試験の終了時にインクリメントされる。ビン定義を有する別個のファイルは接尾部.bdefsを有するべきある。
# File CHIPbins.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 at2.8GHz","2.8GHzFail";
"2.8GHzSBFTFail":
"SBFT Fails at 2.8GHz", "2.8GHzFail";
"2.8GHzLeakage":
"Leakages at 2.8GHz", LeakageFail;
}
}
File CHIPbins.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
{
"3 GHzAllPass" :
"Good DUTs at 3GHz", "3GHzPass";
"3 GHzCacheFail":
"Cache Fails at 3GHz", "3GHzFail";
"3 GHzSBFTFail":
"SBFT Fails at 3GHz", "3GHzFail";
"3GHzLeakage":
"Leakages at 3GHz", LeakageFail;
"2.8GHzAllPass":
"Good DUTs at 2.8GHz", "2.8GHzPass";
"2.8GHzCacheFail":
"Cache Fails at2.8GHz", "2.8GHzFail";
"2.8GHzSBFTFail":
"SBFT Fails at 2.8GHz", "2.8GHzFail";
"2.8GHzLeakage":
"Leakages at 2.8GHz", LeakageFail;
}
}
{
# A group of most base bins
BinGroup A { ... }
# A group of base 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 { ... }
}
1.識別子又はストリングリテラルのいずれかである名前と、
2.このビンが何を要約するかを記述する記述と、
3.このビンがリファインメントBinGroup内にある場合には、それがリファインメントであり、ベースビンとしても知られているビンの名前とを有する。
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 SoftBins."3GHzPass";
}
SetBin SoftBins."2.8GHzAllPass";
1.複数のSoftBin「2.8GHzAllPass」
2.複数のHardBinのリファインメント「2.8GHzPass」
3.複数のPassFailBinのリファインメント「Pass」
1.ビンがリーフビンである場合には、それは、1つのDUTの試験の終了時にこのビンのためにSetBinステートメントが実行された回数である。
2.ビンがベースビンである場合には、それは、それがリファインメントであるビンのカウンタの和である。
1.BinDefinitions宣言はいくつかのBinGroup宣言から構成される。
2.各BinGroup宣言は、名前と、それがリファインメントであるオプションのBinGroup名と、それに続くビン宣言のブロックとを有する。
3.ビン宣言は、名前と、それに続く記述と、オプションでそれに続く、このビンがリファインメントであるベースビンの名前とを含む。
4.ビン名はストリングリテラル又はIdにすることができる。空ストリングは有効なビン名にすべきではない。ビン名は、BinGroup宣言内の名前の中で固有であるべきであるが、他のBinGroup宣言において同じ名前を用いることができる。
5.BinGroup宣言Xxxが別のBinGroup宣言Yyyのリファインメントである場合には、Xxx内の全てのビン宣言は、Yyyからのベースビンの名前を宣言しなければならない。したがって、複数のSoftBinは複数のHardBinのリファインメントであることを宣言されるので、複数のSoftBin内の各ビン宣言は複数のHardBinのビンのリファインメントである。
6.PassFailBinのような、別のBinGroup宣言のリファインメントでないBinGroup宣言は、ベースビンを宣言しないBin宣言を有することが好ましい。
1.AaaがBbbのベースビンである場合には、AaaはBbbの1組のベース内にある。
2.Aaaの任意のベースもBbbの1組のベース内にある。
上記の規則を用いて、1つのオブジェクトタイプBinGroupを、BinDefs宣言内のBinGroup宣言毎に構成することができる。クラスBinGroupはサブクラスLeafBinGroupを有する。これらの2つのクラスの演算は同じであるが、BinGroup::incrementBinがC++保護演算であるのに対して、LeafBinGroup::incrementBinがC++公開演算であることを除く。
LeafBinGroup(BinGroup& baseBinGroup);
const String& description,
const String& baseBinName);
String& description);
Status getBaseBin(const String& binName,
BinGroup* pBaseBinGroup,
String& baseBinName);
Status getBinValue(const String& binName,
unsigned int& value);
TestPlan::TestPlan()
:m_PassFailBins, // Default Constructor
m_HardBins(&m_PassFaiIBins),
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");
...
pTestPlan->setBin("SoftBins", "3GHzAllPass");
m_pCurrentBinGroup->incrementBin(m_currentBin);
試験計画は、試験プログラムの主要構造と考えることができる。試験計画はファイルをインポートし、類似のコンストラクツインラインを定義することができる。こうして、いくつかのグローバルの定義を与えられたファイルをインポートし、付加的なグローバルズインラインを宣言することができる。
試験計画の重要な要素のうちの1つはFlowである。Flowは、有限状態機械をカプセル化する。それはいくつかのFlowItemを含み、それらのFlowItemはIFlowableオブジェクトを実行し、その後、別のフロー項目に遷移する。IFlowableを実行することは、IFlowableインターフェースを実装するオブジェクトを実行することを含む。IFlowableインターフェースを実装する一般的なオブジェクトはTest及びFlowそのものである。
# FlowTest1 implements a finite state machine for the
# Min, Typ and Max flavors of MyFunctionalTest1. On
# success it testsTest1Min, 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 testsMyFunctionalTest1Min, ... 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
{
PropertyPassFail = "Pass";
IncrementCounters PassCount;
GoTo FlowTest1_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 { ... }
}
1.FlowItem FlowTest1_Minを実行することで開始する。
2.FlowTest1_Minは機能試験、MyFunctionalTest1Minを実行する。この試験の詳細は、後に完全な試験計画が提示されるときに与えられる。
3.この試験を実行することから、9つの結果、0、1、2、5、6、7、−6、−5又は−4が予想される。最初の2つのResult句はそれぞれ0及び1を処理し、第3の句は結果値の残り全てを処理する。
4.結果「0」(合格)が生じる場合には、FlowTest1_MinはカウンタPassCounterをインクリメントする。その後、それは新たなFlowItem FlowTest1_Typに遷移する。
5.結果「1」又は結果「2」が生じる場合には、FlowTest1_MinはカウンタFailCounterをインクリメントし、そのフローから戻る。
6.FlowTest1_Typは同じようにして動作し、成功時にFlowTest1_Maxをコールする。
7.FlowTest1_Maxは同じようにして動作し、成功時に、成功した結果(「0」)でFlowTest1から戻る。
1.1つのIFlowableを実行する(それは、以前に定義されたFlow、又はTest、又は上記の規則によってC++において実装されることができるユーザ定義のFlowを用いることができる)。
2.IFlowableの実行は数値結果を返す。その結果に基づいて、ある特定の動作が行われ(いくつかのカウンタを更新する)、その後、2つの事柄のうちの1つが起こる。
a.Flowは数値結果にとともにコール元に戻る。
b.Flowは、別の状態(FlowItem)に遷移することにより継続する。
・1つのFlowItemは1つの名前を有する。
・1つのFlowItemは実行されるべき1つのFlowableを有する。
・1つのFlowItemは数又はResult句を有する。
・1つのFlowItemの各Result句は動作を提供し、1つの遷移で終了し、1つ又は複数の結果値に関連付けられる。
{
Result <one or more result values>
{
<actions for these result values>
<transition for these result values>
}
Result<one or more other result values>
{
...
}
...
}
・GUIツールによって用いられるストリング値を有する実体を属性結果にセットするためのプロパティ動作。これは上記のFlowTest1の例において見ることができる。
・任意の、又はユーザルーチンをコールするためのルーチンコール動作。これは後に説明される。
Flowオブジェクトの典型的な使用法は、Testのシーケンスを定義することである。その後、このシーケンスは、試験計画サーバ(TPS)において生じるイベント、すなわちExecute Test Planイベントの結果として実行される。各サイトコントローラ上にある試験計画サーバが、ユーザの試験計画を実行する。しかしながら、Flowオブジェクトは、他のイベントに応答しても実行される。括弧内の名前は、Flowをこれらのイベントに割り当てる際に用いられる名前である。
1.System Load Flow(SysLoadFlow)。このFlowは、1つの試験計画が1つ又は複数のサイトコントローラにロードされるときに、システムコントローラ上で実行される。それは、任意のサイトコントローラ上に試験計画を実際にロードする前に実行される。このフローによって、試験計画開発者は、システムコントローラを起源とすべきである動作を定義できる。そのような動作は、パターンファイルのブロードキャストロード、較正動作等を含む。
2.Site Load Flow(SiteLoadFlow)。このFlowは、1つの試験計画がサイト上にロードされ、初期化された後に、サイトコントローラ上で実行される。これにより、任意のサイト特有の初期化を行うことができる。
3.Lot Start/End Flow(LotStartFlow/LotEndFlow)。これらのFlowは、試験計画サーバが新たなロットの開始を通知されるときに、サイトコントローラ上で実行される。これは典型的には、データログストリームにロット特有の情報で注釈を付すために製造環境において用いられる。
4.DUT Change Flow(DUTChangeFlow)。このFlowは、そのDUT情報が変化するときに、サイトコントローラ上で実行される。再び、これは典型的には、アナログストリームを更新するために製造環境において用いられる。
5.TestPlan Start/End Flow(TestPlanStartFlow/TestPlanEndFlow)。これらのFlowは、試験計画サーバが、現在のTest Flowを実行し始めるように指示されるとき、及びそのフローがその実行を終了するときに、サイトコントローラ上で実行される。
6.Test Start/End Flow(TestStartFlow/TestEndFlow)。これらのFlowは、Test Flowが新たなTestを実行し始めているとき、及びそのTestがその実行を終了するときに、サイトコントローラ上で実行される。
7.Test Flow(TestFlow)。このFlowは、試験計画サーバが「Execute Test Plan」メッセージを受信するときに実行される主要Flowオブジェクトであることに留意されたい。
以下の例では、フローによって実装される有限状態機械を記述するコメントとともにFlowが与えられる。その有限状態機械は、遷移行列として与えられる。その行列の行はFlowItemに対応し、列は結果に対応する。その行列の1つの行のエントリは、返された結果が列において指定された値であるときに、その行のFlowItemから遷移されるFlowItemを指示する。
# 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.bdefs;
# -------------------------------------------------------------
# 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.
# Pattern list variables are deferred till customization is
# examined.
PListDefs
{
# File qualified pattern list names
pllA.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";
}
TestConditionTClMin
{
TestConditionGroup = TCG1;
Selector = min;
}
TestCondition.TClTyp
{
TestConditionGroup = TCG1;
Selector = typ;
}
TestCondition TC1Max
{
TestConditionGroup = TCG1;
Selector max;
}
# Likewise for TC2Min, TC2Typ, TC2Max ...
#
# 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 theTClMin TestCondition.
#
Test FunctionalTest MyFunctionalTest1Min
{
PListParam = patlAList;
TestConditionParam =TClMin;
}
# Another FunctionalTest selecting TCG1 with "typ"
Test FunctionalTestMyFunctionalTest1Typ
{
PListParam = patlAList;
TestConditionParam = TC1Typ;
}
# Another FunctionalTest selecting TCG1 with "max"
Test FunctionalTest MyFunctionalTest1Max
{
PListParam = patlAList;
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 patlAList;
TestConditionParam = TC2Typ;
}
Test FunctionalTest MyFunctionalTest2Max
{
PListParam patlAList;
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 areUnsignedIntegers that are
# initialized to zero.
#
Counters {PassCount, FailCount}
#
# Flows can 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 numberof 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, both 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 testsMyFunctionalTest1Min, ... 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
{
PropertyPassFail = "Pass";
IncrementCounters PassCount;
GoTo FlowTest1_Typ;
}
Result 1,2
{
PropertyPassFail = "Fail";
IncrementCounters Fail Count;
Return 1;
}
}
FlowItem FlowTest1_Typ MyFunctionalTest1Typ
{
Result 0
{
PropertyPassFail = "Pass";
IncrementCounters PassCount;
GoToFlowTest1_Max;
}
Result 1,2
{
PropertyPassFail ="Fail";
IncrementCountersFaiICount;
Return 1;
}
}
# Likewise for FlowTest1_Max
FlowItem FlowTest1_Max MyFunctionalTest1Max
{
Result 0
{
PropertyPassFail = "Pass";
IncrementCounters PassCount;
Return 0;
}
Result 1,2
{
PropertyPassFail = "Fail";
IncrementCountersFailCount;
Return 1;
}
}
}
#
# FlowTest2 is similar to FlowTest1. 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 testsMyFunctionalTest2Min, ... 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:
# -------------------------------------------------------------
# Result 0 Result 1 Result 2
# -------------------------------------------------------------
# FlowTest2_Min FlowTest2_Typ return 1 return 1
# FlowTest2_Typ FIowTest2_Max return 1 return 1
# FlowTest2_Max return 0 return 1 return 1
#
# Where the IFlowables run by eachFlowItem are:
# FlowItem IFlowable that is run
# FIowTest2_Min MyFunctionalTest2Min
# FlowTest2_Typ MyFunctionalTest2Typ
# FlowTest2_Max MyFunctionalTest2Max
#
Flow FlowTest2
{
# ...
}
#
# Now the FlowMain, the main test 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 return 0 return 1
#
# Where the IFlowables run by each FlowItem are:
# FlowItem IFlowable that is run
# FlowMain_l 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
{
PropertyPassFail "Pass";
IncrementCounters PassCount;
GoTo FlowMain_2;
}
Result 1
{
# Sorry ... FlowTest1 failed
PropertyPassFail = "Fail";
IncrementCounters FailCount;
# Add to the right soft bin
SetBin SoftBins. "3GHzSBFTFail";
Return 1;
}
}
FlowItem FlowMain_2 FlowTest2
{
Result 0
{
# All passed!
PropertyPassFail = "Pass";
IncrementCounters PassCount;
# Add to the right soft bin
SetBin SoftBins."3GHzAllPass";
Return 0;
}
Result 1
{
# FlowTest1 passed, but FlowTest2 failed
PropertyPassFail = "Fail";
IncrementCounters FailCount;
# Add to the right soft bin
SetBin SoftBins."3GHzCacheFail";
Return 1;
{
}
}
TestFlow = FlowMain;
1.最初に、バージョン番号が与えられる。この番号を用いて、コンパイラバージョンの互換性が確保される。
2.その後、複数のインポートが宣言される。これらは、その試験計画において用いられる名前を分解するために必要とされる宣言を有する種々のファイルである。
3.次に、試験計画名が宣言され、その後、試験計画のインライン宣言を行う。
4.次に、1組のPListDefsが宣言される。これらは、名前付きファイルからGlobalPListsの名前を付ける、ファイル修飾付きの名前を含む。それらは、パターンリスト変数も含む。パターンリスト変数は、実行時にcustom flowableにおいて初期化されることができる変数である。それらは、ランタイムまで、試験と実際のパターンリストとの結合を遅らせる手段を提供する。
5.次に、1組のUserVarsが宣言される。これらはストリングを含む。
6.その後、合格した試験及び不合格の試験の数を判定するために、いくつかのカウンタが宣言される。カウンタは変数に過ぎず、初期化されて0になり、IncrementCounterステートメントにおいてインクリメントされる。それらは、1つのDUTの試験の終了時に現在セットされているビンだけがインクリメントされるという意味を有する、先に説明されたBinとは異なる。
7.次に、一連のTest Conditionが宣言される。これらはそれぞれ、Test Condition Group及びセレクタを指定する。この例では、Test Condition Groupは、mytestconditionsgroup.tcgからもたらされる。しかしながら、それらは試験計画においてインラインにすることができる。
8.次に、一連のFlowable又はTestが宣言される。これは、パターンリスト及び試験条件を選択する既知のTest FunctionalTestである。こうして、たとえば、MyFunctionalTest1Maxは、試験条件TC1Max及びパターンリストを選択する。
9.この後に、3つのフロー、FlowTest1、FlowTest2及びFlowMainが宣言される。FlowはFlowableを実行する。Flowableは、Test(MyFunctionalTest1Max等)及び他のフロー(FlowTest1及びFlowTest2等)を含む。FlowTest1及びFlowTest2はそれぞれ、Test1及びTest2の最小、典型及び最大バージョンを通る。フローFlowMainは、先に宣言されているフロー、FlowTest1及びFlowTest2をコールする。
10.最後に、TestFlowイベントがFlowMain Flowに割り当てられる。したがって、フローFlowMainは、ユーザがこの計画を実行しようするときに、この試験計画によって実行されることになるフローである。
上記の規則を用いて、Flowそのものを除いて、要素の大部分のためのC++インプリメンテーションを果たすことができる。
FlowItemを表すためのC++クラスは以下のインターフェースを有することができる。
・このFlowItemのために実行されることになるIFlowableをセットすることになる演算。
CounterRefList counterRefs) ;
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) ;
unsigned int returnResult);
・最後に、FlowItemは演算を実行する必要がある。
FlowItem FlowMain_2;
CounterRefList counters;
FlowMain_1.setFlowable(FIowTest1);
// 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","3GHzSBFTFaiI");
FlowMain_1.setReturnResult (1, 1) ;
カウンタは0に初期化される変数であり、試験実行中の種々の時点において、IncrementCounterステートメントによってインクリメントされることができる。これは、試験の終了時にのみインクリメントされるBinとは異なる。さらに、ビンは階層的であるのに対して、カウンタは変数に過ぎない。したがって、カウンタはビンよりもはるかに簡単であり、より制限されたファシリティである。
一旦、全てのFlowItemが作成されたなら、Flowオブジェクトは、以下に示されるように、C++オブジェクトとして作成されることができる。
・FlowItemを追加するための演算。
・Flowを実行するための演算。
一般に、プログラムコードの大部分はデバイス試験のためのデータであり、残りは、試験方法を実現する試験プログラムのコードである。このデータはDUTに依存する(たとえば、電源条件、信号電圧条件、タイミング条件等)。試験コードは、ATEハードウエアに指定されたデバイス条件をロードするためのメソッドと、ユーザによって指定された目的(データロギング等)を実現するために必要とされるメソッドから構成される。
先に述べられたように、試験クラスはITestから派生する。上記の規則を用いて、これらは、ITestインターフェースを実装するC++クラスにおいて実装されることができる。ITestインターフェースのための指定されるメソッドに加えて、これらのクラスは、デバイス試験の特定のクラスを実行するために必要とされるTest固有のインテリジェンス及びロジックを提供する。また試験クラスはIFlowableインターフェースも実装する。この結果として、Testクラスのインスタンスは、試験を実行するためにFlowItemにおいて用いることができる。
ユーザがC関数をコールできるようにし、ITest及びIFlowableインターフェースを実装する自らのクラスを開発できるようにするために、カスタマイゼーションの仕組みが提供される。
1つの試験クラスのオブジェクトが、そのメソッド及びシグネチャに関して問合せを受けることができる場合には、そのオブジェクトは、生成されるソースコード内に包含するのに適したパラメータが入手できることを検証されることができる。そのような特徴は、翻訳段階における誤り検査及び妥当性検査のために極めて有用である。試験技師がパラメータの名前、又はこれらのパラメータへの引き数の数(又はおそらくタイプ)を間違った場合には、C++コンパイラからのコンパイル時エラーメッセージを待つ代わりに、翻訳段階において、それが見つけられて、翻訳時に意味のあるエラーメッセージを与えることができる。これは、試験技師にとってさらに有用である。
C++においてヘッダを用いることはよく知られている。しかしながら、C++はパースし、読み出すのが難しいので、本発明の一実施形態は、コンパイラが、試験クラス開発者がヘッダとして用いることができるC++出力を作成できるようにする構文を定義する。この実施形態によれば、試験クラス開発者はプリヘッダファイルを書き、それがプリヘッダファイルとしてコンパイラ400によって出力され、それにより、対応する試験クラス又は他の試験実体において見ることができるようにする。
TestCondition TC 1
{
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;
}
#
# Parameterization specification pre-header for FunctionalTest
#
ImportTest1.ph; # For base class Test1
Import Test2. ph; # For base class Test2
TestClass = FunctionalTest; # The name of this test class
PublicBases = Test1, Test2; # List of public base classes
# The parameters list or "parameter block":
Parameters
{
# The following declaration specifies that a FunctionalTest has
# - a parameter of type PList
# - [represented by C++ typeTester::PatternTree]
# - stored in a member named m_pPatList
# - a function to set it named setPatternTree.
# - 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.
# - a parameter description for the GUI to use as a tool tip
# 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";
}
}
#
# The section below is part of the Pre-Header which is an escape
# into C++ code. This will be referred to as a "template block."
#
# 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 voidexec();
virtual voidpostExec();
$ParamFns
...
private:
double m_someVar;
$ParamAttrs
...
};
...
$ParamImpls
} // End namespace
CPlusPlusEnd
コンパイラがプリヘッダファイルを処理するとき、コンパイラは、$Inc、$Class、$ParamAryTypes等のコンパイラ変数の値を蓄積する。これにより、その後、コンパイラは上記と全く同じようにC++コードを生成し、指示された場所においてコンパイラ変数$Inc、$Class等の値に拡張することにより、以下のC++ヘッダを作成できる。FunctionalTest.phの場合、コンパイラは、FunctionalTestクラスのための以下のC++ヘッダファイルFunctionalTest.hを作成する。
#include <ITest.h>
#line 5 "./FunctionalTest.ph"
#include <Test1.h>
#line 6 "./FunctionalTest.ph"
#include <Test2.h>
#line 55 "./FunctionalTest.ph"
#include <vector>
#line 55"./FunctionalTest.ph"
#include <Levels.h>
#line 55 "./FunctionalTest.ph"
#include <TestCondnGrp.h>
...
#line 56 "./FunctionalTest.ph"
namespace
{
#line 7 "./FunctionalTest.ph"
class FunctionalTest : public ITest,
#line 8 "./FunctionalTest.ph"
public Test1,
#line 8 "./FunctionalTest.ph"
public Test2
#line 59 "./FunctionalTest.ph"
{
// Array types for parameters storage:
#line 61"./FunctionalTest.ph"
public:
#line 37 "./FunctionalTest.ph"
typedef std::vector<Tester::TestCondition *>
TestConditionPtrsAry_t;
#line 62 "./FunctionalTest.ph"
public:
virtual void preExec();
virtual voidexec();
virtual void postExec();
public:
#line 7 "./FunctionalTest.ph"
void setName(OFCString &name); # Automatic for all tests
#line 22 "./FunctionalTest.ph"
void setPatternTree(PatternTree *);
#line 23 "./FunctionalTest.ph"
StringgetPListParamDescriptionO const;
#line 39 "./FunctionalTest.ph"
void addTestCondition(TestCondition*);
#line 40 "./FunctionalTest.ph"
void getTestConditionParamDescription () const;
#line 67 "./FunctionalTest.ph"
...
private:
double m_someVar;
#line 70 "./FunctionalTest.ph"
private:
#line 7 "./FunctionalTest.ph"
OFCString m_name; # Automatic for all tests
#line 21 "./FunctionalTest.ph"
Tester::PatternTree *m_pPatList;
#line 38 "./FunctionalTest.ph"
TestConditionPtrsAry_tm testCondnsArray;
#line 71 "./FunctionalTest.ph"
...
};
...
#line 7 "./FunctionalTest.ph"
inline void
#line 7 "./FunctionalTest.ph"
FunctionalTest::setName(OFCString &name)
#line 74 "./FunctionalTest.h"
{
m_name = name;
return;
}
#line 39 "./FunctionalTest.ph"
inline void
#line 39 "./FunctionalTest.ph"
FunctionalTest::addTestCondition(TestCondition *arg)
#line 74 "./FunctionalTest.ph"
{
m_testCondusArray.push_back(arg);
return;
}
#line 23 "./FunctionalTest.ph"
inline void
Tester::String FunctionalTest::getPListParamDescription()
{
return "The PList parameter for a FunctionalTest";
}
#line 40"./FunctionalTest.ph"
inline void
Tester: :StringFunctionalTest::getTestConditionParamDescription()
{
return "The TestCondition parameter for a FunctionalTest";
}
#line 75"./FunctionalTest.ph"
} // End namespace
{
PListParam = patList1; # Previously defined pattern list
TestConditionParam = TC1;
TestConditionParam = TC2;
}
FuncTest1.setName ("FuncTest1");
FuncTest1.setPatternTree(&patList1);
FuncTest1.addTestCondition(&TC1);
FuncTest1 .addTestCondition(&TC2);
プリヘッダは、付加的なタイプとして、いくつかの他のユーザ定義列挙法をサポートする。これにより、GUIは、ある特定のパラメータの値をセットするために用いることができる、取り得る選択肢のドロップダウンリストを提供できる。さらに、プリヘッダは、テーブルと考えることができる複数のパラメータを関連付けるための機能を提供する。たとえば、プリヘッダは、「プロパティ」のアレイを、関連する1組の、名前のためのストリングのアレイ、及び値のための整数のアレイとして実装するのに都合良く用いることができる。この機能を実装する1つの簡単な方法は、カスタムタイプ(後に説明される)のアレイを用いることである。しかしながら、それは、ユーザに、使用すべきカスタムタイププリヘッダを書くことを要求する。これらの機能がいずれも、以下の例において示される。
# 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 setPattemTree.
# - 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
これにより、フロー遷移が行われるときに、ユーザはカスタム関数をコールできる。カスタム関数は、以下のように、プリヘッダを通して宣言される。
# 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 inta_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, Unsignedlnteger dutld);
#
# 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.
Unsignedlnteger GetDUTID();
上記のMyFunctionsのためにコンパイラによって生成されることになるC++コードは、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);
}
プリヘッダを用いて、C++ IFlowableインターフェースを実装するプリヘッダを作成することもできる。これにより、ユーザは、FlowItem内で実行することができるカスタムフローアブルを定義できる。以下に示されるのは、ユーザ定義の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 Intl of type Integer
# - [represented by C++ type int]
# - stored in a member named m_intl Val
# - a function to set it named setIntl Val.
Integer Int1
{
Cardinality= 0-1;
Attribute = m_int1Val;
SetFunction = setIntl Val;
}
# 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 addStr.ingVal.
String Stringltem
{
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
1.現在のテスタ構成内で試験計画を実行することができるか否かを検査することになるプログラムローディングのためのFlow。
2.特定のパターン及びパターンリストをロードすることになるパターンローディングのためのFlow。
3.ハードウエア及びソフトウエアを既知の状態にし、グローバル変数をロードし、他の初期化及び妥当性検査機能を実施することになる初期化のためのFlow。
4.他の一般的に有用な試験フロー。
先のTestクラスパラメータ化に関する説明は、既知のタイプ、すなわち基本タイプ並びにPLists及びTestConditionsのようなテスタ定義のタイプを有するような試験クラスパラメータの場合のみ許される。ユーザの自由度を高めるために、タイプ拡張性を与え、それにより、複数のタイプ(コンパイラには事前にはわかっていない)を作成し、使用できるようにすることが重要である。カスタムタイプ(CT)はCustom Typeにおいて定義される。これらのカスタムタイプを用いて、C言語ストラクトに対応するタイプ(Plain Old Dataタイプ、すなわちPODとも呼ばれ、C++の同じ名前のものとは大きく異なる)及び関数シグネチャのためのC言語タイプ定義に対応するタイプを定義することができる。ユーザタイプを含む別個のファイルは拡張子.ctypを有する。ここに示されるのは、本発明の好ましい実施形態によるユーザタイプ宣言の一例である。
# File MyCustomTypes.ctyp
# --------------------------------------------------------
Version 1.0.0;
CustomTypes
{
# A structured Plain-Old-Data type
Pod Foo
{
String S1; # String is a standard type
IntegerI1; # ... and so is Integer
String S2;
}
# Another structured type using Foo
Pod Bar
{
Foo Fool;
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 () Void;
}
先に提示されたCustomType宣言は、コンパイラによって以下のC++コードに翻訳される。
{
struct Foo
{
Tester:: String S1;
int I1;
Tester:: String S2
};
struct Bar
{
Foo Foo 1;
Tester:: String S1;
Foo Foo2;
};
typedef int (*BinaryOp) (int&, int&);
typedef void (*UnaryOp)(int);
typedef void (*NullaryOp)();
}
ユーザがある試験を拡張する場合について考えると、その試験は、パターンリスト及び試験条件に加えて、他のクラスオブジェクト、並びにCustom Type(すなわち、.ctypファイル)を含むファイル内で定義される任意の(すなわち、ユーザ定義の)オブジェクトで初期化される必要がある。たとえば、ユーザがファイルMyTestCTs.ctypにおいて定義されるCTを用いることを望むものと仮定する。
Version 1.0;
CustomTypes
{
Pod Foo
{
String name;
PList patternList;
}
Pod Bar
{
Foo someFoo;
Double dVal;
}
RoutineBinaryOp(Integer, Integer) return Integer;
}
Import MyFunctions.ph;
Import MyCustomTypes.ctyp;
...
# TheCustomVars block defines variables of the Custom
# types defined earlier.
CustomVars
{
...
Bar bar 1 =
{
{"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;
}
...
# 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_binary0p;
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 .
最後に、一旦コンパイラがこのプリヘッダファイルを処理したなら、コンパイラはMyFuncyTestクラスのための以下のC++ヘッダファイル、すなわちMyFuncyTest.hを作成する。
#include <ITest.h>
#include <FunctionalTest.h>
...
namespace
{
class MyFancyTest : public ITest,
public Functional Test
{
public:
typedef std::vector<CustomTypes::Bar *> Bar Ary_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 *) ;
voidsetBinaryOpParam(CustomTypes::BinaryOp *);
...
private:
double m_someVar;
private:
OFCString m_name; # Automatic for all tests
PatternTree*m_pPatList;
TestConditionPtrsAry_t m_testCondnsArray;
BarAry_t m_barsArray;
BinaryOp*m_binary0p;
...
}; // 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
先に示されたように、Testクラス、カスタムFlowableクラス、又はカスタム関数定義のためのプリヘッダは、パラメータ化仕様セクションを通して、クラス/関数へのイントロスペクションを制限する。コンパイラはこのセクションを用いて、クラス/関数のためのパラメータ化インターフェースを生成する(そして、クラス/関数ヘッダそのものを生成する)。Testクラス及びFlowableクラスの場合、コンパイラはまた、このセクションを用いて、Test Planコード内のコールを後に生成し、そのクラスのインスタンスを初期化する。プリヘッダ及び対応する宣言に関する以下の点に留意されたい。
1.全てのTest又はカスタムFlowableクラス定義は、プリヘッダ内で指定されることが好ましい。プリヘッダ内のParametersブロックは、そのようなクラスのためのパラメータリストを指定することができる唯一の場所であることが好ましい(したがって、結果として、パターンリスト及び試験条件仕様のようなTestのための「標準的な」パラメータも、プリヘッダのParametersブロックに含まれる必要がある;これにより、全てのパラメータ、標準及びCTが一様に処理される)。
2.Test又はFlowableクラスのためのプリヘッダにおいて非オプションとして定義される(すなわち、0以外の基数を有する)全てのパラメータが、そのクラスのインスタンスのためのTestブロック又はFlowableブロック宣言の中で初期化されるべきである。
3.Test/Flowableブロックにおいてパラメータの初期化のために用いられるオブジェクトは予め定義されているべきである。
4.置換指示子$Class、$Inc、$ParamAryTypes、$ParamFns、$ParamAttrs及び$ParamImplsが、ユーザが対応する生成されたコードを生成されたクラスヘッダファイル内に挿入させるつもりである、プリヘッダのユーザコードセクション内の正確な場所に現われなければならない。置換指示子毎に特定のコードが生成されるので、これらの置換指示子は厳密に一度だけ現われるべきである。
5.プリヘッダのParametersブロック内のパラメータ仕様の名前(上記の例のPListParam、TestConditionParam又はBarParamのような)は、そのクラスのインスタンスの宣言において用いられることになるパラメータの名前である。
6.以下はパラメータ仕様において用いられる記述子の意味である。
a.Cardinality:これはサポートされることになるこのタイプのパラメータの数を指示する。以下は一実施形態において取り得る値である。
i.1:このパラメータは強制的であり、厳密に一度だけ指定されるべきである。このパラメータは、パラメータのタイプのオブジェクトへのポインタとして保持される。
ii.0−1:このパラメータはオプションである。指定される場合には、それは一度だけ指定されなければならない。このパラメータは、パラメータのタイプのオブジェクトへのポインタとして保持される。
iii.1−n:このパラメータは強制的である。さらに、このパラメータのために複数の値を指定することができる。この値は指定された順序で記憶される。
iv.0−n:このパラメータはオプションである。このパラメータのために複数の値を指定することができる。この値は指定された順序で記憶される。
上記の()及び()の場合に、全ての指定された値が、パラメータのタイプへのポインタ上でテンプレート化される、STLベクター<>に記憶されることになることに留意されたい。このベクターのタイプは定義され、$ParamAryTypesによって指示される場所に挿入される。これらのタイプ定義のためのアクセスレベルは常に公開である。
b.Attribute:このタイプのパラメータ値(複数可)のための記憶として用いるためのC++変数の名前。その名前は、C++クラスの私用データメンバとして全く同じ語で再現されることになり、C++識別子のための要件に準拠しなければならない。この属性のタイプに関して、以下のことに留意されたい。
i.ただ1つの値だけが許される場合には、そのパラメータのタイプへのポインタである。
ii.複数の値が許される場合には、そのパラメータのタイプへのポインタ上にテンプレート化されるSTLベクター<>である(上記の()を参照)。
それらの属性はTest Planによって作成され、ポピュレートされるオブジェクトへの参照を保持し、これらのオブジェクトを所有しないことに留意されたい。オブジェクトの寿命は常に、Test Planそのものによって管理される。
c.SetFunction:このパラメータのための値をセットするために用いるための関数の名前。以下の点に留意されたい。
i.その名前は全く同じ語で再現されることになり、それゆえ、C++言語要件に準拠しなければならない。
ii.その関数のアクセスレベルは常に公開である。
iii.リターンタイプは常に空である。
iv.その関数は常に、タイプポインタ/パラメータタイプのただ1つの引き数をとる。
d.Description:このパラメータのランタイム変更中にヘルプを提供するために、GUIツールによって用いられることになるツールチップであるストリングリテラル。Xxxと名前を付けられたパラメータのためのカスタムクラスにおいて生成されるC++メンバ関数は以下の通りであり、その関数は指定されたストリングを返す。
以下に示されるのは、いくつかのカスタム化を用いて説明される試験計画例である。
# File MyCustomizedTestPlan.tpl
# --------------------------------------------------------
Version 0.1;
#
# Imports as before ...
# 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 theTClMin TestCondition.
#
# Note that compiler can compile this because of the imported
# FunctionalTest.ph file.
#
Test FunctionalTest MyFunctionalTest1Min
{
PListParam = patlAList;
TestConditionParam = TC1Min;
}
#
# Additional FunctionalTest 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;
Stringltem = "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
# FIowMain_4 FlowMain_5 return 1
# FlowMain_5 return 0 return 1
#
# Where the IFlowables run by eachFlowltem are:
# --------------------------------------------------------
# Flowltem IFlowable that is run
# --------------------------------------------------------
# FlowMain_l 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 ("PassedMyFlowable1",
Functions.GetDUTID());
GoTo FlowMain_2;
}
Result 1
{
Property PassFail = "Fail";
IncrementCounters 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.GetDUTIDO);
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;
# A user function call
MyFunctions.Print("Failed FlowTest1",
Functions.GetDUTID());
SetBin SoftBins."3GHzCacheFail";
Return 1;
}
}
# This FlowItem calls the previously defined FIowTest2
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_5DatalogStopFlow
{
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;
# A user function call
MyFunctions.Print("Failed DatalogStopFlow",
Functions.GetDUTID());
Return1;
}
}
}
1.ここでPListDefsセクションは、いくつかのPList名とともに、いくつかのPList変数も有する。PList名は、試験において直に用いることができる名前である。PList変数は試験において用いることができる変数であり、その値は、ランタイムにおいて、カスタム化されたFlowable内のコードによって実際のPListに結び付けられる。
2.PListDefsセクションはオプションである。存在しない場合には、その内容は種々のTest宣言からコンパイラによって推測される。存在する場合には、それは、用いられるTestのPListパラメータの全てを宣言しなければならないが、それはさらに多くのパラメータを宣言することもできる。
3.値をPList変数に割り当てるために、ランタイムAPIを利用できる。TestPlanクラスは以下の関数を有する。そのFlowableはPListVariableを特定のPListに結び付けるためにその関数を用いることができる。
const Tester: :String& fileQualifiedPListName);
複数のフローにおいてカスタム関数コールを呼び出すことを除いて、コンパイラによって生成されることになるC++コードが、先に提示された種々のカスタム化技法のために示されている。FlowItem内のユーザ関数コールは、各FlowのIUserCallsメンバによって取り扱われることが好ましい。各Flowは、以下に示されるように、単一の仮想メンバ関数をエクスポートするインターフェースIUserCallsのメンバを有することが好ましい。
{
public:
virtual void exec(const String& flowItemName,
unsigned int result) = 0;
} ;
{
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")
{
// ...
}
}
};
先に説明されたように、Test Plan記述ファイルは、1つの試験計画において用いられる複数のオブジェクトと、それらの互いに対する関係とを指定する。一実施形態では、このファイルはC++コードに翻訳され、それは、標準インターフェースITestPlanのインプリメンテーションの形でサイトコントローラにおいて実行されることになる。このコードは、サイトコントローラ上にロードされることができるウインドウズ・ダイナミックリンクライブラリ(DLL)にパッケージ化されることができる。Test Program DLLは、サイトコントローラソフトウエアが試験計画オブジェクトを生成し、それが含む試験計画オブジェクトを返すために用いることができる標準的な既知のエントリポイントを有するように生成される。
1つの試験計画記述からITestPlanのインプリメンテーションへの変換のプロセスは、試験プログラムコンパイラ400によって達成される。このプロセスは2段階、すなわち翻訳及びコンパイルにおいて行われる。
MyTestPlan.cpp
Timing1.cpp
MyTestPlan.sln (MSVC++ "Solution" file)
MyTestPlan.vcproj (MSVC++ "Project" file)
サイトコントローラソフトウエアは、その処理空間内にTest Program DLLをロードし、DLL内の「ファクトリ」関数をコールして、Test Planオブジェクトのインスタンスを作成する。一旦Test Planオブジェクトが作成されたなら、サイトコントローラソフトウエアは、その試験計画を実行するか、又は必要とされる任意の他の方法で試験計画とやりとりすることができる。
ウインドウズ環境の大部分のC++ソフトウエア開発者にとってアプリケーション(又はDLL、ライブラリ等)を構築することは、開発環境(MSビジュアルC++、ボーランドC++等)を構築し、コードを編集し、そして(多くの場合に)ボタンを押してプロダクトを構築することを意味する。
ユーザの環境について、ある特定の想定がなされる。それらの想定は以下の通りである。
1.Test Plan開発者は、上記の方法及び規則に従って、自らのTest Planを開発している。
2.Test Plan開発者はC++の熟練者レベルの知識を持たない場合もある。
3.Test Plan開発者は、ファイル(複数可)をTest Plan DLLに変換するために、コマンドラインツール又はGUIツールを利用できる。
MSビジュアルスタジオで非インタラクティブに作業するには、2つの手法のうちの1つが必要になる。第1の(そして最も簡単な)手法はコマンドラインインターフェースを用いることである。第2の(そしてより自由度のある)手法は自動インターフェースを用いることである。このセクションは両方の手法を説明する。
ビジュアルスタジオを非インタラクティブに使用するために、1つ又は複数の有効なプロジェクトを含むワーキングソリューションで開始すべきである。残念なことに、これは、コマンドライン手法又は自動手法のいずれからも達成することができないタスクである。いずれの方法もプロジェクト作成のための仕組みを提供しない。しかしながら、ビジュアルスタジオのためのプロジェクト及びソリューションはテンプレートから作成することができる。それゆえ、プロジェクト名及びテンプレートを与えて開始することにより、ビジュアルスタジオのためのソリューション/プロジェクトを作成することができる。
コマンドラインがサポートしないので、生成されたプロジェクトに新たなファイルを追加するために、ビジュアルスタジオ自動モデルが用いられる。プロジェクトに新たなファイル及び既存のファイルを追加するために、2つのビジュアルスタジオマクロが提供される。ActiveScriptエンジン(VBScript、JScript、ActivePerl、ActivePython等のような)を用いて同じタスクを実行するために、外部スクリプトが類似のコードを用いることができる。それゆえ、本発明のコード生成ツールは新たなファイルを作成し、自動モデルを用いて、それらのファイルを既存のビジュアルスタジオプロジェクトに追加することができる。ファイルが作成された後に、それらのファイルは、必要に応じて、ツールによって更新することができる。
一旦、適当なソリューション及びプロジェクトが得られたなら、ビジュアルスタジオを非インタラクティブに用いて、Test Planを構築することに対していくつかのオプションがある。最も単純なオプションは、コマンドラインからそれを呼び出すことである。そのようなコマンドラインを以下に示す。
Testクラスの開発者がその作業を検査し、デバックするために、サイトコントローラに侵入し、そのコードの中を逐次的に進むことができるようにするデバッガを利用する必要がある。コンパイラによって生成されるコードはMSVC++によってコンパイルされるC++であるので、MSVC++デバッガを用いて、Testクラスインプリメンテーションがデバッグされる。この特徴は、C++において直に作業するTestクラス開発者等だけを対象にしていることに留意されたい。生成されたC++コードを直に参照することなくTestプログラムの動作をデバッグするか、又は逐次的に進めることを望む試験技師に対して他の仕組みが提供される。
このセクションは、テスタのための一般的なソフトウエア環境、すなわちユーザ試験計画によって必要とされるファイルのための場所、そのようなファイルのための代替の場所を指定するための仕組み、並びに試験計画及びモジュール制御ソフトウエアの場所を指定するための方法を説明する。
システムの標準的な場所、及び1つの試験計画によって必要とされる
1.パターンリスト
2.パターン
3.タイミングデータ
4.試験クラスDLL、
・パターンリスト:Tester_PATLIST_PATH
・パターンオブジェクトファイル:Tester_PATOBJ_PATH
・パターンソースファイル:Tester_PATSRC_PATH(これはオプションである;以下を参照)
・Timingデータファイル:Tester_TIMING_PATH
・TestクラスDLL:Tester_TEST_CLASS_LIBPATH
$Tester_INSTALLATION_ROOT\cfg\setups\Setup.envが、「環境」変数のデフォルト値を指定する。他の構成の仕組みが利用できない場合には、このファイルが必要とされる。一般的に、それは、システム上で実行される全ての試験計画の場合に利用可能である。このファイルはインストール中にインストール及び構成管理(ICM)システムによって作成され、インストーラからの入力が先に述べられた3つの変数のためのデフォルト値を割り当てる(上記の3つの変数のためのシステムデフォルトに加えて、このファイルは、以下のサブセクションにおいて説明されるような、ある特定の他のテスタ「環境」変数のためのシステムデフォルトも含むことに留意されたい)。
ユーザ試験計画によって必要とされる「環境」変数に加えて、試験環境によって、以下の2つの「環境」変数が必要とされる。
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に格納される。
探索経路を指定する「環境」変数について以下の点に留意されたい。
1.各変数は、ある特定のタイプの参照されるファイルを見つけるためにシステムが探索することになるディレクトリ名の、セミコロン(「;」)によって分離されたリストにすべきである。
2.システムがそのような「環境」変数の値を最初に調べた後に、その値に対してユーザによって行われた任意の変更(たとえば、環境構成ファイルを編集することによる)は、それを行うための必要性をユーザが明示的にシステムに「通知する」ときにのみ、システムによって登録される。
3.テスタが正常に動作する環境のような分散環境内の「カレントワーキングディレクトリ」(CWD)の表記法は、ユーザが直観的に予想するものではないかもしれないので、CWDに対する経路が曖昧な結果に繋がる可能性があるとき、探索経路内の相対経路名は、関連する環境変数(ルートを定義する機能を提供する)の特定の設定に関連するように解釈される。探索経路内の全ての相対経路名が基づくことになると想定されるルートを指示する、この関連する環境変数は、「Tester_INSTALLATION_ROOT」変数であり、それはユーザのシステムへのテスタインストールのトップレベル(すなわち「ルート」)ディレクトリの場所を与える。
4.ディレクトリエントリは集合[V:*?<>|;]内の文字を含むことができない。セミコロン(「;」)を除いて、この集合内の全ての他の文字はウインドウズファイル名において違法であることに留意されたい。セミコロン(「;」)は探索経路内のエントリを区切るために用いられるので、セミコロンは探索経路エントリにおいて用いられるべきでない。経路名には空白を埋め込むことができるが、経路名の直前及び直後に生じる(すなわち、経路名内の空白でない最初の文字の前及び最後の文字の後の)全ての空白は経路名の一部であるとは見なされず、無視されることに留意されたい。
5.探索経路ディレクトリは、定義の中に現われた順序に探索される。最初に現われたファイルが選択される。
非常に大きな1組の試験パターンファイルの効率的な管理、取り扱い及びローディングは、本発明の一実施形態のフレームワークのアーキテクチャに関する重要な側面である。階層的なパターンリストの概念は、扱いやすい概念化を提供し、エンドユーザがシステムを使いやすくする際の効率的な手段であると見なされる。
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 optionsopt
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 :
Pat pattern-name optionsopt
pattern-list-entry :
PList pattern-list-reference optionsopt
pattern-list-reference :
pattern-list-qualified-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 optionsopt
options :
option
options option
option :
[option-definition]
option-definition :
option-name option-parametersopt
option-parameters:
option-parameter
option-parameters ',' option-parameter
1.version-identifier:集合[0−9.]からの1つ又は複数の文字を含む文字列であり、最初の文字は数字でなければならない。
2.name:集合[a−zA−Z_0−9]からの1つ又は複数の文字を含む文字列であり、最初の文字は集合[a−zA−Z_]から選択されなければならない。
3.pattern-list-name:集合[a−zA−Z_0−9]からの1つ又は複数の文字を含む文字列であり、最初の文字は集合[a−zA−Z_]から選択されなければならない。
4.file-name:有効なウインドウズファイル名(ファイル名内に任意の空白が含まれる場合には、それは二重引用符で囲まれなければならない)。これは単純なファイル名でなければならない、すなわちディレクトリコンポーネントを持つべきでないことに留意されたい。pattern-list-referenceは、同じファイル内のパターンリストを内部参照することができるか、又は別のファイル内のパターンリストを外部参照することができる。外部参照はファイル名によって修飾される必要がある。
5.oprion-name:集合[a−zA−Z_0−9]からの1つ又は複数の文字を含む文字列であり、最初の文字は集合[a−zA−Z_]から選択されなければならない。
6.option-parameter:集合[a−zA−Z_0−9]からの1つ又は複数の文字を含む文字列。
パターンリストのための静的規則又はコンパイル時の規則は宣言及び名前の分解を規定する。パターンリスト言語内の名前は、global-pattern-list-definition及びlocal-pattern-list-definitionによって宣言される。それらの名前は、pattern-list-referenceによって参照される。以下は、これらの宣言及び参照を規定するいくつかの規則である。
1.global-pattern-list-definition又はlocal-pattern-list-definitionはパターンリストの名前を宣言する。pattern-list-referenceは、宣言されたパターンリストの名前を参照する。グローバルパターンリストの名前はグローバルに知られている。ローカルパターンリストの名前は、それらの宣言されたリストブロック内でのみ知られている。それらの名前は、修飾を用いることなく、そのリストブロック内で直に参照されることができる。さらに深くネストされた宣言では、ローカルパターンリストは、修飾された名前によって参照される必要がある。
2.ローカルパターンリスト名は、包含パターンリストの範囲内で知られており、グローバルパターンリスト名はシステムの範囲内で知られている。たとえば、以下を参照されたい。
{
LocalPList L1
{
LocalPList L2
{
...
}
GlobalPList G2
{
...
}
PList L2; # OK. Name L2 is known in this scope
PList G2 # OK. Name G2 is global
}
PList L2; # Error. Name L2 is not known here.
PListL1.L2; # OK. Name L1 is known here. L2 is known by
# qualification.
PList G1.L1.L2; # OK. Qualification by G1 is not needed but
# is allowed.
PList G2; # OK. Name G2 is global
}
3.グローバルパターンリストはパターンリストファイルの最も外側のレベルにおいて定義されることができるか、又は包含パターンリスト内でネストされるように定義されることができる。しかしながら、そのネスティングは単に便宜的なものである。それらは、ファイル内の最も外側のレベルにおいてグローバルパターンリストとして概念的に定義される。ネストされたグローバルパターンリストは、同じ名前の最も外側の(ネストされない)グローバルパターンリストと意味的に同等である。したがって、たとえば、以下を参照されたい。
{
GlobalPList G2
}
is semantically equivalent to:
GlobalPList G1
{
PList G2; # References G2
}
GlobalPList G2 ...
4.全てのグローバルパターンリストは固有に名前を付けられる。
{
# 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.ローカルパターンリストは常に、ローカルパターンリストの名前の範囲も決定する、包含パターンリスト内でネストされた定義を有する。ローカルパターンリストは、その包含パターンリスト内で固有に名前を付けられる。ローカルパターンリストは構文的に、パターンリストファイル内の最も外側のレベルにおいて生じることを許されない。
{
LocalPList L
{
}
LocalPList L2
{
LocalPList L1 # OK. No local name L1 is declared
directly
# in the enclosing scope defined by L2.
{
}
PList Ll; #OK. Refers to Ll declared in L2
PListG1.L1; #OK. Refers to L1 declared in G1.
}
# Error. Redeclaring name L1 when the enclosing scope
# defined by G1 already has an Ll declared in it.
LocalPList L1;
{
}
}
6.各パターンリストファイルは、1つ又は複数のグローバルパターンリストのための定義を含む。これは構文から直に生じる。最も外側のレベルはglobal-pattern-list-definitionであり、それらのうちの少なくとも1つが存在しなければならない。
7.Pattern-nameは、Patキーワードに続く、1つのパターンへの参照である。それは、その名前が接尾語.patをパターン名に連結することによって得られるパターンファイル内に存在するパターンを参照する。そのファイルは、パターンのために定義された1つの探索経路に沿って得られることになる1つのファイルを示す。
8.pattern-list-referenceは、PListキーワードに続くパターンリストへの参照である。その参照は、オプションのファイル名、及びそれに続く、修飾されたパターンリスト名からなり、そのパターンリスト名は単に、ドットによって分離される名前のリストである。したがって、たとえば、以下は、ファイルfoo.plist内にあるグローバルパターンリストG1内にネストされるL1内にネストされるL2内にネストされるローカルパターンリストL3を参照するpattern-list-referenceとして用いることができる。その名前の最も左側の名前部分はG1である。
1.各名前部分は、その前にある接頭部に照らして宣言される名前に分解する。
2.ファイル修飾がある場合には、最も左側の名前部分は、名前を付けられたファイルにおいて宣言されるグローバルパターンリストに分解する。
3.ファイル修飾がない場合には、最も左側の名前は、包含範囲内のローカルパターンリストに分解することができ、それが失敗する場合には、次の包含範囲内のローカルパターンリストに分解することができ、それが包含グローバル範囲まで続けられる。
4.グローバル範囲がパターンリストファイル内の最も外側のレベルにおいて宣言されたかのように、グローバル範囲の意味を保持するために、最も近くにある包含グローバル範囲への範囲の探索を制限する必要がある。ネストされたグローバル範囲が最も外側のレベルにおいて(同等に)テキスト形式で宣言された場合には、名前分解探索は、その範囲を検査した後に終了する。
5.その参照が以前のステップによって分解されていなかった場合には、最も左側の名前部分が、この同じファイル内のグローバルパターンリストに分解されることができる。
6.その参照が以前のステップによって分解されていなかった場合には、最も左側の名前部分が、.plist接尾部を最も左側の名前部分に追加することにより、そのファイル内で名前を付けられるグローバルパターンリストに分解されることができる。
7.その参照が以前のステップによって分解されていなかった場合には、その参照はエラー状態である。
{
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 Gl in the file "my_plists.plist".
PList my_plists.plist:Gl;
# 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:Gl.Ll.L2;
LocalPList L1
{
LocalPList L2
{
}
}
PList L1; # OK. Refers to L1 declared in the
# enclosing scope of Gl
}
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 declared 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;
PListG1.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 name L2 is declared in G2.
PList L2;
}
}
{
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
GI.L2.
# This is a mutually recursive reference to G1.L2.
PList G1.L2;
}
図6は、本発明の一実施形態によるパターンコンパイラ602及びパターンローダ604を示す。パターンのユーザ定義の内容は、プレーンテキストファイルであるパターンソースファイル606において入手することができる。パターンコンパイラは、ソースファイルを、テスタハードウエア上にロードするのに適したモジュール特有のフォーマットにコンパイルする責任を担う。この後者のファイルはパターンオブジェクトファイルと呼ばれる。以下はその一般的な属性である。
1.パターンオブジェクトは、ユーザが作成することはできない。むしろ、ユーザは、他のパターンリスト及び/又はパターンのコレクションであるパターンリストを常に取り扱う。パターンリストオブジェクトは、必要に応じてユーザがアクセスできるようにしながら、その中に含まれるパターンオブジェクトを作成し、所有し、保持する。
2.パターンは1つの試験計画内で固有に名前を付けられる。すなわち、その試験計画内では、同じ名前を有する2つのパターンは存在することはできない。パターンの名前は、それを含むファイルの名前とは異なる。パターンファイル名は、1つのパターンを参照するためにパターンリストファイルにおいて用いられる名前であり、一方、そのパターンの実際の名前はパターンファイルにおいて定義される。
こうして、パターンコンパイラ602は、(用いられるベンダ特有のデジタルモジュールに照らして)特定のサイト構成をターゲットにする必要がある。この説明の残りの部分において、用語「モジュール」は、一例として、デジタルモジュールを指すために用いられる。種々のベンダからのモジュール608をシステムに組み込むことができるようにするために、以下の手順が好ましい。
1.各モジュールベンダは、動的にロード可能なライブラリ又は個別の実行可能プログラムの形で、自ら所有するモジュール特有のパターンコンパイラ610を提供する責任を担う。このコンパイラライブラリ/実行可能プログラムは、最低でも、引き数とみなされる既知のcompile()関数を提供する。
a.(1つ又は複数の)パターンソースファイル名のアレイ
b.Pin Descriptionファイル名
c.Socketファイル名
d.コンパイルされるオブジェクトの宛先を指定するオプションのディレクトリパス名
e.任意のベンダ特有のパラメータの指定を許可するストリング名/数値対のオプションのアレイ(これは他のベンダによって無視され得る)
2.パターンソースファイルは、2つの異なるタイプのセクションを収容する。
a.全てのコンパイラがアクセス可能である情報を含む「共通」セクション(ただし、必ずしも用いられる必要はない)。
b.固有ベンダコードによってそれぞれ特定され、特定のベンダコンパイラによって使用可能な情報のための1つ又は複数のオプションのベンダ特有のセクション。
3.ベンダのコンパイラは、パターンオブジェクトファイルを直に作成しない。代わりに、テスタは、パターンコンパイラの一部であるオブジェクトファイルマネージャ(OFM)614によって管理されるパターンオブジェクト「metafile」612を提供する。パターンコンパイラは、システムコントローラとして動作するコンピュータ上に、又はオフラインで、たとえばシステムコントローラが接続されるネットワーク上に配置することができる。これまで抽象語において参照された「パターンオブジェクトファイル」は、実際にはこのオブジェクトメタファイルである。オブジェクトメタファイルは、パターンソースファイルと同じ名前を付けられることになり、ソースファイル拡張子がオブジェクトファイル拡張子によって置き換えられる。OFMは、このファイルの読出し及び書込みを行うためのアプリケーションプログラミングインターフェース(API)を提供する。オブジェクトメタファイルは、以下のものを格納するための手段を有する。
a.共通ヘッダ情報
b.対応するモジュール、及びそのモジュールためのパターンデータの場所を特定する情報を含む、モジュール特有のヘッダ情報
c.モジュールベンダの要求に応じて編成され、モジュールベンダによって解釈されることができる、モジュール特有のパターンデータ
本発明の一実施形態の試験システムでは、各モジュールベンダが、自ら所有する特有のパターンローディング機構を提供する責任を担う。先に説明されたように、パターンオブジェクトメタファイルは、種々のセクションにモジュール特有のデータを格納する。ベンダインプリメンテーションは、パターンオブジェクトメタファイルから関連するセクションにアクセスするために、システムアプリケーションプログラミングインターフェース(API)を用いる。さらにOFMフレームワークは、各モジュールのロードパターンメソッドをコールし、モジュール特有のデータをメタファイルの適当なセクションからモジュールにロードする責任を担う。
各コンパイラベンダは複数のパターンのための種々のプレーンテキストフォーマットを完全に指定することができ、それは実際には大部分の場合に必要になる。しかしながら、一般的に、全てのベクターのために複数のモジュールにわたる統一性及び同一の意味が必要になる、サイクルベースの試験環境の場合、パターンファイルのための、共有され、一般化された構文が望ましいだけでなく、必要になる。この共有された構文は、パターンソースファイル内の「共通」セクションのために指定されることになる構文である。実際には、大抵の場合に、「共通」セクションはパターンファイルにおいて必要とされる唯一のセクション(ヘッダ情報を除く)であり、全てのベンダのコンパイラはそのセクションにおいてのみ正常に動作することが想定される。このセクションは、全てのコンパイラが解釈できるべきである、パターンファイルのための規則を表す。パターンファイルは以下のように編成される。
version_info pattern_definitions
version_info :
Version_version-identifier ';'
pattern_definitions :
pattern_definition
pattern_definitions pattern_definition
pattern_definition :
main_header '{' main_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 :
identifier
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
jff_op :
JFF identifier
jffi_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_mask_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_section_domains :
subr_section_domains subr_section_domain
subr_section_domain
subr_section_domain :
Domain domain_name '{' subr_section_contents '}'
source_selection_table :
SourceSelectionTable '{' source_selector_definitions '}'
source_selector_definitions :
source_selector_definitions 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]からの1つ又は複数の文字を含む文字列であり、最初の文字は数字でなければならない。
2.identifier:集合[a−zA−Z_0−9]からの1つ又は複数の文字を含む文字列であり、最初の文字は[a−zA−Z_]から選択されなければならない。
3.vendor-section-contents:ベンダ特有のコンパイラに対してのみ意味のある任意のテキスト。
4.file-name:有効なウインドウズファイル名(ファイル名内に任意の空白が含まれる場合には、それは二重引用符で囲まれなければならない)。これは単純なファイル名でなければならない、すなわちディレクトリコンポーネントを持つべきでないことに留意されたい。
5.waveform-table-pin-group-name:集合[a−zA−Z_0−9]からの1つ又は複数の文字を含む文字列であり、最初の文字は[a−zA−Z_]から選択されなければならない。この変数は他の場所で宣言され、ピンのグループに共通である波形テーブルの名前を保持する。
6.24bit number:最大16777215までの有効な10進数。
7.8bit number:最大256までの有効な10進数。
8.index-register:有効な10進数。1つのモジュールの実施形態では、これは値[1−8]を有することができる。
9.vector:これは、STIL内のVectorステートメントに類似である。これは、信号名及び信号グループ名を参照し、コンパイラがPin Descriptionファイルにアクセスできるようにするために必要になることに留意されたい。
10.waveform-time-reference:集合[a−zA−Z_0−9]からの1つ又は複数の文字を含む文字列であり、最初の文字は[a−zA−Z_]から選択されなければならない。
1.pattern-name項目は、パターンファイルがそのためのデータを含むPatternオブジェクトに関連付けられることになる名前を指定する。これは、対応するパターンオブジェクトメタファイル内のヘッダに引き継がれる。
2.waveform-time-referenceは、Timingファイル内の、パターンファイルに対して外部から定義されることになる特定のwaveform-and-timing定義のための名前である。パターンファイルにおいてwaveform-time-referenceを指定することにより、別のwaveform-time-referenceが現われるまで、(waveform-and-timingのための)特定の名前が全ての後続のベクターに結合される。
3.サブルーチンコールのためのオペランド(たとえば、JSR及びJSRC)は、同じパターンファイルにおいて以前に現われたpattern-specラベル、又は外部から定義されたサブルーチンパターン内のpattern-specラベルであるストリングである。このオペランドは最終的には、サブルーチンをロード/処理するために分解される。サブルーチンコールオペランドのためのラベルは、システムにわたって固有である必要がある。
MAIN Patternソースファイルの簡単な例が、その使用法を例示するのを助ける。
# Filename : good1.pat
#
Version 1.0 ;
# -------------------------------------------------------------
# Main Pattern definition:
# -------------------------------------------------------------
MainPattern good1
{
CommonSection
{
MacroDef defaultDataVal (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
{
SourceSelectorSrcSelDef
{
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 =LLHHLLHH; } }
STSS SrcSelOne { Vector { DATA = LHLHLHLH; } }
RTN { Vector { DATA = LLXXXXXX; } }
}
}
}
1.パターンソースファイル名
2.ソースファイルにおいて宣言されるようなパターンのタイプ
3.ソースファイルからのバージョン情報
4.パターンソースファイルの共通セクションにおいて用いられる全てのwaveform-and-timing名のリスト
5.パターンソースファイルの共通セクション内の(相対的な)ベクターアドレスへの全てのサブルーチン参照のマップ
6.パターンソースファイルの共通セクション内の(相対的な)ベクターアドレスへの全てのラベル参照のマップ
7.一般的なブックキーピング情報:ベクターカウント、命令カウント等。
プレーンテキストパターンソースファイル:.pat
コンパイルされたパターンオブジェクトメタファイル:.pobj
パターンリストファイル:.plst
Tester_PATLIST_PATH:パターンリストファイルの場合。
Tester_PATSRC_PATH:パターンソースファイル(オプション)の場合。
Tester_PATOBJ_PATH:パターンオブジェクトメタファイルの場合。
パターンオブジェクトはユーザによって作成されない。むしろ、ユーザは常に、他のパターンリスト及び/又はパターンのコレクションであるパターンリストオブジェクトを処理する。ユーザがアクセスできるようにしながら、パターンリストオブジェクトは、その中に含まれるパターンオブジェクトを作成し、所有し、保持する。ユーザの試験プログラム内のパターンリストオブジェクトは、パターンリストの実際の定義を含む、ディスク上のパターンリストファイルに関連する。パターンリストの定義は、そのパターンリストのための明示的な名前を提供し、ファイル名連想を通して、パターンの順序付きリスト及び/又は他のパターンリストを特定する。このセクションは、パターンリスト及びパターンのソフトウエアがテスタフレームワークにおいて如何に操作されるかを理解するための前置きとして、それらのソフトウエア表現を記述する。
試験システム内の1つの試験サイト(及び拡大解釈して、その中にある試験計画)は、複数のトップレベルパターンリストに関連付けることができる。しかしながら、複数の試験計画に対して、常に1つの実行文脈だけが存在する。トップレベルパターンリストは、それによって(階層的に)参照されるパターンのための実行シーケンスを定義するので、アクティブな実行文脈は、現在選択されているトップレベルパターンリストに対応するものである。これは、ある時点において、1つのパターンリスト内に含まれるパターンだけがハードウエア上にロードされることができることを意味しないことに留意されたい。むしろ、1つの実行シーケンスを実行可能にするためにハードウエア上にロードされる必要がある1組のパターンは常に、現在ロードされている全てのパターンのサブセットでなければならない。
直観的には、トップレベルパターンリストを表現するための1つの方法は、ある種のツリーデータ構造によると考えられる。図7は、本発明の順序付きのパターンツリーの一実施形態を示しており、パターンリストAがトップレベルパターンリストであると仮定する。
以下の情報がパターンツリーの全てのノードにおいて格納される。
1.そのノードに関連するエンティティ(パターンリスト又はパターン)の名前。
2.定義ソースのタイプ。葉(パターンノード)の場合、これは常にパターンファイルになる。中間(パターンリスト)ノードの場合、これは「トップレベルファイル」(トップレベルパターンリスト定義用)、又は「エンベデッド・イン・ファイル」(ネストされたパターンリスト定義用)のいずれかにすることができる。
3.そのノードが関連するディスク上のファイルの最後の変更タイムスタンプ。
1.そのノードによって表されるパターンリストオブジェクト上に(もしあるなら)セットされる実行オプション、すなわちそのオブジェクトオプション。
2.その子毎に、そのノードによって表されるパターンリスト定義内の各子参照上に(もしあるなら)セットされる実行オプション、すなわち参照オプション。
1.実行ツリーとして編成される、外部及び内部両方のパターンによってコールされるサブルーチンへの全ての(おそらく遷移的な)参照。
パターンリストの内容に対してなされる変更は概念的には、そのパターンリストへの全ての参照に影響を及ぼす。必要に応じてパターンオブジェクト及びパターンリストオブジェクトに適用される以下の規則が、そのような変更を管理するために用いられる。
1.ディスク上のパターンリストファイルの内容に対してなされる変更は、そのパターンリスト上(又はそれを参照する任意の他のパターンリスト上)で実行されるload()コマンドにおいてのみ、試験システムの中に伝えられる。言い換えると、ソフトウエア内のパターンリスト階層は常に、ハードウエア上に現在ロードされているパターンリストを反映する。
2.ユーザは、パターンリストをそれらのディスクファイルソースと同期させるために、ロード時間中に行われる検査を無効にするモードをセットすることができる。これにより、生成モードの動作を、より迅速且つ安全にすることができる。
試験サイト(及び拡大解釈して、そのサイトのための試験計画)に関連するトップレベルパターンリストは公開(グローバル)範囲を有する。そのシステムは、ユーザが個々のノード及びサブツリーにアクセスできるように、トップレベルパターンリストを表すパターンツリーをナビゲートするためのAPIを提供する。
パターンリストの静的な規則は先に説明された。パターンリストの動的な(実行)規則の記述がここで提示される。
上記のように、各パターンリスト宣言(その定義に先行する)又はパターンリスト/パターン参照エントリの後に、複数の実行オプションが続くことができる。パターンリスト実行オプションは、パターンリストのランタイム実行を変更する。さらに拡張できるようにするために、これらのオプションのための名前(及びオプション値)がパターンコンパイラのパターンリストファイルパーサによって単にストリングとして処理され、必要に応じて特定のバージョンによって解釈されることになる。テスタは、以下に記述される、1組のオプション及びそれらの解釈を規定する。しかしながら、ベンダはその1組のオプションを拡張することができる。オプション構文をパース時に妥当性検査できるようにするために、パターンリストファイルパーサは、ある特定のバージョンのための情報ファイルを読み出すことができる。そのような情報ファイルを用いて、ある特定のバージョンがそもそも実行オプションの指定をサポートするか否かを指定することもできる。
1.パターンリスト定義上(すなわち、ファイル内の「local-pattern-list-declaration、global-pattern-list-declaration」生成物内)でセットされるIntrinsicオプションは、事実上、ユーザの試験プログラム内の対応するパターンリストオブジェクト上での直接的なオプション設定である。したがって、これは、そのパターンリストオブジェクトへの全ての参照に当てはまり、オブジェクトオプションと呼ばれる。
2.パターンリスト/パターンへの参照上(すなわち、ファイル内の「pattern-entry」及び「pattern-list-entry」生成物内)でセットされるReferentialオプションは、オプションの範囲を、その階層内の特有の経路、すなわちツリーのルートから考慮中の参照に導く経路(パターンリスト/パターンの宣言順序によって確立される)に制限する。したがって、これらは、特定のオブジェクト参照上のオプションであり(且つ、オブジェクトそのものにおけるオプションではない)、参照オプションと呼ばれる。
3.コレクション階層(パターンリスト/パターンの宣言順序によって確立される)内の任意のリスト/パターンのための有効オプション設定は、ツリーのルートからそのリスト/パターンまでの経路に沿って出合うオブジェクトオプション及び参照オプションの組み合わせである。その特定の組み合わせの仕組み(たとえば、集合の結び、集合の交わり、又は任意の他の競合解消アルゴリズム)は、オプションそのもののプロパティである。
・それがIntrinsicである(すなわち、Global又はLocalキーワードを伴う定義に関連する)か、Referentialである(すなわち、Pat又はPListキーワードを伴う参照に関連する)か。Intrinsicオプションは、定義の場所及び全ての参照において当てはまるが、Referentialオプションは、それらが関連する参照においてのみ当てはまる。
・さらに、オプションが全ての静的に(構文的に)又は動的に(参照されることにより意味的に)ネストされたパターン又はパターンリストに再帰的に当てはまるものと仮定される場合には、そのオプションは「子によって継承される」と言われる。
1.Mask<pin/pin group>
GlobalPList、LocalPListに適用されるときにIntrinsic。
PList、Patに適用されるときにReferential。
子によって継承される。
このパターンリストは常に、使用禁止の指示されたピン又はピングループによって参照されるピンの比較回路を有する。多くの場合に、ハードウエアの制限の結果として、バースト不連続部が生じることになる。
2.BurstOff
GlobalPList、LocalPListに適用されるときにIntrinsic。
PList、Patに適用されるときにReferential。
子によって継承されない。
このパターンリストは常に、非バーストモードにおいて実行される。このオプションは子によって継承されないが、BurstOffDeepオプション(下記)は子によって継承される。
3.BurstOffDeep
GlobalPList、LocalPListに適用されるときにIntrinsic。
PList、Patに適用されるときにReferential。
子によって継承される。
このパターンリストは常に、非バーストモードにおいて実行される。このオプションは子によって継承されるが、BurstOffオプション(上記)は子によって継承されない。BurstOffDeepオプションは子によって消されないことに留意されたい。
4.PreBurst<pattern>
GlobalPList、LocalPListに適用されるときにIntrinsic。
指定されたバーストオプションを有しない子ノードによってのみ継承される。
指示されるパターンは、このパターンリスト内の全てのバーストに前置されるべきである。PreBurstパターンは、このパターンリストノードに起因して開始される全てのバーストの直前に生じる。そのオプションは、同じパターンであるPreBurstオプションを有するバースト内に既にあるときには適用されない。
5.PostBurst<pattern>
GlobalPList、LocalPListに適用されるときにIntrinsic。
指定されたバーストオプションを有しない子ノードによってのみ継承される。
指示されるパターンは、このパターンリスト内の全てのバーストに後置されるべきである。PostBurstパターンは、このパターンリストノードに起因して開始される全てのバーストの直後に生じる。そのオプションは、同じパターンであるPostBurstオプションを有するバースト内に既にあるときには適用されない。
6.PrePattern<pattern>
GlobalPList、LocalPListに適用されるときにIntrinsic。
子によって継承されない。
指示されるパターンは、このパターンリスト内の全てのパターンに前置されるべきである。
7.PostPattern<pattern>
GlobalPList、LocalPListに適用されるときにIntrinsic。
子によって継承されない。
指示されるパターンは、このパターンリスト内の全てのパターンに後置されるべきである。
8.Alpg<alpg object name>
GlobalPList、LocalPListに適用されるときにIntrinsic。
子によって継承されない。
名前付きALPGオブジェクトは、低速APGレジスタ設定、読出し待ち時間、中間データレジスタ、アドレススクランブル、データ反転、データ発生器等の関連する情報を格納する。
9.StartPattern<pattern>
GlobalPList、LocalPListに適用されるときにIntrinsic。
子によって継承されない。
そのパターンリストは、その実行シーケンスにおいてStartPatternが最初に現われるときに実行し始める。
10.StopPattern<pattern>
GlobalPList、LocalPListに適用されるときにIntrinsic。
子によって継承されない。
そのパターンリストは、その実行シーケンスにおいてStopPatternが最初に現れるときに実行を止める。
11.StartAddr<vector offset or label>
GlobalPList、LocalPListに適用されるときにIntrinsic。
子によって継承されない。
これはStartPatternオプションを伴わなければならない。そのパターンリストは、その実行シーケンスにおいてStartPatternが最初に現われるときのStartAddrにおいて実行し始めなければならない。
12.StopAddr<vector offset or label>
GlobalPList、LocalPListに適用されるときにIntrinsic。
子によって継承されない。
これはStopPatternオプションを伴わなければならない。そのパターンリストは、その実行シーケンスにおいてStopPatternが最初に現われるときにStopAddrにおいて実行するのを止めなければならない。
13.EnableCompare_StartPattern<pattern>
GlobalPList、LocalPListに適用されるときにIntrinsic。
子によって継承されない。
パターン比較は、指示されるパターンが最初に現われるときに開始する。
14.EnableCompare_StartAddr、EnableCompare_StartCycle
GlobalPList、LocalPListに適用されるときにIntrinsic。
子によって継承されない。
これは、EnabelCompare_StartPatternを伴わなければならない。パターン比較が開始することになるパターン内のアドレス又はサイクルを指示する。
15.EnableCompare_StopPattern<pattern>
GlobalPList、LocalPListに適用されるときにIntrinsic。
子によって継承されない。
パターン比較は、指示されるパターンが最初に現われるときに終了する。
16.EnableCompare_StopAddr、EnableCompare_StopCycle
GlobalPList、LocalPListに適用されるときにIntrinsic。
子によって継承されない。
これは、EnableCompare_StopPatternを伴わなければならない。パターン比較が終了することになるパターン内のアドレス又はサイクルを指示する。
17.Skip
PList、Patに適用されるときにReferential。
子によって継承されない。
パターンリストによって支配されるパターン又はサブシーケンス全体がスキップされるようにする。これは、このパターンリスト副ツリーのルートにおいて全てのオプションもスキップさせる。それは、このパターン副ツリーが実行するために存在しなかったかのようにする。
先に説明されたように、或るパターンリストのための実行シーケンスがハードウエアに提示されるとき、ハードウエアは、ソフトウエアが関与することなく、パターンのシーケンスのバーストを生成する。バースト不連続部は、先行するバーストが終了し、新たなバーストが開始される、実行シーケンス内の場所である。上記のオプションリストに示されるように、PreBurst、PostBurst、BurstOff及びBurstOffDeepオプションは、バースト不連続部が生じる場所を制御する。PreBurst及びPostBurstオプションは、以下に記述されるある特定の付加的な規則に対するバースト不連続部サブジェクトを決定する。
1.親リストがPreBurst及びPostBurstオプションを有し、ネストされたリストが同じ対応するオプションを有するとき、バースト不連続部は存在せず、ネストされたリストのPreBurst及びPostBurstオプションは当てはまらない。親リストのPreBurst及びPostBurstを適用するただ1つのバーストだけが存在する。
2.ネストされたリストがバーストオプションを持たないとき、それは、これらのオプションの記述によって親リストと同じPreBurst及びPostBurstオプションを有すること同じであることに留意されたい。結果として、バーストオプションを持たないネストされたリストはバースト不連続部を生じない。
3.上記の規則1が当てはまらず、且つ親リストの開始からネストされたリストの開始までパターン実行シーケンスへの寄与がある場合には、ネストされたリストの開始時にバースト不連続部が存在する。この場合、親リストのPreBurst及びPostBurstは、親リストからのパターン実行シーケンスへのこの寄与に当てはまる。ネストされたリストのPreBurst及びPostBurstは、ネストされたリストに当てはまる。
4.上記の規則1が当てはまらず、且つネストされたリストの終了から親リストの終了までのパターン実行シーケンスへの寄与がある場合には、ネストされたリストの終了時にバースト不連続部が存在する。この場合、親リストのPreBurst及びPostBurstは、親リストからのパターン実行シーケンスへのこの寄与に当てはまる。ネストされたリストのPreBurst及びPostBurstは、ネストされたリストに当てはまる。
5.上記の規則1が当てはまらず、且つネストされたリストから以外の親リストからのパターン実行シーケンスへの寄与がない場合には、親リストのPreBurst及びPostBurstは当てはまらない。ネストされたリストのPreBurst及びPostBurstを適用するただ1つのバーストだけが存在する。
{
Pat q;
PList B;
Pat r;
Pat s;
Grobal C
{
Pat t;
PList D;
};
PList D;
PList E;
};
Global B
{
Pat a;
Pat b;
};
Global D [BurstOff]
{
Pat c;
Pat d;
};
Global E
{
Pat e;
};
zq|ab|zr|zs|t|c|d|c|d|e
1.A上のBurstOffオプションはBによって継承されないので、B内のパターンa及びbはバーストとして動作する。
2.A上のPreBurstオプションはBによって継承されないので、Bによるバースト内のa及びbはzによって前置されない。
3.zによる前置は、aの直接の子であることに起因して実行されるパターン、すなわちパターンq、r及びsの場合にのみ起こる。これらのパターンは、BurstOffオプションを有するAに起因して1パターン長だけであるバースト内にあるかのように1つずつ実行される。BurstOffは、パターンに、1パターン長バーストにおいて個別に実行されることを要求する。それゆえ、PreBurst及びPostBurstオプションは依然として当てはまる。
4.パターンリストDは、その子c及びdが1つずつ実行される固有バーストオフオプションを有する。それは、AからのPreBurst zを継承しない。
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によって継承される。
1.Aの定義上のオプション:[PreBurst x]、[PostBurst y]
2.Cの定義上のオプション:[PreBurst x]、[PostBurst z]
3.任意の他のノード上の他のオプションはない。
xqabrstcdcdey
1.最初のxは、実際には現在のバーストに関連するプレバーストオプションxに等しいので、禁止される。
2.最後のzは、PostBurst zがDに継承されず、zが付加されることができるCから生成されるパターンが存在しないので、禁止される。
1.Aの定義上のオプション:[Skip]、[PreBurst z]、[PostBurst y]
2.rへの参照上のオプション:[Skip]
3.Cの定義上のオプション:[Skip]
zqabscdey
1.r及びCのためのノードはスキップされる。
2.バーストブレークは全く存在しない。
1.Aの定義上のオプション:[mask pin1_pin2]、[PreBurst z]
2.Bの参照上のオプション:[mask pin3]
3.Bの定義上のオプション:[mask pin4]
4.eの参照上のオプション:[mask pin5]
5.任意のノード上の他のオプションはない。
1111111111111 1
2222222222222 2
33 5
44
1.ベンダのハードウエアは、バーストブレークを生じることなく、2つのマスクブロックだけしか収容することができない。eが実行されるまで、2つのマスクブロックはピン{1、2}及びピン{1、2、3、4}である。パターンeがピン{1、2、5}の異なるマスクブロックで到着するとき、ハードウエアはバーストブレークを要求する。
{
Global B [BurstOffDeep]
{
Global C
{
...
};
...
};
...
PList C;
};
Global D
{
PList C;
};
{
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
ユーザは主に、パターンファイルを用いて試験設定を定義することにより、システムとやりとりする。Timing Fileは、これらのパターンのTimingを記述するために用いられる。このファイルは、分解されるべき基礎的な定義のための他のシステムファイル(たとえば、Pin、SpecSelector)を必要とする。さらに、Timing定義において用いられる種々の変数を分解するために用いられるSpec-Selector及びGlobal定義は、複合TestConditionGroupオブジェクトにカプセル化される。Test Planファイルのような、さらに上位のファイルはさらに、このTestConditionGroupインスタンスを使用する。
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;}
}
}
}
*Here we define the
WaveformSelector
component of the TimingMap
to use for the pattern
characters.
Importtim1.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;
}
TestFunctionalTest MyFunctionalTestFast
{
PListParam = patList1;
TestConditionParam = tim2_prod_max;
}
**Two Tests within a Test Plan
using different timing objects
defined earlier
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; }};
};
};
}
**This variable, which defines
the edge placement, is
defined elsewhere and is
dependent on a
SpecificationSet.
{
t_le = 10ns, 14ns, 12ns;
t_te = 30ns, 34ns, 32ns;
...
}
{
TestConditionGroup = prodTmgSpec;
SpecSelector = typ; *
}
TestConditionGroup prodTmp_max
{
TestConditionGroup = prodTmgSpec;
SpecSelector = max; **
};
*This timing uses the
typical specification in the
SpecSelector.
**This timing uses the
max specification in the
SpecSelector.
テスタモジュールの2つのコンポーネントが、波形の生成及びその関連するタイミングに直に関与する。2つのモジュールは、パターン発生器(PG)及びフレームプロセッサ(FP)である。オープンアーキテクチャ試験システムアーキテクチャ内のフレームプロセッサによる波形フォーマッティング及びタイミング発生を例示する簡略化されたブロック図が図10に示される。波形の発生の簡単な説明が以下に与えられる。
その方法は、ピン毎の全てのWaveformTableブロックをテスタ内のLTSにマッピングすることである。テスタハードウエアが4LTSをサポートする場合には、ユーザは最大4つのWaveformTableブロックを定義することができる。各WaveformTableブロックは、テスタデジタルモジュールのために最大n個の波形定義を有することができる。
このセクションはテスタオペレーティングシステム(TOS)の基本動作を記述する。このセクションにおいて考えられる動作は以下のものである。
・システム初期化
・Test Planローディング
・パターンローディング
・Test Planの実行
・個々のTestの実行
一実施形態ではシステムを初期化するために、ある特定の仮定が満たされなければならず、且つある特定の条件が満たされなければならない。以下のサブセクションがこれらを記載する。
関連するシステムソフトウエアコンポーネントのコピーが中央に格納され、その場所がシステムコントローラに知られている。これは、システムコントローラそのものに存在することができるか、又はネットワーク実装ディレクトリを有する(又は別の仕組みを介してSYSCに知られている)他のシステム上に存在することができ、どのような仕組みであっても、システムが機能することができる前に、システムコントローラが使用するために、全てのソフトウエアが入手できなければならない。このソフトウエアは以下のものを含む。
ベンダハードウエア制御(すなわちモジュールソフトウエア)DLL
標準又はユーザ試験クラスDLL
ユーザ試験計画DLL
一旦、上記の仮定及び事前条件が満たされたなら、システム初期化は最初に、以下のようなシステム妥当性検査ステップを開始する。
1.システムコントローラが、システム及びモジュール構成ファイルを読み出し、システムのユーザ指定の意図を初期化する。
2.指定されたシステム構成情報を用いて、システムコントローラは、指定されたサイトコントローラが動作中であり、接触可能であり、しかも準備できている(すなわち、SCMを実行している)ことを確認する。この確認ステップ中にエラーがあれば、システムエラーが引き起こされて、初期化は中止される。
3.その後、システムコントローラは、SITEC−1にあるSCMサービスに、スイッチマトリックスを構成して、全てのハードウエアモジュールにアクセスできるようにすることを指示し、ハードウエア発見を実行するように要求する。
4.SITEC−1におけるSCMサービスは、{vendor,hardware}タプルのための全ての利用可能なモジュールスロット(既知のハードウエアの場所)をポーリングし、{vendor,hardware}タプルのスロットへのマッピングを生成する。したがって、終了時に、このポーリングは、完全なシステム内に存在する完全な1組の{vendor,hardware,slot}結合を特定している。このポーリングの結果はシステムコントローラに送られる。
5.システムコントローラは、上記のハードウエア発見ステップの結果が、モジュール構成ファイル内のユーザ指定の構成と一致することを確認する。この確認ステップ中に何らかのエラーがあれば、システムエラーが引き起こされ、初期化は中止される。
6.その後、システムコントローラは、周知の場所(複数の場合もあり)において環境設定ファイル(複数の場合もあり)からデフォルト環境(モジュールDLLを探すための探索経路、パターンリスト、パターン、試験計画DLL、試験クラスDLL等)をロードする。
7.システムコントローラは、全ての特定されたモジュールソフトウエアDLLが存在することを確実にする。システムコントローラ上で入手できない場合には、可能であるなら、中央記憶装置から検索される。そうでない場合には、システムエラーが引き起こされ、初期化が中止される。
サイト構成、すなわちサイト分割は、利用可能なシステムハードウエアモジュールを種々のサイトに(すなわち、複数のDUTにサービスするために)ソフトウエアレベルで割り当てることを含む。サイト分割情報はソケットファイルにおいて提供されることを思い起こされたい。
1.ソケットが与えられるとき、システムコントローラは最初に、現時点で存在しているシステム分割がソケットに適合するか否か、又は再分割が必要であるか否かを判定する。初期化中のデフォルト分割は、全ての利用可能なモジュールがSITEC−1に接続される分割である。以下の残りのステップは、再分割が必要とされる場合のみ実行される。
2.システムコントローラは各サイトコントローラSCMに構成メッセージを送り、新たなソケットの下でそのために使用可能なDUTサイトの数及び識別でそのものを再構成する。これは一般的な手順であり、1つのサイトコントローラによって制御されるDUTサイトの数が1つである場合を取り扱うことに留意されたい。新たなソケット情報はSCMにも伝達される。
3.各SCMは、もしあれば、実行中のTPSを停止して、新たなTPSを開始し、新たなソケットと、新たなソケットの下でそのために使用可能なDUTサイトの数及び識別とを用いてそれを初期化する。
4.システムコントローラは、どのサイトが、必要とされるシステムモジュールのどのサブセットを必要とするかを判定する。これを行いながら、システムコントローラはサイトのためのハードウエアスロット情報も準備する。サイト毎の最終的な結果は、そのサイトに割り当てられるモジュールDLLに対するスロットのリストである。このサイト特有のリストは、Site Module DLL Slot List(SITE-MDSL)として表される。
5.システムコントローラは適当なSITE-MDSL、及び必要なモジュールDLLを各SCMに提供する。各SCMはさらに、新たに開始されたTPSがこの情報を入手できるようにする。
6.その後、システムコントローラは、適当なサイト‐スロット間接続のために、すなわち、サイト分割作業のために、SITEC-1にSwitch Matrixを構成するように要求する。
7.サイト1〜n上のTPSは、そのSITE-MDSLにおいて指定されるDLLをロードする。これらの各DLLは、initialize()という名前の関数を有し、その関数はスロット番号のアレイを取得する。TPSは、そのモジュールタイプのための適当なスロットリストでinitialize()をコールする。この時点で誤動作があれば、システムエラーが引き起こされて、初期化が中止される。initialize()メソッドは以下のことを行う。
a.標準インターフェースIXXXModuleに基づいて具体的なクラスを作成する。たとえば、或るデジタルモジュールに関連するDLLは、それが関連する各スロットにサービスするために、1つのIPinModuleベースオブジェクトを作成する。
b.インターフェースIResourceに基づいて、そのモジュール内の「資源ユニット」毎に1つの複数の具体的なクラスを作成する。再び、或るデジタルモジュールの場合、各IPinModuleベースオブジェクトは、デジタルモジュールによって占有されるスロットのコレクション内の全てのピンのためのITesterPinベースオブジェクトを作成する。
8.その後、サイト1〜n上のTPSは、ロードされた各モジュールDLLにおいてgetXXXModule()をコールし、モジュール内容情報を検索する。
9.getXXXModule()へのコールの度に、IModuleポインタとして<VendorHWType>Moduleクラスオブジェクトが返される(たとえば、AdvantestPinModule)。そのような各IModuleポインタはTPSによってキャッシュされ、TPSは、フレームワーク/ユーザコードがこれらを入手できるようにする。IModule、IResource等のコレクションは永続的である(少なくともTPSの寿命にわたって)ことに留意されたい。
10.一旦、上記のステップが完了したなら、TPSは、その割り当てられた(既知の)ポートにおいて、listen()を開始する。これは、TPSが標準(すなわちサイト分割された)動作を開始する「準備ができている」ことを、システムコントローラに伝える。
このセクションは、ユーザTest Plan DLLがサイトコントローラ上にロードされる(1つ又は複数のDUT試験のために)ステップを記述する。
1.システムコントローラは最初に、試験計画DLLをその自らの処理空間内にロードし、それに、関連するソケットファイル及びDUTタイプ識別子を問い合わせる。この情報を用いて、この試験計画を実行するサイト(複数の場合もあり)、それゆえこの試験計画がロードされることになるサイトコントローラ(複数の場合もあり)が特定される。
2.その後、システムコントローラは、その試験計画に関連するソケット情報を用いて、先に略述されたような再分割プロセスを開始する。
3.システムコントローラは、試験計画DLLから、試験計画によって用いられる試験クラスDLLのリストを抽出し、一旦、システムコントローラが、TPSが標準(すなわち、サイト分割された)動作を開始する準備ができていることを確認したなら、試験クラスDLLを、そして最後に、試験Plan DLLそのものを適当なTPSに送出する。
4.TPSはLoadLibrary()をコールして、それを処理空間にロードする。それは、DLLにおいて周知の関数をコールして、それがサービスするサイト(すなわちDUT)の数と同じ数の試験計画オブジェクトを作成する。
5.TPSは、必要なテスタフレームワークオブジェクトで試験計画オブジェクト(複数の場合もあり)を初期化する。初期化中に、TPSは、試験計画オブジェクト(複数の場合もあり)によって用いられる試験クラスに適したDLLを処理空間にロードし、試験クラスインスタンスを作成する。
6.TPSはシステムコントローラに対する通信チャネルを試験計画オブジェクト(複数の場合もあり)に設定する。
7.システムコントローラはTPSと通信し、試験計画オブジェクト(複数の場合もあり)のためのプロキシを構築する。
予め定義されたフローロジックに従って試験計画内の全ての試験を実行するための方法は以下のとおりである。
1.ユーザのアプリケーションがRunTestPlanメッセージをTPSに送信する。TPSはExecutingTestPlanメッセージを全ての接続されたアプリケーションに送る。その後、TPSはTest Plan上でexecute()をコールする。
2.1つのサイトコントローラで複数のDUTを試験することは、そのサイトコントローラ上で、DUT当たり1つの複数のスレッドを用いて実行される。各スレッドは、同じ試験計画オブジェクトの異なる個別のインスタンスを実行する。この場合には、モジュール制御ソフトウエアDLLを複数のDUTにわたって共有することができるので、DUT識別子パラメータを取得するために、ハードウエア通信のためのモジュールコマンドが必要とされる。
3.試験計画オブジェクトは、そのコレクション内の各試験にわたって繰り返され(別法では、そのFlowオブジェクトに、フローロジックに従って各試験を処理するように指示し)、preExec()、execute()及びpostExec()をコールする。
4.各試験が実行されるとき、全ての接続されるアプリケーションに対してステータスメッセージが返送される。
ユーザは、全ての試験ではなく、1つの試験計画内のただ1つの試験を実行したい場合もある。ただ1つの試験を実行する場合、その方法は以下のとおりである。
1.ユーザアプリケーションがRunTestメッセージをTPSに送信する。TPSはExecutingTestメッセージを全ての接続されるアプリケーションに送る。その後、TPSは、Test PlanにおいてexecuteTest()をコールし、実行するための試験を指定する。
2.Test Planオブジェクトは、その試験オブジェクトにおいてpreExec()、execute()及びpostExec()をコールすることにより、指定された試験を実行する。
3.その試験が実行されるとき、それは全ての接続されるアプリケーションにステータスメッセージを返送する。
本発明の一実施形態のオープンアーキテクチャ試験システムは、試験システムフレームワークレベルにおいて必要最低限のインターフェースを用いる。試験システムフレームワークは、1組の標準インターフェースに従うベンダモジュールで動作するように設計される。モジュール製造業者が新たなモジュールコンポーネントを試験システムに組み込むときはいつでも、新たなコンポーネントは、必要に応じて、試験システムに所定の標準インターフェースを提供することが好ましい。これにより、プラグ・アンド・プレイのように、システムにベンダモジュールをシームレスに組み込むことができる。
1.それは、ダイナミックリンクライブラリ(DLL)の形で提供される。上記のコンポーネントはそれぞれ、モジュールで使用するために、且つメンテナンスしやすくするために、別個のDLLで存在する。さらに、以下のことが要求される。
a.モジュールDLLは、標準システムモジュールDLLインターフェースを実装することが好ましく、そのインターフェースは、モジュールタイプ、エキスポートされる資源等の固有のモジュール情報を検索するための基本インターフェースである。
b.モジュールDLLはただ1つのモジュールタイプだけをエキスポートすることができる。
2.そのDLLのバージョンはCCRにおいてベンダによって記述される。
3.ユーザは、システムプロファイル内にDLLのバージョンを含み、システムプロファイルは特定のシステムソフトウエア構成を定義するために必要とされる情報の全コレクションである。これにより、ドライバ、エミュレータ、較正、診断及びパターンコンパイラの実行可能コンポーネントのためのDLL仕様が、システムモジュール構成ファイル(MCF)及びシステムユーティリティズ構成ファイル(UCF)において生成される。これらのファイルは、ロードされるべきコンポーネントを見つけるために、ランタイム中にシステムによって用いられる。
ハードウエアモジュールタイプとその対応するソフトウエアオブジェクトとの間の関係がIModuleインターフェース1402によって定義される。言い換えると、IModuleインターフェースは、特定のハードウエアモジュールタイプを表すシステム標準インターフェースを実装し、1つのサイトコントローラに接続される、そのモジュールタイプの個々のユニットを包含する。IModuleインターフェース1402は、モジュール情報、検索資源及び資源グループを入手するために、ユーザレベルメソッドを宣言する。ベンダモジュールによって提供されるベンダ特有の機能を利用するために、ユーザはベンダレベルにおいてこのインターフェースを適用することができる。一実施形態では、IModuleインターフェース1402は以下のメソッドを含む。
・getResource():このメソッドは資源名によってモジュール資源を検索する。
・getResources():このメソッドは特定のタイプの全てのモジュールインスタンス化資源を検索する。
・getResourceGroups():このメソッドは特定のタイプの全てのモジュールインスタンス化資源グループを検索する。
・getResourceGroup():このメソッドはその名前によって既存の資源グループを検索する。
ハードウエア資源(又は略して資源)の仕様を用いて、全てのモジュールのためにシステムフレームワークによってサポートされることができるように、ハードウエアモジュール機能が記述される。1つの資源は、ただ1つの個別のオブジェクトとして制御することができる1つ又は複数の機能ハードウエアエンティティの論理的なコレクションである。通常、モジュールによって1つの資源ユニットが提供される。資源ユニットの1つの例は、システムモジュール接続イネーブラ(MCE)のただ1つの出力ポートに接続されるDM250MHzボードによって提供されるただ1つのデジタルテスタピンである。ハードウエア資源ユニットとその対応するソフトウエアオブジェクトとの間の関係は、ソフトウエアオブジェクトが特定の資源タイプのただ1つの論理ユニットを表す資源インターフェースを実装するということである。
・getAttributeCache():このメソッドはこの資源に関連する属性キャッシュを検索する。
・getName():このメソッドはこのIResourceの名前を検索する。
・getChannelID():このメソッドは、その資源のためのHWチャネルIDを検索する。
・getPortID():このメソッドは、その資源のためのスイッチマトリックスポートIDを検索する。
・getType():このメソッドは資源のTPLタイプを検索する(たとえば、「Digital.dpin」等)。
・getConnetedDUTPins():このメソッドは、1組の接続されるDUTピン名を検索する(共有される資源の場合に有用)。
・getModule():このメソッドは、このIResourceを作成したIModuleへのポインタを検索する。
・getAllAttributes():このメソッドは、この資源のための全ての属性のための名前/タイプ情報のリストを検索する。
・getAllAttributeValues():このメソッドは、この資源のための全ての属性のための完全な情報のリストを検索する。
・getAttribIntVal():このメソッドは、1つの属性の整数値を検索する(適当な場合)。
・getAttribUIntVal():このメソッドは、1つの属性の符号なし整数値を検索する(適当な場合)。
・getAttribDblVal():このメソッドは、1つの属性の2倍値を検索する(適当な場合)。
IResourceGroupインターフェース1406は、1組のIResourceの集合的な挙動を表す。それは、ユーザがIResourceのコレクションを指定し、その後、そのコレクションをただ1つの資源ユニットとして使用できるようにする、IModuleに対して公開されるインターフェースである。IResourceGroupは、IResourceGroupを作成するために用いられる1組のIResourceを含むが、それは、全体として、そのコレクションに対して統一されたプログラム用インターフェースを提供する。たとえば、或る特定のベンダは、或るハードウエアによってサポートされる仕組みを用いて、各メンバにおいて属性設定メソッドを個別にコールすることなく、全てのIResourceのメンバに同時に、IResourceGroup上で属性設定コールを報知することができる。
DUT-pin-group-name, resource-type, vendor-ID, module-ID
・getName():このメソッドはこのグループの名前を検索する。
・getMembers():このメソッドは、このグループを含むIResourceのコレクションを検索する。
・getModule():このメソッドは、このグループを作成したIModuleへのポインタを検索する。
・getType():このメソッドは、このグループを含むIResourceのTPLタイプ、たとえば「Digital.dpin」等を検索する。
・getAttributeCache():このメソッドは、このグループのための資源タイプのための属性キャッシュを検索する。
・getAllAttributes():このメソッドは、このグループのための資源タイプのための全ての属性のための名前/タイプ情報のリストを検索する。
IPatternListModuleインターフェース1408はIModuleインターフェースを特化したものであり、試験パターンオブジェクトの操作をサポートするハードウエアモジュールを表す。それは以下のメソッドを含む。
・getNumberOfLoadedPatterns():このメソッドはロードされるパターンの数を検索する。
・getPatternIDs():このメソッドは、ロードされるパターンIDアレイをゲットする。
・getPatternListIDs():このメソッドは、モジュール内にロードされるパターンリストのアレイをゲットする。
IDomainModuleインターフェース1410は、IPatternListModuleインターフェース1408を特化したものであり、時間ドメインのために必要とされる機能をサポートするハードウエアモジュール(特定の周波数においてクロック供給される1組の資源等)を表す。それは以下のメソッドを実装する。
・getVendorDomain():このメソッドは、識別子によってベンダドメインオブジェクトを検索する。
・getVendorDomain():このメソッドは、名前によってベンダドメインオブジェクトを検索する。
・getVendorDomains():このメソッドは、このモジュールによってインスタンス化される全てのベンダドメインオブジェクトのコレクションを検索する。
・getVendorDomainsForPattern():このメソッドは、所与のパターンに関連する全てのベンダドメインのコレクションを検索する。
ICyclizedModuleインターフェース1412は、サイクライズモジュールのためのインターフェースを提供する。それは以下のメソッドを含む。
・getCyclizedAddressFailMemory():このメソッドは、モジュールアドレス故障メモリオブジェクトポインタを入手する。
・getCyclizedFailMemory():このメソッドは、モジュール故障メモリオブジェクトポインタを入手する。
・getCyclizedResource():このメソッドは、その名前によってサイクライズ資源を検索する。
・getCyclizedResourceGroup():このメソッドは、その名前によって資源グループを検索する。
ICyclizedResourceインターフェース1414は、サイクライズ資源に特有の機能で、標準IResourceインターフェースを拡張する。サイクライズ資源は、システムタイミング、タイミングマップ及びサイクライズデジタルパターンデータに関連するコンポーネントのような、タイミング属性を有する要素を含む。ICyclizedResourceは、ICyclizedAttributeCacheをエキスポートする機能を提供し、システムフレームワークが、システムタイミング及びタイミングマップ属性のためのTCM設定で正常に動作できるようにする。さらに、ICyclizedResourceによって、ユーザは、使用時にタイミング及びタイミングマップ属性を検索できる。
・getCyclizedAttributeCache():このメソッドは、ハードウエアにタイミング及びタイミングマップ属性を適用できるようにするキャッシュオブジェクトを検索する。
・getTimingData():このメソッドは、資源ユニットにおいて現在セットされているタイミングデータを検索する。
・getTimingMapData():このメソッドは、資源において現在セットされているタイミングマップ関連属性を検索する。
・setTimingData():このメソッドは、このサイクライズデジタル資源においてタイミング関連属性をセットする。これは、TPLタイミング言語において定義されるような、単一の波形の全ての内容をセットする。
・setTimingMapData():このメソッドは、このサイクライズデジタル資源においてタイミングマップ関連属性をセットする。
このICyclizedResourceGroupインターフェース1416は、ICyclizedResourceをグループ化するための特化したIResourceGroupインターフェースを提供する。それは以下のメソッドを含む。
・getCyclizedAttributeCache():このメソッドは、ハードウエアにタイミング及びタイミングマップ属性を適用できるようにするキャッシュオブジェクトを検索する。
・setTimingData():このメソッドは、このサイクライズデジタル資源グループにおいてタイミング関連属性をセットする。これは、TPLタイミング言語において定義されるような、単一の波形の全ての内容をセットする。
・setTimingMapData():このメソッドは、このサイクライズデジタル資源グループにおいてタイミングマップ関連属性をセットする。
ベンダモジュールのドライバDLLは、それを必要とするサイトコントローラ上に、試験システムによって自動的にロードされる。この文脈では、用語「モジュールDLL」はモジュールドライバDLLを指している。一実施形態において、モジュール初期化フローが以下に示されており、それは、システム及びサイトコントローラ(複数可)上のメインサービスプロセスが開始された後に生じる。オフラインモードでは、シミュレーションフレームワーク実行可能プログラム(Simulated Tester、又はSim Tester)が開始された後に、モジュール起動(bring-up)が開始する。
1.システムコントローラは自ら初期化して、サイトコントローラとの接続を確立する。
2.システムコントローラはシステムMCFをロードする。
3.システムコントローラは、マスターサイトコントローラ(すなわち、サイトコントローラ1)においてハードウエア発見のプロセスを開始する。そのサイトコントローラは、システムモジュール接続イネーブラの入力ポート1に接続される。このハードウエア情報を用いて、システムコントローラ上にシステムハードウェアインベントリファイルが作成される。
4.システムコントローラは、ハードウエア発見を通して得られる情報に対してMCFの妥当性を検査する。
5.その後、システムコントローラは、以下のように、全てのモジュールソフトウエアの妥当性検査を実行する。
a.システムコントローラは、そのようなDLLのための探索経路を用いて、MCFにおいて指定されるモジュールDLLを見つける。
b.システムコントローラは、各モジュールDLLをロードする(モジュールDLLはそのインターフェースを実装することが好ましい)。
c.システムコントローラは、(DLLによってエキスポートされる標準的なメソッドを用いて)そのモジュールのためにMCFにおいて宣言される資源がそのモジュールによって作成できることを確認する。
6.その後、システムコントローラは、モジュール構成情報で全てのサイトコントローラ(マスター以外)をポピュレートする。この情報は、モジュールオブジェクトを構成するために後に用いられる。
7.システムコントローラは、システムのデフォルト分割のための準備をする(全てのモジュールがマスターサイトコントローラに接続される)。この状態はシステム較正のために変更される。
別の実施形態では、非デフォルトのシステム分割を成功に導くイベントのシーケンスが以下に示される。分割情報はソケットファイルにおいて指定されるので、適当なソケットファイルが読み出され、そのソケットファイルに基づくソケットオブジェクトが作成されたものと仮定される。
1.システムコントローラは、マスターサイトコントローラに、ソケットにおいて指定された分割に従ってシステムMCEを構成するように指示する。
2.その後、各サイトコントローラは、モジュールDLLをロードし、モジュールオブジェクトを構成する。各モジュールオブジェクトは標準インターフェースIModuleを実装することが好ましい。そのプロセスは以下のとおりである。
a.モジュールDLLはシステムコントローラからサイトコントローラに転送される。
b.モジュールDLLはサイトコントローラサービスプロセスの処理空間内にロードされる。
c.モジュールDLLインターフェース上に、IModuleオブジェクトが作成される。ベンダは、ベンダ特有のオブジェクトの作成のための責任を負う。このステップでは、ベンダは、必要とされる任意の内部初期化ステップも実行する。
3.各サイトコントローラは、initialize()メソッドをコールすることにより、先に作成されたIModuleオブジェクトを初期化する。このメソッドのためのパラメータは、ソケットオブジェクトへの参照、MCFに記述される任意のベンダ特有のデータへの参照、及び試験されるDUTの識別子のリスト(並列試験環境の場合)への参照として用いられる。このステップでは、IModuleオブジェクトは、試験システムが入手することができるIResourceユニットオブジェクトを作成し、初期化する。
1.クライアントが、そのpostExec()メソッドにおいて、ピンA0及びA1を含むDUTピングループG0のために、ハードウエア上にセットされるピン属性の現在値のデータロギングを実行する必要がある。
2.クライアントは、1つのサイトコントローラ上で実行されており、試験計画から、DUTピングループG0に対応する信号(それは、DUTピンと、接続されるハードウエア資源ユニットとの間の関係をカプセル化する、フレームワーク提供のオブジェクトである)を検索する。
3.クライアントは、メソッドSignal::getResources()を用いて、G0のための信号から、IResourceGroupポインタを検索する。
4.クライアントは、IResourceGroup::getMembers()メソッドを用いて、その中にあるIResource(すなわち、DUTピンA0及びA1に接続される資源ユニット)を抽出する。
5.サイクライズモジュール及び資源が用いられたなら、クライアントはC++ dynamic_cast<>演算子を用いて、IResourceポインタをICyclizedResourceポインタにキャストする。
6.各ICyclizedResourceポインタを通して、クライアントは、たとえば、ICyclizedResource::getTimingData()メソッドを用いることによりタイミングデータを検索する。
7.クライアントは、先に検索されたタイミング属性値をデータロギングする。
Claims (26)
- モジュール式試験システムに試験モジュールを組み込むための方法であって、
コントローラで少なくとも1つの試験モジュール及びその対応する被試験デバイス(DUT)を制御し、
モジュール制御フレームワークで、ベンダ提供試験モジュールと前記モジュール式試験システムとの間に標準モジュール制御インターフェースを確立し、
前記ベンダ提供試験モジュール及び対応するベンダ提供制御ソフトウエアモジュールをインストールし、該ベンダ提供制御ソフトウエアモジュールは複数のベンダ提供モジュール制御コンポーネントに編成され、
前記モジュール制御フレームワーク及び前記複数のベンダ提供モジュール制御コンポーネントに基づいて、前記モジュール式試験システムを構成し、
前記モジュール制御フレームワークを用いて、前記複数のベンダ提供モジュール制御コンポーネントに従って、前記ベンダ提供試験モジュールにアクセスすること
を含む、モジュール式試験システムに試験モジュールを組み込むための方法。 - 前記モジュール制御フレームワークは、
前記ベンダ提供試験モジュールのハードウエアモジュールタイプを表すためのモジュールクラスと、
前記ベンダ提供試験モジュールの特定の資源タイプの論理ユニットを表すための資源クラスと、
統一されたインターフェースを有する個々の資源ユニットのグループを表すための資源グループクラスと
を含む、請求項1に記載の方法。 - 前記モジュール制御フレームワークは、
パターン及びパターンリストをサポートするためのパターンリストモジュールクラスと、
ベンダドメインオブジェクトを検索するためのドメインモジュールクラスと、
サイクライズ資源を検索するためのサイクライズモジュールクラスと
をさらに含む、請求項2に記載の方法。 - 前記モジュール制御フレームワークは、
タイミング属性を有する、ベンダ提供試験モジュールをサポートするためのサイクライズ資源クラスと、
個々のサイクライズ資源ユニットのグループを表すサイクライズ資源グループクラスと
をさらに含む、請求項2に記載の方法。 - 前記モジュール制御フレームワークは、
ベンダ提供ハードウエア資源のカスタム構成をサポートするためのシステム資源定義言語と、
ベンダ提供特殊用途の資源を格納するためのシステム資源定義ファイルと
をさらに含む、請求項1に記載の方法。 - 前記システム資源定義言語は、
対応する1組の資源タイプのための1組の資源名と、
前記対応する1組の資源タイプのための1組のパラメータ名及びタイプと
を定義するために用いられる、請求項5に記載の方法。 - 前記複数のベンダ提供モジュール制御コンポーネントは、
資源記述コンポーネントと、
ドライバコンポーネントと、
診断コンポーネントと、
較正コンポーネントと、
エミュレーションコンポーネントと
を含む、請求項1に記載の方法。 - 前記複数のベンダ提供モジュール制御コンポーネントはさらに、
パターンコンパイラコンポーネントと、
モジュール特有のコンポーネントと
を含む、請求項7に記載の方法。 - 前記複数のベンダ提供モジュール制御コンポーネントは、ダイナミックリンクライブラリの形式において実行可能なコンポーネントである、請求項1に記載の方法。
- 前記複数のベンダ提供モジュール制御コンポーネントはコンポーネント構成レコードにおいて提供される、請求項1に記載の方法。
- 前記モジュール式試験システムを構成することは、
システムコントローラを初期化し、
前記システムコントローラと前記少なくとも1つのサイトコントローラとの間に接続を確立し、
システムモジュール構成ファイルを前記システムコントローラにロードし、
前記モジュール式試験システムに接続されるハードウエアデバイスを発見し、
発見されたハードウエア情報を、前記システムコントローラ上のハードウエアインベントリファイルに格納し、
前記ハードウエアインベントリファイルに対して、前記システムモジュール構成ファイルの妥当性を検査し、
前記ベンダ提供制御ソフトウエアモジュールの妥当性を検査し、
前記システムモジュール構成ファイルで前記少なくとも1つのサイトコントローラをポピュレートし、
前記モジュール式試験システムを分割すること
を含む、請求項1に記載の方法。 - 前記ベンダ提供制御ソフトウエアモジュールの妥当性を検査する方法であって、
前記システムモジュール構成ファイルにおいて指定されるモジュールダイナミックリンクライブラリを特定し、
前記モジュールダイナミックリンクライブラリをロードし、
前記システムモジュール構成ファイルにおいて宣言された資源が前記対応するベンダ提供制御ソフトウエアモジュールによって作成されることを確認すること
を含む、請求項11に記載の方法。 - 前記モジュール式試験システムを分割することは、
ソケットファイルを読み出し、該ソケットファイルはユーザ指定のシステム分割情報を含み、
前記ソケットファイルに従って、システムモジュール接続イネーブラを構成し、
各サイトコントローラにおいて、対応するモジュールダイナミックリンクライブラリをロードし、
前記対応するモジュールダイナミックリンクライブラリに従って、標準モジュール制御インターフェースを作成し、
各サイトコントローラにおいて前記標準モジュール制御インターフェースを初期化すること
を含む、請求項11に記載の方法。 - モジュール式試験システムであって、
少なくとも1つの試験モジュール及びその対応する被試験デバイス(DUT)を制御するためのコントローラと、
ベンダ提供試験モジュールと該モジュール式試験システムとの間に標準モジュール制御インターフェースを確立するためのモジュール制御フレームワークと、
該ベンダ提供制御ソフトウエアモジュールは複数のベンダ提供モジュール制御コンポーネントに編成され、前記ベンダ提供試験モジュール及び対応するベンダ提供制御ソフトウエアモジュールをインストールするための手段と、
前記モジュール制御フレームワーク及び前記複数のベンダ提供モジュール制御コンポーネントに基づいて、該モジュール式試験システムを構成するための手段と、
前記モジュール制御フレームワークを用いて、前記複数のベンダ提供モジュール制御コンポーネントに従って、前記ベンダ提供試験モジュールにアクセスするための手段と
を備える、モジュール式試験システム。 - 前記モジュール制御フレームワークは、
前記ベンダ提供試験モジュールのハードウエアモジュールタイプを表すためのモジュールクラスと、
前記ベンダ提供試験モジュールの特定の資源タイプの論理ユニットを表すための資源クラスと、
統一されたインターフェースを有する個々の資源ユニットのグループを表すための資源グループクラスと
を含む、請求項14に記載のシステム。 - 前記モジュール制御フレームワークは、
パターン及びパターンリストをサポートするためのパターンリストモジュールクラスと、
ベンダドメインオブジェクトを検索するためのドメインモジュールクラスと、
サイクライズ資源を検索するためのサイクライズモジュールクラスと
をさらに含む、請求項15に記載のシステム。 - 前記モジュール制御フレームワークは、
タイミング属性を有する、ベンダ提供試験モジュールをサポートするためのサイクライズ資源クラスと、
個々のサイクライズ資源ユニットのグループを表すサイクライズ資源グループクラスと
をさらに含む、請求項15に記載のシステム。 - 前記モジュール制御フレームワークは、
ベンダ提供ハードウエア資源のカスタム構成をサポートするためのシステム資源定義言語と、
ベンダ提供特殊用途の資源を格納するためのシステム資源定義ファイルと
をさらに含む、請求項14に記載のシステム。 - 前記システム資源定義言語は、
対応する1組の資源タイプのための1組の資源名と、
前記対応する1組の資源タイプのための1組のパラメータ名及びタイプと
を定義するために用いられる、請求項18に記載のシステム。 - 前記複数のベンダ提供モジュール制御コンポーネントは、
資源記述コンポーネントと、
ドライバコンポーネントと、
診断コンポーネントと、
較正コンポーネントと、
エミュレーションコンポーネントと
を含む、請求項14に記載のシステム。 - 前記複数のベンダ提供モジュール制御コンポーネントはさらに、
パターンコンパイラコンポーネントと、
モジュール特有のコンポーネントとを含む、請求項20に記載のシステム。 - 前記複数のベンダ提供モジュール制御コンポーネントは、ダイナミックリンクライブラリの形式において実行可能なコンポーネントである、請求項14に記載のシステム。
- 前記複数のベンダ提供モジュール制御コンポーネントはコンポーネント構成レコードにおいて提供される、請求項14に記載のシステム。
- 前記モジュール式試験システムを構成するための前記手段は、
システムコントローラを初期化するための手段と、
前記システムコントローラと前記少なくとも1つのサイトコントローラとの間に接続を確立するための手段と、
システムモジュール構成ファイルを前記システムコントローラにロードするための手段と、
前記モジュール式試験システムに接続されるハードウエアデバイスを発見するための手段と、
発見されたハードウエア情報を、前記システムコントローラ上のハードウエアインベントリファイルに格納するための手段と、
前記ハードウエアインベントリファイルに対して、前記システムモジュール構成ファイルの妥当性を検査するための手段と、
前記ベンダ提供制御ソフトウエアモジュールの妥当性を検査するための手段と、
前記システムモジュール構成ファイルで前記少なくとも1つのサイトコントローラをポピュレートするための手段と、
前記モジュール式試験システムを分割するための手段と
を備える、請求項14に記載のシステム。 - 前記ベンダ提供制御ソフトウエアモジュールの妥当性を検査するための前記手段は、
前記システムモジュール構成ファイルにおいて指定されるモジュールダイナミックリンクライブラリを特定するための手段と、
前記モジュールダイナミックリンクライブラリをロードするための手段と、
前記システムモジュール構成ファイルにおいて宣言された資源が前記対応するベンダ提供制御ソフトウエアモジュールによって作成されることを確認するための手段と
を備える、請求項24に記載のシステム。 - 前記モジュール式試験システムを分割するための前記手段は、
ソケットファイルを読み出すための手段であって、該ソケットファイルはユーザ指定のシステム分割情報を含む、読み出すための手段と、
前記ソケットファイルに従って、システムモジュール接続イネーブラを構成するための手段と、
各サイトコントローラにおいて、対応するモジュールダイナミックリンクライブラリをロードするための手段と、
前記対応するモジュールダイナミックリンクライブラリに従って、標準モジュール制御インターフェースを作成するための手段と、
各サイトコントローラにおいて前記標準モジュール制御インターフェースを初期化するための手段と
を備える、請求項24に記載のシステム。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US57357704P | 2004-05-22 | 2004-05-22 | |
US10/917,916 US7184917B2 (en) | 2003-02-14 | 2004-08-13 | Method and system for controlling interchangeable components in a modular test system |
PCT/JP2005/009815 WO2005114240A1 (en) | 2004-05-22 | 2005-05-23 | Method and system for controlling interchangeable components in a modular test system |
Publications (2)
Publication Number | Publication Date |
---|---|
JP3890079B1 true JP3890079B1 (ja) | 2007-03-07 |
JP2008519248A JP2008519248A (ja) | 2008-06-05 |
Family
ID=34968283
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2006519572A Expired - Fee Related JP3890079B1 (ja) | 2004-05-22 | 2005-05-23 | モジュール式試験システムにおける交換可能コンポーネントを制御するための方法及びシステム |
Country Status (5)
Country | Link |
---|---|
US (1) | US7184917B2 (ja) |
EP (1) | EP1756603B1 (ja) |
JP (1) | JP3890079B1 (ja) |
TW (1) | TWI363879B (ja) |
WO (1) | WO2005114240A1 (ja) |
Families Citing this family (70)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6970794B2 (en) | 2002-09-19 | 2005-11-29 | Marvell International Ltd. | Semiconductor having reduced configuration pins and method thereof |
US7197417B2 (en) | 2003-02-14 | 2007-03-27 | Advantest America R&D Center, Inc. | Method and structure to develop a test program for semiconductor integrated circuits |
US7437261B2 (en) * | 2003-02-14 | 2008-10-14 | Advantest Corporation | Method and apparatus for testing integrated circuits |
US7197416B2 (en) * | 2004-05-22 | 2007-03-27 | Advantest America R&D Center, Inc. | Supporting calibration and diagnostics in an open architecture test system |
US7430486B2 (en) * | 2004-05-22 | 2008-09-30 | Advantest America R&D Center, Inc. | Datalog support in a modular test system |
US7210087B2 (en) * | 2004-05-22 | 2007-04-24 | Advantest America R&D Center, Inc. | Method and system for simulating a modular test system |
GB0427670D0 (en) * | 2004-12-16 | 2005-01-19 | Ibm | Methods, systems and computer program products for loading a resource |
US8214800B2 (en) * | 2005-03-02 | 2012-07-03 | Advantest Corporation | Compact representation of vendor hardware module revisions in an open architecture test system |
US7516381B2 (en) * | 2005-04-21 | 2009-04-07 | Panasonic Corporation | Integrated circuit test system |
US7440863B2 (en) * | 2005-04-29 | 2008-10-21 | Agilent Technologies, Inc. | Integrated tool for compliance testing within an enterprise content management system |
JP4427002B2 (ja) * | 2005-05-20 | 2010-03-03 | 株式会社アドバンテスト | 半導体試験用プログラムデバッグ装置 |
US20090214650A1 (en) * | 2006-02-01 | 2009-08-27 | Alkermes, Inc. | Methods of Treating alcoholism and alcohol related disorders using combination drug therapy and swellable polymers |
US7558770B2 (en) * | 2006-08-23 | 2009-07-07 | International Business Machines Corporation | Method and system to detect application non-conformance |
US8024721B2 (en) * | 2006-09-01 | 2011-09-20 | Sap Ag | System and method for implementing a safe framework |
US8079023B2 (en) * | 2007-03-22 | 2011-12-13 | Microsoft Corporation | Typed intermediate language support for existing compilers |
US7640132B2 (en) * | 2007-04-23 | 2009-12-29 | Advantest Corporation | Recording medium and test apparatus |
US8060891B2 (en) * | 2007-06-29 | 2011-11-15 | Microsoft Corporation | Management of external hardware appliances in a distributed operating system |
US20090013218A1 (en) * | 2007-07-02 | 2009-01-08 | Optimal Test Ltd. | Datalog management in semiconductor testing |
US8131387B2 (en) * | 2007-08-09 | 2012-03-06 | Teradyne, Inc. | Integrated high-efficiency microwave sourcing control process |
CN101493474B (zh) * | 2008-01-22 | 2012-03-21 | 致茂电子股份有限公司 | Ic元件检测机台用模块化程序组件 |
US7650255B2 (en) * | 2008-05-02 | 2010-01-19 | Texas Instruments Incorporated | Automatic selective retest for multi-site testers |
EP2321751A4 (en) * | 2008-07-07 | 2014-03-05 | Quali Systems Ltd | SYSTEM AND METHOD FOR HARDWARE SEQUENCING AND AUTOMATIC SOFTWARE OF COMPUTER-AIDED DESIGN (CAD) FUNCTIONAL TESTING |
US8078424B2 (en) * | 2008-09-29 | 2011-12-13 | Advantest Corporation | Test apparatus |
TWI381176B (zh) * | 2008-12-05 | 2013-01-01 | Hon Hai Prec Ind Co Ltd | 電子裝置測試裝置及測試方法 |
US8112249B2 (en) * | 2008-12-22 | 2012-02-07 | Optimaltest Ltd. | System and methods for parametric test time reduction |
JP5153670B2 (ja) * | 2009-01-30 | 2013-02-27 | 株式会社アドバンテスト | 診断装置、診断方法および試験装置 |
US8274544B2 (en) * | 2009-03-23 | 2012-09-25 | Eastman Kodak Company | Automated videography systems |
US8237771B2 (en) * | 2009-03-26 | 2012-08-07 | Eastman Kodak Company | Automated videography based communications |
JPWO2011001462A1 (ja) * | 2009-06-29 | 2012-12-10 | 株式会社アドバンテスト | 試験装置 |
US20110012902A1 (en) * | 2009-07-16 | 2011-01-20 | Jaganathan Rajagopalan | Method and system for visualizing the performance of applications |
KR101028359B1 (ko) * | 2009-12-10 | 2011-04-11 | 주식회사 이노와이어리스 | 스크립트를 이용한 dut 자동화 테스트 장치 |
CN102375795B (zh) * | 2010-08-25 | 2013-12-25 | 安凯(广州)微电子技术有限公司 | 一种接口转换装置及转换方法 |
US8923277B1 (en) * | 2010-12-15 | 2014-12-30 | Juniper Networks, Inc. | Methods and apparatus related to flexible physical interface naming in a distributed switch fabric system |
US8839057B2 (en) * | 2011-02-03 | 2014-09-16 | Arm Limited | Integrated circuit and method for testing memory on the integrated circuit |
CN102567205B (zh) * | 2012-01-05 | 2014-12-17 | 中国铁路总公司 | 列车网络控制软件仿真测试系统及仿真测试装置 |
KR101291817B1 (ko) | 2012-04-26 | 2013-07-31 | 비티에스테크놀로지스(주) | 요구사항 모델 기반 테스트 케이스 자동 생성 시스템 및 방법 |
CN103488615B (zh) * | 2012-06-12 | 2016-08-24 | 北汽福田汽车股份有限公司 | 一种软硬件接口定义的源文件自动生成方法和装置 |
US9217772B2 (en) * | 2012-07-31 | 2015-12-22 | Infineon Technologies Ag | Systems and methods for characterizing devices |
US9529704B2 (en) | 2012-09-07 | 2016-12-27 | Aai Corporation | Graphical conversion between test program languages |
US8789006B2 (en) * | 2012-11-01 | 2014-07-22 | Nvidia Corporation | System, method, and computer program product for testing an integrated circuit from a command line |
US11009550B2 (en) | 2013-02-21 | 2021-05-18 | Advantest Corporation | Test architecture with an FPGA based test board to simulate a DUT or end-point |
US10162007B2 (en) * | 2013-02-21 | 2018-12-25 | Advantest Corporation | Test architecture having multiple FPGA based hardware accelerator blocks for testing multiple DUTs independently |
US10161993B2 (en) | 2013-02-21 | 2018-12-25 | Advantest Corporation | Tester with acceleration on memory and acceleration for automatic pattern generation within a FPGA block |
US9952276B2 (en) | 2013-02-21 | 2018-04-24 | Advantest Corporation | Tester with mixed protocol engine in a FPGA block |
US9810729B2 (en) | 2013-02-28 | 2017-11-07 | Advantest Corporation | Tester with acceleration for packet building within a FPGA block |
CN104298590B (zh) * | 2013-07-16 | 2019-05-10 | 爱德万测试公司 | 用于按管脚apg的快速语义处理器 |
US9547581B2 (en) | 2013-10-01 | 2017-01-17 | Wipro Limited | Systems and methods for fixing software defects in a binary or executable file |
CN104979016B (zh) * | 2014-04-10 | 2018-03-09 | 国民技术股份有限公司 | 一种智能卡及智能卡的制造方法 |
EP3032270A1 (en) * | 2014-12-12 | 2016-06-15 | Airbus Defence and Space, S.A. | Method and system for performing electrical tests to complex devices |
CN106909353B (zh) * | 2015-12-22 | 2019-12-13 | 阿里巴巴集团控股有限公司 | 应用程序的运行方法和装置 |
TWI586979B (zh) * | 2015-12-23 | 2017-06-11 | 致茂電子股份有限公司 | 自動測試設備的群組化時間量測模組及其方法 |
US9967042B2 (en) * | 2016-01-05 | 2018-05-08 | Sure, Inc. | Remotely testing operational components of a mobile device |
US20180114161A1 (en) * | 2016-10-26 | 2018-04-26 | T3W Business Solutions, Inc. | Systems and methods for supply chain risk analysis |
US10191736B2 (en) * | 2017-04-28 | 2019-01-29 | Servicenow, Inc. | Systems and methods for tracking configuration file changes |
DE102017214892A1 (de) * | 2017-08-25 | 2019-02-28 | Lenze Automation Gmbh | Verfahren zur Inbetriebnahme eines Steuergerätesystems und Steuergerätesystem |
CN107707561B (zh) * | 2017-11-01 | 2020-05-19 | 北京知道创宇信息技术股份有限公司 | 渗透测试方法及装置 |
CN107888299A (zh) * | 2017-11-17 | 2018-04-06 | 国网冀北电力有限公司电力科学研究院 | 一种通信模块的测试装置 |
KR102583174B1 (ko) | 2018-06-12 | 2023-09-26 | 삼성전자주식회사 | 테스트 인터페이스 보드, 이를 포함하는 테스트 시스템 및 이의 동작 방법 |
WO2020105130A1 (ja) | 2018-11-20 | 2020-05-28 | 三菱電機株式会社 | 通信システム、リスト参照局、リスト配信局、通信方法、および通信プログラム |
JP7122236B2 (ja) * | 2018-11-28 | 2022-08-19 | 東京エレクトロン株式会社 | 検査装置、メンテナンス方法、及びプログラム |
US10976361B2 (en) | 2018-12-20 | 2021-04-13 | Advantest Corporation | Automated test equipment (ATE) support framework for solid state device (SSD) odd sector sizes and protection modes |
US11137910B2 (en) | 2019-03-04 | 2021-10-05 | Advantest Corporation | Fast address to sector number/offset translation to support odd sector size testing |
US11237202B2 (en) | 2019-03-12 | 2022-02-01 | Advantest Corporation | Non-standard sector size system support for SSD testing |
US11302412B2 (en) * | 2019-06-03 | 2022-04-12 | Advantest Corporation | Systems and methods for simulated device testing using a memory-based communication protocol |
EP3751532A1 (en) | 2019-06-13 | 2020-12-16 | Rohde & Schwarz GmbH & Co. KG | Remote access and control system and corresponding method |
US10884847B1 (en) | 2019-08-20 | 2021-01-05 | Advantest Corporation | Fast parallel CRC determination to support SSD testing |
CN111479265B (zh) * | 2020-03-09 | 2021-06-18 | 珠海格力电器股份有限公司 | 信息传播方法、装置、计算机设备和存储介质 |
US11650893B2 (en) * | 2020-03-31 | 2023-05-16 | Advantest Corporation | Multiple name space test systems and methods |
CN111611007B (zh) * | 2020-05-21 | 2023-08-29 | 掌阅科技股份有限公司 | 基于脚本实现的应用程序安装包的打包方法及设备 |
CN114721977B (zh) * | 2022-03-28 | 2024-06-25 | 一汽解放汽车有限公司 | 一种驱动控制方法、装置、系统、电子设备和存储介质 |
Family Cites Families (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DK557884A (da) * | 1983-11-25 | 1985-05-26 | Mars Inc | Automatisk testudstyr |
US5488573A (en) | 1993-09-02 | 1996-01-30 | Matsushita Electric Industrial Co., Ltd. | Method for generating test programs |
US5892949A (en) | 1996-08-30 | 1999-04-06 | Schlumberger Technologies, Inc. | ATE test programming architecture |
US6182258B1 (en) | 1997-06-03 | 2001-01-30 | Verisity Ltd. | Method and apparatus for test generation during circuit design |
US6028439A (en) | 1997-10-31 | 2000-02-22 | Credence Systems Corporation | Modular integrated circuit tester with distributed synchronization and control |
US6195774B1 (en) | 1998-08-13 | 2001-02-27 | Xilinx, Inc. | Boundary-scan method using object-oriented programming language |
US6601018B1 (en) | 1999-02-04 | 2003-07-29 | International Business Machines Corporation | Automatic test framework system and method in software component testing |
US6427223B1 (en) | 1999-04-30 | 2002-07-30 | Synopsys, Inc. | Method and apparatus for adaptive verification of circuit designs |
US6678643B1 (en) | 1999-06-28 | 2004-01-13 | Advantest Corp. | Event based semiconductor test system |
US6405364B1 (en) | 1999-08-31 | 2002-06-11 | Accenture Llp | Building techniques in a development architecture framework |
DE60021066T2 (de) * | 2000-07-07 | 2006-05-18 | Sun Microsystems, Inc., Santa Clara | Prüfung eines Softwarepakets |
US6779140B2 (en) | 2001-06-29 | 2004-08-17 | Agilent Technologies, Inc. | Algorithmically programmable memory tester with test sites operating in a slave mode |
DE10392497T5 (de) * | 2002-04-11 | 2005-02-17 | Advantest Corp. | Herstellungsverfahren und Herstellungsvorrichtung zum Vermeiden eines Prototypen-Aufschubs bei der ASIC/SOC-Herstellung |
TWI344595B (en) | 2003-02-14 | 2011-07-01 | Advantest Corp | Method and structure to develop a test program for semiconductor integrated circuits |
US7197417B2 (en) | 2003-02-14 | 2007-03-27 | Advantest America R&D Center, Inc. | Method and structure to develop a test program for semiconductor integrated circuits |
US7437261B2 (en) | 2003-02-14 | 2008-10-14 | Advantest Corporation | Method and apparatus for testing integrated circuits |
US7107173B2 (en) * | 2004-02-03 | 2006-09-12 | Credence Systems Corporation | Automatic test equipment operating architecture |
-
2004
- 2004-08-13 US US10/917,916 patent/US7184917B2/en not_active Expired - Lifetime
-
2005
- 2005-05-18 TW TW094116153A patent/TWI363879B/zh not_active IP Right Cessation
- 2005-05-23 EP EP05743357A patent/EP1756603B1/en not_active Not-in-force
- 2005-05-23 WO PCT/JP2005/009815 patent/WO2005114240A1/en active Application Filing
- 2005-05-23 JP JP2006519572A patent/JP3890079B1/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
TWI363879B (en) | 2012-05-11 |
US7184917B2 (en) | 2007-02-27 |
WO2005114240A1 (en) | 2005-12-01 |
TW200608031A (en) | 2006-03-01 |
US20050022087A1 (en) | 2005-01-27 |
JP2008519248A (ja) | 2008-06-05 |
EP1756603A1 (en) | 2007-02-28 |
EP1756603B1 (en) | 2009-08-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP3890079B1 (ja) | モジュール式試験システムにおける交換可能コンポーネントを制御するための方法及びシステム | |
JP4516961B2 (ja) | 半導体試験システム、試験プログラムを生成するための方法、及びプリヘッダ | |
JP4332179B2 (ja) | パターンコンパイラ | |
JP4332200B2 (ja) | モジュール式試験システム内のパターンオブジェクトファイルを管理するための方法およびモジュール式試験システム | |
JP3939336B2 (ja) | 半導体集積回路用のテストプログラムを開発する方法および構造 | |
US8255198B2 (en) | Method and structure to develop a test program for semiconductor integrated circuits | |
JP2007528993A5 (ja) | ||
JP3911007B1 (ja) | モジュール式試験システムをシミュレートする方法及びシステム | |
US20090119054A1 (en) | Test equipment, method for loading test plan and program product | |
KR20070035507A (ko) | 모듈식 테스트 시스템에서 호환성있는 컴포넌트를 제어하는방법 및 시스템 | |
KR20070023762A (ko) | 반도체 집적 회로를 위한 테스트 프로그램을 개발하는 방법및 구조 | |
Dollas et al. | A KNOWLEDGE BASED ENVIRONMENT FOR INTEGRATED CIRCUIT TESTING |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060413 |
|
A871 | Explanation of circumstances concerning accelerated examination |
Free format text: JAPANESE INTERMEDIATE CODE: A871 Effective date: 20060831 |
|
A975 | Report on accelerated examination |
Free format text: JAPANESE INTERMEDIATE CODE: A971005 Effective date: 20060926 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20061114 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20061201 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091208 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101208 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101208 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111208 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111208 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121208 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121208 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121208 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131208 Year of fee payment: 7 |
|
LAPS | Cancellation because of no payment of annual fees |