Zynq UltraScale+ MPSoC エンベデッド設計手法ガ...

Zynq UltraScale+ MPSoC エンベデッド設計手法ガイド

UG1228 (v1.0) 2017 年 3 月 31 日

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

Zynq UltraScale+ MPSoC エンベデッド設計手法ガイド 2UG1228 (v1.0) 2017 年 3 月 31 日 japan.xilinx.com

改訂履歴

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

日付バージョン改訂内容

初版2017 年 3 月 31 日 1.0

https://japan.xilinx.com

https://japan.xilinx.com/about/feedback.html?docType=Methodology_Guides&docId=UG1228&Title=Zynq%20UltraScale+%20MPSoC%20%26%2312456%3B%26%2312531%3B%26%2312505%3B%26%2312487%3B%26%2312483%3B%26%2312489%3B%26%2335373%3B%26%2335336%3B%26%2325163%3B%26%2327861%3B%26%2312460%3B%26%2312452%3B%26%2312489%3B&releaseVersion=1.0&docPage=2

目次

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

第 1 章: 概要ブロック図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

ベクター設計手法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

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

第 2 章: プロセッシングシステムプロセッシング要件を定義する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

プロセッシングシステムの設計手法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

ヘテロジニアスコンピューティングの概念 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

アプリケーションプロセッシングユニット (APU). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

APU の仮想化サポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

リアルタイムプロセッシングユニット (RPU). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

インターコネクト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

割り込み . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

PL を使用したワークロードアクセラレーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

汎用コンピューティングのアクセラレーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

第 3 章: システムソフトウェアの検討事項システムソフトウェア要件を定義する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

システムソフトウェアの設計手法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

ブートプロセスソフトウェア . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

システムソフトウェアスタック . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

OpenAMP フレームワーク . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Xen ハイパーバイザー. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

PMU ソフトウェア . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

ソフトウェア開発ツール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

開発フロー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

第 4 章: 電源に関する注意事項電源の要件を定義する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

パワーマネージメントの調整方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4 つの主要電源ドメイン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

電源アイランドとパワーゲーティング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

プラットフォーム管理ユニット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

パワーマネージメントソフトウェアのアーキテクチャ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Xilinx Power Estimator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

第 5 章: プログラマブルロジックPL の要件を定義する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91




PL の設計手法. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

ロジック . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

統合 IP のサポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

コンフィギュレーションおよびパーシャルリコンフィギュレーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

消費電力削減機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

第 6 章: メモリメモリの概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

メモリ要件を定義する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

メモリの設計手法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

ビルトインメモリブロック . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

PS DDR メモリおよびコントローラー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

グローバルシステムメモリマップ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

PS DMA コントローラー. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

PL を使用する外部メモリ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

第 7 章: リソースの分離と分割リソース分離/分割の要件を定義する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

リソースの分離と分割に関する設計手法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119ARM TrustZone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

システムメモリ管理ユニット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

ザイリンクスメモリ保護ユニット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

ザイリンクスペリフェラル保護ユニット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Xen ハイパーバイザー. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

第 8 章: セキュリティセキュリティ要件を定義する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

セキュリティに関する設計手法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

セキュリティ機能の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

コンフィギュレーションのセキュリティとセキュアブート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

デバイスとデータのセキュリティ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

DPA 攻撃からの保護 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

CSU ハードウェアアクセラレータ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

機能安全 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

第 9 章: マルチメディアマルチメディア要件を定義する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

マルチメディアに関する設計手法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154DisplayPort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

GPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

VCU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

第 10 章: ペリフェラルペリフェラル要件を定義する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

ペリフェラルの設計手法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176GPIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

I2C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

SPI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

UART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

CAN コントローラー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185




NAND. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

SD/SDIO/eMMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Quad-SPI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

ギガビットイーサネットコントローラー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193USB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

PCI Express. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

SATA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

DisplayPort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

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

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

Documentation Navigator およびデザインハブ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

参考資料 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

法的通知 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203




第 1 章

概要Zynq® UltraScale+™ MPSoC プラットフォームは、業界初の完全な All Programmable ヘテロジニアスマルチプロセッ

シング SoC (システムオンチップ) デバイスです。自動車業界、大規模データベース、さらには宇宙開発まで多くの

アプリケーションにおいてスマートシステムの複雑さが増しており、世代交代を重ねる SoC に対する要求もとどま

るところを知りません。電源制御、リアルタイムアプリケーション、強力なグラフィックス機能、および処理性能

に対する要求の高まりにより、大限の柔軟性を備えたプラットフォームが必要とされています。 Zynq UltraScale+

MPSoC プラットフォームは、先進のシステム設計に必要な先端の機能を備えています。

TSMC (Taiwan Semiconductor Manufacturing Company) 社の次世代 16 nm FinFET プロセスノードを採用した Zynq

UltraScale+ MPSoC は、スケーラブルな 32 または 64 ビットマルチプロセッサ CPU、リアルタイムグラフィックスお

よびビデオ処理専用のハードエンジン、先進の高速ペリフェラル、およびプログラマブルロジックを内蔵していま

す。このプラットフォームはデュアルコアまたはクワッドコアの APU により大限のスケーラビリティを実現して

いるほか、グラフィックスおよびビデオパイプラインなどの重要なアプリケーションを専用のプロセッシングブ

ロックにオフロードできます。また、効果的な電源ドメインおよび電源アイランドのゲーティングによりブロック

単位でのオン/オフも可能です。幅広いインターコネクトオプション、デジタル信号処理 (DSP) ブロック、およびプ

ログラマブルロジックの選択肢を豊富に備えた Zynq UltraScale+ MPSoC には、ユーザーアプリケーションの多様な

要件に応える柔軟性があります。

このガイドは、 Zynq UltraScale+ MPSoC の機能セットに関連してユーザーデザインの意思決定を支援するツールと

なるものです。推奨事項とトレードオフを十分に評価した上で、個々の製品に適な判断をしてください。このガ

イドは、Zynq UltraScale+ MPSoC の主要な機能にシステム設計要件をマップしたものを図で表したベクター設計手法

( 「ベクター設計手法」参照) に基づいて構成しています。ベクター設計手法はプラットフォームの機能を大限に

利用することを目的としたものではなく、製品をプラットフォーム上に構築する際に実行できるトレードオフとソ

リューションを視覚的に表現するものです。この結果、全体的なソリューションの中で特定のプラットフォーム機

能の優先度が相対的に低下することがあります。ベクター設計手法を使用すると、設計者はチーム内のハードウェ

ア設計者、アーキテクト、ソフトウェアエンジニアなどほかのメンバーに対し、それぞれの職務に関係のあるセク

ションの設計手法を参照するように指示できます。




第 1 章: 概要

ブロック図

Zynq UltraScale+ MPSoC デバイスはプロセッシングシステム (PS) とプログラマブルロジック (PL) の 2 つのブロック

に大別され、これらは別々の電源ドメインに属しています。

PS はスタンドアロンの MPSoC デバイスとして動作し、 PL に電源を投入しなくてもブート可能で、かつ 8 ページの

図 1-1 に示すすべての機能をサポートできます。このマニュアルでは、内蔵の各ブロックについて説明します。

Zynq UltraScale+ MPSoC デバイスには次の 4 つの電源ドメインがあります。

• 低電力ドメイン (LPD)

• フル電力ドメイン (FPD)

• PL 電源ドメイン (PLPD)

• バッテリ電源ドメイン (BPD)

各電源ドメインはそれぞれ分離させることができます。 LPD に属するプラットフォーム管理ユニット (PMU) を使用

すると、各電源ドメインを容易に分離できます。このように各電源ドメインを個別に切り離すことができるため、

安全およびセキュリティアプリケーションで特に重要となる機能の分離が可能です。また、不測の事態によってい

ずれかの電源ドメインへの電源供給が停止すると、ドメインの分離が自動的に実行されます。




第 1 章: 概要

図 1‐1: ブロック図

X-Ref Target - Figure 1-1

RPU

256 KBOCM

LPD-DMA

CSUPMU

Processing System

Cortex-R532 KB I/D

128 KB TCM

Cortex-R532 KB I/D

128 KB TCM

4 x 1GE

APU

Cortex-A5332 KB I/D

Cortex-A5332 KB I/D

Cortex-A5332 KB I/D

Cortex-A5332 KB I/D

GIC

SCU

ACP 1 MB L2

GPUMali-400 MP2

64 KB L2

2 x USB 3.0

NAND x8ONFI 3.1

2 x SD3.0/eMMC4.51

Quad-SPIx 8

2 x SPI

2 x CAN

2 x I2C

2 x UART

GPIOs

SYSMON

MIO Central

Switch

FPD-DMA

VCU H.264/H.265

PCIe Gen4

DisplayPort v1.2 x1, x2

2 x SATAv3.0

PCIe Gen2x1, x2, or x4

SHA3AES-GCMRSA

Processor System BPU

DDRC (DDR4/3/3L, LPDDR3/4)

Programmable Logic

128 KB RAM

PL_

LPD

HP

GIC

LLLP

LLLP

RGMII

ULPI PS-G

TR

SMMU/CCI

GFC

USB 3.0

SGMII

Low Power Switch

To ACP

Low Power Full PowerBattery Power

32-bit/64-bit

64-bitM S

128-bitM S

UG1085_c1_01_091715

LPD

_PL

HP

CH

PM

GTY Quad

GTH Quad

Interlaken 100G Ethernet

AC

E DisplayPort Video and

Audio Interface




第 1 章: 概要

ベクター設計手法

ベクター設計手法を Zynq UltraScale+ MPSoC デバイスに適用すると、次の図のようになります。

図 1‐2: ベクター設計手法の図


Power

Processing System

Programmable Logic

Real-Time Processing

Security

Multimedia

Memory

Peripherals

System Software Configurations

Resource Isolationand Partitioning

X18044-032917

この図で、中心から放射状に伸びている線は Zynq UltraScale+ MPSoC プラットフォームの各機能領域を表していま

す。中心点はその機能領域の必要性がゼロであることを示し、外側に向かうほど必要性と複雑さが大きくなってい

きます。システムアーキテクトは FAE またはセールスエンジニアと共同で、各機能領域がどの程度デザインに関係

するかをこの図にプロットします。これらの点を結ぶと、どのような問題に対処すればよいのかを全体像として把

握できます。

例として、先進運転支援システム (ADAS) の場合を考えてみます。




第 1 章: 概要

図 1‐3: ベクター設計手法の例: 先進運転支援システム


Power

Processing System

Programmable Logic

m

Progra

Real-Time Processing

Security

Multimedia

Memory

Peripherals

System Software Configurations

Resource Isolationand Partitioning

Advanced Driver Assistance System (ADAS) Design Example

ystem

P

Re

Multimedia

ls

re s

Resoand Processing Sy

ySecurity

ource Isolationd Partitioning

yMemory

g

70

80

90

100

60

50

40

30

20

10

0

X18043-032917

この例では、システムソフトウェアコンフィギュレーション、リアルタイム処理、プログラマブルロジック、およ

びプロセッシングシステムが大値を示しています。したがって、このガイドでこれら 4 つのベクターについて説

明した各章を重点的に読み、 MPSoC のどの部分に注意を向ければよいか、そしてそれぞれの長所/短所および制限事

項を理解すればよいことになります。消費電力、セキュリティ、マルチメディア、ペリフェラル、およびリソース

分離/分割の必要性は平均的なレベルであるため、これらの領域に対する作業量はそれに応じて減らすことができま

す。その分だけ、製品にとってより重要なベクターに作業を集中できます。つまり、このガイドを使用すると要件

のレベルに応じてデザインの取捨選択をし、 Zynq UltraScale+ MPSoC ベースのデザインに対して労力とリソースのめ

りはりをつけた適化が可能となります。

注記: この図は、このガイドの各章の重要度を測る柔軟なツールとなるものですが、無視してよいベクターがあるわ

けではありません。このガイドの設計手法をすべて読んでから終的な設計判断を下す必要があります。




第 1 章: 概要

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

デザインクロージャの短時間での達成およびデザインの総合的な成功のためには、適切な情報にタイムリーにアク

セスできることが重要です。ザイリンクスのツールをなるべく短期間で習熟していただけるよう、リファレンスガ

イド、ユーザーガイド、チュートリアル、ビデオを用意しています。このセクションでは、資料およびトレーニン

グの入手先を示します。

Documentation Navigator の使用

ザイリンクスツールには Xilinx Documentation Navigator が付属します。ザイリンクスのソフトウェアおよびハード

ウェアに関連する資料、トレーニング、サポートマテリアルへのアクセスと管理はすべてこの環境から実行できま

す。 Documentation Navigator では、新および以前のバージョンのザイリンクス資料を参照できます。リリース、資

料タイプ、またはデザインタスクをフィルター条件に指定して資料を表示できます。検索機能を使用すると、必要

な情報をすばやく見つけることができます。

Documentation Navigator はザイリンクスのウェブサイトをスキャンして、資料の更新をチェックします。更新がある

場合は [Update Catalog] 機能で通知され、更新された文書の詳細が表示されます。カタログを新にするようメッ

セージが表示された場合は、カタログをアップデートして資料を新の状態にしておくことをお勧めします。資料

を指定してローカル資料カタログを作成および管理することもできます。

Documentation Navigator には、 [Design Hub View] というタブがあります。デザインハブは、 Zynq UltraScale+ MPSoC

デザイン概要、 PetaLinux ツール、ザイリンクスソフトウェア開発キット (SDK) などデザインアクティビティごとに

関連する資料を集めたものです。資料およびビデオがそのタスクを学びやすいように並べられています。各デザイ

ンハブには、 [Embedded Processor Design] セクションや [Design Resources] セクション、およびサポートリソースの

一覧などが表示されます。新規ユーザーは、 [Embedded Processor Design] セクションから始めることを推奨します (

図 1-4 参照)。




第 1 章: 概要

図 1‐4: Documentation Navigator





第 2 章

プロセッシングシステムシステム設計者にとって、 Zynq® UltraScale+™ MPSoC デバイスは内蔵のプロセッシング機能を非常に強力かつ柔軟

に利用できる利点があります。アプリケーションプロセッシングユニット (APU) およびリアルタイムプロセッシン

グユニット (RPU) を適宜構成できるだけでなく、 Zynq UltraScale+ MPSoC デバイスには各種タスクの処理に特化し

た専用のプロセッシングブロックがいくつかあります。この章では、 Zynq UltraScale+ MPSoC デバイスのプロセッ

シングシステムの機能、インターコネクト、およびその使用に関する推奨事項について説明します。

プロセッシング要件を定義する

近のエンベデッドデザインの多くはワークロード、制約、および外部への依存性が複雑に混在した上で成り立っ

ています。アプリケーションの個々のプロセッシング要件について、 Zynq UltraScale+ MPSoC デバイスが備える多く

のプロセッシングブロックの中でも処理に適したものを見つけることが、全体的な製品を成功させる上で非常に

重要です。次のセクションで Zynq UltraScale+ MPSoC デバイスの各プロセッシングブロックの基本概念を紹介した

後、この章全体で各ブロックおよび重要なコンポーネントについて詳しく説明していきます。

これらの説明に移る前に、まず目的のデザインに関して次の質問に答えてみてください。

1. そのアプリケーションの重大な要件は何ですか。それぞれの部分について次の質問に答えてください。

a. 時間的制約の厳しいデータを常時処理しますか。

b. リアルタイム性が必要、またはミッションクリティカルなワークロードですか。

c. マルチメディアに関係しますか。それとも汎用コンピューティングに属するワークロードですか。

d. プロセッシングシステムよりも高速な処理が必要ですか。

2. システムコンポーネント間でどのような通信が必要ですか。それぞれのコンポーネント間について次の質問に

答えてください。

a. データ交換が必要ですか。

b. 必要な場合、どれだけのデータをどの程度の頻度で交換しますか。

c. 重要なイベントを互いに通知する必要がありますか。

3. 外部世界との間でどのような通信が必要ですか。それぞれの部分について次の質問に答えてください。

a. メモリについてどのような要件がありますか。

b. 割り込みによってトリガーされますか。それとも割り込みに応答しますか。

c. ペリフェラル I/O を使用する必要がありますか。

4. 消費電力の制約が厳しいのはデザイン内のどのコンポーネントですか。




第 2 章: プロセッシングシステム

プロセッシングシステムの設計手法

Zynq UltraScale+ MPSoC デバイスは柔軟性が高いため、デバイスのプロセッシング機能を十分に理解してからデザイ

ンをマップする必要があります。そこで、第 1 章で示したシステム全体のブロック図から Zynq UltraScale+ MPSoC デ

バイスの主要なプロセッシングブロックおよびインターコネクトによるこれらの接続を抜き出した概略図を次に示

します。この図で、何らかの形でカスタマイズが可能なプロセッシングブロックは緑で示してあります。

図 2‐1: デバイス全体のプロセッシング可能ブロック


RPU PMU LPDPeripherals

Inter-ProcessorCommunication

Framework(OpenAMP)

APU GPU*

CSU

PL

FPDPeripherals

Full Power Domain

Low Power Domain

Programmable Logic Power Domain

PLPeripherals AcceleratorsAccelerators

* GPU support is OS-specific

X18660-032917

注記: 図 2-1 は Zynq UltraScale+ MPSoC デバイスの内部ブロックを正確に表現したものではなく、このセクションで

説明する概念を図にしたものです。

以降のセクションでは、 Zynq UltraScale+ MPSoC デバイスの主要なブロックの詳細、および関連する割り込み機能、

インターコネクト、および主なプロセッサ間通信メカニズムについて説明します。たとえばインターコネクトは種

類の異なる複数のブロックで構成されており、本来は各ブロックについて個別に説明が必要です。しかしここでは

システムの各部分のハイレベル機能に絞って説明します。

個々のデザインに存在するプロセッシング要件を見ると、それがどのような種類のものであれ、前のセクションの

質問内容からもわかるようにユーザーは次の点を制御できます。

• 処理の実行場所 (プロセッシングブロック )

• プロセッシングブロック間のインターコネクト





• 外部世界との通信

° メモリ

° 割り込み

° ペリフェラル I/O

処理の実行場所は、ワークロードの種類によって選択肢を絞り込むことができます。

表 2‐1: 各プロセッシングブロックに適したワークロード

ブロック適性理想的なワークロード

• Linux などのハイレベル OS のサポート

• ハイパーバイザーベースのコンピューティング

• 対称型マルチプロセッシングおよびスーパー

バイザー付き非対称型マルチプロセッシング

• HMI/UX

• ビジネスロジック

• ネットワーク /クラウドとの通信

• 確定的動作

• 低レイテンシのメモリアクセス

• 確定的な応答時間が必要とされるソフト

ウェア

• セーフティクリティカルソフトウェア

• 標準規格に準拠したソフトウェアスタック

(無線など)

• アプリケーションのアクセラレーション • アクセラレーション/並列化

• 各種エフェクト、変換、フィルタリング、

プロセッシング、エンコード /デコードの

ハードウェアアクセラレーション

• Linux 環境での 2D および 3D グラフィックスアクセラレーション

• ディスプレイ

• マルチメディア

これらは一般的なガイドラインであり、実際のデザインでは異なるアプローチが必要となることがあります。特定

のワークロードをどのプロセッシングブロックで処理すべきかは、次に示すデシジョンツリーでも判断できます。

APU

RPU

PL

GPU





図 2‐2: 処理の実行場所を求めるデシジョンツリー


Is it continuously processing time-sensitive data?

PL

Yes No

Is it real-time or mission critical?

Yes No

RPU

Is it multimedia?

Yes No

GPU* APU

Can it be optimized to PL?

Yes


X18706-032117

システムの各コンポーネントについて、この図に示した質問には簡単に答えることができるはずです。一定の時間

枠内でデータストリームまたは要求を継続的に処理する必要がある場合、これらのデータストリームや要求の処理

に関係するシステムコンポーネントの大半をプログラマブルロジック (PL) に置くのが適と考えられます。この条

件に当てはまらないワークロードのうち、外部イベントに対して確定的な (すなわちリアルタイムの) 応答が必要な

ワークロードやミッションクリティカルなワークロードは、 RPU での実行が適していると考えられます。これらの

条件に当てはまらないワークロードは汎用コンピューティングに属する問題と考えられます。これらは、グラ

フィックスに関係するものであればグラフィックスプロセッシングユニット (GPU) で処理し、それ以外は APU で

処理します。

また、上記の条件に当てはめて RPU または APU での処理が適切と判断したソフトウェアであっても、 PL で処理し

た方が適切な場合があります。たとえば FFT のように決まった数式で機能を実行するものや、既知のステートまた

はステートマシンで機能を実行するもの (そして特にこれらを並列に実行する場合) は PL の一部として内蔵するの

が適していると考えられます。

ある機能を PL で処理した方がよいかどうかは、手動によるテストとプロタイピングによって見積もることもできま

すが、ザイリンクスはより効果的な手段を提供しています。たとえば SDSoC™ およびザイリンクス SDK 開発ツール

にはアプリケーションコードのプロファイリング機能があり、特に SDSoC では特定のコードセクションを PL にオ

フロードして、ボタンをクリックするだけでパフォーマンステストを実行できます。 SDSoC は必要なロジックを自

動的に PL にコンパイルし、APU または RPU 側に残ったソフトウェアが PL で高速化されたソフトウェアを透過的に

利用できるようにするためのデータムーバーとソフトウェアドライバーを自動的に割り当てます。このように、

SDSoC を使用すると必要な手順が大幅に簡略化され、ソフトウェアアクセラレーションプロセスを円滑に進めるこ

とができます。したがって、 SDSoC を使用するか手動でオフロードするかは、インプリメンテーションの容易さと

ハンドコーディングによる性能適化のトレードオフで決めることになります。





もう 1 つ、各プロセッシングブロックの大クロック周波数も考慮する必要があります。

• APU – 大 1.5 GHz

• RPU – 大 600 MHz

• GPU – 大 667 MHz

注記: これらは大周波数であることに注意してください。各ブロックは上に示した周波数まで動作が可能ですが、

実際のデザインにおいてこれらのブロックを大周波数で常時動作させることは現実的ではありません。

Zynq UltraScale+ MPSoC デバイスの APU は ARM® Cortex®-A53 プロセッサを内蔵しているため、汎用コンピュー

ティングリソースとしてはも高性能です。特に Zynq UltraScale+ MPSoC デバイスでは Cortex-A53 プロセッサを

大 4 つ利用できるため、なるべく高い処理性能が必要なワークロードには APU が初の候補として挙げられます。

ただし、動作周波数が高いだけでは機能の実行に必ずしも有利とはいえません。たとえばリアルタイムワークロー

ドには APU の Cortex-A53 プロセッサよりも RPU の ARM® Cortex®-R5 プロセッサの方が適しています。APU と RPU

のどちらを選択するかは多くの要因を考慮して決める必要がありますが、特に性能と確定的動作のトレードオフは

重要な検討事項です。

ある機能の実行に適なブロックが決まったら、次に、インターコネクトを介してブロック間でデータを移動する

適な方法、および処理を実行する各ブロックがシステム内部の各種プロセッシングリソース、および外部世界の

インターフェイス / リソースとどのように通信するのかを決定する必要があります。インターコネクトと割り込みの

詳細は、この章で後述します。ペリフェラル I/O の詳細は、第 10 章「ペリフェラル」を参照してください。メモリ

の詳細は、第 6 章「メモリ」を参照してください。 PL 内蔵のアクセラレータなど、 PL の機能の詳細は、第 5 章「プ

ログラマブルロジック」を参照してください。

なお、このガイドラインで特定のプロセッシングブロックが候補に上がったとしても、デザインのその部分に関係す

るすべての内容を検討した結果、別のプロセッシングブロックの方が製品要件により適していると判断することも十

分にありえます。たとえば前出のデシジョンツリーでは、リアルタイムソフトウェアには RPU の使用が推奨されて

います。しかしデザインによっては APU でリアルタイムオペレーティングシステム (RTOS) を実行し、 Cortex-R5 プ

ロセッサでベアメタルを実行した方がよいこともあります。もう 1 つの例としてネットワーク通信があります。これ

までの説明に従うと、ネットワーク通信の実行には APU が適と考えられます。ただしそれは一般論で、 PL に内蔵

されている 100G イーサネットおよび PCIe 用の統合ブロックを組み合わせた方がより効率よく実行できることもあり

ます。ザイリンクスのホワイトペーパー『Zynq UltraScale+ MPSoC で圧倒的な低消費電力と柔軟性を実現』 (WP470) [

参照 10] では、データセンターアプリケーションの例を紹介しながら Zynq UltraScale+ MPSoC の柔軟性について説明

しています。また、この文書ではセントラル先進運転支援システム (ADAS) モジュールおよびソフトウェア無線

(SDR) の例も取り上げており、デザインの処理をどのように分割すればよいかの参考になります。

デザインの処理をどのプロセッシングブロックで実行するかを決める際にもう 1 つ考慮する必要があるのが、パ

ワーマネージメントの問題です。 Zynq UltraScale+ MPSoC デバイスのアーキテクチャでは、消費電力をきめ細かく

制御できます。 14 ページの図 2-1 に示した電源ドメインもパワーマネージメントの一部です。パワーマネージメン

トの詳細は、第 4 章「電源に関する注意事項」で説明します。あるワークロードを Zynq UltraScale+ MPSoC デバイ

スのどのプロセッシングブロックで実行するかを決める際には、必ず全体的なパワーマネージメントの要件との関

係を考慮する必要があります。たとえばある重要なアルゴリズムを APU で実行しているとして、ある一定時間 APU

への電源供給を停止したい場合、そのアルゴリズムの実行を PL または RPU に移す必要があります。前述のとおり、

APU はシステムの中でも強力なブロックといえますが、も消費電力が大きいブロックでもあります。





ヘテロジニアスコンピューティングの概念

Zynq UltraScale+ MPSoC デバイスおよびその周辺機能の処理能力を理解するには、ヘテロジニアスコンピューティ

ング分野に特有の重要な概念をいくつか理解しておく必要があります。したがって、ここではこの文書および Zynq

UltraScale+ MPSoC デバイスに関する資料全般で使用する用語について簡単に説明します。

Zynq UltraScale+ MPSoC デバイスには、マルチプロセッシングコンポーネント (互いに並列に動作するプロセッサ)

のレイヤーが大きく 2 つあります。初のレイヤーは、次の主要なプロセッシングブロックで構成されます。

• APU

• RPU

• PL

• GPU

2 番目のレイヤーとして、上記のブロック内部に次のプロセッシングユニットがあります。

• APU 内部: 2 つまたは 4 つの Cortex-A53 コア

• RPU 内部: 2 つの Cortex-R5 プロセッサコア

• PL 内部: PL に適化されたアプリケーション、および MicroBlaze™ プロセッサインスタンス

• GPU 内部: 複数のグラフィックス処理パイプライン

Zynq UltraScale+ MPSoC デバイスの主要コンポーネントどうしの関係は、一般に「非対称」と考えられます。つまり

APU、 RPU、 PL、 GPU はそれぞれ異なる長所と短所を備えており、実行する OS も同じとは限らず、ワークロード

をこれらブロック間でシームレスに移動することもできません。これらいずれかのコンポーネントを使用してワー

クロードを実行する場合は、使用するコンポーネントに合ったワークロードを作成する必要があります。これを非

対称型マルチプロセッシング (AMP) と呼びます。

APU 内部の Cortex-A53 プロセッサどうしの関係は、次の 4 つのいずれかの形態をとります。

• すべての Cortex-A53 プロセッサコアで Linux など同じ OS を実行する場合 (これも推奨構成の 1 つ)、これらは

互いに「対称な」関係にあるといいます。この場合、共通の OS である Linux は各プロセッサに対してワーク

ロード (実質的には OS プロセス) を透過的にディスパッチおよび移動できます。ソフトウェア開発の観点から

見ると、ソフトウェアがどの Cortex-A53 プロセッサで実行されるかにかかわらず、 OS の API 境界によってソ

フトウェアが同じように動作することが保証されます。このような動作の形態を対称型マルチプロセッシング

(SMP) と呼びます。

• Cortex-A53 プロセッサを独立して動作させるのは同じでも、オープンソースの Xen や商用の各種ハイパーバイ

ザーを使用して全体の動作を管理する場合、これらは互いに「スーパーバイザー付き」非対称な関係にあると

いいます。この場合、ハイパーバイザーが複数の Cortex-A53 プロセッサを管理するスーパーバイザーとして動

作することにより、各 Cortex-A53 プロセッサ上で並列に動作する独立したソフトウェアスタック間に両者が共

通に同意したアービタが存在することになります。アプリケーションの種類によっては、 APU をスーパーバイ

ザー付き AMP モードで使用することを第 3 章「システムソフトウェアの検討事項」では推奨しています。

• APU のハードウェアではハイブリッド構成も可能です。ハイパーバイザーを使用して Cortex-A53 プロセッサの

一部をスーパーバイザー付き AMP モードにし、残りのコアを SMP モードで 1 つの OS イメージを使用して一括

管理するという方法です。ただしこれは高度な構成であるため、ザイリンクスは提供もサポートもしていません。





• 各 Cortex-A53 プロセッサが独立して動作しており、共通の OS またはハイパーバイザーなしでそれぞれが異な

るシステムソフトウェアを実行している場合も、これらは互いに非対称な関係と見なされます。より厳密には、

この形態では、各 Cortex-A53 プロセッサの動作を管理する単一のソフトウェアが存在しないため、「スーパーバ

イザーなし」 AMP モードと呼ばれます。ただし Cortex-A53 プロセッサでのスーパーバイザーなし AMP 構成は

複雑なため、 APU の構成としてザイリンクスは推奨もサポートもしていません。詳細は、第 3 章「システムソ

フトウェアの検討事項」を参照してください。

Zynq UltraScale+ MPSoC デバイスは多くの種類のプロセッサおよびプロセッサコアを 1 つのデバイスに統合している

ため、そのコンピューティング環境を「ヘテロジニアス」コンピューティングと呼びます。このため、 Zynq

UltraScale+ MPSoC デバイスでは多くのプロセッサおよびプロセッサセットとほかのブロックまたは同じブロック内

のほかのプロセッサとの関係が、これまで述べたようにさまざまな形で存在します。

次に、ここまでの説明を簡単にまとめます。

• SMP: APU 内の複数のプロセッサコアを 1 つの OS で管理する方式

• AMP: 各プロセッシングブロックが互いに独立して動作する方式

° スーパーバイザー付き : 複数の AMP ブロックの動作をハイパーバイザーで管理する方式

° スーパーバイザーなし : 複数の AMP ブロックの動作を管理する単一のアービタが存在しない方式

• ヘテロジニアスコンピューティング: 種類の異なる複数のプロセッサを 1 つのデバイスに統合したもの





アプリケーションプロセッシングユニット (APU)

Zynq UltraScale+ MPSoC デバイスの APU は、使用する製品により 2 つまたは 4 つの Cortex-A53 プロセッサを内蔵し

ています。

図 2‐3: アプリケーションプロセッシングユニット (APU) のブロック図


各 Cortex-A53 プロセッサには、主に次の機能があります。

• ARMv8-A アーキテクチャをサポート

• 64 または 32 ビット動作

• 大 1.5 GHz の性能

• 独立したメモリ管理ユニット (MMU)

• 専用 L1 キャッシュ

• 個別のパワーゲーティング

• ARM TrustZone をサポート

• VFPv4 FPU を実装

• NEON および Crypto API をサポート

注記: 全機能の一覧は、 Zynq UltraScale+ MPSoC デバイスのデータシートおよび『Zynq UltraScale+ MPSoC テクニカ

ルリファレンスマニュアル』 (UG1085) [参照 7] を参照してください。

第 3 章「システムソフトウェアの検討事項」で説明するように、 Cortex-A53 プロセッサはほかのコンピューティン

グプラットフォームと同じハイエンドの汎用コンピューティング性能を備えており、ハイエンドの汎用アプリケー

ションおよび OS を実行できます。 Cortex-A53 プロセッサの各コアはほぼ完全に独立していますが、 APU を正しく

動作させるには後述するグローバル割り込みコントローラー (GIC) など APU の一部のリソースについて、すべての

Cortex-A53 プロセッサに対してコヒーレンシが維持されるように管理する必要があります。





次に、 APU の詳細なブロック図を示します。

図 2‐4: APU の詳細なブロック図


APU

GIC

Cortex-A53 MPCore

Cortex-A53

FPU/NEON/Crypto

32K L1ICache

32K L1DCache

Debug/Timers

Cortex-A53

FPU/NEON/Crypto

32K L1ICache

32K L1DCache

Debug/Timers

Cortex-A53

FPU/NEON/Crypto

32K L1ICache

32K L1DCache

Debug/Timers

Cortex-A53

FPU/NEON/Crypto

32K L1ICache

32K L1DCache

Debug/Timers

Snoop Control Unit (SCU)

L2 Cache 1MB

IRQ/vIRQFIQ/vFIQ

Timers Interrupts

System Counter (in LPD) FPD Core Switch CoreSightSPI Interrupts

64-bit counter

AP

B, TS

ATB

32-bit AXI

128-bit ACPCCI

128-bit ACE

APU のソフトウェア動作の詳細は、第 3 章「システムソフトウェアの検討事項」および『Zynq UltraScale+ MPSoC

ソフトウェア開発者向けガイド』 (UG1137) [参照 5] を参照してください。ここからは APU のプロセッシング機能に

ついて説明します。

APU における SMP

ザイリンクスはオープンソースの Linux を提供しています。この中に含まれるカーネルは SMP をサポートしてお

り、開発者のニーズに合わせて構成することもできます。カーネルの構成により、 OS の SMP 機能で使用する CPU

コアの数を開発者が指定できます。利用可能なコアより少ない数を指定し、下層にハイパーバイザーを導入すると、

残りのコアをザイリンクス SDK で作成したカスタムベアメタルアプリケーションなど、ほかのアプリケーション

実行に割り当てることができます。

APU のスーパーバイザーなし AMP

APU をスーパーバイザーなし AMP で使用する場合、まず制御を初のプロセッサに渡し、このプロセッサがほかの

プロセッサ上で特定の OS をブートしてワークロードを実行します。この動作モードでは、リソース共有を開発者自

身で実装する必要があります。前述のとおり、この実装は非常に複雑であるため、 Zynq UltraScale+ MPSoC デバイス

のユースケースとしてザイリンクスは推奨もサポートもしていません。





APU のスーパーバイザー付き AMP

APU でハイパーバイザーを使用すると、利用可能なコア上で種類の異なる OS やベアメタルワークロードを実行で

きます。使用するハイパーバイザーおよびユーザーニーズに応じて、動作するゲストに対してリソース共有の管理

を透過的に実行すること (完全仮想化) も、半透過的に実行すること (準仮想化) も可能です。仮想化サポートについ

ては、次のセクションで説明します。

64 または 32 ビット動作

Cortex-A53 プロセッサは ARMv8 仕様に準拠しており、 64 ビット (AArch64) および 32 ビット (AArch32) 実行モード

のどちらでも動作します。各モードの制限事項は、 ARM アーキテクチャの仕様に準じます。 Zynq® UltraScale+™

MPSoC の AArch32 実行モードは Zynq 7000 デバイスファミリおよび ARMv7 仕様との互換性を維持しつつ、SIMD や

暗号化など ARMv8 の一部の機能をサポートするように拡張されています。どちらの実行モードを選択するかは、通

常、デバイスで実行するソフトウェアに応じて決定します。

ハイパーバイザーモードで AArch32 と AArch64 のどちらを使用するかは、ハイパーバイザーが使用する実行ステー

トによって決まります。

• 64 ビットハイパーバイザーは、 AArch64 または AArch32 モードで動作するオペレーティングシステムカーネ

ルを実行できます。なお、ハイパーバイザーが AArch64 モードで動作していても、 OS カーネルが AArch32

モードで動作している場合は AArch32 モードのアプリケーションしか実行できません。

• 32 ビットハイパーバイザーは、 AArch32 モードの OS およびアプリケーションしか実行できません。

APU の仮想化サポート

Zynq UltraScale+ MPSoC デバイスは 4 つの主要なコンポーネントでハードウェア仮想化をサポートしています。その

うちのいくつかは、 Xen ハイパーバイザーなど Zynq UltraScale+ MPSoC デバイス用に設計されたシステムソフト

ウェアによって既に利用されています。 Zynq UltraScale+ MPSoC デバイスをベースにしたシステムをより効果的に設

計するには、これらの機能を理解する必要があります。

Cortex‐A53 プロセッサの仮想化

通常、 APU における仮想化サポートは Cortex-A53 プロセッサの ARMv8 アーキテクチャ仕様で定義された例外レベ

ル (EL) の 1 つを使用して実装します。 ARMv8 でサポートされる EL は 4 つあり、サポートされるハイパーバイザー

は EL2 を使用してハイパーバイザーのコンテキストをゲスト OS から隔離します。 Cortex-A53 プロセッサの EL の詳

細は、第 7 章「リソースの分離と分割」の「ARM TrustZone」セクションで説明します。





図 2‐5: TrustZone の例外レベル


Non-secure State

App1

AArch64 orAArch32(1)

App2


App1


App2


Supervisor (Guest OS1)

AArch64 or AArch32(2)



Hypervisor Mode

AArch64 or AArch32

EL0

EL1

EL2

SVC

HVC

SMC

Secure Monitor Mode

Supervisor (Secure OS)

AArch64 or AArch32

Trusted App1


Trusted App2


EL3

Secure State

X15288-032917

割り込みの仮想化

割り込みの仮想化は 37 ページの「APU の割り込み仮想化」で説明します。





システム MMU による I/O 仮想化

システム MMU (SMMU) はソフトウェアで管理されるテーブルに基づいてアドレス変換を自動で実行し、 I/O および

ハイパーバイザーで使用するアドレスの仮想化を簡略化します。次の図に、 SMMU によるアドレス仮想化の例を示

します。

図 2‐6: SMMU の使用例


Cache Coherent Interconnect

Memory

Device1 Device2

Interconnect

Device3 Device<n>

Interconnect

SMMU S2 SMMU S1/2 SMMU S1/2

CPU0 CPU1-3

MMU S1/2

L1 Cache

MMU S1/2

L1 Cache

GPU

MMU S1

Cache

Coherent Interconnect

L2 Cache

X15290-092916

SMMU は 2 つのステージで動作します。これを上の図では「S1」、「S2」、または「S1/S2」と示しています。

• ステージ 1:

このステージの動作は、従来のシングルステージの CPU MMU と同じです。仮想アドレス (VA) を取得して、中

間物理アドレス (IPA) に変換します。

• ステージ 2:

ハイパーバイザー環境では、このステージによってゲスト OS はハイパーバイザーに接続して要求を発行しなく

てもシステム内の DMA 対応デバイスを直接設定できるようになるため、ハイパーバイザーの設計が簡略化され

ます。このステージでは、 SMMU は IPA を取得して物理アドレス (PA) に変換します。





次の図に、ハイパーバイザー環境における SMMU のアドレス仮想化を示します。

図 2‐7: SMMU のアドレス変換ステージ


B2

A0 A1

Guest OS0

B0 B1

Guest OS0

Hypervisor

CPUMMU

Memory Accessing Devices

System Memory

SystemMMU

B2

Gue

st O

Sm

4GB

B2

B2

0

4GB

Sto

ge 1

Add

ress

Tra

nsla

tion

Under control of Guest OS

A2

A2

Gue

st O

Sm

4GB

A2

A2

0Sta

ge 1

Add

ress

Tra

nsla

tion

Intermediate PhysicalAddress (IPA) Space

Virtual Address (VA) Space

4GB

B2

4GB

A2

B2

A2

Sta

ge 2

Add

ress

Tra

nsla

tion

Physical Address (PA) Space

0

0

X15291-032917

SMMU には、後述する Zynq UltraScale+ MPSoC デバイスのインターコネクトに接続する重要なコンポーネントとし

て次のものがあります。

• 変換バッファーユニット (TBU): アドレス変換に使用

• 変換制御ユニット (TCU): アドレス変換を制御および管理

第 7 章「リソースの分離と分割」で詳細を説明します。

ペリフェラルの仮想化

一般に、ハイパーバイザーは SMMU を使用してゲストが DMA 対応デバイスを排他的に所有できるようにします。

システムデザインで 1 つのハードウェアデバイスを複数のゲスト OS で共有したい場合は、準仮想化と呼ばれる手

法を使用します。そのためには、デバイスを共有するすべての OS に新しいデバイスドライバーが必要となります。

共有したデバイスのスループットは、 SMMU によってマップされた排他所有のデバイスよりもスループットが低く

なります。

タイマーの仮想化

ARM プロセッサには、各種タスクに対応した汎用ハードウェアタイマーが複数あります。 1 つのタイマーは、シス

テムのグローバルな時間経過を計算します。この汎用タイマーは、システム設定または CPU 周波数に応じたレート

でインクリメントするカウンターに関連付けられています。各 CPU コアには、システムカウンター値を格納する物

理カウンターがあります。各 CPU コアには仮想時間を示す仮想カウンターもあります。この仮想カウンターは、仮

想マシンに割り込みが発生して制御がハイパーバイザーに戻ると、値が保存されて一時停止します。カウンター値

へのアクセスは、実行レベルに応じて OS によって制御できます。





リアルタイムプロセッシングユニット (RPU)

Zynq® UltraScale+™ MPSoC には 2 つの Cortex-R5 プロセッサが内蔵されています。通常、これらは確定的な低レイテ

ンシの動作が必要とされる処理や、応答時間の要件が厳しいアプリケーションに使用されます。

図 2‐8: リアルタイムプロセッシングユニット (RPU) のブロック図


各 Cortex-R5 プロセッサには、主に次の機能があります。

• ARMv7-R アーキテクチャをサポート

• 32 ビット動作

• 大 600 MHz の性能

• 専用 L1 キャッシュ

• 128 KB の ECC (エラー訂正符号) 付き密結合メモリ

• 単精度および倍精度 FPU

APU の場合と同様、 Cortex-R5 プロセッサも独立して動作させることができますが、 RPU を正しく動作させるには後

述するグローバル割り込みコントローラーなど RPU の一部のリソースについて、両方の Cortex-R5 プロセッサに対

してコヒーレンシが維持されるように管理する必要があります。

Cortex-R5 プロセッサは、必要に応じて 2 つの動作モードのいずれかを選択できます。

• スプリットモード /スーパーバイザーなし AMP:

Cortex-R5 プロセッサのデフォルトモードで、パフォーマンスモードとも呼ばれます。このモードでは、前述

のように割り込みコントローラーを除いて各コアが独立して動作します。スプリットモードでは、 1 つのコア

で RTOS を実行しながらもう 1 つのコアでベアメタルを実行したり、 2 つのコアで別々の RTOS を実行したりで

きます。 APU とは異なり Cortex-R5 プロセッサはハイパーバイザーをサポートできないため、このモードでの

そのような構成はすべてスーパーバイザーなし AMP に分類されます。 Cortex-R5 プロセッサ間の通信は、ザイ

リンクスベアメタルライブラリを使用して単純に割り込みを渡してメモリを共有するか、 OpenAMP フレーム

ワークで提供される各種の高度な機能を利用して実装します。詳細は、『Zynq デバイス向け OpenAMP フレーム

ワーク : スタートアップガイド』 (UG1186) [参照 8] を参照してください。





• ロックステップモード :

セーフティモードとも呼ばれるこのモードでは、 Cortex-R5 プロセッサは、 RPU 以外のシステムから見るとシン

グル CPU として動作します。ただし内部では、 2 つのコアが同じ命令を並列に処理します (シングルイベント

アップセットを検出できるように 1 ½ クロックサイクルの遅延がある )。 2 つのコアからの出力が異なる場合、

比較/同期ロジックで検出してエラー通知信号を出力し、これを受けてカスタム応答を実行します。たとえば改

ざんによってロックステップコアの動作が食い違った場合には、これに応答してシステムのシャットダウンや

ロックアウトを実行できます。次の図に、このモードにおける RPU の動作を示します。

図 2‐9: Cortex‐R5 プロセッサのロックステップ動作


TCMs Associated with CPU1

TCM A

TCM B

TCMs Associated with CPU0

TCM A

TCM B Shim

Shim

GIC

Cortex-R5CPU0

Cortex-R5CPU1

Caches Associated with CPU0

D-Cache

I-Cache

Comparison and Synchronization Logic

X15295-092916

ミッションクリティカルなアプリケーションや機能安全アプリケーションでシングルイベントアップセットの検出

が必要な場合は、ロックステップモードを推奨します。これに対し、 2 つの Cortex-R5 プロセッサによりアプリケー

ションの性能を大限に高めたい場合は、デフォルトのスプリットモードが適しています。

第 4 章「電源に関する注意事項」で説明するように、 Cortex-R5 プロセッサは「電源アイランド」の一部であり、ま

とめてパワーゲーティングできます。ただし個別にはパワーゲーティングできません。

RPU の詳細は、「リアルタイムプロセッシングユニット (RPU)」の章で説明します。





インターコネクト

Zynq UltraScale+ MPSoC デバイスのヘテロジニアスアーキテクチャの中心にあるのがインターコネクトです。イン

ターコネクトはすべてのプロセッシングブロックを接続し、これらのブロックがアクセスペリフェラル、デバイス

およびメモリを介して外部世界と通信できるようにします。したがって、システムを適化するにはインターコネ

クトの機能を理解しておく必要があります。

Zynq UltraScale+ MPSoC デバイスのインターコネクトは ARM 社の AMBA (Advanced Microcontroller Bus Architecture)

4.0 仕様の一部として定義された AXI (Advanced eXtensible Interface) をベースに、キャッシュコヒーレントインター

コネクト (CCI-400) や CoreLink NIC-400 ネットワークインターコネクトなど多くの関連する ARM テクノロジを採用

しています。 ARM 社は、これらのテクノロジの詳細を仕様および資料の形で公開しています。ここでは、 Zynq

UltraScale+ MPSoC デバイスのインターコネクトを個々のニーズに合わせてカスタマイズできるようになる上で押さ

えておくべき基本的な概念のみを簡単に紹介します。

AXI インターフェイス

Zynq UltraScale+ MPSoC では、ブロックのペアを接続する手段として主に AXI インターフェイスを使用します。基

本的に、 AXI インターフェイスは 1 つの AXI マスターを 1 つまたは複数の AXI スレーブに接続します。マスターが

スレーブに対して要求を発行し、スレーブがこの要求を実行します。各 AXI インターフェイスは、次の 5 つのチャ

ネルで構成されます。

• 読み出しアドレスチャネル

• 書き込みアドレスチャネル

• 読み出しデータチャネル

• 書き込みデータチャネル

• 書き込み応答チャネル





次の図に、マスターとスレーブ間の通信をまとめます。

図 2‐10: AXI マスターとスレーブの通信: 読み出しチャネル


Masterinterface

Read address channelAddress

andcontrol

Read data channel

Readdata

Readdata

Readdata

Readdata

Slaveinterface

X12076

図 2‐11: AXI マスターとスレーブの通信: 書き込みチャネル


Masterinterface

Write address channelAddress

andcontrol

Write data channel

Writedata

Writedata

Writedata

Writedata

Writeresponse

Write response channel

Slaveinterface

X12077

Zynq UltraScale+ MPSoC デバイスの各ブロックには、多くのインターフェイスマスターとスレーブを含めることが

できます。 Zynq UltraScale+ MPSoC デバイスでは多くのコンポーネントが複雑に関係し合っているため、マスターと

スレーブを直接接続することはほとんどありません。 Zynq UltraScale+ MPSoC デバイスにはいくつかの戦略的なポイ

ントにスイッチが配置されており、これを利用して各種ブロックが相互に接続します。これにより、 Zynq

UltraScale+ MPSoC デバイスで重視されるパワーマネージメント、セキュリティ、分離、全体的な柔軟性が維持され

ます。





トラフィック優先度とコヒーレンシ

Zynq UltraScale+ MPSoC デバイスでは常時非常に多くの並列トラフィックが発生しています。インターコネクトに接

続した多くのブロックが同時にメモリにアクセスする一方、トラフィックの優先度はプロセッシングブロックおよ

びリソースにより異なります。したがって、トラフィックに優先度を割り当てると同時に、メモリへのトラフィッ

クのコヒーレンシを維持する仕組みが必要です。

インターコネクトスイッチを流れるトラフィックにはすべて同じ優先度が割り当てられるわけではありません。

Zynq UltraScale+ MPSoC デバイスのインターコネクトを流れる AXI トラフィックには、次の 3 つの優先度のいずれか

が割り当てられます。

• 低レイテンシ (高優先度)

通常、このタイプのトラフィックはほかのタイプのトラフィックよりも優先的に処理する必要があります。こ

れには APU と RPU、およびメモリ間のトラフィックが該当します。

• 高スループット (ベストエフォート )

このタイプのトラフィックはある程度のレイテンシは許容できますが、非常に高いスループットを必要としま

す。これには GPU や PL が該当します。

• アイソクロナス (ビデオクラス)

このタイプのトラフィックは、一部の重要なタイミングを除いて長いレイテンシを許容できます。一般的には、

ビデオ/イメージデータが該当します。タイムアウトが発生しそうになると、このトラフィッククラスに高の

優先度が割り当てられます。





次に、 Zynq UltraScale+ MPSoC デバイスのインターコネクトとトラフィッククラスの概略図を示します。

図 2‐12: インターコネクトとトラフィッククラスの概略図


図に示したデフォルトのトラフィッククラスは、「LL」が低レイテンシ、「BE」がベストエフォート、「V」がビデ

オクラスです。この図に示したブロックの多くは、この章またはこのセクションで説明したものです。 TBU および

TCU ブロックは、前のセクションで説明した SMMU の一部です。したがって、この図は SMMU とインターコネク

トの緊密な関係を示しています。

Zynq UltraScale+ MPSoC デバイスのインターコネクトでスイッチ以外の重要なコンポーネントとして、キャッシュ

コヒーレントインターコネクト (CCI) があります。これは、 Zynq UltraScale+ MPSoC デバイス全体でメモリトランザ

クションのコヒーレンシを維持するものです。





次の図に、 CCI の役割を示します。

図 2‐13: CCI の役割


詳細図

Zynq UltraScale+ MPSoC デバイスのインターコネクトには、ここまで述べてきたコンポーネント以外にも重要なサブ

モジュールがいくつかあります。

• AXI タイムアウトブロック :

スレーブからの応答がない場合にマスターがハングするのを防止します。

• AXI 分離ブロック (AIB):

システムブロック間のパワーダウン遷移を管理します。

• XMPU/XPPU:

マスターブロックとスレーブブロックを分離します (第 7 章「リソースの分離と分割」参照)。

• AXI トレースマクロセル (ATM):

アドバンストトレースバス (ATB) を使用して CoreSight 用の AXI トレースを取得します。

• AXI パフォーマンスモニター (APM):

AXI パフォーマンスメトリクスをキャプチャします。





ここまでの説明をふまえ、次に Zynq UltraScale+ MPSoC デバイスのインターコネクトの詳細図を示します。

図 2‐14: Zynq UltraScale+ MPSoC デバイスのインターコネクト (詳細図)


8

16

16

16

OCM

RPU

USB1

IOU

LPD-DMA

CS-DAP

CSU

Slaves

GIC

APU

ADB ADB

CCI-400TBU

2

TCU

Programmable Logic (PL)

Dis

play

Por

t

TBU

0TB

U1

FPD

-DM

A

PC

Ie

GP

U

SAT

AG

IC/T

CU

Sla

ves

TBU3 TBU4 TBU5

Core Switch

DDR Subsystem

2 x

64-b

it

S_AXI_LPD

USB0

OC

M

AXI Stream

XMPU

XPPU

ATM

PMU

AXI Stream

M_AXI_HPM0_LPDS_AXI_LPDS_AXI_ACP_FPDS_AXI_ACE_FPD

QoS-400

AXI Isolation Block

AXI Timeout Block

ATM+APM

S_AXI_HPC[0:1]_FPD S_AXI_HP[0:3]_FPD

AIB

ATB

AIB

AIB

AIB

AIB

ATB

AIB

AIBAIB

AIB

AIB

ATB

ATB

AIB

M_AXI_HPM0/1_FPD

AIB

AIB

ATB

64-bitM S

128-bitM S

AcronymsADB: AMBA Domain Bridge; TCU: Translation Control Unit; TBU: Translation Buffer Unit

16 16 161616 16

8

16

8 8

32

3232

32

32

28

16

ATB

16

1614,8

88

8 8

S3

S2

S1

S0S4

S3

M0M1M2DVM

S5S4S2S1S0

16The following markings designate the read/write capability of the bus. Where an example value of 16 designates 16 reads and 16 writes. Two values (for example 14,8) designates 14 reads and 8 writes. 14,8

X15277-100116

CoreSight

サービス品質 (QoS)

上の図に示したインターコネクトでもう 1 つ重要なのがサービス品質 (QoS) です。 QoS に関係するシステムブロッ

クには、インターコネクトスイッチと CCI の 2 つがあります。

スイッチを利用した QoS

上の図をよく見るとわかるように、ほとんどのスイッチが QoS-400 に対応しています。 QoS-400 は前述の CoreLink

NIC-400 規格を ARM 社が拡張したもので、 Zynq UltraScale+ MPSoC デバイスはこれをスイッチインターコネクトに

使用しています。 QoS-400 レギュレータはインターコネクトのほとんどの AXI マスターに割り当てられます。

注記: QoS-400 「レギュレータ」とは、 AXI マスターに関連付けられてマスターの動作を制御するブロックを表す用

語として ARM 社の資料で使用されています。

このレギュレータの働きにより、各 AXI マスターに対して次の制限を加えることができます。

• 未処理トランザクションの大数

• コマンド発行レート





CCI を利用した QoS

Zynq UltraScale+ MPSoC デバイスで使用する CCI-400 には、優先度の異なる 2 つのトラフィッククラスによって生成

された要求がメモリにアクセスした際にヘッドオブラインブロッキング (HOLB) が発生するのを防ぐ QoS 仮想ネッ

トワーク (QVN) 機能があります。次の図に、このような状況を示します。

図 2‐15: CCI を利用した QoS


CCI-400

LL Traffic BE Traffic

DDR ControllerPort 1 Port 2

X15889-101816

この場合、 CCI を通過する一方のトラフィックは低レイテンシ (LL) としてタグ付けされ、もう一方のトラフィック

はベストエフォート (BE) としてタグ付けされます。低優先度の BE トラフィックが DDR ポートを占有して高優先度

の LL トラフィックがアクセスできなくなると HOLB が発生します。 QVN は 2 つの DDR ポートに異なるキューと

トークンを使用してトラフィックのアービトレーションを実行することで、 HOLB による遅延を防ぎます。

APU は事前に割り当てられた 1 つの DDR ポートを使用するのではなく、前のセクションの図に示したように CCI-400

を経由して 2 つの DDR ポートを常時切り替えながら使用しているため、 QVN の恩恵を受けることができます。

APU のトラフィックは一般に LL で、 CCI を共有するその他のトラフィックはほとんどが BE であるため、ここで説

明したように QVN を使用すると APU は常に適切な QoS でメモリにアクセスできます。

QoS のカスタマイズ

ほとんどの場合、 Zynq UltraScale+ MPSoC デバイスのデフォルトの QoS 設定を変更する必要はありません。ただし

デフォルトのままでは問題があり、 QoS-400 レギュレータの一部を調整したいこともあります。その場合は、まず

前述の APM や ATM として内蔵されているデータ収集機能を使用してください。『ザイリンクスソフトウェア開発

キット (SDK) ユーザーガイド : システムパフォーマンス解析』 (UG1145) [参照 11] では、無償で利用可能なザイリン

クスソフトウェア開発キット (SDK) のパフォーマンスモニター機能を使用してトラフィックをモデル化し、 Zynq

UltraScale+ MPSoC デバイスからライブランタイム情報を取得する方法を紹介しています。同じことは SDSoC 開発

環境でも実行できます。これはザイリンクスのユニークな機能で、 APU からだけでなく Zynq UltraScale+ MPSoC デ

バイスのすべての内部ブロックを接続するインターコネクトからも情報を取得できます。





これらのツールから得られたデータを使用して、前出のインターコネクト詳細図を見ながらシステム内のホットパ

スを見つけ出し、必要に応じてその設定を調整します。この作業ではまず、 AXI マスターからのトラフィックのう

ち、低優先度のマスターからのトラフィックによって影響を受けているものがないかどうかを調べます。次に、重

要度の低い AXI マスターに対応する QoS-400 レギュレータを調整してスロットリングを実装します。たとえば APU

および RPU からのトラフィックの方が PL のトラフィックよりも優先度が低い場合、 PL からのトラフィックを優先

するように APU および RPU のレギュレータを設定します。ただしこのような調整を正しく行うには、 Zynq

UltraScale+ MPSoC デバイス内のトラフィックフローを十分に理解しておく必要があります。

QoS のカスタマイズは、デフォルト設定では実際のデザインで問題が生じる場合にのみとどめてください。

PL インターフェイス

Zynq UltraScale+ MPSoC デバイスのインターコネクトで設計者が完全に制御できるものの 1 つに、 PL とそれ以外のシ

ステムの接続があります。前出のメインインターコネクトの図にも示したように、 PL からインターコネクト (すなわ

ちシステム全体) への接続にはいくつかのパスがあります (詳細は第 5 章「プログラマブルロジック」でも後述)。

第 5 章では、このセクションで前述した内容をさらに詳しく説明します。

その他の情報

インターコネクトの詳細は、『Zynq UltraScale+ MPSoC テクニカルリファレンスマニュアル』 (UG1085) [参照 7] のイ

ンターコネクトに関する章、および次の項目に関する ARM 社の公式文書を参照してください。

• AMBA 4.0: AXI 規格のコア仕様

• NIC-400: スイッチインターコネクト

• CCI-400: キャッシュコヒーレントインターコネクト

• QoS-400: NIC-400 に QoS を追加したもの





割り込み

Zynq UltraScale+ MPSoC デバイスは多くの機能を集積したヘテロジニアス設計を採用しているため割り込みソースの

数が非常に多く、割り込みを処理する方法もいくつかあります。たとえばイーサネット、 USB、 GPU、 DisplayPort、

DMA、 UART、 SPI、 SD など、内蔵ペリフェラルのほとんどが割り込みをトリガーして重要なイベントをプロセッ

サに通知します。 PL も 16 種類の割り込みをトリガーできます。

また、 Zynq UltraScale+ MPSoC デバイスには設定可能なプロセッサ間割り込み (IPI) があり、これを使用して独立し

たプロセッシングブロックどうしを通信させることができます。

Zynq UltraScale+ MPSoC デバイスには APU 用と RPU 用に合計 2 つの割り込みコントローラーがあります。APU の割

り込みコントローラーは ARM GICv2 (Generic Interrupt Controller version 2) 仕様に準拠し、RPU の割り込みコントロー

ラーは ARM GICv1 仕様に準拠しています。 GICv2 の利点として、 APU では割り込み仮想化がサポートされます。

次に、 Zynq UltraScale+ MPSoC デバイスの割り込みの接続図を示します。

図 2‐16: Zynq UltraScale+ MPSoC デバイスの割り込み接続


Cortex-A53 MPCore

CPU0 CPUn

CPU0 I/FVCPU0 I/F CPU0 I/FVCPUn I/F

Distributor

RPU Cores

CPU0 CPU1

GIC (PL390)CPU0 I/F CPU1 I/F

Distributor

niRQ0/nFIQ0nViRQ/nVFIQ

niRQ0/nFIQ0 niRQ1/nFIQ1

Interrupt Source Blocks (e.g., VCU, GPU,

DisplayPort)

PCIeTop Level IPI

PCIe Inbound

To Interconnect

To PMU

To PL

To PMU

To PMU

MSI

Legacy IRQ/FiQ per CPUFrom PL

APU

GIC-400

X15327-092816

この図で、 APU の GICv2 割り込みコントローラーは「GIC-400」、 RPU の GICv1 割り込みコントローラーは「GIC

(PL390)」として示しています。





APU の割り込みコントローラー

各 Cortex-A53 プロセッサには、入力として次に示す 4 つの割り込みラインがあります。

• nIRQ: 通常優先度の割り込み

• nFIQ: 高優先度の高速割り込み

• nVIRQ: 通常優先度の仮想割り込み (APU で仮想化をサポートするために使用)

• nVFIQ: 高優先度の仮想割り込み (APU で仮想化をサポートするために使用)

次の図に、 APU の割り込みコントローラーによる Cortex-A53 プロセッサの割り込み処理を示します。

図 2‐17: APU の割り込みコントローラー


割り込みコントローラーは 2 つの部分で構成されます。 1 つはディストリビューターで、受信した割り込みを登録し

て優先度を割り当てた後、適切な CPU に分配します。もう 1 つの部分は各 CPU の割り込みラインに接続し、適切な

Cortex-A53 プロセッサに対して実際の割り込みをトリガーします。

割り込みコントローラーは、次に示す 3 つのタイプの割り込みを処理します。

• コア間で割り込みを送信するためのソフトウェア生成割り込み (SGI) が 16 個

• 1 つの Cortex CPU コアをターゲットにしたプライベートペリフェラル割り込み (PPI) が 7 個

• すべての APU および RPU コアで共有する共有ペリフェラル割り込み (SPI) が 92 個

APU の割り込み仮想化

APU がハイパーバイザーを実行中に割り込みを受信すると、ハイパーバイザーは APU の割り込みコントローラーと

通信し、次の図に示すようにゲスト OS に対して仮想割り込みを生成します。これらの割り込みはゲスト OS に直接

送信され、ゲスト OS が割り込みを処理してクリアします。ゲスト OS 以外に対する割り込みは、ハイパーバイザー

がローカルに処理してクリアします。





図 2‐18: APU の割り込み仮想化


RPU の割り込みコントローラー

RPU の GICv1 割り込みコントローラーは、次の図のように Cortex-R5 プロセッサに接続されます。この割り込みコ

ントローラーは APU のものに似ていますが、仮想割り込みはサポートしていません。また、前述の割り込みタイプ

(SGI、 PPI、 SPI) に対してそれぞれ処理できる割り込みの数も少なくなっています。

図 2‐19: RPU の割り込みコントローラー






セキュアステートと割り込み

第 7 章「リソースの分離と分割」で説明するように、インターコネクト経由で接続される Zynq UltraScale+ MPSoC

デバイスのすべてのブロックは、 ARM TrustZone 仕様に基づいてセキュアまたは非セキュアのいずれかに分類され

ます。詳細は第 7 章で説明しますが、 APU と RPU の割り込みコントローラーはどちらも割り込みをトリガーする側

がセキュアか非セキュアかを区別しません。慣例により APU の FIQ はセキュアモニターに送信されますが、これは

ソフトウェアによる選択であり、ハードウェア要件ではありません。

プロセッサ間割り込み

プロセッサ間割り込み (IPI) は Zynq UltraScale+ MPSoC デバイス内のプロセッシングブロック間の通信基盤となるも

ので、リモートプロセッサに対して割り込みを送信するためのチャネルを提供します。また、ある程度のペイロー

ドも転送できます。 IPI の主な使用例として、パワーマネージメントがあります。フル電力ドメインへの電源供給が

停止した場合、 IPI をプラットフォーム管理ユニット (PMU) に送信して電源の回復を要求できます。

IPI チャネルは 11 あり、そのうち 4 チャネルは PMU との通信用に予約されています。 PMU との通信用に予約されて

いる IPI チャネルを除き、各 IPI チャネルには 2 つの 32 バイトバッファーと 6 つのレジスタがあり、これらを使用し

てソースとターゲットが通信します。 2 つのバッファーのうち 1 つはソースが要求を格納するために使用し、もう 1

つはターゲットが応答を格納するために使用します。次の図に、マスターがレジスタを操作して IPI をトリガーし、

ターゲットがレジスタを操作して ACK を返して割り込みに応答する動作を示します。

図 2‐20: プロセッサ間割り込みの割り込みチャネルレジスタ


Enable

Trigger

Observation

Status/Clear

Disable

Mask

Req/Resp buffers

Master A Master B

IPI Channel

X18707-032117





OpenAMP

Zynq UltraScale+ MPSoC デバイス内のブロック間通信に IPI を直接使用するのは手間がかかります。このため、ザイ

リンクスはヘテロジニアス環境で AMP システムを容易に開発できるように OpenAMP フレームワーク (第 3 章「シ

ステムソフトウェアの検討事項」参照) を提供しています。 OpenAMP は IPI をベースにしつつ、次に示す 2 つの重要

なコンポーネントで CPU コアどうしの通信をサポートします。

• Remoteproc: リモート CPU のライフサイクルを開始および管理します。

• RPMsg: リモート CPU どうしの通信に使用します。

OpenAMP とその使用方法の詳細は、第 3 章「システムソフトウェアの検討事項」を参照してください。

PL を使用したワークロードアクセラレーション

14 ページの「プロセッシングシステムの設計手法」で説明したように、 Zynq UltraScale+ MPSoC デバイスではハン

ドコーディングあるいは Vivado® HLS またはザイリンクス SDSoC 開発環境を使用してプロセッシングを PL にオフ

ロードできます。これらのツールを使用すると、システム設計者はソフトウェアを容易に PL に移行して性能を向上

させることができます。

次に、 SDSoC を使用してプロセッシングを PL にオフロードする手順を図に示します。

図 2‐21: PL オフロード手順のまとめ






SDSoC には、アプリケーションを MPSoC のハードウェアで実行した場合の性能を解析するのに役立つ機能がいくつ

かあります。この機能を利用してコードに関する完全なレポートを生成すると、コード内の繰り返しセグメントを

見つけることができます。このレポート機能は、この環境で作成したコードを PL にオフロードした場合に性能が向

上するかどうかを判定し、システム性能がどれだけ向上するか、および PL リソースをどれだけ使用するかを見積

もってくれます。 SDSoC 環境では、次のような画面で情報が表示されます。

図 2‐22: SDSoC による PL アクセラレーション出力の例


次に、 C/C++ コードを Zynq UltraScale+ MPSoC デバイスの PL 内のブロックに変換します。これは、 Vivado HLS (高

位合成) コンパイラで実行します。

合成が完了したら、合成環境で選択されたデータムーバーに関するレポートが生成されます。データムーバーとド

ライバーは SDSoC によって自動的に選択されますが、必要に応じてユーザーが容易に変更できます。また、 Verilog

または VHDL を使用して PL 内に生成した IP ブロックを APU または RPU で動作するアプリケーションから呼び出す

ためのラッパーを生成することもできます。この場合、前述の HLS によるコンパイルは実行しません。





汎用コンピューティングのアクセラレーション

前のセクションではワークロードを手動または自動で PL にオフロードする方法について説明しましたが、それ以外

に汎用コンピューティングのアクセラレーションに使用できる一般的な手法およびテクノロジがいくつかあります。

これには、 GPGPU をサポートしたグラフィックスプロセッシングユニット上で OpenCL ライブラリや汎用コン

ピューティングを使用する場合が含まれます。前述した Zynq UltraScale+ MPSoC デバイスの PL オフロード機能は、

業界で使用されているその他の手法に比べ演算を圧倒的に高速化できます。 Zynq UltraScale+ MPSoC デバイスで使用

される MALI-400 GPU はグラフィックスアクセラレーション専用に設計されており、 GPGPU には適していません。

次の表に示すように、独立機関による発表を見ても FPGA による適化の方が汎用 GPU と CPU を組み合わせた場合

よりもよい結果を達成しています。

図 2‐23: FPGA による最適化と CPU+GPGPU および CPU のみの場合の比較


後に、アクセラレーションには GPGPU よりも PL (すなわち FPGA) の方が適していると考えられる一般的な理由

を次の表に示します。





図 2‐24: GPGPU と比較した FPGA アクセラレーションの利点


結論として、ソフトウェアを高速化したい場合は、 PL のオフロード機能を利用することを強く推奨します。前述の

SDSoC ツール以外に、ザイリンクス SDAccel™ 開発環境の使用も検討してください。 SDAccel は、 FPGA を利用した

OpenCL および C/C++ のアクセラレーションに適化されています。




第 3 章

システムソフトウェアの検討事項Zynq® UltraScale+™ MPSoC では、デバイスのほぼ全体にソフトウェアが存在します。ソフトウェアはベアメタルア

プリケーション、ミドルウェア、ファームウェア、ドライバー、ハイレベルオペレーティングシステム (HLOS)、

ライブラリ、ハイレベルアプリケーション、グラフィックスアプリケーション、通信プロトコルなどの形で存在し

ます。 Zynq UltraScale+ MPSoC でこれらのソフトウェアコンポーネントを含めるか除外するか、特定のハードウェ

ア機能を有効にするかどうかは個々のアプリケーションによって異なり、それによってデバイスのスピードや効率

も変化します。また、これらのソフトウェアコンポーネントは一般にユーザーが希望する主要な実行環境を提供し

ます。要するに、特定のソフトウェアフットプリントがシステム全体をつなぐ役割を果たします。

システムソフトウェア要件を定義する

Zynq UltraScale+ MPSoC デバイスはソフトウェアの柔軟性が高いため、 Zynq UltraScale+ MPSoC デバイスの可能性を

大限に引き出すには Zynq UltraScale+ MPSoC デバイスの各ブロックで利用可能なソフトウェアの選択肢について

十分に理解しておく必要があります。この章では、 Zynq UltraScale+ MPSoC デバイスで利用可能なソフトウェアの選

択肢、および関連する推奨事項について説明します。

Zynq UltraScale+ MPSoC デバイスに関してデザインの要件を定義するために、次の質問に答えてみてください。

1. 実行したいのはベアメタルですか、または OS ですか。

2. ベアメタルを実行したい場合、その理由は何ですか。

3. リアルタイム処理が必要ですか。

4. ブート時間の制約はありますか。制約がある場合、それはどの程度厳密な制約ですか。

5. 使用したいビルド /開発環境はありますか。




第 3 章: システムソフトウェアの検討事項

システムソフトウェアの設計手法

図 3‐1: Zynq UltraScale+ MPSoC デバイスのソフトウェア概略図


RPU PMU LPDPeripherals

Inter-ProcessorCommunication

Framework(OpenAMP)

APU GPU*

CSU

PL

FPDPeripherals

Full Power Domain

Low Power Domain

Programmable Logic Power Domain

PLPeripherals AcceleratorsAccelerators


X18660-032917

注記: Zynq UltraScale+ MPSoC プラットフォームでは、システム内の複数のプロセッシングブロック上で幅広い種類

のソフトウェアスタックを同時に実行できます。次に示すのは、第 1 章で示したシステム全体のブロック図から主

要なプロセッシングブロックを抜き出した概略図です。緑のブロックがも柔軟性が高く、あらゆる種類のソフト

ウェアを実行できます。ブロックの柔軟性は黄色、白の順に低くなります。この図は Zynq UltraScale+ MPSoC デバ

イスの内部ブロックを正確に表現したものではなく、このセクションで説明する概念を図にしたものです。

アプリケーションプロセッシングユニット (APU) とリアルタイムプロセッシングユニット (RPU) はそれぞれ汎用

の ARM A53 と ARM R5 で構成されており、一般的なエンベデッドプロセッサで動作するソフトウェアなら何でも

実行できます。グラフィックスプロセッシングユニット (GPU)、プラットフォーム管理ユニット (PMU) およびプロ

グラマブルロジック (PL) は特定の用途を想定して機能が設計されており、実行できるソフトウェアには制約があり

ます。通常、 GPU の機能にはザイリンクスから提供されるグラフィック /マルチメディアライブラリおよびドライ

バー経由でアクセスします。ザイリンクスは PMU のデフォルトファームウェアを提供しています。カスタム

ファームウェアも作成できますが、デフォルトファームウェアをそのまま使用することを強く推奨します。 PL で

ソフトウェアを実行する方法は 2 つあります。 1 つはソフトウェアの一部をハードウェアに適化する方法、そして

もう 1 つは MicroBlaze™ プロセッサソフトコアインスタンスを実行する方法です。

45 ページの図 3-1 でコンフィギュレーションセキュリティユニット (CSU) ブロックは点線で示してありますが、

これは工場でプログラム済みのため、一切カスタマイズができないことを意味しています。





Zynq UltraScale+ MPSoC デバイスのアーキテクチャではパワーマネージメントが特に重要な要素となります。した

がって、各ブロックで使用するソフトウェアコンポーネントを決定する際にもパワーマネージメントを考慮する必

要があります。第 2 章「プロセッシングシステム」で説明したように、 Zynq UltraScale+ MPSoC デバイスにはいく

つかの電源ドメインがあり、これらを実行時に制御できます。たとえば APU で Linux を動作させる場合、フル電力

ドメイン (FPD) への電源供給が停止すると Linux OS を利用できなくなります。

この章では、 APU および RPU のソフトウェア機能の詳細について説明します。また、 GPU を使用するためのソフト

ウェア、および PMU のデフォルトファームウェアの機能についても紹介します。 GPU を含むグラフィックスの詳

細は、第 9 章「マルチメディア」を参照してください。 PMU を含むパワーマネージメントの詳細は、第 4 章「電源

に関する注意事項」を参照してください。 PL によるハードウェアオフロードの機能は、第 2 章「プロセッシングシ

ステム」を参照してください。ザイリンクス PL で MicroBlaze ソフトコアを使用する方法の詳細は、 MicroBlaze に

関するザイリンクスの資料全般を参照してください。

アプリケーションプロセッシングユニット (APU) のソフトウェア

APU は Zynq UltraScale+ MPSoC デバイスの中心的な汎用プロセッシングブロックです。大動作周波数 1.5 GHz の

A53 を大 4 つ備えた APU は圧倒的なコンピューティング性能を発揮し、強力なソフトウェアアブストラクション

をサポートします。

APU では次のソフトウェアおよびソフトウェア構成を利用できます。

• ベアメタル動作 (A53 上で直接動作、または Xen ハイパーバイザー上のゲストとして動作)。

注記: この場合は A53 を 1 つしか使用できないため、マルチコアのスケーラビリティは得られません。

• 本格的な SMP Linux (A53 上で直接動作、または Xen ハイパーバイザー上のゲストとして動作)。

• FreeRTOS (A53 上で直接動作、または Xen ハイパーバイザー上のゲストとして動作)。

注記: この場合は A53 を 1 つしか使用できないため、マルチコアのスケーラビリティは得られません。

• Xen ハイパーバイザー (ゲスト Linux インスタンスをホスティング、またはいくつかの A53 上で Linux インスタ

ンスを実行)。

• ARM トラステッドファームウェア (ATF) (A53 の TrustZone 機能をサポート。第 7 章「リソースの分離と分割」

を参照)。

• ザイリンクス OpenAMP (Open Asymmetric Multi Processing) (Zynq UltraScale+ MPSoC デバイスの異なるブロック

上で動作する複数のソフトウェア間の通信を可能にするフレームワーク )。

• 上記のいずれかに関連するドライバー、サービス、およびライブラリ。





次に、前述のパッケージの多くを実行した APU の構成例を示します。

図 3‐2: APU ソフトウェアスタックの例


Non-secure world

Xen Hypervisor

Guest OS Guest OS

App1 App2 App1 App2

Secure world

ARM Trusted Firmware (ATF)

A53Core 0

A53Core 1

A53Core 2

A53Core 3

X18930-032117

この例で、 APU は ARM トラステッドファームウェア (ATF) と Xen ハイパーバイザー、および 2 つのゲスト OS を同

時に実行します。このため、 APU は 2 つの重要な方法で分離されます。 1 つはセキュア環境と非セキュア環境の分離

で、これは ARMv8 TrustZone 機能によって実現しています (第 7 章「リソースの分離と分割」参照)。もう 1 つは、並

列に動作する 2 つの異なるゲスト OS の分離で、これは Xen ハイパーバイザーによって実現しています。

APU におけるベアメタルの使用

Zynq UltraScale+ MPSoC デバイスを使用するにあたり、デバイス全体でベアメタルを実行する (すなわち OS もハイ

パーバイザーも使用しない) ことを検討しているなら、特に APU に関してはその判断の根拠を慎重に分析すること

を強く推奨します。 APU はベアメタルの実行をサポートしていますが、その場合 1 つの A53 しか使用できず、それ

以外の 3 つの A53 は使用できなくなります。したがって、システムアーキテクチャを決定する前にこの点を十分に

考慮する必要があります。その理由は、ベアメタルでは SMP 動作がサポートされないことにあります。 Xen と

Linux はどちらも APU の A53 を複数管理できるため、これはハードウェア上の制限というよりもむしろ必要なソフ

トウェアが複雑になりすぎて手間がかかるという問題によるものです。

そのため、 APU でベアメタルを使用するかどうか迷っている場合は、次の点を考慮してください。

1. RPU なら 600 DMIPS のプロセッサで高のリアルタイム割り込み応答が得られます。

2. APU でベアメタルを実行した場合、多くのデザインで十分なレベルのリアルタイム応答が得られますが、 APU

のすべてのプロセッサコアを使用するのは困難です。





それほど高い速度および安定したリアルタイム性能が必要とされない場合、ハイパーバイザー上でほかのオペレー

ティングシステムと並行してベアメタルを実行しても主要な製品要件を満たすことができます。厳密なリアルタイ

ム応答時間を重視する場合は、リアルタイムコードを Linux に密結合する必要があるかどうかを検討します。リア

ルタイムコードがほぼ単独で動作する場合は RPU での実行が適しています。リアルタイムコードと Linux の間に依

存関係がある場合も、まずはリアルタイム部分を RPU で実行し、 OpenAMP フレームワークを使用して APU 上の

Linux インスタンスと必要に応じて通信することを推奨します。 OpenAMP を使用しても問題を解決できない場合は、

サードパーティから提供されているいずれかのリアルタイム Linux バリアントを APU で実行するか、適切なパ

フォーマンスを備えたハイパーバイザーを使用して APU 上で Linux と並行してベアメタル/RTOS をホスティングす

る方法があります。

それほど厳密なリアルタイム性能が必要とされないアプリケーションの場合、 Xen ハイパーバイザー上でベアメタ

ルアプリケーションを実行するのが有効です。 Xen を使用すると、 Linux をゲストとして実行しなくても A53 上で動

作するソフトウェアをユーザーが完全に制御できます。このため、 Xen を使用すると複数の A53 上でベアメタル

コードを実行できます。

リアルタイムプロセッシングユニット (RPU) のソフトウェア

Zynq UltraScale+ MPSoC デバイスでは APU とは別に完全に独立したブロックとして RPU が内蔵されているため、リ

アルタイムコンピューティングと汎用コンピューティングの両方のワークロードをどちらも妥協することなく同じ

システムで実行できます。専用のリアルタイムプロセッシング環境として RPU の 2 つの R5 を利用できるため、

APU の汎用 A53 で無理にリアルタイム性能を追求する必要がなくなります。業界標準の汎用ハイレベル機能および

オペレーティングシステムを A53 で実行しながら、 RPU では同時に次のものを実行できます。

• ベアメタルアプリケーション

• FreeRTOS およびその他の商用 RTOS

• ほかのプロセッシングブロックとの通信を可能にする OpenAMP フレームワーク

• 上記のいずれかに関連するドライバー、サービス、およびライブラリ

RPU の R5 はスプリットモードまたはロックステップモードでの動作が可能です。スプリットモードでは、次の図

に示すように各 R5 がそれぞれ専用のソフトウェアスタックを実行できます。

図 3‐3: RPU ソフトウェアスタックの例


RPU

R5 Core 0

Baremetal RTOS

Baremetal RTOS

App1 App2 App1 App2

R5 Core 1

第 2 章「プロセッシングシステム」で説明したように、ロックステップモードでは 2 つの R5 が同じ処理を実行し、

その出力が異なるとエラーがトリガーされます。ロックステップモードでは、 RPU から密結合メモリ (TCM) 全体の

256 KB にアクセスできます。





R5 はスタートアップ時に FSBL から独立してブートさせることも、 APU のスレーブとして動作させることもできま

す。スレーブモードでは APU で OpenAMP を動作させ、実行時に指定したワークロードで R5 のロードおよびリ

セットを実行します。

グラフィックスプロセッシングユニット (GPU) のソフトウェア

Zynq UltraScale+ MPSoC デバイスは、業界標準の ARM Mali-400 MP2 グラフィックスプロセッシングユニット (GPU)

を使用して 2D および 3D グラフィックスを処理します。次の図に、 Linux ベースのソフトウェアスタックで GPU を

使用する際のシステムコンポーネントを示します。

図 3‐4: Linux ベースの GPU ソフトウェアスタック


Graphics Application

Display ServerEx: XII, Wayland Mali common

Libraries

Video Codecs

Graphic LibrariesEx: Open GLES1,

Open GLES 2, Open VG

Gstreamer

Frame Buffer Driver

Display Drivers

Video DriversEx: V4L2

Mali Graphic DriversDRM

APU

Linux Kernel Drivers

DDR Controller

Memory

GPO PPO PP1Display Port

ARM MALI GPUCache Coherent

Interconnect

X14822-032917

GPU を使用するアプリケーションの下位層には、ディスプレイサーバー (Wayland など)、グラフィックスライブラ

リ (OpenGL ES 1.1 など)、 Mali 共通ライブラリ、 Gstreamer、およびビデオコーデックで構成されるミドルウェアが

あります。ミドルウェアと実際の GPU ハードウェアコンポーネントの間には、 Linux カーネルドライバーのレイ

ヤーがあります。これらのドライバーは、フレームバッファー、 DRAM、 Mali グラフィックス、ビデオ、および

ディスプレイを処理します。





ブートプロセスソフトウェア

ブート時の動作と性能がアプリケーションにとって重要かどうかはシステム要件により異なります。しかしいずれ

の場合も、一部の処理はブート時にしか実行できないため、システムがどのようにブートするのかを理解しておく

ことが重要です。

次に示すブロックはいずれもブートプロセスに関係します。

• PMU

• CSU

• APU

• RPU

• PL

これらのブロックが使用するソフトウェアおよびバイナリコンポーネントには次のものがあります。

• PMU ファームウェア

• CSU ブート ROM

• 第 1 段階ブートローダー (FSBL)

• U-Boot

• ARM トラステッドファームウェア (ATF)

• PL ビットストリーム

ブートプロセスは主に次の 3 つのステージで構成されます。

• プリコンフィギュレーションステージ: このステージは主に PMU が制御し、 PMU ROM を実行してシステムを

セットアップします。リセットおよびウェークアップに関するプロセスはすべて PMU が処理します。

• コンフィギュレーションステージ: FSBL コードをオンチップ RAM (OCM) にロードします。セキュアブートと

非セキュアブートのどちらのモードもサポートされます。 FSBL は APU または RPU にロードできます。

• ポストコンフィギュレーションステージ: FSBL の実行が開始すると、 Zynq UltraScale+ MPSoC デバイスはポス

トコンフィギュレーションステージに移行します。





ブートプロセスの基礎

次に、ブートプロセスおよび関係するブロックとソフトウェアを概略図として示します。

図 3‐5: ブートプロセスの例


Time

Release CSU

Power Monitoring

LoadFSBL

AMP Firmware

U-Boot

Linux

PMU

CSUBootROM

RPU0

APU0 FSBL

AMP FirmwareRPU1

AMP Firmware

APU1,APU2,APU3,

...

LinuxLinux

AMP Firmware

MB (PL)

RP

Msg*

AMP Firmware

*RMPsg is provided in the Xilinx OpenAMP Library

RP

Msg* R

PM

sg*

RP

Msg*

ATF

この図に示すように、ブートフローでは PMU、 CSU、および APU 内のソフトウェアシステムがすべて連携してシ

ステムを起動します。実行されるアクションは次のとおりです。

• PMU は CSU に制御を渡し、認証が必要かどうかを CSU がチェックします。

• CSU が FSBL をオンチップメモリ (OCM) にロードします。

• APU で FSBL が実行されます。 FSBL は RPU でも実行できます。

• 次に、 FSBL がユーザーのアプリケーションソフトウェアまたは U-Boot などの第 2 段階ブートローダーを起動

します。

次に示す図は、ブートプロセスを別の観点から見たものです。パワーアップおよびリセットシーケンスはすべて

PMU によって制御されます。 PMU はまず CSU を解放し、これによってユーザーからは通常見えない内部チェック

および初期化が実行されます。 FSBL の実行を開始するブートイメージの構成に基づいて制御が RPU または APU に

移ります。 FSBL は RPU 上の RTOS、 PL ビットストリーム、 ATF および U-Boot、 Linux、ハイパーバイザーなど、そ

の他のシステムコンポーネントをすべてロードしてシステム全体をブリングアップします。





図 3‐6: 別の観点から見たブートプロセス


PlatformManagement ROM

ConfigurationSecurity ROM

First Stage Boot Loader

Loads ARM Trusted Firmware, Loads U-Boot for Hypervisor

and non-secure OS

Loads Hypervisor on APU

Uboot loads Linux Kernel on APU

Load RTOS on RPU

Load PL bitstream

X18661-032917

ハードウェア RoT (Root of Trust)、ウォームリスタート、およびサブシステム間の分離といった基本的な機能を実行

するには、 PMU ファームウェア、 CSU ブート ROM および FSBL が必要です。 Linux を使用する場合は ATF も使用し

ます。

セキュアブート

Zynq UltraScale+ MPSoC デバイスには、セキュアブートと非セキュアブートの 2 つのモードがあります。前出のタ

イミング図は、基本的に非セキュアモードのブートプロセスを示しています。次の図に、完全なセキュアモードの

ブートプロセスを示します。

図 3‐7: セキュアブートプロセス


Time

Release CSU

Power Monitoring

LoadFSBL

Tamper Monitoring

AMP Firmware

U-Boot

Linux

PMU

CSUBootROM

RPU0

APU0 FSBL

AMP FirmwareRPU1

AMP Firmware

APU1,APU2,APU3,

...

LinuxLinux

AMP Firmware

MB (PL)

RP

Msg*

AMP Firmware

*RMPsg is provided in the Xilinx OpenAMP Library

RP

Msg* R

PM

sg*

RP

Msg*

ATF

X18662-032117





セキュアブートの場合、 CSU は次の動作も実行します。

• 認証チェックを実行し、このチェックにパスした場合のみ次へ進みます。イメージに暗号化されたパーティ

ションがあるかどうかをチェックします。

• パーティションが暗号化されている場合、 CSU は復号化を実行し、 FSBL を OCM にロードします。

また、この例では APU 上で動作する Linux インスタンスが OpenAMP を使用して RPU 上のソフトウェアおよび PL

で動作する MicroBlaze 上のソフトウェアを起動していることも見てとれます。

ブート時の性能

前述のとおり、一部の処理はブート時にしか実行できません。したがって、ブートプロセスをカスタマイズする際

にはブート時間の制約があるかどうかを理解しておく必要があります。たとえば PCIe、 CAN-FD、イーサネット

AVB などではシステムがオンラインになるまでの時間が仕様で定義されています。これらの規格に従う場合、パー

シャルリコンフィギュレーションを使用してブート時にビットストリームのも重要な部分のみを短時間でロード

しておき、残りは後でロードするという方法も可能です。

ブートデバイス

Zynq UltraScale+ MPSoC デバイスの CSU ブート ROM は、次のプライマリブートデバイスをサポートしています。

• クワッド SPI

• NAND

• SD/MMC

• eMMC

CSU は SATA、イーサネット、および PCI Express からのブートを直接サポートしていませんが、小限の FSBL を

使用して、これらデバイスからのセカンダリブートが可能です。

一般に、ブートデバイスは次のようなニーズに応じて選択します。

• 速度を重視する場合は、 SPI フラッシュを使用します。

• 容量を重視し、なおかつシステムのホストにフラッシュファイル管理の負担をかけたくない場合は eMMC が適

しています。

• ストレージ構成が複雑な場合は、 NAND の方が柔軟性に優れています。性能上の理由でフラッシュをきめ細か

く制御する必要があり、なおかつフラッシュ管理ソフトウェアを実行できるだけの強力なプロセッサを備えた

システムでは、この選択肢が理想的です。

また、ストレージを選択する際にはデバイスによって必要なピン数が異なることも考慮する必要があります。

サポートされるブートデバイスについてのその他の注意点は次のとおりです。

• QSPI (シリアルフラッシュ ) のプライマリブートモードは 4 バイトアドレス指定をサポートしています。

• NAND は ONFI (Open NAND Flash Interface) バージョン 3.1 をサポートしています。

• SD カードは SD 仕様バージョン 3.0 をサポートしています。

• eMMC は eMMC (embedded Multimedia Card) 仕様バージョン 4.51 をサポートしています。

• NOR (パラレルフラッシュ ) はサポートされません。

• PS JTAG を利用できます。





• PL JTAG は FSBL のみに限られます。

• スプリット JTAG モードは FSBL のみに限られます。

ブートに関するその他のリソース

ブートプロセスの詳細、およびセキュア/非セキュアブートの詳細は、次の資料を参照してください。

• 『Zynq UltraScale+ MPSoC テクニカルリファレンスマニュアル』 (UG1085) [参照 7]

° ブートおよびコンフィギュレーション

° セキュリティ

• 『Zynq UltraScale+ MPSoC ソフトウェア開発者向けガイド』 (UG1137) [参照 5]

° Zynq UltraScale+ MPSoC デバイスのプログラミングビュー

° システムブートおよびコンフィギュレーション

° セキュリティ機能

システムソフトウェアスタック

APU および RPU で使用できるソフトウェアスタックは、 45 ページの「システムソフトウェアの設計手法」に示し

たとおりです。ここでは、これらスタックのいくつかを詳しく取り上げ、それらの使用に関する推奨事項について

説明します。

RPU ベアメタルソフトウェアスタック

RPU ベアメタルソフトウェアスタックは、次に示す複数のレイヤーで構成されます。

• スタックの下層には、 Cortex R5 スタンドアロンボードサポートパッケージ (BSP) プロセッサレイヤーがあ

ります。このレイヤーには、プロセッサブートコード、キャッシュ、例外処理、メモリ、システムタイマー

コンフィギュレーション、およびプロセッサ機能の初期化を含むスタンドアロン BSP があります。

• Cortex R5 スタンドアロン BSP プロセッサレイヤーの上位には、各種ハードウェアコンポーネントに対する複

数のシングルスレッドデバイスドライバーがあります。これにはペリフェラルドライバーのほか、システム

でのデバッグをサポートする CoreSight デバッグドライバーも含まれます。

• その上位には、アプリケーションソフトウェア開発をサポートする各種ライブラリで構成されるレイヤーがあ

ります。これには、 C ライブラリ、ファイルシステムライブラリ、メモリ、フラッシュ、セキュアキー、パ

ワーマネージメントライブラリ、および lwIP ネットワークスタックライブラリが含まれます。また、 Zynq

UltraScale+ MPSoC デバイスの OpenAMP フレームワーク (60 ページの「OpenAMP フレームワーク」参照) を使

用するための OpenAMP ライブラリもこのレイヤーに含まれます。

• このスタックの上位にユーザーアプリケーション、カスタムライブラリ、およびサービスが必要に応じて存在

します。



http://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug1085-zynq-ultrascale-trm.pdf;a=xBootAndConfiguration

http://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug1085-zynq-ultrascale-trm.pdf;a=xDeviceSecureBoot

http://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug1137-zynq-ultrascale-mpsoc-swdev.pdf;a=xProgrammingViewOfZynqUltraScaleMPSoCDevices

http://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug1137-zynq-ultrascale-mpsoc-swdev.pdf;a=xSystemBootAndConfiguration

http://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug1137-zynq-ultrascale-mpsoc-swdev.pdf;a=xSecurityFeatures



図 3‐8: RPU ベアメタルソフトウェアスタック


Standalone Kernel and DriversStandard USB

Drivers SysMon Driver

CoreSight Debug Driver

EMAC EthernetDriver

RTC Driver Interrupt Controller Driver

CAN Driver AXI Performance Monitor Driver

NAND Driver QSPI Driver

SPI, I2C, UART Drivers ZDMA Driver

GPIO Driver IPI Driver

SD Card Driver TTC Driver

Cortex R5 Standalone BSP Processor Layer

LibrariesStandard ‘C’ Library

(libXil)

Secure Key (xilskey)

lwIP Networking (lwip141)

Memory File System (xilmfs)

FAT file system (xilffs)

Serial Flash (xilisf)

Secure (xilsecure) RSA (xilrsa) Power Mgr API

(xilpm)OpenAMP

(xilopenamp)Parallel Flash

(xilflash)

ApplicationsTemplate Applications Customer Applications

RPU の R5 でベアメタルを実行すると RPU の機能を完全に制御できますが、そのためにはタスクのスケジューリン

グ、ソフトウェアコンポーネント間の主要な通信の管理、ソフトウェア間ロックの管理はもちろん、それ以外にも

通常なら OS カーネルが実行してくれるいくつかの処理を手動で実行しなければならないことがあります。十分に定

義された、または十分に同期したタスクを限られた回数だけ実行するようなアプリケーションの場合、片方または

両方の R5 でベアメタルを実行するのが適しています。 R5 で実行する機能が今後拡張される可能性がある場合は、

R5 で何らかの OS を実行することを推奨します。たとえば初は while(1) ループだけだったデザインが、開発を

重ねた結果、終的に高機能な OS のようになってしまうことも珍しくありません。





RPU FreeRTOS ソフトウェアスタック

RPU FreeRTOS ソフトウェアスタックは、下層に FreeRTOS カーネルコンポーネントが含まれる点を除き、 RPU

ベアメタルソフトウェアスタックと同じです。 RPU ベアメタルの代わりに FreeRTOS を実行すると、 OS の基本機能

を自分で管理しなくても業界標準のリアルタイム OS を使用してアプリケーションを段階的に拡張できる利点があり

ます。その反面、 FreeRTOS およびその API の使用経験がない場合は習熟の必要があります。

図 3‐9: FreeRTOS ソフトウェアスタック


FreeRTOS Kernel and DriversStandard USB



EMAC EthernetDriver







FreeRTOS 8.2.1

Cortex R5 Standalone BSP Processor Layer


(libXil)







(xilpm)OpenAMP


(xilflash)


APU ベアメタルスタック

APU のベアメタルソフトウェアスタックも、ここまで示したソフトウェアスタックと同様のレイヤーで構成され

ます。

• スタックの下層には Cortex-A53 スタンドアロン BSP (32 ビットモード用と 64 ビットモード用に 1 つずつ) が

あります。 32 ビットモードは ARMv7-A と互換性があり、 64 ビットモードは ARMv8-A アーキテクチャと互換

性があります。各スタンドアロン BSP にはプロセッサブートコード、キャッシュ、例外処理、メモリ、システ

ムタイマーコンフィギュレーション、およびプロセッサ固有機能の初期化が含まれます。

• Cortex-A53 スタンドアロン BSP レイヤーの上位には、各種ハードウェアコンポーネントに対する複数のデバイ

スドライバーがあります。これにはペリフェラルドライバーのほか、システムでのデバッグをサポートする

CoreSight デバッグドライバーも含まれます。

• その上位には、アプリケーションソフトウェア開発をサポートする各種ライブラリで構成されるレイヤーがあ

ります。これには、標準 C ライブラリ、ファイルシステムライブラリ、メモリ、フラッシュ、セキュアキー、

パワーマネージメントライブラリ、および lwIP ネットワークスタックライブラリが含まれます。また、 Zynq








します。

図 3‐10: APU ベアメタルスタック


Standalone Kernel and DriversStandard USB



EMAC EthernetDriver







Cortex A53 Standalone BSP Processor Layer


(libXil)







(xilpm)OpenAMP


(xilflash)


APU でベアメタルを使用する際の注意点は、 47 ページの「APU におけるベアメタルの使用」で説明したとおりで

す。ベアメタルアプリケーションのリアルタイムまたは割り込み応答要件を見直し、可能なら Xen ハイパーバイ

ザー上でアプリケーションをホスティングすることを推奨します。こうすると、より多くのシステムリソースをほ

かのタスクに割り当てることができます。





APU Linux ソフトウェアスタック

Zynq UltraScale+ MPSoC デバイスの使用方法としては、 APU で Linux を実行することが推奨されます。 PetaLinux

ツールの一部として提供される APU Linux ソフトウェアスタックもいくつかのレイヤーで構成されています。これ

らの多くは標準 Linux ソフトウェアエコシステムに含まれます。

• スタックの下層には Linux コアカーネル/サービスと Cortex-A53 BSP プロセッサレイヤーがあります。この

レイヤーには、プロセッサブートコード、キャッシュ、例外処理、メモリ、システムタイマーコンフィギュ

レーション、およびプロセッサ固有機能の初期化に関するコンポーネントが含まれます。

• その上位には、カーネルレベルの複数のデバイスドライバー、ペリフェラルドライバー、いくつかの Linux ド

ライバーおよびシステムサービスがあります。これには、リソース管理、ファイルシステム、 I/O 管理、パ

ワーマネージメント、ネットワークおよびマルチメディアスタックレイヤー、グラフィックス、ビデオドラ

イバー、およびネットワークスタックが含まれます。

• その上のレイヤーにはアプリケーションソフトウェア開発をサポートする各種ライブラリがあります。これに

は、標準 C ライブラリ、ファイルシステムライブラリ、メモリ、フラッシュ、セキュアキー、パワーマネー

ジメントライブラリ、マルチメディアライブラリ OpenGL、 EGL、 DRM ライブラリ、ディスプレイサーバー、

オーディオサーバー、 OpenMAX、その他多くのミドルウェアライブラリが含まれます。また、 Zynq




します。

図 3‐11: APU Linux ソフトウェアスタック


Linux Kernel and DriversFile System

ManagerRPmsg &

Remoteproc

Linux TCP/IP Network Stack

Graphics Driver

Ethernet Driver

USBDrivers

V4I2 ARM Arch Support

SATA Driver

Video Codec Driver

SPI, I2C, UART Drivers

PCIe Driver

Display Driver

ALSA Audio Driver

SD Card Driver

Flash Drivers

Linux Core Kernel and Services

Libraries

EGL DRM Library Display Server Audio Server OpenAMP Library Power Mgr API


OpenGL FBdev Other Middleware Libraries RSA Secure Library OpenMAX

FileSystem Services

File System

DRM KMS SMP Support

Cortex A53 BSP Processor Layer





Linux は 20 年以上にわたって組み込みシステム、サーバー、デスクトップで使用されており、非常に活発で充実し

たエコシステムが形成されています。したがって Linux は多くのカスタムおよび汎用アプリケーションで強固な基

盤として利用できます。特に、 APU のマルチコアデザインの可能性を大限に引き出すには Linux が適しています。

Linux の経験が豊富なチームなら、 Linux を採用するのがも自然な選択肢といえます。反対に、 Linux に不慣れな

チームの場合はザイリンクス独自の PetaLinux を使用してプロジェクトを開始することを推奨します。前述のとお

り、 PetaLinux は初心者のエンベデッドニーズに向けて敷居を下げた Linux バージョンです。

ただし Linux は分散開発モデルを採用しているため、伝統的なエンベデッド OS とは異なり責任を持つ単一のベン

ダーが存在せず、使用法について信頼できる情報をワンストップで入手できないことが問題となる可能性がありま

す。このため、 Linux の初心者がシステムの特定の事項について情報を得ようとすると、実際のユースケースに関

係のない情報までヒットしてしまい、取捨選択が必要となります。しかし先に述べたように Linux はエンベデッド

プロジェクトへの採用実績が豊富で、非常に多くのチームが成功を収めているため、このような短所はそれほど大

きな障壁とはならないでしょう。

それよりも技術的な問題として、デフォルトの Linux カーネルでは完全なリアルタイム性能が得られない点に注意

が必要です。 Linux にリアルタイム性を追加する拡張機能として PREEMPT_RT や Xenomai もありますが、本稿執筆

時にはそのどちらも Linux カーネルに完全には含まれていません。このため、これらの拡張機能を使用する場合は

Linux カーネルにパッチを追加する手間が必要となります。ただし前述のとおり、リアルタイム性能が求められる場

合はまず RPU とその機能を活用することを検討してください。

ザイリンクスがサポートする Linux バリアントの詳細は、この章で後述します。 Linux の使用についての詳細は、

『Zynq UltraScale+ MPSoC ソフトウェア開発者向けガイド』 (UG1137) [参照 5] でも説明しています。

APU で Linux を使用する場合、これ以外にも説明の必要なソフトウェアスタックがいくつかあります。これらはグ

ラフィックスに関係するものです。 Linux 環境における次のスタックの詳細は、第 9 章「マルチメディア」を参照し

てください。

• Linux DisplayPort スタック

• Linux GPU ソフトウェアスタック

• Linux ビデオコーデックドライバースタック





OpenAMP フレームワーク

OpenAMP (Open Asymmetric Multiprocessing) は、 Zynq UltraScale+ MPSoC デバイスのような非対称型マルチプロセッ

シング (AMP) システムにおいてソフトウェアコンポーネントどうしを相互接続するための一般的な API とメソドロ

ジを提供する多層モジュール構造のフレームワークです。これにより、異なるコアインスタンスで異なるオペレー

ティングシステム (HLOS、ベアメタル、または FreeRTOS などのリアルタイム OS) を実行するヘテロジニアスマル

チプロセッサシステムで動作するソフトウェアアプリケーションどうしが協調して通信できるようになります。も

う少し具体的に言うと、 OpenAMP はパワーオン、ファームウェアのロード、パワーオフ、およびシステムを構成す

るヘテロジニアスプロセッサ間での情報共有 (通信) を可能にするジェネリックな抽象化フレームワークです。

AMP システムでは、一般的にマスタープロセッサが要求に応じてリモートコア上のソフトウェアを起動します。そ

してコアどうしはプロセッサ間通信 (IPC) を使用して通信し、マスタープロセッサがほかのプロセッサにワーク

ロードをオフロードします。

次の図は、非常に簡単な AMP トポロジを示したものです。この例で、 Linux は APU でマスタープロセッサとして動

作し、 RPU はリモートプロセッサとしてベアメタルアプリケーションを実行しています。リモートプロセッサの

ロードと開始は Linux が実行します。

図 3‐12: 簡単な AMP トポロジ


OpenAMP は 2 つの主要なコンポーネントで構成されます。

• Remoteproc: リモートプロセッサのライフサイクル管理 (LCM) をマスタープロセッサから制御するための管理

用フレームワーク。

• RPMsg: AMP システムの独立したコア上で動作するソフトウェア間で API 経由でのプロセス間通信 (IPC) を可

能にするメッセージングフレームワーク。

図 3‐13: Remoteproc と RPMsg






Remoteproc

Remoteproc はデバイスドライバーで実装され、 API 経由で命令を受け取ります。 API から受け取った命令に従い、

Remoteproc はマスタープロセッサに対してコードとデータをリモートプロセッサのメモリにロードする、リモート

プロセッサを開始する、マスタープロセッサとリモートプロセッサ間の通信チャネルを管理する、リモートプロ

セッサをシャットダウンするといった動作の実行を指示します。

リモートプロセッサからは、 API 経由のマスタープロセッサに対する呼び出しにより、リモートプロセッサ上の

Remoteproc システムを初期化する、リモートプロセッサとマスタープロセッサ間の通信チャネルを管理する、

リモートプロセッサ上の Remoteproc システムをシャットダウンするといった動作を実行できます。

RPMsg

RPMsg はプロセッサ間のメッセージングバスで、各プロセッサはバス上のデバイスとして存在します。プロセッサ

はチャネルと呼ばれるリンクで相互に通信します。チャネルはリモートプロセッサが開始すると作成されます。

各チャネルは、名前とソースおよびデスティネーションアドレスで識別します。

RPMsg は仮想 I/O (Virtio) コンポーネントを使用します。 Virtio は、マスタープロセッサとリモートプロッサ間の通

信をサポートする仮想 I/O サービスを提供します。

次の図は、 OpenAMP のレイヤーに Virtio がどのように組み込まれるかを示したものです。

図 3‐14: RPMsg と Virtio


Virtio は、 Virtio が使用する I/O 処理用のトランスポート抽象化として vring を使用します。 vring はリングバッ

ファーを実装します。





API

OpenAMP の API はマスタープロセッサとリモートプロセッサの両方に実装されます。 API からの指示により、

RPMsg は次の動作を実行します。

• チャネルのデフォルトエンドポイントへメッセージを送信する

• 明示的なソース /デスティネーションアドレスおよびブロッキングオプションに対応した複合メッセージを送信

する

• チャネルおよびチャネルエンドポイントを作成および破棄する

• データを受信する

• データ転送中にバッファーサイズを認識して使用する

次に、 Zynq UltraScale+ MPSoC デバイスの OpenAMP 対応コア間での API の使用例を示します。

図 3‐15: OpenAMP フレームワークを使用したハイブリッド SMP + AMP の例


RPMsg

RPMsg

Open AMP(APIs for loading/ Unloading firmware, Message Passing)

その他のリソース

OpenAMP の詳細は、『Zynq UltraScale+ MPSoC OpenAMP: 入門ガイド』 (UG1186) [参照 8] を参照してください。





Xen ハイパーバイザー

ザイリンクスはオープンソースの Xen ハイパーバイザーをザイリンクス Zynq UltraScale+ MPSoC デバイス向けに

ポーティングし、同じコンピューティングプラットフォームで複数のオペレーティングシステムを実行できるよう

にしています。 Xen はハードウェア上で直接動作し、ハイパーバイザー上で複数の OS を実行しながら CPU、メモ

リ、割り込みを管理します。これらの OS をドメインまたは仮想マシン (VM) と呼びます。

注記: Xen ハイパーバイザーの詳細は、 https://wiki.xen.org/wiki/Xen_Project_Software_Overview の「Xen プロジェクト

のソフトウェア概要」を参照してください。

次の図に、 Zynq UltraScale+ MPSoC デバイス上の Xen ハイパーバイザーアーキテクチャの例を示します。

図 3‐16: Xen ハイパーバイザーのアーキテクチャ


Hypervisor

APU

ARMCortex-A53

ARM Cortex-A53

ARM Cortex-A53

ARM Cortex-A53

Linux Kernel inSMP mode

RTOSKernel

BaremetalApplication

Application 1

Thre

ad 1

Thre

ad 2

Thre

ad n

App

licat

ion

n

Task

1

Task

2

Task

n

X14840-081015

Xen ハイパーバイザーは、1 つのドメイン ( ドメイン 0 または dom0) と 1 つまたは複数のゲストドメイン (domU) を制

御します。コントロールドメインには次の特権があります。

• ハードウェアへの直接アクセス

• システムの I/O 機能へのアクセス処理

• ほかの仮想マシンとの通信

また、外部からアクセス可能な制御インターフェイスもあり、このインターフェイスを利用してシステムを制御し

ます。各ゲストドメイン上ではそれぞれの OS とアプリケーションを実行します。ゲストドメインはハードウェア

から完全に隔離されます。

ハイパーバイザーはブートローダーによって起動します。詳細は、 50 ページの「ブートプロセスソフトウェア」を

参照してください。 Xen ハイパーバイザーを使用して複数の OS を実行するには、ホスト OS をセットアップして 1 つ

または複数のゲスト OS を追加します。 Zynq UltraScale+ MPSoC デバイスの場合、 Xen はゲスト OS なしでベアメタル

アプリケーションを実行することもできます。



https://wiki.xen.org/wiki/Xen_Project_Software_Overview



パフォーマンス最適化に関する検討事項

前述のとおり、リアルタイムおよび割り込み応答要件によっては、 Xen ハイパーバイザーを使用したシステムデザ

イン構成の方がよいこともあります。しかし個々のデザインはすべて異なっており、設計要件によっては Xen の使

用に関してさらにいくつか注意が必要になることがあります。ここでは、 Zynq UltraScale+ MPSoC デバイスで Xen を

適化するためのパフォーマンス調整方法をいくつか紹介します。

割り込み応答時間

割り込み応答時間とは、ハードウェアレベルで生成された割り込みが、そのハードウェア上で動作する OS 内で対

応するコードの実行をトリガーするまでの時間をいいます。割り込み応答時間は、ネイティブ OS とゲスト OS で異

なります。ネイティブ OS の場合、パフォーマンスに影響する要因としてはプロセッサの例外レベル 3 (ARMv8 アー

キテクチャの場合) で発生する動作、 OS 割り込みハンドラー、および実際の応答時間のテストに使用するタイマー

と計測精度が挙げられます。ゲスト OS の場合、ハイパーバイザーの割り込み処理および転送ルーチン、ハイパーバ

イザーのタイマー分解能、ゲスト OS のコンフィギュレーションなどパフォーマンスに影響する多くの要因を考慮す

る必要があり、複雑です。

計測を実行後、アプリケーションでゲスト OS の割り込み応答時間を微調整する必要があると判断した場合、次の

適化手法を検討します。これらの手法で実行するコンフィギュレーションまたは設計変更は比較的簡単なものです。

• Xen ハイパーバイザーのスケジューラの選択と設定

• ゲスト OS から物理 CPU への割り当て

• ゲスト OS: デバイスをポーリングするか割り込みドリブンとするかの決定

適化手法にはこれ以外もありますが、この文書の目的からは外れるため割愛します。

ブート時間

ブート時間とは、 Xen ハイパーバイザーおよび Xen Dom0 が初のゲスト OS をブートする準備ができるまでの時間

をいいます。ブート時間は FSBL、 ARM トラステッドファームウェア、および U-Boot の実行時間によって異なりま

す。また、ブートデバイスおよびセキュアブートフロー (Xen ハイパーバイザーの起動および Dom0 の起動など) に

よっても異なります。

ブート時間が問題になるようなユースケースでは、次の事項を検討します。これらはハイパーバイザー自体への変

更を必要としません。

• Dom0 の設定 (サイズが小さいほど高速)

• ブートデバイスの選択 (ハイパーバイザーを使用しないシステムの場合)

• セキュアブートのパラメーター (ハイパーバイザーを使用しないシステムの場合)





パススルーデバイスの I/O スループット

Zynq UltraScale+ MPSoC には IOMMU (ARM SMMU-400) があります。 Xen などのハイパーバイザーが IOMMU をサ

ポートしている場合、ゲスト OS はネイティブな DMA 対応デバイスドライバーを使用でき、エミュレーションや仮

想化などのレイヤーを介さずにデバイスがデータを直接ゲストへパススルー転送できます。

このような構成における I/O スループットは、デバイスドライバーを同じ OS にデプロイした場合のパフォーマンス

に依存しますが、 SMMU の第 2 ステージアドレス変換に伴うわずかな遅延が伴います。

準仮想化した共有デバイスの I/O スループット

Xen ハイパーバイザーは準仮想化したデバイス用のインフラストラクチャをサポートし、次の 2 つの重要な機能を実

現します。

• Xen Dom0 が所有および制御するデバイスは複数のゲスト OS で効果的に共有できます。

• ゲスト OS どうしは、各 OS からは UART またはネットワークインターフェイスとして見える仮想デバイスを

使用して互いに通信します。

この種の構成における I/O スループットは、次の要因に左右されます。

• ネイティブ Linux デバイスドライバー (Dom0 が使用) のパフォーマンス

• ほかのゲスト OS が要求する I/O デバイス帯域幅

• Xen バスインフラストラクチャの性能

• Xen Dom0 および Xen DomU のワークロード





PMU ソフトウェア

プラットフォームマネージメントユニット (PMU) には、ブートプロセスへの参加、パワーマネージメント API の

提供、および各種システムエラーの処理など多くの役割があります。このセクションでは、 PMU のソフトウェア開

発に関するいくつかの項目について説明します。パワーマネージメントの詳細は、 87 ページの「プラットフォーム

管理ユニット」を参照してください。次に、 PMU の機能ブロック図を示します。

図 3‐17: PMU のブロック図


メモリ

PMU は次の種類のメモリを使用します。

• RAM にはデータ用の ECC (エラー訂正符号) メモリがあり、オプションでユーザー /ファームウェアコードも格

納できます。

• PMU ROM にはデフォルトの割り込みサービスハンドラー (ISR) が格納されており、フックモードでの割り込

み処理に使用します。

• PMU メモリ (ROM および RAM) はパワーアップ、パワーダウン、 IPI、リセット要求などのパワーマネージメ

ント機能を処理します。

• PMU はザイリンクスが提供するフレームワーク内にユーザーコード領域を持ち、これが PMU RAM にロードさ

れます。

PMU の機能拡張に使用できるメモリ容量は非常に限られています。 Linux で周波数制御などのパワーマネージメン

トを実行すると、 PMU ファームウェアのサイズに影響します。したがって、必要な機能をすべて PMU のメモリに

格納できるように、パワーマネージメントの必要性を十分に検討する必要があります。





パワーマネージメントフレームワーク

パワーマネージメントソフトウェアフレームワークは、複数の消費電力削減モード (電源ドメイン) をサポートして

います。これらのモードは各種ハードウェアをターゲットとし、電源に関するカスタマー要件が厳しいアプリケー

ションに使用されます。このフレームワークはソースコードとして提供されているため、カスタマイズが可能です。

次の図は、代表的なフレームワーク呼び出しがシステムをどのように伝搬するかを示したものです。

図 3‐18: パワーマネージメントセルシーケンス


このフレームワークは、いくつかの API レイヤーで構成されており、上の図では各レイヤーを左から右に示してい

ます。このフレームワークが電源アクションをどのようにサポートするかを知るために、 Cortex-A53 ユニットなど

のマスターパワーユニットがプロセッサ間割り込み (IPI) を使用して PMU に割り込みを送信し、電源アイランドの

シャットダウンなどの電源アクションを実行する例について見てみます。 PMU ファームウェアは IPI を受信した後

API イベントを生成し、それを受けて ROM へのハンドラー呼び出しが実行されます。 ROM にはデフォルトの割り

込みサービスルーチン (ISR) が格納されており、電源アクションが実行されます。電源アイランドのシャットダウ

ンなどのアクションが実行されるとコードが戻り、 ACK 信号がフレームワークの初の位置まで戻ると要求が完了

します。

PMU フレームワークのランタイムソフトウェアはシステムパワーダウンモードの有効化をサポートし、パワーダ

ウンモードを管理して必要に応じてシステムをウェークアップします。また、適切な電源ステートを維持し、 APU

と RPU をスリープステートからウェークアップする必要がある場合には APU と RPU の代理として動作します。

このフレームワーク内では、 PMU がパワーマネージメントサーバーです。サーバーはすべてのマスターに対して

API を提供し、外部パワーマネージメント IC およびすべての電源ドメインスイッチを制御します。また、サブシス

テムのサスペンド処理を完了し、サスペンドしたサブシステムを必要に応じてウェークアップできます。

プロセッシングユニット (APU と RPU) はパワーマネージメントマスターです。マスターはパワーマネージメント

サーバーからデバイス電源の各種スイッチングを要求できます。また、サブシステムのサスペンドを開始および実

行し、ウェークアップ命令を受け取ったらサブシステムのレジュームを実行し、 PMU からの要求に応答します。





次の図は、 PMU フレームワークの内部および上位にあるソフトウェアレイヤーを示したものです。これらのレイ

ヤーにより、アプリケーションと下位ファームウェアはそれぞれ異なるレベルでパワーマネージメントにアクセス

できます。プロセッシングユニットの複雑なソフトウェアスタックはすべてのレイヤーを使用し、ベアメタルなど

のシンプルなユニットはシステムレベル API のみを使用します。

図 3‐19: パワーマネージメントフレームワーク


フレームワークおよびレイヤーを通じて行われる処理はすべてパワーマネージメント API を利用して簡単に実行で

きます。この API によって、次の機能が管理されます。

• プロセッシングユニットをサスペンドするためのシステムレベル機能

• パワーマネージメントスレーブを管理するためのシステムレベル機能

• その他の各種システムレベル機能

• 直接制御システム機能 (読み出しおよび書き込み)

ソフトウェア開発ツール

Zynq UltraScale+ MPSoC デバイスの利点を大限に引き出して個々のデザインに役立てていただけるよう、ザイリン

クスは幅広い種類のソフトウェア開発ツールを提供しています。このセクションでは、これらツールの概要を説明

し、 Zynq UltraScale+ MPSoC デバイスの豊富なソフトウェア機能がこれらツールによってどのようにサポートされる

のかを示します。





開発環境およびキット

次の図に、 Zynq UltraScale+ MPSoC デバイス向けソリューションの開発に使用できる主な開発環境を示します。

図 3‐20: Zynq UltraScale+ MPSoC デバイスに対応したザイリンクスの開発環境


Vivado Design Suite

この統合開発環境 (IDE) は業界で初めて SoC に対応したハードウェアソリューション設計のためのデザインスイー

トです。 Vivado® には C ベースのアルゴリズムをハードウェア IP に変換する高位合成 (HLS) コンパイラ (Vivado

HLS) のほか、ザイリンクスの充実した IP ライブラリから IP を選んで統合できるブロックベースの IP インテグレー

ションツールが含まれます。システム検証向けに、Vivado には混在言語シミュレーションツールの Vivado ロジック

シミュレーターがあり、この中にはターゲット環境でのシステムデバッグをサポートしたロジックアナライザー

(Vivado ロジック解析) が含まれます。 Vivado 全体で使用するスクリプト言語の Tcl (Tool Command Language) を用い

て Vivado の機能を拡張することもできます。

PetaLinux

PetaLinux は、完全なエンベデッド Linux システム開発キットです。このキットには Linux OS およびザイリンクスシ

リコン用の完全なコンフィギュレーション、ビルド、デプロイ環境、 Linux OS コンフィギュレーション、コマンド

ラインツール、開発テンプレート (アプリケーション、デバイスドライバー、およびライブラリ )、デバッグエー

ジェント、 GCC ツール、統合エミュレータ QEMU (QuickEMUlator)、およびザイリンクス BSP パッケージが含まれ

ます。

PetaLinux は Linux カーネル、 U-Boot、プロジェクト固有コンポーネント、およびプロジェクト固有ライブラリなど

のコンポーネントを集約します。コンポーネントは C コードである必要はなく、 PetaLinux プロジェクトで何らかの

目的を達成する一連の命令であればかまいません。 PetaLinux コンフィギュレーションユーティリティを使用して、

特定のコンポーネントを有効または無効にできます。





PetaLinux ではすべてがコンポーネントをベースにしているため、このキットを使用した設計ではモジュール構造を

活かすことができます。異なるコンポーネントのライブラリを使用して既存デザインに対してイタレーションを実

行することにより、派生デザインを容易に作成できます。

PetaLinux はバックグラウンドで make を使用してプロジェクトをビルドします。

前述のとおり、 Linux の経験がほとんどなく、しかもごく基本的なスケジューラまたはオペレーティングシステム

で APU の A53 を動作させたい場合は、まず PetaLinux を使用することを推奨します。

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

ザイリンクスソフトウェア開発キット (SDK) は、 MicroBlaze ソフトプロセッサを含むザイリンクスの任意のプロ

セッサ上で動作するエンベデッドアプリケーションの作成に向けた統合設計環境 (IDE) です。ザイリンクス SDK は

ソフトウェアの開発とデバッグを完全にサポートしており、 Vivado Design Suite に統合して使用することも、スタン

ドアロンインターフェイスとして使用することもできます。この SDK は、定評ある Eclipse IDE をベースにしてい

ます。

SDK を Vivado ハードウェアデザイン環境に接続し、Vivado で設計したハードウェアを SDK にエクスポートすると、

BSP パッケージやドライバーなど、そのデザインに必要なソフトウェア環境が自動的に作成されます。

SDK にはエディター、コンパイラ、ビルドツール、フラッシュメモリ管理、デバッグ、およびプロファイリング

ツールが付属します。 SDK は 1 本の JTAG ケーブルを使用して JTAG デバッグをサポートします。

SDSoC 開発環境

SDSoC™ 開発環境は、 Eclipse IDE をはじめヘテロジニアスな Zynq UltraScale+ MPSoC 向けの包括的な開発環境を備

えた、使いやすいエンベデッド C/C++/OpenCL アプリケーション開発環境を提供します。フルシステムの適化を

C/C++/OpenCL のみで実現するコンパイラを備えたこの開発環境は、システムレベルのプロファイリング、プログ

ラマブルロジック (PL) を利用したソフトウェアアクセラレーションの自動化、システムコネクティビティの自動

生成、およびプログラミングを迅速に行うためのライブラリを提供します。また、エンドユーザーやサードパー

ティプラットフォームの開発者は、システムレベルのソリューションを迅速に定義、統合および検証できることか

ら、エンドカスタマーに独自のプログラミング環境を提供できます。

この開発環境には次の機能があります。

• 使いやすい Eclipse IDE を使用して、エンベデッド C/C++/OpenCL アプリケーションで Zynq All Programmable

SoC および MPSoC システム開発が可能

• ファンクションを PL で高速化

• ターゲットオペレーティングシステムとしてベアメタル、 Linux、および FreeRTOS をサポート

• Vivado HLS の一部としてザイリンクスライブラリを提供。また、ハードウェアに適化したオプションのライ

ブラリをアライアンスメンバーから提供

SDSoC 開発システムの詳細は、 https://japan.xilinx.com/products/design-tools/software-zone/sdsoc.html を参照してください。



https://japan.xilinx.com/products/design-tools/software-zone/sdsoc.html



開発フロー

ソフトウェアソリューションの開発に利用する環境は 1 つと限りません。事実、 1 つのイメージを作成するのに複

数の環境を使用します。たとえば Zynq UltraScale+ MPSoC の実行可能フラッシュイメージは、次に示す複数のツー

ルで作成できます。

• Vivado IP インテグレーターおよびプロセッサコンフィギュレーションウィザード (PCW) を使用して PS サブシ

ステムおよび .bit ファイルコンポーネントを構成します。

• SDK を使用して BSP、 PMU ファームウェア、 FSBL、およびアプリケーションイメージを作成します。この中

には結合イメージを生成するための bootgen ユーティリティも含まれます。

• PetaLinux を使用して U-Boot、 ATF、 Linux、デバイスツリー BLOB などのオープンソースソフトウェアイメー

ジを作成します。

次に、複数の開発環境およびツールを使用したデザインフローを 2 つ示します。初の例では、 Vivado と SDK の両

方を使用してベアメタルイメージを開発しています。

図 3‐21: ベアメタルイメージの生成






次の例では、 3 つの開発環境すべてを使用して Linux イメージを生成しています。

図 3‐22: Linux イメージの生成


Yocto Project 開発

チームが既に Linux に習熟しており、 Linux の実装を完全に制御したい場合は PetaLinux よりも Yocto の方が適してい

ます。 Yocto Project ツールおよび開発環境で使用できる Zynq UltraScale+ MPSoC デバイスの Yocto レシピはザイリン

クスの git サーバーから入手できます。

Yocto には次の機能があります。

• 新の Linux カーネルおよびエンベデッド環境に適したシステムコマンドのセットとライブラリを提供します。

• X11、 GTK+、 Qt、 Clutter、 SDL をはじめとする各種システムコンポーネントを利用できるため、ディスプレイ

ハードウェアを備えたデバイスで豊富なユーザー体験を実現できます。デバイスにディスプレイがない場合や

別の UI フレームワークを使用する場合、これらのコンポーネントはインストール不要です。

• OpenEmbedded プロジェクトと互換性のある安定したコアを、目的に応じて作成します。このコアを使用して、

Linux ソフトウェアを簡単かつ確実にビルドして開発できます。

• Quick Emulator (QEMU) により、幅広い種類のハードウェアおよびデバイスのエミュレーションをサポートします。





次の図に、 Yocto Project 開発環境を示します。

図 3‐23: Yocto Project 開発環境


User Configuration

Metadata(.bb+patches)

Machine(BSP)Configuration

Policy Configuration

SourceFetching

PatchApplication

Configuration / Compile /

Autoreconf as needed

OutputAnalysis for

package splitting plus

Packagerelationships

.rpmGeneration

.debGeneration

.ipkGeneration

QATests

imageGeneration

ImagesApplication

DevelopmentSDK

Package Feeds

Source Mirror(s)

Upstream Project

Releases

LocalProjects

SCMs(optional)

Upstram SourceMetadata/InputsBuild System

Output PackagesProcess steps (Tasks)Output Image Data

SDKGeneration

X14841-020717

2016 年 4 月現在、前述の PetaLinux 開発環境は完全な Yocto バックエンドを備えています。

Zynq UltraScale+ MPSoC デバイスで Yocto を使用する方法について、詳細は『Zynq UltraScale+ MPSoC ソフトウェア

開発者向けガイド』 (UG1137) [参照 5] を参照してください。

マルチメディア開発ツール

マルチメディア開発には次のものが利用できます。

• PetaLinux ツールチェーンを使用してディスプレイ、オーディオ、 GPU、およびビデオコーデック用のユーザー

モードライブラリおよびカーネルモードドライバーをコンパイルできます。

• GDB デバッガーまたは SDK のデバッグツールを使用してマルチメディアアプリケーションのアプリケーショ

ンコードをデバッグできます。

• SDK にはマルチメディアデザインのプロファイリングを実行できるシステムパフォーマンス解析 (SPA) があり

ます。

• SDSoC 開発環境では C/C++ ロジックから IP を生成し、 Vivado Design Suite を利用して特定用途向けイメージ処

理用 SoC の FPGA ビットストリームを生成できます。実例については、『SDSoC 環境チュートリアル: 入門』

(UG1028) [参照 9] を参照してください。

• グラフィックスアプリケーション開発には ARM Mali 開発ツールを使用できます。





デバッグ

デバッグはシステムの機能検証およびソフトウェア評価を行い、設計プロセスの早期段階で見つけにくい重大なデ

ザインエラーを検出できます。また、実チップでは再現しにくい条件をシミュレーションでき、 ARM A53 および

R5 コア、および PS ペリフェラルをエミュレートできます。

このセクションで述べたように、 IDE にはいくつかのデバッグツールおよび手法があります。 IDE に付属するデ

バッガ以外にも、次のようなデバッグツールがあります。

• ザイリンクス SDK は Xilinx System Debugger (XSDB) をサポートしています。 XSDB はブレークポイント /ウォッ

チポイントの設定、プログラムのステップ実行、プログラム変数およびスタックの表示、システム内のメモリ

内容の表示といった一般的なデバッグ機能をすべてサポートしています。また、マルチプロセッサシステムの

異なるプロセッサ上で動作しているプログラムを同じデバッグ環境から同時にデバッグできます。たとえば

APU のコアと複数の MicroBlaze ソフトプロセッサの両方を 1 本の JTAG ケーブルを使用して同じデバッグセッ

ションに表示できます。

Vivado ロジックアナライザー同様、XSDB もザイリンクスハードウェアサーバーをデバッグエンジンとして使

用します。これにより、ヘテロジニアスデバッグ (ソフトウェアとハードウェアの同時デバッグ) という重要な

利点を実現しています。

XSDB を使用してアプリケーションをデバッグするにはデバッグシンボルが必要なため、デバッグ用にコンパ

イルした ELF (Executable Linkable Format) ファイルを使用する必要があります。また、実行ファイル名や実行す

るターゲットプロセッサ、その他の情報を含むデバッグセッションも作成する必要があります。デバッガーを

起動後、 GUI でデバッグパースペクティブを切り替えることができます。これにより、プログラムのデバッグ

と実行を管理できます。

• PetaLinux はデバッグツールとして QEMU、 Oprofile、および GDB (GNU デバッガー ) を使用します。

• Yocto Project のデバッグツールには、 Perf、 Ftrace、 Oprofile、 Sysprof、および Blktrace があります。

• ARM 社の DS-5 Development Studio では DS-5 デバッガーを使用します。このデバッガーはデバイスのブリング

アップからアプリケーションデバッグまでを支援します。 DS-5 デバッガーを使用すると、 RTL シミュレータ、

仮想プラットフォーム、およびハードウェア上でコードを開発できます。

• 一部の商用 Linux ディストリビューションはデバッグ用ツールをサポートしています。

• Zynq UltraScale+ MPSoC は BIST (Built-in Startup Test) もサポートしており、これにはメモリテスト (MBIST) とロ

ジックテスト (LBIST) が含まれます。




第 4 章

パワーマネージメントに関する注意事項今日のテクノロジ市場ではますます複雑なソリューションとコンピューティング機能が求められています。複雑性

と機能性が高くなると、適に機能するために消費電力に対する要件も高まります。これによって、システム設計

者、開発者、エンジニアには消費電力を削減する任務が課せられます。この章では、 Zynq® UltraScale+™ デバイス

のパワーマネージメント機能とその使用に関連する推奨事項について説明します。

電力要件を定義する

Zynq UltraScale+ デバイスには、特定のパワーマネージメントの要件に合わせて調整できる非常に豊富なパワーマ

ネージメント機能があります。そのため、 Zynq UltraScale+ デバイスに適用されたデザインが高の結果となるよう

に、一歩下がった視点からシステムの特定デザイン要件を批判的に分析することが重要です。

Zynq UltraScale+ デバイスに間してシステムのパワーマネージメントの要件を定義するには、次の質問に答えてみてく

ださい。

1. プロセッシング機能は常に実行する必要がありますか。

2. Zynq UltraScale+ デバイスのどの部分の電源を切断できますか。

3. デザインには指定された再開時間要件がありますか。

4. システムの処理の一部をプログラマブルロジック (PL) にオフロードできますか。

Zynq UltraScale+ MPSoC エンベデッドデザイン設計手法ガイド 75UG1228 (v1.0) 2017 年 3 月 31 日 japan.xilinx.com



第 4 章: パワーマネージメントに関する注意事項

パワーマネージメントの調整方法

Zynq UltraScale+ デバイスでシステムのパワーマネージメントを調整する方法は主に次の 5 つとなります。

1. 機能を無効化

2. 動的なパワーマネージメント

3. 周波数制御

4. クロックゲーティング

5. PL アクセラレーションの使用

初の 4 つは、エンベデッドシステムのパワーマネージメントにおいて共通する方法であり、 Zynq UltraScale+ デバ

イスはこれらの分野において独自の機能を提供します。これらの方法に加えて、 Zynq UltraScale+ MPSoC デバイスで

は、 C 言語を HDL に変換するツールを使用して、ソフトウェアタスクをプログラマブルロジックに移行することも

可能です。コプロセッサへソフトウェアタスクをオフロードすることは、より高性能な処理が可能になるだけでな

くワットあたりの性能も向上することが実証されています。

Zynq UltraScale+ デバイスの動作を効果的に制御するには、まずパワーマネージメントの基本を押さえておく必要が

あります。 77 ページの図 4-1 に示すように、 Zynq UltraScale+ MPSoC デバイスは、効率的なパワーマネージメント

を行うために 4 つの電源ドメインで構成されています。各電源ドメインは、外部電圧レギュレータにより電力が供

給されます。個々の電源ドメイン制御が必要ない場合は、ドメイン間で電源レールを共有できます。

プロセッシングシステムには、バッテリ電源ドメイン、低電力ドメイン、フル電力ドメインという、主に 3 つの電

源ドメインがあります。低電力ドメインとフル電力ドメインには、さらに IP のパワーゲーティングオプションがあ

ります。

4 つ目の電源ドメインは、プログラマブルロジック (PL) です。信頼性の高いパワーマネージメント制御を可能にす

る三重冗長マイクロコントローラーを含むプラットフォーム管理ユニット (PMU) によってパワーマネージメントが

制御されます。





図 4‐1: Zynq UltraScale+ MPSoC の電源ドメイン

X-Ref Target - Figure 4-1Zy

TextFull-Power Domain

Text

Text

Low-Power Domain

PL Domain

Application Processing Unit

Real-Time Processing Unit

Textn Programmable Logic

TextDDR Controller

Graphics Processing Unit

High-Speed Connectivity

TextSecurity &

Configuration Unit

Platform Management

Unit

System Monitor

General Connectivity

TextBattery Power Domain

TTe txtBBRAM RTCProcessing System

一般的にベクター設計手法の消費電力に対する必要性が大きいほど、 Zynq UltraScale+ MPSoC デバイスのパワー

マネージメント機能についてより多くの時間を費やす必要があるため、ユーザーデザイン要件と対比させて、要

件に応じて実装を細かく調整する必要があります。デザインのベクターおよびそれらの使用方法の詳細は、

9 ページの「ベクター設計手法」を参照してください。

機能を無効化

Zynq UltraScale+ デバイスは豊富な機能を備えていますが、デザインにすべての機能が必要とは限りません。 Zynq

UltraScale+ デバイスを電力要件に応じて調整する際の初のステップは、 Zynq UltraScale+ デバイスの機能を理解し、

デザインに不要な部分を判断することです。次に、これ以降の説明および関連する Zynq UltraScale+ デバイスの技術

資料を参照して、必要のないブロックへの電力供給を無効化または小化する方法を習得する必要があります。

たとえば、 R5 プロセッサが提供するリアルタイム処理機能が必要ない場合は、これらのプロセッサを無効化するよ

うに Zynq UltraScale+ デバイスを設定できます。 A53 に対しても同様です。つまり、これらのプロセッサを選択的に

無効化できます。計算ブロックのほかに、 USB 機能などのペリフェラルブロックを無効化することも可能です。

一般的にベクター設計手法の消費電力に対する必要性が大きいほど、 Zynq UltraScale+ デバイスから可能な限り不

要な機能を除き、パワーマネージメント機能を使用してこれらの機能を無効化することに注力する必要があります。

次のセクションでは、電源ドメインと電源アイランドについて詳しく説明します。

動的なパワーマネージメント

無効化する不要な機能を特定した後、次に Zynq UltraScale+ デバイスのどの部分の電源を定期的に切断すべきかを判

断します。通常、動的なパワーマネージメントでは、 Zynq UltraScale+ デバイスのいかなる部分、いかなる時点でも

完全に電源を切断することは不可能です。このような場合は、次に説明する周波数制御やクロックゲーティング方





法を使用できます。しかしながら、一部のコンポーネントを定期的にシャットダウンし、必要に応じて起動する方

法が一般的です。

たとえば、プログラマブルロジックのみを常時アクティブにする必要があり、アプリケーションプロセッシングユ

ニット (APU) は定期的に必要となるデザインの場合、 Zynq UltraScale+ デバイスの機能を慎重に考慮し、 PL を常にア

クティブにして、必要に応じて APU を起動する方法を考えます。

ほかにもさまざまな例があり、 PL を定期的にシャットダウンする場合や、より複雑な方法が必要な場合がありま

す。たとえば、 PL を常にアクティブにし、 APU を一時的に起動させる必要がある上に、リアルタイムプロセッシン

グユニット (RPU) を一定時間ごとにアクティブにする必要がある場合などがあります。

この章では、デザインの各部の動的なパワーマネージメントの要件に応じて Zynq UltraScale+ デバイスの機能をゲー

ティングする方法について説明します。

Zynq UltraScale+ デバイスの各部の電源を定期的に切断できると判断した場合には、これらが起動して動作を再開

するまでの時間も考慮する必要があります。たとえば、 A53 で Linux などの高性能 OS を再起動させるには、 PL

を再起動させるよりもかなりの時間が必要になる可能性があります。 A53 で OS やアプリケーションの再起動時間

が長すぎる可能性があるため、起動時の応答時間要件を満たすためにロジックの一部を PL に移動する必要があり

ます。

再起動時間を事前に判断することは複雑な作業であり、おおよその再起動時間を定量化するためにデザインの基本

機能の一部をプロトタイプ化することが必要です。たとえば、 A53 で Linux を実行している場合、 Linux の再起動時

間は特定のソフトウェアコンフィギュレーションと使用しているドライバーに依存します。したがって、 Linux は

数百ミリ秒以内に再起動できますが、 Zynq UltraScale+ デバイスベースのデザインでは、その正確な再起動時間を予

測できません。

場合によっては、慎重な再起動時間の分析によって、デザインで動的なパワーマネージメントを使用できないとい

う結論に至る可能性があります。そのような場合は、パワーマネージメントを適化するための別のオプションと

して周波数制御やクロックゲーティングを検討することをお勧めします。

周波数制御

Zynq UltraScale+ デバイスで永久的または定期的にオフにできる部分を特定した場合、周波数制御を使用してアク

ティブ部分の消費電力をさらに削減できる可能性があります。デザインの A53 を特定の期間中にアクティブにする

必要がある場合でも、フルの処理機能が不要なときには速度を下げることによって A53 の消費電力をさらに削減で

きる可能性があります。

プロセッシングシステムは、独自のパワーマネージメント機能を備えた 2 つの主要プロセッシングシステム (APU

と RPU) を使用して電力/性能を制御します。通常、 APU の周波数制御は Linux の CPU ガバナーで実行されます。

プロセッシングコンポーネントの周波数を下げると、性能が低下する代わりに電力効率が向上します。このような

トレードオフを許容できない場合、残されたオプションは機能を無効化 (77 ページの「機能を無効化」参照) する方

法とクロックゲーティングです。詳細は次のセクションを参照してください。

周波数制御の詳細は、『Zynq UltraScale+ MPSoC テクニカルリファレンスマニュアル』 (UG1085) [参照 7] の「クロッ

キング」セクションを参照してください。

クロックゲーティング

Zynq UltraScale+ デバイスの別のパワーマネージメントオプションとして、クロックゲーティングがあります。こ

れにより、特定コンポーネントへのクロック供給を無効にできるため、ダイナミック消費電力を削減できます。ス

タティック消費電力は変化しません。つまり、電源は投入された状態でクロック信号が受信されません。


http://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xClocking





クロックゲーティングは Zynq UltraScale+ デバイス内の複数コンポーネントに適用できます。プロセッサコア、プ

ロセッサペリフェラル、 PL ソフトコア、 PL ハードコアなどがその対象となります。

クロックゲーティングの詳細は、『Zynq UltraScale+ MPSoC テクニカルリファレンスマニュアル』 (UG1085) [参照 7]

の「クロッキング」セクションを参照してください。

PL アクセラレーションの使用

ASSP とは異なり、 Zynq UltraScale+ MPSoC はソフトウェアタスクをプログラマブルロジックに移行できる特別な機

能を備えているため、ソフトウェア動作を大幅に加速できる上にワットあたりの性能を向上できます。新世代の

プログラマブルロジックは、次世代の低消費電力ハード IP と性能強化されたソフト IP による独自の消費電力削減/

管理機能を提供します。

これらは、エンベデッドシステムの消費電力を調整する革新的な方法です。実際には、前述のその他の調整方法と

は異なり、 Zynq UltraScale+ デバイスの独自機能は、システム全体のパフォーマンスを向上させながら消費電力を削

減する唯一の方法です。したがって、ザイリンクスでは、システムの目標を確認して、 PL に実装できる機能を判断

することを強くお勧めします。

ハードウェアに関する注意事項

Zynq UltraScale+ デバイスのパワーマネージメント機能の中には、ボードのサポートが必要なものがあります。たと

えば、フル電力ドメインの電源を切断できるかどうかは、ボードレベルのサポートに依存します。レギュレータは

ソフトウェアで制御できるように、 GPIO や PMBUS などを介して正しく配線される必要があります。求められる柔

軟性レベルに応じて、電源レールの結合に制約が生じます。したがって、必要となる動作時の PM (パワーマネージ

メント ) 機能を考慮に入れてボード設計を行う必要があります。

ソフトウェアに関する注意事項

ザイリンクスは、消費電力削減モードをサポートするソフトウェアのパワーマネージメントフレームワークを提供

しています。このフレームワークは、電力モードとサブモードをサポートする業界標準をベースに構築され、プ

ラットフォーム管理ユニット (PMU) で制御されます。このパワーマネージメントフレームワークにより、任意のシ

ステムソフトウェアで、ベアメタル操作、従来型 Linux のパワーマネージメント、独自のソフトウェアスタックな

どのパワーマネージメントを制御できます。 Linux 経由でのこれらのモードの使用例を示したサンプルコードを提

供しています。

まとめ

次の表は、各調整方法が性能、消費電力、および PL フットプリントの適化に有効または無効であるかを示してい

ます。

方法性能消費電力 PL フットプリント

つまり、通常、電力調整では消費電力、性能、利用可能な機能という 3 つの要素の間でトレードオフが行われます。

機能を無効化有効有効無効

動的なパワーマネージメント有効有効無効

周波数制御有効有効無効

クロックゲーティング無効有効無効

PL アクセラレーションの使用有効有効有効






4 つの主要電源ドメイン

Zynq UltraScale+ デバイスの 4 つの主要電源ドメインは、かなり高度なレベルで早期に導入されました。次の図で、

これらのドメインを構成するコンポーネントの詳細を示しています。左下隅にはバッテリ電源ドメインがあり、左

上隅にはリアルタイムプロセッシングユニット (RPU) を含む低電力ドメインがあります。右上はアプリケーション

プロセッシングユニット (APU) を含むフル電力ドメインです。そして、下部にプログラマブルロジック (PL) の電源

ドメインがあります。

図 4‐2: Zynq UltraScale+ デバイス: 4 つの主要電源ドメイン


プロセッシングシステム (PS) の電源ドメイン

プロセッシングシステム (PS) は、バッテリ電源モード、低電力モード、およびフル電力モードの 3 つの電力モード

で動作します。

バッテリ電源モードは、も低消費電力かつもシンプルなモードであり、リアルタイムクロックとバッテリバッ

クアップ式 RAM を維持するために使用されます。消費電力は、バッテリバックアップ式 RAM に電力を供給してい

るときの 180 ナノワットから、リアルタイムクロックが有効のときのわずか 3 マイクロワットまでの範囲です。

低電力モードは、リアルタイムプロセッシングユニット (RPU) に関連付けられています。消費電力は、動作レベル

に応じて約 20 mW から 220 mW の範囲です。

フル電力モードは、有効に設定されたアプリケーションプロセッシングユニットに関連付けられています。消費電

力は、動作レベルに応じて大で数ワットに及ぶ可能性があります。低電力モードからフル電力モードに切り替え

るには、通常、 APU 上で実行されている OS (一般的に Linux) を起動または再開する必要があります。





図 4‐3: プロセッシングシステム: 複数の電力モード


上の図では、機能の無効化と動的なパワーマネージメントという点で、 PS 電源ドメインにおける処理能力と消費電

力のトレードオフを理解することができます。積み重なった各モードは、下のモードがアクティブになることが前

提となります。つまり、フル電力モードは、低電力モードとバッテリ電源モードの両方がアクティブであることが

前提です。

処理能力と消費電力のトレードオフを検討する際、特定タスクにフル電力モードを適用すると、そのタスクの電力

バジェットに合致しない可能性があります。そのような場合は、関連する機能を PL に移行することを推奨していま

す。一方、消費電力が許容電力バジェット内に収まっている場合、フル電力モードの消費電力を把握することで、

システム全体の消費電力を評価できます。また、フル電力モードの消費電力が大きすぎても、このモードをアク

ティブにする必要がある場合は、システムの消費電力をさらに調整するために周波数制御とクロックゲーティング

の適用を推奨しています。

再開時間の要件がある場合は、電力モードの切り替えに要する時間を考慮する必要があります。たとえば、再開時

間が非常に重要で、可能な限り短く抑える必要があり、重要な入力データを処理するためにバッテリ電源モードか

らフル電力モードに切り替える必要がある場合は、切り替え時間が要件を満たしているかを確認する必要がありま

す。たとえば、 APU 上で Linux を実行しているとし、ユーザー空間プロセスが特定の入力を処理するために提案さ

れた方法であるとします。その場合、外部イベントと前述のユーザー空間プロセスの再開との間の時間差が要件に

合っているかどうかを確認する必要があります。

バッテリ電源ドメイン

バッテリ駆動ドメインには、暗号化キーとリアルタイムクロックを格納するためのバッテリバックアップ式 RAM

があります。





図 4‐4: バッテリ電源ドメイン


バッテリバックアップ式 RAM には、オプションでデータの復号に使用される 256 ビットのデバイスキーがあり

ます。

リアルタイムクロックは 40 ビットタイマーとして構成され、残りのシステムがスリープモードにあるときに使用

されるカウントダウンタイマーです。これは設定可能 ( 大 40 ビット ) で、周期的な割り込みを生成してシステムの

残りのクロックよりも低い周波数でシステムの状態をチェックします。通常は、 32 キロヘルツの「時計」式の水晶

発振器が接続されています。

通常、 Zynq UltraScale+ デバイスのバッテリ電源ドメインは常にオンとなります。そうでない場合は、次に電源ドメ

インが有効になる (電源が投入された) ときに RTC を再プログラムする必要があります。





低電力ドメイン

低電力ドメイン (LPD) は、 R5 プロセッサを使用するリアルタイムプロセッシングユニット、スタティックオン

チップメモリ (OCM)、プラットフォーム管理ユニット (PMU)、コンフィギュレーション/セキュリティユニット

(CSU)、低速ペリフェラルで構成されています。

図 4‐5: 低電力ドメイン






フル電力ドメイン

フル電力ドメイン (FPD) は、 A53 プロセッサを使用する APU、 GPU、 DDR (ダブルデータレート ) メモリコントロー

ラー、および高性能ペリフェラル (PCI Express、 USB 3.0、ディスプレイポート、 SATA など) で構成されています。

図 4‐6: フル電力ドメイン


フル電力ドメインは、低電力ドメインが有効に設定されていなければ有効にできないことに注意してください。こ

れは、低電力ドメインにはフル電力ドメインで必要となるすべてのパワーマネージメントプロセスを担う PMU が

含まれているためです。





PL 電源ドメイン

プログラマブルロジック (PL) 電源ドメインは、ロジックセル、ブロック RAM、デジタル信号処理 (DSP) ブロック、

AMS、入力/出力、および高速シリアルインターフェイスで構成されています。プラットフォームによっては、ビデ

オコーデック、 PCI Express Gen-4、 UltraRAM、 CMAC、 Interlaken などを含む場合があります。

図 4‐7: PL 電源ドメイン






電源アイランドとパワーゲーティング

低電力ドメインとフル電力ドメインの中には、複数の電源アイランドがあります。これにより、外部の電源レール

やレギュレータを必要としないデバイス内で局所的なパワーゲーティングが可能になります。

ゲーティングを適用できるデバイスには次の特長を持つドメインがあります。

• 低電力ドメイン

° R5 はペアでゲート制御可能です。

° TCM と OCM は 4 つのバンクに分割され、それぞれ個別にゲート制御またはリテンションモードで保持で

きます。

° USB は個別にゲート制御できます。

• フル電力ドメイン

° 各 A53 は個別にゲート制御できます。

° L2 キャッシュ

° GPU - ジオメトリプロセッサと L2 キャッシュは同時にクロックゲートできますが、各ピクセルプロセッ

サは個別にゲート制御できます。

電源アイランドは、 e-fuse によって無効化されていない限り、初は電源が投入された状態となります。ユーザー

コードによって電源が投入された後、 PMU は適切なアイランドを即座にパワーダウンできます。

機能の無効化と動的なパワーマネージメントの両方の面から、有効な電源アイランドを確認し、デザインに必要な

パワーマネージメント方法とそれらを使用するタイミングを検討する必要があります。たとえば、システムにユー

ザーインターフェイスも USB 接続もない場合は、起動時に USB と GPU の電源アイランドに電源を投入しないよう

に PMU に命令を送ることをお勧めします。また、クロックゲーティングを使用して、必要に応じて一部のペリフェ

ラルの消費電力を削減することもできます。





プラットフォーム管理ユニット

プラットフォーム管理ユニット (PMU) には、主に 2 つの機能があります。

• パワーマネージメント

• 安全管理

このユニットには、電源投入、電源切断、およびリセット要求を処理する専用のブート ROM が含まれています。ま

た、システムプロセッサ間の通信用にプロセッサ間割り込み (IPI) をサポートしています。

PMU プロセッサは、エラー訂正コード (ECC) 付きの 128 キロバイトの RAM に接続されており、この RAM にデータ

やファームウェア、ザイリンクスのフレームワークコードを格納します。 PMU は、ザイリンクスのパワーマネージ

メントファームウェアで使用されるグローバルレジスタ (Power、 Isolation、 Reset、 Logic Clear、 Error Capture、

System Power State レジスタなど) を提供します。

PMU には専用の割り込みコントローラーと専用のローカルレジスタがあります。 PMU は、プロセッシングシステ

ムの I/O やプログラマブルロジック (PL) との間にインターフェイス接続があります。

図 4‐8: プラットフォーム管理ユニットのブロック図


消費電力の要件が高くなるほど、 PMU とその機能について深く理解する必要があります。

電源投入時の機能

電源投入後、PMU は次の一連のイベントを実行してからコンフィギュレーションセットアップユニット (CSU) に制

御を渡します。

• CSU と残りの LP ドメインの適切な動作を保証するために、システムモニター (SysMon) を使用してパワーイン

テグリティをチェックする

• PLL を初期化する





• MBIST (Memory Built-In Self Test) をトリガーしてシーケンスを実行する

• JTAG を介して読み出すことができるエラーをキャプチャして通知する

• 電源アイランドおよび eFuse を介して無効になっているその他の IP の電源を切断する

• CSU のリセットを解放する

ザイリンクスの PMU ファームウェア

ザイリンクスが提供する PMU ファームウェアは、 ROM の既存機能を拡張し、さらに充実した機能を提供します。

これは、パワーマネージメントおよび安全管理用に提供されているフレームワークであり、ソースコードとして利

用して簡単にカスタマイズや拡張が可能になります。

ファームウェアは、 IPI を使用してその他のオンチップマスターデバイスと通信し、エラー処理や RAM スクラブな

どの安全機能を実行します。

PMU ブート ROM (PBR) には、次の 2 つの割り込み処理モードがあります。

• フックモード

• 完全置換モード

1 つ目のモードでは、 PMU 割り込みが ROM 内に直接送信され、その後 ROM 内の割り込みサービスルーチン (ISR)

によって処理されます。

2 つ目のモード (完全置換モード ) では、 ROM 内の割り込みハンドラーが RAM 内にあるコードに置き換えられます。

PMU ファームウェアは、 2 つ目のモードを使用して実行されます。





パワーマネージメントソフトウェアのアーキテクチャ

Zynq UltraScale+ MPSoC デバイスのソフトウェアフレームワークは、複数のプロセッシングユニットがパワーマ

ネージメントにおいて連携することを可能にするため、ヘテロジニアスマルチプロセッシングシステムを管理する

ためのパワーマネージメント API を実装します。次の図は、 API ベースのパワーマネージメントソフトウェアの

アーキテクチャを示しています。

図 4‐9: パワーマネージメントソフトウェアのアーキテクチャ


PMU のランタイムソフトウェア機能には、次のものがあります。

• システムのパワーダウンモードを有効にする

• パワーダウンモード中のシステムを管理し、各種トリガーメカニズムに基づいてシステムをウェークアップさ

せる

• システムの電力ステートを常に維持管理する

• APU および RPU がスリープステートの場合にこれらの代理として動作し、ウェークアップ要求に従ってこれ

らに電源投入して再起動させる

パワーマネージメント用のさまざまな API の使用については、『Embedded Energy Management Interface (EEMI) API

ユーザーガイド』 (UG1200) [参照 6] を参照してください。





Xilinx Power Estimator

ザイリンクスは、ターゲットデバイスの消費電力を迅速に見積もるためのツールを提供しています。デバイスタイ

プ、パッケージ、スピードグレード、温度グレードを選択でき、オプションで「Typical」または「Maximum」を選

択して見積もりを実行できます。また、どのプロセッサコアがアクティブであるか、その使用率レベル、計画され

ているメモリタイプとその使用率、および使用されているペリフェラルを選択できます。同様に、プログラマブル

ロジックに対しては、どの IP ブロックが使用されているか、またそれらのクロック周波数やリソース使用率を選択

できます。

図 4‐10: Xilinx Power Estimator


詳細は、『Xilinx Power Estimator ユーザーガイド』 (UG440) [参照 1] を参照してください。




第 5 章

プログラマブルロジックすべての Zynq® UltraScale+™ MPSoC デバイスにはプログラマブルロジックが統合されており、プロセッシングシ

ステム (PS) とプログラマブルロジック (PL) 間の通信を可能にするインターフェイスも含まれています。この章で

は、 PS と PL 間のインターフェイスを含む設計に関するあらゆる注意事項について説明します。 PL のさまざまな機

能間相互のやり取りに影響を及ぼす設計上の注意事項については、ここでは割愛しますが、 PL のさまざまな機能に

ついては、十分理解しておく必要があります。これらの詳細は、『UltraFast 設計手法ガイド (Vivado Design Suite 用)』

(UG949) [参照 4] を参照してください。

PL の要件を定義する

PL の要件を認識することは、システム設計の基本です。使用できる PL のサイズや機能は、選択するデバイスに

よって異なります。したがって、まず、システムの観点から要件を明確にして、適切な種類のデバイスを選択する

ことが重要です。ザイリンクスの All Programmable ヘテロジニアス MPSoC のウェブサイト [参照 18] にある製品一覧

表に、さまざまなデバイスおよび PL の機能が示されています。あらかじめ要件を定義することで、 PS と PL 間の通

信の設定方法においても正しい判断を下すことができます。

この章では、 FPGA のプログラマブルロジックを使用する設計についての知識があることを前提として説明します。

具体的には、デザインで必要となるカスタムおよび既製の IP に必要なロジックの量を考慮に入れて、適切なサイズ

のデバイスを選択する方法を熟知している必要があります。

トレーニング: ザイリンクスでは、資料、トレーニング、チュートリアルなどさまざまなリソースを提供していま

す。トレーニング情報は、 https://japan.xilinx.com/training.html を参照してください。

その他の詳細は、ハードウェア開発者ゾーン (https://japan.xilinx.com/products/design-tools/hardware-zone.html) を参照し

てください。



https://japan.xilinx.com/training.html

https://japan.xilinx.com/products/design-tools/hardware-zone.html


第 5 章: プログラマブルロジック

次の質問は、 PS-PL 間相互のやり取りに関する要件を定義する際に役立ちます。

• PS-PL 間でデータを転送する必要がありますか。

• PS に接続されたメモリとの間でデータを転送する際の性能要件 (スループット、レイテンシ) はありますか。

• PS-PL 間に割り込みを配線する必要がありますか。

• 起動時間や PL コンフィギュレーションは重要ですか。

• PL 内にある IP はリセット信号による通知が必要ですか。

• PL では、 PS からクロック信号を受信する必要がありますか。

• PS へクロックを供給するために PL でクロックを生成する必要がありますか。

PL の設計手法

システムアーキテクチャ全体における PL の役割を確認するために、次の図に PL とその機能、および PL-PS 間の通

信インターフェイスを示します。

図 5‐1: Zynq UltraScale+ MPSoC のプログラマブルロジック


前述したとおり、ここで説明する PL の設計手法は、 PS-PL 間相互のやり取りに焦点を当てています。図 5-2 にシン

プルかつ正確な図を示します。





図 5‐2: Zynq UltraScale+ MPSoC の PS‐PL インターフェイス


Processing System

ProgrammableLogic

AXI Interfaces

There are several AXI Interfaces, see Fig 5-3 for details

Interrupts

FPD

APU

LPD

RPU

16 Shared Peripheral Interrupts

64 Peripheral Interrupts

4 IPI + 4 FIQ + 4 IRQ

100 Peripherals Interrupts

4 IPI + 2 nFIQ + 2 nIRQ

Clocks

LPD 4 Clocks

EMIO96 EMIO bits (Use GPIO for Resets)LPD

DisplayPort Dedicated Stream

Dedicated Connections

PMU Several Signals

GigEth Dedicated Stream

DMA

FPD-DMA Flow Control

LPD-DMA Flow Control

(DMA transfers are done over AXI interfaces)

注記: この図は、 Zynq UltraScale+ デバイスの内部ブロックを正確に表現したものではなく、このセクションで説明

する概念を図にしたものです。

図示されているように、デバイスの PL 領域との接続にはいくつかの種類があります。各接続には、デザインに影響

を与える重要な特性があります。接続の種類は次のとおりです。

• AXI インターフェイス

• 割り込み

• クロック

• EMIO、リセット (EMIO 経由の GPIO) を含む

• 専用ストリーム

• PMU

• DMA

次のセクションでは、各接続の詳細を説明します。





AXI インターフェイス

第 2 章「プロセッシングシステム」で説明したとおり、 Zynq UltraScale+ MPSoC デバイスのコンポーネント間通信

の主なメカニズムは ARM AXI インターコネクトです。また、 PS-PL 間には複数の AXI リンクがあります。 PS-PL 間

で使用する AXI リンクの選択は、 Zynq UltraScale+ MPSoC デバイスをベースとするアプリケーションの設計におい

ても重要な項目の 1 つです。使用できる選択肢を認識できるように、次の図では、 PS-PL 間で共有される AXI イ

ンターフェイスの詳細を示しています。

図 5‐3: PL‐PS 間における AXI インターフェイス通信の詳細


PS

S_AXI_ACP_FPDAPU

CCI

Mem

ory

Sub

syst

em

LP

PL

S_AXI_ACE_FPD

S_AXI_HPC0_FPDS_AXI_HPC1_FPD

S_AXI_HP0_FPDS_AXI_HP1_FPDS_AXI_HP2_FPDS_AXI_HP3_FPD

SM

MU

M_AXI_HPM0_FPDM_AXI_HPM1_FPD

S_AXI_LPD

M_AXI_HPM0_LPD

SMMU

X15278-100116





高性能 AXI マスター

高性能 AXI ポートは、 PL から DDR (ダブルデータレート ) へのアクセスに利用できます。 PL から接続されるポート

は 6 つ (S_AXI_HPCn_FPD が 2 つ、 S_AXI_HPn_FPD が 4 つ) あり、これらは 128、 64、または 32 ビットに設定可能

です。これらのポートのうちの 2 つは、次に説明するキャッシュコヒーレントインターコネクト (CCI) に接続され、

4 つはメモリアクセスのために DDR インターフェイスに直接接続されます。

インバウンド AXI スレーブ

1 本の大 128 ビット幅の低レイテンシスレーブインタフェイス (M_AXI_HPM0_LPD) は、 LPD からの PS-PL 間通

信を可能にします。 2 本のインバウンドスレーブインターフェイス (M_AXI_HPM0_FPD、 M_AXI_HPM1_FPD) は、

FPD から PL への通信を可能にします。

アクセラレータコヒーレンシポート (ACP)

128 ビット幅の AXI スレーブインターフェイス (S_AXI_ACP_FPD) は、 APU L2 キャッシュコントローラーと PL 内

の可能なアクセラレータ機能との間の接続を可能にします。このスレーブインターフェイスは、スヌーピングプロ

セスによってコヒーレントな CPU L2 キャッシュを共有します。つまり、 PL は CPU キャッシュを常に新の状態に

保ちます。デフォルトで PL から CPU のコヒーレンシが維持されない場合、このインターフェイスは、 CPU キャッ

シュへ既にロードされているデータに依存する PL のアクセラレーション機能に適です。

AXI コヒーレンシ拡張

AXI コヒーレンシ拡張 (ACE) は、128 ビットの AXI4 スレーブインターフェイス (S_AXI_ACE_FPD) であり、APU と

PL 内の潜在的なアクセラレータ機能との接続を可能にします。 ACP とは異なり、このスレーブは CCI へのコヒーレ

ントなアクセスを可能にします。 ACE は CCI および PL へのアクセスをスヌープするため、ハードウェアに 2 とおり

のコヒーレンシを提供します。 PL には、 PS に対してそのようなマスターインターフェイスが 1 つあります。

PL/PS 通信の詳細は、『Zynq UltraScale+ MPSoC テクニカルリファレンスマニュアル』 (UG1085) [参照 7] の「PS - PL

インターフェイス」セクションを参照してください。

ソフトウェアとハードウェアのコヒーレンシの詳細は、『Zynq UltraScale+ MPSoC ソフトウェア開発者向けガイド』

(UG1137) [参照 5] の「システムコヒーレンシ」セクションを参照してください。

適切な AXI インターフェイスを選択する

設計者は、インターフェイスの利用/割り当てを判断する際に、いくつかのトレードオフを考慮する必要があります。

選択肢によって異なる結果が生じます。まずは、ピンの方向 (双方向のピン、あるいは PL からまたは PL への単方向

のピン) です。インターフェイスの中には、コヒーレンシを提供するもの、安全性のために保護機能 (低電力ドメイ

ン (LPD) に属する ) を提供するもの、そして性能の優位性 (レイテンシ、スループット ) を提供するものがあります。

次の表に、ピンの方向および必要な機能に基づいた有効な AXI インターフェイスを示します。


http://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xPSPLInterfacing


http://japan.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug1137-zynq-ultrascale-mpsoc-swdev.pdf;a=xSystemCoherency




双方向 PL から PL へ

コヒーレント

LPD に属す

性能

汎用、非コヒーレント

たとえば、 FPD がダウンしても継続する PL からのアウトバウンドリンクが必要な場合は、 S_AXI_LPD が適とな

ります。一方、 PS-PL 間に完全コヒーレントな双方向リンクが必要な場合は、 S_AXI_ACE_FPD を選択する方が好

ましいでしょう。

その選択に基づいて残りのアーキテクチャが展開されるため、特定リンクを使用した場合の長所と短所を考察する

のに十分な時間を費やす必要があります。つまり、後から変更を加えると、非常に高いコストが発生する可能性が

あります。

割り込み

PL からの割り込み送信/受信は、デザインの重要な部分です。『Zynq UltraScale+ MPSoC テクニカルリファレンスマ

ニュアル』 (UG1085) [参照 7] の表 35-6 では、 PL から送受信される割り込みの完全リストを示し、前述の設計手法の

図では、次のような有効な割り込みの概要を示しています。

• PL で受信される割り込み信号

° 100 の LPD ペリフェラル割り込み

° 64 の FPD ペリフェラル割り込み

• PL から送信される割り込み信号:

° PS への 16 の共有ペリフェラル割り込み

° 4 つのプロセッサ間割り込み、 APU への 4 つの FIQ および 4 つの IRQ

° 4 つのプロセッサ間割り込み、 RPU への 2 つの nFIQ および 2 つの nIRQ

ユーザーは任意の受信した割り込みを使用して、 PL IP の動作をトリガーでき、任意の送信された割り込みをアサー

トして、 PS の割り込みをトリガーできます。マルチメディアの選択は、アプリケーションによって異なります。

S_AXI_ACE_FPD S_AXI_HPC0_FPD、

S_AXI_HPC1_FPD

N/A

N/A S_AXI_LPD M_AXI_HPM0_LPD

N/A S_AXI_ACP_FPD N/A

N/A S_AXI_HP0_FPD、

S_AXI_HP1_FPD、

S_AXI_HP3_FPD、

S_AXI_HP4_FPD、

M_AXI_HPM0_FPD、

M_AXI_HPM1_FPD





クロック

PS からクロック信号を受信する必要がある場合は、 PL の境界から送信される 4 つのクロックのいずれかを使用でき

ます。これらのクロックは独立して動作し、これらの信号間のタイミング関係は保証されません。そのため、 PL IP

は、 PS から受信するクロック間の暗黙の同期に依存すべきではありません。

EMIO

第 10 章「ペリフェラル」で説明したとおり、 EMIO は、 LPD ペリフェラル出力ピンを PL にマップする手段として

使用されます。また、 LPD を PL へ双方向リンクで接続する簡単な方法としても使用できます。たとえば、 LPD

GPIO 出力を PL 機能にマップすることによって、 PL で使用するためのリセット信号を PS から生成できます。 PS-PL

間に専用のリセット信号はありません。

専用ストリーム

LPD のギガビットイーサネットコントローラーや FPD の DisplayPort などの一部の機能には、 PL との間で接続され

た専用ストリームがあります。ギガビットイーサネットコントローラーについては、第 10 章「ペリフェラル」で

説明します。 DisplayPort については、第 9 章「マルチメディア」で説明します。これらのペリフェラルが PL と通信

する方法の詳細は、『Zynq UltraScale+ MPSoC テクニカルリファレンスマニュアル』 (UG1085) [参照 7] を参照してく

ださい。

PMU

PMU と PL は次の信号を共有します。

• 32 ビットの汎用入力 (GPI) および汎用出力 (GPO)

• LPD と FPD 両方の AIB 要求信号と ACK 信号

• PMU への入力として提供される PL からの 4 つのエラー出力

• PL へエラーを示す PS からの 47 の出力

これらの信号は、ミッションクリティカルなアプリケーションで、ユーザーの PL IP が PMU と密接に連携する必要

がある場合に役立ちます。

DMA

FPD-DMA と LPD-DMA は両方とも、 PL 内にフロー制御信号を提供できます。 SMA コントローラーの詳細は、

第 6 章「メモリ」を参照してください。

ロジック

このセクションでは、ルックアップテーブル (LUT) とフリップフロップで構成された PL の機能について説明しま

す。ユーザーは独自の RTL を実装し、ザイリンクスツールを使用してそれらをプログラムできます。それらを PS

に接続するには、データ転送用に PS と通信する必要があるすべてのロジックに AXI インターフェイスを実装する必

要があります。 PS と通信する必要があるインターフェイスが複数ある場合、複数のマスターが複数のスレーブと通

信できるように AXI Interconnect IP をインスタンシエートする必要があります。 AXI Interconnect IP を使用すると、接





続に使用されるロジック量が増加します。あらかじめ計画することで、ロジックリソースの適な使用が可能にな

ります。

このセクションでは、ユーザーが PL のロジックリソースを使用して設計できるように、有効なツール、設計手法、

およびライブラリについて簡単に説明します。

注記: デバイスのあらゆる設計段階をサポートするザイリンクスツールの一般的情報は、開発者ゾーンを参照してく

ださい。

Vivado Design Suite

Vivado® Design Suite 統合開発環境 (IDE) は、ハードウェアソリューションの設計に適な業界初の SOC に対応でき

る設計環境です。次の機能が含まれます。

• Vivado HLS: C ベースのアルゴリズムをハードウェア IP に変換する高位合成コンパイラ。

• Vivado IP インテグレーター : 豊富なザイリンクス IP ライブラリから IP を統合するブロックベースの IP 統合

ツール。

• Vivado ロジックアナライザー : ターゲット環境でシステムデバッグを行うためのロジック解析機能 (Vivado ロ

ジックアナライザー ) を含む混合言語シミュレーションツール。

• TCL: Vivado 全体で使用される基本的なスクリプト言語であるツールコマンド言語。

• ザイリンクスソフトウェア開発キット (SDK): MicroBlaze™ ソフトコアマイクロプロセッサなどのザイリンクス

マイクロプロセッサをベースにエンベデッドアプリケーションを構築する場合に使用できるもう 1 つの統合設

計環境 (IDE)。ザイリンクス SDK を使用して、 FPGA で実行するアプリケーションを作成できます。ザイリンク

ス SDK は、 Vivado Design Suite のインストール時にオプションでインストールできます。ザイリンクス SDK の

詳細は、ザイリンクスソフトウェア開発キットのウェブページ [参照 14] を参照してください。

Vivado は完全な IDE であるため、 PL の構成に使用される暗号化ビットストリームの作成など、 FPGA に必要なすべ

てのロジック開発を初から後までサポートします。また、高度な設計、検証、および実装を短時間で実行でき

ます。 Vivado は複数のエディション (HL System、 HL Design、 HL WebPack™) で展開されています。詳細は、 Vivado

Design Suite のウェブサイト [参照 15] を参照してください。

アイソレーションデザインフロー

ザイリンクスアイソレーションデザインフロー (IDF) は、 1 つの FPGA 上で独立した機能をパーティション方式で

動作させるために開発されました。たとえば、機密データ (赤) と非機密データ (黒) あるいは関数が相互に侵害され

ないようにする必要がある赤/黒の概念を使用するソリューションでは、関数とデータを物理的に分離すること (取

り消し不可) が不可欠です。

IDF は、既存のインプリメンテーションツールフローに基づいた設計手法です。デザインのさらなるフロアプラン

は、既存の制約ツール (PlanAhead/Vivado GUI) を使用して行います。デザイン (ピン配置および配線済みデザイン) の

検証は、スタンドアロンツール (ISE® Design Suite または Vivado の IVT または VIV のいずれか) で行います。

IDF を使用すると、プログラマブルロジック (PL) に実装されているすべての IP が、リソースの分離要件とセキュリ

ティ要件が満たされるように分離されます。ザイリンクスは、 IDF を紹介するためのリファレンスデザインをいく

つか提供しています。詳細は、アイソレーションデザインフローのウェブサイト [参照 16] を参照してください。

ザイリンクスのパーティション技術を使用することで、 1 つの FPGA に分離された機能が複数含まれた安全で信頼性

の高いシングルチップソリューションを開発できます。認証機関が求める要件を満たすために必要な分離を実現す

るには、 SCC_ISOLATED など特別な属性とそれが可能にする機能による制御が必要です。 IDF の詳細を理解するに

は、通常のパーティションデザインフローを十分理解しておく必要があります。 IDF では、パーティションフロー


https://japan.xilinx.com/products/design-tools.html




の用語およびプロセスが多く使用されます。通常のパーティションデザインフローと比較した場合の IDF 機能の優

れている点については、ザイリンクスのアプリケーションノートを参照してください。

注記: ザイリンクス 7 シリーズ FPGA または Zynq-7000 AP SoC (Vivado Tools) 用アプリケーションノートのアイソ

レーションデザインフローで Vivado Design Suite を使用した IDF を紹介しています。これらのアプリケーション

ノートでは、 Zynq 7000 AP SoC を対象としていますが、 Zynq UltraScale+ MPSoC デバイスにも適用できます。

IDF フローのコンセプトは、 FPGA 内に独立した領域を作成することです。次の図に例を示します。

図 5‐4: アイソレーションデザイン


COMPAREAES

AES_R

INOUT

led

push_button

reset

data_pins

clkkey_pins

key_addr

key_sel

mode

INOUT

X1086_01_113012

AES_R

この FPGA デザインの例には、 I/O バンド、比較ロジックブロック、 AES (Advanced Encryption Standard)、および冗

長 AES (AES_R) があります。それぞれのエリアは、論理的に分離されており、相互に隔てられています。制御され

た信頼できる通信のみが各ロジックブロック間で可能です。

FPGA の設計手法とコーディングスタイルを使用して、従来の FPGA 開発フローをわずかに変更するだけで安全性

と信頼性に優れたソリューションを実現できます。 IDF 開発では、ロジック、配線、および I/O バッファー (IOB) で

適切な分離が行われるように、設計プロセスのかなり早い段階でフロアプランを検討する必要があります。さらに、

開発フローはパーティションをベースとして進められます。つまり、ユーザーが分離したいと思う各機能はそれぞ

れの階層レベルに配置されている必要があります。

この段階で、設計者は次の 2 つの方法のいずれかを使用できます。

• 不必要に繰り返される適化を回避したい場合、分離された各機能をほかのパーティションから独立させて個

別に合成して実装します。そして、各パーティションの実装後、デザインを 1 つのフラットな FPGA デザイン

にマージしてデバイスをコンフィギュレーションします。

• そのような適化を回避する別の方法としては、分離が必要な各パーティションに IDE 制約を適用できるよう、

少なくとも 1 つのレベルの階層を保持しながらデザイン全体を合成することができます。

このフローは、 FPGA 設計者がこれまで行ってきた開発フローから外れることになりますが、パーティションを使用

する方法には明らかな利点があります。設計サイクルの後半になって分離されたパーティションに変更が必要な場

合、その特定機能のみを変更し、その他のパーティションをそのまま保持できます。


https://japan.xilinx.com/support/documentation-navigation/application-notes.html




注記: グローバルクロック、リセット、および IOB を除くすべてのロジックは 1 つの分離されたパーティションに属

する必要があります。

図 5-5 は、通常の FPGA デザインフローと追加の IDE フロー (右側) を示しています。階層パーティションとロジッ

クパーティションの両方を考慮する必要があります。これらの両方を考慮することで、機能が分離されて相互に干

渉しないことが保証されます。 IDF 検証ツール (VIV) を使用することで、フロアプランの制約やデザインの検証をサ

ポートできます。

図 5‐5: アイソレーションデザインフロー






ザイリンクスの IP

ザイリンクスおよびそのパートナー企業は、厳しい検証に合格した豊富な IP (Intellectual Property) ライブラリを提供

しており、 FPGA の開発にこれらを使用できます。ライブラリは、次のような IP をカバーするカテゴリに分類され

ています。

• インターフェイスおよびインターコネクト

• 通信

• IP ユーティリティ

• DSP および計算

• メモリおよびコントローラー

• デバイスファミリ

• エンベデッド

• オーディオおよびビデオ画像処理

• 特定市場向け IP

https://japan.xilinx.com/products/intellectual-property.html で IP ライブラリを検索できます。

98 ページの「Vivado Design Suite」で説明したとおり、 Vivado IP インテグレーターは、 AXI ベースの共通ユーザー

インターフェイスによって IP の接続をすばやく実行できます。このツールを利用することで、設計期間を数か月

単位で短縮できます。 IP ライブラリには、複数の IP を 1 つのソリューションに統合した IP サブシステムがありま

す。

統合 IP のサポート

PL には、 PCI Express、 100G イーサネット、システムモニター、および Video コーデックユニット用の統合ブロッ

クが含まれています。これらの使用については、ユーザーアプリケーションのユースケースによってさまざまで

す。次のサブセクションでは、これらの PL ペリフェラルについて簡単に説明します。

これらのデバイスのペリフェラルサポートの詳細は、『Zynq UltraScale+ MPSoC テクニカルリファレンスマニュア

ル』 (UG1085) [参照 7] の「PS - PL インターフェイス」セクションを参照してください。

PCI Express

FPGA に小限の FPGA ロジック使用率でトランザクション層、データリンク層、および物理層を実装して、完全

な PCI Express エンドポイントおよびルートポート機能を提供します。

これらの機能は、 PCI Express プロトコルを用いたチップ間のカスタム通信を可能にする互換性のあるルートコン

プレックスを構築するための根幹、またイーサネットコントローラーやファイバーチャネル HBA などの ASSP

エンドポイントデバイスを MPSoC に接続するための根幹を提供します。システムデザインの要件に応じて、

大データレート 2.5Gb/s、 5.0Gb/s、 8.0Gb/s、 16Gb/s のレーン数 1、 2、 4、 8、 16 で動作するようにこのブロックを

構成できます。


https://japan.xilinx.com/products/intellectual-property.html





Interlaken

Interlaken IP は、広帯域幅で信頼性の高いパケット転送に適です。この IP は、レーンロジックとプロトコルロジック

を有効にするチップ間のインターコネクトプロトコルを提供します。プロトコルロジックは、大 150Gb/s まで拡張

できます。大 12.5Gb/s を使用する場合は大 12 レーン、また大 25.78125Gb/s を使用する場合は大 1 ～ 6 レーン

のロジックを構成できます。複数の Interlaken ブロックを持つ UltraScale アーキテクチャデバイスでは、これらを活用

することで信頼性の高い Interlaken スイッチおよびブリッジを簡単に設計できます。

100G イーサネット

IEEE Std 802.3ba に準拠するイーサネット統合ブロックは、ユーザーによるカスタマイズと統計収集をサポートする、

低レイテンシの 100Gb/s イーサネットポートを提供します。 Zynq UltraScale+ MPSoC 100G イーサネットブロックに

は IEEE Std 802.3bj に準拠した RS-FEC (Reed Solomon Forward Error Correction) ブロックが含まれています。この

RS-FEC ブロックは、ユーザーアプリケーションでイーサネットブロックと組み合わせて使用したり、また単独で

も使用できます。

システムモニター

第 8 章「セキュリティ」で説明したとおり、システムモニターブロックは、オンチップの温度と電源センサーを使

用して物理的環境を監視することで、システム全体の安全性、セキュリティ、信頼性を向上させることが可能です。

システムモニターを使用することで、電圧の監視、電流の測定、センサー出力の測定が可能になり、必要な外部ア

ナログ信号を接続する IO ポートが不足している場合には外部マルチプレクサーモードでの使用が可能です。

PL のシステムモニターは、 10 ビット 1MSPS の ADC でセンサー出力をデジタル化します。この計測値はレジスタに

格納され、 PS のプロセッサおよび PMU は APB (Advanced Peripheral Bus) インターフェイスを介してアクセスされま

す。 PL のシステムモニターは、汎用 A/D コンバーターとして使用できます。

ビデオコーデックユニット

「EV」シリーズで利用可能な Zynq® UltraScale+™ MPSoC ビデオコーデックユニット (VCU) は、高効率なビデオ

コーディング (HEVC) H.265 規格や高度なビデオコーディング (AVC) H.264 規格のサポートなど、複数規格のビデオ

エンコーディング/デコーディング機能を提供します。 VCU は、 PS への直接接続がない一部の Zynq UltraScale+

MPSoC の PL 内にある統合ブロックです。 VCU の動作は、レジスタでプログラム可能です。

詳細は、第 9 章「マルチメディア」の「VCU」セクションを参照してください。

コンフィギュレーションおよびパーシャルリコンフィギュレーション

第 3 章「システムソフトウェアの検討事項」および第 8 章「セキュリティ」で説明したとおり、 PL は CSU の PCAP

を使用して起動時に FSBL によって構成されます。場合によっては、起動時に FSBL によって PL を部分的にロード

することが望ましい場合があります。システムの寿命期間中には、 PL を部分的に後から再構成する必要性が生じま

す。

つまり、パーシャルリコンフィギュレーションとは、残りのロジックの動作を継続させながら、部分的なビットス

トリームをダウンロードすることによってロジックブロックを動的に変更できる機能です。このフローでは、複数

コンフィギュレーションの実装が必要です。つまり、各コンフィギュレーションのフルビットストリームと、パー





シャルリコンフィギュレーションに関与する各モジュールのパーシャルビットストリームが生成されます。必要な

コンフィギュレーションの回数は実装する必要のあるモジュールの数によって異なります。

パーシャルリコンフィギュレーションの詳細は次を参照してください。

• 『Vivado Design Suite チュートリアル: パーシャルリコンフィギュレーション』 (UG947) [参照 3]

• パーシャルリコンフィギュレーションのウェブページ [参照 17]

• すべてのコンフィギュレーションでは、同じ上位 (スタティック ) の配置配線結果が使用されます。これらの

スタティックの結果は初期コンフィギュレーションからエクスポートされ、その後のチェックポイントを使用

するすべてのコンフィギュレーションでインポートされます。

FPGA テクノロジは、変更したデザインで製品を再製造しなくても、オンサイトでプログラムまたは再プログラムで

きる柔軟性を提供します。パーシャルリコンフィギュレーションによって、この柔軟性がさらに高まり、パーシャ

ルコンフィギュレーションファイル (パーシャル BIT ファイル) を読み込むことで動作中の FPGA デザインに変更を

加えることができます。フル BIT ファイルで FPGA をコンフィギュレーションした後、パーシャル BIT ファイルを

ダウンロードして FPGA のリコンフィギャラブルな領域を変更できます。このとき、リコンフィギュレーションさ

れない領域で実行されているアプリケーションに影響を与えることはありません。

図 5‐6: パーシャルリコンフィギュレーション


FPGA

ReconfigBlock “A”

A4.bitA3.bit

A2.bitA1.bit

X12001

パーシャルリコンフィギュレーションの基本概念は、フィールドのデバイスにロードしたいすべてのビットスト

リーム (フル/パーシャル) を作成することです。それには、 Zynq UltraScale+ MPSoC がフィールドで動作している間

に、どのデバイスの再構成が必要になるかを把握しておく必要があります。

消費電力削減機能

20nm および 16nm の微細化技術による消費電力の削減は、プログラマブルロジック (PL) 内での機能です。適な電

圧調整がワットあたり性能の向上を実現させること以外に、ザイリンクスは 20nm プロセスデバイスから、アーキ

テクチャブロックに対して数多くの機能強化を行ってきました。また、 16nm では、 UltraRAM、新 PCI Express

Gen4、新タイプ I/O バンクなど、新技術を導入しました。

各固有デザインの総消費電力は 4 つのソース (静的消費電力、動的消費電力、トランシーバー消費電力、 I/O 消費電

力) で構成されます。それぞれが占める割合は、実際に使用されているリソース、頻度、温度、および負荷によって

異なります。ザイリンクスの 28nm 製品と UltraScale+ アーキテクチャベースの FPGA を比較すると、すべての電源

ソースに対して消費電力が削減されています。結果として、 FPGA の電力バジェットを大 50 % まで削減できます。

あるいは同じ電力バジェットの場合には、より高いシステム性能を実現できます。





これらの進歩は、 UltraScale+ アーキテクチャ FPGA に革新的な機能が備わっているためです。たとえば、ザイリン

クスはトランシーバーの設計を見直して、前世代より消費電力を 50 % 削減することに成功しました。 UltraScale+

アーキテクチャ FPGA では、マルチモード I/O が引き続き使用可能で、高性能メモリおよび LVDS インターフェイス

で大幅な消費電力削減が可能です。細かいレベルでのクロックゲーティングといった機能は、 Vivado IDE とシーム

レスに連携し、ロジックの大幅な動的消費電力削減を実現します。ブロック RAM にも、多くの消費電力削減機能が

あります。次の図に、 Zynq UltraScale+ MPSoC デバイスの電力適化機能を示します。

図 5‐7: PL の消費電力削減機能





第 6 章

メモリ

メモリの概要

Zynq® UltraScale+™ MPSoC デバイスに固有のヘテロジニアスコンピューティング機能は、一般的な汎用コンピュー

ティングプロセッサを使用する場合よりも、適切なメモリ構成を提供し、その動作に不可欠な機能を提供します。

Zynq UltraScale+ MPSoC デバイスには、複数のオンチップメモリコンポーネント、メモリアクセス用に多数の制御

機能、高速で効率的な外部メモリインターフェイスが含まれています。この章では、 Zynq UltraScale+ MPSoC デバ

イスのメモリ関連の情報とその使用に関する推奨事項について説明します。

メモリ要件を定義する

ユーザーアプリケーションのメモリ要件を認識し、それらと Zynq UltraScale+ MPSoC デバイスとの関連性を定義す

ることは、設計プロセスの重要な部分です。この章でも説明しますが、 Zynq UltraScale+ MPSoC デバイスのメモリを

設定して使用する方法は多数あります。 Zynq UltraScale+ MPSoC デバイスをベースとするメモリ要件に応じた設計方

法を説明するにあたって、ここでは、第 2 章「プロセッシングシステム」で説明したプロセッシングシステムの設

計手法について理解していることが前提です。つまり、第 2 章で説明したように、ユーザーデザインの主要部分を

Zynq UltraScale+ MPSoC デバイスの主要プロセッシングブロックにどのように分割するかを考えておく必要があり

ます。

これらのことを踏まえた上で、次の質問に応えると、要件に応じた Zynq UltraScale+ MPSoC デバイスのメモリ機能

のカスタマイズに備えることができます。

• デバイスの特定部分で、どの時点でどれくらいのメモリ容量が必要ですか。

• 相互に比較した場合、それらのデザイン部分の動的なメモリ帯域幅の要件何ですか。

• プロセッシングブロックを安全に分離するために処理機能を分割する必要がありますか。

• 扱うデータは常に安全に保管する必要がありますか。

メモリの設計手法

Zynq UltraScale+ MPSoC デバイスにはさまざまな種類のメモリブロックがあり、 Zynq UltraScale+ MPSoC デバイスの

プロセッシングブロックとメモリ間にもさまざまなパスがあります。第 1 章「概要」のアーキテクチャ図は、シス

テム全体と関連するメモリコンポーネントの全体図を示しています。この章では、メモリとそれらの関係に焦点を

当てて説明するため、 Zynq UltraScale+ MPSoC デバイスの概要図を使用します。




第 6 章: メモリ

注記: この図は、 Zynq UltraScale+ MPSoC デバイスの内部コンポーネントを正確に表現したものではなく、このセク

ションで説明する概念を図にしたものです。

メモリの相互関係に焦点を当てた場合、次のようにコンポーネントを 3 つのカテゴリに分類できます。

• ユーザー : 場所にかかわらずさまざまな方法でメモリへアクセスするブロック。

• アービタ : 通過するときにメモリアクセスにフィルタリングまたは条件を付けるブロック。

• プロバイダー : 実際のメモリストレージを提供するブロック。

次の図は、これらのカテゴリに分類した関連する Zynq UltraScale+ MPSoC デバイスのブロックを示しています。青

色の矢印は標準的なフローを示し、それを受けたメモリ参照を示しています。

図 6‐1: メモリ関連の Zynq UltraScale+ MPSoC デバイスのブロックカテゴリ


APU

GPU

RPU

Peripherals

DMA

PL

XMPU

Switch QoS

CCI

DDRC

ExternalMemory

OCM

PL

TCM

Users Arbitrators Providers

PL

Peripherals

X18700-032917

注記: この図は、 Zynq UltraScale+ MPSoC デバイスの内部コンポーネントを正確に表現したものではなく、このセク

ションで説明する概念を図にしたものです。

要するに、実際にはメモリプロバイダーに到達する前に 1 つ (通常は、もっと多く ) のアービタを経由する必要があ

ります。これにはいくつか例外があります。 RPU には、低遅延リンクを介して RPU 内の R5 に直接アクセスできる

密結合メモリ (TCM) が含まれています。また、プロセッシングロジック (PL) をプログラムして外部メモリへのアク

セスを調停したり、 PL のその他の部分から内部アクセスできるメモリや、さほど頻繁ではないがシステムのその他

の部分からアクセスできるメモリを提供したりすることも可能です。

第 2 章「プロセッシングシステム」で説明したとおり、メモリの動作とアクセスは、 Zynq UltraScale+ MPSoC デバ

イスの相互接続に大きく影響を受けます。この章では、スイッチの QoS (Quality of Service)、 CCI (Cache Coherent

Interconnect)、および必要に応じてインターコネクトの QoS を要件に合わせる方法について説明します。ザイリンク

スメモリ保護ユニット (XMPU) は、事実上メモリアクセスをフィルタリングするためのセキュリティブロックであ

り、詳細は第 7 章「リソースの分離と分割」で後述します。

ほとんどのアプリケーションの場合、 256 KB のオンチップメモリ (OCM) 、および各 R5 のサイズが 128 KB のツイ

ン TCM は、完全に機能するシステムを構築するには不十分です。このため、外部メモリが常にデザインの一部とし

て機能します。したがって、デザインに使用する外部メモリのサイズを決めることは、重要な決定事項の 1 つとな

ります。さらに、デフォルトの DDR コントローラー (DDRC) よりも広い帯域幅が必要であるかを判断する必要があ





ります。ほとんどのアプリケーションは、 DDRC の大帯域幅 19,200 MB/s で問題なく機能します。アプリケーショ

ンがこの帯域幅をどのように使用しているのかを把握し、必要な場合に備えてオプションを理解しておくことが重

要です。

アプリケーションが DDRC の大帯域幅の約 60 % 以下を必要とする場合、 Zynq UltraScale+ MPSoC デバイスは、メ

モリに関してはそのまま使用できます。大帯域幅の 60 ～ 80 % の間であれば、ザイリンクスソフトウェア開発

キット (SDK) のシステムパフォーマンスモニタリング (SPM) ツールを使用して、 Zynq UltraScale+ MPSoC デバイス

のメモリ使用量をモデル化し、現状のワークロードでシステムがいかに効率的に動作するかを把握することができ

ます。 SDK については、 34 ページの「QoS のカスタマイズ」で言及しており、詳細は、第 3 章「システムソフト

ウェアの検討事項」を参照してください。しかし、大帯域幅の 90 % に近づくにつれて、追加の外部メモリコント

ローラーが必要になる可能性が高くなります。そのようなコントローラーは、 PL 内に実装することができ、前の図

に示すように、 PL にメモリアクセスのアービタとして機能させることができます。通常のアプリケーションでは、

そのようなコンフィギュレーションを必要としませんが、ビデオ処理や UltraHD を含むシステムでは、追加のメモ

リコントローラーが必要になる可能性が高くなります。

外部メモリの要件は、サイズと ECC の考慮事項によっても左右されます。

ビルトインメモリブロック

Zynq UltraScale+ MPSoC デバイスには、さまざまな状況で使用するためのビルトインメモリとメモリ対応ブロッ

クがいくつか含まれています。このセクションでは、これらのブロックとそれらの一般的な使用法について説明

します。

オンチップメモリ

プロセッシングシステム (PS) のオンチップメモリ (OCM) のサイズは 256 KB です。 OCM には、 DDR コントロー

ラー経由でアクセスすることはできません。 OCM へのインターフェイスは、 PL と PS から接続されています。後者

は、フル電力ドメイン (FPD) と低電力ドメイン (LPD) の両方から OCM にアクセスできます。

DDR よりも OCM を使用する主な理由は、 OCM のレイテンシは DDR コントローラーよりも数サイクル短く、 DDR

よりも高い帯域幅を持つため、より高い性能を実現できるからです。したがって、メモリアクセススピードは重要

でもサイズが制限されている場合は OCM を戦略的に使用することで解決します。性能のために OCM の使用を大

限にする 1 つの方法は、コードではなくデータを格納するために使用することです。コードは外部メモリに格納し

てそこから実行できます。また、外部メモリを使用していない場合や外部メモリをほかの用途に使用したい場合は、

XIP (eXecute-In-Place) 方式を使用してコードを実行することも可能です。たとえば、 Quad-SPI (QSPI) ベースのスト

レージから直接コードを実行できます。

外部メモリの代わりに OCM を使用するもう 1 つの理由はセキュリティです。 OCM は Zynq UltraScale+ MPSoC デバ

イスに組み込まれているため、さまざまなプロセッシングブロックと OCM 間で転送されるデータを攻撃者がス

ヌープすることは不可能です。したがって、 OCM は、暗号キーや機密情報などの重要な一時データを安全に格納す

るための理想的な場所です。保存するオブジェクトが OCM には大きすぎる場合は、 OCM に格納された一時キーを

使用して暗号化し、暗号化されたオブジェクトを外部メモリに保存できます。この場合、外部メモリに格納された

暗号化されたオブジェクトへアクセスするためのキーは OCM に格納されているため、オブジェクトは保護されま

す。

一般に、アプリケーションプロセッシングユニット (APU) およびリアルタイムプロセッシングユニット (RPU) 上

で実行されるソフトウェアは、 OCM を使用できます。さらに、 OCM を使用するシナリオはほかにもあります。た

とえば、ブートプロセスの設定段階で FSBL (第 1 段階ブートローダー ) は、システムのブートモード (セキュア

モード /非セキュアモード ) にかかわらず PS を起動するためのコードを OCM にロードします。 OCM は、 JTAG を介





して不揮発性フラッシュメモリをプログラムする場合にも使用されます。 JTAG ブートモードの場合、フラッシュ

メモリをプログラムするルーチンが OCM にロードされ、その後フラッシュメモリに関するプロセスを引き継ぎま

す。

プログラム可能なロジックメモリ

PL をプログラムして 3 種類のメモリブロックを提供できます。 PL 内で利用できるメモリ容量は限られていますが、

これらのメモリは消費電力が少ない上に、外部メモリよりも高速アクセスが可能です。このことは、 PL でハード

ウェアを設計する際にも重要です。したがって、 Zynq UltraScale+ MPSoC デバイスのプロセッシングブロックが一

般的な目的で PL のメモリ機能を使用するような設定は、後の手段にすべきです。

PL の 3 種類のメモリは異なる特性を持ち、ザイリンクス開発ツールを使用することで、これらはすべて FPGA デザ

イン内にインスタンシエート可能です。

BRAM

ブロック RAM (BRAM) メモリは、以前のザイリンクス FPGA プロセッサで有効なメモリの一種です。 BRAM は、 PL

コンポーネントが使用できる小規模メモリを提供します。 36 KB ブロックで提供されるため、 Zynq UltraScale+

MPSoC デバイスでは、デバイスの種類に応じて PL 全体で大 35 MB の BRAM を含めることができます。 BRAM ユ

ニットは、 2 つの独立した 18 Kb ブロックまたは 1 つの 36 Kb ブロックとして使用できます。使用するポート数は、

2 つまたは 1 つに設定できます。複数の BRAM ブロックを結合して、 1 つのユニットとして使用することも可能で

す。

UltraRAM

UltraRAM は、 Zynq UltraScale+ MPSoC デバイス用の FPGA RAM です。各 UltraRAM ブロックは 288 Kb で、 Zynq

UltraScale+ MPSoC デバイスでは大 128 MB の UltraRAM を利用できます。UltraRAM は BRAM よりも集積度が高い

ため、 FPGA ファブリックのスペースが少なくて済みます。 UltraRAM の集積度が高くなるほど、 BRAM よりも消費

電力を抑えられます。

LUTRAM

LUTRAM (分散 RAM) は、 Zynq® UltraScale+™ MPSoC 上に限られた数だけ存在します。分散 RAM は、 PL 内の LUT

プリミティブで構築されたメモリブロックです。メモリの必要性が低い場合や BRAM のレイテンシが望ましくない

場合には、分散型メモリを使用できます。

密結合メモリ

密結合メモリ (TCM) は、リアルタイムプロセッシングユニット (RPU) 内の Cortex R5 プロセッサコアに接続された

4 バンクの 64 KB メモリです。 TCM により、 RPU は決定的なパフォーマンスと低レイテンシのアクセスを持つメモ

リへ、優先的にアクセスできます。

第 2 章「プロセッシングシステム」で説明したとおり、 R5 プロセッサはスプリットモードまたはロックステップ

モードのいずれかで動作するように設定できます。デフォルトの動作モードはスプリットモードです。このモード

の場合、各 Cortex-R5 プロセッサには ATCM ポートと BTCM ポートと呼ばれる 2 つの 64 ビット幅 64 KB メモリバン

クがあり、合計 128 KB のメモリを利用できます。 TCM を 2 つの部分に分割することで、 R5 CPU または AXI イン

ターフェイス経由でメモリバンクに同時にアクセス可能になります。ロックステップモードの場合は、 TCM を 1 つ

の 256 KB 領域にまとめることができます。 RPU と PS 内のその他の部分との間の通信を可能にするために、 TCM メ





モリは APU またはその他の AXI マスターがアクセスできるグローバルシステムアドレスマップにもマップされま

す。次の図は、 TCM メモリへアクセスできるさまざまな方法を示しています。

図 6‐2: RPU および APU 側からの TCM アドレス空間


Global Address Map

TCMs (256 KB)

LLPP + RPU-GIC

DRAM

BTCM (64 KB)

ATCM (64 KB)

0xFFFF-FFFF RPU Split View

Global Address Map

TCMs (256 KB)

LLPP + RPU-GIC

DRAM

BTCM (128 KB)

ATCM (128 KB)

RPU Lock-step View

Global Address Map

TCMs (256 KB)

APU-GIC

DRAM

APU View

GIC BaseAddr

Top of DRAM

TCMs alias

0x0000-0000

0xFFE0-0000

X15298-092916

注記: グローバルシステムアドレスマップの詳細は、 110 ページの「グローバルシステムメモリマップ」を参照し

てください。

TCM は APU アドレス空間内にマップされますが、 RPU はこの章の前半で説明したメモリアービタを経由せずに、

常に直接低レイテンシパスを通って TCM にアクセスします。

PS DDR メモリおよびコントローラー

Zynq® UltraScale+™ MPSoC PS DDR サブシステムは、 6 つの AXI インターフェイスを使用して第 2 章「プロセッシ

ングシステム」で説明したインターコネクトを介してシステムの残りの部分に接続されます。 DDR サブシステム

は、複数のメモリ規格 (DDR3、 DDR3L、 LPDDR3、 DDR4、 LPDDR4)、および UDIMM と RDIMM の両方をサポート

しています。サポートされている DRAM 総容量は 32 GB です。





図 6‐3: DDR サブシステムのブロック図


AXI Performance

Monitor

XMPU0

FromRPU

XMPU1

FromCCI-400

XMPU2

FromCCI-400

XMPU3 XMPU4

FromAFI3/AFI42x2 Switch

XMPU5

From AFI5FPD-DMA2x2 Switch

QoS ControllerAXI to APB

Bridge

DDR Memory Controller

DDR multiPHY

DDR3, LPDDR3, DDR4, LPDDR4Standard DDR Memory Interface

From Top Switch

FromAFI2/Display Port

2x2 Switch

X15348-092816

インターコネクトの動作および QoS のカスタマイズ方法の詳細は、第 2 章「プロセッシングシステム」を参照して

ください。上記の図に示す「QoS コントローラー」は、スイッチベースの QoS と CCI ベースの QoS (第 2 章の各セク

ションで説明) を使用して設定されたポリシーを実行します。

グローバルシステムメモリマップ

Zynq UltraScale+ MPSoC デバイスのグローバルシステムアドレスマップ空間は 1TB に及んでおり、複数タイプの

AXI マスターに対応するように構築されています。たとえば、 RPU の R5 は 32 ビットのプロセッサであるのに対し、

APU の A53 は 64 ビットまたは 32 ビットのプロセッサとなります。したがって、基本的に 64 ビットモードの A53

は R5 よりも多くのメモリ容量に対応できます。 32 ビットのプロセッサは大 4GB まで対応でき、 64 ビットのプロ

セッサは理論的には大 16GB まで対応できます。実際、 ARMv8-A は大 48 ビットのアドレス指定しかサポートし

ていません。システムメモリマップは、両方のタイプの AXI マスターに対応し、 32 ビット、 36 ビット、または 40

ビットのシステムアドレスをサポートするように構成できます。

ページテーブル変換では、変換ステージ間でアドレスを変換するためにメモリ管理ハードウェアがページテーブル

をウォークスルーする必要があります。アドレス空間が広くなるほど、ウォークスルーするテーブルが増加します。

たとえば、 4 KB のページでは、 40 ビット幅のアドレスは 4 つのテーブルをウォークスルーする必要があり、 36 ビッ





ト幅のアドレスは 3 つ必要であり、 32 ビット幅のアドレスは 2 つ必要です。したがって、より広いアドレス空間

に対応できるプロセッサであっても、できるだけ少ないアドレスビットを使用することでメモリアクセスを高速

化できるという利点があります。

次に示す Zynq UltraScale+ MPSoC デバイスのシステムアドレスは、 32 ビットマスター、および 64 ビットに対応で

きるマスター用に適化された 36 ビットアクセスをサポートしています。

図 6‐4: Zynq UltraScale+ MPSoC デバイスのシステムアドレスマップ


FooDDR - 2GBFooLPD-PL - 512 MBFooHPM0 - 256MBFooHPM1 - 256MB

QSPI - 512MBFooLower PCIe - 256MBFooReserved - 128MB

CoreSight STM 4MB per master ID - 16MBRPU Low Latency Peripheral Port - 1MB

Reserved - 63MBFPS Slaves Includes FPS Top Slaves - 16MBLPS Slaves Includes LPS Top Slaves - 28MB

CSU/PMU/TCM/OCM - 4MBReserved - 12GB

FooPL - 8GBFooPCIe - 8 GB

DDR - 32GBPL - 448GB

PCIe - 256 GBFooReserved - 256GB

32-bitAddressSpace

36-bitAddressSpace

40-bitAddressSpace

0GB2GB

3GB

4GB16GB24GB32GB64GB512GB768GB1TB

X18701-032117

注記: 16 ExaBytes、 16*1,024 PetaBytes、または 16*1,024*1,1024 TeraBytes です。

Zynq UltraScale+ MPSoC デバイスでは、 DDR などの重要なシステムコンポーネントを 32 ビット対応のマスターがア

クセスできる下位 32 ビットのアドレス指定可能な空間にマップすることにより、これらのマスターが大部分のオン

チップペリフェラルおよび機能を使用できるようになります。それを超える 36 ビットアドレス空間にマップする

と、 64 ビットのマスターが、その他の DDR を含むも頻繁に必要とされるリソースへすばやくアクセスできるよう

になります。後に、 40 ビットのアドレス空間にマップすると、 64 ビットのマスターが、 Zynq UltraScale+ MPSoC

デバイスの機能へアクセスできます。 64 ビットのマスターには、 APU、 PCIe、 SATA、 DisplayPort、フル電力ドメイ

ンダイレクトメモリアクセス (FPD-DMA)、 USB、ギガビットイーサネット MAC (GEM)、 SD、 NAND、 QSPI、コ

ンフィギュレーションセキュリティユニット (CSU) DMA、および低電力ドメインダイレクトメモリアクセス

(LPD-DMA) のインターコネクトがあります。

PS DMA コントローラー

新の SoC と同様に、 Zynq UltraScale+ MPSoC デバイス上で大量のデータを転送するも効率的な方法は、 DMA コ

ントローラーを使用することです。これによって、さまざまな CPU コアへの関与を回避できます。 Zynq UltraScale+





MPSoC デバイスには、 2 つの汎用 DMA コントローラーといくつかのペリフェラル特有の DMA エンジンが含まれて

います。前者は、メモリ間、メモリと I/O 間、および I/O 間の転送をサポートします。後者については、第 10 章

「ペリフェラル」で詳しく説明します。また、ザイリンクスでは、 IP カタログで PL DMA コアを提供しています。

汎用コントローラーの 1 つはフル電力ドメイン (FPD-DMA) にあり、もう 1 つは低電力ドメイン (LPD-DMA) にあり

ます。この 2 つの汎用 DMA コントローラーは同一であり、 8 つの独立した DMA チャネルを使用して、 1 つの共通

バッファーを内部で共有して大 AXI 帯域幅を使用します。これらは両方とも、 QoS、 TrustZone、 OverFetch、およ

び整列していない転送をサポートしています。また、どちらも通知の割り込みを発生させることができ、シンプル

DMA とスキャッターギャザー DMA の 2 つの転送モードに対応できます。

これらのコントローラーの相違点の 1 つは、共通バッファーのサイズです。 FPD-DMA は 128 ビットの AXI バスに接

続され、 4 K の内部共通バッファーを使用し、 LPD-DMA は 64 ビットの AXI バスに接続され、 2 K の共通バッファー

を使用します。共通バッファーはコントローラーで自動的に管理されますが、各チャネルのレートコントローラー

と読み出し発行レジスタを調整することによって、各チャネルのバッファーの使用状況をある程度操作することも

可能です。

コントローラー間のもう 1 つの相違点は、 LPD-DMA が I/O コヒーレントであるのに対して、 FPD-DMA が I/O コ

ヒーレントでないことです。 LPD-DMA 転送は CCI を経由するため I/O コヒーレントとなりますが、 FPD-DMA は

CCI を経由せずに直接 DDR へアクセスします。したがって、 FPD-DMA 転送は、コヒーレンシを確保するためにソ

フトウェアサポートが必要となります。





次の図は、各汎用 DMA コントローラーの内部を示しています。

図 6‐5: DMA のブロック図


DMA Channel 1

DMAChannel 7

MUX

CommonBuffer

Read Arbiter

Write Arbiter

APB Registers APB

DMAChannel 0

RDATA

AXI RD CMD AXI WR CMD

WDATA

X15366-092516

シンプル DMA

シンプル DMA モードでは、転送コマンドが単一の命令としてコントローラーに発行されます。この DMA 要求のプ

ログラミングモデルは、次のようになります。

1. データ転送ソースアドレスのデスティネーションアドレスが DMA チャネルレジスタにプログラムされます。

2. ソースのサイズとデスティネーションバッファーは、同じチャネルレジスタ内にプログラムされます。

3. 必要に応じて、チャネルで割り込みが有効になります。

4. DMA 転送が開始されます。

割り込みが有効な場合、 DMA コントローラーがメモリの読み出しを完了すると割り込みが生成され、 DMA コント

ローラーがメモリへの書き込みを完了すると、また別の割り込みが生成されます。

要求された DMA 読み出しがメモリページの境界を越える場合、 DMA コントローラーはオプションの指示に従っ

て、その境界まで残りのデータをフェッチすることができます。これが OverFetch 機能です。この機能が無効になっ

ている場合、不完全なメモリページへの読み出し要求は、シングルバイト読み出しを複数回実行して完了します。

シンプル DMA モードには、 2 つのサブモードがあります。





• Read-only: 読み出し専用モードでは、 DMA チャネルはメモリからデータを読み出すだけで、データを書き込む

ことはできません。このモードは、可能性のあるエラー訂正コード (ECC) エラーを訂正するために、メモリス

クラブを行うのに役立ちます。

• Write-only: 書き込み専用モードでは、 DMA チャネルは DMA チャネルレジスタからあらかじめロードしたデー

タをメモリに書き込みます。このモードは、メモリブロックをすばやく初期化するのに役立ちます。

スキャッターギャザー DMA

スキャッターギャザー DMA は、データソースとデータデスティネーションがバッファーディスクリプター (BD)

フォーマットで指定される、より複雑な動作モードです。 DMA コントローラーは、異なるニーズに対応できる 3 つ

の異なるディスクリプターフォーマットをサポートしています。

• リニア: リニア BD は、リニアアレイに格納されます。各 128 ビットディスクリプターには、 DMA 転送用の

ソースアドレスとデスティネーションアドレスが含まれます。

• 連結リスト : 連結リスト BD は 256 ビット幅です。リニアディスクリプターと同じ情報を含みますが、次の BD

のアドレス ( メモリ内のどこに配置されていても問題ない) も含みます。

• ハイブリッド : ハイブリッドモードでは、 2 種類の BD が混在可能です。 2 つのパターンを同時に使用するこの

モードでは、メモリページの境界でのみ連結リスト BD を使用し、その他のページではリニア BD を使用しま

す。





次の図にこれらの 3 つのフォーマットを示します。

図 6‐6: サポートされているスキャッターギャザーのユースケース


Dscr0

Dscr1

Dscr2

Dscr3

Dscr4

Dscr5

Dscr6

Dscr7

Dscr0

Dscr1

Dscr2

Dscr3

Dscr4

Dscr5

Dscr6

Next Addr

Dscr3Next Addr

Dscr0Next Addr

Dscr7

Dscr8

Dscr13

Next Addr

Dscr5Next Addr

Dscr4Next Addr

Dscr2Next Addr

Dscr1Next Addr

Linear Descriptor Mode Linked-List Descriptor Mode Hybrid Descriptor Mode

128-bit DescriptorDescriptor Element

Type = 0

256-bit DescriptorDescriptor Element

Type = 1

128 and 256-bit DescriptorDescriptor Element Type = 0 and 1

Linked-List Descriptor is OnlyUsed on Page Boundary

X15368-092516

スキャッターギャザー DMA は割り込みもサポートしています。生成された割り込みの数は、専用のアカウンティ

ングレジスタを使用して管理されます。このレジスタは、 DMA コントローラーで処理されるディスクリプターごと

にインクリメントされます。アプリケーションは、このレジスタを参照して DMA 転送ステータスを把握し、必要に

応じてレジスタをリセットできます。

ペリフェラル DMA

前述のように、 Zynq® UltraScale+™ MPSoC の高速ペリフェラルには、独自の DMA コントローラーが付属していま

す。各ペリフェラルの DMA の特性は、それぞれに固有となります。詳細は、第 10 章「ペリフェラル」を参照して

ください。次の表は、各高速ペリフェラルの DMA に関する情報をまとめたものです。





図 6‐7: ペリフェラルの DMA サポート


使用およびプログラミング

通常、第 2 章「プロセッシングシステム」で説明したプロセッシングユニット上で動作する OS やドライバーは、

さまざまな DMA コントローラーをプログラムおよびインターフェイスします。したがって、 DMA の適な使用方

法とリソースの分割方法の分析は、ソフトウェア全体の設計プロセスの一環として実行するのが適しています。さ

らに、 DMA コントローラーは、 AXI バス上にあるその他多数のコンポーネントと同様の AXI マスターであることに

留意してください。したがって、 DMA トラフィックの優先順位付けは、第 2 章で説明した QoS を調整する場合と同

じ技術を使用して実行できます。

PL を使用する外部メモリ

既に説明したとおり、 Zynq UltraScale+ MPSoC デバイスの PL を使用して外部 DDR メモリへ接続できます。これは、

ザイリンクスが提供する特別な IP ブロックジェネレーターを使用することで可能になります。メモリインターフェ

イスジェネレーター (MIG) を使用して、 FPGA の PL ファブリックに統合するのに必要なブロックを生成します。

MIG は、次のダイナミック RAM 用インターフェイスを生成できます。

• DDR3/DDR4

• QDR II+

• QDR-IV

• RLDRAM

DDR3 および DDR4 の場合、 MIG は次のような構造を生成します。





図 6‐8: MIG で生成される一般的なブロック


User FPGA Logic

A User Interface

Memory Controller

Initialization/Calibration

Physical Layer

DDR3/DDR4

SDRAM

UltraScale Architecture-Based FPGAs

UltraScale Architecture-Based FPGAs Memory Interface Solution

CalDone

Read Data

1

0

物理層 (PHY) は、 DDR メモリの動作に必要な低レベル信号を扱います。キャリブレーションを実行し、メモリの読

み書きに必要な正確なタイミング信号を生成します。また、電源投入時には RAM の初期化も実行します。メモリコ

ントローラー (MC) は、ユーザーインターフェイスからの書き込み/読み出しトランザクション要求を処理し、それ

らを物理層に転送します。また、必要に応じてメモリ ECC 機能も実行します。

MIG を使用することで、 PL ブロックを介して追加の外部メモリへアクセスできるようになります。つまり、 PL が

システムのその他の部分から独立してメモリを使用できるようになり、また外部メモリを別のコンポーネントと共

有できるようになります。たとえば、 PL に内蔵されているビデオコーデックユニット (VCU) が、ソフト DDR コン

トローラーで制御される追加の外部メモリを使用できるようになります。 PL を介してメモリを拡張して使用するも

う 1 つの目的は、前にも言及しましたが、 PS DDR コントローラーを用いる Zynq UltraScale+ MPSoC デバイスの大

メモリアクセス帯域幅である 19,200 MB/s 以上を達成するためです。




第 7 章

リソースの分離と分割Zynq® UltraScale+™ MPSoC デバイスはヘテロジニアスコンピューティングデバイスであるため、種類の異なるプロ

セッシングブロック、ペリフェラル、およびメモリを内蔵しています。 Zynq UltraScale+ MPSoC デバイスには、こ

れらのリソースをグループにまとめ、グループごとに分割および分離できる重要な機能があります。この機能を使

用すると、設計者は複数の独立したサブシステムを作成し、必要なハードウェアリソースにはアクセスしつつもほ

かのサブシステムからは保護されるようにできます。こうすることで、サブシステムをまたいだ攻撃を防ぐことが

できます。また、 Zynq UltraScale+ MPSoC デバイスのプロセッシングブロックには、指定したサブシステムの内部

を分割および分離するサブシステム内セキュリティメカニズムもいくつかあります。この章では、 Zynq UltraScale+

MPSoC デバイスのリソース分離/分割メカニズムおよびその使用に関する推奨事項について説明します。

リソース分離/分割の要件を定義する

リソース分離/分割の要件を定義するには、まず Zynq UltraScale+ MPSoC デバイスの主要なコンポーネントとそれぞ

れの関係、およびそれらの代表的な使用方法について理解しておく必要があります。したがって、この章に進む前

に少なくとも第 2 章「プロセッシングシステム」、第 3 章「システムソフトウェアの検討事項」、および第 6 章「メ

モリ」の内容を理解しておく必要があります。この章で見ていくように、 Zynq UltraScale+ MPSoC デバイスには非常

に柔軟なリソース分離/分割の機能があります。これらの機能を使用する上での指針として、まずはデザイン内で独

立した形で共存する複数の区分を明確に定義する必要があります。この区分は、相補的な機能を備えた共存するサ

ブシステムとして多少なりとも明確に識別できるものとします。完全または部分的に互いを分離または保護する必

要があるかどうかは問いません。

この作業を進めるにあたり、まずは次の質問に答えてみてください。

• 第 2 章「プロセッシングシステム」で説明した Zynq UltraScale+ MPSoC デバイスの主要なコンポーネントの間

でデザインのワークロードを主にどのように分割しますか。つまり、アプリケーションプロセッシングユニッ

ト (APU)、リアルタイムプロセッシングユニット (RPU)、プログラマブルロジック (PL) でそれぞれどのような

ワークロードを実行しようと考えていますか。

• 先の質問で分割したワークロードを、明確に識別できる複数のサブシステムにグループ化できますか。別の言

い方をすると、 Zynq UltraScale+ MPSoC デバイスのヘテロジニアスコンピューティング機能に基づいてデザイ

ン全体を複数のサブシステムに分けられますか。

• Zynq UltraScale+ MPSoC デバイス上で異なる実行環境 (すなわちサブシステム) を同時に並行してホスティング

する必要があり、なおかつこれらをそれぞれ強固に分離する必要がありますか。たとえば次のような場合です。

° APU 上で複数の実行環境を分離する必要がありますか。

° APU 上での処理と RPU 上での処理を分離する必要がありますか。




第 7 章: リソースの分離と分割

• 特定のペリフェラルやメモリへのアクセスを、それらが属するサブシステムに基づいて制限または制御する必

要がありますか。たとえば次のような場合です。

° APU のみが DisplayPort にアクセスできるようにしたいですか。

° RPU のみが CAN (Controller Area Network) バスにアクセスできるようにしたいですか。

° RAM の一部を RPU のみがアクセスできる領域にしたいですか。

リソースの分離と分割に関する設計手法

Zynq UltraScale+ MPSoC デバイスのリソース分離/分割機能およびその適な使用方法を理解するには、いくつかの

システムコンポーネントについて見ていく必要があります。これまでの章と同様に、詳細はこの後のセクションに

譲るとして、このセクションでは詳細を理解する上で必要となる重要な概念のみを紹介します。そうすることで、

前のセクションの質問の答えがよくわからなかった方も、デザインを独立した複数のサブシステムに分割して保護

できるかどうか、そしてその方法についてよりよく理解できるようになります。

これまでの章で、 Zynq UltraScale+ MPSoC デバイスのリソースとブロックをいくつかの異なる視点から紹介してきま

した。次の図は、リソースの分離/分割の視点から Zynq UltraScale+ MPSoC デバイスのブロックを大きく 3 つのカテ

ゴリに分類しています。

図 7‐1: Zynq UltraScale+ MPSoC デバイスのリソースおよび相互通信の概略図


PeripheralsProcessing Blocks& General-Purpose DMA

Memory* GPU support is OS-specific

TCM

DDRCMemoryy

OCM

FPDPeripherals

PLPeripherals

LPDPeripherals

RPU

PL

GPDMA

APU

GPU*

PL/MIG

X18702-032917

注記: これらカテゴリと次に示す図は Zynq UltraScale+ MPSoC デバイスの内部ブロックを正確に表現したものではな

く、このセクションで説明する概念を図にしたものです。





この図で示した 3 つのカテゴリは次のとおりです。

• プロセッシングブロックおよび汎用ダイレクトメモリアクセス (DMA)

Zynq UltraScale+ MPSoC デバイスのほとんどのアクセス、転送、および通信を開始/制御するブロックはすべて

ここに属します。

• ペリフェラル

すべての電源ドメインのすべてのペリフェラル、すなわち低電力ドメイン (LPD) とフル電力ドメインのペリ

フェラル、および PL に作成したすべてのペリフェラルがここに属します。

• メモリ

Zynq UltraScale+ MPSoC デバイス内に存在するメモリブロック、および Zynq UltraScale+ MPSoC デバイスによっ

てアクセス可能なメモリブロックはすべてここに属します。

矢印は、代表的なアクセスが開始される方向を示しています。通常、各種プロセッシングブロックおよび汎用 DMA

はペリフェラルまたはメモリに接続して所定のワークロードを実行します。これに対し、ペリフェラルは主に I/O の

ためにメモリに接続します。メモリバンク自体が通信を開始することはありません。

図の矢印は、より厳密に言えば AXI トラフィックの方向を示しています。第 2 章「プロセッシングシステム」で説

明したように、 Zynq UltraScale+ MPSoC デバイスの内部インターコネクトは ARM 社が定義したいくつかの標準規格

に基づいています。これらの規格の中心概念となるのが、 AXI マスターおよび AXI スレーブと呼ばれるエンドポイ

ントです。読み出し /書き込み要求を開始するのが AXI マスターで、これらの要求に応答するのが AXI スレーブで

す。したがって、プロセッシングブロックおよび汎用 DMA からペリフェラルへの矢印は、前者の AXI マスターか

ら後者の AXI スレーブに対してトラフィックが開始されることを意味しています。通常、この種のアクセスはプロ

セッシングブロックがペリフェラルの制御レジスタにアクセスしたり、ペリフェラルに対して特定の動作を要求し

たりする目的で使用します。第 10 章「ペリフェラル」で説明するように、 Zynq UltraScale+ MPSoC デバイスのほと

んどのペリフェラルには DMA 対応 AXI マスターもあり、プロセッシングブロックで適切にプログラムするとこれ

らのペリフェラルからメモリにアクセスしてデータを送受信できます。これを表しているのが、ペリフェラルから

メモリへの矢印です。

なお、プロセッシングブロックのカテゴリに示した GP DMA ブロックには、第 6 章「メモリ」で説明した低電力ド

メイン (LPD) 汎用 DMA コントローラーとフル電力ドメイン (FPD) 汎用 DMA コントローラーの両方が含まれます。

どちらも、AXI スレーブポートを介してそれぞれ LPD ペリフェラルまたは FPD ペリフェラルとしてプログラムでき

ます。ただし前述のとおり、この図は Zynq UltraScale+ MPSoC デバイスの主要な機能を大まかな概念図として示し

たもので、詳細は省略しています。インターコネクトの詳細図は、第 2 章「プロセッシングシステム」を参照して

ください。

Zynq UltraScale+ MPSoC デバイス内部では、上記の 3 つの主要な境界は次に示す 3 つの相補的な保護メカニズムに

よって保護されます。





図 7‐2: Zynq UltraScale+ MPSoC デバイスのリソースと保護メカニズム


XMPUXMPU

XPPU

SMMU

SMMU


MemorySM

MU

FPDPeripherals

LPDPeripherals

PLPeripherals

GPDMA XMPU

RPU

PL

GPU*

APU

XPPU


TCMOCM

PL/MIG

DDRCMemory

X18704-032917

システム設計者は、相補的に機能するシステムメモリ管理ユニット (SMMU)、ザイリンクスメモリ保護ユニット

(XMPU) およびザイリンクスペリフェラル保護ユニット (XPPU) を利用してリソースを分離および分割できます。

次に、それぞれについて説明します。

• SMMU (詳細は第 2 章「プロセッシングシステム」参照): DMA 対応デバイスから仮想アドレスを参照できるよ

うにします。これらの仮想アドレスは、ハイパーバイザーゲストが必要とする仮想物理アドレス、または APU

上でネイティブに動作するオペレーティングシステムが使用する実際の物理アドレスに SMMU が直接マップし

ます。

• XMPU (詳細は 132 ページの「ザイリンクスメモリ保護ユニット」参照): アクセス要求を開始した AXI マスター

の ID などに基づいてメモリおよび FPD ペリフェラルへのアクセスをフィルタリングします。

• XPPU (詳細は 134 ページの「ザイリンクスペリフェラル保護ユニット」参照): アクセス要求を開始した AXI マ

スターの ID などに基づいて LPD ペリフェラルへのアクセスをフィルタリングします。

上の図に示したように、これら 3 つの保護メカニズムには何とおりかの組み合わせがあり、プロセッシングブロッ

ク、ペリフェラルおよびメモリの各境界で使用できる保護メカニズムが異なります。 Zynq UltraScale+ MPSoC デバイ

スの各種ブロック間のパスで使用される保護メカニズムの詳細は、第 2 章「プロセッシングシステム」で示したイ

ンターコネクトの詳細図を参照してください。次の図は、ここでの説明に関係する部分のみをアクセス相関図とし

てまとめたものです。





図 7‐3: 分離/分割パスの詳細図


XMPU XMPU

XP

PU

SMMU

SMMU


MemoryOCM

TCM

DDRCMemory

MM

SM

MU

FPDPeripherals

LPDPeripherals

PLPeripherals

DDMADGPD XM

PUU

RPURPPURPPUP

PLLP

TrustZ

one

Secure

Non-Secure

Linu

xnuAp

psAp

pP1

P2

P3P4

GPU*

Xen

PPUAP

XPPU


PL/MIG

X18703-032917

この図で、矢印の色はその色のコンポーネントからの、またはその色のコンポーネントへのアクセスに使用するこ

とを表しています。 RPU を例に説明します。 RPU を表す円にはピンク色の部分があります。これは、ピンク色の矢

印を使用して XPPU 経由で LPD ペリフェラルにアクセスすることを意味しています。また、 RPU を表す円には黄色

の部分もあります。これは、黄色の矢印を使用して黄色の TCM にアクセスすることを意味しています。このアクセ

スは、 SMMU、 XMPU、 XPPU のいずれも経由しません。第 6 章「メモリ」で説明したように、 TCM にはグローバ

ルメモリマップを使用してシステム全体からアクセスできますが、 TCM は RPU 内部に存在しているため、 RPU か

らのアクセス方法のみが異なります。これに対し、 APU から TCM へのアクセスには APU から LPD ペリフェラルへ

のアクセス同様、 XPPU を経由するピンク色の矢印を使用します。

ここではすべての矢印について詳細な説明は省きますが、この図からわかる重要な点がいくつかあります。なお、

前述のとおり矢印は AXI マスターから AXI スレーブへの AXI トラフィックの方向を示しています。

第一に、ほとんどの矢印が XMPU または XPPU を経由していることに注目してください。唯一の例外は、同じサブ

システムに属する内部コンポーネント間のアクセス (RPU 内部に存在する TCM、 PL の内部に存在する PL ペリフェ

ラル) です。これらの例外を除き、同じ電源ドメインに属する場合も含め、すべてのアクセスに XMPU および XPPU

で設定した規則が適用されます。たとえば APU と FPD ペリフェラルはすべてフル電力ドメイン (FPD) に属します

が、これら 2 つの間のアクセスはすべて XMPU を経由します。同様に、 RPU と LPD ペリフェラルはどちらも低電力

ドメイン (LPD) に属しますが、これらの間のアクセスはすべて XPPU を経由します。つまり、 XMPU と XPPU を適

切に設定しておけば、システム内のすべてのアクセスを常時制御できることになります。

第二に、 SMMU の役割に注目してください。汎用 DMA を使用する場合、またはペリフェラルからメモリにアクセ

スする場合は必ず SMMU を経由します。前述のとおり、そして第 2 章「プロセッシングシステム」でも説明したよ

うに、 SMMU をネイティブ (すなわち仮想化していない) OS で使用した場合、 DMA 対応デバイスに対する 2 段階の

アドレス変換を実行します。また、 I/O およびハイパーバイザーで使用するアドレス仮想化もサポートします。仮想

化していない環境で SMMU を使用すると、デバイスは自分自身に割り当てられたアドレスにしかアクセスできませ

ん。仮想化環境では、 APU 上で動作するゲスト OS が使用するメモリ空間にデバイスアドレスを正しくマップする

ことも SMMU の役割となります。つまり、ゲスト OS はペリフェラル DMA に実際の物理アドレスを明示的にプロ

グラムするわけではありません。ペリフェラルからメモリへのアクセスは途中で必ず SMMU を経由するため、ゲス

ト OS が提供するアドレスとペリフェラルが使用するアドレスが正しく変換されます。





第三に、 APU にはこれまで述べた以外にも、 APU 上で動作するソフトウェアを分離および分割するためのメカニズ

ムが複数存在することに注目してください。も下層レベルでは、 TrustZone によって APU をセキュア実行環境と非

セキュア実行環境に分割できます。後述するように、セキュア/非セキュアステートは AXI トランザクションで伝達

され、 XMPU/XPPU はこの情報に基づいて要求を適切にフィルタリングします。また、第 3 章「システムソフト

ウェアの検討事項」で説明したように Xen などのハイパーバイザーを使用して APU の A53 コアを複数のゲストに分

割できます。あるいは、第 3 章で説明したように Linux などの OS を使用して A53 コアを対称型マルチプロセッシン

グ (SMP) モードで直接管理することもできます。ハイパーバイザーを使用するかどうかにかかわらず、ハイレベル

OS は通常 A53 のメモリ管理ユニット (MMU) を使用してプロセスどうし、および OS とユーザー空間プロセスを分

離して保護します。

後に、 PL および PL ペリフェラルに対する規則はある程度設定可能であることに注目してください。たとえば PL

からメモリへのアクセスで SMMU を経由するかどうかは、 PL 側で使用する AXI ポートによって異なります。また、

デフォルトでは PL 内のペリフェラルに PL 外部のコンポーネントからはアクセスできません。このように PL IP は

ユーザーによる設定が必要で、その際に必要に応じて AXI フィルタリング規則を IP に追加できます。この例につい

ては後述します。

前述のとおり、これらのメカニズムを組み合わせることによってデザインを複数の独立したサブシステムに分割で

きます。次の図は、このように分割したデザインの例を示したものです。

図 7‐4: サブシステムに分離および分割した例


Subsystem A

APU GPU

Processing

Peripherals

Low-PowerDomain

Full-PowerDomain

USB

eMMC

PCIe

DisplayPort

Ether-net

Subsystem B

RPU

Processing

Peripherals

Low-PowerDomain

Full-PowerDomain

OCM

CAN

SATA

GPIO

Subsystem C

PLPeripheralsPL

X18705-032117

この図の例では、 Zynq UltraScale+ MPSoC デバイスの保護メカニズムを使用してデザイン全体を 3 つの独立したサブ

システムに分割しています。各サブシステムにはそれぞれ異なるプロセッシングブロックが属しており、これらは

そのブロック内の主要なプロセッシングエージェントとして動作し、そのサブシステムのペリフェラルにアクセス

します。ここで、サブシステム A とサブシステム B のどちらの場合も、それぞれ異なる電源ドメインに属するプロ

セッシングブロックとペリフェラルが存在することに注目してください。たとえばサブシステム A の APU は FPD

に属します。しかし XPPU を使用すると、 LPD に属するペリフェラル (USB、 eMMC、イーサネット ) に APU から排

他的にアクセスできます。サブシステム B でも、同じ方法で LPD に属する RPU が FPD に属する SATA インターフェ

イスに排他的にアクセスできます。したがって、第 4 章「パワーマネージメントに関する注意事項」で説明した方

法で電源ドメインを使用しても、 Zynq UltraScale+ MPSoC デバイスのリソース分離および分割機能には影響しませ

ん。





この例では、サブシステム A のペリフェラルにはサブシステム B からアクセスできず、サブシステム B のペリフェ

ラルにはサブシステム A からアクセスできません。たとえば SATA インターフェイスはサブシステム B 専用でサブ

システム A からはアクセスできません。反対に、 DisplayPort はサブシステム A 専用でサブシステム B からはアクセ

スできません。このアクセス制限はインターコネクトレベルで実行されます。インターコネクトのコンフィギュ

レーションはブート時に読み出し専用に設定できます。したがってこのアーキテクチャは、システムリソースへの

不正アクセスに対する非常に強力な防御となります。たとえば APU 上で動作するソフトウェアが実行時にこれらの

規則を変更しようとしても、そのような手段は存在しません。実質的に、 Zynq UltraScale+ MPSoC デバイスの分離/

分割機能はサブシステム A とサブシステム B がそれぞれ物理的に切り離されたデバイスであるかのように分割する

ためのものです。

同様の保護機能は、サブシステム A/B とサブシステム C の間にも存在します。ただし、サブシステム A/B からサブ

システム C を保護する方法はこれまでの説明とはやや異なります。 PL の場合、 PL ブロックへのアクセスは XMPU

も XPPU も経由しません。 PL IP は、 PL の AXI スレーブポートで受信したトラフィックを AXI マスターの ID に基

づいてフィルタリングするようにコンフィギュレーションできます。つまり、特定の PL AXI スレーブポートで受信

した AXI トラフィックを要求発行元の AXI ブロックの ID に基づいて設計者がブロックできます。たとえば PL の特

定の AXI スレーブポートが APU に対してのみ応答するように設定できます。この場合、 RPU からその AXI スレー

ブに対してアクセス要求を発行すると拒否されます。つまり、 PL の IP をカスタマイズすることにより、 Zynq

UltraScale+ MPSoC デバイスのほかのコンポーネントに対して XMPU や XPPU が提供するのと同程度に厳密な制御を

実装できます。

分離/分割の例は先に示したもの以外にも数多く存在します。実際のデザインでこのような分割が必要かどうか、そ

して必要な場合はどのような方法で分割するかは、個々のデザインの要件および仕様によって決まります。すべて

の場合に当てはまる、特に決まった規則というものはありません。 1 つだけ挙げるとすれば、前述のとおり、サブシ

ステムの分割を明確にし、基本的な設計目標を達成するために Zynq UltraScale+ MPSoC デバイスの機能をどのよう

に使用すればよいのかを理解する作業に十分な時間をかける必要があります。

もう 1 つ言えるのは、 Zynq UltraScale+ MPSoC デバイスのリソース分離/分割機能をデザインに組み込むとセキュリ

ティの向上に確実に寄与するという点です。早い段階からこれらの機能に対する理解をチーム全体で深めておけば、

必要に応じて微調整を重ねていくことができます。これの機能が不要と判断した場合でも、その判断を後から見直

すこともできます。ただしセキュリティ制約を後付けするのは往々にしてシステムの実装が進むにつれて難しくな

ることに注意が必要です。このため、デザインの要件にセキュリティが含まれる場合、またはプロジェクトの途中

で要件に加わる可能性が予想される場合は、この章の内容を真剣に吟味することを強く推奨します。





ARM TrustZone

Zynq UltraScale+ MPSoC デバイスのいくつかの機能では、 ARM TrustZone テクノロジおよびその基礎概念が重要な役

割を果たしています。前述のとおり、たとえば XMPU と XPPU には ARM TrustZone で定義したセキュリティステー

トに基づいてアクセスをフィルタリングする機能があります。しかし多くの理由により、 TrustZone は経験豊富な

チームにとっても決して扱いやすいトピックではありません。それでも、 TrustZone の内容および実際のユーザーデ

ザインで TrustZone が Zynq UltraScale+ MPSoC デバイスの全体的な機能にどのように組み込まれているかを十分に理

解しておく必要があります。このセクションでは TrustZone の概要、 Zynq UltraScale+ MPSoC デバイスにおける

TrustZone の使用、および TrustZone を中心としたデザインのカスタマイズ方法について説明します。

TrustZone の基礎

TrustZone の動作を理解するには、まず現在のプロセッサが複数の特権をどのように分離しているのかについて見てい

く必要があります。現在のプロセッサ設計では、特権モードと非特権モードの少なくとも 2 つの動作モードが存在す

るものがほとんどです。特権モードは OS が使用し、非特権モードは通常のアプリケーションが使用します。通常、

プロセッサには特権モードでのみ使用可能なオペランドとレジスタがあります。このため、 OS にはシステム制御に

関してプロセッサの構成を超えた権限が与えられます。プロセッサの MMU でもこのような分離が徹底されるため、

非特権モードのアプリケーションから OS への不正なアクセスを防ぐことができます。

この特権モードと非特権モードという分離方式はさまざまなプロセッサアーキテクチャに見られ、ソフトウェアの

分野では「カーネル空間」と「ユーザー空間」という用語で区別されることもあります。これ以外にも、「OS がリ

ング 0 で動作する」という表現をすることがあります。これは、複数の特権「リング」が存在し、 OS がも内側の

リングで動作していることを意味します。このように用語はさまざまですが、いずれにせよこれまでほとんどのア

プリケーションではこのような概念に基づく分離があれば十分でした。

しかし近年、 ARM アーキテクチャなどの汎用プロセッサを使用したアプリケーションにおいて特定のソフトウェア

ワークロードをシステム全体から分離することが必要となるケースが増えており、その処理をアプリケーションで

動作する汎用 OS に任せるのは信用の面で問題があることが指摘されています。事実、近の OS は非常に複雑化が

進んでおり、定期的にセキュリティパッチが発行されることも珍しくありません。しかし近のデザインでは、

ユーザー資格情報のセキュリティ保護や DRM で符号化されたメディアの復号化といったセキュアな機能を同じプロ

セッサ上で汎用 OS と共存させることがますます求められるようになっています。

ARM TrustZone テクノロジは、プロセッサ上で汎用 OS が動作する特権レベルよりもさらに下層にもう 1 つの新しい

特権レベルを定義することにより、こうした要求に応えることを目的としています。 TrustZone を導入すると、 ARM

プロセッサ上で動作する OS は高の特権レベルではなくなります。 OS よりも高い特権を持つソフトウェアレベル

が存在し、重要な処理は OS やアプリケーションのコンテキスト外でセキュアに実行されます。 TrustZone を使用し

た場合、これらの処理を含むセキュアコンテキスト全体が OS からは透過的に動作します。つまり、 TrustZone 対応

ARM プロセッサ上で動作する汎用 OS からは、あたかも TrustZone が存在せず自分自身がプロセッサを完全に制御し

ているかのように見えます。しかし実際には TrustZone が動作を継続し、必要に応じてサービスを提供します。

OS がプロセッサの特別な機能およびレジスタにアクセスし、コンフィギュレーションメモリの保護メカニズムによ

り自身を通常のアプリケーションから保護するのと同様、 TrustZone で定義される新しい特権レベルも ARM プロ

セッサの特別な機能にアクセスすることにより、分離されたセキュアなコンテキストを提供します。つまり、非セ

キュアワールド (すなわち通常の OS およびアプリケーション) から見たプロセッサのステート (レジスタ値を含む)

は、セキュアステートに移行する際に保存し、非セキュアステートに戻る際に復元する必要があります。また、非

セキュアステートを保存したらプロセッサは非セキュアな汎用 OS およびそのアプリケーションから完全に分離し

たセキュアスタックを実行できることになります。このセキュアスタックは後者からは見えません。





セキュアソフトウェアスタックと通信するため、 TrustZone 上で動作する汎用 OS には通常、割り込みを使用してセ

キュアコンテキストを呼び出すための 1 つまたは複数のドライバーがあります。アプリケーションは、通常のデバ

イスと通信するのと同じ方法でこれらのドライバーを使用します。 OS 自身は、ドライバーからの要求を受け取ると

通常どおりプロセッサに用意されている機能を使用して割り込みをトリガーします。ただし唯一の違いとして、こ

れらの割り込みは通常なら OS の割り込みサービスルーチンによって捕捉されますが、この場合は TrustZone セキュ

リティコンテキストによって捕捉されます。そしてセキュアコンテキストで動作するソフトウェアのプログラム内

容に従って、セキュアコンテキストによって割り込みが処理されます。

例外レベル

APU の ARMv8 A53 に実装される TrustZone は、ここまで説明した基本概念に基づき、 4 つの特権レベルを定義して

います。これらは、次の図に示すようにそれぞれが個別の例外レベル (EL) と呼ばれます。

図 7‐5: TrustZone の例外レベル


Non-secure State

App1


App2


App1


App2






Hypervisor Mode

AArch64 or AArch32

EL0

EL1

EL2

SVC

HVC

SMC

Secure Monitor Mode

Supervisor (Secure OS)

AArch64 or AArch32

Trusted App1


Trusted App2


EL3

Secure State

X15288-032917

まずこの図からわかるのは、 TrustZone では分離されたセキュアスタックが A53 上で動作するメインの非セキュア

スタックと並行して存在できるという点です。この例では、非セキュアサイドの EL2 で Xen をハイパーバイザーと

して動作させ、 Xen でホスティングする Linux ゲスト OS インスタンスを EL1 で動作させ、それぞれのゲスト OS イ

ンスタンスが EL0 でアプリケーションを実行しています。しかし EL3 に入ると上の図で「Secure Monitor Mode」と

示したソフトウェアが動作しており、分離してセキュアスタックで実行されます。分離されたセキュアスタックの

EL1 ではセキュア OS が動作し、 EL0 でセキュアアプリケーションが動作しています。

セキュアサイド内にあるこれらのソフトウェアレイヤーも、非セキュアサイドのソフトウェアレイヤーとまった

く同じ方法で互いに保護されます。つまり、非セキュアコンテキストで動作する通常の Linux アプリケーションが

互いに保護され、 EL1 でホスティングされる Linux カーネルリソースには直接アクセスできないのと同様、 EL0 で

動作するセキュアアプリケーションは互いに保護され、 EL1 の OS リソースには直接アクセスできません。





セキュリティプロファイルとトランザクションタグ

APU がセキュアステートと非セキュアステートに分割されるのに加え、 Zynq UltraScale+ MPSoC デバイスおよび

AXI インターコネクト上のコンフィギュレーションレジスタも APU の TrustZone と同様にセキュア、非セキュア、

両方、またはコンフィギュレーション依存 (セキュアまたは非セキュアのいずれか) に設定できます。インターコネ

クト上のすべての AXI メモリトランザクションはセキュアまたは非セキュアのいずれかにタグ付けされるため、こ

れは非常に重要な点です。このステートはトランザクションの発行元がセキュアか非セキュアかを反映しており、

AXI スレーブおよび前述のとおり XMPU と XPPU はこのステートを使用してステートの一致しないトランザクショ

ンをフィルタリングします。

いくつかの重要なシステムコンポーネントはセキュア AXI スレーブです。これには、プラットフォーム管理ユニッ

ト (PMU)、コンフィギュレーションセキュリティユニット (CSU)、およびシステムレベル制御レジスタ (SLCR) が

該当します。したがって、これらコンポーネントとの通信を開始できるのはセキュア AXI マスターのみです。同様

に、一部のシステムコンポーネントはセキュア AXI マスターです。これには PMU と CSU が該当します。したがっ

て、 PMU と CSU の間ではいつでもセキュア AXI トランザクションを開始できます。

また、セキュアコンテキストで動作する A53 によって開始された APU メモリトランザクションは AXI バス上では

すべてセキュアとしてタグ付けされます。重要なシステム動作の中には、 APU で動作するセキュアコードでしか実

行できないものがあるため、このことにも注意が必要です。したがって、 PMU または CSU とはセキュアコンテキ

スト上で動作する A53 からは通信できますが、非セキュアコンテキスト上で動作する A53 からは通信できません。

原則としてセキュアマスターは非セキュアスレーブにアクセスできますが、 XMPU および XPPU の設定によってセ

キュアマスターから非セキュアスレーブへのアクセスを禁止できます。

TrustZone プロファイルの詳細は、『Zynq UltraScale+ MPSoC テクニカルリファレンスマニュアル』 (UG1085) [参照 7]

の表 16-10 を参照してください。

ARM トラステッドファームウェア

ザイリンクス FSBL は APU を常にセキュアモードでブートします。また、上の図で示したセキュアモニターとして

ARM トラステッドファームウェアを EL3 で実行するようにも設定できます。第 3 章「システムソフトウェアの検

討事項」で概要を説明したように、 ARM トラステッドファームウェア (ATF) はブート時のトラストチェーンの一部

を構成します。

ATF の役割として特に重要なのが、セキュアコンテキストとの切り替え時に非セキュアコンテキストを保存および

復元することです。また、 ATF はパワーマネージメントにも一部関与します。これは、パワーマネージメントの機

能を担う PMU はセキュア AXI スレーブであり、ハイパーバイザーまたは APU 上で動作する非セキュア OS が発行

したコマンドを受け取ることができないためです。このため、 Linux などの非セキュア OS によるパワーマネージメ

ント要求は ATF をプロキシとして経由して PMU に渡されます。

ATF には A53 の内部プロセッサステートを維持すると同時に、 APU と主要なシステム機能間の仲介役としての働

き、および基本的なシステムセキュリティを確保する役割があるため、ほとんどのデザインで ATF を使用する必要

があると考えられます。特に、第 3 章「システムソフトウェアの検討事項」で説明したように Linux を動作させる

場合は ATF が必要です。

注記: 下層に ATF を使用しないで OS を実行する構成をザイリンクスは一切サポートしていません。





TEE (Trusted Execution Environment)

ATF は A53 を動作させる上で重要な役割を果たしますが、 ATF 自体にはセキュアモードの EL0 (上の図の右上部分)

で動作するカスタムセキュアアプリケーションのホスティングに必要な機能および API はありません。通常、この

役割を果たすのは「スーパーバイザー (セキュア OS)」と呼ばれるコンポーネントで、 ARM 社の資料では TEE

(Trusted Execution Environment) と呼ばれています。

TEE はザイリンクスが提供するシステムソフトウェアスタックには含まれませんが、重要なコンポーネントのため

ここで少し説明します。 TEE は ATF からは独立したソフトウェアコンポーネントで、 ATF に関しては ARM 社から

オープンソースのリファレンスインプリメンテーションが提供されていますが、 TEE の提供はサードパーティパー

トナーに任されています。このため市場にはいくつかの TEE があり、ユーザーは TEE が必要かどうか、そして必要

ならどの TEE を使用するのかを判断する必要があります。 Zynq UltraScale+ MPSoC デバイスをサポートしたオープ

ンソース TEE としては、少なくとも op-tee.org で提供されている Open Portable Trusted Execution Environment

(OP-TEE) が 1 つ存在します。

どの TEE もセキュアアプリケーションを作成するための API をそれぞれ独自に定義しており、非セキュア OS およ

びアプリケーションが必要な非セキュア/セキュアコンテキストスイッチを介して TEE と通信するための手段と API

もそれぞれ異なるものを提供しています。 TEE を選択する際は、プロジェクトに必要な API およびメカニズムが提

供されているかどうかを検討する必要があります。

機能のまとめ

ここまで、 TrustZone の基礎およびその中心的な機能と主なサポートソフトウェアについて説明してきました。これ

で、次に示す主要な機能の意義を容易に理解できるようになったはずです。

• PMU、 CSU、 SCLR などの重要なデバイスは常にセキュアであり、セキュリティシステム自体に対する不正ア

クセスおよび改ざんを防ぎます。

• デバイスをセキュアまたは非セキュアにプログラムできます。

• オンチップメモリや DDR (Double Data Rate) などのメモリは領域ごとにセキュアまたは非セキュアにプログラム

できます。

• APU は常にセキュアモードでブートします。

• RPU は TrustZone テクノロジをサポートしませんが、各 RPU から AXI バスへトランザクションをセキュアマス

ターとして、または非セキュアマスターとして送信するかを SCLR で設定できます。

詳細情報

TrustZone の詳細は、 ARM 社のテクニカルリファレンスマニュアルを参照してください。また、 Zynq UltraScale+

MPSoC デバイスにおける TrustZone の使用および設定の詳細は、『Zynq UltraScale+ MPSoC テクニカルリファレンス

マニュアル』 (UG1085) [参照 7] のこのセクションを参照してください。



http://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xSystemProtectionUnit



システムメモリ管理ユニット

システムメモリ管理ユニット (SMMU) は APU コアの MMU を補完するもので、任意のコンポーネント (すなわち

AXI マスター ) が APU 上で動作するソフトウェアのプログラムに従って生成したメモリアクセスが、 APU 上で使用

されるマッピングとの間でコヒーレンシ (一貫性) を維持できるようにします。 Zynq UltraScale+ MPSoC デバイス内で

は、確実に分離が行われるように SMMU を使用してすべての DMA アクセスが適切に変換されます。

これには、次のものからの DMA アクセスが該当します。

• LPD および FPD ペリフェラル

• ソフトウェアで設定可能な DMA チャネル (すなわち汎用 DMA)

• プログラマブルロジック (PL) 内の DMA 対応カスタム IP

したがって、 SMMU は正しくプログラムされていないデバイス、または悪意のあるデバイスによるシステムメモリ

の破損やシステム障害からシステムを保護するのに役立ちます。

SMMU の主要なコンポーネントは次のとおりです。

• 変換バッファーユニット (TBU): ページテーブルをキャッシュする変換ルックアサイドバッファー (TLB) が含

まれます。 SMMU は接続されたマスターごとに TBU を実装します。これにより、共通メモリにアクセスしよう

とする複数のデバイスを仮想環境で隔離できます。

• 変換制御ユニット (TCU): アドレス変換を制御および管理します。





次の図に、インターコネクトにおける SMMU コンポーネントの位置を示します。

図 7‐6: インターコネクトにおける SMMU コンポーネントの位置


ネイティブ環境におけるアドレス変換

仮想化していないネイティブなシステムでは、 SMMU を使用してペリフェラルに対するアドレス変換を実行できま

す。この変換により、 DMA 対応ペリフェラルは事前に割り当てた物理空間のみに制限されるため、結果的にデバイ

スが分離され DMA 攻撃を防ぐことができます。このようにしてメモリを分離しないと、ペリフェラルによってシス

テムメモリが破壊される可能性があります。次の図に示すように、ネイティブ環境で SMMU を使用すると、任意の

デバイス (すなわちペリフェラル) の DMA マスターがどのメモリにアクセスするかを APU 上でネイティブに動作す

る OS で制御できます。

図 7‐7: 仮想化していないネイティブ環境における SMMU の使用






なお、ネイティブ環境では SMMU の使用は必須ではありません。ただし、 SMMU を使用するとシステムのセキュリ

ティは確実に向上します。

仮想化環境におけるグローバルな分離

仮想化したシステムで SMMU を使用すると、複数のゲスト OS によって要求された DMA アクセスを互いに分離で

きる利点があります。これにより、あるドメインで誤動作、障害、またはハッキングが発生してもほかのドメイン

への影響を防ぐことができ、仮想化環境におけるシステムの完全性が維持されます。この目的のため、 SMMU は適

切な変換方式とコンテキストを設定するための機能を提供します (I/O 仮想化)。

仮想化環境では、 SMMU は 2 段階の変換プロセスを必要とするアドレス変換方式をサポートします。仮想化環境で

はハイパーバイザーが複数のゲスト OS を管理し、 OS 上で動作する複数のアプリケーションが同じシステムリソー

スにアクセスを試みる可能性があります。次の図に示すように、この変換はゲスト OS から独立して実行されます。

図 7‐8: 仮想化環境における SMMU の使用


その他の情報

SMMU の詳細は、第 2 章「プロセッシングシステム」および『Zynq UltraScale+ MPSoC テクニカルリファレンスマ

ニュアル』 (UG1085) [参照 7] のこのセクションとこのセクションを参照してください。



http://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xInterrupts

http://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xTimers



ザイリンクスメモリ保護ユニット

前述のとおり、 XMPU はメモリを分割してシステム間の脅威から保護します。具体的には、特定のマスターから

FPD ペリフェラルおよびメモリの領域へのアクセスを制限することにより、主に FPD ペリフェラルとメモリを保護

します。 Zynq UltraScale+ MPSoC デバイス全体には、次の図の赤で示した 6 つの XMPU があります。

図 7‐9: Zynq UltraScale+ MPSoC デバイスの XMPU の位置


各 XMPU には次の機能があります。

• フィルタリングの対象となる 16 の設定可能な領域

• アクセス要求を受け取るためのスレーブ AXI ポート

• ポイズン出力を備えたマスター AXI ポート

• XMPU をプログラムするための APB スレーブ

• レベルセンスの非同期割り込み出力

• AXI クロック (マスターポートとスレーブポートで共通) および APB (Advanced Peripheral Bus) クロック

要するに、各 XMPU はそれぞれの構成に基づいてアクセスを許可するかどうかを判定します。アクセスが許可され

ない場合、後述する「ポイズン」の使用を含むいくつかの手段が実行されます。





XMPU の領域

各 XMPU には領域 0 から 15 まで合計 16 の領域があります。各領域は開始アドレスと終了アドレスで定義します。

各領域は個別に有効または無効にできます。無効にした領域は、保護チェックには使用しません。領域のアドレス

は 1 MB 境界と 4 KB 境界のいずれかのアライメントが可能です。領域は重複可能です。その場合、領域番号が大き

いものが優先されます (つまり領域 0 の優先度がも低い)。

すべての領域を無効にした場合、または要求がどの領域にも一致しない場合、 XMPU は XMPU 制御レジスタで指定

したデフォルトの動作に従って要求を許可またはポイズンします。

保護チェックの動作

XMPU によって保護されている AXI スレーブに対して AXI マスターからの読み出しまたは書き込み要求を受信する

たびに、その要求に対するチェックが XMPU の有効な各領域ごとに行われます。次に示す 2 つの基本チェックが実

行されます。

• トランザクションのアドレスが領域内にあるかどうか

• 受信したトランザクションのマスター ID が許可されているかどうか

これらの判定がどちらも真の場合、その領域のセキュアステートおよび読み出し /書き込みパーミッションの設定を

チェックします。

• セキュアマスターが必要と設定されている領域にアクセスできるのはセキュアな要求のみです。このチェック

を通過した場合、読み出しパーミッションと書き込みパーミッションを個別にチェックし、トランザクション

が許可されるかどうかを判定します。セキュアマスターの詳細は、 125 ページの「ARM TrustZone」を参照して

ください。

• 領域がセキュアとして設定されており、トランザクションが非セキュアの場合、チェックでエラーになります。

• 領域が非セキュアとして設定されており、トランザクションが非セキュアの場合、次に読み出しパーミッショ

ンと書き込みパーミッションを個別にチェックし、トランザクションが許可されるかどうかを判定します。

XMPU のエラー処理

前述のとおり、読み出しであれ書き込みであれ XMPU を経由する AXI トランザクションがエラーになるのは、パー

ミッション違反とセキュリティ違反のいずれかが理由です。これらのエラーが発生すると、 XMPU は要求を無効化 (ポイズン) し、チェックがエラーになった初のトランザクションのアドレスとマスター ID を記録して違反フラグ

をセットします。また、オプションで割り込みも生成できます。セキュリティ違反の場合は、そのエラーがセキュ

リティ違反であることを示すログも記録されます。

要求に対するポイズン処理の方法には次の 2 つがあります。

1. 要求のポイズン属性をセットすると、読み出しにはすべて 0 のデータを返し、書き込みは無視するように AXI ス

レーブに通知できます。ポイズン属性をサポートしているのは DDR メモリコントローラーと OCM のみです。

2. 受信した読み出し要求を、事前にプログラムしたポイズンアドレスに XMPU が変更します。ポイズンアドレス

にある内容は基本的に「ハニーポット」と呼ばれるもので、要求元のマスターに送信する偽データです。この

ポイズン処理は、無効な要求の宛先であるスレーブ側に特別なサポートは必要ありません。





コンフィギュレーション

各 XMPU には、専用のコンフィギュレーションレジスタセットがあります。 XMPU のレジスタで特に重要なのが

LOCK レジスタです。これは読み出し /書き込み、デフォルト、読み出し専用のいずれかに設定できます。このレジ

スタをいったん設定すると、システム全体をリセットするまで XMPU の設定は変更できません。したがって、個々

のデザインの必要に応じて XMPU を構成したら、その設定は固定されます。

XMPU のコンフィギュレーション方法には次の 2 つがあります。

1. Vivado® Design Suite の Processor Configuration Wizard (PCW) を使用して第 1 段階ブートローダー (FSBL) を生成する。

2. 実行時に、セキュア AXI マスターを使用する。

いずれの場合も、 LOCK レジスタが設定済みの場合、次のリブートまで設定は変わりません。

常に正しい設定でシステムのセキュリティを確保するには PCW を使用し、ロックモードのブート時に FSBL 経由で

XMPU を構成することを推奨します。 2. の方法で実行時に構成する場合、 XMPU の設定を誤るとリソースを利用で

きなくなるため注意が必要です。

各領域が各 XMPU の構成に使用する領域と権限は、デザインによって異なります。 118 ページの「リソース分離/分

割の要件を定義する」で説明したように、 Zynq UltraScale+ MPSoC デバイスの機能を使用してデザインをどのように

分割するかは、個々のデザインの機能と要件によります。

XMPU の詳細は、『Zynq UltraScale+ MPSoC テクニカルリファレンスマニュアル』 (UG1085) [参照 7] のこのセクショ

ンを参照してください。

ザイリンクスペリフェラル保護ユニット

ザイリンクスペリフェラル保護ユニット (XPPU) は LPD ペリフェラルを分離し、プロセッサ間割り込み (IPI) を保護

します。 XMPU 同様、 XPPU もシステム間の脅威を防ぎます。 XMPU に比べ XPPU の方がアドレス一致の精度が細

かく、アドレスアパーチャの数も多く、ペリフェラル、 IPI、および Quad-SPI フラッシュメモリの要求に応えます。

また、 XMPU とは異なり XPPU はシステム全体で 1 つしかありません。

XPPU の概要

XPPU には次の機能があります。

• 特定のアドレスアパーチャに対してマスター単位でのアクセス制御

• ペリフェラル単位またはメッセージバッファー単位でのアクセス制御

• 同時に大 20 個のマスターをサポート

• 大 128 x 32B アパーチャ、 256 x 64 KB アパーチャ、 16 x 1 MB アパーチャ、および 1 x 512 MB アパーチャをサ

ポート

• 64 KB および 1 MB のペリフェラルアパーチャ、および 32B のメッセージアパーチャをサポート

• リニア Quad-SPI フラッシュメモリのパーミッションチェック用に 512 MB アパーチャを 1 つサポート

• 禁止されたトランザクションに対するエラー処理 (オプションで割り込み生成も可能)

XMPU 同様、 XPPU も AXI マスターと AXI スレーブの間に位置し、 AXI 読み出しおよび AXI 書き込みトランザク

ションに対してメモリアクセス制御を実行します。



http://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xXilinxMemoryProtectionUnit

http://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xXilinxMemoryProtectionUnit



XPPU は次の図の青で示した場所にあります。

図 7‐10: Zynq UltraScale+ MPSoC デバイスの XPPU の位置


XPPU は次に示す 2 つのデータ構造でアクセスを制御します。

• マスター ID リスト :

このリストの一部はユーザーがプログラムできます。このリストで、ペリフェラルへのアクセスが許可される

マスターを指定します。基本的に、このリストは潜在的なマスターのプールを定義したものです。初の 9 個

のマスターは定義が決まっています。残りの 11 個はプログラマブルで、 XPPU を有効にする前に設定しておく

必要があります。

• アパーチャパーミッションリスト :

アクセス可能なアドレスアパーチャセットを定義し、各アパーチャにアクセス可能なマスターを指定します。

前述のとおり、 XPPU は大 128 x 32B アパーチャ、 256 x 64 KB アパーチャ、 16 x 1 MB アパーチャ、および 1 x 512 MB アパーチャ (スレーブ) をサポートします。ソフトウェアでセットアップしたパーミッション設定は、

RAM に格納します。この RAM はシステムアドレスマップにあり、通常のソフトウェアプログラマブルレジ

スタと同じようにアクセスできます。





XPPU の動作

XPPU は細かなアクセス制御が可能な 1x1 AXI スイッチと見なすことができます。すべての読み出しおよび書き込み

トランザクションについて、 XPPU はそのトランザクションが許可されるかどうかを判定します。許可されたトラン

ザクションは、通常の処理を実行します。許可されないトランザクションは、 XMPU の場合と同様に無効化 (ポイズ

ン) されます。

AXI マスターが XPPU を経由して AXI スレーブにアクセスするには、次の 2 つの条件を満たす必要があります。

• AXI マスターの ID がマスター ID リストに存在する (ここでは m 番目のエントリとする )

• アパーチャパーミッションリストの該当する AXI スレーブのエントリで、 PERMISSION フィールドの対応す

るビットがセットされている (すなわち PERM[m] == 1)

これらは必要条件です。これ以外にも、後述するいくつかのチェック項目があります。

次に、 XPPU の動作をブロック図にまとめます。

図 7‐11: XPPU の動作


APBInterface

AXIARADDR

ARID ARADDR

AXIAWADDR

AWID

AWADDR

APB

RegisterFile

Permission RAM

Address Decode

ADDR

IDPermission

CheckMatch

Data

Aperture Info

poison

poison

ID Lookup

X15344-091616

AXI 読み出しトランザクションはこの図の上部で受信し、 AXI 書き込みトランザクションは下部で受信します。

これらのトランザクションにはマスター ID、パーミッションなどが埋め込まれており、 XPPU はこれらを使用して

読み出し /書き込み要求が有効で許可されるかどうかを判定します。 APB (Advanced Peripheral Bus) インターフェイス

は、 XPPU を有効にする前に XPPU をプログラムするのに使用します。パーミッション RAM にはパーミッション条

件を格納します。

XPPU はルックアップベースのペリフェラル保護ユニットのため、どのマスターがどのペリフェラルに対して読み

出しまたは書き込みを試みているのかをテーブル (すなわちマスター ID とアパーチャパーミッション) を使用して正

確に判定します。テーブルおよびその使用方法の詳細は、『Zynq UltraScale+ MPSoC テクニカルリファレンスマニュ

アル』 (UG1085) [参照 7] を参照してください。





XPPU のパーミッションチェック

パーミッションチェックは、読み出し /書き込みトランザクションが許可されるかどうかを判定します。基本的に、

このチェックは一致したマスター ID ルックアップとアパーチャパーミッションリストからのエントリを取得して

実行します。受信した AXI マスター ID (マスク適用済みのもの) がマスター ID リストに含まれており、なおかつア

パーチャパーミッションリストに許可されたマスターとして登録されている必要があります。また、受信したセ

キュアステートがアパーチャのセキュアステート設定に一致している必要もあります。パリティチェックを有効に

している場合は、アパーチャパーミッションリストの選択したエントリに対してパリティチェックも実施します。

これらのチェックにすべて合格すると、そのトランザクションは許可されます。それ以外の場合、次のいずれかの

エラーが発生しています。

• マスター ID リストパリティエラー

• マスター ID リスト読み出し専用エラー

• マスター ID リスト不在エラー

• アパーチャパーミッションリストパリティエラー

• トランザクション TrustZone エラー

• トランザクションパーミッションエラー

XPPU のパーミッションチェックおよびエラー処理の詳細は、『Zynq UltraScale+ MPSoC テクニカルリファレンスマ

ニュアル』 (UG1085) [参照 7] を参照してください。

トランザクションへのポイズン処理

前出の XPPU の機能ブロック図にも示したように、読み出しまたは書き込み AXI トランザクションがチェックに合

格しない場合、そのトランザクションはポイズン処理されます。ポイズン処理された読み出しはすべて 0 の値を返

し、ポイズン処理された書き込みは無視されます。システムには、ポイズン処理されたトランザクションを受け取

るとエラー応答を返すシンクモジュールがあります。このモジュールには、オプションでトランザクションアドレ

スの下位 12 ビットを記録する機能もあります。これにより、データアボートまたはプロセッサへの割り込みが発生

します。

XPPU の保護

XPPU 自体は 2 つの方法で保護されます。

• マスター ID リストとアパーチャパーミッションリストには、セキュアマスターしか書き込みできません。

• マスター ID リストとアパーチャパーミッションリストは、 XPPU 自体のコンフィギュレーション機能を使用し

てさらなる書き込みを防ぐことができます。これは、マスター ID リストとアパーチャパーミッションリスト

で該当するエントリを設定して XPPU へのさらなる書き込みを防ぐのと同じ方法による保護です。





コンフィギュレーション

XMPU の場合と同様、 XPPU の構成方法も 2 とおりあります。

1. Vivado Design Suite の Processor Configuration Wizard (PCW) を使用して第 1 段階ブートローダー (FSBL) を生成する。

2. 実行時に、セキュア AXI マスターを使用する。

XMPU の場合と同様、常に正しい設定でシステムのセキュリティを確保するには、 PCW を使用してブート時に

FSBL で XPPU を構成してさらなる書き込みから保護することを推奨します。 2. の方法で実行時に構成する場合、

XPPU の設定を誤るとリソースを利用できなくなるため注意が必要です。

XMPU の場合と同様に、各領域が各 XPPU の構成に使用する領域と権限は、デザインによって異なります。

XPPU の詳細は、『Zynq UltraScale+ MPSoC テクニカルリファレンスマニュアル』 (UG1085) [参照 7] のこのセクショ

ンを参照してください。

Xen ハイパーバイザー

Xen ハイパーバイザーの概要および Zynq UltraScale+ MPSoC デバイスでの使用法については、第 3 章「システムソ

フトウェアの検討事項」で説明しました。ここでは、この章の主題であるリソース分離/分割の観点からハイパーバ

イザーの中でも特に Xen について少し説明します。

前述のとおり、 Xen のようなハイパーバイザーを使用すると、複数の異なるゲスト OS 間、またはいくつかのゲスト

OS とベアメタルアプリケーションの間で仮想化した A53 CPU を分割できます。 TrustZone のセクションで説明した

ように、 Xen は非セキュアコンテキストで動作し、 Xen の下層では ATF が動作しています。このため、 Xen および

Xen がホスティングするゲストから開始されたメモリアクセスはすべて非セキュア AXI トランザクションとして

AXI インターコネクトに発行されます。したがって、 XMPU と XPPU を構成する際には APU のソフトウェアアーキ

テクチャの一部として Xen に適用するソフトウェア分割を考慮する必要があります。



http://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xXilinxPeripheralProtectionUnit

http://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xXilinxPeripheralProtectionUnit


第 8 章

セキュリティ近ではあらゆるエンベデッドデザインでセキュリティの重要性が高まっています。 Zynq® UltraScale+™ デバイス

には、現在のも高度なセキュリティ脅威および課題に対処するための機能が包括的に用意されています。この章

では、 Zynq UltraScale+ デバイスのこれら機能の根底にあるセキュリティ理念と、これらの機能を使用して実際のデ

ザインのセキュリティ要件を満たす方法について説明します。

セキュリティ要件を定義する

セキュリティは非常に幅の広い分野であり、設計者やエンジニアはその重要性を理解してはいるものの、プロジェ

クトで計画しているデザインのセキュリティを十分に分析しようとするとセキュリティに関して相当な知識量が求

められます。事実、技術的な脆弱性だけに対処していればよいケースは少なく、企業としての信用や財務への影響、

ミッションクリティカルな安全性、そして場合によっては国家安全保障といった問題までも分析が必要となること

があります。

したがって、ここでいくつかの簡単な質問に答えていただいて個々のデザインのセキュリティ評価の指針とするの

は適切ではありません。チームのセキュリティ専門家の協力を得てデザインが直面する脅威モデルの理解を深める

ことを強く推奨します。そこでは次の事項について考慮してください。

• 保護しようとしている IP にはどれだけの価値がありますか。

• システムをどのような環境にデプロイしますか (無人環境、入退室の容易な環境、ゲートや守衛/武装警備員に

守られた環境など)。

• どのような攻撃者が想定されますか。それはどの程度の攻撃能力を持っていますか。




第 8 章: セキュリティ

セキュリティに関する設計手法

前述のとおり、セキュリティは多岐の分野にわたります。 Zynq UltraScale+ デバイスを使用したシステムデザインに

関して言えば、図 8-1 に示す 3 つの観点からデザインを検討することを推奨します。

図 8‐1: セキュリティの基本的な分野


• 耐タンパー (AT: Anti-Tamper): AT は「物理セキュリティ」とも呼ばれます。 AT はカスタム IP をリバースエンジ

ニアリング、クローニング、盗難、改変など、システムの設計目標に沿わない形での使用から保護します。カ

スタム IP に高い価値がある場合、セキュリティストラテジの中でも AT を特に重視する必要があります。

• 情報保証 (IA: Information Assurance): 処理対象の情報およびデータを業界標準の暗号化およびフォルトトレラン

ト設計手法によって保護します。

• トラスト (サプライチェーンセキュリティ ): シリコン、ソフトウェア、ファームウェア、および IP に「トロイ

の木馬」が存在しないことを保証します。

図 8-1 からもわかるように、これら 3 つの分野には重なり合う部分があります。このため、セキュリティは全体的な

視点に立って解析する必要があります。セキュリティはこのように複数の分野で構成されているだけでなく、階層

構造としても捉えることができます。初は特定の特定の側面にのみ関心が向くかもしれませんが、図 8-2 に示す

ようにセキュリティは各階層が積み重なって構成されています。





図 8‐2: セキュリティのピラミッド


この図からもわかるように、ベストプラクティスを使用しているかどうか、信頼できるサプライヤーを利用してい

るかどうかといったサプライチェーンの信頼が、セキュリティアーキテクチャ全体の土台となります。この土台に

より、デバイスが意図した以外の動作をすることがなくなります。この階層はザイリンクスが担当する領域です。

ピラミッドの階層を 1 つ上がると、物理タンパー攻撃 (温度や電圧などの変動や監視を利用した攻撃、あるいは

JTAG などデバイスの正当な機能を悪用した攻撃) などの攻撃からシリコン自体を保護するセキュリティ機能があり

ます。この階層もザイリンクスが担当する領域です。

さらにピラミッドの階層を上がると、機密性、認証、完全性といった情報保証 (IA) の分野の原則を適用してブート

およびコンフィギュレーションプロセスを保護する機能があります。このためのツールはザイリンクスから提供さ

れますが、設計者がこれらを正しく使用する必要があります。

さらに階層を上がると、ハイパーバイザーによる保護、 TrustZone、モニターなどスタックの上位に位置するソフト

ウェアレベルがあります。ここでも、ザイリンクスが提供する機能を正しく使用する必要があります。

後に、ピラミッドの頂上にあるアプリケーションは署名およびユーザーが設定したパスワードによって保護され

ます。この階層は、主にシステム設計者が担当する領域です。

実質的に、セキュリティにはサプライチェーンから始まってデバイスがフィールドで動作するまでのライフサイク

ルがあります。

先端のセキュリティ対策を周知することを目的とした団体やフォーラムがいくつも存在します。ザイリンクスは

毎年、北米とヨーロッパで Xilinx Security Working Group (XSWG) と呼ばれるイベントを開催しています。ここには航

空宇宙、防衛、およびコマーシャル分野のザイリンクス顧客企業、大学関係者、ザイリンクスアライアンスメン

バー、政府機関代表者が集まってセキュリティに関する先端のトピックについて議論を交わしています。これら

のトピックには、サプライチェーンの保護、デバイスセキュリティ、セキュアブート、およびランタイムセキュ

リティなどがあります。



https://japan.xilinx.com/about/security-working-group-2016.html



なお、この章のタイトルは明示的に「セキュリティ」と名付けていますが、セキュリティに関連するトピックはそ

の他の章でも取り上げています。

• 第 2 章「プロセッシングシステム」 : Zynq UltraScale+ デバイスでほとんどのコンポーネント間通信に使用され

るインターコネクトについて説明しています。

• 第 7 章「リソースの分離と分割」 : TrustZone、ザイリンクスメモリ保護ユニット (XMPU)、ザイリンクスペリフェ

ラル保護ユニット (XPPU) などの各種ランタイムセキュリティに関するメカニズムについて説明しています。

• 第 5 章「プログラマブルロジック」 : プログラマブルロジック (PL) の IP 機能を分離することを目的としたフォ

ルトトレラント設計手法であるアイソレーションデザインフロー (IDF) について説明しています。

セキュリティ機能の概要

セキュリティとは終わりのない「軍拡競争」のようなもので、ザイリンクスは新しいセキュリティ機能の追加およ

び既存セキュリティ機能の強化を続け、常に脅威の一歩先を行くよう全力を尽くしています。図 8-3 はザイリンク

ス製品に内蔵されているセキュリティ機能をまとめたもので、右端の 2 列が UltraScale+ の機能です。

図 8‐3: ザイリンクスのセキュリティ機能






セキュリティ機能は受動機能と能動機能の 2 つに大別されます。受動セキュリティ機能はデバイスに内蔵されてお

り、設計者はデザインで特に何もしなくても利用できます。たとえばセキュアコンフィギュレーション/ブートおよ

び認証がこのグループに該当します。能動セキュリティ機能は Zynq UltraScale+ デバイスの一部の機能を設計者が設

計時または実行時に有効にする必要があります。たとえば、特定の動作電圧/温度範囲を監視するようにデバイスを

構成するといったものが能動セキュリティ機能に該当します。

どの機能を実装するかを決めるには、 Zynq UltraScale+ デバイスの機能を理解し、それらがどのような種類の攻撃に

対するものかを知っておく必要があります。セキュリティの詳細は、『Zynq UltraScale+ MPSoC テクニカルリファレ

ンスマニュアル』 (UG1085) [参照 7] のこのセクションを参照してください。

コンフィギュレーションのセキュリティとセキュアブート

メーカーから顧客までのトラストチェーンをセキュリティ保護する上でシステム設計者がまず初に理解する必要

があるのは、 SoC のブートプロセスのセキュリティを確保する方法です。実際、スタートアップ時に読み込まれる

一連のソフトウェアがブート時にデバイスで検出される正当なキーによって正しく署名されていることを確認する

ことがオンチップロジックおよびファームウェアの重要な役割です。こうして、いわゆるハードウェアの信頼の起

点 (Root of Trust) を保証します。署名なしのイメージをブートすることも可能ですが、そのような方法がシステムデ

ザインにとって善の方法であると判断されるなら、そのデザインではそもそもセキュリティは大きな問題でない

といえます。開発の初期段階では、たとえば JTAG 経由で署名なしのイメージを読み込んで動作させることも慣例的

に行われています。

Zynq UltraScale+ デバイスでは、プラットフォーム管理ユニット (PMU) とコンフィギュレーションセキュリティユ

ニット (CSU) によってセキュアブートを容易に実現できます。 CSU はブートプロセスの一部ですが、後述するよう

にそれ以外にも Zynq UltraScale+ デバイスの多くのセキュリティ機能において重要な役割を果たします。 CSU は、非

対称認証に RSA を使用し、機密性 (暗号化/復号化) に AES-GCM を使用することによってハードウェアの信頼の起点

を保証します。次に、 Zynq UltraScale+ MPSoC デバイスの全体的なシステムブロック図における CSU の位置を示し

ます。



http://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xDeviceSecureBoot



図 8‐4: コンフィギュレーションセキュリティユニット






図 8-5 に、ブート時における PMU と CSU の役割を示します。

図 8‐5: ブートフローの概略図


Test I/F Lockdown

Zeroize PMU Registers

Run LBIST*

SHA3/384 IntegrityCheck of PMU ROM

Release Reset to PMU

Zeroize RegistersLPD/FPD*

Zeroize PMU RAM

Voltage Checks(LPD, AUX, I/O)

Zeroize memories on CSU, LPD and FPD

SHA3/384 Integrity Check of CSU ROM

Release Reset to CSU

Enforces HW Root of Trust when enabled

Enforces Security “State”

Validate Integrity of User Public Key

Public Key Revocation

FSBL and PMU FW*Authentication/Decryption*

Zeroize storage elements after processing(including fallback)

Release Reset to RPU/APU

HW PMU CSU

CSU Tamper MonitoringLoad FSBL andPMU FW1

PMU ReleaseCSU

HW ReleasePMU

PowerValid

NOTE:1. Authentication with optional decryption.

Power Monitoring

X18922-032917

ブートフローは次の 3 つの段階で構成されます。

• プリコンフィギュレーション: システムのブート (POR: パワーオンリセット ) が必要と判断した場合、 PMU が

PMU ROM セットアップを実行します。リセットおよびウェークアッププロセスはすべて PMU が処理します。

• コンフィギュレーション: CSU が処理を引き継ぎ、 FSBL をオンチップメモリ (OCM) にロードします。コン

フィギュレーション中、 FSBL イメージが認証され (ハードウェアの信頼の起点が有効な場合)、復号化された

後、 OCM にロードされ、アプリケーションプロセッシングユニット (APU) またはリアルタイムプロセッシン

グユニット (RPU) が使用します。

• ポストコンフィギュレーション: FSBL が実行を開始すると、 CSU はタンパー監視ステートに移行します。

「システムソフトウェアの検討事項」の章で説明したように、 Zynq UltraScale+ デバイスは外部デバイスとして

Quad-SPI、 NAND、 SD、および eMMC からのブートをサポートしています。これらのストレージデバイスを使用し

た場合、 CSU によってハードウェアの信頼の起点が保証されます。 SATA、イーサネットおよび PCIe からはセカン

ダリブートを利用できます。小限の FSBL を使用することも可能ですが、これらのデバイスからのセキュアブー

トはシステム設計者側で正しく実装する必要があります。

ブート ROM は実行を開始すると、ロードすべき有効なイメージの検出を開始します。有効なイメージかどうかは、

イメージ識別文字列で判定します。この方法により、 Zynq UltraScale+ デバイスの各種プロセッシングデバイスで使

用する複数のブートイメージを外部デバイスに格納しておくことができます。また、この方法ではフォールバック

およびマルチブートイメージ検索を使用することもできます。





チェックおよびブート対象のブートイメージは、外部ブートデバイスから CSU ブロックと三重冗長 MicroBlaze™

プロセッサ、各種セキュリティブロック、 CSU DMA、セキュアストリームスイッチ (SSS)、およびプロセッサコ

ンフィギュレーションアクセスポート (PCAP) を経由して Zynq UltraScale+ デバイスへロードされます。図 8-6 に、

CSU ブロックおよびセキュアブートに使用する各種ブロックを示します。

図 8‐6: コンフィギュレーションセキュリティユニット (CSU) のブロック図


CSU PMU Switch

ROMValidation

ROM(128 KB)

RAM(32 KB)

TripleRedundantMicroBlaze

SHA-3384

AES-GCM256

Secure Stream Switch

PCAP

CSU DMA

CSURegisters

KeyManagement

To PL Configuration

PMU ROMValidation

To/From LPD Main Switch

TamperSources INTC

ECC

BBRAMeFUSEPUFOperationKUP Family

CSU Local

Registers

PUF RSA Multiplier

PSTP

Security Processor Block Crypto Interface Block

X15318-032917

左側には三重冗長 MicroBlaze プロセッサと CSU RAM および ROM があります。また、デバイス固有の暗号キーの生

成に使用する PUF (Physically Unclonable Function) ブロックもあります。右側には暗号/復号キー、各種復号プロセス

(AES-GCM および RSA) を管理するブロックがあり、全体を CIB (Crypto-Interface Block) と呼びます。また、 SSS の動

作経路には CSU DMA プロセスブロックがあります。

CSU の役割で特に重要なのがキー管理です。 CSU は次の表に示すいくつかのキーのうち 1 つを使用して AES-GCM

の機能を実行します。





表 8‐1: キーの種類

キーの名称説明

BBRAM バッテリバックアップ式 RAM (BBRAM) キーは 256 ビット SRAM アレイに平文で

格納されます。バッテリ消費を抑えるため、 VCCAUX に電源が供給されている場

合、 SRAM アレイは VCCAUX 電源で動作します。それ以外の場合、 SRAM アレイ

は VCCBAT 電源で動作します。

ブートブートキーレジスタには、使用中のキーを復号化したものが格納されます。

eFUSE eFUSE キーは eFUSE に格納されます。平文、難読化 (ファミリキーでの暗号化)、

または PUF KEK での暗号化のいずれかの形式で格納されます。

ファミリファミリキーは、デバイスにハードコードされた定数値の AES キーです。同じ

キーを Zynq UltraScale+ MPSoC ファミリのすべてのデバイスで使用します。この

キーは、難読化したキーを CSU ROM が復号化する場合のみ使用します。難読化し

たキーを復号化したものは、ブートイメージの復号化に使用します。難読化した

キーは、 eFUSE または認証済みのブートヘッダーに格納できます。ファミリキー

はデバイス全体で共通のため、セキュリティメカニズムの相対的な強度を表すた

めに「暗号化」ではなく「難読化」の用語を使用しています。

オペレーションオペレーションキーは、デバイスのほかのキーソースから取得した平文のキーを

使用してセキュアヘッダーを復号化して得ます。セキュアブートの場合、この

キーはオプションです。オペレーションキーはブートヘッダーで指定されます。

このキーを使用するとデバイスキーの使用を小限に抑え、外部への露出を減ら

すことができます。

PUF KEK PUF KEK はキーを暗号化するためのキーで、 PUF によって生成されます。

キー更新レジスタユーザーが支給するキーソースです。ブート後は、ユーザーが選択したキーを

ハード化した AES アクセラレータで使用できます。

Zynq UltraScale+ デバイスの BBRAM と eFUSE にプログラムしたキーは、いかなる方法でも取り出すことができませ

ん。キーが正しくプログラムされたかどうかは、 CRC でしかチェックできません。

CSU の動作が完了して FSBL の動作が開始すると、 CSU はタンパー応答のためにシステムの監視を開始します。

タンパーが検出されると、セキュアロックダウンを含むさまざまなユーザー定義の応答を実行できます。

ブート時に設計者が選択およびコンフィギュレーションできるソフトウェアコンポーネントの詳細は、「システム

ソフトウェアの検討事項」の章で説明しています。ここでの「ブート時」とは、 FSBL のブート以降のプロセスを指

します。

なお、 PL 用のビットストリームは、 FSBL で CSU DMA を使用して CSU の PCAP から読み込む必要があります。

Vivado® Design Suite を使用すると、このプロセスは自動化されます。

詳細は、次の資料を参照してください。

• CSU の詳細は、『Zynq UltraScale+ MPSoC テクニカルリファレンスマニュアル』 (UG1085) [参照 7] のこのセク

ションを参照してください。

• CSU の PCAP を経由した PL ビットストリームのプログラミングの詳細は、『Zynq UltraScale+ MPSoC テクニカ

ルリファレンスマニュアル』 (UG1085) [参照 7] のこのセクションを参照してください。

• ブート時のセキュリティについては、『Zynq UltraScale+ MPSoC ソフトウェア開発者向けガイド』 (UG1137) [参

照 5] のこのセクションでも説明しています。





http://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xBootAndConfiguration

http://japan.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug1137-zynq-ultrascale-mpsoc-swdev.pdf;a=xSecurityFeatures



デバイスとデータのセキュリティ

CSU とセキュアブートはデバイスのセキュアな起動を保証するためのものですが、 Zynq UltraScale+ MPSoC デバイ

スにはデバイス実行時のセキュリティを確保するための機能もあります。

タンパーの監視と応答

140 ページの「セキュリティに関する設計手法」で説明したように、耐タンパー (AT) とはリバースエンジニアリン

グやクローニングなど不正な方法による操作から IP を保護することをいいます。また、前のセクションで説明した

ように、 FSBL が実行を開始した後の CSU の主な役割は、監視モードで動作してタンパーイベントを検出すること

にあります。タンパーイベントは、たとえば Zynq UltraScale+ デバイスの電圧と温度を監視することによって検出で

きます。

タンパーに対する応答は、次の表に示す CSU タンパーレジスタを設定して制御できます。

表 8‐2: タンパーおよび監視レジスタ

レジスタ監視内容の説明

csu_tamper_12 GT の AMS 電圧アラーム

csu_tamper_11 PSIO バンク 3 の AMS 電圧アラーム

csu_tamper_10 PSIO バンク 0/1/2 の AMS 電圧アラーム

csu_tamper_9 DDRPHY の AMS 電圧アラーム

csu_tamper_8 VCCPAUX の AMS 電圧アラーム

csu_tamper_7 VCCPINT_FPD の AMS 電圧アラーム

csu_tamper_6 VCCPINT_LPD の AMS 電圧アラーム

csu_tamper_5 APU の AMS 過温度/低温度アラーム

csu_tamper_4 LPD の AMS 過温度/低温度アラーム

csu_tamper_3 PL SEU エラー

csu_tamper_2 JTAG トグル検出

csu_tamper_1 外部 MIO

csu_tamper_0 CSU レジスタ

次の表に、これらタンパーイベントに対して可能な応答を示します。

表 8‐3: タンパー監視および応答ビット

ビット応答

4 下記のいずれかの応答に加え、 BBRAM キーを消去

3 セキュアロックダウンおよびすべての I/O をトライステート

2 セキュアロックダウン

1 システムリセット

0 システム割り込み





場合によっては、タンパーイベント検出時にこれよりも厳格で永続的なペナルティを課す必要があることがありま

す。そのような場合の例については、『Zynq UltraScale+ MPSoC テクニカルリファレンスマニュアル』 (UG1085) [参

照 7] のこのセクションを参照してください。

また、 Zynq UltraScale+ デバイスには一意の ID の作成、またはメンテナンス /タンパーイベントに関するデータを事

後解析用として記録するためのユーザー定義可能な eFUSE ビットも多数備えています (図 8-7)。

図 8‐7: タンパーおよびメンテナンスの記録


eFUSE を使用してデータロギングに必要な一意の ID を取得する方法の詳細は、『Zynq UltraScale+ MPSoC テクニカ

ルリファレンスマニュアル』 (UG1085) [参照 7] のこのセクションを参照してください。

システムモニター

CSU の機能に加え、 Zynq UltraScale+ デバイスには PS と PL の両方にシステムモニター (SYSMON) ブロックがあり

ます。 SYSMON はカスタム環境や高度な環境の監視に使用します。 SYSMON は検証とインプリメントが完了した形

で提供される自己完結型のブロックで、ザイリンクスのセキュリティ機能を統合し、非常に高い使い勝手を実現し

ています。

たとえば SYSMON ブロックのレジスタインターフェイスを使用して SYSMON ブロックを設定し、オンチップ電圧

およびジャンクション温度監視するようにできます。 SYSMON ブロックにはアラーム生成ロジックも内蔵されてお

り、特定のアラーム条件に基づいてプロセッサへの割り込みを生成できます。たとえば、過温度 (OT) アラームが生

成されるとシステムをシャットダウンするといったことが可能です。図 8-8 に、 Zynq UltraScale+ デバイスの

SYSMON ブロックを示します。



http://japan.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug1137-zynq-ultrascale-mpsoc-swdev.pdf;a=xRevocationAsATamperPenalty

http://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xSecurityRelatedEFUSEs



図 8‐8: システムモニター (SYSMON) ブロック


AXI/APB Interconnect APB

Splitter

Reg

iste

rs

APB To

DRP

PS SYSMON

PL SYSMON

DRP Bus

Alarm

Alarm

DRP Bus

Remote Temperature Sensorfrom Full Power Domain

PS Lower Power Domain PL

APB To

DRP

X15149-021216

SYSMON には次に示すセキュリティおよび安全機能があります。

• JTAG ポートの監視とブロック

• 低電力ドメイン (LPD) を含む電源電圧の監視

• デバイスのダイ温度監視 (APU、 RPU、および PL)

• ユーザークロック監視 (8 つの周波数モニター ) およびウォッチドッグ

• パーシャルコンフィギュレーション管理

• コンフィギュレーション RAM の整合性監視

• BIST (Built-In Self Test) による自己診断

SYSMON は、 LPD の LPD I/O ペリフェラルアドレスマップを経由してアクセス可能なダイナミックリコンフィ

ギュレーションポート (DRP) を使用して構成できます。

SYSMON の詳細は、『Zynq UltraScale+ MPSoC テクニカルリファレンスマニュアル』 (UG1085) [参照 7] のこのセク

ションを参照してください。



http://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xPSSystemMonitor

http://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xPSSystemMonitor



DPA 攻撃からの保護

差分電力解析 (DPA) 攻撃とは、デバイスが情報を復号化しているときにデバイス全体の消費電力や放射電磁波の信

号をある一定時間にわたってサンプリングし、その統計情報を使用して変化を解析することによって秘密キーを特

定しようとする攻撃をいいます。このように、総当たり攻撃を実行したり使用されている暗号アルゴリズムの弱点

を見つけようとしたりするのではなく、システムインプリメンテーションを監視してデバイスまたはその動作につ

いての情報を得ようとするタイプの攻撃を「サイドチャネル攻撃」と呼びます。

DPA 攻撃を防ぐには、計測値として現れる消費電力や電磁波放射の変動を小限に抑えるバランス回路を使用する

方法や、計測に対してノイズフロアを引き上げる方法などがあります。イメージのロードに関して、 Zynq

UltraScale+ デバイスは攻撃者が収集できるデータ量を制限し、サイドチャネル情報に対して十分な解析を行えなく

するアプローチを採用しています。

一般に、 DPA 攻撃には次の 2 つの形態があります。

• ランダムデータ攻撃: 攻撃者が暗号システムにランダムデータを送り込み、「秘密」 (AES キー ) を抽出するのに

十分なサイドチャネル情報を収集しようとする攻撃です。

• グッドデータ攻撃: プログラミングファイルは非常に大きいため、攻撃者が有効なイメージを暗号システムへ

の入力として使用した場合、解析を実行するのに十分なサイドチャネル情報を収集できることがあります。

ランダムデータ攻撃を防ぐには、公開鍵非対称認証 (RSA) を実行してから復号処理を実行します。こうすると、正

当なイメージのみ復号を許可できます。

グッドデータ攻撃を防ぐには、ブートイメージを複数の小さなイメージに分割し、それぞれを異なるキーで暗号化

します (キーローリング)。ブロックのサイズは選択でき、デバイスの eFUSE または BBRAM に格納する必要がある

のは初のキーのみです。 2 番目以降のキーはすべて直前のブロックで保護、認証、および復号化されます。

図 8‐9: 差分電力解析 (DPA) への対抗策






CSU ハードウェアアクセラレータ

CSU の暗号機能はブート時に使用する以外にも、 RSA、 SHA、および AES-GCM の暗号処理のハードウェアアクセ

ラレーションに使用できます。これら機能の詳細は、『Zynq UltraScale+ MPSoC テクニカルリファレンスマニュア

ル』 (UG1085) [参照 7] を参照してください。

機能安全

セキュリティに密接に関連するもう 1 つの分野として、機能安全があります。これは、システム動作の正しさにつ

いて扱う分野です。 Zynq UltraScale+ デバイスには、機能安全をサポートする機能がいくつかあります。詳細は、

『Zynq UltraScale+ MPSoC テクニカルリファレンスマニュアル』 (UG1085) [参照 7] のこのセクションを参照してくだ

さい。

セーフティクリティカルアプリケーションに適な機能の 1 つに、 RPU のロックステップモードがあります。デザ

インプロセスの一部としてアプリケーションの特定の部位を IEC61508 や ISO26262 などの機能安全規格に適合させ

る必要がある場合は、このモードが特に役立ちます。 RPU の ARM Cortex R5 のアーキテクチャは、システムのハー

ドウェア故障への応答が必要とされる高信頼性アプリケーション向けに設計されています。また、ザイリンクスの

デザインツールスイートは TUV SUD 認証に適合したツールセットによって機能安全デザインフローをサポートし

ており、プロジェクトの安全認証プロセスを短期間で完了できます。

プロセッシングシステムにおける信頼性と FIT の特定および応答は、 Zynq UltraScale+ デバイスの分離アーキテク

チャによって達成されます。 RPU は Zynq UltraScale+ デバイスアーキテクチャのその他の部分から完全に独立した

システムとして分離でき、アクセスは特定のペリフェラルおよびメモリアドレスのみに限定できます。インターコ

ネクトレベルでは、「リソースの分離と分割」の章で説明したザイリンクスメモリ保護ユニット (XMPU) とザイリ

ンクスペリフェラル保護ユニット (XPPU) を使用してアクセスを制御します。これらのコンポーネントは、メモリ

またはペリフェラルに対するデータトランザクションを権限のあるサブシステムコンポーネントのみに限定しま

す。また、各サブシステムに対するデータトランザクションは ARM TrustZone アーキテクチャによってアクセス権

限が個別にチェックされます。

実際のデザインで機能安全の問題に対処する方法の詳細は、『Xilinx All Programmable Functional Safety Design Flow

Solution Product Brief』 (PB015) [参照 12] および『Xilinx Reduces Risk and Increases Efficiency for IEC61508 and ISO26262

Certified Safety Applications White Paper』 (WP461) [参照 13] を参照してください。



http://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xSafety


第 9 章

マルチメディアZynq® UltraScale+™ MPSoC デバイスは、先端のプログラマブルロジック (PL)、ビデオおよびオーディオ処理機能

を備えた DisplayPort、消費電力を抑えたグラフィックスプロセッシングユニット (GPU)、ビデオの同時エンコード /

デコードをサポートしたビデオコーデックユニット (VCU) を組み合わせています。この豊富なマルチメディア機能

により、きわめて要求の厳しいマルチメディアアプリケーションにも対処できる性能と柔軟性を実現しています。

この章では、これらの機能およびその使用に関する推奨事項について説明します。

マルチメディア要件を定義する

通常、マルチメディアアプリケーションは非常に多くのシステムリソースを必要とします。 Zynq UltraScale+

MPSoC デバイスはマルチメディアに適化して設計されていますが、マルチメディア要件を Zynq UltraScale+

MPSoC デバイスの機能でどのように満たすのかを十分に理解しておく必要があります。具体的には、「プロセッシ

ングシステム」および「メモリ」の章の内容を理解した上で、システムインターコネクトおよびメモリ機能の観点

からデータ処理のパスを特定してそれぞれのパスの相互関係を理解する作業が必要です。


• グラフィックスアクセラレーションを必要とするデザインですか。

• Zynq UltraScale+ MPSoC デバイスをユーザーディスプレイを使用するシステムの一部として使用しますか。

• アプリケーションにオーディオ出力はありますか。

• アプリケーションプロセッシングユニット (APU) でどの OS を使用する予定ですか。

• カスタムマルチメディア処理を必要とするデザインですか。




第 9 章: マルチメディア

マルチメディアに関する設計手法

これまでの章と同様、このセクションでは Zynq UltraScale+ MPSoC デバイスのマルチメディア機能に関連するシス

テムコンポーネントに焦点を当てて説明していきます。このため、図 9-1 には Zynq UltraScale+ MPSoC デバイスの

マルチメディアに関係する主要なブロックとその相互関係のみを示しています。この図に記載されていない主要な

コンポーネントとして APU があります。 APU はマルチメディアソフトウェアスタックが必要な場合にはほぼ例外

なく使用しますが、それは主にコマンドおよび制御用コンポーネントとしての役割であり、マルチメディア処理に

必要なデータ転送/処理にはほとんど関与しません。マルチメディアデザインでは後者に重点を置いて考える必要が

あります。

図 9‐1: Zynq UltraScale+ MPSoC デバイスのマルチメディアコンポーネント


GPU

VCU

Programmable Logic

PS-GTRDisplayPortDisplayPort

DDRMemory

Controller

X18927-032117

注記: 図 9-1 は Zynq UltraScale+ MPSoC デバイスの内部ブロックを正確に表現したものではなく、このセクションで


図 9-1 で、マルチメディアに関して考慮すべきも重要なコンポーネントはメモリです。マルチメディア処理では

通常、大量のメモリ転送が発生します。したがって、マルチメディアスループットを向上させるには何らかの方法

でメモリ転送を小限に抑える必要があります。メモリ転送が避けられない場合は、メモリ転送に使用するパスに

ついて (転送中にどのブロックがそのパスにアクセスする必要があるかを含め) 十分に理解しておくことがシステム

の正しい動作には欠かせません。

たとえば GPU は主にレンダリング対象データを RAM から取得し、レンダリング済みコンテンツを同じく RAM に存

在するディスプレイバッファーに戻します。 DisplayPort はメモリからビデオおよびオーディオバッファーを読み出

し、出力を PS-GTR トランシーバーに送信するか、さらなる処理が必要な場合はプログラマブルロジック (PL) に送

信します。また、 VCU のエンコードおよびデコード処理でもメモリとの間でデータ移動が発生します。したがっ

て、第 2 章「プロセッシングシステム」で説明したインターコネクトを十分に理解すると共に、既存のメモリ帯域

幅ではアプリケーションに不十分な場合の対策について第 6 章「メモリ」の推奨事項を参照することを推奨します。





マルチメディアでもう 1 つ重要なのが、ソフトウェアサポートです。ザイリンクスは Zynq UltraScale+ MPSoC デバ

イスのマルチメディア機能用に Linux ベースのソフトウェアスタックを提供しています。したがって、これらのス

タックを利用する場合は APU で Linux を動作させる必要があります。

DisplayPort

Zynq UltraScale+ MPSoC デバイスの DisplayPort コントローラーは VESA DisplayPort v1.2a 仕様 (ソースのみ) に準拠し、

ビデオ、グラフィックスおよびオーディオをサポートしています。ビデオパイプラインとグラフィックスパイプラ

インはアルファブレンドまたはクロマキーのステージまで独立して動作し、そこでこれらが合成されます。図 9-2

に、 DisplayPort コントローラーのデータフローの概略図を示します。

図 9‐2: DisplayPort の概略ブロック図






DisplayPort には 2 つのデータソースがあります。 DisplayPort は DMA マスターとして動作してメモリから非ライブ

データを取得し、 PL からライブデータを受信します。出力先は PS-GTR と PL のいずれかとなります。図 9-3 に、

DisplayPort の機能の詳細図を示します。

図 9‐3: DisplayPort コントローラー内のデータフロー


Interrupt

High Level Address Decoder

APB

Display PortSource

Controller

Link layer and PHY layer logic. PS-GTR is at the system level.

128-bit AXI-S (Memory)

Live Native Video Input(36-bit Video +

36-bit Graphics + 8-bit Alpha)

Live Audio Input(AXI-S 32-bit)

Video Stream 1

AUX + HPDNative Video (Mapped to

48-bit)

APB Master

Lane0: 16-bit Data + 2-bit

Lane1: 16-bit Data + 2-bit

PS-GTR Status

32-bit AXI-S (Audio)

Video Stream 2

Audio Stream 1

Audio Stream 2

Blended Video to

PL

Mixed Audio to

PL

ExternalVSYNCEvent

ExternalCustomEvent 1

ExternalCustomEvent 2

Audio/Video Buffer Manager

and STC

Audio Mixer

Video RenderingPipeline

Channel 0

Channel 1

Channel 2

Channel 3

Channel 4

Channel 5

DPDMA

PS

-GTR

X16959-092516

ビデオ/グラフィックスレンダリングパイプライン

前のセクションの DisplayPort コントローラーのブロック図に示したように、ビデオレンダリングパイプラインには

いくつかの入力ストリームがあり、これらを 1 つのビデオ出力にまとめる必要があります。前述のとおり、

DisplayPort には主な入力ソースとして PL からのライブデータとメモリ内バッファーの 2 つがあります。前者は PL

から DisplayPort に直接接続していますが、後者はダイレクトメモリアクセス (DMA) を使用して転送されます。

図 9-4 に、各種入力ストリームに対するビデオレンダリングパイプラインでの処理を示します。





図 9‐4: DisplayPort コントローラーのビデオレンダリングパイプラインのブロック図


Test PatternGenerator

Live VideoInterface DisplayPort DMA Live Graphics

Interface

MUX Split

4:2:0 or 4:2:2

CHROMA Up Sampling

Color Space Conversion


Alpha Blending


Chroma Sub-sampling

MUX

Pallete or Bypass

Video Rendering Pipeline

Video Graphics

To Display Port Core/PL

4:2:2 or 4:4:4

4:2:2 or 4:4:4

X15506-092516

ビデオパイプラインは次のいずれかの動作モードに設定できます。

• ライブプレゼンテーションモード

° このモードでは、 PL のみを A/V データソースとして使用します。 A/V データからのタイミング情報を使用

して DisplayPort コントローラーを駆動します。

• 非ライブプレゼンテーションモード

° このモードでは、 DisplayPort DMA を使用してメモリから AXI 経由で A/V データをフェッチします。この

モードでは、ソフトウェアを使用してオーディオとビデオを正しく同期させる必要があります。このため、

DisplayPort コントローラーが使用する DMA ディスクリプター内部のタイムスタンプを用いて同期を取りま

す。 DisplayPort DMA (DPDMA) の機能については後述します。

• 混在プレゼンテーションモード

° このモードは、上記の 2 つのモードを組み合わせたものです。





ブレンディングステージは、図 9-5 に示すようにアルファブレンドまたはクロマキーのいずれかの方法で実行され

ます。

図 9‐5: ビデオブレンディングステージ


Chroma Upsampling

Input Color Space

Converter

input_video_color_format[3:0]

Chroma Upsampling

Input Color Space

Converter

graphics_color_format [3:0]

Alpha Blending (RGB) or Chroma Keying

Output Color Space

Converter

output_color_format[3:0]

Chroma Subsampling Video Out

Video 1

Video 2

Alpha

X17915-092516

アルファブレンド

DisplayPort コントローラーは、デフォルトではアルファブレンドの方法で 2 つのデータソースを合成します。アル

ファブレンドは、ある決まった計算式を使用して 2 つのイメージをブレンドします。アルファブレンドプロセスの

いくつかのパラメーター (ブレンディングマトリックス、係数など) は DisplayPort コントローラーのレジスタでプロ

グラムできます。

クロマキー

クロマキーは 2 つのイメージまたはビデオストリームをレイヤー化するビデオ手法です。これは映画製作で「グリー

ンスクリーン」と呼ばれているものと同じです。ビデオパイプラインのこのステージでは、キーとなるカラーを 1 つ

選ぶ必要があります。このパイプラインステージが完了すると、キーに指定したカラーはパイプラインの 2 番目の

データソースの内容で置き換わります。クロマキーを有効にすると、パイプラインのアルファブレンドステージの

代わりにクロマキーが実行されます。

オーディオ

図 9-6 に示すように、 DisplayPort コントローラーは 2 つの独立したソースからのオーディオも管理できます。 2 つの

ソースが互換の場合、これらはパイプラインで合成されます。一方の入力は、テストパターンジェネレーター、ス

トリーミングオーディオ、非ライブオーディオインターフェイス (DPDMA) のいずれかが可能です。もう一方の入

力は非ライブオーディオインターフェイスとする必要があります。各ストリームにはそれぞれ独立したボリューム

コントロールがあります。





図 9‐6: MPSoC のディスプレイコントローラーのテクニカルモジュール


DisplayPort DMA

DPDMA コントローラーは大 6 チャネルをサポートします。 DDR コントローラーとは、 128 ビット AXI3 マスター

ポートを使用して通信します。 DPDMA で使用するディスクリプターには 16 個の異なるデータワードが含まれま

す。 DDR コントローラーの汎用 DMA ディスクリプター同様、 DPDMA ディスクリプターにもディスクリプターが

指し示すデータのサイズを宣言するフィールド (XFER_SIZE) と次のポインターのアドレスを指定するフィールド

(ADDR_NEXT) があります。また、これ以外にも LINE_SIZE、 STRIDE、 TIME_STAMP_LSB、 TIME_STAMP_MSB

など、ディスクリプターが指し示すデータを記述する DisplayPort 特有のフィールドがあります。

Linux DisplayPort スタック

前述のとおり、 Zynq UltraScale+ MPSoC デバイスのマルチメディア機能は Linux 環境でサポートされます。図 9-7 に、

DisplayPort を動作させるための Linux パッケージの一部としてザイリンクスが提供する Linux ベースのソフトウェア

スタックを示します。





図 9‐7: DisplayPort Linux ソフトウェアスタック


DisplayPort サブシステムの Linux スタックは、 DisplayPort ハードウェアの上位に存在する次の 2 つのレイヤーで構成

されます。

• 下層にあるのはカーネルレイヤーで、 DRM (Direct Rendering Manager)、 KMS (Kernel Mode Setting)、 DMA エン

ジン、および ALSA (Advanced Linux Sound Architecture) ドライバーで構成されます。

° DRM フレームワークは、グラフィックスハードウェアへの接続に使用します。

° KMS ドライバーはディスプレイモードの設定に使用します。これがディスプレイコントローラーのデバ

イスドライバーです。

° DMA エンジンは DMA 転送をサポートします。

° ALSA はオーディオハードウェア用のデバイスドライバーとローレベルサポートを提供します。

• カーネルレベルの上位には、ライブラリとサーバーで構成されるユーザーレベルがあります。

° Libdrm は、ユーザー空間のプログラムと DRM サブシステムを接続するためのユーザーライブラリです。

° Libasound は、アプリケーションプログラムに ALSA 機能を提供するユーザーライブラリです。

° X11 ディスプレイサーバーは、ディスプレイ装置上のウィンドウの描画と移動、およびマウス /キーボード

との通信など GUI 環境の構築に必要な基本フレームワークを提供します。

° Wayland ディスプレイサーバーは X11 ディスプレイサーバーよりも新しいディスプレイサーバーで、 X11

の置き換えとして使用できます。

° PA オーディオサーバーは、複数のオーディオアプリケーションがサウンド /オーディオデバイスに同時に

アクセスして使用できるように管理します。





GPU

Zynq UltraScale+ MPSoC デバイスのグラフィックスプロセッシングユニット (GPU) は ARM Mali-400 MP2 アーキテ

クチャをベースにしており、 2D および 3D アクセラレーションをサポートしています。 Zynq UltraScale+ MPSoC デバ

イスのその他のマルチメディア機能同様、 GPU の動作にも Linux が必要です。 Mali GPU 向け Linux プラットフォー

ム上では、X11 と FBDEV のどちらのウィンドウシステムに対しても OpenGLES1.1 と OpenGLES 2.0 を両方サポート

した OpenGL グラフィックスライブラリを利用できます。図 9-8 に、 GPU のブロック図を示します。

図 9‐8: Mali GPU のブロック図


GeometryProcessor

MMU

AXI 64-bit

L2 Cache (64 KB)

PixelProcessor

MMU

AXI 64-bit

PixelProcessor

MMU

AXI 64-bit

AXI 128-bitAPB 32-bit

GPU 自体の動作、および GPU とそれ以外のシステムとの通信を理解するには、図 9-9 に示すような GPU に関する

データフローを見るのがも効果的です。





図 9‐9: GPU に関するデータフローの概略図


この図のステップ 1 では、 APU 上で動作するソフトウェアが GL ライブラリを使用して頂点データを RAM の頂点

バッファーに書き込みます。ステップ 2 では、これらの頂点データがジオメトリプロセッサに読み込まれて処理さ

れ、ステップ 3 でポリゴンリストとして書き込まれます。ステップ 4 では、ポリゴンとテクスチャがピクセルプロ

セッサに読み込まれ、ステップ 5 で終イメージとしてフレームバッファーにレンダリングされます。

GPU の動作は一般にレンダリングパイプラインと呼ばれるプロセスで構成され、アプリケーションから初に受け

取ったデータセットをいくつかの工程を経てイメージにレンダリングして画面に表示します。現在の GPU はプログ

ラマブルパイプラインという概念に基づいて構成されています。 Zynq UltraScale+ MPSoC デバイスの GPU パイプラ

イン (図 9-10) は GLSL API (OpenGL Shading Language) でプログラムします。





図 9‐10: Zynq UltraScale+ MPSoC デバイスの Mali 400 ベース GPU のパイプライン


Geometry Processing Pixels Processing

Application Vertex Setup Vertex Shader Rasterizer Fragment Shader Frame buffer

Texturing

ジオメトリ処理ステージでは、アプリケーションから送信された生の頂点データを処理します。描画コマンドを実

行して頂点配列オブジェクトで指定された頂点属性データを頂点シェーダーに入力すると、個々の頂点が処理され、

レンダリング不要な頂点が削除されます。後にこれらの頂点を連結してプリミティブを作成し、次のステージに

渡します。ラスタライザーは個々のプリミティブを受け取り、これらをプリミティブのサンプルカバレッジに基づ

いてフラグメントと呼ばれるディスクリート画素に分解します。フラグメントシェーダーはラスタライザーで生成

されたフラグメントに対して、深度値、可能なステンシル値 (フラグメントシェーダーによって変更されない)、お

よびゼロ以上のカラー値を正規化して処理します。これらはすべて現在のフレームバッファーに書き込まれる可能

性があります。

先に示したデータフロー図からもわかるように、レンダリングパイプラインの各処理ではメモリと GPU の間でい

くつかの転送が実行されます。このため、 Mali GPU ではメモリ転送の少ないタイルベースのレンダラーを採用して

います。このタイルベースのレンダラーの利点を理解するには、まず従来の GPU の動作方式である即時モード

(Immediate Mode) について見ていく必要があります。即時モードアーキテクチャでは、メモリに保存された頂点

データはフラグメントシェーダーで処理された後、 1 つずつ直接レンダリングされます。描画呼び出しのたびにフ

ラグメントシェーダーがプリミティブを 1 つずつ順番に処理します (図 9-11)。

図 9‐11: 即時モードレンダラーのデータフロー


GPU Vertex Shader FIFO Fragment Shader

DDR Attributes Textures FramebufferWorking Set

X18928-032117

ブレンド、深度テスト、およびステンシルテストを実行するたびに、現在のフラグメントのピクセル座標に対応す

るデータの現在値を DRAM のオフチップバッファーからフェッチする必要があります。 1 つのフラグメントにつき

多数の Read-Modify-Write 動作が発生するため、高解像度では特にシステムメモリの帯域幅が圧迫される可能性があ

ります。また、 GPU は高い周波数で動作する必要があるため、外部メモリも一般的なシステムメモリより高い周波

数での動作が必要となります。これらはいずれも GPU の消費電力増大を招きます。





レンダリング時のメモリトランザクションを小限に抑えるため、 Mali GPU は異なるアプローチとしてタイルベー

スのレンダリング手法を採用しています。タイルとは通常、フレームバッファー内の多数のピクセルで構成される

正方形をいいます。処理対象のタイルはオンチップ GPU メモリバッファーに格納されます。ここには、現在レンダ

リングしているタイルのフレームバッファー内容が格納されています。タイルベースのレンダリングではフレーム

バッファーの内容をオフチップメモリとの間で転送するトラフィックが小限に抑えられ、帯域幅およびメモリバ

ス性能の要件を緩和できます。図 9-12 に示すように、 ARM Mali は 2 パスレンダリングストラテジを採用していま

す。

1 回目のパスですべてのジオメトリ処理を実行し、 2 回目のパスですべてのフラグメント処理を実行します。ジオメ

トリ処理ステージでは、レンダリング領域を 16x16 ピクセルのタイルに分割します。フラグメントシェーダーコア

は各タイルを完全に処理してから次のタイル処理を開始します。 Mali 400 では 2 つのピクセルプロセッサが 2 つの

タイルを同時にレンダリングできるため、 GPU スループットが向上しています。

図 9‐12: タイルベースレンダラーのデータフロー


GPU Vertex Shader Tiler Fragment Shader

DDR Attributes

LocalTile Memory

GeometryWorking Set Textures Compressed

Framebuffer

X18929-032117

外部メモリへのトランザクションを小限に抑えるだけでなく、この手法にはもう 1 つの利点もあります。それは、

タイルは GPU のメモリ内で局所性があるため、頂点データをメインメモリからフェッチしなくてもいくつかのグラ

フィックアルゴリズムを効率よく適用できるという点です。

ジオメトリプロセッサ

ここまで GPU の全体的な機能について見てきました。次に、ジオメトリプロセッサとその内部コンポーネント (図 9-13) について詳しく説明します。ジオメトリプロセッサは、イメージにレンダリングされる頂点に対してデー

タ処理を実行します。その名が示すように、ジオメトリプロセッサはイメージジオメトリを扱うもので、供給され

たデータに対して GL ライブラリの API を使用して数学演算を実行します。





図 9‐13: Mali GPU のジオメトリプロセッサのブロック図


Geometry Processor

GPU

System Bus Interface

Vertex Shader

Command Processor

PLB Command Processor

PLB

Vertex Shader Core

Vertex Shader

Vertex Storer

Vertex Loader

Configuration Registers

MMU

L2 Cache

Pixel Processor

MMU

X15300-032817

頂点シェーダー

ジオメトリプロセッサの前半に位置する内部コンポーネントが頂点シェーダーコアです。この中には次のものが含

まれます。

• 頂点ローダー

° 頂点ごとに処理が必要なデータをメインシステムメモリからロードする DMA ユニットです。

• 頂点シェーダー

° 各頂点に対して計算を実行します。パイプラインの後段で処理されるポリゴンリストは、この出力を使用

して作成されます。

• 頂点ストアラー

° 頂点シェーダーコアの出力レジスタからのデータをメモリに格納します。 32 ビット浮動小数点形式のデー

タを固定小数点またはサイズの異なる浮動小数点形式のデータに変換する機能もあります。





ポリゴンリストビルダー

ポリゴンリストビルダー (PLB) は、ピクセルシェーダーで処理するポリゴンのリストを作成します。前述のとお

り、 Mali GPU はレンダリング領域を複数のタイルに分割し、タイル単位でレンダリングを実行します。 Zynq

UltraScale+ MPSoC デバイスの Mali 400 では、 2 つのピクセルプロセッサがそれぞれ 2 つのタイルを並列に処理しま

す。ピクセルプロセッサが処理を開始する前に、 PLB が各タイルでレンダリングするポリゴンのリストを生成して

おく必要があります。ほかのポリゴンに隠れるポリゴンはリストから削除します。

ピクセルプロセッサ

ジオメトリプロセッサによってポリゴンの準備が完了したら、ポリゴンデータがピクセルプロセッサに渡され、こ

こで GPU パイプラインのフラグメントシェーダーステージが実行されます。図 9-14 に、各ピクセルプロセッサの

ブロック図を示します。

図 9‐14: ピクセルプロセッサのブロック図


Geometry Processor

GPU

System Bus Interface

MMU

L2 Cache

Pixel Processor

MMU

Title Writeback Unit

Tile Buffers

BlendingUnitRasterizer Fragment

Shader

Configuration Registers

Vertex Loader

Polygon List

Reader

Triangle Setup Unit

RSW

X15302-091616

各ピクセルプロセッサの動作は次のとおりです。

1. トライアングルセットアップユニットは PLB によって生成されたポリゴンリストを入力として受け取り、トラ

イアングルを構築します。

2. ラスタライザーは入力データを独立したフラグメントに分割します。終的にレンダリングされるフラグメン

トのみが次のステージに進み、隠れて見えないフラグメントは破棄されます。

3. フラグメントシェーダーコアは、プリミティブからの各フラグメントがどのように見えるかを計算します。

4. ブレンディングユニットは計算後のフラグメントをタイルバッファーにブレンドし、終的なイメージを生成

します。フラグメントをブレンドする方法は、フラグメントを不透明にするか、一部を透明にするかを設定で

きます。低解像度でイメージのエッジを目立たなくするアンチエイリアシング処理もこのステージで適用され

ます。





5. タイルバッファーモジュールは前のステージで完成したタイルを処理し、不要なフラグメントを画面に描画し

ないようにフラグメントに対して各種テストを実行します。

6. タイルライトバックユニットはタイルバッファーの内容をシステムメモリに書き戻します。

Linux GPU ソフトウェアスタック

その他のマルチメディアコンポーネント同様、 Zynq UltraScale+ MPSoC デバイスの GPU は Linux 環境でサポートさ

れます。図 9-15 に、 GPU を動作させるための Linux パッケージの一部としてザイリンクスが提供する Linux ベース

のソフトウェアスタックを示します。

図 9‐15: Linux GPU ソフトウェアスタック


Linux GPU ソフトウェアスタックには次のレイヤーがあります。

• 下層には Mali カーネルドライバーがあります。このレイヤーは MMU、 GP、 PP、 L2 キャッシュ、 PMU など

の各種ハードウェアコンポーネントのドライバーで構成されます。

• ドライバーの上位にはユーザーライブラリがあります。

° Mali 共通ユーザーライブラリには GPU 共通のライブラリが含まれます。

° EGL は、 OpenGL ES や OpenVG などの Khronos レンダリング API と下層のネイティブプラットフォーム

ウィンドウシステムの間のインターフェイスです。 EGL はグラフィックスコンテキスト管理、サーフェス/

バッファーバインド、レンダリング同期を実行し、ほかの Khronos API を使用して高性能で高速な 2D およ

び 3D 混合レンダリングを実現します。

° OpenGL (Open Graphics Language) は 3D グラフィックス向けのオープンな業界標準 API で、ハードウェアア

クセラレーションを利用して、テクスチャ処理をした三角形の描画に対応します。 OpenGL は基本的にはグ

ラフィックスハードウェアに対するソフトウェアインターフェイスです。

° OpenVG は 2D グラフィックスのハードウェアアクセラレーション用 API です。





• スタックの上位にはグラフィックスアプリケーションがあります。

ARM Mali GPU 上でのデバッグ

Mali グラフィックスデバッガー (MGD) は、 Mali ハードウェアを使用する開発者が Mali GPU 上で動作するプログラ

ムをデバッグするためのツールです。図 9-16 に、その動作をまとめます。

図 9‐16: Mali グラフィックスデバッガー (MGD)


MGD には、アプリケーションで実行している GPU 処理の理解に役立つ次のような機能があります。

• 描画呼び出し (Draw Call) のステップ実行

• テクスチャ使用状況の表示

• シェーダー統計情報

• 頂点属性

• ステート表示

• 動的適化アドバイス

Zynq UltraScale+ MPSoC デバイスを搭載したザイリンクス ZCU102 評価キットでの MGD の使用方法の詳細は、

「Zynq UltraScale+ MPSoC グラフィックス : ARM Mali グラフィックスデバッガー (MGD) を使用した GPU アプリケー

ションのデバッグ」の Wiki ページ [参照 19] を参照してください。





VCU

一部の Zynq UltraScale+ MPSoC デバイスには、プログラマブルロジック (PL) にビデオコーデックユニット (VCU)

があります。 VCU はビデオデータのエンコード /デコード速度が重視されるビデオアプリケーションに特に適して

います。 VCU は H.264 および H.265 フォーマットの同時デコード /エンコードをサポートしています。図 9-17 に、シ

ステム概略図における VCU の位置を示します。

図 9‐17: Zynq UltraScale+ MPSoC デバイスの VCU の位置


VCU には独立したビデオエンコードユニットとデコードユニットがあります。各ユニットはマイクロコントロー

ラーユニット (MCU) によって制御されます。この MCU は、 AXI インターフェイスから受信したエンコードまたは

デコード対象データのフローを制御します。 APU からデコーダーまたはエンコーダーの MCU ユニットにコマンド

が渡され、エンコーダーの場合は各フレーム、デコーダーの場合は各スライスまたはタイルに対して処理が実行さ

れます。 MCU へのコマンドはレジスタ経由で渡すことも、メインメモリにコピーして MCU が読み出すこともでき

ます。





図 9-18 に、 VCU のビデオエンコーダーのアーキテクチャを示します。

図 9‐18: VCU のビデオエンコーダーのアーキテクチャ


VCU のエンコーダーユニットには 32 ビットスレーブ AXI インターフェイスが 1 つあり、 APU はこれを使用してエ

ンコーダーユニットと通信してエンコーダーユニットの構成およびエンコード動作の開始/停止を実行します。 AXI

マスターインターフェイスは MCU 命令のフェッチ用に 2 つ、 MCU データのロード /ストア用に 1 つを使用します。

MCU は 2 つの 128 ビット AXI インターフェイスを使用してエンコード対象データを抽出し、エンコード済みデータ

を書き戻します。これ以外にも、 VCU には必要に応じてエンコーダーを PL BRAM または UltraRAM ブロックに接続

して使用するためのインターフェイスがあります。図 9-19 に、 VCU のビデオデコーダーのアーキテクチャを示し

ます。





図 9‐19: VCU のビデオデコーダーのアーキテクチャ


ビデオデコーダーユニットもエンコーダーユニットと同様のアーキテクチャを使用して動作します。エンコーダー

の場合と同様、 2 つの AXI マスターインターフェイスを使用してデコード対象データをフェッチし、デコード済み

データをメモリに書き込みます。

VCU は低レイテンシモードにも設定できます。この場合、入力からコーデック (またはコーデックからの出力) まで

のレイテンシは削減されますが、圧縮品質が低下します。

メモリトポロジ

前述のとおり、 VCU の動作ではメモリからのデータ取得とメモリへのデータ保存が発生します。 VCU は PL の一部

であるため、コンフィギュレーションに応じて 3 つのメモリトポロジを使用できます。具体的には、次のいずれか

の構成が可能です。

1. DDR コントローラー経由で DDR RAM を使用する方法

2. PL で Memory Interface Generator (MIG) を使用して外部メモリに接続する方法 (第 6 章「メモリ」参照)

3. 上の 2 つを組み合わせた方法

図 9-20 ～図 9-22 にこれらの構成を示します。





図 9‐20: DDR コントローラー経由でアクセス可能な RAM を使用した VCU


図 9‐21: PL で Memory Interface Generator を使用した VCU






図 9‐22: DDR RAM と PL の MIG を組み合わせて使用した VCU


前述のとおり、マルチメディアアプリケーションの設計で考慮すべきも重要な事項はメモリ帯域幅です。 GPU や

DisplayPort とは異なり、 VCU はオプションで PL のリコンフィギャラブルロジックを使用してメモリ帯域幅を拡大

でき、 PL 内のメモリコントローラーを使用することで DDR コントローラーのみを使用した場合よりも広い帯域幅

を確保できます。メモリ帯域幅の説明、およびシステムデザインでメモリ帯域幅が不足する場合の調整方法の詳細

は、第 6 章「メモリ」を参照してください。





Linux ビデオコーデックドライバースタック

これまで説明したマルチメディアコンポーネント同様、 Zynq UltraScale+ MPSoC デバイスの VCU は Linux 環境でサ

ポートされます。図 9-23 に、 VCU を動作させるための Linux パッケージの一部としてザイリンクスが提供する

Linux ベースのソフトウェアスタックを示します。

図 9‐23: Linux ビデオコーデックドライバースタック


Video Application

Open MAX Implementation Layer (OMX IL)

VCU Hardware

MCU Decodercore+

Decoder IPMCU Encoder

core+Encoder IP

gstreamer

gstreamer OMX IL plugins

Driver APIs

Kernel Driver(ioctl)

User space

Kernel space

Hardware

Linux ビデオコーデックドライバースタックには次のレイヤーがあります。

• ハードウェアの上位に位置する下層のスタックがカーネル空間です。これは Video for Linux 2 (V4L2) ドライ

バーと I/O Control (ioctl) カーネルドライバーで構成されます。 V4L2 はビデオキャプチャに使用する標準 Linux

カーネルインターフェイスです。 V4L2 にはキャプチャ寸法とカラーフォーマットを選択するための専用イン

ターフェイスがあります。 Memory-to-Memory デバイスがサポートされます。また、メモリ割り当てやバッファ

リングなどの一般的な機能もあります。

• カーネル空間の上位にはユーザー空間があります。このレイヤーは Gstreamer/Bellagio OMX IL および OpenMAX

ライブラリで構成されます。

° Gstreamer は、各種メディア処理システムを連結して複雑なワークフロー (あるフォーマットでデータを読

み込み、処理後に別のフォーマットでデータを出力するなど) を完成させるパイプラインベースのマルチ

メディアフレームワークです。 Bellagio OMX IL (OpenMAX Integration Layer) は、プラットフォーム上の

ハードウェアアクセラレータにアクセスできる標準 API です。

° OpenMAX ライブラリは、マルチメディアコーデックおよびアプリケーション移植のためのクロスプラッ

トフォーム API 群です。

• スタックの上位にはビデオアプリケーションがあります。




第 10 章

ペリフェラルZynq UltraScale+ デバイスは I2C、シリアルペリフェラルインターフェイス (SPI)、汎用 I/O (GPIO) などのレガシ I/O

インターフェイス、および PCIe、 SATA、 USB 3.0 などの新規格の両方を含む非常に多くのペリフェラルをサポー

トしています。 Zynq® UltraScale+™ デバイスでサポートされる個々のペリフェラルインターフェイスについての概

要および詳細を説明するのはこのガイドの目的ではありません。この章では、各種ペリフェラルをサポートする方

法およびこれらを使用する際に考慮すべきトレードオフについて説明します。

ペリフェラル要件を定義する

I/O 要件を理解することはシステム設計の基本であり、これを理解できれば Zynq UltraScale+ デバイスでどのペリフェ

ラル I/O 機能を使用する必要があるかを容易に判断できるようになります。このため、ペリフェラルの要件定義に関

して Zynq UltraScale+ デバイス特有の考慮事項はありません。一般的な SoC の場合と同様の要件に従ってください。

ただし Zynq UltraScale+ デバイスで 1 つだけ注意が必要なのは、「電源に関する考慮事項」の章で説明したようにペ

リフェラルインターフェイスを含むシステムブロック全体が 4 つの電源ドメインに分割されているという事実で

す。したがって、どのペリフェラルを使用するかは、パワーマネージメントの要件を考慮して決定する必要があり

ます。反対に、システムのパワーマネージメントを設計する際にはどのペリフェラルが必要か、そしてそのペリ

フェラルがどの電源ドメインに属するかを考慮する必要があります。


• どのペリフェラルが必要ですか。

• そのペリフェラルはどの電源ドメインに属しますか。

• システムのウェークアップに使用するペリフェラルはありますか。




第 10 章: ペリフェラル

ペリフェラルの設計手法

これまでの章と同様、ここでもシステムの概略図を使用しながらペリフェラルの使用に関する設計手法を説明して

いきます。次の図は、各電源ドメインに属するペリフェラルおよびほかの電源ドメインとの関係を示したものです。

デバイスの外部境界、すなわちチップのピンを経由して外部世界と接続する場所は、システムの外周にグレーで

「Device Boundary (デバイス境界)」として示しています。

図 10‐1: 各電源ドメインに属するペリフェラル


Device Boundary

GigEth

USBNAND

GPIOQuad-

SPI

SD/eMMC

I2C

UARTCAN

SPI

Lower PowerDomain

PCIe

SATA

DisplayPort

Full PowerDomain

GTHQuad

Device Boundary

EMIO (Except USB, Quad-SPI and NAND)

MIOPS-GTR

100GEth

PCIeGen4

Interlaken

VCU

Programmable Logic Power

Domain

GTYQuand

USB 3.0ULPI

RGMIISGMII

X18886-032017

注記: この図は Zynq UltraScale+ MPSoC デバイスの内部ブロックを正確に表現したものではなく、このセクションで


前のセクションで説明したように、システムを設計する際には各ペリフェラルがどの電源ドメインに属しているか

を意識しておく必要があります。





Zynq UltraScale+ デバイスのペリフェラルおよびそれらが属する電源ドメインに関するもう 1 つの重要な点として、

ペリフェラルを外部世界に接続する方法が電源ドメインごとに異なることも理解しておく必要があります。低電力

ドメイン (LPD) は MIO (Multiplexed I/O) インターフェイス、フル電力ドメイン (FPD) は PS-GTR インターフェイスを

それぞれ使用して外部世界に接続します。プログラマブルロジック (PL) 電源ドメイン (PLPD) は、チップの PL ピン

をどのように接続するかは PL の構成によって決まります。一般に、 LPD に属するペリフェラルは低速ペリフェラル

に分類され、 FPD に属するペリフェラルは高速ペリフェラルに分類されます。

MIO インターフェイスは、マルチプレクサーを利用して LPD ペリフェラルを 78 本のピンに接続します。ピン機能

の割り当ては、 MIO コントローラーのレジスタにプログラムして決定します。これは通常、ザイリンクス SDK ツー

ルで生成した第 1 段階ブートローダー (FSBL) に含まれるコンフィギュレーションコードを使用して行います。MIO

コントローラーの構成は、この方法を推奨します。どのピンをどのペリフェラルに使用できるかの詳細は、『Zynq

UltraScale+ MPSoC テクニカルリファレンスマニュアル』 (UG1085) [参照 7] を参照してください。すべてのピンをす

べてのペリフェラルに使用できるわけではないため、必要なペリフェラルと利用可能なピンの数を十分に検討する

必要があります。

PL はリコンフィギュレーションが可能なため、 PL のデバイス境界にある I/O ピンの一部を PL 内の IP 以外の用途で

使用するように構成できます。具体的には、 EMIO (Extended Multiplexed I/O) を使用して LPD ペリフェラルを PL ピ

ンに接続できます。ただし例外として USB、 Quad-SPI および NAND は EMIO 経由では接続できません。 EMIO の使

用法、および EMIO 経由で接続した LPD ペリフェラルに対する制限事項は、『Zynq UltraScale+ MPSoC テクニカルリ

ファレンスマニュアル』 (UG1085) [参照 7] を参照してください。ただし、 MIO ピンが不足して必要なペリフェラル

を利用できない場合は EMIO を使用することによってこの問題を回避できます。AXI マスターから PL 内の IP にアク

セスする方法として EMIO を使用することもできますが、 PL 内の IP をシステムのその他のブロックに接続する方法

はいくつかあるため、どの方法を用いるかは第 5 章「プログラマブルロジック」を参照して十分に検討して決定し

てください。





PS-GTR は、次の図の赤で囲んだ FPD の SIOU (Serial Input Output Unit) の一部です。

図 10‐2: SIOU


CSU PSMU

RPU

GKv1

Cortex-R532K I/D Cache128 KB TCM

Cortex-R532K I/D Cache128 KB TCM

OCM(256 KB)

To P

L From

PL

APU

Cortex-A53 L1 I$/D$

GICv2

Cortex-A53 L1 I$/D$

Cortex-A53 L1 I$/D$

Cortex-A53 L1 I$/D$

SCU

ACP L2 with ECC [1MB]

128-bit ACE

CCI

TCU

Switch

FPD-DMA

DDRC (DD3/4, LP DDR3/4)

FullPower

LowPower

BatteryPower

BPU

64-b

it

PL-ACE

TBU

TBU PCIe Gen2

1/2/4

2 x SATAv3.0

DisplayPort v1.2 p1/3

Inte

rcon

nect

Mat

rix

PS

-GTR

x4

128-bit

GPUMali-4 MP2(64 KB L2)

PL

PCIeGTH

or GTY

AMS HDI/O

Vide

o C

odec

H.2

64/5

SGMIIUSB3

128-

bit

128-bit128-bit

128-bit

To CCI

To ACP

From LP

64-bit

CFG

TBU

TBU

TBU

LPD-DMA

128-

bit

TBU

128-bit64-bit

128-

bit

128-

bit

32 bit/64 bit

Processor

ROM 128 KB

RAM 32 KB

SHAAESRSA

Processor

ROM 128 KB

RAM 32 KB

SYSMON

EMIO

GPIOs

2x UART

2x I2C

2x CAN

2x SPI

QSPI

2x SDIOSD3.0

NANDONFI 3.1

2x USB3

4 x GigaE128D

UL PI

M SControl Path

M SControl Path/Datapath

M SDatapath

MIO

SIOU

X18888-032117

FPD の PS-GTR トランシーバーは 4 つのマルチギガビットレーンをサポートしており、外部世界からはこれらの

レーンを使用して FPD ペリフェラルにアクセスします。また、 PS-GTR は LPD のギガビットイーサネットおよび

USB 機能へのアクセスにも使用でき、その場合、 SGMI PHY アクセスおよび USB 3.0 をそれぞれ提供します。 4 つの

異なる PS-GTR レーンは 1.25Gbps ～ 6Gbps の周波数で動作します。 PS-GTR 経由で接続する各ペリフェラルブロッ

クには、 PS-GTR レジスタをプログラムして PS-GTR のいずれか 1 つのレーンを割り当てる必要があります。 MIO お

よび LPD ペリフェラルの場合と同様、PS-GTR には PS-GTR がデバイスのピンに同時に配線できる数よりも多くのペ

リフェラルブロックが接続されます。





したがって、 FPD のペリフェラルおよび LPD のギガビットイーサネットと USB 機能のうち、どのペリフェラルを

PS-GTR に接続するのかを選択する必要があります。ギガビットイーサネットは PS-GTR の SGMII を利用できなく

ても、 RGMII を使用してイーサネット PHY に接続できます。ギガビットイーサネットは EMIO も使用できますが、

その場合の接続は RGMII/SGMII ではなく GMII です。 USB ブロックは MIO 経由でも接続できますが、その場合は

ULPI に限られます。

ペリフェラルに関するシステム設計において、パワーマネージメントに関してもう 1 つ注意が必要なのが、ウェー

クアップ信号です。プラットフォーム管理ユニット (PMU) の汎用入力 (GPI) のいくつかは、外部ウェークアップ信

号に使用できます。また、 USB 2.0 またはイーサネットからのウェークアップも可能ですが、その場合は ULPI また

は RGMII をそれぞれ使用します。

GPIO

MIO モジュールで使用可能な全 78 ピンは、汎用 I/O (GPIO) ペリフェラルを使用して制御します。 EMIO を使用する

と、 GPIO ペリフェラルは大 96 本の PL ピンを入力として使用し、 192 本の PL ピンを出力として使用できます (96

本が純粋な出力で、残りは出力イネーブル)。 MIO に接続した GPIO 出力はトライステート (Low、 High またはハイ

インピーダンス) が可能です。次に、 GPIO ペリフェラルと MIO モジュール、および EMIO 経由での PL との接続を

ブロック図で示します。





図 10‐3: GPIO と MIO の接続、および EMIO 経由での PL との接続


AP

B Interface

APB

Event Detector

Configuration

Registers

PL

MIOPins

Pins

PS

GPIO Module

EMIO Interface to PL

gpio_in[n]

gpio_out[n]

gpio_oe[n]

gpio_in[0]

gpio_out[0]

gpio_oe[0]

gpio_in[n]

gpio_out[n]

gpio_oe[n]

gpio_in[0]

gpio_out[0]

gpio_oe[0]

X18889-032017

GPIO ピンの機能はピン単位またはグループ単位でプログラムできます。ピンは 6 つのバンク (バンク 0 ～ 5) にグ

ループ化されます。バンク 0 ～ 2 には MIO インターフェイス経由でアクセスし、バンク 3 ～ 5 には EMIO 経由でア

クセスします。次の図に、 GPIO ペリフェラルのバンクを示します。





図 10‐4: GPIO バンク


GPIOBank 0

MIO

26-bit

GPIOBank 1

26-bit

GPIOBank 2

26-bit

Pin

x78

32-bit

EMIOGPIOI[95;64]EMIOGPIOO[95;64]EMIOGPIOTN[95;64]

EMIO Interface to PL

EMIOGPIOI[31:0]EMIOGPIOO[31:0]EMIOGPIOTN[31:0]

32-bit

EMIOGPIOI[63:32]EMIOGPIOO[63:32]EMIOGPIOTN[63:32]

32-bit

GPIOBank 3

GPIOBank 4

GPIOBank 5

X18890-032017X18891-032017

割り込みをピンにトリガーする方法は、次のいずれかにカスタマイズできます。

• レベルセンス : High または Low

• エッジセンス : 立ち上がり、立ち下がり、または両方





I2C

I2C は低速ペリフェラルとの接続に使用するシンプルな 2 線式バスです。 2 本のラインのうち 1 本がデータライン

(SDA) で、もう 1 本はクロック信号 (SCL) の駆動に使用します。 I2C バス上のノードはマスターまたはスレーブのい

ずれかです。マスターノードはバスのクロック信号を駆動し、スレーブノードとの通信を開始します。スレーブ

ノードはクロック信号を受信し、マスターの要求に応答します。 I2C プロトコルは複数のマスターもサポートしてい

ます。この場合、各マスターはほかのマスターを認識し、ほかのマスターが使用中は I2C バスを使用しない必要が

あります。

Zynq UltraScale+ デバイスは I2C コントローラーモジュールを内蔵しており、マルチマスターデザインではマス

ターモードでもスレーブモードでも動作します。次に、 Zynq UltraScale+ デバイスの I2C コントローラーのブロック

図を示します。

図 10‐5: I2C ブロック図


APBInterface

InterruptsInterrupts

APB

StatusRegister

RX DataRegister

TX DataRegister

ControlRegister

ControlFSM

RX ShiftRegister

ClockEnable

Generator

SCL/SDAInterface

X18892-032017

このコントローラーの動作は、レジスタプログラミングによってマスターノードまたはスレーブノードに設定でき

ます。また、このコントローラーはポーリングモードおよび割り込みドリブンモードでも使用できます。





SPI

シリアルペリフェラルインターフェイス (SPI) バスは、電子デバイス間で I2C よりも高速な通信手段として使用し

ます。 SPI バス上のノードはマスターまたはスレーブのいずれかです。マスターは複数存在できます。このプロトコ

ルは 4 本のラインを使用して通信します。

• MOSI: マスター出力/スレーブ入力

• MISO: マスター入力/スレーブ出力

• SCLK: シリアルクロック

• SS: スレーブセレクト

MOSI および MISO 信号はマスターとスレーブ間の全二重通信に使用します。 Zynq UltraScale+ デバイスには同一の

SPI コントローラーが 2 つあり、対応するソフトウェアドライバーを使用してこれらを独立して同時に制御して動作

させることができます。次に、 Zynq UltraScale+ デバイスの SPI コントローラーのブロック図を示します。

図 10‐6: SPI コントローラーのブロック図


TX FIFO

MI

APBInterface

Transmit

SPI CTRL

RX FIFO

SPIMaster

SPISlave

ReceiveSlaveSync

SO

SS[2:0]

SCLK

SCLK

SS

SI

Interrupt Interrupts

MO

MOSI

SPI Interface

Pins

MOSI

SCLK

SS

MISO

APB

X18893-032017

Zynq UltraScale+ デバイスの SPI コントローラーは次の 3 つのモードのいずれかに設定できます。

• スレーブモード : SPI バスに接続されたほかのマスターがコントローラークロックを駆動します。

• マスターモード : SPI コントローラーがスレーブノードのクロックを管理します。通信相手のスレーブは、コン

トローラーが SS ラインを駆動して選択します。

• マルチマスターモード : 転送を実行していない間、ほかのマスターとの競合を避けるためにコントローラーを

無効にしておく必要があります。別のコントローラーがバスを使用しているかどうかは SS 信号を監視して検出

します。





SPI コントローラーはダイレクトメモリアクセス (DMA) をサポートしません。したがって通信はコントローラーの

AXI インターフェイスを使用したレジスタ読み出し /書き込みによって実行します。コントローラーには深さ 128 バ

イトの FIFO (TX および RX) があります。スレーブにデータを送信する場合、マスターはレジスタを使用して

TXFIFO にデータを書き込みます。スレーブからデータを読み出す場合、マスターは RXFIFO から読み出します。

1 バイトを TXFIFO に書き込むたびに RXFIFO に 1 バイトが格納されます。 TXFIFO に n バイトを書き込むたびに

RXFIFO には n バイトが格納されるため、ソフトウェアで RXFIFO を読み出してから次の転送を開始する必要があり

ます。

コントローラーは、データ転送中にスレーブセレクト (SS) ラインを自動的に制御するようにも、ソフトウェアで制

御するようにも設定できます。後者のモード (手動モード ) では、 SPI ソフトウェアでレジスタを操作して SS ライン

を有効にする必要があります。

UART

PART (Universal Asynchronous Receiver/Transmitter (UART) は非同期シリアル通信用のシンプルなプロトコルです。

2 つの UART モジュール間の通信のフォーマットと転送速度は設定可能ですが、通信を確立する前に指定する必要が

あります。

Zynq UltraScale+ デバイスの UART は幅広いパラメーター値をサポートしています。

• プログラム可能なボーレート

• 6、 7、または 8 データビット

• 1、 1.5、または 2 ストップビット

• 奇数、偶数、スペース、マーク、パリティなし

注記: パラメーターの詳細は、『Zynq UltraScale+ MPSoC テクニカルリファレンスマニュアル』 (UG1085) [参照 7] を参

照してください。

これらのパラメーターは、 UART コントローラー専用のレジスタで変更できます。

図 10‐7: UART コントローラー


APBSlave

Interface

PS AXIInterconnect

Control andStatus Register

Interrupts

InterruptController (GIC)

OptionalDivide by 8

UART Reference Clock

TXFIFO

RXFIFO

Transmitter

Receiver

ModeSwitch MIO/EMIO

EMIOCTS, RTS, DSR, DCD, RI, DTR

UART TxD

UART RxD

Baud RateGenerator

X18898-032017





コントローラーは受信 (RX) と送信 (TX) の 2 つの部分で構成されます。各パスには 64 バイトの FIFO バッファーがあ

ります。

UART コントローラーは 4 種類のモードに設定できます。そのうち 3 つはアプリケーションまたはハードウェアのテ

ストに使用します。

• 標準的な UART 通信には通常モードを使用します。

• 自動エコーモードでは、 RxD で受信したデータがレシーバーと TxD ピンの両方に送信されます。

• ローカルループバックモードでは、 UART コントローラーで送信したデータがレシーバー側にループバックし

ます。このため、コントローラーは送信データをそのまま受信します。

• リモートループバックモードでは、 RxD 信号が TxD 信号に接続されます。このモードでは、コントローラー

はデータを送信できません。このモードは、リモート /ホストチャネルの UART レシーバーおよびトランスミッ

ターの動作をテストする目的で使用します。

CAN コントローラー

CAN (Controller Area Network) は自動車業界で車載デバイス間の通信に使用される標準バス規格です。 Zynq

UltraScale+ デバイスには 2 つの CAN コントローラー (CAN0、 CAN1) があります。ほかの LPD ペリフェラル同様、

CAN コントローラーは MIO サブシステムまたは EMIO を経由してデバイス境界の外部に接続します。 CAN コント

ローラーは内部クロックをクロックソースにすることも、外部クロックで駆動することもできます。次に、 CAN コ

ントローラーのシステム図を示します。

図 10‐8: CAN コントローラーのシステム図


CANControllers

PL

Clock

TX, RX

TX, RX

ClockingCAN{0,1} REF clock

CAN{0,1] CPU_1x clock

IRQ ID# {60,83}

MIO-EMIORouting

EMIO

MIOPins

DeviceBoundary

TX, RX

ExternalClock

Source

ControlRegisters

APBInterconnect

SlavePort

CAN{0,1] CPU_1x reset

X18897-032017





次に、 CAN コントローラーのブロック図を示します。データの送信用と受信用にそれぞれ専用のストレージバッ

ファーがあります。これら 2 つの FIFO バッファー (送信用の TXFIFO と受信用の RXFIFO) は大 64 個のメッセージ

を格納できます。各コントローラーには、高優先度の送信メッセージを格納する専用バッファー TXHPB もありま

す。このバッファーに格納されたメッセージは TXFIFO から送信される通常のメッセージよりも優先されます。

図 10‐9: CAN コントローラーのブロック図


Object Layer – Data Buffer and Filtering Transfer Layer Protocol Engine

Bit Stream Processor

Bit TimingLogic

TX FIFO

TX HPB

TXPriority Logic

TX Storage

ConfigurationRegisters

RXFIFO

Acceptance Filtering

CAN TX

CAN RX

Data Read

Register R/W

Data Write

APBInterface

X18899-032017

メッセージのフィルタリング

受信側では、ユーザー定義によるアクセプタンスフィルターによってどの受信メッセージを RXFIFO に格納するか

を決定できます。アクセプタンスフィルターにはマスクと ID があり、このフィルターに基づいて受信メッセージを

RXFIFO に書き込むか ACK だけを返してメッセージを破棄するかを決定します。

フィルターモジュールには 4 種類のアクセプタンスフィルターを設定でき、レジスタ設定によってこれらを個別に

有効または無効にできます。フレームを受信すると、有効にした各アクセプタンスフィルターに格納されているマ

スクおよび ID と受信したメッセージのマスクおよび ID が比較されます。いずれかのフィルターがメッセージ内の

対応するデータと一致すると、メッセージは受信されます。





CAN コントローラーのモード

CAN コントローラーは 5 つのモードのいずれかに設定できます。モードの切り替えは、次に示すステートマシンに

従って実行する必要があります。

図 10‐10: CAN コントローラーの動作モードの遷移、モード設定


Configuration

Reset

Normal

SleepLoopback

Snoop

Reset

can.SRR[CEN]=0

Diagnostics

CRL_APB.RST_LPD_IOU2 [CANx_RESET] = 0

Reset:CRL_APB.RST_LPD_IOU2 [CANx_RESET]=1ORcan.SRR[SRST}=1(Self-clearing)

Hardware Forcescan.SRR[CEN]=0

X18900-032117

コンフィギュレーションモード

リセット後のコントローラーのモードです。上のステートマシンにも示したように、コントローラーをいずれかの

診断モードにする場合はコンフィギュレーションモードを経由する必要があります。

通常モード

このモードでは、 CAN コントローラー仕様に基づいて TX ラインでメッセージを送信し、 RX ラインでメッセージを

受信します。

スリープモード

このモードでは、コントローラーのアイドル時に消費電力をわずかに削減できます。スリープモードでデータを受

信するか、データ送信要求を受け取るとコントローラーは通常モードに遷移します。

ループバックモード (診断用)

ループバックモードでは、コントローラーは送信したすべてのデータを自動的に受信します。 CAN ネットワークの

ほかのノードからのメッセージは受信しません。





スヌープモード (診断用)

スヌープモードではコントローラーは何も送信せず、システムのほかのノードから送信されたメッセージを受信し

ます。

割り込み

CAN コントローラーは汎用割り込みコントローラー (GIC) に接続されています。各 CAN コントローラーが使用する

割り込み番号は異なり、 CAN0 は 55、 CAN1 は 56 を使用します。割り込み要因はいくつかありますが、次の 4 つに

分類されます。

• TXFIFO および TXHPB

• RXFIFO

• メッセージ送信およびアービトレーション

• スリープモードおよびバスオフステート

NAND

Zynq UltraScale+ デバイスには ONFI 3.1 仕様に準拠した NAND メモリコントローラーがあります。次の図に示すよ

うに、このコントローラーには ONFI 仕様で定義された SLC (Single-Level Cell) および MLC (Multi-Level Cell) のエ

ラー訂正をサポートした ECC (エラー訂正符号) インターフェイスがあります。

図 10‐11: NAND フラッシュの AXI 機能ブロック図


ARMProcessor

AXIMaster

Interface

AXISlave

Interface

Dual-PortRAM

ControlRegisters

NANDFlash

Interface

ECC

FlashMemory 0

FlashMemory 1

FlashMemory 2

FlashMemory 3

AXI BusNAND Flash Bus

(8-Bit)

X18901-032017





NAND コントローラーには AXI スレーブおよび AXI マスターインターフェイスがあります。 AXI スレーブイン

ターフェイスは制御レジスタとの接続に使用します。 AXI マスターは、このインターフェイスを使用して NAND フ

ラッシュインターフェイスを制御します。 DMA 読み出し /書き込み転送中は、 NAND コントローラーの AXI マス

ターインターフェイスを使用してデュアルポート RAM 経由でメモリとフラッシュの間で読み出しまたは書き込み

を実行します。

SD/SDIO/eMMC

SD コントローラーは SD カード、 MMC、 eMMC デバイスなど各種 SD フォーマットへのアクセスをサポートします。

図 10‐12: SD/SDIO/eMMC コントローラーのブロック図


AXIMaster

AXITarget

PIO/DMAController

Host ControlRegister

Set

BlockBufferFIFO

(Configurable)

SDInterfaceController

TX Clock Delay

(DLY_BUF/DLL)

TX Flip-Flops

RX Flip-Flops

RX Clock Delay

(DLY_BUF/DLL)

SDTUNING

SD RECV_CTRL

SD CMD_CTRL

SD XMIT_CTRL

SD TIME_OUT

SD CARD_DET

SDCLK_GEN

SD Host Control Block

MasterInterface

TargetInterface

SDInterface

X18902-032017

システム全体からは、 AXI スレーブインターフェイス経由で SD カードにアクセスします。 NAND コントローラー

の場合と同様、コントローラーの AXI マスターインターフェイスは DMA 要求に使用します。

SD/SDIO/eMMC DMA

SDIO コントローラーは SD コントローラー仕様に準拠しており、仕様で定義された DMA を実装しています。この

仕様では 2 種類の DMA インターフェイスが定義されています。 1 つは ADMA (Advanced DMA) で、もう 1 つは

SDMA (Single Operation DMA) です。 Zynq UltraScale+ デバイスのコントローラーは両方の DMA モードをサポートし

ています。

SDMA

SDMA はディスクリプターを使用せず、 1 つのアドレスを使用して読み出しまたは書き込みを実行します。 SD カー

ドコントローラーは、転送のアドレス、コピーするブロックの数とサイズをレジスタ経由で受け取ります。 1 ブ

ロックの転送が完了するたびにコントローラーが割り込みをトリガーし、アプリケーションがデータソースレジス

タを更新します。大量のデータ転送の場合、 SDMA では CPU がボトルネックとなり十分な性能が得られません。し

たがって、 SD コントローラーの DMA 転送には ADMA を推奨します。

SDMA を正しく実行するための手順は、 SD ホストコントローラー仕様 1.0 で説明されています。





ADMA

SD 仕様で定義されている ADMA は、システム全体のスキャッターギャザー DMA でサポートされるハイブリッド

ディスクリプターと同様の DMA ディスクリプターを使用します。 ADMA では、 SDMA のような CPU に割り込みを

使用せずコントローラーは複数のトランザクションを処理できます。サポートされる ADMA には 2 つのバージョン

があります。 ADMA1 でサポートされる転送サイズは 4 KB のみで、 ADMA2 では任意の転送サイズがサポートされま

す。どちらのバージョンの ADMA プロトコルも、 SD ホストコントローラー仕様バージョン 3.0 で定義されています。

SD/SDIO/eMMC PIO

SDIO コントローラーには、コントローラーのレジスタ経由で内部転送バッファーに直接アクセスできる PIO

(Programmed I/O) インターフェイスもあります。 PIO モードの要求はコントローラーのスレーブインターフェイスを

経由し、これにより DMA なしで SD 転送を実行できます。

Quad‐SPI

Zynq UltraScale+ デバイスの Quad-SPI コントローラーには、ジェネリック Quad-SPI コントローラーとレガシ

Quad-SPI コントローラーの 2 種類のコントローラーがあります。次に、 Quad-SPI コントローラーのブロック図を示

します。

図 10‐13: Quad‐SPI コントローラーの最上位ブロック図


DMA

AXI MasterWrite I/F

AXI SlaveRead I/F

GenericQuad-SPIController

APB SlaveI/F

LegacyQuad-SPIController

RX Capture and

Delay Line

DIN

DOUT

OEN

DIN

DOUT

OEN

I/OLogic

DOUT

DOUT

OEN

generic_qspi_en

X18903-032017

2 つのコントローラーの切り替えは、レジスタプログラミングによって行います。レガシ Quad-SPI コントローラー

はブートプロセスの第 1 段階で使用する XIP (eXecute In Place) をサポートしているため、ブートプロセスで重要な

役割を果たします。ブートプロセスで XIP を使用する方法は、「メモリ」の章を参照してください。





ジェネリック Quad‐SPI コントローラー

ジェネリック Quad-SPI コントローラーは、データラインの数を 1 本から 4 本に増やした SPI コントローラーです。

シンプルな SPI コントローラーは全二重で通信しますが、このコントローラーはライン数を抑えるために半二重で

通信します。ジェネリック Quad-SPI コントローラーは SPI プロトコルのすべての機能をサポートしています。この

コントローラーは、外部にコマンドベースインターフェイスを提供します。コントローラーに送信するコマンド

は、次の図に示すようにレジスタプログラミングによってジェネリックコマンド FIFO に書き込む必要があります。

図 10‐14: ジェネリック Quad‐SPI コントローラーのブロック図


AXI MasterWrite I/F

RX Capture and

Delay Line

I/OLogic

DIN

OEN

Generic Quad-SPI Controller

DMA(AXI Master)

AXI Slave I/F

APBRegisters

Generic FIFO

20 x 32

RXFIFO

Command Generator

TXFIFO

QuadSPIRX

Quad-SPI TX

DOUT

X18904-032017

SPI コントローラーとは異なり、ジェネリック Quad-SPI コントローラーは DMA 転送と PIO (Programmed I/O) をサ

ポートしているため、 AXI マスターと AXI スレーブの両方を備えています。

DMA

ジェネリック Quad-SPI コントローラーの DMA はディスクリプターを使用しません。すべての DMA 要求について、

データの転送先アドレスとデータサイズをコントローラーの適切なレジスタにプログラムして設定する必要があり

ます。

I/O モード

このモードでは、クライアントがレジスタを使用して RXFIFO および TXFIFO バッファーから直接読み出しを実行

します。

レガシ Quad‐SPI コントローラー

レガシ Quad-SPI コントローラーの動作モードはリニアアドレスモードのみです。このモードでは、コントローラー

に接続されたフラッシュメモリは AXI インターフェイスを持つ読み出し専用メモリとして動作します。レガシモー

ドのコントローラーに対する書き込みコマンドは無視され、 ACK のみが返されます。





フラッシュメモリの構成

ジェネリック Quad-SPI コントローラーを 2 つの SPI フラッシュメモリに接続する方法は、次の図に示すように 2 と

おりあります。

図 10‐15: デュアルパラレルモード (上) とスタックドモード (下)



SPI FlashMemory Upper

SPI FlashMemory Lower

QSPI1_SCLK

QSPI1_SS_B

QSPI1_IO[3:0]

QSPI0_SCLK

QSPI0_SS_B

QSPI0_IO[3:0]


SPI FlashMemory Upper

SPI FlashMemory Lower

QSPI0_SCLK

QSPI0_SS_B

QSPI0_IO[3:0]

QSPI1_SS_B





スタックドモードでは、 2 つのメモリのどちらにアクセスするかをチップセレクト信号で決定します。コントロー

ラーの Stripe コマンドを使用すると、 2 つのメモリにデータを分割するようにコントローラーを設定できます。スト

ライプ機能を使用した場合、偶数位置のバイトが下位データバスに送信され、それ以外のデータバイトは上位デー

タバスに送信されます。

レガシ Quad-SPI コントローラーは、 1 つのデータバスを両方のフラッシュメモリに接続するデュアルパラレル

モードもサポートしています。どちらのメモリを選択するかは、 Data Bus Select フィールドで制御します。

ギガビットイーサネットコントローラー

Zynq UltraScale+ デバイスには 10/100/1000 Mb/s イーサネット MAC を実装したギガビットイーサネットコントロー

ラーが 4 つあります。イーサネットコントローラーは、構成に応じて複数の MII (Media Independent Interface) をサ

ポートします。コントローラーを EMIO 経由で PL に接続した場合は、 GMII (Gigabit Media Independent Interface) を使

用します。コントローラーを MIO 経由で接続した場合は RGMII (Reduced Gigabit Media Independent Interface) を使用

します。コントローラーを PS-GTR 経由で接続した場合は SGMII (Serial Gigabit Media Independent Interface) を使用し

ます。次に、イーサネットコントローラーのブロック図を示します。

図 10‐16: イーサネットコントローラーのブロック図


PCS

DMAController

AXI Master AXIFIFO

Interface

MACTransmitter

MACReceiver

GMII to RGMIIAdapter

RegisterInterface

APB Slave Status and Statistics Registers

Control Registers

GMII to RGMIIAdapter

RGMII

EMIO PLUser

Defined

DeviceBoundary

MDC, MDIO

FrameFiltering

GMII/MII

EMIO

MIOPins

PLSignals

MIOPins

External FIFO interface Ten-bit Interface (SGMII)

X18907-032017

MAC フィルタリング

イーサネットコントローラーは MAC フィルタリングをサポートしています。コントローラーは、受信したパケッ

トとコントローラーの構成を比較して、パケットを DMA または PIO 転送用の FIFO に書き込むかどうかを判定しま

す。

プロミスキャスモード

イーサネットコントローラーをプロミスキャスモードに設定すると、すべての有効なフレームがメモリにコピーさ

れます。





指定アドレス

大 4 つのアドレスを指定してフィルタリングを実行するようにコントローラーを設定できます。指定したいずれ

かのアドレスから受信したフレームは、 FIFO にコピーされます。

ブロードキャストアドレス

ブロードキャストパケットの受信を拒否または許可するようにコントローラーを設定できます。

PAUSE フレーム

PAUSE フレームは IEEE 802.3x 規格で定義されたフロー制御機能の 1 つです。 Zynq UltraScale+ デバイスのイーサ

ネットコントローラーは、 PAUSE フレームのコピーを禁止するように設定できます。

VLAN のサポート

Zynq UltraScale+ MPSoC デバイスのイーサネットコントローラーは、特定の VLAN (Virtual LAN) に宛てたパケット

のみを受信するように設定できます。

WOL (Wake‐on‐LAN)

イーサネットコントローラーの受信ブロックは、次に示すイベントを検出することによって WOL (Wake-on-LAN) を

サポートします。

• マジックパケット

• デバイスの IP アドレスに対する ARP (Address Resolution Protocol) 要求

• 指定アドレス 1 フィルターの一致

• マルチキャストハッシュフィルターの一致

これらのイベントのいずれかが検出されると、ウェークアップ割り込みがトリガーされます。

ギガビットイーサネット DMA

イーサネットコントローラーはスキャッターギャザー DMA をサポートしています。ディスクリプターのフォー

マットは固定されておらず、コントローラーの動作モードおよびデータの受信 (RX) または送信 (TX) にバッファー

を使用するかどうかによって異なります。ディスクリプターのサイズは、コントローラーで 64 ビットアドレス指定

およびタイムスタンプキャプチャ (後述) を有効にしているかどうかによって 64 ～ 196 ビットの間で可変です。

DMA ディスクリプターの詳細な構造は、『Zynq UltraScale+ MPSoC テクニカルリファレンスマニュアル』 (UG1085) [参照 7] で定義しています。この中には次の重要なフィールドが含まれます。

• 送信データのメモリアドレス

• チェックサムオフロードのステータス

• VLAN タグおよび優先度

注記: パラメーターの詳細は、『Zynq UltraScale+ MPSoC テクニカルリファレンスマニュアル』 (UG1085) [参照 7] を参

照してください。





Zynq UltraScale+ デバイスのイーサネットコントローラーは、 AXI DMA 転送を容易にするために送信パスと受信パ

スの両方にパケットバッファーがあります。次に、パケットバッファーを含む DMA コントローラーの構造を示し

ます。パケットバッファーを使用するとパケット全体をメモリに格納してチェックできるため、チェックサムオフ

ロードも完全にサポートされます。衝突が発生した場合、コントローラーはパケットバッファーから自動的にパ

ケットを再送します。

図 10‐17: DMA パケットバッファー


Register Interface

APBInterconnect

Control Registers

MDIOMIO or EMIO

Status and Statistic

Registers

TX Packet Buffer

RX Packet Buffer

TX Packet Buffer

DPSRAM

TXDMA

RXDMA

AXIDMA

MACTransmitter

RX Packet Buffer

DPSRAM

MACReceive

FrameFiltering

GigabitEthernetController

AXIInterconnect

TX GMIIMIO or EMIO

RX GMIIMIO or EMIO

X18908-032017

チェックサムオフロード

Zynq UltraScale+ デバイスのイーサネットコントローラーは、 TX と RX のどちらの方向もチェックサムオフロード

をサポートしています。

チェックサムオフロードを有効にしてパケットを受信すると、 IPv4 パケット、 TCP および UDP パケットのチェック

サムヘッダーが検査されます。コントローラーは、チェックサム検査の結果を受信処理に使用するディスクリプ

ターに記録します。チェックサムに誤りがある場合、コントローラーはパケットを破棄します。

パケット送信時には、パケットバッファーに格納される各パケットに対し、送信フレームのプロトコルを自動で検

出してチェックサムを計算します。チェックサムは UDP、 TCP および IPv4 パケットに対して計算されます。





USB

Zynq UltraScale+ デバイスの USB 3.0 コントローラーは、 2 つの独立したデュアルロールデバイス (DRD) コントロー

ラーで構成されます。このコントローラーは AXI スレーブインターフェイスを経由して xHCI 機能を外部に提供し

ます。このコントローラーには DMA インターフェイスもあり、 AXI マスターインターフェイスを使用してデータ

を転送します。

次に、 Zynq UltraScale+ デバイスの USB コントローラーの概略ブロック図を示します。各 USB DRD コントローラー

のモードは、AXI バス経由で USB コントローラーのコンフィギュレーションステータスレジスタ (CSR) にアクセス

して制御します。

図 10‐18: Zynq UltraScale+ デバイスの USB 3.0 のブロック図


USB 3.0 Dual Role Device Controller 1

AXI Bus Interface,

Buffer, and Register

Management Module

CSR Regs

USB 3 Protocol Layer

USB 3 LinkLayer

PIPE3Interface


USB 2 LinkLayer

ULPIInterface

RAM1RAM0 RAM2

S CSR Access

M DMA

USB 3.0 Dual Role Device Controller 2

AXI Bus Interface,

Buffer, and Register

Management Module

CSR Regs


USB 3 LinkLayer

PIPE3Interface


USB 2 LinkLayer

ULPIInterface

RAM1RAM0 RAM2

S CSR Access

M DMA

ToAXI

Switch

ToAXI

Switch

Zynq UltraScale+ MPSoC USB 3.0 block

X18909-032017





次の表に示すように、サポートする USB バージョン、および USB コントローラーを MIO と PS-GTR のどちらを経

由して接続するかによって、標準 USB プロトコルのサポートされる速度が異なります。

表 10‐1: USB 3.0 コントローラーの構成

コンフィギュレーション PHY インターフェイススーパースピードハイスピードフルスピードロースピード

USB 2.0 ホスト

USB 2.0 デバイス

USB 2.0 OTG

USB 3.0 ホスト (xHCI)

USB 3.0 デバイス

USB 3.0 OTG

PCI Express

Zynq UltraScale+ デバイスには、『PCI Express Base Specification Revision 2.1』を実装した統合ブロックがあります。

Zynq UltraScale+ デバイスは PCIe エンドポイントとしても PCIe ルートポートとしても動作します。PCIe ルートポー

トとはほかの PCIe デバイスをホスティングしてこれらのデバイスと通信できるデバイスで、 PCIe エンドポイントと

はルートポートに対するクライアントとして動作できるデバイスをいいます。次に、 Zynq UltraScale+ デバイスの

PCIe コントローラーのブロック図を示します。

図 10‐19: PCIe コントローラーのブロック図


AXI-PCIe Bridge(DMA, RP/EP)

Integrated Block for PCIe

Egress Address Translation / BAR

MSI/INTx/Msg

Ingress Address Translation/BAR

Tran

sact

ion

Laye

r

Dat

a Li

nk L

ayer

Phy

sica

l Lay

er

Configuration/Status Register

AXI3 64-bit

Clock/Reset

Interrupts

AXI3 64-bit

AXI4 Streaming

AXI4 Streaming

Configuration Status

APB

PCIe Configuration

ECAM Write FIFO

DMA (4 channels)

Blk

Reg

ECAM Read Sidebands

(interrupts etc.)

PIPE

X18910-032017

ULPI サポートサポートサポート



PIPE3 サポートサポートサポートサポート

PIPE3 サポートサポートサポート

PIPE3 サポートサポートサポートサポート

(ホストのみ)





PCIe は実質的にバスであり、 Zynq UltraScale+ デバイスの内部インターコネクトは AXI ベースであるため、 PCIe コ

ントローラーでは内部 AXI インターコネクトと PCIe エンドポイントを管理するブロックを相互に接続する

AXI-PCIe ブリッジが主要なコンポーネントの 1 つに挙げられます。これにより、内部コンポーネントは AXI トラン

ザクションを使用して PCIe に接続したデバイスと通信できるようになります。

パワーマネージメント

『PCI Express Base Specification Revision 2.1』では 4 つのパワーマネージメントステートが定義されていますが、Zynq

UltraScale+ デバイスの PCIe コントローラーがサポートしているのは L0 と L1 の 2 つのみです。また、このコント

ローラーは ASPM (Active State Power Manager) もサポートしていません。 L0 と L1 の切り替えは、 PPM (Programmed

Power Manager) を使用して手動で実行できます。

セキュリティ

PCIe コントローラーの AXI マスターは、「リソースの分離と分割」の章で説明した TrustZone でセキュア/非セキュア

に設定したトランザクションを生成できます。セキュア/非セキュアの設定は、コントローラーのプログラミングイ

ンターフェイスでレジスタプログラミングによってアドレス変換および DMA チャネルごとに設定できます。

DMA

Zynq UltraScale+ デバイスの PCIe コントローラーはスキャッターギャザー形式の DMA をサポートしており、 4 チャ

ネル DMA エンジンを内蔵しています。各チャネルは受信または送信にプログラムできます。次の図に示すように、

PCIe DMA は 3 種類の DMA ディスクリプターを使用します。

図 10‐20: DMA SGL‐Q のフォーマット


Source Address [31:0]

Source Address [63:32]

Byte Count [23:0]Flags [7:0]

UserHandle[15:0]UserID[15:0]

SRC SGL Flags-[0]: Location (AXI or PCIe)[1]: EOP[2]: Interrupt[7:4]: Attributes

SRC-SGL


CM

PLT

Error[3:1]Completed Byte

Count [26:0]

Upper Status Non-Zero

Error-[1]: Source Error[2]: Destination Error[3]: Internal DMA Error

STAS/STAD-SGL

Destination Address [31:0]

Destination Address [63:32]

Byte Count [23:0]Flags [7:0]


DST SGL Flags-[0]: Location (AXI or PCIe)[1]: Enable one packet per element[7:4]: Attributes

DST-SGL

X18911-032017

SRC-SGL はソースデータのスキャッターギャザーリストで、 DST-SGL はデスティネーションデータのスキャッ

ターギャザーリストです。 DMA エンジンは、ソースおよびデスティネーションディスクリプターのステータスを

格納するディスクリプターリストも使用します。フォーマットはソースとデスティネーションで共通で、上の図で

は STAS/STAD-SGL として定義しています。 DMA エンジンは、ソースデータの読み出し (SRC-SGL ディスクリプ

ターの場合) またはデスティネーションへのデータ書き込み (DST-SGL ディスクリプターの場合) が完了するかエ

ラーが発生するたびにこれらのディスクリプターを更新します。

Zynq UltraScale+ デバイスはエンドポイントとして動作できるため、 DMA エンジンの設定で DMA 機能の役割をホス

ト (すなわちルートポート ) と共有させることができます。これをデュアル CPU 制御モードと呼びます。この場合、

ホスト CPU と AXI CPU の両方が DMA を制御します。 DMA 転送をホストのみで制御するシングル CPU 制御モード

に設定することもできます。





SATA

シリアル ATA (SATA) プロトコルは、初期のパーソナルコンピューターで使用されていたパラレル ATA プロトコル

(IDE) を置き換える目的で設計されました。 Zynq UltraScale+ デバイスには SATA Gen1 ～ Gen3 をサポートした SATA

コントローラーが 2 つあります。 SATA コントローラーの主な機能は次のとおりです。

• AHCI v1.3 に準拠

• 1.5、 3.0、および 6.0Gb/s のデータレートをサポート

• DMA 内蔵 64 ビット AXI マスターポート

注記: 機能の詳細は、『Zynq UltraScale+ MPSoC テクニカルリファレンスマニュアル』 (UG1085) [参照 7] を参照してく

ださい。

次に、 Zynq UltraScale+ MPSoC デバイスの SATA コントローラーのブロック図を示します。この図の「Command

Layer (コマンド層)」、「Transport Layer ( トランスポート層)」、「Link Layer ( リンク層)」、「PHY Controller Layer (PHY 制

御層)」は、 SATA ホストコントローラーインターフェイスの仕様に記載のレイヤーに対応します。

図 10‐21: SATA のシステムブロック図


Zynq UltraScale+MPSoC SATA Block

SATA Host Controller

DMA

AXI Engine

SToAXI

Switch

RAM

Port 0

Command Layer

Transport Layer Link Layer

PHY Control Layer S

erD

es

Inte

rface

AHCIRegs

M

RAM

DMA

Port 1

Command Layer

Transport Layer Link Layer

PHY Control Layer S

erD

es

Inte

rface

To PS-GTR MUX

To PS-GTR MUX

X18912-032017





SATA のセキュリティ

SATA コントローラーは、マスターおよびスレーブポートの両方で TrustZone セキュアアクセスをサポートしていま

す。詳細は、『Zynq UltraScale+ MPSoC テクニカルリファレンスマニュアル』 (UG1085) [参照 7] のこのセクションを

参照してください。

DMA

Zynq UltraScale+ デバイスの SATA コントローラーに実装されている DMA 機能は、 Serial ATA Advanced Host

Controller Interface (AHCI) で定義されている DMA プロトコルに基づいています。

DisplayPort

Zynq UltraScale+ デバイスの DisplayPort 機能については、第 9 章「マルチメディア」で説明しています。



http://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xSATAHostTrustZoneSupport


付録 A

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

ザイリンクスリソース

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

ください。

ソリューションセンター

デバイス、ツール、 IP のサポートについては、ザイリンクスソリューションセンターを参照してください。デザイ

ンアシスタント、デザインアドバイザリ、トラブルシューティングのヒントなどが含まれます。

Documentation Navigator およびデザインハブ

Xilinx® Documentation Navigator では、ザイリンクスの資料、ビデオ、サポートリソースにアクセスでき、特定の情

報を取得するためにフィルター機能や検索機能を利用できます。 Xilinx Documentation Navigator (DocNav) を開くに

は、次のいずれかを実行します。

• Vivado® IDE で [Help] → [Documentation and Tutorials] をクリックします。

• Windows で [スタート ] → [すべてのプログラム] → [Xilinx Design Tools] → [DocNav] をクリックします。

• Linux のコンドプロンプトに「docnav」と入力します。

ザイリンクスのデザインハブでは、資料やビデオへのリンクがデザインタスクおよびトピックごとにまとめられて

おり、これらを参照することで重要なコンセプトに関する知識を得たり、よくある質問 (FAQ) を参考に問題を解決

できます。デザインハブにアクセスするには、次のいずれかを実行します。

• Xilinx Documentation Navigator で [Design Hubs View] タブをクリックします。

• ザイリンクスウェブサイトのデザインハブページを参照します。

注記: Documentation Navigator の詳細は、ザイリンクスウェブサイトの Documentation Navigator ページを参照してく

ださい。



https://japan.xilinx.com/support/

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

https//japan.xilinx.com/cgi-bin/docs/ndoc?;t=design+hubs

https://japan.xilinx.com/cgi-bin/docs/rdoc?t=docnav


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

参考資料

注記: 日本語版のバージョンは、英語版より古い場合があります。

1. 『Xilinx Power Estimator ユーザーガイド』 (UG440: 英語版、日本語版)

2. 『UltraScale アーキテクチャコンフィギュレーションユーザーガイド』 (UG570: 英語版、日本語版)

3. 『Vivado Design Suite チュートリアル: パーシャルリコンフィギュレーション』 (UG947)

4. 『UltraFast 設計手法ガイド (Vivado Design Suite 用)』 (UG949: 英語版、日本語版)

5. 『Zynq UltraScale+ MPSoC ソフトウェア開発者向けガイド』 (UG1137: 英語版、日本語版)

6. 『Embedded Energy Management Interface (EEMI) API ユーザーガイド』 (UG1200)

7. 『Zynq UltraScale+ MPSoC テクニカルリファレンスマニュアル』 (UG1085: 英語版、日本語版)

8. 『Zynq デバイス向け OpenAMP フレームワーク : スタートアップガイド』 (UG1186)

9. 『SDSoC 環境チュートリアル: 入門』 (UG1028: 英語版、日本語版)

10. 『Zynq UltraScale+ MPSoC で圧倒的な低消費電力と柔軟性を実現』 (WP470: 英語版、日本語版)

11. 『ザイリンクスソフトウェア開発キット (SDK) ユーザーガイド : システムパフォーマンス解析』 (UG1145: 英語版、日本語版)

12. 『Xilinx All Programmable Functional Safety Design Flow Solution Product Brief』 (PB015)

13. 『Xilinx Reduces Risk and Increases Efficiency for IEC61508 and ISO26262 Certified Safety Applications White Paper』 (WP461)

14. ザイリンクスソフトウェア開発キット (XSDK) のウェブページ: https://japan.xilinx.com/products/design-tools/embedded-software/sdk.html

15. ザイリンクス Vivado Design Suite のウェブページ: https://japan.xilinx.com/products/design-tools/vivado.html

16. ザイリンクスアイソレーションデザインフローのウェブページ: https://japan.xilinx.com/applications/isolation-design-flow.html

17. パーシャルリコンフィギュレーションのウェブページ: https://japan.xilinx.com/products/design-tools/vivado/implementation/partial-reconfiguration.html

18. All Programmable ヘテロジニアス MPSoC のウェブページ: https://japan.xilinx.com/products/silicon-devices/soc/zynq-ultrascale-mpsoc.html#productTable

19. Wiki ページ「Zynq UltraScale+ MPSoC グラフィックス : ARM Mali グラフィックスデバッガー (MGD) を使用した GPU アプリケーションのデバッグ」 : http://www.wiki.xilinx.com/Zynq+UltraScale%EF%BC%8BMPSoC+Graphics-+GPU+application+debugging+using+ARM+Mali+Graphics+Debugger+tool



https://www.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug440-xilinx-power-estimator.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug440-xilinx-power-estimator.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug570-ultrascale-configuration.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug570-ultrascale-configuration.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug947-vivado-partial-reconfiguration-tutorial.pdf

https://www.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug949-vivado-design-methodology.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug949-vivado-design-methodology.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1137-zynq-ultrascale-mpsoc-swdev.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug1137-zynq-ultrascale-mpsoc-swdev.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1200-eemi-api.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug1085-zynq-ultrascale-trm.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug1186-zynq-openamp-gsg.pdf

https://www.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug1028-sdsoc-intro-tutorial.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug1028-sdsoc-intro-tutorial.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=white_papers;d=wp470-ultrascale-plus-power-flexibility.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=white_papers;d=j_wp470-ultrascale-plus-power-flexibility.pdf

https://www.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug1145-sdk-system-performance.pdf

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

https://japan.xilinx.com/publications/prod_mktg/safety-guidelines.pdf

https://japan.xilinx.com/support/documentation/white_papers/wp461-functional-safety.pdf

https://japan.xilinx.com/products/design-tools/embedded-software/sdk.html

https://japan.xilinx.com/products/design-tools/vivado.html

https://japan.xilinx.com/applications/isolation-design-flow.html.

https://japan.xilinx.com/products/design-tools/vivado/implementation/partial-reconfiguration.html

https://japan.xilinx.com/products/silicon-devices/soc/zynq-ultrascale-mpsoc.html#productTable

http://www.wiki.xilinx.com/Zynq+UltraScale%EF%BC%8BMPSoC+Graphics-+GPU+application+debugging+using+ARM+Mali+Graphics+Debugger+tool

http://www.wiki.xilinx.com/Zynq+UltraScale%EF%BC%8BMPSoC+Graphics-+GPU+application+debugging+using+ARM+Mali+Graphics+Debugger+tool


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

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

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

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

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

貴社による本情報の使用を含む) に関係し、起因し、関連する、いかなる種類・性質の損失または損害についても、責任を負わな

い (契約上、不法行為上 (過失の場合を含む)、その他のいかなる責任の法理によるかを問わない) ものとし、当該損失または損害に

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

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

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

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

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

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

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

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

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

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

スの販売条件を参照してください。

自動車用のアプリケーションの免責条項

オートモーティブ製品 (製品番号に「XA」が含まれる ) は、 ISO 26262 自動車用機能安全規格に従った安全コンセプトまたは余剰性

の機能 ( 「セーフティ設計」 ) がない限り、エアバッグの展開における使用または車両の制御に影響するアプリケーション ( 「セー

フティアプリケーション」 ) における使用は保証されていません。顧客は、製品を組み込むすべてのシステムについて、その使用

前または提供前に安全を目的として十分なテストを行うものとします。セーフティ設計なしにセーフティアプリケーションで製品

を使用するリスクはすべて顧客が負い、製品の責任の制限を規定する適用法令および規則にのみ従うものとします。

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

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

者に帰属します。

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

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

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

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



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

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

mailto:[email protected]


Zynq UltraScale+ MPSoC エンベデッド設計手法ガ...

Documents

Transcript of Zynq UltraScale+ MPSoC エンベデッド設計手法ガ...