SOFTWARE SOLUTIONS FOR A PROGRAMMABLE WORLD 創刊号 2015
SOFTWARE C/C++、OpenCL
プログラミングの 次なるロジカル ステップ
SDSoC 環境の容易性：
サンプル デザインのビルド
Zynq SoC にシステム レベルの ハードウェア / ソフトウェアを最適化 FPGA 向 SDAccel ソフトウェア アプリケーションデザイン フロー MathWorks: ラボではなく
デスクトップ上で設計のトレードオフを検討 japan.xilinx.com/xcell
Letter from the Publisher
SOFTWARE
Xcell Software Journal へようこそ！ 今年、ザイリンクスは、FPGA の専門家でなくても、C/C++ や OpenCL™ を使用 してザイリンクスのデバイス ロジックをプログラム可能にする開発環境、SDx ™ シリーズ を発表しました。SDx 環境が目指すのは、GPU や CPU をプログラムするのと同じく らい容易に、ソフトウェア開発者とエンベデッド システム アーキテクトがザイリンクス のデバイスをプログラムできるようにすることです。ザイリンクスでは、長年にわたり、 FPGA ハードウェア テクノロジによってアルゴリズムの高速化を可能にしてきましたが、 下位のソフトウェア テクノロジおよびハードウェア プラットフォームにおいて、ソフトウェ
発行人
Mike Santarini mike.santarini@xilinx.com +1-408-626-5981
アおよびシステム アーキテクトの広範な C/C++ および OpenCL ユーザー コミュニ ティ向けの開発環境を作成できるレベルに達したのは、つい最近です。 2000 年以降、ハードウェア プラットフォームは急速な進化を遂げました。2000 年
編集
Diana Scheben
アートディレクター
Scott Blair
デザイン/制作
Teie, Gelwicks & Assoc.
日本語版統括
神保 直弘 naohiro.jinbo@xilinx.com
デバイスを世に送り出し続けるとともに、今ではシステム オン チップ (SoC) として知ら
制作進行
周藤 智子 tomoko.suto@xilinx.com
マルチコアへの転換により、ソフトウェア開発者には、新しい分散プロセッシング アー
日本語版 制作・広告
有限会社エイ・シー・シー
し掛かりました。ザイリンクスの SDx シリーズの開発環境は、このようなソフトウェア
代初めには、ソフトウェア開発業者の仕事の流れが、半導体業界によって大きく変わり ました。太陽のエネルギー密度にチップが達する将来を回避するため、 MPU ベンダーは、 モノリシック MPU から、 ホモジニアス マルチコアの分散プロセッシング アーキテクチャ に転換したのです。この選択により、半導体業界は、 「ムーアの法則」に沿って数世代の れているヘテロジニアス マルチコア プロセッシング システムを開拓できました。しかし、 キテクチャで効率良く動作するソフトウェアを設計しなければならない、という重荷がの 開発者を支援します。SDx 環境の使用により、開発スピードを劇的に高速化することが 可能となり、C/C++ および OpenCL コードは次世代のプロセッシング アーキテクチャ (その多くは現在 FPGA により高速化されている ) ベースのシステムで動作します。 実際に、データ センターなどの演 算能 力が重 視される市場では、高消費 電 力の CPU/GPU アーキテクチャから、MPU と FPGA の融合による、FPGA で高速化さ
Xcell Software Journal 日本語版 創刊号 2015 年 10 月 9 日発行 Xilinx, Inc 2100 Logic Drive San Jose, CA 95124-3400
ザイリンクス株式会社 〒141-0032 東京都品川区大崎 1-2-2 アートヴィレッジ大崎セントラルタワー 4F
れたプロセッシング アーキテクチャに置き換わりはじめています。同様に、エンベデッ ド システムでは、ザイリンクスの Zynq®-7000 All Programmable SoC や、近日発表 のザイリンクス UltraScale+ ™ MPSoC（複数のプロセッサと FPGA ロジックを同一 チップ上に統合）などの新しいヘテロジニアス マルチコア プロセッサが、他の製品に はない性能を持ち、差別化された次世代システムを開発できるようになります。従来、 FPGA はハードウェア エンジニアの独壇場でしたが、もはや、そうではありません。 ザイリンクスが自社ハードウェア プラットフォーム上で使用できる SDx シリーズの開 発環境を発表したことで、ソフトウェア分野のエンベデッド ソフトウェアおよびシステム 開発者は、使い慣れた環境で C/C++ または OpenCL を使用して、FPGA の高速化の 恩恵を得られるようになりました。高位合成 (HLS) ツール フローの強力な基盤コンパ イル テクノロジと、ヘテロジニアス アーキテクチャのために設計されたプログラム言語 およびツールの集約によって、ソフトウェアおよびシステム設計者が独自のヘテロジニ アス SoC にカスタムのハードウェア アクセラレータを搭載するための最後のピースが 揃いました。 Xcell Software Journal は、SDx 環境と、National Instruments 社や MathWorks®
japan.xilinx.com/xcell/ Ⓒ 2015 Xilinx, Inc. All Right Reserved. XILINX や、Xcell のロゴ、その他本書に記載の商標は、米国および その他各国の Xilinx 社の登録商標です。ほかすべての名前は、 各社の登録商標または商標です。
社 などのザイリンクス アライアンス メンバー企業が提供する環境の有効活用を支援す るための季刊誌です。急速に拡大している利用者に向けて、ソフトウェアのトレンド、 ケース スタディ、ハウツー チュートリアル、最新情報、今後の見通しなどを提供します。 記事を読み進める中で、ザイリンクスのリソースへの興味が深まり、ザイリンクス ソフ トウェア開発者ゾーンから入手できる SDx 開発環境をテストしてみたくなるでしょう。 Xcell Daily Blog ( 英文 )、特に Adam Taylor による SDSoC 開発環境使用記録も
本書は、米国 Xilinx, Inc. が発行する英文季刊誌を、ザイリンクス 株式会社が日本語に翻訳して発行したものです。
お読みになることをお勧めします。また、ジャーナルへの寄稿もお待ちしております。
米国 Xilinx, Inc. およびザイリンクス株式会社は、本書に記載され たデータの使用に起因する第三者の特許権、他の権利、損害にお ける一切の責任を負いません。
是非シェアしてください。
本書の一部または全部の無断転載、複写は、著作権法に基づき 固く禁じます。
FPGA で高速化されたシステムのプログラミングを開拓する仲間と、あなたの経験を
— Mike Santarini 発行人
天国のブルース シーンに新たな ベース プレイヤーが加わりました。 本号は、アナリストおよび ESL ビジョナリの Gary Smith 氏 (1941 ∼ 2015 年) に捧げます。
This year’s best release.
Xcell Publications
Solutions for a Progammable World
ザイリンクス SDx IDE およびデバイスで C/C++、OpenCL コーディングの 高速化を追求するソフトウェア開発者向けの決定版 受賞歴のあるザイリンクスのパブリケーション グループは、プログラマブル FPGA のソフトウェア業界に特化した 新しい業界誌を四半期ごとに発行します。ザイリンクス SDx™ 開発環境や高位の入力方法を用いて、 ザイリンクスの All Programmable デバイスのプログラミングを行うユーザーが対象になります。
広告掲載について
Xcell Software Journal では、この美しくデザインされた新しい誌面への広告掲載の予約を受け付けています。 最も関心の高い人々に、製品やサービスについてお知らせする絶好の機会です。
広告に関するお問い合わせは、有限会社 エイ・シー・シー ( sohyama@acc-j.com ) へ お気軽にお問い合わせください。
CONTENTS 目次 創刊号
2015
14 VIEWPOINT Letter from the Publisher Xcell Software Journal へようこそ！ . . . 2
COVER STORY
C/C++、OpenCLプログラミングの 次なるロジカル ステップ
6
36 XCELLENCE WITH SDSOC FOR EMBEDDED DEVELOPMENT ステップバイステップの SDSoC : サンプル デザインのビルド . . . 14
SDSoC 統合開発環境を使用した、Zynq SoC における システム レベルのハードウェア / ソフトウェア最適化 . . . 20
XCELLENCE WITH SDACCEL FOR APPLICATION ACCELERATION コンパイル、デバッグ、最適化 . . . 30
C++ ライブラリを使用した OpenCL イメージングアプリケーションの開発 . . . 36
20
XCELLENT ALLIANCE FEATURES Zynq SoC のハードウェア /ソフトウェア協調設計を支援する MATLAB と Simulink . . . 42
30
42
XCELL SOFTWARE JOURNAL: COVER STORY
The Next Logical Step in C/C++, OpenCL Programming
C/C++、OpenCL
プログラミングの次なる ロジカル ステップ
6
コードの性能を 最大限引き出す新環境
1980 代 年 初 めにザイリンクス が FPGA を 世界で初めて考案、製品化して以来、FPGA は ハードウェア エンジニアにとり、冒険野郎マク
Mike Santarini Publisher, Xcell Publications Xilinx, Inc. mike.santarini@xilinx.com Lawrence Getman Vice President, Corporate Strategy and Marketing Xilinx, Inc. larryg@xilinx.com
ガイバーの万能ナイフのように、何にでも使える プログラマブル ロジック デバイスとして使用さ れてきました。最近、ザイリンクスが SDx ™ シ リーズの 開 発 環 境 (SDAccel ™、SDSoC ™、 SDNet ™ ) を発表したことで、FPGA 設計に未 経験のソフトウェア開発者やシステム エンジニア でも、ザイリンクスのデバイスにより独自のカスタ ム ソフトウェア定義のハードウェアを簡単に作成 できるようになりました。これにより、クリエイ ティブな精神を持つより多くのユーザーが、驚く ような革新を生み出すことが可能になりました。 ザイリンクスとアライアンス メンバー企業が 提供する最新の開発環境やその他のソフトウェ ア開発リソースについて説明しますが、その前 に、プロセッシング アーキテクチャの 進化と、 そのソフトウェア開発への影響について見てい きましょう。
ソフトウェア開発者の受難 2000 年以前の典型的なマイクロプロセッサ は、大きなモノリシック プロセッサ コアが 1 つ と、オンボード メモリ、後はその他の細々とした 部品で構成されていました。当時 MPU は、次 世代のアプリを開発するための比較的分かりや すいプラットフォームでした。それまでの 30 年 間、マイクロプロセッサ ベンダーは 22 ヶ月ご とに ( ムーアの法則の通りに ) 大容量で高性能な デバイスを発表していました。クロック レートを 上げるだけで、性能を向上できた頃でした。当 時最 速のモノリシック MPU であった Intel の Pentium 4 Pro は、4 GHz をちょうど超えた あたりで、その進化は頭打ちになりました。開発 者にとって、このような進化は素晴らしいもので した。世代が変わるごとに、プログラムを複雑化 して、より充実した機能を搭載し、しかも、動作 を高速化することが可能だったのです。
7
XCELL SOFTWARE JOURNAL: COVER STORY
図 1 — Zynq UltraScale+ MPSoC
しかし、2000 年代初めになると、半導体業界の流れが変
と半導体ベンダーは、新世代のより大容量デバイスの製造を
わり、開発者は、新たな流れに合わせることを強いられました。
続け、主に、1 つのシリコンにより多くの機能を集積するこ
この転換のきっかけになったのは、MPU 業界がそのままモ
とで、性能をさらに向上していきました。しかし、従来のプロ
ノリシック MPU アーキテクチャ新製品のクロックを上げ続
グラムは新しい分散アーキテクチャを有効利用できないため、
けたとしたら、シリコン プロセス テクノロジのロード マップ
ソフトウェアの開発者は、複数のプロセッサ コア間で効率的
と、トランジスタの漏れ電流の悪化を踏まえると、近い将来、
に動作するプログラムを開発する方法を考えなければなりま
MPU は太陽と同じ電力密度を持つようになることが分かっ
せんでした。
たことでした。
時期を同じくして、その後の数世代のシリコン プロセス テ
そのため、MPU 業界は、低速なクロック レートで動作す
クノロジでトランジスタ数が劇的な増加を続けたことで、半導
る複数の小型コアに演算を分散させるホモジニアス マルチ プ
体企業では、1 つのシリコン上に異なる種類のコアを集積し
ロセッシング アーキテクチャへと急速に移行していきました。
て SoC にするという、革新的な手法が可能になりました。こ
この新しいプロセッシング モデルを使用して、MPU ベンダー
のヘテロジニアス マルチプロセッサ アーキテクチャにより、
8
アプリケーションをターゲット システム上で適切に動作させ るには、カスタムのソフトウェア スタックを開発する必要が 生じ、エンベデッド ソフトウェアの開発者にはさらなる受難 の時代が訪れました。
FPGA で高速化された処理を OPENCL、C/C++ でプログラムする SDACCEL ザイリンクスの新しい SDAccel 開発環境は、データ セン ター アプリケーション開発者のための完全な FPGA ベース
今、半導体業界の流れが再び、変わろうとしています。しか
のハードウェアおよびソフトウェア ソリューションです ( 図
し、今回の変化は、ソフトウェア開発者にとって歓迎すべき変
2)。SDAccel 環境には、チップ上の FPGA リソースを効率
化です。消費電 力による新しいジレンマに直面して、半 導体
的に使用する、高速なアーキテクチャ最適化コンパイラが含
企業やシステム企業は、MPU と FPGA を密に連携すること
まれています。コード開発、プロファイリング、およびデバッ
で、最小の電力コストでシステム性能を向上できる、FPGA で
グに Eclipse ベースの統合設計環境 (IDE) を採用し、CPU/
高速化されたヘテロジニアス プロセッシング アーキテクチャ
GPU のような使い慣れた作業環境とソフトウェア開発フロー
へと向かっています。この先進のアーキテクチャは、特に、新
を開発者に提供します。この環境を使用すると、その場で入
しいデータ センターのプロセッシング アーキテクチャとして
れ替えるデータ センター アプリケーションに最適化された、
活用されています。今日では有名になったある論文において、
動的にリコンフィギュレーション可能なアクセラレータを作成
MPU と FPGA を組み合わせたアーキテクチャは、わずか
できます。SDAccel 環境により、サーバー CPU と FPGA
10% の消費電力増によって、90% の性能向上がもたらされ、
とのやりとりを中断させることなく、ランタイム中に FPGA 上
MPU に消費電力の大きい GPU を組み合わせたアーキテク
で複数のカーネルを交換するアプリケーションを作成して、ノ
チャと比較して、はるかに優れたワット当たり性能が実現され
ンストップのアプリケーション アクセラレーションを実現でき
たことが、Microsoft の研究者によって報告されていました。
ます。SDAccel 環境は、x86 サーバー プロセッサをベース
FPGA で高速化されたヘテロジニアス マルチプロセッシン
とするホスト システムをターゲットとし、FPGA 機能をプラス
グは、データ センター アプリケーションに留まりません。ザ
する市 販 (commercial off-the-shelf: COTS) の プラグイ
イリンクスの Zynq® -7000 All Programmable SoC を 使
ン PCIe カードを提供します。
用する多数のエンベデッド システムが、ARM プロセッサとプ
SDAccel 環境を使用すると、FPGA 開発の未経験者でも、
ログラマブル ロジックをチップ上で統合することで大きな恩
使い慣れたワークフローによりアプリケーションを最適化し、
恵を 受けています。近日発 売 予定の Zynq UltraScale+ ™
FPGA プラットフォームを活用できます。IDE はコーディング
MPSoC で構築したシステムは、確実に、さらに優れた製品
テンプレートとソフトウェア ライブラリを提供し、コンパイル、
となるでしょう。Zynq UltraScale+ MPSoC では、複数の
デバッグ、幅広い開発目標に対するプロファイリングを可能に
ARM コア ( クワッドコア Cortex ™ -A53 アプリケーション
します。これには、x86 上でのエミュレーション、高速シミュ
プロセッサ、デュアルコア Cortex-R5 リアルタイム プロセッ
レーションを使用した性能検証、FPGA プロセッサ上でのネ
サ、Mali ™ -400MP GPU)、プログラマブル ロジック、複
イティブ実行が含まれます。同環境では、サポート対象のあら
数の層のセキュリティ、安全性の向上、先進的なパワー マネー
ゆる開発目標について、自動インストルメント化挿入を備えた
ジメントを 1 つのデバイスに統合します ( 図 1) 。
データセンター対応 FPGA プラットフォームでアプリケーショ
®
しかし、これらの FPGA で高速化されたヘテロジニアス
ンを実行します。SDAccel は、CPU/GPU 開発者が、使い
アーキテクチャを実際に大 規模 展開できるようにし、ソフト
慣れたワークフローで既存の OpenCL™、C、C++ コードを
ウェア開 発 者 が 使 えるようにするには、FPGA ベンダーは
維持し、再利用しながら、簡単に FPGA アプリケーションに
まったく新しい開発環境を提供する必要がありました。ザイ
移行できるよう設計されています。
リンクスでは、データ センター開発者向け SDAccel、エン
CPU/GPU に近い開発環境を実現するのに大きく貢献して
ベデッド システム開発者向けの SDSoC、ネットワーク ライ
いるのが、SDAccel のライブラリです。SDAccel のライブラ
ン カードのアーキテクトおよび開発者向けの SDNet という
リには、低水準の数学ライブラリと、BLAS、OpenCV、DSP
3 つの開発プラットフォームを用意しました。これらの新環
ライブラリなどの生産性向上のためのライブラリがあります。
境は、開発者が容易にコードの低速な部分をプログラマブル
これらのライブラリは、(RTL ではなく ) C++ で記述されてい
ロジック上にプログラミングすることで高速化が可能となり、
るため、開発およびデバッグのあらゆる工程において、記述さ
最適なシステムを作成するためのツールとして提供します。
れているとおりに使用できます。プロジェクトの初期段階では、 9
XCELL SOFTWARE JOURNAL: COVER STORY
SDAccel — CPU/GPU Development Experience on FPGAs OpenCL, C, C++ Application Code
Environment Compiler
x86-Based Server
Debugger
Profiler
PCIe
Libraries
FPGA-Based Accelerator Boards
図 2 — OpenCL、C、C++ 向けの開発環境 SDAccel は、FPGA を使用したデータセンター アプリケーションの アクセラレーションにおいて、ワット当たり性能を最大 25 倍に向上できます。
開発はすべて CPU ホストで行います。SDAccel ライブラリ
Eclipse IDE を入力として使用するなど、非常にシンプルなエ
が C++ で記述されているため、ある CPU ターゲットに対し
ンベデッド C/C++ アプリケーション プログラミング環境を
てアプリケーション コードとともにコンパイルするだけで ( 仮
提供します。SDSoC は、ヘテロジニアスな Zynq SoC およ
想プロトタイプ作成 )、テスト、デバッグ、初期プロファイリン
び Zynq MPSoC プラットフォームのデプロイメント用の総合
グをすべて、初期段階にホスト上で行うことができます。この
的な開発プラットフォームです ( 図 3)。SDSoC は、フルシ
段階では、FPGA は不要です。
ステムの最適化を C/C++ で行う業界初のコンパイラを搭載 しているだけでなく、システムレベルのプロファイリング、プ
ZYNQ SOC/MPSOC ベースの エンベデッド システム開発用 SDSOC
ログラマブル ロジックを利用したソフトウェア アクセラレー ションの自動化、システム コネクティビティの自動生成、プ
SDSoC は、ザイリンクスの Zynq SoC および 近日発 売
ログラミング時間を短縮するライブラリも提供しています。ま
予 定 の Zynq UltraScale+ MPSoC を プ ロ グ ラムす る エ
た、カスタマーおよびサードパーティ プラットフォーム 開発者
ンベデッド システム開発者向けに設計された開発環境です。
が SDSoC 開発環境内でプラットフォームを使用するための
SDSoC 環 境 は、 ベ アメタル ま た は Linux や FreeRTOS
フローも提供されています。
などのオペレーティング システム 上で 動 作 する使 いやすい 10
SDSoC は、Zynq All Programmable SoC ベ ース の
The SDSoC Development Environment Rapid system-level performance estimation SoC
C/C++ Development
System-level Profiling
MPSoC
Specify C/C++ Functions for Acceleration
• Embedded C/C++ application development experience • System-level profiling • Full system optimizing compiler • Expert use model for platform developers & system architects
Full System Optimizing Compiler
図 3 — SDSoC は、使いやすい Eclipse IDE や、ヘテロジニアスな Zynq All Programmable SoC および MPSoC のデプロイメント用の包括的なデザイン環境を含む、 使い慣れたエンベデッド C/C++ アプリケーション開発環境を提供します。
開 発 ボード (ZC702、ZC706) や サードパー ティ提 供 の 特 定 市 場 向 け プ ラットフォ ーム (ZedBoard、MicroZed、
できます。 従 来 のソフトウェア定 義されたネットワークのアーキテク
ZYBO) 向けの BSP ( ボード サポート パッケージ ) と、ビ
チャが、制約のある Southbound API でコントロール プレー
デオおよびイメージング開発キットを提 供しています。BSP
ンに接続された固定のデータ プレーン ハードウェアを持つの
にはプラットフォームをソフトウェア開発者やシステム アーキ
に対して、Softly Defined Network は、コンテンツ インテ
テクトから抽象化するメタデータが含まれているため、よりス
リジェンスを持ち、よりリッチな Southbound API によって
マートなヘテロジニアス システムの作成、インテグレーション、
コントロール プレーンと接続されたプログラム可能なデータ
検証作業が容易化されます。
プレーンを持ちます。これにより、プロトコルの複雑性に依存
FPGA で高速化されたライン カードの設計と プログラミング用 SDNet SDNet は、C 言 語 に似 た直 感 的な 高 水準言 語を 使 用し てネットワーク ライン カードの要件を設計し、ソフトウェア
しないワイヤスピード サービスのサポート、フローを意識した 柔軟なサービスの提供、100% のラインレートで動作しなが らサービス提供中にアップグレードが可能な画期的な「ヒット レス」アップグレードのサポートなど、さまざまな破壊的イノ ベーションが可能になります。
定義の仕様を作成するための環境です ( 図 4)。この環境を
これらの独自の性能によって、通信事業者や MSO ( マル
使用すると、ネットワーク アーキテクトと開発者は、Softly
チサービス システム オペレータ ) は、既存のサービスを一切
Defined Network を構築し、プログラマビリティとインテリ
中断させることなく、ハードウェアの再検証やトラック ロール
ジェンスを、コントロール プレーンからデータ プレーンに拡張
( 機器取り付け出張サービス ) も必要とせずに、差別化された
11
XCELL SOFTWARE JOURNAL: COVER STORY
SDNet — Software Defined Specification Environment for Networking System Architect
SDNet Specifications
SDNet Compiler
• LogiCORE • SmartCORE • Custom Core • SW Function
Implementation Engineer
HW/SW Implementation
SDK/API
Executable Image
FPGA or SoC
“Softly” Defined Line Card
図 4 — SDNet 環境の使用で、ネットワーク アーキテクトは C と似た言語で仕様を作成できるようになります。 ハードウェア チームがデザインを完成した後、開発者が SDNet を使用して、 現場でカードのプロトコルをアップデートしたり追加したりできます。
12
サービスを動的に提供できるようになります。この動的サービ
National Instruments 社 ( 米国テキサス州、オースティン )
ス プロビジョニングを使用すると、サービス プロバイダは、
のハードウェア開発プラットフォームは、制御および検査シス
利益を拡 大し、市場投 入にかかる期間を短縮するとともに、
テムのイノベーターから熱烈な支持を集めています。National
設備投資費や運用コストを削減できます。ネットワーク機器プ
Instruments 社 の R I/O（Reconfigurable I/O）プラット
ロバイダもまた、Softly Defined Network プラットフォーム
フォームには、ザイリンクスの FPGA と Zynq SoC が使用
を使用することによって同様なメリットがあります。コンテン
されています。National Instruments 社の LabVIEW 開発
ツ識別可能なデータ プレーン ハードウェアを配備し、それを
環境は、使いやすいグラフィック ベースのプログラムで、ザイ
SDNet 環境でプログラムできることで、大きな差別化が可能
リンクスの Vivado ® Design Suite を内部的に実 行できる
になるためです。
ため、National Instruments 社の顧客は FPGA デザイン の詳細を知る必要がありません。実際、ザイリンクスのデバ
エンベデッド開発環境
イスが R I/O プラットフォームの中核に使用されていること
ザイリンクスは、エンベデッド ソフトウェア エンジニアの
を知らない技術者もいるかもしれません。単純に、National
プ ログラミング作 業 を支 援 するため、エンベデッド ソフト
Instruments 社製ハードウェアの LabVIEW 環境でシステム
ウェア開発者がアイデアを効率よく製 造段階に移せるように
をプログラミングするのみで、開発中のデザインの性能をより
設計された、エンベデッド ツールとランタイム環境の総合セッ
高速化することができるのです。
トを提 供しています。ザイリンクス ソフトウェア開発キット
MathWorks® 社 ( 米国マサチューセッツ州、ナティック ) で
(SDK) は、Eclipse ベースの統合設計環境 (IDE) です。こ
は、10 年以上前に MATLAB®、Simulink®、HDL Coder ™、
の SDK は、ザイリンクスの 32 ビット MicroBlaze ™ ソフ
Embedded Coder ® に、完全自動で内部的に実行されるザイ
ト コアが内蔵された Zynq SoC または FPGA をターゲッ
リンクスの ISE® および Vivado ツールを使用して、FPGA の
トとするエディター、コンパイラ、デバッガー、ドライバー、
サポートを追加しました。その結果、ユーザー ( その多くは数
およびライブラリで構成されています。この SDK は、ザイ
学者のアルゴリズム開発者 ) は、アルゴリズムをただ FPGA
リンクス独自の Zynq SoC および MPSoC に組み込まれた
ファブリックで実行するだけで、開発したアルゴリズムの性能
セキュリティや仮 想化ソフトウェア ドライバーなどの先進機
を指数関数的に高速化することができました。
能を、追加設定なしに直接サポートしています。これにより、
ザイリンクスは、10 年以上前に、ISE 開発環境に System
よりスマートかつセキュアな、真に差別化されたコネクテッド
Generator と呼ばれる FPGA アーキテクチャ レベル ツール
システムを生み出すことができます。
を加えました。最近、同ツールが Vivado Design Suite にも
ザイリンクスは、ザイリンクス SoC またはエミュレーショ
搭載され、FPGA 設計を熟知したチームがデザインを微調整
ン プラットフォーム上で動作する Linux ベースのアプリケー
することで、アルゴリズムの性能をさらに引き出すことができ
ションを開発、ブート、実行、デバッグ、メンテナンスするた
るようになりました。このような MathWorks 社とザイリンク
めの包括的なオープンソース リソースのスイートを提 供して
ス テクノロジの組み合わせにより、カスタマー企業によって何
います。これには、サンプル アプリケーション、カーネル構
千もの画期的な製品が生み出されています。
造、Yocto レシピ、マルチプロセッシングおよびリアルタイ
ARM 社、Lauterbach 社、横河ディジタルコンピュータ株
ム ソリューション、ドライバー、フォーラム、多くのコミュニティ
式会社、京都マイクロコンピュータ株 式会 社など、ザイリン
とのつながりが含まれます。Linux オープンソース開発者に
クスの多数のアライアンス メンバー企業から成るエコシステ
とって、学習、開発、関心対象やニーズが似通った他の技術
ムは、SDx とアライアンス環境をサポートする開発ツール群
者との交流に最適な環境といえます。
を提供しています。OS やミドルウェア サポートについては、 Linux、RTOS、ベアメタル、ハイパーバイザ、安全性とセキュ
拡大を続けるパワフルな プログラミング環境のアライアンス
リティを重視した Trust Zone 対応ソリューションなど、さま ざまなソフトウェア オプションが提供されています。
新たな SDx 開発環境や SDK を提供することに加えて、ザ
SDx 環境や、ザイリンクスの広範囲にわたり現在も拡大中
イリンクスはこの 10 年間、特定の市場セグメントで定評のあ
の開発用ソリューションの詳細については、新しいソフトウェ
る開発環境を提供している企業との連携を強化してきました。
ア開発者ゾーンをご覧ください。 13
XCELL SOFTWARE JOURNAL: XCELLENCE WITH SDSOC
SDSoC, Step by Step: Build a Sample Design
ステップバイステップ の SDSoC: サンプル デザインの ビルド Adam Taylor Chief Engineer e2v aptaylor@theiet.org
ZedBoard のサンプルにより、 シームレスな環境でのビルドと 最適化の容易性を実証
14
ザイリンクスが SDSoC ™ 開発環境を発表す
した。当初、デバイスは、技術者の回路図入力に
るまで、標準的な SoC 設計手法には、まった
よってプログラミングされていました (22v10 な
く異なる種類のいくつものエンジニアリング ス
どの黎明期の PLD のプログラムは論理式による
キルが必要でした。通常、システム アーキテク
もの )。ロジック設計と最適化は、通常、電子工
トが要件に基づいてシステムのアーキテクチャ
学の学位の範疇であるため、ハードウェア エン
とサブシステム セグメンテーションを生成した
ジンニアが PLD 開発の大半を行う必要があり
後、ソリューションをハードウェアで実装される
ました。デバイスの寸法と機能が拡張されるにつ
機能 ( ロジック側 ) とソフトウェアで実装され
れ、設計の複雑度が上がり、設計時間と検証時
る機能 ( プロセッサ側 ) に分割します。FPGA
間が増大するため、回路図入力は自然に限界を
エンジニアとソフトウェア エンジニアが それ
迎えました。エンジニアからはより抽象度の高い
ぞ れの 機 能を 別 々に開 発した 後、統 合し、統
作業環境を求める声が高まりました。
合テスト計画に従ってテストします。このよう
そこで、VHDL と Verilog が登場しました。
なアプ ロー チは長年にわたって 有 効に機 能し
どちらの言語も、ロジック デザイン、特に ASIC
てきました が、ザイリンクスの Zynq -7000
を記述し、シミュレーションするための言語とし
All Programmable SoC や、近日発売予定の
て開発されました。VHDL には、独自の MIL 規
Zynq UltraScale+ ™ MPSoC など、SoC の
格（軍用規格）もありました。HDL ( ハードウェ
多機能化が進むにつれ、新しい設計手法が求め
ア記述言語 ) 内でロジック動作を記述している
られるようになりました。
ならば、必要なロジック回路を合成できればい
®
SDSoC の手法が登場したことで、より多く
いのに、という発想に至るのは当然の成り行き
の技術者が、超高性能なシステムを開発できる
です。合成ツールが開発されると、ロジック動
ようになります。SDSoC 開発環境を使用する
作を、一般的に RTL ( レジスタ トランスファー
ことで開発に不慣れな技術者であっても、シス
レベル ) で記述できるようになりました。HDL
テムを動作させることや最適化することが容易
の 導入により、構 造 的 な 検 証を可能にする動
であることが分かるはずです。
作テストベンチが開発できるようになったこと
本稿では、シンプルな代表的サンプルを使用
で、検証手法も劇的に改善されました。さらに、
して、これらの作業を行い、結果を得る方法を
HDL によって、初めて、モジュール化とベンダー
説明します。ここでは、Linux が動作し、組み
独立性が実現されました。
込みサンプルの 1 つ「行列乗算器と加算テンプ
とはいえ、HDL は原理的に並行動作であり、
レート」を使用する ZedBoard をターゲットに
RTL ( レジスタ トランスファー レベル ) の設計
します。
手法およびインプリメンテーション フローには、
設計手法の略史 PLD ( プログラマブル ロジック デバイス ) は 1980 年代に登場して以来、急速に変遷してきま
最適化とタイミング クロージャの知識が不可欠 であったため、PLD 開発作業の大部分は、ハー ドウェア エンジニアの範疇であることに変わり ありませんでした。
15
XCELL SOFTWARE JOURNAL: XCELLENCE WITH SDSOC
使い慣れた環境 SDSoC 開 発 環 境 は、 多 くのソ フト ウェア開 発 者に使い 慣 れた環 境 である Eclipse ベースです ( 図 1)。この環境を 使用すると、デバイスのプログラマブル ロジック (PL) 側の機能をシームレスに高 速化できます。これは、C または C++ のプログラムを扱うことのできる新しい SDSoC コンパイラによって可能になり ました。 最も抽象性が高いレベルでの SDSoC
図 1 — SDSoC の [Welcome] ページ
環境の開発サイクルは次のとおりです。 1. アプリケーションを C または C+ +
HDL は、長年、PLD 開発の事実上の標準として使用され てきましたが、その間、業界のニーズを汲んで進化してきまし た。VHDL だけが、1987 年 (IEEE 採用初年 )、1993 年、 2000 年、2002 年、2007 年、2008 年にアップデート されました。しかし、回路図入力による設計のときと同様に、
で開発します。 2. アプリケーションをプロファイリングして、パフォーマンス のボトルネックを見つけます。 3. プロファイリング情報を使用して、デバイスの PL 側で高速 化する関数を特定します。
HDL は開発期間、検証期間、デバイス機能の増大の壁に突き
4. システムを構成し、SD カード イメージを生成します。
当たりました。
5. ハードウェアをボードに実装後、パフォーマンスをさらに解
PLD の役割が、単なるグルー ロジックから、アクセラレー ション ペリフェラルへ、そして、ついにはシステムの心臓部へ
析し、必要に応じて、アクセラレーション関数を最適化します。
と進化するにつれて、業界では、その進化を利用するための新
SDSoC 環境では、ベアメタル、FreeRTOS、または Linux
しい設計手法が求められるようになりました。近年普及した高
などのオペレーティング システム上でさまざまに動作するア
位合成 (HLS) では、( ザイリンクスの Vivado HLS を使用し
プ リ ケ ー シ ョン を 開 発 で き ま す。ZedBoard、MicroZed、
て ) C/C++ を使用するか、MathWorks® 社の MATLAB® や
Digilent ZYBO Zynq SoC 開 発 ボ ード な ど、 ほ と ん ど の
National Instruments 社の LabVIEW を使用してデザインが
Zynq SoC 開発ボードを直接サポートしています。その結果、
入力されます。このようなアプローチにより、デザインとイン
アプリケーション開発期間を短縮できるだけでなく、その機
プリメンテーションが電子工学 ( ハードウェア）の領域からソフ
能を使用して、カスタムのハードウェア プラットフォームが統
トウェアの領域へと移行していき、PLD 設計が可能な技術者
合できる状態になったときに、独自の下位のハードウェア プ
のユーザー基盤が大きく拡大しました。また、新しい設計手法
ラットフォームを定義することもできます。
®
によってデバイスのさらなるパフォーマンスが引き出され、シ ステムの中核としての PLD の地位が強固になってきました。
SDSoC 環境内でプログラムをコンパイルすると、ビルド処 理の出力として、SD カードから Zynq SoC を構成するため
そのため、SoC ベースの設計で HLS を使用して、技術者
に必要なファイル群が出力されます。このファイル群には、第
がデザインのロジック側の機能をシームレスに高速化できる
1 段階と第 2 段階のブート ローダーのほか、各オペレーティ
高度に統合された開発環境を実現するのは当然のことです。
ング システムに必要なアプリケーションおよびイメージが含
そこで、SDSoC 環境の登場です。
まれています。
16
SDSOC のサンプル SDSoC 環境の使い方をご紹介しながら、どれほど短時間 でサンプルを使用できるか確認しましょう。Linux が動作し、 内蔵の行列乗算器と加算テンプレートを使用する ZedBoard をターゲットとします。 最初の作 業は、通常どおり、プロジェクトの作成です。プ ロジェクトの作成は、[Welcome] ページ ( 図 1) から行うか、 メニューで [File] -> [New] -> [SDSoC Project] を選択し て行います。どちらの場合も、プロジェクト名を入力して、ボー ドとオペレーティング システムを選択するためのダイアログ ボックス ( 図 2) が開きます。 これにより、SDSoC の GUI の左側にある [Project Explorer] 内にプロジェクトが作成されます。このプロジェクト の配下に、それぞれ異なるグラフィック シンボルが付いた次 のフォルダーが表示されます。
• [SDSoC Hardware Functions]: ハードウェア化された機
能が表示されます。最初は、関数をまだハードウェア化して いないため、このフォルダーは空になります。
• [Includes]: このフォルダーを展開すると、このビルドで使
用されている C/C++ ヘッダー ファイルがすべて表示され ます。
• [src]: デモ用のソース コードが含まれています。 SDSoC のインストールと環境だけでなく、開発ボードの構成 も間違いがないことを確認するため、デバイスのオンチップ プ ロセッシング システム (PS) 側のみで実行されるようにデモを 構築します。 もちろん、次のステップは、プロジェクトのビルドです。メ ニューでプロジェクトを選択した状態で、[Project] - > [Build Project] を選択します。ビルドには長い時間はかかりません。 ビルドが完了すると、[Project Explorer] の現在のプロジェク トの配下に、図 3 のようなフォルダーが表示されます。上述の フォルダーの他に、次のフォルダーがあります。
• [Binaries]: ソフトウェア コンパイル プロセスで生成された ELF (Executable and Linkable Format) ファイルが入って います。
• [Archives]: バイナリを作成するためにリンクされたオジェクト
図 2 — プロジェクトの作成
17
XCELL SOFTWARE JOURNAL: XCELLENCE WITH SDSOC
COVER STORY
ファイルが入っています。
• [SDRelease]: ブート ファイルとレポートが入っています。 Zynq SoC の PS 側のみで動作するように構成された最初 のデモを使って、意図した通りに動作しているか確認する方法 を説明します。SDSoC のアクセラレーションは、アプリケー ションをプロファイリングし、技術者がそのプロファイリング された情報を元に、 ハードウェア化する機能を決めることによっ て実現されることを思い出してください。
図 3 — ビルド時の [Project Explorer] タブ
付属ライブラリの sds_lib.h を使用して、基本的なレベルでの プロファイリングを行うことができます。このライブラリには、 64 ビット グローバル カウンターをベースとした基本的なタイ ムスタンプ API が含まれており、各関数の実行にかかる時間を 計測できます。この API は、単に関数の開始時間と終了時間を 記録するもので、その差分がプロセスの実行時間になります。 ソース コードには、行列の乗算および加算用のアルゴリズム として 2 つのバージョンが含まれています。いわゆる「ゴール デン」バージョンは、オンチップ プログラマブル ロジック (PL)
図 4 — PS 側での両関数の実行時間
へのオフロード用ではありませんが、もう一方のバージョンは PL へのオフロード用です。これらを PS 内のみで構築、実行 することで、同等のものを比較しており、両方のプロセスが実 行に同じくらいの時間がかかることを確認できます。 ビルドが完了したら、[Project Explorer] 配下の [SDRelease] -> [sd_card] フォルダー内のすべてのファイルを SD カードに コピーして、カードを ZedBoard に挿入できます ( モード ピン は、必ず、SD カードのコンフィギュレーションにします )。端 末プログラムを接続した状態で、ブート シーケンスが完了後、 プログラムを実 行する必要があります。/mnt/mult_add.elf と入力します ( ここで、mult_add は作成したプロジェクトの 名前です )。私がこのプログラムを ZedBoard 上で実行したと きの結果を図 4 に示します。この図から、2 つの関数の実行 にほぼ同じ時間がかかったことが分かります。 実行時間がほぼ同じであることを確認したので、乗算関数を SoC の PL 側に移します。これは簡単に行えます。 この例の src ディレクトリのファイル構造は、次のように なっています。
• main.cpp: main 関数、ゴールデン計算、タイムスタンプ、 デバイスのハードウェア側で使用される mult および add 関数呼び出しが含まれます。 18
図 5 — [Project Explorer] を使用して 乗算器カーネルを PL 側に移動
• mmult.cpp: ハードウェアにオフロードされる乗算関数が 含まれます。
• madd.cpp: ハードウェアにオフロードされる加算関数が 含まれます。
次のステップでは、これらの関数のうち、1 つだけを SoC の PL 側にオフロードします。これは、次の 2 つの方法のいず れかで行えます。 1. [Project Explorer] 内で、ファイルを展開してファイルに含 まれる関数を表示して、対象の関数を選択した状態で右ク リックして、[Toggle HW/SW [H]] を選択します ( 図 5)。
図 6 — [Outline] タブを使用して 乗算器カーネルを PL 側に移動
2. ファイルを開き、右側の [Outline] タブにも同じように関数 が表示されているので、 そこで同じ操作を行います ( 図 6)。 mmult() 関数をハードウェア内でアクセラレーションするよ う切り替えると、[H] が関数の末尾に付きます ( 図 7)。 また、選択した関数は、[Project Explorer] タブの現在のプ ロジェクトの [SDSoC Hardware Functions] にも表示され るようになります ( 図 8)。この方法で、このデザインでアクセ ラレーション済みのすべての関数を簡単に確認できます。 ここで説明したステップを一度行うと、プロジェクトを次にビ ルドするときに、SDSoC リンカーが自動的に Vivado HLS と
図 7 — ハードウェア内の mmult() 関数
Vivado Design Suite の残りを呼び出し、SoC の PL 側に関 数をインプリメントします。その過程で、 関数のアクセラレーショ ンをサポートする適切なソフトウェア ドライバーが生成されま す。技術者から見て、 デバイスの PL 側への関数のオフロードは、 パフォーマンス向上以外の点で、シームレスになります。 今回は、コンパイルと SD カードのイメージ生成後に、プロ グラムを ZedBoard 上で実行しながら mmult() 関数をハード ウェアに移しました。図 9 に示すように、実行時間 ( プロセッ サ サイクル単位 ) は 52,444 / 183,289 = 0.28 で、デバ
図 8 — アクセラレーション済み関数の特定
イスの PS 側のみで実行したときの実行時間、183,289 プ ロセッサ サイクルのわずか 28% でした ( 図 4)。デバイスの PS 側で実行された同じ関数のパフォーマンスを考えると、簡 単なマウス クリック操作だけで、これほどの実行時間の短縮 が可能ということになります。 本稿では、単純なサンプルを使用して、SDSoC がパワフル かつシームレスな環境であり、HLS 機能が緊密に統合されて いることを実証しました。
図 9 — アクセラレーション結果
19
XCELL SOFTWARE JOURNAL: XCELLENCE WITH SDSOC
Using the SDSoC IDE for System-level HW-SW Optimization on the Zynq SoC
SDSoC 統合開発環境を使用した、 Zynq SoC におけるシステム レベル のハードウェア / ソフトウェア最適化
Daniele Bagni DSP Specialist FAE Xilinx, Inc. danieleb@xilinx.com Nick Ni Product Manager, SDSoC Development Environment Xilinx, Inc. nickn@xilinx.com
20
コレスキー行列分解の サンプルでは、数分で アクセラレーション推定が 可能
ザイリンクスの Zynq ® -7000 All Programmable SoC ファミリは、エンベデッド デザインの新機軸として、かつてな いパフォーマンスとフレキシビリティをエンベデッド システム 開発コミュニティにもたらしました。Zynq SoC では、多機能 なデュアルコア ARM® Cortex ™ -A9 MPCore ™ をベースと するプロセッシング システム (PS) と、ザイリンクスのプログ ラマブル ロジック (PL) が 1 つのデバイスに統合されていま す。同一チップ上の PS と PL は、3,000 を超えるインター コネクトでリンクされているため、プロセッサと FPGA がそれ ぞれに配置される 2 チップ構成では追随できないパフォーマ ンスを誇ります。Zynq SoC は、ザイリンクスが 2011 年に 発表するとすぐに、エンベデッドシステム技術者やハードウェ ア設計言語および手法に精通するアーキテクト、同様にエンベ デッドソフトウェア開発にも大きな人気を集めました。この種 のデバイスとして業界初の Zynq SoC は、現在では、無線イ ンフラストラクチャからスマート ファクトリ、スマート ビデオ / ビジョンといったエンベデッド アプリケーションに採用され、 先進的な自動車運転支援システムでは事実上の標準プラット フォームとして急速に普及しています。 この 注目すべきデバイスを、HDL 設 計は 未 経 験ではある が、ソフトウェア開発に精通しているエンベデッド技術者が使 えるようにするため、ザイリンクスは今年、Eclipse ベースの SDSoC ™ 統合開発環境を発表しました。ソフトウェア技術 者が、Zynq SoC の ARM プロセッシング システムのプログ ラミングだけでなく、プログラマブル ロジックも設計できるよ うにするためです。 本稿では、Zynq SoC [1] の機能を詳しく紹介し、ソフト ウェア技術者が SDSoC 環境を活用して、他のプロセッサ + FPGA の構成では不可能であるシステム設計を行う方法につ いて説明します。説明には、ハードウェア プラットフォームと して、Zynq Z-7020-1 デバイスを搭 載したザイリンクスの ZC702 評価ボード [2] を使用します。 図 1 に示すように、Zynq SoC は、PS ( アプリケーション プロセッサ ユニット、メモリ インターフェイス、ペリフェラル、 およびインターコネクト ) と PL (FPGA ファブリック ) の 2 つの主要機能ブロックで構成されています。 PS と PL は、ARM® AMBA® AXI4 インターフェイス互 換のインターコネクトで密に接続されています。4 つの高性能
21
XCELL SOFTWARE JOURNAL: XCELLENCE WITH SDSOC
Processing System
S_AXI_HP0
2x UART GPIO
NEON/ FPU Engine
NEON/ FPU Engine
S_AXI_HP2
Cortex-A9 MPCore 32/32 KB I/D Caches
Cortex-A9 MPCore 32/32 KB I/D Caches
S_AXI_HP3
512KB L2 Cache
2x SDIO with DMA
General Interrupt Controller
2x GigE with DMA
S_AXI_ACP
Snoop Control Unit (SCU)
Timer Counters
2x USB with DMA
EMIO
S_AXI_HP1
ARM CoreSight Multicore and Trace Debug
2x CAN
256KB On-Chip Memory DMA
Configuration
AMBA Switches
S_AXI_GP0/1
XADC
M_AXI_GP0/1
Multistandard I/Os (3.3V & High Speed 1.8V)
PCIe
Multistandard I/Os (3.3V & High Speed 1.8V)
2x I2C
I/O MUX
System Gates, DSP, RAM
AMBA Switches
AMBA Switches
2x SPI
Programmable Logic:
Dynamic Memory Controller DDR3, DDR2, LPDDR2
Static Memory Controller Quad-SPI, NAND, NOR
Multi Gigabit Transceivers
図 1 — Zynq アーキテクチャの概要
(HP) AXI4 インターフェイス ポートを使用して、PL を PS
使用 )、モデル ベースで行う場合 (Vivado System Gene-
内の AFI ( 非同期 FIFO インターフェイス ) ブロックに接続し
rator for DSP [4] 使用 ) などがあります。
ているため、PL と PS メモリ システム (DDR およびオンチッ プ メモリ ) 間に高スループットのデータパスが確立されます。 AXI4 ACP ( アクセラレータ コヒーレンシ ポート ) を使用す ることで、PL マスタから L1 および L2 キャッシュに直接、 低レイテンシのキャッシュ コヒーレントなアクセスが提供され ます。GP ( 汎用 ) ポートは、PS と PL の両方からアクセス 可能な低パフォーマンスな汎用ポートを構成します。 ザイリンクスの Vivado® Design Suite を使用して、従来 のハードウェア設計中心のフローで Zynq SoC のエンベデッド システムを設計するには、次の 4 つのステップが必要でした。 1. システム アーキテクトが、ハードウェアとソフトウェアの分 割スキームを決定します。演算が集中しているアルゴリズム が、ハードウェア化に適したアルゴリズムです。プロファイリ ング結果を使用して、パフォーマンスのボトルネックを特定 し、データ移動コストとアクセラレーション効果のトレード オフを調査します。
3. 次に、Vivado IP インテグレーター [5] を使用して、エンベ デッド システム全体のブロック ベースの設計を作成します。 システム全体を開発するには、各種データ ムーバー (AXIDMA、AXI Memory Master、AXI-FIFO など ) や、PL IP と PS を接続する AXI インターフェイス (GP、HP、および ACP) を使用する必要があります。IP インテグレーター内 でデザイン ルール チェックにすべて合格すると、プロジェク トをザイリンクス SDK ( ソフトウェア開発キット ) [6] にエ クスポートできます。 4. ソフトウェア技 術 者が、ザイリンクス SDK を 使 用して、 PS 内の ARM プロセッサ用にドライバやアプリケーション を開発します。 近年、ザイリンクスは、IP 開発や IP ブロックの接続 ( 上記 のステップ 2 とステップ 3 の一部 ) にかかる期間を短縮する ため、Vivado Design Suite の使い勝手を向上する取り組み
2. ハードウェア技術者が、ハードウェア用に分割された関数を
に力を注いできました。IP 開発については、Vivado HLS ツー
担当し、IP (Intellectual Property) コアに変換 / 設計し
ル の C/C++ 高 位合 成や、Vivado System Generator for
ます。設計作業は、VHDL や Verilog で行う場合 (Vivado
DSP のモデル ベースの設計など、新しい設計テクノロジを導
使用 ) や、C/C++ で行う場合 (Vivado HLS ( 高位合成 ) [3]
入することで、開発期間や検証期間が劇的に短縮され、抽象度
22
が上がり、デザイン チームがアーキテクチャを把握しやすくな りました。VHDL や Verilog では数週間かかっていた設計作 業が、これらの新しいツールを使用することにより数日で終了
C/C++ Development
することもありました。 Vivado IP インテグレーターの導入により、このフローはさ らに拡張されました。Vivado Design Suite の IP インテグ レーター機能を使用すると、IP ブロックを GUI ( グラフィカ
Rapid system-level performance estimation
ル ユーザー インターフェイス ) 上で接続するだけで、 エンベデッ
System-level Profiling
ド デザインでも非エンベデッド デザインでも、複雑なハード ウェア システムを簡単に設計できるようになり、ハードウェア
Specify C/C++ Functions for Acceleration
システムの統合を迅速に行えます。 これら の 新し い Vivado Design Suite の 機 能 に よって、 Zynq SoC に携わるデザイン チームや開発チームの負担は多 少軽減されました。しかし、ハードウェア中心の最適化ワーク
Full System Optimizing Compiler
フローでは、各種データ ムーバーおよび PS と PL 間のイン ターフェイスの調査 ( ステップ 3 の一部 ) や、ドライバおよび アプリケーションの作成とデバッグ ( ステップ 4) に必要な開 発期間を短縮するためにできることはほとんどありませんでし た。システム全体がスループット、レイテンシ、エリアなどの
図 2 — SDSoC デザイン フローの主なステップ
設計要件を満たさなかった場合、チームは、ハードウェア アー キテクチャに立ち戻って、ステップ 3 のシステム コネクティビ ティを修正する必要があります。この修正を行うと、必ず、ス テップ 4 のソフトウェア アプリケーションにも変更が必要に なります。場合によっては、 アクセラレーション不足やハードウェ ア使用率のオーバーフローによって、元々のハードウェア / ソフ トウェア分割まで立ち戻らなければならない場合もあります。 いくつものハードウェア チーム、ソフトウェア チームが、最終 要件を満たすかもしれないアーキテクチャ候補に対して、同じ ようなシステムの反復を行わなければなりません。 これらの例は、手作業によるシステムの最適化が Time-toMarket に与える影響を示す例です。それでもなお、システム の最適化は、Zynq SoC のように緊密に統合されたシステム にとって極めて重要です。ボトルネックは、多くの場合、PS と PL 間のシステム コネクティビティで発生するためです。 SDSoC 開発環境は、ステップ 2、3、4 の大半を自動化 することで、Zynq SoC の開発プロセスを大きく簡略 化し、 全 体 の 開 発 期間を 大 幅に短 縮します。SDSoC 開 発 環 境 で は、ハードウェアとソフトウェアを同期し、元のプログラムの
セマンティクスを保ち、タスク レベルの並列化とパイプライ ン化された通信および演算で高いパフォーマンスを実現する ために必要なハードウェア コンポーネントとソフトウェア コ ンポーネントがシステムによって生成されます。SDSoC 環境 は、人手のかかる作業は最低限に抑え、必要なすべてのザイリ ンクス ツール (Vivado、IP インテグレーター、HLS、SDK) を自動連携して、Zynq SoC 向けの完全なハードウェア / ソフ トウェア システムを作成します。 PS 用に C/C++ で完全に記述されたアプリケーションが存 在し、PL 用に分割してアクセラレーションする関数がすでに決 まっている場合、SDSoC 開発フローは、大まかに、次のよう に進みます ( 図 2 )。 1. SDSoC 環境は、高速推定フロー ( バックグランドで Vivado HLS を呼び出す ) を使用して、アプリケーション プロジェク トをビルドします。そのため、わずか数分間で、パフォーマン スおよびリソースの概算値が得られます。
23
XCELL SOFTWARE JOURNAL: XCELLENCE WITH SDSOC
4 x 4 のとき、次の MATLAB® コード に示すように、行列 B は、B = L’* L になるように三角行列 L に分解されま す。ここで、L’は L の転置です。 全ビルド サイクルを行うことなく、ア プリケーションから期待されるパフォー マンスとリソース使用率の推定をどの ように行うのかを見てみましょう。 SDSoC 環境に適したテストベンチ 構造を図 3 に示します。main プログ ラムがすべての空行列にダイナミック メモリを割り当て、( ファイルから読み 図 3 — SDSoC 環境向け C/C++ テストベンチの構造
2. 必要な場合、適切な指示子を使用して C/C++ アプリケー ションとハードウェア機能を最適化し、必要なパフォーマンス とエリアが得られるまで、推定を再実行します。 3. SDSoC 環境によって、システム全体をビルドします。この プロセスにより、 Vivado Design Suite のプロジェクト全体、 ビットストリームのほか、Linux、FreeRTOS、ベアメタル でブート可能なランタイム ソフトウェア イメージが生成さ れます。
SDSOC 開発環境を使用した、 ハードウェア対ソフトウェアのパフォーマンス推定 線形代数は、工学のほぼすべての分野において基本かつパワ フルなツールで、多次元の変数を持つ連立方程式全体を計算 的に解くことができます。たとえば、技術者は、線形制御理論 系を「ステート」とステートの変化の行列として記述できます。 画像のデジタル信号処理は、もう 1 つの線形代数の典型的な 適用例です。特に、コレスキー分解による行列反転は、連立方 程式を解いたり、行列を反転したりするのに最も効率的な手法 の 1 つと考えられています。Zynq SoC のハードウェア / ソ フトウェア分割の適用例として、32 ビット浮動小数点表記の 64 x 64 実データのコレスキー行列分解を見てみましょう。 コレスキー分解では、正定値行列を、真に正の対角を持つ、 下三角行列と上三角行列の積に変換します。行列の大きさが
24
出すか、ランダムに生成した ) データを 入れます。次に、リファレンス用ソフト
ウェア関数とハードウェア化候補の関数を呼び出します。最後
また、アクセラレータとデータ モーション コアのそれぞれに
に、main プログラムが両方の関数の計算結果を確認し、実際
クロック周波数を選択できます ( 図 4 の SDSoC プロジェ
の正確性をテストします。
クト ページでは 100 MHz)。
入出力配列ごとに sds_alloc という名前の 特別なメモリ
これで、 「推定高速化」のプロセスを開始できます。数分で
アロケーターが使 用されていることに注意してください。こ
コンパイル 処 理が終わると、Vivado プロジェクト内にすべ
れにより、SDSoC 環境は、ハードウェア アクセラレータの
てのコアおよびデータ モーション ネットワークが生成されま
各 I/O ポート間にシンプル DMA IP を自動的に挿入できま
す。SDSoC 環境では、FPGA ビットストリームとソフトウェ
す。一方、malloc は、物理アドレス空間の 複 数の不連 続な
アのみバージョンのアプリケーション バイナリを含む Linux
ページにまたがる配列を処理可能な、スキャッター ギャザー
ブート イメージが書き込まれた SD カード イメージも生成さ
DMA をインスタンシエートします。シンプル DMA は、エリ
れます。この SD カードから、ZC702 ターゲット プラット
アとパフォーマンス オーバーヘッドの面でスキャッター ギャ
フォーム上で、アプリケーションを実行します。
ザー DMA よりも安価ですが、物理的に連続するメモリを取 得するために sds_alloc が必要です。
ボード上で Linux が起動すると、ソフトウェアのみバージョ ンのアプリケーションを実行できます。このときに SDSoC
ハードウェア化候補のアクセラレータの選択は、SDSoC 環
環境で生成されるパフォーマンス推定レポートを図 5 に示し
境の GUI 上で、特定の関数をクリックするだけです。図 4 に
ます。この図には、cholesky_alt_top 関数をソフトウェア
示すように、cholesky_alt_top ルーチンには、ハードウェア ア
でなくハードウェアで実行した場合の FPGA リソース使用率
クセラレータ化されることを示す「H」のマークが付いています。
(DSP: 26、BRAM: 80、LUT: 15,285、FF: 17,094) と
図 4 — SDSoC プロジェクト ページにおける、ハードウェア アクセラレータ コアとクロック周波数の設定
25
XCELL SOFTWARE JOURNAL: XCELLENCE WITH SDSOC
図 5 — SDSoC で生成されたパフォーマンス、高速化、リソースの推定レポート
図 6: Vivado HLS 合成の推定レポート
26
パフォーマンス高速化 (1.75) の両方が 表示されています。さらに、main アプリ ケーションの 観 点 では、malloc やデー タ転送などの他のソフトウェア オーバー ヘッドにより、システム全体の高速化は少 し低い (1.23) ことが分かります。今回の アプリケーションは SDSoC のフローと 設計手法を説明するための小規模なもの であり、実際の PL には、もっと多くのア クセラレーション対象のルーチンがある はずですが、本稿では扱いません。 SDSoC 環境を使用することで、FPGA
図 7 — リリース ビルド用 Makefile
コンパイルを行うことなく（ハードウェア システムの複雑性によっては合成や配置 配線で数時間を要す） 、このような情報を数分間で生成できま
CK HW クロック サイクル必要だとして ( レイテンシの概念 )、
した。多くの場合、ハードウェア / ソフトウェア分割のシステ
その関数が ARM CPU で実行されたときに FARM MHz のク
ム レベルのパフォーマンスを解析し、設計を迅速に反復してシ
ロック周波数で CK ARM かかるとすると、ハードウェア アクセラ
ステムを最適化するには、この程度の推定で十分です。
レータは、計算時間が同じ場合、ARM CPU と同等のパフォー
パフォーマンス推定結果の理解
マンスを実現します。つまり、CK HW / FHW = CK ARM / FARM です。この論理式から、CK ARM = CKHW *FARM / FHW が得られ
推 定 高速化プロセス用に SDSoC 環 境がアプリケーショ
ます。これは、関数をハードウェアに移行することによる高速
ン コードをコンパイルする際、中間ディレクトリ ( 図 5 の _
化を実現するためにアクセラレータがプロセッサからオフロー
sds) が生成され、この中に中間プロジェクト (Vivado HLS、
ドできる最大のクロック サイクルを表します。
Vivado IP インテグレーターなど ) がすべて保 存されます。
図 6 は、Vivado HLS 合成の推定結果のレポートを示して
特に、プログラム関数の主要部分の実行時間を測定するため
います。クロック周波数 FHW = 100MHz のとき、ハードウェ
に、フリーランニング ARM パフォーマンス カウンター関数、
ア アクセラレータのレイテンシは CK HW = 83,652 サイクル
sds_clock_counter() への呼び出しが元のコードに挿入され
です。ZC702 ボードでは FARM = 666 MHz のため、CK ARM
ます。推定高速化プロセス中に、SDSoC 環境の GUI にター
= CK HW *FARM / FHW = 83,653*666/100 = 557,128 と
ゲット ボードが接続されている必要があるのはこのためです。
なり、結果として得られるハードウェア アクセラレーションは、
図 5 のレポートにあるすべての数値は、これらのカウンターに
図 5 の SDSoC 環境のレポート結果の 565,554 サイクルと
よってランタイム実行中に測定されています。唯一の例外は、
よく一致しています。以上が、実際に配置配線を行ってビルド
FPGA ビルドがすべて ( 配置配線インプリメンテーションを含
しなくても、SDSoC 開発環境を使って、アクセラレータに要
め ) 終わるまでは存在しない、ハードウェア アクセラレーショ
求されるクロック サイクル数を推定できる理由です。
ンされた関数です。そのため、Vivado HLS はハードウェア アクセラレーションされた関数の推定サイクルを ( リソース使 用率の推定とともに )、有効な Vivado HLS 合成ステップ中 に、内部的に、計算します。 ハードウェア化候 補のハードウェア アクセラレータ関数が FHW MHz のクロック周波数で実行され、全計算を行うのに
SDSoC 開発環境によるハードウェア ソフトウェア システムのビルド ハードウェア アクセラレーションが合理的であることが明 らかになった後、SDSoC 開発環境を使用して、ハードウェア およびソフトウェア システム全体をインプリメントできます。 27
XCELL SOFTWARE JOURNAL: XCELLENCE WITH SDSOC
axi_interconnect_M_AXI_GP0 M00_AXI S00_AXI
M01_AXI
S_AXI
dom_locked
bus_struct_reset[0:0]
A
peripheral_aresetn[0:0]
L
ap_ctrl
peripheral_reset[0:0] interconnect_aresetn[0:0]
AP_CTRL
AP_FIFO_OARG_0
cholesky_at_top_0 mb_reset
mb_debug_sys_rst
M_AXIS_0
AP_FIFO_IARG_0
proc_sys_reset_0 aux_reset_in
S_AXI_LITE
S_AXI_0
ap_return[31:0]
interrupt
S_AXI_S2MM
DDR FIXED_IO
IRQ_F2P[1:0]
dout[3:0]
Constant proc_sys_reset_3
M_AXIS_MM2S
proc_sys_reset_0 mb_reset
aux_reset_in
aux_reset_in
bus_struct_reset[0:0]
mb_debug_sys_rst
mb_reset bus_struct_reset[0:0]
mb_debug_sys_rst
peripheral_reset[0:0]
dom_locked
peripheral_reset[0:0]
dom_locked
FIXED_IO
ZYNQ7 Processing System acp_axcache_0xF
mm2s_prmry_reset_out_n
DDR
USBIND_0 M_AXI_GPO
AXI4-Stream Accelerator Adapter
M_AXI_MM2S
AXI Direct Memory Access
PTP_ETHERNET_0 S_AXI_ACP
AXI Direct Memory Access
datamover_0 S_AXI_LITE
M_AXIS_S2MM s2mm_prmry_reset_out_n
ap_oscalar_0_din[31:0]
Cholesky_alt_top (Pre-Production)
Processor System Reset
ps7
datamover_1
cholesky_alt_top_0_if
M02_AXI
AXI Interconnect
interconnect_aresetn[0:0] peripheral_aresetn[0:0]
Processor System Reset
Processor System Reset
proc_sys_reset_2
axi_interconnect_S_AXI_ACP
mb_reset
S00_AXI S00_AXI_arcache S01_AXI
aux_reset_in M00_AXI
S01_AXI_awcache
AXI Interconnect xlconcat
bus_struct_reset[0:0]
mb_debug_sys_rst dom_locked
peripheral_reset[0:0] interconnect_aresetn[0:0] peripheral_aresetn[0:0]
Processor System Reset
dout[1:0]
Concat
図 8 — SDSoC 環境による IP インテグレーター ブロック ベースのデザイン
そのためには、単に、( プラグマ コマンドの形式で ) 適切な
Format) ファイルが得られます。その後、ZC702 ボードでパ
指示子を追加するだけです。各プラグマ コマンドを使用して、
フォーマンスを測定すると、ソフトウェアのみでは 995,592
(I/O 配 列 の順 次 スキャンによる ) FIFO インターフェイス、
サイクル、ハードウェア アクセラレーションでは 402,529
アクセラレー タ呼 び 出し のためにランタイムに 転 送さ れる
サイクルになります。したがって、cholesky_alt_top 関数の
データ量、PL の IP コアと PS の IP コアを接続する AXI ポー
実効パフォーマンス ゲインは、2.47 です。
トの種類、およびデータ ムーバーの種類を指定できます。次
SDSoC 環境が Vivado IP インテグレーターのブロック図
の C/C++ コードは、これらの指示子の適用例を示していま
を読みやすいように HTML ファイルとして出力 ( 図 9) した
す。実際には、最後の指示子は必要ありません。sds_alloc
ときに生成された、エンベデッド システム全体のブロック図を
が使用されているため、SDSoC 環境はシンプル DMA をイ
図 8 に示します。このレポートでは、ハードウェア アクセラレー
ンスタンシエートするからです。ここでは、分かりやすくするた
タは、ACP ポートを使用してシンプルな AXI4-DMA を介し
めに記載しています。
て接続されており、アクセラレータの設定は、GP ポートを使
SDSoC 環 境 の GUI で 直 接、プ ロジェクトをリリース構 成でビルドすることも、図 7 に示す Makefile を使 用して、
用して AXI4-Lite インターフェイスを介して行われていること が分かりやすく表示されています。
SDSoC Tcl ( ツール コマンド言語 ) インタープリタから開始
エンベデッド システムが動作する ZC702 ボード用の SD
することもできます。Vivado Design Suite の他のツールと
カードを生成するのに、どれくらいの時間がかかったでしょう
同様に、設計者は、GUI か Tcl スクリプトのいずれも使用で
か。Vivado HLS と SDSoC 環境の両方に適した C++ テス
きます。高速化のメリットを向上するには、ハードウェア アク
トベンチを記述するのに 1 日、線形代数 HLS ライブラリか
セラレータのクロック周波数を FHW =142 MHz に上げます
ら良い結果を得るための実験に 1 時間、SDSoC 環境でエン
(-clkid 1 makefile フラグで設定 )。
ベデッド システムを生成するのに 1 時間 (FPGA コンパイル
FPGA のコ ンパイル に は 30 分 も か か りま せ ん。 完 了
プロセス )、合わせて 10 時間かかりました。これらすべての
すると、ZC702 ボード をプ ログラムするビットストリーム
作業を手作業で ( ステップ 3 を Vivado IP インテグレーター
と、Linux OS 上 で 実 行 す る ELF (Executable Linkable
で、ステップ 4 をザイリンクス SDK で ) 行った場合、ツール
28
参考文献
を効率的に使用するために必要な経験を無視しても、フルタイ ムの困難な作業を少なくとも 2 週間は行う必要があると推定
1. UG1165、Zynq-7000 All Programmable SoC:
されます。
エンベデッド デザイン チュートリアル
SDSoC 開発環境を使用すると、エンベデッド システムと
2. UG850、Zynq-7000 XC7Z020 All Programmable
ソフトウェアの開発者のより広いコミュニティが、これまでの
SoC 向け ZC702 評価ボード ユーザー ガイド
エンベデッド C/C++ 開発経験を元に、Zynq SoC 向けの 開発を行えるようになります。SDSoC 環境は、業界で初めて、
3. UG871、Vivado Design Suite チュートリアル: 高位合成
フルシステムの最適化を C/C++ で実現するコンパイラを搭
4. UG948、Vivado Design Suite チュートリアル: System
載しており、システム レベルのプロファイリング、プログラ
Generator を使用したモデル ベースの DSP デザイン
マブル ロジックを利用したソフトウェア アクセラレーション
5. UG994、Vivado Design Suite ユーザー ガイド:
の自動化、システム コネクティビティの自動生成、開発スピー
IP インテグレーターを使用した IP サブシステムの設計*
ドを上げるライブラリを提 供します。ツールの入手方法など の 詳 細 に つ い て は、http://japan.xilinx.com/products/
6. UG782、ザイリンクス ソフトウェア開発キット (SDK)
design-tools/software-zone/sdsoc.html を参照してくだ
ユーザー ガイド
さい。
＊は日本語版、それ以外は英語版になります。
Data Motion Network Accelerator
Argument
IP Port
Direction
Declared Size (bytes)
Pragmas
Connection
cholesky_alt_top_0 A A IN 4096*4
• length: (BUF_SIZE) S_AXI_ACP:AXIDMA_SIMPLE • sys_port:ACP
L L OUT 4096*4
• length: (BUF_SIZE) S_AXI_ACP:AXIDMA_SIMPLE • sys_port:ACP
return AP_return OUT
4
M_AXI_GP0:AXILITE:0xC0
Accelerator Callsites Accelerator Callsite IP Port Transfer Size (bytes) Paged or Contiguous cholesky_alt_top_0 cholesky_alt_tb.cpp:246:23
Cacheable or Non-cacheable
A
(BUF_SIZE) * 4
contiguous
cacheable
L
(BUF_SIZE) * 4
contiguous
cacheable
ap_return
4
paged
cacheable
図 9 — SDSoC のコネクティビティ レポート
29
XCELL SOFTWARE JOURNAL: XCELLENCE WITH SDACCEL
Compile, Debug, Optimize
コンパイル、デバッグ、 最適化 Jayashree Rangarajan Senior Engineering Director, Interactive Design Tools Xilinx, Inc. jayr@xilinx.com Fernando Martinez Vallina Software Development Manager, SDAccel Xilinx, Inc. vallina@xilinx.com Vinay Singh Senior Product Marketing Manager, SDAccel Xilinx, Inc. singhj@xilinx.com
30
ザイリンクスの SDAccel 開発環境は、 FPGA 向けソフトウェア アプリケーションデザイン フローで開発が可能 ザイリンクスの FPGA デバイスは、主に、アプリケーショ
OpenCL C、C、C++ 向けの SDAccel 開発環境を使用す
ン設 計 者が空間的、時間的な並列化を使 用できるようにし、
ると、CPU や GPU で 使 用されるプ ロセスと似 た 方法 で、
大 規 模アプリケーションのアルゴリズムまたはクリティカル
FPGA デバイス用アプリケーションのコンパイル、デバッグ、
カーネルのパフォーマンスを最大限にするプログラマブル ロ
最適化を行うことが可能になり、データ センター アプリケー
ジック ファブリックを備えています。このファブリックの中核
ションのアクセラレーションで最大 25 倍のワット当たり性能
には、ルックアップテーブル ベースのロジック エレメント、分
を達成できます。
散メモリ セル、積和演算ユニットの配列があります。設計者は、
ソフトウェア設計者は、SDAccel 開発環境を使用して、多
これらの要素をさまざまな方法で組み合わせてアルゴリズム
くのファンクションやアプリケーションを作成し、アクセラレー
のロジックをインプリメントしながら、消費電力、スループット、
ションできます。Median フィルター アプリケーションについ
レイテンシの設計目標を達成できます。
て、SDAccel 環境でコンパイル、デバッグ、および最適化の
FPGA ファブリック エレメントを組み合わせてロジック機
デザイン ループを実現する方法について解説します。
能を実現する作業には、現代的なソフトウェア設計手法より は、アセンブリ レベルのコーディングに類似したプロセスが
Median フィルター
含まれるため、長年にわたり、FPGA 設計はハードウェア技
Median フィルターは、画像処理でノイズ除去のためによく
術者の領域とされてきました。一般的なソフトウェア設計手
使用される空間的ファンクションです ( 図 1)。Median フィル
順でアセンブリ言語が使われなくなってすでに久しいですが、
ターのアルゴリズムでは、真ん中の 1 つのピクセルを中心にし
CPU と FPGA のコンパイルの性質の違いにより、FPGA 設
た 3 x 3 のピクセル ウィンドウを使用して、すべての隣接値
計手法の進化はゆっくりとしたペースで進みました。
の中央値に基づいて、真ん中のピクセル値を計算します。この
CPU や GPU の 場 合、ハードウェアは決まっており、す べてのプログラムは静的な ISA ( インストラクション セット
処理の論理式は、次のようになります。
アーキテクチャ ) に対してコンパイルされます。ISA は CPU、 GPU の種類によって異なりますが、基本となるコンパイル テ クニックは共通です。このような共通点の影響もあり、アセン ブリ コードの手入力による設計から、ソフトウェア開発で一 般的な OpenCL ™ C、C、C++ プログラミング言語を使用 したコンパイル、デバッグ、最適化設計手順まで進化すること ができました。 FPGA デザインの場合、設計者は、特定のワークロードを 実行するために、独自のプロセッシング アーキテクチャを作
コンパイル
成できます。各システムのニーズに合わせてアーキテクチャを
Median フィルターの機能を OpenCL C などのプログラム
カスタマイズできることは、FPGA の大きな利点ですが、ソ
言語で取り込んだら、最初の開発工程はコンパイルです。CPU
フトウェア開発の手順を FPGA アプリケーションの開発に適
や GPU では、コンパイルは、ソフトウェア デザイン フロー内
用する際の障壁にもなっていました。
で必須かつ当然の工程です。ターゲットの ISA が固定かつ既
ザイリンクスは 6 年前に、この障壁を克服するための研究
知であるため、プログラマは、利用できるプロセッシング コ
開 発に着 手し、直 感 的なソフトウェア開 発 デザイン ル ープ
ア数とアルゴリズムのキャッシュ ミスについてだけ考えれば良
を FPGA に導入した開発環境 SDAccel ™ を開発しました。
いのです。しかし、FPGA のコンパイルは、自由回答の問い
31
XCELL SOFTWARE JOURNAL: XCELLENCE WITH SDACCEL
のようなものです。コンパイル時には、まだ、ターゲット ISA
ループ伝搬依存性がないことを把握します。各ループは、異な
は存在せず、ロジック リソースはプロセッシング ファブリッ
る物理リソース上に保存可能な専用の RGB コピーを持ってい
クに組み込まれておらず、システム メモリ アーキテクチャも
ます。SDAccel 環境がこのコードから導き出されるもう 1 つ
定義されていません。
の重要な特性は、getMedian 関数呼び出しの独立性です。
このような難題に取り組むプログラマをサポートするため、
図 2 に示すアルゴリズムは、getMedian 関数を、固定さ
SDAccel 開発環境のコンパイラは、ループ内もしくはルー
れた境界を持つ「for」ループ内で実 行します。SDAccel 環
プ間のステートメントにおける並列化の自動抽出、配列の読
境は、フィルターのパフォーマンス目標と選択した FPGA に
み出し / 書き込みパターンに基づいたメモリ アーキテクチャ
応じて、全 3 つのチャネルの間で計算リソースを再利用する
の自動推定、FPGA デバイス内の基本的ロジック エレメント
か、ロジックの割り当てを増やして空間的並列化を行い、す
の種類と数のアーキテクチャ的把握という、3 つの機能を提
べてのチャネルを同時に実行するか選択できます。この選択
供します。この 3 つの機能の重要性を、Median フィルター
により、配列 RGB のメモリ ストレージの実装方法が影響を
のソース コードを例に説明します ( 図 2)。
受けます。
Median フィルターの処理は、2 つの主なセクションを持
アプリケーション プログラマからは、上記のステップは透過
つ 一 連 のネステッド ル ープ で 表 現されています。このアル
的で、GCC (GNU Compiler Collection) の –O1 から –O3
ゴリズムの 1 つ目のセクションは、input という名前の外部
への最適化とみなすことができます。
メモリから配列からデータを取得し、その値をローカル配列 RGB に保存します。2 つ目のセクションは、getMedian 関 数の「for」ループです。getMedian は、計算処理が行われ る関数です。
デバッグ ソフトウェア開発の原理原則は、アプリケーションがコンパ イルできたからといって、アプリケーションが正しく動作する
SDAccel 環境は、図 2 のコードを解析して、配列 RGB に
とは限らないということです。アプリケーションがターゲット
図 1 — Median フィルターの動作
32
ハードウェア上で起動できてはじめて、プログラマがエラーを 発見、追跡、修正する作業 ( すなわちデバッグ ) をできるよう になります。 CPU アプリケーションのデバッグの問題はよく理解されてお り、商用ベンダーからも、オープンソース コミュニティからも、 問題を解決するために多数のツールが提供されています。ここ でも、FPGA は異なります。アプリケーション プログラマは、 指定されたパフォーマンス目標でコードの機能を実装するため に作られたものを、どのようにデバッグするのでしょうか。 SDAccel 開発環境は、CPU の世界から printf と GDB デバッグという 2 つの概念を流用することで、この問いに答 えます。 printf 関数は、ソフトウェア プログラマが使う基本的なツー ルです。あらゆるプログラミング言 語に存 在し、プログラム 実行中に主要なアプリケーション変数の状態を表示できます。 CPU デバイスでは、レジスタのステータスをモニタするだけ のシンプルなものです。printf の機能を実装するためにハー ドウェアのコストは必要ありません。 FPGA では、printf を実装することで、アルゴリズム機能 を実装するはずのロジック リソースが消費されることがあり ます。SDAccel 環境では、ロジック リソースを余計に消費 することなく、printf を実装可能です。これは、printf データ の生成をデコード レイヤーおよびユーザー プレゼンテーショ ン レイヤーから分離することで可能になりました。ハードウェ ア リソースの観点からは、printf 用データの生成に使用される レジスタは数個であり、レジスタを多く持つ FPGA ファブリッ 図 2 — Median フィルターのコード
クでは無視できるコストです。データのデコードは、FPGA の ドライバーで行われます。ホスト CPU を使用して printf 用の
図 3 — メモリ アクセス処理のトレース
33
XCELL SOFTWARE JOURNAL: XCELLENCE WITH SDACCEL
データ デコード レイヤーおよびプレゼンテーション レイヤーを 実行することで、ソフトウェア プログラマは FPGA リソースに かかるコストは実質ゼロで、printf を実行できます。 CPU から流用した 2 つ目のデバッグ テクニックは、GDB (GNU Project Debugger) などのツールを使用して、ブレー クポイントやシングル ステップ スルー コードを挿入すること です。プログラマは、SDAccel 環境のエミュレーション モー ドを使用することで、実行中のエミュレーション プロセスに GDB を付加できます。エミュレーション プロセスは、アプリ ケーション固有のハードウェアのシミュレーションで、FPGA デバイス上で開発者が行います。エミュレーション プロセス において、GDB は変数の状態を監視して、ブレークポイント とシングル ステップ スルー コードを挿入します。アプリケー ション プログラマから見ると、これは、CPU 上での GDB の 動作とまったく同じになります。
最適化 コンパイルとデバッグが終わると、ソフトウェア開発サイク ルの次のステップは、アプリケーションの最適化です。FPGA におけるアプリケーション最適化は、原則としては CPU と同 じです。ただし、アプローチが異なります。CPU の場合、プ ロセッサのキャッシュや演 算ユニットの限界値に収まるよう に、アプリケーション コードを調整します。FPGA では、そ
図 4 — 明示的なバースト メモリ転送を行った Median フィルター コード
のアプリケーションに応じて、ロジック計算をカスタムで構築 します。そのため、FPGA のサイズとアプリケーションのパ
ケーション コード内に明示的に、外部メモリからローカル メ
フォーマンス目標によって、最適化の制約が決まります。
モリへのバースト処理を記述することです。図 4 に抜粋する
SDAccel 環境のコンパイラは、計算ロジックを自動的に最
コードでは、OpenCL C カーネルで採用されている async_
適化します。プログラマは、コードから推 測されるデータ転
work_group_copy 関数を使用しています。この関数を呼び
送パターンを分析して、自動最適化を向上できます。図 3 は、
出す目的は、各メモリ処理を複数のデータ値を含むバーストに
Median フィルターのコードの入出力時のメモリへの読み出し
することをコンパイラに伝えることです。これにより、ターゲッ
/ 書き込み処理を示しています。
ト デバイスの有効メモリ帯域幅を効率的に使用し、全体のメ
プ ロットの 各 縦 線はメモリ処 理を 表します。緑 の 横 線は、
モリ処理回数を削減できます。図 4 のコードでは、async_
Median フィルター機能の実 行時間を示しています。このプ
work_group_copy 関数は、DDR メモリの入力イメージの全
ロットから、Median フィルターは常にアクティブであるもの
行の内容を、カーネル データパス内のメモリに移します。
の、各メモリ処理の間に、間隔がかなりあいていることが分
図 5 のメモリ処理トレースは、async_work_group_copy
かります。この間隔は、Median フィルターが 処理を切り替
を使用した結果を表しています。図 5 に示すように、カーネル
えるために必要な時間を表しています。各メモリ処理は 1 つ
には、メモリ処理を行う前に、元の Median フィルター コー
の 値しかアクセスしないため、メモリ処理間の間隔は、この
ドには存在しないセットアップ時間がかかります ( 図 2)。
アプリケーションにとって重要なパフォーマンス ボトルネック になります。 このパフォーマンスの問題を解決する 1 つの方法は、アプリ
34
このセットアップ時間の差は、コードのロジックと関係があり ます。図 2 の元のコードでは、1 回のメモリ処理を即座に実行 した後、次のデータが利用可能になるのを待機していました。
図 5 — コード最適化後のメモリ アクセス処理トレース
対照的に、図 4 の最適化後のコードでは、メモリ処理が必要
変更の影響やアプリケーション要件を評価できます。
かどうか、もしくはデータがすでにカーネルのローカル メモ
コンパイル、デバッグ、最適化の作業から成るデザイン ルー
リ内にあるかどうかを確認します。また、生成されたロジック
プは、ソフトウェア開発フローの基本です。SDAccel 開発環
で、引き続きメモリ処理をスケジュールしたり、読み出し処理
境を使用すると、CPU の開発環境に似たツールとテクニック
と書き込み処理を同時に行うこともできます。
を使用して、最大 25 倍のワット当たり性能、50 ～ 75 倍
最終デバイスが CPU であろうと FPGA であろうと、プロ
のレイテンシ性能向上といった FPGA ならではのアプリケー
ファイリングはアプリケーション開発にとって極めて重要な工
ション高速化が 可能です。SDAccel を使 用すると、ハード
程です。SDAccel 環 境の仮 想化およびプロファイラー機能
ウェア設計の細部までは理解していないソフトウェア プログ
を使用することで、アプリケーション プログラマは、カーネ
ラマでも、ロジック ファブリックの柔軟性を活用して、高性能、
ル占有率、メモリ処理、メモリ帯域幅使用率の面で、コード
低消費電力のアプリケーションを設計できます。
XCELLで日々の情報を入手してください！ ザイリンクスは、数々の受賞歴がある Xcell Journal をさらに拡充し、エキサイティングな
Xcell Daily Blog（英文）を始めました。このブログでは、コンテンツを頻繁に更新し、 エンジニアや開発者の皆様が、ザイリンクスの製品とエコシステムの多岐にわたる情報を入手できます。
ハードウエア エンジニア
ソフトウエア エンジニア
最新ブログ
Thinking of switching to Xilinx? Read this Dual-voltage 20nm Virtex UltraScale devices appear on the Xilinx Secret Menu. Sip power or go fast and draw a bit more power Video shows GTR and GTH SerDes ports operating on 16nm Xilinx Zynq UltraScale+ MPSoC Tiny 100x62mm, Zynq-based Avnet PicoZed SDR implements 2x2 MIMO, 70MHz to 6GHz radio using ADI RF Agile Transceiver ARTY—the $99 Artix-7 FPGA Dev Board/Eval Kit with Arduino I/O and $3K worth of Vivado software. Wait, What????
35
XCELL SOFTWARE JOURNAL: XCELLENCE WITH SDACCEL
Developing OpenCL Imaging Applications Using C++ Libraries
C++ ライブラリを使用した OpenCL イメージング アプリケーションの開発
36
Stephen Neuendorffer Principal Engineer, Vivado HLS Xilinx, Inc. stephenn@xilinx.com Thomas Li Software Engineer, Vivado HLS Xilinx, Inc. thl@xilinx.com Fernando Martinez Vallina Development Manager, SDAccel Xilinx, Inc. vallina@xilinx.com
ザイリンクスの SDAccel 開発環境、 既存のライブラリを活用して アプリケーション設計の スピードを向上
イメージング アプリケーションは、近年、映画やビデオのオ ンライン配信、ロボット工学、運転支援アプリケーションが急 速に広まるにつれ、規模と普及率の両面で拡大してきました。 イメージング分野のコア アルゴリズムは互いに非常に似通って おり、アプリケーション開発者が市場と展開ターゲットに応じ て製品を迅速にリターゲットして差別化できる開発手法が求め られています。 このようなニーズの結果、イメージング アプリケーションは、 通常、CPU をターゲットにしたソフトウェア プログラムとして 最初に開発し、標準関数へのライブラリ呼び出しを使用します。 ソフトウェア設計の手法と、即使用可能なライブラリを組み合 わせることで、デスクトップ上で開発を開始し、機能的に正確 なアプリケーションを作成できます。 開発者にとって難しいのは、実行ターゲットに合わせてイメー ジング アプリケーションを最適化することです。ザイリンクス の Vivado® HLS のテクノロジを応用した SDAccel ™ 開発環 境を使用すると、FPGA をターゲットとする OpenCL™ アプ リケーションでの開発において、C++ ライブラリをそのまま利 用できるようになります。
並列計算タスク セット イメージング アプリケーションの重要な特長の 1 つは、基 本的に、ある 1 つのピクセルに対して、そのピクセルの空間 的 ( アプリケーションによっては時間的 ) 周囲に隣接する複数 のピクセルを比較して行われる一連の処理であることです。し たがって、開発者にとって、イメージング アプリケーションとは、 CPU、GPU、または FPGA 上で実行できる 1 組の並列計算 タスクとみなすことができます。 CPU は、常に、開発を始める際に最も容易なターゲット デ バイスになります。通常、最適化を検討する前の段階でコード がすでに CPU 上で動作しており、提供されている豊富なライ
37
XCELL SOFTWARE JOURNAL: XCELLENCE WITH SDACCEL
DDR memory
HOST
DDR memory
DEVICE
PCIe
図 1 — 基本的な OpenCL プラットフォームには、1 つのホストと、少なくとも 1 つのデバイスが含まれます。
ブラリを利用できます。イメージング ワークロードを CPU 上
います。しかし、GPU のケースと同様に、ソフトウェア アプ
で実行する際に問題となるのは、持続的で達成可能なパフォー
リケーション開発者が慣れ親しんだ方法で FPGA プログラム
マンスです。キャッシュ ヒット / キャッシュ ミス、 複数のスレッ
を実現できる OpenCL 規格を採用したことで、プログラミン
ドを マルチ CPU コアに分散して実行する並列化の処理が困難
グ モデルの障壁を乗り越えることができました。
である場合は、全体的なパフォーマンスが制限されます。 GPU は、ハードウェアがイメージング ワークロード用に設
OpenCL フレームワーク
計されているため、イメージング アプリケーションについて
OpenCL フレ ームワー クは、デー タ並 列プ ログラムを 記
CPU より高いパフォーマンスが見込めます。何年か前までは、
述 するため の 共 通 のプ ログラミング モ デル を 提 供しま す。
一般的なイメージング アプリケーション向けの GPU には、プ
OpenCL フレームワークは、現在業界標準となっており、こ
ログラミング モデルの問題がありました。GPU のプログラミ
の規格をサポートするすべてのデバイス ベンダー間で、同じ
ングは CPU とは異なっており、また、GPU のプログラミン
プラットフォームとメモリ モデルを使用します。デバイスは、
グ モデルは、GPU デバイス ファミリ間で移植することもでき
CPU、GPU、FPGA を問わず、OpenCL カーネルを実行可
ませんでした。この問題は、OpenCL フレームワークのもとで
能な任意のハードウェアとして定義されています。
GPU などに、並列システム向けプログラミングの標準化によっ て変化を与えました。 FPGA も、イメージング ワークロードのインプリメンテー
OpenCL アプリケーションのプラットフォームは、アプリケー ションを実行するハードウェア環境を定義します。OpenCL プ ラットフォームの主な構成要素を図 1 に示します。
ションに使用できます。FPGA ロジック ファブリックをカスタ
OpenCL のプラットフォームには、常に１つのホストが存在し
マイズすることで、ワークロード固有の回路を作成できます。
ます。通常、このホストはプロセッサ上に実装されており、デ
FPGA ファブリックは柔軟性が高く、アプリケーション開発者
バイスのタスク開始と、ホストとデバイス間のデータ転送の明
は、ASIC 設計のようにコストや労力をかけずに、カスタム ロ
示的な調整を行います。
ジックによるパフォーマンス向上と消費電力の削減が可能です。
ホストの他に、デバイスが少なくとも 1 つあります。Open
GPU と同様に、FPGA デバイス採用の障壁となっていた問
CL プラットフォームにおけるデバイスは、OpenCL カーネル
題の 1 つが、プログラミング モデルでした。従来、FPGA は
コードを実行可能なハードウェア要素です。OpenCL アプリ
Verilog や VHDL などの RTL ( レジスタ トランスファー レベ
ケーションにおいて、カーネル コードとは、アルゴリズムの中
ル ) 言語を使用してプログラムされていました。これらの言語
で、アクセラレーションを要する計算集約型の部分を指します。
で並列化を表現することは可能ですが、その粒度は、CPU や GPU をプログラムするのに必要なレベルをはるかに下回って
38
デバイスが CPU もしくは GPU の場合、カーネル コードは、 デバイスに搭載されている 1 つまたは複数のコア上で実行され
ます。各コアは、デバイス仕様に従って完全に同一であるとい
メモリ モデルの主な構成要素は、ホスト メモリ、グローバ
う制約があるため、アプリケーション開発者は、カーネル コー
ル メモリ、ローカル メモリ、プライベート メモリです。ホス
ドを変更することで、固定されたアーキテクチャの中で最大の
ト メモリは、ホスト プロセッサのみがアクセスできるメモリ
パフォーマンスを引き出そうとします。
空間です。FPGA ( デバイス ) から可視できるメモリ空間は、
逆に、FPGA では、そのアプリケーション カーネルの計算要
グローバル メモリ、ローカル メモリ、およびプライベート メ
件に合わせて、SDAccel 開発環境によってカスタムのコアを作
モリです。グローバル メモリは、ホストとデバイスの両方がア
成します。アプリケーション開発者は、 アルゴリズムの目的に従っ
クセスでき、通常、FPGA に接続される DDR として実装さ
て、インプリメンテーション アーキテクチャに自由に手を加え、
れます。アクセラレーション ボードで使用する FPGA によっ
システム全体のレイテンシや消費電力を低減できます。
ては、グローバル メモリの一部を FPGA ファブリックの内部
OpenCL の 2 つ目の構成要素は、メモリ モデル ( 図 2) で
に実装することもできます。ローカル メモリとプライベート メ
す。このモデルは、全ベンダー共通で、ひとつのメモリ階層を
モリは、FPGA ファブリック内で実行するカーネルのみから
定義します。開発者は、このメモリ階層に対して、移植可能な
可視が可能であり、完全にファブリック内で、ブロック RAM
アプリケーションを開発できます。
(BRAM) とレジスタ リソースを使用して構成されます。
Host Memory
Constant Global Memory
Global Memory
FPGA
On-chip Global Memory Kernel A
Host
PCIe
Kernel B
Compute Unit 0
Local Memory Private Memory
Private Memory
PE
Private Memory
Compute Unit 1
Local Memory Private Memory
Private Memory
PE
Private Memory
Compute Unit 0
Local Memory Private Memory
Private Memory
Private Memory
Compute Unit 1
Local Memory Private Memory
Private Memory
PE
Private Memory
PE
図 2 — OpenCL メモリ モデルは、アプリケーション開発のための単一のメモリ階層を定義します。
39
XCELL SOFTWARE JOURNAL: XCELLENCE WITH SDACCEL
Left camera
Viewing ray
Right camera
図 3 — マルチカメラ処理の概念図
それでは、ステレオ イメージング ブロック マッチング ア
れたカーネルを、OpenCL C で記述されたカーネルと同じよ
プリケーションを 例に、SDAccel 環 境 で OpenCL および
うに扱えます。アプリケーション開発者は、Vivado HLS で最
C++ ライブラリを使用する方法を説明しましょう。
適化済みの C++ ライブラリおよびコードを使用して、生産性
ステレオ ブロック マッチング ステレオ ブロック マッチングでは、2 つのカメラの画像を
を向上できます。 ステレオ ブロック マッチング アプリケーションの主なコード を次のページに示します。
使用して、両カメラの視野にあるオブジェクトの形状を表現し
Vivado HLS は、一般的な OpenCV フレームワークに基づ
ます。図 3 に示すように、このアルゴリズムは、左カメラと右
く画像処理関数を提供しています。これらの画像処理関数は
カメラの入力画像を使用して、画像間の対応部分を探します。
C++ で記述されており、FPGA で高いパフォーマンスを発揮
このようなマルチカメラ画像処理タスクは、奥行きマップ、画
するよう最適化されています。FPGA インプリメンテーション
像分割、前景背景分離などに適用できます。これらはすべて、
に合成されると、1 クロック サイクルごとに RISC プロセッサ
運転支援システムの歩行者検出アプリケーションなどで不可
換算で何十～何千個もの命令が同時に実行されます。
欠な機能です。
ビデオにおける C++ ライブラリの使用 SDAccel 開発環境は、コア カーネル コンパイラの一部に、
アプリケーション用のコードは、Vivado HLS のビデオ処理 関数を使用してアプリケーションを作成します。アプリケーショ ン コードには、Vivado HLS ライブラリへの C++ 関数呼び 出しと、コンパイル プロセスの指針としてのプラグマが含まれ
ザイリンクスの Vivado HLS の C から RTL に変換するコン
ています。プラグマは、インターフェイス定義用プラグマと、パ
パイラのテクノロジを使用しているため、C や C++ で記述さ
フォーマンス最適化用プラグマに分けられます。
40
インターフェイス定義用プラグマは、ステレオ ブロック マッ
このアクセラレータでは、hls::Mat データタイプが配下でイ
チング アクセラレータとシステムの他の部分との接続方法を定
ンプリメントされるため、各関数間にもデータが伝送されます。
義します。このアクセラレータは、OpenCL C コードではなく
これにより、Split 関数がピクセルを生成した直後に、画像全
C++ で記述されているため、アプリケーション プログラマは、
体の生 成を待つことなく、FindStereoCorrespondenceBM
SDAccel 環境が想定する OpenCL モデルに一致するインター
関数が開始できます。その結果、フレームバッファーを挟みな
フェイス定義用プラグマを提供する必要があります。
がら各関数を順次処理するのと比べて、アーキテクチャが効率
m_axi が付くプラグマは、バッファーの中身がデバイスのグ
化され、処理レイテンシが短縮されます。
ローバル メモリに格納されることを示します。s_axilite が付く
イメージング アプリケーションは、利用できるライブラリが
プラグマは、バッファーのグローバル メモリ内のベース アドレ
豊富に存在する、計算集約型のアプリケーション領域です。課
スを、アクセラレータがホストから受信するために必要です。
題は、実行ターゲットに合わせたアプリケーションの最適化に
このコードで使用されているパフォーマンス最適化用プラグマ
あります。SDAccel 環境を使用すると、C++ ライブラリを使
は、dataflow です。dataflow プラグマは、異なるサブ関数
用して、OpenCL でプログラムされた FPGA のイメージング
を同時に実行できるアクセラレータを生成します。
アプリケーションの開発スピードを向上できます。
41
XCELL SOFTWARE JOURNAL: XCELLENT ALLIANCE
MATLAB and Simulink Aid HW-SW Co-design of Zynq SoCs
Zynq SoC のハードウェア /
ソフトウェア協調設計を支援する MATLAB と Simulink Eric Cigan and Noam Levine FPGA/SoC Technical Marketing MathWorks
42
モデルベースのデザイン ワークフローにより、 ラボではなくデスクトップ上で 設計のトレードオフ検討が可能に グラムすればよいのか、ということでした。ハードウェア / ソ フトウェア協調設計の可能性を想像した設計者は、ARM プ ロセッサとプログラマブル ロジック間でインテリジェントにデ ザインを分割する統合ワークフローでした。しかし、実際は、 ARM コアをターゲットにした従来のエンベデッド ソフトウェ ア開発フローに、プログラマブル ロジック用として IP アセン ブリ、伝統的な RTL、そして新たに登場した高位合成ツール を組み合わせただけの、ハードウェアとソフトウェアが分断さ れたワークフローでした。 2011 年のザイリンクスの Zynq -7000 All Programmable ®
SoC ファミリの発表は、FPGA 業界に大きな革新をもたらし
統合ワークフロー
ました。Zynq SoC は、デュアルコア ARM Cortex ™ -A9
2013 年 9 月、MathWorks 社は、モデルベース デザイン
MPCore ™ プロセッサと、豊富なプログラマブル ロジックの
を使用した Zynq-7000 SoC 向けのハードウェア / ソフト
組み合わせにより、多数のアプリケーションにメリットを提供
ウェア ワークフローを発表しました。このワークフロー ( 図
しました。Zynq SoC の採用により、業界で最も人気の高い
1) では、動的システム全体を表すモデル (Zynq SoC をター
プロセッサの 1 つを使用して、ソフトウェア アプリケーショ
ゲットとするアルゴリズム用の Simulink モデルを含む ) を
ン開発の長所を取り入れながら、高速なプログラマブル ロジッ
Simulink で作成し、アルゴリズムから直接、Zynq SoC 向け
ク ファブリックのハードウェア アクセラレーションで実現され
のハードウェア / ソフトウェア インプリメンテーションを迅速
る柔軟性とスループットが得られます。
に作成できます。
®
MathWorks 社の MATLAB と Simulink を使用すると、 ®
®
®
システム設計者とアルゴリズム開発者は、Simulink のシミュ
密に統合されたハードウェア / ソフトウェア ワークフローを
レーションを使用して、システム全体 ( 通信、電気機械部品な
使用して、高度に最適化されたシステムを開発できます。本稿
ど ) のモデルを作成し、設計のコンセプトを評価し、大まかな
では、このモデルベースのワークフローを説明するケース スタ
トレードオフ検討を行い、アルゴリズムをソフトウェア部分と
ディをご紹介します。
ハードウェア部分に分割します。Simulink で HDL コードを
2011 年 12 月にザイリンクスが初めて Zynq SoC を発表
生成することは、IP コアの作成と、Zynq SoC ファブリック
したとき、ディスクリートのプロセッサと FPGA による従来の
における高速な I/O 処理が可能になります。Simulink で C/
マルチチップ ソリューションが統合され、シングルチップ プ
C++ コードの生成により、Zynq SoC の Cortex-A9 コアの
ラットフォームに統合される、というアイデアは、多くの設計
プログラミングが可能になり、エンベデッド ソフトウェアの開
者の心をとらえました。新しいプラットフォームで FPGA ベー
発サイクルがスピードアップできます。
スのアクセラレータを作成することは、ソフトウェア実行のボ
このアプローチにより、ARM プロセッシング システムとプ
トルネックを解消できるとともに、ザイリンクスやザイリンク
ログラマブル ロジックをつなぐ、Zynq SoC をサポートする
ス IP パートナーが開発済みのデジタル信号処理、ネットワー
AMBA® AXI4 インターフェイスを自動生成できるようになり
ク、通信などのアプリケーションに対応し、量産に適応した多
ました。下流タスク (ARM プロセッシング システム用の
くの標準 IP コアが利用できるようになります。
C/C++ のコンパイルと実行ファイルのビルド、ザイリンクス
しかし、問題は、この新しいデバイスをどのようにしてプロ
のインプリメンテーション ツールを使用したビットストリーム
43
XCELL SOFTWARE JOURNAL: XCELLENT ALLIANCE
Model-Based Design for Zynq-7000 All Programmable SoCs RESEARCH
REQUIREMENTS DESIGN System Modeling
このワークフローは、通信、画像
Software/Hardware Partitioning Algorithms for programmable fabric
C code generation
Verification
Algorithms for ARM core
処 理、 スマート 電 力、 モ ー タ ー 制 HDL code generation
IMPLEMENTATION Hardware / software design iterations
Build Executable
IP Core Generation
ARM Cortex-A9
Programmable Logic
御などのアプリケーションでモデル ベース デザインを使用しているデザ イン チームにより、アルゴリズム開 発者とハードウェア設計者およびエ ンベデッド ソフトウェア開発者との 連携を強化し、プログラマブル SoC へのアルゴリズムの実装をスピード アップ するための手段として導入さ
INTEGRATION
れています。生成された HDL およ び C コードでハードウェア プロトタ イプを作成後、デザイン チームがザ
Zynq-7000 SoC development boards
イリンクスの Vivado ® IP インテグ レーターを使用して、製造に必要な 他のデザイン コンポーネントとコー ドを統合できます。
図 1 — Simulink により設計者は、動的システム全体を表すモデルを作成し、 そのモデルから Zynq SoC 用のハードウェア / ソフトウェア インプリメンテーションを直接作成できます。
ケーススタディ : 三相モーターの制御 効率的な電力変換効率を持つカス タムのモーター コントローラーは、
の生成、Zynq 開発ボードへのダウンロード ) との統合により、
いくつかの理由により、プログラマブル SoC の最も一般的
プロトタイピング ワークフローが高速化しました。
な用途の 1 つになっています。1 つの理由は、高い性能と高
このワークフローの中核には、Embedded Coder と HDL
い効率が求められることです。世界中の電力消費量の実に約
Coder ™ という 2 つ のテクノロジが 使われています。Em-
46% が電動モーターで駆動されるシステムによるものである
bedded Coder は、MATLAB、Simulink、 お よ び State-
ことから、革新的な制御アルゴリズムによって高い効率を実現
flow
することは、モーター ドライブの一般的な設計目標になって
®
®
から、エンベデッド システム用にターゲット固有の最
適化がなされた実稼働可能な品質の C および C++ コード
きています。ザイリンクスの Zynq プログラマブル ロジックは、
を生成します。Embedded Coder は広く普及しており、最新
正確なタイミングが得られるため、低レイテンシかつ高効率な
の乗用車、高速列車や旅客機では、高い確率で Embedded
駆動を実現するための理想的なプラットフォームになります。
Coder によって機体をガイドするリアルタイム コードが生成
もう 1 つの理由は、多軸制御です。プログラマブル SoC
されています。HDL Coder は、Embedded Coder と似て
には、豊富なプログラマブル ロジックおよび DSP ( デジタ
いますが、 FPGA や ASIC 向けの VHDL または Verilog コー
ル信号処理 ) リソースを搭載するため、各モーターが独立し
ドを生成するもので、ザイリンクスのワークフローに緊密に統
て動作するか連動して動作するかにかかわらず、統合モーショ
合されています。プログラマブル SoC 向けのモデルベース デ
ン コントロール システムのように、複数のモーター コント
ザイン ワークフローの基盤には、このような成熟した C およ
ローラーを 1 つのプログラマブル SoC に実装できる可能性
び HDL コード生成テクノロジが使われています。
が広がりました。
44
• ARM Cortex-A9 プロセッシング システムには、「速度制
また、インダストリアル ネットワーキング IP の統合も、も
御」ブロックと、 「モード選択」ブロックを割り当てます。こ
う 1 つの要素です。ザイリンクスとその IP パートナーは、プ ログラマブル SoC にそのまま組み込 み可能 な EtherCAT、
の 2 つのブロックはモデルの他の部分よりも遅い速度で実
PROFINET、その他のインダストリアル ネットワーキング プ
行可能で、この部分のデザインは、開発中に改変および再コ
ロトコルとの統合のための IP を提供しています。
ンパイルされる可能性が最も高いからです。
一般的なモーター制御におけるこのワークフローの使用を
• ARM コア上で実行される「モード選択」ステート マシンに
説 明 するため、Zynq-7020 SoC ( このハードウェア プ ロ
よって、モーター コントローラーの動作モード ( たとえば、
トタイプ プラットフォームの詳細については、http://www.
開ループ動作や閉ループ制御など ) が決まります。 「モード
mathworks.com/zidk を 参 照 ) に 実 装した 三 相 電 動 モ ー
選択」ステート マシンは、閉ループ制御モードに遷移する
ター の 磁 界方 向 制 御 (FOC) アルゴリズ ムを 例に 取ります。
前の、起動モード、開ループ制御モード、エンコーダー キャ
モーター制御システム モデルは、2 つのプライマリ サブシス
リブレーション モード間の遷移をコントロールします。
テムで構成されています ( 図 2)。1 つは、 Zynq SoC 用のモー
• エンコーダー センサーの信号は、外部ポートを介して、プ
ター コントローラーで、Zynq プロセッシング システムとプロ
ログラマブル ロジック内の「エンコーダー ペリフェラル」に
グラマブル ロジックに分割されています。もう 1 つは、軸角
入り、さらに「位置 / 速度推定」ブロックに渡され、モーター
を計測するエンコーダーを備えた、ブラシレス DC モーター
の状態 ( 軸位置および速度 ) が計算されます。
に接続されたモーター コントローラー FPGA メザニン カー
•「ΣΔ ADC ( アナログ / デジタル コンバーター )」がモー
ド (FMC) です。 ハードウェアとソフトウェアの分割について、データ フロー
ターの電流を検出し、ハンドコードで記述された「ADC ペ
の観点から見てみましょう。
リフェラル」ブロックがその電流を処理します。
Programmable Logic
ARM Cortex-A9 Processing System
Core controller(HDL)
Velocity Control
Current Controller • Open-loop mode • Calibrate encoder mode • Closed-loop mode • Standby mode
Open-source LINUX
C code (from model)
HDL code (from model)
Position / Velocity Estimate
Encoder Peripheral
Current Conversion
ADC Peripheral
Voltage Conversion
PWM Peripheral
Encoder Interface Isolation
AXI4 Interface
Core controller (C)
Mode Select
Motor FMC Card
∑∆ ADC
Inverter Module
HDL (hand-coded)
図 2 — モーター制御システム モデルには、2 つのプライマリ サブシステムがあります。
45
XCELL SOFTWARE JOURNAL: XCELLENT ALLIANCE
System Inputs Verify Outputs
boolean Mode Select
comm single
C/D
Current Convert
uint 16 boolean uint 16
Position Velocity
uint 16
Disabled
...1010...
Open Loop Calibrate Encoder Velocity Control
...1010...
boolean Volt Convert
Current Control
D/C
...1010...
uint 16
Motor_And_Load
FOC_Velocity_Encoder_Core_Algorithm
図 3 — モーター制御システム用の制御ループ モデルとシミュレーション結果は、 速度パルス コマンドへの応答を示しています。
•「電流コントローラー」は、モーターの状態と電流を受け取
• プラント モデル : FMC のドライブエレクトロニクス、ブラ
て動作モードおよび速度制御コマンドを受信して、電流コン
デル、モーター軸の慣性負荷のモデル、エンコーダー セン
トローラー コマンドを算出します。閉ループ モードのとき、
サー モデルが含まれます。
るとともに、ARM コアから AXI4 インターフェイスを介し
「電流コントローラー」では PI (Proportional Integral) 制 御法則が使用され、そのゲインはシミュレーションとプロト タイプで調整できます。 「電圧変換」ブロックに入り、 • 電流コントローラー コマンドは、 「PWM ペリフェラル」を介して、最終的にモーターをドライ
シレス DC モーターの永久磁石形同期マシン (PMSM) モ
• 出力検証モデル : アルゴリズム開発者のモデル改良作業およ び検証作業を支援するポスト処理およびグラフィックスが含 まれます。 Simulink では、ハードウェア テストを開始するかなり前の
ブしているモーター制御 FMC に出力されます。
段階で、シミュレーションによってアルゴリズムをテストできま
設計者は、このシステム全体を Simulink でモデリングでき
ラス プロファイルをテストし、プロセッシング レートを変化さ
ます ( 図 3)。 モデルベース デザインでは、システムの構成要素が増え、最
す。PI コントローラーのゲインを調整し、 さまざまなスティミュ せたときの効果を検証できます。しかし、シミュレーションを 使用する中で、 重要な問題に突き当たります。つまり、一般的に、
上位の Simulink モデルで 4 つの部分に分けられます。
モーター制御のプロセッシング レートは多岐にわたるため ( 全
• 入力モデル : コマンドされた軸速度とオン / オフ コマンドを、
ルゴリズムのレートは 1 ～ 25kHz、プログラマブル ロジック
コントローラーにスティミュラスとして提供します。
•
Zynq SoC をターゲットとするモーター制御アルゴリズムの モデル
46
体の機械的応答レートは 1 ～ 10Hz、コア コントローラー ア は 10 ～ 50MHz もしくはそれ以上で動作 )、シミュレーショ ン時間が数十分、時には数時間にも及ぶのです。ペリフェラル (PWM、電流検出、エンコーダー プロセッシング ) にビヘイ ビアー モデルを使用する制御ループ モデルを使用して、図 3
Field-Oriented Velocity Control Zynq ARM Real-Time inputSourceEnum.StandAloneTest Input_Source
Display
Convert Data_Type_Conversion controllerMode
Calibrate +100 rad/sec, no load motorOn (logical)
boolean
PVelocity, 2=CalibrateEncoder, 3=Velocity
Enum
single
velocityCommand (rad/esc)
FPGA Interface For Bitstream
motorOn
<motorOn>
commandType
<velocityCommand> velocityCommand
ADC
Select_Source
Current Convert
rotorPosition electricalPosition
Calibrate Encoder
Encoder
Position Velocity
FOC_Velocity_Encoder_C
rotorVelocity
Scope
PWM
Current Control
motorOn
off
FOC_Velocity_Encoder_FPGA_Interface
1
Z-
commandType
Command_Mode
1
Z-
1 DSP
encoderOffset
Volt Convert
on
commandTypeEnum.Velocity
phaseCurrentB
Open Loop
Velocity Control
0
PhaseCurrent
Disabled
Mode Select
<commandType>
Signal_Builder_Experiments
1
phaseCurrentA
100
1 Z-
velocityCommand
velocityCommand
1
Z-
Slider_Gain Sine_Wave F = 0.1 Hz
Copyright 2014 The MathWorks, Inc.
Measured Me asur sured ed velocity (rad/sec)
図 4(a) — プロトタイプ ハードウェアをテストする Simulink モデル
100 80 60 40 20 Prototype hardware System simulation
0
Control loop simulation
-20
Prototype’s startup response (in green) differs from those from simulation (red, purple) because of a difference in the shaft angle at t=0.
Phase e curr currents urren ents t (amps))
5 4 3 2 1 0 -1
Prototype hardware
-2
System simulation
Control loop simulation
-3 -4 0
1
2
3
4
5
6
7
Time (sec)
図 4(b) — ハードウェア プロトタイプの結果とシミュレーション結果の比較
47
XCELL SOFTWARE JOURNAL: XCELLENT ALLIANCE
COVER STORY
に示す時間応答を得ることで、この問題を軽減できます。 制御ループ モデルを使用してコントローラーを調整した後
図 4b は、ハードウェア プロトタイプとシミュレーション結 果で、軸回転速度と位相電流を比較したものを示しています。
の次のステップは、ペリフェラルを含む高忠実度モデルを使用
ハードウェア プロトタイプの起動シーケンスは、それぞれのシ
したシミュレーションを行い、コントローラーが正常に動作す
ミュレーション モデルの起動シーケンスと大きく異なります。
るのを確認することです。そのため、コントローラーの C コ
しかし、これは、予想される結果です。ハードウェア テストに
ンポーネントおよび HDL コンポーネント用にタイミング精度
おけるモーターの回転子と固定子間の初期角度は、シミュレー
仕様モデルを組み込みます。これらの仕様モデルは、C およ
ションで使用した初期角度とは異なっており、電流制御アル
び HDL コードの生成に必要なセマンティクスを備えていま
ゴリズムがエンコーダー キャリブレーション モードを介して
す。その後、シミュレーションで、仕様モデルを持つシステム
モーターをドライブするため、応答が変わります。パルスが 2
の動作が制御ループ モデルに極めて近いことを検証します。
秒で印加されると、シミュレーション結果とプロトタイプ ハー
高忠実度モデルでパフォーマンスを検証した後、コントロー
ドウェアの結果はほぼ完全に一致します。
ラーをハードウェアでプロトタイピングします。図 1 のワーク
その結果を踏まえて、負荷および動作条件を変えてテストを
フローに従って、まず、IP コアを生成します。IP コア生成ワー
続行するか、別の C および HDL 最適化に進むことができます。
クフローでは、ターゲット開発ボードの選択と、コアの入力ポー
ザイリンクス Zynq SoC へのアルゴリズムのハードウェア
トと出力ポートからターゲット インターフェイスへのマッピング
/ ソフトウェア インプリメンテーションを行うため、モデル
(AXI4 インターフェイスと外部ポートを含む ) を指示に従って
ベースのデザイン ワークフローが技術者に受け入れられはじ
行えます。
めています。Simulink シミュレーション導入は、アルゴリズ
Vivado Design Suite との統合により、ビットストリーム
ムを早い段階で評価できるようになり、設計者は、ラボでは
の構築と、Zynq-7020 SoC のファブリックのプログラミン
なくデスクトップ上で、アルゴリズムの 有 効 性の評価や設 計
グがワークフローによって行われます。
のトレードオフ検討を行い、生産性を向上できます。実績あ
IP コアがターゲット デバイスにロードされた後 の次のス
る C および HDL コード生 成テクノロジがザイリンクス All
テップは、Simulink モデルから、ARM コア用のエンベデッ
Programmable SoC のハードウェアとともに使 用できるこ
ド C コードを生成することです。C コードの生成、コンパイ
とで、アルゴリズムが実ハードウェア上で動作するように高速
ル、組み込み Linux によって実行ファイルをビルドするプロ
で再現が可能なプロセスを用意できることが証明されました。
セスは完全自動で行われ、プロトタイプを実行可能な状態に
シミュレーション環境とハードウェア環境間で連続的に検証を
なります。
行うことで、設計者は、開発プロセスの早い段階で問題を特
プロトタイプ ハードウェアを実行して、シミュレーション モ
定し、解決できるようになります。
デルと整合する結果が得られることを確認するため、ハイレベ
Zynq ベースの開発ボード、 ソフトウェア定義された無線キッ
ル コントロール パネルとして機能する改変済みの Simulink
ト、およびモーター制御キットに対するワークフロー サポー
モデル ( 図 4a) を作成します。このモデルでは、プラント ( ド
トは、MathWorks 社によって提供されます。ワークフロー
ライブ エレクトロニクス、モーター、負荷、センサー ) のシミュ
の詳細については、http://www.mathworks.com/zynq を
レーション モデルが削除され、ZedBoard への I/O に置き換
参照してください。
えられています。 このモデルを Simulink セッションで使用することにより、
MATLAB と Simulink は、The MathWorks, Inc. 社の登
モーターの電源を入れ、異なるスティミュラス プロファイルを
録商標です。その他の商標のリストについては、http://www.
選択し、対象の信号を監視し、MATLAB で後にポスト プロ
mathworks.com/trademarks をご覧ください。その他の製
セスを行うためのデータを取得できますが、ここでは、パルス
品名あるいはブランド名などの商標および登録商標はそれぞれ
テスト ( 図 3) をもう一度行います。
の所有者に帰属します。
48
ウェブセミナー All Programmable FPGA、SoC、3D IC の世界的なリーディング プロバイダーの ザイリンクスが提供するプログラマブル ロジックからプログラマブル システム インテグレーションのさまざまな機能と活用方法をご紹介します。 コストを抑え、最大のパフォーマンスを実現するための最新情報を手に入れてください。
ニーズに合わせたプログラムを各種取り揃えて好評配信中 !!
注目のセミナー
UltraScale
アーキテクチャ概要 FPGA 入門編
FPGA の基本を理解したい方へ FPGA の全体概要を解説した入門編と、ものづくりにチャレンジする経営者、 技術管理者の方へ FPGA を採用する利点をご説明します。
30分で判る! FPGA入門
15分で判る! FPGA採用理由
ザイリンクス FPGA/SoC を使った最先端デザインの設計手法や、さまざまなアプリケーション設計に 求められるデザイン チャレンジに対するソリューションをご紹介・解説します。
All Programmableで実現するハイエンド組込みヒューマン マシン インターフェイス
FPGA/SoC 活用編
ザイリンクス All Programmable ソリューションで実現する機能安全
Zynq SoC を使用したマルチチャンネル リアルタイム ビデオ プロセッサの設計 ∼アクセレータでのソフトウェア
Zynq SoC を使用した最先端 エンベデッド システムの設計 ボトルネックの解消方法∼
7 シリーズ ターゲット デザイン プラットフォーム プログラマブルデバイスである FPGA の設計には開発ツールがキーになります。ザイリンクスが提供する ユーザー フレンドリーな開発ツールの特徴や使い方、先端設計メソドロジについて解説します。
開発ツール編
次世代FPGA設計手法セミナー PlanAhead デザイン解析ツール ∼ 第1部、第2部、第3部、デモ ∼
AMBA AXI4 テクニカルセミナー FPGA の世界トップシェアを誇るザイリンクスが提案するソリューションや、ザイリンクスの最先端 FPGA の 詳細を解説します。
FPGA/SoC 概要編
UltraScale アーキテクチャ概要 Zynq-7000 SoC アーキテクチャとエコシステム
28nm ザイリンクス 7 シリーズ FPGA のアジャイル ミックスド シグナル テクノロジ セミナー内容の詳細／ご視聴は今すぐこちらから
http://japan.xilinx.com/webseminar/
®
m
Find it at
mathworks.com/accelerate datasheet video example trial request
GENERATE HDL CODE AUTOMATICALLY from
MATLAB and
Simulink
HDL CODER™ automatically
©2015 The MathWorks, Inc.
converts Simulink models and MATLAB algorithms directly into Verilog and VHDL code for FPGAs or ASIC designs. The code is bit-true, cycleaccurate and synthesizable.
® ®
Client Name: The Mathworks REQ #: 082415A Title: HDL_NEW_8.5X11.0 Size: 8.5” x 11” This advertisement prepared by: Magnitude 9.6 345 W. 13th Street New York, NY 10014 240-362-7079 Edwin_Havens@yahoo.com
Cosmos Communications C
M
31369a
Y
1
K
08.19.15
133
js 1
QC