How to make your asymmetric multiprocessor design OS and CPU independent
By Francis St. Amant , Polycore Software Inc.
Dec 21 2005 (1:42 AM), Embedded.com
Even as semiconductor companies tend toward multiprocessing solutions in many network as well as embedded consumer and mobile designs, the RTOSes and development tools are still rushing to catch up with the shift.
Most multiprocessing-capable operating systems support one type of processor at a time and are often limited to symmetric multiprocessing (SMP). While SMP provides a relatively straightforward path from single processing, it can only be used for homogeneous configurations with shared resources.
But most embedded applications are at least partially asymmetric in nature. And asymmetric multiprocessor (AMP) systems require multiple instantiations of the same or different operating systems running on different cores.
In a system with different OSes or a heterogeneous multicore system, implementing a common middleware structure to manage communications between the processors comes down to bridging between the different OSes and/or processor types.
Many of the first generation multiprocessor designs currently in consumer embedded systems, fortunately, are not complicated and it has been possible to incorporate simple, often hand-coded, communications mechanisms to synchronize operation. But such designs will not scale well and are not portable to the next generation of three, four, six and eight core configurations that are emerging.
What is needed is a way to organize all the system software modules necessary for inter-core communications into a framework transparent to the operating system or platform (hardware and logical).
Dec 21 2005 (1:42 AM), Embedded.com
Even as semiconductor companies tend toward multiprocessing solutions in many network as well as embedded consumer and mobile designs, the RTOSes and development tools are still rushing to catch up with the shift.
Most multiprocessing-capable operating systems support one type of processor at a time and are often limited to symmetric multiprocessing (SMP). While SMP provides a relatively straightforward path from single processing, it can only be used for homogeneous configurations with shared resources.
But most embedded applications are at least partially asymmetric in nature. And asymmetric multiprocessor (AMP) systems require multiple instantiations of the same or different operating systems running on different cores.
In a system with different OSes or a heterogeneous multicore system, implementing a common middleware structure to manage communications between the processors comes down to bridging between the different OSes and/or processor types.
Many of the first generation multiprocessor designs currently in consumer embedded systems, fortunately, are not complicated and it has been possible to incorporate simple, often hand-coded, communications mechanisms to synchronize operation. But such designs will not scale well and are not portable to the next generation of three, four, six and eight core configurations that are emerging.
What is needed is a way to organize all the system software modules necessary for inter-core communications into a framework transparent to the operating system or platform (hardware and logical).
To read the full article, click here
Related Semiconductor IP
- HBM4 PHY IP
- Ultra-Low-Power LPDDR3/LPDDR2/DDR3L Combo Subsystem
- MIPI D-PHY and FPD-Link (LVDS) Combinational Transmitter for TSMC 22nm ULP
- HBM4 Controller IP
- IPSEC AES-256-GCM (Standalone IPsec)
Related Articles
- How to Elevate RRAM and MRAM Design Experience to the Next Level
- Last-Time Buy Notifications For Your ASICs? How To Make the Most of It
- How to design secure SoCs, Part V: Data Protection and Encryption
- How to Turbo Charge Your SoC's CPU(s)
Latest Articles
- ElfCore: A 28nm Neural Processor Enabling Dynamic Structured Sparse Training and Online Self-Supervised Learning with Activity-Dependent Weight Update
- A 14ns-Latency 9Gb/s 0.44mm² 62pJ/b Short-Blocklength LDPC Decoder ASIC in 22FDX
- Pipeline Stage Resolved Timing Characterization of FPGA and ASIC Implementations of a RISC V Processor
- Lyra: A Hardware-Accelerated RISC-V Verification Framework with Generative Model-Based Processor Fuzzing
- Leveraging FPGAs for Homomorphic Matrix-Vector Multiplication in Oblivious Message Retrieval