Rocket - tilelink - HintHandler

https://docs.qq.com/doc/DUVRtUFZ4RWlCSVRP

简单介绍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

#TODO

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) 如何区分？

这两者如何共处呢？

这里且先提出问题，等后续再研究。

原文地址：https://www.cnblogs.com/wjcdx/p/11437465.html