セッションE2:コデザイン ---------------------------------------------------------------------- HW/SW協調シミュレーションのためのモデル作成の試行及び評価 田中 博志,伊藤 雅樹,中本 貴士 (日立) ---------------------------------------------------------------------- システムLSIの開発において、短期間での開発、システム全体の最適化が問題 となる。そのとき、HW,SWが別々の開発フローでは解決できない ↓ 協調設計 … HWとSWの相互作用を考慮しながら設計を行うことであると捉える このような中では「協調シミュレーション」が重要であると考えるこの、協調 シミュレーション活用法の確立を目的としている(MPEG4デコーダをアプリケー ションとする) N2Cの特徴 ・CoWare-Cベースである ラッパ部分と処理部分 ・機能レベルからRTLレベルまでの広い抽象度でのシミュレーションが可能 ・動作解析支援機能 ・RTレベルCからVerilogVHDLへの変換コマンドを持つ 設計フロー システム機能記述 HW,SW分割 それぞれの開発 システム検証 の各段階でのシミュレーションをおこなう。 設計対象 : MPEGオーディオデコーダ 携帯機器向きにシステム構成の総合的な最適化が必要なアプリケーション 処理アルゴリズムのうちフィルタバンク処理をHW化して高速化する。 協調シミュレーションモデル作成の概要 C言語の機能記述とVerilogのフィルタバンク処理部分が利用可能であった。 機能(C言語)から必要な部分を切りだし、SWモデル(C/CoWareC)とした SWモデル作成 機能記述からHWで実現する機能(フィルタバンク処理)を削除しN2C用ラッパモ デルを作成 HWモデル 設計済みVerilogモデルを利用してラッパを記述 実行の仕組み C言語で書かれたSW CoWareCで書かれたHW Verilogで書かれたHW SHコンパイラ Cコンパイラ Verilogコンパイラ プロセッサシミュレータを利用した。 評価結果と考察 協調シミュレーションモデルへの変換作業 | 1モジュールあたりの工数 ------+------------------------ SW部 | 2人日 HW部 | 0.2人日 考察・評価 ・ソフトウェアには設計フローに適したシステム記述方法の確立が必要 ・機能ブロックの結合密度を小さく ・通信とデータ処理の分離 システム全体の機能的な正しさを確認できた。 システム性能を確認(処理1/60秒) MPEG4規格を満足することを確認 各段階で設計の後戻りを無くし、効率化を吐かれた プロセッサシミュレータの性能 MPEG4オーディオデータ 秒分 ---------------------------------------------- シミュレータ不使用 7.5分 サイクル精度なし シミュレータ使用 6時間 サイクル精度あり プロセッサシミュレータの性能 総シミュレーション時間に104日かかる ↓ リグレッションテストを1日で行うためには約100倍の性能向上が必要 異なる抽象度・速度のプロセッサシミュレータの使い分けによる期間短縮が考 えられる まとめ 協調シミュレーションの試行によってその効果と課題を確認した。 [質疑応答]---- Q: 3種類の抽象度の異なるシミュレータの種類と今回使用したシミュレータ (SH,C)との対応が分からなかった。 A: 機能レベルシミュレータ…プロセッサシミュレータの抽象度 ソフトウェアを実行するのに必要な抽象度とHWの抽象度とはべつに考える Q: 3種類の違い A: 機能レベルシミュレータ バストランザクションレベルシミュレータ RTLレベルシミュレータ Q: N2Cはインタフェース合成の機能を持つが使っているか A: プロセッサレベルと専用ハードウェアの間などで、通信インタフェース合 成機能使った。簡単になった。 Q: 今回は3つのモデルで、プロセッサシミュレーションに足を引っ張られてい るが、HWのシミュレーションに足を引っ張られることは無いのか。 A: ありうるが、自分の手の入れられる範囲として今回の対象はプロセッサシ ミュレータを対象としたが。実際Verilogシミュレータを使用して遅くなっ ているということもある。 Q: 協調シミュレーションの仕方を「確立した」と言うのはどのようなことな のか簡単に教えてもらいたい。 A: 手順や効果について確認した程度のものである。 Q: オーディオデコーダのアルゴリズムは何をターゲットとしているのか。 A: 詳しくはわからないが、AACなどいくつか実行できるらしい。 Q: もとのソフトについては大域変数に対して処理したのか A: そのように思って良い Q: 処理が終わる前に次の処理が始まらないようにメモリアクセスを変えるよ うなことは簡単に出来ると思うが。 A: 残りのSWに対してHWの処理があまりに早いので、次のデータが来る前には HWの処理は終わっているはずである。 Q: 今回のものは最初にシステムをC記述していたが、HWでやる部分をと決めた あとに、戻って考えたらやはりSWのほうがいいとかいうことがあるがどう なのか。 A: 今回はうまく行ったが、実際はそう言うことも考えている。 Q: N2CはHWやOSなどが決まってから適用出来るようなものなのか A: N2Cいくつかのプロセッサモデルがある。ツールとしては実行時間の比較が できる仕組みを備えている。 Q: 実行環境は具体的に A: UltraSPARCで特に遅いと言うことは感じなかった。細かいことは分かりか ねる。 ---------------------------------------------------------------------- アプリケーションプログラムを基にしたプロセッサアーキテクチャの自動生成 松田 和幸,門脇 一馬,宮内 新,石川 知雄 (武蔵工大) ---------------------------------------------------------------------- これまでのプロセッサ開発サイクル、 汎用プロセッサの処理時間の短縮を特定用途向け専用ハードの追加で対応して きたが、汎用プロセッサの高速化とアルゴリズムの改良で汎用プロセッサによ る処理に戻る 従来はスペック決定のためにパラメータを変化させた複数のプロセッサの中か ら、目的に応じて最適なものを選んできたが、この方法では手作業の設計作業 が必要となり、直接生成は出来ない。 そこで用途を限定しないプロセッサの自動生成を行うシステムの提案を行う。 具体的にはアプリケーションソフトウェア(C言語)からその処理に適したプロ セッサのVHDLソースを自動的に生成するものである。 ベースプロセッサの仕様 ・スーパースカラ型のだとデバイスリソースやスピードの点で問題がある →VLIWを採用 ・並列度は3 ・命令セット基本的な分岐・転送命令のみで構成 このベースプロセッサをターゲットアルゴリズムにより変化させる。 *プロセッサ自動生成の流れ* このシステムには、プロセッサが実装されるFPGAデバイスのゲート数の情報 とコンポーネントの遅延時間ゲート数の情報を持っている。 ターゲットアルゴリズムの並列度の抽出 独自のコンパイラシステム ループブロックの並列度の抽出を最優先している。 このコンパイラシステムの出力する中間言語(木構造)を基に同時実行可能な 命令列を得て、並列スケジューリングを行う。 ↓ プロセッサスペックの決定 ベースプロセッサの最小の命令セットをさらに縮小して回路規模の削減を図り 過ぎると、汎用性が無くのでそのようなことは行わないものとする。最終的に 生成されるプロセッサの命令・基本命令・拡張命令(特定分野に有用な命令)・ 合成命令(新規に作成する演算命令) 基本命令のみで入力されたアルゴリズムを実行し命令実行頻度から特徴を調べる 特徴的な命令列を拡張命令に変換(例.SIMD演算など) 拡張命令とは別にスペック決定時に作成される合成命令 水平型合成 ビット幅を縮めた演算機でクロックサイクル時間の短縮を図る 垂直型合成 連続して実行する演算のレイテンシを縮めて1クロックサイクル 時間内に納める ↓ レジスタ本数、ビット幅、データバス幅も決定 オペコードも極力命令長が短くなるように決定 ↓ 以上で求められたスペックからゲート数を見積もり、デバイスと適合するかで 最終判断を行う。適合しない場合は頻度が低い命令、それが使う演算機を削除 ↓ 以上で得られた命令をベースプロセッサに加え、専用プロセッサVHDLソースを 出力する 今後の課題 ・有効な合成命令の選択 ・メモリアクセスの考慮 [質疑応答]---- Q: ビット幅の測定はどのようにして行っているのか。 A: 入力のCプログラムのデータから。それでわからないところはCのコメント 文の中に情報を加える。 Q: 1クロックに収まるかの判断は回路レベルまで考えるのか、VHDLソースの レベルまでか。 A: 最的には回路レベルまで考えるべきだと思うが、現状ではそれぞれの演算 器単体の遅延を計測し、そのデータから見積もっている。 Q: ALUに入力が増えると、その前のマルチプレクサが大きくなるかもしれない が考慮しているのか。 A: そこまでは考慮していない。 Q: プリプロセッサで並列度を抽出するということだが、実際はいったん最小 の命令セットに変換しないと抽出出来ないのではないか。 A: 1回命令を追加したらまたプリプロセッサの処理に戻るようなことを繰り返 すことで対応している。 Q: 完全に独自開発したコンパイラなのか。 A: フリーで提供されているSUIFコンパイラを改造している。 Q: ベンチマークを適用して何倍速度向上したというようなデータは無いのか。 A: まだ測定していない。 Q: 合成命令で頻度チェックはする。アプリケーション依存だと思うけど、限 られたアプリしか使わないようなプロセッサを考えるのならこれで良いと 思うが、そのような捉え方で良いのか? A: 入力されたプログラムは高速に、しかしそれ以外の処理も実行可能である という方針である。 C: 今までこういうことってやられているので、そういうのを参考にすること を勧める。SUIFコンパイラも参考になるものがある。 ---------------------------------------------------------------------- コードサイズ縮小を目的としたプロセッサ/目的コードコジェネレータの実装 平尾 智也(奈良先端大),中野 猛(リクルート), 中西 恒夫(奈良先端大),福田 晃(九州大) ---------------------------------------------------------------------- プロセッサには高信頼性・低消費電力が求められる。 オンチップメモリは高価だが、その一方で、ソフトウェア規模は巨大化。高級 言語も使われつづける コードサイズを縮小し、使用するメモリの縮小を目的とする。 アプリケーションに合わせてプロセッサの命令セットを定義するものである。 (頻繁に出現する命令列を短い複合命令に置き換える) 処理の流れ 高級言語プログラムを通常のコンパイラでコンパイル ↓ このアセンブリコードから複合命令を定義 ↓ 複合命令を定義したプロセッサのVHDLとそのプロセッサ用のアセンブリコード を出力 論理合成型複合命令 … デコーダとALUをプロセッサに追加する必要がある 展開注入型複合命令 … 展開辞書を追加する FPGAに実装して動かしている。 基本命令に追加削除を行うシステムを実装(Z-80命令セット) 普通のアセンブリコードを入力としてVHDLとそれようのアセンブリコードが出 てくる 命令セット確定 ・不用命令の検出 ・頻出命令列の検出 Fraserのアルゴリズムを利用 さらに、頻出命令の尾部共有を検出するものを独自に追加 問題 ・コード圧縮による展開辞書の肥大化 命令列の置換順序で削減量に違いが生じることもある 解法 ・出現回数と命令列の積の大きいものから辞書に採用 ・GAで置換順序の問題に対応(この方が良い) また、命令セット非依存部分をクラスライブラリ化した(CFL) ・複合命令の定義 プロセッサ・目的コードの生成過程 複合命令の実現 実装について述べた 今後は論理合成型複合命令の自動生成、命令幅(横方向)の縮小 [質疑応答]---- Q: まとめられるコードの長さ A: 実際に今動かしているものは20命令ほどを頻出命令としている Q: 理論的には100でもいくらでも可能なのか。 A: そうではあるが、1回出現した命令列はともう1回近くで出るという傾向 が見られるがあるので、検索範囲を限定している。 Q: アセンブリコード=オブジェクトを小さくすると考えていいのか A: 一応、両者を1対1対応で考えている。 Q: コンパイラの吐くコードの癖を考慮すると効率良くなるって言うことは? A: あり得る。コンパイラごとにそのようなことを準備したほうがいいと思う。 Q: ヒューリスティックな方法よりもGAが良かったようだが。もっと厳密にはど の程度の差があるのかといったデータはないか。 A: たいていはヒューリスティックな方法でも強力だったが、辞書に余り取れ ないような厳しかった場合にGAが良いという傾向がある。数字まではなん ともいえない。また、リカーシブに圧縮する(圧縮で生成された複合命令を さらに圧縮する)ともっと良いと思う。シミュレーテッドアニーリングも検 討中である。 Q: 全部の検索を行うと結局メモリが膨大になりそうだから、無理なのか。 A: 処理を行うパソコンのメモリが膨大になる。 Q: なら、小規模ものくらいでやってみたらどうか。 A: 行ってみます。 Q: 未使用基本命令の扱いは A: 完全に排除。アプリケーション専用とする。 Q: OSまどを考えると網羅しなきゃいけないような気がする。 A: 2件目の発表(武蔵工大)のように基本命令を残すようなアプローチも参考に したい Q: これは開発の最後の最後で効くような物であると思う。命令セットが変わ るとソフトウェアの改変がなされるので、これを「協調設計」というのは ちょっとどうか A: 「アプリケーションありき」ということなので、協調からは外れるかもし れない。 Q: 頻度の高いものの検出では、オペランドまで一致しなくては行けないのか A: 現在はそうである。 Q: 実際にレジスタ数の多いものでは検出できないような気がする。 A: そのとおりだとおもう。また、プログラムGCCとYCでコンパイルすると、 GCCのほうが効率良かったが、圧縮したら両方が同じような結果になった。 レジスタの違いをクリアするためにいったん仮想の名前を与えて、後で配 置することで圧縮を行うようなこと行われたり、レジスタの使い方に制約 があるので、今は考えなかった。今後は直行性の高い命令では苦労しそう C: 辞書をプロセッサに近いメモリに配置するとローパワーになるとおもうそ のような研究もなされているので参考にしたらいいと思う。