WO2007139536A2 - A method and apparatus for transferring data between cores in an integrated circuit - Google Patents

A method and apparatus for transferring data between cores in an integrated circuit Download PDF

Info

Publication number
WO2007139536A2
WO2007139536A2 PCT/US2006/020462 US2006020462W WO2007139536A2 WO 2007139536 A2 WO2007139536 A2 WO 2007139536A2 US 2006020462 W US2006020462 W US 2006020462W WO 2007139536 A2 WO2007139536 A2 WO 2007139536A2
Authority
WO
WIPO (PCT)
Prior art keywords
data
integrated circuit
receive
hubs
cores
Prior art date
Application number
PCT/US2006/020462
Other languages
French (fr)
Other versions
WO2007139536A3 (en
Inventor
Adam J. Courchesne
Kenneth J. Goodnow
W. Riyon Harding
David W. Milton
Jason M. Norman
Clarence R. Ogilvie
Jason E. Rottella
Paul M. Schanely
Sebastian T. Ventrone
Original Assignee
International Business Machines Corporation
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by International Business Machines Corporation filed Critical International Business Machines Corporation
Priority to PCT/US2006/020462 priority Critical patent/WO2007139536A2/en
Priority to JP2009502750A priority patent/JP2009531771A/en
Publication of WO2007139536A2 publication Critical patent/WO2007139536A2/en
Publication of WO2007139536A3 publication Critical patent/WO2007139536A3/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/15Interconnection of switching modules
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/10Packet switching elements characterised by the switching fabric construction
    • H04L49/109Integrated on microchip, e.g. switch-on-chip
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/25Routing or path finding in a switch fabric
    • H04L49/252Store and forward routing

Definitions

  • 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.
  • 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.
  • FIG. 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
  • FIG. 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
  • 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
  • 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.
  • 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 .
  • FIG. 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.
  • 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.
  • 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).
  • the Hubs operate at a multiple of the frequency of the Cores 1 -5.
  • 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.
  • 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.
  • 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.
  • FIFO First In First Out memory mechanism
  • 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.
  • 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.
  • FIG. 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.
  • Hub 6 ( Figure 2) is used as an example of how the method is implemented in each of the Hubs 7-10.
  • Hub 6 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).
  • 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).
  • 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.
  • 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).
  • 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.
  • 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.
  • Step 306 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.
  • Step 302 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).
  • FIG. 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.
  • 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.
  • 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).
  • 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
  • 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.
  • the Control Unit 204 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).
  • 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).
  • the flush signal 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.
  • step 414 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.

Abstract

A method and apparatus for providing communication between various cores (1-5) located in an integrated circuit. The method and apparatus uses Hubs/Routers (6-10) to facilitate and manage communication of data from /between the cores (1-5) according to a specified methodology.

Description

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.

Claims

What is claimed is:
[Claim 1 ] 1 . An integrated circuit comprising: a plurality of cores each one capable of implementing a desired function; a plurality of hubs each one capable of receiving and transmitting data from one the cores initiating a data transfer to a destination at another one of the cores.
[Claim 2] 2. The integrated circuit of claim 1 wherein the plurality of hubs includes: a first set of hubs each one being associated with at least one of the cores each one of the first hubs capable of receiving and transmitting data to and from it's associated core.
[Claim 3] 3. The integrated circuit of claim 2 wherein the plurality of hubs includes: a second set of hubs each one being associated with at least one of the first set of hubs, each one of the second hubs capable of receiving and transmitting data to and from it's associated first hub(s).
[Claim 4] 4. The integrated circuit of claim 3 wherein the plurality of hubs includes: a third set of hubs each one being associated with at least one of the second hubs, each one of the third hubs capable of receiving and transmitting data to and from it's associated second hub.
[Claim 5] 5. The integrated circuit of claim 4 wherein each one of the first, second and third hubs includes: a receive/transfer unit capable of receiving and transferring data; and a control unit capable of controlling the receipt and transfer of data via the receive/transfer unit, and of receiving and transmitting various signals for maintaining data integrity.
[Claim 6] 6. The integrated circuit of claim 5 wherein the receive/transfer unit includes a FIFO for storing and transmitting data.
[Claim 7] 7. The integrated circuit of claim 6 wherein the control unit includes: a signal for indicating whether one of the hubs to which data is to be transferred is available.
[Claim 8] 8. The integrated circuit of claim 6 wherein the control unit includes: a signal for indicating whether one of the cores to which data is to be transferred.
[Claim 9] 9. The integrated circuit of claim 6 wherein the control unit is capable of transmitting a signal indicating the availability of the resources of the hub to which data is to be transferred.
[Claim 1 0] 10. The integrated circuit of claim 6 wherein the control unit includes: logic for transmitting multiple copies of the same data to differing hubs.
[Claim 1 1 ] 1 1 . An integrated circuit comprising: two or more cores of functional logic; and two or more local receive/transmit units each of which are adjacent with at least one of the cores, the adjacent receive/transmit units being capable of simultaneously receiving and transmitting data to/from one or more of the cores.
[Claim 1 2]
12. The integrated circuit of claim 11 further comprising: two or more intermediate receive/transmit units each of which are adjacent with at least one of the local receive/transmit units, the intermediate receive/transmit units being capable of simultaneously receiving and transmitting data to/from one or more of the cores.
[Claim 1 3] 1 3. The integrated circuit of claim 1 2 wherein one or more of the local adjacent receive/transmit units includes: logic capable of transmitting multiple copies of the same data to differing adjacent intermediate receive/transmit units.
[Claim 1 4] 14. The integrated circuit of claim 1 3 wherein one or more of the local adjacent receive /transmit units includes: logic capable of receiving a stale signal from one of the cores indicating that a copy of the data attempting to be transmitted to the core has already been received.
[Claim 1 5] 1 5. The integrated circuit of claim 14 wherein one or more of the local adjacent receive /transmit units includes: logic capable of deleting the data to be transferred to the core in response to receiving the stale signal.
[Claim 1 6] 16. The integrated circuit of claim 1 3 wherein one or more of the local adjacent receive/transmit units includes: logic for receiving and storing data from the one or more adjacent intermediate receive/transfer units.
[Claim 1 7] 1 7. The integrated circuit of claim 16 wherein one or more of the local adjacent receive/transmit units includes: logic for indicating to an adjacent intermediate receive/transfer attempting to transfer data to the local adjacent receive/transmit unit that the data is stale.
[Claim 1 8] 1 8. The integrated circuit of claim 1 7 wherein one or more of the intermediate adjacent receive/transmit units includes: logic capable of deleting, in response to the stale indication, any of the associated stale data.
[Claim 1 9] 1 9. The integrated circuit of claim 1 8 wherein each one of the local receive/transmit units includes: logic capable of receiving and storing data from the one or more adjacent cores.
[Claim 20] 20. The integrated circuit of claim 1 9 wherein each one of the intermediate receive/transmit units includes: logic capable of receiving and storing data from one or more of the adjacent local receive/transmit units.
PCT/US2006/020462 2006-05-21 2006-05-21 A method and apparatus for transferring data between cores in an integrated circuit WO2007139536A2 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/US2006/020462 WO2007139536A2 (en) 2006-05-21 2006-05-21 A method and apparatus for transferring data between cores in an integrated circuit
JP2009502750A JP2009531771A (en) 2006-05-21 2006-05-21 Method and apparatus for transferring data between cores in an integrated circuit

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2006/020462 WO2007139536A2 (en) 2006-05-21 2006-05-21 A method and apparatus for transferring data between cores in an integrated circuit

Publications (2)

Publication Number Publication Date
WO2007139536A2 true WO2007139536A2 (en) 2007-12-06
WO2007139536A3 WO2007139536A3 (en) 2009-05-07

Family

ID=38779124

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2006/020462 WO2007139536A2 (en) 2006-05-21 2006-05-21 A method and apparatus for transferring data between cores in an integrated circuit

Country Status (2)

Country Link
JP (1) JP2009531771A (en)
WO (1) WO2007139536A2 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI565265B (en) * 2013-03-20 2017-01-01 英派爾科技開發有限公司 Hybrid routers in multicore architectures

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020191588A1 (en) * 2001-06-13 2002-12-19 Drexel University Integrated circuit and packet switching system
US20030154324A1 (en) * 2002-02-13 2003-08-14 International Business Machines Corporation Hub/router for communication between cores using cartesian coordinates
US20040098518A1 (en) * 2002-11-20 2004-05-20 Beckett Richard C. Integrated circuit having multiple modes of operation

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000082011A (en) * 1998-05-13 2000-03-21 Axis Ab Improved memory access method using dma unit and computer system
JP2001167066A (en) * 1999-12-08 2001-06-22 Nec Corp Inter-processor communication method and multiprocessor system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020191588A1 (en) * 2001-06-13 2002-12-19 Drexel University Integrated circuit and packet switching system
US20030154324A1 (en) * 2002-02-13 2003-08-14 International Business Machines Corporation Hub/router for communication between cores using cartesian coordinates
US20040098518A1 (en) * 2002-11-20 2004-05-20 Beckett Richard C. Integrated circuit having multiple modes of operation

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI565265B (en) * 2013-03-20 2017-01-01 英派爾科技開發有限公司 Hybrid routers in multicore architectures

Also Published As

Publication number Publication date
WO2007139536A3 (en) 2009-05-07
JP2009531771A (en) 2009-09-03

Similar Documents

Publication Publication Date Title
CN105677608B (en) A kind of how main RS485 bus arbitration method and system
US5889776A (en) Physical layer switch system for ethernet local area network communication system
US10104006B2 (en) Bus interface apparatus, router, and bus system including them
JP2551304B2 (en) Broadcast link control method
EP0373161B1 (en) Switching arrangement and method
US20030118040A1 (en) Fibre channel arbitrated loop bufferless switch circuitry to increase bandwidth without significant increase in cost
US20030174720A1 (en) Fibre channel arbitrated loop bufferless switch circuitry to increase bandwidth without significant increase in cost
JPH08265270A (en) Transfer line assignment system
EP2378742A1 (en) Method for data communication and device for ethernet
KR101699784B1 (en) Bus system and operating method thereof
CN107766267B (en) Arbitration method and system for I2C bus
JP4992296B2 (en) Transfer processing device
US20050169262A1 (en) Method and system for transmitting data via switchable data networks
GB2411985A (en) Bus arrangement for reducing response time in a System on a Chip
CN101385291A (en) System and method for transferring data packets through a communication system
JPH06237256A (en) Fddi station bypass device
CN107453895B (en) Method for configuring a communication path and first communication node forming a vehicle network
US20060262779A1 (en) A method and apparatus for transferring data between cores in an integrated circuit
CN109144914A (en) Communication means and CPLD between a kind of storage server, mainboard and hard disk
CN107682162A (en) Electronic equipment, network share method and device
US9660835B2 (en) Bidirectional packet transfer fail-over switch for serial communication
US20130208727A1 (en) Apparatus & method
WO2007139536A2 (en) A method and apparatus for transferring data between cores in an integrated circuit
US8559424B2 (en) Data communication method and communication apparatus
SE456629B (en) PROCEDURE AND DEVICE FOR TRANSFERING INFORMATION FROM A BUS SYSTEM

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 06771305

Country of ref document: EP

Kind code of ref document: A2

WWE Wipo information: entry into national phase

Ref document number: 2009502750

Country of ref document: JP

NENP Non-entry into the national phase in:

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 7028/CHENP/2008

Country of ref document: IN

122 Ep: pct application non-entry in european phase

Ref document number: 06771305

Country of ref document: EP

Kind code of ref document: A2