一种获取共享资源的协同仲裁方法及装置制造方法
【专利摘要】本发明公开了一种获取共享资源的协同仲裁方法及装置，涉及信息【技术领域】，其方法包括以下步骤：协同仲裁器接收多个主机关于使用共享资源的请求，并将其转发给所述共享资源；所述协同仲裁器采集当前请求使用共享资源的所有主机的信息；所述协同仲裁器根据所采集的当前请求使用共享资源的所有主机的信息，计算出所述协同仲裁器下一次有效接收用于使用所述共享资源的请求的时间点；所述协同仲裁器将所述时间点发送给使用共享资源的所有主机，以便其进行关于使用所述共享资源的下一次请求。本发明通过由协同仲裁器与各级队列共同完成各主机对共享资源共享，并使所有主机获得响应的最晚时间点。
【专利说明】一种获取共享资源的协同仲裁方法及装置
【技术领域】
[0001]本发明涉及信息【技术领域】，特别涉及一种获取共享资源的协同仲裁方法及装置。
【背景技术】
[0002]仲裁(Arbitrat1n) —词广泛应用于人类日常事务的方方面面，例如公共会议室的分配方法，除了按照预订会议室的先后顺序之外，还需要考虑根据会议重要性不同而预留/锁定一些给高优先级的会议。具体到信息技术，仲裁可以定义为:针对多个用户/源对同一共享资源进行(一段时间)分时独占时的分配方法，例如网络带宽、总线带宽、存储带宽等等的分配方法。
[0003]一般来说仲裁器设计遵循以下原则:尽可能充分地利用共享资源；可设置用户优先级(遇到竞争时优先级高的用户先获得共享资源，平均下来其获得的带宽相对就高)；不会导致低优先级用户一直无法获得对共享资源的使用权(即保证优先级的同时保证一定的公平性)。传统的仲裁器设计即在以上原则中优化或折衷。随着系统设计复杂度越来越高，传统仲裁器的设计导致一个问题越来越严重，那就是:对用户/源端来说，仲裁导致的响应延迟不可确定性！
[0004]以图1仲裁示意图为例,η个用户/源主机master通过仲裁器Arbiter使用共享资源slave:某一刻masterl向Arbiter发出对slave的读或写请求(①),而此刻Arbiter与slave之间的通路可能正在处理其他master的请求,从而导致Arbiter不能立刻接收masterl的请求,并且不会告诉masterl什么时候接收其请求。直到未来的某一刻,Arbiter终于可以接收masterl的这次请求了(②),接下来masterl (根据具体设计)可以非阻塞地继续请求或阻塞地等待响应。而这次被Arbiter接收的请求什么时候可以得到slave的响应(③)，Arbiter也不会告知masterl (仲裁可能级联,不能确定真正响应时间)。总结:图1中masterl无法得知①与②之间、②与③之间这两次时间间隔。甚至Arbiter都不知道这些时间间隔，特别是多级级联仲裁的时候。
[0005]除了非常简单的只有一级仲裁器的结构之外(如图1)，一般来说，在众master与slave之间可能有多级仲裁。现有的级联仲裁器，每一级Arbiter将互相冲突的并行请求并串转换为下一级的一个请求端口，最终只有一个请求端口与共享资源slave相连，如图2所示:由于仲裁器的级联，前一级被接收的请求(如图2中的masterl的请求①被第一级仲裁器lst-level Arbiter#I接收,即②)被排序串行送往后一级等待仲裁(如Ist-1evelArbiter#I将masterl到master j的有效请求并串转化为请求队列，作为新的请求等待第二级仲裁器2nd-level Arbiter#I的接收),从而导致:即使是每一级的Arbiter,也无法知道某一笔请求在下一级仲裁中什么时候可以被接收，更别提什么时候被slave响应了。
[0006]总的来说，现有的仲裁器设计都是一种单向的、无反馈决策系统，各master、甚至各级Arbiter无法预知响应延迟。
[0007]随着现代SoC系统设计复杂度指数增长，单芯片上集成的子系统/IP越来越多，为了实现资源的高效利用，各子系统之间、子系统内部的共享、子系统内部的共享设计也越来越多，仲裁器设计越来越复杂，且级联越来越多，从而导致:
[0008]1.当多源请求竞争激烈时，仲裁导致的延迟(仅考虑并串转换延迟，不考虑仲裁机制的额外开销)越来越长，特别是低优先级/被分配低带宽的master的请求响应延迟越来越长；
[0009]2.延迟与应用情况强相关(各master请求冲突情况)不可预知，从而无法在设计阶段确定仲裁导致的响应延迟不会影响系统功能或性能需求。
[0010]当前为了应对这类不可预知的延迟的方法有:
[0011]1.设计前期进行高层次建模,如ESL (Electronic System Level,电子系统级)建模，对系统架构进行完整分析。通过仿真统计备选总线、存储等带宽、延迟情况是否满足系统应用需求，是否会因为竞争导致的仲裁延迟影响系统功能或性能。然而真正的延迟情况很难获得，特别是当前的仲裁器设计需要时钟精确的仿真才能准确分析，从而导致在高层次架构分析阶段获得的结论往往误差很大。
[0012]2.过度设计。由于设计前期无法获得准确的分析结果，导致需要在架构分析结论基础上再预留20%甚至更多的余量来进行真正的设计，即过度设计。例如，总线要快、更快！DDR (Double Data Rate,双倍速率同步动态随机存储器)带宽要大、更大！ master侧、各级仲裁器开很大的缓存等等。然而，即使进行了过度的(可能多数情况下是浪费的)设计，也不能确保一定可以满足所有应用场景(除非前期的高层次仿真对各种极端情况进行了充分的、一定程度上来说很准确的分析)，一旦过度设计也没有满足某种极端恶劣应用场景，芯片或整系统还是可能会出现功能错误或性能不足。
[0013]此外，未知的延迟可能导致某些设计的master在等待响应期间不能或不方便在不同任务之间进行切换，只能等待。
【发明内容】
[0014]本发明的目的在于提供一种获取共享资源的协同仲裁方法及装置，能更好地解决在系统越来越复杂，仲裁级联越来越多，响应延迟也越来越大的情况下，可以预知响应延迟的问题。
[0015]根据本发明的一个方面，提供了一种获取共享资源的协同仲裁方法，包括以下步骤:
[0016]协同仲裁器接收多个主机关于使用共享资源的请求，并将其转发给所述共享资源；
[0017]所述协同仲裁器采集当前请求使用共享资源的所有主机的信息；
[0018]所述协同仲裁器根据所采集的当前请求使用共享资源的所有主机的信息，计算出所述协同仲裁器下一次有效接收用于使用所述共享资源的请求的时间点；
[0019]所述协同仲裁器将所述时间点发送给使用共享资源的所有主机，以便其进行关于使用所述共享资源的下一次请求。
[0020]优选地，所述当前请求使用共享资源的主机信息包括主机ID号和请求使用共享资源主机的请求长度。
[0021]优选地，还包括:
[0022]当所述协同仲裁器按照预设的规则顺序将多个主机关于使用共享资源的请求转发给所述共享资源时，则所述当前请求使用共享资源的所有主机将根据其预设的规则顺序确知在所述请求时间点的具体时间获得共享资源的响应。
[0023]优选地，还包括:
[0024]当所述当前请求使用共享资源的主机根据预设的规则顺序确知在所述请求时间点的具体时间获得共享资源的响应时无法满足其系统功能或性能需求时，所述当前请求使用共享资源的主机通过所述协同仲裁器向高层上报中断报警，以便请求优先处理。
[0025]优选地，所述协同仲裁器用于检测当前请求使用共享资源的所有主机及计算请求使用共享资源主机的请求长度之和=接收请求总长度。
[0026]优选地，所述计算出所述协同仲裁器下一次有效接收用于使用所述共享资源的请求的时间点包括:
[0027]当前接收请求总长度响应时间。
[0028]根据本发明的另一方面，提供了一种获取共享资源的协同仲裁装置，包括:
[0029]接收模块，用于协同仲裁器接收多个主机关于使用所述共享资源的请求，并将其转发给所述共享资源；
[0030]采集模块，用于协同仲裁器采集当前请求使用共享资源的所有主机的信息；
[0031]计算模块，用于协同仲裁器根据所采集的当前请求使用共享资源的所有主机的信息，计算出协同仲裁器下一次有效接收用于使用所述共享资源的请求的时间点；
[0032]反馈模块，用于协同仲裁器将所述时间点发送给使用共享资源的所有主机，以便其进行关于使用所述共享资源的下一次请求。
[0033]优选地，还包括:
[0034]共享资源单元，用于当所述协同仲裁器按照预设的规则顺序将多个主机关于使用共享资源的请求转发给所述共享资源时，则所述当前请求使用共享资源的所有主机将根据其预设的规则顺序确知在所述请求时间点的具体时间获得共享资源的响应。
[0035]优选地，所述接收模块包括:
[0036]检测单元，用于协同仲裁器检测当前请求使用共享资源的所有主机；
[0037]接收单元，用于协同仲裁器接收多个主机关于使用所述共享资源的请求；
[0038]发送单元，用于协同仲裁器将所述共享资源的请求转发给所述共享资源。
[0039]优选地，所述反馈模块包括:
[0040]确定单元，用于使用共享资源的所有主机通过接收所述协同仲裁器反馈的时间点。
[0041]与现有技术相比较，本发明的有益效果在于:
[0042]a)仲裁响应延迟可以根据每批请求协同确定，从而可以在系统架构分析阶段准确仿真明确设计满足功能和性能需求；
[0043]b)仲裁响应延迟可确定，使得各master可以利用这些等待延迟时间来切换到进行其他工作，而不用一直无效等待；
[0044]c)master及早地意识到可能无法及时获得响应时，可以在造成功能错误或性能不足前采取应急措施或善后准备。
【专利附图】
【附图说明】
[0045]图1是现有技术提供的一种仲裁示意图；
[0046]图2是现有技术提供的一种级联仲裁不意图；
[0047]图3是本发明提供的一种获取共享资源的协同仲裁方法流程图；
[0048]图4是本发明提供的一种获取共享资源的协同仲裁装置示意图；
[0049]图5是本发明实施例提供的一种获取共享资源的协同仲裁结构示意图；
[0050]图6是本发明实施例提供的一种获取共享资源的协同仲裁器示意图。
【具体实施方式】
[0051]以下结合附图对本发明的优选实施例进行详细说明，应当理解，以下所说明的优选实施例仅用于说明和解释本发明，并不用于限定本发明。
[0052]图3是本发明提供的一种获取共享资源的协同仲裁方法流程图，如图3所示，包括以下步骤:
[0053]步骤S301:协同仲裁器接收多个主机关于使用共享资源的请求，并将其转发给所述共孕资源；
[0054]步骤S302:所述协同仲裁器采集当前请求使用共享资源的所有主机的信息；
[0055]步骤S303:所述协同仲裁器根据所采集的当前请求使用共享资源的所有主机的信息，计算出所述协同仲裁器下一次有效接收用于使用所述共享资源的请求的时间点；
[0056]步骤S304:所述协同仲裁器将所述时间点发送给使用共享资源的所有主机，以便其进行关于使用所述共享资源的下一次请求。
[0057]其中，所述当前请求使用共享资源的主机信息包括主机ID号和请求使用共享资源主机的请求长度。
[0058]本发明还包括:当所述协同仲裁器按照预设的规则顺序将多个主机关于使用共享资源的请求转发给所述共享资源时，则所述当前请求使用共享资源的所有主机将根据其预设的规则顺序确知在所述请求时间点的具体时间获得共享资源的响应。
[0059]本发明还包括:当所述当前请求使用共享资源的主机根据预设的规则顺序确知在所述请求时间点的具体时间获得共享资源的响应时无法满足其系统功能或性能需求时，所述当前请求使用共享资源的主机通过所述协同仲裁器向高层上报中断报警，以便请求优先处理。
[0060]其中，所述协同仲裁器用于检测当前请求使用共享资源的所有主机及计算请求使用共享资源主机的请求长度之和=接收请求总长度。
[0061]所述计算出所述协同仲裁器下一次有效接收用于使用所述共享资源的请求的时间点包括:当前接收请求总长度响应时间。
[0062]图4是本发明提供的一种获取共享资源的协同仲裁装置示意图，如图4所示，包括:接收模块401，用于协同仲裁器接收多个主机关于使用所述共享资源的请求，并将其转发给所述共享资源；采集模块402，用于协同仲裁器采集当前请求使用共享资源的所有主机的信息；计算模块403，用于协同仲裁器根据所采集的当前请求使用共享资源的所有主机的信息，计算出协同仲裁器下一次有效接收用于使用所述共享资源的请求的时间点；反馈模块404，用于协同仲裁器将所述时间点发送给使用共享资源的所有主机，以便其进行关于使用所述共享资源的下一次请求。
[0063]本发明还包括:共享资源单元，用于当所述协同仲裁器按照预设的规则顺序将多个主机关于使用共享资源的请求转发给所述共享资源时，则所述当前请求使用共享资源的所有主机将根据其预设的规则顺序确知在所述请求时间点的具体时间获得共享资源的响应。
[0064]所述接收模块401包括:检测单元，用于协同仲裁器检测当前请求使用共享资源的所有主机；接收单元，用于协同仲裁器接收多个主机关于使用所述共享资源的请求；发送单元，用于协同仲裁器将所述共享资源的请求转发给所述共享资源。
[0065]所述反馈模块404包括:确定单元，用于使用共享资源的所有主机通过接收所述协同仲裁器反馈的时间点。
[0066]图5是本发明实施例提供的一种获取共享资源的协同仲裁结构示意图，如图5所示，由协同仲裁器Synergic Arbiter与各级队列Queue共同完成各主机master对共享资源slave共享的仲裁作用。
[0067]各级Queue仍如传统仲裁器设计一样,对与其相连的master有效请求进行接收请求ack (图1中的②)和按照设计的或可配置的优先级进行并转串排序。
[0068]此外，如果还对各master有设置带宽的需求(例如分配给masterl的带宽是master2 的两倍，则 Synergic Arbiter 和第一级队列 lst-level Queue#l 米样 masterl 请求的频率是master2请求频率的两倍:如对masterl的请求每批都采样,对master2的请求隔一批米样一次)。
[0069]这个由Synergic Arbiter采样/收集所有master (或者根据带宽设置当前可以被采样master)请求信息计算出来的有效请求总长度acked_req_len反馈给所有master,则所有master都可以得知当批被采样的有效请求将在接下来的时间段T内由各级Queue和slave顺序处理:
[0070]对于所有master来说，下一批请求获得接收将会在确定的时间T之后；
[0071]对于当批被采样的有有效请求的master来说,它们的请求获得slave的响应最晚会在时间T以内(T与acked_req_len成正比,该比率设计之初即可确定)；
[0072]如果事先设计各级Queue确定按照某种顺序,例如按照分配的master id大小顺序，并且Synergic Arbiter反馈给各有效请求master当前被采样的master id(图3中的有效请求主机IDs acked_req_master_ids,是一个向量),则各master可以根据自己的id在当前被采样master id向量中的排序而确知自己在时间T以内的哪个时刻获得slave响应。
[0073]因此，通过以上协同仲裁结构，众master可以获知每批次被采样的有效请求情况，从而得知下一次采样/接收请求的时间点，如T时刻之后(图1中的①与②时间间隔)，当批次被采样/接收的有效请求master可以获知自己的请求最晚在时间T以内(与acked_req_len成正比，该比率设计之初即可确定)可以获得响应(图1中的②与③时间间隔)，从而可以在这些提前预知的时间段内进行各种任务切换或者延迟过大报警等操作。
[0074]图6是本发明实施例提供的一种获取共享资源的协同仲裁器示意图，如图6所示，Synergic Arbiter负责采样/收集所有与slave有共享需求的master当前一批请求信息(是否有请求，以及请求读或写等连续猝发请求burst操作的长度为多少)，并计算得出接下来一段时间T内各级Queue所需要顺序排列的总的有效请求长度acked_req_len (各有效请求长度之和，如single请求长度为I,burst请求长度为粹发请求长度burst_len),时间T 与 acked_req_len @ΙΕΙ:匕。
[0075]本发明从传统的仲裁器单向、无反馈决策，转变为众master协同仲裁。具体阐述如下:
[0076]a)众master可以获得当前被仲裁器接收的所有有请求master的信息；
[0077]b)仲裁器安排本次接收的所有有请求master按照设计的先后顺序访问slave，并在此过程结束后接收下一批请求；
[0078]c)根据a)中获得的信息，众master可以获知仲裁器接收下一批请求的时间点，对于有请求master可以获知slave最晚响应自己时间点(甚至按照设计好的规则获知确切响应时间点)；
[0079]d)众master可以在确切可知的延迟时间段内进行其他操作(例如CPU切换进程)；
[0080]e)如果根据a)中获得的信息,对于有请求master获知slave最晚响应自己时间点无法满足其系统功能或性能需求，可以向高层上报中断报警，高层接到此类中断报警可以进行相应的应急处理或善后准备。
[0081]综上所述，本发明具有以下技术效果:
[0082]本发明多个主机通过获知每批次被采样的有效请求情况，得知下一次采样\接收请求的时间点，从而可以在提前预知的时间段内进行各种任务或者延迟过大报警等操作，提闻了用户体验。
[0083]尽管上文对本发明进行了详细说明，但是本发明不限于此，本【技术领域】技术人员可以根据本发明的原理进行各种修改。因此，凡按照本发明原理所作的修改，都应当理解为落入本发明的保护范围。
【权利要求】
1.一种获取共享资源的协同仲裁方法，其特征在于，包括以下步骤: 协同仲裁器接收多个主机关于使用共享资源的请求，并将其转发给所述共享资源； 所述协同仲裁器采集当前请求使用共享资源的所有主机的信息； 所述协同仲裁器根据所采集的当前请求使用共享资源的所有主机的信息，计算出所述协同仲裁器下一次有效接收用于使用所述共享资源的请求的时间点； 所述协同仲裁器将所述时间点发送给使用共享资源的所有主机，以便其进行关于使用所述共享资源的下一次请求。
2.根据权利要求1所述的方法，其特征在于，所述当前请求使用共享资源的主机信息包括主机ID号和请求使用共享资源主机的请求长度。
3.根据权利要求2所述的方法，其特征在于，还包括: 当所述协同仲裁器按照预设的规则顺序将多个主机关于使用共享资源的请求转发给所述共享资源时，则所述当前请求使用共享资源的所有主机将根据其预设的规则顺序确知在所述请求时间点的具体时间获得共享资源的响应。
4.根据权利要求3所述的方法，其特征在于，还包括: 当所述当前请求使用共享资源的主机根据预设的规则顺序确知在所述请求时间点的具体时间获得共享资源的响应时无法满足其系统功能或性能需求时，所述当前请求使用共享资源的主机通过所述协同仲裁器向高层上报中断报警，以便请求优先处理。
5.根据权利要求4所述的方法，其特征在于，所述协同仲裁器用于检测当前请求使用共享资源的所有主机及计算请求使用共享资源主机的请求长度之和=接收请求总长度。
6.根据权利要求1所述的方法，其特征在于，所述计算出所述协同仲裁器下一次有效接收用于使用所述共享资源的请求的时间点包括: 当前接收请求总长度响应时间。
7.一种获取共享资源的协同仲裁装置，其特征在于，包括: 接收模块，用于协同仲裁器接收多个主机关于使用所述共享资源的请求，并将其转发给所述共享资源； 采集模块，用于协同仲裁器采集当前请求使用共享资源的所有主机的信息； 计算模块，用于协同仲裁器根据所采集的当前请求使用共享资源的所有主机的信息，计算出协同仲裁器下一次有效接收用于使用所述共享资源的请求的时间点； 反馈模块，用于协同仲裁器将所述时间点发送给使用共享资源的所有主机，以便其进行关于使用所述共享资源的下一次请求。
8.根据权利要求7所述的装置，其特征在于，还包括: 共享资源单元，用于当所述协同仲裁器按照预设的规则顺序将多个主机关于使用共享资源的请求转发给所述共享资源时，则所述当前请求使用共享资源的所有主机将根据其预设的规则顺序确知在所述请求时间点的具体时间获得共享资源的响应。
9.根据权利要求7所述的装置，其特征在于，所述接收模块包括: 检测单元，用于协同仲裁器检测当前请求使用共享资源的所有主机； 接收单元，用于协同仲裁器接收多个主机关于使用所述共享资源的请求； 发送单元，用于协同仲裁器将所述共享资源的请求转发给所述共享资源。
10.根据权利要求7所述的装置，其特征在于，所述反馈模块包括:确定单元，用于使用共享资源的所有主机通过接收所述协同仲裁器反馈的时间点。
【文档编号】H04L12/937GK104243359SQ201310246721
【公开日】2014年12月24日 申请日期:2013年6月20日 优先权日:2013年6月20日
【发明者】张林生 申请人:中兴通讯股份有限公司