How Semiconductor Complexity Is Driving Systems Engineering Upstream

The phrase “the chip is the system” gets used loosely. But in 2026, it’s increasingly accurate in ways that matter operationally. A flagship mobile SoC today embeds a CPU complex, GPU, NPU, ISP, DSP, cellular modem, Wi-Fi subsystem, security enclave, multiple voltage and power domains, and a real-time OS interface — all on a single die or chiplet assembly. An automotive microcontroller for ADAS contains safety islands, hardware security modules, lockstep cores, and functional safety mechanisms that must be traceable to ISO 26262 decomposition requirements.

These are not chips with some extra features. They are distributed systems that happen to be implemented in silicon. And that distinction is creating a structural problem: the people building them have been trained, tooled, and process-optimized for chip design, not systems engineering.

That gap is closing — not because the industry has decided systems engineering is philosophically appealing, but because the economics of getting it wrong have become intolerable.

What’s Actually Changing Inside Chip Programs

The traditional chip design flow has a clear logic. Marketing defines features. Architecture writes a spec in a document or a wiki. RTL designers implement it. Verification engineers test it. When something doesn’t work, you debug it. The process is inherently document-driven and implicitly assumes the specification is stable and coherent — assumptions that held reasonably well when a chip’s primary interface was a bus protocol and a data sheet.

Neither assumption holds for today’s SoC.

Hardware/software boundaries are negotiable and frequently renegotiated. A hardware accelerator that turned out to be over-specified can have some of its functionality pushed back to firmware. A security feature that was assumed to live in software can be pulled into a hardware root-of-trust engine. These decisions happen continuously during architecture, but their downstream effects — on power, area, timing, verification scope, software deliverables — propagate in ways that are nearly impossible to track with documents.

Safety and security requirements carry mandatory traceability obligations. ISO 26262 for automotive functional safety, ISO/SAE 21434 for cybersecurity, and IEC 62443 for industrial security all require formal decomposition of requirements from system level to component level, with documented rationale and verification evidence. A fabless company that wants to sell automotive-grade silicon now must produce this evidence or have its tier-1 customer produce it — a situation that reveals process gaps quickly.

Chiplet architectures create multi-party integration risk. When a chip program assembles compute tiles from one source, memory interfaces from another, and I/O PHYs from a third — all on an advanced packaging substrate — the system-level interface specifications become contractual documents. Misaligned requirements between chiplet suppliers and integrators have already caused expensive respins. This is the same failure mode that produced DO-178C and the MBSE movement in aerospace, just with a different part number on the box.

AI and ML workloads have dynamic performance requirements that resist static specification. An NPU that performs acceptably on one inference topology may throttle badly on another due to memory bandwidth contention or thermal limits. Characterizing what “meets requirements” means in this context requires formal requirements that can flex — not a number in a spreadsheet that was correct when the model was defined but is now outdated.

The HW/SW Co-Design Requirements Problem

The most acute pressure point is HW/SW co-design. The concept has existed for decades; the requirement to manage it formally is new.

In a classical SoC program, HW and SW specifications are maintained in separate documents by separate teams. The hardware architecture document describes register maps, interrupt routing, memory-mapped interfaces, and performance envelopes. The software requirements specification (or SDK documentation) describes what the OS, drivers, and firmware are expected to do with those interfaces. These documents are written at different times, by different people, in different tools, often with no formal link between them.

The problem is not that the teams don’t communicate. It’s that the communication is informal, the decisions are undocumented, and when something goes wrong at system integration — which is late, expensive, and on the critical path — nobody can efficiently trace the failure back to its origin.

Modern approaches to HW/SW co-design requirements management are beginning to borrow from model-based systems engineering (MBSE). Rather than maintaining two separate document trees, requirements are structured in a shared model that makes the interface between hardware and software explicit. A requirement that says “the security engine shall process authentication tokens within 500 microseconds under peak load” can be allocated simultaneously to the hardware performance specification and the firmware scheduling specification, with a traceable link between them. When the hardware team changes the architecture to reduce area and the latency budget shifts, the link makes the impact visible rather than invisible.

This is not a new idea. It’s how Airbus manages requirements for avionics. It’s how NASA decomposes mission requirements down to component level. Semiconductor teams are arriving at the same conclusion through a different path: not regulatory mandate (though that’s coming), but the operational cost of late discovery.

The EDA Integration Problem

The chip industry has a toolchain that is extraordinarily mature and deeply siloed. Cadence, Synopsys, and Mentor have built comprehensive environments for RTL development, simulation, synthesis, place-and-route, and verification. These tools are excellent at what they do and represent decades of accumulated capability. They are not, and were not designed to be, systems engineering platforms.

The gap shows up in specific ways:

Formal requirements do not exist natively in EDA flows. A requirement in a Cadence Virtuoso environment is a comment in a schematic or a line in a spec document. It is not a structured entity with properties, verification status, and traceability links. When a verification engineer closes a simulation, there is no automatic mechanism that marks a requirement as verified and records the evidence. That connection, if it exists at all, is maintained manually in a spreadsheet.

Verification plans are not directly linked to requirements. The industry-standard Universal Verification Methodology (UVM) is sophisticated, but it operates at the testbench level. The connection between a UVM test and the requirement it’s intended to verify is, in most organizations, documented in a separate tool — or not at all. This is why requirement coverage reporting for chip programs often requires someone to manually compile a compliance matrix at the end of the project.

IP integration lacks a requirements layer. Semiconductor IP blocks are delivered with data sheets, verification reports, and application notes. They are not delivered with structured requirements that can be imported into a system-level requirements model. Every team that integrates third-party IP must either reverse-engineer the requirements from the data sheet or operate without them — which means the traceability chain breaks at the IP boundary.

Bridging EDA flows and systems engineering tools requires integration that most organizations are building point-by-point. Some teams are using Python scripts to extract simulation pass/fail data and feed it into requirements management platforms. Others are maintaining manual trace matrices. A few are implementing formal MBSE flows using SysML-based tools, then handing off to EDA through interface control documents. None of these approaches is elegant; all of them require ongoing maintenance effort.

What Modern Tooling Looks Like When It’s Done Well

The tools that are beginning to address this problem share a few characteristics. They treat requirements as structured data rather than document text. They model the system — including the boundary between hardware and software — in a way that makes allocations and dependencies explicit. And they are built to produce traceability evidence as a byproduct of normal engineering work, not as a post-hoc documentation effort.

Flow Engineering, built specifically for hardware and systems engineering teams, takes a graph-based approach to requirements and system models. Rather than organizing requirements in a document hierarchy, it models them as nodes in a connected graph with explicit relationships — allocation, derivation, verification — that can span the hardware/software boundary. For semiconductor programs dealing with HW/SW co-design complexity, this means a performance requirement at the SoC level can be directly linked to the hardware block that implements it, the firmware requirement that depends on it, and the verification test that covers it — without those relationships living in three separate tools with no automated connection.

This approach is particularly valuable for chiplet-based programs, where system-level interface requirements need to be shared across multiple design teams. A graph model can represent a multi-party requirement — say, a PCIe subsystem performance floor that constrains both the host controller tile and the endpoint IP — in a way that makes each team’s obligations visible without requiring a document handoff.

The deliberate trade-off is depth within the EDA flow itself. Flow Engineering integrates with EDA environments through data interfaces rather than replacing them. Teams working heavily within Cadence Xcelium or Synopsys VCS verification environments will still need to manage the connection between simulation results and requirements through an integration layer. This is a real limitation for programs where deep EDA integration is a hard requirement — but it reflects a principled choice to build a genuinely capable systems engineering platform rather than a thin wrapper around an EDA tool.

IBM DOORS Next and Polarion remain capable options for teams in regulated markets that need enterprise-grade change management, formal review workflows, and established integrations with safety analysis tools like FMEA platforms. Their document-centric architectures create friction for graph-based system modeling, but they carry significant installed-base momentum and regulatory acceptance in aerospace and automotive. Jama Connect offers strong review and approval workflow management and has built out its systems engineering capabilities, though it is less native to the structural complexity that chiplet-based programs generate.

The honest picture is that no single tool currently spans the full chain from system-level requirements through EDA verification with native, seamless integration. The market is in transition.

Practical Implications for Engineering Process

For chip programs adopting systems-level thinking, the process implications are significant and underappreciated:

Architecture review needs a requirements baseline. The architecture review process in most chip programs reviews feasibility, area estimates, and design risk. It does not review requirement completeness, allocation coverage, or traceability. Adding a requirements audit to architecture review — even informally — catches misalignment between hardware and software scope before RTL is committed.

Verification plans should be derived from requirements, not parallel to them. The standard practice of writing a verification plan alongside a specification, with a manual trace matrix linking them, should be replaced by direct derivation. If verification objectives are generated from requirement nodes rather than from documents, coverage reporting becomes automatic rather than compiled.

IP procurement should include requirements evidence. Fabless companies evaluating third-party IP should add requirements deliverables to the procurement checklist. A data sheet is not a requirements specification. Structured requirements from an IP supplier are the starting point for system-level traceability, not a nice-to-have.

HW/SW interface specifications need mutual ownership. The interface between a hardware block and its firmware driver should be owned by a requirements entity that both teams commit to — not by whichever team writes the spec first and whichever team reads it later. This is an organizational change more than a tooling change, but the tooling makes it sustainable.

Honest Assessment

The semiconductor industry is not going to adopt MBSE wholesale because systems engineers think it’s a good idea. It will adopt enough of it to solve the problems that are actually costing money: late integration failures, traceability evidence gaps for regulated customers, HW/SW misalignment that surfaces at bring-up, and chiplet interface disputes that require a respin to resolve.

The adoption will be pragmatic and incomplete. Teams will pick the methods and tools that solve their specific pain, not the ones that implement a textbook framework. That means the toolchain will remain heterogeneous, the integrations will remain custom, and the process will vary by company and by program.

What won’t vary is the direction of travel. As chips become more complex, as safety and security obligations grow, and as chiplet assembly creates multi-party integration dependencies, the case for formal requirements management upstream of RTL becomes stronger. The teams that build that capability now will have a process advantage when their first automotive customer or first chiplet partner asks for traceability evidence they can actually produce.

The others will be compiling that spreadsheet the week before tapeout.