Why Hardware-Software Co-Design Is Now a Systems Engineering Problem

For most of the embedded systems era, the hardware-software boundary was a negotiation that happened early and settled fast. Hardware architects drew a line: here is what runs on silicon, here is what runs on the processor, here are the register maps and interrupt lines. Software teams received that interface specification and built against it. The two domains coordinated at defined seams, and the V-model gave each side a clean lane.

That model is breaking down. Not because the underlying engineering has changed, but because the assumptions that justified the model no longer hold. Silicon development cycles are compressing. FPGAs have made hardware logic programmable—and therefore updatable—long after integration. Software-defined hardware architectures are pushing more and more system behavior into firmware layers that sit beneath the operating system but above the register file. The “line” between hardware and software is now a zone, and that zone is contested territory.

The result is that hardware-software co-design—once a specialized practice associated with SoC development and ASIC-intensive aerospace programs—has become a mainstream systems engineering problem. Teams that are building modern embedded systems for automotive, defense, industrial, and medical applications are discovering that their processes, tools, and organizational structures were optimized for a boundary that no longer exists.

What Changed, and When

Three developments have converged to dissolve the traditional boundary. They did not arrive simultaneously, but their combined effect has become impossible to ignore.

Silicon development timelines are no longer monolithic. The classic narrative was that hardware took three to five years and software waited. That is still partially true for custom ASICs, but the ecosystem has fragmented. High-level synthesis (HLS) tools let engineers implement IP blocks from C or SystemC, compressing RTL development. Chiplet architectures mean that programs can integrate pre-existing silicon blocks with custom logic, changing what needs to be designed versus licensed. And tape-out schedules for advanced nodes are increasingly driven by ecosystem factors—packaging availability, EDA tool readiness, IP qualification—rather than pure design time. The result is that hardware timelines are less predictable and less monolithic than they were, which means software teams cannot rely on stable targets.

FPGAs have normalized the idea of post-production hardware changes. In defense and aerospace programs, FPGAs have been used for reconfigurable signal processing for decades. But the practice has spread. Industrial equipment now ships with FPGA-based motor controllers that receive logic updates in the field. Automotive radar systems use FPGAs for algorithm implementation specifically because the algorithm will evolve post-production. When the hardware can be updated alongside the software, the concept of a hardware baseline becomes ambiguous. The interface agreement is not between a fixed hardware design and a software build—it is between two living artifacts.

Software-defined hardware has inserted a new engineering layer that belongs to neither domain. Programmable logic in power management ICs, configurable analog front ends, DSP cores with downloadable filter coefficients, memory controllers with tunable timing parameters—all of these are “hardware” in the sense that they are physical devices, but their behavior is substantially determined by configuration data that software teams load at runtime. This layer does not fit cleanly into hardware or software engineering processes. It is not RTL, so hardware verification tools do not cover it. It is not application code, so software testing frameworks do not handle it well. It sits in the gap, and in many programs, it is systemically undertested because neither side claims ownership.

What This Means for Interface Agreements

The interface control document (ICD) and software interface specification (SIS) were designed for a world where hardware and software teams negotiated once, documented the result, and then executed against it. That process assumes the interface is stable. It is not, in co-design contexts.

The specific failure modes are predictable. Hardware architectural decisions shift during RTL development—a DMA controller gets redesigned to support a new memory access pattern, and the software driver model that was specified six months ago is now wrong. FPGA logic is updated to fix a timing closure issue, and the change inadvertently alters interrupt latency in ways that break a real-time software assumption. A configuration parameter for a software-defined peripheral is changed to optimize power, and the downstream effect on signal chain behavior is not caught until system-level integration.

Each of these is a real failure mode that practicing engineers encounter. The common thread is that the change occurred within one domain but had cross-domain effects that were not caught by either domain’s internal review process.

Managing this requires treating interface agreements as living architectural artifacts, not as documents produced at a milestone and then filed. That means:

• Explicit allocation decisions with documented rationale. When a system function is allocated to hardware, firmware, or software, that decision needs to be recorded as a deliberate architectural choice with the reasoning captured. If the allocation changes, the rationale needs to be revisited, not just the artifact.
• Cross-domain change impact analysis. When a hardware engineering change order (ECO) is issued, the assessment needs to include downstream software and firmware effects. When a software requirement changes, the assessment needs to trace back to the hardware capabilities it depends on. This is not new in principle; it is extremely rare in practice.
• Interface versioning that both domains respect. Interface specifications need version control semantics, not document management semantics. Software teams need to know which version of the hardware interface they are building against, and they need to be notified—not surprised—when that version changes.

The V&V Problem

Verification and validation in co-design contexts is where the process debt comes due. Traditional V-model V&V assigns test responsibility by artifact type: hardware tests verify hardware requirements, software tests verify software requirements, system tests verify system requirements. That assignment works when the domains are cleanly separated. It fails when the thing being verified spans the boundary.

Consider a latency requirement: “The system shall process sensor input within 2 milliseconds of receipt.” In a co-design architecture, meeting that requirement depends on FPGA processing time, DMA transfer behavior, driver interrupt handling, firmware scheduling, and application layer processing—all of which are implemented across different substrates and developed by different teams. Which team owns the test? Which team owns the failure if the requirement is missed?

In practice, this often results in a test that is performed at the system level, late in integration, when the cost of failure is highest. The earlier verification activities—hardware simulation, software unit test, firmware bench test—are each internally valid but do not cover the cross-domain interaction. The gap is structural.

Leading teams are addressing this by explicitly modeling co-design requirements as cross-domain requirements, with allocated sub-requirements to each implementing layer. The latency requirement above gets decomposed: FPGA processing contributes N microseconds, DMA transfer contributes M microseconds, software scheduling contributes P microseconds, and the sum must be less than 2 milliseconds. Each sub-requirement is testable within its domain, and the system-level test verifies the integration. The decomposition and its rationale are part of the requirement structure, not buried in a design document.

How Leading Teams Are Approaching the Tooling Problem

The tooling situation in co-design is genuinely difficult. The tools that hardware teams use—EDA environments, simulation platforms, RTL verification suites—are not connected to requirements management. The tools that software teams use—IDEs, CI/CD pipelines, test frameworks—are similarly isolated. The tools that systems engineers use to manage requirements and traceability were largely designed before co-design became a mainstream practice.

The practical result is that traceability in co-design programs is often maintained in spreadsheets that someone updates manually, disconnected from both the hardware design tool chain and the software development environment. This is not a criticism of the engineers involved; it is a process gap that the tool ecosystem has not solved.

Several approaches are gaining traction among teams that are getting ahead of this problem.

Graph-based requirements models instead of document hierarchies. Traditional requirements management tools structure requirements in hierarchical documents that mirror the V-model decomposition. Co-design requirements do not decompose cleanly into a tree—they form a graph, with cross-domain dependencies, multiple allocation targets, and interface nodes that belong to neither domain exclusively. Teams that are managing this well have moved to model-based representations that can express those relationships natively, rather than trying to force co-design structures into document hierarchies.

Explicit architectural decision records (ADRs) for allocation decisions. Borrowed from software architecture practice, ADRs capture not just what was decided—function X is allocated to FPGA—but why, what alternatives were considered, and what constraints would prompt revisiting the decision. When a hardware ECO or a software requirement change comes in, engineers can evaluate it against the recorded rationale rather than reconstructing the reasoning from scratch.

Cross-domain impact analysis integrated into change management. Some teams are building structured change impact workflows that require hardware ECOs to include a software/firmware impact assessment before they can be approved. This is process discipline, not tool dependency, but it has to be built into whatever workflow system the team uses.

Tools like Flow Engineering are beginning to address the gap from the requirements side. Flow Engineering’s graph-based model allows requirements, architectural decisions, interface specifications, and test evidence to be linked in a connected structure rather than maintained as separate document artifacts. In co-design contexts, that means an allocation decision—FPGA handles pre-processing, CPU handles classification—can be expressed as an explicit node in the model, with links to the requirements it satisfies, the interface specifications it generates, and the verification activities that confirm it. When the allocation changes, the impact is visible in the graph rather than discovered through a change review process that depends on someone remembering all the connections.

The limitation worth naming: tools like Flow Engineering are requirements and architecture management environments. They do not integrate with EDA tool chains, and they do not replace hardware simulation or software CI pipelines. The traceability they provide covers the systems engineering layer; the implementation verification still lives in domain-specific tools. The gap between the two is smaller than it was, but it has not been closed by any current commercial tool.

The Organizational Dimension

Tooling and process changes are necessary but not sufficient. The organizational structure of most hardware and software development teams was designed for separation, not integration. Hardware teams optimize for tape-out and bring-up milestones. Software teams optimize for sprint velocity and release cadence. Systems engineers sit between them and are often under-resourced relative to the integration complexity they are being asked to manage.

Co-design programs that work well share a common feature: the systems engineering function has explicit authority over allocation decisions, not just advisory responsibility. When the hardware team wants to move a function from FPGA to software to save gate count, the systems engineer has standing to evaluate the cross-domain impact and, if necessary, block the change pending a full analysis. When the software team wants to change an assumption about DMA behavior to simplify a driver, the systems engineer has standing to require a hardware impact assessment.

That authority is organizational and cultural, not just procedural. It requires management commitment to fund the systems engineering function adequately and to give systems engineers real decision-making power in the architecture process—not just the responsibility of maintaining the documentation after decisions have already been made elsewhere.

Honest Assessment

Hardware-software co-design is not a new practice. What is new is its scope. The number of embedded systems programs where the hardware-software boundary is fluid enough to create real engineering risk has expanded dramatically in the last five years, and the systems engineering processes and tools that most teams use have not kept pace.

The teams that are managing this well are not using a single tool or a single process innovation. They are combining graph-based requirements models, explicit allocation decision records, cross-domain change impact workflows, and organizational structures that give systems engineering real authority. None of these individually is sufficient. Together, they represent a practice that is meaningfully ahead of the field average.

The teams that are struggling are largely trying to manage co-design complexity with document-centric requirements tools, manually maintained RTMs, and informal coordination between hardware and software engineering leads. That works until it doesn’t, and when it fails in a co-design program, it tends to fail expensively and late.

The practical question for systems engineering leaders is not whether to address this—the convergence of hardware and software timelines is not going to reverse. The question is whether to build the processes and tooling infrastructure now, during a period of relative stability, or to discover the gaps during a program integration that has no slack.