最近、生成 AI のおかげでコードを書くことが随分楽になったと思いませんか？ソフトウェアのコードに比べると、ハードウェア向けの VHDL や Verilog、SystemC は、まだ精度こそ高くないものの、単純な処理であれば十分に実用的なコードを生成してくれるようになっています。
“単純なコードはAIが書く時代” は、すぐそこまで来ています。
では今後エンジニアに求められる価値はどうなるでしょうか ― その答えの一つは、生成 AI には真似できない “独自性のある高度な技術で付加価値を生み出す”ことです。それを実現するための最有力の設計アプローチがモデルベースデザインです。
本連載では、モデルベースデザインによるFPGA実装を数回に分けて解説します。第1回の本稿では、そのコンセプトを整理し、狙いと効果をご紹介します。
モデルベースデザインってFPGA/ASIC設計にどう役立つの？
さて、FPGA / ASIC 設計に携わるハードウェア設計エンジニアの皆さんは、モデルベース デザイン（モデルベース開発 / MBD、以下 MBD）という言葉を聞いたことがあるでしょうか？もしかすると『ハードウェア設計者には関係ない』と思っている方もいるかもしれません。
高位合成ツールの一角として捉えられがちなこの手法。実際にはアルゴリズムをモデル化し、人為的なミスを最小化して効率的に実機へ落とし込める “設計手法” です。すでに海外だけでなく日本でも、製品開発をはじめ、大学や企業の研究開発の現場で数多く利用されています。
特にレーダー、ワイヤレス通信、モーター制御、画像処理といった複雑なアルゴリズムを FPGA / ASIC に実装する際に、大きな恩恵がある設計手法。このブログでは、FPGA 設計者にとってのモデルベースデザインの「うれしさ」を解説します。
なぜ「モデル」から始めるのか？
モデルで解析やシミュレーションを行い検証したら、モデルからコードを生成して実装～この一連のフローで設計開発を進めることを MBD と言います。
なぜ「モデル」から始めるのでしょう？「モデル」で始めることでどのような「うれしさ」があるのでしょうか？
ここで言う「モデル」は単なる絵や図ではなく、時間的な変化や入出力の挙動を再現できる動く設計仕様書です。このモデルを使うことで、設計段階からシミュレーションによる動作確認が可能となり、設計意図の共有や不具合の早期発見に大きく貢献します。
また、モデルは実装コードそのものではなく、実現したい機能を機能ブロックの配置・配線によって抽象的に表現したものです。そのため、設計者はコード記述の細部にとらわれず、ロジックやシステム全体の挙動を上位レベルで検討できます。最終的には、このモデルから自動的に HDL や C コードを生成することで、モデルと実装の等価性を維持しながら効率的に開発を進めることができます。
“付加価値“を生み出すためには“技術革新”が欠かせません。“革新“とは、全く新しいものを生み出すことではなく、「既存の要素を新しい形で組み合わせること」だと言われます。読者のみなさんが日々取り組む FPGA 開発の現場においても、この考え方はそのまま当てはまります。FIR フィルタ、FFT、PID コントローラなど、既に確立されたアルゴリズムや IP コアをベースにしつつ、自分たち独自のロジックや処理方式、アーキテクチャを融合させていく～そこに新しい“付加価値“が生まれます。
MBD の代表的なプラットフォームである Simulink には、膨大な数のアルゴリズム・ライブラリが用意されています。それらを配置・配線・パラメータ設定をして、独自の処理を少し追加すれば、エンジニアが頭の中で描いた「新しい形での組み合わせ」を具体化できます。
ライブラリは後述するような抽象度の高ものから、加算器・乗算器やビット演算といった抽象度の低いものまで揃っており、十分豊富なバリエーションが用意されています。
それにより、”技術革新”による”付加価値”を生み出すことができるようになっています。
さらに、作成したモデルは波形表示や数値解析を通じてその場で動作を確認でき、開発の初期段階から問題の早期発見・設計の改善を可能にします。
下図は、通信システムのベースバンド送受信シミュレーションを行うモデルの一例です。信号生成、変復調、フィルタ、RF コンポーネントによる信号劣化、通信路などのブロックライブラリを組み合わせて「モデル」を構築し、送受信信号のコンスタレーションやパワースペクトルを可視化しています。これにより、通信品質や信号処理アルゴリズムの特性を実機作成前に解析・評価することができます。
下図ではクアッドローター（ドローン）の飛行モデルを用いて、シミュレーションによる動作確認を行っています。グラフでは、機体の姿勢角（ピッチ・ロール・ヨー）や位置座標（X・Y・Z）の応答を時系列で可視化しており、制御アルゴリズムの安定性や追従性を確認できます。
下部のアニメーションビューでは、3D空間上でドローンの動作を可視化しており、離陸から荷物の運搬、着陸までの動きを直感的に理解できます。
このように、モデルを使うことで制御対象を含んだシステム全体を統合的に検証でき、実機を使わずに安全かつ効率的な制御設計の評価を行うことが可能になります。
下図は、SoC FPGA に実装可能な抽象度で構築されたパルス・ドップラー・レーダーシステムのモデルです。このモデルは、RF 信号の送受信からデータ処理、結果の可視化までを一貫してシミュレーションできるように設計されています。
モデルの最上位階層は、RF Data Converter ブロック、FPGA 実装用の信号処理サブシステム、AXI4-Stream + DMA、プロセッサ実装用サブシステム、および結果可視化用ブロックで構成されています。これにより、ハードウェアとソフトウェア間のデータフローや処理分担を明確に把握できます。
一方、左下に示すモデルの下位階層では、受信信号のレンジ（距離）およびドップラー（速度）推定を行うために、フィルタや加算・乗算などの基本演算ブロックを組み合わせ、信号の相関計算処理を実装しています。
この階層構造により、アルゴリズム設計から FPGA 実装に至るまでをモデル単位で一貫して検証・最適化できるのが特徴です。
右下のシミュレーション結果では、距離‐速度平面上におけるターゲット検出マップが可視化されており、特定の距離・速度に対応する目標物体が検出されている様子が確認できます。
このように、モデル化することで、次のような効果を得ることができます。
- 「動作のイメージ」と「実際の挙動」のギャップを埋める
- 性能や安定性を定量的に把握する
- 問題箇所を視覚的に特定する
MBD は単なる設計・開発の補助ツールではなく、技術革新を加速するための設計・開発環境なのです。
FPGA 実機ではなくシステムシミュレーションで機能検証を行う
話を FPGA / ASIC 設計に戻しましょう。VHDL / Verilog などのハードウェア記述言語をコーディングしてターゲットデバイスに実装していく従来のアプローチでは、設計の初期段階で詳細な実装表現に縛られてしまうという課題がありました。そのため、アーキテクチャ全体の妥当性やアルゴリズムの有効性といった “機能レベルの検証“が後回しになり、実機が完成するまでその性能や安定性を十分に評価できないケースが多くありました。
たとえば HDL シミュレーターでは、クロック周期でタイミングや数値の確認はできても、モーター制御で制御対象を含めてモーターの回転速度の偏差を評価したり、ワイヤレス通信で対向モデルを含めて BER（ビット誤り率）を測定したりするようなシステムレベルの機能検証は困難です。
このため、設計の意図と実際の挙動との間にギャップが生じやすく、実機で初めて問題が発覚するケースも少なくありませんでした。
MBD では、実機で行っていた多くの検証を、より早い段階で機能モデルを使ってシミュレーションで確認することが可能になります。
これにより、設計の手戻り、つまり後工程でのやり直しが大幅に削減され、開発サイクル全体の効率化が実現します。
ただ、ここまでで作成されたものは、“動く仕様書”＝シミュレーションモデルです。このモデルは、「こう動くべき」という理想的な動作を表現しているに過ぎません。では、この高度なシミュレーションモデルをどのようにして実際に動作する FPGA へと落とし込み、さらに「モデルと FPGA が同じ動きをしている」と確信できる状態にまで持っていくにはどうすればよいのでしょうか。
ここから先が、MBD におけるもう1つの重要なステップ、すなわち「コード生成」と「等価性検証」です。
等価性の確保：モデル＝参照仕様にして“ギャップ”を消す
従来の“コード”ベースの開発では、自然言語で書かれた仕様書をもとにコードを書いて設計が進められていました。しかし、文章で書かれた仕様には、人によって異なる“解釈”が入り込む余地があります。たとえば、「信号が安定したら出力を保持する」と仕様に書かれていても、“安定”の定義や保持のタイミングを、設計者ごとに微妙に違って理解してしまうことがあります。
さらに、仕様を回路に落とし込み最適化していく過程では、「回路はこう動くはず」「こうしたほうが速い」といった個人の経験や勘にもとづいた判断が入りやすくなります。
その結果、本来意図していた機能仕様と、実際に実装された回路の挙動との間に“ギャップ（乖離）”が生じることがあります。
こうした“解釈のズレ”は、開発が進んでから発覚することが多く、手戻りやデバッグ工数の増大といった形で、プロジェクト全体の効率を大きく損なう原因になります。
このような課題を解決するのが MBD の考え方です。MBD では、まずシステムの振る舞いを「モデル」で表現し、そこで機能検証や性能評価を行います。この段階でシミュレーションを通じて「これで本当に意図した動作になるか？」「要求されている性能を達成できるか？」を繰り返し確かめ、実機依存する実装の前段階で設計の正しさを固めます。
ここで大切なのは、「モデルが仕様の参照である」という点です。I/O インターフェイスの型、動作周期、性能や偏差といった機能上の肝を、モデルに紐づけて明示し、仕様の更新は、まずモデルで行います。そのうえで自動コード生成をかけるため、実装はモデルの振る舞いと等価になります。
もちろん「自動生成だから常に完全一致」と言い切るのは乱暴です。
仕様書に基づいて機能を定義した「仕様」モデルでは一般的に浮動小数点でシミュレーションが行われるため、固定小数点化を行った実装とは誤差が生じます。ここで重要なのは、誤差を「数値で管理」することです。たとえば浮動小数点モデルを真値とし、固定小数点化後の出力との最大偏差に始まり、制御系ならオーバーシュート量や定常偏差、通信系なら BER といった各アプリケーションで利用される KPI を、モデル上で自動計測します。後述する実装モデルにおけるパイプライン遅延も、モデル上で明確化して“遅延込みで等価”を定義し直します。「なんとなく一致している気がする」といった曖昧な判断を排除し、定量的かつ再現性のある検証を実現します。
開発期間の短縮：実装前に“回せる”から、手戻りが激減する
TAT（開発のリードタイム）短縮は、単に自動コード生成の時間が短いから、という話ではありません。効いているのは 設計判断の場所が上流に移る ことです。
SNR やエラー率が何％なのか、検出性能は仕様通りか、バッテリー駆動時間は ～ 従来なら“まずコードを書いて論理合成して実機実装して動かして”から分かることを、モデルの段階で相当部分まで決められます。しかも決めるたびに、テストモデルが同じ指標で合否を出してくれる。意思決定のサイクルが、日単位から分・時間単位へと短縮されます。
実作業で特に大きいメリットは、失敗は実機を作る前の“安いところ”で起こせる点です。
例えばフィードバック制御の定常偏差とオーバーシュート量が両立しないように見える場合でも、コントローラのパラメータを自動的にスウィープすれば、性能を満たす解が短時間で見つかります。デジタルフィルタの次数とカットオフ特性のトレードオフなども同様で、モデル上で機能的な特性を素早く押さえてから、詳細化していけば下流の探索は狭い範囲で済みます。それにより試作回数を減らすことができます。
さらに、ワークフローの自動化も、TAT 短縮に大きく寄与します。後述する HDL ワークフローアドバイザーのようなツールを利用すれば、I/F 設定から合成、ビットストリーム生成、ボードへの書き込みまでの一連の作業を半自動化できます。
また、SoC FPGA 評価ボードの I/O インターフェイスや AXI インターコネクトを事前定義したテンプレート、「リファレンス設計」を活用すれば、PS / PL の接続にかかる工数を最小化でき、最初の“動く実機”に早く到達できます。
このように、MBD による TAT 短縮の本質は、「設計判断の前倒し」「失敗コストの低減」「ワークフロー自動化」の三つの仕組みが組み合わさっている点にあります。
これらを実現することで、単なる時間短縮にとどまらず、設計の品質と再現性を両立させた開発プロセスが確立されるのです。
全体ワークフロー：機能モデルから実装モデルへと落とし込んでいく
MBD による FPGA 実装のフローを詳細に見ていきましょう。
(1) 機能モデル作成～アルゴリズム検証
まず、要求仕様（入出力・レート・KPI・機能）を整理し、シミュレーション実行が可能な浮動小数点ベースの機能モデルを作成します。この段階では、設計したアルゴリズムが要求どおりの機能・性能を満たすかを早期に確認することが目的です。
また、テストモデルを作成し、そこでの出力を真値（ゴールデン）として確立します。このテスト環境を用いて、実機に近い利用条件や入力シナリオをスウィープさせて、境界条件やエラーモードを網羅的に洗い出します。
例えばレーダー信号処理で FFT を実装するケースを考えます。機能モデルでは下図のように複数の機能ブロックや MATLAB Function ブロックに MATLAB コードで処理内容を書いて動作をテストします。
これにより、各パラメータによる影響・演算精度などの特性を定量的に確認し、後続の実装モデルの作成や固定小数点化に向けて最適な構成を検討できます。
(2) 実装モデル作成～固定小数点化
機能モデルで動作と性能を確認した後は、実装モデルへと発展させます。この段階では、固定小数点化の支援ツールを使って各演算器のビット幅を最適化し、FPGA や ASIC での実装に適した演算精度に変換します。
変換したモデルと浮動小数点演算を行う機能モデルとを比較して生じる量子化誤差を測定し、あらかじめ定義した許容誤差範囲に収まっているかを検証します。もし誤差が大きい場合は、ビット幅やスケーリングの設定を調整し、精度と回路リソース使用量のバランスを取ります。
またこの段階では、回路アーキテクチャを考慮してモデル構成のリファクタリングも並行して行います。例えば、演算の並列・直接化、パイプライン挿入、リソース共有化など、ハードウェア実装時の速度性能やリソース効率に影響する部分をモデルの構造やパラメータで調整します。
前の機能モデルから実装モデルに発展させると、下図のようになります。ここではレジスタに相当するブロックや HDL コード生成用に最適化された FFT ブロックを使用し、MATLAB コードで記述していた処理を HDL コード生成可能なスタイルへと書き換えています。
このように、FPGA 実装後の動作が機能モデルと許容誤差範囲内で等価になるように、演算精度、回路構造、HDL コード生成適合性を同時に考慮しながら、ハードウェア性能に直結する設計を進めていきます。
(3) HDLコード生成・レポート確認
実装モデルが完成したら、HDL コード生成を実行します。この段階では、モデルで設定したパイプライン段数、リソース共有、RAM マッピングなどに加えて、生成するコードの種類（VHDL / Verilog / SystemVerilog）、リセットタイプ、クロックやリセットのポート名やタイプなど全体に関わる設定を行ってからコードを自動生成します。
コード生成後は、コード生成レポートを確認します。レポートには、主に以下のような情報が出力されます。
- HDL コードとモデルのトレーサビリティ（対応表）
- 追加されたパイプライン段数の情報
- 推定リソース使用量（乗算器 / 加算器 / レジスタ / RAM）
- 推定クリティカルパスの場所と遅延
- リソース共有された演算器の情報
これらの情報をもとに、性能とリソース使用量のバランスを評価し、必要に応じてモデル側へフィードバックして設計パラメータを再調整します。
このように「モデル⇔レポート」を行き来することで、設計仕様とハードウェア性能を段階的に高めていくことができます。
また、生成されたコードは、コメント、信号名、ブロック名がモデルから継承された形で出力されるため、モデルとコードの対応関係（トレーサビリティ）を容易に確認できます。
このトレーサビリティ機能により、デバッグやコードレビューを効率的かつ確実に進めることが可能です。
(4) 等価性検証
実装モデルから生成した HDL コードが、元のモデルと同等の動作をしているかを確認する工程が、等価性検証です
まず、HDL コ・シミュレーションを行います。これは、モデルと生成された HDL コードに同一の入力信号を与え、両者の出力を自動比較して誤差をチェックする手法です。このとき HDL コードは HDL シミュレーター（Vivado Simulator、Questa/ModelSim、Xcelium、VCS など）上で動作するため、文法エラーや構文上の問題の検出も同時に行えます。
次に、論理合成後の実機検証として FPGA-in-the-Loop（FIL）を実施します。FIL では、PC 上で動作するモデルと FPGA 実機上の HDL 実装とを同一テストベンチで実行して比較します。
これにより、論理合成・配線後の実ハードウェア上での動作とモデルの等価性を直接確認できます。また、FIL では一部または全ての処理を PC から FPGA へオフロード実行するため、シミュレーション全体の実行速度を 数十倍程度高速化できます。その結果、検証時間を大幅に短縮できるという利点があります。検証時間が短縮されると、より多くのテストパターンを実行できるようになり、結果として品質向上にも寄与します。
このように、次の二段階の検証フローによって、モデル＝実装の等価性を確実に担保できます。
- HDL コ・シミュレーションでモデルと HDL コードの論理的一致を確認し、
- FPGA-in-the-Loop で合成後のハードウェアとの動作等価性を検証する、
なお、シミュレーション出力の比較は自動化されており、モデル出力と生成 HDL や FPGA 出力に誤差があれば自動的にアサートが発生します。
(5) コンパイル・FPGA ボード実装
HDL ワークフローアドバイザーを使用して、ターゲットとなる FPGA ボードや SoC FPGA 構成（AXI4-Stream / AXI4-Lite などのインターコネクト、外部インターフェイスなど）を選択し、それらを半自動的に接続することができます。
HDL ワークフローアドバイザーは、HDL コード生成から論理合成、ビットストリーム生成、FPGA ボードへの書き込みまでの一連の手順を簡単な操作で半自動実行できるため、個別のツール操作や設定ファイル作成といった手作業を大幅に削減します。
さらに、PS（Processing System）/ PL（Programmable Logic）間のアドレスマップや DMA 転送設定もテンプレート化されており、設計者は必要なパラメータを選択するだけで、SoC FPGA ボードの初期立ち上げを短期間で完了できます。これにより、ボード実装段階で発生しがちなインターフェイス設定ミスやデバッグ工数を最小化し、「動く実機」へ最短経路で到達できるワークフローが実現します。
(6) 実機デバッグ
実機検証の段階では、AXI Manager と FPGA Data Capture を活用して、FPGA 上の動作をリアルタイムに観測・解析します。
AXI Manager を使うと、FPGA の AXI レジスタを経由してパラメータの変更や状態の読み出しを PC から直接行うことができます。
また、FPGA Data Capture は、FPGA 内部の信号を指定したトリガ条件でキャプチャし、波形として MATLAB／Simulink 側で可視化できます。これにより、FPGA 内部の処理結果をモニターし、エラーの要因やタイミングのズレをすばやく特定することができます。
この過程で問題が見つかった場合は、モデルを修正し、HDL コード生成 ⇒ 実装 ⇒検証のサイクルを迅速に反復することができます。この繰り返しループにより、モデル・コード・実機の一貫性を保ちながら開発を加速できるのが、MBD ワークフローの大きな強みです。
キーポイント
機能モデルの作成
HDLコードや後述する実装モデル作成から始めるほうが、手間が少なくてベターと考える人もいるかもしれませんが、実装に縛られずに機能やアルゴリズムにフォーカスしてモデルを作成して検証しておくことが後々の手戻り削減のキーポイントとなります。
実装モデルのテストモデルを再利用した HDL や FPGA の等価性検証
等価性検証機能「HDL コ・シミュレーション」および「FPGA-in-the-Loop」では元モデルのテスト信号が継承されて自動的にモデルが生成されます。検証用のテストベンチを作成する場面でも工数を削減できる1度で2度美味しいワークフローなのです。
HDL ワークフローアドバイザーとリファレンス設計
モデルでは、実際の FPGA ボードにあるインターフェイスは抽象化されます。そうすることで、詳細なハードウェア設計と機能シミュレーションとを分離できます。リファレンス設計は、特定ボードや用途向けのテンプレートをまとめたファイル群です。ボード上で必要なインターフェイス・制約・IP 構成が最初から整っていて、それにユーザデザインを追加すれば、すぐに動きます。ボード固有の下回りをゼロから作らなくて良いので、再現性高く早期立ち上げができるようになります。
実機デバッグ
ボードに実装できたらモデルの期待値と実機のふるまいを突き合わせて検証する段階です。ここでは HDLワークフローアドバイザー実行時に、AXI Manager と FPGA Data Capture 機能を有効にしておいて、（1）制御レジスタの Read / Write と （2）内部信号の波形取得を素早く回します。
AXI Manager：PC から JTAG / Ethernet 経由で AXI4-Lite レジスタに直接アクセスします。ゲイン、しきい値、モード切替などパラメータのオンザフライ変更、状態レジスタの読み出し、メモリ領域の確認がコマンド実行で即時に行えます。MATLAB スクリプト化できるので、再現性のあるテストを実施できます。
FPGA Data Capture：PL 内部の任意信号をトリガ条件でロギングし、ブロック RAM または DDR メモリに一時保存します。取得後 PC に吸い上げで波形（時系列データ）として可視化・解析を行います。
AXI Manager＝その場で弄れるスパナ、FPGA Data Capture＝FPGA の内部を見る内視鏡のように、FPGA デバッグの場面で頼りになります。
まとめ
モデルベースデザインのコンセプトはシンプルです。「仕様をモデルで保証し、工数を上流で削減する」これが基本思想です。
実行可能な機能モデルを用いることで要件・機能・性能を可視化し、固定小数点化による演算誤差を数値基準で詰めることができます。実装モデルから等価なHDLコードを自動生成し、 HDL ワークフローアドバイザー＋リファレンス設計を活用して、自分のデザインを “テンプレート” にはめ込むように実装を進めます。さらに、等価性検証やデバッグ機能を使えば、モデルと実機の差分やエラーを即時に確認し、潰すことができます。
これらを一連のワークフローとして運用することで、属人化や解釈の違いによるギャップが減り、実機テストの試行回数を最小化できます。その結果、TAT は着実に短縮されます。
ここまでお読みいただき、ありがとうございました。次回以降では、信号処理や画像処理アルゴリズムの実装例について触れる予定です。
あなたが生成 AI には真似できない、 “独自性のある高度な技術で付加価値を生み出す” エンジニアとして活躍することを心よりお祈りしています。
MathWorks Japan 松本 充史