Rocket - tilelink - Xbar

Posted wjcdx

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Rocket - tilelink - Xbar相关的知识,希望对你有一定的参考价值。

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的主要内容,如果未能解决你的问题,请参考以下文章

Rocket - tilelink - Monitor

Rocket - tilelink - ProbePicker

Rocket - tilelink - Edges

Rocket - tilelink - Xbar

Rocket - tilelink - Filter

Rocket - tilelink - Metadata