Network-on-chip architecture with destination virtualization

Abstract

Embodiments herein describe using a virtual destination to route packets through a NoC (105). In one embodiment, instead of decoding an address as a target destination ID for the NoC (105), an ingress logic block (115) assigns the same virtual destination ID to packets for multiple different targets. For example, the targets may be located in the same segment or location of the NoC (105). Thus, the ingress logic block (115) does not have to store an entry for each target in a lookup table, but it may have a single entry for the virtual destination ID. The virtual destination ID is then used to route the packets for the targets to a decoder switch (140) in the NoC (105). The decoder switch (140) may then select an appropriate target destination ID using the address in the packet, which is different from the destination ID.

Description

Technical Field

[0001] The examples disclosed herein generally involve using virtual destination identifiers (IDs) to route packets at least partially through a network on-chip (NoC). Background Technology

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

[0003] A NoC (No. 1 Controller) can include an ingress block (e.g., a master block) that performs read or write requests to an egress block (e.g., a slave block). An initiator (e.g., a circuit that relies on the ingress block to use the NoC for communication) can use the NoC to send data to many different destinations. This means that the switches in the NoC must store routing information to route data from the ingress block to all the different destinations, increasing the overhead of the NoC. For example, each destination has a destination ID, where each switch looks up the destination ID and routes the transaction to the next switch. For this purpose, the switch consists of lookup tables. The size of the lookup table is limited due to both area and timing considerations. For example, in one implementation, the switch can route up to 82 destinations. However, increasingly, the number of destinations exceeds the number accessible to the initiator. For example, a system with four High Bandwidth Memory (HBM)-3 stacks exposes 128 destinations, and each initiator is required to access all 128 destinations.

[0004] To increase the number of targets accessible to the initiator, one solution is to increase the number of entries in the lookup table. This directly impacts the size of the NoC switch and its timing. Furthermore, it limits the design's scalability. As more devices are integrated using an upward scaling approach, the NoC needs to be redesigned to handle the increased number of targets. Summary of the Invention

[0005] One embodiment described herein is an IC comprising: an initiator including circuitry, and a NoC configured to receive data from the initiator to be sent to a destination. The NoC includes: an ingress logic block configured to assign a first virtual destination ID to the data, wherein the first virtual destination ID corresponds to a first decoder switch in the NoC; and a first NoC switch configured to route the data to the first decoder switch using the first virtual destination ID. Furthermore, the first decoder switch is configured to decode addresses in the data to assign a destination ID corresponding to the destination.

[0006] One implementation described herein is a method comprising: receiving data from an initiator at a NoC; decoding an address associated with the data to generate a first virtual destination ID corresponding to a first decoder switch in the NoC; using the first virtual destination ID to route the data through a portion of the NoC to the first decoder switch; determining a destination ID at the first decoder switch corresponding to the destination of the data; and using the destination ID to route the data through the remainder of the NoC. Attached Figure Description

[0007] To gain a more detailed understanding of the features described above, a more specific description of the brief summary can be obtained by referring to the exemplary embodiments, some of which are illustrated in the accompanying drawings. However, it should be noted that the drawings illustrate only typical exemplary embodiments and should not be considered as limiting the scope of the description.

[0008] Figure 1 This is a block diagram of an example SoC that includes NoC.

[0009] Figure 2 This is a block diagram of a NoC with a shared decoder, based on an example.

[0010] Figure 3 This is a block diagram of a NoC with a decoder switch, based on an example.

[0011] Figure 4 This is a block diagram of a NoC with multiple decoder switches, based on an example.

[0012] Figure 5 This is a block diagram of a NoC with multiple decoder switches, based on an example.

[0013] Figure 6 It is a block diagram based on an example NoC, which illustrates different segments.

[0014] Figure 7It is a block diagram based on an example NoC, which illustrates different segments.

[0015] Figure 8 This is a flowchart based on an example of routing packets in a NoC using virtual destination IDs.

[0016] Figure 9 This example illustrates how to map system addresses to physical addresses in a decoder switch.

[0017] For ease of understanding, the same reference numerals are used where possible to denote common elements in the accompanying figures. Consider that elements of one example can be advantageously incorporated into other examples. Detailed Implementation

[0018] Various features are described below with reference to the accompanying drawings. It should be noted that the drawings may be drawn to scale or not, and elements with similar structures or functions are indicated by similar reference numerals in all the drawings. It should be noted that the drawings are intended only to facilitate the description of features. They are not intended to provide an exhaustive description of the embodiments herein, nor are they intended to limit the scope of the claims. Furthermore, the illustrated examples need not possess all the 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 so explicitly described.

[0019] The implementation described herein describes the use of virtual destinations to route packets through a NoC. In one implementation, instead of decoding the address to the target destination ID of the NoC, the ingress logic block assigns the same virtual destination ID to packets targeting multiple different destinations. For example, these destinations may be located in the same segment or location within the NoC. Therefore, the ingress logic block does not need to store an entry for each destination in a lookup table; instead, it can have a single entry for that virtual destination ID.

[0020] The virtual destination ID is then used to route these packets to the decoder switches in the NoC. The decoder switch can use the address in the packet (which is different from the destination ID) to select the appropriate destination ID. Advantageously, the decoder switch can store only the information used to decode the addresses of the destinations in the segment of the NoC, thereby saving memory. The destination ID is then used to route the packets to the destinations along the remaining path. In this way, the switch does not have to store routing information for each destination of the initiator, but only the virtual destination IDs of the segments that include those destinations. For example, if the initiator sends packets to 20 destinations in five different segments, the switch coupled to the initiator only needs to store the virtual destination IDs of the five decoder switches that grant access to the five segments of the NoC, instead of storing the destination ID of each of the 20 destinations.

[0021] Figure 1 This is a block diagram of an example SoC 100 including a NoC 105. In one embodiment, the SoC 100 is implemented using a single IC. In one embodiment, the SoC 100 includes a mixture of hardened and programmable logic. For example, hardened circuitry can be used instead of programmable circuitry to form the NoC 105, thereby reducing its footprint in the SoC 100.

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

[0023] PL block 125A may include an output logic block 140 for receiving data sent by PL block 125B and processor 110. In one embodiment, the hardware logic block (or hardware logic circuitry) is capable of communicating with all other hardware logic blocks also connected to NoC 105; however, in other embodiments, the hardware logic block may communicate only with sub-sections of other hardware logic blocks connected to NoC 105. For example, memory 120 may be able to communicate with PL block 125A but not with PL block 125B.

[0024] As described above, the entry logic block 115 and the exit logic block 140 can all communicate with the PL block 125, the processor 110, and the memory 120 using the same communication protocol, or they can use different communication protocols. For example, the PL block 125A can communicate with the PL block 125B using a memory mapping protocol, while the processor 110 can communicate with the memory 120 using a streaming protocol. In one embodiment, NoC 105 can support multiple protocols.

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

[0026] also, Figure 1 Examples of connections and various switches 135 (marked as boxes with “X”) used by NoC 105 to route packets between ingress logic block 115 and egress logic block 140 are shown.

[0027] The positions of PL block 125, processor 110, and memory 120 in the physical layout of SoC 100 are merely one example of how these hardware components can be arranged. Furthermore, SoC 100 may include more hardware components than shown. For example, SoC 100 may include additional PL blocks, processors, and memories located at different locations on SoC 100. Additionally, SoC 100 may include other hardware components such as I / O modules and memory controllers, which may or may not be coupled to NoC 105 using corresponding entry logic block 115 and exit logic block 140. For example, I / O modules may be positioned around the perimeter of SoC 100.

[0028] Figure 2 This is a block diagram of a NoC 200 with a shared decoder, based on an example. Figure 2 Another solution (instead of simply increasing the size of the routing table in the switch) is illustrated to increase the number of targets accessible to initiator 205. In this method, NoC 200 includes a shared decoder 210 to which all transactions are routed. That is, when initiator 205 (e.g., circuitry coupled to NoC 200, such as...) Figure 1 When the initiator 205 (processor 110, PL block 125, or memory 120) wants to send a packet to one of the destinations 215, it first sends the packet to the shared decoder 210. For example, when the initiator 205 wants to send a packet to any one of the destinations 215 (each of which has its own destination ID), the initiator 205 first assigns a destination ID (i.e., destination ID 0) to the shared decoder 210. Therefore, the switch 135 between the initiator 205 and the shared decoder 210 only needs to have routing information for sending packets to the shared decoder 210 instead of to the destination 215, thereby saving memory on those switches 135.

[0029] Once the shared decoder 210 receives a packet, it can use the address in the packet to identify the correct destination 215 and then reinsert the packet into NoC200 with a destination ID corresponding to the destination (e.g., destination IDs 1 through 4). In this example, any request for destination ID 1, 2, 3, or 4 is first routed to the shared decoder 210 (destination-ID 0). The shared decoder 210 performs its own decoding and reroutes the transaction to the correct destination.

[0030] However, this virtualization approach has several problems. First, it introduces additional latency during the time it takes for packets to be removed from NoC 200, decoded by shared decoder 210, and then reinserted into NoC 200. Second, shared decoder 210 may occupy a significant area on the SoC. Third, it may create a bottleneck at shared decoder 210. Although Figure 2 Only one initiator 205 is shown that relies on the shared decoder 210 to perform virtualization, but NoC 200 may include many initiators that rely on the same shared decoder 210, which may overwhelm the decoder 210 (or cause more shared decoders 210 to have to be added, which further increases the required area).

[0031] Therefore, the following implementation discusses other techniques for virtualizing destination IDs without using a shared decoder. These techniques can increase the number of targets accessible to the initiator, while relative to... Figure 2The implementation scheme shown improves latency and bottlenecks.

[0032] Figure 3 This is a block diagram of a NoC 300 with a decoder switch 305 as an example. The NoC 300 has a combination of a NoC switch 135 and an address decoding enabled switch (referred to as the decoder switch 305). The decoder switch 305 has an address decoder in the switch, which allows the NoC 300 to reduce the number of destinations by allowing the decoder switch 305 to perform second-level decoding (e.g., translating a virtual destination ID into a target destination ID).

[0033] exist Figure 3 In the context of a process where initiator 205 wants to send a service to one of the targets, the entry logic block (e.g., ...) Figure 1 The ingress logic block 115 first assigns a virtual destination ID corresponding to the decoder switch 305. In one implementation, the ingress logic block can map one or more address ranges corresponding to the four destinations 215 in NoC 300 to the same virtual destination ID (i.e., destination ID 0). In other words, whenever the initiator 205 provides data to be transmitted to any of the four destinations 215, the data is converted into a NoC packet with the destination ID of the decoder switch 305.

[0034] Furthermore, in one implementation, traffic from initiator 205 to decoder switch 305 can travel along the same path. For example, regardless of which of the four destinations 215 is the final destination of the traffic, the traffic can be routed on the same switches (i.e., switch 135A, then switch 135B, then switch 135C, then switch 135D) and then reach decoder switch 305. Advantageously, switches 135A to 135D do not need to store routing information for individual destinations 215, but only for the decoder switch 305. That is, switches 135A to 135D can store routing information for destination ID 0 (e.g., next hop), but not for destination IDs 1 to 4, because they may never receive packets with those destination IDs. Furthermore, since traffic from initiator 205 to decoder switch 305 can use the same switches 135A to 135D, other switches (e.g., switches 135E to 135H) do not need to store routing information for decoder switch 305 or destination 215. Switches 135E to 135H can be used by initiator 205 to reach other destinations (not shown) in NoC 300, or can be used by other initiators. In this way, instead of storing routing information for four destinations, switches 135A to 135D can simply store routing information for decoder switch 305.

[0035] Once decoder switch 305 receives a packet, it can ignore the current destination ID (e.g., destination ID 0) and use the address in the packet (which is different from the destination ID) to perform the decoding operation. In this case, instead of mapping the address of destination 215 to the same destination ID, the decoder switch can map a separate address corresponding to destination 215 to a unique destination ID (i.e., IDs 1 through 4). Therefore, when decoder switch 305 forwards a packet, the packet has the destination ID.

[0036] In one implementation, the switch 135 between the decoder switch 305 and the target 215 has routing information for the target 215. Furthermore, the decoder switch 305 can perform load balancing by distributing traffic to the switches, which also reduces the amount of routing information stored by each switch 135. For example, the decoder switch 305 can use its top-right port to send traffic to the target 215 with destination ID 1, and then the traffic reaches the target via the upstream switch 135. In contrast, the decoder switch 305 can use its second-topmost port to send traffic to the target 215 with destination ID 2, and then the traffic reaches the target via the second-upstream switch 135. Similarly, traffic to the target 215 with destination ID 3 will use the third row from the top to reach the target, and traffic to the target 215 with destination ID 4 will use the bottom row to reach the target.

[0037] Therefore, each row in the switch can store only the routing information for its corresponding target. That is, since the decoder switch 305 can only transmit packets for the topmost target 215 to the uplink of the switch 135, these switches 135 do not need to store routing information for the other three targets 215. Therefore, the amount of routing information stored in the switches between the decoder switch 305 and the targets can be further reduced.

[0038] Figure 4 This is a block diagram of a NoC 400 with multiple decoder switches, based on an example. Specifically, the NoC 400 includes a first decoder switch 305A and a second decoder switch 305B. The NoC 400 also includes three initiators 205A to 205C and six destinations 215A to 215F.

[0039] In this example, initiator 205 can send packets to any of the six destinations 215, and therefore, switch 135 is configured with routing information to make this possible. However, access to destination 215 is controlled by two decoder switches, where decoder switch 305A controls access to destinations 215A through 215C, and decoder switch 305B controls access to destinations 215D through 215F. Therefore, as discussed above, the switch does not need to store routing information for destination 215, but can only store routing information for reaching decoder switch 305.

[0040] NoC 400 can be configured to predefine routes from each initiator in initiator 205 to each decoder switch in decoder switch 305 by configuring a routing table (lookup table) in switch 135. For example, when initiator 205A wants to send data to any of the three destinations 215A to 215C, the data travels along the same path through switch 135 and is received in the upper left port of decoder switch 305A. In other words, in one implementation, data sent between initiator 205A and decoder switch 305A uses the same path, regardless of the final destinations 215A to 215C. The same applies to the paths between initiators 205B and 205C and decoder switch 305A. That is, data sent between initiator 205B and decoder switch 305A can always use the same path. In this example, as indicated by the hash, decoder switch 305A can receive data from initiator 205B on its middle port, while decoder switch 305A can receive data from initiator 205C on its bottom port. Decoder switch 305A can then use the address in the received NoC packet to determine the target destination ID (e.g., ID 2 to 4).

[0041] When initiator 205A wants to send data to any of the three targets 215D to 215F, the data travels along the same path through switch 135 and is received in the left port of decoder switch 305B. In other words, in one implementation, data sent between initiator 205A and decoder switch 305B follows the same path, regardless of the final target 215D to 215F. The same applies to the paths between initiators 205B and 205C and decoder switch 305B, except that decoder switch 305B receives data from initiator 205B at its middle port and from initiator 205C at its right port. Decoder switch 305B can then use the address in the received NoC packet to determine the target destination ID (e.g., IDs 5 to 7).

[0042] In the NoC 400, switch 135 may have a routing table to route only to the two destinations indicated by the hash, thereby saving memory compared to the NoC configuration in which switch 135 has a routing table to route from all three initiators 205 to all six destinations 215.

[0043] NoC 400 illustrates that each initiator 205 can use its own dedicated port to send traffic to the decoder switch 305. However, if there are more initiators wanting to access the destination than the number of ports on the decoder switch 305, the initiators can share ports. For example, if there are six initiators, each port on the decoder switch 305 can be dedicated to two of the ports. Furthermore, Figure 4 Example: Target 215 can be partitioned so that access is controlled by different decoder switches 305.

[0044] Figure 5 This is a block diagram of a NoC 500 with multiple decoder switches 305, based on an example. Figure 5 This is a simplified use case with a single initiator 205, where there are two decoder switches 305 at the boundary of NoC 500. Here, initiator 205 is connected to switch A. In one implementation, switch A routes vertically only to decoder switch 305B at the bottom. Decoder switch 305B routes to one of four destinations 415E to 415H. Furthermore, switch A can route horizontally to decoder switch 305A on the right. Decoder switch 305A routes to one of four destinations 415A to 415D.

[0045] Advantageously, switch A only needs to be programmed for the two destinations indicated by the hash, because initiator 205 uses the same two ports to communicate with decoder switches 305A and 305B.

[0046] Figure 6 This is based on a block diagram of an example NoC 600, which illustrates different segments 605. In this case, each segment 605 contains a unique set of targets, which can be accessed using the corresponding decoder switch 305. That is, decoder switch 305A controls access to targets in segment 605A, decoder switch 305B controls access to targets in segment 605B, and so on for segments 605C and 605D.

[0047] In this scenario, switch A only needs to route to the four endpoints shown in the diagram (one port for each decoder switch 305). Then, the decoder switches 305 locally route to their respective destinations in segment 605.

[0048] Figure 7This is based on a block diagram of an example NoC 700, illustrating different segments 705. In this example, as shown, a decoder switch 305A is placed between two segments (e.g., segments 705A and 705B). For segments 705C through 705E, switch A can use only one destination ID per segment. Furthermore, to route to segment 705A or 705B, switch A can horizontally route to decoder switch 305A, which then routes to segment 705A or 705B. Therefore, a total of four destination IDs are used in switch A to cover 16 destinations.

[0049] Furthermore, the switches in the bottom two rows of decoder switch 305 can be used to route to targets in segment 705B, while the switches in the top two rows are used to route to targets in segment 705A. However, in another embodiment, targets in segments 705A and 705B can be considered part of the same segment, since access to targets in those segments is controlled by decoder switch 305A.

[0050] also, Figure 7 An example is illustrated where some decoder switches are directly connected to the target (or egress logic block), while other decoder switches can be coupled to additional NoC switches. For example, decoder switches 305B to 305D are coupled to a NoC switch on one side and to the target (or egress logic block) on the other side, while decoder switch 305A is coupled to a NoC switch on both sides. However, in other embodiments, decoder switch 305 can always be directly connected to the target or ingress logic block, or can always be coupled to a NoC switch on both sides.

[0051] Figure 8 This is a flowchart of method 800 for routing packets in a NoC using a virtual destination ID, based on an example. At block 805, the ingress logic block receives data from the initiator. In one implementation, the initiator may be a circuit located outside the NoC.

[0052] At box 810, the ingress logic block decodes the address to generate a virtual destination ID corresponding to the decoder switch. For example, the ingress logic block can map multiple addresses (which may be consecutive or non-consecutive) corresponding to different targets (or destinations) to the same virtual destination ID.

[0053] At box 815, the NoC uses a virtual destination ID to route packets through one or more NoC switches until they reach the decoder switch. In one implementation, packets generated by the initiator destined for the decoder switch arrive at the decoder switch via the same path through the NoC (e.g., through the same switch). In one implementation, the NoC switch positioned between the initiator and the decoder switch does not have an address decoder.

[0054] At box 820, the decoder switch determines the target destination ID corresponding to the target. In one implementation, the decoder switch uses the address in the NoC packet to perform the address decoding operation.

[0055] At box 825, the decoder switch uses the destination ID of the target to route NoC packets through the remainder of the NoC to the target. In one embodiment, the decoder switch has multiple ports, each connected to a target. The decoder switch can use the destination ID to select which port to use to forward packets so that the packets reach the desired target. In another embodiment, the decoder switch has output ports coupled to additional NoC switches (which may not have decoders). These NoC switches may have routing tables configured to use the destination ID to identify and route packets, compared to the NoC switch at box 815, which can be configured to recognize only the virtual destination ID corresponding to the decoder switch.

[0056] Hierarchical addressing In one implementation, hierarchical address decoding is used to enable the NoC to cover many destinations in a scalable manner. While not required, a crossbar switch can be used in conjunction with the address decoder. The crossbar switch reduces the number of destinations the initiator must route to. See again. Figure 4 Without crossbars, each initiator 205 would have to decode all destinations 215. With the introduction of crossbars, initiator 205 will only decode to a virtual destination ID that identifies the crossbar (e.g., the crossbar in decoder switches 305A or 305B). The router routes the transaction to one of the four input ports of the crossbar. The crossbar performs address decoding to determine the destination. In large systems, this mechanism significantly reduces the size of the routing table in the switch. For example, a dual-stacked high-bandwidth memory (HBM4) system with 128 pseudo-channels can be routed using 4-bit route lookup and 16 4×4 crossbars.

[0057] Layered address decoding enables the architecture to provide an abstraction between software-visible addressing and the corresponding physical address. By allocating addressing between the NMU and the decoding switch, the desired address virtualization can be achieved at a lower cost compared to setting up virtualization only at the NMU. This is in Figure 9 As shown, a contiguous address space 905 addressed to a decoder switch 910 can be split into different physical addresses and mapped to separate pseudo-channels. Alternatively, from a software perspective, different address regions 915 can be mapped to contiguous spaces within the physical space of the decoder switch 920.

[0058] Reference has been made to the embodiments presented in this disclosure. However, the scope of this disclosure is not limited to the specifically described embodiments. Rather, any combination of the described features and elements (whether or not it relates to different embodiments) is contemplated as an implementation and practice of the contemplated embodiments. Furthermore, while the embodiments disclosed herein may achieve advantages over other possible solutions or over the prior art, whether a particular advantage is achieved through a given embodiment does not limit the scope of this disclosure. Therefore, the foregoing aspects, features, embodiments, and advantages are illustrative only and should not be considered as elements or limitations of the appended claims unless expressly stated in the claims.

[0059] As those skilled in the art will understand, the embodiments disclosed herein may be embodied as systems, methods, or computer program products. Therefore, aspects may take the form of entirely hardware implementations, entirely software implementations (including firmware, resident software, microcode, etc.), or implementations combining software and hardware aspects, all of which may generally be referred to herein as “circuit,” “module,” or “system.” Furthermore, aspects may take the form of computer program products embodied in one or more computer-readable media having computer-readable program code embodied thereon.

[0060] Any combination of one or more computer-readable media may be used. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be (e.g., 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 (not an exhaustive list) of computer-readable storage media will include: electrical connections having one or more wires, portable computer floppy disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, 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 programs for use by or in connection with an instruction execution system, apparatus, or device.

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

[0062] Program code embodied on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, fiber optic cable, RF, or any suitable combination of the foregoing.

[0063] Computer program code used to perform operations relating to the aspects of this disclosure may 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 may be executed entirely on the user's computer, partially on the user's computer, as a standalone 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 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 through an Internet service provider).

[0064] Various aspects of this 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 this 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, special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, executable via the processor of the computer or other programmable data processing apparatus, create components for implementing the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams.

[0065] These computer program instructions may also be stored in a computer-readable medium that can instruct 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 writing including instructions that implement the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0066] Computer program instructions may also be loaded onto a computer, other programmable data processing apparatus or other equipment to cause a series of operational steps to be performed on the computer, other programmable apparatus or other equipment to produce a computer-implemented method, such that the instructions, which execute on the computer or other programmable apparatus, provide a process for implementing the function / action specified in one or more boxes of a flowchart and / or block diagram.

[0067] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible specific implementations of systems, methods, and computer program products according to various examples of the invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions comprising one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions indicated in the blocks may not occur in the order shown in the figures. For example, depending on the functionality involved, two blocks shown consecutively may actually be executed substantially simultaneously, or these blocks may sometimes be executed in reverse order. It will also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system that performs the specified function or action or executes a combination of dedicated hardware and computer instructions.

[0068] The techniques described above can be expressed in the following non-limiting embodiments.

[0069] Example 1. An integrated circuit (IC) comprising: an initiator including circuitry; and a network on-chip (NoC) configured to receive data to be sent to a target from the initiator, the NoC including: an ingress logic block configured to assign a first virtual destination ID to the data, wherein the first virtual destination ID corresponds to a first decoder switch in the NoC; and a first NoC switch configured to route the data to the first decoder switch using the first virtual destination ID, wherein the first decoder switch is configured to decode an address in the data to assign a target destination ID corresponding to the target.

[0070] Example 2. According to the IC of Example 1, wherein a plurality of targets are connected to the first decoder switch, wherein the ingress logic block is configured to assign the same first virtual destination ID to any traffic going to each of the plurality of targets.

[0071] Example 3. According to the IC described in Example 2, wherein the NoC sends data to the plurality of targets only through the first decoder switch, wherein each of the plurality of targets corresponds to a different target destination ID.

[0072] Example 4. According to the IC of Example 2, wherein the first decoder switch is configured to use different ports to route data to each of the plurality of targets.

[0073] Example 5. According to the IC of Example 2, data flows along the same path in the NoC between the initiator and the first decoder switch, regardless of which of the plurality of targets is the final destination of the data.

[0074] Example 6. According to the IC of Example 1, wherein the NoC includes: a second NoC switch disposed between the first decoder switch and the target, wherein the second NoC switch is configured to route the data using the target destination ID.

[0075] Example 7. According to the IC described in Example 6, wherein the second NoC switch does not store routing information corresponding to the first virtual destination ID, and wherein the first NoC switch does not store routing information corresponding to the target destination ID.

[0076] Example 8. According to the IC of Example 1, the NoC further includes: a second decoder switch corresponding to a second virtual destination ID, wherein, compared to the first decoder switch, the second decoder switch controls access to different sets of unique targets, wherein the first NoC switch includes routing information for both the first virtual destination ID and the second virtual destination ID.

[0077] Example 9. The IC according to Example 8, wherein the IC further includes: a second initiator configured to use a third NoC switch to route data to the first decoder switch using the first virtual destination ID and to route data to the second decoder switch using the second virtual destination ID.

[0078] Example 10. According to the IC of Example 9, wherein the first decoder switch uses a first dedicated port to receive data from the initiator and a second dedicated port to receive data from the second initiator, and the second decoder switch uses a third dedicated port to receive data from the initiator and a fourth dedicated port to receive data from the second initiator.

[0079] Example 11. A method comprising: receiving data from an initiator at a NoC; decoding an address associated with the data to generate a first virtual destination ID corresponding to a first decoder switch in the NoC; using the first virtual destination ID to route the data through a portion of the NoC to the first decoder switch; determining a destination ID at the first decoder switch corresponding to a destination of the data; and using the destination ID to route the data through the remainder of the NoC.

[0080] Example 12. The method according to Example 11, wherein a plurality of targets are connected to the first decoder switch, the method further comprising: assigning the same first virtual destination ID to any service destined for each of the plurality of targets.

[0081] Example 13. The method according to Example 12, wherein the NoC sends data to the plurality of targets only through the first decoder switch, wherein each of the plurality of targets corresponds to a different target destination ID.

[0082] Example 14. The method according to Example 12, the method further comprising: using different ports on the first decoder switch to send data from the first decoder switch to each of the plurality of targets.

[0083] Example 15. The method according to Example 12, the method further comprising: sending data received from the initiator to each of the plurality of targets via the first decoder switch, wherein the data flows between the initiator and the first decoder switch along the same path in the NoC, regardless of which of the plurality of targets is the final destination of the data.

[0084] Example 16. The method according to Example 11, wherein using the target destination ID to route the data through the remainder of the NoC includes: using a NoC switch disposed between the first decoder switch and the target, wherein the NoC switch is configured to route the data using the target destination ID.

[0085] Example 17. The method described in Example 16, wherein the NoC switch does not store routing information corresponding to the first virtual destination ID.

[0086] Example 18. The method according to Example 11, the method further comprising: receiving second data from the initiator at the NoC, the second data corresponding to a second target; decoding an address associated with the second data to generate a second virtual destination ID corresponding to a second decoder switch in the NoC; using the second virtual destination ID to route the second data through a portion of the NoC to the second decoder switch; determining a second target destination ID corresponding to the second target at the second decoder switch; and using the second target destination ID to route the second data through the remainder of the NoC, wherein the second decoder switch controls access to a different set of unique targets compared to the first decoder switch, wherein a first NoC switch located between the initiator and the first decoder switch and the second decoder switch includes routing information for both the first virtual destination ID and the second virtual destination ID.

[0087] Example 19. The method according to Example 18, the method further comprising: receiving third data from a second initiator at the NoC; decoding an address associated with the third data to generate a first virtual destination ID or a second virtual destination ID; and routing the third data to a first decoder switch or a second decoder switch using a second NoC switch including routing information for both the first virtual destination ID and the second virtual destination ID, wherein the first decoder switch uses a first dedicated port to receive data from the initiator and a second dedicated port to receive data from the second initiator, and the second decoder switch uses a third dedicated port to receive data from the initiator and a fourth dedicated port to receive data from the second initiator.

[0088] Example 20. According to the method of Example 11, the method further includes: performing hierarchical address decoding in the NoC, wherein a contiguous address space addressed to a decoder switch is split into different physical addresses and mapped to separate pseudo-channels.

[0089] While the foregoing describes specific embodiments, other and additional examples may be devised without departing from the basic scope of the invention, the scope of which is defined by the appended claims.

Claims

1. An integrated circuit (IC), the integrated circuit (IC) comprising: an initiator, the initiator comprising circuitry; and a network-on-chip (NoC) configured to receive data from the initiator to be sent to a target, the NoC comprising: an ingress logic block configured to assign a first virtual destination ID to the data, wherein the first virtual destination ID corresponds to a first decoder switch in the NoC, and a first NoC switch configured to use the first virtual destination ID to route the data to the first decoder switch, wherein the first decoder switch is configured to decode an address in the data to assign a target destination ID corresponding to the target.

2. The IC of claim 1, wherein a plurality of targets are connected to the first decoder switch, wherein the ingress logic block is configured to assign the same first virtual destination ID to any traffic destined for each of the plurality of targets.

3. The IC of claim 2, wherein the NoC sends data to the plurality of targets only through the first decoder switch, wherein each of the plurality of targets corresponds to a different target destination ID.

4. The IC of claim 2, wherein the first decoder switch is configured to use different ports to route data to each of the plurality of targets.

5. The IC of claim 2, wherein data flows between the initiator and the first decoder switch along the same path in the NoC regardless of which target in the plurality of targets is the ultimate destination of the data.

6. The IC of claim 1, wherein the NoC comprises: a second NoC switch disposed between the first decoder switch and the target, wherein the second NoC switch is configured to use the target destination ID to route the data.

7. The IC of claim 6, wherein the second NoC switch does not store routing information corresponding to the first virtual destination ID, and wherein the first NoC switch does not store routing information corresponding to the target destination ID.

8. The IC of claim 1, wherein the NoC further comprises: a second decoder switch corresponding to a second virtual destination ID, wherein the second decoder switch controls access to a different set of unique targets than the first decoder switch, wherein the first NoC switch comprises routing information for both the first virtual destination ID and the second virtual destination ID.

9. The IC of claim 8, the IC further comprising: a second initiator configured to use a third NoC switch to route data to the first decoder switch using the first virtual destination ID and to route data to the second decoder switch using the second virtual destination ID.

10. The IC of claim 9, wherein the first decoder switch uses a first dedicated port to receive data from the initiator and a second dedicated port to receive data from the second initiator, and the second decoder switch uses a third dedicated port to receive data from the initiator and a fourth dedicated port to receive data from the second initiator.

11. A method comprising: receiving data at a NoC from an initiator; decoding an address associated with the data to generate a first virtual destination ID corresponding to a first decoder switch in the NoC; routing the data through a portion of the NoC to the first decoder switch using the first virtual destination ID; determining, at the first decoder switch, a target destination ID corresponding to a target of the data; and routing the data through a remaining portion of the NoC using the target destination ID.

12. The method of claim 11, wherein a plurality of targets are connected to the first decoder switch, the method further comprising: assigning the same first virtual destination ID to any traffic destined for each of the plurality of targets.

13. The method of claim 12, wherein the NoC sends data to the plurality of targets through only the first decoder switch, wherein each of the plurality of targets corresponds to a different target destination ID.

14. The method of claim 12, further comprising: sending data from the first decoder switch to each of the plurality of targets using a different port on the first decoder switch; or sending data received from the initiator to each of the plurality of targets via the first decoder switch, wherein data flows between the initiator and the first decoder switch along the same path in the NoC regardless of which of the plurality of targets is the ultimate destination of the data, wherein routing the data through the remaining portion of the NoC using the target destination ID comprises: using NoC switches disposed between the first decoder switch and the targets, wherein the NoC switches are configured to route the data using the target destination ID.

15. The method of claim 11, further comprising: receiving second data at the NoC from the initiator, the second data corresponding to a second target; decoding an address associated with the second data to generate a second virtual destination ID corresponding to a second decoder switch in the NoC; ​ using the second virtual destination ID to route the second data through a portion of the NoC to reach the second decoder switch; determining, at the second decoder switch, a second target destination ID corresponding to the second target; and using the second target destination ID to route the second data through a remaining portion of the NoC, wherein the second decoder switch controls access to a different set of unique targets than the first decoder switch, wherein a first NoC switch disposed between the initiator and the first and second decoder switches includes routing information for both the first and second virtual destination IDs.

Images