Rocket - tilelink - SRAM

https://mp.weixin.qq.com/s/-z9n6SHyAiK2OE7mOSvC2Q

 
简单介绍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重命名表
 
 
 
 
posted @ 2019-09-05 12:28  wjcdx  阅读(719)  评论(0编辑  收藏  举报