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

[Ron Wilson，EDN]

ハードウエア合成

　Synopsys社のバーチャルプロトタイプでのESLの利用法を、もう一歩進めることが期待される。バーチャルプロトタイプのデバッグを経験すると、実行ボタンを押すだけで、SystemCのモデルからRTLコードやネットリストが合成されることの素晴らしさを感じられるはずだからである。多くの設計者は、そのような状況の実現がESL設計の将来的な目標であると認識するだろう。しかし、実はいくつかの設計チームでは、すでにある種の構造の設計においてそうしたアプローチを実際に利用している。

　その一例が東芝（東芝情報システム）の最近のプロジェクトである。同社の大黒昭宜氏らによると、そのプロジェクトは固有値分解エンジンをC言語ソースから構成しようとするものである（固有値は線形関数に関連するスカラー値の組み合わせである）。大黒氏らのチームは、自動車における衝突防止用レーダーの処理に固有値分解を利用することを考えていた。この固有値分解法は画像認識アルゴリズムとして強力であるが、計算の負荷が大きいという問題があった。

　この開発に当たって、大黒氏のチームは、まず、CatapultCでアルゴリズムを記述し、3種類の数値計算法を比較検討した。大黒氏らは、使用言語の選択に当たって、飽和演算を含む整数演算などの数学ライブラリが充実していることを重視した。こうしたライブラリがなければ、アルゴリズムの開発よりも数値計算のコーディングに時間を取られてしまうからである。

　大黒氏らは、米Mentor Graphics社の合成ツールを使用し、CatapultCコードにアーキテクチャ上の制限を加え、その結果を用いてRTLコードを合成した。大黒氏らは、「アルゴリズムとアーキテクチャ上の制限を分離できることが重要だ。さもなければ、それらが絡み合ってしまうため、実装条件に合わせてアルゴリズムのソースコードを修正しなければならなくなる」と語っている。

　大黒氏らのチームは、RTLコードのチェックは簡単に済ませ、直ちにFPGAに実装した。FPGAでは、実際にレーダーで取得したデータを入力信号としてアルゴリズムの動作を検証した。

　C言語によるデータパスの合成はかなり前から行われており、同プロジェクトの成功は必ずしも驚かされることではない。とはいえ、データパス内の数値演算ロジックやレジスタなどだけでなく、今ではさらに複雑な機能も合成できるということには注目すべきだろう。

　ESL合成に付きまとっていた課題の一つは、通常のRTL設計と同様に、初期化の過程にかかわる問題であった。シミュレーションのときだけ用いるデータパスが生成されてしまうということが珍しくないのである。大黒氏によれば、「当社が適用している設計フローには自動リセット機能があり、それによりRTLに対する初期化シーケンスが正しく生成される」という。

　この例のようなESL合成であれば、これまでにも利用する価値があったのではないだろうか。大黒氏の見積もりによると、従来の手法だと6カ月要するところが、ESL合成の結果を実装したFPGAの利用によって、必要な情報が1カ月で得られるようになったという。

SoC合成への展開

　機能ブロック単体の合成もSoC全体の合成に向けての大きなステップになるが、設計チームとしてはそのステップに入る前に、まずはSoCを構成するいくつものブロックの相互関係を十分に理解しておく必要がある。

　ところが、多くの場合、そうした時間が十分でない状態でRTL設計を始めなければならないという状況にある。この種の問題は、例えば、先進的手法を先導しているスイスSTMicroelectronics社の設計チームもマルチメディアデータを多用するSoCを開発する過程で経験している。同社システム設計部門長であるPascal Urard氏は、「われわれの目標はアルゴリズム開発から実装までの全過程を自動化することだ。この目標に向けて、C++コードからRTLコードを生成するためのツールを選択し、それらをSynopsys社の通常の合成フローと組み合わせることにした」と述べている。

　その設計プロセスは、C++によって新規の機能を記述することから始める。この段階で、チップに必要な機能とともに、各ブロックの処理速度や遅延、消費電力などを見積もる。また、ハードウエアとソフトウエアの機能分割も行う。

　アーキテクチャ設計者の多くは、少なくとも理論的な観点からは、機能分割は可能な限り設計プロセスの後半に行うべきだと主張する。しかし、「現状、利用可能なツールを前提とした場合、この観点は実際的ではない。システムレベルから見ても、ハードウエアを対象とするのとソフトウエアを対象とするのとでは、適用するアルゴリズムが異なるだろう。従って、対象とするのはハードウエアなのか、それともソフトウエアなのかという選択は早期に行うべきだ」（Urard氏）という。

　電力の見積もりも重要な問題である。Urard氏は、「初期の段階における電力の見積もりは、最終的なチップでの消費電力の値の±20％以内という驚くほど正確な値になる。このことは、高速信号線が多数存在するような設計でも成立する。通常、見積もりのほうが最終結果よりも良い値になる。重要なのは、電力を消費する要因が正確に見極められることだ」と述べる。

　Urard氏は、「ESLによる見積もりは容易ではないが、さらに進歩するだろう」と予測している。今後は、能動的でダイナミックな電力管理技術として多電源化や多モード化が進むことは間違いなく、正確な電力見積もりのためにはブロックやセルライブラリなど低位レベルの情報を利用することが必要になるだろう。

　STMicroelectronics社の設計フローは、性能の見積もりとシステムレベルでの最適化を行った後、Mentor社のツール類を利用した合成の段階に移行する。Urard氏は、今日のESLにおける合成はコントロール回路よりもデータパスに対してより良い結果が出ることを認める。

　しかし、同氏はこれを大きな問題だとは考えていない。同氏は「SoCでは、データパスこそが主要な課題だ」としつつ、「コントロール回路のロジックの大半はアルゴリズム内に埋め込まれているため合成可能だ。さらに、コントロール回路のロジックも標準インターフェース用のものならば既存のツールにより合成できる。このようなことから、実際的な課題は、アルゴリズムに埋め込まれておらず、しかも標準的なインターフェースプロトコル以外の部分のコントロールロジックを合成することだ」と語っている。

　合成のプロセスには、そのほかにもいくつかの問題点がある。1つは、合成のプロセスがコーディングスタイルからの影響を受けることである。「C++による記述に小さな変更を加えると、RTLのコードに大きな変化が生じることがある」とUrard氏は指摘する。「そのため、合成に適したコーディングを習得しておかなければならない。ソフトウエア的に書くのではなく、MATLABで記述するのと似たようなコードを書くことになる。幸い、われわれは数年間もこうした経験を重ねてきた。その過程で、新人の技術者であっても、1つのプロジェクトを経験すればRTL合成において効果的なコーディングを習得できるようになった」と同氏は語っている。

　さらに、Urard氏は「同様な状況はRTL設計の初期にもあったことだ。当時を振り返ると、コードに乗算記号を使うことはなかったはずだ。適切なネットリストを生成するには、RTLでは加算とシフトで書く必要があった。今日のESLでも同様だ。合成ツールがどのように働くかを理解し、それに対応したコーディングを行わなければならないのだ」と指摘する。

　合成の次に行う検証過程にも問題は存在する。STMicroelectronics社の設計フローでは、検証ステップはC++記述とRTL記述の形式等価性を可能な限り詳細に検証する。問題となるのは、合成用C++コードを記述した設計者自身が形式等価判定ツール用の制約ファイルを作成しなければならないことである。

　検証自体にもいくつかの問題がある。Urard氏によれば、1つは形式等価判定ツールに付きまとっている問題、つまり容量の問題である。Urard氏は「われわれが行わなければならないのは大規模なIPブロックに対する検証だ。そのため、より大容量のデータに対応可能なツールを常に探している」と語っている。

　もう1つの問題はより難しい。形式等価証明はC++設計とRTL設計が機能的に等価であることは証明できるが、タイミング性能については検証できない。そのため、この段階からタイミングモデルを使用する従来法での検証に移らざるを得ないのである。

　設計フローは期待どおりであったか、という問いに対して、Urard氏は「当社は今後もESL合成を前進させる予定であり、後退させる考えはない。この設計フローはRTL設計に比較して生産性を4〜5倍向上できると評価するからだ」と述べた。

---

　本稿で紹介した多くの設計チームの経験から見れば、ESLはもはや実際の設計環境において、経験豊かな設計者を有するならば、ある程度までIPブロック全体の合成が可能なレベルまで確立してきたと言えるだろう。ESLツールはもはや“マジックボタン”を待つ業界の夢ではない。すでに現実のものとなり、ESLの講習会などは習得を希望する多くの技術者で活況を呈している。多くの設計チームにとって、ESLはもはや明日に得られるだろう解ではなく、実用的なツールなのである。