https://mp.weixin.qq.com/s/-pjCLzzincJz0Z66orx8kg
介绍Broadcast的实现。
1. 基本介绍
TLBroadcast实现的是TL-C等级，支持Transfer操作。主要功能是根据输入的请求类型，广播Probe请求进行权限调整，维持缓存一致性（cache coherency）。
2. Tracker
跟踪为了实现缓存一致性而发出的Probe请求的过程。Tracker根据配置参数bufferless，决定是否保存上游节点下发的请求。
3. TLBroadcast
1) 类参数
a. lineBytes
每个Tracker支持的字节数：
限制条件：
i. 值大于0；
i. 值为2的幂；
i. 值大于数据带宽（beatBytes）；
b. numTrackers
支持的Tracker的数量。
c. bufferless
是否保存上游节点下发的请求。
2) node
用于与其他diplomacy节点连接并协商传递参数的diplomacy节点。
A. clientFn
用于向下传递参数的方法：
因为要对source增加两位进行编码，所以这里乘以4。
B. managerFn
用于向上传递参数的方法：
a. endSinkId = numTrackers；
b. 限定下游节点不能支持Acquire操作，即下游节点不支持TL-C：
c. 只处理区域类型为UNCACHED的manager，把UNCACHED转换为TRACKED。即我们看到的下游节点的区间类型为UNCACHED，而上游节点看到的我们支持的这个区间的类型为TRACKED。因为我们做了TRACK的工作。
所谓UNCACHED区间类型，是指当前节点对该区间的支持不包含CACHE，但不妨碍上游节点为之添加缓存的功能。
这里not cached yet，不是指时间上，而是指结构上。
就时间上而言，一个区域是否缓存是一个动态的过程。而这里区域类型是一个静态的属性，不会随时间的变化而变化。即某个节点对某个区域的支持是否可缓存，不随时间的变化而变化。
但可以随结构的变化而变化。节点不是鼓励的节点，而是DAG中的一个节点。DAG中某个节点对某个区域的支持是不缓存，不代表其上游的节点不可以代为缓存。
所以可以理解几个区域类型的意义：
UNCACHED：当前节点没为之缓存，上游节点可为之缓存；
TRACKED：当前节点为下游节点增加了缓存的支持；
UNCACHEABLE：不可缓存，当前节点不缓存，上游节点也不可以缓存，因为内容会变（比如IO编址区间）。这样的区间每次使用都要重新读取；
CACHED：当前节点已为之缓存；
d. 支持的传输大小变化：
e. 响应不必FIFO顺序返回，也就是说先来的请求的响应可以后面才返回；
3) module
A. node.in & node.out
因为所有节点组成的是DAG，所以只有上游节点可以缓存下游节点的数据，兄弟节点不能缓存。所以当上游节点发起的请求触发权限相关的Probe操作时，只需要向上游节点（通过node.in）发出Probe请求即可。
B. clients/managers
取出这一条线上的clients/managers：
C. lineShift
用于处理地址，因为缓存的数据大小为lineBytes，所以地址相应的低位可以忽略：
D. caches
取出缓存数据的clients：
E. 创建Trackers
创建numTrackers个Trackers：
其中：log2Up(caches.size + 1)为记录probe个数所需要的比特数。
F. 处理channel e
channel e只有1种message，即GrantAck：
a. 一直接收channel e的输出；
b. 选择与in.e.bits.sink对应的tracker，输入e_last的值；
G. in.a：上游节点的请求
a. 请求类型
左侧列出了各种请求类型。
b. Acquire
Acquire操作请求提升权限：
i. NtoB：从None提升到Branch，Branch节点具有只读权限，所以向其他缓存了数据的节点发送Probe请求，把权限设定为Branch，即只读权限，超过的需要降权。
i. NtoT：从None提升到Trunk，Trunk节点可读，Trunk节点具有读权限，并且缓存了可能是脏数据的数据。所以如果一个节点要提升至Trunk节点，需要向其他节点发送Probe请求，把权限设定为None，以促使其把数据回写。
i. BtoT：同NtoT。
c. 其他操作
i. PutFullData：上游节点发来写数据请求，需要其他cache节点回写数据，若有需要之后再重新缓存。所以Probe其他cache节点的权限至None；
i. PutPartialData：同PutFullData；
i. ArithmeticData：需要先读、计算、再回写，同PutFullData；
i. LogicalData：同PutFullData；
i. Get：为了读取到最新数据，需要回写脏数据，如果没有脏数据则直接从缓存中返回即可。即如果是Trunk权限，则需要降权为Branch。如果是Branch权限，则无需再降权。
i. Hint：预读取和预写入与读取和写入同理；
d. selectTracker
其中：
i. freeTrackers：各个tracker是否空闲的标志；
i. freeTrack：是否存在空闲的Tracker；
i. matchTrackers：各个tracker跟踪的是否是当前访问的地址的标志；
i. matchTracker：是否有一个tracker跟踪者当前访问的地址；
i. allocTracker：从空闲的tracker中分配一个tracker用于跟踪当前访问的地址；
i. selectTracker：如果有tracker正在跟踪当前访问的地址，则仍然使用这个tracker。否则，使用重新分配的新tracker；
e. trackerReady
trackerReady是各个tracker是否可以接收输入的标志：
f. in.a.ready
是否接收channel a的请求，取决于如下条件：
i. 选中的tracker可以接收：(selectTracker & trackerReady).orR()；
i. burst请求的后续beat（!a_first）或者已经全部probe完成；
g. 请求存入tracker
其中：t.probe表示要probe的client的个数。如果没有caches则为0。否则要看请求是否来自于某一个cache节点，如果是则为caches.size - 1，如果不是则为caches.size。
H. in.b
channel b用于向上游节点发送Probe请求：
其中：
i. probe_todo：待probe的cache节点；
i. probe_line：probe的address；
i. probe_perms：param中cap的权限；
i. probe_next：下一个要probe的对象；
i. probe_busy：是否probe完所有要probe的cache节点；
i. probe_target：当前要probe的对象；
i. in.b.fire()时切换下一个probe对象；
I. in.c
a. 消息类型
![]()
i. ProbeAck：我方发出Proe的响应消息，说明某client Probe完成。递减tracker中的Probe计数器。DROP是指收到ProbeAck无需其他动作。
i. ProbeAckData：除了递减计数器之外，还需要把返回的数据回写。即通过out.a发出PutFull消息。DROP是指无需再有其他动作。
i. ReleaseData：不同于ProbeAckData的地方在于，ReleaseData是上游节点发起，是一个请求消息，需要我方回复。回复的动作需要在PutFull完成之后，把PutFull的响应消息即AccessAck转换（transform）成为ReleaseAck返回给上游节点。
i. Release：直接使用in.d回复ReleaseAck即可。
b. 甄别消息类型
c. 消息与tracker的关系
d. releaseack
针对Release消息的回复ReleaseAck：
i. valid：channel c发送release时回复；
i. 使用in.c.bits组装releaseack；
通过in.d返回：
e. putfull
针对ProbeAckData和ReleaseData消息，需要把Data回写：
其中：
i. put_what：标识PutFull是为了ReleaseData还是为了ProbeAckData，如果是ReleaseData，就标识为TRANSFORM_B，如果是ProbeAckData就标识为DROP。
i. put_who：如果是ReleaseData消息，那么source在in.c.bits.source；如果是ProbeAckData，这里source使用的是tracker中存着的in.a中取的source，与ProbeAckData中的Source即Probe消息的目标不一样，后续并没有使用这个source，用意不做分析。
i. Cat(put_what, put_who)：修改Put操作的source，以方便响应消息AccessAck返回时处理；因为put_what有四种可能（TRANS_B/TRANS_T/DROP/PASS）占两位，所以下游节点看到的client的endSourceId相比Broadcast节点看到的上游节点cliet的endSourceId，扩大了四倍。这就是diplomacy node的clientFn中cp.endSourceId乘以4的原因：
通过out.a发出：
f. probenack
如果in.c返回ProbeAck消息，则告诉tracker递减probe计数器：
J. out.d/in.d
如何根据out.d生成in.d要回复的消息。channel d支持的消息类型如下：
a. 取出编码在source中的信息：
b. 判断是否ProbeAckData消息衍生成出的Put消息的响应消息AccessAck：
有个assert限定：
如果是这个AccessAck消息，就允许发送：
然而这个消息不会被传往in.d：
c. d_hasData：是否包含数据：
d. d_normal：使用out.d生成的消息，发往in.d
a) 使用in.d克隆的Wire：
这意味着d_normal中各个域的位宽与in.d一致，而不是out.d。
实际上，out.d的source域比in.d的source域多两位，所以把out.d连接到d_normal时，会把这两位丢掉：
b) TRANSFORM
TRANSFORM的信息从out.d.bits.source中取出，即do_what。
这个信息从两处传入：
i. put_what：
- ReleaseData需要把Put的响应消息AccessAck变换为ReleaseAck；
- ProbeAckData需要把Put的响应消息AccessAck丢弃；
i. in.a的Acquire消息：
in.a发出的Acquire消息，会被转换为Get消息，从下游节点请求数据，然后返回给上游节点。
c) do_what(1)：TRANSFORM_B/TRANSFORM_T
如果do_what(1)为真，那么编码在source中的信息是TRANSFORM_B/TRANSFORM_T：
进而表明tracker中跟踪的是一个Acquire消息或ReleaseData消息。
如果d_hasData为真，out.d返回的是Acquire变换成的Get消息的响应消息AccessAckData，应该被转换为GrantData消息返回；
如果d_hasData为假，out.d返回的是ReleaseData变换成的Put消息的响应消息AccessAck，应该被转换为ReleaseAck消息返回；
GrantData消息的param：
ReleaseAck消息的param为0：
d) probedack
标志着ProbeAckData处理完成：
如果ProbeAckData衍生的Put消息返回，则ProbeAckData消息处理完成。
e) d_last
响应消息是否发送完成：
d_normal.fire() && d_last代表d_normal发送完成。
d_response指除ProbeAckData的AccessAck消息和ReleaseData的ReleaseAck消息之外的其他消息。
为什么要排除这两个消息？
因为这两个消息的响应消息虽然都是从channel d返回，但他们都是从channel c发送的请求消息。而tracker跟踪的是channel a发出的请求消息。
4. TLBroadcastTracker
1) 参数
a. id：tracker的编号；
b. lineBytes：tracker缓存的字节数；
c. probeCountBites：需要probe的cache节点计数所需的比特位数；
d. bufferless：是否保存上游节点下发的请求；
2) io
其中：
a. in_a_first：是否in_a的第一个beat；
b. in_a：保存的channel a的输入；
c. out_a：向channel d输出的信号；
d. probe：要probe的cache节点的数目；
e. probenack：处理完成一个ProbeAck消息；
f. probedack：处理完成一个ProbeAckData消息；
g. d_last：是否channel d的最后一个beat；
h. e_last：是否channel e的最后一个beat；
i. source：提取in_a中的source域，输出用于比对；
j. line：提取in_a中的address域，处理后输出用于比对；
k. idle：表示该tracker是否空闲；
l. need_d：是否需要channel d；
3) 临时变量
其中：
a. idle = got_e && sent_d：表示已经完成全部消息交互：channel d已经发送完成，并收到了channel e的消息。
b. count：probe请求的计数器。
4) 存入channel a的请求消息
a. sent_d：假，刚收到in.a的消息，还没有返回响应消息；
b. got_e：只有Acquire/Grant/GrantAck交互需要用到channel e置为假，其他用不到的置为真。
c. count：值等于io.probe;
5) sent_d && need_d
当channel d的最后一个beat发出后，sent_d置为真：
channel d的响应消息已发出，则不再需要channel d：
6) e_last && got_e
当channel e的最后一个beat（实际上channel e有且只有一个beat）发出后，got_e置为真：
7) line
根据存的数据大小，地址的低若干位没有意义可以移除：
8) probe计数
a. 处理完一个ProbeAck减1；
b. 处理完一个ProbeAckData减1；
c. 同时处理完则减2；
9) probe_done：标志着probe已经完成：
10) Queue
创建一个队列用于输入、存储、输出数据：
11) 输入规则：
12) 输出规则：
其中：
a. Acquire消息被转换为Get消息，其余透传；
b. source进行编码，Acquire消息对应的source编入transform信息，其他的透传（PASS=0b00）;
out_a输出到out.a：
5. Broadcast主动发出的消息
无。
6. Broadcast被动发出的消息
1) 向上游发出Probe请求消息；
2) 向上游直接回复ReleaseAck消息；
3) 向上游回复transform后的ReleaseAck消息；
4) 向下游发出transform后的Get消息；
5) 向下游发出transform后的Put消息；
7. Broadcast透传的消息
channel a支持的消息如下：
除Acquire需要transform外，其余的都会透传。