How AI May Move the Freeze Point in Chip Design
Fast Turnaround
Late last month, Architect Labs posted a paper to arXiv titled Redwood: A Frontier AI Accelerator Designed, Verified, and Deployed from Scratch in 2 Weeks by AI. The experiment started with two human architects writing a high-level specification for an AI accelerator. From there, the company’s AI system generated the hardware design, verification environment, firmware, and software needed to run it.
That seems unusual to me partly because chip development is such a long and unforgiving process. Architectural decisions can be made years before the resulting chip reaches large-scale production, even at companies releasing new generations every nine to twelve months through overlapping development programs. A recent industry survey found that only 5% of chip-design projects achieved working silicon on the first attempt in 2026, down from 14.4% just two years earlier. The same study found that most projects were running behind schedule.
Redwood has not reached manufactured silicon yet, so it has not faced that part of the process. Still, the chip-design project figure gives some sense of how difficult chip development remains once a design moves beyond simulation and emulation into physical hardware.
Architect Labs says the initial Redwood design went from specification to running on an FPGA, a reprogrammable chip often used to prototype and test custom hardware designs, in under two weeks. After that, changes to the architectural specification could be regenerated, reverified, and running on hardware again in less than 48 hours. Against the development timelines and failure rates that seem typical for this kind of work, that turnaround time seems fast.
From Specification to Implementation
In the Redwood development flow, the specification sits at the top: a description of what the chip should do and the constraints it has to satisfy. Below it sits the implementation work required to turn those requirements into a functioning system: the hardware design itself, the verification needed to establish that it works, and the firmware and low-level software required to operate it.
Those layers depend on one another, so changes near the top can require work throughout the stack. That dependency becomes important later when considering why chip designs eventually have to freeze.
Credible, but not Competitive
What the system produced was not a toy processor; Redwood is a tile-based spatial-dataflow design with RISC-V control cores, systolic INT8 matrix engines, and a custom credit-based network for moving data across the chip. In plain terms, it is a complete AI accelerator architecture with specialized hardware for computation, processors for control, and dedicated systems for moving data where it needs to go. The design also includes the firmware and software required to make those pieces work together and run a modern language model.
I’m not a chip designer, but the scope of what was built seems like it matters. This was a working system capable of running a modern language model, not a small demonstration showing that AI could generate a few pieces of chip logic.
On the FPGA hardware Architect Labs actually tested, Redwood ran Qwen3-0.6B at 12.1 tokens per second, compared with 28 tokens per second on an NVIDIA Jetson Orin Nano. In other words, on the hardware that exists today, Redwood was less than half as fast. The picture changes only when Architect Labs projects the design onto a future custom chip, where it estimates roughly 49 tokens per second at much lower power. That projected result is what produces the reported 3.4x performance-per-watt advantage.
Designing the physical chip, manufacturing it, and validating the resulting silicon all still need to happen. The paper also describes a form of recursive self-improvement, because a model running on Redwood contributed to work on a later Redwood design. That is interesting, but it is still a long way from showing an AI system that is improving its own capabilities at an accelerating rate.
But I still find Redwood very interesting; it doesn’t need to have beaten NVIDIA on today’s benchmarks for the process behind it to be worth examining. What Architect Labs built only needs to be credible enough to show that the process was solving a real engineering problem rather than a toy one, and the paper makes a reasonable case that it was.
The “Design Freeze”
A chip designer has to make expensive decisions years before the resulting silicon reaches the market, while the workloads it is meant to run can change much faster. One response is to design for flexibility, but that approach has significant costs: area, power, and complexity pile on to support capabilities that may never matter, and the eventual workload can still map poorly onto choices made years earlier.
The design freeze is another response. Once enough downstream work depends on an architectural decision, updating it can force changes to the implementation, verification, firmware, software, and other assumptions built on top of it. Eventually, changing your mind costs more than you are likely to gain from a better design. That makes a design freeze less an engineering preference for certainty than an economic decision. You freeze because reopening the decision becomes too expensive.
Architect Labs' approach and AI system attacks that cost directly. It made some individual stages much faster, but the more important claim is that it reduced the cost of reopening decisions between them. A change to the specification could trigger new implementation, verification, firmware, and software without requiring people to manually unwind the dependencies underneath it.
But that does not eliminate the need for a design freeze, it moves the point where freezing becomes rational. The work leading to manufacturing may become much cheaper to revisit, but once the design starts becoming a physical chip, the commitments become harder and more expensive to change. AI can regenerate the work leading up to that point. It cannot regenerate manufactured silicon.
Where the Humans Stood
An unusual detail in the story of the Redwood experiment is not simply that there were only two humans involved. The two architects worked at the specification level, adjusting design intent in response to feedback on function, area, timing, power, and performance, while the AI system generated and regenerated the implementation underneath.
That is different from the usual picture of a human supervising AI-generated work. The architects were not primarily reviewing low-level hardware designs, checking test cases, or approving firmware. They were deciding which tradeoffs were worth making: more performance for more area, less generality for lower power, one architectural choice against another, then changing the specification when the result was not worth the cost.
In that sense, their role looked less like producing the artifacts themselves and more like continuously steering what the system should optimize for. There is not an obvious job description for that yet, but it is a different kind of engineering work from either implementing the design directly or simply reviewing someone else’s output.
Verification Has to Keep Up
Generating a new version of a design quickly only helps if you can check it just as quickly. Otherwise, verification becomes the new bottleneck. Architect Labs built much of that checking into the same automated system, so changes could be tested and validated without waiting for a separate human verification process.
To me, that appears to be an important part of how the iteration cycle got so short. Some optimization runs that previously took roughly 15 hours were reduced to 15 to 30 minutes, allowing the system to test changes and feed the results back into the next iteration much faster. The broader point is that if checking a change is cheap, you can afford to make more changes and keep architectural decisions open longer.
The 48-hour turnaround is harder to evaluate independently. Architect Labs points to its repository history and its record of architectural iterations, but the team itself defines what counts as an iteration. Unlike the performance figures, there is no external benchmark or simple calculation a reader can use to verify the result, so I think of 48 hours as a reported process result rather than an established capability.
What Hasn’t Changed
The authors are explicit that manufactured silicon is still the final test, and many of the hardest commitments are still ahead; Redwood does not show that design freezes have disappeared. Once a design moves from something that can be regenerated in software toward something that has to be physically manufactured, changes become much harder and more expensive.
What may be changing is how long designers can wait before reaching that point. Silicon has not become easier to change, but changing your mind before you reach silicon may have.
References
- Architect Labs / arXiv, Redwood paper: https://arxiv.org/abs/2608.26418
- Siemens EDA, 2026 Functional Verification Study: https://blogs.sw.siemens.com/verificationhorizons/2026/09/08/the-2026-functional-verification-study/
- Intel, FPGA and processor guide: https://www.intel.com/content/www/us/en/newsroom/tech101/client-computing/processor-guidebook-the-basics-from-cpus-to-asics.html
- RISC-V International, About RISC-V: https://riscv.org/about/
- Qwen, Qwen3-0.6B model page: https://huggingface.co/Qwen/Qwen3-0.6B/tree/main
- NVIDIA, Jetson Orin Nano: https://www.nvidia.com/en-us/autonomous-machines/embedded-systems/jetson-orin/nano-super-developer-kit
- Synopsys, What is ASIC Design?: https://www.synopsys.com/glossary/what-is-asic-design.html
- arXiv, Recursive Self-Improvement in AI: https://arxiv.org/abs/2607.07663
