Rocket - tilelink - RAMModel
https://mp.weixin.qq.com/s/9ccDTm6HytvfGN5R2CPoAQ
简单介绍RAMModel的实现。
1. 基本介绍
RAMModel用于定义内存访问模型,即统计内存访问信息,并进行验证,以确定是否存在非法访问。
2. MonitorParameters
封装监控参数,包括访问地址和访问大小:
3. ByteMonitor
一个字节的监控信息,包括是否有值、值:
4. FlightMonitor
封装正在等待响应消息的请求消息的信息,包括:请求的地址、请求的大小,请求的类型:
5. TLRAMModel
1) 类参数
a. log:日志信息前缀;
b. ignoreCorruptData:忽略错误数据;
c. ignoreDeniedData:忽略被拒绝的数据;
2) diplomacy node
是一个适配器节点,用于与上下游节点相连接:
这里diplomacy node什么都不做,也表明lazy module中不需要实现转换逻辑。
3) lazy module
那么lazy module中要做什么呢?实现一个内存访问的监控模型。
A. 成对的输入边和输出边
B. 基本参数
其中:
decTrees表示计量最大传输大小的请求包含的beat数目所需要的比特数。
C. wipeIndex
a. wipeIndex是一个初始值为0的寄存器;
b. wipe是wipeIndex最高位取反;
c. wipeIndex每个时钟周期都要自加wipe的值;
不考虑wipeIndex除MSB以外的其他位,相当于wipeIndex的MSB每个时钟周期都取反,wipe的值也每个时钟周期都取反,两者的值差一个时钟周期。
D. 若wipe为真,则阻塞channel a/d:
根据wipe值的特点,也就是每隔一个时钟周期channel a/d都要被阻塞。
E. 不支持channel b/c/e:
F. 一组存储器:
其中:
a. shadow
beatBytes * endAddressHi = endAddress,也就是创建针对每一个字节的监控参数存储空间;
b. inc_bytes/dec_bytes
countBits是计量sourceId总数所需要的比特数,那么inc_bytes/dec_bytes针对每一个字节创建一个记录访问该字节的source个数的存储空间,用于记录每个字节是正被多少个source访问。
c. inc_trees/dec_trees
访问大小size域的值是一个2的对数值,所以访问大小是以2的倍数逐渐增大的。记录beatBytes内的访问大小的source的个数,使用inc_bytes/dec_bytes即可。那么访问大小2*beatBytes对应的请求的source个数应该记录在endAddressHi >> 1对应的监控信息中,以此类推。
G. 是否使能各项监控信息的记录
H. 记录某个sourceId是否有请求存在
I. channel a的请求监控信息
J. 记录channel a的请求信息
K. 取出channel d回应的请求信息
其中:bypass已经见过多次,指能否在请求下发的同一个时钟周期返回响应消息。
L. 提取channel a中请求的各项信息
M. 获取相应地址对应的访问监控信息
a. a_inc_bytes/a_dec_bytes表示访问大小小于等于beatBytes时访问到该字节的source的个数;
b. a_inc_trees/a_dec_trees表示访问大小大于beatBytes时访问到该字节的source的个数;
c. a_inc_tree/a_dec_tree表示对大于beatBytes的访问source的计数进行求和;
d. a_inc/a_dec表示再加上访问大小小于等于beatBytes的访问source的计数;
N. a_fire
a. 不支持Acquire操作:
b. 记录a.source存在访问请求
c. 打开字节访问source统计使能:
这里排除掉Hint和Get消息,表明不改变内存内容的消息不被逐字节监控。
另外,若访问大小小于或等于beatBytes,那么a_sizeOH >> (shift+1) == 0,也就是说不会打开inc_trees_wen。
d. 若消息可能改变内存内容,则打开shadow_wen,并记录信息:
其中:
- a.mask对应着访问到的字节;
- busy表示某个字节是否已经被某个source访问;减去(!a_first)是因为寄存器的特性,a_first对a_inc的改变需要到下一个时钟周期才能表现出来;
- 无论size域的值是多少,data总是以beatBytes为单位传输的(单时钟小于或等于beatBytes),所以这里的i只在0和beatBytes之间取值;
e. 记录Get消息的信息:
f. 讨论
channel a支持的消息类型如下:
在a中首先排除掉Acquire消息的情况下,c和d中对消息类型的判断实际上是等价的,即不是Hint也不是Get,就是PF/PP/A/L之一。
O. 更新inc_bytes/inc_trees的值
不考虑wipe的情况下,这里根据相应wen的值,对inc_bytes和inc_trees进行更新。
存储监控信息的地址,是相应请求的地址:
P. shadow
参考第6节。
Q. CRC
略
R. 响应消息的基本信息
S. d_inc/d_dec
T. d_fire
a. 判断size域是否与请求信息中相同
b. HintAck需要与Hint请求配对:
c. 每字节使用计数的使能开关打开
只有响应消息的最后一个beat时才打开:
下面会生成逻辑递减使用计数:
d. 响应消息的地址范围是否与某个请求重叠?
如果有,则对应的请求不合法。
e. AccessAck与PutFull和PutPartial配对:
f. AccessAckData与Get/Arithmetic/Logical配对:
g. 对返回的每个字节进行判断:
返回数据是以beatBytes为单位进行的,每次返回的数据不能超过总线宽度(beatBytes),所以这里使用0 until beatBytes;
h. 取出返回的数据与shadow中的数据进行比对:
d_mask决定了哪些字节是合法的返回数据。
i. 如果shadow中没有存储监控数据:
RAM也就是内存不是数据的源头,RAM只是处理中的数据。也就是说,内存中每一个字节最开始都是未初始化的,需要先从别处把数据写入内存中(Put),而后参与运算。
所以如果内存中的数据初始化了,那么shadow中的数据也应该是合法的;反之,如果shadow中存储的监控数据不合法,那么内存中的数据也是非法的。
使用到非法的数据存在两种情况:
- 未初始化,即该字节还从未存储过合法数据;
- Get请求在Put请求之前:Get, Put, Ack, Ack;如果不支持fifo,那么AccessAckData看到的shadow.valid为假;
j. 判断计数值是否相等:
分类讨论一下。
先看Get请求。
处理Get请求时,不会增加inc的值,也不会增加dec的值,所以两者应该相等。如果不等,那么就是有一个PP/PF/A/L请求在飞(inflight,即未得到回复)。这里两者不等是一个错误。
再看Arithmetic和Logical请求。
A/L请求发出时,会增加inc的值,得到回复消息时会增加dec的值。而增加dec的值是在最后一个beat(d_last)时做出的,到再下一个时钟周期才会生效。也就是说这里读到的dec的值,是增加之前的,所以理应比inc少1。即两者不等才是正常情况,相等是错误情况。
所以这里针对A/L请求这样判断是有问题的。(欢迎讨论指正)
k. 判断是否有地址范围重叠的请求:
如果有一个地址范围重叠的请求同时完成,那么那个请求就会把对应的valid清掉,这里就会发现d_valid == false:
判断d_fifo是因为如果是fifo的话,即便有另外一个Put请求先完成清掉了对应的valid位,也不会导致内存值不确定。因为是fifo,最后一个Put的数据生效。所以可以放过d_valid == false的情况。
l. 检查是否拒绝服务:
m. 检查是否返回错误数据:
n. 断言正确的情况:
断言shadow和got应该相等:
6. shadow
1) 释名
shadow,影子的意思。谁的影子呢?
shadow定义为存储字节监控信息,数目上足以监控manager中的全部字节:
所以shadow是manager支持的内存的影子。其中存储了内存中的每个字节应有的值,如果与内存中的值不一致,就说明内存中的值出错了。
2) 使用
a. a_shadow:首先读出shadow中对应地址字节的值;
b. a_known_old:是否某个字节的监控信息没有被存储;
c. alu:创建一个Atomics实例alu,alu的两个参数:一个是a.data,一个是a_shadow中的value;a.data是请求自带的数据,a_shadow则相当于(影子)从内存中读取的数据;
3) 赋值
当消息要修改内存中的值的时候,同时需要更新shadow中存储的值:
更新的方法如下:
A. 使用alu的输出来更新shadow中的值:
因为Atomics支持channel a的全部消息类型,所以这里的data_out能够为PP/PF/A/L产生正确的输出;
B. 判断每个字节的监控信息是否合法(不考虑wipe):
a. !busy || a_fifo:没有flight中的请求,或者请求是按照fifo的顺序响应的。如果不是fifo的顺序,那么可能会存在插入其他消息,导致shadow中存储的监控数据不合法;
b. !amo || (a_known_old && beat_amo):不是amo消息,如果是amo消息,则要求实现已经在shadow中存储了内存中的数据信息,并且amo请求的大小不能超过beatBytes。当请求为Arithmetic消息时,高字节的值会影响到低字节的值,所以如果请求大小大于beatBytes,下一个beat中传入的数据可能改变上一个beat中计算的结果,进而导致监控数据不合法;
7. wipe
wipe看上去没有什么实际的意义。
1) 用于生成wipeIndex
每隔一个时钟周期改变一下值(取反)。
2) 用于阻塞channel a/d一个时钟周期
这里注释中的wiping Mems是指擦除内存,但是没看到擦内存的动作。
3) 用于生成监控信息写使能的初始值
4) 用于选择监控信息的地址
当wipe == true时,a_waddr = wipeIndex:
若wipe==1,则wipeIndex的最高位为0,进而可知wipeIndex == 0。所以a_waddr并未超出各个监控Mem的容量限制。
写地址0的意义何在?
5) 用于选择写入inc/dec中的值:
6) 用于生成shadow的valid值:
8. inc/dec
1) 只增不减?
两者都是递增加1,没有看到在哪里减小他们的值。
可以看到对两者的对比都是看是否相等,而不会比对值的大小。
这样使用不需要减小他们的值,溢出时会自动返回0。
如果发起的请求太多,inc溢出为0,而dec因为没有一个响应而为0呢?
这是一个异常情况。
2) countBits
inc/dec中每个监控单元的计数值占用的比特位数为countBits:
countBits是endSourceId占用的比特数:
endSourceId是输入边的所有client的source中最大的值:
因为每个存储单元的比特数能够存储最大的sourceId,
所以第一个推测是:inc/dec中存放的是访问某字节的source的值。
然而这种推测是错的。
看到了inc/dec加一,
产生第二个推测是:inc/dec中存放的是访问某字节的不同source的数目。
然而这种推测也是错的,inc/dec增加时并不区分source是否与已记录的相同。有记录每个source的请求信息吗?有,是flight:
所以这里与其用countBits误导,不如直接使用一个无意义的值,比如4/5/6/8等等。