JP2007052028A - 集積回路をテストする方法および装置 - Google Patents

集積回路をテストする方法および装置 Download PDF

Info

Publication number
JP2007052028A
JP2007052028A JP2006252498A JP2006252498A JP2007052028A JP 2007052028 A JP2007052028 A JP 2007052028A JP 2006252498 A JP2006252498 A JP 2006252498A JP 2006252498 A JP2006252498 A JP 2006252498A JP 2007052028 A JP2007052028 A JP 2007052028A
Authority
JP
Japan
Prior art keywords
test
operating system
module
site
site controller
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
JP2006252498A
Other languages
English (en)
Other versions
JP2007052028A5 (ja
Inventor
Ankan Pramanick
プラマニック、アンカン
Mark Elston
エルストン、マーク
Leon Chen
チェン、リーオン
Robert Sauer
サウアー、ロバート
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Advantest Corp
Original Assignee
Advantest Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US10/404,002 external-priority patent/US7460988B2/en
Priority claimed from US10/403,817 external-priority patent/US7290192B2/en
Application filed by Advantest Corp filed Critical Advantest Corp
Publication of JP2007052028A publication Critical patent/JP2007052028A/ja
Publication of JP2007052028A5 publication Critical patent/JP2007052028A5/ja
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/319—Tester hardware, i.e. output processing circuits
    • G01R31/31903—Tester hardware, i.e. output processing circuits tester configuration
    • G01R31/31907—Modular tester, e.g. controlling and coordinating instruments in a bus based architecture
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/26—Testing of individual semiconductor devices
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/3183—Generation of test inputs, e.g. test vectors, patterns or sequences
    • G01R31/318307—Generation of test inputs, e.g. test vectors, patterns or sequences computer-aided, e.g. automatic test program generator [ATPG], program translations, test program debugging
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/3183—Generation of test inputs, e.g. test vectors, patterns or sequences
    • G01R31/318342—Generation of test inputs, e.g. test vectors, patterns or sequences by preliminary fault modelling, e.g. analysis, simulation
    • H—ELECTRICITY
    • H01—ELECTRIC ELEMENTS
    • H01L—SEMICONDUCTOR DEVICES NOT COVERED BY CLASS H10
    • H01L22/00—Testing or measuring during manufacture or treatment; Reliability measurements, i.e. testing of parts without further processing to modify the parts as such; Structural arrangements therefor

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Manufacturing & Machinery (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Power Engineering (AREA)
  • Tests Of Electronic Circuits (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)
  • Non-Volatile Memory (AREA)

Abstract

【課題】テストの要件に応じて再構成可能であるテスタを提供する。
【解決手段】自動テスト機器（ATE）のような半導体テストシステム用の分散オペレーティングシステムが記載されている。このオペレーティングシステムは、システムコントローラによる一つ以上のサイトコントローラの制御を可能にするホストオペレーティングシステムを有している。一つ以上のローカルオペレーティングシステムは、それぞれがサイトコントローラに関連しており、関連しているサイトコントローラによる一つ以上のテストモジュールの制御を可能にする。各テストモジュールは、テストサイトにおいて対応するテスト対象装置上でテストを行う。
【選択図】図２

Description

本出願は、2003年2月24日に出願された出願第60/449,622号「集積回路をテストする方法および装置」、2003年2月14日に出願された出願第60/447,839号「半導体集積回路用のテストプログラムを展開する方法および構造」、2003年3月31日に出願された米国出願第10/404,002号「テストエミュレータ、テストモジュールエミュレータおよびプログラムを記憶する記録媒体」、および2003年3月31日に出願された米国出願第10/403,817号「テスト装置およびテスト方法」の恩恵を受けることを主張する。これらの出願は全体としてここに援用される。また本出願は、2003年2月14日に出願された出願第60/447,839号「半導体集積回路用のテストプログラムを展開する方法および構成」の恩恵を受けることを主張する同時に出願された米国出願第10/772,434号「半導体集積回路用のテストプログラムを展開する方法および構成」も全体的に援用する。
本発明は、集積回路（IC）のテストに関連する。特に本発明は、一つ以上のICをテストする自動テスト機器（ATE）に関連する。
システムオンチップ（SOC）装置がより複雑になりチップのテストのコストを削減する要求が出てくるにつれて、IC製造者およびテスタのベンダはともに、どのようにICのテストを行うべきかを考え直すことを余儀なくされている。産業の研究によると、リエンジニアリングをしなければ、テスタの予想されるコストは、しばらくは劇的に上昇し続けるであろう。
テスト機器のコストが高い主な理由には、従来のテスタアーキテクチャの専門化した性質があげられる。それぞれのテスタ製造業者は、アドバンテスト、テラダイン、アジリエントといった会社間で互換性がないだけではなく、アドバンテストによって製造されたT3300、T5500およびT6600シリーズのテスタのようなプラットフォーム間でも互換性のないテスタプラットフォームを数多く有している。このように互換性がないために、各テスタは、他のテスタでは用いることができないそれ自身の特化したハードウェアおよびソフトウェアコンポーネントを必要とする。また、一つのテスタから他のテスタにテストプログラムを移植するのに多大な変換の手間が必要であり、サードパーティソリューションを開発するのは困難である。一つのプラットフォームから他のプラットフォームへの変換プロセスは、一般的に、複雑で間違いを起こしやすく、その結果よけいな手間、時間がかかり、テストのコストが増加することになる。
オペレーティングシステムおよびテスト解析ツール／アプリケーションのようなテスタのソフトウェアはホストコンピュータ上で動く。そのアーキテクチャの専用的な性質のために、すべてのハードウェアおよびソフトウェアは、任意のテスタに対して固定された構成のままである。ICをテストするためには、テスタの能力のいくらか、あるいはすべてを用いる専用のテストプログラムを展開して、テストデータ、信号、波形、ならびに電流および電圧レベルを定義するとともに、DUT応答を集めたり、DUTの合格／不合格を決めたりする。
テスタは幅広いICをテストすることができなければならないので、ハードウェアおよびソフトウェアコンポーネントは両方とも、幅広い動作範囲で動作するように設計される。したがって、テスタは多くのテストの状況下で用いられることのないリソースを多く含んでいる。同時に、任意のICに対して、テスタは、そのICに適した最も望ましいリソースを提供し得ないかもしれない。例えば、内蔵のマイクロコントローラ、大きな内蔵DRAMおよびフラッシュ、ならびにPCIやUSB等のようなさまざまな他のコアを含む複雑なSoC Aをテストするのに適しているロジックテスタは、内蔵マイクロコントローラおよび大きな内蔵DRAM／フラッシュを有してはいないが、DACおよびシグマ−デルタコンバータを有しているASIC Bには不適切であることが判明するかもしれない。ASIC Bをテストするためには、それにふさわしいテスタは、内蔵メモリのテストのための広範囲なサポートよりも、むしろアナログおよび混合された信号のテストユニットを必要とするであろう。
したがって、テストの要件に応じて再構成可能であるテスタを提供することが望ましい。また、ATEと関連して他のベンダの機器と接続し、それを用いることが望ましい。しかしながら、従来のテストシステムの特化した性質と、各ベンダの機器のデータフォーマットの独自仕様というような性質とのために、他のベンダからの機器を差し込んで用いることはしばしば不可能である。
発明の一実施形態によるオープンアーキテクチャのテストシステムは、サードパーティモジュールの使用を許容する。このテストシステムのハードウェアおよびソフトウェアフレームワークは、異なるベンダからのモジュールがプラグアンドプレイの要領で相互作用し得る標準的なインタフェースを有する。モジュールは、機能ユニット、デジタルピンカード、アナログカード、あるいは装置電源のようなハードウェア、または、テスト実行ツール、システムモニタあるいはライセンスツール、ユニットレベルコントローラ（例えばベース機器、GPIB制御）、データベース、あるいは他の機器の制御のためのソフトウェアのようなツールまたはユーティリティのようなソフトウェアであってもよい。
一実施形態において、アーキテクチャは、マイクロソフトウィンドウズオペレーティングシステム下の分散オブジェクト環境である。テスタは、モジュールとモジュールとの通信だけでなく、コントローラとモジュールとの通信をも可能にするモジュール制御ソフトウェアとバックプレーン通信ライブラリとを有するモジュール化されたシステムである。モジュールは、例えば、デジタルモジュール、装置電源（DPS）モジュール、任意波形発生器（AWG）モジュール、デジタイザモジュールおよびアプリケーション特有のソフトウェアを含む。
一実施形態において、モジュール接続イネーブラは、マルチモジュール接続および同期メカニズムを提供するスイッチマトリクスネットワークを備えている。同じタイプの複数のDUTをテストするとき、このスイッチマトリクスネットワークは、複数のコントローラおよびテストサイトの間で共通のテストデータおよびリソースの共有も可能にする。
サイトごとに独立したサイトコントローラのおかげで、全てのテストサイトは非同期で動作することができる。これは結局、複数のDUTテストを容易にする。このモジュール化および複数サイト構成はまた、システムの拡張性も提供する。システムの一実施形態においては、単一のコントローラを、複数のDUTを制御、テストするように構成することができる。
プラグアンドプレイまたは交換可能なモジュールの考え方は、ハードウェア、ソフトウェア両方のレベルで標準的なインタフェースを用いることで助長される。ソフトウェアにおいては、モジュールを有効にし、アクティブにし、制御し、モニタするためにフレームワーククラスを用いる。フレームワークは、共通のテスト関連動作をインプリメントするクラスおよび方法のセットである。これは、電力供給およびピンエレクトロニクスの順序付け、電流／電圧レベルおよびタイミング条件の設定、測定値取得、テストフロー制御等のためのクラスを含んでいる。またフレームワークは、ランタイムサービスおよびデバッグのための方法も提供する。フレームワークオブジェクトは、発明の一実施形態による標準的なインタフェースをインプリメントすることを通して動作する。フレームワーククラスのC++ベースのレファレンスインプリメンテーションが提供される。ユーザは、自身に特有のフレームワーククラスを展開することもできる。
ハードウェアとソフトウェアとのインタフェース接続および通信は、バックプレーン通信ライブラリを通じて実現される。C++言語ベースのテストプログラムとC++より上のGUIテストプログラミングレイヤとを介してアクセスされるオープンバックプレーン通信ライブラリは、テストシステムのための一般化されたユーザインタフェースを提供する。C/C++コンストラクトを用いたテストプログラムを生成する方法は、米国出願第60/447,839号に開示されている。通信ライブラリは、ユーザアプリケーションおよびテストプログラムに見えないやり方でサイトコントローラと通信するメカニズムを提供する。基本的に、バックプレーン通信ライブラリは、テスタバックプレーン（この文脈では「バックプレーン」は抽象的なものであり、必ずしも物理的なハードウェアバックプレーンボードでなくてもよい）をまたいでの通信のために意図されたインタフェースを提供し、それによって、特定のサイトに接続されたモジュールとの通信に必要な機能を提供する。このライブラリの使用により、モジュールベンダは彼ら自身のドライバ（MS−ウィンドウズレベルのドライバ等）を作る必要がなくなる。これにより、ベンダ特有のモジュールソフトウェアは、対応するハードウェアモジュールと通信するために標準的なバックプレーンドライバを用いることが可能である。バックプレーン通信プロトコルは、一実施形態においてパケットベースのフォーマットを用いる。
オープンアーキテクチャの一つの利点は、これは全体的なテスタの使用法を単純にするということである。これは、サードパーティソリューションを展開し、これらのソリューションを重大な再作業を必要とすることなく再利用するためのメカニズムを提供する。任意のテストサイトに関して、所望する通りの適切なモジュールを選択し、用いることができる。モジュールは交換可能であるので、各テストサイトをDUTの最適テストを実現するように再構成することができる。またそれは、プラットフォーム間の非互換性の問題も単純にする。これらの単純化は全て、手間の減少、ターンアラウンド時間をはやくすることにつながり、結果としてテストコストの減少をもたらす。
本発明は、少なくとも一つのテスト対象装置（DUT）をテストするシステムを提供する。このシステムは、少なくとも一つのDUTに少なくとも一つのテスト（これはテストプランの一部であってもよい）を適用するように少なくとも一つのテストモジュールを制御する少なくとも一つのサイトコントローラを含んでいる。システムコントローラは、この少なくとも一つのサイトコントローラを制御する。
テストモジュールインタフェースは、サイトコントローラを第一のテストモジュールにインタフェース接続するテストモジュール機能を規定し、ここでテストモジュールインタフェースは、そのサイトコントローラを第二のテストモジュールにインタフェース接続するように拡張可能であり、拡張されていないテストモジュールインタフェースは、そのサイトコントローラを第二のテストモジュールにインタフェース接続するには不十分である。
このシステムはさらに、ユーザによって定義可能なテストクラスのような、DUT特有の特性からは独立している拡張可能なテスト機能を有している。テストは、拡張可能なテスト機能のインプリメンテーションである。
テストモジュールは、テスタピンインタフェースを用いてDUTと通信してもよく、これはDUT特有の特性からは独立していてもよい。テストモジュールインタフェースは、テストモジュールインタフェースクラスを備えていてもよく、テスタピンインタフェースはテスタピンインタフェースクラスを備えていてもよい。
発明の一実施形態による分散オペレーティングシステムは、システムコントローラによる少なくとも一つのサイトコントローラの制御を可能にするホストオペレーティングシステムと、各サイトコントローラに関連しており、関連するサイトコントローラによる少なくとも一つのテストモジュールの制御を可能にする少なくとも一つのローカルオペレーティングシステムとを備えている。少なくとも一つのテストモジュールが、対応するDUTに関するテストを行う。
ホストオペレーティングシステムは、少なくとも一つのサイトコントローラの動作を同期させてもよく、システムコントローラと少なくとも一つのサイトコントローラとの間の通信を仲裁してもよく、また少なくとも一つのサイトコントローラの動作をモニタしてもよい。サイトコントローラは、そのサイトコントローラに関連している少なくとも一つのテストモジュールの動作をモニタしてもよい。
ホストオペレーティングシステムは、少なくとも一つのサイトコントローラと通信するための少なくとも一つのホストインタフェースを備えている。テストモジュールインタフェースは、サイトコントローラを第一のテストモジュールにインタフェース接続するためのテストモジュール機能を規定し、テストモジュールインタフェースはそのサイトコントローラを第二のテストモジュールにインタフェース接続するように拡張可能であり、拡張されていないテストモジュールインタフェースはそのサイトコントローラを第二のテストモジュールにインタフェース接続するには不十分である。
ホストオペレーティングシステムは、少なくとも一つのホストフレームワーククラスを含んでいてもよく、これは、少なくとも一つのサイトコントローラを制御するためのアプリケーション特有のクラスをユーザが展開することを可能にするために、標準的なコンピュータ言語（例えばC/C++）で展開されてもよい。
各ローカルオペレーティングシステムは、少なくとも一つのローカルフレームワーククラスを有していてもよく、これは、少なくとも一つのサイトコントローラを制御するためのアプリケーション特有のクラスをユーザが展開することを可能にするために、標準的なコンピュータ言語（例えばC/C++）で展開されてもよい。
各サイトコントローラによって制御されるモジュールの数は計数可能である。対応するサイトコントローラに関連しているローカルオペレーティングシステムは、そのサイトコントローラによって制御されるタイプのテストモジュールが再構成されることを可能にする。ホストオペレーティングシステムは、システムコントローラによって制御されるサイトコントローラの数を計数可能とすることができ、テストシステムによってテストされるDUTの数を計数可能とすることができる。
エミュレータは、対象テストモジュールをテストシステムとともに使用することをシミュレートして、対象モジュールがテストシステムと互換性を有していることを検証してもよい。
なお、上記の発明の概要は、本発明の必要な特徴の全てを列挙したものではなく、これらの特徴群のサブコンビネーションもまた、発明となりうる。
以下、発明の実施の形態を通じて本発明を説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。
図１は、従来のテスタの一般化されたアーキテクチャを示しており、どのように信号が生み出されてテスト対象装置（DUT）に与えられるかを図示している。それぞれのDUT入力ピンは、テストデータを与えるドライバ２に接続されており、各DUT出力ピンはコンパレータ4に接続されている。多くの場合、各テスタピン（チャネル）が入力ピンまたは出力ピンのどちらかとして動作することができるように、３つの状態を有するドライバ−コンパレータを用いる。単一のDUT専用のテスタピンは、関連するタイミング生成器６、波長生成器８、パターンメモリ１０、タイミングデータメモリ１２、波長メモリデータ１４、およびデータレートを規定するブロック１６とともに動作するテストサイトを共同で構成する。
図２は、本発明の一実施形態によるシステムアーキテクチャ１００を示している。システムコントローラ（SysC）１０２は複数のサイトコントローラ（SiteC）１０４に連結されている。またシステムコントローラは、関連するファイルにアクセスするようにネットワークにもつながれている。モジュール接続イネーブラ１０６を通じて、各サイトコントローラは、テストサイト１１０にある一つ以上のモジュール１０８を制御するように連結されている。モジュール接続イネーブラ１０６は、接続されたハードウェアモジュール１０８の再構成を可能にし、また（パターンデータをロードする、応答データを集める、制御を提供する等のための）データ転送用のバスとしても機能する。また、モジュール接続イネーブラを通じて、あるサイトのモジュールが他のサイトのモジュールにアクセスすることができる。モジュール接続イネーブラ１０６は、異なるテストサイトが同一または異なるモジュール構成を有することを可能にする。言い換えれば、各テストサイトは、異なる数・タイプのモジュールを使用してもよい。考えられるハードウェアのインプリメンテーションには、専用の接続、スイッチ接続、バス接続、リング接続、およびスター接続が含まれる。モジュール接続イネーブラ１０６は、例えばスイッチマトリクスによってインプリメントされてもよい。各テストサイト１１０は、DUT１１２と関連づけられており、これはロードボード１１４を通じて対応するサイトのモジュールに接続されている。ある実施例においては、単一のコントローラを複数のDUTサイトに接続してもよい。
システムコントローラ１０２は、総合的なシステムマネージャとして機能する。これは、サイトコントローラの活動を統合し、システムレベルでの並列試験の計画を管理し、さらにハンドラ／プローブ制御を提供するとともにシステムレベルでのデータロギングおよびエラー処理サポートを提供する。動作設定に応じて、システムコントローラ１０２は、サイトコントローラ１０４の動作とは別のCPU上に配置されてもよい。あるいは、システムコントローラ１０２とサイトコントローラ１０４とで共通のCPUを共有してもよい。同様に、各サイトコントローラ１０４を、自身の専用CPU（中央演算処理装置）上に、あるいは同じCPU内の異なるプロセスまたはスレッドとして展開することもできる。
個々のシステムのコンポーネントを集積されたモノリシックなシステムの論理コンポーネントとして見なすことができ、必ずしも分散システムの物理的な構成要素として見なされなくてもよいという理解のもとに、システムアーキテクチャを、図２に示す分散システムとして概念的に描くことができる。
図３は、本発明の一実施形態によるソフトウェアアーキテクチャ２００を示している。ソフトウェアアーキテクチャ２００は、関連するハードウェアシステムの要素１０２、１０４、１０８と対応して、システムコントローラ２００、少なくとも一つのサイトコントローラ２４０、および少なくとも一つのモジュール２６０のための要素を有している分散オペレーティングシステムを表している。モジュール２６０に加えて、アーキテクチャ２００は、ソフトウェアでのモジュールエミュレーションのための対応する要素２８０を含んでいる。
例示的な選択として、このプラットフォームの用の展開環境はマイクロソフトのウィンドウズに基づいていてもよい。このアーキテクチャの使用は、プログラムおよびサポートの携帯性において副次的な利点（例えばフィールドサービスエンジニアは高度な診断を行うためのテスタオペレーティングシステムを動作させるラップトップコンピュータを接続することができるであろう）を有している。しかし、大規模なコンピュータ集約型の動作（テストパターンのコンパイル等）については、関連するソフトウェアは、独立して動作して分散されたプラットフォームを横断してのジョブスケジューリングを可能にすることができる独立した構成要素とされ得る。したがって、バッチジョブに関連するソフトウェアツールは、複数のプラットフォームタイプ上で動作することができる。
例示的な選択として、ANSI/ISO標準のC++をソフトウェア用のネイティブ言語とすることができる。当然のことながら、サードパーティが自身の選択した代わりの言語をシステムにまとめることを可能にする、（名目上のC++インタフェース上のレイヤを提供するための）使用可能な複数の選択肢がある。
図３は、名目上のソースによる組織化（あるいはサブシステムとしての集合的な展開）にしたがって、テスタオペレーティングシステムインタフェース２９０、ユーザコンポーネント２９２（例えば、テスト目的のためにユーザによって供給される）、システムコンポーネント２９４（例えば、基本的な接続性および通信のためのソフトウェアインフラとして提供される）、モジュール展開コンポーネント２９６（例えば、モジュールディベロッパによって提供される）、および外部コンポーネント２９８（例えばモジュールディベロッパ以外の外部ソースによって提供される）を含む要素を陰付きで示している。
ソースベースの組織化の観点から、テスタオペレーティングシステム（TOS）インタフェース２９０は、システムコントローラ−サイトコントローラインタフェース２２２、フレームワーククラス２２４、サイトコントローラ−モジュールインタフェース２４５、フレームワーククラス２４６、所定のモジュールレベルインタフェース２４７、バックプレーン通信ライブラリ２４９、シャーシスロットIF（インタフェース）２６２、ロードボードハードウェアIF２６４、バックプレーンシミュレ−ションIF２８３、ロードボードシミュレーションIF２８５、DUTシミュレーションIF２８７、DUTのVerilogモデル用のVerilog PLI（プログラミング言語インタフェース）２８８、およびDUTのC/C++モデル用のC/C++言語サポート２８９を含んでいる。
ユーザコンポーネント２９２は、ユーザテストプラン２４２、ユーザテストクラス２４３、ハードウェアロードボード２６５、DUT２６６、DUT Verilogモデル２９３およびDUT C/C++モデル２９１を含んでいる。
システムコンポーネント２９４は、システムツール２２６、通信ライブラリ２３０、テストクラス２４４、バックプレーンドライバ２５０、HWバックプレーン２６１、シミュレーションフレームワーク２８１、バックプレーンエミュレーション２８２およびロードボードシミュレーション２８６を含んでいる。
モデル展開コンポーネント２９６は、モジュールコマンドインプリメンテーション２４８、モジュールハードウェア２６３およびモジュールエミュレーション２８４を含んでいる。
外部コンポーネント２９８は外部ツール２２５を含んでいる。
システムコントローラ２２０は、サイトコントローラに対するインタフェース２２２、フレームワーククラス２２４、システムツール２２６、外部ツール２２５および通信ライブラリ２３０を含んでいる。システムコントローラソフトウェアは、ユーザに対する相互作用の主要な点である。これは、発明のサイトコントローラへのゲートウェイと、同一譲受人による米国出願第60/449,622号に述べられているマルチサイト／DUT環境におけるサイトコントローラの同期化とを提供する。ユーザアプリケーションおよびツールは、グラフィカルユーザインタフェース（GUI）ベースかそれ以外のものであり、システムコントローラ上で動作する。システムコントローラは、テストプラン、テストパターンおよびテストパラメータファイルを含むすべてのテストプラン関連の情報の収納庫としても機能する。テストパラメータファイルは、発明の一実施形態のオブジェクト指向の環境におけるテストクラス用のパラメータ化されたデータを含んでいる。
サードパーティのディベロッパは、標準的なシステムツール２２６に加えて（あるいはその代わりとして）ツールを提供することができる。システムコントローラ２２０上の標準的なインタフェース２２２は、ツールがテスタおよびテストオブジェクトにアクセスするために用いるインタフェースを有している。ツール（アプリケーション）２２５、２２６は、テストおよびテスタオブジェクトの相互的なバッチ制御を可能にする。このツールは、（例えばSECS/TSEM等の使用を通じて）自動化能力を提供するためのアプリケーションを含んでいる。
システムコントローラ２２０上にある通信ライブラリ２３０は、ユーザアプリケーションおよびテストプログラムにトランスペアレントな形でサイトコントローラ２４０と通信するメカニズムを提供する。
インタフェース２２２は、システムコントローラ２２０と関連したメモリに常駐しており、システムコントローラ上で実行するフレームワークオブジェクトに対するオープンインタフェースを提供する。サイトコントローラベースのモジュールソフトウェアがパターンデータにアクセス、取得することを可能にするインタフェースが含まれる。また、アプリケーションおよびツールがテスタおよびテストオブジェクトにアクセスするために用いるインタフェース、ならびに、スクリプトエンジンを通じてテスタおよびテストコンポーネントにアクセスして操作することができる能力を提供するスクリプトインタフェースも含まれる。これにより、インタラクティブな、バッチおよびリモートアプリケーションのための共通のメカニズムがそれらの機能を行うことが可能となる。
システムコントローラ２２０に関連しているフレームワーククラス２２４は、これらの上述したオブジェクトと相互に作用するメカニズムを提供し、これは標準的なインタフェースのリファレンスインプリメンテーションを提供する。例えば、発明のサイトコントローラ２４０は機能テストオブジェクトを提供する。システムコントローラフレームワーククラスは、この機能テストオブジェクトのリモートシステムコントローラベースの代理として、対応する機能テストプロキシを提供してもよい。したがって、標準的な機能テストインタフェースは、システムコントローラ２２０上のツールに対して利用可能とされる。システム、モジュール展開コンポーネントおよびインタフェースコンポーネント２９４、２９６および２９０はそれぞれ、システムコントローラとサイトコントローラとの間で分散されたオペレーティングシステムであると考えてもよい。フレームワーククラスは、ホストシステムコントローラに関連するオペレーティングシステムインタフェースを実質的に提供する。これらはまた、サイトコントローラに対するゲートウェイを提供するソフトウェア要素も構成し、マルチサイト／DUT環境におけるサイトコントローラの同期を提供する。したがってこのレイヤは、コミュニケーションレイヤを直接扱う必要なくサイトコントローラを操作し、それにアクセスするのに適している、発明の一実施形態におけるオブジェクトモデルを提供する。
サイトコントローラ２４０は、ユーザテストプラン２４２、ユーザテストクラス２４３、標準テストクラス２４４、標準インタフェース２４５、サイトコントローラフレームワーククラス２４６、モジュールハイレベルコマンドインタフェース（例えば所定のモジュールレベルのインタフェース）２４７、モジュールコマンドインプリメンテーション２４８、バックプレーン通信ライブラリ２４９、およびバックプレーンドライバ２５０のホストとなる。好ましくは、テストの機能の大半をサイトコントローラ１０４／２４０が扱い、それによってテストサイト１１０の独立した動作が可能である。
テストプラン２４２はユーザによって書かれる。このプランは、C++のような標準的なコンピュータ言語で直接記述されてもよいし、実行可能なテストプログラムへとコンパイル可能であるC++コードを生成するような、より高レベルのテストプログラミング言語で記述されてもよい。
このテストプランは、フレームワーククラス２４６および／または、サイトコントローラに関連する標準あるいはユーザによって供給されるテストクラス２４４を用いて、テストオブジェクトを作り出し、標準インタフェース２４５を用いてハードウェアを構成し、テストプランのフローを定義する。また、テストプランの実行中に必要とされる追加的なロジックも提供する。テストプランは、いくつかの基本的なサービスをサポートし、デバッグサービス（例えばブレークポイント）等のその下にあるオブジェクトのサービスに対するインタフェースと、その下にあるフレームワークおよび標準クラスへのアクセスとを提供する。
サイトコントローラに関連するフレームワーククラス２４６は、共通のテスト関連動作をインプリメントするクラスおよび方法のセットである。サイトコントローラレベルフレームワークは、例えば、電力供給およびピンエレクトロニクスの順番付け、レベルおよびタイミング条件の設定、測定値取得、テストフロー制御のためのクラスを含んでいる。フレームワークオブジェクトは、標準インタフェースをインプリメントすることを通じて動作してもよい。例えば、テスタピンフレームワーククラスのインプリメンテーションは、テストクラスがハードウェアモジュールピンと相互に作用するために用いるであろう汎用のテスタピンインタフェースをインプリメントするように統一される。
あるフレームワークオブジェクトは、モジュールと通信するためにモジュールレベルインタフェース２４７の助けを借りて動作するようにインプリメントされてもよい。サイトコントローラフレームワーククラスは、実質的に、各サイトコントローラをサポートするローカルオペレーティングシステムとして機能する。
一般的に、プログラムコードの９０％以上は装置テスト用のデータであり、残りの１０％のコードがテスト方法を実現する。装置テストデータはDUT依存のデータ（例えば電力供給条件、信号電圧条件、タイミング条件等）である。テストコードは、指定された装置条件をATEハードウェア上にロードする方法からなり、またユーザが指定した目的（データロギング等）を実現するのに必要である方法からも構成される。発明の一実施形態のフレームワークは、ハードウェア依存性のテストと、ユーザがDUTテストプログラミングのタスクを行うことを可能にするテスタオブジェクトモデルとを提供する。
テストコードの再利用性を高めるために、このようなコードは、装置特有のデータ（例えばピンの名前、刺激データ等）、あるいは装置テストに特有のデータ（例えばDCユニットの条件、測定ピン、ターゲットピンの数、パターンファイルの名前、パターンプログラムのアドレス）のいずれに対しても独立とされてもよい。もしテスト用のコードをこれらのタイプのデータとともにコンパイルすれば、テストコードの再利用性は低下する。したがって、発明の一実施形態によれば、いかなる装置特有のデータあるいは装置テストに特有のデータも、コード実行期間中の入力として、外部からテストコードに役立てられてもよい。
発明の一実施形態においては、標準テストインタフェースのインプリメンテーションであるテストクラスは、ここでたITestと記載するが、特定のタイプのテストに関してテストデータとコードとの分離（したがってコードの再利用性）を実現する。このようなテストクラスは、装置特有および／あるいは装置テスト特有のデータにおいてのみ異なるような別々のテストクラスの「テンプレート」とみなしてもよい。テストクラスはテストプランファイルにおいて指定される。各テストクラスは、典型的には、具体的なタイプの装置テストあるいは装置テスト用のセットアップをインプリメントする。例えば、発明の一実施形態は、DUTに関するすべての機能テストの基本となるクラスとして、ITestインタフェースの具体的なインプリメンテーション、例えばFunctionalTestを提供する。それは、テスト条件の設定、パターンの実行および、失敗したストローブの存在に基づくテスト状況の判定という基本的な機能を提供する。他のタイプのインプリメンテーションは、ここではACParametricTestおよびDCParametricTestとして表記されるACおよびDCテストクラスを含んでいてもよい。
全てのテストタイプは、いくつかの仮想的な方法のデフォルトのインプリメンテーション（例えば、init( )、preExec( )およびpostExec( )）を提供してもよい。これらの方法は、デフォルトの動作を乗り越えてテスト特有のパラメータを設定するためのテストエンジニアのエントリポイントとなる。しかしながら、カスタムテストクラスもテストプランにおいて用いることができる。
テストクラスは、そのテストの特定の場合に関するオプションを指定するために用いられるパラメータを提供することによって、ユーザがクラスの動作を構成することを可能にする。例えば、機能テストは、実行すべきパターンリストとテスト用のレベルおよびタイミング条件とを指定するために、パラメータPlistおよびTestConditionと採用してもよい。（テストプラン記述ファイルにおける異なる「テスト」ブロックの使用を通して）これらのパラメータについて異なる値を指定することにより、ユーザは機能テストの異なる例を作り出すことが可能である。図４は、どのようにして単一のテストクラスから異なるテスト例が導き出されるかを示している。テンプレートライブラリは、一般的なアルゴリズムおよびデータ構造の汎用ライブラリとして採用されてもよい。このライブラリはテスタのユーザに見えてもよく、ユーザは、例えば、ユーザ定義のテストクラスを作り出すようにテストクラスのインプリメンテーションを改変してもよい。
ユーザによって展開されるテストクラスに関して、システムの一実施形態は、このようなテストクラスを、全てのテストクラスが単一のテストインタフェース、例えばITestから得られるようなフレームワークに統合することをサポートし、その結果、そのフレームワークはシステムテストクラスの標準的なセットと同じようなやり方でそれらを処理することができる。ユーザは、追加のファシリティを生かすためには自分達のテストプログラムにおいてカスタムコードを用いなければならないという理解のもとで、自分達のテストクラスに追加の機能を自由に追加することができる。
各テストサイト１１０は、一つ以上のDUT１０６のテスト専用のものであり、テストモジュール１１２の構成可能な集合体を通じて機能する。各テストモジュール１１２は特定のテストタスクを行う主体である。例えば、テストモジュール１１２は、DUTの電源、ピンカード、アナログカード等であり得る。モジュールによるこのアプローチは、高いフレキシビリティと構成可能性を提供する。
モジュールコマンドインプリメンテーションクラス２４８は、モジュールハードウェアベンダによって提供されてもよく、ベンダによって選択されるコマンド実行方法に応じて、ハードウェアモジュールに関するモジュールレベルインタフェースをインプリメントするか、あるいは標準的なインタフェースのモジュール特有のインプリメンテーションを提供する。これらのクラスの外部インタフェースは、所定のモジュールレベルインタフェース要件およびバックプレーン通信ライブラリ要件によって規定される。またこのレイヤは、標準的なセットのテストコマンドの拡張も提供し、それにより方法（機能）およびデータ要素の追加が可能となる。
バックプレーン通信ライブラリ２４９は、バックブレーンをまたいでの標準的な通信のためのインタフェースを提供し、それによってテストサイトに接続されたモジュールとの通信に必要な機能を提供する。これにより、ベンダに特有のモジュールソフトウェアが対応するハードウェアモジュールとの通信にバックプレーンドライバ２５０を用いることが可能である。バックプレーン通信プロトコルはパケットベースのフォーマットである。
テスタピンオブジェクトは、物理的なテスタチャネルを表しており、ここではITesterPinで示されるテスタピンインタフェースから得られる。発明の一実施形態によるソフトウェア展開キット（SDK）は、TesterPinと呼ばれることもあるITesterPinのデフォルトのインプリメンテーションを提供し、これは所定のモジュールレベルインタフェースIChannelに関してインプリメントされる。ベンダは、IChannelに関して彼らのモジュールの機能をインプリメントすることができるのであればTesterPinを自由に使うことができるが、そうでなければ、彼らのモジュールとどもに動作するITesterPinのインプリメンテーションを提供しなければならない。
発明のテスタシステムによって提供される標準的なモジュールインタフェースは、ここではIModuleと表記するが、これは一般的には、ベンダのハードウェアモジュールを表している。ベンダによって供給される、システム用のモジュール特有のソフトウェアは、ダイナミックリンクライブラリ（DLL）のような実行可能な形態で提供されてもよい。ベンダからの各モジュールタイプ用のソフトウェアは、単一のDLLにカプセル化されていてもよい。このようなソフトウェアモジュールのそれぞれは、モジュールソフトウェア展開のためのAPIを備えている、モジュールインタフェースコマンド用のベンダに特有なインプリメンテーションを提供することを担っている。
モジュールインタフェースコマンドには２つの局面がある。それらは、第一に、ユーザがシステムにおける特定のハードウェアモジュールと（間接的に）通信するためのインタフェースとして機能し、第二に、サードパーティディベロッパが彼ら自身のモジュールをサイトコントローラレベルのフレームワークに統合するために活用することができるインタフェースを提供する。したがって、フレームワークによって提供されるモジュールインタフェースコマンドは、2つのタイプに分けられる。
一つ目は、最も疑う余地のないものであるが、フレームワークインタフェースを通じてユーザに対してあらわになる「コマンド」である。したがって、例えば、テスタピンインタフェース（ITesterPin）は、レベルおよびタイミングの値を取得、設定するための方法を提供し、一方で電源インタフェース（IPowerSupply）は電力を上げたり下げたりする方法を提供する。
また、フレームワークは、モジュールとの通信に用いられることができる、所定のモジュールレベルインタフェースの特別なカテゴリを提供する。これらは、ベンダのモジュールとの通信のためにフレームワーククラスによって用いられるインタフェース（すなわち、フレームワークインタフェースの「標準的な」インプリメンテーション）である。
しかしながら、第二の局面、モジュールレベルインタフェースの使用は、任意のものである。それをすることの利点は、ベンダは、モジュールレベルインタフェースをインプリメントすることによって彼らのハードウェアに対して送られる具体的なメッセージの内容を注視しつつ、ITesterPinおよびIPowerSupplyのようなクラスのインプリメンテーションを活用し得るということである。しかし、もしこれらのインタフェースがベンダに不適切であれば、それらはフレームワークインタフェースのそれらのカスタムインプリメンテーション（例えばITesterPin、IPowerSupply等のベンダインプリメンテーション）を提供することを選択してもよい。そうすればこれらは、それらのハードウェアに対して適切であるカスタム機能を提供するであろう。
したがって、モジュールに特有なベンダソフトウェアの統合は、2つの異なった手段、すなわち、関連するフレームワーククラスおよびインタフェースのカスタムインプリメンテーション、あるいはモジュールレベルインタフェースの特別なカテゴリのカスタムインプリメンテーションを通じて実現され得る。
次に、両方の方法の例示的な応用を図５の助けを借りて説明する。図５は、発明の一実施形態によるテスタシステムとベンダによって供給されるモジュールとの相互作用を示すユニバーサルモデリング言語（UML）クラスダイアグラムである。
新しいデジタルモジュールのベンダであるサードパーティA（TPA）は、そのハードウェアモジュールと通信するためのソフトウェアモジュールを提供する。このソフトウェアモジュールは、標準的なインタフェースIModuleをインプリメントする。このモジュールオブジェクトをTPAPinModuleと呼ぶことにしよう。ベンダTPAは、そのモジュールにおいて、関連する所定のモジュールレベルインタフェース、この場合にはIChannelをインプリメントすることによって、ここではTesterPinとして表されている、ITesterPinインタフェースの標準的なシステムインプリメンテーションを利用することができる。これは、TesterPinがモジュールと通信するためにIChannelのような標準的な所定のモジュールレベルインタフェースを用いるという事実によって可能とされる。したがって、TPAPinModuleは、TesterPinオブジェクトを単に作り出してあらわにすることでピンを提供する。
ここで、IChannelインタフェースは自分達のハードウェアとともにはうまく動作しないと判断する、異なるベンダであるサードパーティB（TPB）を考える。したがって、TPBは、彼ら自身のIModuleインプリメンテーション（TPBPinModule）だけではなく、ITesterPinインタフェースのインプリメンテーションTPBTesterPinも提供することが必要となる。
このアプローチは、サードパーティディベロッパがどのようにして自分達のハードウェアを展開するかの選択およびソフトウェアのサポートにおいて、多大なフレキシビリティをサードパーティディベロッパに与える。彼らはIModuleインタフェースをインプリメントすることを求められながら、モジュールレベルインタフェースをインプリメントすることか、適合するとわかればTesterPinのようなオブジェクトをインプリメントすることかを選択し得る。
実際に、ベンダは、ITesterPinインタフェースにおいてはサポートされていない拡張を提供するためにTesterPinをインプリメントすることを選択してもよい。フレームワークはユーザに、特定のインタフェースを取り出すためのメカニズムあるいはオブジェクトへのインプリメンテーションポインタを提供する。これは、ユーザコードがITesterPinポインタを有している場合に、フレームワークはそれが必要であるときにいわゆるTPBTesterPinオブジェクトをポイントしているかどうかを判断することができるということを意味している。（この特徴は標準的なC++ランタイムタイプ識別（RTTI）を介して提供されてもよいことに留意されたい。）言い換えると、テストプランがITesterPinインタフェースを要求するときには、インタフェースは、TesterPinクラスのベンダのテスタピンのインプリメンテーションを直接呼び出し、これがモジュールに特有の情報（例えば、特定のDUT刺激を与えるように設定されるべきレジスタのアドレス）を内蔵している。
まとめると、フレームワークコードが常にITesterPinインタフェースを使用している間、ユーザは、必要なときにモジュールベンダによって提供される具体的な特徴および拡張を自由に使うことができる。言い換えると、モジュールベンダは、例えば、クラスの標準的なシステムインプリメンテーションに方法（機能）を付加することができる。ユーザに対するトレードオフは、具体的なベンダの拡張を活用することが他のベンダのモジュールに対するテストコードの有用性を低下させるということである。
モジュールのレベルでは、システム１００は、名目上2つの動作モードを有している。動作のオンラインモードでは、モジュールエレメント２６０（例えばハードウェアエレメント）が用いられ、動作のオフラインモードではソフトウェアにおけるモジュールエミュレーション２８０が用いられる。
動作のオンラインモードについて、モジュールエレメント２６０は、HW（ハードウェア）バックプレーン２６１、シャーシスロットIF（インタフェース）２６２、モジュールハードウェア２６３、ロードボードハードウェアIF２６４、ハードウェアロードボード２６５およびDUT２６６を有している。
動作のオフラインモードについて、ソフトウェアでのモジュールエミュレーション２８０は、シミュレーションフレームワーク２８１、バックプレーンエミュレーション２８２、バックプレーンシミュレーションIF２８３、モジュールエミュレーション２８４、ロードボードシミュレーションIF２８５、ロードボードシミュレーション２８６およびDUTシミュレーションIF２８７を有している。2つのモデルをDUTシミュレーションに関して示す。Verilogを用いるモデルは、Verilog PLI（プログラミング言語インタフェース）２８８とDUT Verilogモデル２９３とを有している。C/C++を用いるモデルは、C/C++言語サポート２８９とDUT C/C++モデル２９１とを有している。シミュレーションは、PC等のいかなるコンピュータ上でも行うことができることに留意されたい。
オンラインモードでは、モジュールベンダは、デジタルテスタチャネル、DUT電源、あるいはDC測定ユニットといった、テストをサポートするための物理的なハードウェアコンポーネントを提供する。モジュールは、シャーシスロットIF２６２を通じてHWバックプレーン２６１にインタフェース接続される。
オフラインでの作業については、システムコントローラと等価なものを動かすPCベースあるいは他の環境が、付加的に、サイトコントローラレベルのフレームワークと、ソフトウェアのより低いレイヤのランタイム環境とを提供するとともにハードウェアをエミュレートするための全ての任務を引き受ける。
バックプレーンエミュレーション２８２は、物理的なバックプレーン２６１のためのソフトウェアによる代理を提供する。これは、バックプレーンシミュレーションインタフェース２８３を通して（ベンダが供給する）モジュールエミュレーションソフトウェア２８４と通信する。
モジュールエミュレーションソフトウェア２８４は、好ましくはモジュールベンダによって提供され、典型的にはモジュール２６３の特定のベンダインプリメンテーションと密接に結びついている。したがって、モジュールエミュレーションソフトウェアは、典型的には、異なるベンダによって供給されるモジュール間で詳細で異なっている。この場合、モジュールシミュレーションにより、ベンダは、ソフトウェアモデル（例えばモジュールエミュレーションソフトウェア２８４）を通してハードウェアの機能をあらわにし、シミュレートされるロードボード２８６に対して刺激信号を送り、DUTシミュレーションIF２８７を介してDUTモデリングソフトウェア２９１、２９３に接続されているシミュレートされるロードボード２８６からのDUT応答信号を受け取って処理することが可能になる。モジュールの単純な機能シミュレーションを提供してモジュールファームウェアのエミュレーションを迂回することが有利であるとベンダが考える場合もある。モジュールエミュレーションソフトウェアは、シミュレートされたモジュール刺激信号に対するシミュレートされたDUTの応答を、既知の良好なDUT応答と比較する。この比較に基づいて、ソフトウェアは、そのモジュールによって実行されているテストが所望のとおりDUTをテストするという目標に適合しているかを判断し、ユーザがオンラインの実際のテスタ上のIC（実際のDUT）上でそれを用いるのに先立って、モジュールのデバッグを行うことを助ける。
ロードボードシミュレーションインタフェース２８５は、モジュールエミュレーションレイヤおよびシミュレートされるロードボード２８６への、およびこれらからの信号のためのルートとして機能する。ロードボードシミュレーションコンポーネント２８６は、デバイスソケットマッピングと、DUTシミュレーションIF２８７への、およびそれからの信号伝達とをサポートする。
DUTシミュレーションは、ネイティブコード（すなわちC/C++）シミュレーション２９１、または目的のテスト対象装置２９３の機能モデルに対するVerilogプログラミング言語インタフェース（PLI）であってもよい。このモデルは、DUTシミュレーションインタフェース２８７を通じて、シミュレートされるロードボードとインタフェース接続する。
これらのレイヤの全体の制御はシミュレーションフレームワーク２８１によって提供されることに留意されたい。シミュレーションフレームワークは、既知の刺激信号に対するシミュレートされたDUT応答を測定する。システムエミュレーションの方法は、米国出願第10/403,817号に開示されている。

通信および制御
通信および制御は、関連するソフトウェアオブジェクトの管理を通じて実現される。好ましくは、通信のメカニズムは、システムコントローラ上のオブジェクトモデルの後ろに隠れている。このオブジェクトモデルは、サイトコントローラ上に見られるクラスおよびオブジェクトに対してプロキシを提供し、それによって、アプリケーションの展開（例えばIC装置のテスト）のための便利なプログラミングモデルを提供する。これにより、アプリケーションの開発者（例えばATEシステムのユーザ）は、アプリケーションとサイト／システムコントローラとの間の通信の具体的な情報に関連する不要な詳細を避けることが可能である。
図６は、サイトコントローラソフトウェア２４０内にサイトコントローラ１０４によって維持されているときのサイトコントローラオブジェクトの具体的な実施形態を示している。サイトコントローラオブジェクトは、CmdDispatcher６０２、FunctionalTestMsgHandler６０４およびFunctionalTest６０６を有している。インタフェースは、IMsgHandler６０８およびITest６１０を有している。
好ましくはサイトコントローラ２４０は、アプリケーションがアクセスのために必要とする機能クラスの全てを含んでいる。これらのクラスは、例えば、テスト、モジュール、ピン等を含む。ユーザのテストおよびソフトウェアツールは典型的には異なるコンピュータ上に存在するので、メッセージは、システムコントローラ上のツールからサイトコントローラ上のサーバに送られる。このサーバは、コマンド発送オブジェクトに関する方法を必要とする。
コマンド発送オブジェクト（CmdDispatcher）６０２は、IMsgHandlerインタフェース６０８をインプリメントするメッセージハンドラオブジェクトのマップを保持する。図６は、IMsgHandlerの具体的なインプリメンテーションFunctionalTestMsgHandler６０４を示している。DmdDispatcherオブジェクト６０２によって受信されたメッセージは通信すべきオブジェクトの識別子を含んでいる。この識別子は、内部のマップにおいて見られ、具体的なインプリメンテーション、この場合には図示されているFunctionalTestMsgHandlerオブジェクト６０４に帰着する。
本例では、IMsgHandler６０８は、単一の方法handleMessage()からなる。この方法は、好ましくは単一のインプリメンテーションクラスとしてインプリメントされる。図示されている場合においては、FunctionalTestMsgHandler６０４は、入ってくるメッセージの正確な性質に応じて、６つの方法のうちの１つにメッセージを送る。入ってくるメッセージのヘッダは、メッセージハンドラがどのようにメッセージを解釈し、どこにメッセージを送るかを決定することを可能にするメッセージIDを含んでいる。
システムコントローラ１０２における対応する通信環境は、システムコントローラソフトウェア２２０のツール２２５、２２６セクションに関連する。図７は、システムコントローラソフトウェア２２０においてシステムコントローラ１０２上に保持されるツールオブジェクト（あるいはシステムコントローラオブジェクト）の一実施形態を、図6に示したサイトコントローラオブジェクトと対応するように示している。ツールオブジェクトは、オブジェクトCmdDispatcher７０２、FunctionalTestMsgHandler７０４およびFunctionalTestProxy７０６を含んでいる。インタフェースは、IMsgHandler７０８、ITestClient７１０、およびIDispatch７１２を含んでいる。またユーティリティアプリケーション７１４も含まれる。
この例に関して、クラスCmdDispatcher７０２、IMsgHandler７０８、およびFunctionalTestMsgHandler７０４は図６に示したものと同じである。しかしながら、FunctionalTest６０６（あるいは他のいかなるサイトコントローラクラス）のインスタンス化は用いられない。代わりに、ツールオブジェクトは、サイトコントローラ１０４上の各オブジェクトと通信するためのプロキシクラスを有している。したがって例えば、ツールオブジェクトはFunctionalTest６０６に代えてクラスFunctionalTestProxy７０６を含んでいる。同様に、ツールオブジェクトにおけるITestClient７１０は、サイトコントローラオブジェクトにおけるITest６１０と同じではない。一般的に、サイトコントローラ１０２上で動作するアプリケーションは、サイトコントローラ１０４上に設けられているものそのもののようなインタフェースを用いない。この場合、ITest６１０の3つの方法（すなわち、preExec()、execute()およびpostExec()）はITestClient７１０における単一の方法（すなわちrunTest()）に置き換えられる。またITestClient７１０は、好ましくはデュアルインタフェース、すなわち、IDispatch７１２を受け継ぐものであり、マイクロソフトコンポーネントオブジェクトモデル（COM）としてインプリメントされる。それは、そのインタフェースをインプリメントするオブジェクトへのスクリプトエンジンのアクセスを可能にするようなインタフェースを提供する。これによって、システムをマイクロソフトウィンドウズプラットフォーム上で記述することが可能となる。
図６〜７に示す実施形態の動作の一例として、（例えば、ツールセクション２２６、２２８のうちの一つにおいて）システムコントローラ１０２上で動作するアプリケーションは、テストプラン２４２が一つ以上のFunctionalTestオブジェクト６０６を有しているようなサイトコントローラ１０４と通信してもよい。サイトコントローラ１０４上でのテストプラン２４２の初期化中に、対応するテストプランオブジェクトはサイトコントローラ１０４上にロードされ、TestPlanMessageHandlerオブジェクトを構成し、それをCmdDispatcherオブジェクト６０２とともに登録する。これがメッセージハンドラに独自のIDを割り当てる。同様な動作は、テストプラン２４２を構成する他のTestPlanオブジェクトでも起こる。
システムコントローラ１０３上の（例えばツール２２６、２２８における）アプリケーションは、通信ライブラリ２３０を初期化し、通信チャネルを介してサイトコントローラ１０４に接続し、TestPlanオブジェクトのためのIDを取得する。この初期化中に、プロキシオブジェクトは、それがテストをいくつ含んでいるかと、それらのタイプおよびIDとを決定する。それはタイプごとに（この場合には一つだけのタイプ）適切なDLLをロードし、それらに関するプロキシオブジェクトを構成し、それらをID値を用いて初期化する。
TestProxyオブジェクトも初期化する。これをするために、それらは、それらの名前を（それらのID値を用いて）取得するための適切なメッセージを構成してサイトコントローラ１０４の通信サーバに送信する。通信サーバは、メッセージをCmdDispatcher６０２に渡す。このオブジェクトは、その内部マップにおいて宛先IDを調べて、FunctionalTestMsgHandler６０４のhandleMessage()方法にメッセージを送る。例えばもしメッセージがテスト名取得の要求であれば、これらのオブジェクトは、それぞれのテスト名を取得し、適切なネーム列でアプリケーションのTestProxyオブジェクトに応答する。
初期化が完了すると、アプリケーションは、TestPlanオブジェクトへのリモートアクセスと、それを通じて両方のTestオブジェクトへのリモートアクセスを有する。ユーザはここで、例えば、アプリケーション上の「テストプラン起動」のボタンを押す。その結果、アプリケーションはTestPlanProxyオブジェクト上のRunTestPlan()方法を呼び出す。この方法は、TestPlanオブジェクトの宛先IDでRunTestPlanメッセージを構成し、RPCプロキシ上でsendMessage()機能を呼び出す。この機能がサイトコントローラにメッセージを送信する。
サイトコントローラ１０４上の通信サーバは、CmdDispatcherオブジェクト６０２上のhandleMessage()方法を呼び出し、TestPlanオブジェクトのIDをそれに渡す。CmdDispatcherオブジェクト６０２はその内部マップでこのIDを調べて、TestPlanオブジェクト用のメッセージハンドラを見つけて、このオブジェクト上のhandleMessage()方法を呼び出し、これがTestPlanオブジェクト上のRunTestPlan()方法を呼び出す。同じようなやり方で、アプリケーションは名前とTestオブジェクトの最近の動作状況とを取得することができる。

通信ライブラリを用いる方法
通信ライブラリ２３０を用いる例を以下に述べる。
通信ライブラリ２３０は好ましくは静的なライブラリである。アプリケーションは、CommLibrary.hファイルを通してこの通信ライブラリを使用することができる。通信ライブラリクラスをエクスポートする必要があるアプリケーションは、上記インクルードファイルを含むことに加えて、定義されたプリプロセッサ定義COMMLIBRARY_EXPORTS、COMMLIBRARY_FORCE_LINKAGEを有していなければならない。通信ライブラリをインポートするアプリケーションは、プリプロセッサ定義を何も定義する必要はない。通信ライブラリがサーバとして用いられるときには、アプリケーションは、CcmdDispatcherの次の静的な関数を呼び出さなければならない：InitializeServerunsigned long portNo）。
このportNoは、サーバが要求を待たなければならないポート番号である。サーバに対応するコマンドディスパッチャは、静的な関数getServerCmdDispatcherをCcmdDispatcherクラス上に呼び出すことによって読み出される。
通信ライブラリがクライアントとして用いられるときには、アプリケーションはCcmdDispatcherの以下の静的な関数を呼び出さなければならない。
InitializeClientconst OFCString serverAddress,
unsigned long serverPortNo,
CcmdDispatcher **pCmdDispatcher,
OFCString serverId)
このserverAddressおよびServerPortNoは、クライアントが接続しなければならないものである。この関数は、クライアント用のコマンドディスパッチャポインタおよびそれが接続するサーバIDを初期化する。また、後の時点で、クライアントは、静的な関数getClientCmdDispatcherを呼び出すことによってサーバIDに対応するコマンドディスパッチャを取り出すことができる。
通信ライブラリがコンパイルされるときには、ファイルClientInterface.idlおよびServerInterface.idl上ではビルドは排除される。好ましい実施形態は、これらのインタフェース定義ファイルに関して既に生成されたスタブおよびプロキシファイルを適用して、プロキシおよびスタブインプリメンテーションファイルを同じライブラリにリンクする。したがって、サーバおよびクライアントは、同じアドレス空間内にインスタンス化される。インタフェース定義ファイルおよびスタブファイルにおける以下の変更は、好ましくは、通信ライブラリをサーバおよびクライアントとして同じアドレス空間内で動作させるために行われる。

インタフェース定義ファイルにおける変更
以下のネームスペースの宣言は、好ましくは、インタフェース定義ファイルのそれぞれにおいて付加される。これは、プロキシインプリメンテーション機能とインタフェース機能の我々自身のインプリメンテーションとの名前の衝突を避けるためである。以下のネームスペースの宣言は、serverInterface.idlにおいて付加される。

cpp_quote("#ifdef __cplusplus")
cpp_quote("namespace COMM_SERVER")
cpp_quote("{")
cpp_quote("#endif")
cpp_quote("}")
スタブインプリメンテーションファイルにおける関数は、インタフェースにおいて宣言された機能のための我々自身のインプリメンテーション関数を呼び出すように変更される。すなわち、我々は、インタフェースにおいて宣言された機能のそれぞれに対応する異なる名前の関数をもつことになる。
関数呼び出しにおける競合を避けるために、インプリメンテーション関数の名前を「COMM_」列で始まる名前とすることが好ましい。そうすればスタブ関数におけるコードは、「functionName」に代えて「COMM_functionName」を呼び出すように変更される。
この方法が動作するためには、存在する全ての機能クラスは、対応するメッセージハンドラオブジェクトおよびプロキシクラスも有していなければならない。全てのメッセージハンドラオブジェクトは、通信ライブラリによって提供されるIMsgHandlerクラスから得られなければならない。IMsgHandlerクラスは抽象的なクラスである。メッセージハンドラのインプリメンタの任務は、handleMessage、setObject、handleErrorの定義を提供することが好ましい。全てのメッセージタイプは、１から始まらなければならない（ゼロはhandleErrorのためにとっておく）。機能クラスは好ましくは、そのメンバが可変であるように対応するメッセージハンドラを有する。機能クラスのコンストラクタにおいて、機能クラスは、そのメッセージハンドラによって提供される関数を呼び出すことによって、メッセージハンドラとともに自身を登録させる。次にメッセージハンドラオブジェクトは、addMsgHandler関数をコマンドディスパッチャ上にパラメータとしてのメッセージハンドラとともに呼び出すことによって、コマンドディスパッチャとともに登録されなければならない。addMsgHandler関数は、メッセージハンドラおよび機能クラスにIDを割り当てる。機能クラスのデストラクタは、パラメータとしての機能クラス識別子を送ることによって、コマンドディスパッチャ上にremoveMsgHandler関数を呼び出さなければならない。またプロキシクラスも、機能クラスに関して説明されたように、同じ登録手順に従わなければならない。
以下のCTestPlanクラスは、典型的な機能クラスがどのように本発明の好ましい実施形態に従うかを示している。

File: - TestPlan.h
Class CTestPlan
{
private:
unsigned long m_Id;
CTestPlanMsgHandler m_tplMsgHandler;
}
File: - TestPlan.cpp
extern CcmdDispatcher *g_pCmdDispatcher;
CTestPlan::CTestPlan
{
m_tplMsgHandler.setTestPlan(this);
g_pCmdDispatcher.AddMsgHandler(&m_tplMsgHandler)
}
CTestPlan::~CTestPlan
{
g_pCmdDispatcher.removeMsgHandler(m_Id)
}
この g_pCmdDispatcher object は、通信ＤＬＬ’ｓによりエクスポーズされるgetCmdDispatcher()を呼び出すことで初期化される。以下のCTestPlanMsgHandler クラスは、典型的なメッセージハンドラがどのようなものかを示す。
File: - TestPlanMsgHandler.h
Class CtestPlanMsgHandler : public IMsgHandler
{
public:
setTestPlan(CTestPlan *pTestPlan);
setTestPlanProxy(CTestPlanProxy *pTestPlanProxy);
void handleMessage(unsigned long msgType,
unsigned long senderId,
unsigned long senderMsgLen,
byte *pSenderMsg)
void handleSetName(unsigned long senderId,
unsigned long senderMsgLen,
byte *pSenderMsg);
void handleGetName(unsigned long senderId,
unsigned long senderMsgLen,
byte *pSenderMsg);
private:
CTestPlan m_pTestPlan;
CTestPlanProxy m_pTestPlanProxy;
typedef void (CFuncTestMsgHandler::*handlerFn)(unsigned long, unsigned long, byte*);
std::map<int, handlerFn> m_handlers;
}
File: - TestPlanMsgHandler.cpp
CTestPlanMsgHandler::CtestPlanMsgHandler
{
m_handlers[HandleError] = handleError;
m_handlers[GetName] = handleGetName;
m_handlers[SetName] = handleSetName;
}
void
CTestPlanMsgHandler::handleMessage(unsigned long msgType,
unsigned long senderId,
unsigned long senderMsgLen,
byte *pSenderMsg)
{
if (msgType == 0)
{
handleError(senderId, senderMsgLen, pSenderMsg);
}
else
{
handlerFn fn = NULL;
hIter_t fIter;
fIter = m_handlers.find(msgType);
if (fIter == m_handlers.end())
{
return;
}
fn = fIter→second;
if (NULL != fn)
{
(this→*fn)(senderId, senderMsgLen, pSenderMsg);
}
}
}
void
CTestPlanMsgHandler::handleSetName(unsigned long senderId,
unsigned long senderMsgLen,
byte *pSenderMsg)
{
if (m_pTestPlanProxy != NULL)
{
OFCString tplName = ByteToString(senderMsgLen, pSenderMsg)
m_pTplProxy→setName(tplName);
}
}
void
CTestPlanMsgHandler::handleGetName(unsigned long senderId,
unsigned long senderMsgLen,
byte *pSenderMsg)
{
OFCString testName;
if (m_pTestPlan != NULL)
{
unsigned long l_destId
unsigned long l_msgType;
unsigned long l_senderId;
unsigned l_senderMsgLen;
byte *l_senderMsg = NULL;
if (m_pTestPlan→getName(testName) != true)
{
// If a failure has occurred Send error message
char *errorString = "Error retrieving name";
l_destId = senderId;
l_msgType = HandleError;
l_senderId = m_Id;
l_senderMsgLen = strlen(errorString);
l_senderMsg = StringToByte(errorString);
sendMsg(l_destId,
l_msgType,
l_senderId,
l_senderMsgLen,
l_senderMsg);
return;
}
l_destId = senderId;
l_msgType = SetName;
long l_senderId = m_Id;
l_senderMsgLen = testName.length();
l_senderMsg = NULL;
StringToByte(testName, &l_senderMsg);
sendMsg(l_destId,
l_msgType,
l_senderId,
l_senderMsgLen,
l_senderMsg);
DELETE_BYTE(l_senderMsg);
}
}
void
CTestPlanMsgHandler::handleError(unsigned long senderId,
unsigned long senderMsgLen,
byte *pSenderMsg)
{
OFCString errorString;
ByteToString(senderMsgLen, pSenderMsg, errorString);
m_pTestPlanProxy→setError(errorString);
}


The following CTestPlanProxy class shows how a typical Proxy class will look like.

File: - TestPlanProxy.h
Class CTestPlanProxy
{
CTestPlanProxy(unsigned long serverId);
~CTestPlanProxy();
private:
CTestPlanProxy();
unsigned long m_Id;
unsigned long m_serverId;
CTestPlanMsgHandler m_tplMsgHandler;
}
File: - TestPlanProxy.cpp
extern CcmdDispatcher *g_pCmdDispatcher;
CTestPlanProxy::CTestPlanProxy(unsigned long serverId)
{
m_serverId = serverId;
m_tplMsgHandler.setTestPlanProxy(this);
g_pCmdDispatcher.AddMsgHandler(&m_tplMsgHandler)

/// initialize the proxy with its name.
unsigned long msgType;
unsigned long senderMsgLen;
byte *pSenderMsg = NULL;
msgType = GetName;
senderMsgLen = 0;
pSenderMsg = NULL;
sendMsg(m_clientId,
msgType,
m_Id,
senderMsgLen,

pSenderMsg);
// Check if the error string has been set by the message handler.
if (m_errorString.length() != 0)
{
OFCString errorString = m_errorString;
m_errorString = "";
throw exception(errorString.c_str());
}
}
CTestPlanProxy::~CTestPlanProxy
{
g_pCmdDispatcher.removeMsgHandler(m_Id)
}


The g_pCmdDispatcher object should be initialized by calling getCmdDispatcher().

システム構成とテスト
図８は、本発明の一実施形態による名目上のテストシーケンス８００を示している。テストシーケンス８００は、テスト環境８０４におけるモジュールの設置８０２を含んでおり、これはテスト準備８０６とシステムテスト８０８とを包含している。初めに新しいモジュール（ハードウェアまたはソフトウェアまたはこれらの組み合わせ）８１０が（ベンダの品質管理に基づいているかもしれないいくつかの外部手順によって）認証８１２される。設置８０２はまず、オフラインシミュレーション８１０のためのハードウェアモジュールエミュレーションの設定、テストプログラム展開８１２のためのモジュールリソースファイルおよびインタフェースの設定、ならびにパターンコンパイル８１４のためのモジュール特有のパターンコンパイラの設定を含むテスト準備８０６を必要とする。次にシステムテスト８０８が、較正８１６、診断８１８および構成８２０からの入力を用いて実行される。そして新しいモジュールに対して、（１）インタフェース制御、（２）同期、順序付けおよび再現性、（３）エラー／アラーム対応、（４）マルチサイト制御、ならびに（５）マルチインストゥルメントモジュール制御を含むシステムテスト８０８が行われる。
以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。その様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。
図１は従来のテスタアーキテクチャを示している。 図２は本発明の一実施形態によるシステムアーキテクチャを示している。 図３は本発明の一実施形態によるソフトウェアアーキテクチャを示している。 図４は発明の一実施形態によるテストクラスの使用を示している。 図５は発明の一実施形態による、テスタシステムと異なるベンダが提供するモジュールリソースとの相互作用を示す統一モデリング言語（UML）ダイアグラムである。 図６は、サイトコントローラによって保持されているときのユーザのテストを管理するためのサイトコントローラオブジェクトの一実施形態を示している。 図７は、図６に示されているサイトコントローラオブジェクトを表しているシステムコントローラ側のオブジェクトの代理の一実施形態を示している。 図８は発明の一実施形態によるテスト環境を示している。
符号の説明
１００ システムアーキテクチャ
１０２ システムコントローラ
１０４ サイトコントローラ
１０６ モジュール接続イネーブラ
１０８ モジュール
１１０ テストサイト
２００ ソフトウェアアーキテクチャ
２４０ サイトコントローラソフトウェア
２４２ ユーザテストプラン
２４３ ユーザテストクラス
２４４ 標準テストクラス
２４６ フレームワーククラス
２４５ 標準インタフェース
２４７ モジュールレベルインタフェース
２４８ モジュールコマンドインプリメンテーション
２４９ バックプレーン通信ライブラリ
２５０ ＰＣＩバックプレーンドライバ
２６０ モジュール
２６１ ＨＷバックプレーン
２６２ シャーシスロットＩＦ
２６３ モジュールハードウェア
２６４ ロードボードハードウェアＩＦ
２６５ ハードウェアロードボード
２８０ ＳＷにおけるモジュールエミュレーション
２８１ シミュレーションフレームワーク
２８２ バックプレーンエミュレーション
２８３ バックプレーンシミュレーションＩＦ
２８４ モジュールエミュレーション
２８５ ロードボードシミュレーションＩＦ
２８６ ロードボードシミュレーション
２８７ ＤＵＴシミュレーションＩＦ
２９０ オペレーティングシステムインタフェース
２９１ ＤＵＴ C/C++モデル
２９２ ユーザコンポーネント
２９３ ＤＵＴ Verilogモデル
２９４ システムコンポーネント
２９６ モジュール展開コンポーネント
２９８ 外部コンポーネント
８０４ テスト環境
８１７ 較正
８１８ 診断
８２０ 構成
８０６ テスト準備
８１４ テストプログラム展開
８０８ テストシステム
８１０ 新しいＨＷまたはＳＷモジュール
８１２ 認証

Claims (24)

  1. 少なくとも一つのテスト対象装置（DUT）をテストする半導体テストシステムのための分散オペレーティングシステムであって、
    システムコントローラによる少なくとも一つのサイトコントローラの制御を可能にするホストオペレーティングシステムと、
    各サイトコントローラと関連しており、関連するサイトコントローラによる少なくとも一つのテストモジュールの制御を可能にする少なくとも一つのローカルオペレーティングシステムとを備えており、
    少なくとも一つのテストモジュールが対応するDUT上でテストを行う分散オペレーティングシステム。
  2. 前記ホストオペレーティングシステムは、前記少なくとも一つのサイトコントローラの動作を同期させる請求項１に記載の分散オペレーティングシステム。
  3. 前記ホストオペレーティングシステムは、前記システムコントローラと前記少なくとも一つのサイトコントローラとの間の通信を仲裁する請求項１に記載の分散オペレーティングシステム。
  4. 前記システムコントローラは、前記少なくとも一つのサイトコントローラの動作をモニタする請求項１に記載の分散オペレーティングシステム。
  5. サイトコントローラは、当該サイトコントローラに関連する前記少なくとも一つのテストモジュールの動作をモニタする請求項1に記載の分散オペレーティングシステム。
  6. 前記ホストオペレーティングシステムは、前記少なくとも一つのサイトコントローラと通信するための少なくとも一つのホストインタフェースを備えている請求項１に記載の分散オペレーティングシステム。
  7. 前記少なくとも一つのホストインタフェースは、サイトコントローラに関連している少なくとも一つのテストモジュールと通信するためのものである請求項６に記載の分散オペレーティングシステム。
  8. 前記分散オペレーティングシステムは、サイトコントローラを第一のテストモジュールにインタフェース接続するためのテストモジュール機能を規定するテストモジュールインタフェースをさらに備えており、前記テストモジュールインタフェースは、前記サイトコントローラを第二のテストモジュールにインタフェース接続するように拡張可能であり、前記拡張されていないテストモジュールインタフェースは、前記サイトコントローラを前記第二のテストモジュールにインタフェース接続するには不十分である、請求項１に記載の分散オペレーティングシステム。
  9. 前記ホストオペレーティングシステムは、少なくとも一つのホストフレームワーククラスを有している請求項１に記載の分散オペレーティングシステム。
  10. 前記少なくとも一つのフレームワーククラスは、前記少なくとも一つのサイトコントローラを制御するためのアプリケーション特有のクラスをユーザが展開ことを可能にするように標準的なコンピュータ言語で展開される請求項１に記載の分散オペレーティングシステム。
  11. 前記標準的なコンピュータ言語はCまたはC++である請求項１０に記載の分散オペレーティングシステム。
  12. 各ローカルオペレーティングシステムは、少なくとも一つのローカルフレームワーククラスを有している請求項１に記載の分散オペレーティングシステム。
  13. 前記少なくとも一つのローカルフレームワーククラスは、前記少なくとも一つのテストモジュールを制御するためのアプリケーション特有のクラスをユーザが展開することを可能にするように標準的なコンピュータ言語で展開される請求項１２に記載の分散オペレーティングシステム。
  14. 前記標準的なコンピュータ言語はCまたはC++である請求項１３に記載の分散オペレーティングシステム。
  15. 各サイトコントローラによって制御されるモジュールの数は計数可能である請求項１に記載の分散オペレーティングシステム。
  16. 対応するサイトコントローラに関連している前記ローカルオペレーティングシステムは、前記サイトコントローラによって制御されるテストモジュールのタイプの再構成を可能にする請求項１に記載の分散オペレーティングシステム。
  17. 前記ホストオペレーティングシステムは、前記システムコントローラによって制御されるサイトコントローラの数を計数可能とする請求項１に記載の分散オペレーティングシステム。
  18. 前記ホストオペレーティングシステムは、前記テストシステムによってテストされるDUTの数を計数可能とする請求項１に記載の分散オペレーティングシステム。
  19. 前記少なくとも一つのテストモジュールは、ハードウェアおよび／またはソフトウェアを備えている請求項１に記載の分散オペレーティングシステム。
  20. 対象テストモジュールを前記テストシステムとともに使用することをシミュレートして、前記対象モジュールが前記テストシステムと互換性があることを検証するエミュレータをさらに備えている請求項１に記載の分散オペレーティングシステム。
  21. 第一のテストサイトにおける第一のセットのモジュールは、第二のテストサイトにおける第二のセットのモジュールとは異なって構成されている請求項１に記載の分散オペレーティングシステム。
  22. 第一のテストサイトは第一のDUTをテストするための第一の構成を有しており、第二のテストサイトは第二のDUTをテストするための第二の構成を有しており、前記第一および第二のテストサイトは、代わりに第三のDUTをテストするための第三のテストサイトをともに形成するように再構成可能である請求項１に記載の分散オペレーティングシステム。
  23. 第一のテストサイトにおける第一のモジュールは、第二のテストサイトにおける第二のモジュールにアクセスすることができる請求項１に記載の分散オペレーティングシステム。
  24. テストモジュールとともに使用するための所定のセットの関数およびインタフェースを有している通信ライブラリをさらに備えている請求項１に記載の分散オペレーティングシステム。
JP2006252498A 2003-02-14 2006-09-19 集積回路をテストする方法および装置 Withdrawn JP2007052028A (ja)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US44783903P 2003-02-14 2003-02-14
US44962203P 2003-02-24 2003-02-24
US10/404,002 US7460988B2 (en) 2003-03-31 2003-03-31 Test emulator, test module emulator, and record medium storing program therein
US10/403,817 US7290192B2 (en) 2003-03-31 2003-03-31 Test apparatus and test method for testing plurality of devices in parallel

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2006502669A Division JP3954639B2 (ja) 2003-02-14 2004-02-16 集積回路をテストする方法および装置

Publications (2)

Publication Number Publication Date
JP2007052028A true JP2007052028A (ja) 2007-03-01
JP2007052028A5 JP2007052028A5 (ja) 2007-04-19

Family

ID=32872965

Family Applications (3)

Application Number Title Priority Date Filing Date
JP2006502670A Expired - Fee Related JP3939336B2 (ja) 2003-02-14 2004-02-16 半導体集積回路用のテストプログラムを開発する方法および構造
JP2006502669A Expired - Fee Related JP3954639B2 (ja) 2003-02-14 2004-02-16 集積回路をテストする方法および装置
JP2006252498A Withdrawn JP2007052028A (ja) 2003-02-14 2006-09-19 集積回路をテストする方法および装置

Family Applications Before (2)

Application Number Title Priority Date Filing Date
JP2006502670A Expired - Fee Related JP3939336B2 (ja) 2003-02-14 2004-02-16 半導体集積回路用のテストプログラムを開発する方法および構造
JP2006502669A Expired - Fee Related JP3954639B2 (ja) 2003-02-14 2004-02-16 集積回路をテストする方法および装置

Country Status (8)

Country Link
EP (2) EP1592976B1 (ja)
JP (3) JP3939336B2 (ja)
KR (2) KR20050101216A (ja)
CN (1) CN1784609B (ja)
AT (1) ATE384269T1 (ja)
DE (1) DE602004011320T2 (ja)
TW (1) TWI344595B (ja)
WO (2) WO2004072669A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7906981B1 (en) 2009-09-10 2011-03-15 Advantest Corporation Test apparatus and test method
US8261119B2 (en) 2009-09-10 2012-09-04 Advantest Corporation Test apparatus for testing device has synchronization module which synchronizes analog test module to digital test module based on synchronization signal received from digital test module
US8405415B2 (en) 2009-09-10 2013-03-26 Advantest Corporation Test apparatus synchronous module and synchronous method
US8692566B2 (en) 2008-12-08 2014-04-08 Advantest Corporation Test apparatus and test method

Families Citing this family (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7197417B2 (en) 2003-02-14 2007-03-27 Advantest America R&D Center, Inc. Method and structure to develop a test program for semiconductor integrated circuits
US7184917B2 (en) * 2003-02-14 2007-02-27 Advantest America R&D Center, Inc. Method and system for controlling interchangeable components in a modular test system
US7437261B2 (en) 2003-02-14 2008-10-14 Advantest Corporation Method and apparatus for testing integrated circuits
US7197416B2 (en) 2004-05-22 2007-03-27 Advantest America R&D Center, Inc. Supporting calibration and diagnostics in an open architecture test system
US7430486B2 (en) 2004-05-22 2008-09-30 Advantest America R&D Center, Inc. Datalog support in a modular test system
US7210087B2 (en) 2004-05-22 2007-04-24 Advantest America R&D Center, Inc. Method and system for simulating a modular test system
US7543200B2 (en) * 2005-02-17 2009-06-02 Advantest Corporation Method and system for scheduling tests in a parallel test system
US8214800B2 (en) * 2005-03-02 2012-07-03 Advantest Corporation Compact representation of vendor hardware module revisions in an open architecture test system
JP2006275986A (ja) 2005-03-30 2006-10-12 Advantest Corp 診断プログラム、切替プログラム、試験装置、および診断方法
US7253607B2 (en) * 2005-04-29 2007-08-07 Teradyne, Inc. Site-aware objects
EP1724599B1 (en) 2005-05-20 2007-08-22 Agilent Technologies, Inc. Test device with test parameter adaptation
US7788562B2 (en) * 2006-11-29 2010-08-31 Advantest Corporation Pattern controlled, full speed ATE compare capability for deterministic and non-deterministic IC data
JP5022262B2 (ja) * 2008-02-12 2012-09-12 株式会社アドバンテスト デバッグ中にツールを使用可能な試験システム及び方法
US8949784B2 (en) 2008-10-03 2015-02-03 Microsoft Technology Licensing, Llc Type system for declarative data scripting language
CN102193553A (zh) * 2010-03-02 2011-09-21 珠海格力电器股份有限公司 空调控制器功能的测试方法、装置及系统
TWI470421B (zh) * 2010-03-16 2015-01-21 Via Tech Inc 微處理器及其除錯方法
US8868371B2 (en) * 2011-09-09 2014-10-21 Infineon Technologies Ag Method and device for determining test sets of operating parameter values for an electronic component
US9400307B2 (en) 2013-03-13 2016-07-26 Keysight Technologies, Inc. Test system for improving throughout or maintenance properties of semiconductor testing
CN104144084B (zh) * 2013-05-10 2017-12-01 腾讯科技（深圳）有限公司 终端状态的监控方法及装置
CN104298590B (zh) * 2013-07-16 2019-05-10 爱德万测试公司 用于按管脚apg的快速语义处理器
US10539609B2 (en) * 2014-12-08 2020-01-21 Nxp Usa, Inc. Method of converting high-level test specification language to low-level test implementation language
KR20180084385A (ko) 2017-01-17 2018-07-25 한국항공우주산업 주식회사 데이터베이스 기반의 자동시험장비의 운용 시스템 및 그 운용 방법
US10592370B2 (en) * 2017-04-28 2020-03-17 Advantest Corporation User control of automated test features with software application programming interface (API)
US10890621B2 (en) * 2017-05-30 2021-01-12 Raytheon Company Systems and methods for testing an embedded controller
KR102179508B1 (ko) 2019-07-05 2020-11-16 한국항공우주산업 주식회사 자동화 시험장비의 운용 시스템
TWI748300B (zh) * 2019-12-09 2021-12-01 新唐科技股份有限公司 測試系統和測試方法
CN111459840A (zh) * 2020-04-26 2020-07-28 恩亿科(北京)数据科技有限公司 一种进程的调试方法及装置
CN112311627B (zh) * 2020-10-29 2022-09-09 许昌许继软件技术有限公司 一种基于xml格式的规约描述文件的电力规约通用测试方法及系统
CN113051114A (zh) * 2021-03-19 2021-06-29 无锡市软测认证有限公司 一种用于提高芯片测试效率的方法
US11574696B2 (en) * 2021-04-12 2023-02-07 Nanya Technology Corporation Semiconductor test system and method
KR102314419B1 (ko) * 2021-07-27 2021-10-19 (주) 에이블리 반도체 테스트 패턴 발생 장치 및 방법
CN114818669B (zh) * 2022-04-26 2023-06-27 北京中科智加科技有限公司 一种人名纠错模型的构建方法和计算机设备
CN115630594B (zh) * 2022-12-19 2023-03-21 杭州加速科技有限公司 一种芯片设计仿真文件到Pattern文件的转换方法及其系统
CN116520754B (zh) * 2023-06-27 2023-09-22 厦门芯泰达集成电路有限公司 基于预加载模式的dps模块控制方法、系统
CN117291145A (zh) * 2023-11-24 2023-12-26 之江实验室 片上系统的验证方法、系统和电子装置

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH02246841A (ja) * 1989-03-17 1990-10-02 Hitachi Ltd 自動車の制御装置及び制御方法
US5488573A (en) * 1993-09-02 1996-01-30 Matsushita Electric Industrial Co., Ltd. Method for generating test programs
US6182258B1 (en) * 1997-06-03 2001-01-30 Verisity Ltd. Method and apparatus for test generation during circuit design
US6028439A (en) * 1997-10-31 2000-02-22 Credence Systems Corporation Modular integrated circuit tester with distributed synchronization and control
US6195774B1 (en) * 1998-08-13 2001-02-27 Xilinx, Inc. Boundary-scan method using object-oriented programming language
US6779140B2 (en) * 2001-06-29 2004-08-17 Agilent Technologies, Inc. Algorithmically programmable memory tester with test sites operating in a slave mode

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8692566B2 (en) 2008-12-08 2014-04-08 Advantest Corporation Test apparatus and test method
US7906981B1 (en) 2009-09-10 2011-03-15 Advantest Corporation Test apparatus and test method
US8261119B2 (en) 2009-09-10 2012-09-04 Advantest Corporation Test apparatus for testing device has synchronization module which synchronizes analog test module to digital test module based on synchronization signal received from digital test module
US8405415B2 (en) 2009-09-10 2013-03-26 Advantest Corporation Test apparatus synchronous module and synchronous method

Also Published As

Publication number Publication date
JP2006518460A (ja) 2006-08-10
EP1592975B1 (en) 2008-03-26
WO2004072670A1 (en) 2004-08-26
EP1592975A1 (en) 2005-11-09
EP1592976B1 (en) 2008-01-16
ATE384269T1 (de) 2008-02-15
JP2006520947A (ja) 2006-09-14
TWI344595B (en) 2011-07-01
WO2004072669A1 (en) 2004-08-26
TW200508855A (en) 2005-03-01
KR20050101216A (ko) 2005-10-20
JP3954639B2 (ja) 2007-08-08
DE602004011320D1 (de) 2008-03-06
EP1592976A1 (en) 2005-11-09
DE602004011320T2 (de) 2009-02-05
KR20050099626A (ko) 2005-10-14
CN1784609A (zh) 2006-06-07
JP3939336B2 (ja) 2007-07-04
CN1784609B (zh) 2011-02-23

Similar Documents

Publication Publication Date Title
JP3954639B2 (ja) 集積回路をテストする方法および装置
US7437261B2 (en) Method and apparatus for testing integrated circuits
JP2006518460A5 (ja)
JP3735636B2 (ja) 試験エミュレート装置、試験モジュールエミュレート装置、及びこれらのプログラムを記録した記録媒体
US20050022087A1 (en) Method and system for controlling interchangeable components in a modular test system
JP4608516B2 (ja) モジュール式試験システムに試験モジュールを統合する方法およびモジュール式試験システム
JP4608517B2 (ja) モジュール式試験システム
JP2008519247A (ja) モジュール式試験システムをシミュレートする方法及びシステム
US7548828B2 (en) Automatic test equipment platform architecture using parallel user computers
JP2007057541A (ja) 試験エミュレート装置
CN100456043C (zh) 检测集成电路的方法和装置
TWI287639B (en) A distributed operating system for a semiconductor test system for testing at least one device under test
JP2005285092A (ja) 試験エミュレート装置
Rajsuman et al. Open architecture test system: System architecture and design
Rajsuman et al. Architecture and design of an open ATE to incubate the development of third-party instruments

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070216

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20070216

A761 Written withdrawal of application

Free format text: JAPANESE INTERMEDIATE CODE: A761

Effective date: 20070903