标签：消息 data node 请求 基本 href 有关 数值 each
https://mp.weixin.qq.com/s/UXFHYEQaYotWNEhshro68Q
简单介绍Xbar的实现。
?
?
1. 基本介绍
用于为Xbar的输入和输出连接生成内部的连接逻辑。
2. object TLXbar
定义了一些辅助方法。
1) assignRanges
?
?
把size放大到与之临近的2的幂，然后进行排序累加，确定新的范围。
?
?
运行结果如下：
?
?
2) mapInputIds
重新划定sourceId的范围：
?
?
3) mapOutputIds
重新划定sinkId的范围；
4) relabeler
re-lable，重新打标签的意思。这里是用于把fifoId重新赋值成为连续的整数值。
?
?
a. relabler返回的是一个无参函数：
?
?
b. 这个无参函数返回的是带一个整型值参数返回一个整型值的函数：
?
?
在diplomacy node中使用：
?
?
a. 首先，调用relabler返回一个函数名叫fifoIdFactory；
b. 然后，调用fifoIdFactory这个函数，返回一个函数名叫fifoIdMapper；
c. 最后，针对每个manager的fifoId调用这个fifoIdMapper函数，返回新的连续的fifoId；
5) fanout
?
?
根据select中各个位的值，决定是否把input转发到对应的输出口中。
a. 复制select.size份input类型的输出口filtered；
b. 逐个连接input和filtered中的输出口；
c. filtered(i).bits与input.bits连接：force用于一定生成这样一个扇出口，应该与优化有关；
d. filtered(i).valid由input.valid和select(i)的值决定，即要么被选择输出，要么只有一个输出口必须要从中输出；
e. input.ready由被选择的输出口的ready信号决定；
3. class TLXbar
1) 类参数
类参数policy是一个仲裁策略：
?
?
2) diplomacy node
diplomacy node用于与上下游节点连接，并进行参数协商。
?
?
A. clientFn
clientFn用于把Xbar看到的上游节点的参数，转换为下游节点看到的Xbar的参数：
?
?
a. 调整minLatency，client的最小延迟适用于下游节点发起的Probe消息；
b. 调整每个client的sourceId，使之落入新的范围；（这里是否假设原来的sourceId.start==0?）
B. managerFn
managerFn用于把Xbar看到的下游节点的参数，转换为上游节点看到的Xbar的参数：
?
?
a. 调整minLatency；
b. 调整endSinkId；
c. 调整fifoId；
d. 要求所有下游连接边的数据总线宽度相同；
3) lazy module
lazy module用于生成Xbar的内部逻辑。
这里主要是生成上游各个节点与下游各个节点之间的转发连接逻辑。
A. 所有输入边和所有输出边统一处理：
?
?
B. 输入边和输出边不能太多：
?
?
C. 输入边是否可以转发到输出边：
把输入边的可见地址范围与输出边的支持地址范围进行比对，如果有重叠，就存在从这个输入边项这个输出边转发消息的情况：
?
?
a. 一个输入边对所有输出边都存在是否可达的判断；
b. 每个输入边都有这样的一组判断值；
D. 输入边和输出边之间是否存在转发Probe消息的情况：
?
?
E. 输入边和输出边之间是否存在转发Release消息的情况：
?
?
F. 生成各channel的连接矩阵：
?
?
其中：
a. channel a/d有reachableIO决定；
b. channel b由是否发起Probe消息的ProbeIO决定；
c. channel c有是否发起Release消息的releaseIO决定；
d. channel e：这个单独讨论一下；
首先，Release和Acquire是一对消息，所以可以转发Release消息的配对，也会转发到Acquire消息；Acquire消息会触发Probe/ProbeAck消息，ProbeAck消息使用channel e；所以channel e由releaseIO决定。
其次，Acquire消息通过channel a发送，所以releaseIO实际上也部分决定了channel a的配对表。
G. 矩阵行列转置方法transpose：
?
?
H. 把输入边视角的配对表，转换为输出边视角的配对表：
?
?
I. 处理id
?
?
其中：wide_bundle是找到最宽线参数，用于生成转发连接逻辑。
J. 使用最宽的线参数，生成与输入边的连接：
?
?
K. 根据配对表，生成与输入边的连接
a. channel a
?
?
a) 如果没有输出边接收这个输入边的消息，那么直接关闭channel a；
b) 需要把source域做转换；
b. channel b
?
?
这里主要是把source与调整回来。
c. channel c/d/e
?
?
L. 根据配对表，生成与输出边的连接
?
?
a. channel a/b/c
直连即可：
?
?
b. channel d/e
需对sink域做处理：
?
?
M. filter
根据mask，选出相应的data：
?
?
N. 生成一个基于地址的转发函数表
?
?
a. port_addrs包含每个Port支持的所有地址集合；
b. routingMask是区分一个地址属于哪一个Port所需要比对的最少比特的掩码；
c. route_addrs是把Port支持的地址集合使用routingMask简化之后的转发地址表；
d. 映射的第一个元素是配对表；
e. 映射的第二个元素是一个函数，这个函数根据访问地址，生成一个转发表，表明是否转发到对应的Port；
O. 取出channel a/c的地址域：
这是一个序列，包含每个输入边的地址域：
?
?
P. 根据地址，确定请求消息的转发表
?
?
Q. 计算请求消息需要多少个beat：
?
?
R. 使用消息转发表生成转发扇出：
?
?
首先，针对一个输入边，生成到每个输出边的转发扇出；
其次，转置成为所有输入边到某一个输出边的扇出接口；
S. 生成仲裁输出逻辑：
?
?
以outs(i).a为例：
a. sink是outs(i).a；
b. portsAOI是所有输入边的扇出接口；
c. filter根据connectAOI过滤出会向其转发请求消息的输入边的扇出接口；
d. 仲裁器根据仲裁策略仲裁哪一个扇出接口的消息转发到outs(i).a；
T. unique
unique表示，如果输入边和输出边的配对表中只有一项，也就是输入边只连接到一个输出边，那么可以忽略地址转发表，而直接进行转发：
?
?
这样可以把fn(a)的逻辑优化掉。
这样导致：
a. requestAIO中的某一行为全1；
b. portsAOI中的所有扇出接口都会被选中：
?
?
但在仲裁时相应的扇出接口会被connectAOI(i)过滤掉：
?
?
Rocket - tilelink - Xbar
标签：消息 data node 请求 基本 href 有关 数值 each
原文地址：https://www.cnblogs.com/wjcdx/p/11478410.html
