Architecture automation is frequently described as a path from requirements to a new chip. That description collapses several distinct problems. Selecting cache capacity, issue width, queue depth, and accelerator dimensions is a search problem. Producing legal RTL is an implementation problem. Preserving ISA and system behavior is a validation problem. Showing that a result matters after place and route is an evidence problem.
The 2025 literature is strongest when these boundaries remain visible. QiMeng-CPU-v2 constructs and validates a superscalar RISC-V processor through an automated state-based design process[1]. LEMOE uses language-model assistance inside multi-objective Bayesian optimization for BOOM microarchitecture exploration[2]. An ICCAD system combines textual parameter meaning with graph features extracted from Chisel-generated RTL for SoC design-space exploration[3]. These systems do not automate the same layer, but together they reveal the useful role of AI: compress a large decision space while keeping an executable contract at the center.
Architecture is a sequence of commitments
An early architectural choice appears cheap because it is written as a parameter. Increasing issue width from two to four, however, changes wakeup and selection, register-file ports, bypass paths, queue pressure, and physical wiring. A larger cache changes miss rate and also access latency, banking, coherence traffic, and floorplan. The visible knob is only the first commitment in a chain.
Conventional design-space exploration handles this by choosing a parameterized template, evaluating samples, and building a surrogate model. The method is effective when the template already contains the right architecture and the unknown is which configuration to select. It is less effective when the important decision changes topology, control semantics, or the workload contract. AI can propose those changes, but then the evaluator must become deeper.
The evidence gates are therefore cumulative. A PPA estimate filters obviously poor candidates. Generated RTL shows that the choice can be expressed. ISA tests and long-running programs expose behavioral defects. FPGA or silicon implementation reveals timing, power, and integration effects. A proposal that has crossed only the first gate remains a search result, not a processor.
QiMeng-CPU-v2 searches states that produce a machine
QiMeng-CPU-v2 is notable because its target is not a collection of isolated RTL exercises. The framework assembles a four-ALU superscalar RISC-V CPU and reports execution of more than one trillion instructions in real programs, along with FPGA validation[1]. Its State-Based Design method separates a state selector, which uses simulated annealing, from a state speculator that expands the design with language-model assistance.
The state formulation is an important editorial clue. A CPU is a temporal system. Instructions enter queues, wait for operands, compete for resources, commit in order, and recover after exceptional events. Organizing generation around machine state gives the automation a vocabulary for these transitions. It also makes failures easier to localize than a single prompt that asks for a processor.
The paper compares the resulting processor with earlier automated designs and places its capability near an Arm Cortex-A53-class reference. That comparison describes an architectural level, not process-node parity or product readiness. Frequency, memory system, compiler, physical implementation, and workload conditions determine whether two CPUs deliver comparable system performance. The stronger contribution is that an automated flow produced an executable out-of-order design with a long behavioral test history.
Even the trillion-instruction statement needs the right interpretation. It expands confidence that the implementation survives real execution and rare interactions. It does not enumerate every architectural corner or prove equivalence to a golden model. Interrupt timing, memory ordering, privileged behavior, debug, coherency, and low-power state transitions can contain defects that ordinary workloads rarely trigger. The next step is to connect generated state transitions to formal ISA properties and coverage goals.
LEMOE automates selection inside a known CPU family
LEMOE addresses a narrower but commercially familiar problem: choose a strong BOOM configuration under multiple objectives[2]. Bayesian optimization normally builds a surrogate from expensive evaluations and selects the next sample by an acquisition rule. Language-model assistance can inject knowledge about parameter relationships, explain prior observations, or guide the search toward more plausible regions.
This boundary is useful because BOOM already supplies a coherent out-of-order RISC-V implementation. The search system does not need to invent retirement semantics or a cache coherence protocol. It decides among parameters whose consequences can be measured with IPC and power models. That turns architecture automation into a constrained optimization service.
The limitation follows from the same strength. A good BOOM configuration is not a new processor organization. The result can reveal unexpected parameter combinations and reduce evaluation cost, but the design family, RTL generator, and measurement harness define the space. If an application needs a different dataflow, memory consistency model, or accelerator coupling, the correct answer may not exist inside that template.
An architecture team should therefore ask two questions before adopting a search result. First, does the template contain the decision that differentiates the product? Second, does the evaluator include the workload and physical effects that make that decision valuable? If either answer is no, faster search can converge precisely on the wrong boundary.
Multimodal SoC DSE connects names to structure
The ICCAD multimodal system adds another missing signal. It encodes semantic information from parameter descriptions with an LLM and structural information from RTL graphs produced through Chisel, then fuses the features for performance prediction and Bayesian exploration[3]. The evaluation uses a Gemmini-based RISC-V SoC.
Text and structure answer different questions. The name and description of a parameter may indicate that it controls a scratchpad bank, a queue, or an array dimension. The RTL graph shows how that choice changes connectivity and logic. A model that uses only numeric parameter values treats two unrelated knobs as similar if their ranges match. A model that uses only structure may miss why a change is meaningful to the architecture. Fusion can reduce that ambiguity.
This approach is closer to how an engineer reads a generator. A parameter is not merely an integer; it carries intent and produces a structural consequence. The useful outcome is better sample efficiency on new configurations, not natural-language creativity. The system still depends on the generator to produce legal implementations and on the evaluator to represent the desired SoC behavior.
No single metric represents an architecture
IPC is meaningful only with a workload, compiler, memory model, and clock assumption. Power requires activity, voltage, technology, and physical implementation. Area estimates can reverse after wiring and buffering. A composite reward may simplify optimization, but it does not remove these denominators. It merely hides them behind weights.
A better evaluation preserves a vector of outcomes. Throughput, tail latency, energy, area, memory traffic, and implementation risk should remain visible. Constraints define unacceptable regions, while product priorities rank the feasible set. This lets engineers see when an automated design wins by spending a resource the system cannot afford.
Workload selection is equally important. An average benchmark score may favor wider execution while a target service is limited by memory latency or synchronization. Training on one suite can also reward changes that exploit its instruction mix. Architecture automation needs scenario coverage: compute-bound, cache-capacity, bandwidth, branch, OS, and interference cases. The search result should expose which scenario created each trade-off.
The missing industry evidence is itself informative
The public 2025 record contains impressive academic CPU and SoC exploration, including industry participation in some tools. It contains less evidence of an industry-owned flow automatically changing a production microarchitecture and carrying the result through signoff or silicon. Vendor product claims and white papers often describe AI-assisted design, but they do not provide the experimental detail needed for an independent technical comparison.
This gap should not be filled with marketing inference. Physical design automation has clearer industrial evidence because timing, congestion, and routed quality can be compared against established tools on real layouts. Architecture value appears later and depends on software, workloads, and product decisions that companies rarely disclose. The slower publication path reflects the difficulty of the evidence, not an absence of internal use.
The practical implication is that architecture AI should be introduced first where the contract already exists. Parameterized cores, accelerator array sizing, cache hierarchy options, and interconnect settings offer measurable spaces. Free-form invention of a new organization needs a much stronger validation stack and a human owner for the resulting system contract.
A deployable architecture agent needs memory of causality
Search logs should record more than configuration and score. They should preserve why a parameter was changed, which workload moved, which physical constraint became active, and whether the result transferred across seeds and implementations. This creates reusable architectural knowledge instead of a pile of samples.
Counterfactual experiments are especially valuable. If a larger reorder buffer improves IPC, the system should test whether the gain comes from memory-level parallelism, branch recovery, or benchmark phase behavior. A change that helps for the wrong reason may fail after another subsystem is updated. Causal probes can be simple, such as holding memory latency constant or swapping workloads, but they make the recommendation reviewable.
The agent also needs the ability to decline. A predictor should report when a candidate lies outside its training distribution, when uncertainty is high, or when the generator cannot represent the requested change. Returning no recommendation is better than optimizing a surrogate beyond its credible range.
The adoption decision
AI architecture tools are ready to compress bounded design spaces and organize evidence. They can propose samples, use parameter meaning, learn structural features, and help maintain a Pareto frontier. QiMeng-CPU-v2 also shows that a more generative workflow can reach a running superscalar processor when state and validation are explicit.
The authority boundary should remain clear. Engineers define the architectural contract, workloads, constraints, and evidence gates. The automation explores candidates and explains the observed trade-offs. A candidate becomes an architecture only after its behavior is executable and its system consequences survive implementation.
That is not a modest role. Design teams spend enormous effort deciding which experiments deserve a full run. A system that rejects weak regions, carries insight from one configuration to another, and presents causal evidence can shorten the architecture cycle. The value comes from reducing uncertainty before expensive commitment, not from claiming that a language model designed the chip alone.
Source and copyright notice
This article is an independent editorial analysis of the three cited papers and their official publication records. We restated technical claims in our own words and did not reproduce source text, tables, benchmark layouts, or figures. Both explanatory figures were created specifically for this article. The cited papers are copyright their respective publishers and authors.