Using softcore-based FPGAs to balance hardware/software needs in a multicore design
By Bryon Moyer, Teja Technologies, Inc.
Mar 15 2006 (11:00 AM), Embedded.com
Embedded system design is a dance between software and hardware. The question is, which of the two gets to call the tune? Who leads? Who controls the relationship?
On the one hand, it is the hardware that really does the work. On the other hand, the ultimate functionality of the system tends to be in the software, with the hardware supporting that effort. Hardware and software engineers may have differing opinions as to which of those spins is more accurate.
In reality, system hardware and software are defined together at a high level. Board content, memory size, I/O, and other such pieces of support hardware are provided to address the needs of the functions to be executed by the software. But at a lower level, once a processing engine is picked, the on-chip computational resources are fixed and immutable.
Any changes to this fixed structure have to be managed through patching with separate accelerator chips. As soon as the processor decision is concrete, there is a shift from a process of designing hardware to meet the software needs to a process of working the software to ensure it fits within the constraints of the processor or processors (in the case of a multi-core implementation).
This is intensified in embedded design, where resources are relatively scarce and performance may be mission-critical. From here on, the hardware leads the dance, and the software follows. The software becomes an enabler in a codependent relationship that caters to the sometimes unreasonable needs of the hardware.
Mar 15 2006 (11:00 AM), Embedded.com
Embedded system design is a dance between software and hardware. The question is, which of the two gets to call the tune? Who leads? Who controls the relationship?
On the one hand, it is the hardware that really does the work. On the other hand, the ultimate functionality of the system tends to be in the software, with the hardware supporting that effort. Hardware and software engineers may have differing opinions as to which of those spins is more accurate.
In reality, system hardware and software are defined together at a high level. Board content, memory size, I/O, and other such pieces of support hardware are provided to address the needs of the functions to be executed by the software. But at a lower level, once a processing engine is picked, the on-chip computational resources are fixed and immutable.
Any changes to this fixed structure have to be managed through patching with separate accelerator chips. As soon as the processor decision is concrete, there is a shift from a process of designing hardware to meet the software needs to a process of working the software to ensure it fits within the constraints of the processor or processors (in the case of a multi-core implementation).
This is intensified in embedded design, where resources are relatively scarce and performance may be mission-critical. From here on, the hardware leads the dance, and the software follows. The software becomes an enabler in a codependent relationship that caters to the sometimes unreasonable needs of the hardware.
To read the full article, click here
Related Semiconductor IP
- Mesochronous Bridge for PCIe/CXL
- AI-native GPU
- OpenGMSL Verification IP
- OpenGMSL Leaf IP
- FlexGen Multi-Die Smart Network-on-Chip (NoC) IP
Related Articles
- Automotive Design Needs Efficient Verification to Survive
- It's Just a Jump to the Left, Right? Shift Left in IC Design Enablement
- An introduction to offloading CPUs to FPGAs - Hardware programming for software developers
- It's Not My Fault! How to Run a Better Fault Campaign Using Formal
Latest Articles
- FlexSpIM: An Event-Based Digital Compute-In-Memory Accelerator with Flexible Operand Resolution and Layer-Wise Hybrid Stationarity
- MeshKV: A Network-on-Chip KV Cache Fabric for Scalable Transformer Decoding Accelerators
- Analog Pin Directionality as an Exfiltration Attack Surface in Mixed-Signal ICs
- SIMT-Aware Lockstep Verification and Functional-Coverage Closure Methodology for an Open-Source RISC-V GPGPU: A UVM 1.2 Environment
- Efficient Hardware Information-Flow Tracking for Pre-Silicon Security Testing