The Rise of Hardware-Software Co-Design and What It Means for Systems Engineering

For most of the last four decades, hardware and software engineering operated on a predictable rhythm: hardware teams defined the platform, documented its interfaces, handed off specifications, and software teams built on top of what they received. The rhythm was slow, sometimes frustrating, but it was legible. Everyone understood where their domain ended.

That rhythm is breaking down. Not gradually—abruptly, across multiple industries at once. The drivers are well-documented in the technical press: custom silicon for AI inference, FPGA-based compute fabrics that blur programmability and logic, neuromorphic hardware that has no clean software analog, and software-defined architectures where “hardware configuration” and “software configuration” are the same thing. What the technical press covers less thoroughly is what this means operationally for systems engineering teams who have to manage requirements, traceability, and integration in an environment where the old domain boundaries no longer hold.

This article covers that operational reality: why the co-design trend is structurally different from previous hardware-software integration challenges, what it specifically breaks in traditional systems engineering practice, and what teams are doing—and what tools are enabling—to keep engineering coherent when the disciplines merge.

What’s Actually Driving Co-Design

It’s worth being precise about the drivers, because they’re not all the same phenomenon.

FPGA-based compute is the oldest member of this group, but its role has changed. FPGAs were once niche accelerators tucked into specific subsystems. Now they are primary compute fabrics in data center inference cards, radar signal processing chains, and automotive perception pipelines. The distinction between “what the FPGA does” and “what the software does” is a design decision made mid-project, not a fixed boundary. Teams designing with Xilinx Versal or Intel Agilex aren’t deciding between hardware and software—they’re partitioning a unified workload across programmable logic, hard processors, and AI engines simultaneously. Requirements that say “the system shall process 200 frames per second” don’t belong to the FPGA team or the software team. They belong to both, jointly, with the partition decided iteratively.

Edge AI chips—whether custom ASICs like Apple’s Neural Engine, merchant silicon like Qualcomm’s Hexagon, or open designs built on RISC-V with accelerator extensions—bring a different challenge. The hardware is fixed post-fabrication, but its effective behavior is controlled by model quantization, compiler targeting, and runtime scheduling decisions that live entirely in software. A latency requirement depends on the hardware architecture. The hardware architecture was shaped by expected model characteristics. The model is trained to fit the hardware constraints. This is a closed loop, and systems engineering tools built for open-loop handoff processes are not designed to manage it.

Neuromorphic hardware is the extreme case. Chips like Intel’s Hala Point or research systems based on spiking neural network (SNN) architectures don’t execute conventional software. They run event-driven computation on hardware that mimics biological neural structure. Writing requirements for a neuromorphic system—and then tracing those requirements to a verification strategy—requires that the requirements engineer understand both the compute model and the neuroscience it approximates. No amount of interface documentation between “hardware team” and “software team” makes that work. The people writing requirements and the people designing the hardware substrate need to be in continuous conversation.

Software-defined systems are perhaps the most commercially consequential driver. Software-defined vehicles (SDVs), software-defined radios, and software-defined networking hardware share a common characteristic: physical capabilities that were previously fixed at manufacturing time are now configurable at runtime through software updates. This creates requirements volatility that hardware-first development cannot absorb. If the brake system’s behavior can be updated over-the-air, the safety requirements that drove the hardware design need to be traceable all the way through the software update pipeline—or the certification argument falls apart.

What This Breaks in Traditional Systems Engineering

Traditional systems engineering practice isn’t wrong about its goals. The V-model, interface control documents (ICDs), hardware requirements specifications (HRS), software requirements specifications (SRS), and allocated baselined requirements—all of these exist because someone solved real integration problems by creating structured documentation. The problem isn’t the intent; it’s that the structures assume a cleaner domain partition than co-design allows.

Interface management breaks first. ICDs are designed to capture the boundary between two stable subsystems. When hardware and software are co-designed, interfaces move. The API between a DMA engine and its driver changes when you optimize the hardware pipeline. The memory map shifts when you add a new accelerator register. In a traditional workflow, each change triggers an ICD revision, an impact assessment, and a requirements change request. In a co-design workflow running at modern velocity, this process creates more latency than the team can absorb. ICDs become stale faster than they can be updated, and engineers stop trusting them.

Domain-siloed requirements tools compound the problem. The standard enterprise toolchain still routes hardware requirements through one system and software requirements through another, with manual synchronization at defined integration milestones. When requirements span both domains—which in co-design they routinely do—this architecture forces artificial decomposition. A requirement that reads “the system shall achieve 95% detection accuracy at 30ms latency” gets decomposed into a hardware performance budget and a software algorithm budget, but the decomposition is a model of the requirement, not the requirement itself. The original system-level intent becomes invisible in the tool, and verification coverage maps to the decomposed children rather than the parent. Integration testing then surfaces gaps that were predictable had the connection remained visible.

Traceability loses coherence. In single-domain workflows, traceability is linear enough that it can be managed in spreadsheet-format RTMs or flat link tables in a requirements tool. In co-design, traceability needs to represent a graph: a system requirement may allocate partially to an FPGA configuration, partially to a software scheduler, and partially to a trained model artifact, all of which interact to produce the verified behavior. Flat traceability matrices cannot represent this structure without becoming unmaintainably complex. And when they become unmaintainably complex, engineers simplify them by dropping links—which defeats the purpose.

Verification strategy becomes incoherent. When you don’t know at requirements-authoring time whether a behavior will be implemented in logic, firmware, or a machine learning model, you cannot write a verification method in the traditional sense. “Test by analysis” presupposes what you’re analyzing. “Test by demonstration” requires a stable implementation to demonstrate against. Co-design teams are increasingly running hardware-software co-simulation, in-the-loop testing, and model-based verification simultaneously, and the requirements tool needs to support multiple verification approaches against a single requirement—not force a single method selection at authoring time.

How Teams Are Responding

The most effective response isn’t organizational restructuring for its own sake, though many co-design teams do eliminate the formal hardware/software boundary in favor of integrated system pods. The structural response that actually changes engineering outcomes is adopting a unified requirements and architecture layer that treats hardware and software as nodes in the same model.

This means requirements that live in a single system, not synchronized between two. It means architecture models where a requirement can allocate to a hardware block, a software module, or a hybrid element without changing tools or crossing a process boundary. It means traceability that is inherently graph-structured—so that when a hardware partition changes, all dependent software requirements are immediately visible as affected, without a manual impact assessment pass.

Model-based systems engineering (MBSE) platforms have been pushing in this direction for years. SysML-based tools like Cameo or Rhapsody can represent hardware and software in a unified model, and when used rigorously, they support exactly the kind of allocation traceability that co-design requires. The limitation is implementation friction: SysML models in large teams require significant discipline to keep synchronized with actual design artifacts, and the toolchain integrations to connect a SysML model to an FPGA synthesis tool, a software CI/CD pipeline, and a machine learning training run are non-trivial to build and maintain.

The more recent development is AI-native requirements platforms that treat requirements as structured data in a connected graph rather than documents with links appended afterward. Flow Engineering is the clearest example of this approach applied specifically to hardware and systems engineering teams. Rather than starting with document templates that get linked together, Flow Engineering structures requirements as nodes in a graph where relationships—allocation, derivation, verification coverage, interface dependency—are first-class objects. For co-design teams, this means a system-level performance requirement can maintain live connections to its hardware allocation, its software allocation, its verification tests, and its simulation results simultaneously, and any change to any node propagates visibility of impact through the graph immediately.

The practical advantage in a co-design context is that the tool’s structure doesn’t force the artificial decomposition that siloed tools require. A requirement can exist at whatever level of hardware-software abstraction is honest, and it can be allocated to multiple implementation domains without losing its identity. When the FPGA partition changes, the affected software requirements don’t need to be found through a manual search—they’re directly connected in the graph. This is not a feature add; it’s a consequence of building the data model correctly from the start.

Flow Engineering’s current focus is on requirements and traceability rather than full MBSE modeling, which means teams still need to integrate with architecture tools for detailed hardware-software partitioning work. For organizations that need deep SysML modeling, this is a real consideration. But for the large category of teams whose primary pain is requirements coherence and traceability across domain boundaries—rather than formal model-based design—the focused scope is a genuine advantage: less configuration overhead, faster onboarding, and a graph-based foundation that can grow with the architecture.

The Honest Assessment

Hardware-software co-design is not a trend that systems engineering practice can wait out. Edge AI shipments are measured in billions of units annually. Automotive OEMs are committed to software-defined vehicle architectures. Defense and aerospace programs are incorporating FPGA-based reconfigurable computing as standard platform components. The organizational and toolchain structures that worked when hardware and software were sequentially developed will not survive contact with these programs at scale.

The transition required is not subtle. It is not “add more integration reviews” or “improve communication between teams.” It is a structural change in how requirements are authored, allocated, and traced—from domain-siloed documents with links to unified graph-structured models where hardware and software elements are peers in the same engineering representation.

Teams that make this transition earlier are discovering a non-obvious benefit: the integrated model makes co-design trade studies faster, not slower. When you can change a hardware partition and immediately see which software requirements are affected, you can explore the design space more aggressively than teams that have to run a manual impact assessment before each design iteration.

The tooling exists to support this. The process understanding exists. What remains is the institutional willingness to treat the hardware-software boundary as what co-design has made it: a design variable, not a fixed organizational boundary—and to engineer the requirements and traceability infrastructure accordingly.