zynq ultrascale+ mpsoc - xilinx

Zynq UltraScale+ MPSoC 嵌入式设计方法指南

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

条款中英文版本如有歧义，概以英文文本为准。

Zynq UltraScale+ MPSoC 嵌入式设计方法指南 2UG1228 (v1.0) 2017 年 3 月 31 日 china.xilinx.com

修订历史下表列出了本文档的修订历史。

日期版本修订

2017 年 3 月 31 日 1.0 初始版本。

Send Feedback

https://china.xilinx.com

https://china.xilinx.com/about/feedback.html?docType=User_Guides&docId=UG1228&Title=Zynq%20UltraScale+%20MPSoC%20%26%2323884%3B%26%2320837%3B%26%2324335%3B%26%2335774%3B%26%2335745%3B%26%2326041%3B%26%2327861%3B%26%2325351%3B%26%2321335%3B&releaseVersion=1.0&docPage=2

目录修订历史. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

第 1 章 : 引言原理图 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6矢量评估法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8访问技术文档和培训资料. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

第 2 章 : 处理器系统定义您的处理需求 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11处理器系统方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11异构计算概念 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14应用处理单元 (APU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16APU 虚拟化支持 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18实时处理单元 (RPU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22互联 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23中断 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29使用 PL 加速工作负载 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34通用计算加速 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

第 3 章 : 系统软件考虑因素定义您的系统软件需求 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38系统软件方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39启动进程软件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44系统软件堆栈 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48OpenAMP 框架 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Xen Hypervisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55PMU 软件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58软件开发工具 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60开发人员流程 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

第 4 章 : 电源考虑因素定义您的电源需求 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66电源优化方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67四大功耗域 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70电源岛与电源门控 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76平台管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76功耗管理软件架构 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Xilinx Power Estimator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

第 5 章 : 可编程逻辑定义您的 PL 需求. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Zynq UltraScale+ MPSoC 嵌入式设计方法指南 3UG1228 (v1.0) 2017 年 3 月 31 日 china.xilinx.com Send Feedback



PL 方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81逻辑 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85集成 IP 支持 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89配置和部分重配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90功耗降低功能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

第 6 章 : 存储器存储器简介 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92定义您的存储器需求 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92存储器方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92内置存储器块 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94PS DDR 存储器和控制器 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96全局系统内存映射 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97PS DMA 控制器 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98使用 PL 接口外部存储器 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

第 7 章 : 资源隔离以及分区定义您的资源隔离以及分区需求 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103资源隔离以及分区方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Arm TrustZone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108系统内存管理单元 (SMMU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111赛灵思内存保护单元 (XMPU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113赛灵思外设保护单元 (XPPU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Xen 虚拟机管理器 (Hypervisor) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

第 8 章 : 安全性定义您的安全性需求 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119安全性方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120安全性特性简介 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122配置安全性和安全启动 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123器件和数据安全性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126防范 DPA 攻击 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129CSU 硬件加速器. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130功能安全 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

第 9 章 : 多媒体定义您的多媒体性需求 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131多媒体方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132DisplayPort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133GPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139VCU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

第 10 章 : 外设定义您的外设需求 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152外设方法学 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153GPIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156I2C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158SPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159UART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160CAN 控制器 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161




NAND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164SD/SDIO/eMMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165QSPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166千兆以太网控制器 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169USB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171PCI Express . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173SATA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175DisplayPort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

附录 A: 附加资源与法律提示赛灵思资源 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177解决方案中心 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177Xilinx Documentation Navigator 与设计中心. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177参考资料 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177请阅读：重要法律提示 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179




第 1 章

引言Zynq® UltraScale+™ MPSoC 平台可为设计人员提供首款真正的 All-Programmable 异构多处理片上系统 (SoC) 器件。汽车产业、大型数据库部署乃至太空探索等应用中的智能系统日益复杂，不断推动每一代新的 SoC 突破性能极限。为满足行业对于电源控制、实时应用、图形密集功能以及功耗处理的更高要求，亟需一款具备大灵活性的平台。 Zynq UltraScale+ MPSoC 平台可为现代系统设计人员提供所需的先进特性。

Zynq UltraScale+ MPSoC 基于台积电 (TSMC) 推出的新一代 16 nm FinFET 工艺节点，包含一个可扩展的 32 位或 64 位多处理器 CPU、用于实时图形和视频处理的专用硬化引擎、先进的高速外设以及可编程逻辑。该平台可通过双核或四核 APU 器件实现大的可扩展性，将图形和视频流水线等关键应用卸载 (offloading) 至专用处理块处理，并通过有效的电源域和门控电源孤岛来开启和关闭块。 Zynq UltraScale+ MPSoC 可提供多种互连选项、数字信号处理 (DSP) 块以及可编程逻辑选择，能够灵活满足不同用户应用的要求。

本指南可作为工具，有助于用户在使用 UltraScale+ MPSoC 特性集进行设计时做出决策。在为您的产品确定适合的特性功能时，请参考有关建议，并认真权衡。本指南根据矢量评估法（如 “矢量评估法”中所述）编撰而成，并提供了系统设计要求与 Zynq UltraScale+ MPSoC 基本特性对比的初步示意图。矢量评估法不能确保大限度地利用平台功能，只是通过图形表示说明了用户在平台上构建产品时所能做出的权衡和解决方案。这会降低某些平台特性在整体解决方案中的优先级。使用矢量评估法，设计人员能够精准调动硬件设计人员、架构师、软件工程师等团队成员，使其根据相应的工作职责关注具体的方法领域。

原理图在两个隔离的电源域中， Zynq UltraScale+ MPSoC 器件包含两个主要的底层处理器系统 (PS) 以及可编程逻辑 (PL) 块。

PS 作为独立的 MPSoC 器件，无需 PL 供电即可启动并支持第 7 页的图 1-1 中所示的全部特性。本手册介绍了每个单独的嵌入式块。

Zynq UltraScale+ MPSoC 器件有四个不同的电源域：

• 低功耗域 (LPD)

• 全功耗域 (FPD)

• PL 功耗域 (PLPD)

• 电池电源域 (BPD)




第 1 章：引言

每个电源域都可以单独隔离。低功耗域 (LPD) 中的平台管理单元（PMU）可以帮助管理各功耗域的隔离功能。由于每个电源域可以单独隔离，因此能实现功能隔离（这是安全应用的一个重要方面）。此外，隔离也能在相应电源域的某个电源意外断电时自动打开。 X-Ref Target - Figure 1-1

图 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

GICLL

LP

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 器件采用，的矢量法：

在这个图中，从中心点放射出的每条线都代表 Zynq UltraScale+ MPSoC 平台的一个功能域。中心点代表对功能域的零要求、需求，每条线的端点代表对该功能域的更高要求、需求和复杂性。以该图作为起点，系统架构师可与 FAE 或销售工程师合作，绘制其设计中应用的特定功能域的程度，并连接各个绘图点，从而初步了解他们将要解决的问题。

我们来看看下面的这个高级驾驶辅助系统 (ADAS) 示例：

X-Ref Target - Figure 1-2

图 1-2：矢量评估法图

Power

Processing System

Programmable Logic

Real-Time Processing

Security

Multimedia

Memory

Peripherals

System Software Configurations

Resource Isolationand Partitioning

X18044-032917




第 1 章：引言

在本例中，我们看到系统软件配置、实时处理、可编程逻辑以及处理器系统都处于大值。这就意味着我们要重点查看本指南中介绍 MPSoC 的具体章节，设计人员需要关注有关内容，考虑上述四个矢量的优势与劣势以及局限性因素。由于功耗、安全性、多媒体、外设和资源隔离以及分区等方面的需求不相上下，您可以适当地缩减这些领域的投入力度。这就让您能够集中更多精力解决对产品更重要的矢量。因此，通过使用该指南，您可以根据您的需求级别做出一系列更好的设计选择，对于 UltraScale+ MPSoC 设计中的特定部分所分配的精力与资源进行优化。

注释：示意图作为灵活的工具，能分析指南中不同章节内容之间的关联性，但这并不代表我们可以跳过任何矢量。在您做出后的设计决策之前，请确保阅读完整的方法指南。

访问技术文档和培训资料在适当的时间获得正确的信息，对于及时设计收敛并确保整体设计成功而言十分重要。参考手册、用户指南、教程和视频能够帮助您尽快掌握赛灵思工具。本节为您列出了部分技术文档和培训资料的来源。


图 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




第 1 章：引言

使用 Documentation NavigatorXilinx Documentation Navigator 是赛灵思工具的一部分。它提供了用于访问和管理全套赛灵思软/硬件文档、培训资料和辅助材料的环境。借助 Documentation Navigator，您可查看赛灵思新及过去的技术文档。通过版本、文档类型或设计任务来过滤技术文档显示内容。结合搜索功能可帮助您快速找到正确的信息。

Documentation Navigator 会扫描赛灵思网站，以检测并提供技术文档更新。 “Update Catalog”功能可提醒您有可用的更新内容，并提供有关文档的具体信息。赛灵思建议您在出现提醒时要更新目录，以使其保持新。您可以为指定的文档建立本地技术文档目录并对其进行管理。

Documentation Navigator 中有一个“Design Hub View”标签。 “Design Hub”是指与设计活动（Zynq UltraScale+ MPSoC 设计简介、 PetaLinux 工具，赛灵思软件开发套件 (SDK)）相关的文档集。文档和视频被纳入每个设计中心内，以简化相关领域的学习过程。每个设计中心均包含“Embedded Processor Design” （嵌入式处理器设计）部分，以及“Support Resources” （辅助性资料）部分。 “Embedded Processor Design”部分（所示图 1-4）可为新用户提供清晰的入门指导。


图 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. 您设计中的哪些组件是节能应用？

处理器系统方法鉴于 Zynq UltraScale+ MPSoC 器件的灵活性，在将您的设计映射到任何给定器件之前，必须谨慎、细致地分析其处理功能。因此，下图提供了本指南引言部分中呈现的完整系统框图的简化视图，重点展示 Zynq UltraScale+ MPSoC 器件的主要处理块和通过互联建立的块间互联，以及能够处理用绿色高亮显示的某种形式定制处理的块。

注释：图 2-1 并非 Zynq UltraScale+ MPSoC 器件内部块的精确表达。相反，它主要是一张概念图，用于解释当前概念。




第 2 章：处理器系统

在下面的几节中，我们将逐一详细介绍各种主要块，以及它们的相关中断功能、互联和 Zynq UltraScale+ MPSoC 器件的主要处理器间通信机制。互联由多个不同类型的块组成，每种块都值得单独讨论。就当前话题而言，我们将重点关注系统每部分的高级功能。

审核您设计中任何给定类型的处理需求，如前一节中问题所提，您可控制的特性包括：

• 处理位置

• 处理位置间的互联

• 与外部环境的交互

° 存储器

° 中断

° 外设 I/O

在处理位置选择方面，对特定类型的工作负载，通常有典型的候选块可选择：


图 2-1：全局处理器功能块

表 2-1：按处理块划分的工作负载选择方案

块优化目的适用于：

APU • 支持 Linux 等高级操作系统

• 基于虚拟机管理器的计算

• 对称多处理和受监督非对称多处理

• HMI/UX• 业务逻辑

• 网络/云交互

RPU • 确定性运算

• 低时延存储器访问

• 确定性响应时间软件

• 安全关键型软件

• 符合标准的软件堆栈（例如：无线电）

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





以上皆为通用指南，您的设计可能需要不同方法。另一种助您决定特定处理负载位置的途径是遵循该决策树：

对于上图中针对您的系统的每个组件的问题，相应答案皆较为明了。如果您有特定时限内需要持续处理的持续数据流或请求，通常可编程逻辑 (PL) 是布置您系统中涉及上述处理工作的大部分组件的绝佳位置。如果某个工作负载不符合上面描述的情况，但仍需要对外部事件或任务关键性事件做出确定性响应（如实时响应），那么 RPU 可能是非常理想的备选对象。如果仍不符合上述情况，那就可能是某种通用计算问题。如果属于图形问题，则应该由图形处理器单元 (GPU) 负责处理。如果是其他问题，则由 APU 负责处理。

即便您决定在首次运行就由 RPU 或 APU 处理特定的软件部分，但将它们移植到 PL 运行或将带来进一步优化的机会。比如，如果待实现功能可描述为一个固定的数学公式清单，如 FFT。和/或一套已知状态或状态机（尤其在它们能够并行运行的情况下），将该功能嵌入在 PL 中或更加理想。

对于衡量将特定功能移植到 PL 中是否有利，方法之一显然是手工测试和原型制作。然而赛灵思为您提供了一种为 PL 发现和处理优化备选对象更加有效的途径。实际上 SDSoC 和将赛灵思 SDK 开发工具能剖析您的应用代码。而且在使用 SDSoC 的情况下，您一键单击就能够将代码段卸载到 PL 中，以便开展性能测试。 SDSoC 可将所需逻辑自动编译至 PL 中，分配必要的数据移动器和软件驱动，让其他受限运行于APU 或 RPU 的软件部分的能够通过透明方式使用被加速的软件部分。因此 SDSoC 通过极大地简化所涉及的各个步骤，帮助优化软件加速进程。因此与手动卸载相比，使用 SDSoC 是实现易用性和手工性能调试间的取舍。

PL • 加速应用 • 加速/并行化

• 硬件辅助特效、转换、滤波、处理、编码/解码……

GPU • Linux 下的 2D 和 3D 图形加速 • 显示

• 多媒体


图 2-2：处理位置决策树

表 2-1：按处理块划分的工作负载选择方案

块优化目的适用于：

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





另一个需要关注的地方是处理块的高时钟速度：

• APU – 高 1.5 GHz

• RPU – 高 600 MHz

• GPU – 高 667 MHz

注释：应注意这些是高速度。虽然每个块能够以上述高速度运行，但长时间以这样的高速度运行并不太可能，对您的设计也没有意义。

由于搭载 Arm® Cortex®-A53 处理器，APU 是 Zynq UltraScale+ MPSoC 器件上的高速通用计算资源。对于需要高计算能力的工作负载，它貌似是佳选择，而且您的 Zynq UltraScale+ MPSoC 器件多可搭载四个 Cortex-A53 处理器。但是大频率并不一定意味着对功能适合。例如 APU 的 Cortex-A53 处理器就不如 RPU 的 Arm® Cortex®-R5 处理器适合实时工作负载。此外还存在诸多其他因素，导致在 APU 和 RPU 间做出选择时，需要在性能和确定性间做利弊取舍。

找出容纳给定功能的佳候选块后，您仍然需要确定通过互联在块间传递数据的佳途径，以及每个处理位置如何与系统内的各种处理资源交互，以及如何与外部环境中的接口和资源交互。互联和中断处理的详细讨论，见本章后续内容。关于外设 I/O 的各个相关方面，请参阅第 10 章"外设"。关于内存的说明，请参阅第 6 章"存储器"。关于包括内建加速器在内的 PL 各项功能说明，请参阅第 5 章"可编程逻辑"。

请注意，虽然当前指导方针可提供给定建议的处理块，但有可能在审核完您设计的特定部分有关的完整内容后，会发现某种更合适的替代方案，有助于满足您特定的产品需求。以上文描述的决策树为例，建议对您的实时软件使用 RPU。您的设计则可能要求在 APU 上运行实时操作系统 (RTOS)，以裸机方式运行 Cortex-R5 处理器。另一个例子是网络通信。上述建议认为网络通信适合发挥 APU 的性能。但是 PL 集成有 100G 以太网和 PCIe 块，两者相结合，有助于高效完成通常由 APU 运行的网络相关任务。赛灵思白皮书《发挥 Zynq UltraScale+ MPSoC 前所未有的低功耗与灵活性优势》 (WP470) [参照 10] 旨在介绍 Zynq UltraScale+ MPSoC 的灵活性，并简述适用于数据中心应用的示例用例。该白皮书还提供了其他两个示例用例，具体为中央“高级驾驶辅助系统 (ADAS)”模块和软件定义无线电 (SDR)。这两个示例有助于您更加妥善理解如何划分您的设计处理。

在确定执行您的设计的处理工作的给定部分的位置时，另一个重点在于功耗管理。 Zynq UltraScale+ MPSoC 器件的架构便于对功耗管理实施高精度控制。第 12 页的图 2-1 所示的电源域是第 4 章"电源考虑因素"中详细介绍的功耗管理的组成部分。一旦您决定在特定的 Zynq UltraScale+ MPSoC 器件块上运行给定工作负载，请注意这一选择与您的功耗管理需求有所关联。例如，如果某个关键算法在 APU 上运行，同时您希望在特定时间段里降低 APU 耗电水平，您或需将这一算法移植到 PL 或 RPU。如前文的解释所述， APU 可能是系统中功能强大的块，但它同时也是耗电大的块。

异构计算概念要理解 Zynq UltraScale+ MPSoC 器件的处理能力和周边功能，需要掌握一般在异构计算领域之外不常使用的几个关键概念。因此这里将对您将在本指南中以及在 Zynq UltraScale+ MPSoC 器件文档其余部分遇到的一些术语做简要介绍。

Zynq UltraScale+ MPSoC 器件包含两个主要的多处理组件层（即处理器彼此并行工作）。第一层是主要处理块：

• APU

• RPU

• PL

• GPU

第二层是这些块里的处理器单元：

• APU 内的两个或四个 Cortex-A53 核

• RPU 内的双 Cortex-R5 处理器核

• PL 中的 PL 优化应用和/或 MicroBlaze™ 处理器实例

• GPU 内的图形处理流水线





Zynq UltraScale+ MPSoC 器件内主要组件间的关系通常假设为“非对称”。也就是说，APU、RPU、PL 和 GPU 中的每一个都有不同功能和限制，它们不必共享公用 OS，工作负载也不能在这些块之间无缝迁移。因此，如果设计人员要把这些组件中的一个用于特定工作负载，必须针对该组件特别定制工作负载。这也就是所谓的非对称多核处理器 (AMP)。

在 APU 内部， Cortex-A53 处理器间的关系以四种不同形式存在。

• 如果所有的 Cortex-A53 处理器核都用于运行单个公共操作系统，例如 Linux，就构成另一种建议的配置。此时处理器间彼此形成“对称”关系。在这种情况下，公共操作系统 Linux 能够在处理器间透明地分派和移动工作负载，即操作系统进程。从软件开发的角度来看，无论它运行在哪个 Cortex-A53 处理器上，操作系统 API 边界都确保软件以相同方式运行。这种类型的运行也称为对称多处理 (SMP)。

• 如果 Cortex-A53 处理器保持独立运行，但是如采用开源 Xen 或各种商用解决方案等虚拟机管理器来协调它们的合并运行，处理器间的关系就被视为“受监督”非对称关系。也就是说虚拟机管理器在 Cortex-A53 处理器间起着监督器的作用，确保并行运行在 Cortex-A53 处理器上的独立软件堆栈间存在共同约定的仲裁方。第 3 章"系统软件考虑因素"中， APU 的受监督 AMP 模式是针对特定类型应用的建议配置。

• APU 应用还应允许混合配置。如一部分 Cortext-A53 核可以划分到虚拟机管理器管理之下，同时其他的核由某一 OS 管理运行在 SMP 模式。但是这是一种赛灵思既不提供，也不支持的高级配置。

• 如果 Cortex-A53 处理器全部独立运行，处理期间没有公共操作系统或虚拟机管理器的情况下各自运行不同的系统软件，也应将它们视为彼此建立于非对称关系。更具体地讲，可以说它们运行在“无监督”AMP 模式下，即没有统一的软件负责协调 Cortex-A53 处理器间的运行。然而要注意的是，由于 Cortex-A53 处理器上的有受监督 AMP 配置的复杂性，赛灵思并不建议也不支持这样的 APU 配置。具体参阅第 3 章"系统软件考虑因素"。

后， APU 硬件上是允许混合配置的。一部分 Cortext-A53 核可以划分到虚拟机管理器管理之下，同时其他的核由某一 OS 管理运行在 SMP 模式。但是这是一种赛灵思既不提供，也不支持的高级配置。

总的来说，因为 Zynq UltraScale+ MPSoC 器件把众多不同类型的处理器和处理器核结合在单个器件里，这种情况称为提供“异构”计算。作为这种类型的器件， Zynq UltraScale+ MPSoC 器件让众多处理器和处理器集能够通过上述各种方式，与同一个块内的其他块或组件建立关联。

下面是对上文介绍内容的快速回顾：

• SMP：当 APU 内的处理核受单个操作系统管理时

• AMP：当处理块彼此独立工作时

° 受监督：当虚拟机管理器协调 AMP 块时

° 无监督：当 AMP 块间不存在统一仲裁器时

• 异构计算：在同一器件中结合不同处理器类型





应用处理单元 (APU)根据您使用的具体 Zynq UltraScale+ MPSoC 器件型号， Zynq UltraScale+ MPSoC 器件上的 APU 可搭载两个或四个 Cortex-A53 处理器。

除许多其他特性外，每个 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] 了解完整的特性清单。


图 2-3：应用处理单元 (APU) 原理图





因此 Cortex-A53 处理器提供与第 3 章"系统软件考虑因素"中讨论的其他计算平台相同的高端通用计算功能，能够满足高端通用应用与 OS 运行条件。请注意，虽然 Cortex-A53 处理器大多是独立运行的，但是为了让 APU 正确运行，必须为所有 Cortex-A53 处理器一致地管理一些 APU 资源，包括下文介绍的通用中断控制器 (GIC)。

下面是对 APU 的详细介绍：

如需了解 APU 软件运行方面的更多信息，请参阅第 3 章"系统软件考虑因素"和《Zynq UltraScale+ MPSoC：软件开发指南》 (UG1137) [参照 5]。本章其余内容重点关注 APU 的处理功能。

APU 上的 SMP赛灵思提供具备支持 SMP 模式的开源 Linux，能进一步根据开发人员的需求加以配置。该内核配置支持开发人员指定可供操作系统 SMP 功能使用的 CPU 核数量。在可用核数量下选择一个数值，使用底层虚拟机管理器部署核，可以释放一个或多个核用于其他应用，例如赛灵思软件开发套件 (SDK) 创建的定制裸机应用。

APU 上的无监督 AMPAPU 上的无监督 AMP 指将控制权移交给第一个处理器，由该处理器启动特定 OS 并且在其他处理器上运行工作负载。在这种工作模式下，资源共享由开发人员实现。如前文所述，由于实现存在微妙的复杂性，赛灵思建议既不推荐也不支持此类 Zynq UltraScale+ MPSoC 器件用例。


图 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 上的受监督 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 模式下的虚拟机管理器内，以 AArch32 运行的操作系统内核也只能在 AArch32 执行模式下运行应用。

• 32 位虚拟机管理器仅限用于 AArch32 操作系统和应用。

APU 虚拟化支持Zynq UltraScale+ MPSoC 可通过四个关键组件支持硬件虚拟化。部分功能已经为 Zynq UltraScale+ MPSoC 器件的系统软件所用，例如 Xen 虚拟机管理器。理解这些功能将有助于您更有效地围绕 Zynq UltraScale+ MPSoC 器件对您的系统进行设计。

Cortex-A53 处理器虚拟化

APU 上的虚拟化支持一般通过 Cortex-A53 处理器的 Armv8 架构规格中定义的异常级别 (EL) 之一实现。 Armv8 支持四个 EL，受支持的虚拟机管理器可以使用 EL2 将虚拟机管理器情景从客户操作系统中隔离出来。有关 Cortex-A53 处理器的异常级别的详细讨论，请参阅第 7 章"资源隔离以及分区"中的 Arm TrustZone 部分。





中断虚拟化

有关中断虚拟化的讨论，请参阅第 31 页的“APU 中断虚拟化”。


图 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





用于 I/O 虚拟化的系统 MMU通过根据软件管理的表格自动运行的地址转换，系统 MMU (SMMU) 可将用于 I/O 和虚拟机管理器的地址虚拟化进行简化。下图体现的就是 SMMU 地址虚拟化示例之一：

SMMU 可分两个阶段运行，如上图所示的“S1”、 “S2”或“S1/S2”。

• 阶段 1：

它取得虚拟地址 (VA) 并将其转换成“中间物理地址”IPA。它取得虚拟地址（VA）并将其转换成“中间物理地址” （IPA）。

• 阶段 2：

在虚拟机管理器环境中，通过让客户直接在系统中配置具有 DMA 功能的器件，无需与虚拟机管理器接口，达到简化了虚拟机管理器的设计。在这个阶段，它将 IPA 转换为物理地址 (PA)。


图 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





下图是虚拟机管理器 (hypervisor) 环境中 SMMU 的地址虚拟化图示：

SMMU 拥有下列关键组件，与下一节中描述的 Zynq UltraScale+ MPSoC 器件互联接口：

• 转换缓存单元 (TBU)：用于地址转换

• 转换控制单元 (TCU)：用于控制和管理地址转换

第 7 章"资源隔离以及分区"进一步讨论这个话题。

外设虚拟化

通常，虚拟机管理器能够使用 SMMU，以便让客户完全占有带 DMA 功能的器件。对于希望跨多个客户 OS 共享单个硬件器件的系统设计，使用名为半虚拟化的技术。这需要为所有要共享器件的 OS 提供新的器件驱动。共享器件的吞吐量相应地小于专有器件，如 SMMU 所映射器件。

定时器虚拟化

Arm 处理器内置用于各种任务的通用硬件计时器。一个计时器能够计算系统的全局时间。这个通用计时器与一个计数器相关联。这个计数器的计数速度取决于系统设置或 CPU 频率。每个 CPU 核包含一个物理计数器，该计数器包含系统计数器值。每个 CPU 核还具有一个虚拟计数器，用于提示虚拟时间。在虚拟机已中断、控制权返回至虚拟机管理器的同时，这个虚拟计数器会保存并暂停。根据执行层面，能否使用计数器值可以由操作系统控制。


图 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





实时处理单元 (RPU)Zynq® UltraScale+™ MPSoC 配备两个 Cortex-R 处理器。这两个处理器通常用于运行确定性、低时延与需要迅速响应的应用。

除众多特性，每个 Cortex-R5 处理器还可提供：

• Armv7-R 架构支持

• 32 位运行

• 性能高达 600 MHz

• 专用 L1 缓存

• 具有纠错模式 (ECC) 的 128 KB 紧密耦合存储器 (TCM)

• 单精度和双精度 FPU

请注意，与 APU 的情况相似，虽然 Cortex-R5 处理器能够独立运行，但是为了让 RPU 正确运行，必须为两个 Cortex-R5 处理器一致地管理一些 RPU 资源，包括下文进一步讨论的通用中断控制器 (GIC)。

根据您的需要，可将 Cortex-R5 处理器设置为两种不同的工作模式：

• 分离模式/无监督 AMP 模式：

也称为性能模式。这是 Cortex-R5 处理器的默认模式。在这种模式下，除上文刚解释说明过的中断控制器，每个核都独立运行。在分离模式下，一个核可能运行 RTOS，而另一个核则可能运行裸机。或者两个核可能运行不同的 RTOS。与 APU 不同，因为 Cortex-R5 处理器不支持虚拟机管理器，所有这种模式下的此类配置都被视为无监督的 AMP。通过直接传递中断以及与赛灵思裸机库共享内容，或是使用 OpenAMP 框架里提供的高级特性实现一系列高级特性，就能实现 Cortex-R5 处理器间的通信。如需了解更多信息，请参阅《Zynq UltraScale+ MPSoC OpenAMP：入门指南》 (UG1186) [参照 8]。

• 锁步模式：

也称为安全模式。在该运行模式下，对于系统的其余部分来说，Cortex-R5 处理器起单个 CPU 的作用。然而，在内部，核并行处理同一指令；延迟 1½ 时钟周期以便检测单事件故障。如果来自两个核的输出不同，比较与同步逻辑将检测后续的定制响应并通过发信号提示错误。例如，篡改可能导致锁步核间失去同步。为对此做出响应，您可以决定关闭系统或锁定系统。下图所示的是这种模式下工作的 RPU：


图 2-8：实时处理单元 (RPU) 原理图





如果您的应用是任务关键型应用，或者如果您要求具备检测单个事件故障能力的功能安全性，则锁步模式很可能是优选模式。另一方面，如果您希望将两个 Cortex-R5 处理器都用于您的应用，从而从它们发挥出的完整性能获益，则默认的分离模式是理想的。

正如第 4 章"电源考虑因素"所述， Cortex-R5 处理器属于所谓的“电源岛”的组成部分，可以一起进行门控。但是，它们不能够单独分开门控。

有关 RPU 的更详细讨论，请参阅“实时”一章。

互联Zynq UltraScale+ MPSoC 器件的互联是其异构架构的核心。它可将所有处理块链接在一起，并让它们通过接入外设、器件及存储器与外部环境接口相连。因此，理解其功能至关重要，有助于理想地调整您的系统。

Zynq UltraScale+ MPSoC 器件的互联基于 Arm 的高级微控制器总线架构 (AMBA) 4.0 规格定义的 Arm 的高级可扩展接口 (AXI) 的组成部分，同时包含多种其他相关的 Arm 技术，例如缓存一致性互联 (CCI-400) 以及 CoreLink NIC-400 网络互联。 Arm 在其提供的相应规格与文档中极为详尽地介绍了这些技术。但是，当前目的在于简要介绍相关核心概念，将有助于确定如何按自己的需求对 Zynq UltraScale+ MPSoC 器件的互联进行调整。

AXI 接口

在 Zynq UltraScale+ MPSoC 器件内链接任何块对的主要机制是 AXI 接口。但是，当前目的在于简要介绍相关核心概念，将有助于确定如何按自己的需求对 Zynq UltraScale+ MPSoC 器件的互联进行调整。主控制器发出需要由从设备完成的请求。每个 AXI 接口由五个不同通道组成：

• 读取地址通道

• 写入地址通道

• 读取数据通道

• 写入数据通道

• 写入响应通道


图 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





下图总结的是主控制器与从设备间的交互。

每个 Zynq UltraScale+ MPSoC 器件块可包含多个接口主从设备。鉴于 Zynq UltraScale+ MPSoC 器件中的组件数量以及它们之间复杂的关系，主从控制器极少直接连接。相反， Zynq UltraScale+ MPSoC 器件在战略点上配置多个开关，用于实现各个块之间的彼此互联，同时保持 Zynq UltraScale+ MPSoC 器件对功耗管理、安全、隔离以及总体灵活性的重视。


图 2-10：AXI 主控制器与从设备间的交互，读取通道


图 2-11：AXI 主控制器与从设备间的交互，写入通道

Masterinterface

Read address channelAddress

andcontrol

Read data channel

Readdata

Readdata

Readdata

Readdata

Slaveinterface

X12076

Masterinterface

Write address channelAddress

andcontrol

Write data channel

Writedata

Writedata

Writedata

Writedata

Writeresponse

Write response channel

Slaveinterface

X12077





流量优先级与一致性

在 Zynq UltraScale+ MPSoC 器件内，无时不刻都存在显著的并行流量。然而，不同处理块与资源有不同优先级，同时互联上仍然有多方正在同时访问存储器。因此必须有方法对流量进行分级，与此同时保持去往存储器的流量的一致性。

就流量而言，并非所有进出互联开关的流量都被赋予相同的优先级水平。相反，在 Zynq UltraScale+ MPSoC 器件的互联内的 AXI 流量属于下列三种优先级之一：

• 低时延（高优先级）

该类流量优先级一般需要高于其他类型的流量。例如 APU 和 RPU 间、以及内存间的流量就属于这种情况。

• 高吞吐量（高工作量）

该类型流量能承受更高时延，但是必须拥有极高的吞吐量。 GPU 和 PL 就属于这种类型。

• 同步（视频类）

除了某些关键时刻外，该类型流量通常能承受高时延。如视频/图像数据。当超时限定即将到期时，这类流量就会被分配高优先级。

下图是 Zynq UltraScale+ MPSoC 器件的互联与流量类别简图：

图示默认流量类别用“LL”表示“低时延”， “BE”表示“尽力而为”， “V”表示“视频”。本图中的许多块已经在本章的前文中有所讲述，或是已经在本节前文中做了介绍。注意 TBU 块和 TCU 块是前一节中讨论的 SMMU 的组成部分。因此本图还显示了 SMMU 和互联间的紧密关系。

除开关外， Zynq UltraScale+ MPSoC 器件的其他关键组件均属于缓存一致性互联 (CCI)。该互联用于确保不论涉及 Zynq UltraScale+ MPSoC 器件的哪一部分，内存传输事务都可以保持一致。


图 2-12：互联与流量类别简图





下图突出显示了 CCI 的作用：

详细视图

除本节之前介绍的组件， Zynq UltraScale+ MPSoC 器件的互联还包含一些值得了解的额外子模块：

• AXI 超时块：

防止主控制器因从设备不响应而挂起

• AXI 隔离块 (AIB)：

在系统块间管理断电模式转换

• XMPU/XPPU：

在主块和从块间强制隔离。具体讨论请参阅第 7 章"资源隔离以及分区"。

• AXI 走线宏单元 (ATM)：

使用高级跟踪总线 (ATB) 为 CoreSight 取回 AXI 跟踪

• AXI 性能监控 (APM)：

采集 AXI 性能指标


图 2-13：CCI 的作用





下图是根据以上说明绘制的 Zynq UltraScale+ MPSoC 器件互联的详细视图。

服务质量 (QoS)如上图，互联的另一个极为重要的方面是服务质量 (QoS)。在 QoS 系统包含两个部分，分别是互联开关和 CCI。

基于开关的 QoS

如果您仔细观察该图，您会注意到大部分开关都具有 QoS-400 能力。QoS-400 是前文提到的 CoreLink NIC-400 标准的 Arm 补充。该标准被 Zynq UltraScale+ MPSoC 器件用于自己的开关互联。互联中的大部分 AXI 主控制器都分配有 QoS-400 调节器。

注释：QoS-400“调节器”是 Arm 文档中的术语，指的是与 AXI 主控制器有关，并用于控制 AXI 主控制器行为的块。

该调节器有助于针对每个 AXI 主控制器限制下列内容：

• 在任何时间未完成的大可能传输事务数量

• 命令发布率


图 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





基于 CCI 的 QoS

Zynq UltraScale+ MPSoC 器件中使用的 CCI-400 具备 QoS 虚拟网络 (QVN) 特性，用于避免两个不同流量优先级生成的请求在访问存储器的过程中产生线头阻塞 (HOLB) 效应。下图体现的正是这种情况：

在这种情况下，通过 CCI 的一个流量标记为“低时延”，另一个流量标记为“尽力而为”。线头阻塞 (HOLB) 是指较低优先级流量，即“尽力而为”流量会占用较高优先级流量，即“低时延”流量的资源（例如 DDR 端口）。 QVN 使用不同队列和令牌在两个 DDR 端口间仲裁流量，以避免 HOLB 导致延迟。

这种做法对 APU 有所帮助。因为 APU 不局限于使用单个预分配 DDR 端口，相反，它在两个与 CCI-400 上的 DDR 相连的端口间来回切换，同时 APU 本身也与 CCI-400 相连。详情请查阅上一节的原理图。

如前文所述，因为 APU 的流量一般是“低时延”流量，同时大部分与 APU 共享 CCI 的其他流量是“尽力而为”流量，因此使用 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 主控制器中的哪个流量正受来自较低优先级主控制器流量的负面影响。随即，您可以调整对应的 QoS-400 调节器，将重要性较低的 AXI 主控制器减速。比如，如果 APU 和 RPU 的流量重要性低于来自 PL 的流量，您可以配置 APU 和 RPU 的调节器使 PL 中的流量更加优先。但是为有效地完成这项工作，您必须确保对 Zynq UltraScale+ MPSoC 器件中的流量具有深刻的认识。

只有默认设置对您的设计不起作用时才可进行这样的操作。


图 2-15：基于 CCI 的 QoS

CCI-400

LL Traffic BE Traffic

DDR ControllerPort 1 Port 2

X15889-101816





PL 接口

Zynq UltraScale+ MPSoC 器件互联中 PL 与系统其余部分的连接是由设计人员完全控制的。正如前文中主互联图中所示，以及和第 5 章"可编程逻辑"中所讨论的内容，从 PL 到互联，进而到系统其余部分存在多条路径。第 5 章中的说明建立在本节之前的说明之上。

附加信息

如需了解有关互联的更多信息，请参阅《Zynq UltraScale+ MPSoC 技术参考手册》 (UG1085) [参照 7] 中的对应章节，以及针对下列内容的官方 Arm 文档：

• AMBA 4.0–the core AXI standard

• NIC-400–the switch interconnect

• CCI-400–the cache coherent interconnect

• QoS-400–the QoS addition to NIC-400

中断具有高集成度，并采用异构设计的 Zynq UltraScale+ MPSoC 器件包含大量中断源，并具有多种处理中断源的方法。例如，大部分集成外设通过触发中断向处理器通知重大事件；这包括以太网、USB、GPU、DisplayPort、DMA、UART、SPI、 SD 等。 PL 还能够触发 16 种不同的中断。

此外， Zynq UltraScale+ MPSoC 器件还包含可配置的处理器间中断 (IPIs)，也可以用于独立处理块之间的通信。

在 Zynq UltraScale+ MPSoC 器件上有两个中断控制器，一个用于 APU，另一个用于 RPU。APU 的中断控制器使用 Arm 通用中断控制器第 2 版 (GICv2) 规格， RPU 的中断控制器则基于 Arm GICv1 规格。前者的主要优势是能够在 APU 上实现中断虚拟化。





下图体现的是 Zynq UltraScale+ MPSoC 器件的中断布线：

标注为 GIC-400 的块是 APU 的 GICv2 中断控制器，而标注为 GIC (PL390) 的块是 RPU 的 GICv1 中断控制器。

APU 中断控制器

每个 Cortex-A53 处理器有四条中断线输入：

• nIRQ 是正常优先级中断

• nFIQ 是高优先级中断或“快速中断”

• nVIRQ 是正常优先级虚拟中断，用于 APU 上的虚拟化支持

• nVFIQ 是高优先级虚拟中断，用于 APU 上的虚拟化支持


图 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 中断处理器对 Cortex-A53 处理器的中断处理如下图所示：

中断处理器分为两个部分。分配器负责寄存入站中断，同时在将它们分配给正确的目标 CPU 之前排列它们的优先顺序。中断控制器的第二部分是与每个 CPU 的中断线的接口，在相关的 Cortex-A53 处理器上触发中断。

中断控制器处理三种类型的中断：

• 16 个用于在核间发送中断的软件生成中断 (SGI)

• 7 个针对单个 Cortex CPU 核的专用外设中断 (PPI)

• 所有 APU 核和 RPU 核间共享的 92 个共享外设中断 (SPI)

APU 中断虚拟化

当 APU 在运行虚拟机管理器时接收到中断，虚拟机管理器会与 APU 的中断控制器相接，从而为客户 OS 生成虚拟中断，如下图所示。这些中断将直接发送到客户 OS，客户操作系统会处理并清除它们。如果中断不需要到达客户，虚拟机管理器能够在本地处理并清除中断。


图 2-17：APU 中断控制器





RPU 中断控制器

RPU 的 GICv1 中断以如下所示的方式连接到 Cortex-R5 处理器。它与 APU 的中断控制器类似，但不支持虚拟中断。它还能为前面提到的每一种中断类型（例如 SGI、 PPI 与 SPI）处理少量的中断。


图 2-18：APU 中断虚拟化


图 2-19：RPU 中断控制器





安全状态与中断

第 7 章"资源隔离以及分区"中有所阐释，根据 Arm 的 TrustZone 规格，所有通过互联连接的 Zynq UltraScale+ MPSoC 器件块可分为安全与非安全两类。虽然在第 7 章会详细介绍，但请注意 APU 与 RPU 的中断控制器都不区分触发中断的模块是安全还是非安全。按照惯例， APU 上的 FIQ 会发送到安全监测器，但这是一个软件选择而非硬件要求。

处理器间中断

处理器间中断 (IPI) 是 Zynq UltraScale+ MPSoC 器件中处理块之间的通信基础，能为中断远程处理器提供通道，并且可承载一定数量的有效载荷。例如， IPI 的主要用途之一是功耗管理。如果全功耗域断电， IPI 会发送至 PMU，以请求为其恢复供电。

共有 11 条 IPI 通道，其中 4 条保留用来与平台管理单元 (PMU) 通信。除保留用于与 PMU 通信的通道外，每条 IPI 通道都有两个 32 字节的缓存区和 6 个寄存器，供源和目标间的通信使用。第一个缓存由主控制器用于存储请求，第二个缓存由目标设备用于存储响应。下图展示了主控制器是如何操作寄存器触发 IPI，目标设备如何确认并应答中断。

OpenAMP

直接将 IPI 用于 Zynq UltraScale+ MPSoC 器件内的跨块通信可能会相当繁琐。因此，赛灵思提供了 OpenAMP 框架（更详细讨论见第 3 章"系统软件考虑因素"），以促进异构环境中的 AMP 系统开发。OpenAMP 建立在 IPI 之上，并提供两个关键组件以便 CPU 核之间进行通信：

• Remoteproc：用于启动和管理远程 CPU 的生命周期

• RPMsg：用于远程 CPU 间的通信。

如需了解更多关于 OpenAMP 及其使用的信息，请参阅第 3 章"系统软件考虑因素"。


图 2-20：处理器间中断通道寄存器

Enable

Trigger

Observation

Status/Clear

Disable

Mask

Req/Resp buffers

Master A Master B

IPI Channel

X18707-032117





使用 PL 加速工作负载正如第 11 页的“处理器系统方法”里提到的， Zynq UltraScale+ MPSoC 器件的 PL 可通过手动编码、 Vivado® HLS 或赛灵思 SDSoC 开发环境来卸载处理。这种方法能帮助系统设计人员轻松地把软件移动到 PL 上，从而实现性能加速。

使用 SDSoC 卸载处理到 PL 的过程总结如下：


图 2-21：PL 卸载过程总结





SDSoC 拥有多项特性，有助于开发人员分析运行在 MPSoC 硬件上的应用性能。它通过生成完整的代码报告，便于开发人员识别重复的代码段。该报告可判断内置在环境中的代码是否可以通过卸载到 PL 而得到改善，并估算其对系统性能的改善情况以及对 PL 资源的占用情况。下面的屏幕截图就是 SDSoC 环境能提供的信息类型示例。

C/C++ 代码随后能转换为布局在 ZU 的 PL 里面的块。这一步使用 Vivado HLS （用于高层次综合）编译器完成。

在完成综合后，会为开发人员提供关于综合环境选择数据移动器的报告。 SDSoC 可自动选择您的数据移动器和驱动程序，不过在需要时也可以通过用户控制轻松地变更。 SDSoC 还能生成调用封装，以便运行在 APU 或 RPU 上的应用能调用 Verilog 中生成的 IP 块，或是板上的 PL 部分中生成的 VHDL。这种方法跳过了前面刚刚介绍的 HLS 编译流程。


图 2-22：通过 SDSoC 进行 PL 加速输出示例





通用计算加速除了前文介绍的针对性地手工或自动将工作负载卸载到 PL，还有几种用于加速通用计算的常用方法与技术。这其中包括在支持 GPGPU 的图形处理单元上使用 OpenCL 库与通用计算。与其他行业的方法相比，前文刚刚讨论的 Zynq UltraScale+ MPSoC 器件 PL 卸载功能可提供极具优势的计算加速路径。 Zynq UltraScale+ MPSoC 器件中使用的 MALI-400 GPU 采用专为图形加速设计的架构，并不适用于 GPGPU。

下表所示的是独立发表的有关结果，说明通过 FPGA 实现的优化可超越通用 GPU 与 CPU 相结合的性能：


图 2-23：FPGA 与 CPU+GPGPU 及 CPU-Only 优化的对比





后，下表总结了为什么使用 PL （例如 FPGA）比使用 GPGPU 进行加速可能会得到更优异的结果。

总之，如果您正在寻找加速软件，我们强烈建议您尝试 PL 的卸载功能。除上面提到的 SDSoC 工具，还有一个或许对您有用的工具——赛灵思 SDAccel™ 开发环境。 SDAccel 专为 FPGA 上的 OpenCL、 C 和 C++ 加速定制开发。


图 2-24：FPGA 加速优势与 GPGPU 对比




第 3 章

系统软件考虑因素Zynq® UltraScale+™ MPSoC 上的软件基本渗透到该器件的所有区域。软件的存在形式包括裸机应用、中间件、固件、驱动程序、高级操作系统 (HLOS)、库、高级应用、图形应用、通信协议等。根据您特定的 Zynq US+ MPSoC 应用，可以定制化（包括或排除）芯片上的软件组件，用于实现特定硬件特性，从而影响器件运行速度与效率，并在总体上提供您所希望的全覆盖执行环境。简言之，您特定的软件定义是您系统的粘合剂。

定义您的系统软件需求鉴于 Zynq UltraScale+ MPSoC 器件具备的软件灵活性以及发挥 Zynq UltraScale+ MPSoC 器件完整潜力的重要性，设计人员必须确保自己充分认识对应 Zynq UltraScale+ MPSoC 器件不同部分所提供的软件选项。本章为您介绍可供 Zynq UltraScale+ MPSoC 器件使用的软件选择以及相关建议。

回答下列问题有助于您针对 Zynq UltraScale+ MPSoC 器件定义您的设计需求：

1. 您倾向于运行裸机还是使用操作系统？

2. 如果您选择运行裸机，这个选择背后的具体原因是什么？

3. 您是否需要实时功能？

4. 您是否有任何启动时间约束？如果有，这些约束的严格程度如何？

5. 您首选的构建或开发环境是什么？




第 3 章：系统软件考虑因素

系统软件方法注释：Zynq UltraScale+ MPSoC 平台能够在系统内的多个处理块上同时运行多种独立软件堆栈。下图是本指南介绍部分中介绍的完整系统图的简化概念图，以高亮显示各个处理块，其中绿色块灵活性高，适合运行任何类型的软件。黄色块和白色块灵活性依次降低。本图并非是 Zynq UltraScale+ MPSoC 器件内部块的准确表达。相反，它主要是一张概念图，用于解释当前概念。


图 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





应用处理单元 (APU) 与实时处理器单元 (RPU) 包括通用 Arm A53 和 Arm R5 处理器，可以运行任何在嵌入式处理器上运行的软件。图形处理单元 (GPU)、平台管理单元 (PMU) 和处理逻辑 (PL) 在构建时考虑了特定功能，在软件应用方面受约束较大。GPU 的功能一般通过赛灵思提供的图形库、多媒体库和驱动程序进行访问。赛灵思为 PMU 提供默认固件。虽然可以创建定制 PMU 固件版本，但仍然强烈建议使用默认固件。此外， PL 还能以两种方式运行软件：1）通过优化软件部分到硬件，或 2）通过运行 MicroBlaze™ 处理器软核实例。

注意，正如第 39 页的图 3-1 所示，配置安全单元 (CSU) 块以虚线显示，因为它在工厂编程，因此不能进行任何方式的定制。

功耗管理是 Zynq UltraScale+ MPSoC 器件架构的核心，因此决定在每个块上使用软件组件时，记住这一点至关重要。正如第 2 章"处理器系统"中介绍的， Zynq UltraScale+ MPSoC 器件拥有多个能够在运行时中控制的功耗域。例如，如果您选择在 APU 上运行 Linux，当整个功耗域都会断电， Linux 操作系统将不可使用。

本章详细介绍 APU 和 RPU 的软件功能。本章还介绍用于运用 GPU 的软件以及默认 PMU 固件的功能。如需了解有关 GPU 在内的图形功能的更多信息，请参阅第 9 章"多媒体"。如需了解有关功耗管理的更多信息，请参阅第 4 章"电源考虑因素"。PL 的硬件卸载功能，请参阅第 2 章"处理器系统"。如需了解在赛灵思 PL 中使用 MicroBlaze 软核的信息，请参阅赛灵思 MicroBlaze 技术文档。

应用处理单元 (APU) 软件

APU 是 Zynq UltraScale+ MPSoC 器件的主要通用处理块。拥有多达 4 个运行速度高达 1.5 GHz 的 A53 处理器，该 APU 能够提供可观的计算能力，支持强大的软件抽象。

该 APU 上提供下列软件及软件配置：

• 裸机运行。可直接在 A53 上运行，或是作为客户在 Xen 虚拟机管理器上运行。

注释：可在单个 A53 处理器上运行，但不支持多核 A53 处理器上运行。

• 功能齐备的 SMP Linux。可直接在 A53 上运行，或是作为客户在 Xen 虚拟机管理器上运行。

• FreeRTOS。可直接在 A53 上运行，或是作为客户在 Xen 虚拟机管理器上运行。

注释：可在单个 A53 处理器上运行，但不支持多核 A53 处理器上运行。

• Xen 虚拟机管理器可用来在一些 A53 上托管客户 Linux 实例，或运行 Linux 实例。

• Arm 可信固件 (ATF) 支持 A53 处理器的 TrustZone 功能，具体讨论见第 7 章"资源隔离以及分区"。

• 赛灵思开放非对称多处理 (OpenAMP) 框架能够让运行在不同 Zynq UltraScale+ MPSoC 器件块上的软件彼此通信。

• 针对上述任一种情况的相关驱动程序、服务及库。

这里是 APU 的一个示例配置，能够运行前文介绍的许多软件包。





在本例中， APU 同时运行 Arm 可信固件 (ATF)、 Xen 虚拟机管理器和两个单独的客户操作系统。因此，用两种重要方式对 APU 进行隔离。首先，是安全环境与非安全环境，通过使用 Armv8 TrustZone 特性实现，具体见第 7 章"资源隔离以及分区"。其次，是两个不同的客户操作系统并行运行，这通过使用 Xen 虚拟机管理器实现。

APU 裸机用途

如果您是初次接触 Zynq UltraScale+ MPSoC 器件，您的第一感觉可能是好完整地以裸机方式（即不使用任何操作系统或虚拟机管理器）使用它，强烈建议您细致地分析这一倾向背后的原因，尤其是与 APU 有关的方面。虽然 APU 可支持裸机运行，但只有一个 A53 处理器能用于这种用例，从而使得其他三个 A53 处理器都不可用。因此，在对您的系统进行架构之前，您应该仔细地权衡这种情况。背后的原因在于裸机不支持 SMP 运行。这算不上什么硬件限制，因为 Xen 和 Linux 都能管理 APU 的众多 A53，更多的是这项工作的意义和所涉及软件的复杂性。

因此，如果您有意使用 APU 裸机或还在犹豫不决：

1. 凭借 600 DMIPS 的性能， RPU 可在处理器上提供业界佳的实时中断响应。

2. 在 APU 上运行裸机能提供足以满足大量设计方案要求的实时响应，但代价是难以利用所有 APU 处理器核。

对于既不需要超快速，也不必需要紧密分布的实时特性的产品而言，实践证明在虚拟机管理器 (hypervisor) 上并行运行裸机与其他操作系统就足矣满足关键产品要求。如果您担心的是硬实时响应时间，那么您就需要回答如下问题：是否需要实时代码与 Linux 紧密关联。如果实时代码具有相当的独立性，那么可能使用 RPU 运行代码要合适得多。如果实时代码和 Linux 之间存在相依性，我们仍然建议您首先考虑在 RPU 上运行实时部分，并在需要时使用 OpenAMP 框架与在 APU 上运行的 Linux 实例进行通信。后，如果即使使用 OpenAMP 也未能解决您的问题，那么您可以考虑在 APU 上使用第三方提供的 Linux 实时版本中的其中一种，或是使用性能适合的虚拟机管理器 (hypervisor) 在 APU 上运行裸机或与 Linux 及 RTOS 的组合实例。

如果您的应用不要求严格的实时性能，那么经实践证明，在 Xen 虚拟机管理器上执行裸机应用具有可行性。 Xen 能帮助您全面控制运行在 A53 上的软件，而实际上不会要求必须以客户端运行 Linux。因此，借助 Xen 您还可以在单独的 A53 上运行裸机代码。


图 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





实时处理单元 (RPU) 软件

Zynq UltraScale+ MPSoC 器件将 RPU 当作与 APU 并列的完全独立块，让设计人员能在其上同时部署实时计算与通用计算工作负载，且不会降低两者的性能。通过提供专用的实时处理环境， RPU 的两个 R5 可让设计人员不必求助 APU 的通用 A53 就能实现近乎实时的性能。在 A53 负责运行符合业界标准的通用高级功能和操作系统的同时， RPU 能够运行：

• 裸机应用

• FreeRTOS 与其他商业化 RTOS。

• 实现与其他处理块通信的 OpenAMP 框架

• 适用于上述任意一种情况的相关驱动程序、服务和库

注意， RPU 的 R5 既能在分离模式下运行，也能在锁步模式下运行。在分离模式下，每个 R5 都能运行其自己的软件堆栈，如这里的图示所示：

如第 2 章"处理器系统"中所述，在锁步模式下， R5 之一可跟随另一个 R5 运行，并且如果它们的输出不同，就会触发错误。在锁步模式下运行时，与可用的紧密耦合型存储器 (TCM) 相结合，能为 RPU 提供 256 KB 的容量。

R5 能独立于 APU 由 FSBL 引导启动，或作为 APU 的从设备运行。在从模式下，可在 APU 上通过 OpenAMP 对 R5 进行加载应用并复位以启动实时应用。


图 3-3：RPU 软件堆栈示例

RPU

R5 Core 0

Baremetal RTOS

Baremetal RTOS

App1 App2 App1 App2

R5 Core 1

• • • • • • •• • • • • •





图形处理单元 (GPU) 软件

Zynq UltraScale+ MPSoC 器件可对 2D 和 3D 图形使用业界标准的 Arm Mali-400 MP2 图形处理单元 (GPU)。下图显示了在使用基于 Linux 的软件堆栈时，使用 GPU 所涉及的系统组件。

使用 GPU 的应用居于中间件之上，包括显示服务器（如 Wayland）、图形库（如 OpenGL ES 1.1）、 Mali 通用库、Gstreamer 以及视频编解码器等。在中间件和实际 GPU 硬件组件之间分层的是 Linux 内核驱动程序。这些驱动程序可处理缓存帧、 DRAM、 Mali 图形、视频及显示。


图 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





启动进程软件根据您系统的要求，启动时间行为与性能可能对您的应用至关重要，也可能不重要。无论是哪种情况，理解您系统的启动方式至关重要，尤其在部分操作只能在启动过程中完成时更是如此。

在启动过程会涉及到下列所有的块：

• PMU

• CSU

• APU

• RPU

• PL

其中的部分块可能使用下列软件和二进制组件：

• PMU 固件

• CSU 启动 ROM

• 第一阶段启动加载器 (FSBL)

• U-Boot

• Arm 可信固件 (ATF)

• PL 比特流

简言之，启动过程存在三个主要的阶段：

• 预配置阶段：PMU 主要控制预配置阶段，可执行能设置系统的 PMU ROM。PMU 能处理与复位及唤醒相关的所有处理器。

• 配置阶段：本阶段负责将第一阶段的启动加载器 (FSBL) 代码加载到片上 RAM (OCM)。它同时支持安全与非安全启动模式。可将 FSBL 加载到 APU 或 RPU 上。

• 后配置阶段：在 FSBL 执行开始后， Zynq UltraScale+ MPSoC 器件则进入后配置阶段。





启动进程基本

下图是启动过程的简化视图，显示了相关的块和软件：

在上述启动流程图中， PMU、 CSU 和 APU 中的软件系统全都协同工作以启动系统。完成下列操作：

• PMU 将控件移交给 CSU，以便检查并确定是否需要身份验证。

• CSU 将 FSBL 加载到片上存储器 (OCM) 中。

• 随后，在 APU 上执行 FSBL；另外，作为替代方案，其也能在 RPU 上执行。

• 然后， FSBL 启动客户应用软件或第二阶段的启动加载器，如 U-Boot 等。

下图是从另一个视角分析启动过程。PMU 控制所有的功耗与复位次序。PMU 首先释放 CSU，这样它就能执行通常不向用户公开的内部检查和初始化。根据开始执行 FSBL 的启动镜像的配置，将控件移交给 RPU 或 APU。 FSBL 可加载系统中的所有其他组件，如 RPU 上的 RTOS、 PL 比特流、 ATF 和 U-Boot、 Linux、虚拟机管理器等，以启动整个系统。


图 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 启动 ROM 和 FSBL 才能确保硬件可信根、热重启动和子系统间隔离等基本功能。此外，ATF 的使用和 Linux 的使用也密切相关的。

安全启动

有两种启动 Zynq UltraScale+ MPSoC 器件的模式：安全模式与非安全模式。前文中的时序图对非安全启动过程进行了基本的阐述。这里更完整的启动示例显示的是安全启动：

在这种情况下， CSU 完成了更多的工作，具体如下：


图 3-6：启动过程的另一种视角


图 3-7：安全启动进程

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

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 或 Ethernet AVB 等？在某些情况下，您可以使用部分重配置，先在启动过程中迅速加载比特流的核部分，然后再在较晚时间加载其余部分。

启动器件

Zynq UltraScale+ MPSoC 器件的 CSU 启动 ROM 支持下列主启动器件：

• QSPI

• NAND

• SD/MMC

• eMMC

虽然 CSU 不支持直接从 SATA、以太网或 PCI Express 启动，但使用小化 FSBL 有可能实现从这些器件的次级启动。

通常，您的选择取决于您的需要：

• 如果您需要的是速度，那么 SPI 闪存是首选。

• 如果您需要的是容量，那么对于不想让主机负担闪存文件管理职责的系统， eMMC 是较为理想的选择。

• 如果您具有错综复杂的存储配置，那么 NAND 将为您提供更大的灵活性。对于出于性能原因要求更精细地控制闪存且拥有强大的处理器以运行闪存管理软件的系统，这种选择是理想选择。对出于性能原因要求更精细地控制闪存且具备运行闪存管理软件的强大处理器的系统。

对于存储，另一个您可能需要牢记在心的是支持不同存储器件所涉及的引脚数。

就获得支持的启动器件而言，还有一些额外的注意事项：

• 串行闪存 (QSPI) 主启动模式可支持 4 字节寻址。

• NAND 支持开放式 NAND 闪存接口 (ONFI) 3.1 版。

• SD 卡支持 SD 规范 3.0 版。

• eMMC 支持嵌入式多媒体卡标准 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 上使用的软件堆栈列在了第 39 页的“系统软件方法”中。让我们更深入地了解其中一些堆栈以及有关它们用途的相关建议。

RPU 裸机软件堆栈

RPU 裸机软件堆栈由多层组成：

• 位于堆栈底层的是 Cortex R5 独立板支持包 (BSP) 处理器层。该层包含一个独立 BSP，内含处理器启动代码、缓存、异常处理、存储器、系统时钟配置和处理器功能初始化。

• 在 Cortex R5 独立 BSP 处理器层之上是针对各种硬件组件的多个单线程器件驱动程序，其中包括外设驱动程序和 Coresight 调试驱动程序，以支持系统调试。

• 再上一层由多个支持应用软件开发的库组成，包括 C 语言库、文件系统库、存储器、闪存、安全秘钥、功耗管理库和 lwIP 网络堆栈库。此外，该层还包含 OpenAMP 库，用于使用 Zynq UltraScale+ MPSoC 器件的 OpenAMP 框架，具体介绍参见第 53 页的“OpenAMP 框架”。

• 栈顶层根据需要可以是用户应用、定制库及服务。



http://china.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xBootAndConfiguration

http://china.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xDeviceSecureBoot

http://china.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug1137-zynq-ultrascale-mpsoc-swdev.pdf;a=xProgrammingViewOfZynqUltraScaleMPSoCDevices

http://china.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug1137-zynq-ultrascale-mpsoc-swdev.pdf;a=xSystemBootAndConfiguration

http://china.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug1137-zynq-ultrascale-mpsoc-swdev.pdf;a=xSecurityFeatures



虽然运行 RPU 的 R5 裸机确实能让您全面控制它们的功能，但这也意味着您必须手动调度任务，协调您软件组件之间的重要通信，手动管理跨软件锁定，并有可能手动处理通常由 OS 内核处理的其他几项功能。对于将处理过程视为有限数量的任务定义或任务同步良好的应用而言，运行一个或两个 R5 裸机可能是适合的方案。但是，如果您认为让 R5 完成的功能可能会超出您的初始计划，那么可能好考虑在 R5 上使用某种形式的 OS。实际上，从单 while(1) 循环开始，到后要求开发功能性 OS，对设计而言是司空见惯的事情。


图 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 FreeRTOS 软件堆栈

RPU FreeRTOS 软件堆栈与刚刚介绍的 RPU 裸机软件堆栈相同，只有一种情况例外：FreeRTOS 内核组件所处的位置在底层。通过使用 FreeRTOS，而不是运行 RPU 裸机，您可以从业界标准的实时 OS 获益。它能让您随着时间的流逝增长您的应用，而不必亲自管理核 OS 功能。相反，如果您的团队还不够熟悉 FreeRTOS 及其 API，那么他们就需要去适应。

APU 裸机堆栈

APU 的裸机软件堆栈与到目前为止介绍过的软件堆栈类似，由多个层组成：

• 位于堆栈底层的是 Cortex-A53 独立 BSP。一个用于 32 位模式，一个用于 64 位模式。 32 位模式与 Armv7-A 架构兼容，而 64 位模式则与 Armv8-A 架构兼容。每个独立 BSP 都包含处理器启动代码、高速缓存、异常处理、存储器、系统定时器配置及处理器专用功能初始化等。

• 在 Cortex-A53 独立 BSP 层的之上是针对各种硬件组件的多个器件驱动程序，如外设驱动程序与 Coresight 调试驱动程序，以支持基于系统的调试。

• 再上一层由可支持应用软件开发的多个库组成，如标准的 C 语言库、文件系统库、存储器、闪存、安全秘钥、功耗管理库及 lwIP 网络堆栈库。此外，该层还包含 OpenAMP 库，用于使用 Zynq UltraScale+ MPSoC 器件的 OpenAMP 框架，具体介绍参见第 53 页的“OpenAMP 框架”。



图 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 的裸机使用说明请参见第 41 页的“APU 裸机用途”里的介绍。赛灵思建议您检查您裸机应用的实时或中断响应要求，以确认应用是否能够托管在 Xen 虚拟机管理器上，从而为其他任务留出更多系统资源。


图 3-10：APU 裸机堆栈

Standalone Kernel and DriversStandard USB



EMAC EthernetDriver







Cortex A53 Standalone BSP Processor Layer


(libXil)







(xilpm)OpenAMP


(xilflash)






APU Linux 软件堆栈

在 APU 上运行 Linux 是运行 Zynq UltraScale+ MPSoC 器件的首选方法。作为 PetaLinux 工具的组成部分进行提供的 APU Linux 软件堆栈也由多个层组成，其中的众多层都是标准 Linux 软件生态系统不可或缺的部分：

• 位于堆栈底层的是 Linux 核内核与服务以及 Cortex-A53 BSP 处理器层。这些组件可提供处理器启动代码、高速缓存、异常处理、存储器、系统定时器配置和处理器专用功能初始化。

• 在该底层之上的是多个器件驱动程序、外设驱动程序、多个 Linux 驱动程序以及内核层的系统服务，包括资源管理、文件系统、 IO 管理、功耗管理、网络与多媒体堆栈层、图形、视频驱动程序以及网络堆栈。

• 该层的上一层由可支持应用软件开发的多个库组成，包括标准 C 语言库、文件系统库、存储器、闪存、安全秘钥、功耗管理库、多媒体库 OpenGL、EGL、DRM 库、显示服务器、音频服务器、OpenMAX 以及众多其他中间件库。此外，该层还包含 OpenAMP 库，用于使用 Zynq UltraScale+ MPSoC 器件的 OpenAMP 框架，具体介绍参见第 53 页的“OpenAMP 框架”。


Linux 在嵌入式系统、服务器和台式机中的使用已超过 20 年，并且周边已建立起极为丰富和活跃的生态系统。因此，对于众多定制与通用应用来说，它是一个坚实的基础，并且非常适合帮助您发挥 APU 多核设计的全部潜力。如果您的团队已对 Linux 非常熟悉，那么这可能是自然而然的选择途径。但是，如果您的团队还不熟悉 Linux，那么我们建议您先从赛灵思自己的 PetaLinux 入手。如前文所述， PetaLinux 是针对您嵌入式需求的低入门门槛 Linux 版本。

相反，与更加传统的嵌入式 OS 的情况相同，使用 Linux 的不便之处在于它采用的是分布式开发模式，这就不存在某个单独的权威实体能提供所有关于其使用的确定信息。因此，如果您不熟悉 Linux，那么在搜索关于系统特定方面的信息时，可能需要过滤掉与您用例无关的信息。但是， Linux 已被众多团队成功用于如此多的嵌入式项目中，因而后者可能也算不上什么障碍。

使用 Linux 的更加现实的技术限制是：默认情况下，内核不提供硬实时功能。 Linux 拥有一些众所周知的实时扩展版本，比如 PREEMPT_RT 和 Xenomai，但在撰写本文时却没有一个可以完全成为 Linux 内核的组成部分。因此，如果您


图 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 内核添加相关补丁。正如前文所述，如果您有任何实时需求，您都应该首先查看 RPU 及其功能。

赛灵思支持的各种 Linux 版本将在本章节后续部分进行更详细讨论。此外，您还可以参阅《Zynq UltraScale+ MPSoC：软件开发指南》 (UG1137) [参照 5]，获取有关使用 Linux 的更多信息。

当在 APU 上使用 Linux 时，还必须更深入地探讨一些软件堆栈，尤其是与图形有关的。如需了解有关下列堆栈在 Linux 环境中的更多信息，请参阅第 9 章"多媒体"。

• “Linux DisplayPort 堆栈”

• “Linux GPU 软件堆栈”

• “Linux 视频编解码器驱动堆栈”

OpenAMP 框架开放式非对称多处理 (OpenAMP) 是一种分层的模块化框架，能提供常见的 API 及方法，可实现 Zynq UltraScale+ MPSoC 器件等非对称多处理 (AMP) 系统中软件组件的彼此互联。它使得软件应用能够在这个异构多处理器系统中运行，其中不同的核实例能够运行不同的操作系统（如 HLOS、裸机或 FreeRTOS 等实时操作系统），以实现彼此通信与协作。更具体地说，OpenAMP 是一种通用的抽象框架，允许在构成系统的异构处理器之间加电、加载固件、断电及共享信息（通信）。

在 AMP 系统中，根据需要通常由主处理器启动远程核上的软件。随后，远程核通过使用处理器间通信 (IPC) 进行通信，从而让主处理器将工作分担给其他处理器。

下图展示了一种非常简单的 AMP 拓扑结构。在本例中，Linux 作为 APU 中的主处理器运行，同时 RPU 作为远程处理器来运行裸机应用。 Linux 负责加载和启动远程处理器。

OpenAMP 包括两个关键组件：

• Remoteproc：管理框架，用于控制来自于主处理器中对远程处理器的生命周期管理 (LCM)。

• RPMsg：消息传递框架，通过 API 实现运行在 AMP 系统中独立核上的软件间的进程间通信 (IPC)。


图 3-12：简单 AMP 拓扑结构


图 3-13：Remoteproc 和 RPMsg





RemoteprocRemoteproc 通过器件驱动程序实现，并通过 API 进行控制。在主处理器端通过 Remoteproc 的 API 将代码和数据加载到远程处理器的存储器中，启动远程处理器，管理自身与远程处理器间的通信通道以及关闭远程处理器。

从远程处理器的角度看，主处理器对 API 的调用能初始化远程处理器上的 Remoteproc 系统，管理远程处理器与主处理器间的通信通道以及关闭远程处理器上的 Remoteproc 系统。

RPMsgRPMsg 是处理器间的消息传输总线，其中每个处理器都是总线上的器件。处理器拥有作为彼此间通信链路的通道，这些通道在远程处理器启动时就完成创建。这些通道由源地址与目的地地址的名称进行识别。

RPMsg 可使用虚拟 I/O (Virtio I/O) 组件。 Virtio 可提供虚拟 I/O 服务，以支持主处理器与远程处理器之间的通信。

下图显示了 Virtio 如何适应 OpenAMP 层：

Virtio 使用 Vring，一种 Virtio 使用的 I/O 操作的传输抽象。 Vring 实现了环状缓存。

APIOpenAMP API 同时在主处理器和远程处理器上实现。该 API 指示 RPMsg 执行下列操作：

• 将消息发送至通道上的默认端点

• 发送可支持明确的源地址、目的地地址与阻塞选项的复杂消息

• 创建和删除通道及通道端点

• 接收数据

• 在数据传输过程中识别和使用缓存大小


图 3-14：使用 Virtio 的 RPMsg





这里是在 Zynq UltraScale+ MPSoC 器件上的启用 OpenAMP 核之间使用 API 的示例：

附加资源

如需了解更多 OpenAMP 的信息，请参阅《Zynq UltraScale+ MPSoC OpenAMP：入门指南》 (UG1186) [参照 8]。

Xen Hypervisor赛灵思已将 Xen 开源虚拟机管理器移植到赛灵思 Zynq UltraScale+ 器件上，并能在同一个计算平台上运行多个操作系统。Xen 可直接在硬件上运行，负责管理 CPU、存储器及中断，同时允许多个 OS 在虚拟机管理器顶部运行。可将这些 OS 称为域；有时也将其称为虚拟机 (VM)。

注释：如需了解有关 Xen 虚拟机管理器的更多信息，请参阅 Xen 项目软件简介，网址：https://wiki.xen.org/wiki/Xen_Project_Software_Overview。

下图显示了 Zynq UltraScale+ MPSoC 器件上的 Xen 虚拟机管理器架构示例：


图 3-15：使用 OpenAMP 框架的 SMP 与 AMP 混合示例

RPMsg

RPMsg

Open AMP(APIs for loading/ Unloading firmware, Message Passing)



https://wiki.xen.org/wiki/Xen_Project_Software_Overview

https://wiki.xen.org/wiki/Xen_Project_Software_Overview



Xen 虚拟机管理器可控制一个被称为域 0 （或 dom0）的域，以及一个或多个客户域（或 domU）。控制域拥有特殊权限，例如：

• 能直接访问硬件

• 能处理对系统 I/O 功能的访问

• 能与其他虚拟机进行交互

此外，其还向外界提供控制接口，通过该接口控制系统。每个客户域都运行自己的 OS 与应用。客户域与硬件完全隔离。

虚拟机管理器由启动加载器启动；欲知详情，请参阅第 44 页的“启动进程软件”。使用 Xen 虚拟机管理器运行多个 OS 涉及设置主机 OS 以及添加一个或多个客户 OS 等操作设置。就 Zynq UltraScale+ MPSoC 器件而言，Xen 还能在没有客户 OS 的情况下运行裸机应用。

性能优化考虑因素

如前文所述，根据您特定的实时与中断响应要求的不同，使用 Xen 虚拟机管理器可能适合您的系统设计配置。但是，每种设计各不相同，您可能需要额外关注 Xen 使用的特定方面。这里是一些在 Zynq UltraScale+ MPSoC 器件上优化 Xen 的性能优化技巧。

中断响应时间

中断响应时间是指在硬件层面生成中断，以便在运行于硬件之上的 OS 中触发相应代码的执行时间。对比本地 OS 与客户 OS，中断响应的时间不同。本地 OS 的性能因素涉及在处理器异常级别 3 （按 Armv8 架构）、 OS 中断处理程序与定时器上发生的操作，以及用于测试实际响应时间的测量精度。对于客户 OS，中断响应时间的性能因素要复杂得多，因为它们必须考虑一系列影响因素，包括虚拟机管理器中断处理、布线例程、虚拟机管理器定时器分辨率以及客户 OS 配置。

如果您在完成测量后，发现客户 OS 的中断响应时间需要对您的应用进行精细调节，您可以考虑进行下列优化，其利用相对直观的配置或设计变更：


图 3-16：Xen Hypervisor 架构

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 虚拟机管理器调度器的选择与配置

• 客户 OS 到物理 CPU 的分配

• 客户 OS：对比器件轮询与中断驱动决策

还可以采用其他优化技术，但这些技术不在本文的讨论范围之内。

启动时间

引导时间指 Xen 虚拟机管理器和 Xen Dom0 可以启动首个客户 OS 所需的时间。启动时间取决于 FSBL、Arm 可信固件和 U-Boot 的执行时间。此外，启动时间还依赖于启动器件和安全启动流程（即 Xen 虚拟机管理器启动和 Dom0 启动）。

如果您发现启动时间对于用例能够构成问题，您可以考虑几种无需改动虚拟机管理器的方法：

• Dom0 配置（缩小，加快）

• 启动器件选择（适用于未使用虚拟机管理器的系统）

• 安全启动参数（适用于未使用虚拟机管理器的系统）

直通 (Pass Through) 器件的 I/O 吞吐量

Zynq UltraScale+MPSoC 包含一个 IOMMU (Arm SMMU-400)，已经得到 Xen 等虚拟机管理器的支持。 IOMMU 允许客户 OS 使用具备 DMA 功能的原生器件驱动程序，该器件将数据直通给客户，无需调用仿真层或虚拟化层。

这种配置的 I/O 吞吐量取决于客户 OS 使用的器件驱动程序，并受执行 SMMU 提供的第二级地址转换的表现略有下降。

半虚拟化共享器件 I/O 吞吐量

Xen 虚拟机管理器可支持用于半虚拟化器件的基础架构，能实现两大特性：

• Xen Dom0 拥有和控制的器件能够有效地在多个客户 OS 间共享。

• 客户 OS 可通过虚拟器件相互通信，这些虚拟器件在每个 OS 中以 UART 或网络接口的形式体现。

这种类型配置的 I/O 吞吐量取决于下列因素：

• 原生 Linux 器件驱动程序的性能（由 Dom0 使用）

• 其他 OS 系统要求的 I/O 器件带宽

• Xen-总线基础架构的性能

• Xen Dom0 和 Xen DomU 负载的工作





PMU 软件平台管理单元 (PMU) 拥有多项职能，包括参与启动进程、提供功耗管理 API 和处理各种系统错误。本节介绍与 PMU 相关的一些软件开发方面的内容。有关功耗管理的更多具体介绍，请参阅第 76 页的“平台管理”。PMU 功能性原理图如下所示：

存储器

PMU 使用下列存储器类型：

• 针对数据， RAM 使用纠错码 (ECC) 存储器，并具有可选用户/固件代码。

• PMU ROM 具有默认的中断服务处理器 (ISR)，用作钩子模式 (Hook Mode) 下的中断处理。

• PMU 存储器（ROM 和 RAM）负责处理功耗管理功能（例如加电、断电、 IPI、复位请求。）

• 在赛灵思提供的框架内， PMU 有一个用户代码区域，可加载到 PMU RAM 内。

请注意，用于扩展 PMU 功能的存储器数量极为有限。在 Linux 内进行功耗管理，例如频率缩放，会影响 PMU 固件的大小。因此，您需要慎重估算您的功耗管理需求，确保 PMU 存储器能够容纳所需功能。

功耗管理框架

功耗管理软件框架可支持多种功耗降低模式（称为 Power Domains），这些模式的目标是各种硬件，并且能够使用具有稳健与定制电源需求的应用。该框架以源代码方式提供，因此可以定制。下图体现了典型框架调用如何在系统中传输：


图 3-17：PMU 原理图





该框架由上图中从左到右不同的 API 层组成。要了解该框架如何支持电源操作，需要考虑一个主电源单元，如核 A53 单元，通过处理器间中断 (IPI) 中断 PMU 以执行某些电源操作，如关闭电源岛。PMU 固件接收 IPI 之后生成一个 API 事件，向发送 ROM 处理程序调用。在默认中断服务程序 (ISR) 的驻留 ROM 执行电源操作。在该任务处理完成后（即电源岛关闭后），代码会返回并穿过该框架发回确认信号，完成本次请求。

PMU 框架运行时软件有助于实现系统掉断电模式、管理断电模式并根据需要唤醒系统、维持正确的系统电源状态，并能够在 APU 和 RPU 需要由休眠状态下唤醒时代理执行。

在本框架内， PMU 起到功耗管理服务器的作用。该服务器为所有主控制器提供 API，控制外部功耗管理 IC 和所有功耗域开关，终完成子系统挂起，并能够根据需要唤醒挂起的子系统。

处理单元（APU 和 RPU）是功耗管理主控制器。主控制器能从功耗管理服务器请求开关各种器件的电源、启动并执行子系统挂起，在受到唤醒时执行子系统恢复，并响应来自 PMU 的请求。

下图是 PMU 框架内和框架上的软件层。这些层为应用和低级固件提供不同级别的功耗管理访问。复杂处理单元软件堆栈会使用所有层，而较简单的单元（如裸机）则只使用系统级 API：

在功耗管理 API 的辅助下，该框架和各个层内的全部工作都能够得以实现。功耗管理 API 负责管理以下功能：


图 3-18：功耗管理单元序列


图 3-19：功耗管理框架





• 系统级的挂起处理器单元

• 系统级的从控制器的功耗管理

• 其他系统级功能

• 直接控制系统级功能（读取与写入）

软件开发工具赛灵思可提供多种类型的软件开发工具，使您能够有效地运用 Zynq UltraScale+ MPSoC 器件的各个方面，以发挥您的设计的优势。本部分将概述这些工具，以及它们与 Zynq UltraScale+ MPSoC 器件的丰富软件功能的搭配使用方法。

开发环境和套件

下图显示了主要开发环境，通过它您可以开发在 Zynq UltraScale+ MPSoC 器件上运行的解决方案。

Vivado Design Suite该集成开发环境 (IDE) 是行业首款片上系统 (SoC) 级设计套件，适用设计硬件解决方案。 Vivado® 可提供高层次综合 (HLS) 编译器，用于把基于 C 语言的算法转换为硬件 IP (Vivado HLS)，并具有基于块的 IP 集成工具，使您能够从大型赛灵思 IP 库集成 IP。在系统验证方面， Vivado 具有 Vivado 逻辑仿真器。这是一种混合语言仿真工具，包含能够在目标环境中开展系统调试的逻辑分析器（Vivado 逻辑分析器）。您甚至能够通过工具命令语言 (Tcl) 扩展 Vivado 功能，该命令语言是整个 Vivado 所使用的底层描述语言。


图 3-20：用于 Zynq UltraScale+ MPSoC 器件的赛灵思开发环境





PetaLinuxPetaLinux 是一款全嵌入式 Linux 系统开发套件。该套件包括 Linux 操作系统和一个用于赛灵思芯片的完整配置、构建和部署环境；Linux OS 配置；命令行工具、开发模板（应用、器件驱动程序和库）；调试代理；GCC 工具；一个集成 QuickEMUlator (QEMU) 仿真器；和赛灵思 BSP 软件包。

PetaLinux 可将 Linux 内核、 U-Boot、特定项目组件和项目专用库等组件汇聚一体。组件不必采用 C 语言代码，也可以是用于实现 PetaLinux 项目中特定方面的一系列指令。 PetaLinux 配置实用工具便于您启用或禁用特定组件。

因为 PetaLinux 工具完全基于组件，因此模块化是使用该套件开展设计的一大优势。借助不同组件库，开发人员能在以前设计上迭代，轻松完成设计变体的设计。

PetaLinux 使用“在后台生成”的方式构建项目。

如前文所述，如果您只是寻求一个基本调度器或操作系统以运行 APU 的 A53，但是对 Linux 又不太熟悉，那么 PetaLinux 可能是一个很好的出发点。

赛灵思软件开发套件 (SDK)赛灵思软件开发套件 (SDK) 也是一个集成设计环境 (IDE)，用于在包括 MicroBlaze 软处理器在内的任何赛灵思处理器上创建嵌入式应用。它支持软件的完整开发与调试，既能作为一个组成部分包含在 Vivado Design Suite 中，也能起独立接口作用。该 SDK 基于常见的 Eclipse IDE。

SDK 与 Vivado 硬件设计环境接口，以便 Vivado 能够将所设计的硬件导出到 SDK，并自动为设计创建所需的软件环境，该环境包括 BSP 软件包和驱动程序。

该 SDK 还与编辑器、编译器、构建工具、闪存管理、调试与配置工具捆绑。 SDK 可支持通过单条 JTAG 线缆进行 JTAG 调试。

SDSoC 开发环境

SDSoC™ 开发环境可提供用户熟悉的嵌入式 C/C++/OpenCL 应用开发体验，内含用于异构 Zynq UltraScale+ MPSoC 部署的 Eclipse IDE 和综合设计环境。该开发环境使用 C/C++/OpenCL 全系统优化编译器，可提供系统级剖析、可编程逻辑 (PL) 内的自动软件加速、自动系统连接生成和加速编程的库。 SDSoC 开发环境还能够帮助终用户和第三方平台开发人员迅速定义、集成和验证系统级解决方案，并为他们的终客户提供定制化编程环境。

该开发环境具备下列功能：

• 内置易于使用的 Eclipse IDE，并能够使用嵌入式 C/C++/OpenCL 应用开发完整的 Zynq SoC 和 MPSoC 系统

• 在可编程逻辑中为功能加速

• 可将裸机、 Linux 和 FreeRTOS 用作目标操作系统

• 可提供赛灵思库构成 Vivado HLS 的组成部分，并能够提供来自赛灵思联盟成员的可选配硬件优化库。

有关 SDSoC 开发系统的更多介绍，请访问：https://china.xilinx.com/products/design-tools/software-zone/sdsoc.html。



https://china.xilinx.com/products/design-tools/software-zone/sdsoc.html

https://china.xilinx.com/products/design-tools/software-zone/sdsoc.html



开发人员流程在开发软件解决方案时，开发人员并不限于使用一个环境。相反，可以使用多个环境来创建单个镜像。例如，可使用多个工具为 Zynq UltraScale+ MPSoC 创建可执行闪存镜像：

• Vivado IP 集成器和处理器配置向导 (PCW) 可配置 PS 子系统和 .bit 文件组件。

• SDK 用于创建 BSP、 PMU 固件、 FSBL 和应用镜像，并具有创建合成镜像的 bootgen 实用工具。

• PetaLinux 用于创建开源软件镜像，如 U-Boot、 ATF、 Linux、设备树二进制对象 (dtb) 等。

下面是使用多重设计环境和设计工具的两个设计流。第一个示例用于开发裸机镜像，同时使用了 Vivado 和 SDK。

第二个示例通过使用全部三个开发环境生成 Linux 镜像：


图 3-21：裸机镜像生成





Yocto 项目开发

如果您的团队已熟练掌握 Linux，同时您想完整控制 Linux 的各项功能，那么相比 PetaLinux， Yocto 更加适合您的需要。与 Yocto 项目工具和开发环境配套使用，针对 Zynq UltraScale+ MPSoC 器件的 Yocto 方案可登陆赛灵思 git 服务器访问。

Yocto 的特性包括：

• 通过一套适用于嵌入式环境的系统命令和库，可提供新的 Linux 内核。

• 可提供 X11、 GTK+、 Qt、 Clutter 和 SDL （等等）系统组件，方便您在具有显示硬件的器件上创造丰富的用户体验。对于没有显示器的器件，或是您打算使用替代用户界面框架，就不必安装这些组件。

• 可创建兼容开放嵌入式项目的重要、稳定的核，方便您轻松可靠地创建和开发 Linux 软件。

• 通过快速仿真器 (QEMU) 可支持多种类型的硬件仿真和器件仿真。

下图即为 Yocto 项目开发环境：


图 3-22：Linux 镜像生成





请注意，自 2016.4 版起，前文介绍的 PetaLinux 开发环境拥有完整的 Yocto 后端。

有关 Yocto 与 Zynq UltraScale+ MPSoC 器件配合使用的更多信息，请参阅《Zynq UltraScale+ MPSoC：软件开发指南》 (UG1137) [参照 5]。

多媒体开发工具

下列工具用于多媒体开发：

• 开发人员可使用 PetaLinux 工具链为显示、音频、 GPU 和视频编解码器编译用户模式库和内核模式驱动程序。

• 开发人员可使用 GDB 调试器或 SDK 调试工具在多媒体应用中调试应用代码。

• 在 SDK 内，系统性能分析 (SPA) 可用于剖析多媒体设计。

• SDSoC 开发环境可以生成符合给定 C/C++ 逻辑的 IP，而且能够使用 Vivado Design Suite 为芯片上的特定应用镜像处理器系统生成 FPGA 比特流。请参阅《SDSoC 环境教程：简介》 (UG1028) [参照 9] 查看演示。

• Arm Mali 开发人员工具有助于图形应用开发。

调试

调试可提供系统功能验证、软件评估，并能够尽早在设计进程中检测出难度大、成本高的设计错误，还能够仿真在芯片中难以重现的情况、模拟 Arm A53 和 R5 核，以及 PS 外设。

正如前文所述， IDE 可提供多种调试工具与方法。除了与 IDE 捆绑的调试器，也可以使用其他调试工具：

• 赛灵思 SDK 支持赛灵思系统调试器 (XSDB)。 XSDB 支持所有常见的调试特性，例如设置断点或观察点、单步调试程序执行、查看程序变量与堆栈、查看系统中存储器内容。它还能从同一调试环境里同时调试运行在不同处理器上的多个程序（在多处理器系统内）。例如，系统调试器能通过单根 JTAG 线缆在同一调试会话中显示 APU 和多个 MicroBlaze 软处理器的核。

与 Vivado 逻辑分析器一样，XSDB 也使用赛灵思硬件服务器作为底层调试引擎。这一点非常重要，因为它能够让您开展异构调试。换言之，它能够同时调试软件和硬件。


图 3-23：Yocto 项目开发环境

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





要使用 XSDB 调试应用，您必须使用为调试模式所编译的可执行可链接格式 (ELF) 文件，才能取得调试符号。另外，您必须创建调试会话，其中包括可执行文件名称、将运行的处理器目标和其他信息。启动调试器之后，您可以在GUI 中切换至调试视图。这有助于您管理调试和程序运行。

• PetaLinux 使用 QEMU、 Oprofile、 GDB 和 GNU 调试器作为调试工具。

• Yocto 项目调试工具包括 Perf、 Ftrace、 Oprofile、 Sysprof 和 Blktrace。

• Arm 的 DS-5 Development Studio 使用 DS-5 调试器。该调试器通过应用调试辅助器件初始化。您可以使用 DS-5 调试器在 RTL 仿真器、虚拟平台和硬件上开发代码。

• 部分商用 Linux 版本也支持调试工具。

• Zynq UltraScale+ MPSoC 还支持内置启动测试 (BIST)，其中包括存储器测试 (MBIST) 和逻辑测试 (LBIST)。




第 4 章

电源考虑因素今天的科技市场上，对高复杂性解决方案与更强计算功能的需求与日俱增。随着复杂性的提高和功能的增强，为实现佳运行状态，电源要求也随之提高。系统设计人员、架构师和工程师肩负着降低功耗的重任。本章介绍 Zynq®

UltraScale+™ 器件的功能及其使用的功耗管理相关建议。

定义您的电源需求Zynq UltraScale+ 器件拥有一套极为丰富的功耗管理功能，通过调谐能够满足特定功耗管理需求。因此有必要后退一步，用批判的眼光分析您系统的特定设计要求，从而将它们好地转化为应用于 Zynq UltraScale+ 器件的设计决策。

具体而言，回答下列问题有助于将您的系统功耗管理需求映射到 Zynq UltraScale+ 器件之中：

1. 系统是否需要始终进行处理工作？

2. Zynq UltraScale+ 器件的哪些部分可以关闭？

3. 设计中是否有具体的恢复时间要求？

4. 您系统的部分处理工作是否能够卸载到可编程逻辑 (PL)？




第 4 章：电源考虑因素

电源优化方法在 Zynq UltraScale+ 器件上有五种优化您系统功耗管理的主要方法：

1. 功能禁用

2. 动态功耗管理 (Dynamic Power Management)

3. 频率缩放

4. 时钟门控

5. 使用 PL 加速

前四种方法对嵌入式系统功耗管理而言是常见方法。在这些领域，Zynq UltraScale+ 提供了自己的特定功能。除了这些方法以外，Zynq UltraScale+ MPSoC 器件还帮助设计人员通过 C 至 HDL 工具，将软件任务移植到可编程逻辑中。这种将软件任务转移到协同处理器的做法不仅体现出更高的处理性能，还能提升单位电源性能。

为有效地优化 Zynq UltraScale+ 器件，我们必须首先掌握其功耗管理基础知识。为实现高效率功耗管理， Zynq UltraScale+ MPSoC 器件由四个功耗域组成，如第 67 页的图 4-1 所示。每个功耗域从外部电源调节器接收电源。如果不需要单独的功耗域控制，可以在功耗域间共享电源供电线。

处理器系统有三个主功耗域：电池功耗域、低功耗域和全功耗域。在低功耗域和全功耗域中，有附加的 IP 电源门控选项。

附加的第四个功耗域是可编程逻辑 (PL)。控制通过平台管理单元 (PMU) 实现功耗管理，而可靠的功耗管理控制则是通过三冗余微控制器实现。

通常，电源向量上的要求越高，您就需要花费更多的时间研究 Zynq UltraScale+ MPSoC 器件的功耗管理功能，将这些功能与您的设计要求做对比，然后相应地精细调整您的实现方案。如需了解有关设计向量及其使用方法的更多信息，请参阅第 8 页的“矢量评估法”。

X-Ref Target - Figure 4-1Zy

图 4-1：Zynq UltraScale+ MPSoC 功耗域

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+ 器件功能丰富，您的设计可能不需要使用其全部功能。针对您的电源要求优化 Zynq UltraScale+ 器件，第一步是全面了解 Zynq UltraScale+ 器件的各项功能，并确定哪些功能是您的设计不需要的。然后，您应该考虑本章剩余部分以及相关的 Zynq UltraScale+ 器件技术文档的说明，了解如何禁用您不需要的块或大限度降低其功耗。

例如，您不需要 R5 处理器提供的实时处理功能。在这种情况下，您可以设置 Zynq UltraScale+ 器件以禁用这些处理器。对 A53 进行相同的操作：您可以有选择地禁用 A53 处理器。除计算块外，您还可以禁用 USB 功能等外设块。

您对电源向量的需求越高，您就需要花费更多的时间和精力对尽可能多的 Zynq UltraScale+ 器件的功能进行整理，并使用 Zynq UltraScale+ 器件的功耗管理功能禁用它们。

下列章节详细介绍功耗域与电源岛。

动态功耗管理 (Dynamic Power Management)在您确认需要禁用的多余功能以后，下一步是确认在您的设计中，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 的功耗。

处理器系统使用 APU 和 RPU 两个主要处理器系统级提供功耗或性能缩放，且每级都拥有自己的功耗管理功能。通常情况下，由 Linux 的 CPU 调速器控制 APU 的频率缩放。

当您降低处理组件的频率时，您能够牺牲整体性能换来更出色的功耗性能。如果您的设计不允许这样的权衡，那么您的设计只能考虑采用下文介绍的功能禁用（请参阅第 68 页的“功能禁用”）以及时钟门控。

如需了解更多有关频率缩放的信息，请参阅《Zynq UltraScale+ MPSoC 技术参考手册》 (UG1085) [参照 7] 中的链接。



http://china.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xClocking



时钟门控

另一项可供您用于功耗调节的 Zynq UltraScale+ 器件功能是时钟门控。时钟门控能够对特定组件禁用时钟，从而降低其动态的电源使用。因此，虽然它们的静态电源使用保持不变，也就是说，它们保持上电状态，但它们不再接收时钟信号。

Zynq UltraScale+ 器件的多个组件可以时钟门控。其中包括处理器核、处理器外设以及 PL 软核与硬核。

如需了解有关时钟门控的更多信息，请参阅《Zynq UltraScale+ MPSoC 技术参考手册》 (UG1085) [参照 7] 中的链接。

使用 PL 加速

与 ASSP 不同， Zynq UltraScale+ MPSoC 拥有一项独特功能，它可将软件任务移植至可编程逻辑之中，从而实现动态软件加速及更高的单位电源性能。新一代可编程逻辑能够通过新一代更低功耗的硬 IP 和性能增强的软 IP，提供降低功耗与管理功能。

这些功能为优化嵌入式系统的电源使用开辟了全新途径。实际上，与前文讨论的许多其他优化方法不同， Zynq UltraScale+ 器件的这一独特功能是增强您的系统总体性能并降低功耗水平的唯一途径。因此，赛灵思强烈建议您审核您的系统目标，并决定可以在 PL 中实现哪些功能。

硬件考虑因素

Zynq UltraScale+ 器件的一些功耗管理功能需要板级支持。例如，是否能够对全功耗域进行断电取决于板级支持。例如，需要穿过 GPIO 或 PMBUS 正确连接调节器，以便软件能够控制它们。根据所需灵活性的不同，在可以组合的电源供电线上可能存在一些限制，因而，需要在供电设计的简洁性与 BOM 成本之间进行取舍。因此，板级设计必须谨慎进行，将所需的运行时 PM 功能考虑在内。

软件考虑因素

赛灵思可提供支持降耗模式的软件功耗管理框架。该框架基于行业标准，可支持多种电源模式和子模式，并且可以通过平台管理单元 (PMU) 对其加以控制。该功耗管理框架能够使任何系统软件对功耗管理进行控制，包括裸机运行、传统 Linux 功耗管理及定制的专有软件堆栈。同时通过 Linux 提供示例代码，展示这些模式的使用方法。

总结

下表总结了每种可调试功能对性能、功耗及 PL 占用的影响。

后，电源优化一般涉及在功耗、性能及可用功能间进行权衡。

容量性能功耗 PL 占用

功能禁用 Y Y N

动态功耗管理 (Dynamic Power Management) Y Y N

频率缩放 Y Y N

时钟门控 N Y N

使用 PL 加速 Y Y Y



http://china.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xClocking



四大功耗域前文已经在较高层面上介绍了 Zynq UltraScale+ 器件的四大功耗域。下图进一步详细说明了构成这些功耗域的组件。位于左下角的是电池功耗域，左上角是包含实时处理单元 (RPU) 的低功耗域。右上角是包含应用处理器单元 (APU) 的全功耗域。后，位于底部的是可编程逻辑 (PL) 功耗域：

处理器系统 (PS) 功耗域

处理器系统 (PS) 在三种功耗模式下运行：电池功耗模式、低功耗模式及全功耗模式。

电池功耗模式是功耗低也是简单的模式。它用于保持实时时钟和电池供电 RAM 的正常运行。为电池供电 RAM 供电时，功耗水平为 180 毫微瓦；启用实时时钟时，功耗可达 3 毫瓦。

低功耗模式与实时处理器单元或 RPU 相关联。根据活动水平，功耗范围可低至约 20 毫瓦，并高达 220 毫瓦不等。

全功耗模式与启用的应用处理器单元相关联。根据活动水平，功耗可高达数瓦。从低功耗模式切换到全功耗模式，通常涉及启动或恢复在 APU 上运行的 OS （一般是 Linux）。


图 4-2：Zynq UltraScale+ 器件：四大功耗域





从禁用功能和动态功耗管理的角度来看，上图有助于您了解 PS 功耗域的处理能力与功耗间的权衡取舍。请注意，当每种模式都层叠在另一种模式之上时，可以假定较低的模式处于活跃状态。换句话说，处于全功耗模式下时，可以假定低功耗模式和电池功耗模式均处于活跃状态。

为体现处理功能与功耗间的权衡，比如，为特定任务激活全功耗模式会超出该特定任务的功耗预算。在这种情况下，有必要考虑将相关功能移植到 PL 中。另外，如果功耗在您功耗预算的接受范围之内，则了解全功耗模式下的功耗将有助于更好地分析系统的总体电源使用情况。或者，如果全功耗模式的功耗过高，但您仍然需要激活该模式，可以考虑结合使用频率缩放和时钟门控来进一步优化您的系统功耗。

从恢复时间要求的角度来看，您需要考虑在功耗模式间进行切换所需的时间。例如，如果您的恢复时间起到关键作用，而且必须尽量缩短，那么您需要从电池功耗模式切换到全功耗模式以处理重要输入，并需要确保这个切换时间符合您的需求。例如，您在 APU 上运行 Linux，那么对于特定输入而言，用户空间进程是推荐的处理方法。在这种情况下，您应确保外部事件与该用户空间进程的恢复时间间隔能够符合您的需求。


图 4-3：处理器系统：多种功耗模式





电池功耗域

电池功耗域包括用于存储秘钥的电池支持的 RAM 和实时时钟。

电池供电 RAM 具有 256 位器件秘钥，可选用于数据解密。

实时时钟由 40 位定时器构成，在系统其余部分处于休眠模式时，可作为倒数定时器使用。可对该时钟进行设置（高达 40 位）、定期生成中断，也能够以相对较低频率（相对于系统内其余时钟）检查系统状态。该器件通常连接一个 32 千赫“手表”式晶体振荡器。

一般情况下， Zynq UltraScale+ 器件的电池电源域需要随时保持开启，否则，将需要为 RTC 重新编程，然后下次启用这个电源域（即加电）。


图 4-4：电池功耗域





低功耗域

低功耗域 (LPD) 由使用 R5 处理器的实时处理器单元 (RPU)、静态片上存储器 (OCM)、平台管理单元 (PMU)、配置和安全单元 (CSU) 以及低速外设共同组成：


图 4-5：低功耗域





充满功耗域

全功耗域由使用 A53 处理器的 APU、 GPU、双倍数据速率 (DDR) 存储器控制器以及包含 PCI Express、 USB 3.0、Display Port 和 SATA 在内的高性能外设共同组成。

需要澄清的是，如果低功耗域没有启用，全功耗域就不能启用。因为低功耗域包含全功耗域的一切功耗管理操作所需要的 PMU。


图 4-6：充满功耗域





PL 功耗域

可编程逻辑功耗域包括逻辑单元、块 RAM、数字信号处理 (DSP) 块、AMS、输入/输出及高速串行接口。平台的一些版本包括视频编解码器、 PCI Express Gen-4、 UltraRAM、 CMAC 及 Interlaken。


图 4-7：PL 功耗域





电源岛与电源门控在低功耗域与全功耗域内存在多个电源岛。这有助于在器件内实现局部电源门控，无需外部电源供电线与调节器。

可门控器件包括：

• 低功耗域

° R5 处理器可成对门控。

° 将 TCM 和 OCM 分为四个 bank，可以对每个 bank 进行单独门控或将其维持在保持模式下。

° USB 能够逐个单独门控。

• 充满功耗域

° A53 处理器中的每一个都能单独门控。

° L2 高速缓存

° GPU - 每个像素处理器都能单独门控，同时几何处理器和 L2 高速缓存能共同进行时钟门控。

请注意，除非用 eFuse 禁用，电源岛会首先上电。通过用户代码上电后， PMU 能快速对适当的电源岛断电。

从特性禁用与动态功耗管理两个方面来说，值得花一些时间考虑可用的电源岛以及您的设计是否需要它们、什么时候需要它们。例如，如果您的系统既没有用户界面，也没有 USB 连接，那么您可能想通过指示 PMU 在启动时关闭 USB 和 GPU 电源岛。您还能够根据需要，使用时钟门控来减少一些外设的功耗。

平台管理平台管理单元 (PMU) 负责两大功能：

• 功耗管理

• 安全管理

它包括一个专用的启动 ROM，可以处理上电、断电与复位请求。此外，该 PMU 还支持处理器间中断 (IPI)，以实现系统处理器间的通信。

可将 PMU 处理器连接至使用纠错代码 (ECC) 的 128 KB RAM （用于供数据与固件使用，并可存储赛灵思提供的框架代码）。该 PMU 可提供多种全局寄存器，包括电源寄存器、隔离寄存器、复位寄存器、逻辑清零寄存器、错误采集寄存器及系统电源状态寄存器。这些寄存器都可供赛灵思功耗管理固件使用。





该 PMU 还包含自己的本地寄存器以及专用的中断控制器。接口的存在是为了向 PMU、处理器系统 I/O 和可编程逻辑 (PL) 输入和从其输出数据。

您感觉您的电源要求越高，您就应该花越多的时间研究 PMU 及其功能。

加电时的功能

加电后， PMU 在交接给配置设置单元 (CSU) 之前执行一系列下列事件：

• 使用系统监控器 (SysMon) 提供电源完整性检查，确保 CSU 与 LP 域其余部分的正常运行。

• 初始化 PLL

• 触发并运行存储器内置的自检测 (MBIST)

• 通过 JTAG 可读取采集与信号错误错误

• 通过 eFuse 对任何电源岛及其他禁用 IP 断电

• 释放复位给 CSU

赛灵思 PMU 固件

赛灵思提供的 PMU 固件扩展了 ROM 的既有功能，并为客户提供了附加功能。该固件是为电源与安全管理功能提供的框架，以源代码方式提供，便于定制与扩展。

该固件使用 IP 集成器与其他片上主机进行通信。它处理安全特性，包括错误处理与 RAM 擦除。

PMU 启动 ROM (PBR) 可提供两种中断处理模式：

• 挂接模式

• 完全替代模式

使用第一种模式， PMU 中断能够直接进入 ROM，然后由 ROM 中的中断服务程序 (ISR) 进行处理。


图 4-8：平台管理単元原理图





在第二种模式，即完全替代模式下，处于 RAM 中的代码替代 ROM 内的中断处理程序。该 PMU 固件使用后一种模式实现。

功耗管理软件架构为了让多个处理单元能够在功耗管理领域开展合作， Zynq UltraScale+ MPSoC 器件的软件框架可提供一种用于管理异构多处理器系统的功耗管理 API 实现方案。下图展示了这种基于 API 的功耗管理软件架构。

PMU 运行时软件功能包括：

• 实现系统断电模式

• 在断电模式下管理系统，并使用各种触发机制唤醒系统

• 始终保持系统电源状态

• 在应用处理器和实时处理器休眠状态期间起处理器代理作用，在收到唤醒请求后为处理器加电并重启处理器

如需了解有关用于功耗管理的各种 API 的使用的更多信息，请参阅嵌入式能源接口 (EEMI) API 用户指南 (UG1200) [参照 6]。


图 4-9：功耗管理软件架构





Xilinx Power Estimator赛灵思提供公共可用工具，用于快速估算目标器件的功耗。该工具不仅能提供器件类型、封装、芯片速度等级、温度等级的选择功能，而且还可提供典型或“ 大”芯片的可选估算。该工具能够选择处于活跃状态的处理器核、它们的利用率水平、规划的存储器类型和利用率以及使用的外设类型。与此类似，对可编程逻辑，可选择使用的 IP 块类型、 IP 块的时钟频率以及 IP 块利用率。

如需了解更多信息，请参阅《Xilinx Power Estimator 用户指南》 (UG440) [参照 1]。


图 4-10：Xilinx Power Estimator




第 5 章

可编程逻辑Zynq® UltraScale+™ MPSoC 器件均集成可编程逻辑，包括多个用于在处理器系统 (PS) 与可编程逻辑 (PL) 间实现通信的接口。本章讨论范围的重点是使用 PS 和 PL 之间的接口开展设计时的所有考虑因素。用于管理 PL 各特性间的交互的设计考虑因素不在本章的讨论范围内。但是，彻底了解 PL 的各种特性对设计人员来说至关重要。这些特性的全面介绍请参阅《UltraFAST 设计方法指南 (适用于 Vivado Design Suite) (UG949)》 [参照 4]。

定义您的 PL 需求了解您的 PL 需求是您系统设计的基础部分。根据所选器件，PL 的规模和可用功能会有所变化。但是，首先从系统的角度理解各项需求并选择正确的器件至关重要。各种器件及其 PL 功能请参阅赛灵思 All Programmable 异构 MPSoC 网站上的器件表 [参照 18]。此外，预先定义需求还便于系统设计人员正确选择如何在 PS 和 PL 之间设置通信。

本章假定您已掌握在 FPGA 中使用可编程逻辑开展设计的知识。具体而言，我们假定您已经掌握了如何选择正确尺寸的器件，兼顾您设计中任何定制 IP 和现有 IP 所需的逻辑量。

培训：赛灵思提供综合全面的成套入门文档、培训和教程，供进一步参考。培训信息请见 https://china.xilinx.com/training.html。您可以首先访问 https://china.xilinx.com/products/design-tools/hardware-zone.html，在硬件开发人员专区了解详情。



https://china.xilinx.com/training.html

https://china.xilinx.com/products/design-tools/hardware-zone.html


第 5 章：可编程逻辑

下列问题有助于您定义与 PS-PL 交互有关的需求：

• 您是否需要在 PS 和 PL 之间传输数据？

• 对于向连接在 PS 上的存储器发送数据和从该存储器接收数据，您是否有相关性能要求（吞吐量与时延）？

• 您是否需要在 PS 和 PL 之间进行中断连接？

• 启动时间和/或 PL 配置是否至关重要？

• 您 PL 中的 IP 是否需要接收复位通知？

• 您是否需要 PL 接收来自 PS 的时钟？

• 您是否需要在 PL 中生成可为 PS 计时的时钟信号？

PL 方法作为 PL 在整个系统架构里的作用的说明，下图体现了 PL 及其功能，以及 PL 和 PS 之间的通信接口。

正如前文所述，当前 PL 方法的重点放在 PS 和 PL 之间的交互。如图 5-2 所示，简化但同样准确的原理图有助于说明这一点。

注释：该原理图的目的并不在于准确地表示 Zynq UltraScale+ 器件的内部块。相反，它主要是一张概念图，用于解释当前概念。


图 5-1：Zynq UltraScale+ MPSoC 可编程逻辑





如图所示，器件的 PL 区域间有多种类型的连接。每种类型的连接都具有可能影响设计的重要特性。连接类型包括：

• AXI 接口

• 中断

• 时钟

• EMIO，包括复位（比如通过 EMIO 的 GPIO）

• 专用流

• PMU

• DMA

下面的小节将详细介绍这些内容。


图 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)





AXI 接口

如第 2 章"处理器系统"所述，Zynq UltraScale+ MPSoC 器件中跨组件通信的核机制是 Arm AXI 互联。根据上文的介绍，PS 和 PL 之间存在多条 AXI 链接。基于 Zynq UltraScale+ MPSoC 器件设计您的应用时，选择您在 PS 和 PL 之间使用的 AXI 链接是其中至关重要的决定。为了更好地理解可用选择，下图呈现了 PS 和 PL 之间的共享 AXI 接口的详细视图。

高性能 AXI 主接口

高性能 AXI4 端口提供从 PL 到双倍数据速率 (DDR) 的访问。从 PL 中向外存在六个这样的端口（两个 S_AXI_HPCn_FPD 和四个 S_AXI_ HPn_FPD），并且它们都可以配置为 128 位、 64 位或 32 位。其中两个端口连接到下文提及的高速缓存一致性互联 (CCI)，四个端口直接与 DDR 接口连接，用于访问存储器。

输入 AXI 从控

单个宽度高达 128 位的低时延从接口 (M_AXI_HPM0_LPD) 可提供来自 LPD 的 PS 和 PL 之间的通信。两个输入从接口（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 的一致性，由于 PL 中的加速特性依赖于已加载到 CPU 高速缓存中的数据，该接口是理想的选择。


图 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 一致性扩展 (ACE) 是 128 位的 AXI 从接口 (S_AXI_ACE_FPD)，用于提供 APU 与 PL 中可能的加速器功能间的连接。与 ACP 不同，该从设备端共享对 CCI 的一致性访问。ACE 能够嗅探对 CCI 和 PL 侧的访问，从而在硬件中提供双向一致性。 PL 包括一个到 PS 的主接口。

如需了解有关 PL/PS 通信的更多信息，请参阅《Zynq UltraScale+ MPSoC 技术参考手册》 (UG1085) [参照 7] 中的链接。

选择合适的 AXI 接口

在使用/分配接口时，设计人员必须做出某些权衡取舍。有多个选择能够影响决策。首先是引脚方向（某些是双向的，某些是单向的，可以是来自或指向 PL）。有些接口可以提供一致性，某些接口能够提供保护（出于安全因素而规划在低功耗域 (LPD)），其他一些接口能够提供性能优势（时延和吞吐量）。下表是根据方向和所需功能对可用 AXI 接口的总结。

例如，如果您需要一个即使在 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 个共享外设中断

° 到 APU 的中断：4 个处理器间中断、 4 个 FIQ 和 4 个 IRQ

° 到 RPU 的中断：4 个处理器间中断、 2 个 nFIQ 和 2 个 nIRQ

您可以使用任何输入中断在您的 PL IP 中触发行为，您也可以通过激活任何可用的输出中断，在 PS 内触发中断。您选择哪个媒介终还是由具体应用决定。

双向来自 PL 到 PL

一致性 S_AXI_ACE_FPD S_AXI_HPC0_FPD、S_AXI_HPC1_FPD

不适用

属于 LPD 不适用 S_AXI_LPD M_AXI_HPM0_LPD

性能不适用 S_AXI_ACP_FPD 不适用

通用，非一致不适用 S_AXI_HP0_FPD、S_AXI_HP1_FPD、S_AXI_HP3_FPD、S_AXI_HP4_FPD、

M_AXI_HPM0_FPD、M_AXI_HPM1_FPD



http://china.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xPSPLInterfacing



时钟

如果您需要接收来自 PS 的时钟信号，可以使用由 PL 边界发送的四个时钟中的任何一个。请注意，这些时钟是独立运行的，它们的信号之间并不一定存在时序关系。因此，您的 PL IP 不应依赖来自 PS 的时钟间的隐性同步。

EMIO如第 10 章"外设"中所述，EMIO 机制是一种可将 LPD 外设输出引脚映射到 PL 的方式。此外，EMIO 还可作为将 LPD 双向链接到 PL 的简单方法。例如，通过映射 LPD GPIO 输出到 PL 功能，它能从 PS 生成供 PL 使用的复位。请注意，在 PS 和 PL 之间不存在专用复位。

IP 专用数据流

像 LPD 中的千兆以太网控制器以及 FPD 中的 DisplayPort 等某些功能，都具有来自和指向 PL 的专用数据流。有关千兆以太网控制器的讨论请参见外设一章。 DisplayPort 的讨论请参见多媒体一章。如需了解有关这些外设如何与 PL 进行交互的具体详情，请参阅《Zynq UltraScale+ MPSoC 技术参考手册》 (UG1085) [参照 7]。

PMU该 PMU 和 PL 共享多个信号：

• 32 位通用输入 (GPI) 和通用输出 (GPO)

• 针对 LPD 和 FPD 的 AIB 请求和确认信号

• 将来自 PL 的 4 个错误输出作为 PMU 输入

• 来自 PS、向 PL 指出错误的 47 个输出

如果您需要您的 PL IP 在 PMU 中与任务关键型应用紧密协调，那么这些信号就对您有所帮助。

DMAFPD-DMA 和 LPD-DMA 都能在 PL 中提供流控制信号。如需了解有关 DMA 控制器的更多信息，请参阅第 6 章"存储器"。

逻辑本节介绍由查找表 (LUT) 和触发器构成的 PL 功能。设计人员能够实现定制 RTL 并使用赛灵思工具为它们编程。为将它们连接到 PS 上，设计人员必须在所有逻辑上实现 AXI 接口，以便与 PS 进行通信并传输数据。如果需要与 PS 进行通信的接口超过一个，那么设计人员应例化 AXI 互联 IP，让多个主控制器与多个从设备进行通信。包含 AXI 互联 IP 将增加用于连接的逻辑数量。提前规划可确保逻辑资源的佳使用。

可用工具、方法学和库能够支持您通过 PL 中的逻辑资源开展设计，本节将对其展开整体介绍。

注释：有关有助于设计您器件各个方面的赛灵思工具的总体介绍，请访问开发人员专区。



https://china.xilinx.com/products/design-tools.html



Vivado Design SuiteVivado® Design Suite 集成开发环境 (IDE) 是业界首款适用于设计硬件解决方案的 SOC 级设计套件。它包括下列组成部分：

• Vivado HLS：可将基于 C 语言的算法转换为硬件 IP 的高级综合编译器。

• Vivado IP 集成器：从大型赛灵思 IP 库集成 IP 且基于块的 IP 集成工具。

• Vivado 逻辑分析器：包括可在目标环境中开展系统调试的逻辑分析器（Vivado 逻辑分析器）的“混合语言仿真工具”。

• TCL：Vivado 中使用的整体底层脚本编写语言，即工具命令语言。

• 赛灵思软件开发套件 (SDK)：用于在任何赛灵思微处理器（包括 MicroBlaze™ 软核微处理器）上开发嵌入式应用的另一种 IDE。您可以使用赛灵思 SDK 来生成由您的 FPGA 运行的应用。赛灵思 SDK 可作为您 Vivado Design Suite 安装的一部分进行安装。如需了解有关赛灵思 SDK 的信息，请参阅赛灵思软件开发套件网页 [参照 14]。

由于 Vivado 是一个完整的 IDE，它能对您 FPGA 中所需的全部逻辑进行端到端开发，包括支持创建用于配置 PL 的加密比特流。 Vivado 可加速高级设计、验证和实现过程。赛灵思提供多个 Vivado 版本（HL System、 HL Design 和 HL WebPACK™）。如需了解有关 Vivado 的更多信息，请参阅 Vivado Design Suite 网页 [参照 15]。

隔离设计流程

赛灵思隔离设计流程 (IDF) 的开发目的在于，支持独立功能在单个 FPGA 上以分区方式运行。例如，在使用红/黑概念的解决方案里，功能与数据的永久性物理分离至关重要，因为这种概念需要确保敏感（红色）和非敏感（黑色）数据或功能永远不会彼此侵犯。

IDF 是一种基于现有实现工具流程的方法。利用现有约束工具 (PlanAhead/Vivado GUI) 对设计进行进一步布局规划。工作成果的验证（管脚和布线设计）通过另外的独立工具（对 ISE® Design Suite 或 Vivado 分别使用 IVT 或 VIV）完成。

使用 IDF，您可确保在可编程逻辑 (PL) 中将所有实现的 IP 都进行划分，从而满足资源隔离和安全需求。赛灵思提供示范 IDF 的多个参考设计。您可以在隔离设计流程网页上获取 IDF 的相关信息 [参照 16]。

运用该赛灵思分区技术，能够在单个 FPGA 上开发出包含多种隔离功能的安全单芯片解决方案。SCC_ISOLATED 等特殊属性及其实现的各项功能，为实现满足认证机构要求的隔离提供了必要控制。为更好地理解 IDF 细节，设计人员需要充分掌握标准分区设计流程。分区流程中的许多名词和流程也适用于 IDF。并在赛灵思提供的应用指南中列出了与分区设计流程中不同的部分：

注释：《赛灵思 7 系列 FPGA 或 Zynq-7000 SoC （Vivado 工具）隔离设计流程》应用指南通过 Vivado Design Suite 介绍 IDF。虽然应用指南针对的是 Zynq-7000 SoC，但其概念对 Zynq UltraScale+ MPSoC 同样适用。

在 IDF 方法中，主要概念为在 FPGA 内创建隔离区域。下图显示了一个示例设计。



https://china.xilinx.com/support/documentation-navigation/application-notes.html



本示例 FPGA 拥有一个 I/O Bank、一个比较 (Compare) 逻辑块、一个高级加密标准核 (AES) 以及一个冗余 AES (AES_R)。每个区域都在逻辑上独立并彼此“分区”。每个逻辑块间只能存在受控和可信通信。

您只需在使用 FPGA 设计技术和编码方式时，对传统 FPGA 开发流程做适度调整，就能实现安全关键型解决方案。 IDF 开发要求您在设计进程中更早地考虑布局规划，以确保在逻辑、布线和 I/O 缓存 (IOB) 中实现正确隔离。此外，开发流程是基于分区的（即用户想要隔离的每一项功能都必须处于自身层级内）。

此时，您可以采取以下两种方法之一：

• 如果您想尽量避免对冗余的不必要优化，那么您必须综合每一项隔离功能并独立于其他分区将其实现。在您实现每一个分区后，设计合并入扁平化的 FPGA 工程，实现器件配置。

• 如果您想使用其他方法阻止这种优化，您可以在综合整个设计的同时细致地保持至少一个层级，从而使 IDF 约束能应用到要求隔离的每一个分区。

虽然这种开发流程要求您突破传统 FPGA 开发流程，但分区方法确实具有一定优势。如果受隔离的分区要求在设计周期后期进行更改，只有这项特定功能会被修改，其余分区均保持不变。

注释：除全局时钟、复位和 IOB 外，所有逻辑应隶属于一个隔离分区。

图 5-5 展示了典型 FPGA 设计流程，图右为纳入考量的额外 IDF 步骤。您务必确保同时兼顾层级分区和逻辑分区。所有这些考虑因素都能确保您的功能彼此独立，不会相互破坏。您可以使用 IDF 验证工具 (VIV) 帮助布局规划约束和验证设计。


图 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





赛灵思知识产权

赛灵思及其合作伙伴拥有丰富的知识产权 (IP) 库，该库经格测试，可供您用于开发 FPGA。该库由下列涵盖 IP 的门类构成：

• 接口和互联

• 通信

• IP 小工具

• DSP 和数学

• 存储器和控制器

• 器件系列

• 嵌入式


图 5-5：隔离设计流程





• 音频/视频成像

• 特定市场专用 IP

您可以访问该链接浏览 IP 库：https://china.xilinx.com/products/intellectual-property.html。

正如第 86 页的“Vivado Design Suite”中所提到的， Vivado IP 集成器通过基于 AXI 的通用用户界面，能实现快速 IP 连接。该工具能够将设计工作减少数月。 IP 库同时还包含 IP 子系统，可将多个 IP 集成到一个解决方案中。

集成 IP 支持PL 中包含针对 PCI Express、 Interlaken、 100G 以太网、系统监控器和视频编解码单元的集成块。对这些块的使用取决于您的应用用例。以下小节对这些 PL 外设进行了简要介绍。

如需了解有关对这些器件外设支持的信息，请参阅《Zynq UltraScale+ MPSoC 技术参考手册》 (UG1085) [参照 7] 中的链接。

PCI ExpressFPGA 可实现传输事务层、数据链接层和物理层功能，从而以小 FPGA 逻辑利用率提供完整 PCI Express 端点和根端口功能。

这些功能为构建 Root Complex 奠定了基础，该 Root Complex 可使用 PCI Express 协议实现定制芯片间通信，同时还能将 ASSP 端点器件连接到 MPSoC （例如，以太网控制器或光纤 Fiber Channel HBA）。根据您的系统设计要求，您可以将该块配置为在 1、 2、 4、 8 或 16 通道上以高达 2.5 Gb/s、 5.0 Gb/s、 8.0 Gb/s 或 16 Gb/s 的数据速率运行。

InterlakenInterlaken IP 专为高带宽、可靠的数据包传输进行了优化。此 IP 可提供芯片级互联协议，能实现通道逻辑和协议逻辑。协议逻辑能扩展到高达 150 Gb/s。您可以使用 12.5 Gb/s 将该逻辑配置为多达 12 个通道，或是高达 25.78125 Gb/s 的 1 到 6 个通道。利用多个 Interlaken 块，某些基于 UltraScale 架构的器件能实现简便可靠的 Interlaken 路由器和桥接器。

100G 以太网

符合 IEEE 802.3ba 标准的以太网集成块可提供低时延 100 Gb/s 以太网端口，具有各种用户定制的解决方案和统计数据收集功能。 Zynq UltraScale+ MPSoC 100G 以太网块中包含 Reed-Solomon 前向纠错 (RS-FEC) 块，该块符合 IEEE 802.3bj 标准，您既可与以太网块结合使用，也可在独立用户应用中使用。

系统监控器

根据第 8 章"安全性"中的介绍，系统监控器块通过使用片上电源和温度传感器检测物理环境，用来强化总体安全性与可靠性。您可使用系统监控器来监测电压、测量电流、测量传感器输出，并且在缺少连接所需外部模拟信号的 IO 端口时，还可以在外部多路复用器模式中使用。

PL 中的系统监控器使用 10 位精度、每秒 1 兆采样率 (MSPS) 的 ADC 将传感器输出数字化。测量结果存储在寄存器中，并由 PS 中的处理器和 PMU 通过使用高级外设总线 (APB) 接口进行访问。请注意， PL 中的系统监控器也可用作通用 A/D 转换器。



https://china.xilinx.com/products/intellectual-property.html





视频编解码单元

Zynq® UltraScale+™ MPSoC EV 系列中视频编解码单元 (VCU) 可提供多标准的视频编码解码功能，如支持高效率视频编码 (HEVC) H.265 标准和高级视频编码 (AVC) H.264 标准。 VCU 是特定 Zynq UltraScale+ MPSoC 的 PL 中的集成块，不提供到 PS 的直接连接。 VCU 是以寄存器可编程的方式工作。

如需了解更多有关 VCU 的信息，请参阅第 9 章"多媒体"。

配置和部分重配置如第 3 章"系统软件考虑因素"和第 8 章"安全性"所介绍，PL 由 FSBL 在启动时使用 CSU 的 PCAP 来配置。有时，可能只需要 FSBL 在启动过程中加载部分 PL。随后，有必要在系统生命周期里继续对 PL 进行部分重配置。

本质上，部分重配置是通过下载部分比特流来动态修改逻辑块，同时让其余逻辑继续无间断运行的能力。为达成这一目的，您必须执行多个配置，终为每种配置实现完整比特流，以及为部分重配置中涉及的每个模块实现部分比特流。所需的配置数量随需实现的模块数量而变化。

如需了解有关部分重配置的更多信息，请参阅

• 《Vivado Design Suite 教程：部分重配置》 (UG947) [参照 3]• 部分重配置网页 [参照 17]

• 所有配置均使用相同的顶层或静态、布局及布线结果。这些静态结果从初始配置导出，然后由所有后续配置使用检查点导入。

FPGA 技术可提供现场编程和重新编程的灵活性，在进行设计修改时，无需开展重新架构。部分重配置推动这一灵活性进一步发展，允许通过加载部分重配置文件（通常是部分 .bit 文件）来修改工作中的 FPGA 设计。在使用完整的 .bit 文件配置 FPGA 后，可下载部分 .bit 文件以修改 FPGA 中的可重新配置区域，而不影响运行在未被重新配置的器件部分上的应用的完整性。

部分重配置的基础概念是：为您想要现场加载的一切内容创建比特流（全部或部分）。理想情况下，您应该知道当 Zynq UltraScale+ MPSoC 在现场运行时需要配置哪些模块。


图 5-6：部分重配置

FPGA

ReconfigBlock “A”

A4.bitA3.bit

A2.bitA1.bit

X12001





功耗降低功能可编程逻辑 (PL) 采用更精细的 20 nm 和 16 nm 工艺，以达到节省功耗目的。虽然佳电压调节是提高单位功耗性能的主要实现手段，赛灵思还对首次采用 20 nm 工艺的架构块做出了大量增强功能。此外，赛灵思还在 16 nm 工艺方面推出多种全新技术，例如 UltraRAM、新 PCI Express Gen4 和新型 I/O bank。

每种独特设计的总功耗源自四大方面，分别是静态功耗、动态功耗、收发器功耗以及 I/O 功耗。这些功耗的混合与搭配，取决于实际使用的资源、频率、温度和负载。在比较赛灵思 28 nm 产品和基于 UltraScale+ 架构的 FPGA 时，所有功耗来源的功耗都有降低。因此，您可以降低 PFGA 功耗预算高达 50%，或者在保持功耗预算不变的情况下，您可以在相同的 FPGA 功耗预算下实现更高的系统性能。

这些大幅度进步是通过基于 UltraScale+ 架构的 FPGA 中的多项创新来实现。例如，赛灵思对收发器架构进行重新设计，使其比上一代收发器的功耗降低了 50%。在基于 UltraScale+ 架构的 FPGA 中继续采用多模式 IO 模式，可在高性能存储器和 LVDS 接口中显著降低功耗。精细粒度时钟门控等功能与 Vivado IDE 无缝协作，能使逻辑中的动态功耗显著下降。此外， Block 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 章"处理器系统"中的处理器系统方法。更具体地讲，您应掌握了如何在 Zynq UltraScale+ MPSoC 器件的主要处理块间细分您设计的总体理念，如第 2 章所述。

以此为基础，下列问题将帮助您为根据您的需求自定义 Zynq UltraScale+ MPSoC 器件的存储器功能做好准备：

• 在任一时间点上您设计的每个部分需要多大的存储器？

• 与其他部分相比，有什么样的动态存储器带宽需求？

• 为了安全地隔离处理块，您是否需要对您的处理进行分区？

• 您所管理的数据中是否存在始终需要安全存储的？

存储器方法Zynq UltraScale+ MPSoC 器件包含多种类型的存储器块，以及 Zynq UltraScale+ MPSoC 器件的处理块和存储器间的多种路径。第 1 章"引言"中介绍的架构图提供了系统与所涉及的存储器组件的完整视图。就当前探讨目的而言，我们准备使用 Zynq UltraScale+ MPSoC 器件的简化概念视图来重点介绍与存储器相关的主要器件和它们的关系。

注释：本视图的目的并非准确表示 Zynq UltraScale+ MPSoC 器件的内部。相反，它主要作为概念视图，用于当前的解释说明目的。

具体而言，我们将参与存储器交互的组件分为下列三个大类：

• 用户：在任意位置以某种方式访问存储器的块。

• 仲裁器：对通过的存储器访问做筛选或调整的块。

• 提供器：提供实际存储器存储的块。

下图展示了其中一个类别中部分相关 Zynq UltraScale+ MPSoC 器件块，蓝色箭头代表内存引用后续的典型流程：




第 6 章：存储器

注释：请注意，本视图的目的并非准确表示 Zynq UltraScale+ MPSoC 器件的内部。相反，它主要作为概念视图，用于当前的解释说明目的。

简言之，在实际抵达存储器提供器之前，用户一般会经过一个或多个仲裁器。也有一些例外情况。 RPU 包含紧密耦合存储器 (TCM)，可通过低时延链接直接访问 RPU 中的 R5。此外，处理逻辑 (PL) 可通过编程来仲裁对外部存储器的访问，并内部从 PL 的其余部分提供可用的存储器，或是由系统其余部分提供存储器（较为罕见）。

存储器操作与访问受到 Zynq UltraScale+ MPSoC 器件互联的严密管理，具体介绍见第 2 章"处理器系统"。如需了解有关开关服务质量 (QoS)、高速缓存一致性互联 (CCI) 的作用，以及如何在需要时按自身需求微调互联 QoS 的更多信息，请参阅此章节。赛灵思内存保护单元 (XMPU) 实际上就是用于过滤存储器访问的安全块，相关详细介绍请参阅第 7 章"资源隔离以及分区"。

对大部分应用来说，大小为 256 KB 的片上存储器 (OCM) 和每个大小为 128 KB 的 R5 双 TCM 很有可能并不足以构建全功能系统。相反，您设计中或总会包含外部存储器。因此，确定您设计中要使用的外部存储器的大小，是您的团队需要做出的重大决策之一。此外，您需要解决的另一关键问题就是：您是否需要高于默认 DDR 控制器 (DDRC) 所能提供的带宽。使用 DDRC 的大 19,200 MB/s 的带宽已经能满足大部分应用的需求。了解您的应用如何利用这一带宽以及在您需要更大带宽时可做的选择至关重要。

根据经验法则，如果您的应用所需的带宽是 DDRC 大带宽的 60% 左右或更小，那么在存储器方面就可以直接使用 Zynq UltraScale+ MPSoC 器件。如果您所需的带宽是该带宽的 60% 到 80%，那么您应该会使用赛灵思软件开发套件 (SDK) 中的系统性能监控 (SPM) 工具，为您在 Zynq UltraScale+ MPSoC 器件上的内存使用进行建模，从而更好地掌握系统如何在您的工作负载下运行。该 SDK 的介绍见第 28 页的“自定义 QoS”，详细介绍见第 3 章"系统软件考虑因素"。但是，当您使用到 90% 的带宽，您更有可能需要额外的外部存储器控制器。这样的控制器可以在 PL 中实现，将 PL 作为存储器访问的仲裁器，如上图中所示。虽然大部分应用并不需要这样的配置，但是在涉及视频处理或 UltraHD 的系统中，很有可能需要额外的存储器控制器。

外部存储器需求也受尺寸和 ECC 考虑因素影响。


图 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 器件包含多个针对不同使用场景的內建存储器和存储器功能块。本节将介绍这些块及其典型用途。

片上存储器

处理器系统 (PS) 中的片上存储器 (OCM) 的大小是 256 KB。不能通过 DDR 控制器访问 OCM。OCM 存在来自 PL 和 PS 的接口。后者既能从全功耗域 (FPD) 访问 OCM，也能从低功耗域 (LPD) 访问 OCM。

使用 OCM 存储器而非 DDR 的原因之一是为了实现更高性能，因为 OCM 的时延比 DDR 控制器能提供的水平少几个周期，而且它具有比 DDR 更高的带宽。因此，在要求存储器访问速度但尺寸可能受限的情况下，策略性地使用 OCM 可能有所帮助。优化使用 OCM 以实现高性能的途径之一在于，严格将其用于存储数据而非代码。随后，您可以从外部存储器运行代码，或在少有情况下，您没有使用外部存储器或是想将外部存储器用于其他用途，您也可以使用 eXecute-In-Place (XIP) 策略，让代码直接从基于 Quad-SPI (QSPI) 上的存储运行。

使用 OCM 而非外部存储器的另一个原因是安全性。由于 OCM 内建于 Zynq UltraScale+ MPSoC 器件中，因此入侵者无法从各个处理块与 OCM 间的传输中轻松嗅探数据。因此， OCM 是安全存储加密秘钥和敏感信息等重要瞬态数据的理想位置。如果要存储的对象对于 OCM 而言过大，那么它们可使用存储在 OCM 中的临时秘钥进行加密，然后把加密后的对象发送到外部存储器存储。在这种情况下，存储在外部存储器中的加密对象始终保持安全，因为访问它们所需的密钥限制在 OCM 内。

通常，运行在应用处理单元 (APU) 和实时处理器单元 (RPU) 上的软件能够访问 OCM 满足自身用途。此外，还存在其他使用 OCM 的具体情况。例如，无论系统是否在安全模式下启动，第一阶段启动加载器 (FSBL) 在启动进程配置阶段把用于启动 PS 的代码加载到 OCM 中。此外， OCM 也用于通过 JTAG 为非易失性闪存编程。在 JTAG 启动模式下，负责为闪存编程的程序先加载到 OCM 中，然后接管闪存进程。





编程逻辑存储器

可将 PL 配置为可提供三种不同类型的存储器块。虽然 PL 中可用的存储器数量有限，但与外部存储器相比，内部存储器功耗更低，访问速度更快。此外，它也对 PL 中的硬件设计至关重要。因此，把 PL 的部分存储器功能配置用于 Zynq UltraScale+ MPSoC 器件处理块的一般用途，应是后手段。

PL 内的三种存储器类型有不同的特性，但它们都能使用赛灵思开发工具在 FPGA 设计中实例化。

BRAM块 RAM (BRAM) 存储器是一种在以往的赛灵思 FPGA 处理器上已经提供的存储器类型。块 RAM 为 PL 组件提供少量可用存储器。块 RAM 是 36 KB 大小的块，根据具体器件类型，Zynq UltraScale+ MPSoC 器件能在 PL 包含高达 35 MB 的块 RAM。块 RAM 单元既可用作两个独立的 18 KB 块，也可用作单个 36 KB 块。它可配置为使用双端口或者单端口。此外，多个块 RAM 块也能链接在一起，当作一个独立的单元使用。

UltraRAMUltraRAM 是一种用于 Zynq UltraScale+ MPSoC 器件的 FPGA RAM。每个 UltraRAM 块的大小是 288 KB。 Zynq UltraScale+ MPSoC 器件上提供大容量为 128 MB 的 UltraRAM。 UltraRAM 密度比块 RAM 大，在 FPGA 架构中使用它更节省空间。 UltraRAM 器件密度的提升也带来了低于块 RAM 的功耗。

LUTRAM在 Zynq® UltraScale+™ MPSoC 上存在有限数量的 LUTRAM 或分布式 RAM。分布式 RAM 是在 PL 中用 LUT 原语构建的存储器块。如果对存储器的需求较低，或想避免使用块 RAM 带来的时延，那么 PL 设计人员可以使用分布式 RAM。

紧密耦合存储器 (TCM)紧密耦合存储器 (TCM) 是连接实时处理器 (RPU) Cortex R5 处理器核的 4 个 64 KB 的存储器的 bank。TCM 允许 RPU 优先访问提供确定性能和低时延访问的存储器。

正如第 2 章"处理器系统"所述，R5 处理器可设置为分离 (Split) 模式下或锁步 (Lock-Step) 模式下运行。默认运行模式为分离模式。在这种模式下，每个 Cortex-R5 处理器包含两个 64 位宽的 64 KB 存储器 bank，分别调用 ATCM 和 BTCM 端口，总共提供 128 KB 存储器。将 TCM 分为两个部分便于 R5 CPU 或 AXI 接口并发访问存储器 bank。在锁步模式下，TCM 可合并到单个 256 KB 大小的区域。为了实现 RPU 与 PS 其余部分的通信，TCM 存储器也被映射到全局系统地址映射， APU 或任何能访问该映射的其他 AXI 主控制器都可以访问该映射。下图展示了访问 TCM 存储器的不同方式。

注释：全局系统地址映射的探讨见第 97 页的“全局系统内存映射”。





虽然 TCM 是映射在 APU 地址空间内，但 RPU 始终会通过直接的低时延路径访问 TCM，不会穿过本章前文介绍过的任何存储器仲裁器。

PS DDR 存储器和控制器Zynq® UltraScale+™ MPSoC 的 PS DDR 子系统通过第 2 章"处理器系统"介绍的互联，使用六个 AXI 接口与系统其余部分相连。DDR 子系统可支持多种存储器标准 (DDR3、DDR3L、LPDDR3、DDR4、LPDDR4) 并支持 UDIMM 和 RDIMM。可支持的 DRAM 总容量为 32 GB。


图 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





有关互联如何运行以及如何自定义 QoS 的更多信息，请参阅第 2 章"处理器系统"。上图展现的“QoS 控制器”使用基于开关的 QoS 和基于 CCI 的 QoS 实现配置的策略，两种 QoS 的具体介绍请参阅本章中的相应内容。

全局系统内存映射Zynq UltraScale+ MPSoC 器件的全局系统地址映射空间容量为 1 TB，可为服务多种类型的 AXI 主控制器定制。例如，RPU 的 R5 为 32 位处理器，而 APU 的 A53 为 64 位或 32 位处理器。因此，基本上 64 位模式下的 A53 比 R5 能寻址到更多的存储器。32 位处理器的大寻址空间高达 4 GB，而理论上 64 位处理器的大寻址空间可达 16 EB。但实际上，ARMv8-A 只支持大 48 位寻址。系统存储器映射同时兼容这两种类型的 AXI 主控制器，并且经配置能支持 32 位、36 位或 40 位的系统地址。

页表转换要求存储器管理硬件遍历页表，从而在转换阶段间转换地址。地址空间越大，遍历的页表就越多。例如，当使用 4 KB 大小的页表时，40 位宽的地址需要遍历 4 个页表，36 位宽的地址需要遍历 3 个，而 32 位宽的地址需要遍历 2 个。因此，即便是在能够处理较宽地址空间的处理器上，使用较少地址位来加快存储器访问速度也能带来好处。

Zynq UltraScale+ MPSoC 器件的系统地址如下所示，支持 32 位主控制器，同时支持对 64 位主控制器进行优化的 36 位访问。


图 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





注释：该地址映射大小有 16 艾字节，也就是 16*1,024 拍字节或 16*1,024*1,1024 太字节。

通过将必要系统组件（包括 DDR）映射到 32 位控制器可访问的 32 位地址空间，Zynq UltraScale+ MPSoC 器件可确保这些控制器能够利用大部分片上外设与功能。除此之外， 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 器件包含两种通用 DMA 控制器和多种外设专用 DMA 引擎。前者支持存储器间、存储器到 I/O、 I/O 到存储器和 I/O 到 I/O 间传输。后者的详细介绍请参阅第 10 章"外设"。此外，赛灵思还在 IP 目录中提供多种 PL DMA 核。

一个通用控制器位于全功耗域内 (FPD-DMA)，另一个位于低功耗域内 (LPD-DMA)。两个通用 DMA 控制器完全相同，管理在内部共享公共缓存的 8 条独立 DMA 通道，以大限度地利用 AXI 带宽。两个控制器均可支持 QoS、TrustZone、 OverFetch 和非对齐传输。其均能发出用于通知目的的中断并可支持两种传输模式：简单 DMA 和散集 DMA。

两个控制器间的差异在于公共缓存的大小。FPD-DMA 与 128 位 AXI 总线相连，并使用 4K 内部公共缓存。LPD-DMA 与 64 位 AXI 总线相连，并使用 2K 公共缓存。公共缓存由控制器自动管理，但编程人员可通过微调每个通道的速率控制器和读取-发出寄存器对每个通道的缓存使用情况产生影响。


图 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





两个控制器间的另一个差异在于 LPD-DMA 具备 I/O 一致性但 FPD-DMA 不具备。 LPD-DMA 传输具备 I/O 一致性的原因在于它们经过了 CCI，而 FPD-DMA 直接去往 DDR，未经过 CCI。因此，如果要确保一致性， FPD-DMA 传输需要软件支持。

下图展示了每个通用 DMA 控制器的内部结构：

简单 DMA在简单 DMA 模式下，传输命令以单条指令方式发出给控制器。这种 DMA 请求的编程模式可总结如下：

1. 在 DMA 通道寄存器内编程数据传输源地址和目的地地址。

2. 在同一通道寄存器内编程源大小和目的地缓存。

3. 如果需要，在通道内启用中断。

4. 启动 DMA 传输。

如果启用中断，那么不仅在 DMA 控制器完成读取存储器时会生成中断，而且一旦执行完写入目的地后还将生成另一个中断。

如果请求的 DMA 读取超出存储器页面边界， DMA 控制器可选择性地按指令要求，取回剩余数据直至边界。这就是 OverFetch 功能。在禁用该功能后，可使用多次单字节读取完成对不完整存储器页面的请求。

此外，简单 DMA 模式有两种子模式：

• 只读模式：在只读模式下， DMA 通道从存储器读取数据但不写入任何地方。这种模式可用于擦除存储器，以纠正潜在的纠错代码 (ECC) 错误。


图 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 通道寄存器预加载的数据到存储器。这是一种快速初始化存储器块的捷径。

分散聚集 (Scatter-Gather) DMA散集 DMA 具备更复杂的操作模式。在已格式化的缓存描述符 (BD) 中指定数据源和数据目的地。该 DMA 控制器可支持三种不同的描述符格式，以满足不同需求：

• 线性格式：线性 BD 以线性阵列存储。每个 128 位描述符包含用于 DMA 传输的源地址和目的地地址。

• 链表格式：链表 BD 宽 256 位，包含与线性描述符相同的信息，但是它们还包含下一个 BD 的地址，而这个地址可位于存储器内的任何地方。

• 混合格式：在混合模式下两种类型的 BD 可以混用。一种可以同时使用这两种格式的有意思的方式是只在存储器页面边界上使用链表 BD，在页面的其余部分使用线性 BD。

下图展示了这三种格式。

散集 DMA 也可支持中断。使用特殊的计数寄存器来维护生成的中断数量。对于每个被 DMA 控制器处理的描述符，该寄存器计增一次。应用不仅可查询寄存器，了解 DMA 传输状态，而且还可根据需要重置该寄存器。


图 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如前文所述， Zynq® UltraScale+™ MPSoC 上的高速外设配有自己的 DMA 控制器。每个外设 DMA 的特性均针对特定外设，详细讨论见第 10 章"外设"。下表总结了每个高速外设的 DMA 相关信息。

使用与编程

一般情况下，运行在第 2 章"处理器系统"中介绍的任何处理单元上的 OS 和/或驱动可编程和接口各种 DMA 控制器。因此，分析如何好地使用 DMA 以及对它们的资源进行分区，应该成为您整体软件设计的一个环节。此外需要注意的是，和 AXI 总线上的众多其他组件一样，DMA 控制器也是 AXI 主控制器。因此，使用第 2 章中介绍的用于 QoS 微调的方法同样可以对 DMA 流量进行优先级排序。

使用 PL 接口外部存储器如前文所述，使用 Zynq UltraScale+ MPSoC 器件的 PL 可接口外部 DDR 存储器。使用赛灵思专用 IP 块生成器就能实现。存储器接口生成器 (MIG) 用于生成需要集成到 FPGA PL 架构中的块。 MIG 能为多种类型的动态 RAM 生成接口：

• DDR3/DDR4

• QDR II+

• QDR-IV

• RLDRAM

对于 DDR3 和 DDR4， MIG 可生成类似于这里展示的结构：


图 6-7：外设 DMA 支持





物理层 (PHY) 处理 DDR 存储器工作所需的低级信号。它处理校准并生成读取和写入存储器所需的准确定时信号。此外，它还在上电时处理 RAM 的初始化。存储器控制器 (MC) 可处理来自用户接口的读取和写入传输事务请求并将它们布线到物理层。必要时它还处理存储器 ECC 功能。

因此， MIG 允许开发人员通过 PL 块对额外的外部存储器进行访问。该功能可用于让 PL 独立于系统其余部分使用存储器，或通过适配支持与其他组件共享外部存储器。例如，内建在 PL 中的视频编解码单元 (VCU) 经设置，就能使用软 DDR 控制器提供的额外存储器。正如前文所述，另一种通过 PL 扩展存储器的方法是运用 Zynq UltraScale+ MPSoC 器件的 PS DDR 控制器，实现比该器件所具备的大 19,200 MB/s 访问带宽更高的外部存储器访问带宽。


图 6-8：存储器接口生成器生成的典型块

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

• • • • • • •• • • • •




第 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 上完成的工作彼此隔离？

• 根据您设计中所属的子系统，您是否需要对特定的外设和/或存储器进行限制或控制？例如，您是否需要确保：

° 只有 APU 可以访问 DisplayPort？

° 只有 RPU 可以访问控制器区域网络（CAN 总线）？

° RAM 的特定段只供 RPU 使用？

资源隔离以及分区方法了解 Zynq UltraScale+ MPSoC 器件的资源隔离与分区功能以及如何好地使用它们涉及几种系统组件。和其他章节一样，这里的方法介绍是为您呈现在后续章节中理解深度讲解所需的主要概念。即使您不清楚如何立即回答上一节提出的问题，但这样做能助您更好地理解是否需要以及如何能够将您的设计划分为独立的、可保护的子系统。

本指南前文中已通过多种不同方式介绍了 Zynq UltraScale+ MPSoC 器件的资源和块。就当前讨论目的，我们将把 Zynq UltraScale+ MPSoC 器件中与资源隔离与分区有关的组成部分划为三大类，具体如下图所示。




第 7 章：资源隔离以及分区

注释：这些分类与相关示意图目的并非在于准确表示 Zynq UltraScale+ MPSoC 器件的内部块。相反，它主要是一张概念图，用于解释当前概念。

上图所示的三大类具体有：

• 处理块和通用直接存储器访问 (DMA)

包括所有初始化和控制大部分与 Zynq UltraScale+ MPSoC 器件有关的访问、传输与通信的块。

• 外设

包括来自所有功耗域的外设；主要有低功耗域 (LPD)、全功耗域 (FPD) 以及内置在 PL 中的所有外设。

• 存储器

包括所有内置并可供 Zynq UltraScale+ MPSoC 器件访问的存储器块。

箭头代表访问初始化的典型方向。各种处理块和通用 DMA 通常与外设或存储器接口，以执行它们指定的工作负载。另一方面，外设在 I/O 用途方面通常需要与存储器接口交互。存储器 bank 自身不会发起任何通信。

更具体地说，箭头代表的是 AXI 流量的方向。此刻回顾第 2 章"处理器系统"中介绍的内容， Zynq UltraScale+ MPSoC 器件的内部互联基于多重 Arm 标准，其核心概念是称为 AXI 主控和 AXI 从控的端点。AXI 主控初始化读写请求，同时，AXI 从控则对这些请求做出响应。因此，从处理块和通用 DMA 出发到外设的箭头代表流量由前者的 AXI 主控初始化，并前往后者的 AXI 从控。一般情况下，这种类型的访问允许处理块访问外设的控制寄存器和/或从外设请求具体操作。正如第 10 章"外设"中讨论的，大部分 Zynq UltraScale+ MPSoC 器件外设也提供具备 DMA 功能的 AXI 主控器，因而这些外设在被处理块相应编程后，能与存储器进行交互，以向外设传输数据或从外设接收数据。这种情况用从外设指向存储器的箭头表示。

请注意，包含处理块的 GP DMA 块同时包含第 6 章"存储器"中介绍的低功耗域通用 DMA 控制器和全功耗域通用 DMA 控制器。实际上，将它们的从端口分别作为 LPD 外设和 FPD 外设，即可对两者进行编程。需要重申的是，本图的目的是帮助建立对 Zynq UltraScale+ MPSoC 器件的各项功能的概念。请参阅第 2 章"处理器系统"查看完整的互联图。

在 Zynq UltraScale+ MPSoC 器件内，上图所示的三个主边界由三个互补保护机制保护，如下图所示：


图 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





系统内存管理单元 (SMMU)，赛灵思内存保护单元 (XMPU) 和赛灵思外设保护单元 (XPPU) 可实现系统设计人员对资源进行隔离与分区的互补作用。换言之：

• 第 2 章"处理器系统"中介绍的 SMMU 允许具有 DMA 功能的器件引用虚拟地址。SMMU 能将这些虚拟地址直接映射到虚拟机管理器客户指定的虚拟物理地址，也可直接映射至由操作系统（本地运行于 APU 之上）利用的真实物理地址。

• 在第 113 页的“赛灵思内存保护单元 (XMPU)”中详细介绍的 XMPU 能根据发出访问请求的 AXI 主控器 ID 过滤对存储器和 FPD 外设的访问。

• 在第 115 页的“赛灵思外设保护单元 (XPPU)”中介绍的 XPPU 能根据发出访问请求的 AXI 主控器 ID 过滤对 LPD 外设的访问。

如上图所示，这三种保护机制间存在多种组合方式。而且它们并非用在处理块、外设和存储器间的所有路径上。第 2 章"处理器系统"中介绍的互联图提供各 Zynq UltraScale+ MPSoC 器件块间沿上述路径所使用保护机制的完整细节。下图是对当前讨论所涉及的交互总结：


图 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





上图中，各种颜色的箭头对应颜色相近的组件。以 RPU 为例。它包含一个粉色象限，说明它使用粉色箭头通过 XPPU 访问 LPD 外设。然而，在访问黄色 TCM 时， RPU 的黄色象限说明它使用黄色箭头，不穿过任何 SMMU、 XMPU 或 XPPU。这是由于 TCM 位于 RPU 之内，虽然系统其余部分通过全局内存映射（见第 6 章"存储器"）也能访问它。另一方面， APU 对 TCM 的访问遵循 APU 访问 LPD 外设的类似路径，即使用粉色箭头穿过 XPPU。

在介绍该图时，本文不详细深入每一条可能的路径，只做一些重点提示。和以前一样，需要注意的是，箭头表示从 AXI 主控器到 AXI 从控器的 AXI 流量方向。

首先请注意 XMPU 和 XPPU 是如何出现在大多数交互路径上的。唯一的例外是同一个子系统内部组件间的交互，即构成 RPU 一部分的 TCM 与构成 PL 一部分的 PL 外设。除此类例外之外的所有交互，即便位于给定功耗域内，也遵循在 XMPU 和 XPPU 中设置的一切规则。例如，虽然 APU 和 FPD 外设都是全功耗域的组成部分，但两者间的所有交互均穿过 XMPU。与此类似，尽管 RPU 和 LPD 外设都是低功耗域的组成部分，但是它们的交互均穿过 XPPU。简言之，通过正确地配置 XMPU 和 XPPU，您可以从本质上随时控制系统中发生的所有交互。

其次，请注意 SMMU 的作用。在使用通用 DMA 或外设需要与存储器进行交互的情况下，都会使用 SMMU。根据前文介绍和第 2 章"处理器系统"中的详细说明，当 SMMU 被原生（如非虚拟化）OS 使用以及当 SMMU 对于 I/O 和虚拟机管理器的使用进行地址虚拟化时， SMMU 能为具备 DMA 功能的器件提供两级地址转换。在非虚拟化环境中使用 SMMU 时，SMMU 可确保器件只访问为它们指定的地址。在虚拟化场景中，SMMU 还能进一步确保器件地址被正确映射到由运行在 APU 上的客户 OS 所使用的存储器空间。换言之，客户 OS 并不明确使用实际物理地址对外设 DMA 进行编程。相反，实际上所有外设访问在到达存储器之前均先穿过 SSMU，以保证客户 OS 提供的地址与外设使用的地址两者间的正确转换。

其三，请注意 APU 可进一步提供额外的机制，用于对运行于其上的软件进行隔离和分区。在低层， TrustZone 允许在安全与非安全执行环境之间对 APU 进行分区。正如我们在下图看到的，安全/非安全状态通过 AXI 事务进行通信，从而 XMPU/XPPU 可以使用它来相应地区别请求。此外，如第 3 章"系统软件考虑因素"一章的讨论，使用 Xen 等虚拟机管理器，能进一步在不同客户间细分 APU 内的 A53 核。此外，正如第 3 章中介绍的，使用 Linux 等 OS 也能在对称多处理 (SMP) 模式下直接管理 A53 核。不管是否使用虚拟机管理器，随后的任何高级 OS 都通常依靠 A53 的内存管理单元 (MMU) 提供进程间隔离与保护，依靠 OS 提供用户空间进程隔离与保护。

后，需要注意的是，PL 及其外设的规则一定程度上可配置。例如，在访问存储器时，根据 PL 侧使用的 AXI 端口，PL 可能穿过或不穿过 SMMU。此外，默认条件下 PL 内的外设不通过 PL 外的组件提供。您必须按此要求配置 PL IP，才能向 IP 中添加任何你认为合适的 AXI 过滤规则。后文将给出这方面的例子。


图 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





通过将这些机制结合在一起，您就能有效地把您的设计细分为前文介绍的独立子系统。下图展示了这样一个细分设计示例：

在这个使用 Zynq UltraScale+ MPSoC 器件的保护机制的示意图里，设计被分为三个独立的子系统。每个子系统包含一个单独的处理块，在该块内作为主要的处理代理，用于与该子系统的外设进行交互。请注意，子系统 A 和 B 内均包含属于功耗域的外设，而不是属于该子系统的处理块的外设。例如，子系统 A 中的 APU 属于全功耗域。我们仍然可以使用 XPPU 来实现诸如 USB、 eMMC 和以太网等属于低功耗域外设的独占访问。在子系统 B 中情况相同。属于低功耗域的 RPU 能独占访问属于全功耗域的 SATA 接口。因此，按照第 4 章"电源考虑因素"中介绍的方式使用功耗域不会干扰 Zynq UltraScale+ MPSoC 器件的资源隔离和分区功能。

在本例中，子系统 A 的外设对子系统 B 禁入，反之亦然。例如，子系统 A 不能访问为子系统 B 预留的 SATA 接口。相反，子系统 B 不能访问为子系统 A 预留的 Display 端口。这些增强功能在互联层完成，其配置可在启动时设置为只读。因此，对企图违规访问系统资源的对手而言，该架构固若金汤。例如，对于运行在 APU 上的软件，无法在运行时改动这些规则。总而言之， Zynq UltraScale+ MPSoC 器件的隔离与分区功能能让您把子系统 A 和 B 分成就如同是两个物理上独立的器件。

子系统 C 对子系统 A 和 B 提供类似程度的保护。但是子系统 A 和 B 对子系统 C 的保护略有不同。在 PL 示例中没有通往 PL 块的 XMPU 或 XPPU。相反，根据 AXI 主控器的 ID 可将 PL IP 配置成用来筛选去往 PL AXI 从端口的输入流量。换句话说，作为设计人员，您可以根据发出请求的 AXI 块的 ID，对进入给定 PL AXI 从端口的任何 AXI 流量进行阻拦。例如，您可以让 PL 上的特定 AXI 从端口独占地响应 APU。因此，来自 RPU 的 AXI 从控器上的任何请求都会被拒绝。简言之，通过定制 PL IP，您能够有效地对 Zynq UltraScale+ MPSoC 器件的其余部分实现与由 XMPU 和 XPPU 提供的同等水平（即便不是更严格）的控制。

正如上文所述，还存在更多的示例场景。关于您的设计是否需要按这种方式进行细分以及如何实现这种细分，需要根据您的要求和规格而定。没有具体规则可供遵循，正如我们在前文中所建议的，您可以用些时间明确您系统内的细分并理解如何利用 Zynq UltraScale+ MPSoC 器件的功能来实现基本设计目标。

当然，把 Zynq UltraScale+ MPSoC 器件的资源隔离和分区功能集成到您的设计中无疑有助于提升安全性。通过让您的团队尽早熟悉这些功能，您将能够按照要求不断调整它们。如果您决定不使用这些功能，您也可以在以后随时重新考虑这个决策。但是要注意的是，随着系统实现的推进，对安全性约束进行改进的难度会越来越大。因此，如果安全性是您的要求之一，或者在您的项目生命周期里很有可能成为考虑因素，我们强烈建议您考虑进一步思考本章介绍的内容。


图 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





Arm TrustZoneArm 的 TrustZone 技术及其底层概念是多项 Zynq UltraScale+ MPSoC 器件功能的重要组成部分。例如正如前文提及的，XMPU 和 XPPU 能根据 Arm TrustZone 中定义的安全状态过滤访问。但是令人遗憾的是，出于多种原因 TrustZone 并非是一种易于掌握的方法，即便是对有经验的团队也是如此。针对您的设计，透彻理解 TrustZone 及其如何适应 Zynq UltraScale+ MPSoC 器件的整体功能至关重要。本节的目的是帮助您理解 TrustZone、它在 Zynq UltraScale+ MPSoC 器件中的用途以及您如何围绕它自定义您的设计。

TrustZone 基本

为了理解 TrustZone 的作用，我们必须先返回一步，了解现代处理器如何隔离特权。在现代的处理器设计中，一般存在至少两种操作模式：特权操作模式和非特权操作模式。特权模式由 OS 使用，而非特权模式由常规应用使用。一般情况下，处理器拥有只能在特权模式下使用的操作数和寄存器，所以通过处理器配置能让 OS 对系统有更大控制权。这种隔离由处理器的 MMU 进一步执行，从而确保 OS 免受来自非特权应用的无授权访问。

这种特权模式和非特权模式间的隔离方案存在于各种进程架构上，在软件界有时也称为“内核空间与用户空间”隔离。其他情况下， OS 可被称为在“ring 0”方式下运行，也就是可能存在多个特权“ring”的情况且 OS 是位于内侧的环。虽然这些概念可以有不同的名称，但是这样的划分长久以来对大部分应用已经足够。

但是，近期 Arm 架构等通用处理器在应用中的使用不断普及。在这种架构下甚至是运行的通用 OS也不能完全信任，用来将特定软件工作负载与系统其余部分隔离。实际上，现代 OS 已经变得极为复杂，定期对它们进行安全修复并不罕见。但是，设计中越来越多地需要涉及安全功能，例如保障用户证书安全或解密 DRM 编码媒体，从而在同一个处理器上与通用 OS 并存。

Arm TrustZone 技术的目的是在运行在处理器上通用 OS 特权级之下定义另一个特权级，来满足这一需求。使用 TrustZone，运行在 Arm 处理器上的 OS 不再拥有高特权。相反，有另一个软件层拥有比 OS 更高的特权，从而能以安全方式让重要操作在 OS 环境之外或其应用环境中进行。使用 TrustZone 后，这些操作和整个安全环境实际上对 OS 是透明的。换言之，运行在拥有 TrustZone 功能的 Arm 处理器上的通用 OS 实际上认为自己对处理器有全面的控制权，很大程度上就如同 TrustZone 并不存在一样。但是， TrustZone 仍然继续运行并提供所需的服务。

就像 OS 能够访问特殊处理器功能和寄存器，能够配置存储器保护机制来保护自己免受常规应用影响， TrustZone 定义的额外特权级也能访问 Arm 处理器的特殊功能，从而确保它能提供隔离的安全环境。这就意味着非安全环境（如常规 OS 及其应用）所见的处理器状态（包括寄存器值）必须在进入安全状态时予以保留，并在返回非安全状态时予以恢复。此外，这还意味着一旦非安全状态被保存，处理器就能从非安全的通用 OS 及其应用运行完全独立的安全堆栈。该安全堆栈对后者是不可见的。

为了与该安全软件堆栈进行通信，运行在 TrustZone 上的通用 OS 一般拥有一个或一套驱动程序，通过使用中断调用安全环境。使用这些驱动程序的应用就如同它们在与任何常规器件进行通信。当收到驱动程序的请求时， OS 自身仅使用可用的处理器功能就可以触发中断。唯一的区别在于这些中断是被 TrustZone 安全环境捕获，而不是像通常发生的那样，被 OS 中的中断服务程序捕获。随后，按照运行在安全环境中的软件的编程目的，这些中断由安全环境执行。





异常级别 (EL)在 APU 的 Armv8 A53s 上实现 TrustZone 建立在我们前文介绍的基本概念之上，并定义 4 种特权级，每种都被称为单独的异常级别 (EL)。具体如下图所示。

首先，请注意 TrustZone 是如何实现独立安全堆栈与运行在 A53 上的主要非安全堆栈的并存的。例如，在非安全侧，可将 Xen 用作运行在 EL2 上的虚拟机管理器，同时 Xen 将 Linux 客户 OS 实例托管在 EL1 上，后者则自己在 EL0 上运行应用。但进入 EL3 后，这里运行的软件及上述的安全监控模式，能够发展成一个单独的安全堆栈，其中有运行在 EL1 上的安全 OS，也有运行在 EL0 上的安全应用。

安全侧内的这些软件层级以与在非安全侧上的软件层级间完全相同的保护方式实现彼此间的保护。换言之，运行在 EL0 上的安全应用能彼此保护且无法直接访问 EL1 OS 资源。这与运行在非安全环境中的常规 Linux 应用间彼此保护且无法直接访问托管在 EL1 上的 Linux 内核资源的情况相同。

安全配置与事务标注

除了可将 APU 划分为安全状态和非安全状态， Zynq UltraScale+ MPSoC 器件和 AXI 互联上的配置寄存器也遵循 TrustZone 在 APU 上的规则，也就是说既可以兼具安全状态和非安全状态，也可配置为其中之一。该特性至关重要，因为互联上的所有 AXI 存储器事务都被标注为安全事务或非安全事务。这一状态反映了事务源是否安全，是否能被前面提及的 AXI 从控器、 XMPU 和 XPPU 使用，用来区别非匹配方。

有多个关键系统组件属于安全 AXI 从控器。这其中包括平台管理单元 (PMU)、配置安全单元 (CSU) 和系统级控制寄存器 (SLCR)。因此，初始化这些组件间的通信只能由安全 AXI 主控器完成。同样地，一些系统组件也是安全 AXI 主控器。这其中包括 PMU 和 CSU。因此， PMU 和 CSU 能随时在它们之间初始化安全 AXI 事务。

此外，由运行在安全环境中的 A53 进行初始化的所有 APU 存储器事务都将在 AXI 总线上标注为安全。这也需要加以注意，因为一些关键系统操作只能由运行在 APU 上的安全代码完成。因此，运行在安全环境中的 A53 能与 PMU 或 CSU 进行通信，而运行在非安全环境中的 A53 则无法实现通信。

虽然原则上安全主控器能够访问非安全从控器，但是 XMPU 和 XPPU 配置能够阻止安全从控器非对非安全从控器进行访问。


图 7-5：TrustZone 异常级别 (EL)

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





请参阅《Zynq UltraScale+ MPSoC 技术参考手册》 (UG1085) [参照 7] 中的表格 16-10 查阅有关 TrustZone 剖析的完整列表。

Arm 可信固件 (ATF)赛灵思 FSBL 始终以安全模式启动 APU，并且能够使 Arm 可信固件 (ATF) 作为前文介绍的安全监控在 EL3 上运行。ATF 介绍参见第 3 章"系统软件考虑因素"，它是启动时间信任链的组成部分。

作为众多功能之一， ATF 负责在切换到安全环境时保留和恢复非安全环境。此外，它也负责部分功耗管理。因为负责功耗管理的 PMU 是一个安全 AXI 从控器，不接受由虚拟机管理器或运行在 APU 上的非安全 OS 发出的任何命令。因此， Linux 等非安全 OS 发出的功耗管理请求通过 ATF 代理后与 PMU 进行交互。

鉴于其用于维持 A53 内的内部处理器状态、在 APU 和关键系统功能间发挥中介作用以及提供基本的系统安全性，您的设计很有可能会用到 ATF。如果您按照第 3 章"系统软件考虑因素"中提及的方式运行 Linux，这样做就尤为正确。

注释：对于在没有底层 ATF 的情况下运行的 OS，赛灵思不提供任何配置支持。

可信执行环境 (TEE)虽然 ATF 对运行 A53 至关重要，但它本身并不提供托管定制安全应用所需的必要功能与 API，就如上图右上方所示的以安全模式运行在 EL0 上所需的功能与 API。这项功能通常由标记为“虚拟机管理器（安全 OS） ”的组件来实现，也就是 Arm 文献中所称的可信执行环境 (TEE)。

TEE 并没有作为赛灵思系统软件堆栈的组成部分提供。但是在这里值得一提。TEE 是由 ATF 提供的单独软件组件。而且虽然 Arm 提供基准开源 ATF 实现方案，但它依赖第三方合作伙伴提供 TEE。因此，市场上存在多个 TEE，而且您需要确定是否需要使用 TEE，以及如果需要，应该使用哪一个 TEE。至少有一个开源 TEE 可支持 Zynq UltraScale+ MPSoC 器件，托管在 op-tee.org 上的开放可移植的可信执行环境 (OP-TEE)。

每个 TEE 都定义了各自用于编写安全应用的 API，同时为非安全 OS 和应用提供不同手段与 API，以便在所需的非安全/安全环境切换中与其进行通信。在选择 TEE 时，应了解它所提供的 API 和机制，以确保它们适用于您的项目。

特性总结

现在我们已经介绍完 TrustZone 基础、其核心功能及主要支持软件，下面的主要特性应更易于理解：

• PMU、 CSU 和 SCLR 等关键器件始终保持安全，防止对安全系统本身的无授权访问和修改。

• 您可以将器件编程为安全或非安全状态。

• 可按区域编程存储器，如片上存储器 (OCM) 和双数据速率 (DDR) 存储器，使之处于安全或非安全状态。

• 始终以安全模式启动 APU。

• RPU 不支持 TrustZone 技术，但您可以通过 SCLR 把每个 RPU 配置为向 AXI 总线发送事务的安全或非安全主控器。

如需了解更多信息

您可以参阅 Arm 技术参考手册，进一步了解 TrustZone。您也可以通过《Zynq UltraScale+ MPSoC 技术参考手册》 (UG1085) [参照 7] 中的本链接进一步详细了解 TrustZone 在 Zynq UltraScale+ MPSoC 器件中的使用与配置。



http://china.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xSystemProtectionUnit



系统内存管理单元 (SMMU)系统内存管理单元 (SMMU) 的目的是通过确保由 APU 上运行的软件编程的任何组件（如 AXI 主控器）生成的存储器访问与 APU 自身之上使用的映射一致，从而作为对 APU 核的 MMU 的补充。在 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，从而允许原本运行在 APU 上的 OS 对任何器件（如外设）的 DMA 主控器能访问的存储器进行控制。

注意，在原生环境中 SMMU 并非必须的使用条件。但是，使用 SMMU 必定会提升您系统的安全性。

虚拟化场景中的全局隔离

SMMU 对虚拟化系统特别有用，因为它可以确保客户操作系统请求的 DMA 访问彼此隔离。这样能防止一个域内的功能失常、故障或非法侵入波及到其他域，从而在虚拟化环境中提供系统完整性。为此目的， SMMU 提供了合适的设置转换机制与情景（I/O 虚拟化）功能。

SMMU 为地址转换机制提供支持，该机制需要具备 2 级转换过程的虚拟化环境。在此环境中，虚拟机管理器管理着多个客户操作系统，并且在这些系统中运行着多个可能会试图访问相同系统资源的应用。下图所示的是，这一转换如何在独立于客户操作系统的情况下进行。

附加信息

请返回阅读第 2 章"处理器系统"了解 SSMU 的更多信息，也可参阅《Zynq UltraScale+ MPSoC 技术参考手册》 (UG1085)中的这个链接和这个链接[参照 7]。


图 7-7：SSMU 在原生（非虚拟化）配置中的使用


图 7-8：SMMU 在虚拟化配置中的使用



http://china.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xInterrupts

http://china.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xTimers



赛灵思内存保护单元 (XMPU)如前文所述， XMPU 提供存储器分区和系统间威胁防护。具体而言，它使您可以通过给定主控器组对 FPD 外设和存储器区域进行约束访问，从而在根本上保护 FPD 外设和存储器。 Zynq UltraScale+ MPSoC 器件上实际分布着 6 个 XMPU，如下图中的红色高亮所示：

每个 XMPU 都具备下列特性：

• 16 个用于过滤的可配置区域

• 用于接收访问请求的从 AXI 端口

• 具备毒化输出功能的主 AXI 端口

• 用于编程 XMPU 的 APB 从控器

• 电平敏感的异步中断输出

• AXI 时钟（同样适用于主端口与从端口）和高级外设总线 (APB) 时钟

简单地说，每个 XMPU 都依靠其设置来确认是否允许访问。如果不允许访问，那么需采取包括使用“毒化”的几个步骤，下面将对其进行介绍。


图 7-9：Zynq UltraScale+ MPSoC 器件中的 XMPU 位置





XMPU 区域

每个 XMPU 有 16 个区域（编号从 0 到 15），每个区域用起始地址和结束地址定义。您可以独立于其他区域启用或禁用每个区域。如果您禁用某个区域，则该区域将不被用于保护方案的检查。有两种区域地址对齐方式：1 MB 和 4 KB。虽然区域能够重叠，但较高的区域编号有更高的优先级（即，区域 0 的优先级低）。

如果您未启用任何区域或者某请求与任何区域都不匹配，那么 XMPU 会采取 XMPU 控制寄存器中设定的默省行为（允许申请或毒化）。

保护检查操作

每当 AXI 主控器向由 XMPU 保护的 AXI 从控器发送读/写请求时，检查对比该请求与每一个 XMPU 启用的区域。具体包括如下两项基本检查：

• 检查事务的地址是否位于该区域内

• 检查是否允许输入事务的主 ID

如果两项检查均已通过，则对安全状态和读写授权进行如下区域配置检查：

• 如果该区域被配置为需要安全主控器，则仅安全请求能访问该区域。一旦通过这项检查，单独进行读/写授权检查，判断事务是否被允许。请参阅第 108 页的“Arm TrustZone”，了解安全主控器的进一步介绍。

• 如果该区域为安全区域，但事务是非安全事务，则检查失败。

• 如果该区域被配置为非安全区域且事务为非安全事务，单独进行读/写授权检查，以判断事务是否被允许。

XMPU 错误处理

如前文所述，通过 XMPU 执行的 AXI 事务（不论是读取还是写入操作）可能会因不被授权或安全违规而失败。如果发生这种错误， XMPU 会毒化请求，记录检查失败的首个事务的地址与主 ID，并为违规标注旗标，然后选择性地生成一个中断。对于安全违规，还需要进一步建立日志，说明错误是安全违规。

毒化请求的方式有两种：

1. 如果申请里设置了毒化属性，可向 AXI 从控器发送信令，要求返回清零数据或忽略写入。注意，只有 DDR 存储器控制器和 OCM 支持毒化属性。

2. 输入的读取请求可被 XMPU 修改，并指向预先编程的毒化地址。毒化地址的内容实质上是一个“诱捕系统”，也就是向发出请求的主控器返回虚假数据。该类型毒化无需由无效请求指向的从控器提供特殊支持。

配置

每个 XMPU 都有一组可用于配置它的寄存器。一个极为重要的 XMPU 寄存器是 LOCK 寄存器。这个寄存器可设置为读/写、默省或只读模式。设置完毕后，该寄存器无需重置整个系统就能防止进一步修改 XMPU 的配置。当您根据您的设计要求完成 XMPU 配置后，这个操作能让您锁定 XMPU 配置。

有两种配置 XMPU 的方法：

1. 使用 Vivado® 设计套件里的处理器配置向导 (PCW) 生成第一阶段的启动加载程序 (FSBL)。

2. 在运行时，通过安全的 AXI 主控器。

不论那种方式，如果 LOCK 寄存器已完成设置，在下一次重启前，配置将不可更改。

为确保您的系统一直处于正确配置和安全状态下，我们建议您在启动时，通过 FSBL 在锁定模式下使用 PCW 配置 XMPU。否则，在运行时您必须极为小心，避免因错误的 XMPU 配置导致资源不可用的情况发生。





关于每个 XMPU 里使用的具体区域和为每个区域配置的具体权限，需根据您的设计予以确定。正如第 103 页的“定义您的资源隔离以及分区需求”所强调的，如何使用 Zynq UltraScale+ MPSoC 器件的功能分区您的设计，具体需根据您设计的特性和要求来决定。

关于 XMPU 的进一步介绍，请参阅《Zynq UltraScale+ MPSoC 技术参考手册》 (UG1085) [参照 7]中的本链接。

赛灵思外设保护单元 (XPPU)赛灵思外设保护单元 (XPPU) 可提供 LPD 外设隔离与处理器间中断 (IPI) 保护。类似于 XMPU，XPPU 可帮助防范系统间威胁。与 XMPU 相比，XPPU 使用更精细粒度的地址匹配，可提供更大地址匹配口径，并能同时满足外设、IPI 和 QSPI 闪存的不同需求。另外，与 XMPU 不同的是，在整个系统中只有一个 XPPU。

XPPU 简介

XPPU 具有下列特性：

• 为特定地址口径组提供每个主控器访问控制

• 按每个外设或每个消息缓存的访问控制

• 多支持 20 个并发主控器组

• 支持大 128x32 B 孔径， 256x64 KB 孔径、 16x1 MB 孔径和 1x512 MB 孔径。

• 支持 64 KB 和 1 MB 外设孔径及 32 B 消息孔径。

• 支持用于线性 Quad-SPI 闪存授权检查的单一 512 MB 孔径。

• 为禁用事务提供出错处理（和可选的中断生成）

和 XMPU 的情况一样， XPPU 居于 AXI 主设备和 AXI 从设备之间，为 AXI 读取和写入事务提供存储器访问控制。



http://china.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xXilinxMemoryProtectionUnit



下图以蓝色显示 XPPU 布局：

XPPU 使用两个数据结构控制访问：

• 主 ID 列表：

您可以部分编程该列表。该列表指定允许访问外设的主设备。本质上该列表是一个潜在主设备池。前 9 个主控器是预定义的，其余 11 个是可编程的，都应在启用 XPPU 前设置。

• 孔径授权列表：

该列表定义可访问的地址孔径并确定能访问每个孔径的主控器。如前文所述， XPPU 大可支持 128x32 B 孔径、 256x64 KB 孔径、16x1 MB 孔径和 1x512 MB 孔径（从控器）。软件设定的许可设置存储于 RAM 中。该 RAM 位于系统地址映射上，访问方式与常规软件可编程寄存器相同。


图 7-10：XPPU 在 Zynq UltraScale+MPSoC 器件内的位置





XPPU 操作

可将 XPPU 视为一个能够提供精细访问控制的 1x1 AXI 交换机。对于每个读写事务， XPPU 都将判断其是否被允许。如果允许该事务，它会正常处理。如果不允许该事务，它将毒化该事务使之无效，与 XMPU 的操作基本一样。

如果 AXI 主控器要通过 XPPU 成功访问 AXI 从控器，那么应满足下列两个条件：

• AXI 主控器 ID 必须位于主控器 ID 列表中（例如第 m 个输入）

• 孔径权限列表中的 AXI 从控器输入，必须在允许字段里有对应的位设置（即 PERM[m] == 1）。

上述条件为一般规则。还需要额外的检查，下方为其详细介绍。

这个块级图是对 XPPU 运行方式的总结：

在上图中，AXI 读取事务将抵达靠近图顶部的位置，而 AXI 写入事务则抵达靠近底部的位置。在这些事务中隐藏着主控器 ID、授权等，由 XPPU 用来判断读/写请求是否有效、是否被允许。高级外设总线 (APB) 接口允许您在启用 XPPU 前为其编程。授权 RAM 用于保持授权标准。

因为 XPPU 是一个基于查找的外设保护单元，它使用表格（例主控器 ID 和孔径权限）具体判断哪个主控器在试图读/写哪个外设。关于这些列表的更多详细介绍及使用方法，请参阅《Zynq UltraScale+ MPSoC 技术参考手册》 (UG1085) [参照 7]。

XPPU 权限检查

权限检查用于判断读/写事务是否被允许。基本上，检查是通过匹配主控器 ID 查找表和间隙权限列表条目来执行。输入的 AXI 主控器 ID （携带施加的掩码）应列出在主控器 ID 列表中，同时在间隙权限列表中也应被列为允许的主控器。此外，输入的安全状态应满足间隙的安全状态设置。如果启用奇偶校验，将对间隙权限列表上的选中条目进行奇偶校验，进一步验证结果。

如果上述全部检查均通过，那么该事务被允许。否则，可能是发生了下列错误之一:：

• 主控器 ID 列表奇偶校验错误

• 主控器 ID 列表只读错误

• 主控器 ID 列表缺失错误


图 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





• 间隙权限列表奇偶校验错误

• 事务 TrustZone 错误

• 事务权限错误

有关 XPPU 权限检查的更多详情以及如何处理上述错误，请参阅《Zynq UltraScale+ MPSoC 技术参考手册》 (UG1085) [参照 7]。

传输事务投毒 (Transaction Poisoning)正如前文 XPPU 功能性原理图中所示，如果读/写 AXI 事务未通过检查，该事务就会被毒化。读事务的毒化将导致所有 0 的读取，而写事务的毒化会造成写行为的忽略。系统包含一个接收模块，用于接收被毒化的事务，返回错误响应，并选择性地记录较低的 12 位事务地址。这可能导致数据中止或处理器中断。

XPPU 保护

XPPU 本身受两种方式保护。主控器 ID 列表和间隙权限列表能够：

• 仅由安全主控器写入

• 使用 XPPU 自己的配置功能在主设备 ID 列表和孔径权限列表里设置对应的条目，阻止 XPPU 本身被进一步写入，从而为主设备 ID 列表和孔径权限列表加锁。

配置

和 XMPU 的情况一样，有两种配置 XPPU 的方法：

1. 使用 Vivado Design Suite 的处理器配置向导 (PCW) 部分生成第一阶段启动加载器 (FSBL)。

2. 在运行时，通过安全的 AXI 主控器。

与 XMPU 类似，我们建议您在启动时使用 PCW 在 FSBL 里配置 XPPU，并防止其被进一步修改，从而确保您的系统始终得到正确配置与安全保护。否则在运行时您必须极为小心谨慎，避免因错误的 XPPU 配置造成资源不可用的情况发生。

在每个 XPPU 中将要配置的区域所使用的特定区域和权限将取决于您的设计，与 XMPU 的情况相同。

如需了解有关 XPPU 的更多信息，请参阅《Zynq UltraScale+ MPSoC 技术参考手册》 (UG1085) [参照 7] 中的本链接。

Xen 虚拟机管理器 (Hypervisor)Xen 虚拟机管理器及其与 Zynq UltraScale+ MPSoC 器件的结合运用，请参阅第 3 章"系统软件考虑因素"。在这里我们将详细介绍有关虚拟机管理器（具体指 Xen）的相关内容，包括本章介绍的资源隔离与分区特性。

正如前文所述，Xen 等虚拟机管理器能让您在不同的客户 OS 间或在某些客户 OS 与裸机应用间对虚拟 A53 CPU 进行分区。请回顾前文中关于 TrustZone 的探讨，请注意，Xen 运行在非安全环境中，而 ATF 运行在 Xen 之下。因此，由 Xen 及其托管的客户发起的所有存储器访问都将是在 AXI 互联上以非安全 AXI 事务发出。因此，XMPU 和 XPPU 的配置应考虑到作为 APU 软件架构组成部分而使用 Xen 执行的软件分区。



http://china.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xXilinxPeripheralProtectionUnit


第 8 章

安全性在任何嵌入式设计中，安全性都占据着日趋显著的先决性地位。 Zynq® UltraScale+™ 器件为设计人员提供全面的特性功能集，可应对当今一些为艰巨的安全威胁与挑战。本章用于阐释奠定 Zynq UltraScale+ 器件基础的安全性理念以及如何利用其功能满足您设计的安全性需求。

定义您的安全性需求安全性是一个非常宽泛的范畴。虽然大部分从业设计人员和工程师都能意识到它的重要性，但是在预定设计中开展详尽的安全性分析则对相关的专业知识水平具有较高要求。实际上，要解决的问题往往并非局限于技术缺陷。相反，您的分析可能涵盖如下课题，包括企业名誉、财务责任、关键任务安全，在某些情况下还包括国家安全事宜。

因此，使用固定的问题组合引导您完成设计安全性评估，可能会使您误入歧途。所以我们强烈建议您与自身团队的安全专家合作，掌握您设计面临的威胁模型。您应该考虑如下问题：

• 您要保护的知识产权的价值如何？

• 您的系统将要部署在怎样的环境中？例如，它是否无人值守且易于接近？还是处于武备、门禁和警卫的重重保护下？

• 您觉得您的竞争对手是谁？他们有什么样的能力？




第 8 章：安全性

安全性方法正如上文所说，安全性是一个非常宽泛的课题。从基于 Zynq UltraScale+ 器件的系统设计角度出发，我们建议您采取图 8-1 所示的三个角度审视您的设计。

• 防篡改 (AT)：防篡改有时也称为“物理安全”。 AT 功能保护客户 IP 不受反向工程、克隆、窃取、修改等其他违背您系统设计目的的方式使用。如果您认为自己的 IP 颇具价值，那么 AT 对您的安全战略至关重要。

• 信息保证 (IA)：借助业界标准的加密和容错设计方法来保护正在处理的信息与数据。

• 信任 (供应链安全)：确保芯片、软件、固件和 IP“无木马”。

如图 8-1 所示，这三个原则彼此重叠交集，因此需要以全面的方式分析安全性。除了涉及多项原则，安全性也是一个多层次课题。虽然您或许首先对某一具体方面为关注，但是图 8-2 展示了安全层相互叠加的构成方式。


图 8-1：基本安全性原则





正如您看到的，对供应链的信任，即确保您使用佳实践和权威的供应商，是您安全架构的基石。这个基石保证器件各司其职。这个部分由赛灵思负责。

安全特性沿金字塔向上部署，用于保护芯片本身免受以改变和/或测量温度/电压等方式进行的物理篡改、或滥用 JTAG 等合法器件功能带来的攻击。这个部分也由赛灵思负责。

再往上，通过运用信息保障原则，即保密性、验证和完整性，对启动和配置过程进行保护。赛灵思为设计人员提供这方面的功能，但是否能正确使用还取决于您。

更上一层是高于堆栈的软件层，例如虚拟机管理器保护、 TrustZone 和监控。赛灵思在该层也同样提供需要正确使用的功能。

后，用户可在顶层通过创建签名与密码对应用进行保护。主要通过设计人员的正确操作来负责该层。

实际上，安全性也有生命周期，从供应链延伸到实地运行的器件。


图 8-2：安全金字塔





各类专业组织和论坛能够帮助您了解整个行业的新安全动态。赛灵思在北美和欧洲每年举办赛灵思安全工作组 (XSWG) 活动。它齐聚赛灵思航空航天、国防与商业客户、学术界代表、赛灵思联盟成员以及政府机构，共商新的安全性课题。这些课题包括供应链保护、器件安全、安全启动和运行时安全性。

请注意，虽然本章标题开章明义地提及“安全性”，但是其他章节也会对安全相关课题进行探讨：

• 第 2 章"处理器系统"介绍 Zynq UltraScale+ 器件大部分组件间通信使用的互联。

• 第 7 章"资源隔离以及分区"探讨各类运行时安全相关机制，例如 TrustZone、赛灵思内存保护单元 (XMPU)、赛灵思外设保护单元 (XPPU)。

• 第 5 章"可编程逻辑"介绍了隔离设计流程 (IDF)，这是一种容错设计方法，用于在可编程逻辑 (PL) 中隔离 IP 功能。

安全性特性简介安全是永恒的“军备竞赛”，赛灵思通过不断添加安全特性和功能并强化现有的安全性特性，努力在威胁来临之前做好充足准备。图 8-3 借助右面两列列出的 UltraScale+ 特性，总结了赛灵思整个产品线内置的安全特性。

安全特性可分为两大类：被动特性和主动特性。被动安全特性内建在器件中，无需设计人员对它们的设计进行额外介入。例如安全配置/启动和验证就属于此类特性。主动安全特性要求设计人员在设计或运行时主动激活一些 Zynq UltraScale+ 器件的功能。将器件配置为用来监控特定电压与温度工作范围就是其中的主动安全特性之一。

理解 Zynq UltraScale+ 器件的特性并了解针对这些特性存在哪些类型的攻击，有助于您决定在实现方案中使用哪些特性。如需了解更多有关安全性的信息，请参阅《Zynq UltraScale+ MPSoC 技术参考手册》 (UG1085) [参照 7] 中的链接。


图 8-3：赛灵思安全性特性



https://china.xilinx.com/about/security-working-group-2016.html

https://china.xilinx.com/about/security-working-group-2016.html




配置安全性和安全启动确保从制造商到客户的信任链完整有效后，系统设计人员要掌握的优先事项之一是保障 SoC 启动过程的安全性。实际上，对于片上逻辑和固件而言，关键在于确保启动时加载的软件链签发与器件启动时的授权密钥相符，这样才能确保所谓的硬件信任根。或者，您也可以启动未签发镜像，但如果这对您的系统设计而言是佳途径，那在您的情况中安全性或许毫无问题。在开发早期阶段，通常可以使用未签发镜像运行，比如通过 JATG 加载它们。

就 Zynq UltraScale+ 器件而言，安全启动由平台管理单元 (PMU) 和配置安全单元 (CSU) 提供支持。除了参与启动过程，CSU 也负责 Zynq UltraScale+ 的众多其他安全性相关功能，下文将很快谈到。 CSU 通过首先启用 RSA 完成非对称验证，然后启用 AES-GCM 实现保密（加密/解密），从而为硬件信任根提供保障。下图显示了 Zynq UltraScale+ MPSoC 器件整体系统原理图中的 CSU。


图 8-4：配置安全性単元





启动流程包含三个阶段：

• 配置前：一旦确定了需要启动的系统（“上电复位”或 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 块这一 Zynq UltraScale+ 器件上的三冗余 MicroBlaze™ 处理器、安全块、CSU DMA，安全流开关 (SSS) 和处理器配置访问端口 (PCAP)，可从外部启动器件载入待检查和启动的启动镜像。图 8-6 显示了 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





位于左侧的是三冗余 MicroBlaze 处理器和 CSU RAM 以及 ROM。其中包括物理防克隆功能 (PUF) 块，该块用于生成有器件唯一性的加密密钥。位于右侧的是管理加密与解密密钥的块、各种加密过程（AES-GCM 和 RSA），即所谓的加密接口块 (CIB)。此外，还有 CSU DMA 进程块， SSS 凭借其发挥功能。

CSU 的重要功能之一是密钥管理。如下表所示， CSU 能够将多个密钥中的一个用于其 AES-GCM 功能。


图 8-6：配置安全性单元 (CSU) 原理图

表 8-1：密钥类型

密钥名称描述

BBRAM 备份电池 RAM (BBRAM) 密钥以纯文本形式存储在 256 位 SRAM 阵列中。为延长电池使用寿命， SRAM 阵列可在 VCCAUX 加电时由其供电。否则该 SRAM 阵列通过 VCCBAT 供电。

启动密钥在使用中，可启动密钥寄存器保持解密的密钥。

eFUSE eFUSE 密钥存储在 eFUSE 中。密钥可以是纯文本，混淆密钥（例如使用族密钥加密）或使用 PUF KEK 加密。

系列族密钥是硬编码到器件中的 AES 密钥常量值。Zynq UltraScale+ MPSoC 系列中的所有器件都使用相同密钥。该密钥仅供 CSU ROM 用于解密混淆密钥。解密后的混淆密钥用于解密启动镜像。混淆密钥可存储在 eFUSE 内或是经验证的启动报头文件中。因为族密钥在所有器件上都相同，所以使用“obfuscated”而非“encrypted”来体现这种安全机制的相对强度。

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





关于 BBRAM 和 eFUSE，请注意编程到 Zynq UltraScale+ 器件中的密钥不能以任何方式取回。只有 CRC 校验可用于检查密钥是否正确编程。

一旦 CSU 配置完成，且 FSBL 执行开始后， CSU 即开始监控系统中有无被篡改响应。如果检测出篡改，则执行一系列用户定义响应，包括安全锁定。

设计人员在启动时可选择和配置的软件组件的详细介绍，请参阅“系统软件考虑因素”章节。也就是说，从 FSBL 的启动起到以后的进程。

请注意， FSBL 负责使用 CSU DMA 通过 CSU 的 PCAP 为 PL 加载比特流。在使用 Vivado® Design Suite 时，该过程自动完成。

如需了解更多信息，请参阅下列参考资料：

• 如需了解有关 CSU 的更多信息，请参阅《Zynq UltraScale+ MPSoC 技术参考手册》 (UG1085) [参照 7] 中的本链接。

• 如需了解有关通过 CSU 的 PCAP 为 PL 比特流编程的更多信息，请参阅《Zynq UltraScale+ MPSoC 技术参考手册》 (UG1085) [参照 7] 中的本链接。

• 《Zynq UltraScale+ MPSoC：软件开发指南》 (UG1137) [参照 5] 中的本链接介绍了几个与启动时安全性有关的方面。

器件和数据安全性尽管 CSU 和安全启动能确保器件安全启动，但是 Zynq UltraScale+ MPSoC 器件也提供确保器件运行时安全的特性与功能。

篡改监控与响应

如第 120 页的“安全性方法”中所述，防篡改 (AT) 有助于您的 IP 免受反向工程、克隆和其他非授权方式的操纵。而且上一节也提到，在 FSBL 开始执行后， CSU 的主要功能是以监控模式运行，以寻找篡改事件。例如，可通过 Zynq UltraScale+ 器件的电压和温度监控检测篡改事件。

您可以通过设置 CSU 篡改寄存器来控制篡改响应，如下表所示。

运行通过使用来自其他器件密钥源的纯文本密钥解密安全报头，就能获取运行密钥。对安全启动而言，该密钥属可选项。在启动报头文件中指定运行密钥，同时大限度减少器件密钥的使用，从而限制其暴露。

PUF KEK PUF KEK 是一种由 PUF 生成的密钥加密型密钥。

密钥更新寄存器用户提供的密钥源。启动后，用户选定的密钥可与硬化 AES 加速器结合使用。

表 8-2：篡改与监控寄存器

寄存器监控描述

csu_tamper_12 GT 的 AMS 电压告警。

csu_tamper_11 PSIO bank 3 的 AMS 电压告警。

csu_tamper_10 PSIO bank 0/1/2 的 AMS 电压告警。

csu_tamper_9 DDRPHY 的 AMS 电压告警。

表 8-1：密钥类型（续）

密钥名称描述





http://china.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xBootAndConfiguration

http://china.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug1137-zynq-ultrascale-mpsoc-swdev.pdf;a=xSecurityFeatures



这些篡改事件的可能响应如下表所示。

在某些情况下，如果检测出篡改事件，您可能想施加严格且永久的处罚。请参阅“撤销作为篡改处罚”一节，在《Zynq UltraScale+ MPSoC 技术参考手册》 (UG1085) [参照 7] 中的本链接，查看这样的例子。

此外， Zynq UltraScale+ 器件也提供一系列用户可定义的 eFUSE 位，用于为维护或篡改事件的日志数据创建唯一标识符，以便事后取证分析，如图 8-7 所示。

如需了解有关使用 eFUSE 为日志数据创建唯一标识符的更多信息，请参阅《Zynq UltraScale+ MPSoC 技术参考手册》 (UG1085) [参照 7] 中的本链接。

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 系统中断。


图 8-7：篡改与维护日志

表 8-2：篡改与监控寄存器（续）

寄存器监控描述



http://china.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug1137-zynq-ultrascale-mpsoc-swdev.pdf;a=xRevocationAsATamperPenalty

http://china.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xSecurityRelatedEFUSEs



系统监控器

除具有 CSU 功能，Zynq UltraScale+ 也在 PS 和 PL 内包含系统监控器 (SYSMON) 块。SYSMON 用于定制和/或高级环境监控。它是可以进行预先验证与预先实现的独立设备，不仅集成了赛灵思安全性特性，并具备极高的易用性。

例如，您可以使用 SYSMON 块寄存器接口来配置块，并能够监控片上电压和结温。此外，SYSMON 块还拥有内建告警生成逻辑，可根据特定告警条件来中断处理器。例如，它能根据过温 (OT) 告警关闭系统。图 8-8 展示了 Zynq UltraScale+ 器件中提供的 SYSMON 块。

SYSMON 拥有下列安全性特性：

• JTAG 端口监控和阻塞

• 包括低功耗域 (LPD) 在内的电源电压监控

• 器件裸片温度监控（APU、 RPU 和 PL）

• 用户时钟监控（8 个频率监控器）和看门狗

• 部分配置管理

• 配置 RAM 完整性监控

• 内建自检功能，用于自我检查

您可以通过动态可重新配置端口 (DRP) 配置 SYSMON，并可以通过 LPD I/O 外设地址映射访问该端口。

如需了解有关 SYSMON 的完整介绍，请参阅《Zynq UltraScale+ MPSoC 技术参考手册》 (UG1085) [参照 7] 中的本链接。


图 8-8：系统监控器块

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



http://china.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xPSSystemMonitor



防范 DPA 攻击差分功耗分析 (DPA) 攻击涉及对整个器件的功耗或其他辐射使用统计和信号采样，因为它可以在一段时间内解密信息并分析变化以掌握密钥情况。这些类型的攻击也称为“旁路攻击”，一种通过监控系统实现，而非使用暴力破解或试图寻找使用的加密算法薄弱点，来试图获取器件信息或器件工作状态信息的方法。

为帮助防御 DPA 攻击，您可以使用平衡电路来大限度降低电源或辐射中的可测摆幅。或者，您也可以添加噪声来提高测量的本底噪声。Zynq UltraScale+ 器件对于镜像加载使用的方法是限制攻击者能采集的数据量，从而避免攻击者在边信道信息上执行所需的分析。

DPA 攻击一般以两种方式开展：

• 随机数据攻击：本攻击是指，当攻击者将随机数据转储进加密系统，以采集足够用于提取“秘密” （即 AES 密钥）的边信道信息。

• 良性数据攻击：由于编程文件相当巨大，攻击者可能能够使用有效镜像作为加密系统的输入，并采集足以用于执行他们的分析的边信道信息。

为了防范随机数据攻击，应在解密前执行公共密钥非对称验证 (RSA)。通过此验证，只有被授权的镜像才能够解密。

为了防范良性数据攻击，您可以选择把启动镜像分解为较小的块，每个较小块使用自己的密钥加密（密钥滚动）。您可以选择块的大小，只有第一个密钥需要存储在器件中（eFUSE 或 BBRAM）。所有后续密钥都在之前的块中被保护、验证和解密。


图 8-9：差分功耗攻击 (DPA) 对应措施





CSU 硬件加速器除了在启动时使用， CSU 的加密功能也能用于加密函数的硬件加速，即 RSA、 SHA 和 AES-GCM。请参阅《Zynq UltraScale+ MPSoC 技术参考手册》 (UG1085) [参照 7] 了解这些功能的更多介绍。

功能安全另一个与安全紧密关联的方法是功能安全，这是一个涉及系统运行正确性的领域。Zynq UltraScale+ 器件包含多项支持功能安全性的特性，具体见《Zynq UltraScale+ MPSoC 技术参考手册》 (UG1085) [参照 7] 中的本链接。

例如，理想适用于安全关健型应用的 RPU 的锁步模式。如果作为设计进程的一部分，应用的一个子集可能必须满足 IEC61508 和/或 ISO26262 这样的功能安全标准，那么这个模式就很有意义。 RPU 中的 Arm Cortex R5 专为要求高可靠性、能响应硬件系统故障的应用而设计。同时，赛灵思设计工具套件为功能安全设计流程提供了一套满足 TUV SUD 认证的工具集，有助于加快您的项目的安全认证进程。

处理器系统中的可靠性与 FIT 识别和响应通过 Zynq UltraScale+ 器件的隔离架构来实现。 RPU 可以被隔离为与 Zynq UltraScale+ 器件架构其余部分完全独立的系统，仅允许部分外设和存储器位置对其进行访问。在互联层面，通过使用“资源隔离与分区”章节中所介绍的赛灵思存储器保护单元 (XMPU) 和赛灵思外设保护单元 (XPPU) 的强化访问，这些组件可确保存储器或外设上的数据传输事务仅限定在被授权的子系统组件上。此外，Arm TrustZone 架构对每个数据传输事务进行检查，以便授权访问正确的子系统。

如需了解有关如何针对您的设计解决功能安全问题的更多信息，请参阅《赛灵思 All Programmable 功能安全设计流程解决方案产品简介》（PB015） [参照 12] 和《赛灵思技术为 IEC61508 和 ISO26262 认证安全应用降低风险、提高效率白皮书》 (WP461) [参照 13]。



http://china.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xSafety


第 9 章

多媒体Zynq® UltraScale+™ MPSoC 器件将先进水平的可编程逻辑与 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 器件的内部块。相反，它主要是一张概念图，用于解释当前概念。

根据图 9-1，对于多媒体而言需要重视的组件是存储器。多媒体操作一般都涉及高强度存储器传输。因此，任何能大限度减轻存储器传输强度的措施都有利于提高多媒体的吞吐量。在无法避免数据传输的情况下，需深入理解涉及的路径，包括哪些其他方将需要同时使用这些路径，以确保系统功能正常。

例如，GPU 主要负责从 RAM 提取待渲染数据，然后将渲染后的内容返回同在 RAM 内的显示器缓存。DisplayPort 从存储器读取视视频和音频缓存，并将其输出发送至 PS-GTR，或是馈送给可编程逻辑 (PL) 做进一步处理。后，VCU 的编解码操作也依赖于进出存储器的数据。因此，您务必深入掌握第 2 章"处理器系统"中介绍的互联。同时回顾第 6 章"存储器"中对现有存储器带宽不足以满足您的应用需求的情况给出的处理建议。

另一个与多媒体有关的重要方面是软件支持。赛灵思为 Zynq UltraScale+ MPSoC 器件的多媒体功能提供基于 Linux 的软件堆栈。因此，如果您想让这些堆栈发挥作用，则需要在 APU 上运行 Linux。


图 9-1：Zynq UltraScale+ MPSoC 器件多媒体组件

GPU

VCU

Programmable Logic

PS-GTRDisplayPortDisplayPort

DDRMemory

Controller

X18927-032117





DisplayPortZynq UltraScale+ MPSoC 器件的 DisplayPort 控制器遵循纯粹 VESA DisplayPort v1.2a 源规格，为视频、图形和音频提供支持。其视频和图形流水线功能保持独立运行，直至两者混合的 α 混合级或色度键控级。图 9-2 为 DisplayPort 控制器数据流的简化视图。

实际上， DisplayPort 有两种数据源。它既可以用作 DMA 主控制器，从存储器取回非实时数据，也能从 PL 取回实时数据。其输出可提供给 PS-GTR 或 PL。图 9-3 为 DisplayPort 功能的更详细视图。


图 9-2：简化 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 控制器一部分的视频渲染流水线可以有多个输入流，但必须合并为单个视频输出。正如我们看到的， DisplayPort 有两个主要输入源：来自 PL 的实时数据和存储器中的缓存。前者从 PL 直接链接至 DisplayPort，而后者则使用直接存储器访问 (DMA) 传输。图 9-4 展示了视频渲染流水线对其各种输入流的处理。

视频流水线可设置为在下列模式下运行：

• 实时呈现模式：

° 本模式下 PL 是唯一的 A/V 数据源。取自 A/V 数据的时序信息用于驱动 DisplayPort 控制器。

• 非实时呈现模式：

° 在本模式下使用 DisplayPort DMA，通过 AXI 从存储器获取 A/V 数据。在本模式下需要软件协助才能完成正确的音频/视频同步。这是通过在 DisplayPort 控制器使用的 DMA 描述符内提供时间戳来实现的。DisplayPort DMA (DPDMA) 的特性见如下。

• 混合呈现模式：

° 该模式是前面两种工作模式的混合。


图 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





混合级可以通过 α 混合或色度键控两种方式实现，如图图 9-5 所示。

α 混合

α 混合是 DisplayPort 控制器混合两种数据源的默认方法。 α 混合是用来混合两个图像的预定义数学过程。 α 混合过程（混合矩阵、系数等）的多个参数能通过 DisplayPort 控制器里的寄存器编程。

色度键控

色度键控是层叠两个图像或视频流的视频技术，是电影摄影术中通常称为“绿屏”的方法的技术名称。该视频流水线级要求选择单一键控颜色。在流水线级出口处，键控颜色将由流水线第二数据源的内容替代。启用此功能后，它将替代流水线中的 α 混合级。


图 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 控制器还能管理来自两个独立源的音频，如图 9-6 所示。如果这两个源兼容，它们就会在流水线中混合。一个可以作为测试模式生成器、流音频或非实时音频接口 (DPDMA) 中的任意一个。另一个输入则必须作为另一个非实时音频接口。两个流可以对音量进行独立控制。

DisplayPort DMA (DPDMA)DPDMA 处理器多可以处理高达 6 个通道。与 DDR 控制器的通信通过 128 位 AXI3 主端口进行。DPDMA 使用的描述符包含 16 个不同的数据字。与 DDR 控制器使用的通用 DMA 描述符类似， DPDMA 描述符包含用于声明由描述符 (XFER_SIZE) 指向的数据的大小的字段和用于下一描述符 (ADDR_NEXT) 地址的字段。此外，该描述符还提供数个 DisplayPort 专用字段，用于描述由描述符指向的数据，包括 LINE_SIZE、 STRIDE、 TIME_STAMP_LSB、TIME_STAMP_MSB。

Linux DisplayPort 堆栈

如本章前文所述，Zynq UltraScale+ MPSoC 器件对多媒体的支持以 Linux 为中心。图 9-7 展示了赛灵思在其 Linux 包中提供的用于运行 DisplayPort 的基于 Linux 的软件堆栈。


图 9-6：MPSoC 显示控制器技术模块





DisplayPort 子系统 Linux 堆栈由 DisplayPort 硬件上的两个顶层构成：

• 位于底层的是内核层，包含 DRM、内核模式设置 (KMS)、 DMA 引擎和 ALSA 驱动。

° 直接渲染管理器 (DRM) 框架用于与图形硬件连接。

° KMS 驱动用于显示模式的设置。它是用于显示控制器的器件驱动。

° DMA 引擎用于实现 DMA 传输。

° 先进的 Linxu 音频架构 (ALSA) 为音频硬件提供器件驱动与低级支持。

• 在内核层之上的是用户层，它包含库和服务器。

° Libdrm 是一个用户库，便于用户空间与 DRM 子系统的接口。

° Libasound 是为应用程序提供 ALSA 功能的用户库。

° X11 显示服务器为 GUI 环境提供基本框架，用于在显示器件上移动和绘制窗口以及与鼠标和键盘进行交互。

° Wayland 显示服务器可替代较老的 X11 显示服务器。

° PA 音频服务器通过多个音频应用同时管理声音和音频器件的使用与访问。


图 9-7：DisplayPort Linux 软件堆栈





GPUZynq UltraScale+ MPSoC 器件的图形处理单元 (GPU) 采用 Arm Mali-400 MP2 架构，提供 2D 和 3D 加速。与 Zynq UltraScale+ MPSoC 器件的其余多媒体功能一样，GPU 的运行依赖于 Linux。在 Linux 平台上提供可支持 OpenGLES1.1 和 OpenGLES2.0 的 OpenGL 图形库，供运行在 X11 和“FBDEV 窗口系统”下的 Mali GPU 使用。图 9-8 展示了该 GPU 的原理图。

掌握 GPU 本身的运行方式以及它如何与系统其余部分进行交互的佳方法是查看进出 GPU 的数据流，如图 9-9 所示。


图 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

• • • • • • •• • • • • •





第一步，运行在 APU 上的软件使用 GL 库向 RAM 中的顶点缓存写入顶点。第二步，几何处理器对顶点进行加载和处理。第三步，把处理后的顶点写入多边形列表。第四步，由像素处理器加载多边形和纹理。第五步，渲染成终图像并存入帧缓存。

GPU 运行过程通常称为渲染流水线，其中涉及多个步骤。先从应用中提取原始数据集，然后把它渲染成图像，后将其显示在屏幕上。现代 GPU 建立在可编程流水线的概念之上。Zynq UltraScale+ MPSoC 器件的 GPU 流水线通过 GLSL API （OpenGL 着色语言）进行编程，如图 9-10 所示。


图 9-9：进出 GPU 的数据流简单视图





几何处理级基于应用发送的原始顶点数据运行。当通过绘图命令向顶点着色器馈送顶点阵列对象规定的顶点属性数据时，顶点着色器会逐个处理顶点并消除那些不需要显示的顶点。后，它把各顶点连接起来，形成需要在下一级处理的原语。随后，栅格化提取单个原语，并根据原语的样本覆盖将其分解为称为片段的离散元素。片段着色器将栅格化生成的片段处理成深度值、可能的模板值（未经片段着色器修改）、零值或更多颜色值。所有这些值都可能写入到当前的帧缓存中。

正如我们在之前的数据流图中所看到的，在执行渲染流水线的不同步骤时，涉及多个存储器到 GPU 和 GPU 到存储器的操作。在这方面， Mali GPU 采用基于块的渲染器来减少存储器传输。为了充分地理解这种基于块的渲染器的优势，我们需要查看传统的 GPU 工作方式，即快速模式。在快速模式架构下，存储在存储器中的顶点由片段渲染器处理后，逐个直接渲染。片段渲染器在每次绘图调用中在每个原语上按顺序执行，如图 9-11 所示。

每一次混合、深度测试和模板测试都需要数据的当前值，以便从 DRAM 中的片外缓存获取当前片段的像素坐标。在高分辨率下，由于每个片段要完成多个读取-修改-写入操作，系统存储器上的带宽负载可能特别高。 GPU 需要工作于较高频率下，这也要求外部存储器在比常规系统存储器更高的频率下运行。这些考虑因素提高了 GPU 的能源需求。

Mali GPU 使用不同方法来大限度地减少渲染期间完成的存储器事务数量。 Mali 使用基于块的渲染技术。在该技术中，块一般是一个正方形区域，覆盖了帧缓存中一定数量像素。操作的块在片上 GPU 存储器缓存中保持。此缓存负责保持当前正在渲染的块的帧缓存内容。基于块的渲染能大限度地降低到片外存储器的帧缓存内容流量，从而降低带宽和存储器总线性能要求。Arm Mali 使用两次通过渲染策略，如图 9-12 所示。这种策略在第一次通过时执行所有几何处理，在另一次通过时执行所有片段处理。在几何处理阶段中， Mali 把渲染区域分解成 16x16 的像素块。片段着色器核逐一完成每个块的处理，然后再进行下一个块的处理。对 Mali 400 来说，两个像素处理器能一次性渲染两个块，从而提高 GPU 的吞吐量。


图 9-10：Zynq UltraScale+ MPSoC 器件基于 Mali 400 的 GPU 流水线

Geometry Processing Pixels Processing

Application Vertex Setup Vertex Shader Rasterizer Fragment Shader Frame buffer

Texturing

• • • • • • •• • • • • •


图 9-11：快速模式渲染器数据流

GPU Vertex Shader FIFO Fragment Shader

DDR Attributes Textures FramebufferWorking Set

X18928-032117





除了大限度减少去往外部存储器的事务量，该技术还有另一大优势。具体而言，位于 GPU 存储器的块使多种图形算法的高效率应用成为可能，从而无需从主存储器获取顶点数据。

几何处理器

现在我们已经介绍了 GPU 的总体功能，让我们更详细地了解几何处理器及其内部组件，如图 9-13 所示。几何处理器在待渲染成图像的顶点上执行数据处理。顾名思义，几何处理器与图像几何有关，负责通过使用 GL 库 API 在提供的数据上执行数学运算。


图 9-12：基于块的渲染器数据流


图 9-13：Mali GPU 几何处理器原理图

GPU Vertex Shader Tiler Fragment Shader

DDR Attributes

LocalTile Memory

GeometryWorking Set Textures Compressed

Framebuffer

X18929-032117

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)

多边形列表生成器 (PLB) 可创建供像素着色器进行操作的多边形列表。如上文所述， Mali GPU 把渲染区域划分为多个块，然后逐块将其渲染。 Zynq UltraScale+ MPSoC 器件的 Mali 400 上的两个像素处理器分别并行处理一对块。但是在这些像素处理器开展工作之前， PLB 必须生成需要在每个块中渲染的多边形列表，并且在它们被其他多边形隐藏时丢弃一部分。

像素处理器

一旦几何处理器准备好多边形，它们就被移交给像素处理器，由像素处理器负责处理 GPU 流水线的片段着色器阶段。图 9-14 展示了每个像素处理器的原理图。

每个像素处理器的方式工作如下：

1. 三角形设置单元可以将作为输入的三角形构建为由 PLB 生成的多边形列表。


图 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





2. 栅格化将输入数据分为独立的片段。被渲染的片段进入下一阶段，而那些不可见的片段就会被丢弃。

3. 片段着色器核可为来自原语的每个片段计算外观。

4. 混合单元把计算出的片段混合到块缓存中，用于生成终图像。片段混合方式是可配置的：片段可以不透明或部分透明。在该阶段也应用抗混叠方式，这是一种能在低分辨率下保持图像边缘外观良好的方法。

5. 块缓存模块对之前阶段完成的块进行处理，在片段上执行多项测试，以避免在屏幕上对它们做无用渲染。

6. 写回单元把块缓存内容写入到系统存储器中。

Linux GPU 软件堆栈

与其他多媒体组件一样，Zynq UltraScale+ MPSoC 器件对 GPU 的支持同样以 Linux 为中心。图 9-15 展示了赛灵思在其 Linux 软件包里提供的用于运行 GPU 的基于 Linux 的软件堆栈。

Linux GPU 软件堆栈有多个层次：

• 底层是 Mali 内核驱动。该层可为 MMU、 GP、 PP、 L2 高速缓存和 PMU 等多个硬件组件提供驱动。

• 驱动上层为用户库：

° Mali 通用用户库包含 GPU 通用库。

° EGL 是 OpenGL ES 或 OpenVG 等 Khronos 渲染 API 与底层原生平台窗口系统间的接口。EGL 可处理图形情境管理、表面/缓存绑定、渲染同步，并通过使用其他 Khronos API 实现高性能、加速混合模式 2D 和 3D 渲染。

° 打开图形语言 (OpenGL) 是面向 3D 图形的开放业界标准 API，用于处理纹理化三角形的硬件加速绘图。OpenGL 基本上是图形硬件的软件接口。

° OpenVG 是为硬件加速 2D 图形设计的 API。

• 位于堆栈顶层的是图形应用。


图 9-15：Linux GPU 软件堆栈





在 Arm Mali GPU 上调试

Mali 图形调试器 (MGD) 是一种能够帮助开发人员借助 GPU 使用任何 Mali 硬件来调试程序行为的工具。图 9-16 总结了它的工作方式。

MGD 帮助开发人员了解 GPU 运行情况及其应用的工作情况：

• 允许绘图调用单步

• 查看纹理使用

• 着色器统计数据

• 顶点属性

• 状态视图

• 动态优化建议

请参阅《使用 Arm Mali 图形调试器工具对 Zynq UltraScale+ MPSoC Graphics-GPU 应用进行调试》或访问维基页 [参照 19]，了解有关使用 MGD 与基于 Zynq UltraScale+ MPSoC 器件的赛灵思® ZCU102 评估套件的更多信息。


图 9-16：Mali Graphics Debugger (MGD)





VCU在部分 Zynq UltraScale+ MPSoC 器件变体中，视频编解码器单元 (VCU) 包含在可编程逻辑 (PL) 中。VCU 特别适合需要快速编解码视频数据的高要求视频应用。它支持 H.264 和 H.265 格式的同步编解码。图 9-17 提供了系统内 VCU 位置的高级视图。


图 9-17：视频编解码器单元在 Zynq UltraScale+ MPSoC 器件中的位置





VCU 拥有独立的视频编码单元和解码单元。每个单元受微控制器单元 (MCU) 控制，后者可控制来自 AXI 接口的待编码或解码的数据流。APU 向解码器或编码器 MCU 单元发出命令，以在编码时处理每一帧或在解码时处理每个片或块。命令可通过寄存器发给 MCU，或复制在主存储器中等待 MCU 读取。

VCU 的视频编码器架构如图 9-18 所示。

VCU 编码器单元拥有单个由 APU 使用的 32 位从 AXI 接口，用来与编码器单元通信，以配置编码器单元或启停编码操作。有两个 AXI 主接口，一个用来获取 MCU 指令，另一个用来加载/存储额外的 MCU 数据。由 MCU 使用的一对 128 位 AXI 接口用来提取待编码数据和写回编码后数据。VCU 内还有其他接口，用于在需要时连接编码器到需要使用的 PL BRAM 或 UltraRAM 块。 VCU 的视频解码器架构如图 9-19 所示。


图 9-18：VCU 视频编码器架构





视频解码器单元的运行架构与编码单元类似。与解码器的情况一样，两个 AXI 主接口提取待解码的数据并将解码后的数据写入存储器。

请注意， VCU 可设置为低时延模式，虽然这种模式会降低压缩质量，但却能缩短从输入到编解码器或从编解码器到输出的时延。

存储器拓扑结构

如前文所述，VCU 通过取回数据并将其存储至存储器来进行工作。作为 PL 的组成部分，VCU 可配置为通过三种不同拓扑结构使用存储器。 VCU 可配置为：

1. 通过 DDR 控制器使用 DDR RAM

2. 通过使用 PL 中的存储器接口生成器 (MIG) 与外部存储器接口，详细介绍参见第 6 章"存储器"。

3. 使用上述两种拓扑结构的组合。

所有三种配置见图 9-20 到图 9-22 所示。


图 9-19：VCU 视频解码器架构






图 9-20：使用可访问 DDRC 的 RAM 的 VCU


图 9-21：在 PL 中使用存储器接口生成器的 VCU





正如前文所述，在设计多媒体应用时，存储器带宽是需要注意的关键因素。与 GPU 和 DisplayPort 不同，通过使用 PL 中的存储器控制器比单纯使用 DDR 控制器能实现更大存储器带宽，VCU 可以选择使用 PL 的可重新配置逻辑来扩大其存储器带宽。请参阅第 6 章"存储器"了解有关存储器带宽以及在您的设计受带宽约束时，调整系统设计的选项的相关讨论。


图 9-22：在 PL 中使用 DDR RAM 和 MIG 组合的 VCU





Linux 视频编解码器驱动堆栈

和与前面介绍的多媒体组件一样，Zynq UltraScale+ MPSoC 器件对 VCU 的支持也是以 Linux 为中心。图 9-23 展示了赛灵思在其 Linux 软件包里提供的用于运行 VCU 的基于 Linux 的软件堆栈。

Linux 视频编解码器驱动堆栈由数层构成：

• 位于硬件之上的底层是内核空间，其包含 Video for Linux 2 (V4L2) 驱动和 I/O 控制 (ioctl) 内核驱动。 V4L2 是用于视频采集的标准 Linux 内核接口。 V4L2 包含用于选择采集维度和颜色格式的专用接口。它支持存储器到存储器器件。此外，还提供存储器分配和缓存等通用功能。

• 位于内核空间上一层的是用户空间。该层包含 Gstreamer/Bellagio OMX IL 库和 OpenMAX 库。

° Gstreamer 是基于流水线的多媒体框架，它将各媒体处理器系统连接在一起，以完成复杂的工作流程，例如，以一种格式读取数据，处理数据，然后以不同格式输出数据。 Bellagio OpenMAX 集成层 (OMX IL) 是一种标准 API，能访问位于相同平台上的硬件加速器。

° OpenMAX 库是一套用于多媒体编解码器和应用可移植性的跨平台 API。

• 视频应用位于该堆栈顶层。


图 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




第 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+ 器件开展进一步分析。我们在“功耗管理”一章中对此进行过阐述。即包括外设接口在内的系统块被划分为 4 个功耗域。因此，在选择要使用的外设时，必须注意您的功耗管理需求。相反，在为您的系统设计功耗管理时，需要关注所需外设和它们所属的功耗域。

下列问题在将对您有所帮助：

• 您需要哪些外设？

• 它们属于哪些功耗域？

• 您是否有外设参与系统唤醒？




第 10 章：外设

外设方法学和其他章节一样，我们将使用系统的简化视图来讨论有关外设使用的方法问题。下图重点介绍了每个功耗域中存在的外设以及它们与其他功耗域之间的交互。器件的外边界，即通过芯片引脚与外部环境相连的地方，在系统周围用灰色背景标识，作为“器件边界”。

注释：该原理图的目的并不在于准确地表示 Zynq UltraScale+ 器件的内部块。相反，它主要是一张概念图，用于解释当前概念。

如前一节所提到的，请注意，每个外设都属于一个特定的功耗域，并且在设计您的系统时需要对此关注。


图 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




第 10 章：外设

另一个需要理解的与 Zynq UltraScale+ 器件的外设和它们所属的功耗域有关的重要方面，是每个功耗域的外设与外部环境的连接方式不同。低功耗域 (LPD) 依赖多路复用 IO (MIO) 接口，全功耗域 (FPD) 依赖 PS-GTR 接口，可编程逻辑 (PL) 功耗域 (PLPD) 依赖配置 PL，以确定芯片上 PL 的引脚连接方式。一般来说，将 LPD 外设视为低速外设，而将 FPD 外设视为高速外设。

MIO 接口的多路复用可供 LPD 外设使用的 78 个引脚进行访问。引脚功能分配通过 MIO 控制器上的寄存器编程完成。这一般使用赛灵思 SDK 工具生成的第一阶段加载程序 (FSBL) 中的配置代码来实现。这是配置 MIO 控制器的推荐方法。《Zynq UltraScale+ MPSoC 技术参考手册》 (UG1085) [参照 7] 提供了引脚与外设间对应关系的详细描述。不是所有外设都能使用全部引脚，您需要根据可用的引脚谨慎考虑您的外设需求。

由于 PL 是可重新配置的，可将其一些边界 I/O 引脚配置成用于其他用途，而并不局限于 PL 中的 IP。也就是说，LPD 外设能通过使用扩展的多路复用 IO (EMIO) 布线到 PL 引脚。但也存在一些例外，例如 USB、 Quad-SPI 和 NAND 就不能通过 EMIO 进行重新布线。有关 EMIO 的使用和通过 EMIO 布线对 LPD 外设构成限制的详情，请参阅《Zynq UltraScale+ MPSoC 技术参考手册》 (UG1085) [参照 7]。不过，使用可用的 MIO 引脚满足您的外设需求时，借助 EMIO 是用于规避您设计面临的限制的方法之一。此外，还可将 EMIO 用于 AXI 主控制器对 PL 中的 IP 的访问。不过我们建议您先阅读第 5 章"可编程逻辑"，掌握将 PL 中的 IP 连接到系统其余部分的各种选项，然后再决定选择哪种方案。




第 10 章：外设

PS-GTR 是 FPD 的串行输入输出单元 (SIOU) 的组成部分，如下图中的红色高亮部分所示：

FPD 的 PS-GTR 收发器可支持 4 个数千兆位通道，提供通往 FPD 外设的外部环境访问。此外，还可将 PS-GTR 用于为 LPD 中的千兆位以太网和 USB 功能提供连接，从而分别提供 SGMI PHY 访问和 USB 3.0 功能。这四种不同的 PG-GTR 通道的工作频率介于 1.25 Gbps 到 6 Gbps 之间。对于需要通过 PS-GTR 连接的每个外设块，应先编程 PS-GTR 寄存器，为外设块分配四个 PS-GTR 通道中的一个。对于 MIO 和 LPD 外设来说，PS-GTR 所连接外设块的数量超过了自身能够同时向器件引脚布线的限度。

因此，您必须从 FPD 和 LPD 的千兆位以太网和 USB 功能外设列表中选出要连接到 PS-GTR 的外设。就千兆位以太网而言，您转而求助于用 RGMII 连接到以太网 PHY，避免使用通过 PS-GTR 提供的 SGMII。此外，您也可以将 EMIO 用于千兆位以太网，但此时的连接方式是通过 GMII，而不是 RGMII 或 SGMII。对于 USB 来说，虽然您会受到 ULPI 的限制，但是您仍然能够通过 MIO 对 USB 块进行布线。

在围绕外设设计您的系统时，另一个需要注意的有关功耗管理的方面是唤醒信号。换句话说，可将一些平台管理单元 (PMU) 通用输入 (GPI) 用于外部唤醒信号。此外，使用 ULPI 和 RGMII 可以分别在 USB 2.0 和以太网中唤醒。


图 10-2：串行输入输出单位

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




第 10 章：外设

GPIO可以使用通用 I/O (GPIO) 外设通过 MIO 模块来控制全部 78 个可用引脚。通过 EMIO，GPIO 外设还可以使用多达 96 个 PL 引脚作为输入， 192 个 PL 引脚作为输出（96 个作为真正的输出，其余作为输出使能）。用 MIO 连接的 GPIO 输出具备三态能力，即低阻抗、中阻抗和高阻抗。下图是 GPIO 外设及其通过 EMIO 与 MIO 模块与 PL 进行交互的原理图。


图 10-3：GPIO 通过 EMIO 与 MIO 和 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




第 10 章：外设

GPIO 引脚功能可以单独编程或按组编程。引脚分为编号从 0 到 5 的 6 个 bank。bank 0 到 2 通过 MIO 接口访问，bank 3 到 5 通过 EMIO 接口访问。下图展示了 GPIO 外设 bank。

使用自定义的敏感度可以在引脚上触发中断：

• 电平敏感：高或低

• 边沿敏感：上升沿、下降沿、或两者


图 10-4：GPIO bank

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




第 10 章：外设

I2CI2C 是一种简单的 2 线总线，专为与低速外设接口连接而设计。这两条线中其中一条是数据线 (SDA)，另一条线用于驱动时钟信号 (SCL)。 I2C 总线上的节点可以是主节点，也可以是从节点。主节点负责驱动总线的时钟信号，并初始化与从节点的通信。从节点负责接收时钟信号并响应主节点的请求。此外， 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




第 10 章：外设

SPI串行外设接口总线 (SPI) 能为电子组件间通信提供比 I2C 更高的速度。 SPI 总线上的节点也包括主节点和从节点。可以存在多个主节点。该协议使用 4 线通信。

• MOSI：主输出 -> 从输入

• MISO：主输入-> 从输出

• SCLK：串行时钟

• SS：从选择

将 MOSI 和 MISO 信号用于主从节点间的全双工通信。Zynq UltraScale+ 器件包含两个完全相同的 SPI 控制器，能够独立地同时由对应的软件驱动进行控制与操作。下图是 Zynq UltraScale+ 器件的 SPI 控制器的原理图。


图 10-6：DDR 控制器原理图

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




第 10 章：外设

可将 Zynq UltraScale+ 器件的 SPI 控制器设置为下列三种模式之一：

• 从模式：在这种模式下，其他连接到 SPI 总线的主节点负责驱动控制器时钟。

• 主模式：在这种模式下， SPI 控制器将负责管理从节点时钟。控制器可以通过操纵 SS 线来决定与哪个从节点对话。

• 多主节点模式：在多主节点模式下，需要在传输之间禁用控制器，以免与其他主节点发生冲突。控制器通过监控 SS 信号来检测是否有另一个控制器在使用总线。

SPI 控制器不支持直接存储器访问 (DMA)。因此，通信是通过寄存器读取和写入至控制器 AXI 接口来完成的。控制器中的 FIFO (TX 和 RX) 深度为 128 字节。将数据传输给从节点时，主节点使用相关寄存器在 TXFIFO 中写入数据。为读取来自节点的数据，主节点读取 RXFIFO。对于每一个写入 TXFIFO 的字节，就有一个字节存储在 RXFIFO 中。对于 n 个写入 TXFIFO 的字节，就有 n 个字节存储在 RXFIFO 中。在开始下一次传输前，必须由软件读取这 n 个字节。

能够将该控制器配置成在数据传输过程中自动控制从节点选线，或是把控制权交给软件。在后一种模式，即手动模式下， SPI 软件必须设置一个寄存器来启用 SS 线。

UART通用异步接收器/发射器 (UART) 是一种用于异步串行通信的简单协议。两个 UART 模块间的通信格式与传输速度是可配置的，但需要在通信建立前指定。

Zynq UltraScale+ 器件中的 UART 可支持多种参数：

• 编程波特率

• 6、 7、或 8 数据比特

• 1、 1.5 或 2 个停止位

• 奇、偶、空间、符号或无校验

注释：请参阅《Zynq UltraScale+ MPSoC 技术参考手册》 (UG1085) [参照 7]，查看完整的参数列表。

这些参数可通过 UART 控制器的专用寄存器进行更改。

控制器可分为两个部分：接收 (RX) 和发送 (TX)。每个路径都包括一个 64 字节的 FIFO 缓存。

能够将 UART 控制器设置为 4 种不同模式。其中三种用于应用或硬件测试。


图 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




第 10 章：外设

• 正常模式用于标准的 UART 操作。

• 自动回声模式把 RxD 上接收的数据路由到接收器和 TxD 引脚。

• 本地环回模式将通过 UART 发出的数据环回到接收器侧。因此，任何发出的数据都会由接收器按原样接收。

• 远程环回模式将 RxD 信号连接到 TxD 信号。在该模式下控制器不能发出任何数据。该模式可用于测试远程/主机通道 UART 接收器和发射器操作。

CAN 控制器控制器区域网络 (CAN) 总线是汽车行业用来促进车载器件间通信的标准。 Zynq UltraScale+ 器件包含两种单独的 CAN 控制器：CAN0 和 CAN1。与其他 LPD 外设一样， CAN 控制器通过 MIO 子系统或 EMIO 运行，在器件边界外进行连接。 CAN 控制器的时钟源能够设置为使用内部时钟，也可以使用外部时钟驱动。 CAN 控制器系统视图如下所示。

下图展示了 CAN 控制器的原理图。单独的存储缓存用于发送和接收数据。两个 FIFO 缓存（TXFIFO 用于发送，RXFIFO 用于接收）多能同时保持 64 条消息。此外，每个控制器还为高优先级出站消息提供专用缓存 (TXHPB)。该缓存内的消息优先级高于正常情况下通过 TXFIFO 发出的消息。


图 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




第 10 章：外设

消息滤波

在接收侧，用户定义的接收滤波器负责确定把哪个入站消息存入 RXFIFO。接收滤波器包含一个掩码和一个 ID，用于确定是把消息进一步往堆栈上方传递，还是确认并丢弃消息。

滤波器模块能保持 4 个不同的接收滤波器。通过寄存器配置，每个滤波器都能单独启用或禁用。接收到一帧数据时，先存储掩码和 ID，然后将每个启用的接收滤波器与消息中的 ID 和掩码进行比较。如果任意滤波器和消息中的对应数据相匹配，就接受消息。


图 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




第 10 章：外设

CAN 控制器模式

CAN 控制器有 5 种工作模式。模式之间的转换必须按照下面的状态机进行。

配置模式

这是控制器在重置后所处的模式。从上面的状态机可以看到，让控制器进入诊断模式之一需要首先经过配置模式。

正常模式

在这种模式下，根据 CAN 控制器规格，消息经 TX 线发送，经 RX 线接收。

休眠模式

该模式在待机过程中能为控制器节省少量功耗。处于休眠模式时，在控制器接收数据或要求其发送数据时，控制器就转换到正常模式。

环回模式（诊断）

在环回模式下，控制器将自动接收它发送的一切数据。它不会从 CAN 网络中的其他节点接收任何消息。

监听模式（诊断）

监听模式下，控制器不发送任何，但会接收由系统其他节点发出的消息。


图 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




第 10 章：外设

中断

CAN 控制器连接到通用中断控制器 (GIC)。每个 CAN 控制器使用不同的中断号。CAN0 用 55，CAN1 用 56。虽然存在多种中断源，但它们可以归为 4 大类：

• TXFIFO 和 TXHPB

• RXFIFO

• 消息传递与仲裁

• 休眠模式与总线关闭状态

NANDZynq UltraScale+ 器件包含符合 ONFI 3.1 规格的 NAND 存储器控制器。如下图所示，控制器内置支持 ONFI 规格规定的单级单元 (SLC) 和多级单元 (MLC) 纠错的纠错代码 (ECC) 接口。

NAND 控制器包含一个 AXI 从接口和一个 AXI 主接口。 AXI 从接口用于与控制寄存器连接，以便让 AXI 主接口来控制 NAND 闪存接口。在 DMA 传输过程中，无论是读还是写，NAND 控制器的 AXI 主接口都用于通过双端口 RAM 的从存储器到闪存的读取或写入。


图 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




第 10 章：外设

SD/SDIO/eMMCSD 控制器能实现对多种 SD 格式的访问，例如 SD 卡、 MMC 和 eMMC 等器件。

系统其余部分能通过 AXI 从接口访问 SD 卡。与 NAND 控制器情况非常相似，控制器中的 AXI 主接口用于 DMA 请求。

SD/SDIO/eMMC DMASDIO 控制器符合 SD 控制器规格并根据该规格中的规定执行 DMA。该规格定义了两种 DMA 接口。一种称为 ADMA（高级 DMA），另一种称为 SDMA （单操作 DMA）。 Zynq UltraScale+ 器件支持两种 DMA 模式。

SDMA

SDMA 未使用描述符，但使用了用于读取或写入的单地址。 SD 卡控制器负责预测传输地址，以及需复制并传递到其寄存器的块数量和块大小。在完成每个块的传输后，控制器触发中断，让应用更新数据源寄存器。对于大数据量传输来说，这种做法会成为 CPU 的一个瓶颈，并限制 SDMA 的性能。因此， ADMA 成为使用 SD 控制器完成 DMA 操作的首选方法。

使用 SDMA 的正确步骤参见 SD 主机控制器规格 1.0 中的介绍。

ADMA

ADMA 的 SD 规格描述了 DMA 描述符，其类似于由系统范围的分散聚集 DMA 支持的混合描述符。与 SDMA 的不同之处在于，使用 ADMA 时无需中断 CPU，控制器就能处理多个传输事务。ADMA 支持两个版本。ADMA1 只支持 4 KB 传输规模，而 ADMA2 支持任何传输规模。两种版本的 ADMA 协议都在 SD 主机控制器规格 3.0 版中有所描述。

SD/SDIO/eMMC PIO此外， SDIO 控制器还提供一个编程 IO (PIO) 接口，能通过控制器寄存器直接访问内部传输缓存。 PIO 模式请求通过控制器的从接口，因此是一种无需 DMA 就可以实现 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




第 10 章：外设

QSPIZynq UltraScale+ 器件的 Quad-SPI 控制器包含两种控制器，分别是通用 Quad-SPI 控制器和传统 Quad-SPI 控制器。下图是 Quad-SPI 控制器原理图。

两个控制器间的切换可通过寄存器编程来实现。传统 Quad-SPI 控制器在启动过程中起重要作用，因为它支持对启动过程第一阶段有帮助的片上执行 (XIP)。如需了解有关在启动过程中如何使用 XIP 的更多信息，请参阅“存储器”一章。


图 10-13：QSPI 控制器顶层原理图

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




第 10 章：外设

通用 QSPI 控制器

通用 Quad-SPI 控制器是一种有 4 条数据线路而不是 1 条数据线路的 SPI 控制器。为了减少线数，通信以半工方式进行，而不像简单的 SPI 控制器采用全双工方式。通用 Quad-SPI 控制器支持 SPI 协议的全部特性。它采用基于命令的接口。发送给控制器的命令必须通过通用命令 FIFO 中的寄存器编程才能写入，如下图所示。

与 SPI 控制器不同，因为通用 Quad-SPI 控制器既支持 DMA 传输也支持编程 IO，所以它同时包含 AXI 主控制器和 AXI 从设备。

DMA

通用 Quad-SPI 控制器 DMA 不使用描述符。每个 DMA 请求都需要通过编程将数据目的地和大小进行配置，以便在控制器中正确的寄存器中进行传输。

I/O 模式

在这种模式下，客户端使用寄存器直接从 RXFIFO 和 TXFIFO 缓存中读取。

传统 QSPI 控制器

传统 Quad-SPI 控制器只能工作在线性地址模式下。在该模式下，与控制器连接的闪存充当使用 AXI 接口的只读存储器的作用。在传统模式下，知晓向控制器写入命令，但会被忽略。


图 10-14：通用 QSPI 控制器原理图

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




第 10 章：外设

闪存布局

通用 Quad-SPI 控制器能以两种不同方式连接到两个 SPI 闪存，如下图所示。


图 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




第 10 章：外设

在堆栈模式下，使用芯片选择信号能指定访问两片存储中的哪一个。通过使用控制器 stripe 命令，能够对控制器进行配置，以在两个存储器之间分割数据。在使用 stripe 功能后，将均等位置上的字节发送到低位数据总线，而将其余的数据字节发送到高位数据总线。

此外，传统 Quad-SPI 控制器也支持双通道模式，此时单条数据总线同时与两个闪存相连。选择其中哪一个存储器由数据总线选择字段控制。

千兆以太网控制器Zynq UltraScale+ 器件包含 4 个千兆以太网控制器，能实现 10/100/1000 Mb/s 的以太网 MAC。以太网控制器根据具体配置，可支持多种媒体独立接口。当使用 EMIO 通过 PL 引脚对控制器进行布线时，使用千兆位媒体独立接口 (GMII)。当通过 MIO 对控制器进行布线时，使用简化的千兆位媒体独立接口 (RGMII)。当通过 PS-GTR 对控制器进行布线时，使用串行千兆位媒体独立接口 (SGMII)。下图是以太网控制器原理图。


图 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




第 10 章：外设

MAC 过滤

以太网控制器支持 MAC 过滤。控制器将收到的数据包与控制器配置作比较，查看是否应把数据包写入 FIFO，用于 DMA 或 PIO 传输。

混杂模式

当以太网控制器以混杂模式设置时，所有有效的帧都会被复制到存储器中。

特定地址

控制器多能为 4 个特定地址配置成滤波器。当从其中一个地址接收到这样的帧时，就会被复制到 FIFO。

广播地址

控制器可配置为拒绝或接受广播包。

暂停帧

暂停帧是定义在 IEEE 802.3x 标准中的流程控制特性。通过配置， Zynq UltraScale+ 器件的以太网控制器能禁用对暂停帧的复制。

VLAN 支持

可将 MPSoC 以太网控制器配置成能够只接收以特定虚拟 LAN (VLAN) 为目的地的数据包。

网络唤醒 (WOL)以太网控制器上的接收块通过检测下列事件，支持网络唤醒 (WOL)：

• 魔术封包 (magic packet)

• 到器件 IP 地址的地址解析协议 (ARP) 请求

• 特定地址 1 滤波器匹配

• 多播散列滤波器匹配

如果检测到任何上述事件，就会触发唤醒中断。

千兆以太网 DMA以太网控制器支持分散/聚集 DMA。描述符不使用固定格式，这要取决于控制器的工作模式以及是否使用缓存接收 (RX) 或发送 (TX) 数据。根据是否在控制器中启用 64 位寻址或时间戳采集（见下文介绍），描述符大小可在 64 位和 196 位间变化。

DMA 描述符的准确结构参见《Zynq UltraScale+ MPSoC 技术参考手册》 (UG1085) [参照 7] 中的介绍，但是他们包含下列重要字段：

• 待发送数据的存储器地址

• 卸载校验和状态

• VLAN 标签和优先级





第 10 章：外设

Zynq UltraScale+ 器件的以太网控制器在发送和接收路径上都建有数据包缓存，从而协助 AXI DMA 的传输。DMA 控制器结构及其包含的数据包缓存如下图所示。此外，该数据包缓存还全面支持校验和卸载，只需把完整的数据包存放在存储器内以备检查。数据包存储还允许控制器在发生冲突时自动重新尝试发送数据包。

卸载校验和

Zynq UltraScale+ 器件的以太网控制器能够用于在 TX 和 RX 两个方向来执行校验和卸载。

在接收到数据包并启用校验和卸载功能时，能验证 IPv4 数据包、TCP 数据包和 UDP 数据包的校验和报头。控制器在用于处理接收的描述符中保留校验和验证结果。如果校验和无效，控制器将丢弃这个数据包。

当发送数据包时，通过对正在传输的帧进行自动协议检测，为存储在数据包缓存中的每个数据包计算校验和。校验和在 UDP、 TCP 和 IPv4 数据包上进行计算。

USBZynq UltraScale+ 器件 USB 3.0 控制器包含两个独立的双功能器件 (DRD) 控制器。该控制器能通过 AXI 从接口提供 xHCI 功能。此外，该控制器还提供使用 AXI 主接口来传输数据的 DMA 接口。

下图是 Zynq UltraScale+ 器件上的 USB 控制器的高级视图。AXI 总线可以访问 USB 控制器的配置状态寄存器 (CSR)，后者负责控制每个 USB DRD 控制器的设置状态。


图 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




第 10 章：外设

根据需要支持的 USB 版本以及 USB 控制器是否通过 MIO 或 PS-GTR 连接，支持下表中列出的标准 USB 协议速度。


图 10-18：Zynq UltraScale+ 器件 USB 3.0 原理图

表 10-1：USB 3.0 控制器配置

配置 PHY 接口超高速高速全速低速

USB 2.0 主机 ULPI 有有有

USB 2.0 设备 ULPI 有有有

USB 2.0 OTG ULPI 有有有

USB 3.0 主机 (xHCI) PIPE3 有有有有

USB 3.0 设备 PIPE3 有有有

USB 3.0 OTG IPIE3 有有有有（限主机）

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




第 10 章：外设

PCI ExpressZynq UltraScale+ 器件上的集成块可实现 PCI Express 基本规格修订版 2.1。 Zynq UltraScale+ 器件既能够作为 PCIe 端点，也能够作为 PCIe 根端口。PCIe 根端口是一个能托管其他 PCIe 器件并与之进行通信的器件，而 PCIe 端点是一个能用作根端口客户端的器件。下图是 Zynq UltraScale+ 器件 PCIe 控制器的原理图。

由于 PCIe 本质上是一个总线，并且 Zynq UltraScale+ 器件的内部互联是基于 AXI 的，而 PCIe 控制器的重要组件之一是 AXI-PCIe 桥接，用来将内部 AXI 互联与管理 PCIe 端点的块进行连接。这样通过使用 AXI 传输事务，内部组件就能与 PCIe 连接的器件通信。

功耗管理

虽然 PCI Express 基本规格修订版 2.1 说明了四种可能的功耗管理状态，但 Zynq UltraScale+ 器件内的 PCIe 控制器只支持两种功耗管理级别，即 L0 和 L1。此外，还需注意的是该控制器不支持开源状态的功耗管理器 (ASPM)。 L0 与 L1 间的切换可由编程功耗管理器 (PPM) 手动控制。

安全性

PCIe 控制器的 AXI 主控制器能使用 TrustZone 安全与非安全分类生成传输事务，如“资源隔离与分区”章节所述。可通过控制器编程接口中的寄存器编程功能对每个地址转换和每个 DMA 通道的分类进行配置。


图 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




第 10 章：外设

DMAZynq UltraScale+ 器件的 PCIe 控制器可支持一种形式的分散聚集 DMA，并包含一个 4 通道 DMA 引擎。可以将每个通道编程为接收或发送。如下图所示， PCIe DMA 可使用 3 种不同的 DMA 描述符。

SRC-SGL 是源数据的分散聚集列表，而 DST-SGL 则对应目标数据。此外，DMA 引擎还可以使用描述符列表来保持每个源和目标描述符的状态。源和目标描述符都使用上图中所定义的 STAS/STAD-SGL 格式。当传输完成时；SRC-SGL 描述符的读取源数据出错时；DST-SGL 描述符的数据写入目的地出错时， DMA 引擎会更新这些描述符。

因为 Zynq UltraScale+ 能用作端点，因此在所谓的双 CPU 控制模式下，可将 DMA 引擎配置为与主机（即根端口）共同分担 DMA 功能。在这种情况下，主机 CPU 和 AXI CPU 能够共同分担对 DMA 的控制。也可将 DMA 配置为在单 CPU 控制模式下操作，此时主机完全控制 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




第 10 章：外设

SATA串行 ATA 或 SATA 协议的设计用于替代早期个人计算机中使用的并行 ATA 协议 (IDE)。 Zynq UltraScale+ 器件拥有两个 SATA 控制器，用于支持 1 代到 3 代 SATA 并提供下列特性：

• 符合 AHCI v1.3

• 支持 1.5、 3.0 和 6.0 Gb/s 的数据速率

• 拥有内置 DMA 的 64 位 AXI 主端口


Zynq UltraScale+ MPSoC 器件的 SATA 控制器原理图如下图所示。命令层、传输层、链路层、PHY 控制器层与《SATA 主控制器接口标准》规定的对应层。

SATA 安全性

SATA 控制器能够在自己的主端口和从端口上对 TrustZone 进行强制安全访问。完整的详细介绍见《Zynq UltraScale+ MPSoC 技术参考手册》 (UG1085) [参照 7] 中的本链接。

DMA在 Zynq UltraScale+ 器件的 SATA 控制器中实现的 DMA 特性，基于串行 ATA 高级主控制器接口 (AHCI) 中定义的 DMA 协议。


图 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


http://china.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xSATAHostTrustZoneSupport



第 10 章：外设

DisplayPort有关 Zynq UltraScale+ 器件的 DisplayPort 功能性介绍，请参阅第 9 章"多媒体"。




附录 A

附加资源与法律提示

赛灵思资源如需了解答复记录、技术文档、下载以及论坛等支持性资源，请参阅赛灵思技术支持。

解决方案中心如需了解设计周期各阶段有关器件、软件工具和 IP 等的技术支持，请参阅赛灵思解决方案中心。相关专题包括设计辅助、建议和故障排除提示等。

Xilinx Documentation Navigator 与设计中心Xilinx® Documentation Navigator (DocNav) 提供了访问赛灵思文档、视频和支持资源的渠道，您可以在其中筛选搜索信息。打开 DocNav 的方法：

• 在 Vivado IDE 中，单击“Help > Documentation and Tutorials”。

• 在 Windows 中，单击“Start > All Programs > Xilinx Design Tools > DocNav”。

• 在 Linux 命令提示中输入 docnav。

赛灵思设计中心（Xilinx Design Hubs）提供了根据设计任务和其他话题整理的文档链接，您可以使用链接了解关键概念以及常见问题解答。访问设计中心：

• 在 XDocNav 中，单击“Design Hubs View”视图。

• 在赛灵思网站上，请参阅设计中心页面。

注释：如需了解更多有关 Documentation Navigator 的信息，请参阅赛灵思网站上的 Documentation Navigotor。

参考资料1. 《Xilinx Power Estimator 用户指南》 (UG440)

2. 《UltraScale 架构配置用户指南》 (UG570)

3. 《Vivado Design Suite 教程：部分重配置》 (UG947)

4. 《UltraFAST 设计方法指南（适用于 Vivado Design Suite）》 (英文版、中文版)



http://china.xilinx.com/support

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

http://china.xilinx.com/cgi-bin/docs/ndoc?t=design+hubs

http://china.xilinx.com/cgi-bin/docs/rdoc?t=docnav

https://china.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug440-xilinx-power-estimator.pdf

https://china.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug570-ultrascale-configuration.pdf

https://china.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug947-vivado-partial-reconfiguration-tutorial.pdf

https://china.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug949-vivado-design-methodology.pdf

https://china.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug949-vivado-design-methodology.pdf

https://china.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=c_ug949-vivado-design-methodology.pdf


附录A：附加资源与法律提示

5. 《Zynq UltraScale+ MPSoC：软件开发指南》 (UG1137)

6. 嵌入式能源管理接口规格 (UG1200)

7. 《Zynq UltraScale+ MPSoC 技术参考手册》 (UG1085)

8. 《Zynq UltraScale+ MPSoC OpenAMP：入门指南》 (UG1186)

9. 《SDSoC 环境教程：简介》 (UG1028)

10. 赛灵思白皮书：发挥 Zynq UltraScale+ MPSoC 无与伦比的功耗与灵活性优势 (WP470)

11. 《赛灵思软件开发套件 (SDK) 用户指南：系统性能分析》 (UG1145)

12. 赛灵思功能安全设计流程解决方案产品简介 (PB015)

13. 赛灵思技术不仅可降低 IEC61508 和 ISO26262 认证安全应用的风险，同时还能提高效率白皮书 (WP461)

14. 赛灵思软件开发套件 (SDK) 网页：https://china.xilinx.com/products/design-tools/embedded-software/sdk.html

15. 赛灵思 Vivado Design Suite 网页：https://china.xilinx.com/products/design-tools/vivado.html

16. 赛灵思隔离设计流程网页：https://china.xilinx.com/applications/isolation-design-flow.html

17. 部分重配置网页：https://china.xilinx.com/products/design-tools/vivado/implementation/partial-reconfiguration.html

18. 异构 MPSoC 网页：https://china.xilinx.com/products/silicon-devices/soc/zynq-ultrascale-mpsoc.html#productTable

19. 使用 Arm Mali 图形调试器工具 (ARM Mali Graphics Debugger Tool) 进行 Zynq UltraScale+ MPSoC Graphics-GPU应用调试维基页：http://www.wiki.xilinx.com/Zynq+UltraScale%EF%BC%8BMPSoC+Graphics-+GPU+application+debugging+using+ARM+Mali+Graphics+Debugger+tool


http://china.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug1137-zynq-ultrascale-mpsoc-swdev.pdf

https://china.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1200-eemi-api.pdf

http://china.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf

https://china.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug1186-zynq-openamp-gsg.pdf

https://china.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug1028-sdsoc-intro-tutorial.pdf

https://china.xilinx.com/support/documentation/white_papers/wp470-ultrascale-plus-power-flexibility.pdf

https://china.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug1145-sdk-system-performance.pdf

https://china.xilinx.com/publications/prod_mktg/safety-guidelines.pdf

https://china.xilinx.com/support/documentation/white_papers/wp461-functional-safety.pdf

https://china.xilinx.com/products/design-tools/embedded-software/sdk.html

https://china.xilinx.com/products/design-tools/vivado.html

https://china.xilinx.com/applications/isolation-design-flow.html

https://china.xilinx.com/products/design-tools/vivado/implementation/partial-reconfiguration.html

https://china.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）资料均按

“现状”提供，且不保证不存在任何瑕疵，赛灵思在此声明对资料及其状况不作任何保证或担保，无论是明示、暗示还是法定的保证，包括但不限于对适销性、非侵权性或任何特定用途的适用性的保证；且（2）赛灵思对任何因资料发生的或与资料有关的（含对资料的

使用）任何损失或赔偿（包括任何直接、间接、特殊、附带或连带损失或赔偿，如数据、利润、商誉的损失或任何因第三方行为造成

的任何类型的损失或赔偿），均不承担责任，不论该等损失或者赔偿是何种类或性质，也不论是基于合同、侵权、过失或是其他责任认定原理，即便该损失或赔偿可以合理预见或赛灵思事前被告知有发生该损失或赔偿的可能。赛灵思无义务纠正资料中包含的任何错误，

也无义务对资料或产品说明书发生的更新进行通知。未经赛灵思公司的事先书面许可，贵司/您不得复制、修改、分发或公开展示本资料。部分产品受赛灵思有限保证条款的约束，请参阅赛灵思销售条款： http://china.xilinx.com/legal.htm#tos；IP 核可能受赛灵思向

贵司/您签发的许可证中所包含的保证与支持条款的约束。赛灵思产品并非为故障安全保护目的而设计，也不具备此故障安全保护功

能，不能用于任何需要专门故障安全保护性能的用途。如果把赛灵思产品应用于此类特殊用途，贵司/您将自行承担风险和责任。请参阅赛灵思销售条款：http://china.xilinx.com/legal.htm#tos。关于与汽车相关用途的免责声明

如将汽车产品（部件编号中含“XA”字样）用于部署安全气囊或用于影响车辆控制的应用（“安全应用”），除非有符合 ISO 26262 汽车安

全标准的安全概念或冗余特性（“安全设计”），否则不在质保范围内。客户应在使用或分销任何包含产品的系统之前为了安全的目的全

面地测试此类系统。在未采用安全设计的条件下将产品用于安全应用的所有风险，由客户自行承担，并且仅在适用的法律法规对产品责任另有规定的情况下，适用该等法律法规的规定。

© Copyright 2017 年赛灵思公司版权所有。Xilinx、赛灵思标识、Artix、ISE、Kintex、Spartan、Virtex、Vivado、Zynq 及本文提到的其它指定品牌均为赛灵思在美国及其它国家的商标。所有其它商标均为各自所有方所属财产。


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

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



zynq ultrascale+ mpsoc - xilinx

Documents