JP4972244B2 - 低コストで使用が容易な自動テスト・システム用ソフトウェア - Google Patents

Description

本発明は、広くは、半導体製造において用いられる自動テスト（試験）装置に関し、更に詳しくは、そのようなテスト・システムのための制御ソフトウェアに関する。
自動テスト装置は、半導体の製造において広く用いられている。半導体は、その製造の間に少なくとも１回はテストがなされるのが一般的であり、時には、製造プロセスにおいて複数回のテストがなされることもある。すべての素子がテストされるのであるから、テスト速度は、半導体の経済的な製造にとって重要である。ゆっくりとテストを行うのでは、半導体素子を製造するのに必要となる高価な設備である装置を完全に用いないことになる。
現代の半導体素子は非常に複雑であり、多くの動作状態を有する。完全なテストを実行するには、これらの動作状態のそれぞれを確認してみなければならない。従って、自動テスト装置は、テスト・データを半導体デバイスに与え、多数の測定を製造過程において行うように設計されている。図１には、従来技術による自動テスト・システムが一般化された態様で示されている。完全で迅速なテストを行うには、自動テスト・システムは、テスタ（試験装置）本体１１２と、コンピュータ化されたワークステーション１１０と、操作デバイス（handling device）１１４とを含むのが一般的である。
コンピュータ・ワークステーション１１０は、操作デバイス１１４とテスタ本体１１２との両方を制御する。コンピュータ・ワークステーション１１０は、半導体デバイス（図示せず）をテスタ本体１１２上の多数のテスト・プローブ１１８と接触する位置に位置決めするように、操作デバイス１１４を制御する。多くの場合、テスタは、テスト・プローブ１１８を含む別個のテスト・ヘッドを含んでいる。しかし、そのような区別は、本発明には重要ではない。
ワークステーション１１０は、次に、テスト対象であるデバイスに対して一連のテストを実行するように、テスタ本体１１２を制御する。それぞれのテストは、制御信号がワークステーション１１０からテスタ本体１１２に送られるセットアップ部分を含むのが一般的である。制御信号は、通常、バス１１６を介して送られるデジタル値である。これらの制御信号は、テストに必要な測定を行うようにテスタ本体１１２内のハードウェアのコンフィギュレーションを定める。テスタ本体内部のハードウェアは、制御信号に従って、刺激を与え、テスト対象デバイスからの応答を測定する。
図１には、テスタ本体１１２内のハードウェアがピン１２４として識別される多数の回路を含んでいる様子が示されている。それぞれのピン１２４は、テスト・プローブ１１８の１つに対して信号を発生し測定を行う。それぞれのピンは、静的（static）な、すなわち直流信号を提供しうる。また、それぞれのピン１２４は、時には「バースト（burst）」とも称される状況では、変化するデータを提供又は測定することもあり得る。
バーストの間には、テスタ本体１１２は、タイミング及びシーケンシング（sequencing）回路１２０によって制御される。タイミング及びシーケンシング回路１２０は、ピン１２４のそれぞれに、関連するメモリ１２８から一連のデータ値を読み出させる。それぞれのデータ値は、ピンがその関連するテスト・プローブ１１８で特定の時点において与えるべき又は測定を予測すべき信号のタイプを示す。ピンが測定値を予測値と比較すると、その結果もまたメモリ１２８に記憶されうる。
１回にすべてのピン１２４が提供すべき又は測定を予測すべき値を定義するデータ値の組は、「ベクトル」と称される。バーストの間には、多くのベクトルが実行される。テスト対象デバイスの実際の動作条件をシミュレートするには、ベクトルは、非常な高速で実行されなければならない。半導体デバイスをテストするのに必要なバーストを定義するには、数百万のベクトルが存在する。これらのベクトルは、典型的には、テスト・システムが特定のタイプのパーツをテストするようにプログラムされている時刻において、メモリ１２８にロードされる。このローディング・プロセスには数分を要することがあり、それぞれのバーストに対して反復されない。むしろ、それぞれのバーストに対して、ワークステーション１１０は、どのベクトルがバーストの一部として実行されるべきかを示すコマンドを送る。バーストがいったん完了すると、ワークステーション１１０は、バーストの結果を、メモリ１２８又はタイミング及びシーケンシング回路１２０から読み出す。
更に、テスタ本体１１２は、１つ又は複数の器具（instruments）１２６を含む。１つの器具が、特定のテスト機能を実行する。器具は、例えば、正弦波などの特定のテスト信号を発生しうる。また、器具は、高速で信号をサンプリングし、それによって、後でデジタル信号プロセッサによる解析が可能にすることもある。これらの機能は、あるバーストの一部として実行されることもあるし、バーストとは別に実行されることもある。
１つのパーツの完全なテストは、時には「ジョブ」と呼ばれるが、直流測定又は器具１２６による測定に対して散在する一連のバーストから構成される。バーストは、テスト対象デバイスの特定の機能的属性（functional attributes）を測定するのに用いられ得る。また、それぞれのバーストは、テスト対象デバイスを直流測定が実行可能な状態におく目的だけに用いられることもある。テストのこれらの構成要素が実行される順序は、時には「フロー」とも呼ばれるが、ワークステーション１１０内のソフトウェアによって決定される。
あるデバイスが完全にテストされる、又は、欠陥があると判断される時点までテストされると、ワークステーション１１０は、制御信号を操作デバイス１１４に対して発生する。すると、操作デバイス１１４は、次にテストされるべきデバイスをテスタ本体１１２に提供し、プロセスが反復される。ワークステーション１１０は、また、特定のデバイスがテストに合格した又は失格したことに関するデータを収集する。ワークステーション１１０は、このデータを処理し欠陥のあるデバイスが廃棄されるようにすることができるし、また、欠陥の傾向に関するデータを解析するなど、それ以外の機能を実行することもできる。
ワークステーション１１０の中のソフトウェアのもう１つの重要な機能として、特定のデバイスに対するテストの開発（development）中や、更にはデバイスの設計それ自体の間にも、補助的機能を果たすことがある。開発の間には、テスト・エンジニアは、テスタ本体１１２内部のハードウェアに対する設定などを特定できなければならない。技術者は、また、テストのフローを特定できなければならない。テスタを制御するソフトウェアは、融通性があり、学習及び使用が非常に容易であることが非常に望ましい。半導体チップの市場は、非常に競争が激しく、多くの場合、技術革新によって左右される。従って、チップが可能な限り迅速に開発され製造の準備が整うことは、重要である。テスト・エンジニアがテスタのプログラム方法を学ぶ必要があるために遅れが生じるようなことは望ましくない。
図２には、ワークステーション１１０内のソフトウェアのための伝統的なソフトウェア・アーキテクチャが示されている。このソフトウェアは、テストの開発及び解析時に用いられる要素と、テストの実行時に用いられるソフトウェアとに分けられる。
テストを定義する第１のステップは、一般的には、デバイス・データを特定することである。図２には、デバイス・データ開発ツール２１０が示されている。伝統的には、これらのツールは、テスト対象である特定のデバイスに関するデータを集め、そのテスタのためにカスタム開発されたデータベースに記憶している。この情報は、これらをピン・グループ及びタイム・セット（time set）として定義する。半導体デバイスは、多くのデバイス・リードを有する。これらのリードは、グループとしてまとまって動作することが多い。例えば、あるグループは、アドレス・バス又はデータ・バスを表すことがあり得る。従って、あるツールによって、リードのグループを特定することが可能になる。別のツールによれば、デバイス上の特定のリードとテスタ上のピンとの間の相関関係を特定することが可能になる。場合によっては、特定のデータを、その値を別のデータ値に関係付ける方程式によって定義することが可能である。しかし、従来技術では、方程式を扱う能力は限定的なものであった。
他のツールによれば、信号のタイミングを特定することが可能となる。それぞれのピン１２４は、タイミング「エッジ」に関係して定義される信号を発生又は測定することができる。それぞれのピンには、１組のタイミング・エッジが存在する。それぞれのエッジは、実行されるそれぞれのベクトルに対して１回生じうる。それぞれのエッジが生じる時間は、プログラムすることができる。それぞれのピンに対するそれぞれのエッジに対するプログラムされた時間が、１組のタイミング・データを表す。異なるバーストにおいて又は同一のバーストの中でも所望のプログラミングは異なりうるので、複数のタイム・セットが特定されるのが通常である。それぞれのタイム・セットの組が入力され記憶されなければならない。この情報は、伝統的には、特定のテスタに対して設計されたカスタム・データベース・プログラムを介して入力されてきた。カスタム・データベースを介して入力された情報は、デバイス・データ・ファイル２１４に記憶される。
入力されなければならない別のタイプの情報は、あるテストのために実行されなければならない特定のステップである。この情報は、テスト・テンプレート２２０において特定される。テンプレートとは、どのような特定のデバイス・データ・ファイルの値とも独立に記述されるステップの組である。テスト・テンプレートは、特定のテスト・システムに対して定義されたフォーマットのデータ・ファイルとして記録されてきた。これらのファイルは、一般的には、テスタを製造した者によって提供され、典型的には、高速な実行速度で知られているＣプログラミング言語などのプログラミング言語で書かれている。場合によっては、テスト・エンジニアが、テスト・テンプレートをカスタマイズする。
テスト・テンプレートは、コンパイラ２５０によってコンパイルされる。コンパイルされたプログラムは、翻訳された（interpreted）プログラムよりも高速に実行可能であると、通常考えられている。テスタにおける実行速度に関する要件のために、コンパイルされたテスト・プログラムの方が好まれてきた。
カスタム・フロー・ツール２１８はまた、テストの順序の特定を可能にする。フローは、プログラム・フロー２２２として記録される。伝統的には、フローは、テーブルへの一連のエントリとして特定されるが、伝統的なプログラミング言語と類似する特別なプログラミング言語でも可能である。
フローのステップを特定するために、特定のテスト・テンプレートを、そのステップに対して用いられるべきデバイス・データ・ファイルと共に特定することもできる。あるテンプレートによって、実行されるバーストが特定される。また、他のテンプレートによって、テストの結果がテスタ１１２の中のハードウェアから読み出されることや、そのハードウェアが特定の方法でセットアップされることが決まる。フローの他のステップとして、伝統的なプログラミング言語において見られる分岐（branching）及びルーピング（looping）命令などの制御ステートメントがある。
プログラム・フローは、カスタム・エグゼクティブ（custom executive）２２４として機能する。カスタム・エグゼクティブ２２４は、プログラム・フローにおいて特定されたテンプレートの中に、デバイス・データ・ファイル２１４からのデータを満たす。これによって、テスト・オブジェクトが作成される。
テスト時間においては、カスタム・エグゼクティブ２２４は、テスト・オブジェクトを処理し、テスタ１１２を実際に制御する。カスタム・エグゼクティブ２２４は、データ及びコマンドをデバイス・ドライバ２２８を介してテスタ１１２に送る。カスタム・エグゼクティブ２２４の動作速度が全体のテスト時間を決定するのに大きな意味を有するので、カスタム・エグゼクティブは、伝統的に、プログラマにその実行を特定し従って最適化するオプションを与えるＣ言語などのプログラミング言語で書かれてきた。
デバイス・ドライバ２２８は、バス１１６を介して情報を送受信してテスタ１１２内部のハードウェアを制御するプログラム手順である。デバイス・ドライバ２２８は、低レベルのハードウェア制御を実行するので、そのような制御を許容するＣ言語などのプログラミング言語で書かれている。
すべてのデバイスができるだけ迅速にテストされることが、強く望まれる。従って、プログラム・フローにおけるそれぞれのステップを実行するのに要求される時間は、非常に短いことが望ましい。テスタ１１２又は操作デバイス１１４がコマンドに応答する又はそれを「実行」するのにかかる実際の時間は、ワークステーション１１０内のソフトウェアとは無関係である。しかし、ワークステーション１１０内のソフトウェアは、それぞれのコマンドを設定するのにかかる時間の長さである「オーバヘッド」を決定する。１つのジョブの実行時間を非常に短くするために、かなりの努力がなされている。従って、オーバヘッド時間もまた非常に短いことが非常に重要である。従来技術のシステムでは、これは、カスタム・エグゼクティブ２２４を用いて達成された。カスタム・エグゼクティブ２２４は、伝統的にＣ言語で書かれている。Ｃ言語は、設計されうるエグゼクティブの開発が迅速になされることを可能にする言語であると広く認められている。
Ｃ言語でカスタム・エグゼクティブ２２４を準備するのに伴う主な問題は、そのようなエグゼクティブを書くのに非常に長い時間がかかるということである。そのための費用は、文字通り数百万ドルになる可能性があり、数年の努力を要する可能性がある。カスタム・エグゼクティブを有することに伴う別の問題として、ユーザ・インターフェースもまたカスタム・インターフェースであるということがある。これは、テスタを操作している技術者は、テスタをプログラムする方法を学習するのに時間をかけなければならないことを意味しているが、これは、ほとんどのユーザにとって望ましくない。しかし、これまでは、これらの短所は、テスタを迅速に動作させるためには必要であると考えられてきた。
Ｃ言語でのカスタム・エグゼクティブの別の欠点として、ユーザ・インターフェース能力が極めて限定される可能性が大きいということがある。ユーザ・インターフェースは、テスタにとって特に重要である。というのは、テスタは、非常に異なったスキルのレベルを有する複数の人間によって様々な時に操作されるからである。デバイス及びテストの開発段階では、テスタは、熟練度の高い技術者によって操作される。しかし、いったんデバイス及びテストが開発されてしまうと、テスタは、中程度のスキルを有するプロダクション・ワーカー（production worker）によって操作される。従って、ユーザ・インターフェースは、生産段階では、極めて単純化されていなければならない。
テスタは、伝統的には、ワークステーション１１０上で動作する別個の生産インターフェースを有している。ユーザ・インターフェースは、伝統的には、１つのメニュとして実現されてきた。テスト・エンジニアは、メニュ上に、生産段階のテストにおいてオペレータが必要とするコマンドだけを配置する。従って、テスタと共に提供されるソフトウェアでは、メニュの形式でユーザ・インターフェースを作成することしかできなかった。不運なことであるが、メニュは階層的であるが、多くの操作はそうではない。従って、非階層的なインターフェースを迅速かつ容易に開発することを可能にするソフトウェアをテスタに提供することが望ましいだろう。
図２には、ワークステーション１１０に含まれる他のソフトウェア要素が示されている。メモリ１２８（図１）にロードされたベクトルは、大量のデータを表す。これらは、通常、ソフトウェア・シミュレータによって開発されるか、又は、自動化された方法で導かれる。これらは、ユーザによってマニュアルで入力されるのが通常である。ベクトル開発ツールによって、ユーザは、ベクトル・ファイルを編集することが可能になり、ベクトル・ファイルは、その後で、ベクトル及び結果ファイル２３４に記憶される。ベクトル・ファイルは、テストに先立って、メモリ１２８にロードされる。
同様にして、多数の連続するサイクルの間にテスト対象デバイスにおいて例えば測定された値を表している大量のデータがテストの間に集められた場合には、それは、バス１１６（図１）を介して戻される（passed back）。
ベクトル・ファイル２３４は、デバグ及び解析ツール２３０によってもアクセス可能である。デバグ及び解析ツールは、テストを開発しているエンジニア又はテスト対象のパーツを開発しているエンジニアによって用いられる。これらのツールによれば、ベクトルや結果をグラフィカルに表示したり、ユーザが、ベクトル・ファイルを修正したり予測される値を測定された値の上に重ね書きすることが可能になる。更に、デバグ及び解析ツールによると、ユーザは、テスタ１１２におけるハードウェアを直接にプログラムすることができるようになる。従って、これらのツールは、時には、デバイス・ドライバ２２８をコールすることもある。
典型的なシナリオでは、デバイス・データ及び開発ツール２１２と、テスト及びフロー開発ツール２１８と、デバグ及び解析ツールと、テスト・ベクトル開発ツール２３２とは、テスタと共に供給される。テスト対象デバイスがまだ開発中である間も、ユーザは、デバイス・データ及び開発ツール２１２を用いて、デバイスの特性を特定する。テスト及びフロー開発ツール２１８は、デバイス上でなされるいくつかのテストを特定するのに用いられる。
サンプル・デバイスが製造される。テスト・プログラムが動かされ、デバグ及び解析ツールが用いられて、これらのサンプル・デバイスがチェックされる。このプロセスでは、サンプル・デバイスにおける欠陥が検出される又はプログラムに伴う問題点が検出される。これらの問題点は、訂正され、更なるテストが作られ動作される。
開発プロセスが終了すると、半導体デバイスは、テスト・プログラムと共に、生産に移行される。生産においては、それぞれのパーツは、製造される際にテストがなされる。
発明の概要
以上の背景を鑑みると、本発明の目的は、迅速かつ安価に開発することができるテスタ制御ソフトウェアを提供することである。
更に、ユーザが容易かつ迅速に使い方を学習できるテスタ用ソフトウェアを提供することも本発明の目的である。
以上の及びそれ以外の目的は、市販のスプレッドシート・ソフトウェアを用いて、デバイス・データ・ファイルとテスト・テンプレートとプログラム・フローとを開発することで達成される。市販のスプレッドシート・ソフトウェアが、これらの機能のすべてを、要求される速度をもって、非常な低コストで提供することができ、更に、ユーザが高価なトレーニングを受けなくとも学習できる標準的なユーザ・インターフェースを与えてくれるという長所を有することを見いだされた。
【図面の簡単な説明】
本発明は、次の添付した図面と以下の詳細な説明を参照することによって、よりよく理解されるはずである。
図１は、従来技術によるテスタのハードウェア・ブロック図である。
図２は、従来技術によるテスタのためのソフトウェアのソフトウェア・ブロック図である。
図３は、本発明によるソフトウェアのソフトウェア・ブロック図である。
図４Ａないし９は、本発明と共に用いられるデバイス・データ・シートを図解している。
図１０Ａないし１１Ｃは、本発明と共に用いられるフロー・データ・シートを図解している。
図１２Ａ及び１２Ｂは、サンプル・テスト・テンプレートを示している。
図１３は、本発明によるフロー制御ソフトウェアの動作を示している図である。
図１４は、本発明によって容易に実現され得るオプショナルなプログラミング・インターフェースである。
図１５は、別の市販のスプレッドシート・プログラムを用いて実現されるデバイス・データ・シートの例である。
図１６Ａ及び１６Ｂは、オプショナルなデバイス・データ及びフロー開発ツールの例である。
好適実施例の説明
図３は、従来技術によるテスタにおけるカスタム・ソフトウェアの機能のほとんどは市販のスプレッドシート・プログラムによって実行されうるという認識から生じるユニークなソフトウェア・アーキテクチャを示している。この好適実施例では、米国ワシントン州レドモンド（Redmond）所在のマイクロソフト社（Microsoft）によるエクセル（EXCEL）が用いられる。
エクセルは、ユーザが「ワークブック（workbook）」を作成することを可能にするスプレッドシート・プログラムである。ワークブックは、異なるスプレッドシートとして構成されたデータの集まりである。スプレッドシートとは、単に、セル（cell）の格子（グリッド：grid）であり、それぞれのセルは、１つのデータ又はデータ値が他のセルにおける値からいかにして計算されるべきかを定義する方程式を保持する。セルは、順序付けられたグリッドに現れる。セルは、一般的に、関連するデータが特定のロー（行、row）又は特定のコラム（列、column）にあるセルの中に生じるように構成されている。セルのそれぞれに対して作用するツールは、データが何を表しているかとは無関係に、同一である。ワークブックの内部では、スプレッドシートのどれにもアクセス可能であり、あるスプレッドシートの中のデータを別のスプレッドシートにおいて用いることができる。
エクセルは、また、スプレッドシートを定義し、「アプリケーション」を開発するという特徴も含む。エクセルは、会計システムの開発などのアプリケーションに用いられてきた。スプレッドシートの外観を特定して、ユーザが、特定のタスクに関係するセルだけを見るようにすることができる。表示を、『エクセル・アプリケーション開発者ガイド』やキュー・コーポレーション（Que Corporation）から１９９６年に刊行されたJeff Webbによる“Using Excel Visual Basic for Applications”（ISBN 0-7897-0269-X）に説明されている他の方法に変更することもできる。これらの書籍は、この出願において援用する。
エクセルを用いてアプリケーションを作成することができる第２の方法では、ビジュアル・ベーシック（Visual Basic）（登録商標）を用いる。ビジュアル・ベーシックは、エクセルの中に組み入れられるプログラミング言語である。その名称が示唆するように、ビジュアル・ベーシックの基本的な目的は、ユーザがデータを入力するために与えられる際のスプレッドシートの外観を制御することである。ビジュアル・ベーシックは、一般的には、複数のスプレッドシートのどれをアプリケーションが実行されている間の任意の時点においてユーザに提供するかを選択するのに用いられる。選択は、一般的には、ユーザによって入力されたデータ又はコマンドに基づいており、それによって、任意の与えられたタスクが実行されている間に、ユーザは、そのタスクに関連するデータを見ることになる。従って、ビジュアル・ベーシックは、動作しているアプリケーションがユーザにとってどのように見えるのかを制御するのに用いることができる多くのコマンドを含む。ビジュアル・ベーシックは、また、分岐（ブランチング：branching）及びルーピング（looping）のための条件ステートメントなどのプログラム・フローを制御するプログラミング・コマンドを含む。
本発明者は、半導体テスタのワークステーションにおいて用いられるときにテストの実行を制御するだけでなく、テスト・テンプレートを書くのにも、ビジュアル・ベーシックを用いることができることを発見した。特に、エクセルなどの市販のスプレッドシート・プログラムをカスタマイズして、データ及びテスト・テンプレートからのテスト・プログラムを非常に迅速にアセンブルすることができるので、カスタム・エグゼクティブと比較してテストを実行する速度がほとんど失われないということを発見した。この認識によって、多数の長所を達成することができた。このようなソフトウェア・アプリケーションの開発は非常に迅速である。更に、ほとんどのプログラマは市販のスプレッドシート・プログラムに親しんでいるので、誰かが、そのアプリケーションの使用法を学習するのは非常に容易である。更にまた、テスタ制御ソフトウェアは、コンテキスト・センシティブなヘルプや編集コマンドなど、カスタム・スプレッドシート・プログラムの中に組み込まれている多くの特徴を利用することができる。
図３は、デバイス・データ及びフロー開発ツール３１０を示している。この好適実施例では、これらのツールは、エクセル・ワークブックの中のスプレッドシートをカスタマイズすることによって、実現される。デバイス・データを保持するためには、ピン・マップと、それぞれのピンにおいて印加される信号のレベルと、タイム・セットとに対するスプレッドシートが存在する。チャネル・マップ、様々な定数値の仕様、エッジ・セットなどのデータに対する他のスプレッドシートも、オプションとして、存在しうる。それぞれのタイプのスプレッドシートは複数あり得るが、これは、異なるデータ値が異なる種類のテストに必要であるからである。それぞれのスプレッドシートは、「データ・セット」と称される。ある好適実施例において用いられるデバイス・データのためのスプレッドシートが、図４ないし９において図解されている。
テスト・フローは、ワークブック内のスプレッドシートとしても表される。テスト・フローは、実行される一連のステップによって特定される。それぞれのステップと関連するデータが存在し、それぞれのステップは、スプレッドシートにおける１つのローとして表される。それぞれのステップにおいて実行される厳密な動作は、１つ又は複数のフラグの状態によって影響されうる。ステップの実行によって、これらのフラグのいずれかの状態が変更されることもあり得る。これにより、ブランチング又はそれ以外の同様な制御の構築が達成されうる。
フローにおけるあるステップに対して特定されるデータの１つとして、どのテスト・テンプレートがどのデータ・セットと共に用いられるかがある。テスト・テンプレートとそのテスト・テンプレートと共に用いるデータ・セットとは、「インスタンス（instance）」と称される。インスタンスは、スプレッドシートとしても記述することができる。ある好適実施例において用いられるフロー情報のためのスプレッドシートが、図１０ないし１１に図解されている。
それぞれのスプレッドシートの構造は、ワークステーション１１０内のソフトウェアによって定義される。それぞれのスプレッドシートの構造は、市販のスプレッドシート・プログラムの広く知られたメカニズムを用いてテンプレートを特定することによって、作成される。それぞれのスプレッドシートに対するデータ値は、テスト・エンジニアによって入れられ、これらの値は、テスト対象のデバイスのタイプに左右される。
本発明によるテスタ制御ソフトウェアは、従来技術の場合のように、デバグ及び解析ツールとテスト・ベクトル開発ツールとを用いる。これらのアイテムは、簡潔にするために、図３には示されていない。この好適実施例では、ベクトル・ファイルは、市販のスプレッドシート・プログラムで容易に扱うには、大きすぎる。その理由で、これらは、エクセルにおいては実現されない。
次に図４Ａ及び４Ｂを参照すると、ピンマップ・デバイス・データ・シートがアクセスされている間のワークステーション１１０上の表示が示されている。図４Ａ及び４Ｂが、１つのウィンドウを表す。このウィンドウは、ワークステーション１１０上のエクセル・ソフトウェアによって表示される。エクセル・ソフトウェアは、Windows NT（マイクロソフト社の登録商標）オペレーティング・システムによって制御されるので、一度に複数のウィンドウを、スクリーン上に表示することができる。
それぞれのウィンドウは、いくつかのフィールドを含む。フィールド４１０は、ツール・バーとして知られている。フィールド４２０は、メニュ・バーとして知られている。フィールド４３０は、データ・セル・フィールドである。フィールド４４０は、タブ・フィールドである。これらのフィールドのコンテンツは、多くの場合に、ワークステーション１１０を制御するソフトウェアの準備の一部として特定される。しかし、これらのフィールドのそれぞれの配置及び一般的な動作は、エクセルを用いて開発されるすべてのアプリケーションに対して標準的である。従って、本発明によっても、エクセルが、半導体テスト・システムの制御に用いられ、エクセルや他のエクセル・アプリケーションに親しんでいる者であれば、このソフトウェアの使用法を一般的に理解するであろう。このようにして、本発明によれば、使用が容易であるから、カスタム・ソフトウェア・システムと比較して、著しい時間及びコストの削減が達成される。
ツール・バー４１０は、ツール・アイコン４１２及び４１４など、多くのツール・アイコンを含む。後により詳しく説明されるように、テスタ１１２のためのテスト・プログラムは、様々なスプレッドシートにデータを入れることによって、大部分が特定される。データは財務上のデータや市販のスプレッドシート・プログラムが通常用いられるそれ以外のタイプのデータとは異なり半導体テスタに対する制御情報を表すという事実にもかかわらず、データは、同じように操作されなければならない。従って、データ操作ツールが必要であるが、エクセルと共に用いられる標準的なデータ操作ツールでよい。これらのツールは、データのコピー、データの削除、スプレッドシートのコンピュータ・ファイルへのセーブなどの機能を実行する。これらのツールは、マウスやトラックボールなどの入力デバイスを操作して特定のツール・アイコンを選択するユーザによってアクセスされる。
更に、フィールド４１０は、カスタム・ツールを用いてカスタマイズすることができる。エクセルによれば、カスタム・ツールを特定してツール・バーに追加することができる。望む場合には、テスト・プログラムの生成に対して一意的な機能を実行するカスタム・ツールを、ツール・バー４１０に追加することもできる。例えば、一方で、テスト・プログラムを実行するカスタム・ツールもあれば、他方では、デバイス・データをチェックしてエラーや非一貫性（不一致）を検出するカスタム・ツールもある。
メニュ・バー４２０は、４２２や４２４などのシステム・メニュ・アイテムを含む。これらのアイテムは、ユーザによってアクセスされると、このシステム・メニュ・アイテムに関係する作用の複数の選択肢を提供するように拡張する。例えば、ファイル（FILE）というシステム・メニュ・アイテムの下には、保存（save）、削除（delete）、印刷（print）などの選択肢がある。ツール・バー４１０とメニュ・バー４２０とからアクセスできるツールの間にはいくらかの重複がある。一般的には、ほとんどの共通のツールは、ツール・バー４１０上に現れ、システム・メニュ・アイテムの１つの下にある選択肢の１つとして複写されることが多い。
メニュ・アイテムのほとんどは、自動テスト・システムに用いられるデータに特定ではない機能を表す。従って、エクセル・アプリケーションに対するデフォルト条件として提供されるシステム・メニュ・アイテムを、ほとんどのメニュ・アイテムに対して用いることができる。しかし、自動テスト・システムに特定の機能も多く存在する。この好適実施例では、これらの機能は、ユーザがカスタム・メニュ・アイコン４２６からの選択肢を選択することによって実行される。エクセルは、上述したエクセル・アプリケーション開発ガイドにおいて提供されている命令に従って、アプリケーションに対してカスタマイズすることができる。カスタム・メニュの選択肢は、システム・メニュ・アイテムと同じメニュ・バー又は別個のカスタム・メニュ・バーの上に現れる。
デバイス・データを含むデータ・シートに対しては、カスタム・メニュ・アイテムによって、データ・シートの「有効化確認（validate）」を可能にする。すでに述べたように、データ・シートにおける様々なセルは、データ有効化機能をそれらと関係付けしている場合がある。これらのデータ有効化機能は、現在のデータ・シートのコンテキストにおける不適切なデータ値を検出することができる。例えば、特定のフィールドが数値を保持することを意図されていれば、入力される値が文字を含む場合には、エラーが検出されうる。また、別のセルが正の値だけに限定されている場合には、入力される値が負であれば、エラーが指示される。しかし、複数のシートに依存する有効化機能もある。例えば、ピンの総数は、１つのシート上で特定され、ある属性は、それぞれのピンに対して別のシート上で特定される場合がある。属性があまりに少数のピンに対して特定されている場合には、これは、２つのシートを比較することによって検出されるだけである。様々な有効化機能を、テスタ・ハードウェアの要件及び制限に基づいて定義することができる。これらの有効化機能は、カスタム・メニュ・アイテムから選択することができる。また、同じ機能を、ツールバー・ボタンを用いて選択することもできる。
更に、フロー・データ・シートに対しては、そのフローによって定義されるテストを実行する方法が存在することが要求される。フロー・シートと関連するカスタム・メニュ・アイテムによって、フローが実行され、また、実行の態様も決定される。例えば、フローの実行においてブレーク・ポイントを設定する、又は、一度に１つのステップずつフローを実行することが望ましい場合がある。これらの機能のそれぞれは、カスタム・メニュ又はツールバー・ボタンからのメニュ選択として特定することができる。
カスタム・メニュ・アイテムは、シートのそれぞれとは異なることがある。エクセルによると、その何らかの属性を、それぞれのデータ・シートに対して特定することが可能である。これらの属性の１つに、カスタム・メニュ・アイテムがある。このようにして、カスタム・メニュを、特定のシートに表示される特定のデータ・タイプに適する操作だけを含むように修正することができる。以下では、ソフトウェア制御テスタ１１２によって実行される他の操作について説明する。これらの操作は、カスタム・メニュ上に現れるメニュ・アイテムにマップされる機能として定義することができる。
データ・セル・フィールド４３０は、テスタ１１２を制御するようにカスタマイズされたデータ・セルを含む。セルのレイアウトは、エクセルによって提供される。しかし、ウィンドウにおいて見ることができるロー及びコラムの数は、エクセルをプログラムすることによって、決定される。図４Ａ及び４Ｂは、デバイス・ピンマップ・データ・シートを表している。従って、データ・セル・フィールド４３０は、デバイス・ピンマップ・データを受け取るように設定されたセルのロー及びコラムを含む。
半導体テスタでは、デバイス・ピンマップ（device pinmap）は、論理的な名称を物理的なピン１１８（図１）に、テスト・プログラムが動いている間にこれらのピン１１８がどのようにテスト対象デバイスと接触するかに基づいて、割り当てる。データ・セル・フィールド４３０は、データ・セル４３２Ａ、・・・、４３２Ｄの４つのコラムと共に示されている。これらのコラムのそれぞれは、先頭に、ヘッダ・セル４３４などのセルを有する。ヘッダ・セル４３４は、そのコラムの残りのセルに入れられるデータのタイプの記述を含む。スプレッドシートがエクセルにおいて定義されるときには、ヘッダ・セルなどのいくつかのセルには、固定値を与えることができる。
データを入力しチェックするための規則（ルール）は、図４Ａ及び４Ｂでは見ることができない。しかし、市販されているスプレッドシート・プログラムの特徴の１つとして、様々なセルに入力される際にデータが有効化されるということがある。また、データ・セルによっては、他のセルに入力された値に基づいて計算されうるものもある。市販のスプレッドシートは、大量の財務データを入力するなどの目的で、この特徴を備えているように開発された。しかし、データをテスタ制御のために用いる場合でも、いくつかのデータ入力規則は可能であり、用いることができる。
図４Ａ及び４Ｂにおける別のフィールドとして、タブ・フィールド４４０がある。タブ・フィールド４４０は、４４２及び４４４などの一連のタブを含む。それぞれのタブは、テスト・プログラムを含むワークブックの中にある１つのスプレッドシートを表す。ユーザは、タブの１つを付勢する（アクティブにする）ことによって、どのスプレッドシートがアクティブであるかを選択する。図４Ａ及び４Ｂの図解では、pinmap. pmpという名称を有するタブ４４３が、他のタブの最上位にある。これが選択されたタブであり、図４Ａ及び４Ｂに示されているピンマップ・スプレッドシートに対応する。
タブ・フィールド４４０は、すべてのデバイス・データを１つのワークブックとしてセットアップするという重要な効果を図解している。異なるタイプのデータが異なるツールに入力されていた従来技術によるテスタとは対照的に、すべてのデバイス・データが、１つのエクセル・ワークブックに入力される。すべてのデータを１つのワークブックにおいて有することによって、１つのスプレッドシートにおけるデータ値が別のスプレッドシートに入力されたデータに依存することが可能となる。更に、これにより、テスト・プログラムを開発している人間が、異なるタイプのデータに対するシートの間で迅速に切り替えを行うことが可能となる。テスタのためのカスタム・プログラム環境が適切に開発された場合にはこれらの操作のそれぞれが可能であり得るのに対し、データを１つのプログラミング・ツールから別のプログラミング・ツールに送ることの複雑性なしに、この簡潔性が比較的低コストで達成される。更に、これは、プログラマが迅速に理解することが概念的に容易であるような態様で実現される。
図５を参照すると、第２のデバイス・データ・スプレッドシートが示されている。図５は、チャネル・マップ（channel map）データが入力される間に現れるワークステーション１１０のスクリーン上のウィンドウを示している。チャネル・マップ・データはピン・マップ・データとは異なっているが、図４Ａ／４Ｂと図５とのスクリーン表示は非常に類似していることに注意することは重要である。
図５におけるスクリーン表示は、図４Ａ及び４Ｂと同じフィールドを有する。ツール・バー５１０は、ツール・バー４１０と同じである。メニュ・バー５２０は、メニュ・バー４２０と同じである。メニュ・バー５１０におけるいくつかのメニュ・アイテムがメニュ・バー４１０におけるアイテムと異なることはあり得る。例えば、いくつかの機能はチャネル・マップ・データにだけ適用可能であるような場合には、そうである。その場合には、これらの機能に対するメニュ・アイテム又はサブメニュ・アイテムは、メニュ・バー５１０にだけ現れる。好適実施例では、表示されているスプレッドシートにおけるテスタ・データのタイプに依存するこれらの機能は、カスタム・メニュ・アイテム５２６の下のサブメニュ・アイテムとして現れる。また、データに依存する機能は、カスタム・ツール・バー・アイテムを介してアクセスすることもできる。
テスタのためのソフトウェアを実現するのに用いられる市販のスプレッドシートは、異なるタイプのデータ・シートの定義を許容し、更に、表示されるサブメニュ・アイテムが用いられるデータ・シートのタイプに依存することを許容するという特徴を含むことが好ましい。
タブ・フィールド５４０では、それぞれのタブがその上に２つの部分からなる名称を有していることに注意すべきである。第１の部分は、スプレッドシートに対する識別子である。名称の第２の部分、又は、拡張子は、スプレッドシートのタイプである。例えば、図５は、ChannelMap. cmpとラベル付けされたタブを示している。チャネル・マップを定義するタイプであるデータを保持するすべてのスプレッドシートは、. cmpという拡張子を有する。しかし、テスト・エンジニアが特定の識別子を選択する。好適実施例では、ワークステーション１１０上で動いている市販のスプレッドシート・プログラムによれば、アプリケーションの開発者は、そのタイプのスプレッドシートに対してどのメニュ・アイテム及びサブメニュ・アイテムがメニュ・バー４２０上に現れるかを特定することができる。
次に、図６を参照すると、スペック・シート（spec sheet）に対するスプレッドシートが示されている。他のすべてのデータ・ツールと同じように、このスプレッドシートは、ツール・バー６１０と、メニュ・バー６２０と、タブ・フィールド６４０とを有している。タブ・フィールド６４０は、「SpecSheet, sps」とラベル付けされた現在のスプレッドシートがハイライトされて示されている。同様に、SpecSheetは、多くのデータ・セルがロー及びコラムとして構成されているデータ・フィールド６３０を有している。ここで、それぞれのローは、特定のテスト対象デバイスと関連するパラメータに対するシンボルを含む。それぞれのパラメータには、様々な情報が与えられる。図６は、データ・フィールド６３０のそれぞれのローにおける７つのコラムを示している。シンボル名に加えて、それぞれのローは、値と、その値に対する単位と、シンボルの説明のためのテキスト・フィールドと、適切に動作するパーツのための最小値及び最大値と、コメント・フィールドとを含む。データ・シートはすべて１つのエクセル・ワークブックにおいて開発されるので、これらのシンボルは、他のスプレッドシートにおける名称によって参照することができる。より重要なこととして、それぞれのシンボルと関連するパラメータは、他のスプレッドシートにおいても用いることができる。更に、スペック・シートの名称は、テスト・インスタンスが開発される際に、特定のテスト・テンプレートにパラメータとして送られうる。これによって、テスト・テンプレートが、テスト対象デバイスが仕様の範囲内で動作しているかどうか（すなわち、テストに合格なのか不合格なのか）を決定するなど、スペック・シート・データと比較することが可能になる。
図６は、１つの仕様シートを示している。１つのジョブの中において、異なるタイプのテストのために異なる仕様が要求されることもあり得る。従って、複数の仕様シートを用いることができる。データ・マネジャ３１６との関係で後に説明されるように、特定のタイプを有する複数のデータの組を有するための用意（provisions）がなされている。
図７は、エッジ・セット（edge set）を定義するのに用いられる別のデバイス・データ・シートを示している。図１に示されているように、テスタ１１２は、複数のピン１２４を含む。それぞれのピンは、それぞれがエッジを発生しエッジ発生器と称される複数の回路を含む。エッジは、ピン１２４による何らかの作用を計時するのに用いられる信号である。例えば、ピンによって生じるパルスの開始及び停止時間などのパラメータを制御する４つのエッジ信号が存在しうる。それぞれのエッジが発生される時間は、プログラムすることができる。１つのピンに対するそれぞれのエッジがプログラムされる時間は、エッジ・セットとして定義される。エッジが特定のピンに対してプログラムされる時間はジョブの間に変化しうるので、それぞれのピンに対して複数のエッジ・セットがあり得る。
図７は、１つのピンに対するエッジ・セットを示している。コラム７５０は、エッジ・セットが特定されるピンは、「QdataPins」と称されることを示している。他のピンに対するエッジ・セットは、データ・フィールド７３０にローを更に加えることによって追加することが可能である。コラム７５２は、ピンQdataPinsに対する１つのエッジ・セットは、「LooseFunction 1」と称されることを示している。データ・フィールド７３０にローを加えることによって追加することが可能である。
コラム７５４及び７５６は、ピン１２４をセットアップし所望の信号を発生するのに必要なそれ以外の情報を与える。コラム７５８は、そのピンの中のエッジをリスト化し、隣接するコラム７６０及び７６２は、これらのエッジが生じる時間に対する値を与える。
コラム７６０及び７６２は、市販のスプレッドシートを用いてテスタ１１２を制御することの有益な長所を図解している。スプレッドシートは、自動的に方程式から値を計算することができる。従って、コラム７６２によって、それぞれのエッジに対する時間値が、他のスプレッドシートにおいて定義された他の定数又はパラメータとの関係で方程式として特定されることを可能になる。コラム７６０は、そのフィールドに対してプログラムされた数値がコラム７６２における方程式を評価することによってスプレッドシート・プログラムによって自動的に計算されることを示している。
セル７６６、７６８、７７０及び７７２は、市販のスプレッドシート・プログラムを用いることによって得られる他の効果を示している。データ・フィールド７３０におけるドロップ・ダウン・リスト・ボックスは、データ・フィールド７３０におけるデータ・セルの表示又は値を制御するのに用いることができる。これらのセルは、ドロップ・ダウン・ボックスとして実現されるが、これは、エクセルにおける標準的なオブジェクトである。それぞれのドロップ・ダウン・ボックスは、固定された数の値の中の１つを有することができる。これらの値は、固定されたリストとして、又は、ワークブックの中のスプレッドシートの１つに入力された値を参照して特定することができ、入力された値が変化すると、これらの値も変化する。
テスタ１１２に多数のピンが与えられると、エッジ・セット・スプレッドシートは、潜在的に多くのローを含みうる。セル７６６、７６８、７７０及び７７２は、一度に表示されるデータの量を制限するのに用いることができる。セル７６６は、特定のピン又はピン・グループの名称を含む。そのピン又はグループ内の複数のピンに対するエッジ・セットだけが、データ・フィールド７３０の中に表示される。同様にして、セル７６８及び７７０は、特定のタイミング・モードと選択された数のエッジだけとに対するエッジ・セットを表示する。セル７７２は、同様に、ドロップ・ダウン・ボックスであるが、値コラム７６０に入力される値に対する単位を特定するのに用いられる。
図８Ａは、エクセル・ワークブック内の別のデータ・シートを示している。図８Ａにおけるシートは、タイム・セットに対するデータを与えており、他のデータ・シートと同じフォーマットを有している。タイム・セットは、エッジ・セットの集合であり、ピン１２４のそれぞれに１つが対応する。複数のタイム・セットが定義され、異なるプログラムされた時間が１つのジョブの中で用いられることも多い。
図８Ａは、タイム・セットの名称の上にデータの入力を許容するコラムを示している。周期は、そのタイム・セットとピン又はピン・グループと関連している。それぞれのピン又はピン・グループに対しては、テーブル内に１つのローが存在する。それぞれのピン又はピン・グループに対しては、そのピンのエッジに対するプログラムされた時間がエッジ・セット又は方程式のどちらかを参照することによって特定されることを可能にするコラムが存在する。図８Ａはまた、ドロップ・ダウン・ボックス８３２Ａ及び８３４Ａを示している。ドロップ・ダウン・ボックス８３２Ａは、どのタイム・セットが表示されるかを選択する。ドロップ・ダウン・ボックス８３４Ａは、すべての時間値が表示される単位を指定する。
図８Ｂは、市販のスプレッドシート・プログラムを用いる結果として得られる別の効果を図解している。複数のスプレッドシート・テンプレートを、同じデータに対して定義することができる。同じスプレッドシートに対して複数のテンプレートを有することによって、同じデータが異なって表示され、それにより、ユーザは、現在自分が作業しているタスクが何であってもそれに対して最も便利なフォーマットでそのデータを見ることが可能になる。図８Ｂは、エッジ・セット・データを表示する別のテンプレートを示している。これは、ドロップ・ダウン・ボックス８３２Ａのようなドロップ・ダウン・ボックス８３２Ｂを有する。これはまた、データ・フィールド８３０Ａと類似のデータ・フィールド８３０Ｂを有する。しかし、データ・フィールド８３０Ａ及び８３０Ｂにおけるコラムは、異なる態様で構成されている。
図８Ａに示されているテンプレートは、例えば、ピン・グループを特定のタイム・セットに割り当てるのに用いられ得る。図８Ｂにおけるテンプレートは、例えば、それぞれのピンがどのエッジに割り当てられているかを判断するのに用いられ得る。好適実施例では、図８Ｂのテンプレートは、リード・オンリ・テンプレートである。
図９は、ユーザによって一貫したフォーマットで容易に入力されうる更に別のタイプのデータを示している。図９は、他のスプレッドシートに用いられるのと同じツール・バーとメニュ・バーとを示している。図９は、様々な名称のパラメータと関連するレベルを特定するスプレッドシートを示している。これらのパラメータは、同様に、様々の測定値又は刺激信号と関連する電圧及び電流レベルである。エクセルによれば、これらの名称付きのパラメータは、他のスプレッドシートにおける名称によって、参照されることが可能である。また、パラメータの値を、他の名称付きの値を組み入れている方程式によって特定することも可能である。
図１０Ａを参照すると、本発明の効果の１つを見ることができる。図１０Ａは、「フロー・タイプの」スプレッドシートを表している。図１０Ａは、テスト「インスタンス」が特定のテストに対して定義される態様を表す。半導体テスト・システムは、一般的に、限定された数のものに対するテストを行うのに必要とされる。例えば、このテスト・システムは、パターン「バースト」をランさせることもありうる。バーストの間には、テスタは、特定された刺激を与え、いくつかの予測される応答をチェックする。刺激及び応答に対する値は、「ベクトル・ファイル」において特定される。ベクトル・ファイルの中の異なる値は、異なる種類のパーツをテストする、又は、同じパーツ上で異なるテストを行うのに用いられる。しかし、ベクトル・ファイルを用いるためにテスタが実行する動作は、その中の特定のデータ値とは関係なく、同一であるのが一般的である。
テスト・システムがパターン・バーストを実行するのに経験する一連のステップは、「テンプレート」と称される。テンプレートは、特定のベクトル・ファイル又は必要とされるそれ以外のデータの記述のためのブランク・スペースと同等のプログラミングを用いて実行されなければならない一連のステップである。このようにして、テンプレートは、それが用いる特定のデータ値がいったん特定されると、任意のテストに対して用いることができる。データが特定のテンプレートと共に用いられるために特定されると、このテンプレートの「インスタンス」が作成される。インスタンスは、プログラムにおいて用いることができる。
テスタの製造業者は、一般に、その制御ソフトウェアの一部として複数のテスト・テンプレートを提供する。テスト・テンプレートは、パターン・バーストをランしたり、漏れ電流の測定を行ったり、テスト対象デバイスのリード上の直流レベルやそれ以外のテスタ動作をチェックするのに用いられる。後で更に詳しく説明されるように、好適実施例のテンプレートは、ビジュアル・ベーシックで書かれているが、これは、スプレッドシート・プログラムであるエクセルと関連するプログラミング言語である。それぞれのテンプレートは、ビジュアル・ベーシックの手順として書かれ、データ値は、手順への引数（argument）として特定される。
図１０Ａは、プログラム・インスタンスが作成される方法を図解している。データ・フィールド１０３０は、テスト・ジョブにおいて用いられ得るインスタンスの名称をリスト化するコラム１０３２Ａを含む。コラム１０３２Ｂは、インスタンスを作成するのに用いられるテンプレートの名称を含む。
図１０Ｂは、特定のデータがあるテンプレートとどのように関連するかを示している。エクセルは、ダイアログ・ボックス１０３６をデータ・フィールド１０３０における特定のセルと関連させることを可能とするプログラミング上の特徴を含む。セルにおける又はどれか別のセルにおける値に依存して、異なるダイアログ・ボックスを選択することができる。例えば、図１０Ｂでは、ダイアログ・ボックス１０３６は、セル１０３４と関連するように示されている。セル１０３４は、特定のデータ値をセル１０３５の中にリスト化されたテンプレートと関連付けることによって、作成されるインスタンスの名称である。この例では、ダイアログ・ボックス１０３６のフォーマットは、セル１０３５にリスト化されたテンプレートに基づいて選択される。
ダイアログ・ボックス１０３６は、領域１０３８及び１０５０と含んでおり、それぞれが、セル１０３５におけるテンプレートが関連付けられるいくつかのデータ値がリスト化されるフィールドを備えている。「30Mhzfunc」とラベル付けされるテスト・インスタンスを作成するために、ダイアログ・ボックス１０３６の中の値は、引数として、「functional」という名称のテンプレートに送られる。
図１０Ｂは、データ・フィールド１０３０が多くのローを含むことを示している。テスト・ジョブにおいて必要とされるそれぞれのテスト・インスタンスに対して、１つのローが存在する。「Functional」と命名されたテンプレートは２つの異なるインスタンスを作成するのに用いられる。異なる引数をダイアログ・ボックス１０３６において特定することによって、同じテンプレートを用いて異なるインスタンスが作成される。
図１０Ａ及び１０Ｂは、テスト・フローを特定する際のステップを示している。しかし、このユーザ・インターフェースは、図４ないし９のデータ・スプレッドシートのためのユーザ・インターフェースと同じであることに注意すべきである。従って、プログラム・フローを特定するために、特別のトレーニングは何も必要とならない。また、ダイアログ・ボックス１０３６に入力される引数は、他のスプレッドシートの名称か、又は、スプレッドシートの中で定義される値であることがほとんどである。従って、デバイス・データは、プログラム・フロー情報との組合せが容易であり、ソフトウェアの開発時間をかなり節約することができる。この利点は、デバイス・データとプログラム・フローとの両方がスプレッドシートにおいて表されているという事実に起因する。
他のプログラム・フロー情報は、図１１Ａに示されているスプレッドシートに入力される。インスタンスがいったん定義されると、実行される順序が特定されなければならない。更に、インスタンスがテスト・ジョブの中のテストを記述するので、テスト・インスタンスが合格するか又は失敗する場合にどのイベントが生じるかに関する情報が提供されなければならない。この情報の全体が、他のフローやデバイス・データ・スプレッドシートと同じインターフェースを用いて、スプレッドシートの中にユーザによって入力される。
データ・フィールド１１３０の中には、テスト・ジョブにおけるそれぞれのステップに対して特定されなければならない情報を保持する複数のコラムが存在する。データ・フィールド１１３０におけるそれぞれのローは、テスト・ジョブにおける１つのステップに関する情報を保持している。コラム１３２は「OPCODE」とラベル付けされる。このコラムは、この特定のステップにおいて何が起こるのかを指示する。一般的に、OPCODEコラム１３２におけるそれぞれのエントリは、テスト・インスタンスである。
コラム１１３４は、テストにおけるステップ番号を含む。ステップ番号は、テスト・システムがそのテストの実行に関する報告に用いることができる。例えば、欠陥がテストの間に検出された場合には、欠陥が検出されたステップ番号を報告することができる。
コラム１１３６は、合格ビン番号（pass bin number）を含む。それぞれのデバイスがテストされる際に、テスタは、一般に、テスト対象デバイスに、テストの結果に対応する「ビン」番号を割り当てる。ビン番号は、パーツのグレード付け（grading）を示す。例えば、あるビン番号は、デバイス仕様の程度まで動作するパーツを表す。他のビン番号は、欠陥があり役に立たないパーツを示す。更に別のビン番号は、仕様の範囲内の動作はしないが、程度を落とした仕様の程度であれば十分に機能を果たすデバイスを示す。テスト・エンジニアが、ビン番号とその意味とを割り当てる。
コラム１１３８も同様である。これには、テストが失敗した場合に割り当てられるビン番号を含む。
データ・フィールド１１３０は、示されている範囲を超えたそれ以外のコラムを含みうる。図１１Ｂは、より複雑なフロー制御のためのより多くのコラムの情報によって拡張されたデータ・フィールド１１３０Ｂを有するフロー・シートを示している。例えば、データ・フィールド１１３０Ｂは、フラグ・フィールド１１５６及び１１５８を含む。フラグ・フィールド１１５６は、オプションで、あるステップで特定されたテストに合格した場合に「真」（true）であると設定されるフラグ、すなわち、ブール変数（boolean variable）と同じものを含む。フィールド１１５８も同様であるが、テストが不合格であった場合に設定されるフラグの名称を含む。
データ・フィールド１１３０Ｂにおける他のコラムは、複数のデバイスが同時にテストされるような場合のより複雑なフローに用いられ得る。例えば、コラム１１５２は、任意のローにおいて特定されたステップがどのデバイスに適用され得るかを示している。それまでのすべてのテストに合格してきたデバイスにだけ他のテストを実行することがありうる。また、先行する１回のテストに合格しなかったデバイスにだけ他のテストを実行することがありうる。
コラム１１５４は、テストの結果をどのデバイスに適用すべきかを特定する。
これらの示されているもの以外のコラムを用いることもありうる。そのステップにおけるテスト・インスタンスの実行の前に、あるブール表現の評価が与えられている条件フィールドを含むコラムもありうる。このようにして、条件的なプログラム・フローを実現することができる。この機能は、それがブール表現をとることを許容することによって、コラム１１５２と組み合わせることができる。真であると評価されるブール表現は、テストがすべてのデバイスに対して実行されることを示す。逆に、表現が偽（false）であると評価される場合には、テストはすべてのデバイスに対して行われるとは限らない。ブール表現をそれぞれのデバイスに対して特定できる場合には、混合的（ハイブリッド）な状況もありうる。図１１Ｂの例では、コラム１１５２は、「すべて」に関して一定値を有する何らかの値を含む。そのような値は、そのローにおいて参照されたテストがすべてのデバイスに対して無条件的に実行されるべきであることを示している。しかし、他のローは、先行するローにおいてコラム１１５６又は１１５８にリスト化されているフラグを参照するブール表現を示している。更に、これは、セルがその中ではある値に設定されデバッギング・ブレーク・ポイント（debugging break point）のように作用するコラムを含みうる。
図１１Ｂに示されている情報は、既存のテスタをプログラムするために特定されなければならない情報と類似している。しかし、図１１Ｂのフロー情報は、複数のローとして構成され、それぞれのローは、それぞれの中に複数の種類の情報を有している複数のコラムを含む。フロー情報をテキスト・ファイルの中に記憶するのと比較すると、市販のスプレッドシート・プログラムを用いることから帰結されるロー及びコラムの構成は、プログラマにとってははるかに直感的であり、それによって、プログラマは、フローをより迅速にプログラムすることを学ぶことになる。第２の利点は、図１１Ｂに示されているフロー情報を操作するための構造及びツールが、市販のスプレッドシート・プログラムによって提供されるということである。このようにして、ソフトウェアの開発をより迅速に行うことができる。
図１１Ｃは、フロー制御情報を特定することができる別の方法を示している。図１１Ｃは、低級の制御ソフトウェア３１４（図３）のオプションを修正するオプションを特定するのに用いることができるポップアップ・オプション・ボックスを示している。オプションは、ダイアログ・ボックスの中の選択肢の上をクリックすることによって、人間であるテスト・エンジニアによって特定される。例えば、「すべてを実行せよ」というオプションによれば、１つのステップが失敗した場合であってもフロー制御ソフトウェア３１４にプログラム・フローにおけるすべてのステップを動作させることになる。このオプションが選択されないときには、特定のパーツのテストは、１つのステップが失敗すると、停止することになる。別の例としては、「最終のものを印刷せよ」というオプションの場合には、テスト・ジョブが終了すると、テストの結果が印刷されることになる。選択されないときには、結果は印刷されないが、ユーザによって読み出されるまで記憶されていることになる。更に別の例として、「計時を実行」（Do Time）のオプションによると、フロー制御ソフトウェアは、ジョブの開始とジョブの終了の時間を記録し、それによって、ジョブに要した時間の長さを記憶することができる。以下で説明されるように、フロー・データ・シートは、フロー・データ構造に変換される。特定されたオプションによって、この変換がなされる実際の方法が影響を受ける。
図１２Ａ及び１２Ｂは、テスト・テンプレートのサンプルを示している。テスト・テンプレートは、ビジュアル・ベーシックで書かれているが、このビジュアル・ベーシックは、スプレッドシートに添付されたマクロを書くのに用いることができるプログラミング言語である。それぞれのマクロは、プログラミング言語における手順として用いることができ、従って、テスト・テンプレートとして用いることができる。
図１２Ａ及び１２Ｂでは、複数の重要なポイントを見ることができる。第１に、全体的なプログラミング環境は、情報をデバイス・データとフロー・スプレッドシートに入力するのに用いられるものと同一である。同じツール・バー１２１０と、メニュ・バー１２２０と、タブ・フィールド１２４０とを有している。しかし、データ・フィールドの代わりに、テスト・テンプレート・スクリーンは、複数のラインのプログラム・コードを含む。
プログラム・コードのそれぞれのラインは、テスタ製造業者によって開発された他の手順をコールすることができるし、又は、ユーザが書くこともできる。ライン１２５０及び１２５４は、テスタ製造業者によって提供される機能へのコールを表している。ライン１２５０では、「PinHi」は、デバイス・ドライバ３２８（図３）の１つにアクセスし、特定されたピンをハイ（high）状態に設定する手順である。ライン１２５４では、「StartPatgen」は、タイミング及びシーケンシング回路１２０（図１）の動作を開始させるのと同じ機能である。
図１２Ａ及び１２Ｂは、また、デバグ・ツール・バー１２３２を示している。新たな半導体デバイスが最初に開発されているときには、デバイス・エンジニアは、このデバイスの実際のパフォーマンスを測定しその設計が適切であるかどうかを評価することが必要である。欠陥が検出されたときには、デバイス・エンジニアは、何がうまくいかなかったのかを正確に割り出すことを望む。そのために、デバイス・エンジニアは、テスタを「デバグ・モード」で用いる。デバイス・エンジニアは、テスタが一度に１つの動作を実行するように制御し、それによって、それぞれの動作の結果を解析できるようにする。デバグ・ツール・バー１２３２は、好ましくは、市販のスプレッドシート・プログラムの一部として提供されている。
デバグ・ツール・バー１２３２は、様々なデバグ機能を実行するツールを含む。例えば、ツール１２３４は、コードにおけるブレーク・ポイントを設定する。ライン１２５４は、そのラインにおいてブレーク・ポイントが設定されていることを示すためにハイライトされる。テストを実行する間には、ブレーク・ポイントのマークが記されているラインを実行する前に、実行は停止する。とのときに、デバイス・エンジニアは、テスタ又はデバイスの状態をチェックすることができる。
ブレーク・ポイントにおいて実行が停止したときには、デバグ・ツール・バー１２３２上の他のツールが、実行がどのように継続するかを制御する。例えば、ツール１２３６によって、実行がそれ以後のすべての手順までステップ・バイ・ステップで進行することが可能になる。対照的に、他のツールでは、手順をスキップしてとばすことが可能になるし、更に別のツールによると、ある値が検査されることが可能になる。このようにして、デバイス・エンジニアは、デバイスの動作について多くのことを観察することができる。同じデバグ・ツールは、テスト対象デバイスのためのテストを開発しているテスト・エンジニアによって用いられることも可能である。有意義なことに、これらの能力のすべては、デバグ・ツールを備えたプログラミング言語と関連付けされている市販のスプレッドシート・プログラムを用いることによって、非常に低コストで提供され得る。
テスト・ジョブのためのデータ及びフロー情報がテスト・エンジニア又はシステムのそれ以外のユーザによって入力されると、ワークステーション１１０内のソフトウェアを動作させ、テスト・ジョブを制御することができる。図３に示されているように、テスト・ジョブの実行は、ユーザ入力に応答して、フロー制御ソフトウェア３１４によってなされる。図解されている実施例では、フロー制御ソフトウェア３１４は、Ｃ＋＋言語として実現されている。より詳しくは、それは、ＤＬＬである。
図１３は、フロー制御ソフトウェア３１４の動作を説明する流れ図である。フロー制御ソフトウェア３１４は、アイドル状態１３１０から始動する。フロー制御ソフトウェア３１４は、ソフトウェアへの入力に基づき、３つの異なる作用の中の１つを実行することができる。フロー制御ソフトウェア３１４がとりうる１つの作用として、テスト・ジョブのためのデータをテスト・ジョブの間にアクセスすることができるデータ構造に構成することがある。図１０及び１１と共に既に説明したように、テスト・ジョブは、インスタンスのリストとして特定され、インスタンスは、特定のデバイス・データとあるテンプレートとの関連付けによって特定される。更に、特定のインスタンスが実行される順序は、プログラムのフロー・データ・シートに入力される条件によって影響される。
ユーザ・コマンドに応答して、フロー制御ソフトウェア３１４は、実行されるそれぞれのテンプレートとそのテンプレートの実行のために用いられるデータとをリスト化するジョブ制御データ構造を構築する。テンプレートの実行順序を条件から決定することができる場合には、それは、テンプレートがコア・ブロック制御データ構造の中に配置される前に決められる。しかし、テンプレートの実行順序がテスト・ジョブが実行されるまで決められない場合には、ジョブ制御データ構造は、単に、テンプレートが実行される順序を決定するのに評価される条件に関する情報を含む。ジョブ制御データ構造は、インデクス付きのリストでありうるが、それ以外の実現例も可能である。
ジョブ制御データ構造を構築する際には、実行は、ステップ１３１２に進む。ステップ１３１２では、第１のテンプレートが決定される。テンプレートは、フロー・データ・シートにおける第１のインスタンスから決定される。このインスタンスと関連するテンプレートは、インスタンス・データ・シートから決定される。テンプレートに対するノーテーション（記号、notation）は、ジョブ制御データ構造に入力される。好適実施例では、このノーテーションは、テンプレートを実行するようにコールするサブプログラムの名称を示す。
ステップ１３１４では、選択されたテンプレート・サブプログラムのコールの際に送られるデータが識別される。どのデータを用いるべきかは、インスタンス・データ・シートから決定される。
ステップ１３１６では、特定のテスト・テンプレートのための用いられるデータのＩＤがジョブ制御データ構造に追加される。図３に示されているように、データ・マネジャが、データを、テスタ１１２（図１）に与えるために、エクセル・ワークブックからデバイス・ドライバに送る。後で詳細に説明されるように、データ・マネジャ３１６は、テスト・ジョブの間のテスタ１１２に送られる特定のデータを保持するパラメータ・データ構造をアセンブルする。パラメータ・データ構造におけるデータは、「コンテナ」（容器、containers）の中に構成されることにより、データに正しい「コンテナ」の名称を提供することによって、正しいデータがパラメータ・データ構造から選択されることが可能になる。フロー制御データ構造に加えられる引数は、データ・マネジャ３１６がパラメータ・データ構造から選択する正しい「コンテナ」を特定する。この情報は、好適実施例では、データ・シートに与えられた名称に基づいて選択されるテキスト・ストリングとして表される。コンテナには、同じテキスト・ストリングが関連付けされる。しかし、コンテナを識別する別の方法を、代わりに用いることもできる。
「コンテナ」の名称を表す引数に加えて、データ値である引数が特定のテンプレートによって用いられ、更に、アクチュエータ・データ構造に追加されることもありうる。
テンプレートを識別する情報とデータ値とがジョブ制御データ構造に追加されると、実行は、ステップ１３１８に進む。ステップ１３１８では、フロー・シートにおいて特定された次のテンプレートを実行するための条件が決定される。この条件は、実行すべき次のインスタンスでありうるフロー・シートにおけるすべてのありうるインスタンスを決定するために計算される。更に、それぞれのインスタンスが次になる条件が、論理方程式として表現される。テスト・ジョブの間に評価されなければならない値に対して、変数が用いられる。これらの論理的表現は、ジョブ制御データ構造にステップ１３２０において入力される。これらの論理的表現は、伝統的なプログラミングにおけるブランチング（分岐）命令と何が等しくなりうるかの条件として用いられる。
フロー制御シートの１つのローに対する情報が入力されると、実行は、ステップ１３２２に進む。ステップ１３２２は、フロー制御データ・シートにローが更にあるかどうかをチェックする。あるならば、実行は、ステップ１３１２までループする。フロー制御データ・シートにそれ以上ローがない場合には、フロー制御ソフトウェア３１４は、アイドル状態１３１０に戻る。
フロー制御ソフトウェア３１４は、そのアイドル状態にあるときには、ユーザからテスト・ジョブを実行せよとのコマンドを受け取ったり、又は、操作デバイス１１４から、テスト対象デバイスがロードされテストの準備ができていることを示す開始信号を受け取ったりする。テスト・ジョブを実行するようにとのコマンドを受け取ったときには、実行は、ステップ１３２４に進む。ステップ１３２４では、ジョブ制御データ構造からの第１のテンプレートが読み出される。テンプレートは、ジョブ制御データ構造からの特定の引数を伴うサブプログラムとしてコールされる。次に、テンプレート・サブプログラムが実行され、フロー制御ソフトウェア３１４に戻る。
テストを表すそれぞれのテンプレート・サブプログラムは、テストが合格だったのか不合格だったのかを指示する。テストの結果が指示されうる１つの方法として、テンプレート・サブプログラムが、値を、そのサブプログラム・テンプレートによって行われたテストの結果を指示するコール・プログラムに戻すようにコード化されているかどうかである。また、テンプレートか、又は、適切な場合にデバイス・ドライバは、テスタの状態をチェックしてテストが合格であった不合格であったかを判断するフローＤＬＬの中の機能をコールすることができる。ステップ１３２６では、テスト・ジョブの状態は、コールされたばかりのテスト・テンプレートによって戻された値に基づいて更新される。例えば、テストは、エラーを検出することなく（すなわち、テストは合格）テスト・テンプレートが実行されたか又はエラーが検出されたかを示す。場合によっては、エラーは、テスト対象デバイスのビニング（binning）を容易にする数値を有することがある。
ステップ１３２８では、テストの新たな状態を用いて、ステップ１３２８においてジョブ・フロー・データ構造に記憶された論理的表現を評価する。この評価に基づき、次のテンプレートが、ステップ１３２０において記憶されたブランチング情報を用いて選択される。
実行は、次に、ステップ１３３０に進む。ステップ１３３０では、実行すべき別のテンプレートがあるかどうかが評価される。ある場合には、ジョブ実行は、ステップ１３２４へのループ上に戻る。それ以上のテンプレートがない場合には、フロー制御ソフトウェア３１４は、そのアイドル状態に戻る。
好適実施例では、テスト・ジョブの結果は、テストが終了したときに、ユーザ又は操作デバイス１１４に与えられることはない。データを提供すると、テスト・ジョブの実効速度を低下させることになる。従って、好適実施例では、それぞれのテスト・ジョブの実行結果は、リクエストがなされるまで、コンピュータ・メモリに記憶される。結果をリクエストすると、フロー制御ソフトウェア３１４が、アイドル状態１３１０からステップ１３３２に移動することになる。ステップ１３３２では、結果を人間であるユーザのために表示したり、操作デバイス１１４に送ったりすることができる。結果は、ユーザに都合の良い態様又は操作デバイスに対して適切な態様で表示のためにフォーマット化することができる。
データ・マネジャ３１６に関する詳細をここで述べることにする。データ・マネジャ３１６は、一連のＣ＋＋「クラス」から構成されている。クラスは、関連する状態図（state diagram）を有さない。クラスは、他のプログラミング要素からのリクエストに応答して動作を実行する。クラスは、関連する「方法」を有する。それぞれの方法は、従来のプログラミング機能のようにコールして、クラス内に記憶されているデータにアクセスすることができる。
Ｃ＋＋の方法は、他のＣ＋＋プログラムによって直接的にコールされることができる。図３の実施例では、デバイス・ドライバ３２８は、Ｃ＋＋手順として実現されているので、方法をコールしてデータ・マネジャ３１６内のデータを直接に読み出す又は変更することができる。エクセル・ワークブックは、Ｃ＋＋ではないので、データ・マネジャ３１６からのデータを記憶したり検索したりする方法をコールするのにＡＰＩ（Application Program Interfaces）を必要とする。しかし、ＡＰＩは、広く知られたプログラミング構造である。データは、ビジュアル・ベーシックのマクロを含むエクセル・プログラムと「SafeArray」と称されるフォーマットのデータ・マネジャ３１６との間でやりとりされる。SafeArrayは、市販のスプレッドシート・プログラムであるマイクロソフト・エクセルと共に用いることができるマイクロソフトＯＬＥ（Object Linking and Embedding Language）の一部である。
データ・マネジャ３１６は、「コンテナ」と称される。一連のメモリ構造として実現される。コンテナのフォーマットは、記憶されるデータのタイプに依存する。例えば、ピン・マップ・データは、レベル・シート・データを保持しているコンテナとは異なるフォーマットでコンテナに記憶されている。コンテナのフォーマットは、記憶される情報に基づき、既知のプログラミング技術を用いて定義される。
コンテナは、入れ子状（nested）にすることができる。例えば、ピン・マップに対するコンテナ内部には、複数のピン・グループが存在しうる。それぞれのピン・グループの中には、複数のピンが存在しうる。この例では、コンテナは、３つのレベルの入れ子構造（nesting）を有している。しかし、任意のレベルの入れ子構造を採用することができる。
Ｃ＋＋ＳＴＬ（スタンダード・テンプレート・ライブラリ）は、クラス内のデータを操作するのに有用な方法を含む。これらの方法の中の２つとして、MAP及びVECTORがある。一般に、「コンテナ」は、コンピュータ・メモリの中に、論理的な順序ではなくプログラムによって作成された順序で配分されている。しかし、情報の検索をより容易にするために、コンテナの名称とメモリ内のその物理的位置との間に１組の「キー」（鍵）が作成される。これらのキーは、正確なキーを見つけることによって所望のデータを見つけることができるように、インデクスとして機能する。
MAPの方法は、バイナリ・ツリー（二進木、binary tree）のように分岐している１組のキーを作成する。VECTORの方法は、リストのような、順序付けがなされたインデクスを作成する。MAPの方法の長所は、ランダムなアイテムを迅速に発見することができるということである。MAPの方法の短所は、順序付けが失われているということである。例えば、ピンマップ・データ・シートにおけるピンの順序は、テスト・プログラムにとって重要な情報である。MAPの方法だけを用いると、結果として、順序が失われてしまう。データをデータ・マネジャ３１６に記憶する方法は、MAP及びVECTORのSTLの組合せを用いて、それぞれの長所を達成している。
記憶及び検索機能に加えて、データ・マネジャ３１６は、必要となるデータ管理機能を実行する他の方法を含む。追加的な機能は、SELECT DEFAULT機能である。既に述べたように、１つのテスト・ジョブに複数のピン・マップが存在することがありうる。SELECT DEFAULTの方法は、どのデータの組をデフォルトとして用いるかを指示する。例えば、テスト・ジョブが２つのピン・マップPIN MAP1及びPIN MAP2を有する場合には、PIN MAP1が、デフォルトに設定される。ピン・マップ・データを検索する検索する検索機能をどのように用いても、検索動作が実行されるときにPIN MAP2が明白に指示されていなければ、データは、PIN MAP1から取得される。
データ・マネジャ３１６には、SELECT ACTIVEの方法もまた、含まれうる。この方法は、SELECT DEFAULTと類似しているが、用いられ得るコンテナを特定する。
含まれうる別の方法に、REPLACEの方法がある。既に述べたように、データ・マネジャ３１６は、テスト・ジョブが特定のデバイスをテストするデータのための一連のコンテナである。テスト・ジョブの開発の間に、又は、特定のジョブにおけるテストの間に、そのデバイスに対するデータのいくつかを変更することが望ましい場合がありうる。REPLACEの方法によれば、１組のデータが別のものと交換されることが可能となる。例えば、ユーザがテスト・ジョブの開発プロセスの一部としてデバイスのピン・マップ・スプレッドシートを編集した場合には、ピン・マップ・データ・シートと関連するマクロは、自動的にREPLACEの方法をコールして、テスト・ジョブが実行されるときに新たなデータが用いられることを確認する。データが変更されたときに自動的に実行されるのではなく、REPLACEの方法は、ユーザ入力に応答して動作するマクロによってコールされる。
データ・マネジャにおけるデータがデバイス・ドライバ３２８によって変更される場合には、同様の方法が必要となる。既に述べたように、データ・マネジャ３１６は、本質的に、エクセル・ワークブックの中に維持されるデータとは別個のデータのコピーを維持する。エクセル・ワークブックの中の変更は、REPLACEの方法によって、データ・マネジャ３１６において反映される。データ・マネジャの中のデータがワークブックの内部においてではなく変更された場合には、REPLICATEの方法が必要となる。例えば、デバイス・ドライバたデータ・マネジャにおけるコンテナの１つの中の値を変更する場合には、データ・マネジャ３１６は、REPLICATEの方法をコールすることになる。
REPLICATEの方法は、現在のデータをデータ・マネジャ３１６から読み戻すエクセル・ツールをコールする。データは、適当なエクセルのスプレッドシートの中にロードされ、これによって、ワークブックと関連するエクセルの機能は、変更されたデータに基づいてすべてのデータを再計算することになる。そして、変更されたすべてのスプレッドシートにおけるデータは、データ・マネジャにおいて、交換される。データ・マネジャによって記憶されたデータを変更する動作を実行するテスト・テンプレートは、実行を終了すると、REPLICATEの方法を用いる。
動作
以上で、テスタ１１２を制御するソフトウェアの構造を説明した。このソフトウェアの多くの使用が可能である。１つの可能性のある使用法は、最初にテスト・ジョブを開発し、次に半導体デバイスを製造する間にそのテスト・ジョブを反復的に実行するように用いることである。また、可能性のある使用法は、デバイス・エンジニアが、必要であれば、最初にテスト・テンプレート３２０を編集することであろう。非常に少数のテスト・テンプレートで多くの種類のデバイスをテストすることができることが意図されている。従って、テスト・テンプレートの編集が要求される可能性は低い。
半導体テスト・デバイスの開発者が選択する可能性のある次のステップは、デバイス・データとフロー開発ツール３１０（図３）とを用いることである。これらのツールは、開発されている特定のデバイスに対してエクセル・ワークブックを開くことによってアクセスすることができる。特に、これらのツールは、図４ないし１１に示されているスプレッドシートを表している。マクロ又はウィザードを用いて、これらのフォームに関してユーザを誘導することができる。有効化マクロを、特定のシートに対するデータ・エントリが完了したときに動作させ、他のデータと一貫性のないデータはすべて検出され訂正されるようにすることができる。例えば、プログラマは、ピン・マップにない特定のピンに対するデータ値を入力することができる。しかし、そのような入力は、エラーを示すのであり、その理由は、そのピンがピン・マップから偶然に取り去られたからであったり、又は、特定のピンに対して誤った名称が用いられたからである。
好適実施例では、ソフトウェアは、データが入力されなかった又は変更され有効化されなかった場合にはテスト・ジョブが動作しないようにコード化される。有効化は、ユーザによって、カスタム・メニュ・バーから選択されうる。
データがいったん入力されると、ユーザは、「コンパイル」のオプションを選択する。好適実施例では、このコンパイル・オプションは、フロー・データ・シートに関連するカスタム・メニュ・アイテムから選択される。コンパイル・オプションによって、フロー制御ソフトウェア３１４が、ジョブ・フロー・データ構造を構築することがトリガされる。また、これによって、データ・マネジャ３１６内の方法が、エクセル・ワークブックからデータ・マネジャにデータを転送することになる。
開発環境では、テスト・エンジニアは、次に、プログラムのデバッギングのプロセスを開始する。おそらく、このエンジニアは、デバイスをテスタ１１２に接続する。また、テスト・エンジニアは、シミュレータを用いてテスト・プログラムをデバッギングする可能性もある。シミュレータとは、それに接続されたデバイスを用いてテスタ１１２の動作をシミュレートするソフトウェア・プログラムである。
エンジニアは、既に述べたようなデバッギング・ツールを用いて、プログラムを検査することがありうる。テスト・エンジニアは、プログラムにおけるエラーを検出する際に、テスト・テンプレートを編集することもありうる。テスト・テンプレートは翻訳された言語であるビジュアル・ベーシックで書かれているので、テスト・ジョブをリコンパイル（recompile）することなく、この変更は直ちに効力を生じることができる。
また、テスト・エンジニアは、デバイス・データ構造の１つにおいてデータのいくつかを変更する必要が生じることもある。テスト・エンジニアは、図４ないし１１に示されたスプレッドシート・スクリーンを介してデータにアクセスし得る。次に、有効化プロセスが再び動作する。有効化プロセスの一部として、REPLACEツールが自動的にランする。REPLACEツールを自動的に用いることによって、データ・マネジャ３１６が日付データまでを提供することが保証される。
デバッギングの一部としてテスト・エンジニアがプログラム・フローを変更する場合には、フローは、新たなジョブ・フロー構造が構築され得るようにリコンパイルされなければならない。
要求された変更がデバイス・データ、テスト・テンプレート又はデバイス・フローに対してなされると、テスト・ジョブを再度ランさせることができる。テスト・プログラムに変更を加えるのに要する時間は、非常に短いことがありうる。従来技術によるいくつかのシステムでは、テスト・ジョブに対するどのような変更でも、非常にわずかなものであっても、完全なリコンパイルが要求された。結果として、そのような変更でも、１時間程度を要することがあった。本発明では、テンプレートへの変更は、リコンパイルを全く要求しない。デバイス・データへの変更がなされると、変更されたデータが再ロードされることだけが要求される。変更された場合にコンパイルされなければならないのは、プログラム・フローだけである。コンパイルはフローだけを扱うのであって、すべてのデータを扱うとは限らないので、数秒で実行することができる。
典型的な開発のセッティングでは、テスト・エンジニアは、テスト・ジョブが予測されたとおりに実行されるまでは、テスト・ジョブを変更するプロセスを反復する。完了すると、テスト・ジョブは、製造のセッティングに転送される。製造セッティングでは、デバイス・データ及びフロー開発ツールは、用いられない。同様に、カスタム・インターフェースが開発される。カスタム・インターフェースは、テスタを動かしてパーツをテストするのに必要な制御だけを提供し、基本的な出力情報だけを表示してオペレータにテストが進行していることを知らせる。テスタは多くのデータを測定し記憶することができるが、製造環境ではオペレータに対しほんのわずかな部分だけが提示される。
ソフトウェアはエクセルを用いて実現されているが、ビジュアル・ベーシックのプログラミング言語を用いて、カスタム製造インターフェースを準備することができる。インターフェースにおいて可能性のあるのは、テストを開始し、テストを終了し、いずれかのテストに合格しなかったデバイスの数を示す表示を行うという制御である。
他の実施例
以上で１つの実施例を説明したが、多くの別の実施例又は変更例が可能である。例えば、本発明は、本体（ボディ）と別個のコンピュータ化されたワークステーションとを有するテスタに関して説明されている。しかし、コンピュータ化されたワークステーションがテスタ本体と物理的に分離していることは必要ない。例えば、テスタ本体の内部に組み入れることも可能である。それ以外の構成も可能である。例えば、テスタには、メインフレームとテスト・ヘッドとを有するものがある。しかし、本発明の目的のためには、テスタは、１つ又は複数の異なるパッケージであってもよい。
特定のデータ及びフロー・シートの例を与えてきた。それぞれのローは、特定の数のコラムを有し、それぞれのコラムは、フローにおけるアイテム又はステップに関する特定のタイプの情報を含むように、示した。動作されるタイプによって、テスタのハードウェアや、テスト対象のデバイスの要件、それぞれのローに含まれる情報の数及び種類は、異なることがある。より多く又はより少ないコラムでもかまわない。１つの可能性としては、それぞれのタイプのスプレッドシートに対してスーパー・セット（super set）の可能なコラムを有することである。ユーザは、次に、どのコラムが特定のジョブに対して重要であるのかを選択する。ウィザード（Wizard）を提供して、選択プロセスによってプログラマを誘導することもできる。ウィザードとは、ユーザに選択を促すマクロである。特定のスクリーン上の表示のために選択されていないスーパー・セットにおけるこれらのコラムは、スプレッドシートから全体を削除することができるし、与えられるが表示されないことも可能である。存在するが表示されないコラムは、無視されるか、又は、デフォルト値を与えられる。
フロー制御ソフトウェア３１４はＣ＋＋で書かれているものとして説明してきた。Ｃ＋＋はビジュアル・ベーシックよりも高速に実行することができると広く考えられている。ビジュアル・ベーシックは、市販のスプレッドシート・プログラムであるエクセルの一部であるプログラミング言語である。しかし、フロー制御ソフトウェアがＣ＋＋で書かれている場合にはより高速に実行されるが、デバイスへのインターフェースと、エクセル・プログラムを用いたフロー・データ入力とに要する時間は、より低速であることが認識された。従って、場合によっては、フロー制御ソフトウェアをビジュアル・ベーシックや、市販のスプレッドシート・プログラムの一部である他のマクロ・プログラミング言語で実現することが好ましい。
図１３との関係で既に述べたことであるが、フロー制御ソフトウェア３１４は、単一のパーツをテストするテスト・ジョブを制御する。テスタ１１２は、数百から数千個のピン１２４を有していることが多い。従って、複数のパーツをテスタ１１２に同時に接続するのに十分なだけのピンが存在している。この場合には、ピンは、「サイト」（sites）としてグループ化されている。それぞれのサイトにおけるピンは、同一のデータを取得し、同じ測定を行う。しかし、１つのサイトが１つのエラーを検出する場合には、異なる処理がそのサイトに対して必要となる可能性がある。従って、フロー制御ソフトウェア３１４は、複数のサイトに対して複数のテストを同時に実行するように構成することができる。しかし、どれかのサイトが故障する場合には、そのサイトは、別個にテストされることになる。この機能を実行するには、ステップ１３２６を変更し、サイトの状態を別々にトラッキングすることがありうる。次に、ステップ１３２８は、変更され、それぞれのサイトにおけるデバイスがテスト・ジョブにおける何らかのテストに合格したか不合格であったかによって、それぞれのサイトに対するテンプレートを選択する。
また、テスト・システムは半導体素子をテストすると説明してきた。プリント回路ボード又はそれ以外のデバイスに対するテスト・システムを制御するのにも、同様のソフトウェアを用いることもできる。
更に、市販のスプレッドシート・プログラムを用いることによってテスト・システムを制御するソフトウェアをユーザが容易に理解することができる態様で迅速に実現することができるようになることを説明してきた。図１４は、実現可能な別のツールの例を示している。図１４は、デバグ又は解析ツールとして用いられることが主に意図されたツールを示している。ここでは、データ入力スクリーンが示されている。このスクリーンは、スプレッドシートではなくビジュアル・ベーシックを用いてダイアログ・ボックスとして実現されている。図１４の特定の例は、ただ１つのピン（図１）のハードウェア・セットアップに関係する。ダイアログ・ボックスは、データを入力することができる複数のフィールドを含んでいる。データは、テスタにおけるハードウェアに送られる値を表す。このダイアログ・ボックスが用いられるときには、これは、フロー制御３１４を介する通常のデータ経路をバイパスし、直接にデバイス・ドライバ３２８をコールしてテスタ・ハードウェアにアクセスする。
可能性のある変更の別の例として、市販のスプレッドシート・プログラムは、エクセル以外のものや、図面に示したもの以外のバージョンのエクセルを用いることもできる。図１５には、マイクロソフト社から販売された市販のスプレッドシート・プログラムであるエクセル９７を用いて実現されたデータ・エントリ・スクリーンの例を示してある。複数の追加的な特徴が、エクセル９７を用いることを通じて可能である。制御要素１５１０は、グループ表示制御である。複数のローのデータが同じグループに書き込まれた場合には、表示は、ただ１つのローだけがそのグループを表示する専用となるように、隠れてしまう可能性がある。図１５では、例えば、１５１２及び１５１４において示されたローは、すべて、「rdcycle」と命名されるタイム・セットの中にある。すべてのローが示されており、グループは拡張（復活）したと称される。しかし、グループ表示制御１５１０が用いられる場合には、ただ１つのローだけがそのグループに対して示される。他のローを見ることができないにもかかわらず、それらのローは、図１５のデータ・エントリ・スクリーンを用いて実行される任意の動作によって作用を受ける。
エクセル９７の使用を介して用いられる別の特徴として、データを、そのタイプに基づいて異なる外観にすることがある。例えば、セル１５１６内のデータは、セル１５１８の中のデータとは異なる外観を有する。この理由は、セル１５１６におけるデータには、アドレス・バスのためのタイプが割り当てられ、セル１５１８の中のデータには、データ・バスのためのタイプが割り当てられているからである。異なるタイプのデータを視覚的に区別することによって、ソフトウェアをより容易に用いることが可能になる。
図１６Ａ及び１６Ｂには、行うことができるそれ以外の強化策（enhancements）が図解されている。グループ制御要素１６１０は、その拡張（展開）状態で示されている。従って、「General Info」として示されているグループに対して示された要素のリストが存在する。対照的に、グループ制御１６１２は、その非拡張状態で示されている。このように、グループ「Digital Setup」に対するエントリは示されていない。
図１６Ａ及び１６Ｂは、また、グループを視覚的に区別可能とすることの利点を強調している。例えば、フィールド１６１４及び１６１６は、異なるタイプのデータを含むために異なる外観を呈する。
図１６Ａ及び１６Ｂに示されている別の特徴は、ナビゲーションの特徴である。これまでの例では、ツールにアクセスするには、スクリーンの最下部にあるタブを選択することによった。図１６Ａ及び１６Ｂは、スクリーンは「ホット・リンク」を用いて相互にリンクすることが可能であることを示している。別のスクリーンからスクリーンの名称をクリックすることにより、ユーザは、スクリーン表示を変更することができる。また、ナビゲーション・ツール・バーは、所望のデータ・スクリーンを見つけるために有用なツールを含んでいる。ナビゲーション・ツール・バーは、インターネット・ナビゲータで見出されるツールを含む。このツールは、先のスクリーンに移動するとか、予め特定しておいた好みのスクリーンに行くなどの動作を実行する。
エクセル９７を用いることの別の利点として、それが、オブジェクト指向言語である点がある。それぞれのデータ・スクリーンはオブジェクトである。データ・スクリーンなどのそれぞれのオブジェクトは、それに関連するクラスを有している。すべてのデータ・シートにベース・クラスを与えることが可能であり、このベース・クラスが、任意のデータ・シートに共通の動作を定義する。例えば、エラー処理、データ・タイプ及びフォーマッティングなどが、ベース・クラスにおいて定義されうる。データの有効化やデータのデータ・マネジャへの送出などそれ以外の機能は、そのベース・クラスに対する「公共的な方法」（public methods）として定義することができる。このようにして、これらの能力の全体が、すべてのデータ・スクリーンに提供される。ただし、これらが特定されるのは１回だけである。等しく重要なことであるが、それぞれのデバイス・データ又はフロー・データ・ツールは、同じように動作する。
オブジェクト指向プログラミングを用いることによって可能となるこれ以外の変更は、シート間のエラー（inter-sheet errors）を瞬間的に有効化することである。有効化規則は特定することができ、データは、入力されたときにチェックされる。複数のシートの間で一貫性のないデータをチェックする有効化ルーチンは、依然として動作させることができる。
従って、本発明は、請求の範囲の精神と範囲とによってだけ限定されるべきものである。

Claims (8)

1. 複数のテスト信号を生成及び測定する電子回路（１２０、１２２、１２４、１２６、１２８）を保持するテスタ本体（１１２）と、
   前記テスタ本体（１１２）内の前記電子回路に制御情報を提供するコンピュータ・ワークステーション（１１０）と、
   を有する半導体テスト・システムにおいて、
   前記コンピュータ・ワークステーションは、制御ソフトウェアによって制御され、該制御ソフトウェアは、
   それぞれが前記テスタ本体内の前記電子回路の一部を制御するように配置された複数のデバイス・ドライバ・プログラム要素（３２８）と、
   市販のスプレッドシート・プログラムにより作成された複数タイプのスプレッドシート（３１２）であって、
   テスト対象デバイスに関するデータを保持するように構成された第１タイプのスプレッドシートと、
   テスト対象デバイスに対するテスト・ジョブの間に実行されるステップに影響を及ぼすテストフロー情報を保持するように構成された第２タイプのスプレッドシートと、
   を含む複数タイプのスプレッドシートと、
   前記第２タイプのスプレッドシートからテストフロー情報を受け取り、前記受け取ったテストフロー情報によって決定される前記第１タイプのスプレッドシートに含まれるデータを、前記受け取ったテストフロー情報によって決定される順序で前記複数のデバイス・ドライバ・プログラム要素に提供することによってテスト・ジョブの実行を制御する制御プログラム手段（３１４、３１６、３２０）であって、前記第２タイプのスプレッドシートからテストフロー情報を読み出すように統合された前記スプレッドシート・プログラムに含まれる統合型プログラム言語で書かれたフロー制御プログラム手段（３１４）を含む制御プログラム手段と、
   を備えることを特徴とする、半導体テスト・システム。
2. 請求項１に記載の半導体テスト・システムにおいて、前記複数タイプのスプレッドシートはワークブックに構成され、前記ワークブック内の１つのスプレッドシートにおけるデータは、前記ワークブック内の別のスプレッドシートにおいて利用可能である、半導体テスト・システム。
3. 請求項１又は２のいずれかに記載の半導体テスト・システムにおいて、前記制御ソフトウェアは、前記テスト・ジョブの１つのステップの間に実行される機能をそれぞれ表す複数のテスト・プログラム要素を更に含み、前記第２タイプのスプレッドシートの一つは複数のローを含むフロー・シートであり、前記複数のローの少なくとも一部は、それぞれが、
   前記テスト・プログラム要素に対する識別子と、
   前記テスト・プログラム要素が実行にあたり失敗を示した場合に、前記テスト対象デバイスに割り当てられる分類の表示と、
   を含む、半導体テスト・システム。
4. 請求項３記載の半導体テスト・システムにおいて、フロー・シートにおける前記複数のローの少なくとも一部は、それぞれが、
   前記テスト・プログラム要素が実行にあたり失敗を示した場合に設定されるフラグの名称と、
   前記テスト・プログラム要素がどのテスト対象デバイスに適用されるべきかを指示するブール表現であって、１つのローにおける前記ブール表現は、先行する他のローにリスト化されているフラグを参照する、ブール表現と、
   を更に含む、半導体テスト・システム。
5. 請求項３又は４記載の半導体テスト・システムにおいて、それぞれのフロー・シートは、該フロー・シートと関連付けられた手段であって、前記テスト・ジョブの実行を修正する引数を入力する手段を更に備える、半導体テスト・システム。
6. 請求項３〜５のいずれかに記載の半導体テスト・システムにおいて、前記テスト・プログラム要素のそれぞれはテスト・テンプレート（３２０）を含み、前記複数のスプレッドシートの前記第２タイプのスプレッドシートの一つは、複数のローを含むインスタンス・シートであり、前記複数のローの少なくとも一部は、それぞれが前記テスト・テンプレートを用いてテスト・インスタンスを定義し、
   前記テスト・テンプレートに対する識別子と、
   前記テスト・インスタンスに対する識別子と、
   を含み、
   前記インスタンス・シートは、前記テスト・テンプレートと組み合わされて前記テスト・インスタンスを形成する前記第１タイプのスプレッドシートのうちの選択されたスプレッドシートを特定する手段（１０３６）を更に含み、
   前記フロー・シートにおけるテスト・プログラム要素に対する前記識別子は、テスト・インスタンスに対する前記識別子である、
   半導体テスト・システム。
7. 請求項６記載の半導体テスト・システムにおいて、前記テスト・テンプレートのそれぞれは、翻訳されたプログラミング言語で書かれている、半導体テスト・システム。
8. 請求項１〜７のいずれかに記載の半導体テスト・システムであって、前記制御ソフトウェアは、
   市販のスプレッドシート・プログラムにおけるアプリケーションとして実現され、
   前記コンピュータ・ワークステーションのディスプレイに表示されて、テスト対象デバイスに関するデータ及びテスト・プログラムのフローに関するデータのユーザによる入力をそれぞれ受け取る複数のデータ入力画面を生成する、制御ソフトウェアであり、
   前記データ入力画面のそれぞれは、
   ａ）ロー及びコラムに形成された複数のデータ・セルを有するデータ・セル・フィールドであって、それぞれのコラムは同一タイプのデータを保持し、前記複数のデータ入力画面のうち第１部分に含まれる一又は複数のデータ入力画面におけるデータ・セルはテスト対象半導体デバイスに関するデータを保持し、前記複数のデータ入力画面のうち第２部分に含まれる一又は複数のデータ入力画面におけるデータ・セルは前記テスト対象半導体デバイスのためのテスト・プログラム実行のフローに関するデータを保持する、データ・セル・フィールドと、
   ｂ）複数のツール・アイコンを有するツール・バー・フィールドであって、前記ツール・アイコンは、前記テスト対象半導体デバイスに関するデータまたは前記テスト・プログラム実行フローに関するデータを変更する操作機能を表す、ツール・バー・フィールドと、
   ｃ）前記複数のデータ入力画面をそれぞれ表す複数のタブを有し、それぞれのタブが異なるデータ入力画面にアクセスするように選択可能であるタブ・フィールドと、
   ｄ）それぞれが複数のサブメニュ・アイテムを示すように選択可能である複数のメニュ・アイテムを有するメニュ・バー・フィールドであって、前記メニュ・アイテムの少なくとも１つの下にある前記サブメニュ・アイテムは、前記タブ・フィールドで選択されたタブに応じて現れるサブメニュ・アイテムを含む、メニュ・バー・フィールドと、
   を有する複数のデータ入力画面であって、
   前記データ・セル・フィールド、前記ツール・バー・フィールド、前記タブ・フィールド及び前記メニュ・バー・フィールドが、前記複数のデータ入力画面のそれぞれにおいて同じ位置にレイアウトされるデータ入力画面を生成する制御ソフトウェアを備える、半導体テスト・システム。

Images