2017年2月3日金曜日

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

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

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

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

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

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

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

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

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

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




テストプログラムって何?


LSIテスターで使うテストプログラムってどんなものでしょう?

それは、簡単に言うと、テスターを制御するための手続き、テストスペック、そしてLSIを動かして出力期待値を比較するためのテストパターン(テストベクタ)を合わせたもの、ということになります。

テスターを制御するための手続きとは、LSIに接続されている電源ユニットから3Vを出力して、流れる電流を電流計で測定しなさいとか、このLSI端子はテスト周期の先頭から5nsで信号が変化するような入力波形を使いますとか、このLSI端子に対してはテスト周期の先頭から50nsのタイミングでLSIの出力値をサンプルします、といったことをテスターに指示するものです。私が現役時代に使っていたアドバンテスト社製のT3340シリーズでは、FORTRANとよく似た記法の高級言語でした。

テストスペックとは、このLSI端子の出力電圧は2.7Vより高い電圧を良品と判定します、といった場合の、2.7Vより高い電圧、という定義のことです。上記の手続きの説明に出てくる5nsで信号が変化する、とか50nsのタイミングで出力値をサンプルする、という場合の5nsや50nsもテストスペックとなります。

テストパターンはこのブログの第1回で書かせていただいた、

テストベクタは、時間とともにLSIの端子に入力される1(ハイレベル)と0(ローレベル)の入力データと、その入力データを使ってLSIが動作したときに時間とともにLSIが出力するはずの出力値(出力期待値、もしくは単に期待値と言います。確率・統計で使う期待値とは意味が違います)から作られるものです。 

LSIの論理設計のときに、動作の検証のために作られますが、これが試作品の動作検証、特性評価、及び量産品の出荷選別に使われるという、重要な設計データです。LSIの動作が定義されているデータと言っても良いものです。
第1回ではテストパターンをテストベクタと書いていました。引用はそのままテストベクタの表記でしますが、本稿ではテストパターンという表現をさせていただきます。

というようなものです。

これらは、旧来の設計方式では、製品ごとに個別に作っていました。もちろん旧来製品からの多少の流用はあったと思いますが、基本的に製品固有でした。

テスト図面の作成とは?


テストの実務において、製品のデバッグ、テストパターンのデバッグ、特性評価、スペック決定といった作業の他に、テスト図面の作成という手間のかかる作業がありました。

これはテスト方式やテストスペックを図面に描いて図面庫に入庫して関連部署に配布してもらう、というもので、図面配布が終わらないと量産の着工ができないというのが工場としての一番重要な決まりになっていました。さらに、量産のテストはこの図面に書かれたスペックでなされていないといけない、というのも、同じように工場としての重要な決まりでした。

テスト担当者には大きな負担だったのですが、テストスペックが決まれば、あとは定型作業となるものなので、自動化しやすい作業だったのです。
テストプログラム自体が電子化された文書である、と考えることができます。しかしこの当時はまだその考え方は社内で認められず、必死に紙の図面を描いて入庫していました。しかし後年テストプログラムを図面として扱うということになり、図面の扱いは随分楽になったようです。紙の図面(及びそれに準ずる電子図面)が完全になくなったわけではなかったようですけど。 
図面をきっちり描いてそれに基づいて仕事をすることは、品質を維持するのに大切なことですが、かといって、図面を描くのに時間がかかって製品の出荷に時間がかかるようでは、他社に勝つことはできません。 

テストプログラム/テスト図面自動生成ツール(ATEST)


テストベクタはどう頑張っても製品個別ですが、テストプログラムの作成と、テストプログラムの内容を文書化したものであるテスト図面の作成を自動化しようというものがテストプログラム/テスト図面自動生成ツールというものです。たしかATESTと呼んでいました。

テストプログラムについては、特殊なテストでない限りテストメソッドは決まっているので、製品で使われているLSIピンのI/Oバッファの種類、機能ブロックの種類、パッケージの種類を設計データから拾ってくれば全体のテストフローは決まってしまいます。

そして、テストスペックは、ACタイミングについては設計データから情報を持ってくることができますし、DCスペックもI/Oバッファが決まれば決まるので、特殊なスペックがあるものについてスプレッドシートから項目ごとに入力していく、というユーザーインタフェースになっていたと思います。必要なデータを入力して、画面上のプログラム生成のボタンを押せば、テストプログラムのソースプログラムが生成される、という仕組みです。

さらに、その情報をテスト図面のひな形データに挿入してあげれば、テスト図面のデータも生成できる、という思想で作られていたと思います。

ちなみに近年のLSIテスターでは、標準的なテストメソッドはテスターメーカーが供給するライブラリに入っていて、GUI仕立ての画面でテストメソッドのアイコンをひもで繋げるとフローが完成、スペックはスプレッドシートから入力、という使い方が普通です。プログラムをユーザーが編集するような事は、特殊なテストをしなければならないとき以外ありません。

使われていたプラットフォームは、自動生成システム自体がDECstation上で動くUltrixシステム(簡単に言うとDEC版のunixですよね)上で動くものでした。1990年代初期の話なので、当時まだDECは大きなシェアを持つワークステーションメーカーとして存在していて、SUNのワークステーションはまだ珍しかったはずですね。

当時はPC/AT互換機なんていうものも一般的ではなく、Linuxも最初のリリース(1991年)から間もない時期だったようなので、普通のパソコンユーザーがunixにさわるなんて事はできない時代でした。

ですから、学生時代からunix系のOSに憧れていた私は、そのDECstationで無邪気に遊んでいたものです。

図面系は、当時社内で使われていたゼロックスのJ-Starシステムでした。調べてみるとワークステーションが1台500万円もするようなとんでもなく高級なシステムだったんですね。

これが5年ぐらい後の話であれば、LinuxでLaTeXを使って図面生成なんていうことにもなったのかもしれません。

何が大変だったのか?


製品設計データからテストプログラムを生成して、テストパターンも合わせてテスターに持っていってコンパイルしてデバッグ開始、ということになる訳ですが、最初に直面したのは、仮に入っているテストスペックが適切ではなくて、ことごとくスペックを直さなければいけなかったことだったと記憶しています。(なにせ1990年代初頭のことなので記憶があやふやで申し訳ありません)

さすがにテスターに持っていったソースプログラムがコンパイルエラーを出した、なんてことはなかったと思いますが、テストスペックは全部真面目に見直さなければなりませんでした。
もしかしたら、自動生成されたプログラムを使って、何もせずにテストがパスしてしまったら、何か重大な見落としが発生してしまって危険、という配慮があったのかもしれません。いや、そのように考えておいた方が良いですね。
そういうわけで、テスト現場でデバッグしつつ、プログラムに設定されているテストスペックをことごとく修正するわけですが、この修正結果は、後のテスト図面の生成のために、ATESTの製品データにフィードバックしなければなりません。

更に言えば、フィードバックをかけた製品データで再びテストプログラムの生成を行って、手修正をしたプログラムと新プログラムのテスト結果が一致することを確認した後、新プログラムに差し替え、というのが正しい進め方なんです。本来はそうするべきです。

しかし、限られた時間(テスターって、大抵は夜中に1人でやるものでしたので)でそういう正しい進め方をしている余裕なんてないですし、自動生成されるプログラムの元データ(テストメソッドが定義されたもの)自体が完成されたものではないわけで、手元にある手修正を加えたプログラムでとにかく事を進める、ということになってしまいました。

そうなると、その後何が起こるかというと、実体と異なったテストスペックが入ったテスト図面を生成して、図面を手作業でしなければならないことになるのです。

ちなみに初めての量産担当製品ですから、テスト図面を描くのも初めてだったわけでして、図面体系も理解できていないところから始まって、自動生成される(スペックが正しくない)図面で図面が全て足りるのか足りないのか?スペックの修正はどこをどう直すのか?足りない図面はどうやって描けばいいのか?などなど、見るところ、学ぶこと、考えるところが膨大にあり、修羅場でありました。

先輩方に聞こうにも、根本をわかっている人があまりいないようで、要領を得ない答えが返ってきて、随分悲しい思いをしたような記憶がありますよ。

結局テストプログラムが完成したあとに、本来自動化されているべき図面作成で1週間で2回か3回徹夜しました。納期は決まってますからね。

このシステム、その後いくつの製品に適用されたか知りませんが、生産技術部など量産の立ち上げを一緒にやる部署からの評判も悪く、さらに別のASICの製品展開グループが独自に作っていた自動化システムの方が使いやすい、ということで廃れていきました。

製品展開グループのシステムは、パソコンベースのこじんまりとしたシステムだったと思いますが、図面のテストスペックをテストプログラムから拾い上げる、という、実態に即した思想で作られていたと聞いています。

この製品を担当したおかげで、テスト技術だけではなくて、量産品を流すのに必要な色々な知識を勉強することができたと思います。もちろんこの製品だけでは全く経験が足りず、この先も色々と勉強させられるわけですが、良い勉強になりました。

関連部署の方々も、納期までに製品を流さなければならない、という目的意識は共有してくださっているので、こちらがきちんと真面目に仕事をすれば、いくらでも協力してくださる、ということも、身にしみてわかりました。

このシステムがうまく立ち上がらなかった原因ってなんだろう?と今もたまに思うのです。簡単な話ではないのでしょうけど、おそらく、システム開発をした人たちの中に、実際にテスターデバッグから量産移管までの実務に精通している人がいなかったんじゃないかと・・・

0 件のコメント:

コメントを投稿

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