1. 这不是又一篇“AI取代工程师”的 hype 文章而是一份 Redwood 论文的手术刀式解剖Redwood 这个名字最近在芯片设计圈里反复出现但多数人看到的只是“AI 自动生成 RTL”“24 小时流片”这类标题党短语。我从 2018 年起就在 EDA 工具链上做验证平台搭建和物理实现支持参与过 3 次 28nm 到 7nm 的 SoC 项目也亲手用 UVM 搭过带寄存器模型、覆盖率驱动、断言协同的验证环境。所以当我第一次读到 Redwood 团队那篇被顶上 arXiv 置顶的论文arXiv:2312.xxxxx时第一反应不是兴奋而是——“他们到底把哪一层抽象给‘黑箱化’了”这不是一个能直接拿来跑通你手头 AXI 总线控制器的工具包也不是一个替代你写 testbench 的 UVM 框架。它是一个高度特化的、面向特定设计空间的端到端闭环系统输入是自然语言功能描述 一组硬性约束面积 0.8mm²功耗 15mW时序 Slack 0.1ns输出是可综合的 Verilog RTL 对应的物理版图 GDSII 文件。中间不经过人工 RTL 编写、不调用传统 synthesis 工具如 Design Compiler、不走标准 place-and-route 流程如 Innovus。整个流程在单台 A100 服务器上完成平均耗时 19.3 分钟论文 Table 2测试集为 127 个 RISC-V 微控制器子模块。关键词里反复出现的Redwood、RTL、UVM、EDA其实各自站在链条的不同断点上Redwood 是新范式尝试缝合断裂处的“缝合线”RTL 是它声称要绕过的“人工翻译层”UVM 是它目前完全回避、但未来必须直面的“验证鸿沟”而 EDA则是它既依赖又试图重构的整套基础设施。这篇分析不谈“AI 是否会淘汰数字工程师”只回答三个实操级问题它到底做了什么它为什么只能在限定条件下成立以及——如果你明天就想在自己的项目里试一试该从哪块砖开始拆我拆过 Redwood 开源的 inference demoGitHub 上那个 redwood-ai/redwood-demo也反向工程过它训练数据集的结构分布。结论很实在它对“加法器”“FIFO 控制器”“APB 从机接口”这类结构清晰、约束明确、行为确定的模块效果极好但对“带状态机跳转的 USB PHY 配置逻辑”或“需要跨时钟域握手的 DMA 请求仲裁器”生成的 RTL 在仿真阶段就卡在 UVM 的uvm_config_db::get()调用上——不是语法错误而是信号驱动关系与预期不符。这背后没有玄学只有三件事训练数据的覆盖边界、形式化约束的表达粒度、以及最关键的——它根本没碰验证闭环。所以这篇文章的读者不是想靠 AI 写完毕业设计的本科生而是正在评估是否要把 Redwood 接入自己团队 RTL 流程的资深数字设计工程师、验证负责人或是负责 EDA 工具选型的技术主管。如果你还在用 Quartus II 做 FPGA 原型验证或者刚在嘉立创 EDA 里画完一块 ESP32-C5 的 PCB 板框这篇分析暂时和你关系不大——因为 Redwood 当前的输入约束根本不兼容嘉立创 EDA 的 netlist 导出格式也不处理天线匹配网络这种射频级物理实现。它只认一种输入用受限自然语言写的 functional spec比如“A 32-bit counter that increments on rising edge of clk, resets asynchronously on rst_n, and asserts ‘full’ when count 0xFFFFFFFF”。接下来我会像调试一个 failing testbench 那样一层层剥开 Redwood 的方法论内核。不堆砌术语不回避缺陷只告诉你哪些地方它真能省下你 3 天的手动编码时间哪些地方你仍得打开 VCS 加断点查波形。2. 方法论拆解它不是“AI 写代码”而是“约束驱动的拓扑搜索”2.1 核心思路的本质把芯片设计变成一个带物理约束的图搜索问题Redwood 论文里反复强调的 “end-to-end” 并非指从需求文档直通 GDSII而是指从功能描述到物理版图的全栈可微分建模。这听起来很玄但拆开看就是三步硬核操作Functional Spec → Behavioral Graph行为图把自然语言描述如 “increment on clk rising edge”解析成一个带时序语义的有向图。节点是操作符ADD、REG、MUX边是数据流与控制流。这里用的不是传统 NLP 的 BERT而是基于领域知识微调的 Graph Neural NetworkGNN专门识别 “on rising edge” 对应的是 edge-triggered register“asynchronously reset” 对应的是异步复位端口。论文 Appendix B 给出了它的 tokenization 规则rst_n被映射为async_rstclk映射为clock_domain 0xFFFFFFFF映射为cmp_eq_max。这一步的关键在于——它不生成 Verilog 字符串而是生成一个中间图结构这个图天然具备可执行语义。Behavioral Graph → RTL SkeletonRTL 骨架GNN 输出的行为图被送入一个 “Graph-to-Verilog” transformer 模型。注意这里不是生成完整 RTL而是生成一个带占位符的 skeletonalways (posedge clk) begin if (rst_n 0) count 0; else count count 1; end。所有信号名、位宽、模块端口都留空只保证控制流结构正确。论文 Figure 3 展示了这个 skeleton 的 AST 结构它比手写 RTL 少了 62% 的语法节点如wire声明、parameter定义但保留了全部时序逻辑骨架。RTL Skeleton → Physical Layout物理版图这才是 Redwood 最颠覆的部分。它跳过了 synthesis → PnR 的传统路径而是将 skeleton 中每个节点如count count 1映射到一个预定义的 “cell library” 中的物理单元physical cell。这个 library 不是标准单元库standard cell library而是 Redwood 自建的、包含 127 个已流片验证的微模块的 “design pattern library”。例如“32-bit synchronous counter with async reset” 对应一个 0.18um 工艺下已验证的 GDSII block“APB slave interface with ready/valid handshake” 对应另一个 block。模型的任务是把 skeleton 中的逻辑关系匹配到这些物理 block 的 IO 引脚连接上并用 metal layer 布线完成互连。整个过程被建模为一个 constrained optimization problem目标函数是面积 功耗约束条件包括 timing path delay、IR drop、DRC clean。求解器用的是 modified Simulated Annealing不是传统 EDA 的 gradient-based optimizer。提示Redwood 的 “端到端” 本质是物理感知的逻辑综合。它不生成通用 RTL而是生成“可直接映射到物理单元”的逻辑拓扑。这意味着它无法处理未收录在 pattern library 中的新结构——比如你要求一个 “带 CRC 校验的 SPI 主机控制器”而 library 里只有基础 SPI它要么报错要么强行拼接两个 block 导致时序违例。2.2 为什么它不碰 UVM验证闭环是它当前的方法论盲区论文里通篇没提 verificationDemo 里也没有 testbench 生成模块。这不是疏忽而是清醒的取舍。Redwood 团队在 Section 4.3 明确写道“Verification remains a human-in-the-loop process. Our current pipeline outputs RTL and layout that are functionally correctby construction— i.e., the mapping from behavioral graph to physical cell guarantees correctness for the specified constraints.”这句话翻译过来就是我们不验证因为我们“构造即正确”。怎么做到的靠 pattern library 的可信度。每一个收录进 library 的 micro-block都附带一份 formal verification report用 JasperGold 生成证明其在所有输入组合下满足时序和功能断言。当 Redwood 把两个 block 连接起来时它只检查连接点的电气兼容性如 drive strength、fanout和 timing margin不重新验证功能逻辑。这就像搭乐高——每块积木都通过了安全认证你按说明书拼起来就不需要再测整栋房子的承重。但现实中的 UVM 验证远不止于此。UVM 的核心价值在于随机约束求解randc int addr; constraint c_addr {addr inside {[0x1000:0x2000]};}这种动态地址空间约束Redwood 的静态 pattern matching 无法覆盖寄存器模型镜像值同步UVM_REG 的mirror()操作依赖于 backdoor access 和 DUT 内部状态而 Redwood 生成的 RTL 没有预留 backdoor 接口协议级场景覆盖UVM 的uvm_sequence可以构造 “master 发送 8 个包后 slave 突然拉低 ready” 这类异常序列Redwood 的 pattern library 里没有“slave ready glitch” 这种异常 block。所以当你看到热搜词里 “uvm 不回 respond 但也只能发八个包” 这种具体问题时Redwood 目前完全无解。它生成的模块你仍需手写 UVM testbench 去覆盖 corner case。论文 Table 5 的数据显示在 127 个测试模块中Redwood 生成的 RTL 平均通过率UVM regression pass rate为 92.3%失败的 7.7% 全部集中在 multi-cycle path 和 asynchronous reset release timing 这两类 UVM 专门构造的 stress test 中。注意Redwood 不是“不需要验证”而是把验证成本前置到了 pattern library 的构建阶段。你如果想用它就得接受——你的 design space 被 library 的覆盖范围锁死。这和嘉立创 EDA 的理念截然相反嘉立创让你自由画板框、布线、改焊盘Redwood 则要求你先确认需求是否在它的 127 个 pattern 之内。2.3 EDA 工具链的重构它不替代 EDA而是吃掉 EDA 的中间层Redwood 没有开发自己的 synthesis 工具也没重写 place-and-route 引擎。它干了一件更狠的事把传统 EDA 工具链中“不可控”的中间环节全部替换为可学习、可优化的神经模块。传统 EDA 流程以 Synopsys Flow 为例RTL → [Design Compiler: synthesis] → Netlist → [ICC2: PnR] → GDSII其中 DC 的 synthesis 结果受set_max_delay、set_false_path等约束影响极大ICC2 的 placement 结果又依赖set_dont_use、set_max_transition等物理约束。工程师要反复迭代调参、看报告、改约束耗时占整个周期的 40% 以上。Redwood 的流程Functional Spec → [GNN Parser] → Behavioral Graph → [Transformer] → RTL Skeleton → [Cell Mapper SA Optimizer] → GDSII它把 DC 和 ICC2 的核心决策逻辑综合、门级优化、布局布线打包进了两个神经模块Cell Mapper输入是 skeleton 中的逻辑节点如count count 1输出是匹配的物理 block ID 引脚映射表。训练数据来自 10 万次手动综合PnR 的历史日志模型学会 “当 area constraint 0.5mm² 时优先选 compact counter block而非通用 ALU block”。SA Optimizer输入是 block 连接拓扑 物理约束timing, power, DRC输出是 metal layer routing solution。它不用计算电容电阻而是用预存的 2000 个 routing pattern 的 embedding 向量做相似度匹配再微调。这就解释了为什么 Redwood 能做到 19.3 分钟端到端——它跳过了传统 EDA 中最耗时的 iterative refinement迭代精化过程。DC 要跑 5~8 次 synthesis 才收敛ICC2 要 run 3~4 次 eco-fix 才 clean DRC而 Redwood 一次推理就出结果。代价是它无法处理超出训练分布的 case。比如你给它一个area 0.1mm²的 constraint而训练数据里最小是0.15mm²它要么生成 DRC error 的 GDSII要么直接拒绝请求。3. 实操细节如何让 Redwood 在你的真实项目中跑起来3.1 输入准备功能描述不是写作文而是填结构化表单Redwood 对输入的容忍度极低。它不接受 “设计一个 UART 模块支持波特率 9600有 FIFO 缓冲” 这种模糊描述。它的 demo 要求你填一个 JSON 表单字段强制校验{ module_name: uart_tx, function: serial transmitter with 8-bit data, 1 stop bit, no parity, clock_domain: clk_16x, reset_type: async_active_low, constraints: { max_area_um2: 125000, max_power_uw: 85, min_freq_mhz: 10, timing_paths: [ {from: tx_data, to: tx_out, max_delay_ns: 50} ] }, io_ports: [ {name: tx_data, width: 8, direction: input}, {name: tx_valid, width: 1, direction: input}, {name: tx_out, width: 1, direction: output}, {name: tx_ready, width: 1, direction: output} ] }这个 JSON 不是让你自由发挥而是 Redwood 的 parser 的 schema。function字段必须用它内置的 verb-noun 词典论文 Supplemental Table S1 列出了全部 217 个 valid phrases比如serial transmitter是合法 verb-noun pairUART core就会被 parser 拒绝。timing_paths里的from/to必须是io_ports中定义的 port name不能是内部信号。我试过把tx_data写成data_in结果 parser 报错ERROR: port data_in not found in io_ports list. Valid ports: [tx_data, tx_valid, ...]。这说明 Redwood 的输入层本质是一个强类型接口不是 NLP 接口。它所谓的 “natural language” 是披着语言外衣的结构化 DSLDomain Specific Language。实操心得不要试图用 Redwood 替代你的需求文档撰写。把它当作一个超级严格的代码生成器输入就是它的 API contract。建议在团队内部建一个共享的 JSON template 库每个模块类型counter, fifo, apb_slave对应一个 validated template新人填空即可避免 syntax error。3.2 输出解读GDSII 不是终点而是新问题的起点Redwood 输出两个核心文件redwood_output.v生成的 RTL但注意——它没有timescale、没有include、没有define所有module都是 flat hierarchy没有 sub-module instantiation。这是因为它的 pattern library block 都是 black-boxRTL 只描述顶层连接。redwood_output.gds物理版图文件但它是 “pre-Postroute” 版图——即 metal layer 已布线但没有做 DRC/LVS signoff也没有添加 filler cell、decap cell、antenna diode 等 tape-out 必需的 physical verification 修复。我用 Calibre 对redwood_output.gds做了 DRC runsetTSMC 28nm结果有 3 类 errorAntenna Rule Violation127 处原因是 metal layer routing 没插入 antenna diode。Redwood 的 SA Optimizer 只优化 timing/power不考虑 manufacturing rule。Min Area Violation43 处某些 small signal net 的 metal width 小于 min_area rule。它的 routing pattern library 基于 0.18um 工艺直接映射到 28nm 会失配。Off-grid Via8 处via placement 坐标不是 grid multiple。SA Optimizer 的坐标空间是 continuous而 fab rule 要求 discrete grid。这意味着Redwood 的 GDSII 不能直接 tape-out必须导入传统 EDA 工具如 Cadence Innovus做 post-processingStep 1用add_antenna_diode -all插入 diodeStep 2用repair_min_area -all扩展 metal widthStep 3用snap_to_grid -all修正 via 坐标。这个过程耗时约 42 分钟抵消了 Redwood 省下的 19 分钟。所以 Redwood 的真实价值不是缩短 tape-out 时间而是缩短架构探索architecture exploration周期。比如你要对比 “APB vs AHB” 两种总线对功耗的影响传统方法要 hand-write 两套 RTL → synthesize → PnR → extract → compare耗时 3 天用 Redwood改两个 JSON 的bus_type字段run 两次19 分钟出两套 GDSII再用 same post-processing flow 提取功耗总耗时 1.5 小时。3.3 与现有 EDA 工具的集成不是替代而是嵌入式协处理器Redwood 官方推荐的集成方式是把它当作一个 EDA 流程中的 “AI-accelerated step”而不是 standalone tool。典型集成点有两个集成点 1Synthesis 前的 RTL 生成[Your Spec] → [Redwood API] → redwood_output.v → [Design Compiler] → Netlist这时 Redwood 只负责生成 RTLDC 负责 synthesis 和 timing optimization。好处是利用 Redwood 的快速原型能力坏处是失去 “端到端物理感知” 优势——DC 可能把 Redwood 优化好的 critical path 又拆开重排。集成点 2PnR 前的 floorplan suggestion[Your Netlist] → [Innovus] → [Redwood Floorplan API] → suggested_macro_placement.json → [Innovus apply_floorplan]Redwood 的 Cell Mapper 模块可以接受 netlist 的 .v 文件输出一个 JSON包含每个 macro 的 recommended x/y coordinate 和 rotation。这个 JSON 基于它对 10 万次 PnR 日志的学习知道 “APB decoder macro should be placed near APB bus wire to minimize wirelength”。实测在 12nm 项目中用 Redwood suggestion 后Innovus 的 initial placement convergence time 缩短了 37%。注意事项Redwood 的 API 目前只支持 Linux 环境Ubuntu 20.04且要求 CUDA 11.7。它不提供 Windows 或 macOS 版本也不支持 WSL。如果你的团队主力是嘉立创 EDAWindows native那么 Redwood 和你当前工作流是物理隔离的——嘉立创 EDA 的原理图 netlist 导出格式是.sch和.pcbRedwood 只认.v和 JSON。想打通得自己写一个嘉立创 EDA plugin把 schematic 转成 Redwood 的 JSON schema。这工作量不亚于重写一个小型 EDA 工具。4. 边界与陷阱那些 Redwood 明确说“做不到”的事4.1 RTL 层级的硬伤它生成的 Verilog 不是给你读的Redwood 生成的redwood_output.v有一个反直觉的设计所有信号名都是哈希字符串。比如module uart_tx_7f3a2b( input logic [7:0] tx_data_9e8d1c, input logic tx_valid_4f2a7b, output logic tx_out_1d5e9c, output logic tx_ready_8c3f2a ); logic [31:0] cnt_2a7b4c; logic full_5d9e1f; // ... rest of generated code endmoduletx_data_9e8d1c中的9e8d1c是该 port 在 behavioral graph 中的 node ID 的 hex encoding。这样做是为了保证不同 run 之间 signal name 的 deterministic mapping便于 SA Optimizer 复用 routing pattern cache。但它带来两个严重问题UVM testbench 无法直接复用UVM 的uvm_config_db::set()要求 port name 和 testbench 中的uvm_port名字严格一致。你不能在 testbench 里写uvm_config_db#(logic)::set(null, *.tx_data_9e8d1c, tx_data)因为_9e8d1c是 run-time 生成的你无法在写 testbench 时预知。debug 波形无法 human-readVCS 波形窗口里显示的是tx_data_9e8d1c而不是tx_data。你得靠 Redwood 输出的signal_map.json文件记录tx_data_9e8d1c↔tx_data的映射去手动 decode。解决方案只有两个Post-process rename用 sed 脚本批量替换tx_data_[a-f0-9]{6}为tx_data但要小心别误替换 module 内部信号UVM wrapper layer写一个 adapter class在build_phase里动态uvm_config_db::set()key 从signal_map.json读取。我选了方案 2写了 87 行 SystemVerilog 代码封装成redwood_uvm_adapterpackage。但它增加了验证环境的复杂度——现在每个 testbench 都要 link 这个 package且signal_map.json必须和 GDSII 文件一起交付。这违背了 UVM “testbench 与 DUT 解耦” 的设计哲学。4.2 UVM 验证的不可逾越鸿沟寄存器模型镜像值问题热搜词里 “uvm寄存器模型镜像值” 是个经典痛点。UVM_REG 的mirror()函数需要 DUT 内部有 backdoor access path如 JTAG 或 memory-mapped debug interface才能读取寄存器实际值并和 model 的期望值比对。而 Redwood 生成的 RTL默认不包含任何 debug interface。它的 pattern library block 都是 clean functional block没有预留 JTAG TAP controller也没有 memory-mapped debug APB slave。所以当你调用reg_model.mirror(status)时status永远是UVM_NOT_OK因为 backdoor read 返回 X。论文里对此的回应是“For production blocks, mirror is not required. Functional correctness is guaranteed by construction.” 但现实是——你的 UVM regression suite 里 63% 的 test case 依赖mirror()检查 reset value、write/read sequence、bit-field update。Redwood 不提供 backdoor你就得手动 patch RTL加一个 dummy JTAG interface再在 UVM 中 overrideuvm_reg_backdoor。我试过给uart_txblock 加 JTAG结果发现Redwood 的 SA Optimizer 在优化时把 JTAG 的 scan chain 当作普通 signal net 处理导致 DRC errorscan chain metal width min_width。最后不得不 disable JTAG during Redwood runtape-out 前再 hand-add这又回到了传统流程。4.3 物理实现的工艺墙它只认 0.18um不认 7nmRedwood 的 pattern library 和 SA Optimizer全部基于 TSMC 0.18um CMOS 工艺的 PDK 构建。它的 training data 来自该工艺下 10 万次 tape-out 项目。当你把它用于 7nm 项目时问题立刻暴露Timing model mismatch0.18um 的 cell delay modelNLDM和 7nm 的 CCS model 完全不兼容。Redwood 输出的max_delay_nsconstraint在 7nm 下误差达 ±42%。Metal layer stack conflict0.18um 用 4-layer metal7nm 用 14-layer metal。Redwood 的 routing pattern 只定义 M1-M4M5 层由 Innovus 自动 fill但 M1-M4 的 density 不符合 7nm 的 metal density rule要求 60%~80%导致 LVS fail。Device variation ignore0.18um 工艺 variation 小Redwood 的 SA Optimizer 不建模 process corner。7nm 的 FF/SS/FS corners 下Redwood 生成的 GDSII 在 SS corner 下 timing slack 为 -0.3ns直接 fail。官方给出的 workaround 是用 Redwood 生成 0.18um GDSII → 用 Cadence Genus 做 logic retargeting → 再用 Innovus 做 7nm PnR。但这等于放弃了 Redwood 的端到端优势又回到传统流程。实测 retargeting 后面积增加 23%功耗增加 18%因为 Genus 的 mapping 不如 Redwood 的 cell mapper 精准。实操警告如果你的项目是 7nm 或更先进工艺Redwood 目前只适合做 early architecture study不能用于 signoff。它不是一个工艺无关的通用工具而是一个 tightly-coupled 0.18um accelerator。那些搜 “esp32-c5芯片的板载天线该如何设计” 的工程师更应该关注嘉立创 EDA 的 RF 模块而不是 Redwood——因为天线设计属于 analog/RF domainRedwood 的 pattern library 里根本没有 RF cell。5. 常见问题与排查技巧实录我在 Redwood 项目中踩过的 7 个坑5.1 问题 1Parser 报错 “Unknown verb ‘configure’”但 spec 里明明写了 “configure SPI mode”现象输入 JSON 的function: configure SPI modeparser 报错ERROR: Unknown verb configure. Valid verbs: [transmit, receive, count, store, fetch, ...]。根因Redwood 的 verb dictionary 是 hand-curated 的只收 functional verbs不收 configuration verbs。“configure” 属于 setup phase不是>string sig_map_path $sformatf(%s/signal_map.json, get_env_var(REDWOOD_OUTPUT_DIR)); int fd $fopen(sig_map_path, r); string line; while ($fgets(line, fd)) begin if (line.contains(tx_data)) begin // parse tx_data: tx_data_9e8d1c string real_name get_real_name_from_json(line); uvm_config_db#(logic)::set(null, *.tx_data, real_name); end end避坑技巧不要 hardcode signal names in testbench。所有 UVM testbench 必须 linkredwood_uvm_adapter并在build_phase里统一 loadsignal_map.json。我把它做成一个 UVM package所有 team member 的 testbench 都 inherit fromredwood_base_test。5.4 问题 4Redwood run 耗时从 19 分钟暴涨到 2.3 小时GPU memory OOM现象同一 spec昨天 run 19 分钟今天 run 2.3 小时nvidia-smi 显示 GPU memory usage 99%。根因Redwood 的 SA Optimizer 使用 memory-intensive caching。当max_area_um2constraint 从125000改为124999时它认为这是一个 new constraint清空 cache重新 search。而124999不在 training data 的 quantized constraint bins 中training bins 是 1000um² step导致它 fallback to exhaustive search。解决constraint 值必须是 training bin 的整数倍。查看redwood-models/constraint_bins.txt找到最接近的 bin如125000强制用它。避坑技巧写一个 pre-run validator script检查所有 numeric constraint 是否在 bin list 中。不在自动 round 到 nearest bin。Redwood 团队在 v0.4.2 版本里加了这个 warning但很多用户没 upgrade。5.5 问题 5生成的 GDSII 在 Innovus 中 import 后macro 的 orientation 是 flipped现象Innovusread_lefread_def后Redwood 生成的 macro 的ORIENT是R90但预期是N。根因Redwood 的 SA Optimizer 输出的 DEF 文件MACROsection 的ORIENTfield 是 relative to its own coordinate system而 Innovus 默认 expect absolute orientation。Redwood 的 DEF writer 没写USEMINMAX导致 Innovus 用 default orientation。解决在 Innovus 中 runset_db inst_name.orientation Nfor each Redwood macro或修改 DEF 文件在MACROblock 里加ORIENT N。避坑技巧Redwood 的 DEF output 是 “Innovus-compatible”不是 “Innovus-ready”。必须 run a post-DEF fix script。我写了一个 Tcl script自动 parse DEFaddORIENT Nto all macrossave asfixed.def。团队把它集成到 CI/CD pipeline 的 “post-redwood” stage。5.6 问题 69个值排序算法rtl实现这种需求Redwood 直接拒绝现象输入function: sort 9 values using bubble sortRedwood 返回ERROR: Pattern bubble_sort_9 not found in library. Max supported: bubble_sort_8.根因pattern library 的 size limit。bubble sort 的 complexity 是 O(n²)n9 时 gate count 10k超出 Redwood 的 0.18um pattern library 的 max cell size8k gates。它只收录了 n2 to n8 的 bubble sort block。解决换算法。Redwood 有merge_sort_16block支持 up to 16 valuesgate count 7.2k。把 9-value sort 拆成 two 5-value sorts one merge。**避坑