Multi-path routing in network-on-chip

Abstract

Embodiments herein describe a network-on-chip (NoC) that implements multi-path routing (MPR) between an ingress logic block and an egress logic block. Different alias destination IDs corresponding to the same destination ID may be assigned to multiple paths between the ingress logic block and the egress logic block. The NoC may route packets along different paths through an interconnect switch in the NoC using the alias destination ID.

Description

Technical Field

[0001] Examples of the present disclosure generally relate to multipath routing in a network-on-chip (NoC). Background Art

[0002] A system-on-chip (SoC) (e.g., a field-programmable gate array (FPGA), a programmable logic device (PLD), or an application-specific integrated circuit (ASIC)) may include a packet network structure called a NoC to route data packets between circuit elements (e.g., programmable logic blocks, processors, memories, etc.) in the SoC.

[0003] The NoC may include an ingress logic block (e.g., a master block) that performs read requests or write requests on an egress logic block (e.g., a slave block). Most solutions use single-path routing (SPR), in which one path is selected to route all packets transmitted between the ingress logic block and the selected egress logic block. That is, in SPR, the ingress logic block routes data through the NoC to the egress logic block using only one path.

[0004] In contrast, multipath routing (MPR) establishes multiple routes between the ingress logic block and the egress logic block. However, considering the disordered reception of data due to different delays in multiple paths, current MPR techniques generally rely on reordering buffers at the egress logic block. In addition, many solutions place routing information in the packets being sent, which increases packet overhead. Summary of the Invention

[0005] One example is an integrated circuit including a first circuit element, a second circuit element, and a network-on-chip (NoC) configured to communicatively couple the first circuit element and the second circuit element. The NoC is configured to receive, at an ingress logic block, a packet from the first circuit element to be sent to the second circuit element, determine a destination of the packet using multipath routing (MPR) in the NoC, and assign an alias destination ID corresponding to the destination based on a bandwidth utilization required for multiple paths used to send data from the ingress logic block to an egress logic block in the NoC, wherein each path among the multiple paths between the ingress logic block and the egress logic block has a different alias destination ID.

[0006] Another example is a method that includes: receiving, at an ingress logic block of a NoC, a packet from a first circuit element to be sent to a second circuit element coupled to the NoC, determining a destination of the packet using multipath routing (MPR) in the NoC, and allocating an alias destination ID corresponding to the destination based on a bandwidth utilization required for multiple paths used to send data from the ingress logic block to an egress logic block in the NoC, wherein each of the multiple paths between the ingress logic block and the egress logic block has a different alias destination ID.

[0007] Another example is an integrated circuit that includes a first circuit element, a second circuit element, and a NoC, where the first circuit element is assigned a first ID and the second circuit element is assigned a second ID different from the first ID. The NoC includes an ingress logic block configured to receive packets from the first circuit element and the second circuit element to be sent through the NoC to the same egress logic block in the NoC, where the ingress logic block is configured to allocate, through the NoC, a first alias destination ID used by a packet received from the first circuit element to reach the egress logic block corresponding to a first path, and to allocate, through the NoC, a second alias destination ID used by a packet received from the second circuit element to reach the egress logic block corresponding to a second path. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] To enable a detailed understanding of the manner in which the above-described features can be obtained, a more specific description briefly summarized above can be acquired by reference to example embodiments, some of which are illustrated in the accompanying drawings. It should be noted, however, that the drawings illustrate only typical example embodiments and are therefore not to be considered limiting of their scope.

[0009] Figure 1 is a block diagram of a SoC including a NoC according to one example.

[0010] Figure 2A illustrates a NoC lacking sufficient link bandwidth to perform SPR according to one example.

[0011] Figure 2B illustrates using MPR to solve Figure 2A the routing problem in

[0012] Figure 3 is a flowchart of performing MPR according to one example.

[0013] Figure 4 illustrates packet processing circuitry in an ingress logic block according to one example.

[0014] Figure 5 is a flowchart of performing MPR according to one example.

[0015] Figure 6 Illustrates the grouping processing circuit in the ingress logic block according to one example.

[0016] For ease of understanding, where possible, the same reference numerals are used to denote the same elements common to the drawings. It is contemplated that an element of one example may be advantageously incorporated into other examples. Detailed Description

[0017] Various features are described hereinafter with reference to the drawings. It should be noted that the drawings may or may not be drawn to scale, and elements of similar structure or function are denoted by like reference numerals throughout the drawings. It should be noted that the drawings are only intended to facilitate the description of the features. They are not intended to provide an exhaustive description of the following examples nor to limit the scope of the claims. Additionally, the examples illustrated need not have all aspects or advantages shown. Aspects or advantages described in connection with a particular example are not necessarily limited to that example and may be practiced in any other example even if not so illustrated or explicitly described.

[0018] The embodiments herein describe a NoC implementing MPR between an ingress logic block and an egress logic block. In one embodiment, if during configuration, the router determines that the NoC does not have a single path with sufficient available bandwidth to satisfy the traffic that the ingress logic block needs to transmit to the egress logic block, the router uses MPR by identifying sufficient available bandwidth in multiple paths in the NoC.

[0019] In one embodiment, the ingress logic block may provide services to multiple components (e.g., circuit elements) assigned different IDs (e.g., different Advanced eXtensible Interface (AXI) IDs). If there is a path with sufficient available bandwidth for the traffic generated by each of the components therein, the router may assign the flow of each component to a corresponding path among the paths using an alias destination ID. For example, traffic received at the ingress logic block of component 1 may be assigned an alias ID 1 and routed to the egress logic block using path 1 in the NoC. Traffic received at the ingress logic block of component 2 may be assigned an alias ID 2 and routed to the same egress logic block using path 2 in the NoC, and so on.

[0020] However, if the ingress logic block does not serve multiple components, or the NoC does not have a corresponding path with sufficient available bandwidth for the traffic generated by multiple components, different MPR techniques can be used. In this example, multiple paths can be selected in which their total available bandwidth meets the bandwidth requirements for the connection between the ingress logic block and the selected egress logic block. The ingress logic block can then assign packets to different alias IDs corresponding to different paths. For example, if between the ingress logic block and the egress logic block, path 1 provides two-thirds of the bandwidth and path 2 provides one-third of the bandwidth, the ingress logic block can assign every two packets to the alias ID of path 1 and for every one packet, it assigns to the alias ID of path 2. Additionally, since ordering may be important for packets with overlapping addresses, the ingress logic block can ensure that packets with overlapping addresses are transmitted on the same path so that these packets are received in order at the egress logic block.

[0021] Figure 1 FIG. is a block diagram of an SoC 100 including a NoC 105 according to an example. In one embodiment, the SoC 100 is implemented using a single integrated circuit (IC). In one embodiment, the SoC 100 includes a mix of hardened logic and programmable logic. For example, a hardened circuit can be used instead of a programmable circuit to form the NoC 105, such that its footprint in the SoC 100 is reduced.

[0022] As shown, the NoC 105 interconnects programmable logic (PL) block 125A, PL block 125B, processor 110, and memory 120. That is, the NoC 105 can be used in the SoC 100 such that different hardened circuit elements and programmable circuit elements in the SoC 100 can communicate. For example, PL block 125A can communicate with PL block 125B using one ingress logic block 115 (also referred to as a NoC master unit (NMU)) and communicate with processor 110 using another ingress logic block 115. However, in another embodiment, PL block 125A can communicate with both PL block 125B and processor 110 using the same ingress logic block 115 (assuming the endpoints use the same communication protocol). PL block 125A can send data to the corresponding egress logic blocks 140 (also referred to as NoC slave units or NoC subordinate units (NSUs)) for PL block 125B and processor 110, and the PL block and the processor can determine whether the data is intended for them based on the address (if using a memory-mapped protocol) or the destination ID (if using a streaming protocol).

[0023] The PL block 125A may include an egress logic block 140 that is configured to receive data transmitted by the PL block 125B and the processor 110. In one embodiment, the hardware logic block (or hardware logic circuit) is capable of communicating with all other hardware logic blocks that are also connected to the NoC 105. However, in other embodiments, the hardware logic block may only communicate with a sub - set of other hardware logic blocks that are connected to the NoC 105. For example, the memory 120 may be capable of communicating with the PL block 125A, but not with the PL block 125B.

[0024] As described above, the ingress logic block 115 and the egress logic block 140 may all use the same communication protocol to communicate with the PL block 125, the processor 110, and the memory 120, or they may use different communication protocols. For example, the PL block 125A may use a memory - mapped protocol to communicate with the PL block 125B, while the processor 110 uses a streaming protocol to communicate with the memory 120. In one embodiment, the NoC 105 may support multiple protocols.

[0025] In one embodiment, the SoC 100 is an FPGA that configures the PL block 125 according to a user design. That is, in this example, the FPGA includes both programmable logic blocks and hardened logic blocks. However, in other embodiments, the SoC 100 may be an ASIC that only includes hardened logic blocks. That is, the SoC 100 may not include the PL block 125. Even in this example, although the logic blocks are not programmable, the NoC 105 may still be programmable such that hardened logic blocks such as the processor 110 and the memory 120 can switch between different communication protocols, change the data width at the interface, or adjust the frequency.

[0026] In addition, Figure 1 Illustrated are the connections and the various switches 135 (marked as boxes with "X") used by the NoC 105 to route packets between the ingress logic block 115 and the egress logic block 140.

[0027] The positions of the PL block 125, the processor 110, and the memory 120 in the physical layout of the SoC 100 are merely an example of the arrangement of these hardware elements. In addition, the SoC 100 may include more hardware elements than shown. For example, the SoC 100 may include additional PL blocks, processors, and memories located at different positions on the SoC 100. In addition, the SoC 100 may include other hardware elements such as I / O modules and memory controllers, which may or may not be coupled to the NoC 105 using the corresponding ingress logic block 115 and egress logic block 140. For example, the I / 0 module may be arranged around the periphery of the SoC 100.

[0028] Figure 2A Illustrates that part of the SPR cannot be executed due to insufficient link bandwidth in the NoC 105 according to an example. Figure 2A Illustrates an attempt to configure the NoC 105 such that the ingress logic blocks 115A to 115D can be correspondingly connected to the egress logic blocks 140A to 140D. In this case, the router (e.g., a software application stored in a memory and executed by one or more processors in the computing system) attempts to configure the NoC 105 such that the ingress logic block 115A is connected to the egress logic block 140A through the NoC 105, the ingress logic block 115B is connected to the egress logic block 140B through the NoC 105, the ingress logic block 115C is connected to the egress logic block 140C through the NoC 105, and the ingress logic block 115D is connected to the egress logic block 140D through the NoC 105.

[0029] In this case, the connection between the ingress logic block 115A and the egress logic block 140B uses 66% of the bandwidth of the link 0 (L0) between the switches 135A and 135B, the connection between the ingress logic block 115C and the egress logic block 140C uses 100% of the bandwidth of the link 1 (L1) between the switches 135C and 135D, and the connection between the ingress logic block 115D and the egress logic block 140D uses 66% of the bandwidth of the link 2 (L2) between the switches 135E and 135F. However, as shown in the figure, the path 205 between the ingress logic block 115B and the egress logic block 140B also needs to use 66% of the bandwidth of L0. Since the router has already allocated the connection between the ingress logic block 115A and the egress logic block 140A to L0, there is not enough available bandwidth on this link for the connection between the egress logic block 115B and the egress logic block 140B.

[0030] In addition, the router may also consider using the other links L1 and L2 to route the path 205 between the egress logic block 115B and the egress logic block 140B. However, there is not enough available bandwidth on these links either. Therefore, when using SPR, Figure 2A Illustrates a scenario where not all connections can be routed.

[0031] Figure 2B Illustrates using MPR to solve the Figure 2A routing problem in accordance with an example. That is, if the NoC 105 supports MPR, then all the connections in Figure 2A can be routed. In Figure 2BAmong them, the traffic connecting the ingress logic block 115B and the egress logic block 140B is split, with half of the traffic using L0 along path 210 and the other half using L2 along path 215. That is, paths 210 and 215 use different sets of switches 135 to reach the egress logic block 140B. Therefore, Figure 2B Illustrates that in the case where the bandwidth requirement between the ingress logic block 115 and the egress logic block 140 is not satisfied by any single path or connection through the NoC 105, MPR can be used. Instead, multiple paths can be identified in which their total available bandwidth meets or exceeds the bandwidth requirement of the paired ingress and egress logic blocks.

[0032] The following discussion describes various techniques for performing MPR in a NoC.

[0033] Figure 3 Is a flowchart of a method 300 for performing MPR according to an example. At block 305, the router determines whether a route in the NoC satisfies the bandwidth (BW) for the connection between the ingress logic block and the egress logic block. If it is satisfied, method 300 proceeds to block 310, in which the router allocates the route to be used by the ingress logic block to exchange packets with the egress logic block. That is, the available bandwidth of a single route in the NoC is sufficient to meet the bandwidth requirement between the ingress logic block and the egress logic block.

[0034] However, assuming that the NoC does not have a single route with sufficient available bandwidth, method 300 proceeds to block 315, in which the route determines whether the ingress logic block serves multiple components. In some hardware deployments, the ingress logic block can serve multiple components (e.g., master components) such as peripheral devices assigned with corresponding IDs (i.e., different AXI IDs). Figure 2B Illustrates two components 220A and 220B connected to the ingress logic block 115B. Different AXI IDs can be assigned to these components 220A and 220B.

[0035] In AXI, transactions corresponding to the same component 220 should arrive at the destination in the order in which the transactions are issued, regardless of their addresses. That is, all packets generated by the ingress logic block 115B under the command of component 220A should arrive at the egress logic block 140B in the same order in which the ingress logic block 115B sends those packets. In contrast, transactions from components with different IDs to the same destination are independent and can be issued in any order. For example, if the ingress logic block 115B first sends the packets of component 220A and then the packets of component 220B, the packets of component 220B can arrive at the egress logic block 140B before the packets of component 220A without violating any AXI ordering constraints.

[0036] Return to block 320. If the ingress logic block does not serve multiple components with independent IDs, method 300 proceeds to block 320 to perform the flow split discussed in Figure 5 and Figure 6 .

[0037] However, if the ingress logic block does serve multiple components with independent IDs, method 300 proceeds to block 325, where the router determines whether there is a path that satisfies the BW of each of the components therein. Using Figure 2B as an example, assume that component 220A requires 50% of the bandwidth of one of links L0 through L2. In this case, no link would have enough available bandwidth for the traffic generated by component 220A. In other words, the NoC does not have a link with enough bandwidth to serve the traffic generated by each component 220. In this case, method 300 proceeds to block 320, where flow splitting (discussed below) can be performed.

[0038] However, if component 220A and component 220B require 34% or less of the bandwidth of the link, the link has enough available bandwidth. For example, L0 can be used to serve the traffic generated by component 220A, as shown by path 210, while L2 can be used to serve the traffic generated by component 220B, as shown by path 215. Thus, in this example, the router has identified paths that can be allocated to serve the traffic of each component 220.

[0039] Method 300 then proceeds to block 330, where the router generates an alias ID for each path identified at block 325. In one embodiment, the alias ID can be used to represent different paths to the same egress logic block. One alias ID can be used by the traffic generated by Figure 2B component 220A in

[0040] while another alias ID can be used by the traffic generated by component 220B. Thus, the traffic of component 220A uses path 210 to reach egress logic block 140B, while the traffic of component 220B uses path 215 to reach egress logic block 140B. This ensures that the traffic generated by one of the components 220 arrives at egress logic block 140B in order. However, since there are different delays on paths 210 and 215, the combined traffic of components 220A and 220B may arrive out of order relative to their transmission order at ingress logic block 115B, but this does not violate the communication protocol used by the NoC. Figure 2BConfigure the routing in the NoC according to the routing table in switch 135 therein. Thus, when switch 135C receives a packet from ingress logic block 115B, switch 135C can evaluate the alias ID (i.e., destination ID) in the packet. If the packet has an alias ID for path 210, the routing table indicates that the next hop is to reach switch 135A, but if the packet has an alias ID for path 215, the routing table indicates that the next hop is to reach switch 135E. In this way, the router can generate a routing table in each switch 135 to support MPR.

[0041] Advantageously, this MPR technique does not require additional hardware in switch 135, although they may have a slightly larger routing table in memory, because when using MPR, egress logic block 140 can be associated with multiple alias IDs.

[0042] In one embodiment, method 300 can be executed for each ingress logic block in the NoC. Additionally, if an ingress logic block is connected to multiple egress logic blocks, method 300 can be executed for each of these connections.

[0043] Figure 4 Illustrates packet processing circuit 400 in an ingress logic block according to an example. Packet processing circuit 400 can be used to execute the MPR technique described in method 300. As shown, circuit 400 includes request FIFO 405, which stores requests received from an upstream circuit (e.g., Figure 2B components 220 therein). Address map 410 receives requests (or transactions) from FIFO 405 and contains address ranges and corresponding destination IDs of egress logic blocks. In one embodiment, the ingress logic block performs a lookup in address map 410 using the address in the request (e.g., packet) to identify the destination ID.

[0044] Then, the destination ID is passed to alias ID map 415, which stores the mapping of the destination ID to its corresponding alias ID, which is generated at block 330 of method 300. Alias ID map 415 can use the destination ID and the ID of the component submitting the request (e.g., AXI ID) to identify the corresponding alias ID. That is, hitting alias ID map 415 generates an alias ID for the request (or more specifically, for the packet corresponding to the request).

[0045] Then, the alias ID and the request are transmitted to the grouper 420, which generates a packet containing the alias ID for the request. The resulting packet can then be sent to the switch 135 in the NoC, which, as discussed above, has a routing table that includes the alias ID, which is used to determine how to route packets corresponding to different alias IDs (and different components) to the same egress logic block on different routes or paths.

[0046] Figure 5 is a flowchart of a method 500 for performing MPR according to an example. In one embodiment, method 500 describes flow splitting. In one embodiment, method 500 is performed when the NoC does not have multiple master components (e.g., Figure 3 in block 315) or when the NoC does not have links with sufficient bandwidth to support traffic from each master component (e.g., Figure 3 in block 325). However, in another embodiment, method 500 can be used in all cases. That is, the flow splitting described in method 500 can be a general use case that can be applied to any situation where a single route with sufficient bandwidth between the ingress logic block and the egress logic block cannot be identified.

[0047] At block 505, the ingress logic block performs a lookup in the address map to identify the destination of the received packet. The address map can store the destination ID for each destination supported by the NoC.

[0048] At block 510, the ingress logic block uses the identified destination to determine whether the destination is part of the MPR. In one embodiment, the ingress logic block queries the alias map, which determines whether a particular destination ID corresponds to multiple alias destination IDs. If not, data is routed from the ingress logic block to the destination using SPR routing. In this case, method 500 proceeds to block 515, in which the ingress logic block routes the data through the NoC using the destination ID via SPR.

[0049] However, if the ingress logic block determines that the destination ID is associated with multiple alias destination IDs, the method proceeds to block 515, in which the ingress logic block queries the overlap table to determine whether there is a data dependency between the current packet and previously transmitted packets that are still being sent to the destination. In one embodiment, the overlap table stores information about in-use packets (e.g., packets that have been sent by the ingress logic block but have not yet received an acknowledgment of receipt from the egress logic block), and the ingress logic block has sent the in-use packets to the egress logic block corresponding to each destination. The overlap table can store the addresses corresponding to these packets. The ingress logic block can compare the address (or address range) with the addresses or address ranges of the packets stored in the overlap table.

[0050] At block 520, the ingress logic block determines whether the address or address range of the current packet is the same as or overlaps with the address or address range of any in-use packet, indicating a match. For example, if the address range of the current packet is 0 to 16 and the address range of an in-use packet to the same destination is 16 to 32, the addresses do not overlap (i.e., there is no match). However, if the address range of the current packet is 0 to 16 and the address range of the in-use packet is 10 to 15, the address ranges overlap and there is a match.

[0051] In this embodiment, when the addresses overlap at least partially, this means that the packets should arrive at the egress logic block in the order in which they are sent by the ingress logic block. That is, since the packets are accessing overlapping memory, it is important to process these packets at the destination in the order in which they are sent by the ingress logic block. For example, assume that the first packet sent by the ingress logic block changes data corresponding to its address range, and a second packet sent subsequently reads that data. If the first packet is sent through the NoC to the egress logic block using a path with a longer latency than the second packet, the second packet may arrive at the egress logic block before the first packet. Thus, the read performed by the second packet will read "stale" data because the destination will process this "stale" data first.

[0052] In contrast, if the first and second packets do not overlap, they can be executed by the destination in any order because there are no data dependencies between the packets. That is, for in-use packets with non-overlapping address ranges, the order does not matter.

[0053] If the ingress logic block determines that the current packet overlaps with an in-use packet, method 500 proceeds to block 525, where the ingress logic block assigns the alias destination ID of the matching in-use packet to the current packet. By assigning the same alias destination ID, this ensures that the current packet uses the same path as the in-use packet that reaches the egress logic block through the NoC, thus guaranteeing the sequential reception of packets at the egress logic block. This ensures that the destination processes the packets in order and thus correctly handles any data dependencies that exist between the packets.

[0054] Conversely, if no match exists, method 500 proceeds to block 530, where the ingress logic block assigns an alias destination ID based on the ratio of the bandwidth. For example, assume that the ingress logic block has three different links to the egress logic block, where 33%, 33%, and 66% of the bandwidth of these paths is allocated to serve the data connection between the ingress logic block and the egress logic block. Assume that the total bandwidth of these three paths is the same. In this case, the ingress logic block assigns two packets to use the third path, and for each packet, it assigns to the first path and the second path. Thus, the ingress logic block can use any allocation technique (e.g., round-robin) to assign packet alias IDs so as to achieve the desired bandwidth ratio. This can also consider packets that are forced to use the same path due to address overlap. For example, if the ingress logic block transmits two subsequent packets on the first path because their addresses overlap, it can transmit the next two packets on the second path and the next four packets on the third path (assuming their addresses do not overlap) to maintain the desired bandwidth utilization between the paths.

[0055] At block 535, the ingress logic block packets and injects the packets into the switching network. That is, the ingress logic block can add the corresponding alias destination ID (or the actual destination ID in the case of using SPR) to the packet and transmit the packet to the switch connected to the ingress logic block. As discussed above, the routing table in the switch can be configured to identify the actual destination ID and the alias destination ID (if MPR is enabled) so that the packet can be routed to the egress logic block on the correct path.

[0056] Figure 6 Illustrated is a packet processing circuit 600 in an ingress logic block according to one example. The packet processing circuit 600 can be used to perform the MPR technique described in method 500. As shown, the circuit 600 includes a request FIFO 605 that stores requests received from an upstream circuit (e.g., Figure 2B component 220 therein). The address mapping 610 receives requests (or transactions) from the FIFO 605 and contains the address range and the corresponding destination ID of the egress logic block. In one embodiment, a lookup is performed in the address mapping 610 using the address in the request (e.g., packet) to identify the destination ID.

[0057] Then, the destination ID is transmitted to the alias ID mapping 615, which stores the mapping of the destination ID to its corresponding alias ID when MPR is enabled in the NoC. The alias ID mapping 615 can use the destination ID to identify the corresponding alias ID. That is, hitting the alias ID mapping 615 generates an alias ID for the request (or more specifically, for the packet corresponding to the request). Thus, in Figure 5At block 510, the ingress logic block can query the alias ID mapping 615 to determine if the destination ID is part of an MPR (i.e., the destination ID has multiple alias destination IDs).

[0058] Circuit 600 also includes an overlap table 620 that keeps track of in-use packets previously sent by the ingress logic block. If the ingress logic block sends data to multiple destinations, the overlap table 620 can keep track of the in-use packets for each of these destinations. Once a packet is no longer in an in-use state (e.g., the egress logic block for that destination has acknowledged receipt of the packet), the packet can be removed from the overlap table 620.

[0059] As discussed above, the ingress logic block can use the overlap table 620 at Figure 5 blocks 515 and 520 to determine if the current packet matches one of the in-use packets stored in the overlap table 620 (e.g., the address range of the current packet overlaps with the address range of one of the in-use packets going to the same destination). If there is a match, this indicates that the current packet should be transmitted on the same path (e.g., assigned the same alias ID) as the in-use packet, thus maintaining order. If there is no match, the ingress logic block can assign an alias destination ID to meet the bandwidth utilization requirements for the path to reach the egress logic block.

[0060] Then, the alias ID and the request are transmitted to the packetizer 625, which generates a packet containing the alias ID for the request. Then, the resulting packet can be sent to switch 135 in the NoC, which, as discussed above, has a routing table that includes alias destination IDs used to determine how to route packets corresponding to different alias IDs to the same egress logic block on different routes or paths.

[0061] It should be noted that Figure 4 and Figure 6 the process for assigning an alias ID to route data to an egress logic block can be applied to an egress logic block that assigns a source ID to route data to an ingress logic block. That is, the source ID of the ingress logic block can also be aliased to route the packet back to the source on the corresponding path.

[0062] Previously, reference has been made to embodiments presented in the present disclosure. However, the scope of the present disclosure is not limited to the specifically described embodiments. Instead, any combination of the described features and elements (whether or not they relate to different embodiments) is contemplated for implementing and practicing the contemplated embodiments. Moreover, although the embodiments disclosed herein may achieve advantages over other possible solutions or over the prior art, whether a particular advantage is achieved by a given embodiment does not limit the scope of the present disclosure. Accordingly, the foregoing aspects, features, embodiments, and advantages are illustrative only and are not to be considered elements or limitations of the appended claims unless expressly recited therein.

[0063] As will be understood by those skilled in the art, the embodiments disclosed herein may be embodied as a system, method, or computer program product. Accordingly, aspects may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, all of which may herein be generally referred to as a "circuit," "module," or "system." Moreover, aspects may take the form of a computer program product embodied in one or more computer-readable media having computer-readable program code embodied thereon.

[0064] Any combination of one or more computer-readable media may be utilized. A computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium may be, for example but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer-readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium is any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0065] A computer-readable signal medium may include a propagated data signal having computer-readable program code embodied therein (e.g., in baseband or as part of a carrier wave). Such a propagated signal may take any of a variety of forms, including but not limited to electromagnetic, optical, or any suitable combination thereof. A computer-readable signal medium may be any computer-readable medium that is not a computer-readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

[0066] The program code embodied on a computer-readable medium can be transmitted using any appropriate medium, including but not limited to wireless, wired, fiber optic cable, RF, etc. or any suitable combination of the foregoing.

[0067] The computer program code for performing operations for aspects of the present disclosure can be written in any combination of one or more programming languages, including object-oriented programming languages (such as Java, Smalltalk, C++, etc.) and conventional procedural programming languages (such as the "C" programming language or similar programming languages). The program code can be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0068] Aspects of the present disclosure are described below with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments presented in the present disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general purpose computer, a special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions executed by the processor of the computer or other programmable data processing apparatus create means for implementing the functions / acts specified in one or more blocks of the flowchart and / or block diagram.

[0069] These computer program instructions can also be stored in a computer-readable medium that can direct a computer, other programmable data processing apparatus, or other device to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instructions for implementing the functions / acts specified in one or more blocks of the flowchart and / or block diagram.

[0070] The computer program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to produce a computer-implemented method, such that the instructions executed on the computer or other programmable apparatus provide a process for implementing the functions / acts specified in one or more blocks of the flowchart and / or block diagram.

[0071] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various examples of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of instructions that includes one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, depending on the functionality involved, two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order. It will also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, can be implemented by a dedicated hardware-based system that performs the specified functions or acts, or combinations of dedicated hardware and computer instructions.

[0072] While the foregoing is directed to specific examples, other and additional examples can be devised without departing from the basic scope of the present invention, and the scope of the present invention is determined by the appended claims.

Claims

1. An integrated circuit, the integrated circuit comprises: a first circuit element; a second circuit element; and a Network-on-Chip (NoC), the NoC being configured to communicatively couple the first circuit element and the second circuit element, the NoC being configured to: receive, at an ingress logic block, a packet to be sent from the first circuit element to the second circuit element, determine a destination of the packet using Multipath Routing (MPR) in the NoC, and allocate an alias destination ID corresponding to the destination based on a bandwidth utilization required for a plurality of paths for sending data from the ingress logic block in the NoC to an egress logic block, wherein each path among the plurality of paths between the ingress logic block and the egress logic block has a different alias destination ID.

2. The integrated circuit according to claim 1, wherein the NoC is configured to: receive, at the ingress logic block, a second packet to be sent from the first circuit element to the second circuit element; and when determining that an address of the packet matches an address of an in-use packet previously sent to the destination, allocate the second packet the same alias destination ID as that allocated to the in-use packet, such that the second packet reaches the egress logic block through the NoC using the same path as the in-use packet.

3. The integrated circuit according to claim 2, wherein the ingress logic block includes an overlap table configured to store an address range of the in-use packet sent from the ingress logic block to the egress logic block.

4. The integrated circuit according to claim 2, wherein allocating the second packet the same alias destination ID as the in-use packet ensures that the second packet and the in-use packet arrive at the egress logic block in the same relative order as that in which the second packet and the in-use packet have been sent from the ingress logic block.

5. The integrated circuit according to claim 1, wherein the required bandwidth usage rate is based on a percentage of the bandwidth of each path among the plurality of paths that the ingress logic block is permitted to use to send a packet to the egress logic block, wherein the percentage of the bandwidth that the ingress logic block is permitted to use for each path among the plurality of paths is less than 100%.

6. The integrated circuit according to claim 1, wherein the NoC is configured to, before determining that the destination of the packet uses MPR: look up an address mapping in the ingress logic block to identify the destination of the packet.

7. The integrated circuit according to claim 1, wherein the NoC is configured to: route the packet to the egress logic block through a plurality of interconnect switches using the alias destination ID.

8. An integrated circuit, the integrated circuit comprises: a first circuit element, the first circuit element being assigned a first ID; a second circuit element, the second circuit element being assigned a second ID different from the first ID; and a NoC, the NoC comprising: An ingress logic block configured to receive packets from the first circuit element and the second circuit element to be sent via the NoC to the same egress logic block in the NoC; wherein the ingress logic block is configured to: allocate, via the NoC, a first alias destination ID corresponding to a first path for use by packets received from the first circuit element to reach the egress logic block, and allocate, via the NoC, a second alias destination ID corresponding to a second path for use by packets received from the second circuit element to reach the egress logic block.

9. The integrated circuit according to claim 8, wherein the packets from the first circuit element received at the ingress logic block are sent to the egress logic block only via the first path, and the packets from the second circuit element received at the ingress logic block are sent to the egress logic block only via the second path.

10. The integrated circuit according to claim 8, wherein the first ID and the second ID are different Advanced eXtensible Interface (AXI) IDs.

11. The integrated circuit according to claim 8, wherein the first path uses a different set of switches in the NoC to reach the egress logic block than the second path.

12. The integrated circuit according to claim 8, wherein the first circuit element and the second circuit element are peripheral devices.

13. The integrated circuit according to claim 8, the integrated circuit further comprising, before allocating the first alias destination ID and the second alias destination ID: looking up an address mapping in the ingress logic block to identify the destination of the packets received from the first circuit element and the second circuit element.

14. A method, the method comprising: receiving, at an ingress logic block of a NoC, a packet from a first circuit element to be sent to a second circuit element, the second circuit element being coupled to the NoC; determining a destination of the packet using multipath routing (MPR) in the NoC; and allocating an alias destination ID corresponding to the destination based on bandwidth utilization required for multiple paths for sending data from the ingress logic block in the NoC to an egress logic block, wherein each of the multiple paths between the ingress logic block and the egress logic block has a different alias destination ID.

15. The method according to claim 14, the method further comprising: receiving, at the ingress logic block, a second packet from the first circuit element to be sent to the second circuit element; and when determining that the address of the packet matches the address of an in-use packet previously sent to the destination, allocating to the second packet the same alias destination ID as the alias destination ID that has been allocated to the in-use packet, such that the second packet uses the same path as the in-use packet to reach the egress logic block via the NoC.

Images