Today's assortment of electronic gadgets relies on digital signal processing to interact with the outside world. Everything from your thermostat to cell phone and handheld organizer requires increasingly sophisticated technology to provide voice and graphical interaction. Add to this an insatiable demand for new features and applications, together with ever-shortening development cycles, and you have a picture of the challenges today's designers face. Advances in hardware and processor design promise a quantum leap in capability but bring a corresponding increase in complexity. The bottom line is a need for significant improvement in the design process.
Almost all of these devices and embedded applications are using some sort of DSP technology inside. Either a chip is specifically designed to do DSP or architectures are modified to have DSP capabilities, such as multiply-accumulate instructions or fixed-point data types. A couple of years ago, you could identify special DSP processors that were programmed in assembly and ran only a small piece of code. Today, hybrid situations prevail, whereby the same processor is used for other code as well and the applications are much larger.
Most processors now have DSP capabilities of some sort. In the past, compilers could not handle such architectural features well, and the DSP code was generally developed in assembly, a painstaking, time-consuming manual process. However, as architectures grew ever more complex over the last couple of years, it became clear that assembly code was simply too error-prone and resulted in an unacceptably long time-to-market. When you had only 4 or 16 kbytes of code, it wasn't a big deal. Now, with codes exceeding the megabyte level, it's not attractive anymore to use assembly. The trend is therefore toward high-level programming languages, especially C.
Moreover, designers today want as much flexibility as they can get when choosing a processor, because with so many new designs, they don't want to be tied to a particular selection. C code is more portable, takes less time to develop and can be used on different processors and platforms more easily than assembly code. This results in lower development and maintenance costs.
Today, when a designer is looking for a certain part to use, he or she is also looking at software tools. That includes the compilers that are now standard equipment with any particular piece of silicon. If the compiler doesn't provide efficient code, in many cases it just doesn't make sense to use the chip.
More and more architectures are being tuned to a specific application domain for example, special network processors for networking, or special DSPs for telecom. There are different approaches from different vendors and designers, but clearly the trend is to tune the hardware to the application in which it's going to be used. We see many more strange features in architecture design because they make sense for a particular application domain. They might include a special Viterbi decoding instruction for the telecom market, or a dedicated memory architecture, a specific pipeline or parallelism inside the core all features that make sense for specific applications.
Some vendors are producing parts with FPGAs on them so that designers can quickly change part of the instruction set of a CPU core according to the application needs. Everyone is trying to distinguish themselves and accommodate special market segments. And each strange, unique core requires a special compiler to program it.
All these trends pose interesting challenges to compiler vendors or developers. One issue is that there aren't that many compiler vendors left. Most have been bought out by processor developers to secure their tool development. The few that remain are busy and have long waiting lists. Their business model is aimed at selling tool chains in large volumes, and special processors aiming at a specific market are not always very attractive for these compiler developers. Also, these special architectures can pose a challenge to traditional compiler technologies.
Developers have a couple of options. First, they can pay a large amount of money to one of these compiler vendors and hope for the best. Or they can take matters into their own hands and develop the compiler themselves.
There are compelling reasons to bring such a project in-house. As the CPU developer, you know the most important part of the architecture and what the core technology is supposed to do. You know what your customers expect from the compiler, and the sort of applications they will be developing. And you know best what code the compiler is expected to produce, so you can tune the compiler to the architecture. When you do the compiler in-house, you can also give feedback to the hardware architects to improve the architecture to make it more efficient and compiler friendly. This leads to the most efficient combination in the end. Equally important, you have control over the project and you protect your intellectual property.
Rather than developing an entire compiler from scratch, you will want to start with a reliable basic technology. Technology that is easy to use and does all the generic things you expect of a compiler such as language parsing and high-level optimizations is the way to go. And then you want to quickly retarget that technology to your specific architecture, and focus on special features and optimizations that are specific for your architecture or application. The end result should be a real compiler product, efficient and robust, that you can proudly ship to your customers or developers.
Fortunately, such compiler-development systems are now available on the market including the CoSy system from Associated Compiler Experts (ACE) and are flexible enough to allow everybody to quickly develop the efficient compiler products that have become so important over the past few years.
If you're thinking of programming your DSP in a high-level language instead of assembler, that high-level language will almost certainly be a C variant. It's unlikely to be standard C, however, because standard C was never designed to handle the fixed-point arithmetic, divided memory spaces and circular buffers that are typical of DSP architectures. Of the several C variants available, the one you choose will have a significant impact on both the portability and efficiency of the generated code.
An extension to the C language called DSP-C can support DSP features for compiler development. Designed a few years ago by ACE and a number of customers, this extension adds a few language constructs, as a strict superset of ISO C. It supports fixed-point data types, multiple memory spaces and circular buffers three features of DSPs that you want to be able to describe in your application code in a convenient and portable manner. DSP-C is easy to use, easy to debug and cost effective.
DSP-C is on the standardization path, being discussed in an ISO working group, and at this point it's the de facto standard. A growing number of compiler developers support DSP-C.
Many other DSP characteristics can be supported without language constructs, such as hardware loops, parallel load and store, constraints on the register set, heterogeneous register sets and so on. DSP-C adds the things that the compiler can't figure out for itself.
In much the same way that C includes predefined routes for type conversion from a "short" to an "int" to a "long," DSP-C provides similar type-conversion routes from a "short fixed" to a "fixed" to a "long fixed." In other words, the new type definitions in DSP-C are supported in the same logical way that programmers have come to expect from a language like C.
Whereas the C-with-intrinsics approach tackles DSP issues from the target system viewpoint, resulting in a lack of portability, DSP-C tackles these issues from within the language itself. As a result, DSP-C programs remain highly portable.
By using a technology such as the CoSy compiler-development system, architecture designers are empowered to develop the compilers themselves, instead of standing in line for one of the few remaining third-party compiler vendors. They become more flexible in their compiler development and, with DSP-C, are able to get efficiency and performance where it counts from their architecture. Efficient DSP compiler products are a reality today, and a determining factor in the success of the exciting, advanced architectures being developed now.