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