(57)【要約】【課題】試験装置のオフライン・シュミレーション環境において、テストプログラムの動作検証をより高速かつ低コストで実現する。【解決手段】本シミュレーション方法は、試験信号を被試験デバイス（ＤＵＴ）１１２に供給する試験装置１００を用いて、実デバイスから所定の特性を測定するステップと、測定により取得された測定結果から生成された試験結果データを、ファイル１３６に保存するステップと、ファイル１３６に保存された試験結果データを用いて、試験装置１００をシミュレートするシミュレーションシステム１２０でテストプランプログラムの動作を検証するステップと、を備える。かかる発明によれば、試験装置１００のオフライン・シュミレーション環境において、仮想デバイスの試験結果を容易に作成できる。【選択図】図１２
2009116876.tif 000002
【特許請求の範囲】
【請求項１】
試験信号を被試験デバイス（ＤＵＴ）に供給する試験装置を用いて、実デバイスから所定の特性を測定するステップと、
前記測定により取得された測定結果から生成された試験結果データを、ファイルに保存するステップと、
前記ファイルに保存された試験結果データを用いて、前記試験装置をシミュレートするシミュレーションシステムでテストプランプログラムの動作を検証するステップと、
を備えるシミュレーション方法。
【請求項２】
前記試験結果データは、
一以上の特性の測定値と、所定のテスト項目に対する出力結果と、を含む、
請求項１記載のシミュレーション方法。
【請求項３】
前記出力結果は、
前記所定のテスト項目に対する実デバイスからの出力結果がパス又はフェイルで設定される、
請求項２記載のシミュレーション方法。
【請求項４】
前記検証するステップは、
前記試験結果データに出力結果が設定されていない場合には、出力結果をパスとみなす、
請求項３記載のシミュレーション方法。
【請求項５】
前記試験結果データは、
一以上の実デバイスから取得された測定結果に基づいて生成される、
請求項１記載のシミュレーション方法。
【請求項６】
前記ファイルに保存された試験結果データを、ユーザが任意に改変するステップと、
を備える請求項１記載のシミュレーション方法。
【請求項７】
前記試験結果データは、
一以上の特性に対して、出力結果がマトリクス状に配列される、
請求項１記載のシミュレーション方法。
【請求項８】
前記検証するステップは、
パターンプログラムをロードすることなく、前記テストプランプログラムの動作を検証する、
請求項１記載のシミュレーション方法。
【請求項９】
前記検証するステップは、
前記シミュレーションシステムに前記ファイルから試験結果データをロードするステップと、
前記シミュレーションシステムに前記テストプランプログラムをロードするステップと、
前記テストプランプログラムを実行するステップと、
前記測定結果が前記シミュレーションシステム上で再現されることにより、前記テストプランプログラムの動作を検証するステップと、
を含む請求項１記載のシミュレーション方法。
【請求項１０】
試験信号を被試験デバイス（ＤＵＴ）に供給する試験装置によって解釈されるテストプランプログラムの動作を検証するシミュレーションシステムであって、
前記試験装置を用いて、実デバイスから所定の特性を測定し、前記測定により取得された測定結果から生成された試験結果データを保存するファイルと、
前記ファイルから読み出した試験結果データを用いて、前記テストプランプログラムの動作を検証するフレームワークと、
を備えるシミュレーションシステム。
【請求項１１】
前記試験結果データは、
一以上の特性の測定値と、所定のテスト項目に対する出力結果と、を含む、
請求項１０記載のシミュレーションシステム。
【請求項１２】
前記出力結果は、
前記所定のテスト項目に対する実デバイスからの出力結果がパス又はフェイルで設定される、
請求項１１記載のシミュレーションシステム。
【請求項１３】
前記フレームワークは、
前記試験結果データに出力結果が設定されていない場合には、出力結果をパスとみなす、
請求項１２記載のシミュレーションシステム。
【請求項１４】
前記試験結果データは、
一以上の実デバイスから取得された測定結果に基づいて生成される、
請求項１０記載のシミュレーションシステム。
【請求項１５】
前記ファイルに保存された試験結果データは、ユーザが任意に改変可能である、
請求項１０記載のシミュレーションシステム。
【請求項１６】
前記試験結果データは、
一以上の特性に対して、出力結果が１次元又は２次元以上のマトリクス状に配列される、
請求項１０記載のシミュレーションシステム。
【請求項１７】
コンピュータに、
試験信号を被試験デバイス（ＤＵＴ）に供給する試験装置を用いて、実デバイスから所定の特性を測定するステップと、
前記測定により取得された測定結果から生成された試験結果データを、ファイルに保存するステップと、
前記ファイルに保存された試験結果データを用いて、前記試験装置をシミュレートしてテストプランプログラムの動作を検証するステップと、
を実行させるためのプログラム製品。
【請求項１８】
前記試験結果データは、
一以上の特性の測定値と、所定のテスト項目に対する出力結果と、を含む、
請求項１７記載のプログラム製品。
【請求項１９】
前記出力結果は、
前記所定のテスト項目に対する実デバイスからの出力結果がパス又はフェイルで設定される、
請求項１８記載のプログラム製品。
【請求項２０】
前記検証するステップは、
前記試験結果データに出力結果が設定されていない場合には、出力結果をパスとみなす、
請求項１９記載のプログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は自動試験装置（ＡＴＥ）の技術分野に関する。特に、本発明は、自動試験装置をシミュレートする技術分野に関する。
【背景技術】
【０００２】
半導体製造における主なコストは、実行可能性及び機能性に対し集積回路を試験するテストプログラムの開発及び保守である。これを行うには、従来、実際のテスタハードウェアに対する何時間もの作業が必要である。すなわち、従来の半導体テスタには、テストプログラムをシミュレートする能力がほとんどないかまったくない。この制限により、技術者は、実際のテスタハードウェアにおいて自身のテストプログラムをデバッグすることが余儀なくされる。
【０００３】
しかしながら、近年、試験装置のエミュレータが提供され、高価な試験装置を使用することなくテストプログラムの機能性を検証することが可能になっている。例えば、特許文献１には、テストプログラム、ベンダモジュール及びそれらの対応する被試験デバイス（ＤＵＴ）を用いてモジュール式試験システムをシミュレートするエミュレータが開示されている。
【特許文献１】特許第３７３５６３５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ところで、近年、多くの機能が１チップ化されるなど、デバイスのスピード、サイズ、機能は飛躍的に進化しつつあり、デバイス試験においても、高機能化、複雑化に対応するとともに、デバイス解析能力を高めて、ターン・アラウンド・タイム（ＴＡＴ）を短縮することが大きな課題である。また、開発期間の短縮の要求のみならず、テスタ価格及びテスト時間を含むテストコストを削減することも大きな課題である。そのため、試験装置のオフライン・シミュレーション環境を充実させて、より高速かつ低コストでテストプログラムを検証できるようにすることが求められている。
【０００５】
本発明は、かかる事情に鑑みてなされたものである。本発明に係るいくつかの態様は、試験装置のオフライン・シュミレーション環境において、テストプログラムの動作検証を妥当な時間内に実現し、それにより製品開発時間を短縮することを目的とする。また、本発明に係る幾つかの態様は、試験装置のオフライン・シュミレーション環境において、テストプログラムの動作検証を低コストで実現し、それにより製品開発コストを削減することを目的とする。
【課題を解決するための手段】
【０００６】
上記課題を解決するために、本発明による試験装置のシミュレーション方法は、試験信号を被試験デバイス（ＤＵＴ）に供給する試験装置を用いて、実デバイスから所定の特性を測定するステップと、測定により取得された測定結果から生成された試験結果データを、ファイルに保存するステップと、ファイルに保存された試験結果データを用いて、試験装置をシミュレートするシミュレーションシステムでテストプランプログラムの動作を検証するステップと、を備える。かかる発明によれば、試験装置のオフライン・シュミレーション環境において、仮想デバイスの試験結果を容易に作成できるので、より高速かつ低コストでテストプログラムを検証できる。
【０００７】
好適には、試験結果データは、一以上の特性の測定値と、所定のテスト項目に対する出力結果と、を含む。また、好適には、出力結果は、所定のテスト項目に対する実デバイスからの出力結果がパス又はフェイルで設定される。さらに好適には、検証するステップは、試験結果データに出力結果が設定されていない場合には、出力結果をパスとみなす。
【０００８】
また、好適には、試験結果データは、一以上の実デバイスから取得された測定結果に基づいて生成される。
【０００９】
さらに好適には、ファイルに保存された試験結果データを、ユーザが任意に改変するステップを備える。
【００１０】
また、好適には、試験結果データは、一以上の特性に対して、出力結果が１次元又は２次元以上のマトリクス状に配列される。
【００１１】
さらに、検証するステップは、パターンプログラムをロードすることなく、テストプランプログラムの動作を検証する。好適には、検証するステップは、シミュレーションシステムにファイルから試験結果データをロードするステップと、シミュレーションシステムにテストプランプログラムをロードするステップと、テストプランプログラムを実行するステップと、測定結果がシミュレーションシステム上で再現されることにより、テストプランプログラムの動作を検証するステップと、を含む。
【００１２】
また、本発明による試験装置のシミュレーションシステムは、試験信号を被試験デバイス（ＤＵＴ）に供給する試験装置によって解釈されるテストプランプログラムの動作を検証する。当該シミュレーションシステムは、試験装置を用いて、実デバイスから所定の特性を測定し、測定により取得された測定結果から生成された試験結果データを保存するファイルと、ファイルから読み出した試験結果データを用いて、テストプランプログラムの動作を検証するフレームワークと、を備える。
【００１３】
本発明によるプログラム製品は、本発明による試験装置のシミュレーション方法の各処理ステップをコンピュータに実行させることを特徴とする。本発明のプログラムは、ＣＤ−ＲＯＭ等の光学ディスク、磁気ディスク、半導体メモリなどの各種の記録媒体を通じて、又はインターネットなどの伝送媒体などを介してダウンロードすることにより、コンピュータにインストール又はロードすることができるが、プログラムを記録又は伝送等する媒体はこれらに限定されない。本明細書で説明されるコンピュータプログラム製品、ならびに任意のソフトウェアおよびハードウェアは、実施形態にある本発明の機能を実行するための様々な手段を形成する。
【００１４】
なお、本明細書等において、手段とは、単にハードウェアによる物理的手段を意味するものではなく、その手段が有する機能をソフトウェアによって実現する場合も含む。また、１つの手段が有する機能が２つ以上の物理的手段により実現されても、２つ以上の手段の機能が１つの物理的手段により実現されてもよい。
【００１５】
以下、本発明の上述した特徴及び利点とともにその追加の特徴及び利点について、以下の図面をともに考慮した場合に、本発明の実施形態の詳細な説明の結果として、より明確に理解されるであろう。
【発明を実施するための最良の形態】
【００１６】
以下、本発明の実施の形態について詳細に説明する。なお、同一の要素には同一の符号を付し、重複する説明を省略する。また、以下の実施の形態は、本発明を説明するための例示であり、本発明をその実施の形態のみに限定する趣旨ではない。さらに、本発明は、その要旨を逸脱しない限り、さまざまな変形及び応用が可能である。
【００１７】
図１は、如何に信号が生成され、被試験デバイス（ＤＵＴ）に加えられるかを示す、従来のテスタの一般化されたアーキテクチャを示す。各ＤＵＴ入力ピンが、試験データを加えるドライバ２に接続され、一方、各ＤＵＴ出力ピンはコンパレータ４に接続される。大抵の場合に、トライステートドライバ‐コンパレータが用いられ、各テスタピン（チャネル）が入力ピン、出力ピンのいずれかとして動作できるようにする。単一のＤＵＴのために専用に設けられるテスタピンは合わせて試験サイトを形成し、その試験サイトは、関連するタイミング発生器６、波形発生器８、パターンメモリ１０、タイミングデータメモリ１２、波形メモリデータ１４及びデータ速度を規定するブロック１６によって動作する。
【００１８】
図２は、本発明の一実施形態による試験装置１００のシステムアーキテクチャを示す。試験装置１００は、試験信号を生成してＤＵＴ１１２に供給し、ＤＵＴ１１２が試験信号に基づいて動作した結果出力する結果信号が期待値と一致するか否かに基づいてＤＵＴ１１２の良否を判断する。本実施形態に係る試験装置１００は、オープンアーキテクチャにより実現され、ＤＵＴ１１２に試験信号を供給するモジュール１０８として、オープンアーキテクチャに基づく各種のモジュールを用いることができる。
【００１９】
また、試験装置１００は、オフラインでテストプランプログラム（以下「試験プログラム」ともいう。）の動作検証（デバッグ等）を行うためのシミュレーションシステム１２０を有し、このシミュレーションシステム１２０により、ＤＵＴ１１２の実試験を適切にシミュレートするオフライン・シミュレーション環境（以下「オフライン環境」ともいう。）を提供する。本実施形態において、シミュレーションシステム１２０は、シミュレーション環境として、フル・シミュレーションモード（以下「ＦＳＭ」という。）と、ライト・シミュレーションモード（以下「ＬＳＭ」という。）の、２種類のシミュレーションモードを有する。
【００２０】
本実施形態では、システムコントローラ（ＳｙｓＣ）１０２が複数のサイトコントローラ（ＳｉｔｅＣ）１０４に接続される。システムコントローラ１０２は、ネットワークにも接続され、ファイルにアクセスすることができる。試験サイト１１０に配置される１つ又は複数の試験モジュール１０８を制御するために、各サイトコントローラ１０４は、モジュール接続イネーブラ１０６を通して、試験モジュール１０８に接続される。モジュール接続イネーブラ１０６は、接続されるハードウェアモジュール１０８の構成を変更できるようにするとともに、データ転送用（パターンデータのロード用、応答データの収集用、制御用等）のバスとしての役割も果たす。実現可能なハードウェアの実装形態は、専用接続、交換接続、バス接続、リング接続及びスター接続を含む。モジュール接続イネーブラ１０６は、たとえばスイッチマトリクスとして実装することができる。各試験サイト１１０は１つのＤＵＴ１１２に関連付けられ、ＤＵＴ１１２は、ロードボード１１４を通して、対応するサイトのモジュールに接続される。他の一実施形態では、単一のサイトコントローラを複数のＤＵＴサイトに接続することができる。
【００２１】
システムコントローラ１０２は、システム全体のマネージャとしての役割を果たす。また、システムコントローラ１０２は、試験装置１００がＤＵＴ１１２の試験に用いる試験制御プログラム、試験プログラム、及び試験データ等を外部のネットワーク等を介して受信し、格納する。システムコントローラ１０２は、サイトコントローラ１０４の動作状態を調整し、システムレベルの並列試験方法を管理し、さらに、ハンドラ／プローブを制御し、システムレベルのデータロギング及び誤り処理をサポートする。動作環境によっては、システムコントローラ１０２は、サイトコントローラ１０４の動作とは別のＣＰＵ上に配置することができる。別法では、システムコントローラ１０２及びサイトコントローラ１０４は、共通のＣＰＵを共有することができる。同様に、各サイトコントローラ１０４は、その専用のＣＰＵ（中央演算装置）上に配置することができるか、あるいは同じＣＰＵ内の別個のプロセス又はスレッドとして配置することができる。また、動作環境によっては、システムコントローラ１０２は、シミュレーションシステム１２０の動作とは別のＣＰＵ上に配置することができる。別法では、システムコントローラ１０２及びシミュレーションシステム１２０は、共通のＣＰＵを共有することができる。
【００２２】
個々のシステムコンポーネントを、集積されたモノリシックシステムの論理的なコンポーネントを見なすことができ、必ずしも１つの分散処理システムの物理的なコンポーネントではないことを前提とすると、図２に示されるシステムアーキテクチャは概念的には分散処理システムと考えることができる。 
【００２３】
図３は、本発明の一実施形態によるシミュレーションシステム１２０の概略構成を示すブロック図である。シミュレーションシステム１２０は、ＬＳＭにてテストプランの検証を行うためフレームワーク１３０と、試験装置１００をエミュレートするエミュレータ１４０とを含む。
【００２４】
フレームワーク１３０は、試験結果データベース（以下「試験結果ＤＢ」という。）１３２を備え、ＬＳＭによる試験実行のシミュレーションを提供する。ＬＳＭでテストプランプログラムを実行するためには、まず、シミュレーションモードとしてＬＳＭを選択した上で、テストプランプログラムをロードする。なお、ＬＳＭでロードする際に、テストプランプログラムやパターン等の変更は必要ない。
【００２５】
ＬＳＭでは、フレームワーク１３０上で、ロードされたテストプランプログラムが動作する。このとき、フレームワーク１３０では、記憶装置に保存された試験結果データファイル（Response Data File）１３６から読み出した試験結果データ（Response Data）を試験結果ＤＢ１３２に予め格納しておき、試験結果ＤＢ１３２に格納されたデータは、直接又はモジュールドライバ（Module Driver）１３８を通して、テストプランプログラムのＤＬＬに作用する。こうして、ＬＳＭでは、シミュレーションシステム１２０上で任意にテスト結果を発生させて、オフラインエミュレータ上で動作するデバイスプランに対して期待値を外部から変更する機能を備えることにより、テストフローを中心とするテストプランプログラムの検証を、ＦＳＭよりも短時間で実行する。
【００２６】
エミュレータ１４０は、コントローラモデルと、１つ又は複数のモジュールモデルと、１つ又は複数の被試験デバイス（ＤＵＴ）モデルと、ロードボードモデルとを含む。シミュレーション環境を組み立てるために、ユーザは、モジュールモデル、ロードボードモデル及びＤＵＴモデルがシミュレーションフレームワークを介して接続される方法を記述する、システム構成ファイル及びオフライン構成ファイルを生成する。
【００２７】
エミュレータ１４０のシミュレーションフレームワークは、ロードボードモデルと、１つ又は複数のテスタチャネルと、１つ又は複数のＤＵＴチャネルとを提供する。モジュールモデルは、ベンダの動的リンクライブラリ（ＤＬＬ）からロードされる。各ブロックは、モジュールの単一インスタンスを表す。ＤＬＬを複数回ロードすることにより、同じモジュールタイプの複数のインスタンスを生成することができる。ＤＵＴモデルが、Ｃ＋＋で書かれる場合はＤＵＴモデルをＤＬＬとして提供してもよく、又はＶｅｒｉｌｏｇモードとして提供してもよい。
【００２８】
ロードボードモデルは、ユーザによって構成可能である。ユーザは、テスタチャネルを対応するＤＵＴチャネルにマップし、各接続に関連する移送遅延を指定する。接続はすべて双方向であり、そのため、コネクタを出力ドライバ又は入力ストローブとして指定するように特別に考慮する必要はない。
【００２９】
エミュレータ１４０によるＦＳＭでのシミュレーションの主な部分はシミュレーションフレームワークであり、それはまたフレームワークとも呼ばれる。フレームワークは、２つの基本サービスを提供する。第一に、フレームワークにより、各モジュールを、システムバスを介して標準テスタ動作中と実質的に同じようにプログラム可能である。バスコールをシミュレートすることにより、試験プログラムは、エミュレートされたモジュールレジスタに書き込むことができ、それにより試験をセットアップする。もう一方のサービスは、試験実行のシミュレーションである。フレームワークは、エミュレートされたモジュールとＤＵＴモデルとの間の物理接続のためのモデルを提供する。フレームワークはまた、さまざまなシミュレーションコンポーネントの実行シーケンスを維持するエンジンも提供する。
【００３０】
試験装置１００は、オフライン・シミュレーションモード（オフライン環境）にある時、テスタモジュールハードウェアと通信するために使用されるデバイスドライバを、共有メモリを通してフレームワークと通信するソフトウェアモジュールに置き換える。実際のテスタでは、モジュールとの通信は、バスとして知られるハードウェアモジュールによって容易にされる。バスは、通常、ベンダのハードウェアモジュールにおけるアドレス指定可能レジスタにバイナリパターンを送出するコマンドを使用する。このシミュレーションでは、フレームワークによって、特定のエミュレートされたモジュールを対象とするために同じコマンドが受け取られ且つ解釈される。その後、フレームワークは、レジスタアドレス及びデータをモジュールに送出することにより、モジュールがそのシミュレートされたレジスタにデータを保存することができるようにする。試験プログラムローディングは、最終的にはアドレス／データ対のこれらの基本単位に分解されるため、この単純なモデルは、試験プログラムがモジュールと行うすべての対話をサポートする。
【００３１】
オンラインモードとオフラインモードとの間のランタイムソフトウェアの相違は、システムバスデバイスドライバのみにあるため、オンライン環境における試験プログラムの挙動とオフライン環境におけるその対応する挙動とには高い相関性がある。このため、シミュレーションは、ユーザの試験プログラム及び基礎となるテスタオペレーティングシステム（ＴＯＳ）の挙動に関して正確である。
【００３２】
フレームワークはまた、テスタモジュールとＤＵＴとの物理接続の詳細なモデルも提供する。接続はすべて、ワイヤにおける電圧としてモデル化され、それにより基礎となる物理的特性が再現される。モジュール／ＤＵＴ対話においてデータフォーマットに関する仮定がないため、フレームワークは、エミュレーションモジュール及びＤＵＴモデルがフレームワークによって確立されるアプリケーションプログラミングインタフェース（ＡＰＩ）を使用する限り、それらの任意の組合せとともに機能する。フレームワークは、２つの電源が同じワイヤを同時に駆動する場合、電圧の自動調停を提供する。
【００３３】
試験プログラムの実行中にシミュレーションを制御するために、フレームワークは、そのＡＰＩにおいて、ベンダのモジュールがイベントを登録し且つ受け取ることができるようにするさまざまなメソッドを提供する。フレームワークは、これらのイベントを使用して、エミュレートされたモジュール及びＤＵＴモデルの実行のシーケンスを制御する。これらのイベントを管理することにより、且つモジュールがいかにイベントを処理するかに関する何らかの基本的な規則を指定することにより、モジュールエミュレーションを生成する柔軟なテンプレートを、モジュール式試験システムのユーザが利用することができるようになる。
【００３４】
図４は、本発明の一実施形態によるソフトウェアアーキテクチャ２００を示す。ソフトウェアアーキテクチャ２００は分散オペレーティングシステムを表しており、関連するハードウェアシステム要素１０２、１０４、１０８に対応する、システムコントローラ２２０、少なくとも１つのサイトコントローラ２４０及び少なくとも１つのモジュール２６０のための構成要素を有する。モジュール２６０に加えて、アーキテクチャ２００は、ソフトウェア内のモジュールエミュレーション２８０のための対応する構成要素を含む。
【００３５】
１つの例示的な選択として、このプラットフォームのための開発環境はマイクロソフト  ウインドウズを基にすることができる。このアーキテクチャを用いることによって、プログラム及びサポートの可搬性に関して副次的な利点がもたらされる（たとえば、フィールドサービスエンジニアが、テスタオペレーティングシステムを実行するラップトップを接続して、高度な診断を実行することができる）。しかしながら、大量のコンピュータ集約的な作業（たとえば、テストパターンコンパイル）を行うために、関連するソフトウェアは、分散プラットフォーム上でジョブをスケジューリングできるようにするために個別に実行することができる個別の実体として構成することができる。したがって、バッチジョブのための関連するソフトウェアツールは、複数のプラットフォームタイプ上で動作することができる。
【００３６】
１つの例示的な選択として、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等のベンダインプリメンテーション）を提供することを選択することもできる。その際、これらのベンダは、そのハードウェアに適したカスタム機能を提供する。 
【００６９】
次に、上記のように構成される試験装置１００におけるシミュレーション環境について説明する。
【００７０】
本実施形態における試験装置１００は、シミュレーション環境として、ＦＳＭとＬＳＭの２種類のシミュレーションモードを備える。ＦＳＭは、エミュレータ１４０上で実行される従来の試験モードであり、ＤＵＴ１１２を含む試験装置１００の動作をエミュレータ１４０で再現することにより、テストプランプログラムの検証を行う。一方、ＬＳＭは、新たな試験モードであり、ＤＵＴモデルの出力を任意にコントロールすることによって、パターンファイルのロードやＤＵＴモデルのエミュレーション等の処理を行うことなく、高速にテストプランプログラムの検証を行う。好適には、ユーザは、シミュレーションシステム１２０にテストプランプログラムをロードする際に、シミュレーションモードを選択する。
【００７１】
（ＦＳＭ）
ＦＳＭは、例えば同じ譲受人による日本特許３７３５６３６に記載されるような従来のシミュレーションモードであり、オフライン環境において、シミュレーションシステム１２０がＤＵＴ１１２の実試験を適切にエミュレートするエミュレート環境を提供する。
【００７２】
図７は、本発明の一実施形態によるＦＳＭのソフトウェアアーキテクチャ７００の一例を示す図である。ソフトウェアアーキテクチャ７００は、試験プログラム（テストプランプログラム）７０２と、オペレーティングシステム（ＯＳ）７０４と、仮想テスタ７０６と、仮想デバイス７０８と、パターンプログラム７１０と、パターンジェネレータ（ＰＧ）７１２と、パフォーマンス・ボード（ＰＢ）７１４と、デバイスプラン７１６とを含む。試験プログラム７０２とオペレーティングシステム７０４は、システムコントローラ１０２に対応する。また、仮想テスタ７０６と仮想デバイス７０８は、エミュレータ１４０に対応する。ＰＢ７１４は、ロードボード１１４に対応する。オペレーティングシステム７０４と仮想テスタ７０６及び仮想デバイス７０８との間は、通信経路７１８等を介して接続される。
【００７３】
ＦＳＭでは、試験プログラム７０２が通信経路７１８等を介して仮想テスタ７０６に渡され、仮想テスタ７０６上で動作する。仮想テスタ７０６では、まず、試験プログラム７０２の命令により、パターンプログラム７１０のオブジェクトファイルがパターンジェネレータ７１２のメモリにロードされる。その後、試験プログラム７０２中の、パターンジェネレータ７１２を動作させる命令が実行されることによって、パターンの発生が開始され、発生されたパターンは仮想デバイス７０８に入力される。仮想デバイス７０８では、ＤＵＴ１１２の論理回路に従って作成されたデバイスプラン７１６に基づいて、入力されたパターンに対する出力をシミュレートする。そして、仮想テスタ７０６は、仮想デバイス７０８の出力結果を期待値パターンと比較して、試験確認する。
【００７４】
ところで、ＦＳＭにおいては、ＣＰＵ、メモリ、ハードディスク等のストレージなどに関して、多大なリソースを必要とする。例えば、パターンプログラム７１０は通常数ギガ（Ｇ）バイトオーダーの、また、デバイスプラン７１６は数１００メガ（Ｍ）バイトオーダーの長大データであるため、パターンプログラム７１０及びデバイスプラン７１６をエミュレータ１４０にロードして、試験プログラム７０２をデバッグ可能なスタンバイ状態になるまでに１日前後の時間が必要である。また、メモリ容量の制限等により、パターンプログラム７１０、パターンジェネレータ７１２、及び仮想デバイス７０８のシミュレーションをメモリアクセスのみで行うことはできず、ストレージへのアクセスを要するため、シミュレーション自体にも時間がかかる。さらに、ＦＳＭでは、オペレーティングシステム７０４とエミュレータ１４０（仮想テスタ７０６及び仮想デバイス７０８）との間の通信スピードも遅い。こういった理由で、ＦＳＭでは、テストに一週間ほどの時間を要することになり、テストプランプログラムのデバッグ作業には多大な時間を要することになる。
【００７５】
また、ＦＳＭでは、ＤＵＴ１１２の論理回路に従って作成されたデバイスプラン７１６に基づいてエミュレーションを行う。このため、個別の試験の結果（パス／フェイル）を任意に設定することは困難である。なお、シミュレーションシステム１２０では、ＤＵＴ１１２に対して所定の試験を実行した結果、ＤＵＴ１１２からの出力結果が期待値の範囲内であれば、試験結果は「パス」であると判定する。これに対して、ＤＵＴ１１２からの出力結果が期待値の範囲外の場合、試験結果は「フェイル」であると判定する。また、通常発しない結果を発生させることができないため、テストプランプログラムの耐性を担保し難い。
【００７６】
（ＬＳＭ）
一方、ＬＳＭは、オフライン環境において、任意にテスト結果を発生させ、テストプランプログラムの動作検証をＦＳＭよりも高速に行うためのシミュレーションモードであり、オフライン環境にて、テストフローを中心とするテストプランの検証を、妥当な時間内に行う機能を提供し、かつ、オフライン環境にて、テストクラス内のほとんどの処理手順を確認する手段を提供する。
【００７７】
本実施形態では、ＬＳＭにおいて、パターンロード省略機能、テスト実行省略機能、及び試験結果注入（Response Injection）機能を備える。パターンロード省略機能は、テストプランプログラムをロードするときに、パターン内容のロードを行わないことにより、高速なロードを実現する。テスト実行省略機能は、パターンの実行とＤＣ測定をスキップし、オフラインでのテストプランプログラム実行を高速化する。試験結果注入機能は、オフラインエミュレータ上で動作するデバイスプランに対して期待値を外部から変更する機能である。これらの機能により、ＬＳＭでは、テストプランプログラム検証時に、エミュレータ１４０との通信を最小限しか行わず、ユーザが指定した試験結果データ（Response Data）に基づいて、高速にテストプランプログラムの検証を行うことができる。
【００７８】
図８は、本発明の一実施形態によるＬＳＭのソフトウェアアーキテクチャ８００の一例を示す図である。ソフトウェアアーキテクチャ８００は、試験プログラム（テストプランプログラム）８０２と、オペレーティングシステム（ＯＳ）８０４と、試験結果ＤＢ８０６と、結果適用プログラム８０８とを含む。試験結果ＤＢ８０６は、試験結果ＤＢ１３２に相当する構成であり、ユーザが設定した試験結果データファイル１３６から読み込んだ試験結果データが格納される。結果適用プログラム８０８は、実行されることによりフレームワーク１３０として機能するものであり、試験結果ＤＢ８０６に格納された試験結果データに基づいて、テストプランプログラムの動作に合わせて、テスト項目に対応するＤＵＴモデルの出力結果を返す機能を備える。
【００７９】
次に、本発明の一実施例に基づいて、ＬＳＭの試験結果注入機能について説明する。
【００８０】
図９は、本発明の一実施例におけるテストプランプログラムのテストフローを示す図である。図９に示すように、本実施例のテストプランプログラムは、５種類のテスト項目（テスト９０１、テスト９０２、テスト９０３、テスト９０４、及びテスト９０５）により構成される。このテストプランでは、まず、ＤＵＴに対してテスト９０１を実行する。その後、テスト９０１をパスすればテスト９０２を実行し、テスト９０２をパスすればテスト９０３を実行し、テスト９０３をパスすればテスト９０５を実行する。また、テスト９０１、９０２、９０３のいずれかでフェイルしたときには、テスト９０４を実行し、最後にテスト９０５を実行する。
【００８１】
図１０は、図９に示すテストプランプログラムをＬＳＭで検証するための試験結果データの一例を示す図である。図１０に示す試験結果データでは、４つの異なる特性を有するデバイスが想定され、各デバイス毎に個別のテストの試験結果が設定されている。ケースＡは、テスト９０１、９０２、９０３のいずれをもパスするデバイスを想定している。ケースＢは、テスト９０１と９０２をパスするが、テスト９０３をフェイルするデバイスを想定している。ケースＣは、テスト９０１をパスするが、テスト９０２をフェイルするデバイスを想定している。ケースＤは、テスト９０１をフェイルするデバイスを想定している。
【００８２】
なお、試験結果データには、少なくともフェイルのテスト箇所を指定することが好ましい。このとき、フェイル指定されていないテスト項目は、パスするものとみなす。すなわち、図１０に示す例では、ケースＡは全てのテスト項目をパスするので、何も指定する必要はない。ケースＢでは、テスト９０３をフェイルする旨を指定する。ケースＣでは、テスト９０２をフェイルする旨を指定する。また、ケースＤでは、テスト９０１をフェイルする旨を指定する。そして、テストプランプログラムを検証する際、結果適用プログラム８０８は、所定のテスト項目に対して試験結果ＤＢ８０６を参照して、当該テスト項目がフェイル指定されている場合には、当該テスト項目に対するデバイスの出力結果としてフェイルを注入する。一方、何も指定されていない場合には、そのテスト項目に対するデバイスの出力結果としてパスを注入する。
【００８３】
次に、図８乃至図１０に示す実施例に基づいて、ＬＳＭの動作を説明する。まず、ユーザは、検証しようとするテストプランプログラムのテストフローに応じて、試験結果データを作成しておく。図９に示すテストプランでは、想定されるテストの経路が４通り考えられるので、試験結果データとして、図１０に示すように、４通りの経路を網羅するような４つの仮想デバイスを想定することが好ましい。そして、テストプランプログラム８０２がフレームワーク１３０にロードされるとともに、試験結果データが試験結果ＤＢ８０６にロードされた後、ＬＳＭによるシミュレーションが実行される。ＬＳＭでは、テストプランプログラムの動作に応じて、ＯＳ８０４を介してデバイスの出力結果を取り込む。この出力結果としては、結果適用プログラム８０８が試験結果ＤＢ８０６を検索することにより、パス又はフェイルのいずれかが注入される。テストプランが複数のテスト経路を有し、試験結果データとして複数の仮想デバイスが想定されている場合には、仮想デバイスを順次取り替えて検証を行うことによって、複数のテスト経路の検証を行うことができる。
【００８４】
例えば、本実施例では、まず、仮想デバイスとしてケースＡが設定され、テストプランプログラムが動作する。すると、テスト９０１が実行され、テスト９０１に対するデバイスの出力結果としてパスが注入される。図９に示すように、このテストプランプログラムでは、テスト９０１にパスすると、テスト９０２に移行し、テスト９０２が実行される。そして、テスト９０２に対するデバイスの出力結果としてパスが注入され、テスト９０３に移行する。ケースＡでは、テスト９０３に対する出力結果もパスが注入され、テスト９０５に移行する。こうして、ケースＡでは、全てのテスト項目にパスする経路が検証される。
【００８５】
続いて、仮想デバイスとしてケースＢが設定され、同様にテストが行われる。ケースＢでは、テスト９０１に対してパスが注入され、テスト９０２に移行し、テスト９０２に対してパスが注入され、テスト９０３に移行する。ケースＢでは、テスト９０３に対してフェイルが注入され、テスト９０４に移行する。こうして、ケースＢでは、テスト９０３でフェイルする経路が検証される。
【００８６】
次に、仮想デバイスとしてケースＣが設定され、同様にテストが行われる。ケースＣでは、テスト９０１に対してパスが注入され、テスト９０２に移行するが、テスト９０２に対してフェイルが注入され、テスト９０４に移行する。こうして、ケースＣでは、テスト９０２でフェイルする経路が検証される。
【００８７】
最後に、本実施例では、仮想デバイスとしてケースＤが設定され、同様にテストが行われる。ケースＤでは、テスト９０１に対してフェイルが注入され、テスト９０４に移行する。こうして、ケースＤでは、テスト９０１でフェイルする経路が検証される。
【００８８】
以上のように、ＬＳＭでは、テストプランプログラムの検証の際に、パターンプログラム等をロードする必要がなく、また、ＤＵＴモデルのエミュレーションを行う必要もないので、ＦＳＭよりも高速に検証作業を行うことができるようになる。また、テストプランプログラムは、複数のテスト項目が存在して複数の分岐が存在するため、複数のテスト経路が存在することが一般的であるが、ＬＳＭでは、ユーザがテスト項目毎に出力結果を任意に指定できる。そのため、ユーザは、任意の分岐やテスト経路を容易に検証できる。また、ユーザは、想定される全てのテスト経路を網羅する試験結果データを作成することにより、テストプランの全テストフローを容易に検証することができる。
【００８９】
図１１は、本発明の一実施形態によるＬＳＭのソフトウェアアーキテクチャ１１００の他の一例を示す図である。ソフトウェアアーキテクチャ１１００は、試験プログラム（テストプランプログラム）１１０２と、オペレーティングシステム（ＯＳ）１１０４を含み、また、ＯＳの外部に試験結果ＤＢ１１０６と結果適用プログラム１１０８とを備え、通信経路１１１０によって接続される。図１１に示すソフトウェアアーキテクチャでもＬＳＭを実行可能であるが、試験結果ＤＢ１１０６と結果適用プログラム１１０８を、ＯＳの外部（例えば、エミュレータ１４０）に持たせる構成となるため、図８のようにＯＳ内部に試験結果ＤＢ１１０６と結果適用プログラム１１０８を持たせる場合よりも、処理スピードは劣ることになる。
【００９０】
（デバイス特性測定結果の利用）
以上のように、ＬＳＭでは、所定のテスト経路を検証するための試験結果データを任意に作成可能である。これは、ＬＳＭにおいて、検証用のＤＵＴモデルとして、所望の特性を有するデバイスを任意に設定可能であることを意味する。このとき、デバイス特性は、ユーザが明示的に設定してもよいが、試験装置１００で実デバイスの特性を測定した結果を利用してもよい。すなわち、試験装置１００で実デバイスの特性を測定し、この測定結果に基づいて試験結果データを作成することによって、ＬＳＭでテストプランプログラムの検証を行う際に、実デバイスと同じ特性を備えるデバイスを再現できる。
【００９１】
図１２及び図１３を参照しつつ、この実デバイス測定結果をＬＳＭに反映させる処理について説明する。図１２は、本発明の一実施形態による、実デバイスの測定結果をオフライン環境で再現する処理の流れを示すフローチャートである。また、図１３は、電圧と周波数により構成されるデバイス特性空間の任意のポイントにおける期待値の一例を示す図である。
【００９２】
まず、試験装置１００をオンライン環境で使用して、実デバイス（ＤＵＴ）の特性を測定する（Ｓ１２０１）。そして、測定結果の中から、試験結果データの作成に必要なものを適宜取得し（Ｓ１２０２）、取得した測定結果に基づいて試験結果データを作成し、試験結果データファイルに保存する（Ｓ１２０３）。
【００９３】
例えば、ある実デバイスを測定したとき、電圧２．５Ｖで周波数１００ＭＨｚのときの測定結果が「Ｐ（パス）」であった場合、この測定結果に基づいて、電圧２．５Ｖで周波数１００ＭＨｚのときの試験結果が「Ｐ（パス）」となる試験結果データが作成される。さらに、実デバイスの測定結果を利用して、図１３に示すように、デバイス特性空間の任意のポイントにおける期待値（パス／フェイル）をマトリクス状に設定した試験結果データを作成することもできる。なお、図１３には、試験結果データを２次元のマトリクス状に設定する例を示したが、試験結果データは１次元又は２次元以上のマトリクス状に設定可能である。
【００９４】
次に、試験装置１００をオフライン環境で使用して、テストプランの検証を行う。まず、シミュレーションシステム１２０上にてオンライン測定で作成した試験結果データファイルをロードする（Ｓ１２０４）。そして、テストプランプログラムをロードし（Ｓ１２０５）、その後、ロードしたテストプランプログラムを実行すると（Ｓ１２０６）、オフライン環境において、実デバイスと同様の試験結果が再現される（Ｓ１２０７）。
【００９５】
例えば、先の例では、オフライン環境でのシミュレーションにおいて、テストプランプログラムを実行すると、電圧２．５Ｖで周波数１００ＭＨｚのとき、ＤＵＴモデル（デバイス）からの出力は、実デバイスと同様に、「Ｐ（パス）」となる。これにより、実デバイスの測定結果に基づいて試験結果データを作成することにより、実デバイスの測定結果をＬＳＭで再現することができるようになる。
【００９６】
こうして、本実施形態では、オンライン環境で実デバイスから取得した測定結果をオフライン環境にて再現し、テストプランプログラムの検証を行うことができる。実デバイスにおいては、図１３に示すように、電圧特性により周波数特性がリニアに定まるとは限らない。そこで、実デバイスから取得した測定結果を使ってテストプランプログラムの検証を行うことにより、試験結果データを実デバイスと同じように作成することができる。
【００９７】
また、実デバイスから取得した測定結果を適宜修正することにより、所望のテスト項目でフェイルするデバイスを任意に設定することができる。これにより、ユーザが自由に不良品や故障品を紛らした状態の試験結果データを作成し、テストプランプログラムの検証を行うことができる。なお、本実施形態では、デバイス特性の一例として、電圧と周波数を例示したが、デバイス特性はこの２項目に限られず、他にも任意の特性を任意数利用できることは言うまでもない。
【００９８】
以下、本実施形態に係るシミュレーションシステム１２０の試験結果注入機能を実現するための具体的な仕様例を説明する。
【００９９】
（試験結果注入機能の概要）
試験結果注入機能は、ＤＵＴ出力のパターン指定、ＤＵＴ出力のパラメータ指定、パターンとパターンリストのフェイル指定、バーストパターン（Burst Pattern）のフェイル指定、ＤＣ測定結果の強制指定、テストインスタンス（Test Instance）実行結果の強制指定等の機能を備える。ＤＵＴ出力のパターン指定とＤＵＴ出力のパラメータ指定は、ＤＵＴの振る舞いを入力する機能である。これを入力することで、現実のＤＵＴの動作に即したオフライン・デバッグが可能となる。
【０１００】
（試験結果データの設定）
試験結果データは、テストプランプログラムＤＬＬ１３４をロードするタイミングで試験結果データファイル１３６を指定し、試験結果ＤＢ１３２にロードされる。また、システムコントローラ１０２の入力手段を介して試験結果データファイル１３６のロードを明示的に行ってもよい。さらに、ＬＳＭ制御用のスクリプトコマンドで、試験結果データのロード、追加、又は削除を行ってもよいし、ＡＰＩ関数で試験結果データファイル１３６をロードしてもよい。
【０１０１】
（試験結果データの構造）
試験結果データを設定するために、以下の３つの機能を使って、任意の試験結果データを、任意のタイミングで設定できる。まず、１個の試験結果データを設定できる試験結果データの指定機能である。次に、試験結果データをグルーピングする試験結果グループの定義機能である。このとき、ＤＵＴへ試験結果データを適用（反映）できる単位は、試験結果グループである。最後に、サイトコントローラ１０４間ＤＵＴ同時測定、及びサイトコントローラ１０４内ＤＵＴ同時測定で、それぞれ対象となるＤＵＴ毎に異なる試験結果データ指定が可能なＤＵＴ定義機能である。ＤＵＴ予約語とソケットファイル（Socket File）で定義したＤＵＴ番号を使用して、ＤＵＴ毎に、DUTFlow/Flowと試験結果グループの対応が定義できます。つまり、ＤＵＴ毎に独立したDUTFlow/Flowと試験結果グループの割り当てが実現できる。
【０１０２】
ＤＵＴ定義機能では、ソケットファイルで定義したＤＵＴと試験結果グループを結びつけることができる。つまり、どのＤＵＴにどの試験結果グループを適用するかを指定できる。このＤＵＴ定義の特徴を以下に示す。
【０１０３】
第一に、ＤＵＴ定義に指定するＤＵＴ番号は、ソケットファイルで定義したＤＵＴ番号を指定する。指定したＤＵＴに対する試験結果を指定できる。試験結果指定の対象とするＤＵＴには、このＤＵＴ定義を定義する必要がある。ＤＵＴ定義が無いＤＵＴにはデフォルトの試験結果で動作する。
【０１０４】
第二に、試験結果グループの割付は、ＯＴＰＬ言語のDUTFlow/Flow識別子に対して行う。このためDUTFlow/Flowインスタンス毎に、任意の試験結果グループを割り付けることができる。対象のDUTFlow/Flowインスタンスはサブフローとして扱われているものでも問題ない。サブフローで試験結果データ（ApplySequence）の記述が無い場合には上位のフローからレスポンスデータが継承される。
【０１０５】
第三に、実行中のフローアイテムからみて、DUTFlow/Flowインスタンスへの指定が２つ以上、同時に当てはまる場合は、最後に適用が決まった試験グループだけを適用する。
【０１０６】
第四にDUTFlow/Flowインスタンスには、複数の試験結果グループを割り付けることができる。指定のDUTFlow/Flow インスタンスの実行が完了するたびに、順番に一つずつ適用する試験結果グループが進む。最後の試験グループを適用すると、再び、先頭の試験グループに戻ります。
【０１０７】
最後に、サイトコントローラ１０４内同時測定ＤＵＴ間および、サイトコントローラ１０４間のＤＵＴ間での異なる試験結果データ指定をする。つまり、サイトコントローラ１０４に関係なく、各ＤＵＴに対して任意の試験結果グループを指定できる。
【０１０８】
（ＤＵＴ出力のパターン指定）
ＬＳＭでは、ＤＵＴ出力パターンを記述できる。これは、パターンファイルの期待値と同等のものと考えることができるが、ＬＳＭでは、試験結果データとして入力可能である。このＤＵＴ出力パターンの指定機能は、次の振る舞いに影響を与える。
【０１０９】
第一に、パターンとパターンリストのフェイル指定でフェイルが発生するが、このフェイルの種類が影響を受ける。Ｈ比較用ストローブがフェイルか、もしくは、Ｌ側のフェイルかが変わる。
【０１１０】
第二に、DFMで取得できるデータに影響する。DFMのフェイル指定の位置のキャプチャデータに対して、Ｈ側がフェイルか、もしくは、Ｌ側がフェイルかが変わる。
【０１１１】
つまり、ＤＵＴ出力のパターン指定の指定値が、直接的にＬＳＭの結果に影響を与えるものではない。あくまで、パターンとパターンリストのフェイル指定機能、もしくは、DFMのフェイル指定と組み合わせて、意味を持つ。
【０１１２】
ＤＵＴ出力のパターン指定には、もともと規定値（デフォルト値）がある。このデフォルト値は「Ｈ」である。ユーザ指定が何も無い状態でも、試験結果注入機能が動作する全てのベクトルアドレス空間をデフォルト値が満たしている。なお、ユーザがピン毎にデフォルト値を指定することもできる。この記述は、試験結果データとして入力可能である。
【０１１３】
さらに、ユーザがＤＵＴ出力のパターン指定を明示的に行う機能がある。これには、ＤＵＴ出力のパターン指定の開始箇所と、開始箇所からのＤＵＴ出力の羅列の２つの指定を行う必要がある。
【０１１４】
本実施形態において、ＤＵＴ出力のパターン指定には、「Ｈ」、「Ｌ」、及び「Ｚ」の出力キャラクタを指定可能である。「Ｈ」は、デジタル信号で１に相当する信号が出力される。「Ｌ」は、デジタル信号で０に相当する信号が出力される。「Ｚ」は、デバイス出力抵抗がハイ・インピーダンス相当である。
【０１１５】
なお、１キャラクタが、テスタ側の１回の期待値比較で使用される。そのため、ピンあたりで１テスト・サイクルに複数回の比較がある場合には、１テスト・サイクルに比較回数分のＤＵＴ出力キャラクタが必要となる。実際にＤＵＴ出力を記述する場合は、出力キャラクタを、一度に複数、羅列することが可能である。出力キャラクタ指定数に制限はない。
【０１１６】
（ＤＵＴ出力のパラメータ指定）
【０１１７】
ＤＵＴ出力のパラメータ指定では、ＤＵＴのある特定条件における試験結果を定義できる。つまり、任意の条件下でのみ有効な試験結果を個別に定義できる。この条件には、テスタ・モジュール内の予め定められたパラメータを使用できる。
【０１１８】
以下に、動作原理を示す。この機能の使用者は、入力パラメータを１つ、または、２つ指定する。この指定した入力パラメータに対する挙動を試験結果グループを指定することによって定義する。これには任意の試験結果グループを指定できる。
【表１】
2009116876.tif 000003
【０１１９】
表１に示す例では、RDGroupで試験結果データが定義されている「TestItem1」Test Instanceに対してＤＵＴ出力のパラメータ指定が可能となる。「InputPins」ピンにおいて、VForceが1.2Vの場合で、かつ、「Domain1」ドメインのPeriodが10nsecである場合に、パターンの実行結果がフェイルする。
【０１２０】
詳細は次のとおり。入力パラメータを指定するには、予約語のXParam、YParamを使用する。２つまで同時に指定可能である。１つだけ使用する場合は、XParamを使用する。また、ハードウェア・パラメータの指定は、pin, pin group, domain に対して行う。さらに、入力パラメータには、テスタのハードウェア・パラメータ、OTPLのSpecificationSet内定義変数、またはOTPLのユーザ定義変数を指定できる。指定可能入力パラメータは、例えば、ハードウェア・パラメータとして、DPSの電圧値、Test Period値、Digital ModuleのOutput Pin(Comparator Pin)の比較電圧値(VOH,VOL)、Digital ModuleのInput Pinの出力電圧(VIH,VIL)、Timing EdgeのTiming値等であり、定義した変数として、参照できるユーザ定義変数の１つである。
【０１２１】
なお、入力パラメータを２つ指定する場合の組み合わせに制限はない。また、入力条件が成立した場合には任意の試験結果グループが一つだけ適用される。
【０１２２】
また、入力するパラメータと試験結果である試験結果グループの関係を連続的に定義することができる。表１で説明したＤＵＴ出力のパラメータ指定では、一点での挙動を定義したが、あるパラメータ範囲内での連続的なＤＵＴの振る舞いを指定する連続入力機能を備えることもできる。
【０１２３】
連続入力の機能は以下のとおり。入力パラメータには、開始値、ステップ値、ステップ数を指定する。入力パラメータのそれぞれに対応した試験結果の指定が必要である。なお、試験結果グループの指定数がステップ数よりも少ない場合は、最後に適用した試験結果グループが適用され続ける。同じ試験結果グループを連続して簡便に指定することができる。これには、連続指定記述子を用いる。ステップ間隔と開始値には負数を使用してもよい。２つの入力パラメータを指定した場合における、TargetResponse指定順は、まず、YParamの初期値に対して、XParamに対するものを全ステップ分記述する。続けてYParamの次のステップ値に対して、XParamを全ステップ分記述する。TargetResponseのブロック内で改行が入っても構わない。
【０１２４】
これらのパラメータを、１次元形式の場合は一つ指定できる。また２次元形式で指定する場合は、これらの中から、任意の２つの組み合わせを適用できる。表２にこの例を示す。
【表２】
2009116876.tif 000004
【０１２５】
図１４は、表２に示す例において注入される試験結果の一例を示す図である。図１４に示すとおり、連続指定機能では、指定した試験結果グループが連続的に有効である。次のステップ点までは直近の試験結果グループが有効である。たとえば、15.1nsecのPeriodを表２に示す例に適用すると、「PatPass」試験結果グループが有効であり、パターン実行結果はパスとなる。
【０１２６】
また、表３に示すように、入力データを２つ用意し、さらに、試験結果データのキャラクタマップ機能を使用すれば、ＤＵＴの挙動を二次元Shmoo形式で試験結果データとして入力することが可能である。
【表３】
2009116876.tif 000005
【０１２７】
キャラクタマップ機能では、CharMap予約語を使用して任意の試験結果グループをキャラクタ、もしくは、正数にマップできる。マップしたキャラクタはそのTargetResponse内で使用できる。
【０１２８】
（パターンとパターンリストのフェイル指定）
パターンとパターンリストのフェイル指定は、パターンリストファイルとパターンファイルを基点にし、任意の場所にフェイルを強制指定する方法である。指定個数に制限はない。
【０１２９】
この機能によって、テストプランプログラム内の動作において、特定パターンのフェイルを発生させることができる。このとき、任意のPin,Domain,やCycle,Address,Labelを指定してフェイルを発生させることもできる。また、特定パターンリストのフェイルを発生させることができる。このとき、任意の所属パターンのPin,Domain,やCycle,Address,Labelを指定してフェイルを発生させることもできる。さらに、DFM内容へのフェイルを指定できる。
【０１３０】
このDFM内容へのフェイル指定機能は、特定パターン、特定パターンリストへのフェイル発生機能の拡張機能である。例えば、特定パターン、特定パターンリストでフェイルを発生させれば、DFMの該当する箇所にもフェイルが記録されるが、さらに、積極的に、DFM内容をコントロールすることができる。パターンとパターンリストのフェイル指定は、フェイルを発生させるための機能である。ＤＵＴ出力のパターン指定におけるＤＵＴの出力内容によって、何の理由でフェイルしたかの内容が決定される。
【０１３１】
（パターンとパターンリストへのフェイル発生機能）
テストプランプログラムのロード直後、もしくは、試験結果データのロード直後に、結果を指定する箇所が確定する。この機能の指定方法を示す。期待できる試験結果としては、対象パターンリストのトータル・フェイルとピン・フェイルである。
【０１３２】
パターンとパターンリストのフェイル指定では、フェイル場所の指定条件が最も複雑な単一の機能を応用して、全てのフェイル場所指定を実現する方式をとる。ピン、パターンリスト内の特定パターン、アドレス指定の３つの指定、もしくは、ピン、パターンリスト内の特定パターン、サイクル指定の３つの指定の、合計２つの機能のみを用意する。これらをパターン指定の基本機能と呼ぶ。このパターン指定の機能を応用することで、見かけ上、ユーザは自由な単位で指定ができるようになる。
【０１３３】
ピンの結果取得関数は、ＤＵＴ出力のパターン指定に影響を受ける。フェイル発生場所リストに対応するＤＵＴ出力のパターン指定のキャラクタ値と、その結果値をまとめると、次のとおり。フェイル対象場所のＤＵＴ出力が「Ｈ」である場合には、 PinResultHighFailで結果が取得される。また、フェイル対象場所のＤＵＴ出力が「Ｌ」である場合には、PinResultLowFailで結果が取得される。さらに、フェイル対象場所のＤＵＴ出力が「Ｚ」である場合には、PinResultHighFailで結果が取得される。
【０１３４】
（DFMへのフェイル指定）
ＬＳＭでは、DFMのキャプチャ・データに対して、フェイルが発生する箇所を試験結果データで指定可能である。この機能は、パターンとパターンリストへのフェイル発生機能と同じ機能であるが、複数のフェイル発生を一度に指定できる点が異なる。複数のフェイル発生位置を指定することで、DFMの取得内容を制御する機能として使用できる。フェイル指定された箇所に対するDFMで取得できるデータ内容は、ＤＵＴ出力のパターン指定の結果を反映する。例えば、ＤＵＴ出力のパターン指定の内容が「Ｈ」であり、その場所にフェイルが指定されると、Ｈ比較用ストローブがフェイルしたデータを取得できる。なお、指定した以外の箇所は全てパス扱いで、それに相当するデータを取得できる。
【０１３５】
フェイル指定を実現するには、フェイルを発生させる開始箇所の指定と、フェイル発生場所リストの指定を行う必要がある。フェイルを発生させる開始箇所の指定は、パターンとパターンリストのフェイル指定で示した機能を使用する。これに、フェイル発生場所リストの羅列指定を加えることで、DFMへのフェイル指定が実現できる。フェイル発生場所リストの指定が無い場合は、指定場所の１比較のみフェイル指定した動作と同等となる。
【０１３６】
次に、フェイル発生場所リストの指定方法を示す。フェイル指定方法は、開始箇所を０番目とし、何番目にフェイルが発生しているかの数値を列挙する方式である。一つの指定に対し、複数個の指定が可能である。指定方法の例を示します。
【０１３７】
図１５は、本発明の一実施形態によるフェイル指定の一例を示す図である。図１５において、リストはpositions表記の６−８を指し、１比較はpositions表記の２を指している。
【０１３８】
DFMへのフェイル指定では、さらに、次の機能がある。
【０１３９】
DFMへのフェイル指定は、Test Item内のTotal Resultや、Pin Resultへ影響を与える。バースト実行単位やPin単位では、DFM上のフェイルとつじつまが合うように、フェイルを発生する。
【０１４０】
DFMへのフェイル指定で取得できるフェイルの種類は、ＤＵＴ出力のパターン指定におけるＤＵＴの出力指定に依存する。ＤＵＴ出力の明示的な指定が無い場合には、ＤＵＴ出力指定のデフォルト値である「Ｈ」出力に対するフェイルが発生する。つまり、DFMで検出できるフェイルの種類は「Ｈ」フェイルとなる。
【０１４１】
（ＤＣ測定結果の強制指定）
DPS、PMUでのＤＣ測定結果の強制指定では、ＤＣ測定結果の電圧値、電流値を試験結果データから指定できる。また、電流サンプリングの値を複数、配列形式で指定できる。ここで、複数の測定値を、配列データとして与えた場合は電流サンプリングの値として取得できる。異なる使い方として、これを電圧測定、電流測定の一回の測定値としても取得できる。その場合、測定の度に先頭から順次、指定値を測定値として採用する。
【０１４２】
電圧および電流の測定結果の強制指定では、試験結果データの指定が無い場合に、デフォルト値が存在し、それぞれ電圧測定に対しては0V、電流測定に対しては0Aであることが好ましい。電流サンプリングデータは全て0A で、１個数分取得できる。また、パス／フェイル判定のデフォルト値はパスであることが好ましい。なお、そのTest Instance に一つでもＤＣ値の試験結果データが設定された場合は、デフォルト値が無くなり、取得したＤＣ値での判定となる。
【０１４３】
（Test Instance実行結果の強制指定）
ＬＳＭでは、Test Instance実行結果の強制指定が可能である。Test Instance名を指定して、それに対して、Test Instance実行結果である、Result Statusを指定できる。
【０１４４】
なお、本発明は、上記した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内において、他の様々な形で実施することができる。このため、上記実施形態はあらゆる点で単なる例示にすぎず、限定的に解釈されるものではない。例えば、上述の各処理ステップは処理内容に矛盾を生じない範囲で任意に順番を変更して又は並列に実行することができる。
【図面の簡単な説明】
【０１４５】
【図１】従来のテスタの一般化されたアーキテクチャを示す図である。
【図２】本発明の一実施形態による試験装置１００のシステムアーキテクチャを示す。
【図３】本発明の一実施形態によるシミュレーションシステム１２０の概略構成を示すブロック図である。
【図４】本発明の一実施形態によるソフトウェアアーキテクチャ２００を示す図である。
【図５】本発明の一実施形態による試験プログラムコンパイラを示す図である。
【図６】本発明の一実施形態による単一の試験クラスから種々の試験インスタンスを如何に導出することができるかを示す図である。
【図７】本発明の一実施形態によるＦＳＭのソフトウェアアーキテクチャ７００の一例を示す図である。
【図８】本発明の一実施形態によるＬＳＭのソフトウェアアーキテクチャ８００の一例を示す図である。
【図９】本発明の一実施例におけるテストプランプログラムのテストフローを示す図である。
【図１０】図９に示すテストプランプログラムをＬＳＭで検証するための試験結果データの一例を示す図である。
【図１１】本発明の一実施形態によるＬＳＭのソフトウェアアーキテクチャ１１００の他の一例を示す図である。
【図１２】本発明の一実施形態による、実デバイスの測定結果をオフライン環境で再現する処理の流れを示すフローチャートである。
【図１３】本発明の一実施形態による、電圧と周波数により構成されるデバイス特性空間の任意のポイントにおける期待値の一例を示す図である。
【図１４】表２に示す例において注入される試験結果の一例を示す図である。
【図１５】本発明の一実施形態によるフェイル指定の一例を示す図である。
【符号の説明】
【０１４６】
１００ 試験装置
１０２ システムコントローラ
１０４ サイトコントローラ
１０６ モジュール接続イネーブラ
１０８ モジュール
１１０ 試験サイト
１１２ 被試験デバイス（ＤＵＴ）
１１４ ロードボード
１２０ シミュレーションシステム
１３０ フレームワーク
１３２ 試験結果データベース
１３４ テストプランプログラムＤＬＬ
１３６ 試験結果データファイル
１３８ モジュールドライバ
１４０ エミュレータ
８００ ソフトウェアアーキテクチャ
８０２ テストプランプログラム
８０４ オペレーティングシステム（ＯＳ）
８０６ 試験結果データベース
８０８ 結果適用プログラム
【図１】
2009116876.tif 000006
【図２】
2009116876.tif 000007
【図３】
2009116876.tif 000008
【図４】
2009116876.tif 000009
【図５】
2009116876.tif 000010
【図６】
2009116876.tif 000011
【図７】
2009116876.tif 000012
【図８】
2009116876.tif 000013
【図９】
2009116876.tif 000014
【図１０】
2009116876.tif 000015
【図１１】
2009116876.tif 000016
【図１２】
2009116876.tif 000017
【図１３】
2009116876.tif 000018
【図１４】
2009116876.tif 000019
【図１５】
2009116876.tif 000020