JP4332200B2 - モジュール式試験システム内のパターンオブジェクトファイルを管理するための方法およびモジュール式試験システム - Google Patents

Description

本特許出願は、２００４年２月６日に出願の同時係属の米国特許出願第１０／７７２，４３４号「Method and Structure to Develop a Test Program for Semiconductor Integrated Circuits」の一部継続出願であり、同特許出願の恩典を主張し、同特許出願は、２００３年２月１４日に出願の米国特許出願第６０／４４７，８３９号「Method and Structure to Develop a Test Program for Semiconductor Integrated Circuits」の恩典を主張する。また本特許出願は、２００４年５月２２日に出願の米国仮特許出願第６０／５７３，５７７号「Software Development in an Open Architecture Test System」の恩典も主張する。それらの特許出願は全て、アドバンテスト社に譲渡され、その全体を参照することにより本明細書に援用される。

本発明は半導体検査のための自動試験装置（ＡＴＥ）の分野に関する。詳細には、本発明は、モジュール式試験システム内のパターンオブジェクトファイルを管理するための方法およびシステムに関する。

従来のＡＴＥシステムでは、パターンオブジェクトファイルの内容は、ベンダに特有の自社開発のハードウエアに密接に関連する。１つの試験システムにおいてパターンオブジェクトファイルを結合して、種々のベンダの自社開発のハードウエアで正常に機能するようにするための標準規格は存在しない。さらに、モジュールのベンダは、自社開発のフォーマットを公開して共有することを望まないので、汎用のパターンオブジェクトフォーマットを開発するのは難しい。さらに、共通のフォーマットを強要することは、余分なオーバーヘッドを生み出す可能性があり、パターンの使用効率を低下させることに繋がる可能性がある。結果として、種々のモジュールベンダの間でパターンデータが用いられるようにするための共通のオブジェクトファイルフォーマットは存在しない。モジュールベンダは、パターンソースファイルをコンパイルして、パターンオブジェクトファイルを生成するために、自社のパターンコンパイラを提供しなければならない。これにより、或るベンダが異なるベンダの試験装置をインストールすることに決める度に、パターンファイルを翻訳するという一連の面倒な作業を行ってきた。これらの不都合な点を克服することが望ましい。

それゆえ、オープンアーキテクチャのモジュール式試験システムが必要とされている。詳細には、モジュール式試験システム内のパターンオブジェクトファイルを管理するための仕組みが必要とされている。

本特許出願は、オブジェクト指向構成体、たとえばC++オブジェクトおよびクラスを用いる試験プログラム開発を記述する。詳細には、この方法は、本発明の譲受人に譲渡される米国特許出願第６０／４４９，６２２号、第１０／４０４，００２号および第１０／４０３，８１７号に記載されるような、オープンアーキテクチャテスタのための試験プログラムを開発するのに適している。

本発明の一実施の形態は、汎用のオブジェクト指向、たとえばC/C++構成体において、試験システム資源、試験システム構成、モジュール構成、試験シーケンス、試験計画、試験条件、試験パターンおよびタイミング情報を記述することによって、自動試験装置（ＡＴＥ）のような半導体検査システムにおいて、被試験デバイス、たとえばＩＣを試験するための試験プログラムを開発するための方法を提供する。これらの記述を含むファイルは、それらのファイルを使用する試験システムまたは関連する装置がアクセスできるメモリ、すなわちコンピュータ読取り可能媒体に記憶される。

試験システム資源を記述することは、資源タイプを指定することであって、その資源タイプは、ＩＣに対して１つの試験を実施するための少なくとも１つの試験モジュールに関連付けられる、資源タイプを指定することと、その資源タイプに関連付けられるパラメータタイプを指定することと、及び、そのパラメータタイプのパラメータを指定することとを含んでもよい。

試験システム構成を記述することは、少なくとも１つの試験モジュールを制御するためのサイトコントローラを指定することであって、各試験モジュールはＩＣに対して１つの試験を実施する、サイトコントローラを指定することと、及び、モジュール接続イネーブラの入力ポートを指定することとを含んでもよい。その試験システムは、指定された入力ポートにおいて、サイトコントローラをモジュール接続イネーブラに接続し、モジュール接続イネーブラは、サイトコントローラを１つの試験モジュールに接続する。モジュール接続イネーブラはスイッチマトリクスとして実装してもよい。

モジュール構成を記述することは、モジュールタイプを指定するためのモジュール識別子を指定することと、モジュール識別子によって指定されるモジュールタイプの試験モジュールを制御するための実行可能コードを指定することと、及び、試験モジュールに関連付けられる資源タイプを指定することとを含んでもよい。実行可能コードは、ダイナミックリンクライブラリの形をとることができる。

モジュール構成を記述することはさらに、ユーザが、モジュール接続イネーブラの出力ポートを指定するためのスロット識別子を指定することを含んでもよく、試験システムは、その出力ポートにおいて、試験モジュールをモジュール接続イネーブラに接続し、モジュール接続イネーブラは試験モジュールを対応するサイトコントローラに接続する。またユーザは、試験モジュールの供給元を特定するためのベンダ識別子と、資源タイプに関連して利用することができる資源ユニットの最大数の識別子とを指定してもよい。資源タイプは、たとえばデジタルテスタピンおよび資源ユニットテスタチャネルであってもよい。別法では、テスタチャネル資源ユニットはまた、たとえば、アナログテスタピン、ＲＦテスタピン、電源ピン、デジタイザピンおよび任意波形発生ピンのような資源タイプに対応してもよい。どの資源ユニットが使用禁止にされるかに関する指標も与えることができる。使用禁止として指示された資源ユニットは、試験モジュールの欠陥のある資源ユニットを表し得る。

試験条件を記述することは、少なくとも１つの試験条件グループを指定することと、少なくとも１つの変数を含む仕様セットを指定することと、及び、変数に結び付けられるべき式を選択するためのセレクタを指定することとを含んでもよい。試験条件グループをその仕様セットのためのセレクタに関連付けることにより、試験条件が規定される。

試験シーケンスを記述することは、種々の試験を実施することができる順序（またはフロー）を指定することを含んでもよい。

試験パターンを記述することは、試験パターン、関連する電圧および電流レベル、信号値の遷移、対応する立ち上がりおよび立ち下がり時間、ならびに関連するタイミングを指定することを含んでもよい。

本発明の一実施の形態は、プリヘッダファイルを使用することも含む。プリヘッダファイルはコンパイルされて、試験実体に関連するクラスのためのヘッダファイルを作成する。プリヘッダは、試験実体の少なくとも１つの属性を設定するためのパラメータを指定するためのパラメータブロックと、コンパイラによって試験実体クラスのためのヘッダファイルに挿入されるソースコードを指定するためのテンプレートブロックとを含む。ヘッダファイルはC++ヘッダファイルであってもよい。たとえば、試験実体は１つの試験であってもよく、試験実体クラスは１つの試験クラスであってもよい。パラメータは、たとえばパターンリストおよび試験条件に関連してもよい。

一実施の形態では、モジュール式試験システム内のパターンオブジェクトファイルを管理するための方法は、モジュール式試験システムを配設することを含み、モジュール式試験システムは少なくとも１つのサイトコントローラを制御するためのシステムコントローラを備え、少なくとも１つのサイトコントローラは少なくとも１つの試験モジュールおよびその対応する被試験デバイス（ＤＵＴ）を制御する。本方法はさらに、ベンダ供給パターンコンパイラとモジュール式試験システムとの間に標準インターフェースを確立するためのオブジェクトファイル管理フレームワークを作成すること、サイトコントローラにおいてパターンソースファイルを受信すること、オブジェクトファイル管理フレームワークを用いて、パターンソースファイルに基づいてパターンオブジェクトメタファイルを作成すること、及び、パターンオブジェクトメタファイルを用いて試験モジュールを通して被試験デバイスを試験することを含む。一実施の形態では、パターンコンパイラであって、少なくとも１つのモジュール特有のパターンコンパイラと、各モジュール特有のコンパイラに対し、パターンソースファイルの対応するモジュール特有のセクションおよび該パターンソースファイルの共通セクションの両方をコンパイルするように指示するためのオブジェクトファイルマネージャと、パターンオブジェクトメタファイルであって、共通ヘッダセクションと、少なくとも１つのモジュール特有のパターンデータセクションとを含むパターンオブジェクトメタファイルとを含む、パターンコンパイラを提供する。共通セクションは、全てのモジュール特有のコンパイラにアクセスできる情報を含んでよい。パターンコンパイラは、モジュール特有のパターンデータを、実行するための対応する試験モジュールにロードするための少なくとも１つのモジュール特有のパターンローダをさらに備えてよい。パターンオブジェクトメタファイルは、パターンソースファイル内の非サイクルベースパターンブロックを表すための１つまたは複数のパターンブロックと、パターンソースファイル内のサイクルベースパターンブロックを表すための多くても１つのサイクライズパターンブロックとをさらに含んでよい。

本発明の上記の特徴および利点、ならびに本発明のさらに別の特徴および利点は、添付の図面とともに取り上げられるときに、本発明の実施形態の詳細な説明の結果として、以下においてさらに明確に理解されるであろう。

モジュール式試験システム内のパターンオブジェクトファイルを管理するための方法およびシステムが提供される。以下の説明は、当業者の誰もが本発明を実施し、使用できるようにするために提示される。特定の実施形態および応用形態の説明は、例としてのみ提供される。本明細書において説明される例の種々の変更および組み合わせが当業者には容易に明らかになるはずであり、本発明の精神および範囲から逸脱することなく、本明細書において規定される一般原理は、他の例および応用形態にも適用することができる。したがって、本発明は説明および図示される例に限定されることを意図するのではなく、本明細書に開示される原理および特徴と合致する最も広い範囲を与えられるべきである。

本発明は包括的には、同じ譲受人による米国特許出願第６０／４４９，６２２号、第１０／４０４，００２号および第１０／４０３，８１７号に開示されるようなオープンアーキテクチャ試験システムの観点から説明される。しかしながら、本発明の試験プログラム開発システムおよび方法の実施形態が、オープンテスタアーキテクチャだけでなく、固定テスタアーキテクチャにも同様に当てはまることは当業者には認識されよう。

オープンアーキテクチャ試験システムに関する記述は、米国特許出願第１０／７７２，３７２号「Method and Apparatus for Testing Integrated Circuits」において見ることができ、その特許出願は、同じ譲受人による米国特許出願第６０／４４９，６２２号の恩典を主張する。

図１は、如何に信号が生成され、被試験デバイス（ＤＵＴ）に加えられるかを示す、従来のテスタの一般化されたアーキテクチャを示す。各ＤＵＴ入力ピンが、試験データを加えるドライバ２に接続され、一方、各ＤＵＴ出力ピンはコンパレータ４に接続される。大抵の場合に、トライステートドライバ‐コンパレータが用いられ、各テスタピン（チャネル）が入力ピン、出力ピンのいずれかとして動作できるようにする。単一のＤＵＴのために専用に設けられるテスタピンは合わせて試験サイトを形成し、その試験サイトは、関連するタイミング発生器６、波形発生器８、パターンメモリ１０、タイミングデータメモリ１２、波形メモリデータ１４およびデータ速度を規定するブロック１６によって動作する。

図２は、本発明の一実施形態によるシステムアーキテクチャ１００を示す。システムコントローラ（ＳｙｓＣ）１０２が多数のサイトコントローラ（ＳｉｔｅＣ）１０４に接続される。システムコントローラは、ネットワークにも接続され、ファイルにアクセスすることができる。試験サイト１１０に配置される１つまたは複数の試験モジュール１０８を制御するために、各サイトコントローラは、モジュール接続イネーブラ１０６を通して、試験モジュール１０８に接続される。モジュール接続イネーブラ１０６は、接続されるハードウエアモジュール１０８の構成を変更できるようにするとともに、データ転送用（パターンデータのロード用、応答データの収集用、制御用など）のバスとしての役割も果たす。実現可能なハードウエアの実装形態は、専用接続、交換接続、バス接続、リング接続およびスター接続を含む。モジュール接続イネーブラ１０６は、たとえばスイッチマトリクスとして実装することができる。各試験サイト１１０は１つのＤＵＴ１１２に関連付けられ、ＤＵＴ１１２は、ロードボード１１４を通して、対応するサイトのモジュールに接続される。１つの実施形態では、単一のサイトコントローラを多数のＤＵＴサイトに接続することができる。

システムコントローラ１０２は、システム全体のマネージャとしての役割を果たす。システムコントローラ１０２は、サイトコントローラの動作状態を調整し、システムレベルの並列試験方法を管理し、さらに、ハンドラ／プローブを制御し、システムレベルのデータロギングおよび誤り処理をサポートする。動作環境によっては、システムコントローラ１０２は、サイトコントローラ１０４の動作とは別のＣＰＵ上に配置することができる。別法では、システムコントローラ１０２およびサイトコントローラ１０４は、共通のＣＰＵを共有することができる。同様に、各サイトコントローラ１０４は、その専用のＣＰＵ（中央演算装置）上に配置することができるか、あるいは同じＣＰＵ内の別個のプロセスまたはスレッドとして配置することができる。

個々のシステムコンポーネントを、集積されたモノリシックシステムの論理的なコンポーネントを見なすことができ、必ずしも１つの分散処理システムの物理的なコンポーネントではないことを前提とすると、図２に示されるシステムアーキテクチャは概念的には分散処理システムと考えることができる。
・別の実施形態では、システムコントローラおよびサイトコントローラは１つまたは複数のコンピューティングデバイスで実装することができる。各コンピューティングデバイスは、
・種々の基本システムサービスを取り扱うための手順、およびハードウエアに依存するタスクを実行するための手順を含むオペレーティングシステム；
・オペレーティングシステムと、パターンオブジェクトファイルを管理するためのアプリケーションプログラムのような、試験システムの他のアプリケーションプログラムとの間のインターフェースを構成するためのアプリケーション層；
・オペレーティングシステムおよびアプリケーションプログラムからの命令を実行するためのプロセッサユニット；および
・試験システムのデータを記憶するためのメモリユニットを含むことができ、メモリユニットは、ランダムアクセスメモリ、不揮発性メモリまたは大容量記憶装置を含むことができる。

アプリケーションプログラムは、実行可能手順、サブモジュール、テーブルおよび他のデータ構造を含むことができる。他の実施形態では、付加的な、または異なるモジュールおよびデータ構造を用いることができ、先に記載されたモジュールおよび／またはデータ構造のうちのいくつかが用いられない場合もある。アプリケーションプログラムはソフトウエアおよび／またはハードウエアにおいて実装することができる。ハードウエアで実装するとき、それらのアプリケーションプログラムは、特定用途向け集積回路（ＡＳＩＣ）で、またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）で実装することができる。

図３は、本発明の一実施形態によるソフトウエアアーキテクチャ２００を示す。ソフトウエアアーキテクチャ２００は分散オペレーティングシステムを表しており、関連するハードウエアシステム要素１０２、１０４、１０８に対応する、システムコントローラ２２０、少なくとも１つのサイトコントローラ２４０および少なくとも１つのモジュール２６０のためのコンポーネントを有する。モジュール２６０に加えて、アーキテクチャ２００は、ソフトウエア内のモジュールエミュレーション２８０のための対応するコンポーネントを含む。

１つの例示的な選択として、このプラットフォームのための開発環境はマイクロソフト ウインドウズを基にすることができる。このアーキテクチャを用いることによって、プログラムおよびサポートの可搬性に関して副次的な利点がもたらされる（たとえば、フィールドサービスエンジニアが、テスタオペレーティングシステムを実行するラップトップを接続して、高度な診断を実行することができる）。しかしながら、大量のコンピュータ集約的な作業（たとえば、テストパターンコンパイル）を行うために、関連するソフトウエアは、分散プラットフォーム上でジョブをスケジューリングできるようにするために個別に実行することができる個別の実体として構成することができる。したがって、バッチジョブのための関連するソフトウエアツールは、多数のプラットフォームタイプ上で動作することができる。

１つの例示的な選択として、ANSI/ISO標準C++を、ソフトウエアのためのネイティブ言語とすることができる。当然、第三者が自ら選択した別の言語を用いるシステムに組み込むことができるようにする多数のオプションが（名目的なC++インターフェース上に層を設けるために）利用可能である。

図３は、テスタオペレーティングシステム、ユーザコンポーネント２９２（たとえば、試験を実施するためにユーザによって供給される）、システムコンポーネント２９４（たとえば、基本的な接続性および通信のためのソフトウエアインフラストラクチャとして供給される）、モジュール開発コンポーネント２９６（たとえば、モジュール開発者によって供給される）および外部コンポーネント２９８（たとえば、モジュール開発者以外の外部供給元によって供給される）を含む、名目的な供給元によって（またはサブシステムとしてまとめて開発するものとして）編成された構成に基づくコンポーネントの陰影を示す。

供給元に基づいて編成されたという見方をすると、テスタオペレーティングシステム（ＴＯＳ）インターフェース２９０は、システムコントローラ／サイトコントローラインターフェース２２２と、フレームワーククラス２２４と、サイトコントローラ／モジュールインターフェース２４５と、フレームワーククラス２４６と、既定モジュールレベルインターフェースと、バックプレーン通信ライブラリ２４９と、シャーシスロットＩＦ（インターフェース）２６２と、ロードボードハードウエアＩＦ２６４と、バックプレーンシミュレーションＩＦ２８３と、ロードボードシミュレーションＩＦ２８５と、ＤＵＴシミュレーションＩＦ２８７と、ＤＵＴのVerilogモデルのためのVerilog PLI（プログラミング言語インターフェース）２８８と、ＤＵＴのC/C++モデルのためのC/C++言語サポート２８９とを含む。

ユーザコンポーネント２９２は、ユーザ試験計画２４２と、ユーザ試験クラス２４３と、ハードウエアロードボード２６５と、ＤＵＴ２６６と、ＤＵＴ Verilogモデル２９３と、ＤＵＴ C/C++モデル２９１とを含む。

システムコンポーネント２９４は、システムツール２２６と、通信ライブラリ２３０と、試験クラス２４４と、バックプレーンドライバ２５０と、ＨＷバックプレーン２６１と、シミュレーションフレームワーク２８１と、バックプレーンエミュレーション２８２と、ロードボードシミュレーション２８６とを含む。

モジュール開発コンポーネント２９６は、モジュールコマンドインプリメンテーション２４８と、モジュールハードウエア２６３と、モジュールエミュレーション２８４とを含む。

外部コンポーネント２９８は外部ツール２２５を含む。

システムコントローラ２２０は、サイトコントローラへのインターフェース２２２と、フレームワーククラス２２４と、システムツール２２６と、外部ツール２２５と、通信ライブラリ２３０とを含む。システムコントローラソフトウエアはユーザのための一次的なインタラクションポイントである。それは、本発明のサイトコントローラへのゲートウエイと、同じ譲受人による米国特許第６０／４４９，６２２号に記載されるようなマルチサイト／ＤＵＴ環境におけるサイトコントローラの同期とを提供する。ユーザアプリケーションおよびツールは、グラフィカルユーザインターフェース（ＧＵＩ）に基づくものでも、そうでないものでも、システムコントローラ上で実行される。システムコントローラは、試験計画、試験パターンおよび試験パラメータファイルを含む、全ての試験計画関連情報のためのリポジトリとしての役割も果たす。これらのファイルを記憶するメモリは、システムコントローラに対してローカルに存在することができるか、またはオフライン、すなわち或るネットワークを通してシステムコントローラに接続されることができる。試験パラメータファイルは、本発明の一実施形態のオブジェクト指向環境内にある試験クラスのためのパラメータ化データを含む。

第三者の開発者は、標準システムツール２２６に加えて（またはその代わりに）、複数のツールを提供することができる。システムコントローラ２２０上の標準インターフェース２２２は、テスタおよび試験オブジェクトにアクセスするためにそれらのツールが用いるインターフェースを含む。ツール（アプリケーション）２２５、２２６によって、試験およびテスタオブジェクトをインタラクティブに、かつバッチで制御できるようになる。それらのツールは、自動能力（たとえば、ＳＥＣＳ／ＴＳＥＭを用いること等による）を提供するためのアプリケーションを含む。

システムコントローラ２２０上に存在する通信ライブラリ２３０は、ユーザアプリケーションおよび試験プログラムに対してトランスペアレントであるように、サイトコントローラ２４０と通信するための仕組みを提供する。

システムコントローラ２２０に関連するメモリ内に存在するインターフェース２２２は、システムコントローラ上で実行されるフレームワークオブジェクトへのオープンインターフェースを提供する。サイトコントローラに基づくモジュールソフトウエアがパターンデータにアクセスし、それらを検索できるようにするインターフェースが含まれる。また、テスタおよび試験オブジェクトにアクセスするためにアプリケーションおよびツールが用いるインターフェース、ならびにスクリプト用エンジンを通してテスタおよび試験コンポーネントにアクセスし、それらを操作する能力を提供するスクリプト用インターフェースも含まれる。これにより、インタラクティブ、バッチおよびリモートアプリケーションのための共通の仕組みが、それらの機能を実行できるようになる。

システムコントローラ２２０に関連付けられるフレームワーククラス２２４は、これらの上記のオブジェクトと対話するための仕組みを提供し、標準インターフェースの参照インプリメンテーションを提供する。たとえば、本発明のサイトコントローラ２４０は機能試験オブジェクトを提供する。システムコントローラフレームワーククラスは、機能試験オブジェクトのリモートシステムコントローラに基づく代理として、対応する機能試験プロキシを提供することができる。こうして、システムコントローラ２２０上のツールが、標準機能試験インターフェースを利用できるようになる。フレームワーククラスは実効的には、ホストシステムコントローラに関連付けられるオペレーティングシステムを提供する。また、それらのフレームワーククラスは、サイトコントローラへのゲートウエイを提供し、かつマルチサイト／ＤＵＴ環境におけるサイトコントローラの同期を提供するソフトウエアコンポーネントを構成する。こうして、この層は、通信層で直に取り扱うことを必要とすることなく、サイトコントローラを操作し、それにアクセスするのに適した、本発明の一実施形態におけるオブジェクトモデルを提供する。

サイトコントローラ２４０は、ユーザ試験計画２４２、ユーザ試験クラス２４３、標準試験クラス２４４、標準インターフェース２４５、サイトコントローラフレームワーククラス２４６、モジュールハイレベルコマンドインターフェース（すなわち、既定モジュールレベルインターフェース）２４７、モジュールコマンドインプリメンテーション２４８、バックプレーン通信ライブラリ２４９およびバックプレーンドライバ２５０のホストとして機能する。試験機能の大部分がサイトコントローラ１０４／２４０によって取り扱われ、それにより試験サイト１１０が個別に動作できるようにすることが好ましい。

試験計画２４２はユーザによって記述される。その計画は、Ｃ＋＋のようなオブジェクト指向構成体を用いて、標準的なコンピュータ言語において直に記述することができるか、または、C++コードを生成するための、さらに高いレベルの試験プログラミング言語において記述することができ、後に実行可能な試験プログラムにコンパイルすることができる。試験プログラムを開発するために、本発明の１つの実施形態は、譲受人の発明による試験プログラム言語（ＴＰＬ）コンパイラを利用する。図４を参照すると、試験プログラムコンパイラ４００が部分的には、翻訳プログラムセクション４０２を含むコード生成プログラムとしての役割を果たし、試験および関連するパラメータを記述する、試験プログラム開発者のソースファイル４０４を、C++コードのようなオブジェクト指向構成体に翻訳する。さらに、コンパイラセクション４０６が、コードをコンパイルして、そのコードを実行可能ファイル、たとえばＤＬＬにリンクし、テスタシステムが実行することができる試験プログラムを生成する。ＴＰＬコード生成プログラム／翻訳プログラムを試験システムに適用することには新規性があるが、コード生成プログラムは当該技術分野において知られていることに留意されたい。また、コンパイラセクションには、当該技術分野において知られている標準的なC++コンパイラを用いることができる。

試験計画は、そのサイトコントローラに関連するフレームワーククラス２４６および／または標準的な、またはユーザによって供給される試験クラス２４４を用いることにより試験オブジェクトを作成し、標準インターフェース２４５を用いてハードウエアを構成し、試験計画フローを規定する。また試験計画は、試験計画の実行中に必要とされる任意の付加的なロジックを提供する。試験計画はいくつかの基本的なサービスをサポートし、デバッグサービス（たとえば、ブレークポイント生成）のような、下層のオブジェクトのサービスへのインターフェースを提供し、下層のフレームワークおよび標準クラスにアクセスできるようにする。

試験プログラムコンパイラ４００に入力されるソースコードは、１つの試験計画において用いられるオブジェクト、およびその互いに対する関係を指定する試験計画記述ファイルを含む。このファイルは、標準インターフェースのインプリメンテーションの形で、サイトコントローラ上で実行されるC++コードに翻訳され、それはITestPlanで表すことができる。このコードは、ウインドウズ・ダイナミックリンクライブラリ（ＤＬＬ）にパッケージングされ、サイトコントローラにロードされることができる。サイトコントローラソフトウエアが試験計画オブジェクトを生成し、それが含む試験計画オブジェクトを戻すために用いることができる標準的な既知のエントリポイントを有するように、試験プログラムＤＬＬが生成される。サイトコントローラソフトウエアは、その試験プログラムＤＬＬを、その処理空間内にロードし、それらのエントリポイントのうちの１つを用いて、試験計画オブジェクトのインスタンスを作成する。一旦、試験計画オブジェクトが作成されたなら、その後、サイトコントローラソフトウエアはその試験計画を実行することができる。

サイトコントローラに関連するフレームワーククラス２４６は、共通の試験関連動作を実装する１組のクラスおよびメソッドである。サイトコントローラレベルフレームワークは、たとえば、電源およびピンエレクトロニクスを一定の順序で配列するためのクラス、レベルおよびタイミング条件を設定するためのクラス、測定値を求めるためのクラス、および試験フローを制御するためのクラスを含む。またフレームワークは、ランタイムサービスおよびデバッグのためのメソッドも提供する。フレームワークオブジェクトは、標準インターフェースを実装することによって機能することができる。たとえば、ＴｅｓｔｅｒＰｉｎフレームワーククラスのインプリメンテーションは、試験クラスがハードウエアモジュールピンと対話するために用いることができる汎用のテスタピンインターフェースを実装するように標準化される。

特定のフレームワークオブジェクトは、モジュールレベルインターフェース２４７の助けを借りて動作し、モジュールと通信するように実装することができる。サイトコントローラフレームワーククラスは実効的には、各サイトコントローラをサポートするローカルオペレーティングシステムとしての役割を果たすことができる。

一般的には、プログラムコードの９０パーセント以上がデバイス試験のためのデータであり、コードの残りの１０パーセントは試験方法を実現する。デバイス試験データは、ＤＵＴに依存する（たとえば、電源条件、信号電圧条件、タイミング条件など）。試験コードは、指定されたデバイス条件をＡＴＥハードウエアにロードするための方法、およびユーザによって指定された目的（データロギングなど）を実現するために必要な方法からなる。本発明の一実施形態のフレームワークは、ハードウエアに依存しない試験、およびユーザがＤＵＴ試験プログラミングのタスクを実行できるようにするテスタオブジェクトモデルを提供する。

試験コードの再利用性を高めるために、そのようなコードは、任意のデバイス固有のデータ（たとえば、ピン名、刺激データなど）、またはデバイス試験固有のデータ（たとえば、ＤＣユニットのための条件、測定ピン、ターゲットピンの数、パターンファイルの名前、パターンプログラムのアドレス）とは無関係に作成することができる。１つの試験のためのコードがこれらのタイプのデータとコンパイルされる場合には、試験コードの再利用性が減少するであろう。それゆえ、本発明の一実施形態によれば、任意のデバイス固有のデータまたはデバイス試験固有のデータを、コード実行時間中の入力として、外部の試験コードが利用できるようにする。

本発明の一実施形態では、試験クラスは、標準試験インターフェースの１つのインプリメンテーションであり、ここではITestとして表され、特定のタイプの試験のための試験データおよびコードの分離（それゆえ、コードの再利用）を実現する。そのような試験クラスは、それ自体の別個のインスタンスのための「テンプレート」と見なすことができ、それらのインスタンスは、デバイス固有データおよび／またはデバイス試験固有データだけが互いとは異なる。試験クラスは、試験計画ファイルにおいて指定される。各試験クラスは通常、特定のタイプのデバイス試験、またはデバイス試験のための設定を実装する。たとえば、本発明の一実施形態は、ＤＵＴのための全ての機能試験のための基本クラスとして、ITestインターフェースの特定のインプリメンテーション、たとえばFunctionalTestを提供することができる。それは、試験条件を設定する機能、パターンを実行する機能、およびストローブに失敗した場合に試験のステータスを判定する機能からなる基本機能を提供する。他のタイプのインプリメンテーションは、ここではACParametricTestおよびDCParametricTestとして表される、ＡＣおよびＤＣ試験クラスを含むことができる。

全試験タイプは、いくつかの仮想的なメソッド（たとえば、init( )、preExec( )およびpostExec( )）のデフォルトインプリメンテーションを提供することができる。これらのメソッドは、試験技師がデフォルトの挙動を無効にし、任意の試験固有のパラメータを設定するためのエントリポイントになる。しかしながら、試験計画において、カスタム試験クラスを用いることもできる。

試験クラスによって、ユーザは、その試験の特定のインスタンスのためのオプションを指定するために用いられるパラメータを与えることにより、クラス挙動を構成できるようになる。たとえば、機能試験は、パラメータＰリストおよびTestConditionを受け取り、それぞれ、実行すべきパターンリスト、およびその試験のためのレベルおよびタイミング条件を指定することができる。これらのパラメータのために種々の値を指定することによって（試験計画記述ファイルにおいて種々の「試験」ブロックを用いることによる）、ユーザは機能試験の種々のインスタンスを作成できるようになる。図５は、単一の試験クラスから種々の試験インスタンスを如何に導出することができるかを示す。これらのクラスは、C++コードのような、オブジェクト指向構成体において直にプログラミングすることができるか、または試験プログラムコンパイラが試験計画ファイルから試験の記述およびそのパラメータを取り込み、対応するC++コードを生成できるようにし、その後、対応するC++コードをコンパイルし、リンクして、試験プログラムを生成することができるように設計することができる。テンプレートライブラリは、一般的なアルゴリズムおよびデータ構造の汎用のライブラリとして用いることができる。このライブラリはテスタのユーザから見ることができるので、ユーザは、たとえば、ある試験クラスのインプリメンテーションを変更し、ユーザ定義の試験クラスを作成することができる。

ユーザによって開発された試験クラスに関しては、そのシステムの一実施形態は、全ての試験クラスが単一の試験インターフェース、たとえばITestから派生し、結果として、標準的な１組のシステム試験クラスと同じようにして、フレームワークがそれらの試験クラスを操作できるようになるという点で、そのような試験クラスをフレームワークに組み入れることをサポートする。これらの付加的なファシリティを利用するために試験プログラムにおいてカスタムコードを使用しなければならないことを前提とした上で、ユーザは付加機能をその試験クラスに自由に取り入れることができる。

各試験サイト１１０は、１つまたは複数のＤＵＴ１０６を専用に試験し、構成変更可能な一群の試験モジュール１１２を通して機能する。各試験モジュール１１２は、特定の試験タスクを実行する実体である。たとえば、試験モジュール１１２には、ＤＣＴ電源、ピンカード、アナログカードなどを用いることができる。このモジュールによる手法は、高い自由度と構成可能性とを提供する。

モジュールコマンドインプリメンテーションクラス２４８は、モジュールハードウエアベンダが提供することができ、ベンダによって選択されるコマンドインプリメンテーション方法に応じて、ハードウエアモジュールのためのモジュールレベルインターフェース、または標準インターフェースのモジュール固有のインプリメンテーションを実装する。これらのクラスの外部インターフェースは、既定モジュールレベルインターフェース要件、およびバックプレーン通信ライブラリ要件によって規定される。この層は、標準的な１組の試験コマンドの拡張も可能にし、メソッド（関数）およびデータ要素を追加できるようにする。

バックプレーン通信ライブラリ２４９は、バックプレーンにわたる標準的な通信のためのインターフェースを提供し、それにより試験サイトに接続されるモジュールと通信するために必要な機能を提供する。これにより、ベンダ固有のモジュールソフトウエアが、バックプレーンドライバ２５０を用いて、対応するハードウエアモジュールと通信できるようになる。バックプレーン通信プロトコルはパケットに基づくフォーマットを用いることができる。

テスタピンオブジェクトは、物理的なテスタチャネルを表し、ここではITesterPinとして表される、テスタピンインターフェースから派生する。本発明の一実施形態のソフトウエア開発キット（ＳＤＫ）は、TesterPinとも呼ばれる場合がある、ITesterPinのデフォルトインプリメンテーションを提供し、それは既定モジュールレベルインターフェース、IChannelという形で実装される。ベンダは、IChannelという形でモジュールの機能を実装することができる場合には、自由にTesterPinを利用することができる。そうでない場合には、ベンダは、そのモジュールで正常に機能するためのITesterPinのインプリメンテーションを提供しなければならない。

本発明のテスタシステムによって提供される、ここではIModuleとして表される標準モジュールインターフェースは包括的には、ベンダのハードウエアモジュールを表す。種々のベンダが種々のモジュールを提供することができる。また、１つのベンダが複数の異なるモジュールを提供する場合もある。ベンダ供給の、そのシステムのためのモジュール固有のソフトウエアは、ダイナミックリンクライブラリ（ＤＬＬ）のような実行可能ファイルの形で提供されることができる。１つのベンダからのモジュールタイプ毎のソフトウエアは、単一のＤＬＬ内にカプセル化することができる。そのような各ソフトウエアモジュールは、モジュールソフトウエア開発のためのＡＰＩを含む、モジュールインターフェースコマンドのためのベンダ固有のインプリメンテーションを提供するための役割を担う。

モジュールインターフェースコマンドには２つの側面がある。第一に、それらのコマンドは、ユーザがシステム内の特定のハードウエアモジュールと（間接的に）通信するためのインターフェースとしての役割を果たし、第二に、それらのコマンドは、第三者の開発者が、自らのモジュールをサイトコントローラレベルフレームワークに組み込むために利用することができるインターフェースを提供する。したがって、フレームワークによって提供されるモジュールインターフェースコマンドは、２つのタイプに分類される。

最初の、そして最も明らかなコマンドは、フレームワークインターフェースを通してユーザが見ることができる「コマンド」である。こうして、テスタピンインターフェース（ITesterPin）は、レベルおよびタイミング値を入手し、設定するための方法を提供し、一方、電源インターフェース（IPowerSupply）は、たとえばパワーアップおよびパワーダウンするための方法を提供する。

さらに、フレームワークは既定モジュールレベルインターフェースの特殊なカテゴリを提供し、それは、モジュールと通信するために用いることができる。これらは、ベンダのモジュールと通信するためにフレームワーククラスによって用いられるインターフェース（すなわち、フレームワークインターフェースの「標準的な」インプリメンテーション）である。

しかしながら、第２の側面、すなわちモジュールレベルインターフェースを用いることはオプションである。それを用いることの利点は、モジュールレベルインターフェースを実装することによってハードウエアに送出される特定のメッセージの内容に重点を置きながら、ベンダがITesterPinおよびIPowerSupplyなどのクラスのインプリメンテーションを利用できることである。しかしながら、これらのインターフェースがそのベンダに適していない場合には、それらのベンダは、フレームワークインターフェースのカスタムインプリメンテーション（たとえば、ITesterPin、IPowerSupplyなどのベンダインプリメンテーション）を提供することを選択することもできる。その際、これらのベンダは、そのハードウエアに適したカスタム機能を提供するであろう。

バックグラウンドとしてこのオープンアーキテクチャを用いて、本発明の試験プログラム開発システムが以下にさらに説明される。以下のセクションＡは、試験プログラムが用いられることになる試験環境を記述するための規則を説明する。セクションＢは、試験プログラム開発のための方法および規則を説明する。セクションＣは、試験計画を開発するための方法および規則、ならびに試験プログラムの主要構造を定義する方法を説明する。セクションＤは、オープンアーキテクチャ試験システム上で試験プログラムを実行する方法を説明する。セクションＥは、試験パターンのための方法および規則を説明する。セクションＦは、試験パターンのタイミングを記述するための規則を説明する。セクションＧは、テスタ動作全体のための規則を説明する。

［Ａ．コンポーネント］
試験環境は、テスタをインストールし、それを１組の試験を実行するために準備するための必要な条件を指定する１組のファイルを含む。試験環境は、以下に記載されるもののためのファイルを含むことが好ましい。
１．テスタ資源定義：そのオープンアーキテクチャ試験システムにおいて利用することができるテスタ資源タイプ、およびそのような資源のためにサポートされるパラメータを指定するためのファイル。
２．テスタ構成：サイトコントローラ、サイトおよび対応するマッピングを指定するためのファイル。
３．モジュール構成：各サイト内のハードウエアモジュールを指定するためのファイル。
４．ピン記述：信号ピン、電源のようなＤＵＴピンを命名し、ピングループを記述するためのファイル。
５．ソケット：ＤＵＴピン‐テスタピンの割当てを指定するためのファイル。
６．ピンオプション：ピンのための特殊なオプション又はモードを指定するためのファイル。
７．パターンリスト：試験パターンおよびそのシーケンスを指定するためのファイル。
８．パターン：試験ベクトルを指定するためのファイル。

上記のファイルのうち、項目１〜３はＣＭＤ（構成管理データベース）からの情報を用いてＩＣＦ（インストールおよび構成ファイル）によって作成され、既知の場所において入手可能であるのに対して、項目４〜８はユーザによって指定される。このセクションは、上記の項目１〜６のための説明を提供する。項目７および８はセクションＥにおいてさらに詳細に説明される。これらのコンポーネントをそれぞれ開発するために、特定の方法および規則が用いられることが好ましい。これらの方法および規則は、例とともにこのセクションにおいて説明されるであろう。

［Ａ１．資源定義］
各ハードウエアモジュールは、試験システムによって用いるための１つまたは複数のタイプのハードウエア資源（略して資源）を提供する。テスタ資源定義は、利用可能な資源タイプのための１組の資源名、並びにそれぞれの特定の資源タイプに関連する１組のパラメータ名およびタイプを宣言するために用いられることが好ましい。たとえば、資源名ｄｐｉｎは、デジタルテスタピンを指すために用いられる。これらの資源は、ＶＩＬ（入力低電圧用）、ＶＩＨ（入力高電圧用）、ＶＯＬ（出力低電圧用）、ＶＯＨ（出力高電圧用）などのパラメータを有する。資源定義ファイルは、「．ｒｓｃ」の拡張子を有するであろう。以下に示されるのは、いくつかのテスタ資源を含む、資源定義の一例である。

#
# 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;
}
}

資源パラメータのタイプ（ＶｏｌｔａｇｅまたはＴｉｍｅなど）は標準的な工学単位であることが好ましいことに留意されたい。異なるパラメータを指定することが望ましい特定用途の資源を供給するベンダは、自らの資源定義ファイルを提供すべきである。

［資源定義のための構造］
以下に与えられるのは、本発明の好ましい実施形態による資源定義ファイルのための構造である。

resource-file:
version-info resource-defs
version-info:
Version version-identifer;
resource-defs:
ResourceDefs {resource-def-list}
resource-def-list:
resource-def
resource-def-list resource-def
resource-def:
resource-name {resource-params-decl-list}
resource-params-decl-list:
resource-params-decl
resource-params-decl-list resource-params-decl
resource-params-decl:
elementary-type-name resource-param-name-list;
resource-param-name-list:
resource-param-name
resource-param-name-list , resource-param-name

上記の未定義の非終端記号は以下のように指定される。
１．version-identifier：集合［０−９ａ−ｚＡ−Ｚ．］からの１つまたは複数の文字からなる文字列。それはバージョン番号を表す。
２．resource-name：集合［ａ−ｚＡ−Ｚ＿０−９］からの１つまたは複数の文字からなる文字列であり、数字で始まらない。それはｄｐｉｎまたはｄｐｓのような資源の名前を表す。
３．elemantary-type-name：集合［ａ−ｚＡ−Ｚ＿０−９］からの１つまたは複数の文字からなる文字列であり、数字で始まらない。それは、Voltage(cf.)のような基本タイプの名前を表す。
４．resource-param-name：集合［ａ−ｚＡ−Ｚ＿０−９］からの１つまたは複数の文字空なる文字列であり、数字で始まらない。それは、ＶＩＬのような資源パラメータの名前を表す。

［Ａ２．テスタ構成］
テスタ構成は、特定のシステム構成内のサイトコントローラ、およびサイトコントローラのスイッチマトリクス入力ポートへの接続を記載するために用いられることが好ましい１組の規則である。本発明の一実施形態のアーキテクチャでは、単一のサイトコントローラを単一のスイッチマトリクス入力ポートに接続することができる。したがって、この状況では、スイッチマトリクス接続は、システム内のサイトコントローラのための暗黙の識別子としての役割を果たす（他の構成も可能である）。以下は一般的なテスタ構成の一例である。

#
# 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;
}

特定の試験フロアシステムのためのシステム構成はシステムプロファイルの一部であり、システム構成ファイルSys.cfgとして入手することができる。１つの実施形態では、ポート１（上記の例では「１２７．０．０．０」）に接続されるサイトコントローラは特別なステータスを享受することができ、そのステータスでは、そのサイトコントローラが単独でスイッチマトリクスを構成することに留意されたい。この「特殊な」サイトコントローラはＳＩＴＥＣ−１と呼ばれるであろう。また、そのサイトコントローラは内部ネットワークによってシステムコントローラに接続することができるので、この例におけるサイトコントローラアドレスはＩＰアドレスであることにも留意されたい。逆に、システムコントローラは、パターンデータのようなファイルにアクセスするために外部ネットワークに接続することができる。

［テスタ構成のための構造］
以下に与えられるのは、本発明の一実施形態によるシステム構成ファイルのための構造である。

system-config-file:
version-info system-config
version-info:
Version version-identifer;
system-config:
SysConfig{ site-controller-connection-list}
site-controller-connection-list:
site-controller-connection
site-controller-connection-list site-controller-connection
site-controller-connection:
site-controller-hostname input-port;
site-controller-hostname:
ip-address
domain-qualified-hostname
ip-address:
octet . octet .octet . octet
domain-qualified hostname:
name
domain-qualified-hostname . name

上記の未定義の非終端記号は以下のように指定される。
１．version-identifier：集合［０−９ａ−ｚＡ−Ｚ．］からの１つまたは複数の文字からなる文字列。それはバージョン番号を表す。
２．octet：０〜２５５の負でない整数（１０進表記）。
３．name：集合［ａ−ｚＡ−Ｚ＿０−９］からの１つまたは複数の文字からなる文字列であり、数字で始まらない。それは、ドメイン修飾されたホスト名内の名前部分を表す。
４．input-port：１０進表記の負でない整数。

［Ａ３．モジュール構成］
モジュール構成によって、テスタの物理的な構成、たとえばシステムシャーシ内の各モジュールの物理的な場所およびタイプを指定できるようになる。これは、動的なテスタバス構成によって必要とされ、そのテスタバス構成によって、テスタバスアドレスを物理的なスロットの場所にマッピングできるようになる。この情報は、システム構成の妥当性を検査するためにシステムブートアップ時に行われるハードウエア発見プロセスを可能にする。スイッチマトリクスの各出力ポートは物理的なスロットを定義し、そのスロットは単一のハードウエアモジュールによって占有されることが好ましい。以下に示されるのは、本発明の一実施形態による、ファイル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;
}
}
}

先に記載されたように、１つの実施形態では、スロットは、スイッチマトリクスの出力ポートのような、１つのハードウエアモジュールを接続することができるコネクタを指している。各構成定義は、１つまたは複数のスロットに取り付けられる場合があるモジュールについての情報を提供する。構成定義において指定されるVendorIDは、１つのベンダに関連する固有のＩＤである。ModuleIDは、このベンダによって提供されるモジュールのタイプを指している。１つのテスタ構成内に同じModuleIDのいくつかのインスタンスが存在する場合もある。ModuleDriverは、そのモジュールをサービスするためにベンダ供給ＤＬＬを指している。最後に、Resourceは、このモジュールによってサービスされるユニットを指しており、資源タイプのための名前を与える。資源名は資源定義ファイルから得られる。

上記の例は、モジュール構成ファイル内の３つの構成ブロックを記述する。１つの実施態様では、第１の構成ブロック、スロット１〜１２および３２〜４８はベンダ１によって製造されるモジュールによってサービスされる。このベンダは、そのモジュール、このモジュールタイプを指すための識別子「１」、およびモジュールを制御するためのモジュールドライバライブラリを提供する。このモジュールは２つのタイプの資源ユニットを提供することができ、一方のタイプは資源名「dpin」によって表され、好ましくは全数が３２資源ユニット（すなわち「チャネル」）であり、その全てが利用可能であり、他方のタイプは資源名「analog」によって表され、全数が１６資源ユニットであり、９から１６までのみ利用可能である。第２および第３の構成ブロックは第１の構成と同じようにして指定される。

チャネルが「使用禁止」として指示されるようにする措置は、他の点では依然として機能するモジュールにおいて欠陥のある資源ユニットを特定できるようにすることであることに留意されたい。また、構成ブロックは１つまたは複数のスロット識別子を有することができることにも留意されたい。１つのブロックが２つ以上のスロット識別子を有するとき、特定されたスロットはクローンであると言われる。

モジュール構成ファイル、Module.cfgは、ＩＣＭ（インストール構成管理システム）によってシステムプロファイルの一部として作成され（ユーザによって提供される試験フロア固有の情報を含む）、周知の場所において入手することができる。ＩＣＭは、試験システム、たとえばシステムコントローラ上にローカルに存在することができるか、またはシステムコントローラが接続されるネットワーク上のいずれかの場所に存在することができるユーティリティである。ＩＣＭはＣＭＤ（構成管理データベース）を管理し、通常は、システム構成に対するハードウエア変更時に更新される。ＩＣＭによって、ユーザは、システム、たとえばサイトコントローラおよびモジュールを構成できるようになる。ＣＭＤは、それらの構成を記憶するデータベースである。実際のテスタの場合、構成／動作ＩＣＭが構成ファイル、たとえばモジュール構成、および他のファイルを生成し、それらのファイル、および特定のモジュールＤＬＬのような関連するファイルをテスタ上にコピーする。

［モジュール構成のための構造］
以下は、好ましい実施形態によるモジュール構成構造である。

file-contents:
version-info module-config-def
version-info:
Version version-identifier;
module-config-def:
ModuleConfig {slot-entry-list}
slot-entry-list:
slot-entry
slot-entry-list slot-entry
slot-entry:
Slot positive-integer-list {slot-info}
slot-info:
required-config-list
required-config-list:
required-config
required-config-list required-config
required-coiifig:
VendorID id-code ;
ModuleID id-code ;
ModuleDriver file-name ;
Resource resource-name {max-spec disabled spec_opt}
max-spec:
MaxAvailable positive-integer ;
disabled-spec:
Disabled 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

上記の未定義の非終端記号は以下のように指定される。
１．version-identifier：集合［０−９ａ−ｚＡ−Ｚ．］からの１つまたは複数の文字からなる文字列。ただし、最初の文字は集合［０−９］から選択されなければならない。
２．positive-integer：集合［０−９］からの１つまたは複数の文字からなる文字列であり、０で始まらない。
３．id-code：集合［ａ−ｚＡ−Ｚ＿０−９］からの１つまたは複数の文字からなる文字列。
４．resource-name：集合［ａ−ｚＡ−Ｚ＿０−９］からの１つまたは複数の文字からなる文字列。ただし、第１の文字は集合［ａ−ｚＡ−Ｚ］から選択されなければならない。

コメントがサポートされる。コメントは「＃」文字で始まり、行の終わりまで続く。

［Ａ４．ピン記述］
ＤＵＴピン記述はピン記述ファイルを用いて記述される。ユーザは、ピン記述ファイル内のＤＵＴピンの記述を入手できようになり、その記述は拡張子．ｐｉｎを有する。このプレーンテキストファイルは、少なくとも、ＤＵＴピン名のリストと、定義されたＤＵＴピン名を利用する、命名されたピングループの初期定義とを含む（それらの定義は、たとえばプログラミングによって、後に変更または追加することができるので「初期」である）。

このデータ指定を試験計画記述から分離することにより、ＤＵＴピン定義を広く再利用できるようになり、そのプロセスを特定の試験計画に関連付けることなく、パターンコンパイラが、ピン記述ファイルからピン名（ベクトル指定において用いられるピン名への参照を決定するために必要とされる）を導出できるようになる。

以下に示されるのは、ピン記述ファイルの一例である。

#
# 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
}
}
}

コンパイラがピンおよびピングループ定義をＬｅｖｅｌなどのため許容パラメータ設定と関連付けられるようにするために、ＤＵＴピンおよびピングループ定義は資源タイプブロック内にカプセル化されることに留意されたい。

ピン記述についての以下の点に留意されたい。
１．ピングループおよびピンは同じ名前空間を共有し、グローバル（すなわち試験計画）範囲を有する。これらの名前をグローバル範囲にする結果の１つは、異なる資源ブロックにおいて宣言されるときでも、ピンおよびピングループが重複した名前を使用することができないことである。
２．ピン記述ファイルにおいて少なくとも１つの資源定義が必要とされる。
３．各資源において少なくとも１つのピン名が定義されなければならない。
４．ピンおよびピングループ名は資源境界内で固有であることが要求される。
５．２つ以上の資源のために同じピンまたはグループ名を定義することができる。しかしながら、同じ資源内に同じものがある場合には無視される。
６．１つのグループ定義内に現れる全てのピン名およびグループ名はその資源内で既に定義されていなければならない。
７．もし与えられる場合には、グループ定義は少なくとも１つのピン名またはグループ名を持たなければならない（すなわち、グループ定義は空であることはできない）。
８．ピングループ定義は、予め定義されたピングループへの参照を含むことができる。
９．ピングループ定義は、予め定義されたピンおよび／またはピングループの追加および削除のような集合演算を含むことができる。

［ピン記述のための構造］
以下に与えられるのは、本発明の好ましい実施形態によるピン記述のための構造である。

pin-description-file:
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

上記の未定義の非末端部は以下のように指定される。
１．version-identifier：集合［０−９ａ−ｚＡ−Ｚ．］からの１つまたは複数の文字からなる文字列。それはバージョン番号を表す。
２．resource-name：集合［ａ−ｚＡ−Ｚ＿０−９］からの１つまたは複数の文字からなる文字列であり、数字で始まらない。それはｄｐｉｎまたはｄｐｓのような資源の名前を表す。
３．pin-name：集合［ａ−ｚＡ−Ｚ＿０−９］からの１つまたは複数の文字からなる文字列であり、数字で始まらない。それは、ピンＡ０の名前を表す。
４．pin-gourp-name：集合［ａ−ｚＡ−Ｚ＿０−９］からの１つまたは複数の文字からなる文字列であり、数字で始まらない。それは、ピングループＡＢＵＳの名前を表す。
５．index：負でない整数。それは、関連するピンのグループの下限または上限を表す。

［Ａ５．ソケット］
ソケットは、ＤＵＴピン名と物理的なテスタピン（チャネル）割当てとの間のマッピングを指定する（物理的なテスタチャネル番号はモジュール構成ファイルにおいて定義される）。異なるソケットを用いて、異なるＤＵＴパッケージおよび異なるロードボード構成などをサポートすることができることに留意されたい。マルチＤＵＴシステムの場合、ＤＵＴ／チャネル割当てのためのソケット定義は、基本ソケットの多数のサイトへの「クローニング」をサポートすることができる。しかしながら、異なるソケット（すなわち、同じ論理ピンのための異なる物理的なマッピング）はサイトモジュール区分を考慮すべきである。したがって、ＤＵＴピンをテスタチャネル割当てに与えることに加えて、ソケットは実効的にはサイト区分も定義する。こうして、ソケットファイルは、いくつかの個別のサイトソケットのための定義を含むことができる。以下に示されるのは、３つのＤＵＴサイトを定義するソケットファイルのサンプルである。

Version 1.1.3
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

ソケットファイルについて以下の点に留意されたい。
１．ソケットファイルは、モジュール構成ファイル、および所与のＤＵＴタイプのためのユーザのピン記述ファイルの両方からの情報を用いる（上記の例のピン記述の場合の指定を参照されたい）。モジュール構成情報は、ソケットファイルコンパイラが暗黙のうちに利用することができる。ソケットファイルコンパイラは、パターンコンパイラの一部を構成し、ソケットＤＵＴ名からテスタチャネルへのマッピング、モジュール構成およびピン記述ファイルを読み出し、分析して、テスタピンのパターンコンパイラによって用いられるＤＵＴピンへのマッピングを設定する。
２．ＤＵＴタイプ当たり少なくとも１つのＤＵＴサイト定義が必要とされ、それは、SlotOffset構文ではなく、フルスペック構文を用いなければならない。同じＤＵＴタイプに対して２つ以上のＤＵＴサイト定義が与えられる場合には、第１のサイト定義はフルスペック構文を用いなければならない。
３．後続の各ＤＵＴサイト定義（同じＤＵＴタイプ）は、フルスペック構文、SlotOffset構文のいずれかを用いることができるが、両方は用いることができない。これにより、個々のサイトが、標準パターンから逸脱できるようになる（たとえば、動作不能のチャネルに起因する）。
４．SlotOffset構文から導出される結合は、そのＤＵＴタイプのために定義される第１のサイト（フルスペック構文を用いる）に対して定義される。
５．ＤＵＴサイトは、実際の物理的な順序で宣言される必要はない。これにより、第１の（物理的な）サイトがそのパターンから逸脱する状況が許される。
６．ＤＵＴサイトＩＤは、ソケット全体にわたって（すなわち、その中で定義される全てのＤＵＴタイプにわたって）固有であることが要求される。
７．ＤＵＴサイト定義毎に少なくとも１つの資源定義が必要とされる。
８．サイト定義を、モジュール構成とともに用いて、試験構成が単一サイト／単一ＤＵＴであるか、単一サイト／多数ＤＵＴであるかを判定しなければならない。
９．全ての場合に、ソケットファイルは、ピン記述ファイルおよびモジュール構成ファイルと一致する１組のＤＵＴチャネルマッピングを指定しなければならない。
１０．場合によっては、１つまたは複数のＤＵＴチャネルがテスタから切断されることをソケットが指定できるようにすることが望ましいであろう（たとえば、割り当てられた物理チャネルを特殊なＩＤ「０．０」を有するチャネルと指定することによる）。この場合、試験プログラムの関連で、これらのＤＵＴチャネルを使用し、参照することができる。そのようなチャネル上での動作の結果として、システム警告が生成されるであろう（ただし、エラーではない）。ロード時に、切断されたチャネルのためのパターンデータは破棄されるであろう。

［ソケットのための構造］
以下は、本発明の好ましい実施形態によるモジュール構成のための構造である。

socket-file:
version-info socket-def
version-info:
Version version-identifer;
socket-def:
SocketDef {device-specific-socket-def-list}
device-specific-socket-def-list:
device-specific-socket-def
device-specific-socket-def list device-specific-socket-def
device-specific-socket-def:
DUTType DUT-type-name {pin-description-file dut-info-list}
pin-description-file:
PinDesc pin-description-file-name ;
dut-info-list:
dut-info
dut-info-list dut-info
dut-info:
DUT dut-id {site-controller-input-port resource-info-list}
site-controller-input-port:
SiteController switch-matrix-input-port-number;
resource-info-list:
resource-info
resource-info-list resource-info
resource-info:
Resource resource-name {resource-item-unit-assignment-list}
resource-item-unit-assignment-list:
resource-item-unit-assignment
resource item-unit-assignment-list resource-item-unit-assignment
resource-item-unit-assignment:
resource-item-name slot-number. resource-unit;
resource-item-name [resource-item-index] slot-number. resource-
unit-index;
resource-item-name [resource-item-index-range]
slot-number. [resource-unit-index-range];
resource-item-index-range:
resource-item-index : resource-item-index
resource-unit-index-range:
resource-unit-index : resource-unit-index

上記の未定義の非終端記号は以下のように指定される。
１．version-identifier：集合［０−９ａ−ｚＡ−Ｚ．］からの１つまたは複数の文字からなる文字列。それはバージョン番号を表す。
２．Dut-type-name：集合［０−９ａ−ｚＡ−Ｚ．］からの１つまたは複数の文字からなる文字列。ただし、最初の文字は集合［０−９］から選択されてはならない。それは、ＣＨＩＰ３のようなＤＵＴのタイプを表す。
３．pin-description-file-name：ファイルの簡単な名前であり、そのディレクトリ名は含まないが、全ての拡張子を含む。そのファイル名は、ホストオペレーティングシステムによって認識される構文からなり、引用符に囲まれる場合には、空白および他の文字が許される。
４．switch-matrix-input-port-number：１０進表記の負でない整数であり、サイトコントローラに接続される入力ポートのポート数を表す。
５．dut-id：１０進表記の負でない整数であり、ＤＵＴのインスタンスを特定する。
６．resource-name：集合［０−９ａ−ｚＡ−Ｚ］からの１つまたは複数の文字からなる文字列であり、最初の文字は数字であってはならない。それは資源ファイルにおいて定義される資源の名前を表す。
７．resource-item-name：集合［０−９ａ−ｚＡ−Ｚ］からの１つまたは複数の文字からなる文字列であり、最初の文字は数字であってはならない。それは、ピンまたはピングループのような資源ユニットの名前を表す。
８．resource-item-index：１０進表記の負でない整数であり、資源項目のグループのうちの特定のメンバを表す。resource-item-index-rangeの関連では、それは、資源項目グループの連続した文字列の下限または上限を表す。
９．resource-unit-index：１０進表記の負でない整数であり、資源ユニット（チャネル）のグループのうちの特定のメンバを表す。resource-unit-index-rangeの関連では、それは、資源ユニットグループの連続した文字列の下限または上限を表す。

［Ａ６．ピン］
論理的なピン名を物理チャネルにマッピングすること（たとえばソケットによって提供される）に加えて、テスタ資源を指定するためにいくつかの属性を用いることができることに留意されたい。たとえば、試験固有、ベンダ固有、および／または試験システム固有の場合がある、チャネルのための特定のハードウエア構成を定義するために、複数のオプションを用いることができる。これらのオプションは、ピンモードオプションを用いて記述され、ピンモードオプションファイルを通して入手できるようになるであろう。

ピンモードオプション定義は、テスタチャネルのための特殊なオプションまたはモードの構成をサポートするであろう。たとえば、これを用いて、チャネルを選択し、チャネル多重化を構成することができる。ピンモードオプションはチャネル構成をかなり変更することが必要となる場合もあるので、試験計画初期フローの一部としてのみ用いられることが好ましい。ピンオプション構文は、ベンダによって定義されるオプションをサポートする。一例が以下に示される。

PinModeOptions
{
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

インストール中に、ホストコンピュータ上に存在するインストールおよび構成管理システム（ＩＣＭ）が、Tester_ACTIVE_CONFIGSの値を設定することが好ましいであろう。ＩＣＭが上記のファイルのうちの１つの新たなバージョンを作成する度に、その新たなバージョンを、Tester_ACTIVE_CONFIGSによって指示される場所に置くであろう。上記の３つのファイルに加えて、シミュレーション構成ファイルのような他のシステム構成ファイルも、Tester_ACTIVE_CONFIGSによって指示される場所に置かれることに留意されたい。

［Ｂ．試験プログラム開発のための規則］
テスタシステムの２つの主なエンドユーザ向けコンポーネントのうちの１つが試験環境である。他のコンポーネントは、テスタがエンドユーザ（すなわち、試験技師および試験クラス開発者）に提供するプログラミングファシリティである。

プログラミング環境の主なコンポーネントは試験計画である。試験計画は試験クラス（すなわちTestで表される試験インターフェースの種々のインプリメンテーションである）を使用し、試験クラスは、特定のタイプの試験のための試験データおよびコードの分離を実現する。

その計画はC++試験プログラムとして直に書くことができるか、または試験計画記述ファイル内に記述することができ、そのファイルは試験プログラム発生プログラム（翻訳プログラム４０２）によって処理され、C++コードのようなオブジェクト指向コードが生成される。その後、生成されたC++コードをコンパイルして、実行可能試験プログラムを作成することができる。レベル、タイミングなどの試験クラスインスタンスを構成するために必要とされるデータは、試験計画記述ファイルにおいてユーザによって指定される。

試験プログラムは、１つのデバイス上で試験を実行するための詳細を指定する、１組のユーザ書込みファイルを含む。本発明の一実施形態は、ユーザがC++構成体を用いてこれらのファイルを書くことができるようにする複数組の規則を含む。

本発明の実施形態による要件のうちの１つは、オープンアーキテクチャ試験システムのモジュール性を追求することである。モジュール式の開発によって、ユーザが試験の種々の側面に関係する個々のコンポーネントを書くことできるようになり、それにより、これらのコンポーネントを種々の態様で様々に組み合わせて、１つの完全な試験プログラムを生成できるようになる。本発明の好ましい実施形態による試験プログラムは以下のような１組のファイルを含む。
ユーザ変数および定数のためのファイル*.usrv
仕様セットのためのファイル*.spec
レベルのためのファイル*.lvl
タイミングのためのファイル*.tim
試験条件グループのためのファイル*.tcg
ビン定義のためのファイル*.ddefs
カスタム関数および試験クラス用のファイルプリヘッダのためのファイル*.ph
カスタムタイプのためのファイル*.ctyp
カスタム変数のためのファイル*.cvar
試験計画のためのファイル*.tpl

上記のファイル拡張子は、ファイルのカテゴリ化を容易にする、推奨される決まりである。単一の試験プログラムは、単一の試験計画ファイルと、それがインポートするファイルとを含むことが好ましいであろう。「インポート」は、インポータ（インポートを指定するファイル）によって直に参照されるか、またはインポータによって直に参照されるいくつかの他のファイルによってインポートされるデータを有する他のファイルを指している。試験計画ファイルは、グローバル、フロー、およびそのファイル内の他のそのようなオブジェクトを定義することができるか、またはそのファイルは、他のファイルからこの情報をインポートすることができる。これらの規則によって、上記のコンポーネントのうちの任意のものが、その自らの個々のファイル内に存在できるようになるか、または試験計画ファイル内に直に並べられるようになる。試験計画は、Ｃ言語ｍａｉｎ（）関数に概念的に類似であることに留意されたい。

［試験プログラム主要項目］
・ユーザ変数および定数
・仕様セット
・レベル
・タイミング
・試験条件
・ビン定義
・プリヘッダ
・カスタムタイプ
・カスタム変数
・試験計画

試験プログラム識別子は、アルファベットの大文字または小文字で始まり、それに続いて、任意の数のアルファベット文字、数字またはアンダーバー（＿）を有することができることが好ましい。それは、以下に与えられる説明において提供されるいくつかのキーワードを有する。これらのキーワードは、Ｖｅｒｓｉｏｎのように、太字を用いて、本明細書のコード内で視覚的に特定される。キーワードは予約され、識別子として用いられないことが好ましい。｛，｝、（，）などのいくつかの特殊な記号、および他の記号があり、それらの記号が以下に説明される。

［試験オブジェクトのエラボレーション］
試験記述ファイルをインポートすることにより、インポート用ファイルが、インポートされるファイルによって利用可能であるオブジェクトの名前を参照できるようになる。これにより、インポート用ファイルは、インポートされるファイルによって命名されるオブジェクトを参照できるようになる。ピン記述ファイルxxx.pinをインポートするソケットファイルaaa.socについて考える。同じくxxx.pinをインポートする別のbbb.socファイルも存在することができる。しかしながら、これらのインポートのいずれによっても、xxx.pinによって記述されるオブジェクトは発生しない。それらは、既に存在するものと仮定されるオブジェクトを参照するだけである。

そのようなオブジェクトがいつ発生するかという疑問が生じる。これは、試験計画ファイルが根本的に異なる場合である。Ｃとの類似性から、その中にmain()ルーチンを有するファイルが存在するであろう。試験計画ファイル内の「Import」ステートメントは、これらのオブジェクトをエラボレートするであろう。すなわち、「Import」ステートメントによって、これらのオブジェクトが発生する。以下に示される試験計画mickey.tplによって、xxx.pinおよびaaa.soc内のオブジェクトがエラボレートされる。

# File for Mickey's Test Plan
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
{
・・・
}

試験計画にxxx.pinをインポートすることにより、xxx.pinにおいて宣言される全てのピンおよびピングループオブジェクトがエラボレートされる。これは、「ファイルxxx.pinがエラボレートされる」のように記述される。試験計画が、エラボレートされる必要がある全てのファイルを直にインポートする必要はない。以下の２つのステートメントのうちのいずれかが正しい場合には、ファイルｘがファイルｙによってインポートされる。
１．ｙがｘを命名するインポートステートメントを有する。または、
２．ｘがｚによってインポートされ、ｙがｚを命名するインポートステートメントを有する。

試験プログラムがコンパイルされるとき、それは、試験計画によってインポートされるファイル内の全てのオブジェクトをエラボレートするであろう。１つの試験計画によってインポートされる１組のファイルは、それらのファイルがエラボレートされる順序をもたらすようにトポロジカルソートされる。１つの試験計画によってインポートされる１組のファイルは、その試験計画のインポート閉包と呼ばれる。１つの試験計画のインポート閉包がトポロジカルソートできない場合には、インポートサイクルが存在しなければならない。そのような状況は誤っており、コンパイラによって拒否されるであろう。

［ユーザ変数および定数］
ユーザ変数および定数を用いて、グローバル変数および定数が定義されるであろう。それらの定数は、その値がコンパイル時に固定され、変更することができないオブジェクトである。たとえば、最大整数値は定数になるであろう。一方、変数に結び付けられる式は、ＡＰＩを介して、実行時に変更することができる。
・整数
・符号なし整数
・ダブル
・ストリング
・ボルト単位の電圧（Ｖ）
・ボルト／秒単位の電圧スルー（ＶＰＳ）
・アンペア単位の電流（Ａ）
・ワット単位の電力（Ｗ）
・秒単位の時間（Ｓ）
・メートル単位の長さ（Ｍ）
・ヘルツ単位の周波数（Ｈｚ）
・オーム単位の抵抗（Ｏｈｍ）
・ファラド単位の静電容量（Ｆ）

タイプ整数、符号なし整数、ダブルおよびストリングは基本タイプと呼ばれる。基本タイプは測定単位を持たない。基本タイプでない基本的なタイプはダブルであり、関連する測定単位およびスケールを有する。指数記号は、共通の工学指数記号である。
・ｐＦ（ピコファラド）の場合のような、１０−１２の場合のｐ（ピコ）
・ｎＳ（ナノ秒）の場合のような、１０−９の場合のｎ（ナノ）
・ｕＳ（マイクロ秒）の場合のような、１０−６の場合のｕ（マイクロ）
・ｍＶ（ミリアンペア）の場合のような、１０−３の場合のｍ（ミリ）
・ｋＯｈｍ（キロオーム）の場合のような、１０＋３の場合のｋ（キロ）
・ＭＨｚ（メガヘルツ）の場合のような、１０＋６の場合のＭ（メガ）
・ＧＨｚ（ギガヘルツ）の場合のような、１０＋９の場合のＧ（ギガ）

ユーザ変数および定数を有する別個のファイルは拡張子.usrvを有するであろう。以下は、いくつかのグローバル定数を有するファイルの一例である。いくつかの変数を有するファイルの一例は後に与えられる。

# --------------------------------------------------------
# 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;
}

先に宣言された１組のUserVarsは「＝」の左側に変数の定義を有するものと見なされる。結果として、１つの変数または定数の定義は一度だけ行われることが好ましく、初期化されるべきである。

先に述べられたように、定数は、一旦定義されたなら、変更されないであろう。１つの定数に結び付けられる式は、予め定義された定数と、リテラル値とを含むことができる。一方、変数はＡＰＩを介して変更することができる。変数に結び付けられる式は、予め定義された変数と、定数と、リテラル値とを含むことができる。

各変数は実行時に保持される式オブジェクトに結び付けられる。これは、実行時に変数に関連する式を変更し、その後、全ての変数を再評価する能力を与える。式オブジェクトは、変数または定数定義の右辺のパースされた形である。１つの実施形態では、実行時に定数を変更するためのファシリティは提供されない。それらの値は、コンパイル時に固定されることが好ましい。

グローバルを有する任意の数のそのようなファイルが、１つの試験計画のインポート閉包内に存在することができる。上記のグローバルファイルは１組の数値限界であるが、ここでは、工学測定単位を用いる１組の工学グローバルおよびいくつかのランダムユーザ変数である。

# --------------------------------------------------------
# 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};
}

コンパイラは、単位およびタイプが一致することを確認することが好ましい。電圧×電圧は電力になるので、上記のPlowおよびPHighのための式はコンパイルされることに留意されたい。しかしながら、以下に記載されるようなステートメントは典型的にはコンパイルされないであろう。

#
# Does not compile because a Current and a Voltage cannot be added
# to yield a Power.
#
Power Pxxx = IHigh + VInHigh;

コンパイラは、ある特定の自動タイプ変換を可能にするであろう。

Power Pxxx = 2; # Set the power to 2.0 watts
Integer Y = 3.6; # Y gets assigned 3
Power Pyyy = Y; # Pyyy gets assigned 3.0 watts
Double Z = Pyyy; # Pyyy gets converted to a unitless Double

ダブル、符号なし整数および整数への明示タイプ変換も許される。

Power Pxxx = 3.5;

# 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

中間の基本タイプに変換することにより、非関連タイプ間の変換も可能である。

Power Pxxx = 3.5;

# Explicit type conversion is required.
Length L = Double (Pxxx); #L becomes 3.5 meters
Voltage V = Integer (Pxxx); #V becomes 3.0 Volts.

試験計画オブジェクトは、名前及びその関連する式、値並びにタイプを含むコレクションであるUserVarsクラスを提供する。ユーザ変数は、デフォルトユーザ変数コレクションに、または命名ユーザ変数コレクションに入ることができる。上記の例のUserVars宣言は、指定された名前はなく、デフォルトコレクションに入る。しかしながら、以下のように、コレクションを明示的に命名することができる。

# Declare X and Y in the MyVars UserVars collection.
UserVars MyVars
{
Integer X = 2.0;
#
# Refers to the above X, and to the globally
# available MaxInteger from the default
# UserVars collection.
#
Integer Y =MaxInteger - X;
}
# Declare X, Y1 and Y2 in the YourVars UserVars collection.
UserVars YourVars
{
Integer X = 3.0;
# Refers to the X from MyVars.
Integer Y1 =MaxInteger - MyVars.X;
# Refers to the X declared above.
Integer Y2 =MaxInteger - X;
}
# More variables being added to the MyVars collection
UserVars MyVars
{
#
# Refers to X and Y from the earlier declaration
# of MyVars.
#
Integer Z = X + Y;
}

UserVarsコレクション内の名前分解は以下のように進められる。
名前が修飾されている、すなわち名前が点によって分離される２つの部分を含む場合には、変数は、その点の前にある部分によって名前を付けられる、名前付きユーザ変数コレクションからもたらされる。したがって、上記のMyVars.XはMyVarsコレクション内のＸを指している。デフォルトユーザ変数コレクションを明示するために、名前「_UserVars」を用いることができる。

その名前が修飾されず、かつそのコレクション内に同じ名前の定数または変数が存在する場合には、名前はその定数または変数に分解する。

そうでない場合には、その名前はデフォルトユーザ変数コレクション内の定数または変数に分解する。

UserVarsコレクション内の定義のブロックの評価は、最初の定義から最後の定義まで順番に生じるものと考えることができる。これには、各変数が用いられる前に、その変数が定義される必要がある。

さらに、UserVarsコレクションのためにいくつかの定義ブロックが存在することができ、各ブロックがいくつかの変数を定義している。これらの定義ブロックは全て、試験計画において宣言された順序で評価されるものと考えることができ、その後、各ブロックの変数も宣言された順序で検査される。

最後に、いくつかのUserVarsコレクションが存在することができ、各UserVarsコレクションがいくつかの定義ブロックにわたって変数を定義する。再び、それらの変数は全て、宣言された順序で初期化されるものと考えることができる。こうして、上記の例では、評価順序は、MyVars.X、MyVars.Y、YoursVars.X、YoursVars.Y1、YoursVars.Y2、MyVars.Zになるであろう。

UserVarsコレクションが別のコレクションからの変数を用いるとき、UserVarsコレクションはその変数の生データだけを用いることが好ましい。コレクション間では従属性情報は保持されない。それゆえ、従属性に基づく再評価は、ただ１つのコレクションに限定することができる。

各ユーザ変数コレクションはC++ UserVarsクラスのインスタンスを指している。C++ UserVarsクラスのデフォルトオブジェクトは「_UserVars」と名前を付けられる。名前付きでないUserVars宣言内の変数は、デフォルトユーザ変数コレクションからのものであり、このデフォルトオブジェクトに追加される。名前付きユーザ変数コレクション内の変数は、その名前を有するC++ UserVarsクラスのオブジェクトに追加される。上記の例では、「MyVars」C++オブジェクトは、変数Ｘ、ＹおよびＺを有することになるであろう。

［ユーザ変数のためのC++］
ユーザ変数は、nameストリング、const/varブーリアン、列挙された値としてのtypeおよび式木としてのexpressionを有するｎ個組のコレクションとして実装される。１つの名前の式は、以下のコールによってセットすることができる。

enum ElemenaryType {UnsignedlntegerT, IntegerT,
DoubleT, VoltageT,...};
Status setExpression(const String& name,
const bool isConst,
const elementaryType,
const Expression& expression);

タイプExpressionは、アサインメントの右辺に対応するテキストのパースされた形であるタイプである。UserVarsのグローバルに利用可能なインスタンスが存在するであろう。たとえば、limits.usrv内の１組のユーザ変数の集合（pageを参照）は、以下に示される１組のコールによって実装される。

_UserVars.setExpression ("MaxInteger", true, IntegerT,
Expression (2147483647));
_UserVars.setExpression ("MinInteger", true, IntegerT,
Expression(-2147483648));
_UserVars.setExpression ("Epsilon", true, DoubleT,
Expression (2.2204460492503131e-016));
_UserVars.setExpression ("MaxDouble", true, DoubleT,
Expression (1.7976931348623158e+308));
_UserVars.setExpression ("MinDouble", true, DoubleT,
Expression("- MaxDouble") );
_UserVars.setExpression("ZeroPlus", true, DoubleT,
Expression(2.2250738585072014e-308));
_UserVars.setExpression("ZeroMinus", true, DoubleT,
Expression("- ZeroPlus") );

以下は、myvars.usrvにおいて宣言される変数のために実行されることになるC++ステートメントである。

myVars.setExpression("VInLow", true, VoltageT,
Expression(0.0));
myVars.setExpression("VInHigh", true, VoltageT,
Expression(5.0));
myVars.setExpression("DeltaT", true, TimeT,
Expression(2.0E-9));
myVars.setExpression("ClkTick", true, TimeT,
Expression (1.0E-9));
myVars.setExpression("R10", true, ResistanceT,
Expression(10.0E+3));
myVars.setExpression("ILow", false, CurrentT,
Expression (1.0E-3));
myVars.setExpression("IHigh", false, CurrentT,
Expression(2.0E-3));
myVars.setExpression("PLow", false, PowerT,
Expression("ILow * VInLow"));
myVars.setExpression("PHigh", false, PowerT,
Expression("IHigh * VInHigh"));
myVars.setExpression ("ABusVil[0]", false, VoltageT,
Expression(1.0));
myVars.setExpression("ABusVil[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));

上記のコードでは、Expressionクラスは式のパースされた形を表すコンストラクタを有することが好ましい。Expressionはいくつかのコンストラクタを有し、その中には、ストリングリテラルを受け取り、それをパースするコンストラクタ、およびストリングリテラルを受け取り、ストリングリテラルとしてだけ用いる別のコンストラクタが含まれる。これらは、読みやすくするためにこれまでは指定されていない付加的なパラメータによって区別される。

デフォルトユーザ変数コレクション内のユーザ変数は、クラスUserVarsの_UserVarsオブジェクトによって管理されるであろう。名前付きユーザ変数コレクションXxx内のユーザ変数は、Xxxと名前を付けられたUserVarsオブジェクトによって管理されるであろう。

［UserVarsのためのランタイムＡＰＩ］
これらの名前および式を含むC++ UserVarsクラスは、アプリケーションプログラムインターフェース（ＡＰＩ）をエクスポートし、実行時にこれらの値を評価し、変更する。UserVarsに関連する式の変更は、UserVarsがいつ再評価されるか、およびその評価の影響が何であるかという問題にも対処する。

最初に、１つの変化の結果としてのUserVarsの再評価がいつトリガされるべきであるかの問題を考える。それが、式に変更を加えるときに直ちにトリガされる場合には、ユーザは、再評価をトリガする前に、一連の関連する変更を加えることができないであろう。したがって、再評価は、ユーザによる明示的なコールによってトリガされる。

次に、再評価の影響を考えることができる。好ましい実施形態によれば、３種類の再評価が利用可能である。

UserVars Collection Re-evaluationは、ただ１つのUserVarsコレクションに限定される再評価である。この演算の意味は、このコレクションの全ての変数をもう一度、再評価することである。

UserVars Targeted Re-evaluationは、ただ１つの名前に結び付けられる式に対する変更に限定される再評価である。これにより、ユーザは、ただ１つの名前の式を変更できるようになり、この特定の変更だけを考慮に入れて、コレクションの再評価が行われるであろう。

UserVars Global Re-evaluationは、全てのUserVarsコレクションの再評価である。これは基本的には、全てのUserVarsコレクションの再評価を、宣言された順序でトリガするので、非常にコストがかかる。

上記の再評価は全て、UserVarsを再評価した後に、Level、Timingなどの従属オブジェクトを再評価するであろう。従属オブジェクトは、それが再評価を必要とすることを表すダーティビットを有するであろう。UserVarsコレクションがプログラムによって変更されるときはいつでも、それは、全ての従属オブジェクトにおいてダーティビットもセットするであろう。これは、従属オブジェクトの再評価をトリガするであろう。

要約すると、名前付きUserVarsコレクションは、再評価の影響の問題を封じ込めるのを助ける。再評価は通常、ただ１つのコレクションに限定される。UserVarsを用いる１つの単純な方法は、デフォルトUserVarsコレクションだけを用いることであろう。そのように、変更を加えることの波及効果は、全てのUserVarsに起こり得る。この波及効果は、いくつかの名前付きUserVarsコレクションを有することによって制限することができる。

多数のコレクションが互いからの変数を参照することができるが、それらの変数に結び付けられる値は使用時に固定される。UserVarsコレクション間の従属性は保持されない。

基本タイプXxx（符号なし整数、電流、電圧など）毎に、値をゲットするためのメソッドは、以下の通りである。

Status getXxxValue(const String& name, Xxx& value) const;

値を直にセットするためのメソッドは存在しないので、それは、式をセットするためのコールと、その後のreevaluateCollection()へのコールとを通して行われることに留意されたい。

式をゲットし、セットするためのメソッド。setExpression()コールを用いて、これまでに定義されていなかった新たな変数を定義することもできる。

enum elementaryType
{
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()コールは、その式の結果として循環的な従属性が生じる場合には、失敗する可能性がある。たとえば、以下の２つのコールが行われる場合には、第２のコールは、循環的な従属性による失敗によって失敗するであろう。

setExpression ("X", true, IntegerT, Expression("Y+1"));
setExpression ("Y", true, IntegerT, Expression("X+1"));

これは、名前に結び付けられる値が式であり、アサインメントでないためである。変数の値が変更されるとき、直接的および間接的に従属する名前を全て再評価するためのメソッドが提供される。上記の一対の式のような式の結果として、循環的な従属性が生じ、それは許容されない。

このＡＰＩは典型的には要求されていない再評価をサポートしないことに留意されたい。setExpression()へのコールでは、変数、およびその変数に従属する全ての他の変数が自動的には再評価されない場合がある。全ての変数に結び付けられる値は、reevaluateCollection()（以下）へのコールが生じるまで、変更されないままであろう。

特定の名前が定数であるか否かを判定するためのメソッド。

Status getIsConst(const String& name, bool& isConst);

タイプをゲットするためのメソッド。

enum ElementaryType
{
UnsignedIntegerT, IntegerT, DoubleT, VoltageT, ...
};
Status getType(const String& name,
ElementaryType& elementaryType) const;

UserVars Collection Re-evaluationメソッド。

Status reevaluateCollection();

そのクラスは、全ての変数およびそれらの従属する変数に関連する式を保持するであろう。このメソッドがコールされるとき、全ての変数が再評価されるようになるであろう。

UserVars Targeted Re-evaluationメソッド。

Status reevaluateTargeted(const String& var);

そのクラスは、全ての変数およびそれらの従属する変数に関連する式を保持するであろう。このメソッドがコールされるとき、名前付き変数、およびその従属変数の全てが再評価されるようになるであろう。
・UserVars Global Re-evaluationメソッド。

static Status reevaluateAllCollections();

そのクラスは、全ての変数およびそれらの従属する変数に関連する式を保持するであろう。このメソッドがコールされるとき、全てのUserVarsコレクション上で、reevaluateCollection()が不特定の順序でコールされる。

特定の名前が定義されるか否かを判定するためのメソッド。

StatusgetIsDefined(const String& name, bool& isDefined) const;

現在定義されている全てのユーザ変数を判定するためのメソッド。

Status getNames(StringList& names) const;

現在定義されている変数を削除するためのメソッド。

Status deleteName(const String& name);

この演算は、その名前が他の変数を含む式において用いられる場合には、失敗するであろう。
・所与の変数または定数に従属する変数および定数のリストをゲットするためのメソッド。

Status getDependents(const String& name, StringList& dependents);

［仕様セット］
仕様セットは、セレクタに基づいて値を取り込むことができる変数のコレクションを供給するために用いられる。たとえば、セレクタMinnie、Mickey、GoofyおよびDaisyを用いる以下の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; }
}

セレクタGoofyを有する上記の仕様セットは以下のように連想するであろう。

xxx= 3.0;
yyy = 30;
zzz =MaxInteger - xxx - 2;
www = yyy + zzz;

Testが記述されるときに、仕様セットにおいてセレクタをセットする演算が以下に説明されるであろう。

構文的には、仕様セットａは、セレクタのリスト（上記の例では、Minnie、Mickey、GoofyおよびDaisy）と、変数定義のリスト（上記の例では、xxx、yyy、zzzおよびwww）である。変数の定義は、セレクタのリストと同じ長さの式のリストを含むか、またはただ１つの式を含む。

概念的には、仕様セットは式の行列と考えることができ、その列がセレクタであり、その行が変数であり、そのエントリが式である。特定のセレクタ（列）が各変数（行）を特定の式（エントリ）に結び付ける。そのリストがただ１つの式を有する場合には、そのリストは、セレクタが存在するのと同じ数だけ式が繰り返される行を表す。

仕様セットは２つの別個の状況において現れることができる。仕様セットは、.specファイルにおいて別個に宣言されることができ、その場合には、それらの仕様セットは先に示されたように現れる。これらは名前付き仕様セットである。別の状況では、ローカル仕様セットをTest Codition Group内で宣言することができる。そのような宣言では、仕様セットは名前を与えられないであろう。取り囲んでいる試験条件グループに対してだけ意味のあるローカルな仕様セットが存在するであろう。

名前付きユーザ変数コレクションの後に、名前付き仕様セットをモデル化することができる。上記の仕様セットは、Aaaと名前を付けられるUserVarsコレクションとしてモデル化されることができ、それはxxx[Minnie]、xxx[Mickey]、xxx[Goofy]、xxx[Daisy]、yyy[Minnie]などのための式を有するであろう。ある試験の状況において特定のセレクタ（たとえばMickey）が選択されるとき、xxx、yyyおよびzzzの値は変数名および仕様セット名から得られる。

試験条件グループは、ローカル仕様セットか、名前付き仕様セットへの参照かのいずれかである、多くても１つの仕様セットを有することができる。ローカル仕様セットは、試験条件グループの状況においてのみ現われ、明示される名前を持たない。そのような仕様セットは、取り囲んでいる試験条件グループの名前によって定義される暗黙の名前を有する。いくつかの仕様セットおよびいくつかのUserVarsコレクションが現われる時点で、１つの試験条件グループ内の１つの名前を分解するために、以下の規則が適用される。
１．その名前が修飾されている場合には、その名前は、名前付きユーザ変数コレクションにおいて分解されなければならない。
２．その名前が修飾されていない場合には、その名前は、その名前が試験条件グループにおいて宣言される場合にはローカル仕様セットにおいて、それが試験条件グループにおいて参照される場合には名前付き仕様セットにおいて分解される。
３．その名前が上記の規則によって分解されない場合には、その名前はデフォルトユーザ変数コレクションにおいて分解される。

これらの規則を例示するために、Test Conditions Group（後に説明されることになる）を用いる以下の例について考える。

Version 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.
}

仕様セット内の名前の分解（上記の規則）では、そのセットのセレクタが、名前分解が要求される時点で使用可能にされることが要求される。これは、試験条件グループが、セレクタを指定することによって１つのTestにおいて参照されることになるという事実によって強要されるであろう。

［仕様セットのためのC++］
上記の規則を用いるとき、仕様セットは、C++ SpecificationSetクラスによって実装されることができる。SpecificationSetクラスは基本的には、UserVarsクラスと同じＡＰＩを有するが、セレクタのための余分なストリングパラメータがあることが異なる。したがって、このＡＰＩは詳細には説明されない。

全ての名前付き仕様セットは、その名前のC++オブジェクトに関連付けられることが好ましい。ある試験条件グループの状況におけるローカル仕様セットは、その試験条件グループに固有の名前を有するであろう。そのローカル仕様セットが定義される試験条件グループの状況以外では、ローカル仕様セットの変数を参照することは違法である。

［レベル］
Levelは、ピンおよびピングループのパラメータを指定するために用いられる。それは、以下の形の宣言のコレクションである。

<pin-or-pin-group-name>
{
<pin-param-1> = xxx;
<pin-param-2> = yyy;
...
}

そのような宣言は、名前付きピンまたはピングループの種々のパラメータの設定を指定する。たとえば、以下の例に示されるように、そのようなステートメントを用いて、InputPinsグループ内の全てのピンのためのVIL値をセットすることができる。

# ------------------------------------------------------
# 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
{
# ...
}

上記のように、各Levelブロックは、多数のレベル項目から構成されることが好ましく、各レベル項目は１つのピンまたはピングループのためのパラメータを指定する。各レベル項目は多数の資源パラメータを指定することができる。これらのレベル値の設定のための実行時の意味は以下の通りである。

Levelsブロックのレベル項目は宣言された順序で処理される。２つ以上のレベル項目において生じるピンがあれば、何度でも処理されることになる。ただ１つのパラメータのための値の多数の仕様は、指定された順序で保持され、適用されるべきである。

１つのレベル項目内の資源パラメータは、それらが指定された順序で処理される。

次のレベルグループをセットする前に、Delayステートメントによって、レベルをセットするプロセスが概ね指示された持続時間だけ中断する。実際の待ち時間は、指定された遅延を中心にして、小システムによって規定される範囲内にあることができる。したがって、遅延がｔ秒であった場合には、実際の遅延は以下の式を満たすであろう。

t - Δt <= actual-wait <= t + Δt

Ｄｅｌａｙステートメントは、Levels指定を多数のサブシーケンスに分割し、各サブシーケンスは、処理するための別個のTest Condition Memory設定を必要とするであろう。

次のレベルグループをセットする前に、MinDelayステートメントによって、レベルをセットするプロセスが少なくとも指定された持続時間だけ中断する。実際の待ち時間は、小システムによって規定される範囲内にあり、指定された最小遅延の最小値を有することができる。したがって、最小遅延がｔ秒であった場合には、実際の遅延は以下の式を満たすであろう。

t <= actual-wait <= t + Δt

MinDelayステートメントは、Levels指定を多数のサブシーケンスに分割し、各サブシーケンスは、処理するための別個のTest Condition Memory設定を必要とするであろう。

各ピンまたはピングループ名はピン記述ファイル（接尾部.pin）内の厳密に１つの資源において指定され、それゆえ、資源ファイル（接尾部.rsc）において指定される、ある１組の実用的な資源パラメータを有する。名前を付けられる全てのパラメータはこの１組の実用的な資源パラメータの中からもたらされるべきであり、それらの値をセットするために用いられる式と同じ基本タイプを有するべきである。資源パラメータの名前およびタイプについての情報は資源ファイルからもたらされる。

資源ファイルResource.rscは暗黙のうちにインポートされ、テスタにdpinおよびｄｐｓのような標準的な資源のパラメータのための名前およびタイプを与える。

資源パラメータは、UserVarsを用いることができる式、および名前付きの仕様セットまたは現時点で見ることができるローカル仕様セットからの値を割り当てられる。

dpsピン資源は、特殊なパラメータPRE_WAITおよびPOST_WAITを有する。PRE_WAITパラメータは、電源ピンがその目標電圧に達する時刻から、パターン生成を開始することができる時刻まで経過するのにかかる時間を指定する。ＰＯＳＴ＿ＷＡＩＴパラメータは、パターン生成が停止した時刻から、電源ピンが遮断する時刻まで経過するのにかかる時間を指定する。

またdpsピンは、電圧パラメータがその最終値に如何に達するかも指定する。それらのピンは、全ての他のピンパラメータのように、単に１つの式によって電圧パラメータを指定することができる。その場合、その値は、ハードウエアがそれを可能にするときに、達成されるであろう。またそれらのピンは、Slewステートメントを用いて、それを指定することもできる。Slewステートメントは、電源電圧が、指定された絶対Voltage Slew Rateを有する傾斜で、その初期値から最終値に達することを指定する。

［LevelsのためのＣ＋＋］
上記の規則を用いて、以下の演算をサポートするC++ Levelsオブジェクトを書くことができる。
・以下の演算が行われる。

Status setParameter(const String& pinOrPinGroupName,
const String& parameterName,
ElementaryType elementaryType,
const Expression& Expression);

この演算は、１つの式を、１つのピンまたはピングループのパラメータに結び付ける。たとえば、dpin.InPins VIH値は以下の式によってセットされる。

setParameter ("InPins", "VIH", VoltageT,
Expression("v_ih + 1.0");

この演算は、Levelsオブジェクト内の全ての宣言のために何度もコールされるであろう。
・以下の演算が行われ、その演算は、先に説明されたように、全ての所定のモジュールレベルインターフェースをくまなく調べて、発行し、パラメータの全てのレベルを、指定された順序で割り当てるであろう。セレクタパラメータを用いて、先に指定された規則に従って、それらの式内の名前が分解される。

Status assignLevels(const String& selector);

［試験条件グループ］
試験条件グループ部分言語は、仕様、タイミングおよびレベルの記述を一緒にパッケージ化する。Timingオブジェクトは多くの場合に、複数のパラメータを用いて指定される。複数のパラメータを複数のタイミングにおいて用いて、種々のパルスの前縁および後縁を指定することができる。同様に、Levelsは種々の電圧レベルの最大値、最小値および典型値を指定することによりパラメータ化することができる。試験条件グループ（ＴＣＧ）オブジェクトは、仕様と、これらの仕様に基づくTimingsおよびLevelsのインスタンシエーションとを一纏めにする。

TestConditionGroup宣言はオプションのSpecificationSetを含む。SpecificationSet宣言には、インライン化された（そして名前付きでない）ローカルSpecificationSetを用いることができるか、または他の場所で宣言された名前付きSpecificationSetへの参照を用いることができる。ＴＣＧ宣言内のオプションのSpecificationSet宣言には、少なくとも１つのLevelsまたはTimings宣言が続く。それは、複数のLevelおよび複数のTimingの両方を任意の順序で有することができる。しかしながら、それは、２つ以上のLevelsおよびTimings宣言を有することは許されない。これらの制約は構文的に強制される。

ＴＣＧ内の仕様セット宣言は、それが名前を持たないことを除いて、別個に宣言される仕様セットと同じである。その名前は暗黙のうちに、取り囲んでいるＴＣＧの名前になる。Timings宣言は、指定されたタイミングファイルからのTimingsオブジェクトのただ１つの宣言を含む。ここに示されるのは、試験条件グループを有するファイルの一例である。

# ---------------------------------------------------------
# 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;
}

上記の例では、試験条件グループＴＣＧ１は、「min」、「typ」および「max」の名前を付けられた３つのセレクタを有する仕様セットを記述する。任意の数の別個のセレクタが存在することができる。仕様セットの本体内で、それらのセレクタに対応する３個１組の値で、変数v_il、v_ih、t_leおよびt_teが初期化される。したがって、上記の例では、セレクタ「min」を有するＴＣＧ１のインスタンスが、変数v_ilを第１の数値と結合するであろう（vInputLow+0.0）。再び、１つの仕様セットのための複数のセレクタがユーザによって定義され、任意の数のセレクタが許される。唯一の要件は以下の通りである。

１つの仕様セットのセレクタは固有の識別子である。

その仕様セットにおいて指定される各値は、その１組のセレクタと厳密に同じ数の要素を有する値のアレイに関連付けられる。ｉ番目のセレクタを選ぶことにより、各値が、それらの値の関連するベクトルのｉ番目の値に結び付けられるであろう。

ＴＣＧ内の仕様セットに続いて、Levels宣言またはTimings宣言、あるいはその両方が存在することができる。Levels宣言を用いて、種々のピンパラメータのためのレベルがセットされる。仕様セットにおいて特定される変数を用いて、これらのレベルがセットされることになり、それにより、ＴＣＧを初期化するために用いられるセレクタに基づいて、ピンパラメータのための種々の実際の値を動的に結合できるようになる。

これを例示するために、セレクタ「min」を使用可能にするTestを考える。ページ上に与えられる仕様セットCHIP3Levelsを参照すると、InPinsグループ内のピンのためのピンパラメータ「ＶＩＨ」は、以下の宣言によって式（v_ih+1.0）に初期化されるであろう。

InPins { VIL = v_il; VIH = v_ih + 1.0; }

セレクタ「min」が使用可能にされるとき、これは（VInHigh+0.0+1.0）に分解する。同様に、Timingsオブジェクトは、仕様セット変数の選択された値に基づいて初期化することができる。TimingsおよびLevels宣言の両方を有する必要はない。以下の例によって例示されるように、いずれかがそれだけで存在することができるか、または両方が任意の順序で存在することができる。

# ------------------------------------------------------
# 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;
}

しかしながら、１つのＴＣＧ内に２つ以上のTimingsおよび２つ以上のLevelsが存在すべきでないことに留意されたい。したがって、要約すると、TimingsまたはLevelsの少なくとも一方が存在すべきであり、かつ多くてもそれぞれの１つが存在すべきである。

［試験条件］
TestConditionオブジェクトは１つのＴＣＧを特定のセレクタに結び付ける。一旦、ＴＣＧが先に示されるように宣言されたなら、以下に示されるように、TestConditionオブジェクトを宣言することができる。

TestCondition TCMin
{
TestConditionGroup = TCG1;
Selector = min;
}
TestCondition TCTyp .
{
TestConditionGroup = TCG1;
Selector = typ;
}
TestCondition TCMax
{
TestConditionGroup = TCG1;
Selector = max;
}

これらのTest Conditionは、以下のように、１つのTest Planにおいてインスタンス化されるであろう。

#
# 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;
}

［ＴＣＧ（試験条件グループ）内の名前分解］
試験条件グループ内の名前の分解は先に説明された。しかしながら、これらの規則が繰返し述べられ、再び以下に与えられる。
１．その名前が修飾されている場合には（ページを参照されたい）、その名前は、名前付きユーザ変数コレクションにおいて分解されなければならない。
２．その名前が修飾されていない場合には、その名前は、その名前が試験条件グループにおいて宣言される場合にはローカル仕様セットにおいて、それが試験条件グループにおいて参照される場合には名前付き仕様セットにおいて分解される。
３．その名前が上記の規則によって分解されない場合には、その名前はデフォルトユーザ変数コレクションにおいて分解される。

［ＴＣＧランタイム］
試験条件グループは以下の実行時の意味を有する。

Test（FunctionalTestなど）は、インスタンス化されたTestConditionを用いて、そのSpecificationSetからの特定のセレクタを有するＴＣＧを参照するであろう。このセレクタは、SpecificationSet内の各変数を、選択されたセレクタに関連付けられる値に結び付けるであろう。その後、変数とそれらの値とのこの結び付きを用いて、LevelsおよびTimingsが判定されるであろう。

TestConditionGroup内のパラメータLevelsは、Levelsブロックの提示順に、順番にセットされることが好ましい。したがって、CHIP3Levelsブロックでは、パラメータレベルがセットされることになる順序は以下の通りである（表記法：<resource-name>.<resource-parameter>）。
・InputPins.VIL
・InputPins.VIH
・OutputPins.VIL
・OutputPins.VIH
・Clock.VOL
・Clock.VOH

このようなシーケンシングの順序によって、試験ライタは、電源の明示的なパワーシーケンシングを制御できるようになる。さらに、１つのレベル項目が２回生じ、１つのピンのために同じピンパラメータの名前を付ける場合には、そのピンパラメータは２回セットされるようになる。これは、プログラムによって生じることもできる。

１つのパラメータが以下のようなSlewステートメントによってセットされる場合には、それは、ＶＣＣが、毎秒±０．０１ボルトの電圧スルーレートの傾斜で、その現在の値から２．０ボルトの最終値に達することを意味する。

VCC = Slew(0.01,2.0 V);

仕様セット変数はＴＣＧ内のTimingsオブジェクトにも渡すことができる。その後、Timingsオブジェクトは、選択された変数に基づいて初期化されるであろう。そのような仕組みを用いて、たとえば、波形の前縁および後縁を指定することにより、Timingsオブジェクトをカスタマイズすることができる。

［ＴＣＧのためのＣ＋＋］
上記の規則を用いて、Test Condition GroupがC++ TestConditionGroupクラスにおいて宣言されることができ、それを以下のように初期化することができる。

以下のTestConditionGroupメンバ関数へのコールが行われる。

Status setSpecificationSet(SpecificationSet *pSpecificationSet);

その関数はTestConditionGroupのための仕様セットをセットするであろう。これは、ローカル仕様セット、または名前付き仕様セット、またはヌル（存在しない場合）のいずれかにすることができる。

以下のTestConditionGroupメンバ関数へのコールが行われる。

Status setLevels(Levels *pLevels);

その関数はTestConditionGroupのためのLevelsオブジェクトをセットするであろう。これは、ローカルに宣言されるレベルオブジェクト、または外部から宣言されるレベルオブジェクト、またはヌル（存在しない場合）のいずれかにすることができる。

以下のTestConditionGroupメンバ関数へのコールが行われる。

Status setTimings(Timings *pTimings);

その関数はTestConditionGroupのためのTimingsオブジェクトをセットするであろう。これは、外部から宣言されるTimingsオブジェクト、またはヌル（存在しない場合）のいずれかにすることができる。

［ビン定義］
Bin Definitionクラスはビン、すなわち、数多くのＤＵＴを試験した結果を要約するカウンタのコレクションを定義する。１つのＤＵＴを試験する過程において、そのＤＵＴは、たとえば特定の試験の結果を指示するために、任意のビンにセットされることができる。試験が進められるとき、そのＤＵＴは別のビンにセットされることができる。ＤＵＴが最終的にセットされるビンは、その試験の終了時の最後のそのような設定である。この最終的なビンのためのカウンタは、このＤＵＴの試験の終了時にインクリメントされる。ビン定義を有する別個のファイルは接尾部.bdefsを有するべきある。

ビン定義は階層的であることが好ましい。たとえば、最も外側にあるレベルでは、PassおよびFailと名前を付けられる２つのビンを有するPassFailBinが存在することができる。その際、いくつかのHardBinが存在することができ、そのうちのいくつかはPassビンにマッピングし、他のものはFailビンにマッピングする。HardBinは、PassFailBinのリファインメントと言われる。最後に、多数のSoftBin、すなわちHardBinのリファインメントが存在することができ、それらの多くが同じHardビンにマッピングする。以下はビンの階層を示す一例である。

# -------------------------------------------------------------
# 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;
}
}

上記の例では、複数の最も基本的なベースビンはBinGroup HardBinsである。いくつかの他のBinGroupがＸのリファインメントである場合には、BinGroupXは、ベースビンのグループであると言われる。したがって、BinGroup SoftBinsは複数のHardBinsのリファインメントであるので、BinGroup HardBinsはベースビンのグループである。複数のSoftBinsのビンはリーフビンと呼ばれる。他のBinGroupがＹのリファインメントでない場合には、BinGroupYは、リーフビンのグループであると言われる。

その中にただ１つのBinGroupZを有するBinDefsブロックの悪化した事例は、最も基本的な複数のベースビンのグループ、ならびにリーフビンのグループであるようなＺを有するであろう。BinGroup名は、その範囲がグローバルである。任意の数のBinDefsブロックが存在することができるが、宣言された複数のBinGroupsは識別できなければならない。１つのBinDefsブロックからのBinGroupは、別のBinDefsブロックからのBinGroupのリファインメントであることを許される。したがって、上記の例では、複数のSoftBinsは、複数のHardBinsからの別個のBinDefsブロック内に存在することができる。しかしながら、読みやすくするために、全てのBinGroupsが定義されているただ１つのBinDefsブロックを有することが強く推奨される。

ここで、合格したＤＵＴの数および不合格のＤＵＴの数をカウントするために、別のBinGroupを追加することにより、上記の階層を拡張することができる。

# -------------------------------------------------------------
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;
}
}

今度は、複数の最も基本的なベースビンがBinGroup PassFailBinsである。それらは典型的には任意のビンのリファインメントではない。BinGroup HardBinsは複数のPassFailBinsのリファインメントであり、ベースビンでもある。複数のSoftBinsは複数のHardBinsのリファインメントであり、リーフビンのグループである。上記の例は、その階層内に３つのBinGroupしか持たない。以下は、さらに複雑な階層である。

BinDefs
{
# 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 { ... }
}

この例では、AxおよびAyはAのリファインメントであり、AxxはAxのリファインメントであり、AyyはAyのリファインメントである。この例は、BinGroupBおよびBxも提供し、BxはBのリファインメントである。PassFailBins、HardBinsおよびSoftBinsと名前を付けられたBinGroupを有する上記のBinDefs宣言は、このセクションにおいて、継続的な例として用いられるであろう。

１つのBinGroup内の各ビンは、
１．識別子またはストリングリテラルのいずれかである名前と、
２．このビンが何を要約するかを記述する記述と、
３．このビンがリファインメントBinGroup内にある場合には、それがリファインメントであり、ベースビンとしても知られているビンの名前とを有する。

複数のPassFailBin内の２つのビンは「Pass」および「Fail」と名前を付けられる。複数のHardBin内の５つのビンは、「3GHzPass」、「2.8GHzPass」、「3GHzFail」、「2.8GHzFail」、「LeakageFail」と名前を付けられる。ビン名は、リテラルストリング、または識別子にすることができる。ビン名は１つのBinGroup内で固有でなければならないが、複数のBinGroupにわたって繰り返されることができる。しかしながら、BinGroup名は、範囲がグローバルであり、１つの試験計画にわたって固有でなければならない。

５つのHardBinのうち、ビン「3GHzPass」および「2.8GHzPass」はいずれも、PassFailBinの「Pass」ビンにマッピングする。複数のHardBinのうちの残りはPassFailBinのうちの「Fail」ビンにマッピングする。

最後に、８つのSoftBinが存在する。ＳＢＦＴ（ソフトビン機能試験）およびCacheの場合の3GHzにおける２つの不合格は「3GHzFail」HardBinにマッピングする。同様に、ＳＢＦＴおよびCacheの場合の2.8GHzにおける２つの不合格は「2.8GHzFail」HardBinにマッピングする。Leakageに起因する不合格はいずれも、それらが生じた速度にかかわらず、同じ「LeakageFail」HardBinにマッピングする。たとえば、最も粗い（最も外側のレベルでの）試験は、１つのＤＵＴが試験に合格するか、不合格であるかである。たとえば、リファインメントは、そのＤＵＴが特定の周波数、たとえば３ＧＨｚなどで、試験に合格するか、不合格であるかである。

ビンは以下に述べるようにTest Plan FlowItem内のＤＵＴに割り当てられる。TestPlan FlowItemはResult Clauseを有し、その中で、試験計画は、１つの試験を実施することから特定の結果が戻される結果として行われるべき動作および遷移を記述する。この時点で、SetBinステートメントが生じることができる。

# A FlowItem Result clause. It is described later.
Result 0
{
# Action to be taken on getting a 0 back from
# executing a test.

# Set the bin to SoftBin."3GHZPass" expressing that the
# DUT was excellent.
SetBin SoftBins."3GHzPass";
}

多くのSetBinステートメントは、１つのＤＵＴにおける試験を実行している過程において実行することができる。その試験が最終的に完了するとき、ランタイムは、そのＤＵＴのためにセットされた最終的なビン、および全てのそのリファインメントのためのカウンタをインクリメントするであろう。その試験の過程において実行される以下のSetBinステートメントを有するＤＵＴについて考える。

SetBin SoftBins."3GHzSBFTFaiI";
SetBin SoftBins."2.8GHzAllPass";

このＤＵＴは3GHz CacheおよびLeakage試験に合格したが、ＳＢＦＴ試験には不合格であったので、「3GHzSBFTFail」ビンに割り当てられる。その後、2.8GHzにおいて試験され、全ての試験に合格した。したがって、最終的なビン割当ては、「2.8GHzAllPass」ビンに対してなされ、それは、１組のSoftBinの中にある。この最終的な割当ては、以下のビンのカウンタをインクリメントするであろう。
１．複数のSoftBin「2.8GHzAllPass」
２．複数のHardBinのリファインメント「2.8GHzPass」
３．複数のPassFailBinのリファインメント「Pass」

その試験が完了するとき、ランタイムは、ＤＵＴの最終的なビン割当て、およびそれがリファインメントである全ての他のビンのためのカウンタをインクリメントするであろう。

SetBinステートメントはリーフビンにおいてのみ許される。ベースビンをセットすることは違法である。上記のカウンタインクリメントの意味は、以下のことを仮定する。
１．ビンがリーフビンである場合には、それは、１つのＤＵＴの試験の終了時にこのビンのためにSetBinステートメントが実行された回数である。
２．ビンがベースビンである場合には、それは、それがリファインメントであるビンのカウンタの和である。

こうして、上記の例では、１つのSetBinステートメントにおいて、SoftBinだけが許される。複数のHardBin「LeakageFail」のためのカウンタは、複数のSoftBin「3GHzLeakageFail」および複数のSoftBin「2.8GHzLeakageFail」のためのカウンタの和である。以下はビン定義に関するいくつかの規則である。
１．BinDefinitions宣言はいくつかのBinGroup宣言から構成される。
２．各BinGroup宣言は、名前と、それがリファインメントであるオプションのBinGroup名と、それに続くビン宣言のブロックとを有する。
３．ビン宣言は、名前と、それに続く記述と、オプションでそれに続く、このビンがリファインメントであるベースビンの名前とを含む。
４．ビン名はストリングリテラルまたはＩｄにすることができる。空ストリングは有効なビン名にすべきではない。ビン名は、BinGroup宣言内の名前の中で固有であるべきであるが、他のBinGroup宣言において同じ名前を用いることができる。
５．BinGroup宣言Xxxが別のBinGroup宣言Ｙｙｙのリファインメントである場合には、Xxx内の全てのビン宣言は、Yyyからのベースビンの名前を宣言しなければならない。したがって、複数のSoftBinは複数のHardBinのリファインメントであることを宣言されるので、複数のSoftBin内の各ビン宣言は複数のHardBinのビンのリファインメントである。
６．PassFailBinのような、別のBinGroup宣言のリファインメントでないBinGroup宣言は、ベースビンを宣言しないBin宣言を有することが好ましい。

ビンBbbは、Bbbがそのリファインメントである完全な１組のビンである１組のベースを有する。正式には以下のように定義される。
１．AaaがBbbのベースビンである場合には、AaaはBbbの１組のベース内にある。
２．Aaaの任意のベースもBbbの１組のベース内にある。

BinGroup名は１つのTestPlanにおいてグローバルである。

ビン名は１つのBinGroupに対してローカルである。

SetBinステートメントはリーフビンの場合にのみ許される。

［ビン定義のためのＣ＋＋］
上記の規則を用いて、１つのオブジェクトタイプBinGroupを、BinDefs宣言内のBinGroup宣言毎に構成することができる。クラスBinGroupはサブクラスLeafBinGroupを有するであろう。これらの２つのクラスの演算は同じであるが、BinGroup::incrementBinがC++保護演算であるのに対して、LeafBinGroup::incrementBinがC++公開演算であることを除く。

以下は、他のどのBinGroupのリファインメントでもないBinGroupまたはLeafBinGroupを構築するデフォルトコンストラクタである。

以下のコンストラクタは、所与のベースBinGroupのリファインメントであるBinGroupを構築する。

BinGroup(BinGroup& baseBinGroup);
LeafBinGroup(BinGroup& baseBinGroup);

以下のメソッドは１つのビンおよびその記述を定義する。

Status addBin(const String& binName,
const String& description,
const String& baseBinName);

それが最も基本的なベースビンである場合には、ベースBinNameパラメータは空ストリングでなければならない。

ビンカウンタをインクリメントするためのメソッド。

Status incrementBin(const String&binName);

この演算は、このビン、およびこのビンのベースである全てのビンのためのカウンタをインクリメントするであろう。その演算はクラスBinGroupにおいて保護され、クラスLeafBinGroupにおいて公開される。

ビンカウンタをリセットするためのメソッド。

Status resetBin(const String&binName);

この演算は、このビン、およびこのビンのベースである全てのビンのためのカウンタをリセットするであろう。

１つのビンについての情報をゲットするためのメソッド。

Status getBinDescription(const String& binName,
String& description);
Status getBaseBin(const String& binName,
BinGroup* pBaseBinGroup,
String& baseBinName);
Status getBinValue(const String& binName,
unsigned int& value);

現在定義されている全てのビン名を知るために繰返し子が与えられるであろう。

TestPlan状態は、BinGroup宣言毎に１つの、多数のBinGroupメンバを含むであろう。上記のBinDefinitionのためのＣ＋＋は以下のようになるであろう。

// TestPlan constructor
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");
...

１つのTestPlanのための状態は、未定義のBinGroup(NULL)に初期化されるm_pCurrentBinGroupと未定義のビン名（空ストリング）に初期化されるm_currentBinとを含む。SetBinステートメントが実行される度に、１つのコールによって、m_pCurrentBinGroupが指示された名前付きBinGroupに変更され、m_currentBinがグループ内の名前付きビンに変更される。

// Translation of: SetBin SoftBins."3GHzAllPass";
pTestPlan->setBin("SoftBins", "3GHzAllPass");

試験計画が実行を完了するとき、その試験計画は以下をコールして、このビンおよび全てのそのベースビンのカウンタがインクリメントされるようにする。
m_pCurrentBinGroup->incrementBin(m_currentBin);

BinGroupカウンタは、試験計画がエラボレートされるときにリセットされるが、試験が実行される度に再初期化されない。カウンタは、BinGroup::resetBinへの明示的なコールによってリセットすることができる。

［Ｃ．試験計画］
試験計画は、試験プログラムの主要構造と考えることができる。試験計画はファイルをインポートし、類似のコンストラクツインラインを定義することができる。こうして、いくつかのグローバルの定義を与えられたファイルをインポートし、付加的なグローバルズインラインを宣言することができる。

［Ｃ１．Test Plan FlowおよびFlowItem］
試験計画の重要な要素のうちの１つはFlowである。Flowは、有限状態機械をカプセル化する。それはいくつかのFlowItemを含み、それらのFlowItemはIFlowableオブジェクトを実行し、その後、別のフロー項目に遷移する。IFlowableを実行することは、IFlowableインターフェースをインプリメントするオブジェクトを実行することを含む。IFlowableインターフェースをインプリメントする一般的なオブジェクトはTestおよびFlowそのものである。

こうして、１つのFlowは、Testおよび他のFlowを実行し、その後、別のFlowItemへの遷移を実行するFlowItemを有する。それは、１つのIFlowableを実行することに起因する種々のリターン結果において、ユーザがカスタマイズしたルーチンをコールするための機会も提供する。典型的には、こうして、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 { ... }
}

フローFlowTest1の演算は以下の通りである。
１．FlowItem FlowTest1_Minを実行することで開始する。
２．FlowTest1_Minは機能試験、MyFunctionalTest1Minを実行する。この試験の詳細は、後に完全な試験計画が提示されるときに与えられる。
３．この試験を実行することから、９つの結果、０、１、２、５、６、７、−６、−５または−４が予想される。最初の２つのResult句はそれぞれ０および１を処理し、第３の句は結果値の残り全てを処理する。
４．結果「０」（合格）が生じる場合には、FlowTest1_MinはカウンタPassCounterをインクリメントするであろう。その後、それは新たなFlowItem FlowTest1_Typに遷移するであろう。
５．結果「１」または結果「２」が生じる場合には、FlowTest1_MinはカウンタFailCounterをインクリメントし、そのフローから戻るであろう。
６．FlowTest1_Typは同じようにして動作し、成功時にFlowTest1_Maxをコールするであろう。
７．FlowTest1_Maxは同じようにして動作し、成功時に、成功した結果（「０」）でFlowTest1から戻るであろう。

こうして、FlowTest1は、実行の成功時に、Test1の最小、典型および最大バージョンを通してデバイスを動かし、その後、戻るであろう。FlowTest2も同じようにして動作するであろう。

上記のようなFlowは基本的には、状態および遷移を有する有限状態機械を記述する。FlowItemは基本的には状態であり、それは以下のことを果たすであろう。
１．１つのIFlowableを実行する（それは、以前に定義されたFlow、またはTest、または上記の規則によってＣ＋＋においてインプリメントされることができるユーザ定義のFlowを用いることができる）。
２．IFlowableの実行は数値結果を返す。その結果に基づいて、ある特定の動作が行われ（いくつかのカウンタを更新する）、その後、２つの事柄のうちの１つが起こる。
ａ．Flowは数値結果にとともにコール元に戻る。
ｂ．Flowは、別の状態(FlowItem)に遷移することにより継続する。

こうして、１つのFlowItemは以下のコンポーネントを有する。
・１つのFlowItemは１つの名前を有する。
・１つのFlowItemは実行されるべき１つのFlowableを有する。
・１つのFlowItemは数またはResult句を有する。
・１つのFlowItemの各Result句は動作を提供し、１つの遷移で終了し、１つまたは複数の結果値に関連付けられる。

これらの項目はFlowItem内で構文的に以下のようになる。

FlowItem <name> <IFlowable to be executed>
{
Result <one or more result values>
{
<actions for these result values>
<transition for these result values>
}
Result<one or more other result values>
{
...
}
...
}

実行されるべきIFlowableは、Test、またはユーザ定義IFlowable、またはＦｌｏｗのいずれかにすることができる。１つの結果のための動作は、以下に記載される動作のうちの任意のものにすることができる。
・ＧＵＩツールによって用いられるストリング値を有する実体を属性結果にセットするためのプロパティ動作。これは上記のFlowTest1の例において見ることができる。

Property PassFail = "Pass";

プロパティは基本的には、１つの結果句に関連付けられる名前付きストリングまたは整数値を有する実体である。任意の数のプロパティが存在することができ、プロパティは、この結果に関連する情報を表示するためにユーザが用いることになる、ＧＵＩのようなツールによって用いられることが好ましい。プロパティは、試験の実際の結果、すなわち試験のフローに影響を及ぼさない。

いくつかの数のカウンタをインクリメントするためのカウンタ動作。これは上記の例において見ることができる。

IncrementCounters PassCount;
・任意の、またはユーザルーチンをコールするためのルーチンコール動作。これは後に説明される。

最後に、FlowItemは、別のFlowItemに制御を渡すためのGoToステートメント、またはコール元（コール処理フロー、または試験計画を開始したシステムルーチンのいずれか）に制御を戻すためのReturnステートメントのいずれかにすることができる遷移を有する。

［予め定義されたFlow］
Ｆｌｏｗオブジェクトの典型的な使用法は、Testのシーケンスを定義することである。その後、このシーケンスは、試験計画サーバ（ＴＰＳ）において生じるイベント、すなわちExecute Test Planイベントの結果として実行される。各サイトコントローラ上にある試験計画サーバが、ユーザの試験計画を実行する。しかしながら、Ｆｌｏｗオブジェクトは、他のイベントに応答しても実行される。括弧内の名前は、Ｆｌｏｗをこれらのイベントに割り当てる際に用いられる名前である。
１．System Load Flow(SysLoadFlow)。このFlowは、１つの試験計画が１つまたは複数のサイトコントローラにロードされるときに、システムコントローラ上で実行される。それは、任意のサイトコントローラ上に試験計画を実際にロードする前に実行される。このフローによって、試験計画開発者は、システムコントローラを起源とすべきである動作を定義できるようになる。そのような動作は、パターンファイルのブロードキャストロード、較正動作などを含む。
２．Site Load Flow(SiteLoadFlow)。このFlowは、１つの試験計画がサイト上にロードされ、初期化された後に、サイトコントローラ上で実行される。これにより、任意のサイト特有の初期化を行うことができる。
３．Lot Start/End Flow(LotStartFlow/LotEndFlow)。これらのFlowは、試験計画サーバが新たなロットの開始を通知されるときに、サイトコントローラ上で実行される。これは典型的には、データログストリームにロット特有の情報で注釈を付すために製造環境において用いられる。
４．DUT Change Flow(DutChangeFlow)。このFlowは、そのＤＵＴ情報が変化するときに、サイトコントローラ上で実行される。再び、これは典型的には、アナログストリームを更新するために製造環境において用いられる。
５．TestPlan Start/End Flow(TestPlanStartFlow/TestPlanEndFlow)。これらのFlowは、試験計画サーバが、現在のTest Flowを実行し始めるように指示されるとき、およびそのフローがその実行を終了するときに、サイトコントローラ上で実行される。
６．Test Start/End Flow(TestStartFlow/TestEndFlow)。これらのFlowは、Test Flowが新たなTestを実行し始めているとき、およびそのTestがその実行を終了するときに、サイトコントローラ上で実行される。
７．Test Flow(TestFlow)。このFlowは、試験計画サーバが「Execute Test Plan」メッセージを受信するときに実行される主要Flowオブジェクトであることに留意されたい。

ユーザが、TestFlowでないか、または他の所定のフローのうちの１つでない、ユーザの試験計画内の１つのFlowを定義する場合には、それを実行させるための好ましい方法は、これらの所定のフローのうちの１つの遷移状態内にそれを含むことであることに留意されたい。

［試験計画例］
以下の例では、フローによってインプリメントされる有限状態機械を記述するコメントとともにFlowが与えられる。その有限状態機械は、遷移行列として与えられる。その行列の行はFlowItemに対応し、列は結果に対応する。その行列の１つの行のエントリは、返された結果が列において指定された値であるときに、その行のFlowItemから遷移されるFlowItemを指示する。

３つのフロー、FlowTest1、FlowTest2およびFlowMainを有する試験計画が以下に示される。FlowTest1は先に説明されたように動作するであろう。それは、「min」、「typ」および「max」の各構成において、MyFunctionalTest1と名前を付けられた試験を実行するであろう。同様に、FlowTest2は、これらの各構成において、MyFunctionalTest2を実行するであろう。最後に、FlowMainは、FlowTest1およびFlowTest2を実行するであろう。これらの各フローの開始時に、コメントにおいて、有限状態機械遷移行列が与えられる。

# -------------------------------------------------------------
# File mySimpleTestPlan.tpl
# -------------------------------------------------------------

Version 0.1;

Import xxx.pin; # Pins

# Constants and variables giving limiting values.
Import limits.usrv;

# Import test condition groups
Import myTestConditionGroups.tcg;

# Import some bin definitions.
Import bins.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;

上記の試験計画は、好ましい順序で以下のように構成される。
１．最初に、バージョン番号が与えられる。この番号を用いて、コンパイラバージョンの互換性が確保される。
２．その後、多数のインポートが宣言される。これらは、その試験計画において用いられる名前を分解するために必要とされる宣言を有する種々のファイルである。
３．次に、試験計画名が宣言され、その後、試験計画のインライン宣言を行う。
４．次に、１組のPListDefsが宣言される。これらは、名前付きファイルからGlobalPListsの名前を付ける、ファイル修飾付きの名前を含む。それらは、パターンリスト変数も含む。パターンリスト変数は、実行時にcustom flowableにおいて初期化されることができる変数である。それらは、ランタイムまで、試験と実際のパターンリストとの結合を遅らせる手段を提供する。
５．次に、１組のUserVarsが宣言される。これらはストリングを含む。
６．その後、合格した試験および不合格の試験の数を判定するために、いくつかのカウンタが宣言される。カウンタは変数に過ぎず、初期化されて０になり、IncrementCounterステートメントにおいてインクリメントされる。それらは、１つのＤＵＴの試験の終了時に現在セットされているビンだけがインクリメントされるという意味を有する、先に説明されたＢｉｎとは異なる。
７．次に、一連のTest Conditionが宣言される。これらはそれぞれ、Test Condition Groupおよびセレクタを指定する。この例では、Test Condition Groupは、mytestconditionsgroup.tcgからもたらされる。しかしながら、それらは試験計画においてインラインにすることができる。
８．次に、一連のFlowableまたはTestが宣言される。これは、パターンリストおよび試験条件を選択する既知のTest FunctionalTestである。こうして、たとえば、MyFunctionalTest1Maxは、試験条件TC1Maxおよびパターンリストを選択する。
９．この後に、３つのフロー、FlowTest1、FlowTest2およびFlowMainが宣言される。FlowはFlowableを実行する。Flowableは、Test（MyFunctionalTest1Maxなど）および他のフロー（FlowTest1およびFlowTest2など）を含む。FlowTest1およびFlowTest2はそれぞれ、Test1およびTest2の最小、典型および最大バージョンを通る。フローFlowMainは、先に宣言されているフロー、FlowTest1およびFlowTest2をコールする。
１０．最後に、TestFlowイベントがFlowMain Flowに割り当てられる。したがって、フローFlowMainは、ユーザがこの計画を実行しようするときに、この試験計画によって実行されることになるフローである。

［FlowのためのＣ＋＋］
上記の規則を用いて、Flowそのものを除いて、要素の大部分のためのC++インプリメンテーションを果たすことができる。

［FlowItemのためのＣ＋＋］
FlowItemを表すためのC++クラスは以下のインターフェースを有することができる。
・このFlowItemのために実行されることになるIFlowableをセットすることになる演算。

StatussetFlowable(IFlowable* pIFlowable);

一旦、このIFlowableを実行するための必要とされる１組のコールからFlowItemが戻ったなら、それは、Result値に応じて、カウンタのリストをインクリメントする必要がある。これを果たすために、FlowItemは、インクリメントされることになるカウンタのベクトルを有する必要がある。これは以下のコールによって初期化される。

Status setCounterRefs(unsigned int result,
CounterRefList counterRefs) ;

これをコールすることにより、カウンタへの参照のベクトルがFlowItem内に設定され、結果として、一旦、IFlowableが実行を完了したなら、それはそれらのカウンタをインクリメントできるようになる。たとえば、ステートメントIncrementCounters Ａ，Ｂ，Ｃは、以下のように上記のコールを用いることが好ましいであろう。

// Somewhere earlier
CounterRefList counters;
...
// Code for Result clause
// Result 2, 3 {...}
// of flowobject.
counters.reset();
counters.add(&A);
counters.add(&B);
counters.add(&C);
flowObject.setCounterRefs(2, counters) ;
flowObject.setCounterRefs(3, counters) ;

カウンタで名前を付けられた一時的なCounterRefListオブジェクトが用いられる。最初に、counters.reset()がコールされ、その後、多数のcounters.add()をコールして、カウンタリストが設定される。その後、これを用いて、結果値２および３のために更新されることになるカウンタアドレスのベクトルが設定される。

その後、FlowItemは、特定の結果において別のFlowItemに遷移する必要があり得る。

Status setTransition(unsigned int result, Flowltem*pFlowItem);

ある特定のResult句が多数の結果値を取り扱う場合には、必然的にいくつかのそのようなコールが行われる必要があり得る。

FlowItemは結果を返す必要があり得る。これは以下のコールによって果たされる。

Status setRetumResult(unsigned int result,
unsigned int returnResult);

たとえば、以前の例におけるFlowItem FirstFlowItemの場合、上記のコールは、「result」の場合には値「２」で、「returnResult」の場合には「１」でコールされるであろう。
・最後に、FlowItemは演算を実行する必要がある。

Status execute(unsigned int& result, FlowItem* pNextFlowItem);

この演算は、IFlowableを実行し、その後、指示されたカウンタを更新し、その後、Result、または次のFlowItemへのポインタを返すであろう。このポインタがヌルである場合には、その結果は返された値である。

FlowItem FlowMain_1のために生成されることになるコードは以下の通りである。

FlowItem FlowMain_l;
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) ;

上で生成されたコードはFlowMain_1を設定し、IFlowable「FlowTest1」を実行し、その後、それを設定して、結果毎にカウンタの適当なリストをインクリメントし、最後に、必要な動作を行う。結果「０」の場合の必要な動作は、FlowMain_1への遷移であり、結果「１」の場合には、リターンである。

［Ｃ２．TestPlanにおけるカウンタサポート］
カウンタは０に初期化される変数であり、試験実行中の種々の時点において、IncrementCounterステートメントによってインクリメントされることができる。これは、試験の終了時にのみインクリメントされるＢｉｎとは異なる。さらに、ビンは階層的であるのに対して、カウンタは変数に過ぎない。したがって、カウンタはビンよりもはるかに簡単であり、より制限されたファシリティである。

カウンタは、符号なし整数である１組の名前付きカウンタを保持するCounterクラスのメンバを介して、TestPlanにおいてサポートされることができる。Counter宣言を介して、このクラスにおいてオブジェクトが定義されるであろう。カウンタは試験開始時に自動的にリセットされないので、TestPlanが、数多くのＤＵＴを試験し終えるまでカウントを収集できるようになる。カウンタの値をリセット、インクリメントおよび問い合わせるためのメソッドが与えられるであろう。これにより、順番にビンに入れることに対する代替の手段が、試験を実行する結果としてのカウントを判定できるようになる。

TestPlanはメンバ変数、m_modifiedCountersを含むことが好ましく、そのメンバ変数は、１つのＤＵＴにおいて試験を実行することによって変更される１組のカウンタである。この１組のカウンタは試験の開始時に空集合に初期化される。各場所において、IncrementCountersコールが行われ、コードが生成されて、名前付きカウンタをm_modifiedCounterメンバに追加するであろう。こうして、このメンバは、１つのＤＵＴで試験を実行中に変更された全てのカウンタを集める。

［FlowオブジェクトのためのＣ＋＋］
一旦、全てのFlowItemが作成されたなら、Flowオブジェクトは、以下に示されるように、C++オブジェクトとして作成されることができる。
・FlowItemを追加するための演算。

Status addFlowItem(FlowItem* pFlowItem, bool isInitalFlowItem);

その演算は、指示されたFlowItemをそのFlowに追加するであろう。これがFlowの初期FlowItemである場合には、ブーリアンが真にセットされる。
・Ｆｌｏｗを実行するための演算。

Status executeFlow(unsigned int& result);

これは、そのフローを実行する結果として、Flowが戻るときに戻ることが好ましい。この動作は、初期FlowItemでそのフローを実行し始めることである。それは、現在のFlowItemが実行すべき次のFlowItemを返す限り、FlowItemを実行し続けるであろう。現在のFlowItemが結果を返すとき、この演算は、その結果で完了する。

それゆえ、１つのFlowのために生成されるC++コードは、そのFlowにFlowItemを追加するために、addFlowItem()へのコールを何度か繰り返す。executeFlow()演算は、TestPlan内のこのFlowが実行するために選択されるときに生じるであろう。

［Ｃ３．Ｔｅｓｔクラス］
一般に、プログラムコードの大部分はデバイス試験のためのデータであり、残りは、試験方法を実現する試験プログラムのコードである。このデータはＤＵＴに依存する（たとえば、電源条件、信号電圧条件、タイミング条件など）。試験コードは、ＡＴＥハードウエアに指定されたデバイス条件をロードするためのメソッドと、ユーザによって指定された目的（データロギングなど）を実現するために必要とされるメソッドから構成される。

先に説明されたように、試験コードの再利用性を高めるために、そのようなコードは任意のデバイス固有データ（たとえば、ピン名、刺激データなど）、またはデバイス試験固有のデータ（たとえば、ＤＣユニットのための条件、測定ピン、ターゲットピンの数、パターファイルの名前、パターンプログラムのアドレスなど）とは無関係であるべきである。１つの試験のためのコードがこれらのタイプのデータとコンパイルされる場合には、その試験コードの再利用性は低下するであろう。それゆえ、任意のデバイス固有のデータまたはデバイス試験固有のデータは、コード実行時の入力として、その試験コードが外部から入手できるようにすべきである。

オープンアーキテクチャ試験システムでは、ITestインターフェースの１つのインプリメンテーションであるTestクラスが、特定のタイプの試験のための試験データとコードとの分離を（それゆえ、コードの再利用性を）実現する。そのような試験クラスは、それの別個のインスタンスのための「テンプレート」と見なすことができ、デバイス固有のデータおよび／またはデバイス試験固有のデータに基づいてのみ互いとは異なる。試験クラスは、試験計画ファイルにおいて指定される。各試験クラスは典型的には、ある特定のタイプのデバイス試験またはデバイス試験のための設定をインプリメントする。たとえば、機能的なＡＣおよびＤＣパラメータ試験は、別個の試験クラスによってインプリメントされることが好ましい。しかしながら、カスタム試験クラスも試験計画において用いることができる。

試験クラスによって、ユーザは、その試験の特定のインスタンスのためのオプションを指定するために用いられるパラメータを与えることにより、クラス挙動を構成できるようになる。たとえば、１つの機能試験は、パラメータＰリストおよびTestConditionsを取り込み、実行すべきパターンリスト、ならびにその試験のためのレベルおよびタイミング条件をそれぞれ指定するであろう。これらのパラメータのために異なる値を指定することにより（試験計画記述ファイル内の異なる「Test」ブロックを用いることによる）、ユーザは、１つの機能試験の種々のインスタンスを作成できるようになる。図５は、ただ１つの試験クラス５０４から異なる試験インスタンス５０２が如何に導出されることになるかを示す。

これらの試験クラスは、コンパイラ４００が試験および試験のパラメータの記述を試験計画ファイルから取り込み、正確なC++コードを生成できるようになり、そのC++コードがコンパイルおよびリンクされて、試験プログラムを生成することができるように設計されるべきである。試験クラスインスタンスを、試験フローを記述するオブジェクトに追加して、デバイス試験の複雑な実行シーケンスを作成することができる。

［Ｃ４．ITestおよびIFlowableからの導出］
先に述べられたように、試験クラスはITestから派生する。上記の規則を用いて、これらは、ITestインターフェースをインプリメントするC++クラスにおいてインプリメントされることができる。ITestインターフェースのための指定されるメソッドに加えて、これらのクラスは、デバイス試験の特定のクラスを実行するために必要とされるTest固有のインテリジェンスおよびロジックを提供する。また試験クラスはIFlowableインターフェースもインプリメントする。この結果として、Testクラスのインスタンスは、試験を実行するためにFlowItemにおいて用いることができる。

［カスタマイゼーション］
ユーザがＣ関数をコールできるようにし、ITestおよびIFlowableインターフェースをインプリメントする自らのクラスを開発できるようにするために、カスタマイゼーションの仕組みが提供される。

［イントロスペクション能力］
１つの試験クラスのオブジェクトが、そのメソッドおよびシグネチャに関して問合せを受けることができる場合には、そのオブジェクトは、生成されるソースコード内に包含するのに適したパラメータが入手できることを検証されることができる。そのような特徴は、翻訳段階における誤り検査および妥当性検査のために極めて有用であろう。試験技師がパラメータの名前、またはこれらのパラメータへの引き数の数（またはおそらくタイプ）を間違った場合には、C++コンパイラからのコンパイル時エラーメッセージを待つ代わりに、翻訳段階において、それが見つけられて、翻訳時に意味のあるエラーメッセージを与えることができる。これは、試験技師にとってさらに有用であろう。

イントロスペクションは、オブジェクトに自らの内部を探索し、その属性およびメソッドに関する情報を返すように求める能力を指している。Ｊａｖａのようないくつかの言語は、その言語の一部としてこの能力を提供する。ビジュアルベーシックのような他の言語は、それとともに用いられることになるオブジェクトにそのような要件を課す。Ｃ＋＋は、この機能を提供しない。

この方法は、デフォルトパラメータ値、およびオプションのパラメータの指示を提供するのにも非常に役に立つ。さらに、この能力が全てのTestクラスのインプリメンテーションの一部として提供される場合には、ＧＵＩアプリケーションがこの情報を用いて、ダイアログおよび他のユーザインターフェース要素を動的に構築し、技師がこれらのクラスを効率的に使用するのを助けることもできる。

このように複雑であることは、十分なイントロスペクションの代わりに、Ｔｅｓｔクラス開発者がそのクラスをパラメータ化するために必要とされるものとして設計したＴｅｓｔクラスの公開メソッド／属性を、ただ１つ（Ｔｅｓｔクラス当たり）のテキスト系ソースファイルにおいて完全に指定できるようにする方法を提供する仕組みを用いる本発明の１つの実施形態では相殺される。

ただ１つのソースが好ましい。１つのファイル内に１つのＴｅｓｔクラスのパラメータ化インターフェースの記述と、別の個別の（ヘッダ）ファイル内にC++インターフェース記述とを有し、その後、両方のソースを同期させておくための要求を負担することは望ましくないであろう。このような目的で、その試験クラスのためのプリヘッダファイル内に「テキスト系」の記述が埋め込まれ、それがイントロスペクションを制限し、かつその試験クラスのためのC++ヘッダを生成するためにコンパイラによって用いられる。生成されたC++ヘッダファイルは、TestクラスC++コードを最終的にコンパイルするために用いられるファイルである。

［プリヘッダ］
Ｃ＋＋においてヘッダを用いることはよく知られている。しかしながら、Ｃ＋＋はパースし、読み出すのが難しいので、本発明の一実施形態は、コンパイラが、試験クラス開発者がヘッダとして用いることができるC++出力を作成できるようにする構文を定義する。この実施形態によれば、試験クラス開発者はプリヘッダファイルを書き、それがプリヘッダファイルとしてコンパイラ４００によって出力され、それにより、対応する試験クラスまたは他の試験実体において見ることができるようにする。

以下の例は、本発明の好ましい実施形態による、１つのTestクラスのためのプリヘッダファイルの概念を例示する。試験FuncTest1について、ソースファイルから抜粋された以下の部分を考える。

...
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;
}

上記のFuncTest1の宣言が正当であるか否かを判定するために、コンパイラは、FunctionalTestが何を引き起こすかを知る必要がある。FunctionalTestの知識をコンパイラに組み込むのではなく、FunctionalTestが何を引き起こすかの定義を、プリヘッダにおいて指定することができる。

FunctionalTestが、ベースクラスTest1およびTest2を有し、かつPListであるメンバおよびTestConditonのアレイを有するC++クラスであると仮定する。コンパイラは、FuncTest1の上記の宣言が正当であることを認識するために、FunctionalTestのメンバのタイプについて知る必要がある。

さらに、FuncTest1のためのC++オブジェクト宣言を生成するために、クラスFunctionalTestのためのC++ヘッダが構成される必要がある。これは、コンパイラに対して、FunctionalTestクラスのベースクラス、そのメンバの名前および他のそのような情報について知ることも要求する。

本発明の一実施形態のプリヘッダ部分言語は、コンパイラに、宣言の正当性を認識し、かつ宣言に対応するC++ヘッダおよびオブジェクト宣言を生成するために必要とされる情報を提供する。

FunctionalTestは１つの単純なタイプ（パラメータ化が関係している限り）であり、それゆえ、パラメータ化のためにかなり単純な記述を使用するであろうことに留意されたい。こうして、以下のように、上記のパラメータ化をサポートするプリヘッダ、FunctionalTest.phを書くことができる（プリヘッダはベース試験クラスTest１及びTest２について利用可能であると仮定する）。

Version 1.0;
#
# 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を作成する。

#line 7 "./FunctionalTest.ph"
#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

先に説明されたように、このプリヘッダによって、コンパイラはFunctionalTest宣言の妥当性を検査し、そのためのコードを生成し、それによって必要とされることになるC++ヘッダを生成できるようになる。

一例として、便宜上、以下に再現される、先に与えられたFunctionalTest宣言について考える。

Test FunctionalTestFuncTest1
{
PListParam = patList1; # Previously defined pattern list
TestConditionParam = TC1;
TestConditionParam = TC2;
}

このためにコンパイラによって生成されることになるC++ヘッダは先に与えられている。コンパイラは、上記のFunctionalTest構成体のための以下のコードを生成するであろう。

FunctionalTest FuncTest1;
FuncTest1.setName ("FuncTest1");
FuncTest1.setPatternTree(&patList1);
FuncTest1.addTestCondition(&TC1);
FuncTest1 .addTestCondition(&TC2);

Description関数のために生成される名前にも注目されたい。Xxxと名前を付けられる各パラメータは以下のメンバ関数に関連し、それは、ＧＵＩが用いることができるツールチップのための記述を有するストリングを返す。

Status getXxxDescription() const;

［他のプリヘッダの特徴］
プリヘッダは、付加的なタイプとして、いくつかの他のユーザ定義列挙法をサポートする。これにより、ＧＵＩは、ある特定のパラメータの値をセットするために用いることができる、取り得る選択肢のドロップダウンリストを提供できるようになる。さらに、プリヘッダは、テーブルと考えることができる多数のパラメータを関連付けるための機能を提供する。たとえば、プリヘッダは、「プロパティ」のアレイを、関連する１組の、名前のためのストリングのアレイ、および値のための整数のアレイとしてインプリメントするのに都合良く用いることができる。この機能をインプリメントする１つの簡単な方法は、カスタムタイプ（後に説明される）のアレイを用いることである。しかしながら、それは、ユーザに、使用すべきカスタムタイププリヘッダを書くことを要求する。これらの機能がいずれも、以下の例において示される。

# --------------------------------------------------------
# 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

カスタムタイプ名前‐数値対が宣言されることもでき、そのカスタムタイプのただ１つのアレイパラメータを用いて、パラメータの上記のParamGroupと同じ効果をもたらすこともできることに留意されたい。上に提示された技法は、カスタムタイプを宣言する必要性を避けるのに好都合である。

［Ｃ５．カスタム関数宣言］
これにより、フロー遷移が行われるときに、ユーザはカスタム関数をコールできるようになる。カスタム関数は、以下のように、プリヘッダを通して宣言される。

# --------------------------------------------------------
# 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);

典型的には、コンパイラが標準的な方法でこれらの宣言を拡張するとき、上記の宣言のためにC++セクションが与えられる必要がある。当然、ユーザはこれらの関数のC++インプリメンテーションに対して責任を持つ。上記の関数は全て、おそらく、暗示的な第１のパラメータとしてITestPlanポインタを取り込むことに留意されたい。このポインタは、関数ライタがTestPlan内の状態Ｓにアクセスできるようにする。たとえば、関数ライタは、現在のFlow、そのフロー内の現在のFlowItem、現在のResult句、UserVarsの値および他のそのような情報にアクセスするために、ITestPlanインターフェースを用いることができる。ファイルFunctions.phにおいて用いるために、ある特定のテスタによって定義される関数を利用することができる。

Version 1.2.3;

#
# File Functions.ph
#
Functions = Functions; # The name of this group of functions

# Declare the following C++ function in the
# Functions namespace

# Returns the ID of the current DUT being tested by the
# caller.
UnsignedlntegerGetDUTID();

［カスタム関数宣言のためのＣ＋＋］
上記のMyFunctionsのためにコンパイラによって生成されることになるC++コードは、MyFunctions名前空間において単純にいくつかの関数を宣言することである。

namespace MyFunctions
{
double Min(ITestPlan* pITestPlan, int& x, int& y);
double Avg(ITestPlan* pITestPlan, double* a, const int a_size);
void Print(ITestPlan* pITestPlan, char* Msg, unsigned int dutID);
}

これらの関数は１つのフローからコールすることができるであろう。

［Ｃ６．カスタムFlowables］
プリヘッダを用いて、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 namedm_intl Val
# - a function to set it named setIntlVal.
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_int2VaI;
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

IFlowableインターフェースをインプリメントするいくつかのクラスが存在する。これらは以下のものを含む。
１．現在のテスタ構成内で試験計画を実行することができるか否かを検査することになるプログラムローディングのためのFlow。
２．特定のパターンおよびパターンリストをロードすることになるパターンローディングのためのFlow。
３．ハードウエアおよびソフトウエアを既知の状態にし、グローバル変数をロードし、他の初期化および妥当性検査機能を実施することになる初期化のためのＦｌｏｗ。
４．他の一般的に有用な試験フロー。

［Ｃ７．カスタムタイプ］
先のＴｅｓｔクラスパラメータ化に関する説明は、既知のタイプ、すなわち基本タイプ並びにPListsおよびTestConditionsのようなテスタ定義のタイプを有するような試験クラスパラメータの場合のみ許される。ユーザの自由度を高めるために、タイプ拡張性を与え、それにより、複数のタイプ（コンパイラには事前にはわかっていない）を作成し、使用できるようにすることが重要である。カスタムタイプ（ＣＴ）はCustom Typeにおいて定義されるであろう。これらのカスタムタイプを用いて、Ｃ言語ストラクトに対応するタイプ（Plain Old Dataタイプ、すなわちＰＯＤとも呼ばれ、Ｃ＋＋の同じ名前のものとは大きく異なる）および関数シグネチャのためのＣ言語タイプ定義に対応するタイプを定義することができる。ユーザタイプを含む別個のファイルは拡張子.ctypを有するであろう。ここに示されるのは、本発明の好ましい実施形態によるユーザタイプ宣言の一例である。

# --------------------------------------------------------
# File MyCustomTypes.ctyp
# --------------------------------------------------------

Version 1.0.0;

CustomTypes
{
# A structured Plain-Old-Data type
Pod Foo
{
String S1; # String is a standard type
Integer I1; # ... and so is Integer
String S2;
}
# Another structured type using Foo
Pod Bar
{
Foo 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++コードに翻訳されるであろう。

namespace CustomTypes
{
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)();
}

これらのタイプのオブジェクトは、次に示されるように、パラメータとしてTestクラスに渡すことができる。

［試験クラスパラメータとしてのカスタムタイプの使用］
ユーザがある試験を拡張する場合について考えると、その試験は、パターンリストおよび試験条件に加えて、他のクラスオブジェクト、ならびにCustom Type（すなわち、.ctypファイル）を含むファイル内で定義される任意の（すなわち、ユーザ定義の）オブジェクトで初期化される必要がある。たとえば、ユーザがファイルMyTestCTs.ctypにおいて定義されるＣＴを用いることを望むものと仮定する。

# File MyTesetCTs.ctyp
Version 1.0;

CustomTypes
{
Pod Foo
{
String name;
PList patternList;
}

Pod Bar
{
Foo someFoo;
Double dVal;
}
RoutineBinaryOp(Integer, Integer) return Integer;
}

上記のタイプを用いるためにユーザがする必要がある全てのことが、ユーザの試験クラスプリヘッダにおいて上記のファイルをインポートされる。コンパイラが、そのように定義されたＣＴを解釈するので、コンパイラが試験クラスプリヘッダを処理しているときに、FooおよびBarのための定義を入手することができる。さらに、コンパイラは、上記のタイプFooおよびBarにそれぞれ対応する２つのＣ言語ストラクト、すなわちストラクトFooおよびストラクトBarを定義し、それらの定義がファイルmyTestCTs.h内に置かれる。myTestCTs.cttのためのImportステートメントによって、ファイルmyTestCTs.hは、生成された試験クラスC++ヘッダ内に含まれるようになる。以下の例はこのプロセスを例示する。最初に、試験計画内の試験のための宣言を考える（パターンリストおよび試験条件のための宣言は、明確にするために省略されている）。

...
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;
}
...

上記の例では、試験計画にCustomVarsブロックが含まれる。カスタム化変数を含む別個のファイルは拡張子.cvarを有するであろう。ユーザは、以下のようにして、上記のパラメータ化をサポートするMyFuncyTestのためのプリヘッダを書くであろう（パターンリストおよび試験条件のためのパラメータ化宣言は、明確にするために省略されている）。

# --------------------------------------------------------
# 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 <MyCustomTypes.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コード内のコールを後に生成し、そのクラスのインスタンスを初期化する。プリヘッダおよび対応する宣言に関する以下の点に留意されたい。
１．全てのTestまたはカスタムFlowableクラス定義は、プリヘッダ内で指定されることが好ましい。プリヘッダ内のParametersブロックは、そのようなクラスのためのパラメータリストを指定することができる唯一の場所であることが好ましい（したがって、結果として、パターンリストおよび試験条件仕様のようなTestのための「標準的な」パラメータも、プリヘッダのParametersブロックに含まれる必要がある；これにより、全てのパラメータ、標準およびＣＴが一様に処理されるようになる）。
２．TestまたはFlowableクラスのためのプリヘッダにおいて非オプションとして定義される（すなわち、０以外の基数を有する）全てのパラメータが、そのクラスのインスタンスのためのTestブロックまたはFlowableブロック宣言の中で初期化されるべきである。
３．Test/Flowableブロックにおいてパラメータの初期化のために用いられるオブジェクトは予め定義されているべきである。
４．置換指示子$Class、$Inc、$ParamAryTypes、$ParamFns、$ParamAttrsおよび$ParamImplsが、ユーザが対応する生成されたコードを生成されたクラスヘッダファイル内に挿入させるつもりである、プリヘッダのユーザコードセクション内の正確な場所に現われなければならない。置換指示子毎に特定のコードが生成されるので、これらの置換指示子は厳密に一度だけ現われるべきである。
５．プリヘッダのParametersブロック内のパラメータ仕様の名前（上記の例のPListParam、TestConditionParamまたはBarParamのような）は、そのクラスのインスタンスの宣言において用いられることになるパラメータの名前である。
６．以下はパラメータ仕様において用いられる記述子の意味である。
ａ．Cardinality：これはサポートされることになるこのタイプのパラメータの数を指示する。以下は一実施形態において取り得る値である。
ｉ．１：このパラメータは強制的であり、厳密に一度だけ指定されるべきである。このパラメータは、パラメータのタイプのオブジェクトへのポインタとして保持されるであろう。
ｉｉ．０−１：このパラメータはオプションである。指定される場合には、それは一度だけ指定されなければならない。このパラメータは、パラメータのタイプのオブジェクトへのポインタとして保持されるであろう。
ｉｉｉ．１−ｎ：このパラメータは強制的である。さらに、このパラメータのために多数の値を指定することができる。この値は指定された順序で記憶されるであろう。
ｉｖ．０−ｎ：このパラメータはオプションである。このパラメータのために多数の値を指定することができる。この値は指定された順序で記憶されるであろう。
上記の（）および（）の場合に、全ての指定された値が、パラメータのタイプへのポインタ上でテンプレート化される、ＳＴＬベクトル＜＞に記憶されることになることに留意されたい。このベクトルのタイプは定義され、＄ＰａｒａｍＡｒｙＴｙｐｅｓによって指示される場所に挿入されるであろう。これらのタイプ定義のためのアクセスレベルは常に公開である。
ｂ．Attribute：このタイプのパラメータ値（複数可）のための記憶として用いるためのC++変数の名前。その名前は、C++クラスの私用データメンバとして全く同じ語で再現されることになり、C++識別子のための要件に準拠しなければならない。この属性のタイプに関して、以下のことに留意されたい。
ｉ．ただ１つの値だけが許される場合には、そのパラメータのタイプへのポインタである。
ｉｉ．多数の値が許される場合には、そのパラメータのタイプへのポインタ上にテンプレート化されるＳＴＬベクトル＜＞である（上記の（）を参照）。
それらの属性はTest Planによって作成され、ポピュレートされるオブジェクトへの参照を保持し、これらのオブジェクトを所有しないことに留意されたい。オブジェクトの寿命は常に、Test Planそのものによって管理される。
ｃ．SetFunction：このパラメータのための値をセットするために用いるための関数の名前。以下の点に留意されたい。
ｉ．その名前は全く同じ語で再現されることになり、それゆえ、C++言語要件に準拠しなければならない。
ｉｉ．その関数のアクセスレベルは常に公開である。
ｉｉｉ．リターンタイプは常に空である。
ｉｖ．その関数は常に、タイプポインタ／パラメータタイプのただ１つの引き数をとる。

１つの値が常に１つずつセットされる；すなわち、多数の値を指定できるようにするパラメータの場合に、Test Plan内の生成されたコードが、指定された値毎に一度、この関数を繰返しコールし、各値がＳＴＬベクトル（先に説明されたような）に追加されることになることに留意されたい。

関数名に続くオプションのキーワード［インプリメント］は、この関数のための普通のインプリメンテーションが、クラスヘッダ（$ParamImplsによって指示される場所において挿入される）においてインラインメソッドとして利用できるようになることを指示する。そうでない場合には、ユーザがその関数のインプリメンテーションを提供する役割を担う。
ｄ．Description：このパラメータのランタイム変更中にヘルプを提供するために、ＧＵＩツールによって用いられることになるツールチップであるストリングリテラル。Xxxと名前を付けられたパラメータのためのカスタムクラスにおいて生成されるC++メンバ関数は以下の通りであり、その関数は指定されたストリングを返すであろう。

String getXxxDescription () const;

［カスタム化を用いる試験計画例］
以下に示されるのは、いくつかのカスタム化を用いて説明される試験計画例である。

# --------------------------------------------------------
# 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 Flowltem calls the previously defined FIowTest2
Flowltem 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;
}
}
}

上記のコードにおいて、以下の点について留意されたい。
１．ここでPListDefsセクションは、いくつかのPList名とともに、いくつかのPList変数も有する。PList名は、試験において直に用いることができる名前である。PList変数は試験において用いることができる変数であり、その値は、ランタイムにおいて、カスタム化されたFlowable内のコードによって実際のPListに結び付けられる。
２．PListDefsセクションはオプションである。存在しない場合には、その内容は種々のTest宣言からコンパイラによって推測されるであろう。存在する場合には、それは、用いられるTestのPListパラメータの全てを宣言しなければならないが、それはさらに多くのパラメータを宣言することもできる。
３．値をPList変数に割り当てるために、ランタイムＡＰＩを利用できるであろう。TestPlanクラスは以下の関数を有するであろう。そのFlowableはPListVariableを特定のPListに結び付けるためにその関数を用いることができるであろう。

Status SetPListVariable(const Tester::String& varName,
const Tester: :String& fileQualifiedPListName);

４．別のFlowableに制御を渡すことか、リターンかのいずれかである遷移の直前に、FlowItemにおいてユーザ関数および関数をコールすることができる。

［ユーザ関数コールのためのＣ＋＋］
複数のフローにおいてカスタム関数コールを呼び出すことを除いて、コンパイラによって生成されることになるC++コードが、先に提示された種々のカスタム化技法のために示されている。FlowItem内のユーザ関数コールは、各FlowのIUserCallsメンバによって取り扱われることが好ましい。各Flowは、以下に示されるように、単一の仮想メンバ関数をエクスポートするインターフェースIUserCallsのメンバを有することが好ましい。

class IUserCalls
{
public:
virtual void exec(const String& flowItemName,
unsigned int result) = 0;
} ;

ユーザ関数コールを有するFlowに直面するとき、そのFlowは、上記のインターフェースをインプリメントするクラスのインスタンスでポピュレートされるようになる。たとえば、その例内のFlowMainでは、フローは以下のクラスのインスタンスでポピュレートされるであろう。

class FlowMain_UserCalls : public IUserCalls
{
public:
virtual void exec(const String& flowItemName,
unsigned int result)
{
if (flowItemName == "FlowMain_1")
{
//...
} else if(flowItemName== "FlowMain_2")
{
//...
} else if (flowItemName == "FlowMain_3")
{
switch (result)
{
case 0:
MyFunctions::Print("Passed FlowTest1",
Functions: :GetDUTID());
return;
case 1:
MyFunctions::Print("Failed FlowTest1",
Functions: :GetDUTID());
return;
default:
return;
}
}
else if (flowItemName =="FlowMain_4")
{
// ...
}
else if (flowItemName =="FlowMain_5")
{
// ...
}
}
};

FlowItem::execute()演算はフロー項目の名前を知っている。それは次のフローへのポインタとともに戻る前に、それは取り囲んでいるフローのためのIUserCalls::exec()をコールし、その自らのフロー項目名、および現在の結果の値を渡すであろう。これにより、上記のコードが実行されることになり、必要とされるユーザ定義関数が呼び出される。

［Ｃ９．試験プログラムコンパイル］
先に説明されたように、Test Plan記述ファイルは、１つの試験計画において用いられる複数のオブジェクトと、それらの互いに対する関係とを指定する。一実施形態では、このファイルはC++コードに翻訳され、それは、標準インターフェースITestPlanのインプリメンテーションの形でサイトコントローラにおいて実行されることになる。このコードは、サイトコントローラ上にロードされることができるウインドウズ・ダイナミックリンクライブラリ（ＤＬＬ）にパッケージ化されることができる。Test Program DLLは、サイトコントローラソフトウエアが試験計画オブジェクトを生成し、それが含む試験計画オブジェクトを返すために用いることができる標準的な既知のエントリポイントを有するように生成される。

［試験計画記述からの構成］
１つの試験計画記述からITestPlanのインプリメンテーションへの変換のプロセスは、試験プログラムコンパイラ４００によって達成される。このプロセスは２段階、すなわち翻訳およびコンパイルにおいて行われる。

翻訳段階４０２では、コンパイラ４００は試験計画ファイル（およびそれがインポートする種々の他のファイル）と、試験計画において用いられる全ての試験タイプのためのプリヘッダとを処理する。この段階では、コンパイラ４００は、MSVC++（マイクロソフト・ビジュアルC++）ワークスペースおよびプロジェクトファイル、ＤＬＬ「ボイラープレート」コードなどの全ての他のサポート用ファイルとともに、Test PlanオブジェクトのためのC++コード、および出合った試験タイプのためのC++ヘッダを作成する。コンパイラ４００は、生成されたコードにファイルおよび行指示文を挿入し、コンパイル時エラーメッセージが、生成されたコードの中を指示する代わりに、記述ファイル内の適当な場所に戻って参照できるようにする。

コンパイラが必要なファイルを作成した後に行われるコンパイル段階では、MSVC++コンパイラのような標準的なコンパイラ４０４が呼び出され、ファイルをコンパイルし、それらのファイルをＤＬＬにリンクする。

コンパイラは、入力として、有効な試験計画ファイル（および全ての関連するファイル）を取り込み、必要に応じて、試験計画ファイル内の「インポート」指示文によって表されるTestPlanファイルおよび全ての他のファイルを生成する。さらに、コンパイラは、MSVC++「ソリューション」を生成し、Test Plan DLLを構築する。たとえば、メインファイル（MyTestPlan.tpl）が、タイミング情報を組み入れるためのTiming1.timを含んでいた場合には、コンパイラは、（中でも）以下のファイルを作成するであろう。

MyTestPlan.h
MyTestPlan.cpp
Timing1.cpp
MyTestPlan.sln (MSVC++ "Solution" file)
MyTestPlan.vcproj (MSVC++ "Project" file)

全てのファイルが作成（または更新）された後に、コンパイラはMSVC++アプリケーションを呼び出し、そのアプリケーションが作成する「Solution」を指定し、ＤＬＬを構築する。エラーおよび／または警告があれば、ユーザに対して示されるであろう。

Test Planを構築した後に、ユーザがTiming1.timに変更を加えた場合には、ユーザはコンパイラを呼び出し、コンパイラにMyTestPlan.tplを渡す。コンパイラは（タイムスタンプ情報によって）メイン試験計画ファイルが変更されていないことを認めるので、MyTestPlan.h/.cppは作成し直されないであろう。しかしながら、メイン試験計画ファイルを処理している間に、Timing.timファイルが変更されていることがわかるであろう。それゆえ、コンパイラはTiming1.cppファイルを作成し直し、MSVC++アプリケーションを呼び出し、ＤＬＬを構築し直すであろう。これにより、MyTestPlan.cppをコンパイルし直すのが避けられ、Timing1.cppのみがコンパイルされ、ＤＤＬがリンクし直される。この手法は、コンパイルするのにかなりの時間を要する大きな試験計画の場合に、コンパイルおよびリンクし直す時間を切り詰める際に特に有用であろう。

［Ｄ．試験プログラムの実行］
サイトコントローラソフトウエアは、その処理空間内にTest Program DLLをロードし、ＤＬＬ内の「ファクトリ」関数をコールして、Test Planオブジェクトのインスタンスを作成する。一旦Test Planオブジェクトが作成されたなら、サイトコントローラソフトウエアは、その試験計画を実行するか、または必要とされる任意の他の方法で試験計画とやりとりすることができる。

［非インタラクティブビルド］
ウインドウズ環境の大部分のC++ソフトウエア開発者にとってアプリケーション（またはＤＬＬ、ライブラリなど）を構築することは、開発環境（ＭＳビジュアルC++、ボーランドC++など）を構築し、コードを編集し、そして（多くの場合に）ボタンを押してプロダクトを構築することを意味する。

本発明の１つの実施形態の試験環境は、類似の１組の機能を有するであろう。Test Plan開発者は、コードを編集し、それらのTest Planを構築する必要があるであろう。しかしながら、テスタは、結果として生成されるTest Plan DLLを生成するために、Test Plan開発者がC++開発環境を構築することを要求しないであろう。

これを果たすために、本発明は非インタラクティブビルドの概念を利用する。非インタラクティブビルドは、非インタラクティブモードにおいてＭＳビジュアルC++を用いるビルドと定義される。この場合でも依然として、他のツールがインタラクティブに用いられ、そのようなビルドを管理できるようになることに留意されたい。唯一意味することは、ビジュアルC++が非インタラクティブに用いられることである。

［想定される環境］
ユーザの環境について、ある特定の想定がなされる。それらの想定は以下の通りである。
１．Test Plan開発者は、上記の方法および規則に従って、自らのTest Planを開発しているであろう。
２．Test Plan開発者はC++の熟練者レベルの知識を持たない場合もある。
３．Test Plan開発者は、ファイル（複数可）をTest Plan DLLに変換するために、コマンドラインツールまたはＧＵＩツールを利用できるであろう。

［ボタンを使用しないアプリケーションの構築］
ＭＳビジュアルスタジオで非インタラクティブに作業するには、２つの手法のうちの１つが必要になる。第１の（そして最も簡単な）手法はコマンドラインインターフェースを用いることである。第２の（そしてより自由度のある）手法は自動インターフェースを用いることである。このセクションは両方の手法を説明する。

［プロジェクトの作成］
ビジュアルスタジオを非インタラクティブに使用するために、１つまたは複数の有効なプロジェクトを含むワーキングソリューションで開始すべきである。残念なことに、これは、コマンドライン手法又は自動手法のいずれからも達成することができないタスクである。いずれの方法もプロジェクト作成のための仕組みを提供しない。しかしながら、ビジュアルスタジオのためのプロジェクトおよびソリューションはテンプレートから作成することができる。それゆえ、プロジェクト名およびテンプレートを与えて開始することにより、ビジュアルスタジオのためのソリューション／プロジェクトを作成することができる。

［プロジェクトのポピュレーション］
コマンドラインがサポートしないので、生成されたプロジェクトに新たなファイルを追加するために、ビジュアルスタジオ自動モデルが用いられる。プロジェクトに新たなファイルおよび既存のファイルを追加するために、２つのビジュアルスタジオマクロが提供される。ActiveScriptエンジン（VBScript、JScript、ActivePerl、ActivePythonなどのような）を用いて同じタスクを実行するために、外部スクリプトが類似のコードを用いることができる。それゆえ、本発明のコード生成ツールは新たなファイルを作成し、自動モデルを用いて、それらのファイルを既存のビジュアルスタジオプロジェクトに追加することができる。ファイルが作成された後に、それらのファイルは、必要に応じて、ツールによって更新することができる。

［プロジェクトの構築］
一旦、適当なソリューションおよびプロジェクトが得られたなら、ビジュアルスタジオを非インタラクティブに用いて、Test Planを構築することに対していくつかのオプションがある。最も単純なオプションは、コマンドラインからそれを呼び出すことである。そのようなコマンドラインは以下のようになるであろう。

devenv solutionFile /build solutionCfg

ただし、solutionFileはビジュアルスタジオソリューションファイルであり、solutionCfgは、そのソリューション内のプロジェクトに適用することができる特定の構成である。別のソリューションは、自動のためのビジュアルスタジオオブジェクトモデルを用いることである。これにより、そのビルドおよび構成プロセスを、さらに細かく制御できるようになる。上記のように、それは、コマンドラインからプロジェクトを構築するために、Perlスクリプトのリストを含む。このプログラムは、構築するためのプロジェクトおよび構成を指定する構成ファイル（およびそれらのプロジェクトについての他の情報）を読み出し、自動モデルを用いてそれらを全て構築する。１つのスクリプトにおいて自動オブジェクトを用いる方法を例示するために、このスクリプトにおける$msdevオブジェクトの使用を考える。

［デバッガサポート］
Ｔｅｓｔクラスの開発者がその作業を検査し、デバックするために、サイトコントローラ内でブレークし、そのコードの中を逐次的に進むことができるようにするデバッガを利用する必要がある。コンパイラによって生成されるコードはMSVC++によってコンパイルされるC++であるので、MSVC++デバッガを用いて、Testクラスインプリメンテーションがデバッグされる。この特徴は、Ｃ＋＋において直に作業するTestクラス開発者などだけを対象にしていることに留意されたい。生成されたC++コードを直に参照することなくTestプログラムの動作をデバッグするか、または逐次的に進めることを望む試験技師に対して他の仕組みが提供されるであろう。

［システムソフトウエア環境］
このセクションは、テスタのための一般的なソフトウエア環境、すなわちユーザ試験計画によって必要とされるファイルのための場所、そのようなファイルのための代替の場所を指定するための仕組み、ならびに試験計画およびモジュール制御ソフトウエアの場所を指定するための方法を説明する。

［試験計画によって必要とされる環境］
システムの標準的な場所、および１つの試験計画によって必要とされる
１．パターンリスト
２．パターン
３．タイミングデータ
４．試験クラスＤＬＬ、のための探索経路のランタイム構成を、環境構成ファイルによって指定されるような、「環境」変数によって構成することができる。これらはテキストファイルであり、以下のような単純な構文を用いる。

Tester_PATOBJ_PATH = "patterns\data;D:\projects\SC23\patterns\data"

ネイティブＯＳによってサポートされる環境変数を用いる代わりに、テキストファイルにおいて、そのような「環境」を定義する利点は、そのインプリメンテーションが後に、ＯＳによってサポートされる環境変数が最大ストリング長を有するなどの共通の制約によって制限されないことである。以下の「環境」（設定）変数は、先に記載されたエンティティのために用いられるであろう。
・パターンリスト：Tester_PATLIST_PATH
・パターンオブジェクトファイル：Tester_PATOBJ_PATH
・パターンソースファイル：Tester_PATSRC_PATH（これはオプションである；以下を参照）
・Timingデータファイル：Tester_TIMING_PATH
・TestクラスDLL：Tester_TEST_CLASS_LIBPATH

特殊な事例をサポートするために、有用なデフォルト挙動を保持しながら、３つの構成レベルが提供される。これは、優先順位が高くなる順に説明される。

第一に、システム環境設定ファイル、
$Tester_INSTALLATIONROOT\cfg\setups\Setup.envが、「環境」変数のデフォルト値を指定するであろう。他の構成の仕組みが利用できない場合には、このファイルが必要とされるであろう。一般的に、それは、システム上で実行される全ての試験計画の場合に利用可能であろう。このファイルはインストール中にインストールおよび構成管理（ＩＣＭ）システムによって作成され、インストーラからの入力が先に述べられた３つの変数のためのデフォルト値を割り当てる（上記の３つの変数のためのシステムデフォルトに加えて、このファイルは、以下のサブセクションにおいて説明されるような、ある特定の他のテスタ「環境」変数のためのシステムデフォルトも含むことに留意されたい）。

第二に、環境設定ファイルを、試験計画に対するランタイム引き数としてユーザが指定することができる。このランタイム構成の変数は、デフォルト定義よりも高い優先順位を取るであろう。

最後に、試験計画が特殊なブロックを用いて、その実行時に用いられることになる環境変数を指定することができる。試験計画において定義される変数は、デフォルトシステムファイルまたはユーザ定義ファイル内の変数よりも高い優先順位を取るであろう。

一般的に、全ての必要な変数は、上記の仕組みのうちの１つを通して定義されるべきである。変数が定義されない場合には、ランタイムエラーが生じることになる。

［他の環境設定］
ユーザ試験計画によって必要とされる「環境」変数に加えて、試験環境によって、以下の２つの「環境」変数が必要とされる。
１．Tester_TEST_PLAN_LIBPATH：これは、ロードされるべきであるユーザ試験計画ＤＬＬを見つけるためにシステムコントローラが用いることになる探索経路を指定する。ユーザピン記述およびソケットファイルを見つけるためにも同じ探索経路が用いられることに留意されたい。ＩＣＭへのインストール時間中に指定される、この変数のためのデフォルト値は、ＩＣＭによって、ファイル$Tester_INSTALLATION_ROOT\cfg\setups\Setup.envに格納される。
２．Tester_MODULE_LIBPATH：これは、ベンダ提供ハードウエアモジュール制御ソフトウエアＤＬＬをロードするためにシステムが用いることになる探索経路を指定する。構成管理データベース（ＣＭＤ）から引き出されるこの情報も、ＩＣＭによってファイル$Tester_INSTALLATION_ROOT\cfg\setups\Setup.envに格納される。

ユーザはTester_TEST_PLAN_LIBPATH変数のためのSetup.envファイル内に与えられる値を無効にすることができるが、ユーザがベンダ提供ハードウエアモジュール制御ソフトウエアＤＬＬのための探索経路を明示的に変更することを望まない限り、Tester_MODULE_LIBPATHのためのSetup.envファイル内に与えられる値は変更されるべきでないことに留意されたい。

［探索経路指定の意味］
探索経路を指定する「環境」変数について以下の点に留意されたい。
１．各変数は、ある特定のタイプの参照されるファイルを見つけるためにシステムが探索することになるディレクトリ名の、セミコロン（「；」）によって分離されたリストにすべきである。
２．システムがそのような「環境」変数の値を最初に調べた後に、その値に対してユーザによって行われた任意の変更（たとえば、環境構成ファイルを編集することによる）は、それを行うための必要性をユーザが明示的にシステムに「通知する」ときにのみ、システムによって登録されるであろう。
３．テスタが正常に動作する環境のような分散環境内の「カレントワーキングディレクトリ」（ＣＷＤ）の表記法は、ユーザが直観的に予想するものではないかもしれないので、ＣＷＤに対する経路が曖昧な結果に繋がる可能性があるとき、探索経路内の相対経路名は、関連する環境変数（ルートを定義する機能を提供する）の特定の設定に関連するように解釈されるであろう。探索経路内の全ての相対経路名が基づくことになると想定されるルートを指示する、この関連する環境変数は、「Tester_INSTALLATION_ROOT」変数であり、それはユーザのシステムへのテスタインストールのトップレベル（すなわち「ルート」）ディレクトリの場所を与える。
４．ディレクトリエントリは集合［Ｖ：^＊？＜＞｜；］内の文字を含むことができない。セミコロン（「；」）を除いて、この集合内の全ての他の文字はウインドウズファイル名において違法であることに留意されたい。セミコロン（「；」）は探索経路内のエントリを区切るために用いられるので、セミコロンは探索経路エントリにおいて用いられるべきでない。経路名には空白を埋め込むことができるが、経路名の直前および直後に生じる（すなわち、経路名内の空白でない最初の文字の前および最後の文字の後の）全ての空白は経路名の一部であるとは見なされず、全て無視されるであろうことに留意されたい。
５．探索経路ディレクトリは、定義の中に現われた順序に探索されるであろう。最初に現われたファイルが選択されるであろう。

［Ｅ．試験パターン］
非常に大きな１組の試験パターンファイルの効率的な管理、取り扱いおよびローディングは、本発明の１つの実施形態のフレームワークのアーキテクチャに関する重要な側面である。階層的なパターンリストの概念は、扱いやすい概念化を提供し、エンドユーザがシステムを使いやすくする際の効率的な手段であると見なされる。

ＤＵＴへの刺激は、試験ベクトルを通して試験システムが入手できるようになる。ベクトルは一般的に、シーケンシャル（または線形）、スキャンあるいはアルゴリズムパターン発生器（ＡＰＧ）導出として分類することができる。本発明の１つの実施形態のシステムでは、試験ベクトルは、試験時にＤＵＴに加えられるパターンの観点から編成される。パターンは、ユーザの試験プログラム内のパターンオブジェクトによって表される。そのシステムでは、パターンは、パターンリストオブジェクトによってプログラムに基づいて表されるパターンリストとして編成される。パターンリストオブジェクトは、パターンの順序付きリストまたは他のパターンリストを表す。その順序は、リストコンポーネントの宣言の順序で暗示される。ただ１つのパターンしか必要とされない場合には、そのパターンはそれだけでリスト内にカプセル化される必要があることに留意されたい。

ユーザの試験プログラム内のパターンリストオブジェクトは、ディスク上のパターンリストファイルに関連付けられ、そのファイルはパターンリストの実際の定義を含む。こうして、パターンリストの内容は、関連するディスクファイルの内容によって動的に判定される（これについては後にさらに説明されるであろう）。

パターンリストの定義は、そのパターンリストのための明示的な名前を与え、ファイル名の連想を通して、パターンの順序付きリストおよび／または他のパターンリストを特定する。それは、実行オプションの仕様も提供し、それらのオプションはパターンリストおよびパターンの両方に適用されることができるので、パターンオブジェクトが説明された後にさらに詳細に説明されるであろう。パターンリストは以下の規則に従うべきである。

file-contents :
version-info global-pattern-list-definitions
version-info :
Version version- identifier;
global-pattern-list-definitions :
global-pattern-list-definition
global-pattern-list-definitions global-pattern-list-definition
global-pattern-list-definition :
global-pattern-list-declaration {list-block}
global-pattern-list-declaration :
GlobalPList pattern-list-name options_opt
list-block :
list-entry
list-block list-entry
list-entry :
pattern-entry ;
pattern-list-entry ;
global-pattern-list-definition ;
local-pattern-list-definition
pattern-entry :
Pat pattern-name options_opt
pattern-list-entry :
PList pattern-list-reference options_opt
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 options_opt
options :
option
options option
option :
[option-definition]
option-definition :
option-name option-parameters_opt
option-parameters:
option-parameter
option-parameters ',' option-parameter

以下は、先に用いられた未定義の非終端記号の記述である。
１．version-identifier：集合［０−９］からの１つまたは複数の文字からなる文字列であり、最初の文字は数字でなければならない。
２．name：集合［ａ−ｚＡ−Ｚ＿０−９］からの１つまたは複数の文字からなる文字列であり、最初の文字は［ａ−ｚＡ−Ｚ＿］から選択されなければならない。
３．pattern-list-name：集合［ａ−ｚＡ−Ｚ＿０−９］からの１つまたは複数の文字からなる文字列であり、最初の文字は［ａ−ｚＡ−Ｚ＿］から選択されなければならない。
４．file-name：有効なウインドウズファイル名（ファイル名内に任意の空白が含まれる場合には、それは二重引用符で囲まれなければならない）。これは単純なファイル名でなければならない、すなわちディレクトリコンポーネントを持つべきでないことに留意されたい。pattern-list-referenceは、同じファイル内のパターンリストを内部参照することができるか、または別のファイル内のパターンリストを外部参照することができる。外部参照はファイル名によって修飾される必要がある。
５．oprion-name：集合［ａ−ｚＡ−Ｚ＿０−９］からの１つまたは複数の文字からなる文字列であり、最初の文字は［ａ−ｚＡ−Ｚ＿］から選択されなければならない。
６．option-parameter：集合［ａ−ｚＡ−Ｚ＿０−９］からの１つまたは複数の文字からなる文字列。

パターンリストファイルはコメントをサポートし、コメントはパターンリストファイルパーサによって無視されなければならない。コメントは「＃」文字で開始し、その行の終わりまで続く。

［Ｅ１．パターンリストのための規則］
パターンリストのための静的規則またはコンパイル時の規則は宣言および名前の分解を規定する。パターンリスト言語内の名前は、global-pattern-list-definitionおよびlocal-pattern-list-definitionによって宣言される。それらの名前は、pattern-list-referenceによって参照される。以下は、これらの宣言および参照を規定するいくつかの規則である。
１．global-pattern-list-definitionまたはlocal-pattern-list-definitionはパターンリストの名前を宣言する。pattern-list-referenceは、宣言されたパターンリストの名前を参照する。グローバルパターンリストの名前はグローバルに知られている。ローカルパターンリストの名前は、それらの宣言されたリストブロック内でのみ知られている。それらの名前は、修飾を用いることなく、そのリストブロック内で直に参照されることができる。さらに深くネストされた宣言では、ローカルパターンリストは、修飾された名前によって参照される必要があるであろう。
２．ローカルパターンリスト名は、包含パターンリストの範囲内で知られており、グローバルパターンリスト名はシステムの範囲内で知られている。たとえば、以下を参照されたい。

GlobalPList Gl
{
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
}
３．グローバルパターンリストはパターンリストファイルの最も外側のレベルにおいて定義されることができるか、または包含パターンリスト内でネストされるように定義されることができる。しかしながら、そのネスティングは単に便宜的なものである。それらは、ファイル内の最も外側のレベルにおいてグローバルパターンリストとして概念的に定義される。ネストされたグローバルパターンリストは、同じ名前の最も外側の（ネストされない）グローバルパターンリストと意味的に同等である。したがって、たとえば、以下を参照されたい。

GlobalPList Gl
{
GlobalPList G2
}
is semantically equivalent to:
GlobalPList G1
{
PList G2; # References G2
}
GlobalPList G2 ...
４．全てのグローバルパターンリストは固有に名前を付けられる。

GlobalPList G1
{
# Note that this is as if declared at the outermost level
# with a reference to it right here.
GlobalPList G2
{
...
}
}

# This declaration will be an error in this or any other file,
# as the name G2 is already taken.
GlobalPList G2 # Error. Global name G2 is taken.
{
...
}
５．ローカルパターンリストは常に、ローカルパターンリストの名前の範囲も決定する、包含パターンリスト内でネストされた定義を有する。ローカルパターンリストは、その包含パターンリスト内で固有に名前を付けられる。ローカルパターンリストは構文的に、パターンリストファイル内の最も外側のレベルにおいて生じることを許されない。

GlobalPList G1
{
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;
{
}
}
６．各パターンリストファイルは、１つまたは複数のグローバルパターンリストのための定義を含む。これは構文から直に生じる。最も外側のレベルはglobal-pattern-list-definitionであり、それらのうちの少なくとも１つが存在しなければならない。
７．Pattern-nameは、Ｐａｔキーワードに続く、１つのパターンへの参照である。それは、その名前が接尾語．ｐａｔをパターン名に連結することによって得られるパターンファイル内に存在するパターンを参照する。そのファイルは、パターンのために定義された１つの探索経路に沿って得られることになる１つのファイルを示す。
８．pattern-list-referenceは、PListキーワードに続くパターンリストへの参照である。その参照は、オプションのファイル名、およびそれに続く、修飾されたパターンリスト名からなり、そのパターンリスト名は単に、ドットによって分離される名前のリストである。したがって、たとえば、以下は、ファイルfoo.plist内にあるグローバルパターンリストＧ１内にネストされるＬ１内にネストされるＬ２内にネストされるローカルパターンリストＬ３を参照するpattern-list-referenceとして用いることができる。その名前の最も左側の名前部分はＧ１である。

PList foo.plist:G1.L1.L2.L3;

最も左側の名前部分は、グローバルパターンリストに分解しなければならないか、または参照点から見ることができるローカルパターンリストに分解しなければならない。

pattern-list-referenceの名前分解は以下のように進められる。
１．各名前部分は、その前にある接頭部に照らして宣言される名前に分解する。
２．ファイル修飾がある場合には、最も左側の名前部分は、名前を付けられたファイルにおいて宣言されるグローバルパターンリストに分解する。
３．ファイル修飾がない場合には、最も左側の名前は、包含範囲内のローカルパターンリストに分解することができ、それが失敗する場合には、次の包含範囲内のローカルパターンリストに分解することができ、それが包含グローバル範囲まで続けられる。
４．グローバル範囲がパターンリストファイル内の最も外側のレベルにおいて宣言されたかのように、グローバル範囲の意味を保持するために、最も近くにある包含グローバル範囲への範囲の探索を制限する必要がある。ネストされたグローバル範囲が最も外側のレベルにおいて（同等に）テキスト形式で宣言された場合には、名前分解探索は、その範囲を検査した後に終了するであろう。
５．その参照が以前のステップによって分解されていなかった場合には、最も左側の名前部分が、この同じファイル内のグローバルパターンリストに分解されることができる。
６．その参照が以前のステップによって分解されていなかった場合には、最も左側の名前部分が、.plist接尾部を最も左側の名前部分に追加することにより、そのファイル内で名前を付けられるグローバルパターンリストに分解されることができる。
７．その参照が以前のステップによって分解されていなかった場合には、その参照はエラー状態である。

先に述べられたように、上記の規則は、最も左側の名前部分が、参照点から見ることができるローカルパターンリスト、またはグローバルパターンリストのいずれかに分解することを指示する。

以下の例はこれらの概念のいくつかを例示する。

GlobalPlist G1
{
PList G3; # OK. Refers to a pattern list later in this file.

PList G4; # OK. Refers to a pattern list in file "G4.plist
# OK. Refers to 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;
}
}

全てのパターンリストファイル名およびパターンファイル名は、それらを用いる試験計画の中で固有であることが要求される。

パターンリスト参照は、同じファイル内の参照の前後いずれかにおいて定義されるパターンリストを参照することができる。

再帰的および相互に再帰的なパターンリスト定義は許されない。ユーザがそのような定義を作成するのを防ぐために、パターンリストファイル構文内には何も存在しないが、パーサがそのような条件を検出するとき、パーサはエラーフラグを立てるであろう。そのような条件を検出することに関連して或るコストがかかることに留意されたい。ユーザは、入力空間が相互に再帰的な定義を免れることを保証する責任を負うことができるか否かの検査のスイッチを切ることができるであろう。

GlobalPList G1
{
LocalPList L2
{
LocalPList L3
{
# Error. L2 runs L3 which runs L2.
# This is a recursive reference to L2
PList L2;
PList G2;
}
}
}

GlobalPList G2
{
# Error. G1.L2 runs L3 which runs G2 which runs GI.L2.
# This is a mutually recursive reference to G1.L2.
PList G1.L2;
}

パターンおよびパターンリストの構文的な記述は、それらの記述においてオプションを指定できるようにする。一般的に、オプションはベンダ特有である。構文は、任意のパターンまたはパターンリストが、それぞれ複数のパラメータで指定される複数のオプションを有することができるようにする。大部分のベンダによって認識されることになるいくつかのサポートされるオプションが記述される。

パターン実行シーケンスを定義した後に、パターン木の動的な（すなわち実行時の）意味が記述される。

［Ｅ２．パターン］
図６は、本発明の一実施形態によるパターンコンパイラ６０２およびパターンローダ６０４を示す。パターンのユーザ定義の内容は、プレーンテキストファイルであるパターンソースファイル６０６において入手することができる。パターンコンパイラは、ソースファイルを、テスタハードウエア上にロードするのに適したモジュール特有のフォーマットにコンパイルする責任を担うであろう。この後者のファイルはパターンオブジェクトファイルと呼ばれるであろう。以下はその一般的な属性である。
１．パターンオブジェクトは、ユーザが作成することはできない。むしろ、ユーザは、他のパターンリストおよび／またはパターンのコレクションであるパターンリストを常に取り扱う。パターンリストオブジェクトは、必要に応じてユーザがアクセスできるようにしながら、その中に含まれるパターンオブジェクトを作成し、所有し、保持する。
２．パターンは１つの試験計画内で固有に名前を付けられる。すなわち、その試験計画内では、同じ名前を有する２つのパターンは存在することはできない。パターンの名前は、それを含むファイルの名前とは異なる。パターンファイル名は、１つのパターンを参照するためにパターンリストファイルにおいて用いられる名前であり、一方、そのパターンの実際の名前はパターンファイルにおいて定義される。

本発明の一実施形態では、一般的に、ただ１つのＤＵＴ（被試験デバイス）が、種々のベンダからのテスタモジュールに接続されることもある。これは、全パターンのコンパイル‐ロード‐実行連鎖にとって複数の意味を有する。主なものがこのセクションにおいて説明される。

［Ｅ３．パターンコンパイル］
こうして、パターンコンパイラ６０２は、（用いられるベンダ特有のデジタルモジュールに照らして）特定のサイト構成をターゲットにする必要がある。この説明の残りの部分において、用語「モジュール」は、一例として、デジタルモジュールを指すために用いられるであろう。種々のベンダからのモジュール６０８をシステムに組み込むことができるようにするために、以下の手順が好ましい。
１．各モジュールベンダは、動的にロード可能なライブラリまたは個別の実行可能プログラムの形で、自ら所有するモジュール特有のパターンコンパイラ６１０を提供する責任を担うであろう。このコンパイラライブラリ／実行可能プログラムは、最低でも、compile()メソッドを提供するであろう。
２．パターンソースファイルは、それが含むパターンブロックのタイプ毎に２つの異なるタイプのセクションを収容するであろう。
ａ．全てのコンパイラがアクセス可能である情報を含む「共通」セクション（ただし、必ずしも用いられる必要はない）。
ｂ．固有ベンダコードによってそれぞれ特定され、特定のベンダコンパイラによって使用可能な情報のための１つまたは複数のオプションのベンダ特有セクション。
３．ベンダのコンパイラは、パターンオブジェクトファイルを直に作成しないであろう。代わりに、テスタは、パターンコンパイラの一部であるオブジェクトファイルマネージャ（ＯＦＭ）６１４によって管理されるパターンオブジェクト「metafile」６１２を提供するであろう。パターンコンパイラは、システムコントローラとして動作するコンピュータ上に、またはオフラインで、たとえばシステムコントローラが接続されるネットワーク上に配置することができる。これまで抽象語において参照された「パターンオブジェクトファイル」は、実際にはこのオブジェクトメタファイルである。オブジェクトメタファイルは、パターンソースファイルと同じ名前を付けられることになり、ソースファイル拡張子がオブジェクトファイル拡張子によって置き換えられる。ＯＦＭは、このファイルの読出しおよび書込みを行うためのアプリケーションプログラミングインターフェース（ＡＰＩ）を提供するであろう。オブジェクトメタファイルは、以下のものを格納するための手段を有するであろう。
ａ．共通ヘッダ情報
ｂ．対応するモジュール、およびそのモジュールためのパターンデータの場所を特定する情報を含む、モジュール特有のヘッダ情報
ｃ．モジュールベンダの要求に応じて編成され、モジュールベンダによって解釈されることができる、モジュール特有のパターンデータ

ＯＦＭ ＡＰＩによって、モジュールベンダのコンパイラは、モジュール特有のヘッダ情報およびデータをオブジェクトメタファイルに書き込むことができるようになるであろう。オブジェクトメタファイルのこのレイアウトによって、ターゲットにされたサイトにおいて２つ以上のモジュールが同じ場合であっても、パターンデータがモジュール毎に編成されるようになることに留意されたい。

直接メモリアクセス（ＤＭＡ）のような効率的なデータ通信を利用することができる、モジュール特有のハードウエアローディング情報の生成を容易にするために、パターンコンパイラによって、さらに多くのベンダ供給構成情報が必要とされる場合もあることに留意されたい。

［Ｅ４．オブジェクトファイルマネージャ（ＯＦＭ）フレームワーク］
オープンアーキテクチャ試験システムは、拡張性があり、かつ自由度の高いソリューションを提供する。本発明の一実施形態のオープンアーキテクチャ試験システムでは、単一の被試験デバイス（ＤＵＴ）を種々のベンダからのテスタモジュールに接続することができる。この文脈における試験モジュールは、オープンアーキテクチャ試験システム内の１つの機能ユニットを指しており、ハードウエアおよびソフトウエア両方のコンポーネントを含むことができる。この実施形態の分散形で、構成変更可能なモジュール式オープンアーキテクチャ試験システムは、本明細書では、試験システムまたはシステムとも呼ばれる。

このパターンを種々のハードウエアベンダによって開発された多数のテスタモジュールとコンパイルできるようにするための知識をできる限り用いることなく、試験システムのユーザは、ＤＵＴを試験するためのパターンを書く。これは、これらの各モジュールがそのパターンにおいて指定される機能を提供することができること、およびベンダに特有のパターンフォーマットがそのパターンファイル内に含まれることができることを前提とする。

ＤＵＴへの刺激は、試験ベクトルを通して試験システムが入手できるようになる。試験システムフレームワーク内の試験ベクトルは、試験中のＤＵＴに加えられるパターンに照らして編成される。パターンはユーザの試験プログラム内のパターンオブジェクトによって表される。以下の段落は、試験システムのＯＦＭフレームワークの重要な用語のうちのいくつかを導入する。

パターンブロックオブジェクトは、所与のタイプのパターンデータ（サイクライズまたは非サイクライズ）のコレクションを表しており、パターンブロック内のパターンデータを記述するための共通の構文を共有する。一実施形態では、サポートされるパターンブロックのタイプは、パターンソース内のタイプ（たとえば、pattern[type]）によって特定される、サイクライズパターンブロック（たとえば、MainPattern、SubrPattern、algorithmic pattern generator pattern(ALPG Pattern)、および非サイクライズパターンタイプである。ＳｕｂｒパターンブロックおよびALPG Patternブロックは、補助パターンオブジェクトメタファイルの例示的なブロックである。パターンブロックは以下の２つの異なるタイプのセクションを収容することができる：１）全てのコンパイラがアクセス可能な（ただし、必ずしも用いられない）情報を含む共通セクション、および２）ベンダコンパイラが用いることができる情報を格納するための、それぞれが固有のベンダコードによって特定される１つまたは複数のオプションのベンダ特有のセクション。パターンオブジェクトは、パターンオブジェクト内の２つのブロックが同じタイプから成らないという制約を有する、パターンブロックのコレクションを表す。サイクライズパターンブロックは、シーケンシャルに繰り返されるデジタルテスタにおいて用いられる試験ベクトルのコレクションを表しており、それは、ベンダが従うべき標準的な構文を提供する。パターンソースファイルは、１つまたは複数のパターンブロックを収容することができる。

図１３は、本発明の一実施形態によるモジュール式試験システムにおいてパターンオブジェクトファイルを管理するためのＯＦＭフレームワークを示す。ＯＦＭフレームワークは、ベンダコンパイラインターフェース（IVendorCompiler）１３０２と、ベンダパターンコンパイラインターフェース（IVendorPatCompiler）１３０３と、ベンダサイクライズパターンコンパイラインターフェース（IVendorCyclizedPatCompiler）１３０４とを備える。モジュールベンダは、自ら所有するパターンコンパイラを提供する責任があり、そのパターンコンパイラは、IVendorPatCompilerインターフェース１３０３またはIVendorCyclizedPatCompilerインターフェース１３０４、あるいはその両方をインプリメントする。ＯＦＭフレームワークはさらに、ＯＦＭモジュールエージェント(OFMModuleAgent)クラス１３０６と、ＯＦＭサイクライズパターンモジュールエージェント(POFCyclizedModuleAgent)クラス１３０８と、ＯＦＭラベルリーダ(OFMLabelReader)クラス１３１０と、オブジェクトファイルマネージャ(OFMManager)クラス１３１２と、パターンオブジェクトメタファイル(PatternObjMetaFile)クラス１３１４とを備える。非サイクライズパターンブロックを取り扱うための第１のベンダパターンコンパイラ（ATRFPatCom)クラス１３１６、およびサイクライズパターンブロックを取り扱うための第２のベンダパターンコンパイラ（ATDM250PatCom）クラス１３１８はそれぞれ、IVendorPatCompilerインターフェース１３０３およびIVendorCyclizedPatCompilerインターフェース１３０４をインプリメントするベンダ提供のクラスの例である。それらのインターフェースおよびクラスの記述が以下に提供される。

［IVendorPatCompilerインターフェース］
IVendorPatCompilerインターフェース１３０３は、２つの関数グループをサポートする。第１の関数グループは、パターンソースファイル内の非サイクライズパターンブロックのコンパイルと、モジュールデータによるパターンオブジェクトメタファイルの更新とをサポートする。第２の関数グループは、パターンオブジェクトメタファイルの共通ブロックセクションの更新をサポートする。

ベンダコンパイラがモジュール構成ファイルにおいてセットされるモジュールタイプＩＤと一致し、そのブロックタイプをサポートする場合には、ＯＦＭはパターンコンパイルメソッドのグループを呼び出す。パターンコンパイルメソッドが呼び出され、ベンダコンパイラが、コンパイルされたパターンオブジェクトデータを、対応するモジュールパターンローダのためのメタファイルに格納する。パターンコンパイルメソッドの第１のグループが以下に説明される。
・compile()：compile()メソッドは、パターンソースファイルをコンパイルするためにＯＦＭによって呼び出される。ＯＦＭはPOFCyclizedModuleAgentオブジェクトをベンダコンパイラに渡す。このオブジェクトは、保護／アクセス制御を提供し、ベンダコンパイラがパターンソースファイルの共通セクションおよびモジュール特有セクションへの読出しアクセス、並びにベンダモジュール特有セクションへの書込みアクセスを共に許可されるようにする。ピンと資源との間のマッピングについての情報を提供するために、OFMResourcePinMapperインスタンスも引き数としてベンダコンパイラに渡される。
・needsPinNames()：needsPinNames()メソッドは、compile()メソッドが呼び出されるときに、モジュールコンパイラが提供されることになるピン名のリストを必要とするか否かを問い合わせるために、ＯＦＭによって呼び出される。
・getSupportedResources():getSupportedResources()メソッドは、それがサポートする資源の名前についてモジュールコンパイラに問い合わせるために、ＯＦＭによって呼び出される。これは、ベンダコンパイラが資源レベル毎にパターンコンパイルプロセスのためのピンリストを必要とするときに、ピンのリストを作成するために用いられる。
・release():release()メソッドは、所望のIVendorPatCompilerオブジェクトが削除される前に、ベンダパターンコンパイラがクリーンアップ動作を実行できるようにするために、ＯＦＭによって呼び出される。
・getErrorList():getErrorList()メソッドは、OFCStatusオブジェクトのアレイを検索するために、ＯＦＭによって呼び出される。このアレイは、パターンコンパイラがパターンソースのコンパイル中に出合う場合があるエラーおよび警告の両方を含む。OFCStatusは、エラーについての情報を含むエンティティである。それには、特定のエラーコードを表す簡単な形の整数値を用いることができる。OFCStatusを、エラーが生じた場合のエラーコード、およびエラーの特定のインスタンスに関連するいくつかの特有のデータを含む情報を有するオブジェクトとすることが有用である。

ＯＦＭは、IVendorPatCompilerインターフェース１３０３の「getter」メソッドを用いて、ベンダコンパイラに共通セクションの種々の設定を問い合わせる。コンパイルされるパターンソースファイルからの共通セクションの設定に関する詳細を提供することは、ベンダコンパイラの責任である。パターンソースファイルをコンパイルするために用いられる共通セクションメソッドが以下に説明される。
・getPinRef()：オブジェクトファイルマネージャがベンダパターンコンパイラにパターンソースファイルをパースし、ＯＦＭにピン参照設定ファイルの名前を提供することを要求する場合には、オブジェクトファイルマネージャはgetPinRef()メソッドを呼び出す。
・getSubReferences()：オブジェクトファイルマネージャがベンダパターンコンパイラにパターンソースファイルをパースし、ＯＦＭにこのパターンソースファイルによって参照されるSubroutineのアレイを提供することを要求する場合には、オブジェクトファイルマネージャはgetSubReferences()メソッドを呼び出す。
・getSynchronizedNameArray()：ＯＦＭがベンダパターンコンパイラにパターンソースファイルをパースし、ＯＦＭにこのパターンソースファイル内に存在する同期したブロックのアレイを提供することを要求する場合には、ＯＦＭはgetSynchronizedNameArray()メソッドを呼び出す。ＯＦＭフレームワークはこれらの名前（ピン記述ファイルにおいて宣言される）を用いて、これらのブロックの実行を調整する。

［IVendorCyclizedPatCompilerインターフェース］
IVendorCyclizedPatCompilerインターフェース１３０４は、IVendorCompilerインターフェース１３０２から継承する。またそれは、モジュールベンダに２つの関数グループをサポートすることを要求する。第１の関数グループは、パターンソースファイル内のサイクライズパターンブロックのコンパイルをサポートし、パターンオブジェクトメタファイルを更新する。第２の関数グループは、パターンオブジェクトメタファイルの共通ブロックセクションの更新をサポートする。

ベンダコンパイラがモジュール構成ファイルにおいてセットされるモジュールタイプＩＤと一致し、そのブロックタイプをサポートする場合には、ＯＦＭはパターンコンパイルメソッドを呼び出す。パターンコンパイルメソッドが呼び出され、ベンダコンパイラが、コンパイルされたパターンオブジェクトデータを、対応するモジュールパターンローダのためのメタファイルに格納する。パターンコンパイルメソッドの第１のグループが以下に説明される。

compile()メソッドは、パターンソースブロックをコンパイルするためにＯＦＭによって呼び出される。ＯＦＭはPOFCyclizedModuleAgentオブジェクトをベンダコンパイラに渡す。このオブジェクトは、保護／アクセス制御を提供し、ベンダコンパイラが共通セクションおよびモジュールセクションへの読出しアクセス、並びにモジュールセクションへの書込みアクセスを許可されるようにする。ピンと資源との間のマッピングについての情報を提供するために、OFMResourcePinMapperインスタンスも引き数としてベンダコンパイラに渡される。

ＯＦＭは、IVendorCyclizedPatCompilerインターフェース１３０４の「getter」メソッドを用いて、ベンダコンパイラに共通セクションの種々の（サイクライズテスタ特有の）設定を問い合わせる。コンパイルされるパターンソースファイルからの詳細を提供することは、ベンダコンパイラの責任である。パターンソースファイルをコンパイルするために用いられる共通セクションメソッドが以下に説明される。
・getALPGReferences()：ＯＦＭがベンダパターンコンパイラにパターンソースファイルをパースし、ＯＦＭにパターンソースファイル内で参照されるＡＬＰＧパターンのリストを提供することを要求する場合には、ＯＦＭはgetALPGReferences()メソッドを呼び出す。
・getDomainList()：ＯＦＭがベンダパターンコンパイラにパターンソースファイルをパースし、ＯＦＭにパターンによって用いられるDomainのリストを提供することを要求する場合には、ＯＦＭはgetDomainList()メソッドを呼び出す。１つのパターンがデバイスの全てのドメインのために用いられない場合もあるので、このドメインのリストには、ピン記述ファイルにおいて指定されるドメインのリストのサブセットを用いることができることに留意されたい。
・getLabelList()：ＯＦＭがベンダパターンコンパイラにパターンソースファイルをパースし、ＯＦＭに所与のドメインのためのパターンソースにおいて用いられるLabelのリストを提供することを要求する場合には、ＯＦＭはgetLabelList()メソッドを呼び出す。ラベルは１つのドメインにおいて或る範囲を有し、同じラベルを多数のドメインにおいて用いることができることに留意されたい。
・getLabelOpcodeOffset()：ＯＦＭがベンダパターンコンパイラにパターンソースファイルをパースし、ＯＦＭに所与のドメインのラベルのためのOpcodeオフセットを提供することを要求する場合には、ＯＦＭはgetLabelOpcodeOffset()メソッドを呼び出す。
・getLabelOperandOffset()：ＯＦＭがベンダパターンコンパイラにパターンソースファイルをパースし、ＯＦＭに所与のドメインのラベルのためのOperandオフセットを提供することを要求する場合には、ＯＦＭはgetLabelOperandOffset()メソッドを呼び出す。
・getPXRSetupFileRef()：ＯＦＭがベンダパターンコンパイラにパターンソースファイルをパースし、ＯＦＭに、インポートされるPattern Cross Reference Setupファイルの名前を提供することを要求する場合には、ＯＦＭはgetPXRSetupFileRef()メソッドを呼び出す。
・getCyclizedPatternType()：ＯＦＭがベンダパターンコンパイラにパターンソースファイルをパースし、ＯＦＭに指定されるサイクライズパターンブロックのタイプ（SQPG、ALPG、SUBR、SCAN、ESCAN）を提供することを要求する場合には、ＯＦＭはgetCyclizedPatternType()メソッドを呼び出す。
・getAMAX()：ＯＦＭがベンダパターンコンパイラにソースファイルをパースし、ＯＦＭに、共通セクションに属する最大アドレスサイズデータを提供することを要求する場合には、ＯＦＭはgetAMAX()メソッドを呼び出す。

［OFMModuleAgent］
OFMModuleAgent１３０６は、POFCyclizedModuleAgentクラスによって拡張することができるベースクラスである。このクラスは、各モジュールのバイナリオペークデータにアクセスするために必要とされるメソッドグループのインプリメンテーションを提供する。OFMModuleAgentクラス１３０６は以下のメソッドを含む。
・flush()：バッファされたバイナリデータがフラッシュされる必要がある場合には、ベンダコンパイラはflush()メソッドを呼び出す。
・position()：１つのパターンブロック内のバイナリデータの現在位置を判定するために、ベンダコンパイラはposition()メソッドを呼び出す。
・preAllocate()：ベンダコンパイラがＯＦＭに、効率を改善するために所与のサイズのpattern‐object‐metafile内の１つのブロックを予め割り当てることを要求する場合には、ベンダコンパイラはpreAllocate()メソッドを呼び出す。バイナリブロックのために割り当てられるデフォルトサイズは０ｘ４０００である。
・getSize()：ベンダコンパイラがＯＦＭに、モジュールのためのバイナリデータのサイズを判定するためにメタファイルに問い合わせることを要求する場合には、ベンダコンパイラはgetSize()メソッドを呼び出す。
・read()：ベンダコンパイラがＯＦＭに、所与のサイズのデータを、そのモジュールのためのメタファイルからの所与のオフセットにおいて読み出すことを要求する場合には、ベンダコンパイラはread()メソッドを呼び出す。オフセットおよびサイズはそのモジュールのためのブロックに対するものであり、全メタファイルに対するものではない。
・verify()：ベンダコンパイラがＯＦＭに、所与のサイズの有効データが、そのモジュールのためのこのメタファイルの所与のオフセットにおいて存在することを検査することを要求する場合には、ベンダコンパイラはverify()メソッドを呼び出す。オフセットおよびサイズはそのモジュールのためのブロックに対するものであり、全メタファイルに対するものではない。
・write()：ベンダコンパイラがＯＦＭに、所与のサイズのデータを、所与のオフセットにおいてそのモジュールのためのメタファイルに書き込むことを要求する場合には、ベンダコンパイラはwrite()メソッドを呼び出す。オフセットおよびサイズはそのモジュールのためのブロックに対するものであり、全メタファイルに対するものではない。
・getSocketRef()：ベンダコンパイラがＯＦＭに、タイプSocketInfoのオブジェクトを作成することを要求する場合には、ベンダコンパイラはgetSocketRef()メソッドを呼び出す。このクラスは、ファイルをパースすることを必要とすることなく、コンパイラがシステムソケットファイルの設定にアクセスできるようにする。
・getSourceRef()：ベンダコンパイラがＯＦＭに、パターンソースファイルの名前を提供することを要求する場合には、ベンダコンパイラはgetSourceRef()メソッドを呼び出す。
・getSourceVersion()：ベンダコンパイラがＯＦＭに、パターンソースファイル言語バージョンを表すバージョンストリングを供給することを要求する場合には、ベンダコンパイラはgetSourceVersion()メソッドを呼び出す。

［POFCyclizedModuleAgent］
POFCyclizedModuleAgentクラス１３０８は、ＯＦＭが或るパターンをコンパイルし始めるときに、ＯＦＭによって開かれるPatternObjMetaFileクラス１３１４へのシャローハンドルである。それは、サイクライズテスタモジュールに特有の付加的な方法でOFMModuleAgentを拡張する。それは、ベンダパターンコンパイラが共通セクションおよびモジュールセクションの両方から読出しを行うことができるようにすることにより、ベンダパターンコンパイラがパターンオブジェクトメタファイルにアクセスするのを制限する。また、それはベンダコンパイラのモジュールセクションへの書込みアクセスも提供する。このインターフェースは、ＯＦＭがcompile()メソッドを呼び出すときに、パターンのコンパイル中にベンダパターンコンパイラによって用いられる。POFCyclizedModuleAgentクラス１３０８は以下のメソッドを含む。
・getALPGRefList()：ベンダコンパイラがＯＦＭに、このパターンソース内で参照されるＡＬＰＧパターンのアレイを提供することを要求する場合には、ベンダコンパイラはgetALPGRefList()メソッドを呼び出す。
・getDomainList()：ベンダコンパイラがＯＦＭに、このパターンによって用いられるドメインのアレイを提供することを要求する場合には、ベンダコンパイラはgetDomainList()メソッドを呼び出す。１つのパターンが１つのデバイスの全てのドメインのために用いられない場合もあるので、このドメインのアレイは、ピン記述ファイルにおいて指定されるドメインのアレイのサブセットの場合もあることに留意されたい。
・getLabelList()：ベンダコンパイラがＯＦＭに、所与のドメインのためのパターンソースにおいて用いられるLabelのアレイを提供することを要求する場合には、ベンダコンパイラはgetLabelList()メソッドを呼び出す。ラベルはドメイン内の或る範囲を有し、同じラベルを多数のドメインにおいて用いることができることに留意されたい。
・getLabelOpcodeOffset()：ベンダコンパイラがＯＦＭに、所与のドメイン内のラベルのためのOpcodeオフセットを提供することを要求する場合には、ベンダコンパイラはgetLabelOpcodeOffset()メソッドを呼び出す。
・getLabelOperandOffset()：ベンダコンパイラがＯＦＭに、所与のドメイン内のラベルのためのOperandオフセットを提供することを要求する場合には、ベンダコンパイラはgetLabelOperandOffset()メソッドを呼び出す。
・getPXRSetupFileRef()：ベンダコンパイラがＯＦＭに、インポートされるPattern Cross Reference Setupファイルの名前を提供することを要求する場合には、ベンダコンパイラはgetPXRSetupFileRef()メソッドを呼び出す。
・getTimingRef()：ベンダコンパイラがＯＦＭに、ITimFileインターフェースをインプリメントするオブジェクトを提供することを要求する場合には、ベンダコンパイラはgetTimingRef()メソッドを呼び出す。このクラスは、このファイルをパースすることを必要とすることなく、コンパイラがシステム試験プログラム言語タイミングファイルの設定にアクセスできるようにする。
・getTimingMapRef()：ベンダコンパイラがＯＦＭに、ITMapFileインターフェースをインプリメントするオブジェクトを提供することを要求する場合には、ベンダコンパイラはgetTimingMapRef()メソッドを呼び出す。このクラスは、このファイルをパースすることを必要とすることなく、コンパイラが試験システムタイミングマップファイルの設定にアクセスできるようにする。
・getCyclizedPatternType()：ベンダコンパイラがＯＦＭに、指定されるパターンのタイプ（SQPG、ALPG、SUBR、SCAN、ESCAN）を提供することを要求する場合には、ベンダコンパイラはgetCyclizedPatternType()メソッドを呼び出す。
・getTMapResolutionChecksFlag():ベンダコンパイラは、試験システム変数TMAP_RESOLUTION_CHECKＳがシステム環境構成ファイル内でセットされるか否かを問い合わせるために、getTMapResolutionChecksFlag()メソッドを呼び出す。

［OFMLabelReader］
ベンダパターンコンパイラは、サイクライズパターンブロックをコンパイルするときに、サブルーチンパターンオブジェクトメタファイルおよびＡＬＰＧパターンオブジェクトメタファイルのラベルおよびオフセットにアクセスする必要がある。このアクセスは、OFMLabelReaderクラス１３１０によって提供される。このクラスは、POFCyclizedModuleAgentクラスと同じように機能し、ドメイン毎にメタファイルのサブルーチンおよびALPGラベル／オフセットデータへの読出し専用アクセスを提供する。ベンダコンパイラは、参照されるサブルーチン／ALPGパターン毎にこのオブジェクトをインスタンス化し、そのタスクが完了するときに、そのオブジェクトを削除することができる。この実施形態では、これは、サイクライズデジタルモジュールパターンコンパイラに特有である。OFMLabelReaderクラス１３１０は以下のメソッドを含む。
・OFMLabelReader()：ベンダコンパイラは、指定されたサブルーチンまたはALPGパターンオブジェクトメタファイルのためのOFMLabelReaderオブジェクトを構成するために、OFMLabelReader()メソッドを呼び出す。
・open()：ベンダコンパイラは、OFMLabelReaderオブジェクトがファイルを開くために、open()メソッドを呼び出す。
・close()：ベンダコンパイラは、OFMLabelReaderオブジェクトがファイルを閉じるために、close()メソッドを呼び出す。
・getLabelsList()：ベンダコンパイラがＯＦＭに、OFMLabelReaderインスタンスの所与のドメインのためのラベルのアレイをゲットすることを要求する場合には、ベンダコンパイラはgetLabelsList()メソッドを呼び出す。
・getLabelOpcodeOffset()：ベンダコンパイラがＯＦＭに、OFMLabelReaderインスタンスの所与のドメイン内のラベルのためのOpcodeオフセットを読み出すことを要求する場合には、ベンダコンパイラはgetLabelOpcodeOffset()メソッドを呼び出す。
・getLabelOperandOffset()：ベンダコンパイラがＯＦＭに、OFMLabelReaderインスタンスの所与のドメイン内のラベルのためのOperandオフセットを読み出すことを要求する場合には、ベンダコンパイラはgetLabelOperandOffset()メソッドを呼び出す。
・getSourceVersion()：ベンダコンパイラがＯＦＭに、このOFMLabelReaderインスタンスによって表されるサブルーチンパターンオブジェクトファイルを生成するために用いられるソースファイルのVersionを読み出すことを要求する場合には、ベンダコンパイラはgetSourceVersion()メソッドを呼び出す。

一実施形態では、パターンブロックは、Pattern Blockのタイプをカプセル化する最も上位のオブジェクトである。１つのパターンソースファイル内に、パターンブロックのうちの１つまたは複数が存在することができる。各パターンブロックは、ただ１つのCommonSectionおよび０または１つ以上のVendorSection（モジュールセクションとも呼ばれる）を含む。ＯＦＭフレームワークは、以下のタイプのパターンブロックをサポートする：MainPattern、SubrPattern、ALPGPatternおよびPattern。MainPattern、SubrPatternおよびALPGPatternは、サイクライズパターンを取り扱うための特有のブロックである。汎用のパターンタイプは、ＯＦＭフレームワークが他のテスタパターン言語をトランスペアレントに使用できるように拡張可能である。

以下はパターンソースファイルの一例である。それは、サイクライズデジタルモジュールおよび仮想汎用パターン（タイプＦＯＯ）のためのMainPatternを含む。同じソースファイル内にサイクライズパターンおよびＦＯＯタイプパターンを入れる理由は、サイクライズMainPatternブロックおよびＦＯＯパターンブロックが、共にただ１つのエンティティとして用いることができるほど十分に密接に関連しているためであることに留意されたい。この例では、Pattern FOOのCommonSection内の構文は、試験システム内のタイプFOOの全てのパターンために標準化されている構文であるものと仮定される。標準的な構文が存在しない場合には、CommonSectionは空であってもよい。

#
# Filename : main1. pat (produces object file main1.pobj)
#
Version 1.0 ;
#
---------------------------------------------------------------------------------------------------------
# Main Pattern definition:
#
---------------------------------------------------------------------------------------------------------
MainPattern
{
CommonSection
{
$ define ALL_H (H*)
$ define ALL_L (L*)
$ define ALL_0 (0*)
$ define ALL_1 (1*)
# ----------------------------------------------------------------------------------------
# Timing Specifications
# ----------------------------------------------------------------------------------------
Timing "productionTiming.tim:ProductionTiming";

# ----------------------------------------------------------------------------------------
# Pin Description file Specifications
# ----------------------------------------------------------------------------------------
PinDescription "Pin.pin";

# ----------------------------------------------------------------------------------------
# Setup file Specifications
# ----------------------------------------------------------------------------------------
Pxr "setup.pxr";

# ----------------------------------------------------------------------------------------
# Default Domain Cycles
# ----------------------------------------------------------------------------------------
Domain default
{
# ------------------------------------------------------------------------
# label:instruction {Vector/Waveform Data}
# ------------------------------------------------------------------------
NOP { V { DIR=1; APins=$ (ALL_1) ;
BPins=$ (ALL_H); OE_=0; } W {AllPins=wfs1; } }
NOP { V { APins=${ALL_0}; BPins=${ALL_L}; } }
NOP { V { APins=10000000; BPins=HLLLLLLL; } }
NOP { V { APins=${ALL_1}; BPins=${ALL_H}; } }
EXIT { V { APins=${ALL_0}; BPins=${ALL_L}; } }
}
}
}
# ---------------------------------------------------------------------------------------------------------
# FOO Pattern definition;
# ---------------------------------------------------------------------------------------------------------
Pattern FOO
{
CommonSection
{
NumberOfData = 192;
DataFormat
{
float, int;
}
Data
{
0.0E+00, 1;
5.21E+00, 0;
. . . . ;
}
}
VendorSection 1
{
Compression = ENABLED;
}

同じタイプの多数のインスタンスは許されない。これは、MainPattern、SubrPatternまたはALPGPatternブロックのうちの１つだけが同じサイクライズパターンタイプとして取り扱われることを意味する。以下の例は、同じタイプ（サイクライズ）の２つのパターンブロックを含むときにエラーを生成する。

#
---------------------------------------------------------------------------------------------------------
# File twoCyclizedTypes.pat
#
---------------------------------------------------------------------------------------------------------

Version 1.0;
#
# This is the main cyclized pattern block
#
MainPattern
{
CommonSection
{
. . .
}
}
#
# This is the subroutine cyclized pattern block
#
SubrPattern
{
CommonSection
{
. . .
}
}

パターンの場合、宣言されたタイプのただ１つのインスタンスが許される。他の異なる、宣言されたタイプの場合、パターンの多数のインスタンスが許される場合もある。以下の例は、PatternFOO1およびPatternFOO2の２つのインスタンス、ならびにタイプMainPatternのPattern Blockインスタンスを含む。

#
---------------------------------------------------------------------------------------------------------
# File threeTypes.pat
#
---------------------------------------------------------------------------------------------------------

Version 1.0;

#
# This is the main cyclized pattern block
#
MainPattern
{
CommonSection
{
. . .
}
}
# Thisis ,a pattern block of generic type FOO1
#
Pattern FOO1
{
CommonSection
{
. . .
}
}
#
# This is a pattern block of generic type FOO2
#
Pattern FOO2
{
CommonSection
{
. . .
}
}

CommonSectionブロックは、試験システムのために標準化されるパターンタイプの記述を含む。このセクションの内容によって、この標準的な構文が、種々のコンパイラによって同じように解釈されるようになる。そのような標準的な構文の一例は、CyclizedデジタルモジュールのためのMainPatternのために定義される構文である。試験システム内のこのタイプのための標準的な構文が存在しない場合には、空のCommonSectionが定義される。

ＯＦＭフレームワークによって、各モジュールコンパイラが、各Patternブロック内の対応するモジュールセクションの内容を判定できるようになる。他のベンダコンパイラは、ベンダ特有のPatternブロックにおいて確立される内容にアクセスすることを許されない。

［パターンオブジェクトメタファイル］
要約情報および他の共通の構成情報がパターンオブジェクトメタファイルのメイン共通ヘッダに格納される。その要約は、パターンオブジェクト内の種々のパターンブロックにアクセスするために必要な情報からなる。以下の情報がメイン共通ヘッダに格納される。
１．パターンソースファイル名。
２．ソースファイルからのバージョン情報。
３．パターンコンパイル中に用いられることになる、Ｓｏｃｋｅｔファイル、Utility Configuration FileおよびModule Configuration Fileへの参照。
４．パターンオブジェクトメタファイル内に収容されるパターンブロックのタイプのコレクション。

各パターンブロックはヘッダセクションを有し、ヘッダセクションは、アドレスのプリロード分解などを処理するため、またはデータロギングを処理するために必要とされる情報を含む。各パターンブロックの共通セクションの意味は、特定のブロックタイプの場合と概ね同じであるので、各コンパイラは同じ要約情報を提供することができる。こうして、メタファイルを書く第１のコンパイラがこの情報を格納する。以下の情報は、非サイクライズブロックの共通セクションヘッダに格納される。
１．ソースファイルにおいて宣言されるようなパターンのタイプ。
２．パターンソースファイルの共通セクション内のサブルーチン参照のマップ。
３．このタイプのパターンブロックのために必要とされる場合には、Ｐｉｎ設定ファイルへの参照。
４．このパターンにおいて定義される同期したブロックのマップ。これは、システムピン記述ファイル内のkeyword Synchronizedで定義される名前に対応する。

以下の情報は、サイクライズブロックの共通セクションヘッダに格納される。
１．ソースファイルにおいて宣言されるようなパターンのタイプ。
２．パターンソースファイルの共通セクション内のサブルーチン参照のマップ。
３．このパターンにおいて定義されるドメインブロックのマップ。これは、システムピン記述ファイル内のkeyword Domainで定義される名前に対応する。これらの名前は、非サイクライズパターンのためのSynchronizedブロックと同じようにしてＯＦＭフレームワークによって処理される。
４．パターンソースファイルの共通セクションにおいて用いられる波形およびタイミング名のリスト。
５．パターンソースファイルの共通セクション内のベクトルオペコードおよびオペランドアドレスへのラベル参照のマップ。
６．パターンソースファイルにおいて指定されるPin、Timing、Timing Mapおよび他の設定への参照。

図１４は、パターンオブジェクトメタファイル（PatternObjMetaFile）とそのサポート用クラスとの間のインタラクションを示す。PatternObjMetaFileクラス１４０２は、サイクライズパターンオブジェクトブロック（POFCyclizedCommonSection）クラス１４１６の１つのインスタンスと、非サイクライズパターンオブジェクトブロック（POFCommonSection）クラス１４０８の０または１つ以上のインスタンスとを含む。パターンオブジェクトメタファイル(PatternObjMetaFile)クラス１４０２は、パターンオブジェクトメタファイルの機能をカプセル化し、ＯＦＭフレームワークに、メタファイルとやりとりするためのＡＰＩを提供する。

POFCommonSectionクラス１４０８は、メタファイル内の非サイクライズパターンオブジェクトの機能をカプセル化する。このクラスは、ＰＯＦ共通セクションインターフェース(IPOFCommonSection)１４１０をインプリメントする。ObjMetaFileクラス１４０５は、パターンオブジェクトメタファイルのプロプリエタリベンダセクションへのクライアントアクセスを提供する。プロプリエタリベンダモジュールセクションは、POFModuleオブジェクト１４１２およびそれらの対応するPOFBLOBオブジェクト１４１４内にカプセル化される。各POFModuleオブジェクトは、ベンダの特定のモジュールに関連する。１つのベンダが２つ以上のモジュールを提供することができ、それゆえ、１つのパターンオブジェクトメタファイル内に２つ以上のモジュールセクションを有することができる。

POFCyclizedCommonSectionクラス１４１６は、サイクルベースのデジタルパターンオブジェクトブロックの機能をカプセル化する。このクラスは、ＰＯＦサイクライズ共通セクションインターフェース（IPOFCyclizedCommonSection）１４１８をインプリメントする。それは、全てのパターンブロックタイプのために提供される、サイクルベースの共通セクションデータ、および非サイクルベースの共通データの両方へのアクセスを提供するので、POFCommonSectionクラスとは異なる。

［ＯＦＭフレームワークとベンダモジュールコンパイラとの間のインタラクション］
一実施形態では、試験システムパターンコンパイラは、特定のサイト構成（用いられるベンダ特有のデジタルモジュールに照らして）をターゲットにする。種々のベンダからのモジュールの試験システムへの組み込みをサポートするために、以下の手法がインプリメントされる。
１．ベンダコンパイラはパターンオブジェクトファイルを直に作成しない。代わりに、試験システムは、ＯＦＭによって管理されるパターンオブジェクトメタファイルを提供する。用語「パターンオブジェクトメタファイル」は、オブジェクトメタファイルとも呼ばれる。ＯＦＭフレームワークは、共通パターンデータのメタファイルへの格納を管理するが、種々のモジュールベンダからのプラグインに基づいて、ベンダ特有のデータのコンパイルを呼び出す。パターンコンパイルプロセスのためのモデルは、図６に示されるように視覚化することができる。パターンオブジェクトメタファイルは、パターンソースファイルと同じ名前を有するが、ソースファイル拡張子がパターンオブジェクトファイル拡張子によって置き換えられる。ＯＦＭは、これらのファイルに対する読出しおよび書込みのためのアプリケーションプログラミングインターフェース（ＡＰＩ）を提供する。パターンオブジェクトメタファイルは、以下のものを格納するための手段を有する。
ａ．共通ヘッダ情報
ｂ．モジュール特有ヘッダ情報
ｃ．モジュールベンダによって編成され、モジュールベンダによって解釈されることができるモジュール特有パターンデータ
２．各モジュールベンダは、動的にロード可能なライブラリの形で、自ら所有するパターンコンパイラを提供する責任がある。このライブラリは、IVendorPatCompilerまたはIVendorCyclizedPatCompiler、あるいはその両方のような、ＯＦＭフレームワークによって定義される標準インターフェースの完全なインプリメンテーションを検索する能力を与える。IVendorPatCompilerインターフェースを提供する機能は以下のライブラリによって与えられる。

OFCStatus create VendorPatCompiler (
IVendorPatCompiler*&pCompiler,
const OFCString& type);

さらに、IVendorCyclizedPatCompilerインターフェースを提供する機能はベンダによって与えられる。

OFCStatus create VendorCyclizedPatCompiler (
IVendorCyclizedPatCompiler*& pCompiler);

ベンダがCyclizedデジタルパターンまたは特定のタイプの汎用パターンのためのコンパイラをサポートしない場合には、上記の機能は予め定義されたOFCStatusを返し、要求されたコンパイラタイプがサポートされないことをＯＦＭフレームワークに通知する。
３．ＯＦＭフレームワークは、パターンコンパイルのタスクをサポートするために必要とされる、ベンダコンパイラが共通データにアクセスできるようにするための１組のインターフェースを含む。これは、ＤＵＴピン、ＤＵＴソケットおよびＤＵＴタイミングの記述をカプセル化するランタイムオブジェクトへのアクセスを含む。またそれは、パターンサブルーチンのような、他の参照されるパターンメタファイルにアクセスするための能力も含む。
４．ＯＦＭフレームワークは、モジュールベンダのコンパイラがモジュール特有のヘッダ情報およびデータをパターンオブジェクトメタファイルに書き込むことができるようにするための１組のインターフェースも含む。オブジェクトメタファイルのこのレイアウトによって、ターゲットとされるサイト内の２つ以上のモジュールが同じ場合であっても、パターンデータがモジュール毎に編成されるようになることに留意されたい。

上記の手法によって、多数のベンダが、自らの独自開発のフォーマットを使用し続けることができるようになり、かつ多数のベンダからのモジュールがオープンアーキテクチャ試験システム内で共存できるようになる。メタファイルのベンダ特有セクションは「ブラックボックス」として取り扱われ、ＯＦＭフレームワークはそれについての特定の知識を有する必要はなく、他のベンダはそれにアクセスできない。

別の実施形態では、パターンコンパイル中のVendor Module CompilerとＯＦＭフレームワークとのインタラクションは、以下に記述されるステップのシーケンスにおいて例示される。
１．ＯＦＭフレームワークはOFMManagerのインスタンスをインスタンス化し、SYSTEMパターンコンパイラのコマンドラインにおいて指定される１つまたは複数のパターンのコンパイルを管理する。
２．OFMManagerは初期化されるようになる。これは、システムユーティリティズ構成ファイルを用いて、指定された（ベンダ毎およびモジュール毎）全てのパターンコンパイラ・ダイナミックリンクライブラリ（ＤＬＬ）を登録することを含む。システムユーティリティズ構成ファイルは、或る特定のシステム構成のユーティリティ設定を指定する。このファイルは、パターンコンパイラＤＬＬ（複数の場合もあり）の名前（複数の場合もあり）と、ベンダのモジュール（複数の場合もあり）毎に登録される共有されるライブラリとを含む。この情報は、種々のベンダコンパイラを呼び出して、パターンソースファイルの対応するセクションをコンパイルするために、ＯＦＭフレームワークによって用いられる。登録の一部として、それがサポートするパターンブロックのタイプを見つけ出すために、各ＤＬＬが問い合わせを受ける。
３．その後、OFMManagerはPatternObjectMetaFileクラスを用いて、全パターンソースファイルに共通のデータをセーブする。このステップの一部として、フレームワークはパターンソースファイルを読み出し、このパターンソースファイルを含むパターンブロックのタイプを検索する。見つけられたパターンブロックの種々のタイプが共通セクションに格納される。フレームワークがパターンブロックの２つの広義のタイプ、CyclizedとRegular（非Cyclized）とを区別することに留意されたい。通常のパターンブロックは、それらのタイプを定義する任意の名前を有することができる。ＯＦＭフレームワークは、これらの名前を予め通知される必要はないので、システムはオープンアーキテクチャを有することができる。
４．コンパイルされるパターンソース内に含まれるパターンブロックのタイプ毎に、その後、OFMManagerはベンダパターンコンパイラＤＬＬを問い合わせて、IVendorPatCompilerインターフェースをインプリメントするオブジェクトをインスタンス化する。サイクライズパターンブロックがコンパイルされている場合、OFMManagerはＤＬＬを問い合わせて、代わりに、ICyclizedVendorPatCompilerインターフェース（それはIVendorCompileｒインターフェースのサブタイプである）をインプリメントするオブジェクトをインスタンス化する。
５．上記のステップ４において得られたIVendorCompiler派生オブジェクト毎に、OFMManagerはgetSupportedResources()メソッドをコールし、このモジュールによってサポートされるシステム資源のリストをゲットする。システム資源のリストを用いて（SocketファイルおよびシステムModule Configuration File(MCF)とともに）、コンパイルされる必要がある資源のコレクションが作成される。パターンコンパイルのためにベンダコンパイラがそのようなリストを提供される必要がある場合には、同じくシステム資源のリストを用いて、被試験デバイス（ＤＵＴ）のためのピンのリストが作成される。コンパイルされているパターンがピン向きには記述されず、それゆえコンパイラがピンリストを必要としない場合もあるので、ＯＦＭフレームワークはこれを強制しないことに留意されたい。その場合には、IVendorPatCompilerインターフェースが、ｎｅｅｄｓＰｉｎＮａｍｅｓ（）メソッドをサポートし、OFMManagerが、特定のベンダコンパイラがＤＵＴピンのリストを必要とするか否かを見いだすことができるようにする。
６．OFMManagerは、コンパイルされているパターンブロックのタイプをサポートする各IVendorPatCompilerインターフェースのcompile()メソッドを呼び出す。それは、このメソッドに以下の引き数を与える。
ａ．パターンソースにおいて参照される資源タイプのリスト、および（オプションで）そのような各資源タイプのピン名のリスト。ピンが必要とされない場合には、ピンのリストは空である。
ｂ．ベンダパターンコンパイラが、パターンオブジェクトメタファイルに読出しアクセスおよび書込みアクセスできるようにするためのOFMModuleAgent派生オブジェクト（またはサイクライズパターンの場合のPOFCyclizedModuleAgent）のインスタンス。
７．パターンソースの各ブロックをコンパイルした後に、OFMManagerは、最初に用いられたコンパイラに、共通セクションデータを問い合わせて、その後、それを用いて、パターンオブジェクトメタファイルが更新される。
８．その後、OFMManagerは各ベンダパターンコンパイラに、出合ったエラー／警告のリストを問い合わせる。このエラー／警告のリストは一纏めにされて、ユーザに提供される。
９．コンパイルされるパターンソースファイル毎にステップ３〜８が繰り返されて、対応するパターンオブジェクトメタファイルが生成される。
１０．最後に、OFMManagerは、このステップシーケンスのステップ２において登録された全てのベンダパターンコンパイラを公開する。これにより、種々のベンダコンパイラが、コンパイルプロセスが終了する前に、クリーンアップできるようになる。

［パターンデータのローディング］
本発明の一実施形態の試験システムでは、各モジュールベンダが、自ら所有する特有のパターンローディング機構を提供する責任を担う。先に説明されたように、パターンオブジェクトメタファイルは、種々のセクションにモジュール特有データを格納する。ベンダインプリメンテーションは、パターンオブジェクトメタファイルから関連するセクションにアクセスするために、システムアプリケーションプログラミングインターフェース（ＡＰＩ）を用いる。さらにＯＦＭフレームワークは、各モジュールのロードパターンメソッドをコールし、モジュール特有のデータをメタファイルの適当なセクションからモジュールにロードする責任を担う。

パターンローディングのためのＯＦＭフレームワークとベンダモジュールとの間のインタラクションを例示するステップのシーケンスが以下に説明される。
１．PatternMgrオブジェクトが、パターン実行シーケンスを含むパターンのコレクションをロードするための責任を担う。このオブジェクトは、ロードされるパターン毎にPatternLoaderインスタンスをインスタンス化する。
２．PatternLoaderは、ロードされるパターンのためのPatternObjMetaFileクラスのインスタンスをインスタンス化し、それに、パターンオブジェクトメタファイル内のパターンブロックのタイプのリストを問い合わせる。PatternLoaderはさらに、PatternObjMetaFileクラスに、各パターンブロックタイプ内に含まれるモジュールのタイプを問い合わせる。
３．その後、PatternLoaderは、ベンダによって提供される対応する派生IModuleクラスのloadPattern()メソッドを呼び出し、ブロックおよびモジュールのタイプ毎にパターンデータをロードする。
４．対応するIModuleインターフェースのloadPattern()メソッドは、PatternLoaderクラスに渡された参照を用いる。その後、それはPatternLoaderクラスのload()メソッドを用いて、PatternObjMetaFileクラスにアクセスし、それからモジュール特有のデータを読み出し、それによりパターンのローディングを達成する。

［Ｅ５．パターンファイル］
各コンパイラベンダは複数のパターンのための種々のプレーンテキストフォーマットを完全に指定することができ、それは実際には大部分の場合に必要になるであろう。しかしながら、一般的に、全てのベクトルのために複数のモジュールにわたる統一性および同一の意味が必要になる、サイクルベースの試験環境の場合、パターンファイルのための、共有され、一般化された構文が望ましいだけでなく、必要になるであろう。この共有された構文は、パターンソースファイル内の「共通」セクションのために指定されることになる構文である。実際には、大抵の場合に、「共通」セクションはパターンファイルにおいて必要とされる唯一のセクション（ヘッダ情報を除く）であり、全てのベンダのコンパイラはそのセクションにおいてのみ正常に動作することが想定される。このセクションは、全てのコンパイラが解釈できるべきである、パターンファイルのための規則を表す。パターンファイルは以下のように編成されるであろう。

file_contents :
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

以下は、先に用いられた未定義の非終端記号の記述である。
１．version-identifier：集合［０−９］からの１つまたは複数の文字からなる文字列であり、最初の文字は数字でなければならない。
２．identifier：集合［ａ−ｚＡ−Ｚ＿０−９］からの１つまたは複数の文字からなる文字列であり、最初の文字は［ａ−ｚＡ−Ｚ＿］から選択されなければならない。
３．vendor-section-contents：ベンダ特有のコンパイラに対してのみ意味のある任意のテキスト。
４．file-name：有効なウインドウズファイル名（ファイル名内に任意の空白が含まれる場合には、それは二重引用符で囲まれなければならない）。これは単純なファイル名でなければならない、すなわちディレクトリコンポーネントを持つべきでないことに留意されたい。
５．waveform-table-pin-group-name：集合［ａ−ｚＡ−Ｚ＿０−９］からの１つまたは複数の文字からなる文字列であり、最初の文字は［ａ−ｚＡ−Ｚ＿］から選択されなければならない。この変数は他の場所で宣言され、ピンのグループに共通である波形テーブルの名前を保持する。
６．24bit number：最大１６７７７２１５までの有効な１０進数。
７．8bit number：最大２５６までの有効な１０進数。
８．index-register：有効な１０進数。１つのモジュールの実施形態では、これは値［１−８］を有することができる。
９．vector：これは、ＳＴＩＬ内のＶｅｃｔｏｒステートメントに類似である。これは、信号名および信号グループ名を参照し、コンパイラがPin Descriptionファイルにアクセスできるようにするために必要になることに留意されたい。
１０．waveform-time-reference：集合［ａ−ｚＡ−Ｚ＿０−９］からの１つまたは複数の文字からなる文字列であり、最初の文字は［ａ−ｚＡ−Ｚ＿］から選択されなければならない。

パターンファイルはコメントをサポートし、コメントはパターンファイルコンパイラによって無視されることになっている。コメントは「＃」文字で始まり、その行の終わりまで続く。

パターンファイルのヘッダおよび「共通」セクションの構成体を参照して、以下の点に留意されたい。
１．pattern-name項目は、パターンファイルがそのためのデータを含むＰａｔｔｅｒｎオブジェクトに関連付けられることになる名前を指定する。これは、対応するパターンオブジェクトメタファイル内のヘッダに引き継がれるようになる。
２．waveform-time-referenceは、Timingファイル内の、パターンファイルに対して外部から定義されることになる特定のwaveform-and-timing定義のための名前である。パターンファイルにおいてwaveform-time-referenceを指定することにより、別のwaveform-time-referenceが現われるまで、（waveform-and-timingのための）特定の名前が全ての後続のベクトルに結合されるであろう。
３．サブルーチンコールのためのオペランド（たとえば、ＪＳＲおよびＪＳＲＣ）は、同じパターンファイルにおいて以前に現われたpattern-specラベル、または外部から定義されたサブルーチンパターン内のpattern-specラベルであるストリングである。このオペランドは最終的には、サブルーチンをロード／処理するために分解されるであろう。サブルーチンコールオペランドのためのラベルは、システムにわたって固有である必要がある。

waveform-time-reference名は、構文的に正確であるなら何でも用いることができるが、特定のハードウエア含意に起因して、waveform-time-reference名は予めわかっている明確な集合に限定される必要があり得る（さらに読みやすくするために、それはオプションでは、ユーザ選択の名前にユーザによってマッピングされることができ、そのマッピングはオプションのファイルにおいて提示される）ことに留意されたい。

また、パターンおよびwaveform-time-referenceソースファイルは、物理的なテスタチャネルに接続される全てのＤＵＴチャネルのための初期構成データを提供すべきであることにも留意されたい。任意のＤＵＴチャネルの場合に後続のデータが省略される場合には、パターンコンパイラは、パターンデータを「パッド」して、初期レベルからの出力を保持するであろう。

［パターンファイル例］
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パターンソースファイルを例示する別の例が以下に示される。

# -------------------------------------------------------------
# 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; } }
}
}
}

パターンソースファイル内のメインヘッダおよび共通セクションからの要約情報は、オブジェクトメタファイル内のメインヘッダに格納される。その要約は、アドレスなどのプリロード分解を助けるために、またはデータロギングにおいて助けるために、迅速に抽出するために通常必要とされる情報からなる。共通セクションの意味は全てのコンパイラの場合と厳密に同じであるので、全てのコンパイラが同じ要約情報を提供することができ、メタファイルを書く第１のコンパイラがこの情報を格納するであろう。以下は、格納されることになる情報である。
１．パターンソースファイル名
２．ソースファイルにおいて宣言されるようなパターンのタイプ
３．ソースファイルからのバージョン情報
４．パターンソースファイルの共通セクションにおいて用いられる全てのwaveform-and-timing名のリスト
５．パターンソースファイルの共通セクション内の（相対的な）ベクトルアドレスへの全てのサブルーチン参照のマップ
６．パターンソースファイルの共通セクション内の（相対的な）ベクトルアドレスへの全てのラベル参照のマップ
７．一般的なブックキーピング情報：ベクトルカウント、命令カウントなど。

オープンアーキテクチャ試験システムは、明示的で、かつ異なる拡張子を有するために、パターンおよびパターンリストファイルの両方を必要とする。パターンファイルの場合、これは、プレーンテキストソースおよびコンパイルされたオブジェクトファイルの両方に当てはまる。これは、ディレクトリリスティング等において視覚的にファイルタイプを迅速に特定するために、および拡張子に基づいて連想がなされるようにするために、ユーザにとって好都合であると考えられる。パターンリストファイルパーサは、これらの拡張子を用いてファイル名を予想するであろう。
プレーンテキストパターンソースファイル：.pat
コンパイルされたパターンオブジェクトメタファイル：.pobj
パターンリストファイル：.plst

ユーザは、たとえば、テスタ環境変数または設定オプションを通して、これらのデフォルト値を無効にすることができる。

テスタは、以下に記述される環境構成ファイルのうちの少なくとも１つにおいて、ファイル探索経路のための以下の「環境」変数の定義を必要とするであろう。
Tester_PATLIST_PATH：パターンリストファイルの場合。
Tester_PATSRC_PATH：パターンソースファイル（オプション）の場合。
Tester_PATOBJ_PATH：パターンオブジェクトメタファイルの場合。

オプションの環境／設定変数Tester_PATSRC_PATHが定義されない場合には、Tester_PATOBJ_PATHと同じであると仮定されることに留意されたい。一般的に、Tester_PATOBJ_PATHと同じ値である場合、Tester_PATSRC_PATHを定義するよりも、定義しないほうが、より効率的であろう。

［Ｅ６．ソフトウエア表現］
パターンオブジェクトはユーザによって作成されない。むしろ、ユーザは常に、他のパターンリストおよび／またはパターンのコレクションであるパターンリストオブジェクトを処理する。ユーザがアクセスできるようにしながら、パターンリストオブジェクトは、その中に含まれるパターンオブジェクトを作成し、所有し、保持する。ユーザの試験プログラム内のパターンリストオブジェクトは、パターンリストの実際の定義を含む、ディスク上のパターンリストファイルに関連する。パターンリストの定義は、そのパターンリストのための明示的な名前を提供し、ファイル名連想を通して、パターンの順序付きリストおよび／または他のパターンリストを特定する。このセクションは、パターンリストおよびパターンのソフトウエアがテスタフレームワークにおいて如何に操作されるかを理解するための前置きとして、それらのソフトウエア表現を記述する。

［パターンリスト連想］
試験システム内の１つの試験サイト（および拡大解釈して、その中にある試験計画）は、多数のトップレベルパターンリストに関連付けることができる。しかしながら、複数の試験計画に対して、常に１つの実行文脈だけが存在する。トップレベルパターンリストは、それによって（階層的に）参照されるパターンのための実行シーケンスを定義するので、アクティブな実行文脈は、現在選択されているトップレベルパターンリストに対応するものである。これは、ある時点において、１つのパターンリスト内に含まれるパターンだけがハードウエア上にロードされることができることを意味しないことに留意されたい。むしろ、１つの実行シーケンスを実行可能にするためにハードウエア上にロードされる必要がある１組のパターンは常に、現在ロードされている全てのパターンのサブセットでなければならない。

［パターン木］
直観的には、トップレベルパターンリストを表現するための１つの方法は、ある種の木データ構造によると考えられる。図７は、本発明の順序付きのパターン木の１つの実施形態を示しており、パターンリストＡがトップレベルパターンリストであると仮定する。

［パターン木情報内容］
以下の情報がパターン木の全てのノードにおいて格納されるであろう。
１．そのノードに関連するエンティティ（パターンリストまたはパターン）の名前。
２．定義ソースのタイプ。葉（パターンノード）の場合、これは常にパターンファイルになるであろう。中間（パターンリスト）ノードの場合、これは「トップレベルファイル」（トップレベルパターンリスト定義用）、または「エンベデッド・イン・ファイル」（ネストされたパターンリスト定義用）のいずれかにすることができる。
３．そのノードが関連するディスク上のファイルの最後の変更タイムスタンプ。

以下の付加情報は、中間（パターンリスト）ノードにおいてのみ格納されるであろう。
１．そのノードによって表されるパターンリストオブジェクト上に（もしあるなら）セットされる実行オプション、すなわちそのオブジェクトオプション。
２．その子毎に、そのノードによって表されるパターンリスト定義内の各子参照上に（もしあるなら）セットされる実行オプション、すなわち参照オプション。

こうして、ルートから中間ノードへの固有の経路において現われるノードのコレクション、およびそれらに出合ったシーケンスは、そのノードによって表される、組み合わせられた有効な実行オプションを決定するために必要とされる全ての情報を含む。１つのパターンの実行オプションは、その中間の親の有効な実行オプションと、それと組み合わせた、その中間の親がそのために有することができる参照オプションによって決定される。

ここで、パターンリストパーサがパターン木を作成している過程にあるときに、その使用の文脈が後の時点まで分解されない場合もあるので、ある特定の実行オプションが単にストリングとして値を最初に格納する必要があるかもしれないことに留意されたい。そのようなオプションの１つの例は「マスク」オプションであり、それは、ピンマスク情報を指定する。パターンリストはＳｏｃｋｅｔ情報に関連しないので、ピンマスクオプション（ピンおよびグループ名）は、ローディング前に分解されるべきストリングとして格納される。

以下の付加情報は葉（パターン）ノードにおいてのみ格納されるであろう。
１．実行木として編成される、外部および内部両方のパターンによってコールされるサブルーチンへの全ての（おそらく遷移的な）参照。

当然、全てのパターンノードはさらに、オブジェクトメタファイル共通ヘッダにおいて入手可能な全てのパターンファイル要約情報にアクセスでき、そしてそれらをキャッシュすることができるであろう。

［パターンリスト変更の処理］
パターンリストの内容に対してなされる変更は概念的には、そのパターンリストへの全ての参照に影響を及ぼす。必要に応じてパターンオブジェクトおよびパターンリストオブジェクトに適用される以下の規則が、そのような変更を管理するために用いられるであろう。
１．ディスク上のパターンリストファイルの内容に対してなされる変更は、そのパターンリスト上（またはそれを参照する任意の他のパターンリスト上）で実行されるｌｏａｄ（）コマンドにおいてのみ、試験システムの中に伝えられるであろう。言い換えると、ソフトウエア内のパターンリスト階層は常に、ハードウエア上に現在ロードされているパターンリストを反映するであろう。
２．ユーザは、パターンリストをそれらのディスクファイルソースと同期させるために、ロード時間中に行われる検査を無効にするモードをセットすることができるであろう。これにより、生成モードの動作を、より迅速かつ安全にすることができるであろう。

［パターン木ナビゲーション］
試験サイト（および拡大解釈して、そのサイトのための試験計画）に関連するトップレベルパターンリストは公開（グローバル）範囲を有する。そのシステムは、ユーザが個々のノードおよび副木にアクセスできるように、トップレベルパターンリストを表すパターン木をナビゲートするためのＡＰＩを提供する。

［Ｅ７．パターンリスト動力学］
パターンリストの静的な規則は先に説明された。パターンリストの動的な（実行）規則の記述がここで提示される。

パターン木は包括的なパターン管理のために不可欠である。たとえば、１つのパターンロードシーケンスのための開始点は、サイトまたは試験計画に現在関連しているパターン木上でのload()メソッドへのコールである。しかしながら、１つのパターン木は孤立して動作しない。完全に初期化されたパターン木を用いて、以下の２つのフレームワークオブジェクトが作成されるであろう。
１．トップレベルパターンリストは、複数のパターンのための１つのPattern Execution Sequenceを定義する。それは、そのような実行シーケンスをそのトップレベルパターンリストに対応するパターン木から如何に導出することができるかを記述する。たとえば、図７に示されるパターン木Ａに対応するパターン実行シーケンスは｛ｑ、ｓ、ｔ、ｑ、ｒ、ｑ、ｕ、ｕ、ｖ｝である。Pattern Execution Sequenceは概念的には、そのパターン木を通して記述される実行シーケンスを反映する順序木である。フレームワークは、パターン木ノードと、Pattern Execution Sequence内の対応するエントリとの間の任意の必要なナビゲーションリンクを確立し、保持する。
２．Pattern Setは、そのパターン木内の全ての固有のパターン（サブルーチンを含む）のリストに過ぎない。したがって、これは、ハードウエア上にロードされるべきである個々のパターンを決定するために用いられることになるリストである。フレームワークは、パターン木ノードと、Pattern Set内の対応するエントリとの間の任意の必要なナビゲーションリンクを確立し、保持する。図７のパターン木のためのPattern Setは（ｑ、ｓ、ｔ、ｒ、ｕ、ｖ）である（パターンリストＡ内のパターンはいずれも如何なるサブルーチンコールも含まないものと仮定される）。

Pattern Execution SequenceおよびPattern Setはいずれも、常に、パターン木から導出することができることに留意されたい。しかしながら、多くの場合に、実用的である限り、初期構成後に、それらをキャッシュことが理にかなっているであろう。

［パターンリスト実行オプション］
上記のように、各パターンリスト宣言（その定義に先行する）またはパターンリスト／パターン参照エントリの後に、多数の実行オプションが続くことができる。パターンリスト実行オプションは、パターンリストのランタイム実行を変更する。さらに拡張できるようにするために、これらのオプションのための名前（およびオプション値）がパターンコンパイラのパターンリストファイルパーサによって単にストリングとして処理され、必要に応じて特定のバージョンによって解釈されることになる。テスタは、以下に記述される、１組のオプションおよびそれらの解釈を規定する。しかしながら、ベンダはその１組のオプションを拡張することができる。オプション構文をパース時に妥当性検査できるようにするために、パターンリストファイルパーサは、ある特定のバージョンのための情報ファイルを読み出すことができる。そのような情報ファイルを用いて、ある特定のバージョンがそもそも実行オプションの指定をサポートするか否かを指定することもできる。

１組の実行オプションをサポートするバージョンの場合、以下の一般的な規則がそれらの使用法を決定するであろう。これらの規則を理解するために、パターンリスト／パターンの階層的なコレクションを順序木として視覚化することが有用である。
１．パターンリスト定義上（すなわち、ファイル内の「local-pattern-list-declaration、global-pattern-list-declaration」生成物内）でセットされるIntrinsicオプションは、事実上、ユーザの試験プログラム内の対応するパターンリストオブジェクト上での直接的なオプション設定である。したがって、これは、そのパターンリストオブジェクトへの全ての参照に当てはまり、オブジェクトオプションと呼ばれる。
２．パターンリスト／パターンへの参照上（すなわち、ファイル内の「pattern-entry」および「pattern-list-entry」生成物内）でセットされるReferentialオプションは、オプションの範囲を、その階層内の特有の経路、すなわち木のルートから考慮中の参照に導く経路（パターンリスト／パターンの宣言順序によって確立される）に制限する。したがって、これらは、特定のオブジェクト参照上のオプションであり（且つ、オブジェクトそのものにおけるオプションではない）、参照オプションと呼ばれる。
３．コレクション階層（パターンリスト／パターンの宣言順序によって確立される）内の任意のリスト／パターンのための有効オプション設定は、木のルートからそのリスト／パターンまでの経路に沿って出合うオブジェクトオプションおよび参照オプションの組み合わせである。その特定の組み合わせの仕組み（たとえば、集合の結び、集合の交わり、または任意の他の競合解消アルゴリズム）は、オプションそのもののプロパティである。

上記の規則の結果、そして１つのパターンファイル内のパターン定義上で実行オプションをセットするためのファシリティがないという事実は、１つのパターンへの全ての参照に当てはまるオプションをセットするための直接的な規則が存在しないということであることに留意されたい。これを果たすための仕組みは、単一パターンのパターンリストを用いることである。

テスタは、そのバースト挙動を変更し、その実行シーケンスを変更する、ある１組のパターンリスト実行オプションを指定する。

１つのパターンリストのための実行シーケンスがハードウエアに提示されるとき、ハードウエアはバーストを生成する。Burstは、ソフトウエアが何も関与することなく、ハードウエアによって直にパターンのシーケンスを実行することである。Burst Discontinuityは、先行するバーストが終了し、新たなバーストが開始される、実行シーケンス内の場所である。

パターン管理ソフトウエアの目的の１つは、バーストを生成するために必要とされる実行シーケンスをハードウエアに与えることである。デフォルトによって、１つのパターン木は１つの実行シーケンスを生成し、それがハードウエアに提示される場合には、結果として１つのバーストが生成されるであろう。しかしながら、この挙動は、パターンリスト上でオプションを用いることにより変更することができる。したがって、オプション結果を用いる結果として、バースト不連続部が生じ得る。

さらに、ユーザは多くの場合に、全てのパターンまたは全てのバーストの前または後に実行されることになるプロローグまたはエピローグパターンを必要とするであろう。これは、ハードウエアに提示されることになる実行シーケンスを変更する。

Pattern Execution Sequenceオブジェクトの作成または変更中に、フレームワークは、指定された実行オプションと、パターン木によって具現される特定の実行シーケンスとの組み合わせから生じるパターンバースト内のブレークを判定するために必要な全ての情報を有し、必要に応じて報告する。これを果たすときに、システム内のモジュールのハードウエア能力を調査することが必要な場合もある。たとえば、１つのハードウエアインプリメンテーションによれば、ピンマスクのために４つの構成を格納できるようになり、そのうちの２つ（０および３）は（Mask This Vector、ＭＴＶをサポートするために）デフォルトマスクおよびアンマスク演算のために用いられる。こうして、ユーザは、バーストモードをブレークすることなく、２つの異なるグローバルピンマスク構成を許される。

或るモジュールベンダがハードウエアにおいてパターンリストインプリメンテーションをサポートしない場合には、Pattern Execution Sequenceのベンダの処理の結果として、実行シーケンス内の全てのパターンが個別に実行されることになることに留意されたい。Site-CompatibleおよびSite-Heterogeneousの両方のシステムにおいて、サイトのバースト能力は、「最小共通分母」によって制限されるであろう。テスタは、ある特定のデフォルトの１組のオプションを提供し、それらのパラメータが以下に記述される。各オプションは以下のことを述べることにより指定される。
・それがIntrinsicである（すなわち、GlobalまたはLocalキーワードを伴う定義に関連する）か、Referentialである（すなわち、PatまたはPListキーワードを伴う参照に関連する）か。Intrinsicオプションは、定義の場所および全ての参照において当てはまるが、Referentialオプションは、それらが関連する参照においてのみ当てはまる。
・さらに、オプションが全ての静的に（構文的に）または動的に（参照されることにより意味的に）ネストされたパターンまたはパターンリストに再帰的に当てはまるものと仮定される場合には、そのオプションは「子によって継承される」と言われる。

以下はオプションのリストである。全ての準拠するベンダは、これらのオプションを指定されたとおりに解釈するであろう。
１．Mask<pin/pin group>
GlobalPList、LocalPListに適用されるときにIntrinsic。
PList、Patに適用されるときにReferential。
子によって継承される。
このパターンリストは常に、使用禁止の指示されたピンまたはピングループによって参照されるピンの比較回路を有するであろう。多くの場合に、ハードウエアの制限の結果として、バースト不連続部が生じることになる。
２．BurstOff
GlobalPList、LocalPListに適用されるときにIntrinsic。
PList、Patに適用されるときにReferential。
子によって継承されない。
このパターンリストは常に、非バーストモードにおいて実行されるであろう。このオプションは子によって継承されないが、BurstOffDeepオプション（下記）は子によって継承される。
３．BurstOffDeep
GlobalPList、LocalPListに適用されるときにIntrinsic。
PList、Patに適用されるときにReferential。
子によって継承される。
このパターンリストは常に、非バーストモードにおいて実行されるであろう。このオプションは子によって継承されるが、BurstOffオプション（上記）は子によって継承されない。BurstOffDeepオプションは子によって消されないことに留意されたい。
４．PreBurst<pattern>
GlobalPList、LocalPListに適用されるときにIntrinsic。
指定されたバーストオプションを有しない子ノードによってのみ継承される。
指示されるパターンは、このパターンリスト内の全てのバーストに前置されるべきである。PreBurstパターンは、このパターンリストノードに起因して開始される全てのバーストの直前に生じる。そのオプションは、同じパターンであるPreBurstオプションを有するバースト内に既にあるときには適用されない。
５．PostBurst<pattern>
GlobalPList、LocalPListに適用されるときにIntrinsic。
指定されたバーストオプションを有しない子ノードによってのみ継承される。
指示されるパターンは、このパターンリスト内の全てのバーストに後置されるべきである。PostBurstパターンは、このパターンリストノードに起因して開始される全てのバーストの直後に生じる。そのオプションは、同じパターンであるPostBurstオプションを有するバースト内に既にあるときには適用されない。
６．PrePattern<pattern>
GlobalPList、LocalPListに適用されるときにIntrinsic。
子によって継承されない。
指示されるパターンは、このパターンリスト内の全てのパターンに前置されるべきである。
７．PostPattern<pattern>
GlobalPList、LocalPListに適用されるときにIntrinsic。
子によって継承されない。
指示されるパターンは、このパターンリスト内の全てのパターンに後置されるべきである。
８．Alpg<alpg object name>
GlobalPList、LocalPListに適用されるときにIntrinsic。
子によって継承されない。
名前付きＡＬＰＧオブジェクトは、低速ＡＰＧレジスタ設定、読出し待ち時間、中間データレジスタ、アドレススクランブル、データ反転、データ発生器などの関連する情報を格納する。
９．StartPattern<pattern>
GlobalPList、LocalPListに適用されるときにIntrinsic。
子によって継承されない。
そのパターンリストは、その実行シーケンスにおいてStartPatternが最初に現われるときに実行し始めるであろう。
１０．StopPattern<pattern>
GlobalPList、LocalPListに適用されるときにIntrinsic。
子によって継承されない。
そのパターンリストは、その実行シーケンスにおいてStopPatternが最初に現れるときに実行するのを止めるであろう。
１１．StartAddr<vector offset or label>
GlobalPList、LocalPListに適用されるときにIntrinsic。
子によって継承されない。
これはStartPatternオプションを伴わなければならない。そのパターンリストは、その実行シーケンスにおいてStartPatternが最初に現われるときのStartAddrにおいて実行し始めなければならない。
１２．StopAddr<vector offset or label>
GlobalPList、LocalPListに適用されるときにIntrinsic。
子によって継承されない。
これはStopPatternオプションを伴わなければならない。そのパターンリストは、その実行シーケンスにおいてStopPatternが最初に現われるときにStopAddrにおいて実行するのを止めなければならない。
１３．EnableCompare_StartPattern<pattern>
GlobalPList、LocalPListに適用されるときにIntrinsic。
子によって継承されない。
パターン比較は、指示されるパターンが最初に現われるときに開始するであろう。
１４．EnableCompare_StartAddr、EnableCompare_StartCycle
GlobalPList、LocalPListに適用されるときにIntrinsic。
子によって継承されない。
これは、EnabelCompare_StartPatternを伴わなければならない。パターン比較が開始することになるパターン内のアドレスまたはサイクルを指示する。
１５．EnableCompare_StopPattern<pattern>
GlobalPList、LocalPListに適用されるときにIntrinsic。
子によって継承されない。
パターン比較は、指示されるパターンが最初に現われるときに終了するであろう。
１６．EnableCompare_StopAddr、EnableCompare_StopCycle
GlobalPList、LocalPListに適用されるときにIntrinsic。
子によって継承されない。
これは、EnableCompare_StopPatternを伴わなければならない。パターン比較が終了することになるパターン内のアドレスまたはサイクルを指示する。
１７．Skip
PList、Patに適用されるときにReferential。
子によって継承されない。
パターンリストによって支配されるパターンまたはサブシーケンス全体がスキップされるようにする。これは、このパターンリスト副木のルートにおいて全てのオプションもスキップさせるであろう。それは、このパターン副木が実行するために存在しなかったかのようにする。

［パターンリストバースト制御］
先に説明されたように、或るパターンリストのための実行シーケンスがハードウエアに提示されるとき、ハードウエアは、ソフトウエアが関与することなく、パターンのシーケンスのバーストを生成する。バースト不連続部は、先行するバーストが終了し、新たなバーストが開始される、実行シーケンス内の場所である。上記のオプションリストに示されるように、PreBurst、PostBurst、BurstOffおよびBurstOffDeepオプションは、バースト不連続部が生じる場所を制御する。PreBurstおよびPostBurstオプションは、以下に記述されるある特定の付加的な規則に対するバースト不連続部サブジェクトを決定する。
１．親リストがPreBurstおよびPostBurstオプションを有し、ネストされたリストが同じ対応するオプションを有するとき、バースト不連続部は存在せず、ネストされたリストのPreBurstおよびPostBurstオプションは当てはまらない。親リストのPreBurstおよびPostBurstを適用するただ１つのバーストだけが存在する。
２．ネストされたリストがバーストオプションを持たないとき、それは、これらのオプションの記述によって親リストと同じPreBurstおよびPostBurstオプションを有することと同じであることに留意されたい。結果として、バーストオプションを持たないネストされたリストはバースト不連続部を生じない。
３．上記の規則１が当てはまらず、かつ親リストの開始からネストされたリストの開始までパターン実行シーケンスへの寄与がある場合には、ネストされたリストの開始時にバースト不連続部が存在する。この場合、親リストのPreBurstおよびPostBurstは、親リストからのパターン実行シーケンスへのこの寄与に当てはまる。ネストされたリストのPreBurstおよびPostBurstは、ネストされたリストに当てはまる。
４．上記の規則１が当てはまらず、かつネストされたリストの終了から親リストの終了までのパターン実行シーケンスへの寄与がある場合には、ネストされたリストの終了時にバースト不連続部が存在する。この場合、親リストのPreBurstおよびPostBurstは、親リストからのパターン実行シーケンスへのこの寄与に当てはまる。ネストされたリストのPreBurstおよびPostBurstは、ネストされたリストに当てはまる。
５．上記の規則１が当てはまらず、かつネストされたリストから以外の親リストからのパターン実行シーケンスへの寄与がない場合には、親リストのPreBurstおよびPostBurstは当てはまらない。ネストされたリストのPreBurstおよびPostBurstを適用するただ１つのバーストだけが存在する。

以下は、実行シーケンスへのオプションの影響を示す数例である。簡略化するために、全てのパターンリストがただ１つのファイルにおいて指定されるものと仮定する。

［例１：BurstOffの使用］
この例はBurstOffおよびPreBurstを例示する。特に強調されるのは、BurstOffによって、複数のパターンが、１パターン長である複数のバースト内で１つずつ実行されることである。それゆえ、PreBurstオプションは依然として当てはまる。入力パターンリストは以下のとおりである。

Global A [BurstOff] [PreBurst pat_z]
{
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;
};

Ａをルートとする木は図８に表されるであろう。

このパターンのための実行シーケンスが以下に示される。｜文字はバーストブレークを示す。このパターンリストは１０バーストにおいて実行され、第１のバーストはパターンｚおよびｑを有し、最後のバーストはパターンｅを有する。
ｚｑ｜ａｂ｜ｚｒ｜ｚｓ｜ｔ｜ｃ｜ｄ｜ｃ｜ｄ｜ｅ

この実行シーケンスについて以下のことに留意されたい。
１．Ａ上のBurstOffオプションはＢによって継承されないので、Ｂ内のパターンａおよびｂはバーストとして動作する。
２．Ａ上のPreBurstオプションはＢによって継承されないので、Ｂによるバースト内のａおよびｂはｚによって前置されない。
３．ｚによる前置は、ａの直接の子であることに起因して実行されるパターン、すなわちパターンｑ、ｒおよびｓの場合にのみ起こる。これらのパターンは、BurstOffオプションを有するＡに起因して１パターン長だけであるバースト内にあるかのように１つずつ実行される。BurstOffは、パターンに、１パターン長バーストにおいて個別に実行されることを要求する。それゆえ、PreBurstおよびPostBurstオプションは依然として当てはまる。
４．パターンリストＤは、その子ｃおよびｄが１つずつ実行される固有バーストオフオプションを有する。それは、ＡからのPreBurst zを継承しない。

［例２：BurstOffDeepの使用］
この例はBurstOffBurstOffオプションを例示する。パターンリスト定義中のBurstOffDeepは、ネストされる定義および参照されるリストに影響を及ぼす。しかしながら、PreBurstおよびPostBurstオプションは、ネストされたリストおよび参照されたリストによって継承されない。その例は、例１の場合と同じパターンＡ、Ｂ、Ｃ、Ｄ、Ｅを用いるが、それらのオプションが異なる。
５．Ａの定義上のオプション：［BurstOffDeep］、［PreBurst z］、［PostBurst y］
６．任意の他のノード上の他のオプションはない。

実行シーケンスは以下のとおりである。先に説明されたように、｜文字はバーストブレークを示す。
ｚｑｙ｜ａ｜ｂ｜ｚｒｙ｜ｚｓｙ｜ｔ｜ｃ｜ｄ｜ｃ｜ｄ｜ｅ

この実行シーケンスについて以下のことに留意されたい。
１．PreBurstおよびPostBurstはＢ、Ｃ、Ｄ、Ｅによって継承されない。
２．BurstOffDeepはＢ、Ｃ、Ｄ、Ｅによって継承される。

［例３：PreBurstおよびPostBurst禁止］
ここで、例１のパターンリスト木について考えるものとする。ただし、オプションは以下のとおりである。
１．Ａの定義上のオプション：［PreBurst x］、［PostBurst y］
２．Ｃの定義上のオプション：［PreBurst x］、［PostBurst z］
３．任意の他のノード上の他のオプションはない。

実行シーケンスは以下のようになるであろう。
ｘｑａｂｒｓｔｃｄｃｄｅｙ

「ｔｃｄ」サブシーケンスが「ｘｔｃｄｚ」でない理由は以下のとおりである。
１．最初のｘは、実際には現在のバーストに関連するプレバーストオプションｘに等しいので、禁止される。
２．最後のｚは、PostBurst zがＤに継承されず、ｚが付加されることができるＣから生成されるパターンが存在しないので、禁止される。

［例４：Skipの使用］
この例は、ネストされた定義および参照されるリストへのＳｋｉｐオプションの影響を例示する。その例は、例１の場合と同じパターンＡ、Ｂ、Ｃ、Ｄ、Ｅを用いるが、それらのオプションが異なる。
１．Ａの定義上のオプション：［Skip］、［PreBurst z］、［PostBurst y］
２．ｒへの参照上のオプション：［Skip］
３．Ｃの定義上のオプション：［Skip］

その実行シーケンスは、以下のような、ブレークのない単一のバーストである。
ｚｑａｂｓｃｄｅｙ

この実行シーケンスについて以下のことに留意されたい。
１．ｒおよびＣのためのノードはスキップされる。
２．バーストブレークは全く存在しない。

［例５：Maskの使用］
この例はMaskオプションの影響と、パターンならびにパターンリスト定義および参照へのその影響とを例示する。その例は、例１の場合と同じパターンＡ、Ｂ、Ｃ、Ｄ、Ｅを用いるが、それらのオプションが異なる。
１．Ａの定義上のオプション：［mask pin1_pin2］、［PreBurst z］
２．Ｂの参照上のオプション：［mask pin3］
３．Ｂの定義上のオプション：［mask pin4］
４．ｅの参照上のオプション：［mask pin5］
５．任意のノード上の他のオプションはない。

名前「pin1_pin2」はPin1およびPin2をマスクするグループを指定する。名前「pin3」、「pin4」および「pin5」はそれぞれPin3、Pin4およびPin5をマスクすることを指定する。実行シーケンスが以下に与えられ、｜はバーストブレークを示している。各パターンの下の数字は、そのパターン実行中にマスクされるピンを示す。

ｚｑａｂｚｒｚｓｔｃｄｃｄ｜ｅ
１１１１１１１１１１１１１ １
２２２２２２２２２２２２２ ２
３３ ５
４４

この実行シーケンスについて以下のことに留意されたい。
１．ベンダのハードウエアは、バーストブレークを生じることなく、２つのマスクブロックだけしか収容することができない。ｅが実行されるまで、２つのマスクブロックはピン｛１、２｝およびピン｛１、２、３、４｝である。パターンｅがピン｛１、２、５｝の異なるマスクブロックで到着するとき、ハードウエアはバーストブレークを要求する。

［例６：継承されるオプションおよび参照の使用］
この例は、或る定義において継承されるオプションが、その定義が参照されるときには当てはまらないことを例示する。以下の例について考える。

Global A
{
Global B [BurstOffDeep]
{
Global C
{
...
};
...
};
...

PList C;
};

Global D
{
PList C;
};

BurstOffDeepオプションは、その定義の時点においてＣによって継承される。しかしながら、それは固有オプションではないので、その参照のいずれの時点においてもＣに適用されない。

［例７：ネストされたリストを有するPreBurstおよびPostBurst］
以下の例について考える。

GlobalPList A [PreBurst x] [PostBurst y]
{
Pat p1;
LocalPList B [PreBurst x] [PostBurst y]
{
Pat p2;
}
LocalPList C
{
Pat p3;
}
LocalPList D [PreBurst x] [PostBurst z]
{
Pat p4;
}
LocalPList E [PreBurst w] [PostBurst y] .
{
Pat p5;
}
Pat p6;
}

実行シーケンスは以下のとおりである。
ｘ ｐ１ ｐ２ ｐ３ ｙ｜ｘ ｐ４ ｚ｜ｗ ｐ５ ｙ｜ｘ ｐ６ ｙ

１．ネストされたリストのPreBurstおよびPostBurstオプションは親と同じように指定されるので、パターンｐ２はｐ１と同じバーストの中にある。これらのオプションは親と同じように継承されるので、パターンｐ３も同じバーストの中にある。これらのオプションは、残りのネストされたリスト内に少なくとも１つの異なるメンバを有し、バースト不連続部を生じる。

［タイミング］
ユーザは主に、パターンファイルを用いて試験設定を定義することにより、システムとやりとりする。Timing Fileは、これらのパターンのTimingを記述するために用いられる。このファイルは、分解されるべき基礎的な定義のための他のシステムファイル（たとえば、Pin、SpecSelector）を必要とする。さらに、Timing定義において用いられる種々の変数を分解するために用いられるSpec-SelectorおよびGlobal定義は、複合TestConditionGroupオブジェクトにカプセル化される。Test Planファイルのような、さらに上位のファイルはさらに、このTestConditionGroupインスタンスを使用する。

Test Plan Fileは、TestConditionGroupオブジェクトへの参照を含む。Pattern Source Fileは、TimingMapオブジェクト内のWaveformSelectorコンポーネントを参照する。TimingオブジェクトそのものはＰｉｎオブジェクトを参照する。オプションでは、Timingオブジェクトは、SpecSelectorオブジェクトによって変更される変数も参照する場合がある。これらの関係が図９に示される。

Pattern-List内のPatternオブジェクトは、１組のパターン文字のために用いるためのWaveformSelectorオブジェクトの名前を指定する。Timing Mapファイルがそのパターンにおいて指定されることにも留意されたい。このマップが変更されない場合には、パターンはコンパイルされる必要はない。

Version 1.0;
MainPattern
{
CommonSection
{
...
Timing = myGalxy.tim;
TimingMap = myGalxyMap.tmap;
...
Domain default
{
NOP V {SIG= 1;CLK= 1; DATA=L;} W {SIG=wfs1;
FASTCLK=wfs1;} *
NOP W {SIG=wfs2;}
NOP V {SIG=L;}
NOP V {SIG=0;}
}
}
}

*Here we define the
WaveformSelector
component of the TimingMap
to use for the pattern
characters.

TestConditionGroup Fileオブジェクトは、使用するためのTimingオブジェクトおよび使用するためのTimingMapオブジェクトをインポートする。各Testは、そのインスタンスのためのTestConditionGroupオブジェクトから導出されるTimingConditionインスタンスを使用する。こうして、同じ１組の波形テーブルをサポートする多数のTimingオブジェクトがテスタフレームワーク内に格納されることができ、必要に応じてスワップされることができる。同様に、多数のTest Plan Fileが、共通のTestConditionGroupオブジェクトを共有することができる。

Test Plan記述ファイルの一例が、以下のTimingオブジェクトの使用を例示する。

Import patlist1.plist;
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オブジェクトはピン毎に種々の波形を定義する。TimingファイルおよびTiming Mapファイルにおいて用いられるピンは、Ｐｉｎ定義ファイルにおいて適当に定義される必要がある。

TimingオブジェクトはSpecificationSetオブジェクトを用いて、波形オブジェクト内の値を定義することができる。Timingオブジェクトは種々の属性のためのハードコード化された値を含むことができるが、通常は、ユーザが、変数を用いて種々の属性に値を設定するというのが実情である。これらの変数はさらに、SpecificationSetオブジェクトにも依存することができる。この使用法の一例が以下に示される。

Version 1.0;
Timing basic_functional
{
...
Pin SIG
{
WaveformTable wfs1
{
{ 1 { U@t_le ; D@t_te D; Z@45ns;} } **
};
};
Pin CLK
{
WaveformTable wfs1
{
{ 0 { U@20ns; D@40ns; }};
};
};
}

**This variable, which defines
the edge placement, is
defined elsewhere and is
dependent on a
SpecificationSet.

SpecSelectorは以下に示されるように定義される。

SpecificationSet prodTmgSpec( min, max, typ)
{
t_le = 10ns, 14ns, 12ns;
t_te = 30ns, 34ns, 32ns;
...
}

specを変更することによって用いられるタイミングの変化が以下の例に示される。

TestCondition prodTmp_typ
{
TestConditionGroup = prodTmgSpec;
SpecSelector = typ; *
}

TestConditionGroup prodTmp_max
{
TestConditionGroup = prodTmgSpec;
SpecSelector = max; **
};

*This timing uses the
typical specification in the
SpecSelector.

**This timing uses the
max specification in the
SpecSelector.

［Ｆ２．テスタのタイミングコンポーネントへのマッピング］
テスタモジュールの２つのコンポーネントが、波形の生成およびその関連するタイミングに直に関与する。２つのモジュールは、パターン発生器（ＰＧ）およびフレームプロセッサ（ＦＰ）である。オープンアーキテクチャ試験システムアーキテクチャ内のフレームプロセッサによる波形フォーマッティングおよびタイミング発生を例示する簡略化されたブロック図が図１０に示される。波形の発生の簡単な説明が以下に与えられる。

パターン発生器１００２は、モジュール内の全てのピンに共通であるタイミングセットを生成する。このタイミングセットはGlobal Timing Set(GTS)と呼ばれる。パターン発生器を設定することができる３つのモードがある。これらの３つのモードは、ＧＴＳを記述するために用いることができるビットの数に影響を及ぼす。さらに、これらの設定は、バンクを選択するために用いられるビットの数、およびCapture This Vector(CTV)およびMask This Vector(MTV)がセットされるか否かにも影響を及ぼす。テスタにこのベクトルの結果を収集するように指示するために、ユーザはパターンファイルにおいてＣＴＶフラグを用いる。同様に、テスタに現在のベクトルの結果をマスクするように指示するために、ユーザはそのパターンにおいてＭＴＶフラグを用いる。これが以下の表１に示される。パターン発生器１００２は、Waveform Character(WFC)を生成する責任も担う。ＷＦＣはピン毎に生成される。テスタモジュールは一定のビット数を用いて、ＷＦＣを記述する。

テスタモジュールはピン毎に１つのフレームプロセッサ１００４を設ける。各フレームプロセッサは、Timing Set Scrambler(TSS)１００６を含み、それは、この例では、１０２４までの全深を有する。ＴＳＳ１００６は、先に説明され、図１０に示されるパターン発生器のモードに応じて、多数のバンク１００８に分割されることができる。ここでは、バンク当たり６４エントリの１６バンクが用いられている。ＴＳＳは、ピン毎にWaveform Tableを定義する能力において、より高い自由度を与えることができるように設けられる。「ＦＰ」モードでは、ＴＳＳは、２ビットを用いてTiming Setを出力する。こうして、ＴＳＳは、ピン当たり全部で４つの個別の物理的なTiming Setを生成するであろう。これらのTiming Setは、Local Timing Set(LTS)と呼ばれる。

フレームプロセッサ１００４はＬＴＳおよびＷＦＣを組み合わせて、Waveform Memory１０１２およびTiming Memory１０１４へのインデックス１０１０を作成する。「ＦＰ」モードでは、５ビット値が、ＬＴＳによって生成される２ビットと、ＷＦＣによって生成される３ビットに分割される。こうして、最大４つの物理的なTiming Setを用いることができるが、物理的なWaveform MemoryおよびTiming Memoryの深さはピン当たり３２の深さである。Waveform Memoryは、波形を形成する使用可能なタイミングエッジを含む。使用可能なエッジのためのタイミング値はTiming Memoryから得られる。こうして、フレームプロセッサは波形をフォーマットする。

［マッピング方法］
その方法は、ピン毎の全てのWaveformTableブロックをテスタ内のＬＴＳにマッピングすることである。テスタハードウエアが４ＬＴＳをサポートする場合には、ユーザは最大４つのWaveformTableブロックを定義することができる。各WaveformTableブロックは、テスタデジタルモジュールのために最大ｎ個の波形定義を有することができる。

Timing-Mapファイルは、Timing-Mapブロックにおいて定義されるLogical WaveformSelectorの、オープンアーキテクチャ試験システム内のモジュールのためのWaveformTableへのマッピングを提供する。この場合、テスタは２５６までのLogical WaveformSelectorをサポートする。オープンアーキテクチャ試験システムでは、Logical WaveformSelectorはＧＴＳに直にマッピングする。パターンコンパイラは、Timing-MapおよびTimingブロックの両方に基づいて、パターンファイルをコンパイルすることができる。しかしながら、TimingブロックのWaveformTable内の波形文字が変更されないか、またはTiming-Mapブロック内のWaveformSelectorマッピングが変更されない場合には、そのパターンをコンパイルし直す必要はない。

［このマッピング方法を用いる例］
テスタDigital Moduleへのマッピングを例示するために、以下のことが仮定される。フレームプロセッサはＦＰモードにセットされる。ＣＴＶおよびＭＴＶビットは、ＧＴＳビットの全数が６であり、Timing Bank Selectorビットの総数が４であるようにセットされる。

Timingブロックにおいて定義される各WaveformTableは、Timingファイル内の個別のＬＴＳにマッピングされる。これはピン毎に行われる。こうして、WaveformTable seq1はＬＴＳ１にマッピングされる。「ＳＩＧ」ピンの場合には、全部で８個の取り得る波形エントリを使い果たす。しかしながら、「ＣＬＫ」ピンは、ただ１つの波形エントリを必要とし、それゆえ、Waveformメモリ（ＷＦＴ）およびWaveform Timingメモリ（ＷＴＭ）内のただ１つの行を使い果たす。

「ＳＩＧ」ピンの最初の２つの物理的な波形のマッピングが図１１に示される。このWaveformTableはエッジの個別の構成を必要とする２つの波形文字をマッピングするので、Waveformメモリ（ＷＦＴ）１１１２およびWaveform Timingメモリ（ＷＴＭ）１１１４において２つのエントリを割り当てることにする。波形の形状はＷＦＭに格納され、タイミングの詳細はＷＴＭに格納される。そのモジュールの一実施形態は、Ｔ１、Ｔ２、Ｔ３、Ｔ４、Ｔ５およびＴ６の全部で６個のタイミングエッジを有する。これらは、TimingブロックのEdge Resourceセクション内の波形において定義されるEvent E1、E2、...に直にマッピングする。７個以上のイベントがTimingブロックにおいて定義され、上記のモジュールとともに用いられる場合には、エラーが生じるであろう。

図１１の例では、第１の波形文字「０」はTiming Edge T1を用いて、「Force Down」または「Ｄ」イベントをプログラミングし、それはそのサイクル内の１０ｎｓにおいて生じる。Ｔｉｍｉｎｇ Ｅｄｇｅ Ｔ２も、時刻３０ｎｓにおいて「Force Down」または「Ｄ」イベントを生成するために用いられる。最後に、Timing Edge T3は、時刻４５ｎｓにおいて「Force Off」または「Ｚ」イベントを生成するために用いられる。

第２の波形文字「１」はTiming Edge T1を用いて、「Force Up」または「Ｕ」イベントをプログラミングし、それはそのサイクル内の１０ｎｓにおいて生じる。Timing Edge T2も、時刻３０ｎｓにおいて「Force Down」または「Ｄ」イベントを生成するために用いられる。最後に、Timing Edge T3は、時刻４５ｎｓにおいて「Force Off」または「Ｚ」イベントを生成するために用いられる。

このようにして、ＷＦＣは、フレームプロセッサのＷＦＭメモリおよびＷＴＭメモリにマッピングされる。ピン「ＳＩＧ」のためのＬＴＳ１のWaveform Memory WFMの最後の設定が以下の表２に示される。

ピン「ＳＩＧ」のためのＬＴＳ１のWaveform Timing Memory WTMの最後の設定が以下の表３に示される。

「ＣＬＫ」ピンはただ１つの波形を使い果たすので、このピンのためのＷＦＭおよびＷＦＴは非常に簡単である。「ＣＬＫ」ピンのためのＬＴＳ１のWaveform Memory WFMの最後の設定が以下の表４に示される。

ＬＴＳ２のWaveform Timing Memory WTMの最後の設定が以下の表５に示される。

TimingMapブロックは、WaveformSelectorをTimingブロックのWaveformテーブルに明示的にマッピングする。或るテスタシステムの場合、これは要するに、Timing Set Scrambler(TSS)メモリを設定することになる。ＴＳＳは基本的には、それらの設定を保持する、ＧＴＳからＬＴＳへのマッピングを含む。ピンＳＩＧのための本発明の例のためのＴＳＳ設定は、以下の表６のようになるであろう。

最後に、ＴＳＳおよびＬＴＳ設定マッピングが分解された後に、Pattern Compilerはこの情報を用いて、用いるための正確な波形テーブル（ＬＴＳ）および正確な波形文字を用いてパターンをプログラミングすることができる。こうして、本発明の例による、ピン「ＳＩＧ」だけを考慮した擬似パターンが図１１に示される。このコンパイルはTimingブロックに依存せず、Timing-Mapブロックだけに依存することに留意されたい。

［Ｇ．テスタ動作］
このセクションはテスタオペレーティングシステム（ＴＯＳ）の基本動作を記述する。このセクションにおいて考えられる動作は以下のものである。
・システム初期化
・Test Planローディング
・パターンローディング
・Test Planの実行
・個々のTestの実行

［システム初期化］
一実施形態ではシステムを初期化するために、ある特定の仮定が満たされなければならず、かつある特定の条件が満たされなければならない。以下のサブセクションがこれらを記載する。

［事前条件］
関連するシステムソフトウエアコンポーネントのコピーが中央に格納され、その場所がシステムコントローラに知られている。これは、システムコントローラそのものに存在することができるか、またはネットワーク実装ディレクトリを有する（または別の仕組みを介してＳＹＳＣに知られている）他のシステム上に存在することができ、どのような仕組みであっても、システムが機能することができる前に、システムコントローラが使用するために、全てのソフトウエアが入手できなければならない。このソフトウエアは以下のものを含む。
ベンダハードウエア制御（すなわちモジュールソフトウエア）ＤＬＬ
標準またはユーザ試験クラスＤＬＬ
ユーザ試験計画ＤＬＬ

システムモジュール構成ファイルはシステムコントローラ上で入手することができる。このファイルによって、ユーザがテスタの物理的な構成、たとえばシステムシャーシ内の各モジュールの物理的な場所およびタイプ、ならびにモジュールソフトウエアＤＬＬの名前を指定できるようになることを思い起こされたい。

システム構成ファイルはシステムコントローラ上で入手することができる。このファイルはシステム内のサイトコントローラのリスト、およびサイトコントローラホスト名のSwitch Matrix入力ポートアドレスへのマップを含むことを思い起こされたい。

サイトコントローラは、Site Configuration Manager(SCM)と呼ばれるサービスを実行する。このサービスは、「ハードウエア発見」と呼ばれるプロセスによって、どんなハードウエアが各スロットにインストールされるかを判定する責任を担う。またそれは、システムコントローラでのシステム初期化プロセスに関与する責任も担う。一実施形態では、Switch Matrix動作プロトコルは、Switch Matrix入力ポート接続アドレス１とともに、ただ１つのSite Controller上のSCMを常に用いて、モジュールに対するSwitch Matrix接続を構成すべきであることに留意されたい。この「特別な」サイトはSITEC-1として表されることを思い起こされたい。

システムコントローラは、各サイトコントローラのＳＣＭに、そのSwitch Matrix接続アドレスを提供する責任を担う。

各サイトコントローラのＳＣＭは、Test Plan Server(TPS)と呼ばれるプロセスを開始することができる。各サイトコントローラ上のTest Plan Serverは最終的に、ユーザの１つの試験計画（または、１つのサイトコントローラが多数のＤＵＴ上で試験を実行している場合には、複数の試験計画）を保持し、実行する責任を担う。

［初期化段階Ｉ：システム妥当性検査］
一旦、上記の仮定および事前条件が満たされたなら、システム初期化は最初に、以下のようなシステム妥当性検査ステップを開始する。
１．システムコントローラが、システムおよびモジュール構成ファイルを読み出し、システムのユーザ指定の意図を初期化する。
２．指定されたシステム構成情報を用いて、システムコントローラは、指定されたサイトコントローラが動作中であり、接触可能であり、しかも準備できている（すなわち、ＳＣＭを実行している）ことを確認する。この確認ステップ中にエラーがあれば、システムエラーが引き起こされて、初期化は中止されるであろう。
３．その後、システムコントローラは、ＳＩＴＥＣ−１にあるＳＣＭサービスに、スイッチマトリックスを構成して、全てのハードウエアモジュールにアクセスできるようにすることを指示し、ハードウエア発見を実行するように要求する。
４．ＳＩＴＥＣ−１におけるＳＣＭサービスは、{vendor,hardware}タプルのための全ての利用可能なモジュールスロット（既知のハードウエアの場所）をポーリングし、{vendor,hardware}タプルのスロットへのマッピングを生成する。したがって、終了時に、このポーリングは、完全なシステム内に存在する完全な１組の{vendor,hardware,slot}結合を特定している。このポーリングの結果はシステムコントローラに送られる。
５．システムコントローラは、上記のハードウエア発見ステップの結果が、モジュール構成ファイル内のユーザ指定の構成と一致することを確認する。この確認ステップ中に何らかのエラーがあれば、システムエラーが引き起こされ、初期化は中止されるであろう。
６．その後、システムコントローラは、周知の場所（複数の場合もあり）において環境設定ファイル（複数の場合もあり）からデフォルト環境（モジュールＤＬＬを探すための探索経路、パターンリスト、パターン、試験計画ＤＬＬ、試験クラスＤＬＬなど）をロードする。
７．システムコントローラは、全ての特定されたモジュールソフトウエアＤＬＬが存在することを確実にする。システムコントローラ上で入手できない場合には、可能であるなら、中央記憶装置から検索される。そうでない場合には、システムエラーが引き起こされ、初期化が中止される。

［初期化段階ＩＩ：サイト構成（オプション）］
サイト構成、すなわちサイト分割は、利用可能なシステムハードウエアモジュールを種々のサイトに（すなわち、多数のＤＵＴにサービスするために）ソフトウエアレベルで割り当てることを含む。サイト分割情報はソケットファイルにおいて提供されることを思い起こされたい。

テスタシステムによって、試験計画ロードの一部として（各試験計画は特定のソケットに関連するため）、かつ個別のユーザコール可能なステップとして、サイト（再）分割が実行されるようになる。後者の場合、ユーザは、システムを分割するためにのみ用いられるソケットファイルを提供することにより、サイト分割を開始する。これは、各サイトが異なるＤＵＴタイプを試験するマルチＤＵＴ試験の場合のシステム初期化中に特に有用である。しかしながら、このステップは、初期化段階ではオプションであり、ユーザはそれを実行しないように選択し、代わりに、試験計画ロードがシステムを適当に分割できるようにすることを選択することができる。

サイト分割を達成するためにどの手段が選択されるにしても（個別のコールによるか、または試験計画ロードを通して暗黙的に）、その仕組みは同じである。この仕組みが以下に記載される。
１．ソケットが与えられるとき、システムコントローラは最初に、現時点で存在しているシステム分割がソケットに適合するか否か、または再分割が必要であるか否かを判定する。初期化中のデフォルト分割は、全ての利用可能なモジュールがＳＩＴＥＣ−１に接続される分割である。以下の残りのステップは、再分割が必要とされる場合のみ実行される。
２．システムコントローラは各サイトコントローラＳＣＭに構成メッセージを送り、新たなソケットの下でそのために使用可能にされるＤＵＴサイトの数および識別でそのものを再構成する。これは一般的な手順であり、１つのサイトコントローラによって制御されるＤＵＴサイトの数が１つである場合を取り扱うことに留意されたい。新たなソケット情報はＳＣＭにも伝達される。
３．各ＳＣＭは、もしあれば、実行中のＴＰＳを停止して、新たなＴＰＳを開始し、新たなソケットと、新たなソケットの下でそのために使用可能にされるＤＵＴサイトの数および識別とを用いてそれを初期化する。
４．システムコントローラは、どのサイトが、必要とされるシステムモジュールのどのサブセットを必要とするかを判定する。これを行いながら、システムコントローラはサイトのためのハードウエアスロット情報も準備する。サイト毎の最終的な結果は、そのサイトに割り当てられるモジュールＤＬＬに対するスロットのリストである。このサイト特有のリストは、Site Module DLL Slot List（SITE-MDSL）として表されるであろう。
５．システムコントローラは適当なSITE-MDSL、および必要なモジュールＤＬＬを各ＳＣＭに提供する。各ＳＣＭはさらに、新たに開始されたＴＰＳがこの情報を入手できるようにする。
６．その後、システムコントローラは、適当なサイト‐スロット間接続のために、すなわち、サイト分割作業のために、SITEC-1にSwitch Matrixを構成するように要求する。
７．サイト１〜ｎ上のＴＰＳは、そのSITE-MDSLにおいて指定されるＤＬＬをロードする。これらの各ＤＬＬは、initialize()という名前の関数を有し、その関数はスロット番号のアレイを取得する。ＴＰＳは、そのモジュールタイプのための適当なスロットリストでinitialize()をコールする。この時点で誤動作があれば、システムエラーが引き起こされて、初期化が中止される。initialize()メソッドは以下のことを行う。
ａ．標準インターフェースIXXXModuleに基づいて具体的なクラスを作成する。たとえば、或るデジタルモジュールに関連するＤＬＬは、それが関連する各スロットにサービスするために、１つのIPinModuleベースオブジェクトを作成するであろう。
ｂ．インターフェースIResourceに基づいて、そのモジュール内の「資源ユニット」毎に１つの複数の具体的なクラスを作成する。再び、或るデジタルモジュールの場合、各IPinModuleベースオブジェクトは、デジタルモジュールによって占有されるスロットのコレクション内の全てのピンのためのITesterPinベースオブジェクトを作成するであろう。
８．その後、サイト１〜ｎ上のＴＰＳは、ロードされた各モジュールＤＬＬにおいてgetXXXModule()をコールし、モジュール内容情報を検索する。
９．getXXXModule()へのコールの度に、IModuleポインタとして<VendorHWType>Moduleクラスオブジェクトが返される（たとえば、AdvantestPinModule）。そのような各IModuleポインタはＴＰＳによってキャッシュされ、ＴＰＳは、フレームワーク／ユーザコードがこれらを入手できるようにする。IModule、IResourceなどのコレクションは永続的である（少なくともＴＰＳの寿命にわたって）ことに留意されたい。
１０．一旦、上記のステップが完了したなら、ＴＰＳは、その割り当てられた（既知の）ポートにおいて、listen()を開始する。これは、ＴＰＳが標準（すなわちサイト分割された）動作を開始する「準備ができている」ことを、システムコントローラに伝える。

［試験計画ロード］
このセクションは、ユーザTest Plan DLLがサイトコントローラ上にロードされる（１つまたは複数のＤＵＴ試験のために）ステップを記述する。

一旦、システム初期化（およびオプションで初期サイト分割）が完了したなら、ユーザ試験計画をロードすることができる。ユーザ試験計画のサイトコントローラ上へのローディングは、以下のように進められる。
１．システムコントローラは最初に、試験計画ＤＬＬをその自らの処理空間内にロードし、それに、関連するソケットファイルおよびＤＵＴタイプ識別子を問い合わせる。この情報を用いて、この試験計画を実行するサイト（複数の場合もあり）、それゆえこの試験計画がロードされることになるサイトコントローラ（複数の場合もあり）が特定される。
２．その後、システムコントローラは、その試験計画に関連するソケット情報を用いて、先に略述されたような再分割プロセスを開始する。
３．システムコントローラは、試験計画ＤＬＬから、試験計画によって用いられる試験クラスＤＬＬのリストを抽出し、一旦、システムコントローラが、ＴＰＳが標準（すなわち、サイト分割された）動作を開始する準備ができていることを確認したなら、試験クラスＤＬＬを、そして最後に、試験Plan DLLそのものを適当なＴＰＳに送出する。
４．ＴＰＳはLoadLibrary()をコールして、それを処理空間にロードする。それは、ＤＬＬにおいて周知の関数をコールして、それがサービスするサイト（すなわちＤＵＴ）の数と同じ数の試験計画オブジェクトを作成する。
５．ＴＰＳは、必要なテスタフレームワークオブジェクトで試験計画オブジェクト（複数の場合もあり）を初期化する。初期化中に、ＴＰＳは、試験計画オブジェクト（複数の場合もあり）によって用いられる試験クラスに適したＤＬＬを処理空間にロードし、試験クラスインスタンスを作成する。
６．ＴＰＳはシステムコントローラに対する通信チャネルを試験計画オブジェクト（複数の場合もあり）に設定する。
７．システムコントローラはＴＰＳと通信し、試験計画オブジェクト（複数の場合もあり）のためのプロキシを構築する。

その結果として、サイトコントローラ上のユーザの試験計画のロードに成功する。

［試験計画の実行］
予め定義されたフローロジックにしたがって試験計画内の全ての試験を実行するための方法は以下のとおりである。
１．ユーザのアプリケーションがRunTestPlanメッセージをＴＰＳに送信する。ＴＰＳはExecutingTestPlanメッセージを全ての接続されたアプリケーションに送る。その後、ＴＰＳはTest Plan上でexecute()をコールする。
２．１つのサイトコントローラで多数のＤＵＴを試験することは、そのサイトコントローラ上で、ＤＵＴ当たり１つの多数のスレッドを用いて実行される。各スレッドは、同じ試験計画オブジェクトの異なる個別のインスタンスを実行する。この場合には、モジュール制御ソフトウエアＤＬＬを複数のＤＵＴにわたって共有することができるので、ＤＵＴ識別子パラメータを取得するために、ハードウエア通信のためのモジュールコマンドが必要とされる。
３．試験計画オブジェクトは、そのコレクション内の各試験にわたって繰り返され（別法では、そのＦｌｏｗオブジェクトに、フローロジックにしたがって各試験を処理するように指示し）、preExec()、execute()およびpostExec()をコールする。
４．各試験が実行されるとき、全ての接続されるアプリケーションに対してステータスメッセージが返送される。

［単一の試験の実行］
ユーザは、全ての試験ではなく、１つの試験計画内のただ１つの試験を実行したい場合もある。ただ１つの試験を実行する場合、その方法は以下のとおりである。
１．ユーザアプリケーションがRunTestメッセージをＴＰＳに送信する。ＴＰＳはExecutingTestメッセージを全ての接続されるアプリケーションに送る。その後、ＴＰＳは、Test PlanにおいてexecuteTest()をコールし、実行するための試験を指定する。
２．Test Planオブジェクトは、その試験オブジェクトにおいてpreExec()、execute()およびpostExec()をコールすることにより、指定された試験を実行する。
３．その試験が実行されるとき、それは全ての接続されるアプリケーションにステータスメッセージを返送する。

本発明が特定の実施形態とともに説明されてきたが、本発明の精神および範囲から逸脱することなく、当業者によって種々の変更形態および代替形態が実施できることは理解されたい。本発明は上記の例示的な詳細によって制限されるべきでなく、特許請求の範囲にしたがって解釈されるべきである。

従来のテスタアーキテクチャを示す図である。 本発明の一実施形態による、テスタアーキテクチャを示す図である。 本発明の一実施形態による、テスタソフトウエアアーキテクチャを示す図である。 本発明の一実施形態による、試験プログラムコンパイラを示す図である。 本発明の一実施形態による、単一の試験クラスから種々の試験インスタンスを如何に導出することができるかを示す図である。 本発明の一実施形態による、パターンコンパイラを示す図である。 本発明の一実施形態による、順序パターン木の例を示す図である。 本発明の一実施形態による、別の順序パターン木の例を示す図である。 本発明の一実施形態による、試験プログラムによって必要とされるファイル間の関係を示す図である。 本発明の一実施形態による、波形発生を示す図である。 本発明の一実施形態による、タイミングのために用いられるマッピングを示す図である。 本発明の一実施形態による、タイミングのために用いられる別のマッピングを示す図である。 本発明の一実施形態による、モジュール式試験システムにおいてパターンオブジェクトファイルを管理するためのＯＦＭフレームワークを示す図である。 パターンオブジェクトメタファイルとそのサポート用クラスとの間のインタラクションを示す図である。

Claims (26)

1. モジュール式試験システム内のパターンオブジェクトファイルを管理するための方法であって、
   モジュール式試験システムを配設することであって、該モジュール式試験システムは少なくとも１つのサイトコントローラを制御するためのシステムコントローラを備え、該少なくとも１つのサイトコントローラは少なくとも１つの試験モジュールおよびその対応する被試験デバイス（ＤＵＴ）を制御する、モジュール式試験システムを配設すること、
   複数のベンダ供給パターンコンパイラと前記モジュール式試験システムとの間に標準インターフェースを確立するためのオブジェクトファイル管理（ＯＦＭ）フレームワークを作成すること、
   複数のタイプのパターンブロックを含むパターンソースファイルを受信すること、
   各ベンダ供給パターンコンパイラから得られた情報から共通のタイプのパターンブロックを決定することであって、前記共通のタイプのパターンブロックは全てのベンダ供給パターンコンパイラにより利用することができること、
   前記ＯＦＭフレームワークを用いて、前記パターンソースファイルに基づいてパターンオブジェクトメタファイルを作成することであって、前記共通のタイプのパターンブロックを、複数の同じインスタンスを許容しないように共通セクションに集約することを含む、パターンオブジェクトメタファイルを作成すること、及び
   前記パターンオブジェクトメタファイルを用いて前記試験モジュールを通して前記ＤＵＴを試験すること
   を含む、モジュール式試験システム内のパターンオブジェクトファイルを管理するための方法。
2. 前記ＯＦＭフレームワークは、ベンダ供給パターンデータを前記モジュール式試験システムに組み込むことをサポートするための標準インターフェースクラスを提供する、請求項１に記載の方法。
3. 前記ＯＦＭフレームワークはさらに、モジュール特有のパターンデータを種々のベンダから前記パターンオブジェクトメタファイルに転送するように構成される、請求項１に記載の方法。
4. 前記ＯＦＭフレームワークを作成することは、
   前記ベンダ供給パターンコンパイラと前記試験モジュールを接続するためのベンダパターンコンパイラクラスを作成すること、
   パターンオブジェクトメタファイルクラスにアクセスするためのＯＦＭモジュールエージェントクラスを作成することであって、該パターンオブジェクトメタファイルクラスは、コンパイルされる前記パターンオブジェクトメタファイルをカプセル化する、ＯＦＭモジュールエージェントクラスを作成すること、及び
   パターンコンパイル中に用いられる他の補助パターンオブジェクトメタファイルの特定の部分にアクセスするためのＯＦＭラベルリーダクラスを作成すること
   を含む、請求項１に記載の方法。
5. 前記ベンダパターンコンパイラクラスを作成することは、
   前記パターンソースファイルのパターンコンパイルをサポートすること、
   前記パターンオブジェクトメタファイルのモジュール特有のセクションを更新すること、
   前記パターンオブジェクトメタファイルの前記共通セクションを更新すること、及び
   コンパイルエラーを一纏めにすること
   を含む、請求項４に記載の方法。
6. 前記ＯＦＭモジュールエージェントクラスを作成することは、
   前記共通セクションからの前記ベンダ供給パターンコンパイラの読出し動作をサポートすること、
   ベンダ特有のセクションからの前記ベンダ供給パターンコンパイラの読出し動作をサポートすること、及び
   前記ベンダ供給パターンコンパイラから前記パターンオブジェクトメタファイルのモジュール特有のセクションへの書込み動作をサポートすること
   を含む、請求項４に記載の方法。
7. 前記ＯＦＭラベルリーダクラスを作成することは、
   補助パターンオブジェクトメタファイルのラベルにアクセスすること、及び
   前記補助パターンオブジェクトメタファイルのラベルオフセットにアクセスすること
   を含む、請求項４に記載の方法。
8. 前記パターンオブジェクトメタファイルは、
   前記パターンソースファイル内の非サイクルベースのパターンブロックを表すための１つまたは複数のパターンブロックと、
   前記パターンソースファイル内のサイクルベースのパターンブロックを表すための多くても１つのサイクライズパターンブロックと
   を含む、請求項１に記載の方法。
9. 前記パターンオブジェクトメタファイルを作成することは、
   パターンのコンパイルを制御するためにＯＦＭマネージャを初期化すること、
   各ベンダモジュールが前記パターンオブジェクトメタファイルによって利用されるべくベンダパターンコンパイラインターフェースオブジェクトをインスタンス化することであって、該ベンダパターンコンパイラインターフェースオブジェクトは多数のタイプのパターンブロックをサポートする、インスタンス化すること、
   ベンダパターンコンパイラインターフェースオブジェクトに従って前記試験モジュールによってサポートされるシステム資源のリストを獲得すること、
   パターンコンパイラを用いて前記パターンソースファイル内の１以上の共通のタイプのパターンブロックを含む資源タイプのリストをコンパイルすることであって、それによって、共通セクションデータを生成する、コンパイルすること、
   パターンオブジェクトメタファイルクラスとして共通セクションデータを格納することであって、該共通セクションデータは、前記ベンダ供給パターンコンパイラがアクセスできる情報をパターンオブジェクトメタファイルに含む、共通セクションデータを格納すること、
   並びに
   コンパイルエラーおよび警告のリストを生成すること
   を含む、請求項１に記載の方法。
10. 前記パターンコンパイラは、
    少なくとも１つのモジュール特有のパターンコンパイラと、
    各モジュール特有のコンパイラに対し、前記対応するパターンソースファイルのモジュール特有のセクションおよび共通セクションの両方をコンパイルするように指示するためのオブジェクトファイルマネージャとを含む、請求項９に記載の方法。
11. 前記ベンダパターンコンパイラインターフェースオブジェクトはサイクルベースパターンコンパイラインターフェースオブジェクトを含む、請求項９に記載の方法。
12. 前記ベンダパターンコンパイラインターフェースオブジェクトは非サイクルベースパターンコンパイラインターフェースオブジェクトを含む、請求項９に記載の方法。
13. 前記多数のタイプのパターンブロックは、サイクルベースパターンおよび非サイクルベースパターンからなるグループから選択される１つまたは複数の項目を含む、請求項９に記載の方法。
14. モジュール式試験システムであって、
    システムコントローラと、
    前記システムコントローラに接続される少なくとも１つのサイトコントローラと、
    少なくとも１つの試験モジュールおよびその対応する被試験デバイス（ＤＵＴ）であって、該試験モジュールは前記サイトコントローラによって制御される、少なくとも１つの試験モジュールおよびその対応する被試験デバイスと、
    複数のベンダ供給パターンコンパイラと該モジュール式試験システムとの間に標準インターフェースを確立するためのオブジェクトファイル管理（ＯＦＭ）フレームワークと、
    複数のタイプのパターンブロックを含むパターンソースファイルを受信するための手段と、
    各ベンダ供給パターンコンパイラから得られた情報から共通のタイプのパターンブロックを決定する手段であって、前記共通のタイプのパターンブロックは全てのベンダ供給パターンコンパイラにより利用することができる手段、
    前記ＯＦＭフレームワークを用いて、前記パターンソースファイルに基づいてパターンオブジェクトメタファイルを作成するための手段であって、前記共通のタイプのパターンブロックを、複数の同じインスタンスを許容しないように共通セクションに集約することを含む、パターンオブジェクトメタファイルを作成する手段、と、
    前記パターンオブジェクトメタファイルを用いて、前記試験モジュールを通して前記ＤＵＴを試験するための手段と
    を備える、モジュール式試験システム。
15. 前記ＯＦＭフレームワークは、ベンダ供給パターンデータを前記モジュール式試験システムに組み込むことをサポートするための標準インターフェースクラスを提供する、請求項１４に記載のシステム。
16. 前記ＯＦＭフレームワークは、モジュール特有のパターンデータを種々のベンダから前記パターンオブジェクトメタファイルに転送するように構成される、請求項１４に記載のシステム。
17. 前記ＯＦＭフレームワークは、
    前記ベンダ供給パターンコンパイラと前記試験モジュールを接続するためのベンダパターンコンパイラクラスを作成するための手段と、
    パターンオブジェクトメタファイルクラスにアクセスするためのＯＦＭモジュールエージェントクラスを作成するための手段であって、該パターンオブジェクトメタファイルクラスは、コンパイルされる前記パターンオブジェクトメタファイルをカプセル化する、作成するための手段と、
    パターンコンパイル中に用いられる他の補助パターンオブジェクトメタファイルの特定の部分にアクセスするためのＯＦＭラベルリーダクラスを作成するための手段と
    をさらに備える、請求項１４に記載のシステム。
18. 前記ベンダパターンコンパイラクラスを作成するための前記手段は、
    前記パターンソースファイルのパターンコンパイルをサポートするための手段と、
    前記パターンオブジェクトメタファイルのモジュール特有のセクションを更新するための手段と、
    前記パターンオブジェクトメタファイルの前記共通セクションを更新するための手段と、
    コンパイルエラーを一纏めにするための手段と
    を備える、請求項１７に記載のシステム。
19. 前記ＯＦＭモジュールエージェントクラスを作成するための前記手段は、
    前記共通セクションからの前記ベンダ供給パターンコンパイラの読出し動作をサポートするための手段と、
    モジュール特有のセクションからの前記ベンダ供給パターンコンパイラの読出し動作をサポートするための手段と、
    前記ベンダ供給パターンコンパイラから前記パターンオブジェクトメタファイルの前記モジュール特有のセクションへの書込み動作をサポートするための手段と
    を備える、請求項１７に記載のシステム。
20. 前記ＯＦＭラベルリーダクラスを作成するための前記手段は、
    補助パターンオブジェクトメタファイルのラベルにアクセスするための手段と、
    前記補助パターンオブジェクトメタファイルのラベルオフセットにアクセスするための手段と
    を備える、請求項１７に記載のシステム。
21. 前記パターンオブジェクトメタファイルは、
    前記パターンソースファイル内の非サイクルベースパターンブロックを表すための１つまたは複数のパターンブロックと、
    前記パターンソースファイル内のサイクルベースパターンブロックを表すための多くても１つのサイクライズパターンブロックと
    を含む、請求項１４に記載のシステム。
22. 前記パターンオブジェクトメタファイルを作成するための前記手段は、
    パターンのコンパイルを制御するためにＯＦＭマネージャを初期化するための手段と、
    各ベンダモジュールが前記パターンオブジェクトメタファイルによって利用されるべくベンダパターンコンパイラインターフェースオブジェクトをインスタンス化するための手段であって、該ベンダパターンコンパイラインターフェースオブジェクトは多数のタイプのパターンブロックをサポートする、インスタンス化するための手段と、
    ベンダパターンコンパイラインターフェースオブジェクトに従って前記試験モジュールによってサポートされるシステム資源のリストを獲得するための手段と、
    パターンコンパイラを用いて前記パターンソースファイル内の１以上の共通のタイプのパターンブロックを含む資源タイプのリストをコンパイルするための手段であって、それによって、共通セクションデータを生成する、コンパイルするための手段と、
    パターンオブジェクトメタファイルクラスとして共通セクションデータを格納する手段であって、該共通セクションデータは、前記ベンダ供給パターンコンパイラがアクセスできる情報をパターンオブジェクトメタファイルに含む、格納する手段と、 コンパイルエラーおよび警告のリストを生成するための手段と
    を備える、請求項１４に記載のシステム。
23. 前記パターンコンパイラは、
    少なくとも１つのモジュール特有のパターンコンパイラと、
    各モジュール特有のコンパイラに対し、前記対応するパターンソースファイルのモジュール特有のセクションおよび共通セクションの両方をコンパイルするように指示するためのオブジェクトファイルマネージャと
    を備える、請求項２２に記載のシステム。
24. 前記ベンダパターンコンパイラインターフェースオブジェクトはサイクルベースパターンコンパイラインターフェースオブジェクトを含む、請求項２２に記載のシステム。
25. 前記ベンダパターンコンパイラインターフェースオブジェクトは非サイクルベースパターンコンパイラインターフェースオブジェクトを含む、請求項２２に記載のシステム。
26. 前記多数のタイプのパターンブロックは、サイクルベースパターンおよび非サイクルベースパターンからなるグループから選択される１つまたは複数の項目を含む、請求項２２に記載のシステム。

Images