改訂版EDA用語辞典とは・著者一覧

 ハードウェア・ソフトウェア協調設計(hardware software co-design,以下ハード・ソフト協調設計)とは,ハードウェア部とソフトウェア部からなるシステムの設計手法である。両部の設計を連携させながら,かつ同時並行的に進める。従来は,ハードウェア部とソフトウェア部は別々に設計し,最後に統合するのが一般的だった。ハード・ソフト協調設することで,従来手法に比べて,性能やコストの最適化が図りやすくなる。

 なお,ハード・ソフト協調設計のハードウェア部とはASIC(application specific integrated circuit)やFPGA(field programmable gate array)などで実現する論理回路を,またソフトウェア部はマイクロプロセサ(MPU:micro processing unit)やDSP(digital signal processor)などで実行されるプログラムのことを言う。

登場には二つの背景

 従来手法に代ってハード・ソフト協調設計が注目されるようになった背景として,次の二つが挙げられる。

 一つは,半導体製造技術の進歩により,「これまで複数のLSIで構成されていたシステムが一つのチップ上に実現できるようになった」ことである。いわゆる,SoC(system on a chip)が登場した。

 SoCは回路規模が大きく,かつ複雑な構成になっていることが多い。このため,設計と検証の期間が延びがちである。設計の後段で不具合が見つかると,非常に大きな問題になる。設計の早い段階で,大きな不具合がないことを確認することが重要になっている。

 ハード・ソフト協調設計が注目されるようになったもう一つの理由は,「ハードウェア部とソフトウェア部の関係が密接になった」ことである。例えば,SoCでは,ハードウェア部とソフトウェア部が密に連携して,ひとまとまりのデータ処理を行うことが多い。両部を別々に開発したり検証することは,現実的ではない。

 これらの二つの背景に加えて,電子機器(セット)の開発サイクルが短くなっていることもある。従来に比べて,短期間で確実な開発が求められている。それに応えるのが,ハード・ソフト協調設計である。

三つの段階がある

 ハード・ソフト協調設計は,大きく分けて次のような三つの段階を経て進められる。すなわち,(1)システムの仕様や機能を決定する段階,(2)システムの各機能をハードウェア部とソフトウェア部に分割し,資源(リソース)を割り付ける段階,(3)システムのハードウェア部とソフトウェア部の設計をある程度進めて,両部の統合検証をする段階,である。以下にそれぞれを概説する。

 (1)の「システムの仕様や機能を決定する段階」では,ハードウェア部とソフトウェア部からなるシステムの機能を記述し,そのシステムが想定通りになるかどうかを検証する。この段階でシステムを記述する際には,あまり詳細には触れない。

 例えば,「入出力だけ」など,システムの一部の動作のみを記述する。これを「抽象化モデル」と呼ぶ。抽象化モデルの記述には,C言語/C++,あるいはこれらをベースとしたシステム・レベル記述言語が使われる。

 (2)の「システムの各機能をハードウェア部とソフトウェア部に分割し,資源を割り付ける段階」では,各機能をハードウェア部として実現するか,あるいはソフトウェア部として実現するかを決定し(ハード・ソフト分割)し,ソフトウェア部を実現するMPUやDSPを選択する。さらに,ハードウェア部とソフトウェア部(実際には,MPUやDSP)間の通信や,ハードウェア部同士の通信に使うバスの構成もここで決める。

 このハード・ソフト分割とバス構成を含む,資源の割り付けが,システム全体の性能やコストに大きな影響を与える。ただし,現在の技術レベルでは,各機能をハードウェア部,ソフトウェア部で実行したときの処理性能やチップ・コスト(チップ面積),消費電力,開発コスト,変更容易性,など多くの要因を,この段階で見積ることが難しいという課題がある。

 なお,この段階でMPUやDSPが決まるため,実機に即したソフトウェア開発を始められる。いわゆる,「ハードウェア完成前にソフトウェアの先行開発」が実現する。

 (3)の「両部の設計と統合検証」の段階では,ハードウェア部,ソフトウェア部の設計を,詳細設計の一歩手前まで進める。そして,両部の統合検証をクロック・サイクル精度で行う。一般に,この段階では,ハードウェア部は,論理合成可能なRTL(register transfer level)記述となる。記述には,HDL(hardware description language)を使う。一方ソフトウェア部は,使う予定のMPUやDSP向けにコンパイルできるような記述となる。

 そして,ハードウェア部のデータは論理シミュレータで,ソフトウェア部はMPUやDSPのISS(instruction set simulator)で稼働させる。両シミュレータは協調して,すなわち互いにデータをやりとりしながら,動作する。この検証は,ハード・ソフト協調検証(hardware software co-verification)と呼ばれる。

進化は高速化の歴史

 次に,上述した三つの段階の技術レベルと課題について説明する。三つの中で,最も実用化が進んでいるのは,(3)の段階で紹介した,ハード・ソフト協調検証である。

 ハード・ソフト協調検証の進歩は,高速化の歴史とも言える。例えば,かつては,ソフトウェア部もハードウェア部と同程度の詳細なモデル(記述)となっていた。しかし,これでは遅いため,命令単位にシミュレーションを進めるISSを使うようになった。論理シミュレータとISSの組み合わせは,ハードウェア設計者がHDL記述を確認する格好の手段として定着した。またISSにはソフトウェア用のデバガが付属していることが多く,ISSの利用はソフトウェア設計者にも都合が良い。

 最近ではソフトウェアの規模が大きくなってきたため,ソフトウェア部ではISSよりもさらに高速なモデルを採用したり(後述),ハードウェア部ではハードウェア・アクセラレータや論理エミュレータを使うようになった。

TLMがEDAツールに

 このような(3)の段階での検証高速化に加えて,その検証をもっと前の段階,すなわち(1)や(2)の段階で実施する試みがある。(1)や(2)は(3)に比べて設計の抽象度が高いことから,検証速度の向上が期待できる。

 例えば,(2)の段階に対しては,ハードウェア部にTLM(transaction level modeling)技術を適用する試みがある。その具体例として,SystemCの管理団体のOSCI(Open SystemC Initiative)が策定した,SystemCの「TLM2.0」仕様が挙げられる。

 TLMはRTLより高い度抽象度で,バスなどデータ通信/データ転送に関連した設計の検証の高速化に効く。TLM2.0をサポートするEDAベンダーが増えており,バス構造の性能解析の高速化や,ソフトウェアの先行開発の実現などが促進されている。なお,現在のTLMでは,モデリング・スタイルの標準化やライブラリの充実が課題である。

 またソフトウェア部では,ISSを高速化する技術が提案されている。例えば,シミュレータが稼働するプロセサのコードに,検証対象のソフトウェアのコードを置き換える技術(ネイティブ・コード化)や,ジャスト・イン・タイム・コンパイル方式で高速化する技術などがある。

機能記述にもSystemC

 (1)の段階でも,システムの機能記述にSystemCを使う動きがある。これで,アルゴリズムが早期に検証できるようになる。重大な誤りがこの段階で除去できれば,設計期間全体の短縮に大きな効果がある。ただし,このSystemC記述から各機能ブロックの演算量や機能ブロック間の通信量などを見積って,(2)の段階の「ハード・ソフト分割」を自動化することはできていない。

 一方で(1)の段階に向けては,独自のシステム・レベル設計言語を使うESL(electronic system level)ツールが登場し始めている。その独自の言語を使ってシステムを記述すれば,ハード・ソフトの自動分割や,資源の自動割り付けが可能である。これらの記述方法が標準化されたり,ESLツールが広く一般に使えるようになるのが今後期待される。