FPGA Xilinx Zynq 系列（七）Zynq 设计指南( 如何使用？) 之 设计流程概述

今天给大侠带来FPGA Xilinx Zynq 系列第七篇，本篇内容目录简介如下：

3. Zynq 设计指南(“ 如何使用它？”)

3.2 设计流程概述

3.2.1 需求和技术参数

3.2.2 系统设计

3.2.3 硬件开发和测试

3.2.4 软件开发和测试

3.2.5 系统集成和测试

本系列分享来源于《The Zynq Book》，Louise H. Crockett, Ross A. Elliot,Martin A. Enderwitz, Robert W. Stewart. L. H. Crockett, R. A. Elliot, M. A. Enderwitz and R. W. Stewart, The Zynq Book: Embedded Processing with the ARM Cortex-A9 on the Xilinx Zynq-7000 All Programmable SoC, First Edition, Strathclyde Academic Media, 2016。

Zynq 设计指南(“ 如何使用它？ ”)

3.2 设计流程概述

在满足 Zynq 设计的软硬件需求之后，接下来返回到我们第 1 章中提到过的 开发流程的话题。图 3.2 展现的是包含相关联的设计工具的参照的增强图。这将在接下来几页中作为我们的讨论基础。

图 3.2: Zynq 片上系统设计流程 （扩展模型）

上图描述的是一个单独设计者所需要完成的流程，如果他想要单独完成一个设计的话，并且这就是完成接下来的练习样例的过程。在 3.2 节中，同样会考虑团队开发流程，这与当前的工业开发更加贴近，Vivado 设计套件同样也适合这样的任务。

3.2.1. 需求和技术参数

任何项目都始于基于项目的需求评估目标系统的技术参数。毫无疑问，在着手实际的设计工作以前，尽可能完整和准确地定义系统参数是非常重要的。

技术参数包含很多方面，比如该设计的计划功能、接口、性能标准以及目标设 备或平台。尽管最初的规范已经在最初的时候就被详细定义，但是随着项目的推进，它很可能会变化，细节的层次也会被扩展。规范的具体内容当然取决于项目的要求和范围。

3.2.2. 系统设计

系统架构的设计通常采用自上而下的方法。其意思是先定义顶层的接口和参 数，再确定底层的子系统或功能。而子系统的功能和所需求的性能，以及两者之间的联系，将会在这之后定义。这个阶段的成果通常是对于组件和事务的抽象描述。由于对设计的复杂度不同，这些子系统可能会在更低的层级上被分解。

在定义完了功能单元后，设计必须被适当地分割为硬件和软件，而系统定义中 各个部分之间需要必要的通信。一般来说，软件 （在 PS 端）常常用来完成一些一般性的顺序执行的任务，比如操作系统、用户应用程序以及图形界面，而偏向于数据流计算的任务则更加适合于在 PL 端实现。另外，那些具有并行限制的软件算法，也应该考虑在 PL 端实现；这比较近似于 “ 协处理器 ” 模型，可以把处理器从那些重在计算并且具有并行性的任务中解放出来，改为硬件处理，从而在整体上提升性能。

Zynq的一个特别的优势就是处理器和可编程逻辑之间的强耦合，即两者部署于 同一设备上。在 PS 和 PL 之间以低延时，高性能的 AXI 连接，这允许性能不同的两种资源可以在系统被分割为软件和硬件两部分时同时发挥其最高性能。这是由于与两者分离系统相比，这种模式在通信开销上有大量减少。

关于 Zynq 体系结构的知识能够使设计者更加适当地使用一些特殊资源，比如 PS 上的 NEON 和 FPU，以及 PL 上的 BlockRAMs 和 DSP48E1 芯片。对外部通信的高速接口也已经在设备中集成并随时可以使用。很明显 Vivado 流程把重点放在了系统设计上。通常 Vivado IDE 作为设计起点， 会在顶层设计的创建过程中起到 “ 驾驶舱 ” 一样的作用。套件内工具和其他部分（特别是 System Generator 和 Vivado HLS）的集成支持多种功能设计不同的子系 统。当硬件设计完成后，它就会被导出到 SDK 进行软件开发，如果需要的话，还可以在 SDK 和 VivadoIDE 之间进行设计上的迭代。在团队开发方案中，软件设计也许会和硬件设计并行推进。

3.2.3. 硬件开发和测试

硬件系统开发包括在 PL 上设计和实现的外部模块和其他逻辑单元，在这些模块 和 PS 之间创建合适的连接，以及恰当的配置 PS。举例来说一个硬件系统可能会包括一个 CAN 总线接口、一个调试用的 UART 接口、以及 GPIO，这些和协处理器一起支持软件在 ARM 上的运行。该系统参考图 3.3。硬件系统开发由 Xilinx 的 Vivado IDE 开发套件承担，开发者可以从 IP 库中选 出模块来组成所期望的系统的框图，配置模块参数，以及设计合适的内部连接和外部接口。这一过程由 Vivado 组件中的 IP Integrator 承担， 图 3.4 展示了一副 IP Intergrator 设计的屏幕截图。其中有 Zynq PS 模块（见 图左下）, 一个 PS 重置模块，一个外设，以及一个 AXI 内联模块。这些模块之间主要通过 AXI 接口连接。外部接口可以在图表的右边见到。测试硬件系统有多种机制可用。首先 , 使用 IP Integrator 创建模块框图时， 会有一系列设计规则检查 (DRC)。这保证了设计最基本的完整性和正确性，比如说，检查所需求的连接是否都正确接上。框图检查通过后，系统会接下来进行综合和实现。其中每一个阶段都包含着更多对于细节流程和完整性设计的检查，然后若有需要注意的问题，Vivado 会标记出其中的错误。

这些实现于 PL 上的 IP 模块来自于：

• Xilinx 提供的库
• 第三方源
• 由用户自己或者组织内的同事设计 （内部的）

按照不同的来源分，模块可能需要由单独实体授权。那些来自于 Xilinx 库的 IP是作为已经授权的基本单元而提供的，但是那些来自第三方组织的模块却不一定如此。所有的内部 IP，以及那些未授权的第三方模块，都需要先作为独立模块验证后才能整合进系统。按照设计方法来分，这可能需要使用例如 HDL 仿真，或者 MATLAB/Sumulink 的仿真。更多的关于创建，测试，管理 IP 的讨论，将在后续介绍。

图 3.3: 使用 MIO 的示例硬件系统概念图

硬件系统常常会在软件部署上去的同时得到测试，即硬件在集成系统的环境中 运行。某些用户特定的信号可以通过在 IP Integrator 中标识调试信号 （marked for debug）的方式进行特定的硬件测试。之后，通过运行硬件系统上的软件功能， 这些信号将会能在主机的波形查看器上进行查看。另一种强大的硬件调试方法被称为硬件环路测试 (HIL)。使用这种方式，部分 设计在开发板上运行的同时，信号可被返回到仿真环境进行观察。例如，Xilinx 提供一个教程，教程中 PS 端在板子上运行，而 PL 组件则在仿真器中运行。这为在真实 PS 环境下详细观察 PL 信号提供了机会。当硬件系统设计迭代完成后，工程将被导出到 SDK 进行软件设计。然后包括返 回到 Vivado 进行 IP Integrator 设计的修改，或者更多的设计内容从软件实现划分到硬件实现。设计团队可能采取软硬件分组编程的方法或者并行地对两方面进行迭代。

图 3.4: Integrator 框图示例

3.2.4 软件开发和测试

鉴于 Zynq 是一个灵活的平台 , 硬件系统上运行的软件可以有所不同。从 Vivado 导出到 SDK 的项目代表为软件的平台而定制的硬件，它常常被成为 “ 基础硬件系统” 或者 “ 硬件平台 ”。硬件平台对应在 IP Integrator 中的配置，系统模型如图 3.4 所示。软件系统可以被认为是建立于基于硬件的系统上的一个栈，或者说是一系列 层，如图 3.5 所示。在基础硬件系统上一层的是板级支持包（BSP），它提供底层的驱动和函数供下 一层 （操作系统）使用和硬件通信；软件应用程序则运行于操作系统之上 —— 这些共同构成了上层软件，它们和硬件平台抽象分离。

图 3.5: Zynq 设计的软硬层次

创建完软件栈后，设计上的首选就是决定将使用的操作系统：它可以是例如 Linux 或者 Android 这样的成熟的操作系统；也可以是嵌入式操作系统；对于时序严格确定的程序则可选用实时操作系统 (RTOS) ；或者是 Standalone，一个轻型的包含大多数基本函数的 “ 操作系统 ”。软件也可以直接和硬件通信，这也就是常常被提及的 “ 裸跑 ” 应用。由于是双核架构，所以也可能部署两个不同的操作系统，每一个使用一个核心。这一主题在 《Zynq-7000 All Programable SoC Software Developers Guide》[33] 中的介绍部分有所概括。BSP 会针对硬件基础系统进行调整，以保证操作系统在给定的硬件上有效地工 作。

BSP 是为基础硬件系统和操作系统定制之间的连接定制的，包括硬件参数，设备驱动，以及底层操作系统函数。因此，在 Vivado/SDK 开发期间，如果对基础硬件系统进行了调整，那么 BSP 也需要被更新。SDK 提供了创建 BSP 以及开发测试上层软件的环境。同样也支持使用第三方开发工具替代 Xilinx SDK 来创建 BSP，比如 ARM Development Studio 5(DS-5)[33],[36]。

在测试阶段，SDK 包含 Xilinx Microprocessor Debugger(XMD) 和 System Debugger(TCF) 工具，提供给该开发者在硬件平台上运行时测试软件的功能，即 HIL的一种形式。这一过程可以通过使用比特流 (.bit 文件 ) 烧写 Zynq 的 PL 端，然后 在 PS 端运行软件 (.elf 文件 ) 完成。烧写过程通常通过从主机上通过 JTAG 或者以太网下载程序完成。通过这种方法，无论是基于 PS 端和基于 PL 端的系统组件都会被部署并且成为被测试的一部分。GDB 调试器是一种更加高级的 （建立在 XMD 上）完成远程调试的方法。另一种方法是使用内建的 Vivado Simulator 在 PC 端上复现 PL 端的操作 [19]。

根据硬件系统的测试结果，设计者可以从 SDK 返回 Vivado 以做进一步的改进， 在导出硬件后先更新 BSP，然后重新开始软件设计以及测试的过程。图 3.2 中描述了这一软件硬件迭代的循环。

需要注意的是并不是所有的设计都同时需要可执行链接格式（ELF,.elf）的文 件和比特流 （BIT,.bit）文件来配置设备的。ELF 文件的作用是烧写 PS，而 BIT 文件的作用则是烧写 PL。因此如果只使用了 Zynq 中的一种设备 （PS 或者 PL），那么就只需要相应地烧写文件。

更多关于 GNU 编译器，调试和烧写工具的信息请参看《Embedded System Tools Manual》[17]。

3.2.5 系统集成和测试

系统集成在一定程度上通过设计中的软硬件部分的开发和联合测试完成。然而，还有一些其他的要素要被纳入考虑。

系统级测试将在软硬件在各自的独立开发和测试阶段完成自身的测试和验证之 后进行。即使两个部分在各自分离的情况下能够正常运行，当它们在一起运行时，也可能产生新的问题。另一种调试这种系统级问题的方法就是软硬件交叉触发器进行嵌入式联合调试。这一过程将 PL 上的 Integrated Logic Analyzer(ILA) 的硬件 调试核心和 Zynq PS 端的 Fabric Trace Module (FTM) 通过一对输出输出信号进行 连接 [20]。

当使用软硬件交叉触发器进行联合调试时，软件和硬件的开发工具会被结合起 来。这允许用户通过软件上的断点来捕获硬件的数据，对应地，硬件断点也可以在软件开发环境中中止应用程序调试 [20]。

另一个需要考虑的因素是配置设备的方法。在开发和调试的过程中，Zynq 一般 会由从主机通过 JTAG 或者以太网下载的文件来配置。然而，这并不是在这一领域最合适的方法，更一般的方法是通过闪存来引导和配置 Zynq[33],[34]。因为在系统的部署准备过程可能需要在引导时进行特定的开发和认证。

第七篇到此结束，明日将会带来第八篇，soc设计团队、使用 Vivado 进行以 IP 为重点的系统级设计、ISE 和 Vivado 设计套件等相关内容。欢迎各位大侠一起交流学习，共同进步。

END

后续会持续更新，带来Vivado、 ISE、Quartus II 、candence等安装相关设计教程，学习资源、项目资源、好文推荐等，希望大侠持续关注。

大侠们，江湖偌大，继续闯荡，愿一切安好，有缘再见！