COMMUNICATION CONTROLLER, COMMUNICATION METHOD, AND SYSTEM ON A CHIP

Abstract

An optimized communication technique is provided. A communication controller has a retransmission list and a destination control logic circuit. The retransmission list records an identification number of a communication transaction that failed to transmit from a source module to a destination module. The destination control logic circuit manages the retransmission list. When a tracker is released from a queue of the destination module, the destination control logic circuit requests the source module to retransmit the communication transaction to the destination module according to the identification number recorded in the retransmission list.

Claims

1. A communication controller, comprising: a retransmission list, recording an identification number of a communication transaction that failed to transmit from a source module to a destination module; and a destination control logic circuit, managing the retransmission list, wherein when a tracker is released from a queue of the destination module, the destination control logic circuit requests the source module to retransmit the communication transaction to the destination module according to the identification number recorded in the retransmission list.

2. The communication controller as claimed in claim 1, further comprising: a waiting queue, recording contents of a communication transaction that failed to transmit from a source module and are temporarily stored and dynamically managed in a tracker of the queue of the destination module, wherein: the destination control logic circuit further manages the waiting queue; and when the queue of the destination module releases the tracker, the destination control logic circuit fills the released tracker with the contents of the communication transaction obtained from the waiting queue.

3. The communication controller as claimed in claim 2, wherein: the destination control logic circuit requests the source module to retransmit the communication transaction with the identification number recorded in the retransmission list to the destination module when the queue of the destination module releases the tracker and the released tracker is filled with the contents of the communication transaction obtained from the waiting queue.

4. The communication controller as claimed in claim 3, wherein: the destination control logic circuit temporarily stores contents of the retransmitted communication transaction in the waiting queue.

5. The communication controller as claimed in claim 4, wherein: when the retransmission list is not full but already has an identification number of a communication transaction recorded thereon, an identification number of a new communication transaction is added to the retransmission list by the destination control logic circuit; and when the retransmission list is not full and the waiting queue is full, an identification number of a new communication transaction is added to the retransmission list by the destination control logic circuit.

6. The communication controller as claimed in claim 5, wherein: when the waiting queue is not full but already has contents of a communication transaction loaded thereon, contents of a new communication transaction are added to the waiting queue by the destination control logic circuit; and when the waiting queue is not full and the queue is full, the contents of a new communication transaction are added to the waiting queue by the destination control logic circuit.

7. The communication controller as claimed in claim 4, wherein: in comparison with the waiting queue, the retransmission list is smaller in size and lower in power consumption; and compared to the queue, the waiting queue is smaller in size and lower in power consumption.

8. The communication controller as claimed in claim 1, wherein: the destination control logic circuit temporarily stores contents of the retransmitted communication transaction in the queue for dynamic management.

9. The communication controller as claimed in claim 8, wherein: when the retransmission list is not full but already has an identification number of a communication transaction recorded thereon, an identification number of a new communication transaction is added to the retransmission list by the destination control logic circuit; and when the retransmission list is not full and the queue is full, an identification number of a new communication transaction is added to the retransmission list by the destination control logic circuit.

10. The communication controller as claimed in claim 9, wherein: compared to the queue, the retransmission list is smaller in size and lower in power consumption.

11. A system on a chip, comprising: at least one source module; and at least one destination module, wherein each destination module has a communication controller as claimed in claim 1 to deal with at least one communication transaction transmitted from the at least one source module.

12. A communication method, comprising: using a retransmission list to record an identification number of a communication transaction that failed to transmit from a source module to a destination module; managing the retransmission list; and when a tracker is released from a queue of the destination module, requesting the source module to retransmit the communication transaction to the destination module according to the identification number recorded in the retransmission list.

13. The communication method as claimed in claim 12, further comprising: using a waiting queue to record contents of a communication transaction that failed to transmit from a source module and are temporarily stored and dynamically managed in a tracker of the queue of the destination module; managing the waiting queue; and when the queue of the destination module releases the tracker, filling the released tracker with the contents of the communication transaction obtained from the waiting queue.

14. The communication method as claimed in claim 13, wherein: the source module is requested to retransmit the communication transaction with the identification number recorded in the retransmission list to the destination module when the queue of the destination module releases the tracker and the released tracker is filled with the contents of the communication transaction obtained from the waiting queue.

15. The communication method as claimed in claim 14, further comprising: temporarily storing contents of the retransmitted communication transaction in the waiting queue.

16. The communication method as claimed in claim 15, further comprising: when the retransmission list is not full but already has an identification number of a communication transaction recorded thereon, adding an identification number of a new communication transaction to the retransmission list; and when the retransmission list is not full and the waiting queue is full, adding an identification number of a new communication transaction to the retransmission list.

17. The communication method as claimed in claim 16, further comprising: when the waiting queue is not full but already has contents of a communication transaction loaded thereon, adding contents of a new communication transaction to the waiting queue; and when the waiting queue is not full and the queue is full, adding contents of a new communication transaction to the waiting queue.

18. The communication method as claimed in claim 15, wherein: in comparison with the waiting queue, the retransmission list is smaller in size and lower in power consumption; and compared to the queue, the waiting queue is smaller in size and lower in power consumption.

19. The communication method as claimed in claim 12, further comprising: temporarily storing contents of the retransmitted communication transaction in the queue for dynamic management.

20. The communication method as claimed in claim 19, further comprising: when the retransmission list is not full but already has an identification number of a communication transaction recorded thereon, an identification number of a new communication transaction is added to the retransmission list; and when the retransmission list is not full and the queue is full, an identification number of a new communication transaction is added to the retransmission list.

21. The communication method as claimed in claim 20, wherein: compared to the queue, the retransmission list is smaller in size and lower in power consumption.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The present invention can be more fully understood by reading the subsequent detailed description and examples with references made to the accompanying drawings, wherein:

[0012] FIG. 1 depicts a system on a chip (SoC) 100, having an on-chip interconnection network 102;

[0013] FIG. 2 depicts an architecture for communication from a functional block P0 to another functional block P1 on the SoC 100;

[0014] FIG. 3 depicts the modifications made to a source module for communication optimization in accordance with an exemplary embodiment of the disclosure;

[0015] FIGS. 4A, 4B, and 4C depict a flowchart illustrating the management of the transaction capability tables Tab.sub.0 . . . Tab.sub.(m-1) in accordance with an embodiment of the disclosure;

[0016] FIG. 5 illustrates the optimized communication technology implemented on the side of destination modules in accordance with an exemplary embodiment of the disclosure;

[0017] FIG. 6 is a flowchart illustrating the use of the turbo queues of FIG. 5 in accordance with an exemplary embodiment of the disclosure;

[0018] FIG. 7 is another flowchart illustrating the use of the turbo queues of FIG. 5 in accordance with an exemplary embodiment of the disclosure;

[0019] FIG. 8 illustrates an optimized communication technology implemented on the side of destination modules in accordance with another exemplary embodiment of the disclosure;

[0020] FIG. 9 illustrates how communication transactions transmitted to a destination module T.sub.k through the on-chip interconnection network 102 is filled in a turbo queue taught in FIG. 8;

[0021] FIG. 10 is a flowchart illustrating the use of the turbo queues of FIG. 8 in accordance with an exemplary embodiment of the disclosure;

[0022] FIG. 11A is a flowchart illustrating the use of the turbo queues of FIG. 8 in accordance with an embodiment of the disclosure;

[0023] FIG. 11B is another flowchart illustrating the use of the turbo queues of FIG. 8 in accordance with an embodiment of the disclosure; and

[0024] FIG. 12 is a block diagram depicting communication optimization in accordance with an exemplary embodiment of the disclosure.

DETAILED DESCRIPTION OF THE INVENTION

[0025] The following description shows exemplary embodiments of carrying out the invention. This description is made for the purpose of illustrating the general principles of the invention and should not be taken in a limiting sense. The scope of the invention is best determined by reference to the appended claims.

[0026] The communication technology described in this disclosure may be applied to various architectures of electronic systems. In the following, an on-chip interconnection network in SoC (System on a Chip) is discussed as an example, but it is not intended to be limited thereto.

[0027] FIG. 1 depicts a system on a chip (SoC) 100, having an on-chip interconnection network 102. The on-chip interconnection network 102 is a communication bridge between devices/functional blocks (or IPs) in SoC. As shown, the devices/functional blocks (or IPs) may include a central processing unit (CPU), an image processor (GPU), an input/output controller (I/O controller), a cache L2/LLC controller and a memory controller.

[0028] FIG. 2 depicts an architecture for communication from a functional block P0 to another functional block P1 on the SoC 100. The switches/routers RO are provided for signal transmission. The switches/routers RO form the aforementioned on-chip interconnection network 102. Signals are transmitted by packages through an architecture that includes a routing layer, a link layer, and a physical layer. Signals are transmitted as messages through a protocol layer. In the disclosure, the protocol layer is specially designed to make the point-to-point communication between different functional blocks smooth. The computing hardware and code involved in the technology of the present disclosure may be implemented as a single hardware module, or embedded in a microcontroller of a functional block, or placed in a link interface of a functional block. In an exemplary embodiment, a specially-designed state machine is provided in the protocol layer to implement the disclosure.

[0029] The functional blocks in the SoC 100 sometimes act as a source of communication data, sometimes as a destination for communication data. For example, a central processing unit may be a source module that provides data to be transmitted to the cache L2/LLC controller via the on-chip interconnection network 102. The central processing unit may also be a destination module that receives the data that the memory controller read from a memory. Communication optimization may be applied to modify a source module or a destination module. The functional blocks that switch between the two roles (sometimes being a source module and sometimes being a destination module) may combine the two types of communication optimization solutions.

[0030] First, the modifications made to the source module for communication optimization are discussed.

[0031] FIG. 3 depicts the modifications made to the source module for communication optimization in accordance with an exemplary embodiment of the disclosure. The source modules S.sub.0 . . . S.sub.(m-1) may request communication transactions to the destination modules T.sub.0 . . . T.sub.(n-1) via the intra-chip interconnect network 102. The source modules S.sub.0 . . . S.sub.(m-1) may exchange transaction capability (or credits for transmitting communication transactions). As shown, transaction capability tables Tab.sub.0 . . . Tab.sub.(m-1) are managed on the source modules S.sub.0 . . . S.sub.(m-1), respectively, as a reference for the source modules S.sub.0 . . . S.sub.(m-1) to transmit communication transactions to the destination modules T.sub.0 . . . T.sub.(n-1). In this embodiment, there are n queues Q.sub.0, Q.sub.1 . . . Q.sub.(n-1) provided in the n destination modules T.sub.0, T.sub.1 . . . T.sub.(n-1), respectively. Each of the queues Q.sub.0, Q.sub.1 . . . Q.sub.(n-1) provides r trackers Tracker_0, Tracker_1 . . . Tracker_(r1) for temporary storage and dynamic management of communication transactions requested by the source modules S.sub.0 . . . S.sub.(m-1). Each tracker is provided to track one communication transaction. Each tracker has a state machine that dynamically manages the tracked communication transaction.

[0032] The transaction capability table Tab.sub.0 is discussed in this paragraph as an example. In the transaction capability table Tab.sub.0, several factors are recorded for each of the destination modules T.sub.0 . . . T.sub.(n-1). The factors include values representing intrinsic transaction capability k, borrowed transaction capability Cb#, a loan Cl# of transaction capability, and practical transaction capability TC#. The practical transaction capability TC# is estimated from the intrinsic transaction capability k, the borrowed transaction capability Cb#, the loan Cl# of transaction capability and transaction capability consumption C#. Based on the practical transaction capability TC#, it is determined whether the corresponding source module could transmit a communication transaction to the corresponding destination module without affecting the communication network. The non-zero value of the practical transaction capability TC# represents that the corresponding source module is allowed to issue a communication transaction to the corresponding destination module. When the practical transaction capability TC# is zero, the source module is not allowed to request a communication transaction to the destination module to avoid blocking the communication network.

[0033] In this paragraph, the contents recorded in the transaction capability table Tab.sub.0 for the destination modules T.sub.0 is discussed in detail. The intrinsic transaction capability k may be r/m. The number of trackers Tracker_0, Tracker_1 . . . Tracker_(r1) contained in the queue Q.sub.0 is r, which is expected to be evenly shared by the m source modules S.sub.0 . . . S.sub.(m-1). The borrowed transaction capability Cb# shows how much transaction capacity the source module S.sub.0 has borrowed from other source modules S.sub.1 . . . S.sub.(m-1) to transmit communication transactions to the destination module T.sub.0. In an exemplary embodiment, borrowing information Sb.sub.info is recorded to show which source modules the borrowed transaction capability Cb# comes from. The loan Cl# of transaction capability shows how much transaction capacity the source module S.sub.0 lends other source modules S.sub.1 . . . S.sub.(m-1) to transmit communication transactions with the destination module T.sub.0. In an exemplary embodiment, loan information Sl.sub.info is recorded which lists the source modules that get the loan Cl# of transaction capability. The transaction capability consumption C# reflects the number of communication transactions that have been transmitted from the source module S.sub.0 to the destination module T.sub.0 and is being processed in the destination module T.sub.0. When one communication transaction requested by the source module S.sub.0 is stored to the queue Q.sub.0 of the destination module T.sub.0, the value representing the transaction capability consumption C# is increased by one. After a communication transaction is finished and removed from the queue Q.sub.0, the value representing the transaction capability consumption C# is decreased by 1. An estimate of the practical transaction capability TC# of the source module S.sub.0 to request communication transaction to the destination module T.sub.0 can be calculated using the following formula:

TC#=k+Cb#Cl#C#

By sharing the transaction capability regarding a particular destination module between the different source modules, the practical transaction capability TC# can be kept above zero. As a result, the source module S.sub.0 is no longer limited to the intrinsic transaction capability k if it has a strong communication transaction demand to the destination module T.sub.0. On the contrary, if the source module S.sub.0 does not have a demand for communication transactions to the destination module T.sub.0, its intrinsic transaction capability k can be lent to the other source modules S.sub.1 . . . S.sub.(m-1). In one exemplary embodiment, the loan Cl# of transaction capacity cannot exceed the intrinsic transaction capability k. Only the intrinsic transaction capability k can be loaned.

[0034] FIGS. 4A, 4B, and 4C depict a flowchart illustrating the management of the transaction capability tables Tab.sub.0 . . . Tab.sub.(m-1) in accordance with an embodiment of the disclosure. The flowchart can be implemented by the source modules S.sub.0 . . . S.sub.(m-1) by using hardware and code, or a state machine.

[0035] Referring to FIG. 4A, the transaction capability tables Tab.sub.0 . . . Tab.sub.(m-1) are reset in step S402. The intrinsic transaction capability k (=r/m) is set. The borrowed transaction capability Cb#, the loan Cl# of transaction capability, the transaction capability consumption C# are all reset to 0. The borrowing information Sb.sub.info and the loan information Sl.sub.info are cleared. At this time, an equal value, k, is assigned as the practical transaction capability TC# for the different source modules S.sub.0 . . . S.sub.(m-1) to transmit communication transactions to the different the destination modules T.sub.0 . . . T.sub.(n-1).

[0036] In step S404, it detects whether a request for communication transaction occurs and the source module S.sub.x and the destination module T.sub.y regarding the communication transaction are recorded. With regard to this communication transaction, step S406 determines whether the practical transaction capability TC# of the source module S.sub.x to the destination module T.sub.y is greater than zero. If it is greater than 0, the flow proceeds to step S408, and the source module S.sub.x transmits the communication transaction detected in step S404 to the queue Q.sub.y of the destination module T.sub.y to be temporarily stored and dynamically managed in one of the trackers. In step S408, a value representing the transaction capability consumption C# of the source module S.sub.x to the destination module T.sub.y is increased by one.

[0037] When it is determined in step S406 that the source module S.sub.x has no transaction capability to the destination module T.sub.y (the practical transaction capability TC# is 0), the flow proceeds to step S412 of FIG. 4B through the node A. In step S412, the transaction capability table TAB.sub.X is checked, referring to the column corresponding to the destination module T.sub.y, the loan Cl# of transaction capability that the source module S.sub.x lends the other source modules to transact with the destination module T.sub.y is obtained and a check is made as to whether the loan Cl# is greater than zero. When the loan Cl# is greater than zero, step S414 is performed to send a return request according to the loan information Sl.sub.info. In an exemplary embodiment, the return request is send to the source module having the highest value of practical transaction capability TC# regarding the destination module T.sub.y. In another exemplary embodiment, the return request is sent to the source module that is in the closest transmission distance. In step S416, the return of transaction capability is monitored. When the transaction capability is returned from a source module S.sub.z, step S418 is performed. In a transaction capability table Tab.sub.z, a value representing the borrowed transaction capability Cb# regarding the destination module T.sub.y is decreased by 1 and the corresponding borrowing information Sb.sub.info is modified. In the transaction capability table Tab.sub.x, a value representing the loan Cl# of transaction capability regarding the destination module T.sub.y is decreased by 1 and the corresponding loan information Sl.sub.info is modified. Then, step S408 is performed. The source module S.sub.x transmits the communication transaction to the destination module T.sub.y and the value representing the transaction capability consumption C# of the source module S.sub.x to the destination module T.sub.y is increased by one.

[0038] When it is determined in step S412 that the source module S.sub.x has no transaction capability lent to other source modules to transact with the destination module T.sub.y (the loan Cl# of transaction capability is 0), the flow proceeds through the node B to step S422 of FIG. 4C. In step S422, the source module S.sub.x broadcasts a borrowing request. In step S424, a check is made as to whether all of the other source modules have responded to the borrowing request. If yes, step S426 is performed to identify the idle source modules. In an exemplary embodiment, an idle source module does not have any communication transaction is being processed in the destination modules T.sub.0 . . . T.sub.(n-1). In step S428, one eligible (idle) source module S.sub.z is selected to share out the transaction capability. In an exemplary embodiment, the selection further depends on the transmission distance. The source module S.sub.x may select the nearest source module to borrow the transaction capability. In an exemplary embodiment, the selection further depends on whether the owned transaction capability is plenty. The source module S.sub.x may select to borrow transaction capability from a source module that has plenty of transaction capability to lend other source modules, i.e. having the highest number of (kCl#). In step S430, the transaction capability table Tab.sub.x is modified. Regarding the destination module T.sub.y, a value representing the borrowed transaction capability Cb# is increased by 1 and the corresponding borrowing information Sb.sub.info is modified. In step S430, code for acknowledgment ACK is transmitted to the source module S.sub.z to modify the transaction capability table Tab.sub.z. In the transaction capability table Tab.sub.z, regarding the destination module T.sub.y, a value representing the loan Cl# of transaction capability is increased by 1 and the corresponding loan information Sl.sub.info is modified. In step S430, code for negative acknowledgment NAK to refuse the sharing of transaction capability is transmitted to the other source modules except the source module S.sub.z. Then, step S408 is performed. The source module S.sub.x transmits the communication transaction to the destination module T.sub.y and the value representing the transaction capability consumption C# of the source module S.sub.x to the destination module T.sub.y is increased by one.

[0039] When it is determined in step S426 that none of the other source modules are idle, step S432 is performed. In step S432, transaction capability tables are checked. Regarding the destination module T.sub.y, the loans Cl# of transaction capability are checked. The source module S.sub.z having the loan Cl# not exceeding the value k or not exceeding a threshold value l_th (that is smaller than the value k) is selected in step S428 to lend the source module S.sub.x the transaction capability. In an exemplary embodiment, the selection further depends on the transmission distance. The source module S.sub.x may select the nearest source module to borrow the transaction capability. In an exemplary embodiment, the selection further depends on whether the owned transaction capability is plenty. The source module S.sub.x may select to borrow transaction capability from a source module that has plenty of transaction capability to lend other source modules, i.e. having the highest number of (kCl#). Then, step S430 is performed for the corresponding modifications to the transaction capability tables Tab.sub.x and Tab.sub.z. Then, step S408 is performed. The source module S.sub.x sends the planned communication transaction to the destination module Ty, and the value representing the transaction capability consumption C# of the source module S.sub.x to the destination module T.sub.y is increased by one.

[0040] When it is determined in step S432 that no source module is qualified for sharing out the transaction capability because the checked loans Cl# of transaction capability are too high, step S434 is performed to wait for the completion of a communication transaction that have been transmitted from the source module S.sub.x to the destination module T.sub.y and processed in the destination module T.sub.y (for example, waiting for the value representing the transaction capacity consumption C# to be decreased by 1). Then, step S408 is performed. The source module S.sub.x sends the planned communication transaction to the destination module T.sub.y, and the value representing the transaction capability consumption C# of the source module S.sub.x to the destination module T.sub.y is increased by one.

[0041] According to the above, the use of the all trackers of the destination module is optimized.

[0042] The number of trackers in the different queues Q0 . . . Q(n1) (provided by the different destination modules T0 . . . T(n1)) may be not unified as r, and may be different from each other.

[0043] In the following paragraphs, the optimized communication technology implemented on the side of destination modules is discussed.

[0044] FIG. 5 illustrates the optimized communication technology implemented on the side of destination modules in accordance with an exemplary embodiment of the disclosure. The destination modules T.sub.0 to T.sub.(n-1) use turbo queues. In addition to an aforementioned queue (referring to queues Q.sub.0 . . . Q.sub.(n-1)), a retransmission list (referring to retransmission lists ReT.sub.0 . . . ReT.sub.(n-1)) is also managed in a turbo queue. Each of the queues Q.sub.0 to Q.sub.(n-1) contains r trackers Tracker_0 to Tracker_(r1). Each of the retransmission lists ReT.sub.0 to ReT.sub.(n-1) contains T entries Entry_0 to Entry_(T1). When all trackers within the same queue are occupied, the corresponding retransmission list records the identification number (ID#) for a planned communication transaction. When a tracker is released later, a retransmission request is issued according to the recorded identification number ID# and the corresponding source module retransmit the planned communication transmission that was not successfully transmitted. By managing and operating according to the retransmission lists ReT.sub.0 to ReT.sub.(n-1), the queues Q.sub.0 to Q.sub.(n-1) are effectively utilized.

[0045] FIG. 6 is a flowchart illustrating the use of the turbo queues of FIG. 5 in accordance with an exemplary embodiment of the disclosure. The flow can be implemented in the destination modules T.sub.0 . . . T.sub.(n-1) by hardware and code, or state machines.

[0046] In step S602, it is monitored whether there is a plan for a communication transaction, and the source module S.sub.x and the destination module T.sub.y regarding the planned communication transaction are recorded. For the planned communication transaction, step S604 is performed to check whether the retransmission list ReT.sub.y records any retransmission needs. If yes, step S606 is performed to list the identification number ID# of the communication transaction planed in step S602 in the retransmission list ReT.sub.y. Then, step S602 is performed to continue monitoring whether there are other plans for communication transactions.

[0047] When the retransmission list ReT.sub.y checked in step S604 shows no communication transaction waiting to be retransmitted, step S608 is performed to check whether the queue Q.sub.y is full. When the queue Q.sub.y is full, step S606 is performed and the identification number ID# of the communication transaction planed in step S602 is listed in the retransmission list ReT.sub.y. When the queue Q.sub.y has any empty tracker, the flow proceeds to step S610. The source module S.sub.x transmits the planned communication transaction to the queue Q.sub.y of the destination module T.sub.y to be temporarily stored and dynamically managed in one of the trackers. Then, step S602 is performed to continue monitoring whether there are other plans of communication transactions.

[0048] FIG. 7 is another flowchart illustrating the use of the turbo queues of FIG. 5 in accordance with an exemplary embodiment of the disclosure. The flow can be implemented in the destination modules T.sub.0 . . . T.sub.(n-1) by hardware and code, or state machines.

[0049] In step S702, it is monitored whether any tracker is released and the queue Q.sub.h providing the released tracker is recorded. For the released tracker, step S704 is performed to check whether the retransmission list ReT.sub.h records a retransmission demand for a communication transaction. If yes, step S706 is performed. According to the oldest identification number ID# recorded in the retransmission list ReT.sub.h, the corresponding source module S.sub.z is obtained. A retransmission request is issued and the source module S.sub.z retransmits the communication transaction (with the identification number ID#) to the destination module T.sub.h to be temporarily stored and dynamically managed by the tracker released from the queue Q.sub.h. In the retransmission list ReT.sub.h, the identification number ID# of the retransmitted communication transaction is deleted. Then, step S702 is performed to continue monitoring whether any tracker of the queues Q.sub.0 . . . Q.sub.(n-1) is released. When it is determined in step S704 that the retransmission list ReT.sub.h does not record any retransmission demand for any communication transaction, the flow may also go back to step S702 to monitor whether any tracker is released.

[0050] FIG. 8 illustrates an optimized communication technology implemented on the side of destination modules in accordance with another exemplary embodiment of the disclosure. The destination modules T.sub.0 to T.sub.(n-1) each contains a turbo queue which is an upgraded version of the turbo queues mentioned in FIG. 5. In addition to the queues Q.sub.0 . . . Q.sub.(n-1) and the retransmission lists ReT.sub.0 . . . ReT.sub.(n-1), the destination modules T.sub.0 . . . T.sub.(n-1) further manages waiting queues WQ.sub.0 . . . WQ.sub.(n-1).

[0051] Each of the queues Q.sub.0 . . . Q.sub.(n-1) has r trackers Tracker_0 to Tracker_(r1) for temporarily storage and dynamic management of communication transactions transmitted from the source modules S.sub.0 . . . S.sub.(m-1) through the on-chip interconnection network 102. One tracker is provided to correspond to one communication transaction. Each tracker has a state machine that dynamically manages the communication transaction temporarily stored therein. Each of the waiting queues WQ.sub.0 . . . WQ.sub.(n-1) has P entries Entry_0 to Entry_(P1). When all trackers of one queue are occupied, the corresponding waiting queue uses one column to record the currently-received communication transaction. When one tracker is released, a communication transaction temporarily stored in the corresponding waiting queue is moved to the released tracker. The waiting queues WQ.sub.0 . . . WQ.sub.(n1) generally do not include any state machine and are not responsible for the management of the temporarily stored communication transactions. Therefore, the size and power consumption of the queues WQ.sub.0 to WQ.sub.(n-1) are much smaller than the queues Q.sub.0 to Q.sub.(n-1). Each of the retransmission lists ReT.sub.0 . . . ReT.sub.(n-1) has T entries Entry_0, Entry_1 . . . Entry_(T1). When all entries of one waiting queue are occupied, the corresponding retransmission list records the identification number ID# of the planed communication transaction. When an entry of the waiting queue is released later, a retransmitting request is sent according to the recorded identification number ID# and thereby the corresponding source module retransmits the communication transaction that was not successfully transmitted before. The retransmitted communication transaction is stored in the waiting queue waiting to be moved to a released tracker of the corresponding queue. According to the design of FIG. 8, a tracker released from a queue is filled in time by moving a communication transaction waited in the corresponding waiting queue to the released tracked. No retransmission delay is required. In comparison with the design of FIG. 5, the design of FIG. 8 utilizes the queues Q.sub.0 to Q.sub.(n-1) more effectively.

[0052] FIG. 9 illustrates how communication transactions transmitted to a destination module T.sub.k through the on-chip interconnection network 102 is filled in a turbo queue taught in FIG. 8. A queue Q.sub.k has several trackers. In each tracker, the progress of the temporarily stored communication transaction is monitored. For example, a state machine in each tracker may show the progress of the monitored communication transaction. The waiting queue WQ.sub.k is not responsible for the dynamic management of the communication transaction temporarily stored therein. In each entry of the waiting queue WQ.sub.k, an identification number ID# and corresponding transaction contents are recorded. The retransmission list ReT.sub.k is smaller than the waiting queue WQ.sub.k in size, storing identification numbers ID# but not storing the transaction contents. The trackers of the queue Q.sub.k may store contents of communication transactions transmitted from source modules through the on-chip interconnection network 102 or store transaction contents obtained from the waiting queue WQ.sub.k. The waiting queue WQ.sub.k may store transaction contents retransmitted from source modules through the on-chip interconnection network 102 or transaction contents transmitted from source modules through the on-chip interconnection network 102 the first time. The identification numbers ID# recorded in the retransmission list ReT.sub.k are obtained from communication transaction which failed to be successfully received.

[0053] FIG. 10 is a flowchart illustrating the use of the turbo queues of FIG. 8 in accordance with an exemplary embodiment of the disclosure. The flow can be implemented in the destination modules T.sub.0 . . . T.sub.(n-1) by hardware and code, or state machines.

[0054] In step S1002, it is monitored whether there is a plane for communication transaction, and it is recorded that the communication transaction is issued by the source module S.sub.x to the destination module T.sub.y. For the planed communication transaction, step S1004 is performed to check whether the retransmission list ReT.sub.y records an identification number ID# of another communication transaction to be retransmitted. If yes, step S1006 lists the identification number ID# of the planed communication transaction (detected in step S1002) in the retransmission list ReT.sub.y. Then, the flow may return to step S1002 to continue monitoring whether there are other plans of for communication transactions.

[0055] If it is determined in step S1004 that the retransmission list ReT.sub.y does not mention any communication transaction to be retransmitted, step S1008 is performed to check whether the waiting queue WQ.sub.y stores any communication transaction waiting to be moved to the queue Q.sub.y. If so, step S1010 is performed to check if the waiting queue WQ.sub.y is full. If it is full, the flow proceeds to step S1006, and the identification number ID# of the planned communication transaction (detected in step S1002) is added to the retransmission list ReT.sub.y. If there is an empty entry in the waiting queue WQ.sub.y, the flow proceeds to step S1012, and the source module S.sub.x transmits the planned communication transaction to the waiting queue WQ.sub.y of the destination module T.sub.y for temporary storage. Then, the flow may return to step S1002 to continue monitoring whether there are other plans for communication transactions.

[0056] When it is determined in step S1008 that the waiting queue WQ.sub.y does not contain any communication transaction waiting to be moved to the queue Q.sub.y, step S1014 checks if the queue Q.sub.y is full. If the queue Q.sub.y is full, the flow proceeds to step S1012, and the source module S.sub.x transmits the planned communication transaction to the waiting queue WQ.sub.y of the destination module T.sub.y for temporary storage. If the queue Q.sub.y has an empty tracker for the planned communication transaction, the flow proceeds to step S1016. The source module S.sub.x transmits the planned communication transaction to queue Q.sub.y of destination module T.sub.y to be stored in one tracker for temporary storage and dynamic management. Then, the flow may return to step S1002 to continue monitoring whether there are other plans for communication transactions.

[0057] FIG. 11A is a flowchart illustrating the use of the turbo queues of FIG. 8 in accordance with an embodiment of the disclosure. The flow can be implemented in the destination modules T.sub.0 . . . T.sub.(n-1) by hardware and code, or state machines.

[0058] Step S1102 monitors whether a tracker is released and the queue Q.sub.h releasing the tracker is recorded. For the released tracker of the queue Q.sub.h, step S1104 is performed to check whether any communication transaction is waiting in the waiting queue WQ.sub.h to be moved to the queue Q.sub.h. If yes, step S1106 moves the oldest communication transaction stored in the waiting queue WQ.sub.h to the tracker released by the queue Q.sub.h for temporary storage and dynamic management in the tracker. Then, the flow may return to step S1102 to continue monitoring whether any tracker in the queues Q.sub.0 . . . Q.sub.(n-1) is released. When it is determined in step S1104 that there is no communication transaction in the waiting queue WQ.sub.h waiting to be moved to the queue Q.sub.h, the flow returns to step S1102 to continue monitoring whether any tracker of the queues Q.sub.0 . . . Q.sub.(n-1) is released.

[0059] FIG. 11B is another flowchart illustrating the use of the turbo queues of FIG. 8 in accordance with an embodiment of the disclosure. The method can be implemented in the destination modules T.sub.0 . . . T.sub.(n-1) by hardware and code, or state machines.

[0060] Step S1112 monitors whether the waiting queues WQ.sub.0 . . . WQ.sub.(n-1) have an entry released (e.g., moving a communication transaction from a waiting queue to a tracker in step S1106 of FIG. 11A) and the waiting queue WQ.sub.h providing the released entry is recorded. For the entry released from the waiting queue WQ.sub.h, step S1114 is performed to check whether any communication transaction is mentioned in the retransmission list ReT.sub.h. If yes, step S1116 is performed to send a retransmission request according to the identification number ID# of the oldest record in the retransmission list ReT.sub.h and the communication transaction indicated by the identification number ID# is retransmitted by its source module (e.g. S.sub.z). In step S1118, the communication transaction retransmitted by the source module S.sub.z to the destination module T.sub.h is temporarily stored in the entry released in the waiting queue WQ.sub.h. In the retransmission list ReT.sub.h, the identification number ID# of the communication transaction that has been successfully retransmitted is deleted. Then, the flow can go back to step S1112 to monitor whether the waiting queues WQ.sub.0 . . . WQ.sub.(n-1) has another entry being released. When it is determined in step S1114 that the retransmission list ReT.sub.h does not list any identification number ID#, the flow may also return to step S1112 to continue monitoring whether the waiting queues WQ.sub.0 . . . WQ.sub.(n-1) has another entry being released.

[0061] The monitoring step S1102 of FIG. 11A for the queues Q.sub.0 to Q.sub.(n-1) and the monitoring step S1112 of FIG. 11B for the waiting queues WQ.sub.0 to WQ.sub.(n-1) may be performed in parallel.

[0062] As the aforementioned discussion, the turbo queues provided in the destination modules T.sub.0 . . . T.sub.(n-1) result in significant improvements. Other variations are possible. The number of trackers in each of the queues Q.sub.0 . . . Q.sub.(n-1) of the different destination modules T.sub.0 . . . T.sub.(n-1) is not limited to r. The different queues Q.sub.0 . . . Q.sub.(n-1) may have different number of trackers. The different retransmission lists ReT.sub.0 . . . ReT.sub.(n-1) of the different destination modules T.sub.0 . . . T.sub.(n-1) may be different in size. The different waiting queues WQ.sub.0 . . . WQ.sub.(n-1) of the different destination modules T.sub.0 . . . T.sub.(n-1) may have different number of entries.

[0063] FIG. 12 is a block diagram depicting communication optimization in accordance with an exemplary embodiment of the disclosure. The devices/functional blocks (or IPs or circuits) PA and PB may perform bidirectional communication transactions through the on-chip interconnection network 102. The functional block PA includes a source module SA and a destination module TA. The functional block PB includes a source module SB and a destination module TB. The source modules SA and SB have transaction capability tables TabA and TabB (referring to FIG. 3) managed thereon and source control logic circuits SA_L and SB_L (referring to FIGS. 4A to 4C, which can be implemented by hardware or by jointly using hardware and software). The destination modules TA and TB have (turbo) queues TurboQA and TurboQB (referring to FIG. 5, FIG. 8 or FIG. 9), and destination control logic circuits TA_L and TB_L (referring to FIGS. 6, 7, 10, 11A and 11B, which can be implemented by hardware or by jointly using hardware and software). Referring to FIG. 1, the functional blocks PA and PB may be the CPU, image processor (GPU), input/output controller (I/O controller), cache L2/LLC controller, memory controller, and so on. The technology of the disclosure is not limited to involving an on-chip interconnection network 102 within an SoC. Any signal transmitting and receiving may use the aforementioned techniques.

[0064] Other techniques that use the above concepts in signal transmitting and receiving are within the scope of the disclosure. Based on the above contents, the present invention further relates to a communication method.

[0065] While the invention has been described by way of example and in terms of the preferred embodiments, it should be understood that the invention is not limited to the disclosed embodiments. On the contrary, it is intended to cover various modifications and similar arrangements (as would be apparent to those skilled in the art). Therefore, the scope of the appended claims should be accorded the broadest interpretation so as to encompass all such modifications and similar arrangements.