令牌流控制：优化芯片通信效率的新方法
下载需积分: 10 | PDF格式 | 491KB |
更新于2024-09-22
| 73 浏览量 | 举报
"Token Flow Control是2008年在NOC领域内的一项重要研究，它引入了一种新的流量控制机制，旨在解决多核芯片中高效片上通信网络的关键问题。通过使用令牌在网络中的路由器间交换资源利用率信息，该方法能够优化路由决策，减少包在路由器中的流水线延迟，从而降低整体通信的能耗和延迟。本文由Amit Kumar, Li-Shiuan Peh和Niraj K. Jha合著，来自普林斯顿大学电气工程系。"
在当前的多核心芯片设计中，构建一个高效的片上通信网络成为至关重要的任务，以满足日益增长的带宽需求并应对有线延迟可扩展性的限制。传统的解决方案是采用模块化的分组交换设计，每个跃点都有路由器，这允许多个数据流共享网络通道。然而，这种设计导致每个跃点的包都要经过复杂的路由器流水线，从而使路由器的开销成为通信能量/延迟的主要贡献者，而不仅仅是线缆的能量/延迟。
针对这一问题，论文提出了Token Flow Control (TFC)。TFC是一种新型的流量控制策略，网络中的节点会向其局部邻居发送令牌，以此传递它们的可用资源信息。这些令牌随后被用于路由决策和流量控制两方面：一是选择网络中较不拥塞的路径，二是让数据包绕过路由器的流水线，显著减少延迟。
TFC机制的核心思想是通过令牌传递来实时更新网络的资源状况。当一个节点发现其资源充足时，可以释放令牌，其他节点收到这些令牌后，不仅能得知当前的资源分布，还能据此调整自己的传输策略，避免拥堵的路径，选择更优的通信路径。此外，令牌的使用还能允许数据包直接跨过路由器的多个处理阶段，减少了数据包在路由器内部的停留时间，从而降低了整体延迟。
Token Flow Control提供了一种创新的方法来优化网络中的流量控制和路由策略，有效地平衡了网络资源的使用，减少了延迟并提高了能效。这对于未来多核芯片的高性能、低能耗通信架构具有重大意义。
51 52 53 54
41 42 43 44
31 32 33 34
21 22 23 24
EonEonEon
SonEon
NonEon
EonSonEon
SonSonEon
WonSonEon
Figure 2. Token forwarding in a network with d
max
=3
32 33 34
EonEon
43
SonEon
Conflict
LA
F1
Eon
LA
F2
Figure 3. Example token conflict
32 33 34
43
LA
F2
LA
F1
LA
F1
successful
LA
F2
killed
Local priority setting at node 33: North
input has priority to use East output
Figure 4. Token conflict resolution
checks to see if there are sufficient resources (greater than b
thr
buffers and v
thr
VCs) at that corresponding input port. For
instance, node 33 is allowed to forward the E
on
token to its
North neighbor (node 43) using an appended S
on
E
on
token,
only if there are sufficient resources at its North input port
(South output port of node 43). All nodes which receive tokens
from node 33 do a similar forwarding to their neighbors by
appending their own tokens, as shown in Fig. 2. This token
forwarding takes place for up to d
max
hops in the network,
thus allowing each node to gather knowledge about resource
availability at all other nodes within its d
max
-hop vicinity.
Propagation of tokens between adjacent nodes uses separate
point-to-point wires which are much narrower than the data
channels. Hence, in a way, TFC makes use of tokens traveling
on separate narrow channels between nodes to optimize com-
munication energy/delay on the wider data channels.
How are tokens used? Tokens provide knowledge of conges-
tionlevelsinad
max
-hop neighborhood. Packets at these nodes
thus use these tokens during RC to form a token route – partial
route of the packet computed for up to the next d
max
hops at
once along less congested sections of the network. Thus, for
instance, the E
on
S
on
E
on
token at node 42 in Fig. 2 can be
used by a packet at that node to travel to node 34 (assuming
node 34 is closer to the packet’s destination) along a three-hop
partial route (assuming d
max
≥ 3) through the East output to
reach node 43, followed by a South hop to node 33 and then
an East hop to node 34 (route shown in bold), thus making use
of the E
on
S
on
E
on
token to route through a path along which
sufficient resources are available.
Once these token routes are known, lookaheads are sent (on
separate channels) ahead of the data flits along these routes
to do control setup at intermediate nodes one cycle prior to
data arrival, thereby allowing the data flit to bypass the router
pipeline and right away traverse the crossbar when it arrives
at these intermediate nodes. In contrast to the baseline, which
allows lookaheads to succeed only under very low loads when
router ports are empty, lookaheads here hold tokens. When such
a lookahead arrives at an intermediate router, it is prioritized to
use its desired switch port over any locally-buffered flits at that
router and hence succeeds in control setup even at high loads.
Moreover, the likelihood of conflicts with other lookaheads is
low along token routes as tokens are forwarded only along less
congested sections in the network. Hence, in the example of
Fig. 2, a packet using the E
on
S
on
E
on
token at node 42 can
bypass intermediate nodes 43 and 33 on its way to node 34.
Are tokens used on a per-flit basis? Yes, tokens are used by
individual flits of a packet. A header flit starting at a node is
free to use any of the available tokens during route computation.
Body/tail flits, on the other hand, do not go through route
computation and need to follow this same route and use tokens
to bypass intermediate routers along that route if such tokens
are available or else they traverse that route without tokens.
Similar to the baseline VC flow control design which uses a
VC control table at each router to store information about each
traversing packet [7], a packet’s route in the token scheme is
stored in a control table at each intermediate router as its header
flit traverses it, which allows the subsequent body/tail flits to
follow the same route as the header.
How are conflicts between multiple flits using tokens re-
solved? As discussed above, tokens are forwarded by broadcast-
ing them in the network. However, since broadcasting involves
forwarding the same token along multiple directions, it can
lead to conflicts when multiple lookaheads (corresponding to
different flits) arrive at a router from different input directions
holding the token for the same output port to bypass that
router. Fig. 3 shows an example of such a conflict where two
lookaheads for flit F1 (using token S
on
E
on
) and flit F2 (using
token E
on
E
on
) arrive simultaneously at router 33 at its North
and West input ports, respectively, holding the token to go out
at the East output.
To resolve such conflicts, each router maintains a local switch
port priority vector which has one entry for each output port
which denotes the particular input port which has priority to
use that output port. If an incoming lookahead matches the
priority setting for its desired output port at that router, it is
deemed to have won the switch. For instance, as shown in Fig. 4,
the current priority setting at node 33 denotes the North input
having priority to use the East output. Hence, the lookahead for
F1 (which matches this priority setting) is allowed to succeed
while the lookahead for F2 is killed. This priority vector is
varied dynamically to balance the request queues at each input
based on the observed traffic, as explained in Section 4.4.
What happens when a lookahead carrying a token
gets killed? Normal tokens only act as hints of resource
(buffers/VCs) availability in the network. They do not need to
guarantee resources at the endpoint node of a flit’s token route.
Hence, a check for a free buffer/VC is done at each intermediate
node along the token route and a lookahead carrying a token is
killed at an intermediate node if there are no free buffers or VCs
available at the next hop along the token route. A lookahead
might also be killed due to conflicts with other lookaheads
(as described above in the answer to the previous question).
When a flit’s lookahead gets killed at an intermediate node,
its corresponding data flit cannot bypass that node and needs
to get buffered there while going through the normal pipeline.
The key thing to note here is that since a check for a free
344
剩余11页未读，继续阅读
相关推荐
25 浏览量
luyeallen
- 粉丝: 0
我的内容管理
展开
最新资源
- ASP.NET集成支付宝即时到账支付流程详解
- C++递推法在解决三道经典算法问题中的应用
- Qt_MARCHING_CUBES算法在面绘制中的应用
- 传感器原理与应用课程习题解答指南
- 乐高FLL2017-2018任务挑战解析：饮水思源
- Jquery Ui婚礼祝福特效：经典30款小型设计
- 紧急定位伴侣：蓝光文字的位置追踪功能
- MATLAB神经网络实用案例分析大全
- Masm611: 安全高效的汇编语言调试工具
- 3DCurator：彩色木雕CT数据的3D可视化解决方案
- 聊天留言网站开发项目全套资源下载
- 触摸屏适用的左右循环拖动展示技术
- 新型不连续导电模式V_2控制Buck变换器研究分析
- 用户自定义JavaScript脚本集合分享
- 易语言实现非主流方式获取网关IP源码教程
- 微信跳一跳小程序前端源码解析
