SDSoC Environment

The software-defined system-on-chip (SDSoC™) environment provides the tools necessary to implement heterogeneous embedded systems forZynq® UltraScale+™ MPSoCorZynq-7000devices. The design tasks and exploration of hardware/software partitioning is accomplished by working in an Eclipse-based integrated development environment referred to as theSDx™IDE. TheSDxIDE is designed to be familiar to users of software development IDEs. Actions carried out with theSDxIDE 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 theSDSoC Environment Platform Development Guide.

Figure:SDx Design Flows

The concept of a platform is integral to theSDSoCenvironment as it defines the hardware, software, and meta-data components on whichSDSoCapplications are built. Multiple base platforms are available within theSDxIDE and can be used to createSDSoCapplications without first having to create a custom platform. TheSDxIDE utilizes thesds++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

Thesds++system compiler invokes theVivado®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 generatedsd_carddirectory, which at minimum is populated with aZynqbootableBOOT.BINfile, the executable and linkable format (ELF) file application code, and aREADME.txtboot instructions file. TheBOOT.BINfile 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, thesd_carddirectory also contains the Linux image file used during the boot process.

TheSDSoCsystem 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 theSDSoCenvironment, this reflects the resources and performance available within theZynq-7000 SoCor theZynq UltraScale+ MPSoCdevice family. When creating applications that require specific real-time behavior, it is important to be aware of the execution environment.

TheZynq-7000family includes a processor system (PS) with dedicatedArm®processing cores, on-chip memories, embedded peripherals, interconnect blocks, a DDR memory controller, and PL fabric used by theSDSoC-generated accelerators.

Ideal processor, memory, and AXI interface performance are shown in the following table using switching characteristics from theZynq-7000 SoCandZynq UltraScale+ MPSoCdata sheets.

Table 1.Processor, Memory, and AXI Interface Performance
Clock or Interface Zynq UltraScale+ MPSoC Zynq-7000 SoC
Max APU clock frequency ArmCortex™-A53 64-bit Quad-Core: 1500 MHz ArmCortex-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
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 theSDSoCtool suite according to the directions provided in theSDSoC Development Environment Release Notes, Installation, and Licensing Guide.

After installing theSDSoCtools, 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 theSDSoC Environment Getting Started Tutorial(UG1028). Working through the tutorial and its labs is the best way to get an overview of theSDSoCenvironment, and should be considered a prerequisite to application development.

Note:The SDSoCtool suite includes the entire tool stack to create a bitstream, object code, and executables. If you have installed the Xilinx® Vivado Design Suiteand the Software Development Kit (SDK)tools independently, you should not attempt to combine these installations with the SDSoCtools. Ensure that your tools are derived from an SDSoCinstallation (which includes the Vivado Design Suiteand SDKtools).
Note:Although SDSoCsupports Linux application development on Windows hosts, a Linux host is strongly recommended for SDSoCplatform development, and required for creating a platform supporting a target Linux OS.

Elements ofSDSoC

TheSDSoCenvironment includes thesds++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 theSDxtools include:

  • Eclipse-based IDE
  • Thesds++system compiler
  • High-Level Synthesis (HLS)
  • Vivado Design Suite
  • IP integrator and IP libraries
  • Vivado-generatedSDxPlatforms
  • 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

TheSDSoCenvironment 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.

TheSDSoCsystem compiler employs underlying tools from theVivado Design SuiteHLS Editions includingVivadoHLS, 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 theSDSoCenvironment, using established, platform-based, design methodologies.TheSDSoCsystem compiler generates an application-specific system-on-chip by customizing a target platform.

TheSDSoCenvironment includes a number of built-in platforms for application development, and others can be provided byXilinxpartners, or custom-developed by FPGA design teams. TheSDSoC Environment Platform Development Guidedescribes how to create a design using theVivado 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 theSDSoCenvironment.

An SDSoCplatform 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 SDSoCenvironment targets a specific platform. Using the SDxIDE 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 theSDxinstallation or a custom platform. Custom platforms are generated from a device support archive (DSA) hardware specification exported from theVivadotools, or derived from a predefined platform.

See theSDSoC Development Environment Release Notes, Installation, and Licensing Guidefor the most up-to-date list of supported devices and required software.

Design Flow Overview

TheSDSoCenvironment 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 theSDSoCtools.

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. SeeSelecting Functions for Hardware Acceleration.
  3. Invoke theSDSoCsystem compiler to generate a complete SoC and SD card image for your application. SeeWorking 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 Guidefor profiling and optimization best practices.

Thesds++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, theSDSoCenvironment 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, seeSDSoC Environment Getting Started Tutorial(UG1028).

Understanding the SDx GUI

When you open a project in theSDxIDE, the workspace is arranged in a series of different views and editors, also known as aperspectivein the IDE. The tool opens with theSDx(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 SDSoCapplication, 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 SDxtool, such as the Vivadohardware server, Target Communication Framework (TCF), and quick emulator (QEMU) networking.

To close a view, click theClosebutton (x) on the tab of the view. To open a view, selectWindow>Show Viewand 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, selectWindow>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, selectWindow>Perspective>Reset Perspective.

To open different perspectives, selectWindow>Perspective>Open Perspective.

To restore theSDx(default) perspective, click theSDxbuttonon the right side of the main toolbar.