XILINX SDSoC Environment Tutorial
Informace o produktu
- Product Name: SDSoC Environment Tutorial
- Version: UG1236 (v2016.3)
- Datum vydání: 30. listopadu 2016
Návod k použití produktu
Creating a Platform from a Reference Design:
To create a platform from a reference design using the SDSoC Environment Tutorial, follow these steps:
- Access the SDSoC Environment software on your system.
- Open the reference design that you want to use as a base for your platform.
- Follow the instructions provided in the SDSoC Environment Tutorial to customize and modify the reference design according to your requirements.
- Save the modified design as a new platform for your project.
Architecture of an SDSoC System
To ensure program correctness, the system compiler intercepts each call to a hardware function,
and replaces it with a call to a generated stub function that has an identical signature but with a
derived name. The stub function orchestrates all data movement and accelerator operation,
synchronizing software and accelerator hardware at the exit of the hardware function call. Within
the stub, all accelerator and data mover control is realized through a set of send and receive APIs
provided by the sds_lib library.
When program dataflow between hardware function calls involves array arguments that are not
accessed after the function calls have been invoked within the program (other than destructors
or free() calls), and when the hardware accelerators can be connected using streams, the
system compiler transfers data from one hardware accelerator to the next through direct
hardware stream connections, rather than implementing a round trip to and from memory. This
optimization can result in significant performance gains and reduction in hardware resources.
At a high-level, the SDSoC program execution model includes the following steps:
1. Initialization of the sds_lib library occurs during the program constructor before entering
main().
. Within a program, every call to a hardware function is intercepted by a function call into a
stub function with the same function signature (other than name) as the original function.
Within the stub function, the following steps occur:
a. A synchronous accelerator task control command is sent to the hardware.
b. For each argument to the hardware function, an asynchronous data transfer request is
sent to the appropriate data mover, with an associated wait() handle. A non-void return
value is treated as an implicit output scalar argument.
c. A barrier wait() is issued for each transfer request. If a data transfer between
accelerators is implemented as a direct hardware stream, the barrier wait() for this
transfer occurs in the stub function for the last in the chain of accelerator functions for
this argument.
3. Clean up of the sds_lib library occurs during the program destructor, upon exiting main().
TIP: Steps 2a–2c ensure that program correctness is preserved at the entrance and exit of accelerator pipelines
while enabling concurrent execution within the pipelines.
Sometimes, the programmer has insight of the potential concurrent execution of accelerator
tasks that cannot be automatically inferred by the system compiler. In this case, the sds++
system compiler supports a #pragma SDS async(ID) that can be inserted immediately
preceding a call to a hardware function. This pragma instructs the compiler to generate a stub
function without any barrier wait() calls for data transfers. As a result, after issuing all data
transfer requests, control returns to the program, enabling concurrent execution of the program
while the accelerator is running. In this case, it is your responsibility to insert a #pragma SDS
wait(ID) within the program at appropriate synchronization points, which are resolved into
sds_wait(ID) API calls to correctly synchronize hardware accelerators, their implicit data
movers, and the CPU.
IMPORTANT! Every async(ID) pragma requires a matching wait(ID) pragma
SDSoC Build Process
The SDSoC build process uses a standard compilation and linking process. Similar to g++, the
sds++ system compiler invokes sub-processes to accomplish compilation and linking.
As shown in the following figure, compilation is extended not only to object code that runs on
the CPU, but it also includes compilation and linking of hardware functions into IP blocks using
the Vivado High-Level Synthesis (HLS) tool, and creating standard object files (.o) using the
target CPU toolchain. System linking consists of program analysis of caller/callee relationships for
all hardware functions, and the generation of an application-specific hardware/software network to implement every hardware function call. The sds++ system compiler invokes all necessary
tools, including Vivado HLS (function compiler), the Vivado Design Suite to implement the
generated hardware system, and the Arm compiler and sds++ linker to create the application
binaries that run on the CPU invoking the accelerator (stubs) for each hardware function by
outputting a complete bootable system for an SD card
The compilation process includes the following tasks:
1. Analyzing the code and running a compilation for the main application on the Arm core, as
well as a separate compilation for each of the hardware accelerators.
2. Compiling the application code through standard GNU Arm compilation tools with an object
(.o) file produced as final output.
3. Running the hardware accelerated functions through the HLS tool to start the process of
custom hardware creation with an object (.o) file as output.
After compilation, the linking process includes the following tasks:
1. Analyzing the data movement through the design and modifying the hardware platform to
accept the accelerators.
2. Implementing the hardware accelerators into the programmable logic (PL) region using the
Vivado Design Suite to run synthesis and implementation, and generate the bitstream for the
zařízení.
3. Updating the software images with hardware access APIs to call the hardware functions from
the embedded processor application.
4. Producing an integrated SD card image that can boot the board with the application in an
Executable and Linkable Format (ELF) file.
SDSoC Development Methodologies
The SDSoC environment supports two primary use cases:
• Software-centric design: The development of an accelerated application written by software
programmers using standard programming languages, accelerating compute intensive
functions into programmable logic, or identifying application bottlenecks for acceleration by
profiling the application.
• Hardware-centric design: The development of predefined accelerated functions for use in
embedded processor applications like a library of intrinsic functions. This design methodology
can be driven from a top-down approach of writing the hardware function in a standard
programming language like C or C++, and then synthesized into RTL for implementation into
programmable logic; or by using standard RTL design techniques to create and optimize the
accelerated function.
The two use-cases are often combined, letting software and hardware developer teams define
hardware accelerators and developing embedded processor applications to use them. This
combined methodology involves different components of the application, developed by different
people, and potentially from different companies. You can use predefined hardware functions
from libraries available for use in your accelerated application, such as the Xilinx xfOpenCV
library, or develop all the accelerators within your own team.
Software-Centric Design
The software-centric approach to accelerated application development, or accelerator
development, begins with the use of the C or C++ programming language. The code is written as
a standard software program, with some attention to the specific architecture of the code. The
software-centric development flow typically uses the following steps:
SDSoC Environment
The software-defined system-on-chip (SDSoC™) environment provides the tools necessary to
implement heterogeneous embedded systems for Zynq® UltraScale+™ MPSoC or Zynq-7000
devices. The design tasks and exploration of hardware/software partitioning is accomplished by
working in an Eclipse-based integrated development environment referred to as the SDx™ IDE.
The SDx IDE is designed to be familiar to users of software development IDEs. Actions carried
out with the SDx IDE include creating an Application project, creating a Platform project, and
creating a Library project. The figure below shows an overview of these design flows. Application
and Library projects are discussed in this user guide, whereas Platform projects are covered in
more detail in the SDSoC Environment Platform Development Guide (UG1146)
The concept of a platform is integral to the SDSoC environment as it defines the hardware,
software, and meta-data components on which SDSoC applications are built. Multiple base
platforms are available within the SDx IDE and can be used to create SDSoC applications without
first having to create a custom platform. The SDx IDE utilizes the sds++ system compiler to
convert C/C++ code into high-performance hardware accelerators that attach to platform
interfaces as determined by the platform designer and by application code pragmas. Declarations
within the platform meta-data identify interface ports, clocks, interrupts, and reset blocks for use
by the system compiler when it attaches hardware accelerators to the base platform.
Platform Block Diagram
The system compiler analyzes a program to determine the dataflow between software and
hardware functions and generates an application-specific system-on-chip. The sds++ system
compiler generates hardware IP and software control code that implements data transfers and
synchronizes the hardware accelerators with application software. Performance is achieved by
pipelining communication and computation, thereby producing hardware functions that can run
with maximum parallelism as illustrated in the following figure.
The sds++ system compiler invokes the Vivado® High-Level Synthesis (HLS) tool to transform
software functions into a bitstream that defines and configures the programmable logic (PL)
portion of the SoC. In addition, stub functions are generated so application software compiled
and linked using the standard GNU toolchain transparently uses the implemented hardware
functions. All necessary drivers and libraries are automatically included in this system compilation
proces.
The final output of system compilation is the generated sd_card directory, which at minimum is
populated with a Zynq bootable BOOT.BIN file, the executable and linkable format (ELF) file
application code, and a README.txt boot instructions file. The BOOT.BIN file contains any
necessary bootloaders, bitstreams, and application code to boot the generated system on a
target board. For systems that run Linux on the target board, the sd_card directory also
contains the Linux image file used during the boot process.
The SDSoC system compilers generate complete applications and let users iterate over design
and architectural features by re-factoring at the program level, reducing the time necessary to
achieve working applications on target platforms. To achieve high-performance, each hardware
function runs independently; the system compilers generate hardware and software components
that ensure synchronization between the hardware functions and the application software while
enabling pipelined computation and communication. Application code can involve many
hardware functions, multiple instances of a specific hardware function, and calls to a hardware
function from different parts of the program.
For the SDSoC environment, this reflects the resources and performance available within the
Zynq-7000 SoC or the Zynq UltraScale+ MPSoC device family. When creating applications that
require specific real-time behavior, it is important to be aware of the execution environment.
The Zynq-7000 family includes a processor system (PS) with dedicated Arm® processing cores,
on-chip memories, embedded peripherals, interconnect blocks, a DDR memory controller, and PL
fabric used by the SDSoC-generated accelerators.
Ideal processor, memory, and AXI interface performance are shown in the following table using
switching characteristics from the Zynq-7000 SoC and Zynq UltraScale+ MPSoC data sheets.
SDSoC Environment Tutorial
Creating a Platform from a Reference Design
UG1236 (v2016.3) November 30, 2016 This document is in process and will be released soon for 2016.3. Please sign up for SDSoCTM and SDAccelTM documentation alerts at www.xilinx.com/myprofile/doc-alerts.html, or check back soon for updates.
Dokumenty / zdroje
 |
XILINX SDSoC Environment Tutorial [pdfPokyny SDSoC Environment Tutorial, Environment Tutorial |