Hardware arbiter, arbitration method, processor, chip and electronic equipment

Abstract

The invention provides a hardware arbiter, an arbitration method, a processor, a chip and electronic equipment, and the hardware arbiter comprises a comparator which is used for responding to at least two received arbitration requests and executing an arbitration strategy before processing a next data frame so as to determine a winner arbitration request; the arbitration strategy comprises the following steps: arbitrating at least two arbitration requests based on the user priority, the user bandwidth use information and the bandwidth satisfaction to determine the winner arbitration request; wherein the bandwidth satisfaction degree is used for representing the ratio of the used bandwidth to the applied bandwidth of the user in the current time window. According to the scheme, the comparator comprehensively considers the user priority, the bandwidth use information and the bandwidth satisfaction, so that the hardware arbiter can distribute bandwidth resources more fairly, and the resource distribution fairness of the hardware arbiter is improved.

Description

Technical Field

[0001] The present application relates to the field of integrated circuit technology, and in particular to a hardware arbitrator, arbitration method, processor, chip, and electronic device. Background Art

[0002] With the continuous development of electronic technology, multiplexer circuits have been widely used in various electronic devices. As the basic unit for implementing multiplexer circuits, the performance and cost of the arbitrator directly affect the performance and cost of the entire system.

[0003] The arbitrator methods used in related technologies are relatively simple, typically performing round-robin arbitration based on the number of arbitrations. The arbitration method using a differential weighted round-robin arbitrator with dynamically adjusted priorities in related technologies includes: a two-level arbitrator: a first-level fixed-priority round-robin arbitration, and a second-level round-robin arbitration for users within the allowed bandwidth. Users send a request signal and a fixed priority code. Users are sorted according to the fixed priority code, with users with the same fixed priority code grouped together and users with different fixed priority codes grouped together. Priorities between groups are differentiated based on the size of the fixed priority code. Groups are polled according to the fixed priority, and users with remaining bandwidth within a group are polled sequentially based on their user ID. The second-level arbitrator receives the bandwidth request and the currently transmitted bandwidth information from the user. Combined with the internally stored used bandwidth, it determines the user's available remaining bandwidth. As long as the available remaining bandwidth is less than the currently transmitted bandwidth, users within the group are traversed in order. If all users in the current fixed priority group have been traversed, arbitration proceeds to the next lower priority group.

[0004] In the above scheme, after obtaining arbitration once, a user can only obtain arbitration again after traversing all remaining users, which leads to poor resource allocation fairness of the arbitrator. Summary of the Invention

[0005] The purpose of the embodiments of the present application is to provide a hardware arbitrator, arbitration method, processor, chip and electronic device to solve the above problems.

[0006] In a first aspect, an embodiment of the present application provides a hardware arbitrator, comprising: a comparator;

[0007] a comparator for executing an arbitration strategy in response to at least two received arbitration requests to determine a winning arbitration request before processing a next data frame;

[0008] The arbitration strategy includes arbitrating at least two arbitration requests based on user priority, user bandwidth usage information, and bandwidth satisfaction to determine the winning arbitration request. The bandwidth satisfaction is used to represent the ratio of the user's used bandwidth to the requested bandwidth in the current time window.

[0009] During the implementation of the above solution, the comparator in the hardware arbiter comprehensively considers user priority, bandwidth usage information, and bandwidth satisfaction, enabling the hardware arbiter to allocate bandwidth resources more fairly, thereby improving the fairness of the hardware arbiter's resource allocation. Furthermore, user priority, bandwidth usage information, and bandwidth satisfaction can be dynamically adjusted, enabling the needs of users with high real-time requirements to be continuously met, thereby improving the real-time performance of the hardware arbiter's resource allocation.

[0010] In an implementation of the first aspect, at least two arbitration requests are arbitrated based on user priority, user bandwidth usage information, and bandwidth satisfaction to determine a winning arbitration request. The method includes: grouping the received arbitration requests based on the user priority and user bandwidth usage information; wherein the user bandwidth usage information includes information on whether the user's bandwidth usage exceeds the requested bandwidth within a current time window and whether the user is allowed to continue using bandwidth resources if the bandwidth usage exceeds the requested bandwidth; performing inter-group arbitration based on the group priority; and performing intra-group arbitration within the winning group to determine the arbitration request with the lowest bandwidth satisfaction as the winning arbitration request.

[0011] In the implementation of the above solution, bandwidth satisfaction is calculated based on the user's actual bandwidth usage and requested bandwidth, which can more accurately reflect the user's actual demand for bandwidth resources. Compared with the number of arbitrations, bandwidth satisfaction can more accurately reflect the degree to which the user's bandwidth needs are met during actual use. Using bandwidth satisfaction for inter-group arbitration can improve the flexibility of the hardware arbitrator. On the other hand, using group priority for inter-group arbitration and bandwidth satisfaction for intra-group arbitration comprehensively considers user priority and bandwidth demand satisfaction, thereby improving the fairness of resource allocation during arbitration by the hardware arbitrator.

[0012] In an implementation of the first aspect, the comparator performs intra-group arbitration in the winning group and determines the arbitration request with the lowest bandwidth satisfaction as the winning arbitration request, including: if the winning group is the highest priority group, determining the arbitration request with the lowest weighted bandwidth satisfaction as the winning arbitration request; wherein the weighted bandwidth satisfaction is obtained by weighting the bandwidth satisfaction using a request urgency weight; and the urgency weight is a weight pre-configured for each user.

[0013] In the implementation of the above solution, the urgency weight can reflect the user's urgency, and the bandwidth satisfaction can reflect the degree to which the user's needs are met. By weighting the bandwidth satisfaction using the urgency weight, the obtained weighted bandwidth satisfaction can more accurately reflect the degree to which the emergency user's needs are met. When arbitrating using the weighted bandwidth satisfaction, the degree to which the emergency user's needs are met can be more accurately measured, thereby helping to improve the resource allocation fairness of the above hardware arbitrator.

[0014] In an implementation manner of the first aspect, the comparator is further configured to:

[0015] Before executing the arbitration policy, check whether the configuration information has changed. If so, update the configuration information. The configuration information includes the window length of the time window, user priority, requested bandwidth, whether the user is allowed to continue using bandwidth resources when the bandwidth used exceeds the requested bandwidth, and the emergency weight.

[0016] During the implementation of the above solution, the configuration information is updated before the arbitration policy is executed, allowing the hardware arbitrator to update the configuration information in a timely manner, which is conducive to improving the rationality of bandwidth allocation. On the other hand, by updating the configuration before executing the arbitration policy, the arbitration basis can be updated in a timely manner during the configuration update. Compared with the method of updating after traversal in related technologies, the above solution can achieve greater configuration flexibility.

[0017] In an implementation of the first aspect, the hardware arbiter further includes: a satisfaction counter electrically connected to the comparator;

[0018] A satisfaction counter is used to calculate the bandwidth satisfaction of each user and send the bandwidth satisfaction to the comparator;

[0019] The satisfaction counter includes a decimal counter and an integer counter, where:

[0020] A decimal counter is configured to, after a user's arbitration request wins, increment a first preset value in a first counting identifier for each clock cycle; and, when the value in the first counting identifier reaches a second preset value, notify the integer counter to increment a third preset value in the second counting identifier and clear the first counting identifier; wherein the first counting identifier and the second counting identifier are respectively used to represent the decimal part and the integer part of the ratio of the user's actual used bandwidth to the clock cycle after the user wins the arbitration request; the second preset value is positively correlated with the first ratio; and the first ratio is the ratio of the user's requested bandwidth to the clock cycle;

[0021] The integer counter is used to increase the third preset value in the second counting identifier after receiving the notification from the decimal counter.

[0022] In the implementation of the above solution, a two-stage counting method using an integer counter and a decimal counter is used. Different users applying for bandwidth have different bandwidth satisfaction increments within a clock cycle. This allows for more accurate calculation of user bandwidth satisfaction, enabling the hardware arbitrator to allocate appropriate bandwidth resources to users based on their precise bandwidth satisfaction, thereby improving the arbitration fairness of the hardware arbitrator. Furthermore, the two-stage counting method simplifies the design, as the decimal counter and the integer counter can count separately, which helps reduce the design cost of the hardware arbitrator.

[0023] In an implementation of the first aspect, the integer counter is further configured to:

[0024] Before the hardware arbitrator executes the arbitration strategy, the value in the second counting identifier is sent to the comparator as the user's bandwidth satisfaction.

[0025] In the implementation process of the above solution, by directly sending the value recorded by the integer counter as the bandwidth satisfaction to the comparator, the hardware arbitrator can use a comparator with fewer bits for arbitration, which is beneficial to reducing the implementation cost of the hardware arbitrator. On the other hand, directly using the integer part for arbitration is beneficial to improving the arbitration efficiency of the comparator, thereby improving the overall performance of the hardware arbitrator.

[0026] In an implementation of the first aspect, the hardware arbiter further includes: an ultra-bandwidth detector electrically connected to the comparator;

[0027] The excessive bandwidth detector is used to detect whether the bandwidth used by the user in the current time window exceeds the requested bandwidth and send the detection result to the comparator.

[0028] In the implementation of the above solution, on the one hand, by setting up an over-bandwidth detector to detect the over-bandwidth situation of users in the current time window, it is beneficial to improve the situation of users over-occupying bandwidth resources, reduce the probability of resource abuse, and thus improve the resource utilization of bandwidth resources; on the other hand, by setting up an over-bandwidth detector, each user can obtain a reasonable bandwidth allocation, which is beneficial to improving the arbitration fairness of the hardware arbitrator.

[0029] In an implementation of the first aspect, the hardware arbiter further includes: a time window counter, the time window counter being electrically connected to the satisfaction counter and the ultra-bandwidth detector respectively;

[0030] A time window counter, configured to, after the start of a current time window, increment a fourth preset value in a third counting identifier for each clock cycle that passes; and, when the value in the third counting identifier reaches a fifth preset value, send an initialization signal to the satisfaction counter and the ultra-bandwidth detector, and clear the third counting identifier; wherein the third counting identifier is used to represent the number of clock cycles that have been completed within the current time window; the fifth preset value is positively correlated with a second ratio; and the second ratio is the ratio of the window length of the current time window to the clock cycle.

[0031] The satisfaction counter is further configured to clear the first counting flag and the second counting flag to zero when receiving an initialization signal sent by the time window counter;

[0032] The ultra-wideband detector is further configured to clear the third counting flag to zero when receiving an initialization signal sent by the time window counter.

[0033] In implementing the above solution, the time window counter helps the comparator more accurately track and understand each user's resource requirements and usage patterns within different time windows, thereby optimizing bandwidth resource allocation and improving bandwidth resource utilization. Furthermore, users have the opportunity to obtain bandwidth resources within each time window, preventing some users from occupying resources for a long time, which helps improve the resource allocation fairness of the hardware arbitrator. Furthermore, using the time window as the update period for the satisfaction counter and the excess bandwidth detector helps improve the local fairness of arbitration performed by the hardware arbitrator.

[0034] In an implementation manner of the first aspect, the comparator is further configured to:

[0035] At the end of the current time window, based on the bandwidth satisfaction of each user, a compensation value of the bandwidth satisfaction of the next time window is obtained; wherein the compensation value is positively correlated with the bandwidth satisfaction;

[0036] And, in the first round of intra-group arbitration in the next time window, the bandwidth satisfaction is compensated using the compensation value.

[0037] In the implementation of the above solution, at the end of the current time window, a bandwidth satisfaction compensation value is allocated to each user. This allows the compensation value to be used to compensate for bandwidth satisfaction during the first round of intra-group arbitration in the next time window. This allows users who originally had the opportunity to obtain arbitration at the end of the previous time window to obtain arbitration first, thereby further improving the global fairness of arbitration.

[0038] In an implementation of the first aspect, the comparator determines the arbitration request with the lowest bandwidth satisfaction as the winning arbitration request, including:

[0039] If there are multiple arbitration requests with the lowest bandwidth satisfaction in the winning group, the arbitration request with the smallest user ID is determined as the winning arbitration request; wherein, the smaller the user ID, the smaller the code value of the user ID.

[0040] In the implementation of the above solution, when the bandwidth satisfaction levels are the same, multiple arbitration requests with the same bandwidth satisfaction levels are arbitrated using the coding value determined based on the user identifier to determine the winning user, which is conducive to improving the fairness and efficiency of arbitration.

[0041] In an implementation manner of the first aspect, the comparator is further configured to:

[0042] The user priority, bandwidth satisfaction and user ID of each user are encoded respectively; wherein, the smaller the encoding value of the user priority, the higher the user priority; the smaller the encoding value of the bandwidth satisfaction, the lower the bandwidth satisfaction; the smaller the encoding value of the user ID, the smaller the user ID;

[0043] The coding of user priority, bandwidth satisfaction and user identification are sequentially integrated into a decision identification;

[0044] In addition, the numerical value of the decision identifier is used to conduct inter-group arbitration and intra-group arbitration.

[0045] During the implementation of the above solution, the group code, bandwidth satisfaction code, and user identification code are bit-wise spliced together to obtain a decision identifier. This allows the comparator to make inter-group and intra-group decisions directly by comparing the sizes of the decision identifiers. This improves the arbitration efficiency of the hardware arbiter. Compared with increasing the bit width of the comparator, the above solution reuses certain bits of the comparator, which helps reduce the implementation cost of the comparator.

[0046] In an implementation of the first aspect, the groups include: a first group, a second group, a third group, and a fourth group, which are sorted in descending order of group priority, wherein:

[0047] The user priority of users in the first group is the emergency priority;

[0048] The user priority of the users in the second group is non-urgent priority, and the bandwidth used by the users in the current time window does not exceed the requested bandwidth;

[0049] The user priority of the user in the third group is non-urgent priority. The bandwidth used by the user in the current time window exceeds the used bandwidth. After the used bandwidth exceeds the applied bandwidth, the user is allowed to continue to use bandwidth resources;

[0050] The user in the fourth group has no arbitration request, or the user priority of the user is non-emergency priority, the bandwidth used by the user in the current time window exceeds the used bandwidth, and the user is not allowed to continue to use bandwidth resources after the used bandwidth exceeds the applied bandwidth.

[0051] In implementing the above solution, users are divided into four groups, each with clearly defined user priority and bandwidth usage. This allows the hardware arbitrator to more precisely control bandwidth resource allocation, improving the accuracy of bandwidth resource allocation. Furthermore, when the user priority is emergency, bandwidth usage and the number of arbitrations are no longer considered, allowing users with the highest priority to obtain bandwidth resources first. Compared to arbitration solutions based on the number of arbitrations in related technologies, the above solution can meet users' urgent needs and improve the real-time arbitration performance of the hardware arbitrator.

[0052] In a second aspect, an embodiment of the present application provides an arbitration method for a hardware arbitrator provided by the first aspect or any possible implementation of the first aspect, the method comprising:

[0053] Before processing a next data frame, executing an arbitration strategy in response to at least two received arbitration requests to determine a winning arbitration request;

[0054] The arbitration strategy includes:

[0055] Based on user priority, user bandwidth usage information, and bandwidth satisfaction, at least two arbitration requests are arbitrated to determine the winning arbitration request; the bandwidth satisfaction is used to represent the ratio of the user's used bandwidth to the requested bandwidth in the current time window.

[0056] In a third aspect, an embodiment of the present application provides a processor, which is used to run a program, wherein when the program runs, the method provided by the second aspect or any possible implementation of the second aspect is executed.

[0057] In a fourth aspect, an embodiment of the present application provides a chip, which includes a hardware arbitrator provided by the first aspect or any possible implementation of the first aspect.

[0058] In a fifth aspect, an embodiment of the present application provides an electronic device, the electronic device comprising:

[0059] The hardware arbiter provided by the first aspect or any possible implementation of the first aspect;

[0060] Alternatively, the processor provided by the third aspect or any possible implementation of the third aspect;

[0061] Alternatively, a chip provided by the fourth aspect or any possible implementation of the fourth aspect.

[0062] Other features and advantages of the present application will be described in the following description and, in part, will become apparent from the description or be understood by practicing the embodiments of the present application. The objectives and other advantages of the present application can be achieved and obtained through the structures particularly pointed out in the written description, claims, and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0063] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments of the present application. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can be obtained based on these drawings without creative work.

[0064] Figure 1 A schematic diagram of the structure of the hardware arbitrator provided in an embodiment of the present application;

[0065] Figure 2 A flowchart illustrating the arbitration strategy executed by the hardware arbitrator provided in an embodiment of the present application;

[0066] Figure 3 Another structural diagram of the hardware arbitrator provided in an embodiment of the present application;

[0067] Figure 4 A schematic diagram of the splicing method of decision identification provided in an embodiment of the present application. DETAILED DESCRIPTION

[0068] The following will describe the technical solutions in the embodiments of the present application in conjunction with the accompanying drawings. The following embodiments are only used to more clearly illustrate the technical solutions of the present application and are therefore only examples and cannot be used to limit the scope of protection of the present application.

[0069] Embodiments of the present application provide a hardware arbiter. A comparator in the hardware arbiter comprehensively considers user priority, bandwidth usage information, and bandwidth satisfaction, enabling the hardware arbiter to more fairly allocate bandwidth resources, thereby improving the fairness of resource allocation in the hardware arbiter. Furthermore, user priority, user bandwidth usage information, and bandwidth satisfaction can be dynamically adjusted, enabling the needs of users with high real-time requirements to be continuously met, thereby improving the real-time performance of resource allocation in the hardware arbiter.

[0070] The following is an introduction to the hardware arbiter. Figure 1, an embodiment of the present application provides a hardware arbiter 100, the hardware arbiter comprising: a comparator 110;

[0071] The comparator 110 is configured to execute an arbitration strategy in response to at least two received arbitration requests before processing a next data frame to determine a winning arbitration request.

[0072] The aforementioned bandwidth resources refer to data processing resources, including data computing resources, data transmission resources, and data storage resources. For example, in fields such as network communications and data transmission, bandwidth resources primarily refer to data transmission resources. The hardware arbitrator allocates bandwidth resources to determine which user or users receive priority for data transmission. Another example is video encoding and decoding, image processing, and other scenarios, where bandwidth resources primarily refer to data computing resources. For example, the processing bandwidth of a video encoder determines the number of video frames or the amount of data it can process per unit time. The hardware arbitrator allocates bandwidth resources to determine which user or users receive priority for data processing.

[0073] The arbitration unit of the comparator 110 may be a frame, that is, each winning arbitration request processes a data frame. The triggering conditions for the comparator 110 to execute the arbitration strategy must meet the following conditions:

[0074] (1) Before processing the next data frame;

[0075] Before processing the next data frame, the frame gap between two data frames may be processed, or before processing the first data frame.

[0076] The above triggering condition can be understood as a time triggering condition of the arbitration policy. When the condition is triggered, it means that the shared resource is capable of providing unoccupied bandwidth resources.

[0077] (2) At least two arbitration requests are received.

[0078] The at least two arbitration requests may be multiple arbitration requests received simultaneously, or may be multiple arbitration requests received during a period when bandwidth resources are occupied, or may be multiple arbitration requests received within a preset time period.

[0079] The above triggering condition can be understood as a requirement triggering condition of the arbitration policy. When the condition is triggered, it means that the bandwidth resource has an arbitration requirement, and the comparator 110 is required to arbitrate multiple arbitration requests.

[0080] In different application scenarios, the winning arbitration request can be one arbitration request or multiple arbitration requests. The following describes these two implementation methods respectively:

[0081] The first implementation method: the winning arbitration request is one arbitration request;

[0082] In some scenarios, bandwidth resources can only process one data frame, or bandwidth resources are only allowed to process one data frame after each arbitration. In these scenarios, hardware arbiter 100 usually only selects one winning arbitration request per arbitration.

[0083] Second implementation method: the winning arbitration request is multiple arbitration requests;

[0084] In some scenarios, if hardware resources allow, the hardware arbiter 100 can support multiple users processing data in parallel. For example, if there are multiple VPUs (Video Processing Units), and each VPU can independently process a data frame, the hardware arbiter 100 can simultaneously select multiple winning requests and assign each request to a VPU for processing.

[0085] For another example, in a scenario where bandwidth resources are relatively sufficient and can simultaneously meet the bandwidth requirements of multiple users, the hardware arbiter 100 may also select multiple winning arbitration requests.

[0086] An arbitration scheme in which the winning request is multiple arbitration requests can be considered an arbitration scheme in which a single winning request is determined multiple times. In the following description, a winning arbitration request generally refers to a single arbitration request. Those skilled in the art can expand upon the arbitration scheme for a single winning request to an arbitration scheme for multiple winning requests.

[0087] The arbitration strategy implemented by the comparator 110 is described below. The arbitration strategy implemented by the comparator 110 includes:

[0088] Based on user priority, user bandwidth usage information, and bandwidth satisfaction, at least two arbitration requests are arbitrated to determine the winning arbitration request; the bandwidth satisfaction is used to represent the ratio of the user's used bandwidth to the requested bandwidth in the current time window.

[0089] The bandwidth satisfaction can be directly obtained by dividing the bandwidth used by the user in the current time window by the bandwidth requested by the user.

[0090] The following describes an optional implementation of the comparator 110 arbitrating at least two arbitration requests to determine a winning arbitration request based on user priority, user bandwidth usage information, and bandwidth satisfaction.

[0091] The first implementation method: arbitration based on scoring;

[0092] The comparator 110 may calculate a score for each user based on preset rules, taking into account user priority, user bandwidth usage information, and bandwidth satisfaction. Users with higher scores may be given priority in arbitration.

[0093] In addition, weights can be set in advance for user priority, user bandwidth usage information, and bandwidth satisfaction based on importance, and the score of each user can be calculated in a weighted manner.

[0094] The second implementation method: arbitration based on priority queue;

[0095] Comparator 110 can establish multiple queues for users of different priorities. For example, high-priority users enter the high-priority queue, and low-priority users enter the low-priority queue. Within each queue, users can be ranked based on their bandwidth usage information and bandwidth satisfaction. Users with higher rankings receive priority arbitration.

[0096] When sorting users in the queue, it is also possible to use a method of scoring users based on preset rules, taking into account user bandwidth usage information and bandwidth satisfaction, and sorting them according to the scores.

[0097] During arbitration, the comparator 110 first processes the arbitration requests in the high-priority queue, and when the high-priority queue is empty, it processes the arbitration requests in the low-priority queue.

[0098] The third implementation method: arbitration based on machine learning;

[0099] Use machine learning models, such as decision trees and neural networks, with arbitration requests, user priorities, user bandwidth usage information, and bandwidth satisfaction as model inputs, and the winning arbitration request as model output to determine the winning arbitration request among multiple arbitration requests.

[0100] The fourth implementation method: arbitration based on inter-group arbitration and intra-group arbitration;

[0101] See Figure 2 ,Optional, arbitration strategies can include:

[0102] Step S210: grouping the received arbitration requests based on user priority and user bandwidth usage information;

[0103] Step S220: performing arbitration between groups based on the priority of the groups;

[0104] Step S230: performing intra-group arbitration among the winning groups, and determining the arbitration request with the lowest bandwidth satisfaction as the winning arbitration request.

[0105] In the above scheme, the comparator 110 in the hardware arbitrator 100 performs inter-group arbitration based on group priority and intra-group arbitration based on bandwidth satisfaction. During each arbitration, an arbitration request with a low bandwidth satisfaction rating within a high-priority group can be determined as the winning arbitration request. On the one hand, the bandwidth satisfaction rating is calculated based on the user's actual bandwidth usage and requested bandwidth, more accurately reflecting the user's actual demand for bandwidth resources. Compared to the number of arbitrations, the bandwidth satisfaction rating more accurately reflects the degree to which a user's bandwidth needs are met during actual use. Using bandwidth satisfaction rating for inter-group arbitration improves the flexibility of the hardware arbitrator 100. On the other hand, using group priority for inter-group arbitration in conjunction with bandwidth satisfaction rating for intra-group arbitration comprehensively considers user priority and bandwidth demand satisfaction, thereby improving resource allocation fairness during arbitration by the hardware arbitrator 100.

[0106] The above-mentioned user bandwidth usage information may include: information on whether the user's bandwidth usage in the current time window exceeds the applied bandwidth (also referred to as information on whether the user exceeds the bandwidth in the current time window) and information on whether the user is allowed to continue using bandwidth resources when the bandwidth usage exceeds the applied bandwidth (also referred to as information on whether the user is allowed to exceed the bandwidth).

[0107] The above-mentioned user priority and whether the user is allowed to use ultra-bandwidth information can be obtained through the configuration information cfg, and the configuration information can be modified by the software deployed in the host computer. It is understood that the configuration information can be written into the register of the hardware arbiter 100, and the comparator 110 can read the configuration information through the register.

[0108] The user priorities described above can be divided into emergency priority and non-emergency priority based on the user's urgency, or they can be divided into multiple levels, for example, with priorities ranging from low to high as Level 1, Level 2, and Level 3. The information about whether the user exceeds the bandwidth within the current time window and whether the user is allowed to exceed the bandwidth can both be binary information. If user priorities are divided into emergency priority and non-emergency priority, then the user groups can include 2 × 2 × 2 = 8 groups. If user priorities are divided into multiple levels, for example, with priorities ranging from low to high as Level 1, Level 2, and Level 3, then the user groups can include 3 × 2 × 2 = 12 groups.

[0109] As shown in Table 1, the above grouping may optionally include:

[0110] The group priorities are ranked from high to low: the first group, the second group, the third group, and the fourth group, where:

[0111] The user priority of users in the first group is the emergency priority;

[0112] The user priority of the users in the second group is non-urgent priority, and the bandwidth used by the users in the current time window does not exceed the requested bandwidth;

[0113] The user priority of the user in the third group is non-urgent priority. The bandwidth used by the user in the current time window exceeds the used bandwidth. After the used bandwidth exceeds the applied bandwidth, the user is allowed to continue to use bandwidth resources;

[0114] The user in the fourth group has no arbitration request, or the user priority of the user is non-emergency priority, the bandwidth used by the user in the current time window exceeds the used bandwidth, and the user is not allowed to continue to use bandwidth resources after the used bandwidth exceeds the applied bandwidth.

[0115] Table 1 User grouping

[0116]

[0117]

[0118] On the one hand, the above scheme divides users into four groups, each with clearly defined user priority and bandwidth usage. This allows the hardware arbiter 100 to more precisely control bandwidth resource allocation, thereby improving the accuracy of bandwidth resource allocation. On the other hand, when the user priority is emergency, bandwidth usage and arbitration times are no longer considered, allowing users with the highest priority to obtain bandwidth resources first. Compared with arbitration schemes based on arbitration times in related technologies, the above scheme can meet users' urgent needs and improve the real-time arbitration performance of the hardware arbiter 100.

[0119] The information about whether the user exceeds the bandwidth in the current time window can be obtained through an excessive bandwidth detector. The specific scheme is as follows:

[0120] like Figure 3 As shown, optionally, the hardware arbiter 100 may further include an ultra-bandwidth detector 120 , which is electrically connected to the comparator 110 .

[0121] The excess bandwidth detector 120 is configured to detect whether the bandwidth used by the user in the current time window exceeds the requested bandwidth, and send the detection result to the comparator 110 .

[0122] The bandwidth requested by the above user can be understood as a number of shares. For example, the bandwidth resources in the entire time window are divided into 32 shares. If a user requests 1 / 32 of the bandwidth, then the bandwidth requested by the user converted into clock cycles is: time window length * 1 / 32.

[0123] The excessive bandwidth detector 120 can use a counter to detect the actual bandwidth used by a user. For example, when a user occupies bandwidth resources for data processing, the counter in the excessive bandwidth detector 120 increments the value of the identification bit corresponding to the user by 1 with each clock cycle. When the value of the counter bit corresponding to the user exceeds the value of the requested bandwidth converted to clock cycles, the excessive bandwidth detector 120 can send a notification to the comparator 110, notifying the comparator 110 that the user has exceeded the bandwidth. The comparator 110 can then use the excessive bandwidth information to group users in the next round of arbitration.

[0124] When implemented in hardware, the above-mentioned ultra-bandwidth detector 120 may include a comparison circuit, which is used to compare the user's used bandwidth in the current time window with the bandwidth requested by the user, and output an ultra-bandwidth signal when the used bandwidth is greater than the requested bandwidth. The comparator can determine the user's ultra-bandwidth situation through this signal.

[0125] In addition, the above-mentioned excess bandwidth detector 120 may periodically upload the excess bandwidth status of each user to the comparator 110 , or may upload the excess bandwidth status of the user to the comparator 110 when the user exceeds the bandwidth.

[0126] It is understood that the excessive bandwidth detector 120 detects the excessive bandwidth of users within the current time window. If the sum of the bandwidth occupied by each user exceeds the length of the preset time window, it is determined that the current time window has been exceeded. At this time, the counter in the excessive bandwidth detector 120 can be initialized to facilitate the next round of arbitration.

[0127] Of course, the time window can also be determined by an independent time window counter. For the implementation of the time window counter, please refer to the relevant introduction to the time window counter in the subsequent content.

[0128] On the one hand, the above solution, by providing an excessive bandwidth detector 120 to detect excessive bandwidth usage by users within the current time window, helps alleviate excessive bandwidth usage, reduces resource misuse, and thus improves bandwidth resource utilization. On the other hand, providing an excessive bandwidth detector 120 ensures that every user has an arbitration opportunity, which helps improve arbitration fairness within the hardware arbitrator 100.

[0129] The following describes the scheme for inter-group arbitration in step S220:

[0130] The above step S220 can perform inter-group arbitration in a traversal manner, for example: starting from the high priority group, if the current group has users, the current group is determined as the winning group; if the current group has no users, the user status in the next group is queried in turn.

[0131] In addition, in order to facilitate the comparator 110 to quickly traverse the groups, each group may be encoded. Taking the four groups shown in Table 1 above as an example, the encoding of each group is shown in Table 2.

[0132] Table 2 Group coding

[0133]

[0134]

[0135] The above encoding uses binary encoding, which can encode four groups using two bits. In the above encoding, the smaller the code value, the higher the priority of the group. This encoding method can quickly achieve arbitration between groups.

[0136] The following describes the scheme for performing intra-group arbitration in step S230:

[0137] The bandwidth satisfaction ratio represents the ratio of a user's bandwidth usage to their requested bandwidth within the current time window. It measures the degree to which a user's bandwidth needs are met within the current time window. A higher bandwidth satisfaction ratio indicates greater user satisfaction within the current time window; conversely, a lower bandwidth satisfaction ratio indicates less user satisfaction within the current time window.

[0138] Step S230 determines the arbitration request with the lowest bandwidth satisfaction in the winning group as the winning request, taking into account information such as user priority, bandwidth usage information, and the degree to which user requirements are satisfied. This allows arbitration requests with high group priority but low bandwidth satisfaction to be arbitrated first, thereby improving arbitration fairness of the hardware arbitrator 100.

[0139] The following describes how the hardware arbiter 100 obtains bandwidth satisfaction:

[0140] See Figure 3 Optionally, the hardware arbiter 100 may further include a satisfaction counter 130 , which is electrically connected to the comparator 110 .

[0141] The satisfaction counter 130 is used to calculate the bandwidth satisfaction of each user and send the bandwidth satisfaction to the comparator 110. When a time window ends, the comparator 110 sends the compensation value to the satisfaction counter 130 as the initial value of the satisfaction counter 130 at the beginning of the next time window.

[0142] The satisfaction counter 130 includes a decimal counter and an integer counter, wherein:

[0143] The decimal counter is configured to, after a user's arbitration request wins, increment a first preset value in a first counting identifier for each clock cycle; and, when the value in the first counting identifier reaches a second preset value, notify the integer counter to increment a third preset value in the second counting identifier and clear the first counting identifier; wherein the first counting identifier and the second counting identifier are respectively used to represent the decimal part and the integer part of the ratio of the user's actual used bandwidth to the clock cycle after the user's arbitration request wins; the second preset value is positively correlated with the first ratio; and the first ratio is the ratio of the user's requested bandwidth to the clock cycle;

[0144] The integer counter is configured to increase the third preset value in the second counting identifier after receiving a notification from the decimal counter. For example, the embodiment is as follows:

[0145] After the user obtains arbitration, the first count flag of the decimal counter is incremented by one every clock cycle. When the value of the first count flag in the decimal counter reaches a preset value (the preset value can be the ratio of the user's requested bandwidth to the clock cycle), the integer counter is notified to add one to the second count flag and clear the first count flag. After receiving the notification from the decimal counter, the integer counter adds one to the second count flag.

[0146] In addition, the bandwidth requested by the user can also be understood as a number of shares. For example, if the bandwidth resources in the entire time window are divided into 32 shares, if the user requests 1 / 32 of the bandwidth, the preset value of the first counting identifier is 1, and the bandwidth requested by the user converted to clock cycles is: time window length * 1 / 32; if the user requests 3 / 32 of the bandwidth, the preset value of the first counting identifier is 3, and the bandwidth requested by the user converted to clock cycles is: time window length * 3 / 32.

[0147] When implemented in hardware, the satisfaction counter 130 may use two counting circuits to respectively implement the functions of the decimal counter and the integer counter.

[0148] During the implementation of the above solution, a two-stage counting method using an integer counter and a decimal counter is used. Different users applying for bandwidth will have different bandwidth satisfaction increments within a clock cycle, enabling more accurate calculation of user bandwidth satisfaction. This allows the hardware arbiter 100 to allocate appropriate bandwidth resources to users based on their precise bandwidth satisfaction, thereby improving arbitration fairness within the hardware arbiter 100. Furthermore, the two-stage counting method simplifies the design, as the decimal counter and the integer counter can perform counting independently, which helps reduce the implementation cost of the hardware arbiter 100.

[0149] The bandwidth satisfaction value can be a decimal or an integer. The following describes the solution where the bandwidth satisfaction value is an integer:

[0150] Optionally, the integer counter is further used to:

[0151] Before the hardware arbiter 100 executes the arbitration strategy, the value in the second counting identifier is sent to the comparator 110 as the user's bandwidth satisfaction.

[0152] It is understandable that the value recorded by the integer counter is the integer ratio of the user's actual bandwidth usage to the requested bandwidth within the current time window.

[0153] By directly sending the value recorded by the integer counter as the bandwidth satisfaction value to the comparator 110, the above solution allows the hardware arbiter 100 to use a comparator 110 with fewer bits for arbitration, which helps reduce the implementation cost of the hardware arbiter 100. Furthermore, directly using the integer part for arbitration helps improve the arbitration efficiency of the comparator 110, thereby improving the overall performance of the hardware arbiter 100.

[0154] Optionally, the hardware arbiter 100 further includes:

[0155] A time window counter 140 , the time window counter 140 is electrically connected to the satisfaction counter 130 and the ultra-bandwidth detector 120 ;

[0156] The time window counter 140 is configured to increase the third count identifier by a fourth preset value each time a clock cycle passes after the start of the current time window; and when the value in the third count identifier reaches a fifth preset value, send an initialization signal to the satisfaction counter 130 and the ultra-bandwidth detector 120 and clear the third count identifier. The third count identifier is used to represent the number of clock cycles completed within the current time window. The fifth preset value is positively correlated with the second ratio; the second ratio is the ratio of the window length of the current time window to the clock cycle.

[0157] The satisfaction counter 130 is further configured to clear the first counting flag and the second counting flag to zero upon receiving an initialization signal sent by the time window counter;

[0158] The ultra-wideband detector 120 is further configured to clear the third counting flag to zero upon receiving an initialization signal sent by the time window counter.

[0159] For example, in the above embodiment, after the start of the current time window, the time window counter 140 increments the third count flag by one each clock cycle. When the value in the third count flag reaches the ratio of the window length of the current time window to the clock cycle, the time window counter 140 sends an initialization signal to the satisfaction counter 130 and the ultra-bandwidth detector 120, and clears the third count flag. Upon receiving the initialization signal from the time window counter, the satisfaction counter 130 clears the first count flag and the second count flag. Upon receiving the initialization signal from the time window counter, the ultra-bandwidth detector 120 clears the third count flag.

[0160] When implemented in hardware, the time window counter 140 may use a counting circuit to count clock cycles, thereby realizing timing of the time window.

[0161] The above scheme, through the time window counter 140, can help the comparator 110 more accurately track and understand the resource requirements and usage patterns of each user within different time windows, thereby optimizing the allocation of bandwidth resources and improving bandwidth resource utilization. Furthermore, users have the opportunity to obtain bandwidth resources within each time window, avoiding the situation where some users occupy resources for a long time, which is conducive to improving the resource allocation fairness of the hardware arbiter 100. Furthermore, using the time window as the update period for the satisfaction counter 130 and the excess bandwidth detector 120 is conducive to improving the local fairness of arbitration performed by the hardware arbiter 100.

[0162] In order to reflect the urgency of the user and the degree to which the hardware arbitrator 100 satisfies the emergency request, the embodiment of the present application performs weighting when calculating the bandwidth satisfaction of the user in the highest priority group. The weight used may be the urgency weight of the request. The specific scheme is as follows:

[0163] Optionally, the comparator 110 performs intra-group arbitration in the winning group and determines the arbitration request with the lowest bandwidth satisfaction as the winning arbitration request, including:

[0164] If the winning group is the highest priority group, the arbitration request with the lowest weighted bandwidth satisfaction is determined as the winning arbitration request; the weighted bandwidth satisfaction is obtained by weighting the bandwidth satisfaction using the request urgency weight; the urgency weight is a weight pre-configured for each user.

[0165] The above emergency weight can be determined by the configuration information cfg, and the host computer can modify the emergency weight of each user through the configuration information cfg. In addition, the above emergency weight can also be determined by the urgency level in the configuration information cfg. The urgency level can be in the form of a level or a number. The higher the urgency level of the user, the higher the urgency level.

[0166] In addition, the bandwidth satisfaction level can be an integer or a decimal. For the calculation method of the bandwidth satisfaction level, please refer to the introduction of the satisfaction level counter 130 in the above content.

[0167] The above-mentioned weighted bandwidth satisfaction can be obtained by directly multiplying the emergency weight and the bandwidth satisfaction, or by using other weighting methods. For example, when introducing the decision identifier in the following content, the emergency weight is encoded in the high position of the decision identifier and the bandwidth satisfaction is encoded in the low position of the decision identifier, thereby adding the emergency weight and the bandwidth satisfaction to obtain the weighted bandwidth satisfaction.

[0168] The urgency weight in the above scheme can reflect the urgency of the user, and the bandwidth satisfaction can reflect the degree to which the user's needs are met. By weighting the bandwidth satisfaction using the urgency weight, the obtained weighted bandwidth satisfaction can more accurately reflect the degree to which the emergency user's needs are met. When arbitrating using the weighted bandwidth satisfaction, the degree to which the emergency user's needs are met can be more accurately measured, thereby facilitating improvement in resource allocation fairness of the hardware arbitrator 100.

[0169] In the related art, the hardware arbitrator needs to wait until all users in the ten thousand groups are traversed before changing the user's priority in order to dynamically adjust the fixed priority of the user. This priority update method takes a long time to take effect and cannot meet the real-time needs of users. Based on this, the embodiment of the present application provides the following solution:

[0170] Optionally, the comparator 110 is further configured to:

[0171] Before executing the arbitration policy, check whether the configuration information has changed. If so, update the configuration information. The configuration information includes the window length of the time window, user priority, requested bandwidth, information on whether the user is allowed to continue using bandwidth resources when the bandwidth used exceeds the requested bandwidth (also known as information on whether the user is allowed to exceed the bandwidth), and emergency weight.

[0172] The contents and main uses of the configuration information cfg are shown in Table 3:

[0173] Table 3 Contents and main uses of configuration information cfg

[0174]

[0175] The time before the arbitration strategy is executed may be the time between when the arbitration strategy is triggered and when the arbitration strategy is formally executed, or it may be the time after the last winning arbitration request completes processing of the data frame and releases bandwidth resources.

[0176] The above configuration information cfg can be configured by the user through software deployed in the host computer. The host computer writes the configuration information cfg into the registers of the hardware arbiter 100. The comparator 110, ultra-bandwidth detector 120, satisfaction counter 130 and time window counter 140 in the hardware arbiter 100 can read their respective configuration information through the registers.

[0177] During the implementation of the above solution, the configuration information is updated before the arbitration policy is executed, so that the hardware arbiter 100 can update various configuration information in a timely manner, which is conducive to improving the rationality of bandwidth allocation. On the other hand, by updating the configuration before executing the arbitration policy, the arbitration basis can be updated in a timely manner during the configuration update. Compared with the method of updating after traversal in related technologies, the above solution can achieve greater configuration flexibility.

[0178] Figure 3 As shown in the figure, req0, req1, ..., reqn are n arbitration requests, cfg is configuration information, ack is the user's response signal ack, and frame_end is the frame end identifier. It can be understood that the comparator 110 can determine whether the arbitration request obtained in the previous round of arbitration has completed data processing before the next round of arbitration, and the next round of arbitration can be carried out only after the arbitration request obtained in the previous round of arbitration has completed data processing and released the right to use bandwidth resources. The comparator 110 can determine whether the arbitration request obtained in the previous round of arbitration has completed data processing and released the right to use bandwidth resources through the frame end identifier frame_end (such as Figure 3 As shown) to determine whether the arbitration request obtained in the previous round of arbitration has completed data processing, the frame end identifier frame_end is the frame end identifier of the data frame processed by the arbitration request obtained in the arbitration, and the identifier can be used to determine whether the data frame has been processed.

[0179] It is understandable that the arbitration result of the comparator 110 can be confirmed by the response signal ack, and the response signal ack of the user who obtains the arbitration is pulled high. Each user can determine whether it has obtained the arbitration through the response signal ack fed back by the comparator 110.

[0180] As described above, the time window counter 140 sends an initialization signal to the satisfaction counter 130 and the ultra-bandwidth detector 120 when the time window is reached. That is, the satisfaction counter 130 and the ultra-bandwidth detector 120 are updated periodically based on the time window, thereby achieving local fairness in arbitration. To achieve global fairness in arbitration, the present embodiment also provides the following solution:

[0181] Optionally, the comparator 110 is further configured to:

[0182] At the end of the current time window, based on the bandwidth satisfaction of each user, a compensation value of the bandwidth satisfaction of the next time window is obtained; wherein the compensation value is positively correlated with the bandwidth satisfaction;

[0183] And, in the first round of intra-group arbitration in the next time window, the bandwidth satisfaction is compensated using the compensation value.

[0184] This implementation example is:

[0185] Assuming that the hardware arbitrator 100 arbitrates the arbitration requests of four users within the current time window, then at the end of the current time window, before the next round of formal arbitration (which can be called true arbitration) is carried out, three consecutive rounds of arbitration (which can be called false arbitration) can be carried out;

[0186] The difference between fake arbitration and real arbitration is that the purpose of real arbitration is to allocate bandwidth resource usage rights to the winning user, while the purpose of fake arbitration is to allocate compensation satisfaction to each user.

[0187] In the first round of fake arbitration, there are four users participating. The users who won the fake arbitration had a compensation satisfaction of 0 in the next round of real arbitration.

[0188] After excluding the users who won the first round of fake arbitration, there are three users participating in the second round of fake arbitration. The compensation satisfaction of the users who won the fake arbitration in the next round of real arbitration is 1;

[0189] After removing the users who won the second round of fake arbitration, there are two users participating in the third round of fake arbitration. The users who won the fake arbitration in this round have a compensation satisfaction of 2 in the next round of real arbitration.

[0190] Finally, the users who failed in all three rounds of fake arbitration had a compensation satisfaction of 3 in the next round of real arbitration;

[0191] After entering the next round of real arbitration, if the received arbitration request is still sent by the above four users, then in the next round of real arbitration, it will be preferentially assigned to users with high priority and low compensation satisfaction value.

[0192] Exemplarily, the compensation satisfaction acquisition rules may be pre-configured in the comparator 110. After the current time window ends, the compensation satisfaction of each user may be determined according to the pre-configured rules, so as to achieve a positive correlation between the compensation satisfaction and the bandwidth satisfaction.

[0193] In addition, it is understandable that the purpose of the positive correlation between compensation satisfaction and bandwidth satisfaction is to: the bandwidth satisfaction of users who obtain arbitration in this round will be greater, and in each arbitration, users with high priority and low bandwidth satisfaction are determined to be the winners. Therefore, setting the compensation satisfaction and bandwidth satisfaction to be positively correlated can ensure that in the next round of real arbitration, users with low bandwidth satisfaction in the previous round can be given priority in arbitration, thereby achieving global fairness in arbitration to a certain extent.

[0194] Furthermore, the compensation satisfaction of the winning user in the first round of fake arbitration is set to 0. If, in the next round of real arbitration, the hardware arbitrator 100 receives an arbitration request from a new user, since the new user has not yet obtained arbitration and its bandwidth usage is 0, the new user's bandwidth satisfaction will also be 0. In the next round of real arbitration, users who had a chance to obtain arbitration at the end of the previous time window can participate in fair arbitration with the new user, thereby further improving the overall fairness of arbitration.

[0195] At the end of the current time window, the above scheme allocates a bandwidth satisfaction compensation value to each user. This value can be used to compensate for bandwidth satisfaction during the first round of intra-group arbitration in the next time window. This allows users who had the opportunity to obtain arbitration at the end of the previous time window to obtain arbitration first, which is conducive to further improving the global fairness of arbitration.

[0196] Optionally, the comparator 110 determines the arbitration request with the lowest bandwidth satisfaction as the winning arbitration request, including:

[0197] If there are multiple arbitration requests with the lowest bandwidth satisfaction in the winning group, the arbitration request with the smallest user identifier is determined as the winning arbitration request; wherein, the smaller the user identifier, the smaller the encoding value of the user identifier. This embodiment is for example:

[0198] User IDs can be determined by sequentially numbering the users entering the hardware arbiter 100, for example, 0, 1, 2, 3, and so on. The user IDs can then be encoded, for example, by binary encoding. Since the user ID is unique, the user code value is also unique. Arbitration requests with the same bandwidth satisfaction can be arbitrated using the unique user ID code value. For arbitration within a group, if the current group contains only one user, that user is determined to be the winner. If the current group contains multiple users, the bandwidth satisfaction of each user is compared, and the user with the lowest bandwidth satisfaction is determined to be the winner. If there are multiple users with the same bandwidth satisfaction and the lowest bandwidth satisfaction, arbitration can be awarded to the user with the smallest user ID code value.

[0199] In the above solution, when the bandwidth satisfaction levels are the same, multiple arbitration requests with the same bandwidth satisfaction levels can be arbitrated using the code value determined based on the user identifier, which is beneficial to improving the fairness and efficiency of arbitration.

[0200] Furthermore, it is understood that the user identifiers may also be numbered based on the order in which the arbitration requests are received by the hardware arbitrator 100. If multiple arbitration requests are received simultaneously, they may be randomly numbered. This allows arbitration to be performed on a first-in, first-out basis when multiple bandwidth satisfaction levels are the same.

[0201] Optionally, the comparator 110 is further configured to:

[0202] The user priority, bandwidth satisfaction and user ID of each user are encoded respectively; wherein, the smaller the encoding value of the user priority, the higher the user priority; the smaller the encoding value of the bandwidth satisfaction, the lower the bandwidth satisfaction; the smaller the encoding value of the user ID, the smaller the user ID;

[0203] The coding of user priority, bandwidth satisfaction and user identification are sequentially integrated into a decision identification;

[0204] In addition, the numerical value of the decision identifier is used to conduct inter-group arbitration and intra-group arbitration.

[0205] This implementation example is:

[0206] The comparator 110 uses a composite comparator to perform inter-group arbitration and intra-group arbitration by comparing the numerical values of the decision identifiers;

[0207] See Figure 4 ,The decision identifiers from high to low are : group code, bandwidth satisfaction code and user identification code;

[0208] The group code determined by user priority and ultra-bandwidth is located in the high bit of the decision flag and occupies 2 bits.

[0209] The bandwidth satisfaction code occupies the middle bit of the decision identifier. In the first group, the bandwidth satisfaction is composed of the urgency weight and the bandwidth satisfaction. The urgency weight is located in the high bit of the decision identifier, and the bandwidth satisfaction is located in the low bit of the decision identifier. When calculating the value of the decision identifier, the urgency weight and the bandwidth satisfaction can be added together to obtain the weighted bandwidth satisfaction of users in the highest priority group.

[0210] The user identification code occupies the low bit of the decision identification;

[0211] The group code, bandwidth satisfaction code and user identification code are bit-wise concatenated to obtain a decision identification. The comparator 110 can arbitrate bandwidth resources to the user with the smallest decision identification value by comparing the bit-wise concatenated numbers of different users.

[0212] The above scheme concatenates the group code, bandwidth satisfaction code, and user identification code bit by bit to obtain a decision identifier, so that the comparator 110 can directly make inter-group and intra-group decisions by comparing the sizes of the decision identifiers. On the one hand, this helps improve the arbitration efficiency of the above-mentioned hardware arbiter 100; on the other hand, compared with the method of increasing the bit width of the comparator 110, the above scheme reuses certain bits of the comparator, which helps reduce the implementation cost of the comparator 110.

[0213] In general, when the hardware arbitrator 100 performs arbitration, users with higher user priorities will be given priority over users with lower user priorities; users with lower historical bandwidth satisfaction will be given priority over users with higher historical bandwidth satisfaction; and users who have not exceeded their bandwidth will be given priority over users who have exceeded their bandwidth.

[0214] During the arbitration process, the hardware arbitrator 100 can implement different arbitration modes through software configuration deployed in the host computer, for example:

[0215] (1) The user priority of all users is configured as the highest priority, and the emergency weight is configured according to user needs, thereby achieving fixed priority arbitration;

[0216] (2) The user priority of all users is configured as the highest priority, and the emergency weight of all users is also configured as the same value, thereby realizing polling arbitration;

[0217] (3) All users are assigned a low priority level, and bandwidth requests are allocated based on customer needs, thus achieving bandwidth satisfaction arbitration.

[0218] (4) Freely configure user priority and requested bandwidth to achieve hybrid arbitration.

[0219] Based on the same inventive concept, an arbitration method is also provided in an embodiment of the present application, and the method includes:

[0220] Step S310: arbitrate at least two arbitration requests based on user priority, user bandwidth usage information, and bandwidth satisfaction to determine a winning arbitration request; wherein the bandwidth satisfaction is used to represent the ratio of the user's used bandwidth to the requested bandwidth in the current time window.

[0221] Optionally, the above step S310 may include:

[0222] Grouping received arbitration requests based on user priority and user bandwidth usage information; wherein the user bandwidth usage information includes: information on whether the user's bandwidth usage in the current time window exceeds the requested bandwidth, and information on whether the user is allowed to continue using bandwidth resources if the bandwidth usage exceeds the requested bandwidth;

[0223] Conduct arbitration between groups based on their priorities;

[0224] Intra-group arbitration is performed among the winning groups, and the arbitration request with the lowest bandwidth satisfaction is determined as the winning arbitration request.

[0225] Based on the same inventive concept, an embodiment of the present application further provides a processor, which is used to run a program, wherein any one of the above arbitration methods is executed when the program is running.

[0226] The above-mentioned processors can be GPU (Graphics Processing Unit, graphics processor), CPU (Central Processing Unit, central processing unit), AI (Artificial Intelligence, artificial intelligence), NPU (Neural Network Processing Unit, neural network processor), ISP (Image Signal Processor, image signal processor), DPU (Display Processing Unit, display processor), VPU (Video Processing Unit, video processing unit), DSP (Digital Signal Processor) data processing core, etc., or they can be processor chips used in some scenarios such as large-scale data computing. The above are only examples and should not be a limitation to this application.

[0227] Based on the same inventive concept, an embodiment of the present application further provides a chip, which includes any one of the above-mentioned hardware arbiters 100 .

[0228] Based on the same inventive concept, an embodiment of the present application further provides an electronic device, the electronic device comprising:

[0229] Any of the above hardware arbiters 100;

[0230] or, the processor described above;

[0231] Alternatively, the aforementioned chip.

[0232] The above are merely examples of the present application and are not intended to limit the scope of protection of the present application. Those skilled in the art will appreciate that various modifications and variations are possible. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present application shall be included within the scope of protection of the present application.

Claims

1. A hardware arbitrator, characterized in that: include: Comparator; The comparator is configured to execute an arbitration strategy in response to at least two received arbitration requests before processing a next data frame to determine a winning arbitration request; The arbitration strategy includes: Based on user priority, user bandwidth usage information, and bandwidth satisfaction, at least two arbitration requests are arbitrated to determine a winning arbitration request; wherein the bandwidth satisfaction is used to represent the ratio of the user's used bandwidth to the requested bandwidth in the current time window.

2. The hardware arbiter according to claim 1, wherein: The arbitrating at least two arbitration requests based on the user priority, the user bandwidth usage information, and the bandwidth satisfaction level to determine a winning arbitration request includes: The received arbitration requests are grouped based on user priority and user bandwidth usage information, wherein the user bandwidth usage information includes: information on whether the bandwidth used by the user in the current time window exceeds the requested bandwidth and information on whether the user is allowed to continue using the bandwidth resource when the bandwidth used exceeds the requested bandwidth; performing arbitration between groups based on the priorities of the groups; Intra-group arbitration is performed in the winning group, and the arbitration request with the lowest bandwidth satisfaction is determined as the winning arbitration request.

3. The hardware arbiter according to claim 2, wherein: The comparator performs intra-group arbitration in the winning group and determines the arbitration request with the lowest bandwidth satisfaction as the winning arbitration request, including: If the winning group is the highest priority group, the arbitration request with the lowest weighted bandwidth satisfaction is determined as the winning arbitration request; wherein the weighted bandwidth satisfaction is obtained by weighting the bandwidth satisfaction using the request urgency weight; the urgency weight is a weight pre-configured for each of the users.

4. The hardware arbiter according to claim 3, wherein: The comparator is also used to: Before executing the arbitration strategy, detect whether the configuration information has changed. If the configuration information has changed, update the configuration information; wherein the configuration information includes the window length of the time window, the user priority, the requested bandwidth, information on whether the user is allowed to continue using the bandwidth resource when the used bandwidth exceeds the requested bandwidth, and the urgency weight.

5. The hardware arbiter according to claim 2, wherein: The hardware arbiter further includes: a satisfaction counter, the satisfaction counter being electrically connected to the comparator; The satisfaction counter is used to calculate the bandwidth satisfaction of each user and send the bandwidth satisfaction to the comparator; The satisfaction counter includes a decimal counter and an integer counter, wherein: The decimal counter is configured to, after the arbitration request of the user wins, increase a first preset value in the first counting identifier every clock cycle; and, when the value in the first counting identifier reaches a second preset value, notify the integer counter to increase a third preset value in the second counting identifier and clear the first counting identifier; wherein the first counting identifier and the second counting identifier are respectively used to represent the decimal part and the integer part of the ratio of the user's actual used bandwidth to the clock cycle after the user wins the arbitration request; the second preset value is positively correlated with the first ratio; and the first ratio is the ratio of the user's applied bandwidth to the clock cycle; The integer counter is configured to add a third preset value to the second counting identifier after receiving a notification from the decimal counter.

6. The hardware arbiter according to claim 5, characterized in that: The integer counter is further used for: Before the hardware arbitrator executes the arbitration strategy, the value in the second counting identifier is sent to the comparator as the bandwidth satisfaction of the user.

7. The hardware arbiter according to claim 5, wherein: The hardware arbiter further includes: an ultra-bandwidth detector, the ultra-bandwidth detector being electrically connected to the comparator; The ultra-bandwidth detector is configured to detect whether the bandwidth used by the user in the current time window exceeds the requested bandwidth, and send the detection result to the comparator.

8. The hardware arbiter according to claim 7, wherein: The hardware arbiter further includes: a time window counter, the time window counter being electrically connected to the satisfaction counter and the ultra-bandwidth detector respectively; The time window counter is configured to increase a fourth preset value in a third counting identifier for each clock cycle after the current time window begins; and, when the value in the third counting identifier reaches a fifth preset value, send an initialization signal to the satisfaction counter and the ultra-bandwidth detector, and clear the third counting identifier; wherein the third counting identifier is used to represent the number of clock cycles completed within the current time window; the fifth preset value is positively correlated with a second ratio; and the second ratio is a ratio of the window length of the current time window to the clock cycle; The satisfaction counter is further configured to clear the first counting flag and the second counting flag to zero upon receiving the initialization signal sent by the time window counter; The ultra-wideband detector is further configured to clear the third counting flag to zero upon receiving the initialization signal sent by the time window counter.

9. The hardware arbiter according to claim 2, wherein: The comparator is also used to: At the end of the current time window, based on the bandwidth satisfaction of each user, obtaining a compensation value of the bandwidth satisfaction in the next time window; wherein the compensation value is positively correlated with the bandwidth satisfaction; And, in a first round of intra-group arbitration in the next time window, the bandwidth satisfaction level is compensated using the compensation value.

10. The hardware arbiter according to any one of claims 2 to 9, characterized in that: The comparator determines the arbitration request with the lowest bandwidth satisfaction as the winning arbitration request, including: If there are multiple arbitration requests with the lowest bandwidth satisfaction in the winning group, the arbitration request with the smallest user ID is determined as the winning arbitration request; wherein, the smaller the user ID, the smaller the encoding value of the user ID.

11. The hardware arbiter according to claim 10, wherein: The comparator is also used to: Encoding the user priority, the bandwidth satisfaction, and the user identifier of each user respectively; wherein the smaller the encoded value of the user priority, the higher the user priority; the smaller the encoded value of the bandwidth satisfaction, the lower the bandwidth satisfaction; and the smaller the encoded value of the user identifier, the smaller the user identifier; The code of the user priority, the code of the bandwidth satisfaction and the code of the user identifier are sequentially merged and spliced into a decision identifier; Furthermore, the inter-group arbitration and the intra-group arbitration are performed using the numerical value of the decision identifier.

12. The hardware arbiter according to any one of claims 2 to 9, characterized in that: The groups include: a first group, a second group, a third group, and a fourth group, which are sorted in descending order of group priority, wherein: The user priority of the user in the first group is an emergency priority; The user priority of the user in the second group is a non-urgent priority, and the bandwidth used by the user in the current time window does not exceed the applied bandwidth; The user priority of the user in the third group is a non-urgent priority, the bandwidth used by the user in the current time window exceeds the used bandwidth, and the user is allowed to continue using the bandwidth resource after the used bandwidth exceeds the applied bandwidth; The user in the fourth group has no arbitration request, or the user priority of the user is a non-emergency priority, the used bandwidth of the user in the current time window exceeds the used bandwidth, and after the used bandwidth exceeds the applied bandwidth, the user is not allowed to continue using the bandwidth resource.

13. An arbitration method for a hardware arbitrator according to any one of claims 1 to 12, characterized in that: The method comprises: Before processing a next data frame, executing an arbitration strategy in response to at least two received arbitration requests to determine a winning arbitration request; The arbitration strategy includes: Based on user priority, user bandwidth usage information, and bandwidth satisfaction, at least two arbitration requests are arbitrated to determine a winning arbitration request; wherein the bandwidth satisfaction is used to represent the ratio of the user's used bandwidth to the requested bandwidth in the current time window.

14. A processor, characterized in that: The processor is configured to run a program, wherein the program executes the method according to claim 13 when running.

15. A chip, characterized in that: The chip includes the hardware arbiter according to any one of claims 1 to 12.

16. An electronic device, characterized in that: The electronic device comprises: The hardware arbiter according to any one of claims 1 to 12; or, a processor as claimed in claim 14; Or, the chip as claimed in claim 15.

Images