AI-designed silicon: Redefining the route from workload to accelerator
The development of specialised AI hardware has traditionally been a lengthy, sequential process. Architecture is defined, hardware is designed, verification follows, software is developed around the resulting implementation, and successive iterations are tested before a chip can eventually reach production. Architect Labs is proposing a substantially different model, in which artificial intelligence is used to connect these stages into a single optimisation process.
By Redwoor architech Labs
The company has unveiled Redwood, an AI accelerator that it says was designed, verified and deployed on an FPGA in less than two weeks, starting from a specification written by two human architects. According to Architect Labs, its AI system generated the accelerator’s performance model, RTL, verification environments, formal proofs, firmware, drivers and compute kernels without human intervention below the specification level. The work was also undertaken without using pre-existing accelerator IP.
The significance of Redwood therefore extends beyond the specifications of one accelerator. It represents an experiment in whether AI can automate not just individual stages of semiconductor development, but the interactions between architecture, hardware and software that determine whether a processor is well matched to a particular workload.
That distinction is important as AI moves into increasingly diverse applications. The computational requirements of large language models, computer vision, robotics and other forms of Physical AI are not necessarily identical. A processor designed around a specific combination of model architecture, latency, memory requirements and power constraints can potentially make different trade-offs from a general-purpose accelerator.
From sequential design to optimisation loop
Architect Labs argues that the conventional chip-development model creates a particular problem for AI hardware. Semiconductor development can take years, while AI models and workloads can change much more rapidly. By the time an architectural decision has passed through RTL development, verification and implementation, the workload for which the hardware was optimised may have evolved considerably.
The company’s alternative is based around its Architect Labs Platform, or ALP an in-house platform for end-to-end chip design. Rather than treating architecture, RTL, verification and software as largely separate activities, the platform uses a high-level design specification as the common source of truth. Architectural alternatives can then be explored across hardware and software, with functional, area, performance, timing and power considerations used to evaluate different implementations.
This is potentially significant because hardware/software co-design is not a new concept. What changes in the proposed model is the scale and speed at which alternatives can be investigated. If AI systems can generate, test and discard large numbers of candidate implementations automatically, architectural exploration becomes less constrained by the number of engineers who can work on a problem simultaneously.
For Redwood, Architect Labs says that each architectural iteration could be regenerated, reverified and redeployed to an FPGA within 48 hours.
The company also reports that every block through the SoC level achieved at least 95% code and functional coverage using commercial electronic design automation tools, its own formal engine and hardware-in-the-loop validation. These are company-reported results rather than independently established industry benchmarks.
The approach also changes the relationship between software and hardware. Rather than waiting for hardware to exist before optimising software, ALP is intended to develop firmware, kernels and performance models alongside the hardware architecture. This allows software implications to influence architectural decisions before those decisions become embedded in RTL.
Architecture for low-power inference
Redwood itself has been designed around single-batch, low-power and low-latency inference workloads. Its architecture uses a mesh of tiles connected through a custom on-chip network. Each tile combines a RISC-V control processor with dedicated compute resources for transformer inference, including INT8 matrix multiplication engines and a vector engine incorporating SIMD processing, transpose functions and floating-point activation units.
Each tile also contains 512KB of local memory. Rather than implementing every operation as dedicated hardware, the architecture attempts to reuse resources where appropriate. The company’s implementation of softmax, for example, uses an emulated algorithm based on FlashAttention-4 and the existing SIMD resources rather than introducing separate hardware for the operation.
This type of specialisation illustrates one of the potential advantages of AI-assisted hardware exploration. Conventional accelerator design necessarily involves decisions about where to invest silicon area, memory and power. Dedicated hardware can improve performance for a particular operation but consumes resources that cannot easily be redirected. Software implementation provides flexibility but can impose additional computational overhead.
An automated search process could, in principle, examine more combinations of these trade-offs than a human design team could practically evaluate. Architect Labs says its system explored the performance, area, timing and coverage space of the Redwood SIMD engine over multiple days, generating and verifying substantially different candidate microarchitectures.
The important question is not whether AI can generate RTL. It is whether automated exploration can consistently identify architectures that provide meaningful advantages once all the constraints of a real chip are considered.
From FPGA demonstration to silicon
That question remains open because Redwood has not yet been demonstrated as a manufactured ASIC. The currently reported hardware results come from Redwood Nano, a scaled-down two-by-two tile implementation synthesised on an AMD Versal VPK180 FPGA and operating at 250MHz. It has been used to run Qwen3-0.6B end to end, including communication of the prompt to the accelerator and streaming generated tokens back to the host.
Architect Labs reports a throughput of 12.1 tokens per second for this configuration. It also projects that an ASIC implemented at the same process technology class as the NVIDIA Jetson Orin Nano could deliver a projected
3.4-times improvement in performance per watt compared with a measured Jetson baseline running the same model. The company further projects an order-of-magnitude improvement in area efficiency.
These figures should be distinguished from measured silicon performance. The company itself acknowledges that manufactured silicon represents the final validation of the design and says
it is continuing development towards full GDSII generation and a TSMC tapeout.
That distinction is particularly important in evaluating an AI-generated chip. FPGA implementations, synthesis results and architectural projections cannot capture every characteristic of a production device. Physical design, process variation, clock distribution, thermal behaviour, memory performance, manufacturing yield and post-silicon validation can all influence the final result.
The transition from an FPGA demonstration to a manufacturable chip is therefore one of the most important tests of the approach.
Verification becomes part of the experiment
Verification is arguably the most consequential part of the company’s proposition. Generating RTL quickly is of limited value if the resulting hardware cannot be demonstrated to be correct.
Architect Labs says its system automatically generated testbenches, test cases, formal verification artefacts and simulations from the same design intent used to create the hardware. It combined UVM-based verification with formal methods and a proprietary formal engine. According to the company, the first RTL version moved from simulation to the FPGA platform without identified bugs. The underlying concept is that verification capacity becomes linked to available computing resources rather than simply engineering headcount.
The company’s AI agents can run large numbers of simulations and optimisation cycles concurrently, allowing alternative implementations to be assessed continuously. That potentially addresses one of the central bottlenecks in AI-assisted chip design. Increasing the number of generated designs is only useful if verification can scale with it. Otherwise, automated generation simply transfers the bottleneck from design engineering to design validation.
A hardware feedback loop
Perhaps the most unconventional aspect of Redwood is what Architect Labs describes as recursive self-improvement.
The company deployed Qwen3 on Redwood and exposed the model through an inference endpoint within its AI development system. It says the deployed model subsequently identified timing and kernel optimisations that could be incorporated into the accelerator’s development.
This should not be confused with an autonomous system independently redesigning and manufacturing successive generations of silicon. At this stage, the demonstration is considerably narrower: an AI model running on the accelerator was used to identify optimisation opportunities for the hardware and software environment.
Nevertheless, it points towards an intriguing feedback mechanism. AI is being used to design the hardware; that hardware runs an AI workload; observations from that workload are then fed back into the development process.
If such a loop can eventually be extended through physical implementation, tapeout and post-silicon measurement, the potential implications are significant. Hardware development could become increasingly workload-specific, with future accelerators co-evolving with the models they are intended to execute.
Implications for Physical AI
This possibility is particularly relevant to Physical AI, where computational requirements extend beyond conventional cloud inference. Robots, autonomous machines and intelligent industrial systems need to combine perception, inference and physical action under constraints involving latency, power consumption, thermal management and physical size.
A general-purpose accelerator may offer flexibility across many workloads, but an autonomous machine could benefit from hardware optimised around the particular models and operating conditions it uses. Local inference can also reduce dependence on remote computing infrastructure where latency, connectivity or power consumption make cloud processing impractical.
Redwood is not itself presented as a dedicated Physical AI processor. Its architecture is described more broadly as targeting low-power, low-latency inference. However, the development methodology could become relevant to embodied systems if increasingly specialised accelerators are required at the edge.
The broader proposition is therefore less about replacing conventional chip designers than about changing the rate at which specialised hardware can be explored. If AI can shorten the design cycle sufficiently, hardware could potentially follow rapidly changing workloads rather than requiring architects to predict those workloads several years ahead.
That remains a hypothesis to be tested.
For now, Redwood provides an early demonstration of a different semiconductor-development model: one in which AI participates across architecture, hardware, verification and software rather than being confined to an individual stage of the engineering process. Its FPGA implementation provides tangible evidence that parts of this workflow can already be automated, while the projected ASIC results and planned tapeout represent the next, considerably more demanding stage of validation.
If that transition succeeds, the more consequential innovation may not be Redwood’s particular architecture. It may be the possibility of making the journey from workload specification to specialised silicon substantially shorter, more iterative and more computationally driven.
