本文综合 Architect Labs 的 Redwood 博文与其完整技术论文、以及此前公开的 RTL 生成训练方法的相关信息。

Redwood 真正值得关注的地方，并不只是“AI 两周写出了一颗芯片”，而是它试图把芯片架构、RTL、验证、固件、算子 Kernel 和性能优化统一成一个由 AI 驱动的闭环搜索系统。这与今天常见的“LLM 帮工程师写 Verilog”是两个层级的问题。

一、先给 Redwood 一个准确的技术定位

Redwood 是 Architect Labs 面向 single-batch、低功耗、超低时延 Physical AI 推理设计的一类专用 AI 加速器。其 FPGA 版本 Redwood Nano 已经在 AMD Versal VPK180 上运行 Qwen3-0.6B；公司称从两名架构师编写高层规格开始，到性能模型、RTL、UVM、形式验证、固件、驱动和计算 Kernel，均由其 AI 系统生成，在两周内完成设计与验证。(Architect Labs)

所以可以把项目理解成：

Redwood = 一颗 AI 推理加速器；ALP（Architect Labs Platform）= 设计 Redwood 的 AI-native 芯片设计系统。

从技术研究价值看，后者实际上比前者更重要。

传统芯片开发大致是：

需求 → 架构 → 微架构 → RTL → DV验证 → 综合 → 软件 → FPGA/仿真 → 性能优化

Architect Labs 想做的是：

高层规格 → AI并行生成架构/RTL/验证/软件 → EDA反馈 → 性能/PPA/覆盖率反馈 → AI修改设计 → 再验证

也就是说，它不是简单把 AI 插入某一个步骤，而是在尝试把整个芯片开发流程变成一个机器可执行的优化循环。这一点是 Redwood 最核心的技术思想。

---

二、Redwood 本身是什么架构？

从微架构上看，Redwood 并没有发明一种完全陌生的计算范式。它实际上采用了当前 AI ASIC 很合理的一条路线：

Tile + Spatial Dataflow + Scratchpad + DMA + Matrix Engine + Vector Engine。

但它把这些模块做得非常适合自动化搜索。

整个芯片由一个 N×M 的 Tile Mesh 构成。Tile 周围部署 DMA Engine，通过自定义片上网络连接。外部 DRAM 数据先通过全局 DMA 进入片上 SRAM，再通过边缘 DMA 送到计算 Tile。

可以简单画成：

          External DRAM / LPDDR / HBM
                    │
                  GDMA
                    │
              Last-Level SRAM
                    │
        ┌──── Edge DMA ────┐
        │                  │
     Tile ── Tile ── Tile
       │       │       │
     Tile ── Tile ── Tile
       │       │       │
     Tile ── Tile ── Tile
        │
     Edge DMA

这是一种非常典型的空间计算架构。

GPU 倾向于让大量线程执行通用指令，而 Redwood 更倾向于：

提前决定数据往哪里走、哪个计算单元执行什么，然后让数据沿着预定的数据路径流动。

因此它特别适合稳定、结构明确的 Transformer 推理工作负载。

---

三、一个 Redwood Tile 才是架构的核心

每一个 Tile 又被清晰地拆成两个部分：

Front End，负责控制；Back End，负责真正的数据计算。

这项设计看似普通，但实际上与 Architect Labs 的“AI 自动设计芯片”目标高度相关。

前端包含一个精简的 RISC-V 控制核 CRV，以及指令存储器和数据存储器。后端则包含：

• CTM：Core Task Manager
• GEMM/GEMV Matrix Engine
• SIMD Vector Engine
• Transpose 单元
• DMA
• 512 KB CMEM 本地 Scratchpad

论文中的 Tile 图非常清楚地体现了这种结构。

这里最重要的不是 RISC-V，而是 CRV 与计算后端解耦。

传统处理器中，指令不断驱动计算单元：

Fetch → Decode → Execute → Fetch → Decode → Execute

Redwood 更接近：

RISC-V生成任务描述 → CTM拿到任务队列 → 后端自行执行一串计算

于是 CRV 可以在任务执行期间休眠。

这带来三个重要结果。

第一，控制核很小，功耗低。

第二，Matrix Engine、SIMD、DMA 等后端模块以后发生变化，RISC-V 指令译码器基本不需要跟着修改。

第三，也是对 AI 自动设计最重要的一点：

AI 可以大幅修改 Back End，而不用把整个软件控制体系一起推倒重来。

所以 FE/BE 解耦实际上是一种非常适合自动微架构搜索的设计。

---

四、CTM 可能是 Redwood 中最值得关注的模块之一

Redwood 没有让 RISC-V Core 微观管理所有计算，而是引入了 Core Task Manager，CTM。

可以把它理解成一个硬件任务调度器。

例如 Transformer 中执行：

RMSNorm
   ↓
QKV GEMV
   ↓
RoPE
   ↓
QK
   ↓
Softmax
   ↓
PV
   ↓
Output Projection

RISC-V 不需要逐条发指令。

它可以一次写入一系列 Task Descriptor：

Task 101 → GEMV
Task 102 → SIMD
Task 103 → Transpose
Task 104 → GEMV
...

随后告诉 CTM：

按照依赖关系执行这些任务。

CTM 支持 Task ID、Fence、乱序完成、循环、硬件 Trace 等机制。不同 Tile 的 CTM 之间还能直接通过 Message Fabric 相互同步，而不需要唤醒各自的 RISC-V Core。

这意味着：

Redwood 把大量原本属于硬件动态调度的问题，转移给了编译器和软件。

这是一项非常关键的设计取舍。

---

五、为什么要把调度“推给软件”？

传统高性能处理器里有很多昂贵的硬件：

动态调度、仲裁、Cache 一致性、乱序执行、冲突解决……

这些东西非常灵活，但：

面积大、功耗高、验证复杂。

Redwood 反过来：

如果 AI 模型计算图本来就是已知的，为什么还要让硬件在运行时重新猜应该做什么？

于是编译器提前安排：

DMA → Prefetch → Compute → Double Buffer → Synchronization

Tile 之间通过显式 Message 协调。

论文明确指出，这能够减少 Mesh 内复杂仲裁，把 Scheduling 转移到软件层。

因此 Redwood 在哲学上比较接近：

“软件定义的数据流机器”。

它并非 GPU 那种高度通用计算架构。

而这恰恰是专用 ASIC 获得高能效的主要来源之一。

---

六、Matrix Engine + Vector Engine 是典型的 Transformer 分工

Redwood 后端有两个主要计算引擎。

Matrix Engine

负责：

GEMM 和 GEMV。

底层是 INT8 MAC Array，并采用 systolic 数据通路。

Transformer 中最重的计算，包括：

Q、K、V Projection
Output Projection
MLP Gate
MLP Up Projection
Down Projection

本质上大量都是矩阵计算。

因此这些工作交给 Matrix Engine。

Redwood Nano FPGA 配置中，论文给出的矩阵计算阵列为 4 个 Tile，每 Tile 有 64 个 INT8 MAC Lane，在 250 MHz 下理论峰值约为 128 GOP/s。

---

七、Vector Engine 解决“矩阵之外”的问题

Transformer 并不只是矩阵乘。

还有：

RMSNorm
RoPE
Softmax
SiLU
Reduction
Quantization
Transpose
Element-wise 运算

这些计算如果全塞进矩阵阵列，效率并不好。

所以 Redwood 使用 512-bit SIMD Vector Engine。

FPGA 版本在 BF16 时每周期可处理 32 个元素；INT32 则为 16 个。

这与 GPU 中：

Tensor Core + CUDA Core

的分工逻辑有点类似。

只是 Redwood 把计算资源缩得更小、更专用。

---

八、Softmax 的实现特别能体现 Hardware–Software Co-design

一个很有意思的例子是 Softmax。

通常设计 AI ASIC 时可能会问：

要不要做一个专门的 Softmax 硬件单元？

这样当然快。

问题是这个单元占面积，而很多时间可能闲置。

Redwood 的选择是：

不设计昂贵的专用 Softmax Hardware。

而采用来自 FlashAttention-4 的 emulated-softmax 方法，复用现有 SIMD 单元完成相关计算。(Architect Labs)

这就是 HW/SW Co-design 一个非常典型的例子：

传统思路：
算法需要 Softmax
       ↓
增加 Softmax Hardware

Redwood：
算法需要 Softmax
       ↓
能否改变 Softmax 算法？
       ↓
复用 SIMD
       ↓
省芯片面积

也就是说，AI 系统优化的不是单独的 RTL。

它可以同时修改：

算法、Kernel 和硬件。

这才是 Redwood 所谓“统一优化”的真正价值。

---

九、Redwood 为什么大量使用本地 Scratchpad，而不是依赖 Cache？

每个 Tile 有 512 KB CMEM。

本质上属于软件管理的本地 SRAM。

AI 加速器喜欢 Scratchpad 的原因很简单：

Cache：

“我猜以后可能要用这些数据。”

Scratchpad：

“编译器明确告诉硬件，把这些数据搬到这里。”

对于已知计算图来说，第二种方法通常：

更确定、更省电、更容易计算带宽、更容易做实时调度。

Redwood 又通过 DMA + Double Buffer 实现：

Buffer A：正在计算

Buffer B：同时加载下一批数据

计算完成

A/B交换

这样可以隐藏一部分 DRAM 延迟。

这对低延迟推理尤其重要。

---

十、Redwood 的真正瓶颈其实不是 MAC，而是内存

这是论文里一个相当重要、而且比较诚实的结果。

在 FPGA 上跑 Qwen3-0.6B 时，Redwood Nano：

12.1 token/s

而 Jetson Orin Nano：

28 token/s。

所以真实 FPGA 测量中 Redwood 并没有击败 Jetson。

但两者条件差异非常大：

Redwood FPGA：

250 MHz
约 16 GB/s 内存带宽
LPDDR4

Jetson：

1020 MHz
68 GB/s
LPDDR5

因此论文进一步做 Roofline Analysis。

结果非常有意思：

一个 Token 的计算过程中：

DRAM 服务时间约是算术计算时间的 3.6 倍。

换句话说：

MAC 大部分时候不是最大问题，把模型权重送进 MAC 才是问题。

论文得到 FPGA 架构理论 Roofline 大约：

21.73 token/s

而实际是：

12.1 token/s。

差距来自 Kernel Launch、同步、Pipeline Fill/Drain、Host Overhead 等。

所以 Redwood 后续优化最关键的问题其实不是继续增加 MAC。

而是：

Memory → DMA → NoC → Tile 的数据供应链。

这是很典型的 LLM Decode 问题。

---

十一、这也解释了为什么 Redwood 面向 single-batch

Batch 大时，矩阵计算利用率很高。

Batch = 1 时却完全不同。

比如聊天机器人、机器人、无人机、边缘设备：

一个用户
一个摄像头
一个机器人控制循环

通常就是 Batch 1。

此时 Decode 中大量 GEMM 会退化为 GEMV。

GPU 大规模并行能力无法充分展开。

而权重仍然必须不断从 Memory 搬进计算单元。

因此性能越来越接近：$$性能 \approx \frac{内存带宽}{每Token需要读取的数据}$$

Redwood 专门针对这一场景做架构优化，所以它实际上瞄准的是：

Edge / Robotics / Physical AI inference ASIC

而不是训练 GPU。

---

十二、ALP 才是 Redwood 最重要的“AI 技术”

Redwood 博文容易给人一种错觉：

AI 一次 Prompt 就生成了一颗芯片。

实际情况显然不是这样。

Architect Labs 的系统更接近：

专用模型 + Agent Harness + EDA Tools + Simulator + Formal Verification + FPGA + Search。

也就是：

Specification
      ↓
AI Agent
      ↓
生成候选设计
      ↓
RTL / Firmware / Kernel / Verification
      ↓
Compile / Simulation / Formal / Synthesis
      ↓
真实机器评分
      ↓
Functional / Coverage / PPA / Timing
      ↓
AI修改
      ↓
再次验证

关键不是 LLM “知道答案”。

而是：

答案可以被机器自动验证。

这对 AI 芯片设计极其重要。

---

十三、为什么硬件特别适合“可验证奖励”？

Architect Labs 在此前的 RTL 模型研究中专门讨论过这个问题。

它们从 Kimi-K2.5 开始，对 Architect v0.1 进行 RLVR——Reinforcement Learning from Verifiable Rewards 后训练，并结合 GRPO、课程学习等方法。生成 RTL 后，不是让另一个 LLM 判断代码“写得好不好”，而是真正进行语法检查、仿真和测试。(Architect Labs)

例如：

LLM生成Verilog
      ↓
编译
      ↓
仿真
      ↓
Testbench
      ↓
结果是否正确？
      ↓
Reward

这是硬件 AI 的巨大优势。

因为：

RTL 正不正确是可以执行验证的。

与写文章相比，不需要让另一个模型凭感觉打分。

需要特别说明的是，Architect Labs 并没有公开确认 Redwood 全流程使用的恰好就是 Architect v0.1 或 Kimi-K2.5；Redwood 论文只说使用了自研模型、Agent Harness 和 AI-native EDA。因此不能简单说“Kimi-K2.5 设计了 Redwood”。

---

十四、ALP 最大突破可能其实是自动 Verification

芯片行业有一个经常被忽略的问题：

写 RTL 并不是最耗时间的环节。

验证往往更耗资源。

所以“AI 能写 Verilog”并不足以缩短芯片项目。

Redwood 更有意义的一项主张是：

UVM Testbench、Test Case、SVA、Formal Artifact 和 Simulation 全部自动生成。

公司报告所有 Block：

Code Coverage ≥ 95%

并且：

Functional Coverage ≥ 95%。

还结合商业 EDA、UVM、自研 Formal Engine 和 FPGA Hardware-in-the-loop。

这就出现了一个非常重要的变化。

传统模式：

10个AI Agent写RTL
       ↓
可能需要更多工程师验证

Redwood 模式：

AI生成RTL
   │
   ├── AI生成UVM
   ├── AI生成SVA
   ├── AI生成Test
   ├── Formal Proof
   ├── Simulation
   └── FPGA validation
          ↓
       Feedback
          ↓
       AI修正

如果这种能力能够扩展到真正的大型 SoC，那么影响可能远大于“RTL Coding Copilot”。

---

十五、它甚至把 Microarchitecture 本身当成搜索空间

这里又是 Redwood 和普通 EDA Agent 的一个重要区别。

很多自动设计系统主要优化：

位宽
Pipeline Stage
Register Placement
参数数量

但 Architect Labs 声称 ALP 可以生成具有不同：

Control Path
Datapath
State Machine

的 RTL。

例如它们让系统自动探索 SIMD Engine。

AI 可以生成很多不同实现，然后分别做：

Performance
Area
Timing
Coverage

评估，再继续搜索。论文展示了其 SIMD 微架构的自动探索过程。

所以这已经越来越像：

Architecture Search + RTL Synthesis + Verification 的联合搜索。

这可能才是未来 AI EDA 最有价值的方向。

---

十六、FPGA 在这个系统中的意义也发生了变化

传统 FPGA Prototype 更多用于：

ASIC 做完后验证一下。

Architect Labs 则把 FPGA 变成了 AI Agent 的实验环境。

论文称，他们建立了 FPGA Multiplexing Environment，让数百个 Agent 可以共享 FPGA，自动运行实验、读取结果、修改 Kernel，再运行下一轮。

原来一次仿真优化可能需要：

约 15 小时

进入 FPGA Hardware-in-the-loop 后：

15～30 分钟。

于是 FPGA 变成了类似机器学习中的：

“Environment”。

可以类比强化学习：

Agent
  ↓
生成设计 / Kernel
  ↓
FPGA运行
  ↓
Latency / Throughput / Error
  ↓
Reward
  ↓
下一轮

这个思路非常值得关注。

---

十七、所谓“Recursive Self-Improvement”应该怎样理解？

这是 Redwood 宣传中最容易被夸大的部分。

他们做的是：

1. AI 系统设计 Redwood；
2. 在 Redwood 上运行 Qwen3；
3. 把这个 Qwen3 暴露成 ALP 内部 API；
4. 让 Qwen 对运行自己的部分 Kernel 和 Timing 进行优化；
5. 优化结果用于下一代 Redwood。

公司称这属于早期的 Recursive Self-Improvement。

其逻辑就是：

AI
 ↓
设计 AI Chip
 ↓
Chip运行AI
 ↓
AI优化Chip
 ↓
更好的Chip
 ↓
运行更强AI
 ↓
继续设计更好的Chip

从工程角度看，它确实形成了一个“AI→硬件→AI”的闭环。

但目前称为“递归自我改进”还是应该谨慎理解。

因为现在实际上更接近：

AI-assisted iterative hardware optimization

而不是一个模型自主修改自身权重、训练方法和计算基础设施后持续指数式提升。

论文自己也承认，目前存在一个明显 Gap：

能够设计复杂硬件的 AI，比能够部署在 Redwood 上的 AI 强得多。

所以目前更多是一种非常有趣的工程原型。

---

十八、那“3.4×性能功耗比”到底怎么来的？

这是理解 Redwood 时必须特别区分的一点。

不是当前 FPGA 测量结果。

Redwood FPGA 实际：

12.1 token/s。

3.4×来自 ASIC Projection。

Architect Labs 假设将 Redwood 放到类似 Jetson Orin Nano 的 Samsung 8 nm 工艺，并采用：

1 GHz Logic Clock
0.75 V
约 64 GB/s Memory Delivery

得到保守估计：

49 token/s。

估算功耗：

1.335 W。

于是：

36.7 token/s/W

对比其测量的 Jetson：

28 token/s
2.59 W
10.8 token/s/W

因此得到：

约 3.4× performance-per-watt。

其芯片面积估计约：

2.88 mm²。

面积计算也不是凭空估计，而是根据约 200 万组合逻辑 Cell、50 万寄存器等做 Gate Equivalent 推算，再加入 DFT、布线利用率、Clock Tree、Timing Closure 等余量。

方法本身合理。

但一定要强调：

这是 ASIC Projection，不是实际流片测量。

---

十九、这也是目前 Redwood 最大的技术边界

Architect Labs 自己也明确承认：

目前真正跑起来的是：

FPGA。

下一阶段才是：

Physical Design
GDSII
Tape-out
Post-silicon Validation。(Architect Labs)

所以“production-worthy AI accelerator”目前主要还是公司的定性描述。

严格从芯片工程角度，Redwood 尚未证明几个最困难的问题：

先进工艺完整 P&R
Timing Sign-off
IR Drop
Power Integrity
Clock Tree
Signal Integrity
DFT
Scan/ATPG
Memory PHY
封装
Thermal
Yield
Post-silicon Debug

FPGA 能正常运行是非常重要的一步，但：

FPGA Success ≠ ASIC First-silicon Success。

近期外部报道也特别指出，这项工作的下一项真正关键验证，就是把设计真正带到 silicon。(Venturebeat)

此外，“95% coverage”同样不能简单翻译为“95% 正确”。

Coverage 证明的是：

测试覆盖到了多少预设行为。

Formal Verification 最终能证明什么，也取决于：

Property 写得是否完整。

因此规格自动生成验证环境这一环节，本身仍是系统可靠性的核心。

---

二十、我认为 Redwood 最重要的技术意义，是把 EDA 问题重新定义了

过去谈 AI for EDA，问题通常是：

AI 能不能帮助工程师写 RTL？

后来变成：

AI Agent 能不能调用 EDA 工具？

而 Redwood 提出了更激进的一层：

能不能把整个芯片开发过程变成一个机器可搜索、机器可验证、机器可优化的系统？

这三个层级的差异非常大：

第一阶段
AI → 代码生成

第二阶段
AI Agent → EDA工具自动化

第三阶段
AI → Architecture
   → RTL
   → Verification
   → Firmware
   → Kernel
   → FPGA
   → PPA反馈
   → 再设计

Redwood 真正指向的是第三阶段。

如果这一模式最后能够扩展到真实 Tape-out，那么未来芯片设计最根本的变化可能不是：

“一名 RTL 工程师效率提高五倍。”

而是芯片开发逐渐从：

人设计 → 工具验证

转向：

人定义目标和约束 → AI搜索设计 → 工具证明设计 → 人审批架构。

---

最后用一句话概括

Redwood 表面上是一颗 AI 推理芯片，实质上是 Architect Labs 用来证明“AI-native 芯片设计闭环”可行性的实验载体。

它现在最有说服力的成果并不是“性能超过 NVIDIA”，因为 FPGA 实测目前还没有超过 Jetson；真正重要的是，它已经把架构生成、RTL、UVM、Formal、Firmware、Kernel、FPGA Hardware-in-the-loop 和微架构搜索连接成了一个自动反馈循环，而且能在几十小时而不是数月的时间尺度上重新生成和验证一次硬件架构。

如果后续 Architect Labs 真正完成 GDSII → Tape-out → First Silicon → Post-silicon Validation，并且仍然能够保持这种接近“Specification-to-Silicon”的自动化程度，那么 Redwood 的意义就不只是又一个 AI Accelerator，而可能成为 AI-native EDA / AI-native Chip Engineering 的一个重要技术节点。