A METHOD AND APPARATUS FOR TRANSFERRING DATA BETWEEN CORES IN AN INTEGRATED CIRCUIT
[Para l ] TECHNICAL FIELD
[Para 2] Technical Field of the Present Invention [Para 3] The present invention generally relates to integrated circuits, and more specifically, to methods and apparatuses that facilitate the transfer of data between the various cores located within the integrated circuit.
[Para 4] BACKGROUND
[Para 5] Technological advancements in semiconductors have resulted in consumers expecting increasingly smaller more powerful devices. The number of circuits/functional units (cores) that reside on a typical integrated circuit to support these functions is astronomical. The sheer number of devices has forced the semiconductor industry to solve new problems associated with power consumption, heat dissipation, noise, and communication. A related issue is the number of wires required to provide communication between the various cores that implement the desired functionality. In the past, the wiring of the communication from one core to another has been accomplished using point-to-point techniques. Unfortunately, the exponential increase in density is causing point-to- point wiring to reach its limits.
[Para 6] It would, therefore, be a distinct advantage to have a method and apparatus that could transfer data from one core to another while addressing the concerns that arise during dense point- to-point wiring. The present invention provides such a method and apparatus.
[Para 7] DISCLOSURE OF THE INVENTION
[Para 8] The present invention is a method and apparatus for providing communication between various cores located in an integrated circuit. More specifically, the present invention uses Hubs/Routers to facilitate and manage communication of data from/between the cores according to a specified methodology.
[Para 9] BRIEF DESCRIPTION OF THE DRAWINGS [Para 10] The present invention will be better understood and its numerous objects and advantages will become more apparent to those skilled in the art by reference to the following drawings, in conjunction with the accompanying specification, in which: [Para 1 1] Figure 1 is a block diagram illustrating an example of a hub/router network for transferring data between various cores residing in an integrated circuit according to the teachings of the present invention;
[Para 12] Figure 2 is a schematic diagram is shown illustrating in greater detail one of the hubs of Figure 1 according to the teachings of the preferred embodiment of the present invention;
[Para 1 3] Figure 3 is a flow chart illustrating the method used by the Hubs of Figure 1 for receiving data from adjacent Hubs and Cores according to the teachings of the present invention; and [Para 14] Figure 4, a flow chart is shown illustrating the steps used by the Hubs 6-10 for transmitting previously received data according to the teachings of the present invention.
[Para 1 5] BEST MODE FOR CARRYING OUT THE INVENTION [Para 16] The present invention is a system and method for transferring data between various cores residing in an integrated circuit. The system/method uses hub/routers that are strategically located between the various cores. The operation of the hub/routers for providing the communication is explained in greater detail in connection with Figure 1 .
[Para 1 7] Reference now being made to Figure 1 , a block diagram is shown illustrating an example of a Hub network 1 00 for transferring data between various Cores 1 -5 residing in an integrated circuit 20 according to the teachings of the present invention. In this particular example, the Hub network 100 includes four Hubs 6-10 which are connected one to another so as to provide a communication path between Cores 1 -5 in accordance with a particular design. In a preferred embodiment of the present invention, a Hub is initially placed within a distance of one clock cycle of a Core (e.g. Hubs 6-7 and 9-10 for cores 1 and 4, and 3 and 5, respectively). In an alternative preferred embodiment, the Hubs operate at a multiple of
the frequency of the Cores 1 -5. Regardless of how the frequency is selected for the operation of the Hubs 6-7, it should be sufficient so as to meet the timing requirements of the Cores 1 -5. It should also be noted that the number of Hubs required to sufficiently transfer data among various Cores is dependent upon the distance between the Cores, desired number of redundant paths, and overall system design. As such, this particular example is used for ease of explanation and is not to be considered a limitation on the arrangement or number of cores that can be supported in a particular system implementation. The components of the Hubs 6-10 involved with providing communication are explained in greater detail in connection with Figure 2.
[Para 18] Reference now being made to Figure 2, a schematic diagram is shown illustrating in greater detail Hub 6 of Figure 1 according to the teachings of the preferred embodiment of the present invention. Hub 6 is representative of a Hubs 7-10, and therefore, the discussion provided therewith is equally applicable to Hubs 7-1 0. Hub 6 includes a Receive/Transmit Unit 202 and a Control Unit 204. [Para 19] The Receive /Transmit Unit 202 is responsible for receiving, storing, and transmitting data to/from other adjacent Hubs 7-1 0 or adjacent Cores 1 -5. The Receive/Transmit unit 202 receives data on Receive communication line 206, and transmits data on Transmit communication line 208. The Receive /Transmit unit 202 includes a FIFO (First In First Out memory mechanism) for storing received data via the Receive communication line 206, and temporarily
storing data for transmission on the Transmit communication line 208. For purposes of clarity, the Receive and Transmit communication lines 206 and 208, respectively are illustrated as being separate one from another. It should be noted, however, that these communication lines 206-208 can be implemented using a tagging scheme and shared bus or the like. The Control Unit 204 manages the receipt and transmission of data by the Receive /Transmit Unit 202 as explained below.
[Para 20] Control Unit 204 receives and transmits various signals to and from other adjacent Hubs (7-8) and Cores 1 -2. The receipt and transmission of these signals by the Control Unit 204 can be accomplished using individual communication lines for each of the signals as well as a tagging methodology in combination with a desired bus type structure. For each of the adjacent hubs (7-8) and adjacent Cores (1 -2), Control Unit 204 receives a Status/Flush signal 204a and a Select Hub signal 204c, and transmits a Select signal 204b and a Hub Status/Flush signal 204d. The interaction between the various signals, the Control Unit 204, and the Receive/Transmit Unit 202 is explained in connection with Figure 3.
[Para 21 ] Reference now being made to Figure 3, a flow chart is shown illustrating the method used by the Hubs 6-10 for receiving data from adjacent Hubs 6-10 and Cores 1 -5 according to the teachings of the present invention. For ease of explanation and clarity, Hub 6 (Figure 2) is used as an example of how the method is implemented in each of the Hubs 7-10. Prior to receiving any data,
Hub 6 via the Control Unit 204 receives a Select Hub signal 204c from one of the adjacent Hubs (7-8) or Cores (1 -2) (Step 302). In response to the Select Hub signal 204c, the Control Unit 204 communicates with the Receive /Transmit Unit 202 to verify that the FIFO has sufficient resources (e.g. memory) to receive the requested data (Step 304). If the FIFO does not have sufficient resources to receive and process the requested data, then the Control Unit 204 sends an indication that Hub 6 is currently busy via Hub Status/Flush signal 204d to the requesting adjacent Hub 7-8 (step 304) or Core (1 -2) (Step 304) (The processing of the busy signal is explained in connection with the transmission of data by a Hub (i.e. Figure 4)). If, however, the FIFO has sufficient resources to receive and process the requested data, then the Control Unit 204 sends an indication that Hub 6 can receive the requested data via Hub Status/Flush signal 204d. The adjacent Hub (7-8) or Core (1 -2) then beings to transfer the data according to the process described in connection with Figure 4.
[Para 22] It should be noted that in the preferred embodiment of the present invention, multiple Hubs can be used to simultaneously transmit the same data (e.g. when receipt of the data by one of the Cores 1 -5 is critical). In general, the transmission of the data is accomplished using packets or other similar type data structure for segmenting data into components that can be transferred individually and reassembled upon their receipt. Consequently, when there are multiple transmissions of the same data, the destination Core 1 -5 needs to be able to distinguish between different sets of the same data
and when to discard stale data. The present invention accomplishes this requirement by using unique identifiers to identify a particular set of data and affixes a time stamp to each packet (e.g. in the header) of data according to the time at which it was received by each preceding Hub 6-10. In the scenario where multiple sets of data are on route to a destination Core 1 -5, the destination Core 1 -5 examines the first packet it receives, records the unique identifier and time stamp. Any subsequently received duplicate sets of the same data (those packets having a unique identifier that is different from that of the first received packet) are ignored and a flush signal is sent to the transmitting Hub 6-10. The processing of the Flush signal is explained below.
[Para 23] If a flush signal has been previously received either from an adjacent Hub (6-10) or Core (1 -5), then the Control Unit 204 compares the unique identifier in the first packet that is received (Step 306), and if it matches that of the identifier in the flush signal, then a Flush signal is sent to the adjacent Hub 7-8 that is transmitting the data and any new data received having the flush identifier is ignored (Step 308). The processing of the receipt of a flush signal is explained in connection with the description of Figure 4 for the transmission of data by a Hub 6-10.
[Para 24] If, however, the identifier in the first received packet does not match that of a flush identifier, then the data/packet is stored in the FIFO (Step 314). If the Hub 6 is still selected via Select
Hub signal 204c (i.e. More data needs to be received), the processing
proceeds to Step 302 and repeats the method from that point (Step 316). If, however, the Hub 6 is not selected, then the processing ends until the Hub 6 is selected again (step 31 8).
[Para 25] Reference now being made to Figure 4, a flow chart is shown illustrating the steps used by the Hubs 6-1 0 for transmitting previously received data according to the teachings of the present invention. If there is data residing in the FIFO (step 402), then the processing of that data by the Control Unit 204 begins by examining the data to determine if it includes a prioritization scheme indicator. The prioritization scheme indicator can be, for example, an indication in the header of the packet to rank the priority of the data for processing. More specifically, the priority can be ranked and depending upon the a specified rank, the Hub 6-10 has the ability to transmit multiple copies of the same data to ensure that the data reaches the destination Core 1 -5 in the most expedient manner. In the preferred embodiment of the present invention, when the data has a prioritization scheme of a predefined rank/level, the transmitting Hub 6-10 will transmit multiple copies to all or some of the adjacent Hubs 6-10 depending upon the particular design implementation (Step 404).
[Para 26] The Control Unit 204 selects either a single or multiple adjacent Hubs 6-10 for receipt of the data via the Select signal 204b (the signal being transmitted to each adjacent Hub 6-10 (Step 406-406n). The selection of either single or multiple adjacent
Hubs 6-10 can also be based upon a weighted determination. For
example, the first attempt of the transmission of the data would be to a first preferred adjacent Hub 6-10. If the preferred adjacent Hub 6- 10 was busy, then an attempt to transmit the data to next preferred adjacent Hub 6-10 could occur and so on.
[Para 27] Upon receiving a Status/Flush signal 204a from one or more adjacent Hubs 6-10 or Cores 1 -5, the Control Unit 204 examines the Status/Flush signal 204a to determine if the selected adjacent Hub 6-1 0 is available. If the Status/Flush signal 204a indicates that the selected adjacent Hub 6-10 is currently unavailable (step 408), depending on the particular scheme employed the Control Unit 204 with either wait a predetermined period of time and then try again to select the adjacent Hub 6-10 via Select signal 204b, or try the next weighted adjacent Hub 6-10 again using Select signal 204b (Steps 410). The attempt to use the next weighted Hub 6-10 can either proceed down a vertical path (illustrated) where each weighted Hub 6-10 is attempted one after another or in a horizontal (parallel) fashion similar to that used for step 406 for launching multiple sets of the same data (not illustrated).
If the Control Unit 204 receives an indication that the selected [Para 28] If the Control Unit 204 receives an indication that the selected adjacent Hub 6-10 is available (step 41 2), then the Control Unit 204 transmits the data (in packets or the like) to the adjacent Hub 6-10 or Core 1 -5 via Transmission line 208. After transmitting a packet, the Control Unit 204 determines whether there
is additional related data to be transferred to the adjacent Hub 6-10 or Core 1 -2 (Step 414).
[Para 29] At this time, it is also possible that the Control Unit
204 could receive a flush indication via the Status/Flush signal 204a from the adjacent Hub 6-10 or Core 1 -5. The flush signal would include an indicator sufficient to coincide with the indicator used to identify the particular instance/set of data being transmitted as previously explained.
[Para 30] If a Flush signal was received, then the Control Unit
204 flushes the data identified in the flush signal that is still pending in the FIFO. In addition, the flush identifier is saved for a predetermined period of time so that if any preceding Hubs 6-1 0 transmit additional pieces of the now identified stale data (step 414). If there is either no more related data to be transmitted or the processing of the flush signal is complete, then the process proceeds to end at step 416.
[Para 31 ] It is thus believed that the operation and construction of the present invention will be apparent from the foregoing description. While the method and system shown and described has been characterized as being preferred, it will be readily apparent that various changes and/or modifications could be made without departing from the spirit and scope of the present invention as defined in the following claims.