|
Part 1 presents ten laws that guide DSP system development.
In part 1, we looked at the basic laws that guide DSP system development. We will now apply these principles to the key decisions that every designer must make. When building DSP systems, there are five critical elements that determine the performance of the final system. They are:
- The DSP engine,
- Programming,
- Real-Time Operating System (RTOS),
- I/O and DMA support, and
- DSP libraries.
This article will talk about all of these items, but we will first look at issues related to design requirements.
Design requirements
Many DSP applications are characterized by a short window of opportunity. If the product comes to market late, it will sell poorly or not at all. In order to meet these short windows, OEMs must get their designs right the first time—and this is a major challenge.
Generally, a design must meet both business and technical requirements. First and foremost, new products must meet the OEM's strategic and marketing goals. For example, many design requirements flow from user needs and wants, and from the OEM's desire for differentiating features. The technical requirements are often driven by the technologies selected—e.g., the requirements for FPGAs are different than those for DSP—and by the IP available for reuse.
Market research and prototyping are essential elements of requirement definition. These steps verify the marketability of a product, reduce risks, and ensure that the requirements are both correct and reasonable. Prototyping also provides great insight into a system's real-world performance. Thus, prototyping should always precede system design, particularly when the product is substantially new.
Of course, getting the requirements correct is only the start. The OEM must then follow through with proper system design and software architecture.
System Design
First and foremost, system design is driven by performance and feature requirements—a product won't sell if it does not perform the expected functions. However, the designer must also create a design appropriate for the targeted sales volume to maximize profits and minimize costs. With both of these factors considered, the system design choices become clear. Here are some examples:
- A wireless meter reader has high sales volume and very compact physical dimensions. Thus, ASICs are the natural solution. However, the ASICs must be flexibile to meet future needs, such as a wider measurement range.
- A radar processor for an unmanned aerial vehicle (UAV) has very low volumes and a long field life, and it requires high performance floating point processing. Generally this means COTS processors like PowerPC or SHARC, possibly in concert with FPGAs for glue logic and hardware acceleration.
- An acoustic helmet mounted sniper range and direction system has medium volume, and must be small and portable. The size and power requirements favor an ASIC approach, but the volume doesn't warrant such expense. FPGAs are not an option due to high development costs and power requirements. Thus, a digital signal controller (DSC) like the dsPIC is a good option. DSCs are capable of performing the calculations, and some have excellent high volume pricing.
Figure 1. Volume, size, and power technologies.
In reviewing the options, the OEM should keep in mind that most applications have been implemented before. An examination of these systems will provide valuable insight into the optimal system design.
As noted earlier, prototyping also provides valuable insight. A key system architecture prototyping approach is to implement the entire set of algorithms in MATLAB. Doing so eliminates substantial algorithm risk. MATLAB specifications can also be used to generate a software implementation running on a DSC or DSP, or a hardware implementation using an FPGA. These generated implementations are good for lower volume solutions, but are too inefficient for volume production.
To get sufficient efficiency for volume production, OEMs typically take the algorithms from MATLAB and recode them in C or C++. In many cases, the design requirements require splitting the code across multiple processors. In some designs, part of the processing will be implemented on an FPGA, while the rest is left in software. This latter approach is become more common now that C to FPGA compilers are available.
|
