OpenMPによるハードウェア動作合成 システムの設計と検証 立命館大学 理工学研究科 中谷 嵩之 松崎 裕樹 山崎 勝弘 2007/09/05 1 発表内容 • 研究背景と目的 • OpenMPを用いた動作合成システム • 動作合成による並列ハードウェアの構成 • 信号処理を対象とした実験結果と考察 • まとめと今後の課題 2 研究背景と目的 • 背景 – システムLSI開発の大規模化・期間の短縮 – 高抽象度設計手法の発展・製品への適用 – 高位合成における並列処理記述の課題 • 目的 – 並列プログラミング言語(OpenMP)を用いた動作合成 手法の提案と評価 – 動作合成システムの検討と実装 – 信号処理を対象とした実験と評価 3 動作合成の課題 • 並列処理の記述が困難 – 同期・排他処理制御記述が難しい – 記述量の大幅な増加 – 並列性のツールによる自動抽出の限界 • 検証時間の増加 – 回路検証用シミュレータなどの専用ツールによる長時間の検証 OpenMPを用いた動作合成システム - 並列性記述の容易化、高速化 - SMPクラスタ環境による検証時間の短縮 4 OpenMP • 共有メモリ環境における並列処理用API fork • Fork,joinモデルでのスレッド実行 • 既存のプログラムにプラグマを挿入 ユーザが明示的に並列性を指示 – データ並列(#pragma parallel for) – タスク並列(#pragma omp sections) マスター スレッド join fork join • 同期・排他制御が自動 • 逐次処理プログラムから段階的・シームレスに並列化 並列実行部 5 OpemMPを用いた動作合成システム ハードウェ ア制約 動作記述 (OpenMP) 動作合成 OpenMP コンパイラ 並列動作HW中間 表現 最適化 性能評価 マルチスレッド プログラム SMP環境 シミュレーション • OpenMPで動作記述 • シミュレーション系で動作 や並列化手法を検討 • ハードウェア(HW)合成系で 制約に従い並列動作HWの 中間表現を生成 • 並列動作ハードウェアの生成 並列動作 ハードウェ ア ハードウェア合成 シミュレーション 6 並列実行ハードウェアの動作モデル マスター スレッド プラグマに よって指示 実行 起動及び 結果回収 逐次処理 ハードウェア 並列処理 データパス 並列実行部 • ハードウェアは動作合成時に生成 並列処理 データパス マスター スレッド • ソフトウェア実行との対応 マスタースレッド → 逐次処理 並列実行部 → 並列処理 動作合成 ハードウェア – スレッド生成の負荷がない – 処理の粒度によらず並列化 → 積極的な並列化が可能 7 システムの利点 • シミュレーション系 ハードウェア 制約 動作記述 (OpenMP) – SMP環境による高速シミュレーション →並列化手法の検討、検証時間の短縮 • ハードウェア合成 – OpenMPによる並列処理記述の容易化 – 同期・排他処理制御の自動化 →設計の初期段階での並列化手法の評価 →逐次プログラムからの段階的な設計 動作合成 並列動作HW 中間表現 最適化 性能評価 OpenMP コンパイラ マルチスレッド プログラム SMP環境 シミュレーショ ン 並列動作 ハードウェア ハードウェア合成 シミュレーション 8 データ分割の実行モデル • 大量のデータへの繰り返し処理をノードで分割・担当 • 100回の繰り返しを4ノードで分担する場合 #pragma omp parallel for for(i=0;i<100;i++) { 処理A(i); } #pragma omp parallel for (スレッド生成 & fork) スレッド 処理A(i=0~24) スレッド 処理A(i=25~49) join スレッド 処理A(i=50~74) 終了時のリダクション演算 (結果の足し合わせなど) スレッド 処理A(i=75~99) 各スレッドはforループ内 の繰り返し処理を分担 9 データ分割の並列ハードウェア構成 逐次データパス 並列HWの起動・終了 並列データパス Control Op Memory or Register Control 処理A 処理A 処理A 処理A Arbiter 並列データパス 動作時は停止 スレッド間共有データへの 同時アクセス制御 Memory or Register 10 タスク分割の並列ハードウェア構成 #pragma omp parallel sections (スレッド生成 & fork) スレッド 処理A 各スレッド 終了時の 同期 スレッド 処理B スレッド 処理C #pragma omp parallel sections { 処理A; #pragma omp section 処理B; #pragma omp section 処理C; } join 各スレッドはsectionで分割された処理を担当 11 タスク分割のパイプライン構成 Control W R 処理A Loop Memory or Register W Memory or Register Memory R 処理B or Register 並列データパス Memory R or Register pipeline buffer pipeline buffer R: Read W: Write W 処理C Loop Control R 処理A W Memory or R Register Memory or R Register Memory or Register Memory or Register 処理B 並列データパス W W 処理C • 共有変数が単一データパスからアクセスされる記述のみ構成可能 12 信号処理を対象としたシステムの評価 • 信号処理を対象としたシステムの評価 – 最適化・パーサー部分の構成の検討を目的 – RTL中間表現までを動作合成システムによって自動生成 – 中間表現から手作業でHDL記述へ変換 • 対象とするアルゴリズム – FIRフィルタ – ウェーブレット変換 13 FIRフィルタ、ウェーブレット変換の並列化 • FIRフィルタ – 特定の周波数信号の除去、抽出 Task 1 x[n] Z-1 x[n-1] h0 Z-1 h1 Z-1 h2 Z-1 x[n-M] hM Task 2 hM-1 y[n] Task 3 • ウェーブレット変換 – スペクトル解析に用いられる処理 0 1 2 2n-1 2n - Task 1 Loop (n = n/2) Task 2 >>1 0 >>1 1 n-1 n 2n-1 2n 14 実験内容 • FIRフィルタ、ウェーブレット変換 – – – – タスク分割 データ分割(2並列、4並列) FIRフィルタ:次数16、ウェーブレット変換:256点1次元 10000点のサンプルデータ • 実験環境 – – – – OpenMPコンパイラ: Intel C/C++ Compiler 9.0 SMP環境:Intel Dual core Xeon 2.8Gx2 Quad Core サイクルレベルシミュレータ:Menter Graphics ModelSim SE 5.8 論理合成ツール:Xilinxs ISE7.1 15 実行時間に実験結果 動作合成ハードウェアの実行時間(単位:10^6cycle) SMP環境での実行時間(単位:s) FIR Wavelet FIR Wavelet 12.8(1.00) 87.5(1.00) 逐次 130(1.00) 2100(1.00) 逐次 タスク分割 260(2.06) 3000(1.40) タスク分割 データ分割(2 Node) 270(2.11) 5300(2.51) データ分割(2 CPU) 9.06(1.41) 57.1(1.53) データ分割(4 Node) 530(4.17) 10400(4.98) データ分割(4 CPU) 7.48(1.71) 32.8(2.67) 29.42(0.43) 1803(0.04) ※()内は値は逐次との速度向上比 • 処理負荷が高いウェーブレット変換の方が速度向上比が高い • データ分割において両アプリケーション共に、理想的な速度向上 • ノード間におけるメモリアクセス要求の衝突が非常に少ない 16 回路面積、検証時間の実験結果 動作合成ハードウェアの回路面積(単位:Slice) FIR サイクルレベルシミュレータの検証時間(単位:s) Wavelet FIR Wavelet 逐次 31.7(1.00) 100.69(1.00) 逐次 400(1.00) 65000(1.00) タスク分割 20.6(1.54) 115.99(0.87) タスク分割 440(1.10) 84000(1.29) データ分割(2 Node) 15.9(1.99) 50.38(1.99) データ分割(2 Node) 470(1.18) 230000(3.57) データ分割(4 Node) 25.21(3.99) データ分割(4 Node) 500(1.24) 420000(6.49) 8.0(3.96) ※()内は値は逐次との回路面積比 ※()内は値は逐次との時間比 • SMP環境ではサイクルレベルシミュレータの検証時間と比べ数十から 数万倍程度高速化 • シミュレータでは並列化するほど検証時間が長くなるが、SMPでは 検証時間が減少 17 • まとめ – OpenMPを用いた動作合成システム – FIRフィルタ、ウェーブレット変換による評価 – データ分割において理想的な速度向上 • 今後の課題 – パイプライン化の有効性の検証 – 各種アプリケーションによる評価 – コードジェネレータの作成によるシステム全体の統合 18 19 20 21 22 23 24
© Copyright 2024 ExpyDoc