noc relaxed write order scheme

Abstract

Embodiments herein describe SoCs that include NoCs that support strict ordering requests and relaxed ordering requests. That is, some applications can require strict ordering, where requests transmitted from the same entry logic to different exit logic blocks are executed sequentially. However, other applications can not require strict ordering, such as interleaved writes to memory. In these applications, relaxed ordering can be used if the same entry logic block can transmit multiple requests in parallel to different exit logic blocks. For example, an entry logic block can receive a first request that is indicated as a relaxed ordered request. After transmitting the request to an exit logic block, the entry logic block can receive a second request. The entry logic block can transmit the second request to a different exit logic block without waiting for a response to the first request.

Description

Technical Field

[0001] The examples disclosed herein generally involve performing strictly ordered and loosely ordered requests using 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 an on-chip network (NoC) to route data packets between logic blocks (e.g., programmable logic blocks, processors, memory, etc.) within the SoC.

[0003] NoC can include ingress logic blocks (e.g., master logic blocks) that execute read or write requests to egress logic blocks (e.g., slave logic blocks). An ingress logic block can receive multiple requests. If strict ordering is required, an ingress logic block may have to wait until it receives a response to a first request from a first egress logic block before it can transmit a second request to a different egress logic block. In other words, strict ordering requires that responses to different egress logic blocks occur in a specific order. Therefore, this can lead to significant latency if an ingress logic block waits for responses from each egress logic block before issuing another read or write request. Summary of the Invention

[0004] A technique for defining loosely ordered requests is described. An example is an integrated circuit including a first hardware entity, a second hardware entity, and an on-chip network (NoC) providing connectivity between the first and second hardware entities. The NoC includes an entry logic block coupled to the first hardware entity and an exit logic block coupled to the second hardware entity. The entry logic block includes a 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 a loosely ordered request or a strictly ordered request, wherein the loosely ordered request can be executed in parallel with subsequently received responses, while a strictly ordered request cannot be executed in parallel with subsequently received responses having a destination different from the first request.

[0005] One example described herein is a method that includes receiving a first request from a first hardware entity to write data to a second hardware entity, wherein the first and second hardware entities are communicatively coupled via a NoC, and determining at an entry logic block in the NoC whether the first request is a loosely ordered request or a strictly ordered request, wherein a loosely ordered request can be executed in parallel with a subsequently received response, while a strictly ordered request cannot be executed in parallel with a subsequently received response having a destination different from the first request. Attached Figure Description

[0006] To gain a more detailed understanding of the features described above, reference can be made to exemplary embodiments for a more specific description of the above-brief overview, some of which are illustrated in the accompanying drawings. However, it should be noted that the drawings only show typical exemplary embodiments and should not be considered as limiting the scope thereof.

[0007] Figure 1 This is a block diagram of a SoC containing a programmable NoC, based on an example.

[0008] Figure 2 An exemplary layout of a SoC containing a programmable NoC is shown, based on an example.

[0009] Figure 3 This is a flowchart based on an example of a write request using a linked list service.

[0010] Figure 4 This is a flowchart based on an example for removing write requests from a linked list.

[0011] Figures 5A-5P The diagram illustrates the state of the linked list as it receives and completes write requests, based on an example.

[0012] For ease of understanding, the same reference numerals are used where possible to denote the same elements common to the figures. It is conceivable that elements in one example can be beneficially incorporated into other examples. Detailed Implementation

[0013] The various features will be described below with reference to the accompanying drawings. It should be noted that the drawings may be drawn to scale or not, and in all drawings, elements with similar structures or functions are indicated by similar reference numerals. 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 specification or as a limitation on the scope of the claims. Furthermore, the examples shown do not need to 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 shown or so explicitly described.

[0014] The embodiments described herein depict a SoC including NoC that supports both strict and loose ordering requests. That is, some applications may require strict ordering (e.g., operations of many processor types), where requests transferred from the same entry logic block (also known as the NoC master unit (NMU)) to different exit logic blocks (also known as NoC slave units or NoC service units (NSU)) are executed sequentially. However, other applications may not require strict ordering, such as interleaved writes to memory. In these applications, loose ordering can be used if the same entry logic block can transfer multiple requests in parallel to different exit logic blocks. For example, an entry logic block may receive a first request indicated as a loosely ordered request. After transferring the request to the corresponding exit logic block, the entry logic block may receive a second request destined for the same or a different destination than the first request. The entry logic block can then transfer the second request to its destination without waiting for a response to the first request. In this way, specifying requests as loosely ordered avoids the latency caused by strict ordering.

[0015] In one embodiment, the ingress logic block still returns a completion notification to the hardware entities that submitted the requests in sequence. Continuing the example above, if the second request is completed 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 entities that submitted the requests that the second request has been completed until the first request has been completed. However, this may be a protocol-specific requirement and therefore may depend on the communication protocol used to transmit data on the NoC.

[0016] Figure 1 This is a block diagram of an SoC 100 containing a NoC 105, based on an example. In one embodiment, the SoC 100 is implemented using a single integrated circuit (IC). In one embodiment, the SoC 100 includes a hybrid of hardened logic and programmable logic. For example, a hardened circuit system can be used instead of a programmable circuit system to form the NoC 105, thereby reducing its footprint in the SoC 100.

[0017] As shown in the figure, NoC 105 interconnects programmable logic (PL) blocks 125A, PL blocks 125B, processor 110, and memory 120. That is, NoC can be used within SoC 100 to allow different hardened and programmable circuitry system elements within SoC 100 to communicate. For example, PL block 125A can communicate with PL block 125B using one entry logic block 115 (e.g., 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 transfer data to corresponding exit logic blocks 140 (e.g., NSU) of PL block 125B and processor 110, and processor 110 can determine whether the data is intended for them based on address (if using a memory mapping protocol) or destination ID (if using a streaming protocol).

[0018] PL block 125A may include an exit logic block 140 for receiving data transmitted by PL block 125B and processor 110. In one embodiment, the hardware logic block is capable of communicating with all other hardware logic blocks also connected to NoC 105, but 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.

[0019] 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, the transfer network 130 in NoC 105 can support multiple protocols.

[0020] In one embodiment, SoC 100 is an FPGA configured with PL block 125 according to a user design. That is, in this example, the FPGA includes both programmable logic blocks and hardened logic blocks. However, in other embodiments, 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 is still programmable, allowing the hardened logic blocks (e.g., processor 110 and memory 120) to switch between different communication protocols, change the data width at the interface, or adjust the frequency.

[0021] NoC 105 allows entities (e.g., PL block 125, processor 110, and memory 120) to submit write requests using either strict or loose ordering. For example, when transferring data via NoC 105, processor 110 can always use strict ordering. However, PL block 125A may include a memory controller that can use loose ordering to store data in memory 120. Using the embodiments described herein, a user can customize SoC 100 to perform certain writes facilitated by NoC 105 using either strict or loose ordering.

[0022] Each entry logic block in entry logic block 115 may include a write tracker 145 that tracks write requests transmitted from the entry logic block to the exit logic block 140. The write tracker includes a linked list 150 and all status information regarding write requests and received write responses. In one embodiment, the write tracker may handle a maximum number of requests (e.g., 64 requests), but this number may vary depending on the implementation.

[0023] Write tracker 145 includes a linked list 150 with a head and a tail. When a write request is received, it can be added to linked list 150. Furthermore, as described below, write requests can be added to linked list 150 depending on whether they are strictly ordered or loosely ordered. For example, if linked list 150 already includes strictly ordered requests, subsequently received strict requests may be blocked (i.e., not added to linked list 150). Figure 3 Section -5 describes the details used to explain how to add and remove requests from linked list 150.

[0024] Figure 2 An exemplary layout of a SoC 100 containing NoC 105 is shown, based on an example. (Compared to...) Figure 1 similar, Figure 2 The diagram shows PL block 125, processor 110, memory 120, and input logic block 115 and output logic block 140. Furthermore, Figure 2 The diagram shows the transfer network in the NoC used for routing packets between ingress logic block 115 and egress logic block 140, and various switches 135 (labeled as boxes with “X”).

[0025] 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 110 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.

[0026] Figure 3 This is a flowchart of method 300 for writing requests using a linked list service, based on an example. In block 305, the entry logic block receives the write request from hardware entities in the SoC (e.g., PL block, processor, memory controller, I / O module, etc.). For ease of explanation, the write request will be referred to as a "request" below.

[0027] In box 310, the entry logic block determines whether a request is blocked. A request may be blocked for a variety of reasons. In one example, the list may already contain strictly ordered requests that have not yet been completed. If a request received at box 305 is to a different destination than a strictly ordered request already existing in the list, the new request is blocked if it is also a strictly ordered request. In another example, a request may be subdivided into different “chops” (e.g., a 512-byte write request is divided into two 256-byte segments). If the segments of a strictly ordered request are for two different destinations, the second segment may be blocked while the first segment is transferred to its destination. That is, the first segment can be transferred to its exit logic block while the second segment must wait. The memory system may also have a mode bit that can force a strictly ordered request to wait until all loosely ordered requests with the same AXI ID are retired from the write tracker. These examples are not intended to cover all scenarios in which a request will be blocked (at least partially) by the entry logic block. The type of scenario can vary depending on the implementation of the NoC and the communication protocol used.

[0028] There are many other situations where requests are 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). Therefore, strictly or loosely ordered requests with the same or different destinations as another request with a different AXI ID will not be blocked. Furthermore, AXI allows requests with the same AXI ID and the same destination ID (e.g., the same destination exit logic block) to occur in parallel. Therefore, even if the list has previous strictly ordered requests with the same destination as the new strictly ordered request received at box 305, the new request will not be blocked. Conversely, a previously received strictly ordered request will only block a new strictly ordered request (with the same AXI ID) if the new request has a different destination than the previously received request. Furthermore, if the previous request was a loosely ordered request, the new request (whether strictly ordered or loosely ordered) will not be blocked by the previous request, regardless of whether the new request has the same or different destinations. Similarly, the memory system may also have a mode bit that enforces strict request waiting until all loosely ordered requests with the same AXI ID are deferred from the write tracker. These examples are not intended to cover all scenarios where requests will not be blocked at the entry logic block. Figure 5A-5L The document shows many different examples where a request is blocked and unblocked by a previously received request.

[0029] If the request is blocked at box 310, method 300 proceeds to box 315, where the entry logic block adds a temporary entry for the request in the write tracker. That is, the entry logic block does not add the entry to the linked list, but can still store a temporary entry for the request, where the request can wait until it is unblocked.

[0030] At box 320, the ingress logic block adds the request to the list after a previously blocked request has been served (i.e., completed). For example, if a newly received request is blocked by a previously received strictly ordered request, the ingress logic block can add a temporary entry for the new request to the list and transmit the request to its destination egress logic block after receiving a response from the destination corresponding to the previously received request.

[0031] Returning to box 310, if the request is not blocked, method 300 proceeds to box 325, where the entry logic block adds the entry corresponding to the request to the tail of the list. If the request is the only request currently being tracked in the list, its corresponding entry will be both the head and tail of the list.

[0032] In box 330, the ingress block transmits requests without waiting for responses to previous requests. That is, if other entries in the list correspond to previously received requests, the ingress block can still transmit the newly received request to its destination without waiting for responses to the previously received requests(one or more). In this way, loose ordering reduces latency between requests. Specifically, if the previous request was loosely ordered, the new request can be transmitted without waiting for the ingress block to receive a response to the previous request. In contrast, if the previous request was strictly ordered, new strictly ordered requests with the same AXI ID but a different destination ID are blocked. Therefore, by providing the user with the ability to specify which requests are strictly ordered and which are loosely ordered, the user can avoid latency caused by strictly ordered requests with the same AXI ID but different destination IDs being blocked.

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

[0034] To illustrate how the leniency bit is used, in one embodiment, when a new strict AXI write request arrives at the ingress logic block and its dest-ID / leniency bit is selected by the address mapping, the write tracker checks the linked list for any valid (VALID) entries where the matching AXI-ID and leniency bit are set to 0 (indicating that the previous request was a strict ordering request). If a match with a different dest-ID is found with the new strict ordering request, the new request is blocked until the matching entry receives all its NoC responses and is deferred—i.e., removed from the linked list. Conversely, when a new leniency AXI write request arrives at the ingress logic block and its dest-ID / leniency bit is selected by the address mapping, the write tracker does not block the write request from being sent to the NoC.

[0035] Figure 4 This is a flowchart of method 400 for removing a request from a linked list, based on the example. At box 405, the entry logic block receives the response to the request from the exit logic block (i.e., the destination of the request).

[0036] In box 410, the entry logic block determines whether the entry corresponding to the request is at the head of the linked list. That is, assuming the linked list only stores requests with the same AXI ID, the write tracker determines whether the request is the oldest request stored on the linked list (e.g., the request was received before all other requests represented in the linked list). As mentioned above, at least for AXI, the entry logic block notifies the entity that submitted the request in the order the requests were received. Therefore, if a request in the linked list completes before a previously received request, method 400 moves to box 415, where the write tracker waits until all previous responses in the linked list have been reported.

[0037] Once completed (or if the response is at the head of the list), method 400 proceeds to box 420, where the tracker writes a report that the request has been completed—that is, the request has been terminated.

[0038] At box 425, the write tracker removes an entry from the linked list. That is, the head of the linked list is moved to the next entry in the list.

[0039] Figure 5A-5L The example shows the state written to the tracker when a request is received and completed. That is, Figure 5A-5L This demonstrates how a write tracker is used to receive and serve new requests over multiple time periods. In other words, Figure 5A The first time period is shown. Figure 5B The second subsequent time period is shown, while Figure 5C A third time period is shown after the second time period, and so on. In one embodiment, it is received at the same write tracker (or the same entry logic block). Figure 5A-5L The request shown in the document, although Figure 5L This illustrates two linked lists that can be managed by the same entry logic block or by two different write trackers in two different entry logic blocks.

[0040] Figure 5A The state of the write tracker is shown after Req0 is received. Since no previous request has been written to the tracker service (i.e., list 150 is empty), the write tracker can immediately add the entry for Req0 to list 150 and transmit the request on NoC.

[0041] As shown in the figure Figure 5A-5LThis includes a valid (VALID) section indicating whether an entry is valid, an AXI-ID section indicating the AXI ID of an entry logic block or a write tracker (one or more) within an entry logic block, a DEST-ID section indicating the exit logic block that is the destination of the request, a loose section indicating whether the request is strictly ordered or loosely ordered, a STATUS section indicating whether all responses (one or more) to the request have been received, a LAST section indicating whether the entry is the last entry of the request, and a RESP section indicating whether the request is a single request or has been broken down into multiple sub-requests or segments. Figure 5A The entry shown is a strict ordering request (because the loose bit is set to 0 instead of 1), and the write tracker has not yet received a response to the request because the status bit value is still 0 instead of 1.

[0042] Figure 5B The diagram illustrates the state of the write tracker after receiving Req1. Req1 is a strictly ordered request (because the loose bit is 0) and has a different destination than Req0—namely, D7 instead of D2. In this example, since the status bit of Req0 is still 0, indicating that the write tracker has not yet received a response to REQ0, the write tracker block blocks Req1 to maintain strict ordering. In other words, the write tracker does not transfer Req1 on NoC to its destination.

[0043] also, Figure 5B This shows that the blocked Req1 is not added to linked list 150. Instead, the write tracker stores the entry for Req1 as a temporary entry 505A. Blocking Req1 and storing the temporary entry 505A in the write tracker is an example of the logic described in boxes 310 and 315 of method 300.

[0044] Figure 5C This shows the status of the write tracker after a response from the destination of Req0 has been received. This is indicated in the entry corresponding to Req0 by a status bit changing from 0 to 1. Since a response has now been received, the write tracker can report to the entity that submitted Req0 that it has completed, which is an example of the logic described in box 420 of method 400. Furthermore, receiving a response to Req0 unblocks Req1, which is an example of the description in box 320 corresponding to method 300.

[0045] Figure 5DThis shows the state of the write tracker after Req1 has been added to linked list 150. That is, the entry for Req0 has been removed from linked list 150, while the entry for Req1 has been added to linked list 150 (and the temporary entry 505A for Req1 can be removed from the write tracker). Req1 has been transmitted to its destination (i.e., D7), but the write tracker has not yet received a response. Because Req1 is currently the only request served by the write tracker, its corresponding entries are at the head and tail of linked list 150.

[0046] Figure 5E The state of the write tracker after receiving Req2 is shown. Req2 is a loosely ordered request indicated by a loose bit with a value of 1. Furthermore, unlike Req0 and Req1, Req2 has been divided into two segments, as shown by the RESP segment with a value of 2.

[0047] Because Req2 is a loosely ordered request, it will not be blocked by the strictly ordered request Req1. Therefore, the write tracker can add an entry to the tail of linked list 150 of Req2 and forward its two segments to their respective destinations (which may be the same or different). That is, the two segments can be forwarded to their destinations in parallel.

[0048] In this embodiment, the two segments of Req2 are represented by the same (i.e., a single) entry in linked list 150. That is, because Req2 is a loosely ordered request, the order in which the segments are transmitted, or the order in which responses to the two segments are received at the write tracker, is not important. Therefore, the write tracker can use the same entry for Req2 to ensure that it receives both responses (as shown in the RESP segment) before retiring Req2, but does not care in what order the responses to the segments are received.

[0049] Figure 5F The diagram illustrates the state of the write tracker after receiving Req3. As shown, Req3 is a loosely ordered request with only one segment (unlike Req2, which has two segments). Because Req3 is a loosely ordered request, it will not be blocked by any requests already existing in linked list 150. Thus, the write tracker adds the entry for Req3 to the tail of linked list 150 and forwards REQ3 to its destination in its NoC. Therefore, Figure 5F The write tracker is shown to have four pending requests: Req1, two segments (or sub-requests) of Req2, and Req3.

[0050] Figure 5GThe diagram shows the status of the write tracker after receiving two responses to a segment of Req2. In response, the status bit of the Req2 entry changes to 1, indicating that all responses to the request have been received. However, because Req2 is not at the head of linked list 150 (i.e., not the earliest received request), the write tracker cannot report that Req2 has been completed. Therefore, Figure 5G An example of the logic discussed in blocks 410 and 415 of method 400 is shown, where the write tracker waits until all previous responses in the linked list have been reported as complete. However, this requirement is specific to the AXI communication protocol, and other communication protocols may not require it. That is, AXI states that requests with the same AXI ID (in this example, all requests stored in linked list 150 have the same ID) should be reported as complete in the order they are received. Therefore, because the write tracker has not yet received a response from the destination of Req1, it cannot report Req2 as complete even though responses to both of its segments have been received. Thus, the entry for Req2 remains in linked list 150.

[0051] Figure 5H The status of the write tracker after a response to Req1 has been received is shown. As shown, the status bit of Req1 has changed from 0 to 1, therefore, Req1 can report to the entity that submitted the request to the entry logic block that Req1 has been completed. The Req1 entry in linked list 150 can be removed.

[0052] After removing the entry for Req1, the entry for Req2 is now at the head of linked list 150. This is because a response to Req2 has been received (e.g., ...). Figure 5G As shown), the write tracker also reports to the entity that submitted the request to the entry logic block that Req2 has been completed (after reporting that Req1 has been completed to maintain the AXI response order), and removes the entries representing the two Req2 from the linked list 150.

[0053] Figure 5I This shows the state of the write tracker after the entries for Req1 and Req2 have been removed from linked list 150—that is, after these requests have been retired. Therefore, the entry for Req3 is now at the head and tail of linked list 150, as Req3 is the only pending request in the write tracker.

[0054] Figure 5JThe diagram illustrates the state of the write tracker after receiving Req4 as a strict ordering request. Furthermore, Req4 is subdivided into two segments: Segment 1 and Segment 2. Therefore, similar to the loosely ordered request Req2, Req4 has too much data to be sent in a single request via NoC, and is thus divided into multiple segments. In this example, the segments are sent to two different destinations: D2 and D3. For example, Req4 could be an interleaved write to two different memories.

[0055] Although Req4 is strictly ordered, Req3 is loosely ordered, so Req4 segment 1 is not blocked. However, because segment 2 has a different destination than Req4 segment 1, segment 2 is blocked and transmitted in parallel with Req4 segment 1. If both segments had the same destination as Req3, both segments of Req4 could be transmitted in parallel with Req3. Instead, the write tracker continues to forward segment 1 on NoC and stores the entries for both segments 1 as temporary entries 505B and 505C. That is, the write tracker may not add segments of Req4 to linked list 150.

[0056] Figure 5K This shows the state of the write tracker after receiving a response to segment 1 of Req3 and Req4. That is, the status bits for Req3 and segment 1 of Req4 become 1, indicating that the write tracker has received a response from its destinations (i.e., D2 and D3). In this example, the write tracker copies the NoC response of segment 1 of Req4 to the entry for segment 2 (i.e., entry 505C).

[0057] Furthermore, since a response to Req3 has been received, the write tracker can report that Req3 is complete and remove its entry from linked list 150. Additionally, since a response to segment 1 has been received, segment 2 of Req4 is no longer blocked by AXI strict ordering and can be sent to NoC.

[0058] Figure 5L The state of the tracker is shown after Req5 is received, which has a different AXI ID than the previous requests (e.g., Req0-Req4) received at the entry logic block. Figure 5L It is also shown that temporary entries 505B-C have been combined and added to linked list 150. That is, linked list 150 includes entries for segment 2 of Req4 and includes responses to segment 1, but this is not required.

[0059] 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, an entry logic block may correspond to multiple AXI IDs. The entry logic block may maintain a corresponding linked list for each AXI ID.

[0060] As mentioned above, AXI allows requests with different AXI IDs to be sent in parallel, regardless of whether these requests are strictly or loosely ordered. That is, Req5 is never blocked by Req4 because they are assigned different AXI IDs. Therefore, Req5 can be transmitted to the NoC without first waiting for a response to segment 2. Furthermore, the write tracker can report receiving responses to Req4 and Req5 in any order, as they are assigned different AXI IDs (and stored in different linked lists). In other words, if the write tracker receives a response to Req5 before a response to segment 2 for Req4, the write tracker can proceed and report Req5 completion to the entity that submitted it, without first waiting to report Req4 completion, which conforms to AXI.

[0061] Figure 5M The status of writing to the tracker is shown after Req6 is received as a strict order request. Req6 is not blocked and can be transmitted immediately.

[0062] Figure 5N The diagram shows the state of the write to the tracker after receiving the loosely ordered request Req7. Req7 consists of two segments and is not blocked. Therefore, it can be sent immediately and added to linked list 150.

[0063] Figure 5O This shows the state after the strict order request Req8 is received and written to the tracker. Additionally, Req8 has the block_en bit ( Figure 5O (Not shown in the image), which performs blocking between a previous loose-order request and a new strict-order request. Therefore, even though Req8 would otherwise be unblocked, the block_en bit indicates that the entry logic block blocking block Req8 is being transferred. That is, since Req7 is a previously received loose-order request, the write tracker blocks Req8. Therefore, Req8 will not be added to linked list 150.

[0064] Figure 5PThis shows the state of the write tracker after Req6 and Req7 are completed. That is, the write tracker has received responses from the destinations of both segments of Req7 and has removed Req7 from linked list 150. Since there are no previously received loose-order requests in linked list 150, Req8 is unblocked and can therefore be transmitted to its destination.

[0065] In addition to the techniques described in the claims, the disclosed technology may also be expressed by the following non-limiting examples.

[0066] 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 entry logic block coupled to the first hardware entity; and an exit logic block coupled to the second hardware entity, wherein the entry logic block includes a write tracker configured to: receive from the first hardware entity a first request to write data to the second hardware entity; and determine whether the first request is a loosely ordered request or a strictly ordered request, wherein a loosely ordered request can be executed in parallel with a subsequently received response, while a strictly ordered request cannot be executed in parallel with a subsequently received response having a different destination than the first request.

[0067] Example 2. An integrated circuit according to Example 1, wherein the write tracker is configured to: determine that a first request is not blocked by a previous request received at the entry logic block, wherein the previous request is a loosely ordered request.

[0068] Example 3. The integrated circuit according to Example 2, wherein the write tracker is configured to add a second entry to the tail of the linked list corresponding to the first request when it is determined that the first request is not blocked, wherein the linked list includes the first entry corresponding to the previous request.

[0069] Example 4. An integrated circuit according to Example 2, wherein the write tracker is configured to transmit a first request to a second hardware entity without waiting for a response from the destination of the previously requested request.

[0070] Example 5. An integrated circuit according to Example 1, wherein the write tracker is configured to: determine that a first request is blocked by a previous request received at the entry logic block, wherein the previous request is a strictly ordered request.

[0071] Example 6. The integrated circuit according to Example 5, wherein the write tracker is configured to: add a temporary entry corresponding to the first request when it is determined that the first request is blocked; receive a destination response from the previous request; and unblock the first request and add the entry corresponding to the first request to a linked list.

[0072] Example 7. An integrated circuit according to 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.

[0073] Example 8. An integrated circuit according to Example 1, wherein the write tracker is configured to: receive a response from the exit logic block after the exit logic block receives a first request; and determine whether the entry corresponding to the first request is at the head of a linked list, wherein the linked list tracks pending write requests being processed by the write tracker.

[0074] Example 9. An integrated circuit according to Example 8, wherein the write tracker is configured to: wait until all previous responses represented in the linked list have been reported when it is determined that the entry corresponding to the first request is not at the head of the linked list; and report the completion of the first request to a first hardware entity after determining that the first request is at the head of the linked list, so as to be compatible with the Advanced Extensible Interface (AXI) response order.

[0075] Example 10. A method comprising: receiving from a first hardware entity a first request to write data to a second hardware entity, wherein the first hardware entity and the second hardware entity are communicatively coupled via NoC; and

[0076] At the entry logic block in NoC, it is determined whether the first request is a loosely ordered request or a strictly ordered request. Loosely ordered requests can be executed in parallel with subsequently received responses, while strictly ordered requests cannot be executed in parallel with subsequently received responses that have a different destination than the first request.

[0077] Example 11. The method according to Example 10 further includes: determining that the first request was not blocked by a previous request received at the entry logic block, wherein the previous request is a loosely ordered request.

[0078] Example 12. The method according to Example 11 further includes: when it is determined that the first request is not blocked, adding a second entry to the tail of the linked list corresponding to the first request, wherein the linked list includes the first entry corresponding to the previous request.

[0079] Example 13. The method according to Example 11 further includes: transmitting the first request to a second hardware entity via NoC without waiting for a response from the destination of the previously requested request.

[0080] Example 14. The method according to Example 10 further includes: determining, based on the block_en bit of blocking between a previously received loosely ordered request and a currently received strictly ordered request, that the first request is blocked by a previous request received at the entry logic block, wherein the previous request is a loosely ordered request.

[0081] Example 15. The method according to Example 14 further includes: when it is determined that the first request is blocked, adding a temporary entry corresponding to the first request; receiving a response from the destination of the previous request; and unblocking the first request and adding the entry corresponding to the first request to a linked list.

[0082] Example 16. The method described in Example 10, wherein strictly ordered requests can be executed in parallel with subsequently received responses having the same destination as the first request.

[0083] Example 17. The method according to Example 10 further includes: receiving a response from the exit logic block in the NoC after the exit logic block receives the first request; and determining whether the entry corresponding to the first request is at the head of a linked list, wherein the linked list tracks pending write requests being processed by the entry logic block.

[0084] Example 18. The method according to Example 17 further includes: when it is determined that the entry corresponding to the first request is not at the head of the list, waiting until all previous responses represented in the list have been reported; and after determining that the first request is at the head of the list, reporting the completion of the first request to the first hardware entity to be compatible with the AXI response order.

[0085] Example 19. The method according to Example 18 further includes: deleting the entry corresponding to the first request from the linked list.

[0086] Example 20. The method according to Example 10 further includes: dividing the first request into several segments to be transmitted on the NoC; and waiting until responses to all segments have been received from their respective destinations before reporting the completion of the first request to the first hardware entity.

[0087] While the foregoing is directed to specific examples, other and additional examples may be devised without departing from its basic scope, and the scope of which is determined by the following claims.

Claims

1. An integrated circuit, comprising: First hardware entity; Second hardware entity; Network on-chip (NoC) provides connectivity between the first hardware entity and the second hardware entity, the NoC comprising: The entry logic block is coupled to the first hardware entity; as well as An exit logic block, coupled to the second hardware entity, wherein the entry logic block includes a 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 a loosely ordered request or a strictly ordered request, wherein the loosely ordered request can be executed in parallel with subsequently received requests, while the strictly ordered request cannot be executed in parallel with subsequently received strictly ordered requests having a different destination than the first request.

2. The integrated circuit of claim 1, wherein the write tracker is configured to: It is determined that the first request was not blocked by a previous request received at the entry logic block, wherein the previous request was a loosely ordered request.

3. The integrated circuit of claim 2, wherein the write tracker is configured to: When it is determined that the first request is not blocked, a second entry is added to the tail of the linked list corresponding to the first request, wherein the linked list includes the first entry corresponding to the previous request.

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

5. The integrated circuit of claim 1, wherein the write tracker is configured to: It is determined that the first request was blocked by a previous request received at the entry logic block, wherein the previous request was a strictly ordered request.

6. The integrated circuit of claim 5, wherein the write tracker is configured to: When it is determined that the first request is blocked, a temporary entry corresponding to the first request is added; Receive a response from the previously requested destination; as well as Unblock the first request and add the entry corresponding to the first request to the linked list.

7. The integrated circuit of claim 1, wherein the strictly ordered request is capable of being executed in parallel with a subsequently received response having the same destination as the first request.

8. The integrated circuit of claim 1, wherein the write tracker is configured to: After the egress logic block receives the first request, a response is received from the egress logic block; and Determine whether the entry corresponding to the first request is at the head of a linked list, wherein the linked list tracks pending write requests being processed by the write tracker.

9. The integrated circuit of claim 8, wherein the write tracker is configured to: Upon determining that the entry corresponding to the first request is not at the head of the linked list, wait until all previous responses represented in the linked list have been reported; and After determining the head of the linked list, the first hardware entity is notified that the first request is complete in order to be compatible with the AXI Advanced Extensible Interface response order.

10. A method comprising: Receive a first request from a first hardware entity to write data to a second hardware entity, wherein the first hardware entity and the second hardware entity are communicatively coupled via NoC. as well as At the entry logic block in the NoC, it is determined whether the first request is a loosely ordered request or a strictly ordered request, wherein the loosely ordered request can be executed in parallel with subsequently received requests, while the strictly ordered request cannot be executed in parallel with subsequently received strictly ordered requests that have a different destination than the first request.

11. The method of claim 10, further comprising: It is determined that the first request was not blocked by a previous request received at the entry logic block, wherein the previous request was a loosely ordered request.

12. The method of claim 10, further comprising: Based on the block_en bit that performs blocking between a previously received loosely ordered request and a currently received strictly ordered request, it is determined that the first request was blocked by a previous request received at the entry logic block, wherein the previous request was a loosely ordered request.

13. The method of claim 10, wherein the strictly ordered request is capable of being executed in parallel with a subsequently received strictly ordered request having the same destination as the first request.

14. The method of claim 10, further comprising: After the export logic block receives the first request, it receives a response from the export logic block in the NoC; as well as Determine whether the entry corresponding to the first request is at the head of a linked list, wherein the linked list tracks pending write requests being processed by the entry logic block.

15. The method of claim 10, further comprising: The first request is divided into several segments to be transmitted on the NoC; as well as Before reporting the completion of the first request to the first hardware entity, wait until responses for all said segments have been received from their respective destinations.

Images