"内存编译器"的真正含义：从位单元到GDS拼接

# “Memory Compiler” 的真正含义：从位单元到 GDS 拼接 | The Cloudlet 来源：https://thecloudlet.github.io/technical/compiler/memory-compiler/ 2026年5月29日 \[编译器设计 (https://thecloudlet.github.io/categories/compiler-design/)\] \#内存编译器 (https://thecloudlet.github.io/tags/memory-compiler/)\#SRAM (https://thecloudlet.github.io/tags/sram/)\#EDA (https://thecloudlet.github.io/tags/eda/)\#版图 vs 原理图 (https://thecloudlet.github.io/tags/layout-vs-schematic/)\#拼接 (https://thecloudlet.github.io/tags/tiling/)> 大多数人看到“Memory Compiler”这个名字，根本不知道它到底是做什么的。 --- ## 1. 编译器的表示 经典的表示法是 **T 型图 (https://en.wikipedia.org/wiki/Tombstone_diagram)**（或称墓碑图）。它用三种语言来刻画一个编译器：它读取的源语言 (A)，它生成的目标语言 (B)，以及它自身实现所用的语言 (C)： `` ┌───┬───┐ │ A → B │ └───┴───┘ │ C `` 解读为：“一个将 A 翻译为 B 的程序，用 C 语言编写。” 教科书中的例子是 C → 机器码。但它的定义远比这个广泛： - 典型编译器：C / C++ → 汇编 / 机器码 - 我在 Synopsys 开发的编译器：VHDL / Verilog RTL → 仿真 / 调试数据库 - **Memory Compiler**：设计参数（深度、宽度、端口数……）→ 流片所需的所有视图 - 着色器编译器：GLSL / HLSL → GPU 机器码（例如 Mesa 的 NIR 管道、DXC） - 查询编译器：SQL → 物理执行计划（例如 PostgreSQL 的计划器/执行器） - 字节码编译器：Java 源码 → JVM 字节码 (javac)，或 JavaScript → V8 字节码 (Ignition) --- ## 2. 原材料：位单元内部 任何 **SRAM (静态随机存取存储器) (https://en.wikipedia.org/wiki/Static_random-access_memory)** 的基本构建模块是 **位单元 (bitcell)** —— 一个保存一个比特的小型电路。硬件团队会手工设计和表征这些单元；Memory Compiler 的工作就是将它们大规模复制。 最常见的变体是 **6T 位单元**（六个晶体管）。三条信号线将其与外界相连：`WL`（字线 —— 选择一行）、`BL`（位线）和 `BLB`（位线反，互补信号）： `` WL ══════════════════╦══════════════════════════════╦════════ ║ ║ ┌─────╫──────────────────────────────╫─────┐ │ [ M5 ] [ M6 ] │ │ │ │ │ BL ──┼─────●───── Q Q' ─────●─────┼── BLB │ │ │ │ │ │ ┌───────┐ │ │ │ ├─►─┤ INV_R ├───┤ │ │ │ │(M2,M4)│ │ │ │ │ └───────┘ │ │ │ │ │ │ │ │ ┌───────┐ │ │ │ ├───┤ INV_L ├─◄─┤ │ │ │ │(M1,M3)│ │ │ │ │ └───────┘ │ │ │ │ │ 位单元 (6T) │ └──────────────────────────────────────────┘ `` 晶体管数量： - `INV_L`：PMOS M3 + NMOS M1 = 2 - `INV_R`：PMOS M4 + NMOS M2 = 2 - 存取晶体管：M5, M6 = 2 - 总共：6 → “6T” ### 正反馈：比特如何被锁定 两个反相器首尾相连（**交叉耦合**）： 1. 假设 `Q` = 1（高电平，`Vdd`） 2. `INV_R` 接收 1，输出 0 到 `Q'` 3. `INV_L` 接收 0，输出 1 回到 `Q` 4. `Q` 保持 1 —— 一个完美的闭环 这就是 **正反馈 + 双稳态**。只要 `Vdd` 存在，`Q` 和 `Q'` 就会无限期地锁定在相反电压上。存储的比特实际上就是那两个节点上的电压。SRAM 之所以称为“静态”，是因为 —— 与 DRAM 不同 —— 它永远不需要刷新。 ### 三种操作 #### 保持（待机） - `WL` = 0，存取晶体管关断 - 交叉耦合反相器完全自行维持状态；只有漏电流流过 - 严格来说，保持是一种*状态*，而非操作 —— 但数据手册会将其与读/写并列列出，因为设计人员需要漏电流数据来进行功耗预算 #### 读 1. 将 `BL` 和 `BLB` 预充电到 Vdd 2. 将 `WL` 拉高；M5 和 M6 导通 3. 存储 0 的那一侧将其位线拉低约 100 mV 4. 感测放大器放大微小的差分信号 → 输出 1 位 **读干扰**：在 `WL` 导通的瞬间，高电压的 `BLB` 可能通过 M6 轻微拉高 Q'（存储 0 的节点）。如果它上升超过 `INV_L` 的开关阈值，单元就会翻转 —— 这称为**破坏性读**。解决方法是让下拉 NMOS M2 比存取晶体管 M6 更强（更宽）。这个强度比称为 **β 比 (Beta Ratio)**（β = W_下拉 / W_存取），通常要求大于 1。这就是为什么标准位单元中的六个晶体管并不都是相同尺寸。 #### 写 1. 写驱动器强制 `BL` 和 `BLB` 达到目标值（一个高，一个低） 2. 将 `WL` 拉高 3. 写驱动器的强度超过单元的上拉能力 → 强制单元翻转 4. 这些力之间的尺寸权衡称为 **上拉比** ### 超越 6T：其他位单元类型 6T 并非唯一选择。不同的使用场景需要不同的权衡： | 单元 | 晶体管 | 关键特性 | 典型用途 | |------|--------|----------|----------| | 6T | 6 | 高密度，标准读/写 | L2/L3 缓存 | | 8T | 8 | 隔离读端口，无读干扰 | L1 缓存，寄存器文件 | | 10T | 10 | 超低电压操作 | 近阈值设计 | 8T 单元增加了一个专用的读路径（两个额外的晶体管），因此读操作永远不会触及存储节点 —— 完全消除读干扰，代价是面积增加约 33%。 --- ## 3. 为什么需要 Memory Compiler 当硬件团队设计 **SoC (片上系统) (https://en.wikipedia.org/wiki/System_on_a_chip)** 时，他们需要 SRAM —— 大量的 SRAM，而且尺寸各异。他们工作的基本单元是 **单元 (cell)**：SRAM 阵列的最小可验证构建块。但一颗芯片可能在一个地方需要深度 512 × 宽度 32 的 SRAM，在另一个地方需要深度 4096 × 宽度 64。为每种配置从头重新设计一个新单元是不可行的。 解决方案是 **参数化 IP**：你不再交付一个固定设计，而是交付一个接受参数并自动生成正确实现的工具。这个工具就是 Memory Compiler。给定深度、宽度、端口数量以及一些其他旋钮，它会产生一个完整的、可流片的 SRAM 宏单元。 一个 Memory Compiler 生成一个完整的、自包含的 SRAM 宏单元 —— 位单元阵列以及操作所需的所有外围电路：行/列译码器、感测放大器、写驱动器和自定时控制。它**不**生成的是内存控制器 —— 决定读/写什么、处理仲裁和 BIST 序列的系统级逻辑，它位于宏单元外部的 SoC RTL 中。 `` 叶单元视图 ┌──────────────────────────────┐ 生成视图 (来自硬件团队): │ Memory Compiler │ │ │ .gds / .oas (版图) ────────>│ │───> .gds / .oas .lef (抽象视图) ────>│ │───> .lef .cdl / .sp (网表) ────────>│ │───> .lib .lib (时序) ───────>│ │───> .v (Verilog) │ │───> .sp / .cdl 参数: │ │───> .cpf / .upf │ │───> .pat (ATPG/MBIST) depth ────────>│ │───> .pdf (数据手册) width ────────>│ │ port ────────>│ │ mux factor ────────>│ │ corner (PVT) ────────>│ │ └──────────────────────────────┘ `` ### 输出视图 | 视图 | 格式 | 用途 | |------|------|------| | 版图 | GDS (https://en.wikipedia.org/wiki/GDSII)/OASIS (https://en.wikipedia.org/wiki/Open_Artwork_System_Interchange_Standard) | 流片，送往晶圆厂 | | 抽象视图 | LEF (https://en.wikipedia.org/wiki/Library_Exchange_Format) | P&R (布局布线) (https://en.wikipedia.org/wiki/Place_and_route) —— 仅暴露引脚 + 阻挡层 | | 时序 | `.lib` (Liberty (https://en.wikipedia.org/wiki/Liberty_File_Format)) | STA (静态时序分析) (https://en.wikipedia.org/wiki/Static_timing_analysis) —— 建立/保持时间，访问时间 | | 行为级 | Verilog / SV | RTL 仿真 | | 网表 | SPICE / CDL (https://en.wikipedia.org/wiki/Circuit_description_language) | SPICE 仿真，LVS (版图 vs 原理图) (https://en.wikipedia.org/wiki/Layout_Versus_Schematic) | | 功耗 | `.lib` / CPF (https://en.wikipedia.org/wiki/Common_Power_Format) / UPF (https://en.wikipedia.org/wiki/Unified_Power_Format) | 功耗分析 | | 测试 | ATPG (https://en.wikipedia.org/wiki/Automatic_test_pattern_generation) / MBIST (https://en.wikipedia.org/wiki/Built-in_self-test) 模式 | DFT (可测试性设计) (https://en.wikipedia.org/wiki/Design_for_testing) / 制造测试 | --- ## 4. 两个团队，一个边界 Memory Compiler 位于两个工作完全不同的团队的交叉点。 ### 硬件团队：设计叶单元 硬件团队 —— 电路设计人员和版图工程师 —— 设计并验证 **叶单元 (leaf cell)**：最小的 SRAM 单元。设计一个单独的 6T 位单元涉及解决多个相互制约的约束： - 晶体管尺寸（β 比，上拉比）以平衡读稳定性与写能力 - 在工艺节点的设计规则下进行全定制版图 - 在所有 PVT 角点下进行表征（数十次 SPICE 仿真） - 签核：DRC (设计规则检查) (https://en.wikipedia.org/wiki/Design_rule_check)，LVS (版图 vs 原理图) (https://en.wikipedia.org/wiki/Layout_Versus_Schematic)，天线效应检查，电迁移 硬件团队交付一小套经过验证、手工精调的文件 —— GDS、CDL、LEF、`.lib` —— 用于那一个叶单元。**他们的工作在单单元边界结束。** ### CAD 团队：构建编译器 CAD 团队（或 Memory Compiler 团队）接手这些经过验证的叶单元，并构建将其缩放到任意尺寸的自动化工具。他们的工作是回答：给定一个单独工作时正确的叶单元，如何将其拼接成任意深度 × 宽度的阵列，同时保证： 1. **LVS 通过** —— GDS 和网表拼接必须完全匹配 2. **DRC 通过** —— 在每个工艺节点的设计规则下，拼接边界必须干净 3. **所有输出视图一致** —— `.lib` 时序模型、Verilog 行为模型、SPICE 网表和 GDS 都描述了相同的电路 ### 为什么不直接写一个脚本？ 基于脚本的流程（例如使用 Tcl 或 Python）是结构组装的常见初步方法。虽然在简单情况下功能正常，但随着复杂度的增加，它会出现特定的限制： | 问题 | 为什么脚本难以应对 | |------|-------------------| | 多种输出格式 | 每种格式有不同的拼接逻辑；手动保持同步容易出错 | | LVS 正确性 | 行编号差一个就会在数千条网线中默默地导致 LVS 不匹配 | | 新配置 | 添加新的 mux 比例或端口组合需要触及每种格式中的拼接逻辑 | | 回归安全性 | 没有共享的数据模型意味着 GDS 拼接中的修复不会自动传播到网表拼接 | | 位单元更换 | 更换叶单元需要找到每个格式脚本中所有硬编码的假设 | 最后一点值得强调。在基于脚本的流程中，位单元的几何和网表结构会泄漏到拼接逻辑中 —— 网线名称、晶体管数量、引脚位置都被硬编码。将 6T 单元换成 8T 单元，脚本会在多个位置同时崩溃，跨越多个文件，而且这种崩溃方式可能不会立即显现。 Memory Compiler 将位单元视图（GDS、CDL、`.lib`）视为**输入**，而不是代码中内置的假设。拼接引擎不知道也不关心单元内部是什么 —— 它只知道如何复制和连接它们。更换输入文件，每个输出格式都会自动更新。一致性是结构性的，而非手动维护的。 Memory Compiler 通过让**一个数据结构驱动所有发射器**来解决这个问题。拼接逻辑只运行一次；GDS、CDL、Verilog 和 `.lib` 都是派生输出。这与任何编译器的架构见解相同：将意图的表达与渲染它的多个后端分离。 --- ## 5. 参数空间 ### depth × width —— 阵列形状 `` <──── width = 32 bits ────> ┌──┬──┬──┬──┬──┬──┬──┬── ... ──┐ ↑ │ │ │ │ │ │ │ │ │ │ ├──┼──┼──┼──┼──┼──┼──┼── ... ──┤ │ │ │ │ │ │ │ │ │ │ depth = 1024 words ├──┼──┼──┼──┼──┼──┼──┼── ... ──┤ │ │ │ │ │ │ │ │ │ │ │ └──┴──┴──┴──┴──┴──┴──┴── ... ──┘ ↓ Total bits = 1024 × 32 = 32,768 bits `` ### port —— 独立访问通道 | 特性 | 1-Port (1P / 1RW) | Multi-Port (例如 2R1W) | |------|--------------------|-------------------------| | 地址总线 | 1 | 2+ (单独的读地址、写地址) | | 并发性 | 读**或**写 | 读**和**写同时进行 | | 位单元 | 标准 6T | 8T (隔离读端口) | | 面积 | 高密度 | ~1.5x–2.0x 惩罚 | | 应用 | L1/L2/L3 缓存 | CPU 寄存器文件、FIFO | 寄存器文件需要多端口阵列以防止流水线停顿。执行 `ADD R1, R2, R3` 需要在同时读取 R2 和 R3 的同时，将之前指令的结果写回 R1。1 端口 SRAM 强制串行执行，破坏流水线并发性。因此，寄存器文件承受 8T 的面积惩罚以维持吞吐量。 ### mux factor —— 列多路选择器比 感测放大器在面积上很昂贵。mux factor 决定有多少位列共享一个感测放大器： `` mux=1 (无 mux): mux=4: 每列一个 SA 每 4 列一个 SA ┌─┬─┬─┬─┐ ┌─┬─┬─┬─┐ │ │ │ │ │ │ │ │ │ │ SA SA SA SA └─┴─┴─┴─┘ SA 最快、最宽的布局 较慢、较窄的布局 // SA = Sense Amplifier: 检测 BL/BLB 上的微小电压差分 // 并将其放大到完整的逻辑电平 `` **一个容易忽略的点**：mux factor 不仅影响面积 —— 它直接影响延迟。每个用于选择哪一列连接到感测放大器的周期都是延迟。更高的 mux factor 意味着更长的位线、更大的电容和更慢的感测放大器使能。**缓存访问延迟的很大一部分隐藏在列 mux 内部** —— 这是 L1 微架构设计中的一级权衡旋钮，而不仅仅是版图的便利性。 ### corner —— PVT (工艺、电压、温度) `` 工艺: TT (典型), SS (慢), FF (快) 电压: 0.72V (低), 0.8V (标称), 0.88V (高) 温度: -40°C, 25°C, 125°C SS + 高温 + 低电压 → 最差情况时序 (建立时间检查) FF + 低温 + 高电压 → 最佳情况时序 (保持时间检查) `` `.lib` 文件为每个角点包含一个时序表。Memory Compiler 必须在每个角点下都通过静态时序分析 (STA)。 ### 整合起来：完整的阵列结构 `` BL_0 BL_1 BL_2 BL_3 BL_4 BL_5 BL_6 BL_7 │ │ │ │ │ │ │ │ addr[A-1:M] ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ (高位) ┌────────────────────────────────────────────────────┐ ┌───────┐ │ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ │ │ R │────►│ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ │◄─ WL_0 │ o │ │ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ │ │ w │────►│ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ │◄─ WL_1 │ │ │ ┌──┐