Building applications in SDK

The software workflow in SDK is described in the following figure.

SDK software workflow

The first step in developing a software application is to create a Board Support Package (SDK) that will be used by the application. Then, you can create an application project.

To build an executable for this application, SDK automatically performs the following actions. Configuration options can also be provided for these steps.

  1. SDK builds the board support package using Libgen. This is sometimes called a software platform.
  2. SDK compiles the application software using a platform-specific gcc/g++ compiler.
  3. The object files from the application and the Board Support Package are linked together to form the final executable. This step is performed by a linker which takes as input a set of object files and a linker script that specifies where object files should be placed in memory.

The following sections provide an overview of concepts involved in building applications.


Compilation of source files into object files is controlled using Makefiles. With SDK, there are two possible options for Makefiles:

Build configurations

Software developers typically build different versions of executables, with different settings used to build those executables. For example, an application that is built for debugging uses a certain set of options (such as compiler flags and macro definitions), while the same application is built with a different set of options for eventual release to customers. SDK makes it easier to maintain these different profiles using the concept of build configurations.

Each build configuration could customize:

By default, SDK provides three build configurations, as shown here:

Configuration TypeCompiler Flags
Debug -O0 -g
Release -O2
Profile -O2 -g -pg

MicroBlaze-specific options

Applications specific to the MicroBlaze™ processor can be compiled in one of two modes:

Linker scripts

The final step in creating an executable from object files and libraries is linking. This is performed by a linker which accepts linker command language files called linker scripts. The primary purpose of a linker script is to describe the memory layout of the target machine, and specify where each section of the program should be placed in memory.

SDK provides a linker script generator to simplify the task of creating a linker script. The linker script generator GUI examines the target hardware platform and determines the available memory sections. The only action required by you is to assign the different code and data sections in the ELF file to different memory regions.

Note: For multi-processor systems, each processor will be running a different ELF file, and each ELF file requires its own linker script. Ensure that the two ELF files do not overlap in memory.

Related concepts
Board support package (SDK)
SDK application projects

Related tasks
Creating software projects

Related references

Copyright © 1995-2010 Xilinx, Inc. All rights reserved.