DSP system design, part 2: Critical design choices
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
New Articles
- Quantum Readiness Considerations for Suppliers and Manufacturers
- A Rad Hard ASIC Design Approach: Triple Modular Redundancy (TMR)
- Early Interactive Short Isolation for Faster SoC Verification
- The Ideal Crypto Coprocessor with Root of Trust to Support Customer Complete Full Chip Evaluation: PUFcc gained SESIP and PSA Certified™ Level 3 RoT Component Certification
- Advanced Packaging and Chiplets Can Be for Everyone
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- UPF Constraint coding for SoC - A Case Study
- Dynamic Memory Allocation and Fragmentation in C and C++
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)