アプリケーションプロセッサコアとプログラマブルロジック部を1個のICに集積したプログラマブルSoC。注目を集めるプログラマブルSoCを用いた製品開発に最適なのが、「MATLAB/Simulink」によるモデルベースデザインである。ブロック線図で記述するSimulinkモデルだけでも、プログラマブルSoCの評価ボードへの実装コードが生成できるだけでなく、プログラム言語の違いによって生まれていたソフトウェアとハードウェアのエンジニアの間の相克を、Simulinkモデルという共通言語で解消することも可能になるのだ。

» 2014年03月13日 10時00分公開

[PR／MONOist]

　現在注目されているICカテゴリーの1つにプログラマブルSoCがある。ARMのアプリケーションプロセッサコア「Cortex-A9」と、周辺機能や入出力機能をFPGAのように再構成できるプログラマブルロジック部を集積したもので、代表的な製品にはXilinxの「Zynq」やAlteraの「SoC FPGA」がある。

　このプログラマブルSoCに、MathWorksのモデルベースデザイン環境「MATLAB/Simulink」が2013年9月発表のリリース2013b（R2013b）から対応した。プログラマブルSoCは、従来の製品開発で使っていたプロセッサとFPGAという2種類の個別ICの機能を1個に集積しているのでプリント基板を小型化できる他、開発効率の向上が可能な点も特徴となっている。MATLAB/SimulinkがR2013bでプログラマブルSoCに対応したのは、この開発効率向上の効果をモデルベースデザインによって最大化するためだ。

プログラマブルSoCの開発プロセスのイメージ。システムモデルを、プロセッサ上で動作させるソフトウェアモデルと、FPGAなどのハードウェア上で動作させるハードウェアモデルに切り分け、各モデルから組み込みソフトウェア向けCコードとHDLコードを生成する。「MATLAB/Simulink」では、R2013bから、両者の間をつなぐAXI4に準拠したバスインタフェースのコードを自動で組み込む機能が追加された

Simulinkモデルが共通言語になる

　プログラマブルSoCの開発にMATLAB/Simulinkを利用する際の最大のメリットとは何か。それは、ブロック線図で記述するSimulinkモデルが、使用するプログラム言語の違いによって生まれていたソフトウェアエンジニアとハードウェアエンジニアの間の相克を解消する共通言語になるところにある。

　この相克から発生していた最大の問題が、両者の開発成果を評価ボード上に実装して行う統合テストが最終段階でしか実行できていなかったことだ。共通言語のない中で両者が開発したものをいきなり統合／実装しても、なかなか思い通りの動作をさせることができない。その不具合を解決するための手戻りによって、開発効率はどうしても低下してしまう。

　しかし、MATLAB/Simulinkを用いたプログラマブルSoCの開発環境であれば、Simulinkモデルが両者の共通言語になる。例えば、ソフトウェアエンジニアの方で、ハードウェアエンジニアが開発中のプログラマブルロジック部を含めたハードウェアのSimulinkモデルを使って、早い段階からの統合テストや組み込みソフトウェアの手直しを行えるのだ。手戻りが起こりにくくなるので、飛躍的に開発効率が向上する。

　プログラマブルSoCを用いた製品開発では、プロセッサとプログラマブルロジック部のどちらに何を処理させるかといった製品の仕様に合わせた最適なバランスをとる作業に、限られたエンジニアのリソースを割くべきである。MATLAB/Simulinkによるモデルベースデザイン環境であれば、それを容易に実現できる。

プロセッサとFPGAを用いた製品の開発は2つのチームで進められる

　それでは、MATLAB/SimulinkのプログラマブルSoCへの対応がどのようなものかを説明する前に、現在のプロセッサとFPGAを使った製品開発について紹介しておこう。

　プロセッサとFPGAを用いる製品の開発は、大まかに分けて2つのチームで進められる。1つは、プロセッサ上で動作させる組み込みソフトウェアの開発チームである。主にソフトウェアエンジニアが担当し、プログラム言語にはC言語などを用いている。もう1つは、FPGAをはじめとするハードウェアを設計する開発チームだ。主にハードウェアエンジニアが担当しており、FPGAに実装する回路を記述するためにハードウェア記述言語（HDL）を用いている。

　これら2つのチームは、製品仕様を基に別々の環境で開発を進める。組み込みソフトウェアとハードウェアの最終的なすり合わせは、実機を使った統合テストで実施されることがほとんど。このため統合テストで不具合が起ると手戻りが発生し、開発が遅延することも多かった。

　特に、最終的なすり合わせの際のボトルネックとなっていたのが、プロセッサとFPGAをつなぐバスインタフェースである。製品仕様に求められるさまざまなバスインタフェースに合わせて、組み込みソフトウェアとハードウェアをそれぞれ対応させなければならず、その分だけ手間が掛かるため、実機を使った統合テストで不具合が出る可能性も高い。

　これに対して、プログラマブルSoCでは、プロセッサとFPGAをつなぐバスインタフェースはARMの内部通信バスインタフェース規格であるAXI4に統一されている。これによって今までのボトルネックが解決されるので開発効率を向上できるというわけだ。

「Embedded Coder」と「HDL Coder」

　R2013b 以降のMATLAB/Simulinkを使えば、プログラマブルSoCを用いた製品開発をモデルベースで行えるようになるとともに、プロセッサとFPGAのバスインタフェースがAXI4に統一されることによる開発効率向上の効果をさらに高められる。

　MATLAB/Simulinkを用いたプログラマブルSoCのモデルベースデザインには、2つのオプションツールが必要になる。1つは、既に多くのユーザーが利用している、MATLABコードやSimulinkモデルから組み込みソフトウェア向けのCコードを自動生成する「Embedded Coder」。もう1つは、同じくMATLABコードやSimulinkモデルなどからHDLコードを自動生成する「HDL Coder」だ。

　1994年発表の「Real-Time Workshop」から派生した「Embedded Coder」は、自動車のエンジン制御などをつかさどるECU（電子制御ユニット）に組み込む車載ソフトウェアの開発ではデファクトスタンドードとなっている、Cコードを生成するオプションツールだ。ROM／RAMサイズがコンパクトなコードを生成するので、技術者の熟練度に関わらず効率的な実装を行うことができることを特徴としている。

　また、生成するCコードは、ANSI-C／ISO-C／GNU-C準拠といったターゲットに依存しないコードだけでなく、コード置換ライブラリ機能を使用すれば、ARMの「Cortex-M／R／A」やTexas Instrumentsの「C28x／C64x」といった特定のプロセッサコア向けの専用コードを生成できる。このため、実行パフォーマンスを大幅に向上させることも可能だ。

　さらに。「Eclipse」やGreen Hills Softwareの「MULTI」などの組み込み開発環境と連携し、デバッグやビルドの作業を自動化できる。プログラマブルSoCに実装する際にも、FPGAベンダーが提供するコンパイラをキックして、生成したコードを自動的にビルドし、プロセッサコアであるCortex-A9にダウンロードしてくれる。

　一方、2006年発表のHDL Coderは、熟練技術者でなければ難しいHDLコードのコーディングを、ブロック線図で作成するSimulinkモデルなどから自動で行えることもあって急速にユーザー数が拡大しているオプションツールだ。また、FPGAの実装設計で最も手間が掛かる、プログラマブルロジックのクロック周波数（速度）とリソース（面積）のバランス取りを容易に行える点でも高い評価を得ている。

　例えば、時分割共有で演算器の回路面積を減らしたり、パイプラインレジスタを挿入してクロック周波数を向上したりといった最適化をGUIで設定してコードを生成できる。もし、これらの変更を手入力で行うのであれば1週間はかかるという。また、1つのモデルについて、パラメータ設定を変更するだけで、速度／面積のトレードオフの探索を短時間で実行できるのだ。

SimulinkモデルからのHDLコードの速度／面積最適化（クリックで拡大）

HDLコードの速度／面積のトレードオフを短時間で探索できる（クリックで拡大）

　HDL Coderの導入で、通信機器の信号処理回路をFPGAに実装する際の開発期間を大幅に削減したのが、日立製作所の情報・通信システム社と日立情報通信エンジニアリングだ。何と、HDL Coderの導入によって開発期間を70％も削減できたという。

AXI4バスインタフェースのコードを自動生成

　従来のプロセッサとFPGAを用いた製品開発でも、プロセッサ上で動作する組み込みソフトウェアをEmbedded Coderで、FPGAに実装する回路のHDLコードをHDL Coderで、それぞれ生成することはできた。しかし、これらの組み込みソフトウェアとHDLコードには、プロセッサとFPGAをつなぐバスインタフェースに関わるコードは含まれていない。このため、実際に評価ボードを動作させるには手入力による修正作業が必要だった。

　先述した通り、プログラマブルSoCのバスインタフェースはAXI4である。そこで、MATLAB/SimulinkはR2013bから、Embedded Coderで生成する組み込みソフトウェアとHDL Coderで生成するHDLコードに、両者の間をつなぐAXI4に準拠したバスインタフェースのコードを自動で組み込む機能を追加したのだ。

　R2013bでプログラマブルSoCに対応したといっても、特別なオプションツールが追加されたわけではない。まずはHDL Coderで、プログラマブルロジック部のHDLコードを生成する。このとき、プログラマブルロジック部のピン情報（アドレスマップ）に対応して生成されるソフトウェアインタフェースモデルをEmbedded Coderに引き継げば、プログラマブルロジック部のピン情報に対応したAXI4バスインタフェースのコードを持つ組み込みソフトウェアを生成できる。

　そしてこれらのコードを、プログラマブルSoCの開発環境（XilinxのZynqであれば「ISE」、AlteraのSoC FPGAであれば「Quartus II」）でコンパイルすれば、プログラマブルSoCにそのまま実装できる。つまりハンドコーディングなしので開発も可能になるのである。

　また、ただ単にプログラマブルSoCに実装するだけではなく、Simulinkが動作しているPCとプログラマブルSoCの評価ボードをイーサネットで接続し、Simulinkモデル上でチューニングしたパラメータの信号波形をリアルタイムでモニタリングできる「エクスターナルモード」も利用できる。エクスターナルモードは、Simulinkモデル上でプログラマブルSoCの最適化作業を行える画期的な機能といえるだろう。

「エクスターナルモード」は、信号波形をリアルタイムでモニタリングしながら、Simulinkモデル上でパラメータをチューニングできる

　なお、現時点でMATLAB/Simulinkが対応しているプログラマブルSoCは、一般向けに評価ボードの供給が始まっているXilinxのZynqだけだ。対応OSについても、Zynqの評価ボードに用いられている組み込みLinuxに限られている。ただし、MathWorksによれば、AlteraのSoC FPGAや、その他の組み込みOSにも順次対応していく方針である。