2018年9月13日木曜日

イーサネット + DMACの評価でやってしまいました

2009年頃、筆者はとあるプリンターメーカー向けASICの実装機評価に参加して、イーサネットインタフェースの評価を担当しました。これは、既存のイーサネットインタフェースとDMA(Direct Memory Access)コントローラを1つの機能ブロックとしてまとめたもので、この製品のために開発されたカスタム機能ブロックでした。

内蔵CPUを動かすプログラムをC言語で書いて、ソフトウエアでイーサネットコントローラーを制御し、動作させる、というのが、実装機評価の内容です。

試作品が出て来た時点で、実装機を使った通信機能の機能評価をして、通信機能に問題が無いことは確認していました。しかしお客様のセット試作品評価において、とある動作条件のときのみ発生する動作不具合が見つかってしまいました。筆者が実施した内部評価で見つけることが出来なかったのは、筆者の力不足だったのはもちろんなのですが、イーサネットコントローラー単体評価がミッションだったのか、イーサネットコントローラー+DMAコントローラーの評価がミッションだったのか、今となっては定かではありません。

しかしまた、ここでも、筆者が実装機評価に参画して担当した機能ブロックにはバグが出る、というジンクス通りのことが起こりました。

本件、記事執筆時点で9年を経過した出来事なので、記憶が曖昧な点があります。可能な限り矛盾が生じないように、内容を吟味してはいますが、お許しを。

2018年5月15日火曜日

シフトレジスタの罠

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

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


2018年3月13日火曜日

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

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

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

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

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

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

その名も

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


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

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


2018年3月1日木曜日

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

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

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

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

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

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

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

2018年1月13日土曜日

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

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

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

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

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

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