https://mp.weixin.qq.com/s/kNQrhlf33AErK7IzalnUDw
简单介绍Fragmenter的实现。
1. 基本介绍
用于把上游节点地址空间范围比较大的访问请求，拆分成下游支持的多个地址空间范围较小的访问请求。
1) 类参数
a. minSize：向下游节点发起的最小的访问大小；
b. maxSize：上游节点可以下发的最大的访问大小；
c. alwaysMin：是否把所有上游节点的请求，都拆分成minSize大小的访问请求：
- 如果为真：把所有上游节点的请求，都拆分成minSize大小的访问请求；
- 如果为假：根据下游节点的能力大小来拆分上游节点的访问请求；
d. earlyAck：针对一个Put burst，是在第一个beat回复响应消息，还是再最后一个beat回复响应消息；
e. holdFirstDeny：针对一个Get burst，在出现denied时就一直保持，直到整个burst结束；
2) 参数限制
要求minSize/maxSize都是2的幂，并且minSize小于等于maxSize：
3) minSize/maxSize
a. 实例
其中：ramBeatBytes是RAM支持的访问大小的物理能力。而maxSize是Fragmenter能拆分的最大访问请求的大小。
b. minSize
minSize实际上更多的指代下游节点的物理能力，比如说总线宽度。
c. 实际访问大小
但上游节点的访问请求，可能会小于minSize。此时不需要拆分，直接以原请求大小透传即可。
比如：minSize = ramBeatBytes = 4，而Get请求的大小为2，即读取两个字节。
2. diplomacy node
1) 添加的编码位
a. fragmentBits：分片编号所需要占用的比特数；
b. fullBits：是否需要earlyAck所需要占用的比特数，All和None都不需要这个比特：
c. toggleBits：用于区分两个连续的burst请求的比特位；
d. addedBits：上面加在一起就是需要添加的全部比特位的数目；
2) expandTransfer
扩展Transfer x的大小：
a. 如果x为none，则不进行扩展；
b. 把x.max扩展为maxSize，即Fragmenter支持的最大传输大小；
c. x.min不变；
3) shrinkTransfer
缩小transfer x的大小：
A. 如果不要求把所有的请求都拆分成minSize大小，则不需要缩小x；
B. 如果要求把所有的请求都拆分成minSize大小：
a. 如果x.min大于minSize，那么该传输不支持；
b. 如果x.min小于等于minSize，则把x.max限定在不大于minSize；
总结：缩小的意思是把传输大小的最大值限定在minSize以下。
4) mapManager
放大或缩小manager支持的各项操作的传输大小：
a. 对Atomic操作的大小进行缩小；
b. 对Get/Put/Hint操作的大小进行放大；
根据注释：
a. Arithmetic操作透传：数学运算需要提供操作数，而操作数不能分片，所以只能透传；
b. Get/Put/Hint/Logical操作可以分片：相较之下，位运算的结果只与当前位相关，所以可以分片进行运算；
c. 不支持Acquire操作；
Arithmetic操作要把传输大小缩小可以理解，因为其不支持分片。Logical操作呢？可以把传输大小放大吗？我认为是可以的，所以这里针对supportsLogical，应该是expandTransfer，而不是shrinkTransfer。
但考虑到Logical操作是原子操作，分片后的多个Logical请求之间，是否会被插入其他的请求消息呢？有可能，为了避免这种情况，还是shrinkTransfer较为妥当，毕竟Fragmenter不处理这种同步问题。
5) diplomacy node
A. clientFn：把Fragmenter看到的上游节点的参数，转换为下游节点看到的Fragmenter的参数。
这里进行了如下调整：
a. name：名称为TLFragmenter；
b. sourceId：需要把分片号等信息编码进sourceId中，所以其范围扩大了；
c. requestFifo：需要下游节点实现按请求顺序返回响应信息；
B. managerFn：把Fragmenter看到的下游节点的参数，转换为上游节点看到的Fragmenter的参数。
这里把下游节点各manager支持的传输能力大小进行了转换。
3. lazy module
1) 成对的输入边和输出边
2) 如果不需要分片，则直连即可：
3) 限定条件
a. 所有manager的fifoId都相同，因为需要manager按顺序返回响应消息：
b. manager不支持cache：
c. minSize >= beatBytes
这里的beatBytes是真正的总线宽度，虽然minSize经常被设置为与beatBytes相同，但也可以比其大。如果minSize = 2 * beatBytes，那么Fragmenter拆分后的请求基本上都是包含2个beat的burst。
d. 上下游节点都不支持Cache：
e. 如果可能拒绝Get请求，那么需要保持deny信号：
f. 如果可能拒绝Put请求，那么不能提早对其进行响应：
4) beat数目
beatBytes是Fragmenter与下游节点之间的总线宽度，maxSize是上游节点向Fragmenter发起的请求的最大传输大小。
两者的商是最大传输大小的请求，最终对应的针对下游节点的请求的beat数。
对比一下：
maxSize/minSize：最大传输大小的请求，转化为针对下游节点的请求的数目。
如果minSize == beatBytes，那么这个请求的数目即是beat的数目。
如果minSize > beatBytes，那么这个请求的数目是指burst请求的数目。每个burst请求中包含多少个beat，则由minSize/beatBytes的值决定。
即：
maxSize/minSize = 分片的数目 = (burst)请求的数目
maxSize/beatBytes = 所有请求中beat的数目之和
5) maxDownSize
向下游发送请求时能使用的最大传输大小：
6) 响应相关的变量
这里不再详细介绍。
7) 响应处理
A. out.d.fire()
记录如下信息：
a. ackNum：如果是第一个响应消息，那么响应编号（ackNum）= dFirst_AckNum，后面逐个递减ack_Decrement；
b. 记录dOrig；
c. 从source中取出编码进去的toggle位；
B. 计算是否要EarlyAck：
其中，如果earlyAck的类型为只针对PutFull，那么则从source中取出相应的编码位；
C. drop
是否丢弃这一个响应消息：
a. 如果有数据，则不能drop；
b. 如果要EarlyAck，那么不是第一个的响应消息，都应该丢弃；
c. 如果非EarlyAck，那么不是最后一个的响应消息，都应该丢弃；
D. 把out.d导向in.d
E. 处理针对Put的denied信号：
若出现denied信号，则保持住：
需要注意的是：这里的保持denied信号，不是指在单个burst请求的多个beat之间保持。而是指在多个分片请求的响应消息之间保持，每个分片请求都有可能是burst请求。
F. 处理针对Get的denied信号：
8) 请求分片
A. 计算每个manager针对每种操作的最大传输能力
并转换为lg值：
这里如果manager支持的最大能力为0，也就是manager不支持这种操作，使用lgMinSize代替。注释里的意思是：我们寄希望于client不对某个manager发出他不支持的request，所以这里无论是使用lgMinSize代替或者其他任何值，都没有意义。
根据请求访问的地址，确定地址所属的manager，进而确定支持的最大传输大小：
B. 确定分片的最大大小：
C. 请求分片相关的变量
这里不做详细介绍。
D. 使用repeater重复in.a的请求
a. 从in.a输入，输出到in_a：
b. 何时重复in.a？
需要同时满足一下条件：
- 请求消息中没有数据：如果有数据就透传；
- 分片编号不为0，为0代表最后一个分片；
如果没有数据的请求，即Get/Hint请求消息，则把in.a的数据保存到最后一个分片发出为止。
Arithmetic/Logical都带有数据，但是他们的传输大小是被缩小了的，所以下游节点可以支持透传。如果是Put请求呢？其传输大小是被放大了的。这个问题下面单独研究。
E. 组装各个编码位：
F. 两点优化
a. 直连in.a.bits.data到out.a.bits.data，不需要repeater中转
这个问题会在下面单独研究。
b. 如果repeater.io.full为真，则out.a.bits.mask应当为全1
意思是说，如果当前正在发送一个分片，那么这个分片的大小包含下游节点支持的beatBytes中的所有字节。
9) 不支持Cache
4. Put请求
首先，下游节点支持的Put请求的大小，被Fragmenter放大了。
其次，Put请求不经过repeater，而直接传递给out.a。
那么问题来了：
a. Put请求是否分片？如果分片，原始请求在哪里缓存或者说阻塞以等待所有分片请求发完？
b. 如果in.a.bits.data直连out.a.bits.data会不会丢失数据？
进而，针对Get请求：
c. out.d.bits.data直连in.d.bits.data，会不会丢失数据？
直接说结论：这三个问题，实际上都牵涉到数据的传输。数据的传输是由beatBytes也就是总线位宽限定的（而不是请求中的size域）。
那么Fragmenter改变了上游节点和下游节点的总线宽度了吗？答案是没有。
跟一下代码：
a. channel a的data域的宽度由参数params.dataBits决定：
b. params在创建TLBundle时传入：
c. 创建输入边和输出边的TLBundle，分别使用输入边和输出边中的bundle参数：
d. TLBundleParameters中的dataBits取决于manager的beatBytes：
e. 这个manager是指TLManagerPortParameters：
也就是说：
a. Fragmenter与下游节点之间数据总线的宽度，由下游节点的beatBytes参数决定；
b. Fragmenter与上游节点之间数据总线的宽度，由Fragmenter的beatBytes参数决定；
Fragmenter的beatBytes参数由下游节点使用managerFn转换而来：
这个managerFn只改变了支持的能力的大小，并没有改变beatBytes的大小：
也就是说，改变了可以填到channel a的size域的值的大小，并没有改变数据总线的宽度。
这下就好理解了：
a. Put请求，无论size多大，数据终究需要受数据总线的限制，一个beat一个beat的传输。在这种情况下Fragmenter逐个beat透传没有问题。
b. Get请求，无论size多大，返回的数据也终究需要收数据总线的限制，一个beat一个beat的传输。