特性データはどうやって使う？〜テストの実際の最後

今まで何度かにわたってテストの実際をご紹介してきました。

テストの実際を始めるにあたって、テストとは製品出荷のための良品・不良品の判定と、その判定を行うための判定スペックの決定、及びそれに付帯する業務のことであると説明しました。

この判定スペックの決定にあたっては、実際に製品の特性データを測定して、そのデータを吟味し、社外に不良品を出さず、かつ本来良品とすべき製品を不良品と誤判定しないようなスペックを決定しなければならず、時としてスペック決定が難しい状況となります。どんな製品でも最低1項目や2項目はスペックの決定に悩むような項目があるものです。

今回はテストの実際の締めくくりとして、このデータの評価からスペックを決めるというところのお話を書きたいと思います。

発振器とかメモリーとか〜テストの実際5

DCテスト、ファンクションテスト、ACテストと、実際にテストってどうやってやっているのかをご紹介してきました。

回路には回路ごとにその回路のためのテスト方法があるので、とても全てを網羅することはできませんし、私もASIC/SOCという限られた製品分野での経験しかありませんので、私の経験からご紹介できるテストの話しも残り少なくなりました。

今回は、水晶発振器のテスト、そしてASIC/SOCのみならず、マイコン製品にも必ず搭載されているメモリーのテストをご紹介します。

ACテストって何でしょう？ 〜 テストの実際4

今回は、ファンクションテストの回でも少し出て来た、ACテストについて少し詳しく書いてみたいと思います。

ここで言うACテストは、ACタイミングを測定するテストのことを指しますが、「テストの実際」を始めたころに出て来たDCテスト、そして今回のACテスト、なぜDCとかACと言うのでしょう？

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

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

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

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

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

補足・プルアップ/プルダウン電流のはなし

第8回の「テストの実際（その２・電気的特性）」でプルアップ/プルダウン電流の測定について書きましたが、プルアップ/プルダウン電流ってそもそも何？っていうことを補足しておこうと思います。

結論を先に書くと、フローティング防止のためにI/Oバッファに内蔵されたプルアップ/プルダウン抵抗に流れる電流をプルアップ/プルダウン電流と言います、ということになるのですが、それだと訳がわからないので、以下に詳細を示します。

入力オープンの場合

CMOSはComplementary MOS（相補的なMOS）という意味で、PチャンネルMOS（P-MOS）とNチャンネルMOS（N-MOS）を回路内で同時に使い、P-MOSがオンのときはN-MOSがオフ、N-MOSがオンのときはP-MOSがオフという動作をするように作られています。

この回路の構造から、回路の状態が定まると電源とGNDの間にほとんど電流が流れないので、消費電流が少ない、という性質があります。初期のCMOSデバイスが電卓に好んで使われたのは、これが理由です。

しかしながら、回路の状態が定まっていない状態では、P-MOSとN-MOSの両方が同時にオンしてしまって、電源・GND間に大きな電流がながれてしまうことがあります。これを貫通電流と呼んでします。

この状態を作り出す一番大きな原因が、入力が不定であること、もっと簡単に書くと入力端子に何もつながっていない入力開放、つまり入力オープンによるフローティングです。入力が浮いている、と言ったりします。

プルアップ抵抗付き入力の場合

この状態は、大電流が流れてデバイスが壊れることもあり得る危険な状態なので、CMOS LSIでは、貫通電流が発生しないように、入力端子はかならず電位が固定されるような使い方をしなければなりません。

しかし、オープンとなる可能性があるような場合に対応するために、オープンにしても内部でHレベル固定がなされるようなプルアップ抵抗付きバッファ、内部でLレベル固定されるようなプルダウン抵抗付きバッファというものがあります。

このようなバッファが使われたピンに対して、内部で電位固定されている方向の反対側のレベル（プルアップに対してLレベル、プルダウンに対してHレベル）を印加すると、内部の抵抗を電流が流れます。これがプルアップ/プルダウン電流です。

プルアップ電流はデバイスの電源からピンに向かって、プルダウン電流はピンからデバイスのGNDに向かって流れるので、システム電源の都合やつなぐ相手の都合を考える上で、重要なファクターですね。

一方、プリント基板の設計では、基板パターンを色々な理由から電源電圧の1/2の電圧レベルに終端したり、プルアップ抵抗を使って電源電圧レベルにプルアップすることがあります。

基板のプルアップ/プルダウンが、LSI端子のプルアップ/プルダウンと逆の方向になるような使い方をすると、基板上のプルアップ/プルダウン抵抗と、LSI内部のプルアップ/プルダウン抵抗の抵抗分圧で決まる電位が、LSIに印加されることになるので、貫通電流が流れる原因となります。これにも気をつけなければいけません。

第8回〜テストの実際（その2、電気的特性編）

今回は、前回お知らせしたテスト内容の詳細についての1回目、DCパラメトリックテスト（以下DCテストとします）という分類のテストについて、詳細を書きます。

DCテスト、このテストで測定される項目は、LSIの電気的特性の基本となるもので、外の部品とのインタフェースが取れるかどうかにかかわるものです。

今回はDCテストとして以下のテストについて詳細を書きます。

• オープン/ショートテスト
• 出力電圧（VOH/VOL）テスト
• 入力/双方向/トライステートリークテスト
• プルアップ/プルダウン電流テスト

それでは以下、話を進めていきます。

第7回〜テストの実際（その1、導入編）

半導体は、写真製版技術を使って、シリコンウエハ上に全く同じチップを数百個から千個分、繰り返し回路を焼き付けて作ります。そして、製造途中での良否は外観検査でしか判定できず、良品か不良品化の判定は、全ての工程が終わって、実際に回路を動かしてみないとできません。

この判定をすることをテストと読んでいます。「テスト」という単語はとても一般的な単語ですが、半導体設計製造の世界で「テスト」というと、主としてこのことを指します。

良品･不良品の判定をするということは、ここで不良を見逃すと、お客様のところに不良品が出荷されてしまうということから、とてもシビアな業務であると言えます。

判定のスペックを決めるための色々な業務として以下のようなものがあります。

• 試作品評価による動作検証
• 各種特性取得（DC特性、AC特性）
• 取得したデータの処理とデータの吟味
• 特性が設計目標値を満足しているかどうかの認定
• 判定スペック決定
• スペックを入れ込んだ量産テストプログラムの作成
• お客様への製品納入時の選別条件のお約束をする納入仕様書作成
• 量産工程への公式な製造仕様ドキュメントとして設計部が発行する製造図面の作成

これら、帳票類の整備などの様々な業務も含めた業務をテスティング業務と考えて、これらの業務全般がテスト担当者のミッションとなります。

さらに、大規模なLSIのテストを効率的に実施するための、様々な仕掛けを製品の中に入れ込んでおくテスト容易化設計のための様々なアドバイスを製品設計者に対して行うこともあります。

このテスト容易化設計は、大規模な製品を少ない時間で効率的にテストをするために必須の考え方で、この検討が行われていないと、量産工程の能力を不必要に落としてしまったり、最悪テストが出来ない、ということになりかねません。

業務範囲に関しては、会社によって異なるようです。上記は私が所属していた会社での例です。とある会社ではLSI設計者は一切テストにはタッチせず、試作着工後に設計ドキュメントとデータを以てテスト担当部署に業務移管する、という話も聞いたことがあります。

これから何回かに分けて、このテストに関する話をご紹介したいと思います。

番外編〜どんなスクリプト書いたっけ？

第1回のテストベクタの加工、そして第5回の正規表現のお話で、sed、awk、そしてperlでスクリプトを書いて、長大なテストベクタの中から加工する箇所を見つけたり、実際に加工したりしたということを書きました。

実際どんなスクリプトを書いたかな？と、思い出しがてらperlのスクリプトを書いてみました。

第6回〜アナログテストでごめんなさい その２

アナログテストでごめんなさい、第2回目です。

今回は、テスト抜けがあって市場不良を出してしまった話です。

なぜテスト抜けとなってしまったのか、すでに全く覚えていないのですが、原因はともかくどのようなテスト抜けが起こっていたのかは覚えているので、ご紹介します。

LSIのテストは結構長い期間メイン業務としてやっていましたが、担当製品で明らかなテスト抜けが原因の市場不良を起こしてしまったのはこの製品だけです。

しかも、担当から外れていた時期に市場不良が出たので、後始末を他の方がやってくださって、20年近く経った今でも、お客様及び後始末をして下さった方には本当に申し訳なく思っています。

第5回〜半導体屋だけど正規表現にはお世話になりました

前回のawkのお話の一件以来、仕事の中でミスの混入を防ぐだとか、効率的に仕事をするという観点から、小技として仕事でスクリプト言語を使う頻度が増えました。

 EWSの普及と、自分の席にあるパソコンがネットワークにつながって、パソコンからEWSにリモートログインできるようになったことも機会が増えた理由ではあります。

私が扱った設計データ、内製設計ツール用のネットリストファイル、Verilog HDL、LSIテスターのテストプログラム、テストパターンはみんなテキストファイルで、ものによってはテキストエディタで簡単に開くことが出来ないような巨大なものもあります。ですから、テキストエディタで開くことなく修正、加工をしたいわけです。

そこで役に立つのがsedやawk、perlです。これらのコマンドを使って対象文字列をサーチしながら加工すると、対象ファイルがいくら巨大でも大丈夫です。そして、このsed、awk、perlのスクリプトの中で、加工対象文字列を探すために欠かせないのが正規表現（Regular Expression）です。

正規表現っていう言葉、わかりにくい言葉ですけれど、色んな文字列を一つの文字列で表現するために考えられたもの、と言いましょうか・・・それ自身がわかりにくいですね。

第4回〜レイアウト設計でawkのお世話になったお話

入社5年目ぐらいの頃に、自分が所属していた会社が設計拠点を青森県五所川原市に作る動きになり、私を含む3名がロジック系のグループとして、五所川原に異動ということになったのでした。

そこで私待ち受けていたのは、お仕事全然な〜い！っていう状況からの、設計拠点の立ち上げのための様々な雑務、そしてやったこともないチップレイアウト・・・

でも、レイアウト設計に関するノウハウみたいなものは、自分的には全くないので（笑）、さすがに書けません。が、持てる知識を総動員して、なんとか切り抜けた、っていうお話です。

第3回〜アナログテストでごめんなさい

シングルチップマイコンには、だいぶ前からA/Dコンバーター（ADC）やD/Aコンバーター（DAC）が搭載されています。私がいた会社のマイコン製品群にも当たり前のように搭載されていました。

もっとも、性能面では、当時たとえばADCは5Vフルスイングの10bit解像度、変換時間がシステムクロックで20クロック前後、つまり10MHz動作の製品だと2μsec、変換誤差が±2LSBぐらいのスペックのものだったので、高速高性能の要求に応えられるようなものではありませんでした。今現在の製品はよく知りませんけどね。

当時やろうとしていたCPU搭載ASICでは、これらも含めてASICライブラリー化しようとしていたので、当然これらADC、DACの製造テストを考えなければなりません。

今回は、この辺のお話で、タイトルにあるように「ごめんなさい」なお話をご紹介します。ADC、DACを専門的に扱っている方から見たら、なんとレベルの低い話、と思われるかも知れません。申し訳ありません。

第2回〜2相クロックの罠

はじめに

第2回目は、私が会社に入って最初に任されたまとまった仕事のことを書きます。

会社に入って最初の年は、ひたすら机でお勉強することと、いろんなソケットの半田付けなんかが主立った仕事でしたが、その年の秋頃から評価用のLSIの実装機評価を任されました。

これはタイマーとかシリアルインタフェースといったマイコン周辺機能のブロックだけを入れたLSIを作って（LSIの開発自体は別の人がやってました）、それを実装機で動かして機能の評価をする、という仕事で、たしか評価対象のLSIは、ウォッチドッグ・タイマー、フリーランタイマー、クロック同期シリアルインタフェース、調歩同期シリアルインタフェースの4チップ。

おそらく、機能的にそれほどたいしたものではないっていうことから、先輩方も新人に任せたのでしょう（調歩同期はちょっと厄介だけど）。

ところが、動かない・・・

第1回〜他部署のテストベクタのバグを見つけちゃった

第1回目の今回は、自分の業務経験の中で、最も技術的、そして力業（ちからわざ）的によくできたと思っている事案をご紹介します。技術的に良く出来たとは言っても、技術レベルが高いという話では全くないのですけれど（苦笑）

それは、自部門の製品開発のために、他部門から頂いてきた設計データ一式の中に入ってた、LSIテスト用のテストベクタ、しかもそれはすでに結構な数量の出荷実績のある製品シリーズ共通で使われていたテストベクタにバグがあることを、量産工程へのテストデータ払い出し直前に見つけちゃって、力業（ちからわざ）で直して適用したっていう話です。

しかもテストベクタとは言っても、内蔵しているCPUで動作するプログラムのアセンブラソースがおかしいっていうお話でして、結構話が面倒なのです。だから力業（ちからざわ）と申し上げているのでして・・・。

しかしまあ、数百万個出荷された製品シリーズのテストに製品シリーズ共通で使われていたテストベクタに紛れ込んでいたバグだったので、見つけたこっちが青くなりました。

エンドユーザーに渡るデータではないにしても、テストベクタは不良を外部に流出させないための砦ですから、ちゃんとコードレビューをしないといけませんね。