【０００１】
【発明の属する技術分野】
本発明は、半導体の検査プログラムの検証に用いられる、検査条件抽出プログラムに関するものである。
【０００２】
【従来の技術】
半導体は、近年集積化が進み、その検査には膨大な検査項目が必要である。検査プログラムの検査条件が正しいか否かは、検査の品質に関わる重大な問題であり、十二分にもチェックをしなければならない。
【０００３】
検査プログラム開発が完全に自動化されている場合には、検査条件の設定ミスの可能性はないが、現実には検査プログラムを完全に自動では開発できず、一部手修正が入ったり、最初から人手で作成したりする場合がある。よって、検査条件のチェックには、検査仕様書と検査プログラムに記述されている検査条件が完全に一致していることを人手で確認しなければならない（非特許文献１参照）。
【０００４】
検査プログラムに記述されている検査条件を知るためには、１つは、検査プログラムを読み設定条件を得る方法がある。しかし、検査条件記述部に変数を使ったりサブルーチンを使ったりしているため、プログラムを熟読しても誤る可能性が高いし、また、工数も膨大になる。
【０００５】
そこで有効なのが、検査プログラムを半導体検査装置（以下テスターと呼ぶ）で走らせ、その時テスターに設定されている値を読み出す方法である。この時読み出された値は、まさにテスターハードの設定値であるので、最も正確である。
【０００６】
テスターハードの設定値を読み出す方法について説明する。
【０００７】
まず、テスターに検査プログラムを読み込ませ、検査プログラムを走らせる。ハードの設定値を読み出すことが目的なので、半導体デバイスは必ずしも必要ではない。目的のテスト項目を繰り返し実施し、ハードの設定値を読み出すツールを起動する。一般に、ハードの設定値を読み出すツールは、テスターに準備提供されている。
【０００８】
一つのテスト項目についてハードの設定値の読み出しを完了したら、次のテスト項目を繰り返し実行し、同様にハード設定値を読み出す。これを、最後のテスト項目まで実施したら、結果をファイルに出力する。
【０００９】
このようにして、必要とするテスターハードの設定値を次々読み出すことで、検査条件を知ることができる（特許文献１参照）。
【００１０】
しかし、この方法では、目的とするテスト項目ごとにテストを繰り返し実行し、ツールを起動し、ハード設定値を読み出すという作業をくりかえさなければならない。今日のように検査項目が数百を越える場合、手作業で行うには工数がかかる。
【００１１】
全テスト項目の検査条件を自動的に出力する機能をもつツールも、従来知られているが、出力が数百ページものドキュメントになり、実用的ではない。
【００１２】
また、半導体検査では、ウェハー状で実施するプローブ検査と、組み立て後に実施する組み立て検査のように、複数工程の検査が実施される。上述の方法では１工程の検査条件ファイルは作成できるが、複数工程の検査条件を作成するためには、必要工程分上記作業を行い、それぞれの検査条件を加工する作業が必要である。
【００１３】
そのような作業の従来の手法について、図７を用いて説明する。
【００１４】
８１，８２，８３はそれぞれ第１、第２、第ｎの検査工程の検査プログラム、８４，８５，８６はそれぞれ第１、第２、第ｎの検査工程の検査条件を抽出する工程、９１，９２，９３はそれぞれ第１、第２、第ｎの検査条件をファイル出力する工程、９４は第１〜第ｎ工程の検査条件ファイルをそれぞれ読み込む工程、９５は全検査工程の検査条件ファイルを出力する工程である。また、８８はテスター、９６はＥＷＳを示す。
【００１５】
まず、第１工程の検査プログラム８１をテスター８８で実行する。このとき工程８４で各テスト項目の検査条件をテスターハードから読み出す。工程９１で検査条件をファイルに出力する。
【００１６】
次に、第２工程の検査プログラム８２をテスター８８で実行する。このとき工程８５で各テスト項目の検査条件をテスターハードから読み出す。工程９２で検査条件をファイルに出力する。
【００１７】
以上のような処理を、最終工程ｎまで繰り返す。
【００１８】
次に、工程９１から９３で出力されたファイルを、工程９４でＥＷＳ９６に読み込む。工程９５で、全工程の検査条件をまとめて、ファイルに出力する。
【００１９】
【特許文献１】
特開平１０−１８５９８７号公報
【００２０】
【非特許文献１】
Ａ．Ｍａｔｓｕｍｏｔｏ，”Ｄｅｓｉｇｎ Ｒｅｖｉｅｗ ｆｏｒ ｔｈｅ Ｅｓｔａｂｌｉｓｈｍｅｎｔ ｏｆ ｔｅｓｔｉｎｇ”，ＳＥＭ−ＩＣＯＮ Ｊａｐａｎ ９７
【００２１】
【発明が解決しようとする課題】
このように、従来の手法では、全検査項目の検査条件を作成するのに工数がかかり、また、作成された検査条件ファイルも膨大な量となるので、検査仕様書とのチェックは容易ではない。
【００２２】
本発明は、以上の問題を鑑み、半導体検査プログラムに関して、分かりやすく正確な検査条件ドキュメントファイルを簡単に作成するための検査条件抽出プログラムを提供することを目的とする。
【００２３】
【課題を解決するための手段】
上記の目的を達成するために、本発明にかかる半導体検査プログラムの検査条件抽出プログラムは、半導体検査プログラムのテスト条件を、当該半導体検査プログラムを実行する半導体検査装置のハードウェアに設定されている値から読み出す機能と、検査条件を抽出する対象ハードウェアを選択し、選択されたハードウェアの設定値のみ出力する機能とを、コンピュータに実現させることを特徴とする。
【００２４】
【発明の実施の形態】
本発明にかかる半導体検査プログラムの検査条件抽出プログラムは、上述したように、検査条件を出力する対象とするハードを選択できるよう出力対象ハード選択機能を設けることにより、不要な検査条件の出力を省略することができ、分かりやすく正確な検査条件ドキュメントファイルを簡単に作成することが可能となる。
【００２５】
また、本発明にかかる検査条件抽出プログラムにおいて、前記ハードウェアの設定値を出力する際に、同じ検査条件のテスト項目をまとめて出力する機能をコンピュータに実現させることとしても良い。
【００２６】
従来は、１回の作業では１検査工程の検査条件ファイルしか作成できず、検査工程ごとの検査条件を他検査工程と比較してチェックすることが容易ではなかったため、チェックの工数が大きかった。これに対して、本発明の検査条件抽出プログラムによれば、同じ検査条件のテスト項目をまとめて出力することにより、チェックが容易となる。
【００２７】
また、本発明にかかる検査条件抽出プログラムにおいて、複数検査工程の検査プログラムから検査条件を抽出し、各検査工程の検査条件をメモリに保存し、最終検査工程の検査条件抽出時に各検査工程でのテスト項目実施有無を判断し、実施している場合は該検査工程の検査条件を出力する機能をコンピュータに実現させることとしても良い。
【００２８】
従来は、複数工程の検査条件ファイルをまとめて作成するためには、ＥＷＳなど別のコンピュータで、加工用のプログラムを別途作成し、処理しなければならなかった。よって、ＥＷＳが付随していないテスターではその作業ができないため、ＥＷＳへのファイル転送という手間が発生していた。また、図７に示したように、検査条件を出力したファイルを、各検査工程ごとに検査工程数分だけ読み込む作業が発生し、二度手間で工数が大となっていた。これに対して、本発明にかかる検査条件抽出プログラムによれば、最終検査工程を除く各検査工程の検査条件を、最終検査工程において前記メモリから読み出してまとめてファイルへ出力することにより、ＥＷＳを用いなくても複数検査工程の検査条件ファイルをまとめて出力することができる。
【００２９】
また、前記最終検査工程において、当該最終検査工程において抽出された検査条件を前記メモリを介さずにファイルへ直接出力し、最終検査工程を除く各検査工程の検査条件を前記メモリから読み出して前記ファイルへ出力することとしても良い。これにより、メモリを有効活用することができる。
【００３０】
以下、本発明の具体的な実施形態の一例について、図面を参照しながら説明する。
【００３１】
図１に、本発明の検査条件抽出プログラムによる処理のフローを示す。
【００３２】
図１において、１，２，３はそれぞれ第１、第２、第ｎの検査工程の検査プログラム、４，５，６はそれぞれ第１、第２、第ｎの検査工程の検査条件を抽出する工程、７は全検査工程の検査条件をファイルに出力する工程である。第ｎ検査工程は最終検査工程である。また、８はテスターである。すなわち、工程４〜７は、テスター８により実行される。
【００３３】
テスター８において、第１〜第ｎ検査工程の検査プログラムを実行し、各検査工程の検査条件をテスター上のメモリ（図示せず）に保存する。最終検査工程（第ｎ検査工程６）を実施するときに、この検査工程の各テスト項目の検査条件を抽出してメモリを介さずファイルへ直接出力すると共に、第１〜第ｎ−１検査工程での検査条件を、前述のメモリから同じファイルへ出力する。
【００３４】
このように、各検査工程でファイル出力を行わず、最終検査工程で全検査工程の検査条件を一度にファイル出力することにより、処理効率が向上する。
【００３５】
ここで、本実施形態における第１〜第ｎ検査工程の検査プログラム１，２，３の構造を図２に示す。なお、図２では、第１検査工程の検査プログラム１を例示するが、第２〜第ｎ検査工程の検査プログラムもこれと同様である。図２に示すように、検査プログラム１には、検査条件出力対象ハードを選択するルーチン２１と、各テスト項目実行時にルーチン２１で選択されたハードに設定されている値を読み出すルーチン２２と、ルーチン２２で読み出した検査条件をメモリに保存するルーチン２３と、最終検査工程ｎで全検査工程の検査条件をまとめるルーチン２４と、全検査条件をファイルに出力するルーチン２５から成るプログラム２０が組み込まれる。
【００３６】
ルーチン２１において検査条件出力対象として選択されるハードとは、汎用的に全テスト項目で使用すると考えられるハードで、かつ、検査仕様に関わるハードである。例えば、電源部、入力電圧印加部、出力電圧比較部、測定周波数設定部、測定判定部、および、テスト対象ピン等が、選択対象となる。なお、ルーチン２１における選択対象ハードは、これらの例に限定されない。電源クランプ部や特殊テスト用テスターハードを除く任意のハードを、選択対象とすることができる。
【００３７】
組み込みプログラム２０は、別ファイルに記述しておき、検査プログラム１にはそのファイルを挿入する命令（ＩＮＳＥＲＴ命令など）で記述しておけば良い。このようにすれば、他の検査プログラム２，３にも、組み込みプログラム２０を容易に組み込める。
【００３８】
上記組み込み後の検査プログラム１をテスター上で走らせる。
【００３９】
検査プログラム１は、第１のテスト項目を実行するため各ハードに必要な条件を設定していく。第１のテスト項目の設定が完了すると、第１のテスト項目が実施される。この時、組み込まれたルーチン２２の作用により、ハードに設定された値が読み出される。この値をルーチン２３によりメモリ変数に代入する。
【００４０】
テスターのメモリには限りがあるため、メモリを有効に使用しなければ全テストの条件は保存できない。このため、本実施形態では、以下のようにメモリ配置を工夫している。
【００４１】
図３に、メモリの配置の一例を概念的に示す。検査条件が全く同じテスト項目のテストを１つのテストグループと考え、テストグループ毎に検査条件を管理する。これにより、全テスト項目の検査条件を保持する必要がなく、メモリの有効活用ができる。ＥＷＳが接続されていないテスターでは、一般にメモリも小規模であるので、この手法により、大規模回路の検査条件を保持することも可能である。
【００４２】
メモリ変数は、同じ検査条件を持つテストグループのテスト数を保有する第１変数と、同じ検査条件を持つ、つまり同じテストグループに属するテスト番号を保有する第２変数と、該検査条件を保有する第３変数からなる。検査条件を保有する第３変数は、組み込みルーチンにおいて選択されたハードの検査条件だけを保有するように割り当てられる。これは、第３変数の第３配列要素に対応するハードを割り当てることで実現する。
【００４３】
このフローを、図４に示す。
【００４４】
まず、第１のテスト項目について検査プログラム１を実行する（ステップＳ４１）。このとき、組み込みルーチン２２，２３により、ハードに設定された値が読み出され、以下のように処理される（ステップＳ４２）。まず、テストグループ番号には“１”が割り当てられる。テスト数を保有する第１変数については、配列要素ｅ１はテストグループ番号“１”、配列要素ｅ２は検査工程を要素とし、テスト数“１”が代入される。テスト番号を保有する第２変数については、配列要素ｅ１はテストグループ番号“１”、配列要素ｅ２は検査工程を要素とし、第１のテスト項目のテスト番号が代入される。検査条件を保有する第３変数については、配列要素ｅ１はテストグループ番号”１”、配列要素ｅ２は検査工程、配列要素ｅ３は検査条件を抽出したハードを要素とし、指定されたハードの設定値が保有される。これで、組み込みルーチン２３の処理は終わり、フローは通常のテストフローに戻る。このときの各変数の状態は、図４のＳ４２に示すとおりである。
【００４５】
次に、第２のテスト項目の条件が設定され、第２のテスト項目について検査プログラム１が実行される（ステップＳ４３）。この時も、組み込みルーチン２２，２３により、ハードに設定された値が読み出され、以下のように処理される。
【００４６】
まず、第２のテスト項目で読み出されたハード条件を、第１のテスト項目で保存された第３変数のハード条件と比較する（ステップＳ４４ａ）。
【００４７】
すべての検査条件が一致した場合、テスト数を保有する第１変数の値に１を加算する。また、テスト番号を保有する第２変数には、第２のテスト項目のテスト番号を追加する。検査条件を保有する第３変数は変更されない。この場合の各変数の状態を図４のステップＳ４４ｂに示す。これで組み込みルーチンでの処理は一旦終わりフローは通常のテストフローに戻る。
【００４８】
なお、前記ステップＳ４４ａにおいて１つでもハードの条件が一致しなかった場合、第１のテスト項目と第２のテスト項目は別のテストグループと見なし、テストグループ番号に１を加算する。
【００４９】
テスト数を保有する第１変数については、配列要素ｅ１はテストグループ番号“２”、配列要素ｅ２は検査工程を要素とし、テスト数“１”が代入される。テスト番号を保有する第２変数については、配列要素ｅ１はテストグループ番号“２”、配列要素ｅ２は検査工程を要素とし、第１のテスト項目のテスト番号が代入される。検査条件を保有する第３変数については、配列要素ｅ１はテストグループ番号“２”、配列要素ｅ２は検査工程、配列要素ｅ３は検査条件を抽出したハードを要素とし、指定されたハードの設定値が保有される。このときの各変数の状態を図４のステップＳ４４ｃに示す。
【００５０】
上述の処理を、以下同様にして、第３のテスト項目から最後（第ｎ）のテスト項目まで実行する。
【００５１】
検査工程が１工程のみの場合は、テスト番号を保存する第２変数を、テスト数を保存する第１変数の値分だけ読み出すことにより、該テストグループに属するテスト番号を列挙できる。検査条件を保存する第３変数の値を選択されたハード分だけ順次出力すれば、テスト番号と検査条件とを符合させることができる。しかも、同じ検査条件のテストはまとめて出力されているので、出力ファイルの量は小規模である。また、検査仕様書とのチェックも容易になり、誤りも削減できる。
【００５２】
一方、検査工程が複数の場合は、最終検査工程（第ｎの検査工程）を除き、第１検査工程から第ｎ−１検査工程まで同じ処理を繰り返す。この時メモリの状態は初期化されないようにする。
【００５３】
最終検査工程（第ｎの検査工程）では、検査条件を読み出しながら、他の検査工程の検査条件を変数から読み出し同時に出力していく。検査工程の管理は、第１変数から第３変数まで、配列要素ｅ２で管理可能である。また、最終工程の条件はメモリに保存する必要がないので、メモリが削減できる。これは、メモリが少ないテスターでは非常に有効である。
【００５４】
複数検査工程の検査では、必ずしも各検査工程で各テストのテスト順番が同じであるとは限らない。また、ある検査工程でのみ実施されるテストもある。
【００５５】
そうした不規則なテスト順番の検査条件を出力するための手法を説明する。
【００５６】
最終検査工程（第ｎの検査工程）の検査プログラムに組み込みプログラム２０を挿入し、テスターで実行する。第１のテスト項目における組み込みプログラム２０の処理を、図５を用いて説明する。第１のテスト項目と同じテスト番号が他の検査工程に存在するかどうかを調べるため、テスト番号を保存する第２変数を検索する。
【００５７】
第１検査工程で存在すれば、第１検査工程で第１のテスト項目を実行するまでに別のテスト項目が実行されていないかを検索する。テスト番号を保存する第２変数は該検査工程でのテストの実施順にテスト番号を保存しているので容易に検索できる。
【００５８】
別のテスト項目ｘが実施されている場合は、第１検査工程のテスト項目ｘの検査条件を出力する。
【００５９】
これを、第ｎ−１検査工程まで同様に行う。
【００６０】
最終検査工程（第ｎの検査工程）ではテスト項目ｘは実施されていないので、最終検査工程（第ｎの検査工程）の条件欄は例えば“−”のように出力する。そして、第１のテスト項目のテスト番号と検査条件とを全検査工程分出力する（出力５１）。図６（ａ）に、この出力５１の一例を示す。
【００６１】
別のテスト項目ｘが実施されていない場合は、テスト項目１の検査条件を出力する（出力５２）。図６（ｂ）に、出力５２の一例を示す。
【００６２】
他の検査工程で最終検査工程ｎの第１のテスト項目が実施されていない場合は、該検査工程の検査条件欄は例えば“−”のように出力する（出力５３）。図６（ｃ）に、出力５３の一例を示す。
【００６３】
次に、最終検査工程（第ｎの検査工程）の検査プログラムは、第２のテスト項目を実施する。第２のテスト項目と同じテスト番号が他の検査工程に存在するかどうかを調べるため、テスト番号を保存する第２変数を検索する。存在すれば、第１のテスト項目から第２のテスト項目を実行するまでに別のテスト項目が実行されていないかを検索する。この手法は、第１のテスト項目でおこなったものと同じである。
【００６４】
以下、上述の処理を、最終検査工程の全テスト項目について実施する。
【００６５】
最終検査工程の検査プログラムが終了する前に、検査条件の出力先ファイルを閉じておく。
【００６６】
この手順により、全検査工程の全テスト項目の検査条件が同じ検査条件ごとにまとめられ、１つのファイルに出力される。
【００６７】
以上のように、本発明により、簡単に正確な検査条件ドキュメントファイルが作成できる。また、ＥＷＳを必要とせずテスター上で処理できるため、作業工数も削減できる。さらに、使用メモリも削減できるので、低機能テスターでの実行も可能となる。
【００６８】
【発明の効果】
以上に説明したように、本発明によれば、半導体検査プログラムに関して、分かりやすく正確な検査条件ドキュメントファイルを簡単に作成するための検査条件抽出プログラムを提供できる。
【図面の簡単な説明】
【図１】本発明の一実施形態にかかる検査条件抽出プログラムの構成を示す説明図
【図２】本発明の一実施形態にかかる検査プログラムおよび組み込みプログラムの構造を示す説明図
【図３】本発明の一実施形態にかかる変数マップ
【図４】本発明の一実施形態において、検査条件をメモリに保存する処理のフローを示す説明図
【図５】本発明の一実施形態において、複数検査工程の検査条件出力フローを示す説明図
【図６】（ａ）〜（ｃ）は、図５のフローを実行した場合の出力例を示す説明図
【図７】従来の検査条件抽出プログラムの構成を示す説明図
【符号の説明】
１ 第１検査工程の検査プログラム
２ 第２検査工程の検査プログラム
３ 第ｎ検査工程の検査プログラム
４ 第１検査工程の検査条件抽出工程
５ 第２検査工程の検査条件抽出工程
６ 第ｎ検査工程の検査条件抽出工程
７ 全検査工程の検査条件ファイル出力工程
８ テスター
５１〜５３ 出力
８１ 第１検査工程の検査プログラム
８２ 第２検査工程の検査プログラム
８３ 第ｎ検査工程の検査プログラム
８４ 第１検査工程の検査条件抽出工程
８５ 第２検査工程の検査条件抽出工程
８６ 第ｎ検査工程の検査条件抽出工程
８８ テスター
９１ 第１検査工程の検査条件ファイル出力工程
９２ 第２検査工程の検査条件ファイル出力工程
９３ 第ｎ検査工程の検査条件ファイル出力工程
９４ 第１〜第ｎ検査工程の検査条件ファイル読み込み工程
９５ 全検査工程の検査条件ファイル出力工程
９６ ＥＷＳ
２０ 組み込みプログラム[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to an inspection condition extraction program used for verifying a semiconductor inspection program.
[0002]
[Prior art]
Semiconductors have been increasingly integrated in recent years, and a huge number of inspection items are required for the inspection. Whether or not the inspection conditions of the inspection program are correct is a serious problem related to the quality of the inspection and must be checked more than enough.
[0003]
If the inspection program development is completely automated, there is no possibility of incorrect setting of the inspection conditions, but in reality, the inspection program cannot be developed completely automatically, and some manual corrections may be made, And may be created manually. Therefore, in checking the inspection conditions, it is necessary to manually confirm that the inspection conditions described in the inspection specification and the inspection program completely match (see Non-Patent Document 1).
[0004]
One way to know the inspection conditions described in the inspection program is to read the inspection program and obtain the setting conditions. However, since variables or subroutines are used in the inspection condition description section, there is a high possibility that an error will occur even if the program is carefully read, and the number of steps will be enormous.
[0005]
Therefore, an effective method is to run an inspection program on a semiconductor inspection apparatus (hereinafter, referred to as a tester) and read a value set in the tester at that time. The value read out at this time is exactly the set value of the tester hardware, and is therefore the most accurate.
[0006]
A method for reading the setting value of the tester hardware will be described.
[0007]
First, the test program is read by the tester, and the test program is run. Since the purpose is to read out the set values of hardware, a semiconductor device is not always necessary. Execute the target test item repeatedly and start the tool that reads the hardware setting values. Generally, a tool for reading a hardware setting value is prepared and provided to a tester.
[0008]
When the reading of the hardware setting value for one test item is completed, the next test item is repeatedly executed, and the hardware setting value is similarly read. When this is performed up to the last test item, the result is output to a file.
[0009]
In this way, by reading out the necessary tester hardware set values one after another, the inspection conditions can be known (see Patent Document 1).
[0010]
However, in this method, it is necessary to repeatedly execute the test for each target test item, activate the tool, and read out the hardware setting values. When the number of inspection items exceeds several hundreds as in today, it takes a lot of time to perform manually.
[0011]
A tool having a function of automatically outputting inspection conditions of all test items is also conventionally known, but the output is a document of several hundred pages, which is not practical.
[0012]
In the semiconductor inspection, a plurality of inspection steps are performed, such as a probe inspection performed on a wafer and an assembly inspection performed after assembly. In the above-described method, an inspection condition file for one process can be created. However, in order to create inspection conditions for a plurality of processes, it is necessary to perform the above operations for the required processes and to process each inspection condition.
[0013]
A conventional method of such an operation will be described with reference to FIG.
[0014]
81, 82, and 83 are inspection programs for the first, second, and n-th inspection processes, respectively; 84, 85, and 86 are processes for extracting inspection conditions for the first, second, and n-th inspection processes, respectively; Reference numerals 92 and 93 denote the steps of outputting the first, second and n-th inspection conditions as files, respectively 94 the step of reading the inspection condition files of the first to n-th steps, and 95 output the inspection condition files of all the inspection steps This is the step of performing Reference numeral 88 denotes a tester, and 96 denotes an EWS.
[0015]
First, the test program 81 of the first step is executed by the tester 88. At this time, in step 84, the inspection condition of each test item is read from the tester hardware. In step 91, the inspection conditions are output to a file.
[0016]
Next, the inspection program 82 of the second step is executed by the tester 88. At this time, in step 85, the inspection condition of each test item is read from the tester hardware. In step 92, the inspection conditions are output to a file.
[0017]
The above processing is repeated until the final step n.
[0018]
Next, the file output in steps 91 to 93 is read into the EWS 96 in step 94. In step 95, inspection conditions for all steps are put together and output to a file.
[0019]
[Patent Document 1]
JP-A-10-185987
[Non-patent document 1]
A. Matsumoto, "Design Review for the Establishment of Testing", SEM-ICON Japan 97
[0021]
[Problems to be solved by the invention]
As described above, in the conventional method, it takes a lot of time to create the inspection conditions for all the inspection items, and the created inspection condition files are enormous, so that it is not easy to check the inspection specifications. .
[0022]
In view of the above problems, an object of the present invention is to provide an inspection condition extraction program for easily creating an easy-to-understand and accurate inspection condition document file for a semiconductor inspection program.
[0023]
[Means for Solving the Problems]
In order to achieve the above object, an inspection condition extraction program for a semiconductor inspection program according to the present invention includes a test condition of the semiconductor inspection program, which is a value set in hardware of a semiconductor inspection device that executes the semiconductor inspection program. And a function of selecting a target hardware from which inspection conditions are extracted and outputting only a set value of the selected hardware.
[0024]
BEST MODE FOR CARRYING OUT THE INVENTION
As described above, the inspection condition extraction program of the semiconductor inspection program according to the present invention omits output of unnecessary inspection conditions by providing an output target hardware selection function so that hardware for outputting inspection conditions can be selected. This makes it possible to easily create an easy-to-understand and accurate inspection condition document file.
[0025]
Further, in the inspection condition extraction program according to the present invention, when outputting the hardware setting values, the computer may have a function of collectively outputting test items of the same inspection condition.
[0026]
Conventionally, an inspection condition file for only one inspection process can be created in one operation, and it is not easy to check the inspection conditions for each inspection process as compared with other inspection processes. On the other hand, according to the inspection condition extraction program of the present invention, checking is facilitated by collectively outputting test items of the same inspection condition.
[0027]
In the inspection condition extraction program according to the present invention, the inspection conditions are extracted from the inspection program of the plurality of inspection processes, the inspection conditions of each inspection process are stored in a memory, and the inspection conditions in each inspection process are extracted at the time of extracting the inspection conditions of the final inspection process. The function of judging the presence / absence of the test item and outputting the inspection condition in the inspection step when the test item is executed may be realized by a computer.
[0028]
Conventionally, in order to create inspection condition files for a plurality of processes collectively, a processing program must be separately created and processed by another computer such as EWS. Therefore, a tester without an EWS cannot perform the work, and a trouble of transferring a file to the EWS occurs. In addition, as shown in FIG. 7, the operation of reading the files having the output of the inspection conditions by the number of inspection steps for each inspection step has occurred, and the man-hour has been increased twice. On the other hand, according to the inspection condition extraction program according to the present invention, the EWS is read out from the memory in the final inspection step and collectively output to a file in the final inspection step, and the inspection condition of each inspection step except the final inspection step is obtained. It is possible to collectively output inspection condition files of a plurality of inspection processes without using them.
[0029]
In the final inspection step, the inspection conditions extracted in the final inspection step are directly output to a file without passing through the memory, and the inspection conditions of each inspection step except the final inspection step are read out from the memory and the file is read out. It is also possible to output to. Thereby, the memory can be effectively used.
[0030]
Hereinafter, an example of a specific embodiment of the present invention will be described with reference to the drawings.
[0031]
FIG. 1 shows a flow of processing by the inspection condition extraction program of the present invention.
[0032]
In FIG. 1, 1, 2, and 3 denote inspection programs for the first, second, and n-th inspection steps, respectively, and 4, 5, and 6 extract inspection conditions for the first, second, and n-th inspection steps, respectively. Step 7 is a step of outputting the inspection conditions of all the inspection steps to a file. The n-th inspection step is a final inspection step. 8 is a tester. That is, steps 4 to 7 are performed by the tester 8.
[0033]
In the tester 8, the inspection programs of the first to n-th inspection steps are executed, and the inspection conditions of each inspection step are stored in a memory (not shown) on the tester. When the final inspection step (the n-th inspection step 6) is performed, the inspection conditions of each test item in this inspection step are extracted and directly output to a file without going through the memory, and the first to n-1th inspection steps are performed. Are output from the above-mentioned memory to the same file.
[0034]
Thus, the processing efficiency is improved by outputting the inspection conditions of all the inspection processes to the file at once in the final inspection process without outputting the file in each inspection process.
[0035]
Here, the structure of the inspection programs 1, 2, and 3 in the first to n-th inspection steps in the present embodiment is shown in FIG. Although FIG. 2 illustrates the inspection program 1 in the first inspection step, the inspection programs in the second to n-th inspection steps are the same. As shown in FIG. 2, the inspection program 1 includes a routine 21 for selecting an inspection condition output target hardware, a routine 22 for reading a value set in the hardware selected in the routine 21 when each test item is executed, and a routine 22. A program 20 including a routine 23 for storing the inspection conditions read out in the memory 22 in a memory, a routine 24 for summarizing the inspection conditions of all the inspection processes in the final inspection process n, and a routine 25 for outputting all the inspection conditions to a file is incorporated.
[0036]
The hardware selected as the inspection condition output target in the routine 21 is hardware that is generally used for all test items and hardware related to the inspection specification. For example, a power supply unit, an input voltage application unit, an output voltage comparison unit, a measurement frequency setting unit, a measurement determination unit, a pin to be tested, and the like are selection targets. The hardware to be selected in the routine 21 is not limited to these examples. Any hardware other than the power clamp part and the special tester hardware can be selected.
[0037]
The embedded program 20 may be described in a separate file, and the inspection program 1 may be described with an instruction (such as an INSERT instruction) for inserting the file. In this way, the embedded program 20 can be easily incorporated into the other inspection programs 2 and 3.
[0038]
The inspection program 1 after the installation is run on a tester.
[0039]
The inspection program 1 sets necessary conditions for each hardware in order to execute the first test item. When the setting of the first test item is completed, the first test item is performed. At this time, the value set in the hardware is read out by the operation of the built-in routine 22. This value is substituted into a memory variable by the routine 23.
[0040]
Because the tester's memory is limited, all test conditions cannot be saved unless the memory is used effectively. For this reason, in the present embodiment, the memory arrangement is devised as follows.
[0041]
FIG. 3 conceptually shows an example of a memory arrangement. Tests of test items having exactly the same inspection conditions are considered as one test group, and the inspection conditions are managed for each test group. Thereby, it is not necessary to hold the inspection conditions of all test items, and the memory can be effectively used. In a tester to which the EWS is not connected, the memory is generally small, so that this method can hold the inspection conditions of a large-scale circuit.
[0042]
The memory variables include a first variable having the number of tests of a test group having the same test condition, a second variable having the same test condition, that is, a second variable having a test number belonging to the same test group, and the test condition. Consists of a third variable. The third variable holding the inspection condition is assigned to hold only the inspection condition of the hardware selected in the built-in routine. This is realized by allocating hardware corresponding to the third array element of the third variable.
[0043]
This flow is shown in FIG.
[0044]
First, the inspection program 1 is executed for the first test item (step S41). At this time, the values set in the hardware are read out by the built-in routines 22 and 23, and the processing is performed as follows (step S42). First, “1” is assigned to the test group number. For the first variable holding the number of tests, the array element e1 is a test group number “1”, the array element e2 is an inspection process as an element, and the test number “1” is substituted. As for the second variable holding the test number, the array element e1 has the test group number “1”, the array element e2 has the inspection process as an element, and the test number of the first test item is substituted. As for the third variable holding the inspection condition, the array element e1 is a test group number “1”, the array element e2 is an inspection process, the array element e3 is a hardware element from which the inspection condition is extracted, and the set value of the specified hardware element Is held. Thus, the processing of the built-in routine 23 ends, and the flow returns to the normal test flow. The state of each variable at this time is as shown in S42 of FIG.
[0045]
Next, the condition of the second test item is set, and the inspection program 1 is executed for the second test item (step S43). Also at this time, the values set in the hardware are read out by the built-in routines 22 and 23, and are processed as follows.
[0046]
First, the hardware condition read in the second test item is compared with the hardware condition of the third variable stored in the first test item (step S44a).
[0047]
If all the inspection conditions match, 1 is added to the value of the first variable that holds the number of tests. In addition, the test number of the second test item is added to the second variable holding the test number. The third variable holding the inspection condition is not changed. The state of each variable in this case is shown in step S44b of FIG. This completes the processing in the built-in routine once and the flow returns to the normal test flow.
[0048]
If at least one of the hardware conditions does not match in step S44a, the first test item and the second test item are regarded as different test groups, and 1 is added to the test group number.
[0049]
As for the first variable holding the number of tests, the array element e1 is a test group number “2”, the array element e2 is an inspection process as an element, and the test number “1” is substituted. As for the second variable holding the test number, the array element e1 has the test group number “2”, the array element e2 has the inspection process as an element, and the test number of the first test item is substituted. As for the third variable holding the inspection condition, the array element e1 is a test group number “2”, the array element e2 is an inspection process, the array element e3 is a hardware element from which the inspection condition is extracted, and the set value of the specified hardware element Is held. The state of each variable at this time is shown in step S44c of FIG.
[0050]
The above-described processing is similarly executed from the third test item to the last (n-th) test item.
[0051]
When there is only one inspection step, the test numbers belonging to the test group can be enumerated by reading the second variables storing the test numbers by the value of the first variables storing the number of tests. By sequentially outputting the values of the third variables for storing the inspection conditions for the selected hardware, the test numbers and the inspection conditions can be matched. In addition, since the tests under the same inspection conditions are output together, the output file size is small. In addition, it is easy to check with the inspection specification, and errors can be reduced.
[0052]
On the other hand, when there are a plurality of inspection steps, the same processing is repeated from the first inspection step to the (n-1) th inspection step except for the final inspection step (the n-th inspection step). At this time, the state of the memory is not initialized.
[0053]
In the final inspection step (n-th inspection step), while reading out the inspection conditions, the inspection conditions of the other inspection steps are read out from variables and output simultaneously. The inspection process can be managed from the first variable to the third variable by the array element e2. Further, since the conditions of the final step do not need to be stored in the memory, the memory can be reduced. This is very effective for a tester with a small memory.
[0054]
In the inspection in a plurality of inspection steps, the test order of each test is not always the same in each inspection step. In addition, some tests are performed only in a certain inspection process.
[0055]
A method for outputting inspection conditions in such an irregular test order will be described.
[0056]
The embedded program 20 is inserted into the inspection program of the final inspection step (the n-th inspection step) and executed by the tester. The processing of the embedded program 20 in the first test item will be described with reference to FIG. In order to check whether the same test number as the first test item exists in another inspection process, a second variable storing the test number is searched.
[0057]
If it exists in the first inspection step, a search is made to see if another test item has been executed before the first test item is executed in the first inspection step. The second variable for storing the test number can be easily searched because the test number is stored in the order of execution of the test in the inspection process.
[0058]
If another test item x is being executed, the inspection condition of the test item x in the first inspection process is output.
[0059]
This is similarly performed up to the (n-1) th inspection step.
[0060]
Since the test item x is not performed in the final inspection step (n-th inspection step), the condition column of the final inspection step (n-th inspection step) is output as, for example, "-". Then, the test number and the inspection condition of the first test item are output for all inspection steps (output 51). FIG. 6A shows an example of the output 51.
[0061]
If another test item x is not implemented, the test condition of test item 1 is output (output 52). FIG. 6B shows an example of the output 52.
[0062]
If the first test item of the final inspection step n is not performed in another inspection step, the inspection condition column of the inspection step is output as, for example, "-" (output 53). FIG. 6C shows an example of the output 53.
[0063]
Next, the inspection program of the final inspection step (the n-th inspection step) performs the second test item. In order to check whether the same test number as the second test item exists in another inspection process, a second variable storing the test number is searched. If there is, a search is made to determine whether another test item has been executed before the first test item to the second test item are executed. This method is the same as that performed for the first test item.
[0064]
Hereinafter, the above-described processing is performed for all test items in the final inspection process.
[0065]
Before the end of the inspection program in the final inspection step, the inspection condition output destination file is closed.
[0066]
According to this procedure, the inspection conditions of all the test items in all the inspection processes are put together for the same inspection condition and output to one file.
[0067]
As described above, according to the present invention, an accurate inspection condition document file can be easily created. In addition, since processing can be performed on a tester without the need for EWS, the number of work steps can be reduced. Further, since the memory used can be reduced, it can be executed by a low-function tester.
[0068]
【The invention's effect】
As described above, according to the present invention, it is possible to provide an inspection condition extraction program for easily creating an easy-to-understand and accurate inspection condition document file for a semiconductor inspection program.
[Brief description of the drawings]
FIG. 1 is an explanatory diagram showing the configuration of an inspection condition extraction program according to an embodiment of the present invention; FIG. 2 is an explanatory diagram showing the structure of an inspection program and an embedded program according to an embodiment of the present invention; Variable map according to one embodiment of the present invention FIG. 4 is an explanatory diagram showing a flow of processing for storing inspection conditions in a memory in one embodiment of the present invention. FIG. 6A to FIG. 6C are explanatory diagrams showing an output example when the flow of FIG. 5 is executed. FIG. 7 shows a configuration of a conventional inspection condition extraction program. Illustrated diagram [Description of reference numerals]
DESCRIPTION OF SYMBOLS 1 Inspection program of 1st inspection process 2 Inspection program of 2nd inspection process 3 Inspection program of nth inspection process 4 Inspection condition extraction process of 1st inspection process 5 Inspection condition extraction process of 2nd inspection process 6 of nth inspection process Inspection condition extraction process 7 Inspection condition file output process of all inspection processes 8 Testers 51 to 53 Output 81 Inspection program of first inspection process 82 Inspection program of second inspection process 83 Inspection program of nth inspection process 84 Inspection program of first inspection process Inspection condition extraction step 85 Inspection condition extraction step 86 of second inspection step 86 Inspection condition extraction step 88 of nth inspection step Tester 91 Inspection condition file output step 92 of first inspection step Inspection condition file output step 93 of second inspection step 93 Inspection condition file output step 94 for n-th inspection step Inspection condition file reading step 95 for first to n-th inspection steps 95査 condition file output step 96 EWS
20 Embedded programs
