all programmable soc のシステム性能解析 -...

XAPP1219 (v1.0) 2014 年 12 月 11 日 japan.xilinx.com 1

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

概要このアプリケーションノートでは、 Zynq-7000 All Programmable (AP) SoC の性能を評価、測定、およびモデル化するために必要な情報を提供します。サンプルデザインを用いて、 Zynq-7000 デバイスのシステム性能をさまざまな側面から説明します。このデザインは、 Zynq-7000 アーキテクチャのプログラマブルロジック (PL) とプロセッシングシステム間の通信に焦点を当てています。また、このデザインを利用して、システムをモデル化し、 Zynq-7000 AP SoC が特定システムの性能要件を満たすかどうかを判断できます。

このアプリケーションノートに付属するデザインは、SDK で提供される SPM (System Performance Modeling) プロジェクトを適用しています。詳細は、『SDK ユーザーガイド : システム性能解析』 (UG1145) [参照 1] を参照してください。 SPM プロジェクトは、実際のターゲットハードウェアで実行され、 5 つの AXI トラフィックジェネレーターを備えた固定ビットストリームを含みます。これらのトラフィックジェネレーターはコンフィギュレーション可能なコアであり、プログラマブルロジック (PL) のトラフィックアクティビティをモデル化するために SDK で使用されます。ソフトウェアアプリケーションもプロセッシングシステム (PS) で同時に実行可能であり、ユーザーはシステムコンフィギュレーションパラメーターを指定できます。ユーザーが SPM プロジェクトを実行した後、アプリケーションをより正確に反映させるために、このアプリケーションノートのデザインを使用できます。

はじめにこのアプリケーションノートは、主に次の 3 つのセクションで構成されています。

• 最初のセクションでは、 Zynq-7000 AP SoC のシステム性能について説明しています。

• 2 番目のセクションでは、次の方法について説明しています。

° PL に実装するデザインのシステムモデルを実行してアプリケーションをエミュレートする。

° SDK (ソフトウェア開発キット ) でモデルを使用して、システム性能の指標を示す。

• 3 番目のセクションでは、次の方法について説明しています。

° 独自のソフトウェアを追加してモデルを実行する。

° PL 内のアイテムを独自の IP に置き換える。

必要なハードウェアおよびツールリファレンスシステムのハードウェア要件は次のとおりです。

• ZC702 評価ボード

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

• USB Type-A/Mini-B ケーブル (UART 通信用)

• USB Type-A/Micro-B ケーブル (JTAG アクセス用)

• Vivado® Design Suite 2014.3

アプリケーションノート : Zynq-7000 AP SoC

XAPP1219 (v1.0) 2014 年 12 月 11 日

All Programmable SoC のシステム性能解析著者 : Forrest Pickett

http://japan.xilinx.com

http://japan.xilinx.com/about/feedback.html?docType=Application_Notes&docId=XAPP1219&Title=All%20Programmable%20SoC%20%26%2312398%3B%26%2312471%3B%26%2312473%3B%26%2312486%3B%26%2312512%3B%26%2324615%3B%26%2333021%3B%26%2335299%3B%26%2326512%3B&releaseVersion=1.0&docPage=1

AP SoC システム性能


AP SoC システム性能SoC の性能は、デバイスまたはシステムレベルで測定され、インターフェイスや回路ブロックレベルでは測定されません。性能を決定する最も重要な要素は、システムアーキテクチャが共有リソースの競合を処理する効率性です。通常、結合されたブロックには、アプリケーションプロセッサユニット (APU)、インターコネクト、 I/O ペリフェラル、 I/O、およびメモリコントローラー (スタティック /ダイナミック ) が含まれます (図 1)。次に重要な要素は、これらのブロックが動作するスピード、および生成するトラフィックです。これらのブロックは、サブシステム (アプリケーションプロセッサユニット、 I/O サブシステム、およびメモリサブシステムなど) にグループ化できます。特に AP SoC 上にあるメモリサブシステムは、 SoC 性能に影響を与える最も重要な共有リソースサブシステムです。

システム性能に影響を与える要素を次に示します。

• キャッシュサイズ

• メモリスピード

• メモリの効率

• メモリデータ幅

• CPU スピード

• インターコネクト

• ブロックの統合

これらの要素の中には不変で変更できないものがありますが、ほとんどの要素は、デバイス、プラットフォーム、またはデザインによって異なります。

このアプリケーションノートで使用される効率性および有効性は、次のように定義されています。

効率性とは、メモリコントローラーが効率的に DRAM を使用することを示します。効率的なメモリコントローラーは、DRAM をインテリジェントに使用して、より広い帯域幅を実現します。帯域幅は MB/s で測定され、効率はパーセンテージで測定されます。

X-Ref Target - Figure 1

図 1 : SoC ブロック図の例





有効性とは、 DRAM コントローラーが効果的にメモリ帯域幅を分配することを示します。言い換えれば、異なるポートに帯域幅を与える際の DDR コントローラーの「公平性」を示します。

つまり、効率性とは、論理上の最大帯域幅からどれだけの帯域幅を実現できるかを示し、有効性とは、その帯域幅が競合ブロックにいかに分配されるかを示します。図 2 に、システム性能に影響を与える最も重要な要素を示します。

SoC に課せられた重要な任務の一つは、データ依存のストールを最小限に抑えて CPU を継続的に実行することです。これを達成するには、 CPU で使用されるデータをキャッシュへロードする必要があります。このようにした場合、メインメモリよりもアクセスレイテンシが大幅に減少します。データをキャッシュへロードするスピードは、メモリサブシステムの性能に依存します。たとえば、メモリサブシステムの帯域幅が不足している場合、キャッシュは指定時間内にフルにならずに、 CPU はストールしてデータを待機します。メモリサブシステムの性能は、主に次の要素に依存します。

• メモリのスピード (周波数)

• DRAM コントローラーの効率性

• DRAM コントローラーの有効性

• メモリインターフェイスの幅 (内部/外部)

° DDR コントローラーへのポート (内部)

° DRAM へのインターフェイス (PHY 経由 - 外部)

注記 : メモリサブシステムにキャッシュは含まれません。

SoC 内のメモリサブシステムが十分な帯域幅を備えていない場合、システム全体の性能が低下します。たとえば、 CPU が高周波数で動作し、レベル 2 キャッシュが適時送信できるデータ量よりも多くのデータをメモリからフェッチしようとする場合、 CPU はデータを受信するまで一時的にストール状態になります。このようなシステムでは、メモリサブシステムがボトルネックとなるため、より高いクロックスピードで CPU を実行するだけではシステムの性能は向上しません。図 3に、システム性能に影響を与えるその他の要素を示します。


図 2 : システム性能に最も重要な要素





通常、SoC はヘテロジニアスなシステムであり、多様なトラフィックを生成するブロックを含んでいます。これらのブロックはすべて、同じメモリリソースを求めて競合します。メモリサブシステムには、異なる回路ブロック間のリソース競合問題を解決し、異なるトラフィックを効率的かつ公平に処理する能力が必要です。したがって、 SoC 内 (特にメモリサブシステムとプログラマブルロジック ) のほかの要素を考慮せずに CPU のクロックレートを比較する評価方法は現実的ではなく、誤った診断を招く可能性があります。 Zynq-7000 AP SoC のさまざまなトラフィック例として、マスターと DDR間のトラフィックを次に示します。

• APU からのトラフィック (CPU からのメモリのロード /ストア命令、セントラル DMA からのダイレクトメモリアクセス (DMA) 要求)

• PS ペリフェラル (Ethernet、 USB など)

• PL からの DMA 要求

• PL ペリフェラル (IP およびアクセラレーター )。例 : ビデオパイプライン IP

メモリサブシステムは、このような異なるトラフィックソースからのアクセス要求を調停し、また DRAM の有効帯域幅を最大化する必要があります。効率的なメモリコントローラーは、このバランスを保ちながら予想どおりのビヘイビアーを継続します。メモリコントローラーの公平性は、 QoS (quality of service) メカニズムによって維持され、全体的なスループットを最適化しながら、各トラフィックがスタベーション状態になることを回避します。メモリサブシステムの偏ったインプリメンテーションは、無条件の調停プライオリティが原因であることが多く、このタイプの調停は、異なるソースからの複数データストリームを同時にサポートする必要がある SoC には不適切です。通常、いずれかのソースがスタベーション状態になると、システム全体のスピードが低下します。


図 3 : AP SoC システム性能のコンポーネント



性能解析用に構成されたデザイン


性能解析用に構成されたデザインZynq-7000 AP SoC を使用するシステムをモデル化するには、PL から PS へのトラフィックをエミュレートできるデザインが必要です。これには、コンフィギュレーション可能なザイリンクス IP を使用して、ユーザーデザインのさまざまな部分を模倣できます。デザインファイルのダウンロードは、「リファレンスデザイン」を参照してください。

1. C ドライブの「XAPP1219」という名前が付いたディレクトリにファイルを解凍します。

2. Vivado Design Suite 2014.3 を起動します。

a. Tcl ウィンドウを開きます。

b. デザインファイルを配置したディレクトリへ移動 (cd) します。

c. Source コマンドで project.tcl ファイルを実行します。

3. Vivado IP インテグレーターでブロック図を表示します。

a. [IP Integrator] → [Open Block Design] をクリックします。

4. [Generate Bitstream] をクリックします。必要に応じて使用できるように、生成済みのビットストリームを 1 つ提供しています。このビットストリームを使用する場合は、手順 6 から始めてください。

5. [Export Hardware] をクリックして、 [Include bitstream] をオンにします。

6. Vivado Design Suite から SDK コマンドを実行します。

また、すべてのアイテムを含むワークスペースも提供しています。 Vivado Design Suite を終了して SDK を起動する場合は、このワークスペースを選択してください。

このデザインは、 PL から PS DDR へのトラフィックを生成してアプリケーションをエミュレートします。このため、プログラムで AXI Traffic Generator (ATG) という IP コアを使用します。詳細は、『LogiCORE™ IP AXI Traffic Generator v2.0 製品ガイド』 (PG125) [参照 2] を参照してください。 ATG は、 Ethernet、 USB、 PCIe® などの標準インターフェイスを模倣できますが、ユーザーアプリケーションにより線密に適合するようにカスタマイズも可能です。このアプリケーションノートに付属するリファレンスデザインには、 6 つの ATG があり、それぞれ Zynq-7000 SoC の 4 つの HP (high-performance) ポート、 ACP (アクセラレーターコヒーレンシーポート )、および汎用 (GP) ポートに接続されています。これらはあらかじめ設定されていますが、モデル化するシステムに応じて変更できます。アプリケーションのモデル化におけるデザインの変更手順 (特に ATG 関連) については、「システム性能解析」を参照してください。図 4 に、デザインのブロック図を示します (Vivado Design Suite)。






図 4 : システム性能解析のブロック図





最上位図をシンプルにするため、 ATG は階層ブロックの中に配置されています。最上位には、 ATG、 Constant ブロック、および AXI Interconnect ブロックが 3 つ分かれるのではなく、1 つのブロック (TrafficGen ブロック ) の中に含まれています。図 5 のブロック図は、階層内の TrafficGen ブロックを示しています。Constant ブロックが ATG の実行を開始し、Interconnectブロックが ATG AXI4 を Zynq-7000 AP SoC AXI3 インターフェイスに切り換えます。

6 つの ATG はすべて同じように設定され、最上位のトラフィックプロファイルとデータのトラフィックプロファイルを設定します。データフローの設定は、読み出しと書き込みがそれぞれ 50% となり、インターバルは 50 サイクルで固定です。 1 つのトランザクションの開始から次のトランザクションの開始までの 50 サイクルが測定されます ( トランザクションの開始は、 AXI Interconnect ブロックのアドレスが現れる)。各 ATG は、 PS からの FCLK で動作し、 100MHz に設定されています。これによって、 HP ポートと ACP ポートのそれぞれのインターフェイスで 256MB/s の読み出しと書き込みが実行されます。GP ポートのデータ幅は 32 ビットであるため、生成されるトラフィックは、デザイン内のほかの ATG の半分となります。したがって、 GP ポートの読み出しと書き込みはそれぞれ 128MB/s となります。図 6 に、各 ATG の設定を示します。


図 5 : TrafficGen ブロック図






図 6 : AXI Traffic Generator の設定





式 1 に MB/s 単位のレート計算式を示し、式 2 に ATG の設定値を使用した計算式を示します。

式 1

説明

B = 1 ワードのバイト数N = TX のワード数I = インターバルf = PL クロック周波数 (MHz)

式 2

ATG を 50% の読み出しと 50% の書き込みとしてプログラムした場合、 AXI の書き込みチャネルに 256MB/s、 AXI の読み出しチャネルに 256MB/s が生じます。ATG は読み出しトランザクションと書き込みトランザクションを同時に実行するため、 AXI インターフェイスでは合計 512MB/s のトランザクションが生じます。したがって、この例の場合は、 HP ポートと ACP ポートのそれぞれで 512MB/s が生じます。表 1 に、各ポートのトラフィックおよび PS から PL へ転送される合計の MB/s を示します。 PS DDR の最大帯域幅を示し、 533MHz で動作する 32b DDR をベースとしています。

表 1 では、 PL からのトラフィック量が PS DDR の最大帯域幅の 60% であることを示しています。 PL から PS のインターフェイスでは、 DDR コントローラーが処理できる量よりも多くのトラフィックを生成できます。 ATG トラフィックを設定する際には、 PS DDR コントローラーの許容可能オーバーロードに留意してください。つまり、 ATG をいかなる設定にしても、 PS DDR の最大帯域幅を超えるトラフィックを生成することはできません。 PL が PS DDR の理論上最大帯域幅の80% を超えるかどうかを確認するには、このようなシンプルな表を作成する方法が有効です。これにより、性能が目標値に達しない問題、あるいはレイテンシが高いなどの問題を認識できます。

ここでは、システムをモデル化できるデザインを利用します。性能指標を満たしているかは、どのように確認したらよいのでしょうか。 HP および ACP ポートでは、実際に 256MB/s トラフィックが生成されているのでしょうか。これらのデータをデザインから取得するには、もう一つザイリンクス IP を使用する必要があります。AXI Performance Monitor (APM) を使用して、モデル化された各 AXI インターフェイスや HP、 ACP、および GP ポートからデータを収集します。図 7 に、APM の設定を示します。

表 1 : PS DDR の HP および ACP ポートの帯域幅

HP0 HP1 HP2 HP3 ACP GP1

読み出し 256 256 256 256 256 128

書き込み 256 256 256 256 256 128

ポートの合計 512 512 512 512 512 256

合計 2816

PS DDR の最大帯域幅 4264

PS DDR の最大帯域幅のパーセンテージ

66.04%

B N×1f--- I×------------------ Rate=

8 16×1

100---------- 50×------------------------------ 256=





APM は Profile モードで動作します。このモードは、 SDK 2014.1 またはそれ以降でサポートされています。その他のモードの詳細は、『LogiCORE IP AXI Performance Monitor v5.0 製品ガイド』 (PG037) [参照 3] を参照してください。

Profile モードの場合は、最上位の帯域幅とレイテンシを示します。 SDK は、各スロットまたはインターフェイスのデータを取得するため、 50ms ごとに APM の情報を読み出します。より詳しいインターフェイスデータを収集するには、その他のモードを使用します。 Advanced モードおよび Trace モードの場合は、 Profile モードよりも高いレートでデータを取得します。これらのモードは SDK でサポートされていないため、このアプリケーションノートでは説明しません。

図 7 に、 APM の設定を示します。 6 つのインターフェイスが選択されています。各モニターインターフェイスは、 AXI3(Zynq-7000 AP SoC) ポート、および 64 ビットのデータ幅として同じように設定されています。例外として、 GP ポートだけは 32 ビットデータ幅となります。図 7 に、最初の 4 つのモニターインターフェイスの設定を示します (これらは HPポートであり、 5 番目は ACP ポートで 6 番目は GP ポート )。 SDK の仕様に合わせて、最初の 5 つの APM ポートは、HP0 → slot 0、 HP1 → Slot 1、 HP2 → Slot 2、 HP3 → Slot 3、 ACP → Slot 4 のように接続する必要があります。このように設定しなければ、不正な結果が生じます。

Zynq-7000 AP SoC AXI ポートの設定は、図 8 に示します。この設定で、トラフィックジェネレーターを Zynq-7000 AP SoCの異なるインターフェイスに接続します。


図 7 : AXI Performance Monitor の設定





このデザインは、システムをモデル化して性能情報を収集するように構成された、いわゆるシステム性能解析用のデザインです。

Vivado ウィンドウの右側にある Flow Navigator で [Generate Bitstream] をクリックすると、ビットストリームを生成できます。この手順は、 ZIP ファイルに含まれるワークスペース内のビットストリームを使用することで省略できます。ビットストリームの生成方法を示す手順は、次のセクションで説明していますので、 Vivado IDE は起動させたままにしておいてください。

「はじめに」で示したとおり、システム性能に関する指標はもう一つあります。 PL でハードウェアをモデル化した場合、CPU の動作はどのように確認したらよいでしょうか。この場合、 Zynq-7000 アーキテクチャには PS 内にパフォーマンスモニタリングユニット (PMU) があり、動作中の ARM Cortex-A9 に関するデータを収集できます。また、 L2 キャッシュにはパフォーマンスカウンターがあり、それらのカウンター値を収集してユーザーに提示します。収集される指標は次のとおりです。

• CPU レベル 1 のキャッシュミス率

• CPU レベル 1 のキャッシュアクセス数

• 1 読み出し命令に対する CPU のストールサイクル

• 1 書き込み命令に対する CPU のストールサイクル

CPU で動作するソフトウェアの指標とモデル化されたハードウェアを使用して、設計を開始する前にシステム性能を解析できます。


図 8 : Zynq AXI ポートの設定



システム性能解析


システム性能解析次の手順では、モデルを実行して、さまざまな解析ポイントで何が生じているかを示します。性能指標を確認するには、SDK でこのデザインを実行する必要があります。最初の実行は、ソフトウェアを使用せずに行います。この場合、 PS メモリコントローラーのみを介した場合の、 HP ポートおよび GP ポートから DDR への性能を示します。

ビットストリームを生成しない場合は、SDK を起動して Workspace ディレクトリ (ZIP ファイルに含まれる ) を使用して、SDK 内でワークスペースを選択できます。その場合は、図 11 に示す画面からのスタートとなるため、 14 ページの手順 4までスキップしてください。

システム解析の設定手順は次のとおりです。

1. Vivado IDE の [File] メニューから、[Export] → [Export Hardware] をクリックして、SDK 用にハードウェアをエクスポートします。次に、 [File] → [Launch SDK] をクリックして、エクスポートしたハードウェア定義を使用して SDK を起動します。図 9 に示す SDK ウィンドウで、 [File] → [Import] → [General] → [Existing Projects into Workspace] をクリックして [Next] をクリックします。


図 9 : インポートしたハードウェアを示す SDK 画面





2. ZIP ファイルの中にあるルートディレクトリをワークスペースとして選択します。図 10 に示すように、 2 つのチェックボックス ([perfmon] および [standalone_bsp_0]) をオンにします。


図 10 : SDK でプロジェクトをワークスペースにインポート





3. [Finish] をクリックします。図 11 に、インポートされた SDK プロジェクトを示します。

4. ユーザーのコンピューターが 2 つの USB コネクタを使用して ZC702 評価ボードへ接続されていることを確認します。1 つはプログラミングケーブルへ接続し、もう一つは UART へ接続することによって、端末で出力を確認できます。

5. ZC702 ボード上では、電源スイッチを ON にして、デバイスをプログラム可能にします。

6. Terminal 1 を接続して、 C プログラムからの出力を表示します。端末の接続手順は次のとおりです。

a. SDK ウィンドウ下部にある Terminal 1 タブ (図 11 には [Term] と表示) を開きます。

b. 3 つ目のボタンをクリックします (テーブルのようなもの)。これが設定タブです。


図 11 : SDL プロジェクトワークスペース





c. 図 12 のように設定を変更します。 COM3 は、ユーザーマシンによって異なる COM# になる場合があるので注意が必要です。


図 12 : UART Terminal 0 の設定





PL のプログラム手順は次のとおりです。

1. ザイリンクスツールの中にある FPGA プログラムコマンドを使用します。 SDK でビットストリーム(pretest_wrapper.bit) が自動的に選択されます。その画面で [Program] をクリックします。

2. DONE を示す LED (DS3) が High になった後、図 13 に示すように、 [Run] → [Debug Configurations] をクリックして新しいデバッグコンフィギュレーションを作成し、 [Xilinx C/C++ Application (System Debugger)] をクリックします。

3. 新しいウィンドウで、 [Debug Type] を [Standalone Application Debug] に変更します。


図 13 : [Debug Configurations] の設定





4. [Name] を perf_mon に変更します。設定されたウィンドウは図 14 のようになります。


図 14 : デバッグコンフィギュレーションのスタンドアロンアプリケーションの設定





5. [Application] タブへ移動して、 [Download Application] をオンにします。 [Project Name] および [Application] は、図 15 に示すように自動的に入力されます。

6. [Stop at program entry] をオンにします。これによって、自動的にブレークポイントを挿入する機能がプログラムに備わり、ユーザーが SDK に指示するとプログラムが開始します。


図 15 : デバッグコンフィギュレーションのソフトウェアダウンロード追加





7. 次に、 [Debug] をクリックしてデバッグセッションを開始します。 [Confirm Perspective Switch] ダイアログボックスが表示されます。そのダイアログボックスで [Yes] をクリックします。 SDK セッション画面は図 16 のようになります。

8. [Target Connection] および [SD log] タブを閉じます。

9. [Terminal 1] タブを選択すると、プログラムの出力内容を確認できます。


図 16 : デバッグパースペクティブ





10. スタートボタン (図 17 の赤枠部分) をクリックします。

この動作で hello_world のコードが実行され、 ATG に接続されたポートのトランザクション数が提示されます。その後、プログラムが MB/s を素早く計算して表示します。 SDK セッション画面は図 17 のようになります。

端末に表示された結果は、 HP ポートと ACP ポートがすべて 256MB/s で GP ポートは 128MB/s になる必要があります。これは、 C コードを使用して APM からデータを抽出する方法ですが、 SDK の現バージョンには、 HP0 ～ 3 および ACP の性能データを自動で提示する新機能があります。


図 17 : Terminal 1 に表示されたデバッグパースペクティブの結果





GP ポートのみを読み出すように変更した perf_mon があります。これを使用して、 GP ポートを読み出すことができます。手順は次のとおりです。

1. SDK で新規の性能解析パースペクティブ (Performance Analysis Perspective) を開始するため、 [Window] →[ClosePerspective] をクリックして、既存のデバッグパースペクティブを閉じます。

2. 性能解析パースペクティブを実行するため、前回の perf_mon の実行と同様に [Run] → [Debug configurations] をクリックします。

3. 今回は、図 18 のように [Performance Analysis] をクリックします。

4. コンフィギュレーション名を「Performance」に変更します。今回は、 SDK が自動的に APM を読み出すため、ユーザーがアプリケーションに読み出しを実行させる必要はありません。


図 18 : デバッグコンフィギュレーションのスタンドアロンアプリケーションの設定





5. [Debug] をクリックし、[Yes] をクリックしてパースペクティブを切り換えます。出力結果は、図 19 のようになります。

これらの結果は、 APM を読み出したものと同じですが、 SDK は APM だけでなく、 PS の PMU も読み出して APU またはAPM に関するデータを提供するため、データ量は多少増加します。 [PL Performance] および [PS Performance] の表は、サマリのテーブルをグラフ化したものです。サマリは瞬間的に捉えたスナップショットを表し、グラフは長期的なデータを表します。 MicroBlaze™ プロセッサのタブに関しては、このアプリケーションノートの範疇ではないため閉じても構いません。

これで、性能を示すデータが揃いましたが、これらは何を表しているのでしょうか。最初の手順として、それぞれの値が示す意味を理解していきます。その後、高度な手順として、これらのデータを解析して、目標の性能に到達しているかを判断します。

まず、 [APU Performance Summary] タブを開きます。このタブには、 PMU カウンターと APM の指標が一覧表示されています。 1 つ目のテーブルは、 PMU カウンターからの値で、各 Cortex-A9 プロセッサの指標を示しています。各プロセッサのレベル 1 (L1) キャッシュ、そして 2 つの Cortex-A9 コアで共有される統合されたキャッシュのレベル 2 (L2) キャッシュに対応しています。 PS 性能の指標は次のとおりです。

• CPU Utilization (%) : 非アイドル状態での CPU クロックサイクル率を示す。

• CPU Instructions Per Cycle (IPC) : 1 サイクルに実行された命令数を示す。

• L1 Data Cache Miss Rate (%) : L1 データキャッシュに対してアクセスした数およびミス率を示す。

• CPU Write/Read Stall Cycles Per Instruction : メモリの書き込み (write) およびデータキャッシュのリフィル (read) 動作が原因となる、 1 命令に対するストールサイクル数を示す。


図 19 : パフォーマンスパースペクティブ





APM の指標は、次のように定義されています。

• Read/Write Transactions

ATG で生成される読み出し /書き込みトランザクションの数を示しています。一般的に ATG はトランザクションを多数生成するため、この値は大きくなります。

• Read/Write Latency - Average

トランザクションのレイテンシを示しています。コマンドを受信してからバーストの最後のワードが送信されるまでの期間が測定されます。

レイテンシは上記のように測定されるため、書き込みの受信と同時に書き込み動作が測定され、レイテンシが低くなります。したがって、システムにバックプレッシャーがない場合、この値はバーストサイズよりもわずかに上回る程度となります。これを使用して、書き込みトランザクションに対してバックプレッシャーが動作するタイミングを示すことができます。ユーザーは、このようにして、書き込みがスレーブでストールするタイミングを認識できます。書き込みレイテンシがバースト長よりも大きく上回ると、これらのトランザクションがスレーブでストールします (デザイン内の PS)。

• Read/Write Latency - Std.Dev.

レイテンシ測定値の標準偏差を示しています。

• Read/Write Throughput (MB/s)

トランザクション数、トランザクションサイズ、およびインターフェイススピードに基づいて、インターフェイスのスループットが計算されています。

全体的な PL 性能を見てみましょう。ボードの電源投入で ATG が動作しています。コアの実行開始に伴って一定値 (ロジック 1) が保持されているため、 ATG は Zynq-7000 AP SoC がリセットから回復すると実行します。また ATG は、一定数のトラフィックを生成するように設定されているため、図 20 のようにトラフィックはグラフ上で一本の線として現れます。 +印が付いたオレンジ色のボックスは、グラフの拡大/縮小機能です。図 20 に、このボックスを丸で囲んでいます。





このタブの上部には、オレンジ色の + の拡大部分を示します。グラフ内の任意の部分をクリックして、ズームボックスを配置できます。拡大表示したい部分にズームボックスをクリックしてドラッグします。 CTRL キーを押しながらマウスをスクロールして、ズームエリアを拡大/縮小することも可能です。

[PS Performance] タブは、 [PL Performance] と類似していますが、 PMU カウンターをグラフ化したものであり、 APM から取得したデータではありません。それぞれの値が示す意味を理解することで、これらがデザイン要件を満たしているかを判断できます。結果は、アプリケーションによって異なります。まず最初に、任意のトラフィックで ATG が設定されていることを確認します。ソフトウェアを動作させた状態で、帯域幅とレイテンシがアプリケーションの要件を満たしている場合は、これで終了ですが、性能に関する要件が満たされていない場合は、何をすべきでしょうか。

この問題は、簡単には解決できません。通常、性能を向上させるパラメーターは 1 つだけではありません。いくつかの要素を確認する必要があります。すでに言及したとおり、 PS-PL 間を往来するトラフィック量を確認します。 PS DDR の理論上の最大帯域幅の 80% を使用している場合は、これが問題となる可能性があります。もう一つの要素として、すべてのトラフィックが 1 つまたは 2 つの HP ポート上に集中しているかを確認します。そのような場合は、これらのトラフィックを複数ポートに分散可能であるかを考えます。ピークトラフィック用にシステムがモデル化されていませんか。 10% ～50% 程度しか生じないにもかかわらず、 100% のピークトラフィックを達成しようとしていませんか。

Zynq-7000 AP SoC で性能を調整する作業は非常に複雑です。このアプリケーションノートでは言及していませんが、デザインのフローや性能要件が異なるため、特定アプリケーションの設定がほかのアプリケーションに必ずしも有効とは限りません。詳細は、『SDK ユーザーガイド : システム性能解析』 (UG1145) [参照 1] および『UltraFast エンベデッドデザイン設計手法ガイド』 (UG1046) [参照 4] を参照してください。


図 20 : [Performance Analysis] の [PL Performance] タブ



モデルへの変更および追加


注記 : SDK 2014.3 には、次の制約事項があります。

° ハードウェアデザインには、 AXI Performance Unit が 1 つ含まれる必要があり、 0 から 5 までのスロットは、順にHP0、 HP1、 HP2、 HP3、 HP4、 ACP ポートへ接続します。

° APM カウンターが読み出されると、すべてのプロファイルカウンターがリセットされます。このため、 2 つのエンティティが APM を読み出すと、結果が不正になります。可能な限り、 SDK または perf_mon C コードを使用して、帯域幅を読み出しおよび表示させます。推奨方法は SDK です。 perf_mon コードは、必要に応じて GP ポートを読み出す際に使用します。

モデルへの変更および追加このモデルを使用してユーザーアプリケーションをより厳密に模倣する方法は 2 つあります。 1 つ目は、ソフトウェアを追加する方法です。 2 つ目は、ハードウェアモデルを変更して、ユーザーアプリケーションのデータフローを模倣する方法です。前のセクションでは、モデルに複数のソフトウェアを追加しました。ソフトウェアを追加する際、 SDK でhello_world コードを独自のものに置き換えることができます。 GP ポートの APM を読み出すために hello_world のコードが重要な場合は、独自コードに統合できます。 SDK の詳細は、『Zynq-7000 All Programmable SoC ソフトウェア開発者向けガイド』 (UG821) [参照 5] または『Zynq-7000 All Programmable SoC : コンセプト、ツール、テクニックガイド : 効率的なエンベデッドシステム構築をサポートするハンディガイド』 (UG873) [参照 6] の「Zynq プロセッシングシステムを使用するエンベデッドシステムデザイン」を参照してください。また、その他の参考資料およびビデオは、Document Navigatorのデザインハブから入手できます。

1. [Import] ウィンドウで [C/C++] をクリックして、 C コードを含むディレクトリを選択します。図 21 および図 22 に、 Cまたは C++ コードをインポートするウィンドウを示します。


図 21 : 既存の C コードを SDK にインポート






図 22 : 既存コードのインポート





2. 新規のパフォーマンスパースペクティブを作成します (図 23)。

SDK およびソフトウェアデバッグに関するその他の資料は、「参考資料」を参照してください。

2 つ目は、ハードウェアモデルを変更する方法です。この方法には、次の 4 つの手法があります。

• さらに ATG を追加する

• ATG を独自の IP で置き換える

• 既存 ATG のトラフィックフローを変更する

• APM を追加した独自の IPI デザインを追加する

ハードウェアデザインは、このアプリケーションノートの一部であり、これらの変更および追加が可能です。

このデザインで ATG の追加はサポートされていません。 ATG を PS へ接続するために残されたポートは GP ポートのみです。追加する場合は、このデザインの ATG と GP0 の接続方法を真似て、 GP1 への別の TrafficGen 接続を行うことで実現できます。その後、 TrafficGen が GP0 へ接続される方法と同じようにして、各信号を所定の場所へ接続します。

ATG を独自の IP に置き換える方法は、多くの時間を要する上に Vivado IP インテグレーターの知識も必要です。この方法については、アプリケーションノートの後半で説明しています。確認すべき最も重要な事は、コアが AXI3 または AXI4メモリマップドインターフェイスを備えていることです。 AXI4 の場合は、 PS へ接続するために TrafficGen ブロックで使用されるようなインターコネクトが必要です。

ATG コンフィギュレーションのフローを変更して、より厳密にアプリケーションデータフローを模倣する方法について説明します。 ATG コンフィギュレーションを変更する手順は次のとおりです。

1. アプリケーションノートの最初に作成したデザインを Vivado IDE で開きます ( 「性能解析用に構成されたデザイン」参照)。


図 23 : 新しいコンフィギュレーション





2. 任意の TrafficGen モデルをダブルクリックして階層内に入ります。

TrafficGen ブロックには 0 ～ 5 までの番号が付いています。最初の 4 つ (TrafficGen0 ～ 3) は、 HP0 ～ 3 に接続されており、 TrafficGen4 は ACP、 TrafficGen5 は S_AXI_GP0 に接続されています。

3. 階層内に入った後、図の中の axi_traffic_gen_0 をダブルクリックします。図 24 のような ATG のコンフィギュレーション画面が表示されます。

まず最初に、プロファイルを変更します。カスタムモードでは、 Zynq-7000 プラットフォームの Cortex-A9 あるいは PL のその他の CPU (MicroBlaze プロセッサなど) を使用して ATG をプログラムできます。詳細は、『LogiCORE IP AXI TrafficGenerator v2.0 製品ガイド』 (PG125) [参照 2] の ATG に関する説明を参照してください。ドライバーソフトウェアは、C:\Xilinx\SDK\2014.3\data\embeddedsw\XilinxProcessorIPLib\drivers\trafgen_v3_2\doc\html\ap

i\index.html にあります。トラフィックの動的制御を実装する場合は、このモードを使用しますが、このアプリケーションノートでは説明していません。

次に、トラフィックプロファイルを設定します。便宜上、 4 つのプロファイル (Video、 PCIe、 Ethernet、 USB) があらかじめ定義されています。これらのプロファイルの詳細は、『LogiCORE IP AXI Traffic Generator v2.0 製品ガイド』 [参照 2] を参


図 24 : ATG コンフィギュレーションの変更



まとめ


照してください。これらの各モードを使用して、インターフェイスや生成するトラフィックに関するさまざまな項目を選択できます。あらかじめ定義されているすべてのモードが、モデル化するトラフィックの要件を満たさない場合は、 Dataモードを使用します。例では、このモードを使用しています。ユーザーは、次の項目を変更できます。

• AXI オプション : 生成されるトランザクションのデータ幅、ベースアドレス、高位アドレス。これらは、 Zynq-7000AP SoC の DDR 用に設定されます。 1 つの設定を変更すると、オンチップメモリ (OCM) のこれらの設定が変更される場合があります。

• Data モード :

° パターン (固定またはランダムサイズ)、ランダムサイズの最小/最大転送サイズ、固定サイズの転送長。

° トランザクションタイプ。 ATG の読み出し、書き込み、読み出し /書き込み、およびそれらのパーセンテージ。

° 例で使用される設定は、固定の 16 ワードバースト、 50% の読み出しと 50% の書き込み。

° トランザクション間のインターバル (固定またはランダム)。インターバルの設定は 50 サイクルで、 ATG 用のクロックサイクル。例では 100MHz クロックを使用。

° トランザクションアドレッシング。固定のみ。これは、アドレスがインクリメントまたはランダムのいずれかに制限される。

このデザインを使用して ATG を変更することで、 Zynq-7000 AP SoC 用のアプリケーションモデルを作成できます。

注記 : システムに過度の付加が与えられると、性能可視化 (Performance Visualization) の結果が不正になります。たとえば、最初のセクションで示したリファレンスデザインで、各 ATG のインターバルを 30 サイクル未満に設定します。その結果、生成されるトラフィックは、各 AXI インターフェイスで 844MB/s、合計すると 4,220MB/s になります。これは 533MHz で100% の DDR 使用率となり、(すべてとは言わないが) ほとんどの DDR コントローラーでは達成不可能です。Zynq-7000 APSoC の付加に関する詳細は、『SDK ユーザーガイド : システム性能解析』 (UG1145) [参照 1] を参照してください。

もう一つ有効な方法として、 ATG を既存 IP で置き換える方法があります (この場合、 Vivado ツールにすでにインポートされている必要がある )。 IP を追加する場合は、 ATG を削除してから独自 IP を追加します。この作業には、 Vivado アーキテクチャおよび IP インテグレーターに関する実用的な知識が必要です。 Vivado アーキテクチャおよび IP インテグレーターに精通していない方は、『Vivado Design Suite チュートリアル : IP を使用した設計』 (UG939) [参照 7] および『Vivado DesignSuite ユーザーガイド : IP を使用した設計』 (UG896) [参照 8] を参照してください。 Vivado 2014.2 の Document Navigator からアクセス可能なデザインハブ [参照 9] では、役に立つさまざまな資料およびビデオを提供しています。

まとめこのアプリケーションノートでは、 All Programmable SoC の性能解析について包括的な説明をしています。このように性能を解析することで、デバイスが性能要件を満たすことが可能であるかを判断できます。 CPU のスピードを着目するだけなら簡単なのですが、メモリコントローラーの効率が悪ければ、 CPU 動作は低速化します。

ここでは、 Zynq-7000 AP SoC をベースとするアプリケーションのモデル化に利用できるリファレンスデザインを提供し、これらを使用して実際に達成可能な性能を示します。このモデルは、ユーザーが独自のソフトウェアと組み合わせ可能な実際のハードウェア内のデザインを採用しています。これによって、ユーザーのアプリケーションをモデル化して、早期の設計段階で性能を評価できます。

このモデルの ATG を変更、あるいは独自 IP に置き換えることで、アプリケーションを厳密にモデル化できます。これにより、 Zynq-7000 デバイスで達成できること、できないことをより詳しく解析できます。

SDK の機能と性能解析用の IP を組み合わせて使用することで、 Zynq-7000 AP SoC がユーザーアプリケーションの性能要件を満たすかどうかを確実に評価できます。

リファレンスデザインこのアプリケーションノートのリファレンスデザインは、ザイリンクスのウェブサイトからダウンロードできます。

表 2 に、リファレンスデザインの詳細を示します。

https://secure.xilinx.com/webreg/clickthrough.do?cid=370682



参考資料


参考資料1. 『SDK ユーザーガイド : システム性能解析』 (UG1145)

2. 『LogiCORE IP AXI Traffic Generator v2.0 製品ガイド』 (PG125)

3. 『LogiCORE IP AXI Performance Monitor v5.0 製品ガイド』 (PG037)

4. 『UltraFast エンベデッドデザイン設計手法ガイド』 (UG1046)

5. 『Zynq-7000 All Programmable SoC ソフトウェア開発者向けガイド』 (UG821)

6. 『Zynq-7000 All Programmable SoC : コンセプト、ツール、テクニックガイド : 効率的なエンベデッドシステム構築をサポートするハンディガイド』 (UG873)

7. 『Vivado Design Suite チュートリアル : IP を使用した設計』 (UG939)

8. 『Vivado Design Suite ユーザーガイド : IP を使用した設計』 (UG896)

9. Vivado 2014.2 - Document Navigator のデザインハブ (Document Navigator は Vivado Design Suite からアクセス可能)

10. 『AXI リファレンスガイド』 (UG761)

表 2 : リファレンスデザインの詳細

パラメーター説明

全般

開発者 Forrest Pickett

デバイス番号 XC7Z020

ソースコードの提供あり

ソースコードの形式 (提供される場合) C

既存リファレンスデザインから使用した IP AXI Traffic Generator

AXI Performance Monitor

シミュレーション

論理シミュレーションの実施 N/A

タイミングシミュレーションの実施 N/A

論理シミュレーションおよびタイミングシミュレーション用テストベンチの提供

N/A

テストベンチの形式 N/A

使用したシミュレータ /バージョン N/A

SPICE/IBIS シミュレーションの実施 N/A

使用したインプリメンテーションツール/バージョンザイリンクス SDK (2014.3)

スタティックタイミング解析の実施 N/A

ハードウェア検証

ハードウェア検証の実施 N/A

使用したプラットフォーム Vivado Design Suite 2014.3

http://japan.xilinx.com/cgi-bin/docs/ipdoc?c=AXI%20Traffic%20Generator

http://japan.xilinx.com/cgi-bin/docs/ipdoc?c=AXI%20Performance%20Monitor

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=2014.4;d=ug1145-sdk-system-performance.pdf

http://japan.xilinx.com/support/documentation/sw_manuals_j/ug1046-ultrafast-design-methodology-guide.pdf

http://japan.xilinx.com/cgi-bin/docs/ndoc?v=zynq-7000;t=user+guide

http://japan.xilinx.com/support/documentation/sw_manuals_j/xilinx14_7/ug873-zynq-ctt.pdf#page=12

http://japan.xilinx.com/support/documentation/sw_manuals_j/xilinx2014_2/ug939-vivado-designing-with-ip-tutorial.pdf

http://japan.xilinx.com/support/documentation/sw_manuals_j/xilinx2014_2/ug896-vivado-ip.pdf

http://japan.xilinx.com/support/documentation/ip_documentation/ug761_axi_reference_guide.pdf



改訂履歴


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

法的通知The information disclosed to you hereunder (the “Materials”) is provided solely for the selection and use of Xilinx products.To the maximum extentpermitted by applicable law:(1) Materials are made available "AS IS" and with all faults, Xilinx hereby DISCLAIMS ALL WARRANTIES ANDCONDITIONS, EXPRESS, IMPLIED, OR STATUTORY, INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY,NON-INFRINGEMENT, OR FITNESS FOR ANY PARTICULAR PURPOSE; and (2) Xilinx shall not be liable (whether in contract or tort, includingnegligence, or under any other theory of liability) for any loss or damage of any kind or nature related to, arising under, or in connection with, theMaterials (including your use of the Materials), including for any direct, indirect, special, incidental, or consequential loss or damage (including loss ofdata, profits, goodwill, or any type of loss or damage suffered as a result of any action brought by a third party) even if such damage or loss was reasonablyforeseeable or Xilinx had been advised of the possibility of the same.Xilinx assumes no obligation to correct any errors contained in the Materials or tonotify you of updates to the Materials or to product specifications.You may not reproduce, modify, distribute, or publicly display the Materials withoutprior written consent.Certain products are subject to the terms and conditions of Xilinx’s limited warranty, please refer to Xilinx’s Terms of Sale whichcan be viewed at http://www.xilinx.com/legal.htm#tos; IP cores may be subject to warranty and support terms contained in a license issued to you byXilinx.Xilinx products are not designed or intended to be fail-safe or for use in any application requiring fail-safe performance; you assume sole risk andliability for use of Xilinx products in such critical applications, please refer to Xilinx’s Terms of Sale which can be viewed athttp://www.xilinx.com/legal.htm#tos.

Automotive Applications DisclaimerXILINX PRODUCTS ARE NOT DESIGNED OR INTENDED TO BE FAIL-SAFE, OR FOR USE IN ANY APPLICATION REQUIRING FAIL-SAFEPERFORMANCE, SUCH AS APPLICATIONS RELATED TO:(I) THE DEPLOYMENT OF AIRBAGS, (II) CONTROL OF A VEHICLE, UNLESSTHERE IS A FAIL-SAFE OR REDUNDANCY FEATURE (WHICH DOES NOT INCLUDE USE OF SOFTWARE IN THE XILINX DEVICE TOIMPLEMENT THE REDUNDANCY) AND A WARNING SIGNAL UPON FAILURE TO THE OPERATOR, OR (III) USES THAT COULD LEADTO DEATH OR PERSONAL INJURY.CUSTOMER ASSUMES THE SOLE RISK AND LIABILITY OF ANY USE OF XILINX PRODUCTS INSUCH APPLICATIONS.

© Copyright 2014 Xilinx, Inc. Xilinx, the Xilinx logo, Artix, ISE, Kintex, Spartan, Virtex, Vivado, Zynq, and other designated brands included herein aretrademarks of Xilinx in the United States and other countries.Cortex is a trademark of ARM in the EU and other countries.PCI, PCIe, and PCI Expressare trademarks of PCI-SIG and used under license.All other trademarks are the property of their respective owners.

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

にある [フィードバック送信] ボタンをクリックすると表示されるフォームからお知らせください。いただきましたご意見を参考に早急に

対応させていただきます。なお、このメールアドレスへのお問い合わせは受け付けておりません。あらかじめご了承ください。

日付バージョン内容

2014 年 12 月 11 日 1.0 初版

mailto:[email protected]

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

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



all programmable soc のシステム性能解析 -...

Documents