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
- Ultra-Low-Power LPDDR3/LPDDR2/DDR3L Combo Subsystem
- 1G BASE-T Ethernet Verification IP
- Network-on-Chip (NoC)
- Microsecond Channel (MSC/MSC-Plus) Controller
- 12-bit, 400 MSPS SAR ADC - TSMC 12nm FFC
Related Articles
- It's Just a Jump to the Left, Right? Shift Left in IC Design Enablement
- How to Design SmartNICs Using FPGAs to Increase Server Compute Capacity
- Automotive Design Needs Efficient Verification to Survive
- An introduction to offloading CPUs to FPGAs - Hardware programming for software developers
Latest Articles
- Extending and Accelerating Inner Product Masking with Fault Detection via Instruction Set Extension
- ioPUF+: A PUF Based on I/O Pull-Up/Down Resistors for Secret Key Generation in IoT Nodes
- In-Situ Encryption of Single-Transistor Nonvolatile Memories without Density Loss
- David vs. Goliath: Can Small Models Win Big with Agentic AI in Hardware Design?
- RoMe: Row Granularity Access Memory System for Large Language Models