7. Hardware-Software Co-Design

Learning Objectives

• Define hardware-software co-design and explain why it replaced sequential hardware-then-software development
• Explain the hardware/software partitioning decision and the trade-offs it involves
• Read a simple VHDL module and compare it to the equivalent C function
• Explain the role of co-simulation and rapid prototyping in catching integration bugs early
• Describe System-on-Chip (SoC) design as the natural conclusion of co-design thinking
• Analyze a design scenario to decide whether a function belongs in hardware or software

Quick Answer

Hardware-software co-design is the practice of developing the hardware and software components of an embedded system concurrently and interactively, rather than designing all the hardware first and writing software for it afterward. The core decision it forces engineers to make explicit is partitioning: which functions run as software on a general processor, and which run as dedicated hardware logic (in an FPGA or ASIC)? Getting this decision right matters because hardware is fast but expensive and inflexible to change, while software is flexible and cheap to change but slower. Co-design exists because sequential design — build the board, then write the firmware — routinely discovers integration problems (a UART wired to the wrong pin, insufficient processing throughput for a signal) only after both halves are already built, which is exactly when fixing them is most expensive.

The Partitioning Decision

Every function in an embedded system can, in principle, be implemented in either hardware or software. The central question of co-design is: where should this function live?

Consideration	Favors Hardware	Favors Software
Speed requirement	Needs true parallelism or nanosecond timing	Can tolerate sequential execution
Flexibility needed	Function is fixed and unlikely to change	Function needs frequent updates/tweaks
Development cost	High volume justifies upfront HDL design cost	Low volume; cheaper to iterate in code
Power/area budget	Dedicated circuit uses less energy per operation than a general CPU running equivalent code	General processor already present; reuse is "free"

A concrete example: a 4-bit adder can be implemented as a dedicated hardware circuit or as a software function. Here is the same operation both ways.

Hardware (VHDL) — a real parallel circuit that computes the sum in one clock edge:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity simple_adder is
    Port ( A : in STD_LOGIC_VECTOR (3 downto 0);
           B : in STD_LOGIC_VECTOR (3 downto 0);
           SUM : out STD_LOGIC_VECTOR (4 downto 0));
end simple_adder;

architecture Behavioral of simple_adder is
begin
    SUM <= ("0" & A) + ("0" & B);
end Behavioral;

Software (C) — the same logical operation, executed sequentially by a CPU:

uint8_t add_4bit(uint8_t a, uint8_t b) {
    return (a & 0x0F) + (b & 0x0F);   // masked to 4 bits, returns up to 5-bit result
}

For a single 4-bit add, software is obviously the right choice — there's no reason to burn silicon area on a dedicated adder when the CPU's ALU already does this in one instruction. But now imagine needing to add 1,000 independent 4-bit pairs simultaneously, every clock cycle — a task like real-time FIR filtering across many channels. A CPU must process these one at a time in a loop; dedicated hardware can compute all 1,000 sums in parallel in the same single clock edge. This is precisely the kind of decision co-design methodology forces engineers to make deliberately, with real numbers, instead of defaulting to "software because that's what we know."

Why Co-Design Instead of Sequential Design

The traditional (and riskier) approach: finalize the hardware design completely, fabricate or assemble the board, and only then start writing software for it. Problems this creates:

• If the software team discovers the chosen MCU's ADC can't sample fast enough for the required signal, the hardware must be respun — after it's already built.
• If a peripheral is wired to a pin sharing a conflicting internal function, this is only found once real code tries to use it.
• Total project schedule is the sum of hardware time and software time, since software can't meaningfully start until real hardware exists.

Co-design addresses all three by developing hardware and software concurrently, using simulation and virtual prototypes so software development can start on a simulated model of the hardware before physical silicon exists.

Co-Simulation and Prototyping

Co-simulation runs a model of the hardware (in a tool like ModelSim or QEMU) alongside the actual software, letting engineers verify that a piece of firmware correctly drives simulated hardware registers before any physical board exists. This catches an entire category of bugs — incorrect register addresses, wrong bit-field assumptions, timing mismatches — at the cheapest possible point in the project.

Rapid prototyping builds a functional but not-yet-final version of the system (often on an FPGA standing in for what will eventually be an ASIC) so the whole team can test real interaction between hardware and software early, iterating quickly before committing to expensive, hard-to-change fabrication.

System-on-Chip: Co-Design Taken to Its Conclusion

A System-on-Chip (SoC) integrates a CPU core, memory, and custom hardware accelerators onto a single die — the natural end point of co-design thinking. A smartphone SoC, for example, dedicates specialized hardware blocks to tasks that would be far too slow or power-hungry in pure software: a hardware video decoder block, a hardware image signal processor for the camera, and a neural processing unit for ML inference, all alongside a general-purpose CPU running the operating system and apps. Deciding which functions get their own silicon block versus running as software on the general CPU is exactly the partitioning decision co-design methodology formalizes — done at massive scale and with enormous consequences for battery life and performance.

Why It Matters

Getting the hardware/software partition wrong is expensive in both directions. Put too much in hardware and you've spent months of HDL design and fabrication cost on a function that could have shipped as a software update in a week — and now it can never be patched without a new chip revision. Put too much in software and your product misses its real-time or power targets because a general CPU simply cannot match dedicated silicon's parallelism and efficiency for that specific task. Co-design methodology exists precisely to make this trade-off a deliberate, data-driven engineering decision rather than a default based on team comfort or historical habit.

Key Terms

Term	Definition	Related Concept
Hardware-software partitioning	The decision of which system functions run as dedicated hardware versus general-purpose software	Co-design
HDL (Hardware Description Language)	A language (VHDL, Verilog) used to describe digital circuits before fabrication or FPGA loading	FPGA, ASIC
Co-simulation	Simulating hardware and software together to verify correct interaction before physical hardware exists	Virtual prototyping
Rapid prototyping	Building a functional but non-final system (often FPGA-based) to test integration early	FPGA, ASIC
System-on-Chip (SoC)	A single chip integrating CPU, memory, and dedicated hardware accelerators	Partitioning, ASIC
Hardware accelerator	A dedicated circuit block performing one function (e.g., video decode) far faster/more efficiently than software	SoC, parallel processing

Common Mistakes

Misconception: Hardware-software co-design just means "hardware people and software people talk to each other more." Why it's wrong: Co-design is a specific engineering methodology involving formal partitioning decisions, co-simulation tools, and concurrent development schedules — not simply improved communication between teams. Correct understanding: Co-design is the concurrent development of hardware and software using shared models/simulations, with an explicit decision process for what belongs in each domain.

---

Misconception: Putting a function in hardware is always faster and therefore always better if performance matters. Why it's wrong: Hardware implementation costs significant design time and fabrication expense, and — critically — is essentially unchangeable after fabrication (an ASIC bug ships forever). Many "performance-critical" functions are still better as software running on a sufficiently fast processor, preserving the ability to patch bugs or add features. Correct understanding: The partitioning decision must weigh speed against flexibility, development cost, and the real-world consequence of an un-patchable hardware bug — not default to "hardware is always faster, so hardware wins."

---

Misconception: Co-simulation is only useful for large, complex SoC projects. Why it's wrong: Even a simple embedded project benefits from co-simulation because it catches register-address mistakes, timing assumptions, and peripheral misconfiguration before physical hardware exists — errors that are just as costly to discover late on a simple board as on a complex one. Correct understanding: Co-simulation's value (catching integration bugs before physical fabrication) scales down to small projects just as it scales up to complex SoCs, though the tooling investment may not always be justified for the simplest one-off designs.

Comparison and Connections

Aspect	Sequential Design (hardware then software)	Hardware-Software Co-Design
When software starts	Only after hardware exists	Concurrently, using simulated/virtual hardware
Integration bugs found	Late — often after fabrication	Early — during co-simulation
Total schedule	Hardware time + software time (additive)	Overlapping — shorter total time
Risk of costly redesign	High	Lower
Best suited for	Very simple, well-understood designs	Complex SoCs, novel architectures, tight schedules

Practice Questions

Recall

1. What is the "partitioning" decision at the heart of hardware-software co-design? Answer guidance: Deciding which system functions are implemented as dedicated hardware circuits versus which run as software on a general-purpose processor.

2. Name two tools/techniques used in co-design to catch integration issues before final fabrication. Answer guidance: Co-simulation (simulating hardware and software together) and rapid prototyping (using an FPGA stand-in before committing to an ASIC).

Understanding

3. Explain why sequential hardware-then-software design tends to discover integration problems later and at higher cost than co-design. Answer guidance: In sequential design, software development can only begin once hardware is physically built, so mismatches (wrong pin assignments, insufficient throughput) are found only after fabrication, when fixing them requires an expensive respin, rather than during earlier concurrent simulation.

4. Why doesn't a single 4-bit addition operation justify a dedicated hardware adder, but 1,000 simultaneous 4-bit additions might? Answer guidance: A CPU's ALU already performs one 4-bit add in a single instruction essentially for free; software wins on flexibility and zero extra cost. But processing 1,000 independent adds every clock cycle requires true parallelism a sequential CPU cannot provide without looping 1,000 times, making dedicated parallel hardware the only way to meet that throughput.

Application

5. A team is designing an IoT sensor node that occasionally needs firmware updates to add new cloud protocols. Should the communication protocol logic be implemented in hardware or software? Justify your answer using the partitioning table. Answer guidance: Software — the requirement for frequent updates directly favors software's flexibility; hardware implementation would be unpatchable and require a costly ASIC/FPGA respin for every protocol change.

6. A video doorbell needs to decode H.264 video in real time on a tight power budget. Should video decoding be implemented in software on the main CPU or as a dedicated hardware accelerator? Justify your answer. Answer guidance: Dedicated hardware accelerator — H.264 decoding is computationally intensive and needs to run continuously; a hardware decoder block performs this far more power-efficiently than software on a general CPU, which matters critically given the tight power budget, and the function itself (a standardized codec) is unlikely to need frequent changes.

Analysis

7. Compare the risk profile of implementing an encryption algorithm in an ASIC versus in software, given that encryption standards are occasionally updated or deprecated due to newly discovered vulnerabilities. Answer guidance: An ASIC-hardcoded encryption algorithm cannot be patched if a vulnerability is found or the standard is deprecated — the entire product may need replacement. A software implementation can be patched via firmware update. This is a case where the "favors hardware" speed/efficiency argument must be weighed against a real risk that flexibility is needed, arguing for either a software implementation or a hardware accelerator that supports multiple/updatable algorithms.

8. A company skips co-simulation entirely, reasoning that "we've built similar boards before, so we don't need to simulate." They later discover in physical testing that the software cannot read the ADC fast enough for the intended signal. Evaluate what co-simulation would have caught and when. Answer guidance: Co-simulation modeling the ADC's timing characteristics alongside the planned software sampling loop would have revealed the throughput mismatch during the design phase, before any physical board was built — at that point, the fix (choose a faster ADC or reduce required sample rate) is a design change, not a costly hardware respin after fabrication.

FAQ

Is hardware-software co-design only relevant to companies designing custom chips? No. Even teams using off-the-shelf MCUs and FPGAs practice a lighter form of co-design whenever they develop firmware alongside hardware bring-up, using simulators or early prototype boards to catch integration issues before the final product is finalized — the core idea (don't wait for hardware to be 100% finished before starting software) scales down to smaller projects.

What's the difference between an HDL and a regular programming language like C? An HDL (VHDL, Verilog) describes parallel hardware circuits — every statement can represent something that exists and operates simultaneously in silicon. C describes sequential instructions executed one after another by a CPU. Writing HDL requires "thinking in parallel hardware," not translating software algorithms line by line.

Why would anyone still choose software if hardware is faster? Because hardware costs significant design and fabrication time/money and, once fabricated, generally cannot be changed — a bug or needed feature update in an ASIC often means the whole chip must be redesigned. Software can be patched in the field. The right choice depends on whether the function's requirements are stable and performance-critical enough to justify giving up that flexibility.

How does co-design relate to Hardware/Software Co-Simulation tools like QEMU? QEMU and similar tools let you run real firmware against an emulated model of the target hardware, so software development and testing can begin before physical silicon exists — a practical implementation of the co-simulation concept central to co-design methodology.

Does every embedded project need an FPGA to practice co-design? No — co-design is a methodology (concurrent development, explicit partitioning decisions, simulation before fabrication), not a requirement to use FPGAs specifically. FPGAs are simply a common way to prototype what will eventually become dedicated hardware (an ASIC) without committing to fabrication costs upfront.

Quick Revision

• Co-design develops hardware and software concurrently instead of sequentially (hardware first, then software)
• The central decision is partitioning: which functions run as dedicated hardware vs. general-purpose software
• Hardware favors speed/parallelism and efficiency at the cost of flexibility and high non-recurring engineering cost
• Software favors flexibility and low iteration cost at the cost of raw speed/parallelism
• HDLs (VHDL, Verilog) describe parallel circuits; C describes sequential instructions — fundamentally different mental models
• Co-simulation verifies hardware/software interaction using models before physical hardware exists
• Rapid prototyping (often via FPGA) tests real integration cheaply before committing to expensive fabrication
• An SoC is co-design's natural conclusion: CPU + hardware accelerators integrated on one die
• The riskiest partitioning mistake is hardcoding into an ASIC a function likely to need future updates (e.g., a security algorithm)
• Sequential design's total schedule is additive (hardware time + software time); co-design overlaps them, shortening delivery

Related Topics

Prerequisites: Embedded System Architecture, Embedded System Design

Related Topics: Embedded System Programming, Embedded System Applications

Next Topics: Debugging Embedded Systems, Future Trends in Embedded Systems