Technology Reports 2006

動作合成はなぜチップ設計者に受け入れられなかったのか?

はじめに

 高位合成技術の意図するものは、常に設計者の生産性向上にありました。何年も前に第一世代の動作合成ツールが紹介された際には、興奮したものです。数百万ゲート規模のSoCの出現により、エンジニアはRTLにおけるアーキテクチャ検討という複雑な作業を克服するための手法を探していました。マーケティングでは高い設計レベルへの移行によるRTLの時代の終焉が叫ばれ、エンジニアが行うべきことはチップのアルゴリズム記述だけであり、残りはツールが行うようになると言われました。

 まもなく、設計者は動作合成ツールの実際の処理内容に大きな限界があることに気付き、過大な期待に対する現実が明らかになりました。基本的に、それらのツールは、ソースとなる言語コードに対して、何らかのタイミング、設計階層、並列性、およびインタフェース情報までを必要とするものでした。結果として設計者は、ソース言語と共にどんな種類の情報をどれだけ与えるべきかを理解するために、合成ツールの能力を熟知する必要がありました。過剰な情報は合成ツールの動きに制限を与え、結果、品質を低下させます。与える情報が少なすぎると、デザインが期待通りに動きません。いずれにしても、設計者が当初期待していた生産性や柔軟性を得ることはできませんでした。

初期に期待を裏切った動作合成ツール

  エンジニアが失敗を忘れることは滅多にありません。動作合成はそのデビューにおいてつまずき、その手法の初期に直面した問題が、リスクを嫌う設計チームに悪い印象を植え付けました。多くは新しい手法による試みを嫌い、従来からのRTLベース設計を継続して使用することになりました。それから時をおかず、コンピューティングと通信の集約が、3Gワイヤレス、衛星通信、ワイヤレスLAN、および映像/画像処理のような、アルゴリズム重視のアプリケーションを牽引し始めました。これらのデザインにおける極度の複雑性はRTLベースの設計フローの限界まで達し、高位合成に対する興味が再び生まれました。

(図をクリックすると拡大表示します)(図をクリックすると拡大表示します)

過去18ヶ月以内に市場投入された新しい動作合成ツールは、デザインの複雑性における解決に取り組むことを約束しました。しかし、これらのツールは、 Handel-CやSystemCといったハードウェア構造を含む言語に依存しています。残念ながら、これらの言語は、これまでの動作記述とあまり変わらないものです。言語そのものはVHDLやVerilogからSystemCやHandel-Cに変わったかも知れませんが、抽象度については従来からの動作記述と変わらないのです。これらの新しいツール群は過去のそれらに比べて良好な結果を生成しますが、基本となる動作合成技術が従来のものと変わらないため、本来の目的の達成には全く至っていません。並列性、構造、およびインタフェース等に関する重要な部分については、時間がかかり、エラーの原因となる手動作成に頼ったままです。このようなすべての理由により、これらの新しい世代のツールに対する設計者の反応も、期待を下回るものとなりました。

市場に対してはつまずいてしまった動作合成ですが、新しく、より高いレベルの合成手法による試みは実を結び始めました。アルゴリズムベースの合成として知られる手法は、シーケンシャルなC++記述を用い、アルゴリズム・レベルでの合成を提供するという点で従来の動作合成より優れています。入力にシーケンシャルなC++を用いることで、Catapult Cのようなアルゴリズムベースの合成ツールでは、システム・レベルのモデルからハードウェア実装までの間で、これまで手動で行われてきたハードウェア記述作業のほとんどを自動化できるパスを提供します。CおよびC++はANSI(American National Standards Institute)で規定された国際標準という付加価値をともない、おそらくは世界で最も幅広く使用されているモデリング言語と言えます。CやC++によるアルゴリズムベース合成の要件は、ハードウェアの設計要件を満足する詳細な要素(並列性、インタフェース、構造等)を元のアルゴリズムに反映しながら、機能的に等価なRTLを生成するという単純なものです。ただし、高い品質のハードウェアを生成するアルゴリズムベース合成技術を実際に開発することは非常に難しく、毎年50人から100人の開発者を割り当てなくてはいけません。一般的に、これは多くの企業の投資能力を上回るものです。この莫大な投資を考えれば、過去18ヶ月に市場投入されたツールのほとんどが、古い技術の焼き直しである理由が理解できます。

アルゴリズムベースの新しい高位合成

 高度なアルゴリズムベースの合成手法では、タイミング要件や構造要件の含まれた入力ソースを必要とせずに、ユーザー定義のゴールに基づいた並列性とタイミング要件を実現します。より高い抽象度で記述された入力を使用しながら、アルゴリズムベースの合成では、手書きの動作記述やRTL記述に費やされる労力を削減します。さらに重要なのは、アルゴリズムベースの合成では、設計アーキテクチャの解析と最適化を自動化することで、手書きのRTLに対して同等かそれ以上に優れた結果が得られるという点です。

(図をクリックすると拡大表示します)(図をクリックすると拡大表示します)

この手法により、設計者は設計アーキテクチャの最適化に、より多くの時間を費やせます。ユーザーはアルゴリズムベースの合成環境における制約条件を変更するだけで、サイズ、パフォーマンス、あるいは他の様々な変数についての設計最適化を行うことが可能です。経験のある多くの設計者が述べるように、 SystemCやRTLのレベルにおける設計アーキテクチャの手動最適化には多くの時間がかかるため、機能的には十分なものの、完全に最適化された状態からはかけ離れたアーキテクチャを受け入れざるを得ません。設計者は、アルゴリズムベースの合成を用いることで、設計効率や設計時間を犠牲にすることなく、設計仕様を満足させることが可能になります。

アルゴリズムベースの合成ツールは、インタフェースの自動生成さえ可能です。第一世代の動作合成手法ではインタフェースを取り扱うことさえせず、設計者に対して非常に複雑な手動設計部分を残したままでした。マイクロ・アーキテクチャはハードウェア・インタフェースに大きく依存するため、動作合成におけるインタフェース定義の複雑性は、マイクロ・アーキテクチャの範疇に入っています。一方、インタフェース合成と組み合わされたアルゴリズムベースの合成手法では、ソース・コードが純粋にシーケンシャルでハードウェア・インタフェースの詳細から独立したものであるため、あらゆるハードウェア・インタフェースに容易に対応可能です。優れたアルゴリズムベースの合成ツールは、ハードウェアの設計要件に合致するために必要な並列性と構造を生成できるだけでなく、データフロー要件に一致するインタフェース・プロトコルの生成まで行うことが可能です。結果として、より効率的でエラーの少ない設計を行えます。加えて、結果として得られるインタフェースとマイクロ・アーキテクチャは、チップのパフォーマンス要件を満足させつつ、面積を大きく上回らせることがないため、貴重なシリコンを無駄に消費することがありません。

トランザクション・レベル・モデリングのようなシステム・レベルのタスクでさえ、多くの動作合成ツールでは完全に無視されてしまいます。したがって、ハードウェア設計者は、SystemCで独自のモデルを作成し、構造と並列性を段階的に加えながらトランザクション・レベルの動作およびRTLモデルを開発しなくてはなりません。プログレッシブ・リファインメント(段階的な改良)として知られるこの手法は、コードにおける誤った解釈や構文エラーが発生しやすく、時間もかかる手動プロセスであり、検証とモデルの管理は非常に手間がかかります。これに対してアルゴリズムベースの合成では、より高い抽象度でのソース・コードを使用するため、様々な抽象度における構造や並列性の自動追加がツールにより可能となります。この手法はプログレッシブ・リファインメントを結果的に自動化するものであり、従来の動作合成では解決を試みることさえできない、さらなる手動設計プロセスの削減が可能になります。

動作合成は、その登場以来、多くの技術的課題と市場課題に挑み続けましたが、複雑性が持ち上がるたびに、それに取り組む設計者を助ける機会を逃してきました。ANSI C++の入力を基にした新しいアルゴリズムベースの合成手法の登場は、動作合成ツールが約束しかできなかったことを実現します。複雑性の必然的拡大に従って多くの設計者が、より高い抽象度から開始でき、従来の手動による手法にくらべはるかに早く、高品質なRTLを自動生成できるツールを求めることになるでしょう。