Cache snooping mode to extend coherency protection on demand

Abstract

The cache memory includes a data array, a directory of the contents of the data array that specifies coherence state information, and snoop logic that processes operations snooped from the system fabric with reference to the data array and directory. The snoop logic responds to snooping on the system fabric a request for a flush / clean memory access operation from one of multiple processor cores that specifies a target address by servicing the request and then entering reference mode. While in referee mode, the snoop logic protects the memory block identified by the target address against conflicting memory access requests by multiple processor cores, such that no other coherence participants are allowed to assume coherence ownership of the memory block.

Description

[Technical field]

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

[0002] A conventional multiprocessor (MP) computer system, such as a server computer system, includes multiple processing units all coupled to a system interconnect that typically includes one or more address, data, 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 processing units. To reduce access latency to instructions and data resident in the system memory, each processing unit is typically further supported by a respective multilevel cache hierarchy, the lower of which may be shared by one or more processor cores.

[0003] Cache memories are commonly utilized to temporarily buffer memory blocks that may be accessed by a processor to speed up processing by reducing the access latency introduced by having to load the required data and instructions from the system memory. In some MP systems, the cache hierarchy includes at least two levels. Level 1 (L1) or higher caches are typically private caches 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, a processor core first accesses the directory of the higher cache. If the requested memory block is not found in the higher cache, the processor core accesses a lower cache (e.g., Level 2 (L2) or Level 3 (L3) cache) for the requested memory block. The lowest cache (e.g., L2 or L3) may 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 ensure at least a minimum level of coherency between the various processor cores' "views" of the contents of system memory. In particular, cache coherency requires, at a minimum, that a hardware thread cannot access the stale copy of a memory block again after accessing a copy of the memory block and subsequently accessing the updated copy of the memory block.

[0005] Some MP systems support flush and clean operations that copy modified cache lines associated with the target address of a flush or clean operation from a specific cache hierarchy that contains the cache line in a coherence state indicating write permission (sometimes referred to herein as the "HPC state") back to system memory, if present. For a clean operation, the target cache line is also transitioned to an unmodified HPC coherence state. For a flush operation, the target cache line in the HPC state is transitioned to an invalid coherence state, if present, whether modified or not. A flush operation additionally requires any other copy or copies of the target cache line in a non-HPC state to be invalidated in all cache hierarchies of the MP system. This invalidation may not be completed if the cache that holds the target cache line in the HPC state, if present, has not completed its processing.

[0006] In MP systems that maintain coherency via a snoop-based coherence protocol, a flush or clean operation is typically broadcast on the MP system's system interconnect and will receive a Retry coherence response unless any caches that hold the target cache line in an HPC state have 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 any caches that hold the target cache line in an HPC state have completed processing 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 has not yet been created (in modified HPC state for a clean operation and modified or unmodified HPC state for a flush operation), 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 cached copies of the line exist) or a coherence response that transfers responsibility to the initiating coherence participant for invalidating any remaining non-HPC cached copies of the target cache line. In either of these cases of flush operations, the flush operation may be considered "successful" in the sense that it has either completed completely or has completed when one or more remaining non-HPC copies of the target cache line have been invalidated by the initiating coherence participant (e.g., via issuance of a kill operation).However, if another coherence participant creates a new copy of the target cache line in the relevant 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, then the subsequent reissue of the flush or clean operation will again 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 exacerbated 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 via a designated coherence participant extending a protection window for the target cache line.

[0008] According to one aspect of the invention, a cache memory is provided that includes a data array, a directory of contents of the data array that specify coherence state information, and snoop logic that processes operations snooped from a system fabric with reference to the data array and directory. In response to snooping on the system fabric a request for a flush or clean memory access operation of one of a plurality of processor cores that specifies a target address, the snoop logic services the request and then enters a referee mode. While in the referee mode, the snoop logic protects a memory block identified by the target address against conflicting memory access requests by the plurality of processor cores such that no other coherence participants are permitted to assume coherence ownership of the memory block. [Brief description of the drawings]

[0009] [Figure 1] FIG. 1 illustrates a high-level block diagram of an exemplary data processing system in accordance with 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 of a lower level cache according to one embodiment. [Figure 4] FIG. 2 is an exemplary timing diagram of processor memory access operations according to one embodiment. [Diagram 5] 4 is a high-level logic flowchart of an exemplary process by which a processing unit performs flush / clean memory access operations, according to one embodiment. [Figure 6] 1 is a high-level logic flowchart of an exemplary process by which a cache that has coherent ownership of a target cache line of a snooped flush or clean type request handles the request, according to one embodiment. [Figure 7]4 is a timing diagram of an exemplary flush / clean memory access operation according to one embodiment. [Figure 8] 1 is a high-level logic flowchart of an exemplary process by which a cache that holds a non-HPC shared copy of the target cache of a snooped flush-type request handles the request, according to one embodiment. [Figure 9] FIG. 1 is a data flow diagram illustrating a design process. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] Referring now to the drawings, wherein like reference numerals refer to like and corresponding parts throughout, and specifically to FIG. 1, a high level block diagram illustrating an exemplary data processing system 100 according to one embodiment is shown. In the illustrated embodiment, data processing system 100 is a cache coherent multiprocessor (MP) data processing system that includes multiple processing nodes 102 that process 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 bussed interconnect, a switched interconnect, or a hybrid interconnect.

[0011] In the illustrated embodiment, each processing node 102 is implemented as a multi-chip module (MCM) that includes four processing units 104, each preferably implemented as a respective integrated circuit. The processing units 104 in each processing node 102 are communicatively connected to one another and to 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.

[0012] 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 to a respective system memory 108. Data and instructions resident in the system memory 108 may generally be accessed, cached, and modified by a processor core in any processing unit 104 of any processing node 102 in the data processing system 100. As such, 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 of the memory controllers 106 (and the system memory 108) may be coupled to the system interconnect 110 rather than to the local interconnect 114.

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

[0014] 2, a more detailed block diagram of an exemplary processing unit 104 according to one embodiment is shown. 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 executing instructions, such as an LSU 202 that executes memory access instructions that request access to memory blocks or generates requests for access to memory blocks. In at least some embodiments, each processor core 200 is capable of simultaneously executing multiple hardware threads of execution.

[0015] The operation of each processor core 200 is supported by a multi-level memory hierarchy having at the bottom a shared system memory 108 accessed via an integrated memory controller 106. Above that, the memory hierarchy includes one or more levels of cache memory, which in an exemplary embodiment includes a store-through level 1 (L1) cache 226 within and dedicated to each 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 implement multiple L2 cache slices, with each L2 cache slice handling memory access requests for a respective set of real memory addresses.

[0016] Although the illustrated cache hierarchy includes only two levels of cache, those skilled in the art will appreciate that alternative embodiments include additional levels (e.g., L3, L4, etc.) of on-chip or off-chip inline or look-aside caches that may or may not contain the contents of the higher caches in full, in part, or in part.

[0017] With further reference to FIG. 2, each processing unit 104 further includes a unified and distributed fabric controller 216 responsible for controlling the flow of operations onto the local interconnect 114 and the system interconnect 110, and response logic 218 for determining a coherency response to a memory access request utilized by a selected cache coherency protocol.

[0018] In operation, when a hardware thread under execution by processor core 200 includes a memory access instruction that requests a specified memory access operation to be performed, LSU 202 executes the memory access instruction to determine a target real address to be accessed. If the requested memory access cannot be fully executed by reference to L1 cache 226 of the executing processor core 200, processor core 200 generates a memory access request including at least a request type and a target real address, for example, and issues the memory access request to its associated L2 cache 230 for processing.

[0019] 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 the system memory (real) address. The particular memory blocks stored within a cache line of cache array 302 are recorded in cache directory 308, which includes one directory entry for each 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 real 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 for the cache line with reference to other cache lines in the same congruence class, and a global field that indicates whether the memory block is held in the associated L1 cache 226.

[0020] The L2 cache 230 includes a plurality of (e.g., 16) read-claim (RC) machines 312a-312n) for independently and simultaneously servicing memory access requests received from an associated processor core 200. To service remote memory access requests originating from processor cores 200 other than the associated processor core 200, the L2 cache 230 also includes a plurality of snoop (SN) machines 311a-311m. Each SN machine 311 can independently and simultaneously handle remote memory access requests, “snoops,” from the local interconnect 114. As will be appreciated, servicing of memory access requests by the RC machines 312 may require replacement or invalidation of memory blocks in the cache array 302. Thus, the L2 cache 230 includes a CO (castout) machine 310 that manages the removal and write-back of memory blocks from the cache array 302.

[0021] The L2 cache 230 further includes an arbiter 305 that controls multiplexers M1-M2 to direct the 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 according to an arbitration policy implemented by the arbiter 305 to dispatch logic 306, which processes memory access requests with respect to the directory 308 and cache array 302 for a given number of cycles.

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

[0023] Each RC machine 312 is also assigned a respective one of a number 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 buffers 322 assigned to each RC machine 312 are preferably constructed with connections and functionality corresponding to memory access requests that may be serviced by the associated RC machine 312. The RCDAT buffers 322 have 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.

[0024] In operation, a processor store request including a request type (t type), 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 one of its input requests for forwarding to multiplexer M2, which receives as input a remote request received from the local interconnect 114 via a remote request path 326. The arbiter 305 schedules local and remote memory access requests for processing and generates a sequence 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 be processed.

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

[0026] The operation begins with a request phase 450 in which a master 400, such as the RC machine 312 of the L2 cache 230, issues a request 402 onto the system fabric. The request 402 preferably includes at least a request type indicating the type of access desired and a resource identifier (e.g., a real address) indicating the resource to be accessed by the request. The request preferably includes those shown in Table I below.

[0027] [Table 1]

[0028] The request 402 is received by snoopers 404a-404n distributed in the data processing system 100, such as the SN machines 311a-311m of the L2 caches 230 and a snooper (not shown) in the memory controller 106. For a READ type request, 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 only sent on the system fabric 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., 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.

[0029] Operation continues with a partial response phase 455. During the partial response phase 455, each snooper 404 receiving and processing 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 integrated memory controller 106 determines its partial response 406 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 L2 cache 230 may determine its partial response 406 based on, for example, the availability of an L2 cache directory 308, the availability of a snoop logic instance 311 in the snooper 404 to handle the request, and a coherence state, if any, associated with the request address in L2 cache directory 308.

[0030] Operation continues with a combined response phase 460. During the combined response phase 460, the partial responses 406 of the snoopers 404 are logically combined, either incrementally or 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 assumed hereinafter, 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, Cresp 410 may indicate, for example, the data source for 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 (if applicable) to invalidate cached copies of the requested memory block in one or more L2 caches 230.

[0031] In response to receiving the combined response 410, one or more masters 400 and 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 coherency state of data cached in one or more L2 caches 230, performing castout operations, writing data to system memory 108, etc. If required by the request 402, the requested or target memory block may be transmitted to one of the masters 400 or snoopers 404 before or after generation of the combined response 410 by the response logic 218.

[0032] In the following description, the partial response 406 of the snooper 404 to a request 402, and the operations and / or combined response 410 performed by the snooper 404 in response to the request 402 are described with reference to the snooper being the highest point of coherency (HPC), the lowest point of coherency (LPC), or neither for the request address specified by the request. The LPC is defined herein as a memory device or I / O device that serves as the final repository for a memory block. If no caching participants hold a copy of the memory block, the LPC holds the only image of the memory block. If there is no HPC caching participant for the memory block, the LPC has the sole authority to grant or deny a request to modify the memory block. Furthermore, the LPC provides data for a request to read or modify the memory block if the LPC data is current and no caching participant can provide the data. If a caching participant has a more current copy of the data but cannot provide it for the request, the LPC does not provide the stale data and the request is retried. For a typical requirement in the embodiment of data processing system 100 shown in FIGS. 1-3, the LPC is a memory controller 106 for system memory 108 that holds the referenced memory block.

[0033] The 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 grant or deny a request to modify the memory block. Descriptively, the HPC also provides a copy of the memory block to the requester in response to any request to read or modify the memory block (cache-to-cache transfers are faster than LPC-to-cache transfers) (even though that copy may match the main memory behind the LPC). Thus, for a typical request in an embodiment of a data processing system, the HPC is the L2 cache 230, if present. Although other indicators may be utilized to indicate HPC for a memory block, the preferred embodiment indicates HPC for a memory block using a selected cache coherence state, if present, in the L2 cache directory 308 of the L2 cache 230. In a preferred embodiment, the coherency states in the coherency protocol, in addition to (1) providing an indication for a memory block of whether a cache is HPC or not, also indicate (2) whether the cached copy is unique (i.e., whether the only cached copy system-wide or not), (3) whether and when the cache can provide a copy of the memory block to a master requesting the memory block for a phase of operation, and (4) whether the cached image of the memory block matches the corresponding memory block in the LPC (system memory). These four attributes can be represented, for example, by an exemplary variation of the well-known MESI (Modified, Exclusive, Shared, Invalidate) protocol summarized in Table II below. Further information regarding coherency protocols can be found, for example, in U.S. Pat. No. 7,389,388, which is incorporated herein by reference.

[0034] [Table 2]

[0035] Table II above lists the T, Te, and S states, which are all "shared" coherency 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. L There are three states: HPC, Tx, and S. 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 that supplied 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 the 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) serves as a cache data source of last resort (post-Cresp) for a query-only copy of that cache line in that the cache memory will only supply a query-only copy to another cache memory if there is no cache memory that holds the cache line in the SL state that can serve as a data source (pre-Cresp).

[0036] S L A state is formed in the cache memory in response to a cache memory receiving a query-only copy of the cache line from the 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 has the ability to provide a query-only copy of that cache line to another cache memory, and can do so before the receipt of Cresp. L In response to providing a query-only copy of the cache line to the cache memory (assuming the coherency state), the cache memory that provides the query-only copy of the cache line updates its coherency state for the cache line to S LUpdate from to S. Therefore, S L The implementation of the coherence state may allow multiple query-only copies of frequently queried cache lines to be created throughout a multiprocessor data processing system, advantageously reducing the latency of query-only accesses to those cache lines.

[0037] 4, the HPC, if any, for the memory block referenced in request 402, or, in the absence of an HPC, the LPC of the memory block, is preferably responsible for protecting the transfer of coherence ownership of the memory block as necessary in response to request 402. In the exemplary scenario illustrated in FIG. 4, the snooper 404n for the memory block specified by the request address of request 402 protects the transfer of coherence ownership of the requested memory block to master 400 during a protection window 412a that extends from when snooper 404n determines its partial response 406 until snooper 304n receives the combined response 410, or during a subsequent window extension 412b that extends a programmable time beyond receipt by snooper 404n of the combined response 410. During protection window 412a and window extension 412b, snooper 404n protects the transfer of ownership by providing partial responses 406 to other requests that specify the same request address that prevent other masters from obtaining ownership (e.g., Retry partial responses) until ownership is successfully transferred to master 400. Master 400 can similarly initiate a protection window 413 to protect coherence ownership of the memory block requested in request 402 following receipt of combined response 410.

[0038] Because all of the snoopers 404 have limited resources to handle the above CPU and I / O requests, several different levels of Presp and corresponding Cresp are possible. For example, if the snooper in memory controller 106 responsible for the requested memory block has a queue available to handle the request, the snooper can 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 handle the request, the snooper can 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 L2 cache 230 needs an available instance of snoop logic to handle the request, and may need access to the L2 cache directory 406. Without access to either (or both) of these resources, the partial response (and corresponding Cresp) signals that the request cannot be serviced because the requested resource does not exist.

[0039] As noted above, in systems that implement snoop-based coherence protocols, flush operations (e.g., DCBF and AMO) and clean operations (e.g., DCBST) can have forward progress problems in a window of vulnerability between the finalization of the flush / clean operation in the cache hierarchy that contains the target cache line in the HPC state, if any, and the master of the flush / clean request that initiates the final successful flush / clean request. As described in more detail below with reference to Figures 5-8, these forward progress problems can be addressed by coherence participants having coherence ownership of the target cache line (i.e., HPC) that extends the protection window for the target cache line.

[0040] 5, a high-level logic flow diagram of an exemplary process by which a master 400 (e.g., RC machine 312) within a processing unit 104 performs a flush or clean type memory access operation according to one embodiment is shown. As discussed above, any number of masters may simultaneously perform their own respective flush / clean memory access operations to potentially conflicting target addresses. Thus, multiple instances of the process shown in FIG. 5 may execute overlapping in time within data processing system 100.

[0041] 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 generally belongs to one of several classes or types of operations collectively referred to herein as flush / clean (FC) operations. These FC operations, which include DCBF, DCBST, and AMO referenced in Table I, are full storage modification operations that require any modified cached copies of the target memory block to be written back to the associated system memory 108.

[0042] 4, the FC request 402 of the master 400 is received on 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 associated instances of response logic 218. In an exemplary embodiment, the L2 caches 230 respond to snooping the FC request 402 with one of three Presps: (1) Heavyweight Retry, (2) Lightweight Retry, or (3) Null. The Heavyweight Retry Presp is provided by the L2 caches 230 that do not currently have access to the coherence state of the target address of the FC request 402 in their directory 308. Additionally, a Weighted Retry Presp may also be provided by the L2 cache 230, which is designated by a coherence state in its directory 308 as HPC for the target address, but is unable to respond to the FC request 402 at this time or is currently busy processing a request for the target cache line.

[0043] A lightweight Retry Presp is provided by the L2 cache 230, where the directory 308 of the L2 cache 230 is accessible and indicates either the SL or S state for the target address and (1) another conflicting request for the target address is currently being processed, or (2) an SN machine 311 cannot be dispatched and there is no SN machine 311 currently active for the target address, or (3) an SN machine 311 has already been dispatched to process the FC request 402.

[0044] It should be understood that for all intervals in which the L2 cache 230 has an SN machine 311 actively processing requests for a given target address, the L2 cache 230 provides a heavyweight or lightweight Retry Presp based on the coherence state associated with the target address when the request was first snooped. Specific actions performed by an L2 cache 230 holding a target address of an FC request 402 in a dirty (e.g., M or T) HPC coherence state are described in detail below with reference to FIG. 6. Actions performed by an L2 cache 230 holding a target address of a flush request in a shared (e.g., Te, SL, or S) coherence state are described in detail below with reference to FIG.

[0045] In response to snooping an FC request (402), a memory controller 106 that is not responsible for the target address (i.e., not an LPC) does not provide a Presp (or a Null 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 due to the memory controller 106 already servicing another memory access request that specifies the same address. If the LPC memory controller 106 can 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 to subsequent FC operations (or other operations) until it receives a successful Cresp for the original snooped FC request 402.

[0046] 5, the process proceeds from block 502 to blocks 504-506, which illustrate the master 400 of the request 402 for the FC operation 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. It should be noted that in at least some embodiments, the DCBST request does not receive a lightweight Retry Presp (as shown in rows 1, 2, and 4 of Table III) because the DCBST request is ignored by caches that hold the target cache line in either the SL and S states.

[0047] [Table 3]

[0048] In response to receiving Cresp 410, master 400 determines whether Cresp 410 indicates Retry (block 504), as shown in the first three rows of Table III. If so, the process returns to block 502, which shows master 400 reissuing request 402 for the FC operation on the system fabric. If master 400 determines in block 504 that Cresp 410 of request 402 is not Retry, in the embodiment of Table III, the coherence result is either Success_with_cleanup (Success_CU) (fourth row of Table III) or Success (fifth row of Table III). If Cresp 410 is Success (as indicated by a negative determination in block 506), the flush or clean operation is successfully completed, and the process of FIG. 5 ends at 520.

[0049] However, if Cresp 410 indicates Success_CU, master 400 begins protecting the target address by opening a protection window 413 and causing any conflicting snooped requests to receive a weight Retry (block 508). Additionally, master 400 issues a cleanup command on the system fabric to write the modified cached copy of the target memory block that resides in the HPC cache back to system memory 108 (block 510). Depending on the type of request 402, the cleanup command may additionally cause any other cached copy or copies of the target memory block to be invalidated, similar to the BK and BK_Flush commands included 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 illustrates master 400 reissuing the cleanup command. If a Cresp 410 is received indicating Success for the cleanup command issued in block 510, the master 400 ends protection for the target address by closing the protection window 413 (block 514). The process of FIG. 5 then ends in block 520.

[0050] 6, there is shown a high level logic flowchart of an exemplary process by which an HPC cache handles snooped requests for FC memory access operations according to one embodiment. To facilitate a better understanding, the flowchart of FIG. 6 will be described in conjunction with timing diagram 700 of FIG.

[0051] The process illustrated in FIG. 6 begins at block 600 and then proceeds to block 602, which illustrates the L2 cache memory 230 holding the target cache line of the FC memory access operation in a dirty HPC coherence state (e.g., 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 previously described, or any other storage modification FC operation that requires modified cached 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 service 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. 7 illustrates, at 702, the transition of an SN machine 311 assigned to service a request for an FC memory access operation from an idle state to a busy state. Additionally, the L2 cache memory 230 provides a weighted Retry Presp to the request for the FC memory access operation because the modified data from the target cache line has not yet been written to the system memory 108.

[0052] While the SN machine 311 is busy, the SN machine 311 performs normal processing on the snooped request (block 604). This normal processing includes writing the modified data of the target cache line back to the associated system memory 108 via the system fabric and invalidating the target cache line in the local directory 308 as required by the FC request 402 when the update to the system memory 108 is complete. Also, as further described in block 604, while the SN machine 311 is busy, the L2 cache 230 provides a heavyweight Retry partial response to the snooped request requiring access to the target cache line, as shown in FIG. 7 at 704. The heavyweight Retry partial response causes an associated instance of the response logic 218 to form a Retry Cresp 410 that causes the master of the conflicting request to reissue its request.

[0053] In some embodiments, the SN machine 311 assigned to the request for the FC memory access operation automatically sets the REF (referee) mode indicator (as shown in block 608 of FIG. 6 and reference numeral 706 of FIG. 7) based on snooping the request for the FC memory access operation. In another embodiment, represented by optional block 606 of FIG. 6, while the SN machine 311 is busy requesting the FC memory access operation, the SN machine 311 conditionally sets the REF mode indicator in block 608 only if a conflicting request for a non-FC operation has been snooped by the L2 cache 230. Following block 608, or if optional block 606 is implemented, after it has been determined that there are no conflicting non-FC requests being snooped, in block 610, it is determined whether the processing of the snooped FC request by the SN machine 311 has been completed. If not, the process of FIG. 6 returns to block 604 as described. However, if it is determined that processing of the snooped FC request by the SN machine 311 is complete, as illustrated at reference numeral 708 in FIG. 7, then the process of FIG. 6 proceeds from block 610 to block 612.

[0054] At block 612, the SN machine 311 is shown determining whether the REF mode indicator is set after completing processing of the FC operation. If not, the SN machine 311 returns to an idle state, as illustrated in FIG. 6 at block 614 and in FIG. 7 at reference numeral 710. Following block 614, the process of FIG. 6 ends at block 616. Returning to block 612, if the SN machine 311 determines that the REF mode indicator is set, the SN machine 311 does not return to an idle state upon completing processing of the FC operation request, but instead enters a REF (referee) mode that extends protection of the target cache line, as illustrated at block 620 of FIG. 6 and reference numeral 712 of FIG. 7. In connection with entering the REF mode, the SN machine 311 also starts a REF mode timer, in one embodiment.

[0055] Following block 620, processing of the SN machine 311 enters a processing loop in which the SN machine 311 monitors for the first occurrence of the expiration of a REF mode timer and the receipt of a REF mode exit request for an FC class of operation, as illustrated in blocks 640 and 642, respectively. During this processing loop, the SN machine 311 monitors on the system fabric for any conflicting non-FC operations targeting the same cache line as the snooped FC request, as illustrated in block 622 of FIG. 6 and reference numeral 714 of FIG. 7. In response to detecting any such conflicting non-FC request, the SN machine 311 provides a weighted Retry Presp to the conflicting non-FC request, as illustrated in block 624 of FIG. 6. This weighted Retry Presp causes the associated instance of the response logic 218 to issue a Retry Cresp, as described above with reference to Table III of FIG. 5 and block 504. The process then passes to block 640, described below.

[0056] While in the processing loop, the SN machine 311 also monitors on the system fabric for any conflicting FC operations targeting the same cache line as an earlier snooped FC request, as shown in block 630 of FIG. 6 and reference numeral 716 of FIG. 7. In response to detecting any such conflicting FC requests, the SN machine 311 provides a lightweight Retry partial response to the conflicting FC requests, as shown in block 632 of FIG. 6. This lightweight Retry partial response causes the associated instance of the response logic 218 to determine which of the multiple conflicting time-overlapping FC requests is selected first to update system memory 108, e.g., based on instructions implied by the partial response provided by the associated memory controller 106. Following block 632, or in response to negative determinations at both blocks 622 and 630, the process of FIG. 6 proceeds to block 640.

[0057] Block 640 illustrates the SN machine 311 determining if a REF mode timeout has occurred by consulting a REF mode timer. In various embodiments, the timeout may occur at a static, pre-defined timer value or at a dynamic value determined, for example, based on the number of conflicting FC and / or non-FC operations received during the REF mode. In response to determining at block 640 that the REF mode has timed out, the process proceeds to block 650, which illustrates the SN machine 311 exiting the REF mode, as illustrated at reference numeral 718 in FIG. 7. As such, the SN machine 311 terminates protection of the target cache line and returns to an idle state (block 614 in FIG. 6 and reference numeral 720 in FIG. 7). The process of FIG. 6 then ends at block 616.

[0058] However, if the SN machine 311 determines in block 640 that the REF mode has not timed out, then in block 642, as shown at reference numeral 722 in FIG. 7, the SN machine 311 determines whether a termination request for an FC class operation (e.g., CLEAN_ACK, BK, BK_FLUSH) has been received on the system fabric. The termination request will vary for various embodiments and / or different types of FC memory access requests, but provides an indication that the original FC request was successfully selected for processing by the memory controller 106 for the target memory block. If the SN machine 311 detects a termination request for an FC operation in block 642, the process of FIG. 6 then passes to block 650 and the following blocks. However, if the SN machine 311 does not detect a termination request for an FC class operation on the system fabric, then the process returns from block 642 to block 622 as described.

[0059] 6 discloses a technique in which the HPC snooper temporarily enters a REF mode in which the HPC snooper extends coherence protection to a memory block that is the target of a FC memory access operation request in the interval between the completion of the flush / clean activity performed by the HPC snooper and the acceptance of the request for processing by the LPC. This extended protection of the target cache line ensures that no other HPCs are formed against the target cache line until the FC memory access operation is guaranteed to succeed.

[0060] 8, a high level logic flow diagram of an exemplary process by which a cache that holds a non-HPC shared copy of the target cache of a snooped flush type request (e.g., DCBF or AMO) handles the request according to one embodiment. It should be noted that clean requests are ignored by caches that hold a shared copy of the target cache of clean (e.g., DCBST) requests.

[0061] The process of FIG. 8 begins at block 800 and proceeds to block 802, which illustrates the L2 cache 230 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) that holds the target cache line of the flush-type request. 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 assigns a SN machine 311 to handle the initial request. The assigned SN machine 311 transitions from an idle state to a busy state and begins protecting the target cache line.

[0062] In block 804, the SN machine 311 assigned to handle the snooped request in block 802 performs normal processing for the initial request or cleanup command by invalidating the target cache line in the local directory 308. As further indicated in block 804, while the SN machine 311 is busy, the L2 cache 230 provides a lightweight Retry partial response to any snooped request that requires access to the target cache line. In block 806, it is determined whether the SN machine 311 has completed processing the snooped request. If not, the process of FIG. 8 returns to block 804 as described. 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 808) and the process of FIG. 8 ends at block 810.

[0063] Referring to FIG. 9, a block diagram of an exemplary design flow 900 used, for example, in semiconductor IC logic design, simulation, testing, layout, and manufacturing is shown. The design flow 900 includes a process, machine, or mechanism, or combination thereof, for processing a design structure or device to generate a logical or other functionally equivalent representation of the design structure or device or both described above and shown in FIGS. 1-3. The design structure processed and / or generated by the design flow 900 may be encoded on a machine-readable transmission or storage medium and 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 may include a lithography machine (e.g., an electron beam lithography machine) for generating a mask, a machine, and / or an instrument, a computer or apparatus 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).

[0064] The design flow 900 may vary depending on the type of representation being designed. For example, a design flow 900 for building an application specific IC (ASIC) may differ from a design flow 900 for designing a standard component, or from a design flow 900 for instantiating a design into a programmable array, such as a programmable gate array (PGA) or a programmable gate array (FPGA) offered by Altera® or Xilinx®.

[0065] FIG. 9 illustrates a number of such design structures, including an input design structure 920, which is preferably processed by the design process 900. The design structure 920 is a logical simulation design structure that is generated and processed by the design process 900 to produce a logically equivalent functional representation of a hardware device. The design structure 920 may also, or alternatively, include data and / or program instructions that, when processed by the design process 900, generate a functional representation of the physical structure of the hardware device. Whether representing functional and / or structural design features, the design structure 920 may be generated using electronic computer aided design (ECAD), which may be implemented, for example, by a core developer / designer. When encoded on a machine readable data transmission, gate array, or storage medium, the design structure 920 may be accessed and processed by one or more hardware and / or software modules in the design process 900 to simulate or otherwise functionally represent an electronic component, circuit, electronic or logical module, apparatus, device, or system, such as those shown in FIGS. 1-3. Thus, design structure 920 may include files or other data structures containing 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 of 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, or both, lower level HDL design languages ​​such as Verilog or VHDL, or higher level design languages ​​such as C or C++, or both.

[0066] Design process 900 preferably employs and incorporates hardware and / or software modules for synthesizing, translating, or otherwise processing functional equivalents of the design / simulation of components, circuits, devices, or logic structures shown in FIGS. 1-3 to generate netlist 980, which may include design structures such as design structure 920. Netlist 980 may include, for example, compiled or otherwise processed data structures representing lists of wires, 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 980 may be synthesized using an iterative process of resynthesizing netlist 980 one or more times depending on the design specifications and parameters of the device. As with the other design structure types described herein, netlist 980 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. Additionally or alternatively, the medium may be system or cache memory, or buffer space.

[0067] The design process 900 may include hardware and software modules for processing various input data structure types, including netlist 980. Such data structure types may, for example, reside in library elements 930 and 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, 90 nm, etc.). The data structure types may further include design specifications 940, characterization data 950, verification data 960, design rules 970, and test data files 985, which may include input test patterns, output test results, and other test information. The design process 900 may further include standard mechanical design processes, such as, for example, stress analysis, thermal analysis, mechanical event simulation, process simulation for operations such as casting, molding, and die pressing. Those skilled in the art of mechanical design will appreciate the range of possible mechanical design tools and applications that may be used in the design process 900 without departing from the scope of the present invention. Design process 900 may also include modules for performing standard circuit design processes, such as timing analysis, verification, design rule checking, place and route operations, etc.

[0068] The design process 900 employs and incorporates logic and physical design tools, such as HDL compilers and simulation model building tools, to process the design structure 920 together with some or all of the illustrated supporting data structures, along with any additional mechanical designs or data (if applicable), to generate a second design structure 990. The design structure 990 resides on a storage medium or programmable gate array in a data format used to exchange mechanical device and structure data (e.g., information stored in IGES, DXF, Parasolid XT, JT, DRG, or any other suitable format for storing or rendering such mechanical design structures). Like the design structure 920, the design structure 990 preferably includes one or more files, data structures, or other computer-encoded data or instructions, which reside on a transmission medium or data storage medium and which, when processed by an ECAD system, generate a logically or otherwise functionally equivalent form of one or more embodiments of the present invention shown in FIGS. 1-3. In one embodiment, design structure 990 may include a compiled executable HDL simulation model that functionally simulates the devices shown in FIGS.

[0069] The design structure 990 may also employ data formats used for the exchange of integrated circuits 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). The design structure 990 may include, for example, symbolic data, map files, test data files, design content files, manufacturing data, layout parameters, wires, interconnect levels, vias, shapes, data for routing through a manufacturing line, and any other data required by a manufacturer or other designer / developer to produce a device or structure as described above and shown in FIGS. 1-3. The design structure 990 may then proceed to stage 995, where, for example, the design structure 990 may proceed to tape-out, be released to manufacturing, be released to a mask house, be sent to another design house, be sent back to the customer, etc.

[0070] 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 to process operations snooped from the system fabric with reference to the data array and directory. The snoop logic responds by snooping on the system fabric a request for an FC memory access operation of one of the multiple processor cores specifying a target address, services the request, and then enters a referee mode. While in the referee mode, the snoop logic protects a memory block identified by a target address against conflicting memory access requests by the multiple processor cores such that a memory controller of the system memory selects which request to process.

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

[0072] The flowcharts and block diagrams in the figures 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 of 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 embodiments, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may in fact be executed substantially simultaneously, 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, as well as 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 implements a combination of dedicated hardware and computer instructions.

[0073] Although aspects have been described with respect to a computer system executing program code directing the functions of the invention, it should be understood that the invention may also be embodied as a program product including a computer readable storage device storing program code that can be processed by a processor of the data processing system to cause the data processing system to perform the functions described. The computer readable storage device may include volatile or non-volatile memory, optical or magnetic disks, etc., but excludes non-statutory subject matter such as propagated signals per se, transmission media per se, and energy forms per se.

[0074] As an example, a program product may include data and / or instructions that, when executed or otherwise processed on a data processing system, generate a logical, structural, or other 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 or VHDL, or high-level design languages, such as C or C++, or both. Additionally, the data and / or instructions may 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).

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 and a memory controller of a system memory for receiving operations on the system fabric, the cache memory comprising: A data array; a directory of contents of said data array, said directory including coherence state information; snoop logic for processing operations snooped from the system fabric with reference to the data array and the directory; Including, A cache memory, wherein in response to snooping on the system fabric a request for a flush or clean memory access operation of one of the multiple processor cores specifying a target address, the snoop logic services the request and then enters a referee mode, and while in the referee mode, the snoop logic protects a memory block identified by the target address against conflicting memory access requests by the multiple processor cores such that no coherence participants other than the one that serviced the request are allowed to assume coherence ownership of the memory block.

2. the request for a flush or clean memory access operation is a first request; the snoop logic is configured to enter the referee mode based on snooping a conflicting second request after snooping the first request and before the snoop logic completes processing of the first request.

2. The cache memory of claim 1.

3. 2. The cache memory of claim 1, wherein the snoop logic is configured to protect the memory block against conflicting memory access requests by issuing a Retry coherence response to the conflicting memory access request.

4. the snoop logic is configured, while in the referee mode, to provide a first coherence response to conflicting flush or clean requests and to provide a different second coherence response to other types of conflicting requests.

2. The cache memory of claim 1.

5. 2. The cache memory of claim 1, wherein said snoop logic detects a timeout condition while in said referee mode and exits said referee mode in response to detecting said timeout condition.

6. 2. The cache memory of claim 1, wherein said snoop logic exits said referee mode in response to snooping a termination request on said system fabric while in said referee mode.

7. A cache memory according to any one of claims 1 to 6; at least one associated processor core coupled to said cache memory; A processing unit including:

8. A system fabric; a plurality of processing units according to claim 7 coupled to said system fabric; A data processing system comprising:

9. 1. A method of data processing in a multiprocessor data processing system, the multiprocessor data processing system including a cache memory of an associated processor core 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 a system memory for receiving operations on the system fabric, the method comprising: the cache memory snooping on a system fabric a request for a flush or clean memory access operation from one of the plurality of processor cores specifying a target address; based on snooping the request, the cache memory services the request and thereafter enters a referee mode; and While in the referee mode, the cache memory protects a memory block identified by a target address against conflicting memory access requests by the plurality of processor cores such that no coherence participant other than the one servicing the request is permitted to assume coherence ownership of the memory block. The method includes:

10. the request for a flush or clean memory access operation is a first request; entering the referee mode includes entering the referee mode based on snooping a conflicting second request after the first request has been snooped and before processing of the first request has been completed.

10. The method of claim 9.

11. 10. The method of claim 9, wherein said protecting comprises protecting said memory block against conflicting memory access requests by issuing a Retry coherence response to said conflicting memory access requests.

12. 10. The method of claim 9, wherein the protecting includes providing a first coherence response to conflicting flush or clean requests and providing a different second coherence response to other types of conflicting requests while the cache memory is in the referee mode.

13. 10. The method of claim 9, further comprising: detecting a timeout condition while the cache memory is in the referee mode; and exiting the referee mode in response to detecting the timeout condition.

14. 10. The method of claim 9, further comprising: the cache memory exiting the referee mode in response to snooping a termination request on the system fabric while in the referee mode.

15. A design structure recorded in a machine-readable storage device for designing, manufacturing, or testing an integrated circuit, said design structure being capable of transmitting to a design or simulation data processing system, when processed or executed on the data processing system: Processor Core a processing unit including: Data Array a cache memory including: a directory of contents of said data array, said directory including coherence state information; snoop logic for processing operations snooped from a system fabric of a multiprocessor data processing system with reference to said data array and said directory; encoded on said machine-readable storage device to contain data or instructions that cause a medium to generate, simulate, or program a representation equivalent to the functionality of A design structure in which the snoop logic, in response to snooping on the system fabric a request for a flush or clean memory access operation of one of a plurality of processor cores specifying a target address, services the request and then enters a referee mode, and while in the referee mode, the snoop logic protects a memory block identified by the target address against conflicting memory access requests by the plurality of processor cores, and therefore a memory controller providing an interface between the processing units and a system memory selects the request for processing.

16. the request for a flush or clean memory access operation is a first request; the snoop logic is configured to enter the referee mode based on snooping a conflicting second request after snooping the first request and before the snoop logic completes processing of the first request.

16. The design structure of claim 15.

17. 16. The design structure of claim 15, wherein the snoop logic is configured to protect the memory block against conflicting memory access requests by issuing a Retry coherence response to the conflicting memory access requests.

18. the snoop logic is configured, while in the referee mode, to provide a first coherence response to conflicting flush or clean requests and to provide a different second coherence response to other types of conflicting requests.

16. The design structure of claim 15.

Images