ESL設計の現状、その可能性：複雑化するSoC設計の救世主となれるか（2/4 ページ）

[Ron Wilson，EDN]

ESLでのアルゴリズム開発

　上述したようなさまざまなアプローチや期待、あるいはニーズが存在するが故に、混乱が生じていることも確かである。状況を明確にするには、さまざまなレベルでツールを実際に使用している設計者に語ってもらうのが最良であろう。

　特にデジタル信号処理の分野では、正確なアルゴリズムの構築が設計上の主要な課題である。この課題に対処するには少なくとも2つのステップを要する。まず初めに、正しい数式を得ること、次にその数式をハードウエア/ソフトウエアとして正しく実現することである。Smith氏が分析するように、この課題に対しては、ESLは登場初期のころから成果を出すとともに、現在も重要な位置にある。

　このような目的でESLを使用しているのが、米MC2 Technology Group社でDSP/システム設計を専門とするコンサルタントのBob Davenport氏である。同氏は、米Agilent Technologies社の「SystemVue」の愛用者である。SystemVueはブロックダイアグラム入力によって機能する開発環境であり、通信制御や信号処理の分野に向けたものとなっている。Davenport氏は、SystemVueが内蔵する機能ライブラリを利用しながらアルゴリズムを開発し、それを細かく展開してC言語のプログラムを生成し、そのプログラムを米Texas Instruments社の「Code Composer Studio」を用いて最適化するという手順を採用している。

　Davenport氏は、「例えば、PLL（Phase Locked Loop）を設計する場合、式を書くことから初め、次いでそれをモデルで表現すれば、その動作を解析可能だ。解析結果からデータが得られ、それをグラフ化すれば、報告書などにも使用することができる」と、自らの経験を語っている。

　Davenport氏が重要だと評価するSystemVueの機能は、アルゴリズムを表現する場合はビット数に制限のない浮動小数点を用いて展開できるとともに、具体的な処理を規定する場合には対象とする信号に合わせてビット数に依存する精度を設定できることである。この機能のおかげで、「例えば、GPS （Global Positioning System）の周波数領域相関器を設計する場合、まずDSPコアに組み込むべきアルゴリズムを求め、次に実装に適するようにデータ幅を制限すればよい」（同氏）という。同氏の場合、データ幅の制限を単に固定小数点化により実現することもある。固定小数点演算によるシミュレーション出力と本来の浮動小数点演算の結果とを比較し、両者に差異がある場合にはアルゴリズムの見直しに戻ることもあるという。

　Davenport氏は主としてDSPコア用の処理コードを設計している。SystemVueはFPGAに対するコードも生成できるため、同氏は「今後はそういった機能も活用していくようにしたい」と語っている。

バーチャルプラットフォーム

写真1　Synopsys社の設計チームが使用している開発ボード　このボードはSystemCによるトランザクションレベルでモデル化され、ハードウエア/ソフトウエアの協調設計に利用されている。

　上述したように、ESLをアルゴリズム開発向けとして利用する設計者もいるが、ハードウエア/ソフトウエアの並行開発用ツールとしてESLを利用している例もある。その状況を米Synopsys社におけるIP（Intellectual Property）開発に見てみよう。

　USBやPCI Expressのようなインターフェース用IPでは、顧客がIPのインターフェース機能を使用するためだけでなく、チップの設計チームが検証を行うためにもドライバソフトウエアが必要となる。ところが、従来のアプローチでは、ハードウエアを開発しながら、そのハードウエアを使ってドライバソフトウエアを開発し、さらに両者を使って各々の動作を検証するといったことは困難であった。

　その対策として、Synopsys社はバーチャルプロトタイプ方式を適用してきた。それにより、ハードウエアとドライバソフトウエアを並行して開発することが可能になった。同社の「DesignWare」が提供するUSB OTG（On-The-Go）のIPコアの開発プロセスについて、同社バイスプレジデント/ソリューション部門統括マネジャであるJoachim Kunkel氏および研究開発担当マネジャのJoel Gotesman氏から、以下のような説明を受けた。

　Gotesman氏によれば、同社DesignWare開発チームはハードウエア開発ボードを使って開発を始める（写真1）。同氏は「このボードはIP設計評価用として用意したものであり、DesignWareチームが広く使用しているものだ。韓国Samsung Electronics社製のARMベースCPUを搭載し、ディスプレイ、外部接続用コネクタ、FPGAベースのドーターボードから構成されている」と説明した。

　同社DesignWare開発チームは少し以前に、SystemCを用いてこの開発ボードをトランザクションレベルモデル（TLM：Transaction Level Model）としてモデル化した。このボードは、モデル構築ツールにおいては一連の機能ブロックを有するバスとして定義される。各機能ブロックは、バスで実行される一連のリーガルトランザクション（プロトコルにより規定された指令）、およびトランザクションに対応して実行される機能の集合として定義される。このモデルがソフトウエアベースのバーチャルプロトタイピング環境になる。なお、このモデルにはタイミング情報は含まれない。

　新規IPの開発もIPに対するTLMの作成から開始する。開発ボードのモデルとIPのモデルを結合し、ドーターボードに搭載したFPGAに実装する。これによりバーチャルプロトタイプが完成する。

　具体例としては、USB OTG用のIPを機能拡張し、ディスクリプタベースDMA（Direct Memory Access）をサポートできるようにするというケースがある。この設計では、開発ボードとUSB OTGのIPのバーチャルプロトタイプからスタートし、IPプロトタイプを編集して新たな機能を付与する。これによりソフトウエアによるバーチャルプロトタイプが完成し、これをドライバ開発チームに渡す。こうして、ドライバ開発は所要の機能が規定され次第、着手できることになる。

　Kunkel氏によれば、このようなプロセスによって、ハードウエア開発チームがFPGAに実装可能なレベルのRTL設計を完成させる4週間ほども前に、ソフトウエア開発チームはデバイスドライバのデバッグを完了し、実装準備を完了できるようになったという。Gotesman氏の説明によれば、RTLをFPGAに実装した時点で、開発ボードのトランザクションレベルのバーチャルプロトタイプ、新IPのRTLモデル、デバイスドライバを含む全系に対するミックスドモードシミュレーションが可能になる。なお、「この過程では、SystemCコードを編集し、詳しいタイミング情報を含める必要があった」と同氏は説明する。その後は、FPGAへのIPの実装、次いでチップのテストへと進む。

　以上のように、開発ボードのESL記述が、実質的に新IPのESL記述とRTL記述の両方に対するテストベンチとして使用されたのである。