NOC relaxed write ordering scheme

Abstract

Embodiments herein describe an SoC including an NoC that supports both strict-order and relaxed-order requests. That is, some applications may require strict ordering, in which requests sent from the same ingress logic block to different egress logic blocks are executed sequentially. However, other applications may not require strict ordering, such as interleaved writes to memory. These applications can use relaxed ordering when the same ingress logic block can send multiple requests to different egress logic blocks in parallel. For example, an ingress logic block may receive a first request indicated as a relaxed-order request. After sending the request to the egress logic block, the ingress logic block may receive a second request. The ingress logic block can send the second request to a different egress logic block without waiting for a response for the first request.

Description

[Technical field]

[0001] Technical Field Examples of this disclosure generally relate to enforcing strict and relaxed ordering requirements using a network on a chip (NoC). [Background technology]

[0002] background A system-on-chip (SoC) (e.g., a field programmable gate array (FPGA), programmable logic device (PLD) or application specific integrated circuit (ASIC)) may include a packet network structure known as a network-on-chip (NoC) to route data packets between logic blocks within the SoC, such as programmable logic blocks, processors and memories. Summary of the Invention [Problem to be solved by the invention]

[0003] The NoC may include an ingress logic block (e.g., a master) that executes a read or write request to an egress logic block (e.g., a servant). The ingress logic block may receive multiple requests. If strict ordering is required, the ingress logic block may have to wait until a response to a first request is received from a first egress logic block before a second request can be sent to a different egress logic block. That is, strict ordering requires that responses to different egress logic blocks occur sequentially. Thus, this may cause a significant delay in which the ingress logic block waits for a response from each egress logic block before issuing another read or write request. [Means for solving the problem]

[0004] overview Techniques for defining relaxed ordering requests are described. One example is an integrated circuit including a first hardware entity, a second hardware entity, and a network-on-chip (NoC) providing connectivity between the first hardware entity and the second hardware entity. The NoC includes an ingress logic block coupled to the first hardware entity and an egress logic block coupled to the second hardware entity, the ingress logic block including a write tracker, the write tracker configured to receive a first request from the first hardware entity to write data to the second hardware entity and determine whether the first request is one of a relaxed ordering request or a strict ordering request, where the relaxed ordering request can be executed in parallel with a subsequently received response, while the strict ordering request cannot be executed in parallel with a subsequently received response having a different destination than the first request.

[0005] One example described herein is a method, the method comprising: receiving a first request to write data to a second hardware entity from a first hardware entity, the first hardware entity and the second hardware entity being communicatively coupled by a NoC, the method further comprising determining, at an ingress logic block within the NoC, whether the first request is one of a relaxed-order request or a strict-order request, wherein the relaxed-order request can be executed in parallel with a subsequently received response, while the strict-order request cannot be executed in parallel with a subsequently received response having a different destination than the first request.

[0006] So that the above features briefly summarized can be understood in detail, a more particular description can be had by reference to example embodiments, some of which are illustrated in the accompanying drawings. It should be noted, however, that the accompanying drawings depict only typical example embodiments and should not be considered as limiting the scope thereof. [Brief description of the drawings]

[0007] [Figure 1] 1 is a block diagram of an SoC including a programmable NoC according to an example. [Diagram 2] FIG. 2 illustrates an exemplary layout of an SoC including a programmable NoC, according to one example. [Diagram 3] 1 is a flowchart for servicing a write request using a linked list according to an example. [Figure 4] 11 is a flow chart for removing a write request from a linked list according to an example. [Figure 5A] FIG. 1 illustrates the state of a linked list when a write request is received and completed, according to an example. [Figure 5B] FIG. 1 illustrates the state of a linked list when a write request is received and completed, according to an example. [Figure 5C] FIG. 1 illustrates the state of a linked list when a write request is received and completed, according to an example. [Figure 5D] FIG. 1 illustrates the state of a linked list when a write request is received and completed, according to an example. [Figure 5E] FIG. 1 illustrates the state of a linked list when a write request is received and completed, according to an example. [Figure 5F] FIG. 1 illustrates the state of a linked list when a write request is received and completed, according to an example. [Figure 5G] FIG. 1 illustrates the state of a linked list when a write request is received and completed, according to an example. [Figure 5H] FIG. 1 illustrates the state of a linked list when a write request is received and completed, according to an example. [Figure 5I] FIG. 1 illustrates the state of a linked list when a write request is received and completed, according to an example. [Figure 5J] FIG. 1 illustrates the state of a linked list when a write request is received and completed, according to an example. [Figure 5K] FIG. 1 illustrates the state of a linked list when a write request is received and completed, according to an example. [Figure 5L] FIG. 1 illustrates the state of a linked list when a write request is received and completed, according to an example. [Figure 5M] FIG. 1 illustrates the state of a linked list when a write request is received and completed, according to an example. [Figure 5N] FIG. 1 illustrates the state of a linked list when a write request is received and completed, according to an example. [Figure 5O] FIG. 1 illustrates the state of a linked list when a write request is received and completed, according to an example. [Figure 5P] FIG. 1 illustrates the state of a linked list when a write request is received and completed, according to an example. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] 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 example may be beneficially incorporated in other examples.

[0009] Detailed Description 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 elements of similar structure or function are represented by similar reference numbers 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 description or as a limitation on the scope of the claims. Furthermore, the illustrated example does not necessarily have to have all aspects or advantages shown. An aspect or advantage described in relation to a particular example is not necessarily limited to that example and can be implemented in any other example, even if not so shown or explicitly described.

[0010] Embodiments herein describe a SoC including a NoC that supports both strict and relaxed-order requests. That is, some applications may require strict ordering (such as many processor-type operations) in which requests sent from the same ingress logic block (also called NoC master unit (NMU)) to different egress logic blocks (also called NoC slave units or NoC servant units (NSUs)) are executed sequentially. However, other applications may not require strict ordering, such as interleaved writes to memory. In these applications, relaxed ordering may be used when the same ingress logic block can send multiple requests to different egress logic blocks in parallel. For example, an ingress logic block may receive a first request that is indicated to be a relaxed-order request. After sending the request to a corresponding egress logic block, the ingress logic block may receive a second request to the same or different destination as the first request. The ingress logic block may send the second request to its destination without waiting for a response for the first request. In this way, by specifying requests as relaxed ordering, the delays caused by strict ordering can be avoided.

[0011] In one embodiment, the ingress logic block still returns a completion notification to the hardware entity that in turn submitted the request. Continuing with the example above, if the second request completes before the first request (e.g., the ingress logic block receives a response from the egress logic block corresponding to the second request before receiving a response from the egress logic block corresponding to the first request), the ingress logic block waits to notify the entity submitting the request that the second request is complete until the first request is completed. However, this may be a protocol-specific requirement and therefore may depend on the communication protocol used to transmit data over the NoC.

[0012] 1 is a block diagram of an SoC 100 including a NoC 105 according to an example. In one embodiment, the SoC 100 is implemented using a single integrated circuit (IC). In one embodiment, the SoC 100 includes a mix of hard and programmable logic. For example, the NoC 105 may be formed using hard circuitry rather than programmable circuitry such that its footprint on the SoC 100 is reduced.

[0013] As shown, NoC 105 interconnects programmable logic (PL) block 125A, PL block 125B, processor 110, and memory 120. That is, NoC 105 can be used within SoC 100 to enable different hard and programmable circuit elements within SoC 100 to communicate. For example, PL block 125A may use one ingress logic block 115 (e.g., an 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 respective egress logic blocks 140 (e.g., NSUs) for PL block 125B and processor 110, which can determine whether the data is intended for them based on the address (if a memory mapping protocol is used) or destination ID (if a streaming protocol is used).

[0014] PL block 125A may include egress logic block 140 for receiving data transmitted by PL block 125B and processor 110. In one embodiment, the hardware logic blocks can communicate with all other hardware logic blocks also connected to NoC 105, while in other embodiments, the hardware logic blocks may communicate with only a subportion of the other hardware logic blocks connected to NoC 105. For example, memory 120 can communicate with PL block 125A but not with PL block 125B.

[0015] As mentioned above, ingress logic block 115 and egress logic block 140 may all use the same or different communication protocols to communicate with PL block 125, processor 110, and memory 120. For example, PL block 125A may use a memory mapping protocol to communicate with PL block 125B, while processor 110 uses a streaming protocol to communicate with memory 120. In one embodiment, transport network 130 in NoC 105 may support multiple protocols.

[0016] In one embodiment, the SoC 100 is an FPGA that configures the PL block 125 according to a user design. That is, in this example, the FPGA includes both programmable and hard logic blocks. However, in other embodiments, the SoC 100 may be an ASIC that includes only hard logic blocks. That is, the SoC 100 may not include the PL block 125. Even though the logic blocks are non-programmable in that example, the NoC 105 may still be programmable, so that the hard logic blocks, e.g., the processor 110 and the memory 120, can switch between different communication protocols, change the data width in the interface, adjust the frequency, and so on.

[0017] NoC 105 allows entities (e.g., PL block 125, processor 110, and memory 120) to submit write requests using strict ordering or relaxed ordering. For example, processor 110 may always use strict ordering when sending data through NoC 105. However, PL block 125A may include a memory controller that can use relaxed ordering to store data in memory 120. Using embodiments herein, a user can customize SoC 100 such that certain writes facilitated by NoC 105 are performed using strict ordering or relaxed ordering.

[0018] Each of the ingress logic blocks 115 may include a write tracker 145 that tracks write requests sent by the ingress logic block to the egress logic block 140. The write tracker includes a linked list 150 and all status information regarding the write requests and received write responses. In one embodiment, the write tracker can handle a maximum number of requests (e.g., 64 requests), although this number may be implementation dependent.

[0019] Write tracker 145 includes a linked list 150 having a head and a tail. As write requests are received, they may be added to linked list 150. Additionally, as described below, write requests may be added to linked list 150 depending on whether they are strict-ordered or relaxed-ordered requests. For example, if linked list 150 already contains a strict-ordered request, subsequently received strict requests may be blocked (i.e., not added to linked list 150). Further details explaining how requests are added to and removed from linked list 150 are provided in FIGS. 3-5.

[0020] Figure 2 illustrates an exemplary layout of SoC 100 including NoC 105, according to one example. Similar to Figure 1, Figure 2 illustrates PL block 125, processor 110, memory 120, ingress logic block 115, and egress logic block 140. Figure 2 further illustrates connections and various switches 135 (labeled as boxes with "X's") used by a forwarding network within the NoC 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 only one example of the arrangement of these hardware elements. SoC 100 may further include more hardware elements than shown. For example, SoC 100 may include additional PL blocks, processors, and memories located at different locations on SoC 100. SoC 100 may further 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] 3 is a flow chart of a method 300 for servicing write requests using a linked list according to an example. At block 305, an ingress logic block receives a write request from a hardware entity (e.g., a PL block, a processor, a memory controller, an I / O module, etc.) in the SoC. For ease of explanation, the write request will be referred to below simply as a "request."

[0023] In block 310, the ingress logic block determines whether the request is blocked. A request may be blocked for multiple reasons. In one example, the linked list may already contain a strictly ordered request that has not yet completed. If the request received in block 305 is for a different destination than a strictly ordered request already in the linked list, the new request is blocked if it is also a strictly ordered request. In another example, the request may be subdivided into different "chops" (e.g., a 512-byte write request is split into two 256-byte chops). If the chops of a strictly ordered request are for two different destinations, the second chop may be blocked while the first chop is sent to its destination. That is, the second chop must wait while the first chop can be sent to its egress logic block. The memory system may also have a mode bit that can cause a strict request to wait until all relaxed-order requests with the same AXI ID are discarded from the write tracker. These examples are not intended to cover all scenarios in which a request would be blocked (at least partially) by the ingress logic block: the types of scenarios may vary depending on the implementation of the NoC and the communication protocol being used.

[0024] There are many circumstances in which a request is not blocked. For example, the Advanced eXtensible Interface (AXI) communication protocol allows requests with different AXI IDs to occur in parallel (e.g., without strict ordering). Thus, a strict-ordered or relaxed-ordered request to the same or different destination as another request with a different AXI ID may not be blocked. Furthermore, AXI allows requests with the same AXI ID and the same destination ID (e.g., the same destination egress logic block) to occur in parallel. Thus, even if the linked list has a previous strict-ordered request with the same destination as the new strict-ordered request received in block 305, the new request is not blocked. Conversely, a previously received strict-ordered request blocks a new strict-ordered request (with the same AXI ID) only if the new request has a different destination than the previously received request. Furthermore, if the previous request is a relaxed-ordered request, the new request (whether strict-ordered or relaxed-ordered) is not blocked by the previous request, regardless of whether the new request has the same destination or a different destination. Again, the memory system may have a mode bit that forces a strict request to wait until all relaxed order requests with the same AXI ID have been discarded from the write tracker. These examples are not intended to cover all scenarios in which a request may not be blocked in the ingress logic block. Figures 5A-5L show a number of different examples in which a request is blocked and unblocked by a previously received request.

[0025] If the request is blocked at block 310, the method 300 proceeds to block 315 where the ingress logic block adds a temporary entry in the write tracker for the request. That is, the ingress logic block does not add an entry to the linked list, but may nevertheless store a temporary entry for the request that can wait until the request is unblocked.

[0026] In block 320, the ingress logic block adds a request to the linked list after a previous blocking request has been serviced, i.e., completed. For example, if a new received request is blocked by a previously received strict ordering request, after a response is received from the destination corresponding to the previously received request, the ingress logic block can add a temporary entry for the new request to the linked list and send the request to its destination egress logic block.

[0027] Returning to block 310, if the request is not blocked, the method 300 proceeds to block 325 where the ingress logic block adds an entry corresponding to the request to the end of the linked list. If the request is the only request currently being tracked in the linked list, then its corresponding entry becomes both the head and the tail of the linked list.

[0028] At block 330, the ingress logic block transmits the request without waiting for a response associated with the previous request. That is, if there are other entries in the linked list that correspond to previously received requests, the ingress logic block may nevertheless transmit the newly received request to its destination without waiting for a response to the previously received request(s). In this manner, relaxed ordering may reduce delays between requests. That is, if a previous request is relaxed ordering, a new request may be transmitted without waiting for the ingress logic block to receive a response to the previous request. In contrast, if a previous request is strict ordering, a new strict ordering request with the same AXI ID but a different destination ID is blocked. Thus, by providing a user with the ability to specify which requests are strict ordering and which requests are relaxed ordering, a user may avoid delays caused by strict ordering blocking requests with the same AXI ID but different destination IDs.

[0029] There are several different ways to specify a request as relaxed or strict ordering. In one embodiment, a new bit, hereafter referred to as the RELAX bit, is added to each entry in the address map table maintained in the ingress logic block. This bit indicates whether the address region requires enforcement of strict or relaxed AXI write order rules. That is, the user can specify which address regions should follow strict or relaxed ordering, and the entity submitting the request (e.g., the PL block, processor, or memory controller) can assign the relax_order_en bit accordingly. In another embodiment, a two-bit AWUSER signal in the AXI write address channel is used to enforce either relaxed or strict write order. In yet another embodiment, the relax_order_en bit is also added to the write tracker entry data structure in the ingress logic block. This bit is set based on a lookup address map table entry (or remap operation). In another embodiment, another bit may be added to implement blocking between previous relaxed ordering requests and new strict ordering requests (ie, the block_en bit), as described below.

[0030] To illustrate how the RELAX bit can be used, in one embodiment, when a new strict AXI write request arrives at the ingress logic block and its dest-ID / RELAX bit is selected by the address map, the write tracker checks whether the linked list contains any VALID entries with a matching AXI-ID and the RELAX bit set to 0 (indicating that the previous request was a strictly ordered request). If any match with a different dest-ID of the new strictly ordered request is found, the new request is blocked and discarded, i.e., removed from the linked list, until the matching entry has received all its NoC responses. In contrast, when a new relaxed AXI write request arrives at the ingress logic block and its dest-ID / RELAX bit is selected by the address map, the write tracker does not block the write request from being sent to the NoC.

[0031] 4 is a flow diagram of a method 400 for removing a request from a linked list, according to an example. At block 405, the ingress logic block receives a response to the request from the egress logic block (i.e., the destination of the request).

[0032] At block 410, the ingress logic block determines whether the entry corresponding to the request is at the head of the linked list. That is, assuming that the linked list stores only requests with the same AXI ID, the write tracker determines whether the request is the oldest request stored in the linked list (e.g., the request is received before all other requests shown in the linked list). As described above, at least for AXI, the ingress logic block notifies the entity that submitted the request in the order in which the requests were received. Thus, if a request in the linked list finishes before a previously received request, the method 400 moves to block 415, where the write tracker waits until all previous responses in the linked list have been reported.

[0033] Once this occurs (or if the response was at the top of the linked list), the method 400 proceeds to block 420 where the write tracker reports the request as complete, ie, the request is discarded.

[0034] In block 425, the write tracker removes the entry from the linked list, i.e., the head of the linked list is moved to the next entry in the linked list.

[0035] 5A-5L illustrate the state of a write tracker as requests are received and completed, according to an example. That is, FIGS. 5A-5L illustrate the use of a write tracker to receive new requests and service those requests over multiple time periods. That is, FIG. 5A illustrates a first time period, FIG. 5B illustrates a second subsequent time period, FIG. 5C illustrates a third time period following the second time period, and so on. In one embodiment, the requests illustrated in FIGS. 5A-5L are received at the same write tracker (or the same ingress logical block), but FIG. 5L illustrates two linked lists that may be managed by two different write trackers or two different ingress logical blocks within the same ingress logical block.

[0036] 5A shows the state of the write tracker after receiving Req0. Because there were no previous requests being serviced by the write tracker (i.e., linked list 150 was empty), the write tracker can immediately add an entry for Req0 to linked list 150 and send the request on the NoC.

[0037] As shown, the entries in Figures 5A-5L include a VALID section indicating whether the entry is valid, an AXI-ID section indicating the AXI ID of the ingress logical block or the write tracker(s) within the ingress logical block, a DEST-ID section indicating the egress logical block to which the request is destined, a RELAX section indicating whether the request is strictly-ordered or relaxed-ordered, a STATUS section indicating whether all response(s) for the request have been received, a LAST section indicating whether the entry is the last entry for the request, and a RESP section indicating whether the request is a single request or has been split into multiple sub-requests or chops. The entry shown in Figure 5A is a strictly-ordered request (because the RELAX bit is set to 0 instead of 1), and the write tracker has not yet received a response to the request because the value of the STATUS bit is still 0 instead of 1.

[0038] 5B shows the state of the write tracker after receiving Req1. Req1 is a strictly ordered request (because the RELAX bit is 0) and has a different destination than Req0, i.e., D7 instead of D2. In this example, the write tracker blocks Req1 to maintain strict ordering because the STATUS bit of Req0 is still 0, indicating that the write tracker has not yet received a response to Req0. In other words, the write tracker does not send Req1 on the NoC to its destination.

[0039] 5B further illustrates that blocked Req1 is not added to linked list 150. Instead, the write tracker stores an entry for Req1 as temporary entry 505A. Blocking Req1 and storing temporary entry 505A in the write tracker is an example of the logic described in blocks 310 and 315 of method 300.

[0040] 5C illustrates the state of the write tracker after a response has been received from the destination of Req0. This is indicated in the entry corresponding to Req0 by the STATUS bit changing from 0 to 1. Because a response has been received, the write tracker can report that it is complete to the entity that submitted Req0, which is an example of the logic described in block 420 of method 400. Additionally, receiving a response to Req0 unblocks Req1, which is an example of the logic described corresponding to block 320 of method 300.

[0041] 5D shows the state of the write tracker after Req1 has been added to linked list 150: the entry for Req0 has been removed from linked list 150, and an entry for Req1 has been added to linked list 150 (and temporary entry 505A for Req1 can be removed from the write tracker). Req1 has been sent to its destination (i.e., D7), but the write tracker has not yet received a response. Because Req1 is the only request currently being serviced by the write tracker, its corresponding entry is both the head and the tail of linked list 150.

[0042] 5E illustrates the state of the write tracker after it receives Req2, a relaxed order request, as indicated by the RELAX bit having a value of 1. Furthermore, unlike Req0 and Req1, Req2 has been split into two chops, as indicated by the RESP section having a value of 2.

[0043] Because Req2 is a relaxed-order request, it is not blocked by the strict-order request Req1. Therefore, the write tracker can add an entry to the end of the linked list 150 for Req2 and forward the two chops to their respective destinations (which may be the same or different destinations). That is, the two chops can be forwarded to their destinations in parallel.

[0044] In this embodiment, the two chops of Req2 are represented by the same (i.e., single) entry in the linked list 150. That is, because Req2 is a relaxed-order request, it does not matter in what order the chops are sent or in what order the responses to the two chops are received at the write tracker. Thus, the write tracker can use the same entry for Req2 to ensure that it receives two responses (as indicated by the RESP section) before discarding Req2, but does not care in what order the responses to the chops are received.

[0045] FIG. 5F illustrates the state of the write tracker after it receives Req3. As shown, Req3 is a relaxed-order request with only one chop (unlike Req2, which has two chops). Because Req3 is a relaxed-order request, it is not blocked by requests already in linked list 150. Thus, the write tracker adds an entry for Req3 to the end of linked list 150 and forwards Req3 to its destination in the NoC. Thus, FIG. 5F illustrates that the write tracker has four pending requests: Req1, two chops (or subrequests) of Req2, and Req3.

[0046] FIG. 5G illustrates the state of the write tracker after receiving both responses to the chop of Req2. In response, the STATUS bit of the entry for Req2 is changed to 1 indicating that all responses have been received for that request. However, because Req2 is not at the top of the linked list 150 (i.e., it is not the oldest received request), the write tracker cannot report Req2 as completed. Thus, FIG. 5G illustrates an example of the logic discussed in blocks 410 and 415 of method 400, where the write tracker waits until all previous responses in the linked list are reported as completed. However, this requirement is specific to the AXI communication protocol and may not be required by other communication protocols. That is, it states that requests with the same AXI ID (in this example, all requests stored in the linked list 150 have the same ID) should be reported as completed in the order they are received. Thus, the write tracker cannot report Req2 as completed despite having received responses to both of its chops because it has not yet received a response from the destination of Req1. Therefore, the entry for Req2 remains in the link list 150.

[0047] 5H shows the state of the write tracker after a response to Req1 has been received. As shown, the STATUS bit for Req1 has changed from 0 to 1, and therefore Req1 can be reported as completed to the entity that submitted the request to the ingress logic block. The entry for Req1 in linked list 150 can be removed.

[0048] After the entry for Req1 is removed, the entry for Req2 becomes the head of linked list 150. Because a response for Req2 has already been received (as shown in FIG. 5G), the write tracker can also report Req2 as completed to the entity that submitted the request to the ingress logic block (after reporting Req1 as completed to maintain the AXI response order) and remove the entry representing the two chops of Req2 from linked list 150.

[0049] 5I shows the state of the write tracker after the entries for Req1 and Req2 have been removed from linked list 150, i.e., after these requests have been discarded. As a result, the entries for Req3 are at the top and bottom of linked list 150 because Req3 is the only request still pending in the write tracker.

[0050] FIG. 5J shows the state of the write tracker after receiving Req4, a strict-order request. Further, Req4 is subdivided into two chops, Chopl and Chop2. Thus, similar to the relaxed-order request Req2, Req4 has too much data to send in a single request through the NoC and is therefore split into multiple chops. In this example, the chops are sent to two different destinations, D2 and D3. For example, Req4 may be an interleaved write to two different memories.

[0051] Because Req4 is strictly ordered but Req3 is relaxed ordered, Req4 chop 1 is not blocked. However, because Chop 2 has a different destination than Req4 Chop 1, Chop 2 is blocked from being sent in parallel with Req4 Chop 1. If the destination of both chops was the same destination as Req4, both chops of Req4 could have been sent in parallel with Req3. Instead, the write tracker proceeds with the forwarding of Chopl on the NoC and stores the entries of the two chops as temporary entries 505B and 505C. That is, the write tracker does not need to add the chop of Req4 to the linked list 150.

[0052] 5K shows the state of the write tracker after receiving responses to Chopls Req3 and Req4. That is, the STATUS bits of Req3 and Req4 Chopl are changed to 1, indicating that the write tracker has received responses from their destinations, i.e., D2 and D3. In this example, the write tracker copies the NoC response for Req4 Chop1 to the entry for Chop2 (i.e., entry 505C).

[0053] Furthermore, because a response has been received for Req3, the write tracker can report Req3 as completed and remove its entry from linked list 150. Also, because a response has been received for Chop1, Req4 Chop2 is no longer blocked by AXI strict ordering and can be sent to the NoC.

[0054] Figure 5L shows the state of the write tracker after receiving Req5 with a different AXI ID than previous requests received at the ingress logic block (e.g., Req0-Req4). Figure 5L also shows that temporary entries 505B-C have been combined and added to linked list 150. That is, linked list 150 contains an entry for Chop2 of Req4 and a response for Chop1, although this is not a requirement.

[0055] In this embodiment, because Req5 has a different AXI ID than the previous request, the write tracker stores an entry for Req5 in linked list 510. In one embodiment, the write tracker maintains a different linked list for each AXI ID. For example, the ingress logic block may accommodate multiple AXI IDs. The ingress logic block may maintain a respective linked list for each of the AXI IDs.

[0056] As mentioned above, AXI allows requests with different AXI IDs to be sent in parallel, regardless of whether those requests are in strict or relaxed order. That is, Req5 is not blocked by Req4 because they are assigned to different AXI IDs than Req5 and Req4. Thus, Req5 can be sent to the NoC without waiting for a response to Chop2 to be received first. Furthermore, the write tracker can report receipt of Req4 and the response to Req5 in any order because they are assigned to different AXI IDs (and stored in different linked lists). That is, if the write tracker receives a response to Req5 before the response to Req4 Chop2, the write tracker can go ahead and report Req5 as completed to the entity that submitted it without waiting for Req4 to be reported as completed first, which is AXI compliant.

[0057] Figure 5M shows the state of the write tracker after receiving Req6, a strictly ordered request, which is not blocked and can be sent immediately.

[0058] 5N shows the state of the write track after receiving a relaxed order request, Req7. Req7 contains two chops and is not blocked, so it can be sent immediately and added to the linked list 150.

[0059] FIG. 5O shows the state of the write tracker after receiving Req8, which is a strict-order request. Furthermore, Req8 has a block_en bit (not shown in FIG. 5O) that enforces blocking between the previous relaxed-order request and the new strict-order request. Thus, even though Req8 would otherwise be unblocked, the block_en bit instructs the ingress logic block to block Req8 from being sent. That is, the write tracker blocks Req8 because Req7 is a previously received relaxed-order request. Thus, Req8 is not added to the linked list 150.

[0060] 5P shows the state of the write tracker after completing Req6 and Req7: the write tracker has received responses from the destinations of both chops of Req7 and has removed Req7 from linked list 150. Since there are no previously received relaxed order requests in list 150, Req8 is unblocked and can be sent to its destination.

[0061] The disclosed technology can be expressed by the following non-limiting examples in addition to the claims.

[0062] Example 1. An integrated circuit comprising: a first hardware entity, a second hardware entity, and a network-on-chip (NoC) providing connectivity between the first hardware entity and the second hardware entity, the NoC including an ingress logic block coupled to the first hardware entity and an egress logic block coupled to the second hardware entity, the ingress logic block including a write tracker, the write tracker configured to receive a first request from the first hardware entity to write data to the second hardware entity and determine whether the first request is one of a relaxed ordering request or a strict ordering request, where the relaxed ordering request can be executed in parallel with a subsequently received response while the strict ordering request cannot be executed in parallel with a subsequently received response having a different destination than the first request.

[0063] Example 2. The integrated circuit of example 1, wherein the write tracker is configured to determine that the first request is not blocked by a previous request received at the ingress logic block, the previous request being a relaxed order request.

[0064] Example 3. The integrated circuit of example 2, wherein the write tracker is configured to, upon determining that the first request is not blocked, add a second entry to the end of the linked list corresponding to the first request, the linked list including the first entry corresponding to the previous request.

[0065] Example 4. The integrated circuit of example 2, wherein the write tracker is configured to send the first request to the second hardware entity without waiting for a response from a destination of the previous request.

[0066] Example 5. The integrated circuit of example 1, wherein the write tracker is configured to determine that the first request is blocked by a previous request received at the ingress logic block, the previous request being a strictly ordered request.

[0067] Example 6. The integrated circuit of example 5, wherein the write tracker is configured, upon determining that the first request is blocked, to add a temporary entry corresponding to the first request, receive a response from a destination of the previous request, unblock the first request, and add an entry corresponding to the first request to the linked list.

[0068] Example 7. The integrated circuit of example 1, wherein a strictly ordered request can be executed in parallel with a subsequently received response having the same destination as the first request.

[0069] Example 8. The integrated circuit of example 1, wherein the write tracker is configured to receive a response from the egress logic block after the egress logic block receives the first request and determine whether an entry corresponding to the first request is at the head of a linked list, the linked list tracking pending write requests being processed by the write tracker.

[0070] Example 9. The integrated circuit of Example 8, wherein the write tracker is configured, upon determining that an entry corresponding to the first request is not at the top of the linked list, to wait until all previous responses indicated in the linked list have been reported, and to report to the first hardware entity that the first request is completed after determining that the first request is at the top of the linked list in a manner compatible with an Advanced eXtensible Interface (AXI) response order.

[0071] Example 10. A method comprising receiving a first request to write data to a second hardware entity from a first hardware entity, the first hardware entity and the second hardware entity being communicatively coupled by a NoC, the method further comprising determining, at an ingress logic block within the NoC, whether the first request is one of a relaxed-order request or a strict-order request, where a relaxed-order request can be executed in parallel with a subsequently received response while a strict-order request cannot be executed in parallel with a subsequently received response having a different destination than the first request.

[0072] Example 11. The method of Example 10, further comprising determining that the first request is not blocked by a previous request received at the ingress logic block, the previous request being a relaxed order request.

[0073] Example 12. The method of Example 11, further comprising adding a second entry to the end of the linked list corresponding to the first request upon determining that the first request is not blocked, the linked list including the first entry corresponding to the previous request.

[0074] Example 13. The method of Example 11, further comprising sending the first request through the NoC to a second hardware entity without waiting for a response from a destination of the previous request.

[0075] Example 14. The method of example 10, further comprising determining that the first request is blocked by a previous request received at the ingress logic block based on a block_en bit that enforces blocking between a previously received relaxed-order request and a currently received strict-order request.

[0076] Example 15. The method of Example 14, further comprising, upon determining that the first request is blocked, adding a temporary entry corresponding to the first request, receiving a response from a destination of the previous request, and unblocking the first request and adding an entry corresponding to the first request to the linked list.

[0077] Example 16. The method of example 10, in which a strictly ordered request can be executed in parallel with a subsequently received response having the same destination as a first request.

[0078] Example 17. The method of Example 10, further comprising receiving a response from an egress logic block in the NoC after the egress logic block receives the first request, and determining whether an entry corresponding to the first request is at the head of a linked list, the linked list tracking pending write requests being processed by the ingress logic block.

[0079] Example 18. The method of Example 17, further comprising, upon determining that an entry corresponding to the first request is not at the top of the linked list, waiting until all previous responses indicated in the linked list are reported, and reporting the first request as completed after determining that the first request is at the top of the linked list, compatible with AXI response ordering.

[0080] Example 19. The method of Example 18, further comprising removing an entry from the linked list that corresponds to the first request.

[0081] Example 20. The method of Example 10, further comprising splitting the first request into multiple chops to be transmitted on the NoC, and waiting until responses for all of the chops are received from their respective destinations before reporting the first request to the first hardware entity as completed.

[0082] While the above is directed to specific examples, other and further examples may be devised without departing from the basic scope thereof, the scope of which is determined by the claims that follow.

Claims

1. 1. An integrated circuit comprising: a first hardware entity; a second hardware entity; and a network-on-chip (NoC) providing connectivity between the first hardware entity and the second hardware entity; The NoC includes: an ingress logic block coupled to the first hardware entity; an egress logic block coupled to the second hardware entity; the ingress logic block includes a write tracker; The write tracker receiving a first request from the first hardware entity to write data to the second hardware entity; configured to determine whether the first request is one of a relaxed ordering request or a strict ordering request; an integrated circuit configured to: when the first request is the relaxed-order request, the first request and a second request received after the first request can be executed in parallel without waiting for a response to the first request; and when the first request is the strict-order request, the first request and the second request having a different destination than the first request cannot be executed in parallel until a response to the first request is received.

2. the write tracker is configured to determine that the first request is not blocked by a previous request received at the ingress logic block; The integrated circuit of claim 1 , wherein the previous request is a relaxed order request.

3. the write tracker is configured to, upon determining that the first request is not blocked, add a second entry to the end of the linked list corresponding to the first request; 3. The integrated circuit of claim 2, wherein the linked list includes a first entry corresponding to the previous request.

4. 3. The integrated circuit of claim 2, wherein the write tracker is configured to send the first request to the second hardware entity without waiting for a response from a destination of the previous request.

5. the write tracker is configured to determine that the first request is blocked by a previous request received at the ingress logic block; The integrated circuit of claim 1 , wherein the previous request is a strict-order request.

6. The write tracker upon determining that the first request is blocked, adding a temporary entry corresponding to the first request; receiving a response from the destination of said previous request; 6. The integrated circuit of claim 5, configured to unblock the first request and add an entry corresponding to the first request to a linked list.

7. An integrated circuit as described in claim 1, wherein if the first request is the strictly ordered request, the first request and the second request having the same destination as the first request can be executed in parallel.

8. The write tracker receiving a response from the egress logic block after the egress logic block receives the first request; configured to determine whether an entry corresponding to the first request is at the head of a linked list; 2. The integrated circuit of claim 1, wherein the linked list tracks pending write requests being processed by the write tracker.

9. The write tracker if determining that the entry corresponding to the first request is not at the head of the linked list, waiting until all previous responses indicated in the linked list have been reported; 9. The integrated circuit of claim 8, wherein the integrated circuit is configured to report the first request as completed to the first hardware entity after determining that the first request is at the head of the linked list in a manner compatible with Advanced eXtensible Interface (AXI) response ordering.

10. 1. A method comprising: receiving a first request from a first hardware entity to write data to a second hardware entity; the first hardware entity and the second hardware entity are communicatively coupled by an Network on Chip; The method further comprises determining, at an ingress logic block in the NoC, whether the first request is one of a relaxed-order request or a strict-order request; wherein, if the first request is the relaxed-order request, the first request and a second request received after the first request can be executed in parallel without waiting for a response to the first request, while, if the first request is the strict-order request, the first request and the second request having a different destination than the first request cannot be executed in parallel until a response to the first request is received.

11. determining that the first request is not blocked by a previous request received at the ingress logic block; The method of claim 10 , wherein the previous request is a relaxed order request.

12. determining that the first request is blocked by a previous request received at the ingress logic block based on a block_en bit that enforces blocking between a previously received relaxed-order request and a currently received strict-order request; The method of claim 10 , wherein the previous request is a relaxed order request.

13. The method described in claim 10, wherein if the first request is the strictly ordered request, the first request and the second request having the same destination as the first request can be executed in parallel.

14. receiving a response from an egress logic block in the NoC after the egress logic block receives the first request; determining whether the entry corresponding to the first request is at the head of a linked list; The method of claim 10 , wherein the linked list tracks pending write requests being processed by the ingress logical block.

15. Dividing the first request into multiple chops to be transmitted over the Network on Chip (NoC); and waiting until responses for all of the chops have been received from their respective destinations before reporting the first request to the first hardware entity as completed.

Images