Method and apparatus for transmitting data in an integrated circuit

A method and apparatus for transmitting data between cores residing in an integrated circuit. Data is transmitted by using hubs located between the cores and an arbiter. The arbiter maintains a table that contains all the valid combinations of routing paths between the cores.

BACKGROUND

1. Technical Field of the Present Invention

The present invention generally relates to integrated circuits and, more specifically, to the communication of data between cores that reside in an integrated circuit.

2. Description of Related Art

As manufacturing processes continue to become more complex and of smaller geometries, error-free communication of data between functional cores of an integrated circuit without introducing additional problems from noise, available space, and other similar issues is becoming increasingly difficult. Current methods for providing this communicated data use point-to-point or similar wiring techniques such as shared buses. Unfortunately, as integration density continues to increase, these techniques are becoming inefficient and prone to the introduction of errors.

It would, therefore, be a distinct advantage to have a method and apparatus that could transfer data from one core to another while reducing the issues typically associated with point-to-point wiring techniques and the like.

SUMMARY OF THE PRESENT INVENTION

In one aspect, the present invention is a method of transmitting data in an integrated circuit. The method includes the steps of creating multiple cores that implement a desired function and creating multiple hubs that transmit data between the cores. The method further includes the step of creating a table that contains all valid path routings for data to travel from a source core of the multiple cores to a destination core of the multiple cores using one or more of the hubs. The method also includes the step of selecting one of the valid path routings for transmitting data from a first source core to a first destination core. In addition, the method also includes the step of transmitting the data according to the selected path routing from the first source core to the first destination core.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT OF THE PRESENT INVENTION

The present invention is a method and apparatus for transmitting data between cores in an integrated circuit using hubs/routers that are coupled one to another. The data is segmented into data packets and transmitted from a source core to a destination core. Each data packet includes a header for specifying its path route from the source core to the destination core and the time spent at hub/routers. This information is centrally maintained and updated in an arbiter that organizes the information according to source to destination path and time. Prior to transmitting data, the source core queries the arbiter to determine which of the available paths is appropriate for the transmission.

Reference now being made toFIG. 1, a diagram of an integrated circuit100is shown that implements a communication system102of a preferred embodiment of the present invention. The communication system102includes a plurality of cores A-E, an arbiter108, arbiter bus106, and hubs/routers1-8. In order to simplify the ease with which the present invention can be understood and explained, a limited number of cores and hubs have been illustrated. In practice, the number of cores and hubs would be numerous and dependent upon the particular design being implemented.

Each one of the hubs1-8is coupled to another hub1-8or core A-E in such a fashion so as to provide communication of data between cores A-E in accordance with transfer timing (e.g., synchronous or asynchronous) and design constraints. In addition, each of the hubs1-8and cores A-E communicate with the arbiter108using the arbiter bus106(each core A-E is coupled to the arbiter bus106) as described in connection withFIG. 2below.

Reference now being made toFIG. 2a flow chart is shown illustrating the method for transmitting data from a source core to a destination core ofFIG. 1according to the teachings of a preferred embodiment of the present invention. The transmission of data from a source core (e.g., Core A) to a destination core (e.g., Core B) can take several different paths (e.g., hubs (1=>5=>8), (1=>5=>4=>8), (1=>6=>7=>8), (1=>2=>4=>8), etc.). Some of these paths can be congested or otherwise unavailable.

Prior to transmitting data packets, the source core will query the arbiter108for a routing path to the destination core (Steps200-202). The arbiter108is responsible for storing the potential paths for transmission of data from any one of the cores A-E to another core A-E and updating the time it takes for the data to actually travel one of these paths in real time as explained in connection withFIG. 4.

Based upon certain criteria such as time to reach the destination core and priority, the arbiter108upon receiving this request will return the routing path in the form of a header such as the example header300illustrated inFIG. 3(Step204). The header300includes the path the data packet should take from source core A to destination core B. In this example, the routing path is hubs1,2,3,4, and8.

In the preferred embodiment of the present invention, as the data packet travels from one hub to another, the time spent at the hub is recorded in the header of the data packet. Alternatively, the total time it takes for the transmission of the data packet from the source core to the destination core can be stored on any other means for indicating the relative congestion of the routing path.

In accordance with the preferred embodiment of the present invention, the header300includes a time storage location with each hub designation. In this case, since the transmission of the header is just beginning, the time storage fields are blank or otherwise initialized.

Upon receiving the path route, the source core A, generates data packets containing the header200and transmits them to hub1(Steps206-208) where they are further transmitted according to the indicated routing path.

Reference now being made toFIG. 4, a flow chart is shown illustrating the method used by the arbiter108and a destination core ofFIG. 1to store relevant transmission history information according to the preferred embodiment of the present invention. When a destination core receives a data packet from an adjacent hub, it transmits the header200information to the arbiter108with an indication of the time spent at each hub or the total transmission time for the indicated path route (Step400). In the present example, the header of a received data packet can take the form of header500ofFIG. 5. Header500represents header300updated to include the time spent at each of the hubs as shown. For instance, the data packet spent 0.007 seconds at hub1and 0.010 seconds at hub8with a total time of transmission of 0.033 seconds.

Reference now being made toFIG. 6, a diagram is shown illustrating a table602that is used by the arbiter108ofFIG. 1for saving path routing information received from a destination core according to the teachings of the preferred embodiment of the present invention. In the preferred embodiment of the present invention, the arbiter108includes memory (not shown) that can be used to store the table602that includes a source to destination field, a path field, a time field, and a rank field.

The source to destination field indicates the source core and destination core. The path field indicates the hubs (i.e., routing path) that the data packets will take when being transmitted to the destination core. The time field indicates the last recorded amount of time that a data packet following the indicated routing path took to reach the destination core from the source core. The rank field is used for indicating the relative rank of this row in the table600when compared to other rows having the same source and destination combination. In lieu of a rank field, the table600could be indexed on the time and source to destination field.

The table600includes all combinations for hub routing for any source to any destination core (not shown). As the destination cores provide the header information to the arbiter108, the arbiter108updates the matching record (row) to reflect the new time and reset the ranks accordingly.

As an example, the table600indicates that for source core A to destination core B the fastest routing path is hubs1,2,3,4, and8via its rank. As time progresses, the table600could be updated as indicated inFIG. 7to represent the data packets and sorted accordingly.

It should be noted that although the preferred embodiment uses a table with rows and columns, that any suitable data structure technique (e.g., link lists) could be used to track the fields noted above so that they can be accessed quickly and indexed appropriately.

The scheme used for determining which one of the path routing records to provide in response to a request for a particular source core and destination core can depend upon such things as hubs along the route path being available to transmit the packet data. If one or more of the hubs in the highest rank record for the route path indicate source to destination are unavailable, then the arbiter108selects the next highest rank record for this source to destination combination until it finds one that has the hubs available for this transaction.

The transmission of data packets from a source core to the indicated routing path provided by the arbiter108is explained below.

Reference now being made toFIG. 8, a schematic diagram is shown illustrating in greater detail the hub6ofFIG. 1according to the teachings of the preferred embodiment of the present invention. Hubs1-8are structurally equivalent one to another, and therefore, the discussion with respect to hub6is equally applicable to hubs1-8. Hub6includes a receive/transfer unit802and a control unit804.

The receive/transfer unit802receives, stores and transmits data packets from other adjacent hubs and cores via receive and transmit data lines806and808, respectively. Data packets are stored in the First In First Out (FIFO) memory mechanism as they are received and stored until they are either discarded or transmitted.

Control unit804manages the receipt and transmission of packet data by the receive/transfer unit802according to signals status/flush804a, select hub804c, select804b, and hub status/flush804din accordance with the flow chart ofFIG. 9.

Reference now being made toFIG. 9, a flow chart is shown illustrating the method used by a hub such as hub6ofFIG. 1for receiving packet data from an adjacent hub or core according to the teachings of the preferred embodiment of the present invention. Continuing with the explanation of hub6, the receipt of data packets by hub6begins when an adjacent hub or source core asserts the hub select signal804c(Step902). The control unit804verifies that the FIFO of the receive/transfer unit802has sufficient resources to receive the incoming packet data (Step904).

If there are insufficient resources the control unit804notifies the adjacent hub or source core that hub6is currently busy via hub status/flush signal804d. If sufficient resources exist then the control unit804notifies the adjacent hub or source core to transmit data packets (Step906)

In the preferred embodiment of the present invention, a hub or source core can simultaneously transmit multiple copies of the data when transmission is considered critical. When a hub or source core initiates multiple instantiations of the same data packets, unique identifiers are included in the header to indicate the instantiation to which the data packet belongs and that there are multiple instantiations. As a destination core receives a data packet, it records this information until the data transmission has been completed.

As explained below in connection with the receipt of data packets by a destination core, the destination core provides the headers of received data packets to the arbiter108. The arbiter108tracks when multiple instances of the same data is being transmitted, and upon receiving header information on the data packets for the first instance to reach the destination core, the arbiter108informs all other hubs that are holding or transmitting the other instance(s) to flush their FIFOs of these redundant data packet instances via the status/flush signal804a(Steps906-908, and918).

Received data packets are stored in the FIFO (Step914). If the select hub signal804cis still selected, then the source core or adjacent hub desires to send more packet data and the receipt of packet data proceeds back to step302and repeats the method from that point; otherwise, the receipt of the packet data ends (Step918).

Reference now being made toFIG. 10, a flow chart is shown illustrating the transmission of data packets by a hub ofFIG. 1according to the teachings of a preferred embodiment of the present invention. The control unit804processes any data packets stored in the FIFO according to any priorities that can be indicated in the headers of the data packets.

As previously discussed, the arbiter108can inform the hub that when it receives a certain data packet as identified with header information that the data packet should be transmitted to multiple adjacent hubs (Step404).

The control unit804checks whether an adjacent hub is available for receipt of data packets by asserting the status/flush signal804d(406-n). If the status/flush signal804aindicates that the adjacent hub is available then the control unit804instructs the receive/transfer unit802to transmit the data packets in the FIFO (Steps1012-1014).

If the status/flush signal804aindicates that the adjacent hub is busy then the control unit804waits a predetermined period of time and attempts the transmission again (Step1006)

It should be noted, that as the transmission of the data packets is proceeding that if this was part of a multiple instantiation that a flush signal can be received from the arbiter108via the status/flush signal804a. If a flush signal is received the control unit804instructs the receive/transfer unit802to flush the indicated data packets stored in the FIFO.

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.