シフトレジスタの罠

以前筆者が担当した製品で、バウンダリスキャン回路のテストパターンが、どう頑張っても通らないという事例が発生しました。

テストパターンのフェイルデータを取って解析してもらったところ、バウンダリスキャン回路の、シフトレジスタを構成するFFでホールドタイム不足が発生していたことが発覚しました。タイミング制約の設定抜けでした。

携帯電話向けASIC・テストタイム短縮が急務

筆者のキャリアを変える製品となった携帯電話向けASIC製品ですが、設計完了して試作評価も終わり、信頼度試験も終わって量産出荷開始となった後、さほど生産量も多くなく生産が収束しました。こちらは一番大きなキャリア向けの製品だったのですが、さほど数が出なかったのです。

しかし、他のキャリア向けの製品として、論理変更、ROM変更を施した展開製品の開発がありました。

こちらは、最初の製品で出た様々な問題をフィードバックして、開発はスムーズに進んだと記憶しています。

特性評価は、開発の実務を仕切ってくれた若い実務担当者に、評価結果のまとめ方、設計部見解の考え方、書き方を学んで欲しかったので、筆者が作成した評価結果まとめ（社内では特製認定書と呼んでいました）を参考にしてもらって、やってもらいました。

量産出荷スタートの後、色々と問題が出ました。

携帯電話ビジネスでは、生産数量の増減がとても急激に起こります。しかし、注文が急激に増えたとしても、工場の物理的な生産能力はすぐに増やすことはできません。そこで大事なのが、既存の設備で何とかできないかを検討すること。ことテストに関しては、時短、つまりテストタイム短縮です。

携帯電話向けASIC・試作評価〜私のキャリアを変えた製品のはなし

論理設計、レイアウト設計を完了して、製品開発はアートワーク工程、マスク作成、試作着工と進んでいきます。

この間およそ1ヶ月弱、ものによってはもっと早い場合もありますが、試作ロットが前工程を流れている間、評価チームや論理設計チームは、測定しなければならない項目の吟味等をしつつ、試作品の評価の準備をします。

ASIC製品では、電気的特性の社外保証項目が決まっているので、何を計るかはあまり気にしません。この製品でも、具体的な数値要求のある測定項目はあるものの、項目自体はどの製品でも測るものなので、あまり深く考えていませんでした。

少なくとも、評価を始めるまでは、そして最初の測定値を見るまでは・・・

実機評価でバグ発見！ 〜 オーディオI/F編

はじめに

筆者がいたASICの世界では、製品の仕様から論理設計はお客様の担当、論理設計から先が半導体メーカーの担当、という分担となる場合が多いです。

そのようなビジネスの場合、デバイスがお客様が作成したテストベクタ通りに動くことは半導体メーカーで確認できますが、仕様として正しく動くかどうかを確認するのはお客様の担当となります。

製品仕様をお客様が策定する場合、動作仕様を正しく半導体メーカーが理解するのは無理なんです。

そのような製品開発では、半導体メーカーの試作評価は、製造テストをにらんだLSIテスターのみ、ということになり、実装機を使った実使用条件での評価は行いません。

このようなASICの世界にいた筆者ですが、以前「2相クロックの罠」のエントリーで書いた評価用チップの評価以外に、2製品で実装機評価を担当したことがありました。そしてその２製品で、担当した機能ブロックにバグがありまして、まるで当時から将来このような記事を書けと言われていたかのような歩留まりの良さ（笑）でありました。

その２製品のうち、片方は筆者がバグを発見、片方はバグを発見できず、お客様の評価でバグが見つかった、という状況でした。

今回のエントリーでは、私がバグを見つけた、という製品について書きます。オーディオI/Fに潜んでいた、非同期のクロックドメインをまたぐデータ転送のバグに関する話です。

半導体とお風呂の関係とは・・・？

はじめに

タイトルをご覧になって、何のこと？と思われる方も多いと思います。しかし半導体業界でデバイス開発寄りの仕事をしていた方なら、あー、なるほど、と思われるかも知れません。

後ほど種明かしをしますので、ちょっとお待ちを。

先日、「モニターバーンインの知見をお持ちですか？」というお問い合わせをいただきました。ありがとうございます。

モニターバーンインという言葉は、モニターという言葉とバーンインという言葉を繋げたものですが、モニターはいいとして、バーンインっていう単語、これは一体何ですか？というお話から、今回のエントリーを始めていこうと思います。

ちゃんとお風呂と話がつながりますからご安心を。

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

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

時短とは？

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

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

メモリーテスト〜フェイルビットマップに関する補足

以前のエントリーでSRAMのテストについて書きました。

この中で、テスターにSRAMのアドレス端子を教えてあげれば、不良を起こしているメモリーセルの物理的な位置を知ることの出来る、フェイルビットマップという便利なものがある、というような内容の説明を書きました。

これについて、若干補足したいと思います。

番外編〜テストにまつわる技術系派遣社員のはなし

1月に、前にいた職場の仲間と年に一度の集まりをしまして、近況報告をしあったのであります。

今回は参加者が少なくて、筆者を入れて5人、そのうち4人がテスト業務経験者という、随分と偏った集まりでありました。そのうち2人が技術系派遣会社に在籍して、派遣社員としてテスト業務に従事しているようであります。

そこで聞いた話によると、職場にいる若い人材、標準で用意されたテストメソッドを使うだけならいいんだけど、そのテストメソッドも中で何をやってるのか理解していないとのこと。

ん〜・・・

前回のエントリーで、テスト自動化を立ち上げようとして上手くいかなかった話を書きました。

その中で、

ちなみに近年のLSIテスターでは、標準的なテストメソッドはテスターメーカーが供給するライブラリに入っていて、GUI仕立ての画面でテストメソッドのアイコンをひもで繋げるとフローが完成、スペックはスプレッドシートから入力、という使い方が普通です。 

プログラムをユーザーが編集するような事は、特殊なテストをしなければならないとき以外ありません。

ということを書きました。こういう世界では、テスターから供給される標準的なテストメソッドは、トラブルがなければ特に中身を知る必要がないと言えばないわけですね。

しかし、せめて、ある測定をする場合には、どのような手順で測定がなされているのかが頭の中にあったうえで、提供されたテストメソッドを使うのでなければ、何かトラブルにあったときに対応できないですし、そもそもエンジニアとしてどうなの？ということになると思うんですよね。技術の幅も広がりませんね。

この先、世の中どうなっちゃうんだろう？と思わずにはいられないひとときでした。

技術を磨かないと、技術系派遣社員の人たちは仕事がもらえないですよ。

初めて量産出荷を担当した話のつづき

前回の「初めて量産出荷を担当した製品のはなし」の中で、普通ならしなくてもいい苦労をしたと書きました。

その中で前回の投稿ではウエハテストで水晶発振回路のテストをしたことを書きましたが、今回の投稿では、ASICの製品シリーズ立ち上げ期で道具立てがあちこちで不完全だったがための苦労について書こうと思います。

ASICのビジネスは、ASIC（Application Specific Integrated Circuit）が特定用途向けのICの略であることからもわかるように、特定顧客、特定用途向けにLSIを開発して販売するビジネススタイルとなるので、多品種少量生産となります。

他品種少量生産のビジネススタイルで事業をするためには、開発の期間、評価の期間、量産立ち上げの期間をできる限り短くして、お客様に早く製品をお届けしなければなりません。

これに対応するために、論理設計では標準セルライブラリーや各種の機能ブロックライブラリー、実負荷タイミング検証ツール、レイアウト設計では自動配置配線技術、EDAを使ったレイアウト検証技術を使って開発期間を短縮していきました。

テストにおいても、開発期間の短縮、量産立ち上げの短縮のために、テストプログラム/テスト図面の自動生成ツールというものを、設計部、生産技術部、そして生産技術研究所を巻き込んで開発していました。そして、そのツールのβ適用製品が、私が初めて量産出荷を担当した製品だったというわけです。

製品シリーズの立ち上げというものは、最初の頃は製品開発のためのインフラストラクチャーの開発から始まりますが、いつまでもインフラの開発だけ、というわけにも行かず、ある時期からは実際の製品の開発が並行して走るようになります。

つまり、道具立てがしっかり立ち上がっていなくても、それとは別に製品は出荷しなければならないわけです。

しかしそんな重たそうな仕事が、なんで新人に毛の生えた程度の業務経験しかない私なの？っていう気もいたしますけどね。

初めて量産出荷を担当した製品のはなし

　このエントリーでは、初めて自分が主担当で量産品の出荷立ち上げを担当した製品のことを書こうと思います。

今まで何回かに渡って特性評価について書いて来ましたが、それは実は今回のエントリーを書くための前準備でもありました。何せ、量産品の出荷の話となると、電気的特性の測定に関するいろんな事が出てくるので、事前に書いて置いた方が良いだろうと思ったのです。

会社に入って、業務実習という形で親会社の製品設計部門へと送り込まれ、256ピンのLSIソケットのハンダ付けから始まった筆者の技術者人生でしたが、第２回目のエントリーでご紹介した評価用LSIの機能・特性評価業務を経て、外部のお客様向けの製品を担当することとなります。

最初に担当した量産品は、とあるアーケードゲームの会社向けのCPU搭載ASICでした。ただ、出荷形態が通常製品と異なることや、当時参画していたCPU搭載ASICの製品シリーズの立ち上げ過渡期で、製品開発の道具立てがあちこちで不完全だったことなどから、普通ならしなくても良い苦労を色々と強いられた思い出深い製品です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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