[发明专利]一种获取共享资源的协同仲裁方法及装置

说明书

本发明公开了一种获取共享资源的协同仲裁方法及装置，涉及信息技术领域，其方法包括以下步骤：协同仲裁器接收多个主机关于使用共享资源的请求，并将其转发给所述共享资源；所述协同仲裁器采集当前请求使用共享资源的所有主机的信息；所述协同仲裁器根据所采集的当前请求使用共享资源的所有主机的信息，计算出所述协同仲裁器下一次有效接收用于使用所述共享资源的请求的时间点；所述协同仲裁器将所述时间点发送给使用共享资源的所有主机，以便其进行关于使用所述共享资源的下一次请求。本发明通过由协同仲裁器与各级队列共同完成各主机对共享资源共享，并使所有主机获得响应的最晚时间点。

技术领域

本发明涉及信息技术领域，特别涉及一种获取共享资源的协同仲裁方法及装置。

背景技术

仲裁（Arbitration）一词广泛应用于人类日常事务的方方面面，例如公共会议室的分配方法，除了按照预订会议室的先后顺序之外，还需要考虑根据会议重要性不同而预留/锁定一些给高优先级的会议。具体到信息技术，仲裁可以定义为：针对多个用户/源对同一共享资源进行（一段时间）分时独占时的分配方法，例如网络带宽、总线带宽、存储带宽等等的分配方法。

一般来说仲裁器设计遵循以下原则：尽可能充分地利用共享资源；可设置用户优先级（遇到竞争时优先级高的用户先获得共享资源，平均下来其获得的带宽相对就高）；不会导致低优先级用户一直无法获得对共享资源的使用权（即保证优先级的同时保证一定的公平性）。传统的仲裁器设计即在以上原则中优化或折衷。随着系统设计复杂度越来越高，传统仲裁器的设计导致一个问题越来越严重，那就是：对用户/源端来说，仲裁导致的响应延迟不可确定性！

以图1仲裁示意图为例，n个用户/源主机master通过仲裁器Arbiter使用共享资源slave：某一刻master1向Arbiter发出对slave的读或写请求（①），而此刻Arbiter与slave之间的通路可能正在处理其他master的请求，从而导致Arbiter不能立刻接收master1的请求，并且不会告诉master1什么时候接收其请求。直到未来的某一刻，Arbiter终于可以接收master1的这次请求了（②），接下来master1（根据具体设计）可以非阻塞地继续请求或阻塞地等待响应。而这次被Arbiter接收的请求什么时候可以得到slave的响应（③），Arbiter也不会告知master1（仲裁可能级联，不能确定真正响应时间）。总结：图1中master1无法得知①与②之间、②与③之间这两次时间间隔。甚至Arbiter都不知道这些时间间隔，特别是多级级联仲裁的时候。

除了非常简单的只有一级仲裁器的结构之外（如图1），一般来说，在众master与slave之间可能有多级仲裁。现有的级联仲裁器，每一级Arbiter将互相冲突的并行请求并串转换为下一级的一个请求端口，最终只有一个请求端口与共享资源slave相连，如图2所示：由于仲裁器的级联，前一级被接收的请求（如图2中的master1的请求①被第一级仲裁器1st-level Arbiter#1接收，即②）被排序串行送往后一级等待仲裁（如1st-levelArbiter#1将master1到master j的有效请求并串转化为请求队列，作为新的请求等待第二级仲裁器2nd-level Arbiter#1的接收），从而导致：即使是每一级的Arbiter，也无法知道某一笔请求在下一级仲裁中什么时候可以被接收，更别提什么时候被slave响应了。

总的来说，现有的仲裁器设计都是一种单向的、无反馈决策系统，各master、甚至各级Arbiter无法预知响应延迟。

随着现代SoC系统设计复杂度指数增长，单芯片上集成的子系统/IP越来越多，为了实现资源的高效利用，各子系统之间、子系统内部的共享、子系统内部的共享设计也越来越多，仲裁器设计越来越复杂，且级联越来越多，从而导致：

1.当多源请求竞争激烈时，仲裁导致的延迟（仅考虑并串转换延迟，不考虑仲裁机制的额外开销）越来越长，特别是低优先级/被分配低带宽的master的请求响应延迟越来越长；