CMP EMBEDDED.COM

Login | Register     Welcome Guest IPS  Call for Abstracts
 

DSP optimization strategies using simulators and profilers
This article reveals the pros and cons of simulators and profilers. It shows how to use these tools to optimize code and to choose the right memory layout and sizing.



DSP DesignLine
[Editor's note: For more tips on using simulators and emulators to optimize DSP code, see Measuring DSP code performance.]

DSP developers face a long and growing set of challenges. The constraints a typical DSP programmer faces can be summarized by the following:

  • The processor computation power, in terms of available MHz, is limited due to cost and power constraints
  • The amount of zero-wait state (also referred to as level 1 memory) is reduced to the minimum and is usually dictated by cost constraints. In addition, there is a severe latency penalty for accessing code and data in level 2 and 3 memories as well as in external SDRAM
  • The latest processors have a deep pipeline (8 stages and above), which causes a severe latency penalty in the cases of pipeline breaks (e.g., false branch predictions or interrupt latency)
  • The consolidation of different types of tasks such as video, audio and wireless modems on a single processor requires fast and sophisticated task switching
  • The integration of different types of software requires complex optimizations. For example, control code demands smaller code size while real-time DSP software is constrained by cycle counts In addition to the above technology constraints, there are numerous market considerations, such as the never for product differentiation and the ever-shrinking window of opportunity for new products that dictates a short design cycle.

When developing software under so many constraints, the development environment becomes a critical factor. An effective development tool chain can enable the designer to meet the goals for the product, while an insufficient one can lead to failure. As a result, it is important to have a comprehensive, advanced and robust tool chain. Such a tool chain should include optimizing compilers, advanced debugging and analysis tools, as well as a fully featured integrated development environment (IDE). The tool chain will be most effective if it was defined in conjunction with the definition of the processor's instruction set architecture (ISA) to make full use of the ISA's features.

In the following sections, we will describe two major elements in the CEVA tool chain environment, and how these tools are utilized to improve software and increase productivity. These tools are:

  • Comprehensive and accurate system simulation
  • C-level system profiling

From theory to practice—how do we put all together?
Before we dive into the details of the simulation environment and profiling capabilities, let's roughly describe the methodology for DSP-based software development. As in the development of most software products, DSP software design flow is generally comprised of the following stages:


1. The Five Stages of DSP Software Design Flow

It is clear that the last stage of the design flow (stage 5 above) needs to be executed on the hardware platform or a representative emulator such as an FGPA. However, a comprehensive, accurate software-based emulator can take care of stages 3 and 4, and it significantly reduces the efforts, complexity and time spent in stage 5. The hardware can be modeled (simulated) and the software development can be based on the simulated hardware rather than on the real hardware. This provides many benefits, which are described in the next section.

Simulation: Shortens time and effort, improves performance
The simulation environment is essential for real-time DSP software development. Some of the key benefits include:

  • Visibility/Transparency – hardware internals and the operation of the hardware logic can be monitored in a simulator. These internal operations would not normally be visible in the real hardware environment because they are not part of the hardware interface. Understanding what is going on behind the scenes is often a key to resolving problems and improving performance.
  • Debugging – a simulation environment can offer extra debug functionalities that are not supported by the hardware itself. Relying solely on hardware inevitably makes debugging far more difficult and time consuming.
  • Flexibility – a simulation environment provides the ability to check several system layouts and scenarios before committing to the final system architecture. You cannot always predict in advance the effects on the system when choosing specific settings. Thus, reaching optimum performance is a matter of trial-and-error where you experiment with various hardware parameters and software configurations. Obviously, setting up these different scenarios is much faster in a simulator than it is in hardware.
  • Time – an effective simulator enables parallel hardware and software development without the time and expense of generating hardware before executing runtime tests.

CEVA has developed a state-of-the-art simulation and profiling environment. Full software modeling of the architecture, coupled with comprehensive profiling capabilities, assists system architects and DSP software developers in multiple aspects of their application designs. The methodology and environment contribute significantly to enhanced system performance and enables corresponding reductions in development time. A full modeling environment means that the simulator can be used in several modes for different stages or purposes of the development.

1 | 2 | 3

Rate this article: Low High
Current rating
  • .
Embedded.com Career Center
Ready to take that job and shove it?
SEARCH JOBS

Browse all jobs

SPONSOR
RECENT JOB POSTINGS




 :