Part 2 shows how to write optimized C code on the mAgic DSP.
Developing a powerful new DSP is no easy feat. To be successful, developers must strike a delicate balance between often conflicting requirements. A DSP must offer competitive performance for its target applications. It must be small to keep costs low. And it must have powerful, easy to use software tools that enable DSP programmers to meet increasingly short development cycles.
In designing the architecture and software tools for the mAgic DSP, our group at Atmel's goal was ambitious; create a DSP that was small, powerful, could be programmed exclusively with a C-based toolchain, and deliver C code performance equivalent to that of hand-optimized assembly. In this article we show how we accomplished this goal in the mAgic DSP by focusing on hardware and software interaction from the beginning, designing and optimizing the architecture and toolchain concurrently.
mAgic DSP
First, a brief overview of the mAgic DSP (Figure 1). The mAgic DSP an ATMEL floating-point VLIW DSP. It delivers 1 GFLOPS at 100 MHz, and in a single cycle can perform up to 10 floating point operations, 4 data movements from/to internal memory, 2 address updates, and 1 DMA communication. The mAgic DSP is part of the DIOPSIS system on chip (SoC), which includes a 200 MHz ARM9 processor and numerous peripherals.
(Click to enlarge)
Figure 1. Overview of the mAgic DSP architecture.
Software tools: what's so wrong with assembly?
Relying on customers to program in assembly is simply no longer viable. Time to market pressures have made switching to assembly a decision no application manager wants to make. Assembly often requires developers to learn a completely new language. And getting highly optimal code (the main motivation for the switch) requires intimate knowledge of a typically complex DSP architecture. Programmers must know all the registers, specialized instructions, specialized data paths, pipeline stages and so on.
Moreover, assembly is not portable and difficult to maintain. In a world of emerging standards that continually forces companies to update code and/or migrate to newer, more powerful processors, this presents a terrible problem—a problem that's exacerbated further when the person who wrote the code leaves the company.
In the market there exists a strong consolidated concept: C is the natural successor to assembly. C gives you the flexibility of handling low, bit level details but is still common and easy to use. For next generation processors, unless your powerful new hardware feature is easily accessible from C, it will likely go unused, resulting in wasted silicon area and development time.
To illustrate the benefits of C over assembly, take for example the signal processing library for the mAgic DSP. In the first generation mAgic DSP, this library was written in assembly. For the second generation it was written entirely in C. Both were written by the same skilled team. Working in C, this team obtained the same or better performance levels and reduced development time by a factor 3. This factor would be higher if we took training time into account.
