WO2014201923A1 - 一种获取共享资源的协同仲裁方法及装置 - Google Patents
一种获取共享资源的协同仲裁方法及装置 Download PDFInfo
- Publication number
- WO2014201923A1 WO2014201923A1 PCT/CN2014/077390 CN2014077390W WO2014201923A1 WO 2014201923 A1 WO2014201923 A1 WO 2014201923A1 CN 2014077390 W CN2014077390 W CN 2014077390W WO 2014201923 A1 WO2014201923 A1 WO 2014201923A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- request
- shared resource
- arbiter
- hosts
- shared
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 34
- 230000004044 response Effects 0.000 claims description 34
- 238000003860 storage Methods 0.000 claims description 7
- 238000001514 detection method Methods 0.000 claims 2
- 238000005516 engineering process Methods 0.000 abstract description 3
- 238000010586 diagram Methods 0.000 description 16
- 230000006870 function Effects 0.000 description 8
- 238000004590 computer program Methods 0.000 description 7
- 238000004458 analytical method Methods 0.000 description 5
- 230000002195 synergetic effect Effects 0.000 description 5
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 238000005070 sampling Methods 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 230000001010 compromised effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000007257 malfunction Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 238000004088 simulation Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
- H04L47/826—Involving periods of time
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
- H04L47/822—Collecting or measuring resource availability data
Definitions
- the present invention relates to the field of information technology, and in particular, to a collaborative arbitration method and apparatus for acquiring shared resources. Background technique
- Arbitration is widely used in all aspects of human daily affairs, such as the allocation method of public meeting rooms. In addition to the order of meeting rooms, it is also necessary to consider reservation/locking according to the importance of the meeting. Priority meeting. Specific to information technology, arbitration can be defined as: a method of allocating time-sharing exclusive allocation (for a period of time) to multiple shared users/sources, such as network bandwidth, bus bandwidth, storage bandwidth, and the like.
- the arbiter design follows the following principles: Make full use of shared resources as much as possible; User priority can be set (users with higher priority in the event of competition will first obtain shared resources, and the average bandwidth obtained by them will be relatively high); It does not cause low-priority users to always have access to shared resources (that is, to ensure priority while ensuring certain fairness).
- Traditional arbiter design is optimized or compromised in the above principles. As system design complexity becomes higher and higher, the design of the traditional arbiter leads to an increasingly serious problem: that is, for the user/source, the response delay caused by arbitration is undeterminable.
- n users/source masters use shared resources (slavery) through the arbiter: Arbiter sends a read or write request to the slave to the Arbiter (1), and now Arbiter The path to the slave may be processing requests from other masters, causing Arbiter not to receive masterl requests immediately, and will not tell masterl when to receive its requests. Until the moment, Arbiter can finally receive the request from masterl (2), then masterl (depending on the design) can continue non-blocking Request or block waiting for a response. And when the request received by Arbiter can get the response of the slave (3), Arbiter will not tell masterl (the arbitration may cascade, the true response time cannot be determined). Summary: In Figure 1, masterl cannot know the two time intervals between 1 and 2 and between 2 and 3. Even Arbiter does not know these time intervals, especially when multi-level cascading arbitration.
- each level of Arbiter converts mutually conflicting parallel requests into one request port of the next level, and finally only one request port is connected with the shared resource slave, as shown in FIG. 2: due to the arbiter Cascading, the request received by the previous stage (the request 1 of masterl in Figure 2 is received by the first-stage arbiter 1 st-level Arbiter #1, ie 2) is sorted and serially sent to the next stage for arbitration.
- the existing arbiter design is a one-way, non-feedback decision system, and the master, and even the various levels of Arbiter cannot predict the response delay.
- Overdesign Due to the inability to obtain accurate analysis results in the early stage of design, it is necessary to reserve a margin of 20% or more on the basis of the analysis of the architecture to carry out the real design, that is, over-design.
- the bus should be fast, the DDR (Double Data Rate) bandwidth should be large, the master side, the arbiters at each level should have a large cache, and so on.
- DDR Double Data Rate
- the master side the arbiters at each level should have a large cache, and so on.
- it can't ensure that all application scenarios can be met. Once the over-design is not enough to meet some extreme application scenarios, the chip or the whole system may still have functional errors or insufficient performance.
- an unknown delay may cause some designed masters to be unable or inconvenient to switch between different tasks while waiting for a response, and can only wait.
- the object of the present invention is to provide a cooperative arbitration method and device for acquiring shared resources, which can better solve the problem that the system becomes more and more complex, the arbitration cascade is more and more, and the response delay is also larger. Predict the problem of response delay.
- a collaborative arbitration method for acquiring a shared resource including:
- the collaborative arbiter receives a request from a plurality of hosts for using the shared resource and forwards the request to the shared resource;
- the cooperative arbiter collects information of all hosts currently requesting to use the shared resource;
- the collaborative arbiter calculates information of the next valid reception of the collaborative arbiter by using information of all hosts of the shared resource according to the current request collected; The point in time for the request to use the shared resource;
- the collaborative arbiter sends the point in time to all hosts that use the shared resource for it to make a next request for use of the shared resource.
- the host information of the current request to use the shared resource includes a host ID number and a request length of requesting to use the shared resource host.
- the cooperative arbiter forwards, to the shared resource, a request for using the shared resource to the shared resource, and the request includes: forwarding the request to the shared resource;
- the method further includes: the current request to use all the hosts of the shared resource according to the preset rule The sequence determines that a response to the shared resource is obtained at a specific time at the requesting time point.
- the method further comprises:
- the current requesting host uses the shared resource according to a preset rule order to determine that the system function or performance requirement cannot be met when the response to the shared resource is obtained at the specific time of the request time point, the current request uses the shared resource.
- the host reports an interrupt alarm to the upper layer through the collaborative arbiter to request priority processing.
- the method further comprises:
- the collaborative arbiter detects all hosts currently requesting to use the shared resource, and calculates a total length of the received request, the total length of the received request being the sum of request lengths requesting to use the shared resource host.
- the calculating a time point at which the collaborative arbiter next validly receives a request for using the shared resource includes:
- the current received request total length response time is calculated, and the current receiving request total response time is proportional to the total length of the receiving request.
- a cooperative arbitration apparatus for acquiring a shared resource including:
- a receiving module configured to receive, by the collaborative arbiter, a request of the multiple hosts to use the shared resource, and forward the request to the shared resource;
- the collection module is configured to cooperate with the arbiter to collect information of all hosts currently requesting to use the shared resource;
- a computing module configured to cooperate with the arbiter to use information of all hosts sharing the resource according to the current request being collected, and calculate a time point at which the collaborative arbiter next validly receives the request for using the shared resource;
- the feedback module is configured to cooperate with the arbiter to send the point in time to all hosts using the shared resource for the next request to use the shared resource.
- the receiving module includes:
- a detecting unit configured to cooperate with the arbiter to detect all hosts currently requesting to use the shared resource; and the receiving unit, configured to receive, by the cooperative arbiter, a request of the multiple hosts to use the shared resource;
- the detecting unit is further configured to calculate a total length of the receiving request, where the total length of the receiving request is a sum of request lengths of requesting to use the shared resource host.
- the calculating module is specifically configured to calculate a total response time of the current receiving request, where the current receiving request total response time is proportional to the total length of the receiving request.
- Embodiments of the present invention also provide a computer storage medium in which computer executable instructions are stored, the computer executable instructions being used to perform the above method.
- the arbitration response delay can be determined collaboratively based on each batch of requests, so that the system can be accurately simulated during the system architecture analysis phase to clearly meet the functional and performance requirements;
- the arbitration response delay can be determined so that each master can use these wait delay times to switch to other work without having to wait for invalidity
- FIG. 3 is a flowchart of a cooperative arbitration method for acquiring a shared resource according to an embodiment of the present invention
- FIG. 4 is a schematic diagram of a cooperative arbitration device for acquiring a shared resource according to an embodiment of the present invention
- FIG. 6 is a schematic diagram of a collaborative arbiter for acquiring shared resources according to an embodiment of the present invention.
- FIG. 3 is a flowchart of a collaborative arbitration method for acquiring a shared resource according to an embodiment of the present invention. As shown in FIG. 3, the method includes the following steps:
- Step S301 The collaborative arbiter receives a request of the multiple hosts for using the shared resource, and forwards the request to the shared resource.
- Step S302 The collaborative arbiter collects all hosts that currently request to use the shared resource. Information
- Step S303 The cooperative arbiter uses the information of all the hosts of the shared resource according to the current request that is collected, and calculates a time point at which the collaborative arbiter next effectively receives the request for using the shared resource.
- Step S304 The collaborative arbiter sends the time point to all hosts using the shared resource, so that it makes a next request for using the shared resource.
- the host information of the current request using the shared resource includes a host ID number and a request length of requesting to use the shared resource host.
- the embodiment of the present invention further includes: when the collaborative arbiter forwards a request of the multiple hosts for using the shared resource to the shared resource according to a preset rule sequence, then all hosts that use the shared resource for the current request are based on The preset rule order determines that a response to the shared resource is obtained at a specific time of the request time point.
- the embodiment of the present invention further includes: when the host that currently requests to use the shared resource determines, according to a preset rule sequence, that the system function or performance requirement cannot be met when the response of the shared resource is obtained at a specific time of the request time point, The host that currently requests to use the shared resource reports an interrupt alarm to the upper layer through the collaborative arbiter to request priority processing.
- the calculating a time point at which the collaborative arbiter next validly receives a request for using the shared resource includes: a current receiving request total length response time.
- FIG. 4 is a schematic diagram of a cooperative arbitration apparatus for acquiring a shared resource according to an embodiment of the present invention.
- the method includes: a receiving module 401 configured to receive, by a cooperative arbiter, a request of multiple hosts to use the shared resource, And forwarding the data to the shared resource; the collecting module 402 is configured to cooperate with the arbiter to collect information of all hosts currently requesting to use the shared resource; and the calculating module 403 is configured to cooperate with the arbiter according to the current request of the collected set.
- Shared resources for all hosts Information calculating a time point at which the collaborative arbiter next validly receives a request for using the shared resource; the feedback module 404 is configured to cooperate with the arbiter to send the time point to all hosts using the shared resource, so as to perform About the next request to use the shared resource.
- the embodiment of the present invention further includes: a shared resource unit, configured to: when the collaborative arbiter forwards a request of the multiple hosts for using the shared resource to the shared resource according to a preset rule sequence, the current request uses the shared All hosts of the resource will determine the response of the shared resource at the specific time of the request time point according to their preset rule order.
- a shared resource unit configured to: when the collaborative arbiter forwards a request of the multiple hosts for using the shared resource to the shared resource according to a preset rule sequence, the current request uses the shared All hosts of the resource will determine the response of the shared resource at the specific time of the request time point according to their preset rule order.
- the receiving module 401 includes: a detecting unit configured to cooperate with an arbiter to detect all hosts currently requesting to use the shared resource; and a receiving unit configured to receive, by the cooperative arbiter, a request of the multiple hosts to use the shared resource; sending unit, configuring A request for the shared resource is forwarded to the shared resource for a collaborative arbiter.
- the feedback module 404 includes: a determining unit configured to use all the hosts sharing resources to receive a point in time when the cooperative arbiter feedbacks.
- FIG. 5 is a schematic diagram of a collaborative arbitration structure for acquiring shared resources according to an embodiment of the present invention. As shown in FIG. 5, a cooperative arbiter Synergic Arbiter and a queue Queue at all levels complete the arbitration function of the shared resource slave sharing by the host master. .
- the Queue like the traditional arbiter design, performs a receive request ack (2 in Figure 1) and a sorted order according to the designed or configurable priority for the master valid request connected to it.
- the frequency of the masterl request is the frequency of the master2 request. Twice: If the request for masterl is the same for each batch, the request for master2 is the same every other batch;).
- the next batch of requests will be received after the determined time T; for the masters with valid requests when the batch is sampled, their request to get the slave's response will be within the time T at the latest ( T is proportional to acked-reqjen, which can be determined at the beginning of the design);
- each master can know which time within time T gets the slave response according to the order of its own id in the current master id vector.
- the master can know the valid request status of each batch, so as to know the time point of the next sample/reception request, such as after time T (1 and 2 times in Fig. 1) Interval), when the batch is sampled/received, the valid request master can know that his request is within the time T at the latest (in proportion to acked-reqjen, the ratio can be determined at the beginning of the design) to obtain the response (in Figure 1 2 and 3 time intervals), so that various task switching or delaying excessive alarms can be performed during these advance-predicted time periods.
- FIG. 6 is a schematic diagram of a collaborative arbiter for acquiring shared resources according to an embodiment of the present invention.
- Synergic Arbiter is responsible for sampling/collecting all current request information of all masters sharing requirements with the slave (whether or not there is a request) And the length of the continuous burst request burst operation such as requesting read or write, and calculating the total effective request length acked-reqjen (the length of each valid request) in the order of the Queues in the next period of time T And, such as single request length is 1, burst request length is burst request length burst-len), time T is proportional to acked_req_len.
- the embodiment of the invention further provides a computer storage medium, wherein the computer is executable
- the embodiment of the invention changes from the traditional arbiter one-way, no feedback decision to the master master collaborative arbitration. The details are as follows:
- the master can obtain all the information of the requested master currently received by the arbiter; b) The arbiter arranges all the requested masters received this time to access the slave in the order of design, and receives the next batch after the process ends.
- the master can know the time point when the arbiter receives the next batch of requests.
- the slave can know the latest response time of the slave (even according to the designed rules to know the exact response time point). );
- the master can perform other operations within the exact known delay period (such as CPU switching process);
- the requesting master knows that the slave can't meet its system function or performance requirement at the latest time, it can report the interrupt alarm to the upper layer, and the upper layer can receive the corresponding interrupt alarm. Emergency treatment or preparation for rehabilitation.
- a plurality of hosts know the effective request status of each batch, and know the time point of the next sampling/receiving request, so that various tasks can be performed or the delay is too large in a predetermined time period. Operations such as alarms improve the user experience.
- each unit may be a central processing unit (CPU), a digital signal processor (DSP), or a Field-Programmable Gate Array (FPGA) in an electronic device. achieve.
- CPU central processing unit
- DSP digital signal processor
- FPGA Field-Programmable Gate Array
- embodiments of the present invention can be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of a hardware embodiment, a software embodiment, or a combination of software and hardware. Moreover, the present invention is applicable to one or more computer-usable storage media (including but not limited to disks) having computer usable program code embodied therein. A form of computer program product embodied on a memory and optical storage, etc.).
- the computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture comprising the instruction device.
- the apparatus implements the functions specified in one or more blocks of a flow or a flow and/or block diagram of the flowchart.
- These computer program instructions can also be loaded onto a computer or other programmable data processing device such that a series of operational steps are performed on a computer or other programmable device to produce computer-implemented processing for execution on a computer or other programmable device.
- the instructions provide steps for implementing the functions specified in one or more of the flow or in a block or blocks of a flow diagram.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Bus Control (AREA)
- Multi Processors (AREA)
Abstract
本发明公开了一种获取共享资源的协同仲裁方法及装置，涉及信息技术领域，其方法包括以下步骤：协同仲裁器接收多个主机关于使用共享资源的请求，并将其转发给所述共享资源；所述协同仲裁器采集当前请求使用共享资源的所有主机的信息；所述协同仲裁器根据所采集的当前请求使用共享资源的所有主机的信息，计算出所述协同仲裁器下一次有效接收用于使用所述共享资源的请求的时间点；所述协同仲裁器将所述时间点发送给使用共享资源的所有主机，以便其进行关于使用所述共享资源的下一次请求。
Description
一种获取共享资源的协同仲裁方法及装置 技术领域
本发明涉及信息技术领域， 特别涉及一种获取共享资源的协同仲裁方 法及装置。 背景技术
仲裁（ Arbitration )一词广泛应用于人类日常事务的方方面面， 例如公 共会议室的分配方法， 除了按照预订会议室的先后顺序之外， 还需要考虑 根据会议重要性不同而预留 /锁定一些给高优先级的会议。具体到信息技术， 仲裁可以定义为： 针对多个用户 /源对同一共享资源进行（一段时间）分时 独占时的分配方法， 例如网络带宽、 总线带宽、 存储带宽等等的分配方法。
一般来说仲裁器设计遵循以下原则： 尽可能充分地利用共享资源； 可 设置用户优先级（遇到竟争时优先级高的用户先获得共享资源， 平均下来 其获得的带宽相对就高）； 不会导致低优先级用户一直无法获得对共享资源 的使用权（即保证优先级的同时保证一定的公平性）。 传统的仲裁器设计即 在以上原则中优化或折衷。 随着系统设计复杂度越来越高， 传统仲裁器的 设计导致一个问题越来越严重， 那就是： 对用户 /源端来说， 仲裁导致的响 应延迟不可确定性。
以图 1仲裁示意图为例， n个用户 /源主机（ master )通过仲裁器（ Arbiter ) 使用共享资源 （ slave ): 某一刻 masterl向 Arbiter发出对 slave的读或写请 求（①）， 而此刻 Arbiter与 slave之间的通路可能正在处理其他 master的请 求， 从而导致 Arbiter不能立刻接收 masterl的请求， 并且不会告诉 masterl 什么时候接收其请求。 直到未来的某一刻， Arbiter终于可以接收 masterl 的这次请求了 （②）， 接下来 masterl (根据具体设计）可以非阻塞地继续
请求或阻塞地等待响应。 而这次被 Arbiter接收的请求什么时候可以得到 slave的响应 （③）， Arbiter也不会告知 masterl (仲裁可能级联， 不能确定 真正响应时间）。 总结： 图 1 中 masterl无法得知①与②之间、 ②与③之间 这两次时间间隔。 甚至 Arbiter都不知道这些时间间隔， 特别是多级级联仲 裁的时候。
除了非常简单的只有一级仲裁器的结构之外 （如图 1 )， 一般来说， 在 众 master与 slave之间可能有多级仲裁。现有的级联仲裁器，每一级 Arbiter 将互相冲突的并行请求并串转换为下一级的一个请求端口， 最终只有一个 请求端口与共享资源 slave相连， 如图 2所示： 由于仲裁器的级联， 前一级 被接收的请求（如图 2中的 masterl的请求①被第一级仲裁器 1 st-level Arbiter #1接收， 即② )被排序串行送往后一级等待仲裁（如 1 st-level Arbiter #1将 masterl到 master j的有效请求并串转化为请求队列， 作为新的请求等待第 二级仲裁器 2nd-level Arbiter #1的接收），从而导致：即使是每一级的 Arbiter, 也无法知道某一笔请求在下一级仲裁中什么时候可以被接收， 更别提什么 时候被 slave响应了。
总的来说， 现有的仲裁器设计都是一种单向的、 无反馈决策系统， 各 master, 甚至各级 Arbiter无法预知响应延迟。
随着现代 SoC系统设计复杂度指数增长，单芯片上集成的子系统 /IP越 来越多， 为了实现资源的高效利用， 各子系统之间、 子系统内部的共享、 子系统内部的共享设计也越来越多， 仲裁器设计越来越复杂， 且级联越来 越多， 从而导致：
1. 当多源请求竟争激烈时， 仲裁导致的延迟（仅考虑并串转换延迟， 不考虑仲裁机制的额外开销）越来越长， 特别是低优先级 /被分配低带宽的 master的请求响应延迟越来越长；
2. 延迟与应用情况强相关（各 master请求冲突情况） 不可预知， 从而
无法在设计阶段确定仲裁导致的响应延迟不会影响系统功能或性能需求。 当前为了应对这类不可预知的延迟的方法有：
1. 设计前期进行高层次建模， 如 ESL ( Electronic System Level, 电子 系统级）建模， 对系统架构进行完整分析。 通过仿真统计备选总线、 存储 等带宽、 延迟情况是否满足系统应用需求， 是否会因为竟争导致的仲裁延 迟影响系统功能或性能。 然而真正的延迟情况很难获得， 特别是当前的仲 裁器设计需要时钟精确的仿真才能准确分析， 从而导致在高层次架构分析 阶段获得的结论往往误差很大。
2. 过度设计。 由于设计前期无法获得准确的分析结果， 导致需要在架 构分析结论基础上再预留 20%甚至更多的余量来进行真正的设计， 即过度 设计。 例如， 总线要快、 DDR ( Double Data Rate, 双倍速率同步动态随机 存储器） 带宽要大、 master侧、 各级仲裁器开很大的緩存等等。 然而， 即 使进行了过度的设计， 也不能确保一定可以满足所有应用场景， 一旦过度 设计也没有满足某种极端恶劣应用场景， 芯片或整系统还是可能会出现功 能错误或性能不足。
此外， 未知的延迟可能导致某些设计的 master在等待响应期间不能或 不方便在不同任务之间进行切换， 只能等待。 发明内容
本发明的目的在于提供一种获取共享资源的协同仲裁方法及装置， 能 更好地解决在系统越来越复杂， 仲裁级联越来越多， 响应延迟也越来越大 的情况下， 可以预知响应延迟的问题。
根据本发明实施例的一个方面， 提供了一种获取共享资源的协同仲裁 方法， 包括：
协同仲裁器接收多个主机关于使用共享资源的请求， 并将其转发给所 述共享资源；
所述协同仲裁器釆集当前请求使用共享资源的所有主机的信息； 所述协同仲裁器根据所釆集的当前请求使用共享资源的所有主机的信 息， 计算出所述协同仲裁器下一次有效接收用于使用所述共享资源的请求 的时间点；
所述协同仲裁器将所述时间点发送给使用共享资源的所有主机， 以便 其进行关于使用所述共享资源的下一次请求。
优选地， 所述当前请求使用共享资源的主机信息包括主机 ID号和请求 使用共享资源主机的请求长度。
优选地， 所述协同仲裁器多个主机关于使用共享资源的请求转发给共 享资源， 包括： 的请求转发给所述共享资源；
所述协同仲裁器按照预设的规则顺序将多个主机关于使用共享资源的 请求转发给所述共享资源之后， 该方法还包括： 所述当前请求使用共享资 源的所有主机根据其预设的规则顺序确知在所述请求时间点的具体时间获 得共享资源的响应。
优选地， 该方法还包括：
当所述当前请求使用共享资源的主机根据预设的规则顺序确知在所述 请求时间点的具体时间获得共享资源的响应时无法满足其系统功能或性能 需求时， 所述当前请求使用共享资源的主机通过所述协同仲裁器向高层上 报中断报警， 以便请求优先处理。
优选地， 该方法还包括：
所述协同仲裁器检测当前请求使用共享资源的所有主机， 及计算接收 请求总长度， 所述接收请求总长度为请求使用共享资源主机的请求长度之 和。
优选地， 所述计算出所述协同仲裁器下一次有效接收用于使用所述共 享资源的请求的时间点包括：
计算当前接收请求总长度响应时间， 所述当前接收请求总响应时间与 所述接收请求总长度成正比。
根据本发明实施例的另一方面， 提供了一种获取共享资源的协同仲裁 装置， 包括：
接收模块， 配置为协同仲裁器接收多个主机关于使用所述共享资源的 请求， 并将其转发给所述共享资源；
釆集模块， 配置为协同仲裁器釆集当前请求使用共享资源的所有主机 的信息；
计算模块， 配置为协同仲裁器根据所釆集的当前请求使用共享资源的 所有主机的信息， 计算出协同仲裁器下一次有效接收用于使用所述共享资 源的请求的时间点；
反馈模块， 配置为协同仲裁器将所述时间点发送给使用共享资源的所 有主机， 以便其进行关于使用所述共享资源的下一次请求。
优选地， 所述接收模块包括：
检测单元， 配置为协同仲裁器检测当前请求使用共享资源的所有主机； 接收单元， 配置为协同仲裁器接收多个主机关于使用所述共享资源的 请求；
发送单元， 配置为协同仲裁器将所述共享资源的请求转发给所述共享 资源。
优选地， 所述检测单元， 还配置为计算接收请求总长度， 所述接收请 求总长度为请求使用共享资源主机的请求长度之和。
优选的， 所述计算模块， 具体配置为计算当前接收请求总响应时间， 所述当前接收请求总响应时间与所述接收请求总长度成正比。
本发明实施例还提出了一种计算机存储介质， 其中存储有计算机可执 行指令， 所述计算机可执行指令用于执行上述的方法。
与现有技术相比较， 本发明实施例的有益效果在于：
仲裁响应延迟可以根据每批请求协同确定， 从而可以在系统架构分析 阶段准确仿真明确设计满足功能和性能需求；
仲裁响应延迟可确定， 使得各 master可以利用这些等待延迟时间来切 换到进行其他工作， 而不用一直无效等待；
master及早地意识到可能无法及时获得响应时， 可以在造成功能错误 或性能不足前釆取应急措施或善后准备。 附图说明
图 1是现有技术提供的一种仲裁示意图；
图 2是现有技术提供的一种级联仲裁示意图；
图 3是本发明实施例提供的一种获取共享资源的协同仲裁方法流程图； 图 4是本发明实施例提供的一种获取共享资源的协同仲裁装置示意图； 图 5是本发明实施例提供的一种获取共享资源的协同仲裁结构示意图； 图 6是本发明实施例提供的一种获取共享资源的协同仲裁器示意图。 具体实施方式
以下结合附图对本发明的优选实施例进行详细说明， 应当理解， 以下 所说明的优选实施例仅用于说明和解释本发明， 并不用于限定本发明。
图 3是本发明实施例提供的一种获取共享资源的协同仲裁方法流程图， 如图 3所示， 包括以下步骤：
步骤 S301 : 协同仲裁器接收多个主机关于使用共享资源的请求， 并将 其转发给所述共享资源；
步骤 S302: 所述协同仲裁器釆集当前请求使用共享资源的所有主机的
信息；
步骤 S303: 所述协同仲裁器根据所釆集的当前请求使用共享资源的所 有主机的信息， 计算出所述协同仲裁器下一次有效接收用于使用所述共享 资源的请求的时间点；
步骤 S304: 所述协同仲裁器将所述时间点发送给使用共享资源的所有 主机， 以便其进行关于使用所述共享资源的下一次请求。
其中， 所述当前请求使用共享资源的主机信息包括主机 ID号和请求使 用共享资源主机的请求长度。
本发明实施例还包括： 当所述协同仲裁器按照预设的规则顺序将多个 主机关于使用共享资源的请求转发给所述共享资源时， 则所述当前请求使 用共享资源的所有主机将根据其预设的规则顺序确知在所述请求时间点的 具体时间获得共享资源的响应。
本发明实施例还包括： 当所述当前请求使用共享资源的主机根据预设 的规则顺序确知在所述请求时间点的具体时间获得共享资源的响应时无法 满足其系统功能或性能需求时， 所述当前请求使用共享资源的主机通过所 述协同仲裁器向高层上报中断报警， 以便请求优先处理。
其中， 所述协同仲裁器用于检测当前请求使用共享资源的所有主机及 计算请求使用共享资源主机的请求长度之和=接收请求总长度。
所述计算出所述协同仲裁器下一次有效接收用于使用所述共享资源的 请求的时间点包括： 当前接收请求总长度响应时间。
图 4是本发明实施例提供的一种获取共享资源的协同仲裁装置示意图， 如图 4所示， 包括： 接收模块 401， 配置为协同仲裁器接收多个主机关于使 用所述共享资源的请求， 并将其转发给所述共享资源； 釆集模块 402， 配置 为协同仲裁器釆集当前请求使用共享资源的所有主机的信息； 计算模块 403， 配置为协同仲裁器根据所釆集的当前请求使用共享资源的所有主机的
信息， 计算出协同仲裁器下一次有效接收用于使用所述共享资源的请求的 时间点； 反馈模块 404， 配置为协同仲裁器将所述时间点发送给使用共享资 源的所有主机， 以便其进行关于使用所述共享资源的下一次请求。
本发明实施例还包括： 共享资源单元， 配置为当所述协同仲裁器按照 预设的规则顺序将多个主机关于使用共享资源的请求转发给所述共享资源 时， 则所述当前请求使用共享资源的所有主机将根据其预设的规则顺序确 知在所述请求时间点的具体时间获得共享资源的响应。
所述接收模块 401 包括： 检测单元， 配置为协同仲裁器检测当前请求 使用共享资源的所有主机； 接收单元， 配置为协同仲裁器接收多个主机关 于使用所述共享资源的请求； 发送单元， 配置为协同仲裁器将所述共享资 源的请求转发给所述共享资源。
所述反馈模块 404 包括： 确定单元， 配置为使用共享资源的所有主机 通过接收所述协同仲裁器反馈的时间点。
图 5是本发明实施例提供的一种获取共享资源的协同仲裁结构示意图， 如图 5所示， 由协同仲裁器 Synergic Arbiter与各级队列 Queue共同完成各 主机 master对共享资源 slave共享的仲裁作用。
各级 Queue仍如传统仲裁器设计一样， 对与其相连的 master有效请求 进行接收请求 ack (图 1中的② )和按照设计的或可配置的优先级进行并转 串排序。
此外，如果还对各 master有设置带宽的需求（例如分配给 masterl的带 宽是 master2的两倍， 则 Synergic Arbiter和第一级队列 lst-level Queue #1 釆样 masterl请求的频率是 master2请求频率的两倍： 如对 masterl的请求 每批都釆样， 对 master2的请求隔一批釆样一次；)。
这个由 Synergic Arbiter釆样 /收集所有 master (或者根据带宽设置当前 可以被釆样 master )请求信息计算出来的有效请求总长度 acked_req_len反
馈给所有 master, 则所有 master都可以得知当批被釆样的有效请求将在接 下来的时间段 T内由各级 Queue和 slave顺序处理：
对于所有 master来说，下一批请求获得接收将会在确定的时间 T之后； 对于当批被釆样的有有效请求的 master来说，它们的请求获得 slave的 响应最晚会在时间 T以内 （ T与 acked— reqjen成正比， 该比率设计之初即 可确定）；
如果事先设计各级 Queue确定按照某种顺序，例如按照分配的 master id 大小顺序， 并且 Synergic Arbiter反馈给各有效请求 master 当前被釆样的 master id (图 3中的有效请求主机 IDs acked_req_master_ids , 是一个向量）， 则各 master可以根据自己的 id在当前被釆样 master id向量中的排序而确知 自己在时间 T以内的哪个时刻获得 slave响应。
因此， 通过以上协同仲裁结构， 众 master可以获知每批次被釆样的有 效请求情况， 从而得知下一次釆样 /接收请求的时间点， 如 T时刻之后 （图 1中的①与②时间间隔）， 当批次被釆样 /接收的有效请求 master可以获知自 己的请求最晚在时间 T以内 （与 acked— reqjen成正比， 该比率设计之初即 可确定）可以获得响应 （图 1中的②与③时间间隔）， 从而可以在这些提前 预知的时间段内进行各种任务切换或者延迟过大报警等操作。
图 6是本发明实施例提供的一种获取共享资源的协同仲裁器示意图， 如图 6所示， Synergic Arbiter负责釆样 /收集所有与 slave有共享需求的 master 当前一批请求信息（是否有请求， 以及请求读或写等连续猝发请求 burst操 作的长度为多少），并计算得出接下来一段时间 T内各级 Queue所需要顺序 排列的总的有效请求长度 acked— reqjen (各有效请求长度之和， 如 single 请求长度为 1， burst 请求长度为猝发请求长度 burst— len )， 时间 T 与 acked_req_len成正比。
本发明实施例还提供了一种计算机存储介质， 其中存储有计算机可执
本发明实施例从传统的仲裁器单向、 无反馈决策， 转变为众 master协 同仲裁。 具体阐述如下：
a)众 master可以获得当前被仲裁器接收的所有有请求 master的信息； b)仲裁器安排本次接收的所有有请求 master按照设计的先后顺序访问 slave, 并在此过程结束后接收下一批请求；
c)根据 a )中获得的信息，众 master可以获知仲裁器接收下一批请求的 时间点， 对于有请求 master可以获知 slave最晚响应自己时间点（甚至按照 设计好的规则获知确切响应时间点）；
d)众 master可以在确切可知的延迟时间段内进行其他操作 (例如 CPU 切换进程 );
e)如果根据 a ) 中获得的信息， 对于有请求 master获知 slave最晚响应 自己时间点无法满足其系统功能或性能需求， 可以向高层上报中断报警， 高层接到此类中断报警可以进行相应的应急处理或善后准备。
综上所述， 本发明实施例具有以下技术效果：
本发明实施例多个主机通过获知每批次被釆样的有效请求情况， 得知 下一次釆样 \接收请求的时间点， 从而可以在提前预知的时间段内进行各种 任务或者延迟过大报警等操作， 提高了用户体验。
需要说明的是， 上述各单元可以由电子设备中的中央处理器 （Central Processing Unit, CPU ), 数字信号处理器（ Digital Signal Processor, DSP ) 或可编程逻辑阵列 （Field - Programmable Gate Array, FPGA ) 实现。
本领域内的技术人员应明白， 本发明的实施例可提供为方法、 系统、 或计算机程序产品。 因此， 本发明可釆用硬件实施例、 软件实施例、 或结 合软件和硬件方面的实施例的形式。 而且， 本发明可釆用在一个或多个其 中包含有计算机可用程序代码的计算机可用存储介质 (包括但不限于磁盘
存储器和光学存储器等 )上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、 设备（系统）、 和计算机程序 产品的流程图和 /或方框图来描述的。 应理解可由计算机程序指令实现流程 图和 /或方框图中的每一流程和 /或方框、以及流程图和 /或方框图中的流程和 /或方框的结合。 可提供这些计算机程序指令到通用计算机、 专用计算机、 嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器， 使得 在流程图一个流程或多个流程和 /或方框图一个方框或多个方框中指定的功 能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理 设备以特定方式工作的计算机可读存储器中， 使得存储在该计算机可读存 储器中的指令产生包括指令装置的制造品， 该指令装置实现在流程图一个 流程或多个流程和 /或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备 上， 使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机 实现的处理， 从而在计算机或其他可编程设备上执行的指令提供用于实现 在流程图一个流程或多个流程和 /或方框图一个方框或多个方框中指定的功 能的步骤。
尽管上文对本发明进行了详细说明， 但是本发明不限于此， 本技术领 域技术人员可以根据本发明的原理进行各种修改。 因此， 凡按照本发明原 理所作的修改， 都应当理解为落入本发明的保护范围。
Claims
1、 一种获取共享资源的协同仲裁方法， 其中， 该方法包括： 协同仲裁器接收多个主机关于使用共享资源的请求， 并将其转发给所 述共享资源；
所述协同仲裁器釆集当前请求使用共享资源的所有主机的信息； 所述协同仲裁器根据所釆集的当前请求使用共享资源的所有主机的信 息， 计算出所述协同仲裁器下一次有效接收用于使用所述共享资源的请求 的时间点；
所述协同仲裁器将所述时间点发送给使用共享资源的所有主机， 以便 其进行关于使用所述共享资源的下一次请求。
2、 根据权利要求 1所述的方法， 其中， 所述当前请求使用共享资源的 主机信息包括主机 ID号和请求使用共享资源主机的请求长度。
3、 根据权利要求 2所述的方法， 其中， 所述协同仲裁器多个主机关于 使用共享资源的请求转发给共享资源， 包括：
所述协同仲裁器按照预设的规则顺序将多个主机关于使用共享资源的 请求转发给所述共享资源；
所述协同仲裁器按照预设的规则顺序将多个主机关于使用共享资源的 请求转发给所述共享资源之后， 该方法还包括： 所述当前请求使用共享资 源的所有主机根据其预设的规则顺序确知在所述请求时间点的具体时间获 得共享资源的响应。
4、 根据权利要求 3所述的方法， 其中， 该方法还包括：
当所述当前请求使用共享资源的主机根据预设的规则顺序确知在所述 请求时间点的具体时间获得共享资源的响应时无法满足其系统功能或性能 需求时， 所述当前请求使用共享资源的主机通过所述协同仲裁器向高层上 报中断报警， 以便请求优先处理。
5、 根据权利要求 4所述的方法， 其中， 该方法还包括： 所述协同仲裁器检测当前请求使用共享资源的所有主机， 及计算接收 请求总长度， 所述接收请求总长度为请求使用共享资源主机的请求长度之 和。
6、 根据权利要求 5所述的方法， 其中， 所述计算出所述协同仲裁器下 一次有效接收用于使用所述共享资源的请求的时间点包括：
计算当前接收请求总响应时间， 所述当前接收请求总响应时间与所述 接收请求总长度成正比。
7、 一种获取共享资源的协同仲裁装置， 其中， 该装置包括： 接收模块， 配置为接收多个主机关于使用所述共享资源的请求， 并将 其转发给所述共享资源；
釆集模块， 配置为釆集当前请求使用共享资源的所有主机的信息； 计算模块， 配置为根据所釆集的当前请求使用共享资源的所有主机的 信息， 计算出下一次有效接收用于使用所述共享资源的请求的时间点； 反馈模块， 配置为将所述时间点发送给使用共享资源的所有主机， 以 便其进行关于使用所述共享资源的下一次请求。
8、 根据权利要求 7所述的装置， 其中， 所述接收模块包括： 检测单元， 配置为检测当前请求使用共享资源的所有主机；
接收单元， 配置为接收多个主机关于使用所述共享资源的请求； 发送单元， 配置为将所述共享资源的请求转发给所述共享资源。
9、 根据权利要求 8所述的装置， 其特征在于，
所述检测单元， 还配置为计算接收请求总长度， 所述接收请求总长度 为请求使用共享资源主机的请求长度之和。
10、 根据权利要求 8所述的装置， 其特征在于，
所述计算模块， 具体配置为计算当前接收请求总响应时间， 所述当前
接收请求总响应时间与所述接收请求总长度成正比。
11、 一种计算机存储介质， 其中存储有计算机可执行指令， 所述计算 机可执行指令用于执行所述权利要求 1至 6任一项所述的方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201310246721.6 | 2013-06-20 | ||
| CN201310246721.6A CN104243359B (zh) | 2013-06-20 | 2013-06-20 | 一种获取共享资源的协同仲裁方法及装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2014201923A1 true WO2014201923A1 (zh) | 2014-12-24 |
Family
ID=52103927
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/CN2014/077390 WO2014201923A1 (zh) | 2013-06-20 | 2014-05-13 | 一种获取共享资源的协同仲裁方法及装置 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN104243359B (zh) |
| WO (1) | WO2014201923A1 (zh) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1913477A (zh) * | 2005-08-10 | 2007-02-14 | 三星电子株式会社 | 仲裁对共享资源的访问的系统、方法和计算机程序产品 |
| CN102137158A (zh) * | 2011-03-10 | 2011-07-27 | 西北工业大学 | 利用设备代理系统实现信息设备资源共享的方法 |
| CN102298539A (zh) * | 2011-06-07 | 2011-12-28 | 华东师范大学 | 一种用于分布式并行处理的共享资源调度方法及系统 |
| CN102317918A (zh) * | 2009-02-17 | 2012-01-11 | 松下电器产业株式会社 | 资源排他控制方法以及资源排他控制装置 |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7130947B2 (en) * | 2004-04-29 | 2006-10-31 | International Business Machines Corporation | Method of arbitration which allows requestors from multiple frequency domains |
| CN101587461B (zh) * | 2008-05-20 | 2012-03-07 | 上海奇码数字信息有限公司 | 存储器访问调度装置、调度方法与存储器访问控制系统 |
-
2013
- 2013-06-20 CN CN201310246721.6A patent/CN104243359B/zh not_active Expired - Fee Related
-
2014
- 2014-05-13 WO PCT/CN2014/077390 patent/WO2014201923A1/zh active Application Filing
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1913477A (zh) * | 2005-08-10 | 2007-02-14 | 三星电子株式会社 | 仲裁对共享资源的访问的系统、方法和计算机程序产品 |
| CN102317918A (zh) * | 2009-02-17 | 2012-01-11 | 松下电器产业株式会社 | 资源排他控制方法以及资源排他控制装置 |
| CN102137158A (zh) * | 2011-03-10 | 2011-07-27 | 西北工业大学 | 利用设备代理系统实现信息设备资源共享的方法 |
| CN102298539A (zh) * | 2011-06-07 | 2011-12-28 | 华东师范大学 | 一种用于分布式并行处理的共享资源调度方法及系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN104243359B (zh) | 2018-12-18 |
| CN104243359A (zh) | 2014-12-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20170206462A1 (en) | Method and apparatus for detecting abnormal contention on a computer system | |
| JP6129976B2 (ja) | 高効率アトミック演算を使用した方法および装置 | |
| US10831543B2 (en) | Contention-aware resource provisioning in heterogeneous processors | |
| CN104346307B (zh) | 用于直接存储器访问传输的系统和方法 | |
| CN115840621A (zh) | 一种多核系统的交互方法及相关装置 | |
| US20150378949A1 (en) | Method of Transaction and Event Ordering within the Interconnect | |
| WO2014201923A1 (zh) | 一种获取共享资源的协同仲裁方法及装置 | |
| JP4953794B2 (ja) | バスシステムのバス調停方法及びバスシステム | |
| US9183042B2 (en) | Input/output traffic backpressure prediction | |
| WO2022110681A1 (zh) | 命令响应信息的返回方法、返回控制装置和电子设备 | |
| JP5239769B2 (ja) | リクエスト順序制御システム、リクエスト順序制御方法およびリクエスト順序制御プログラム | |
| KR101639947B1 (ko) | 하둡 선점 데드라인 제약 스케줄링 방법 및 그 방법을 수행하는 컴퓨터프로그램과, 그 프로그램이 기록된 매체 | |
| US9323702B2 (en) | Increasing coverage of delays through arbitration logic | |
| CN112463380A (zh) | 多节点服务器的分区控制方法、装置、系统及存储介质 | |
| US8312193B2 (en) | Eager protocol on a cache pipeline dataflow | |
| WO2018049821A1 (zh) | 请求源响应的仲裁方法、装置及计算机存储介质 | |
| Jiaxin | A Data Stream Scheduling Strategy Based on Topology Features | |
| JPH02277149A (ja) | システムを特徴付ける方法 | |
| Rao et al. | Context switch reduction for delay tolerant activities | |
| JP5949346B2 (ja) | 計算ノード間メッセージ通信状況取得プログラム、方法、及びシステム | |
| Purantra et al. | A Novel Approach to Solve Deadlock Problem in On-Chip BUS Communication | |
| CN105630714B (zh) | 接口资源分析装置及其方法 | |
| Zhao et al. | Servo real-time control network design of dynamic priority control strategy | |
| JP2013205892A (ja) | システム性能検証装置、システム性能検証方法およびシステム性能検証プログラム | |
| Wang et al. | A scalable embedded system for massive medical signal processing |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 14814432 Country of ref document: EP Kind code of ref document: A1 |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 14814432 Country of ref document: EP Kind code of ref document: A1 |