JP4608516B2 - モジュール式試験システムに試験モジュールを統合する方法およびモジュール式試験システム - Google Patents

Description

本発明は、自動試験装置（ＡＴＥ）の分野に関する。特に、本発明は、オープンアーキテクチャ試験システムにおいて較正及び／又は診断をサポートする方法及びシステムに関する。

本出願は、参照により本出願に援用される、株式会社アドバンテスト（Advantest Corporation）によって２００４年５月２２日に出願された、「Software Development in an Open Architecture Test System」と題する米国特許出願第６０／５７３，５７７号の利益を主張する。

システム・オン・チップ（System-on-a-Chip）（ＳＯＣ）デバイスの複雑性が増大することと、同時にチップ試験のコストの低減に対する要求が高まることにより、集積回路（ＩＣ）の製造業者とテスタのベンダとはともに、ＩＣ試験をいかに実行すべきかを再考せざるを得なくなった。企業調査によれば、設計し直さない限り、テスタの予測されるコストは、近い将来劇的に上昇し続ける。

試験装置のコストが高い主な理由は、従来のテスタアーキテクチャが特殊化した性質を有するということである。各テスタ製造業者は、アドバンテスト、テラダイン（Teradyne）及びアジレント（Agilent）等の会社間で互換性がないだけでなく、アドバンテストが製造するＴ３３００、Ｔ５５００及びＴ６６００シリーズのテスタ等、一会社内のプラットフォーム間でも互換性がない多数のテスタプラットフォームを有する。これら非互換性のために、各テスタは、それ自体の特殊なハードウェアコンポーネント及びソフトウェアコンポーネントを必要とし、これら特殊なハードウェアコンポーネント及びソフトウェアコンポーネントを他のテスタで使用することができない。さらに、試験プログラムを１つのテスタから別のテスタに移植するべく、且つサードパーティソリューションを開発するために著しい労力が必要である。或るプラットフォームに対してサードパーティソリューションが開発される場合であっても、それを異なるプラットフォームに移植し又はそこで再使用することはできない。１つのプラットフォームから別のプラットフォームへの移行プロセスは、一般に複雑で且つ誤りが発生しやすく、その結果、労力及び時間が追加され試験コストが増大する。

このような特殊化したテスタアーキテクチャでは、オペレーティングシステム及び試験分析ツール／アプリケーション等のテスタソフトウェアは、ホストコンピュータ上で実行する。アーキテクチャの専用の性質のために、所与のテスタに対し、すべてのハードウェア及びソフトウェアは固定の構成であり続ける。ハードウェアデバイス又はＩＣを試験するために、試験データ、信号、波形、並びに電流及び電圧レベルを定義するとともに、被試験デバイス（ＤＵＴ）応答を収集し且つＤＵＴ合格／不合格を確定するテスタの能力の一部又はすべてを使用する専用試験プログラムが開発されている。

多種多様のＤＵＴを試験するためには、広範囲の機能及び動作を行うテスタシステムのハードウェアコンポーネント及びソフトウェアコンポーネントが必要である。試験中、広範囲の機能をサポートするために、ベンダ提供試験モジュールの種々のセットが利用される場合もあり、試験システムは、ベンダ提供試験モジュールとそれらの対応する較正及び／又は診断データとをプラグ・アンド・プレイ方式でサポートするように設定される必要がある。新たなベンダ提供試験モジュールが利用される時、その新たな試験モジュールの較正及び／又は診断が必要となる場合がある。さらに、試験モジュールの性能が、所定期間にわたって元の較正された範囲外に変動する可能性があり、試験モジュールは、試験システムによって再較正又は再診断される必要のある場合がある。

このため、試験要件に基づいて異なる試験モジュールで構成することができるオープンアーキテクチャ試験システムが必要とされている。特に、ランタイム中にプラグ・アンド・プレイ方式でベンダ提供較正及び／又は診断（Ｃ＆Ｄ）情報を使用するように構成することができるオープンアーキテクチャ試験システムが必要とされている。

本発明の一実施形態のオープンアーキテクチャ試験システムにより、サードパーティ試験モジュールを統合することができる。試験システムのハードウェアフレームワーク及びソフトウェアフレームワークは、異なるベンダからのモジュールがプラグ・アンド・プレイ方式で対話することができる標準インタフェースを含む。

１つの実施の形態では、モジュール式試験システムに試験モジュールを統合する方法は、ベンダ提供試験モジュールを統合するコンポーネントカテゴリを作成すること、及び、ベンダ提供試験モジュールとモジュール式試験システムとの間の標準インタフェースを確立する較正及び診断（Ｃ＆Ｄ）フレームワークを作成することであって、Ｃ＆Ｄフレームワークは、ベンダ提供モジュール統合情報を通信するインタフェースクラスを含む、Ｃ＆Ｄフレームワークを作成することを含む。この方法は、ベンダ提供試験モジュールを受け取ること、コンポーネントカテゴリに従ってベンダ提供試験モジュールからモジュール統合情報を取り出すこと、及び、Ｃ＆Ｄフレームワークを使用してモジュール統合情報に基づきベンダ提供試験モジュールをモジュール式試験システムに統合することをさらに含む。

別の実施の形態では、モジュール式試験システムはシステムコントローラと、システムコントローラに結合される少なくとも１つのサイトコントローラと、少なくとも１つのベンダ提供試験モジュール及びその対応する被試験デバイス（ＤＵＴ）と、ベンダ提供試験モジュールを統合するコンポーネントカテゴリと、ベンダ提供試験モジュールとモジュール式試験システムとの間に標準インタフェースを確立する較正及び診断（Ｃ＆Ｄ）フレームワークであって、ベンダ提供モジュール統合情報を通信するインタフェースクラスを含む、Ｃ＆Ｄフレームワークとを具備する。モジュール式試験システムは、ベンダ提供試験モジュールを受け取る手段と、コンポーネントカテゴリに従ってベンダ提供試験モジュールからモジュール統合情報を取り出す手段と、Ｃ＆Ｄフレームワークを使用してモジュール統合情報に基づいてベンダ提供試験モジュールをモジュール式試験システムに統合する手段とをさらに具備する。

以下、本発明の上述した特徴及び利点とともにその追加の特徴及び利点について、以下の図面をともに考慮した場合に本発明の実施形態の詳細な説明の結果としてより明確に理解されるであろう。

図面を通して同様の番号を使用する。

オープンアーキテクチャ試験システムにおいて較正及び／又は診断をサポートする方法及びシステムを提供する。以下の説明を、当業者が本発明を作成し使用することができるように提示する。特定の技法及び適用の説明は、単に例として提供する。本明細書で説明する例に対するさまざまな変更及び組合せは、当業者には容易に明らかになるであろう。また、本明細書で定義する一般原理を、本発明の精神及び範囲から逸脱することなく他の例及び適用に応用してもよい。このため、本発明は、説明され且つ示される例に限定されるように意図されておらず、本明細書で開示する原理及び特徴に一致する最も広い範囲を付与される。

図１は、本発明の一実施形態によるオープンアーキテクチャ試験システムを示す。システムコントローラ（ＳｙｓＣ）１０２は、複数のサイトコントローラ（ＳｉｔｅＣ）１０４に結合される。システムコントローラを、関連するファイルにアクセスするためにネットワークに結合してもよい。各サイトコントローラは、モジュール接続イネーブラ１０６を通して、試験サイト１１０に位置する１つ又は複数の試験モジュール１０８に結合される。モジュール接続イネーブラ１０６は、接続されたハードウェアモジュール１０８の再構成を可能にし、また、データ転送用のバスとしての役割を果たす（パターンデータをロードする、応答データを収集する、制御を提供する等）。さらに、モジュール接続イネーブラを通して、１つのサイトのモジュールが、別のサイトのモジュールにアクセスすることができる。モジュール接続イネーブラ１０６は、異なる試験サイトが同じか又は異なるモジュール構成を有することができるようにする。言い換えれば、各試験サイトは、異なる数及び異なるタイプのモジュールを採用してもよい。あり得るハードウェアインプリメンテーションには、専用接続、スイッチ接続、バス接続、リング接続及びスター接続が含まれる。モジュール接続イネーブラ１０６を、たとえばスイッチマトリクスによって実施してもよい。各試験サイト１１０は、ＤＵＴ１１２に関連し、ＤＵＴ１１２は、ロードボード１１４を介して対応するサイトのモジュールに接続される。一実施形態では、単一サイトコントローラを複数のＤＵＴサイトに接続してもよい。

システムコントローラ１０２は、全体的なシステムマネージャとしての役割を果たす。システムコントローラ１０２は、サイトコントローラアクティビティを調整し、システムレベルの並列試験戦略を管理し、さらにシステムレベルのデータロギング及びエラー処理サポートとともにハンドラ／プローブ制御を提供する。動作設定に応じて、システムコントローラ１０２を、サイトコントローラ１０４の動作とは別のＣＰＵに配置してもよい。別法として、システムコントローラ１０２とサイトコントローラ１０４とにより共通のＣＰＵを共有してもよい。同様に、各サイトコントローラ１０４を、それ自体の専用ＣＰＵ（中央処理装置）に配置してもよく、又は同じＣＰＵ内の別々のプロセス又はスレッドとして配置してもよい。

個々のシステムコンポーネントを、統合されたモノリシックシステムの論理コンポーネントとみなしてもよく、必ずしも分散システムの物理コンポーネントとしてみなさなくてもよいということを理解して、システムアーキテクチャを、概念的に図１に示す分散システムとして想定してもよい。

本発明のオープンアーキテクチャ試験システムの一実施形態によれば、ハードウェアレベルとソフトウェアレベルとの両方において標準インタフェースを使用することにより、プラグ・アンド・プレイモジュール又は交換可能モジュールが容易になる。テスタオペレーティングシステム（ＴＯＳ）により、ユーザは、テストプランプログラミング言語を使用して、試験システムを特定の被試験デバイス（ＤＵＴ）に特化して動作させるようにテストプランプログラムを書くことができる。また、それにより、テストプランプログラムにおいてライブラリとして一般に使用される試験システム動作のシーケンスのパッケージングも可能となる。これらのライブラリを、テストクラス、テストテンプレート及び他の名称で呼ぶ場合がある。ベンダ提供試験モジュールは、問題を診断する手段とともに測定／応答値の較正を必要とする可能性が高い。ＴＯＳ内の較正及び診断（Ｃ＆Ｄ）フレームワークは、標準インタフェースを使用することにより任意のモジュールに対してこれらの機能を呼び出すことができる必要がある。このように、ＴＯＳの側においていかなるベンダ特定の知識を必要とすることなく、各試験モジュールに対して適当な挙動を呼び出すことができる。この手法により、ＴＯＳ設計が簡略化され、モジュール特定Ｃ＆Ｄモジュールのベンダのインプリメンテーションがカプセル化される。

オープンアーキテクチャ試験システムの実施形態では、フレームワーククラスを使用してモジュールを使用可能にし、起動し、制御し、且つ監視する。フレームワークは、共通の試験関連動作を実施するクラス及びメソッドのセットである。これには、較正及び／又は診断、電源、ピンエレクトロニクスの順番付け、電流／電圧レベルの設定、タイミング条件の設定、測定値の取得、試験フローの制御等のためのクラスが含まれる。フレームワークはまた、ランタイムサービス及びデバッグのための方法を提供する。一手法では、フレームワークオブジェクトを使用して標準インタフェースを実施する。フレームワークオブジェクトの標準インタフェースを実施するために、フレームワーククラスのＣ＋＋ベースのリファレンスインプリメンテーションが提供される。試験システムは、さらに、ユーザ特定フレームワークオブジェクトをサポートする。

オープンアーキテクチャテスタシステムは、システムフレームワークレベルでインタフェースの最小セットを使用する。Ｃ＆Ｄフレームワークは、汎用の且つ普遍的に適用可能なインタフェースを提示するオブジェクトで動作するように設計される。サードパーティモジュールベンダは、その較正及び／又は診断ソフトウェアをシステムに統合する時、システムの、既存のコンポーネントによってサポートされるインタフェースと同じインタフェースをサポートする、新たなコンポーネントを提供する必要がある。本発明の一実施形態のこのような標準インタフェースにより、ベンダ提供モジュールをプラグ・アンド・プレイ方式でシステムにシームレスに統合することができる。

一実施形態では、システムＴＯＳに対する標準インタフェースは、純粋抽象Ｃ＋＋クラスとして定義される。ベンダ提供モジュール特定の較正及び／又は診断クラスは、ランタイムにシステムソフトウェアにより独立して且つ動的に（オンデマンドに）ロードされてもよい、動的リンクライブラリ（ＤＬＬ）等の実行ファイル（executable）の形式で提供される。このようなソフトウェアモジュールは各々、較正及び診断ソフトウェア開発のためのアプリケーションプログラミングインタフェース（ＡＰＩ）を含む、システム較正及び／又は診断インタフェースコマンドに対するベンダ特定インプリメンテーションを提供することに関与する。

較正及び／又は診断を実行するための要件は、異なるタイプのモジュールにわたり、且つ異なるベンダからの同じタイプのモジュールにわたって大きく変化する。Ｃ＆Ｄフレームワークのインタフェースクラスは、このような多種多様の状況に対処するように設計される。較正及び／又は診断モジュール及びルーチンの性質は大きく変化し得るため、ベンダは、標準的な方法でそれらの試験モジュールに関する情報を提供する。このように、実際の較正及び／又は診断ルーチンは、標準を明らかにするモジュール、そのモジュールタイプに特定のインプリメンテーションによって裏づけされる抽象インタフェースに位置する。さらに、ベンダ特定の較正及び／又は診断能力をサポートするために、既知ではない（non-well-known）インタフェースを呼び出す機能がある。
<標準較正及び診断インタフェース>

図２ａは、本発明の一実施形態によるＣ＆Ｄフレームワークを使用してベンダ提供Ｃ＆Ｄデータを統合する方法を示す。図２ａに示すように、統一モデリング言語（ＵＭＬ）クラス図として示すＣ＆Ｄフレームワーク２００は、Ｃ＆Ｄフレームワークが較正及び／又は診断ルーチンセットの内容に関する情報を取得することができるようにするメカニズムを含む、Ｃ＆Ｄベンダ共通情報インタフェース２０２（ICDVendCommonInfo）を含む。ICDVendCommonInfoインタフェース２０２は、複数のルーチン及びコンポーネントモジュールとともに、非標準インタフェースを含むメソッドの名前及び識別子（ＩＤ）を含む。一手法では、ICDVendCommonInfoインタフェースは、以下のメソッドのリストを含む。すなわち、getVendorInfo()、getModuleInfo()、getDLLRev()、getLevelAndCategory()、getGroups()、getThirdPartyAccess()、getSwModules()及びrunSwModules()である。

getVendorInfo()メソッドは、ＤＬＬが対応するハードウェアモジュールのベンダ名を読み出す。このベンダ名ストリングは、そのモジュールＩＤに関連するようなベンダの名称を記述することが意図されている。たとえば、ハードウェアモジュールがアドバンテストのＤＭ２５０ＭＨｚモジュールである場合、ストリングは、「ADVANTEST」のようなものであってもよい。返されるベンダ名は、数字及びアルファベットの文字（「a」〜「z」、「A」〜「Z」、「0」〜「9」）を含む。

getModuleInfo()メソッドは、ＤＬＬが対応するハードウェアモジュールのモジュール名を読み出す。このモジュール名ストリングは、そのモジュールＩＤに関連するようなハードウェアモジュールの名称を記述することが意図されている。たとえば、ハードウェアモジュールがアドバンテストのＤＭ２５０ＭＨｚモジュールである場合、ストリングは、「ＤＭ２５０ＭＨｚ」のようなものであってもよい。返されるモジュール名は、数字及びアルファベットの文字（「a」〜「z」、「A」〜「Z」、「0」〜「9」）を含む。

getDLLRev()メソッドは、このＤＬＬのリビジョンをストリングで読み出す。このインタフェースはまた、インストール中にも使用される。

getLevelandCategory()メソッドは、ベンダモジュールからサポートされるレベル及びカテゴリを読み出す。返されるレベル及びカテゴリに従って、フレームワークは、メソッドgetGroups()を使用して、サポートされるプログラムグループを問い合わせる。

getGroup()メソッドは、指定されたプログラムレベル及びカテゴリに属するプログラムグループを返す。指定されたプログラムレベル及びカテゴリは、メソッドgetLevelAndCategory()を通して返されるものである。

getThirdPartyAccess()メソッドは、較正及び診断モジュール全体に対するサードパーティアクセス（ＴＰＡ）メソッドに関する情報を取得する。これを使用することにより、ベンダモジュールは、較正及び診断ＧＵＩツールに表示されるベンダ特定特性をプラグインしてもよい。ベンダＣ＆Ｄモジュールがこのインタフェースを有する必要がない場合、このメソッドからヌルポインタが返される。

getSwModules()メソッドは、フレームワークに対し詳細な較正又は診断プログラム名を設定する。モジュールが、指定されたレベル及びカテゴリ及びグループに属するプログラムのセットを有する場合、このメソッドのインプリメンテーションは、プログラム情報メソッドを通してフレームワークにプログラム情報のセットを返さなければならない。ＧＵＩツールにおいて、レベル、カテゴリ、グループを使用してプログラムが分類される。プログラム名に対して有効範囲を形成しないため、プログラム識別子（progID）は、特定の較正又は診断ソフトウェアモジュールにおいて一意であってもよい。

runSwModules()メソッドは、モジュールに対し、選択されたプログラムを実行するように要求する。１つの呼出しにおいて１つのプログラムが選択されてもよい。フレームワークは、ＧＵＩツールにおいてユーザが選択するプログラムのシーケンスを有し、関与するモジュールを通してこのメソッドを呼び出す。ユーザは、プログラムを実行するハードウェアエンティティ（一般にはチャネル）を選択してもよい。この情報は、パラメータ環境に通される。各プログラムコードは、選択されたハードウェアエンティティにおいて実行する必要がある。

図２ａのＵＭＬ図はまた、モジュール構成データ２０４、モジュールマネージャ２０６、システム制御Ｃ＆Ｄフレームワーク２０８、サイトコントローラＣ＆Ｄフレームワーク２１０、システムコントローラ２１２、サイトコントローラ２１４及びＣ＆Ｄ ＧＵＩツール２１６も含む。ＵＭＬ図は、さらに、ベンダ較正ＤＬＬオブジェクト２２０から情報を取り出すベンダ較正共通情報オブジェクト２１８と、ベンダ診断ＤＬＬオブジェクト２２４から情報を取り出すベンダ診断共通情報オブジェクト２２２とを含む。

試験システムは、モジュール構成データ２０４によって構成される。モジュールマネージャ２０６は、ベンダ提供ドライバソフトウェア、較正ソフトウェア及び診断ソフトウェアを管理する。Ｃ＆Ｄフレームワークは、モジュールマネージャに保持される較正データに従って、ICDVendCommonInfoインタフェース２０２を介してベンダ較正及び診断プログラム情報を取り出す。各ベンダは、それ自体の特定の方法で、それぞれその較正又は診断機能に対して導出されるベンダ較正共通情報オブジェクト（VendorCalｓ' CommonInfo）２１８又はベンダ診断共通情報オブジェクト（VendorDiag's CommonInfo）２２２を実施してもよい。

Ｃ＆Ｄフレームワークは、ベンダＣ＆Ｄソフトウェア情報を、システムコントローラ２１２で実行しているＣ＆Ｄグラフィカルユーザインタフェース（ＧＵＩ）ツール２１６に渡す。ユーザは、このＣ＆Ｄ ＧＵＩツール２１６を介してＣ＆Ｄシステムを動作させる場合、現システム構成にロードされているベンダＣ＆Ｄソフトウェアすべてから取り出されるＣ＆Ｄプログラムのセットから選択してもよい。システムコントローラのＣ＆Ｄフレームワーク２０８は、選択されたプログラム（複数可）を関与するサイトコントローラ２１４に配布し、その後、サイトコントローラのＣ＆Ｄフレームワーク２１０は、ICDVendCommonInfoインタフェース２０２を使用して適当なベンダＣ＆Ｄモジュールにおいてプログラムを実行する。このように、ICDVendCommonInfoインタフェース２０２を使用することにより、Ｃ＆Ｄフレームワークは、ベンダに対し、ベンダ提供Ｃ＆Ｄモジュールを試験システムに統合する標準インタフェースのセットを提供する。

ICDVendCommonInfoインタフェース２０２に加えて、Ｃ＆Ｄフレームワークは、以下のインタフェースをさらに含む。

□ICDVendFwCtrl
このインタフェースは、ベンダコンポーネントが、ベンダプログラムの実行に必要なＣ＆Ｄフレームワーク環境設定にアクセスするために使用する、フレームワーク支援ユーティリティを提供する。これには、アルゴリズムバージョン、較正データリビジョン設定等が含まれる。

□ICDVendIO
このインタフェースは、ベンダコンポーネントが、Ｃ＆Ｄ ＧＵＩツール、又はシステムコントローラで実行するアプリケーション及びデータロギングサービスを提供するアプリケーションに向けられる標準化メッセージを生成するために使用する、フレームワーク支援ユーティリティを提供する。

□ICDProgress
このインタフェースは、ベンダコンポーネントが、ベンダプログラム実行のステータス（たとえば、「完了率」情報等）を送信するために使用する、フレームワーク支援ユーティリティを提供する。このインタフェースはまた、Ｃ＆Ｄ ＧＵＩツールから呼び出されるＣ＆Ｄ実行フローを停止するため又は実行を休止若しくは再開するためにも使用される。

□ICDVendCalData
このインタフェースは、ベンダコンポーネントが較正データ等のシステムファイルを読み出し且つ書き込むために使用する、フレームワーク支援ユーティリティを提供する。

□ISysDeviceSiteMgr
このシステムデバイスサイトマネージャ（ISysDeviceSiteMgr）インタフェースは、ベンダコンポーネントが、共有システムデバイス又は装置にアクセスするために使用する、フレームワーク支援ユーティリティを提供する。たとえば、これは、ＧＰＩＢバスを介して又はＲＳ−２３２Ｃによって接続されるシステムコントローラ上の装置へのアクセスを提供する。IGPIBDeviceProxy及びIRS232Proxy等のプロキシオブジェクトが提供される。これらは、ベンダモジュールに対し、システムコントローラにインストールされているデバイス又は装置に対するリモートアクセスを与える。図２ｂは、本発明の一実施形態による共有装置にアクセスするために試験システムによって使用される方式を示す。
<ランタイム較正>

ランタイム較正は、システムがテストプランプログラムをロードしているか又は実行している間に、テストクラスから又はＣ＆Ｄフレームワークから呼び出される場合がある較正アクティビティのセットである。一実施形態では、ランタイム較正を実行する方法は、以下を含む。

□ハードウェアモジュールステータスを確かめる
ＴＯＳは、すべてのモジュールが較正されておりＤＵＴを試験する用意ができているか否かを判断する。

□較正データ（先の較正動作中に格納された）をロードする
ＴＯＳは、モジュール特定較正データをロードすることによりモジュールを初期化する。

□時間領域反射（Time Domain Reflection）（ＴＤＲ）及びタイミング較正データ補償
ユーザは、特定のパフォーマンスボード（又はロードボード）で使用されるモジュール特定タイミング較正データを補償してもよい。なお、パフォーマンスボードは特定のＤＵＴタイプに対して設計されているため、システムタイミング較正は、デバイス試験時にユーザが選択する特定のパフォーマンスボードにおけるトレースラインの伝播遅延を考慮しないことに留意する。ラインにおいてテスタモジュールチャネルからＤＵＴピンまで非ゼロ遅延があるため、タイミング較正データは、パフォーマンスボード上のトレースラインの長さを考慮して補償される必要がある。時間領域反射（ＴＤＲ）は、電気的反射を使用してトレースラインの長さを測定するために使用される方法であり、測定されたデータはその後、タイミング較正データを補償するために使用される。また、タイミング較正データが各ベンダ提供モジュールに対して特定であるため、データ補償プロセスはベンダ提供モジュールに対して特定となることにも留意する。
<オンラインタイミング較正データ補償>

ＴＯＳ及びユーザは、試験実行中に発生する状態、パフォーマンスボード効果及び他の要因によって決定される変化に関してモジュール特定タイミング較正データを補償することができる。言い換えれば、タイミング較正データは、試験の実際の状態に従って補償される必要のあることが多い。

一実施形態では、図３ａは、デジタル関数発生器モジュールを示し、それは、そのドライバタイミングを較正することにより、指定されたタイミングが確実にＶｉｈ（高ドライバ電圧）３０４とＶｉｌ（低ドライバ電圧）３０６との５０％点３０２で生成されてよい。

デジタル関数発生器モジュールは、２つのオンライン較正パラメータ、すなわちＶｉｈ３０４及びＶｉｌ３０６を有し、それらは、ドライバ電圧振幅の５０％点を指定するために使用される。基礎タイミング較正データが、事前定義された電圧振幅のセットとともに取得される。たとえば、Ｖｉｈ＝３Ｖ及びＶｉｌ＝０Ｖの場合、Ｖｉｈ及びＶｉｌの５０％点は１．５Ｖである。Ｖｉｈ及びＶｉｈ値を使用して、デバイス試験実行中にドライバタイミングに対しこのタイミング較正データが補償される。図３ｂに示すように、ピン（又はピン群）のドライバが、試験中にＶｉｈ＝１．０Ｖ（３０８）及びＶｉｌ＝０Ｖ（３１０）を有するようにプログラムされる場合、このドライバ振幅の５０％点３１２は０．５Ｖである。オンライン較正を採用することにより、指定されたＶｉｈ及びＶｉｌ値を使用してタイミング較正データをこれらの動作ドライバ電圧に対して適当であるように補償する。

オープンアーキテクチャ試験システムでは、テストプランプログラム言語で使用されるハードウェアリソース表現は、ベンダに依存しない。たとえば、ユーザは、個々のピンが特定のベンダから提供されるピン群だけでなく、一定のシステム要件（ある場合）を満たす限り、他のベンダが提供するピンを含むピン群を宣言することができる。テストクラスは、テストプランプログラムで指定されるハードウェア表現を使用するべく、このタイプのベンダに依存しない（すなわち論理）ハードウェア表現をサポートする。システムにより、ベンダ特定ランタイム較正インプリメンテーションが、インタフェースを介して、たとえばインタフェースクラスICDVendRtCalを介して明らかにされる場合であっても、実際のインプリメンテーションは異なってもよい。このように、各ベンダ特定ランタイム較正コンポーネントは、その機能に対し異なるアクセスハンドルを有する。テストクラス開発者（すなわちユーザ）は、同じ論理ハードウェア表現に関連するベンダ特定アクセスハンドルを別々に取得し各アクセスハンドルを別々に処理する必要がある（それらは各々、同じ論理ハードウェア表現から抽出される特別なベンダ特定ハードウェアリソースに関与する）。テストクラス開発中にこの複雑性を回避するために、Ｃ＆Ｄフレームワークがこの複雑性を隠し、ICDRuntimeCalインタフェースによるプロキシインプリメンテーションを提供する。

図４は、本発明の一実施形態による、ランタイム中にベンダ特定較正情報をオープンアーキテクチャテスタフレームワークに統合することを示すＵＭＬクラス図である。ＵＭＬ図は、Ｃ＆Ｄベンダランタイム較正（ICDVendRtCal）インタフェース４０２と、Ｃ＆Ｄランタイム較正（ICDRuntimeCal）インタフェース４０４と、Ｃ＆Ｄランタイムシステム（ICDRuntimeSys）インタフェース４０６とを含む。ICDVendRtCalインタフェース４０２は、フレームワークがベンダ特定ランタイム較正ルーチンセットの特定のインプリメンテーションを取得することができるメカニズムを含む。ICDRuntimeCalインタフェース４０４によって、ユーザは、ICDVendRtCalランタイム較正インタフェース４０２の異なるベンダ特定インプリメンテーションにアクセスすることができる。図４のＵＭＬ図は、サイトコントローラ２１４、サイトコントローラＣ＆Ｄフレームワーク２１０、ベンダランタイム較正クラス４０８、ランタイム較正クラス４１０及びテストクラス４１２をさらに含む。

一実施形態では、ICDVendRtCalインタフェース４０２、ICDRuntimeCalインタフェース４０４及びICDRuntimeSysインタフェース４０６は、以下のメソッドのうちの１つ又は複数を含む。すなわち、getSwModule()、getAlgRev()、isInitialized()、loadDCCalData()、loadACCalData()、getAttributeCache()、tdrCal()、getTdrCalDataFromFile()、putTdrCalDataToFile()、mergeCal()及びloadACCalData()である。

getAlgRev()メソッドは、試験モジュールがサポートするアルゴリズム又はデータタイプ名を返す。Ｃ＆Ｄフレームワークは、getAlgRev()メソッドを介してデフォルトリビジョン及びサポートされるリビジョンを要求する。リビジョン選択は、ユーザがＣ＆Ｄ ＧＵＩツールで行う。フレームワークは、選択されたリビジョンを読み出すためにベンダモジュールのためのユーティリティを提供する。試験モジュールは、選択されたリビジョンを使用してバンドル機能をサポートする。

isInitialized()メソッドは、Ｃ＆Ｄフレームワークにより、試験モジュールが初期化されるか否かを判断するために呼び出される。

loadDCCalData()メソッドは、ハードウェアモジュールが動作する用意ができるためにＤＣ較正データがハードウェアモジュールにロードされる必要のある場合に呼び出される。フレームワークは、ベンダモジュールにおいてisInitialized()メソッドを呼び出すことにより、モジュールに対してそれらが用意ができているか否かを問い合わせ、この関数をオンデマンドで呼び出すことにより、特定のモジュールに対してＤＣ較正オブジェクトをロードする。ベンダモジュールは、ユーザが使用したいアルゴリズムリビジョンを取得する。このアクティビティに対する機能は、Ｃ＆Ｄフレームワークによって提供される。

loadACCalData()メソッドは、ハードウェアモジュールが動作する用意ができるためにＡＣ較正データがハードウェアモジュールにロードされる必要のある場合に呼び出される。フレームワークは、ベンダモジュールにおいてisInitialized()メソッドを呼び出すことにより、モジュールに対してそれらが用意ができているか否かを問い合わせ、この関数をオンデマンドで呼び出すことにより、特定のモジュールに対してＡＣ較正をロードする。ベンダモジュールは、ユーザが使用したいアルゴリズムリビジョンを取得する。このアクティビティに対する機能は、Ｃ＆Ｄフレームワークによって提供される。標準ＡＣ較正データは、デフォルト条件に対して測定された較正データである。このデフォルト条件は、ベンダハードウェアモジュールによって決定される。たとえば、ADVANTEST DM250MHzモジュールは、ドライバ電圧スイングが０ｖ〜３ｖである標準ＡＣ較正データを測定する。

メソッドgetAttributeCache()メソッドは、ICDCalAttributeCacheオブジェクトを取得する。ICDCalAttributeCacheは、オアシステストプログラム言語（Oasis Test Program Language）（ＯＴＰＬ）において較正ブロックで記述されているパラメータ値の対のベンダモジュール特定インタプリタである。較正ブロックは、オンライン較正条件に対する条件を記述する。各ベンダハードウェアモジュールは、オンライン較正条件として異なるパラメータのセットを有する必要がある。

これらのオンライン較正パラメータは、リソースファイルに列挙される。任意の特定のモジュールによってサポートされるリソースタイプがオンライン較正パラメータを有する場合、それを対応するリソースファイルに列挙する必要がある。リソースファイルは、システムによって読み出され、較正ブロックに指定されているパラメータを受け入れるために何の較正モジュールが関与するかを判断するために使用される。

ICDCalAttributeCacheは、ベンダハードウェアモジュール特定オンライン較正パラメータを設定し、且つそれをハードウェアモジュールに書き込むメソッドを提供するためのインタフェースである。較正モジュール開発者は、ハードウェアモジュールが、ユーザがこの特定のモジュールを使用する条件に従って較正データ補償を必要とする場合、getAttributeCache()を通して特定のリソースタイプに対するインスタンスを返すこのインタフェースを実施する。フレームワークは、オンライン較正パラメータをこのインスタンスに渡し、それをハードウェアモジュールに書き込むapply()メソッドを呼び出す。パラメータは、試験条件メモリ（Test Condition Memory）（ＴＣＭ）に格納され、フレームワークは、試験条件を認識するICDCalAttributeCacheオブジェクトのセットに対しＩＤを与える。

tdrCal()メソッドは、較正データを補償するために時間領域反射（ＴＤＲ）メソッドを使用することにより特定のチャネルにおけるケーブルの長さを測定する。このメソッドは、この機能を必要とするハードウェアモジュールに対して実施される。

getTdrCalDataFromFile()メソッドは、tdrCal()メソッドによって作成されるＴＤＲデータファイルを読み出す。ベンダインプリメンテーションは、パフォーマンスボード識別子に対してＴＤＲデータファイルを読み出す必要がある。このメソッドは、データファイルにおけるピンのＴＤＲデータを読み出す。

putTdrCalDataToFile()メソッドは、ＴＤＲデータファイルを書き込む。このメソッドは、他のユーザ指向データファイルからＴＤＲデータファイルを作成したいユーザか又はtdrCal()によって測定されるＴＤＲデータを補償したいユーザによって使用される。

mergeCal()メソッドは、ＴＤＲ結果データを用いて標準ＡＣ較正データを補償する。標準ＡＣ較正データ又は任意の較正データは、このメソッドを呼び出す前にロードされる必要がある。

loadACCalData()メソッドは、ユーザがデータファイルから標準ＡＣ較正データ又は任意のＡＣ構成データ又は併合されたＡＣ較正データをロードしようと試みる場合に呼び出される。宛先が試験条件メモリである場合、ブロック識別子はTcmIDに指定される。作成された試験条件メモリブロックは、selectTestCondition()メソッドによって選択される。指定されたTcmIDを、システムが、試験実行時に較正データをオンライン較正データからこのメソッドによってロードされた元の較正データに戻すために使用してもよい。ユーザが、データを試験条件メモリにロードするためにこのメソッドを使用しない場合、システムは、TcmIDが未知であるベンダモジュールにおいてselectTestCondition()を呼び出す。ベンダモジュールは、この状態でエラーを返す。
<試験条件メモリの使用>

ランタイム較正アクティビティを、テストプランプログラム実行中に実行してもよい。たとえば、オンライン較正を、システム精度の損失をもたらす可能性がある任意の状態が検出される度毎に行ってもよい。このオンライン較正により、試験実行時間に対するオーバヘッドがもたらされ、それにより、試験システムの生産性が低下する可能性がある。

このオーバヘッドを軽減するために、本発明の別の実施形態によれば、試験システムは、事前定義された較正データのセットをプリロードし、それを試験条件メモリに格納する。試験条件メモリ（ＴＣＭ）は、試験条件を格納する条件データキャッシュであり、試験条件データをＴＣＭからハードウェアレジスタに有効に転送することができる。この試験条件メモリを、ソフトウェアで実施してもよく又はハードウェアで実施してもよい。Ｃ＆Ｄフレームワークは、ベンダ較正モジュールによって実施される以下のメソッドを有するITCMManipulatorインタフェースを使用して、試験条件を作成し、選択し、削除する。
OFCStatus openTCMEntry(TCMID_t condition);
OFCStatus closeTCMEntry(TCMID_t condition);
OFCStatus selectTCMEntry(TCMID_t condition);
OFCStatus removeTCMEntry(TCMID_t condition);
TCMID_tは、試験条件の識別子である。フレームワークは、試験条件の作成（openTestCondition()及びcloseTestCondition()）、選択（selectTestCondition()）、削除（removeTestCondition()）に対する識別子を指定する。TCMManipulatorは、ICDVendRtCal::getTCMManipulator()によって返される。

テストプランプログラム実行時間中、Ｃ＆Ｄフレームワークは、適当な試験条件メモリブロックを選択し、それらを対応するハードウェアモジュールレジスタに転送する。図５は、本発明の一実施形態による試験条件メモリを実施する方法を示す。この方法は、試験条件メモリマニピュレータインタフェース（ITCMManipulator）５０２、Ｃ＆Ｄベンダランタイム較正インタフェース４０２及びベンダランタイム較正データオブジェクト４０８を含む。ITCMManipulatorインタフェース５０２は、Ｃ＆Ｄフレームワークにより、試験条件メモリを操作するために使用される。このインタフェースを実施することにより、任意のベンダの試験条件データをＴＣＭにシームレスに統合し且つロードすることができ、それにより試験システムの較正オーバヘッドが低減する。

開示されたＣ＆Ｄフレームワークによって達成されるいくつかの利益がある。第１に、これにより、装置の較正及び／又は診断のためにいかなるベンダ特定のプロプラエタリな処理を必要とすることなく、マルチベンダ（すなわちサードパーティ）ソフトウェア及び装置を開発し、個々に認証し、試験システムに確実に統合することができる。さらに、開示されたＣ＆Ｄフレームワークは、ベンダ提供較正及び／又は診断モジュールを別々のコンポーネントに編成し、それにより、特定のベンダ提供コンポーネントの統合及び使用のためのシームレスなサポートが提供される。さらに、開示されたＣ＆Ｄフレームワークは、モジュールＣ＆Ｄコンポーネントによってシステム装置を共有するリモートアクセス方式を提供する。さらに、Ｃ＆Ｄフレームワークは、試験条件メモリに較正データを格納するメカニズムを提供し、それにより、通常試験中に試験システムの再較正によってもたらされる試験プログラムランタイムオーバヘッドが低減する。

関連技術分野の熟練者（当業者）は、依然として同じ基本の根本的なメカニズム及び方法を採用しながら、開示された実施形態の多くのあり得る変更及び組合せを使用してもよい、ということを理解するであろう。上述した記述は、説明の目的のために、特定の実施形態を参照して述べた。しかしながら、上記例示的な論考は、網羅的であるように、又は本発明を開示した正確な形態に限定するようにも意図されていない。上記教示に鑑みて、多くの変更及び変形が実施できる。本発明の原理とその実際的な適用とを説明するように、且つ当業者が、企図された特定の使用に適するよう、本発明及びさまざまな実施形態をさまざまな変更態様で最もよく利用することができるように、実施形態を選択し述べた。

本発明の一実施形態によるオープンアーキテクチャ試験システムを示す図である。 本発明の一実施形態によるＣ＆Ｄフレームワークを使用してベンダ提供Ｃ＆Ｄ情報を統合する方法を示す図である。 本発明の一実施形態による共有装置にアクセスする試験システムによって使用される方式を示す図である。 本発明の一実施形態による、それ自体のドライバのタイミングを較正するデジタル関数発生器モジュールの波形を示す図である。 本発明の一実施形態によるドライバタイミング較正データのオンライン補償の波形を示す図である。 本発明の一実施形態による、ランタイム中にオープンアーキテクチャテスタフレームワークへのベンダ特定較正情報の統合を示す図である。 本発明の一実施形態による試験条件メモリを実施する方法を示す図である。

Claims (12)

1. モジュール式試験システムに試験モジュール（１０８）を統合する方法であって、
   ベンダ提供試験モジュール（１０８）を前記モジュール式試験システムに接続すること、
   前記ベンダ提供試験モジュールからサポートするカテゴリを取り出すこと、
   取り出した前記カテゴリに従って前記ベンダ提供試験モジュール（１０８）から当該ベンダ提供試験モジュール（１０８）を前記モジュール式試験システムに統合するためのモジュール統合情報を取り出すこと、及び
   前記ベンダ提供試験モジュール（１０８）と前記モジュール式試験システムとの間の標準インタフェースを確立してモジュール統合情報を通信するインタフェースクラスを含む較正及び診断（Ｃ＆Ｄ）フレームワークを使用して、前記モジュール統合情報に基づき前記ベンダ提供試験モジュールを前記モジュール式試験システムに統合すること
   を含む方法。
2. 前記インタフェースクラスは、Ｃ＋＋クラスとして定義される、請求項１に記載の方法。
3. 取り出された前記モジュール統合情報を前記モジュール式試験システムが備えるサイトコントローラ（１０４）における試験条件メモリ（ＴＣＭ）に格納すること、及び
   前記試験条件メモリに格納された前記モジュール統合情報に基づいて前記ベンダ提供試験モジュール（１０８）の較正を実行すること
   をさらに含む、請求項１に記載の方法。
4. 取り出された前記モジュール統合情報を前記モジュール式試験システムが備えるサイトコントローラ（１０４）における試験条件メモリ（ＴＣＭ）に格納すること、及び
   前記試験条件メモリに格納された前記モジュール統合情報に基づいて前記ベンダ提供試験モジュール（１０８）に対して診断を実行すること
   をさらに含む、請求項１に記載の方法。
5. 較正を実行することは、
   ランタイム較正インタフェースを提供すること、及び
   前記ランタイム較正インタフェースに基づいて前記ベンダ提供試験モジュール（１０８）のランタイム較正を実行すること
   を含む、請求項３に記載の方法。
6. ランタイム較正を実行することは、
   ハードウェアモジュールステータスを取得すること、
   較正データをロードすること、
   時間領域反射を実行すること、及び
   タイミング較正データ補償を実行すること
   を含む、請求項５に記載の方法。
7. モジュール式試験システムであって、
   システムコントローラ（１０２）と、
   該システムコントローラ（１０２）に結合される少なくとも１つのサイトコントローラ（１０４）と、
   サポートするカテゴリを保持する少なくとも１つのベンダ提供試験モジュール（１０８）と、
   ベンダ提供試験モジュール（１０８）を前記モジュール式試験システムに接続する手段（１０６）と、
   前記ベンダ提供試験モジュールからカテゴリを取り出す手段と、
   取り出した前記カテゴリに従って前記ベンダ提供試験モジュール（１０８）から当該ベンダ提供試験モジュール（１０８）を前記モジュール式試験システムに統合するためのモジュール統合情報を取り出す手段と、
   ベンダ提供試験モジュール（１０８）と前記モジュール式試験システムとの間の標準インタフェースを確立してモジュール統合情報を通信するインタフェースクラスを含む較正及び診断（Ｃ＆Ｄ）フレームワークを使用して、前記モジュール統合情報に基づいて前記ベンダ提供試験モジュール（１０８）を前記モジュール式試験システムに統合する手段と
   を具備するモジュール式試験システム。
8. 前記インタフェースクラスは、Ｃ＋＋クラスとして定義される、請求項７に記載のシステム。
9. 前記少なくとも１つのサイトコントローラ（１０４）に設けられ、取り出された前記モジュール統合情報を格納する試験条件メモリ（ＴＣＭ）と、
   該試験条件メモリに格納された前記モジュール統合情報に基づいて前記ベンダ提供試験モジュール（１０８）の較正を実行する手段と
   をさらに具備する、請求項７に記載のシステム。
10. 前記少なくとも１つのサイトコントローラ（１０４）に設けられ、取り出された前記モジュール統合情報を格納する試験条件メモリ（ＴＣＭ）と、
    該試験条件メモリに格納された前記モジュール統合情報に基づいて前記ベンダ提供試験モジュール（１０８）に対して診断を実行する手段と
    をさらに具備する、請求項７に記載のシステム。
11. 前記較正を実行する手段は、
    ランタイム較正インタフェースと、
    該ランタイム較正インタフェースに基づいて前記ベンダ提供試験モジュールのランタイム較正を実行する手段と
    を具備する、請求項９に記載のシステム。
12. 前記ランタイム較正を実行する手段は、
    ハードウェアモジュールステータスを取得する手段と、
    較正データをロードする手段と、
    時間領域反射を実行する手段と、
    タイミング較正データ補償を実行する手段と
    を具備する、請求項１１に記載のシステム。

Images