System and method for managing arbitration and command acquisition

Abstract

A system and method for managing arbitration and command acquisition in a data communication system is provided. The method includes determining that the number of command requests is greater than or equal to a minimum acquisition threshold or the number of resources receiving the command requests is greater than or equal to a resource threshold, and sending the command requests in response to the number of command requests being greater than or equal to a minimum acquisition threshold or the number of resources receiving the command requests being greater than or equal to a resource threshold.

Description

[0001] priority

[0002] This application is based upon and claims priority to U.S. Provisional Patent Application Serial No. 63 / 512,191 filed on July 6, 2023, the entire contents of which are incorporated herein by reference. Technical Field

[0003] The present disclosure relates generally to data processing (process) systems, and more particularly, to methods and systems for optimizing command fetch operations in such systems to improve throughput performance and efficient resource allocation. Background Art

[0004] Data processing systems are often described as including a host system and a memory system. The host system is responsible for performing task functions and typically operates using logical addresses, which act as an intermediate layer between the host system software and the physical memory within the memory system. These memory systems include a controller (e.g., a processor) module that converts host-level read and write requests (e.g., "get" requests) based on logical addresses into command structures that include physical addresses used by the memory devices.

[0005] In situations where the host system issues a fetch request to the memory system and the memory system is engaged in background operations using the flash memory device at that time, the memory system may not respond to the host request immediately. In time-sensitive scenarios such as certain types of data or command reads and status requests, this may cause delays in performing certain functions or trigger a timeout condition, prompting the host system to respond to the timeout condition. The specific response to the timeout varies depending on the nature of the task function and can have a significant impact on host system performance.

[0006] To address this problem, it is desirable to develop a controller that can prevent delays and timeout conditions at the host level. For example, techniques such as multiple command acquisition have been developed to address the slow arbitration turnaround time problem and meet device throughput performance requirements. However, these techniques focus primarily on throughput performance without adequately addressing other aspects of the system, such as power consumption, transmission overhead, and resource allocation planning. Summary of the invention

[0007] The present disclosure has been made to address at least the above disadvantages and to provide at least the advantages described below.

[0008] According to one aspect of the present invention, a system for managing arbitration and command acquisition in a data communication system is provided, and the system includes an input channel configured to issue commands and a controller. The controller is configured to determine that the number of command requests is greater than or equal to a minimum acquisition threshold or the number of resources receiving the command requests is greater than or equal to a resource threshold, and send the command request in response to the number of command requests being greater than or equal to the minimum acquisition threshold or the number of resources receiving the command requests being greater than or equal to the resource threshold.

[0009] According to another aspect of the present invention, a method for managing arbitration and command acquisition in a data communication system is provided. The method includes determining that the number of command requests issued by an input channel is greater than or equal to a minimum acquisition threshold or the number of resources receiving the command requests is greater than or equal to a resource threshold, and sending the command request in response to the number of command requests being greater than or equal to the minimum acquisition threshold or the number of resources receiving the command requests being greater than or equal to the resource threshold. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The above and other aspects, features and advantages of certain embodiments of the present disclosure will become more apparent from the following detailed description in conjunction with the accompanying drawings, in which:

[0011] Figure 1A is a block diagram illustrating a minimum command acquisition system according to an embodiment;

[0012] Figure 1B is a block diagram illustrating a host executing a device acquisition command according to an embodiment;

[0013] Figure 2 is a timing diagram comparing an ideal timing scenario and an actual timing scenario according to an embodiment;

[0014] Figure 3 is a timing diagram comparing burst, pipeline, and concurrent timing schemes according to an embodiment;

[0015] Figure 4 is a block diagram illustrating arbitration selection using a minimum acquisition threshold according to an embodiment;

[0016] Figure 5 is a flow chart illustrating arbitration selection using a minimum acquisition threshold according to an embodiment;

[0017] Figure 6 is a timing diagram illustrating arbitration selection using a minimum acquisition threshold according to an embodiment;

[0018] Figure 7 is a block diagram illustrating a host executing a device acquisition command according to an embodiment;

[0019] Figure 8is a timing diagram illustrating a multi-channel requester scenario according to an embodiment; and

[0020] Fig. 9 is a block diagram illustrating an electronic device in a network environment according to an embodiment. DETAILED DESCRIPTION

[0021] Hereinafter, embodiments of the present disclosure are described in detail with reference to the accompanying drawings. It should be noted that although the same elements are shown in different drawings, the same elements will be represented by the same reference numerals. In the following description, only specific details such as detailed configuration and components are provided to help fully understand the embodiments of the present disclosure. Therefore, it should be clear to those skilled in the art that various changes and modifications can be made to the embodiments described herein without departing from the scope of the present disclosure. In addition, for clarity and conciseness, the description of well-known functions and structures is omitted. The terms described below are defined terms in consideration of the functions in the present disclosure, and may be different according to the user, the user's intention or custom. Therefore, the definition of terms should be determined based on the content in the entire specification.

[0022] The present disclosure may have various modifications and various embodiments, wherein the embodiments are described in detail below with reference to the accompanying drawings. However, it should be understood that the present disclosure is not limited to the embodiments, but includes all modifications, equivalents and substitutes within the scope of the present disclosure.

[0023] Although terms including ordinal numbers such as first, second, etc. can be used to describe various elements, structural elements are not limited by terms. Terms are used to distinguish one element from another element. For example, without departing from the scope of the present disclosure, the first structural element can be referred to as the second structural element. Similarly, the second structural element can also be referred to as the first structural element. As used herein, the term "and / or" includes any and all combinations of one or more associated items.

[0024] The terms used herein are only used to describe various embodiments of the present disclosure and are not intended to limit the present disclosure. Unless the context clearly indicates otherwise, the singular form is intended to include the plural form. In the present disclosure, it should be understood that the term "including" or "having" indicates the presence of features, numbers, steps, operations, structural elements, parts or combinations thereof, and does not exclude the presence of one or more other features, numbers, steps, operations, structural elements, parts or combinations thereof or the possibility of adding one or more other features, numbers, steps, operations, structural elements, parts or combinations thereof.

[0025] Unless otherwise defined, all terms used herein have the same meaning as understood by those skilled in the art to which the present disclosure belongs. Unless explicitly defined in the present disclosure, terms such as those defined in commonly used dictionaries will be interpreted as having the same meaning as the contextual meaning in the relevant art and should not be interpreted as having an ideal or overly formal meaning.

[0026] The electronic device according to one embodiment may be one of various types of electronic devices using a storage device. The electronic device may include, for example, a portable communication device (e.g., a smart phone), a computer, a portable multimedia device, a portable medical device, a camera, a wearable device, or a household appliance. According to one embodiment of the present disclosure, the electronic device is not limited to those described above.

[0027] The terms used in the present disclosure are not intended to limit the present disclosure, but are intended to include various changes, equivalents or replacements of corresponding embodiments. Regarding the description of the accompanying drawings, similar reference numerals may be used to refer to similar or related elements. Unless otherwise clearly stated in the relevant context, the singular form of the noun corresponding to the project may include one or more things. As used herein, each of the phrases such as "A or B", "at least one of A and B", "at least one of A or B", "A, B or C", "at least one of A, B and C" and "at least one of A, B or C" may include all possible combinations of the items listed together in a corresponding phrase. As used herein, terms such as "the 1st", "the 2nd", "the first" and "the second" may be used to distinguish a corresponding component from another component, but are not intended to limit the component in other aspects (e.g., importance or order). It is intended that if an element (e.g., a first element) is referred to as being “coupled with another element (e.g., a second element)”, “coupled to another element (e.g., the second element)”, “connected with another element (e.g., the second element)”, or “connected to another element (e.g., the second element)” with or without the term “operably” or “communicatively”, it indicates that the element may be coupled with the other element directly (e.g., by wire), wirelessly, or via a third element.

[0028] As used herein, the term "module" may include a unit implemented in hardware, software, firmware, or a combination thereof, and may be used interchangeably with other terms (e.g., "logic," "logic block," "component," and "circuit"). A module may be a single integrated component or its smallest unit or portion suitable for performing one or more functions. For example, according to one embodiment, a module may be implemented in the form of an integrated circuit (IC).

[0029] Figure 1A is a block diagram illustrating a minimum command acquisition system according to an embodiment.

[0030] refer to Figure 1A , the minimum command acquisition system 101 may be an electronic device and includes a host 102 having a host memory 103 and a device 104 having a controller 105. The host 102 may communicate with the device 104 by wire or wirelessly. Other structural components may also be included (for example, the host 102 may include a controller and / or the device 104 may include a memory).

[0031] The minimal command fetch system is designed to optimize data retrieval and transfer between the host 102 and the device 104 while optimizing latency and resource utilization.

[0032] Host 102 is a computing entity that initiates and manages data acquisition operations. Host 102 can be a computer, a server, or any device that requires data from an external device. Device 104 can refer to peripheral or external hardware that stores or provides data requested by the host. This can include storage devices (e.g., hard drives, solid-state drives (SSDs)), network devices (e.g., routers or switches), or other specialized hardware.

[0033] The host has a memory 103 for temporarily storing data during the acquisition process. The memory 103 may include random access memory (RAM) and cache memory.

[0034] "Read" refers to the process of retrieving data from a peripheral or external device by a host 102 (typically a computer or central processing unit) in response to a specific request or command request. The process involves the host 102 issuing a read command request to the device 104 to provide a certain amount of data or perform a specific operation, and the device 104 responding by supplying the requested data or performing the required action. "Get" refers to the process of retrieving a command request.

[0035] The minimum fetch threshold (also referred to as "N" or "N") is a parameter that defines the minimum number of data units or commands that need to be fetched in a single operation.

[0036] A completion queue (CQ) is a buffer or data structure used by device 104 to respond to command requests from host 102 when completing command requests from host 102. Device 104 posts CQ entries to the CQ stored in host memory 103 to allow host 102 to retrieve them.

[0037] The submission queue (SQ) is another data structure that holds data retrieval commands when one or more requests are issued from the host 102 to the device 104. It may include information about the priority and order of data acquisition requests. The host 102 publishes commands as SQ entries to the SQ stored in the host memory 103. The device 104 may retrieve the commands stored in the SQ as SQ entries.

[0038] Arbitration logic may be included as the component responsible for deciding which data request to prioritize when multiple requests are pending to help ensure efficient resource allocation.

[0039] Figure 1B is a block diagram illustrating a host executing a device acquisition command according to an embodiment.

[0040] refer to Figure 1B , the host 151 may issue commands 152a, 152b, and 152c to submission queues in different channels 153a, 153b, and 153c. The device may use arbitration 154 to determine which channel to get the command from. Arbitration is the process in which multiple requests or commands compete for a shared resource, and a decision is made to determine which one gets access to the resource. The arbitration step may take a first amount of time, such as 150 nanoseconds (ns). Once it is determined at box 154 which command will be obtained, a command ("CMD" in Figure 1) acquisition 155 is performed to access the address of the host memory 156 included in the host 151. Accessing the host memory 156 address may take a second amount of time, such as 500ns to 1000ns. In addition, at box 157, command dispatch is performed to execute the command obtained from the host memory 156 address, thereby indicating active and inactive input / output (IO) blocks. Therefore, the first amount of time (e.g., arbitration time) is less than the second amount of time (e.g., acquisition time). Additionally, the IO time to execute the read / write command may be 45 microseconds (us), which is greater than the first amount of time and the second amount of time.

[0041] The amount of time available to execute a command may be determined and / or limited by an integrated circuit (IC) (e.g., Peripheral Component Interconnect Express (PCIe) 6x4) (e.g., 8 Mobile IO Ports (MIOPS)). For example, command processing performance may be 125ns per 4 kilobyte (KB) command. In this case, if arbitration 154 takes a duration of 150ns, the system may execute commands inefficiently because the IC execution time (e.g., 125ns) is less than the arbitration time (e.g., 150ns). Ideally, for optimal system performance, the arbitration time should be slightly less than the IC execution time.

[0042] Figure 2 is a timing diagram comparing an ideal timing scenario with an actual timing scenario according to an embodiment.

[0043] refer to Figure 2 , if the upstream push command to the channel is 125ns (e.g., corresponding to a command processing performance of 125ns per 4kB command), the ideal arbitration time should be <125ns. Furthermore, the acquisition time should be <<125ns, and the downstream IO time should be <<<125ns. However, in practice the arbitration time may be 150ns, which is slightly greater than the ideal arbitration time. Furthermore, the acquisition time may be 1000ns, and the IO time may be 45000ns. Therefore, various schemes are proposed to output commands whose timing is more similar to the ideal timing scenario than the actual timing scenario.

[0044] Figure 3 is a timing diagram comparing burst, pipeline, and concurrent timing schemes, according to an embodiment.

[0045] refer to Figure 3 , eight upstream commands are pushed to the channel at approximately 125ns intervals.

[0046] The burst scheme involves processing multiple commands at once in short bursts, which can help increase throughput while minimizing resource allocation inefficiencies. Instead of fetching and processing one command at a time, the burst scheme involves grouping a set of related commands or tasks and processing them together in a single burst. This reduces the overhead of initiating and completing each command individually.

[0047] like Figure 3 As shown, for a burst scheme, a set of two commands may be pushed at 150ns intervals. Therefore, the arbitration time for each command may be equal to approximately 75ns.

[0048] The pipeline scheme breaks processing into multiple stages, each of which can process one command at a time. This allows commands to be processed continuously without waiting for the entire process to complete before starting the next one. Commands are divided into sequential stages, where each stage is responsible for a specific part of the processing. Once a stage completes its task for a command, it passes the command to the next stage in the pipeline. In this way, command acquisition can be performed continuously without waiting for the previous command to finish execution.

[0049] like Figure 3 As shown, for the pipeline scheme, a group of eight commands can be obtained from the channel at intervals of 1000ns. Therefore, the time used to obtain each command can be equal to about 125ns.

[0050] Concurrency schemes involve splitting the processing into multiple concurrent units, each capable of processing its own commands independently. This can further improve throughput and resource utilization. Multiple execution units or cores are used, each capable of executing commands independently. Commands are distributed among these units, allowing them to work concurrently.

[0051] like Figure 3 As shown, the time used to obtain each downstream concurrent access command can be 125ns.

[0052] Although the bursting scheme, pipeline scheme, and concurrent scheme may enhance device throughput performance while addressing concerns such as power consumption, transmission overhead, and resource allocation planning, the pipeline scheme and concurrent scheme may not be used with arbitration.

[0053] Pipeline schemes may not be used with arbitration because arbitration cannot be easily decomposed into independent stages or segments because the outcome of the arbitration that determines the winner among competing requests is a critical and indivisible decision. In other words, the arbitration process cannot be split into stages because the final outcome depends on the entire process. In addition, decisions made during arbitration, such as selecting a request (issuing a command) over other requests, directly affect the subsequent arbitration process. The winner and the estimated burst size from the previous arbitration can affect which requests compete in the next round. This interdependence makes it challenging to implement traditional pipeline structures where the stages operate independently.

[0054] Arbitration cannot be practically applied to concurrent schemes because concurrent arbitration may cause interference between different request groups. The outcome of the arbitration process of one group may affect the outcome of the process of another group. This interference makes it difficult to maintain fairness and predictability in resource allocation. In addition, implementing concurrent arbitration may be expensive in terms of hardware cost and power consumption. Running multiple arbitration processes concurrently requires additional hardware resources, which may increase both the cost and power consumption of the system.

[0055] Although burst schemes can be used with arbitration, burst schemes do not guarantee that each acquisition operation will include a satisfactory number of commands. Sometimes, only a single command may be acquired, especially when the commands are not continuous or there are gaps in the sequence. This inefficiency may lead to underutilization of available bandwidth. In addition, acquiring one command at a time (called a single access) may be inefficient in terms of bandwidth utilization. Although each single acquisition consumes resources, the available data transfer capacity is not fully utilized. In addition, the less efficient single acquisition may lead to excessive power consumption because the system continuously starts and stops the acquisition operation, which may be power intensive. In addition, the overhead associated with initiating the acquisition operation (such as address calculation and control signaling) reduces the effective available bandwidth in shared resources (such as PCIe bus). In addition, burst acquisition may cause resource allocation planning to fluctuate between acquiring multiple commands at a time and acquiring only one command. This variability may make it challenging to allocate resources effectively and predictably.

[0056] Therefore, while burst fetches can help meet bandwidth requirements in arbitration, they have drawbacks including inefficiency in fetching a single command, excessive power consumption, and fluctuations in resource allocation planning. These issues can affect overall system performance and resource utilization.

[0057] Therefore, the present application proposes to proactively bundle acquisitions based on a minimum threshold and / or a timer. This combines the burst approach discussed above, but additionally includes the step of proactively bundling commands into bursts to efficiently utilize system resources.

[0058] Therefore, burst acquisition can be used as the standard and most common behavior during arbitration to improve efficiency.

[0059] To encourage burst acquisition as the default behavior, a "minimum acquisition threshold" is introduced. This threshold represents the minimum number of commands or resources that must be accumulated before a burst acquisition is performed.

[0060] A burst acquisition operation can be triggered only when the accumulated commands or resources are greater than or equal to the minimum acquisition threshold. This means that if there are not enough upstream commands waiting to be acquired or there are not enough downstream resources (e.g., downstream buffer space to receive, queue and process one or more commands, or one or more parsing of receiving commands), the system will postpone (or wait) and not initiate a burst acquisition until enough upstream commands are accumulated or enough downstream resources become available, thereby always maintaining more efficient command processing.

[0061] If one channel or command source is idle or slowly accumulates a number of commands greater than or equal to the number of commands required to meet the minimum acquisition threshold, it may lead to a scenario where the system waits indefinitely for the slow channel to catch up, even if other channels have commands available for acquisition.

[0062] To address the problem of indefinitely waiting for slow channels, a wait timer is introduced as a remedy. The wait timer can be set based on the average time used to accumulate the required number of commands required to meet the minimum acquisition threshold. If a particular channel or source is below the minimum acquisition threshold and does not accumulate enough commands within a predetermined time, the system activates the wait timer.

[0063] The wait timer sets the maximum duration of the wait. If a predetermined number of commands are not acquired within that time frame, the system bursts acquires with available commands from other sources, ensuring that the system does not wait excessively on slow channels.

[0064] Figure 4 is a block diagram illustrating arbitration selection using a minimum acquisition threshold according to an embodiment.

[0065] refer to Figure 4 , commands may be issued from channels 401a, 401b, and 401c. At block 402, arbitration is performed. A wait timer may be initialized, and once the number of commands for arbitration and the device resources are greater than or equal to the minimum acquisition threshold at block 403, commands may be sent as a burst to the CMD acquisition block 404 for execution. However, if the wait timer reaches a predetermined duration (or expires) before the number of commands and / or the device resources are greater than or equal to the minimum acquisition threshold at block 403, then available commands, which may be limited by available device resources, may be sent to the CMD acquisition block 404 for execution.

[0066] Figure 5 is a flow chart illustrating arbitration selection using a minimum acquisition threshold according to an embodiment.

[0067] refer to Figure 5 At step 501, the arbitration selection process is initialized. At step 502, the number of commands in the channel (SQ) is compared with a minimum acquisition threshold N (minimum acquisition threshold). N can be a predetermined number for efficient transmission and meeting power and overhead savings, which is a multiple (e.g., 2, 3, etc.) of the host issuing commands.

[0068] The host may issue a command multiple by an integer number that reduces the overall power consumption required for acquisition (e.g., if the predetermined number is 2, the power consumption may be reduced by 50%). However, the higher the clock frequency, the greater the power consumption. In addition to power reduction, the host may issue a command multiple by reducing the overhead bandwidth required to send data requests because the host may issue a command multiple by enabling multiple pieces of data to be sent for each command.

[0069] If SQ is greater than N (yes in step 502), then at step 503, the downstream resources are compared with N. In step 503, the downstream resources may represent the number of downstream resources. If the downstream resources are greater than N (yes in step 503), a CMD acquisition is performed in step 504, and an acquisition burst is sent. Therefore, according to the above method, both the number of downstream resources (downstream resources in step 503) and the number of upstream commands (SQ in step 502) should meet the minimum acquisition threshold (N in steps 502 and 503) to start the CMD acquisition operation in step 504. On the other hand, in step 502, if SQ is not greater than N (no in step 502), then in step 505, a timer is compared with T, where T is a predetermined waiting time. T can be calculated based on the time to acquire the minimum number of commands. Since the system's clock can run slightly faster or slower than the time to acquire the command, a roundup time can be used.

[0070] For example, T may be further rounded up to an integer that is a multiple of the arbitration round-up time (e.g., T=(150*$ROUNDUP((2×125ns) / 150n)=300ns). The timer may be initialized at step 501, and the timer may be reset after the CMD acquisition is performed at step 504. If the timer is greater than T (yes in step 505), the CMD acquisition may be performed at step 504. Otherwise, if the timer is not greater than T (no in step 505), the arbitration may continue, and the CMD acquisition may be performed again. Step 502. In addition, at step 503, if the resource is not greater than N (No in step 503), the timer is compared with T in step 506, where T is the predetermined waiting time. The timer can be initialized at step 501, and the timer can be reset after performing the CMD acquisition at step 504. If the timer is greater than T (Yes in step 506), the CMD acquisition can be performed at step 504. Otherwise, if the timer is not greater than T (No in step 506), the arbitration can continue, and step 502 can be performed again.

[0071] Figure 6 is a timing diagram illustrating arbitration selection using a minimum acquisition threshold according to an embodiment.

[0072] refer to Figure 6 , issuing upstream push commands (e.g., SQ) to the channel with a predetermined time period of 125ns. The 125ns time period may be a function of the command processing performance of the system (e.g., PCIe 6x4 with 125ns per 4kB command). Figure 6 As shown, the arbitration delay (Init T = 150ns) is a time period that is larger than the upstream push command time period (125ns). Using arbitration selection based on the minimum acquisition threshold, commands are bundled and sent at ideal timing instances to most efficiently use system resources. For example, commands 8 and 7 are bundled and sent at 150ns (which is the arbitration delay). Commands 6 and 5 are bundled and sent at 375ns (corresponding to the next available upstream push command after the arbitration delay of the second command (150ns + 150ns = 300ns rounded up to 375ns)). Similarly, commands 4 and 3 are bundled and sent at 625ns (corresponding to the next available upstream push command after the arbitration delay of the third command (375ns + 150ns = 525ns rounded up to 625ns)). Commands 2 and 1 are bundled and sent at 875 ns, corresponding to the next available upstream push command after the arbitration delay of the fourth command (625 ns + 150 ns = 775 ns rounded up to 875 ns).

[0073] Figure 7 is a block diagram illustrating a host executing a device fetch command according to an embodiment.

[0074] refer to Figure 7 , the host 701 can issue commands 702a, 702b, 702c to submission queues in different channels 703a, 703b, and 703c. The device can use arbitration 704 to determine which channel to get the command from. Once it is determined at block 704 which command to get, the command is executed ( Figure 7 The host 701 may further include a "CMD" in the block 705 to obtain an address of a host memory 706 included in the host 701. In addition, at block 707, command dispatching is performed to execute the command obtained from the host memory 706 address, thereby indicating active and inactive IO blocks. The command dispatching at block 707 may include parsing and conversion to determine the amount of available downstream resources to receive the command. In practice, it may be necessary to fill the downstream buffer with sufficient downstream resources before dispatching.

[0075] in addition, Figure 7 A tag usage monitor 708 is included that can make decisions about how data should be acquired based on "Host_QD" (Host Queue Depth) statistics and other conditions such as timestamps and availability values. The system can adjust acquisition operations accordingly to optimize data transfer while taking into account the host's capacity.

[0076] Host_QD represents the number of outstanding requests or commands that the host can issue to a peripheral device or storage device. The timestamp of the instruction issued by the host 701 is compared with the timestamp of the device acquisition command to obtain Host_QD. When Host_QD is less than a certain value N, the minimum acquisition operation should be disabled or reduced. Therefore, if the queue depth of the host is insufficient, the acquisition operation should be limited to prevent the system from not being able to accumulate enough commands to perform acquisition and the timer remains in the expired state.

[0077] In addition, the size of the burst can be adjusted (increased or decreased) based on whether the previous acquisition (e.g., the acquisition performed) timed out (e.g., due to a no-op) and / or whether the previous acquisition was greater than a minimum size. For example, if the previous acquisition operation experienced a timeout, it means that it took longer than expected to complete and it may have acquired less data than expected. In response to this situation, the next acquisition operation can be more aggressive in catching up to meet the required data transfer or processing rate. To achieve this, the minimum acquisition value for the next acquisition can be increased to compensate for the difference in the previous acquisition. This adjustment is intended to ensure that the next acquisition acquires more data and is performed at a faster rate to catch up with the expected performance.

[0078] Conversely, if a previous fetch operation successfully fetched more data than the minimum requirement, this indicates that the system is processing data ahead of schedule or more efficiently than expected. In this case, the next fetch operation can be relaxed. To achieve this, the value of the minimum fetch value for the next fetch can be reduced by the amount that aligns with the excess data fetched in the previous operation. By reducing the minimum fetch requirement, the system can operate more conservatively and avoid over-fetching, which may be unnecessary and can potentially strain system resources.

[0079] Figure 8 is a timing diagram illustrating a multi-channel requester scenario according to an embodiment.

[0080] refer to Figure 8, the acquisition burst operation is performed by ten channels corresponding to AJ respectively. Two instruction bursts A1 and A2 are sent by the first channel at the 1250ns time instance; two instruction bursts B1 and B2 are sent by the second channel at the 1400ns time instance; two instruction bursts C1 and C2 are sent by the third channel at the 1550ns time instance; two instruction bursts D1 and D2 are sent by the fourth channel at the 1700ns time instance; two instruction bursts E1 and E2 are sent by the fifth channel at the 1850ns time instance; two instruction bursts F1 and F2 are sent by the sixth channel at the 2000ns time instance; two instruction bursts G1 and G2 are sent by the seventh channel at the 2150ns time instance; two instruction bursts H1 and H2 are sent by the eighth channel at the 2300ns time instance; two instruction bursts I1 and I2 are sent by the ninth channel at the 2450ns time instance; and two instruction bursts J1 and J2 are sent by the tenth channel at the 2600ns time instance.

[0081] The arbitration time is 150ns, so each subsequent instruction burst is sent from a different channel in increments of 150ns until the timer of one of the channels exceeds the wait time of that channel. Once the timer of one of the channels exceeds the wait time of that channel, that channel can send another instruction burst (e.g., A3 and A4, B3 and B4, etc.). Each channel can have its own wait time, and the wait time of each channel can vary. The wait time of each channel can be measured between instruction bursts of that channel. The wait time can be based on the minimum acquisition threshold, the arbitration time, and the number of channels. The wait time can be rounded up to the next available upstream push command.

[0082] To ensure efficient management of arbitration and command acquisition, the system can extend the arbitration wait time duration based on the number of input channels and their assigned weights during the arbitration process. For equal-weighted channels, the wait duration can be determined by multiplying the minimum acquisition timeout duration for a single channel by the total number of channels. If the minimum acquisition timeout duration for a single channel is set to 300ns (corresponding to two arbitration cycles of 150ns each), and there are 10 such channels, the resulting extended minimum acquisition timeout duration will be 3000ns.

[0083] In scenarios where channels have different weights, the acquisition timeout duration of the lower-prioritized channel can be combined with the sum of the weights of all channels. For example, if the first channel is assigned a weight five times greater than the other channels, the acquisition timeout duration of the second through tenth channels will be 4200ns, which is calculated as the sum of the weights (5 for the first channel plus 1 for each of the remaining nine channels) multiplied by the single channel minimum acquisition time of 300ns. The first channel will have an acquisition timeout duration of 3000ns during its initial arbitration, while subsequent arbitrations for that channel will each have a standard duration of 300ns.

[0084] The adaptive mechanism effectively balances the system throughput performance with considerations of power consumption, transmission overhead, and resource allocation planning by dynamically adjusting the waiting time in response to the changing arbitration weights and the number of input channels.

[0085] Furthermore, the wait duration may be determined by multiplying the number of minimum acquisition counts by the command or request throughput time. To align with the operating capabilities of the system, this duration may then be rounded up to the nearest integer of the arbitration time, resulting in a so-called rounded-up wait duration.

[0086] The key advantage of rounding up the wait time to the arbitration time is the potential reduction in the frequency of arbitration operations. Such a reduction is quantified by the rounding up of the wait duration to an integer number that fits into the arbitration time. Reducing the frequency of arbitration operations reduces power consumption, thereby reducing operating costs, and alleviates the need for high-speed logic design or large parallel design structures, effectively reducing design costs.

[0087] The baseline wait duration may be an initially calculated duration determined by multiplying the minimum number of gets by the command or request throughput time. The baseline wait duration may be a base interval for processing a command or request before any adjustments are made.

[0088] The ceiling multiple can be a factor used to adjust the baseline wait duration to the nearest whole multiple of the system arbitration time. This ensures that the wait time is aligned with the system's clock (e.g., frequency). The ceiling multiple can be calculated by dividing the baseline wait duration by the arbitration time and then applying a ceiling function to the nearest integer.

[0089] Once the ceiling multiple is determined, the ceiling wait duration can be calculated. The ceiling wait duration can be an adjusted wait time that the system will use, which reconciles the baseline wait duration with the arbitration time by multiplying the ceiling multiple by the arbitration time. The adjusted duration facilitates reducing the frequency of arbitration operations, which can lead to improved system efficiency.

[0090] The rounded-up arbitration operating frequency can be obtained by taking the baseline arbitration operating frequency and dividing it by the rounding-up multiple. This results in a new operating frequency that, because it is rounded, reduces the total number of arbitration operations required. This has the effect of saving power and simplifying system design.

[0091] Fig. 9 is a block diagram illustrating an electronic device in a network environment according to an embodiment.

[0092] Fig. 9 The electronic device in may correspond to a host and / or a device.

[0093] refer to Fig. 9 , an electronic device 901 (e.g., a mobile terminal including a global positioning system (GPS) function) in a network environment 900 may communicate with an electronic device 902 via a first network 998 (e.g., a short-range wireless communication network), or communicate with an electronic device 904 or a server 908 via a second network 999 (e.g., a long-range wireless communication network). The electronic device 901 may communicate with the electronic device 904 via the server 908. The electronic device 901 may include a processor 920, a memory 930, an input device 950, a sound output device 955, a display device 960, an audio module 970, a sensor module 976, an interface 977, a haptic module 979, a camera module 980, a power management module 988, a battery 989, a communication module 990, a subscriber identification module (SIM) 996, or an antenna module 997 including a global navigation satellite system (GNSS) antenna. In one embodiment, at least one of the components (e.g., display device 960 or camera module 980) may be omitted from electronic device 901, or one or more other components may be added to electronic device 901. In one embodiment, some components may be implemented as a single IC. For example, sensor module 976 (e.g., fingerprint sensor, iris sensor, or illumination sensor) may be embedded in display device 960 (e.g., display).

[0094] The processor 920 may execute, for example, software (e.g., program 940) to control at least one other component (e.g., hardware or software component) of the electronic device 901 coupled to the processor 920, and may perform various data processing or calculations. As at least part of the data processing or calculation, the processor 920 may load a command or data received from another component (e.g., sensor module 976 or communication module 990) into the volatile memory 932, process the command or data stored in the volatile memory 932, and store the resulting data in the non-volatile memory 934. The processor 920 may include a main processor 921 (e.g., a central processing unit (CPU) or an application processor) and an auxiliary processor 923 (e.g., a graphics processing unit (GPU), an image signal processor (ISP), a sensor hub processor, or a communication processor (CP)), and the auxiliary processor 923 may operate independently of the main processor 921 or in conjunction with the main processor 921. Additionally or alternatively, the auxiliary processor 923 may be adapted to consume less power than the main processor 921, or to perform a specific function. The auxiliary processor 923 may be implemented separately from the main processor 921 or as a part of the main processor 921 .

[0095] The auxiliary processor 923 may replace the main processor 921 when the main processor 921 is in an inactive (e.g., sleep) state, or control at least some of the functions or states related to at least one of the components of the electronic device 901 (e.g., the display device 960, the sensor module 976, or the communication module 990) together with the main processor 921 when the main processor 921 is in an active state (e.g., executing an application). According to one embodiment, the auxiliary processor 923 (e.g., an image signal processor or a communication processor) may be implemented as part of another component (e.g., a camera module 980 or a communication module 990) that is functionally related to the auxiliary processor 923.

[0096] The memory 930 may store various data used by at least one component of the electronic device 901 (e.g., the processor 920 or the sensor module 976). The various data may include, for example, software (e.g., program 940) and input data or output data for commands related thereto. The memory 930 may include a volatile memory 932 or a nonvolatile memory 934.

[0097] The program 940 may be stored as software in the memory 930 , and may include, for example, an operating system (OS) 942 , middleware 944 , or an application 946 .

[0098] The input device 950 may receive commands or data to be used by other components (eg, the processor 920) of the electronic device 901 from outside the electronic device 901 (eg, a user). The input device 950 may include, for example, a microphone, a mouse, or a keyboard.

[0099] The sound output device 955 can output sound signals to the outside of the electronic device 901. The sound output device 955 may include, for example, a speaker or a receiver. The speaker may be used for general purposes, such as playing multimedia or recording, and the receiver may be used to receive incoming calls. According to one embodiment, the receiver may be implemented as a part of the speaker or as a part of the speaker.

[0100] The display device 960 can visually provide information to the outside of the electronic device 901 (e.g., a user). The display device 960 may include, for example, a display, a hologram device, or a projector, and a control circuit for controlling a corresponding one of the display, the hologram device, and the projector. According to one embodiment, the display device 960 may include a touch circuit suitable for detecting a touch or a sensor circuit (e.g., a pressure sensor) suitable for measuring the strength of the force caused by the touch.

[0101] The audio module 970 can convert sound into an electrical signal, and vice versa. According to one embodiment, the audio module 970 can obtain sound via the input device 950, or output sound via the sound output device 955 or the earphone of the external electronic device 902 directly (e.g., wired) or wirelessly coupled to the electronic device 901.

[0102] The sensor module 976 may detect an operating state (e.g., power or temperature) of the electronic device 901 or an environmental state (e.g., a user's state) outside the electronic device 901, and then generate an electrical signal or data value corresponding to the detected state. The sensor module 976 may include, for example, a gesture sensor, a gyroscope sensor, an atmospheric pressure sensor, a magnetic sensor, an acceleration sensor, a grip sensor, a proximity sensor, a color sensor, an infrared (IR) sensor, a biometric sensor, a temperature sensor, a humidity sensor, or an illumination sensor.

[0103] The interface 977 may support one or more designated protocols for the electronic device 901 to be directly (e.g., wired) or wirelessly coupled to the external electronic device 902. According to one embodiment, the interface 977 may include, for example, a high-definition multimedia interface (HDMI), a universal serial bus (USB) interface, a secure digital (SD) card interface, or an audio interface.

[0104] The connection terminal 978 may include a connector via which the electronic device 901 can be physically connected to the external electronic device 902. According to one embodiment, the connection terminal 978 may include, for example, an HDMI connector, a USB connector, an SD card connector, or an audio connector (eg, a headphone connector).

[0105] The haptic module 979 may convert the electrical signal into mechanical stimulation (eg, vibration or movement) or electrical stimulation that can be recognized by the user via tactile sensation or kinesthetic sensation. According to one embodiment, the haptic module 979 may include, for example, a motor, a piezoelectric element, or an electrical stimulator.

[0106] The camera module 980 may capture still images or moving images. According to one embodiment, the camera module 980 may include one or more lenses, image sensors, image signal processors, or flashes.

[0107] The power management module 988 may manage power supplied to the electronic device 901. The power management module 988 may be implemented as, for example, at least a portion of a power management integrated circuit (PMIC).

[0108] The battery 989 may supply power to at least one component of the electronic device 901. According to one embodiment, the battery 989 may include, for example, a non-rechargeable primary battery, a rechargeable secondary battery, or a fuel cell.

[0109] The communication module 990 can support establishing a direct (e.g., wired) communication channel or a wireless communication channel between the electronic device 901 and an external electronic device (e.g., electronic device 902, electronic device 904, or server 908), and perform communication via the established communication channel. The communication module 990 may include one or more communication processors, which may operate independently of the processor 920 (e.g., an application processor) and support direct (e.g., wired) communication or wireless communication. According to one embodiment, the communication module 990 may include a wireless communication module 992 (e.g., a cellular communication module, a short-range wireless communication module, or a GNSS communication module) or a wired communication module 994 (e.g., a local area network (LAN) communication module or a power line communication (PLC) module). The corresponding communication modules among these communication modules may communicate via a first network 998 (e.g., a short-range communication network such as Bluetooth). TM, Wireless Fidelity (Wi-Fi) Direct, or Infrared Data Association (IrDA) standards) or a second network 999 (e.g., a remote communication network such as a cellular network, the Internet, or a computer network (e.g., a LAN or a wide area network (WAN)) to communicate with an external electronic device. These various types of communication modules may be implemented as a single component (e.g., a single IC), or may be implemented as multiple components (e.g., multiple ICs) separated from each other. The wireless communication module 992 may use subscriber information (e.g., an International Mobile Subscriber Identity (IMSI)) stored in the subscriber identification module 996 to identify and authenticate the electronic device 901 in a communication network (such as a first network 998 or a second network 999).

[0110] The antenna module 997 may transmit or receive a signal or power to or from the outside of the electronic device 901 (e.g., an external electronic device). According to one embodiment, the antenna module 997 may include one or more antennas, and thus, at least one antenna suitable for a communication scheme used in a communication network such as the first network 998 or the second network 999 may be selected, for example, by the communication module 990 (e.g., the wireless communication module 992). Then, a signal or power may be transmitted or received between the communication module 990 and the external electronic device via the selected at least one antenna.

[0111] At least some of the above components can be coupled to each other and transmit signals (e.g., commands or data) therebetween via an inter-peripheral communication scheme (e.g., a bus, general purpose input and output (GPIO), serial peripheral interface (SPI), or mobile industry processor interface (MIPI)).

[0112] According to one embodiment, commands or data may be sent or received between the electronic device 901 and the external electronic device 904 via a server 908 coupled to the second network 999. Each of the electronic devices 902 and 904 may be a device of the same type or a different type as the electronic device 901. All or some of the operations to be performed at the electronic device 901 may be performed at one or more of the external electronic devices 902, 904 or the server 908. For example, if the electronic device 901 should automatically or in response to a request from a user or another device to perform a function or service, the electronic device 901 may not perform a function or service but request one or more external electronic devices to perform at least a part of the function or service, or may request one or more external electronic devices to perform at least a part of the function or service in addition to performing the function or service. The one or more external electronic devices receiving the request may perform at least a part of the requested function or service, or an additional function or additional service related to the request, and transmit the result of the execution to the electronic device 901. The electronic device 901 may provide the result with or without further processing the result as at least a part of the reply to the request. For this purpose, for example, cloud computing, distributed computing or client-server computing technology may be used.

[0113] One embodiment may be implemented as software (e.g., program 940) including one or more instructions stored in a storage medium (e.g., internal memory 936 or external memory 938) readable by a machine (e.g., electronic device 901). For example, the processor of the electronic device 901 may call at least one of the one or more instructions stored in the storage medium and execute it under the control of the processor with or without one or more other components. Thus, the machine may be operated to perform at least one function according to at least one instruction called. The one or more instructions may include code generated by a compiler or code executable by an interpreter. The machine-readable storage medium may be provided in the form of a non-transitory storage medium. The term "non-transitory" indicates that the storage medium is a tangible device and does not include signals (e.g., electromagnetic waves), but the term does not distinguish between a case where data is semi-permanently stored in a storage medium and a case where data is temporarily stored in a storage medium.

[0114] According to one embodiment, the method of the present disclosure may be included and provided in a computer program product. The computer program product may be traded between a seller and a buyer as a product. The computer program product may be distributed in the form of a machine-readable storage medium (e.g., a compact disc read-only memory (CD-ROM)), or distributed online (e.g., downloaded or uploaded) via an application store (e.g., Play StoreTM), or distributed directly between two user devices (e.g., smart phones) (e.g., downloaded or uploaded). If distributed online, at least a portion of the computer program product may be temporarily generated or at least temporarily stored in a machine-readable storage medium, such as a memory of a manufacturer's server, a server of an application store, or a relay server.

[0115] According to one embodiment, each component (e.g., module or program) of the above-mentioned components may include a single entity or multiple entities. One or more of the above-mentioned components may be omitted, or one or more other components may be added. Alternatively or additionally, multiple components (e.g., modules or programs) may be integrated into a single component. In this case, the integrated component may still perform one or more functions of each component of the multiple components in the same or similar manner as performed by the corresponding components of the multiple components before integration. The operations performed by a module, program or another component may be performed sequentially, in parallel, repeatedly or heuristically, or one or more of the operations may be performed or omitted in a different order, or one or more other operations may be added.

[0116] Although certain embodiments of the present disclosure have been described in the detailed description of the present disclosure, the present disclosure may be modified in various forms without departing from the scope of the present disclosure. Therefore, the scope of the present disclosure should not be determined based solely on the described embodiments, but rather on the appended claims and their equivalents.

Claims

1. A system for managing arbitration and command acquisition in a data communication system, comprising: Input channel, which is configured to issue commands; as well as The controller is configured as: determining that the number of command requests is greater than or equal to a minimum acquisition threshold or the number of resources receiving the command requests is greater than or equal to a resource threshold, and In response to the number of the command requests being greater than or equal to the minimum acquisition threshold or the number of resources receiving the command requests being greater than or equal to the resource threshold, sending the command request.

2. The system according to claim 1, wherein: The controller is also configured to: Initialize the wait timer, and In response to the wait timer being greater than or equal to a predetermined wait duration, sending the command request.

3. The system according to claim 2, wherein: The predetermined waiting time duration is greater than the arbitration time and the minimum acquisition time.

4. The system according to claim 1, wherein: The minimum acquisition threshold is based on a number of upstream command requests, and the resource threshold is based on a number of downstream resources.

5. The system according to claim 4, wherein: The command request is sent in response to the number of upstream command requests and the number of downstream resources being greater than or equal to the minimum acquisition threshold.

6. The system according to claim 1, wherein: The minimum acquisition threshold is calculated based on the acquired values ​​performed.

7. The system according to claim 6, wherein: The controller is also configured to: In response to the executed fetch value being less than the minimum fetch threshold due to a no-op, the minimum fetch threshold is increased.

8. The system according to claim 6, wherein: The controller is also configured to: In response to the executed acquisition value being greater than the minimum acquisition threshold or in response to the executed resource count being greater than the executed resource threshold, the minimum acquisition threshold is decreased.

9. The system according to claim 1, wherein: The input channels include a plurality of input channels having a wait time duration.

10. The system according to claim 1, wherein: The controller is also configured to: In response to the host queue depth being less than the minimum get threshold, disabling or reducing the minimum get threshold.

11. A method for managing arbitration and command acquisition in a data communication system, the method comprising: determining that the number of command requests is greater than or equal to a minimum acquisition threshold or the number of resources receiving the command requests is greater than or equal to a resource threshold, and In response to the number of the command requests being greater than or equal to the minimum acquisition threshold or the number of resources receiving the command requests being greater than or equal to the resource threshold, sending the command request.

12. The method according to claim 11, further comprising: Initialize the wait timer, and In response to the wait timer being greater than or equal to a predetermined wait duration, sending the command request.

13. The method according to claim 12, wherein: The predetermined waiting time duration is greater than the arbitration time and the minimum acquisition time.

14. The method according to claim 11, wherein: The minimum acquisition threshold is based on a number of upstream command requests, and the resource threshold is based on a number of downstream resources.

15. The method according to claim 14, wherein: The command request is sent in response to the number of upstream command requests and the number of downstream resources being greater than or equal to the minimum acquisition threshold.

16. The method according to claim 11, wherein: The minimum acquisition threshold is calculated based on the acquired values ​​performed.

17. The method according to claim 16, further comprising: In response to the executed fetch value being less than the minimum fetch threshold due to a no-op, the minimum fetch threshold is increased.

18. The method according to claim 16, further comprising: In response to the executed acquisition value being greater than the minimum acquisition threshold or in response to the executed resource count being greater than the executed resource threshold, the minimum acquisition threshold is decreased.

19. The method according to claim 11, wherein: The input channels include a plurality of input channels having a wait duration.

20. The method according to claim 11, further comprising: In response to the host queue depth being less than the minimum get threshold, disabling or reducing the minimum get threshold.

Images