用ram实现寄存器堆_FPGA设计基础——RAM的应用（二）

上一篇文章介绍了RAM的基本特性(FPGA设计基础——RAM的应用(一))，本文接着介绍RAM的一些应用和注意事项。

(续)3、RAM的使用场景

场景1：表项

某设计输入的数据带一个8bit的user_id，指示该数据属于哪一个user，现在要求统计每个user收到的数据的个数，统计到1024*1024*1024即可，超过了统计计数器的最大值的话，可以翻转。

简单粗暴的方法，定义256个32bit的计数器，来一个数据后，先看user_id是多少，然后相应的计数器加1。如果user_id的不是8bit，是12bit，支持4K个user_id了？那这个方法可能就不好用了。即使是采用数组的方式，那也需要4K*30bit = 120K的reg，太浪费资源。

如下图所示，可以采用RAM来存放各个user_id的计数值，用user_id作为ram的地址，将各个user_id对应的计数值写入到RAM对应的地址中。每来一个数据，根据该数据的user_id读取ram中的值，然后将该值加1后再写回ram中。

场景2：缓存buffer

在报文处理中经常也会用ram来作为缓存。比如在报文的结尾处用1个bit指示该报文是一个正常的报文还是有错误的报文。如果是正常的报文，就写入缓存中然后发送给后级模块，如果是错误的报文，需要丢弃。

如上图所示：假如一个报文写入的地址空间是从地址1——地址100，如果是一个正常的报文，那么读逻辑就从地址1开始读取报文后发送给后级模块。如果不是一个正确的报文，常见的做法就是，将写地址的值从101跳回到1，即下次来一个报文后，把原来的报文覆盖，从而实现对错误报文的丢弃。

还有一种场景就是纯的数据buffer，在这种场景下，笔者建议使用FIFO更加方便，当然这个也看个人使用习惯，无论是FIFO或者RAM都能起到相同的效果。

当然，使用ram的地方还有很多很多，上面的2个例子，只是最基本的场景。了解前面ram的基本特性后，那么在其他场景下使用ram也必然游刃有余。

4、RAM使用的注意事项

(1)、性能

前面已经详细的说明了影响性能的相关因素，这里再列出来想强调的是，RAM的输入输出一定要通过寄存器，记住这点，性能上不会有太大问题。

(2)、资源

实际在项目中，我们需要弄清楚2个问题，方案设计上需要多大的buffer？这么大的buffer需要多少块RAM？后一个问题前面已经详细说明了，前一个问题就只需要注意一点：别溢出了。写的时候控制好地址和使能信号，保证不翻转，读的时候先写后读。

(3)、校验

FPGA中的RAM存在一定的软失效或者器件故障(reg和LUT也一样)，对于可靠性要求不严格的场景，不需要对RAM中的数据进行校验。而对可靠性要求非常高的场景，就需要校验了。

常见的校验有2种，奇偶校验或者ECC，根据相关研究，如果出现失效，大概率(好像是90%以上)是1bit错误。对于这种错误，奇偶和ECC校验都可行。通常的做法是在数据将要写入RAM之前，先计算奇偶校验位或者ECC校验位，和原始数据一起写入RAM中，读数据的时候，再对读出的数据做检验，如果出现错误，上告系统软件，让上层业务决定如何处理。另外，当前供应商的IP本身已经支持ECC校验。

(4)、RAM的复位和初始化

首先要明确一点，RAM中存放的内容是不会复位的。我们在例化RAM的时候，输入的复位信号，仅仅是复位RAM中的输出寄存器。那这就会带来一个问题：系统运行一段时间后复位的话，RAM的值并不是我们想要的初始值。怎么办？可以分2种情况考虑：

RAM做为表项：可以在复位后，先自动对RAM做一次初始化操作(即先写一遍RAM)，使得RAM中的值变成我们想要的初始值。

RAM作为缓存：要从方案上保证对RAM的操作是先写后读，那就不会有上述的问题了。如果确实无法保证，也可以参考上述对RAM初始化操作一次的方案。

以上介绍的都是关于的RAM的一些工程实践基础，更深入的信息可以参考xilinx的官方文档，ug573：ultrascale-memory-resources。文章中有不对的地方，也欢迎留言一起交流讨论。