Multipath Routing in Network-on-Chip

Abstract

Embodiments herein describe a network-on-chip (NoC) that implements multipath routing (MPR) between an ingress logic block and an egress logic block. Multiple paths between the ingress logic block and the egress logic block may be assigned different alias destination IDs corresponding to the same destination ID. The NoC can use the alias destination IDs to route packets along different paths through interconnected switches within the NoC.

Description

[Technical Field]

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

[0002] A programmable 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, known as an NoC, for routing data packets between circuit elements (e.g., programmable logic blocks, processors, memories, etc.) within the SoC.

[0003] The NoC may include an ingress logic block (e.g., a master) that executes read or write requests to an egress logic block (e.g., a servant). Most solutions use single-path routing (SPR), where one path is selected to route all packets forwarded between the ingress logic block and the selected egress logic block. That is, with SPR, the ingress logic block uses only one path through the NoC to route data to the egress logic block.

[0004] In contrast, multipath routing (MPR) establishes multiple routes between an ingress logic block and an egress logic block. However, current MPR techniques typically rely on buffer reordering at the egress logic block to account for data that is received out of order due to different latencies on the multiple paths. Furthermore, many solutions include routing information in the packets being transmitted, which increases packet overhead. Summary of the Invention [Means for solving the problem]

[0005] An 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 and second circuit elements, wherein 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 that a destination of the packet uses multipath routing (MPR) within the NoC, and assign an alias destination ID corresponding to the destination based on desired bandwidth utilization of multiple paths used to transmit the data from the ingress logic block to an egress logic block within the NoC, wherein each of 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 that the destination of the packet uses multipath routing (MPR) within the NoC, and assigning an alias destination ID corresponding to the destination based on desired bandwidth utilization of multiple paths used to send data from the ingress logic block to an egress logic block within 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 including a first circuit element assigned a first ID, a second circuit element assigned a second ID different from the first ID, and an NoC, the NoC including an ingress logic block configured to receive packets from the first circuit element and the second circuit element and transmit them through the NoC to a same egress logic block within the NoC, the ingress logic block configured to assign a first alias destination ID corresponding to a first path through the NoC that the packet received from the first circuit element uses to reach the egress logic block, and to assign a second alias destination ID corresponding to a second path through the NoC that the packet received from the second circuit element uses to reach the egress logic block.

[0008] BRIEF DESCRIPTION OF THE DRAWINGS In a manner in which the above-recited features may be understood in detail, a more particular description briefly summarized above may be made by reference to exemplary implementations, some of which are illustrated in the accompanying drawings. It should be noted, however, that the accompanying drawings illustrate only typical example implementations and therefore should not be considered limiting of the scope thereof. [Brief explanation of the drawings]

[0009] [Figure 1] 1 is a block diagram of an SoC including an NoC, according to an example. [Figure 2A] 1 illustrates an NoC that lacks sufficient link bandwidth to perform SPR, according to an example. [Figure 2B] 2B illustrates the use of MPR to solve the routing problem of FIG. 2A, according to an example. [Figure 3] 1 is a flowchart for performing MPR, according to an example. [Figure 4] 1 illustrates a packet processing circuit within an ingress logic block, according to an example. [Figure 5] 1 is a flowchart for performing MPR, according to an example. [Figure 6] 1 illustrates a packet processing circuit within an ingress logic block, according to an example. DETAILED DESCRIPTION OF THE INVENTION

[0010] For ease of understanding, wherever possible, identical reference numbers have been used to indicate identical elements common to the figures. It is contemplated that elements of one embodiment may be beneficially incorporated in other embodiments.

[0011] MODE FOR CARRYING OUT THE INVENTION Various features are described below with reference to the drawings. It should be noted that the drawings may or may not be drawn to scale, and that elements of similar structure or function are represented by similar reference numerals throughout the drawings. It should be noted that the drawings are intended only to facilitate the description of features. They are not intended as an exhaustive description of the following examples or as limitations on the scope of the claims. In addition, the illustrated examples need not have all the aspects or advantages shown. An aspect or advantage described in connection with a particular embodiment is not necessarily limited to that embodiment and may be implemented in any other embodiment, even if not so illustrated or explicitly described.

[0012] Embodiments herein describe a NoC that implements MPR between ingress and egress logical blocks. In one embodiment, during configuration, if a router determines that the NoC does not have a single path with sufficient available bandwidth to satisfy the amount of traffic that an ingress logical block needs to send to an egress logical block, the router uses MPR by identifying sufficient available bandwidth in multiple paths within the NoC.

[0013] In one embodiment, an ingress logic block may service multiple components (e.g., circuit elements) that are assigned different IDs (e.g., different Advanced Extensible Interface (AXI) IDs). If there are paths with sufficient available bandwidth for the traffic generated by each component, the router can assign each component's flow to a respective one of the paths using the alias destination ID. For example, traffic received at the ingress logic block for component 1 may be assigned alias ID 1 and routed to the egress logic block using path 1 within the NoC. Traffic received at the ingress logic block for component 2 may be assigned alias ID 2 and routed to the same egress logic block using path 2 within the NoC, and so on.

[0014] However, if the ingress logic block does not service multiple components or if the NoC does not have paths with sufficient available bandwidth for each flow generated by multiple components, a different MPR technique can be used. In this example, multiple paths can be selected, and their total available bandwidth satisfies the bandwidth requirement of 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 the different paths. For example, if path 1 provides two-thirds of the bandwidth and path 2 provides one-third of the bandwidth between the ingress logic block and the egress logic block, the ingress logic block can assign every two packets to the alias ID of path 1, assigning every one packet to the alias ID of path 2. Furthermore, because ordering can be an issue for packets with duplicate addresses, the ingress logic block can ensure that packets with duplicate addresses are sent on the same path and received in order at the egress logic block.

[0015] 1 is a block diagram of an SoC 100 including an 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 (e.g., an SoC) includes a mix of hardened and programmable logic. For example, the NoC 105 may be formed using hardened circuitry rather than programmable circuitry so that its footprint within the SoC 100 is reduced.

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

[0017] PL block 125A may include an exit logic block 140 for receiving data sent by PL block 125B and processor 110. In one embodiment, a hardware logic block (or hardware logic circuit) can communicate with all other hardware logic blocks that are also connected to NoC 105, while in other embodiments, a hardware logic block may communicate with only a sub-portion of other hardware logic blocks that are also connected to NoC 105. For example, memory 120 can communicate with PL block 125A but not with PL block 125B.

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

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

[0020] Additionally, FIG. 1 shows the connections and various switches 135 (labeled as boxes with an “X”) used by NoC 105 to route packets between ingress logic block 115 and egress logic block 140.

[0021] The locations of PL block 125, processor 110, and memory 120 in the physical layout of SoC 100 are merely one example of arranging these hardware elements. Furthermore, SoC 100 may include more hardware elements than are shown. For example, SoC 100 may include additional PL blocks, processors, and memories located at different locations on SoC 100. Furthermore, SoC 100 may include other hardware elements, such as I / O modules and memory controllers, which may or may not be coupled to NoC 105 using respective ingress logic blocks 115 and egress logic blocks 140. For example, I / O modules may be located on the periphery of SoC 100.

[0022] 2A illustrates a portion of NoC 105 that lacks sufficient link bandwidth to perform SPR, according to an example. FIG. 2A illustrates an attempt to configure NoC 105 so that ingress logic blocks 115A-115D can have respective connections to egress logic blocks 140A-140D. In this case, a router (e.g., a software application stored in memory and executed by one or more processors in a computing system) attempts to configure NoC 105 so that ingress logic block 115A connects to egress logic block 140A through NoC 105, ingress logic block 115B connects to egress logic block 140B through NoC 105, ingress logic block 115C connects to egress logic block 140C through NoC 105, and ingress logic block 115D connects to egress logic block 140D through NoC 105.

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

[0024] Additionally, the router may consider using other links L1 and L2 to route path 205 between egress logic block 115B and egress logic block 140B. However, these links also do not have sufficient available bandwidth. Therefore, when using SPR, Figure 2A illustrates a scenario in which not all connections can be routed.

[0025] FIG. 2B illustrates, according to an example, the use of MPR to solve the routing problem of FIG. 2A. That is, all connections in FIG. 2A can be routed if the NoC 105 supports MPR. In FIG. 2B, traffic for the connection between 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. Thus, FIG. 2B illustrates that MPR can be used if any single path or connection through the NoC 105 does not meet the bandwidth requirement between the ingress logic block 115 and the egress logic block 140B. Instead, multiple paths can be identified if their aggregate available bandwidth meets or exceeds the bandwidth requirement for the ingress and egress logic block pair.

[0026] The following description describes several techniques for implementing MPR in an NoC. 3 is a flowchart of a method 300 for performing MPR, according to an example. In block 305, the router determines whether one route within the NoC satisfies the bandwidth (BW) of the connection between the ingress logic block and the egress logic block. If so, the method 300 proceeds to block 310, where the router assigns a route for the ingress logic block to use to exchange packets with the egress logic block. That is, a single route within the NoC has enough available bandwidth to satisfy the bandwidth requirement between the ingress logic block and the egress logic block.

[0027] However, assuming the NoC does not have a single root with sufficient available bandwidth, method 300 proceeds to block 315, where the root determines whether the ingress logic block serves multiple components. In some hardware deployments, the ingress logic block may serve multiple components (e.g., masters), such as peripheral devices, that are assigned respective IDs (i.e., different AXI IDs). Figure 2B shows two components 220A and 220B connected to ingress logic block 115B. These components 220A and 220B may be assigned different AXI IDs.

[0028] In AXI, transactions corresponding to the same component 220 must arrive at the destination in the order in which they were issued, regardless of their addresses. That is, all packets generated by ingress logic block 115B at the direction of component 220A must arrive at egress logic block 140B in the same order in which they were sent by ingress logic block 115B. In contrast, transactions from components with different IDs to the same destination are independent, and responses can be issued in any order. For example, if ingress logic block 115B first sends a packet for component 220A and then later sends a packet for component 220B, the packet for component 220B can arrive at egress logic block 140B before the packet for component 220A without violating the AXI ordering constraints.

[0029] Returning to block 320, if the ingress logic block does not service multiple components with distinct IDs, the method 300 proceeds to block 320 and performs flow splitting as described in FIGS.

[0030] However, if the ingress logic block serves multiple components with distinct IDs, method 300 proceeds to block 325, where the router determines whether there is a path that meets the BW for each of the components. Using FIG. 2B as an example, assume that component 220A needs to use 50% of the bandwidth of one of links L0-L2. In that case, none of the links has enough available bandwidth for the traffic generated by component 220A. In other words, the NoC does not have a respective link with enough bandwidth to service the traffic generated by each of components 220A. In that case, method 300 proceeds to block 320, where flow splitting can be performed (as described below).

[0031] However, if components 220A and 220B need to use 34% or less of the link's bandwidth, then the link has sufficient available bandwidth. For example, L0 may be used to service traffic generated by component 220A, as shown by path 210, while L2 may be used to service traffic generated by component 220B, as shown by path 215. Thus, in this example, the router has identified paths that can be assigned to service traffic for each component 220.

[0032] Method 300 then proceeds to block 330, where the router generates an alias ID for each path identified in block 325. In one embodiment, alias IDs may be used to represent different paths to reach the same egress logic block. One alias ID may be used by traffic generated by component 220A of FIG. 2B, and another alias ID may be used by traffic generated by component 220B. Thus, traffic for component 220A reaches egress logic block 140B using path 210, and traffic for component 220B reaches egress logic block 140B using path 215. This ensures that traffic generated for one of components 220 arrives at egress logic block 140B in order. However, the combined traffic for components 220A and 220B may arrive out of order relative to their transmission order at ingress logic block 115B due to different latencies in paths 210 and 215, but this does not violate the communication protocol used by the NoC.

[0033] In block 335, the router configures a separate route for each alias ID. In one embodiment, the router configures routes in the NoC by updating routing tables in switches 135 of FIG. 2B. 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 of path 210, the routing table indicates that the next hop is to switch 135A, but if the packet has an alias ID of path 215, the routing table indicates that the next hop is to switch 135E. In this way, the router can generate routing tables in each of switches 135 to support MPR.

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

[0035] In one embodiment, method 300 may be performed for each ingress logic block in an NoC. Furthermore, if an ingress logic block has connections to multiple egress logic blocks, method 300 may be performed for each of these connections.

[0036] 4 illustrates a packet processing circuit 400 within an ingress logic block, according to one example. Packet processing circuit 400 may be used to perform the MPR technique described in method 300. As shown, circuit 400 includes a request FIFO 405 that stores requests received from upstream circuitry (e.g., component 220 of FIG. 2B). Address map 410 receives requests (or transactions) from FIFO 405 and includes address ranges and corresponding destination IDs for the egress logic block. In one embodiment, the ingress logic block identifies the destination ID by performing a lookup in address map 410 using an address in the request (e.g., packet).

[0037] The destination ID is then sent to an alias ID map 415, which stores a mapping of destination IDs to respective alias IDs generated in 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., the AXI ID) to identify the corresponding alias ID. That is, a hit in alias ID map 415 generates an alias ID for the request (or, more specifically, the packet corresponding to the request).

[0038] The alias ID and the request are then sent to a packetizer 420, which generates a packet for the request that includes the alias ID. The resulting packet may then be sent to a switch 135 in the NoC, which, as described above, has a routing table that includes the alias IDs to determine how to route packets corresponding to different alias IDs (and different components) on different routes or paths to reach the same egress logical block.

[0039] FIG. 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., block 315 of FIG. 3 ) or when the NoC does not have links with sufficient bandwidth to support traffic from each master component (e.g., block 325 of FIG. 3 ). However, in another embodiment, method 500 can be used in all cases. That is, the flow splitting described in method 500 may be a general use case that can be applied to any situation when a single route between an ingress logic block and an egress logic block with sufficient bandwidth cannot be identified.

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

[0041] At block 510, the ingress logic block uses the identified destination to determine whether the destination is part of an MPR. In one embodiment, the ingress logic block queries an alias map to determine whether a particular destination ID corresponds to multiple alias destination IDs. If not, SPR routing is used to route the data from the ingress logic block to the destination. If so, method 500 proceeds to block 515, where the ingress logic block routes the data through the NoC via the SPR using the destination ID.

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

[0043] In 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-service packets, indicating that there is a match. For example, if the current packet has an address range of 0 to 16 and an in-service packet to the same destination has an address range of 16 to 32, the addresses do not overlap (i.e., do not match). However, if the current packet has an address range of 0 to 16 and the in-service packet has an address range of 10 to 15, the address ranges overlap and there is a match.

[0044] In this embodiment, if the addresses at least partially overlap, this means that the packets should arrive at the egress logic block in the order in which they were sent by the ingress logic block. That is, because the packets are accessing overlapping memory, it is important that these packets are processed at the destination in the order in which they were sent by the ingress logic block. For example, assume that a first packet sent by the ingress logic block modifies data corresponding to that address range, and a second, subsequently sent packet reads that data. If the first packet is sent to the egress logic block using a higher latency path through the NoC 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 reads the “old” data because the “old” data was processed first by the destination.

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

[0046] If the ingress logic block determines that the current packet overlaps with an in-service packet, method 500 proceeds to block 525, where the ingress logic block assigns the alias destination ID of the matching in-service packet to the current packet. By assigning the same alias destination ID, this ensures that the current packet uses the same path that the in-service packet took through the NoC to reach the egress logic block, thereby ensuring that the packets are received in order at the egress logic block. This ensures that packets are processed in order by their destination, and therefore data dependencies between packets are handled correctly.

[0047] Conversely, if there is no match, method 500 proceeds to block 530, where the ingress logic block assigns alias destination IDs based on a bandwidth ratio. For example, assume that the ingress logic block has three different links to the egress logic block, and these paths have 33%, 33%, and 66% of the bandwidth allocated to service the data connection between the ingress and egress logic blocks. Assuming these three paths have the same total bandwidth, then for every packet that the ingress logic block assigns to the first and second paths, it assigns two packets to use the third path. Thus, the ingress logic block can assign packet alias IDs using any assignment technique (e.g., round robin) to achieve the desired bandwidth ratio. This can also take into account packets that are forced to use the same path due to having overlapping addresses. For example, if the ingress logic block sends two subsequent packets on the first path because they have overlapping addresses, it can send the next two packets on the second path and the next four packets on the third path (assuming they do not have overlapping addresses) to maintain the desired bandwidth utilization between the paths.

[0048] In block 535, the ingress logic block performs packetization and injects the packet into the switching network. That is, the ingress logic block adds a corresponding alias destination ID (or real destination ID in the case of MPR) to the packet and can send the packet to the switch connected to the ingress logic block. As described above, the routing table in the switch can be configured to recognize the real 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.

[0049] 6 illustrates a packet processing circuit 600 within an ingress logic block, according to one example. Packet processing circuit 600 may be used to perform the MPR technique described in method 500. As shown, circuit 600 includes a request FIFO 605 that stores requests received from upstream circuitry (e.g., component 220 of FIG. 2B). Address map 610 receives requests (or transactions) from FIFO 605 and includes address ranges and corresponding destination IDs for egress logic blocks. In one embodiment, the destination IDs are identified by performing a lookup in address map 610 using an address in the request (e.g., packet).

[0050] The destination ID is then sent to alias ID map 615, which stores a mapping of destination IDs to their respective alias IDs when MPR is enabled in the NoC. Alias ​​ID map 615 can use the destination ID to identify the corresponding alias ID. That is, a hit in alias ID map 615 yields an alias ID for the request (or more specifically, the packet corresponding to the request). Thus, in block 510 of FIG. 5, the ingress logic block can query alias ID map 615 to determine whether the destination ID is part of an MPR (i.e., the destination ID has multiple alias destination IDs).

[0051] Circuit 600 also includes a duplicate table 620 that tracks in-service packets previously sent by the ingress logic block. If the ingress logic block sends data to multiple destinations, duplicate table 620 can track in-service packets for each of those destinations. When a packet is no longer in service (e.g., when the egress logic block from that destination acknowledges the packet), the packet can be removed from duplicate table 620.

[0052] 5, the ingress logic block can use the duplicate table 620 to determine whether the current packet matches one of the in-service packets stored in the duplicate table 620 (e.g., the address range of the current packet overlaps with the address range of one of the in-service packets bound for the same destination). If so, this indicates that the current packet should be sent on the same path as the in-service packet (e.g., assigned the same alias ID) so that ordering is preserved. If not, the ingress logic block can assign an alias destination ID to meet the desired bandwidth utilization of the path used to reach the egress logic block.

[0053] The alias ID and the request are then sent to a packetizer 625, which generates a packet for the request that includes the alias ID. The resulting packet may then be sent to a switch 135 in the NoC, which, as described above, has a routing table that includes the alias destination IDs to determine how to route packets corresponding to different alias IDs on different routes or paths to reach the same egress logical block.

[0054] 4 and 6 for assigning alias IDs for routing data to egress logical blocks can be applied to egress logical blocks that assign source IDs for routing data to ingress logical blocks, i.e., the source IDs of the ingress logical blocks can also be aliased to route packets back to the source on each path.

[0055] In the foregoing, reference is made to the embodiments presented in this disclosure. However, the scope of the disclosure is not limited to the specific described embodiments. Instead, any combination of the described features and elements, whether associated with different embodiments or not, is contemplated for implementing and practicing the contemplated embodiments. Moreover, while the embodiments disclosed herein may achieve advantages over other possible solutions or prior art, whether or not a particular advantage is achieved by a given embodiment does not limit the scope of the disclosure. Accordingly, the foregoing aspects, features, embodiments, and advantages are merely illustrative and are not considered elements or limitations of the appended claims unless expressly recited in the claims.

[0056] As will be appreciated by one skilled in the art, 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 be generally referred to herein as a "circuit," "module," or "system." Furthermore, aspects may take the form of a computer program product embodied in one or more computer-readable medium(s) having computer-readable program code embodied therein.

[0057] Any combination of one or more computer-readable media may be utilized. The computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (non-exhaustive list) of computer-readable storage media include an electrical connection having one or more wires, a portable computer floppy disk, 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 disk 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 specification, 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.

[0058] A computer-readable signal medium may include a propagated data signal in which computer-readable program code is embodied, for example, 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 is not a computer-readable storage medium but may be any computer-readable medium that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

[0059] The program code embodied on the computer readable medium may be transmitted using any suitable medium, including but not limited to wireless, wireline, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

[0060] Computer program code for carrying out operations of aspects of the present disclosure may be written in any combination of one or more programming languages, including, for example, 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 may execute entirely on the user's computer, partially on the user's computer as a standalone software package, partially on the user's computer, partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet Service Provider).

[0061] 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 will 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, 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 the flowchart and / or block diagram blocks.

[0062] These computer program instructions may also be stored on a computer-readable storage medium, and the instructions may direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner to produce an article of manufacture including instructions that implement the functions / acts specified in the flowchart and / or block diagram blocks.

[0063] Computer program instructions may also be loaded into 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 create a computer-implemented process, such that the instructions executing on the computer or other programmable apparatus provide a process for implementing the functions / acts specified in the flowchart and / or block diagram blocks.

[0064] 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 embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a 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, two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may be executed in the reverse order, depending on the functionality involved. It should 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, may be implemented by a dedicated hardware-based system that performs the specified functions or acts or a combination of dedicated hardware and computer instructions.

[0065] While the above is directed to particular examples, other and further examples may be devised without departing from the basic scope thereof, which scope is determined by the following claims.

Claims

1. 1. An integrated circuit comprising: 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 comprising: receiving, at an ingress logic block, a packet from the first circuit element to be transmitted to the second circuit element; determining that the packet's destination uses multipath routing (MPR) within the NoC; and assigning an alias destination ID corresponding to the destination based on desired bandwidth utilization of a plurality of paths used to transmit data from the ingress logical block to an egress logical block within the NoC, wherein each of the plurality of paths between the ingress logical block and the egress logical block has a different alias destination ID.

2. The NoC, receiving, at the ingress logic block, a second packet from the first circuit element to be transmitted to the second circuit element; 2. The integrated circuit of claim 1, wherein the integrated circuit is configured to: upon determining that the address of the packet matches an address of an in-service packet previously sent to the destination, assign the same alias destination ID assigned to the in-service packet to the second packet, thereby causing the second packet to reach the egress logic block using the same path through the NoC as the in-service packet.

3. 3. The integrated circuit of claim 2, wherein the ingress logic block comprises a duplicate table configured to store address ranges of in-service packets being transmitted from the ingress logic block to the egress logic block.

4. 3. The integrated circuit of claim 2, wherein assigning the same alias destination ID to the second packet as the in-service packet ensures that the second packet and the in-service packet arrive at the egress logic block in the same relative order as they were transmitted from the ingress logic block.

5. 2. The integrated circuit of claim 1, wherein the desired bandwidth utilization is based on a percentage of bandwidth on each of the plurality of paths that the ingress logic block is permitted to use to send packets to the egress logic block, and the percentage of bandwidth that the ingress logic block is permitted to use on each of the plurality of paths is less than 100 percent.

6. Before the NoC determines that the destination of the packet uses MPR, 2. The integrated circuit of claim 1, configured to perform a lookup in an address map within the ingress logic block to identify the destination of the packet.

7. The NoC, 2. The integrated circuit of claim 1, configured to use the alias destination ID to route the packet through a plurality of interconnected switches to reach the egress logic block.

8. 1. An integrated circuit comprising: a first circuit element assigned a first ID; a second circuit element assigned a second ID different from the first ID; and a Network on Chip (NoC), wherein the NoC comprises: an ingress logic block configured to receive packets from the first circuit element and the second circuit element and transmit the packets through the Network on Chip to a same egress logic block within the Network on Chip; The entry logic block: assigning a first alias destination ID corresponding to a first path through the NoC that a packet received from the first circuit element uses to reach the egress logic block; assigning a second alias destination ID corresponding to a second path through the NoC that a packet received from the second circuit element uses to reach the egress logic block.

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

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

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

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

13. prior to assigning the first alias destination ID and the second alias destination ID; 9. The integrated circuit of claim 8, further comprising: performing a lookup in an address map in the ingress logic block to identify destinations of the packets received from the first circuit element and the second circuit element.

14. 1. A method comprising: receiving, at an ingress logic block of a Network on Chip (NoC), a packet from a first circuit element to be transmitted to a second circuit element coupled to the Network on Chip (NoC); determining that the packet's destination uses multipath routing (MPR) within the NoC; and assigning an alias destination ID corresponding to the destination based on desired bandwidth utilization of a plurality of paths used to transmit data from the ingress logical block to an egress logical block within the Network on Chip (NoC), wherein each of the plurality of paths between the ingress logical block and the egress logical block has a different alias destination ID.

15. receiving, at the ingress logic block, a second packet from the first circuit element to be transmitted to the second circuit element; 15. The method of claim 14, further comprising: upon determining that the address of the packet matches the address of an in-service packet previously sent to the destination, assigning the second packet the same alias destination ID assigned to the in-service packet, thereby causing the second packet to reach the egress logic block using the same path through the NoC as the in-service packet.

Images