CN114185823B - Arbiter, arbitration method, controller and chip - Google Patents
Arbiter, arbitration method, controller and chip Download PDFInfo
- Publication number
- CN114185823B CN114185823B CN202210144746.4A CN202210144746A CN114185823B CN 114185823 B CN114185823 B CN 114185823B CN 202210144746 A CN202210144746 A CN 202210144746A CN 114185823 B CN114185823 B CN 114185823B
- Authority
- CN
- China
- Prior art keywords
- access
- access request
- sent
- request
- count
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/14—Handling requests for interconnection or transfer
- G06F13/16—Handling requests for interconnection or transfer for access to memory bus
- G06F13/1605—Handling requests for interconnection or transfer for access to memory bus based on arbitration
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2213/00—Indexing scheme relating to interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F2213/0038—System on Chip
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2213/00—Indexing scheme relating to interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F2213/36—Arbitration
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Small-Scale Networks (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The disclosure relates to an arbiter, an arbitration method, a controller and a chip. Disclosed is an arbiter for a multi-port accessible device, comprising: a request port number determination module configured to determine whether there is an access request to be sent at one or more ports; a device access type obtaining module configured to obtain a device access type; the access request characteristic acquisition module is configured to acquire the access type and the urgency of each access request to be sent; and an arbitration execution module configured to perform the following: determining an access request to be sent as a candidate access request if the access request is available at only one port; or if a plurality of corresponding access requests to be sent exist at a plurality of ports, determining at least one priority access request from the plurality of access requests to be sent according to the equipment access type and the urgency degree of each access request, and determining candidate access requests from the priority access requests.
Description
Technical Field
The present disclosure relates generally to an implementation of arbitration. And in particular to an arbiter, arbitration method, controller and chip for a multi-port accessible device.
Background
In recent years, the integrated circuit industry has been rapidly developing with increased policy guidance and market demand. Among them, in a micro integrated circuit System such as an SOC (System On Chip), there is a case where a plurality of components such as a Central Processing Unit (CPU), an Information Processor (IP), and the like share a multi-port accessible device such as a memory through a port bus. In general, the efficiency of access by a multi-port accessible device has a significant impact on overall system performance. In fact, as the speed of the CPU core increases, the speed gap between the CPU core and the memory gradually increases, so that the memory increasingly becomes one of the bottlenecks that restrict the system performance. Therefore, improving the access efficiency of a multi-port accessible device is significant to improving the overall performance of the system.
Disclosure of Invention
According to an aspect of the present disclosure, there is provided an arbiter for a multi-port accessible device, comprising: the device comprises a request port number determining module, a request port number determining module and a processing module, wherein the request port number determining module is configured to judge whether an access request to be sent is available at one port or a plurality of ports, and the access request to be sent refers to an access request which is sent to equipment firstly in each request port with the access request which is not sent; a device access type acquisition module configured to acquire a device access type indicating an access type of a latest access to a device; the access request feature acquisition module is configured to acquire an access type and an urgency degree of each access request to be sent, wherein the access type of the access request comprises a first access type which is the same as the device access type and a second access type which is different from the device access type; and an arbitration execution module configured to perform the following: if the access request to be sent exists at only one port, determining the access request as a candidate access request to be sent to the equipment firstly among the access requests to be sent; or if a plurality of corresponding access requests to be sent exist at a plurality of ports, determining at least one priority access request with the highest current priority from the plurality of access requests to be sent according to the equipment access type and the urgency degree of each access request, and determining candidate access requests from the at least one priority access request.
According to another aspect of the present disclosure, there is provided a controller for a multi-port accessible device, comprising an arbiter as described above, configured to determine a candidate access request from one or more access requests to be transmitted; a credit distributor configured to grant credit to the determined candidate access request when the device is in an accessible state; and a selector configured to receive a gating signal for a port on which an access request with credit is located to transmit the access request to the device through the port.
According to another aspect of the present disclosure, there is provided a chip including the arbiter or the controller as described above.
According to yet another aspect of the present disclosure, there is provided an arbitration method of a multi-port accessible device, comprising: judging whether an access request to be sent exists at one port or a plurality of ports, wherein the access request to be sent refers to an access request which is sent to equipment firstly in each request port with the access request which is not sent; if the access request to be sent exists at only one port, determining the access request as a candidate access request to be sent to the equipment firstly among the access requests to be sent; or if a plurality of corresponding access requests to be sent exist at a plurality of ports, acquiring a device access type representing the access type of the latest access to the device; acquiring an access type and an emergency degree of each access request to be sent, wherein the access type of each access request comprises a first access type which is the same as an equipment access type and a second access type which is different from the first access type; determining at least one priority access request with the highest current priority from the multiple access requests to be sent according to the equipment access type and the emergency degree of each access request; and determining a candidate access request from the at least one priority access request.
Other features of the present disclosure and advantages thereof will become more apparent from the following detailed description of exemplary embodiments thereof, which proceeds with reference to the accompanying drawings.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the disclosure and together with the description, serve to explain the principles of the disclosure.
The present disclosure may be more clearly understood from the following detailed description, taken with reference to the accompanying drawings, in which:
fig. 1 is a schematic diagram illustrating an example of a configuration of a controller and its arrangement with respect to a multi-port accessible device according to an embodiment of the present disclosure.
Fig. 2A is a schematic diagram illustrating an example of a configuration of an arbiter according to an embodiment of the present disclosure.
Fig. 2B is a schematic diagram illustrating an example of a configuration of an access request feature acquisition module according to an embodiment of the present disclosure.
Fig. 3 is a flow chart illustrating an example of an arbitration method according to an embodiment of the present disclosure.
Fig. 4 is a flowchart illustrating an example of sub-steps of the step of determining a priority access request according to an embodiment of the present disclosure.
Fig. 5 is a schematic diagram illustrating hold and switch access types according to an embodiment of the present disclosure.
FIG. 6 illustrates a schematic diagram of reordering multiple access requests to the same port, according to an embodiment of the disclosure.
Note that in the embodiments described below, the same reference numerals are used in common between different drawings to denote the same portions or portions having the same functions, and a repetitive description thereof will be omitted. In some cases, similar reference numbers and letters are used to denote similar items, and thus, once an item is defined in one figure, it need not be discussed further in subsequent figures.
For convenience of understanding, the positions, sizes, ranges, and the like of the respective structures shown in the drawings and the like do not sometimes indicate actual positions, sizes, ranges, and the like. Therefore, the present disclosure is not limited to the positions, dimensions, ranges, and the like disclosed in the drawings and the like.
Detailed Description
The inventors of the present application have recognized that multi-port accessible devices (e.g., multi-port memories) also face significant challenges in improving access efficiency. In particular, the inventors of the present application have recognized that in addition to improving the access efficiency of a multi-port accessible device by optimizing its own structure, efficiency may be further improved by improving the arbitration implementation of multi-port access.
Various exemplary embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings. It should be noted that: the relative arrangement of the components and steps, the numerical expressions, and numerical values set forth in these embodiments do not limit the scope of the present disclosure unless specifically stated otherwise.
The following description of at least one exemplary embodiment is merely illustrative in nature and is in no way intended to limit the disclosure, its application, or uses. That is, the structures and methods herein are shown by way of example to illustrate different embodiments of the structures and methods of the present disclosure. Those skilled in the art will understand, however, that they are merely illustrative of exemplary ways in which the disclosure may be practiced and not exhaustive. Furthermore, the figures are not necessarily to scale, some features may be exaggerated to show details of particular components.
Techniques, methods, and apparatus known to those of ordinary skill in the relevant art may not be discussed in detail but are intended to be part of the specification where appropriate.
In all examples shown and discussed herein, any particular value should be construed as merely illustrative, and not limiting. Thus, other examples of the exemplary embodiments may have different values.
Fig. 1 schematically depicts an example of a configuration of a controller and its arrangement with respect to a multi-port accessible device according to an embodiment of the disclosure.
According to an embodiment of the disclosure, the controller 110 for the multi-port accessible device 120 may include an arbiter 112, a credit distributor 114, and a selector 116.
In some embodiments, the multi-port accessible device 120 may be a memory. For example, the multi-port accessible device 120 may be a multi-port SRAM.
In some cases, the multi-port accessible device 120 may be an on-chip device.
In various embodiments, the arbiter 112 may be configured to determine a candidate access request to be first transmitted to a device from among the respective one or more pending access requests from one or more ports 130-0, 130-1, … … 130-n.
The access request to be sent refers to an access request to be sent to the device first in each request port having an access request that is not sent. That is, the access request to be sent is the first access request in the order of one or more access requests that have not yet been sent to the device in each request port. In general, the access request to be sent is the earliest received access request in each request port.
In some embodiments, the arbiter 112 may be configured to perform the steps of an arbitration method for a multi-port accessible device, which will be described later in connection with fig. 3.
In various embodiments, the credit distributor 114 may be configured to grant credit to the determined candidate access requests while the device is in the accessible state.
In some embodiments, credits may be granted to the determined candidate access requests by sending a credit flag, symbol, or other signal to arbiter 112.
Wherein the device being in the accessible state means that the last access to the device has been completed, enabling the next access to the device.
That is, while the device 120 is performing access processing, even if the arbiter 112 determines a current candidate access request, the credit distributor 114 does not grant credit to the determined candidate access request, and cannot transmit it from the corresponding port to the device 120 via the controller 110. Advantageously, this credit mechanism enables control of the data flow between the port and the controller to avoid backend device 120 bus collisions.
In various embodiments, the selector 116 may be configured to receive a gating signal for a port on which an access request with credit is located to send the access request to the device 120 through the port.
For example, in some embodiments, the selector 116 may be implemented by a Multiplexer (MUX). Arbiter 112 may send a strobe signal to selector 116 for the port on which the access request with credit is located, thereby allowing the transmission path of the access request with credit to conduct so that the access request with credit can be sent to device 120.
An example of the configuration of the arbiter 112 will be described in detail below in conjunction with fig. 2A-2B.
Fig. 2A exemplarily depicts an example of a configuration of an arbiter according to an embodiment of the present disclosure.
The arbiter 112 for a multi-port accessible device 120 according to embodiments of the present disclosure includes a request port number determination module 210, a device access type acquisition module 220, an access request feature acquisition module 230, and an arbitration execution module 240.
In various embodiments, the request port number determination module 210 may be configured to determine whether there is an access request pending at one or more ports. As described above, the access request to be transmitted may refer to an access request to be transmitted to the device first among the respective request ports having an access request that is not transmitted.
In various embodiments, device access type acquisition module 220 may be configured to acquire a device access type representing an access type of a last access to a device.
Generally, access to a device may include read access and write access.
In various embodiments, the access request feature obtaining module 230 may be configured to obtain an access type and an urgency of each access request to be sent.
Wherein the access type of the access request may include a first access type that is the same as the device access type and a second access type that is different therefrom.
For example, if the device access type is a read access, then the first access type refers to a read access and the second access type refers to a write access. In contrast, if the device access type is write access, the first access type refers to write access and the second access type refers to read access.
Further, the urgency of the access request may include information indicating its importance, waiting time, and the like.
In particular, an example of the configuration of the access request feature acquisition module 230 will be specifically described below in conjunction with fig. 2B. Fig. 2B is a schematic diagram illustrating an example of a configuration of an access request feature acquisition module according to an embodiment of the present disclosure.
As shown in fig. 2, the access request feature obtaining module 230 includes an initialization unit 232, an aging unit 234, and an access request type obtaining unit 236.
In various embodiments, the initialization unit 232 may be configured to initialize the ordered count of the access request when an unsent access request becomes an access request to be sent.
Wherein the initialized value of the ordered count may be associated with a preset priority of the access request.
The preset priority of the access request may be configured to reflect the importance of the access request itself such that: the higher the importance of the access request, the higher the pre-set priority. For example, the preset priority of the access request from the CPU may be configured to be higher than the preset priority of the access request from the other master device.
By initializing the ordered count of access requests by a preset priority, the importance of the access requests themselves may be fully taken into account in the reordering of the access requests.
In various embodiments, the aging unit 234 may be configured to decrement the rank count of the access request to be sent according to the increase in latency to obtain an updated rank count representing the urgency until the updated rank count reaches the absolute minimum rank count.
In some embodiments, the aging unit 234 may use a common clock signal. Alternatively, in other embodiments, the aging unit 234 may use a dedicated clock signal.
For ease of understanding and description herein, the relationship of the rank count to the rank (urgency) is set as: the smaller the ranking count, the more advanced the ranking, and the higher the urgency. Those skilled in the art will readily appreciate that the manner in which the relationship is set is not limited thereto.
In some embodiments, the initialization value of the sequencing count may be set to a positive integer. For example, the initialization value of the sort count of an access request from the CPU is 2, and the initialization value of the sort count of an access request from another master is 4.
In some embodiments, the aging module 234 may decrement the sequencing count by 1 each time.
Also, for convenience of description, the absolute minimum sorting count may be set to 0.
Once the updated sort count reaches the absolute minimum sort count (0), it will remain at the absolute minimum sort count and not be decremented.
Those skilled in the art will readily understand that the values of the countdown and absolute minimum sort count are not limited to the above examples, but may be set according to actual requirements.
Furthermore, in various embodiments, the access request type obtaining unit 236 may be configured to obtain an access type of an access request to be sent.
Those skilled in the art will readily appreciate that what has been described above in connection with fig. 2B is merely one example, and the configuration of the access request feature acquisition module 230 is not limited thereto.
In various embodiments, arbitration execution module 240 may be configured to perform the following: or if a plurality of corresponding access requests to be sent exist at a plurality of ports, determining at least one prior access request with the highest current priority from the plurality of access requests to be sent according to the access type of the equipment and the access type and the urgency degree of each access request, and determining the candidate access request from the at least one prior access request.
In some embodiments, the arbitration execution module may determine the candidate access request from the at least one priority access request using a Round-robin (Round-robin) process.
Those skilled in the art will readily appreciate that the manner in which the candidate access request is determined from the at least one priority access request is not limited thereto.
Furthermore, the applicant has appreciated that a bus port generally needs to be subjected to timing conversion when performing data interaction with an interface of a multi-port accessible device (e.g. SRAM), and when performing access type switching (e.g. read-write switching), in order to ensure that the timing of the device interface is accurate, the bus port may be back-pressed by a ready (ready) signal to wait for the phase relationship between the device interface address bus and the data bus to be accurate correspondingly. That is, timing transitions when switching access types typically result in wasted bandwidth.
Thus, in some embodiments, the arbitration execution module 240 determines the priority access request comprises determining the access request of the first access type as the priority access request preferentially to reduce switching of access types, thereby reducing bandwidth waste. The access type hold and switch case will be described in detail below with reference to fig. 5.
In some embodiments, arbitration execution module 240 may be configured to perform sub-steps of the steps for determining priority access requests described later in connection with fig. 4.
It should be noted that the above-mentioned devices, modules or units are only logic modules divided according to the specific functions implemented by them, and are not limited to the specific implementation manner, and can be implemented in software, hardware or a combination of software and hardware, for example. In the course of actual implementation, the various devices, modules or units described above may be implemented as separate physical entities or may also be implemented by a single entity (e.g., a processor (CPU or DSP, etc.), an integrated circuit, etc.). If the various devices, modules or units are implemented as separate physical entities, they may be deployed together or separately from each other.
Advantageously, the arbiter 112 according to the embodiment of the present disclosure may flexibly adjust the arbitration policy according to the number of request ports having an access request to be transmitted, and comprehensively consider both the urgency of the access request and the bandwidth cost of switching the access type in case of a plurality of request ports to determine a currently more preferable candidate access request. Accordingly, the controller 110 according to an embodiment of the present disclosure may grant a credit to the latest candidate access request after the device enters the accessible state, thereby transmitting the most urgent access request in the current situation to the device on the premise of maximally utilizing the bandwidth. Here, by setting the preset priority, the urgency of the access request can reflect both the importance of the access request itself and the waiting time. Therefore, the priority transmission of the data of the CPU main port is ensured, and the condition that other ports are starved can be effectively prevented. Therefore, the technical scheme of the disclosure can greatly improve the access efficiency of the multi-port accessible device.
The steps of an arbitration method for a multi-port accessible device according to an embodiment of the present disclosure are exemplarily described below with reference to fig. 3, 4, variations of access types of the multi-port accessible device are schematically described with reference to fig. 5, and an exemplary description of reordering multiple access requests of the same port according to an embodiment of the present disclosure is given with reference to fig. 6. What has been described above in connection with fig. 1, 2A-2B may also be applied to the corresponding features.
As shown in fig. 3, an arbitration method 300 for a multi-port accessible device according to an embodiment of the present disclosure may essentially comprise the steps of:
at step 302, it is determined whether there is an access request pending at one or more ports. As described above, the access request to be transmitted may refer to an access request to be transmitted to the device first among the respective request ports having an access request that is not transmitted.
If there are access requests to send at only one port ("one" in step 302), then the access requests are determined to be candidate access requests that will be sent first to the device among the access requests to send (step 304).
Conversely, if there are a corresponding plurality of access requests to be sent ("multiple" in step 302) at the plurality of ports, the following process including step 306, step 308, step 310, and step 312 is performed.
At step 306, a device access type representing the access type of the last access to the device is obtained.
In step 308, the access type and urgency of each access request to be sent are obtained. As described above, the access type of the access request includes the first access type which is the same as the device access type and the second access type which is different therefrom.
At step 310, at least one prior access request with the highest current priority is determined from the multiple access requests to be sent according to the device access type and the urgency level of each access request.
At step 312, a candidate access request is determined from the at least one priority access request.
In some embodiments, the above steps may be repeatedly performed when parameters such as the number of request ports, the device access type, and the access type and urgency of the access request are changed, or may be periodically repeated to accurately and timely determine the candidate access request. Alternatively, in some embodiments, the above steps may be performed only after the device enters the accessible state, to save overhead.
In some embodiments, obtaining the urgency of each access request to be sent in step 308 includes initializing a sorted count of the access requests that are not sent when the access requests become access requests to be sent. Wherein the initialized value of the ordered count is associated with the predetermined priority of the access request.
Additionally, obtaining the urgency of each access request to be sent in step 308 further includes decrementing the rank count of the access request to be sent according to the increase in latency to obtain an updated rank count representing the urgency until the updated rank count reaches the absolute minimum rank count.
As described above, the preset priority of the access request may be configured to reflect the importance of the access request itself such that: the higher the importance of the access request, the higher the pre-set priority. By initializing the ordered count of access requests by a preset priority, the importance of the access requests themselves may be fully taken into account in the reordering of the access requests.
For ease of understanding and description herein, the relationship of the rank count to the rank (urgency) is set as: the smaller the ranking count, the more advanced the ranking, and the higher the urgency. Those skilled in the art will readily appreciate that the manner in which the relationship is set is not limited thereto.
In some embodiments, the initialization value of the sort count may be set to a positive integer. For example, the initialization value of the sort count of an access request from the CPU is set to 2, and the initialization value of the sort count of an access request from another master is set to 4.
In some embodiments, the sequencing count may be decremented by 1 at a time.
Also, for convenience of description, the absolute minimum sorting count may be set to 0.
Once the updated sort count reaches the absolute minimum sort count (0), the sort count is no longer decremented.
It will be readily appreciated by those skilled in the art that the values of the countdown and absolute minimum sort count are not limited to the above examples, but may be set according to actual requirements.
As noted above, applicants have appreciated that switching access types generally results in wasted bandwidth.
Thus, in some embodiments, determining a priority access request (step 310) includes determining an access request of the first access type as a priority access request preferentially to reduce switching of access types, thereby reducing bandwidth waste.
Further, in some embodiments, in step 312, a polling process may be used to determine a candidate access request from the at least one priority access request.
An example of the sub-steps of the step of determining a priority access request (step 310) is described in detail below in conjunction with fig. 4.
As illustrated in fig. 4, in some embodiments, it is first determined whether there is an access request of a first access type having an absolute minimum sorted count among a plurality of access requests to be sent (sub-step 402).
If there is an access request of the first access type having the absolute minimum sorting count ("yes" in sub-step 402), the access request of the first access type having the absolute minimum sorting count is determined as a priority access request.
That is, if the updated ordered count of one or more access requests of the first access type among the plurality of access requests to be sent reaches the absolute minimum ordered count, the one or more access requests of the first access type are determined to be priority access requests.
Conversely, if there is no access request of the first access type with the absolute minimum sorted count ("no" in sub-step 402), then processing proceeds to sub-step 404.
In sub-step 404, it is further determined whether there is an access request of the second access type with the absolute minimum sorted count among the plurality of access requests to be sent.
If there is an access request of the second access type having the absolute minimum sorting count ("yes" in sub-step 404), the access request of the second access type having the absolute minimum sorting count is determined to be a priority access request.
That is, if the updated ordering count of only one or more access requests of the second access type among the plurality of access requests to be transmitted reaches the absolute minimum ordering count, the one or more access requests of the second access type are determined as priority access requests.
Conversely, if there is also no access request of the second access type with the absolute minimum sorted count ("no" in sub-step 404), then processing proceeds to sub-step 406.
As can be seen from the above example steps, according to the technical solution of the present disclosure, among all the access requests to be sent, the access request with the absolute minimum sorted count has the highest priority. Furthermore, the priority of an access request of the first access type having the absolute minimum sorting count is higher than the priority of an access request of the second access type having the absolute minimum sorting count. By the strategy, the access request with the highest urgency degree can be preferentially executed, and meanwhile, the switching of the access types is reduced as much as possible so as to save cost.
In sub-step 406, it is determined whether there is an access request of the first access type.
If there is no access request of the first access type ("no" in sub-step 406), an access request of the second access type having a relatively minimum sorted count is determined to be a priority access request.
Conversely, if there is an access request of the first access type ("yes" in sub-step 406), then processing proceeds to sub-step 408.
In sub-step 408, it is determined whether there is an access request of the second access type.
If there is no access request of the second access type ("no" in sub-step 408), the access request of the first access type having the relatively smallest sorted count is determined to be a priority access request.
As can be seen from the above steps, if the access requests to be sent have the same access type, the access request with the relatively smallest sorting count is determined as the priority access request.
Conversely, if there is also an access request of the second access type ("yes" in sub-step 408), then processing proceeds to sub-step 410.
In sub-step 410, a difference is calculated between the updated ordering count of the access request of the first access type having the relatively smallest ordering count and the updated ordering count of the access request of the second access type having the relatively smallest ordering count, and a priority access request is determined based on a comparison of the difference with the switching threshold.
Specifically, as shown in fig. 4, if the difference is less than or equal to the switching threshold ("no" in sub-step 410), an access request of the first access type having a relatively smallest sorting count is determined as a priority access request.
Conversely, if the difference is greater than the switching threshold ("yes" in sub-step 410), then the access request of the second access type having the relatively smallest sorted count is determined to be a priority access request.
Wherein the switching threshold may be not less than zero.
In some embodiments, the switching threshold may be zero. In this case, an access request of the second access type having a relatively smallest sorting count is determined as a priority access request only if the access request of the first access type has a relatively smallest sorting count larger than the relatively smallest sorting count of the access request of the second access type.
Alternatively, in some embodiments, the handover threshold may be greater than zero. For example, in one embodiment, the handover threshold may be set to 1. In this case, an access request of the second access type having a relatively minimum sorting count is determined to be a priority access request only if the access request of the first access type has a relatively minimum sorting count exceeding the relative minimum sorting count of the access request of the second access type by a switching threshold (e.g., 1).
As can be seen from the above example steps, according to the technical solution of the present disclosure, when there is no access request with the absolute minimum sorting count, among the access requests of each access type, the access request with the relative minimum sorting count has the highest priority. Further, when there is no access request with the absolute minimum sort count, the relationship between the priorities P21, P22 of the access requests of the second access type with the update sort count of C, C +1 and the priority P1 of the access request of the first access type with the update sort count of (C +1+ C _ TH) is P21> P1> P22, where C _ TH represents the switching threshold. From "no" in step 410, it is understood that P1 has higher priority than P22, and thus the number of handovers can be reduced as much as possible. From "yes" in step 410, it can be seen that P21 has a higher priority than P1. By this policy, when an access request with a less urgent degree is executed, it is possible to pay more attention to reducing switching of access types while preferentially executing an access request with a higher urgent degree to save bandwidth cost.
Those skilled in the art will readily appreciate that although examples of sub-steps of the step of determining a priority access request are described above in connection with fig. 4, the implementation of determining a priority access request is not limited to the specific steps shown above, but may be designed, modified and adapted as desired. For example, the order of the sub-steps in sub-steps 402 and 408 may be adjusted without affecting the acknowledgement of the priority access request.
It is noted that the boundaries between the various steps of the method described above are merely illustrative. In actual practice, the steps can be combined arbitrarily, and even a single step can be synthesized. In addition, the execution order of the respective steps is not limited by the description order, and some steps may be omitted. The operational steps of the various embodiments may also be combined with one another in any suitable order to similarly implement more or less operations than those described.
Fig. 5 shows a schematic diagram of hold and switch access types according to an embodiment of the present disclosure.
If the priority access request determined while the device is in the accessible state is an access of the first access type, the device may continue with an access of the first access type.
In contrast, if the priority access request determined while the device is in the accessible state is an access of the second access type, the device needs to switch to an access of the second access type.
Specifically, as can be seen from the result of determining the priority access request shown in fig. 4, when the device is in the accessible state, if there is an access request of the first access type with the absolute minimum rank count in the multiple access requests to be sent, or there is only an access request of the first access type in the multiple access requests to be sent, the access request of the first access type will be sent and the access of the first access type will be performed.
In contrast, when the device is in an accessible state, if only an access request of the second access type with the absolute minimum order count exists in the plurality of access requests to be sent, or only an access request of the second access type exists in the plurality of access requests to be sent, the access request of the second access type is sent and switched to perform access of the second access type.
Further, when the device is in an accessible state, if there is no access request having an absolute minimum sorting count among the plurality of access requests to be transmitted and there are both access requests of the first access type and access requests of the second access type, a difference value of an updated sorting count of an access request of the first access type having a relatively minimum sorting count and an updated sorting count of an access request of the second access type having a relatively minimum sorting count is calculated, and it is determined which access type of access request is to be transmitted and whether to perform a switching of the access type according to a result of comparison of the difference value with the switching threshold.
Advantageously, the technical solution of the present disclosure can determine the currently more preferred candidate access request by comprehensively considering both the urgency of the access request and the bandwidth cost of the handover access type.
FIG. 6 illustrates a schematic diagram of reordering multiple access requests to the same port in accordance with an embodiment of the disclosure. Wherein the upper part of fig. 6 illustrates the access request queue before reordering, and the lower part illustrates the access request queue after reordering.
As shown in the pre-ordered queue of access requests, a port may have multiple unsent read (R) and write (W) access requests, and the read and write access requests may be distributed in a staggered manner. If there are access requests only at that port, these interleaved access requests will in turn become candidate access requests and be granted credits in turn, whereby frequent access type switching will result in a waste of bandwidth.
To address this issue, in some embodiments, when there is only one port with an access request to send and the port also has other unsent access requests of different access types, the method 300 may further include: and judging whether the access type of the access request to be sent is the same as the equipment access type, if so, directly sending the access request to be sent, otherwise, taking the access request which is not sent and has the same type as the equipment access type as the access request to be sent, and sending the access request to be sent.
Subsequently, in some embodiments, it is sequentially determined whether each unsent access request is the same as the determined type of the access request to be sent. If so, the original transmission order of the unsent access requests is maintained. Otherwise, the order of the unsent access requests is adjusted. If the unsent access request needing to adjust the order is an unsent access request from a plurality of unsent access requests having the same access address, the original order of the unsent access requests is maintained.
That is, reordering does not change the relative order of transmission of access requests to the same access address, and therefore does not affect the normal execution of accesses.
In some embodiments, the above processing may be performed by the arbiter 112.
For example, in the example shown in fig. 6, the access types of the plurality of access requests before the sorting are sequentially write, read, and read, respectively, and the access addresses are sequentially a0, a1, a2, a3, a4, and a4, respectively. Further, assume that the last access to the device is a read access.
Since the access type of the write access request for the address a0 is different from the device access type, the read access request for the address a1 is queued first as an access request to be sent, which can reduce switching of the access types. Further, the write access requests for address a0 and address a2 are ordered backwards relative to the read access request for address a3, such that the read access request for address a3, the write access request for address a0, and the write access request for address a2 are sent in sequence after the read access request for address a1 is sent. Notably, the relative order of read access requests and write access requests to the same address a4 is not adjusted. Therefore, the write access request and the read access request for the address a4 are still sent last.
Thus, the above reordering does not change the relative sending order of the last two access requests for the same access address a4, but makes read and write accesses more focused.
In one implementation, a chip may include an arbiter or controller as described above.
The terms "front," "back," "top," "bottom," "over," "under," and the like in the description and in the claims, if any, are used for descriptive purposes and not necessarily for describing permanent relative positions. It is to be understood that the terms so used are interchangeable under appropriate circumstances such that the embodiments of the disclosure described herein are, for example, capable of operation in other orientations than those illustrated or otherwise described herein.
As used herein, the word "exemplary" means "serving as an example, instance, or illustration," and not as a "model" that is to be reproduced exactly. Any implementation exemplarily described herein is not necessarily to be construed as preferred or advantageous over other implementations. Furthermore, the disclosure is not limited by any expressed or implied theory presented in the preceding technical field, background, brief summary or the detailed description.
As used herein, the term "substantially" is intended to encompass any minor variation resulting from design or manufacturing imperfections, device or component tolerances, environmental influences, and/or other factors. The word "substantially" also allows for differences from a perfect or ideal situation due to parasitics, noise, and other practical considerations that may exist in a practical implementation.
In addition, the foregoing description may refer to elements or nodes or features being "connected" or "coupled" together. As used herein, unless expressly stated otherwise, "connected" means that one element/node/feature is directly connected to (or directly communicates with) another element/node/feature, either electrically, mechanically, logically, or otherwise. Similarly, unless expressly stated otherwise, "coupled" means that one element/node/feature may be mechanically, electrically, logically, or otherwise joined to another element/node/feature in a direct or indirect manner to allow for interaction, even though the two features may not be directly connected. That is, to "couple" is intended to include both direct and indirect joining of elements or other features, including connection with one or more intermediate elements.
In addition, "first," "second," and like terms may also be used herein for reference purposes only, and thus are not intended to be limiting. For example, the terms "first," "second," and other such numerical terms referring to structures or elements do not imply a sequence or order unless clearly indicated by the context.
It will be further understood that the terms "comprises" and/or "comprising," when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
In the present disclosure, the term "providing" is used broadly to encompass all ways of obtaining an object, and thus "providing an object" includes, but is not limited to, "purchasing," "preparing/manufacturing," "arranging/setting," "installing/assembling," and/or "ordering" the object, and the like.
Those skilled in the art will appreciate that the boundaries between the above described operations merely illustrative. Multiple operations may be combined into a single operation, single operations may be distributed in additional operations, and operations may be performed at least partially overlapping in time. Moreover, alternative embodiments may include multiple instances of a particular operation, and the order of operations may be altered in various other embodiments. However, other modifications, variations, and alternatives are also possible. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
Although some specific embodiments of the present disclosure have been described in detail by way of example, it should be understood by those skilled in the art that the foregoing examples are for purposes of illustration only and are not intended to limit the scope of the present disclosure. The various embodiments disclosed herein may be combined in any combination without departing from the spirit and scope of the present disclosure. It will also be appreciated by those skilled in the art that various modifications may be made to the embodiments without departing from the scope and spirit of the disclosure. The scope of the present disclosure is defined by the appended claims.
Claims (14)
1. An arbiter for a multi-port accessible device, comprising:
the device comprises a request port number determining module, a request port number determining module and a processing module, wherein the request port number determining module is configured to judge whether an access request to be sent is available at one port or a plurality of ports, and the access request to be sent refers to an access request which is sent to equipment firstly in each request port with the access request which is not sent;
a device access type acquisition module configured to acquire a device access type indicating an access type of a latest access to a device;
the access request feature acquisition module is configured to acquire an access type and an urgency degree of each access request to be sent, wherein the access type of the access request comprises a first access type which is the same as the device access type and a second access type which is different from the device access type; and
an arbitration execution module configured to perform the following:
if the access request to be sent exists at only one port, determining the access request as a candidate access request to be sent to the equipment firstly among the access requests to be sent; or
Determining at least one priority access request with the highest current priority from the plurality of access requests to be sent and candidate access requests from the at least one priority access request according to the device access type and the access type and urgency of each access request if there are a corresponding plurality of access requests to be sent at the plurality of ports, wherein the urgency is represented using an updated ranking count that is decremented from a preset initial ranking count according to an increase in latency until an absolute minimum ranking count is reached, calculating a difference between the updated ranking count of an access request of a first access type with a relatively minimum ranking count and an updated ranking count of an access request of a second access type with a relatively minimum ranking count if the plurality of access requests to be sent each have an updated ranking count that is greater than the absolute minimum ranking count but different access types, and determining a priority access request according to a comparison result of the difference value and the switching threshold value.
2. The arbiter of claim 1, wherein the access request feature acquisition module comprises:
the device comprises an initialization unit, a priority setting unit and a priority setting unit, wherein the initialization unit is configured to initialize the sequencing count of an access request when the access request which is not sent becomes the access request to be sent, and the initialization value of the sequencing count is related to the preset priority of the access request;
an aging unit configured to decrement a rank count of an access request to be transmitted according to an increase in the waiting time to obtain an updated rank count representing the urgency until the updated rank count reaches an absolute minimum rank count; and
an access request type obtaining unit configured to obtain an access type of an access request to be sent.
3. The arbiter of claim 1, wherein the arbitration execution module to determine the priority access request comprises:
the access request of the first access type is preferentially determined as a priority access request so as to reduce the switching of the access types.
4. The arbiter of claim 2, wherein the arbitration execution module to determine the priority access request comprises:
and if the updated ordering count of one or more access requests of the first access type in the plurality of access requests to be sent reaches the absolute minimum ordering count, determining the one or more access requests of the first access type as priority access requests.
5. The arbiter of claim 2, wherein the arbitration execution module to determine the priority access request comprises:
and if the updated ordering count of only one or more access requests of the second access type in the plurality of access requests to be sent reaches the absolute minimum ordering count, determining the one or more access requests of the second access type as priority access requests.
6. The arbiter of claim 2, wherein the arbitration execution module to determine the priority access request comprises:
and if the plurality of access requests to be sent have the same access type, determining the access request with the relative minimum sequencing count as a priority access request.
7. The arbiter of claim 1, the arbitration execution module to determine a priority access request based on the difference value comprising:
if the difference is less than or equal to the switching threshold, determining the access request of the first access type with the relative minimum sequencing count as a priority access request; or
If the difference is greater than the handoff threshold, an access request of the second access type having a relatively minimum sort count is determined to be a priority access request.
8. The arbiter of claim 2, wherein,
the initialized value of the sort count is set to a positive integer; and
the aging module decrements the sequencing count by 1 each time.
9. The arbiter of claim 1, wherein the arbitration execution module determines the candidate access request from the at least one priority access request using a round-robin process.
10. The arbiter of claim 1, wherein,
when only one port has an access request to be sent and the port also has other access requests which are not sent and have different access types, the arbiter is configured to judge whether the access type of the access request to be sent is the same as the device access type, if so, the access request to be sent is directly sent, otherwise, the access request which is not sent and has the same type as the device access type is taken as the access request to be sent, and the access request to be sent is sent.
11. The arbiter of claim 10, wherein the arbiter is configured to sequentially determine whether each unsent access request is the same as the determined type of the access request to be transmitted, and if so, maintain an original transmission order of the unsent access requests, otherwise, adjust an order of the unsent access requests, wherein if the unsent access request whose order needs to be adjusted is an unsent access request from among a plurality of unsent access requests having the same access address, the original order of the unsent access requests is maintained.
12. A controller for a multi-port accessible device, comprising:
the arbiter of any one of claims 1-11, configured to determine a candidate access request from one or more access requests to be transmitted;
a credit distributor configured to grant credit to the determined candidate access request when the device is in an accessible state; and
a selector configured to receive a gating signal for a port on which an access request with credit is located to transmit the access request to a device through the port.
13. A chip, wherein the chip comprises an arbiter according to any one of claims 1-11 or a controller according to claim 12.
14. An arbitration method for a multi-port accessible device, comprising:
judging whether an access request to be sent exists at one port or a plurality of ports, wherein the access request to be sent refers to an access request which is sent to equipment firstly in each request port with the access request which is not sent;
if the access request to be sent exists at only one port, determining the access request as a candidate access request to be sent to equipment firstly in the access requests to be sent; or
If there are a corresponding plurality of access requests pending for transmission at the plurality of ports, then:
obtaining a device access type representing an access type of a last access to a device;
acquiring an access type and an emergency degree of each access request to be sent, wherein the access type of each access request comprises a first access type which is the same as an equipment access type and a second access type which is different from the first access type;
determining at least one priority access request with the highest current priority from the multiple access requests to be sent according to the equipment access type and the emergency degree of each access request; and
determining a candidate access request from at least one priority access request;
wherein determining the priority access request includes representing the urgency using an updated ranking count that is decremented from a preset initial ranking count according to an increase in latency until an absolute minimum ranking count is reached, calculating a difference in the updated ranking count of an access request of a first access type having a relatively minimum ranking count and an updated ranking count of an access request of a second access type having a relatively minimum ranking count if the plurality of access requests to be transmitted each have an updated ranking count that is greater than the absolute minimum ranking count but have different access types, and determining the priority access request according to a comparison of the difference with a switching threshold.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210144746.4A CN114185823B (en) | 2022-02-17 | 2022-02-17 | Arbiter, arbitration method, controller and chip |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210144746.4A CN114185823B (en) | 2022-02-17 | 2022-02-17 | Arbiter, arbitration method, controller and chip |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114185823A CN114185823A (en) | 2022-03-15 |
| CN114185823B true CN114185823B (en) | 2022-05-24 |
Family
ID=80546149
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210144746.4A Active CN114185823B (en) | 2022-02-17 | 2022-02-17 | Arbiter, arbitration method, controller and chip |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114185823B (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114911727A (en) * | 2022-05-26 | 2022-08-16 | 上海美仁半导体有限公司 | Bus arbitration method and device, computer readable storage medium and main control chip |
| CN115086438B (en) * | 2022-08-19 | 2022-11-11 | 南京芯驰半导体科技有限公司 | Task processing method, video processing unit, component and traffic equipment |
| CN117312199B (en) * | 2023-11-30 | 2024-03-08 | 杭州海康威视数字技术股份有限公司 | Multi-port access arbitration method, device, equipment and storage medium |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1841350A (en) * | 2005-03-30 | 2006-10-04 | 佳能株式会社 | Arbitrator, arbitrator control method and information processing device |
| CN1952916A (en) * | 2006-11-28 | 2007-04-25 | 北京中星微电子有限公司 | An arbitration device and method for accessing internal storage |
| WO2008065477A1 (en) * | 2006-11-28 | 2008-06-05 | Nokia Corporation | Memory arbitration |
| CN108228510A (en) * | 2018-01-17 | 2018-06-29 | 广东工业大学 | A kind of referee method of bus, equipment, storage medium and bus arbiter |
| CN113760473A (en) * | 2020-06-03 | 2021-12-07 | Oppo广东移动通信有限公司 | Priority processing method, processor, processing chip, circuit board and electronic equipment |
-
2022
- 2022-02-17 CN CN202210144746.4A patent/CN114185823B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1841350A (en) * | 2005-03-30 | 2006-10-04 | 佳能株式会社 | Arbitrator, arbitrator control method and information processing device |
| CN1952916A (en) * | 2006-11-28 | 2007-04-25 | 北京中星微电子有限公司 | An arbitration device and method for accessing internal storage |
| WO2008065477A1 (en) * | 2006-11-28 | 2008-06-05 | Nokia Corporation | Memory arbitration |
| CN108228510A (en) * | 2018-01-17 | 2018-06-29 | 广东工业大学 | A kind of referee method of bus, equipment, storage medium and bus arbiter |
| CN113760473A (en) * | 2020-06-03 | 2021-12-07 | Oppo广东移动通信有限公司 | Priority processing method, processor, processing chip, circuit board and electronic equipment |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114185823A (en) | 2022-03-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN114185823B (en) | Arbiter, arbitration method, controller and chip | |
| US7526593B2 (en) | Packet combiner for a packetized bus with dynamic holdoff time | |
| JP4861339B2 (en) | Flow control method to improve data transfer via switch matrix | |
| US7095752B2 (en) | On-chip inter-subsystem communication including concurrent data traffic routing | |
| US6393500B1 (en) | Burst-configurable data bus | |
| US8078781B2 (en) | Device having priority upgrade mechanism capabilities and a method for updating priorities | |
| EP1018687A2 (en) | A port manager controller for connecting various function modules | |
| US7395364B2 (en) | Data transfer control apparatus | |
| JP2002530744A (en) | Communication system and method with multi-level connection identification | |
| KR101699784B1 (en) | Bus system and operating method thereof | |
| JP3919765B2 (en) | Method and processor for managing arbitration | |
| WO2000017759A2 (en) | Computer system comprising latency tolerant and intolerant modules | |
| US20070101032A1 (en) | Bus arbitration circuit and bus arbitration method | |
| US20100169525A1 (en) | Pipelined device and a method for executing transactions in a pipelined device | |
| US7039750B1 (en) | On-chip switch fabric | |
| CN117348932B (en) | Slave device supporting AXI deep out-of-order transmission and working method | |
| US20210334230A1 (en) | Method for accessing data bus, accessing system, and device | |
| EP1380960B1 (en) | Memory access from different clock domains | |
| JP3317150B2 (en) | Information processing device | |
| JPH11282888A (en) | Data communication method in system to be designed based on system specification description, combination method of interruption controller and synthesizing method of interface circuit | |
| WO2003014948A1 (en) | System architecture of a high bit rate switch module between functional units in a system on a chip | |
| JP2000010914A (en) | Arbitration control device and method | |
| GB2341699A (en) | Inter-module data transfer | |
| GB2341770A (en) | Modular bus topology | |
| GB2341767A (en) | Bus arbitration |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |