Cache snooping mode to extend coherency protection for specific requests

Abstract

The cache memory includes a data array, a directory of the contents of the data array specifying coherence state information, and snoop logic that processes operations snooped from the system fabric by referencing the data array and the directory. The snoop logic, in response to a snoop of a request for a flash memory access operation or a clean memory access operation from an initiating coherence participant on the system fabric, determines whether the directory indicates that the cache memory has coherence ownership of the target address of the request. Based on a determination that the directory indicates that the cache memory has coherence ownership of the target address, the snoop logic provides a coherence response to the request that transfers coherence ownership of the target address to the initiating coherence participant so that the initiating coherence participant can protect the target address from conflicting requests.

Description

[Technical field]

[0001] The present invention relates generally to data processing, and more particularly to a cache snooping mode that extends coherence protection for flush / clean memory access requests that update system memory. [Background technology]

[0002] A conventional multiprocessor (MP) computer system, such as a server computer system, includes multiple processing units, all of which are coupled to a system interconnect, which typically includes one or more address buses, data buses, and control buses. Coupled to the system interconnect is a system memory, which represents the lowest level of shared memory in a multiprocessor computer system and is generally accessible for read and write access by all of the processing units. To reduce access latency to instructions and data present in the system memory, each processing unit is typically further supported by a respective multilevel cache hierarchy, with the lower levels of the hierarchy being shareable by one or more processor cores.

[0003] To speed up processing by reducing the access latency incurred by having to load the required data and instructions from the system memory, cache memories are commonly used to temporarily buffer memory blocks that are likely to be accessed by the processor. In some MP systems, the cache hierarchy includes at least two levels. A level 1 (L1) or higher level cache is usually a private cache associated with a particular processor core and cannot be accessed by other cores in the MP system. Typically, in response to a memory access instruction, such as a load or store instruction, the processor core first accesses the directory of the higher level cache. If the requested memory block is not found in the higher level cache, the processor core then accesses a lower level cache (e.g., a level 2 (L2) or level 3 (L3) cache) for the requested memory block. The lowest level cache (e.g., L2 or L3) can be shared by multiple processor cores.

[0004] Because multiple processor cores may request write access to the same cache line of data, and because modified cache lines are not immediately synchronized with system memory, cache hierarchies in multiprocessor computer systems typically implement cache coherency protocols to guarantee at least a minimum level of coherency between the various processor cores' "views" of the contents of system memory. Specifically, cache coherency requires that, at a minimum, after a hardware thread accesses a copy of a memory block and then subsequently accesses the updated copy of the memory block, the hardware thread cannot access the stale copy of the memory block again.

[0005] Some MP systems support flush and clean operations that cause modified cache lines associated with the target address of a flush or clean operation, if any, to be copied back to system memory from a native cache hierarchy that contains cache lines in a coherence state indicating write permission (sometimes referred to herein as the "HPC state"). In the case of a clean operation, the target cache line is also transitioned to an unmodified HPC coherence state. In the case of a flush operation, the target cache line in the HPC state, if any, is transitioned to an invalid coherence state, regardless of whether it is modified or not. A flush operation further requires that any other copies of the target cache line in a non-HPC state be invalidated throughout the cache hierarchy of the MP system. Caches that hold the target cache line in the HPC state, if any, may not have completed this invalidation when they complete their operations.

[0006] In an MP system that maintains coherency with a snoop-based coherence protocol, a flush or clean operation is typically broadcast on the MP system's system interconnect and receives a retry coherency response unless a cache that holds the target cache line in an HPC state has completed processing the flush or clean operation. Thus, a coherence participant that initiates a flush or clean operation may need to reissue the flush or clean operation multiple times before a cache that holds the target cache line in an HPC state, if any, completes processing of the flush or clean operation. When a cache that held the target cache line in the HPC state completes processing a flush or clean operation and a new copy of the target cache line in the HPC state (either Modified HPC state for a clean operation, and either Modified or Unmodified HPC state for a flush operation) has not yet been created, a subsequent issuance of a clean operation will receive a coherence response indicating success, and a subsequent issuance of a flush operation will receive either a coherence response indicating success (if no cache copies of the line exist at the time) or a coherence response that transfers responsibility for invalidating any remaining non-HPC cache copies of the target cache line to the initiating coherence participant. In either of these cases for a flush operation, the flush operation can be considered "successful" in the sense that it has completed either when the flush operation has completed in its entirety or when the remaining non-HPC copies of the target cache line have been invalidated by the initiating coherence participant (e.g., by issuing a kill operation).However, if another coherence participant creates a new copy of the target cache line in that HPC state (i.e., in a modified HPC state for a clean operation, and in a modified or unmodified HPC state for a flush operation) prior to the subsequent issuance of the clean or flush operation, the subsequent reissue of the flush or clean operation will have to be retried and the new copy of the target cache line in the HPC state will have to be processed, thus delaying the successful completion of the flush or clean operation. This delay may be further increased by the continued creation of new HPC copies of the target cache line of the flush or clean operation. Summary of the Invention

[0007] In at least one embodiment, a target cache line of a flush or clean operation is protected from competing accesses from other coherence participants by a designated coherence participant providing a protection window for the target cache line.

[0008] In at least one embodiment, a cache memory includes a data array, a directory of contents of the data array specifying coherence state information, and snoop logic that processes operations snooped from the system fabric by referencing the data array and the directory. The snoop logic is responsive to a snoop of a request for a flash memory access operation or a clean memory access operation of an initiating coherence participant on the system fabric to determine whether the directory indicates that the cache memory has coherence ownership of a target address of the request. Based on a determination that the directory indicates that the cache memory has coherence ownership of the target address, the snoop logic provides a coherence response to the request that transfers coherence ownership of the target address to the initiating coherence participant such that the initiating coherence participant can protect the target address from conflicting requests.

[0009] Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which: [Brief description of the drawings]

[0010] [Figure 1] 1 is a schematic block diagram illustrating an exemplary data processing system, according to one embodiment. [Diagram 2] FIG. 2 is a more detailed block diagram of an exemplary processing unit, according to one embodiment. [Diagram 3] FIG. 2 is a detailed block diagram illustrating a lower level cache according to one embodiment. [Figure 4] 4 is an exemplary timing diagram illustrating a processor memory access operation according to one embodiment. [Diagram 5] 1 is a schematic logic flow diagram illustrating an exemplary process by which a processing unit performs flush / clean memory access operations in accordance with one embodiment. [Figure 6] 1 is a schematic logic flow diagram illustrating an exemplary process by which a cache having coherent ownership of a target cache line of a snooped flush or clean type request processes the request in accordance with one embodiment. [Figure 7] 1 is a schematic logic flow diagram illustrating an exemplary process by which a cache that holds a non-HPC shared copy of a target cache of a snooped flush-type request processes the request in accordance with one embodiment. [Figure 8] FIG. 1 is a data flow diagram illustrating the design process. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] Referring now to the drawings, in which like reference numerals refer to like and corresponding parts throughout, and specifically to FIG. 1, a schematic block diagram illustrating an exemplary data processing system 100 according to one embodiment is shown. In this illustrated embodiment, data processing system 100 is a cache coherent multiprocessor (MP) data processing system that includes multiple processing nodes 102 for processing data and instructions. The processing nodes 102 are coupled to a system interconnect 110 for carrying address, data and control information. The system interconnect 110 may be implemented, for example, as a bus interconnect, a switch interconnect, or a hybrid interconnect.

[0012] In the illustrated embodiment, each processing node 102 is implemented as a multi-chip module (MCM) that includes four processing units 104, with each processing unit 104 preferably implemented as a respective integrated circuit. The processing units 104 in each processing node 102 are coupled for communication among themselves and with a system interconnect 110 by a local interconnect 114, which, like the system interconnect 110, may be implemented with, for example, one or more buses and / or switches. The system interconnect 110 and the local interconnect 114 together form the system fabric.

[0013] As described in more detail below with reference to FIG. 2, each of the processing units 104 includes a memory controller 106 coupled to a local interconnect 114 to provide an interface with a respective system memory 108. Data and instructions present in the system memory 108 are generally accessible, cacheable, and modifiable by a processor core in any processing unit 104 of any processing node 102 in the data processing system 100. Thus, the system memory 108 forms the lowest level of memory storage in the distributed shared memory system of the data processing system 100. In alternative embodiments, one or more memory controllers 106 (and system memory 108) may be coupled to the system interconnect 110 rather than the local interconnect 114.

[0014] Those skilled in the art will appreciate that the MP data processing system 100 of Figure 1 can include many additional, not shown, components, such as interconnect bridges, non-volatile storage, ports for connection to a network, or auxiliary devices. Because such additional components are not necessary for an understanding of the described embodiments, they are not shown in Figure 1 or described in detail herein. However, it should also be understood that the enhancements described herein are applicable to data processing systems of a variety of architectures and are not limited in any way to the generalized data processing system architecture shown in Figure 1.

[0015] 2, a more detailed block diagram of an exemplary processing unit 104 is shown, according to one embodiment. In the illustrated embodiment, each processing unit 104 is an integrated circuit that includes multiple processor cores 200 for processing instructions and data. Each processor core 200 includes one or more execution units for instruction execution, including an LSU 202 that executes memory access instructions that request access to a memory block or cause the generation of requests to access a memory block. In at least some embodiments, each processor core 200 is capable of simultaneously and independently executing multiple hardware execution threads.

[0016] The operation of each processor core 200 is supported by a multi-level memory hierarchy with, at the lowest level, a shared system memory 108 accessed via an integrated memory controller 106. At a higher level, the memory hierarchy includes one or more levels of cache memory, which in the illustrated embodiment includes within each processor core 200 a private store-through level 1 (L1) cache 226 for that processor core 200 and a respective store-in level 2 (L2) cache 230 for each processor core 200. To efficiently handle multiple simultaneous memory access requests to cacheable addresses, in some embodiments each L2 cache 230 may be implemented with multiple L2 cache slices, each of the multiple L2 cache slices handling memory access requests for a respective set of real memory addresses.

[0017] Although the illustrated cache hierarchy includes only two levels of cache, one skilled in the art will appreciate that other embodiments may include additional levels (e.g., L3, L4, etc.) of on-chip or off-chip inline or look-aside caches, which may contain all, some, or none of the contents of the higher level caches.

[0018] Continuing to refer to FIG. 2, each processing unit 104 further includes an integrated and distributed fabric controller 216 responsible for controlling the flow of operations on the local interconnect 114 and the system interconnect 110, and response logic 218 for determining a coherency response to a memory access request used in a selected cache coherency protocol.

[0019] In operation, when a hardware thread being executed by processor core 200 includes a memory access instruction that requests performance of a specified memory access operation, LSU 202 executes the memory access instruction to determine the target real address to access. If the requested memory access cannot be fully fulfilled by referencing L1 cache 226 of the executing processor core 200, processor core 200 generates a memory access request, e.g., including at least a request type and a target real address, and issues the memory access request to the associated L2 cache 230 of that processor core 200 for processing.

[0020] 3, a more detailed block diagram of an exemplary embodiment of L2 cache 230 is shown in accordance with one embodiment. As shown in FIG. 3, L2 cache 230 includes a cache array 302 and a directory 308 of the contents of cache array 302. Assuming that cache array 302 and directory 308 are conventionally set associative, memory locations in system memory 108 are mapped to particular congruence classes in cache array 302 using predefined index bits in a system memory (real) address. The particular memory blocks stored in cache lines of cache array 302 are recorded in cache directory 308, which contains one directory entry per cache line. Although not explicitly shown in FIG. 3, those skilled in the art will appreciate that each directory entry in cache directory 308 includes various fields, such as a tag field that identifies the actual address of the memory block held in the corresponding cache line of cache array 302, a state field that indicates the coherency state of the cache line, a least recently used (LRU) field that indicates the replacement order of the cache line compared to other cache lines in the same congruence class, and an inclusion field that indicates whether the memory block is held in the associated L1 cache 226.

[0021] The L2 cache 230 includes multiple (e.g., 16) Read-Claim (RC) machines 312a-312n for independently and simultaneously servicing memory access requests received from the associated processor core 200. To accommodate remote memory access requests originating from processor cores 200 other than the associated processor core 200, the L2 cache 230 also includes multiple Snoop (SN) machines 311a-311m. Each SN machine 311 can independently and simultaneously process remote memory access requests “snooped” from the local interconnect 114. Naturally, servicing a memory access request by the RC machine 312 may require replacement or invalidation of memory blocks in the cache array 302. Thus, the L2 cache 230 includes a castout (CO) machine 310 that manages the removal and write-back of memory blocks from the cache array 302.

[0022] The L2 cache 230 further includes an arbiter 305 that controls multiplexers M1-M2 to order processing of local memory access requests received from an associated processor core 200 and remote requests snooped on the local interconnect 114. The memory access requests are forwarded to dispatch logic 306 according to an arbitration policy implemented by the arbiter 305, which processes the memory access requests relative to a directory 308 and cache array 302 for a predetermined number of cycles.

[0023] The L2 cache 230 also includes an RC queue (RCQ) 320 and a castout push intervention (CPI) queue 318 that buffer data to be inserted into and removed from the cache array 302, respectively. The RCQ 320 includes a number of buffer entries, each of which corresponds individually to a particular one of the RC machines 312, such that each dispatched RC machine 312 retrieves data only from its designated buffer entry. Similarly, the CPI queue 318 includes a number of buffer entries, each of which corresponds individually to a respective one of the CO machines 310 and SN machines 311, such that each CO machine 310 and each dispatched snooper 311 retrieves data only from its designated CPI buffer entry.

[0024] Each RC machine 312 also has an assigned one of a plurality of RC data (RCDAT) buffers 322 for buffering memory blocks read from cache array 302 and / or received from local interconnect 114 via reload bus 323. The RCDAT buffer 322 assigned to each RC machine 312 is preferably constructed with connections and functions corresponding to memory access requests serviceable by the associated RC machine 312. The RCDAT buffer 322 has an associated store data multiplexer M4 which selects data bytes from among its inputs for buffering in the RCDAT buffer 322 in response to a select signal, not shown, generated by arbiter 305.

[0025] In operation, a processor store request including a request type (ttype), a target real address, and store data is received from an associated processor core 200 in a store queue (STQ) 304. From the STQ 304, the store data is sent to a store data multiplexer M4 via a data path 324, and the store type and target address are passed to a multiplexer M1. Multiplexer M1 also receives as inputs a processor load request from the processor core 200 and a directory write request from the RC machine 312. In response to a select signal (not shown) generated by an arbiter 305, multiplexer M1 selects and forwards one of the input requests to multiplexer M2, which further receives as input a remote request received from the local interconnect 114 via a remote request path 326. The arbiter 305 schedules the local and remote memory access requests for processing and generates a series of select signals 328 based on the scheduling. In response to a selection signal 328 generated by arbiter 305, multiplexer M2 selects either the local request received from multiplexer M1 or the remote request snooped from local interconnect 114 as the next memory access request to process.

[0026] Referring now to Figure 4, there is shown a time-space diagram of exemplary operations on the system fabric of data processing system 100 of Figure 1. It should be understood that many such operations are occurring on the system fabric at any given time, and that two or more of these concurrent operations may, in some operating circumstances, specify conflicting target addresses.

[0027] The operation begins with a request stage 450 in which a master 400, for example the RC machine 312 of the L2 cache 230, issues a request 402 on the system fabric. The request 402 preferably includes at least a request type indicating the type of intended access and a resource identifier (e.g., a real address) indicating the resource to be accessed by the request. The request preferably includes a request as set forth in Table 1 below.

[0028] [Table 1]

[0029] The request 402 is received by snoopers 404a-404n distributed within the data processing system 100, such as the SN machines 311a-311m of the L2 caches 230 and a snooper, not shown, within the memory controller 106. For read-type requests, the SN machine 311 in the same L2 cache 230 as the master 400 of the request 402 does not snoop the request 402 (i.e., there is generally no self-snooping) because the request 402 is sent on the system fabric only if the read-type request 402 cannot be serviced internally by the processing unit 104. However, for other types of requests 402, such as flush / clean requests (e.g., the DCBF, DCBST, AMO requests listed in Table I), the SN machine 311 in the same L2 cache 230 as the master 400 of the request 402 does self-snoop the request 402.

[0030] Operation continues with a partial response phase 455. In the partial response phase 455, each snooper 404 that receives and processes a request 402 provides a respective partial response ("Presp") 406 that represents at least that snooper's 404 response to the request 402. A snooper 404 in the integrated memory controller 106 determines which partial response 406 to provide based on, for example, whether the snooper 404 is responsible for the request address and whether it has resources currently available to service the request. A snooper 404 in the L2 cache 230 may determine its partial response 406 based on, for example, the availability of its L2 cache directory 308, the availability of a snoop logic instance 311 in the snooper 404 to process the request, and the coherence state, if any, associated with the request address in the L2 cache directory 308.

[0031] Operation continues with a combined response stage 460, in which the partial responses 406 of the snoopers 404 are logically combined, either incrementally or all at once, by one or more instances of the response logic 218 to determine a system-wide combined response ("Cresp") 410 to the request 402. In a preferred embodiment considered below, the instance of the response logic 218 responsible for generating the combined response 410 is located in the processing unit 104 that contains the master 400 that issued the request 402. The response logic 218 provides the combined response 410 to the master 400 and the snooper 404 via the system fabric to indicate a system-wide response (e.g., success, retry, etc.) to the request 402. When Cresp 410 indicates success of request 402, it may indicate, for example, the data source of the requested memory block (if applicable), the coherence state in which the requested memory block is cached by master 400 (if applicable), and whether a “cleanup” operation is required to invalidate cached copies of the requested memory block in one or more L2 caches 230 (if applicable).

[0032] In response to receiving the combined response 410, one or more of the master 400 and the snoopers 404 typically perform one or more operations to service the request 402. These operations may include supplying data to the master 400, invalidating or otherwise updating the coherence state of data cached in one or more L2 caches 230, performing a castout operation, writing data back to the system memory 108, etc. If required by the request 402, the requested or target memory block may be transmitted to or from the master 400 or one of the snoopers 404 before or after the response logic 218 generates the combined response 410.

[0033] The following description describes the partial response 406 of a snooper 404 to a request 402 and the actions taken by the snooper 404 in response to the request 402 and / or the combined response 410, with respect to whether the snooper is the Highest Point of Coherency (HPC), the Lowest Point of Coherency (LPC), or neither with respect to the request address specified by the request. An LPC is defined herein as a memory or I / O device that serves as the ultimate repository for a memory block. If no caching participant holds a copy of the memory block, the LPC holds the only image of the memory block. If no HPC caching participant exists for the memory block, the LPC is the only authority to approve or deny requests to modify the memory block. Additionally, the LPC provides data for requests to read or modify the memory block if the LPC data is current and no caching participant exists that can provide the data. If a caching participant has a more up-to-date copy of the data but is unable to serve it in response to the request, the LPC will not serve the stale data and the request will be retried. For a typical request in the embodiment of data processing system 100 shown in Figures 1-3, the LPC would be the memory controller 106 for the system memory 108 that holds the referenced memory block.

[0034] An HPC is defined herein as a uniquely identified device that caches a true image of a memory block (which may or may not match the corresponding memory block in the LPC) and has the authority to approve or deny requests to modify the memory block. To explain, the HPC (even if that copy matches the main memory behind the LPC) also provides a copy of the memory block to the requester in response to a request to read or modify the memory block (cache-to-cache transfers are faster than LPC-to-cache transfers). Thus, for a typical request in this data processing system embodiment, the HPC is the L2 cache 230, if there is one. Although other indicators may be used to designate the HPC of a memory block, a preferred embodiment uses a selected cache coherence state in the L2 cache directory 308 of the L2 cache 230 to designate the HPC of a memory block, if there is one. In a preferred embodiment, the coherency states in the coherency protocol, in addition to (1) providing an indication of whether a cache is the HPC of a memory block, also indicate (2) whether the cache copy is unique (i.e., the only cached copy system-wide), (3) whether and when the cache is able to provide a copy of the memory block to a master requesting the memory block relative to the stage of operation, and (4) whether the cache image of the memory block is consistent with the corresponding memory block in the LPC (system memory). These four attributes may be represented, for example, by a variation of the well-known MESI (Modified, Exclusive, Shared, Invalid) protocol, as summarized in Table II below. More information regarding coherency protocols may be found, for example, in U.S. Pat. No. 7,389,388, which is incorporated herein by reference.

[0035] [Table 2]

[0036] In addition, in Table II above, T, Te, S L The S and S states are all "shared" coherence states in that a cache memory may simultaneously hold a copy of a cache line held in any of these states by another cache memory. The T or Te states identify an HPC cache memory that previously held the associated cache line in one of the M or Me states, respectively, and was a source of a query-only copy of the associated cache line to another cache memory. As an HPC, a cache memory that holds a cache line in a T or Te coherence state has the authority to modify the cache line or to grant such authority to another cache memory. A cache memory that holds a cache line in a Tx state (e.g., T or Te) has the authority to modify the cache line, or to grant such authority to another cache memory. A cache memory that holds a cache line in a Tx state (e.g., T or Te) has the authority to modify the cache line, or to grant such authority to another cache memory, if it has the authority to modify the cache line ... L It acts as a cache data source of last resort (after Cresp) for the query-only copy of that cache line, in that it will supply a query-only copy to another cache memory only if there is no other cache memory holding the cache line for that state.

[0037] S L The state is formed in a cache memory in response to the cache memory receiving an inquiry-only copy of a cache line from a cache memory in the T coherence state. L The state is not an HPC coherence state, but S L A cache memory that holds a cache line in the state can provide an inquiry-only copy of that cache line to another cache memory, and can do so before the receipt of Cresp. L In response to supplying a cache line to another cache memory (taking the coherence state S), the cache memory that is the source of the query-only copy of the cache line takes the coherence state S for that cache line.L Update from to S. Therefore, S L The implementation of coherence states allows many query-only copies of frequently queried cache lines to be formed throughout a multiprocessor data processing system, thereby advantageously reducing the latency of query-only accesses to those cache lines.

[0038] 4, the HPC, if any, of the memory block referenced in the request 402, or the LPC of the memory block if there is no HPC, is preferably responsible for protecting the transfer of coherence ownership of the memory block, if necessary, in response to the request 402. In the exemplary scenario shown in FIG. 4, a snooper 404n in the HPC (or LPC if there is no HPC) of the memory block specified by the request address of the request 402 protects the transfer of coherence ownership of the requested memory block to the master 400 for a protection window 412a period that extends from the time the snooper 404n determines its snooper 404n's partial response 406 until the snooper 404n receives the combined response 410, and for a subsequent window extension period 412b that extends a programmable time beyond the receipt by the snooper 404n of the combined response 410. During the protection window 412a and window extension period 412b, the snooper 404n protects the transfer of ownership by providing partial responses 406 (e.g., retry partial responses) to other requests that specify the same request address that prevent other masters from taking ownership until ownership is successfully transferred to the master 400. The master 400 may similarly initiate a protection window 413 to protect its coherence ownership of the memory block requested in the request 402 after receiving the combined response 410.

[0039] Because all of the snoopers 404 have limited resources to process the CPU and I / O requests mentioned above, there may be several different levels of Presp and corresponding Cresp. For example, if the snooper in memory controller 106 responsible for the requested memory block has a queue available to process the request, the snooper may respond with a partial response indicating that it can act as the LPC for the request. On the other hand, if the snooper does not have a queue available to process the request, the snooper may respond with a partial response indicating that it is the LPC for the memory block but is currently unable to service the request. Similarly, the snooper 311 in the L2 cache 230 may require an available instance of snoop logic and access to the L2 cache directory 406 to process a request. Lack of access to either (or both) of these resources results in a partial response (and corresponding Cresp) advising that the request cannot be serviced due to lack of the required resources.

[0040] As mentioned above, in systems that implement snoop-based coherence protocols, flush operations (e.g., DCBF and AMO) and clean operations (e.g., DCBST) can be prone to forward progress problems. As described in more detail below with reference to Figures 5 through 7, such forward progress problems can be addressed by having the coherence participant with coherence ownership of the target cache line (i.e., the HPC) transfer coherence ownership of the target cache line to the coherence participant that initiated the flush or clean operation, thereby allowing the initiating coherence participant to initiate a protection window for the target cache earlier than was possible in the prior art.

[0041] 5, a simplified logic flow diagram of an exemplary process by which a master 400 (e.g., RC machine 312) in initiating processing unit 104 performs a flush or clean type memory access operation is shown, according to one embodiment. As indicated above, any number of masters may simultaneously perform their respective flush / clean memory access operations, resulting in target address conflicts. Thus, multiple instances of the process shown in FIG. 5 may occur in a temporally overlapping manner within data processing system 100.

[0042] The process of FIG. 5 begins at block 500 and then proceeds to block 502, which illustrates a master 400 issuing a request 402 for a memory access operation on the system fabric of data processing system 100. In at least some embodiments, a master 400, such as an RC machine 312 of L2 cache 230, issues the request 402 in response to receiving a memory access request from an associated processor core 200 based on execution of a corresponding instruction by an LSU 202. In the described embodiment, the request 402 initiates a memory access operation that belongs to one of several classes or types of operations generally collectively referred to herein as flush / clean (FC) operations. These FC operations, including the DCBF, DCBST, and AMO operations shown in Table I, are all storage-modifying operations that require a modified cached copy of a target memory block to be written back to the corresponding system memory 108.

[0043] As discussed above in the description of FIG. 4, the FC request 402 of the master 400 is received over the system fabric by the L2 caches 230 and memory controllers 106 distributed within the data processing system 100. In response to receiving the FC request 402, these various snoopers 404 generate respective partial responses 406 and communicate the partial responses 406 to appropriate instances of the response logic 218. In one illustrative embodiment, the L2 caches 230 respond to the snooping FC request 402 with one of three Presps: (1) a heavy retry, (2) a lightweight retry, or (3) a null Presp. A heavy retry Presp is provided by an L2 cache 230 that does not currently have access to the coherence state of the target address of the FC request 402 in the directory 308. Additionally, a weighted retry Presp may also be granted by an L2 cache 230 that is designated as the HPC of the target address by its coherence state in the directory 308 but is currently unable to respond to the FC request 402 or is currently processing a request for the target cache line.

[0044] Lightweight retry prep checks if directory 308 is accessible and for which target address L The FC request 402 is given by the L2 cache 230 and indicates either an S state or an S state, and indicates that (1) it is currently processing another conflicting request for the target address, (2) an SN machine 311 cannot be dispatched and there is no SN machine 311 currently active for the target address, or (3) it has already dispatched an SN machine 311 to process the FC request 402.

[0045] It should be appreciated that throughout the period in which the L2 cache 230 has an SN machine 311 actively processing a request for a given target address, the L2 cache 230 will grant a heavy or light retry Presp based on the coherence state associated with the target address when the request was first snooped. The specific actions taken by the L2 cache 230 that hold the target address of an FC request 402 in a dirty (e.g., M or T) HPC coherence state are described in more detail below with reference to FIG. 6. L Actions taken by L2 cache 230 that hold the target address of a flush request in a (S) coherence state are described in more detail below with reference to FIG.

[0046] In response to a snoop of an FC request 402, a memory controller 106 that is not responsible for the target address (i.e., is not an LPC) does not provide a Presp (or provides an empty Presp). A memory controller 106 that is the LPC memory controller for the target address of an FC request 402 provides a Retry_LPC Presp if the memory controller 106 cannot service the FC request 402 due to resource constraints or because the memory controller 106 is already servicing another memory access request that specifies the same address. If the LPC memory controller 106 is able to service the FC request 402, the LPC memory controller 106 protects the target address of the FC request 402 by providing an LPC_Retry Presp for subsequent FC operations (or other operations) until it receives a successful Cresp for the originally snooped FC request 402.

[0047] 5, the process proceeds from block 502 to blocks 504, 505, and 506, which show the master 400 of the FC operation request 402 issued in block 502 waiting to receive a corresponding Cresp 410 from the response logic 218. In at least one embodiment, the response logic 218 can generate the Cresp 410 for the FC operation based on the received Presp of the snooper 404, as shown in Table III below. In at least some embodiments, the DCBST request is L It should be understood that a DCBST request does not receive a lightweight retry Presp (as shown in rows 1, 2, 3, and 5 of Table III) because the Presp is ignored by a cache that holds a target cache line that is in either the S or S state.

[0048] [Table 3]

[0049] In response to receiving Cresp 410, master 400 determines whether Cresp 410 indicates a retry, as shown in rows 2, 3, and 4 of Table III (block 504). If so, the process returns to block 502, which indicates master 400 reissues request 402 for FC operation on the system fabric. If master 400 determines in block 504 that Cresp 410 of request 402 is not a retry, in the embodiment of Table III, the coherence result is HPC_Success (row 1 of Table III), Success_with_cleanup (Success_CU) (row 5 of Table III), or Success (row 6 of Table III). If Cresp 410 is Success (as indicated by negative determinations at both blocks 505 and 506), then either the data processing system does not have a cached copy of the target cache line (in the case of a flush operation) or the data processing system does not have a dirty cache of the target cache line (in the case of a clean operation). In either case, the flush or clean operation is completed successfully and the process of FIG. 5 ends at 520.

[0050] Returning to blocks 505-506, if Cresp 410 indicates HPC_Success or Success_CU, master 400 assumes coherence ownership of the target cache line and opens a protection window 413 in which master 400 protects the target address by causing the conflicting snooped request to receive a heavy retry (block 508). Additionally, master 400 issues a cleanup command on the system fabric to cause modified cache copies of the target memory block present in the HPC cache to be written back to system memory 108 (block 510). Depending on the type of request 402, the cleanup command may also cause other cache copies of the target memory block to be invalidated, such as the BK and BK_Flush commands in Table II. Following block 510, the process of FIG. 5 proceeds to block 512, which illustrates a determination of whether Cresp 410 of the cleanup command indicates Success. If not, the process returns to block 510, which indicates that the master 400 reissues the cleanup command. If a Cresp 410 is received indicating Success for the cleanup command issued in block 510, the master 400 closes the protection window 413, thus terminating protection of the target address (block 514). The process of FIG. 5 then ends at block 520.

[0051] 6, a simplified logical flow diagram of an exemplary process by which a dirty HPC cache processes a snooped request for an FC memory access operation, according to one embodiment, is shown. The method of FIG. 6 focuses on a cache that holds a copy of the target cache line of an FC memory access request in a dirty HPC coherence state, if one exists, because a cache that holds a copy of the target cache line in a non-dirty coherence state will simply ignore the request (in the case of a clean request) or will invalidate its cache's copy of the target cache line (in the case of a flush request).

[0052] The process illustrated in FIG. 6 begins at block 600 and then proceeds to block 602, which illustrates an L2 cache memory 230, which holds a target cache line of an FC memory access operation in a dirty HPC coherence state (e.g., an M or T coherence state), snooping a request for the FC memory access operation from the local interconnect 114. The FC memory access operation may be, for example, a DCBF, DCBST or AMO operation as described above, or other storage modifying FC operation that requires modified cache data to be written back to the system memory 108. In response to snooping the request for the FC memory access operation, the L2 cache memory 230 allocates an SN machine 311 to accommodate the FC memory access operation and sets the SN machine 311 to a busy state so that the SN machine 311 begins protecting the target real address specified by the request. Additionally, L2 cache memory 230 provides an HPC_Ack Presp to the initial request of the FC memory access operation to notify the master of the FC memory access operation that coherence ownership is being transferred to the master of the FC memory access operation.

[0053] While the SN machine 311 is busy, the SN machine 311 performs normal processing for the snooped request (block 604), which includes writing back the modified data of the target cache line to the appropriate system memory 108 via the system fabric and, if required by the FC request 402, invalidating the target cache line in the local directory 308 once the update to the system memory 108 is complete. Additionally, as further shown in block 604, while the SN machine 311 is busy, the L2 cache 230 provides a weighted retry partial response to the snooped request that requires access to the target cache line. The weighted retry partial response causes the appropriate instance of the response logic 218 to form a retry Cresp 410 that forces the master of the conflicting request to reissue the request.

[0054] As indicated by block 606, processing at block 604 continues until processing of the snooped FC request is completed by the SN machine 311. In response to a determination at block 606 that processing of the snooped FC request by the SN machine 311 is completed, the process of FIG.

[0055] Those skilled in the art will appreciate that Figure 6 discloses a technique in which a dirty HPC snooper of a request for an FC memory access operation may transfer coherence ownership of the target cache line of the request to the master of the request, which may then provide coherence protection to the target cache line. In this way, no window of vulnerability is created between the completion of the flush / clean activity performed by the HPC snooper and the acceptance of the request for processing in the LPC. As a result, no other HPC is created for the target cache line until the success of the FC memory access operation is guaranteed.

[0056] 7, a schematic logic flow diagram of an exemplary process for a cache that holds a non-HPC shared copy of the target cache of a snooped flush-type request (e.g., DCBF or AMO) to process the request is shown in accordance with one embodiment. It should be appreciated that clean requests are ignored by caches that hold a shared copy of the target cache of a clean (e.g., DCBST) request.

[0057] The process of FIG. 7 begins at block 700 and proceeds to block 702, which illustrates the L2 cache 230, which holds the target cache line of a flush-type request, snooping an initial request for a flush-type operation (e.g., DCBF or AMO) or an associated cleanup command (e.g., BK or BK_FLUSH). In response to snooping the initial request or cleanup command, the L2 cache 230 provides a lightweight retry response. Further, in response to the initial request, the L2 cache 230 allocates an SN machine 311 to process the initial request. The allocated SN machine 311 transitions from an idle state to a busy state and begins protecting the target cache line.

[0058] At block 704, the SN machine 311 assigned to process the snooped request at block 702 performs normal processing of the initial request or cleanup command by invalidating the target cache line in the local directory 308. As further shown in block 704, while the SN machine 311 is busy, the L2 cache 230 provides a lightweight retry partial response to any snooped requests that require access to the target cache line. At block 706, it is determined whether the SN machine 311 has completed processing the snooped request. If not, the process of FIG. 7 returns to block 704 as discussed above. However, if it is determined that the SN machine 311 has completed processing the snooped request, the SN machine 311 returns to an idle state (block 708) and the process of FIG. 7 ends at block 710.

[0059] Referring now to FIG. 8, a block diagram of an exemplary design flow 800 for use, for example, in semiconductor IC logic design, simulation, testing, layout, and manufacturing is shown. The design flow 800 includes a process, machine, or mechanism, or combination thereof, for generating a logical or other functionally equivalent representation of the design structures and / or devices described above and shown in FIGS. 1-3. The design structures processed and / or generated by the design flow 800 may be encoded on a machine-readable transmission or storage medium to include data and / or instructions that, when executed or otherwise processed on a data processing system, generate a logical, structural, mechanical or other functionally equivalent representation of a hardware component, circuit, device, or system. The machine includes, but is not limited to, any machine used in an IC design process, such as designing, manufacturing, or simulating a circuit, component, device, or system. For example, a machine includes a lithography machine, a machine or equipment for generating a mask (e.g., an electron beam writer), a computer or equipment for simulating a design structure, any apparatus used in a manufacturing or testing process, or any machine for programming a functionally equivalent representation of a design structure into any medium (e.g., a machine for programming a programmable gate array).

[0060] Design flow 800 may differ depending on the type of representation being designed. For example, a design flow 800 for creating an application specific integrated circuit (ASIC) may differ from a design flow 800 for designing a standard component, or for implementing a design in a programmable array, such as a programmable gate array (PGA) or field programmable gate array (FPGA) offered by Altera® or Xilinx®.

[0061] FIG. 8 illustrates a number of such design structures, including an input design structure 820, which is preferably processed by the design process 800. The design structure 820 may be a logical simulation design structure generated and processed by the design process 800 to create a logically equivalent functional representation of a hardware device. The design structure 820 may additionally or alternatively include data and / or program instructions that, when processed by the design process 800, generate a functional representation of the physical structure of the hardware device. Whether representing functional and / or structural design features, the design structure 820 may be generated using electronic computer-aided design (ECAD), such as implemented by a core developer / designer. Once encoded on a machine-readable data transmission, gate array, or storage medium, the design structure 820 is accessible and processable by one or more hardware and / or software modules in the design process 800 to functionally represent, by simulation or otherwise, an electronic component, circuit, electronic or logic module, apparatus, device, or system, such as those shown in FIGS. 1-3. Thus, design structure 820 may include files or other data structures, including human and / or machine readable source code, compiled structures, and computer executable code structures that, when processed by a design or simulation data processing system, functionally simulate or otherwise represent a circuit or other level hardware logic design. Such data structures may include hardware description language (HDL) design entities or other data structures that conform to or are compatible with low-level HDL design languages, such as Verilog and VHDL, and / or high-level design languages, such as C or C++.

[0062] Design process 800 preferably employs and incorporates hardware and / or software modules for synthesizing, transforming or otherwise processing design / simulation functional equivalents of components, circuits, devices or logic structures shown in FIGS. 1-3 to generate netlist 880, which may include design structures such as design structure 820. Netlist 880 may include compiled or otherwise processed data structures representing lists of wiring, discrete components, logic gates, control circuits, I / O devices, models, etc., that describe connections to other elements and circuits in an integrated circuit design. Netlist 880 may be synthesizable using an iterative process in which netlist 880 is resynthesized one or more times depending on the design specifications and parameters of the device. As with the other design structure types described herein, netlist 880 may be recorded on a machine-readable storage medium or programmed into a programmable gate array. The medium may be a non-volatile storage medium such as a magnetic or optical disk drive, a programmable gate array, a compact flash or other flash memory, etc. Additionally or alternatively, the medium may be system memory or a cache memory, or a buffer area.

[0063] The design process 800 may include hardware and software modules for processing various input data structure types, including netlist 880. Such data structure types may be present, for example, in library elements 830 and may include sets of commonly used elements, circuits and devices, including models, layouts and symbolic representations for a given manufacturing technology (e.g., different technology nodes, 32 nm, 45 nm, 80 nm, etc.). The data structure types may further include design specifications 840, characterization data 850, verification data 860, design rules 870, input test patterns, and test data files 885 including output test results and other test information. The design process 800 may further include standard mechanical design processes, such as, for example, stress analysis, thermal analysis, mechanical event simulation, process simulation of operations such as cast, mold and die press formation. Those skilled in the art will recognize the range of possible mechanical design tools and applications that may be used in the design process 800 without departing from the scope and spirit of the present invention. Design process 800 may also include modules for performing standard circuit design processes such as timing analysis, verification, design rule checking, and place-and-route operations.

[0064] The design process 800 employs and incorporates logical and physical design tools, such as HDL compilers and simulation model creation tools, to process the design structure 820 along with some or all of the illustrated supporting data structures, in addition to any additional mechanical design or data (if applicable) to generate a second design structure 890. The design structure 890 resides on a storage medium or program gate array in a data format used for the exchange of mechanical device and structure data (e.g., IGES, DXF, Parasolid XT, JT, DRG or any other suitable format for storing or rendering such mechanical design structures). Like the design structure 820, the design structure 890 preferably resides on a transmission or data storage medium and includes one or more files, data structures or other computer-encoded data or instructions that, when processed by an ECAD system, generate a logical or other functionally equivalent form of one or more of the embodiments of the present invention illustrated in Figures 1-3. In one embodiment, the design structure 890 may include a compiled executable HDL simulation model that functionally simulates the device illustrated in Figures 1-3.

[0065] Design structure 890 may also employ data formats used for the exchange of integrated circuit layout data, and / or symbolic data formats (e.g., information stored in GDSII (GDS2), GL1, OASIS, map files, or any other suitable format for storing such design data structures). Design structure 890 may include, for example, symbolic data, map files, test data files, design content files, manufacturing data, layout parameters, wires, metal levels, vias, shapes, data for routing manufacturing lines, and any other data required by a manufacturer or other designer / developer to manufacture a device or structure such as those described above and shown in FIGS. 1-3. Design structure 890 may then proceed to stage 895, for example, design structure 890 may proceed to tape-out, be shipped for manufacturing, be given to a mask house, be sent to another design house, be sent back to a customer, etc.

[0066] As described above, in at least one embodiment, a cache memory includes a data array, a directory of contents of the data array specifying coherence state information, and snoop logic that processes operations snooped from the system fabric by referencing the data array and the directory. The snoop logic is responsive to a snoop on the system fabric of an initiating coherence participant's request for a flash memory access operation or a clean memory access operation to determine whether the directory indicates that the cache memory has coherence ownership of a target address of the request. Based on a determination that the directory indicates that the cache memory has coherence ownership of the target address, the snoop logic provides a coherence response to the request that transfers coherence ownership of the target address to the initiating coherence participant such that the initiating coherence participant can protect the target address from conflicting requests.

[0067] While various embodiments have been specifically shown and described, it will be understood by those skilled in the art that various changes can be made in form and detail of the embodiments without departing from the spirit and scope of the appended claims, and all such alternative implementations are intended to be included within the scope of the appended claims.

[0068] The flowcharts and block diagrams in the drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions noted in the blocks may occur in a different order than that noted in the figures. For example, two blocks shown in succession may in fact be executed substantially in parallel, or the blocks may be executed in reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, may be implemented by a dedicated hardware-based system that performs the specified functions or operations, or may embody a combination of dedicated hardware and computer instructions.

[0069] Although aspects have been described in terms of a computer system executing program code that directs the functions of the invention, it should be understood that the invention may alternatively be implemented as a program product including a computer readable storage device that stores program code processable by a processor of a data processing system to cause the data processing system to perform the functions described. Computer readable storage devices may include volatile or non-volatile memory, optical or magnetic disks, and the like, but do not include non-statutory subject matter such as propagating signals per se, transmission media per se, and energy forms per se.

[0070] As an example, the program product may include data and / or instructions that, when executed or otherwise processed on a data processing system, result in a logical, structural or otherwise functionally equivalent representation (including a simulation model) of a hardware component, circuit, device or system disclosed herein. Such data and / or instructions may include Hardware Description Language (HDL) design entities or other data structures that conform to or are compatible with low-level HDL design languages ​​such as Verilog and VHDL, or high-level design languages ​​such as C or C++. The data and / or instructions may also employ data formats used for the exchange of integrated circuit layout data, or symbolic data formats (e.g., information stored in GDSII (GDS2), GL1, OASIS, map files, or any other suitable format for storing such design data structures).

Claims

1. 1. A cache memory for an associated one of a plurality of processor cores in a multiprocessor data processing system, the multiprocessor data processing system including a system fabric communicatively coupling the cache memory to a memory controller of a system memory for receiving operations over the system fabric, the cache memory comprising: The data array, a directory of the contents of said data arrays, including coherence state information; snoop logic for processing operations snooped from the system fabric by referencing the data array and the directory; The snoop logic includes: in response to a snoop on the system fabric of an initiating coherence participant's request for a flash memory access operation or a clean memory access operation, the request specifying a target address; determining whether the directory indicates that the cache memory has coherent ownership of the target address; based on a determination that the directory indicates that the cache memory has coherence ownership of the target address, providing a coherence response to the request that transfers coherence ownership of the target address to the initiating coherence participant such that the initiating coherence participant can protect the target address from conflicting requests. Cache memory.

2. 2. The cache memory of claim 1, wherein the snoop logic is configured to protect the target address from a conflicting memory access request by issuing a retry coherence response to the conflicting memory access request.

3. 3. The cache memory of claim 2, wherein the snoop logic terminates protection of the target address in response to completing processing of the request.

4. 2. The cache memory of claim 1, wherein the cache memory provides the coherence response based on the directory indicating that a copy of the memory block associated with the target address held in the data array has been modified compared to the system memory.

5. 2. The cache memory of claim 1, wherein the flush memory access operation is a flush operation that causes modified data associated with the target address to be written to the system memory and causes cached copies of memory blocks associated with the target address to be invalidated.

6. A cache memory according to claim 1; and at least one associated processor core coupled to said cache memory.

7. A system fabric; and a plurality of processing units according to claim 6 all coupled to said system fabric.

8. 1. A method of data processing in a multiprocessor data processing system including a cache memory of an associated one of a plurality of processor cores in the multiprocessor data processing system, the multiprocessor data processing system including a system fabric communicatively coupling the cache memory and a memory controller of the system memory for receiving operations over the system fabric, the method comprising: snooping, by the cache memory, on the system fabric, of an initiating coherence participant's request for a flash memory access operation or a clean memory access operation, the request specifying a target address; in response to snooping the request, the cache memory determining whether a directory of the cache memory indicates that the cache memory has coherent ownership of the target address; based on a determination that the directory indicates that the cache memory has coherence ownership of the target address, providing a coherence response to the request that transfers coherence ownership of the target address to the initiating coherence participant such that the initiating coherence participant can protect the target address from conflicting requests; A method comprising:

9. 9. The method of claim 8, further comprising the cache memory protecting the target address from conflicting memory access requests by issuing a retry coherence response to the conflicting memory access requests.

10. 10. The method of claim 9, wherein the cache memory ceases protecting the target address in response to completing processing of the request.

11. 9. The method of claim 8, wherein the cache memory provides the coherence response based on the directory indicating that a copy of the memory block associated with the target address held in a data array has been modified compared to the system memory.

12. 9. The method of claim 8, wherein the initiating coherence participant, in response to receiving coherence ownership of the target address, issues at least one cleanup command on the system fabric to cause system memory to be updated with modified data associated with the target address.

13. the request is for a flash memory access operation requesting that modified data associated with the target address be written to the system memory and that cached copies of memory blocks associated with the target address be invalidated; 13. The method of claim 12, wherein the at least one cleanup command further causes invalidation of at least one cached copy of a memory block associated with the target address.

14. 1. A design structure for the design, manufacture or testing of an integrated circuit, tangibly embodied in a machine-readable storage device and configured to be executed on a computer that simulates logic of said integrated circuit, comprising: a simulation model of the processing unit, the simulation model being executed on a computer simulating the logic of the integrated circuit to simulate the functioning of the processing unit, the processing unit including a processor core and a cache memory; The cache memory includes: The data array, a directory of the contents of said data arrays, including coherence state information; snoop logic for processing operations snooped from a system fabric by referencing said data array and said directory; The snoop logic includes: in response to a snoop on the system fabric of an initiating coherence participant's request for a flash memory access operation or a clean memory access operation, the request specifying a target address; determining whether the directory indicates that the cache memory has coherent ownership of the target address; based on a determination that the directory indicates that the cache memory has coherence ownership of the target address, providing a coherence response to the request that transfers coherence ownership of the target address to the initiating coherence participant such that the initiating coherence participant can protect the target address from conflicting requests. Design structure.

15. 15. The design structure of claim 14, wherein the snoop logic is configured to protect the target address from a conflicting memory access request by issuing a retry coherence response to the conflicting memory access request.

16. 16. The design structure of claim 15, wherein the snoop logic ceases protecting the target address in response to completing processing of the request.

17. 15. The design structure of claim 14, wherein the cache memory provides the coherence response based on the directory indicating that a copy of the memory block associated with the target address held in the data array has been modified compared to a system memory.

18. 15. The design structure of claim 14, wherein the flush memory access operation is a flush operation that causes modified data associated with the target address to be written to a system memory and that causes cached copies of memory blocks associated with the target address to be invalidated.

Images