XILINX SDSoC Development Environment Tutorials

Informace o produktu

• Product Name: SDSoC Development Environment Tutorials
• Version: UG1028 (v2019.1)
• Datum vydání: 11. listopadu 2019

Návod k použití produktu

1. Nadview
   1. The SDSoC Development Environment Tutorials provide a comprehensive guide for utilizing the SDSoC Development Environment.
   2. Follow the steps outlined in the tutorials to effectively develop and optimize your software-defined systems.
2. Accessing Tutorials
   1. To access the tutorials, visit the SDSoC Development Environment
   2. Tutorials GitHub repository. You can find a collection of tutorials covering various aspects of the development environment.
3.  Tutorial Navigation
   1. Each tutorial is structured to guide you through specific tasks or concepts. Start with the tutorial that aligns with your current development needs or knowledge level. Follow the instructions carefully to make the most of the learning experience.
4. Hands-On Practice
   1. For optimal learning, it is recommended to follow along with the tutorials using the SDSoC Development Environment.
   2. Implement the examples provided in the tutorials to gain practical experience and deepen your understanding of software development with SDSoC.
5. Další zdroje
   1. Refer to supplemental materials or online resources for further assistance or clarification on any tutorial topics. Engage with the SDSoC community for support, tips, and best practices in utilizing the development environment.

Architecture of an SDSoC System

Nadview The SDSoC™ environment provides a framework for developing and delivering hardware accelerated embedded processor applications using standard programming languages. It includes a familiar embedded processor development flow with an Eclipse-based integrated development environment (IDE), compilers for the embedded processor application and for hardware functions implemented on the programmable logic resources of the Xilinx® device. The sdscc/sds++ (referred to as sds++) system compiler analyzes a program to determine the dataflow between software and hardware functions, generating an application-specific SoC supporting bare metal, Linux, and FreeRTOS as the target operating system. The sds++ system compiler generates hardware IP and software control code that automatically implements data transfers and synchronizes hardware accelerators and application software, therefore pipelining communication and computation. Using SoC devices from Xilinx, such as the Zynq®-7000 SoC and the Zynq UltraScale+™ MPSoC, you can implement elements of your application into hardware accelerators, running many times faster than optimized code running on a processor. Xilinx FPGAs and SoC devices offer many advantages over traditional CPU/GPU acceleration, including a custom architecture capable of implementing any function that can run on a processor, resulting in better performance at lower power dissipation. To realize the advantages of software acceleration on a Xilinx device, you should look to accelerate large compute intensive portions of your application in hardware. Implementing these functions in custom hardware allows you to achieve an ideal balance between performance and power. The SDSoC environment provides tools and reports to profile the performance of your embedded processor application and determines where the opportunities for acceleration are. The tools also provide automated runtime instrumentation of cache, memory, and bus utilization to track real-time performance on the hardware. Developers of hardware accelerated applications can make use of a familiar software-centric programming workflow to take advantage of FPGA acceleration with little or no prior FPGA or hardware design experience. As a software programmer, calling a hardware function is the same as calling a software function, letting the compiler implement the hardware/software partitioning. However, developers can also create predefined hardware accelerators for use in an embedded processor application, using a hardware-centric approach working through the Vivado® HLS compiler, or creating and packaging optimized RTL accelerators for distribution as a library of CCallable IP. UG1027 (v2019.1) May 22, 2019 www.xilinx.com SDSoC Environment User Guide 7 Send Feedback The SDSoC environment provides predefined platforms for standard ZCU102, ZCU104, ZCU106, ZC702, and ZC706, which are Zynq-based development boards. Third-party platforms are also available including: the Zedboard, Microzed, Zybo, Avnet Embedded Vision Kit, Video and Imaging Kit, SDR kit, and more. You can also create a custom platform to meet your specific market requirements. An SDSoC platform consists of a hardware portion defining the embedded processor, the hardware function, and any peripherals supported by the platform; and a software portion defining the operating system boot images, drivers, and the application code. You can start your project using one of the standard SDSoC platforms to evaluate a design concept, to be later implemented on a custom platform for production. Software Acceleration with SDSoC When compared with processor architectures, the structures that comprise the programmable logic (PL) in a Xilinx device enable a high degree of parallelism in application execution. The custom processing architecture generated by the sds++/sdscc (referred to as sds++) system compiler for a hardware function in an accelerator presents a different execution paradigm from CPU execution, and provides an opportunity for significant performance gains. While you can retarget an existing embedded processor application for acceleration in PL, writing your application to use the source code libraries of existing hardware functions, such as the Xilinx xfOpenCV library, or modifying your code to better use the PL device architecture, yields significant performance gains and power reduction. CPUs have fixed resources and offer limited opportunities for parallelization of tasks or operations. A processor, regardless of its type, executes a program as a sequence of instructions generated by processor compiler tools, which transform an algorithm expressed in C/C++ into assembly language constructs that are native to the target processor. Even a simple operation, such as the multiplication of two values, results in multiple assembly instructions that must be executed across multiple clock cycles. An FPGA is an inherently parallel processing device capable of implementing any function that can run on a processor. Xilinx devices have an abundance of resources that can be programmed and configured to implement any custom architecture and achieve virtually any level of parallelism. Unlike a processor, where all computations share the same ALU, the FPGA programming logic acts as a blank canvas to define and implement your acceleration functions. ample, only implementing multiply and accumulate hardware for a neural net—not a whole ALU. The sds++ system compiler invoked with the -c option compiles a file into a hardware IP by invoking the Vivado High-Level Synthesis (HLS) tool on the desired function definition. Before calling the HLS tool, the sds++ compiler translates #pragma SDS into pragmas understood by the HLS tool. The HLS tool performs hardware-oriented transformations and optimizations, including scheduling, pipelining, and dataflow operations to increase concurrency. Chapter 1: SDSoC Introduction and Overview UG1027 (v2019.1) May 22, 2019 www.xilinx.com SDSoC Environment User Guide 8 Send Feedback The sds++ linker analyzes program dataflow involving calls into and between hardware functions, mapping into a system hardware data motion network, and software control code (called stubs) to orchestrate accelerators and data transfers through data movers. As described in the following section, the sds++ linker performs data transfer scheduling to identify operations that can be shared, and to insert wait barrier API calls into stubs to ensure program semantics are preserved. Execution Model of an SDSoC Application The execution model for an SDSoC environment application can be understood in terms of the normal execution of a C++ program running on the target CPU after the platform has booted. It is useful to understand how a C++ binary executable interfaces to hardware. The set of declared hardware functions within a program is compiled into hardware accelerators that are accessed with the standard C runtime through calls into these functions. Each hardware function call in effect invokes the accelerator as a task and each of the arguments to the function is transferred between the CPU and the accelerator, accessible by the program after accelerator task completion. Data transfers between memory and accelerators are accomplished through data movers, such as a DMA engine, automatically inserted into the system by the sds++ system compiler taking into account user data mover pragmas such as zero_copy. Chapter 1: SDSoC Introduction and Overview UG1027 (v2019.1) May 22, 2019 www.xilinx.com SDSoC Environment User Guide 9 Send Feedback Figure 1: Architecture of an SDSoC System SDSoC Platform DDR Banks Zynq Embedded Processor (PS Region) Operating System Drivers Application Code Peripherals (Vision, Graphics, Measurement…) Programmable Logic (PL Region) Hardware Function Accelerators Data Movers Direct I/O Access X21358-082418 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(). Chapter 1: SDSoC Introduction and Overview UG1027 (v2019.1) May 22, 2019 www.xilinx.com SDSoC Environment User Guide 10 Send Feedback 2. 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 Chapter 1: SDSoC Introduction and Overview UG1027 (v2019.1) May 22, 2019 www.xilinx.com SDSoC Environment User Guide 11 Send Feedback 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. Figure 2: SDSoC Build Process Embedded Process Application Hardware Functions SDS++ Compilation HLS Function Compile GNU Arm Toolchain SDS++ Linking Vivado Design Suite Update SW Image C/C++ Arm Build Steps Application Executable (.elf) RTL, C/C++ Programmable Logic Build Steps FPGA Binary (Bitstream) Bootable System Image Embedded System Source Code X21126-041119 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 device. 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. Chapter 1: SDSoC Introduction and Overview UG1027 (v2019.1) May 22, 2019 www.xilinx.com.

SDSoC Environment

SDSoC Environment User Guide 12 Send Feedback 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: Table 1: Software-Centric Design Flow Task Steps Profile the embedded processor application. • Baseline the performance, identify bottlenecks, and functions to accelerate. • Assess acceleration potential, plan budgets, and requirements. Code the desired accelerators. • Convert the desired functions to define the hardware function code without optimization. Verify functionality, iterate as needed. • Run system emulation to generate application and accelerator profiling data including: ○ Estimated FPGA resource usage. ○ Overall application performance. ○ Visual timeline showing application calls and accelerator start/ stop times. • Address design recommendations provided by tool guidance. Chapter 1: SDSoC Introduction and Overview UG1027 (v2019.1) May 22, 2019 www.xilinx.com SDSoC Environment User Guide 13 Send Feedback Table 1: Software-Centric Design Flow (cont’d) Task Steps Optimize for performance, iterate as needed. • Analyze the profile summary and application timeline. • Optimize data movement throughout system: ○ Application to DDR, DDR to accelerator, and hardware function interface to local buffers (bursting) ○ Maximize DDR bandwidth usage with efficient transfer sizes ○ Overlapping of transfers ○ Prefetching • Optimize the accelerator code for performance: ○ Task-level parallelism (dataflow) ○ Instruction-level parallelism (pipelining and loop unrolling) ○ Match datapath size to interface bandwidth (arbitrary bit-width) Hardware-Centric Design A hardware-centric flow first focuses on developing and optimizing the accelerators and typically leverages advanced FPGA design techniques to create a library of C-Callable IP. This begins with the definition of the hardware function in C or C++ for use in Vivado HLS, or the use of an RTL language, or an existing IP design or block design in the Vivado Design Suite. The hardware function is defined in RTL code, synthesized, and implemented into the programmable logic of the target device. A software function signature is needed to use the C-Callable IP in the accelerator application, or a compiled library of functions is created for use across multiple applications. The hardware-centric development flow typically uses the following steps: Table 2: Hardware-Centric Design Methodology Task Steps Study the SDSoC platform specification, and the Zynq-7000 SoC device specification and programming model. • Hardware platform, software platform, data movers, AXI interface, DDR. Identify cycle budgets and performance requirements. Define the accelerator architecture and interfaces. Develop the accelerator. • Use Vivado HLS for C or C++ hardware functions. • Use traditional RTL design techniques in the Vivado Design Suite. Verify functionality and performance, iterate as needed. • Run hardware/software co-simulation in Vivado HLS. • Run logic simulation in the Vivado simulator. Optimize the quality of results to reduce resource utilization and increase frequency, iterate as needed. • For HLS, ensure the design rules check (DRC) is clean. • Run the Vivado implementation flow, using the techniques specified in the UltraFast Design Methodology Guide for the Vivado Design Suite (UG949). • Use best practices for out-of-context synthesis and estimation. Chapter 1: SDSoC Introduction and Overview UG1027 (v2019.1) May 22, 2019 www.xilinx.com SDSoC Environment User Guide 14 Send Feedback Table 2: Hardware-Centric Design Methodology (cont’d) Task Steps Import the C-Callable IP into the SDSoC environment. • For the HLS flow, import the C or C++ code into your SDSoC project. • For RTL flow, use the C-Callable IP wizard. • See C-Callable Libraries for more information. Develop sample application code to test the hardware function. • Test sample applications with a dummy function having the same interfaces as the C-Callable IP. See C-Callable Libraries for more information. Verify the hardware function works properly with application, iterate as needed. • Use system emulation for debug. • Use the Hardware debug methodology for complex internal debug problems. Optimize host code for performance, iterate as needed: • Use the Profile Summary report, the Activity Timeline, and event timers in the host application to measure performance. • Ensure the DRC is clean. • Work to achieve an Activity Timeline that matches the desired performance. • Techniques: Overlapping transactions, out-of-order (OOO) synthesis queues, and sub-devices. Finalize the Software Acceleration Layer deliverable (API, share lib, plug-in…). Best Practices for Acceleration with SDSoC The following shows best practices when developing your application code and hardware function in the SDSoC environment: • General guidelines: ○ Reduce resource utilization and improve parallelism by streaming data instead of copying data into the PL region. For example, in an image processing application, stream rows of pixels that make up a frame instead of copying the image frame in one long data transfer. ○ Reuse the data local to the PL region rather than transferring it back and forth to limit DMA. ○ Look to accelerate functions that have: – A high compute time to data transfer time ratio. – Predictable communication streams. – Self-contained control structure not needing control logic outside the accelerator. ○ Look for opportunities to increase task-level parallelization by launching multiple accelerators concurrently, or multiple instances of an accelerator. Chapter 1: SDSoC Introduction and Overview UG1027 (v2019.1) May 22, 2019 www.xilinx.com SDSoC Environment User Guide 15 Send Feedback • For a software-centric approach: ○ Use good memory management techniques, such as having known array sizes, and using sds_alloc()/sds_free() to allocate/de-allocate physically contiguous memory, thereby reducing the device footprint and increasing baseline performance. ○ Use system emulation to validate your code frequently to ensure it is functionally correct. ○ Write/migrate hardware functions to separate C/C++ files as to not re-compile the entire design for incremental changes. • For a hardware-centric approach using C-Callable IP: ○ Keep track of the AXI4 Interface offsets for an IP, or accelerator, and what function definition parameters require what data type. The interfaces need to be byte aligned. ○ Maintain the original Vivado IP project so that modifications to it can be quickly implemented. ○ Keep the static library (.a) file and corresponding header file together. Chapter 1: SDSoC Introduction and Overview UG1027 (v2019.1) May 22, 2019 www.xilinx.com SDSoC Environment User Guide 16 Send Feedback Chapter 2 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). Figure 3: SDx Design Flows Create SDSoC Application Select Platform Create/Import Software or Use Code Template HW+SW Products Build Application Create SDSoC Platform Select DSA Associate or Generate Software Components Platform Generate Platform Create SDSoC Library Select Platform Create Application Using Library HW+SW Products Build Application SDx IDE X21844-110618 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. UG1027 (v2019.1) May 22, 2019 www.xilinx.com SDSoC Environment User Guide 17 Send Feedback Figure 4: Platform Block Diagram External Memory Controller PS MIO PS PL Arm PS Cores ACCELERATOR + PLATFORM Interface PL LOGIC Interface Interface Interface Interface Interface Interface Clocks Resets Interrupts X21847-110618 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.

Pipelined Data Transfer and Computer

Figure 5: Pipelined Data Transfer and Compute FUNC_A FUNC_B FUNC_C FUNC_A FUNC_B FUNC_C Time Time X21846-110618 Chapter 2: SDSoC Environment UG1027 (v2019.1) May 22, 2019 www.xilinx.com SDSoC Environment User Guide 18 Send Feedback 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 process. 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. Table 3: Processor, Memory, and AXI Interface Performance Clock or Interface Zynq UltraScale+ MPSoC Zynq-7000 SoC Max APU clock frequency Arm Cortex™-A53 64-bit Quad-Core: 1500 MHz Arm Cortex-A9 32-bit Dual-Core: 1000 MHz Max RPU clock frequency ArmCortex-R5 32-bit Dual-Core: 600 MHz N/A DDR type and bit width DDR4: x32, x64 DDR3: x16, x32 DDR Max performance 2400 Mb/s 1333 Mb/s DDR Max Ideal Throughput 153.6 Gb/s 42.6 Gb/s AXI Interface width 128-bit, 64-bit, 32-bit 64-bit, 32-bit AXI Interface Max Frequency 333 MHz 250 MHz Chapter 2: SDSoC Environment UG1027 (v2019.1) May 22, 2019 www.xilinx.com SDSoC Environment User Guide 19 Send Feedback Table 3: Processor, Memory, and AXI Interface Performance (cont’d) Clock or Interface Zynq UltraScale+ MPSoC Zynq-7000 SoC AXI Interface Max Ideal Throughput 42.6 Gb/s 16 Gb/s Number of AXI Interface Ports 12 6 Total AXI Throughput 511.2 Gb/s 96.0 Gb/s Getting Started Download and install the SDSoC tool suite according to the directions provided in the SDSoC Environments Release Notes, Installation, and Licensing Guide (UG1294). After installing the SDSoC tools, you can find detailed instructions and hands-on tutorials to introduce the primary work flows for project creation, specifying functions to run in programmable logic, system compilation, debugging, and performance estimation in the SDSoC Environment Getting Started Tutorial (UG1028). Working through the tutorial and its labs is the best way to get an overview of the SDSoC environment, and should be considered a prerequisite to application development. Note: The SDSoC tool suite includes the entire tool stack to create a bitstream, object code, and executables. If you have installed the Xilinx® Vivado Design Suite and the Software Development Kit (SDK) tools independently, you should not attempt to combine these installations with the SDSoC tools. Ensure that your tools are derived from an SDSoC installation (which includes the Vivado Design Suite and SDK tools). RECOMMENDED: Although SDSoC supports Linux application development on Windows hosts, a Linux host is strongly recommended for SDSoC platform development, and required for creating a platform supporting a target Linux OS. Elements of SDSoC The SDSoC environment includes the sds++ system compiler to generate complete hardware/ software systems, an Eclipse-based user interface to create and manage projects and workflows, and a system performance estimation capability to explore different “what if” scenarios for the hardware/software interface. Elements of the SDx tools include: • Eclipse-based IDE • The sds++ system compiler • High-Level Synthesis (HLS) • Vivado Design Suite Chapter 2: SDSoC Environment UG1027 (v2019.1) May 22, 2019 www.xilinx.com SDSoC Environment User Guide 20 Send Feedback • IP integrator and IP libraries • Vivado-generated SDx Platforms • SDx-generated hardware accelerators and associated control software • SDx-generated data movers and associated control software • The Target Communication Framework (TCF) • GNU software development tools The SDSoC environment includes the GNU toolchains and standard libraries (for example, glibc), a performance analysis perspective within the Eclipse C/C++ Development Tooling (CDT)-based GUI, and command-line tools. The SDSoC system compiler employs underlying tools from the Vivado Design Suite HLS Editions including Vivado HLS, IP integrator, and IP libraries for data movement and interconnect, and the RTL synthesis, implementation, and bitstream generation tools. The principle of design reuse underlies workflows you employ with the SDSoC environment, using established, platform-based, design methodologies. The SDSoC system compiler generates an application-specific system-on-chip by customizing a target platform. The SDSoC environment includes a number of built-in platforms for application development, and others can be provided by Xilinx partners, or custom-developed by FPGA design teams. The SDSoC Environment Platform Development Guide (UG1146) describes how to create a design using the Vivado Design Suite, specify platform properties to define and configure platform interfaces, and define the corresponding software runtime environment to build a platform for use in the SDSoC environment. An SDSoC platform defines a base hardware and software architecture and application context, which includes the following: • Processing system • External memory interfaces • Custom input/output • Software runtime including: Operating system (for example, Linux, FreeRTOS, or Standalone), boot loaders, drivers for platform peripherals, and the root file system Every project you create within the SDSoC environment targets a specific platform. Using the SDx IDE to build on the base platform foundation with application-specific hardware accelerators and data motion networks and connecting accelerators to the platform, you can create customized, application-specific SoC designs for different base platforms, and use base platforms for many different applications. Chapter 2: SDSoC Environment UG1027 (v2019.1) May 22, 2019 www.xilinx.com SDSoC Environment User Guide 21 Send Feedback You are provided the option to use either a predefined platform from the SDx installation or a custom platform. Custom platforms are generated from a device support archive (DSA) hardware specification exported from the Vivado tools, or derived from a predefined platform. See the SDSoC Environments Release Notes, Installation, and Licensing Guide (UG1294) for the most up-to-date list of supported devices and required software.

Design Flow Overview

Design Flow Overview The SDSoC environment is a tool suite for building efficient SoC applications, starting from a platform that provides the base hardware and target software architecture. A boot image and the executable application code are generated by the SDSoC tools. The following figure shows a representative top-level design flow that shows key components of the tool suite. For the purposes of exposition, the design flow proceeds linearly from one step to the next, but in practice you are free to choose other work flows with different entry and exit points. Starting with a software-only version of the application that has been compiled for CPUs, the primary goal is to identify portions of the program to move into programmable logic and to implement the application in hardware and software built upon a base platform. Note: Emulation only works on the base platforms. For more on debug or emulation, see SDSoC Environment Debugging Guide (UG1282). Chapter 2: SDSoC Environment UG1027 (v2019.1) May 22, 2019 www.xilinx.com SDSoC Environment User Guide 22 Send Feedback Figure 6: User Design Flow C/C++ Application Running on Arm Profile Application Mark Functions for Hardware Acceleration Estimate Performance Build Application to Generate Software and Hardware SD Card Image Run on the Board Optimize Data Transfer and Parallelism w/ SDSoC Guidelines Optimize Accelerator Code Analyze Performance Emulation X14740-041119 The steps are: 1. Select a development platform, compile the application, and ensure it runs properly on the platform. 2. Identify compute-intensive hot spots to migrate into programmable logic to improve system performance, and isolate them into functions that can be compiled into hardware. See Selecting Functions for Hardware Acceleration. 3. Invoke the SDSoC system compiler to generate a complete SoC and SD card image for your application. See Working with Code. You can instrument your code to analyze performance, and if necessary, optimize your system and hardware functions using a set of directives and tools within the environment. SDSoC Environment Profiling and Optimization Guide (UG1235) for profiling and optimization best practices. Chapter 2: SDSoC Environment UG1027 (v2019.1) May 22, 2019 www.xilinx.com SDSoC Environment User Guide 23 Send Feedback The sds++ system compilers orchestrate the system generation process either through the IDE or in the terminal shell using command lines and makefiles. You select functions to run in hardware, specify accelerator and system clocks, and set properties on data transfers. You can insert pragmas into application source code to control the system mapping and generation flows, providing directives to the system compiler for implementing the accelerators and data motion networks. Because a complete system compile can be time-consuming compared with an conventional compile for a CPU, the SDSoC environment provides a faster performance estimation capability. The estimate allows you to approximate the expected speed-up over a software-only implementation for a given choice of hardware functions. Also, this can be functionally verified and analyzed through system emulation. The system emulation feature uses a quick emulation (QEMU) model executing the software and RTL model of the hardware functions to enable fast and accurate analysis of the system. The overall design process involves iterating the steps until the generated system achieves your performance and cost objectives. To run through the introductory tutorial and become familiar with creating a project, selecting hardware functions, and compiling and running a generated application on the target platform, see SDSoC Environment Getting Started Tutorial (UG1028). Understanding the SDx GUI When you open a project in the SDx IDE, the workspace is arranged in a series of different views and editors, also known as a perspective in the IDE. The tool opens with the SDx (default) perspective shown in the following figure. Chapter 2: SDSoC Environment UG1027 (v2019.1) May 22, 2019 www.xilinx.com SDSoC Environment User Guide 24 Send Feedback Figure 7: SDx – Default Perspective Chapter 2: SDSoC Environment UG1027 (v2019.1) May 22, 2019 www.xilinx.com SDSoC Environment User Guide 25 Send Feedback Some key views/editors in the default perspective are: • Project Explorer: Displays a file-oriented tree view of the project folders and their associated source files, plus the build files, and reports generated by the tool. • Assistant: Provides a central location to view/edit settings, build and run your SDSoC application, launch profiling and debug sessions, and open reports. • Editor Area: Displays project settings, build configurations, and provides access to many commands for working with the project. • Console Area: Presents multiple views including the command console, design guidance, project properties, logs and terminal views. • Outline: Displays an outline of the current source file opened in the Editor Area. • Target Connections: Provides status for different targets connected to the SDx tool, such as the Vivado hardware server, Target Communication Framework (TCF), and quick emulator (QEMU) networking. To close a view, click the Close button (x) on the tab of the view. Chcete-li otevřít a view, select Window  → Show View a vyberte a view. You can arrange views to suit your needs by dragging and dropping them into new locations in the IDE. To save the arrangement of views as a perspective, select Window → Perspective → Save Perspective As. This defines different perspectives for initial project editing, report analysis, and debug for example. Any changes made without saving as a perspective are stored with the workspace. To restore the default arrangement of views, select Window → Perspective → Reset Perspective. To open different perspectives, select Window → Perspective → Open Perspective. To restore the SDx (default) perspective, click the SDx button on the right side of the main toolbar. Chapter 2: SDSoC Environment UG1027 (v2019.1) May 22, 2019 www.xilinx.com SDSoC Environment User Guide 26 Send Feedback Chapter 3 Creating an SDSoC Application An SDSoC™ application can be created through the SDx™ IDE or by using a command line interface. In this chapter, the SDx IDE shows how to create a workspace, generate an application project for a selected platform, and use the available application templates. Working with code, adjusting hardware accelerator settings and targeting either emulation or a board is also covered. Excerpts of how to perform the IDE operations using command line equivalents is interspersed with the GUI illustrations. Using an SDx Workspace IMPORTANT! Linux host is strongly recommended for SDSoC™ platform development, and required for creating a platform supporting a target Linux OS. 1. Launch the SDx™ IDE directly from the desktop icon or from the command line by one of the following methods: • Using either of the following commands from the command prompt: sdx or sdx -workspace • Double-clicking the SDx icon to start the program. • Launching from the Start menu in the Windows operating system. 2. The SDx IDE opens and prompts you to select a workspace, as shown in the following figure. UG1027 (v2019.1) May 22, 2019 www.xilinx.com SDSoC Environment User Guide 27 Send Feedback Figure 8: Specify the SDx Workspace IMPORTANT! When opening a new shell to enter an SDx command, ensure that you first source the settings64 and setup scripts to set up the tool environment. On Windows, run the settings64.bat file from the command shell. See the SDSoC Environments Release Notes, Installation, and Licensing Guide (UG1294) for more information. The SDx workspace is the folder that stores your projects, source files, and results while working in the tool. You can define separate workspaces for each project or have workspaces for different types of projects. The following instructions show you how to define a workspace for an SDSoC project. 1. Click the Browse button to navigate to, and specify, the workspace, or type the appropriate path in the Workspace field. 2. Select the Use this as the default and do not ask again check box to set the specified workspace as your default choice and eliminate this dialog box in subsequent uses of SDx. 3. Click Launch. TIP: You can change the current workspace from within the SDx IDE by selecting File → Switch Workspace. You have now created an SDx workspace and can populate the workspace with projects. Platform and application projects are created to describe the SDx tool flow for creating an SDSoC platform. The SDx IDE can populate the workspace with three types of user selected project types: • Application Project • Platform Project • Library Project The following sections describe how to use the Platform and Application project types while constructing the example SDSoC platforms. Chapter 3: Creating an SDSoC Application UG1027 (v2019.1) May 22, 2019 www.xilinx.com SDSoC Environment User Guide 28 Send Feedback Creating an Application Project TIP: Example designs are provided with the SDSoC tool installation, and also on the Xilinx GitHub repository. See Appendix A: Getting Started with Examples for more information. 1. After launching the SDx IDE you can create a new Project. Select File → New → SDx Application Project, or if this is the first time the SDx IDE has been launched, you can select Create Application Project on the Welcome screen. 2. The Create a New SDx Application Project wizard opens. 3. In the Create a New SDx Application Project page, you can specify the project name as shown. Specify the name of the project in the Project name field. Figure 9: Create a New SDx Application Project 4. The Use default location is selected by default to locate your project in a folder in the SDx workspace. You can uncheck this check box to specify that the project is created in a Location of your choice. 5. If you specify the location, you can use Choose file system to select the default file system, JSch, or enable the Eclipse Remote File System Explorer (RSE). IMPORTANT! The project location cannot be a parent folder of an SDx workspace. 6. Click Next. The Platform dialog box, similar to the one shown in the following figure, displays the available installed platforms. For installing additional platforms, see the “Installing Platform-Specific Packages” section in SDAccel Environment Release Notes, Installation, and Licensing Guide (UG1238). IMPORTANT! Be sure to select the right platform for your project, as subsequent processes are driven by this choice. Chapter 3: Creating an SDSoC Application UG1027 (v2019.1) May 22, 2019 www.xilinx.com SDSoC Environment User Guide 29 Send Feedback Figure 10: Specify SDSoC Platform A platform is composed of a shell, which describes the base hardware design, the meta-data used in attaching accelerators to declared interfaces, and the software environment, which can include operating system images (for example, Linux), as well as boot-up and runtime files. The SDSoC development environment offers base-platforms for specific boards based on the following: • Zynq®-7000 ○ zc702 ○ zc706 • Zynq UltraScale+™ MPSoC ○ zcu102 ○ zcu104 ○ zcu106 ○ zed You can add custom defined or third-party platforms into a repository. See Appendix B: Managing Platforms and Repositories for more information. Chapter 3: Creating an SDSoC Application UG1027 (v2019.1) May 22, 2019 www.xilinx.com SDSoC Environment User Guide 30 Send Feedback 1. Select the target platform for your project from the listed platforms. A series of actions are also available in this Platform dialog through the five icons immediately above the platform list. From left-to-right, clicking an icon invokes a platform text string search, adding a custom platform, managing a platform repository, adding new devices or platforms, and listing additional information about a selected platform. 2. Select one of the predefined, installed platforms and click Next. 3. The System configuration page opens, as shown in the following figure. Select System configuration and Runtime from a list of those defined for the selected platform. The System Configuration defines the software environment that runs on the hardware platform. It specifies the operating system and the available runtime settings for the processors in the hardware platform. Figure 11: Specify System Configuration 4. When setting the system configuration, you can also check the Domain and specify a Linux Root File System if a Linux-based configuration is selected. The Linux Root File System is a sysroot directory structure that provides the necessities for a system to run and locate headers. 5. After selecting the System Configuration and clicking Next, the Templates page displays, as shown in the following figure. Specify an application template for your new project. The samples directory within the SDx tools installation contains multiple source code example templates. 6. Initially, you have the option in the Template dialog box of an Empty Application or one of the provided application templates. You can download additional SDx examples or update the installed examples by clicking the SDx Examples button, which retrieves content from the Xilinx GitHub as discussed in Appendix A: Getting Started with Examples.

SDSoC Development Environment Tutorials
UG1028 (v2019.1) November 11, 2019 The following tutorials are available on the SDSoCTM Development Environment Tutorials GitHub repository:
· Getting Started · Migrate OpenCV to xfOpenCV · Platform Creation

Dokumenty / zdroje

XILINX SDSoC Development Environment Tutorials [pdfPokyny SDSoC Development Environment Tutorials, Development Environment Tutorials, Environment Tutorials

Reference

• Uživatelská příručka