English
DSP system design, part 2: Critical design choices
By Kim Rowe, RoweBots Research
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:
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.
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.
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.
|
E-mail This Article | 
|
|
Printer-Friendly Page |
Related Articles
- Embedded DSP Software Design Using Multicore a System-on-a-Chip (SoC) Architecture: Part 2
- Dealing with automotive software complexity with virtual prototyping - Part 2: An AUTOSAR use case
- Optimizing embedded software for power efficiency: Part 2 - Minimizing hardware power
- Automotive System & Software Development Challenges - Part 2
- Hardware/software design requirements planning - Part 2: Decomposition using structured analysis