シフトレジスタの罠

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

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

番外編・C#の2週間短期集中学習

いつもありがとうございます。1月に20万アクセスをいただいていました。それを記念して、と言うわけではありませんが、今回は番外編です。

たまにプログラムを書く仕事を下さる方から、C#でプログラミングができないでしょうか、というお話が来ました。

内容は、3次元データを平面に投影した絵をウインドウにプロットして、任意の平面で輪切りにしたスライス画像を作ることが出来るプログラム、ということでした。その方が色々とお付き合いをしている会社からの依頼だったようです。

お話を頂いた時点ではC#には触ったこともないので、その時点のスキルで回答するなら、「できません」ということになります。しかし、「できません」で終わらせるのは何かしゃくに障るように思えたので、出来そうかどうか検討するのに時間を下さい、とお願いをして、C#の学習を集中的にやりました。

結局色々な事情から、そのプログラミングのお話は無くなったのですが、せっかく勉強した知識を、忘却に任せて失ってしまうのは勿体ないので、せめて勉強したことを思い出せるように、ブログとして残すことにしました。

その名も

55歳からのC#プログラミング学習の記録

という、何か妙にベタな題名ですが、事実を表している題名なので、これで作っています。

もしよろしければ、こちらもご覧頂ければ幸いです。

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

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

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

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

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

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

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

携帯電話向けASIC・テストの立ち上げは大変でした

この携帯電話向けASICは、回路規模がとても大きく、DFT技術もそれほど進んでいない時代でしたので、その分テストパターンの量が膨大でした。

しかも、DSP付き32bit CPUコアのテストだけは、当面異なる機種のLSIテスターを使わなければならない事情があり、余計に大変なことになっていました。

テストパターンの量が多くなると、やることが増えることになる訳で、色々な問題が出て来ます。そして、色々なミスやトラブルが出ます。

今回は少し与太話のような内容になります。しかし、今回ご紹介する事例で、実際当時は非常に厳しい事態にもなりました。

なお、今回のエントリーでは、テストに関する幾つかのトラブルについて書きますが、決して当事者の方を非難したりする意図はありません。ご理解ください。

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

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

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

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

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