System-on-chip based bus bandwidth allocation method, apparatus and related device

Abstract

The present disclosure provides a system-on-a-chip based bus bandwidth allocation method, device and related equipment, the method comprising: in response to the received bandwidth scheduling instruction, determining the system running scene information corresponding to the bandwidth scheduling instruction, and a plurality of running state dimensions corresponding to the system running scene information; for any functional module, obtaining a plurality of running state data corresponding to the functional module; determining a plurality of scene adjustment factors corresponding to the system running scene information; for any functional module, adjusting the operation of the plurality of running state data corresponding to the functional module through the scene adjustment factor corresponding to the functional module, determining the allocation priority of the functional module according to the operation result, and allocating the bus bandwidth to the plurality of functional modules. The method is based on the dynamic priority mechanism of multi-dimensional state and scene adjustment factor, which ensures that high demand tasks can obtain sufficient bandwidth in time.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a bus bandwidth allocation method, apparatus and related equipment based on a system-on-a-chip. Background Technology

[0002] System-on-a-Chip (SoC) technology integrates multiple functional modules, such as the Central Processing Unit (CPU), Graphics Processing Unit (GPU), and Neural Processing Unit (NPU), onto a single chip. These modules need to access shared resources, such as memory, through a shared internal bus, which leads to competition for bus bandwidth.

[0003] In related technologies, bus arbitration strategies mostly employ fixed-priority arbitration or polling arbitration. These methods typically use static or semi-static arbitration strategies, which have drawbacks such as poor flexibility and inability to adapt to complex scenarios. Summary of the Invention

[0004] This disclosure provides a bus bandwidth allocation method, apparatus, and related equipment based on a system-on-a-chip.

[0005] In a first aspect, this disclosure provides a bus bandwidth allocation method based on a system-on-a-chip, wherein the system-on-a-chip includes multiple functional modules, and the method includes:

[0006] In response to a received bandwidth scheduling instruction, determine the system operation scenario information corresponding to the bandwidth scheduling instruction and multiple operation state dimensions corresponding to the system operation scenario information; for any functional module, obtain the operation state data of the functional module under each operation state dimension;

[0007] Multiple scene adjustment factors corresponding to the system operation scene information are determined, and the multiple scene adjustment factors correspond to the multiple functional modules; for any functional module, the multiple operation status data corresponding to the functional module are adjusted by the scene adjustment factor corresponding to the functional module, and the allocation priority of the functional module is determined according to the calculation result;

[0008] Bus bandwidth is allocated to the multiple functional modules according to their allocation priority.

[0009] Secondly, this disclosure provides a bus bandwidth allocation device based on a system-on-a-chip, wherein the system-on-a-chip includes multiple functional modules, and the device includes:

[0010] The response module is adapted to respond to a received bandwidth scheduling instruction, determine system operation scenario information corresponding to the bandwidth scheduling instruction, and multiple operation state dimensions corresponding to the system operation scenario information; and for any functional module, obtain the operation state data of the functional module under each operation state dimension.

[0011] The calculation module is adapted to determine multiple scene adjustment factors corresponding to the system operation scene information, the multiple scene adjustment factors corresponding to the multiple functional modules; for any functional module, the module performs adjustment calculations on multiple operation state data corresponding to the functional module through the scene adjustment factors corresponding to the functional module, and determines the allocation priority of the functional module based on the calculation results.

[0012] The allocation module is adapted to allocate bus bandwidth to the plurality of functional modules according to the allocation priority of the plurality of functional modules.

[0013] Thirdly, this disclosure provides a chip including programmable logic circuitry and / or program instructions, which, when executed, are used to implement the methods described above.

[0014] Fourthly, this disclosure provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores one or more computer programs executable by the at least one processor, the one or more computer programs being executed by the at least one processor to enable the at least one processor to perform the above-described system-on-a-chip-based bus bandwidth allocation method.

[0015] Fifthly, this disclosure provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the above-described system-on-a-chip bus bandwidth allocation method.

[0016] In a sixth aspect, this disclosure provides a computer program product comprising computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code, wherein when the computer-readable code is run in a processor of an electronic device, the processor in the electronic device executes the above-described system-on-a-chip-based bus bandwidth allocation method.

[0017] The embodiments provided in this disclosure, by introducing dynamic scene awareness and multi-dimensional state adjustment mechanisms, offer at least the following significant advantages compared to traditional static bandwidth allocation schemes: By responding to bandwidth scheduling commands, the system's operating scenarios are dynamically identified, and the corresponding operating state dimensions are determined, ensuring that the bandwidth allocation strategy is highly matched with the current actual scenario requirements. This avoids the problems of resource idleness or insufficient contention in traditional fixed bandwidth allocation, thereby significantly improving the utilization rate of bus bandwidth. Furthermore, it enables comprehensive evaluation of multiple operating state data for each functional module and introduces scene adjustment factors for differentiated adjustment calculations, ultimately generating refined allocation priorities. Therefore, the dynamic priority mechanism based on multi-dimensional state and scene adjustment factors ensures that high-demand tasks can obtain sufficient bandwidth in a timely manner, effectively reducing processing latency and improving overall system throughput and response performance, thus achieving intelligent adaptive resource allocation.

[0018] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0019] The accompanying drawings are provided to further illustrate the present disclosure and form part of the specification. They are used together with the embodiments of the present disclosure to explain the disclosure and do not constitute a limitation thereof. The above and other features and advantages will become more apparent to those skilled in the art from the detailed description of exemplary embodiments with reference to the accompanying drawings, in which:

[0020] Figure 1 A flowchart illustrating a bus bandwidth allocation method based on a system-on-a-chip provided in this disclosure embodiment;

[0021] Figure 2 This is a flowchart illustrating a system-on-a-chip (SoC)-based bus bandwidth allocation method as an example of this disclosure.

[0022] Figure 3 A block diagram of a system-on-a-chip (SoC)-based bus bandwidth allocation device provided in this disclosure embodiment;

[0023] Figure 4 This is a block diagram of an electronic device provided in an embodiment of the present disclosure. Detailed Implementation

[0024] To enable those skilled in the art to better understand the technical solutions of this disclosure, exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments of this disclosure to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0025] Where there is no conflict, the various embodiments of this disclosure and the features thereof in the embodiments may be combined with each other.

[0026] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0027] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Words such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0028] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this disclosure, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined herein.

[0029] According to the bus bandwidth allocation method based on the system-on-a-chip according to the embodiments of this disclosure, the execution subject can be a terminal device or computing platform integrating a system-on-a-chip. These devices include, but are not limited to: mobile smart terminals, such as smartphones, tablets, wearable devices, etc.; embedded systems, such as industrial controllers, IoT nodes, network routers, digital TVs, etc.; high-performance computing platforms, such as autonomous driving domain controllers, smart cockpits, servers, data center acceleration cards, etc. The bus bandwidth allocation method can be implemented in the following two main ways: (1) Hardware logic implementation: It is integrated into the SoC as a dedicated hardware circuit (such as a bus arbiter, part of a DMA controller), designed through a hardware description language, and finally synthesized into a physical circuit on the chip. All its decision-making and scheduling processes are completed in real time by the hardware logic, which has the characteristics of extremely low latency and extremely high determinism. (2) Software and hardware co-implementation: Some functions (such as policy management, status monitoring) are implemented by drivers or firmware running on the processor (such as ARM Cortex-A series cores) inside the SoC. The software controls the behavior of the hardware arbiter by reading and writing dedicated configuration registers in the SoC. This method combines the flexibility of software and the efficiency of hardware. Regardless of the implementation method, the core goal is to improve the overall performance, energy efficiency, and real-time performance of the SoC through intelligent allocation of on-chip bus resources.

[0030] Figure 1 A flowchart illustrating a bus bandwidth allocation method based on a system-on-a-chip (SoC) provided in this disclosure embodiment. (Refer to...) Figure 1 The method includes:

[0031] Step S110: In response to the received bandwidth scheduling instruction, determine the system operation scenario information corresponding to the bandwidth scheduling instruction and multiple operation status dimensions corresponding to the system operation scenario information; for any functional module, obtain the operation status data of the functional module under each operation status dimension.

[0032] This step drives scene recognition through bandwidth scheduling commands: the system receives bandwidth scheduling commands generated externally or internally, and determines the current macro-level operating scenario (such as high-performance computing, low-power mode, real-time audio and video processing, etc.). Correspondingly, it can dynamically determine the set of key operating state dimensions (such as load, waiting time, real-time requirements, etc.) based on the core requirements of different scenarios, making data collection more targeted. The functional module refers to a hardware IP core or processing unit integrated into the system-on-a-chip that can initiate bus access requests as a master device, such as a central processing unit, graphics processing unit, neural network processing unit, digital signal processor, image signal processor, video codec, display controller, etc.

[0033] Among them, bandwidth scheduling instructions refer to signals or commands that trigger the system to start or update the bandwidth allocation process. These instructions can originate from various sources: they can be triggered when a change in the system's operating environment is detected, or they can be triggered periodically. For example, they can be triggered by the operating system scheduler based on changes in task priority; triggered by user applications actively requesting through specific API calls (such as a game engine starting high-performance mode); or triggered by the hardware monitoring unit when it detects specific events (such as temperature exceeding a threshold or low battery).

[0034] System operation scenario information refers to various information related to the scenario during the operation of the system-on-a-chip (SoC), specifically including information related to the application scenario (such as the type of application being run) and the system scenario (such as system power consumption and system performance). Therefore, system operation scenario information is used to characterize the overall operating status, operating goals, and / or system environment of the SoC. Specifically, through system operation scenario information, priority goals or constraints that the system needs to prioritize or adhere to within a specific time period can be defined. For example: high-performance computing scenarios require priority to throughput and are latency-sensitive; low-power energy-saving scenarios require priority to energy efficiency and limit peak power consumption; real-time audio and video processing scenarios require priority to latency stability and bandwidth determinism; and thermal throttling scenarios require priority to temperature safety and appropriate frequency reduction.

[0035] Operational state dimensions refer to metrics used to quantify the current working state and resource requirements of a functional module. Each operational state dimension aims to reflect the characteristics of the functional module from a specific perspective. For example, multiple operational state dimensions may include: task load, latency, real-time requirements, and energy efficiency factor. Task load characterizes the amount of data or computational tasks that the module needs to process per unit of time, typically measured by request queue depth or throughput. Latency characterizes the number of clock cycles the functional module has waited since it was last granted bus access, used to assess the urgency of its access requests. Real-time requirements can be characterized by a flag or priority parameter, indicating whether the module's tasks have strict deadlines (such as audio output or display refresh); timeouts will lead to functional failures or a degraded user experience. Energy efficiency factor characterizes the amount of computation the functional module can perform per unit of power consumption, used to prioritize scheduling modules with higher energy efficiency in energy-saving scenarios. Furthermore, different initial scores can be configured for each of the above operational state dimensions based on their importance, so as to determine the degree of influence of each operational state dimension in the final bandwidth allocation. Correspondingly, runtime status data refers to the specific values ​​of the aforementioned runtime status dimensions at a specific functional module and at a specific time. For example, the GPU's load dimension data might be the number of unprocessed frames in its rendering queue, while the NPU's wait time dimension data might be the number of cycles in which its Direct Memory Access (DMA) requests are queued in the arbitrator.

[0036] In practical implementation, system operating scenario information can be determined in several ways. For example, the system can pre-define an event scenario mapping table. When a bandwidth scheduling command arrives, the event code or source in the command is parsed, and the corresponding scenario information is obtained by looking up the table. This method is simple to implement, fast in decision-making, and has low overhead, making it suitable for systems with high real-time requirements. Alternatively, the system can run a lightweight machine learning model (such as a decision tree or a small neural network). This model uses historical performance counters and power consumption readings over a period of time as input to infer the most appropriate system scenario to enter. This method can better adapt to complex and variable workloads and achieve more refined scenario recognition.

[0037] In addition, multiple operating status data corresponding to functional modules can be obtained through various methods such as register polling, interrupt triggering, and dedicated monitoring units. This disclosure does not limit the specific methods.

[0038] Step S120: Determine multiple scenario adjustment factors corresponding to the system operation scenario information. These multiple scenario adjustment factors correspond to multiple functional modules. For any functional module, adjust multiple operating status data corresponding to the functional module using the scenario adjustment factors corresponding to the functional module. Determine the allocation priority of the functional module based on the calculation results.

[0039] The scene adjustment factor is used to adjust the importance of multiple runtime status data based on the characteristics of the current system runtime scenario information. Therefore, the scene adjustment factor can be a set of coefficients or parameters bound to the system runtime scenario information to adjust the weight of runtime status data. It directly reflects the optimization direction emphasized by the system in that scenario (e.g., prioritizing low latency, high throughput, or low power consumption). For example, in a game scenario, considering that the main requirement is smooth rendering, the weights corresponding to real-time requirements and task load in the scene adjustment factor corresponding to the GPU module can be appropriately increased to ensure real-time rendering. Additionally, for modules that implement background data synchronization, the weights of all dimensions may be reduced to avoid interfering with critical tasks. The adjustment operation refers to the process of combining multiple runtime status data of a functional module with its corresponding scene adjustment factor, calculating, and finally outputting a comprehensive score representing its current priority. Priority allocation is used to represent the priority order of each functional module when accessing the bus, specifically through a summed score of the functional modules.

[0040] Step S130: Allocate bus bandwidth to multiple functional modules according to their allocation priority.

[0041] Among them, the allocation order and / or allocation quantity when allocating bus bandwidth to multiple functional modules can be determined according to the allocation priority of multiple functional modules.

[0042] Therefore, in this embodiment, by responding to bandwidth scheduling commands, the system dynamically identifies the operating scenario and determines the corresponding operating state dimension, ensuring that the bandwidth allocation strategy is highly matched with the current actual scenario requirements. This avoids the problems of resource idleness or insufficient competition in traditional fixed bandwidth allocation, thereby significantly improving the utilization rate of bus bandwidth. Furthermore, it can comprehensively evaluate multiple operating state data for each functional module and introduce scenario adjustment factors for differentiated adjustment calculations, ultimately generating a refined allocation priority. Thus, the dynamic priority mechanism based on multi-dimensional states and scenario adjustment factors ensures that high-demand tasks can obtain sufficient bandwidth in a timely manner, effectively reducing processing latency and improving overall system throughput and response performance, thereby achieving intelligent adaptive resource allocation. The introduction of scenario adjustment factors allows the system to flexibly adjust the focus of the scheduling algorithm according to the core requirements of different scenarios (such as low latency in game scenarios and high bandwidth in video rendering), realizing the customization and optimization of resource allocation strategies.

[0043] Furthermore, those skilled in the art can make various modifications and variations to the embodiments disclosed herein:

[0044] In complex on-chip systems, multiple functional modules share limited bus bandwidth resources. Traditional bandwidth scheduling schemes are mostly statically configured or triggered at fixed intervals, which cannot effectively perceive macroscopic changes in the system's operating scenario and have at least the following problems: First, there may be response lag issues. For example, when user operations cause a significant switch in the application scenario (such as switching from standby to gaming), static strategies cannot be adjusted in time, resulting in the performance of critical tasks in the new scenario failing to meet standards (such as game lag). Second, there may be resource and power consumption waste issues. For example, fixed-period or frequently triggered scheduling strategies will perform a large amount of meaningless repetitive calculations and configurations when the system scenario is stable, generating unnecessary scheduling overhead and increasing power consumption. Third, there may be issues that interfere with system stability. For example, frequent and unnecessary scheduling operations may interfere with ongoing real-time tasks, introducing unpredictable latency and jitter. To address the aforementioned issues and optimize the frequency and timing of bandwidth scheduling, the following steps can be performed before responding to a received bandwidth scheduling command: When the system's operating scenario changes, determine if the difference between the changed and original operating scenarios meets preset scheduling conditions; if the preset conditions are met, trigger the bandwidth scheduling command. In this approach, the system can automatically detect changes in its operating scenario (e.g., switching from a game scenario to a video conferencing scenario), rather than passively waiting for external commands or periodic queries. Furthermore, it enables on-demand triggering, avoiding unnecessary computational resource consumption: in reality, not all scenario changes require immediate bandwidth reallocation. Correspondingly, by calculating the scenario difference, the system can intelligently determine whether the change necessitates triggering subsequent complex bandwidth calculation and allocation processes, effectively preventing frequent scheduler triggers due to minor, insignificant scenario fluctuations. This significantly reduces computational and communication overhead, improving system energy efficiency and stability.

[0045] In this context, a change in system operating scenario typically refers to a switch in the overall task objective and / or external environment state of the on-chip system. This change can be triggered by high-level software (such as the operating system scheduler or power management framework) or specific hardware events (such as temperature sensor alarms or user key presses). For example, a change in system operating scenario might include: a user switching from browsing the web to launching a large game; the device's battery level dropping below a preset value and entering low-power mode; the front-facing camera being activated, preparing for a video call; or the chip temperature exceeding a preset temperature, triggering a temperature control strategy. Scenario difference is used to quantitatively assess the degree of difference between two system operating scenarios. It can be a single-dimensional scalar value (e.g., between 0 and 1) or a multi-dimensional vector, typically calculated based on changes in the core parameters of the resource scheduling strategy under the two operating scenarios. For example, scenario difference can be determined based on factors such as the type of scenario and the minimum guaranteed bandwidth configuration of each functional module. Preset scheduling conditions can be thresholds or rules for determining whether bandwidth rescheduling needs to be triggered. For example, different scenario scores can be pre-configured for different system operating scenarios; if the difference in scores before and after the change exceeds a preset threshold, the preset scheduling condition is considered met. For example, preset scheduling conditions can also be characterized through key dimensions. For instance, if the guaranteed bandwidth change of a core functional module exceeds a preset threshold, the preset scheduling conditions are determined to be met. This approach, by introducing scene change awareness and condition triggering mechanisms, can promptly capture critical scene switching events affecting performance and automatically trigger bandwidth reallocation. This ensures that critical tasks in the new scene (such as games and video calls) immediately obtain the necessary resources, guaranteeing smooth operation. By using an on-demand triggering method, unnecessary scheduling calculations and bus configuration operations during scene stability periods are greatly reduced, significantly lowering the system's dynamic power consumption and computational overhead. Furthermore, it avoids unnecessary scheduling interference caused by slight scene fluctuations or fixed cycles, resulting in higher determinism and less jitter during stable system operation.

[0046] In one optional implementation, the system operation scenario can include: task-class scenarios representing system operation tasks; correspondingly, the scenario difference can be characterized by the dependency relationships between the system operation tasks and multiple functional modules; wherein, the dependency relationship is used to characterize: the degree of dependence on multiple functional modules during the operation of the system operation task. Furthermore, it can be determined whether the scenario difference between the changed system operation scenario and the original system operation scenario meets the preset scheduling conditions by: determining the first dependency relationship between the changed system operation task and multiple functional modules, and the second dependency relationship between the original system operation task and multiple functional modules; based on the change in the first dependency relationship relative to the second dependency relationship, determining whether the scenario difference between the changed system operation scenario and the original system operation scenario meets the preset scheduling conditions. In the above approach, the actual degree of dependence on each functional module during the execution of a specific task can be quantitatively analyzed, thereby making the judgment of scenario difference more accurate.

[0047] The performance impact of task switching fundamentally stems from the change in required hardware resources. Accordingly, by comparing the changes in the dependencies of functional modules such as GPU, NPU, and CPU before and after a task, a decision is made regarding whether bandwidth needs to be reallocated. The bandwidth reallocation process is only triggered when the hardware resource requirements (dependencies) of the new task differ significantly from those of the old task. This avoids unnecessary scheduling overhead caused by minor task fluctuations or switching between similar tasks, achieving precise on-demand response.

[0048] System operation tasks can be represented by specific computing tasks or application units that are being executed or about to be executed on the on-chip system, and are typically managed by the operating system scheduler. For example, a game scene may consist of multiple sub-tasks such as 3D graphics rendering tasks, physics engine calculation tasks, and AI opponent behavior decision-making tasks. A video conferencing scene may consist of camera data acquisition tasks, video encoding tasks, audio noise reduction tasks, and network transmission tasks.

[0049] Dependency relationships are used to characterize the strength and / or pattern of a system task's dependence on the computational power, data throughput, or access latency of different functional modules during execution. It can be a multi-dimensional vector, with each dimension corresponding to the dependency value of the current system task on a functional module. The magnitude of the dependency value is usually used to characterize the strength of the system task's dependence on the computational power, data throughput, or access latency of the functional module during execution.

[0050] Dependency can be represented by dependency vectors. Dependency vectors can include static dependency vectors and / or dynamic dependency vectors. Static dependency vectors represent dependencies determined during task initialization or compilation. For example, a known image processing algorithm task's code dictates frequent calls to the NPU and the Double Data Rate (DDR) controller. Dynamic dependency vectors represent dependencies determined in real-time during task execution. For instance, data such as the number of accesses to various functional modules, bandwidth requests, and cache size used by the task per unit time can be collected by the Power Management Unit (PMU), and after normalization, a dynamic dependency vector is obtained for application in the next scheduling process. Correspondingly, in this approach, scenario difference can be calculated based on dependency vectors to measure the similarity of hardware resource patterns relied upon by two system task executions. A greater difference indicates a more drastic change in hardware resource requirements due to task switching, necessitating bandwidth reallocation.

[0051] In specific implementation, scene difference can be determined using at least one of the following methods: First, scene difference can be determined based on vector distance: calculate the similarity between the first dependency vector corresponding to the first dependency relationship and the second dependency vector corresponding to the second dependency relationship, and compare the similarity calculation result with a preset similarity threshold. Based on the comparison result, determine whether the scene difference meets the preset scheduling conditions. Second, scene difference can be determined based on changes in key modules: for example, focus on whether the change in the dependency value of at least one preset key module (i.e., a functional module with high importance) is greater than a preset variable threshold. For example, for image-related tasks, the scene difference can be determined based on the change in the GPU's dependency value to determine whether the scene difference meets the preset scheduling conditions. Alternatively, information such as the dependency vectors of the old and new tasks and the current system load status can be input into a lightweight machine learning model, which outputs a probability or score to characterize whether scheduling needs to be triggered.

[0052] For example, in a specific instance, suppose the system task switches from an image-based task to a video-based task. Accordingly, based on the changes in the dependencies between the system task and multiple functional modules before and after the switch, it is determined whether the difference between the changed system scenario and the original system scenario meets the preset scheduling conditions. Specifically, the original system scenario was an image browsing scenario, with corresponding high-resolution image decoding and rendering tasks. The changed system scenario is a video playback scenario, with corresponding high-definition video stream decoding and audio synchronization tasks.

[0053] Dependencies are used to quantify the degree of dependence on various functional modules during task execution. In this example, it is quantified into a dependency value, ranging from 0 to 10 (the higher the value, the stronger the dependency).

[0054] First, determine the secondary dependencies between the system's runtime tasks and multiple functional modules before the change: For the high-resolution image decoding and rendering task, its secondary dependencies with multiple functional modules can be determined through performance analysis or predefined configurations: Assuming a GPU dependency of 7, this task requires the GPU for image decoding and scaling rendering, resulting in a high but not continuous load; a VPU dependency of 2, as static image processing typically does not involve the VPU's hardware decoding capabilities, resulting in a low dependency; an NPU dependency of 1, as there is almost no NPU dependency unless AI super-resolution or other enhancements are used; and a DDR controller dependency of 6, as loading images requires a burst of large amounts of data. Then, determine the primary dependencies between the system's runtime tasks and multiple functional modules after the change:

[0055] For the task of decoding high-definition video streams and synchronizing audio, the first dependency relationship is assumed to be as follows: the dependency on the GPU is 8, if the video format requires the GPU to participate in decoding or post-processing, the load is continuous and high; the dependency on the VPU is 9, the VPU is the hardware decoding core, which bears the main computing load, and the dependency is extremely high; the dependency on the NPU is 3, which may be used for video super-resolution or image quality enhancement, the dependency is increased but still secondary; the dependency on the DDR controller is 8, which requires continuous and stable reading and writing of video stream data, with large bandwidth requirements and stable operation.

[0056] Next, analyze the changes in dependencies and determine the degree of difference in scenarios: In specific implementation, the absolute change in the dependency value of each module can be calculated separately: GPU: 8-7=1; VPU: 9-2=7 (key change); NPU: 3-1=2; DDR controller: 8-6=2.

[0057] Finally, determine if the preset scheduling conditions are met: Assume the preset scheduling conditions are: at least one functional module has a dependency value change ≥ 5, or the total dependency value change of all modules ≥ 10. The final result is: the VPU's dependency value change 7 > 5, satisfying the first condition. The total change = 1 + 7 + 2 + 2 = 12 > 10, also satisfying the second condition.

[0058] Therefore, the scenario difference in this change meets the preset scheduling conditions. Accordingly, a scheduling command and bandwidth reallocation are triggered. Because the scenario difference meets the conditions, the system will automatically trigger a bandwidth scheduling command. The bus arbiter or resource manager will reallocate bandwidth based on the new dependencies (first dependency).

[0059] Optionally, the system operation tasks described above include at least one of the following: image-related tasks, video-related tasks, and inference tasks; the multiple functional modules include at least one of the following: image processing units (such as GPU, ISP), video processing units (such as VPU), and neural network processing units (NPU); wherein, image-related tasks depend more on image processing units than on video processing units and neural network processing units; video-related tasks depend more on video processing units than on image processing units and neural network processing units; and inference tasks depend more on neural network processing units than on image processing units and video processing units. Image-related tasks refer to tasks that primarily process and compute static images or image sequences, with the core objective of enhancing image quality, extracting image features, or performing image analysis. Examples include: photo shooting and enhancement in camera applications, image recognition (such as QR code scanning, object recognition), and panoramic image stitching. Video-related tasks refer to tasks that primarily encode, decode, process, or analyze continuous video streams. Their core characteristics are large data volumes, high real-time requirements, and the need to ensure smooth playback. Examples include video recording and playback, video conferencing (real-time video encoding and transmission), video editing, and special effects rendering. Inference tasks refer to tasks that primarily utilize pre-trained neural network models to intelligently analyze, recognize, or generate data from input data (such as images, videos, and audio). Their core operations involve numerous matrix multiplication and addition calculations. Examples include facial recognition unlocking, voice recognition in voice assistants, intelligent album categorization in photo libraries, and real-time pose estimation in AR applications. Image processing units generally refer to hardware modules responsible for image processing and graphics rendering, typically including GPUs and ISPs. Video processing units refer to hardware modules focused on video encoding and decoding, typically including VPUs. Neural network processing units refer to hardware accelerators designed for neural network computations, typically including NPUs. Dependency measures the intensity of a task's demand on the computational power and bandwidth resources of a particular functional module for successful execution. High dependency means that this task is the main source of workload for this functional module. The performance of this module directly determines the speed, quality, and energy efficiency of the task's execution. If the module's bandwidth or computing resources are insufficient, the task will be directly affected. Low dependency means that the task does not primarily use this module, or the performance of this module does not directly determine the core experience of the task.

[0060] In another optional implementation, the aforementioned system operation scenario may further include: a state-class scenario for characterizing the system's operating state; and the scenario difference is characterized by the correlation between the priority of bus bandwidth requirements of multiple functional modules and the system operating state. Accordingly, when determining whether the scenario difference between the changed system operation scenario and the system operation scenario before the change meets the preset scheduling conditions, this can be achieved by: determining the first correlation between the changed system operating state and multiple functional modules, and the second correlation between the system operating state before the change and multiple functional modules; and determining whether the scenario difference between the changed system operation scenario and the system operation scenario before the change meets the preset scheduling conditions based on the change in the first correlation relative to the second correlation.

[0061] The system operating status primarily refers to the on-chip system's own physical conditions, resource status, and external environmental constraints, which are typically detected and defined by sensors, monitoring units, or management software. For example, it may include power consumption status, thermal status, performance status, and external instruction status. Demand priority refers to the priority level of a functional module's access request when it accesses the shared bus, as the arbitrator processes it. Higher-priority requests obtain bus bandwidth resources faster, thus ensuring the performance of the corresponding function. Association refers to the mapping and binding relationship between the system operating status and the demand priorities of each functional module. For example, in game mode, the GPU and CPU demand priorities are set to the highest; while in video playback mode, the display controller and video decoder demand priorities are the highest. Specifically, association can be represented by predefined or dynamically generated mapping rules, which clarify the relative priority level of each functional module's bus bandwidth demand when the system is in a specific operating state. This can be represented by a priority list or weight vector. Correspondingly, preset scheduling conditions can be represented by a pre-set threshold or rule to determine whether the calculated scene difference is large enough to require the reallocation (i.e., scheduling) of bus bandwidth resources. For example, the change in the relationship could exceed a certain percentage, or the priority of a specific key module could be reversed.

[0062] Therefore, unlike task-based scenarios mentioned above that focus on the specific work performed by the system (such as games and video conferencing), state-based scenarios focus on the system's physical and environmental states (such as low power, high temperature, and high-performance modes), thereby achieving a deep understanding of the system's operating environment. In this approach, a priority remapping mechanism is employed to redefine the mapping rules for the priority of bandwidth acquisition by each functional module under different system operating states. For example, in a low-power state, energy saving is the primary goal; therefore, modules with high energy efficiency have increased priority, while high-performance but high-power modules have decreased priority. By sensing and responding to changes in system state, it can proactively prevent performance drops or system crashes caused by overheating and frequency throttling, or power depletion, while fully releasing performance when resources are sufficient, achieving intelligent and adaptive resource management. In summary, by establishing a dynamic correlation between system operating state and module bandwidth priority, it provides important constraints and optimization directions for bandwidth scheduling, ensuring that the system remains efficient and stable under various operating environments.

[0063] For example, let's illustrate this with a scenario where the system switches from normal performance mode to low power mode. Before the change, the system is in normal performance mode (e.g., the device battery is above 50% and not under extreme temperature conditions). After the change, the system is in low power mode (e.g., the device battery is below 20%, and the system actively enters power-saving mode to extend battery life). This relationship can be represented as a mapping rule that clearly defines the priority of bus bandwidth requirements for each functional module under specific system operating conditions. For ease of explanation, this priority can be quantified into three levels: high, medium, and low.

[0064] First, determine the second relationship between the system's operating state before the change and multiple functional modules: In this state, the system's optimization goal is to pursue ultimate performance and a smooth experience. Therefore, the priority mapping rules for each functional module are as follows: GPU (Graphics Processing Unit) is high priority to ensure smooth high frame rate operation for games, UI animations, etc.; CPU (Central Processing Unit) is high priority to ensure application response speed and task processing speed. NPU (Neural Processing Unit) is medium priority to support AI functions, but is not a core experience component.

[0065] Then, the first correlation between the changed system operating state and the multiple functional modules is determined: in this state, the core objective of the system becomes maximizing battery life. Therefore, the correlation is remapped, and the new rule is to prioritize basic interactive functions and limit high-power modules: the GPU (Graphics Processing Unit) is low priority, and its bandwidth is limited to reduce power consumption, which may lead to a decrease in game frame rate or simplification of UI animations; the CPU (Central Processing Unit) is medium priority, ensuring core functions such as basic interaction and calls, but its peak performance may be limited; the NPU (Neural Processing Unit) is low priority, and unnecessary AI functions are turned off or significantly limited to save power; the audio codec is high priority, ensuring that basic and critical functions such as calls and audio playback are not affected.

[0066] Next, we analyze the changes in the correlation and determine the degree of difference in the scenarios: the GPU priority changed from high to low, which is a fundamental and directional reversal; the CPU priority changed from high to medium, which is a significant decrease; the NPU priority changed from medium to low, which is a decrease; and the audio codec priority was added as high.

[0067] The preset scheduling condition is: the priority of core modules undergoes at least two level reversals, or the priority of more than half of the modules changes. In this example, the GPU's priority underwent two level reversals from high to low, thus satisfying the condition. Furthermore, the priorities of both the CPU and NPU changed, meaning the priority of more than half of the modules was adjusted. Therefore, the changes in the relationships caused by this state change are significant, and the calculated scene difference meets the preset scheduling condition.

[0068] In one alternative implementation, to avoid bandwidth scheduling lag, the aforementioned system operation scenarios can be predicted using a pre-trained scenario prediction model. This model is trained based on changes in system operation scenarios over historical periods. Through this model, the system can analyze historical operational data and anticipate potential scenario transitions (e.g., a user switching from browsing a webpage to launching a game), allowing for pre-configuration of bandwidth resources before the actual scenario change, thus improving system responsiveness and smoothness. The scenario prediction model can be a software module built on machine learning or deep learning algorithms. Its core function is to analyze the temporal changes in system operation scenarios and predict the most likely scenario in the near future. It is typically deployed in the operating system kernel or a dedicated processor. The model's training data can come from system operation logs recorded over historical periods. These logs contain a large number of time-varying scenario label sequences (e.g., [browsing, music, game, game]). [ ]) and corresponding system load, user operation and other context information.

[0069] In another alternative implementation, the system operating scenario can be determined by received control commands. These control commands, used to change the system operating scenario, specifically include system control commands and / or user control commands. By receiving control commands from the operating system or the user, the system can directly and explicitly respond to high-level strategies or user intentions (such as manually activating game mode), thereby providing the system with stronger certainty and control, and ensuring the reliable execution of critical commands.

[0070] The two mechanisms described above can be used individually or in combination, together forming an intelligent and reliable scene perception system. For example, predictive models are used to handle predictable, regular changes, while control commands are used to handle sudden or strategically demanding intervention needs.

[0071] Furthermore, in complex on-chip systems, multiple functional modules share limited bus bandwidth resources. Relying solely on single-dimensional state information (such as simple fixed priority or polling) cannot comprehensively and accurately reflect the real-time requirements of modules and the system's optimization goals. To improve the reliability of scheduling algorithms, in one optional implementation, multiple operational state dimensions can include at least two of the following: the task load of the functional module, the waiting time of the functional module, and the time-sensitive priority and / or scenario priority determined based on system operational scenario information. Among these attributes, task load and waiting time are dynamically changing real-time measurements that reflect the current working state of the module; while time-sensitive priority and scenario priority are typically static presets or semi-static policy attributes that reflect the system's optimization goals and external constraints. A scheduling strategy combining dynamic and static attributes can improve response speed and reliability.

[0072] The workload of a functional module refers to the amount of data it needs to process or the amount of computation it needs to complete per unit of time. It is a core indicator for quantifying the module's busyness or throughput requirements. For example, for I / O-intensive modules such as DMA controllers and network interfaces, the workload can be characterized by the depth of their request queues or the number of transmission requests initiated per unit of time. For compute-intensive modules such as GPUs and NPUs, the workload can be characterized by the utilization rate of their computing units or the number of unprocessed frames / tasks in the processing queue. For CPUs, the workload can be characterized by the length of their run queues. The waiting time of a functional module refers to the time elapsed since the module was last granted bus access until the current moment. It is a key indicator for quantifying fairness and can be implemented using a hardware counter. Timeliness priority can be an identifier or parameter related to the functional module's own attributes, used to identify its real-time requirements. It defines the urgency of the data traffic generated by the module. Specifically, it can be characterized by values ​​pre-configured in registers. For example, the display controller is assigned the highest timeliness priority because frame data must arrive before the next refresh cycle; the background disk backup module is assigned the lowest timeliness priority. Scene priority can be a strategy parameter or priority adjustment factor that is tied to the system's operating scene and used to dynamically adjust the priority of functional modules. It reflects the different emphases the system places on different modules under different scenarios. For example, in game mode, the scene priority of the GPU is increased; in video conferencing mode, the scene priority of the ISP and NPU is increased.

[0073] In the above approach, by introducing a multi-dimensional operational status system, the scheduler can be provided with more comprehensive and three-dimensional decision-making information, enabling it to more accurately determine the real-time needs and urgency of each module, thereby making better bandwidth allocation decisions. The introduction of scenario priority allows the system to dynamically adjust its optimization direction, flexibly adapting to the changing needs of different application scenarios, significantly improving user experience and system energy efficiency. The waiting time dimension effectively prevents low-priority modules from being "starved" for extended periods, while the timeliness priority dimension ensures that latency-sensitive critical tasks always receive timely responses, thus guaranteeing fairness and real-time performance. Optionally, an energy efficiency dimension can also be introduced. For example, the current energy efficiency (performance per unit power consumption) of a functional module can be used as a status dimension. In thermally constrained or low-power scenarios, the scheduler can prioritize allocating bandwidth to modules with higher energy efficiency, thereby extending battery life or controlling heat generation.

[0074] Furthermore, to ensure the stable operation of the system's basic functions and prevent any module from failing due to contention failure, thereby enhancing the system's robustness and reliability, bandwidth allocation can be based on guaranteed bandwidth in this embodiment. Specifically, when allocating bus bandwidth to functional modules according to allocation priority, firstly, the remaining available bandwidth is determined based on multiple scenario guaranteed bandwidths corresponding to the system's operating scenario information. These multiple scenario guaranteed bandwidths characterize the minimum bandwidth required for multiple functional modules under the system's operating scenario, and the remaining available bandwidth is the bandwidth remaining after allocating the corresponding scenario guaranteed bandwidths to multiple functional modules. Then, based on the functional module's allocation priority, the module-available bandwidth corresponding to the functional module is determined from the remaining available bandwidth. Accordingly, for any functional module, bus bandwidth is allocated to that functional module based on the sum of its corresponding scenario guaranteed bandwidth and its corresponding module-available bandwidth.

[0075] The scenario-guaranteed bandwidth is the minimum bandwidth value pre-configured or dynamically calculated for each functional module. It represents the minimum bandwidth necessary for the module to maintain its basic functions and avoid functional failures or severe performance degradation under the system's operating scenario. The remaining available bandwidth is a calculated instantaneous value, representing the bandwidth resource pool remaining after deducting the sum of the guaranteed bandwidths of all functional modules from the total system bandwidth, which can be dynamically allocated through contention. This approach, leveraging guaranteed bandwidth, balances fairness and efficiency: scenario-guaranteed bandwidth ensures that each functional module receives bandwidth resources sufficient to meet its most basic functional requirements, preventing any module from experiencing functional abnormalities due to resource contention failure, thus reflecting fairness. Module-available bandwidth allows modules to compete for additional resources based on their real-time needs and priorities, maximizing resource utilization, thus reflecting efficiency. This mechanism physically or logically separates the guaranteed resource pool and the contention resource pool. The guaranteed resource pool is isolated and does not interfere with each other; the contention resource pool is shared on demand, thereby ensuring the stability of critical services while improving overall resource utilization efficiency. Furthermore, both the guaranteed bandwidth and the contention strategy can be dynamically adjusted according to changes in the system's operating scenario. For example, in low-power scenarios, the guaranteed bandwidth for all modules may be reduced, while the competition strategy will favor rewarding low-power modules, thereby achieving system-level energy efficiency optimization. In summary, by dividing the total bandwidth into guaranteed and competitive portions, a balance can be struck between the determinism (guaranteeing basic needs) and flexibility (competition on demand) of bandwidth allocation, thus achieving refined and intelligent resource management.

[0076] Furthermore, when making scheduling decisions by comprehensively considering multiple operational status dimensions (such as load, waiting time, and real-time performance) of functional modules, various problems may arise, such as inconsistent dimensions and conflicting optimization objectives. To address these issues and improve the accuracy of scheduling decisions, the scenario adjustment factors corresponding to the aforementioned functional modules can include multiple weight adjustment factors corresponding to multiple operational status dimensions. Accordingly, when adjusting the multiple operational status data corresponding to a functional module using the scenario adjustment factors, and determining the allocation priority of the functional module based on the calculation results, the multiple operational status data corresponding to the functional module can be weighted according to the multiple weight adjustment factors to obtain the module score, which represents the allocation priority of the functional module.

[0077] The weighting adjustment factor can be a coefficient bound to a specific operational state dimension, used to amplify or reduce the importance of that dimension's data in the overall score. It directly reflects the optimization direction the system prioritizes in the current scenario. The weighting adjustment operation refers to the mathematical process of multiplying the value of each operational state data point by its corresponding weighting adjustment factor and then combining all the products in a certain way. The module score reflects the urgency of the functional module in acquiring bus bandwidth at the current moment; the higher the score, the higher the allocation priority. For example, bandwidth can be allocated proportionally based on the module score: bandwidth is allocated to a functional module according to the proportion of its module score in the total module score of multiple functional modules.

[0078] Weight adjustment operations can be determined through various methods, such as weighted summation. For example, weight adjustment can be implemented through linear weighted summation, nonlinear function transformation, and rule-based weighting. For instance, the importance of certain dimensions is not simply linearly related to their numerical values. For example, in nonlinear function transformation, waiting time may be unimportant initially, but its importance increases dramatically after exceeding a certain threshold. In this case, the original data can be processed using a nonlinear function first, and then the result can be substituted into the weighted summation formula to more precisely characterize the system state and achieve more intelligent scheduling. Furthermore, in rule-based weighting, the weights themselves can be functions of another variable. For example, the weights corresponding to the task load of functional modules can be dynamically adjusted according to the total system load: when the total load is high, more emphasis is placed on the load dimension; when the total load is low, more emphasis is placed on the fairness dimension, thereby achieving adaptive weight adjustment and improving the system's robustness in changing environments.

[0079] The above method, by introducing weight adjustment factors and module score calculation, can integrate multi-dimensional and multi-dimensional state data into a single, comparable module score through weighted calculation. This provides the arbitrator with a clear and quantitative decision-making basis, solving the problem of multi-objective decision-making. Furthermore, by dynamically adjusting the weight factors, the system can switch between different optimization objectives. For example, the load weight can be increased to pursue throughput, or the waiting time weight can be increased to ensure fairness.

[0080] In addition, it should be noted that, in order to flexibly adapt to the actual needs of different system operation scenarios, the above-mentioned scenario adjustment factors, weight adjustment factors, and / or scenario guarantee bandwidth can be dynamically adjusted based on changes in system operation scenario information.

[0081] In one example, when allocating bus bandwidth to multiple functional modules based on their allocation priorities, this can be achieved as follows: For any given functional module, determine the ratio between its module score and the sum of the scores of all functional modules; then, determine the bandwidth to be allocated to any given functional module based on the remaining available bandwidth and this ratio. For example, multiply the remaining available bandwidth by the ratio to obtain the bandwidth to be allocated to any given functional module. Accordingly, if the bandwidth to be allocated is not less than the scenario-guaranteed bandwidth of any given functional module, allocate bus bandwidth to any given functional module according to the bandwidth to be allocated; if the bandwidth to be allocated is less than the scenario-guaranteed bandwidth of any given functional module, allocate bus bandwidth to any given functional module according to the scenario-guaranteed bandwidth of any given functional module. This method can reasonably determine the amount of bandwidth for each functional module based on its module score, and it can also combine this with the scenario-guaranteed bandwidth to ensure the normal execution of functional modules and avoid functional abnormalities due to insufficient bandwidth.

[0082] Optionally, if a change in the system operating scenario information is detected, the scenario-guaranteed bandwidth allocated to multiple functional modules and / or multiple weight adjustment factors corresponding to multiple operating state dimensions can be dynamically adjusted based on the changed system operating scenario information. For ease of understanding, an example is provided below to illustrate the specific implementation details of the on-chip system-based bus bandwidth allocation method provided in this application.

[0083] This example provides a bus bandwidth adaptive arbitration algorithm and scheduling method for multiple functional modules implemented on a SoC, specifically involving SoC system design, adaptive arbitration algorithms, integrated circuit design and other technical fields.

[0084] In a System-on-Chip (SoC), multiple functional modules are integrated, such as a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a Neural Processing Unit (NPU), an Audio Digital Signal Processor (DSP), and an Image Signal Processor (ISP). These functional modules need to access system memory or other peripherals through a shared bus. This shared bus can be characterized by at least one of the following: Advanced eXtensible Interface (AXI), Advanced High-performance Bus (AHB), Network on Chip (NoC), or a DDR controller.

[0085] In related technologies, bus arbitration algorithms typically employ at least one of the following methods:

[0086] (1) Fixed Priority Arbitration: Set a fixed priority for each module, and high-priority modules always have priority access.

[0087] (2) Round Robin: Schedules bus access requests from each module in a time-slice manner.

[0088] (3) Static Bandwidth Reservation: The fixed bandwidth limit of each module is set at system startup or through hardware parameters.

[0089] (4) Manually adjust QoS level: Some systems allow users or drivers to set a module to "high priority" to improve real-time performance.

[0090] Most of the aforementioned scheduling strategies lack real-time performance and scenario adaptability, failing to dynamically adjust resources based on runtime load, task characteristics, system context, etc. Therefore, it is evident that the scheduling strategies in related technologies suffer from at least the following problems:

[0091] (1) Lack of context awareness: Traditional arbitration mechanisms cannot dynamically adjust scheduling priorities based on the current system operation scenario (such as games, speech recognition, taking pictures, etc.).

[0092] (2) Insufficient real-time guarantee: Polling or static priority methods are difficult to provide strong real-time guarantee for real-time modules (such as Audio DSP and ISP), which may lead to problems such as audio stuttering and image frame dropping.

[0093] (3) Resource starvation is likely to occur: In the fixed priority mechanism, low priority modules are likely to not get scheduling opportunities for a long time in high load scenarios.

[0094] (4) Low resource utilization: The bandwidth pre-allocation method may result in some modules having idle bandwidth, which cannot be dynamically transferred to modules that need it more, resulting in low overall system efficiency.

[0095] (5) Does not support module load feedback: The existing scheduling strategy lacks a feedback mechanism for the module's operating status and cannot dynamically adjust the arbitration ratio according to the module's current processing pressure.

[0096] This example aims to address the problems of poor real-time performance, lack of system context awareness, inability to adapt to load changes, and susceptibility to starvation of low-priority modules in the aforementioned SoC bus arbitration schemes. Specifically, this example proposes an adaptive bus arbitration algorithm model based on multi-factor weighted scoring to achieve dynamic scheduling and fair resource allocation among multiple modules, thereby improving the overall resource utilization and responsiveness of the system. Specifically, in a system-on-a-chip (SoC) scenario where multiple high-performance computing modules share access to bus resources, this example addresses how to implement an arbitration method that is aware of module status in real time and adaptively allocates bandwidth resources, effectively solving the following problems: module scheduling cannot be dynamically adjusted according to real-time load, leading to uneven resource allocation; the system lacks scenario awareness and cannot automatically optimize bandwidth configuration according to application requirements; fixed priority strategies result in some modules not receiving scheduling opportunities for extended periods, posing a risk of "starvation"; and low bus resource utilization limits the overall system performance.

[0097] Figure 2 This example illustrates a flowchart of the on-chip system-based bus bandwidth allocation method. Figure 2 As shown, the method includes the following steps:

[0098] Step S201: Based on the system operation scenario information, determine multiple operation status dimensions and collect the operation status of each functional module corresponding to the multiple operation status dimensions.

[0099] Specifically, this step can be performed periodically to achieve periodic data collection and scheduling. Alternatively, the current operating status of each module can be collected before scheduling. These operating status dimensions include, but are not limited to:

[0100] : The current task load of the functional module (e.g., DMA request rate, cache backlog length); specifically, Used to characterize the task load of the i-th functional module;

[0101] : The waiting time of the current functional module since it last obtained bandwidth; specifically, Used to characterize the waiting time of the i-th functional module;

[0102] : Whether it is a real-time task; where, This is used to characterize the timeliness priority of the i-th functional module determined by the system operation scenario information. If the timeliness priority of the i-th functional module is determined to be high according to the system operation scenario information, then a real-time task flag is set for the functional module; otherwise, a non-real-time task flag is set for the functional module.

[0103] : The priority adjustment factor for this functional module under the current system operating scenario (specifically, it can be passed from the application layer, such as "video call" or "AI recognition"); among which, This is used to characterize the scenario priority determined by the i-th functional module based on the system operation scenario information. If the scenario priority of the i-th functional module is determined to be high based on the system operation scenario information, a higher priority adjustment factor is set for that functional module; otherwise, a lower priority adjustment factor is set for that functional module.

[0104] The status acquisition methods include various methods such as register reading and writing, driver interface, and scheduler event listening.

[0105] Step S202: Obtain multiple scenario adjustment factors corresponding to the system operation scenario information. The multiple scenario adjustment factors correspond to multiple functional modules.

[0106] The scenario adjustment factors for each functional module include multiple weight adjustment factors that correspond one-to-one with the aforementioned multiple operating state dimensions. Each weight adjustment factor is used to adjust the corresponding operating state dimension.

[0107] Step S203: For any functional module, use the scene adjustment factor corresponding to the functional module to perform weight adjustment calculation on multiple running state data corresponding to the functional module to obtain the module score of the functional module.

[0108] Specifically, the calculation process for the module score (also called arbitration score) of the functional module is as follows:

[0109] Based on the collected status of each module and the multiple weight adjustment factors in the scene adjustment factors corresponding to the module, the arbitration score of each functional module is calculated. :

[0110]

[0111] Among them, w1~w4 are weight parameters, that is, multiple weight adjustment factors in the scene adjustment factors, and the specific values ​​can be preset by the system or dynamically adjusted.

[0112] Step S204: Allocate bus bandwidth to multiple functional modules based on their module scores.

[0113] Specifically, firstly, based on the scores of all functional modules... Calculate the total score Then, bandwidth is allocated according to the following formula:

[0114]

[0115] in, Used to characterize the bandwidth (i.e., the target bandwidth value) allocated to functional module i (i.e., the i-th functional module);

[0116] Used to characterize the scenario-guaranteed bandwidth configured for functional module i, and used to characterize the minimum bandwidth of the functional module in the current scenario;

[0117] Used to characterize the total available bandwidth, i.e. the total amount of bus bandwidth.

[0118] Therefore, the above formula aims to first allocate a minimum guaranteed bandwidth to each module based on the priority of each module, and then dynamically allocate the remaining available bandwidth according to the real-time score of each functional module. The remaining available bandwidth is the difference between the total bandwidth and the minimum guaranteed bandwidth of each functional module.

[0119] Step S205: Configure the arbiter / scheduler according to the bus bandwidth of multiple functional modules to achieve dynamic bandwidth scheduling.

[0120] Specifically, the target bandwidth value or bandwidth priority of each functional module determined in the previous step can be written into the hardware bus arbiter to configure registers (such as AXI QoS / arbitration window); or, the target bandwidth value or bandwidth priority of each functional module determined in the previous step can be used in the software DMA / scheduler logic to achieve rate limiting and priority scheduling. Furthermore, this example can also implement dynamic scenario optimization and adaptive iteration. In practice, the above steps are repeatedly repeated during system operation to achieve continuous bandwidth optimization iteration. Additionally, adjustments can be made in real time based on task changes, system status, or external control commands. For example, weighting factors w1~w4 and module guarantee lower limits can be dynamically adjusted. Equal values.

[0121] The following example, using a voice call scenario, illustrates the implementation process of this SoC bus bandwidth adaptive arbitration algorithm in practical applications:

[0122] In smartphones or edge AI devices, when a user makes a voice call, multiple modules within the SoC need to access shared bus resources (such as the AXI bus) simultaneously, including but not limited to:

[0123] Audio DSP: Performs audio signal processing such as echo cancellation (AEC), noise suppression (NS), and codec.

[0124] NPU: Used for voice wake-up / speech recognition inference (ASR);

[0125] CPU: Processes system control logic and voice control commands;

[0126] ISP: Used for front-facing camera and beauty / filter processing;

[0127] Other modules, such as Modem and Memory DMA, also need to access the bus.

[0128] In this scenario, the real-time performance of the Audio DSP and NPU is particularly critical, requiring stable bandwidth, while the GPU and ISP can process with a slight delay.

[0129] The specific implementation process is as follows:

[0130] (1) System initialization:

[0131] a. Set the bus arbitration period to 2 ms.

[0132] b. Configure the following initial parameters

[0133]

[0134] c. Configure the minimum guaranteed bandwidth B_min (unit: MB / s), where B_min represents the minimum guaranteed bandwidth corresponding to each functional module in the voice call scenario. This can be further configured through... These represent the minimum guaranteed bandwidth for the i-th functional module in a voice call scenario. It should be noted that... This refers to the bandwidth guarantee for the scenarios mentioned above. A specific form of representation in the context of voice calls.

[0135]

[0136] (2) Collect module status during the scheduling period to determine multiple weight adjustment factors for multiple operating status dimensions corresponding to each functional module.

[0137]

[0138] (3) Arbitration score calculation

[0139]

[0140]

[0141] Total Score

[0142] (4) Dynamic bandwidth allocation

[0143] Set the available system bus bandwidth B_total = 1000MB / s. Total guaranteed bandwidth: 100 + 50 + 30 + 20 + 10 = 210MB / s. Refer to the following formula to allocate the remaining 790MB / s of available bandwidth proportionally:

[0144]

[0145]

[0146] Total allocated bandwidth:

[0147] (5) Configure the arbitrator or software scheduler

[0148] Write the bandwidth limit value to the AXI arbitrator register or the bus QoS controller, and proceed to the next round of monitoring.

[0149] In summary, this example has the following characteristics:

[0150] (1) An extensible arbitration scoring function structure is introduced, denoted as: This enables a scheduling and scoring logic that allows for quantifiable module states and multi-factor fusion. Arbitration decisions no longer rely on fixed priorities but dynamically adapt to system operation, significantly improving the real-time performance and intelligence of system resource allocation. As can be seen, most existing technologies employ fixed priorities or static polling mechanisms, relying solely on module IDs or preset levels. This example, however, integrates the real-time operating status of modules (such as task queue length and waiting time), real-time tags, and contextual factors to calculate arbitration scores, thus introducing a multi-dimensional dynamic scoring system based on arbitration factors (load, waiting, real-time performance, and context).

[0151] (2) Set a minimum bandwidth guarantee value for each functional module. During arbitration allocation, the minimum guaranteed bandwidth (B_min) is enforced, ensuring that critical modules such as Audio DSP and NPU receive the minimum operating resources under extreme load conditions. This prevents system functional failures due to allocation fluctuations and achieves steady-state availability for high-real-time modules. Therefore, this example proposes a minimum guaranteed bandwidth mechanism (B_min) design, setting a minimum guaranteed bandwidth for each critical module during bus arbitration to prevent real-time modules from being completely starved due to low scores.

[0152] (3) A waiting time design is introduced to prevent starvation, thereby enabling automatic compensation scheduling for modules that have not been scheduled for a long time, improving the fairness of resource allocation, preventing certain modules from being "starved" for a long time, and ensuring the stability and service continuity of the system. It can be seen that this example proposes a dynamic scene-aware arrangement mechanism. Existing technologies lack the perception and matching of system operating scenarios (such as speech recognition, video conferencing, and AI computing), while this example sets a scene weighting factor ( It can dynamically adjust the bandwidth allocation strategy according to the operating scenario.

[0153] (4) A scene weight control structure (Scene Factor) is introduced to enable the arbitration algorithm to support "scene awareness". It can automatically adjust the system behavior according to the current user scenario (such as game mode, video call, AI inference, etc.) to improve the consistency and responsiveness of the user experience. As can be seen, this example proposes a waiting time mechanism. In the existing technology, low-priority modules may not receive resources for a long time (starve), while this example uses the integral form of "waiting time factor" to make the score of modules that have not received resources for a long time gradually increase, and eventually they can be scheduled.

[0154] (5) Introduce a proportional normalization processing structure in the resource allocation function. The bandwidth finally allocated to the i-th functional module is determined by the following formula:

[0155] This ensures that all modules are accurately allocated bandwidth according to their dynamic score ratios, enabling on-demand scheduling and maximum utilization of bandwidth resources, and avoiding redundancy, waste, or idle resources. The sum of available bandwidth is the total available bandwidth. As can be seen, this example proposes a bus utilization optimization algorithm (dynamic allocation + minimum waste). Existing technologies are prone to uneven bandwidth allocation or waste, while this example uses dynamic allocation logic to ensure that high-load modules obtain resources in a timely manner, and low-load modules do not occupy redundant resources.

[0156] Accordingly, this example can achieve at least the following beneficial effects:

[0157] (1) Dynamically and adaptively allocate bus bandwidth resources, resulting in a more intelligent and flexible system response. Implementation method: Introduce multiple dimensions of arbitration scoring factors, including: Load Factor (module load intensity), Wait Factor (waiting time), Real-Time Factor (task real-time level), and Scene Factor (current system operating scenario). Through the arbitration scoring model... Arbitration scores are calculated for all modules, and bandwidth is allocated proportionally to achieve adaptive arbitration.

[0158] (2) Ensure the real-time performance of key modules and avoid sudden performance drops in modules such as voice and AI. Implementation method: A "minimum bandwidth guarantee mechanism" was designed. Before allocating scores, B_min is first set for key modules. The final allocated bandwidth is: This mechanism ensures that critical modules always have room to survive in any scheduling cycle, thus avoiding resource starvation.

[0159] (3) The system is fairer, and low-priority modules will not "starve". Implementation method: Introduce a "Starve Factor" as a "waiting time integral", that is, each time a module does not obtain sufficient bandwidth, The value will increase, improving its arbitration score in subsequent scheduling cycles, ultimately forming an automatic "rotating compensation".

[0160] (4) Supports dynamic adaptation and resource optimization in various usage scenarios. Implementation method: The arbitration scoring model in this example incorporates... Factors, which can be provided by upper-layer applications, system kernels, or scene recognition engines, allow for: scene-based weighting of key modules (such as increasing the weight of Audio DSP and ISP in video conferencing); and automatic adjustment of strategies under different system states without manual configuration by the user.

[0161] (5) Significantly improve the utilization rate of system bus bandwidth and reduce resource waste. Implementation method: The dynamic arbitration algorithm combines real-time load and priority scoring to allocate bandwidth on demand. Modules with low scores receive less bandwidth, and the "fixed share" is no longer reserved, which would cause resources to idle, thereby achieving global resource optimization.

[0162] It is understood that the various method embodiments mentioned above in this disclosure can be combined with each other to form combined embodiments without violating the principle and logic. Due to space limitations, this disclosure will not elaborate further. Those skilled in the art will understand that in the above methods of specific implementation, the specific execution order of each step should be determined by its function and possible internal logic.

[0163] In addition, this disclosure also provides a system-on-a-chip (SoC) based bus bandwidth allocation device, electronic device, and computer-readable storage medium, all of which can be used to implement any of the SoC-based bus bandwidth allocation methods provided in this disclosure. The corresponding technical solutions and descriptions are described in the corresponding section of the method and will not be repeated here.

[0164] Figure 3 This is a block diagram of a system-on-a-chip (SoC)-based bus bandwidth allocation device provided in an embodiment of this disclosure.

[0165] Reference Figure 3 This disclosure provides a bus bandwidth allocation device based on a system-on-a-chip (SoC), wherein the SoC includes multiple functional modules, and the device includes:

[0166] The response module 31 is adapted to respond to a received bandwidth scheduling instruction, determine system operation scenario information corresponding to the bandwidth scheduling instruction, and multiple operation state dimensions corresponding to the system operation scenario information; and for any functional module, obtain the operation state data of the functional module under each operation state dimension.

[0167] The calculation module 32 is adapted to determine multiple scene adjustment factors corresponding to the system operation scene information, the multiple scene adjustment factors corresponding to the multiple functional modules; for any functional module, the calculation is performed on multiple operation state data corresponding to the functional module through the scene adjustment factor corresponding to the functional module, and the allocation priority of the functional module is determined according to the calculation result;

[0168] Allocation module 33 is adapted to allocate bus bandwidth to the plurality of functional modules according to the allocation priority of the plurality of functional modules.

[0169] In addition, this disclosure also provides a chip including programmable logic circuitry and / or program instructions, which, when executed, are used to implement the methods described above.

[0170] Figure 4 This is a block diagram of an electronic device provided in an embodiment of the present disclosure.

[0171] Reference Figure 4 This disclosure provides an electronic device, which includes: at least one processor 701; at least one memory 702; and one or more I / O interfaces 703 connected between the processor 701 and the memory 702; wherein the memory 702 stores one or more computer programs that can be executed by at least one processor 701, and the one or more computer programs are executed by at least one processor 701 to enable at least one processor 701 to execute the above-described system-on-a-chip bus bandwidth allocation method.

[0172] This disclosure also provides a computer-readable storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the above-described system-on-a-chip (SoC)-based bus bandwidth allocation method. The computer-readable storage medium may be volatile or non-volatile.

[0173] This disclosure also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code. When the computer-readable code is run in a processor of an electronic device, the processor in the electronic device executes the above-described system-on-a-chip bus bandwidth allocation method.

[0174] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0175] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0176] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0177] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.

[0178] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0179] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0180] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable system-on-a-chip (SoC) bus bandwidth allocation device to produce a machine such that, when executed by the processor of the computer or other programmable SoC bus bandwidth allocation device, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, a programmable SoC bus bandwidth allocation device, and / or other device to operate in a particular manner. Thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0181] Computer-readable program instructions may also be loaded onto a computer, other programmable system-on-a-chip bus bandwidth allocation device, or other device to cause a series of operational steps to be performed on the computer, other programmable system-on-a-chip bus bandwidth allocation device, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable system-on-a-chip bus bandwidth allocation device, or other device to implement the functions / actions specified in one or more boxes of the flowchart and / or block diagram.

[0182] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0183] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in connection with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in connection with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of this disclosure as set forth by the appended claims.

Claims

1. A method for allocating bus bandwidth based on a system-on-chip, characterized by, The system on chip comprises a plurality of functional modules, and the method comprises: In response to the received bandwidth scheduling instruction, system running scene information corresponding to the bandwidth scheduling instruction is determined, and a plurality of running state dimensions corresponding to the system running scene information are determined; for any functional module, running state data of the functional module in each running state dimension is obtained; wherein the plurality of running state dimensions comprise task load of the functional module and waiting time length of the functional module; A plurality of scene adjustment factors corresponding to the system running scene information are determined, and the plurality of scene adjustment factors correspond to the plurality of functional modules; the scene adjustment factor corresponding to the functional module comprises a plurality of weight adjustment factors corresponding to the plurality of running state dimensions; For any functional module, the plurality of running state data corresponding to the functional module are subjected to adjustment operation through the scene adjustment factor corresponding to the functional module, and the allocation priority of the functional module is determined according to the operation result; wherein the plurality of running state data corresponding to the functional module are subjected to weight adjustment operation according to the plurality of weight adjustment factors corresponding to the functional module, and the module score of the functional module is obtained; wherein the module score is used to represent the allocation priority of the functional module; According to the allocation priorities of the plurality of functional modules, the bus bandwidth is allocated to the plurality of functional modules.

2. The method of claim 1, wherein, Before the response to the received bandwidth scheduling instruction, the following is further included: In the case where the system running scene is changed, it is determined whether the scene difference degree between the changed system running scene and the system running scene before the change meets a preset scheduling condition; In the case where the preset scheduling condition is met, the bandwidth scheduling instruction is triggered.

3. The method of claim 2, wherein, The system running scene comprises a task type scene used to represent a system running task; and the scene difference degree is represented by a dependency relationship between the system running task and the plurality of functional modules; wherein the dependency relationship is used to represent the degree of dependence on the plurality of functional modules in the running process of the system running task; Then the determination of whether the scene difference degree between the changed system running scene and the system running scene before the change meets the preset scheduling condition comprises: The first dependency relationship between the changed system running task and the plurality of functional modules and the second dependency relationship between the system running task before the change and the plurality of functional modules are determined; According to the change of the first dependency relationship relative to the second dependency relationship, it is determined whether the scene difference degree between the changed system running scene and the system running scene before the change meets the preset scheduling condition.

4. The method of claim 2, wherein, The system running scene comprises a state type scene used to represent a system running state; and the scene difference degree is represented by an association relationship between the demand priority of the plurality of functional modules for the bus bandwidth and the system running state; Then the determination of whether the scene difference degree between the changed system running scene and the system running scene before the change meets the preset scheduling condition comprises: determine a first association relationship between the changed system running state and the plurality of functional modules, and a second association relationship between the original system running state and the plurality of functional modules; determine whether a scenario difference degree between the changed system running scenario and the original system running scenario meets a preset scheduling condition according to a change of the first association relationship relative to the second association relationship.

5. The method according to any of claims 2-4, characterized by, The system running scenario is predicted by a pre-trained scenario prediction model; wherein the scenario prediction model is trained according to a change of the system running scenario in a historical period; and / or, The system running scenario is determined by a received control instruction; wherein the control instruction is used to change the system running scenario.

6. The method according to any one of claims 1 to 4, characterized in that, The plurality of running state dimensions further comprise: a time efficiency priority and / or a scenario priority determined according to the system running scenario information.

7. The method according to any one of claims 1 to 4, characterized in that, The allocating bus bandwidth for the functional modules according to the allocation priority comprises: determining a remaining available bandwidth according to a plurality of scenario guarantee bandwidths corresponding to the system running scenario information; wherein the plurality of scenario guarantee bandwidths are used to represent a minimum bandwidth of the plurality of functional modules under the system running scenario, and the remaining available bandwidth is a bandwidth remaining after the plurality of functional modules are allocated corresponding scenario guarantee bandwidths; determining a module available bandwidth of the functional module from the remaining available bandwidth according to the allocation priority of the functional module; allocating bus bandwidth for the functional module according to a sum of the scenario guarantee bandwidth of the functional module and the module available bandwidth of the functional module.

8. The method of claim 1, wherein, The allocating bus bandwidth for the plurality of functional modules according to the allocation priority of the plurality of functional modules comprises: determining a ratio between a module score of any functional module and a sum of scores of the plurality of functional modules; determining a to-be-allocated bandwidth of the any functional module according to the remaining available bandwidth and the ratio; allocating bus bandwidth for the any functional module according to the to-be-allocated bandwidth in a case that the to-be-allocated bandwidth is not less than a scenario guarantee bandwidth of the any functional module; allocating bus bandwidth for the any functional module according to the scenario guarantee bandwidth of the any functional module in a case that the to-be-allocated bandwidth is less than the scenario guarantee bandwidth of the any functional module.

9. The method of claim 1, wherein, The method further comprises: in a case that it is detected that system running scenario information is changed, dynamically adjusting the scenario guarantee bandwidth allocated for the plurality of functional modules and / or dynamically adjusting a plurality of weight adjustment factors corresponding to the plurality of running state dimensions according to the changed system running scenario information.

10. A system-on-chip based bus bandwidth allocation apparatus, characterized by, The system on chip comprises a plurality of functional modules, and the device comprises: The response module is adapted to determine system running scenario information corresponding to the received bandwidth scheduling instruction and a plurality of running state dimensions corresponding to the system running scenario information in response to the received bandwidth scheduling instruction; for any functional module, running state data of the functional module in each running state dimension is acquired; wherein the plurality of running state dimensions include task load of the functional module and waiting time length of the functional module; The operation module is adapted to determine a plurality of scenario adjustment factors corresponding to the system running scenario information, the plurality of scenario adjustment factors corresponding to the plurality of functional modules; the scenario adjustment factor corresponding to the functional module includes a plurality of weight adjustment factors corresponding to the plurality of running state dimensions; for any functional module, the plurality of running state data corresponding to the functional module are subjected to adjustment operation through the scenario adjustment factor corresponding to the functional module, and the allocation priority of the functional module is determined according to the operation result; wherein the plurality of running state data corresponding to the functional module are subjected to weight adjustment operation according to the plurality of weight adjustment factors corresponding to the functional module, to obtain a module score of the functional module; wherein the module score is used to represent the allocation priority of the functional module; The allocation module is adapted to allocate bus bandwidth for the plurality of functional modules according to the allocation priority of the plurality of functional modules.

11. A chip, characterized by The chip comprises programmable logic circuit and / or program instructions, and the chip is used to implement the method of any one of claims 1 to 9 when running.

12. An electronic device, comprising: Comprise: At least one processor; And The memory is connected in communication with the at least one processor; wherein The memory stores one or more computer programs that can be executed by the at least one processor, and one or more computer programs are executed by the at least one processor to enable the at least one processor to execute the method of any one of claims 1-9.

13. A computer readable storage medium having stored thereon a computer program, characterized in that The computer program implements the method of any one of claims 1-9 when executed by the processor.

14. A computer program product comprising computer readable code, or a non-transitory computer readable storage medium having computer readable code embodied thereon, the computer readable code comprising instructions for causing a computer to perform the method of any one of claims 1 to 13. When the computer readable code runs in the electronic device, the processor in the electronic device executes the method of any one of claims 1 to 9.

Images