Building applications in SDK

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

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.

Makefiles

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

• Managed Make: For Managed Make projects, SDK automatically creates Makefiles. Makefiles created by SDK typically compile the sources into object files, and finally link the different object files into an executable. In most cases, managed make simply eliminates the job of writing Makefiles. This is the suggested option.
• Standard Make: If you want ultimate control over the compilation process, use standard make projects. In this case, you must manually write a Makefile with steps to compile and link an application. Using the Standard Make flow hides a number of dependencies from SDK, so you must follow manual steps for other tasks such as debugging or running the application from within SDK. Therefore, the Standard Make flow is not recommended for general use.

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:

• Compiler Settings: Debug and Optimization levels
• Macros passed for compilation
• Linker Settings

MicroBlaze-specific options

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

• Executable Mode: This is the default mode. It creates an executable application.
• XMD Stub Mode: Applications running on hardware without an MDM connection to the MicroBlaze processor can be debugged if they are compiled in the XMD Stub Mode. This mode is not recommended for general use.

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.

Board support package (SDK)
SDK application projects

Creating software projects

Reference

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