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等等。