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.

Figure: SDx Design Flows

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.

Figure: 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.

Figure: Pipelined Data Transfer and Compute

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 1. 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 Arm Cortex-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
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 Development Environment Release Notes, Installation, and Licensing Guide.

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).
Note: 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
  • 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 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.

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 Development Environment Release Notes, Installation, and Licensing Guide for the most up-to-date list of supported devices and required software.

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.

Figure: User Design Flow

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 Profiling and Optimization Guide for profiling and optimization best practices.

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.

Figure: SDx – Default Perspective

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. To open a view, select Window > Show View and select 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.