English
Embedded DSP Software Design Using Multicore a System-on-a-Chip (SoC) Architecture: Part 2
By Robert Oshana, Texas Instruments
Embedded.com -- (11/27/07, 12:43:00 AM EST)
Software development for SoCs involve partitioning the application among the various processing elements based on the most efficient computational model. This can require a lot of trial and error to establish the proper partitioning. At a high level the SoC partitioning algorithm is as follows:
Place the state machine software (those algorithms that provide application control, sequencing, user interface control, event driven software, and so on) on a RISC processor such as an ARM.
Place the signal processing software on the DSP, taking advantage of the application specific architecture that a DSP offers for signal processing functions.
Place high rate, computationally intensive algorithms in hardware accelerators, if they exist and if they are customized to the specific algorithm of consideration.
As an example, consider the software partitioning shown in Figure 11.7 below. This SoC model contains a general-purpose processor (GPP), a DSP, and hardware acceleration. The GPP contains a chip support library which is a set of low level peripheral APIs that provide efficient access to the device peripherals, a general-purpose operating system, an algorithmic abstraction layer and a set of API for and application and user interface layer.
The DSP contains a similar chip support library, a DSP centric kernel, a set of DSP specific algorithms and interfaces to higher level application software. The hardware accelerator contains a set of APIs for the programmer to access and some very specific algorithms mapped to the acceleration.
The application programmer is responsible for the overall partitioning of the system and the mapping of the algorithms to the respective processing elements. Some vendors may provide a "black box" solution to one or more of these processing elements, including the DSP and the hardware accelerators.
This provides another level of abstraction to the application developer who does not need to know the details of some of the underlying algorithms. Other system developers may want access to these low level algorithms, so there is normally flexibility in the programming model for these systems, depending on the amount of customization and tailoring required.
Embedded.com -- (11/27/07, 12:43:00 AM EST)
Software development for SoCs involve partitioning the application among the various processing elements based on the most efficient computational model. This can require a lot of trial and error to establish the proper partitioning. At a high level the SoC partitioning algorithm is as follows:
Place the state machine software (those algorithms that provide application control, sequencing, user interface control, event driven software, and so on) on a RISC processor such as an ARM.
Place the signal processing software on the DSP, taking advantage of the application specific architecture that a DSP offers for signal processing functions.
Place high rate, computationally intensive algorithms in hardware accelerators, if they exist and if they are customized to the specific algorithm of consideration.
As an example, consider the software partitioning shown in Figure 11.7 below. This SoC model contains a general-purpose processor (GPP), a DSP, and hardware acceleration. The GPP contains a chip support library which is a set of low level peripheral APIs that provide efficient access to the device peripherals, a general-purpose operating system, an algorithmic abstraction layer and a set of API for and application and user interface layer.
The DSP contains a similar chip support library, a DSP centric kernel, a set of DSP specific algorithms and interfaces to higher level application software. The hardware accelerator contains a set of APIs for the programmer to access and some very specific algorithms mapped to the acceleration.
The application programmer is responsible for the overall partitioning of the system and the mapping of the algorithms to the respective processing elements. Some vendors may provide a "black box" solution to one or more of these processing elements, including the DSP and the hardware accelerators.
This provides another level of abstraction to the application developer who does not need to know the details of some of the underlying algorithms. Other system developers may want access to these low level algorithms, so there is normally flexibility in the programming model for these systems, depending on the amount of customization and tailoring required.
|
E-mail This Article | 
|
|
Printer-Friendly Page |
|
||||||
Related Articles
- Embedded DSP Software Design on a Multicore SoC Architecture: Part 1
- An architecture for designing reusable embedded systems software, Part 2
- DSP system design, part 2: Critical design choices
- Internal JTAG - A cutting-edge solution for embedded instrument testing in SoC: Part 2
- Optimizing embedded software for power efficiency: Part 2 - Minimizing hardware power
New Articles
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- UVM RAL Model: Usage and Application
- Dynamic Memory Allocation and Fragmentation in C and C++
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)