システム開発にもエミュレータ――ソフト/ハードの並行開発を実現（1/2 ページ）

これまで設計実装の最終段階のデバッグやリグレッションテストのためだけに使用されていたエミュレータが、システムの構築においても有用なツールとなりつつある。

[Gabe Moretti（米GABEonEDA社），EDN]

　最先端のLSIを設計するエンジニアはいくつもの困難な課題に直面する。特殊なDFM（design for manufacturing）手法やツールが必要となるようなチップ上の複雑な物理現象に対処しなければならないし、LSIの論理設計を計画、開発、検証する際の構造および集積方法に関する要求への対応も求められる。

　今日のエレクトロニクス市場において、最も活気のある分野は、民生機器と通信機器だろう。これらの製品の市場における平均寿命は1年未満といわれており、競争は非常に激しい。さらに、価格に極めて敏感なため、利益率は低くなる傾向がある。このような市場で成功するには、企業は開発時間を短縮し、開発および製造コストを削減しなければならない。その結果、最先端LSI、つまりSoC（system on chip）の平均開発期間は9カ月となったが、かつてその2倍の開発期間を費やしていた回路よりも構造はさらに複雑である。

　設計期間を短縮するために企業がとった手法の1つが、機能ブロックの再利用である。これによってEDA産業に新たなセグメントが誕生した。サードパーティが設計した機能ブロックを扱う事業である。この市場セグメントには、「IP」（intellectual property）という略語がつけられているが、「IP」は“internet protocol”を指して使用されることの方が多く、同じ略語がついてしまったのは残念だったといえる。

SoC設計における課題

　SoCデバイスでは、マイクロプロセッサ、1つ以上のDSP、1つ以上のインテリジェント・コントローラ、メモリー、組み込みソフトウエア、1つ以上の高速バスを、単一のチップ上に集積することが多い。そしてそのほとんどの場合において、機能ブロックの一部をサードパーティが、通常はハードマクロの形式で提供する。ハードマクロはブラックボックス回路である。マクロを違法な複製から保護するため、ベンダーは、内部アーキテクチャについては明かさずに、回路の機能とそれが使用するI/Oプロトコルのみを提示する。

　これらのIPブロックが、システム開発者にとっては悩みの種だ。なぜなら、ベンダーは設計情報を保護するため、デバイスのTLM（transaction level model）のみを提供することが多いからである。IPとそれを取り巻くシステムとの間のインターフェース・プロトコルを検証するだけであればこのモデルで十分だが、正確なタイミング情報を得ることはできず、I/Oプロトコルが正しく見えても実際のデータに誤りが潜んでいる可能性がある。また、開発者が使用するシミュレーションモデルには、ベンダーが検出できなかったバグが残っているかもしれない。

　新製品の設計において、設計者はまず、必要な機能を列挙していく。そして製品を機能ブロックに分割し、それをハードウエアまたはソフトウエアで実装する。設計者はハードウエアブロックを一から製作するか、内部的に開発されたブロックを再利用するか、またはサードパーティIPを使用することになる。サードパーティのIPを使用する場合には、それを評価しなければならない。評価するには検証と確認のためのテストベンチを開発する必要がある。そしてさらに、検証の結果を評価しなければならない。これらの作業には膨大な時間がかかる。IPブロックを評価するための手段がシミュレーションモデルだけだとすると、モデルとテストベンチのどちらにもエラーが存在する可能性があるので、その結果がIPの実際の動作を反映しているかどうかはわからない。

　EDAベンダーは、モデルの抽象度を上げることで、詳細な実装を始める前に種々のシステム構築ブロック間の相互作用をシミュレーションできるような、新しいツール群を提供している。ESL（electronic system level）を最初に提案した人たちは、ソフトウエア設計者が使用するものと同様の言語を用いて、システム開発者もより効率的にハードウエア/ソフトウエアのトレードオフを解析できるようになるだろうと予測していた。残念ながら、この予測は半分しか当たらなかった。DFMを考察する際には、ソフトウエアブロックの消費電力を、抽象プロセッサモデルを用いる場合よりも正確に見積もることを求められることが多い。正確な実行データを使って最良のアーキテクチャ構成を選択できるように、ソフトウエア設計者は、開発サイクルのできるだけ早い段階でプログラムを実行する必要がある。

　アーキテクチャが決定すると、ハードウエアおよびソフトウエアの開発が始まる。理想的にはこれらのプロセスが並列に実行されることが望ましいが、実際にはソフトウエアを実行するハードウエアが完成するまで、ソフトウエア開発を進めることはできない。本質的にこれら2つのプロセスは逐次的なので、プロセッサのTLMを提供するISS（instruction set simulator）を販売するEDAベンダーもある。ソフトウエア設計者は、コードがアルゴリズム通りに動作しているかを確認するためにこのモデルを使用するのだが、ISSを用いたリアルタイム・ソフトウエアを検証することはできない。モデルのタイミングが正確ではないからだ。ISSモデルは作成にコストがかかるため、よく使用されている組み込みプロセッサに対してのみISSを利用できる。

　開発中に、設計者はさまざまな抽象度の機能ブロックを用いてシステムをシミュレーションする必要がある。アルゴリズムレベルでしか記述できないブロックもあるが、その他のブロックの開発はRTL（register transfer level）へと進み、合成のための準備が行われる。論理シミュレータを用いて、RTLブロックを多く含む設計を検証する作業には、時間もコストもかかる。ソフトウエア実装の検証にRTLブロックを使用すると、論理シミュレーションの実行速度は非常に遅くなってしまい、もはやこの手法は現実的なものとはいえなくなる。