A traffic portrait based adaptive arbitration method and device in SOC

Abstract

The application discloses a kind of SOC based on traffic portrait adaptive arbitration method and device, belong to integrated circuit technical field.Method includes: in each arbitration period, the request behavior characteristics of each input channel is obtained;Traffic portrait is generated for the request set of each input channel based on the request behavior characteristics;Based on the traffic portrait, effective weight is generated for each input channel;According to the effective weight of each input channel, the request of each input channel is adaptively arbitrated.The application can make arbitration decision adaptively adjust with the behavior change of each input channel, to meet the comprehensive requirements of modern SoC to low delay, high throughput, fairness, dynamic service quality guarantee and congestion robustness.

Description

Technical Field

[0001] This invention relates to the field of integrated circuit technology, and in particular to an adaptive arbitration method and apparatus based on traffic profile in a System-on-a-Chip (SoC). Background Technology

[0002] With the continuous advancement of integrated circuit manufacturing processes and the rapid development of heterogeneous computing architectures, the number of functional modules integrated on a single chip in modern System-on-Chip (SoC) systems is constantly increasing. A typical SoC includes a central processing unit (CPU), graphics processing unit (GPU), neural network processor (NPU), digital signal processor (DSP), direct memory access controller (DMA), and various I / O controllers, among other master devices. These master devices access shared memory, cache, peripherals, or bus resources through on-chip interconnect structures such as Network-on-Chip (NoC), shared buses, or crossbar switches. When multiple master devices simultaneously request access to shared resources, an arbitrator needs to make scheduling decisions among the multiple requests to ensure that only one master device obtains the right to use the shared resource at any given time.

[0003] Existing arbitrators typically employ arbitration mechanisms such as fixed priority, round-robin (RR), time-division multiplexing (TDM), or weighted round-robin (WRR).

[0004] The implementation and existing problems of the above four arbitration mechanisms will be explained below.

[0005] The fixed-priority arbitration mechanism assigns a fixed priority to each channel, with higher-priority channels obtaining shared resources. However, in this arbitration mechanism, lower-priority channels may be unable to receive service for extended periods, priorities cannot be dynamically adjusted based on real-time load, resulting in poor fairness, and low-priority task latency lacks an upper bound.

[0006] The polling arbitration mechanism involves multiple channels taking turns to receive arbitration opportunities in a fixed order, regardless of task urgency. However, this mechanism cannot distinguish between urgent and routine tasks, and delay-sensitive tasks may be blocked by routine tasks, resulting in limited resource utilization under heterogeneous loads.

[0007] Time-division multiplexing arbitration mechanisms divide time into fixed time slots and pre-allocate these slots to different channels. Under this arbitration mechanism, time slots are wasted when channels are idle, making it difficult to adapt to sudden traffic surges; furthermore, requests may have to wait for the next fixed time slot, leading to increased latency.

[0008] The weighted round-robin arbitration mechanism allocates arbitration opportunities to channels according to preset weights, with higher weights granting more opportunities. The problems with this mechanism are that the weights are usually statically configured, failing to reflect real-time traffic conditions, and significant weight disparities can still lead to long wait times; furthermore, it lacks a fast channel for sudden, urgent requests.

[0009] In summary, while existing arbitration mechanisms are simple to implement, they fall short of meeting the comprehensive requirements of modern SoCs for low latency, high throughput, fairness, dynamic quality of service guarantees, and congestion robustness. Therefore, a new arbitration scheme capable of satisfying these comprehensive requirements is urgently needed. Summary of the Invention

[0010] This invention provides an adaptive arbitration method and apparatus based on traffic profiling in a System-on-Chip (SOC). The technical solution is as follows: On the one hand, an adaptive arbitration method based on traffic profiling in a System-on-Chip (SOC) is provided, the method comprising: Within each arbitration cycle, acquire the request behavior characteristics of each input channel; Based on the aforementioned request behavior characteristics, a traffic profile is generated for the request set of each input channel; Based on the traffic profile, effective weights are generated for each input channel; Arbitrate the requests from each input channel based on the effective weight of each input channel.

[0011] In a preferred embodiment, the request behavior characteristics include at least: valid request, consecutive request length, adjacent request interval, and waiting period; The process of generating traffic profiles for each input channel based on the request behavior characteristics includes: Determine the number of valid requests within the sliding window, and determine the traffic density of the corresponding input channel based on this number; Based on the continuous request length of the input channel, the average burst length of the input channel is updated using an exponential moving average, and the average burst length is used as the traffic burst degree of the corresponding input channel. Based on the number of idle cycles between adjacent request intervals, the average request interval of the input channel is updated using an exponential moving average, and the average request interval is used as the traffic sparsity of the corresponding input channel. For input channels with valid requests that have not been arbitrated, the accumulated value of the waiting period is incremented in each clock cycle, and the accumulated value of the waiting period is determined as the traffic hunger level. The four dimensions of the traffic profile are determined by the traffic density, the traffic burstiness, the traffic sparsity, and the traffic hunger, thus obtaining the traffic profile.

[0012] In a preferred embodiment, generating effective weights for each input channel based on the traffic profile includes: The traffic profile is classified to obtain the classification results for each input channel; the classification results include sparse, bursty, streaming, or normal types. The basic weights of the corresponding input channels are determined based on the classification results. Determine the number of consecutive skips for each input channel; Calculate the emergency compensation value based on the flow hunger of each input channel; Based on the basic weights, the number of consecutive skips, and the emergency compensation value, effective weights for each input channel are generated.

[0013] In a preferred embodiment, generating effective weights for each input channel based on the base weights, the number of consecutive skips, and the emergency compensation value includes: When the number of consecutive skips reaches the preset hunger threshold, a forced service flag is set for the corresponding input channel; The effective weight of each input channel is determined based on the basic weight, the emergency compensation value, and whether a mandatory service flag is set. If a mandatory service flag is set, the effective weight is assigned a preset maximum value. If there is no mandatory service flag, the effective weight is the sum of the basic weight and the emergency compensation value after saturation clamping.

[0014] In a preferred embodiment, after calculating the emergency compensation value, the method further includes: determining whether the emergency compensation value exceeds an emergency threshold; if so, configuring an emergency request flag for the corresponding input channel. The arbitration of requests for each input channel includes: The existence of an emergency request is determined based on whether an emergency request flag is configured; if an emergency request exists and the downstream interface allows it to be received, the arbitration result is determined based on the input channel configured with the emergency request flag. If there are no urgent requests, a weighted round-robin scheduling is performed on the set of ordinary requests based on the effective weights of each input channel, and the arbitration result is determined based on the input channel with the largest effective weight.

[0015] In a preferred embodiment, it further includes: The downstream back pressure signal is detected. When the downstream is in a congested state, a hierarchical suppression mask is generated according to the request type. The hierarchical suppression mask is used to reserve the passage qualification for emergency requests and forced service requests, and to temporarily suppress ordinary requests. The forced service request is a request whose corresponding input channel is set with a forced service flag.

[0016] On the other hand, an adaptive arbitration device based on traffic profile in a System-on-Chip (SOC) is provided, the device comprising: The acquisition unit is used to acquire the request behavior characteristics of each input channel in each arbitration cycle; The first generation unit is used to generate a traffic profile for the request set of each input channel based on the request behavior characteristics; The second generation unit is used to generate effective weights for each input channel based on the traffic profile. The arbitration unit is used to arbitrate the requests of each input channel based on the effective weight of each input channel.

[0017] On the other hand, a computer device is provided, the computer device including a memory and a processor, the memory for storing computer programs, and the processor for executing the computer programs stored in the memory to implement the steps of the adaptive arbitration method based on traffic profile in the SOC described above.

[0018] On the other hand, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when the computer program is executed by a processor, it implements the steps of the adaptive arbitration method based on traffic profile in the SOC described above.

[0019] On the other hand, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the adaptive arbitration method based on traffic profile in the SOC described above.

[0020] The technical solution provided by this invention can bring at least the following beneficial effects: In this embodiment of the invention, a traffic profile is generated for the request set of each input channel, and an effective weight is generated for each input channel based on the traffic profile. The traffic profile is not generated based on the content of the request message, but on the request behavior characteristics of the input channel. Since the request behavior characteristics are dynamically changing, the effective weight also needs to be dynamically changed according to the different traffic profiles. This allows the arbitration decision to be adaptively adjusted according to the behavior changes of each input channel, thereby meeting the comprehensive requirements of modern SoC for low latency, high throughput, fairness, dynamic quality of service assurance, and congestion robustness. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a flowchart of an adaptive arbitration method based on traffic profiling in a System-on-Chip (SOC) according to an embodiment of the present invention; Figure 2 This is a structural diagram of an adaptive arbitration device based on traffic profile in a SOC provided by an embodiment of the present invention; Figure 3 This is a hardware architecture diagram of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are some embodiments of the present invention, but not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0024] Please refer to Figure 1 This invention provides an adaptive arbitration method based on traffic profile in a System-on-Chip (SOC), the method comprising: Step 100: Within each arbitration cycle, obtain the request behavior characteristics of each input channel; Step 102: Generate a traffic profile for the request set of each input channel based on the request behavior characteristics; Step 104: Generate effective weights for each input channel based on the traffic profile; Step 106: Arbitrate the requests of each input channel according to the effective weight of each input channel.

[0025] In this embodiment of the invention, a traffic profile is generated for the request set of each input channel, and an effective weight is generated for each input channel based on the traffic profile. The traffic profile is not generated based on the content of the request message, but on the request behavior characteristics of the input channel. Since the request behavior characteristics are dynamically changing, the effective weight also needs to be dynamically changed according to the different traffic profiles. This allows the arbitration decision to be adaptively adjusted according to the behavior changes of each input channel, thereby meeting the comprehensive requirements of modern SoC for low latency, high throughput, fairness, dynamic quality of service assurance, and congestion robustness.

[0026] The following description Figure 1 The execution method of each step is shown.

[0027] First, for step 100, within each arbitration cycle, the request behavior characteristics of each input channel are obtained.

[0028] Existing arbitrators typically treat all requests as homogeneous data packets, failing to recognize different traffic patterns such as CPU instruction fetch cache misses, NPU weight loading, GPU rendering streams, and DMA batch transfers. Due to a lack of comprehensive awareness of request density, burst length, request intervals, and latency, arbitrators cannot employ differentiated scheduling strategies for different traffic types, potentially causing latency-sensitive tasks to be blocked by bandwidth-intensive tasks.

[0029] Based on this, in this embodiment of the invention, the traffic profile of each input channel is identified by acquiring the request behavior characteristics of each input channel, so as to dynamically adjust the effective weight and thereby adopt a differentiated scheduling strategy for different traffic types.

[0030] In one embodiment of the present invention, the request behavior characteristics include at least: a valid request, a continuous request length, an adjacent request interval, and a waiting period. A valid request refers to whether the master device has initiated a valid access request to the arbitrator in the current clock cycle; the continuous request length refers to the number of consecutive clock cycles in which a valid request remains high without interruption; the adjacent request interval refers to the number of idle cycles between the end of the previous request and the start of the next request; and the waiting period refers to the cumulative number of clock cycles elapsed since a valid request has existed on the input channel but has not yet been authorized by the arbitrator.

[0031] In this embodiment of the invention, the above four features are used as request behavior features for subsequent generation of traffic profiles. This is mainly because these feature behaviors can be directly obtained on the hardware, and the above four feature behaviors can respectively describe whether there is a valid request, traffic density, traffic gap and latency. They are orthogonal in a physical sense. Combining these four features together forms a four-dimensional feature space, which can map the traffic behavior of any master device with low overhead.

[0032] It should be noted that, in addition to the above-mentioned request behavior characteristics, other characteristics may also be included, such as target address, protocol characteristics, historical behavior status, etc.

[0033] Then, for step 102, a traffic profile is generated for the request set of each input channel based on the request behavior characteristics.

[0034] In this embodiment of the invention, when the request behavior characteristics include valid requests, consecutive request length, adjacent request interval and waiting period, traffic density, traffic burstiness, traffic sparsity and traffic hunger can be determined based on valid requests, consecutive request length, adjacent request interval and waiting period, so as to use the four-dimensional features composed of traffic density, traffic burstiness, traffic sparsity and traffic hunger as traffic profile.

[0035] Specifically, generating a traffic profile for the request set of each input channel based on the requested behavior characteristics may include the following steps 1020-1028: Step 1020: Determine the number of valid requests within the sliding window, and determine the traffic density of the corresponding input channel based on this number; In this embodiment of the invention, each input channel can maintain an N-bit shift register, where N is an integer between 32 and 128, such as N=64. At the rising edge of each clock cycle, the shift register shifts left by 1 bit, and the valid request value (1 or 0) for the current cycle of the input channel is written to the least significant bit. After the shift is complete, the number of valid requests within the sliding window can be obtained by counting all the 1s in the N-bit register using a popcount circuit. In one implementation, the number of valid requests can be directly used as a representation of the flow density of the corresponding input channel, or the ratio of the number of valid requests to N can be used as the flow density of the corresponding input channel. For example, if an input channel has initiated 24 valid requests in the last 64 cycles, then its shift register will have 24 bits set to 1, and the popcount circuit will output 24.

[0036] Step 1022: Based on the continuous request length of the input channel, update the average burst length of the input channel using exponential moving average, and use the average burst length as the traffic burst degree of the corresponding input channel; In this embodiment of the invention, each input channel can maintain a current burst counter and an average burst register. When an input channel has a valid request, the current burst counter increments by 1 in each clock cycle. When the hardware detects that a valid request changes from valid to invalid, it determines that the current burst has ended. At this time, the current value of the current burst counter is taken as the continuous request length of this burst and substituted into the following exponential moving average formula: avg_burst_new = (avg_burst_old × 3 + current_burst)>>2 Where avg_burst_new is the current average burst length, avg_burst_old is the previous average burst length, and current_burst is the continuous request length of the current burst; >>2 means right shift by 2 bits, that is, divide by 4, which is a smoothing coefficient of 0.25, which can be achieved by shifting and adding operations.

[0037] After obtaining the average burst length, the average burst length can be stored in the average burst register, and the current burst counter can be cleared to start counting the next burst.

[0038] Step 1024: Based on the number of idle cycles between adjacent request intervals, update the average request interval of the input channel using exponential moving average, and use the average request interval as the traffic sparsity of the corresponding input channel. In this embodiment of the invention, each input channel can maintain an interval counter and an average interval register. When a valid request for an input channel is invalid, the interval counter increments by 1 in each clock cycle; when the hardware detects that a valid request has changed from invalid to valid, it is determined that a new request has arrived. At this time, the current value of the interval counter is used as the number of idle cycles between adjacent requests, and the average request interval is updated using an exponential moving average method. avg_gap_new = (avg_gap_old × 3 + current_gap)>>2 Where avg_gap_new is the updated average request interval, avg_gap_old is the previous average request interval, and current_gap is the number of idle periods between adjacent request intervals.

[0039] After the update is completed, the average request interval is stored in the average interval register, and the interval counter is cleared to start counting the next request interval.

[0040] Step 1026: For input channels with valid requests that have not been arbitrated, increment the accumulated value of the waiting period in each clock cycle, and determine the accumulated value of the waiting period as the traffic hunger level. In this embodiment of the invention, each input channel can maintain a wait accumulator register. Each clock cycle, if the input channel has a valid request but fails to obtain arbitration, the wait accumulator register is incremented by 1. The value of the wait accumulator register is the accumulated value of the waiting period. The longer the waiting period, the higher the traffic hunger; therefore, the accumulated value of the waiting period can be determined as the traffic hunger level. When the input channel obtains arbitration, the wait accumulator register is cleared to zero.

[0041] Step 1028: Determine the four dimensions of the traffic profile by considering the traffic density, traffic burstiness, traffic sparsity, and traffic hunger, and obtain the traffic profile.

[0042] In this embodiment of the invention, the traffic density, traffic burstiness, traffic sparsity, and traffic hunger of the input channel are used to construct a traffic profile for the corresponding input channel.

[0043] This traffic profile, generated in real-time by the arbitrator's local hardware, represents multi-dimensional behavioral characteristics for each input channel. It does not rely on upstream packet headers or sideband QoS fields; instead, it characterizes the current behavioral pattern of the input channel entirely by monitoring the start, end, density, and rhythm of request signals, thus establishing a dynamically updated profile for each master device. Therefore, this embodiment of the invention achieves the ability to perceive traffic differences without relying on external information, thereby driving the subsequent generation of effective weights.

[0044] Next, for step 104, effective weights are generated for each input channel based on the traffic profile.

[0045] In one embodiment of the present invention, generating effective weights for each input channel based on the traffic profile includes the following steps 1040-1048: Step 1040: Classify the traffic profile to obtain the classification results for each input channel; the classification results include sparse, bursty, streaming, or normal types; Step 1042: Determine the basic weights of the corresponding input channels based on the classification results; Step 1044: Determine the number of consecutive skips for each input channel; Step 1046: Calculate the emergency compensation value based on the flow hunger of each input channel; Step 1048: Generate effective weights for each input channel based on the base weights, the number of consecutive skips, and the emergency compensation value.

[0046] In step 1040, in a preferred embodiment of the present invention, the traffic profile can be classified according to the following preset rules: If the flow density is less than the first preset threshold and the flow sparsity is greater than the second preset threshold, it is determined to be sparse. Otherwise, if the burstiness of the traffic exceeds the third preset threshold, it is determined to be a burst type; Otherwise, if the flow density is greater than the fourth preset threshold, it is determined to be a flow-type flow. Otherwise, it is classified as a normal type.

[0047] In a preferred embodiment, the first preset threshold is 4, the second preset threshold is 32 clock cycles, the third preset threshold is 16 clock cycles, and the fourth preset threshold is 1 / M of the window length of the sliding window, where M is an integer greater than 1, such as M equals 4.

[0048] Traffic profiles are categorized into four types: sparse, bursty, streaming, and normal. These four traffic types cover several typical applications currently known. Typical applications of sparse traffic include CPU instruction fetching, cache misses, and interrupt access; typical applications of bursty traffic include NPU weight loading and bursty image processing; typical applications of streaming traffic include GPU rendering, video encoding / decoding, and continuous data streaming; and typical applications of normal traffic include regular DMA data transfer and normal I / O access.

[0049] In step 1042, a static weight register can be set for each input channel to store the static weight of that input channel. The static weight can be set according to the importance of the SOC task carried by the master device. For example, the static weight of the CPU channel is 50, the static weight of the NPU channel is 20, the static weight of the GPU channel is 30, and the static weight of the DMA channel is 10.

[0050] Furthermore, the static weights can be adjusted based on the traffic type to obtain the base weights. Specifically, determining the base weights for the corresponding input channels based on the classification results may include: The correction amount corresponding to the classification result is determined based on the mapping relationship. The correction amount is then used as the static weight of the corresponding input channel to obtain the basic weight of the corresponding input channel.

[0051] For example, the correction factor for sparse mappings is extremely high, such as 60; while the correction factor for ordinary mappings is lower, such as 10. In one implementation, this correction can be achieved through superposition. It can also be achieved through other methods, such as multiplication or weighting.

[0052] In step 1044, a continuous skip counter can be maintained for each input channel. At the end of each arbitration cycle, if the input channel has a valid request but has not been arbitrated, the continuous skip counter is incremented by 1; if the input channel is arbitrated, the continuous skip counter is reset to zero.

[0053] In this embodiment of the invention, the number of consecutive skips for the corresponding input channel can be determined based on the value of the consecutive skip counter.

[0054] In step 1046, the emergency compensation value can be calculated as follows: If the traffic demand is not greater than the preset demand threshold, the emergency compensation value is 0; If the flow demand is greater than the preset demand threshold, the emergency compensation value is calculated according to the following formula: boost = min((wait_cnt - T_urg)>>shift, max_boost) Here, boost is the emergency compensation value, wait_cnt is the traffic hunger level, T_urg is the preset hunger threshold; shift is used to represent the number of bits to shift right, for example, the default value is 3, which is divided by 8; max_boost is the preset maximum compensation limit, for example, the default value is 80, and the value range is 0~128. This calculation only involves subtraction, right shift, and comparison to take the smaller value, and does not involve dividers or multipliers.

[0055] For example, if T_urg is 64, shift is 3, and max_boost is 80, and the input channel's traffic hunger is 120, then the emergency compensation value calculated using the above formula is 7.

[0056] In step 1048, generating effective weights for each input channel based on the base weights, the number of consecutive skips, and the emergency compensation value includes: When the number of consecutive skips reaches the preset hunger threshold, a forced service flag is set for the corresponding input channel; The effective weight of each input channel is determined based on the basic weight, the emergency compensation value, and whether a mandatory service flag is set. If a mandatory service flag is set, the effective weight is assigned a preset maximum value. If there is no mandatory service flag, the effective weight is the sum of the basic weight and the emergency compensation value after saturation clamping.

[0057] The number of consecutive jumps is determined based on the value of the consecutive jump counter in step 1044, and hunger detection is performed based on the number of consecutive jumps to determine whether the number of consecutive jumps has reached the preset hunger threshold.

[0058] In one embodiment, if a mandatory service flag is present, the effective weight is: effective_weight = WEIGHT_MAX Here, effective_weight is the effective weight, and WEIGHT_MAX is the preset maximum value, for example, 255. This indicates that the input channel has the highest selection priority in the subsequent ordinary arbitration set.

[0059] If there is no mandatory service flag, the effective weight is calculated using the following formula: effective_weight=min(base+boost, WEIGHT_MAX) Where base is the base weight and boost is the emergency compensation value.

[0060] Therefore, the effective weight is determined by the basic weight, emergency compensation, and starvation protection.

[0061] In this embodiment of the invention, the calculation of effective weights can be implemented using adders, comparators, and selectors. The effective weights can be updated periodically, for example, every 2-4 clock cycles, to reduce the weight signal flipping frequency and dynamic power consumption.

[0062] Furthermore, in the generation of effective weights, although the emergency compensation increases with the waiting period, this increase is smooth and slow, and it can only solve the problem of fair queuing. In a System-on-a-Chip (SoC), the CPU typically adopts a pipelined architecture. If the CPU's instruction fetch or data load request does not receive a response for a long time due to arbitration delay, the pipeline will directly stop, and subsequent instructions cannot be executed, causing front-end blocking. Therefore, the system must ensure that such critical requests receive data before the pipeline flushes. Based on this, an emergency request mechanism can be set up, which, after calculating the emergency compensation value, also includes: determining whether the emergency compensation value exceeds the emergency threshold; if so, configuring an emergency request flag for the corresponding input channel.

[0063] In this embodiment of the invention, the emergency request mechanism is set up to address the problems of traditional arbitrators being too slow to respond and lacking a fast channel, providing a dedicated channel for extremely sensitive tasks. This emergency request differs from forced service. An emergency request is triggered by excessively long absolute delays and can bypass the comparator during processing, quickly achieving authorization within one clock cycle; while forced service is triggered due to relative contention failure, ensuring authorization is obtained in the next round of arbitration.

[0064] Finally, for step 106, the requests of each input channel are arbitrated according to the effective weight of each input channel.

[0065] In one embodiment of the present invention, arbitration can be performed directly using the magnitude of the effective weights, based on the maximum value of the effective weights.

[0066] In another embodiment of the present invention, requests from each input channel can be arbitrated in a tiered manner, specifically: The first level of arbitration is the emergency direct-access layer: it determines whether an emergency request exists based on whether an emergency request flag is configured. If an emergency request exists and the downstream interface allows it to be received, the arbitration result is determined based on the input channel configured with the emergency request flag. The second level of arbitration is the effective weight arbitration layer: if there is no urgent request, a weighted round-robin scheduling is performed on the set of ordinary requests based on the effective weight of each input channel, and the arbitration result is determined based on the input channel with the largest effective weight.

[0067] In the first-level arbitration, the emergency pass-through layer can detect the emergency request flags of each input channel to determine whether an emergency request exists on each input channel. If an emergency request exists, the corresponding input channel is designated as the winning channel; if multiple input channels have emergency requests simultaneously, the winning channel is determined according to a preset selection method. The emergency request of the winning channel is output through the emergency pass-through path, and the emergency request output by the emergency pass-through path is taken as the final arbitration result.

[0068] In practical implementation, an emergency request mask generator can generate an emergency request mask based on the emergency request flags and valid requests of each input channel. Each bit of the mask corresponds to an input channel; when the emergency request flag of the corresponding channel is 1 and the valid request is 1, that bit is 1. The priority encoder encodes the emergency request mask and outputs the winning channel number. If multiple input channels have emergency requests simultaneously, the priority encoder selects the channel with the smallest number as the winning channel.

[0069] The entire process, from setting the emergency request flag to outputting the emergency request via the emergency pass-through path, can be controlled within one clock cycle. This emergency pass-through mechanism is suitable for latency-sensitive scenarios such as CPU cache misses, real-time interrupts, functional safety control signals, and touch responses.

[0070] In the second-level arbitration, non-urgent ordinary requests are handled. First, all valid requests are treated as ordinary requests, and the effective weight of each input channel is determined. Then, a weighted round-robin scheduling is performed on the ordinary request set, and the input channel with the largest effective weight is selected as the arbitration result to achieve weight priority and equal weight fairness.

[0071] In its implementation, the maximum effective weight lookup circuit can consist of multiple comparators. It searches for the maximum effective weight in the set of ordinary requests and outputs the channel mask containing that weight. The polling selection circuit receives the maximum effective weight and the current polling pointer. The selection rule is as follows: among the channel masks with the maximum effective weight, the channel with a channel number not less than the current polling pointer and closest to it is selected as the winning channel. If there is no channel with a channel number not less than the current polling pointer in the channel mask with the maximum effective weight, then the channel with the smallest channel number in the channel mask with the maximum effective weight is selected as the winning channel. After each arbitration, the polling pointer update circuit updates the current polling pointer to the winning channel number. If the updated value equals the total number of channels, it wraps back to 0. This mechanism ensures fairness in the rotation among channels with equal weight and prevents a single channel from dominating for an extended period.

[0072] Furthermore, in addition to the first and second levels of arbitration mentioned above, third-level arbitration may also be included: The third-level arbitration is the backpressure coordination layer: it detects downstream backpressure signals, and when the downstream is in a congested state, it generates a hierarchical suppression mask according to the request type. The hierarchical suppression mask is used to reserve the passage qualification for urgent requests and mandatory service requests, and to temporarily suppress ordinary requests. The mandatory service request is a request whose corresponding input channel is set with a mandatory service flag.

[0073] In practical implementation, when the downstream backpressure signal is invalid (logic 0), it indicates downstream congestion and unacceptability. The suppression mask generation circuit generates the backpressure suppression mask for each channel according to the following Boolean expression: bp_suppress=req_valid&~urgent_flag&~force_service Where bp_suppress is the backpressure suppression mask, req_valid is the valid request signal, urgent_flag is the urgent request flag, force_service is the forced service flag, ~ is the logical NOT operation, and & is the logical AND operation.

[0074] Based on the masking logic above, the urgent request flag (urgent_flag=1) is not masked by bp_suppress and retains its eligibility to pass; because urgent requests are sensitive to latency, it is necessary to ensure latency as much as possible. Forced service requests with force_service=1 are not blocked by bp_suppress and are allowed to pass, in order to avoid the accumulation of starvation and deadlock. For normal requests, urgent_flag=0 and force_service=0 are blocked by bp_suppress, temporarily suppressing the sending of requests to avoid further exacerbating downstream congestion.

[0075] When the downstream reverse voltage signal becomes valid (logic 1), the suppression mask is immediately removed, and all requests regain the right to send.

[0076] Based on the above three-level arbitration, the arbitration decision output circuit generates the final authorization signal according to the following priority rules: If an emergency request channel exists and the downstream interface allows receiving, the arbitration result of the first-level arbitration emergency pass-through layer is output, ignoring the result of the second-level arbitration effective weighted arbitration layer. If there is no channel for urgent requests, but there is at least one valid normal request and the downstream interface allows it to be received, then the result of the second-level arbitration valid weight arbitration layer is output. If the downstream is in a congested state, regardless of the arbitration results of the first-level arbitration emergency direct access layer and the second-level arbitration effective weight arbitration layer, an unauthorized state will be output, and no new access will be initiated to the shared resource. If no valid requests are found on any of the channels, an unauthorized status will be output.

[0077] In this embodiment of the invention, after adaptive arbitration of the requests from each input channel, the method may further include: updating the final arbitration result.

[0078] Specifically, the feedback update includes at least the following: updating the accumulated value of the waiting period, updating the number of consecutive skips, and recalculating the effective weights.

[0079] Based on the embodiments of the present invention, simulation verification was performed on the following scenarios, and the simulation verification results are as follows: Scenario 1: Emergency Mechanism Verification During the test, the NPU continuously initiated burst requests, while the CPU initiated sparse requests at certain stages. The results showed that during the phase where both the NPU and CPU made simultaneous requests, the CPU received 46 arbitrations, while the NPU received 54. This demonstrates that CPU-based sparse traffic can be identified; when the CPU waits beyond a threshold, an emergency flag is triggered, increasing its arbitration priority, thus ensuring the smooth operation of latency-sensitive tasks.

[0080] Scenario 2: Validation of the anti-starvation mechanism The test involved continuous NPU requests, alternating GPU requests, and continuous DMA requests, with DMA having the lowest base weight. Over 120 cycles, the NPU received 32 arbitrations, the GPU received 44, and DMA received 44. This demonstrates that even with the lowest base weight, the starvation protection mechanism can still grant DMA service opportunities and prevent low-priority channels from waiting indefinitely.

[0081] Scenario 3: Backpressure Coordination Verification The test was divided into a normal phase, a downstream backpressure phase, and a recovery phase. During the backpressure phase, the downstream backpressure signal became invalid, and there was no data response; after downstream recovery, arbitration resumed immediately. This result indicates that the backpressure response is 0 cycles, and the data integrity and recovery behavior meet the design objectives.

[0082] In the embodiments of the present invention, at least the following beneficial effects exist: 1. In this embodiment of the invention, the traffic profile is not generated based on the content of the request message, but rather on the request behavior characteristics of the input channel, such as valid requests, consecutive request lengths, adjacent request intervals, and waiting periods. Based on preset classification rules, the traffic of each channel is automatically identified as sparse, bursty, streaming, or normal. Compared to the shortcomings of traditional arbitrators that treat all requests as homogeneous data packets and cannot distinguish between different traffic patterns, this invention enables the arbitrator to configure basic weights and emergency thresholds differently according to the real-time traffic type of each channel. This provides more proactive priority guarantees for latency-sensitive sparse traffic and provides scheduling strategies that match the real-time needs of bandwidth-intensive bursty or streaming traffic.

[0083] 2. In this embodiment of the invention, an independent consecutive skip counter is maintained for each input channel to record the number of times a channel has a valid request but fails to receive arbitration consecutively. When the number of consecutive skips reaches a preset starvation threshold, a forced service flag is set, directly increasing the effective weight of that channel to a saturation value, giving it the highest selection priority in the set of ordinary requests. This mechanism differs from the problem of low-priority channels potentially being permanently starved in traditional fixed-priority schemes, and also from the shortcomings of static weighted round-robin schemes where low-weight channels may still wait for a long time. This embodiment of the invention ensures strict control over the upper bound of waiting for any valid request channel. Even if the channel's basic weight is extremely low, it will inevitably receive service after the number of consecutive skips accumulates to a preset threshold, fundamentally eliminating starvation and ensuring the fairness and stability of the system's long-term operation.

[0084] 3. In this embodiment of the invention, an emergency compensation value is generated after the accumulated value of the channel waiting period exceeds a preset hunger threshold. This emergency compensation value increases monotonically with the increase of the excess waiting period and has a maximum compensation upper limit. This mechanism ensures that the effective weight of the channel increases smoothly with the extension of the waiting time, rather than jumping abruptly when the threshold is reached, thus guaranteeing the smoothness and predictability of scheduling priority changes. At the same time, the compensation value adopts right-shift scaling and upper limit clamping to avoid scheduling instability caused by drastic weight jumps.

[0085] 4. In this embodiment of the invention, the effective weight generation decouples the static basic weights and dynamic emergency compensation and then merges them through saturated addition. This preserves the software's static control over system priorities while giving the hardware the ability to adaptively and dynamically adjust to real-time load changes.

[0086] 5. In this embodiment of the invention, the mandatory service flag and emergency compensation form a dual protection mechanism. Emergency compensation moderately increases the weight when the waiting time exceeds the limit, while the mandatory service flag rapidly increases the weight to its maximum value when there are consecutive failed attempts to compete. These two mechanisms protect the channel from two different dimensions—waiting time and the number of failed attempts—complementing each other to ensure that any channel, regardless of the reason for prolonged service interruption, can obtain arbitration within a limited time.

[0087] 6. In this embodiment of the invention, an independent emergency pass-through layer is set up in the three-level arbitration mechanism, enabling emergency requests to be quickly authorized based on the emergency pass-through path. Compared with the problem of traditional solutions where emergency requests and ordinary requests are mixed and queued and need to go through a complete arbitration process, this embodiment of the invention provides deterministic and ultra-fast response guarantees for latency-sensitive scenarios such as CPU cache misses, real-time operating system interruptions, functional safety control signals, and touch responses, effectively avoiding pipeline stalls, real-time task timeouts, and system security risks caused by arbitration delays.

[0088] 7. In this embodiment of the invention, the second-level effective weight arbitration layer first selects the channel with the highest effective weight from all valid requests, and then performs a round-robin process on the set of highest weights. In this way, channels with higher weights receive priority service, while channels with the same weights ensure fair rotation through a polling pointer.

[0089] 8. In this embodiment of the invention, by setting up a backpressure coordination layer, when the downstream interface is in a congested state, tiered suppression is performed according to the request type. Urgent requests and mandatory service requests retain their eligibility to pass, while ordinary requests are temporarily suppressed. In this way, the service quality of critical requests can still be guaranteed in congested scenarios, while preventing the continuous injection of ordinary requests from further aggravating downstream congestion.

[0090] 9. In this embodiment of the invention, all arithmetic units are composed of comparators, adders, shifters and selectors, etc., and do not involve multipliers, dividers or large-capacity memory devices. The area and power consumption are within the acceptable range of the SoC, making it suitable for resource-constrained on-chip network routing nodes and bus bridges.

[0091] 10. In this embodiment of the invention, by using traffic awareness, dynamic priority, anti-starvation protection, emergency rapid response and intelligent backpressure, the tail latency of latency-sensitive tasks can be significantly reduced in typical heterogeneous computing scenarios of SoC, the effective throughput of bandwidth-intensive tasks can be improved, the service quality and timeout protection of background tasks can be guaranteed, and the overall system performance, real-time performance and fairness can be synergistically optimized.

[0092] Please refer to Figure 2 This invention provides an adaptive arbitration device based on traffic profile in a System-on-Chip (SOC), the device comprising: The acquisition unit 200 is used to acquire the request behavior characteristics of each input channel in each arbitration cycle; The first generation unit 202 is used to generate a traffic profile for the request set of each input channel based on the request behavior characteristics; The second generation unit 204 is used to generate effective weights for each input channel based on the traffic profile. Arbitration unit 206 is used to arbitrate the requests of each input channel according to the effective weight of each input channel.

[0093] In one embodiment of the present invention, the request behavior characteristics include at least: valid request, consecutive request length, adjacent request interval, and waiting period; The process of generating traffic profiles for each input channel based on the request behavior characteristics includes: Determine the number of valid requests within the sliding window, and determine the traffic density of the corresponding input channel based on this number; Based on the continuous request length of the input channel, the average burst length of the input channel is updated using an exponential moving average, and the average burst length is used as the traffic burst degree of the corresponding input channel. Based on the number of idle cycles between adjacent request intervals, the average request interval of the input channel is updated using an exponential moving average, and the average request interval is used as the traffic sparsity of the corresponding input channel. For input channels with valid requests that have not been arbitrated, the accumulated value of the waiting period is incremented in each clock cycle, and the accumulated value of the waiting period is determined as the traffic hunger level. The four dimensions of the traffic profile are determined by the traffic density, the traffic burstiness, the traffic sparsity, and the traffic hunger, thus obtaining the traffic profile.

[0094] In one embodiment of the present invention, generating effective weights for each input channel based on the traffic profile includes: The traffic profile is classified to obtain the classification results for each input channel; the classification results include sparse, bursty, streaming, or normal types. The basic weights of the corresponding input channels are determined based on the classification results. Determine the number of consecutive skips for each input channel; Calculate the emergency compensation value based on the flow hunger of each input channel; Based on the basic weights, the number of consecutive skips, and the emergency compensation value, effective weights for each input channel are generated.

[0095] In one embodiment of the present invention, generating effective weights for each input channel based on the base weights, the number of consecutive skips, and the emergency compensation value includes: When the number of consecutive skips reaches the preset hunger threshold, a forced service flag is set for the corresponding input channel; The effective weight of each input channel is determined based on the basic weight, the emergency compensation value, and whether a mandatory service flag is set. If a mandatory service flag is set, the effective weight is assigned a preset maximum value. If there is no mandatory service flag, the effective weight is the sum of the basic weight and the emergency compensation value after saturation clamping.

[0096] In one embodiment of the present invention, after calculating the emergency compensation value, the method further includes: determining whether the emergency compensation value exceeds an emergency threshold; if so, configuring an emergency request flag for the corresponding input channel. The arbitration of requests for each input channel includes: The existence of an emergency request is determined based on whether an emergency request flag is configured; if an emergency request exists and the downstream interface allows it to be received, the arbitration result is determined based on the input channel configured with the emergency request flag. If there are no urgent requests, a weighted round-robin scheduling is performed on the set of ordinary requests based on the effective weights of each input channel, and the arbitration result is determined based on the input channel with the largest effective weight.

[0097] In one embodiment of the present invention, it further includes: The downstream back pressure signal is detected. When the downstream is in a congested state, a hierarchical suppression mask is generated according to the request type. The hierarchical suppression mask is used to reserve the passage qualification for emergency requests and forced service requests, and to temporarily suppress ordinary requests. The forced service request is a request whose corresponding input channel is set with a forced service flag.

[0098] It should be noted that the adaptive arbitration device based on traffic profile in the SOC provided in the above embodiments is only an example of the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the adaptive arbitration device based on traffic profile in the SOC provided in the above embodiments and the adaptive arbitration method embodiment based on traffic profile in the SOC belong to the same concept. The specific implementation process is detailed in the method embodiment, and will not be repeated here.

[0099] Embodiments of this application also provide a computer device, please refer to... Figure 3 The computer device includes a processor and a memory, the memory storing at least one instruction, at least one program, code set or instruction set, the at least one instruction, at least one program, code set or instruction set being loaded and executed by the processor to implement the adaptive arbitration method based on traffic profile in the SOC provided in the above method embodiments.

[0100] Embodiments of this application also provide a computer-readable storage medium storing at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, at least one program, code set, or instruction set is loaded and executed by a processor to implement the adaptive arbitration method based on traffic profile in the SOC provided in the above-described method embodiments.

[0101] Embodiments of this application also provide a computer program product, which includes a computer program. A processor of a computer device reads the computer program from a computer-readable storage medium and executes the computer program, causing the computer device to perform the adaptive arbitration method based on traffic profile in any of the above embodiments of the SOC.

[0102] For ease of description, the above systems or devices are described separately as various modules or units based on their functions. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware components.

[0103] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0104] Finally, it should be noted that in this document, relational terms such as first, second, third, and fourth are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus.

[0105] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. An adaptive arbitration method based on traffic profiling in a System-on-Chip (SOC), characterized in that, The method includes: Within each arbitration cycle, acquire the request behavior characteristics of each input channel; Based on the aforementioned request behavior characteristics, a traffic profile is generated for the request set of each input channel; Based on the traffic profile, effective weights are generated for each input channel; Arbitrate the requests of each input channel based on the effective weight of each input channel.

2. The method according to claim 1, characterized in that, The request behavior characteristics include at least: valid request, consecutive request length, adjacent request interval, and waiting period; The process of generating traffic profiles for each input channel based on the request behavior characteristics includes: Determine the number of valid requests within the sliding window, and determine the traffic density of the corresponding input channel based on this number; Based on the continuous request length of the input channel, the average burst length of the input channel is updated using an exponential moving average, and the average burst length is used as the traffic burst degree of the corresponding input channel. Based on the number of idle cycles between adjacent request intervals, the average request interval of the input channel is updated using an exponential moving average, and the average request interval is used as the traffic sparsity of the corresponding input channel. For input channels with valid requests that have not been arbitrated, the accumulated value of the waiting period is incremented in each clock cycle, and the accumulated value of the waiting period is determined as the traffic hunger level. The traffic density, traffic burstiness, traffic sparsity, and traffic hunger are defined as the four dimensions of the traffic profile to obtain the traffic profile.

3. The method according to claim 2, characterized in that, The process of generating effective weights for each input channel based on the traffic profile includes: The traffic profile is classified to obtain the classification results for each input channel; the classification results include sparse, bursty, streaming, or normal types. The basic weights of the corresponding input channels are determined based on the classification results. Determine the number of consecutive skips for each input channel; Calculate the emergency compensation value based on the flow hunger of each input channel; Based on the basic weights, the number of consecutive skips, and the emergency compensation value, effective weights for each input channel are generated.

4. The method according to claim 3, characterized in that, The generation of effective weights for each input channel based on the base weights, the number of consecutive skips, and the emergency compensation value includes: When the number of consecutive skips reaches the preset hunger threshold, a forced service flag is set for the corresponding input channel; The effective weight of each input channel is determined based on the basic weight, the emergency compensation value, and whether a mandatory service flag is set. If a mandatory service flag is set, the effective weight is assigned a preset maximum value. If there is no mandatory service flag, the effective weight is the sum of the basic weight and the emergency compensation value after saturation clamping.

5. The method according to claim 4, characterized in that, After calculating the emergency compensation value, the method further includes: determining whether the emergency compensation value exceeds the emergency threshold; if so, configuring an emergency request flag for the corresponding input channel. The arbitration of requests for each input channel includes: The existence of an emergency request is determined based on whether an emergency request flag is configured; if an emergency request exists and the downstream interface allows it to be received, the arbitration result is determined based on the input channel configured with the emergency request flag. If there are no urgent requests, a weighted round-robin scheduling is performed on the set of ordinary requests based on the effective weights of each input channel, and the arbitration result is determined based on the input channel with the largest effective weight.

6. The method according to claim 5, characterized in that, Also includes: The downstream back pressure signal is detected. When the downstream is in a congested state, a hierarchical suppression mask is generated according to the request type. The hierarchical suppression mask is used to reserve the passage qualification for emergency requests and forced service requests, and to temporarily suppress ordinary requests. The forced service request is a request whose corresponding input channel is set with a forced service flag.

7. An adaptive arbitration device based on traffic profile in a System-on-Chip (SOC), characterized in that, The device includes: The acquisition unit is used to acquire the request behavior characteristics of each input channel in each arbitration cycle; The first generation unit is used to generate a traffic profile for the request set of each input channel based on the request behavior characteristics; The second generation unit is used to generate effective weights for each input channel based on the traffic profile. The arbitration unit is used to arbitrate the requests of each input channel based on the effective weight of each input channel.

8. A computer device, characterized in that, The computer device includes a memory and a processor. The memory is used to store computer programs, and the processor is used to execute the computer programs stored in the memory to implement the steps of the method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the steps of the method described in any one of claims 1-6.

10. A computer program product, characterized in that, Includes a computer program, which, when executed by a processor, implements the steps of the method according to any one of claims 1-6.

Images