JP2007052028A - 集積回路をテストする方法および装置 - Google Patents
集積回路をテストする方法および装置 Download PDFInfo
- 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
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)のような半導体テストシステム用の分散オペレーティングシステムが記載されている。このオペレーティングシステムは、システムコントローラによる一つ以上のサイトコントローラの制御を可能にするホストオペレーティングシステムを有している。一つ以上のローカルオペレーティングシステムは、それぞれがサイトコントローラに関連しており、関連しているサイトコントローラによる一つ以上のテストモジュールの制御を可能にする。各テストモジュールは、テストサイトにおいて対応するテスト対象装置上でテストを行う。
【選択図】図2
【解決手段】自動テスト機器(ATE)のような半導体テストシステム用の分散オペレーティングシステムが記載されている。このオペレーティングシステムは、システムコントローラによる一つ以上のサイトコントローラの制御を可能にするホストオペレーティングシステムを有している。一つ以上のローカルオペレーティングシステムは、それぞれがサイトコントローラに関連しており、関連しているサイトコントローラによる一つ以上のテストモジュールの制御を可能にする。各テストモジュールは、テストサイトにおいて対応するテスト対象装置上でテストを行う。
【選択図】図2
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の数を計数可能とすることができる。
エミュレータは、対象テストモジュールをテストシステムとともに使用することをシミュレートして、対象モジュールがテストシステムと互換性を有していることを検証してもよい。
なお、上記の発明の概要は、本発明の必要な特徴の全てを列挙したものではなく、これらの特徴群のサブコンビネーションもまた、発明となりうる。
以下、発明の実施の形態を通じて本発明を説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。
図1は、従来のテスタの一般化されたアーキテクチャを示しており、どのように信号が生み出されてテスト対象装置(DUT)に与えられるかを図示している。それぞれのDUT入力ピンは、テストデータを与えるドライバ2に接続されており、各DUT出力ピンはコンパレータ4に接続されている。多くの場合、各テスタピン(チャネル)が入力ピンまたは出力ピンのどちらかとして動作することができるように、3つの状態を有するドライバ−コンパレータを用いる。単一のDUT専用のテスタピンは、関連するタイミング生成器6、波長生成器8、パターンメモリ10、タイミングデータメモリ12、波長メモリデータ14、およびデータレートを規定するブロック16とともに動作するテストサイトを共同で構成する。
図2は、本発明の一実施形態によるシステムアーキテクチャ100を示している。システムコントローラ(SysC)102は複数のサイトコントローラ(SiteC)104に連結されている。またシステムコントローラは、関連するファイルにアクセスするようにネットワークにもつながれている。モジュール接続イネーブラ106を通じて、各サイトコントローラは、テストサイト110にある一つ以上のモジュール108を制御するように連結されている。モジュール接続イネーブラ106は、接続されたハードウェアモジュール108の再構成を可能にし、また(パターンデータをロードする、応答データを集める、制御を提供する等のための)データ転送用のバスとしても機能する。また、モジュール接続イネーブラを通じて、あるサイトのモジュールが他のサイトのモジュールにアクセスすることができる。モジュール接続イネーブラ106は、異なるテストサイトが同一または異なるモジュール構成を有することを可能にする。言い換えれば、各テストサイトは、異なる数・タイプのモジュールを使用してもよい。考えられるハードウェアのインプリメンテーションには、専用の接続、スイッチ接続、バス接続、リング接続、およびスター接続が含まれる。モジュール接続イネーブラ106は、例えばスイッチマトリクスによってインプリメントされてもよい。各テストサイト110は、DUT112と関連づけられており、これはロードボード114を通じて対応するサイトのモジュールに接続されている。ある実施例においては、単一のコントローラを複数のDUTサイトに接続してもよい。
システムコントローラ102は、総合的なシステムマネージャとして機能する。これは、サイトコントローラの活動を統合し、システムレベルでの並列試験の計画を管理し、さらにハンドラ/プローブ制御を提供するとともにシステムレベルでのデータロギングおよびエラー処理サポートを提供する。動作設定に応じて、システムコントローラ102は、サイトコントローラ104の動作とは別のCPU上に配置されてもよい。あるいは、システムコントローラ102とサイトコントローラ104とで共通のCPUを共有してもよい。同様に、各サイトコントローラ104を、自身の専用CPU(中央演算処理装置)上に、あるいは同じCPU内の異なるプロセスまたはスレッドとして展開することもできる。
個々のシステムのコンポーネントを集積されたモノリシックなシステムの論理コンポーネントとして見なすことができ、必ずしも分散システムの物理的な構成要素として見なされなくてもよいという理解のもとに、システムアーキテクチャを、図2に示す分散システムとして概念的に描くことができる。
図3は、本発明の一実施形態によるソフトウェアアーキテクチャ200を示している。ソフトウェアアーキテクチャ200は、関連するハードウェアシステムの要素102、104、108と対応して、システムコントローラ200、少なくとも一つのサイトコントローラ240、および少なくとも一つのモジュール260のための要素を有している分散オペレーティングシステムを表している。モジュール260に加えて、アーキテクチャ200は、ソフトウェアでのモジュールエミュレーションのための対応する要素280を含んでいる。
例示的な選択として、このプラットフォームの用の展開環境はマイクロソフトのウィンドウズに基づいていてもよい。このアーキテクチャの使用は、プログラムおよびサポートの携帯性において副次的な利点(例えばフィールドサービスエンジニアは高度な診断を行うためのテスタオペレーティングシステムを動作させるラップトップコンピュータを接続することができるであろう)を有している。しかし、大規模なコンピュータ集約型の動作(テストパターンのコンパイル等)については、関連するソフトウェアは、独立して動作して分散されたプラットフォームを横断してのジョブスケジューリングを可能にすることができる独立した構成要素とされ得る。したがって、バッチジョブに関連するソフトウェアツールは、複数のプラットフォームタイプ上で動作することができる。
例示的な選択として、ANSI/ISO標準のC++をソフトウェア用のネイティブ言語とすることができる。当然のことながら、サードパーティが自身の選択した代わりの言語をシステムにまとめることを可能にする、(名目上のC++インタフェース上のレイヤを提供するための)使用可能な複数の選択肢がある。
図3は、名目上のソースによる組織化(あるいはサブシステムとしての集合的な展開)にしたがって、テスタオペレーティングシステムインタフェース290、ユーザコンポーネント292(例えば、テスト目的のためにユーザによって供給される)、システムコンポーネント294(例えば、基本的な接続性および通信のためのソフトウェアインフラとして提供される)、モジュール展開コンポーネント296(例えば、モジュールディベロッパによって提供される)、および外部コンポーネント298(例えばモジュールディベロッパ以外の外部ソースによって提供される)を含む要素を陰付きで示している。
ソースベースの組織化の観点から、テスタオペレーティングシステム(TOS)インタフェース290は、システムコントローラ−サイトコントローラインタフェース222、フレームワーククラス224、サイトコントローラ−モジュールインタフェース245、フレームワーククラス246、所定のモジュールレベルインタフェース247、バックプレーン通信ライブラリ249、シャーシスロットIF(インタフェース)262、ロードボードハードウェアIF264、バックプレーンシミュレ−ションIF283、ロードボードシミュレーションIF285、DUTシミュレーションIF287、DUTのVerilogモデル用のVerilog PLI(プログラミング言語インタフェース)288、およびDUTのC/C++モデル用のC/C++言語サポート289を含んでいる。
ユーザコンポーネント292は、ユーザテストプラン242、ユーザテストクラス243、ハードウェアロードボード265、DUT266、DUT Verilogモデル293およびDUT C/C++モデル291を含んでいる。
システムコンポーネント294は、システムツール226、通信ライブラリ230、テストクラス244、バックプレーンドライバ250、HWバックプレーン261、シミュレーションフレームワーク281、バックプレーンエミュレーション282およびロードボードシミュレーション286を含んでいる。
モデル展開コンポーネント296は、モジュールコマンドインプリメンテーション248、モジュールハードウェア263およびモジュールエミュレーション284を含んでいる。
外部コンポーネント298は外部ツール225を含んでいる。
システムコントローラ220は、サイトコントローラに対するインタフェース222、フレームワーククラス224、システムツール226、外部ツール225および通信ライブラリ230を含んでいる。システムコントローラソフトウェアは、ユーザに対する相互作用の主要な点である。これは、発明のサイトコントローラへのゲートウェイと、同一譲受人による米国出願第60/449,622号に述べられているマルチサイト/DUT環境におけるサイトコントローラの同期化とを提供する。ユーザアプリケーションおよびツールは、グラフィカルユーザインタフェース(GUI)ベースかそれ以外のものであり、システムコントローラ上で動作する。システムコントローラは、テストプラン、テストパターンおよびテストパラメータファイルを含むすべてのテストプラン関連の情報の収納庫としても機能する。テストパラメータファイルは、発明の一実施形態のオブジェクト指向の環境におけるテストクラス用のパラメータ化されたデータを含んでいる。
サードパーティのディベロッパは、標準的なシステムツール226に加えて(あるいはその代わりとして)ツールを提供することができる。システムコントローラ220上の標準的なインタフェース222は、ツールがテスタおよびテストオブジェクトにアクセスするために用いるインタフェースを有している。ツール(アプリケーション)225、226は、テストおよびテスタオブジェクトの相互的なバッチ制御を可能にする。このツールは、(例えばSECS/TSEM等の使用を通じて)自動化能力を提供するためのアプリケーションを含んでいる。
システムコントローラ220上にある通信ライブラリ230は、ユーザアプリケーションおよびテストプログラムにトランスペアレントな形でサイトコントローラ240と通信するメカニズムを提供する。
インタフェース222は、システムコントローラ220と関連したメモリに常駐しており、システムコントローラ上で実行するフレームワークオブジェクトに対するオープンインタフェースを提供する。サイトコントローラベースのモジュールソフトウェアがパターンデータにアクセス、取得することを可能にするインタフェースが含まれる。また、アプリケーションおよびツールがテスタおよびテストオブジェクトにアクセスするために用いるインタフェース、ならびに、スクリプトエンジンを通じてテスタおよびテストコンポーネントにアクセスして操作することができる能力を提供するスクリプトインタフェースも含まれる。これにより、インタラクティブな、バッチおよびリモートアプリケーションのための共通のメカニズムがそれらの機能を行うことが可能となる。
システムコントローラ220に関連しているフレームワーククラス224は、これらの上述したオブジェクトと相互に作用するメカニズムを提供し、これは標準的なインタフェースのリファレンスインプリメンテーションを提供する。例えば、発明のサイトコントローラ240は機能テストオブジェクトを提供する。システムコントローラフレームワーククラスは、この機能テストオブジェクトのリモートシステムコントローラベースの代理として、対応する機能テストプロキシを提供してもよい。したがって、標準的な機能テストインタフェースは、システムコントローラ220上のツールに対して利用可能とされる。システム、モジュール展開コンポーネントおよびインタフェースコンポーネント294、296および290はそれぞれ、システムコントローラとサイトコントローラとの間で分散されたオペレーティングシステムであると考えてもよい。フレームワーククラスは、ホストシステムコントローラに関連するオペレーティングシステムインタフェースを実質的に提供する。これらはまた、サイトコントローラに対するゲートウェイを提供するソフトウェア要素も構成し、マルチサイト/DUT環境におけるサイトコントローラの同期を提供する。したがってこのレイヤは、コミュニケーションレイヤを直接扱う必要なくサイトコントローラを操作し、それにアクセスするのに適している、発明の一実施形態におけるオブジェクトモデルを提供する。
サイトコントローラ240は、ユーザテストプラン242、ユーザテストクラス243、標準テストクラス244、標準インタフェース245、サイトコントローラフレームワーククラス246、モジュールハイレベルコマンドインタフェース(例えば所定のモジュールレベルのインタフェース)247、モジュールコマンドインプリメンテーション248、バックプレーン通信ライブラリ249、およびバックプレーンドライバ250のホストとなる。好ましくは、テストの機能の大半をサイトコントローラ104/240が扱い、それによってテストサイト110の独立した動作が可能である。
テストプラン242はユーザによって書かれる。このプランは、C++のような標準的なコンピュータ言語で直接記述されてもよいし、実行可能なテストプログラムへとコンパイル可能であるC++コードを生成するような、より高レベルのテストプログラミング言語で記述されてもよい。
このテストプランは、フレームワーククラス246および/または、サイトコントローラに関連する標準あるいはユーザによって供給されるテストクラス244を用いて、テストオブジェクトを作り出し、標準インタフェース245を用いてハードウェアを構成し、テストプランのフローを定義する。また、テストプランの実行中に必要とされる追加的なロジックも提供する。テストプランは、いくつかの基本的なサービスをサポートし、デバッグサービス(例えばブレークポイント)等のその下にあるオブジェクトのサービスに対するインタフェースと、その下にあるフレームワークおよび標準クラスへのアクセスとを提供する。
サイトコントローラに関連するフレームワーククラス246は、共通のテスト関連動作をインプリメントするクラスおよび方法のセットである。サイトコントローラレベルフレームワークは、例えば、電力供給およびピンエレクトロニクスの順番付け、レベルおよびタイミング条件の設定、測定値取得、テストフロー制御のためのクラスを含んでいる。フレームワークオブジェクトは、標準インタフェースをインプリメントすることを通じて動作してもよい。例えば、テスタピンフレームワーククラスのインプリメンテーションは、テストクラスがハードウェアモジュールピンと相互に作用するために用いるであろう汎用のテスタピンインタフェースをインプリメントするように統一される。
あるフレームワークオブジェクトは、モジュールと通信するためにモジュールレベルインタフェース247の助けを借りて動作するようにインプリメントされてもよい。サイトコントローラフレームワーククラスは、実質的に、各サイトコントローラをサポートするローカルオペレーティングシステムとして機能する。
一般的に、プログラムコードの90%以上は装置テスト用のデータであり、残りの10%のコードがテスト方法を実現する。装置テストデータはDUT依存のデータ(例えば電力供給条件、信号電圧条件、タイミング条件等)である。テストコードは、指定された装置条件をATEハードウェア上にロードする方法からなり、またユーザが指定した目的(データロギング等)を実現するのに必要である方法からも構成される。発明の一実施形態のフレームワークは、ハードウェア依存性のテストと、ユーザがDUTテストプログラミングのタスクを行うことを可能にするテスタオブジェクトモデルとを提供する。
テストコードの再利用性を高めるために、このようなコードは、装置特有のデータ(例えばピンの名前、刺激データ等)、あるいは装置テストに特有のデータ(例えばDCユニットの条件、測定ピン、ターゲットピンの数、パターンファイルの名前、パターンプログラムのアドレス)のいずれに対しても独立とされてもよい。もしテスト用のコードをこれらのタイプのデータとともにコンパイルすれば、テストコードの再利用性は低下する。したがって、発明の一実施形態によれば、いかなる装置特有のデータあるいは装置テストに特有のデータも、コード実行期間中の入力として、外部からテストコードに役立てられてもよい。
発明の一実施形態においては、標準テストインタフェースのインプリメンテーションであるテストクラスは、ここでたITestと記載するが、特定のタイプのテストに関してテストデータとコードとの分離(したがってコードの再利用性)を実現する。このようなテストクラスは、装置特有および/あるいは装置テスト特有のデータにおいてのみ異なるような別々のテストクラスの「テンプレート」とみなしてもよい。テストクラスはテストプランファイルにおいて指定される。各テストクラスは、典型的には、具体的なタイプの装置テストあるいは装置テスト用のセットアップをインプリメントする。例えば、発明の一実施形態は、DUTに関するすべての機能テストの基本となるクラスとして、ITestインタフェースの具体的なインプリメンテーション、例えばFunctionalTestを提供する。それは、テスト条件の設定、パターンの実行および、失敗したストローブの存在に基づくテスト状況の判定という基本的な機能を提供する。他のタイプのインプリメンテーションは、ここではACParametricTestおよびDCParametricTestとして表記されるACおよびDCテストクラスを含んでいてもよい。
全てのテストタイプは、いくつかの仮想的な方法のデフォルトのインプリメンテーション(例えば、init( )、preExec( )およびpostExec( ))を提供してもよい。これらの方法は、デフォルトの動作を乗り越えてテスト特有のパラメータを設定するためのテストエンジニアのエントリポイントとなる。しかしながら、カスタムテストクラスもテストプランにおいて用いることができる。
テストクラスは、そのテストの特定の場合に関するオプションを指定するために用いられるパラメータを提供することによって、ユーザがクラスの動作を構成することを可能にする。例えば、機能テストは、実行すべきパターンリストとテスト用のレベルおよびタイミング条件とを指定するために、パラメータPlistおよびTestConditionと採用してもよい。(テストプラン記述ファイルにおける異なる「テスト」ブロックの使用を通して)これらのパラメータについて異なる値を指定することにより、ユーザは機能テストの異なる例を作り出すことが可能である。図4は、どのようにして単一のテストクラスから異なるテスト例が導き出されるかを示している。テンプレートライブラリは、一般的なアルゴリズムおよびデータ構造の汎用ライブラリとして採用されてもよい。このライブラリはテスタのユーザに見えてもよく、ユーザは、例えば、ユーザ定義のテストクラスを作り出すようにテストクラスのインプリメンテーションを改変してもよい。
ユーザによって展開されるテストクラスに関して、システムの一実施形態は、このようなテストクラスを、全てのテストクラスが単一のテストインタフェース、例えばITestから得られるようなフレームワークに統合することをサポートし、その結果、そのフレームワークはシステムテストクラスの標準的なセットと同じようなやり方でそれらを処理することができる。ユーザは、追加のファシリティを生かすためには自分達のテストプログラムにおいてカスタムコードを用いなければならないという理解のもとで、自分達のテストクラスに追加の機能を自由に追加することができる。
各テストサイト110は、一つ以上のDUT106のテスト専用のものであり、テストモジュール112の構成可能な集合体を通じて機能する。各テストモジュール112は特定のテストタスクを行う主体である。例えば、テストモジュール112は、DUTの電源、ピンカード、アナログカード等であり得る。モジュールによるこのアプローチは、高いフレキシビリティと構成可能性を提供する。
モジュールコマンドインプリメンテーションクラス248は、モジュールハードウェアベンダによって提供されてもよく、ベンダによって選択されるコマンド実行方法に応じて、ハードウェアモジュールに関するモジュールレベルインタフェースをインプリメントするか、あるいは標準的なインタフェースのモジュール特有のインプリメンテーションを提供する。これらのクラスの外部インタフェースは、所定のモジュールレベルインタフェース要件およびバックプレーン通信ライブラリ要件によって規定される。またこのレイヤは、標準的なセットのテストコマンドの拡張も提供し、それにより方法(機能)およびデータ要素の追加が可能となる。
バックプレーン通信ライブラリ249は、バックブレーンをまたいでの標準的な通信のためのインタフェースを提供し、それによってテストサイトに接続されたモジュールとの通信に必要な機能を提供する。これにより、ベンダに特有のモジュールソフトウェアが対応するハードウェアモジュールとの通信にバックプレーンドライバ250を用いることが可能である。バックプレーン通信プロトコルはパケットベースのフォーマットである。
テスタピンオブジェクトは、物理的なテスタチャネルを表しており、ここではITesterPinで示されるテスタピンインタフェースから得られる。発明の一実施形態によるソフトウェア展開キット(SDK)は、TesterPinと呼ばれることもあるITesterPinのデフォルトのインプリメンテーションを提供し、これは所定のモジュールレベルインタフェースIChannelに関してインプリメントされる。ベンダは、IChannelに関して彼らのモジュールの機能をインプリメントすることができるのであればTesterPinを自由に使うことができるが、そうでなければ、彼らのモジュールとどもに動作するITesterPinのインプリメンテーションを提供しなければならない。
発明のテスタシステムによって提供される標準的なモジュールインタフェースは、ここではIModuleと表記するが、これは一般的には、ベンダのハードウェアモジュールを表している。ベンダによって供給される、システム用のモジュール特有のソフトウェアは、ダイナミックリンクライブラリ(DLL)のような実行可能な形態で提供されてもよい。ベンダからの各モジュールタイプ用のソフトウェアは、単一のDLLにカプセル化されていてもよい。このようなソフトウェアモジュールのそれぞれは、モジュールソフトウェア展開のためのAPIを備えている、モジュールインタフェースコマンド用のベンダに特有なインプリメンテーションを提供することを担っている。
モジュールインタフェースコマンドには2つの局面がある。それらは、第一に、ユーザがシステムにおける特定のハードウェアモジュールと(間接的に)通信するためのインタフェースとして機能し、第二に、サードパーティディベロッパが彼ら自身のモジュールをサイトコントローラレベルのフレームワークに統合するために活用することができるインタフェースを提供する。したがって、フレームワークによって提供されるモジュールインタフェースコマンドは、2つのタイプに分けられる。
一つ目は、最も疑う余地のないものであるが、フレームワークインタフェースを通じてユーザに対してあらわになる「コマンド」である。したがって、例えば、テスタピンインタフェース(ITesterPin)は、レベルおよびタイミングの値を取得、設定するための方法を提供し、一方で電源インタフェース(IPowerSupply)は電力を上げたり下げたりする方法を提供する。
また、フレームワークは、モジュールとの通信に用いられることができる、所定のモジュールレベルインタフェースの特別なカテゴリを提供する。これらは、ベンダのモジュールとの通信のためにフレームワーククラスによって用いられるインタフェース(すなわち、フレームワークインタフェースの「標準的な」インプリメンテーション)である。
しかしながら、第二の局面、モジュールレベルインタフェースの使用は、任意のものである。それをすることの利点は、ベンダは、モジュールレベルインタフェースをインプリメントすることによって彼らのハードウェアに対して送られる具体的なメッセージの内容を注視しつつ、ITesterPinおよびIPowerSupplyのようなクラスのインプリメンテーションを活用し得るということである。しかし、もしこれらのインタフェースがベンダに不適切であれば、それらはフレームワークインタフェースのそれらのカスタムインプリメンテーション(例えばITesterPin、IPowerSupply等のベンダインプリメンテーション)を提供することを選択してもよい。そうすればこれらは、それらのハードウェアに対して適切であるカスタム機能を提供するであろう。
したがって、モジュールに特有なベンダソフトウェアの統合は、2つの異なった手段、すなわち、関連するフレームワーククラスおよびインタフェースのカスタムインプリメンテーション、あるいはモジュールレベルインタフェースの特別なカテゴリのカスタムインプリメンテーションを通じて実現され得る。
次に、両方の方法の例示的な応用を図5の助けを借りて説明する。図5は、発明の一実施形態によるテスタシステムとベンダによって供給されるモジュールとの相互作用を示すユニバーサルモデリング言語(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インタフェースを使用している間、ユーザは、必要なときにモジュールベンダによって提供される具体的な特徴および拡張を自由に使うことができる。言い換えると、モジュールベンダは、例えば、クラスの標準的なシステムインプリメンテーションに方法(機能)を付加することができる。ユーザに対するトレードオフは、具体的なベンダの拡張を活用することが他のベンダのモジュールに対するテストコードの有用性を低下させるということである。
モジュールのレベルでは、システム100は、名目上2つの動作モードを有している。動作のオンラインモードでは、モジュールエレメント260(例えばハードウェアエレメント)が用いられ、動作のオフラインモードではソフトウェアにおけるモジュールエミュレーション280が用いられる。
動作のオンラインモードについて、モジュールエレメント260は、HW(ハードウェア)バックプレーン261、シャーシスロットIF(インタフェース)262、モジュールハードウェア263、ロードボードハードウェアIF264、ハードウェアロードボード265およびDUT266を有している。
動作のオフラインモードについて、ソフトウェアでのモジュールエミュレーション280は、シミュレーションフレームワーク281、バックプレーンエミュレーション282、バックプレーンシミュレーションIF283、モジュールエミュレーション284、ロードボードシミュレーションIF285、ロードボードシミュレーション286およびDUTシミュレーションIF287を有している。2つのモデルをDUTシミュレーションに関して示す。Verilogを用いるモデルは、Verilog PLI(プログラミング言語インタフェース)288とDUT Verilogモデル293とを有している。C/C++を用いるモデルは、C/C++言語サポート289とDUT C/C++モデル291とを有している。シミュレーションは、PC等のいかなるコンピュータ上でも行うことができることに留意されたい。
オンラインモードでは、モジュールベンダは、デジタルテスタチャネル、DUT電源、あるいはDC測定ユニットといった、テストをサポートするための物理的なハードウェアコンポーネントを提供する。モジュールは、シャーシスロットIF262を通じてHWバックプレーン261にインタフェース接続される。
オフラインでの作業については、システムコントローラと等価なものを動かすPCベースあるいは他の環境が、付加的に、サイトコントローラレベルのフレームワークと、ソフトウェアのより低いレイヤのランタイム環境とを提供するとともにハードウェアをエミュレートするための全ての任務を引き受ける。
バックプレーンエミュレーション282は、物理的なバックプレーン261のためのソフトウェアによる代理を提供する。これは、バックプレーンシミュレーションインタフェース283を通して(ベンダが供給する)モジュールエミュレーションソフトウェア284と通信する。
モジュールエミュレーションソフトウェア284は、好ましくはモジュールベンダによって提供され、典型的にはモジュール263の特定のベンダインプリメンテーションと密接に結びついている。したがって、モジュールエミュレーションソフトウェアは、典型的には、異なるベンダによって供給されるモジュール間で詳細で異なっている。この場合、モジュールシミュレーションにより、ベンダは、ソフトウェアモデル(例えばモジュールエミュレーションソフトウェア284)を通してハードウェアの機能をあらわにし、シミュレートされるロードボード286に対して刺激信号を送り、DUTシミュレーションIF287を介してDUTモデリングソフトウェア291、293に接続されているシミュレートされるロードボード286からのDUT応答信号を受け取って処理することが可能になる。モジュールの単純な機能シミュレーションを提供してモジュールファームウェアのエミュレーションを迂回することが有利であるとベンダが考える場合もある。モジュールエミュレーションソフトウェアは、シミュレートされたモジュール刺激信号に対するシミュレートされたDUTの応答を、既知の良好なDUT応答と比較する。この比較に基づいて、ソフトウェアは、そのモジュールによって実行されているテストが所望のとおりDUTをテストするという目標に適合しているかを判断し、ユーザがオンラインの実際のテスタ上のIC(実際のDUT)上でそれを用いるのに先立って、モジュールのデバッグを行うことを助ける。
ロードボードシミュレーションインタフェース285は、モジュールエミュレーションレイヤおよびシミュレートされるロードボード286への、およびこれらからの信号のためのルートとして機能する。ロードボードシミュレーションコンポーネント286は、デバイスソケットマッピングと、DUTシミュレーションIF287への、およびそれからの信号伝達とをサポートする。
DUTシミュレーションは、ネイティブコード(すなわちC/C++)シミュレーション291、または目的のテスト対象装置293の機能モデルに対するVerilogプログラミング言語インタフェース(PLI)であってもよい。このモデルは、DUTシミュレーションインタフェース287を通じて、シミュレートされるロードボードとインタフェース接続する。
これらのレイヤの全体の制御はシミュレーションフレームワーク281によって提供されることに留意されたい。シミュレーションフレームワークは、既知の刺激信号に対するシミュレートされたDUT応答を測定する。システムエミュレーションの方法は、米国出願第10/403,817号に開示されている。
通信および制御
通信および制御
通信および制御は、関連するソフトウェアオブジェクトの管理を通じて実現される。好ましくは、通信のメカニズムは、システムコントローラ上のオブジェクトモデルの後ろに隠れている。このオブジェクトモデルは、サイトコントローラ上に見られるクラスおよびオブジェクトに対してプロキシを提供し、それによって、アプリケーションの展開(例えばIC装置のテスト)のための便利なプログラミングモデルを提供する。これにより、アプリケーションの開発者(例えばATEシステムのユーザ)は、アプリケーションとサイト/システムコントローラとの間の通信の具体的な情報に関連する不要な詳細を避けることが可能である。
図6は、サイトコントローラソフトウェア240内にサイトコントローラ104によって維持されているときのサイトコントローラオブジェクトの具体的な実施形態を示している。サイトコントローラオブジェクトは、CmdDispatcher602、FunctionalTestMsgHandler604およびFunctionalTest606を有している。インタフェースは、IMsgHandler608およびITest610を有している。
好ましくはサイトコントローラ240は、アプリケーションがアクセスのために必要とする機能クラスの全てを含んでいる。これらのクラスは、例えば、テスト、モジュール、ピン等を含む。ユーザのテストおよびソフトウェアツールは典型的には異なるコンピュータ上に存在するので、メッセージは、システムコントローラ上のツールからサイトコントローラ上のサーバに送られる。このサーバは、コマンド発送オブジェクトに関する方法を必要とする。
コマンド発送オブジェクト(CmdDispatcher)602は、IMsgHandlerインタフェース608をインプリメントするメッセージハンドラオブジェクトのマップを保持する。図6は、IMsgHandlerの具体的なインプリメンテーションFunctionalTestMsgHandler604を示している。DmdDispatcherオブジェクト602によって受信されたメッセージは通信すべきオブジェクトの識別子を含んでいる。この識別子は、内部のマップにおいて見られ、具体的なインプリメンテーション、この場合には図示されているFunctionalTestMsgHandlerオブジェクト604に帰着する。
本例では、IMsgHandler608は、単一の方法handleMessage()からなる。この方法は、好ましくは単一のインプリメンテーションクラスとしてインプリメントされる。図示されている場合においては、FunctionalTestMsgHandler604は、入ってくるメッセージの正確な性質に応じて、6つの方法のうちの1つにメッセージを送る。入ってくるメッセージのヘッダは、メッセージハンドラがどのようにメッセージを解釈し、どこにメッセージを送るかを決定することを可能にするメッセージIDを含んでいる。
システムコントローラ102における対応する通信環境は、システムコントローラソフトウェア220のツール225、226セクションに関連する。図7は、システムコントローラソフトウェア220においてシステムコントローラ102上に保持されるツールオブジェクト(あるいはシステムコントローラオブジェクト)の一実施形態を、図6に示したサイトコントローラオブジェクトと対応するように示している。ツールオブジェクトは、オブジェクトCmdDispatcher702、FunctionalTestMsgHandler704およびFunctionalTestProxy706を含んでいる。インタフェースは、IMsgHandler708、ITestClient710、およびIDispatch712を含んでいる。またユーティリティアプリケーション714も含まれる。
この例に関して、クラスCmdDispatcher702、IMsgHandler708、およびFunctionalTestMsgHandler704は図6に示したものと同じである。しかしながら、FunctionalTest606(あるいは他のいかなるサイトコントローラクラス)のインスタンス化は用いられない。代わりに、ツールオブジェクトは、サイトコントローラ104上の各オブジェクトと通信するためのプロキシクラスを有している。したがって例えば、ツールオブジェクトはFunctionalTest606に代えてクラスFunctionalTestProxy706を含んでいる。同様に、ツールオブジェクトにおけるITestClient710は、サイトコントローラオブジェクトにおけるITest610と同じではない。一般的に、サイトコントローラ102上で動作するアプリケーションは、サイトコントローラ104上に設けられているものそのもののようなインタフェースを用いない。この場合、ITest610の3つの方法(すなわち、preExec()、execute()およびpostExec())はITestClient710における単一の方法(すなわちrunTest())に置き換えられる。またITestClient710は、好ましくはデュアルインタフェース、すなわち、IDispatch712を受け継ぐものであり、マイクロソフトコンポーネントオブジェクトモデル(COM)としてインプリメントされる。それは、そのインタフェースをインプリメントするオブジェクトへのスクリプトエンジンのアクセスを可能にするようなインタフェースを提供する。これによって、システムをマイクロソフトウィンドウズプラットフォーム上で記述することが可能となる。
図6〜7に示す実施形態の動作の一例として、(例えば、ツールセクション226、228のうちの一つにおいて)システムコントローラ102上で動作するアプリケーションは、テストプラン242が一つ以上のFunctionalTestオブジェクト606を有しているようなサイトコントローラ104と通信してもよい。サイトコントローラ104上でのテストプラン242の初期化中に、対応するテストプランオブジェクトはサイトコントローラ104上にロードされ、TestPlanMessageHandlerオブジェクトを構成し、それをCmdDispatcherオブジェクト602とともに登録する。これがメッセージハンドラに独自のIDを割り当てる。同様な動作は、テストプラン242を構成する他のTestPlanオブジェクトでも起こる。
システムコントローラ103上の(例えばツール226、228における)アプリケーションは、通信ライブラリ230を初期化し、通信チャネルを介してサイトコントローラ104に接続し、TestPlanオブジェクトのためのIDを取得する。この初期化中に、プロキシオブジェクトは、それがテストをいくつ含んでいるかと、それらのタイプおよびIDとを決定する。それはタイプごとに(この場合には一つだけのタイプ)適切なDLLをロードし、それらに関するプロキシオブジェクトを構成し、それらをID値を用いて初期化する。
TestProxyオブジェクトも初期化する。これをするために、それらは、それらの名前を(それらのID値を用いて)取得するための適切なメッセージを構成してサイトコントローラ104の通信サーバに送信する。通信サーバは、メッセージをCmdDispatcher602に渡す。このオブジェクトは、その内部マップにおいて宛先IDを調べて、FunctionalTestMsgHandler604のhandleMessage()方法にメッセージを送る。例えばもしメッセージがテスト名取得の要求であれば、これらのオブジェクトは、それぞれのテスト名を取得し、適切なネーム列でアプリケーションのTestProxyオブジェクトに応答する。
初期化が完了すると、アプリケーションは、TestPlanオブジェクトへのリモートアクセスと、それを通じて両方のTestオブジェクトへのリモートアクセスを有する。ユーザはここで、例えば、アプリケーション上の「テストプラン起動」のボタンを押す。その結果、アプリケーションはTestPlanProxyオブジェクト上のRunTestPlan()方法を呼び出す。この方法は、TestPlanオブジェクトの宛先IDでRunTestPlanメッセージを構成し、RPCプロキシ上でsendMessage()機能を呼び出す。この機能がサイトコントローラにメッセージを送信する。
サイトコントローラ104上の通信サーバは、CmdDispatcherオブジェクト602上のhandleMessage()方法を呼び出し、TestPlanオブジェクトのIDをそれに渡す。CmdDispatcherオブジェクト602はその内部マップでこのIDを調べて、TestPlanオブジェクト用のメッセージハンドラを見つけて、このオブジェクト上のhandleMessage()方法を呼び出し、これがTestPlanオブジェクト上のRunTestPlan()方法を呼び出す。同じようなやり方で、アプリケーションは名前とTestオブジェクトの最近の動作状況とを取得することができる。
通信ライブラリを用いる方法
通信ライブラリを用いる方法
通信ライブラリ230を用いる例を以下に述べる。
通信ライブラリ230は好ましくは静的なライブラリである。アプリケーションは、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)
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("}")
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の定義を提供することが好ましい。全てのメッセージタイプは、1から始まらなければならない(ゼロは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)
}
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 は、通信DLL’sによりエクスポーズされる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().
システム構成とテスト
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().
システム構成とテスト
図8は、本発明の一実施形態による名目上のテストシーケンス800を示している。テストシーケンス800は、テスト環境804におけるモジュールの設置802を含んでおり、これはテスト準備806とシステムテスト808とを包含している。初めに新しいモジュール(ハードウェアまたはソフトウェアまたはこれらの組み合わせ)810が(ベンダの品質管理に基づいているかもしれないいくつかの外部手順によって)認証812される。設置802はまず、オフラインシミュレーション810のためのハードウェアモジュールエミュレーションの設定、テストプログラム展開812のためのモジュールリソースファイルおよびインタフェースの設定、ならびにパターンコンパイル814のためのモジュール特有のパターンコンパイラの設定を含むテスト準備806を必要とする。次にシステムテスト808が、較正816、診断818および構成820からの入力を用いて実行される。そして新しいモジュールに対して、(1)インタフェース制御、(2)同期、順序付けおよび再現性、(3)エラー/アラーム対応、(4)マルチサイト制御、ならびに(5)マルチインストゥルメントモジュール制御を含むシステムテスト808が行われる。
以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。その様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。
100 システムアーキテクチャ
102 システムコントローラ
104 サイトコントローラ
106 モジュール接続イネーブラ
108 モジュール
110 テストサイト
200 ソフトウェアアーキテクチャ
240 サイトコントローラソフトウェア
242 ユーザテストプラン
243 ユーザテストクラス
244 標準テストクラス
246 フレームワーククラス
245 標準インタフェース
247 モジュールレベルインタフェース
248 モジュールコマンドインプリメンテーション
249 バックプレーン通信ライブラリ
250 PCIバックプレーンドライバ
260 モジュール
261 HWバックプレーン
262 シャーシスロットIF
263 モジュールハードウェア
264 ロードボードハードウェアIF
265 ハードウェアロードボード
280 SWにおけるモジュールエミュレーション
281 シミュレーションフレームワーク
282 バックプレーンエミュレーション
283 バックプレーンシミュレーションIF
284 モジュールエミュレーション
285 ロードボードシミュレーションIF
286 ロードボードシミュレーション
287 DUTシミュレーションIF
290 オペレーティングシステムインタフェース
291 DUT C/C++モデル
292 ユーザコンポーネント
293 DUT Verilogモデル
294 システムコンポーネント
296 モジュール展開コンポーネント
298 外部コンポーネント
804 テスト環境
817 較正
818 診断
820 構成
806 テスト準備
814 テストプログラム展開
808 テストシステム
810 新しいHWまたはSWモジュール
812 認証
102 システムコントローラ
104 サイトコントローラ
106 モジュール接続イネーブラ
108 モジュール
110 テストサイト
200 ソフトウェアアーキテクチャ
240 サイトコントローラソフトウェア
242 ユーザテストプラン
243 ユーザテストクラス
244 標準テストクラス
246 フレームワーククラス
245 標準インタフェース
247 モジュールレベルインタフェース
248 モジュールコマンドインプリメンテーション
249 バックプレーン通信ライブラリ
250 PCIバックプレーンドライバ
260 モジュール
261 HWバックプレーン
262 シャーシスロットIF
263 モジュールハードウェア
264 ロードボードハードウェアIF
265 ハードウェアロードボード
280 SWにおけるモジュールエミュレーション
281 シミュレーションフレームワーク
282 バックプレーンエミュレーション
283 バックプレーンシミュレーションIF
284 モジュールエミュレーション
285 ロードボードシミュレーションIF
286 ロードボードシミュレーション
287 DUTシミュレーションIF
290 オペレーティングシステムインタフェース
291 DUT C/C++モデル
292 ユーザコンポーネント
293 DUT Verilogモデル
294 システムコンポーネント
296 モジュール展開コンポーネント
298 外部コンポーネント
804 テスト環境
817 較正
818 診断
820 構成
806 テスト準備
814 テストプログラム展開
808 テストシステム
810 新しいHWまたはSWモジュール
812 認証
Claims (24)
- 少なくとも一つのテスト対象装置(DUT)をテストする半導体テストシステムのための分散オペレーティングシステムであって、
システムコントローラによる少なくとも一つのサイトコントローラの制御を可能にするホストオペレーティングシステムと、
各サイトコントローラと関連しており、関連するサイトコントローラによる少なくとも一つのテストモジュールの制御を可能にする少なくとも一つのローカルオペレーティングシステムとを備えており、
少なくとも一つのテストモジュールが対応するDUT上でテストを行う分散オペレーティングシステム。 - 前記ホストオペレーティングシステムは、前記少なくとも一つのサイトコントローラの動作を同期させる請求項1に記載の分散オペレーティングシステム。
- 前記ホストオペレーティングシステムは、前記システムコントローラと前記少なくとも一つのサイトコントローラとの間の通信を仲裁する請求項1に記載の分散オペレーティングシステム。
- 前記システムコントローラは、前記少なくとも一つのサイトコントローラの動作をモニタする請求項1に記載の分散オペレーティングシステム。
- サイトコントローラは、当該サイトコントローラに関連する前記少なくとも一つのテストモジュールの動作をモニタする請求項1に記載の分散オペレーティングシステム。
- 前記ホストオペレーティングシステムは、前記少なくとも一つのサイトコントローラと通信するための少なくとも一つのホストインタフェースを備えている請求項1に記載の分散オペレーティングシステム。
- 前記少なくとも一つのホストインタフェースは、サイトコントローラに関連している少なくとも一つのテストモジュールと通信するためのものである請求項6に記載の分散オペレーティングシステム。
- 前記分散オペレーティングシステムは、サイトコントローラを第一のテストモジュールにインタフェース接続するためのテストモジュール機能を規定するテストモジュールインタフェースをさらに備えており、前記テストモジュールインタフェースは、前記サイトコントローラを第二のテストモジュールにインタフェース接続するように拡張可能であり、前記拡張されていないテストモジュールインタフェースは、前記サイトコントローラを前記第二のテストモジュールにインタフェース接続するには不十分である、請求項1に記載の分散オペレーティングシステム。
- 前記ホストオペレーティングシステムは、少なくとも一つのホストフレームワーククラスを有している請求項1に記載の分散オペレーティングシステム。
- 前記少なくとも一つのフレームワーククラスは、前記少なくとも一つのサイトコントローラを制御するためのアプリケーション特有のクラスをユーザが展開ことを可能にするように標準的なコンピュータ言語で展開される請求項1に記載の分散オペレーティングシステム。
- 前記標準的なコンピュータ言語はCまたはC++である請求項10に記載の分散オペレーティングシステム。
- 各ローカルオペレーティングシステムは、少なくとも一つのローカルフレームワーククラスを有している請求項1に記載の分散オペレーティングシステム。
- 前記少なくとも一つのローカルフレームワーククラスは、前記少なくとも一つのテストモジュールを制御するためのアプリケーション特有のクラスをユーザが展開することを可能にするように標準的なコンピュータ言語で展開される請求項12に記載の分散オペレーティングシステム。
- 前記標準的なコンピュータ言語はCまたはC++である請求項13に記載の分散オペレーティングシステム。
- 各サイトコントローラによって制御されるモジュールの数は計数可能である請求項1に記載の分散オペレーティングシステム。
- 対応するサイトコントローラに関連している前記ローカルオペレーティングシステムは、前記サイトコントローラによって制御されるテストモジュールのタイプの再構成を可能にする請求項1に記載の分散オペレーティングシステム。
- 前記ホストオペレーティングシステムは、前記システムコントローラによって制御されるサイトコントローラの数を計数可能とする請求項1に記載の分散オペレーティングシステム。
- 前記ホストオペレーティングシステムは、前記テストシステムによってテストされるDUTの数を計数可能とする請求項1に記載の分散オペレーティングシステム。
- 前記少なくとも一つのテストモジュールは、ハードウェアおよび/またはソフトウェアを備えている請求項1に記載の分散オペレーティングシステム。
- 対象テストモジュールを前記テストシステムとともに使用することをシミュレートして、前記対象モジュールが前記テストシステムと互換性があることを検証するエミュレータをさらに備えている請求項1に記載の分散オペレーティングシステム。
- 第一のテストサイトにおける第一のセットのモジュールは、第二のテストサイトにおける第二のセットのモジュールとは異なって構成されている請求項1に記載の分散オペレーティングシステム。
- 第一のテストサイトは第一のDUTをテストするための第一の構成を有しており、第二のテストサイトは第二のDUTをテストするための第二の構成を有しており、前記第一および第二のテストサイトは、代わりに第三のDUTをテストするための第三のテストサイトをともに形成するように再構成可能である請求項1に記載の分散オペレーティングシステム。
- 第一のテストサイトにおける第一のモジュールは、第二のテストサイトにおける第二のモジュールにアクセスすることができる請求項1に記載の分散オペレーティングシステム。
- テストモジュールとともに使用するための所定のセットの関数およびインタフェースを有している通信ライブラリをさらに備えている請求項1に記載の分散オペレーティングシステム。
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 |
---|---|---|---|
JP2006502669A Expired - Fee Related JP3954639B2 (ja) | 2003-02-14 | 2004-02-16 | 集積回路をテストする方法および装置 |
JP2006502670A Expired - Fee Related JP3939336B2 (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 |
---|---|---|---|
JP2006502669A Expired - Fee Related JP3954639B2 (ja) | 2003-02-14 | 2004-02-16 | 集積回路をテストする方法および装置 |
JP2006502670A Expired - Fee Related JP3939336B2 (ja) | 2003-02-14 | 2004-02-16 | 半導体集積回路用のテストプログラムを開発する方法および構造 |
Country Status (8)
Country | Link |
---|---|
EP (2) | EP1592976B1 (ja) |
JP (3) | JP3954639B2 (ja) |
KR (2) | KR20050099626A (ja) |
CN (1) | CN1784609B (ja) |
AT (1) | ATE384269T1 (ja) |
DE (1) | DE602004011320T2 (ja) |
TW (1) | TWI344595B (ja) |
WO (2) | WO2004072669A1 (ja) |
Cited By (4)
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)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7437261B2 (en) | 2003-02-14 | 2008-10-14 | Advantest Corporation | Method and apparatus for testing 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 |
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 |
US7197416B2 (en) | 2004-05-22 | 2007-03-27 | Advantest America R&D Center, Inc. | Supporting calibration and diagnostics in an open architecture 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 |
US7430486B2 (en) | 2004-05-22 | 2008-09-30 | Advantest America R&D Center, Inc. | Datalog support in 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 |
DE602005002131T2 (de) | 2005-05-20 | 2008-05-15 | Verigy (Singapore) Pte. Ltd. | Prüfvorrichtung mit Anpassung des Prüfparameters |
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)
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 |
-
2004
- 2004-02-13 TW TW093103547A patent/TWI344595B/zh not_active IP Right Cessation
- 2004-02-16 WO PCT/JP2004/001648 patent/WO2004072669A1/en active IP Right Grant
- 2004-02-16 KR KR1020057015017A patent/KR20050099626A/ko not_active Application Discontinuation
- 2004-02-16 AT AT04711471T patent/ATE384269T1/de not_active IP Right Cessation
- 2004-02-16 EP EP04711471A patent/EP1592976B1/en not_active Expired - Lifetime
- 2004-02-16 JP JP2006502669A patent/JP3954639B2/ja not_active Expired - Fee Related
- 2004-02-16 WO PCT/JP2004/001649 patent/WO2004072670A1/en active IP Right Grant
- 2004-02-16 KR KR1020057015016A patent/KR20050101216A/ko not_active Application Discontinuation
- 2004-02-16 DE DE602004011320T patent/DE602004011320T2/de not_active Expired - Lifetime
- 2004-02-16 EP EP04711445A patent/EP1592975B1/en not_active Expired - Lifetime
- 2004-02-16 CN CN2004800096901A patent/CN1784609B/zh not_active Expired - Fee Related
- 2004-02-16 JP JP2006502670A patent/JP3939336B2/ja not_active Expired - Fee Related
-
2006
- 2006-09-19 JP JP2006252498A patent/JP2007052028A/ja not_active Withdrawn
Cited By (4)
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 |
---|---|
KR20050099626A (ko) | 2005-10-14 |
TWI344595B (en) | 2011-07-01 |
EP1592975B1 (en) | 2008-03-26 |
DE602004011320D1 (de) | 2008-03-06 |
JP2006520947A (ja) | 2006-09-14 |
JP3954639B2 (ja) | 2007-08-08 |
WO2004072669A1 (en) | 2004-08-26 |
DE602004011320T2 (de) | 2009-02-05 |
ATE384269T1 (de) | 2008-02-15 |
CN1784609A (zh) | 2006-06-07 |
JP2006518460A (ja) | 2006-08-10 |
WO2004072670A1 (en) | 2004-08-26 |
CN1784609B (zh) | 2011-02-23 |
TW200508855A (en) | 2005-03-01 |
KR20050101216A (ko) | 2005-10-20 |
EP1592975A1 (en) | 2005-11-09 |
EP1592976A1 (en) | 2005-11-09 |
JP3939336B2 (ja) | 2007-07-04 |
EP1592976B1 (en) | 2008-01-16 |
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 |