VHDLによるFPGA設計の進め方｜仕様検討からシミュレーション・論理合成・実機検証までの流れ

FPGAの開発というと、HDLでコードを書く作業そのものを思い浮かべる方が多いかもしれません。しかし実際の設計プロジェクトにおいて、VHDLの記述が占める割合は全体の一部にすぎず、その前後には仕様の詰めや検証、制約の設定、実機での確認といった数多くの工程が控えています。

この記事では、VHDLを用いたFPGA設計がどのような流れで進んでいくのかを、工程ごとに何を検討し、どこでつまずきやすいのかという観点から整理します。これからFPGA開発の内製化を検討している方や、外部に委託するにあたって進め方の全体像を把握しておきたい方の参考になれば幸いです。

▶ 関連コラム：VHDLとは？FPGA設計における特徴とVerilogとの違いをわかりやすく解説

FPGA設計は記述が書けたら終わりではない

ソフトウェア開発であれば、コードを書いてビルドが通り、想定どおりに動作すれば一区切りがつきます。ところがFPGA設計の場合、記述が文法的に正しく、シミュレーションで期待どおりの波形が得られたとしても、それは工程の折り返し地点にすぎません。合成された回路が目標の周波数で動作するか、配置配線の結果がタイミング要件を満たすか、実機に載せたときに周辺回路と正しく噛み合うかという確認が、その後に待っています。

FPGA開発のスケジュールが読みにくいと言われるのは、この後半の工程で発生する手戻りが読みにくいためです。逆にいえば、各工程で何を確認すべきかを事前に把握しておくことが、開発期間を安定させるうえでもっとも効果的な対策になります。

第一工程　仕様の整理とアーキテクチャの検討

最初に行うのは、その回路に何をさせたいのかを、実装可能なレベルまで具体化する作業です。入出力する信号の種類とタイミング、動作させるクロック周波数、処理に許される遅延、単位時間あたりに処理すべきデータ量といった要件を洗い出し、それを実現する回路構成を検討します。

この段階で並行して行うのが、必要なリソース量の見積もりとデバイスの選定です。論理規模やメモリ容量、乗算器の数、必要な入出力ピン数を概算し、余裕をもった容量のデバイスを選びます。ここで規模を過小に見積もると、設計が終盤に差しかかってからデバイスの載せ替えが必要になり、基板の再設計にまで影響が及ぶことがあります。逆に過剰な容量を選べば、部品コストがそのまま製品原価に跳ね返ります。仕様検討は地味な工程ですが、後工程の手戻りをもっとも大きく左右する場面です。

第二工程　VHDLによるRTL記述

方針が固まったら、VHDLによる記述に入ります。ここで重要になるのは、個々の文法よりも、回路全体をどう分割するかという設計判断です。機能ごとに階層を分け、それぞれのentityで扱う責務を明確にしておくと、検証も分担もしやすくなり、後から機能を追加する際の影響範囲も限定できます。

あわせて、クロックとリセットの扱い方をプロジェクト全体で統一しておく必要があります。複数のクロックが混在する設計では、どの信号がどのクロックドメインに属するのかを整理し、ドメインをまたぐ箇所には適切な同期化の仕組みを入れなければなりません。この処理を怠ると、シミュレーションでは問題なく動作するのに実機では稀に誤動作するという、再現性の低い不具合の温床になります。リセットを同期式とするか非同期式とするか、アクティブレベルをどちらに揃えるかといった方針も、着手時点で決めておくべき事項です。

▶ 関連コラム：VHDLの書き方 初級編｜entity・architectureの構造と記述のポイントをコード例で解説

第三工程　シミュレーションによる機能検証

記述した回路が意図どおりに動作するかを、実機に載せる前に確認する工程です。テストベンチと呼ばれる検証用の記述を作成し、入力信号を与えて出力を観測します。VHDLにはassert文が用意されているため、期待値と実際の出力を照合し、食い違いがあれば自動的に検出させる仕組みを組み込むことができます。

この工程にどれだけ時間をかけるかは、プロジェクト全体の効率を大きく左右します。シミュレーション上であれば、内部のあらゆる信号を自由に観測でき、条件を変えて何度でも試行できます。一方、実機に載せてからの不具合解析は、観測できる信号が限られるうえに、原因が論理にあるのか基板にあるのかの切り分けから始めなければならず、はるかに多くの時間を要します。境界条件や異常系の入力まで含めて検証を作り込んでおくことが、結果的にもっとも近道になります。

第四工程　論理合成でハードウェアに落とし込む

機能の確認が済んだら、記述をFPGA内部の論理素子の構成へと変換します。この工程が論理合成です。VHDLで書いた動作記述は、ここでルックアップテーブルやフリップフロップ、専用の演算ブロックといった実際の資源に割り当てられます。

合成が完了すると、どの資源をどれだけ使用したかを示すレポートが出力されます。当初の見積もりと大きく乖離していないかを確認するとともに、合成ツールが出す警告に目を通すことが欠かせません。意図せずラッチが生成された、信号が接続されず削除された、同じ信号に複数の駆動元があるといった警告は、そのまま放置すると後の工程で原因不明の不具合として表面化します。警告を一つずつ潰していく地道な作業が、設計の品質を支えています。

第五工程　配置配線とタイミング制約

合成された回路を、FPGA内部の物理的な位置に配置し、配線でつないでいく工程です。ここで初めて、信号が実際にどれだけの時間をかけて伝わるのかが確定します。

この工程で不可欠になるのが、タイミング制約の設定です。クロックの周期はいくつなのか、外部から入力される信号はクロックに対してどのタイミングで確定するのか、非同期のためタイミング解析の対象から外してよいパスはどれなのかといった情報を、設計者が明示的に与える必要があります。制約が書かれていなければ、ツールは何を目標に最適化すればよいのか判断できず、タイミング解析の結果自体が意味をもちません。制約の記述は目立たない作業ですが、FPGA設計の成否を分ける要所であり、経験の差がもっとも出やすい部分でもあります。

制約を満たせない箇所が残った場合は、記述の見直しに戻ります。演算を複数段に分けて一段あたりの処理を軽くする、優先度の低い分岐を整理する、配置の指定を加えるといった対策を、解析結果を見ながら重ねていくことになります。

第六工程　実機での動作確認

最後に、実際のFPGAに書き込んで動作を確認します。ここでは、FPGA内部の信号を観測する機能や、外部の測定器を使って、想定どおりの信号が出ているかを確かめていきます。

実機で問題が出たとき、それが論理設計の誤りなのか、基板の配線や電源、信号品質に起因するものなのかを切り分ける作業は、FPGA単体の知識だけでは完結しません。クロックの波形が乱れている、電源のノイズが動作に影響している、外部デバイスとのインターフェースのタイミングが合っていないといった原因は、基板とその周辺回路まで理解していなければ見抜けないためです。この段階に至って、FPGA設計と基板設計を別々の担当が受け持っていることが、原因究明を長引かせる要因になることもあります。

工程ごとに求められるスキルが異なることが内製化の壁になる

こうして工程を追っていくと、VHDLを書けることと、FPGA設計プロジェクトを完遂できることが、必ずしも同じではないことが見えてきます。仕様からアーキテクチャを起こす力、抜けのない検証環境を組み立てる力、タイミング制約を適切に与える力、実機で原因を切り分ける力は、それぞれ性質の異なる経験の蓄積によって身につくものです。

▶ 関連コラム：FPGA開発の費用と期間はどう決まる？委託前に知っておきたいコスト構造

FPGAを扱う案件が年に数件という頻度であれば、これらすべてを担える技術者を社内に抱え、開発ツールと検証環境を維持し続けることが、かえって割高になることも少なくありません。どの工程を内製し、どこから外部の力を借りるのかを見極めることが、現実的な選択肢になります。

▶ 関連コラム：FPGA設計を外注すべきか？内製との比較と、委託先選びで失敗しないためのポイント

VHDLによるFPGA設計のご相談はアイディアイへ

FPGAを使いたいが社内に経験者がいない、記述はできるが検証や制約の設定に不安がある、実機で出た不具合の原因が切り分けられない。アイディアイには、こうしたご相談が数多く寄せられています。

当社は、VHDLとVerilogのいずれにも対応し、仕様の検討から論理設計、シミュレーションによる検証、タイミング制約の設定、実機での動作確認までを一貫してお引き受けしています。加えて、FPGAを搭載する基板の設計やファームウェアの開発、装置としての組み立てまで社内で対応できるため、論理と基板のどちらに原因があるのか判断しにくい場面でも、担当をまたぐことなく原因を追い込んでいくことができます。

FPGA開発の進め方でお悩みの皆様、構想段階のご相談からで構いませんので、ぜひお気軽に当社までお問い合わせください。お客様の体制やスケジュールに合わせた最適なご提案をさせていただきます。

▶ サービス紹介：FPGA設計開発 代行サービス

▶ サービス紹介：基板設計 代行サービス