Source-linked AI summary
Redwood: A Frontier AI Accelerator Designed, Verified, and Deployed from Scratch in 2 Weeks by AI
Architect Labs
TL;DR
Modern workloads change faster than hardware programs, while conventional chip-design flows leave end-to-end outcomes misaligned with that pace. Redwood addresses this by co-designing and verifying hardware and software from one specification, achieving rapid physical deployment and projected efficiency gains over Jetson Orin Nano. The resulting system also enabled an AI model running on Redwood to help improve a future accelerator generation.
Problem
AI chip-design task acceleration has not solved the mismatch between rapidly changing workloads, long hardware cycles, and limited physically validated end-to-end AI-generated designs.
Method
The system uses a high-level specification as the source of truth to co-design and generate architecture, RTL, verification, firmware, kernels, and deployment artifacts.
Results
3.4x performance-per-watt improvement over the measured Jetson Orin Nano baseline was projected for Redwood on a Samsung 8 nm-class process.
Takeaways & Limitations
Redwood demonstrates an AI-designed accelerator running a modern model, with architectural iterations reverified and redeployed to hardware in under 48 hours.
Abstract
from arXiv · showhide
Modern AI workloads and the hardware that runs them evolve on different timescales: architectural definition precedes volume silicon by years, while target workloads shift in months. Design decisions are therefore committed under deep uncertainty and paid for twice, once in the generality added as a hedge, and again when new workloads map poorly onto frozen silicon. As Moore's Law stagnates, specialization is the main remaining source of performance-per-watt and demands a design cycle that runs at the cadence of the workloads. We present an end-to-end AI system that collapses the software-to-silicon stack into a single optimization loop, where hardware and software are co-designed and verified under one objective. Its first demonstration is Redwood, a frontier AI accelerator built for single-batch, low-power, ultra-low-latency inference for physical AI. From a high-level specification by two human architects, the system autonomously generated the performance model, RTL design, UVM environments, formal proofs, firmware, and kernels in under two weeks with no human intervention below the specification. Every block reached 95% coverage via commercial EDA tools, our proprietary formal engine, and hardware-in-the-loop validation. Specification changes were reverified and redeployed to hardware in under 48 hours. Redwood Nano, its ultra-low-power FPGA variant, runs multi-billion-parameter models like Llama and Qwen. Projected onto Samsung 8 nm, the Jetson Orin Nano's process class, Redwood delivers 1.75x the throughput at 1.9x lower power, a 3.4x performance-per-watt gain against a measured Jetson baseline on the same models. Qwen running on Redwood also helped design next-generation Redwood, an early step toward recursive self-improvement. To our knowledge, this is the first production-worthy AI accelerator designed end-to-end by an AI system and running a modern AI model.
I. Introduction
AI has accelerated individual chip-design tasks, but complete AI-generated hardware validated on physical systems remains rare. Redwood addresses this gap by generating and deploying an accelerator end-to-end from a high-level specification.
- 14% of IC/ASIC projects achieve first-silicon success, while 75% are behind schedule amid rising design complexity and PPA constraints.These figures motivate a shift from task-level acceleration toward complete program outcomes.
- Public demonstrations of end-to-end AI-generated hardware have largely remained simple examples, with almost none validated on physical hardware.The paper identifies physical deployment as the final constraint of hardware design.
- Redwood was generated from two human architects’ high-level specification, including its performance model, RTL, verification environments, proofs, firmware, drivers, and kernels.The complete design was produced from scratch in under two weeks without human intervention below the specification.
- Every block reached 95% code and functional coverage, and Redwood Nano was deployed on an AMD Versal FPGA before Qwen3-0.6B inference was brought online.Architectural changes were regenerated, reverified, and redeployed in under 48 hours.
- The paper proceeds from Redwood’s architecture and programming model to FPGA evaluation and the Architect Labs system that generated the design.The later system discussion includes automated verification, exploration, firmware and kernel generation, and recursive self-improvement.
II. Architecture
Redwood uses a tiled spatial-dataflow architecture that separates control from high-bandwidth computation and coordinates work through DMA, task managers, and software-directed messaging. Its tile engines and memory system are co-designed for transformer inference.
- Memory and interconnect: Redwood uses AXI4 interfaces for control and bulk data, with dedicated DMA engines moving traffic between external memory, LLC banks, and the compute fabric.The NoC supports broadcast, multicast, stream redirection, and per-link flow control.
- SoC and compute fabric: Redwood combines an N×M mesh of identical tiles, edge DMA engines, on-chip LLC banks, and a credit-based NoC for data movement.The global control region includes an MCU, task manager, and broadcast timer for orchestration and time-fenced scheduling.
- Tile architecture: The back end pairs systolic GEMM/GEMV and SIMD, transpose, and floating-point activation engines with banked scratchpads.These units directly map to transformer operations such as attention, GEMM, normalization, and activations, including FlashAttention and GEMM kernels.
- Tile architecture: Each tile separates a front end for control and programming from a back end for data movement and computation.This separation allows slower-clocked or temporarily disabled control logic during kernel execution, while the CTM orchestrates configurable functional units.
- Task orchestration: The Core Task Manager bridges the tile control core and back-end units, tracking task IDs for arbitrary ordering, fencing, tracing, and logging.Kernel execution begins with a function call to the CRV, which expands into MMIO writes that enqueue tasks for functional units.
- Messaging network: CTM messaging coordinates control flow across the SoC without involving the CRV or MCU.The compiler uses fire-and-forget or acknowledgment-based messages for prefetching, double-buffering, and out-of-order computation, reducing mesh arbitration complexity.
III. Programming Model
Redwood’s programming model divides execution between global dispatch programs and tile kernels, with the host loading code, signaling the MCU, and receiving completion interrupts. Runtime partitioning supports models whose code exceeds local instruction memory.
- Program organization: Programs for the global control core are Dispatch Programs, while programs for individual tiles are kernels.Multiple dispatch programs and kernels are grouped into sets to amortize initialization overhead.
- Host-to-accelerator flow: The host loads dispatch and kernel sets into instruction memories, writes a dispatch ID and operands to MCU data memory, and signals the MCU.This establishes the prerequisites for launching a Redwood operation.
- Dispatch execution: The MCU executes the selected dispatch program to configure routing, global and DMA task managers, and tile-kernel launches.Dispatch programs can poll status or use completion mechanisms while orchestrating prefetches, copies, scatter-gather operations, and tile execution.
- Capacity management: If a model’s dispatch or kernel sets exceed ITCM capacity, the host loads them in runtime partitions and groups them to minimize swaps.This provides a programming path for workloads that do not fit in local instruction memory.
IV. Evaluation
Redwood Nano is evaluated on FPGA with Qwen3-0.6B and compared against Jetson Orin Nano using measured performance and projected ASIC roofline, power, and area analyses. The evaluation identifies memory delivery as the main bottleneck and projects substantial efficiency gains for Redwood.
- FPGA evaluation: Redwood Nano uses a 2 × 2 tile array on an AMD Versal VPK180 FPGA at 250 MHz for Qwen3-0.6B inference.Its 128-bit AXI4 interfaces prioritize ingress on the West and North sides and egress on the East side.
- Roofline analysis: 44.65 ms of aggregate DRAM service versus 12.29 ms of aggregate arithmetic service makes decoding strongly memory-bound.The measured throughput remains below the architectural ceiling because launch, synchronization, pipeline fill/drain, and host overhead are excluded.
- ASIC projection: 49 tokens/s is the most conservative projected ASIC throughput over 128 generated tokens without software-stack changes.The projection is based on improved clock frequency, higher memory bandwidth, and better task scheduling under fewer hardware restrictions.
- ASIC projection: 1.75x performance improvement, 1.9x power reduction, and 3.4x performance-per-watt improvement are projected against the measured Jetson Orin Nano baseline.The comparison uses a Samsung 8 nm-class process comparable to Jetson Orin Nano and includes host and accelerator compute while excluding memory controllers and peripherals.
VI. Conclusion
Redwood demonstrates an AI system that designed, verified, and deployed a programmable accelerator from scratch in under two weeks. Its architecture and software were co-designed from a high-level specification, while future work targets larger systems and the remaining physical implementation stages.
- Conclusion: Redwood was designed, verified, and deployed from scratch by an AI system in under two weeks, with every block reaching 95% code and functional coverage.Redwood Nano ran Qwen3-0.6B on an AMD Versal FPGA at 13 peak and 12.1 average tokens/s.
- Conclusion: A high-level specification served as the source of truth for jointly optimizing architecture, RTL, verification, firmware, and kernels.Architectural changes were reverified and redeployed to hardware in less than 48 hours.
- Conclusion: Future work targets the remaining gap to the memory roofline, larger models and fabrics, physical design, tapeout, and post-silicon validation.The paper also identifies recursive self-improvement as an ultimate goal for the AI hardware-design system.