SDx IDE Glossary

SDx™ IDE

The SDx IDE descriptions in this appendix refer to platform projects (as opposed to application projects) and consists of multiple views that can be configured into different perspectives, or view configurations. The default perspective has the following features:

  • Explorer view: On the left side of the display, this view lets you navigate through the project hierarchy, source files, and resources.
  • Editor view: In the center of the display, the Editor displays the project and lets you modify features of the project and edit code, scripts, and configuration files. Files can be opened by double-clicking on them in the Explorer view.
  • Console view: At the bottom, this view displays the output for the different processes and utilities that make up the SDx tool.

The views are configurable from the Window > Show View command. Views can also be shown or hidden, and arranged as needed, and saved into perspectives that can be loaded into the tool. For more information on working with the SDx IDE, refer to the SDSoC Environment User Guide.

In the Editor view, the elements of the processor are contained in three levels of the platform: Platform, System Configurations, and Processor Domains. The bottom of the Editor view also displays a small workflow that defines the process for creating a platform. The following sections describe how you can define the elements of your platform, using the established workflow.

Platform

In the previous example, the platform project has been populated by the information you provided when you created the project:

  • Name: Displays the name.
  • DSA: Indicates the DSA file associated with the platform.
    IMPORTANT: The name and DSA file are specified when the platform is created and cannot be changed.
  • Description: This field is initially copied from the platform name. However, you can click the Edit command () to modify the description to provide more details of the platform.
  • Samples: This optional field specifies the path to a folder containing sample applications for use with the platform. See Sample Applications for more information.
    TIP: The Samples folder can be specified through the Browse command, or you can add samples in the resources folder of the platform project and use the Search command () to load it. The resources folder, as shown in the Explorer view is local to the project in the workspace, and can simplify the process of sharing the platform project with others.

Defining the System Configuration

The System Configuration defines the software environment that is booted and runs on the hardware platform. It will specify Operating Systems and the run-time settings for the processors in the hardware platform, and will also have software-configurable hardware parameters.

With the platform project opened in the SDx IDE, you can add System Configurations to the platform by clicking the Define System Configuration command in the workflow at the bottom of the Editor. This will open the New System Configuration dialog box as shown below.
TIP: You can also use the Add command () in the Editor and select System Configuration.

The fields of the System Configuration dialog box include:

  • Name: Specifies an identifier for the System Configuration. The name should be alphanumeric, between 3 and 40 characters long, and include no special characters except underscore, '_', and dash, '-'. Because the System Configuration name is an identifier it cannot be modified after it is created.
    TIP: When using the Makefile flow, or command-line, you can specify this identifier using -sds-sys-config<name> option of sds++ to specify the software platform used, which includes the target operating system and other settings.
  • Display Name: The name that will be displayed by the SDx IDE and in reports. This name can include spaces and special characters, and can be modified.
  • Description: A brief description for the configuration.
  • IMPORTANT: It is assumed that any files referenced in the BIF file will be in the directory specified by the Boot Directory field.

Click OK to close the New System Configuration dialog box and add the configuration to the platform. You will see the configuration listed in the Editor view.

If you select the System Configuration in the tree view of the platform, on the left side of the Editor, you will see the information for the System Configuration as you have defined it. In addition, the Readme field is displayed to let you define a readme file associated with the configuration. The readme file should be available along with the SD Card. This file informs users of the platform how to boot an application for this configuration, and how the board should be physically set, for example Jumper Settings. It is a plain text file that contains instructions to the user.

Defining the Processor Domain

The Processor Domain will define the OS operating on one or more processors on the device, and the run-time. The domain defines different settings for the OS, whether Linux, FreeRTOS, or Standalone.

As shown in the figure below, SDSoC™ allows for applications targeting the standalone or FreeRTOS operating system to be built to target a specific Processor core (Cortex™-A9, Cortex-A53, or Cortex-R5), and for Linux applications to be built to run on all cores that are visible to the OS. When defining a domain for the Linux operating system, you do not need to target a specific core, but instead can assume that the Linux scheduler will schedule across processors as appropriate, and isn’t restricted to any particular processor core.

You can add domains to a System Configuration by clicking the Add Processor Group/Domain command in the workflow at the bottom of the Editor. This opens the New Domain dialog box as shown below.
TIP: You can also click the Add button () in the Editor and select Domain.

The fields of the System Configuration dialog box include:

  • Name: Specifies the name of the domain.
    TIP: The name should be alphanumeric, between 3 and 40 characters long, and include no special characters except underscore, '_', and dash, '-'.
  • Display Name: The name that will be displayed by the SDx IDE and in reports. This name can include spaces and special characters.
  • OS: Specify the OS you are configuring as either Linux, FreeRTOS, or Standalone from the drop-down menu. For each OS there are various files that must be included in order to compile, link, or generate the boot files for a given application. The fields of the New Domain dialog box vary depending on the OS selected.
  • Processor: Defines the available types of processors for the platform. The types of processors available is determined by the IP in the hardware platform as defined by the DSA. Any processor IP present in the hardware design will show up in this list.
  • Supported Runtime: Specify the kernel runtime for the platform from the drop-down menu. This determines the compiler used to process the kernel logic at runtime. C/C++ is supported for all OSes.
  • Prebuilt Linux Image: In case of Linux OS, you need to build the Linux image for the Hardware design, using PetaLinux for example, and provide the image directory. More details about how to build the correct image, refer to Creating the Platform Software Component.
  • Linker Script: This is required for FreeRTOS and Standalone Only. This is the linker script which will be used while linking the baremetal or FreeRTOS ELF in the SDx application build. This file allows the programmer to control how the sections are merged in the ELF, and at what locations they are placed in memory. It also allows the user to specify how much of DDR memory is allocated for the stack and heap.
    TIP: When you add the linker script to your SDx platform, you must increase the stack and heap sizes because the SDK default values are too small for a typical SDx application.
  • Description: A brief description for the domain.

Click OK to close the New Domain dialog box and add the Processor Domain to the platform. You will see the domain listed in the Editor view. After the domain has been defined, the SDx IDE shows additional details for the domain that can be edited when it is selected in the platform project, as shown below.

The new fields of the domain include the following:

  • Repositories: Available only for Standalone or FreeRTOS. Used to keep the embedded software drivers and libraries that are required to create the BSP for the user hardware design. This is a directory and it will be copied into the <platform>/sw/<sysconfig>/<domain>/bspRepo location. And an entry will be added in the spfm file with the tag sdx:bspRepo.
  • Prebuilt data: This specifies a directory containing a prebuilt bistream and pre-generated software artifacts, meant to be representative of a software-only project with no functions accelerated in hardware. See Prebuilt Hardware for more information on generating prebuilt data for custom platforms.

In addition, when the domain is selected in the Editor, you will see sub-headings of the domain as follows:

  • Prebuilt Image: For Linux domains only, this indicates the Prebuilt Linux Image content that was specified when the domain was created.
  • Application Settings: For Standalone or FreeRTOS domains, this indicates the Linker Script that was specified when the domain was created.
  • Board Support Package: For Standalone or FreeRTOS domains, this specifies a Microprocessor Software Specification (MSS) file that defines the board support package (BSP) libraries and drivers for the base platform without any accelerators, and is the baseline for creating an MSS for the final design that includes the platform, data motion network and hardware accelerator functions. With the MSS, you will be able to define the libraries and the library options. This option will be added to the spfm file with the tag sdx:bspConfig. The MSS file provided will be copied in the <platform>/sw/<sysconfig>/<domain> location.
    IMPORTANT: You should provide an MSS file only if you do NOT want to use default settings for the BSP. If you specify a MSS file, you must also specify Include Paths pointing to a directory containing include files generated when using the MSS file.
  • Libraries: Displays two fields:
    • Libraries: Lets the platform user select the individual libraries to make available for an application.
    • Include Paths: Lets the platform user point to directories containing include files to make them available for an application.
      TIP: Libraries will be copied into <platform>/sw/<sysconfig>/<domain>/lib, and Include Paths will be copied into <platform>/sw/<sysconfig>/<domain>/inc.

Generate Platform and Add to Repository

After configuring the settings for your SDSoC platform project, you can click the Generate Platform command in the workflow at the bottom of the Editor. This will start the process of copying and creating files, and generating metadata for your platform. The new platform files will be written into the workspace for the platform project. You can regenerate the platform files as needed.
IMPORTANT: If you make any changes to any of the fields in the platform project, System Configuration, or domains, you must regenerate the platform to update the platform in the repository. You do not need to re-export the platform to the repository, but you will need to regenerate the output.

When the SDx platform is generated, it is written to the platform project folder in the workspace/<project_name>/export folder.

Finally, with the platform generated, click the Add to Custom Repositories command in the workflow at the bottom of the Editor. This adds the exported platform to the SDx custom repository for use in SDx Application and System projects. The custom repository is a list of directories, where the SDx tool scans for additional platforms. When you click Add to Custom Repositories, the platform output directory (./export) is added to the repository.

To share this platform with other users you can copy the exported platform folder to a common location, and ask other users to add that location to their custom repository using the Xilinx > Add Custom Repository menu command. The platform will be added to the list of available platforms as shown below.

TIP: The SDx GUI journals the TCL commands that underlie the actions identified in this section so that you can script platform generation. For an example of using the command-line flow to build an SDSoC platform, refer to Making the SDSoC Platform from the Command Line.