DAS/SWEST共同招待講演 システムLSIのC言語ベース設計の現状と将来 NEC システムデバイス研究所 システムCAD 若林一敏 日時：2006/07/13 14:50〜16:10 聴講者：200人程度 座長：浜口(阪大) ---------------------------------------------------------------- プレゼンテーション ---------------------------------------------------------------- ○C言語設計の概要と動作合成の(基礎)原理=動作合成とは？ ・ANSI Cでハードの設計・検証を全部行う ・RTLを書かずに、バスなども全部自動合成 ・RTLのデバッグは遅いから、C言語の記述で済ませてしまう ○HW/SWの開発環境 ・HWもSWも同じ環境でお互い話し合って開発⇒SoC設計もSW的開発 ・システム設計⇒機能設計(動作合成ツールCyber)⇒RTL記述 ・等価検証もCで行う ・設計レベルによる規模の違いの例 ＊ゲート回路(100万ゲート)＜RTL(30万行)＜C(4万行) ○C設計による向上率 ・記述効率の向上(4〜20倍) 平均約7倍 ・検証速度の向上(50〜200倍) ○動作合成を用いた設計の実例 ・動作合成で作ったチップ：ex.携帯502i ＊もう実際に使われている技術(toy techではない) ○なぜC言語？ ・人間が協調できるだけでも、効果が大きい ・Cで全部設計：制御系回路・データ処理系回路 ⇔使い分ける(制御系は手で書く)のが大事だと言う人もいるが、全部Cで。 ・CからRTLを出すだけでなく、HW/SW協調シミュレーション(デバッグはC) ・Cソースで形式プロパティ検証 ・動作合成：Cコンパイラ(コンパイラにバグがあっても手で直せる) ・なるべくRTLを見ないで設計 ○CyberWorkBench ・Cソース、生成されたRTL、対応するデータパス図：全て対応関係が目で見て分かるようなGUI ○動作合成による利点 ・RTL言語による構造記述(論理合成)：1パターンしか得られない ・Cによる動作記述(動作合成)：数パターンの回路が得られる⇒色々なパターンを試してみるべき ○動作合成の特徴 ・同じC言語の記述から、使用するハードウェア資源の制約によって、異なる回路を生成できる 1.データフローグラフ 2.スケジューリング(演算器制約)：何状態で実現可能か? 3.データパス生成：Cに書いた通りの回路(大きすぎ) 4.最適化：オペランドの交換 5.最適化：レジスタの共有(セレクタも減る) 6.FSMD:FSM+Datapath ○(局所的)広域スケジューリング ・ハードは並列化が重要 ・記述順の実行：5ステップ⇒投機実行：３ステップ ・複数のIF文の並列化：Cで自分で書き直すのは大変⇒コンパイラ任せにする ・スーパースカラ：並列を5以上にしても変わらない ＊コンパイラの並列化だけで、6倍速くなる ○データパス割り当て(バインディング)の例：逐次割り当て ・割り当て方法によって、コストが変わる(論理的な演算を物理的な演算に結びつける ・スケジューリング＆バインディング：CDFG上で行う ・演算器：ノード レジスタ：演算間の線に配置。 ○なぜこんなことが実現しなかったのか? ・人手並みのRTLにならなかったから。 ・基本ブロックのスケジューリング、バインディングは全体のごく一部 ・合成系 1.配列、ループの最適化(分岐やGOTO文) 2.関数の扱い 3.パイプライン 4.大域的な並列化 5.ポインタ ＋言語レベル最適化(非常にやることが多い) ・演算処理順序を変える⇒精度が変わる ○C言語設計によるLSI設計手順 ・リファレンスモデル作成⇒HW/SWの分担決定 HW：動作レベルC作成⇒動作合成⇒サイクル精度検証 ○HW/SW協調検証・システム検証 ・この時点での検証によって、設計をやり直すことが可能 1.HW生成にかかる時間が短い 2.手で設計している場合、ここまで来るまでの時間が非常に長い ○動作合成の回路品質は人手設計に劣るか？ ・面積、遅延、性能、電力 ・テスト容易性、修正 ＊オプションの意味の理解が必要 ○面積と速度のトレードオフ ・同じ土俵で勝負しない ・動作記述のCは、再利用性が高い。 異なる要求仕様がある場合、RTL設計では一点しか設計できない⇔動作合成は、1つの記述からたくさんのRTLを生成できる ・同じポイントで勝負したら人手の方が勝るかもしれないが、動作合成の場合、同じ記述のCから複数の回路パターンを生成可能 ・再利用性が高いと、一日で別の仕様のチップを生成可能 ＊周波数の違う回路(33,54,108MHzの3パターンの回路) ・人手設計では考慮外の回路も設計(深いシーケンスを持つ回路の生成)可能 ＊シーケンスが深いとデバッグが大変：人手設計が困難 ○回路の比較 ・人手：RTレベル設計＝構造設計(状態遷移)(loop unrolling)：状態数3⇒面積：大、遅延：大 ・動作合成：Cのfor文で記述：FSMで実現(loop rolling)：状態数35⇒面積：小、遅延：小 ＊人手設計では、普通ありえない形式まで考えられる ○複雑大規模な制御の実現 ・人手設計：入力：23KL in BDL(C) 制御回路：1000状態 面積：150Kgate ＊ファームウェア制御しか設計できない ・動作合成：スピード40％アップ、面積：30％削減、デザインTAT：1/10 ○大規模FSM ・遅延制御：人手設計に勝てる ・遅延：状態でコード遅延大⇒FSMを任意の大きさのFSMに自動分割⇒制御回路の遅延を任意の値 ○カスタムプロセッサ ・面積は、若干(5％分)負けたが、少ない工数で等価の品質(ASIP設計は工数がかかりすぎる) ・Verilogで1万行書くのはきつい ・シミューション速度が200倍違う(動作合成：61Kc/s, 人手：0.3Kc/s) ○タイミングクロージャ(遅延収束) ・動作レベルで遅延改善⇒良いRTL記述生成 ・早い段階で、どんどん違うRTLが生成できる⇒2時間で面積40％削減 ＊速く良いRTLが得られる ・同じところまでやろうとすると、人手では4日かかる ＊RTLはバグを気にして、あんまり大きく書き換えられない ○動作合成の利点 1.全く違うアーキテクチャが提案できる 2.分割損：少人数で開発可 3.RTLはデバッグ性重視⇒人間の限界 ＊レジスタのシェアをすると、デバッグが出来なくなる ＊最初にチップを作る時はデバッグ性重視で、面積が小さくならない ・RTLでは考慮外のHW/SW分割を、動作合成で行うことで、電力削減＆設計容易 ・ハードウェア分割⇒並列処理が可能 ○注意点 ・ハードウェア向けアルゴリズムにしないと負ける ＊SW向けアルゴリズムを動作合成しても、あまりいい回路ができない ex.for文で全て配列に入力後、処理 ⇒入力後になるべく早くその値を使った処理を行う ＊必要メモリ量を削減し、高速なHW向けアルゴリズムとすれば、人手と同等の回路) ○C言語の並列化をしないと負ける ・1つのプロセスとして合成するより、2つのプロセスとして合成 ・検証の終わったソースを分割して、2つのプロセスにして並列動作 ＊そうしないと、必要以上にクロック数がかかる ○設計期間処理＋画質 ・RTL設計：各ブロックごとに設計⇒10ヶ月 ・C設計全体を1つのCプログラムで設計⇒1.5ヶ月 ＊人手の設計で、1番時間がかかったところは、画質の設計だった ○チューニングしやすい ・Verilogの行数と論理合成によるゲート数は、必ずしも線形関係ではない ＊上手い具合に良い回路が生成できないパターンに当たることもある。 ・動作合成では、段階的に改良していけるが、RTLでは大局アーキテクチャは徐々に変更していくことは困難 ＊HWの設計だが、SW的な反復設計法を適用できる。 ○まとめ ・同じ期間であれば、動作合成の方が優れている ・1つの記述から、全く違うアーキテクチャが複数生成できる ・アルゴリズムを色々試すことが容易 ○問題点 ・言語レベル最適化がまだまだ弱い ・どんなCでも高速なコードを生成できるわけではない。 ＊形式検証：プロパティ検証 ＊C言語では、CF直前まで、設計アルゴリズムの改良が可能 ---------------------------------------------------------------- 質疑応答 ---------------------------------------------------------------- Q.性能を出すためのノウハウは？ A.そのまま使える。そんなに万能ではないが、合成したものを手直しせずに使用できる Q.RTL設計に比べ、チューニングの大変さの他に手間が増えることはあるか？ A.変えたらすぐ結果が出るので、やりやすい。RTLはそこにたどり着くまでに時間がかかる。 むしろ、チューニングはやりやすくなっていると考えている Q.SWをHWに置き換えれば速くなり、SWもHWやファームウェアにした方がいいものがある。HWでは実現できない部分があるのでは？ A.プログラマビリティはSW。速度や電力系はHW。OSコード系はHWでは実現不可能。 Q.RTLとゲートの相関関係が分かっているが、Cとゲートの結びつきが良くわからない。 A.動作合成をやっているからと言って、ECOがなくなったというわけではない。 Cから生成されたRTLを手直しすると場合もある。 Cyberなら、GUIでゲートから直すことも可能。