ライン検査カメラにおけるハードウェア／ソフトウェア機能分担
基板外観検査用ラインスキャンカメラの開発。センサは4096画素×16ライン、ラインレート60 kHz、16 bit/画素で、生データ量は約7.9 GB/s（4096×16×2 byte×60,000 line/s）。カメラ筐体はIP65、ファンレス、消費電力15 W以下、BOMは現行比+15%以内が条件。処理は(1)固定パターン補正・シェーディング、(2)2値化と欠陥候補のラベリング、(3)形状特徴によるクラス分類の3段構成。撮像から判定出力までのレイテンシは20 ms以内。現行案はCortex-A55 4コア+NEONのみで、試作では(1)だけで1ライン処理時間の80%を消費し、60 kHzに届かず45 kHzで頭打ちになっている。代替案として、FPGAを追加する案（+8,000円/台、NRE 3,000万円、消費+3 W）と、SoCをCortex-A76クラスに変更する案（+5,000円/台、消費+5 W、ファンレス限界に近い）が比較されている。年間出荷5,000台、製品寿命4年。ソフト担当は「まずNEONの最適化をもう一段やるべき」と主張している。
1. 3つの処理のうち、どれをFPGAへオフロードし、どれをCPUに残すか。定量根拠を示して配分を決めよ。
Read the worked answer
まずボトルネックの定量化: 60 kHzは1ライン16.7 µs。45 kHzで頭打ちということは1ライン約22.2 µsかかっており、(1)がその80%＝約17.8 µsを消費している計算になる。ここを削らない限り、他を最適化しても60 kHzには届かない。
割り当て案
- (1)固定パターン補正・シェーディング → FPGA。画素ごとの定数演算で、入力順にストリーム処理でき、CPUを介さずDDR帯域も削減できる。7.9 GB/sをCPUで受けてから処理する構成は、帯域としても現実的でない。
- (2)2値化とラベリング → 2値化はFPGA寄り。ラベリングは連結成分管理のためFPGAの内部メモリとロジックを消費する。1ラインあたりの欠陥候補が数個程度なら、2値化のみFPGA、ラベリングはCPUでも間に合う可能性がある。実測で決める。
- (3)クラス分類 → CPU（NEON）。品種ごとにパラメータが変わり変更頻度が高い。FPGAに置くとロジック再コンパイルが必要になり、品種切替のリードタイムが悪化する。
コスト比較: FPGA案は+8,000円×5,000台×4年＝1.6億円。SoC変更案は+5,000円だが消費+5 Wでファンレス15 Wの枠を超えるリスクがあり、熱設計のやり直しコストが読めない。加えてA76クラスでも(1)のストリーム処理が線形に速くなる保証はない。
→ (1)のFPGA化を先行させ、試作の実測で(2)の割り当てを決める。NEON最適化は(3)に対しては有効だが、(1)の17.8 µsを桁で減らすことは難しい。
2. レイテンシ20 msという要件を、パイプライン遅延とスループットに分解して検証する方法を述べよ。
Read the worked answer
レイテンシ20 msは「1ラインの処理時間」ではなく「撮像から判定出力までのパイプライン遅延」である。ここを混同すると、スループットは満たすが遅延で不合格になる。
分解: 遅延 = センサ露光・読み出し遅延 + バッファリング遅延（Nライン分）+ 処理遅延 + 出力・通信遅延。例えばFPGAで16ライン分のバッファを持つと、60 kHzでは16/60,000 = 0.27 ms。バッファ段数を増やすほどスループットは安定するが遅延は増える。判定をフレーム単位でまとめる設計にすると、フレーム周期分の遅延が丸ごと乗るため、ライン単位で判定を出す構成にする。
検証方法
- 先頭にマーカ画素を持つ擬似欠陥パターンを撮像し、入力エッジから出力エッジまでをオシロスコープまたはタイムスタンプで測る。
- 最悪条件で測る。すなわち欠陥が画面末尾にある場合、CPU負荷が最大の場合、FPGAバッファが満杯の場合。平均値ではなく最大値を合格判定に使う。
- メモリ帯域は、FPGA→DDR→CPUの経路に同時に7.9 GB/sを流したときに競合が起きないかを帯域モニタで確認する。平均帯域が足りていても、バーストで詰まれば遅延スパイクになる。
落とし穴: 試作の45 kHz評価はスループットの評価であり、レイテンシは別途測っていない可能性が高い。FPGA化の効果を判断する前に、現行構成での遅延の内訳を実測しておくべきである。
3. FPGAを追加することで生じる新しい失敗モードと、検証・製造でそれをどう管理するかを述べよ。
Read the worked answer
FPGAの追加は、これまで存在しなかった失敗モードを持ち込む。
- コンフィギュレーション: 起動時にビットストリームをロードする方式（フラッシュから/PROGピン）を決め、ロード失敗を検出する手段（DONE信号の監視、CRC）を設ける。失敗時は安全側（検査停止、アラーム出力）に倒す。起動時間が20 ms要件に含まれるかも確認する。
- バージョン整合: ビットストリームとファームウェアの組み合わせが一致しないと誤動作する。両者を1つのリリース単位として管理し、互換性のない組み合わせを拒否する仕組み（バージョンレジスタの読み出しと照合）を入れる。
- 製造試験: FPGA内部ロジックは外部から観測しにくい。BIST（内部でテストパターンを生成し結果を比較）を実装してFCTで実行し、コンフィグレーション用フラッシュの書き込み検査も追加する。
- 検証: ストリーム処理は境界条件（ライン先頭・末尾、バッファfull、リセット直後）でバグが出やすい。ランダムパターンでのCPU演算結果との突き合わせ試験を計画する。
見積り上の注意: これらをNRE 3,000万円に含めるか別枠にするかを先に決める。FPGAの論理設計だけを見積もり、コンフィグレーション検証・BIST実装・量産試験プログラムの開発を含め忘れると、後半で予算超過する。