ザイリンクスソフトウェア開発キット (SDK) ユーザーガイド...ザイリンクスソフトウェア開発ザイリンクスソフトウェア開発キット

ザイリンクスソフトウェア開発

ザイリンクスソフトウェア開発キット (SDK) ユーザーガイド

システムパフォーマンス解析

UG1145 (v2015.1) 2015 年 4 月 1 日

本資料は表記のバージョンの英語版を翻訳したもので、内容に相違が生じる場合には原文を優先します。資料によっては英語版の更新に対応していないものがあります。日本語版は参考用としてご使用の上、最新情報につきましては、必ず最新英語版をご参照ください。

システムパフォーマンス解析 japan.xilinx.com 2UG1145 (v2015.1) 2015 年 4 月 1 日

改訂履歴

次の表に、この文書の改訂履歴を示します。

日付バージョン改訂内容

2015 年 4 月 1 日 2015.1 AXI パフォーマンスモニター (APM) に関する制限事項を追加して、「PL プロファイルカウンター」を更新

「トレーニングリソース」ビデオを「その他のソースおよび法的通知」に追加

http://japan.xilinx.com

http://japan.xilinx.com/about/feedback.html?docType=User_Guides&docId=UG1145&Title=SDK%20%26%2312518%3B%26%2312540%3B%26%2312470%3B%26%2312540%3B%20%26%2312460%3B%26%2312452%3B%26%2312489%3B%20%3A%20%26%2312471%3B%26%2312473%3B%26%2312486%3B%26%2312512%3B%20%26%2312497%3B%26%2312501%3B%26%2312457%3B%26%2312540%3B%26%2312510%3B%26%2312531%3B%26%2312473%3B%26%2335299%3B%26%2326512%3B%20%28UG1145%29&releaseVersion=2015.1&docPage=2

目次

改訂履歴 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

第 1章 : 概要SPA ツールボックス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

パフォーマンス解析フロー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

要件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

その他のリソース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

第 2章 : 背景

第 3章 : システムパフォーマンスモデリングプロジェクトSPM ソフトウェア . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

SPM ハードウェア . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

第 4章 : 監視フレームワークPL プロファイルカウンター . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

PS プロファイルカウンター . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

ホスト /ターゲット間の通信 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

第 5章 : SPM の入門ATG コンフィギュレーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

パフォーマンス解析のパースペクティブ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

第 6章 : ソフトウェアパフォーマンスの評価パフォーマンスの監視 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

パフォーマンス改善の可視化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

第 7章 : ハイパフォーマンスポートの評価HD ビデオトラフィック . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

高帯域幅トラフィック . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

第 8章 : DDR コントローラー設定の評価デフォルトの DDRC 設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

変更した DDRC 設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

オンチップメモリの使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

第 9章 : メモリ階層および ACP の評価メモリパフォーマンスの査定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

データサイズおよび局所性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

共有 L2 キャッシュ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52




第 10章 : カスタムターゲットの使用ソフトウェアの計測 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

ハードウェアの計測 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

カスタムターゲットの監視 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

第 11章 : 徹底パフォーマンス解析要件の査定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

デザインのモデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

パフォーマンス検証 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

詳細な解析 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

付録 A : パフォーマンスチェックリスト

付録 B : その他のソースおよび法的通知ザイリンクスリソース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

ソリューションセンター . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

参考資料 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

トレーニングリソース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

重要な法的通知 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73




第 1章

概要

ザイリンクス Zynq®-7000 All Programmable SoC デバイスファミリは、デュアルコア ARM® Cortex™-A9 MPCore™プロセッシングシステム (PS) と、 28nm テクノロジのザイリンクス 7 シリーズのプログラマブルロジック (PL) を統合しています。 PS と PL は、パフォーマンスおよびシステムを統合するために設計された標準 ARM AMBA™ AXI インターフェイスを介して接続されています。このタイプの SoC は業界でも新しく、システムパフォーマンスをしっかりと把握できるよう、新しいタイプのパフォーマンス解析およびベンチマーキングテクニックが必要になります。Zynq-7000 AP SoC アーキテクチャの持つ機能を最大限に利用し、市場で製品の差別化を可能にするには、このアーキテクチャをよく理解しておくことが重要です。

SPA ツールボックスパフォーマンス解析とベンチマークテクニックの必要性に応えて、ハードウェアおよびソフトウェアシステムを早期段階で検証できるよう、ザイリンクスソフトウェア開発キット (SDK) には、システムパフォーマンス解析 (SPA)ツールボックスが含まれ、改善されています。特に、 Zynq-7000 AP SoC を設計する場合は、その複雑な異種システムでのインタラクションを把握できるよう、PS と PL の両方を確認できるようになっています。デザインフローの重要な段階でシステムパフォーマンスを確認し、システムのパフォーマンスを改善していくことができます。




第 1 章 : 概要

図 1-1 は、 SDK の機能セットに SPA ツールボックスがどのように組み込まれているかを示しています。 SDK にはほかに、ソフトウェアプロファイリングツール、システムデバッガー、ドライバーおよびライブラリのサポートといった重要な機能があります。 SPA ツールボックスには、監視フレームワーク、ユーザーインターフェイスが含まれているだけでなく、システムパフォーマンスモデリング (SPM) と呼ばれる早期段階の検証用環境と、ユーザーデザインの監視および解析という 2 つの重要な使用モデルに共通した可視化ツールが含まれています。このツールボックスは、デザインプロセスで一貫したパフォーマンスが得られるように、パフォーマンスを検証するために使用できます。

SPM は SDK 独特の機能で、設計作業を始める前から、複雑なパフォーマンスモデリングを行うことができます。SPMは実際のターゲットハードウェアで実行されます。また、5 つの AXI トラフィックジェネレーターを含んだ、非常にコンフィギャラブルな固定ビットストリームが含まれています。これらのトラフィックジェネレーターは、 PL トラフィックをモデルするためのコンフィギャラブルなコアで、 SDK で使用されます。プロセッシングシステムで同時にソフトウェアアプリケーションも実行できるので、システムコンフィギュレーションパラメーターをユーザー指定できます。

X-Ref Target - Figure 1-1

図 1‐1 : システムパフォーマンス解析 (SPA) ツールボックスを含んだザイリンクス SDK の機能

ソフトウェアパフォーマンス解析

(SPA)

システムパフォーマンスモデリング (SPM)

監視フレームワーク

ユーザーインターフェイス/視覚化

ソフトウェアプロファイルツール

システムデバッガー

ドライバー/ライブラリ




第 1 章 : 概要

パフォーマンス解析フローSDK には、 SPM デザインを使用した徹底したパフォーマンス解析フローがあります。このフローを使用し、予想デザインでトラフィックをモデルした後に、実際のデザインを使用してパフォーマンスを検証できます。

図 1-2 に示すように、このフローには 4 つのステップがあります。

要件の査定 : まず、ターゲットシステムの PS - PL インターフェイスでのデータスループットなど、デザインの AXIトラフィック要件を予測します。

デザインのモデル : 予測したトラフィック要件に基づいて、 SPM を使用してデザインをモデルします。実際のターゲットハードウェアが使用されるため、リアルタイムのクロックレートを達成できます。このため、ほかのモデリング環境と比較すると、ランタイムは改善されます。また、実際のシステムアクティビティが監視されるのでより正確になります。

パフォーマンス検証 : デザインを開発しながら、実際のデザインを監視し、可視化していくことで、パフォーマンス結果を検証することができます。

詳細な解析 : SDK パフォーマンスツールは、デザインオプションを評価し、デザインを改善したことによる影響を予測するため、デザインを詳細に解析します。

こうした徹底したパフォーマンス解析フローには次のような利点があります。

• リスク軽減 : SPM ベースモデルを利用して目的のレイテンシおよびスループットを達成しておくことで、最終デザインでも同じパフォーマンスを達成しやすくなります。確約されているわけではありませんが、 Zynq-7000 APSoC でパフォーマンス目標を満たしやすくなります。

• デザインの改善 : SPM を使用してさまざまなトラフィックシナリオを予測しておくことで、レイテンシなどシステムパフォーマンスに関するデータを収集でき、実際のデザインで役立てることができます。

• さまざまなシナリオ設定 : SPM は非常にコンフィギャラブルなモデルであるため、さまざまな機能やアーキテクチャを試してみることができます。

このガイドでは、このパフォーマンス解析ツールボックスの技術情報だけでなく、その利便性や強みを理解するための手法についても説明します。このツールボックスでは、ターゲットプラットフォームの機能に関してだけでなく、デザインの詳細についても情報が提供されます。また、このガイドでは、 Zynq-7000 AP SoC の代表的な機能を説明し、その機能を最大限に活かせることができるように SDK を使用する方法も説明します。このガイドを読むと、次のことができるようになります。

• ソフトウェアアプリケーションを解析し、ハードウェアトラフィックをモデルするため、 SPM デザインを使用できる。

• Zynq-7000 AP SoC プラットフォームとその機能をよりよく理解できる。

• Zynq-7000 AP SoCでの PS - PL インターフェイスの使用方法および機能を認識できる。

• 最高のシステムパフォーマンスを得るため、メモリ階層 (L1 および L2 のデータキャッシュと DDR) を利用できる。

• SPM を使用してデザインをモデルし、その後、実際のデザインのパフォーマンスを検証してフォローアップできる。


図 1‐2 :徹底したパフォーマンス解析フロー

用件の査定デザインのモデルパフォーマンス検証詳細な解析




第 1 章 : 概要

詳細な結果および解析を提供するために具体的な例が使用されています。また、このガイドでは、 SDK で同様の結果を得るための方法も説明します。このガイドは、こうしたテクニックをユーザーデザインを使用した実践で活かせるように構成されています。

次の 4 章では、 SPA ツールボックスの概要を説明します。

• 第 2 章「背景」では、システムパフォーマンスを説明し、その重要性を定義します。

• 第 3 章「システムパフォーマンスモデリングプロジェクト」では、 SPM プロジェクトの内容を説明します。

• 第 4 章「監視フレームワーク」では、 SDK ツールで使用される監視インフラストラクチャを定義します。

• 第 5 章「SPM の入門」では、 SPM デザインを実行するのに必要なステップを説明します。

そして、その後に続く章では、 SPM デザインを使用する上での詳細について説明します。

• 第 6 章「ソフトウェアパフォーマンスの評価」では、 SPM プロジェクトに含まれているソフトウェア実行ファイルを実行するところから説明を始めます。

• 第 7 章「ハイパフォーマンスポートの評価」では、同じソフトウェアを実行しながら、ハイパフォーマンス(HP) ポートでのトラフィックを監視します。

• 第 8 章「DDR コントローラー設定の評価」では、DDR コントローラー (DDRC) の設定変更方法、および HP ポートのトラフィックへのインパクトを解析する方法について説明します。

• 第 9 章「メモリ階層および ACP の評価」では、まずメモリ階層からの帯域幅およびレイテンシを評価して、次にアクセラレータコヒーレンシポート (ACP) のトラフィックを監視して、パフォーマンスへの影響を調査します。

さらに、この後、ユーザーデザインでパフォーマンス解析を実行するにあたっての情報を提供する章が 2 章続きます。

• 第 10 章「カスタムターゲットの使用」では、ユーザーデザインを計測および監視するにあたってのステップと要件を定義します。

• 第 11 章「徹底パフォーマンス解析」では、図 1-2 に示すパフォーマンス解析のサイクルを全体を通して説明します。

最後に、付録 A 「パフォーマンスチェックリスト」には、このガイド全体で説明してきたパフォーマンスについての主な推奨事項がまとめられています。

要件このガイドで説明する結果を再現させるには、次の要件があります。

1. ソフトウェア

a. ザイリンクスソフトウェア開発キット (SDK) 2015.1

b. オプション : Silicon Labs 社の USB-UART ドライバー

2. ハードウェア

a. ザイリンクス ZC702 評価ボード (XC7Z020 CLG484-1 パーツ搭載)

b. AC 電源アダプター (12 VDC)

c. ザイリンクスプログラミングケーブル (プラットフォームケーブルまたは Digilent USB ケーブル)

d. オプション : USB Type-A to USB Mini-B ケーブル (UART 通信の場合)

e. オプション : 『Zynq-7000 All Programmable SoC ZC702 Base ターゲットリファレンスデザイン』 (UG925) [参照 3]


http://www.silabs.com/Support Documents/Software/CP210x_VCP_Windows.zip

http://www.silabs.com/Support Documents/Software/CP210x_VCP_Windows.zip

http://japan.xilinx.com/products/boards-and-kits/EK-Z7-ZC702-G.htm



第 1 章 : 概要

その他のリソースSDK に関する情報や資料へのリンクは、こちらのザイリンクス SDK ホームページをご覧ください。

http://japan.xilinx.com/tools/sdk.htm

『Zynq-7000 All Programmable SoC テクニカルリファレンスマニュアル』 (UG585) [参照 1] をはじめとする Zynq-7000AP SoC の資料は、こちらをご覧ください。

http://japan.xilinx.com/products/silicon-devices/soc/zynq-7000/index.htm










第 2章

背景Zynq®-7000 AP SoC のさまざまなシステムリソースや機能を理解しておくと、デザインをこのデバイスにターゲットしやすくなります。このデバイスに慣れた後に、リソースに機能をマップしていく方法や、デザインのパフォーマンスを最適化する方法を決めていきます。


図 2‐1 : Zynq‐7000 All Programmable SoC のブロック図




第 2 章 : 背景

図 2-1 は Zynq-7000 AP SoC のブロック図です。プロセッシングシステム (PS) には、 ARM Cortex-A9 コアが 2 つ、512KB の L2 キャッシュが 1 つ、 256KB のオンチップメモリが 1 つ、そしてペリフェラルおよびコントローラーが多数含まれています。

プログラマブルロジック (PL) には、コンフィギャラブルシステムゲート、 DSP、ブロックメモリが含まれています。 PS と PL との間のインターフェイスには次の 3 種類があります。

• 汎用 (GP) AXI ポート : スレーブインターコネクトに直接接続されている制御ポート

• アクセラレータコヒーレンシポート (ACP) : PL マスターへのレイテンシの少ないアクセスを提供。L1 および L2キャッシュを使用したコヒーレンシはオプションです。

• ハイパフォーマンス (HP) AXI ポート : 高帯域幅のデータパスの PL バスマスターを DDR および OCM メモリに接続。

これらのインターフェイスは、 PS - PL 間の通信、外部メモリ (DDR SDRAM や単純な DDR など) との通信といった、さまざまな通信目的に合わせて利用できます。




第 2 章 : 背景

図 2-2 では、Zynq-7000 AP SoC 内の共有リソースがハイライトされています。この SoC の機能をすべてフルに利用しているデザインの場合、高帯域幅の通信チャネルが複数必要になります。システムのこうしたトラフィックには、必然的に共有リソースが使用されます。システムがうまく設計されていないと、 L2 キャッシュ、 DDR メモリコントローラー、高速インターコネクトで、競合がいくつも発生する可能性が出てきます。これらのリソースをすべてフルに使用しているデザインのパフォーマンスを最適化するには、システムの複数個所を確認しておく必要があります。デザインを改善するには、コード、デザインのコネクティビティ、システム設定を変更します。

L2 キャッシュはその最たる例です。 ACP は L2 キャッシュを Cortex-A9 CPU と共有しているため、 ACP またはプロセッサからのスループットトラフィックは、互いのパフォーマンスに影響してしまう可能性があります。これは予測可能ですが、その影響がどのようなもので、どれほどのものなのかを把握するのは容易ではありません。


図 2‐2 : Zynq‐7000 AP SoC ブロック図 (共有リソースをハイライト )




第 2 章 : 背景

こうしたときにこそ、 SDK パフォーマンス機能を利用する価値があります。 SDK には、この影響を把握するための可視化ツールと、早期段階でデザインを試行錯誤していくための SPM があります。表やリアルタイムの図を利用して、一般的なタイムラインで PS および PL のパフォーマンスメトリクスを可視化できるようになっています。これにより、潜在的な問題を早い段階で隔離できるよう、問題が発生しそうなタイミングや位置を知るための情報を入手できます。さらに、SPM デザインとユーザーデザインに同じパフォーマンスメトリクスを使用して計算されるため、早期段階でさまざまなオプションを考慮でき、デザインフローを通して一貫した結果が得られるようになります。

このパフォーマンスツールを使用してパフォーマンス結果を解析する前に、まずは、どのデザインが使用され、何が計測されるのかを理解しておくことが重要です。この後の章では、 SPM デザインと、 SDK で使用されるパフォーマンス監視フレームワークについて説明します。




第 3章

システムパフォーマンスモデリングプロジェクト

ザイリンクスソフトウェア開発キット (SDK) にはあらかじめ定義されているプロジェクトが含まれており、システムパフォーマンスモデリング (SPM) を利用し、またデザインの早期段階でパフォーマンス解析を実行しやすくします。この SPM プロジェクトには、ソフトウェア実行ファイルと、ビットストリーム後のコンフィギャラブルハードウェアシステムの両方が含まれています。 SPM は次のような目的で使用することができます。

• ターゲットの評価 : ハードウェア設計の知識や経験に乏しくても、ターゲットプラットフォームを把握できます。 Zynq®-7000 AP SoC などの複雑な SoC を特性化および評価でき、 ARM Cortex-A9 とプログラマブルロジックとの間のクリティカルなパーティショントレードオフを検討することができます。もっとも重要なのは、デザインの進捗状況や完成度とは関係なく、評価できる点です。常に、ターゲットプラットフォームをより理解して判断ができます。

• パフォーマンスストレステスト : システム内で競合が発生する位置を確認できます。ターゲットプラットフォームの機能の制限を評価するには、そのプラットフォームを理解するのが一番です。

• パフォーマンス評価 : デザインのトラフィックをモデルします。ターゲットプラットフォームを理解できたら、デザインの具体的な部分はトラフィックシナリオとして入力できます。また、 SPM を使用してアーキテクチャのオプションを評価することもできます。

• パフォーマンス検証 : 最終デザインを計測し、初期モデルを使用して結果を確認します。 SPM デザインで使用されるのと同じ監視機能をユーザーデザインにも追加し (57 ページの「ハードウェアの計測」を参照)、モデルされたパフォーマンス結果を検証できます。




第 3 章 : システムパフォーマンスモデリングプロジェクト

図 3-1 には、あらかじめ定義されている SPM プロジェクトに含まれるファイルがリストされています。このプロジェクトには、定義済みのトラフィックコンフィギュレーション、コンパイル済みのソフトウェア実行ファイル 2 つ、そして多数のシステム定義ファイルが含まれています。システム定義ファイルには、プロセッシングシステム 7 (PS7)の初期化ファイル、 Vivado IP インテグレーターでデザイン定義を作成する Vivado® Design Suite Tcl ファイル、定義済みのプログラマブルロジック (PL) デザインを含んだビットストリームが含まれています。

SPM ソフトウェアSPM プロジェクトには、コンパイル済みのソフトウェア実行ファイルが 2 つ含まれています。

• BEEBS (Bristol/Embecosm Embedded Energy Benchmark Suite) と呼ばれるベンチマークのコレクション

• メモリ帯域幅およびレイテンシをテストすることに特化しているメモリストライドベンチマーク

BEEBS ベンチマーク

BEEBS プログラムは、 8 つの多様なベンチマークのシーケンスで構成されています。表 3-1 に示すように、このプログラムには、 MiBench、 WCET、 DSPstone といった知名度の高いベンチマークツールの一部に元々は含まれていたアルゴリズムが含まれています。これらのベンチマークは、エンベデッドシステムをテストし、スタンドアロンまたは


図 3‐1 : SDK での SPM プロジェクトファイル





ベアメタルのターゲットに利用できるよう、選択されています。BEEBS ベンチマークツールの詳細は、『BEEBS: OpenBenchmarks for Energy Measurements on Embedded Platforms』 [参照 4]を参照してください。

BEEBS ベンチマークツールは次の 4 つの点で変更されています。

• 1 つの実行ファイル : 1 プログラム内ですべてのベンチマークを実行するための、1 つの実行ファイルが作成されています。表 3-1 には、SPM プロジェクトに含まれているコンパイル済みのプログラムで呼び出される順番でベンチマークがリストされています。

• ベンチマーク間のスリープ : 各ベンチマークの後、次のベンチマークが始まるまで、 1 秒間のスリープが挿入されています。それぞれのベンチマークを区別させるための割り込みベースのスリープで、CPU 使用率は 0% です。

• さまざまなデータアレイサイズ : さまざまなデータアレイサイズに対応できるよう、ベンチマークは変更されています。このベンチマークプログラムで使用される 3 つのアレイサイズは次のようになっています。

° 4KB (2-D アレイ : 32 x 32) – 32KB の L1 データキャッシュにフィットします。

° 64KB (2-D アレイ : 128 x 128) – 512KB の L2 データキャッシュにフィットします。

° 1024KB (2-D アレイ : 512 x 512) – DDR SDRAM にフィットします。

• 計測済み : これらのベンチマークのランタイムは、各ベンチマークの前後のコードに追加された計測に基づいて計算されています。詳細は、 57 ページの「ハードウェアの計測」を参照してください。これらのランタイムは、UART (SDK のターミナル 1 のパネル) で送信されるトランスクリプトにレポートされ、手動で読み込みます。

メモリストライドベンチマーク

メモリストライドベンチマークは、最小限の計算処理を実行し、またメモリの帯域幅とレイテンシをテストするために設計されているという点において、 BEEBS ベンチマークとは異なります。ソフトウェアに含まれているベンチマークは、表 3-2 にリストされています。次の 5 つのタイプのテストがあります。

• リニア帯域幅 : 一定したリニアストライドアクセスのメモリ帯域幅テスト。 SPM プロジェクトに含まれるコンパイル済みのアプリケーションの場合、ストライドの長さは 32 バイトのキャッシュラインと同じです。

• ランダム帯域幅 (計算済み) : ランダムストライドアクセスのメモリ帯域幅テスト。これらのテストで使用されるランダムアドレスはあらかじめ計算されています。

• ランダム帯域幅 ( リアルタイム) : ランダムストライドアクセスのメモリ帯域幅テスト。これらのテストで使用されるランダムアドレスは、ランダム番号ジェネレーターを使用してリアルタイムで計算されます。

• リニアレイテンシ : 一定したリニアストライドアクセスのメモリレイテンシテスト。

• ランダムレイテンシ (計算済み) : ランダムストライドアクセスのメモリレイテンシテスト。これらのテストで使用されるランダムアドレスはあらかじめ計算されています。

BEEBS と同様に、メモリストライドベンチマークは、 1 つの実行ファイルに含まれており、ベンチマークとベンチマークの間には 1 秒間のスリープが設定されています。表 3-2 は、プログラム内のベンチマークの順番を示していま

表 3‐1 : コンパイル済みプログラムで提供されている BEEBS ベンチマーク

ベンチマークツール説明

Blowfish エンコーダー MiBench ブロック暗号

巡回冗長検査 (CRC) MiBench エラー検出コード

セキュアハッシュアルゴリズム (SHA)

MiBench NIST 暗号学的ハッシュ関数

ダイクストラ法 MiBench グラフ検索アルゴリズム

離散コサイン変換 (DCT) WCET MP3、 JPEG で使用される変換

2-D FIR フィルター DSPstone 画像フィルタリングで共通

浮動小数点の行列の乗算 WCET 2x2 の行列の乗算

整数の行列の乗算 WCET 2x2 の行列の乗算





す。各ベンチマークは、 BEEBS用に上記にリストされている 3 つのアレイサイズと同じサイズで動作します。メモリストライドプログラムも計測されていますが、トランスクリプトレポートに各テストで達成できたスループットおよびレイテンシがレポートされます。

SPM ハードウェアSPM プロジェクトには定義済みのハードウェアデザインが含まれており、早期段階でパフォーマンスをいろいろと試すことができます。このデザインは、 Zynq-7000 AP SoC プログラマブルロジック (PL) をコンフィギュレートするための固定ビットストームとして、プロジェクトに含まれています。

表 3‐2 : コンパイル済みプログラムで提供されているメモリストライドベンチマーク

テストタイプパターンタイプ操作タイプ

帯域幅

リニア

読み出し

書き込み

コピー

読み出し /書き込み

ランダム (計算済み)

読み出し

書き込み

コピー

ランダム ( リアルタイム)

読み出し

書き込み

コピー

レイテンシリニア読み出し

ランダム (計算済み) 読み出し





図 3-2 は Zynq-7000 AP SoC をターゲットにした定義済み SPM デザインのブロック図です。これは、非常にコンフィギャラブルなデザインで、 5 つの AXI トラフィックジェネレーター (ATG) と、 1 つの AXI パフォーマンスモニター(APM) が含まれています。 1 つの ATG は 4 つのハイパフォーマンス (HP) ポートのそれぞれに接続されていて、 ACPにも接続されています。これらのコアのコンフィギュレーションは、汎用 (GP) ポート 0 マスターを介して行われます。 CPU パフォーマンスメトリクスは、パフォーマンスモニターユニット (PMU) を使用して得られます。


図 3‐2 : Zynq‐7000 AP SoC の定義済み SPM デザイン





AXI トラフィックジェネレーター

AXI トラフィックジェネレーター (ATG) は、具体的な AXI トラフィック動作を示すためにコンフィギュレートされた、インテリジェントなトラフィックジェネレーターです。各 ATG のコマンドシーケンスは初期化中に読み込まれ、開始ビットが読み込まれると、これらのコマンドが実行されます。書き込み及び読み出しトラフィック用には、 256個のコマンドのキューが別に含まれています。 ATG にはループモードもあり、コマンドキューのトラフィックは連続して実行され、停止ビットが読み込まれるまで、キューのトラフィックは繰り返されます。 SDK では、これはトラフィック期間値 (秒) に簡略されています。 ATG のトラフィックに関する詳細は、第 5 章「SPM の入門」で説明されています。

AXI パフォーマンスモニター

AXI パフォーマンスモニター (APM) は、接続されている AXI インターフェイスすべてのリアルタイムのパフォーマンスを計測するために設計されたコアです。 SPM デザインでは、これらのインターフェイスには 5 つの ATG の出力が含まれます。APM はプロファイルモードでコンフィギュレートされていて、ATG ごとに 6 つのプロファイルカウンターを含んだ、イベントカウントモジュールを提供します。この 6 つのカウンターは、接続されている AXI インターフェイスのすべての書き込みおよび読み出しチャネルの平均スループットおよびレイテンシを計測するよう設計されています。これらのメトリクスの計算方法については、第 4 章「監視フレームワーク」を参照してください。

パフォーマンスモニターユニット

各 ARM Cortex-A9 CPU には、パフォーマンスモニターユニット (PMU) が含まれています。この PMU は、 CPU 使用率やサイクルごとの命令数 (IPC) など、さまざまなパフォーマンスメトリクスを監視するためにコンフィギュレーションされています。 PMU には SDK で使用されるパフォーマンスモニターフレームワークの一部としてアクセスできます。これらの PMU カウンターの使用方法については、第 4 章「監視フレームワーク」を参照してください。




第 4章

監視フレームワークザイリンクスソフトウェア開発キット (SDK) のパフォーマンス解析ツールボックスは、システムレベルのパフォーマンス計測を提供します。 Zynq®-7000 AP SoC をターゲットにしているデザインの場合、プログラマブルロジック(PL) およびプロセッシングシステム (PS) の両方からのパフォーマンスメトリクスがあります。

PL パフォーマンスメトリクスには次のものがあります。

• (書き込み/読み出し ) トランザクション : AXI トランザクションの数

• (書き込み/読み出し ) スループット : 書き込みまたは読み出しの帯域幅 (MB/秒)

• 平均 (書き込み/読み出し ) レイテンシ : AXI トランザクションの平均書き込みまたは読み出しレイテンシ

PS パフォーマンスメトリクスには次のものがあります。

• CPU 使用率 (%) : アイドル状態以外の CPU クロックサイクルの割合

• サイクルごとの CPU 命令数 (IPC) : サイクルごとに実行される命令の予想数

• L1 データキャッシュアクセスおよびキャッシュミス率 (%) : L1 データキャッシュアクセス数およびそのミス率

• CPU (書き込み/読み出し ) の命令ごとのストールサイクル : メモリ書き込み (書き込み)およびデータキャッシュ補充 (読み出し ) が原因の、命令ごとのストールサイクルの予想数

これらのパフォーマンスメトリクスはターゲットのさまざまな箇所から収集され、共通のタイムラインにまとめられて表示され、システムレベルのパフォーマンス解析ができるようになります。これらのメトリクスを収集し表示するため、 SDK には、ターゲットシステム全体にあるプロファイルカウンターにアクセスする監視フレームワークと、これらのカウンターのサンプリングとオフロードを実行するためのホストターゲット通信フレームワークがあります。

SDK がこの監視に必要なメタデータは、 Vivado® Design Suite によってエクスポートされ、ハードウェアプラットフォーム仕様プロジェクトが作成されるときに SDK に読み込まれます。このエクスポート /インポートは、システムパフォーマンスモデリング (SPM) プロジェクトに対して既に実行されていますが、ユーザーデザインに対しても実行できます (57 ページの「ハードウェアの計測」を参照)。言い換えれば、ここで説明されている監視および解析のすべてが、 SPM にもユーザーデザインにも利用可能であるということです。これは、第 11 章「徹底パフォーマンス解析」で詳しく説明されています。

PL プロファイルカウンターデザインに挿入されている AXI パフォーマンスモニター (APM) は、PL プロファイルカウンターを提供します (ユーザーデザインへの挿入方法については57 ページの「ハードウェアの計測」を参照)。接続されている AXI インターフェイスごとに 6 つのカウンターがあります。表 4-1 にはこれらのカウンターの使用方法がまとめられています。これらのカウンターはインクリメントアップカウンターで、送信された実行されているバイト総数、レイテンシ総計、および完了した AXI トランザクション数をそれぞれカウントします。表 4-1 にあるように、連続サンプル間でのこれらのカウンターの差 (Δで表現) は、サンプル間隔の平均スループットおよびレイテンシの計算に使用されます。 SDKで使用されるデフォルトのサンプル間隔は約 50 ミリ秒です。




第 4 章 : 監視フレームワーク

AXI トランザクションを構成するイベントは多いため、SDK が取り込むイベントおよびレイテンシの計算方法を理解しておくことが重要です。図 4-1 は、サンプルの AXI 読み出しトランザクションのタイミング図で、アドレス、データおよび制御信号が含まれています。

SDK で使用される開始イベントはアドレス受諾 (ARVALID=1 と ARREADY=1) で、最終イベントは最終データ(RLAST=1 と RVALID=1 と RREADY=1) です。共通トランザクション内でのこれら 2 つのイベントの差は、トランザクションレイテンシと考えられます。

ARM は次のものをサポートしていないことに注意してください。

• 33 以上の未処理トランザクション。つまり、最初のデータブロック開始の前に 33 個以上のアドレスの初期化が行われるトランザクション、または、最初のアドレスの前に 32 個のデータブロックが送信/受信されるトランザクション。

• インターリーブされたトランザクション。つまり、現在のデータトランザクションが終了する前 (wlast/rlast を受信する前) に、新しいデータトランザクションのアドレス初期化が行われるトランザクション。

表 4‐1 : AXI パフォーマンスモニターでの AXI インターフェイスごとのプロファイルカウンター

APM カウンターメトリクスパフォーマンスメトリクスの式

書き込みバイト数書き込みスループット =(∆(書き込みバイト数))/(サンプル間隔)

書き込みレイテンシ数平均書き込みレイテンシ = (∆(書き込みレイテンシ数))/(∆(書き込みトランザクション数))書き込みトランザクション数

読み出しバイト数読み出しスループット =(∆(読み出しバイト数))/(サンプル間隔)

読み出しレイテンシ数平均読み出しレイテンシ = (∆(読み出しレイテンシ数))/(∆(読み出しトランザクション数))読み出しトランザクション数


図 4‐1 : SDK で使用される読み出しレイテンシを示した AXI トランザクションタイムラインの例





PS プロファイルカウンターPS プロファイルカウンターは、各 Cortex-A9 CPU に含まれている ARM パフォーマンスモニターユニット (PMU) を構成しています。表 4-2 は、各 PMU の 6 つのカウンターが自動的に SDK にコンフィギュレートされる方法と、各CPU に対するパフォーマンスメトリクスの式をまとめています。後で説明するように、これらは SDK で直接グラフ化されるメトリクスです。

表 4‐2 : ARM パフォーマンスモニターユニットで使用されるプロファイルカウンター

イベント名イベント説明パフォーマンスメトリクスの式

CCNT なし非アイドルクロックサイクルカウンター

CPU 使用率 (%)=100x∆CCNT/(2*∆(SPM 基準クロック ))

INST_RENAME 0x68 レジスタの名前変更をした命令数

サイクルごとの CPU 命令数 (IPC)=(∆(INST_RENAME))/∆CCNT

L1D_CACHE_REFILL 0x03 L1 データキャッシュミス L1 データキャッシュミス率

(%)=100*(∆(L1D_CACHE_REFILL))/(∆(L1D_CACHE))L1D_CACHE 0x04 L1 データキャッシュミス

DCACHE_DEP_STALL 0x61 データキャッシュに依存したストールサイクル (保留ラインフィル)

命令ごとの読み出しストールサイクル =(∆(DCACHE_DEP_STALL))/(∆(INST_RENAME))

MEM_WRITE_STALL 0x81 メモリ書き込みを待っているプロセッサストールサイクル

命令ごとの書き込みストールサイクル =(∆(MEM_WRITE_STALL))/(∆(INST_RENAME))





ホスト /ターゲット間の通信プロファイルカウンターがシステムパフォーマンス解析 (SPA) ツールボックスでどのように処理および表示されるのかがこれで理解できたと思います。さらに、これらのカウンターがどのようにサンプルされ、ターゲットからホストコンピューターに転送されるのかを理解することも大切です。

図 4-2 は SDK のホスト /ターゲット間の通信インフラストラクチャを表しています。 SDK ツール自体はホストコンピューターで実行され、また、ツールにはターゲット通信フレームワーク (TCF) を使用したハードウェアサーバーが含まれています。 TCF を使用すると、 JTAG プログラミングケーブルを介してターゲットと効率よく通信できます。この TCF ベースのハードウェアサーバーは、 16 ページの表 3-1 および17 ページの表 3-2 にリストされているプロファイルカウンターにできるかぎり介入せずに制御します。APM および PMU カウンターは、Zynq-7000 AP SoCの中央インターコネクトを介して、メモリマップアクセスを使用して読み出されます。この後、カウンター値は、先に説明したように処理され、 SDK に表示されます。


図 4‐2 : SDK のホスト /ターゲット間の通信インフラストラクチャ




第 5章

SPM の入門定義済みの SPM プロジェクトは、ザイリンクスソフトウェア開発キット (SDK) で [File] → [SPM Project] をクリックすると、ワークスペースに自動的に読み込まれます。

プロンプトが表示されたら、 SPM ターゲットを選択します。 SPM プロジェクト名は、指定されたターゲットに基づいて付けられます。たとえば、ZC702 ボードでサポートされているターゲットを選択した場合は、 SPM プロジェクトの名前は自動的に「SPM_ZC_702_HwPlatform」になります。

これで、テスト用にコンフィギュレーションを変更することができます。たとえば、ターゲット設定、ソフトウェアアプリケーション、 AXI トラフィックジェネレーター (ATG) を使用するためのトラフィックを変更できます。ターゲット設定には、ボード接続情報、ビットストリームの選択、プロセッシングシステム 7 (PS7) 初期化が含まれます。ビットストリームはデフォルトで SPM ビットストリームに指定されていますが、 PS7 の設定は SPM システム定義ファイルで定義されています。ホストコンピューターからターゲットボードへのローカルまたは直接の接続がない場合は、『Vivado Design Suite ユーザーガイド : エンベデッドハードウェアデザイン』 (UG898) [参照 2] を参照して、ボード接続を設定してください。

図 5-1 は SPM のソフトウェアアプリケーション設定を示しています。デフォルトでは、このコンフィギュレーションのソフトウェア実行ファイルは beebs_benchmarks.elf で、これにはかなりの量のデータ処理とメモリアクセスが含まれているため、手始めに利用するには最適です (第 3 章「システムパフォーマンスモデリングプロジェクト」を参照)。


図 5‐1 : SDK コンフィギュレーションウィザードでのアプリケーション設定




第 5 章 : SPM の入門

このデフォルトアプリケーションは、次の章で説明されているソフトウェアパフォーマンスの評価のためにデザインを準備するために選ばれています。後で、この設定を変更していきます。そして、 SPM プロジェクトで提供されているもう 1 つのアプリケーション、メモリストライドが使用されます。

ATG コンフィギュレーションSDK では、 AXI トラフィックジェネレーター (ATG) をコンフィギュレートするためのトラフィックシナリオを指定することができます。

図 5-2 は、トラフィックを指定できる [ATG Configuration] タブを示しています。 SPM の固定ビットストリームでは(15 ページの「SPM ソフトウェア」を参照)、 1 つの ATG はすべてハイパフォーマンス (HP) ポートと、アクセラレータコヒーレンシポート (ACP) に接続されています。つまりプログラマブルロジック (PL) とプロセッシングシステム (PS) との間のすべてのインターフェイスに接続されています。メモリアクセスパターンは、さまざまな長さ、周波数、各ポートのメモリアドレスでの AXI トランザクションを出力する ATG によってモデルされます。 4 つの HPおよび ACP ポートで読み出し /書き込みパターンのさまざまな組み合わせを指定できます。この ATG コンフィギュレーションの表には次の情報が含まれています。

• [Port Location] : コンフィギュレートされている ATG (SPM 内で、わかりやすい名前が付いています)。

• [Template Id] : その行に定義されているトラフィックをディスエーブル/イネーブル。<None> に設定されている場合は、トラフィックは生成されません。

• [Operation] : AXI ポートの AXI トランザクションのタイプ。有効値は、メモリ読み出しトランザクションの RD(AXI 読み出しポートを介す)、およびメモリ書き込みトランザクションの WR (AXI 書き込みポートを介す) です。

• [Address_Start] : AXI トランザクションの開始アドレス。有効値は、 ddr (ddr0 のエイリアス)、 ddr0、 ddr1、 ddr2、ddr3、 ocm のプリセットアドレスです。

• [Address_Next] : Address_Start の後に続くアドレスが生成される方法 (アドレス範囲内でインクリメンタルかランダム)。


図 5‐2 : SDK コンフィギュレーションウィザードでの ATG コンフィギュレーション設定





• [Beats/tranx] : AXI トランザクションごとのバースト長またはビート数。有効な値は 1 ～ 256 です。

• [Tranx interval] : 2 つの連続する AXI トランザクションのそれぞれの開始点の間をカウントした PL クロックサイクル数。有効な値は 5 ～ 1024 です。

• [Est. Throughput] : 現在のトラフィック設定の予想スループット (MB/秒)スループットの計算式は8 ×(Lburst/(MAX(Linterval, Lburst)))×f で、 Lburst はビート数/ トランザクション、 Linterval はトランザクション間隔、f は PL クロックレートです。

パフォーマンス解析のパースペクティブコンフィギュレーションを編集したら、 [Edit Configuration] ダイアログボックス (25 ページの図 5-2) で [Debug] をクリックし、パフォーマンス解析セッションを開始できます。SDK で [Performance Analysis] パースペクティブが開きます。

図 5-3 は Eclipse のパースペクティブを示しており、ここにはパフォーマンス結果のダッシュボードが表示されています。 5 つの重要なパネルがあります。

1. [APU Performance Summary] : CPU のパフォーマンスメトリクス (PS プロファイルカウンターセクションの下)、AXI パフォーマンスモニター (APM) のパフォーマンスメトリクス (PL プロファイルカウンターセクションの下) をまとめた 2 つの表です。

2. [PL Performance] : 共有タイムライン上の 16 ページの表 3-1 にリストされている APM パフォーマンスメトリクスを示すプロット。

3. [PS Performance] : 共有タイムライン上の 17 ページの表 3-2 にリストされている CPU パフォーマンスメトリクスを示すプロット。


図 5‐3 : SDK の [Performance Analysis] パースペクティブ





4. [MicroBlaze Performance Summary] : MicroBlaze™ パフォーマンスメトリクスをまとめた表。これは SPM では使用されないので、このガイドでは説明されていません。

5. [MicroBlaze Performance] : 共有タイムライン上のにリストされている MicroBlaze パフォーマンスメトリクスを示すプロット。これは SPM では使用されないので、このガイドでは説明されていません。

このガイドでは、ターゲットアプリケーションが出力したさまざまな結果が使用され、それを SDK のターミナル 1のパネルに表示します。ソフトウェアランタイム、達成した帯域幅、平均レイテンシなどがその結果に含まれます。

これらの結果を再現したい場合、またはユーザー自身で実行したい場合は、 AC702 ボードの UART と、ホストコンピューターの USB ポート間を、 USB ケーブル (Type-A to USB Mini-B) で接続する必要があります。

図 5-4 は、SDK でこの UART トランスクリプトを表示させるのに必要なターミナル設定を示しています。このポップアップメニューを表示させるには、26 ページの図 5-3の右上にある [Connect] ボタンをクリックします。ユーザーのポートは COM5 ではない場合がありますが、その他の設定はすべて有効です。


図 5‐4 : SDK の [View Transcript] の [Terminal Settings]




第 6章

ソフトウェアパフォーマンスの評価Zynq®-7000 AP SoC のソフトウェアパフォーマンスを評価する監視機能はいろいろとあります。これらの機能を利用すると、アプリケーションの効率を知る情報が得られるだけでなく、ソフトウェアをよりよく把握し最適化するため情報を視覚的に確認することもできます。

パフォーマンスの監視パフォーマンス監視機能を説明するため、 BEEBS (Bristol/Embecosm Embedded Energy Benchmark Suite) ベンチマークプログラム (第 3 章「システムパフォーマンスモデリングプロジェクト」を参照) を ZC702 ターゲットボードで実行し、そのパフォーマンス結果をザイリンクスソフトウェア開発キット (SDK) 2015.1 で取り込みました。プログラマブルロジック (PL) から駆動されるトラフィックはないので、これはソフトウェア専用テストです。これらの結果を再現する必要がある場合は、選択されているソフトウェアアプリケーションは24 ページの図 5-1で、そして PL トラフィックは25 ページの図 5-2で説明されているので、そちらを参照してください。ここでの結果は BEEBS ベンチマーク用ですが、まったく同じメトリクスを、 SDK に提供されているプログラム用または SDK によってコンパイルされるプログラム用に得ることも可能です。

合計 24 個のテストが実行され、 16 ページの表 3-1にリストされている 8 つのベンチマークのそれぞれが、 3 つの異なるデータアレイサイズ (4KB、 64KB、 1024KB) で実行されています。各テスト間に 1 秒間のスリープが挿入されているため、CPU 使用率を見れば、どのベンチマークが実行されているのかを見分けやすくなっています。図 6-1 には、結果のタイムラインが表示されています。各ベンチマーク内で、小さいサイズから大きなサイズへと順番に、 3 つのデータサイズが実行されています。CPU0 の使用率およびその使用期間を確認できます。トラフィックなしの BEEBSベンチマークの実行には約 45 秒かかっています。


図 6‐1 : CPU 使用率 (BEEBS ベンチマーク )




第 6 章 : ソフトウェアパフォーマンスの評価

図 6-2 は、 SDK の [PS Performance] パネルに表示される [CPU Utilization (%)]、 [CPU Instructions Per Cycle]、 [L1 DataCache Access]、 [L1 Data Cache Miss Rate (%)] という 4 つのグラフを示しています。

CPU 使用率を見るとベンチマークがいつ実行されたかが判断できますが、複数のグラフを検討すると詳細な解析データが得られます。これらのテストの場合、サイクルごとの命令数 (IPC) および L1 データキャッシュのグラフを見ると、重要な解析データが確認できます。 IPC はよく知られているもので、ソフトウェアがその環境とどのように関わっているのか、特にメモリ階層がどうなっているのかを示すための指標です。詳細は、『Computer Organization &Design: The Hardware/Software Interface』 (David A. Patterson、John L. Hennessy 共著) [参照 5] を参照してください。図 6-2を見ると、 IPC の値は L1 データキャッシュアクセスをほぼなぞっている形になっています。また、メモリを多用する行列乗数を実行している間、 IPC の最低値は L1 データキャッシュミス率の最大値に該当しています。 IPC がソフトウェア効率を図るものであるとすれば、図 6-2 を見ると、メモリを多用する計算が長時間実行されている間のソフトウェア効率は最低レベルであることが明らかです。この状態が避けられないこともありますが、メモリ階層との関わりを調べる上で IPC を確認すべきであることがわかります。


図 6‐2 : BEEBS ベンチマークのパフォーマンス解析 (CPU 使用率、 IPC、 L1 データキャッシュ )





この解析をさらに 1 歩進めたのが、図 6-3 のグラフです。これは、プロセッサが指定されたアルゴリズムを読み込んで、データを書き出すという、局所的データについての情報を表しています。 L1 データキャッシュミス率が低い場合は、そのキャッシュにデータが保存され、アクセスされるデータ量が多いことを示しています。また、 L1 データキャッシュミス率が高く、命令ごとのCPU 書き込みまたは読み出しのストールサイクル数が多い場合は、データのほとんどが DDR から来ていることを示します。

もちろん、ソフトウェアアプリケーションを理解しておくことが解析に役立ちます。たとえば、図 6-3に示すように、L1 ミス率が高く、 CPU 読み出しストールサイクル数が多い期間が長いのは 2 回あって、それは、浮動小数点および整数の行列乗数アルゴリズムが、 512 x 512 (256K ワード = 1024KB) の 2D データアレイで動作しているときです。

アプリケーションのパフォーマンスをさらに高めるには、 L2 データキャッシュプリフェッチをイネーブルまたはディスエーブルにしてみるというオプションがあります。これは、 reg15_prefetch_ctrl のビット 28 で指定します (絶対アドレスは 0xF8F02F60)。このデータプリフェッチがイネーブルになっている場合、近接するキャッシュラインも自動的にフェッチされます。 29 ページの図 6-2および図 6-3 に示す結果は、プリフェッチがイネーブルになった状態で生成されていますが、 BEEBS ベンチマークはプリフェッチがディスエーブルになった状態で実行されています。整数の行列乗算の場合は、ソフトウェアランタイムが 9.0% 短縮されるという、非常に大きなインパクトがありました。このプリフェッチオプションによってアプリケーションのパフォーマンスが改善されるものがあれば、改善されずに悪化する可能性のあるものもあります。アプリケーションのランタイムは、プリフェッチオプションを使用した状態、そして使用していない状態の両方で検証することを推奨します。


図 6‐3 : BEEBS ベンチマークのパフォーマンス解析 (L1 データキャッシュ、命令ごとのストールサイクル数)





先に説明したように、全体的なソフトウェアパフォーマンスを計測するには、アプリケーションの異なる箇所のランタイムを計測しておくことをお勧めします。図 6-4 は、 8 つのベンチマークを異なる 3 つのデータアレイサイズで実行したときのランタイムのサマリです (これらのランタイムの計算方法とキャプチャ方法については、 57 ページの「ハードウェアの計測」を参照)。図 6-4 の左側の Y 軸は、値の全範囲を示していますが、右側の Y 軸は低い範囲だけを拡大表示させています。アレイサイズが大きいと、ランタイムは長くなります。しかし、異なるベンチマークでテストしてみると、その増加量は変動します。その理由は、データ量、局所的データ、アルゴリズムがデータサイズに左右される点など、さまざまな要因がランタイムに影響しているからです。局所的データに関していえば、 4KB、64KB、1024KB のデータアレイは、L1 データキャッシュ、L2 データキャッシュ、DDR にそれぞれフィットします。

メモリ階層のパフォーマンスの査定については、第 9 章「メモリ階層および ACP の評価」を参照してください。

パフォーマンス改善の可視化図 6-4 に示すように、ランタイムがもっとも長いのは明らかに行列乗算で、特にアレイサイズが最大だと、ランタイムが長くなります。こうしたランタイムを改善する必要があるとしたらどうでしょうか。コードを最適化あるいは改善しやすくするには、SDK のパフォーマンス解析機能をどのように利用すればよいのか、またどのように視覚化ツールとして使用できるのでしょうか。

次のサンプルコードは、浮動小数点の行列乗算の 2 つの異なる C/C++ インプリメンテーションを示しています。1 つは従来のインプリメンテーションである Multiply_Old() です。もう 1 つは新しいインプリメンテーションでMultiply_New() です。新しいほうは複雑そうに見えますが、 32 バイトのキャッシュラインを利用しています。詳細は、 Ulrich Drepper 著の『What Every Programmer Should Know About Memory』 [参照 6] を参照してください。


図 6‐4 : BEEBS ベンチマークツールでのソフトウェアランタイムの結果





#define CLS 32#define SM (CLS / sizeof (float))

/* Original method of calculating floating-point matrix multiplication */void Multiply_Old(float **A, float **B, float **Res, long dim) { for (int i = 0; i < dim; i++) { for (int j = 0; j < dim; j++) { for (int Index = 0; Index < dim; Index++) { Res[i][j] += A[i][Index] * B[Index][j]; }}}}

/* Modified method of calculating floating-point matrix multiplication */void Multiply_New(float **A, float **B, float **Res, long dim){ for (int i = 0; i < dim; i += SM) { for (int j = 0; j < dim; j += SM) { for (int k = 0; k < dim; k += SM) { float *rres = &Res[i][j]; float *rmul1 = &A[i][k]; for (int i2 = 0; i2 < SM; ++i2, rres += dim, rmul1 += dim) { float *rmul2 = &B[k][j]; for (int k2 = 0; k2 < SM; ++k2, rmul2 += dim) { for (int j2 = 0; j2 < SM; ++j2) { rres[j2] += rmul1[k2] * rmul2[j2];

BEEBS ベンチマークソフトウェアは、浮動小数点および整数の行列乗算の新しいインプリメンテーションを使用して、再コンパイルおよび再実行されています。

32 ページの表 6-1には、SDK の [APU Performance Summery] パネルでレポートされている CPU0 のパフォーマンスメトリクスがまとめられています。 8 つあるベンチマークのうち 2 つしか変更されていませんが、レポートされているメトリクスには大きな差があります。平均 IPC 値は 34.9% 増加していますが、 L1 データキャッシュミス率は著しく低下しています。読み出しストールサイクルも大幅に下がり、 CPU がデータキャッシュ補充で待機している間にクロックサイクルが低下することが確認できます。


図 6‐5 :変更前後の C/C++ ソフトウェア (浮動小数点の行列乗算)

表 6‐1 : CPU0 パフォーマンスサマリ (変更前後の行列乗算)

パフォーマンスメトリクスCPU0 パフォーマンスサマリ

変更前変更後変更点

CPU 使用率 (%) 100.00 100.00 ≈

サイクルごとの CPU 命令 0.43 0.58 ↑

L1 データキャッシュミス率 (%)

8.24 0.64 ↓↓

L1 データキャッシュアクセス

3484.33M 3653.48M ≈

命令ごとの CPU 書き込みストールサイクル

0.00 0.00 ≈

命令ごとの CPU 読み出しストールサイクル

0.79 0.05 ↓↓





図 6-6 は、 [PS Performance] パネルでレポートされている L1 データキャッシュのグラフ、命令ごとの CPU ストールサイクル数を示しています。 30 ページの図 6-3と比べると、コードのボトルネックであった浮動小数点および整数の行列乗算が大幅に改善されているのが明らかです。キャプチャの最後のほうの、 IPC が低く、 L1 データキャッシュミス率が高く、 CPU の読み出しストールサイクル数が多い期間が長かったのですが、それがかなり短くなり改善されています。

これはソフトウェアのランタイムで確認されています。計測されたランタイムのまとめは表 6-2 にもあります。浮動小数点および整数の行列乗算のランタイムは、それぞれもとのランタイムと比べて 22.8% そして 17.0% と低減されています。


図 6‐6 :改善された行列乗算を使用した BEEBS ベンチマークのパフォーマンス解析

表 6‐2 : ソフトウェアランタイムのまとめ (変更前および変更後の行列乗算)

ベンチマークソフトウェアランタイム (ミリ秒)

変更前変更後

浮動小数点の行列の乗算9201.70 2100.36

100.0% 22.8%

整数の行列の乗算8726.67 1483.24

100.0% 17.0%




第 7章

ハイパフォーマンスポートの評価システムパフォーマンスモデリング (SPM) の大きな利点は、プロセッシングシステム (PS) とプログラマブルロジック (PL) の動きとそのインタラクションに仮説を立てて、それをチェックできることにあります。この機能により、デザイン段階に入る前にパフォーマンスを試行錯誤することができるため、後になってパフォーマンスに関する問題を発見してしまう可能性を抑えることができます。Zynq®-7000 AP SoC デバイスの競合は直接視覚的に確認はできませんが、システムパフォーマンスへのインパクトは表示されます。

PS でソフトウェアアプリケーションを実行しながらも、具体的なトラフィックシナリオをモデルするために SPM デザインをコンフィギュレートすることができます。その後、スループットやレイテンシなどの PL マスターパフォーマンス指標を使用して、そのシナリオで目指すシステムパフォーマンスに問題がないかを検証することができます。このプロセスは、さまざまなトラフィックシナリオを使って、繰り返し何度も実行することができます。

Zynq-7000 AP SoC デバイスの重要な共有リソースの 1 つが DDR コントローラーです。このリソースは、両方の CPU、4 つのハイパフォーマンス (HP) ポート、アクセラレータコヒーレンシポート (ACP)、中央インターコネクトを介するほかのマスターで共有されます (詳細は第 8 章「DDR コントローラー設定の評価」を参照)。このため、利用可能なDDR の帯域幅を知っておくことが重要です。

DDR の理論上の帯域幅は次の式を使用して計算できます。

(533.3 Mcycles)/sec x (2 tranx)/cycle× (4 bytes)/tranx=4270 MB/sec 式 1

これは、このメモリを使用して達成できる最大帯域幅ですが、実際の DDR 使用率は、リクエストを出すマスターの数やメモリアクセスのタイプなど多くの要因に左右されます。本章で説明するように、この最大値あたり、あるいはそれを越える帯域幅をリクエストすると、リクエストしているマスターすべてのスループットおよびレイテンシに影響する可能性があります。ザイリンクスソフトウェア開発キット (SDK) のシステムパフォーマンス解析 (SPA) ツールボックスは、この解析をしやすくします。

HD ビデオトラフィック使用されているソフトウェアアプリケーションは、 15 ページの「SPM ソフトウェア」で説明した BEEBS(Bristol/Embecosm Embedded Energy Benchmark Suite) ベンチマークプログラムです。これを SDK で指定する方法については、 24 ページの図 5-1を参照してください。このシナリオでは、 4 つのハイパフォーマンス (HP) ポートのトラフィックがシステムに挿入されていて、ソフトウェアおよびハードウェアのパフォーマンスは SDK で計測されています。これは、ソフトウェアの複雑なアルゴリズムを実行しながら、同時に PL で HD ビデオストリームを処理しているシステムをモデルしています。この処理をインプリメントするシステムを設計するのではなく、SPM を使用すると、そのパフォーマンスをモデルできます。また、設計を開始する前に、目的のパフォーマンスを達成できることをすばやく検証することができます。




第 7 章 : ハイパフォーマンスポートの評価

図 7-1 は、最初のトラフィックシナリオを示しています (このトラフィックの詳細については第 5 章「SPM の入門」を参照)。このシナリオは 4 つの未圧縮の 1080p/60 (つまり 1080 の走査線、プログレッシブ、 60 フレーム/秒) の HD ビデオストリームをモデルしています。2 つのストリームがポート HP0 および HP2 で DDR から読み出され、ポート HP1 および HP3 には 2 つのストリームが書き込まれています。モデルされているビデオストリームすべてに対し、トランザクション間隔は 376MB/秒、未圧縮の RGB 4:4:4 ビデオの予想スループットをリクエストするよう選択されています。


図 7‐1 : HP ポートで HD ビデオストリームをモデルする ATG トラフィックコンフィギュレーション





この HD ビデオトラフィックは ZC702 ボード上で実行されています。図 7-2 に示すように、 4 つの HP ポートのすべてが、 376MB/秒のリクエストされたスループットを維持できています。これらの高いスループットは BEEBS ベンチマークが CPU0 で実行されている間も達成されています。これらの 4 つの HP ポートで使用される合計帯域幅は、1510MB/秒、または DDR の使用可能な帯域幅の 35% でした。つまり、 Zynq-7000 AP SoC デバイスで、これらのスループットを達成することが可能だということです。しかし、 DDR コントローラーでのアービトレーションおよびスケジューリングが原因で、いくつかの競合が見られ、ソフトウェアアプリケーションのパフォーマンスに影響しています (40 ページの図 7-7を参照)。ほとんどのベンチマークのランタイムにわずかな影響が出ていましたが、メモリアクセス量の多いベンチマークにはいちばん多く影響が出ていました。ワーストケースは、整数の行列乗算で、ランタイムは 14.0% 増でした。


図 7‐2 : HP ポートで HD ビデオストリームをモデルした場合のパフォーマンス結果のサマリ





高帯域幅トラフィック34 ページの「HD ビデオトラフィック」で説明されているトラフィックモデリングは拡張可能です。 HP ポートのトラフィックシナリオに別のものを使用し、同じ BEEBS ベンチマークを実行できます。

図 7-3 は、どれぐらい高い帯域幅のトラフィックであればパフォーマンスに影響するのかを確認するため、ストレステストを実行するトラフィックを示しています。 4 つの HP ポートはすべて、 DDR へインクリメンタルなアドレス指定を使用し、読み出しと書き込みの両方に対して、 512MB/秒をリクエストします。トラフィックの長さが BEEBS ベンチマークアプリケーション全体の長さと一致するように、合計の長さは 80 秒に設定されています。 28 ページの図 6-1 には、結果のタイムラインが表示されています。

HP マスターによってリクエストされたスループット合計は 8 * 512 = 4096MB/秒、または DDR の理論上の最大スループットの 95.9% です。トラフィックには書き込みと読み出しの両方のリクエストが含まれているため、 DDR コントローラーにはさらにストレスが加えられます。その理由は、複数のリクエスターだけでなく、さまざまなタイプのリクエストの間をこのコントローラーがアービトレートしなければならないからです。このため、これは、達成可能なDDR 帯域幅のストレステストとみなされます。このトラフィックはワーストケースシナリオを表していますが、メモリが提供できる範囲を超えた、さらに高い帯域幅がリクエストされた場合に起きるバックプレッシャーを可視化するように実行することが重要です。


図 7‐3 : HP ポートで高帯域幅のトラフィックをモデルする ATG トラフィックコンフィギュレーション





SDK で SPM デザインを使用すると、このタイプのストレステストは簡単に実行できます。 BEEBS ベンチマーウアプリケーションは CPU0 で実行されましたが、ATG は37 ページの図 7-3に示すリクエストされたトラフィックを実行するために SDK によってコンフィギュレーションされます。このトラフィックシナリオからのパフォーマンス結果のまとめは、図 7-4 にあります。予想どおり、 HP ポートごとに 512MB/秒のスループットがリクエストされていましたが、これは達成されていませんが、非常に高いスループット総計になっています。 HP ポートに割り当てられた読み出し /書き込みの帯域幅の合計は、次のように計算されます。

合計帯域幅 =424.22+424.22+424.06+424.06+370.81+370.81+370.79+370.79= 3179.76 MB/秒式 2

この帯域幅は、式 1 から得られる理論上の最大値の 74.5% ですが、BEEBS ベンチマークツールを実行している CPU0に割り当てられている帯域幅もあります。このストレステストは、 4 つの HP ポートの書き込みおよび読み出し用にDDR コントローラーによって使用されるアービトレーションを確認しています。書き込みまたは読み込みどちらかのトラフィックも使用される可能性があるため、 DDR コントローラーの帯域幅パフォーマンスは上がる点に注意してください。

書き込みと読み出しの両方のトラフィックが指定されているため、両タイプのトランザクションのパフォーマンスを解析することが重要です。 39 ページの図 7-5は、 [PL Performace] パネルの書き込み AXI トランザクションのパフォーマンスを示しています。この 3 つのグラフは [Write Transactions]、 [Average Write Latency]、 [Write Throughput] です。書き込みスループットおよびレイテンシは、テスト実行全体を通し、 4 つの HP ポート上で比較的一定しており、平均値で若干の低下があるのと、 3.2 秒あたりでいくらかの変動が見られる程度です。


図 7‐4 : HP ポートで高帯域幅トラフィックをモデルした場合のパフォーマンス結果のサマリ





HP ポートの読み出しスループットおよびレイテンシには、行列乗算中のパフォーマンスにもっと目立った低下が見られます (図 7-6 を参照)。ほかのすべてのテスト中は、読み出し帯域幅は約 420MB/秒ですが、メモリを多用する行


図 7‐5 : BEEBS ベンチマークを実行した HP ポートの高帯域幅トラフィックの書き込みパフォーマンス結果


図 7‐6 : BEEBS ベンチマークを実行した HP ポートの高帯域幅トラフィックの読み出しパフォーマンス結果





列乗算の間は (1024KB のデータアレイを使用)、スループットは約 340MB/秒に低下します。図 7-6 に示すように、[Show/Hide Trace Tooltip] ボタンを使用して、この事実を確認します。 64 秒間おいて、 4 つの HP ポートの読み出しスループットはすべて約 338MB/秒になります。スループットのこの低下はレイテンシの増加と一致しており、どちらも DDR コントローラーでの飽和に起因しています。

具体的な時点でのパフォーマンス指標値をレポートするには、[Trace Tooltip] ボタンを使用することもできます。ツールヒントが表示されたら、それをグラフ内の任意点に移動させることができ、指定された測定値が表示されます。正確な時点でのパフォーマンスを指定するのに非常に便利です。

HP トラフィックが増加した影響はソフトウェアパフォーマンスで見られます。このパフォーマンスの全体的な指標はランタイムです。 BEEBS ソフトウェアに追加された測定を使用する場合は (57 ページの「ハードウェアの計測」を参照)、 1024KB のデータアレイサイズを使用した 8 つのベンチマークの相対的なランタイムが図 7-7 に表示されます。トラフィックのない各ベンチマークのランタイムは、 1.0 に正規化されます。この大型アレイには DDR へのアクセスが必要となるため、ソフトウェアランタイムの増加は DDR 飽和によるものと考えられます。行列乗算では、ソフトウェエアランタイムが最も長くなります。 CRC (巡回冗長検査) アルゴリズムもランタイムに目立った影響を与えますが、これは、データアレイのメモリ読み出し回数が増加したことと、 CRC 多項式テーブルが原因であることがほとんどです。その他のベンチマークは、 4 つの HP ポートすべてで高いスループットのトラフィックがあっても、パフォーマンスに最低限の影響しか与えません。


図 7‐7 : さまざまな HP ポートトラフィックでの BEEBS ベンチマークの相対的なランタイム (データアレイサイズは 1024KB)




第 8章

DDR コントローラー設定の評価Zynq-7000 AP SoC デバイスファミリの場合、 DDR メモリの帯域幅の割り当てをある程度コントロールできます。これは、オンチップ DDR コントローラー (DDRC) で設定できます。 SDK 2014.4 より、 SPM デザインのクロック周波数および DDRC 設定を変更できるようになっています。この章では、帯域幅は必ずしも作成できませんが、それを割り当て直すことができるということを説明します。

まず、 DDRC へのコネクティビティを理解しておくことが大切です。図 8-1 は Zynq-7000 AP SoC の DDRC のブロック図です。 DDRC には 4 つのポートがあります。 CPU およびアクセラレータコヒーレンシポート (ACP) (ポート 0)からのトラフィック、中央インターコネクトを介したほかのマスター (ポート 1) からのトラフィック、 HP2 およびHP3 の HP ポート (ポート 2) からのトラフィック、 HP0 および HP1 の HP ポート (ポート 3) からのトラフィックを処理します。 DDRC の設定は、ブートプロセスの初期段階でさまざまなシステム設定をコンフィギュレートする、 PS7または FSBL の一部です。詳細は、『Zynq-7000 AP SoC テクニカルリファレンスマニュアル』 (UG585) [参照 1] の「DDR メモリコントローラー」の章を参照してください。


図 8‐1 : Zynq‐7000 AP SoC の DDR コントローラー




第 8 章 : DDR コントローラー設定の評価

SDK の Project Explorer で SPM プロジェクト (プロジェクトのデフォルト名は SPM_ZC_702_HwPlatform) を右クリックし、 [Configure FSBL Parameters] をクリックします。図 8-2 はそのときに開くダイアログボックスです。 SPM デザインのデフォルトの FSBL 設定が表示されています。このダイアログボックスでは次の設定ができます。

• [(PS/PL/DDR) Clock Frequency (MHz)] : プロセッシングシステム (PS)、プログラマブルロジック (PL)、DDR のクロック周波数を指定できます。

• [DDR Data Path Width] : 16 ビットまたは 32 ビットのデータパス幅を指定できます。

• [DDR Port (0/1/2/3) - Enable HPR] : 4 つの DDR ポートに対し、ハイパフォーマンスの読み出し (HPR) を有効にすることができます。

• [HPR/LPR Queue partitioning] : 32 個のリクエスト分の読み出しリクエストのキューが DDRC に含まれています。HPR および優先順位の低い読み出し (LPR) に対するこのキューの割り当て方法を指定できます。

• [(LPR/HPR/Write) to Critical Priority Level] : 図 8-2 にある最後の 3 つの値はクリティカルレベルです。 3 つの異なるキュー (LPR、 HPR、 Write) がクリティカルになる前に待機状態のものをなくすことができるクロック数 (32DDR クロックサイクルが単位) を指定します。クリティカルステートに達すると、そのキューは最優先になります。つまり、値が小さいほど、そのキューの優先度は高くなります。

これらの DDRC 設定は Vivado® Design Suite でも変更できます。 Vivado IP インテグレーターベースのデザインでは、ブロック図の Zynq7 Processing System IP をダブルクリックします。コンフィギュレーションダイアログボックスが開き、そこで IP を再カスタマイズできます。 DDR コントローラーの設定は、 [DDR Configuration] の下にリストされていて、詳細なオプションは [Enable Advanced options] の下にあります。チェックボックスがオンになっていれば、読み出し /書き込み優先順位、優先順位の高い読み出し (HPR) など、パフォーマンスに影響する可能性のある重要な設定を表示したり、変更したりできます。これらの設定の詳細は、『Zynq-7000 AP SoC テクニカルリファレンスマニュアル』 (UG585) [参照 1] で説明されています。


図 8‐2 :デフォルト FSBL コンフィギュレーション設定 (SPM デザイン)





デフォルトの DDRC 設定ベースライン結果は、 42 ページの図 8-2に示すように、デフォルトの FSBL 設定を使用して、HP のみのトラフィックを実行して作成されています。PL トラフィックは 37 ページの図 7-3に示す高帯域幅の HP トラフィックですが、その期間は 10 秒に設定されています。また、ソフトウェアアプリケーションは実行されていません。[Debug Configuration]を変更してコンフィギュレーションできます。[Application] タブをクリックし、[Download Applications] チェックボックスをオフにします。

このトラフィックシナリオは ZC702 で実行されていて、結果は図 8-3 で確認できます。デフォルトの DDRC 設定はまだ変更されていないため、使用されている点に注意してください。 CPU からの DDR トラフィックがないため、38 ページの図 7-4にある前の結果よりも高い帯域幅を HP ポートが維持しています。

このため、合計の DDR 帯域幅は、 HP ポートで計測された各帯域幅の和になり、次のように計算されます。

合計の帯域幅 = 434.63+434.70+434.67+435.08+429.81+429.87+430.06+430.47= 3459.29 MB/秒式 1

合計の帯域幅は、 DDR の理論上の最大スループットの 81.0% です。 4 つの異なる HP ポートからの高帯域幅の読み出しと書き込みが混ざっていることを考えると、これは非常によいパフォーマンスです。


図 8‐3 :デフォルト DDR コンフィギュレーション設定を使用した HP パフォーマンス





変更した DDRC 設定DDRC 設定を変更し、上記の HP のみのテストを再実行して、パフォーマンス結果を比較することができます。DDRC設定をこのストレステスト用に変更するのは重要なのですが、ユーザーデザインにはその変更が好ましくない場合もあるので注意してください。実際、デフォルトの DDRC 設定を使用するとほとんどのデザインで目指すパフォーマンスを達成することができます。

HP0 および HP1 の読み出しトラフィックに、高い優先順位が必要であるシナリオを検討してみましょう。 Zynq-7000AP SoC では、これらの HP ポートは、DDR ポート 3 により処理されます (41 ページの図 8-1を参照)。図 8-4 にあるように、これは、 HPR を DDR ポート 3 に追加することで達成できます。リクエストキューも、 HPR の 24 個のリクエスト、 LPR の 8 個のリクエストを割り当てることで分割できています。 HPR はそのクリティカルレベルを 2 に下げることで、さらに優先度が上がっていて、 LPR および書き込みのクリティカルレベルは 15 に上げられています。これは、 HPR が目指す優先度で受信されるようにするための重要なステップです。


図 8‐4 :変更した FSBL コンフィギュレーション設定 (SPM デザイン)





図 8-5 は、 DDRC 設定を変更し、同じ HP のみのトラフィックを再実行した後の SDK での結果を示しています。 HP0および HP1 の DDR コントローラーでのトランザクションは高い優先順位であるため、HP0 および HP1 はリクエストされている 512 MB/秒の読み出しスループットを達成できています。しかし、ほかのすべてのトラフィック (HP2 および HP3 のリクエストされた読み出し、そしてすべての書き込み) 達成スループットは低下しています。これは、これらのトランザクションの優先順位が低いことが原因です。つまり、 DDRC 設定でそのように指定されているということです。このテストの合計帯域幅は次のように計算されます。

合計帯域幅 =410.34+410.46+410.37+410.58+512.08+512.21+356.39+356.59= 3379.02 MB/秒式 2

この合計帯域幅は、デフォルトの DDRC 設定で達成された合計帯域幅の 2.3% に収まっています (まとめは 43 ページの図 8-3 および式 1 を参照してください)。 DDRC 設定を変更しても帯域幅は作成されず、再度割り当てられるだけである点に注意してください。つまり、 DDR コントローラーで達成された合計帯域幅を占める率が高いものが、リクエストされた優先順位の高いポート HP0 および HP1 に割り当て直されます。一方で合計帯域幅は比較的一定しています。

また、別の確認方法が、図 8-6 にある読み出しレイテンシの図に示されています。 HP0 および HP1 での読み出しトラフィックに高い優先順位を与えるため、 DDRC がコンフィギュレーションされているため、これらのポートのレイテンシは比較的低くなっています。つまり、これらのポートの読み出しリクエストは、高い優先順位で DDRC によって処理されています。一方で、その他の HP ポート、 HP2 と HP3 の読み出しリクエストは低い優先順位で処理されているため、そのレイテンシはもっと高くなります。このため、 HP0 と HP1 のスループットが高くなり、 HP2 と HP3 のスループットは低くなります。


図 8‐5 :変更された DDR コントローラー設定を使用した HP パフォーマンス


図 8‐6 :変更された DDR コントローラー設定を使用した HP ポートの読み出しレイテンシ





オンチップメモリの使用すべての HP ポートの書き込みと読み出し両方のトラフィックに対し、 512MB/秒を得るというのがデザイン要件になっているケースを考えてみましょう。DDRC 帯域幅を増加させるためほかのメモリを利用するにはどうしたらよいでしょうか。帯域幅合計は 8 * 512 = 4096MB/秒、または DDR の理論上の最大スループットの 96.0% が必要になります。通常の DDR コントローラーや、書き込みと読み出しを混合させたメモリを使ってもこれを達成することはできないのですが、追加データバッファリング用にオンチップメモリ (OCM) を利用することが可能です。これは、Zynq-7000 AP SoC PS にある、優れた、低いレイテンシのスクラッチパッドを提供する 256KB メモリとは別です。

図 8-7 は OCM を使用するあるトラフィックシナリオを示しています。このシナリオを、 37 ページの図 7-3にある元のシナリオと比較してください。リクエストされたスループットは、すべての操作およびタイプに対して同じままですが、 HP2 および HP3 のトラフィックは OCM を使用しています。


図 8‐7 : DDR と OCM の両方を使用し、 HP ポートの高帯域幅トラフィックをモデルする ATG トラフィックコンフィギュレーション





そのようなトラフィックシナリオの結果は図 8-8 に示されています。OCM は DDR の帯域幅を増加させるために使用されているので、 4 つの HP ポートすべてで書き込みおよび読み出しの両方の操作に対して、 512MB/秒という必要な帯域幅が維持されています。 OCM からの平均読み出しレイテンシは 32 から 34 サイクルですが、 DDR からの平均は37 から 39 サイクルだということも注目に値します。これらのレイテンシ値はシステムの多くの要因に左右されるので、 SPM デザインを使用し、さまざまな条件の下で解析を実行することが重要です。

もちろん、 DDRC 設定を変更して、帯域幅の再割り当てを試してみることができます。たとえば、ユーザーのプログラマブルロジックデザインで、ある IP の帯域幅要件がもっと高かったり、あるいはレイテンシ要件が低かったりするケースがあります。そのコアがどの HP ポートに接続されるのか (またはどれに接続する予定なのか) を把握したら、その HP ポートとのペアにもっと高い帯域幅を割り当てることができます。たとえば、第 11 章「徹底パフォーマンス解析」では、マルチレイヤービデオディスプレイコントローラーの帯域幅要件が、システムの AXI マスターよりも高くなっています。

デザインの条件と制約が違えば、別の HPR と優先レベルの組み合わせのほうがうまくいくこともあります。たとえば、 DDR ポート 0 の優先順位を上げることで、ユーザーのソフトウェアのランタイムパフォーマンスを改善するために、これらの設定を変更することもできるでしょう。このポートは L2 キャッシュに接続されていて、 CPU およびACP ポート用になっています。

SDK で提供されているパフォーマンス解析機能を利用することで、こうしたパフォーマンス結果をすばやく、視覚的に検証することができます。


図 8‐8 : DDR と OCM の両方を使用した HP ポートの高帯域幅トラフィックのパフォーマンスサマリ




第 9章

メモリ階層および ACP の評価SPM (System Performance Modeling) デザインを使用して、 Zynq®-7000 AP SoC キャッシュのパフォーマンス効果を評価することができます。まずソフトウェアだけを使用したベースラインパフォーマンスを査定して、それから、アクセラレータコヒーレンシポート (ACP) のトラフィックの効果を評価できます。ソフトウェアのみを実行しているときはメモリパフォーマンスは非常に予測しやすいのですが、ほかのトラフィックアクティビティをシステムに加えると、結果はそれほど簡単には予測できなくなる可能性が出てきます。特に、 CPU および ACP のトラフィックは共有の L2 キャッシュで互いに影響し合う可能性があります。 SPM デザインを使用することで、この解析を非常に簡単に行うことができます。

メモリパフォーマンスの査定この査定を始めるには、 SPM デザインを使用し、ソフトウェアのみを実行したベースラインパフォーマンスを査定します。この評価に使用するアプリケーションは、SPM プロジェクトの中にあるプリコンパイルされた実行ファイルの 1 つ、メモリストライドベンチマークプログラムです。


図 9‐1 : メモリストライドベンチマークソフトウェアを使用したアプリケーション設定




第 9 章 : メモリ階層および ACP の評価

図 9-1 は、メモリストライドベンチマークソフトウェア実行ファイルを使用して SDK でこれを定義する方法を示しています (15 ページの「SPM ソフトウェア」を参照)。このソフトウェアは、帯域幅および平均レイテンシを計算するように設定されています (56 ページの「ソフトウェアの計測」を参照)。

プログラマブルロジック (PL) のトラフィックを使用せずに、ソフトウェアのみのテストでの帯域幅結果 (MB/秒) は表 9-1 に、レイテンシ結果 (ナノ秒) は表 9-2 にリストされています。 4KB、 64KB、 1024KB という 3 つのサイズは、メモリ階層の異なるステージでの帯域幅をテストするために使用されています。この 3 つのサイズは、SPM プロジェクトのプリコンパイルされたメモリストライド実行ファイルにより使用されています。これらのデータアレイの位置は、そのサイズと、プログラムで使用されているヒープ以外の場所にはまずみられないという事実から推測できます。

1 つのサイズ内でもっとも高い帯域幅はリニアの帯域幅テストで達成されます。これらのテストは 32 バイトのキャッシュラインを利用することができるからです。コピーや、読み出し /書き込みといった操作は、読み出しと書き込みの両方の操作が行われるため、一般的にその速度は遅くなります。 3 つのサイズのうち、 4KB アレイがいちばん高い帯域幅を維持し、 1024KB アレイがいちばん低い帯域幅を維持します。

表 9-1 および表 9-2 にリストされている 12 個のベンチマークが 3 つのデータアレイサイズでそれぞれに実行されるので、合計 36 個のテストが実行されています。各テスト間に 1 秒間のスリープが挿入されているため、 CPU 使用率を見れば、どのベンチマークが実行されているのかを見分けやすくなっています。図 9-2 には、結果のタイムラインが表示されています。各ベンチマーク内で、小さいサイズから大きなサイズへと順番に、 3 つのデータサイズが実行されています。 CPU0 の使用率およびその使用期間を確認できます。

表 9‐1 : メモリストライドベンチマークを使用したソフトウェアのみの帯域幅結果 (MB/秒)

パターンタイプ操作タイプサイズ

4KB 64KB 1024KB

リニア

読み出し 2141.4 338.4 118.1

書き込み 2114.8 238.4 57.6

コピー 1248.4 126.7 32.9

読み出し / 書き込み

1194.4 265.2 64.4

ランダム (予測値)

読み出し 1019.9 325.9 92.4

書き込み 532.4 285.6 64.1

コピー 442.6 140.6 31.9

ランダム

( リアルタイム)

読み出し 337.2 138.7 41.5

書き込み 409.8 393.6 70.0

コピー 409.7 159.4 32.8

表 9‐2 : メモリストライドベンチマークを使用したソフトウェアのみのレイテンシ結果 (ナノ秒)

パターンタイプ操作タイプサイズ

4KB 64 KB 1024 KB

リニア読み出し 1.87 11.82 33.88

ランダム (予測値)

読み出し 1.89 16.78 69.46





図 9-2 は、 [PS Performance] パネルにレポートされているほかの 3 つのグラフ、 L1 データキャッシュミス率、命令ごとの CPU 書き込み/読み出しのストールサイクル数が示されています。メモリストライドベンチマークは一定間隔で行われるので、それがこれらのグラフに反映されています。また、この 3 つのグラフは、データがどこに取り込まれているかに関する情報も示すことができます。 3 つに 1 つベンチマークの L1 データキャッシュミス率が 0% になりますが、これは 4KB のサイズが使用された場合です。ほかの 2 つのサイズは、 L1 データキャッシュには収まらないため、ミス率はほぼ 100% になります。

これらのキャッシュミスのソフトウェアへの影響は、命令ごとのストールサイクル数で確認できます。ストールサイクル数が多ければ、メモリ書き込み (書き込み) またはデータキャッシュ補充 (読み出し ) を待っている間のプロセッサのサイクル数が多くなります。つまり、そのベンチマークの有効帯域幅が低くなります。たとえば、図 9-2 にあるリニア帯域幅のコピーのベンチマークは、約 10 から 11 秒で実行されています。この期間中の命令ごとの CPU 書き込み/読み出しストールサイクル数が多いのは、すべてのメモリストライドベンチマークの中で最も低い帯域幅の1 つを維持しているからです (33.23 MB/秒、 49 ページの表 9-1を参照)。


図 9‐2 : メモリストライドベンチマークの PS パフォーマンスグラフ





データサイズおよび局所性メモリ階層のパフォーマンスをより視覚的確認するため、メモリストライドテストで使用されたサイズの範囲を1KB から 4096KB までにしました。これで、データサイズおよびその局所性が、 CPU で達成される帯域幅とレイテンシにどのように影響するかをはっきりと確認できるようになります。

51 ページの図 9-3は、メモリストライドテスト中に CPU0 で達成されたメモリ帯域幅を示しています。はっきりと説明できるように、ランダム帯域幅 ( リアルタイム) テストは、このグラフには表示されていません。サイズが大きくなると、 L1 と L2 データキャッシュの境界で大きく変動しています。これはサイズが前のキャッシュには収まらなくなってしまったからです。図 9-4 も、メモリストライドテスト中に CPU0 で達成される平均メモリアクセスレイテンシに対し、同じような変動があることを示しています。しかし、サイズが大きくなると帯域幅が低くなる一方で、レイテンシは大きく増加しています。


図 9‐3 : メモリストライドテストで達成した CPU メモリ帯域幅


図 9‐4 : メモリストライドテストで達成した CPU メモリアクセスレイテンシ





共有 L2 キャッシュCPU とメモリとの間のベースラインパフォーマンスを測ることができたので、次に、アクセラレータコヒーレンシポート (ACP) にトラフィックを追加して、システムパフォーマンスへのその影響を解析します。メモリストライドソフトウェア (15 ページの「SPM ソフトウェア」を参照) は、 CPU0 でまた実行されていますが、今回はトラフィックが ACP に追加されています。 L2 キャッシュは CPU と ACP で共有されているため、そのメモリである程度の競合が起きることが予測されます。

図 9-5 は、ACP の初期トラフィックをモデルする、AXI トラフィックジェネレーター (ATG) のコンフィギュレーションを示しています。 4KB 領域内でのランダムアドレス指定が指定されていますが、 L2 から DDR までのメモリパスが使用されています。 [Tranx interval] の最初の値は 100 クロックサイクルで、100MHz で 128MB/秒のスループットをリクエストするよう、 ATG がコンフィギュレートされます。そのほかの設定はそのままにしておき、 [Tranx interval]の値を下げます。そうすると、リクエストされたスループット値が増えていきます。このトランザクション間隔に使用される値は、 100、 50、 30、 25、 20、 17 です。これらの間隔はそれぞれ、 128、 256、 426、 512、 640、 752MB/秒のスループットをリクエストします。

このトラフィックシナリオで、帯域幅に関して、 CPU と ACP との間でのトレードオフを試行錯誤することができます。ただし、これは CPU と ACP が共有メモリ空間を使用していないケースをモデルしている点に注意してください。DDR に対しても同様で、 L2 データキャッシュは、スケジューリングに基づいて帯域幅を割り当てます。合わせた帯域幅が L2 キャッシュがサポートできる値より高い場合は、バックプレッシャーという形で競合が起きます。


図 9‐5 : ACP でのトラフィックをモデリングする ATG コンフィギュレーション





53 ページの図 9-6 は、 ACP トラフィックなしでメモリストライドを実行した後の、 SDK でのパフォーマンスサマリです。図 9-7 は、752MB/秒 ( トランザクション間隔は 17) をリクエストする ACP の読み出し /書き込みトラフィックを追加してメモリストライドを実行した同じパフォーマンスサマリです。これらは同じテストの 2 種類のサマリですが、その違いはある程度見られます。ACP トラフィックは図 9-7 で明らかに見られますが、CPU 統計は大体類似しています。

命令ごとの CPU 書き込みストールサイクル数と、命令ごとの CPU 読み出しストールサイクル数には 1 つ違いがあります。これらの値は、 ACP トラフィックなしで 2.03 および 4.10 ですが、高帯域幅の ACP トラフィックを追加すると、それぞれ 2.67 および 5.22 に増加します。これら 2 つの指標の値が高くなると、一般的にメモリ書き込みとデー


図 9‐6 : メモリストライドおよび ACP トラフィックなしのパフォーマンスサマリ


図 9‐7 : メモリストライドおよび 752 MB/秒をリクエストする ACP トラフィックのパフォーマンスサマリ





タキャッシュ補充で CPU がストールすることを示します。その理由は、 ACP トラフィックが L2 キャッシュの帯域幅をかなり使ってしまっているために、 L2 キャッシュで競合が起きるからです。

図 9-8 は、この競合が ACP の書き込みおよび読み出しのパフォーマンスにどのような影響を与えているのかを示しています。 ACP 書き込みパフォーマンスへの影響は最小限で、さまざまなソフトウェアベンチマークを試してみてもレイテンシにわずかな増加が見られるだけです。しかし、平均読み出しレイテンシは、メモリストライドソフトウェアの影響を明らかに受けていて、ベンチマークのシーケンスがその周期に反映されています。ACP スループットも影響を受けていて、約 640MB/秒のワーストケース値に低下しています。リクエストされた帯域幅 752MB/秒は、一般的なデザインにはおそらく値が高すぎて現実的ではありませんが、システムのストレステストには効果があります。


図 9‐8 : レイテンシへの影響を示す SDK での ACP パフォーマンス結果


図 9‐9 : CPU0 vs ACP 帯域幅 (サイズ = 4 KB) で達成されたパフォーマンス







リクエストされた ACP 帯域幅の値が確認されたので、維持されている CPU の帯域幅も記録されています。 54 ページの図 9-9は、 4KB のサイズを使用したメモリストライドでの CPU0 によって達成された帯域幅を示しています。図 9-10 は、メモリストライドが 64KB で実行されたときの CPU0 帯域幅を、図 9-11 は、メモリストライドが 1024KBで実行されたときの帯域幅を示しています。これらのサイズで得られた値は、L1 データキャッシュ、L2 データキャッシュ、そして DDR とそれぞれで達成された帯域幅の有効な計測値とみなされます。

メモリストライドソフトウェアを 4KB で実行する場合は、 CPU 帯域幅は ACP のトラフィックの影響は受けません(54 ページの図 9-9を参照)。 64KB および 1024KB を使用すると、 ACP トラフィックは CPU 帯域幅に大きな影響を与えます (図 9-10 および図 9-11 を参照)。CPU0 帯域幅が一番低下したのは、64KB でリニア帯域幅のコピーベンチマークを実行したときで、 14.6% でした。






第 10章

カスタムターゲットの使用ザイリンクスソフトウェア開発キット (SDK) のシステムパフォーマンス解析ツールボックスをデザインで使用するには、ソフトウェアの計測、ハードウェアの計測、そして SDK 内でのカスタムターゲットの監視という 3 つの重要な点を考慮する必要があります。

ソフトウェアの計測ソフトウェアランタイム、帯域幅、平均レイテンシは、 xtime_l.h ヘッダーで定義されているスタンドアロンの BSPで使用できる簡単な計測を使用します。各ベンチマークの前後に、 XTime_GetTime() が挿入されています (57 ページの図 10-1を参照)。 2 つの Xtime 値の差は、 xtime_l.h にある COUNTS_PER_SECOND 値を使用して秒 (またはミリ秒)に変換されています。ベンチマーク実行中に送信されるデータ量はわかっているため、その特定ベンチマークを実行している間に達成された帯域幅および平均レイテンシは計算することもできます。

#include <stdlib.h>#include <stdio.h>#include <unistd.h>#include "xtime_l.h" // XTime_GetTime()

// Macros#define TIMEDIFF(t1,t2) (t2 - t1)#define MILLISECONDS(t) (1000.0 * t / COUNTS_PER_SECOND)

// GlobalsXTime start, end;

// Start a testvoid startTest() { XTime_GetTime(&start);}

// End a testvoid endTest() { XTime_GetTime(&end); double time_curr = TIMEDIFF(start, end); double msec = MILLISECONDS(time_curr); printf("Run-time = %.2f msec...\n", msec);

// Achieved Bandwidth = (total bytes transferred) / (msec) // Average Latency = (msec) / (total memory accesses)}

// Dummy testvoid runSomething(int time) { sleep(time);}




第 10 章 : カスタムターゲットの使用

int main(void) { startTest(); runSomething(1); endTest();

startTest(); runSomething(2); endTest();

return 0;}

ハードウェアの計測SDK でパフォーマンス解析機能を使用したい場合は、プログラマブルロジック (PL) デザインに AXI パフォーマンスモニター (APM) を含める必要があります。 APM は既に SPM (System Performance Modeling) の固定ビットストリームデザインに含まれていることに注意してください (15 ページの「SPM ソフトウェア」を参照)。

図 10-2 は、Vivado® Design Suite の IP インテグレーターのブロック図におよびそのコンフィギュレーションパネルにAPM のインスタンスがどのように表示されるかを示しています。Vivado IP インテグレーターにこれを追加するには、APM のあるデザインを設定するための手順に従ってください。

1. IP インテグレーターのブロック図で、 [Add IP] ボタンをクリックします。

2. 「AXI Performance Monitor」を検索して、それをダブルクリックします。

3. APM をダブルクリックして [Re-Customize IP] ダイアログボックスを開きます。このダイアログボックスでは次のオプションを設定できます。


図 10‐1 :サンプルの C/C++ ソフトウェアコード


図 10‐2 : AXI パフォーマンスモニター –インスタンスとカスタマイズ





a. [APM Mode] の下にある [Profile] をチェックします。

b. [Number of Monitor interfaces] を 5 に設定します。

4. 次の作業を行って、 APM をユーザーデザインに接続します。

a. Zynq-7 プロッセシングシステム (AXI インターコネクトを介す) の GP0 または GP1 に S_AXI を接続します。

b. SLOT_x_AXI ポート (x=0…4)に HP0、 HP1、 HP2、 HP3、および ACP を接続します。これらのインターフェイスがデザインで使用されていない場合は、対応するスロットを未接続のままにしておきます。

c. s_axi_aclk および s_axi_aresetn を、 GP0/GP1 に関連付けられているクロックおよびリセットに接続します。

d. すべての入力、 slot_x_axi_aclk および slot_x_axi_aresetn を該当するクロックおよびリセットに接続します。

e. core_aclk および core_aresetn をもっとも高いクロック周波数でクロック / リセットに接続します。

5. [File] → [Export] → [Export Hardware] をクリックして、ビットストリームをビルドして、 Vivado からエクスポートします。

6. [File] → [New] → [Project] をクリックして、次に [Xilinx] → [Hardware Platform Specification] をクリックして、生成されたファイル <your design>.hdf をSDK にインポートします。

カスタムターゲットの監視SDK には、第 11 章「徹底パフォーマンス解析」で説明したような、実行しているターゲットを監視する機能があります。ターゲットのオペレーティングシステムに関わらず、テクニックには 2 つあり、どちらも使用できます。違いは、ハードウェアプラットフォーム仕様が SDK にインポートされるかどうかです。これは Vivado で作成されたハードウェアデザインで、プロジェクトとして SDK にインポートされます。

Vivado でデザインが定義されているなら、そのデザインに基づいてハードウェアプラットフォーム仕様を作成することをお勧めします。その後、その仕様に基づいてパフォーマンス解析を実行できます。手順は次のとおりです。


図 10‐3 :デバッグコンフィギュレーションでのターゲット設定 (インポートされたハードウェアプラットフォーム仕様を使用)





1. Vivado で [File] → [Export] → [Export Hardware] をクリックして、ビットストリームをビルドして、 Vivado からエクスポートします。 [File] → [New] → [Project] をクリックして、次に [Xilinx] → [Hardware Platform Specification]をクリックして、生成されたファイル <your design>.hdf をSDK にインポートします。

2. [Run] → [Debug Configurations] をクリックして、パフォーマンス解析コンフィギュレーションを作成します。

3. パフォーマンス解析をコンフィギュレーションするには次の手順に従います。

a. [Performance Analysis] を選択して、 [New] をクリックします。

b. [Debug Type] を [Standalone Application Debug] に設定します。

c. [Hardware platform] を先ほどインポートしたハードウェアプラットフォーム仕様に設定します。その他にも、システム全体のリセット、 FPGA のプログラム、 ps7_init の実行、 ps7_post_config の実行、クロストリガーのイネーブルといったオプションがあります。

d. パフォーマンス解析のパースペクティブを開くには、 [Debug] をクリックします。

58 ページの図 10-3 は、第 11 章「徹底パフォーマンス解析」で使用されているターゲット設定を示しています。これは、 Zynq®-7000 AP SoC 基本ターゲットリファレンスデザイン (TRD) に接続し、これを監視するためのものです。チェックボックスはすべてオフになっていることに注意してください。TRD は SD カードブートを使用するため、システムは既にリセットおよびコンフィギュレーションされています。

何らかの理由でハードウェアプラットフォーム仕様を作成できない場合は、SDK でパフォーマンス解析を実行することができます。手順は次のとおりです。

1. [Run] → [Debug Configurations] をクリックして、パフォーマンス解析コンフィギュレーションを作成します。

2. [Performance Analysis] を選択して、 [New] をクリックします。

3. [Debug Type] を [Attach to running target] に設定します。

4. [PS Processor Frequency (MHz)] をデザインで使用されている PS クロック周波数に設定します。

5. デザインに APM が含まれる場合は、次を実行します。

a. [Enable APM Counters] を実行します。


図 10‐4 :デバッグコンフィギュレーションのターゲット設定 (ハードウェアプラットフォームなし )





b. [APM Frequency (MHz)] をデザインの APM コアの s_axi_aclk に接続されているクロックの周波数に設定します。

c. [APM Base Address] をデザインの APM の基本アドレスに設定します。

6. パフォーマンス解析のパースペクティブを開くには、 [Debug] をクリックします。

59 ページの図 10-4 は第 11 章「徹底パフォーマンス解析」で使用されているターゲット設定を示しています。これは『Zynq-7000 All Programmable SoC ZC702 基本ターゲットリファレンスデザイン』 (UG925) [参照 3] で説明されているZynq-7000 AP SoC 基本ターゲットリファレンスデザイン (TRD) に接続し、これを監視するためのものです。 APM周波数は 50MHz で、 APM 基本アドレスは 0x400F0000 という 16 進数に設定されていることに注意してください。




第 11章

徹底パフォーマンス解析SDK では徹底したパフォーマンス解析フローを実行することができます (7 ページの図 1-2を参照)。このフローを使用し、予想デザインでトラフィックをモデルした後に、実際のデザインを使用してパフォーマンスを検証できます。この徹底フローをよりわかりやすくするため、この章ではサンプルデザインを使ってフローを説明します。使用されるデザインは Zynq-7000 AP SoC ベースのターゲットリファレンスデザイン (TRD) で、これは『Zynq-7000 AllProgrammable SoC ZC702 ベースのターゲットリファレンスデザイン (TRD) で、これは『Zynq-7000 All Programmableのターゲットリファレンスデザイン』 (UG925) [参照 3]で説明されています。

要件の査定図 11-1 は、 HDMI ビデオ入力と出力があり、ソーベルフィルターを使用した処理を行う、 TRD のブロック図です。DDR メモリには複数のビデオフレームが格納され、高い帯域幅の書き込みおよび読み出しトラフィックのチャネルが複数作成されます。

ここでは、このデザインは計画段階にあって、まだ完成していないものとします。 SPM を使用してこのデザインをモデルするにはどうしたらよいでしょうか。まず、システムの帯域幅要件を査定します。これには、まずデザインの通信チャネルすべての予期帯域幅を計算し、次に、 PS-PL インターフェイスを決めます。これは AXI トラフィックなので、トランザクションごとのサイクル数、そしてデータの局所性も重要です。

帯域幅を計算するには、入力され、処理されているデータのタイプを知っておく必要があり、それをディスプレイに出力します。 61 ページの図 11-1 に示すように、 TRD の入力データは、 CbCr 4:2:2 のデータフォーマットで 1080p/60のビデオ、または 16ビット /ピクセルを出力する HDMI ソースです。このデザインには、フィルターを介したビデオと、コントロールおよびグラフ用の GUI レイヤーを表示させるため、出力ディスプレイに複数のビデオレイヤーを


図 11‐1 : Zynq‐7000 AP SoC ベースの TRD ハードウェアブロック図




第 11 章 : 徹底パフォーマンス解析

オーバーレイさせるという要件もあります。GUI レイヤーは 1920 x 300、RGB 4:4:4 フォーマットで、ほかのレイヤーはすべてフルフレーム、 YCbCr 4:2:2 フォーマットです。クロック周波数はまだわからなくても、データトラフィックの必須帯域幅を使用して、システムをモデルすることができます。

表 11-1 は Zynq-7000 AP SoC ベースの TRD の帯域幅査定のまとめです。各ビデオチャネルの計算された帯域幅は、DDR 帯域幅のパーセンテージとともにリストされています。このデザイン仕様では、 HP0 および HP2 が使用されています。この 2 つでは、 DDR コントローラーで異なるポートが使用されるからです。もちろん、ほかのコネクティビティのモデリングも可能です。

表 11‐1 : Zynq‐7000 AP SoC ベースの TRD での帯域幅の査定

説明ビデオフォーマットポートタイプ帯域幅 DDR 帯域幅 (%)

HDMI ビデオ入力 YCbCr 4:2:2 HP0 書き込み 248.8 5.8

処理入力 YCbCr 4:2:2 HP2 読み出し 248.8 5.8

処理出力 YCbCr 4:2:2 HP2 書き込み 248.8 5.8

マルチレイヤービデオ出力

(レイヤー 1 : 1920 x 300GUI)

RGB 4:4:4 HP0 読み出し 138.3 3.3

マルチレイヤービデオ出力

(レイヤー 2 : 1920 x 1080)

YCbCr 4:2:2 HP0 読み出し 248.8 5.8

合計トラフィックなし HP0/HP2 書き込み/読み出し 1133.4 26.5





デザインのモデル帯域幅要件が確認できたので、次は SPM デザインを使用してモデリングを実行します。必要というわけではありませんが、プロセッシングシステム (PS) トラフィックのモデルには、ソフトウェアアプリケーションの使用を推奨します。ここでは、 PS で動きの激しいアクティビティをモデルするため、メモリストライドソフトウェアアプリケーションを使用します。実際のデザインでは実行されるソフトウェアではありませんが、アクティビティとメモリ帯域幅に関して、ワーストケースのテストシナリオを提供します。

図 11-2 は、 SPM を使用して TRD のトラフィックをモデルする方法の 1 つを示しています。ビデオフレームはメモリの別の部分に格納されるものとし、 [Address Start] の値は ddr0 および ddr2 に設定されています。さらに、ビデオデータは通常連続するデータラインとして格納されるので、 [Address Next] の値は [increment] に設定されています。[Beats/tranx] の値は、ソーベルフィルターへの入/出力ビデオ、そしてマルチレイヤービデオ出力をモデルするために、それぞれ 8 および 16 が選択されています。 [Tranx interval] は、 62 ページの表 11-1にまとめられているように、それぞれのポートおよびタイプに対して求められるスループットに一致するように指定されています。


図 11‐2 : Zynq‐7000 AP SoC ベースの TRD のトラフィックをモデルするための ATG コンフィギュレーション





ATG は、指定されたトラフィックでコンフィギュレーションされ、ZC702 ボードで実行されています。図 11-3 は、この実行後の結果をまとめたものです。 HP0 および HP2 の両方で、このデザインに必要な書き込みおよび読み出しの帯域幅を達成できています。CPU パフォーマンス結果はメモリストライドベンチマークのもので、実際の TRD アプリケーションではありませんが、このアクティビティをもとに予測することはできます。


図 11‐3 : Zynq‐7000 AP SoC ベースの TRD をモデリングしたパフォーマンス結果


図 11‐4 : Zynq‐7000 AP SoC ベースの TRD をモデリングした書き込みおよび読み出しのパフォーマンス





図 11-4 は、サイリンクスソフトウェア開発キット (SDK) からの書き込みおよび読み出しのパフォーマンスグラフで、達成されたパフォーマンスの詳細を示しています。平均書き込みレイテンシおよび書き込みスループットは、テスト全体で一定しています。平均読み出しレイテンシはメモリストライドベンチマークの影響を大きく受けています。これは DDR コントローラーで競合が起きているためです。しかし、読み出しスループットはテスト全体を通して一定しています。

第 1 章「概要」で説明したように、特にデザインが計画段階にある場合は、このモデリングを実行したほうがよい理由がいろいろとあります。この特定デザインに限っていうと、次のような理由があります。

• リスクを軽減 – この SPM モデルは、必要なレイテンシおよびスループットが達成可能であることを証明しています。つまり、 Zynq-7000 AP SoC ベースの TRD で、同じパフォーマンスが得られる可能性が非常に高いことを示しています。

• デザインの改善 – 64 ページの図 11-3 はモデルの HP0 および HP2 の平均読み出しレイテンシがそれぞれ 40.13、32.41 であることを示しています。フレームレートの制約がはっきりとしているこのようなビデオデザインの場合、ディスプレイコントローラーをこの指標範囲内で動作するように設計することができます。

• さまざまなシナリオ設定 – 出力ディスプレイにもっとビデオレイヤーを追加することも可能です。実際のデザイン内で繰り返し検証作業を行わずに、SPM を使用してシナリオを想定して先に検証しておくことができます。ほかにも、 2 番目のビデオパイプラインを含めたり、 4K の解像度に上げてみたりするオプションもあります。これらのシナリオはすべてモデル可能で、デザインフェーズが始まる前に解析することができます。

パフォーマンス検証SPM モデルのパフォーマンスは実際のデザインを使用して検証できます。 APM を含む、正しく計測されたデザインを使用し、 Zynq-7000 AP SoC ベースの TRD のパフォーマンスを解析します (57 ページの「ハードウェアの計測」を参照)。 2015.1 で配布されている TRD では既に検証が行われています。

図 11-5 は、 Vivado® Design Suite の IP インテグレーターでブロック図で定義されている TRD を示しています。 APMインスタンスがハイライトされています。 APM はプロファイルモードでコンフィギュレートされていて、パフォーマンス結果が正しく SDK にレポートされるようになっています。 HP0 は AXI パフォーマンスモニター (APM) のス


図 11‐5 : Zynq‐7000 AP SoC ベースの TRD の Vivado IP インテグレーターのブロック図





ロット 0 に接続されていて、 HP2 はスロット 2 に接続されています。スロット 1 はオープンのままで (HP1 が使用されていないため)、 [Number of Monitor interfaces] は 3 に設定されています。

図 11-6 は、デモを実行するための ZC702 ボードへの接続図です。ボードは図にあるように接続され、デザインは SDカードからブートされます。

結果は67 ページの図 11-7 の表にまとめられていて、その図は67 ページの図 11-8 にあります。プログラマブルロジック (PL) のパフォーマンス結果は、直接、64 ページの図 11-3 にある SPM モデルから収集された値と比較できます。モデルからの書き込みおよび読み出しスループットはすべて実際の結果の 2.0% 内にすべて収まっています。書き込みレイテンシは実際のデザインの 1 サイクル内にあり、モデルの平均読み出しレイテンシは実際のデザインの 16.0% 内です。実際のデザインは、もともと SPM よりもバースト性が高いようですが、平均パフォーマンス値は十分に正確で、 TRD でパフォーマンス目標が満たすことができるでしょう。


図 11‐6 : ZC702 ボードを使用した Zynq‐7000 AP SoC ベースの TRD の接続図






図 11‐7 :実際の Zynq‐7000 AP SoC ベースの TRD のパフォーマンス結果


図 11‐8 : Zynq‐7000 AP SoC ベースの TRD の書き込みおよび読み出しのパフォーマンス





詳細な解析2 番目の TRD の実行は、 TRD のさまざまなランタイム設定のパフォーマンスへの影響を調べるために、実行されています。表 11-2 は、これらすべて設定、そして SDK で得られたその設定に対応したパフォーマンス結果をまとめたものです。時間はこれらの設定がテスト実行中に使用されたときで、およその時間です (69 ページの図 11-9 および69 ページの図 11-10 を参照)。表 10 の最終行は、64 ページの図 11-3でモデリングされたトラフィックシナリオと、図55 にある実際のデザインを使用した実行に対応しています。

表 11-2 にリストされているように、パフォーマンスへの影響は直接 SDK で計測できます。実際の TRD では、GUI ビデオ出力レイヤーには最小化モード (1920 x 80) および最大化モード (1920 x 300) の 2 つがあります。 0 から 20 秒の間、ビデオフレームのその部分だけがハードウェアで出力され、ビデオディスプレイに送信されます。これは、 HP0での読み出しスループットで確認できます。出力ビデオがイネーブルになった後、合計 HP0 の読み出し帯域幅にはフルビデオフレームおよび GUI レイヤーが含まれます。入力 4:2:2 のビデオも HP0 の DDR に書き込まれます。

ソーベルフィルターをオンにすると、パフォーマンスには非常に大きな変化が出ます。ソフトウェアモードが使用されているとき、明らかに CPU アクティビティが増加し、特に L1 データキャッシュアクセスが多くなっています。また、ソーベルフィルターをハードウェアモードで使用すると、HP2 の書き込みおよび読み出しトラフィックにはっきりと影響が出ます。

Zynq-7000 AP SoC ベースの TRD のパフォーマンス結果は、69 ページの図 11-9 および69 ページの図 11-10 にあるグラフを見ると特にはっきりとわかります。 69 ページの図 11-9にある PS パフォーマンス結果に関しては、約 30 秒から50 秒の間、ソーベルソフトウェアフィルターモードが使用されているときに注目すべきです。この時間は、一定して CPU 使用率が高く、 IPC や L1 データキャッシュアクセスなどの値がとても高くなっています。

69 ページの図 11-10 にある PL パフォーマンスに関しては、どの時間にもはっきりとした特徴が見られます。もちろん、約 50 秒から 70 秒の間、ソーベルハードウェアフィルターが使用されているときに、いちばんアクティビティが見られます。 HP0 および HP2 での書き込みスループット、 HP2 での読み出しスループットは、 4:2:2 のビデオストリームの予期値にすべて対応しています。 HP0 の読み出しスループットには、 4:2:2 のフルフレームビデオとパーシャルフレームの GUI レイヤーが含まれているため、値が高くなっています。

まとめると、Zynq-7000 AP SoC ベースの TRD を計測することには、1) 最初に SPM でモデルされたパフォーマンス結果を検証できる、そして 2) さまざまなデザイン設定でもっと踏み込んだ解析ができる、という 2 つの大きな利点があります。

表 11‐2 :実際の Zynq‐7000 AP SoC ベースの TRD のパフォーマンス指標のまとめ

説明時間 (単位は秒、

概算値)

L1 データキャッシュアクセス (x103)

書き込みスループット (MB/秒)

読み出しスループット (MB/秒)

CPU0 CPU1 HP0 HP2 HP0 HP2

GUI のみ、最小化

0-10 100 100 0 0 37 0

GUI のみ、最大化

10-20 100 100 0 0 140 0

ビデオイネーブル

20-30 100 100 246 0 382 0

ソーベルフィルター – ソフトウェア

モード

30-50 2800 7000 246 0 382 0

ソーベルフィルター – ハードウェア

モード

50-70 100 200 246 246 382 246






図 11‐9 : Zynq‐7000 AP SoC ベースの TRD の PS パフォーマンスグラフ


図 11‐10 : Zynq‐7000 AP SoC ベースの TRD の PL パフォーマンスグラフ




付録 A

パフォーマンスチェックリストこの付録では、Zynq®-7000 AP SoC デザインのパフォーマンスを評価するときに考慮すべき項目をまとめたチェックリストを提供します。これはすべての項目を挙げているリストではありませんが、注意点や、なかなか気づけないような点をリストしていて、これを手始めにして作業を進めるという形で利用してください。サイリンクスソフトウェア開発キット (SDK) も、システムパフォーマンスを評価するのに便利なツールで、その機能や利点もいくつかここに挙げています。

• システムパフォーマンスモデリングの仕様

システムパフォーマンスモデリング (SPM) は、ハードウェア設計の経験や知識がなくても、システムパフォーマンスを調べる場合に理想的です。SPM を使用することで、パフォーマンス目標を満たすことができるという確認作業ができ、達成できたパフォーマンスの指標が把握しやすくなり、さまざまなシナリオを設定して調査していく環境を提供できます。デザインを作成してたり、デバッグしている途中であっても、 SPM を利用することで、オーバーヘッドを出すことなく、デザインを調査し、アーキテクチャに関する判断材料を得ることができます。このガイドでは、わかりやすいように、さまざまな例が用意されています。

• SPM でのクロック周波数の調整

SPM を使用して、プロセッシングシステム (PS)、プログラマブルロジック (PL)、および DDR のクロック周波数を調整するための調査ができます。帯域幅の高いシステムが求められる場合は、スループットを増やすためにクロック周波数を調整することをお勧めします。初期段階の評価環境では、周波数はデザイン目標にもなります。

• L2 キャッシュプリフェッチの設定/設定解除

PL310 キャッシュコントローラーで命令およびデータのプリフェッチ設定をチェックします。チェック方法については、第 6 章「ソフトウェアパフォーマンスの評価」を参照してください。

• コンパイラ最適化設定

SDK で C/C++ ビルド設定をチェックします。ベストパフォーマンスを得るには、 [Optimize More (O2)] または[Optimize Most (O3)] を使用することを推奨します。

• 効率的なソフトウェアコードの記述

このガイドでは、行列乗算のパフォーマンスを約 5 倍伸ばす方法が説明されています。ハイパフォーマンスで、効率的なソフトウェアコードの記述方法に関しては、 Ulrich Drepper 著『What Every Programmer Should Know AboutMemory』 (Ref [3]) を参照してください。この資料では、次のような点を考慮するようアドバイスされています。

° キャッシュのバイパス (一時的な書き込み用ではない場合)

° キャッシュアクセスおよびミス率の最適化

° プリフェッチの使用

° 同時並行処理やマルチスレッドの検討

• 競合の把握

ソフトウェアのみのテストを実行するだけでも予測可能なパフォーマンス結果が得られますが、 HP ポートまたはACP にトラフィックシナリオを導入すると、パフォーマンスに影響が出て、予測が難しくなります。ほかの高帯域幅のトラフィックをシステムに追加すると、必ず L2 キャッシュ、ハイパフォーマンススイッチ、または DDR コントローラーに競合が発生します。この競合と、その影響を把握しておくと、非常に役立ちます。




付録 A : パフォーマンスチェックリスト

• DDR コントローラー設定

これらの設定は SDK (SPM デザインのみ) または Vivado® Design Suite で Processing System 7 (PS7) IP ブロックのコンフィギュレーションで変更することができます。これらの設定は、システムのニーズに基づいて、 DDR から帯域幅を割り当て直すのに使用します。この変更方法、および CPU と HP ポートの DDR 帯域幅への影響については、第 8章「DDR コントローラー設定の評価」を参照してください。

• Zynq-7000 AP SoC オンチップメモリの使用

オンチップメモリ (OCM) は 256KB のメモリブロックで、アクセラレータコヒーレンシポート (ACP)、汎用ポート(GP)、ハイパフォーマンス (HP) ポートから、 CPU とプログラマブルロジックにアクセスできます。 OCM は低レイテンシアクセスを可能にし、同期化またはスクラッチパッドアプリケーションで使用するのに理想的なコンポーネントです。

• アクセラレータコヒーレンシポートの使用

ACP は ARM Cortex-A9 プロセッサーとのキャッシュコヒーレンシ用です。このコヒーレンシは一部のアプリケーションでは有用ですが、 L2 キャッシュで競合が起きる可能性があります。この競合がデザインに発生するのは好ましくない場合は、 OCM を ACP と一緒に使用して、低レイテンシメモリインターフェイスを作成します。

• ハイパフォーマンスポートの使用

HP ポートは、 PS、 PL、 DDR の間にスループットが非常に大きなインターフェイスを提供します。 HP ポートは、高い帯域幅が必要な部分であれば、デザインのどこにでも推奨されます。すべての HP ポートは同じに作成されていますが、 DDR コントローラーで使用される HP ポートのペアを把握しておくことは重要です。 HP0 と HP1 とで 1 つのDDR ポートを共有しており、 HP2 と HP3 とで別の DDR ポートを共有しています。これらのポートぺアは一緒に使用することもできますし (DDR 設定を変更する場合)、個別に使用することもできます (複数の DDRC ポートで帯域幅を最大限にするため)。




付録 B

その他のソースおよび法的通知

ザイリンクスリソースアンサー、資料、ダウンロード、フォーラムなどのサポートリソースは、ザイリンクスサポートサイトを参照してください。

ソリューションセンターデバイス、ツール、 IP のサポートについては、ザイリンクスソリューションセンターを参照してください。トピックには、デザインアシスタント、アドバイザリ、トラブルシュートヒントなどが含まれます。

参考資料さらに詳細な情報が必要な場合は、次のリファレンスを参照してください。

ザイリンクスユーザーガイドおよびリファレンスガイド

1. 『Zynq-7000 All Programmable SoC テクニカルリファレンスマニュアル』 (UG585)

2. Vivado Design Suite ユーザーガイド : エンベデッドプロセッサハードウェアデザイン』 (UG898)

3. 『Zynq-7000 All Programmable SoC ZC702 基本ターゲットリファレンスデザイン (ISE Design Suite 14.4) ユーザーガイド』 (UG925)



http://japan.xilinx.com/support/

http://japan.xilinx.com/support/solcenters.htm

http://japan.xilinx.com/cgi-bin/docs/ndoc?t=user+guides;d=ug585-Zynq-7000-TRM.pdf

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2015.1;d=ug898-vivado-embedded-design.pdf

http://japan.xilinx.com/support/documentation/boards_and_kits/zynq-7000/zc702_ug/v3_0/ug925-zynq-zc702-base-trd.pdf


付録 B : その他のソースおよび法的通知

サードパーティの参考文献

4. James Pallister、Simon Hollis、Jeremy Bennett 共著、「BEEBS: Open Benchmarks for Energy Measurements on EmbeddedPlatforms」 (2013 年 8 月 23 日)オンライン版 : http://dblp.uni-trier.de/db/journals/corr/corr1308.html#PallisterHB13

5. David A. Patterson、John L. Hennessy 共著、『Computer Organization & Design: The Hardware/Software Interface』 (MorganKaufman Publishers, Inc.、第 2 版、 1998 年)

6. Ulrich Drepper 著、「What Every Programmer Should Know About Memory」 (2007年 11 月 21 日)オンライン版 :http://www.cs.bgu.ac.il/~os142/wiki.files/drepper-2007.pdf.

トレーニングリソースザイリンクスでは、本書に含まれるコンセプトを説明するさまざまなトレーニングコースおよびオンラインビデオを提供しています。次のリンクから関連するトレーニングリソースを参照してください。

1. Zynq-7000 All Programmable SoC : 開発ツールの概要

2. Zynq-7000 All Programmable SoC : システムパフォーマンスツールの概要

3. Zynq-7000 All Programmable SoC : 5 分間で Hello World

4. Zynq-7000 All Programmable SoC : ベアメタルアプリケーション開発

重要な法的通知本通知に基づいて貴殿または貴社 (本通知の被通知者が個人の場合には「貴殿」、法人その他の団体の場合には「貴社」。以下同じ )に開示される情報 (以下「本情報」といいます) は、ザイリンクスの製品を選択および使用することのためにのみ提供されます。適

用される法律が許容する最大限の範囲で、 (1) 本情報は「現状有姿」、およびすべて受領者の責任で (with all faults) という状態で提供

され、ザイリンクスは、本通知をもって、明示、黙示、法定を問わず (商品性、非侵害、特定目的適合性の保証を含みますがこれら

に限られません)、すべての保証および条件を負わない (否認する ) ものとします。また、 (2) ザイリンクスは、本情報 (貴殿または貴

社による本情報の使用を含む) に関係し、起因し、関連する、いかなる種類・性質の損失または損害についても、責任を負わない (契約上、不法行為上 (過失の場合を含む)、その他のいかなる責任の法理によるかを問わない) ものとし、当該損失または損害には、

直接、間接、特別、付随的、結果的な損失または損害 (第三者が起こした行為の結果被った、データ、利益、業務上の信用の損失、

その他あらゆる種類の損失や損害を含みます) が含まれるものとし、それは、たとえ当該損害や損失が合理的に予見可能であった

り、ザイリンクスがそれらの可能性について助言を受けていた場合であったとしても同様です。ザイリンクスは、本情報に含まれ

るいかなる誤りも訂正する義務を負わず、本情報または製品仕様のアップデートを貴殿または貴社に知らせる義務も負いません。

事前の書面による同意のない限り、貴殿または貴社は本情報を再生産、変更、頒布、または公に展示してはなりません。一定の製

品は、ザイリンクスの限定的保証の諸条件に従うこととなるので、 http://japan.xilinx.com/legal.htm#tos で見られるザイリンクスの販

売条件を参照してください。 IP コアは、ザイリンクスが貴殿または貴社に付与したライセンスに含まれる保証と補助的条件に従う

ことになります。ザイリンクスの製品は、フェイルセーフとして、または、フェイルセーフの動作を要求するアプリケーションに

使用するために、設計されたり意図されたりしていません。そのような重大なアプリケーションにザイリンクスの製品を使用する

場合のリスクと責任は、貴殿または貴社が単独で負うものです。 http://japan.xilinx.com/legal.htm#tos で見られるザイリンクスの販売

条件を参照してください。

© Copyright 2015 Xilinx, Inc. Xilinx、 Xilinx のロゴ、 Artix、 ISE、 Kintex、 Spartan、 Virtex、 Vivado、 Zynq、およびこの文書に含まれる

その他の指定されたブランドは、米国およびその他各国のザイリンクス社の商標です。すべてのその他の商標は、それぞれの保有

者に帰属します。

この資料に関するフィードバックおよびリンクなどの問題につきましては、 [email protected] まで、または各ページの

右下にある [フィードバック送信] ボタンをクリックすると表示されるフォームからお知らせください。フィードバックは日本語で

入力可能です。いただきましたご意見を参考に早急に対応させていただきます。なお、このメールアドレスへのお問い合わせは受

け付けておりません。あらかじめご了承ください。


http://japan.xilinx.com/legal.htm#tos

http://japan.xilinx.com/legal.htm#tos

http://dblp.uni-trier.de/db/journals/corr/corr1308.html#PallisterHB13

http://www.cs.bgu.ac.il/~os142/wiki.files/drepper-2007.pdf

http://japan.xilinx.com/cgi-bin/docs/ndoc?t=training;d=zynq/zynq-development-tools-overview.htm

http://japan.xilinx.com/cgi-bin/docs/ndoc?t=training;d=zynq/xilinx-sdk-system-performance-tools-overview.htm

http://japan.xilinx.com/cgi-bin/docs/ndoc?t=training;d=zynq/hello-world-in-5-minutes-using-xilinx-sdk.htm

http://japan.xilinx.com/cgi-bin/docs/ndoc?t=training;d=zynq/zynq-bare-metal-application-development-using-xilinx-sdk.htm

mailto:[email protected]



ザイリンクス ソフトウェア 開発キット (SDK) ユーザー ガイド...ザイリンクス ソフトウェア開発 ザイリンクス ソフトウェア 開発キット

Documents

ザイリンクスソフトウェア開発キット (SDK) ユーザーガイド...ザイリンクスソフトウェア開発ザイリンクスソフトウェア開発キット