GEM5 Garnet官方教程：乔治亚理工课程-L07-09 flow control流量控制

最新推荐文章于 2024-04-22 14:25:37 发布

yz_弘毅道远

最新推荐文章于 2024-04-22 14:25:37 发布

阅读量265

点赞数

分类专栏： GEM5 片上网络NoC 文章标签：性能优化硬件架构

本文链接：https://blog.csdn.net/qq_34898487/article/details/134430405

版权

GEM5 同时被 2 个专栏收录

39 篇文章 30 订阅

订阅专栏

片上网络NoC

36 篇文章 10 订阅

订阅专栏

简介

本文是乔治亚理工公开课程Interconnection Networks (Spring 2017)的教程，共有7个主题13堂课加上4个lab，目录在最后的部分。这里是第7堂课L07-09 flow control流量控制。

流量控制介绍

在这里插入图片描述

分配的颗粒度：信息，包，flit

在这里插入图片描述

有2个小问题，这里的All flits of a packet take same route and have the same VCid，

这个vcid在不同的router是一样的么？
同一个router里，不同的cycle数时，同一个packet的不同flit经过的vcid一样么？

不同颗粒度message/packet/flit的flow control

在这里插入图片描述

message based flow control

在这里插入图片描述
就是说，发message之前，之前把一条线路都占了。
下图介绍了弊端是传数据之前有很大的开销，因为传数据之前要先传设置信息和ack。
也有个好处是省去了buffer和routing，还有allocation的开销。关于 routing，还有allocation我们下一篇再将细节，涉及到路由器的微架构。

contention in message-based flow control

如果有冲突，那就硬等
在这里插入图片描述

challenge

在这里插入图片描述

noc’s message-based flow control

其实之前我不知道noc还有message level的做法。我以为只有packet和flit才是noc。
不过这个课程里介绍了message-based flow control的一种， Circuit-Switching in NoCs。
在这里插入图片描述

packet-level flow control

在这里插入图片描述
Packet-based: Store and Forward

包括自己是4个router，hop count是3, Total delay = 4cycles per hop x 3 hops = 12 cycles。
课程ppt里说不适合noc。

store and forward 的时空流程图如下

另一个packet 级别的flow control 是 Packet-based: Virtual Cut-Through

在这里插入图片描述
好处是延迟低了，因为这个相当与允许packet的一部分先走。
但是他要求buffer很大，因为他要求能容纳完整pakcet的buffer。
开玩笑的说就是”分成flit了，但没完全分分成flit“。

时间开销如下，注意，上图标红的只有 0,1,2,5. 下图的router 8在上图没有标红。
在这里插入图片描述
下图是一个例子，要求完整的pakcetbuffer失败，就不能传输packet成功，也就是需要等待。

Virtual Cut-Through 因为buffe不足导致的等待如下图：

Flit-level Flow Control

也许是最关键的flit level flow control，可以认为是vct 的升级版：
在这里插入图片描述

wormhole

就是对一个packet来说，他的n个flit都直接走：（小问题是，vcid是否一致？当然这里wormhole也许不叫vc，意思其实就是，buffer会为这个packet保留没问题，但是不同router用于保留的bufferid是否一样？）

下图是一个很”蠢“的堵法。
我看了一会才理解，下图这个ppt里，前提条件是A. 蓝色比红色必须先走。
从第二行地三列的router看，蓝色flits要往下走，被其他包堵住了。然后红色要往右走，被蓝色堵住了。
（其实这里round robin就可以解决了，也就是说这个router里，蓝色和红色轮流先后走。
站在2023年回头看2017年的课程ppt，有很多答案会先于问题被想起来，比如我就花了点时间，才想明白为什么会有蓝色比红色先走的条件。一个例子就是FIFObuffer，蓝色是head 红色是tail。Round robin要求6个buffer都有出口，但是FIFO buffer只有head处有出口。）
在这里插入图片描述

wormhole的缺点和优点

在这里插入图片描述

Virtual channel

虽然VC 也是flit level，但太重要了。乔治亚理工的课程里是额外的一节课，我这里也用新的大标题写一个详细版。

Virtual channel 详细版

下图提到的，Virtual channel 是否能 Deadlock avoidance请谨慎思考，因为之前也介绍过了，可能会有protocl deadlock，例如一个vn内的req 和resp。
在这里插入图片描述

vc比wormhole 好： Avoid Head-of-Line blocking

在这里插入图片描述

Interleaving Latency

举个例子，没画出来的选项1 A走0-7，B走8-15,分别各自走8个cycle。各自的延迟是8个cycles。
没画出来的选项2 是 A走0-7,B在1-7等待，然后8-15走完，A的延迟是8个cycle，B的延迟是15个cycle。
而下图画出来的是 A和B交错走，A从cycle 0开始走，B从cycle 1开始，但是At出现在cycle 14,BT出现在cycle 15。
在这里插入图片描述

winner take all interleaving

有一个办法可以改善fair interleaving的问题，这个方法就是回归选项2 ，用winner take all。这个方法我看到的也不多，感觉还是fair interleaving 主流。
在这里插入图片描述

Summary of Techniques

在这里插入图片描述

NI和router直接的竞争

原标题是Designing a Flow Control Protocol:Managing Buffers and Contention。其实第一部分就是说 NI和router竞争的时候，router优先，NI先等一等。

假定目标是个ring noc。这样router和router之间只有2个inport 和2个outport。算上与core相连的NI，那就是3个inport和3个outport。
在这里插入图片描述

下面这个图画得不是特别好。
左边是左边的inport，右边是右边的outport。右边的inport不会用到右边的outport，所以只有左边的inport和core这边竞争。而且这里用了input buffer，所以左边的没有buffer，只有input from core有buffer。
这个图有一些不太清楚的是左边没画出来的路由器给绿色路由器输入，这个直接就去output to core而没有一个mux选通的过程很让人误解。
在这里插入图片描述
而这个图的意思是说，先让上图从左去右的，已经在ring里了的先走。还在input from core(我们一般叫NI或者NI buffer)，就等一等。

backpressure

下面介绍了一些需要解决的问题，在我看来主要是为了引出backpressure。
在这里插入图片描述

丢弃包

简单粗暴，将问题丢给潜在的重传机制。主流NOC研究不怎么用。
在这里插入图片描述

misroute 换个地方

就是要去的地方堵住了，找个别的不堵的地方先去待着。
很显然这样消耗额外的能量，走了不必要的路还得回来导致延迟更高，尤其还需要设计一个复杂的找路回来算法。
在这里插入图片描述

Wait 等待

没错就是硬等。大道至简，硬等就好了。
backpressure的传递就是，右边的router NItoCore堵住了，这压力传给了本来要右router的West inport 。而左router的 West inport 因此也停住了。
在这里插入图片描述

backpressur arbitation logic

下图的逻辑是，被堵住没发出去的那个flit，名字叫 prev out的优先。这样的设计还需要在output出额外接一个线，看着有点呆的。
这样的好处是，prevout这个flit不用占用左路由器west inport的flit buffer，坏处是output处有一个额外的buffer。
最后是3个buffer再竞争，in_ring,in_core 和 prevoutBbuffer。

我的经验：
有另一种选项，是不管之前发的是什么，重新竞争，同时不删除output。
也就是一直只有左边路由器的2个buffer in_ring,in_core 竞争。如果右边慢了，左边就一直保持这两个buffer不动。

图里还提了一个note，意思就是如果去不堵的vc可以照常走。

在这里插入图片描述

backpressure 信号机制

On/Off Flow Control vs Credit-based Flow Control

我的经验是credit based 用的比较多
在这里插入图片描述

On/Off Flow Control

On/Off Flow Control机制

在这里插入图片描述

On/Off Flow Control 优劣

在这里插入图片描述

Credit-based Flow Control

Credit-based Flow Control机制

在这里插入图片描述
这里credit 也是要耗时间的。不过不知和一个flit的运输时间相比如何，以及能否同时进行。也许下一堂router 微架构和pipeline会有介绍。

credit based 优劣

好处是给多少buffer都可能被用上，不用设计特别打的buffer。
坏处是每个flit都要回一个credit signal。
在这里插入图片描述

credit based buffer大小要求

在credit信号传输过程中，很显然是有buffer闲置了的。那么要求是 buffer足够多，那么在buffer用满之前，这个信号需要及时到达。
下图是关于信号传输的流程。

这个图也需要一些额外的解释。每个node的credits是自己下一个node(也就是右边node）的值。

我们重点看node1,在t1->t2的时候大家相安无事，node1 的credits=1,代表它node2只有一个flit buffer的位置空着了，所以node1可以且只可以给node2 发一个flit。
不关键的部分：t1->t2node0的credits=4，意味这node 1可以接受4个flits。

t2->t3的时候node1 发出了这个flit去往node2，这意味着node2的buffer都被占满了。存在node1里的credits，虽然它的意义是node2的buffer空余，但是它存在于node1 里，所以它不需要传包，node 1里的credits直接就变成了0，代表node 1 看来， node2没有空余的flit buffer 。(如果这个flit丢包了，node1依然以为node2被占满了，而实际上丢flit了 node2并没有接受到这个flit。这种丢包的情况这里不考虑)。
同时，node1 自己知道自己本来有4个flits 空位，现在又送走了一个flit，他有5个flit空位了。但他的上家没更新，所以t2他发了一个信号给node 0.

t3->4的时候
对node1 来说，它认为node2在t1->t2时候只有一个flit空余， t2->t3的时候有0个flit空余。从t2这个瞬间起，node 1就认为node2已经满了。
对node2来说，t3的时候它才完成接收flit。t3->t4时,他用来处理flit。
不关键：node0收到了credit信号,并且更新了node0里存的credits。

t4->t5 对node1来说，他接受到了 node2 发回的credit信号。对node2来说，t5的时候，它才有一个flit buffer的空位，也就是它自己允许自己接收一个flit。
不关键的：node2发出flit给node。

t5->t6: t5的时候，node2自己能接收了，但是node1不知道。直到t5->t6,node 1在t6的时候，完成了node1内credit的更新。这意味着，t6起，node1可以继续给node2发flit。

从t2到t6,node 1才可以继续发下一个flit给node2,这就是 turnaround delay。
不过这个东西也有点奇怪的，因为t5瞬间node2才允许node2自己接收，而t6瞬间node1就允许node1发给node了。

这个ppt宣称”To prevent backpressure from limiting throughput,
number of buffers >= turnaround time“ 是为什么，我在2023-11-15这一天没有想清楚。
在这里插入图片描述
ppt宣称number of buffers >= turnaround time，也就是大于t2->t6这段时间。
具体的时间，则是下面：