The spread of artificial intelligence has not changed a basic fact in the semiconductor industry: hardware and software development still generally proceed along separate tracks. An analysis published by Semiconductor Engineering on September 15, 2026, argues that the benefits of co-designing the two have been known for years, but implementing it on a wide scale continues to encounter organizational and technical obstacles that AI has not yet resolved.
The problem begins with the structure of the teams themselves. Hardware and software engineers use different tools and languages, and work according to asynchronous schedules and development rhythms. In the traditional model, the design reaches chip-production stage before software teams take over to adapt the system to it, including handling changes and known errors called errata. Sam Grove, head of software and tools at MIPS/GlobalFoundries, describes this situation as a late handoff that leaves the software team under pressure to operate the product instead of participating in the design of the next generation.
The Gap Is Not Merely Organizational
Even when companies try to implement continuous integration, the speed of obtaining a reliable result remains a central obstacle. Frank Schirrmeister, executive director of strategic programs for system solutions at Synopsys, points out that moving from specifications to a hardware and software model can become very fast, provided the system can be simulated quickly enough.
Virtual prototypes, simulation, emulation tools, and FPGA-based models exist, but each option involves different trade-offs among accuracy, performance, and execution time. A virtual model may help test the impact of software on the architecture early, while simulation or more detailed modeling provides better visibility into performance and power. However, running a complete workload representative of the final product remains much harder than testing a small function or a synthetic workload.
The difficulty increases when teams want to run the same workload across multiple stages, from the virtual platform to emulation, then to an FPGA-based model, and finally to silicon. Testing ten seconds of the chip's runtime may not be practical in simulation, requiring the teams to determine which portion can be executed at each stage rather than assuming that a single model will cover all uses.
Shared Specifications Are a Prerequisite for AI
Experts believe the first requirement is to create rich, integrated specifications that engineers and AI agents can use together. According to the article, only limited sectors do this today, including the military and aerospace industries to a greater extent. Without this type of specification, AI lacks a unified reference linking system requirements with RTL design, software, and verification results.
Synthetic experiments may help measure execution time and power consumption for software functions across a range of architectures, but this step alone is not enough to make a design decision. Engineers also balance flexibility and performance, cost and size, the power budget, heat, and environmental factors. Arvind Srinivasan, a verification solutions engineer at Normal Computing, says that one of the highest-performing designs may be fully customized for the task, while there is still no standardized way to encode all these constraints so that an AI algorithm can use them as optimizable objectives.
What Can AI Do Now?
Current uses are more limited than the idea that AI will design the entire system. Andy Meier, principal product marketing manager at Siemens EDA, says customers mainly use it to create RTL and test environments, but he does not see it being used on a comparable scale for architectural decisions. This is because such decisions require broad knowledge of the trade-offs among performance, power, cost, and workload behavior.
By contrast, MIPS/GlobalFoundries uses AI agents to write software and hardware for specific tasks, while emphasizing the importance of understanding the tool's limitations and errors. Steve Roddy, chief marketing officer at Quadric, also notes that software may change many times between the construction of the design model and the arrival of silicon, whether because of developers or AI assistants. This means that co-design is not a decision made once at the beginning of a project, but a process that must continuously handle changes in software.
Normal Computing proposes the possibility of using AI to extract more abstract representations of hardware, allowing software developers to work before RTL is complete. This concept is based on having a representation of the specifications, or an ontology, that can serve as a shared reference, but it does not eliminate the need to link this representation to later models and verify that they match.
Verification and Collaboration Are the Bottleneck
The analysis confirms that progress is likely to be gradual because completely replacing existing methodologies increases project risks. Srinivasan points out that EDA tools still address small parts of the problem rather than improving the overall outcome, and that black boxes require guarantees of correctness, auditability, and a unified record showing the relationships among design elements and verification results.
Synchronization among models remains a practical challenge. A timing-abstract, untimed high-level model in SystemC is not equivalent to RTL in terms of temporal accuracy, and keeping the two consistent consumes considerable time in verification, validation, and software bring-up. Therefore, providing a virtual model is not enough; what is needed is an interconnected chain of simulation and analysis models, along with knowledge transfer among design, applications, and customer-support teams.
From certi.news's perspective, the actual change is not the launch of a single tool or the industry's immediate transition to AI-driven autonomous design. The change is that software has begun influencing the definition of the architecture before the chip is complete, while EDA tools are attempting to connect stages that were previously separate. However, the source does not provide evidence that this problem has been solved; rather, it shows that the lack of unified specifications, the cost of simulation, changing software, and the need for auditability remain fundamental constraints. Human expertise will therefore remain decisive in architectural decisions, while AI's impact will focus on specific tasks whose results can be tested and reviewed.