2016年8月19日金曜日

機能試験(ファンクションテスト)〜テストの実際3

今回は、機能試験、ファンクションテストについて書きます。かなりの長文になると予想されますが、分割するのもいやなので、お許しくださいませ。

ファンクションテストは、LSIの論理設計時に論理シミュレーションに使用したテストベクタを、本物のLSIで実行させる試験です。このテストによって、設計通りの動作をするかどうかの確認ができます。そう言えば、テストベクタを実行させることを、慣用的に「パターンを流す」、なんて言ったりします。以下、テストベクタのことをパターンもしくはテストパターンと記載します。

ファンクションテストは、論理設計時に実施した論理シミュレーションの環境を、タイミングも含めてテスターに持って行くのですが、なかなか簡単に動かないことも多い、難易度のそこそこ高いテストです。しかもLSIの回路規模が増えて行くに従って、テストベクタの量も格段増えて、難易度と量から作業量も増えていき、私の場合はテスターで徹夜する一番の原因はこれだったと思います。ものによっては1000本を超えるパターンがありましたからね。

以下、色々と書いていきたいと思います。

ファンクションテストの意味・目的


ファンクションテストの意味、目的は以下のようなものです。

機能検証

ファンクションテストは、冒頭で書いたように、LSIが論理設計時に実施した論理シミュレーションによる論理検証と同じ動作をするかどうか検証するものです。LSIテスターでパターンを走らせて期待値不一致が起こらなければ、論理シミュレーションと同じ動作をしている、ということが言えます。
なお、この機能検証は、あくまでも設計時の論理シミュレーションと同じ動作をするかどうかの確認であって、出来上がったデバイスが全ての要求仕様を満足して作られているかどうかを判定するものではありません。それを判定するには、実装評価基板を作って、実動作に近い環境での動作確認を積み上げていかなければなりません。ASIC分野では、この実装機試験はお客様の担当となります。半導体ベンダーがお客様の実動作を想定した検証環境を構築することはできません。

電気的特性の確認

このテストを使って、動作を保証する電源電圧範囲、温度範囲で問題なく動作するかどうか、動作スピードや入出力タイミングに余裕がどの程度あるのかをLSIテスターで評価して、製品として製造するに値する特性を持っているかどうか確認します。 
私がいた会社では、この特性確認を特性認定試験と呼んでいて、設計部長決裁で試験の合格・不合格を認定していました。実際問題として、すでに素性のわかった部品を使って、事前にシミュレーションも充分に行って試作するわけですから、この特性認定試験が不合格となることは通常ありません。 
なお、電気的特性の確認をしていく中で、テストの安定のために入力タイミングや出力のサンプリングタイミングを変更したり、場合によってはパターンの出力期待値をマスク(Don't careにする)したりすることがあります。 
ASICの世界では、テストパターンはお客様の設計資産なので、これらの変更は論理シミュレーション環境にフィードバックをかけて、再シミュレーションを行って問題ないことを確認したうえで、お客様に承認をいただくことになります。

出荷時の不良品選別

このテストを使って、量産品の出荷時に製品が不良品ではないかどうか、つまり正しく作られているかどうかの検査をします。このテストがNGであれば、製造時に上手く作ることが出来ずにどこかに破壊が起こっていると判定します。
ちなみに、ASICの世界では、製品仕様はあくまでもお客様サイドのもの、ということになるので、このパターンを適用して動作OKだったものを良品として納入します、という取り決めの文書をお客様と取り交わします。もちろん半導体ベンダーが提供するライブラリーにテスト抜けがある場合は、責任を持って対処します。

このような目的のために、設計時に作成した全てのパターンを用いて、ファンクションテストを実施します。ただし、LSIテスターのパターンメモリーの容量や、テストタイムの長さによっては、一部のパターンを省略する場合もあります。

テストパターンの種類、目的について


テストパターンは、種類、目的が様々あり、色々な分類をすることができます。製品仕様の詳細を知らされないテスト担当者に対しては、どのパターンも同じに見えますが、パターンそれぞれの目的が明らかになっている方がテスターデバッグの進め方が楽になる場合があります。

テスター担当者はパターンの適用結果がNGだった場合には、期待値不一致の起こり方のログを論理設計担当者に渡してパターンの修正なりタイミングの修正なりをしてもらうのですが、パターンの目的等があらかじめわかっていると、論理設計者まで話を上げなくても、テスターの現場で不具合原因を突き止められる場合もあるのです。

結合テスト

製品の通常動作モード、つまりお客様のシステムの上で通常動作するときの動作モードでのパターンです。全体を結合して動作させるパターンなので、結合テストと呼んでいました。なお、LSIの入力ピン、双方向ピンの入力レベル、VIH/VILをこれらのパターンの一部を使って測定します。

単体テスト

LSI内部のブロックを単体でLSI端子からアクセスできる動作モードをテストモードとして設けて置いて、内部ブロック単体のテストを行うものです。マイコン搭載製品ではこのような仕掛けをしておくことがあります。どのブロックをテストしているパターンか、ということがわかっていれば、ピンがどう動くはず、という当たりを付けることもできるわけです。


診断テスト

スキャンテストのテストパターンです。EDAを使ってLSI全体もしくは一部のネットリストにスキャン回路を挿入し、EDAが生成した故障検出のためのテストベクタを適用するものです。
回路の故障検出は、
  • 内部の素子の出力を0/1と変化させること
  • 内部の素子の出力の変化をLSIピンまで伝達させること
という2つのことをしなければなりません。しかし、論理の深いところにある素子を動かすためには、膨大なテストパターンを作成しなければならない場合が多く、膨大な工数を必要とします。 
そこで、故障検出を容易にするために考えられたのがスキャンテストです。
スキャンテストでは、論理の深いところにある素子の状態を外から簡単に設定、観測するために、 
  1. 通常動作とは異なるスキャンテストモードで、SCAN IN端子からスキャンチェーン内のFFにデータをシフトイン(スキャンイン)
  2. 通常動作モードに設定して、FFとFFの間にある組み合わせ論理を動作させ、その結果をFFに格納(キャプチャ)
  3. スキャンテストモードで、SCAN OUT端子からスキャンチェーン内のFFのデータを順番に出力(スキャンアウト)
ということをしています。
このスキャンテストのような仕掛けをDFT(Design for Testability)と呼ぶこともあります。(上記図を作成するにあたって、日経テクノロジー onlineの「改訂版EDA用語事典」を参考とさせて頂きました。)
クロック生成回路としてPLLを搭載している製品の場合は、結合テスト、及び単体テストにPLLが動作するパターンとPLLが動作しないパターンがあり、PLLが動作するパターンは取り扱いが特殊なので注意が必要です(後述)


パターンデバッグの進め方


私が新人の頃のテスター環境は、テストパターンは論理シミュレーションからそのまま持って行くにしても、論理シミュレーションのタイミング精度が非常に低くて、極端に言えば遅延情報のない世界でした。したがってタイミング情報は精度が低くて、安定してパターンがPassするところを探すのがパターンデバッグだったと先輩方から聞いたものでした。

しかし、EDAが進歩した現在は、実際のレイアウトから抽出した配線抵抗、負荷容量を元に計算された遅延情報をつけたネットリストを使って論理シミュレーションを実施して、期待値が一致したシミュレーション環境をそのままテスターに持ち込むわけで、テスターに持って行ったパターンはそのまま全部Passしちゃい・・・そうなものですが、なぜかそんなに上手くはいかない場合が多いです。

論理シミュレーション環境では、入出力タイミングの余裕、つまりタイミングマージンが全くなくても期待値不一致は起こしませんが、LSIテスターではそのようなマージンのない状態ではデバイスの個体差によっては動かない、ということが当たり前に起こります。さらに、LSIテスターではデバイスのピンに対して、少なくとも数十pfの負荷容量が付いてしまうので、これも出力タイミングの誤差を引き起こす原因になります。

こういったことを頭に入れて、まずは全入力、双方向ピンの入力レベルをフルスイング(VIH=VDD-0.1V、VIL=0.1V程度)、出力判定レベルをHレベルもLレベルも1/2VDDにしてパターンを流してみます。


期待値不一致を起こした場合・・・


期待値不一致を起こすパターンがあった場合は、フェイルリスト(期待値不一致を起こしているステップごとに、パターンが何を期待していて、それに対してデバイスの出力がどうだったかを出力してくれるデータログ)を見て、どのような様子かを見ます。

ここで、明らかに誤動作しているものと、信号の変化点だけが期待値不一致を起こしているものとに切り分けます。明らかに誤動作しているものは、入力タイミングが良くないのか、パターンそのものがおかしいのかの区別をする必要があるので、後回しにします。

変化点で期待値不一致が出ているとき


変化点だけが期待値不一致を起こしているものは、出力値をサンプリングしているタイミング(以後ストローブタイミング)を動かしてみて、Passするか様子を見たり、デバイスの出力をオシロスコープで観測して、信号が変化しているタイミングを波形で観測してみます。

クロック同期設計で設計されているLSIは、信号の変化タイミングはいつも基準タイミングから同じ場所にあるはずなので、変化点で期待値不一致を起こしている場合は、パスするストローブタイミングが必ずあります。

たまに、立ち上がりと立ち下がりのタイミングが異なるような回路仕様がありますが、その場合はストローブタイミングを合わせ込むことが不可能な場合が多いので、変化点ステップの期待値マスクを検討したほうが良いと思います。

なお、これはパターンを作る人が考慮すべきことですが、双方向ピンの入出力切り替えが行われるステップは、色んな理由からマスクするのが普通です。出力専用ピンの変化点ステップも、可能ならマスクしたほうがテストが安定します。(ACタイミングを測定する場合を除く)

どうやら完全に誤動作してるな、というとき


変化点の期待値不一致ではなく、完全に誤動作しているように見える場合は、入力タイミングがおかしくて入力データが正しく入力出来ていないことが原因である場合が多いので、入力タイミングを動かしてみます。

テスターにはLSIピンを1本ずつ、入力タイミングやストローブタイミングを前後に振って動作マージンを見る機能があるので、これを使ってみます。また、バス構成のピンは1本ずつ振っても意味が無いので、まとめて同時に振ってみます。これでPassし始めたり変化点ステップの期待値不一致に状態が変わったらしめたもの。

なお、入力タイミングはテスト周期の先頭より前には動かせないのが普通なので、入力タイミングの定義がテスト周期の先頭になっている(信号変化タイミングが0ns)場合は、他のピンのタイミングを一旦全て後ろに下げてから該当ピンのタイミングを振ります。信号の入力タイミングは、他のピンのタイミングとの相対関係が重要なので、このような操作をして相対的に前に出すような操作となります。

こういう面倒な操作をしなくても済むように、論理シミュレーションの段階から、入力の信号変化タイミングはある程度後ろに下げて定義をしておくのが良いと思います。0nsはよろしくありませんね。

いよいよこれでダメなときは、期待値不一致を起こしているデータログを論理設計担当者に渡して、解析を依頼します。

パターンがPassし始めたら、これをやります


Passしたパターンから順に、入力タイミングのマージンとストローブタイミングのマージンの電源電圧依存性のデータをSHMOOプロットなどで取得して、マージンが極端に少ないタイミングがあるばあいは、修正の検討を論理設計担当者に打診します。SHMOOプロットって何?と言う方はこちらをご覧下さい。(外部ページを参照します)

この作業をしっかりやっておかないと、後日大量のESサンプルを選別したり、プローブテストを実施するなど、後々の作業でテストが安定せず、大変な目に遭います。手抜きをせずにしっかりやりましょう。

入力レベル測定用パターンの選定


入力専用ピン、双方向ピンの入力レベル(VIH/VIL)はファンクションテストで測定します。出力レベルの測定のようにDC測定ができればよいのですが、ファンクションテストのパターンがPassするかしないかで判定する以外に方法がありません。

なお、製品がバウンダリスキャン回路を搭載している場合は、バウンダリスキャン回路をテストするパターンを使います。バウンダリスキャン回路を搭載している製品ではI/Oバッファのすぐ内側にバウンダリスキャンテスト用のレジスタとしてFFを持っており、これを使うとLSI内部から発生する電源ノイズの影響をうけないテストができます。

実際のテストでは、特性評価時にSHMOOプロットで実力を測定して、出荷選別時には定めた入力レベルスペックを設定したファンクションテスト、という形での試験になります。

PLLのある製品では・・・


PLL(Phase Locked Loop)が搭載されている製品の中で、PLLを使って内部クロックを生成しているマイコン系の製品では、テストに関して心にとめて置いた方が良いことがあります。

100MHzを超えるようなクロックで動作するマイコン製品では、それよりも低速なクロックを外部から入力して、クロック生成回路内にあるPLLを使って逓倍するのが一般的です。

たとえば、30MHzのクロック入力から内部で120MHzを作る、といった具合です。そして、LSIの内部回路全てが、その高速なクロックで動作しているわけではなく、クロック生成回路内で高速なクロックを分周して生成した低速クロックで動く回路もあります。

なお、現在はもっと高速なデバイスもあると思いますが、基本的には同じ考え方でクロックを生成していると思います。
参考文献:「新人エンジニアの赤面ブログ」

このクロック生成回路の中には、クロック逓倍のための分周器、クロック分周のための分周器など、分周器がたくさん入っています。分周器の中身はカウンターですが、このカウンターは通常動作時には特にリセットしなくても勝手に安定して動作してくれます。

ところが、テストの世界では、クロックのパルス数まで正確に管理するので、勝手に安定してくれる、という世界では、パターンをPassさせることはできません。

図の上の3本が本来期待する波形ですが、分周器を適切にリセットしないと、逓倍クロックの立ち上がりが、図のようにどこに来るか確定させられません。

さらに、逓倍クロックを分周して作るクロックも、周波数は分周比によって決まる周波数になるものの、立ち上がりがどこに来るか確定させることができません。

この状態でファンクションテストを行っても、Passさせるのは無理です。

したがって、テストでは、テストパターンの冒頭で、クロックの位相関係をテスターと同期させるシーケンスが必ず入っていると思います。私が経験した例では、2種類あるリセットピンの入力の組み合わせで、クロック生成回路内の分周器にリセットをかける仕組みが組み込まれていました。

おそらくこの辺の作り込みがヌケることはないとは思いますが、マイコン製品のASIC化、SOC化でこの仕掛け作りが設計から抜けたら、テストができない製品となってしまいます。

ところで、この逓倍クロックというのは結構なくせ者です。テストパターンを作るとき、通常は入力クロックの1周期をテスト周期としてパターンを作成するのが普通ですが、これだと、内部の逓倍クロックの数周期に1回しか出力結果を評価しないことになってしまいます。図の例は4逓倍ですが、逓倍クロック4クロックに1回しか出力結果の評価が行われません。

これはある意味テスト抜けで、本来は逓倍クロック1クロックに1回評価が行われなければなりません。したがって、厳密にテストをしようとすると、図の例だとストローブタイミングを変えて4回テストパターンを走らせる、ということが必要です。

このことを私に教えてくださったK.N.さん、私が退社したあと、亡くなったのだそうです。非常に優秀かつ人当たりの良い方で、私の最後の上司でした。教えてくださって、本当にありがとうございました。

クロックサーチについて


マイコン系の製品では、外部ピンのタイミングの基準点がクロック出力の立ち上がりエッジに定められている製品が多いと思います。マイコンを使うときには、外部回路をマイコンのクロック出力に同期させて作るので、当然クロック出力が基準になるわけですが、テストをする側からすると、デバイスの出力が基準点になっているというのは、テスターが基準ではない、という点で非常に扱いが面倒です。

これに対しては、全てのテストの前に、クロック出力がテスト周期の先頭と一致するように、テスターからのクロック入力とデバイスからのクロック出力の位相差を測定する、ということをします。

ファンクションテストの際には、その位相差をオフセットとしてクロック入力タイミングに加算して、クロック出力の立ち上がりエッジがテスト周期の先頭と一致するようにします。

診断パターンについて


診断パターン、つまりスキャンテストのパターン類についてですが、これも特に他のパターンと区別なく適用します。しかし注意しなければいけないのは、通常動作とはかけ離れた動作をすることによって、LSI内部で実動作とはかけ離れた数の同時変化(内部の素子が同時に1から0、0から1と変化することです)が起こるので、電源に大きなノイズが乗る可能性があるということです。

スキャンテストのことまで考慮して電源ペアの数を決めるのは不経済なので、おそらくスキャンテストのときには電源が足りない状態になっていると思います。

これがテストにどのような影響を与えるかというと、電源電圧マージンの悪化です。

他のファンクションテストパターンと同等の電源電圧マージンの実力があれば問題ありませんが、もし電源電圧マージン不足がスキャンテストだけで発生している場合は、スキャンテストパターンの内部活性化率を下げて同時変化数を減らすしか方法がありませんので、開発チーム全体で相談の上で対処方法を決定、ということにすべきです。

本来電源電圧範囲の保証は通常動作時のテストパターンで行われるべきなので、スキャンテストのような実動作とかけ離れたテストパターンを、電源電圧保証の範囲に含める必要があるのか?という考え方もあると思います。

以上駆け足でファンクションテストについて書いて来ました。ファンクションテストはテストの中では花形だと私は思っています。

デバッグに何日も、ヘタすると何週間もかかるのに、デバッグが終わったらほんの数秒でパターンが全部流れてしまうという世界ですが、数秒でパターンが流れ終わって、テスターのPassランプが点灯するのを見るのは、してやったり!感をたっぷり感じることができます。

0 件のコメント:

コメントを投稿