2017年2月19日日曜日

時短ってなんですか? 〜テストタイムのおはなし

テストの話が続きます。なにせ現役時代一番長くやってた仕事なので、それだけお話ししたいネタも多いのです。

時短とは?


時短ってなんですか?ということですが、ここではLSIテストに於ける時短についてのお話を書きます。LSIテストに於ける時短とは、LSIのテストにかかる時間、テストタイムを短くする活動、ということです。

このテストタイム、どれだけ短く出来るかが、テスト業務をやっている人にとってはかなり重い課題です。


なぜ時短が必要?


なぜ時短が必要なのかを知るためには、テストタイムがどういうところに影響するかを知る必要があります。以下に書きます。

テストタイムは、製品のコストに影響します。

単位時間当たりいくら X テストタイム

というテスト費用が工程単価の一部として原価に計上されるので、短い方が総原価が下がって、収益に対してプラスに作用する、ということになります。

昔は、LSIの単価100円あたりテストタイム1秒、という目安が担当者の間で言われていて、たとえば600円で売るLSIのテストは6秒以内にしないとダメ、と言われていたものです。あくまでも目安ですよ。

また、テストタイムは工場の生産能力に大きく影響します。たとえば、チップが500個取れるウエハのウエハテストを考えると、テストタイムが1個あたり6秒で平均歩留まりが80パーセントだったとすると、ウエハ1枚あたり40分ぐらいでしょうか。1日じゅうテストを流し続けると36枚のウエハをテストできます。

これに対して、テストタイムを0.5秒縮めると、およそ39.2枚の処理能力となります。3.2枚の差です。これをテスター10台で考えると、1日当たり32枚処理能力が増える計算になります。月あたりでみると、テスター1台につき96枚、テスター10台につき960枚の処理能力増です。

テスター1台に付き96枚ということは、組み立てたあとの製品38400個の生産能力ということになります。大きい数字ですね。テストタイム短縮は、これほど大事なのです。

なお、上記では、考えやすくするためにウエハから取れるチップの数に歩留まりを掛けたものでテストタイムの計算をしています。実際には不良品も途中まではテストが流れますし、チップの切り替え時間もありますので、単純に取得数500の80パーセントに対してのテストタイムの総和よりは長くなります。

今回の投稿では、私が実務をやっていた頃に見たり聞いたり、自分の製品に取り入れたりしていたテストタイム短縮のノウハウについて、書いてみようと思います。

しかし、テストタイムを短くすると言っても、10秒かかっていたものが5秒になったりするようなことはないわけで、テスト担当者は1秒、0.5秒削るために頑張っているんです。

テストタイムの内訳

LSIテストにかかる時間は、以下のように分類出来ると思います。

  • テストパターンが走っている時間
  • DC測定をしている時間(デバイスの状態安定のための待ち時間含む)
  • プログラムの処理時間

以下に、少し詳しく説明を書きます。

テストパターンが走っている時間


テストパターンが走っている時間は、文字通りテストパターンが走るのに必要な時間です。これはテスト周期とパターンのボリュームで決まる時間です。また、一番最初にテストが走るときには、テスターのハードディスクからパターンメモリーへのテストパターンの転送時間も加わります。

LSIテスターでは、テストパターンは実時間で流れていくので、無駄に時間がかかることはありません。たとえば、30MHzで動く100万ステップのテストパターンがあったとすると、そのパターンが実際に流れている時間は、30MHzの周波数の1周期は33.3nsですから、その100万倍で0.0333秒です。つまり33.3msです。パターンが流れている時間自体はこれほど短いものです。元々短いパターン走行時間ですので、切り詰めてもあまり効果はありません。

一つ気をつけなければいけないことがあります。LSIテスターのアーキテクチャにもよりますが、テストパターンの量がパターンメモリーがあふれてしまうほど大きい場合は、パターンが流れるたびにハードディスクからパターンメモリーへの転送が発生するので、極端にテストタイムが長くなってしまいます。

スキャンパターンを何も考えずに全てテスターに適用すると、パターンメモリーがあふれてしまい、こういう現象が簡単に起こってしまうことがあるので、テスターに持っていくテストパターンを決める際には、パターンメモリーの容量を気にしなければいけません。

DC測定をしている時間


DC測定は、各端子の出力電圧やプルアップ/ダウン電流、入力端子のリーク電流などを測定するものです。測定するときには、デバイスに電源を入れてから、デバイスの状態設定を行うためのテストパターンを走らせた後に、パターンを止めて、数10ms程度の待ち時間の後、静止状態で測定します。測定系が安定するにはそれなりに時間がかかるので、待ち時間を設けないと測定結果が安定しないことがあります。

これらのテスト、デバイスが安定してから測定することになるので、測定回数が多ければ多いほど時間がかかります。このテストの時間を短縮するためによくやるのは、同時に測定するピン数をなるべく多く取ることです。

しかし、入力、双方向、トライステート出力のリーク電流を測定する場合には、同時測定ピン数を、テスターのDC接続ユニットが接続できる最大のピン数まで増やせば良いのですが、出力電圧の測定はむやみやたらにピン数を増やすことが出来ません。

なぜなら、私が担当していたASIC系の製品においては、出力電圧は、ある出力電流を流したときの電圧としてスペックが規定されていたため、出力電圧の測定は、規定の出力電流を流したときの出力電圧を測定しなければならなかったからです。(右図)

たとえばLレベルの出力電流が8mAのバッファの出力電圧を測定しようとすると、1ピンあたり8mAの電流、100本で800mA、つまり0.8Aの端子電流を流す必要があります。200本だと1.6Aですね。Lレベルだと、これだけの電流をテスターからLSI端子に対して流し込んでやる必要があります。

テスターのマニュアルが手元にないので、テスターとしてDC測定の際にどの程度の電流を流せるか、正確な数字はわかりません。しかし、そのような大電流をテスターが供給できたとしても、測定するデバイスのGNDに大電流が流れ込むことになり、チップ内の電源抵抗によってGNDレベルが上がってしまいそうな気はいたします。

なお、プルアップ/プルダウン電流については、同じように端子に対して電流を流し込んだり、端子から電流を引き抜いたりすることになりますが、電流値のオーダーが1桁以上違うので、問題にはならないかもしれません。(右はプルアップ電流の測定系です)

いずれにしても、同時測定本数を増やすことは、時短には効果があるので、テストが不安定にならない範囲で実施します。

プログラムの処理時間


テストプログラム自体も、当然ながら処理時間がかかります。たとえば、無駄な計算をさせたりすると、その分無駄に時間がかかります。

Cコンパイラなどは、冗長なコードがあると、冗長な部分をきれいさっぱり消し去ってくれたりするような、強力な最適化をしてくれますが、テスターのコンパイラはそんなに強力ではありません。(右図はCコンパイラにおける最適化の例です)

というわけで、テストプログラム自体で効果がありそうな時短ネタは、大きく二つ、

  • サブルーチンコールを使わない
  • ステートメントを減らす

ということがありました。

サブルーチンを使わない


サブルーチンは、プログラムを構造化してわかりやすくしてくれるものですが、実はオーバーヘッドが大きいようです。機械語レベルで考えると、必要なレジスターの値をスタックに積んでジャンプ先に飛び、戻ってきたらスタックに積んだデータをレジスタに復元・・・という動作になると思います。このジャンプすること、そしてデータの退避と復元、リターン動作がサブルーチンコールのたびに行われるので、結構なオーバーヘッドです。

かといって、サブルーチンを使わないでプログラムを書こうとすると、保守性が極端に下がるわけで、サブルーチンコールのかわりになるものとしてテスターメーカーが用意していたのがマクロです。

マクロとサブルーチン、書式はほとんど同じでしたが、マクロはマクロ定義したコードがコンパイル時にマクロを書いた場所にそのまま展開されます。ということは、ジャンプ、データの待避と復元、リターン動作がありません。この差も数が多ければ馬鹿になりません。

ステートメントを減らす


何のことだかわかりにくいですが、プログラムに書く命令の数を減らすっていうことです。具体的にどういうことかというと、複数のパターンを連結して本数を減らして、パターンを流す命令の数を減らします。


テストパターンには、タイミング定義の識別情報が埋め込まれています。(右の書くステップにある/T1や/T2、/T3という記述がその識別情報です)

また、テストプログラムには、一つの波形定義に対して複数のタイミング情報を定義することができます。パターンが流れるときには、パターンに埋め込まれた識別情報で、複数定義されているタイミング情報の中から、ステップごとに実際に使うタイミング定義が選択されるようになっています。アドバンテストのテスターでは、タイミングセットと呼んでいました。

この機能を使うと、波形定義が同じであれば、多少タイミング定義が違っていても、パターンを連結して1本にまとめてしまうことができます。この機能を使って、パターンの総ステップ数は変えずに、パターンの本数を減らして、パターンを流す命令の数を減らすのです。

上にあげた例は、私が実務担当者時代に使っていたアドバンテスト社のシェアードリソーステスターであるT3340シリーズの例です。このテスター、かなり古いので、すでに稼働しているものはほとんどないと思います。しかしながら、テスト技術自体はそれ程変わるものではないので、他社製のパーピンテスターなどにも同様の機能があるものと思います。

なお、前出の同時測定ピン数を増やしてDC測定をする命令を減らすことも、測定の回数が減る時短効果以外に、命令を減らす効果がありますね。

さらなる手はあるのか?


今までは、測定方法を変えずに時短をどうやってやってきたか、という話でした。しかし、これには限度があるんです。測らなければいけない項目は決まっていて、測るのにかかる時間も決まってしまって、プログラミングの工夫でプログラム実行時間も削って、それ以上に時短をしようとしたら、測定項目を減らすか、測定方法自体を変えることを考えます。

私が過去に担当した製品で実際に行った時短の方法としては、テストの不良率を調べて、不良率の著しく低いテストを抜く、というものがありました。

量産工程で、数1000個分の製品の、テストパターンごとの不良数のデータを取ってもらい、不良数が著しく低いテストパターンはテストから抜く方針で進めました。実際にデータを調べてみると、私が担当したその製品では、数1000個分のテストで、不良数が0や一桁といった、不良数の極端に少ないパターンは実際にあり、それをテストから抜きました。

不良発生の少ないテストパターンがあることを不思議に思われるかも知れませんが、開発時には、故障検出ノードが重複していないかどうかなど、あまり意識せずにテストパターンを作ると思うので、テストの前の方で流れるパターンで故障検出がされてしまえば、後ろの方で流れるパターンに不良が発生しないということはあり得ます。

逆に言うと、故障検出率の高いテストパターンをテストの最初の方に持ってくると、不良を早く落とすことが出来るので、無駄なテストをせずに済みます。ですから、特にスキャンパターンは一番最初に流すようにします。

出力電圧テストの時短


出力電圧の測定は、測定条件の設定がしにくく、同時測定数をあまり増やすことが出来ないと書きました。そうなると、同じ測り方ではどうにもならないので、何か違ったことをしなければなりません。手としては、

  • ウエハテストと組立後の選別のどちらかでテストすれば良いことにする。
  • DCテスト以外の速いテスト方法があればそれを実施

と言うのがあるでしょうか。

どちらかでテストすれば良いことにする、というのは、通常ウエハテストと組立後選別で同じテストを実施している場合、これを片方だけにする、ということです。私の担当製品ではやったことがありませんが、そのようなことを検討している話を聞いたことはあります。たとえば、全ピン数の半分をウエハテストで、半分を組立後の選別でテストするとか、組立後選別で実施しないとか、色々ととやり方はあると思います。

しかしこの方法、テスト条件1点だけで、温度特性を含めた社外保証スペックを満足していることを保証できるテストでなければなりません。

特性データはどうやって使う?」の項で書いたように、通常は高温で実施するウエハテスト、常温で実施する組立後選別の二つのテストを使って、温度特性の確認を行っていますが、それをテスト条件1点だけで実施する、ということになります。(右図参照)

経験上、出力電圧の温度傾きはそれほど大きくなかったとは記憶していますが、この温度傾きを充分考慮してテストスペックを決めなければなりません。

DCテスト以外の早いテスト方法があればそれを実施、ということについては、出力レベルをDC測定ではなくファンクションテストで測定する、という考え方があります。

通常は、デバイスの状態設定のために測定ステップまでパターンを走らせて、パターンを止めてDC測定ユニットを使って電圧測定、という手順ですが、これを、測定ポイントまでパターンを走らせて、期待値比較で測定する、という手順です。

実際、製品によってはファンクションテストで測定している場合もありますが、スペック規定の測定条件に注意しなければなりません。

私が担当していたASIC系の製品では、一定の出力電流を流したときの出力電圧がスペックでしたが、スペック規定の条件の出力電流値は、あくまでも静止状態で測定するときの条件なので、その条件を適用してパターンを動作させると、出力負荷が重くなりすぎ、出力端子のスイッチングによる大きな電源ノイズがデバイスの電源やGNDに乗ることとなります。このノイズが測定の邪魔をするのです。

この電源ノイズの影響を避けて、ファンクションテストによる測定を上手く行うためには


  • ノイズを小さくするために負荷をかけるピン数を少なくする
  • ノイズの影響を避けるため、ノイズがおさまったタイミングにストローブタイミングを設定する


といったことに注意して、テスト手順を組み立てて行く必要があります。

プログラムの書き方、テストの組立方をやり尽くしたあと、さらなる時短をしたい、と言う場合には、テスターのさらにハードウエア寄りのところで出来ることがないか、という相談をテスターメーカーにするのも手です。テスターのアーキテクチャを一番よく知っているのは、当たり前ながらテスターメーカーですので、彼らの叡智を利用しない手はありません。

実際、現役時代に、プログラムのコンパイルと実行方法を変えて、テストタイムがかなり早くなった例があったと記憶しています。

以上、いかがでしたでしょうか?

製品の半導体製品は単価が高くないので、1円以下のところで製造原価の検討を行って、原価低減を行っていますし、テストタイム短縮で生産能力が増えれば、生産設備への投資が不要になる、もしくは少なくて済む、ということになります。

こういった、事業の収益に関わるところに、テストタイム短縮の話は大きく関わっているのです。

0 件のコメント:

コメントを投稿

注: コメントを投稿できるのは、このブログのメンバーだけです。