Method for maintaining cache coherence during reordering

Abstract

Disclosed are systems, devices, and methods for performing efficient data transfer in a computing system. The computing system includes a client and multiple fabric interfaces in a fabric. A packet transmitter in the fabric interface includes multiple queues, each for storing packets of a corresponding type, and a corresponding address history cache for each queue. A queue arbiter in the packet transmitter selects candidate packets to be published and determines when the address history caches on both sides of a link store the upper portion of the address. The packet transmitter sends a source identifier and pointer of the request in a packet on the link, rather than the entire request address, which reduces the size of the packet. The queue arbiter supports out-of-order publishing from the queue. The queue arbiter detects conflicts with out-of-order publishing and adjusts outbound packets and fields stored in queue entries to avoid data corruption.

Description

Background Art

[0001] Description of Related Technology

[0002] In computing systems, some types of applications perform functions that are better able to take advantage of parallel processing and shared memory than others. Examples of such applications include machine learning applications, entertainment and real-time applications, and some business, scientific, medical, and other applications. While some processor architectures include more than one processing unit (e.g., CPU, GPU, etc.) or processing core, in some cases, additional processing units coupled to memory do not provide the desired performance level.

[0003] Generally speaking, a computing system transmits communication messages through a communication fabric (or "fabric"). Examples of communication messages include consistency detection, interruption, and read and write access commands and corresponding data. Examples of interconnections in a fabric include bus architecture, crossbar-based architecture, network-on-chip (NoC) communication subsystem, communication channels between dies, silicon interposers, and through-silicon vias (TSVs). In many cases, the fabric has multiple physical channels, each of which supports relatively wide packets. When transmitting data within a single fabric, a large number of available physical lines can be used to reduce the latency through the fabric. In this way, the bandwidth through the fabric may be relatively large overall. However, when connecting separate dies together through a fabric, a smaller number of available physical lines on the separate dies are typically used to transmit data. Similarly, when connecting separate processing nodes together (each using a corresponding fabric), a smaller number of available physical lines between processing nodes limits bandwidth. Therefore, at the fabric boundaries in such computing systems, data transmission efficiency is typically reduced.

[0004] In view of the above, efficient methods and systems for performing efficient data transfers in computing systems are desired. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Advantages of the methods and mechanisms described herein may be better understood by referring to the following description in conjunction with the accompanying drawings, in which:

[0006] Figure 1 is a block diagram of one embodiment of a computing system.

[0007] Figure 2 is a block diagram of one embodiment of a packet transmitter.

[0008] Figure 3 is a block diagram of one implementation of a request queue.

[0009] Figure 4 is a block diagram of one embodiment of a packet transmitter.

[0010] Figure 5 is a flow chart of another embodiment of a method for performing efficient data transfer in a computing system.

[0011] Figure 6 is a flow chart of another embodiment of a method for performing efficient data transfer in a computing system.

[0012] Figure 7 is a flow chart of another embodiment of a method for performing efficient data transfer in a computing system.

[0013] Figure 8 is a flow chart of another embodiment of a method for performing efficient data transfer in a computing system.

[0014] Figure 9 is a block diagram of one embodiment of a packet receiver.

[0015] Figure 10 is a flow chart of another embodiment of a method for performing efficient data transfer in a computing system.

[0016] While the invention is susceptible to various modifications and alternative forms, specific embodiments are shown by way of example in the drawings and are herein described in detail. However, it should be understood that the drawings and detailed description thereof are not intended to limit the invention to the particular forms disclosed, but on the contrary, the invention is to cover all modifications, equivalents, and alternatives falling within the scope of the invention as defined by the appended claims. DETAILED DESCRIPTION

[0017] In the following description, numerous specific details are set forth to provide a thorough understanding of the methods and mechanisms presented herein. However, one of ordinary skill in the art will recognize that various embodiments may be practiced without these specific details. In some cases, well-known structures, components, signals, computer program instructions, and techniques are not shown in detail to avoid obscuring the methods described herein. It will be understood that for simplicity and clarity of illustration, the elements shown in the drawings may not be drawn to scale. For example, the dimensions of some elements may be enlarged relative to other elements.

[0018] Various systems, devices, methods, and computer-readable media for performing efficient data transfer in a computing system are disclosed. One or more clients in the computing system process application programs. Examples of such clients include general-purpose central processing units (CPUs), graphics processing units (GPUs), accelerated processing units (APUs), input / output (I / O) devices, and the like. The computing system also includes at least a power controller and multiple link interfaces for transmitting data between the clients. In addition, each of the one or more clients and the communication fabric between the clients includes a fabric interface with a packet transmitter and a packet receiver. In various embodiments, the packet transmitter includes multiple request queues for storing requests of different packet types. Each of the multiple request queues in the packet transmitter stores requests of a corresponding packet type. Examples of packet types include request type, response type, probe type, control type, and token or credit type. In various embodiments, the packet transmitter divides a write request into a write command and write data. The packet transmitter inserts the write command into a command or control packet and inserts the write data into a separate write data packet corresponding to the write command. Similarly, the packet transmitter divides a read response into a read message and read response data. The packet transmitter inserts the read message into a command or control packet and inserts the read response data into a separate data packet. For read requests that do not include response data, the packet transmitter does not perform the splitting step. Instead, the packet transmitter inserts the read request as a read command into the command or control packet.

[0019] In some cases, two or more of the multiple request queues store packets of different sizes in the packet transmitter. In addition, the packet transmitter and the packet receiver include one or more address history caches corresponding to the one or more request queues. The address history cache stores at least a portion of the request address. Since the request streams from different physical devices may have address locality, the address history cache stores the upper portion of the address on both sides of the link. Address locality is also called "spatial locality" and refers to multiple memory access requests that are relatively close to each other. For example, in some cases, the request addresses are consecutive (e.g., each of the consecutive memory access requests accesses a cache line, byte, etc. that is adjacent to the immediately previous accessed cache line). In other instances, the access pattern has a specific constant offset such that the request address is incremented by a fixed amount between each memory access request. In still other instances, each request address has an increased offset compared to the immediately previous request address.

[0020] A packet transmitter determines when to store a particular address in its local address history cache. The packet transmitter also stores in an associated request packet an indication (or "identifier") identifying a storage location where the packet receiver will store at least a portion of the particular address. In some embodiments, for subsequent requests within the same address range as the particular address, the packet transmitter sends packets without at least a portion of the address corresponding to these subsequent requests. Instead of including the omitted portion of the address, the packet transmitter sends an identifier of the storage location. Avoiding including portions of the address in the packet reduces the amount of data in the packet. Thus, the packet is compressed in size compared to a packet that stores the entire request address. In some embodiments, each of the packet transmitter and the packet receiver uses the same storage location identifier for their respective address history caches. The packet receiver uses the received storage location identifier to determine the entire request address and uses the request address to service the received request.

[0021] The packet transmitter also includes a plurality of queue arbiters, each of which is configured to select a candidate packet from a corresponding request queue in the plurality of request queues. Furthermore, the packet transmitter includes a buffer for storing the link packet. The link packet includes data storage space for storing a plurality of candidate packets. When the candidate packets are compressed using a storage location identifier in the address history cache rather than the entire request address, the link packet is able to store more candidate packets. Consequently, more candidate packets can be transmitted at once, and link utilization becomes more efficient.

[0022] Each of the queue arbiters selects requests from a corresponding request queue, and the packet arbiter selects candidate packets based on one or more attributes and inserts them into the link buffer. Examples of such attributes include age, priority level of packet type, quality of service parameters, source identifier, application identifier or type (e.g., such as real-time application), indication of traffic type (e.g., such as real-time traffic), bandwidth requirement or delay tolerance requirement, virtual channel identifier, etc. In some cases, the queue arbiter selects requests from the request queue for out-of-order posting.

[0023] In various embodiments, when logic de-allocates an entry or otherwise invalidates an entry out of order, arbitration logic updates a field stored in an entry in a request queue. In one instance, arbitration logic selects a later, second request that precedes an earlier, first request in a particular request queue. The request queue entry for the earlier, first request stores an indication for storing a portion of an address at a receiver. The later, second request relies on at least a portion of the address to be stored at the receiver by the first request. Data corruption occurs when the second request bypasses the first request during out-of-order issuance and at least a portion of the address is not available at the receiver. In various embodiments, arbitration logic determines when this occurs and changes the later, second request from a compressed format to an uncompressed format. The compressed format stores an identification of the storage location in an address history cache, which in turn stores a portion of the address, while the uncompressed format stores a portion of the address. Thus, arbitration logic detects when an out-of-order conflict exists during issuance and adjusts outbound packets to avoid data corruption.

[0024] refer to Figure 1 , a generalized block diagram of an embodiment of a computing system 100 is shown. As shown, the computing system 100 includes a communication structure 120 between each of a client 110, a memory controller 130, a power controller 170, and a link interface 180. In some embodiments, the components of the computing system 100 are separate dies on an integrated circuit (IC), such as a system on a chip (SOC). In other embodiments, the components are separate dies in a system-in-package (SiP) or a multi-chip module (MCM). As shown, the client 110 includes a central processing unit (CPU) 112, a graphics processing unit (GPU) 114, a hub 116, and a multimedia engine 118. The CPU 112, the GPU 114, and the multimedia engine 118 are examples of computing resources capable of processing application programs. Although not shown, in other embodiments, other types of computing resources are included in the client 110.

[0025] In general, the CPU 112 includes one or more processor cores for executing instructions according to a given instruction set architecture (ISA). One or more of the processor cores uses a superscalar and multi-threaded micro-architecture to process instructions. The GPU 114 uses a parallel data micro-architecture (e.g., single instruction multiple data or "SIMD") that includes multiple parallel execution channels. The multimedia engine 118 includes a processor for processing audio data and video data for multimedia applications. The hub 116 includes interface logic for communicating between the multimedia engine 118 and external components (such as video ports, audio ports, etc.). In addition, the hub 116 includes interface logic for communicating between the multimedia engine 118 and multiple local computing resources in the computing system 100.

[0026] Power controller 170 collects data (such as predetermined sampling signals) from client 110 during a given sampling interval. On-die current sensors and temperature sensors (not shown) also send information to power controller 170. Power controller 170 selects a corresponding power-performance state (P-state) for at least one or more of the computing resources in client 110 and memory controller 130. The P-state includes at least an operating voltage and an operating clock frequency.

[0027] Although a single memory controller 130 is shown, in other embodiments, the computing system 100 uses another number of memory controllers. The memory controller 130 receives memory requests from the client 110 via the fabric 120, schedules the memory requests, and sends the scheduled memory requests to one or more of the system memory and the main memory. The memory controller 130 also receives responses from the system memory and the main memory and sends the responses to the corresponding sources of the requests in the client 110. The system memory fills the system memory with data via the I / O controller and bus 160 and the memory bus 150. The main memory sends a cache fill line with the requested block to the corresponding cache memory subsystem in the cache memory subsystem in the client 110 to complete the original memory request. The corresponding cache memory subsystem in the cache memory subsystem in the client 110 places the cache fill line in one or more levels of cache.

[0028] The address space of computing system 100 is divided between at least CPU 112, GPU 114, and multimedia engine 118, as well as one or more other components, such as input / output (I / O) peripherals (not shown), and other types of computing resources. A memory map is maintained to determine which addresses are mapped to which component, and therefore to which of CPU 112, GPU 114, and multimedia engine 118 a memory request for a particular address should be routed. System memory is one of several types of dynamic random access memory (DRAM), and memory controller 130 supports a corresponding protocol. The protocol determines the values ​​used for information transfer, such as the number of data transfers per clock cycle, signal voltage levels, signal timing, signal and clock phases, and clock frequency. Main memory is one of several types of non-volatile, random access secondary data storage devices. Examples of main memory are hard disk drives (HDDs) and solid-state drives (SSDs).

[0029] Communications fabric 120 (or fabric 120) carries traffic back and forth between client 110 and memory controller 130 and includes interfaces for supporting the corresponding communication protocols. "Traffic" includes data such as commands, messages, probes, interrupts, and data corresponding to commands and messages. Fabric 120 includes queues for storing requests and responses. Fabric 120 also includes selection logic for arbitrating between received requests before sending them across the internal network. Additional logic in fabric 120 constructs and decodes packets and selects routes for packets.

[0030] Fabric transmission interface (FTI) 180 supports the communication between computing system 100 and other computing systems or processing nodes by transmitting business on the link. The business sent across the link includes the indication of the operating state of one or more processing nodes, power-down request, response to the request, interruption and other information. As shown in the figure, client 110 includes FTI 113 for CPU 112, FTI 115 for GPU 114 and FTI 117 for hub 116. In addition, memory controller 130 includes FTI 132, and power controller 170 includes FTI 172. Each of fabric transmission interfaces 113, 115, 117, 132, 172 and 180 includes a packet transmitter and a packet receiver. Fabric 120 includes multiple fabric transmission interfaces not shown for ease of explanation. In some embodiments, each link connected to the fabric transmission interface is a point-to-point communication channel. In other embodiments, one or more links connected to the fabric transmission interface are end-to-end communication channels.

[0031] The fabric transport interface includes control logic and buffers or queues for communication. At the physical layer, a link includes one or more channels. The fabric transport interface and the corresponding link include communication protocol connections such as PCIe (Peripheral Component Interconnect Express), InfiniBand, RapidIO, HyperTransport, Advanced eXtensible Interface (AXI), etc. Each of the fabric transport interfaces 113, 115, 117, 132, 172, and 180 includes multiple request queues, each request queue being used to store requests of a corresponding type. In addition, each of the fabric transport interfaces 113, 115, 117, 132, 172, and 180 includes one or more address history caches corresponding to the one or more request queues. The address history cache stores at least a portion of the request address. Because request streams from different physical devices have address locality, the address history cache stores the upper portion of the request address on both sides of the link.

[0032] Each of fabric transmission interfaces 113, 115, 117, 132, 172, and 180 includes control logic for various purposes. For example, when a request is received and an entry in a request queue is allocated, the control logic accesses an address history cache to determine whether the address history cache already stores a portion of the request address. During the allocation of an entry in a request queue, the control logic updates a field in the queue entry to indicate whether the outbound packet uses the identifier of the storage location in the address history cache or the request address. Additionally, the packet transmitter includes a plurality of queue arbiters, each of which is configured to select a request from a corresponding request queue in the plurality of request queues. The queue arbiters select requests from the request queues for out-of-order issuance. The queue arbiters determine when an out-of-order conflict exists and adjust fields stored in the outbound packet and the queue entry to avoid data corruption.

[0033] In one example, a queue arbiter bypasses an earlier first request in a request queue by selecting a later second request for issuance. The queue entry for the first request stores an indication to store a portion of the request address at the receiver. Therefore, this portion of the request address is not yet stored at the receiver. The queue entry for the second request stores an indication to retrieve a portion of the request address from a remote address history cache at the receiver. This queue entry for the second request also stores an identification of a storage location in the remote address history cache at the receiver. The queue arbiter determines when this occurs and changes the later second request from a compressed format using the identification of the storage location to an uncompressed format using the portion of the request address. By changing the second request from the expected compressed format to an uncompressed format, the queue arbiter in the transmitter avoids data corruption at the receiver.

[0034] One or more of the fabric transmission interfaces 113, 115, 117, 132, 172, and 180 in the computing system 100 also include a buffer for storing link packets, the buffer including data storage space for storing multiple candidate packets. In some embodiments, two or more of the multiple request queues store candidate packets of different sizes. A packet arbiter in the fabric transmission interface selects qualified candidate packets from the multiple request queues and inserts these candidate packets into the link packet. When the candidate packet is a compressed packet that stores an identifier of a storage location in a remote address history cache at the receiver, the packet arbiter can insert more candidate packets into the link packet. The packet arbiter also determines whether the link packet has remaining available data storage space aligned on a given boundary for a given candidate packet. The packet receiver in the fabric transmission interface includes a receive queue for receiving link packets sent by the packet transmitter.

[0035] refer to Figure 2, shows a generalized block diagram of one embodiment of a packet transmitter 200. Packet transmitter 200 includes a request queue 230 and a corresponding address history cache 220. Although packet transmitter 200 includes a single request queue and a single corresponding address history cache, in other embodiments, packet transmitter 200 uses another number of these components. Packet transmitter 200 receives a request 210 from an on-chip network or fabric to send to an outbound off-chip link. Request 210 includes at least a source identifier (ID) and an address 216. As shown, the source identifier includes a processor identifier (PID) 212 and a thread identifier (TID) 214. In other embodiments, the source identifier additionally includes one or more of a process ID and an application ID. Other information (not shown) in request 210 includes a request type indicating whether request 210 is a read operation or a write operation.

[0036] Control logic, not shown for ease of illustration, uses the source identifier to index into address history cache 220. In some designs, address history cache 220 is a direct-mapped cache. In other designs, address history cache 220 has any set associativity. When used as an index, the source identifier identifies a specific set in address history cache 220. Control logic uses a portion of address 216 as a tag to determine whether any of the channels in the identified set generated a cache hit. Because request streams from different physical devices have address locality, address history cache 220 stores the portion of address 216 used for the request. In one example, address history cache 220 stores the upper portion of address 216. Therefore, as used herein, a "channel" of address history cache 220 is also referred to as a "stream." If a lookup of address history cache 220 generates a cache hit, the control logic for address history cache 220 sends the channel identifier (ID) of the specific channel that generated the hit to the control logic for request queue 230. In the embodiment shown, the queue update 222 sent from the address history cache 220 to the request queue 230 includes at least the channel ID.

[0037] If the lookup of the address history cache 220 generates a cache miss, the control logic for the address history cache 220 selects a specific way within the group. In some cases, the control logic uses a least recently used (LRU) scheme to select the specific way within the group. In other cases, the control logic uses any of a variety of other schemes to select the specific way within the group. The control logic then stores at least a portion of the address 216 (such as the upper portion) in the specific way within the selected group of the address history cache 220. As shown, the queue update 222 sent from the address history cache 220 to the request queue 230 includes at least an indication of the cache hit / miss result. As shown, the queue update 222 also includes the channel ID of the channel where at least a portion of the address 216 is currently stored.

[0038] Request queue 230 includes multiple entries 232a-232g for storing information. In various embodiments, each of entries 232a-232g stores at least fields 240-254. Fields 240 and 242 store source identifier information such as processor ID and thread ID. In other embodiments, the source identifier also includes other information such as process ID and application ID. As shown in the figure, field 244 stores virtual channel ID. Request streams from multiple different physical devices flow through the virtual channel (VC) on the same physical link. Arbitration logic uses at least the priority level of the virtual channel and the stored virtual channel ID in entries 232a-232g when selecting the request to be issued.

[0039] Field 246 stores at least a portion of address 216. Field 248 stores an indication of a cache load. For example, if a lookup of address history cache 220 results in a cache miss and at least a portion of received address 216 is stored or loaded in address history cache 220, field 248 stores a predicate value. In one example, the predicate value is a binary '1', which indicates that a cache load occurred for received request 210. In another example, a binary '0' is used to indicate a predicate value. Field 250 stores an indication that an earlier search of address history cache 220 found the address corresponding to received request 210. In other words, cache hit field 250 stores an indication of whether a cache hit occurred during an earlier lookup of address history cache 220 for received request 210. If the lookup of address history cache 220 results in a cache hit, field 250 stores the predicate value.

[0040] Field 252 stores an indication of the channel within the selected group in address history cache 220 that currently stores at least a portion of received address 216. If a cache hit occurs, the specific channel identified by field 252 already stores at least a portion of received address 216. However, if a cache miss occurs, an alternative approach selects the specific channel identified by field 252, and this specific channel loads at least a portion of received address 216 into it after the cache miss. Other fields included in entries 232a-232g, but not shown, include a status field that indicates whether the entry stores information for the assigned entry. This indication includes a valid bit. Another field stores an indication of the request type. In some embodiments, when the entry position does not indicate an age, an additional field stores the age.

[0041] In some embodiments, when the queue arbiter 260 selects an entry storing a predicated value in field 250, the packet transmitter 200 transmits the FTI candidate packet 270 as a compressed packet. For example, the packet transmitter 200 transmits the source identifier and channel ID in the outbound compressed packet, rather than the entire request address. At the receiver, the control logic uses the source identifier and channel ID (such as fields 240-242 and field 252) to access the address history cache at the receiver. Similar to the local address history cache 220 in the packet transmitter 200, this remote address history cache at the receiver stores at least a portion of the request address. Therefore, when sending an outbound compressed packet across a link, the packet transmitter 200 does not transmit at least a portion of the request address across the link to the receiver.

[0042] In some embodiments, the control logic allocates entries 232a-232g in the request queue 230 in an ordered manner, so that the entry position of entries 232a-232g indicates age. If the control logic allocates entries 232a-232g in the request queue 230 out of order, then entries 232a-232g store an additional age field. In various embodiments, the control logic cancels entries 232a-232g in the request queue 230 out of order. As previously described, request streams from multiple different physical devices flow through virtual channels (VCs) on the same physical link. Sometimes, a client sends requests from different VCs on an outbound link in an order different from the order in which the requests were received by the packet transmitter 200. For example, the queue arbiter 260 selects one of the entries 232a-232g based on one or more attributes to be used in creating the FTI candidate packet 270. Examples of the one or more attributes are a priority level of the request type, a quality of service parameter, a source identifier, an application identifier or type (such as a real-time application), an indication of a traffic type (such as a real-time traffic), a bandwidth requirement or a latency tolerance requirement, a virtual channel identifier, etc. A different ordering may avoid system-level deadlocks.

[0043] Field 254 stores an indication of a cache load match. A cache load match for the second request indicates a first request in request queue 230 from the same source as the one storing the asserted value of cache load field 248, which is earlier than the second request. Therefore, this earlier first request should load at least a portion of its address into the remote address history cache at the receiver. In other words, cache load match field 254 specifies whether request queue 230 has a valid second entry for the first request, which will store the address corresponding to the later second request at the receiver. Each of the first and second requests originates from the same source. In other words, the entries in request queue 230 for each of the first and second requests store the same value in fields 240, 242, and 252. When the control logic determines that the first request is the latest request among the requests that are earlier than the second request stored in request queue 230, cache load match field 254 stores an asserted value specifying an indication of the address to be stored at the receiver. Therefore, the second request is dependent on the earlier first request because the earlier first request should store at least a portion of the request address at the receiver. The control logic sends the later second request as a compressed packet when at least a portion of the request address is stored at the receiver.

[0044] When queue arbiter 260 deallocates an entry out of order, queue arbiter 260 or other control logic updates one or more of fields 240-254 stored in entries 232a-232g of request queue 230. In one example, queue arbiter 260 selects a later second request for deallocation, bypassing an earlier first request in request queue 230. The entry in request queue 230 storing the earlier first request includes an indication that a portion of the address is stored at the receiver. The later second request relies on a portion of the address already stored at the receiver. Queue arbiter 260 determines when this occurs and changes the later second request from a compressed format to an uncompressed format. The compressed format stores an identifier of the storage location, such as the values ​​stored in at least fields 240, 242, and 252. The uncompressed format stores a portion of the address, such as the value stored in field 246. By detecting this situation caused by out-of-order posting from request queue 230, queue arbiter 260 avoids data corruption at the receiver.

[0045] refer to Figure 3, a generalized block diagram of one embodiment of a request queue 300 is shown. The circuits and logic previously described are numbered in the same manner. As shown, the request queue 300 includes a queue 310 and control logic 320. The request queue 310 stores information in entries having at least fields 240-254. The entries in the queue 310 store other fields not shown, such as a status field. The status field stores an indication of whether the entry is allocated. In one example, this indication includes a valid bit. Another field stores an indication of the request type. In some embodiments, the request queue 300 also includes a table 330 that tracks a specific entry having a cache load field 248 storing a predicate value, and a corresponding number of allocated entries in the queue 310 having a cache hit field 250 storing a predicate value, the allocated entries depending on the specific entry. For example, the first entry in the table 330 stores an indication of entry 8. Entry 8 of the queue 310 stores the predicate value in the cache load field 248. Furthermore, this first entry of table 330 stores a count of one for a number of allocated entries in queue 310 having a predicated cache hit field 250 corresponding to entry 8. Here, the count of one refers to entry 7.

[0046] When control logic 320 does not use entry position to indicate age, an additional field (not shown) in the entries of queue 310 stores age. As shown, control logic 320 allocates queue 310 in an ordered manner by age, storing later requests at the top of queue 310 and older requests at the bottom of queue 310. In other embodiments, control logic 320 stores requests in queue 310 in reverse age order. Each of entries 7-8, 15, 20, 32, and 43-44 of queue 310 stores information from the same source (e.g., processor with ID 2, thread with ID 6, and channel with ID 3). The request stored in entry 44 is the oldest request in this group, while the request stored in entry 7 is the latest request in this group.

[0047] The requests allocated in entries 8, 32, and 44 store a predicated value in cache load field 248. As previously described, in some cases, a binary value of '1' indicates a predicated value. Therefore, during a lookup of the local address history cache at the transmitter, the requests corresponding to entries 8, 32, and 44 generate a cache miss, and their corresponding addresses, or portions of their addresses, are loaded into the local address history cache at the transmitter. The request allocated in entry 44 has its request address 0x670 loaded into the local address history cache at the transmitter due to a cache miss. Here, the designation "0x" refers to a hexadecimal number format. The request allocated in entry 32 has its request address 0x100 loaded into the local address history cache at the transmitter due to a cache miss. The request allocated in entry 8 has its request address 0x330 loaded into the local address history cache at the transmitter due to a cache miss.

[0048] Each of the requests allocated in entries 7, 15, 20, and 43 stores a predicated value in cache hit field 250. Thus, the corresponding request generates a cache hit during a lookup of the local address history cache at the transmitter. If the external publishing logic does not insert its corresponding address, or a portion of its address, into the corresponding packet, these packets are compressed packets and improve the efficiency of the link. For compressed packets, the receiver uses fields 240-242 and 252 to access the remote address history cache at the receiver to retrieve the request address previously stored at the receiver.

[0049] As shown, only the request allocated in entry 44 stores a clear (negated) value in field 254 (the cache load match field). As previously described, the cache load match for the second request indicates that an earlier first request from the same source in queue 310 stores a predicated value for cache load field 248. Therefore, immediately after control logic 320 sends this earlier first request to the receiver, this earlier first request should load at least a portion of its address into each of the local address history cache at the transmitter and the remote address history cache at the receiver. In the example shown, only the request allocated in entry 44 does not have an earlier request from the same source that also stores its request address in at least the local address history cache at the transmitter.

[0050] As previously mentioned, in some embodiments, control logic 320 de-allocates entries in queue 310 in an out-of-order manner. In some cases, control logic 320 selects entries in queue 310 for de-allocation in an out-of-order manner, but the actual de-allocation occurs at a later point in time. In some designs, arbitration logic is included in control logic 320, but in other designs, arbitration logic is located separately from control logic 320. Below queue 310, four cases are shown for de-allocating (invalidating) entries in queue 310 when a request is issued.

[0051] Case 1: Entry 20 is selected for publication before entry 32

[0052] For case 1, the control logic 320 selects the later request allocated in entry 20 to be de-allocated before the earlier request allocated in entry 32. In this case, the control logic 320 sends the resulting packet for the later request allocated in entry 20 as an uncompressed packet instead of the expected compressed packet. The control logic 320 sends the request address (e.g., 0x100) in the address field 246 in the uncompressed packet because the receiver does not yet have the request address from the earlier request allocated in entry 32.

[0053] In the illustrated embodiment, the asserted value in cache load match field 254 indicates that control logic 320 should convert the selected later request assigned to entry 20 from the intended compressed packet to an uncompressed packet. Similar to the requests assigned to entries 20 and 32, case 1 also occurs for the requests assigned to entries 15 and 32, such as when control logic 320 selects entry 15 for issuance before entry 32. Similarly, case 1 also occurs for the requests assigned to entries 7-8, such as when control logic 320 selects entry 7 for issuance before entry 8. Similarly, case 1 also occurs for the requests assigned to entries 7-8 and 43-44, such as when control logic 320 selects entry 43 for issuance before entry 44. In other cases, control logic 320 selects the later request assigned to entry 20 after the earlier request assigned to entry 32. In these cases, a clear or negated value in field 254 indicates that the selected later request assigned to entry 20 remains as the intended compressed packet.

[0054] Case 2: Item 8 is selected for publication before items 15, 20, 32, and 43-44

[0055] For Case 2, control logic 320 selects the later request allocated in entry 8 for de-allocation before one or more of the earlier requests allocated in entries 15, 20, 32, and 43-44. In this case, control logic 320 transmits the packet generated for the later request allocated in entry 8 as an expected uncompressed packet. As previously described, the request allocated in entry 8 stores a predicated value in cache load field 248. Therefore, during a lookup of the local address history cache at the transmitter, the request generates a cache miss, and its corresponding address, or a portion of its address, is loaded into the local address history cache. Although control logic 320 creates the expected uncompressed packet for the selected request allocated in entry 8, control logic 320 performs updates for the earlier requests allocated in one or more of entries 15, 20, 32, and 43-44 that are still being allocated. Due to out-of-order issuance and storing address 0x330 at the receiver instead of address 0x100 used by the requests allocated in entries 15 and 20 and address 0x670 used by the request allocated in entry 43, control logic 320 cannot send the packets generated for these earlier requests as compressed packets. Therefore, to perform the update, control logic 320 searches for all earlier requests from the same source as the request allocated in entry 8 and updates certain fields for any requests found from this search.

[0056] As previously described, control logic 320 identifies the source using fields 240-242 and 252 (e.g., PID 2, TID 6, and Way 3). Entries storing requests from the same source as the request assigned in entry 8 include earlier requests assigned in entries 15, 20, 32, and 43-44. For the identified entries 15, 20, 32, and 43-44, control logic 320 clears each of cache load field 248 and cache hit field 250. Therefore, for the requests assigned in entries 15, 20, 32, and 43-44, the receiver does not use its remote address history cache for the corresponding received packet.

[0057] In addition to updating earlier requests stored in request queue 300 as described above, when cache load field 248 stores the predicated value in entry 8, control logic 320 also updates any requests later than the request assigned in entry 8. In the example shown, control logic 320 searches queue 310 for a later entry from the same source that has the predicated value stored in cache load field 248. No such entry exists. Therefore, control logic 320 performs a search, from oldest to youngest, between entry 8 and entry 1 to identify entries assigned to requests from the same source. In this particular case, the search locates entry 7, which stores the predicated value in cache hit field 250. Control logic 320 clears cache load match field 254 for entry 7. Therefore, at a later point in time when control logic 320 selects the request assigned in entry 7, control logic 320 creates a compressed packet. Control logic 320 creates the compressed packet because, since control logic 320 has already published the earlier entry 8, the request address, or a portion of the request address, is stored in the remote address history cache at the receiver.

[0058] Case 3: First select entry 32 for publishing

[0059] For case 3, control logic 320 selects the later request allocated in entry 32 for de-allocation before one or more of the earlier requests allocated in entries 43-44 and before one or more of the later requests allocated in entries 7-8, 15, and 20. Case 3 is similar to case 2, but there are multiple later requests from the same source, and there are later requests with asserted values ​​stored in cache load field 248. For case 3, control logic 320 transmits the packet generated for the request allocated in entry 32 as an expected uncompressed packet. As previously described, the request allocated in entry 32 stores the asserted value in cache load field 248. Therefore, during a lookup of the local address history cache at the transmitter, the request generates a cache miss, and its corresponding address, or a portion of its address, is loaded into the local address history cache.

[0060] Although control logic 320 creates the expected uncompressed packet for the selected request assigned to entry 32, control logic 320 performs updates for one or more still-assigned earlier requests assigned to entries 43-44, as well as one or more still-assigned later requests assigned to entries 7-8, 15, and 20. Control logic 320 cannot send the packet generated for the earlier request assigned to entry 43 as a compressed packet. As shown, the request assigned to entry 43 stores a predicate value in cache hit field 250. If control logic 320 sends the packet as a compressed packet, out-of-order posting and storing address 0x100 at the receiver instead of address 0x670 used by the request assigned to entry 43 would result in data corruption. To avoid data corruption, control logic 320 searches queue 310 for any earlier requests from the same source as the request assigned to entry 32. Entries storing earlier requests from the same source as the request assigned to entry 32 include the request assigned to entries 43-44. For the earlier request in the identified entry 43-44, control logic 320 clears each of cache load field 248 and cache hit field 250. Thus, for the request allocated in entry 43-44, the receiver does not use its remote address history cache for the corresponding received packet.

[0061] In addition to updating earlier requests stored in queue 310 as described above, control logic 320 also updates any requests later than the request assigned in entry 32 when cache load field 248 stores a predicated value. In the example shown, control logic 320 searches for later entries from the same source that have a predicated value stored in cache load field 248. Control logic 320 finds entry 8. Therefore, control logic 320 performs a search between entry 8 and entry 32, in order of age from oldest to youngest, to identify entries assigned to requests from the same source. In this particular case, control logic 320 finds entries 15 and 20, each of which has a predicated value stored in cache hit field 250. Control logic 320 clears field 254 for entries 15 and 20. Therefore, at a later point in time when control logic 320 selects the requests assigned in entries 15 and 20, control logic 320 creates a compressed packet. The control logic 320 creates the compressed packet because the request address or a portion of the request address is stored in the remote address history cache at the receiver due to the control logic 320 having published an earlier entry 32 .

[0062] Case 4: First select entry 44 to publish

[0063] For case 4, control logic 320 selects the request assigned to entry 44 for de-assignment before one or more of the requests assigned to entries 7-8, 15, 20, and 43. For case 4, control logic 320 transmits the packet generated for the request assigned to entry 44 as the expected uncompressed packet. As previously described, the request assigned to entry 44 stores a predicated value in cache load field 248. Therefore, during a lookup of the local address history cache at the transmitter, the request generates a cache miss, and its corresponding address, or a portion of its address, is loaded into the local address history cache. Control logic 320 of request queue 300 searches for any earlier requests from the same source as the request assigned to entry 44. As shown, for case 4, no earlier requests from the same source are assigned to queue 310. Therefore, control logic 320 does not perform any updates to clear cache load field 248 and cache hit field 250 for the earlier request.

[0064] In addition to searching for earlier requests to potentially update their fields stored in queue 310, control logic 320 also searches for any requests older than the request assigned to entry 44 when cache load field 248 stores a predicated value. In the illustrated example, control logic 320 of request queue 300 searches for later entries from the same source that have a predicated value stored in cache load field 248. Control logic 320 finds entry 32. Therefore, control logic 320 searches between entry 32 and entry 44, in order of age from oldest to youngest, to identify entries assigned to requests from the same source. In this particular case, control logic 320 finds entry 43 that has a predicated value stored in cache hit field 250. Control logic 320 clears cache load match field 254 for entry 43. Therefore, at a later point in time when control logic 320 selects the request assigned to entry 43, control logic 320 creates a compressed packet. The control logic 320 creates the compressed packet because the request address, or a portion of the request address, is stored in the remote address history cache at the receiver due to the control logic 320 having published an earlier entry 44 .

[0065] Tracking cache hits

[0066] As previously described, control logic 320 uses table 330 to track the number of allocated entries in queue 310 that have a predicated cache hit field 250 corresponding to a particular entry with a predicated cache load field 248. As shown, the first entry in table 330 stores an indication of entry 8 having a predicated cache load field 248. Furthermore, this first entry in table 330 stores a count of one for the number of allocated entries in queue 310 that have a predicated cache hit field 250 corresponding to entry 8. The count of one refers to entry 7. Similarly, the second entry in table 330 stores an indication of entry 32 having a predicated cache load field 248. Furthermore, the second entry in table 330 stores a count of two for allocated entries 15 and 20 in queue 310 that have a predicated cache hit field 250 corresponding to entry 32. The third entry stores an indication of entry 44 and a count of one corresponding to entry 43.

[0067] Referring again to Case 2 above, when control logic 320 selects entry 8 to be issued and determines that the corresponding cache load field 248 stores a predicated value, control logic 320 accesses table 330. Using the indication of entry 8 of queue 310, control logic 320 searches table 330, finds the first entry, and determines that a request is currently dispatched in queue 310 that is dependent on the request in entry 8. In this case, a count of one corresponds to entry 7. In some embodiments, when control logic 320 determines that at least one other dispatched entry in table 330 stores a higher count (such as the second entry with a count of two), control logic 320 does not perform the previous step of searching for other requests. Instead, control logic 320 sends the intended uncompressed packet for entry 8 and does not update the fields of the other entries. Furthermore, control logic 320 invalidates the storage location in the address history cache that stores at least a portion of the request address of the request dispatched in entry 8. For example, control logic 320 invalidates cache way 3 in the group indexed by processor identifier 2 and thread identifier 6. Therefore, later requests from the same source with the same portion of the request address do not hit in the address history cache.

[0068] The asserted value stored in field 254 of entry 7 of queue 310 ensures that the packet issued later for entry 7 is an uncompressed packet. In other embodiments, when control logic 320 determines that at least one other allocated entry in table 330 stores a higher count, control logic 320 searches for a later request (such as entry 7) and clears or negates cache hit field 250. The uncompressed packet for entry 8 does not include an indication of an asserted cache load field, so there is no load of at least a portion of the request address (e.g., address 0x330) at the receiver. Therefore, if control logic 320 selects entry 32 immediately after entry 8, control logic 320 can still send both packets of entries 15 and 20 as compressed packets at a later point in time. When control logic 320 issues entry 8 of queue 310, control logic 320 does not clear cache hit field 250 for both packets of entries 15 and 20.

[0069] In some embodiments, control logic 320 uses a threshold to determine whether one entry in table 330 has a higher count than another entry. In the above example, control logic 320 uses a threshold of zero. In other embodiments, control logic 320 uses a positive, non-zero integer as the threshold. For example, if the threshold is three, control logic 320 considers the fifth entry (not shown) in table 330 with a count of 7 to be higher than the ninth entry (not shown) with a count of 3 because 7 is greater than 6 (count 3 + threshold 3). However, control logic 320 does not consider the fifth entry with a count of 7 to be higher than the other entries with a count of at least 4 because 7 is not considered to be greater than 7 (count 4 + threshold 3).

[0070] In some embodiments, when control logic 320 assigns a request with the predicated cache load field 248 in queue 310, control logic 320 assigns a given entry in table 330. When a request with the predicated cache hit field 250 has the same request address as the request corresponding to the given entry, control logic 320 updates (increments) the corresponding count in the given entry in table 330. For example, when control logic 320 assigns entry 20 in queue 310, the second entry in table 330 storing a reference to entry 32 in queue 310 increments its count to one. When control logic 320 assigns entry 15 in queue 310, this count increments from one to two. Furthermore, when control logic 320 publishes a corresponding compressed packet, control logic 320 updates (decrements) the corresponding count. For example, when external arbitration logic selects entry 15 for publication and sends a compressed outbound packet for entry 15 across the link, control logic 320 decrements the count in the second entry of table 330 from two to one.

[0071] In some embodiments, a given entry in table 330 is de-allocated when control logic 320 issues a request for the indicated entry of queue 310 without updating the fields of other entries in queue 310 due to a higher count condition. In some embodiments, a given entry in table 330 is de-allocated when control logic 320 allocates the predicated cache load field 248 in queue 310 to a later request and the count reaches zero for the given entry. In this case, there are no more compressed packets to issue, so the control logic de-allocates or invalidates the given entry.

[0072] refer to Figure 4 , a generalized block diagram of one embodiment of a packet transmitter 400 is shown. Packet transmitter 400 includes request queues 411, 413, and 415, each for storing requests of a corresponding type. Each of request queues 411, 413, and 415 has a corresponding local address history cache 410, 412, and 414. Local address history caches 410, 412, and 414 store request addresses. In other embodiments, one or more of request queues 411, 413, and 415 do not utilize a corresponding local address history cache.

[0073] The requests stored in request queues 411, 413, and 415 are packets of a type known as flow control unit ("flits"). A flit is a subset of a larger packet. A flit typically carries data and control information, such as header and trailer information for the larger packet. Although the data for transmission is described as packets routed in a network, in some embodiments, the data for transmission is a stream of bits or bytes in a point-to-point interconnect. Request queues 411, 413, and 415 store control packets for control logic to send on a fabric link. Another source besides packet transmitter 400 sends a corresponding data packet, such as a larger packet corresponding to a flit.

[0074] In some cases, one or more other sources (such as sources of larger data packets) share the fabric link with packet transmitter 400. Therefore, the fabric link is not always available to send control packets. Packet transmitter 400 also includes a packet buffer arbiter 450 for inserting one or more of candidate packets 430-434 into link packet 460. Link packet 460 has sufficient data storage space for storing two or more of FTI candidate packets 430-434. Packet transmitter 400 sends link packet 460 on the fabric link when control logic determines that two requirements are met. The first requirement is that the fabric transport interface sends a signal to packet transmitter 400 indicating that the fabric link is available. The second requirement is that packet transmitter 400 determines that link packet 460 is not empty.

[0075] The examples of the control packet types stored in the queues 411-415 include request types, response types, probe types, and token or credit types. Other examples of packet types are also possible and conceivable. As shown in the figure, in one example, queue 411 stores packets of "type 1" as a control request type. Queue 413 stores packets of "type 2" which are control response types in some cases, and queue 415 stores packets of "type N" which are control token or credit types in some cases.

[0076] The queue arbiter 420 selects an FTI candidate packet 430 from the queue 411. In some embodiments, the queue arbiter 420 selects the FTI candidate packet 430 based on one or more attributes. Examples of attributes are age, priority level of the packet type, priority level of the packet, quality of service parameters, source identifier, application identifier or type (such as a real-time application), indication of the type of traffic (such as real-time traffic), bandwidth requirements or delay tolerance requirements, etc. In a similar manner, the queue arbiters 422-424 select FTI candidate packets 432-434 from the queues 413 and 415.

[0077] As shown in the figure, each among the FTI candidate groups 430-434 has different data sizes 440-444.In some cases, two or more among the FTI candidate groups 430-434 have identical data sizes.One or more among queues 411,413 and 415 can store the FTI groupings of different sizes.Therefore, when the given queue arbiter among the queue arbiter 420-424 selected the FTI candidate grouping, the selected FTI candidate grouping had different sizes with the previous one selected FTI candidate grouping from same queue selection.In an example, when the grouping of queue 411 storage request types, queue 411 storage sizes were 128 non-compression request groups, and storage size was 64 compression request groups.Therefore, some entry storage data sizes of queue 411 are different FTI candidate groups from data size 440.

[0078] The link packet 460 is divided into sectors 462-466. In one example, each sector is 32 bits. Other data sizes of sectors 462-466 ​​are possible and conceivable. In one example, the link packet 460 includes eight sectors. The link packet 460 may also include any other number of sectors. The link packet 460 is stored in a register or other sequential storage element. In addition to storing data such as controlling the FTI candidate packets, the link packet 460 also stores other metadata (not shown). An example of other metadata is an indication of which (some) sectors in the sectors 462-466 ​​are available. The packet buffer arbiter 450 receives the FTI candidate packets 430-434 and selects one or more of the received FTI candidate packets 430-434 to insert into the available data storage space in the link packet 460.

[0079] Now refer to Figure 5 , shows one embodiment of a method 500 for performing efficient data transfer in a computing system. For the purpose of discussion, in this embodiment (and Figures 6 to 8 and Figure 10 The steps of the method 500 are shown in sequential order. However, it should be noted that in various embodiments of the described method, one or more of the described elements may be performed concurrently, performed in a different order than shown, or omitted entirely. Other additional elements may also be performed as needed. Any of the various systems or devices described herein may be configured to implement the method 500.

[0080] A packet transmitter receives a request including an address (block 502). In some cases, the packet transmitter receives the request from an on-chip network or fabric, and the packet transmitter sends the packet to an off-chip processor using an outbound link. Control logic in the packet transmitter selects a given request queue from a plurality of request queues based on the request type (block 504). The control logic allocates the received request among the given request queues (block 506). In some cases, the control logic allocates entries in an ordered manner such that the entry position indicates the age of the corresponding request.

[0081] The address is searched in a corresponding address history cache (block 508). The source identifier is used to index into the address history cache. In an embodiment, the source identifier includes a processor identifier and a thread identifier that identify the processor executing the thread that generated the request. The control logic uses the source identifier to select an index in the address history cache, and the control logic uses a portion of the request address as a tag to determine whether one of the multiple channels in the selected index stores the request address.

[0082] If there is a hit in the address history cache ("yes" branch of conditional block 510), an indication of the address history cache hit is stored in the allocated entry of the given request queue (block 512). In some cases, the control logic updates the cache hit field to store the predicate value. For example, using ( Figure 2 and Figure 3 ) cache hit field 250. An identification of a location in the address history cache is stored in the allocated entry (block 522). For example, a cache hit identifies a particular channel among a plurality of channels within a selected index of the address history cache. In an embodiment, the identification is the particular channel found during the cache hit, and the identification of this particular channel is stored in the allocated entry for the given request queue. For example, as previously described, channel 3 is stored in ( Figure 3 ) request queue 300.

[0083] Information from the given request queue used to perform out-of-order posting is stored in the allocated entry of the given request queue (block 524). In an embodiment, if the earlier request is still allocated in the given request queue with an indication of a cache load, an indication of a cache load match is stored in the allocated entry of the given request queue. In one example, the control logic is updated with the predicate value ( Figure 2 and Figure 3 ) cache load matching field 254.

[0084] If there is a miss in the address history cache ("no" branch of conditional block 510), an indication of an address history cache miss is stored in the allocated entry of the given request queue (block 516). In some cases, the control logic updates the cache load field to store the predicated value. For example, using ( Figure 2 and Figure 3 Cache load field 248 is then identified. A location in the address history cache is identified for storing at least a portion of the request address of the request (block 518). For example, a specific channel from a plurality of channels within the selected index is identified. If an invalid channel is not available, one of the allocated channels is selected as a replacement. For example, a least recently used (LRU) scheme is used.

[0085] At least a portion of the request address is stored in an identified location in the address history cache (block 520). Control flow of method 500 then moves to block 522, where an identification of the storage location in the address history cache is stored in an allocated entry of the given request queue. The storage location stores the address of the request. An identifier of the specific channel found during the cache hit is stored in the allocated entry of the given request queue. Control flow of method 500 then moves from block 522 to block 524, where information from the given request queue used to perform out-of-order issue is stored in the allocated entry of the given request queue. In one example, if the earlier request is still allocated in the given request queue with an indication of a cache load, an indication of a cache load match is stored in the allocated entry of the given request queue.

[0086] Now go to Figure 6 , illustrates one embodiment of a method 600 for performing efficient data transfer in a computing system. An identification of a storage location is received, the identification identifying a storage location in an address history cache storing an address of a request (block 602). The control logic of the request queue receives the identification of the storage location. In one embodiment, the received identification identifies a particular channel in the address history cache storing at least a portion of a request address of a request received by a packet transmitter. For example, channel 3 is sent to ( Figure 3 The request queue 300 is searched using the identifier of the storage location and the identifier of the source of the request (block 604). As previously described, the source identifier includes a processor identifier and a thread identifier that are used to identify the processor executing the thread that generated the request.

[0087] If there is a miss in the request queue ("No" branch of conditional block 606), an entry is allocated in the request queue for the request for which there is no earlier request in the specified request queue (block 608). For example, the allocated entry stores an indication of the hit / miss result of the address history cache for the request, but is updated with a clear or negated value ( Figure 2 and Figure 3 ) cache load match field 254. However, if there is a hit in the request queue ("yes" branch of conditional block 606), a determination is made as to whether the hit entry stores an indication specifying that the request address be stored at the receiver. In one embodiment, the hit entry stores the predicate value in ( Figure 2 and Figure 3 ) cache load field 248.

[0088] If the hit entry stores an indication specifying that the request address is to be stored at the receiver ("yes" branch of conditional block 610), an entry is allocated in the request queue for the request specifying that the earlier request is to store the request address at the receiver (block 612). For example, the allocated entry stores an indication of the hit / miss result of the address history cache for the request and is updated with the predicate value ( Figure 2 and Figure 3 ) cache load match field 254. If there is a hit in the request queue ("yes" branch of conditional block 606) and if the hit entry does not store an indication that the request address is to be stored at the receiver ("no" branch of conditional block 610), an entry is allocated in the request queue. The allocated entry is for a request that specifies that an earlier request not stored in the request queue is to store the request address at the receiver (block 614). For example, the hit entry clears the value stored in ( Figure 2 and Figure 3 The allocated entry stores an indication of the hit / miss result of the address history cache for the request, but is updated with a clear or negated value ( Figure 2 and Figure 3 ) cache load matching field 254.

[0089] Now go to Figure 7 , illustrates one embodiment of a method 700 for performing efficient data transfer in a computing system. A request having an indication of an earlier address history cache hit is selected from a request queue for issuance (block 702). In one embodiment, the selected request in the request queue stores a predicate value in ( Figure 2 and Figure 3 ) cache hit field 250. Determine whether the selected request includes an indication of an earlier request from the same source in the specified request queue and store the address of the earlier request at the receiver (block 704). In one example, the indication is stored in ( Figure 2 and Figure 3 ) cache loads the predicate value in the matching field 254.

[0090] If the selected request includes the above indication ("yes" branch of conditional block 706), then a non-compressed candidate packet with an address is created for the selected request to be packaged into an outbound link packet (block 708). Although there was an earlier hit in the address history cache, the selected request was selected to be issued before the earlier request, which stored the request address at the receiver. Since this earlier request has not yet been issued, the request address is not yet stored at the receiver.

[0091] If the selected request does not include the above indication ("No" branch of conditional block 706), a compressed candidate packet without a portion of the address is created for the selected request to be packaged into an outbound link packet (block 710). Because the selected request already had an earlier hit in the address history cache, and the selected request was selected for issuance after the earlier request, which stored the request address at the receiver, the compressed packet without at least a portion of the request address is sent to the receiver.

[0092] Now go to Figure 8 , illustrates one embodiment of a method 800 for performing efficient data transfer in a computing system. A request having an indication specifying an address for storing a request is selected from a request queue for issuance (block 802). In one embodiment, the selected request in the request queue stores a predicate value in ( Figure 2 and Figure 3 ) cache load field 248. Although the use of a table (such as table 330 previously described for request queue 300) is not described herein, in some cases, the selected request is qualified before performing other steps. For example, if the selected request is found to have a higher corresponding request (having a cache hit field asserted and using the same request address as the selected request) count than other unprocessed requests having counts, then the selected request is considered qualified. The control logic searches for requests that are earlier than the selected request for requests from the same source identifier and using the same identification of the storage location in the address history cache (block 804). For example, the control logic searches for earlier requests for requests that have the same source identifier and the same identification of the storage location (cache way) as the selected request.

[0093] If the above search finds a match ("yes" branch of conditional block 806), any indication of an address history cache hit in the matching request is cleared (block 808). Additionally, in some embodiments, control logic in the packet receiver clears any indication of an address stored at the receiver in the matching request (block 810). Referring again to ( Figure 3 For the example case of the request queue 300 of FIG, blocks 806-810 of method 800 are similar to those during a search for an earlier request from the same source and using the same storage location in the address history cache ( Figure 3 ) Steps 2-4 of situation .

[0094] If the control logic does not find a match from the above search (the "no" branch of conditional block 806), or the control logic completes clearing indications of one or more earlier requests (blocks 808 and 810), the control logic performs another search. For example, the control logic searches for requests that are later than the selected request for requests from the same source identifier and identified using the same storage location in the address history cache (block 816). In one embodiment, the control logic searches for later requests for requests identified using the same source identifier and the same storage location (cache way) as the selected request. If a match is found from this search (the "yes" branch of conditional block 818), then the request that has an indication of the address storage at the receiver in the matching request is identified by age between the selected request and the next earlier request (block 820). Again briefly referring to Figure 3 In the example and case 3 in FIG, for the selected entry 32, the control logic identifies the later entries 15 and 20 that are still being allocated between the entry 8 that is still being allocated and the selected entry 32.

[0095] If there are any identified requests ("yes" branch of conditional block 822), any indications for the identified requests that they share the same source information as the selected request are cleared (block 824). The source information includes a source identifier and an identification of a storage location in the address history cache. In one embodiment, the source identifier includes at least a processor identifier and a thread identifier. In some cases, cache load match fields are cleared or denied for these identified requests. Thus, at a later point in time, when the arbitration logic selects one or more identified requests to be issued, the control logic creates a compressed packet. The compressed packet is created at this time because the request address or a portion of the request address is stored in the remote address history cache at the receiver due to the current (and earlier) selected request being issued.

[0096] If there is no identified request ("No" branch of conditional block 822), then the control flow of method 800 moves to 826 where an uncompressed candidate packet with an address is created for the selected request to be packaged into an outbound link packet. Figure 3In the example of the case where there is a request queue 300 containing a source identifier, blocks 816-824 of method 800 are similar to the steps of cases 2-4 during a search for a later request from the same source and using the same storage location in the address history cache. As previously described, the control logic searches for requests that are later than the selected request for requests that have the same source identifier and use the same storage location in the address history cache (block 816). If no match is found from this search (the "no" branch of conditional block 818), the control flow of method 800 moves to 826, where an uncompressed candidate packet with an address is created for the selected request to be packaged into an outbound link packet.

[0097] refer to Figure 9 , a generalized block diagram of one embodiment of a packet receiver 900 is shown. In the illustrated embodiment, packet receiver 900 includes queues 911, 913, and 915, each for storing packets of a corresponding type. As shown, each of request queues 911, 913, and 915 has a corresponding address history cache 910, 912, and 914. Address history caches 910, 912, and 914 store request addresses for received compressed packets.

[0098] As shown in the figure, packet receiver 900 receives link packet 960 from fabric link.Link packet 960 has enough data storage spaces to be used to store two or more FTI groups.Distribution multiplexing logic 950 (or logic 950) analyzes the sector 962-966 in the link packet 900, determines how many FTI control packets there are in the link packet 960 and their position in the link packet 960, and sends the FTI control packets to queue 911, 913 and 915 so that storage.The example of the control packet type that is stored in the queue 910-914 comprises request type, response type, detection type and token or credit type.In other embodiments, also comprise other examples of packet type.As shown in the figure, queue 911 stores the grouping of " type 1 ", queue 913 stores the grouping of " type 2 ", and queue 915 stores the grouping of " type N ".

[0099] Link packet 960 is divided into sectors 962-966. In an example, each sector is 32 bits. Other data sizes of sectors 962-966 are possible and conceivable. In addition to storing data such as control FTI packets, other metadata (not shown) are also stored. The example of other metadata is the indication of the allocated sectors in the middle of sectors 962-966 and the indication of where the control FTI packets begin, because in some embodiments the control FTI packets have the data size of variation. In various embodiments, logic 950 comprises a combination of combinatorial logic and sequential elements. Logic 950 is implemented with hardware, software or a combination thereof. Logic 950 removes one or more control FTI packets from link packet 960 and sends them to queues 911, 913 and 915.

[0100] As shown in the figure, each in the FTI candidate packets 930-934 has different data sizes 940-944. In other cases, two or more in the FTI candidate packets 930-934 have identical data sizes. In an embodiment, one or more storage FTI packets of different sizes in the queues 911-915. Therefore, when logic 950 sends FTI packets (such as FTI packets 930) to queue 911, the FTI packets have different sizes from the previous FTI packets that are sent to the same queue. In an example, when the grouping of queue 911 storage request types, the queue 911 storage sizes are the non-compression request packets of 128 bits, and the storage size is the compression request packets of 64 bits. Therefore, some entry storage data sizes of queue 911 are different from the FTI candidate packets of data size 940.

[0101] In various embodiments, one or more of the FTI candidate packets 930-934 are compressed packets that do not store at least a portion of the request address. For compressed packets, logic 950 accesses the corresponding address history caches in the address history caches 910-914 to retrieve a portion of the request address that does not exist in the compressed packet sent over the link. In some cases, the compressed packet includes an indication that it is a compressed packet. As previously described, the asserted value of the cache hit field 250 indicates that at least a portion of the request address is stored in the corresponding address history caches in the address history caches 910-914, rather than in the compressed packet. By transmitting a compressed packet that does not have at least a portion of the request address, link efficiency is improved.

[0102] In some embodiments, the uncompressed packets in the FTI candidate packets 930-934 include an indication to store at least a portion of the request address within the uncompressed packet in a corresponding address history cache in the address history caches 910-914. As previously described, the cache load field 248 indicates to the logic 950 that the logic 950 store at least a portion of the request address in a corresponding address history cache in the address history caches 910-914. The logic 950 uses the stored portion of the request address for a compressed packet received at a later point in time.

[0103] In various embodiments, each of the queues 911-915 includes a control logic (not shown) for maintaining a plurality of available entries so that distribution. The entries of the queues 911-915 include a valid bit indicating available entries. In some cases, the negative value indication available entries stored in the valid field, and the asserted value indication allocated entries stored in the valid field. In some embodiments, the control logic in the queues 911-915 determines the quantity of tokens or credits 952 based on the quantity of available entries. The control logic sends the value of tokens 952 to the packet transmitter on the other side of one or more links. For example, packet receiver 900 uses sidebands to send tokens 952 to the packet transmitter.

[0104] Now refer to Figure 10 , illustrates one embodiment of a method 1000 for performing efficient data transfer in a computing system. A request is received from an inbound link (block 1002). A packet receiver receives the request from a packet transmitter on the link. The packet receiver determines whether the request includes an indication specifying that an address history cache store the address of the request (block 1004). The received request stores an indication specifying whether the request is in a compressed packet that does not include at least a portion of the request address. As previously described, in some cases, the cache hit field 250 stores this indication. If such an indication is included in the request (the "yes" branch of conditional block 1006), the packet receiver retrieves an identifier of a storage location in the address history cache that stores the request address (block 1008). In one embodiment, the request includes a cache way. When combined with a source identifier, the cache way identifies a specific storage location in the address history cache at the packet receiver.

[0105] Control logic in the packet receiver retrieves an address from the address history cache using at least an identifier of a storage location in the address history cache (block 1010). For example, the control logic uses the source identifier to select a specific index in the address history cache and uses the cached channel included in the request to select a specific channel within the specific index. The packet receiver then processes the request using the retrieved address (block 1022).

[0106] If the request does not include an indication that the address history cache stores the requested address (the "no" branch of conditional block 1006), the packet receiver determines whether the request contains an indication for storing the address to be requested later. As previously described, in one embodiment, the packet receiver uses cache load field 248 to make this determination. If such an indication exists (the "yes" branch of conditional block 1012), the packet receiver retrieves the identifier of the storage location in the address history cache from the request (block 1014). The packet receiver retrieves the address from the request (block 1016) and uses the identifier of the storage location to store the address in the address history cache (block 1018). As previously described, a source identifier is also used. For example, the packet receiver uses the source identifier to select a specific index in the address history cache and uses the cache path included in the request to select a specific path within the specific index. The packet receiver then uses the retrieved address to process the request (block 1022).

[0107] If there is no indication that the address is to be stored in the corresponding address history cache (the "No" branch of conditional block 1012), the packet receiver retrieves the address from the request without storing the address in any address history cache (block 1020). In one embodiment, the packet receiver examines each of the cache load field 248 and the cache hit field 250 described earlier and determines whether each field stores a negative or cleared value. In such a case, the packet receiver does not use the address history cache to process the request (block 1022).

[0108] In various embodiments, the previously described methods and / or mechanisms are implemented using program instructions of a software application. The program instructions describe the behavior of the hardware in a high-level programming language (such as C). Alternatively, a hardware design language (HDL) such as Verilog is used. The program instructions are stored on a non-transitory computer-readable storage medium. Numerous types of storage media are available. During use, a computing system can access the storage medium to provide the program instructions and accompanying data to the computing system for execution of the program. The computing system includes at least one or more memories and one or more processors that execute the program instructions.

[0109] It should be emphasized that the above embodiments are only non-limiting examples of implementations. Once the above disclosure is fully understood, many variations and modifications will be apparent to those skilled in the art. The appended claims are intended to be interpreted as covering all such variations and modifications.

Claims

1. A device comprising: a plurality of data storage queues, each queue being configured to store requests of a corresponding type for publication to a receiver; one or more address history caches, each address history cache configured to store a request address; circuit, the circuit being configured to: selecting one of the plurality of queues for a received first request including an address; allocating a first entry in the selected queue for the first request; The following items are stored in the first entry: a first indication that the address is found in one of the one or more address history caches; as well as a second indication that the selected queue has a second entry allocated for storing a second request including the address, the second entry being different from the first entry, the storing occurring in response to determining that the second entry includes an indication that the address is to be stored at the receiver.

2. The apparatus of claim 1 , wherein the circuitry is further configured to create, corresponding to the first request, a compressed packet comprising an identification of a location of the address in the address history cache and a portion of the address that is less than the entire address in response to determining: The first request is selected for publication; and The first entry of the selected queue for the first request stores the first indication and does not store the second indication.

3. The apparatus of claim 1 , wherein the circuitry is further configured to create an uncompressed packet corresponding to the first request including the address in response to determining: The first request is selected for publication; and The first entry of the selected queue for the first request stores the first indication and stores the second indication.

4. The apparatus of claim 1 , wherein in response to not finding the address corresponding to the first request in the address history cache corresponding to the selected queue, the circuitry is further configured to: storing in the first entry an indication that the address was not found in the address history cache; identifying a location in the address history cache for storing at least a portion of the address; storing the portion of the address in the location; and An identification of the location is stored in the first entry.

5. The apparatus of claim 1 , wherein in response to determining that the second request is selected for issuance, the circuitry is further configured to search for one or more matching earlier requests that are earlier than the second request and have an assigned entry in the selected queue, wherein the one or more matching earlier requests have the same source and the same identification of a location in the address history cache as the second request.

6. The apparatus of claim 5 , wherein in response to an earlier request finding the one or more matches, the circuitry is further configured to: clearing any indication of an address history cache hit in the allocated entry of the one or more matching earlier requests; and Any indication of a storage address at the receiver in the allocated entry of the one or more matching earlier requests is cleared.

7. The apparatus of claim 5 , wherein in response to determining that the second request is selected for issuance, the circuitry is further configured to search for a plurality of matching later requests that are later than the second request and have assigned entries in the selected queue, wherein the plurality of matching later requests have the same source and the same identification of a location in the address history cache as the second request.

8. A method comprising: storing requests in a plurality of queues, each queue being configured to store requests of a corresponding type for publication to a receiver; storing the request address in one or more address history caches; selecting one of the plurality of queues for a received first request including an address; allocating a first entry in the selected queue for the first request; storing a first indication in the first entry that the address is found in one of the one or more address history caches; and A second indication is stored in the first entry, the second indication indicating that the selected queue has a second entry allocated for storing a second request including the address, the second entry being different from the first entry, the storing occurring in response to determining that the second entry includes an indication that the address is to be stored at the receiver.

9. The method of claim 8, further comprising: Creating a compressed packet corresponding to the first request including an identification of a location of the address in the address history cache and a portion of the address that is less than the entire address in response to determining: The first request is selected for publication; and The first entry of the selected queue for the first request stores the first indication and does not store the second indication.

10. The method of claim 8, further comprising: Creating an uncompressed packet corresponding to the first request and including the address in response to determining: The first request is selected for publication; and The first entry of the selected queue for the first request stores the first indication and stores the second indication.

11. The method of claim 8 , wherein in response to not finding the address corresponding to the first request in the address history cache corresponding to the selected queue, the method further comprises: storing in the first entry an indication that the address was not found in the address history cache; identifying a location in the address history cache for storing at least a portion of the address; storing the portion of the address in the location; as well as An identification of the location is stored in the first entry.

12. The method of claim 8, wherein in response to determining that the second request is selected for publication, the method further comprises: One or more matching earlier requests that are earlier than the second request and have an assigned entry in the selected queue are searched, wherein the one or more matching earlier requests have the same source and the same identification of a location in the address history cache as the second request.

13. The method of claim 12, wherein in response to an earlier request finding the one or more matches, the method further comprises: clearing any indication of an address history cache hit in the allocated entry of the one or more matching earlier requests; as well as Any indication of a storage address at the receiver in the allocated entry of the one or more matching earlier requests is cleared.

14. The method of claim 12, wherein in response to determining that the second request is selected for publication, the method further comprises: A plurality of matching later requests that are later than the second request and have assigned entries in the queue are searched, wherein the plurality of matching later requests have the same source and the same identification of a location in the address history cache as the second request.

15. A non-transitory computer-readable storage medium storing program instructions, wherein the program instructions are executable by a processor to: Store requests in multiple queues, each queue is configured to store requests of the corresponding type; storing the request address in one or more address history caches; selecting one of the plurality of queues for a received first request including an address; allocating a first entry in the selected queue for the first request; The following items are stored in the first entry: a first indication that the address is found in one of the one or more address history caches; as well as a second indication that the selected queue has a second entry allocated for storing a second request including the address, the second entry being different from the first entry, the storing occurring in response to determining that the second entry includes an indication that the address is to be stored at the receiver.

Images