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

xilinx

需积分: 10 22 浏览量更新于2024-07-18 收藏 7.76MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

本资源是Xilinx发布的"ultrafast-embedded-design-methodology"指南，专为Zynq UltraScale+ MPSoC（多核片上系统）的嵌入式设计提供详细的步骤和方法。该文档版本为UG1228(v1.0)，发布日期为2017年3月31日，旨在帮助工程师充分利用UltraScale+平台的优势进行高效设计。第一部分，"Introduction"章节介绍了设计的总体概念，包括系统的块级图解，以及一个称为"Vector Methodology"的设计方法，它可能是基于流水线或并行处理的理念，用于优化设计性能。此外，还提到了访问文档和支持的途径，以便用户能及时获取最新的技术和培训资源。第二章深入探讨了"Processing System"的设计。首先，设计师需明确处理需求，确定所需的处理器架构，如异构计算的概念，强调了应用处理单元(APU)在不同任务中的虚拟化支持，以及实时处理单元(RPU)的角色。这一章还涵盖了系统内部的互联机制，确保各个模块之间的高效通信。中断管理也是关键部分，对于实时性和响应性至关重要。同时，如何利用处理逻辑部分(PL)加速工作负载，以及通用目的计算加速的策略也在此处有所阐述。第三章关注"System Software Considerations"，即对系统软件需求的定义。设计者需要明确软件栈的需求，并遵循特定的系统软件方法论来开发。这部分内容涉及引导过程软件的构建，以及如何构建和维护多层次的系统软件堆栈，确保软件与硬件的协同工作。总结来说，这份Xilinx UltraFast嵌入式设计方法论提供了针对Zynq UltraScale+ MPSoC平台从硬件到软件全面设计的指导，帮助工程师优化性能、提高效率，确保系统的可靠性和稳定性。无论是处理系统的设计、软件架构还是实时性需求，都是这份文档的核心知识点。通过学习和应用这些方法，设计师可以更有效地利用UltraScale+ MPSoC的强大功能，实现高性能的嵌入式系统设计。

资源详情

资源推荐

Zynq UltraScale+ MPSoC Embedded Design Methodology Guide 16

UG1228 (v1.0) March 31, 2017

www.xilinx.com

Chapter 2: Processing System

The answers to the questions in the above diagram for each of your system's components

should be fairly straight forward. If you have continuous data streams or requests that need

to be constantly processed within certain time limits, chances are the programmable logic

(PL) is the best location to put the majority of your system's components involved in

processing those data streams or requests. If a workload doesn't fit that description but still

needs to respond deterministically (i.e. in real-time) to external events or if it's mission

critical then the RPU is probably a very good candidate. If it still doesn't fit that description

then it's probably a general-purpose computing problem that should either be taken care of

by the graphics processing unit (GPU) in case of graphics or the APU for everything else.

Still, even if on a first pass you determine that certain pieces of software should be handled

by the RPU or the APU, there might be further optimization opportunities for moving those

to the PL. If, for instance, the functionality to be achieved can be described as a fixed list of

mathematical equations, such as an FFT, and/or a known set of states or state machines,

especially if they can be run in parallel, it's probably a good candidate for embedding as

part of the PL.

One way to gauge whether moving certain functionality into the PL is beneficial is obviously

manual testing and prototyping. Xilinx, however, provides you with an even more effective

way of identifying and handling optimization candidates for the PL. Indeed, the SDSoC™

and Xilinx® SDK development tools can profile your application code and, in the case of

SDSoC, enable you to offload code sections to the PL for performance testing at the click of

a button. SDSoC will automatically compile the necessary logic into the PL, assign the

X-Ref Target - Figure 2-2

Figure 2-2: Processing Location Decision Tree

Is it continuously processing time-sensitive data?

Yes No

Is it real-time or mission critical?

Yes

RPU

Is it multimedia?

Yes

GPU*

APU

Can it be optimized to PL?

Yes

* GPU support is OS-specific

X18706-032117

Send Feedback

非常重要！

Zynq UltraScale+ MPSoC Embedded Design Methodology Guide 17

UG1228 (v1.0) March 31, 2017

www.xilinx.com

Chapter 2: Processing System

necessary data movers and software drivers to enable the rest of your APU- or RPU-bound

software to transparently use the accelerated software portions. SDSoC therefore helps

streamline the software acceleration process by greatly simplifying all steps involved. The

use of SDSoC vs. manual offloading is therefore a trade off between ease of implementation

and hand-crafted performance tuning.

An additional aspect to keep in mind is the top clock speeds of the processing blocks:

• APU – Up to 1.5 GHz

• RPU – Up to 600 MHz

• GPU – Up to 667 MHz

Note:

Keep in mind that those are top speeds. While each block can run at a maximum at those

speeds, it's very unlikely to be running at those speeds all the time nor will it necessarily make sense

for your design.

With its ARM® Cortex®-A53 processors, the APU is the fastest general purpose computing

resource on the Zynq UltraScale+ MPSoC device. At first glance it might therefore seem to

be the best candidate for workloads requiring maximum computing power, especially since

you can have up to four Cortex-A53 processors on the Zynq UltraScale+ MPSoC device.

Maximum frequency however does not necessarily mean best fit for function. The APU's

Cortex-A53 processors, for instance, are not as well suited to real-time workloads as the

RPU's ARM® Cortex®-R5 processor. Among many other factors, there's therefore a trade

off between performance and determinism in choosing between the APU and the RPU.

Once the most likely candidate blocks for housing a given functionality have been

identified, you still need to identify the best way to move data between blocks through the

interconnect and how each processing location interacts with the various processing

resources internal to the system as well as interfaces and resources within the outside

world. The interconnect and interrupt processing are discussed in detail later in this chapter.

For all aspects related to peripheral I/O, refer to

Chapter 10, Peripherals. For information

regarding the Memory, refer to Chapter 6, Memory. For more information regarding the

PL's capabilities, including its built-in accelerators, refer to Chapter 5, Programmable Logic.

Note that while the present guidelines might prescribe a given recommended processing

block, it's entirely possible that after reviewing the entire set of content related to a given

part of your design that an alternate, better-suited configuration might become evident to

best fit your specific product needs. The decision tree presented earlier, for example,

recommended using the RPU for your real-time software. Your design might, instead, call

for running a real-time operating system (RTOS) on the APU with the Cortex-R5 processors

being run bare-metal. Another example is network communications. The above

recommendations categorize network communication as being best slated for the APU. Yet,

the PL contains integrated blocks for 100G Ethernet and PCIe which, together, can be used

to efficiently accomplish network-related tasks that would typically be designated for the

APU. The Xilinx White Paper Unleash the Unparalleled Power and Flexibility of Zynq

UltraScale+ MPSoCs (WP470)

[Ref 10] describes the flexibility of the Zynq UltraScale+

MPSoC outlines such an example use-case for a data center application. It also covers two

Send Feedback

Zynq UltraScale+ MPSoC Embedded Design Methodology Guide 18

UG1228 (v1.0) March 31, 2017

www.xilinx.com

Chapter 2: Processing System

more example uses-cases, namely a central Advanced Driver Assistance System (ADAS)

module and software-defined radio (SDR), which are likely to help you get a better

understanding of how to partition your design's processing.

Yet another important aspect to keep in mind when determining where to conduct any

given part of your design's processing is power management. The architecture of the Zynq

UltraScale+ MPSoC device allows fine-grained control over power management. The power

domains illustrated in

Figure 2-1, page 14 are part of this power management as is detailed

in Chapter 4, Power Considerations. Whenever you decide to run a given workload on a

given Zynq UltraScale+ MPSoC device block, keep in mind how this choice relates to your

power management needs. If, for example, a key algorithm runs on the APU and yet you

would like to have the APU be powered down during certain periods of time then you might

want to move that algorithm to either the PL or the RPU. The APU might be the most

powerful block in the system, as was explained earlier, but it also happens to be the one

that can consume the most power.

Heterogeneous Computing Concepts

Understanding the processing capabilities of the Zynq UltraScale+ MPSoC device and the

surrounding functionality calls on several key concepts not typically used outside the field

of heterogeneous computing. This is therefore a quick introduction to some terminology

you will find being used throughout this guide and the rest of the Zynq UltraScale+ MPSoC

device documentation.

The Zynq UltraScale+ MPSoC device includes two main layers of multi-processing

components (i.e. processors working in parallel to each other.) At the first layer, there are

the main processing blocks:

•APU

•RPU

•PL

•GPU

At the second layer, there are the processing units within those blocks:

• Dual or Quad Cortex-A53 cores within the APU

• Dual Cortex-R5 processor cores within the RPU

• PL-optimized applications and/or MicroBlaze™ processor instances within the PL

• Graphics processing pipelines in the GPU

The relationship between the main components of the Zynq UltraScale+ MPSoC device is

generally considered “asymmetrical.” That is, each of the APU, RPU, PL, and GPU have

Send Feedback

Zynq UltraScale+ MPSoC Embedded Design Methodology Guide 19

UG1228 (v1.0) March 31, 2017

www.xilinx.com

Chapter 2: Processing System

different capabilities and constraints, they do not necessarily share a common OS, nor can

a workload be seamlessly moved between those blocks. Instead, designers who want to use

one of these components for a certain workload must tailor that workload specifically for

that component. This is what is called Asymmetric Multi-Processing (AMP).

Within the APU, the relationship between the Cortex-A53 processors can take four different

forms.

• If all the Cortex-A53 processor cores are used to run a single common OS such as Linux,

which is another recommended configuration, then they are said to have a

“symmetrical” relationship to one another. In this case, the common OS, Linux, can

dispatch and move workloads -- effectively OS processes -- between processors

transparently. From a software development point of view the OS API boundaries

guarantee that the software will operate just the same no matter which Cortex-A53

processor it runs on. This type of operation is known as Symmetric Multi-Processing

(SMP).

• If the Cortex-A53 processors are still operated independently, but a hypervisor such as

the open source Xen or various commercial offerings is used to coordinate their

combined operation, they would be considered as having a “supervised” asymmetrical

relationship to each other. That is, the hypervisor acts as a supervisor between the

Cortex-A53 processors and ensures there is a commonly-agreed upon arbitrator

between the independent software stacks running in parallel on the Cortex-A53

processors. Supervised AMP mode for the APU is one of the recommended

configurations in Chapter 3, System Software Considerations for certain types of

applications.

• The APU hardware should also permit a hybrid configuration. A hypervisor can be used

to segment the Cortex-A53 processors in supervised AMP mode while a subset of those

cores can be managed collectively by a single OS image in SMP mode. This however is

an advanced configuration that is neither provided nor supported by Xilinx.

• If the Cortex-A53 processors are operated independently, each running different

system software without a common OS or hypervisor between them, they too would be

considered as having an asymmetrical relationship to one another. More specifically,

they would be said to be running in “unsupervised” AMP mode, indicating that there is

no single software coordinating the operation of the Cortex-A53 processors. Note,

however, that due to the complexities of a supervised AMP configuration on the

Cortex-A53 processors, this is neither a recommended nor a Xilinx-supported

configuration for the APU, as is explained in Chapter 3, System Software

Considerations.

Finally, the APU hardware should also permit a hybrid configuration. A hypervisor can be

used to segment the Cortex-A53 processors in supervised AMP mode while a subset of

those cores can be managed collectively by a single OS image in SMP mode. This however

is an advanced configuration that is neither provided nor supported by Xilinx.

Send Feedback

剩余216页未读，继续阅读

u010634378

粉丝: 0
资源: 8

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

特别好用的种子搜索引擎

BT资源搜索助手

P2P 种子播放器3.5 最强大

ultrafast-lane-detection原理

CreateProcess(NULL, "ffmpeg -f rawvideo -vcodec rawvideo -pix_fmt bgr24 - s 640x480\" -r 30 -i - -c:v libx264 -preset ultrafast - f flv rtmp ://server/live/streamName\\\\\\\"\", NULL, NULL, TRUE, 0, NULL, NULL, &si, &pi);这一段有错吗

char cmd[] = "ffmpeg -f rawvideo -vcodec rawvideo -pix_fmt bgr24 -s 640x480 - r 30 - i pipe : 0 - c : v libx264 -preset ultrafast - f flv rtmp ://server/live/streamName "; CreateProcess(NULL, cmd, NULL, NULL, TRUE, 0, NULL, NULL, &si, &pi);

char cmd[] = "ffmpeg -f rawvideo -vcodec rawvideo -pix_fmt bgr24 -s 640x480 - r 30 - i pipe : 0 - c : v libx264 -preset ultrafast - f flv rtmp ://server/live/streamName "; 这样呢

fmpeg -f x11grab -s 1920x1080 -r 30 -i :0.0 -c:v libx264 -preset ultrafast -crf 0 -pix_fmt yuv420p -b:v 5000k output.mp4 仍然不够清晰，怎么办

ffmpeg推流命令行

ffmpeg 编码 ultrafast 码率

java FFmpeg将图片或视频转换成H264/265的编码流直接输出的测试代码

ffmpeg推流加特效代码

ffmpeg6.0 录屏并推流到rtmp

回调中获取的视频裸流如何转码推流？

ffmpeg录屏推流命令

ffmpeg 录制桌面声卡输出和麦克风输出

怎么在directshow实时采集视频的同时使用ffmpeg录制

ubuntu 上利用ffmpeg 多线程推流

ffmpeg 数据存储转发

最新资源