https://mp.weixin.qq.com/s/-z9n6SHyAiK2OE7mOSvC2Qnode
简单介绍SRAM的实现。
1. 基本介绍
实现一个支持读写的静态存储器。存取的内容可使用ECC进行编解码和验证。
2. TLRAM
TLRAM是DiplomaticSRAM的子类：
1) 类参数
a. address：支持的地址集合；
b. cacheable：是否可被缓存；
c. executable：是否可执行；
d. beatBytes：数据总线宽度；
e. ecc：ECC编码参数；
f. devName：设备名称；
2) 限定条件
a. eccBytes：ECC编码每次处理的数据字节数；
b. code：编码类型；
c. eccBytes须要大于1，而且是2的幂；
d. 数据总线宽度须要大于1，而且是2的幂；
e. ECC编码一次编解码的字节数要小于等于总线宽度，不然没法提供足够的数据给ECC编码使用；
3) diplomacy node
diplomacy node用于与其余节点链接，并协商参数。
须要注意的是，这是一个manager节点，也就是他没有下游节点，只能做为节点路径上的最后一个节点。
使用类参数生成一个manager的参数：
a. address：使用类参数address生成一个地址集合序列；
b. regionType：根据是否能够缓存进行赋值，即上游节点是否能够缓存SRAM中的数据，SRAM节点自己是不支持缓存的；
c. supportsXXX：不支持burst请求；
d. fifoId：安装FIFO顺序处理请求；
使用类参数生成一个ManagerPort的参数：
a. beatBytes：使用类参数beatBytes赋值；
b. minLatency = 1：最低延迟一个时钟周期才能回复响应消息，即a.fire()和d.fire()之间间隔至少一个时钟周期；
4) lazy module
lazy module用于实现节点的内部逻辑。这里主要是实现SRAM的读写，以及编解码逻辑。
下面先介绍不考虑sublane（a_rmw_mask == 0）而且eccBytes == 1的状况。
A. 只有一条输入边，而没有输出边
符合最下游节点的位置特色。
B. 计算须要多少个ECC编解码通道
由于每一个ECC编解码的数据字节数有限，为了知足beatBytes个字节的数据同时编解码的要求，须要使用多个通道，同时进行编解码。
C. 生成一块同步读/同步写的内存
mem是一块SyncReadMem：
D. 用于存储channel a请求信息的寄存器：
其中：
a. d_ram_valid：注释的意思是：若是刚从SRAM中读出来的那个时钟周期，那么d_ram_valid为真；其余时钟周期其值为0；
E. 解码原始数据
根据以前对ECC的介绍，对部分变量进行了重命名：
a. d_raw_data
按ECC编解码通道进行划分的原始数据，从内存中读取：
b. d_decoded
把每个编解码通道读取的的数据使用编码算法code进行解码。
c. d_decoded_out：解码结果：修正后的数据；
d. d_decoded_raw：未解码前的数据，码文中的原始数据；
e. d_decoded_corrected：是否进行过纠错；
f. d_decoded_uncorrectable：是否存在没法纠正的错误；
g. d_need_fix：若是进行过纠错，则须要修正数据；
h. d_error：若是存在没法纠正的错误，则出现错误；
F. 通知纠正和不可纠正错误的信息：
G. 生成回写的数据
回写是指读取数据，发现错误，进行纠正，而后写回正确数据。
若是eccBytes==1，那么upd=0；回写的是fix也就是ecc纠正以后的数据。
H. 生成每一个ECC通道是否回写的掩码
a. d_wb_lanes_mask：若是发生过纠错，该通道就须要回写；
b. d_wb_poison：存在不可纠正的错误，或者输入的数据有错误；意义是要回写的数据有毒（有错误）；
I. 是否回写：
若是从ram中读取了数据，而且进行了纠错，就要回写：
J. 保持解码结果和错误信息：
K. 组装响应消息到in.d：
a. in.d.bits.data
若是d_ram_valid为真，那么使用d_decoded_raw。
注释中说，由于d_pause的缘由，使用未修正的数据也是安全的。由于若是发生了纠错，那么d_pause就为真，此时in.a/in.d都是被关闭的：
考虑到minLatency=1，也就是说in.d在至少一个时钟周期后才能返回，那时候d_ram_valid=0，返回的是d_held_data，这是纠错以后的数据。
整理一下，即：
fire() => d_ram_valid = 1 => in.d.bits.data := d_decoded_raw
=> 至少1个时钟周期 => d_ram_valid = 0 => in.d.bits.data = d_held_data
b. in.d.bits.corrupt
这里使用的是d_error，也就是存在不可纠正的错误时才会回复数据出错。
也就是能够纠正的错误不会回复数据出错。
L. d_pause
若是刚读取到的数据须要修正，那么就先暂停接收请求和回复响应：
其中：
若是d_pause为真，代表接收了一个读请求，d_full应当为真；
M. 解析接收到的请求：
N. a_sublane
意思是：某些通道没有足够的数据供编解码使用。
这里假设eccBytes == 1，先忽略a_sublane。
O. 读使能，以及所需ECC通道的掩码：
P. d.fire()则d_full为假：
Q. 默认值
这里的默认值，其实是做为最后一个else语句使用。也就是说别处的判断赋值未触发的状况下，就触发这个默认赋值。
R. a.fire()
解析并存储请求的各项信息：
这里跟上面的结合在一块儿，对a_ram_valid的赋值语句为：
when (in.a.fire()) {
d_ram_valid := a_ren
} otherwise {
d_ram_valid := Bool(false)
}
S. 读写使能
a. wen：若是须要回写纠正后的数据，或者不是一个读请求，那么须要向SRAM中写数据；
b. ren：若是不是写使能，那么就在a.fire的那个时钟周期打开读使能。这有两个效果：首先，写使能优先；其次，读使能只打开一个时钟周期。
T. 生成写逻辑：
其中：
a. addr：若是回写，则使用d_address，即有问题数据的地址；不然使用a_address，即要写的数据的地址；
b. sel：若是回写，则使用d_wb_lanes_mask，即发生了修正的ECC通道组成的掩码；不然使用a_lanes_mask，即从in.a.bits.mask中获取到要写哪些数据字节的掩码；
c. dat：若是回写，则使用ECC纠正后的数据做为写入内存的数据；不然使用in.a.bits.data做为写入内存的数据；
d. poison：若是回写，则根据是否有不能纠正的错误来肯定要写入的数据是否有毒；不然使用in.a.bits.corrupt来肯定；
e. coded：对数据进行编码；若是不能检错，那么就认为没有错；
f. write：写入的是编码后的数据；
U. 不支持channel b/c/e：
3. 流程分析：回写情景
这里对读取数据有误然后成功修复后进行回写的流程，进行简单分析。
1) 读取数据
A. a.fire()
B. ren打开
C. read
D. decode
E. d_pause
由于d_need_fix为真，因此这里暂停channel a/d：
2) 回写数据
A. d_wb：须要回写
B. 回写的数据
C. 回写的掩码
3) 写数据
A. wen
B. write
4) 什么时候回复Get请求？
ren打开读取内存数据的下一个时钟周期，d_ram_valid == 0，使得d_pause = 0，进而in.d.valid == 1，能够回复AccessAckData消息：
4. sublane
sublane的意义为：某些通道没有足够的数据供编解码使用。
若是eccBytes == 1，ECC通道要么使用，要么不使用，不存在数据不够用的状况。
数据不够ECC通道使用，包含以下几种状况：
a. PutPartial请求中的mask能够为任意值，若是eccBytes == 2，而mask = 0x1011，那么其中一个通道就只有一个字节可使用，此时就没法进行编码；
b. PutFull请求的大小小于eccBytes，这样数据也不够；如eccBytes == 2，而size==0要写一个字节；
c. Get请求的大小小于eccBytes，虽然也能使a_sublane为真，可是处理与普通的读并没有区别；由于每次老是读取beatBytes个字节，足够ECC通道使用；
针对Put请求的状况，如何处理呢？
a. 先从RAM中读取缺乏的字节；
b. 而后与现有的数据合在一块儿进行编码；
c. 最后再把合在一块儿的编码数据写入内存中；
5. 附录
1) ECC重命名表
