Rocket - tilelink - Xbar

2024-08-28 21:18:22

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)过滤掉：

最新文章

热门文章