マスクプログラム方式のASICでは不可能な書き換えが、何度もできることはFPGAの大きな利点だ。このため、シミュレーターによる設計検証はそこそこで打ち切り、実機検証へと走りがちになる。しかし、FPGAの規模が大きくなるにつれて、このやり方は厳しくなる。FPGA内部は簡単には見られないため、デバッグが難しいからだ。最悪の場合、検証が収束しなくなる。
こうしたFPGA設計の罠に嵌り、そこから抜け出した経験を、三菱電機マイコン機器ソフトウエアの石野 禎将氏（第４事業部 副事業部長）が講演で語った（図1）。この講演は、「Design Solution Forum 2014」（2014年10月3日に新横浜でDesign Solution Forum 2014 実行委員会と日本エレクトロニクスショー協会が開催）で行われた。同社はその名の通り、ハードウエアもソフトウエアも開発する。FPGA設計の罠（図2）からの脱出には、ソフトウエア開発での経験が役立ったと同氏は言う。
ソフト開発と共通点
石野氏が示したように、ソフトウエア設計とFPGA設計は共通点が多い。容易に変更できる。言語で設計する。設計進捗が見えにくい。開発規模が大きくなると突然問題が顕在化するといった点だ。同社がFPGA設計の罠に嵌った時には、FPGAよりもさらに書き換えやすいソフトウエアの設計ではすでに同様な罠からは抜け出していた。いわゆるV字カーブに沿ってソフトウエア開発体制を整えたからだ。
そこで、ソフトウエア開発での成功体験を基に、ソフトウエア開発で取り入れた手法をFPGA設計にも取り込んだ。2008年ころだったという。例えば、設計レビュー評価にゾーン分析、検証進捗管理にXチャート、さらにメトリクス管理やゴールデンルールチェッカー導入などを行い、設計段階での検証に力を入れた。この結果、FPGA設計品質はかなり向上した。ところがFPGAの設計現場からは不満の声が上がったという。
同社ではFPGAを設計するエンジニアは、おおよそ2グループに分けられる（図3）。元々ASIC設計を担当していたエンジニアと、元々ボード設計を担当していたエンジニアである。前者はシミュレーションを使った設計検証に慣れてはいるものの、後者は実機検証重視の傾向があり、特に反発が大きかった。一方前者に関しても、シミュレーションによる検証の重要さを認識しているものの、エンジニア任せにしておくと、シミュレーションによる検証の適用率が下がってしまう。FPGAの規模が大きくなると、シミュレーション時間が長大化するためだ。
