一种实现可快速释放的VLV访存阵列的方法与流程

文档序号:18142277发布日期:2019-07-10 11:12阅读:555来源:国知局
一种实现可快速释放的VLV访存阵列的方法与流程

本发明公开了一种实现可快速释放的vlv访存阵列的方法,具体为软件程序技术领域。



背景技术:

vlv(variablelengthvector)是目前比较新颖的一种向量指令的架构设计,兼顾了软件程序的可扩展性,兼容性和简洁性,轻松实现一套指令集迎合未来较长时间的应用需求,作为vlv的访存单元,其性能决定了核的存储带宽,间接的影响执行效率。

vlv支持1-1kb的存取以及向量运算,可支持多笔load乱序访存,一旦乱序资源不够,会造成vlv的阻塞。每次流水线restart刷乱序队列的时候,vlv内部资源并不可以被立即释放,需要等待已经发射出去的访存请求全部返回,才可以把曾经标记了restart标志的entry释放掉,否则后面的请求会因为错误的匹配而接收到错误的数据,如果采用乱序id与乱序资源对等的方式,硬件开销过大,为此,我们提出了一种实现可快速释放的vlv访存阵列的方法投入使用,以解决上述问题。



技术实现要素:

针对上述缺陷,本发明的目的在于提供一种快速释放乱序资源,用最小的开销,提升有限的硬件资源利用率的可快速释放的vlv访存阵列的方法,以解决上述背景技术中提出的问题。

为实现上述目的,本发明提供如下技术方案:一种实现可快速释放的vlv访存阵列的方法,包括如下步骤:

步骤一:当每次发生restart的时候,并且已经发送的次数等于返回次数时,id依然保持不变,下一个push进来的请求依然使用现有id;

步骤二:当每次发生restart,并且entry已经发送的次数不等于返回次数时,如果镜像资源没有满,进行以下特殊操作:

a:释放现有entry;

b:把entry的id、发送counter、返回counter复制到另一个结构中;

c:从freelist选出n个status为非busy的id,并把对应的busy置位,填到entry的id域;

步骤三:通过镜像资源用于存储restart未完成得请求时复制出来的请求信息,包括请求的id,发送counter和接收counter;

步骤四:接收counter会在被复制到镜像资源以后,继续monitor返回的响应,并完成自加过程,一旦发送和接收相同,释放当前镜像资源和id,free-list会根据释放的id完成更新操作;

步骤五:如果操作激进,并且当前释放的镜像资源是唯一可用的资源,可以在释放id的同一个周期把id重新复制回有restarted标志的entry,完成和entry信息的互换;

步骤六:通过free-list维护id的分配和回收,每次pushrequest的时候分配id,正常释放entry的时候回收id,或者镜像资源中完成请求的时候回收id。

优选的,所述步骤一中,每个entry多出一个域来表示当前的entry的id,另外有一个freelist来维护所有entryid的状态,刚开始上电的时候,entry的id等于0,1,2依次递加,freelist的前四个id状态为busy,之后每次entry被正常释放,id保持不变,下一个push进来的请求依然使用现有id。

优选的,所述步骤二中,每次发生restart请求的时候,流水线需要重新加载新的指令,前端流水线的延迟可以让以上的操作不需要在一个周期内完成。

优选的,所述步骤三中,id的上限就决定了连续restart后,vlv访存的接收能力,用于存储未完成请求的镜像结构在设计中也需要考虑到本身乱序资源和id的数量。

优选的,所述步骤四中,每次只需要分配一个小的entry,此外freelist也只需要查找一个空闲的id,并更新freelist,把freelist做的很大,支持更多的id。

优选的,所述步骤五中,一旦镜像结构有请求释放了空间,再从乱序资源内部把未完成的请求复制出来,并分配刚才释放的id。

优选的,所述步骤六中对id的分配和回收还设有一种方案,当每次pushrequest的时候不考虑id的分配,释放后的entry自然拥有可用的id,每次正常释放entry的时候,id保持不变,每次非正常释放entry的时候,从free-list中分配一个非busy状态的id,只有在镜像资源等待请求完成的时候回收id。

与现有技术相比,本发明的有益效果是:在发生restart之后,快速释放乱序资源,减少不必要的资源阻塞,用最小的开销,提升有限的硬件资源的利用率,分配和回收过程均可以多个周期做完并且不影响性能,时序压力几乎为零,id和镜像结构资源可配置,根据性能要求灵活可调节,同时解决乱序窗口和释放问题。

附图说明

图1为本发明快速释放的vlv访存阵列的方法具体流程示意图。

具体实施方式

下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。

本发明提供一种实现可快速释放的vlv访存阵列的方法,具有快速释放乱序资源,提升有限的硬件资源的利用率的功能,请参阅图1,包括如下步骤:

步骤一:当每次发生restart的时候,并且已经发送的次数等于返回次数时,id依然保持不变,下一个push进来的请求依然使用现有id;

步骤二:当每次发生restart,并且entry已经发送的次数不等于返回次数时,如果镜像资源没有满,进行以下特殊操作:

a:释放现有entry;

b:把entry的id、发送counter、返回counter复制到另一个结构中;

c:从freelist选出n个status为非busy的id,并把对应的busy置位,填到entry的id域;

步骤三:通过镜像资源用于存储restart未完成得请求时复制出来的请求信息,包括请求的id,发送counter和接收counter;

步骤四:接收counter会在被复制到镜像资源以后,继续monitor返回的响应,并完成自加过程,一旦发送和接收相同,释放当前镜像资源和id,free-list会根据释放的id完成更新操作;

步骤五:如果操作激进,并且当前释放的镜像资源是唯一可用的资源,可以在释放id的同一个周期把id重新复制回有restarted标志的entry,完成和entry信息的互换;

步骤六:通过free-list维护id的分配和回收,每次pushrequest的时候分配id,正常释放entry的时候回收id,或者镜像资源中完成请求的时候回收id。

通过上述方法,实现现在每个entry并不唯一对应一个固定的id,虽然是四个entry,可以总共有n个entryid(n>4)来分配,每个entry多出一个域来表示当前的entry的id,另外有一个freelist来维护所有entryid的状态,刚开始上电的时候,entry的id等于0,1,2依次递加,freelist的前四个id状态为busy,之后每次entry被正常释放(非restart的特殊释放),id保持不变,下一个push进来的请求依然使用现有id;当每次发生restart的时候,并且已经发送的次数等于返回次数时,id依然保持不变,下一个push进来的请求依然使用现有id;当每次发生restart,并且entry已经发送的次数不等于返回次数时,如果镜像资源没有满,进行以下特殊操作:

1.释放现有entry(清除entry的valid域)

2.把entry的id、发送counter、返回counter复制到另一个结构中

3.从freelist选出n个status为非busy的id,并把对应的busy置位,填到entry的id域。

可以在发生restart的时候,把没有结束的请求的少量信息转移到另一存储结构中,保证乱序资源主体的释放,提高了资源的利用率,把4个entry伪装成n个id的资源的效果,此外该结构还可以从面积或者时序上有折衷的方案,因为每次发生restart请求的时候,流水线需要重新加载新的指令,前端流水线的延迟可以让以上的操作不需要在一个周期内完成,比如一个流水线restart同时清除了4个有效的entry,每个entry都需要被释放,那么可以分四个周期做完所有的释放工作,需要复用之前的restarted标志位(每次发生restart置位),然后根据请求顺序,先释放最前面有restarted标志的entry,现在的工作简化成每次只需要把一个entry的必要信息复制到另一个结构,因此另一个镜像结构的分配和释放就变得异常简单,每次只需要分配一个小的entry,此外freelist也只需要查找一个空闲的id,并更新freelist。这样就可以把freelist做的很大,支持更多的id,id成为了一种实际上的乱序资源并且不被主体硬件资源制约。试想一种极端情况,连续的向量的访存被连续的取消,那么每次都需要释放4个entry,需要多出4个id用于分配新的entry,那么id的上限就决定了连续restart后,vlv访存的接收能力。另外用于存储未完成请求的镜像结构在设计中也需要考虑到本身乱序资源和id的数量。如果总量8个id,乱序资源是4个entry,那么不需要每次都把未完成的请求信息(id,发送counter和接收counter)都直接复制到镜像结构,比如已经发生了n次restart,有4笔未完成的请求被拷贝到镜像结构,那么其余只剩下最多4个可用的id,那么完全可以在乱序资源内部等待未完成请求的结束,一旦镜像结构有请求释放了空间,再从乱序资源内部把未完成的请求复制出来,并分配刚才释放的id。

镜像资源用于存储restart未完成得请求时复制出来的请求信息,包括请求的id,发送counter和接收counter,接收counter会在被复制到镜像资源以后,继续monitor返回的响应,并完成自加过程,一旦发送和接收相同,释放当前镜像资源和id,free-list会根据释放的id完成更新操作。当然如果操作激进,并且当前释放的镜像资源是唯一可用的资源,可以在释放id的同一个周期把id重新复制回有restarted标志的entry,完成和entry信息的互换。

free-list用于维护id的分配和回收,有两种方案:

1.每次pushrequest的时候分配id,正常释放entry的时候回收id,或者镜像资源中完成请求的时候回收id

2.每次pushrequest的时候不考虑id的分配,释放后的entry自然拥有可用的id,每次正常释放entry的时候(没有发生restart,顺利完成请求以及发生restart,顺利在entry完成请求),id保持不变,每次非正常释放entry的时候(发生restart,copy到镜像资源等待请求完成),从free-list中分配一个非busy状态的id,只有在镜像资源等待请求完成的时候回收id。

对于第二种方案,只要镜像资源、乱序资源、id总量控制合理,不需要考虑id的可用数量,只要保证镜像资源可用就可以分配到可用的id,比如镜像资源+乱序资源=id总量,如果镜像资源可用或乱序资源可用,free-list一定有空闲id。

本发明解决了restart之后资源的快速释放问题,但是正常情况下,乱序窗口的大小依旧取决于乱序资源,不受id数量的影响,如果id数量等于乱序资源数量,那就可以同时解决乱序窗口和释放问题,代价较大。

本发明通过在请求未完成不能及时释放资源的时候,以最小的代价维持请求的跟踪,用freelist的方式维护id,并在特定的阶段完成分配、回收,并且提供了两种不同的分配、回收方案以及镜像结构记录的信息和更新的时间点,达到了快速释放乱序资源,减少不必要的资源阻塞,用最小的开销,提升有限的硬件资源的利用率。

尽管已经示出和描述了本发明的实施例,对于本领域的普通技术人员而言,可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型,本发明的范围由所附权利要求及其等同物限定。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1