=========================================================================== セッション：C2 タイトル ：「FW/LSI協調設計」〜ファームウェア開発サポートの立場から〜 チューター：松本 展（東芝） 会場 ：E会場 参加者 ：30 〜 40名 =========================================================================== 1) ファームウェアの協調設計とは 小さなブロックに分割し再利用することで設計効率が向上 SoCにおける，データ処理 MPU，標準I/F は再利用されている．今日注目したいのはデータ処理とデ 　ータ処理のところで使われているソフトウェア．(ファームウェアの部分) ・ファームウェアの（FW)/LSI協調設計 ファームウェアとLSIの研究分野の位置付け 3つに分類 1. プラットフォーム方式 リターゲッタブル・ツール 2. 仕様から直接合成 3. IP方式 協調設計をどこに置くか． 仕様とプラットフォーム方式を多く含むが，それに対してIP方式は 　　　　　わずか． ┌────────┐ │プラットフォーム│ │ ┏━━━━━┿┓ └──╂─────┼╂───┐ ┃ 強調設計 │┃IP方式│ ┌──╂─────┼╂───┘ │ ┗━━━━━┿┛ │仕様から直接合成│ └────────┘ 2) 問題の定義 ・対象はコンシューマ向け製品 ・最適化問題 コストあるいは消費電力についてoptimalなものをいかに短期間に開発 　　　するか？ ・その他 仕様変更における柔軟性 再利用性 ツールサポートの容易性 3) HWプラットフォーム プラットフォームとなるプロセッサ種類 1. 汎用プロセッサ コスト ：高い 動作周波数：高い 2. コンフィギャラブルプロセッサ RISC ＋ ハードウェア拡張 コスト ：安い 動作周波数：中程度 3. リコンフィギャラブルプロセッサ RISC ＋ リコンフィギャラブルエンジン 動作周波数：高い ・HWプラットフォームに対する要求 Optimalな製品を短期間に HWの構成，性能を最適化できること HW起動のオーバーヘッドが少ないこと 開発ツールが，統一的にサポートできること 4) MePのコンセプト 異なるメディア応用は，異なる開発が必要とする 汎用メディアプロセッサ ↓ ヘテロジニアスなプロセッサ構成 ・基本アーキテクチャ コンフィギュレーション，機能拡張，階層的バス ・MePコアのコンフィギュレーション オプション命令 メモリ構成 デバッグ機能 ハードウェア機能拡張 1 命令拡張 ユーザー拡張命令 DSPユニット VLIWコプロセッサ 2 HWエンジン拡張 HWエンジン ・Exporation of Multi-grain Paralleism VLIWは細かい粒度で開発 ・Core & VLIW モード VLIWコプロセッサ コプロセッサは命令をつかさどる - オプション 6) HW主体の場合とSW主体の場合で協調設計が異なる SW主体の場合の協調設計 開発フローはストレートフォワード 1. Cでアルゴリズムを記述 2. クロスコンパイラでコンパイル 3. コンフィギュレーション - 命令の選択 4. プロファイラーは取り，どこをHW化する場所を選択 5. CレベルでHW/SWの機能分割 6. 検証を行い，要求を満たしていなければプロファイルに戻る 要求を満たしていれば実装 ・開発ツールのインテグレータ 開発ツールをインテグレートするツールが必要． 　　（プロセッサジェネレータ） コンフィグレーションにあった，ツールなどが自動生成される ・ハードウェア拡張の方法 ハードウェアの粒度に応じて2通り 1. 細かい粒度の場合は命令拡張 2. 荒い劉殿場合はハードウェアアクセラレータ ・命令拡張の方法 Intrinsic Functionを使う（関数形式で記述） Cの関数のような形で記述 → コンパイル コンパイラによる，レジスタ割付と，命令スケジュール ・命令の定義 入力（アーキテクチャDB) コンパイラ・アセンブラ情報，C++パイプラインシミュレータが自動的に 　生成される ・HWエンジンの拡張（Cからの合成） CのプログラムのうちHW化したい部分 Cのシミュレーションモデル I/F 7) 事例 後側方監視システム 後ろからくる車を検出し，認識したものを赤い四角で囲まれる ・画像処理の概要 1. 画像を入力 2. ひずみ補正 3. ソーベルフィルタ ・ひずみ補正 Lenz Tsai(1989)提案のアルゴリズム ・ソーベルフィルタ 垂直方向，水平方向のエッジ強度の検出（車を検出） ・領域の追加 領域内のエッジ強度がしきいち以上のサブ領域のみ追跡候補とする ・VIEW命令の決定 画像処理の性能見積もり Cプログラム シミュレータによる性能解析 命令を決定 ・フィルタ処理の高速化 行列処理を1命令で実行できるようにし，全体では9命令 ・フィルタ処理の実行サイクル 全体では 性能が6〜7倍 チップ面積では12%UP VLIWとSIMDの効果によるもの ・VLIWの効果 30%弱がVLIWだけの効果 7) HW主体の開発フロー 1. 大きくHWの切り出しを行う 2. 処理フローのシミュレーション 3. SW主体の開発フローの適用 さらに小さいHWの切り出しを行う 4. HWのモデリング 5. 協調設計 8) 事例 MPEG2-Codec(DEFiant) 150MHzで動作 ・MPEG2-Codec DEFiantの構成 ・DEFiantの6構成 1つとして同じプロセッサ構成はない ・Video DSP MePモジュール -Decoding- 逆量子化などを連続的に処理 ・処理フローのシミュレーション Excutableなモデルを作成は時間がかかる．シミュレーションにも時間がかかる 機能はあえて実装するな Excutableなモデル作成は，時には害になる ・処理フロー・シミュレーションの必要性 処理フローの複雑化（机上計算は不可能） ・マルチプロセッサ ・書く処理が毎回実行されるとは限らない ・少し前のデータを入力にする ・処理時間が入力ストリームに依存する ソフトウェアの処理時間は，初期にはわからない ・開発工程とシミュレーション コーディングの進行に応じた，実行手段を使い分け 処理フローのシミュレーション SW処理をホスト計算機で代行したHW-SW一体化したシミュレーション Cモデルによる協調シミュレーション RTL実行環境 エミュレータ ・FW開発方針の必要性 開発方針 プロセッサからバスへの著癖いつアクセスは行わず，DMAで行う。 DMAのにも荒いバストランザクションが主体→上位における見積もりが容易。 こういうことをするためには，ハードウェアの支援機構が必要。 多機能なDMA,マルチ・バンク内蔵メモリ。 ・Audio VLIW コプロセッサの効果 ゲート数：38KGates 効果：40%高速化 ・Video Encoder SIMD命令拡張 追加命令 ・2並列SIMD算術・論理・シフト・複合演算 ・バイトシャッフル命令 拡張方式 UCI User Custome Instruction ゲート数 3.1KGates ・Video Decoder PMVのHW化 PMV 動きベクトル予測値 拡張方式 高位合成により，CモデルからHWエンジンを自動合成 ゲート数 12KGates 効果 - マクロ・ブロックのSW処理が19%高速化 高速化が必要になることが，急遽SWから変更 9) 後側方監視のFW開発 紆余曲折し，開発に時間がかかった ・プログラミング習熟の必要性 プログラムのチューニングにより，最終的に性能が１０倍近く向上 FW開発者のアーキテクチャ理解が必要 2度目の応用では，開発期間は非常に短くなった 10) DEFiant FW開発内訳 時間がかかったのはマルチタスク化する部分 11) FW開発工期短縮の可能性 開発はウォータスルー型 特別なOSを作った FWの下流工程をもっとサポートする必要がある クリエィティブな部分は1/3程度だった 12) まとめ ・FW/LSI協調設計には，さまざまな粒度のHW拡張を許す，HWプラットフォー 　　ムが適するソフトウェア主体の場合とハードウェア主体の場合では，アプ 　　ローチが異なる ・ソフトウェア主体の場合，Cにてアルゴリズムを記述，その一部をHW化．協 　　調合成も有用 ・ハードウェア主体の場合は，処理フローのシミュレーションを行う ・FW開発の効率化のためさらに開発フローの改良を進めていく ----------- Q. 命令を取り外して，最適化するということはどいうことでしょうか？ A. MePはプロセッサ内部の構成が2つに分かれていて，あらかじめ用意されて 　いる命令部分とユーザが拡張できる部分に分かれています．あらかじめ用意 　されている命令には取り外せる命令があり，取り外すことで最適化がはかる 　ことができます． また，汎用レジスタはあらかじめ16本あり，64bitのレジスタ64本まで追加 　することができます．バスについては，あらかじめ用意してあるバス(32bit 　 or 64bit)とVCI準拠のバスを自分で追加して使用します．(VCI準拠のブリッ 　ジを用意してあるということ) Q. 階層的なシミュレーションを行っているようですが，その対応付けはどの 　ようになったのでしょうか． A. ベースはCレベルのシミュレーションで，その上でRTLのシミュレーション 　を行いました．もうひとつはCとRTLをそれぞれを比較検証するシミュレーシ 　ョンを行いました． Q. 一貫性の検証を行うときには，同一の人物が検証を行ったのでしょうか？ A. ブラックボックス化して，別々に行われました． Q. SW/HWの一体化の抽象度にかかる時間はどの程度でしょうか？ A. アンタイムドです． Q. SW/HW一体化できたのはバスで区切ることができたからでしょうか？ A. バスモデルにして，抽象度をあわせれば他のケースでもSW/HW一体設計は可 　能だと思います． Q. 汎用OSを適用することはできなかったのですか？ A. uITRONなどを使わなかったのは，プリエンプティブなスケジュールが必要 　なかった為です．またコードエリアを節約するために，使いませんでした。 Q. モデリングの段階で，どの程度人を投入しましたか？ A. 一人ひとつのエンジンを作りました．上位のモデルは一人の人間が作業しま 　した．プログラムのバージョン管理は重要で，シミュレーションモデルは一 　元管理をしないと痛みを伴うものでした． Q. デバッグ機能はオンチップのデバッグ機能をサポートするためのものなので 　しょうか？ A. JTAG上のデバッグ機能としてあり，これはシミュレータのデバッグ機能を充 　実するためのものです． Q. HWはCから生成しているのに，コプロセッサはどうなのでしょうか？ A. コプロセッサは自動生成していません．それは，自動生成するには複雑すぎ 　るからです．サブシステムは自動で生成されるようにしてあります． Q. グローバルバスについてはどうなのでしょう？ A. グローバルバスは自動合成していません．バスの構成はプラットフォーム型 　で固定されています Q. グローバルバスは一系統なのでしょうか？ A. グローバルバスは，手で行う場合は増やせるようになっています． Q. まだ実在しないHWに対してシミュレーションしているようでしたが？ A. RTLレベルではHWは存在しないのですが，Cレベルでは存在しているので，そ 　れにたいしてシミュレーションを行っています． C. コメントとして，こういうものはHW化すると効果的，SWのままがいいという 　ガイドラインがあると良いですね． Q. 開発環境というものをそれぞれのプロジェクトごとに用意する準備などはあ 　るのでしょうか？ A. それぞれのプロセッサの構成が違ってきます．コンパイラやライブラリはバ 　イナリで提供しています．シミュレータについてはソース提供しています． 　コンフィギュレーションは30秒程度でできるようにしているのですが，コン 　パイルなど余計な時間をかけたくはないのでバイナリで提供できるものはバイ 　ナリにしてあります． -------------------------------------------------------------------------------- [記録者自身の感想] 発表が予定時間より早く終了したため，質疑応答には多くの時間を割り当てる ことができ，非常に活発な議論がなされていた．「FW/LSI協調設計」というこ とでSW/HWコデザインに関心をよせる方が多数参加されていた．今後，協調設計 に関する事例が数多く発表され， 今後のシステムの開発工程がどのように変化していくのか興味がある．