Paper deep dive
Redwood: A Frontier AI Accelerator Designed, Verified, and Deployed from Scratch in 2 Weeks by AI
Architect Labs
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 92%
Last extracted: 8/28/2026, 3:42:10 AM
Summary
The paper introduces Redwood, a frontier AI accelerator designed, verified, and deployed end-to-end by an AI system (Architect Labs Platform) in under two weeks. Redwood is a tile-based spatial-dataflow accelerator optimized for single-batch, low-power, ultra-low-latency inference for physical AI. The system autonomously generated the performance model, RTL, UVM environments, formal proofs, firmware, and kernels from a high-level specification. Redwood Nano, an FPGA variant, runs models like Llama and Qwen. Projected on Samsung 8nm, it delivers 1.75x throughput and 1.9x lower power than the NVIDIA Jetson Orin Nano, resulting in a 3.4x performance-per-watt gain. The paper highlights a shift from sequential hardware design to an automated, co-designed optimization loop.
Entities (9)
Relation Signals (6)
Architect Labs Platform → designed → Redwood
confidence 95% · The system autonomously generated the performance model, RTL design, UVM environments, formal proofs, firmware, and kernels... from a high-level specification by two human architects.
Redwood Nano → outperforms → NVIDIA Jetson Orin Nano
confidence 95% · Redwood delivers 1.75x the throughput at 1.9x lower power, a 3.4x performance-per-watt gain against a measured Jetson baseline...
Redwood Nano → runs → Qwen3-0.6B
confidence 95% · Redwood Nano, its ultra-low-power FPGA variant, runs multi-billion-parameter models like Llama and Qwen.
Redwood Nano → deployedon → AMD Versal VPK180
confidence 90% · Redwood Nano is synthesized and deployed on the AMD Versal VPK180 FPGA at 250 MHz.
Redwood → uses → RISC-V
confidence 90% · Each tile pairs a RISC-V-based tile control core (CRV) with compute engines co-designed for transformer inference.
Redwood → implements → FlashAttention
confidence 85% · This region launches, orchestrates, and cleans up kernels such as FlashAttention [7] and GEMM/GEMV.
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract: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.
Tags
Links
- Source: https://arxiv.org/abs/2608.26418v1
- Canonical: https://arxiv.org/abs/2608.26418v1
Trouble viewing inline? Open PDF directly →
Full Text
34,192 characters extracted from source content.
Expand or collapse full text
Redwood: A Frontier AI Accelerator Designed, Verified, and Deployed from Scratch in 2 Weeks by AI Architect Labs Team * Palo Alto, California Abstract— 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 deci sions 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 performanceper watt and demands a design cycle that runs at the cadence of the workloads. We present an endtoend AI system that collapses the softwaretosili con stack into a single optimization loop, where hardware and software are codesigned and verified under one objective. Its first demonstration is Redwood, a frontier AI accelerator built for singlebatch, lowpower, ultralow latency inference for physical AI. From a highlevel specifi cation 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 commer cial EDA tools, our proprietary formal engine, and hardwareinthe loop validation. Specification changes were reverified and redeployed to hardware in under 48 hours. Redwood Nano, its ultralow power FPGA variant, runs multibillionparameter 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 performanceper 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 selfimprovement. To our knowledge, this is the first productionworthy AI accelerator designed endtoend by an AI system and running a modern AI model. I. Introduction The EDA industry now reports orderofmagnitude gains from AI across RTL generation, verification, debugging, and exploration, including claims of reducing multimonth efforts to days and achieving up to 10× productivity across design and verification workflows [1], [2], [3]. However, only 14% of IC/ASIC projects achieve firstsilicon success, the lowest rate in two decades, while 75% are behind schedule as chip programs contend with esca lating design complexity, driven by heterogeneous integration, advancednode physical effects, and increasingly stringent power, performance, and area (PPA) constraints [4], [5]. This divergence highlights a deep misalignment between tasklevel productivity claims and complete program outcomes: AI has accelerated indi vidual activities, but it has not demonstrated clear endtoend program improvement on increasingly complex SoCs. At the same time, publicly demonstrated endtoend AIgener ated designs have remained limited to simple examples, such as toy RISCV cores or hardened numeric datapaths. Almost none have been validated on physical hardware, which is ultimately the final constraint of hardware design. We argue that the opportunity for AI in hardware design is not task acceleration within the existing flow but the reimagining of the entire flow itself. When architec ture, RTL, verification, firmware, and kernels are generated from a single specification and optimized under one objective, the sequential handoffs that dominate program latency disappear, and hardwaresoftware codesign becomes a property of the system rather than a coordination process between teams. * The full list of contributors is in the appendix. To address this, we introduce Redwood, a frontier AI accelerator designed, verified, programmed, and deployed endtoend by such a system. Two human architects captured the workload and archi tectural constraints in a highlevel specification. From that speci fication, the system autonomously generated the performance model, RTL, UVM environments, formal proofs, firmware, drivers, and custom compute kernels. In under two weeks, it produced the complete design from scratch, closed every block at 95% code and functional coverage, and deployed the Redwood Nano configura tion on an AMD Versal FPGA. A third week brought Qwen30.6B inference online [6]. Each architectural change during this period was regenerated, reverified, and redeployed to hardware in under 48 hours. Evaluated on a Samsung 8 nmclass process comparable to that used by NVIDIA Jetson Orin Nano, Redwood Nano is projected to deliver 1.75x the decode throughput at 1.9x lower power, a 3.4x improvement in performance per watt, against the measured Jetson baseline running the same model. The remainder of the paper is organized as follows. Section I describes the Redwood architecture. Section I presents the pro gramming model. Section IV evaluates Redwood Nano on FPGA and projects its performance, area, and power. Section V details the Architect Labs AI system that produced the design, including auto mated verification, microarchitectural exploration, and firmware and kernel generation, and reports an early demonstration of recursive selfimprovement of AI model and the hardware that fuels it. I. Architecture Fig. 1: Redwood SoC architecture.1 Redwood is a tilebased, spatialdataflow accelerator that uses standard AXI4 memorymapped interfaces: AXILite for control 1The AXI4 NoC (pink) shape here is left abstract (in general not a ring), and it is assumed LLC is much closer and has lowerlatency access than the external memory interface (DDR, HBM). 1 and configuration, and wide AXI4 with full burst support for bulk data. Dedicated DMA engines move all traffic to and from external DRAM. A global DMA (GDMA) fabric performs bulk memory tomemory transfers between external memory and the onchip West, North, and East lastlevel SRAM banks (LLCs), while edge DMA engines stage data on and off the compute fabric. A global control region sequences the accelerator and contains the global control core (MCU), a global task manager, and a 48bit global timer (HAC) broadcast to every tile for timefenced scheduling. This region launches, orchestrates, and cleans up kernels such as FlashAttention [7] and GEMM/GEMV. Because the memory interface is confined to modular DMA engines, Redwood can be integrated within a larger SoC or packaged as a standalone chiplet. The DMA back ends can also be retargeted from AXI4 to protocols such as ACE and CHI without disturbing the compute fabric. The compute fabric is an 푁×푀 mesh of identical tiles sur rounded by edge DMA engines. Each tile pairs a RISCVbased tile control core (CRV) with compute engines codesigned for trans former inference. The matrix engine (CMXM) provides systolic GEMM and matrixvector (GEMV) datapaths and streams directly into the vector engine (CVXM), which provides SIMD, transpose, and floatingpoint activation units. Wide, banked scratchpad memories minimize data movement within Redwood. The com pute engines are codesigned with the kernel software, so they map directly onto dominant transformer operators—attention, GEMM, normalization, and activations—and execute kernels such as FlashAttention and GEMM as hardwarescheduled tasks rather than generic instruction streams. A highbandwidth, internally designed, creditbased NoC carries tiletotile, DMAtotile, and tiletoDMA traffic. It provides lowoverhead broadcast and mul ticast, tablebased stream redirection, and perlink flow control. A.Tile Architecture Each tile within the Redwood fabric is divided into a front end (FE) and a back end (BE). The FE handles control and program ming, while the BE handles data movement and computation. Separating sparse control from highbandwidth data processing allows the FE to operate in a slower clock domain and, in some cases, shut down during kernel execution for aggressive power savings. Kernel software runs on the tile control core (CRV), while the Core Task Manager (CTM) bridges the CRV and the BE functional units and orchestrates tasks across a configurable set of units. Fig. 2: Redwood tile architecture. The hardware units within the tile BE are codesigned for modern transformer workloads, including ondevice prefill and decode. One optimization uses the emulatedsoftmax algorithm from FlashAttention4 [8], which reuses existing SIMD resources for an otherwise areaexpensive operation. Fig. 3: Standard Redwood tile BE units. These functional units and the CRV share access to a local 512KB core memory (CMEM) over a highbandwidth bus. Local ingress and egress DMA engines move data into and out of CMEM. B.Control Mechanism To compute using a Redwood tile, a kernel is first loaded into the FE instruction tightly coupled memory (ITCM). The Core Debug, Trace, and Control (CDTC) unit then boots the baremetal tile control core (CRV). The CRV waits for a function call delivered to the data tightly coupled memory (DTCM) through the CDTC and then executes the selected kernel function. A kernel function typi cally expands into several MMIO writes that enqueue CTM tasks for dispatch to the corresponding functional units. Multiple kernel calls can be enqueued provided their implementations reside in ITCM. Fig. 4: Redwood FEBE orchestration. This decoupling between the FE and BE provides the following benefits: •The CRV remains simple, implementing a minimal RISCV spec ification with low area and power overhead. •The CRV decoder remains unchanged when BE functional units are added, changed, or removed. •The CRV can hand a task list to the CTM and then idle until interrupted. The CTM natively supports: •Arbitrary task ordering and fencing using task IDs to track out oforder completions. •Hardware tracing and logging to a trace buffer, with software notifications delivered through interrupts. •Loops over arbitrary sections of queued tasks to reduce repeated CRV writes. CTM tasks can also be fenced by external “messages” carried over the Redwood SoC message fabric, which connects all CTMs. 2 Fig. 5: Redwood CTM messaging network. Messages allow CTMs to order control flow without involving the CRV or MCU. In the representative example in Fig. 6, the tile at (0,0) sends interleaved messages toward the West and East DMA engines, whose CTMs wait for “goahead” messages before releasing their next tasks. Communication can also flow in the op posite direction, with DMA CTMs signaling tile CTMs to send data downstream. Messaging can be configured as fireandforget or acknowledgmentbased. The compiler uses messaging to coordi nate prefetching, doublebuffering, and outoforder computation. Explicit traffic control through messages reduces the need for complex arbitration in the mesh and moves scheduling into the software stack. Fig. 6: Redwood CTM messaging flow example. I. Programming Model Redwood includes a flexible programming model for running different models and workloads on the same fabric. Programs for the global control core (MCU) are called Dispatch Programs (DPs), while programs for individual tiles are called kernels. Multiple DPs are grouped into a “DP set,” and multiple kernels into a “kernel set,” amortizing initialization overhead. For a host processor to use Redwood to perform an operation, the flow is: 1.(Prerequisite) Load the DP set from external memory into the MCU ITCM. 2.(Prerequisite) Load the kernel set from external memory into all tiles’ ITCMs. 3.The host processor writes the dispatch ID and operands into the MCU DTCM and signals the MCU. 4.The MCU executes the dispatch program selected by the dis patch ID. The dispatch program can: •Program the static routing tables in the internal fabric mesh. •Configure the global task manager for prefetches, memory tomemory copies, and scattergather operations. •Configure DMAengine task managers to move data into and out of the tile array. •Launch tile kernels by writing a kernel ID and operands into a tile’s DTCM and signaling the tile control core. The DP can poll status or rely on tile interrupts to determine when the tile array has finished. A running DP may launch one or more kernels over its lifetime. For example, FlashAttention repeatedly launches tiles to process different KV blocks and heads. 5.When the DP completes, the MCU interrupts the host processor to indicate that execution is complete and the reserved input and output buffers are available to the host. Fig. 7: Redwood dispatch and kernel execution flow. If the DP or kernel sets required for an entire model do not fit in ITCM, the host processor loads them in partitions at runtime and groups them to minimize swaps. IV. Evaluation Redwood Nano is the FPGA configuration of Redwood, designed and optimized for ultralow power, lowlatency edge use cases. It consists of a 2×2 tile array, with each DMA engine connected to a set of 128bit AXI4 interfaces. The West and North interfaces prioritize ingress read bandwidth, while the East interface priori tizes egress write bandwidth. Redwood Nano is synthesized and deployed on the AMD Versal VPK180 FPGA at 250 MHz. To evaluate performance, we run Qwen30.6B on Redwood Nano and compare it with the NVIDIA Jetson Orin Nano. Fig. 8 shows the placement and instantiation hierarchy of Redwood Nano on the VPK180 FPGA. We measure LLM decode performance in output tokens per second at both peak and average throughput. For Redwood Nano, the measurement includes sending the prompt from the host to the FPGA, running Qwen on the FPGA, and returning each output token to the host. The NVIDIA Jetson Orin Nano runs the same model at a 1020 MHz GPU clock, with performance measured using NVIDIA’s Jetson WebUI. TABLE I presents the benchmark comparison. 3 Fig. 8: Redwood Nano FPGA placement and instantiation hierarchy. TABLE I: Redwood Nano vs. NVIDIA Jetson GPU performance compar ison for Qwen30.6B LLM inference. Comparison Redwood Nano NVIDIA GPU Jetson Orin Nano Average Tokens/s (*)12.128 Frequency (MHz)2501020 Memory Bandwidth (GBytes/ sec) 16**68 Memory TypeLPDDR4LPDDR5 *Measured over 128 tokens generated. **DRAM Memory BW for Redwood at peak achievable frequency of 250MHz, 4 128bit AXI4 streams. A.Redwood Roofline Analysis of Peak Decoding Throughput The operationlevel roofline is derived from the Qwen30.6B decode graph. The model has 28 decoder layers, hidden width 1024, intermediate width 3072, 16 query heads, 8 KV heads, head dimension 128, and vocabulary size 151,936. In each layer, the INT8 linear shapes are 푄:[2048,1024], 퐾,푉:[1024,1024], 푂: [1024,2048], gate,up:[3072,1024], and down:[1024,3072]. The matrix engine contains four tiles with 64 INT8 MAC lanes per tile. Counting a multiply and accumulation as two operations, its peak rate is 푃 GEMV =4×64×250×10 6 ×2=128Gop/s. The 512bit SIMD datapath accepts 32 BF16 or 16 INT32 operands per cycle, giving peak rates of 푃 SIMD,BF16 =32×250×10 6 =8Gop/s, 푃 SIMD,INT32 =16×250×10 6 =4Gop/s. The sustained externalmemory bandwidth is 퐵=0.90 32×3900×10 6 8 =14.04GB/s. For each unfused operator 푖, we count arithmetic work 푂 푖 and total DRAM traffic 푄 푖 , including all operand reads and result writes. Its compute, memory, and attainable times are 푇 cmp 푖 = 푂 푖 푃 푖 ,푇 mem 푖 = 푄 푖 퐵 ,푇 푖 =max(푇 cmp 푖 ,푇 mem 푖 ). Operators remain sequential because each consumes the preced ing operator’s result. Consequently, the completetoken bound is 푇 token =∑ 푖 푇 푖 . Memory and compute may overlap within one operator, but no work or traffic is hidden across operator bound aries. TABLE I: Operationlevel roofline for one Qwen30.6B decoder layer at context length 128. Each row may group adjacent unfused operators; its attainable time sums the individual operator maxima. One-layer operator group Work (Mop) DRAM (MB) 푇 cmp (μs) 푇 mem (μs) ∑푇 푖 (μs) Limit Input norm + QKV quant.0.0080.0091.00.71.0SIMD Q/K/V projections8.3974.24768.6302.5303.2DRAM Q/K norm, RoPE, and cache 0.0340.0424.23.04.7SIMD QK and score scaling0.5300.1586.111.212.3DRAM Softmax and probability quant. 0.0290.0393.62.84.3SIMD V quantization and PV1.0530.55371.239.477.3SIMD O projection and residual4.2062.12434.7151.3152.0DRAM MLP norm and input quant. 0.0080.0091.00.71.0SIMD Gate and up projections12.5956.367102.9453.5454.6DRAM SiLU and gate multiply0.0220.0312.72.23.6SIMD Down projection and residual 6.3073.17751.6226.2227.3DRAM One decoder layer33.18916.755347.51193.41241.4Mixed One decoder layer therefore has an architectural latency of 1.241 ms. The 28 layers contribute 34.76 ms, while embedding, final normalization, the languagemodel head, and argmax contribute another 11.26 ms. The complete token moves 0.627 GB, requiring 44.65 ms of aggregate DRAM service and 12.29 ms of aggregate arithmetic service. Summing the peroperator roofline times gives 푇 token =46.02ms,푅 roof = 1 푇 token =21.73tokens/s. The memory service time is 3.6 times the arithmetic service time, establishing that decoding is strongly memorybound. The mea sured throughput remains below this architectural ceiling because launch, synchronization, pipeline fill/drain, and host overhead are excluded. If memory transfer and execution are instead forced to serialize within every operator, the corresponding conservative bound is 56.94 ms per token, or 17.56 tokens/s. Further opti mization remains in software and host overhead through better prefetching, software scheduling, and hardware updates in the control path. B.Redwood Performance, Area, and Power Projection We estimate the architectural roofline for the configuration that uses a 1 GHz logic clock, which we believe to be reasonable given FPGA timing. The roofline model bounds throughput by the slowest stage along the weightdelivery path — DRAM → NoC → edge DMAs → mesh switches → compute — so we compute the sustainable bandwidth of each stage and take the minimum. A key point is that the DRAM data rate (3900 Mb/s per pin) is fixed by the memory device and does not scale with the fabric clock; the 1 GHz clock accelerates the onchip fabric, SIMD engine, and MAC arrays. Assuming the same bandwidth as Nvidia Jetson Orin Nano, the tileingress path is still the narrowest stage, so the design remains memorydeliverybound at approximately 64 GB/ s. In this scenario, the architectural ceiling is approximately 95 to kens/s averaged over 128 generated tokens. The gain over today’s approximately 21token/s roofline comes from engaging three controllers and increasing the logic clock, which raises aggregate tileingress bandwidth from 16 to 64 GB/s and scales the compute engines by four. In a nonideal setup, not all execution of the model can be overlapped with data transfer. We profiled the execution of Qwen on the FPGA and carefully scaled every step based on the 4 improved clock frequency, higher memory bandwidth, and better task scheduling due to fewer hardware restrictions. Our most conservative projection shows that the current ASIC design will achieve approximately 49 tokens/s on average over 128 generated tokens without changes to the software stack. We project the area and power of Redwood on a Samsung 8 nmclass process comparable to that used by NVIDIA Jetson Orin Nano. Physical area was estimated using a standard bottomup gateequivalent (GE) methodology tailored to Samsung 8 nm phys icaldesign rules. Standardcell counts were converted into GE units by weighting the 2 million combinational cells and 500,000 sequential registers by their average relative gate sizes. Their sum yields the raw standardcell area, representing active silicon without interconnect gaps. We add 15% overhead for designfor test logic. A 70% placementutilization factor then provides space for metal routing, powergrid rails, and decoupling capacitors. Fi nally, we add 20% area overhead for clocktree synthesis repeaters, timingclosure cells, and perimeter structures. Redwood Nano’s projected Samsung 8 nm NPU block area is ≈2.88m 2 . We estimate total Redwood power by separating dynamic and static components. Core dynamic power follows 푃 dyn =훼퐶푉 2 푓, while core static power is represented by 푃 stat . At a target frequency of 1.0 GHz on Samsung 8 nm and a nominal core voltage of 푉 core =0.75푉, the 2 million logic cells and 500,000 flip flops and 512KB SRAM per tile consume approximately 0.958 W of dynamic power under the average switching activity observed for Qwen30.6B. Static leakage is 푃 stat ≈0.07 W. Including the remaining SoC and clockmanagement components brings total chipside power to 푃 total ≈1.335 W. Running the same application on Jetson, we achieved 28 tokens per second. Jetson’s average power for its CPU and GPU cores is 2.59 W with fusion enabled. For fairness, both power esti mates include host and accelerator compute but exclude memory controllers and other peripheral components. Redwood’s perfor mance and power projections on a comparable Samsung 8 nm class process show a 1.75x performance improvement and a 1.9x power reduction, yielding a 3.4x performanceper watt improve ment while retaining significantly shorter design time and time to market. TABLE I summarizes the projected performance, area, and power of Redwood Nano compared with NVIDIA Jetson Orin Nano. TABLE I: Redwood Nano vs. NVIDIA Jetson Orin Nano power, area, and performance for Qwen30.6B LLM inference on a Samsung 8 nmclass process. Comparison Redwood Nano NVIDIA GPU Jetson Orin Nano Average Tokens/s *49 (1.75×)28 Power (W)1.335 (1.9×)2.59 Area (m2)2.88NA Tokens/s per Watt36.7 (3.4×)10.8 *Projected over 128 tokens generated (ASIC). V. Architect Labs System In under two weeks, the entire Redwood was designed, verified, brought to synthesis and physicaldesign readiness, and deployed as the Redwood Nano FPGA configuration. The accelerator was produced from scratch, with zero preexisting accelerator IP. This was enabled not only by training our own models, building agent harnesses, and building AInative EDA tools, but also by a funda mental rethinking of the hardwaredesign flow from software to silicon. The traditional chipdesign life cycle is highly sequential, progressing through stages from architectural definition to final tapeout. Along the way, collateral is “frozen,” and changes are either made ad hoc or reserved for the next generation. Hardware teams pipeline development so that, after Version N is frozen, the corresponding team begins Version N+1 (Fig. 9). This enables large hardware companies to release new hardware at a 9–12 month cadence. Fig. 9: Representative life cycle of a traditional ASIC program. While its throughput may be acceptable, the latency of this sequential approach makes true hardware–software (HW–SW) co design impractical. In the current AI landscape, by the time an architecture is defined and RTL design and verification are under way, new models can invalidate months of optimization. Hardware teams must therefore predict where workloads are heading and add generalpurpose features as a hedge. The Architect Labs flow is as automated and parallel as possible, removing the requirement for a “freeze” and enabling flexible ar chitectural exploration and endtoend implementation. It is built around the Architect Labs Platform (ALP), our inhouse platform for endtoend chip design. Once design intent is captured in ALP, the automated flow generates RTL, UVM collateral, SVA assertions, formal proofs and other artifacts. No human interven tion is required below the specification; human experts maintain ALP throughout the project life cycle and adjust the specification or design intent using functional, area, performance, timing, and power feedback. Fig. 10: Architect Labs Platform and automated frontend flow. A key benefit of this automated flow is that humans and agents can explore multiple architectural ideas in parallel. For Redwood, each architectural iteration was regenerated, reverified, and rede ployed to FPGA within 48 hours. The complete design cycle, from the initial specification to finalized RTL, verification, firmware, custom kernels, and timing closure took two weeks, with all blocks reaching 95% code and functional coverage. A third week brought the target workloads i.e. new AI models onto the FPGA; the complete threeweek project timeline is shown in Fig. 11. 5 Fig. 11: Redwood design process history, extracted from repository com mits. Fig. 12 shows the repository’s mergecommit history of the AI system over the project life cycle. The AI system reached a peak of 115 merge commits in one day while bringing target workloads online and continuously optimizing Redwood’s firmware and kernels. Fig. 12: Redwood repository commit activity. A.Automated Design Verification and Coverage Closure Testbench generation, testcase development, and coverage clo sure for Redwood were fully automated. Traditional “AI agents for verification” often involve a human engineer using chat to automate testcase development and testbench construction. This approach still requires significant human effort and does not scale with chip complexity, so it has not materially shortened the endtoend ASIC development cycle. In contrast, every Redwood testbench, test case, formal artifacts and simulation was generated automatically from ALP using AI and complier based methods without human DV participation. Following standard industry verification practices, we use UVM technology alongside modern formal methods [9]. We have developed the first version of our proprietary formal engine to generate sections of each verification environment from a humanwritten specification. The verification flow measured and automatically optimized coverage and performance criteria. Every block achieved 95% code and functional coverage. When sending the first RTL drop from simulation to FPGA, there were zero bugs found, and to date our verification methods have not encountered an instance of a bug missed in our verification environment but revealed in actual hardware. As our technology scales, we expect verification rigor to scale with available compute rather than just the size of the team and EDA tool licenses, and we look forward to sharing more in future announcements. B.Design and Optimization Because RTL design is fully automated in our flow, the system can explore a microarchitectural search space an order of magni tude larger than a human team can cover in the same time. Consider our SIMD engine, which performs reducedprecision floatingpoint and integer operations across multiple vector lanes. Although individual lanes are straightforward to develop and replicate, reduction operations such as reduce, max, and min span all lanes. By running more system instances over longer horizons, we can discover a broad set of novel candidates. In the example below, our AI system traversed the performancearea timing search space over multiple days, designing, verifying, and optimizing while maintaining code coverage and verification rigor. Fig. 13: Autonomous SIMD engine exploration path. Fig. 14: SIMD engine microarchitectural exploration and optimization for performance, area, and timing, and code coverage. Prior approaches to automated microarchitectural exploration were often limited to changes such as bitwidth adjustments or register rearrangements. Here, the generated RTL candidates can use fundamentally different control paths, datapaths, and state machines and are free to find solutions beyond what humans may believe to be optimal. As our technology scales, we expect explo ration quality to be bounded by available compute rather than by human insight, and as that bound rises, the system will surface architectures that lie outside the cognitive limits of the best human designers. C.Firmware Generation and Kernel Optimization One benefit of ALP is that it enables codevelopment of all system software, including firmware, kernels, and performance models, before any RTL or verification collateral is written. This gives architects an unparalleled ability to make informed design decisions before committing to an implementation. Our AI system wrote and tested all firmware and kernels required to bring up the SoC and run Qwen inference. Depending on runtime, system software is tested against ALP projections, cycleaccurate RTL simulation, or an existing FPGA build. We designed an inhouse custom emulation environment that multiplexes FPGA access across hundreds of concurrent agents, allowing them to run ex periments, share performance results, and iterate without human intervention for days. In some instances, the AI system discovered optimizations and architectural improvements that our human experts had not considered or thoroughly explored. The system 6 has also enabled us to discover new hardware features for the next generation of Redwood, allowing multiple and parallel iterations of new designs. Moving from RTL and performancemodel simulation to our inhouse FPGA environment reduced optimization runs from 15 hours to approximately 15–30 minutes. As AI automates more of the design process, we believe FPGAbased emulation will become essential for accelerating performance verification and ASIC roadmaps. D.Recursive Self-Improvement As a final result, we deployed Qwen3 on Redwood and exposed it as an inference endpoint within our AI system. Through repeated sampling, the AI model discovered multiple timing improvements and kernel optimizations for several of its own operations, all at zero inference cost. We believe this is one of the earliest demonstrations of recursive selfimprovement: an AI system designed an AI accelerator, deployed an AI model on it, and used that model to improve a future generation of the accelerator. Today, there exists a gap between the capability of an AI system that can design autonomously design hardware, and the capability of AI models that can actually be deployed on said hardware. As our AI system continues to scale to more complex hardware designs, and we close this mismatch, sustained AIdriven improve ments to modern hardware will become one of the largest drivers of AI progress. Fig. 15: Requirements for recursive selfimprovement. VI. Conclusion We presented Redwood, a programmable accelerator designed, verified, and deployed from scratch by an AI system in under two weeks. The system closed every block at 95% code and functional coverage, and Redwood Nano ran Qwen30.6B on an AMD Versal FPGA at 13 peak and 12.1 average tokens/s. Calibrated by these FPGA measurements, our Samsung 8 nmclass projection reaches 49 tokens/s at 1.335 W, a 3.4× performanceper watt improve ment over the measured Jetson Orin Nano baseline. AI assistance within the conventional, sequential chipdesign process has not substantially shortened endtoend development. Our AI system takes an orthogonal approach: a highlevel speci fication is the source of truth from which architecture, RTL, verification, firmware, and kernels are codesigned and optimized together. This allowed architectural changes to be reverified and redeployed to hardware in less than 48 hours. Future work will focus on closing the remaining gap to the memory roofline, scaling Redwood to larger models and fabrics, and extending the AI system through physical design, tapeout, and post silicon validation. Our ultimate goal is to make intelligence abundant through recursive selfimprovement: as AI models and available compute improve, the system can explore and optimize more AI hardware designs, producing more efficient compute that further accelerates the next generation of AI and hardware devel opment. References [1]Cognichip, “Chip Design at 10x Speed: Shifting Semiconductor Economics.” [Online]. Available: https:// w.cognichip.ai/blog/chipdesignat10xspeedshifting semiconductoreconomics [2]ChipAgents, “The Agentic AI Chip Design Environment.” [Online]. Available: https://chipagents.ai/ [3]Cadence Design Systems, “ChipStack AI Super Agent: Agentic AI for SoC Design.” [Online]. Available: https:// w.cadence.com/en_US/home/tools/systemdesignand verification/chipstackaisuperagent.html [4]Wilson Research Group and Siemens EDA, “2024 Wilson Research Group IC/ASIC Functional Verification Trend Re port,” technical report, 2024. [Online]. Available: https:// resources.sw.siemens.com/enUS/whitepaper2024wilson researchgroupicasicfunctionalverificationtrendreport/ [5]E. Sperling, “FirstTime Silicon Success Plummets,” Semicon- ductor Engineering, Mar. 2025, [Online]. Available: https://se miengineering.com/firsttimesiliconsuccessplummets/ [6]Qwen Team, “Qwen3 Technical Report.” [Online]. Available: https://arxiv.org/abs/2505.09388 [7]T. Dao, D. Y. Fu, S. Ermon, A. Rudra, and C. Ré, “FlashAt tention: Fast and MemoryEfficient Exact Attention with IOAwareness,” in Advances in Neural Information Processing Systems, 2022. [Online]. Available: https://arxiv.org/abs/2205. 14135 [8]T. Zadouri, M. Hoehnerbach, J. Shah, T. Liu, V. Thakkar, and T. Dao, “FlashAttention4: Algorithm and Kernel Pipelin ing CoDesign for Asymmetric Hardware Scaling.” [Online]. Available: https://arxiv.org/abs/2603.05451 [9]IEEE, “IEEE Standard for Universal Verification Methodology Language Reference Manual.” [Online]. Available: https:// standards.ieee.org/ieee/1800.2/7567/ Appendix: Contributors and Contact Contributors, ordered alphabetically by last name: Armin Ab dollahi, Vipin Boyanapalli, Trevor Daykin, Omar El Malki, James Fang, Joel Galenson, Dan Ganousis, PinChun (Adrian) Hsu, Ebrahim Hussain, Moenes Iskarous, Arulmani Krishnan, Balbindra Kumar, Rakesh Kumar, Hugh Leather, Gang Li, Mu (Kevin) Lin, Madison Ma, Satyaveer Singh Mahecha, Basil Nabi, Deric Pang, Adam Petcher, Sahand Salamat, Aaditya Subedi, Ekin Sumbul, Raymond Wang, Manthan Wankar, Jindrich Zejda, Changyang Zeng. General inquiries, including partnership & collabration request, and technical questions about Redwood, may be directed to con tact@architectlabs.com or architectlabs.com. 7