Why Hardware-Software Co-Design is Becoming the Central Systems Engineering Challenge

The partition used to be clean. Hardware engineers wrote requirements for circuits. Software engineers wrote requirements for code. A well-defined interface specification sat between them, and systems engineers spent their careers managing that interface. That model worked well enough when the boundary between hardware and software was physically stable—when a function implemented in silicon stayed in silicon.

That boundary is now a design variable.

Across aerospace, automotive, telecommunications, and defense, engineers are making explicit decisions about whether a given function lives in programmable logic, in a software process running on a general-purpose processor, or in some reconfigurable arrangement that can shift between the two over a product’s lifetime. FPGAs have made this tradeoff routine. Software-defined radios have collapsed entire signal processing chains into software that previously required dedicated ASICs. Neural processing units running ML inference pipelines are making algorithm-substrate co-optimization a standard activity. And the emergence of reconfigurable compute architectures—where the same silicon can present different functional profiles depending on configuration—means that “hardware requirement” and “software requirement” are increasingly labels that describe a current decision, not a permanent fact.

The systems engineering discipline has not fully caught up. The tools, processes, and organizational structures most teams use still assume that hardware and software are parallel tracks that merge at integration. This article examines what it actually means to practice systems engineering when that assumption fails.

What Hardware-Software Co-Design Actually Requires

Co-design is not a new concept. Embedded systems engineers have navigated hardware-software tradeoffs for decades. What is new is the scale of the design space, the frequency with which implementation decisions are revisited, and the degree to which those decisions are consequential for downstream verification and certification.

In a conventional development flow, a systems engineer allocates a performance requirement—say, a signal processing latency budget—to either hardware or software at some early stage, and that allocation is treated as relatively stable. The hardware team designs to it. The software team designs to it. Integration is where the two realizations meet.

In a co-design flow, the allocation itself is an engineering output, not an input. The question “should this filter run in the FPGA fabric or in the DSP software layer?” is answered by analysis, often iterative analysis that considers power, latency, reconfigurability, development cost, and certification burden simultaneously. That answer may change as the design matures. It may even be different for different deployment configurations of the same product.

This creates three specific systems engineering problems that conventional processes handle poorly.

First, requirements must carry allocation rationale, not just allocation. A requirement allocated to FPGA firmware is not equivalent to the same requirement allocated to embedded software, even if the functional specification is identical. The verification approach, the development assurance standards that apply, the change management implications, and the risk profile are all different. If the requirements database does not capture why an allocation was made—and what assumptions that allocation depends on—the database becomes unreliable the moment the design evolves.

Second, traceability must span the allocation boundary. In a document-centric process, hardware requirements and software requirements typically live in separate artifacts. The connection between a system-level performance requirement and its hardware and software sub-requirements is managed manually, often through link matrices that become stale immediately after they are created. In co-design contexts, the allocation boundary itself moves. A link matrix cannot represent that.

Third, verification closure cannot be achieved domain by domain. If a system’s behavior emerges from the interaction of programmable logic and software processes—and if the allocation between them can shift—then a verification strategy that qualifies the FPGA separately from the software and then declares integration complete is structurally inadequate. The integrated system behavior is what must be verified, and the verification must remain valid across the range of possible allocations.

Where the Verification Problem Gets Acute

The verification challenge is most visible in industries where both hardware and software carry formal development assurance obligations.

In civil aerospace, DO-254 governs the development of complex electronic hardware, and DO-178C governs airborne software. Both standards require rigorous traceability from requirements through implementation to test. When an avionics function migrates from an ASIC to an FPGA, it moves from a regime where DO-254 applies to one where DO-254 still applies—but with different tool qualification requirements and a different analysis burden. When that same function runs in software on a reconfigurable processor, DO-178C enters the picture. Systems engineering teams at major avionics integrators are now routinely maintaining parallel compliance artifacts for functions that could, depending on the final design decision, qualify under either standard.

This is not a pathological edge case. It is the normal operating condition for FPGA-heavy avionics development, and the process burden it creates is significant. Teams that manage this well have invested in requirements structures that explicitly model the allocation decision as a tracked artifact—not just the allocation outcome—and they maintain traceability graphs that connect system requirements to both the FPGA and software sub-requirement branches simultaneously, with the active branch flagged and the rationale for that selection preserved.

In defense electronics, the problem is compounded by the deliberate use of reconfigurability as a feature. Software-defined radios are not just convenient engineering choices; they are capability strategy. The ability to update a radio’s waveform in the field is operationally valuable. But it means the boundary between what is hardware-verified and what is software-verified is intentionally fluid. Programs operating under the Software Communication Architecture (SCA) and related DoD frameworks have developed allocation and verification practices that treat the hardware abstraction layer as the fixed point and allow the software waveform components to be independently qualified. That architecture works, but it required deliberate systems engineering investment to establish.

Automotive is approaching this problem from a different direction. The move toward zone-based electrical architectures and software-defined vehicles—where features like adaptive suspension calibration, battery management algorithms, and driver assistance functions are implemented in software running on central compute platforms rather than in dedicated ECU hardware—has compressed the hardware-software design space dramatically. ISO 26262 functional safety requirements must now be satisfied by software that runs on hardware not designed for a single function. The partitioning and freedom-from-interference analysis this requires is a systems engineering problem, not a hardware problem or a software problem in isolation.

Which Organizational Structures Are Working

Teams that handle co-design well tend to share a few structural characteristics that are worth naming explicitly.

They have engineers who can read both the hardware design and the software specification without a translation layer. This sounds obvious, but most engineering organizations are still structured around hardware and software as separate career tracks with separate review processes. Co-design requires engineers who treat programmable logic implementation and software implementation as two dialects of the same design language. These engineers are scarce, and growing them requires deliberate investment.

They manage requirements in a shared model, not in parallel document trees. When hardware requirements and software requirements are maintained in separate tools with periodic synchronization, the co-design problem—which is fundamentally about the relationship between those requirement sets—becomes invisible to the tooling. Graph-based requirements models, where system requirements, hardware sub-requirements, software sub-requirements, and their allocation rationale are all nodes in the same connected structure, make the allocation visible and navigable.

They treat the allocation decision as a versioned artifact. When an engineering team decides to move a function from FPGA to software—or considers doing so—that decision needs to be captured with the same rigor as a requirement change. What triggered the reconsideration? What verification work was completed against the previous allocation? What verification work must be redone under the new allocation? Teams that handle this informally, through email chains and meeting notes, consistently find that the institutional knowledge about why allocations were made evaporates as personnel turn over.

How Modern Tooling Is Responding

The requirements management tooling market is adapting, but unevenly. Established platforms like IBM DOORS Next, Jama Connect, and Polarion have broad integration ecosystems and mature change management workflows. They are effective at managing large, stable requirement sets. Their structural limitation in co-design contexts is that they organize requirements into modules and hierarchies that map well to document-centric processes—hardware specifications and software specifications as parallel artifacts—but handle the allocation relationship between those artifacts less elegantly. Linking is possible; first-class representation of the allocation decision as a tracked, reasoned artifact is harder.

Newer platforms built around graph-native requirement models handle this differently. Flow Engineering, for example, represents requirements and their relationships as a connected graph rather than a document hierarchy, which makes it structurally easier to represent the allocation of system requirements to either hardware or software sub-requirements as a navigable relationship rather than a cross-document link. In co-design contexts, where the allocation is itself a design output that needs to be reasoned about and tracked, that structural difference matters. Flow Engineering is also designed to support AI-assisted requirements analysis, which in co-design contexts can help surface inconsistencies between system-level requirements and sub-requirements across the allocation boundary—the kind of cross-domain consistency checking that is easy to miss when hardware and software requirements live in separate review processes.

The honest assessment of tooling in this space is that no platform has fully solved the co-design requirements problem. The challenge of representing “this requirement is currently allocated to FPGA firmware, but the allocation is contingent on timing analysis that is still in progress, and a software alternative has been partially specified” is not a standard use case for any major requirements tool. Teams doing sophisticated co-design work are typically extending their tooling with custom attributes and scripts, which works until it doesn’t—until the custom infrastructure becomes its own maintenance burden or breaks under process changes.

The Discipline Is Adapting, Slowly

Systems engineering as a discipline is structured around the idea that requirements flow down from system to subsystem to component, and that the system integrates subsystems that were developed to those requirements. Co-design does not break that flow, but it adds a loop: the allocation of requirements to implementation substrates is itself a systems engineering output that must be managed with the same rigor as the requirements themselves.

The industries furthest ahead—aerospace and defense—got there because their regulatory environments forced them to take allocation seriously. When moving a function from software to FPGA changes the applicable certification standard, you cannot afford to treat allocation as a detail. The automotive industry is arriving at similar rigor through functional safety requirements. Other industries will follow as reconfigurable compute becomes more prevalent.

What the discipline needs to develop, and what the better engineering teams are building now, is a requirements practice that treats “where is this implemented” as a first-class, tracked, reasoned attribute of every requirement—not an organizational convention, not a filing decision, not a metadata tag added at the end of the design process. That practice, more than any specific tool or process, is what separates teams that handle co-design effectively from those that discover the allocation problem at integration.

The hardware-software boundary is not disappearing. It is becoming a variable. Systems engineering needs to treat it as one.