做FPGA的人应该都遇到过这种场景：项目里要放一块ROM或者RAM，数据只有几百甚至几十个字节，只是为了存一份查找表、一组系数、或者一段上电后要用的配置。与其打开厂商的Memory IP向导去点端口、配时钟、选位宽，我更习惯直接写一个普通的内存数组，再用$readmemb、$readmemh这类系统任务，把外部.txt文件灌进数组里。这样做出来的“非IP核”ROM/RAM，既能在仿真里按照预期工作，也能在综合时被常规流程识别成存储单元，工程换芯片平台也不需要重新生成任何东西。
这篇文章就把这套玩法从原理到实操完整捋一遍：语法怎么写、.txt数据文件怎么组织、哪些坑会让人在仿真里对着红色波形发呆，以及如何用最少代码把初始化这件事做得稳定可复用。
1. 为什么用普通数组做ROM/RAM，而不是现成的存储IP
1.1 “非IP核”指的是什么，适合哪些场景
先解释一下题目里“非IP核”的含义。它不是说不用厂商提供的任何模块，而是指：ROM/RAM本身是通过标准的Verilog数组声明和读写逻辑写出来的，没有生成加密模型、没有额外的BBox约束、没有那套依赖特定工具链的工程文件。
常见写法是声明一个二维数组：
reg [7:0] rom_mem [0:255]; reg [7:0] ram_mem [0:1023];[7:0]是数据位宽，[0:255]是深度，也就是一共有256个地址。后面配合initial块和系统任务，就能把外部数据加载进去。
我还记得第一次用IP核做小容量ROM的体验：为了放一张64×16的sin查找表，生成过程选了两页参数，最后工程里多出一堆仿真模型、综合约束和奇怪的封装文件。更麻烦的是，换另一家FPGA又要从头生成一遍。后来我把这块查找表换成纯用代码写出来，工程瞬间清爽，位宽和深度改动也就改个参数的事。
所以这套做法最适合的场景是：
- 容量不大的查表类ROM，比如查找表、滤波系数、CRC表、字模点阵。
- 需要跟着RTL一起走版本管理、跨平台复用的小型存储。
- 做通用验证环境时，想要内存内容可控、可快速刷新。
- 希望在ASIC仿真阶段用同一种数据初始化方式验证逻辑，而不是依赖带初始化特性的厂商RAM模型。
1.2 相比IP核，用代码数组的优势到底在哪
先说可移植性。纯RTL的内存数组，任何一个支持Verilog-2001的工具都能读。不管是FPGA综合还是ASIC仿真，只要你把.txt文件放在正确路径下，行为就是一致的。这一点在团队协作时特别重要：同事拿你的RTL和一组数据文件，就能原样复现内存内容。
其次是灵敏度。用$readmemb加载数据时，数据文件和RTL完全解耦。你要换一组系数，只需要改.txt，不需要重新生成IP、不需要重新配置接口、不需要重新跑一次GUI流程。
再有就是位级可控性。二进制格式支持x和z状态，这在验证中非常有用。比如你想模拟某块内存上电后部分单元弱态或未定义，直接在数据文件里写x就行，IP核反而很难做到这么精细。
当然，不是说要否定IP核。容量大、要求特殊硬件特性的情况，比如真正的双口RAM、带有错误校验、需要底层原语级优化，那么IP核仍然有优势。我这里强调的是小容量、以初始化内容为主的场景，用代码数组确实更轻、更灵活。
1.3 这套方案的基本逻辑和适用范围
核心逻辑可以拆成三步：
- 在RTL里声明一个二维数组，代表存储实体。
- 用
initial块调用$readmemb或$readmemh，把.txt文件内容按地址顺序写入数组。 - 用
always块按需读写这个数组，ROM只读，RAM正常读写。
整个过程完全不依赖任何厂商的存储IP。只要工具支持$readmemb和$readmemh系统任务——基本上所有主流仿真器和综合工具都支持——就能跑通。
需要提前知道的是：综合阶段的行为和仿真阶段会有差异，后面第3章会专门讲。如果只是做仿真验证，那这方案几乎没有坑；如果要做FPGA综合上板，就要确认综合工具是否能识别initial块中的内存初始化。多数FPGA工具链是支持的，但不同工具对“大容量数组”的推断策略不一样，这需要用实际工程去验证。
2.$readmemb和$readmemh的语法、文件格式与初始化原理
2.1 两个系统任务的基础语法
$readmemb是“读二进制文件”的内存初始化任务，$readmemh是“读十六进制文件”的内存初始化任务。它们的语法一致，只是数据文件的数值基不同。
最基本的形式：
initial $readmemb("init.bin", mem_array); initial $readmemh("init.hex", mem_array);带地址范围的形式：
initial $readmemb("init.bin", mem_array, START_ADDR, END_ADDR); initial $readmemb("init.bin", mem_array, 16); initial $readmemh("init.hex", mem_array, 16, 255);注意参数顺序是：文件名、内存数组名、起始地址、结束地址。起始地址和结束地址不是Verilog数组下标，而是“内存的地地址范围”，这个细节很多初学者会混。
如果省略起始地址，默认从数组的左侧索引开始读入；如果省略结束地址，默认一直读到文件末尾或数组末尾。更准确地说，数据是按地址从低到高逐个存入的，而“低地址”对应数组声明时的左侧索引。
举个例子：
reg [7:0] mem [0:15]; // 地址从0到15 initial $readmemb("data.txt", mem);这个初始化会把data.txt里的第一行数据写入mem[0]，第二行写入mem[1]，以此类推。注意，即使你声明[15:0]的倒序数组，$readmemb仍从索引15开始写入第一行数据，而不是从0开始。这一点很容易导致读出来的内容和地址对不上，我在第4章会展开说。
2.2.txt数据文件的组织规则
不管文件名后缀是.mem、.dat还是.txt，系统任务解析的都是纯文本文件。二进制模式下，文件每行代表一个内存单元的数据，允许出现0、1、x、z以及下划线。十六进制模式下，允许出现0-F、x、z以及下划线。
举个例子，二进制数据文件：
1010_1010 0011_1100 0000_0001对应三个8位单元的初始化数据：0xAA、0x3C、0x01。下划线只是方便阅读，会被当作分隔符忽略，不影响实际数值。
十六进制数据文件：
a5 5a ff 00对应四个8位单元的初始化数据：0xA5、0x5A、0xFF、0x00。
文件里还可以写“地址指示符”，以@开头，作用是跳过某些地址。比如：
@10 ff 00表示先跳到地址10，写入0xFF，紧接着地址11写入0x00。地址指示符在当前地址的基础上继续，不会自动回到0，除非文件里再次出现相对偏移或你重新指定地址。
还有一点：文件里允许空行和注释吗？严格来说，系统任务会忽略空白字符和制表符，注释行为取决于仿真器的实现。多数仿真器支持//和/* */风格的注释，但为了稳妥起见，我建议保持文件“干干净净”，不要在里面写注释。原因很简单：仿真器对注释支持不统一，你在一家仿真器里能过，换到另一家可能就会因为注释导致解析错误，或者把注释当数据读进去。
2.3 数据位宽、地址深度和默认值的关系
这是非常关键的一环。$readmemb读取的数据，如果位数不足内存数据位宽，左侧会补零。
比如你声明的是reg [7:0] mem [0:31];，而文件里写的是：
101读到mem[0]时会得到0000_0101，也就是0x05。这一点在维护数据文件时要心里有数：不要以为少了高位就一定是报错，它只是默默补零而已。
反过来，如果数据行的位数超过数据位宽，多余的最高位会被截掉。这意味着：
reg [3:0] mem [0:3]; // 文件：1111_1010 // mem[0] = 1010高位111被丢弃，你其实存进去的是1010。如果不小心把宽数据文件用到窄内存上，丢失的是高位信息，而不是报错。这类错误在排查时很隐蔽，因为仿真不会崩，只是数值不对。
如果文件里某行只有x或z，存储单元相应位也是x或z。这对于仿真验证很友好，你想测复位、上电不确定态，直接写文件就可以。
最后要强调默认值。如果.txt文件的数据不足内存深度，比如内存深度为256，但文件里只有100行，那么没有被文件覆盖的地址，初始化后默认值是x（Verilog数组初值）。在仿真里，读到这些x地址，波形会显示出红色或紫色未知态，容易引发连锁的X传播问题。解决办法有两个：
- 保证文件行数等于内存深度。
- 初始化时显式用
for循环或默认赋初值方式先把整个数组写一遍，让未覆盖部分至少有确定值。
第二种做法其实很常用，后面第3章会给出代码。
2.4 关于综合阶段的行为差异
需要提前讲清楚：initial块在仿真里肯定会被执行，但在综合阶段，不同工具的行为不完全一样。对于那些支持“寄存器初始值”或“片上存储初始化”的FPGA工具链，initial块中的$readmemb通常会被解读为存储器的初始化内容，写入配置比特流。但如果是ASIC综合，工具往往直接忽略这些initial块，因为ASIC存储器没有全局初始化能力，内存上电后内容不确定，必须由复位逻辑或加载逻辑来写入。
所以如果目标是纯仿真或用FPGA做原型验证，方案没有问题。但如果是用这套RTL去综合ASIC，就要把内存初始化改成“复位后从外部接口加载”，或者考虑使用集成RAM编译器生成的带初始化功能的存储单元。这个区分很重要，我在第4章还会再说一次。
3. 实操过程：从RTL声明到完整工程例化
3.1 内存数组的声明方式与端口设计
先给一个完整可用的ROM例子。这是一个同步读ROM，项目里最常见的形式：给定地址，下一个时钟沿输出数据。
module lut_rom #( parameter DATA_W = 8, parameter DEPTH = 256, parameter ADDR_W = 8 )( input wire clk, input wire [ADDR_W-1:0] addr, output reg [DATA_W-1:0] dout ); reg [DATA_W-1:0] mem [0:DEPTH-1]; initial $readmemb("lut_data.txt", mem); always @(posedge clk) begin dout <= mem[addr]; end endmodule这个写法有几点值得说。第一，数组用了[0:DEPTH-1]的递增索引，这样$readmemb的第一个数据就正好落在mem[0]，地址和文件行是一一对应的，最不容易出错。第二，用参数化定义位宽和深度，改内存大小只需要改参数，数据文件行数和地址位宽按参数同步修改就行。第三，读取用了寄存器输出，这是可综合的推荐写法，时序上更干净，不会出现组合逻辑的毛刺。
如果你想要组合读ROM，也就是地址一变立刻输出变化，那就用：
assign dout = mem[addr];但这种写法在FPGA里通常会被综合工具映射到LUT逻辑而不是块RAM，资源使用不够优化。做小容量查表表可以用，但大容量不建议。
3.2 在initial块中做初始化，同时给默认值
多数情况下，文件数据能正好填满内存。但为了防止文件不完整导致x状态蔓延，我习惯在$readmemb之前先给整个数组赋一个确定初值：
integer i; initial begin for (i = 0; i < DEPTH; i = i + 1) begin mem[i] = {DATA_W{1'b0}}; end $readmemb("lut_data.txt", mem); end注意这里用了integer型循环变量，配合initial块里的for循环，是可综合的固定次数循环。仿真时它会先清零数组，再读文件，文件覆盖到的部分用文件值，没覆盖到的部分是0而不是x。
有的工程师会反着写，先$readmemb再给0，那就错了，等于用后面的清零把文件内容全盖掉了。
另外一点，如果文件本身可能缺失，$readmemb执行时仿真器会给出类似warning: file not found的提示，然后跳过初始化。如果没有先清零数组，此时内存全是x，后续仿真基本没法看。先清零这个习惯能帮你把“文件路径错误”这类问题在仿真一开始就暴露出来，而不是等波形上一片红。
3.3 用同样的方式初始化RAM
RAM和ROM的区别在于RAM可以写。RAM初始化通常在测试上电阶段有意义，用来模拟某块内存已经预置了配置数据。一个单端口RAM的典型写法：
module ram_init #( parameter DATA_W = 8, parameter DEPTH = 128, parameter ADDR_W = 7 )( input wire clk, input wire we, input wire [ADDR_W-1:0] waddr, input wire [DATA_W-1:0] wdata, input wire [ADDR_W-1:0] raddr, output reg [DATA_W-1:0] rdata ); reg [DATA_W-1:0] mem [0:DEPTH-1]; integer i; initial begin for (i = 0; i < DEPTH; i = i + 1) begin mem[i] = {DATA_W{1'b0}}; end $readmemb("ram_init.txt", mem); end always @(posedge clk) begin if (we) mem[waddr] <= wdata; end always @(posedge clk) begin rdata <= mem[raddr]; end endmodule这个RAM是同步写、同步读。初始化完成后，如果后续有写操作，对应地址的内容就被正常写操作覆盖，这是符合预期的。注意，千万不要在一个always块里同时用阻塞赋值去初始化内存又用非阻塞赋值去做写入，那样最容易产生竞态和综合告警。
3.4 不同数据文件对综合结果的影响
实际综合时，如果用的FPGA工具支持initial内存初始化，它会自动把mem推断成带初始值的块RAM或分布式RAM。文件数据最终会变成比特流里的初始配置。这种基于代码数组的实现方式，在综合工具眼里和一个参数化配置的存储IP没什么本质区别。
但如果你用一个非常大的.txt，比如深度上万，综合工具可能不会把它综合成块RAM，而是当成一堆逻辑门。这种情况跑仿真很顺利，一上板资源就爆了。解决办法是让综合工具明确知道这是存储单元，不同工具的做法不一样，有的需要加综合属性，有的需要把数组放到某个固定层次。通用建议是：在综合报告里检查“RAM/ROM资源占用”，如果显示为0，就要确认是不是被当成普通组合逻辑了。
对于RAM，还有一个常见坑：综合工具判断“能不能推断为RAM”的标准，是看你对这个数组的所有读写是否规范。如果数组被initial块之外的非同步逻辑乱读、被拆成多个位、被当普通变量用了，工具可能放弃RAM推断，退回成寄存器堆甚至一组触发器。
3.5 多个内存模块并存时的初始化组织
有时候一个工程里同时有几块ROM，比如一份状态转换表、一份CRC表、一份显示字模。给它们各写一个$readmemb问题不大，但要注意文件路径不要冲突。反正文件名不能重复，最好把数据文件按目录组织：
initial $readmemh("../../data/crc16_table.txt", crc_mem); initial $readmemh("../../data/ascii_rom.txt", font_mem);路径写法在不同仿真器里有细微差别。有的仿真器以“仿真运行目录”为相对路径基准，有的以工程文件目录为基准。最稳妥的做法是在仿真脚本里统一用绝对路径或者统一的宏定义，避免不同同事的电脑上仿真结果不一致。
3.6 仿真测试平台里如何复用初始化结果
如果你只是在测试平台里给一块存储模型做初始化，那更简单：
reg [7:0] test_mem [0:15]; initial $readmemh("test_vector.txt", test_mem);这比在RTL里初始化更灵活，因为测试平台里的初始化不会影响综合。做验证时，我经常用同一份数据文件分别初始化RTL里的ROM和测试平台的期望数组，再用比对的方式判断输出对不对，省去了手工算结果的麻烦。
4. 常见问题与排查技巧实录
4.1 内存内容全部是x，或者初始化为0
这个问题几乎每个人都会遇到。内存内容全x，最常见的原因是文件路径不对或者文件内容为空。仿真器直接跳过初始化。全0则可能是因为清零循环放在了$readmemb后面，把文件数据盖掉了。
排查方法很简单：在initial块里加上$display打印几个关键位置的数值：
initial begin $readmemh("data.txt", mem); $display("mem[0]=%h, mem[1]=%h, mem[255]=%h", mem[0], mem[1], mem[255]); end如果打印出来是x或不合理值，十有八九是文件读取异常或数据格式错误。
4.2 数据行的位数与内存位宽不匹配
文件里一行数据少了一位，仿真器不会报错，只会左侧补零。比如你要做的是8位宽内存，文件里一行却是1_1010这样5位，你会得到0001_1010，而不是报错提示“宽度不够”。这类问题在单纯仿真时不明显，但一旦和预期值比对，就全是地址对不上。
反过来，数据行超过位宽，高位被截断，也会导致数据错。我的习惯是：写文件前先确认位宽，然后在每行都用和位宽一致的位数，比如8位宽就写满8位，16位宽就写满16位，不要偷懒省略前导0。
4.3 数组声明方向带来的地址颠倒
假设你声明：
reg [7:0] mem [255:0];然后$readmemb("data.txt", mem)，第一行数据写入的是mem[255]而不是mem[0]。这在仿真上没有问题，但如果你在测试平台里按mem[0]去索引，就会读到文件最后一行。很多项目就是因为有人习惯[255:0]声明，有人习惯[0:255]声明，导致集成时数据全乱。
建议统一使用[0:DEPTH-1]，放弃CPU编程里那种“高位在前面”的习惯。Verilog的声明方向没有好坏，但一致性就是生产力。
4.4 初始化在综合时不起作用
如果你在FPGA上跑的结果和仿真不一致，优先怀疑综合工具没有识别初始化。识别不出来的表现是：上电后RAM/ROM内容可能与期望不符，或者综合报告里那块内存显示为不具初始化能力。
要解决的思路一般是：
- 确认工具支持
initial块初始化内存。 - 确认数组被综合成了存储单元而不是普通逻辑。
- 检查综合日志里有没有关于“初始化被忽略”的提示。
- 如果工具需要专用属性或专门的数据文件格式，就按它的格式补充一个替代文件。
不同工具差异很大，但流程都是这么几条。不要强行在RTL里绕弯子，先看综合报告怎么说。
4.5 数据文件过大或过大导致仿真卡顿
当内存深度达到几万甚至几十万时，initial块逐行执行$readmemb在仿真效率上会有一定开销。虽然比直接在initial里逐行赋值快得多，但仍可能出现加载时间较长的情况。
如果性能成为问题，可以考虑：
- 用十六进制格式
$readmemh而不是二进制，文件体积更小。 - 减少仿真中的无谓初始化，比如只在复位阶段需要的数据才初始化。
- 对于验证场景，可以把大块RAM初始化放到测试平台的
initial里，因为测试平台不影响综合。
还有一点，不要在一个initial块里连续调用同一个$readmemb去加载同一个数组两次。你没有数据要更新的话，第二次调用纯属浪费，而且如果文件变了，两次之间会存在一个窗口期，数组处于半新半旧状态。
4.6 数据文件的注释和编码问题
有些编辑器会在保存.txt时加上BOM头，或者用UTF-8带BOM格式。仿真器解析时可能把BOM字符当作数据的一部分，导致第一行数值异常。这个问题看似离谱，实际遇到不止一次。排查时如果发现“文件第一行永远不对、后面都对”，可以考虑是不是BOM问题。
解决办法很简单：保存为纯ASCII文本，或者去掉BOM。最好在脚本里自动生成数据文件，保证编码统一。
4.7 故障排查速查表
| 现象 | 可能原因 | 优先检查项 |
|---|---|---|
| 所有内存值都是x | 文件未找到、文件为空 | 路径、文件权限、仿真运行目录 |
| 内存前部x，后部正常 | 文件行数少于深度 | 文件行数、数组清零循环 |
| 第一行数据异常 | BOM头、注释字符被解析 | 文件编码、数据格式 |
| 地址全部错位 | 数组声明方向不一致 | [0:N-1]vs[N-1:0] |
| 上电结果和仿真不一致 | 综合不支持初始化 | 综合报告、综合属性 |
| 数据位异常、高位丢失 | 数据位数超过位宽 | 文件行数据长度 |
| 仿真卡顿严重 | 文件过大、内存过深 | 改用十六进制、减少初始化范围 |
5. 提高初始化效率的细节与扩展用法
5.1 用脚本批量生成数据文件
手工维护几十行数据可以，上千行数据就必须用脚本。我常用某文本处理脚本生成数据文件：从参数表、算法公式或外部配置文件里提取数据，格式化后输出成.txt。
比如生成一个正弦查找表：
import math with open("sin_table.txt", "w") as f: for i in range(256): val = round(math.sin(2 * math.pi * i / 256) * 127) f.write(format(val & 0xFF, "08b") + "\n")生成的文本文件里每行都是8位二进制数，正好能被$readmemb直接读取。如果你用$readmemh，就改成format(val, "X")之类。
脚本生成的好处是：数据逻辑清晰、格式可控、可以自动检查位宽和深度。把脚本放在工程目录下的工具目录里，别人拿到你的工程也能随时重新生成数据。
5.2 用$readmemh还是$readmemb
我的选择标准很简单：如果数据要跨工具、跨芯片流传，用十六进制；如果数据要和位级状态严格对照，比如某几个位是x或z，用二进制。
十六进制文件更适合人眼排查，FF、A5一眼就能看懂。二进制文件在处理位翻转、特定位掩码时更直观。两者都能被综合工具接受，但如果你想让文件和常用的十六进制编辑器、逻辑分析仪格式兼容，建议用$readmemh。
5.3 通过宏或参数控制初始化路径
有时候整个项目会有“用A数据版本”和“用B数据版本”的需求，比如两套系数、两份不同的配置表。我不建议改RTL代码里的文件名，而是用宏定义或仿真脚本去控制。
在RTL里：
`ifdef USE_A_VERSION initial $readmemh("../../data/version_a.txt", mem); `else initial $readmemh("../../data/version_b.txt", mem); `endif或者在仿真脚本里用-define指定宏。这样不需要动RTL，只需要换一个编译选项，就能切换数据版本，对回归验证特别友好。
5.4 在仿真中间重新加载内存
$readmemb不只在initial块里能用，你可以在测试平台的任意时间点再次调用，实现“运行时重载”。比如测试某种场景切换：
task load_memory; input [31:0] addr_start; begin mem[addr_start] = 8'h00; // do something end endtask更常见的用法是在两个测试用例之间重新加载ROM或RAM。但注意，如果在RTL模块的initial块里执行，重新加载会影响综合后的行为。如果只是仿真需要，最好在测试平台里操作，或者通过层次引用访问RTL里的内存数组：
$readmemh("new_data.txt", dut.ram.mem);层次引用在仿真里很好用，但换工具时层次路径可能不一样，所以用在测试平台里时最好也用宏或者参数控制，避免一处改动到处改。
5.5 在ASIC仿真中提前预置内存内容
前面说过，ASIC综合不认initial初始化，但ASIC仿真阶段完全可以靠$readmemb在测试平台里预置内存内容。很多团队会把“内存初始化”放在RTL里，但它实际上只做到仿真层。要搞清楚一条准则：**RTL里写不写initial初始化，取决于你最终交付的是FPGA比特流还是ASIC网表。**FPGA可以用，ASIC不行。
如果项目既要FPGA原型验证又要ASIC后端，我会把初始化文件和数据文件都放到同一层次，在FPGA流程里用$readmemb，在ASIC验证里靠测试平台用层次引用来加载。这样RTL主体不携带只在FPGA阶段有用的初始逻辑，后端也不会有意外的综合行为。
6. 个人经验总结
这套用$readmemb初始化非IP核ROM/RAM的做法，我在好几个项目里反复用。印象最深的一次是准备一个跨多平台的仿真环境，内存表的更新频率很高，每天要换两版数据。用IP核时每次都要重新生成记忆体模型，整个编译流程慢了不少。换成$readmemb加纯RTL数组之后，每天只改数据文件，编译时间基本没变化，不同芯片平台的综合结果也都正常。
再提一个实用小技巧：在文件路径上，我习惯用相对路径统一管理，但会在所有的$readmemb调用上加注释标明“以仿真工程目录为基础”。如果团队协作，就在仿真脚本里统一指定工作目录，这样无论谁跑仿真，都能正确读到数据文件。
最后，初始化数据文件最好和RTL一起放进版本管理，不要只存在某个人本机。否则你改了文件没提交，别人拉下去仿真怎么都跑不出对的结果，那才是最浪费时间的事。以上这些经验，与其说是技術难点，倒不如说都是“做过一遍就会背”的细节。希望这篇文章能帮你少走几步弯路，一次就把ROM/RAM初始化这件事做稳。
