Rocket - tilelink - HintHandler
作者:互联网
简单介绍HintHandler的实现。
1. 基本功能
实现Hint请求的处理逻辑。
类参数:
passthrough:是否把Hint请求透传给下游节点处理;
2. diplomacy node
HintHandler是一个适配器节点:
1) clientFn
把HintHandler看到的上游节点的参数,转换为下游节点看到的HintHandler节点的参数。
这里把原sourceId左移一位,最低位用于编码信息。
2) managerFn
把HintHandler看到的下游节点的参数,转换为上游节点看到的HintHandler节点的参数。
这里根据情况,为下游节点新增支持Hint操作的能力:
a. 如果下游节点支持Hint操作,并且允许透传Hint请求(passthrough),那么直接使用下游节点的能力;否则:
b. 如果下游节点支持PutPartial,则使用PutPartial的能力;否则:
c. 如果下游节点的区域类型为GET_EFFECTS,则使用Get的能力;否则:
d. 告诉上游节点,不支持Hint操作;
3. lazy module
lazy module用于实现HintHandler的内部逻辑。
1) 成对的输入边和输出边
2) 默认in直连out
3) 确保HintHandler支持Hint请求
注意这里使用的是edgeIn,而不是edgeOut。edgeIn.manager是指HintHandler节点作为的manager。
这里判断的意思就是确保HintHandler支持Hint请求。无论是透传,还是由HintHandler代为处理。
4) usePP & useGet
usePP:使用PutPartial消息为下游manager处理Hint请求;
useGet:使用Get消息为下游manager处理Hint请求;
5) mapPP & mapGet
判断当前请求的地址对应的manager使用PP还是Get处理Hint请求:
6) 转换请求到out.a
7) 转换响应到in.d
A. 如果使用Get处理Hint,则需要丢弃响应消息AccessAckData:
a. 如果Get的能力小于或等于beatBytes,就不存在burst请求,都是单beat请求。这个单beat请求会直接被转换(transform),所以不需要丢弃;
b. 如果Get的能力大于beatBytes,就需要把除去最后一个的beat丢弃;
B. transform是编码位,代表着是否需要把Get和PP的响应转换为HintAck:
8) 处理Acquire操作的source:
因为不需要HintHandler做处理,所以直接把source移位即可:
9) repeater
用于处理burst PutPartial转换:
A. 因为Hint请求不包含数据,所以其size可以很大。PutPartial包含数据,所以当size大于beatBytes时需要分成多个beat组成burst请求。
即一个size大于beatBytes的Hint请求,被转换成了包含多个beat的PutPartial请求。
a. The Control type signals (i.e., *_address, *_size,*_param) must be held constant for the entire burst.
b. mask为0,不真的写入数据:
B. 直到所有的PutPartial beats发送完成,才允许in.a继续输入:
repeater.io.repeat在最后一个beat之前的beat时都为真。意味着即便从repeater.io.deq取走数据,repeater.io.full也为真:
此时repeater.io.enq.ready为假:
所以这里repeater的用法与Fragmenter中类似,都是用来Hold住in.a而等待out.a的。
4. 默认连接与特定连接
1) 默认连接
默认out与in直连:
即in.a/b/c/d/e与out.a/b/c/d/e分别相连,这属于bulk connect。
2) 连接特定域
这里又把新的输出连接到out.a的部分域上:
3) 如何区分?
这两者如何共处呢?
这里且先提出问题,等后续再研究。
标签:tilelink,请求,Rocket,Hint,beat,PutPartial,节点,HintHandler 来源: https://www.cnblogs.com/wjcdx/p/11437465.html