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.
To read the full article, click here
Related Semiconductor IP
- Zigbee Transceiver PHY
- Data Flow Architecture IP
- AMBA SPI Controller MRAM Controller
- Ethernet MAC
- Protocol Bridges
Related Articles
- A 24 Processors System on Chip FPGA Design with Network on Chip
- Using non-volatile memory IP in system on chip designs
- Skillfully Emulating a System on Chip
- Power Management for Internet of Things (IoT) System on a Chip (SoC) Development
Latest Articles
- A Low-Latency ASIC Architecture for Real-Time Line Segment Detection
- BitFair: A 12nm Bit-Serial CNN Accelerator with Learnable Early Termination and Adaptive Bit Ordering for Ultra-Low-Power XR Vision
- A Flexible Sparsity-Aware FPGA Accelerator with Column-Wise Compression for Efficient CNN Inference
- Reducing Instruction-Fetch Energy in RISC-V for Embedded AI Processing via Dynamic and Static Loop Caching
- SPARC: Automated Root-Cause Analysis of Pre-Silicon Power Side-Channel Leakage in the Processor Design Flow