UltraFast エンベデッドデザイン設計手法ガイド - Xilinx...UltraFast エンベデッドデザイン設計手法ガイド UG1046 (v2.3) 2018 年 4 月 20 日...

UltraFast エンベデッドデザイン設計手法ガイド

UG1046 (v2.3) 2018 年 4 月 20 日

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

UltraFast エンベデッドデザイン設計手法ガイド 2UG1046 (v2.3) 2018 年 4 月 20 日 japan.xilinx.com

改訂履歴

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

日付バージョン改訂内容

2018 年 4 月 20 日 2.3 • 第 5 章の「概要」に注記を追加。

• ガイド全体で「BFM」を「VIP」に置換。

2017 年 7 月 27 日 2.2 • Vivado IDE をアップデートおよび編集上の変更を追加。

2015 年 4 月 22 日 2.1 • 「エンベデッド設計手法チェックリスト」を追加。

• 「資料およびトレーニングへのアクセス」を追加。

2015 年 3 月 26 日 2.0 • 「SDSoC 環境」を追加。

• 「関連するデザインハブ」を追加。

2014 年 10 月 20 日 1.1 • 古い情報を削除。

• 「システムレベルの考慮事項」の次のセクションに情報を追加:

° 「パフォーマンス」

° 「クロッキングおよびリセット」

2014 年 10 月 8 日 1.0 初版。

https://japan.xilinx.comhttps://japan.xilinx.com/about/feedback.html?docType=Methodology_Guides&docId=UG1046&Title=UltraFast%20%26%2312456%3B%26%2312531%3B%26%2312505%3B%26%2312487%3B%26%2312483%3B%26%2312489%3B%20%26%2312487%3B%26%2312470%3B%26%2312452%3B%26%2312531%3B%26%2335373%3B%26%2335336%3B%26%2325163%3B%26%2327861%3B%26%2312460%3B%26%2312452%3B%26%2312489%3B&releaseVersion=2.3&docPage=2

目次

第 1 章: 概要エンベデッド設計手法チェックリスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7資料およびトレーニングへのアクセス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

第 2 章: システムレベルの考慮事項パフォーマンス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11消費電力 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15クロッキングおよびリセット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33割り込み . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37エンベデッドデバイスのセキュリティ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41プロファイリングおよび分割 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

第 3 章: ハードウェアデザインの考慮事項ブートデバイスおよびそのコンフィギュレーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57メモリインターフェイス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63ペリフェラル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69IP ブロックの設計 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86ハードウェアパフォーマンスの考慮事項 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94データフロー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99PL クロック供給手法. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103ACP およびキャッシュコヒーレンシ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107PL の HP ポートアクセス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110システム管理のハードウェアアシスタンス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114ハードウェアリコンフィギュレーションの管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117APU からの GP およびダイレクト PL アクセス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

第 4 章: ソフトウェアデザインの考慮事項プロセッサの設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127OS および RTOS の選択 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132ライブラリおよびミドルウェア . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141ブートローダー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145ソフトウェア開発ツール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

第 5 章: ハードウェアデザインフロー概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160Vivado IDE を使用した IP サブシステムの構築 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160ルールベースの接続 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161階層的な IP サブシステムの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162[Board] ウィンドウ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162ブロックデザインの生成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162再利用のための IP の作成とパッケージ化. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163



カスタムインターフェイスの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164カスタム IP の管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164Vivado 高位合成 (HLS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

第 6 章: ソフトウェアデザインフローボード立ち上げ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168ドライバーの開発 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171アプリケーション開発 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179ザイリンクス SDK ツールおよびパッケージ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185ザイリンクスソフトウェア開発ツール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

第 7 章: デバッグ概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190ソフトウェアのみのデバッグ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192シミュレーションベースのデバッグ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196ボードのデバッグ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197ハードウェアとソフトウェアの協調デバッグ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198仮想プラットフォーム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

第 8 章: SDSoC 環境概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202全体的な使用フロー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204プロファイリング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206パフォーマンス見積もり . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206ソフトウェア/ハードウェアシステム全体の作成と実行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207C 言語から呼び出し可能な RTL IP ライブラリを使用したパフォーマンスの最適化 . . . . . . . . . . . . . . . . . . . . . . . 207Vivado HLS を使用した IP パフォーマンスの最適化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207システムパフォーマンスの最適化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208システムのデバッグ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209パフォーマンスの測定と解析 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210エクスパート向けの使用モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

付録 A: その他のリソースおよび法的通知ザイリンクスリソース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212ソリューションセンター . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212Documentation Navigator およびデザインハブ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212Xilinx Documentation Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213参考資料 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213トレーニングリソース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217お読みください: 重要な法的通知 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218



第 1 章

概要SoC 製品のリリースに伴い、ザイリンクスでは、さらに高度なシステムを短期間で、効率的に、確実に構築するための効果的な方法を提供しています。システムが高度になるほど、通常複雑性も増します。これには、長所もあれ

ば短所もあります。以前は構築するのが不可能であったり、非常に困難であった製品を作成できるようになったこ

とは長所ですが、製品の複雑性が増したことにより、特に製品のライフサイクルの早期に設計に関する適切な決定を下すことがさらに重要となります。システムソフトウェア、アプリケーション、およびハードウェアは互いに影響し合うので、システムレベルの問題を考慮して解決するためには、新しい手法が必要です。ザイリンクスでは、この課題に対処するため、ソフトウェアツール、ユーザーガイド、リファレンスマニュアル、リファレンスデザインなどを含む包括的なツールボックを提供しており、これを使用することにより SoC を使用した製品の開発期間を短縮できます。

通常、エンベデッド開発チームにはシステム構築者、ソフトウェアエンジニア、およびハードウェアエンジニアが含まれ、それぞれのチームメンバーが使い慣れたツールで設計を開始します。この方法は従来のエンベデッド開発プロジェクトでは問題ありませんでしたが、 SoC のボード機能を使用する場合は、開発方法を前もって考慮しておかないと、問題となる可能性があります。この資料は、開発チームがより効率的にデザインの開発を進められるよ

うにエンベデッドシステム開発者向けに記述されており、主に FPGA 設計者向けの『UltraFast 設計手法ガイド (Vivado Design Suite 用)』 (UG949) [参照 16] を補足するために提供されています。

「手法」の意味は人によって異なりますが、通常はフローチャート、方法、原則、規則、方針などを意味します。この資料は、手順を 1 つずつ示すものではなく、設計者がザイリンクスツールボックスを使用してデザインに関する適切な決定を下すことができるように、エンベデッドシステムを設計するための情報およびガイダンスを示すためのものです。内容によっては、エンベデッドシステム全般に適用されるものもあれば、ザイリンクスの SoC 製品にしか適用されないものもあります。内容は、ユーザーの経験やザイリンクス内外のシステム開発から学んだことを

反映しており、主な原則や、実行すべきことおよび実行すべきでないこと、ベストプラクティス、危険な状況の回避方法などについて記述しています。トピックによっては、概念を示すユースケースも示されています。

この資料は、開発チーム内の役割に応じた次の機能分野別に構成されています。

• 「システムレベルの考慮事項」

• 「ハードウェアデザインの考慮事項」

• 「ソフトウェアデザインの考慮事項」

• 「ハードウェアデザインフロー」

• 「ソフトウェアデザインフロー」

• 「デバッグ」

• 「SDSoC 環境」



第 1 章: 概要

表 1-1 にチームメンバーの各役割に関連する章を示しますが、開発を始める前にチームメンバー全員がこの資料全体を読んでおくことをお勧めします。章の内容が担当している部分のものでなくても、それらに示される課題やガ

イダンスを理解しておくことで役立つことがあります。ソフトウェアエンジニアとハードウェアエンジニアの境はあいまいになってきており、お互いの分野を超えて理解しておくことで、チーム全体が効率的に機能するようにな

ります。たとえば、ソフトウェアエンジニアは使用されるハードウェアがどのように動作するのかを理解しておく必要がありますし、ハードウェアエンジニアはハードウェアに関する決定事項がソフトウェアにどのように影響するかを理解しておく必要があります。

通常エンベデッドデザインは、この資料に示されている順に、システムレベルデザインから開始してテストとデバッグで終わりますが、どの章から読み始めても問題ありません。図 1-1 は、この資料の章の関係を示しています。

注記: 「SDSoC 環境」は図 1-1 には含まれていません。このツールは、第 2 章から第 7 章までの概念および手法のすべてを使用してシステムを構築するのに使用します。第 8 章では、 SDSoC フロー特有の推奨事項も説明しています。

この資料を読むと、ザイリンクスから提供されるさまざまなツールおよびそれに付属するものをより詳細に効率的

な方法で学ぶことができます。各トピック分野で学んだ主要な事項は、 SoC の資料を理解するのにも役立ちます。

表 1-1: 各設計チームメンバーに関連する章

章システム構築者ハードウェア設計者ソフトウェア設計者

「システムレベルの考慮事項」 X X X

「ハードウェアデザインの考慮事項」 X X

「ソフトウェアデザインの考慮事項」 X X

「ハードウェアデザインフロー」 X

「ソフトウェアデザインフロー」 X

「デバッグ」 X X

「SDSoC 環境」 X

X-Ref Target - Figure 1-1

図 1-1: 設計手法ガイドの章の関係



第 1 章: 概要

『Zynq-7000 SoC テクニカルリファレンスマニュアル』 (UG585) [参照 4] および『Zynq-7000 SoC ソフトウェア開発者向けガイド』 (UG821) [参照 7] に精通している場合は、まずこの資料を読むことをお勧めします。

Zynq®-7000 SoC アーキテクチャについてよく知らない場合は、『Zynq-7000 SoC 概要』 (DS190) [参照 31] を参照してください。この資料を読むことで、エンベデッドデザインチームがトレードオフを理解してボトルネックや問題を回避できるようになり、エンベデッドシステム開発に最適な決定を下すことができるようになります。

エンベデッド設計手法チェックリスト

この資料は、 UltraFast エンベデッド設計手法チェックリストと合わせて使用することをお勧めします。チェックリストには、プラニングからその後に続くすべての段階のデザインプロセスに関するよくある質問や推奨される操作が記載されています。チェックリストの質問は、後の段階に悪影響を及ぼす可能性のあるデザインの決定事項に関

するもので、知られていなかったり、無視されてしまいがちな問題が含まれます。

チェックリストを使用する前に、この資料を読むことをお勧めします。チェックリストの項目のほとんどは、この

資料およびその他のザイリンクス資料にリンクされています。これらの参照資料は、チェックリスト項目の質問に

関連するデザインの考慮事項のガイダンスとしてご使用ください。

チェックリストは、ザイリンクス製品を使用しながら資料にアクセスするために使用可能な無償ツールである Xilinx Documentation Navigator の一部として提供されています。 Documentation Navigator は、スタンドアロン製品としてダウンロードできるほか、 SDK および Vivado のインストールに含まれます ( 「Documentation Navigator の使用」参照)。

チェックリストの機能を使用するには、 Documentation Navigator 2015.1 バージョン以降をご使用ください。日本語版のチェックリストは、現在のところ Documentation Navigator からは使用できませんので、スプレッドシートバージョンを参照してください。 Documentation Navigator から設計手法チェックリストを使用するには、次の手順に従います。

1. [Design Hub View] タブをクリックします。

2. 左側のメニューの上部にある [Create Design Checklist] をクリックします。

3. [New Design Checklist] ダイアログボックスに情報を入力し、 [OK] をクリックします。

4. 新しいチェックリストが開きます。チェックリストの一番上のタブ (図 1-2) は、ナビゲーションとして使用します。 [Title Page] タブには、チェックリストを使用する際の基本的な情報が含まれます。ほかのタブをクリックすると、チェックリストの質問およびガイダンスが表示されます。

日本語版は、次のスプレッドシートバージョンを参照してください。

j_xtp397-embedded-design-methodology-checklist.zip


図 1-2: Documentation Navigator のエンベデッド設計手法チェックリストのタブ


https://japan.xilinx.com/cgi-bin/docs/rdoc?d=j_xtp397-embedded-design-methodology-checklist.ziphttps://japan.xilinx.com/cgi-bin/docs/rdoc?d=j_xtp397-embedded-design-methodology-checklist.ziphttps://japan.xilinx.com/cgi-bin/docs/rdoc?d=j_xtp397-embedded-design-methodology-checklist.ziphttps://japan.xilinx.comhttps://japan.xilinx.com/about/feedback.html?docType=Methodology_Guides&docId=UG1046&Title=UltraFast%20%26%2312456%3B%26%2312531%3B%26%2312505%3B%26%2312487%3B%26%2312483%3B%26%2312489%3B%20%26%2312487%3B%26%2312470%3B%26%2312452%3B%26%2312531%3B%26%2335373%3B%26%2335336%3B%26%2325163%3B%26%2327861%3B%26%2312460%3B%26%2312452%3B%26%2312489%3B&releaseVersion=2.3&docPage=7

第 1 章: 概要

資料およびトレーニングへのアクセス

デザインクロージャの短時間での達成およびデザインの総合的な成功のためには、適切な情報にタイムリーにアクセスできることが重要です。ザイリンクスツールについてできるだけ短期間で理解できるよう、リファレンスガイド、ユーザーガイド、チュートリアル、ビデオなどが多数用意されています。このセクションでは、資料およびトレーニングの入手先を示します。

Documentation Navigator の使用ザイリンクスエンベデッドツールには Xilinx Documentation Navigator が含まれており、ザイリンクソフトウェアおよびハードウェア資料、トレーニング、サポート資料にアクセスし、管理する環境を提供しています。

Documentation Navigator を使用すると、最新版およびこれまでのザイリンクス資料を表示できます。資料は、リリース、資料の種類、デザインタスクごとにフィルターして表示できます。検索機能を使用すると、必要な情報をすばやく見つけることができます。

Documentation Navigator はザイリンクスウェブサイトをスキャンして、資料がアップデートされているかどうかをチェックします。 [Update Catalog] を使用すると、利用可能なアップデートがある場合は警告メッセージが表示され、関連する資料の詳細が表示されます。カタログを最新にするようメッセージが表示された場合は、カタログをアッ

プデートして資料を最新の状態にしておくことをお勧めします。指定した資料を含む資料カタログをローカルに作

成して、管理できます。

Documentation Navigator には、 [Design Hub View] というタブがあります。このタブには、 Zynq-7000 デザインの概要、PetaLinux ツール、 SDK など、設計での特定のタスクに関連する資料がリストされています。資料およびビデオがそのタスクを学びやすいように並べられています。エンベデッドデザイン用の各ハブには、 [Embedded Processor Design] (エンベデッドプロセッサデザイン) セクション、 [Design Resources] (デザインリソース) セクション、およびサポートされるリソースのリストなどが含まれます。新規ユーザーは、 [Embedded Processor Design] セクションから始めることをお勧めします。



第 1 章: 概要

ビデオチュートリアルへのアクセスザイリンクスビデオチュートリアルでは、 SDK、 SDSoC、および PetaLinux などのザイリンクスツールの機能の使用方法が具体的に説明されています。これらのチュートリアルを視聴すると、短時間で簡単にツールを学ぶことが

できます。これらは、 https://japan.xilinx.com のビデオチュートリアルのページまたはザイリンクス YouTube チャネルから視聴できます。

ヒント : ビデオチュートリアルには、 Documentation Navigator からもアクセスできます。


図 1-3: Xilinx Documentation Navigator の [Catalog View] タブ


https://japan.xilinx.com/cgi-bin/docs/ndoc?t=vivado+videoshttp://www.youtube.com/user/XilinxInchttp://www.youtube.com/user/XilinxInchttps://japan.xilinx.comhttps://japan.xilinx.com/about/feedback.html?docType=Methodology_Guides&docId=UG1046&Title=UltraFast%20%26%2312456%3B%26%2312531%3B%26%2312505%3B%26%2312487%3B%26%2312483%3B%26%2312489%3B%20%26%2312487%3B%26%2312470%3B%26%2312452%3B%26%2312531%3B%26%2335373%3B%26%2335336%3B%26%2325163%3B%26%2327861%3B%26%2312460%3B%26%2312452%3B%26%2312489%3B&releaseVersion=2.3&docPage=9

第 2 章

システムレベルの考慮事項この章では、 Zynq®-7000 SoC を使用して設計する際に考慮する必要のある次のシステムレベルのデザイン問題について説明します。

• 「パフォーマンス」 : 通常、ターゲットアプリケーションにより全体的なシステムパフォーマンスが決まります。システムパフォーマンスの目標は、ハードウェアとソフトウェアに分配され、さらにサブコンポーネントに分配されます。

• 「消費電力」 : システムパフォーマンスは、消費電力が増加する主な要因となります。消費電力とシステムパフォーマンスのトレードオフは、設計者にとって困難な課題となります。このセクションでは、 Zynq-7000 SoC の消費電力を最適化する際の考慮事項を説明します。

• 「クロッキングおよびリセット」 : クロックリソースを最適に使用するようプランニングするため、使用可能なクロックリソースを理解しておくことが重要です。同様にリセットシステムにもさまざまなソースがあるので、それぞれが異なるリセットデスティネーションにどのように影響するかを理解しておくことも重要です。

• 「割り込み」 : システムレベルの割り込み環境では、アプリケーションのハードウェアとソフトウェアリソースの優先順位を決定する包括的な機能が提供されます。

• 「エンベデッドデバイスのセキュリティ」 : 必要なセキュリティレベルは、アプリケーションによって大きく異なります。 Zynq-7000 SoC のさまざまなセキュリティ機能を理解しておくと、アプリケーションに適切なレベルのセキュリティを適用できます。

• 「プロファイリングおよび分割」 : システムレベルでは、アプリケーションの機能をどのようにハードウェアとソフトウェアに分割するかが重要な決定事項になります。プロファイリングツールは、これらの決定に役立ちます。



第 2 章: システムレベルの考慮事項

パフォーマンス

Zynq-7000 SoC デバイスでは、システムパフォーマンスは最終的なアプリケーションの目標によって異なります。たとえば、リアルタイムアプリケーションのシステムパフォーマンスが割り込みサービスルーチンのレイテンシによって決まったり、ビデオアプリケーションのシステムパフォーマンスがオフチップインターフェイスで毎秒 60 フレームを保持することに依存したりするなどです。このセクションでは、異なる設計チームメンバー間でのパフォーマンス目標の分配について説明し、その後これらのパフォーマンス目標をデータの移動および計算に関する

設計の選択により達成するための考慮事項を示します。また、ソフトウェアおよびプログラマブルロジック (PL) にカスタムパフォーマンス監視機能を構築できるように、 Zynq-7000 SoC デバイスの監視オプションについても説明します。

システムパフォーマンスのデザイン目標システムパフォーマンスの目標は、 Zynq-7000 SoC デバイス設計チームの異なるエンジニアリング部門に分配されます。このガイドでは、ハードウェア、ソフトウェア、システムの 3 つの部門について説明します。

ハードウェア設計者

Zynq デバイスのハードウェア設計者は、 PL コンポーネント、 AXI で接続された IP、高速オフチップインターフェイス、およびカスタムロジックを組み合わせてデザインをインプリメントします。 PL での選択は、スループットやレイテンシなどのパフォーマンス要件により決定されますが、システムソフトウェアとハードウェアの通信におけるパフォーマンスの制限も考慮する場合があります。ハードウェア設計ではデータの移動および同期が PL のスループットおよびレイテンシに大きく影響するので、プロセッシングシステム (PS) との通信を考慮する必要があります。設計における決定を下すため、 PL データの移動および監視ポイントを使用できます。これについては、このセクションの後の方で説明します。最大周波数やリソース使用率などの従来からの PL メトリクスについては説明しません。詳細は、『UltraFast 設計手法ガイド (Vivado Design Suite 用)』 (UG949) [参照 16] を参照してください。

ソフトウェア設計者

ソフトウェア設計者は、 PS 内で実行されるシステムソフトウェアと、そのメモリ、 I/O、および PL との通信に焦点を置いて設計します。たとえば、 PL と通信するユーザーソフトウェアに複数の通信オプションがあり、それぞれ利点と欠点があるとします。 Zynq デバイス特有のソフトウェアパフォーマンス監視機能を使用して、パフォーマンスを調整できます。これについては、このセクションの後の方で説明します。また、既存の Arm パフォーマンスプロファイリングツールおよび監視ツールを使用して、デュアルコア Cortex-A9 プロセッサのパフォーマンスを最適化できます。パフォーマンス監視機能の詳細は、 Arm DS-5 Development Studio Streamline Performance Analyzer の資料 [参照 74] を参照してください。

システム設計者

Zynq デバイスを使用してインプリメンテーションされたデザインのパフォーマンス目標は、ハードウェアとソフトウェアに分配できます。この分配は、デザインのすべての段階を通して考慮する必要があります。初期段階では、

ハードウェア設計者とソフトウェア設計者は比較的個別に作業できますが、早期にパフォーマンスを見積もって現

実的なパフォーマンス目標を設定し、分配することが必要になります。システム設計者は、ハードウェアとソフト

ウェアのパフォーマンスのボトルネックをすべて考慮し、トレードオフを決定する必要があります。システム設計

者は、早期にデータおよび通信パスのパフォーマンスを見積もり、それを後でシステムパフォーマンス監視ポイントおよびツールを使用して調整します。




設計チームのすべてのメンバーは、データの移動およびデータの計算のパフォーマンスに対する影響を考慮しま

す。システムイベントを監視する機能は、 Zynq デバイスのパフォーマンスを設計および最適化する際に有益です。次のセクションでは、これらの考慮事項と、 Zynq デバイスの設計フローを進めていく上で役立つ推奨設計手法を示します。

システムデータの移動システム内でデータを移動させることは、システムレベルパフォーマンスの一般的な問題です。 Zynq デバイスには AXI マスターが複数あり、直接または DMA からトランザクションを駆動できます。このセクションでは、 Zynq デバイスでのデータ移動の問題に対処するためのさまざまなオプションとトレードオフについて説明します。

Arm CPU では、 memcpy などの直接メモリ転送を使用してデータを移動できます。このような転送は 4 KB 以下の小さい転送に有益であり、大きい転送では DMA を使用すると有益です。データのソースおよびデスティネーションバッファーの場所も考慮する必要があります。たとえば、 PS から PL への DMA データ転送は、通常 32 ビットマスター GP ポートを介します。 PS DMA コントローラーを使用するための手法は、『Zynq-7000 SoC テクニカルリファレンスマニュアル』 (UG585) [参照 4] に説明されています。 PS DMA コントローラーは、独自のマイクロコードを実行します。 PL の DMA を使用して 64 ビットの ACP または HP ポートを介してデータを移動する方法もありますが、この方法の方がパフォーマンスが高く、 PL リソースを使用します。

システムデータの移動パフォーマンスを判断する際は、 PS 内のほかの AXI マスターも考慮する必要があります。IOP DMA は、 GigE コントローラー、 SDIO コントローラー、 USB コントローラー、およびデバイスコンフィギュレーションインターフェイス (DevC) の IP ブロックに存在しています。 IP ブロックの機能は『Zynq-7000 SoC テクニカルリファレンスマニュアル』 (UG585) [参照 4] に説明されており、 Linux などのオペレーティングシステムおよびスタンドアロンデザインで使用するためのドライバーが提供されています。 GigE コントローラーのパフォーマンス特性については、『Zynq-7000 SoC 内で PL イーサネットを使用する場合の PS および PL イーサネットパフォーマンスとジャンボフレームのサポート』 (XAPP1082) [参照 40] を参照してください。残りのコアには追加機能を提供するドライバー層がありますが、そのパフォーマンス特性はここでは説明しません。

PL からは、 AXI マスターにより ACP、 HP、またはスレーブ GP ポートのデータ移動を駆動できます。これらのポートおよび関連のパフォーマンスは、次のセクションで説明します。

• 「ACP およびキャッシュコヒーレンシ」

• 「PL の HP ポートアクセス」

• 「APU からの GP およびダイレクト PL アクセス」

これらのポートに接続されている DMA は、AXI4 メモリマップドインターフェイスと AXI4-Streaming インターフェイスの間の変換に使用するのが最適で、メモリマップドアクセスとデータ中心プロセッシング (ビデオパイプラインなど) を確実に分離します。ただし、 DMA が常に好ましい方法ではありません。ストリーミングインターフェイスのパフォーマンスが低く、問題とならない場合は、 AXI4-Stream FIFO コアを使用するのがプロセッサから AXI-Stream インターフェイスをソースおよび同期するのに簡単な方法です。ユーザーアプリケーションには、標準の AXI メモリマップドトランザクションを使用してデータを直接移動するカスタム AXI マスターを含めることができます。このようなカスタムデータ転送のスループットおよびレイテンシのパフォーマンス特性は、標準 PL DMA データ転送に非常に近いものになる可能性があります。「システム監視」に説明されているカウンターおよびタイ

マーを使用して、パフォーマンスを比較できます。

DMA は、ソースからデスティネーションにデータを転送します。データソース、処理、またはデータシンクのレートを一致させるためにメモリがデータバッファーとしてよく使用され、処理段階で最大のスループットを達成できるようにします。




オフチップのデータバッファーの場所は、カスタマイズ可能な MIO または EMIO ピンに接続されているオフチップのメモリを使用してインプリメントできます。メモリの特性は、 SD カードのファイルシステムや GigE コントローラーを介してネットワークで接続されたストレージなど、大きなバッファーを移動する際のパフォーマンスに影響

します。

オンチップのバッファリングでは、 OCM、 L2 キャッシュ、 DDR コントローラーが PS 内の共有可能なバッファー空間の主なソースです。 L2 キャッシュおよび DDR コントローラーは、プロセッサと ACP ポート間でデータを共有するのに非常に適したバッファーアクセスレイテンシを持ちます。 ACP のみが PL から L2 キャッシュにアクセス可能です。 DDR への高帯域幅のアクセスには、 ACP よりも HP ポートが適しています。 OCM は、 PL 内のすべてのマスターでアクセス可能な 256 KB のスクラッチパッドとしてソフトウェアアプリケーションで使用できます。 OCM を使用する利点は、ランダムアクセスレイテンシが優れているということです。 L2 キャッシュおよび DDR メモリはローカルのメモリアクセスで有益です。

システム計算

計算は Arm コアまたは PL 内で実行できます。一般的な Zynq デバイスには、 Arm コアで実行されるソフトウェアに記述された制御プレーンがあります。データ中心の計算は、既存の IP とカスタム IP を組み合わせて使用して PL で実行されます。ラインレートパケットの処理など高パフォーマンスが必要な場合は、計算と制御をデータの近くに移動できます。これには通常、データフローを制御するのにカスタム PL IP が必要です。

計算をソフトウェアから PL に移動できることは、 Zynq-7000 SoC プラットフォームの重要な利点です。すべてのソフトウェアを PL に移動できるわけではありません。コンパイル済みのコード、複雑なライブラリルーチン、 OS サービスなどは移動できません。ソフトウェアコンポーネントを PL に移動できる場合は、フルアプリケーションランタイムなどのパフォーマンスメトリクスでデータ移動のコストとアクセラレーションのトレードオフを考慮する必要があります。このコストと利点の解析はソフトウェアプロファイリングツールを使用して実行でき、アムダールの法則に基づいて可能な高速化を判断できます。

この式で、 S はシステム全体のパフォーマンス向上、 α はハードウェアアクセラレーションによりスピードアップ可能なアルゴリズムの割合を示します。 1-α は向上できないアルゴリズムの割合です。 p はアクセラレーションによるスピードアップです。たとえば、すべてがソフトウェアにインプリメントされている計算アルゴリズムを高速化するた

め、 TCF プロファイラーなどのプロファイリングツールを使用して頻繁に使用される関数を特定できます。その関数が使用される時間の割合が大きいと、 α の値が大きくなります。この関数をハードウェアにインプリメントしてスピードアップできます。関数のスピードアップが p に代入されます。頻繁に使用される関数のスピードアップが大きければ、ハードウェアアクセラレーションによるアルゴリズムの計算のパフォーマンス向上も大きくなります。

特定の関数のスピードアップには、アクセラレーションブロックとのデータ転送と、アクセラレータにより実行される実際の計算の 2 つの要素があります。データ転送に DMA を使用する場合、 p を算出する際に DMA の設定および制御のオーバーヘッドを考慮する必要があります。オーバーヘッドが大きいと p の値が小さくなり、パフォーマンスの向上率も低くなります。詳細は、「プロファイリングおよび分割」を参照してください。

高位合成は、ソフトウェアコンポーネントを PL に移動してアクセラレーションオプションを調べるのに適した方法です。候補となっているソフトウェアが高位合成に適していない場合は、ザイリンクスが提供するプログラマブ

ルロジック IP と対応するドライバーのライブラリを使用して、これらをソフトウェアにインプリメントされた関数と置き換えて、システムパフォーマンス全体を向上できます。




システム監視 Arm プロセッサを監視するために、さまざまなツールがあります。 Zynq デバイスでは、システムレベルパフォーマンスの監視に PS および PL にあるブロックも使用されます。これらのブロックは、次のとおりです。

• SCU グローバルタイマー (PS): SCU グローバルタイマーは、 1 つのクロックドメインでのシステムイベントにタイムスタンプを付けるのに使用できます。また、オペレーティングシステムには通常、 Linux clock_nanosleep のように、ソフトウェアイベントトレーシング用の高精度タイマーが含まれています。

• Arm パフォーマンスモニターユニット (PS): 各 Arm コアには、マイクロアーキテクチャイベントをカウントするのに使用されるパフォーマンス監視ユニット (PMU) が含まれています。これらのカウンターには、オペレーティングシステムのユーティリティを介してソフトウェアから直接アクセスするか、 Linux Perf や Arm Streamline などのチップデバッガーでアクセスできます。これらのカウンターは、 SDK 2014.2 の [Performance] ビューで表示できます。詳細は、 Arm 社の『Cortex-A9 Technical Reference Manual』 [参照 77] の「Performance Monitoring Unit」を参照してください。

• L2 キャッシュイベントカウンター (PS): L2 キャッシュには、キャッシュパフォーマンスを計測するためにアクセス可能なイベントカウンターがあります。これらのカウンターは、 SDK の [Performance Counters] ビューで表示できます。詳細は、『Zynq-7000 SoC テクニカルリファレンスマニュアル』 (UG585) [参照 4] を参照してください。

• GigE コントローラー (PS): ギガビットイーサネットコントローラーには、インターフェイスで送受信されたバイト数を監視するための統計カウンターがあります。詳細は、『Zynq-7000 SoC テクニカルリファレンスマニュアル』 (UG585) [参照 4] を参照してください。

• Arm パフォーマンスモニター (PL): このコアは PL に追加し、スループットやレイテンシなどの AXI パフォーマンスメトリクスを監視するために使用できます。トレース機能は、トランザクションごとのレイテンシを監視するためのタイムスタンプ付きの AXI トランザクションの開始と終了など、タイムスタンプ付き AXI トレースをイネーブルにします。詳細は、 AXI パフォーマンスモニターのウェブページ [参照 45] を参照してください。

• Arm タイマー (PL): このコアは PL に追加し、 PL 内のフリーランニングタイマーとして使用できます。 PL クロックドメイン内のイベントにタイムスタンプを付けるのに便利です。詳細は、 AXI タイマー /カウンターのウェブページ [参照 46] を参照してください。

• Arm トラフィックジェネレーター (PL): このコアを使用すると、 PS インターフェイスに対してさまざまなトラフィックパターンを生成できます。 AXI パフォーマンスモニターと共に使用して、システムレベルのパフォーマンスを早期に見積もることができます。このコアを使用して、データ移動コストを見積もり、デザインの分割

方法を検証できます。詳細は、 LogiCORE™ AXI Traffic Generator のウェブページ [参照 47] を参照してください。

これらのモニターブロックを使用すると、システム全体のパフォーマンスを可視化できます。イベントカウンターおよび PL 監視ブロックは、特定のデザインパフォーマンス目標に合わせてカスタマイズしたり、システムパフォーマンスの全体像を取得するのに使用できます。ビルトインのパフォーマンス監視機能を早期に使用すること

により、デザインサイクルを通してパフォーマンスフィードバックを取得でき、データドリブンのシステムアーキテクチャの決定を下すことができます。

さまざまなブロックからの監視データを利用および取得する方法は複数あります。ほとんどのペリフェラルには、

対応するベアメタルドライバーと共にパッケージされたサンプルアプリケーションがザイリンクス SDK で提供されています。使用可能な Linux ドライバーのリストは、ザイリンクス Linux ドライバー Wiki ページ [参照 52] を参照してください。

ザイリンクス SDK には、ビルトインのシステムパフォーマンスモデリングおよび解析機能が含まれています。パフォーマンスモニターは、システムからライブデータまたは実際のトランザクションをモデリングするトラフィックジェネレーターで作成されたデータを収集します。このデータは、ザイリンクス SDK の表示ツールを使用して、HP および ACP ポートに接続されている APM (プロファイルモード ) からのトランザクション数、帯域幅、およびレイテンシの統計と共に表示できます。詳細は、「ザイリンクス SDK システムデバッガー」を参照してください。




消費電力

Zynq-7000 SoC の消費電力は、システム設計およびボード設計において重要な考慮事項です。消費電力はほとんどのアプリケーションで重大な課題であり、アプリケーションによってはカードごとまたはシステムごとの最大消費電

力が指定されます。そのため、設計プロセスの早期に消費電力を考慮する必要があります (多くの場合デバイス選択時から開始)。

SoC の消費電力を削減すると、電源レールの電力を下げ、電源デザインおよび温度管理を簡略化し、電源分配プレーンの要件を緩和することによりボード設計を向上できます。消費電力が少ないと、バッテリの寿命も長くなり、

システムの動作温度が低い方が長持ちするので信頼性も向上します。

システムの消費電力を削減するには、最適な結果を得るために包括的で集中的なアプローチが必要です。このセク

ションでは、 PS および PL のアーキテクチャおよび機能、 PL に関連する電力コンポーネント、プロセステクノロジなど、 Zynq-7000 SoC の消費電力に関するさまざまな側面について説明します。また、電力損失と、消費電力の見積もりおよび計測に使用される従来からの方法を示します。




消費電力の課題

ムーアの法則によれば、プロセステクノロジの各世代ごとにトランジスタのサイズが小さくなります。サイズが小さくなると、各トランジスタのリーク電流が増加し、スタティック消費電力 (デバイスが動作していないときに消費される電力) が増加します。 SoC のパフォーマンスを向上するには、高周波数クロックが必要で、ダイナミック消費電力が増加します。スタティック消費電力はトランジスタのリーク電流に、ダイナミック消費電力はトランジスタ

のスイッチング周波数によって決まります。さらに不利なことに、トランジスタのサイズを小さくすると、 FPGA 上に搭載できるトランジスタの数が増加します。トランジスタ数が多くなればリーク電流も増加し、各 FPGA デバイス上でより多くのトランジスタがより高いクロック周波数で切り替わることになります。

これらの問題のため、電源および温度管理の問題にデザインサイクルの早期から対処しておく必要があります。デバイスにヒートシンクを使用するだけでは、これらの問題を適切に解決できない可能性があります。デザインロジックの影響を削減する方法を模索する必要があります。

図 2-1 に、デザインサイクルのさまざまな地点で消費電力を削減するために実行可能な操作を示します。消費電力の問題に設計プロセスの早期に対処すると、大きな効果が得られます。


図 2-1: デザインサイクルのさまざまな段階で消費電力の問題に対処




消費電力および信号伝送

Zynq-7000 SoC デバイスは、図 2-2 に示すように、いくつかの電源ドメインに分割されます。

PS と PL の電源は独立していますが、PL に電源を供給しているときには PS にも電源が供給されている必要があります。 PL を必要としないアプリケーションでは、 PL の電源をオフにできます。表 2-1 に PS および PL の電源ピンを示します。電圧シーケンスと電気的仕様は、『Zynq-7000 SoC (Z-7010、 Z-7015、 Z-7020): DC 特性および AC スイッチ特性』 (DS187) [参照 30] を参照してください。

PS 電源ドメイン

Zynq-7000 SoC の PS 電源ドメインについては、『Zynq-7000 SoC PCB デザインガイド』 (UG933) [参照 14] の第 5 章「プロセッシングシステム (PS) の電源および信号」を参照してください。


図 2-2: Zynq-7000 SoC の電源ドメイン

表 2-1: 電源ピン

タイプピン名公称電圧説明

PS 電源 VCCPINT 1.0V 内部ロジック

VCCPAUX 1.8V I/O バッファープリドライバー

VCCO_DDR 1.2V ～ 1.8V DDR メモリインターフェイス

VCCO_MIO0 1.8V ～ 3.3V MIO バンク 0、ピン 0:15

VCCO_MIO1 1.8V ～ 3.3V MIO バンク 1、ピン 16:53

VCCPLL 1.8V 3 つの PLL クロック、アナログ

PL 電源 VCCINT 1.0V 内部コアロジック

VCCAUX 1.8V I/O バッファープリドライバー

VCCO_# 1.8V ～ 3.3V I/O バッファードライバー (バンクごと )

VCC_BATT 1.5V PL 復号キーのメモリバックアップ

VCCBRAM 1.0V PL ブロック RAM

VCCAUX_IO_G# 1.8V ～ 2.0V PL 補助 I/O 回路

XADC VCCADC 1.8V アナログ電源およびグランド

グランド GND グランドデジタルおよびアナロググランド

X14195-073117

Programmable Logic

VCCINT

VCCAUX

VCCO0 VCCO1 VCCOn

Processing System (PS)

VCCPINT

VCCPAUX

VCCPLL

VCCO_MIO0 VCCO_DDR VCCO_MIO1




PL 電源ドメイン

Zynq-7000 SoC の異なる PL リソースに電源を供給するには、複数の電源が必要です。異なるリソースは異なる電圧レベル動作するので、ノイズや寄生効果に対して高い耐性を保ちながら、パフォーマンスおよび信号強度を向上で

きます。

「PL の電源」に、 Zynq-7000 SoC で使用可能な PL リソースで使用される一般的な電源を示します。詳細は Zynq-7000 SoC ファミリによって異なる場合があるので、この表はガイドラインとしてのみ示しています。

表 2-2: PL の電源

電源電源が供給されるリソース

VCCINTおよび

VCCBRAM

• すべての CLB リソース

• すべての配線リソース

• クロックツリー全体 (すべてのクロックバッファーを含む)

• ブロック RAM/FIFO

• DSP スライス

• すべての入力バッファー

• IOB 内のロジックエレメント (ILOGIC/OLOGIC)

• ISERDES/OSERDES

• トライステートイーサネット MAC

• クロックマネージャー (DCM、PLL など) (大部分は Vccaux で供給されるため少量のみを供給)

• MGT の PCIE および PCS 部分

VCCAUXおよび

VCCAUX_IO

• クロックマネージャー (MMCM、 PLL、 DCM など)

• IODELAY/IDELAYCTRL

• すべての出力バッファー

• 差動入力バッファー

• VREF ベースのシングルエンド I/O 規格 (HSTL18_I など)

• 位相器

VCCO • すべての出力バッファー

• 一部の入力バッファー

• デジタル制御インピーダンス (DCI) 回路 (オンチップ終端 (OCT))

MGT • トランシーバーの PMA 回路




ボードレベルの電源分配システムプリント回路基板では、電源が電源分配システム (PDS) によりソースから電源を必要とするさまざまなチップおよびデバイスに分配されます。 PDS デザインは単純なものから複雑なものまでありますが、次の 3 つの主な要件を満たす必要があります。

• 適切に調整された電源を供給する必要があります。電源調整は安定化電源回路で実行され、 1 つまたは複数のバルクキャパシタと LC フィルター回路でサポートされます。

• すべての電流負荷条件下でボードのすべてのポイントで安定している必要があります。すべての負荷条件化での安定には、次の 2 つの要件があります。

° 分配システムの抵抗とインダクタンスは低い必要があります。これには通常、分配用に電源プレーンおよ

び帰路プレーンと、さまざまなデバイス接続に低インダクタンスのパッドおよびビアが必要です。

° 電荷は必要なときに必要な場所にあることが必要です。必要な電荷は通常、ボード全体に配置されている

バイパスキャパシタと、それよりは少ないが分配された平面キャパシタンスに蓄積されます。

• デバイスのスイッチをオンにしたときにほかのデバイスを干渉したり、 EMI を発生させるノイズを生成しないことが必要です。

Zynq デバイスの電源分配システムの詳細は、『Zynq-7000 SoC PCB デザインガイド』 (UG933) [参照 14] の第 3 章「電源分配システム」を参照してください。

パワーマネージメントZynq-7000 SoC を使用することにより、システムのスタティック消費電力を削減できることがあります。 Zynq-7000 SoC の PS は、デュアルコア Arm Cortex-A9 CPU と統合されたペリフェラルから構成される最適化されたシリコンエレメントです。 PL は、 28 nm の高性能、低消費電力 (HPL) プロセスで構築されたザイリンクス 7 シリーズアーキテクチャに基づいており、消費電力を大幅に削減しながら高パフォーマンスを提供します。 HPL プロセスで構築されたデバイスを選択すると、複雑でコストの高いスタティック消費電力管理機構は必要なくなります。

システム消費電力を削減するには、多数の方法があります。次のセクションでは、システム消費電力要件を満たす

ためにデザインを最適化する際に役立つヒントを示します。

PS パワーマネージメント

このセクションでは、 Zynq-7000 SoC PS の消費電力を最適化する際の考慮事項を説明します。これには、 APU ユニット、 PS ペリフェラル、クロックおよび PLL、キャッシュ、 SCU、 OCM の消費電力管理が含まれます。ここでの説明は、システム全体の消費電力管理のトレードオフの影響を理解していることを前提としています。




システム設計に関する考慮事項

PS コンポーネントの消費電力は、次のように管理できます。

• アプリケーションプロセッシングユニット (APU): Zynq-7000 SoC の APU では、動的なクロックゲーティングがサポートされています。この機能は、 CP15 電源制御レジスタを使用して有効にできます。有効にすると、CPU 内部ブロックへのクロックがアイドル期間中、動的に無効になります。クロックゲーティングの対象となるのは、次のブロックです。

° 整数コア

° システム制御ブロック

° データエンジン

プロセッサコアの電圧と動作周波数を下げることにより、消費電力を最大 1/2 削減することが可能です。詳細は、『Zynq-7000 SoC テクニカルリファレンスマニュアル』 (UG585) [参照 4] の消費電力管理のセクションを参照してください。

• PS ペリフェラル: PS は、数個のクロックドメインをサポートしており、各ドメインに個別のクロックゲーティング制御があります。システムが動作モードの場合は、使用されていないクロックドメインをシャットダウンしてダイナミック消費電力を削減できます。タイマー、 DMA、 SPI、 QSPI、 SDIO、 DDR コントローラーなどの PS ペリフェラルのクロックは、個別にゲーティングして消費電力を削減できます。システムクロックと、それらを分周器、ゲート、マルチプレクサーを使用して制御する方法の詳細は、『Zynq-7000 SoC テクニカルリファレンスマニュアル』 (UG585) [参照 4] の第 25 章「クロック」を参照してください。

• キャッシュ : L2 キャッシュコントローラーでは、次のダイナミック消費電力削減機能がサポートされます。この機能は、 l2cpl310.reg15_power_ctrl レジスタの該当するイネーブルビットで制御します。

° 動的クロックゲーティング: 高度な動的クロックゲーティング機能を有効にすると、キャッシュコントローラーがアイドル状態のときにそのクロックが停止します。クロックゲーティング機能は、コントローラーがアイドル状態になってから数サイクル後にクロックを停止します。

° スタンバイモード : L2 キャッシュコントローラーのスタンバイモードは、 L2 キャッシュコントローラーを駆動しているプロセッサの割り込み待機 (WFI) モードと組み合わせて使用できます。プロセッサが WFI モードでスタンバイモードが有効になっている場合、 L2 キャッシュコントローラーの内部クロックが停止します。 WFI 使用の詳細は、『Zynq-7000 SoC テクニカルリファレンスマニュアル』 (UG585) [参照 4] の第 3 章「アプリケーションプロセッシングユニット (APU)」を参照してください。

スタンバイモードは、動的クロックゲーティング機能の一部です。スタンバイモードでは、クロックゲーティングは WFI ステートに限定されるため、通常の動作条件における L2 キャッシュアクセスの予測性が向上します。

• オンチップメモリ (OCM): 通常、 Linux スタンドバイモードなどの低消費電力モードでの全体的な消費電力を削減するために OCM を使用できます。たとえば、 DDR が低消費電力モードの場合に実行コードを格納するのに OCM を使用できます。

• スヌープ制御ユニット (SCU): mpcore.SCU_CONTROL_REGISTER で該当するビットをセットすると、 SCU のスタンバイモードを有効にできます。これを有効にすると、次の条件が満たされた場合に内部 SCU クロックが停止します。

° CPU が WFI モード。

° ACP に保留中の要求がない。

° SCU にアクティビティが残っていない。

CPU が WFI モードを終了するか、 ACP に要求が発生すると、 SCU は通常動作を再開します。




• PLL: PLL の消費電力は PLL の出力周波数に依存するので、 PLL の出力周波数を低くすると消費電力を削減できます。また、未使用の PLL の電源をオフにしても、消費電力を削減できます。たとえば、すべてのクロックジェネレーターを DDR PLL で駆動できる場合、 Arm コア PLL と I/O PLL を無効にして消費電力を削減できます。すべてのクロックジェネレーターを駆動できるのは DDR PLL のみです。各クロックは、使用しない場合は個別に無効にできます。サブシステムに追加のクロック無効化機能およびほかの消費電力削減機能が含まれ

ている場合もあります。

• 物理メモリ : Zynq-7000 SoC では、 DDR2、 DDR3、 LPDDR2 など、異なるタイプの物理メモリがサポートされます。サポートされる DDR メモリタイプは、 16 ビットデータおよび 32 ビットデータの両方で動作できます。DDR の消費電力は総消費電力の大きな割合を占めるため、その消費電力を最小限に抑えることがシステム消費電力を削減する重要な手段となります。 DDR の消費電力を削減する際には、次の事項を考慮します。

° DDR コントローラーの動作速度。

° DDR の幅および ECC を有効にするか無効にするか。

° 使用される DDR チップの数。

° DDR タイプ (電圧を大幅に下げるために LPDDR を使用するなど)。

° 低消費電力動作中に使用される異なる DDR モードの使用 (DDR セルフリフレッシュモードなど)。 DDR の低消費電力動作モードでの消費電力については、該当する DDR 規格を参照してください。

DDR コントローラーのクロックゲーティングのインプリメンテーションについては、『Zynq-7000 SoC テクニカルリファレンスマニュアル』 (UG585) [参照 4] の「クロック」の章を参照してください。

• I/O: MIO や DDR I/O などの I/O デバイスも、総消費電力に影響します。 I/O バッファー制御のパワーマネージメントについては、『Zynq-7000 SoC PCB デザインガイド』 (UG933) [参照 14] の「SelectIO のシグナリング」の章を参照してください。

ソフトウェアサポート

Linux カーネルでは、次のパワーマネージメントステートがサポートされます。

• S0: フリーズまたは低消費電力アイドル状態。これは、汎用の純粋なソフトウェア、軽量、低消費電力ステートです。

• S1: スタンバイまたはパワーオンサスペンド。すべてのプロセッサキャッシュが消去され、命令実行が停止します。プロセッサおよび RAM への電源供給は保持されます。

• S3: STR (Suspend-to-RAM)。システムおよびデバイスのステートがメモリに保存されます。すべてのデバイスがサスペンド状態になり、電源がオフになります。 RAM への電源供給は保持されます。

Linux の Zynq-7000 SoC のパワーマネージメントサポートについては、 Zynq パワーマネージメント Wiki ページ [参照 66] を参照してください。

このリンクには、 Zynq-7000 SoC 用にインプリメントされる CPU スケーリングフレームワークについての情報もあります。 CPU スケーリングフレームワークは、ランタイムに CPU の周波数をスケーリングするために使用されます。高処理パフォーマンスを必要としないアプリケーションでは、アプリケーションの要件に合わせて CPU の周波数を下げることができます。クロック周波数を下げると、動作時の消費電力を大幅に削減できます。




PL パワーマネージメントPL を必要としないアプリケーションでは、 PL の電源をオフにできます。これには、 PS と PL を独立した電源に接続しておく必要があります。オフにできる PL 電源には、 VCCINT、 VCCAUX、 VCCBRAM、および VCCO があります。電源投入シーケンスを判断するには、該当するデータシートを参照してください。

PL の電源をオフにするとコンフィギュレーションが失われるため、次の電源投入時にもう一度コンフィギュレーションする必要があります。 PL の電源をオフにしても安全かどうかは、ソフトウェアで判断するようにする必要があります。

このセクションでは、 Zynq-7000 SoC の PL 消費電力を最適化する際の考慮事項を説明します。

ロジックリソースの使用量

PL リソースの使用量は、 Zynq-7000 SoC で使用される総消費電力を決定する重要な要素です。使用される CLB リソース、専用ハードウェア、配線の量はデザインによって異なり、 PL で使用されるスタティック消費電力およびダイナミック消費電力が追加されます。 PL アーキテクチャを詳細に理解しておくことにより、シリコンリソースを活用できます。

消費電力を削減するには、デザインのロジックを削減できる可能性を探す必要があります。これによりより小型の

デバイスを使用できるようになり、スタティック消費電力が削減されます。 1 つの方法は、 CLB にファンクションをインプリメントするのではなく専用ハードウェアブロックを使用することです。これによりスタティック消費電力およびダイナミック消費電力が削減され、タイミング要件を満たしやすくなります。専用ハードウェアブロックを使用すると、 CLB ロジックを使用して等価コンポーネントを構築するよりも総トランジスタ数が少なくなるので、スタティック消費電力が削減されます。

特定のリソースをインスタンシエートするには、 IP カタログを使用して専用ハードウェアをカスタマイズします。未使用の PS IP は、ほかのタスクに使用できます。たとえば DSP48 スライスには、乗算、加算、累算、多入力ロジックコンパレータ、シフター、パターン一致、カウンターなど、多数のロジックファンクションがあります。ブロック RAM は、ステートマシン、数値演算、 ROM に使用できます。

UltraFast エンベデッド デザイン 設計手法ガイド - Xilinx...UltraFast エンベデッド デザイン 設計手法ガイド UG1046 (v2.3) 2018 年 4 月 20 日...

Documents

UltraFast エンベデッドデザイン設計手法ガイド - Xilinx...UltraFast エンベデッドデザイン設計手法ガイド UG1046 (v2.3) 2018 年 4 月 20 日...