<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Mqtran</id>
	<title>Expertiza_Wiki - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Mqtran"/>
	<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Special:Contributions/Mqtran"/>
	<updated>2026-09-12T15:57:41Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.41.0</generator>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2011/ch8_mc&amp;diff=44467</id>
		<title>CSC/ECE 506 Spring 2011/ch8 mc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2011/ch8_mc&amp;diff=44467"/>
		<updated>2011-03-20T01:29:46Z</updated>

		<summary type="html">&lt;p&gt;Mqtran: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Introduction to bus-based cache coherence in real machines=&lt;br /&gt;
&lt;br /&gt;
Most parallel software in the commercial market relies on the shared-memory&lt;br /&gt;
programming model in which all processors access the same physical address space. The most common multiprocessors today use [http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP] architecture which use a common bus as the interconnect.  In the case of multicore processors (&amp;quot;chip multiprocessors,&amp;quot; or CMP) the [http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP] architecture applies to the cores treating them as separate processors. The key problem of shared-memory multiprocessors is providing a consistent view of memory with various cache hierarchies.  This is called '''''cache coherence problem'''''. It is  critical to  achieve correctness and performance-sensitive design point for supporting the shared-memory model. The cache coherence mechanisms not only govern communication in a shared-memory multiprocessor, but also typically determine how the memory system transfers data between processors, caches, and memory.&lt;br /&gt;
&lt;br /&gt;
[[Image:Busbased SMP.jpg|frame|center|&amp;lt;b&amp;gt;Figure 1:&amp;lt;/b&amp;gt; Typical Bus-Based Processor Model]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Cache Coherence in real machines=&lt;br /&gt;
==Summary of Cache Coherence Protocols==&lt;br /&gt;
At any point in logical time, the permissions for a cache block can allow either a single writer or multiple readers. The '''''coherence protocol''''' ensures the invariants of the states are maintained. The different coherent states used by most of the cache coherent protocols are shown in ''Table 1'':&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''States'''&lt;br /&gt;
|  '''Access Type'''&lt;br /&gt;
|  '''Invariant'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  read, write&lt;br /&gt;
|  all other caches in I state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  read&lt;br /&gt;
|  all other caches in I state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Owned'''&lt;br /&gt;
|  read&lt;br /&gt;
|  all other caches in I or S state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  read&lt;br /&gt;
|  no other cache in M or E state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|  -&lt;br /&gt;
|  -&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 1:&amp;lt;/b&amp;gt; States Used by the Cache Coherent Protocols&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
The first widely adopted approach to cache coherence is snooping on a bus. We will now discuss them in details in the following sections.&lt;br /&gt;
&lt;br /&gt;
===MSI===&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI protocol]''' is a three-state write-back '''invalidation protocol''' which is one of the earliest snooping-based cache coherence-protocols. It marks the cache line with one of the '''Modified (M) ,Shared (S)''', and '''Invalid (I)''' state. '''Invalid''' means the cache line is either not present or is in invalid state. If the cache line is clean and is shared by more than one processor , it is marked as '''Shared'''. If a cache line is dirty and the processor has exclusive ownership of it, it is in '''Modified''' state. BusRdx causes other processors to invalidate (demote) its cache block to the '''I''' state. If it is present in the '''M''' state in another cache, it will flush. &lt;br /&gt;
&lt;br /&gt;
The following state transition diagram for MSI protocol explains the working of the protocol:&lt;br /&gt;
&lt;br /&gt;
[[Image:MSI.jpg|frame|center|&amp;lt;b&amp;gt;Figure 2:&amp;lt;/b&amp;gt; MSI State Diagram]]&lt;br /&gt;
&lt;br /&gt;
===MESI===&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI protocol]''' has a major drawback in that each read-write sequence incurs two bus transactions irrespective of whether the cache line is stored in only one cache or not. This is a huge setback for highly parallel programs that have little data sharing. '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol solves this problem by introducing the E ('''Exclusive''') state to distinguish between a cache line stored in multiple caches and a line stored in a single cache.&lt;br /&gt;
Let us briefly look at how the MESI protocol works. (For a more detailed version readers are referred to Solihin textbook pg. 215)&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' coherence protocol marks each cache line in one of the Modified, Exclusive, Shared or Invalid state. &lt;br /&gt;
* '''Invalid''' : The cache line is either not present or is invalid&lt;br /&gt;
* '''Exclusive''' : The cache line is clean and is owned by this core/processor only&lt;br /&gt;
* '''Modified''' :  This implies that the cache line is dirty and the core/processor has  exclusive ownership of the cache line, exclusive of the memory also.&lt;br /&gt;
* '''Shared''' : The cache line is clean and is shared by more than one core/processor&lt;br /&gt;
&lt;br /&gt;
In a nutshell, the '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol works as the following: &lt;br /&gt;
A line that is just fetched receives '''E''' or '''S''' state depending on whether it exists in other processors in the system or not. Similarly, a cache line gets the '''M''' state when a processor writes to it. If the line is not in '''E''' or '''M''' state prior to being written to, the cache sends a Bus Upgrade (BusUpgr) signal or as the Intel manuals call it, a “Read-For-Ownership (RFO) request” that ensures that the line exists in the cache and is in the '''I''' state in all other processors on the bus (if any). The table shown below will summarize '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''Cache Line State:'''&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''This cache line is valid?'''&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  No&lt;br /&gt;
|-&lt;br /&gt;
|  '''The memory copy is…'''&lt;br /&gt;
|  out of date&lt;br /&gt;
|  valid&lt;br /&gt;
|  valid&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''Copies exist in caches of other processors?'''  &lt;br /&gt;
|  No&lt;br /&gt;
|  No&lt;br /&gt;
|  Maybe&lt;br /&gt;
|  Maybe&lt;br /&gt;
|-&lt;br /&gt;
|  '''A write to this line'''&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  goes to bus and updates cache&lt;br /&gt;
|  goes directly to bus&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 2:&amp;lt;/b&amp;gt; MESI Protocol Summary&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The transition diagram from the lecture slides is given below for reference.&lt;br /&gt;
&lt;br /&gt;
[[Image:MESI.jpg|frame|center|&amp;lt;b&amp;gt;Figure 4:&amp;lt;/b&amp;gt; MESI State Diagram]]&lt;br /&gt;
&lt;br /&gt;
===MESIF===&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/MESIF_protocol MESIF]''' protocol, used in the latest Intel multi-core processors Core i7, was introduced to '''accommodate the point-to-point''' links used in the QuickPath Interconnect. Using the '''MESI''' protocol in this architecture would send many redundant messages between different processors, often with unnecessarily high latency. For example, when a processor requests a cache line that is stored in multiple locations, every location might respond with the data. As the requesting processor only needs a single copy of the data, the system would be '''wasting the bandwidth'''. &lt;br /&gt;
As a '''solution''' to this problem, an additional state, '''Forward state''', was added by slightly changing the role of the Shared state. Whenever there is a read request, only the cache line in the F state will respond to the request, while all the S state caches remain dormant.  Hence, by designating a single cache line to '''respond to requests''', coherency traffic is substantially reduced when multiple copies of the data exist. Also, on a read request, the F state transitions to the S state. That is, when a cache line in the '''F''' state is '''copied''', the F state '''migrates''' to the '''newer copy''', while the '''older''' one drops back to the '''S''' state. Moving the new copy to the F state '''exploits''' both '''temporal and spatial locality'''. Because the newest copy of the cache line is always in the F state, it is very unlikely that the line in the F state will be evicted from the caches. This takes advantage of the temporal locality of the request. The second advantage is that if a particular cache line is in high demand due to spatial locality, the bandwidth used to transmit that data will be spread across several cores.&lt;br /&gt;
All M to S state transitions and E to S state transitions will now be from '''M to F''' and '''E to F'''.  &lt;br /&gt;
The '''F state''' is '''different''' from the '''Owned state''' of the MOESI protocol as it is '''not''' a '''unique''' copy because a valid copy is stored in memory. Thus, unlike the Owned state of the MOESI protocol, in which the data in the O state is the only valid copy of the data, the data in the F state can be evicted or converted to the S state, if desired. &lt;br /&gt;
&lt;br /&gt;
More information on the QuickPath Interconnect and MESIF protocol can be found at&lt;br /&gt;
'''[http://www.intel.com/technology/quickpath/introduction.pdf Introduction to QuickPath Interconnect]'''. &lt;br /&gt;
&lt;br /&gt;
===MOESI===&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/Opteron AMD Opteron] was AMD’s first-generation dual core processor which had two distinct [http://en.wikipedia.org/wiki/Athlon_64 K8 cores] together on a single die. Cache coherence produces bigger problems on such multicore processors. It was necessary to use an appropriate coherence protocol to address this problem. The [http://en.wikipedia.org/wiki/Xeon Intel Xeon], which was the competitive counterpart from Intel to AMD dual core Opteron, used the [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol to handle cache coherence. [http://en.wikipedia.org/wiki/MESI_protocol MESI] came with the drawback of using much time and bandwidth in certain situations. &lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/MOESI_protocol MOESI] was AMD’s answer to this problem. [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] added a fifth state to [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol called the '''owned''' state. [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol addresses the bandwidth problem faced by MESI protocol when processor having invalid data in its cache wants to modify the data.  The processor seeking the data will have to wait for the processor which modified this data to write back to the main memory, which takes time and bandwidth. This drawback is removed in MOESI by allowing dirty sharing.  When the data is held by a processor in the new state '''owned''', it can provide other processors the modified data without writing it to the main memory. This is called '''''dirty sharing'''''. The processor with the data in the '''owned''' state stays responsible to update the main memory later when the cache line is evicted.&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/MOESI_protocol MOESI]  has become one of the most popular snoop-based protocols supported in AMD64 architecture.  AMD dual-core Opteron can maintain cache coherence in systems up to 8 processors using this protocol.&lt;br /&gt;
&lt;br /&gt;
The five different states of [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol are:&lt;br /&gt;
* '''Modified (M)''': The most recent copy of the data is present in the cache line. But it is not present in any other processor cache.&lt;br /&gt;
* '''Owned (O)''': The cache line has the most recent correct copy of the data. This can be shared by other processors. The processor in this state for this cache line is responsible to update the correct value in the main memory before it gets evicted.&lt;br /&gt;
* '''Exclusive (E)''': A cache line holds the most recent, correct copy of the data, which is exclusively present on this processor and a copy is present in the main memory.&lt;br /&gt;
* '''Shared (S)''': A cache line in the shared state holds the most recent, correct copy of the data, which may be shared by other processors.&lt;br /&gt;
* '''Invalid (I)''': A cache line does not hold a valid copy of the data.&lt;br /&gt;
&lt;br /&gt;
A detailed explanation of this protocol implementation on AMD processor can be found in the manual [http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html Architecture of AMD 64-bit core]&lt;br /&gt;
&lt;br /&gt;
The following table summarizes the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''Cache Line State:'''&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  '''Owner''' &lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''This cache line is valid?'''&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  No&lt;br /&gt;
|-&lt;br /&gt;
|  '''The memory copy is…'''&lt;br /&gt;
|  out of date&lt;br /&gt;
|  out of date&lt;br /&gt;
|  valid&lt;br /&gt;
|  valid&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''Copies exist in caches of other processors?'''&lt;br /&gt;
|  No&lt;br /&gt;
|  No&lt;br /&gt;
|  Yes(out of date values)|  Maybe&lt;br /&gt;
|  Maybe&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''A write to this line'''&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  does not go to bus|  does not go to bus&lt;br /&gt;
|  goes to bus and updates cache&lt;br /&gt;
|  goes directly to bus&lt;br /&gt;
|  -&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 3:&amp;lt;/b&amp;gt; MOESI Protocol Summary&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
State transition for [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]is as shown below : &lt;br /&gt;
&lt;br /&gt;
[[Image:MOESI_State_Transition_Diagram.jpg|frame|center|&amp;lt;b&amp;gt;Figure 7:&amp;lt;/b&amp;gt; [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]State transition Diagram]]&lt;br /&gt;
&lt;br /&gt;
We will now discuss which cache coherence protocol processor vendors like '''Intel''', '''AMD''' and others adopt in various products.&lt;br /&gt;
&lt;br /&gt;
===Cache Coherence Protocols and Their Performance===&lt;br /&gt;
Of all protocols, MSI appears to have the worst performance due to the fact that each read-write sequence incurs two bus transactions even if the data is stored in only one cache. This causes a huge performance penalty for highly optimized parallel programs that have little data sharing. MESI protocol solves this problem by introducing the E (Exclusive) state to distinguish between a cache line stored in multiple caches and a line stored in only one cache. This protocol, however, can still be improved further. &lt;br /&gt;
&lt;br /&gt;
One remaining issue with MESI protocol is that in multi-processor configuration, when a processor requests a cache line that is stored in multiple cache, every cache might respond with the data. This behavior would waste bus bandwidth and incur high latency. As a solution to this problem, MESIF protocol was introduced. An additional state, Forward state, was added by slightly changing the role of the Shared state. The result of this improvement is that instead of all caches responding, only the cache line in the F state will respond to the request, while all the S state caches remain dormant. As a result, performance and power efficiency is increased.[23] &lt;br /&gt;
&lt;br /&gt;
Another problem with MESI protocol is when a processor having invalid data in its cache wants to modify the data, it will have to wait for the other processor to write back to the memory, which is a very slow process. MOESI protocol solves this problem by allowing dirty&lt;br /&gt;
sharing. This also saves bus bandwidth and increases performance.[24]&lt;br /&gt;
==SGI - Silicon Graphics, Inc==&lt;br /&gt;
===MSI &amp;amp; SGI IRIS 4D Processors===&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' protocol was first used in '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''' IRIS 4D series. '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''' produced a broad range of '''[http://en.wikipedia.org/wiki/MIPS_architecture MIPS]'''-based (Microprocessor without Interlocked Pipeline Stages) workstations and servers during the 1990s, running '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''''s version of UNIX System V, now called '''[http://en.wikipedia.org/wiki/IRIX IRIX]'''. The 4D-MP graphics superworkstation brought 40 MIPS(million instructions per second) of computing performance to a graphics superworkstation. The unprecedented level of computing and graphics processing in an office-environment workstation was made possible by the fastest available Risc microprocessors in a single shared memory multiprocessor design driving a tightly coupled, highly parallel graphics system. Aggregate sustained data rates of over one gigabyte per second were achieved by a hierarchy of buses in a balanced system designed to avoid bottlenecks.&lt;br /&gt;
&lt;br /&gt;
The multiprocessor bus used in 4D-MP graphics superworkstation is a pipelined, block transfer bus that supports the cache coherence protocol as well as providing 64 megabytes of sustained data bandwidth between the processors, the memory and I/O system, and the graphics subsystem. Because the sync bus provides for efficient synchronization between processors, the cache coherence protocol was designed to support efficient data sharing between processors. If a cache coherence protocol has to support synchronization as well as sharing, a compromise in the efficiency of the data sharing protocol may be necessary to improve the efficiency of the synchronization operations. Hence it uses the simple cache coherence protocol which is the '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' protocol.&lt;br /&gt;
&lt;br /&gt;
With the simple rules of '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]'''protocol enforced by hardware, efficient synchronization and efficient data sharing are achieved in a simple shared memory model of parallel processing in the 4D-MP graphics superworkstation.&lt;br /&gt;
&lt;br /&gt;
==SYNAPSE Multiprocessor==&lt;br /&gt;
===Synapse protocol and Synapse multiprocessor===&lt;br /&gt;
From the state transition diagram of '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''', we observe that for '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' there is transition to the '''S''' state from the '''M''' state when a BusRd is observed for that block. The contents of the block is flushed to the bus before going to '''S''' state. It would look more appropriate to move to the '''I''' state thus giving up the block entirely in certain cases. This choice of moving to '''S''' or '''I''' reflects the designer's assertion that the original processor is more likely to continue reading the block than the new processor to write to the block. In synapse protocol, used in the early Synapse multiprocessor, made this alternate choice of going directly from the '''M''' state to the '''I''' state on a BusRd, assuming the migratory pattern would be more frequent. More details about this protocol can be found in these papers published in late 1980's [http://portal.acm.org/citation.cfm?id=6514Cache Coherence protocols: evaluation using a multiprocessor simulation model] and [http://portal.acm.org/citation.cfm?id=1499317&amp;amp;dl=GUIDE&amp;amp;coll=GUIDE&amp;amp;CFID=83027384&amp;amp;CFTOKEN=95680533 Synapse tightly coupled multiprocessors: a new approach to solve old problems]&lt;br /&gt;
&lt;br /&gt;
In the Synapse protocol, the '''M''' state is called the '''D''' (Dirty) state. The following is the state transition diagram for Synapse protocol which clearly shows its working.&lt;br /&gt;
&lt;br /&gt;
[[Image:Synapse1.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; Synapse State Diagram]]&lt;br /&gt;
&lt;br /&gt;
==Intel==&lt;br /&gt;
===MESI &amp;amp; Intel Processors===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The '''Pentium Pro''' microprocessor, introduced in 1992 was the '''first''' Intel architecture microprocessor to support symmetric multiprocessing ('''[http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP]''') in various multiprocessor configurations. '''[http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP]''' and '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol was the architecture used consistently until the introduction of the 45-nm Hi-k Core micro-architecture in '''Intel's (Nehalem-EP) quad-core x86-64'''. The 45-nm Hi-k Intel Core microarchitecture utilizes a new system of framework called the '''QuickPath Interconnect''' which uses point-to-point interconnection technology based on distributed shared memory architecture. It uses a modified version of '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol called '''MESIF''', by introducing an additional state, F, the forward state. &lt;br /&gt;
&lt;br /&gt;
The '''Intel architecture''' uses the '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol  as the '''basis''' to ensure cache coherence, which is true whether you're on one of the older processors that use a '''common bus''' to communicate or using the new Intel '''QuickPath''' point-to-point interconnection technology. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== CMP Implementation in Intel Architecture ===&lt;br /&gt;
&lt;br /&gt;
Let us now see how Intel architecture using the [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol progressed from a uniprocessor architecture to a Chip MultiProcessor (CMP) using the bus as the interconnect. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Uniprocessor Architecture'''&lt;br /&gt;
&lt;br /&gt;
The diagram below shows the structure of the memory cluster in Intel Pentium M processor.&lt;br /&gt;
&lt;br /&gt;
[[Image:intel_cache1.jpg|frame|center|&amp;lt;b&amp;gt;Figure 5:&amp;lt;/b&amp;gt; Memory Structure of the Pentium M Processor]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In this structure we have,&lt;br /&gt;
* A unified on-chip '''L1 cache''' with the '''processor/core''',&lt;br /&gt;
* A '''Memory/L2 access control unit''', through which all the accesses to the L2 cache, main memory and IO space are made,&lt;br /&gt;
* The second level '''L2 cache''' along with the '''prefetch unit''' and&lt;br /&gt;
* '''Front side bus (FSB)''', a single shared bi-directional bus through which all the traffic is sent across.These wide buses bring in multiple data bytes at a time. &lt;br /&gt;
&lt;br /&gt;
As Intel explains it, using this structure, the processor requests were first sought in the '''L2 cache''' and only on a '''miss''', were they '''forwarded''' to the main '''memory''' via the front side bus ('''FSB'''). The '''Memory/L2 access control''' unit served as a central point for '''maintaining coherence''' within the core and with the external world. It '''contains''' a '''snoop control unit''' that receives snoop requests from the bus and performs the required operations on each cache (and internal buffers) in parallel. It also handles RFO requests (BusUpgr) and ensures the operation continues only after it guarantees that no other version on the cache line exists in any other cache in the system.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''CMP Architecture'''&lt;br /&gt;
&lt;br /&gt;
For CMP implementation, Intel chose the bus-based architecture using snoopy protocols vs the '''directory protocol''' because though directory protocol reduces the active power due to reduced snoop activity, it '''increased''' the '''design complexity''' and the '''static power''' due to larger tag arrays. Since Intel has a large market for the processors in the mobility family, directory-based solution was less favorable since battery life mainly depends on static power consumption and less on dynamic power.&lt;br /&gt;
Let us examine how '''CMP''' was implemented in '''Intel Core Duo''', which was one of the first dual-core processor for the budget/entry-level market. &lt;br /&gt;
The general CMP implementation structure of the Intel Core Duo is shown below&lt;br /&gt;
&lt;br /&gt;
[[Image:intel_cache2.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; Intel Core Duo CMP Implementation]]&lt;br /&gt;
&lt;br /&gt;
This structure has the following changes when compared to the uniprocessor memory cluster structure. &lt;br /&gt;
* '''L1 cache''' and the '''processor/core''' structure is '''duplicated''' to give 2 cores.&lt;br /&gt;
* The '''Memory/L2 access control''' unit is '''split''' into 2 logical units: '''L2 controller''' and '''bus controller'''. The L2 controller handles all '''requests to the L2''' cache from the core and the snoop requests from the FSB. The '''bus controller''' handles '''data and I/O requests''' to and from the FSB.&lt;br /&gt;
* The '''prefetching''' unit is extended to handle the hardware '''prefetches for each core separately'''.&lt;br /&gt;
* A '''new logical unit''' (represented by the hexagon) was added to maintain '''fairness between the requests''' coming from the different cores and hence balance the requests to L2 and memory.&lt;br /&gt;
&lt;br /&gt;
This new '''partitioned structure''' for the  memory/L2 access control unit '''enhanced''' the '''performance''' while '''reducing power consumption'''. &lt;br /&gt;
For more information on uniprocessor and multiprocessor implementation under the Intel architecture, refer to &lt;br /&gt;
[http://www.intel.com/technology/itj/2006/volume10issue02/art02_CMP_Implementation/p03_implementation.htm CMP Implementation in Intel Core Duo Processors]&lt;br /&gt;
&lt;br /&gt;
The '''Intel bus architecture''' has been '''evolving''' in order to accommodate the demands of scalability while using the '''same [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol'''; From using a '''single shared bus''' to '''dual independent buses (DIB)''' doubling the available bandwidth and to the logical conclusion of DIB with the introduction of '''dedicated high-speed interconnects (DHSI)'''. The DHSI-based platforms use four FSBs, one for each processor in the platform. In both DIB and DHSI, the snoop filter was used in the chipset to cache snoop information, thereby significantly reducing the broadcasting needed for the snoop traffic on the buses. With the production of processors based on next generation 45-nm Hi-k Intel Core microarchitecture, the [http://en.wikipedia.org/wiki/Xeon Intel Xeon] processor fabric will transition from a DHSI, with the memory controller in the chipset, to a distributed shared memory architecture using '''Intel QuickPath Interconnects using MESIF protocol'''.&lt;br /&gt;
&lt;br /&gt;
==AMD - Advanced Micro Devices Processors==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===MOESI &amp;amp; AMD Processors===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===AMD Opteron memory Architecture===&lt;br /&gt;
&lt;br /&gt;
[[Image:Untitled.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; AMD Opteron memory Architecture]]&lt;br /&gt;
&lt;br /&gt;
The AMD processor’s high-performance cache architecture includes an integrated, 64-bit, dual-ported  128-Kbyte split-L1 cache with separate snoop port, multi-level translation lookaside buffers (TLBs), a scalable L2 cache controller with a 72-bit (64-bit data + 8-bit ECC) interface to as much as 8-Mbyte of industry-standard SDR or DDR SRAMs, and an integrated tag for the most cost-effective 512-Kbyte L2 configurations. The AMD Athlon processor’s integrated L1 cache comprises two separate 64-Kbyte, two-way set-associative data and instruction caches.&lt;br /&gt;
&lt;br /&gt;
More information about this can be found in [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD 64 bit Architecture Programmers's Manual]&lt;br /&gt;
&lt;br /&gt;
===Special Coherence Considerations in AMD64 architectures===&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
Instruction prefetching is a technique used to speedup the execution of the program. But in multiprocessors, prefetching comes at the cost of performance. Due to prefetching, the data can be modified in such a way that the memory coherence protocol will not be able to handle the effects. In such situations software must use serializing instructions or cache-invalidation instructions to guarantee subsequent data accesses are coherent. &lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
An example of this type of a situation is a page-table update followed by accesses to the physical pages referenced by the updated page tables. The physical-memory references for the page tables are different than the physical-memory references for the data. Because of prefetching, there maybe problem with correctness. The following sequence of events shows such a situation when software changes the translation of virtual-page A from physical-page M to physical-page N:&lt;br /&gt;
# The tables that translate virtual-page A to physical-page M are now held only in main memory. The copies in the cache ae invalidated.&lt;br /&gt;
# Page-table entry is changed by the software for virtual-page A in main memory to point to physical page N rather than physical-page M.&lt;br /&gt;
# Data in virtual-page A is accessed.&lt;br /&gt;
&lt;br /&gt;
Software expects the processor to access the data from physical-page N after the update. However, it is possible for the processor to prefetch the data from physical-page M before the page table for virtual page A is updated. Because the physical-memory references are different, the processor does not recognize them as requiring coherence checking and believes it is safe to prefetch the data from virtual-page A, which is translated into a read from physical page M. Similar behavior can occur when instructions are prefetched from beyond the page table update instruction.&lt;br /&gt;
&lt;br /&gt;
In order to prevent errors from occuring, there are special instructions provided by software like INVLPG or MOV CR3 instruction which is executed immediately after the page-table update to ensure that subsequent instruction fetches and data accesses use the correct virtual-page-to-physical-page translation. It is not necessary to perform a TLB invalidation operation preceding the table update.&lt;br /&gt;
&lt;br /&gt;
More information can be found about this in [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD64 Architecture Programmer's manual]&lt;br /&gt;
&lt;br /&gt;
===Optimization techniques on MOESI when implemented on AMD Phenom processors===&lt;br /&gt;
&lt;br /&gt;
In real machines, using some optimization techniques on the standard cache coherence protocol used, improves the performance of the machine. For example, [http://en.wikipedia.org/wiki/AMD_Phenom AMD Phenom] family of microprocessors (Family 0×10) which is AMD’s first generation to incorporate 4 distinct cores on a single die. It is the first to have a cache that all the cores share, using the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol with some optimization techniques incorporated. &lt;br /&gt;
&lt;br /&gt;
It focuses on a small subset of compute problems which behave like Producer and Consumer programs. In such a computing problem, a thread of a program running on a single core produces data, which is consumed by a thread that is running on a separate core. With such programs, it is desirable to get the two distinct cores to communicate through the shared cache, to avoid round trips to/from main memory. The '''MOESI''' protocol that the [http://en.wikipedia.org/wiki/AMD_Phenom AMD Phenom] cache uses for cache coherence can also limit bandwidth. Hence by keeping the cache line in the '''M''' state for such computing problems, we can achieve better performance.&lt;br /&gt;
&lt;br /&gt;
When the producer thread , writes a new entry, it allocates cache-lines in the '''M''' state. Eventually, these M-marked cache lines will start to fill the L3 cache. When the consumer reads the cache line, the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol changes the state of the cache line to the '''O''' state in the L3 cache and pulls down a '''shared (S)''' copy for its own use. Now, the producer thread circles the ring buffer to arrive back to the same cache line it had previously written. However, when the producer attempts to write new data to the owned (marked '''‘O’''') cache line, it finds that it cannot, since a cache line in the '''O''' state by the previous consumer read does not have sufficient permission for a write request (in the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]). To maintain coherence, the memory controller must initiate probes in the other caches (to handle any other S copies that may exist). This will slow down the process.&lt;br /&gt;
&lt;br /&gt;
Thus, it is preferable to keep the cache line in the '''M''' state in the L3 cache. In such a situation, when the producer comes back around the ring buffer, it finds the previously written cache line still in the'''M''' state, to which it is safe to write without coherence concerns. Thus better performance can be achieved by such optimization techniques to standard protocols when implemented in real machines.&lt;br /&gt;
&lt;br /&gt;
You can find more information on how this is implemented and various other ways of optimizations in this manual [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf Software Optimization guide for AMD 10h Processors].&lt;br /&gt;
&lt;br /&gt;
==Xerox Corporation==&lt;br /&gt;
===Dragon Protocol &amp;amp; Xerox Dragon Processors===&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' is an update based coherence protocol which does not invalidate other cached copies like what we have seen in the coherence protocols so far. Write propagation is achieved by updating the cached copies instead of invalidating them.  But the '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' does not update memory on a cache to cache transfer and delays the memory and cache consistency until the data is evicted and written back, which saves time and lowers the memory access requirements. Moreover only the written '''byte''' or the '''word''' is '''communicated''' to the '''other caches''' instead of the whole block which further '''reduces''' the '''bandwidth''' usage. It has the ability to detect dynamically, the sharing status of a block and use a write through policy for shared blocks and write back for currently non-shared blocks. The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' employs the following four states for the cache blocks: '''Shared Clean''', '''Shared Modified''', '''Exclusive''', and  '''Modified'''. &lt;br /&gt;
* '''Modified (M)''' and '''Exclusive (E)''' - these states have the same meaning as explained in the protocols above. &lt;br /&gt;
* '''Shared Modified (Sm)''' - Only one cache line in the system can be in the Shared Modified state. Potentially two or more caches    have this block and memory may or may not be up to date and this processor's cache had modified the block.&lt;br /&gt;
* '''Shared Clean (Sc)''' -  Potentially two or more caches have this block and memory may or may not be up to date(if no other cache has it in Sm state, memory will be up to date else it is not).&lt;br /&gt;
When a Shared Modified line is evicted from the cache on a cache miss only then is the block written back to the main memory in order to keep memory consistent. For more information on Dragon protocol, refer to Solihin textbook, page number 229. The state transition diagram has been given below for reference.&lt;br /&gt;
&lt;br /&gt;
[[Image:Dragon.jpg|frame|center|&amp;lt;b&amp;gt;Figure 9:&amp;lt;/b&amp;gt; Dragon Protocol State Diagram]]&lt;br /&gt;
&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' , was developed by Xerox Palo Alto Research Center ('''[http://en.wikipedia.org/wiki/Xerox_PARC Xerox PARC]'''), a subsidiary of Xerox Corporation.  This protocol was used in the '''[http://en.wikipedia.org/w/index.php?title=Xerox_Dragon&amp;amp;redirect=no Xerox PARC Dragon]''' multiprocessor workstation, a VLSI research computer that could support multiple processors on a central high bandwidth memory bus. The Dragon design implemented snoopy caches that provided the appearance of a uniform memory space to multiple processors. Here, each cache listens to 2 buses: the processor bus and the memory bus. The caches are also responsible for address translation, so the processor bus carries virtual addresses and the memory bus carries physical addresses.  The Dragon system was designed to support 4 to 8 Dragon processors. The memory bus used in the Xeron Dragon evolved to become the '''[http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=289691 XDBus]''' , a low-cost, synchronous, '''packet-switched VLSI bus''' designed for use in high-performance multiprocessors. This was used as the interconnect in many multiprocessor server systems like '''Cray Superserver 6400''', '''Sun Microsystems' SPARCcenter 2000''' and '''SPARCserver 1000'''  and '''Sun4d''' systems.&lt;br /&gt;
&lt;br /&gt;
=Cache Coherence Power Utilization=&lt;br /&gt;
A number of studies have been performed to reduce the power consumption of cache coherence protocols. In order to perform a solid comparison between the cache coherency protocols, one would need to develop a multi-core processor for each of the cache coherency protocols. Additionally, the hardware and software configuration would also need to be similar between each system (except for the hardware required to implement each of the different protocols). Unfortunately, there are no such processors available. This section will discuss power consumption in general terms, comparing to each of the protocols. Also, this section will briefly discussion some power optimization techniques.&lt;br /&gt;
&lt;br /&gt;
Bus transactions, in general, are costly for both performance and power consumption. Additionally, studies have been performed showing that unnecessary snooping can waste power. Power requirements are typically determined by the number of bus snoops and number of bus accesses by each processor. One study indicates that interchip bus communications can consume up to 20% of total chip power[[#References|&amp;lt;sup&amp;gt;[20]&amp;lt;/sup&amp;gt;]].&lt;br /&gt;
Using the examples from the class notes, we can analyze the relative power consumption between the protocols. The following table is a summary of various protocols showing the number of bus communications that occur for each processor action.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|'''Processor Action'''&lt;br /&gt;
|'''MSI Bus Actions'''&lt;br /&gt;
|'''MESI Bus Actions'''&lt;br /&gt;
|'''Dragon Bus Actions'''&lt;br /&gt;
|'''FireFly Bus Actions'''&lt;br /&gt;
|-&lt;br /&gt;
|R1&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|-&lt;br /&gt;
|W1&lt;br /&gt;
|BusRdX&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R3&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|-&lt;br /&gt;
|W3&lt;br /&gt;
|BusRdX&lt;br /&gt;
|BusRdX&lt;br /&gt;
|BusUpd/Upd&lt;br /&gt;
|BusUpd&lt;br /&gt;
|-&lt;br /&gt;
|R1&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R3&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R2&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 4:&amp;lt;/b&amp;gt; Summary of Bus Actions for Select Protocols&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
From the table above, we can see that MSI has a larger number of bus transactions than the Dragon protocol. Even though bus transactions are not power efficient, snooping can also be enhanced to improve power efficiency. The following section will discuss snoop filtering techniques.&lt;br /&gt;
&lt;br /&gt;
==Power Savings Using Snoop Filtering==&lt;br /&gt;
A number of studies have been performed to reduce the number of unnecessary snoops during cache transactions. Two such filtering techniques are serial snooping and Jetty. The following sections will briefly discuss these two filtering techniques and power savings achieved using these techniques. Studies show that as much as 90% of snoop broadcasts will result in a miss[[#References|&amp;lt;sup&amp;gt;[19]&amp;lt;/sup&amp;gt;]] in the other caches at the same level and require that the information be provided by the next level of cache or memory. As much as a 36% savings in power by filtering snoops using one of the following snoop filtering methods[[#References|&amp;lt;sup&amp;gt;[19]&amp;lt;/sup&amp;gt;]].&lt;br /&gt;
===Serial Snooping===&lt;br /&gt;
Serial snooping takes advantage of the fact that if a miss occurs in one cache, it is possible to find the block in one other cache without having to check all the caches. If the cache block is available in multiple caches, there is a high probability that the cache miss can find the data in a nearby cache. Alternatively, savings can be realized by searching a subset of the caches vice all the caches. One thing to note is that this is only effective for read misses. Write, an invalidation transaction needs to be transmitted to the other caches, thus a bus transaction is unavoidable.&lt;br /&gt;
===Jetty===&lt;br /&gt;
Jetty is a mechanism attached to each cache that verifies that a bus snoop is necessary. Jetty is used to filter L2 tag lookups. When a processor needs to perform a bus snoop, the Jetty is checked first. The Jetty can determine if a cache tag lookup is required. Since the Jetty is much smaller than the associated cache, less power is required to determine if a snoop is required.&lt;br /&gt;
&lt;br /&gt;
There are a couple of different Jetty schemes. There is the exclude-Jetty, include-Jetty, and hybrid-Jetty. The exclude-Jetty exploits the fact that if a cache block is snooped, it is highly likely the same cache block will be snooped in the near future. The exclude-Jetty keeps track of the tag lookups in a small table and can determine if a cache tag lookup is necessary.&lt;br /&gt;
&lt;br /&gt;
The include-Jetty keeps a superset of the blocks that are cached. If a miss occurs in the include-Jetty, then it can be guaranteed that the block is not stored in its associated cache.&lt;br /&gt;
&lt;br /&gt;
The hybrid-Jetty is simply a combinations of and include and exclude-Jetty. Both types of Jetty are present and when a lookup occurs, both Jettys are checked to determine if a cache lookup is necessary.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Cache_coherence Cache coherence]&lt;br /&gt;
# [http://www.intel.com/technology/quickpath/introduction.pdf Introduction to QuickPath Interconnect]&lt;br /&gt;
# [http://www.intel.com/technology/itj/2006/volume10issue02/art02_CMP_Implementation/p03_implementation.htm CMP Implementation in Intel Core Duo Processors]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Symmetric_multiprocessing Common System Interface in Intel Processors]&lt;br /&gt;
# [http://www.zak.ict.pwr.wroc.pl/nikodem/ak_materialy/Cache%20consistency%20&amp;amp;%20MESI.pdf Cache consistency with MESI on Intel processor]&lt;br /&gt;
# [http://techreport.com/articles.x/8236/2 AMD dual core Architecture]&lt;br /&gt;
# [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD64 Architecture Programmer's manual]&lt;br /&gt;
# [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf Software Optimization guide for AMD 10h Processors]&lt;br /&gt;
# [http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html Architecture of AMD 64 bit core]&lt;br /&gt;
# [http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=4913 Silicon Graphics Computer Systems]&lt;br /&gt;
# [http://books.google.com/books?id=g82fofiqa5IC&amp;amp;printsec=frontcover&amp;amp;dq=Parallel+computer+architecture:+a+hardware/software+approach+By+David+E.+Culler,+Jaswinder+Pal+Singh,+Anoop+Gupta&amp;amp;source=bl&amp;amp;ots=COrdamlfVn&amp;amp;sig=YcugVqbzTjHvlofvaFq6Ft_tjfY&amp;amp;hl=en&amp;amp;ei=0ZO6S4TJGcOclgejzI3BBw&amp;amp;sa=X&amp;amp;oi=book_result&amp;amp;ct=result&amp;amp;resnum=1&amp;amp;ved=0CAgQ6AEwAA#v=onepage&amp;amp;q=&amp;amp;f=false Parallel computer architecture: a hardware/software approach By David E. Culler, Jaswinder Pal Singh, Anoop Gupta]&lt;br /&gt;
# [http://www.freepatentsonline.com/5283886.html Three state invalidation protocols]&lt;br /&gt;
# [http://portal.acm.org/citation.cfm?id=1499317&amp;amp;dl=GUIDE&amp;amp;coll=GUIDE&amp;amp;CFID=83027384&amp;amp;CFTOKEN=95680533 Synapse tightly coupled multiprocessors: a new approach to solve old problems]&lt;br /&gt;
# [http://portal.acm.org/citation.cfm?id=6514Cache Coherence protocols: evaluation using a multiprocessor simulation model]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Xerox_Dragon Xerox Dragon]&lt;br /&gt;
# [http://thanaseto.110mb.com/courses/CSD-527-report-engl.pdf Coherence Protocols]&lt;br /&gt;
# [http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=289691 XDBus]&lt;br /&gt;
# [http://www.ece.wisc.edu/~wddd/2002/final/ekman.pdf Evaluation of Snoop-Energy Reduction Techniques for Chip-Multiprocessors]&lt;br /&gt;
# [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.79.7463&amp;amp;rep=rep1&amp;amp;type=pdf Power Efficient Cache Coherence]&lt;br /&gt;
# [http://www.realworldtech.com/page.cfm?ArticleID=RWT082807020032&amp;amp;p=5 The Common System Interface: Intel's Future Interconnect]&lt;br /&gt;
# [http://support.amd.com/us/Processor_TechDocs/24593.pdf AMD64 Architecture Programmer's Manual Vol 2 'System Programming']&lt;br /&gt;
# [http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/search/srchabstract.jsp?tp=&amp;amp;arnumber=4606981&amp;amp;queryText%3D10.1109%2FICEPT.2008.4606981%26openedRefinements%3D*%26searchField%3DSearch+All 'The research of the inclusive cache used in multi-core processor' by Bin-feng Qian and Li-min Yan. ]&lt;br /&gt;
# [http://ieeexplore.ieee.org/search/srchabstract.jsp?tp=&amp;amp;arnumber=5375423&amp;amp;queryText%3D%28%28mesi%29+AND+moesi%29%26openedRefinements%3D*%26matchBoolean%3Dtrue%26searchField%3DSearch+All+Text 'Comparing cache architectures and coherency protocols on x86-64 multicore SMP systems' by Hackenberg, D., Molka, D. and Nagel, W.E.]&lt;/div&gt;</summary>
		<author><name>Mqtran</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2011/ch8_mc&amp;diff=44466</id>
		<title>CSC/ECE 506 Spring 2011/ch8 mc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2011/ch8_mc&amp;diff=44466"/>
		<updated>2011-03-20T01:26:41Z</updated>

		<summary type="html">&lt;p&gt;Mqtran: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Introduction to bus-based cache coherence in real machines=&lt;br /&gt;
&lt;br /&gt;
Most parallel software in the commercial market relies on the shared-memory&lt;br /&gt;
programming model in which all processors access the same physical address space. The most common multiprocessors today use [http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP] architecture which use a common bus as the interconnect.  In the case of multicore processors (&amp;quot;chip multiprocessors,&amp;quot; or CMP) the [http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP] architecture applies to the cores treating them as separate processors. The key problem of shared-memory multiprocessors is providing a consistent view of memory with various cache hierarchies.  This is called '''''cache coherence problem'''''. It is  critical to  achieve correctness and performance-sensitive design point for supporting the shared-memory model. The cache coherence mechanisms not only govern communication in a shared-memory multiprocessor, but also typically determine how the memory system transfers data between processors, caches, and memory.&lt;br /&gt;
&lt;br /&gt;
[[Image:Busbased SMP.jpg|frame|center|&amp;lt;b&amp;gt;Figure 1:&amp;lt;/b&amp;gt; Typical Bus-Based Processor Model]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Cache Coherence in real machines=&lt;br /&gt;
==Summary of Cache Coherence Protocols==&lt;br /&gt;
At any point in logical time, the permissions for a cache block can allow either a single writer or multiple readers. The '''''coherence protocol''''' ensures the invariants of the states are maintained. The different coherent states used by most of the cache coherent protocols are shown in ''Table 1'':&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''States'''&lt;br /&gt;
|  '''Access Type'''&lt;br /&gt;
|  '''Invariant'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  read, write&lt;br /&gt;
|  all other caches in I state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  read&lt;br /&gt;
|  all other caches in I state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Owned'''&lt;br /&gt;
|  read&lt;br /&gt;
|  all other caches in I or S state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  read&lt;br /&gt;
|  no other cache in M or E state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|  -&lt;br /&gt;
|  -&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 1:&amp;lt;/b&amp;gt; States Used by the Cache Coherent Protocols&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
The first widely adopted approach to cache coherence is snooping on a bus. We will now discuss them in details in the following sections.&lt;br /&gt;
&lt;br /&gt;
===MSI===&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI protocol]''' is a three-state write-back '''invalidation protocol''' which is one of the earliest snooping-based cache coherence-protocols. It marks the cache line with one of the '''Modified (M) ,Shared (S)''', and '''Invalid (I)''' state. '''Invalid''' means the cache line is either not present or is in invalid state. If the cache line is clean and is shared by more than one processor , it is marked as '''Shared'''. If a cache line is dirty and the processor has exclusive ownership of it, it is in '''Modified''' state. BusRdx causes other processors to invalidate (demote) its cache block to the '''I''' state. If it is present in the '''M''' state in another cache, it will flush. &lt;br /&gt;
&lt;br /&gt;
The following state transition diagram for MSI protocol explains the working of the protocol:&lt;br /&gt;
&lt;br /&gt;
[[Image:MSI.jpg|frame|center|&amp;lt;b&amp;gt;Figure 2:&amp;lt;/b&amp;gt; MSI State Diagram]]&lt;br /&gt;
&lt;br /&gt;
===MESI===&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI protocol]''' has a major drawback in that each read-write sequence incurs two bus transactions irrespective of whether the cache line is stored in only one cache or not. This is a huge setback for highly parallel programs that have little data sharing. '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol solves this problem by introducing the E ('''Exclusive''') state to distinguish between a cache line stored in multiple caches and a line stored in a single cache.&lt;br /&gt;
Let us briefly look at how the MESI protocol works. (For a more detailed version readers are referred to Solihin textbook pg. 215)&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' coherence protocol marks each cache line in one of the Modified, Exclusive, Shared or Invalid state. &lt;br /&gt;
* '''Invalid''' : The cache line is either not present or is invalid&lt;br /&gt;
* '''Exclusive''' : The cache line is clean and is owned by this core/processor only&lt;br /&gt;
* '''Modified''' :  This implies that the cache line is dirty and the core/processor has  exclusive ownership of the cache line, exclusive of the memory also.&lt;br /&gt;
* '''Shared''' : The cache line is clean and is shared by more than one core/processor&lt;br /&gt;
&lt;br /&gt;
In a nutshell, the '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol works as the following: &lt;br /&gt;
A line that is just fetched receives '''E''' or '''S''' state depending on whether it exists in other processors in the system or not. Similarly, a cache line gets the '''M''' state when a processor writes to it. If the line is not in '''E''' or '''M''' state prior to being written to, the cache sends a Bus Upgrade (BusUpgr) signal or as the Intel manuals call it, a “Read-For-Ownership (RFO) request” that ensures that the line exists in the cache and is in the '''I''' state in all other processors on the bus (if any). The table shown below will summarize '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''Cache Line State:'''&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''This cache line is valid?'''&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  No&lt;br /&gt;
|-&lt;br /&gt;
|  '''The memory copy is…'''&lt;br /&gt;
|  out of date&lt;br /&gt;
|  valid&lt;br /&gt;
|  valid&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''Copies exist in caches of other processors?'''  &lt;br /&gt;
|  No&lt;br /&gt;
|  No&lt;br /&gt;
|  Maybe&lt;br /&gt;
|  Maybe&lt;br /&gt;
|-&lt;br /&gt;
|  '''A write to this line'''&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  goes to bus and updates cache&lt;br /&gt;
|  goes directly to bus&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 2:&amp;lt;/b&amp;gt; MESI Protocol Summary&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The transition diagram from the lecture slides is given below for reference.&lt;br /&gt;
&lt;br /&gt;
[[Image:MESI.jpg|frame|center|&amp;lt;b&amp;gt;Figure 4:&amp;lt;/b&amp;gt; MESI State Diagram]]&lt;br /&gt;
&lt;br /&gt;
===MESIF===&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/MESIF_protocol MESIF]''' protocol, used in the latest Intel multi-core processors Core i7, was introduced to '''accommodate the point-to-point''' links used in the QuickPath Interconnect. Using the '''MESI''' protocol in this architecture would send many redundant messages between different processors, often with unnecessarily high latency. For example, when a processor requests a cache line that is stored in multiple locations, every location might respond with the data. As the requesting processor only needs a single copy of the data, the system would be '''wasting the bandwidth'''. &lt;br /&gt;
As a '''solution''' to this problem, an additional state, '''Forward state''', was added by slightly changing the role of the Shared state. Whenever there is a read request, only the cache line in the F state will respond to the request, while all the S state caches remain dormant.  Hence, by designating a single cache line to '''respond to requests''', coherency traffic is substantially reduced when multiple copies of the data exist. Also, on a read request, the F state transitions to the S state. That is, when a cache line in the '''F''' state is '''copied''', the F state '''migrates''' to the '''newer copy''', while the '''older''' one drops back to the '''S''' state. Moving the new copy to the F state '''exploits''' both '''temporal and spatial locality'''. Because the newest copy of the cache line is always in the F state, it is very unlikely that the line in the F state will be evicted from the caches. This takes advantage of the temporal locality of the request. The second advantage is that if a particular cache line is in high demand due to spatial locality, the bandwidth used to transmit that data will be spread across several cores.&lt;br /&gt;
All M to S state transitions and E to S state transitions will now be from '''M to F''' and '''E to F'''.  &lt;br /&gt;
The '''F state''' is '''different''' from the '''Owned state''' of the MOESI protocol as it is '''not''' a '''unique''' copy because a valid copy is stored in memory. Thus, unlike the Owned state of the MOESI protocol, in which the data in the O state is the only valid copy of the data, the data in the F state can be evicted or converted to the S state, if desired. &lt;br /&gt;
&lt;br /&gt;
More information on the QuickPath Interconnect and MESIF protocol can be found at&lt;br /&gt;
'''[http://www.intel.com/technology/quickpath/introduction.pdf Introduction to QuickPath Interconnect]'''. &lt;br /&gt;
&lt;br /&gt;
===MOESI===&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/Opteron AMD Opteron] was AMD’s first-generation dual core processor which had two distinct [http://en.wikipedia.org/wiki/Athlon_64 K8 cores] together on a single die. Cache coherence produces bigger problems on such multicore processors. It was necessary to use an appropriate coherence protocol to address this problem. The [http://en.wikipedia.org/wiki/Xeon Intel Xeon], which was the competitive counterpart from Intel to AMD dual core Opteron, used the [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol to handle cache coherence. [http://en.wikipedia.org/wiki/MESI_protocol MESI] came with the drawback of using much time and bandwidth in certain situations. &lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/MOESI_protocol MOESI] was AMD’s answer to this problem. [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] added a fifth state to [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol called the '''owned''' state. [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol addresses the bandwidth problem faced by MESI protocol when processor having invalid data in its cache wants to modify the data.  The processor seeking the data will have to wait for the processor which modified this data to write back to the main memory, which takes time and bandwidth. This drawback is removed in MOESI by allowing dirty sharing.  When the data is held by a processor in the new state '''owned''', it can provide other processors the modified data without writing it to the main memory. This is called '''''dirty sharing'''''. The processor with the data in the '''owned''' state stays responsible to update the main memory later when the cache line is evicted.&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/MOESI_protocol MOESI]  has become one of the most popular snoop-based protocols supported in AMD64 architecture.  AMD dual-core Opteron can maintain cache coherence in systems up to 8 processors using this protocol.&lt;br /&gt;
&lt;br /&gt;
The five different states of [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol are:&lt;br /&gt;
* '''Modified (M)''': The most recent copy of the data is present in the cache line. But it is not present in any other processor cache.&lt;br /&gt;
* '''Owned (O)''': The cache line has the most recent correct copy of the data. This can be shared by other processors. The processor in this state for this cache line is responsible to update the correct value in the main memory before it gets evicted.&lt;br /&gt;
* '''Exclusive (E)''': A cache line holds the most recent, correct copy of the data, which is exclusively present on this processor and a copy is present in the main memory.&lt;br /&gt;
* '''Shared (S)''': A cache line in the shared state holds the most recent, correct copy of the data, which may be shared by other processors.&lt;br /&gt;
* '''Invalid (I)''': A cache line does not hold a valid copy of the data.&lt;br /&gt;
&lt;br /&gt;
A detailed explanation of this protocol implementation on AMD processor can be found in the manual [http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html Architecture of AMD 64-bit core]&lt;br /&gt;
&lt;br /&gt;
The following table summarizes the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''Cache Line State:'''&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  '''Owner''' &lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''This cache line is valid?'''&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  No&lt;br /&gt;
|-&lt;br /&gt;
|  '''The memory copy is…'''&lt;br /&gt;
|  out of date&lt;br /&gt;
|  out of date&lt;br /&gt;
|  valid&lt;br /&gt;
|  valid&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''Copies exist in caches of other processors?'''&lt;br /&gt;
|  No&lt;br /&gt;
|  No&lt;br /&gt;
|  Yes(out of date values)|  Maybe&lt;br /&gt;
|  Maybe&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''A write to this line'''&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  does not go to bus|  does not go to bus&lt;br /&gt;
|  goes to bus and updates cache&lt;br /&gt;
|  goes directly to bus&lt;br /&gt;
|  -&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 3:&amp;lt;/b&amp;gt; MOESI Protocol Summary&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
State transition for [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]is as shown below : &lt;br /&gt;
&lt;br /&gt;
[[Image:MOESI_State_Transition_Diagram.jpg|frame|center|&amp;lt;b&amp;gt;Figure 7:&amp;lt;/b&amp;gt; [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]State transition Diagram]]&lt;br /&gt;
&lt;br /&gt;
We will now discuss which cache coherence protocol processor vendors like '''Intel''', '''AMD''' and others adopt in various products.&lt;br /&gt;
&lt;br /&gt;
===Cache Coherence Protocols and Their Performance===&lt;br /&gt;
Of all protocols, MSI appears to have the worst performance due to the fact that each read-write sequence incurs two bus transactions even if the data is stored in only one cache. This causes a huge performance penalty for highly optimized parallel programs that have little data sharing. MESI protocol solves this problem by introducing the E (Exclusive) state to distinguish between a cache line stored in multiple caches and a line stored in only one cache. This protocol, however, can still be improved further. &lt;br /&gt;
&lt;br /&gt;
One remaining issue with MESI protocol is that in multi-processor configuration, when a processor requests a cache line that is stored in multiple cache, every cache might respond with the data. This behavior would waste bus bandwidth and incur high latency. As a solution to this problem, MESIF protocol was introduced. An additional state, Forward state, was added by slightly changing the role of the Shared state. The result of this improvement is that instead of all caches responding, only the cache line in the F state will respond to the request, while all the S state caches remain dormant. As a result, performance and power efficiency is increased. &lt;br /&gt;
&lt;br /&gt;
Another problem with MESI protocol is when a processor having invalid data in its cache wants to modify the data, it will have to wait for the other processor to write back to the memory, which is a very slow process. MOESI protocol solves this problem by allowing dirty&lt;br /&gt;
sharing. This also saves bus bandwidth and increases performance.&lt;br /&gt;
==SGI - Silicon Graphics, Inc==&lt;br /&gt;
===MSI &amp;amp; SGI IRIS 4D Processors===&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' protocol was first used in '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''' IRIS 4D series. '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''' produced a broad range of '''[http://en.wikipedia.org/wiki/MIPS_architecture MIPS]'''-based (Microprocessor without Interlocked Pipeline Stages) workstations and servers during the 1990s, running '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''''s version of UNIX System V, now called '''[http://en.wikipedia.org/wiki/IRIX IRIX]'''. The 4D-MP graphics superworkstation brought 40 MIPS(million instructions per second) of computing performance to a graphics superworkstation. The unprecedented level of computing and graphics processing in an office-environment workstation was made possible by the fastest available Risc microprocessors in a single shared memory multiprocessor design driving a tightly coupled, highly parallel graphics system. Aggregate sustained data rates of over one gigabyte per second were achieved by a hierarchy of buses in a balanced system designed to avoid bottlenecks.&lt;br /&gt;
&lt;br /&gt;
The multiprocessor bus used in 4D-MP graphics superworkstation is a pipelined, block transfer bus that supports the cache coherence protocol as well as providing 64 megabytes of sustained data bandwidth between the processors, the memory and I/O system, and the graphics subsystem. Because the sync bus provides for efficient synchronization between processors, the cache coherence protocol was designed to support efficient data sharing between processors. If a cache coherence protocol has to support synchronization as well as sharing, a compromise in the efficiency of the data sharing protocol may be necessary to improve the efficiency of the synchronization operations. Hence it uses the simple cache coherence protocol which is the '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' protocol.&lt;br /&gt;
&lt;br /&gt;
With the simple rules of '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]'''protocol enforced by hardware, efficient synchronization and efficient data sharing are achieved in a simple shared memory model of parallel processing in the 4D-MP graphics superworkstation.&lt;br /&gt;
&lt;br /&gt;
==SYNAPSE Multiprocessor==&lt;br /&gt;
===Synapse protocol and Synapse multiprocessor===&lt;br /&gt;
From the state transition diagram of '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''', we observe that for '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' there is transition to the '''S''' state from the '''M''' state when a BusRd is observed for that block. The contents of the block is flushed to the bus before going to '''S''' state. It would look more appropriate to move to the '''I''' state thus giving up the block entirely in certain cases. This choice of moving to '''S''' or '''I''' reflects the designer's assertion that the original processor is more likely to continue reading the block than the new processor to write to the block. In synapse protocol, used in the early Synapse multiprocessor, made this alternate choice of going directly from the '''M''' state to the '''I''' state on a BusRd, assuming the migratory pattern would be more frequent. More details about this protocol can be found in these papers published in late 1980's [http://portal.acm.org/citation.cfm?id=6514Cache Coherence protocols: evaluation using a multiprocessor simulation model] and [http://portal.acm.org/citation.cfm?id=1499317&amp;amp;dl=GUIDE&amp;amp;coll=GUIDE&amp;amp;CFID=83027384&amp;amp;CFTOKEN=95680533 Synapse tightly coupled multiprocessors: a new approach to solve old problems]&lt;br /&gt;
&lt;br /&gt;
In the Synapse protocol, the '''M''' state is called the '''D''' (Dirty) state. The following is the state transition diagram for Synapse protocol which clearly shows its working.&lt;br /&gt;
&lt;br /&gt;
[[Image:Synapse1.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; Synapse State Diagram]]&lt;br /&gt;
&lt;br /&gt;
==Intel==&lt;br /&gt;
===MESI &amp;amp; Intel Processors===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The '''Pentium Pro''' microprocessor, introduced in 1992 was the '''first''' Intel architecture microprocessor to support symmetric multiprocessing ('''[http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP]''') in various multiprocessor configurations. '''[http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP]''' and '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol was the architecture used consistently until the introduction of the 45-nm Hi-k Core micro-architecture in '''Intel's (Nehalem-EP) quad-core x86-64'''. The 45-nm Hi-k Intel Core microarchitecture utilizes a new system of framework called the '''QuickPath Interconnect''' which uses point-to-point interconnection technology based on distributed shared memory architecture. It uses a modified version of '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol called '''MESIF''', by introducing an additional state, F, the forward state. &lt;br /&gt;
&lt;br /&gt;
The '''Intel architecture''' uses the '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol  as the '''basis''' to ensure cache coherence, which is true whether you're on one of the older processors that use a '''common bus''' to communicate or using the new Intel '''QuickPath''' point-to-point interconnection technology. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== CMP Implementation in Intel Architecture ===&lt;br /&gt;
&lt;br /&gt;
Let us now see how Intel architecture using the [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol progressed from a uniprocessor architecture to a Chip MultiProcessor (CMP) using the bus as the interconnect. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Uniprocessor Architecture'''&lt;br /&gt;
&lt;br /&gt;
The diagram below shows the structure of the memory cluster in Intel Pentium M processor.&lt;br /&gt;
&lt;br /&gt;
[[Image:intel_cache1.jpg|frame|center|&amp;lt;b&amp;gt;Figure 5:&amp;lt;/b&amp;gt; Memory Structure of the Pentium M Processor]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In this structure we have,&lt;br /&gt;
* A unified on-chip '''L1 cache''' with the '''processor/core''',&lt;br /&gt;
* A '''Memory/L2 access control unit''', through which all the accesses to the L2 cache, main memory and IO space are made,&lt;br /&gt;
* The second level '''L2 cache''' along with the '''prefetch unit''' and&lt;br /&gt;
* '''Front side bus (FSB)''', a single shared bi-directional bus through which all the traffic is sent across.These wide buses bring in multiple data bytes at a time. &lt;br /&gt;
&lt;br /&gt;
As Intel explains it, using this structure, the processor requests were first sought in the '''L2 cache''' and only on a '''miss''', were they '''forwarded''' to the main '''memory''' via the front side bus ('''FSB'''). The '''Memory/L2 access control''' unit served as a central point for '''maintaining coherence''' within the core and with the external world. It '''contains''' a '''snoop control unit''' that receives snoop requests from the bus and performs the required operations on each cache (and internal buffers) in parallel. It also handles RFO requests (BusUpgr) and ensures the operation continues only after it guarantees that no other version on the cache line exists in any other cache in the system.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''CMP Architecture'''&lt;br /&gt;
&lt;br /&gt;
For CMP implementation, Intel chose the bus-based architecture using snoopy protocols vs the '''directory protocol''' because though directory protocol reduces the active power due to reduced snoop activity, it '''increased''' the '''design complexity''' and the '''static power''' due to larger tag arrays. Since Intel has a large market for the processors in the mobility family, directory-based solution was less favorable since battery life mainly depends on static power consumption and less on dynamic power.&lt;br /&gt;
Let us examine how '''CMP''' was implemented in '''Intel Core Duo''', which was one of the first dual-core processor for the budget/entry-level market. &lt;br /&gt;
The general CMP implementation structure of the Intel Core Duo is shown below&lt;br /&gt;
&lt;br /&gt;
[[Image:intel_cache2.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; Intel Core Duo CMP Implementation]]&lt;br /&gt;
&lt;br /&gt;
This structure has the following changes when compared to the uniprocessor memory cluster structure. &lt;br /&gt;
* '''L1 cache''' and the '''processor/core''' structure is '''duplicated''' to give 2 cores.&lt;br /&gt;
* The '''Memory/L2 access control''' unit is '''split''' into 2 logical units: '''L2 controller''' and '''bus controller'''. The L2 controller handles all '''requests to the L2''' cache from the core and the snoop requests from the FSB. The '''bus controller''' handles '''data and I/O requests''' to and from the FSB.&lt;br /&gt;
* The '''prefetching''' unit is extended to handle the hardware '''prefetches for each core separately'''.&lt;br /&gt;
* A '''new logical unit''' (represented by the hexagon) was added to maintain '''fairness between the requests''' coming from the different cores and hence balance the requests to L2 and memory.&lt;br /&gt;
&lt;br /&gt;
This new '''partitioned structure''' for the  memory/L2 access control unit '''enhanced''' the '''performance''' while '''reducing power consumption'''. &lt;br /&gt;
For more information on uniprocessor and multiprocessor implementation under the Intel architecture, refer to &lt;br /&gt;
[http://www.intel.com/technology/itj/2006/volume10issue02/art02_CMP_Implementation/p03_implementation.htm CMP Implementation in Intel Core Duo Processors]&lt;br /&gt;
&lt;br /&gt;
The '''Intel bus architecture''' has been '''evolving''' in order to accommodate the demands of scalability while using the '''same [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol'''; From using a '''single shared bus''' to '''dual independent buses (DIB)''' doubling the available bandwidth and to the logical conclusion of DIB with the introduction of '''dedicated high-speed interconnects (DHSI)'''. The DHSI-based platforms use four FSBs, one for each processor in the platform. In both DIB and DHSI, the snoop filter was used in the chipset to cache snoop information, thereby significantly reducing the broadcasting needed for the snoop traffic on the buses. With the production of processors based on next generation 45-nm Hi-k Intel Core microarchitecture, the [http://en.wikipedia.org/wiki/Xeon Intel Xeon] processor fabric will transition from a DHSI, with the memory controller in the chipset, to a distributed shared memory architecture using '''Intel QuickPath Interconnects using MESIF protocol'''.&lt;br /&gt;
&lt;br /&gt;
==AMD - Advanced Micro Devices Processors==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===MOESI &amp;amp; AMD Processors===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===AMD Opteron memory Architecture===&lt;br /&gt;
&lt;br /&gt;
[[Image:Untitled.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; AMD Opteron memory Architecture]]&lt;br /&gt;
&lt;br /&gt;
The AMD processor’s high-performance cache architecture includes an integrated, 64-bit, dual-ported  128-Kbyte split-L1 cache with separate snoop port, multi-level translation lookaside buffers (TLBs), a scalable L2 cache controller with a 72-bit (64-bit data + 8-bit ECC) interface to as much as 8-Mbyte of industry-standard SDR or DDR SRAMs, and an integrated tag for the most cost-effective 512-Kbyte L2 configurations. The AMD Athlon processor’s integrated L1 cache comprises two separate 64-Kbyte, two-way set-associative data and instruction caches.&lt;br /&gt;
&lt;br /&gt;
More information about this can be found in [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD 64 bit Architecture Programmers's Manual]&lt;br /&gt;
&lt;br /&gt;
===Special Coherence Considerations in AMD64 architectures===&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
Instruction prefetching is a technique used to speedup the execution of the program. But in multiprocessors, prefetching comes at the cost of performance. Due to prefetching, the data can be modified in such a way that the memory coherence protocol will not be able to handle the effects. In such situations software must use serializing instructions or cache-invalidation instructions to guarantee subsequent data accesses are coherent. &lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
An example of this type of a situation is a page-table update followed by accesses to the physical pages referenced by the updated page tables. The physical-memory references for the page tables are different than the physical-memory references for the data. Because of prefetching, there maybe problem with correctness. The following sequence of events shows such a situation when software changes the translation of virtual-page A from physical-page M to physical-page N:&lt;br /&gt;
# The tables that translate virtual-page A to physical-page M are now held only in main memory. The copies in the cache ae invalidated.&lt;br /&gt;
# Page-table entry is changed by the software for virtual-page A in main memory to point to physical page N rather than physical-page M.&lt;br /&gt;
# Data in virtual-page A is accessed.&lt;br /&gt;
&lt;br /&gt;
Software expects the processor to access the data from physical-page N after the update. However, it is possible for the processor to prefetch the data from physical-page M before the page table for virtual page A is updated. Because the physical-memory references are different, the processor does not recognize them as requiring coherence checking and believes it is safe to prefetch the data from virtual-page A, which is translated into a read from physical page M. Similar behavior can occur when instructions are prefetched from beyond the page table update instruction.&lt;br /&gt;
&lt;br /&gt;
In order to prevent errors from occuring, there are special instructions provided by software like INVLPG or MOV CR3 instruction which is executed immediately after the page-table update to ensure that subsequent instruction fetches and data accesses use the correct virtual-page-to-physical-page translation. It is not necessary to perform a TLB invalidation operation preceding the table update.&lt;br /&gt;
&lt;br /&gt;
More information can be found about this in [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD64 Architecture Programmer's manual]&lt;br /&gt;
&lt;br /&gt;
===Optimization techniques on MOESI when implemented on AMD Phenom processors===&lt;br /&gt;
&lt;br /&gt;
In real machines, using some optimization techniques on the standard cache coherence protocol used, improves the performance of the machine. For example, [http://en.wikipedia.org/wiki/AMD_Phenom AMD Phenom] family of microprocessors (Family 0×10) which is AMD’s first generation to incorporate 4 distinct cores on a single die. It is the first to have a cache that all the cores share, using the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol with some optimization techniques incorporated. &lt;br /&gt;
&lt;br /&gt;
It focuses on a small subset of compute problems which behave like Producer and Consumer programs. In such a computing problem, a thread of a program running on a single core produces data, which is consumed by a thread that is running on a separate core. With such programs, it is desirable to get the two distinct cores to communicate through the shared cache, to avoid round trips to/from main memory. The '''MOESI''' protocol that the [http://en.wikipedia.org/wiki/AMD_Phenom AMD Phenom] cache uses for cache coherence can also limit bandwidth. Hence by keeping the cache line in the '''M''' state for such computing problems, we can achieve better performance.&lt;br /&gt;
&lt;br /&gt;
When the producer thread , writes a new entry, it allocates cache-lines in the '''M''' state. Eventually, these M-marked cache lines will start to fill the L3 cache. When the consumer reads the cache line, the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol changes the state of the cache line to the '''O''' state in the L3 cache and pulls down a '''shared (S)''' copy for its own use. Now, the producer thread circles the ring buffer to arrive back to the same cache line it had previously written. However, when the producer attempts to write new data to the owned (marked '''‘O’''') cache line, it finds that it cannot, since a cache line in the '''O''' state by the previous consumer read does not have sufficient permission for a write request (in the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]). To maintain coherence, the memory controller must initiate probes in the other caches (to handle any other S copies that may exist). This will slow down the process.&lt;br /&gt;
&lt;br /&gt;
Thus, it is preferable to keep the cache line in the '''M''' state in the L3 cache. In such a situation, when the producer comes back around the ring buffer, it finds the previously written cache line still in the'''M''' state, to which it is safe to write without coherence concerns. Thus better performance can be achieved by such optimization techniques to standard protocols when implemented in real machines.&lt;br /&gt;
&lt;br /&gt;
You can find more information on how this is implemented and various other ways of optimizations in this manual [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf Software Optimization guide for AMD 10h Processors].&lt;br /&gt;
&lt;br /&gt;
==Xerox Corporation==&lt;br /&gt;
===Dragon Protocol &amp;amp; Xerox Dragon Processors===&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' is an update based coherence protocol which does not invalidate other cached copies like what we have seen in the coherence protocols so far. Write propagation is achieved by updating the cached copies instead of invalidating them.  But the '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' does not update memory on a cache to cache transfer and delays the memory and cache consistency until the data is evicted and written back, which saves time and lowers the memory access requirements. Moreover only the written '''byte''' or the '''word''' is '''communicated''' to the '''other caches''' instead of the whole block which further '''reduces''' the '''bandwidth''' usage. It has the ability to detect dynamically, the sharing status of a block and use a write through policy for shared blocks and write back for currently non-shared blocks. The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' employs the following four states for the cache blocks: '''Shared Clean''', '''Shared Modified''', '''Exclusive''', and  '''Modified'''. &lt;br /&gt;
* '''Modified (M)''' and '''Exclusive (E)''' - these states have the same meaning as explained in the protocols above. &lt;br /&gt;
* '''Shared Modified (Sm)''' - Only one cache line in the system can be in the Shared Modified state. Potentially two or more caches    have this block and memory may or may not be up to date and this processor's cache had modified the block.&lt;br /&gt;
* '''Shared Clean (Sc)''' -  Potentially two or more caches have this block and memory may or may not be up to date(if no other cache has it in Sm state, memory will be up to date else it is not).&lt;br /&gt;
When a Shared Modified line is evicted from the cache on a cache miss only then is the block written back to the main memory in order to keep memory consistent. For more information on Dragon protocol, refer to Solihin textbook, page number 229. The state transition diagram has been given below for reference.&lt;br /&gt;
&lt;br /&gt;
[[Image:Dragon.jpg|frame|center|&amp;lt;b&amp;gt;Figure 9:&amp;lt;/b&amp;gt; Dragon Protocol State Diagram]]&lt;br /&gt;
&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' , was developed by Xerox Palo Alto Research Center ('''[http://en.wikipedia.org/wiki/Xerox_PARC Xerox PARC]'''), a subsidiary of Xerox Corporation.  This protocol was used in the '''[http://en.wikipedia.org/w/index.php?title=Xerox_Dragon&amp;amp;redirect=no Xerox PARC Dragon]''' multiprocessor workstation, a VLSI research computer that could support multiple processors on a central high bandwidth memory bus. The Dragon design implemented snoopy caches that provided the appearance of a uniform memory space to multiple processors. Here, each cache listens to 2 buses: the processor bus and the memory bus. The caches are also responsible for address translation, so the processor bus carries virtual addresses and the memory bus carries physical addresses.  The Dragon system was designed to support 4 to 8 Dragon processors. The memory bus used in the Xeron Dragon evolved to become the '''[http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=289691 XDBus]''' , a low-cost, synchronous, '''packet-switched VLSI bus''' designed for use in high-performance multiprocessors. This was used as the interconnect in many multiprocessor server systems like '''Cray Superserver 6400''', '''Sun Microsystems' SPARCcenter 2000''' and '''SPARCserver 1000'''  and '''Sun4d''' systems.&lt;br /&gt;
&lt;br /&gt;
=Cache Coherence Power Utilization=&lt;br /&gt;
A number of studies have been performed to reduce the power consumption of cache coherence protocols. In order to perform a solid comparison between the cache coherency protocols, one would need to develop a multi-core processor for each of the cache coherency protocols. Additionally, the hardware and software configuration would also need to be similar between each system (except for the hardware required to implement each of the different protocols). Unfortunately, there are no such processors available. This section will discuss power consumption in general terms, comparing to each of the protocols. Also, this section will briefly discussion some power optimization techniques.&lt;br /&gt;
&lt;br /&gt;
Bus transactions, in general, are costly for both performance and power consumption. Additionally, studies have been performed showing that unnecessary snooping can waste power. Power requirements are typically determined by the number of bus snoops and number of bus accesses by each processor. One study indicates that interchip bus communications can consume up to 20% of total chip power[[#References|&amp;lt;sup&amp;gt;[20]&amp;lt;/sup&amp;gt;]].&lt;br /&gt;
Using the examples from the class notes, we can analyze the relative power consumption between the protocols. The following table is a summary of various protocols showing the number of bus communications that occur for each processor action.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|'''Processor Action'''&lt;br /&gt;
|'''MSI Bus Actions'''&lt;br /&gt;
|'''MESI Bus Actions'''&lt;br /&gt;
|'''Dragon Bus Actions'''&lt;br /&gt;
|'''FireFly Bus Actions'''&lt;br /&gt;
|-&lt;br /&gt;
|R1&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|-&lt;br /&gt;
|W1&lt;br /&gt;
|BusRdX&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R3&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|-&lt;br /&gt;
|W3&lt;br /&gt;
|BusRdX&lt;br /&gt;
|BusRdX&lt;br /&gt;
|BusUpd/Upd&lt;br /&gt;
|BusUpd&lt;br /&gt;
|-&lt;br /&gt;
|R1&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R3&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R2&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 4:&amp;lt;/b&amp;gt; Summary of Bus Actions for Select Protocols&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
From the table above, we can see that MSI has a larger number of bus transactions than the Dragon protocol. Even though bus transactions are not power efficient, snooping can also be enhanced to improve power efficiency. The following section will discuss snoop filtering techniques.&lt;br /&gt;
&lt;br /&gt;
==Power Savings Using Snoop Filtering==&lt;br /&gt;
A number of studies have been performed to reduce the number of unnecessary snoops during cache transactions. Two such filtering techniques are serial snooping and Jetty. The following sections will briefly discuss these two filtering techniques and power savings achieved using these techniques. Studies show that as much as 90% of snoop broadcasts will result in a miss[[#References|&amp;lt;sup&amp;gt;[19]&amp;lt;/sup&amp;gt;]] in the other caches at the same level and require that the information be provided by the next level of cache or memory. As much as a 36% savings in power by filtering snoops using one of the following snoop filtering methods[[#References|&amp;lt;sup&amp;gt;[19]&amp;lt;/sup&amp;gt;]].&lt;br /&gt;
===Serial Snooping===&lt;br /&gt;
Serial snooping takes advantage of the fact that if a miss occurs in one cache, it is possible to find the block in one other cache without having to check all the caches. If the cache block is available in multiple caches, there is a high probability that the cache miss can find the data in a nearby cache. Alternatively, savings can be realized by searching a subset of the caches vice all the caches. One thing to note is that this is only effective for read misses. Write, an invalidation transaction needs to be transmitted to the other caches, thus a bus transaction is unavoidable.&lt;br /&gt;
===Jetty===&lt;br /&gt;
Jetty is a mechanism attached to each cache that verifies that a bus snoop is necessary. Jetty is used to filter L2 tag lookups. When a processor needs to perform a bus snoop, the Jetty is checked first. The Jetty can determine if a cache tag lookup is required. Since the Jetty is much smaller than the associated cache, less power is required to determine if a snoop is required.&lt;br /&gt;
&lt;br /&gt;
There are a couple of different Jetty schemes. There is the exclude-Jetty, include-Jetty, and hybrid-Jetty. The exclude-Jetty exploits the fact that if a cache block is snooped, it is highly likely the same cache block will be snooped in the near future. The exclude-Jetty keeps track of the tag lookups in a small table and can determine if a cache tag lookup is necessary.&lt;br /&gt;
&lt;br /&gt;
The include-Jetty keeps a superset of the blocks that are cached. If a miss occurs in the include-Jetty, then it can be guaranteed that the block is not stored in its associated cache.&lt;br /&gt;
&lt;br /&gt;
The hybrid-Jetty is simply a combinations of and include and exclude-Jetty. Both types of Jetty are present and when a lookup occurs, both Jettys are checked to determine if a cache lookup is necessary.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Cache_coherence Cache coherence]&lt;br /&gt;
# [http://www.intel.com/technology/quickpath/introduction.pdf Introduction to QuickPath Interconnect]&lt;br /&gt;
# [http://www.intel.com/technology/itj/2006/volume10issue02/art02_CMP_Implementation/p03_implementation.htm CMP Implementation in Intel Core Duo Processors]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Symmetric_multiprocessing Common System Interface in Intel Processors]&lt;br /&gt;
# [http://www.zak.ict.pwr.wroc.pl/nikodem/ak_materialy/Cache%20consistency%20&amp;amp;%20MESI.pdf Cache consistency with MESI on Intel processor]&lt;br /&gt;
# [http://techreport.com/articles.x/8236/2 AMD dual core Architecture]&lt;br /&gt;
# [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD64 Architecture Programmer's manual]&lt;br /&gt;
# [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf Software Optimization guide for AMD 10h Processors]&lt;br /&gt;
# [http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html Architecture of AMD 64 bit core]&lt;br /&gt;
# [http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=4913 Silicon Graphics Computer Systems]&lt;br /&gt;
# [http://books.google.com/books?id=g82fofiqa5IC&amp;amp;printsec=frontcover&amp;amp;dq=Parallel+computer+architecture:+a+hardware/software+approach+By+David+E.+Culler,+Jaswinder+Pal+Singh,+Anoop+Gupta&amp;amp;source=bl&amp;amp;ots=COrdamlfVn&amp;amp;sig=YcugVqbzTjHvlofvaFq6Ft_tjfY&amp;amp;hl=en&amp;amp;ei=0ZO6S4TJGcOclgejzI3BBw&amp;amp;sa=X&amp;amp;oi=book_result&amp;amp;ct=result&amp;amp;resnum=1&amp;amp;ved=0CAgQ6AEwAA#v=onepage&amp;amp;q=&amp;amp;f=false Parallel computer architecture: a hardware/software approach By David E. Culler, Jaswinder Pal Singh, Anoop Gupta]&lt;br /&gt;
# [http://www.freepatentsonline.com/5283886.html Three state invalidation protocols]&lt;br /&gt;
# [http://portal.acm.org/citation.cfm?id=1499317&amp;amp;dl=GUIDE&amp;amp;coll=GUIDE&amp;amp;CFID=83027384&amp;amp;CFTOKEN=95680533 Synapse tightly coupled multiprocessors: a new approach to solve old problems]&lt;br /&gt;
# [http://portal.acm.org/citation.cfm?id=6514Cache Coherence protocols: evaluation using a multiprocessor simulation model]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Xerox_Dragon Xerox Dragon]&lt;br /&gt;
# [http://thanaseto.110mb.com/courses/CSD-527-report-engl.pdf Coherence Protocols]&lt;br /&gt;
# [http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=289691 XDBus]&lt;br /&gt;
# [http://www.ece.wisc.edu/~wddd/2002/final/ekman.pdf Evaluation of Snoop-Energy Reduction Techniques for Chip-Multiprocessors]&lt;br /&gt;
# [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.79.7463&amp;amp;rep=rep1&amp;amp;type=pdf Power Efficient Cache Coherence]&lt;br /&gt;
# [http://www.realworldtech.com/page.cfm?ArticleID=RWT082807020032&amp;amp;p=5 The Common System Interface: Intel's Future Interconnect]&lt;br /&gt;
# [http://support.amd.com/us/Processor_TechDocs/24593.pdf AMD64 Architecture Programmer's Manual Vol 2 'System Programming']&lt;br /&gt;
# [http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/search/srchabstract.jsp?tp=&amp;amp;arnumber=4606981&amp;amp;queryText%3D10.1109%2FICEPT.2008.4606981%26openedRefinements%3D*%26searchField%3DSearch+All 'The research of the inclusive cache used in multi-core processor' by Bin-feng Qian and Li-min Yan. ]&lt;br /&gt;
# [http://ieeexplore.ieee.org/search/srchabstract.jsp?tp=&amp;amp;arnumber=5375423&amp;amp;queryText%3D%28%28mesi%29+AND+moesi%29%26openedRefinements%3D*%26matchBoolean%3Dtrue%26searchField%3DSearch+All+Text 'Comparing cache architectures and coherency protocols on x86-64 multicore SMP systems' by Hackenberg, D., Molka, D. and Nagel, W.E.]&lt;/div&gt;</summary>
		<author><name>Mqtran</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2011/ch8_mc&amp;diff=44465</id>
		<title>CSC/ECE 506 Spring 2011/ch8 mc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2011/ch8_mc&amp;diff=44465"/>
		<updated>2011-03-20T01:10:04Z</updated>

		<summary type="html">&lt;p&gt;Mqtran: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Introduction to bus-based cache coherence in real machines=&lt;br /&gt;
&lt;br /&gt;
Most parallel software in the commercial market relies on the shared-memory&lt;br /&gt;
programming model in which all processors access the same physical address space. The most common multiprocessors today use [http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP] architecture which use a common bus as the interconnect.  In the case of multicore processors (&amp;quot;chip multiprocessors,&amp;quot; or CMP) the [http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP] architecture applies to the cores treating them as separate processors. The key problem of shared-memory multiprocessors is providing a consistent view of memory with various cache hierarchies.  This is called '''''cache coherence problem'''''. It is  critical to  achieve correctness and performance-sensitive design point for supporting the shared-memory model. The cache coherence mechanisms not only govern communication in a shared-memory multiprocessor, but also typically determine how the memory system transfers data between processors, caches, and memory.&lt;br /&gt;
&lt;br /&gt;
[[Image:Busbased SMP.jpg|frame|center|&amp;lt;b&amp;gt;Figure 1:&amp;lt;/b&amp;gt; Typical Bus-Based Processor Model]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Cache Coherence in real machines=&lt;br /&gt;
==Summary of Cache Coherence Protocols==&lt;br /&gt;
At any point in logical time, the permissions for a cache block can allow either a single writer or multiple readers. The '''''coherence protocol''''' ensures the invariants of the states are maintained. The different coherent states used by most of the cache coherent protocols are shown in ''Table 1'':&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''States'''&lt;br /&gt;
|  '''Access Type'''&lt;br /&gt;
|  '''Invariant'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  read, write&lt;br /&gt;
|  all other caches in I state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  read&lt;br /&gt;
|  all other caches in I state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Owned'''&lt;br /&gt;
|  read&lt;br /&gt;
|  all other caches in I or S state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  read&lt;br /&gt;
|  no other cache in M or E state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|  -&lt;br /&gt;
|  -&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 1:&amp;lt;/b&amp;gt; States Used by the Cache Coherent Protocols&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
The first widely adopted approach to cache coherence is snooping on a bus. We will now discuss them in details in the following sections.&lt;br /&gt;
&lt;br /&gt;
===MSI===&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI protocol]''' is a three-state write-back '''invalidation protocol''' which is one of the earliest snooping-based cache coherence-protocols. It marks the cache line with one of the '''Modified (M) ,Shared (S)''', and '''Invalid (I)''' state. '''Invalid''' means the cache line is either not present or is in invalid state. If the cache line is clean and is shared by more than one processor , it is marked as '''Shared'''. If a cache line is dirty and the processor has exclusive ownership of it, it is in '''Modified''' state. BusRdx causes other processors to invalidate (demote) its cache block to the '''I''' state. If it is present in the '''M''' state in another cache, it will flush. &lt;br /&gt;
&lt;br /&gt;
The following state transition diagram for MSI protocol explains the working of the protocol:&lt;br /&gt;
&lt;br /&gt;
[[Image:MSI.jpg|frame|center|&amp;lt;b&amp;gt;Figure 2:&amp;lt;/b&amp;gt; MSI State Diagram]]&lt;br /&gt;
&lt;br /&gt;
===MESI===&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI protocol]''' has a major drawback in that each read-write sequence incurs two bus transactions irrespective of whether the cache line is stored in only one cache or not. This is a huge setback for highly parallel programs that have little data sharing. '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol solves this problem by introducing the E ('''Exclusive''') state to distinguish between a cache line stored in multiple caches and a line stored in a single cache.&lt;br /&gt;
Let us briefly look at how the MESI protocol works. (For a more detailed version readers are referred to Solihin textbook pg. 215)&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' coherence protocol marks each cache line in one of the Modified, Exclusive, Shared or Invalid state. &lt;br /&gt;
* '''Invalid''' : The cache line is either not present or is invalid&lt;br /&gt;
* '''Exclusive''' : The cache line is clean and is owned by this core/processor only&lt;br /&gt;
* '''Modified''' :  This implies that the cache line is dirty and the core/processor has  exclusive ownership of the cache line, exclusive of the memory also.&lt;br /&gt;
* '''Shared''' : The cache line is clean and is shared by more than one core/processor&lt;br /&gt;
&lt;br /&gt;
In a nutshell, the '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol works as the following: &lt;br /&gt;
A line that is just fetched receives '''E''' or '''S''' state depending on whether it exists in other processors in the system or not. Similarly, a cache line gets the '''M''' state when a processor writes to it. If the line is not in '''E''' or '''M''' state prior to being written to, the cache sends a Bus Upgrade (BusUpgr) signal or as the Intel manuals call it, a “Read-For-Ownership (RFO) request” that ensures that the line exists in the cache and is in the '''I''' state in all other processors on the bus (if any). The table shown below will summarize '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''Cache Line State:'''&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''This cache line is valid?'''&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  No&lt;br /&gt;
|-&lt;br /&gt;
|  '''The memory copy is…'''&lt;br /&gt;
|  out of date&lt;br /&gt;
|  valid&lt;br /&gt;
|  valid&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''Copies exist in caches of other processors?'''  &lt;br /&gt;
|  No&lt;br /&gt;
|  No&lt;br /&gt;
|  Maybe&lt;br /&gt;
|  Maybe&lt;br /&gt;
|-&lt;br /&gt;
|  '''A write to this line'''&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  goes to bus and updates cache&lt;br /&gt;
|  goes directly to bus&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 2:&amp;lt;/b&amp;gt; MESI Protocol Summary&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The transition diagram from the lecture slides is given below for reference.&lt;br /&gt;
&lt;br /&gt;
[[Image:MESI.jpg|frame|center|&amp;lt;b&amp;gt;Figure 4:&amp;lt;/b&amp;gt; MESI State Diagram]]&lt;br /&gt;
&lt;br /&gt;
===MESIF===&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/MESIF_protocol MESIF]''' protocol, used in the latest Intel multi-core processors Core i7, was introduced to '''accommodate the point-to-point''' links used in the QuickPath Interconnect. Using the '''MESI''' protocol in this architecture would send many redundant messages between different processors, often with unnecessarily high latency. For example, when a processor requests a cache line that is stored in multiple locations, every location might respond with the data. As the requesting processor only needs a single copy of the data, the system would be '''wasting the bandwidth'''. &lt;br /&gt;
As a '''solution''' to this problem, an additional state, '''Forward state''', was added by slightly changing the role of the Shared state. Whenever there is a read request, only the cache line in the F state will respond to the request, while all the S state caches remain dormant.  Hence, by designating a single cache line to '''respond to requests''', coherency traffic is substantially reduced when multiple copies of the data exist. Also, on a read request, the F state transitions to the S state. That is, when a cache line in the '''F''' state is '''copied''', the F state '''migrates''' to the '''newer copy''', while the '''older''' one drops back to the '''S''' state. Moving the new copy to the F state '''exploits''' both '''temporal and spatial locality'''. Because the newest copy of the cache line is always in the F state, it is very unlikely that the line in the F state will be evicted from the caches. This takes advantage of the temporal locality of the request. The second advantage is that if a particular cache line is in high demand due to spatial locality, the bandwidth used to transmit that data will be spread across several cores.&lt;br /&gt;
All M to S state transitions and E to S state transitions will now be from '''M to F''' and '''E to F'''.  &lt;br /&gt;
The '''F state''' is '''different''' from the '''Owned state''' of the MOESI protocol as it is '''not''' a '''unique''' copy because a valid copy is stored in memory. Thus, unlike the Owned state of the MOESI protocol, in which the data in the O state is the only valid copy of the data, the data in the F state can be evicted or converted to the S state, if desired. &lt;br /&gt;
&lt;br /&gt;
More information on the QuickPath Interconnect and MESIF protocol can be found at&lt;br /&gt;
'''[http://www.intel.com/technology/quickpath/introduction.pdf Introduction to QuickPath Interconnect]'''. &lt;br /&gt;
&lt;br /&gt;
===MOESI===&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/Opteron AMD Opteron] was AMD’s first-generation dual core processor which had two distinct [http://en.wikipedia.org/wiki/Athlon_64 K8 cores] together on a single die. Cache coherence produces bigger problems on such multicore processors. It was necessary to use an appropriate coherence protocol to address this problem. The [http://en.wikipedia.org/wiki/Xeon Intel Xeon], which was the competitive counterpart from Intel to AMD dual core Opteron, used the [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol to handle cache coherence. [http://en.wikipedia.org/wiki/MESI_protocol MESI] came with the drawback of using much time and bandwidth in certain situations. &lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/MOESI_protocol MOESI] was AMD’s answer to this problem. [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] added a fifth state to [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol called the '''owned''' state. [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol addresses the bandwidth problem faced by MESI protocol when processor having invalid data in its cache wants to modify the data.  The processor seeking the data will have to wait for the processor which modified this data to write back to the main memory, which takes time and bandwidth. This drawback is removed in MOESI by allowing dirty sharing.  When the data is held by a processor in the new state '''owned''', it can provide other processors the modified data without writing it to the main memory. This is called '''''dirty sharing'''''. The processor with the data in the '''owned''' state stays responsible to update the main memory later when the cache line is evicted.&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/MOESI_protocol MOESI]  has become one of the most popular snoop-based protocols supported in AMD64 architecture.  AMD dual-core Opteron can maintain cache coherence in systems up to 8 processors using this protocol.&lt;br /&gt;
&lt;br /&gt;
The five different states of [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol are:&lt;br /&gt;
* '''Modified (M)''': The most recent copy of the data is present in the cache line. But it is not present in any other processor cache.&lt;br /&gt;
* '''Owned (O)''': The cache line has the most recent correct copy of the data. This can be shared by other processors. The processor in this state for this cache line is responsible to update the correct value in the main memory before it gets evicted.&lt;br /&gt;
* '''Exclusive (E)''': A cache line holds the most recent, correct copy of the data, which is exclusively present on this processor and a copy is present in the main memory.&lt;br /&gt;
* '''Shared (S)''': A cache line in the shared state holds the most recent, correct copy of the data, which may be shared by other processors.&lt;br /&gt;
* '''Invalid (I)''': A cache line does not hold a valid copy of the data.&lt;br /&gt;
&lt;br /&gt;
A detailed explanation of this protocol implementation on AMD processor can be found in the manual [http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html Architecture of AMD 64-bit core]&lt;br /&gt;
&lt;br /&gt;
The following table summarizes the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''Cache Line State:'''&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  '''Owner''' &lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''This cache line is valid?'''&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  No&lt;br /&gt;
|-&lt;br /&gt;
|  '''The memory copy is…'''&lt;br /&gt;
|  out of date&lt;br /&gt;
|  out of date&lt;br /&gt;
|  valid&lt;br /&gt;
|  valid&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''Copies exist in caches of other processors?'''&lt;br /&gt;
|  No&lt;br /&gt;
|  No&lt;br /&gt;
|  Yes(out of date values)|  Maybe&lt;br /&gt;
|  Maybe&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''A write to this line'''&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  does not go to bus|  does not go to bus&lt;br /&gt;
|  goes to bus and updates cache&lt;br /&gt;
|  goes directly to bus&lt;br /&gt;
|  -&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 3:&amp;lt;/b&amp;gt; MOESI Protocol Summary&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
State transition for [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]is as shown below : &lt;br /&gt;
&lt;br /&gt;
[[Image:MOESI_State_Transition_Diagram.jpg|frame|center|&amp;lt;b&amp;gt;Figure 7:&amp;lt;/b&amp;gt; [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]State transition Diagram]]&lt;br /&gt;
&lt;br /&gt;
We will now discuss which cache coherence protocol processor vendors like '''Intel''', '''AMD''' and others adopt in various products.&lt;br /&gt;
&lt;br /&gt;
===Cache Coherence Protocols and Their Performance===&lt;br /&gt;
Of all protocols, MSI appears to have the worst performance due to the fact that each read-write sequence incurs two bus transactions even if the data is stored in only one cache. This causes a huge performance penalty for highly optimized parallel programs that have little data sharing. MESI protocol solves this problem by introducing the E (Exclusive) state to distinguish between a cache line stored in multiple caches and a line stored in only one cache. This protocol, however, can still be improved further. &lt;br /&gt;
&lt;br /&gt;
One remaining issue with MESI protocol is that in multi-processor configuration, when a processor requests a cache line that is stored in multiple cache, every cache might respond with the data. This behavior would waste bus bandwidth and incur high latency. As a solution to this problem, MESIF protocol was introduced. An additional state, Forward state, was added by slightly changing the role of the Shared state. The result of this improvement is that instead of all caches responding, only the cache line in the F state will respond to the request, while all the S state caches remain dormant. As a result, performance and power efficiency is increased. &lt;br /&gt;
&lt;br /&gt;
Another problem with MESI protocol is when a processor having invalid data in its cache wants to modify the data, it will have to wait for the other processor to write back to the memory, which is a very slow process. MOESI protocol solves this problem by allowing dirty&lt;br /&gt;
sharing. This also saves bus bandwidth and increases performance.&lt;br /&gt;
==SGI - Silicon Graphics, Inc==&lt;br /&gt;
===MSI &amp;amp; SGI IRIS 4D Processors===&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' protocol was first used in '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''' IRIS 4D series. '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''' produced a broad range of '''[http://en.wikipedia.org/wiki/MIPS_architecture MIPS]'''-based (Microprocessor without Interlocked Pipeline Stages) workstations and servers during the 1990s, running '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''''s version of UNIX System V, now called '''[http://en.wikipedia.org/wiki/IRIX IRIX]'''. The 4D-MP graphics superworkstation brought 40 MIPS(million instructions per second) of computing performance to a graphics superworkstation. The unprecedented level of computing and graphics processing in an office-environment workstation was made possible by the fastest available Risc microprocessors in a single shared memory multiprocessor design driving a tightly coupled, highly parallel graphics system. Aggregate sustained data rates of over one gigabyte per second were achieved by a hierarchy of buses in a balanced system designed to avoid bottlenecks.&lt;br /&gt;
&lt;br /&gt;
The multiprocessor bus used in 4D-MP graphics superworkstation is a pipelined, block transfer bus that supports the cache coherence protocol as well as providing 64 megabytes of sustained data bandwidth between the processors, the memory and I/O system, and the graphics subsystem. Because the sync bus provides for efficient synchronization between processors, the cache coherence protocol was designed to support efficient data sharing between processors. If a cache coherence protocol has to support synchronization as well as sharing, a compromise in the efficiency of the data sharing protocol may be necessary to improve the efficiency of the synchronization operations. Hence it uses the simple cache coherence protocol which is the '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' protocol.&lt;br /&gt;
&lt;br /&gt;
With the simple rules of '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]'''protocol enforced by hardware, efficient synchronization and efficient data sharing are achieved in a simple shared memory model of parallel processing in the 4D-MP graphics superworkstation.&lt;br /&gt;
&lt;br /&gt;
==SYNAPSE Multiprocessor==&lt;br /&gt;
===Synapse protocol and Synapse multiprocessor===&lt;br /&gt;
From the state transition diagram of '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''', we observe that for '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' there is transition to the '''S''' state from the '''M''' state when a BusRd is observed for that block. The contents of the block is flushed to the bus before going to '''S''' state. It would look more appropriate to move to the '''I''' state thus giving up the block entirely in certain cases. This choice of moving to '''S''' or '''I''' reflects the designer's assertion that the original processor is more likely to continue reading the block than the new processor to write to the block. In synapse protocol, used in the early Synapse multiprocessor, made this alternate choice of going directly from the '''M''' state to the '''I''' state on a BusRd, assuming the migratory pattern would be more frequent. More details about this protocol can be found in these papers published in late 1980's [http://portal.acm.org/citation.cfm?id=6514Cache Coherence protocols: evaluation using a multiprocessor simulation model] and [http://portal.acm.org/citation.cfm?id=1499317&amp;amp;dl=GUIDE&amp;amp;coll=GUIDE&amp;amp;CFID=83027384&amp;amp;CFTOKEN=95680533 Synapse tightly coupled multiprocessors: a new approach to solve old problems]&lt;br /&gt;
&lt;br /&gt;
In the Synapse protocol, the '''M''' state is called the '''D''' (Dirty) state. The following is the state transition diagram for Synapse protocol which clearly shows its working.&lt;br /&gt;
&lt;br /&gt;
[[Image:Synapse1.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; Synapse State Diagram]]&lt;br /&gt;
&lt;br /&gt;
==Intel==&lt;br /&gt;
===MESI &amp;amp; Intel Processors===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The '''Pentium Pro''' microprocessor, introduced in 1992 was the '''first''' Intel architecture microprocessor to support symmetric multiprocessing ('''[http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP]''') in various multiprocessor configurations. '''[http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP]''' and '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol was the architecture used consistently until the introduction of the 45-nm Hi-k Core micro-architecture in '''Intel's (Nehalem-EP) quad-core x86-64'''. The 45-nm Hi-k Intel Core microarchitecture utilizes a new system of framework called the '''QuickPath Interconnect''' which uses point-to-point interconnection technology based on distributed shared memory architecture. It uses a modified version of '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol called '''MESIF''', by introducing an additional state, F, the forward state. &lt;br /&gt;
&lt;br /&gt;
The '''Intel architecture''' uses the '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol  as the '''basis''' to ensure cache coherence, which is true whether you're on one of the older processors that use a '''common bus''' to communicate or using the new Intel '''QuickPath''' point-to-point interconnection technology. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== CMP Implementation in Intel Architecture ===&lt;br /&gt;
&lt;br /&gt;
Let us now see how Intel architecture using the [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol progressed from a uniprocessor architecture to a Chip MultiProcessor (CMP) using the bus as the interconnect. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Uniprocessor Architecture'''&lt;br /&gt;
&lt;br /&gt;
The diagram below shows the structure of the memory cluster in Intel Pentium M processor.&lt;br /&gt;
&lt;br /&gt;
[[Image:intel_cache1.jpg|frame|center|&amp;lt;b&amp;gt;Figure 5:&amp;lt;/b&amp;gt; Memory Structure of the Pentium M Processor]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In this structure we have,&lt;br /&gt;
* A unified on-chip '''L1 cache''' with the '''processor/core''',&lt;br /&gt;
* A '''Memory/L2 access control unit''', through which all the accesses to the L2 cache, main memory and IO space are made,&lt;br /&gt;
* The second level '''L2 cache''' along with the '''prefetch unit''' and&lt;br /&gt;
* '''Front side bus (FSB)''', a single shared bi-directional bus through which all the traffic is sent across.These wide buses bring in multiple data bytes at a time. &lt;br /&gt;
&lt;br /&gt;
As Intel explains it, using this structure, the processor requests were first sought in the '''L2 cache''' and only on a '''miss''', were they '''forwarded''' to the main '''memory''' via the front side bus ('''FSB'''). The '''Memory/L2 access control''' unit served as a central point for '''maintaining coherence''' within the core and with the external world. It '''contains''' a '''snoop control unit''' that receives snoop requests from the bus and performs the required operations on each cache (and internal buffers) in parallel. It also handles RFO requests (BusUpgr) and ensures the operation continues only after it guarantees that no other version on the cache line exists in any other cache in the system.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''CMP Architecture'''&lt;br /&gt;
&lt;br /&gt;
For CMP implementation, Intel chose the bus-based architecture using snoopy protocols vs the '''directory protocol''' because though directory protocol reduces the active power due to reduced snoop activity, it '''increased''' the '''design complexity''' and the '''static power''' due to larger tag arrays. Since Intel has a large market for the processors in the mobility family, directory-based solution was less favorable since battery life mainly depends on static power consumption and less on dynamic power.&lt;br /&gt;
Let us examine how '''CMP''' was implemented in '''Intel Core Duo''', which was one of the first dual-core processor for the budget/entry-level market. &lt;br /&gt;
The general CMP implementation structure of the Intel Core Duo is shown below&lt;br /&gt;
&lt;br /&gt;
[[Image:intel_cache2.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; Intel Core Duo CMP Implementation]]&lt;br /&gt;
&lt;br /&gt;
This structure has the following changes when compared to the uniprocessor memory cluster structure. &lt;br /&gt;
* '''L1 cache''' and the '''processor/core''' structure is '''duplicated''' to give 2 cores.&lt;br /&gt;
* The '''Memory/L2 access control''' unit is '''split''' into 2 logical units: '''L2 controller''' and '''bus controller'''. The L2 controller handles all '''requests to the L2''' cache from the core and the snoop requests from the FSB. The '''bus controller''' handles '''data and I/O requests''' to and from the FSB.&lt;br /&gt;
* The '''prefetching''' unit is extended to handle the hardware '''prefetches for each core separately'''.&lt;br /&gt;
* A '''new logical unit''' (represented by the hexagon) was added to maintain '''fairness between the requests''' coming from the different cores and hence balance the requests to L2 and memory.&lt;br /&gt;
&lt;br /&gt;
This new '''partitioned structure''' for the  memory/L2 access control unit '''enhanced''' the '''performance''' while '''reducing power consumption'''. &lt;br /&gt;
For more information on uniprocessor and multiprocessor implementation under the Intel architecture, refer to &lt;br /&gt;
[http://www.intel.com/technology/itj/2006/volume10issue02/art02_CMP_Implementation/p03_implementation.htm CMP Implementation in Intel Core Duo Processors]&lt;br /&gt;
&lt;br /&gt;
The '''Intel bus architecture''' has been '''evolving''' in order to accommodate the demands of scalability while using the '''same [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol'''; From using a '''single shared bus''' to '''dual independent buses (DIB)''' doubling the available bandwidth and to the logical conclusion of DIB with the introduction of '''dedicated high-speed interconnects (DHSI)'''. The DHSI-based platforms use four FSBs, one for each processor in the platform. In both DIB and DHSI, the snoop filter was used in the chipset to cache snoop information, thereby significantly reducing the broadcasting needed for the snoop traffic on the buses. With the production of processors based on next generation 45-nm Hi-k Intel Core microarchitecture, the [http://en.wikipedia.org/wiki/Xeon Intel Xeon] processor fabric will transition from a DHSI, with the memory controller in the chipset, to a distributed shared memory architecture using '''Intel QuickPath Interconnects using MESIF protocol'''.&lt;br /&gt;
&lt;br /&gt;
==AMD - Advanced Micro Devices Processors==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===MOESI &amp;amp; AMD Processors===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===AMD Opteron memory Architecture===&lt;br /&gt;
&lt;br /&gt;
[[Image:Untitled.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; AMD Opteron memory Architecture]]&lt;br /&gt;
&lt;br /&gt;
The AMD processor’s high-performance cache architecture includes an integrated, 64-bit, dual-ported  128-Kbyte split-L1 cache with separate snoop port, multi-level translation lookaside buffers (TLBs), a scalable L2 cache controller with a 72-bit (64-bit data + 8-bit ECC) interface to as much as 8-Mbyte of industry-standard SDR or DDR SRAMs, and an integrated tag for the most cost-effective 512-Kbyte L2 configurations. The AMD Athlon processor’s integrated L1 cache comprises two separate 64-Kbyte, two-way set-associative data and instruction caches.&lt;br /&gt;
&lt;br /&gt;
More information about this can be found in [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD 64 bit Architecture Programmers's Manual]&lt;br /&gt;
&lt;br /&gt;
===Special Coherence Considerations in AMD64 architectures===&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
Instruction prefetching is a technique used to speedup the execution of the program. But in multiprocessors, prefetching comes at the cost of performance. Due to prefetching, the data can be modified in such a way that the memory coherence protocol will not be able to handle the effects. In such situations software must use serializing instructions or cache-invalidation instructions to guarantee subsequent data accesses are coherent. &lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
An example of this type of a situation is a page-table update followed by accesses to the physical pages referenced by the updated page tables. The physical-memory references for the page tables are different than the physical-memory references for the data. Because of prefetching, there maybe problem with correctness. The following sequence of events shows such a situation when software changes the translation of virtual-page A from physical-page M to physical-page N:&lt;br /&gt;
# The tables that translate virtual-page A to physical-page M are now held only in main memory. The copies in the cache ae invalidated.&lt;br /&gt;
# Page-table entry is changed by the software for virtual-page A in main memory to point to physical page N rather than physical-page M.&lt;br /&gt;
# Data in virtual-page A is accessed.&lt;br /&gt;
&lt;br /&gt;
Software expects the processor to access the data from physical-page N after the update. However, it is possible for the processor to prefetch the data from physical-page M before the page table for virtual page A is updated. Because the physical-memory references are different, the processor does not recognize them as requiring coherence checking and believes it is safe to prefetch the data from virtual-page A, which is translated into a read from physical page M. Similar behavior can occur when instructions are prefetched from beyond the page table update instruction.&lt;br /&gt;
&lt;br /&gt;
In order to prevent errors from occuring, there are special instructions provided by software like INVLPG or MOV CR3 instruction which is executed immediately after the page-table update to ensure that subsequent instruction fetches and data accesses use the correct virtual-page-to-physical-page translation. It is not necessary to perform a TLB invalidation operation preceding the table update.&lt;br /&gt;
&lt;br /&gt;
More information can be found about this in [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD64 Architecture Programmer's manual]&lt;br /&gt;
&lt;br /&gt;
===Optimization techniques on MOESI when implemented on AMD Phenom processors===&lt;br /&gt;
&lt;br /&gt;
In real machines, using some optimization techniques on the standard cache coherence protocol used, improves the performance of the machine. For example, [http://en.wikipedia.org/wiki/AMD_Phenom AMD Phenom] family of microprocessors (Family 0×10) which is AMD’s first generation to incorporate 4 distinct cores on a single die. It is the first to have a cache that all the cores share, using the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol with some optimization techniques incorporated. &lt;br /&gt;
&lt;br /&gt;
It focuses on a small subset of compute problems which behave like Producer and Consumer programs. In such a computing problem, a thread of a program running on a single core produces data, which is consumed by a thread that is running on a separate core. With such programs, it is desirable to get the two distinct cores to communicate through the shared cache, to avoid round trips to/from main memory. The '''MOESI''' protocol that the [http://en.wikipedia.org/wiki/AMD_Phenom AMD Phenom] cache uses for cache coherence can also limit bandwidth. Hence by keeping the cache line in the '''M''' state for such computing problems, we can achieve better performance.&lt;br /&gt;
&lt;br /&gt;
When the producer thread , writes a new entry, it allocates cache-lines in the '''M''' state. Eventually, these M-marked cache lines will start to fill the L3 cache. When the consumer reads the cache line, the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol changes the state of the cache line to the '''O''' state in the L3 cache and pulls down a '''shared (S)''' copy for its own use. Now, the producer thread circles the ring buffer to arrive back to the same cache line it had previously written. However, when the producer attempts to write new data to the owned (marked '''‘O’''') cache line, it finds that it cannot, since a cache line in the '''O''' state by the previous consumer read does not have sufficient permission for a write request (in the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]). To maintain coherence, the memory controller must initiate probes in the other caches (to handle any other S copies that may exist). This will slow down the process.&lt;br /&gt;
&lt;br /&gt;
Thus, it is preferable to keep the cache line in the '''M''' state in the L3 cache. In such a situation, when the producer comes back around the ring buffer, it finds the previously written cache line still in the'''M''' state, to which it is safe to write without coherence concerns. Thus better performance can be achieved by such optimization techniques to standard protocols when implemented in real machines.&lt;br /&gt;
&lt;br /&gt;
You can find more information on how this is implemented and various other ways of optimizations in this manual [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf Software Optimization guide for AMD 10h Processors].&lt;br /&gt;
&lt;br /&gt;
==Xerox Corporation==&lt;br /&gt;
===Dragon Protocol &amp;amp; Xerox Dragon Processors===&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' is an update based coherence protocol which does not invalidate other cached copies like what we have seen in the coherence protocols so far. Write propagation is achieved by updating the cached copies instead of invalidating them.  But the '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' does not update memory on a cache to cache transfer and delays the memory and cache consistency until the data is evicted and written back, which saves time and lowers the memory access requirements. Moreover only the written '''byte''' or the '''word''' is '''communicated''' to the '''other caches''' instead of the whole block which further '''reduces''' the '''bandwidth''' usage. It has the ability to detect dynamically, the sharing status of a block and use a write through policy for shared blocks and write back for currently non-shared blocks. The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' employs the following four states for the cache blocks: '''Shared Clean''', '''Shared Modified''', '''Exclusive''', and  '''Modified'''. &lt;br /&gt;
* '''Modified (M)''' and '''Exclusive (E)''' - these states have the same meaning as explained in the protocols above. &lt;br /&gt;
* '''Shared Modified (Sm)''' - Only one cache line in the system can be in the Shared Modified state. Potentially two or more caches    have this block and memory may or may not be up to date and this processor's cache had modified the block.&lt;br /&gt;
* '''Shared Clean (Sc)''' -  Potentially two or more caches have this block and memory may or may not be up to date(if no other cache has it in Sm state, memory will be up to date else it is not).&lt;br /&gt;
When a Shared Modified line is evicted from the cache on a cache miss only then is the block written back to the main memory in order to keep memory consistent. For more information on Dragon protocol, refer to Solihin textbook, page number 229. The state transition diagram has been given below for reference.&lt;br /&gt;
&lt;br /&gt;
[[Image:Dragon.jpg|frame|center|&amp;lt;b&amp;gt;Figure 9:&amp;lt;/b&amp;gt; Dragon Protocol State Diagram]]&lt;br /&gt;
&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' , was developed by Xerox Palo Alto Research Center ('''[http://en.wikipedia.org/wiki/Xerox_PARC Xerox PARC]'''), a subsidiary of Xerox Corporation.  This protocol was used in the '''[http://en.wikipedia.org/w/index.php?title=Xerox_Dragon&amp;amp;redirect=no Xerox PARC Dragon]''' multiprocessor workstation, a VLSI research computer that could support multiple processors on a central high bandwidth memory bus. The Dragon design implemented snoopy caches that provided the appearance of a uniform memory space to multiple processors. Here, each cache listens to 2 buses: the processor bus and the memory bus. The caches are also responsible for address translation, so the processor bus carries virtual addresses and the memory bus carries physical addresses.  The Dragon system was designed to support 4 to 8 Dragon processors. The memory bus used in the Xeron Dragon evolved to become the '''[http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=289691 XDBus]''' , a low-cost, synchronous, '''packet-switched VLSI bus''' designed for use in high-performance multiprocessors. This was used as the interconnect in many multiprocessor server systems like '''Cray Superserver 6400''', '''Sun Microsystems' SPARCcenter 2000''' and '''SPARCserver 1000'''  and '''Sun4d''' systems.&lt;br /&gt;
&lt;br /&gt;
=Cache Coherence Power Utilization=&lt;br /&gt;
A number of studies have been performed to reduce the power consumption of cache coherence protocols. In order to perform a solid comparison between the cache coherency protocols, one would need to develop a multi-core processor for each of the cache coherency protocols. Additionally, the hardware and software configuration would also need to be similar between each system (except for the hardware required to implement each of the different protocols). Unfortunately, there are no such processors available. This section will discuss power consumption in general terms, comparing to each of the protocols. Also, this section will briefly discussion some power optimization techniques.&lt;br /&gt;
&lt;br /&gt;
Bus transactions, in general, are costly for both performance and power consumption. Additionally, studies have been performed showing that unnecessary snooping can waste power. Power requirements are typically determined by the number of bus snoops and number of bus accesses by each processor. One study indicates that interchip bus communications can consume up to 20% of total chip power[[#References|&amp;lt;sup&amp;gt;[20]&amp;lt;/sup&amp;gt;]].&lt;br /&gt;
Using the examples from the class notes, we can analyze the relative power consumption between the protocols. The following table is a summary of various protocols showing the number of bus communications that occur for each processor action.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|'''Processor Action'''&lt;br /&gt;
|'''MSI Bus Actions'''&lt;br /&gt;
|'''MESI Bus Actions'''&lt;br /&gt;
|'''Dragon Bus Actions'''&lt;br /&gt;
|'''FireFly Bus Actions'''&lt;br /&gt;
|-&lt;br /&gt;
|R1&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|-&lt;br /&gt;
|W1&lt;br /&gt;
|BusRdX&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R3&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|-&lt;br /&gt;
|W3&lt;br /&gt;
|BusRdX&lt;br /&gt;
|BusRdX&lt;br /&gt;
|BusUpd/Upd&lt;br /&gt;
|BusUpd&lt;br /&gt;
|-&lt;br /&gt;
|R1&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R3&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R2&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 4:&amp;lt;/b&amp;gt; Summary of Bus Actions for Select Protocols&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
From the table above, we can see that MSI has a larger number of bus transactions than the Dragon protocol. Even though bus transactions are not power efficient, snooping can also be enhanced to improve power efficiency. The following section will discuss snoop filtering techniques.&lt;br /&gt;
&lt;br /&gt;
==Power Savings Using Snoop Filtering==&lt;br /&gt;
A number of studies have been performed to reduce the number of unnecessary snoops during cache transactions. Two such filtering techniques are serial snooping and Jetty. The following sections will briefly discuss these two filtering techniques and power savings achieved using these techniques. Studies show that as much as 90% of snoop broadcasts will result in a miss[[#References|&amp;lt;sup&amp;gt;[19]&amp;lt;/sup&amp;gt;]] in the other caches at the same level and require that the information be provided by the next level of cache or memory. As much as a 36% savings in power by filtering snoops using one of the following snoop filtering methods[[#References|&amp;lt;sup&amp;gt;[19]&amp;lt;/sup&amp;gt;]].&lt;br /&gt;
===Serial Snooping===&lt;br /&gt;
Serial snooping takes advantage of the fact that if a miss occurs in one cache, it is possible to find the block in one other cache without having to check all the caches. If the cache block is available in multiple caches, there is a high probability that the cache miss can find the data in a nearby cache. Alternatively, savings can be realized by searching a subset of the caches vice all the caches. One thing to note is that this is only effective for read misses. Write, an invalidation transaction needs to be transmitted to the other caches, thus a bus transaction is unavoidable.&lt;br /&gt;
===Jetty===&lt;br /&gt;
Jetty is a mechanism attached to each cache that verifies that a bus snoop is necessary. Jetty is used to filter L2 tag lookups. When a processor needs to perform a bus snoop, the Jetty is checked first. The Jetty can determine if a cache tag lookup is required. Since the Jetty is much smaller than the associated cache, less power is required to determine if a snoop is required.&lt;br /&gt;
&lt;br /&gt;
There are a couple of different Jetty schemes. There is the exclude-Jetty, include-Jetty, and hybrid-Jetty. The exclude-Jetty exploits the fact that if a cache block is snooped, it is highly likely the same cache block will be snooped in the near future. The exclude-Jetty keeps track of the tag lookups in a small table and can determine if a cache tag lookup is necessary.&lt;br /&gt;
&lt;br /&gt;
The include-Jetty keeps a superset of the blocks that are cached. If a miss occurs in the include-Jetty, then it can be guaranteed that the block is not stored in its associated cache.&lt;br /&gt;
&lt;br /&gt;
The hybrid-Jetty is simply a combinations of and include and exclude-Jetty. Both types of Jetty are present and when a lookup occurs, both Jettys are checked to determine if a cache lookup is necessary.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Cache_coherence Cache coherence]&lt;br /&gt;
# [http://www.intel.com/technology/quickpath/introduction.pdf Introduction to QuickPath Interconnect]&lt;br /&gt;
# [http://www.intel.com/technology/itj/2006/volume10issue02/art02_CMP_Implementation/p03_implementation.htm CMP Implementation in Intel Core Duo Processors]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Symmetric_multiprocessing Common System Interface in Intel Processors]&lt;br /&gt;
# [http://www.zak.ict.pwr.wroc.pl/nikodem/ak_materialy/Cache%20consistency%20&amp;amp;%20MESI.pdf Cache consistency with MESI on Intel processor]&lt;br /&gt;
# [http://techreport.com/articles.x/8236/2 AMD dual core Architecture]&lt;br /&gt;
# [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD64 Architecture Programmer's manual]&lt;br /&gt;
# [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf Software Optimization guide for AMD 10h Processors]&lt;br /&gt;
# [http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html Architecture of AMD 64 bit core]&lt;br /&gt;
# [http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=4913 Silicon Graphics Computer Systems]&lt;br /&gt;
# [http://books.google.com/books?id=g82fofiqa5IC&amp;amp;printsec=frontcover&amp;amp;dq=Parallel+computer+architecture:+a+hardware/software+approach+By+David+E.+Culler,+Jaswinder+Pal+Singh,+Anoop+Gupta&amp;amp;source=bl&amp;amp;ots=COrdamlfVn&amp;amp;sig=YcugVqbzTjHvlofvaFq6Ft_tjfY&amp;amp;hl=en&amp;amp;ei=0ZO6S4TJGcOclgejzI3BBw&amp;amp;sa=X&amp;amp;oi=book_result&amp;amp;ct=result&amp;amp;resnum=1&amp;amp;ved=0CAgQ6AEwAA#v=onepage&amp;amp;q=&amp;amp;f=false Parallel computer architecture: a hardware/software approach By David E. Culler, Jaswinder Pal Singh, Anoop Gupta]&lt;br /&gt;
# [http://www.freepatentsonline.com/5283886.html Three state invalidation protocols]&lt;br /&gt;
# [http://portal.acm.org/citation.cfm?id=1499317&amp;amp;dl=GUIDE&amp;amp;coll=GUIDE&amp;amp;CFID=83027384&amp;amp;CFTOKEN=95680533 Synapse tightly coupled multiprocessors: a new approach to solve old problems]&lt;br /&gt;
# [http://portal.acm.org/citation.cfm?id=6514Cache Coherence protocols: evaluation using a multiprocessor simulation model]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Xerox_Dragon Xerox Dragon]&lt;br /&gt;
# [http://thanaseto.110mb.com/courses/CSD-527-report-engl.pdf Coherence Protocols]&lt;br /&gt;
# [http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=289691 XDBus]&lt;br /&gt;
# [http://www.ece.wisc.edu/~wddd/2002/final/ekman.pdf Evaluation of Snoop-Energy Reduction Techniques for Chip-Multiprocessors]&lt;br /&gt;
# [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.79.7463&amp;amp;rep=rep1&amp;amp;type=pdf Power Efficient Cache Coherence]&lt;br /&gt;
# [http://www.realworldtech.com/page.cfm?ArticleID=RWT082807020032&amp;amp;p=5 The Common System Interface: Intel's Future Interconnect]&lt;br /&gt;
# [http://support.amd.com/us/Processor_TechDocs/24593.pdf AMD64 Architecture Programmer's Manual Vol 2 'System Programming']&lt;/div&gt;</summary>
		<author><name>Mqtran</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2011/ch8_mc&amp;diff=44464</id>
		<title>CSC/ECE 506 Spring 2011/ch8 mc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2011/ch8_mc&amp;diff=44464"/>
		<updated>2011-03-20T00:28:29Z</updated>

		<summary type="html">&lt;p&gt;Mqtran: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Introduction to bus-based cache coherence in real machines=&lt;br /&gt;
&lt;br /&gt;
Most parallel software in the commercial market relies on the shared-memory&lt;br /&gt;
programming model in which all processors access the same physical address space. The most common multiprocessors today use [http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP] architecture which use a common bus as the interconnect.  In the case of multicore processors (&amp;quot;chip multiprocessors,&amp;quot; or CMP) the [http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP] architecture applies to the cores treating them as separate processors. The key problem of shared-memory multiprocessors is providing a consistent view of memory with various cache hierarchies.  This is called '''''cache coherence problem'''''. It is  critical to  achieve correctness and performance-sensitive design point for supporting the shared-memory model. The cache coherence mechanisms not only govern communication in a shared-memory multiprocessor, but also typically determine how the memory system transfers data between processors, caches, and memory.&lt;br /&gt;
&lt;br /&gt;
[[Image:Busbased SMP.jpg|frame|center|&amp;lt;b&amp;gt;Figure 1:&amp;lt;/b&amp;gt; Typical Bus-Based Processor Model]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Cache Coherence in real machines=&lt;br /&gt;
==Summary of Cache Coherence Protocols==&lt;br /&gt;
At any point in logical time, the permissions for a cache block can allow either a single writer or multiple readers. The '''''coherence protocol''''' ensures the invariants of the states are maintained. The different coherent states used by most of the cache coherent protocols are shown in ''Table 1'':&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''States'''&lt;br /&gt;
|  '''Access Type'''&lt;br /&gt;
|  '''Invariant'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  read, write&lt;br /&gt;
|  all other caches in I state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  read&lt;br /&gt;
|  all other caches in I state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Owned'''&lt;br /&gt;
|  read&lt;br /&gt;
|  all other caches in I or S state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  read&lt;br /&gt;
|  no other cache in M or E state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|  -&lt;br /&gt;
|  -&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 1:&amp;lt;/b&amp;gt; States Used by the Cache Coherent Protocols&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
The first widely adopted approach to cache coherence is snooping on a bus. We will now discuss them in details in the following sections.&lt;br /&gt;
&lt;br /&gt;
===MSI===&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI protocol]''' is a three-state write-back '''invalidation protocol''' which is one of the earliest snooping-based cache coherence-protocols. It marks the cache line with one of the '''Modified (M) ,Shared (S)''', and '''Invalid (I)''' state. '''Invalid''' means the cache line is either not present or is in invalid state. If the cache line is clean and is shared by more than one processor , it is marked as '''Shared'''. If a cache line is dirty and the processor has exclusive ownership of it, it is in '''Modified''' state. BusRdx causes other processors to invalidate (demote) its cache block to the '''I''' state. If it is present in the '''M''' state in another cache, it will flush. &lt;br /&gt;
&lt;br /&gt;
The following state transition diagram for MSI protocol explains the working of the protocol:&lt;br /&gt;
&lt;br /&gt;
[[Image:MSI.jpg|frame|center|&amp;lt;b&amp;gt;Figure 2:&amp;lt;/b&amp;gt; MSI State Diagram]]&lt;br /&gt;
&lt;br /&gt;
===MESI===&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI protocol]''' has a major drawback in that each read-write sequence incurs two bus transactions irrespective of whether the cache line is stored in only one cache or not. This is a huge setback for highly parallel programs that have little data sharing. '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol solves this problem by introducing the E ('''Exclusive''') state to distinguish between a cache line stored in multiple caches and a line stored in a single cache.&lt;br /&gt;
Let us briefly look at how the MESI protocol works. (For a more detailed version readers are referred to Solihin textbook pg. 215)&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' coherence protocol marks each cache line in one of the Modified, Exclusive, Shared or Invalid state. &lt;br /&gt;
* '''Invalid''' : The cache line is either not present or is invalid&lt;br /&gt;
* '''Exclusive''' : The cache line is clean and is owned by this core/processor only&lt;br /&gt;
* '''Modified''' :  This implies that the cache line is dirty and the core/processor has  exclusive ownership of the cache line, exclusive of the memory also.&lt;br /&gt;
* '''Shared''' : The cache line is clean and is shared by more than one core/processor&lt;br /&gt;
&lt;br /&gt;
In a nutshell, the '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol works as the following: &lt;br /&gt;
A line that is just fetched receives '''E''' or '''S''' state depending on whether it exists in other processors in the system or not. Similarly, a cache line gets the '''M''' state when a processor writes to it. If the line is not in '''E''' or '''M''' state prior to being written to, the cache sends a Bus Upgrade (BusUpgr) signal or as the Intel manuals call it, a “Read-For-Ownership (RFO) request” that ensures that the line exists in the cache and is in the '''I''' state in all other processors on the bus (if any). The table shown below will summarize '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''Cache Line State:'''&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''This cache line is valid?'''&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  No&lt;br /&gt;
|-&lt;br /&gt;
|  '''The memory copy is…'''&lt;br /&gt;
|  out of date&lt;br /&gt;
|  valid&lt;br /&gt;
|  valid&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''Copies exist in caches of other processors?'''  &lt;br /&gt;
|  No&lt;br /&gt;
|  No&lt;br /&gt;
|  Maybe&lt;br /&gt;
|  Maybe&lt;br /&gt;
|-&lt;br /&gt;
|  '''A write to this line'''&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  goes to bus and updates cache&lt;br /&gt;
|  goes directly to bus&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 2:&amp;lt;/b&amp;gt; MESI Protocol Summary&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The transition diagram from the lecture slides is given below for reference.&lt;br /&gt;
&lt;br /&gt;
[[Image:MESI.jpg|frame|center|&amp;lt;b&amp;gt;Figure 4:&amp;lt;/b&amp;gt; MESI State Diagram]]&lt;br /&gt;
&lt;br /&gt;
===MESIF===&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/MESIF_protocol MESIF]''' protocol, used in the latest Intel multi-core processors Core i7, was introduced to '''accommodate the point-to-point''' links used in the QuickPath Interconnect. Using the '''MESI''' protocol in this architecture would send many redundant messages between different processors, often with unnecessarily high latency. For example, when a processor requests a cache line that is stored in multiple locations, every location might respond with the data. As the requesting processor only needs a single copy of the data, the system would be '''wasting the bandwidth'''. &lt;br /&gt;
As a '''solution''' to this problem, an additional state, '''Forward state''', was added by slightly changing the role of the Shared state. Whenever there is a read request, only the cache line in the F state will respond to the request, while all the S state caches remain dormant.  Hence, by designating a single cache line to '''respond to requests''', coherency traffic is substantially reduced when multiple copies of the data exist. Also, on a read request, the F state transitions to the S state. That is, when a cache line in the '''F''' state is '''copied''', the F state '''migrates''' to the '''newer copy''', while the '''older''' one drops back to the '''S''' state. Moving the new copy to the F state '''exploits''' both '''temporal and spatial locality'''. Because the newest copy of the cache line is always in the F state, it is very unlikely that the line in the F state will be evicted from the caches. This takes advantage of the temporal locality of the request. The second advantage is that if a particular cache line is in high demand due to spatial locality, the bandwidth used to transmit that data will be spread across several cores.&lt;br /&gt;
All M to S state transitions and E to S state transitions will now be from '''M to F''' and '''E to F'''.  &lt;br /&gt;
The '''F state''' is '''different''' from the '''Owned state''' of the MOESI protocol as it is '''not''' a '''unique''' copy because a valid copy is stored in memory. Thus, unlike the Owned state of the MOESI protocol, in which the data in the O state is the only valid copy of the data, the data in the F state can be evicted or converted to the S state, if desired. &lt;br /&gt;
&lt;br /&gt;
More information on the QuickPath Interconnect and MESIF protocol can be found at&lt;br /&gt;
'''[http://www.intel.com/technology/quickpath/introduction.pdf Introduction to QuickPath Interconnect]'''. &lt;br /&gt;
&lt;br /&gt;
===MOESI===&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/Opteron AMD Opteron] was AMD’s first-generation dual core processor which had two distinct [http://en.wikipedia.org/wiki/Athlon_64 K8 cores] together on a single die. Cache coherence produces bigger problems on such multicore processors. It was necessary to use an appropriate coherence protocol to address this problem. The [http://en.wikipedia.org/wiki/Xeon Intel Xeon], which was the competitive counterpart from Intel to AMD dual core Opteron, used the [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol to handle cache coherence. [http://en.wikipedia.org/wiki/MESI_protocol MESI] came with the drawback of using much time and bandwidth in certain situations. &lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/MOESI_protocol MOESI] was AMD’s answer to this problem. [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] added a fifth state to [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol called the '''owned''' state. [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol addresses the bandwidth problem faced by MESI protocol when processor having invalid data in its cache wants to modify the data.  The processor seeking the data will have to wait for the processor which modified this data to write back to the main memory, which takes time and bandwidth. This drawback is removed in MOESI by allowing dirty sharing.  When the data is held by a processor in the new state '''owned''', it can provide other processors the modified data without writing it to the main memory. This is called '''''dirty sharing'''''. The processor with the data in the '''owned''' state stays responsible to update the main memory later when the cache line is evicted.&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/MOESI_protocol MOESI]  has become one of the most popular snoop-based protocols supported in AMD64 architecture.  AMD dual-core Opteron can maintain cache coherence in systems up to 8 processors using this protocol.&lt;br /&gt;
&lt;br /&gt;
The five different states of [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol are:&lt;br /&gt;
* '''Modified (M)''': The most recent copy of the data is present in the cache line. But it is not present in any other processor cache.&lt;br /&gt;
* '''Owned (O)''': The cache line has the most recent correct copy of the data. This can be shared by other processors. The processor in this state for this cache line is responsible to update the correct value in the main memory before it gets evicted.&lt;br /&gt;
* '''Exclusive (E)''': A cache line holds the most recent, correct copy of the data, which is exclusively present on this processor and a copy is present in the main memory.&lt;br /&gt;
* '''Shared (S)''': A cache line in the shared state holds the most recent, correct copy of the data, which may be shared by other processors.&lt;br /&gt;
* '''Invalid (I)''': A cache line does not hold a valid copy of the data.&lt;br /&gt;
&lt;br /&gt;
A detailed explanation of this protocol implementation on AMD processor can be found in the manual [http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html Architecture of AMD 64-bit core]&lt;br /&gt;
&lt;br /&gt;
The following table summarizes the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''Cache Line State:'''&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  '''Owner''' &lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''This cache line is valid?'''&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  No&lt;br /&gt;
|-&lt;br /&gt;
|  '''The memory copy is…'''&lt;br /&gt;
|  out of date&lt;br /&gt;
|  out of date&lt;br /&gt;
|  valid&lt;br /&gt;
|  valid&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''Copies exist in caches of other processors?'''&lt;br /&gt;
|  No&lt;br /&gt;
|  No&lt;br /&gt;
|  Yes(out of date values)|  Maybe&lt;br /&gt;
|  Maybe&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''A write to this line'''&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  does not go to bus|  does not go to bus&lt;br /&gt;
|  goes to bus and updates cache&lt;br /&gt;
|  goes directly to bus&lt;br /&gt;
|  -&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 3:&amp;lt;/b&amp;gt; MOESI Protocol Summary&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
State transition for [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]is as shown below : &lt;br /&gt;
&lt;br /&gt;
[[Image:MOESI_State_Transition_Diagram.jpg|frame|center|&amp;lt;b&amp;gt;Figure 7:&amp;lt;/b&amp;gt; [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]State transition Diagram]]&lt;br /&gt;
&lt;br /&gt;
We will now discuss which cache coherence protocol processor vendors like '''Intel''', '''AMD''' and others adopt in various products.&lt;br /&gt;
&lt;br /&gt;
==Cache Coherence Protocols and Their Performance==&lt;br /&gt;
Of all protocols, MSI appears to have the worst performance due to the fact that each read-write sequence incurs two bus transactions even if the data is stored in only one cache. This causes a huge performance penalty for highly optimized parallel programs that have little data sharing. MESI protocol solves this problem by introducing the E (Exclusive) state to distinguish between a cache line stored in multiple caches and a line stored in only one cache. This protocol, however, can still be improved further. &lt;br /&gt;
&lt;br /&gt;
One remaining issue with MESI protocol is that in multi-processor configuration, when a processor requests a cache line that is stored in multiple cache, every cache might respond with the data. This behavior would waste bus bandwidth and incur high latency. As a solution to this problem, MESIF protocol was introduced. An additional state, Forward state, was added by slightly changing the role of the Shared state. The result of this improvement is that instead of all caches responding, only the cache line in the F state will respond to the request, while all the S state caches remain dormant. As a result, performance and power efficiency is increased. &lt;br /&gt;
&lt;br /&gt;
Another problem with MESI protocol is when a processor having invalid data in its cache wants to modify the data, it will have to wait for the other processor to write back to the memory, which is a very slow process. MOESI protocol solves this problem by allowing dirty&lt;br /&gt;
sharing. This also saves bus bandwidth and increases performance.&lt;br /&gt;
==SGI - Silicon Graphics, Inc==&lt;br /&gt;
===MSI &amp;amp; SGI IRIS 4D Processors===&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' protocol was first used in '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''' IRIS 4D series. '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''' produced a broad range of '''[http://en.wikipedia.org/wiki/MIPS_architecture MIPS]'''-based (Microprocessor without Interlocked Pipeline Stages) workstations and servers during the 1990s, running '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''''s version of UNIX System V, now called '''[http://en.wikipedia.org/wiki/IRIX IRIX]'''. The 4D-MP graphics superworkstation brought 40 MIPS(million instructions per second) of computing performance to a graphics superworkstation. The unprecedented level of computing and graphics processing in an office-environment workstation was made possible by the fastest available Risc microprocessors in a single shared memory multiprocessor design driving a tightly coupled, highly parallel graphics system. Aggregate sustained data rates of over one gigabyte per second were achieved by a hierarchy of buses in a balanced system designed to avoid bottlenecks.&lt;br /&gt;
&lt;br /&gt;
The multiprocessor bus used in 4D-MP graphics superworkstation is a pipelined, block transfer bus that supports the cache coherence protocol as well as providing 64 megabytes of sustained data bandwidth between the processors, the memory and I/O system, and the graphics subsystem. Because the sync bus provides for efficient synchronization between processors, the cache coherence protocol was designed to support efficient data sharing between processors. If a cache coherence protocol has to support synchronization as well as sharing, a compromise in the efficiency of the data sharing protocol may be necessary to improve the efficiency of the synchronization operations. Hence it uses the simple cache coherence protocol which is the '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' protocol.&lt;br /&gt;
&lt;br /&gt;
With the simple rules of '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]'''protocol enforced by hardware, efficient synchronization and efficient data sharing are achieved in a simple shared memory model of parallel processing in the 4D-MP graphics superworkstation.&lt;br /&gt;
&lt;br /&gt;
==SYNAPSE Multiprocessor==&lt;br /&gt;
===Synapse protocol and Synapse multiprocessor===&lt;br /&gt;
From the state transition diagram of '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''', we observe that for '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' there is transition to the '''S''' state from the '''M''' state when a BusRd is observed for that block. The contents of the block is flushed to the bus before going to '''S''' state. It would look more appropriate to move to the '''I''' state thus giving up the block entirely in certain cases. This choice of moving to '''S''' or '''I''' reflects the designer's assertion that the original processor is more likely to continue reading the block than the new processor to write to the block. In synapse protocol, used in the early Synapse multiprocessor, made this alternate choice of going directly from the '''M''' state to the '''I''' state on a BusRd, assuming the migratory pattern would be more frequent. More details about this protocol can be found in these papers published in late 1980's [http://portal.acm.org/citation.cfm?id=6514Cache Coherence protocols: evaluation using a multiprocessor simulation model] and [http://portal.acm.org/citation.cfm?id=1499317&amp;amp;dl=GUIDE&amp;amp;coll=GUIDE&amp;amp;CFID=83027384&amp;amp;CFTOKEN=95680533 Synapse tightly coupled multiprocessors: a new approach to solve old problems]&lt;br /&gt;
&lt;br /&gt;
In the Synapse protocol, the '''M''' state is called the '''D''' (Dirty) state. The following is the state transition diagram for Synapse protocol which clearly shows its working.&lt;br /&gt;
&lt;br /&gt;
[[Image:Synapse1.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; Synapse State Diagram]]&lt;br /&gt;
&lt;br /&gt;
==Intel==&lt;br /&gt;
===MESI &amp;amp; Intel Processors===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The '''Pentium Pro''' microprocessor, introduced in 1992 was the '''first''' Intel architecture microprocessor to support symmetric multiprocessing ('''[http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP]''') in various multiprocessor configurations. '''[http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP]''' and '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol was the architecture used consistently until the introduction of the 45-nm Hi-k Core micro-architecture in '''Intel's (Nehalem-EP) quad-core x86-64'''. The 45-nm Hi-k Intel Core microarchitecture utilizes a new system of framework called the '''QuickPath Interconnect''' which uses point-to-point interconnection technology based on distributed shared memory architecture. It uses a modified version of '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol called '''MESIF''', by introducing an additional state, F, the forward state. &lt;br /&gt;
&lt;br /&gt;
The '''Intel architecture''' uses the '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol  as the '''basis''' to ensure cache coherence, which is true whether you're on one of the older processors that use a '''common bus''' to communicate or using the new Intel '''QuickPath''' point-to-point interconnection technology. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== CMP Implementation in Intel Architecture ===&lt;br /&gt;
&lt;br /&gt;
Let us now see how Intel architecture using the [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol progressed from a uniprocessor architecture to a Chip MultiProcessor (CMP) using the bus as the interconnect. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Uniprocessor Architecture'''&lt;br /&gt;
&lt;br /&gt;
The diagram below shows the structure of the memory cluster in Intel Pentium M processor.&lt;br /&gt;
&lt;br /&gt;
[[Image:intel_cache1.jpg|frame|center|&amp;lt;b&amp;gt;Figure 5:&amp;lt;/b&amp;gt; Memory Structure of the Pentium M Processor]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In this structure we have,&lt;br /&gt;
* A unified on-chip '''L1 cache''' with the '''processor/core''',&lt;br /&gt;
* A '''Memory/L2 access control unit''', through which all the accesses to the L2 cache, main memory and IO space are made,&lt;br /&gt;
* The second level '''L2 cache''' along with the '''prefetch unit''' and&lt;br /&gt;
* '''Front side bus (FSB)''', a single shared bi-directional bus through which all the traffic is sent across.These wide buses bring in multiple data bytes at a time. &lt;br /&gt;
&lt;br /&gt;
As Intel explains it, using this structure, the processor requests were first sought in the '''L2 cache''' and only on a '''miss''', were they '''forwarded''' to the main '''memory''' via the front side bus ('''FSB'''). The '''Memory/L2 access control''' unit served as a central point for '''maintaining coherence''' within the core and with the external world. It '''contains''' a '''snoop control unit''' that receives snoop requests from the bus and performs the required operations on each cache (and internal buffers) in parallel. It also handles RFO requests (BusUpgr) and ensures the operation continues only after it guarantees that no other version on the cache line exists in any other cache in the system.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''CMP Architecture'''&lt;br /&gt;
&lt;br /&gt;
For CMP implementation, Intel chose the bus-based architecture using snoopy protocols vs the '''directory protocol''' because though directory protocol reduces the active power due to reduced snoop activity, it '''increased''' the '''design complexity''' and the '''static power''' due to larger tag arrays. Since Intel has a large market for the processors in the mobility family, directory-based solution was less favorable since battery life mainly depends on static power consumption and less on dynamic power.&lt;br /&gt;
Let us examine how '''CMP''' was implemented in '''Intel Core Duo''', which was one of the first dual-core processor for the budget/entry-level market. &lt;br /&gt;
The general CMP implementation structure of the Intel Core Duo is shown below&lt;br /&gt;
&lt;br /&gt;
[[Image:intel_cache2.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; Intel Core Duo CMP Implementation]]&lt;br /&gt;
&lt;br /&gt;
This structure has the following changes when compared to the uniprocessor memory cluster structure. &lt;br /&gt;
* '''L1 cache''' and the '''processor/core''' structure is '''duplicated''' to give 2 cores.&lt;br /&gt;
* The '''Memory/L2 access control''' unit is '''split''' into 2 logical units: '''L2 controller''' and '''bus controller'''. The L2 controller handles all '''requests to the L2''' cache from the core and the snoop requests from the FSB. The '''bus controller''' handles '''data and I/O requests''' to and from the FSB.&lt;br /&gt;
* The '''prefetching''' unit is extended to handle the hardware '''prefetches for each core separately'''.&lt;br /&gt;
* A '''new logical unit''' (represented by the hexagon) was added to maintain '''fairness between the requests''' coming from the different cores and hence balance the requests to L2 and memory.&lt;br /&gt;
&lt;br /&gt;
This new '''partitioned structure''' for the  memory/L2 access control unit '''enhanced''' the '''performance''' while '''reducing power consumption'''. &lt;br /&gt;
For more information on uniprocessor and multiprocessor implementation under the Intel architecture, refer to &lt;br /&gt;
[http://www.intel.com/technology/itj/2006/volume10issue02/art02_CMP_Implementation/p03_implementation.htm CMP Implementation in Intel Core Duo Processors]&lt;br /&gt;
&lt;br /&gt;
The '''Intel bus architecture''' has been '''evolving''' in order to accommodate the demands of scalability while using the '''same [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol'''; From using a '''single shared bus''' to '''dual independent buses (DIB)''' doubling the available bandwidth and to the logical conclusion of DIB with the introduction of '''dedicated high-speed interconnects (DHSI)'''. The DHSI-based platforms use four FSBs, one for each processor in the platform. In both DIB and DHSI, the snoop filter was used in the chipset to cache snoop information, thereby significantly reducing the broadcasting needed for the snoop traffic on the buses. With the production of processors based on next generation 45-nm Hi-k Intel Core microarchitecture, the [http://en.wikipedia.org/wiki/Xeon Intel Xeon] processor fabric will transition from a DHSI, with the memory controller in the chipset, to a distributed shared memory architecture using '''Intel QuickPath Interconnects using MESIF protocol'''.&lt;br /&gt;
&lt;br /&gt;
==AMD - Advanced Micro Devices Processors==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===MOESI &amp;amp; AMD Processors===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===AMD Opteron memory Architecture===&lt;br /&gt;
&lt;br /&gt;
[[Image:Untitled.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; AMD Opteron memory Architecture]]&lt;br /&gt;
&lt;br /&gt;
The AMD processor’s high-performance cache architecture includes an integrated, 64-bit, dual-ported  128-Kbyte split-L1 cache with separate snoop port, multi-level translation lookaside buffers (TLBs), a scalable L2 cache controller with a 72-bit (64-bit data + 8-bit ECC) interface to as much as 8-Mbyte of industry-standard SDR or DDR SRAMs, and an integrated tag for the most cost-effective 512-Kbyte L2 configurations. The AMD Athlon processor’s integrated L1 cache comprises two separate 64-Kbyte, two-way set-associative data and instruction caches.&lt;br /&gt;
&lt;br /&gt;
More information about this can be found in [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD 64 bit Architecture Programmers's Manual]&lt;br /&gt;
&lt;br /&gt;
===Special Coherence Considerations in AMD64 architectures===&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
Instruction prefetching is a technique used to speedup the execution of the program. But in multiprocessors, prefetching comes at the cost of performance. Due to prefetching, the data can be modified in such a way that the memory coherence protocol will not be able to handle the effects. In such situations software must use serializing instructions or cache-invalidation instructions to guarantee subsequent data accesses are coherent. &lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
An example of this type of a situation is a page-table update followed by accesses to the physical pages referenced by the updated page tables. The physical-memory references for the page tables are different than the physical-memory references for the data. Because of prefetching, there maybe problem with correctness. The following sequence of events shows such a situation when software changes the translation of virtual-page A from physical-page M to physical-page N:&lt;br /&gt;
# The tables that translate virtual-page A to physical-page M are now held only in main memory. The copies in the cache ae invalidated.&lt;br /&gt;
# Page-table entry is changed by the software for virtual-page A in main memory to point to physical page N rather than physical-page M.&lt;br /&gt;
# Data in virtual-page A is accessed.&lt;br /&gt;
&lt;br /&gt;
Software expects the processor to access the data from physical-page N after the update. However, it is possible for the processor to prefetch the data from physical-page M before the page table for virtual page A is updated. Because the physical-memory references are different, the processor does not recognize them as requiring coherence checking and believes it is safe to prefetch the data from virtual-page A, which is translated into a read from physical page M. Similar behavior can occur when instructions are prefetched from beyond the page table update instruction.&lt;br /&gt;
&lt;br /&gt;
In order to prevent errors from occuring, there are special instructions provided by software like INVLPG or MOV CR3 instruction which is executed immediately after the page-table update to ensure that subsequent instruction fetches and data accesses use the correct virtual-page-to-physical-page translation. It is not necessary to perform a TLB invalidation operation preceding the table update.&lt;br /&gt;
&lt;br /&gt;
More information can be found about this in [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD64 Architecture Programmer's manual]&lt;br /&gt;
&lt;br /&gt;
===Optimization techniques on MOESI when implemented on AMD Phenom processors===&lt;br /&gt;
&lt;br /&gt;
In real machines, using some optimization techniques on the standard cache coherence protocol used, improves the performance of the machine. For example, [http://en.wikipedia.org/wiki/AMD_Phenom AMD Phenom] family of microprocessors (Family 0×10) which is AMD’s first generation to incorporate 4 distinct cores on a single die. It is the first to have a cache that all the cores share, using the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol with some optimization techniques incorporated. &lt;br /&gt;
&lt;br /&gt;
It focuses on a small subset of compute problems which behave like Producer and Consumer programs. In such a computing problem, a thread of a program running on a single core produces data, which is consumed by a thread that is running on a separate core. With such programs, it is desirable to get the two distinct cores to communicate through the shared cache, to avoid round trips to/from main memory. The '''MOESI''' protocol that the [http://en.wikipedia.org/wiki/AMD_Phenom AMD Phenom] cache uses for cache coherence can also limit bandwidth. Hence by keeping the cache line in the '''M''' state for such computing problems, we can achieve better performance.&lt;br /&gt;
&lt;br /&gt;
When the producer thread , writes a new entry, it allocates cache-lines in the '''M''' state. Eventually, these M-marked cache lines will start to fill the L3 cache. When the consumer reads the cache line, the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol changes the state of the cache line to the '''O''' state in the L3 cache and pulls down a '''shared (S)''' copy for its own use. Now, the producer thread circles the ring buffer to arrive back to the same cache line it had previously written. However, when the producer attempts to write new data to the owned (marked '''‘O’''') cache line, it finds that it cannot, since a cache line in the '''O''' state by the previous consumer read does not have sufficient permission for a write request (in the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]). To maintain coherence, the memory controller must initiate probes in the other caches (to handle any other S copies that may exist). This will slow down the process.&lt;br /&gt;
&lt;br /&gt;
Thus, it is preferable to keep the cache line in the '''M''' state in the L3 cache. In such a situation, when the producer comes back around the ring buffer, it finds the previously written cache line still in the'''M''' state, to which it is safe to write without coherence concerns. Thus better performance can be achieved by such optimization techniques to standard protocols when implemented in real machines.&lt;br /&gt;
&lt;br /&gt;
You can find more information on how this is implemented and various other ways of optimizations in this manual [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf Software Optimization guide for AMD 10h Processors].&lt;br /&gt;
&lt;br /&gt;
==Xerox Corporation==&lt;br /&gt;
===Dragon Protocol &amp;amp; Xerox Dragon Processors===&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' is an update based coherence protocol which does not invalidate other cached copies like what we have seen in the coherence protocols so far. Write propagation is achieved by updating the cached copies instead of invalidating them.  But the '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' does not update memory on a cache to cache transfer and delays the memory and cache consistency until the data is evicted and written back, which saves time and lowers the memory access requirements. Moreover only the written '''byte''' or the '''word''' is '''communicated''' to the '''other caches''' instead of the whole block which further '''reduces''' the '''bandwidth''' usage. It has the ability to detect dynamically, the sharing status of a block and use a write through policy for shared blocks and write back for currently non-shared blocks. The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' employs the following four states for the cache blocks: '''Shared Clean''', '''Shared Modified''', '''Exclusive''', and  '''Modified'''. &lt;br /&gt;
* '''Modified (M)''' and '''Exclusive (E)''' - these states have the same meaning as explained in the protocols above. &lt;br /&gt;
* '''Shared Modified (Sm)''' - Only one cache line in the system can be in the Shared Modified state. Potentially two or more caches    have this block and memory may or may not be up to date and this processor's cache had modified the block.&lt;br /&gt;
* '''Shared Clean (Sc)''' -  Potentially two or more caches have this block and memory may or may not be up to date(if no other cache has it in Sm state, memory will be up to date else it is not).&lt;br /&gt;
When a Shared Modified line is evicted from the cache on a cache miss only then is the block written back to the main memory in order to keep memory consistent. For more information on Dragon protocol, refer to Solihin textbook, page number 229. The state transition diagram has been given below for reference.&lt;br /&gt;
&lt;br /&gt;
[[Image:Dragon.jpg|frame|center|&amp;lt;b&amp;gt;Figure 9:&amp;lt;/b&amp;gt; Dragon Protocol State Diagram]]&lt;br /&gt;
&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' , was developed by Xerox Palo Alto Research Center ('''[http://en.wikipedia.org/wiki/Xerox_PARC Xerox PARC]'''), a subsidiary of Xerox Corporation.  This protocol was used in the '''[http://en.wikipedia.org/w/index.php?title=Xerox_Dragon&amp;amp;redirect=no Xerox PARC Dragon]''' multiprocessor workstation, a VLSI research computer that could support multiple processors on a central high bandwidth memory bus. The Dragon design implemented snoopy caches that provided the appearance of a uniform memory space to multiple processors. Here, each cache listens to 2 buses: the processor bus and the memory bus. The caches are also responsible for address translation, so the processor bus carries virtual addresses and the memory bus carries physical addresses.  The Dragon system was designed to support 4 to 8 Dragon processors. The memory bus used in the Xeron Dragon evolved to become the '''[http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=289691 XDBus]''' , a low-cost, synchronous, '''packet-switched VLSI bus''' designed for use in high-performance multiprocessors. This was used as the interconnect in many multiprocessor server systems like '''Cray Superserver 6400''', '''Sun Microsystems' SPARCcenter 2000''' and '''SPARCserver 1000'''  and '''Sun4d''' systems.&lt;br /&gt;
&lt;br /&gt;
=Cache Coherence Power Utilization=&lt;br /&gt;
A number of studies have been performed to reduce the power consumption of cache coherence protocols. In order to perform a solid comparison between the cache coherency protocols, one would need to develop a multi-core processor for each of the cache coherency protocols. Additionally, the hardware and software configuration would also need to be similar between each system (except for the hardware required to implement each of the different protocols). Unfortunately, there are no such processors available. This section will discuss power consumption in general terms, comparing to each of the protocols. Also, this section will briefly discussion some power optimization techniques.&lt;br /&gt;
&lt;br /&gt;
Bus transactions, in general, are costly for both performance and power consumption. Additionally, studies have been performed showing that unnecessary snooping can waste power. Power requirements are typically determined by the number of bus snoops and number of bus accesses by each processor. One study indicates that interchip bus communications can consume up to 20% of total chip power[[#References|&amp;lt;sup&amp;gt;[20]&amp;lt;/sup&amp;gt;]].&lt;br /&gt;
Using the examples from the class notes, we can analyze the relative power consumption between the protocols. The following table is a summary of various protocols showing the number of bus communications that occur for each processor action.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|'''Processor Action'''&lt;br /&gt;
|'''MSI Bus Actions'''&lt;br /&gt;
|'''MESI Bus Actions'''&lt;br /&gt;
|'''Dragon Bus Actions'''&lt;br /&gt;
|'''FireFly Bus Actions'''&lt;br /&gt;
|-&lt;br /&gt;
|R1&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|-&lt;br /&gt;
|W1&lt;br /&gt;
|BusRdX&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R3&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|-&lt;br /&gt;
|W3&lt;br /&gt;
|BusRdX&lt;br /&gt;
|BusRdX&lt;br /&gt;
|BusUpd/Upd&lt;br /&gt;
|BusUpd&lt;br /&gt;
|-&lt;br /&gt;
|R1&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R3&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R2&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 4:&amp;lt;/b&amp;gt; Summary of Bus Actions for Select Protocols&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
From the table above, we can see that MSI has a larger number of bus transactions than the Dragon protocol. Even though bus transactions are not power efficient, snooping can also be enhanced to improve power efficiency. The following section will discuss snoop filtering techniques.&lt;br /&gt;
&lt;br /&gt;
==Power Savings Using Snoop Filtering==&lt;br /&gt;
A number of studies have been performed to reduce the number of unnecessary snoops during cache transactions. Two such filtering techniques are serial snooping and Jetty. The following sections will briefly discuss these two filtering techniques and power savings achieved using these techniques. Studies show that as much as 90% of snoop broadcasts will result in a miss[[#References|&amp;lt;sup&amp;gt;[19]&amp;lt;/sup&amp;gt;]] in the other caches at the same level and require that the information be provided by the next level of cache or memory. As much as a 36% savings in power by filtering snoops using one of the following snoop filtering methods[[#References|&amp;lt;sup&amp;gt;[19]&amp;lt;/sup&amp;gt;]].&lt;br /&gt;
===Serial Snooping===&lt;br /&gt;
Serial snooping takes advantage of the fact that if a miss occurs in one cache, it is possible to find the block in one other cache without having to check all the caches. If the cache block is available in multiple caches, there is a high probability that the cache miss can find the data in a nearby cache. Alternatively, savings can be realized by searching a subset of the caches vice all the caches. One thing to note is that this is only effective for read misses. Write, an invalidation transaction needs to be transmitted to the other caches, thus a bus transaction is unavoidable.&lt;br /&gt;
===Jetty===&lt;br /&gt;
Jetty is a mechanism attached to each cache that verifies that a bus snoop is necessary. Jetty is used to filter L2 tag lookups. When a processor needs to perform a bus snoop, the Jetty is checked first. The Jetty can determine if a cache tag lookup is required. Since the Jetty is much smaller than the associated cache, less power is required to determine if a snoop is required.&lt;br /&gt;
&lt;br /&gt;
There are a couple of different Jetty schemes. There is the exclude-Jetty, include-Jetty, and hybrid-Jetty. The exclude-Jetty exploits the fact that if a cache block is snooped, it is highly likely the same cache block will be snooped in the near future. The exclude-Jetty keeps track of the tag lookups in a small table and can determine if a cache tag lookup is necessary.&lt;br /&gt;
&lt;br /&gt;
The include-Jetty keeps a superset of the blocks that are cached. If a miss occurs in the include-Jetty, then it can be guaranteed that the block is not stored in its associated cache.&lt;br /&gt;
&lt;br /&gt;
The hybrid-Jetty is simply a combinations of and include and exclude-Jetty. Both types of Jetty are present and when a lookup occurs, both Jettys are checked to determine if a cache lookup is necessary.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Cache_coherence Cache coherence]&lt;br /&gt;
# [http://www.intel.com/technology/quickpath/introduction.pdf Introduction to QuickPath Interconnect]&lt;br /&gt;
# [http://www.intel.com/technology/itj/2006/volume10issue02/art02_CMP_Implementation/p03_implementation.htm CMP Implementation in Intel Core Duo Processors]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Symmetric_multiprocessing Common System Interface in Intel Processors]&lt;br /&gt;
# [http://www.zak.ict.pwr.wroc.pl/nikodem/ak_materialy/Cache%20consistency%20&amp;amp;%20MESI.pdf Cache consistency with MESI on Intel processor]&lt;br /&gt;
# [http://techreport.com/articles.x/8236/2 AMD dual core Architecture]&lt;br /&gt;
# [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD64 Architecture Programmer's manual]&lt;br /&gt;
# [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf Software Optimization guide for AMD 10h Processors]&lt;br /&gt;
# [http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html Architecture of AMD 64 bit core]&lt;br /&gt;
# [http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=4913 Silicon Graphics Computer Systems]&lt;br /&gt;
# [http://books.google.com/books?id=g82fofiqa5IC&amp;amp;printsec=frontcover&amp;amp;dq=Parallel+computer+architecture:+a+hardware/software+approach+By+David+E.+Culler,+Jaswinder+Pal+Singh,+Anoop+Gupta&amp;amp;source=bl&amp;amp;ots=COrdamlfVn&amp;amp;sig=YcugVqbzTjHvlofvaFq6Ft_tjfY&amp;amp;hl=en&amp;amp;ei=0ZO6S4TJGcOclgejzI3BBw&amp;amp;sa=X&amp;amp;oi=book_result&amp;amp;ct=result&amp;amp;resnum=1&amp;amp;ved=0CAgQ6AEwAA#v=onepage&amp;amp;q=&amp;amp;f=false Parallel computer architecture: a hardware/software approach By David E. Culler, Jaswinder Pal Singh, Anoop Gupta]&lt;br /&gt;
# [http://www.freepatentsonline.com/5283886.html Three state invalidation protocols]&lt;br /&gt;
# [http://portal.acm.org/citation.cfm?id=1499317&amp;amp;dl=GUIDE&amp;amp;coll=GUIDE&amp;amp;CFID=83027384&amp;amp;CFTOKEN=95680533 Synapse tightly coupled multiprocessors: a new approach to solve old problems]&lt;br /&gt;
# [http://portal.acm.org/citation.cfm?id=6514Cache Coherence protocols: evaluation using a multiprocessor simulation model]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Xerox_Dragon Xerox Dragon]&lt;br /&gt;
# [http://thanaseto.110mb.com/courses/CSD-527-report-engl.pdf Coherence Protocols]&lt;br /&gt;
# [http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=289691 XDBus]&lt;br /&gt;
# [http://www.ece.wisc.edu/~wddd/2002/final/ekman.pdf Evaluation of Snoop-Energy Reduction Techniques for Chip-Multiprocessors]&lt;br /&gt;
# [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.79.7463&amp;amp;rep=rep1&amp;amp;type=pdf Power Efficient Cache Coherence]&lt;/div&gt;</summary>
		<author><name>Mqtran</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2011/ch8_mc&amp;diff=44463</id>
		<title>CSC/ECE 506 Spring 2011/ch8 mc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2011/ch8_mc&amp;diff=44463"/>
		<updated>2011-03-20T00:26:39Z</updated>

		<summary type="html">&lt;p&gt;Mqtran: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Introduction to bus-based cache coherence in real machines=&lt;br /&gt;
&lt;br /&gt;
Most parallel software in the commercial market relies on the shared-memory&lt;br /&gt;
programming model in which all processors access the same physical address space. The most common multiprocessors today use [http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP] architecture which use a common bus as the interconnect.  In the case of multicore processors (&amp;quot;chip multiprocessors,&amp;quot; or CMP) the [http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP] architecture applies to the cores treating them as separate processors. The key problem of shared-memory multiprocessors is providing a consistent view of memory with various cache hierarchies.  This is called '''''cache coherence problem'''''. It is  critical to  achieve correctness and performance-sensitive design point for supporting the shared-memory model. The cache coherence mechanisms not only govern communication in a shared-memory multiprocessor, but also typically determine how the memory system transfers data between processors, caches, and memory.&lt;br /&gt;
&lt;br /&gt;
[[Image:Busbased SMP.jpg|frame|center|&amp;lt;b&amp;gt;Figure 1:&amp;lt;/b&amp;gt; Typical Bus-Based Processor Model]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Cache Coherence in real machines=&lt;br /&gt;
==Summary of Cache Coherence Protocols==&lt;br /&gt;
At any point in logical time, the permissions for a cache block can allow either a single writer or multiple readers. The '''''coherence protocol''''' ensures the invariants of the states are maintained. The different coherent states used by most of the cache coherent protocols are shown in ''Table 1'':&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''States'''&lt;br /&gt;
|  '''Access Type'''&lt;br /&gt;
|  '''Invariant'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  read, write&lt;br /&gt;
|  all other caches in I state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  read&lt;br /&gt;
|  all other caches in I state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Owned'''&lt;br /&gt;
|  read&lt;br /&gt;
|  all other caches in I or S state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  read&lt;br /&gt;
|  no other cache in M or E state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|  -&lt;br /&gt;
|  -&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 1:&amp;lt;/b&amp;gt; States Used by the Cache Coherent Protocols&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
The first widely adopted approach to cache coherence is snooping on a bus. We will now discuss them in details in the following sections.&lt;br /&gt;
&lt;br /&gt;
===MSI===&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI protocol]''' is a three-state write-back '''invalidation protocol''' which is one of the earliest snooping-based cache coherence-protocols. It marks the cache line with one of the '''Modified (M) ,Shared (S)''', and '''Invalid (I)''' state. '''Invalid''' means the cache line is either not present or is in invalid state. If the cache line is clean and is shared by more than one processor , it is marked as '''Shared'''. If a cache line is dirty and the processor has exclusive ownership of it, it is in '''Modified''' state. BusRdx causes other processors to invalidate (demote) its cache block to the '''I''' state. If it is present in the '''M''' state in another cache, it will flush. &lt;br /&gt;
&lt;br /&gt;
The following state transition diagram for MSI protocol explains the working of the protocol:&lt;br /&gt;
&lt;br /&gt;
[[Image:MSI.jpg|frame|center|&amp;lt;b&amp;gt;Figure 2:&amp;lt;/b&amp;gt; MSI State Diagram]]&lt;br /&gt;
&lt;br /&gt;
===MESI===&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI protocol]''' has a major drawback in that each read-write sequence incurs two bus transactions irrespective of whether the cache line is stored in only one cache or not. This is a huge setback for highly parallel programs that have little data sharing. '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol solves this problem by introducing the E ('''Exclusive''') state to distinguish between a cache line stored in multiple caches and a line stored in a single cache.&lt;br /&gt;
Let us briefly look at how the MESI protocol works. (For a more detailed version readers are referred to Solihin textbook pg. 215)&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' coherence protocol marks each cache line in one of the Modified, Exclusive, Shared or Invalid state. &lt;br /&gt;
* '''Invalid''' : The cache line is either not present or is invalid&lt;br /&gt;
* '''Exclusive''' : The cache line is clean and is owned by this core/processor only&lt;br /&gt;
* '''Modified''' :  This implies that the cache line is dirty and the core/processor has  exclusive ownership of the cache line, exclusive of the memory also.&lt;br /&gt;
* '''Shared''' : The cache line is clean and is shared by more than one core/processor&lt;br /&gt;
&lt;br /&gt;
In a nutshell, the '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol works as the following: &lt;br /&gt;
A line that is just fetched receives '''E''' or '''S''' state depending on whether it exists in other processors in the system or not. Similarly, a cache line gets the '''M''' state when a processor writes to it. If the line is not in '''E''' or '''M''' state prior to being written to, the cache sends a Bus Upgrade (BusUpgr) signal or as the Intel manuals call it, a “Read-For-Ownership (RFO) request” that ensures that the line exists in the cache and is in the '''I''' state in all other processors on the bus (if any). The table shown below will summarize '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''Cache Line State:'''&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''This cache line is valid?'''&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  No&lt;br /&gt;
|-&lt;br /&gt;
|  '''The memory copy is…'''&lt;br /&gt;
|  out of date&lt;br /&gt;
|  valid&lt;br /&gt;
|  valid&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''Copies exist in caches of other processors?'''  &lt;br /&gt;
|  No&lt;br /&gt;
|  No&lt;br /&gt;
|  Maybe&lt;br /&gt;
|  Maybe&lt;br /&gt;
|-&lt;br /&gt;
|  '''A write to this line'''&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  goes to bus and updates cache&lt;br /&gt;
|  goes directly to bus&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 2:&amp;lt;/b&amp;gt; MESI Protocol Summary&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The transition diagram from the lecture slides is given below for reference.&lt;br /&gt;
&lt;br /&gt;
[[Image:MESI.jpg|frame|center|&amp;lt;b&amp;gt;Figure 4:&amp;lt;/b&amp;gt; MESI State Diagram]]&lt;br /&gt;
&lt;br /&gt;
===MESIF===&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/MESIF_protocol MESIF]''' protocol, used in the latest Intel multi-core processors Core i7, was introduced to '''accommodate the point-to-point''' links used in the QuickPath Interconnect. Using the '''MESI''' protocol in this architecture would send many redundant messages between different processors, often with unnecessarily high latency. For example, when a processor requests a cache line that is stored in multiple locations, every location might respond with the data. As the requesting processor only needs a single copy of the data, the system would be '''wasting the bandwidth'''. &lt;br /&gt;
As a '''solution''' to this problem, an additional state, '''Forward state''', was added by slightly changing the role of the Shared state. Whenever there is a read request, only the cache line in the F state will respond to the request, while all the S state caches remain dormant.  Hence, by designating a single cache line to '''respond to requests''', coherency traffic is substantially reduced when multiple copies of the data exist. Also, on a read request, the F state transitions to the S state. That is, when a cache line in the '''F''' state is '''copied''', the F state '''migrates''' to the '''newer copy''', while the '''older''' one drops back to the '''S''' state. Moving the new copy to the F state '''exploits''' both '''temporal and spatial locality'''. Because the newest copy of the cache line is always in the F state, it is very unlikely that the line in the F state will be evicted from the caches. This takes advantage of the temporal locality of the request. The second advantage is that if a particular cache line is in high demand due to spatial locality, the bandwidth used to transmit that data will be spread across several cores.&lt;br /&gt;
All M to S state transitions and E to S state transitions will now be from '''M to F''' and '''E to F'''.  &lt;br /&gt;
The '''F state''' is '''different''' from the '''Owned state''' of the MOESI protocol as it is '''not''' a '''unique''' copy because a valid copy is stored in memory. Thus, unlike the Owned state of the MOESI protocol, in which the data in the O state is the only valid copy of the data, the data in the F state can be evicted or converted to the S state, if desired. &lt;br /&gt;
&lt;br /&gt;
More information on the QuickPath Interconnect and MESIF protocol can be found at&lt;br /&gt;
'''[http://www.intel.com/technology/quickpath/introduction.pdf Introduction to QuickPath Interconnect]'''. &lt;br /&gt;
&lt;br /&gt;
===MOESI===&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/Opteron AMD Opteron] was AMD’s first-generation dual core processor which had two distinct [http://en.wikipedia.org/wiki/Athlon_64 K8 cores] together on a single die. Cache coherence produces bigger problems on such multicore processors. It was necessary to use an appropriate coherence protocol to address this problem. The [http://en.wikipedia.org/wiki/Xeon Intel Xeon], which was the competitive counterpart from Intel to AMD dual core Opteron, used the [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol to handle cache coherence. [http://en.wikipedia.org/wiki/MESI_protocol MESI] came with the drawback of using much time and bandwidth in certain situations. &lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/MOESI_protocol MOESI] was AMD’s answer to this problem. [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] added a fifth state to [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol called the '''owned''' state. [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol addresses the bandwidth problem faced by MESI protocol when processor having invalid data in its cache wants to modify the data.  The processor seeking the data will have to wait for the processor which modified this data to write back to the main memory, which takes time and bandwidth. This drawback is removed in MOESI by allowing dirty sharing.  When the data is held by a processor in the new state '''owned''', it can provide other processors the modified data without writing it to the main memory. This is called '''''dirty sharing'''''. The processor with the data in the '''owned''' state stays responsible to update the main memory later when the cache line is evicted.&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/MOESI_protocol MOESI]  has become one of the most popular snoop-based protocols supported in AMD64 architecture.  AMD dual-core Opteron can maintain cache coherence in systems up to 8 processors using this protocol.&lt;br /&gt;
&lt;br /&gt;
The five different states of [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol are:&lt;br /&gt;
* '''Modified (M)''': The most recent copy of the data is present in the cache line. But it is not present in any other processor cache.&lt;br /&gt;
* '''Owned (O)''': The cache line has the most recent correct copy of the data. This can be shared by other processors. The processor in this state for this cache line is responsible to update the correct value in the main memory before it gets evicted.&lt;br /&gt;
* '''Exclusive (E)''': A cache line holds the most recent, correct copy of the data, which is exclusively present on this processor and a copy is present in the main memory.&lt;br /&gt;
* '''Shared (S)''': A cache line in the shared state holds the most recent, correct copy of the data, which may be shared by other processors.&lt;br /&gt;
* '''Invalid (I)''': A cache line does not hold a valid copy of the data.&lt;br /&gt;
&lt;br /&gt;
A detailed explanation of this protocol implementation on AMD processor can be found in the manual [http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html Architecture of AMD 64-bit core]&lt;br /&gt;
&lt;br /&gt;
The following table summarizes the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''Cache Line State:'''&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  '''Owner''' &lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''This cache line is valid?'''&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  No&lt;br /&gt;
|-&lt;br /&gt;
|  '''The memory copy is…'''&lt;br /&gt;
|  out of date&lt;br /&gt;
|  out of date&lt;br /&gt;
|  valid&lt;br /&gt;
|  valid&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''Copies exist in caches of other processors?'''&lt;br /&gt;
|  No&lt;br /&gt;
|  No&lt;br /&gt;
|  Yes(out of date values)|  Maybe&lt;br /&gt;
|  Maybe&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''A write to this line'''&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  does not go to bus|  does not go to bus&lt;br /&gt;
|  goes to bus and updates cache&lt;br /&gt;
|  goes directly to bus&lt;br /&gt;
|  -&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 3:&amp;lt;/b&amp;gt; MOESI Protocol Summary&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
State transition for [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]is as shown below : &lt;br /&gt;
&lt;br /&gt;
[[Image:MOESI_State_Transition_Diagram.jpg|frame|center|&amp;lt;b&amp;gt;Figure 7:&amp;lt;/b&amp;gt; [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]State transition Diagram]]&lt;br /&gt;
&lt;br /&gt;
We will now discuss which cache coherence protocol processor vendors like '''Intel''', '''AMD''' and others adopt in various products.&lt;br /&gt;
&lt;br /&gt;
===Cache Coherence Protocols and Their Performance===&lt;br /&gt;
Of all protocols, MSI appears to have the worst performance due to the fact that each read-write sequence incurs two bus transactions even if the data is stored in only one cache. This causes a huge performance penalty for highly optimized parallel programs that have little data sharing. MESI protocol solves this problem by introducing the E (Exclusive) state to distinguish between a cache line stored in multiple caches and a line stored in only one cache. This protocol, however, can still be improved further. &lt;br /&gt;
One remaining issue with MESI protocol is that in multi-processor configuration, when a processor requests a cache line that is stored in multiple cache, every cache might respond with the data. This behavior would waste bus bandwidth and incur high latency. As a solution to this problem, MESIF protocol was introduced. An additional state, Forward state, was added by slightly changing the role of the Shared state. The result of this improvement is that instead of all caches responding, only the cache line in the F state will respond to the request, while all the S state caches remain dormant. As a result, performance and power efficiency is increased. &lt;br /&gt;
Another problem with MESI protocol is when a processor having invalid data in its cache wants to modify the data, it will have to wait for the other processor to write back to the memory, which is a very slow process. MOESI protocol solves this problem by allowing dirty&lt;br /&gt;
sharing. This also saves bus bandwidth and increases performance.&lt;br /&gt;
==SGI - Silicon Graphics, Inc==&lt;br /&gt;
===MSI &amp;amp; SGI IRIS 4D Processors===&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' protocol was first used in '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''' IRIS 4D series. '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''' produced a broad range of '''[http://en.wikipedia.org/wiki/MIPS_architecture MIPS]'''-based (Microprocessor without Interlocked Pipeline Stages) workstations and servers during the 1990s, running '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''''s version of UNIX System V, now called '''[http://en.wikipedia.org/wiki/IRIX IRIX]'''. The 4D-MP graphics superworkstation brought 40 MIPS(million instructions per second) of computing performance to a graphics superworkstation. The unprecedented level of computing and graphics processing in an office-environment workstation was made possible by the fastest available Risc microprocessors in a single shared memory multiprocessor design driving a tightly coupled, highly parallel graphics system. Aggregate sustained data rates of over one gigabyte per second were achieved by a hierarchy of buses in a balanced system designed to avoid bottlenecks.&lt;br /&gt;
&lt;br /&gt;
The multiprocessor bus used in 4D-MP graphics superworkstation is a pipelined, block transfer bus that supports the cache coherence protocol as well as providing 64 megabytes of sustained data bandwidth between the processors, the memory and I/O system, and the graphics subsystem. Because the sync bus provides for efficient synchronization between processors, the cache coherence protocol was designed to support efficient data sharing between processors. If a cache coherence protocol has to support synchronization as well as sharing, a compromise in the efficiency of the data sharing protocol may be necessary to improve the efficiency of the synchronization operations. Hence it uses the simple cache coherence protocol which is the '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' protocol.&lt;br /&gt;
&lt;br /&gt;
With the simple rules of '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]'''protocol enforced by hardware, efficient synchronization and efficient data sharing are achieved in a simple shared memory model of parallel processing in the 4D-MP graphics superworkstation.&lt;br /&gt;
&lt;br /&gt;
==SYNAPSE Multiprocessor==&lt;br /&gt;
===Synapse protocol and Synapse multiprocessor===&lt;br /&gt;
From the state transition diagram of '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''', we observe that for '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' there is transition to the '''S''' state from the '''M''' state when a BusRd is observed for that block. The contents of the block is flushed to the bus before going to '''S''' state. It would look more appropriate to move to the '''I''' state thus giving up the block entirely in certain cases. This choice of moving to '''S''' or '''I''' reflects the designer's assertion that the original processor is more likely to continue reading the block than the new processor to write to the block. In synapse protocol, used in the early Synapse multiprocessor, made this alternate choice of going directly from the '''M''' state to the '''I''' state on a BusRd, assuming the migratory pattern would be more frequent. More details about this protocol can be found in these papers published in late 1980's [http://portal.acm.org/citation.cfm?id=6514Cache Coherence protocols: evaluation using a multiprocessor simulation model] and [http://portal.acm.org/citation.cfm?id=1499317&amp;amp;dl=GUIDE&amp;amp;coll=GUIDE&amp;amp;CFID=83027384&amp;amp;CFTOKEN=95680533 Synapse tightly coupled multiprocessors: a new approach to solve old problems]&lt;br /&gt;
&lt;br /&gt;
In the Synapse protocol, the '''M''' state is called the '''D''' (Dirty) state. The following is the state transition diagram for Synapse protocol which clearly shows its working.&lt;br /&gt;
&lt;br /&gt;
[[Image:Synapse1.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; Synapse State Diagram]]&lt;br /&gt;
&lt;br /&gt;
==Intel==&lt;br /&gt;
===MESI &amp;amp; Intel Processors===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The '''Pentium Pro''' microprocessor, introduced in 1992 was the '''first''' Intel architecture microprocessor to support symmetric multiprocessing ('''[http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP]''') in various multiprocessor configurations. '''[http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP]''' and '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol was the architecture used consistently until the introduction of the 45-nm Hi-k Core micro-architecture in '''Intel's (Nehalem-EP) quad-core x86-64'''. The 45-nm Hi-k Intel Core microarchitecture utilizes a new system of framework called the '''QuickPath Interconnect''' which uses point-to-point interconnection technology based on distributed shared memory architecture. It uses a modified version of '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol called '''MESIF''', by introducing an additional state, F, the forward state. &lt;br /&gt;
&lt;br /&gt;
The '''Intel architecture''' uses the '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol  as the '''basis''' to ensure cache coherence, which is true whether you're on one of the older processors that use a '''common bus''' to communicate or using the new Intel '''QuickPath''' point-to-point interconnection technology. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== CMP Implementation in Intel Architecture ===&lt;br /&gt;
&lt;br /&gt;
Let us now see how Intel architecture using the [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol progressed from a uniprocessor architecture to a Chip MultiProcessor (CMP) using the bus as the interconnect. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Uniprocessor Architecture'''&lt;br /&gt;
&lt;br /&gt;
The diagram below shows the structure of the memory cluster in Intel Pentium M processor.&lt;br /&gt;
&lt;br /&gt;
[[Image:intel_cache1.jpg|frame|center|&amp;lt;b&amp;gt;Figure 5:&amp;lt;/b&amp;gt; Memory Structure of the Pentium M Processor]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In this structure we have,&lt;br /&gt;
* A unified on-chip '''L1 cache''' with the '''processor/core''',&lt;br /&gt;
* A '''Memory/L2 access control unit''', through which all the accesses to the L2 cache, main memory and IO space are made,&lt;br /&gt;
* The second level '''L2 cache''' along with the '''prefetch unit''' and&lt;br /&gt;
* '''Front side bus (FSB)''', a single shared bi-directional bus through which all the traffic is sent across.These wide buses bring in multiple data bytes at a time. &lt;br /&gt;
&lt;br /&gt;
As Intel explains it, using this structure, the processor requests were first sought in the '''L2 cache''' and only on a '''miss''', were they '''forwarded''' to the main '''memory''' via the front side bus ('''FSB'''). The '''Memory/L2 access control''' unit served as a central point for '''maintaining coherence''' within the core and with the external world. It '''contains''' a '''snoop control unit''' that receives snoop requests from the bus and performs the required operations on each cache (and internal buffers) in parallel. It also handles RFO requests (BusUpgr) and ensures the operation continues only after it guarantees that no other version on the cache line exists in any other cache in the system.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''CMP Architecture'''&lt;br /&gt;
&lt;br /&gt;
For CMP implementation, Intel chose the bus-based architecture using snoopy protocols vs the '''directory protocol''' because though directory protocol reduces the active power due to reduced snoop activity, it '''increased''' the '''design complexity''' and the '''static power''' due to larger tag arrays. Since Intel has a large market for the processors in the mobility family, directory-based solution was less favorable since battery life mainly depends on static power consumption and less on dynamic power.&lt;br /&gt;
Let us examine how '''CMP''' was implemented in '''Intel Core Duo''', which was one of the first dual-core processor for the budget/entry-level market. &lt;br /&gt;
The general CMP implementation structure of the Intel Core Duo is shown below&lt;br /&gt;
&lt;br /&gt;
[[Image:intel_cache2.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; Intel Core Duo CMP Implementation]]&lt;br /&gt;
&lt;br /&gt;
This structure has the following changes when compared to the uniprocessor memory cluster structure. &lt;br /&gt;
* '''L1 cache''' and the '''processor/core''' structure is '''duplicated''' to give 2 cores.&lt;br /&gt;
* The '''Memory/L2 access control''' unit is '''split''' into 2 logical units: '''L2 controller''' and '''bus controller'''. The L2 controller handles all '''requests to the L2''' cache from the core and the snoop requests from the FSB. The '''bus controller''' handles '''data and I/O requests''' to and from the FSB.&lt;br /&gt;
* The '''prefetching''' unit is extended to handle the hardware '''prefetches for each core separately'''.&lt;br /&gt;
* A '''new logical unit''' (represented by the hexagon) was added to maintain '''fairness between the requests''' coming from the different cores and hence balance the requests to L2 and memory.&lt;br /&gt;
&lt;br /&gt;
This new '''partitioned structure''' for the  memory/L2 access control unit '''enhanced''' the '''performance''' while '''reducing power consumption'''. &lt;br /&gt;
For more information on uniprocessor and multiprocessor implementation under the Intel architecture, refer to &lt;br /&gt;
[http://www.intel.com/technology/itj/2006/volume10issue02/art02_CMP_Implementation/p03_implementation.htm CMP Implementation in Intel Core Duo Processors]&lt;br /&gt;
&lt;br /&gt;
The '''Intel bus architecture''' has been '''evolving''' in order to accommodate the demands of scalability while using the '''same [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol'''; From using a '''single shared bus''' to '''dual independent buses (DIB)''' doubling the available bandwidth and to the logical conclusion of DIB with the introduction of '''dedicated high-speed interconnects (DHSI)'''. The DHSI-based platforms use four FSBs, one for each processor in the platform. In both DIB and DHSI, the snoop filter was used in the chipset to cache snoop information, thereby significantly reducing the broadcasting needed for the snoop traffic on the buses. With the production of processors based on next generation 45-nm Hi-k Intel Core microarchitecture, the [http://en.wikipedia.org/wiki/Xeon Intel Xeon] processor fabric will transition from a DHSI, with the memory controller in the chipset, to a distributed shared memory architecture using '''Intel QuickPath Interconnects using MESIF protocol'''.&lt;br /&gt;
&lt;br /&gt;
==AMD - Advanced Micro Devices Processors==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===MOESI &amp;amp; AMD Processors===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===AMD Opteron memory Architecture===&lt;br /&gt;
&lt;br /&gt;
[[Image:Untitled.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; AMD Opteron memory Architecture]]&lt;br /&gt;
&lt;br /&gt;
The AMD processor’s high-performance cache architecture includes an integrated, 64-bit, dual-ported  128-Kbyte split-L1 cache with separate snoop port, multi-level translation lookaside buffers (TLBs), a scalable L2 cache controller with a 72-bit (64-bit data + 8-bit ECC) interface to as much as 8-Mbyte of industry-standard SDR or DDR SRAMs, and an integrated tag for the most cost-effective 512-Kbyte L2 configurations. The AMD Athlon processor’s integrated L1 cache comprises two separate 64-Kbyte, two-way set-associative data and instruction caches.&lt;br /&gt;
&lt;br /&gt;
More information about this can be found in [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD 64 bit Architecture Programmers's Manual]&lt;br /&gt;
&lt;br /&gt;
===Special Coherence Considerations in AMD64 architectures===&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
Instruction prefetching is a technique used to speedup the execution of the program. But in multiprocessors, prefetching comes at the cost of performance. Due to prefetching, the data can be modified in such a way that the memory coherence protocol will not be able to handle the effects. In such situations software must use serializing instructions or cache-invalidation instructions to guarantee subsequent data accesses are coherent. &lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
An example of this type of a situation is a page-table update followed by accesses to the physical pages referenced by the updated page tables. The physical-memory references for the page tables are different than the physical-memory references for the data. Because of prefetching, there maybe problem with correctness. The following sequence of events shows such a situation when software changes the translation of virtual-page A from physical-page M to physical-page N:&lt;br /&gt;
# The tables that translate virtual-page A to physical-page M are now held only in main memory. The copies in the cache ae invalidated.&lt;br /&gt;
# Page-table entry is changed by the software for virtual-page A in main memory to point to physical page N rather than physical-page M.&lt;br /&gt;
# Data in virtual-page A is accessed.&lt;br /&gt;
&lt;br /&gt;
Software expects the processor to access the data from physical-page N after the update. However, it is possible for the processor to prefetch the data from physical-page M before the page table for virtual page A is updated. Because the physical-memory references are different, the processor does not recognize them as requiring coherence checking and believes it is safe to prefetch the data from virtual-page A, which is translated into a read from physical page M. Similar behavior can occur when instructions are prefetched from beyond the page table update instruction.&lt;br /&gt;
&lt;br /&gt;
In order to prevent errors from occuring, there are special instructions provided by software like INVLPG or MOV CR3 instruction which is executed immediately after the page-table update to ensure that subsequent instruction fetches and data accesses use the correct virtual-page-to-physical-page translation. It is not necessary to perform a TLB invalidation operation preceding the table update.&lt;br /&gt;
&lt;br /&gt;
More information can be found about this in [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD64 Architecture Programmer's manual]&lt;br /&gt;
&lt;br /&gt;
===Optimization techniques on MOESI when implemented on AMD Phenom processors===&lt;br /&gt;
&lt;br /&gt;
In real machines, using some optimization techniques on the standard cache coherence protocol used, improves the performance of the machine. For example, [http://en.wikipedia.org/wiki/AMD_Phenom AMD Phenom] family of microprocessors (Family 0×10) which is AMD’s first generation to incorporate 4 distinct cores on a single die. It is the first to have a cache that all the cores share, using the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol with some optimization techniques incorporated. &lt;br /&gt;
&lt;br /&gt;
It focuses on a small subset of compute problems which behave like Producer and Consumer programs. In such a computing problem, a thread of a program running on a single core produces data, which is consumed by a thread that is running on a separate core. With such programs, it is desirable to get the two distinct cores to communicate through the shared cache, to avoid round trips to/from main memory. The '''MOESI''' protocol that the [http://en.wikipedia.org/wiki/AMD_Phenom AMD Phenom] cache uses for cache coherence can also limit bandwidth. Hence by keeping the cache line in the '''M''' state for such computing problems, we can achieve better performance.&lt;br /&gt;
&lt;br /&gt;
When the producer thread , writes a new entry, it allocates cache-lines in the '''M''' state. Eventually, these M-marked cache lines will start to fill the L3 cache. When the consumer reads the cache line, the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol changes the state of the cache line to the '''O''' state in the L3 cache and pulls down a '''shared (S)''' copy for its own use. Now, the producer thread circles the ring buffer to arrive back to the same cache line it had previously written. However, when the producer attempts to write new data to the owned (marked '''‘O’''') cache line, it finds that it cannot, since a cache line in the '''O''' state by the previous consumer read does not have sufficient permission for a write request (in the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]). To maintain coherence, the memory controller must initiate probes in the other caches (to handle any other S copies that may exist). This will slow down the process.&lt;br /&gt;
&lt;br /&gt;
Thus, it is preferable to keep the cache line in the '''M''' state in the L3 cache. In such a situation, when the producer comes back around the ring buffer, it finds the previously written cache line still in the'''M''' state, to which it is safe to write without coherence concerns. Thus better performance can be achieved by such optimization techniques to standard protocols when implemented in real machines.&lt;br /&gt;
&lt;br /&gt;
You can find more information on how this is implemented and various other ways of optimizations in this manual [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf Software Optimization guide for AMD 10h Processors].&lt;br /&gt;
&lt;br /&gt;
==Xerox Corporation==&lt;br /&gt;
===Dragon Protocol &amp;amp; Xerox Dragon Processors===&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' is an update based coherence protocol which does not invalidate other cached copies like what we have seen in the coherence protocols so far. Write propagation is achieved by updating the cached copies instead of invalidating them.  But the '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' does not update memory on a cache to cache transfer and delays the memory and cache consistency until the data is evicted and written back, which saves time and lowers the memory access requirements. Moreover only the written '''byte''' or the '''word''' is '''communicated''' to the '''other caches''' instead of the whole block which further '''reduces''' the '''bandwidth''' usage. It has the ability to detect dynamically, the sharing status of a block and use a write through policy for shared blocks and write back for currently non-shared blocks. The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' employs the following four states for the cache blocks: '''Shared Clean''', '''Shared Modified''', '''Exclusive''', and  '''Modified'''. &lt;br /&gt;
* '''Modified (M)''' and '''Exclusive (E)''' - these states have the same meaning as explained in the protocols above. &lt;br /&gt;
* '''Shared Modified (Sm)''' - Only one cache line in the system can be in the Shared Modified state. Potentially two or more caches    have this block and memory may or may not be up to date and this processor's cache had modified the block.&lt;br /&gt;
* '''Shared Clean (Sc)''' -  Potentially two or more caches have this block and memory may or may not be up to date(if no other cache has it in Sm state, memory will be up to date else it is not).&lt;br /&gt;
When a Shared Modified line is evicted from the cache on a cache miss only then is the block written back to the main memory in order to keep memory consistent. For more information on Dragon protocol, refer to Solihin textbook, page number 229. The state transition diagram has been given below for reference.&lt;br /&gt;
&lt;br /&gt;
[[Image:Dragon.jpg|frame|center|&amp;lt;b&amp;gt;Figure 9:&amp;lt;/b&amp;gt; Dragon Protocol State Diagram]]&lt;br /&gt;
&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' , was developed by Xerox Palo Alto Research Center ('''[http://en.wikipedia.org/wiki/Xerox_PARC Xerox PARC]'''), a subsidiary of Xerox Corporation.  This protocol was used in the '''[http://en.wikipedia.org/w/index.php?title=Xerox_Dragon&amp;amp;redirect=no Xerox PARC Dragon]''' multiprocessor workstation, a VLSI research computer that could support multiple processors on a central high bandwidth memory bus. The Dragon design implemented snoopy caches that provided the appearance of a uniform memory space to multiple processors. Here, each cache listens to 2 buses: the processor bus and the memory bus. The caches are also responsible for address translation, so the processor bus carries virtual addresses and the memory bus carries physical addresses.  The Dragon system was designed to support 4 to 8 Dragon processors. The memory bus used in the Xeron Dragon evolved to become the '''[http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=289691 XDBus]''' , a low-cost, synchronous, '''packet-switched VLSI bus''' designed for use in high-performance multiprocessors. This was used as the interconnect in many multiprocessor server systems like '''Cray Superserver 6400''', '''Sun Microsystems' SPARCcenter 2000''' and '''SPARCserver 1000'''  and '''Sun4d''' systems.&lt;br /&gt;
&lt;br /&gt;
=Cache Coherence Power Utilization=&lt;br /&gt;
A number of studies have been performed to reduce the power consumption of cache coherence protocols. In order to perform a solid comparison between the cache coherency protocols, one would need to develop a multi-core processor for each of the cache coherency protocols. Additionally, the hardware and software configuration would also need to be similar between each system (except for the hardware required to implement each of the different protocols). Unfortunately, there are no such processors available. This section will discuss power consumption in general terms, comparing to each of the protocols. Also, this section will briefly discussion some power optimization techniques.&lt;br /&gt;
&lt;br /&gt;
Bus transactions, in general, are costly for both performance and power consumption. Additionally, studies have been performed showing that unnecessary snooping can waste power. Power requirements are typically determined by the number of bus snoops and number of bus accesses by each processor. One study indicates that interchip bus communications can consume up to 20% of total chip power[[#References|&amp;lt;sup&amp;gt;[20]&amp;lt;/sup&amp;gt;]].&lt;br /&gt;
Using the examples from the class notes, we can analyze the relative power consumption between the protocols. The following table is a summary of various protocols showing the number of bus communications that occur for each processor action.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|'''Processor Action'''&lt;br /&gt;
|'''MSI Bus Actions'''&lt;br /&gt;
|'''MESI Bus Actions'''&lt;br /&gt;
|'''Dragon Bus Actions'''&lt;br /&gt;
|'''FireFly Bus Actions'''&lt;br /&gt;
|-&lt;br /&gt;
|R1&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|-&lt;br /&gt;
|W1&lt;br /&gt;
|BusRdX&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R3&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|-&lt;br /&gt;
|W3&lt;br /&gt;
|BusRdX&lt;br /&gt;
|BusRdX&lt;br /&gt;
|BusUpd/Upd&lt;br /&gt;
|BusUpd&lt;br /&gt;
|-&lt;br /&gt;
|R1&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R3&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R2&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 4:&amp;lt;/b&amp;gt; Summary of Bus Actions for Select Protocols&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
From the table above, we can see that MSI has a larger number of bus transactions than the Dragon protocol. Even though bus transactions are not power efficient, snooping can also be enhanced to improve power efficiency. The following section will discuss snoop filtering techniques.&lt;br /&gt;
&lt;br /&gt;
==Power Savings Using Snoop Filtering==&lt;br /&gt;
A number of studies have been performed to reduce the number of unnecessary snoops during cache transactions. Two such filtering techniques are serial snooping and Jetty. The following sections will briefly discuss these two filtering techniques and power savings achieved using these techniques. Studies show that as much as 90% of snoop broadcasts will result in a miss[[#References|&amp;lt;sup&amp;gt;[19]&amp;lt;/sup&amp;gt;]] in the other caches at the same level and require that the information be provided by the next level of cache or memory. As much as a 36% savings in power by filtering snoops using one of the following snoop filtering methods[[#References|&amp;lt;sup&amp;gt;[19]&amp;lt;/sup&amp;gt;]].&lt;br /&gt;
===Serial Snooping===&lt;br /&gt;
Serial snooping takes advantage of the fact that if a miss occurs in one cache, it is possible to find the block in one other cache without having to check all the caches. If the cache block is available in multiple caches, there is a high probability that the cache miss can find the data in a nearby cache. Alternatively, savings can be realized by searching a subset of the caches vice all the caches. One thing to note is that this is only effective for read misses. Write, an invalidation transaction needs to be transmitted to the other caches, thus a bus transaction is unavoidable.&lt;br /&gt;
===Jetty===&lt;br /&gt;
Jetty is a mechanism attached to each cache that verifies that a bus snoop is necessary. Jetty is used to filter L2 tag lookups. When a processor needs to perform a bus snoop, the Jetty is checked first. The Jetty can determine if a cache tag lookup is required. Since the Jetty is much smaller than the associated cache, less power is required to determine if a snoop is required.&lt;br /&gt;
&lt;br /&gt;
There are a couple of different Jetty schemes. There is the exclude-Jetty, include-Jetty, and hybrid-Jetty. The exclude-Jetty exploits the fact that if a cache block is snooped, it is highly likely the same cache block will be snooped in the near future. The exclude-Jetty keeps track of the tag lookups in a small table and can determine if a cache tag lookup is necessary.&lt;br /&gt;
&lt;br /&gt;
The include-Jetty keeps a superset of the blocks that are cached. If a miss occurs in the include-Jetty, then it can be guaranteed that the block is not stored in its associated cache.&lt;br /&gt;
&lt;br /&gt;
The hybrid-Jetty is simply a combinations of and include and exclude-Jetty. Both types of Jetty are present and when a lookup occurs, both Jettys are checked to determine if a cache lookup is necessary.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Cache_coherence Cache coherence]&lt;br /&gt;
# [http://www.intel.com/technology/quickpath/introduction.pdf Introduction to QuickPath Interconnect]&lt;br /&gt;
# [http://www.intel.com/technology/itj/2006/volume10issue02/art02_CMP_Implementation/p03_implementation.htm CMP Implementation in Intel Core Duo Processors]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Symmetric_multiprocessing Common System Interface in Intel Processors]&lt;br /&gt;
# [http://www.zak.ict.pwr.wroc.pl/nikodem/ak_materialy/Cache%20consistency%20&amp;amp;%20MESI.pdf Cache consistency with MESI on Intel processor]&lt;br /&gt;
# [http://techreport.com/articles.x/8236/2 AMD dual core Architecture]&lt;br /&gt;
# [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD64 Architecture Programmer's manual]&lt;br /&gt;
# [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf Software Optimization guide for AMD 10h Processors]&lt;br /&gt;
# [http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html Architecture of AMD 64 bit core]&lt;br /&gt;
# [http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=4913 Silicon Graphics Computer Systems]&lt;br /&gt;
# [http://books.google.com/books?id=g82fofiqa5IC&amp;amp;printsec=frontcover&amp;amp;dq=Parallel+computer+architecture:+a+hardware/software+approach+By+David+E.+Culler,+Jaswinder+Pal+Singh,+Anoop+Gupta&amp;amp;source=bl&amp;amp;ots=COrdamlfVn&amp;amp;sig=YcugVqbzTjHvlofvaFq6Ft_tjfY&amp;amp;hl=en&amp;amp;ei=0ZO6S4TJGcOclgejzI3BBw&amp;amp;sa=X&amp;amp;oi=book_result&amp;amp;ct=result&amp;amp;resnum=1&amp;amp;ved=0CAgQ6AEwAA#v=onepage&amp;amp;q=&amp;amp;f=false Parallel computer architecture: a hardware/software approach By David E. Culler, Jaswinder Pal Singh, Anoop Gupta]&lt;br /&gt;
# [http://www.freepatentsonline.com/5283886.html Three state invalidation protocols]&lt;br /&gt;
# [http://portal.acm.org/citation.cfm?id=1499317&amp;amp;dl=GUIDE&amp;amp;coll=GUIDE&amp;amp;CFID=83027384&amp;amp;CFTOKEN=95680533 Synapse tightly coupled multiprocessors: a new approach to solve old problems]&lt;br /&gt;
# [http://portal.acm.org/citation.cfm?id=6514Cache Coherence protocols: evaluation using a multiprocessor simulation model]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Xerox_Dragon Xerox Dragon]&lt;br /&gt;
# [http://thanaseto.110mb.com/courses/CSD-527-report-engl.pdf Coherence Protocols]&lt;br /&gt;
# [http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=289691 XDBus]&lt;br /&gt;
# [http://www.ece.wisc.edu/~wddd/2002/final/ekman.pdf Evaluation of Snoop-Energy Reduction Techniques for Chip-Multiprocessors]&lt;br /&gt;
# [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.79.7463&amp;amp;rep=rep1&amp;amp;type=pdf Power Efficient Cache Coherence]&lt;/div&gt;</summary>
		<author><name>Mqtran</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2011/ch8_mc&amp;diff=44462</id>
		<title>CSC/ECE 506 Spring 2011/ch8 mc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2011/ch8_mc&amp;diff=44462"/>
		<updated>2011-03-20T00:04:28Z</updated>

		<summary type="html">&lt;p&gt;Mqtran: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Introduction to bus-based cache coherence in real machines=&lt;br /&gt;
&lt;br /&gt;
Most parallel software in the commercial market relies on the shared-memory&lt;br /&gt;
programming model in which all processors access the same physical address space. The most common multiprocessors today use [http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP] architecture which use a common bus as the interconnect.  In the case of multicore processors (&amp;quot;chip multiprocessors,&amp;quot; or CMP) the [http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP] architecture applies to the cores treating them as separate processors. The key problem of shared-memory multiprocessors is providing a consistent view of memory with various cache hierarchies.  This is called '''''cache coherence problem'''''. It is  critical to  achieve correctness and performance-sensitive design point for supporting the shared-memory model. The cache coherence mechanisms not only govern communication in a shared-memory multiprocessor, but also typically determine how the memory system transfers data between processors, caches, and memory.&lt;br /&gt;
&lt;br /&gt;
[[Image:Busbased SMP.jpg|frame|center|&amp;lt;b&amp;gt;Figure 1:&amp;lt;/b&amp;gt; Typical Bus-Based Processor Model]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Cache Coherence in real machines=&lt;br /&gt;
==Summary of Cache Coherence Protocols==&lt;br /&gt;
At any point in logical time, the permissions for a cache block can allow either a single writer or multiple readers. The '''''coherence protocol''''' ensures the invariants of the states are maintained. The different coherent states used by most of the cache coherent protocols are shown in ''Table 1'':&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''States'''&lt;br /&gt;
|  '''Access Type'''&lt;br /&gt;
|  '''Invariant'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  read, write&lt;br /&gt;
|  all other caches in I state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  read&lt;br /&gt;
|  all other caches in I state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Owned'''&lt;br /&gt;
|  read&lt;br /&gt;
|  all other caches in I or S state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  read&lt;br /&gt;
|  no other cache in M or E state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|  -&lt;br /&gt;
|  -&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 1:&amp;lt;/b&amp;gt; States Used by the Cache Coherent Protocols&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
The first widely adopted approach to cache coherence is snooping on a bus. We will now discuss them in details in the following sections.&lt;br /&gt;
&lt;br /&gt;
===MSI===&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI protocol]''' is a three-state write-back '''invalidation protocol''' which is one of the earliest snooping-based cache coherence-protocols. It marks the cache line with one of the '''Modified (M) ,Shared (S)''', and '''Invalid (I)''' state. '''Invalid''' means the cache line is either not present or is in invalid state. If the cache line is clean and is shared by more than one processor , it is marked as '''Shared'''. If a cache line is dirty and the processor has exclusive ownership of it, it is in '''Modified''' state. BusRdx causes other processors to invalidate (demote) its cache block to the '''I''' state. If it is present in the '''M''' state in another cache, it will flush. &lt;br /&gt;
&lt;br /&gt;
The following state transition diagram for MSI protocol explains the working of the protocol:&lt;br /&gt;
&lt;br /&gt;
[[Image:MSI.jpg|frame|center|&amp;lt;b&amp;gt;Figure 2:&amp;lt;/b&amp;gt; MSI State Diagram]]&lt;br /&gt;
&lt;br /&gt;
===MESI===&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI protocol]''' has a major drawback in that each read-write sequence incurs two bus transactions irrespective of whether the cache line is stored in only one cache or not. This is a huge setback for highly parallel programs that have little data sharing. '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol solves this problem by introducing the E ('''Exclusive''') state to distinguish between a cache line stored in multiple caches and a line stored in a single cache.&lt;br /&gt;
Let us briefly look at how the MESI protocol works. (For a more detailed version readers are referred to Solihin textbook pg. 215)&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' coherence protocol marks each cache line in one of the Modified, Exclusive, Shared or Invalid state. &lt;br /&gt;
* '''Invalid''' : The cache line is either not present or is invalid&lt;br /&gt;
* '''Exclusive''' : The cache line is clean and is owned by this core/processor only&lt;br /&gt;
* '''Modified''' :  This implies that the cache line is dirty and the core/processor has  exclusive ownership of the cache line, exclusive of the memory also.&lt;br /&gt;
* '''Shared''' : The cache line is clean and is shared by more than one core/processor&lt;br /&gt;
&lt;br /&gt;
In a nutshell, the '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol works as the following: &lt;br /&gt;
A line that is just fetched receives '''E''' or '''S''' state depending on whether it exists in other processors in the system or not. Similarly, a cache line gets the '''M''' state when a processor writes to it. If the line is not in '''E''' or '''M''' state prior to being written to, the cache sends a Bus Upgrade (BusUpgr) signal or as the Intel manuals call it, a “Read-For-Ownership (RFO) request” that ensures that the line exists in the cache and is in the '''I''' state in all other processors on the bus (if any). The table shown below will summarize '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''Cache Line State:'''&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''This cache line is valid?'''&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  No&lt;br /&gt;
|-&lt;br /&gt;
|  '''The memory copy is…'''&lt;br /&gt;
|  out of date&lt;br /&gt;
|  valid&lt;br /&gt;
|  valid&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''Copies exist in caches of other processors?'''  &lt;br /&gt;
|  No&lt;br /&gt;
|  No&lt;br /&gt;
|  Maybe&lt;br /&gt;
|  Maybe&lt;br /&gt;
|-&lt;br /&gt;
|  '''A write to this line'''&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  goes to bus and updates cache&lt;br /&gt;
|  goes directly to bus&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 2:&amp;lt;/b&amp;gt; MESI Protocol Summary&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The transition diagram from the lecture slides is given below for reference.&lt;br /&gt;
&lt;br /&gt;
[[Image:MESI.jpg|frame|center|&amp;lt;b&amp;gt;Figure 4:&amp;lt;/b&amp;gt; MESI State Diagram]]&lt;br /&gt;
&lt;br /&gt;
===MESIF===&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/MESIF_protocol MESIF]''' protocol, used in the latest Intel multi-core processors Core i7, was introduced to '''accommodate the point-to-point''' links used in the QuickPath Interconnect. Using the '''MESI''' protocol in this architecture would send many redundant messages between different processors, often with unnecessarily high latency. For example, when a processor requests a cache line that is stored in multiple locations, every location might respond with the data. As the requesting processor only needs a single copy of the data, the system would be '''wasting the bandwidth'''. &lt;br /&gt;
As a '''solution''' to this problem, an additional state, '''Forward state''', was added by slightly changing the role of the Shared state. Whenever there is a read request, only the cache line in the F state will respond to the request, while all the S state caches remain dormant.  Hence, by designating a single cache line to '''respond to requests''', coherency traffic is substantially reduced when multiple copies of the data exist. Also, on a read request, the F state transitions to the S state. That is, when a cache line in the '''F''' state is '''copied''', the F state '''migrates''' to the '''newer copy''', while the '''older''' one drops back to the '''S''' state. Moving the new copy to the F state '''exploits''' both '''temporal and spatial locality'''. Because the newest copy of the cache line is always in the F state, it is very unlikely that the line in the F state will be evicted from the caches. This takes advantage of the temporal locality of the request. The second advantage is that if a particular cache line is in high demand due to spatial locality, the bandwidth used to transmit that data will be spread across several cores.&lt;br /&gt;
All M to S state transitions and E to S state transitions will now be from '''M to F''' and '''E to F'''.  &lt;br /&gt;
The '''F state''' is '''different''' from the '''Owned state''' of the MOESI protocol as it is '''not''' a '''unique''' copy because a valid copy is stored in memory. Thus, unlike the Owned state of the MOESI protocol, in which the data in the O state is the only valid copy of the data, the data in the F state can be evicted or converted to the S state, if desired. &lt;br /&gt;
&lt;br /&gt;
More information on the QuickPath Interconnect and MESIF protocol can be found at&lt;br /&gt;
'''[http://www.intel.com/technology/quickpath/introduction.pdf Introduction to QuickPath Interconnect]'''. &lt;br /&gt;
&lt;br /&gt;
===MOESI===&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/Opteron AMD Opteron] was AMD’s first-generation dual core processor which had two distinct [http://en.wikipedia.org/wiki/Athlon_64 K8 cores] together on a single die. Cache coherence produces bigger problems on such multicore processors. It was necessary to use an appropriate coherence protocol to address this problem. The [http://en.wikipedia.org/wiki/Xeon Intel Xeon], which was the competitive counterpart from Intel to AMD dual core Opteron, used the [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol to handle cache coherence. [http://en.wikipedia.org/wiki/MESI_protocol MESI] came with the drawback of using much time and bandwidth in certain situations. &lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/MOESI_protocol MOESI] was AMD’s answer to this problem. [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] added a fifth state to [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol called the '''owned''' state. [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol addresses the bandwidth problem faced by MESI protocol when processor having invalid data in its cache wants to modify the data.  The processor seeking the data will have to wait for the processor which modified this data to write back to the main memory, which takes time and bandwidth. This drawback is removed in MOESI by allowing dirty sharing.  When the data is held by a processor in the new state '''owned''', it can provide other processors the modified data without writing it to the main memory. This is called '''''dirty sharing'''''. The processor with the data in the '''owned''' state stays responsible to update the main memory later when the cache line is evicted.&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/MOESI_protocol MOESI]  has become one of the most popular snoop-based protocols supported in AMD64 architecture.  AMD dual-core Opteron can maintain cache coherence in systems up to 8 processors using this protocol.&lt;br /&gt;
&lt;br /&gt;
The five different states of [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol are:&lt;br /&gt;
* '''Modified (M)''': The most recent copy of the data is present in the cache line. But it is not present in any other processor cache.&lt;br /&gt;
* '''Owned (O)''': The cache line has the most recent correct copy of the data. This can be shared by other processors. The processor in this state for this cache line is responsible to update the correct value in the main memory before it gets evicted.&lt;br /&gt;
* '''Exclusive (E)''': A cache line holds the most recent, correct copy of the data, which is exclusively present on this processor and a copy is present in the main memory.&lt;br /&gt;
* '''Shared (S)''': A cache line in the shared state holds the most recent, correct copy of the data, which may be shared by other processors.&lt;br /&gt;
* '''Invalid (I)''': A cache line does not hold a valid copy of the data.&lt;br /&gt;
&lt;br /&gt;
A detailed explanation of this protocol implementation on AMD processor can be found in the manual [http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html Architecture of AMD 64-bit core]&lt;br /&gt;
&lt;br /&gt;
The following table summarizes the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''Cache Line State:'''&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  '''Owner''' &lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''This cache line is valid?'''&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  No&lt;br /&gt;
|-&lt;br /&gt;
|  '''The memory copy is…'''&lt;br /&gt;
|  out of date&lt;br /&gt;
|  out of date&lt;br /&gt;
|  valid&lt;br /&gt;
|  valid&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''Copies exist in caches of other processors?'''&lt;br /&gt;
|  No&lt;br /&gt;
|  No&lt;br /&gt;
|  Yes(out of date values)|  Maybe&lt;br /&gt;
|  Maybe&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''A write to this line'''&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  does not go to bus|  does not go to bus&lt;br /&gt;
|  goes to bus and updates cache&lt;br /&gt;
|  goes directly to bus&lt;br /&gt;
|  -&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 3:&amp;lt;/b&amp;gt; MOESI Protocol Summary&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
State transition for [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]is as shown below : &lt;br /&gt;
&lt;br /&gt;
[[Image:MOESI_State_Transition_Diagram.jpg|frame|center|&amp;lt;b&amp;gt;Figure 7:&amp;lt;/b&amp;gt; [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]State transition Diagram]]&lt;br /&gt;
&lt;br /&gt;
We will now discuss which cache coherence protocol processor vendors like '''Intel''', '''AMD''' and others adopt in various products.&lt;br /&gt;
&lt;br /&gt;
==SGI - Silicon Graphics, Inc==&lt;br /&gt;
===MSI &amp;amp; SGI IRIS 4D Processors===&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' protocol was first used in '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''' IRIS 4D series. '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''' produced a broad range of '''[http://en.wikipedia.org/wiki/MIPS_architecture MIPS]'''-based (Microprocessor without Interlocked Pipeline Stages) workstations and servers during the 1990s, running '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''''s version of UNIX System V, now called '''[http://en.wikipedia.org/wiki/IRIX IRIX]'''. The 4D-MP graphics superworkstation brought 40 MIPS(million instructions per second) of computing performance to a graphics superworkstation. The unprecedented level of computing and graphics processing in an office-environment workstation was made possible by the fastest available Risc microprocessors in a single shared memory multiprocessor design driving a tightly coupled, highly parallel graphics system. Aggregate sustained data rates of over one gigabyte per second were achieved by a hierarchy of buses in a balanced system designed to avoid bottlenecks.&lt;br /&gt;
&lt;br /&gt;
The multiprocessor bus used in 4D-MP graphics superworkstation is a pipelined, block transfer bus that supports the cache coherence protocol as well as providing 64 megabytes of sustained data bandwidth between the processors, the memory and I/O system, and the graphics subsystem. Because the sync bus provides for efficient synchronization between processors, the cache coherence protocol was designed to support efficient data sharing between processors. If a cache coherence protocol has to support synchronization as well as sharing, a compromise in the efficiency of the data sharing protocol may be necessary to improve the efficiency of the synchronization operations. Hence it uses the simple cache coherence protocol which is the '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' protocol.&lt;br /&gt;
&lt;br /&gt;
With the simple rules of '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]'''protocol enforced by hardware, efficient synchronization and efficient data sharing are achieved in a simple shared memory model of parallel processing in the 4D-MP graphics superworkstation.&lt;br /&gt;
&lt;br /&gt;
==SYNAPSE Multiprocessor==&lt;br /&gt;
===Synapse protocol and Synapse multiprocessor===&lt;br /&gt;
From the state transition diagram of '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''', we observe that for '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' there is transition to the '''S''' state from the '''M''' state when a BusRd is observed for that block. The contents of the block is flushed to the bus before going to '''S''' state. It would look more appropriate to move to the '''I''' state thus giving up the block entirely in certain cases. This choice of moving to '''S''' or '''I''' reflects the designer's assertion that the original processor is more likely to continue reading the block than the new processor to write to the block. In synapse protocol, used in the early Synapse multiprocessor, made this alternate choice of going directly from the '''M''' state to the '''I''' state on a BusRd, assuming the migratory pattern would be more frequent. More details about this protocol can be found in these papers published in late 1980's [http://portal.acm.org/citation.cfm?id=6514Cache Coherence protocols: evaluation using a multiprocessor simulation model] and [http://portal.acm.org/citation.cfm?id=1499317&amp;amp;dl=GUIDE&amp;amp;coll=GUIDE&amp;amp;CFID=83027384&amp;amp;CFTOKEN=95680533 Synapse tightly coupled multiprocessors: a new approach to solve old problems]&lt;br /&gt;
&lt;br /&gt;
In the Synapse protocol, the '''M''' state is called the '''D''' (Dirty) state. The following is the state transition diagram for Synapse protocol which clearly shows its working.&lt;br /&gt;
&lt;br /&gt;
[[Image:Synapse1.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; Synapse State Diagram]]&lt;br /&gt;
&lt;br /&gt;
==Intel==&lt;br /&gt;
===MESI &amp;amp; Intel Processors===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The '''Pentium Pro''' microprocessor, introduced in 1992 was the '''first''' Intel architecture microprocessor to support symmetric multiprocessing ('''[http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP]''') in various multiprocessor configurations. '''[http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP]''' and '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol was the architecture used consistently until the introduction of the 45-nm Hi-k Core micro-architecture in '''Intel's (Nehalem-EP) quad-core x86-64'''. The 45-nm Hi-k Intel Core microarchitecture utilizes a new system of framework called the '''QuickPath Interconnect''' which uses point-to-point interconnection technology based on distributed shared memory architecture. It uses a modified version of '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol called '''MESIF''', by introducing an additional state, F, the forward state. &lt;br /&gt;
&lt;br /&gt;
The '''Intel architecture''' uses the '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol  as the '''basis''' to ensure cache coherence, which is true whether you're on one of the older processors that use a '''common bus''' to communicate or using the new Intel '''QuickPath''' point-to-point interconnection technology. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== CMP Implementation in Intel Architecture ===&lt;br /&gt;
&lt;br /&gt;
Let us now see how Intel architecture using the [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol progressed from a uniprocessor architecture to a Chip MultiProcessor (CMP) using the bus as the interconnect. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Uniprocessor Architecture'''&lt;br /&gt;
&lt;br /&gt;
The diagram below shows the structure of the memory cluster in Intel Pentium M processor.&lt;br /&gt;
&lt;br /&gt;
[[Image:intel_cache1.jpg|frame|center|&amp;lt;b&amp;gt;Figure 5:&amp;lt;/b&amp;gt; Memory Structure of the Pentium M Processor]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In this structure we have,&lt;br /&gt;
* A unified on-chip '''L1 cache''' with the '''processor/core''',&lt;br /&gt;
* A '''Memory/L2 access control unit''', through which all the accesses to the L2 cache, main memory and IO space are made,&lt;br /&gt;
* The second level '''L2 cache''' along with the '''prefetch unit''' and&lt;br /&gt;
* '''Front side bus (FSB)''', a single shared bi-directional bus through which all the traffic is sent across.These wide buses bring in multiple data bytes at a time. &lt;br /&gt;
&lt;br /&gt;
As Intel explains it, using this structure, the processor requests were first sought in the '''L2 cache''' and only on a '''miss''', were they '''forwarded''' to the main '''memory''' via the front side bus ('''FSB'''). The '''Memory/L2 access control''' unit served as a central point for '''maintaining coherence''' within the core and with the external world. It '''contains''' a '''snoop control unit''' that receives snoop requests from the bus and performs the required operations on each cache (and internal buffers) in parallel. It also handles RFO requests (BusUpgr) and ensures the operation continues only after it guarantees that no other version on the cache line exists in any other cache in the system.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''CMP Architecture'''&lt;br /&gt;
&lt;br /&gt;
For CMP implementation, Intel chose the bus-based architecture using snoopy protocols vs the '''directory protocol''' because though directory protocol reduces the active power due to reduced snoop activity, it '''increased''' the '''design complexity''' and the '''static power''' due to larger tag arrays. Since Intel has a large market for the processors in the mobility family, directory-based solution was less favorable since battery life mainly depends on static power consumption and less on dynamic power.&lt;br /&gt;
Let us examine how '''CMP''' was implemented in '''Intel Core Duo''', which was one of the first dual-core processor for the budget/entry-level market. &lt;br /&gt;
The general CMP implementation structure of the Intel Core Duo is shown below&lt;br /&gt;
&lt;br /&gt;
[[Image:intel_cache2.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; Intel Core Duo CMP Implementation]]&lt;br /&gt;
&lt;br /&gt;
This structure has the following changes when compared to the uniprocessor memory cluster structure. &lt;br /&gt;
* '''L1 cache''' and the '''processor/core''' structure is '''duplicated''' to give 2 cores.&lt;br /&gt;
* The '''Memory/L2 access control''' unit is '''split''' into 2 logical units: '''L2 controller''' and '''bus controller'''. The L2 controller handles all '''requests to the L2''' cache from the core and the snoop requests from the FSB. The '''bus controller''' handles '''data and I/O requests''' to and from the FSB.&lt;br /&gt;
* The '''prefetching''' unit is extended to handle the hardware '''prefetches for each core separately'''.&lt;br /&gt;
* A '''new logical unit''' (represented by the hexagon) was added to maintain '''fairness between the requests''' coming from the different cores and hence balance the requests to L2 and memory.&lt;br /&gt;
&lt;br /&gt;
This new '''partitioned structure''' for the  memory/L2 access control unit '''enhanced''' the '''performance''' while '''reducing power consumption'''. &lt;br /&gt;
For more information on uniprocessor and multiprocessor implementation under the Intel architecture, refer to &lt;br /&gt;
[http://www.intel.com/technology/itj/2006/volume10issue02/art02_CMP_Implementation/p03_implementation.htm CMP Implementation in Intel Core Duo Processors]&lt;br /&gt;
&lt;br /&gt;
The '''Intel bus architecture''' has been '''evolving''' in order to accommodate the demands of scalability while using the '''same [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol'''; From using a '''single shared bus''' to '''dual independent buses (DIB)''' doubling the available bandwidth and to the logical conclusion of DIB with the introduction of '''dedicated high-speed interconnects (DHSI)'''. The DHSI-based platforms use four FSBs, one for each processor in the platform. In both DIB and DHSI, the snoop filter was used in the chipset to cache snoop information, thereby significantly reducing the broadcasting needed for the snoop traffic on the buses. With the production of processors based on next generation 45-nm Hi-k Intel Core microarchitecture, the [http://en.wikipedia.org/wiki/Xeon Intel Xeon] processor fabric will transition from a DHSI, with the memory controller in the chipset, to a distributed shared memory architecture using '''Intel QuickPath Interconnects using MESIF protocol'''.&lt;br /&gt;
&lt;br /&gt;
==AMD - Advanced Micro Devices Processors==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===MOESI &amp;amp; AMD Processors===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===AMD Opteron memory Architecture===&lt;br /&gt;
&lt;br /&gt;
[[Image:Untitled.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; AMD Opteron memory Architecture]]&lt;br /&gt;
&lt;br /&gt;
The AMD processor’s high-performance cache architecture includes an integrated, 64-bit, dual-ported  128-Kbyte split-L1 cache with separate snoop port, multi-level translation lookaside buffers (TLBs), a scalable L2 cache controller with a 72-bit (64-bit data + 8-bit ECC) interface to as much as 8-Mbyte of industry-standard SDR or DDR SRAMs, and an integrated tag for the most cost-effective 512-Kbyte L2 configurations. The AMD Athlon processor’s integrated L1 cache comprises two separate 64-Kbyte, two-way set-associative data and instruction caches.&lt;br /&gt;
&lt;br /&gt;
More information about this can be found in [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD 64 bit Architecture Programmers's Manual]&lt;br /&gt;
&lt;br /&gt;
===Special Coherence Considerations in AMD64 architectures===&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
Instruction prefetching is a technique used to speedup the execution of the program. But in multiprocessors, prefetching comes at the cost of performance. Due to prefetching, the data can be modified in such a way that the memory coherence protocol will not be able to handle the effects. In such situations software must use serializing instructions or cache-invalidation instructions to guarantee subsequent data accesses are coherent. &lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
An example of this type of a situation is a page-table update followed by accesses to the physical pages referenced by the updated page tables. The physical-memory references for the page tables are different than the physical-memory references for the data. Because of prefetching, there maybe problem with correctness. The following sequence of events shows such a situation when software changes the translation of virtual-page A from physical-page M to physical-page N:&lt;br /&gt;
# The tables that translate virtual-page A to physical-page M are now held only in main memory. The copies in the cache ae invalidated.&lt;br /&gt;
# Page-table entry is changed by the software for virtual-page A in main memory to point to physical page N rather than physical-page M.&lt;br /&gt;
# Data in virtual-page A is accessed.&lt;br /&gt;
&lt;br /&gt;
Software expects the processor to access the data from physical-page N after the update. However, it is possible for the processor to prefetch the data from physical-page M before the page table for virtual page A is updated. Because the physical-memory references are different, the processor does not recognize them as requiring coherence checking and believes it is safe to prefetch the data from virtual-page A, which is translated into a read from physical page M. Similar behavior can occur when instructions are prefetched from beyond the page table update instruction.&lt;br /&gt;
&lt;br /&gt;
In order to prevent errors from occuring, there are special instructions provided by software like INVLPG or MOV CR3 instruction which is executed immediately after the page-table update to ensure that subsequent instruction fetches and data accesses use the correct virtual-page-to-physical-page translation. It is not necessary to perform a TLB invalidation operation preceding the table update.&lt;br /&gt;
&lt;br /&gt;
More information can be found about this in [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD64 Architecture Programmer's manual]&lt;br /&gt;
&lt;br /&gt;
===Optimization techniques on MOESI when implemented on AMD Phenom processors===&lt;br /&gt;
&lt;br /&gt;
In real machines, using some optimization techniques on the standard cache coherence protocol used, improves the performance of the machine. For example, [http://en.wikipedia.org/wiki/AMD_Phenom AMD Phenom] family of microprocessors (Family 0×10) which is AMD’s first generation to incorporate 4 distinct cores on a single die. It is the first to have a cache that all the cores share, using the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol with some optimization techniques incorporated. &lt;br /&gt;
&lt;br /&gt;
It focuses on a small subset of compute problems which behave like Producer and Consumer programs. In such a computing problem, a thread of a program running on a single core produces data, which is consumed by a thread that is running on a separate core. With such programs, it is desirable to get the two distinct cores to communicate through the shared cache, to avoid round trips to/from main memory. The '''MOESI''' protocol that the [http://en.wikipedia.org/wiki/AMD_Phenom AMD Phenom] cache uses for cache coherence can also limit bandwidth. Hence by keeping the cache line in the '''M''' state for such computing problems, we can achieve better performance.&lt;br /&gt;
&lt;br /&gt;
When the producer thread , writes a new entry, it allocates cache-lines in the '''M''' state. Eventually, these M-marked cache lines will start to fill the L3 cache. When the consumer reads the cache line, the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol changes the state of the cache line to the '''O''' state in the L3 cache and pulls down a '''shared (S)''' copy for its own use. Now, the producer thread circles the ring buffer to arrive back to the same cache line it had previously written. However, when the producer attempts to write new data to the owned (marked '''‘O’''') cache line, it finds that it cannot, since a cache line in the '''O''' state by the previous consumer read does not have sufficient permission for a write request (in the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]). To maintain coherence, the memory controller must initiate probes in the other caches (to handle any other S copies that may exist). This will slow down the process.&lt;br /&gt;
&lt;br /&gt;
Thus, it is preferable to keep the cache line in the '''M''' state in the L3 cache. In such a situation, when the producer comes back around the ring buffer, it finds the previously written cache line still in the'''M''' state, to which it is safe to write without coherence concerns. Thus better performance can be achieved by such optimization techniques to standard protocols when implemented in real machines.&lt;br /&gt;
&lt;br /&gt;
You can find more information on how this is implemented and various other ways of optimizations in this manual [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf Software Optimization guide for AMD 10h Processors].&lt;br /&gt;
&lt;br /&gt;
==Xerox Corporation==&lt;br /&gt;
===Dragon Protocol &amp;amp; Xerox Dragon Processors===&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' is an update based coherence protocol which does not invalidate other cached copies like what we have seen in the coherence protocols so far. Write propagation is achieved by updating the cached copies instead of invalidating them.  But the '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' does not update memory on a cache to cache transfer and delays the memory and cache consistency until the data is evicted and written back, which saves time and lowers the memory access requirements. Moreover only the written '''byte''' or the '''word''' is '''communicated''' to the '''other caches''' instead of the whole block which further '''reduces''' the '''bandwidth''' usage. It has the ability to detect dynamically, the sharing status of a block and use a write through policy for shared blocks and write back for currently non-shared blocks. The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' employs the following four states for the cache blocks: '''Shared Clean''', '''Shared Modified''', '''Exclusive''', and  '''Modified'''. &lt;br /&gt;
* '''Modified (M)''' and '''Exclusive (E)''' - these states have the same meaning as explained in the protocols above. &lt;br /&gt;
* '''Shared Modified (Sm)''' - Only one cache line in the system can be in the Shared Modified state. Potentially two or more caches    have this block and memory may or may not be up to date and this processor's cache had modified the block.&lt;br /&gt;
* '''Shared Clean (Sc)''' -  Potentially two or more caches have this block and memory may or may not be up to date(if no other cache has it in Sm state, memory will be up to date else it is not).&lt;br /&gt;
When a Shared Modified line is evicted from the cache on a cache miss only then is the block written back to the main memory in order to keep memory consistent. For more information on Dragon protocol, refer to Solihin textbook, page number 229. The state transition diagram has been given below for reference.&lt;br /&gt;
&lt;br /&gt;
[[Image:Dragon.jpg|frame|center|&amp;lt;b&amp;gt;Figure 9:&amp;lt;/b&amp;gt; Dragon Protocol State Diagram]]&lt;br /&gt;
&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' , was developed by Xerox Palo Alto Research Center ('''[http://en.wikipedia.org/wiki/Xerox_PARC Xerox PARC]'''), a subsidiary of Xerox Corporation.  This protocol was used in the '''[http://en.wikipedia.org/w/index.php?title=Xerox_Dragon&amp;amp;redirect=no Xerox PARC Dragon]''' multiprocessor workstation, a VLSI research computer that could support multiple processors on a central high bandwidth memory bus. The Dragon design implemented snoopy caches that provided the appearance of a uniform memory space to multiple processors. Here, each cache listens to 2 buses: the processor bus and the memory bus. The caches are also responsible for address translation, so the processor bus carries virtual addresses and the memory bus carries physical addresses.  The Dragon system was designed to support 4 to 8 Dragon processors. The memory bus used in the Xeron Dragon evolved to become the '''[http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=289691 XDBus]''' , a low-cost, synchronous, '''packet-switched VLSI bus''' designed for use in high-performance multiprocessors. This was used as the interconnect in many multiprocessor server systems like '''Cray Superserver 6400''', '''Sun Microsystems' SPARCcenter 2000''' and '''SPARCserver 1000'''  and '''Sun4d''' systems.&lt;br /&gt;
&lt;br /&gt;
=Cache Coherence Power Utilization=&lt;br /&gt;
A number of studies have been performed to reduce the power consumption of cache coherence protocols. In order to perform a solid comparison between the cache coherency protocols, one would need to develop a multi-core processor for each of the cache coherency protocols. Additionally, the hardware and software configuration would also need to be similar between each system (except for the hardware required to implement each of the different protocols). Unfortunately, there are no such processors available. This section will discuss power consumption in general terms, comparing to each of the protocols. Also, this section will briefly discussion some power optimization techniques.&lt;br /&gt;
&lt;br /&gt;
Bus transactions, in general, are costly for both performance and power consumption. Additionally, studies have been performed showing that unnecessary snooping can waste power. Power requirements are typically determined by the number of bus snoops and number of bus accesses by each processor. One study indicates that interchip bus communications can consume up to 20% of total chip power[[#References|&amp;lt;sup&amp;gt;[20]&amp;lt;/sup&amp;gt;]].&lt;br /&gt;
Using the examples from the class notes, we can analyze the relative power consumption between the protocols. The following table is a summary of various protocols showing the number of bus communications that occur for each processor action.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|'''Processor Action'''&lt;br /&gt;
|'''MSI Bus Actions'''&lt;br /&gt;
|'''MESI Bus Actions'''&lt;br /&gt;
|'''Dragon Bus Actions'''&lt;br /&gt;
|'''FireFly Bus Actions'''&lt;br /&gt;
|-&lt;br /&gt;
|R1&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|-&lt;br /&gt;
|W1&lt;br /&gt;
|BusRdX&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R3&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|-&lt;br /&gt;
|W3&lt;br /&gt;
|BusRdX&lt;br /&gt;
|BusRdX&lt;br /&gt;
|BusUpd/Upd&lt;br /&gt;
|BusUpd&lt;br /&gt;
|-&lt;br /&gt;
|R1&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R3&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R2&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 4:&amp;lt;/b&amp;gt; Summary of Bus Actions for Select Protocols&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
From the table above, we can see that MSI has a larger number of bus transactions than the Dragon protocol. Even though bus transactions are not power efficient, snooping can also be enhanced to improve power efficiency. The following section will discuss snoop filtering techniques.&lt;br /&gt;
&lt;br /&gt;
==Power Savings Using Snoop Filtering==&lt;br /&gt;
A number of studies have been performed to reduce the number of unnecessary snoops during cache transactions. Two such filtering techniques are serial snooping and Jetty. The following sections will briefly discuss these two filtering techniques and power savings achieved using these techniques. Studies show that as much as 90% of snoop broadcasts will result in a miss[[#References|&amp;lt;sup&amp;gt;[19]&amp;lt;/sup&amp;gt;]] in the other caches at the same level and require that the information be provided by the next level of cache or memory. As much as a 36% savings in power by filtering snoops using one of the following snoop filtering methods[[#References|&amp;lt;sup&amp;gt;[19]&amp;lt;/sup&amp;gt;]].&lt;br /&gt;
===Serial Snooping===&lt;br /&gt;
Serial snooping takes advantage of the fact that if a miss occurs in one cache, it is possible to find the block in one other cache without having to check all the caches. If the cache block is available in multiple caches, there is a high probability that the cache miss can find the data in a nearby cache. Alternatively, savings can be realized by searching a subset of the caches vice all the caches. One thing to note is that this is only effective for read misses. Write, an invalidation transaction needs to be transmitted to the other caches, thus a bus transaction is unavoidable.&lt;br /&gt;
===Jetty===&lt;br /&gt;
Jetty is a mechanism attached to each cache that verifies that a bus snoop is necessary. Jetty is used to filter L2 tag lookups. When a processor needs to perform a bus snoop, the Jetty is checked first. The Jetty can determine if a cache tag lookup is required. Since the Jetty is much smaller than the associated cache, less power is required to determine if a snoop is required.&lt;br /&gt;
&lt;br /&gt;
There are a couple of different Jetty schemes. There is the exclude-Jetty, include-Jetty, and hybrid-Jetty. The exclude-Jetty exploits the fact that if a cache block is snooped, it is highly likely the same cache block will be snooped in the near future. The exclude-Jetty keeps track of the tag lookups in a small table and can determine if a cache tag lookup is necessary.&lt;br /&gt;
&lt;br /&gt;
The include-Jetty keeps a superset of the blocks that are cached. If a miss occurs in the include-Jetty, then it can be guaranteed that the block is not stored in its associated cache.&lt;br /&gt;
&lt;br /&gt;
The hybrid-Jetty is simply a combinations of and include and exclude-Jetty. Both types of Jetty are present and when a lookup occurs, both Jettys are checked to determine if a cache lookup is necessary.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Cache_coherence Cache coherence]&lt;br /&gt;
# [http://www.intel.com/technology/quickpath/introduction.pdf Introduction to QuickPath Interconnect]&lt;br /&gt;
# [http://www.intel.com/technology/itj/2006/volume10issue02/art02_CMP_Implementation/p03_implementation.htm CMP Implementation in Intel Core Duo Processors]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Symmetric_multiprocessing Common System Interface in Intel Processors]&lt;br /&gt;
# [http://www.zak.ict.pwr.wroc.pl/nikodem/ak_materialy/Cache%20consistency%20&amp;amp;%20MESI.pdf Cache consistency with MESI on Intel processor]&lt;br /&gt;
# [http://techreport.com/articles.x/8236/2 AMD dual core Architecture]&lt;br /&gt;
# [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD64 Architecture Programmer's manual]&lt;br /&gt;
# [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf Software Optimization guide for AMD 10h Processors]&lt;br /&gt;
# [http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html Architecture of AMD 64 bit core]&lt;br /&gt;
# [http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=4913 Silicon Graphics Computer Systems]&lt;br /&gt;
# [http://books.google.com/books?id=g82fofiqa5IC&amp;amp;printsec=frontcover&amp;amp;dq=Parallel+computer+architecture:+a+hardware/software+approach+By+David+E.+Culler,+Jaswinder+Pal+Singh,+Anoop+Gupta&amp;amp;source=bl&amp;amp;ots=COrdamlfVn&amp;amp;sig=YcugVqbzTjHvlofvaFq6Ft_tjfY&amp;amp;hl=en&amp;amp;ei=0ZO6S4TJGcOclgejzI3BBw&amp;amp;sa=X&amp;amp;oi=book_result&amp;amp;ct=result&amp;amp;resnum=1&amp;amp;ved=0CAgQ6AEwAA#v=onepage&amp;amp;q=&amp;amp;f=false Parallel computer architecture: a hardware/software approach By David E. Culler, Jaswinder Pal Singh, Anoop Gupta]&lt;br /&gt;
# [http://www.freepatentsonline.com/5283886.html Three state invalidation protocols]&lt;br /&gt;
# [http://portal.acm.org/citation.cfm?id=1499317&amp;amp;dl=GUIDE&amp;amp;coll=GUIDE&amp;amp;CFID=83027384&amp;amp;CFTOKEN=95680533 Synapse tightly coupled multiprocessors: a new approach to solve old problems]&lt;br /&gt;
# [http://portal.acm.org/citation.cfm?id=6514Cache Coherence protocols: evaluation using a multiprocessor simulation model]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Xerox_Dragon Xerox Dragon]&lt;br /&gt;
# [http://thanaseto.110mb.com/courses/CSD-527-report-engl.pdf Coherence Protocols]&lt;br /&gt;
# [http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=289691 XDBus]&lt;br /&gt;
# [http://www.ece.wisc.edu/~wddd/2002/final/ekman.pdf Evaluation of Snoop-Energy Reduction Techniques for Chip-Multiprocessors]&lt;br /&gt;
# [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.79.7463&amp;amp;rep=rep1&amp;amp;type=pdf Power Efficient Cache Coherence]&lt;/div&gt;</summary>
		<author><name>Mqtran</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2011/ch8_mc&amp;diff=44461</id>
		<title>CSC/ECE 506 Spring 2011/ch8 mc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2011/ch8_mc&amp;diff=44461"/>
		<updated>2011-03-19T23:45:44Z</updated>

		<summary type="html">&lt;p&gt;Mqtran: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Introduction to bus-based cache coherence in real machines=&lt;br /&gt;
&lt;br /&gt;
Most parallel software in the commercial market relies on the shared-memory&lt;br /&gt;
programming model in which all processors access the same physical address space. The most common multiprocessors today use [http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP] architecture which use a common bus as the interconnect.  In the case of multicore processors (&amp;quot;chip multiprocessors,&amp;quot; or CMP) the [http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP] architecture applies to the cores treating them as separate processors. The key problem of shared-memory multiprocessors is providing a consistent view of memory with various cache hierarchies.  This is called '''''cache coherence problem'''''. It is  critical to  achieve correctness and performance-sensitive design point for supporting the shared-memory model. The cache coherence mechanisms not only govern communication in a shared-memory multiprocessor, but also typically determine how the memory system transfers data between processors, caches, and memory.&lt;br /&gt;
&lt;br /&gt;
[[Image:Busbased SMP.jpg|frame|center|&amp;lt;b&amp;gt;Figure 1:&amp;lt;/b&amp;gt; Typical Bus-Based Processor Model]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Cache Coherence in real machines=&lt;br /&gt;
==Summary of Cache Coherence Protocols==&lt;br /&gt;
At any point in logical time, the permissions for a cache block can allow either a single writer or multiple readers. The '''''coherence protocol''''' ensures the invariants of the states are maintained. The different coherent states used by most of the cache coherent protocols are shown in ''Table 1'':&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''States'''&lt;br /&gt;
|  '''Access Type'''&lt;br /&gt;
|  '''Invariant'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  read, write&lt;br /&gt;
|  all other caches in I state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  read&lt;br /&gt;
|  all other caches in I state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Owned'''&lt;br /&gt;
|  read&lt;br /&gt;
|  all other caches in I or S state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  read&lt;br /&gt;
|  no other cache in M or E state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|  -&lt;br /&gt;
|  -&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 1:&amp;lt;/b&amp;gt; States Used by the Cache Coherent Protocols&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
The first widely adopted approach to cache coherence is snooping on a bus. We will now discuss them in details in the following sections.&lt;br /&gt;
&lt;br /&gt;
===MSI===&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI protocol]''' is a three-state write-back '''invalidation protocol''' which is one of the earliest snooping-based cache coherence-protocols. It marks the cache line with one of the '''Modified (M) ,Shared (S)''', and '''Invalid (I)''' state. '''Invalid''' means the cache line is either not present or is in invalid state. If the cache line is clean and is shared by more than one processor , it is marked as '''Shared'''. If a cache line is dirty and the processor has exclusive ownership of it, it is in '''Modified''' state. BusRdx causes other processors to invalidate (demote) its cache block to the '''I''' state. If it is present in the '''M''' state in another cache, it will flush. &lt;br /&gt;
&lt;br /&gt;
The following state transition diagram for MSI protocol explains the working of the protocol:&lt;br /&gt;
&lt;br /&gt;
[[Image:MSI.jpg|frame|center|&amp;lt;b&amp;gt;Figure 2:&amp;lt;/b&amp;gt; MSI State Diagram]]&lt;br /&gt;
&lt;br /&gt;
===MESI===&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI protocol]''' has a major drawback in that each read-write sequence incurs two bus transactions irrespective of whether the cache line is stored in only one cache or not. This is a huge setback for highly parallel programs that have little data sharing. '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol solves this problem by introducing the E ('''Exclusive''') state to distinguish between a cache line stored in multiple caches and a line stored in a single cache.&lt;br /&gt;
Let us briefly look at how the MESI protocol works. (For a more detailed version readers are referred to Solihin textbook pg. 215)&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' coherence protocol marks each cache line in one of the Modified, Exclusive, Shared or Invalid state. &lt;br /&gt;
* '''Invalid''' : The cache line is either not present or is invalid&lt;br /&gt;
* '''Exclusive''' : The cache line is clean and is owned by this core/processor only&lt;br /&gt;
* '''Modified''' :  This implies that the cache line is dirty and the core/processor has  exclusive ownership of the cache line, exclusive of the memory also.&lt;br /&gt;
* '''Shared''' : The cache line is clean and is shared by more than one core/processor&lt;br /&gt;
&lt;br /&gt;
In a nutshell, the '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol works as the following: &lt;br /&gt;
A line that is just fetched receives '''E''' or '''S''' state depending on whether it exists in other processors in the system or not. Similarly, a cache line gets the '''M''' state when a processor writes to it. If the line is not in '''E''' or '''M''' state prior to being written to, the cache sends a Bus Upgrade (BusUpgr) signal or as the Intel manuals call it, a “Read-For-Ownership (RFO) request” that ensures that the line exists in the cache and is in the '''I''' state in all other processors on the bus (if any). The table shown below will summarize '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''Cache Line State:'''&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''This cache line is valid?'''&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  No&lt;br /&gt;
|-&lt;br /&gt;
|  '''The memory copy is…'''&lt;br /&gt;
|  out of date&lt;br /&gt;
|  valid&lt;br /&gt;
|  valid&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''Copies exist in caches of other processors?'''  &lt;br /&gt;
|  No&lt;br /&gt;
|  No&lt;br /&gt;
|  Maybe&lt;br /&gt;
|  Maybe&lt;br /&gt;
|-&lt;br /&gt;
|  '''A write to this line'''&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  goes to bus and updates cache&lt;br /&gt;
|  goes directly to bus&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 2:&amp;lt;/b&amp;gt; MESI Protocol Summary&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The transition diagram from the lecture slides is given below for reference.&lt;br /&gt;
&lt;br /&gt;
[[Image:MESI.jpg|frame|center|&amp;lt;b&amp;gt;Figure 4:&amp;lt;/b&amp;gt; MESI State Diagram]]&lt;br /&gt;
&lt;br /&gt;
===MESIF===&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/MESIF_protocol MESIF]''' protocol, used in the latest Intel multi-core processors Core i7, was introduced to '''accommodate the point-to-point''' links used in the QuickPath Interconnect. Using the '''MESI''' protocol in this architecture would send many redundant messages between different processors, often with unnecessarily high latency. For example, when a processor requests a cache line that is stored in multiple locations, every location might respond with the data. As the requesting processor only needs a single copy of the data, the system would be '''wasting the bandwidth'''. &lt;br /&gt;
As a '''solution''' to this problem, an additional state, '''Forward state''', was added by slightly changing the role of the Shared state. Whenever there is a read request, only the cache line in the F state will respond to the request, while all the S state caches remain dormant.  Hence, by designating a single cache line to '''respond to requests''', coherency traffic is substantially reduced when multiple copies of the data exist. Also, on a read request, the F state transitions to the S state. That is, when a cache line in the '''F''' state is '''copied''', the F state '''migrates''' to the '''newer copy''', while the '''older''' one drops back to the '''S''' state. Moving the new copy to the F state '''exploits''' both '''temporal and spatial locality'''. Because the newest copy of the cache line is always in the F state, it is very unlikely that the line in the F state will be evicted from the caches. This takes advantage of the temporal locality of the request. The second advantage is that if a particular cache line is in high demand due to spatial locality, the bandwidth used to transmit that data will be spread across several cores.&lt;br /&gt;
All M to S state transitions and E to S state transitions will now be from '''M to F''' and '''E to F'''.  &lt;br /&gt;
The '''F state''' is '''different''' from the '''Owned state''' of the MOESI protocol as it is '''not''' a '''unique''' copy because a valid copy is stored in memory. Thus, unlike the Owned state of the MOESI protocol, in which the data in the O state is the only valid copy of the data, the data in the F state can be evicted or converted to the S state, if desired. &lt;br /&gt;
&lt;br /&gt;
More information on the QuickPath Interconnect and MESIF protocol can be found at&lt;br /&gt;
'''[http://www.intel.com/technology/quickpath/introduction.pdf Introduction to QuickPath Interconnect]'''. &lt;br /&gt;
&lt;br /&gt;
===MOESI===&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/Opteron AMD Opteron] was AMD’s first-generation dual core processor which had two distinct [http://en.wikipedia.org/wiki/Athlon_64 K8 cores] together on a single die. Cache coherence produces bigger problems on such multicore processors. It was necessary to use an appropriate coherence protocol to address this problem. The [http://en.wikipedia.org/wiki/Xeon Intel Xeon], which was the competitive counterpart from Intel to AMD dual core Opteron, used the [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol to handle cache coherence. [http://en.wikipedia.org/wiki/MESI_protocol MESI] came with the drawback of using much time and bandwidth in certain situations. &lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/MOESI_protocol MOESI] was AMD’s answer to this problem. [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] added a fifth state to [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol called the '''owned''' state. [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol addresses the bandwidth problem faced by MESI protocol when processor having invalid data in its cache wants to modify the data.  The processor seeking the data will have to wait for the processor which modified this data to write back to the main memory, which takes time and bandwidth. This drawback is removed in MOESI by allowing dirty sharing.  When the data is held by a processor in the new state '''owned''', it can provide other processors the modified data without writing it to the main memory. This is called '''''dirty sharing'''''. The processor with the data in the '''owned''' state stays responsible to update the main memory later when the cache line is evicted.&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/MOESI_protocol MOESI]  has become one of the most popular snoop-based protocols supported in AMD64 architecture.  AMD dual-core Opteron can maintain cache coherence in systems up to 8 processors using this protocol.&lt;br /&gt;
&lt;br /&gt;
The five different states of [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol are:&lt;br /&gt;
* '''Modified (M)''': The most recent copy of the data is present in the cache line. But it is not present in any other processor cache.&lt;br /&gt;
* '''Owned (O)''': The cache line has the most recent correct copy of the data. This can be shared by other processors. The processor in this state for this cache line is responsible to update the correct value in the main memory before it gets evicted.&lt;br /&gt;
* '''Exclusive (E)''': A cache line holds the most recent, correct copy of the data, which is exclusively present on this processor and a copy is present in the main memory.&lt;br /&gt;
* '''Shared (S)''': A cache line in the shared state holds the most recent, correct copy of the data, which may be shared by other processors.&lt;br /&gt;
* '''Invalid (I)''': A cache line does not hold a valid copy of the data.&lt;br /&gt;
&lt;br /&gt;
A detailed explanation of this protocol implementation on AMD processor can be found in the manual [http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html Architecture of AMD 64-bit core]&lt;br /&gt;
&lt;br /&gt;
The following table summarizes the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''Cache Line State:'''&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  '''Owner''' &lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''This cache line is valid?'''&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  No&lt;br /&gt;
|-&lt;br /&gt;
|  '''The memory copy is…'''&lt;br /&gt;
|  out of date&lt;br /&gt;
|  out of date&lt;br /&gt;
|  valid&lt;br /&gt;
|  valid&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''Copies exist in caches of other processors?'''&lt;br /&gt;
|  No&lt;br /&gt;
|  No&lt;br /&gt;
|  Yes(out of date values)|  Maybe&lt;br /&gt;
|  Maybe&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''A write to this line'''&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  does not go to bus|  does not go to bus&lt;br /&gt;
|  goes to bus and updates cache&lt;br /&gt;
|  goes directly to bus&lt;br /&gt;
|  -&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 3:&amp;lt;/b&amp;gt; MOESI Protocol Summary&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
State transition for [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]is as shown below : &lt;br /&gt;
&lt;br /&gt;
[[Image:MOESI_State_Transition_Diagram.jpg|frame|center|&amp;lt;b&amp;gt;Figure 7:&amp;lt;/b&amp;gt; [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]State transition Diagram]]&lt;br /&gt;
&lt;br /&gt;
We will now discuss how processor vendors like '''Intel''', '''AMD''' and others maintain cache coherence using '''''snooping based coherence protocols'''''.  For more information on snooping based protocols, readers are referred to Solihin textbook Chapter 8.&lt;br /&gt;
&lt;br /&gt;
==SGI - Silicon Graphics, Inc==&lt;br /&gt;
===MSI &amp;amp; SGI IRIS 4D Processors===&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' protocol was first used in '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''' IRIS 4D series. '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''' produced a broad range of '''[http://en.wikipedia.org/wiki/MIPS_architecture MIPS]'''-based (Microprocessor without Interlocked Pipeline Stages) workstations and servers during the 1990s, running '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''''s version of UNIX System V, now called '''[http://en.wikipedia.org/wiki/IRIX IRIX]'''. The 4D-MP graphics superworkstation brought 40 MIPS(million instructions per second) of computing performance to a graphics superworkstation. The unprecedented level of computing and graphics processing in an office-environment workstation was made possible by the fastest available Risc microprocessors in a single shared memory multiprocessor design driving a tightly coupled, highly parallel graphics system. Aggregate sustained data rates of over one gigabyte per second were achieved by a hierarchy of buses in a balanced system designed to avoid bottlenecks.&lt;br /&gt;
&lt;br /&gt;
The multiprocessor bus used in 4D-MP graphics superworkstation is a pipelined, block transfer bus that supports the cache coherence protocol as well as providing 64 megabytes of sustained data bandwidth between the processors, the memory and I/O system, and the graphics subsystem. Because the sync bus provides for efficient synchronization between processors, the cache coherence protocol was designed to support efficient data sharing between processors. If a cache coherence protocol has to support synchronization as well as sharing, a compromise in the efficiency of the data sharing protocol may be necessary to improve the efficiency of the synchronization operations. Hence it uses the simple cache coherence protocol which is the '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' protocol.&lt;br /&gt;
&lt;br /&gt;
With the simple rules of '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' enforced by the hardware protocols of&lt;br /&gt;
the sync bus and the Multiprocessor bus, efficient synchronization and efficient data sharing are achieved in a simple shared memory model of parallel processing in the 4D-MP graphics superworkstation.&lt;br /&gt;
&lt;br /&gt;
==SYNAPSE Multiprocessor==&lt;br /&gt;
===Synapse protocol and Synapse multiprocessor===&lt;br /&gt;
From the state transition diagram of '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''', we observe that for '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' there is transition to the '''S''' state from the '''M''' state when a BusRd is observed for that block. The contents of the block is flushed to the bus before going to '''S''' state. It would look more appropriate to move to the '''I''' state thus giving up the block entirely in certain cases. This choice of moving to '''S''' or '''I''' reflects the designer's assertion that the original processor is more likely to continue reading the block than the new processor to write to the block. In synapse protocol, used in the early Synapse multiprocessor, made this alternate choice of going directly from the '''M''' state to the '''I''' state on a BusRd, assuming the migratory pattern would be more frequent. More details about this protocol can be found in these papers published in late 1980's [http://portal.acm.org/citation.cfm?id=6514Cache Coherence protocols: evaluation using a multiprocessor simulation model] and [http://portal.acm.org/citation.cfm?id=1499317&amp;amp;dl=GUIDE&amp;amp;coll=GUIDE&amp;amp;CFID=83027384&amp;amp;CFTOKEN=95680533 Synapse tightly coupled multiprocessors: a new approach to solve old problems]&lt;br /&gt;
&lt;br /&gt;
In the Synapse protocol, the '''M''' state is called the '''D''' (Dirty) state. The following is the state transition diagram for Synapse protocol which clearly shows its working.&lt;br /&gt;
&lt;br /&gt;
[[Image:Synapse1.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; Synapse State Diagram]]&lt;br /&gt;
&lt;br /&gt;
==Intel==&lt;br /&gt;
===MESI &amp;amp; Intel Processors===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The '''Pentium Pro''' microprocessor, introduced in 1992 was the '''first''' Intel architecture microprocessor to support symmetric multiprocessing ('''[http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP]''') in various multiprocessor configurations. '''[http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP]''' and '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol was the architecture used consistently until the introduction of the 45-nm Hi-k Core micro-architecture in '''Intel's (Nehalem-EP) quad-core x86-64'''. The 45-nm Hi-k Intel Core microarchitecture utilizes a new system of framework called the '''QuickPath Interconnect''' which uses point-to-point interconnection technology based on distributed shared memory architecture. It uses a modified version of '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol called '''MESIF''', by introducing an additional state, F, the forward state. &lt;br /&gt;
&lt;br /&gt;
The '''Intel architecture''' uses the '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol  as the '''basis''' to ensure cache coherence, which is true whether you're on one of the older processors that use a '''common bus''' to communicate or using the new Intel '''QuickPath''' point-to-point interconnection technology. &lt;br /&gt;
&lt;br /&gt;
Let us now walk through a briefing on the '''MESIF protocol''':&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== CMP Implementation in Intel Architecture ===&lt;br /&gt;
&lt;br /&gt;
Let us now see how Intel architecture using the [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol progressed from a uniprocessor architecture to a Chip MultiProcessor (CMP) using the bus as the interconnect. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Uniprocessor Architecture'''&lt;br /&gt;
&lt;br /&gt;
The diagram below shows the structure of the memory cluster in Intel Pentium M processor.&lt;br /&gt;
&lt;br /&gt;
[[Image:intel_cache1.jpg|frame|center|&amp;lt;b&amp;gt;Figure 5:&amp;lt;/b&amp;gt; Memory Structure of the Pentium M Processor]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In this structure we have,&lt;br /&gt;
* A unified on-chip '''L1 cache''' with the '''processor/core''',&lt;br /&gt;
* A '''Memory/L2 access control unit''', through which all the accesses to the L2 cache, main memory and IO space are made,&lt;br /&gt;
* The second level '''L2 cache''' along with the '''prefetch unit''' and&lt;br /&gt;
* '''Front side bus (FSB)''', a single shared bi-directional bus through which all the traffic is sent across.These wide buses bring in multiple data bytes at a time. &lt;br /&gt;
&lt;br /&gt;
As Intel explains it, using this structure, the processor requests were first sought in the '''L2 cache''' and only on a '''miss''', were they '''forwarded''' to the main '''memory''' via the front side bus ('''FSB'''). The '''Memory/L2 access control''' unit served as a central point for '''maintaining coherence''' within the core and with the external world. It '''contains''' a '''snoop control unit''' that receives snoop requests from the bus and performs the required operations on each cache (and internal buffers) in parallel. It also handles RFO requests (BusUpgr) and ensures the operation continues only after it guarantees that no other version on the cache line exists in any other cache in the system.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''CMP Architecture'''&lt;br /&gt;
&lt;br /&gt;
For CMP implementation, Intel chose the bus-based architecture using snoopy protocols vs the '''directory protocol''' because though directory protocol reduces the active power due to reduced snoop activity, it '''increased''' the '''design complexity''' and the '''static power''' due to larger tag arrays. Since Intel has a large market for the processors in the mobility family, directory-based solution was less favorable since battery life mainly depends on static power consumption and less on dynamic power.&lt;br /&gt;
Let us examine how '''CMP''' was implemented in '''Intel Core Duo''', which was one of the first dual-core processor for the budget/entry-level market. &lt;br /&gt;
The general CMP implementation structure of the Intel Core Duo is shown below&lt;br /&gt;
&lt;br /&gt;
[[Image:intel_cache2.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; Intel Core Duo CMP Implementation]]&lt;br /&gt;
&lt;br /&gt;
This structure has the following changes when compared to the uniprocessor memory cluster structure. &lt;br /&gt;
* '''L1 cache''' and the '''processor/core''' structure is '''duplicated''' to give 2 cores.&lt;br /&gt;
* The '''Memory/L2 access control''' unit is '''split''' into 2 logical units: '''L2 controller''' and '''bus controller'''. The L2 controller handles all '''requests to the L2''' cache from the core and the snoop requests from the FSB. The '''bus controller''' handles '''data and I/O requests''' to and from the FSB.&lt;br /&gt;
* The '''prefetching''' unit is extended to handle the hardware '''prefetches for each core separately'''.&lt;br /&gt;
* A '''new logical unit''' (represented by the hexagon) was added to maintain '''fairness between the requests''' coming from the different cores and hence balance the requests to L2 and memory.&lt;br /&gt;
&lt;br /&gt;
This new '''partitioned structure''' for the  memory/L2 access control unit '''enhanced''' the '''performance''' while '''reducing power consumption'''. &lt;br /&gt;
For more information on uniprocessor and multiprocessor implementation under the Intel architecture, refer to &lt;br /&gt;
[http://www.intel.com/technology/itj/2006/volume10issue02/art02_CMP_Implementation/p03_implementation.htm CMP Implementation in Intel Core Duo Processors]&lt;br /&gt;
&lt;br /&gt;
The '''Intel bus architecture''' has been '''evolving''' in order to accommodate the demands of scalability while using the '''same [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol'''; From using a '''single shared bus''' to '''dual independent buses (DIB)''' doubling the available bandwidth and to the logical conclusion of DIB with the introduction of '''dedicated high-speed interconnects (DHSI)'''. The DHSI-based platforms use four FSBs, one for each processor in the platform. In both DIB and DHSI, the snoop filter was used in the chipset to cache snoop information, thereby significantly reducing the broadcasting needed for the snoop traffic on the buses. With the production of processors based on next generation 45-nm Hi-k Intel Core microarchitecture, the [http://en.wikipedia.org/wiki/Xeon Intel Xeon] processor fabric will transition from a DHSI, with the memory controller in the chipset, to a distributed shared memory architecture using '''Intel QuickPath Interconnects using MESIF protocol'''.&lt;br /&gt;
&lt;br /&gt;
==AMD - Advanced Micro Devices Processors==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===MOESI &amp;amp; AMD Processors===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===AMD Opteron memory Architecture===&lt;br /&gt;
&lt;br /&gt;
[[Image:Untitled.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; AMD Opteron memory Architecture]]&lt;br /&gt;
&lt;br /&gt;
The AMD processor’s high-performance cache architecture includes an integrated, 64-bit, dual-ported  128-Kbyte split-L1 cache with separate snoop port, multi-level translation lookaside buffers (TLBs), a scalable L2 cache controller with a 72-bit (64-bit data + 8-bit ECC) interface to as much as 8-Mbyte of industry-standard SDR or DDR SRAMs, and an integrated tag for the most cost-effective 512-Kbyte L2 configurations. The AMD Athlon processor’s integrated L1 cache comprises two separate 64-Kbyte, two-way set-associative data and instruction caches.&lt;br /&gt;
&lt;br /&gt;
More information about this can be found in [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD 64 bit Architecture Programmers's Manual]&lt;br /&gt;
&lt;br /&gt;
===Special Coherence Considerations in AMD64 architectures===&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
Instruction prefetching is a technique used to speedup the execution of the program. But in multiprocessors, prefetching comes at the cost of performance. Due to prefetching, the data can be modified in such a way that the memory coherence protocol will not be able to handle the effects. In such situations software must use serializing instructions or cache-invalidation instructions to guarantee subsequent data accesses are coherent. &lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
An example of this type of a situation is a page-table update followed by accesses to the physical pages referenced by the updated page tables. The physical-memory references for the page tables are different than the physical-memory references for the data. Because of prefetching, there maybe problem with correctness. The following sequence of events shows such a situation when software changes the translation of virtual-page A from physical-page M to physical-page N:&lt;br /&gt;
# The tables that translate virtual-page A to physical-page M are now held only in main memory. The copies in the cache ae invalidated.&lt;br /&gt;
# Page-table entry is changed by the software for virtual-page A in main memory to point to physical page N rather than physical-page M.&lt;br /&gt;
# Data in virtual-page A is accessed.&lt;br /&gt;
&lt;br /&gt;
Software expects the processor to access the data from physical-page N after the update. However, it is possible for the processor to prefetch the data from physical-page M before the page table for virtual page A is updated. Because the physical-memory references are different, the processor does not recognize them as requiring coherence checking and believes it is safe to prefetch the data from virtual-page A, which is translated into a read from physical page M. Similar behavior can occur when instructions are prefetched from beyond the page table update instruction.&lt;br /&gt;
&lt;br /&gt;
In order to prevent errors from occuring, there are special instructions provided by software like INVLPG or MOV CR3 instruction which is executed immediately after the page-table update to ensure that subsequent instruction fetches and data accesses use the correct virtual-page-to-physical-page translation. It is not necessary to perform a TLB invalidation operation preceding the table update.&lt;br /&gt;
&lt;br /&gt;
More information can be found about this in [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD64 Architecture Programmer's manual]&lt;br /&gt;
&lt;br /&gt;
===Optimization techniques on MOESI when implemented on AMD Phenom processors===&lt;br /&gt;
&lt;br /&gt;
In real machines, using some optimization techniques on the standard cache coherence protocol used, improves the performance of the machine. For example, [http://en.wikipedia.org/wiki/AMD_Phenom AMD Phenom] family of microprocessors (Family 0×10) which is AMD’s first generation to incorporate 4 distinct cores on a single die. It is the first to have a cache that all the cores share, using the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol with some optimization techniques incorporated. &lt;br /&gt;
&lt;br /&gt;
It focuses on a small subset of compute problems which behave like Producer and Consumer programs. In such a computing problem, a thread of a program running on a single core produces data, which is consumed by a thread that is running on a separate core. With such programs, it is desirable to get the two distinct cores to communicate through the shared cache, to avoid round trips to/from main memory. The '''MOESI''' protocol that the [http://en.wikipedia.org/wiki/AMD_Phenom AMD Phenom] cache uses for cache coherence can also limit bandwidth. Hence by keeping the cache line in the '''M''' state for such computing problems, we can achieve better performance.&lt;br /&gt;
&lt;br /&gt;
When the producer thread , writes a new entry, it allocates cache-lines in the '''M''' state. Eventually, these M-marked cache lines will start to fill the L3 cache. When the consumer reads the cache line, the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol changes the state of the cache line to the '''O''' state in the L3 cache and pulls down a '''shared (S)''' copy for its own use. Now, the producer thread circles the ring buffer to arrive back to the same cache line it had previously written. However, when the producer attempts to write new data to the owned (marked '''‘O’''') cache line, it finds that it cannot, since a cache line in the '''O''' state by the previous consumer read does not have sufficient permission for a write request (in the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]). To maintain coherence, the memory controller must initiate probes in the other caches (to handle any other S copies that may exist). This will slow down the process.&lt;br /&gt;
&lt;br /&gt;
Thus, it is preferable to keep the cache line in the '''M''' state in the L3 cache. In such a situation, when the producer comes back around the ring buffer, it finds the previously written cache line still in the'''M''' state, to which it is safe to write without coherence concerns. Thus better performance can be achieved by such optimization techniques to standard protocols when implemented in real machines.&lt;br /&gt;
&lt;br /&gt;
You can find more information on how this is implemented and various other ways of optimizations in this manual [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf Software Optimization guide for AMD 10h Processors].&lt;br /&gt;
&lt;br /&gt;
==Xerox Corporation==&lt;br /&gt;
===Dragon Protocol &amp;amp; Xerox Dragon Processors===&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' is an update based coherence protocol which does not invalidate other cached copies like what we have seen in the coherence protocols so far. Write propagation is achieved by updating the cached copies instead of invalidating them.  But the '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' does not update memory on a cache to cache transfer and delays the memory and cache consistency until the data is evicted and written back, which saves time and lowers the memory access requirements. Moreover only the written '''byte''' or the '''word''' is '''communicated''' to the '''other caches''' instead of the whole block which further '''reduces''' the '''bandwidth''' usage. It has the ability to detect dynamically, the sharing status of a block and use a write through policy for shared blocks and write back for currently non-shared blocks. The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' employs the following four states for the cache blocks: '''Shared Clean''', '''Shared Modified''', '''Exclusive''', and  '''Modified'''. &lt;br /&gt;
* '''Modified (M)''' and '''Exclusive (E)''' - these states have the same meaning as explained in the protocols above. &lt;br /&gt;
* '''Shared Modified (Sm)''' - Only one cache line in the system can be in the Shared Modified state. Potentially two or more caches    have this block and memory may or may not be up to date and this processor's cache had modified the block.&lt;br /&gt;
* '''Shared Clean (Sc)''' -  Potentially two or more caches have this block and memory may or may not be up to date(if no other cache has it in Sm state, memory will be up to date else it is not).&lt;br /&gt;
When a Shared Modified line is evicted from the cache on a cache miss only then is the block written back to the main memory in order to keep memory consistent. For more information on Dragon protocol, refer to Solihin textbook, page number 229. The state transition diagram has been given below for reference.&lt;br /&gt;
&lt;br /&gt;
[[Image:Dragon.jpg|frame|center|&amp;lt;b&amp;gt;Figure 9:&amp;lt;/b&amp;gt; Dragon Protocol State Diagram]]&lt;br /&gt;
&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' , was developed by Xerox Palo Alto Research Center ('''[http://en.wikipedia.org/wiki/Xerox_PARC Xerox PARC]'''), a subsidiary of Xerox Corporation.  This protocol was used in the '''[http://en.wikipedia.org/w/index.php?title=Xerox_Dragon&amp;amp;redirect=no Xerox PARC Dragon]''' multiprocessor workstation, a VLSI research computer that could support multiple processors on a central high bandwidth memory bus. The Dragon design implemented snoopy caches that provided the appearance of a uniform memory space to multiple processors. Here, each cache listens to 2 buses: the processor bus and the memory bus. The caches are also responsible for address translation, so the processor bus carries virtual addresses and the memory bus carries physical addresses.  The Dragon system was designed to support 4 to 8 Dragon processors. The memory bus used in the Xeron Dragon evolved to become the '''[http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=289691 XDBus]''' , a low-cost, synchronous, '''packet-switched VLSI bus''' designed for use in high-performance multiprocessors. This was used as the interconnect in many multiprocessor server systems like '''Cray Superserver 6400''', '''Sun Microsystems' SPARCcenter 2000''' and '''SPARCserver 1000'''  and '''Sun4d''' systems.&lt;br /&gt;
&lt;br /&gt;
=Cache Coherence Power Utilization=&lt;br /&gt;
A number of studies have been performed to reduce the power consumption of cache coherence protocols. In order to perform a solid comparison between the cache coherency protocols, one would need to develop a multi-core processor for each of the cache coherency protocols. Additionally, the hardware and software configuration would also need to be similar between each system (except for the hardware required to implement each of the different protocols). Unfortunately, there are no such processors available. This section will discuss power consumption in general terms, comparing to each of the protocols. Also, this section will briefly discussion some power optimization techniques.&lt;br /&gt;
&lt;br /&gt;
Bus transactions, in general, are costly for both performance and power consumption. Additionally, studies have been performed showing that unnecessary snooping can waste power. Power requirements are typically determined by the number of bus snoops and number of bus accesses by each processor. One study indicates that interchip bus communications can consume up to 20% of total chip power[[#References|&amp;lt;sup&amp;gt;[20]&amp;lt;/sup&amp;gt;]].&lt;br /&gt;
Using the examples from the class notes, we can analyze the relative power consumption between the protocols. The following table is a summary of various protocols showing the number of bus communications that occur for each processor action.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|'''Processor Action'''&lt;br /&gt;
|'''MSI Bus Actions'''&lt;br /&gt;
|'''MESI Bus Actions'''&lt;br /&gt;
|'''Dragon Bus Actions'''&lt;br /&gt;
|'''FireFly Bus Actions'''&lt;br /&gt;
|-&lt;br /&gt;
|R1&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|-&lt;br /&gt;
|W1&lt;br /&gt;
|BusRdX&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R3&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|-&lt;br /&gt;
|W3&lt;br /&gt;
|BusRdX&lt;br /&gt;
|BusRdX&lt;br /&gt;
|BusUpd/Upd&lt;br /&gt;
|BusUpd&lt;br /&gt;
|-&lt;br /&gt;
|R1&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R3&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R2&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 4:&amp;lt;/b&amp;gt; Summary of Bus Actions for Select Protocols&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
From the table above, we can see that MSI has a larger number of bus transactions than the Dragon protocol. Even though bus transactions are not power efficient, snooping can also be enhanced to improve power efficiency. The following section will discuss snoop filtering techniques.&lt;br /&gt;
&lt;br /&gt;
==Power Savings Using Snoop Filtering==&lt;br /&gt;
A number of studies have been performed to reduce the number of unnecessary snoops during cache transactions. Two such filtering techniques are serial snooping and Jetty. The following sections will briefly discuss these two filtering techniques and power savings achieved using these techniques. Studies show that as much as 90% of snoop broadcasts will result in a miss[[#References|&amp;lt;sup&amp;gt;[19]&amp;lt;/sup&amp;gt;]] in the other caches at the same level and require that the information be provided by the next level of cache or memory. As much as a 36% savings in power by filtering snoops using one of the following snoop filtering methods[[#References|&amp;lt;sup&amp;gt;[19]&amp;lt;/sup&amp;gt;]].&lt;br /&gt;
===Serial Snooping===&lt;br /&gt;
Serial snooping takes advantage of the fact that if a miss occurs in one cache, it is possible to find the block in one other cache without having to check all the caches. If the cache block is available in multiple caches, there is a high probability that the cache miss can find the data in a nearby cache. Alternatively, savings can be realized by searching a subset of the caches vice all the caches. One thing to note is that this is only effective for read misses. Write, an invalidation transaction needs to be transmitted to the other caches, thus a bus transaction is unavoidable.&lt;br /&gt;
===Jetty===&lt;br /&gt;
Jetty is a mechanism attached to each cache that verifies that a bus snoop is necessary. Jetty is used to filter L2 tag lookups. When a processor needs to perform a bus snoop, the Jetty is checked first. The Jetty can determine if a cache tag lookup is required. Since the Jetty is much smaller than the associated cache, less power is required to determine if a snoop is required.&lt;br /&gt;
&lt;br /&gt;
There are a couple of different Jetty schemes. There is the exclude-Jetty, include-Jetty, and hybrid-Jetty. The exclude-Jetty exploits the fact that if a cache block is snooped, it is highly likely the same cache block will be snooped in the near future. The exclude-Jetty keeps track of the tag lookups in a small table and can determine if a cache tag lookup is necessary.&lt;br /&gt;
&lt;br /&gt;
The include-Jetty keeps a superset of the blocks that are cached. If a miss occurs in the include-Jetty, then it can be guaranteed that the block is not stored in its associated cache.&lt;br /&gt;
&lt;br /&gt;
The hybrid-Jetty is simply a combinations of and include and exclude-Jetty. Both types of Jetty are present and when a lookup occurs, both Jettys are checked to determine if a cache lookup is necessary.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Cache_coherence Cache coherence]&lt;br /&gt;
# [http://www.intel.com/technology/quickpath/introduction.pdf Introduction to QuickPath Interconnect]&lt;br /&gt;
# [http://www.intel.com/technology/itj/2006/volume10issue02/art02_CMP_Implementation/p03_implementation.htm CMP Implementation in Intel Core Duo Processors]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Symmetric_multiprocessing Common System Interface in Intel Processors]&lt;br /&gt;
# [http://www.zak.ict.pwr.wroc.pl/nikodem/ak_materialy/Cache%20consistency%20&amp;amp;%20MESI.pdf Cache consistency with MESI on Intel processor]&lt;br /&gt;
# [http://techreport.com/articles.x/8236/2 AMD dual core Architecture]&lt;br /&gt;
# [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD64 Architecture Programmer's manual]&lt;br /&gt;
# [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf Software Optimization guide for AMD 10h Processors]&lt;br /&gt;
# [http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html Architecture of AMD 64 bit core]&lt;br /&gt;
# [http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=4913 Silicon Graphics Computer Systems]&lt;br /&gt;
# [http://books.google.com/books?id=g82fofiqa5IC&amp;amp;printsec=frontcover&amp;amp;dq=Parallel+computer+architecture:+a+hardware/software+approach+By+David+E.+Culler,+Jaswinder+Pal+Singh,+Anoop+Gupta&amp;amp;source=bl&amp;amp;ots=COrdamlfVn&amp;amp;sig=YcugVqbzTjHvlofvaFq6Ft_tjfY&amp;amp;hl=en&amp;amp;ei=0ZO6S4TJGcOclgejzI3BBw&amp;amp;sa=X&amp;amp;oi=book_result&amp;amp;ct=result&amp;amp;resnum=1&amp;amp;ved=0CAgQ6AEwAA#v=onepage&amp;amp;q=&amp;amp;f=false Parallel computer architecture: a hardware/software approach By David E. Culler, Jaswinder Pal Singh, Anoop Gupta]&lt;br /&gt;
# [http://www.freepatentsonline.com/5283886.html Three state invalidation protocols]&lt;br /&gt;
# [http://portal.acm.org/citation.cfm?id=1499317&amp;amp;dl=GUIDE&amp;amp;coll=GUIDE&amp;amp;CFID=83027384&amp;amp;CFTOKEN=95680533 Synapse tightly coupled multiprocessors: a new approach to solve old problems]&lt;br /&gt;
# [http://portal.acm.org/citation.cfm?id=6514Cache Coherence protocols: evaluation using a multiprocessor simulation model]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Xerox_Dragon Xerox Dragon]&lt;br /&gt;
# [http://thanaseto.110mb.com/courses/CSD-527-report-engl.pdf Coherence Protocols]&lt;br /&gt;
# [http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=289691 XDBus]&lt;br /&gt;
# [http://www.ece.wisc.edu/~wddd/2002/final/ekman.pdf Evaluation of Snoop-Energy Reduction Techniques for Chip-Multiprocessors]&lt;br /&gt;
# [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.79.7463&amp;amp;rep=rep1&amp;amp;type=pdf Power Efficient Cache Coherence]&lt;/div&gt;</summary>
		<author><name>Mqtran</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2011/ch8_mc&amp;diff=44460</id>
		<title>CSC/ECE 506 Spring 2011/ch8 mc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2011/ch8_mc&amp;diff=44460"/>
		<updated>2011-03-19T21:42:27Z</updated>

		<summary type="html">&lt;p&gt;Mqtran: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Introduction to bus-based cache coherence in real machines=&lt;br /&gt;
&lt;br /&gt;
Most parallel software in the commercial market relies on the shared-memory&lt;br /&gt;
programming model in which all processors access the same physical address space. The most common multiprocessors today use [http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP] architecture which use a common bus as the interconnect.  In the case of multicore processors (&amp;quot;chip multiprocessors,&amp;quot; or CMP) the [http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP] architecture applies to the cores treating them as separate processors. The key problem of shared-memory multiprocessors is providing a consistent view of memory with various cache hierarchies.  This is called '''''cache coherence problem'''''. It is  critical to  achieve correctness and performance-sensitive design point for supporting the shared-memory model. The cache coherence mechanisms not only govern communication in a shared-memory multiprocessor, but also typically determine how the memory system transfers data between processors, caches, and memory.&lt;br /&gt;
&lt;br /&gt;
[[Image:Busbased SMP.jpg|frame|center|&amp;lt;b&amp;gt;Figure 1:&amp;lt;/b&amp;gt; Typical Bus-Based Processor Model]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Cache Coherence in real machines=&lt;br /&gt;
==Summary of Cache Coherence Protocols==&lt;br /&gt;
At any point in logical time, the permissions for a cache block can allow either a single writer or multiple readers. The '''''coherence protocol''''' ensures the invariants of the states are maintained. The different coherent states used by most of the cache coherent protocols are shown in ''Table 1'':&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''States'''&lt;br /&gt;
|  '''Access Type'''&lt;br /&gt;
|  '''Invariant'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  read, write&lt;br /&gt;
|  all other caches in I state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  read&lt;br /&gt;
|  all other caches in I state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Owned'''&lt;br /&gt;
|  read&lt;br /&gt;
|  all other caches in I or S state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  read&lt;br /&gt;
|  no other cache in M or E state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|  -&lt;br /&gt;
|  -&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 1:&amp;lt;/b&amp;gt; States Used by the Cache Coherent Protocols&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
The first widely adopted approach to cache coherence is snooping on a bus. We will now discuss them in details in the following sections.&lt;br /&gt;
&lt;br /&gt;
===MSI===&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI protocol]''' is a three-state write-back '''invalidation protocol''' which is one of the earliest snooping-based cache coherence-protocols. It marks the cache line with one of the '''Modified (M) ,Shared (S)''', and '''Invalid (I)''' state. '''Invalid''' means the cache line is either not present or is in invalid state. If the cache line is clean and is shared by more than one processor , it is marked as '''Shared'''. If a cache line is dirty and the processor has exclusive ownership of it, it is in '''Modified''' state. BusRdx causes other processors to invalidate (demote) its cache block to the '''I''' state. If it is present in the '''M''' state in another cache, it will flush. &lt;br /&gt;
&lt;br /&gt;
The following state transition diagram for MSI protocol explains the working of the protocol:&lt;br /&gt;
&lt;br /&gt;
[[Image:MSI.jpg|frame|center|&amp;lt;b&amp;gt;Figure 2:&amp;lt;/b&amp;gt; MSI State Diagram]]&lt;br /&gt;
&lt;br /&gt;
===MESI===&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI protocol]''' has a major drawback in that each read-write sequence incurs two bus transactions irrespective of whether the cache line is stored in only one cache or not. This is a huge setback for highly parallel programs that have little data sharing. '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol solves this problem by introducing the E ('''Exclusive''') state to distinguish between a cache line stored in multiple caches and a line stored in a single cache.&lt;br /&gt;
Let us briefly look at how the MESI protocol works. (For a more detailed version readers are referred to Solihin textbook pg. 215)&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' coherence protocol marks each cache line in one of the Modified, Exclusive, Shared or Invalid state. &lt;br /&gt;
* '''Invalid''' : The cache line is either not present or is invalid&lt;br /&gt;
* '''Exclusive''' : The cache line is clean and is owned by this core/processor only&lt;br /&gt;
* '''Modified''' :  This implies that the cache line is dirty and the core/processor has  exclusive ownership of the cache line, exclusive of the memory also.&lt;br /&gt;
* '''Shared''' : The cache line is clean and is shared by more than one core/processor&lt;br /&gt;
&lt;br /&gt;
In a nutshell, the '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol works as the following: &lt;br /&gt;
A line that is just fetched receives '''E''' or '''S''' state depending on whether it exists in other processors in the system or not. Similarly, a cache line gets the '''M''' state when a processor writes to it. If the line is not in '''E''' or '''M''' state prior to being written to, the cache sends a Bus Upgrade (BusUpgr) signal or as the Intel manuals call it, a “Read-For-Ownership (RFO) request” that ensures that the line exists in the cache and is in the '''I''' state in all other processors on the bus (if any). The table shown below will summarize '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''Cache Line State:'''&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''This cache line is valid?'''&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  No&lt;br /&gt;
|-&lt;br /&gt;
|  '''The memory copy is…'''&lt;br /&gt;
|  out of date&lt;br /&gt;
|  valid&lt;br /&gt;
|  valid&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''Copies exist in caches of other processors?'''  &lt;br /&gt;
|  No&lt;br /&gt;
|  No&lt;br /&gt;
|  Maybe&lt;br /&gt;
|  Maybe&lt;br /&gt;
|-&lt;br /&gt;
|  '''A write to this line'''&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  goes to bus and updates cache&lt;br /&gt;
|  goes directly to bus&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 2:&amp;lt;/b&amp;gt; MESI Protocol Summary&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The transition diagram from the lecture slides is given below for reference.&lt;br /&gt;
&lt;br /&gt;
[[Image:MESI.jpg|frame|center|&amp;lt;b&amp;gt;Figure 4:&amp;lt;/b&amp;gt; MESI State Diagram]]&lt;br /&gt;
&lt;br /&gt;
===MESIF===&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/MESIF_protocol MESIF]''' protocol, used in the latest Intel multi-core processors Core i7, was introduced to '''accommodate the point-to-point''' links used in the QuickPath Interconnect. Using the '''MESI''' protocol in this architecture would send many redundant messages between different processors, often with unnecessarily high latency. For example, when a processor requests a cache line that is stored in multiple locations, every location might respond with the data. As the requesting processor only needs a single copy of the data, the system would be '''wasting the bandwidth'''. &lt;br /&gt;
As a '''solution''' to this problem, an additional state, '''Forward state''', was added by slightly changing the role of the Shared state. Whenever there is a read request, only the cache line in the F state will respond to the request, while all the S state caches remain dormant.  Hence, by designating a single cache line to '''respond to requests''', coherency traffic is substantially reduced when multiple copies of the data exist. Also, on a read request, the F state transitions to the S state. That is, when a cache line in the '''F''' state is '''copied''', the F state '''migrates''' to the '''newer copy''', while the '''older''' one drops back to the '''S''' state. Moving the new copy to the F state '''exploits''' both '''temporal and spatial locality'''. Because the newest copy of the cache line is always in the F state, it is very unlikely that the line in the F state will be evicted from the caches. This takes advantage of the temporal locality of the request. The second advantage is that if a particular cache line is in high demand due to spatial locality, the bandwidth used to transmit that data will be spread across several cores.&lt;br /&gt;
All M to S state transitions and E to S state transitions will now be from '''M to F''' and '''E to F'''.  &lt;br /&gt;
The '''F state''' is '''different''' from the '''Owned state''' of the MOESI protocol as it is '''not''' a '''unique''' copy because a valid copy is stored in memory. Thus, unlike the Owned state of the MOESI protocol, in which the data in the O state is the only valid copy of the data, the data in the F state can be evicted or converted to the S state, if desired. &lt;br /&gt;
&lt;br /&gt;
More information on the QuickPath Interconnect and MESIF protocol can be found at&lt;br /&gt;
'''[http://www.intel.com/technology/quickpath/introduction.pdf Introduction to QuickPath Interconnect]'''. &lt;br /&gt;
&lt;br /&gt;
We will now discuss how processor vendors like '''Intel''', '''AMD''' and others maintain cache coherence using '''''snooping based coherence protocols'''''.  For more information on snooping based protocols, readers are referred to Solihin textbook Chapter 8.&lt;br /&gt;
&lt;br /&gt;
==SGI - Silicon Graphics, Inc==&lt;br /&gt;
===MSI &amp;amp; SGI IRIS 4D Processors===&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' protocol was first used in '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''' IRIS 4D series. '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''' produced a broad range of '''[http://en.wikipedia.org/wiki/MIPS_architecture MIPS]'''-based (Microprocessor without Interlocked Pipeline Stages) workstations and servers during the 1990s, running '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''''s version of UNIX System V, now called '''[http://en.wikipedia.org/wiki/IRIX IRIX]'''. The 4D-MP graphics superworkstation brought 40 MIPS(million instructions per second) of computing performance to a graphics superworkstation. The unprecedented level of computing and graphics processing in an office-environment workstation was made possible by the fastest available Risc microprocessors in a single shared memory multiprocessor design driving a tightly coupled, highly parallel graphics system. Aggregate sustained data rates of over one gigabyte per second were achieved by a hierarchy of buses in a balanced system designed to avoid bottlenecks.&lt;br /&gt;
&lt;br /&gt;
The multiprocessor bus used in 4D-MP graphics superworkstation is a pipelined, block transfer bus that supports the cache coherence protocol as well as providing 64 megabytes of sustained data bandwidth between the processors, the memory and I/O system, and the graphics subsystem. Because the sync bus provides for efficient synchronization between processors, the cache coherence protocol was designed to support efficient data sharing between processors. If a cache coherence protocol has to support synchronization as well as sharing, a compromise in the efficiency of the data sharing protocol may be necessary to improve the efficiency of the synchronization operations. Hence it uses the simple cache coherence protocol which is the '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' protocol.&lt;br /&gt;
&lt;br /&gt;
With the simple rules of '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' enforced by the hardware protocols of&lt;br /&gt;
the sync bus and the Multiprocessor bus, efficient synchronization and efficient data sharing are achieved in a simple shared memory model of parallel processing in the 4D-MP graphics superworkstation.&lt;br /&gt;
&lt;br /&gt;
==SYNAPSE Multiprocessor==&lt;br /&gt;
===Synapse protocol and Synapse multiprocessor===&lt;br /&gt;
From the state transition diagram of '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''', we observe that for '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' there is transition to the '''S''' state from the '''M''' state when a BusRd is observed for that block. The contents of the block is flushed to the bus before going to '''S''' state. It would look more appropriate to move to the '''I''' state thus giving up the block entirely in certain cases. This choice of moving to '''S''' or '''I''' reflects the designer's assertion that the original processor is more likely to continue reading the block than the new processor to write to the block. In synapse protocol, used in the early Synapse multiprocessor, made this alternate choice of going directly from the '''M''' state to the '''I''' state on a BusRd, assuming the migratory pattern would be more frequent. More details about this protocol can be found in these papers published in late 1980's [http://portal.acm.org/citation.cfm?id=6514Cache Coherence protocols: evaluation using a multiprocessor simulation model] and [http://portal.acm.org/citation.cfm?id=1499317&amp;amp;dl=GUIDE&amp;amp;coll=GUIDE&amp;amp;CFID=83027384&amp;amp;CFTOKEN=95680533 Synapse tightly coupled multiprocessors: a new approach to solve old problems]&lt;br /&gt;
&lt;br /&gt;
In the Synapse protocol, the '''M''' state is called the '''D''' (Dirty) state. The following is the state transition diagram for Synapse protocol which clearly shows its working.&lt;br /&gt;
&lt;br /&gt;
[[Image:Synapse1.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; Synapse State Diagram]]&lt;br /&gt;
&lt;br /&gt;
==Intel==&lt;br /&gt;
===MESI &amp;amp; Intel Processors===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The '''Pentium Pro''' microprocessor, introduced in 1992 was the '''first''' Intel architecture microprocessor to support symmetric multiprocessing ('''[http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP]''') in various multiprocessor configurations. '''[http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP]''' and '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol was the architecture used consistently until the introduction of the 45-nm Hi-k Core micro-architecture in '''Intel's (Nehalem-EP) quad-core x86-64'''. The 45-nm Hi-k Intel Core microarchitecture utilizes a new system of framework called the '''QuickPath Interconnect''' which uses point-to-point interconnection technology based on distributed shared memory architecture. It uses a modified version of '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol called '''MESIF''', by introducing an additional state, F, the forward state. &lt;br /&gt;
&lt;br /&gt;
The '''Intel architecture''' uses the '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol  as the '''basis''' to ensure cache coherence, which is true whether you're on one of the older processors that use a '''common bus''' to communicate or using the new Intel '''QuickPath''' point-to-point interconnection technology. &lt;br /&gt;
&lt;br /&gt;
Let us now walk through a briefing on the '''MESIF protocol''':&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== CMP Implementation in Intel Architecture ===&lt;br /&gt;
&lt;br /&gt;
Let us now see how Intel architecture using the [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol progressed from a uniprocessor architecture to a Chip MultiProcessor (CMP) using the bus as the interconnect. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Uniprocessor Architecture'''&lt;br /&gt;
&lt;br /&gt;
The diagram below shows the structure of the memory cluster in Intel Pentium M processor.&lt;br /&gt;
&lt;br /&gt;
[[Image:intel_cache1.jpg|frame|center|&amp;lt;b&amp;gt;Figure 5:&amp;lt;/b&amp;gt; Memory Structure of the Pentium M Processor]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In this structure we have,&lt;br /&gt;
* A unified on-chip '''L1 cache''' with the '''processor/core''',&lt;br /&gt;
* A '''Memory/L2 access control unit''', through which all the accesses to the L2 cache, main memory and IO space are made,&lt;br /&gt;
* The second level '''L2 cache''' along with the '''prefetch unit''' and&lt;br /&gt;
* '''Front side bus (FSB)''', a single shared bi-directional bus through which all the traffic is sent across.These wide buses bring in multiple data bytes at a time. &lt;br /&gt;
&lt;br /&gt;
As Intel explains it, using this structure, the processor requests were first sought in the '''L2 cache''' and only on a '''miss''', were they '''forwarded''' to the main '''memory''' via the front side bus ('''FSB'''). The '''Memory/L2 access control''' unit served as a central point for '''maintaining coherence''' within the core and with the external world. It '''contains''' a '''snoop control unit''' that receives snoop requests from the bus and performs the required operations on each cache (and internal buffers) in parallel. It also handles RFO requests (BusUpgr) and ensures the operation continues only after it guarantees that no other version on the cache line exists in any other cache in the system.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''CMP Architecture'''&lt;br /&gt;
&lt;br /&gt;
For CMP implementation, Intel chose the bus-based architecture using snoopy protocols vs the '''directory protocol''' because though directory protocol reduces the active power due to reduced snoop activity, it '''increased''' the '''design complexity''' and the '''static power''' due to larger tag arrays. Since Intel has a large market for the processors in the mobility family, directory-based solution was less favorable since battery life mainly depends on static power consumption and less on dynamic power.&lt;br /&gt;
Let us examine how '''CMP''' was implemented in '''Intel Core Duo''', which was one of the first dual-core processor for the budget/entry-level market. &lt;br /&gt;
The general CMP implementation structure of the Intel Core Duo is shown below&lt;br /&gt;
&lt;br /&gt;
[[Image:intel_cache2.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; Intel Core Duo CMP Implementation]]&lt;br /&gt;
&lt;br /&gt;
This structure has the following changes when compared to the uniprocessor memory cluster structure. &lt;br /&gt;
* '''L1 cache''' and the '''processor/core''' structure is '''duplicated''' to give 2 cores.&lt;br /&gt;
* The '''Memory/L2 access control''' unit is '''split''' into 2 logical units: '''L2 controller''' and '''bus controller'''. The L2 controller handles all '''requests to the L2''' cache from the core and the snoop requests from the FSB. The '''bus controller''' handles '''data and I/O requests''' to and from the FSB.&lt;br /&gt;
* The '''prefetching''' unit is extended to handle the hardware '''prefetches for each core separately'''.&lt;br /&gt;
* A '''new logical unit''' (represented by the hexagon) was added to maintain '''fairness between the requests''' coming from the different cores and hence balance the requests to L2 and memory.&lt;br /&gt;
&lt;br /&gt;
This new '''partitioned structure''' for the  memory/L2 access control unit '''enhanced''' the '''performance''' while '''reducing power consumption'''. &lt;br /&gt;
For more information on uniprocessor and multiprocessor implementation under the Intel architecture, refer to &lt;br /&gt;
[http://www.intel.com/technology/itj/2006/volume10issue02/art02_CMP_Implementation/p03_implementation.htm CMP Implementation in Intel Core Duo Processors]&lt;br /&gt;
&lt;br /&gt;
The '''Intel bus architecture''' has been '''evolving''' in order to accommodate the demands of scalability while using the '''same [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol'''; From using a '''single shared bus''' to '''dual independent buses (DIB)''' doubling the available bandwidth and to the logical conclusion of DIB with the introduction of '''dedicated high-speed interconnects (DHSI)'''. The DHSI-based platforms use four FSBs, one for each processor in the platform. In both DIB and DHSI, the snoop filter was used in the chipset to cache snoop information, thereby significantly reducing the broadcasting needed for the snoop traffic on the buses. With the production of processors based on next generation 45-nm Hi-k Intel Core microarchitecture, the [http://en.wikipedia.org/wiki/Xeon Intel Xeon] processor fabric will transition from a DHSI, with the memory controller in the chipset, to a distributed shared memory architecture using '''Intel QuickPath Interconnects using MESIF protocol'''.&lt;br /&gt;
&lt;br /&gt;
==AMD - Advanced Micro Devices Processors==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===MOESI &amp;amp; AMD Processors===&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/Opteron AMD Opteron] was AMD’s first-generation dual core which had two distinct [http://en.wikipedia.org/wiki/Athlon_64 K8 cores] together on a single die. Cache coherence produces bigger problems on such multiprocessors. It was necessary to use an appropriate coherence protocol to address this problem. The [http://en.wikipedia.org/wiki/Xeon Intel Xeon], which was the competitive counterpart from Intel to AMD dual core Opteron, used the [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol to handle cache coherence. [http://en.wikipedia.org/wiki/MESI_protocol MESI] came with the drawback of using much time and bandwidth in certain situations. &lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/MOESI_protocol MOESI] was AMD’s answer to this problem. [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] added a fifth state to [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol called the '''owned''' state. [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] addresses the bandwidth problem faced in MESI protocol when processor having invalid data in its cache wants to modify the data.  The processor seeking the data access will have to wait for the processor which modified this data to write back to the main memory, which takes time and bandwidth. This drawback is removed in MOESI by allowing dirty sharing.  When the data is held by a processor in the new state '''owned''', it can provide other processors the modified data without or even before writing it to the main memory. This is called '''''dirty sharing'''''. The processor with the data in the '''owned''' state stays responsible to update the main memory later when the cache line is evicted.&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/MOESI_protocol MOESI]  has become one of the most popular snoop-based protocols supported in AMD64 architecture.  AMD dual-core Opteron can maintain cache coherence in systems up to 8 processors using this protocol.&lt;br /&gt;
&lt;br /&gt;
The five different states of [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol are:&lt;br /&gt;
* '''Modified (M)''': The most recent copy of the data is present in the cache line. But it is not present in any other processor cache.&lt;br /&gt;
* '''Owned (O)''': The cache line has the most recent correct copy of the data. This can be shared by other processors. The processor in this state for this cache line is responsible to update the correct value in the main memory before it gets evicted.&lt;br /&gt;
* '''Exclusive (E)''': A cache line holds the most recent, correct copy of the data, which is exclusively present on this processor and a copy is present in the main memory.&lt;br /&gt;
* '''Shared (S)''': A cache line in the shared state holds the most recent, correct copy of the data, which may be shared by other processors.&lt;br /&gt;
* '''Invalid (I)''': A cache line does not hold a valid copy of the data.&lt;br /&gt;
&lt;br /&gt;
A detailed explanation of this protocol implementation on AMD processor can be found in the manual [http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html Architecture of AMD 64-bit core]&lt;br /&gt;
&lt;br /&gt;
The following table summarizes the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''Cache Line State:'''&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  '''Owner''' &lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''This cache line is valid?'''&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  No&lt;br /&gt;
|-&lt;br /&gt;
|  '''The memory copy is…'''&lt;br /&gt;
|  out of date&lt;br /&gt;
|  out of date&lt;br /&gt;
|  valid&lt;br /&gt;
|  valid&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''Copies exist in caches of other processors?'''&lt;br /&gt;
|  No&lt;br /&gt;
|  No&lt;br /&gt;
|  Yes(out of date values)|  Maybe&lt;br /&gt;
|  Maybe&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''A write to this line'''&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  does not go to bus|  does not go to bus&lt;br /&gt;
|  goes to bus and updates cache&lt;br /&gt;
|  goes directly to bus&lt;br /&gt;
|  -&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 3:&amp;lt;/b&amp;gt; MOESI Protocol Summary&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
State transition for [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]is as shown below : &lt;br /&gt;
&lt;br /&gt;
[[Image:MOESI_State_Transition_Diagram.jpg|frame|center|&amp;lt;b&amp;gt;Figure 7:&amp;lt;/b&amp;gt; [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]State transition Diagram]]&lt;br /&gt;
&lt;br /&gt;
===AMD Opteron memory Architecture===&lt;br /&gt;
&lt;br /&gt;
[[Image:Untitled.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; AMD Opteron memory Architecture]]&lt;br /&gt;
&lt;br /&gt;
The AMD processor’s high-performance cache architecture includes an integrated, 64-bit, dual-ported  128-Kbyte split-L1 cache with separate snoop port, multi-level translation lookaside buffers (TLBs), a scalable L2 cache controller with a 72-bit (64-bit data + 8-bit ECC) interface to as much as 8-Mbyte of industry-standard SDR or DDR SRAMs, and an integrated tag for the most cost-effective 512-Kbyte L2 configurations. The AMD Athlon processor’s integrated L1 cache comprises two separate 64-Kbyte, two-way set-associative data and instruction caches.&lt;br /&gt;
&lt;br /&gt;
More information about this can be found in [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD 64 bit Architecture Programmers's Manual]&lt;br /&gt;
&lt;br /&gt;
===Special Coherence Considerations in AMD64 architectures===&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
Instruction prefetching is a technique used to speedup the execution of the program. But in multiprocessors, prefetching comes at the cost of performance. Due to prefetching, the data can be modified in such a way that the memory coherence protocol will not be able to handle the effects. In such situations software must use serializing instructions or cache-invalidation instructions to guarantee subsequent data accesses are coherent. &lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
An example of this type of a situation is a page-table update followed by accesses to the physical pages referenced by the updated page tables. The physical-memory references for the page tables are different than the physical-memory references for the data. Because of prefetching, there maybe problem with correctness. The following sequence of events shows such a situation when software changes the translation of virtual-page A from physical-page M to physical-page N:&lt;br /&gt;
# The tables that translate virtual-page A to physical-page M are now held only in main memory. The copies in the cache ae invalidated.&lt;br /&gt;
# Page-table entry is changed by the software for virtual-page A in main memory to point to physical page N rather than physical-page M.&lt;br /&gt;
# Data in virtual-page A is accessed.&lt;br /&gt;
&lt;br /&gt;
Software expects the processor to access the data from physical-page N after the update. However, it is possible for the processor to prefetch the data from physical-page M before the page table for virtual page A is updated. Because the physical-memory references are different, the processor does not recognize them as requiring coherence checking and believes it is safe to prefetch the data from virtual-page A, which is translated into a read from physical page M. Similar behavior can occur when instructions are prefetched from beyond the page table update instruction.&lt;br /&gt;
&lt;br /&gt;
In order to prevent errors from occuring, there are special instructions provided by software like INVLPG or MOV CR3 instruction which is executed immediately after the page-table update to ensure that subsequent instruction fetches and data accesses use the correct virtual-page-to-physical-page translation. It is not necessary to perform a TLB invalidation operation preceding the table update.&lt;br /&gt;
&lt;br /&gt;
More information can be found about this in [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD64 Architecture Programmer's manual]&lt;br /&gt;
&lt;br /&gt;
===Optimization techniques on MOESI when implemented on AMD Phenom processors===&lt;br /&gt;
&lt;br /&gt;
In real machines, using some optimization techniques on the standard cache coherence protocol used, improves the performance of the machine. For example, [http://en.wikipedia.org/wiki/AMD_Phenom AMD Phenom] family of microprocessors (Family 0×10) which is AMD’s first generation to incorporate 4 distinct cores on a single die. It is the first to have a cache that all the cores share, using the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol with some optimization techniques incorporated. &lt;br /&gt;
&lt;br /&gt;
It focuses on a small subset of compute problems which behave like Producer and Consumer programs. In such a computing problem, a thread of a program running on a single core produces data, which is consumed by a thread that is running on a separate core. With such programs, it is desirable to get the two distinct cores to communicate through the shared cache, to avoid round trips to/from main memory. The '''MOESI''' protocol that the [http://en.wikipedia.org/wiki/AMD_Phenom AMD Phenom] cache uses for cache coherence can also limit bandwidth. Hence by keeping the cache line in the '''M''' state for such computing problems, we can achieve better performance.&lt;br /&gt;
&lt;br /&gt;
When the producer thread , writes a new entry, it allocates cache-lines in the '''M''' state. Eventually, these M-marked cache lines will start to fill the L3 cache. When the consumer reads the cache line, the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol changes the state of the cache line to the '''O''' state in the L3 cache and pulls down a '''shared (S)''' copy for its own use. Now, the producer thread circles the ring buffer to arrive back to the same cache line it had previously written. However, when the producer attempts to write new data to the owned (marked '''‘O’''') cache line, it finds that it cannot, since a cache line in the '''O''' state by the previous consumer read does not have sufficient permission for a write request (in the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]). To maintain coherence, the memory controller must initiate probes in the other caches (to handle any other S copies that may exist). This will slow down the process.&lt;br /&gt;
&lt;br /&gt;
Thus, it is preferable to keep the cache line in the '''M''' state in the L3 cache. In such a situation, when the producer comes back around the ring buffer, it finds the previously written cache line still in the'''M''' state, to which it is safe to write without coherence concerns. Thus better performance can be achieved by such optimization techniques to standard protocols when implemented in real machines.&lt;br /&gt;
&lt;br /&gt;
You can find more information on how this is implemented and various other ways of optimizations in this manual [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf Software Optimization guide for AMD 10h Processors].&lt;br /&gt;
&lt;br /&gt;
==Xerox Corporation==&lt;br /&gt;
===Dragon Protocol &amp;amp; Xerox Dragon Processors===&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' is an update based coherence protocol which does not invalidate other cached copies like what we have seen in the coherence protocols so far. Write propagation is achieved by updating the cached copies instead of invalidating them.  But the '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' does not update memory on a cache to cache transfer and delays the memory and cache consistency until the data is evicted and written back, which saves time and lowers the memory access requirements. Moreover only the written '''byte''' or the '''word''' is '''communicated''' to the '''other caches''' instead of the whole block which further '''reduces''' the '''bandwidth''' usage. It has the ability to detect dynamically, the sharing status of a block and use a write through policy for shared blocks and write back for currently non-shared blocks. The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' employs the following four states for the cache blocks: '''Shared Clean''', '''Shared Modified''', '''Exclusive''', and  '''Modified'''. &lt;br /&gt;
* '''Modified (M)''' and '''Exclusive (E)''' - these states have the same meaning as explained in the protocols above. &lt;br /&gt;
* '''Shared Modified (Sm)''' - Only one cache line in the system can be in the Shared Modified state. Potentially two or more caches    have this block and memory may or may not be up to date and this processor's cache had modified the block.&lt;br /&gt;
* '''Shared Clean (Sc)''' -  Potentially two or more caches have this block and memory may or may not be up to date(if no other cache has it in Sm state, memory will be up to date else it is not).&lt;br /&gt;
When a Shared Modified line is evicted from the cache on a cache miss only then is the block written back to the main memory in order to keep memory consistent. For more information on Dragon protocol, refer to Solihin textbook, page number 229. The state transition diagram has been given below for reference.&lt;br /&gt;
&lt;br /&gt;
[[Image:Dragon.jpg|frame|center|&amp;lt;b&amp;gt;Figure 9:&amp;lt;/b&amp;gt; Dragon Protocol State Diagram]]&lt;br /&gt;
&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' , was developed by Xerox Palo Alto Research Center ('''[http://en.wikipedia.org/wiki/Xerox_PARC Xerox PARC]'''), a subsidiary of Xerox Corporation.  This protocol was used in the '''[http://en.wikipedia.org/w/index.php?title=Xerox_Dragon&amp;amp;redirect=no Xerox PARC Dragon]''' multiprocessor workstation, a VLSI research computer that could support multiple processors on a central high bandwidth memory bus. The Dragon design implemented snoopy caches that provided the appearance of a uniform memory space to multiple processors. Here, each cache listens to 2 buses: the processor bus and the memory bus. The caches are also responsible for address translation, so the processor bus carries virtual addresses and the memory bus carries physical addresses.  The Dragon system was designed to support 4 to 8 Dragon processors. The memory bus used in the Xeron Dragon evolved to become the '''[http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=289691 XDBus]''' , a low-cost, synchronous, '''packet-switched VLSI bus''' designed for use in high-performance multiprocessors. This was used as the interconnect in many multiprocessor server systems like '''Cray Superserver 6400''', '''Sun Microsystems' SPARCcenter 2000''' and '''SPARCserver 1000'''  and '''Sun4d''' systems.&lt;br /&gt;
&lt;br /&gt;
=Cache Coherence Power Utilization=&lt;br /&gt;
A number of studies have been performed to reduce the power consumption of cache coherence protocols. In order to perform a solid comparison between the cache coherency protocols, one would need to develop a multi-core processor for each of the cache coherency protocols. Additionally, the hardware and software configuration would also need to be similar between each system (except for the hardware required to implement each of the different protocols). Unfortunately, there are no such processors available. This section will discuss power consumption in general terms, comparing to each of the protocols. Also, this section will briefly discussion some power optimization techniques.&lt;br /&gt;
&lt;br /&gt;
Bus transactions, in general, are costly for both performance and power consumption. Additionally, studies have been performed showing that unnecessary snooping can waste power. Power requirements are typically determined by the number of bus snoops and number of bus accesses by each processor. One study indicates that interchip bus communications can consume up to 20% of total chip power[[#References|&amp;lt;sup&amp;gt;[20]&amp;lt;/sup&amp;gt;]].&lt;br /&gt;
Using the examples from the class notes, we can analyze the relative power consumption between the protocols. The following table is a summary of various protocols showing the number of bus communications that occur for each processor action.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|'''Processor Action'''&lt;br /&gt;
|'''MSI Bus Actions'''&lt;br /&gt;
|'''MESI Bus Actions'''&lt;br /&gt;
|'''Dragon Bus Actions'''&lt;br /&gt;
|'''FireFly Bus Actions'''&lt;br /&gt;
|-&lt;br /&gt;
|R1&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|-&lt;br /&gt;
|W1&lt;br /&gt;
|BusRdX&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R3&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|-&lt;br /&gt;
|W3&lt;br /&gt;
|BusRdX&lt;br /&gt;
|BusRdX&lt;br /&gt;
|BusUpd/Upd&lt;br /&gt;
|BusUpd&lt;br /&gt;
|-&lt;br /&gt;
|R1&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R3&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R2&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 4:&amp;lt;/b&amp;gt; Summary of Bus Actions for Select Protocols&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
From the table above, we can see that MSI has a larger number of bus transactions than the Dragon protocol. Even though bus transactions are not power efficient, snooping can also be enhanced to improve power efficiency. The following section will discuss snoop filtering techniques.&lt;br /&gt;
&lt;br /&gt;
==Power Savings Using Snoop Filtering==&lt;br /&gt;
A number of studies have been performed to reduce the number of unnecessary snoops during cache transactions. Two such filtering techniques are serial snooping and Jetty. The following sections will briefly discuss these two filtering techniques and power savings achieved using these techniques. Studies show that as much as 90% of snoop broadcasts will result in a miss[[#References|&amp;lt;sup&amp;gt;[19]&amp;lt;/sup&amp;gt;]] in the other caches at the same level and require that the information be provided by the next level of cache or memory. As much as a 36% savings in power by filtering snoops using one of the following snoop filtering methods[[#References|&amp;lt;sup&amp;gt;[19]&amp;lt;/sup&amp;gt;]].&lt;br /&gt;
===Serial Snooping===&lt;br /&gt;
Serial snooping takes advantage of the fact that if a miss occurs in one cache, it is possible to find the block in one other cache without having to check all the caches. If the cache block is available in multiple caches, there is a high probability that the cache miss can find the data in a nearby cache. Alternatively, savings can be realized by searching a subset of the caches vice all the caches. One thing to note is that this is only effective for read misses. Write, an invalidation transaction needs to be transmitted to the other caches, thus a bus transaction is unavoidable.&lt;br /&gt;
===Jetty===&lt;br /&gt;
Jetty is a mechanism attached to each cache that verifies that a bus snoop is necessary. Jetty is used to filter L2 tag lookups. When a processor needs to perform a bus snoop, the Jetty is checked first. The Jetty can determine if a cache tag lookup is required. Since the Jetty is much smaller than the associated cache, less power is required to determine if a snoop is required.&lt;br /&gt;
&lt;br /&gt;
There are a couple of different Jetty schemes. There is the exclude-Jetty, include-Jetty, and hybrid-Jetty. The exclude-Jetty exploits the fact that if a cache block is snooped, it is highly likely the same cache block will be snooped in the near future. The exclude-Jetty keeps track of the tag lookups in a small table and can determine if a cache tag lookup is necessary.&lt;br /&gt;
&lt;br /&gt;
The include-Jetty keeps a superset of the blocks that are cached. If a miss occurs in the include-Jetty, then it can be guaranteed that the block is not stored in its associated cache.&lt;br /&gt;
&lt;br /&gt;
The hybrid-Jetty is simply a combinations of and include and exclude-Jetty. Both types of Jetty are present and when a lookup occurs, both Jettys are checked to determine if a cache lookup is necessary.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Cache_coherence Cache coherence]&lt;br /&gt;
# [http://www.intel.com/technology/quickpath/introduction.pdf Introduction to QuickPath Interconnect]&lt;br /&gt;
# [http://www.intel.com/technology/itj/2006/volume10issue02/art02_CMP_Implementation/p03_implementation.htm CMP Implementation in Intel Core Duo Processors]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Symmetric_multiprocessing Common System Interface in Intel Processors]&lt;br /&gt;
# [http://www.zak.ict.pwr.wroc.pl/nikodem/ak_materialy/Cache%20consistency%20&amp;amp;%20MESI.pdf Cache consistency with MESI on Intel processor]&lt;br /&gt;
# [http://techreport.com/articles.x/8236/2 AMD dual core Architecture]&lt;br /&gt;
# [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD64 Architecture Programmer's manual]&lt;br /&gt;
# [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf Software Optimization guide for AMD 10h Processors]&lt;br /&gt;
# [http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html Architecture of AMD 64 bit core]&lt;br /&gt;
# [http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=4913 Silicon Graphics Computer Systems]&lt;br /&gt;
# [http://books.google.com/books?id=g82fofiqa5IC&amp;amp;printsec=frontcover&amp;amp;dq=Parallel+computer+architecture:+a+hardware/software+approach+By+David+E.+Culler,+Jaswinder+Pal+Singh,+Anoop+Gupta&amp;amp;source=bl&amp;amp;ots=COrdamlfVn&amp;amp;sig=YcugVqbzTjHvlofvaFq6Ft_tjfY&amp;amp;hl=en&amp;amp;ei=0ZO6S4TJGcOclgejzI3BBw&amp;amp;sa=X&amp;amp;oi=book_result&amp;amp;ct=result&amp;amp;resnum=1&amp;amp;ved=0CAgQ6AEwAA#v=onepage&amp;amp;q=&amp;amp;f=false Parallel computer architecture: a hardware/software approach By David E. Culler, Jaswinder Pal Singh, Anoop Gupta]&lt;br /&gt;
# [http://www.freepatentsonline.com/5283886.html Three state invalidation protocols]&lt;br /&gt;
# [http://portal.acm.org/citation.cfm?id=1499317&amp;amp;dl=GUIDE&amp;amp;coll=GUIDE&amp;amp;CFID=83027384&amp;amp;CFTOKEN=95680533 Synapse tightly coupled multiprocessors: a new approach to solve old problems]&lt;br /&gt;
# [http://portal.acm.org/citation.cfm?id=6514Cache Coherence protocols: evaluation using a multiprocessor simulation model]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Xerox_Dragon Xerox Dragon]&lt;br /&gt;
# [http://thanaseto.110mb.com/courses/CSD-527-report-engl.pdf Coherence Protocols]&lt;br /&gt;
# [http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=289691 XDBus]&lt;br /&gt;
# [http://www.ece.wisc.edu/~wddd/2002/final/ekman.pdf Evaluation of Snoop-Energy Reduction Techniques for Chip-Multiprocessors]&lt;br /&gt;
# [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.79.7463&amp;amp;rep=rep1&amp;amp;type=pdf Power Efficient Cache Coherence]&lt;/div&gt;</summary>
		<author><name>Mqtran</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2011/ch8_mc&amp;diff=44459</id>
		<title>CSC/ECE 506 Spring 2011/ch8 mc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2011/ch8_mc&amp;diff=44459"/>
		<updated>2011-03-19T21:34:41Z</updated>

		<summary type="html">&lt;p&gt;Mqtran: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Introduction to bus-based cache coherence in real machines=&lt;br /&gt;
&lt;br /&gt;
Most parallel software in the commercial market relies on the shared-memory&lt;br /&gt;
programming model in which all processors access the same physical address space. The most common multiprocessors today use [http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP] architecture which use a common bus as the interconnect.  In the case of multicore processors (&amp;quot;chip multiprocessors,&amp;quot; or CMP) the [http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP] architecture applies to the cores treating them as separate processors. The key problem of shared-memory multiprocessors is providing a consistent view of memory with various cache hierarchies.  This is called '''''cache coherence problem'''''. It is  critical to  achieve correctness and performance-sensitive design point for supporting the shared-memory model. The cache coherence mechanisms not only govern communication in a shared-memory multiprocessor, but also typically determine how the memory system transfers data between processors, caches, and memory.&lt;br /&gt;
&lt;br /&gt;
[[Image:Busbased SMP.jpg|frame|center|&amp;lt;b&amp;gt;Figure 1:&amp;lt;/b&amp;gt; Typical Bus-Based Processor Model]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Cache Coherence in real machines=&lt;br /&gt;
==Summary of Cache Coherence Protocols==&lt;br /&gt;
At any point in logical time, the permissions for a cache block can allow either a single writer or multiple readers. The '''''coherence protocol''''' ensures the invariants of the states are maintained. The different coherent states used by most of the cache coherent protocols are shown in ''Table 1'':&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''States'''&lt;br /&gt;
|  '''Access Type'''&lt;br /&gt;
|  '''Invariant'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  read, write&lt;br /&gt;
|  all other caches in I state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  read&lt;br /&gt;
|  all other caches in I state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Owned'''&lt;br /&gt;
|  read&lt;br /&gt;
|  all other caches in I or S state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  read&lt;br /&gt;
|  no other cache in M or E state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|  -&lt;br /&gt;
|  -&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 1:&amp;lt;/b&amp;gt; States Used by the Cache Coherent Protocols&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
The first widely adopted approach to cache coherence is snooping on a bus. We will now discuss them in details in the following sections.&lt;br /&gt;
&lt;br /&gt;
===MESI===&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI protocol]''' has a major drawback in that each read-write sequence incurs two bus transactions irrespective of whether the cache line is stored in only one cache or not. This is a huge setback for highly parallel programs that have little data sharing. '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol solves this problem by introducing the E ('''Exclusive''') state to distinguish between a cache line stored in multiple caches and a line stored in a single cache.&lt;br /&gt;
Let us briefly look at how the MESI protocol works. (For a more detailed version readers are referred to Solihin textbook pg. 215)&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' coherence protocol marks each cache line in one of the Modified, Exclusive, Shared or Invalid state. &lt;br /&gt;
* '''Invalid''' : The cache line is either not present or is invalid&lt;br /&gt;
* '''Exclusive''' : The cache line is clean and is owned by this core/processor only&lt;br /&gt;
* '''Modified''' :  This implies that the cache line is dirty and the core/processor has  exclusive ownership of the cache line, exclusive of the memory also.&lt;br /&gt;
* '''Shared''' : The cache line is clean and is shared by more than one core/processor&lt;br /&gt;
&lt;br /&gt;
In a nutshell, the '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol works as the following: &lt;br /&gt;
A line that is just fetched receives '''E''' or '''S''' state depending on whether it exists in other processors in the system or not. Similarly, a cache line gets the '''M''' state when a processor writes to it. If the line is not in '''E''' or '''M''' state prior to being written to, the cache sends a Bus Upgrade (BusUpgr) signal or as the Intel manuals call it, a “Read-For-Ownership (RFO) request” that ensures that the line exists in the cache and is in the '''I''' state in all other processors on the bus (if any). The table shown below will summarize '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''Cache Line State:'''&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''This cache line is valid?'''&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  No&lt;br /&gt;
|-&lt;br /&gt;
|  '''The memory copy is…'''&lt;br /&gt;
|  out of date&lt;br /&gt;
|  valid&lt;br /&gt;
|  valid&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''Copies exist in caches of other processors?'''  &lt;br /&gt;
|  No&lt;br /&gt;
|  No&lt;br /&gt;
|  Maybe&lt;br /&gt;
|  Maybe&lt;br /&gt;
|-&lt;br /&gt;
|  '''A write to this line'''&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  goes to bus and updates cache&lt;br /&gt;
|  goes directly to bus&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 2:&amp;lt;/b&amp;gt; MESI Protocol Summary&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The transition diagram from the lecture slides is given below for reference.&lt;br /&gt;
&lt;br /&gt;
[[Image:MESI.jpg|frame|center|&amp;lt;b&amp;gt;Figure 4:&amp;lt;/b&amp;gt; MESI State Diagram]]&lt;br /&gt;
&lt;br /&gt;
===MESIF===&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/MESIF_protocol MESIF]''' protocol, used in the latest Intel multi-core processors Core i7, was introduced to '''accommodate the point-to-point''' links used in the QuickPath Interconnect. Using the '''MESI''' protocol in this architecture would send many redundant messages between different processors, often with unnecessarily high latency. For example, when a processor requests a cache line that is stored in multiple locations, every location might respond with the data. As the requesting processor only needs a single copy of the data, the system would be '''wasting the bandwidth'''. &lt;br /&gt;
As a '''solution''' to this problem, an additional state, '''Forward state''', was added by slightly changing the role of the Shared state. Whenever there is a read request, only the cache line in the F state will respond to the request, while all the S state caches remain dormant.  Hence, by designating a single cache line to '''respond to requests''', coherency traffic is substantially reduced when multiple copies of the data exist. Also, on a read request, the F state transitions to the S state. That is, when a cache line in the '''F''' state is '''copied''', the F state '''migrates''' to the '''newer copy''', while the '''older''' one drops back to the '''S''' state. Moving the new copy to the F state '''exploits''' both '''temporal and spatial locality'''. Because the newest copy of the cache line is always in the F state, it is very unlikely that the line in the F state will be evicted from the caches. This takes advantage of the temporal locality of the request. The second advantage is that if a particular cache line is in high demand due to spatial locality, the bandwidth used to transmit that data will be spread across several cores.&lt;br /&gt;
All M to S state transitions and E to S state transitions will now be from '''M to F''' and '''E to F'''.  &lt;br /&gt;
The '''F state''' is '''different''' from the '''Owned state''' of the MOESI protocol as it is '''not''' a '''unique''' copy because a valid copy is stored in memory. Thus, unlike the Owned state of the MOESI protocol, in which the data in the O state is the only valid copy of the data, the data in the F state can be evicted or converted to the S state, if desired. &lt;br /&gt;
&lt;br /&gt;
More information on the QuickPath Interconnect and MESIF protocol can be found at&lt;br /&gt;
'''[http://www.intel.com/technology/quickpath/introduction.pdf Introduction to QuickPath Interconnect]'''. &lt;br /&gt;
&lt;br /&gt;
We will now discuss how processor vendors like '''Intel''', '''AMD''' and others maintain cache coherence using '''''snooping based coherence protocols'''''.  For more information on snooping based protocols, readers are referred to Solihin textbook Chapter 8.&lt;br /&gt;
&lt;br /&gt;
==SGI - Silicon Graphics, Inc==&lt;br /&gt;
===MSI &amp;amp; SGI IRIS 4D Processors===&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' is a three-state write-back '''invalidation protocol''' which is one of the earliest snooping-based cache coherence-protocols. It marks the cache line in '''Modified (M) ,Shared (S)''', and '''Invalid (I)''' state. '''Invalid''' means the cache line is either not present or is invalid state. If the cache line is clean and is shared by more than one processor , it is marked '''shared'''. If cache line is dirty and the processor has exclusive ownership of the cache line, it is present in '''Modified''' state. BusRdx causes other processors to invalidate (demote) its cache block to the '''I''' state. If it is present in the '''M''' state in another cache, it will flush. BusRdx, even if hit in '''S''' state, is promoted to '''M''' (upgrade) state.&lt;br /&gt;
&lt;br /&gt;
The following state transition diagram for MSI protocol explains the working of the protocol:&lt;br /&gt;
&lt;br /&gt;
[[Image:MSI.jpg|frame|center|&amp;lt;b&amp;gt;Figure 2:&amp;lt;/b&amp;gt; MSI State Diagram]]&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' protocol was first used in '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''' IRIS 4D series. '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''' produced a broad range of '''[http://en.wikipedia.org/wiki/MIPS_architecture MIPS]'''-based (Microprocessor without Interlocked Pipeline Stages) workstations and servers during the 1990s, running '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''''s version of UNIX System V, now called '''[http://en.wikipedia.org/wiki/IRIX IRIX]'''. The 4D-MP graphics superworkstation brought 40 MIPS(million instructions per second) of computing performance to a graphics superworkstation. The unprecedented level of computing and graphics processing in an office-environment workstation was made possible by the fastest available Risc microprocessors in a single shared memory multiprocessor design driving a tightly coupled, highly parallel graphics system. Aggregate sustained data rates of over one gigabyte per second were achieved by a hierarchy of buses in a balanced system designed to avoid bottlenecks.&lt;br /&gt;
&lt;br /&gt;
The multiprocessor bus used in 4D-MP graphics superworkstation is a pipelined, block transfer bus that supports the cache coherence protocol as well as providing 64 megabytes of sustained data bandwidth between the processors, the memory and I/O system, and the graphics subsystem. Because the sync bus provides for efficient synchronization between processors, the cache coherence protocol was designed to support efficient data sharing between processors. If a cache coherence protocol has to support synchronization as well as sharing, a compromise in the efficiency of the data sharing protocol may be necessary to improve the efficiency of the synchronization operations. Hence it uses the simple cache coherence protocol which is the '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' protocol.&lt;br /&gt;
&lt;br /&gt;
With the simple rules of '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' enforced by the hardware protocols of&lt;br /&gt;
the sync bus and the Multiprocessor bus, efficient synchronization and efficient data sharing are achieved in a simple shared memory model of parallel processing in the 4D-MP graphics superworkstation.&lt;br /&gt;
&lt;br /&gt;
==SYNAPSE Multiprocessor==&lt;br /&gt;
===Synapse protocol and Synapse multiprocessor===&lt;br /&gt;
From the state transition diagram of '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''', we observe that for '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' there is transition to the '''S''' state from the '''M''' state when a BusRd is observed for that block. The contents of the block is flushed to the bus before going to '''S''' state. It would look more appropriate to move to the '''I''' state thus giving up the block entirely in certain cases. This choice of moving to '''S''' or '''I''' reflects the designer's assertion that the original processor is more likely to continue reading the block than the new processor to write to the block. In synapse protocol, used in the early Synapse multiprocessor, made this alternate choice of going directly from the '''M''' state to the '''I''' state on a BusRd, assuming the migratory pattern would be more frequent. More details about this protocol can be found in these papers published in late 1980's [http://portal.acm.org/citation.cfm?id=6514Cache Coherence protocols: evaluation using a multiprocessor simulation model] and [http://portal.acm.org/citation.cfm?id=1499317&amp;amp;dl=GUIDE&amp;amp;coll=GUIDE&amp;amp;CFID=83027384&amp;amp;CFTOKEN=95680533 Synapse tightly coupled multiprocessors: a new approach to solve old problems]&lt;br /&gt;
&lt;br /&gt;
In the Synapse protocol, the '''M''' state is called the '''D''' (Dirty) state. The following is the state transition diagram for Synapse protocol which clearly shows its working.&lt;br /&gt;
&lt;br /&gt;
[[Image:Synapse1.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; Synapse State Diagram]]&lt;br /&gt;
&lt;br /&gt;
==Intel==&lt;br /&gt;
===MESI &amp;amp; Intel Processors===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The '''Pentium Pro''' microprocessor, introduced in 1992 was the '''first''' Intel architecture microprocessor to support symmetric multiprocessing ('''[http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP]''') in various multiprocessor configurations. '''[http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP]''' and '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol was the architecture used consistently until the introduction of the 45-nm Hi-k Core micro-architecture in '''Intel's (Nehalem-EP) quad-core x86-64'''. The 45-nm Hi-k Intel Core microarchitecture utilizes a new system of framework called the '''QuickPath Interconnect''' which uses point-to-point interconnection technology based on distributed shared memory architecture. It uses a modified version of '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol called '''MESIF''', by introducing an additional state, F, the forward state. &lt;br /&gt;
&lt;br /&gt;
The '''Intel architecture''' uses the '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol  as the '''basis''' to ensure cache coherence, which is true whether you're on one of the older processors that use a '''common bus''' to communicate or using the new Intel '''QuickPath''' point-to-point interconnection technology. &lt;br /&gt;
&lt;br /&gt;
Let us now walk through a briefing on the '''MESIF protocol''':&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== CMP Implementation in Intel Architecture ===&lt;br /&gt;
&lt;br /&gt;
Let us now see how Intel architecture using the [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol progressed from a uniprocessor architecture to a Chip MultiProcessor (CMP) using the bus as the interconnect. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Uniprocessor Architecture'''&lt;br /&gt;
&lt;br /&gt;
The diagram below shows the structure of the memory cluster in Intel Pentium M processor.&lt;br /&gt;
&lt;br /&gt;
[[Image:intel_cache1.jpg|frame|center|&amp;lt;b&amp;gt;Figure 5:&amp;lt;/b&amp;gt; Memory Structure of the Pentium M Processor]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In this structure we have,&lt;br /&gt;
* A unified on-chip '''L1 cache''' with the '''processor/core''',&lt;br /&gt;
* A '''Memory/L2 access control unit''', through which all the accesses to the L2 cache, main memory and IO space are made,&lt;br /&gt;
* The second level '''L2 cache''' along with the '''prefetch unit''' and&lt;br /&gt;
* '''Front side bus (FSB)''', a single shared bi-directional bus through which all the traffic is sent across.These wide buses bring in multiple data bytes at a time. &lt;br /&gt;
&lt;br /&gt;
As Intel explains it, using this structure, the processor requests were first sought in the '''L2 cache''' and only on a '''miss''', were they '''forwarded''' to the main '''memory''' via the front side bus ('''FSB'''). The '''Memory/L2 access control''' unit served as a central point for '''maintaining coherence''' within the core and with the external world. It '''contains''' a '''snoop control unit''' that receives snoop requests from the bus and performs the required operations on each cache (and internal buffers) in parallel. It also handles RFO requests (BusUpgr) and ensures the operation continues only after it guarantees that no other version on the cache line exists in any other cache in the system.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''CMP Architecture'''&lt;br /&gt;
&lt;br /&gt;
For CMP implementation, Intel chose the bus-based architecture using snoopy protocols vs the '''directory protocol''' because though directory protocol reduces the active power due to reduced snoop activity, it '''increased''' the '''design complexity''' and the '''static power''' due to larger tag arrays. Since Intel has a large market for the processors in the mobility family, directory-based solution was less favorable since battery life mainly depends on static power consumption and less on dynamic power.&lt;br /&gt;
Let us examine how '''CMP''' was implemented in '''Intel Core Duo''', which was one of the first dual-core processor for the budget/entry-level market. &lt;br /&gt;
The general CMP implementation structure of the Intel Core Duo is shown below&lt;br /&gt;
&lt;br /&gt;
[[Image:intel_cache2.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; Intel Core Duo CMP Implementation]]&lt;br /&gt;
&lt;br /&gt;
This structure has the following changes when compared to the uniprocessor memory cluster structure. &lt;br /&gt;
* '''L1 cache''' and the '''processor/core''' structure is '''duplicated''' to give 2 cores.&lt;br /&gt;
* The '''Memory/L2 access control''' unit is '''split''' into 2 logical units: '''L2 controller''' and '''bus controller'''. The L2 controller handles all '''requests to the L2''' cache from the core and the snoop requests from the FSB. The '''bus controller''' handles '''data and I/O requests''' to and from the FSB.&lt;br /&gt;
* The '''prefetching''' unit is extended to handle the hardware '''prefetches for each core separately'''.&lt;br /&gt;
* A '''new logical unit''' (represented by the hexagon) was added to maintain '''fairness between the requests''' coming from the different cores and hence balance the requests to L2 and memory.&lt;br /&gt;
&lt;br /&gt;
This new '''partitioned structure''' for the  memory/L2 access control unit '''enhanced''' the '''performance''' while '''reducing power consumption'''. &lt;br /&gt;
For more information on uniprocessor and multiprocessor implementation under the Intel architecture, refer to &lt;br /&gt;
[http://www.intel.com/technology/itj/2006/volume10issue02/art02_CMP_Implementation/p03_implementation.htm CMP Implementation in Intel Core Duo Processors]&lt;br /&gt;
&lt;br /&gt;
The '''Intel bus architecture''' has been '''evolving''' in order to accommodate the demands of scalability while using the '''same [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol'''; From using a '''single shared bus''' to '''dual independent buses (DIB)''' doubling the available bandwidth and to the logical conclusion of DIB with the introduction of '''dedicated high-speed interconnects (DHSI)'''. The DHSI-based platforms use four FSBs, one for each processor in the platform. In both DIB and DHSI, the snoop filter was used in the chipset to cache snoop information, thereby significantly reducing the broadcasting needed for the snoop traffic on the buses. With the production of processors based on next generation 45-nm Hi-k Intel Core microarchitecture, the [http://en.wikipedia.org/wiki/Xeon Intel Xeon] processor fabric will transition from a DHSI, with the memory controller in the chipset, to a distributed shared memory architecture using '''Intel QuickPath Interconnects using MESIF protocol'''.&lt;br /&gt;
&lt;br /&gt;
==AMD - Advanced Micro Devices Processors==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===MOESI &amp;amp; AMD Processors===&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/Opteron AMD Opteron] was AMD’s first-generation dual core which had two distinct [http://en.wikipedia.org/wiki/Athlon_64 K8 cores] together on a single die. Cache coherence produces bigger problems on such multiprocessors. It was necessary to use an appropriate coherence protocol to address this problem. The [http://en.wikipedia.org/wiki/Xeon Intel Xeon], which was the competitive counterpart from Intel to AMD dual core Opteron, used the [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol to handle cache coherence. [http://en.wikipedia.org/wiki/MESI_protocol MESI] came with the drawback of using much time and bandwidth in certain situations. &lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/MOESI_protocol MOESI] was AMD’s answer to this problem. [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] added a fifth state to [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol called the '''owned''' state. [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] addresses the bandwidth problem faced in MESI protocol when processor having invalid data in its cache wants to modify the data.  The processor seeking the data access will have to wait for the processor which modified this data to write back to the main memory, which takes time and bandwidth. This drawback is removed in MOESI by allowing dirty sharing.  When the data is held by a processor in the new state '''owned''', it can provide other processors the modified data without or even before writing it to the main memory. This is called '''''dirty sharing'''''. The processor with the data in the '''owned''' state stays responsible to update the main memory later when the cache line is evicted.&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/MOESI_protocol MOESI]  has become one of the most popular snoop-based protocols supported in AMD64 architecture.  AMD dual-core Opteron can maintain cache coherence in systems up to 8 processors using this protocol.&lt;br /&gt;
&lt;br /&gt;
The five different states of [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol are:&lt;br /&gt;
* '''Modified (M)''': The most recent copy of the data is present in the cache line. But it is not present in any other processor cache.&lt;br /&gt;
* '''Owned (O)''': The cache line has the most recent correct copy of the data. This can be shared by other processors. The processor in this state for this cache line is responsible to update the correct value in the main memory before it gets evicted.&lt;br /&gt;
* '''Exclusive (E)''': A cache line holds the most recent, correct copy of the data, which is exclusively present on this processor and a copy is present in the main memory.&lt;br /&gt;
* '''Shared (S)''': A cache line in the shared state holds the most recent, correct copy of the data, which may be shared by other processors.&lt;br /&gt;
* '''Invalid (I)''': A cache line does not hold a valid copy of the data.&lt;br /&gt;
&lt;br /&gt;
A detailed explanation of this protocol implementation on AMD processor can be found in the manual [http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html Architecture of AMD 64-bit core]&lt;br /&gt;
&lt;br /&gt;
The following table summarizes the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''Cache Line State:'''&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  '''Owner''' &lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''This cache line is valid?'''&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  No&lt;br /&gt;
|-&lt;br /&gt;
|  '''The memory copy is…'''&lt;br /&gt;
|  out of date&lt;br /&gt;
|  out of date&lt;br /&gt;
|  valid&lt;br /&gt;
|  valid&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''Copies exist in caches of other processors?'''&lt;br /&gt;
|  No&lt;br /&gt;
|  No&lt;br /&gt;
|  Yes(out of date values)|  Maybe&lt;br /&gt;
|  Maybe&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''A write to this line'''&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  does not go to bus|  does not go to bus&lt;br /&gt;
|  goes to bus and updates cache&lt;br /&gt;
|  goes directly to bus&lt;br /&gt;
|  -&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 3:&amp;lt;/b&amp;gt; MOESI Protocol Summary&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
State transition for [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]is as shown below : &lt;br /&gt;
&lt;br /&gt;
[[Image:MOESI_State_Transition_Diagram.jpg|frame|center|&amp;lt;b&amp;gt;Figure 7:&amp;lt;/b&amp;gt; [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]State transition Diagram]]&lt;br /&gt;
&lt;br /&gt;
===AMD Opteron memory Architecture===&lt;br /&gt;
&lt;br /&gt;
[[Image:Untitled.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; AMD Opteron memory Architecture]]&lt;br /&gt;
&lt;br /&gt;
The AMD processor’s high-performance cache architecture includes an integrated, 64-bit, dual-ported  128-Kbyte split-L1 cache with separate snoop port, multi-level translation lookaside buffers (TLBs), a scalable L2 cache controller with a 72-bit (64-bit data + 8-bit ECC) interface to as much as 8-Mbyte of industry-standard SDR or DDR SRAMs, and an integrated tag for the most cost-effective 512-Kbyte L2 configurations. The AMD Athlon processor’s integrated L1 cache comprises two separate 64-Kbyte, two-way set-associative data and instruction caches.&lt;br /&gt;
&lt;br /&gt;
More information about this can be found in [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD 64 bit Architecture Programmers's Manual]&lt;br /&gt;
&lt;br /&gt;
===Special Coherence Considerations in AMD64 architectures===&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
Instruction prefetching is a technique used to speedup the execution of the program. But in multiprocessors, prefetching comes at the cost of performance. Due to prefetching, the data can be modified in such a way that the memory coherence protocol will not be able to handle the effects. In such situations software must use serializing instructions or cache-invalidation instructions to guarantee subsequent data accesses are coherent. &lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
An example of this type of a situation is a page-table update followed by accesses to the physical pages referenced by the updated page tables. The physical-memory references for the page tables are different than the physical-memory references for the data. Because of prefetching, there maybe problem with correctness. The following sequence of events shows such a situation when software changes the translation of virtual-page A from physical-page M to physical-page N:&lt;br /&gt;
# The tables that translate virtual-page A to physical-page M are now held only in main memory. The copies in the cache ae invalidated.&lt;br /&gt;
# Page-table entry is changed by the software for virtual-page A in main memory to point to physical page N rather than physical-page M.&lt;br /&gt;
# Data in virtual-page A is accessed.&lt;br /&gt;
&lt;br /&gt;
Software expects the processor to access the data from physical-page N after the update. However, it is possible for the processor to prefetch the data from physical-page M before the page table for virtual page A is updated. Because the physical-memory references are different, the processor does not recognize them as requiring coherence checking and believes it is safe to prefetch the data from virtual-page A, which is translated into a read from physical page M. Similar behavior can occur when instructions are prefetched from beyond the page table update instruction.&lt;br /&gt;
&lt;br /&gt;
In order to prevent errors from occuring, there are special instructions provided by software like INVLPG or MOV CR3 instruction which is executed immediately after the page-table update to ensure that subsequent instruction fetches and data accesses use the correct virtual-page-to-physical-page translation. It is not necessary to perform a TLB invalidation operation preceding the table update.&lt;br /&gt;
&lt;br /&gt;
More information can be found about this in [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD64 Architecture Programmer's manual]&lt;br /&gt;
&lt;br /&gt;
===Optimization techniques on MOESI when implemented on AMD Phenom processors===&lt;br /&gt;
&lt;br /&gt;
In real machines, using some optimization techniques on the standard cache coherence protocol used, improves the performance of the machine. For example, [http://en.wikipedia.org/wiki/AMD_Phenom AMD Phenom] family of microprocessors (Family 0×10) which is AMD’s first generation to incorporate 4 distinct cores on a single die. It is the first to have a cache that all the cores share, using the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol with some optimization techniques incorporated. &lt;br /&gt;
&lt;br /&gt;
It focuses on a small subset of compute problems which behave like Producer and Consumer programs. In such a computing problem, a thread of a program running on a single core produces data, which is consumed by a thread that is running on a separate core. With such programs, it is desirable to get the two distinct cores to communicate through the shared cache, to avoid round trips to/from main memory. The '''MOESI''' protocol that the [http://en.wikipedia.org/wiki/AMD_Phenom AMD Phenom] cache uses for cache coherence can also limit bandwidth. Hence by keeping the cache line in the '''M''' state for such computing problems, we can achieve better performance.&lt;br /&gt;
&lt;br /&gt;
When the producer thread , writes a new entry, it allocates cache-lines in the '''M''' state. Eventually, these M-marked cache lines will start to fill the L3 cache. When the consumer reads the cache line, the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol changes the state of the cache line to the '''O''' state in the L3 cache and pulls down a '''shared (S)''' copy for its own use. Now, the producer thread circles the ring buffer to arrive back to the same cache line it had previously written. However, when the producer attempts to write new data to the owned (marked '''‘O’''') cache line, it finds that it cannot, since a cache line in the '''O''' state by the previous consumer read does not have sufficient permission for a write request (in the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]). To maintain coherence, the memory controller must initiate probes in the other caches (to handle any other S copies that may exist). This will slow down the process.&lt;br /&gt;
&lt;br /&gt;
Thus, it is preferable to keep the cache line in the '''M''' state in the L3 cache. In such a situation, when the producer comes back around the ring buffer, it finds the previously written cache line still in the'''M''' state, to which it is safe to write without coherence concerns. Thus better performance can be achieved by such optimization techniques to standard protocols when implemented in real machines.&lt;br /&gt;
&lt;br /&gt;
You can find more information on how this is implemented and various other ways of optimizations in this manual [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf Software Optimization guide for AMD 10h Processors].&lt;br /&gt;
&lt;br /&gt;
==Xerox Corporation==&lt;br /&gt;
===Dragon Protocol &amp;amp; Xerox Dragon Processors===&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' is an update based coherence protocol which does not invalidate other cached copies like what we have seen in the coherence protocols so far. Write propagation is achieved by updating the cached copies instead of invalidating them.  But the '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' does not update memory on a cache to cache transfer and delays the memory and cache consistency until the data is evicted and written back, which saves time and lowers the memory access requirements. Moreover only the written '''byte''' or the '''word''' is '''communicated''' to the '''other caches''' instead of the whole block which further '''reduces''' the '''bandwidth''' usage. It has the ability to detect dynamically, the sharing status of a block and use a write through policy for shared blocks and write back for currently non-shared blocks. The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' employs the following four states for the cache blocks: '''Shared Clean''', '''Shared Modified''', '''Exclusive''', and  '''Modified'''. &lt;br /&gt;
* '''Modified (M)''' and '''Exclusive (E)''' - these states have the same meaning as explained in the protocols above. &lt;br /&gt;
* '''Shared Modified (Sm)''' - Only one cache line in the system can be in the Shared Modified state. Potentially two or more caches    have this block and memory may or may not be up to date and this processor's cache had modified the block.&lt;br /&gt;
* '''Shared Clean (Sc)''' -  Potentially two or more caches have this block and memory may or may not be up to date(if no other cache has it in Sm state, memory will be up to date else it is not).&lt;br /&gt;
When a Shared Modified line is evicted from the cache on a cache miss only then is the block written back to the main memory in order to keep memory consistent. For more information on Dragon protocol, refer to Solihin textbook, page number 229. The state transition diagram has been given below for reference.&lt;br /&gt;
&lt;br /&gt;
[[Image:Dragon.jpg|frame|center|&amp;lt;b&amp;gt;Figure 9:&amp;lt;/b&amp;gt; Dragon Protocol State Diagram]]&lt;br /&gt;
&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' , was developed by Xerox Palo Alto Research Center ('''[http://en.wikipedia.org/wiki/Xerox_PARC Xerox PARC]'''), a subsidiary of Xerox Corporation.  This protocol was used in the '''[http://en.wikipedia.org/w/index.php?title=Xerox_Dragon&amp;amp;redirect=no Xerox PARC Dragon]''' multiprocessor workstation, a VLSI research computer that could support multiple processors on a central high bandwidth memory bus. The Dragon design implemented snoopy caches that provided the appearance of a uniform memory space to multiple processors. Here, each cache listens to 2 buses: the processor bus and the memory bus. The caches are also responsible for address translation, so the processor bus carries virtual addresses and the memory bus carries physical addresses.  The Dragon system was designed to support 4 to 8 Dragon processors. The memory bus used in the Xeron Dragon evolved to become the '''[http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=289691 XDBus]''' , a low-cost, synchronous, '''packet-switched VLSI bus''' designed for use in high-performance multiprocessors. This was used as the interconnect in many multiprocessor server systems like '''Cray Superserver 6400''', '''Sun Microsystems' SPARCcenter 2000''' and '''SPARCserver 1000'''  and '''Sun4d''' systems.&lt;br /&gt;
&lt;br /&gt;
=Cache Coherence Power Utilization=&lt;br /&gt;
A number of studies have been performed to reduce the power consumption of cache coherence protocols. In order to perform a solid comparison between the cache coherency protocols, one would need to develop a multi-core processor for each of the cache coherency protocols. Additionally, the hardware and software configuration would also need to be similar between each system (except for the hardware required to implement each of the different protocols). Unfortunately, there are no such processors available. This section will discuss power consumption in general terms, comparing to each of the protocols. Also, this section will briefly discussion some power optimization techniques.&lt;br /&gt;
&lt;br /&gt;
Bus transactions, in general, are costly for both performance and power consumption. Additionally, studies have been performed showing that unnecessary snooping can waste power. Power requirements are typically determined by the number of bus snoops and number of bus accesses by each processor. One study indicates that interchip bus communications can consume up to 20% of total chip power[[#References|&amp;lt;sup&amp;gt;[20]&amp;lt;/sup&amp;gt;]].&lt;br /&gt;
Using the examples from the class notes, we can analyze the relative power consumption between the protocols. The following table is a summary of various protocols showing the number of bus communications that occur for each processor action.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|'''Processor Action'''&lt;br /&gt;
|'''MSI Bus Actions'''&lt;br /&gt;
|'''MESI Bus Actions'''&lt;br /&gt;
|'''Dragon Bus Actions'''&lt;br /&gt;
|'''FireFly Bus Actions'''&lt;br /&gt;
|-&lt;br /&gt;
|R1&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|-&lt;br /&gt;
|W1&lt;br /&gt;
|BusRdX&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R3&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|-&lt;br /&gt;
|W3&lt;br /&gt;
|BusRdX&lt;br /&gt;
|BusRdX&lt;br /&gt;
|BusUpd/Upd&lt;br /&gt;
|BusUpd&lt;br /&gt;
|-&lt;br /&gt;
|R1&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R3&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R2&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 4:&amp;lt;/b&amp;gt; Summary of Bus Actions for Select Protocols&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
From the table above, we can see that MSI has a larger number of bus transactions than the Dragon protocol. Even though bus transactions are not power efficient, snooping can also be enhanced to improve power efficiency. The following section will discuss snoop filtering techniques.&lt;br /&gt;
&lt;br /&gt;
==Power Savings Using Snoop Filtering==&lt;br /&gt;
A number of studies have been performed to reduce the number of unnecessary snoops during cache transactions. Two such filtering techniques are serial snooping and Jetty. The following sections will briefly discuss these two filtering techniques and power savings achieved using these techniques. Studies show that as much as 90% of snoop broadcasts will result in a miss[[#References|&amp;lt;sup&amp;gt;[19]&amp;lt;/sup&amp;gt;]] in the other caches at the same level and require that the information be provided by the next level of cache or memory. As much as a 36% savings in power by filtering snoops using one of the following snoop filtering methods[[#References|&amp;lt;sup&amp;gt;[19]&amp;lt;/sup&amp;gt;]].&lt;br /&gt;
===Serial Snooping===&lt;br /&gt;
Serial snooping takes advantage of the fact that if a miss occurs in one cache, it is possible to find the block in one other cache without having to check all the caches. If the cache block is available in multiple caches, there is a high probability that the cache miss can find the data in a nearby cache. Alternatively, savings can be realized by searching a subset of the caches vice all the caches. One thing to note is that this is only effective for read misses. Write, an invalidation transaction needs to be transmitted to the other caches, thus a bus transaction is unavoidable.&lt;br /&gt;
===Jetty===&lt;br /&gt;
Jetty is a mechanism attached to each cache that verifies that a bus snoop is necessary. Jetty is used to filter L2 tag lookups. When a processor needs to perform a bus snoop, the Jetty is checked first. The Jetty can determine if a cache tag lookup is required. Since the Jetty is much smaller than the associated cache, less power is required to determine if a snoop is required.&lt;br /&gt;
&lt;br /&gt;
There are a couple of different Jetty schemes. There is the exclude-Jetty, include-Jetty, and hybrid-Jetty. The exclude-Jetty exploits the fact that if a cache block is snooped, it is highly likely the same cache block will be snooped in the near future. The exclude-Jetty keeps track of the tag lookups in a small table and can determine if a cache tag lookup is necessary.&lt;br /&gt;
&lt;br /&gt;
The include-Jetty keeps a superset of the blocks that are cached. If a miss occurs in the include-Jetty, then it can be guaranteed that the block is not stored in its associated cache.&lt;br /&gt;
&lt;br /&gt;
The hybrid-Jetty is simply a combinations of and include and exclude-Jetty. Both types of Jetty are present and when a lookup occurs, both Jettys are checked to determine if a cache lookup is necessary.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Cache_coherence Cache coherence]&lt;br /&gt;
# [http://www.intel.com/technology/quickpath/introduction.pdf Introduction to QuickPath Interconnect]&lt;br /&gt;
# [http://www.intel.com/technology/itj/2006/volume10issue02/art02_CMP_Implementation/p03_implementation.htm CMP Implementation in Intel Core Duo Processors]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Symmetric_multiprocessing Common System Interface in Intel Processors]&lt;br /&gt;
# [http://www.zak.ict.pwr.wroc.pl/nikodem/ak_materialy/Cache%20consistency%20&amp;amp;%20MESI.pdf Cache consistency with MESI on Intel processor]&lt;br /&gt;
# [http://techreport.com/articles.x/8236/2 AMD dual core Architecture]&lt;br /&gt;
# [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD64 Architecture Programmer's manual]&lt;br /&gt;
# [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf Software Optimization guide for AMD 10h Processors]&lt;br /&gt;
# [http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html Architecture of AMD 64 bit core]&lt;br /&gt;
# [http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=4913 Silicon Graphics Computer Systems]&lt;br /&gt;
# [http://books.google.com/books?id=g82fofiqa5IC&amp;amp;printsec=frontcover&amp;amp;dq=Parallel+computer+architecture:+a+hardware/software+approach+By+David+E.+Culler,+Jaswinder+Pal+Singh,+Anoop+Gupta&amp;amp;source=bl&amp;amp;ots=COrdamlfVn&amp;amp;sig=YcugVqbzTjHvlofvaFq6Ft_tjfY&amp;amp;hl=en&amp;amp;ei=0ZO6S4TJGcOclgejzI3BBw&amp;amp;sa=X&amp;amp;oi=book_result&amp;amp;ct=result&amp;amp;resnum=1&amp;amp;ved=0CAgQ6AEwAA#v=onepage&amp;amp;q=&amp;amp;f=false Parallel computer architecture: a hardware/software approach By David E. Culler, Jaswinder Pal Singh, Anoop Gupta]&lt;br /&gt;
# [http://www.freepatentsonline.com/5283886.html Three state invalidation protocols]&lt;br /&gt;
# [http://portal.acm.org/citation.cfm?id=1499317&amp;amp;dl=GUIDE&amp;amp;coll=GUIDE&amp;amp;CFID=83027384&amp;amp;CFTOKEN=95680533 Synapse tightly coupled multiprocessors: a new approach to solve old problems]&lt;br /&gt;
# [http://portal.acm.org/citation.cfm?id=6514Cache Coherence protocols: evaluation using a multiprocessor simulation model]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Xerox_Dragon Xerox Dragon]&lt;br /&gt;
# [http://thanaseto.110mb.com/courses/CSD-527-report-engl.pdf Coherence Protocols]&lt;br /&gt;
# [http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=289691 XDBus]&lt;br /&gt;
# [http://www.ece.wisc.edu/~wddd/2002/final/ekman.pdf Evaluation of Snoop-Energy Reduction Techniques for Chip-Multiprocessors]&lt;br /&gt;
# [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.79.7463&amp;amp;rep=rep1&amp;amp;type=pdf Power Efficient Cache Coherence]&lt;/div&gt;</summary>
		<author><name>Mqtran</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2011/ch8_mc&amp;diff=44458</id>
		<title>CSC/ECE 506 Spring 2011/ch8 mc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2011/ch8_mc&amp;diff=44458"/>
		<updated>2011-03-19T21:22:34Z</updated>

		<summary type="html">&lt;p&gt;Mqtran: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Introduction to bus-based cache coherence in real machines=&lt;br /&gt;
&lt;br /&gt;
Most parallel software in the commercial market relies on the shared-memory&lt;br /&gt;
programming model in which all processors access the same physical address space. The most common multiprocessors today use [http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP] architecture which use a common bus as the interconnect.  In the case of multicore processors (&amp;quot;chip multiprocessors,&amp;quot; or CMP) the [http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP] architecture applies to the cores treating them as separate processors. The key problem of shared-memory multiprocessors is providing a consistent view of memory with various cache hierarchies.  This is called '''''cache coherence problem'''''. It is  critical to  achieve correctness and performance-sensitive design point for supporting the shared-memory model. The cache coherence mechanisms not only govern communication in a shared-memory multiprocessor, but also typically determine how the memory system transfers data between processors, caches, and memory.&lt;br /&gt;
&lt;br /&gt;
[[Image:Busbased SMP.jpg|frame|center|&amp;lt;b&amp;gt;Figure 1:&amp;lt;/b&amp;gt; Typical Bus-Based Processor Model]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Cache Coherence in real machines=&lt;br /&gt;
==Summary of Cache Coherence Protocols==&lt;br /&gt;
At any point in logical time, the permissions for a cache block can allow either a single writer or multiple readers. The '''''coherence protocol''''' ensures the invariants of the states are maintained. The different coherent states used by most of the cache coherent protocols are shown in ''Table 1'':&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''States'''&lt;br /&gt;
|  '''Access Type'''&lt;br /&gt;
|  '''Invariant'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  read, write&lt;br /&gt;
|  all other caches in I state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  read&lt;br /&gt;
|  all other caches in I state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Owned'''&lt;br /&gt;
|  read&lt;br /&gt;
|  all other caches in I or S state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  read&lt;br /&gt;
|  no other cache in M or E state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|  -&lt;br /&gt;
|  -&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 1:&amp;lt;/b&amp;gt; States Used by the Cache Coherent Protocols&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
The first widely adopted approach to cache coherence is snooping on a bus. We will now discuss them in details in the following sections.&lt;br /&gt;
&lt;br /&gt;
===MESI===&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI protocol]''' has a major drawback in that each read-write sequence incurs two bus transactions irrespective of whether the cache line is stored in only one cache or not. This is a huge setback for highly parallel programs that have little data sharing. '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol solves this problem by introducing the E ('''Exclusive''') state to distinguish between a cache line stored in multiple caches and a line stored in a single cache.&lt;br /&gt;
Let us briefly look at how the MESI protocol works. (For a more detailed version readers are referred to Solihin textbook pg. 215)&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' coherence protocol marks each cache line in one of the Modified, Exclusive, Shared or Invalid state. &lt;br /&gt;
* '''Invalid''' : The cache line is either not present or is invalid&lt;br /&gt;
* '''Exclusive''' : The cache line is clean and is owned by this core/processor only&lt;br /&gt;
* '''Modified''' :  This implies that the cache line is dirty and the core/processor has  exclusive ownership of the cache line, exclusive of the memory also.&lt;br /&gt;
* '''Shared''' : The cache line is clean and is shared by more than one core/processor&lt;br /&gt;
&lt;br /&gt;
In a nutshell, the '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol works as the following: &lt;br /&gt;
A line that is just fetched receives '''E''' or '''S''' state depending on whether it exists in other processors in the system or not. Similarly, a cache line gets the '''M''' state when a processor writes to it. If the line is not in '''E''' or '''M''' state prior to being written to, the cache sends a Bus Upgrade (BusUpgr) signal or as the Intel manuals call it, a “Read-For-Ownership (RFO) request” that ensures that the line exists in the cache and is in the '''I''' state in all other processors on the bus (if any). The table shown below will summarize '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''Cache Line State:'''&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''This cache line is valid?'''&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  No&lt;br /&gt;
|-&lt;br /&gt;
|  '''The memory copy is…'''&lt;br /&gt;
|  out of date&lt;br /&gt;
|  valid&lt;br /&gt;
|  valid&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''Copies exist in caches of other processors?'''  &lt;br /&gt;
|  No&lt;br /&gt;
|  No&lt;br /&gt;
|  Maybe&lt;br /&gt;
|  Maybe&lt;br /&gt;
|-&lt;br /&gt;
|  '''A write to this line'''&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  goes to bus and updates cache&lt;br /&gt;
|  goes directly to bus&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 2:&amp;lt;/b&amp;gt; MESI Protocol Summary&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The transition diagram from the lecture slides is given below for reference.&lt;br /&gt;
&lt;br /&gt;
[[Image:MESI.jpg|frame|center|&amp;lt;b&amp;gt;Figure 4:&amp;lt;/b&amp;gt; MESI State Diagram]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
We will now discuss how processor vendors like '''Intel''', '''AMD''' and others maintain cache coherence using '''''snooping based coherence protocols'''''.  For more information on snooping based protocols, readers are referred to Solihin textbook Chapter 8.&lt;br /&gt;
&lt;br /&gt;
==SGI - Silicon Graphics, Inc==&lt;br /&gt;
===MSI &amp;amp; SGI IRIS 4D Processors===&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' is a three-state write-back '''invalidation protocol''' which is one of the earliest snooping-based cache coherence-protocols. It marks the cache line in '''Modified (M) ,Shared (S)''', and '''Invalid (I)''' state. '''Invalid''' means the cache line is either not present or is invalid state. If the cache line is clean and is shared by more than one processor , it is marked '''shared'''. If cache line is dirty and the processor has exclusive ownership of the cache line, it is present in '''Modified''' state. BusRdx causes other processors to invalidate (demote) its cache block to the '''I''' state. If it is present in the '''M''' state in another cache, it will flush. BusRdx, even if hit in '''S''' state, is promoted to '''M''' (upgrade) state.&lt;br /&gt;
&lt;br /&gt;
The following state transition diagram for MSI protocol explains the working of the protocol:&lt;br /&gt;
&lt;br /&gt;
[[Image:MSI.jpg|frame|center|&amp;lt;b&amp;gt;Figure 2:&amp;lt;/b&amp;gt; MSI State Diagram]]&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' protocol was first used in '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''' IRIS 4D series. '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''' produced a broad range of '''[http://en.wikipedia.org/wiki/MIPS_architecture MIPS]'''-based (Microprocessor without Interlocked Pipeline Stages) workstations and servers during the 1990s, running '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''''s version of UNIX System V, now called '''[http://en.wikipedia.org/wiki/IRIX IRIX]'''. The 4D-MP graphics superworkstation brought 40 MIPS(million instructions per second) of computing performance to a graphics superworkstation. The unprecedented level of computing and graphics processing in an office-environment workstation was made possible by the fastest available Risc microprocessors in a single shared memory multiprocessor design driving a tightly coupled, highly parallel graphics system. Aggregate sustained data rates of over one gigabyte per second were achieved by a hierarchy of buses in a balanced system designed to avoid bottlenecks.&lt;br /&gt;
&lt;br /&gt;
The multiprocessor bus used in 4D-MP graphics superworkstation is a pipelined, block transfer bus that supports the cache coherence protocol as well as providing 64 megabytes of sustained data bandwidth between the processors, the memory and I/O system, and the graphics subsystem. Because the sync bus provides for efficient synchronization between processors, the cache coherence protocol was designed to support efficient data sharing between processors. If a cache coherence protocol has to support synchronization as well as sharing, a compromise in the efficiency of the data sharing protocol may be necessary to improve the efficiency of the synchronization operations. Hence it uses the simple cache coherence protocol which is the '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' protocol.&lt;br /&gt;
&lt;br /&gt;
With the simple rules of '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' enforced by the hardware protocols of&lt;br /&gt;
the sync bus and the Multiprocessor bus, efficient synchronization and efficient data sharing are achieved in a simple shared memory model of parallel processing in the 4D-MP graphics superworkstation.&lt;br /&gt;
&lt;br /&gt;
==SYNAPSE Multiprocessor==&lt;br /&gt;
===Synapse protocol and Synapse multiprocessor===&lt;br /&gt;
From the state transition diagram of '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''', we observe that for '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' there is transition to the '''S''' state from the '''M''' state when a BusRd is observed for that block. The contents of the block is flushed to the bus before going to '''S''' state. It would look more appropriate to move to the '''I''' state thus giving up the block entirely in certain cases. This choice of moving to '''S''' or '''I''' reflects the designer's assertion that the original processor is more likely to continue reading the block than the new processor to write to the block. In synapse protocol, used in the early Synapse multiprocessor, made this alternate choice of going directly from the '''M''' state to the '''I''' state on a BusRd, assuming the migratory pattern would be more frequent. More details about this protocol can be found in these papers published in late 1980's [http://portal.acm.org/citation.cfm?id=6514Cache Coherence protocols: evaluation using a multiprocessor simulation model] and [http://portal.acm.org/citation.cfm?id=1499317&amp;amp;dl=GUIDE&amp;amp;coll=GUIDE&amp;amp;CFID=83027384&amp;amp;CFTOKEN=95680533 Synapse tightly coupled multiprocessors: a new approach to solve old problems]&lt;br /&gt;
&lt;br /&gt;
In the Synapse protocol, the '''M''' state is called the '''D''' (Dirty) state. The following is the state transition diagram for Synapse protocol which clearly shows its working.&lt;br /&gt;
&lt;br /&gt;
[[Image:Synapse1.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; Synapse State Diagram]]&lt;br /&gt;
&lt;br /&gt;
==Intel==&lt;br /&gt;
===MESI &amp;amp; Intel Processors===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The '''Pentium Pro''' microprocessor, introduced in 1992 was the '''first''' Intel architecture microprocessor to support symmetric multiprocessing ('''[http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP]''') in various multiprocessor configurations. '''[http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP]''' and '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol was the architecture used consistently until the introduction of the 45-nm Hi-k Core micro-architecture in '''Intel's (Nehalem-EP) quad-core x86-64'''. The 45-nm Hi-k Intel Core microarchitecture utilizes a new system of framework called the '''QuickPath Interconnect''' which uses point-to-point interconnection technology based on distributed shared memory architecture. It uses a modified version of '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol called '''MESIF''', by introducing an additional state, F, the forward state. &lt;br /&gt;
&lt;br /&gt;
The '''Intel architecture''' uses the '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol  as the '''basis''' to ensure cache coherence, which is true whether you're on one of the older processors that use a '''common bus''' to communicate or using the new Intel '''QuickPath''' point-to-point interconnection technology. &lt;br /&gt;
&lt;br /&gt;
Let us now walk through a briefing on the '''MESIF protocol''':&lt;br /&gt;
&lt;br /&gt;
The '''MESIF''' protocol, used in the latest Intel multi-core processors was introduced to '''accommodate the point-to-point''' links used in the QuickPath Interconnect. Using the '''MESI''' protocol in this architecture would send many redundant messages between different processors, often with unnecessarily high latency. For example, when a processor requests a cache line that is stored in multiple locations, every location might respond with the data. As the the requesting processor only needs a single copy of the data, the system would be '''wasting the bandwidth'''. &lt;br /&gt;
As a '''solution''' to this problem, an additional state, '''Forward state''', was added by slightly changing the role of the Shared state. Whenever there is a read request, only the cache line in the F state will respond to the request, while all the S state caches remain dormant.  Hence, by designating a single cache line to '''respond to requests''', coherency traffic is substantially reduced when multiple copies of the data exist. Also, on a read request, the F state transitions from F to S state. That is, when a cache line in the '''F''' state is '''copied''', the F state '''migrates''' to the '''newer copy''', while the '''older''' one drops back to '''S'''. Moving the new copy to the F state '''exploits''' both '''temporal and spatial locality'''. Because the newest copy of the cache line is always in the F state, it is very unlikely that the line in the F state will be evicted from the caches. This takes advantage of the temporal locality of the request. The second advantage is that if a particular cache line is in high demand due to spatial locality, the bandwidth used to transmit that data will be spread across several nodes.&lt;br /&gt;
All M to S state transition and E to S state transitions will now be from '''M to F''' and '''E to F'''.  &lt;br /&gt;
The '''F state''' is '''different''' from the '''Owned state''' of the MOESI protocol as it is '''not''' a '''unique''' copy because a valid copy is stored in memory. Thus, unlike the Owned state of the MOESI protocol, in which the data in the O state is the only valid copy of the data, the data in the F state can be evicted or converted to the S state, if desired. &lt;br /&gt;
&lt;br /&gt;
More information on the QuickPath Interconnect and MESIF protocol can be found at&lt;br /&gt;
'''[http://www.intel.com/technology/quickpath/introduction.pdf Introduction to QuickPath Interconnect]'''&lt;br /&gt;
&lt;br /&gt;
=== CMP Implementation in Intel Architecture ===&lt;br /&gt;
&lt;br /&gt;
Let us now see how Intel architecture using the [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol progressed from a uniprocessor architecture to a Chip MultiProcessor (CMP) using the bus as the interconnect. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Uniprocessor Architecture'''&lt;br /&gt;
&lt;br /&gt;
The diagram below shows the structure of the memory cluster in Intel Pentium M processor.&lt;br /&gt;
&lt;br /&gt;
[[Image:intel_cache1.jpg|frame|center|&amp;lt;b&amp;gt;Figure 5:&amp;lt;/b&amp;gt; Memory Structure of the Pentium M Processor]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In this structure we have,&lt;br /&gt;
* A unified on-chip '''L1 cache''' with the '''processor/core''',&lt;br /&gt;
* A '''Memory/L2 access control unit''', through which all the accesses to the L2 cache, main memory and IO space are made,&lt;br /&gt;
* The second level '''L2 cache''' along with the '''prefetch unit''' and&lt;br /&gt;
* '''Front side bus (FSB)''', a single shared bi-directional bus through which all the traffic is sent across.These wide buses bring in multiple data bytes at a time. &lt;br /&gt;
&lt;br /&gt;
As Intel explains it, using this structure, the processor requests were first sought in the '''L2 cache''' and only on a '''miss''', were they '''forwarded''' to the main '''memory''' via the front side bus ('''FSB'''). The '''Memory/L2 access control''' unit served as a central point for '''maintaining coherence''' within the core and with the external world. It '''contains''' a '''snoop control unit''' that receives snoop requests from the bus and performs the required operations on each cache (and internal buffers) in parallel. It also handles RFO requests (BusUpgr) and ensures the operation continues only after it guarantees that no other version on the cache line exists in any other cache in the system.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''CMP Architecture'''&lt;br /&gt;
&lt;br /&gt;
For CMP implementation, Intel chose the bus-based architecture using snoopy protocols vs the '''directory protocol''' because though directory protocol reduces the active power due to reduced snoop activity, it '''increased''' the '''design complexity''' and the '''static power''' due to larger tag arrays. Since Intel has a large market for the processors in the mobility family, directory-based solution was less favorable since battery life mainly depends on static power consumption and less on dynamic power.&lt;br /&gt;
Let us examine how '''CMP''' was implemented in '''Intel Core Duo''', which was one of the first dual-core processor for the budget/entry-level market. &lt;br /&gt;
The general CMP implementation structure of the Intel Core Duo is shown below&lt;br /&gt;
&lt;br /&gt;
[[Image:intel_cache2.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; Intel Core Duo CMP Implementation]]&lt;br /&gt;
&lt;br /&gt;
This structure has the following changes when compared to the uniprocessor memory cluster structure. &lt;br /&gt;
* '''L1 cache''' and the '''processor/core''' structure is '''duplicated''' to give 2 cores.&lt;br /&gt;
* The '''Memory/L2 access control''' unit is '''split''' into 2 logical units: '''L2 controller''' and '''bus controller'''. The L2 controller handles all '''requests to the L2''' cache from the core and the snoop requests from the FSB. The '''bus controller''' handles '''data and I/O requests''' to and from the FSB.&lt;br /&gt;
* The '''prefetching''' unit is extended to handle the hardware '''prefetches for each core separately'''.&lt;br /&gt;
* A '''new logical unit''' (represented by the hexagon) was added to maintain '''fairness between the requests''' coming from the different cores and hence balance the requests to L2 and memory.&lt;br /&gt;
&lt;br /&gt;
This new '''partitioned structure''' for the  memory/L2 access control unit '''enhanced''' the '''performance''' while '''reducing power consumption'''. &lt;br /&gt;
For more information on uniprocessor and multiprocessor implementation under the Intel architecture, refer to &lt;br /&gt;
[http://www.intel.com/technology/itj/2006/volume10issue02/art02_CMP_Implementation/p03_implementation.htm CMP Implementation in Intel Core Duo Processors]&lt;br /&gt;
&lt;br /&gt;
The '''Intel bus architecture''' has been '''evolving''' in order to accommodate the demands of scalability while using the '''same [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol'''; From using a '''single shared bus''' to '''dual independent buses (DIB)''' doubling the available bandwidth and to the logical conclusion of DIB with the introduction of '''dedicated high-speed interconnects (DHSI)'''. The DHSI-based platforms use four FSBs, one for each processor in the platform. In both DIB and DHSI, the snoop filter was used in the chipset to cache snoop information, thereby significantly reducing the broadcasting needed for the snoop traffic on the buses. With the production of processors based on next generation 45-nm Hi-k Intel Core microarchitecture, the [http://en.wikipedia.org/wiki/Xeon Intel Xeon] processor fabric will transition from a DHSI, with the memory controller in the chipset, to a distributed shared memory architecture using '''Intel QuickPath Interconnects using MESIF protocol'''.&lt;br /&gt;
&lt;br /&gt;
==AMD - Advanced Micro Devices Processors==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===MOESI &amp;amp; AMD Processors===&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/Opteron AMD Opteron] was AMD’s first-generation dual core which had two distinct [http://en.wikipedia.org/wiki/Athlon_64 K8 cores] together on a single die. Cache coherence produces bigger problems on such multiprocessors. It was necessary to use an appropriate coherence protocol to address this problem. The [http://en.wikipedia.org/wiki/Xeon Intel Xeon], which was the competitive counterpart from Intel to AMD dual core Opteron, used the [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol to handle cache coherence. [http://en.wikipedia.org/wiki/MESI_protocol MESI] came with the drawback of using much time and bandwidth in certain situations. &lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/MOESI_protocol MOESI] was AMD’s answer to this problem. [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] added a fifth state to [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol called the '''owned''' state. [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] addresses the bandwidth problem faced in MESI protocol when processor having invalid data in its cache wants to modify the data.  The processor seeking the data access will have to wait for the processor which modified this data to write back to the main memory, which takes time and bandwidth. This drawback is removed in MOESI by allowing dirty sharing.  When the data is held by a processor in the new state '''owned''', it can provide other processors the modified data without or even before writing it to the main memory. This is called '''''dirty sharing'''''. The processor with the data in the '''owned''' state stays responsible to update the main memory later when the cache line is evicted.&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/MOESI_protocol MOESI]  has become one of the most popular snoop-based protocols supported in AMD64 architecture.  AMD dual-core Opteron can maintain cache coherence in systems up to 8 processors using this protocol.&lt;br /&gt;
&lt;br /&gt;
The five different states of [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol are:&lt;br /&gt;
* '''Modified (M)''': The most recent copy of the data is present in the cache line. But it is not present in any other processor cache.&lt;br /&gt;
* '''Owned (O)''': The cache line has the most recent correct copy of the data. This can be shared by other processors. The processor in this state for this cache line is responsible to update the correct value in the main memory before it gets evicted.&lt;br /&gt;
* '''Exclusive (E)''': A cache line holds the most recent, correct copy of the data, which is exclusively present on this processor and a copy is present in the main memory.&lt;br /&gt;
* '''Shared (S)''': A cache line in the shared state holds the most recent, correct copy of the data, which may be shared by other processors.&lt;br /&gt;
* '''Invalid (I)''': A cache line does not hold a valid copy of the data.&lt;br /&gt;
&lt;br /&gt;
A detailed explanation of this protocol implementation on AMD processor can be found in the manual [http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html Architecture of AMD 64-bit core]&lt;br /&gt;
&lt;br /&gt;
The following table summarizes the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''Cache Line State:'''&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  '''Owner''' &lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''This cache line is valid?'''&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  No&lt;br /&gt;
|-&lt;br /&gt;
|  '''The memory copy is…'''&lt;br /&gt;
|  out of date&lt;br /&gt;
|  out of date&lt;br /&gt;
|  valid&lt;br /&gt;
|  valid&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''Copies exist in caches of other processors?'''&lt;br /&gt;
|  No&lt;br /&gt;
|  No&lt;br /&gt;
|  Yes(out of date values)|  Maybe&lt;br /&gt;
|  Maybe&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''A write to this line'''&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  does not go to bus|  does not go to bus&lt;br /&gt;
|  goes to bus and updates cache&lt;br /&gt;
|  goes directly to bus&lt;br /&gt;
|  -&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 3:&amp;lt;/b&amp;gt; MOESI Protocol Summary&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
State transition for [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]is as shown below : &lt;br /&gt;
&lt;br /&gt;
[[Image:MOESI_State_Transition_Diagram.jpg|frame|center|&amp;lt;b&amp;gt;Figure 7:&amp;lt;/b&amp;gt; [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]State transition Diagram]]&lt;br /&gt;
&lt;br /&gt;
===AMD Opteron memory Architecture===&lt;br /&gt;
&lt;br /&gt;
[[Image:Untitled.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; AMD Opteron memory Architecture]]&lt;br /&gt;
&lt;br /&gt;
The AMD processor’s high-performance cache architecture includes an integrated, 64-bit, dual-ported  128-Kbyte split-L1 cache with separate snoop port, multi-level translation lookaside buffers (TLBs), a scalable L2 cache controller with a 72-bit (64-bit data + 8-bit ECC) interface to as much as 8-Mbyte of industry-standard SDR or DDR SRAMs, and an integrated tag for the most cost-effective 512-Kbyte L2 configurations. The AMD Athlon processor’s integrated L1 cache comprises two separate 64-Kbyte, two-way set-associative data and instruction caches.&lt;br /&gt;
&lt;br /&gt;
More information about this can be found in [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD 64 bit Architecture Programmers's Manual]&lt;br /&gt;
&lt;br /&gt;
===Special Coherence Considerations in AMD64 architectures===&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
Instruction prefetching is a technique used to speedup the execution of the program. But in multiprocessors, prefetching comes at the cost of performance. Due to prefetching, the data can be modified in such a way that the memory coherence protocol will not be able to handle the effects. In such situations software must use serializing instructions or cache-invalidation instructions to guarantee subsequent data accesses are coherent. &lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
An example of this type of a situation is a page-table update followed by accesses to the physical pages referenced by the updated page tables. The physical-memory references for the page tables are different than the physical-memory references for the data. Because of prefetching, there maybe problem with correctness. The following sequence of events shows such a situation when software changes the translation of virtual-page A from physical-page M to physical-page N:&lt;br /&gt;
# The tables that translate virtual-page A to physical-page M are now held only in main memory. The copies in the cache ae invalidated.&lt;br /&gt;
# Page-table entry is changed by the software for virtual-page A in main memory to point to physical page N rather than physical-page M.&lt;br /&gt;
# Data in virtual-page A is accessed.&lt;br /&gt;
&lt;br /&gt;
Software expects the processor to access the data from physical-page N after the update. However, it is possible for the processor to prefetch the data from physical-page M before the page table for virtual page A is updated. Because the physical-memory references are different, the processor does not recognize them as requiring coherence checking and believes it is safe to prefetch the data from virtual-page A, which is translated into a read from physical page M. Similar behavior can occur when instructions are prefetched from beyond the page table update instruction.&lt;br /&gt;
&lt;br /&gt;
In order to prevent errors from occuring, there are special instructions provided by software like INVLPG or MOV CR3 instruction which is executed immediately after the page-table update to ensure that subsequent instruction fetches and data accesses use the correct virtual-page-to-physical-page translation. It is not necessary to perform a TLB invalidation operation preceding the table update.&lt;br /&gt;
&lt;br /&gt;
More information can be found about this in [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD64 Architecture Programmer's manual]&lt;br /&gt;
&lt;br /&gt;
===Optimization techniques on MOESI when implemented on AMD Phenom processors===&lt;br /&gt;
&lt;br /&gt;
In real machines, using some optimization techniques on the standard cache coherence protocol used, improves the performance of the machine. For example, [http://en.wikipedia.org/wiki/AMD_Phenom AMD Phenom] family of microprocessors (Family 0×10) which is AMD’s first generation to incorporate 4 distinct cores on a single die. It is the first to have a cache that all the cores share, using the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol with some optimization techniques incorporated. &lt;br /&gt;
&lt;br /&gt;
It focuses on a small subset of compute problems which behave like Producer and Consumer programs. In such a computing problem, a thread of a program running on a single core produces data, which is consumed by a thread that is running on a separate core. With such programs, it is desirable to get the two distinct cores to communicate through the shared cache, to avoid round trips to/from main memory. The '''MOESI''' protocol that the [http://en.wikipedia.org/wiki/AMD_Phenom AMD Phenom] cache uses for cache coherence can also limit bandwidth. Hence by keeping the cache line in the '''M''' state for such computing problems, we can achieve better performance.&lt;br /&gt;
&lt;br /&gt;
When the producer thread , writes a new entry, it allocates cache-lines in the '''M''' state. Eventually, these M-marked cache lines will start to fill the L3 cache. When the consumer reads the cache line, the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol changes the state of the cache line to the '''O''' state in the L3 cache and pulls down a '''shared (S)''' copy for its own use. Now, the producer thread circles the ring buffer to arrive back to the same cache line it had previously written. However, when the producer attempts to write new data to the owned (marked '''‘O’''') cache line, it finds that it cannot, since a cache line in the '''O''' state by the previous consumer read does not have sufficient permission for a write request (in the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]). To maintain coherence, the memory controller must initiate probes in the other caches (to handle any other S copies that may exist). This will slow down the process.&lt;br /&gt;
&lt;br /&gt;
Thus, it is preferable to keep the cache line in the '''M''' state in the L3 cache. In such a situation, when the producer comes back around the ring buffer, it finds the previously written cache line still in the'''M''' state, to which it is safe to write without coherence concerns. Thus better performance can be achieved by such optimization techniques to standard protocols when implemented in real machines.&lt;br /&gt;
&lt;br /&gt;
You can find more information on how this is implemented and various other ways of optimizations in this manual [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf Software Optimization guide for AMD 10h Processors].&lt;br /&gt;
&lt;br /&gt;
==Xerox Corporation==&lt;br /&gt;
===Dragon Protocol &amp;amp; Xerox Dragon Processors===&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' is an update based coherence protocol which does not invalidate other cached copies like what we have seen in the coherence protocols so far. Write propagation is achieved by updating the cached copies instead of invalidating them.  But the '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' does not update memory on a cache to cache transfer and delays the memory and cache consistency until the data is evicted and written back, which saves time and lowers the memory access requirements. Moreover only the written '''byte''' or the '''word''' is '''communicated''' to the '''other caches''' instead of the whole block which further '''reduces''' the '''bandwidth''' usage. It has the ability to detect dynamically, the sharing status of a block and use a write through policy for shared blocks and write back for currently non-shared blocks. The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' employs the following four states for the cache blocks: '''Shared Clean''', '''Shared Modified''', '''Exclusive''', and  '''Modified'''. &lt;br /&gt;
* '''Modified (M)''' and '''Exclusive (E)''' - these states have the same meaning as explained in the protocols above. &lt;br /&gt;
* '''Shared Modified (Sm)''' - Only one cache line in the system can be in the Shared Modified state. Potentially two or more caches    have this block and memory may or may not be up to date and this processor's cache had modified the block.&lt;br /&gt;
* '''Shared Clean (Sc)''' -  Potentially two or more caches have this block and memory may or may not be up to date(if no other cache has it in Sm state, memory will be up to date else it is not).&lt;br /&gt;
When a Shared Modified line is evicted from the cache on a cache miss only then is the block written back to the main memory in order to keep memory consistent. For more information on Dragon protocol, refer to Solihin textbook, page number 229. The state transition diagram has been given below for reference.&lt;br /&gt;
&lt;br /&gt;
[[Image:Dragon.jpg|frame|center|&amp;lt;b&amp;gt;Figure 9:&amp;lt;/b&amp;gt; Dragon Protocol State Diagram]]&lt;br /&gt;
&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' , was developed by Xerox Palo Alto Research Center ('''[http://en.wikipedia.org/wiki/Xerox_PARC Xerox PARC]'''), a subsidiary of Xerox Corporation.  This protocol was used in the '''[http://en.wikipedia.org/w/index.php?title=Xerox_Dragon&amp;amp;redirect=no Xerox PARC Dragon]''' multiprocessor workstation, a VLSI research computer that could support multiple processors on a central high bandwidth memory bus. The Dragon design implemented snoopy caches that provided the appearance of a uniform memory space to multiple processors. Here, each cache listens to 2 buses: the processor bus and the memory bus. The caches are also responsible for address translation, so the processor bus carries virtual addresses and the memory bus carries physical addresses.  The Dragon system was designed to support 4 to 8 Dragon processors. The memory bus used in the Xeron Dragon evolved to become the '''[http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=289691 XDBus]''' , a low-cost, synchronous, '''packet-switched VLSI bus''' designed for use in high-performance multiprocessors. This was used as the interconnect in many multiprocessor server systems like '''Cray Superserver 6400''', '''Sun Microsystems' SPARCcenter 2000''' and '''SPARCserver 1000'''  and '''Sun4d''' systems.&lt;br /&gt;
&lt;br /&gt;
=Cache Coherence Power Utilization=&lt;br /&gt;
A number of studies have been performed to reduce the power consumption of cache coherence protocols. In order to perform a solid comparison between the cache coherency protocols, one would need to develop a multi-core processor for each of the cache coherency protocols. Additionally, the hardware and software configuration would also need to be similar between each system (except for the hardware required to implement each of the different protocols). Unfortunately, there are no such processors available. This section will discuss power consumption in general terms, comparing to each of the protocols. Also, this section will briefly discussion some power optimization techniques.&lt;br /&gt;
&lt;br /&gt;
Bus transactions, in general, are costly for both performance and power consumption. Additionally, studies have been performed showing that unnecessary snooping can waste power. Power requirements are typically determined by the number of bus snoops and number of bus accesses by each processor. One study indicates that interchip bus communications can consume up to 20% of total chip power[[#References|&amp;lt;sup&amp;gt;[20]&amp;lt;/sup&amp;gt;]].&lt;br /&gt;
Using the examples from the class notes, we can analyze the relative power consumption between the protocols. The following table is a summary of various protocols showing the number of bus communications that occur for each processor action.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|'''Processor Action'''&lt;br /&gt;
|'''MSI Bus Actions'''&lt;br /&gt;
|'''MESI Bus Actions'''&lt;br /&gt;
|'''Dragon Bus Actions'''&lt;br /&gt;
|'''FireFly Bus Actions'''&lt;br /&gt;
|-&lt;br /&gt;
|R1&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|-&lt;br /&gt;
|W1&lt;br /&gt;
|BusRdX&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R3&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|-&lt;br /&gt;
|W3&lt;br /&gt;
|BusRdX&lt;br /&gt;
|BusRdX&lt;br /&gt;
|BusUpd/Upd&lt;br /&gt;
|BusUpd&lt;br /&gt;
|-&lt;br /&gt;
|R1&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R3&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R2&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 4:&amp;lt;/b&amp;gt; Summary of Bus Actions for Select Protocols&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
From the table above, we can see that MSI has a larger number of bus transactions than the Dragon protocol. Even though bus transactions are not power efficient, snooping can also be enhanced to improve power efficiency. The following section will discuss snoop filtering techniques.&lt;br /&gt;
&lt;br /&gt;
==Power Savings Using Snoop Filtering==&lt;br /&gt;
A number of studies have been performed to reduce the number of unnecessary snoops during cache transactions. Two such filtering techniques are serial snooping and Jetty. The following sections will briefly discuss these two filtering techniques and power savings achieved using these techniques. Studies show that as much as 90% of snoop broadcasts will result in a miss[[#References|&amp;lt;sup&amp;gt;[19]&amp;lt;/sup&amp;gt;]] in the other caches at the same level and require that the information be provided by the next level of cache or memory. As much as a 36% savings in power by filtering snoops using one of the following snoop filtering methods[[#References|&amp;lt;sup&amp;gt;[19]&amp;lt;/sup&amp;gt;]].&lt;br /&gt;
===Serial Snooping===&lt;br /&gt;
Serial snooping takes advantage of the fact that if a miss occurs in one cache, it is possible to find the block in one other cache without having to check all the caches. If the cache block is available in multiple caches, there is a high probability that the cache miss can find the data in a nearby cache. Alternatively, savings can be realized by searching a subset of the caches vice all the caches. One thing to note is that this is only effective for read misses. Write, an invalidation transaction needs to be transmitted to the other caches, thus a bus transaction is unavoidable.&lt;br /&gt;
===Jetty===&lt;br /&gt;
Jetty is a mechanism attached to each cache that verifies that a bus snoop is necessary. Jetty is used to filter L2 tag lookups. When a processor needs to perform a bus snoop, the Jetty is checked first. The Jetty can determine if a cache tag lookup is required. Since the Jetty is much smaller than the associated cache, less power is required to determine if a snoop is required.&lt;br /&gt;
&lt;br /&gt;
There are a couple of different Jetty schemes. There is the exclude-Jetty, include-Jetty, and hybrid-Jetty. The exclude-Jetty exploits the fact that if a cache block is snooped, it is highly likely the same cache block will be snooped in the near future. The exclude-Jetty keeps track of the tag lookups in a small table and can determine if a cache tag lookup is necessary.&lt;br /&gt;
&lt;br /&gt;
The include-Jetty keeps a superset of the blocks that are cached. If a miss occurs in the include-Jetty, then it can be guaranteed that the block is not stored in its associated cache.&lt;br /&gt;
&lt;br /&gt;
The hybrid-Jetty is simply a combinations of and include and exclude-Jetty. Both types of Jetty are present and when a lookup occurs, both Jettys are checked to determine if a cache lookup is necessary.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Cache_coherence Cache coherence]&lt;br /&gt;
# [http://www.intel.com/technology/quickpath/introduction.pdf Introduction to QuickPath Interconnect]&lt;br /&gt;
# [http://www.intel.com/technology/itj/2006/volume10issue02/art02_CMP_Implementation/p03_implementation.htm CMP Implementation in Intel Core Duo Processors]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Symmetric_multiprocessing Common System Interface in Intel Processors]&lt;br /&gt;
# [http://www.zak.ict.pwr.wroc.pl/nikodem/ak_materialy/Cache%20consistency%20&amp;amp;%20MESI.pdf Cache consistency with MESI on Intel processor]&lt;br /&gt;
# [http://techreport.com/articles.x/8236/2 AMD dual core Architecture]&lt;br /&gt;
# [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD64 Architecture Programmer's manual]&lt;br /&gt;
# [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf Software Optimization guide for AMD 10h Processors]&lt;br /&gt;
# [http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html Architecture of AMD 64 bit core]&lt;br /&gt;
# [http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=4913 Silicon Graphics Computer Systems]&lt;br /&gt;
# [http://books.google.com/books?id=g82fofiqa5IC&amp;amp;printsec=frontcover&amp;amp;dq=Parallel+computer+architecture:+a+hardware/software+approach+By+David+E.+Culler,+Jaswinder+Pal+Singh,+Anoop+Gupta&amp;amp;source=bl&amp;amp;ots=COrdamlfVn&amp;amp;sig=YcugVqbzTjHvlofvaFq6Ft_tjfY&amp;amp;hl=en&amp;amp;ei=0ZO6S4TJGcOclgejzI3BBw&amp;amp;sa=X&amp;amp;oi=book_result&amp;amp;ct=result&amp;amp;resnum=1&amp;amp;ved=0CAgQ6AEwAA#v=onepage&amp;amp;q=&amp;amp;f=false Parallel computer architecture: a hardware/software approach By David E. Culler, Jaswinder Pal Singh, Anoop Gupta]&lt;br /&gt;
# [http://www.freepatentsonline.com/5283886.html Three state invalidation protocols]&lt;br /&gt;
# [http://portal.acm.org/citation.cfm?id=1499317&amp;amp;dl=GUIDE&amp;amp;coll=GUIDE&amp;amp;CFID=83027384&amp;amp;CFTOKEN=95680533 Synapse tightly coupled multiprocessors: a new approach to solve old problems]&lt;br /&gt;
# [http://portal.acm.org/citation.cfm?id=6514Cache Coherence protocols: evaluation using a multiprocessor simulation model]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Xerox_Dragon Xerox Dragon]&lt;br /&gt;
# [http://thanaseto.110mb.com/courses/CSD-527-report-engl.pdf Coherence Protocols]&lt;br /&gt;
# [http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=289691 XDBus]&lt;br /&gt;
# [http://www.ece.wisc.edu/~wddd/2002/final/ekman.pdf Evaluation of Snoop-Energy Reduction Techniques for Chip-Multiprocessors]&lt;br /&gt;
# [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.79.7463&amp;amp;rep=rep1&amp;amp;type=pdf Power Efficient Cache Coherence]&lt;/div&gt;</summary>
		<author><name>Mqtran</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2011/ch8_mc&amp;diff=44456</id>
		<title>CSC/ECE 506 Spring 2011/ch8 mc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2011/ch8_mc&amp;diff=44456"/>
		<updated>2011-03-19T20:34:38Z</updated>

		<summary type="html">&lt;p&gt;Mqtran: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Introduction to bus-based cache coherence in real machines=&lt;br /&gt;
&lt;br /&gt;
Most parallel software in the commercial market relies on the shared-memory&lt;br /&gt;
programming model in which all processors access the same physical address space. The most common multiprocessors today use [http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP] architecture which use a common bus as the interconnect.  In the case of multicore processors (&amp;quot;chip multiprocessors,&amp;quot; or CMP) the [http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP] architecture applies to the cores treating them as separate processors. The key problem of shared-memory multiprocessors is providing a consistent view of memory with various cache hierarchies.  This is called '''''cache coherence problem'''''. It is  critical to  achieve correctness and performance-sensitive design point for supporting the shared-memory model. The cache coherence mechanisms not only govern communication in a shared-memory multiprocessor, but also typically determine how the memory system transfers data between processors, caches, and memory.&lt;br /&gt;
&lt;br /&gt;
[[Image:Busbased SMP.jpg|frame|center|&amp;lt;b&amp;gt;Figure 1:&amp;lt;/b&amp;gt; Typical Bus-Based Processor Model]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Cache Coherence in real machines=&lt;br /&gt;
==Summary of Cache Coherence Protocols==&lt;br /&gt;
At any point in logical time, the permissions for a cache block can allow either a single writer or multiple readers. The '''''coherence protocol''''' ensures the invariants of the states are maintained. The different coherent states used by most of the cache coherent protocols are shown in ''Table 1'':&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''States'''&lt;br /&gt;
|  '''Access Type'''&lt;br /&gt;
|  '''Invariant'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  read, write&lt;br /&gt;
|  all other caches in I state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  read&lt;br /&gt;
|  all other caches in I state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Owned'''&lt;br /&gt;
|  read&lt;br /&gt;
|  all other caches in I or S state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  read&lt;br /&gt;
|  no other cache in M or E state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|  -&lt;br /&gt;
|  -&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 1:&amp;lt;/b&amp;gt; States Used by the Cache Coherent Protocols&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
The first widely adopted approach to cache coherence is snooping on a bus. We will now discuss them in details in the following sections.&lt;br /&gt;
&lt;br /&gt;
===MESI===&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI protocol]''' has a major drawback in that each read-write sequence incurs two bus transactions irrespective of whether the cache line is stored in only one cache or not. This is a huge setback for highly parallel programs that have little data sharing. '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol solves this problem by introducing the E ('''Exclusive''') state to distinguish between a cache line stored in multiple caches and a line stored in a single cache.&lt;br /&gt;
Let us briefly look at how the MESI protocol works. (For a more detailed version readers are referred to Solihin textbook pg. 215)&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' coherence protocol marks each cache line in one of the Modified, Exclusive, Shared or Invalid state. &lt;br /&gt;
* '''Invalid''' : The cache line is either not present or is invalid&lt;br /&gt;
* '''Exclusive''' : The cache line is clean and is owned by this core/processor only&lt;br /&gt;
* '''Modified''' :  This implies that the cache line is dirty and the core/processor has  exclusive ownership of the cache line, exclusive of the memory also.&lt;br /&gt;
* '''Shared''' : The cache line is clean and is shared by more than one core/processor&lt;br /&gt;
&lt;br /&gt;
In a nutshell, the '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol works as the following: &lt;br /&gt;
A line that is just fetched receives '''E''' or '''S''' state depending on whether it exists in other processors in the system or not. Similarly, a cache line gets the '''M''' state when a processor writes to it. If the line is not in '''E''' or '''M''' state prior to being written to , the cache sends a Bus Upgrade (BusUpgr) signal or as the Intel manuals term it, “Read-For-Ownership (RFO) request” that ensures that the line exists in the cache and is in the '''I''' state in all other processors on the bus (if any). The table is shown below to summarize '''[http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol'''.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''Cache Line State:'''&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''This cache line is valid?'''&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  No&lt;br /&gt;
|-&lt;br /&gt;
|  '''The memory copy is…'''&lt;br /&gt;
|  out of date&lt;br /&gt;
|  valid&lt;br /&gt;
|  valid&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''Copies exist in caches of other processors?'''|  No&lt;br /&gt;
|  No&lt;br /&gt;
|  Maybe&lt;br /&gt;
|  Maybe&lt;br /&gt;
|-&lt;br /&gt;
|  '''A write to this line'''|  does not go to bus&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  goes to bus and updates cache&lt;br /&gt;
|  goes directly to bus&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 2:&amp;lt;/b&amp;gt; MESI Protocol Summary&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The transition diagram from the lecture slides is given below for reference.&lt;br /&gt;
&lt;br /&gt;
[[Image:MESI.jpg|frame|center|&amp;lt;b&amp;gt;Figure 4:&amp;lt;/b&amp;gt; MESI State Diagram]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
We will now discuss how processor vendors like '''Intel''', '''AMD''' and others maintain cache coherence using '''''snooping based coherence protocols'''''.  For more information on snooping based protocols, readers are referred to Solihin textbook Chapter 8.&lt;br /&gt;
&lt;br /&gt;
==SGI - Silicon Graphics, Inc==&lt;br /&gt;
===MSI &amp;amp; SGI IRIS 4D Processors===&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' is a three-state write-back '''invalidation protocol''' which is one of the earliest snooping-based cache coherence-protocols. It marks the cache line in '''Modified (M) ,Shared (S)''', and '''Invalid (I)''' state. '''Invalid''' means the cache line is either not present or is invalid state. If the cache line is clean and is shared by more than one processor , it is marked '''shared'''. If cache line is dirty and the processor has exclusive ownership of the cache line, it is present in '''Modified''' state. BusRdx causes other processors to invalidate (demote) its cache block to the '''I''' state. If it is present in the '''M''' state in another cache, it will flush. BusRdx, even if hit in '''S''' state, is promoted to '''M''' (upgrade) state.&lt;br /&gt;
&lt;br /&gt;
The following state transition diagram for MSI protocol explains the working of the protocol:&lt;br /&gt;
&lt;br /&gt;
[[Image:MSI.jpg|frame|center|&amp;lt;b&amp;gt;Figure 2:&amp;lt;/b&amp;gt; MSI State Diagram]]&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' protocol was first used in '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''' IRIS 4D series. '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''' produced a broad range of '''[http://en.wikipedia.org/wiki/MIPS_architecture MIPS]'''-based (Microprocessor without Interlocked Pipeline Stages) workstations and servers during the 1990s, running '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''''s version of UNIX System V, now called '''[http://en.wikipedia.org/wiki/IRIX IRIX]'''. The 4D-MP graphics superworkstation brought 40 MIPS(million instructions per second) of computing performance to a graphics superworkstation. The unprecedented level of computing and graphics processing in an office-environment workstation was made possible by the fastest available Risc microprocessors in a single shared memory multiprocessor design driving a tightly coupled, highly parallel graphics system. Aggregate sustained data rates of over one gigabyte per second were achieved by a hierarchy of buses in a balanced system designed to avoid bottlenecks.&lt;br /&gt;
&lt;br /&gt;
The multiprocessor bus used in 4D-MP graphics superworkstation is a pipelined, block transfer bus that supports the cache coherence protocol as well as providing 64 megabytes of sustained data bandwidth between the processors, the memory and I/O system, and the graphics subsystem. Because the sync bus provides for efficient synchronization between processors, the cache coherence protocol was designed to support efficient data sharing between processors. If a cache coherence protocol has to support synchronization as well as sharing, a compromise in the efficiency of the data sharing protocol may be necessary to improve the efficiency of the synchronization operations. Hence it uses the simple cache coherence protocol which is the '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' protocol.&lt;br /&gt;
&lt;br /&gt;
With the simple rules of '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' enforced by the hardware protocols of&lt;br /&gt;
the sync bus and the Multiprocessor bus, efficient synchronization and efficient data sharing are achieved in a simple shared memory model of parallel processing in the 4D-MP graphics superworkstation.&lt;br /&gt;
&lt;br /&gt;
==SYNAPSE Multiprocessor==&lt;br /&gt;
===Synapse protocol and Synapse multiprocessor===&lt;br /&gt;
From the state transition diagram of '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''', we observe that for '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' there is transition to the '''S''' state from the '''M''' state when a BusRd is observed for that block. The contents of the block is flushed to the bus before going to '''S''' state. It would look more appropriate to move to the '''I''' state thus giving up the block entirely in certain cases. This choice of moving to '''S''' or '''I''' reflects the designer's assertion that the original processor is more likely to continue reading the block than the new processor to write to the block. In synapse protocol, used in the early Synapse multiprocessor, made this alternate choice of going directly from the '''M''' state to the '''I''' state on a BusRd, assuming the migratory pattern would be more frequent. More details about this protocol can be found in these papers published in late 1980's [http://portal.acm.org/citation.cfm?id=6514Cache Coherence protocols: evaluation using a multiprocessor simulation model] and [http://portal.acm.org/citation.cfm?id=1499317&amp;amp;dl=GUIDE&amp;amp;coll=GUIDE&amp;amp;CFID=83027384&amp;amp;CFTOKEN=95680533 Synapse tightly coupled multiprocessors: a new approach to solve old problems]&lt;br /&gt;
&lt;br /&gt;
In the Synapse protocol, the '''M''' state is called the '''D''' (Dirty) state. The following is the state transition diagram for Synapse protocol which clearly shows its working.&lt;br /&gt;
&lt;br /&gt;
[[Image:Synapse1.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; Synapse State Diagram]]&lt;br /&gt;
&lt;br /&gt;
==Intel==&lt;br /&gt;
===MESI &amp;amp; Intel Processors===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The '''Pentium Pro''' microprocessor, introduced in 1992 was the '''first''' Intel architecture microprocessor to support symmetric multiprocessing ('''[http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP]''') in various multiprocessor configurations. '''[http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP]''' and '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol was the architecture used consistently until the introduction of the 45-nm Hi-k Core micro-architecture in '''Intel's (Nehalem-EP) quad-core x86-64'''. The 45-nm Hi-k Intel Core microarchitecture utilizes a new system of framework called the '''QuickPath Interconnect''' which uses point-to-point interconnection technology based on distributed shared memory architecture. It uses a modified version of '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol called '''MESIF''', by introducing an additional state, F, the forward state. &lt;br /&gt;
&lt;br /&gt;
The '''Intel architecture''' uses the '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol  as the '''basis''' to ensure cache coherence, which is true whether you're on one of the older processors that use a '''common bus''' to communicate or using the new Intel '''QuickPath''' point-to-point interconnection technology. &lt;br /&gt;
&lt;br /&gt;
Let us now walk through a briefing on the '''MESIF protocol''':&lt;br /&gt;
&lt;br /&gt;
The '''MESIF''' protocol, used in the latest Intel multi-core processors was introduced to '''accommodate the point-to-point''' links used in the QuickPath Interconnect. Using the '''MESI''' protocol in this architecture would send many redundant messages between different processors, often with unnecessarily high latency. For example, when a processor requests a cache line that is stored in multiple locations, every location might respond with the data. As the the requesting processor only needs a single copy of the data, the system would be '''wasting the bandwidth'''. &lt;br /&gt;
As a '''solution''' to this problem, an additional state, '''Forward state''', was added by slightly changing the role of the Shared state. Whenever there is a read request, only the cache line in the F state will respond to the request, while all the S state caches remain dormant.  Hence, by designating a single cache line to '''respond to requests''', coherency traffic is substantially reduced when multiple copies of the data exist. Also, on a read request, the F state transitions from F to S state. That is, when a cache line in the '''F''' state is '''copied''', the F state '''migrates''' to the '''newer copy''', while the '''older''' one drops back to '''S'''. Moving the new copy to the F state '''exploits''' both '''temporal and spatial locality'''. Because the newest copy of the cache line is always in the F state, it is very unlikely that the line in the F state will be evicted from the caches. This takes advantage of the temporal locality of the request. The second advantage is that if a particular cache line is in high demand due to spatial locality, the bandwidth used to transmit that data will be spread across several nodes.&lt;br /&gt;
All M to S state transition and E to S state transitions will now be from '''M to F''' and '''E to F'''.  &lt;br /&gt;
The '''F state''' is '''different''' from the '''Owned state''' of the MOESI protocol as it is '''not''' a '''unique''' copy because a valid copy is stored in memory. Thus, unlike the Owned state of the MOESI protocol, in which the data in the O state is the only valid copy of the data, the data in the F state can be evicted or converted to the S state, if desired. &lt;br /&gt;
&lt;br /&gt;
More information on the QuickPath Interconnect and MESIF protocol can be found at&lt;br /&gt;
'''[http://www.intel.com/technology/quickpath/introduction.pdf Introduction to QuickPath Interconnect]'''&lt;br /&gt;
&lt;br /&gt;
=== CMP Implementation in Intel Architecture ===&lt;br /&gt;
&lt;br /&gt;
Let us now see how Intel architecture using the [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol progressed from a uniprocessor architecture to a Chip MultiProcessor (CMP) using the bus as the interconnect. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Uniprocessor Architecture'''&lt;br /&gt;
&lt;br /&gt;
The diagram below shows the structure of the memory cluster in Intel Pentium M processor.&lt;br /&gt;
&lt;br /&gt;
[[Image:intel_cache1.jpg|frame|center|&amp;lt;b&amp;gt;Figure 5:&amp;lt;/b&amp;gt; Memory Structure of the Pentium M Processor]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In this structure we have,&lt;br /&gt;
* A unified on-chip '''L1 cache''' with the '''processor/core''',&lt;br /&gt;
* A '''Memory/L2 access control unit''', through which all the accesses to the L2 cache, main memory and IO space are made,&lt;br /&gt;
* The second level '''L2 cache''' along with the '''prefetch unit''' and&lt;br /&gt;
* '''Front side bus (FSB)''', a single shared bi-directional bus through which all the traffic is sent across.These wide buses bring in multiple data bytes at a time. &lt;br /&gt;
&lt;br /&gt;
As Intel explains it, using this structure, the processor requests were first sought in the '''L2 cache''' and only on a '''miss''', were they '''forwarded''' to the main '''memory''' via the front side bus ('''FSB'''). The '''Memory/L2 access control''' unit served as a central point for '''maintaining coherence''' within the core and with the external world. It '''contains''' a '''snoop control unit''' that receives snoop requests from the bus and performs the required operations on each cache (and internal buffers) in parallel. It also handles RFO requests (BusUpgr) and ensures the operation continues only after it guarantees that no other version on the cache line exists in any other cache in the system.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''CMP Architecture'''&lt;br /&gt;
&lt;br /&gt;
For CMP implementation, Intel chose the bus-based architecture using snoopy protocols vs the '''directory protocol''' because though directory protocol reduces the active power due to reduced snoop activity, it '''increased''' the '''design complexity''' and the '''static power''' due to larger tag arrays. Since Intel has a large market for the processors in the mobility family, directory-based solution was less favorable since battery life mainly depends on static power consumption and less on dynamic power.&lt;br /&gt;
Let us examine how '''CMP''' was implemented in '''Intel Core Duo''', which was one of the first dual-core processor for the budget/entry-level market. &lt;br /&gt;
The general CMP implementation structure of the Intel Core Duo is shown below&lt;br /&gt;
&lt;br /&gt;
[[Image:intel_cache2.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; Intel Core Duo CMP Implementation]]&lt;br /&gt;
&lt;br /&gt;
This structure has the following changes when compared to the uniprocessor memory cluster structure. &lt;br /&gt;
* '''L1 cache''' and the '''processor/core''' structure is '''duplicated''' to give 2 cores.&lt;br /&gt;
* The '''Memory/L2 access control''' unit is '''split''' into 2 logical units: '''L2 controller''' and '''bus controller'''. The L2 controller handles all '''requests to the L2''' cache from the core and the snoop requests from the FSB. The '''bus controller''' handles '''data and I/O requests''' to and from the FSB.&lt;br /&gt;
* The '''prefetching''' unit is extended to handle the hardware '''prefetches for each core separately'''.&lt;br /&gt;
* A '''new logical unit''' (represented by the hexagon) was added to maintain '''fairness between the requests''' coming from the different cores and hence balance the requests to L2 and memory.&lt;br /&gt;
&lt;br /&gt;
This new '''partitioned structure''' for the  memory/L2 access control unit '''enhanced''' the '''performance''' while '''reducing power consumption'''. &lt;br /&gt;
For more information on uniprocessor and multiprocessor implementation under the Intel architecture, refer to &lt;br /&gt;
[http://www.intel.com/technology/itj/2006/volume10issue02/art02_CMP_Implementation/p03_implementation.htm CMP Implementation in Intel Core Duo Processors]&lt;br /&gt;
&lt;br /&gt;
The '''Intel bus architecture''' has been '''evolving''' in order to accommodate the demands of scalability while using the '''same [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol'''; From using a '''single shared bus''' to '''dual independent buses (DIB)''' doubling the available bandwidth and to the logical conclusion of DIB with the introduction of '''dedicated high-speed interconnects (DHSI)'''. The DHSI-based platforms use four FSBs, one for each processor in the platform. In both DIB and DHSI, the snoop filter was used in the chipset to cache snoop information, thereby significantly reducing the broadcasting needed for the snoop traffic on the buses. With the production of processors based on next generation 45-nm Hi-k Intel Core microarchitecture, the [http://en.wikipedia.org/wiki/Xeon Intel Xeon] processor fabric will transition from a DHSI, with the memory controller in the chipset, to a distributed shared memory architecture using '''Intel QuickPath Interconnects using MESIF protocol'''.&lt;br /&gt;
&lt;br /&gt;
==AMD - Advanced Micro Devices Processors==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===MOESI &amp;amp; AMD Processors===&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/Opteron AMD Opteron] was AMD’s first-generation dual core which had two distinct [http://en.wikipedia.org/wiki/Athlon_64 K8 cores] together on a single die. Cache coherence produces bigger problems on such multiprocessors. It was necessary to use an appropriate coherence protocol to address this problem. The [http://en.wikipedia.org/wiki/Xeon Intel Xeon], which was the competitive counterpart from Intel to AMD dual core Opteron, used the [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol to handle cache coherence. [http://en.wikipedia.org/wiki/MESI_protocol MESI] came with the drawback of using much time and bandwidth in certain situations. &lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/MOESI_protocol MOESI] was AMD’s answer to this problem. [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] added a fifth state to [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol called the '''owned''' state. [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] addresses the bandwidth problem faced in MESI protocol when processor having invalid data in its cache wants to modify the data.  The processor seeking the data access will have to wait for the processor which modified this data to write back to the main memory, which takes time and bandwidth. This drawback is removed in MOESI by allowing dirty sharing.  When the data is held by a processor in the new state '''owned''', it can provide other processors the modified data without or even before writing it to the main memory. This is called '''''dirty sharing'''''. The processor with the data in the '''owned''' state stays responsible to update the main memory later when the cache line is evicted.&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/MOESI_protocol MOESI]  has become one of the most popular snoop-based protocols supported in AMD64 architecture.  AMD dual-core Opteron can maintain cache coherence in systems up to 8 processors using this protocol.&lt;br /&gt;
&lt;br /&gt;
The five different states of [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol are:&lt;br /&gt;
* '''Modified (M)''': The most recent copy of the data is present in the cache line. But it is not present in any other processor cache.&lt;br /&gt;
* '''Owned (O)''': The cache line has the most recent correct copy of the data. This can be shared by other processors. The processor in this state for this cache line is responsible to update the correct value in the main memory before it gets evicted.&lt;br /&gt;
* '''Exclusive (E)''': A cache line holds the most recent, correct copy of the data, which is exclusively present on this processor and a copy is present in the main memory.&lt;br /&gt;
* '''Shared (S)''': A cache line in the shared state holds the most recent, correct copy of the data, which may be shared by other processors.&lt;br /&gt;
* '''Invalid (I)''': A cache line does not hold a valid copy of the data.&lt;br /&gt;
&lt;br /&gt;
A detailed explanation of this protocol implementation on AMD processor can be found in the manual [http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html Architecture of AMD 64-bit core]&lt;br /&gt;
&lt;br /&gt;
The following table summarizes the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''Cache Line State:'''&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  '''Owner''' &lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''This cache line is valid?'''&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  No&lt;br /&gt;
|-&lt;br /&gt;
|  '''The memory copy is…'''&lt;br /&gt;
|  out of date&lt;br /&gt;
|  out of date&lt;br /&gt;
|  valid&lt;br /&gt;
|  valid&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''Copies exist in caches of other processors?'''&lt;br /&gt;
|  No&lt;br /&gt;
|  No&lt;br /&gt;
|  Yes(out of date values)|  Maybe&lt;br /&gt;
|  Maybe&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''A write to this line'''&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  does not go to bus|  does not go to bus&lt;br /&gt;
|  goes to bus and updates cache&lt;br /&gt;
|  goes directly to bus&lt;br /&gt;
|  -&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 3:&amp;lt;/b&amp;gt; MOESI Protocol Summary&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
State transition for [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]is as shown below : &lt;br /&gt;
&lt;br /&gt;
[[Image:MOESI_State_Transition_Diagram.jpg|frame|center|&amp;lt;b&amp;gt;Figure 7:&amp;lt;/b&amp;gt; [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]State transition Diagram]]&lt;br /&gt;
&lt;br /&gt;
===AMD Opteron memory Architecture===&lt;br /&gt;
&lt;br /&gt;
[[Image:Untitled.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; AMD Opteron memory Architecture]]&lt;br /&gt;
&lt;br /&gt;
The AMD processor’s high-performance cache architecture includes an integrated, 64-bit, dual-ported  128-Kbyte split-L1 cache with separate snoop port, multi-level translation lookaside buffers (TLBs), a scalable L2 cache controller with a 72-bit (64-bit data + 8-bit ECC) interface to as much as 8-Mbyte of industry-standard SDR or DDR SRAMs, and an integrated tag for the most cost-effective 512-Kbyte L2 configurations. The AMD Athlon processor’s integrated L1 cache comprises two separate 64-Kbyte, two-way set-associative data and instruction caches.&lt;br /&gt;
&lt;br /&gt;
More information about this can be found in [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD 64 bit Architecture Programmers's Manual]&lt;br /&gt;
&lt;br /&gt;
===Special Coherence Considerations in AMD64 architectures===&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
Instruction prefetching is a technique used to speedup the execution of the program. But in multiprocessors, prefetching comes at the cost of performance. Due to prefetching, the data can be modified in such a way that the memory coherence protocol will not be able to handle the effects. In such situations software must use serializing instructions or cache-invalidation instructions to guarantee subsequent data accesses are coherent. &lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
An example of this type of a situation is a page-table update followed by accesses to the physical pages referenced by the updated page tables. The physical-memory references for the page tables are different than the physical-memory references for the data. Because of prefetching, there maybe problem with correctness. The following sequence of events shows such a situation when software changes the translation of virtual-page A from physical-page M to physical-page N:&lt;br /&gt;
# The tables that translate virtual-page A to physical-page M are now held only in main memory. The copies in the cache ae invalidated.&lt;br /&gt;
# Page-table entry is changed by the software for virtual-page A in main memory to point to physical page N rather than physical-page M.&lt;br /&gt;
# Data in virtual-page A is accessed.&lt;br /&gt;
&lt;br /&gt;
Software expects the processor to access the data from physical-page N after the update. However, it is possible for the processor to prefetch the data from physical-page M before the page table for virtual page A is updated. Because the physical-memory references are different, the processor does not recognize them as requiring coherence checking and believes it is safe to prefetch the data from virtual-page A, which is translated into a read from physical page M. Similar behavior can occur when instructions are prefetched from beyond the page table update instruction.&lt;br /&gt;
&lt;br /&gt;
In order to prevent errors from occuring, there are special instructions provided by software like INVLPG or MOV CR3 instruction which is executed immediately after the page-table update to ensure that subsequent instruction fetches and data accesses use the correct virtual-page-to-physical-page translation. It is not necessary to perform a TLB invalidation operation preceding the table update.&lt;br /&gt;
&lt;br /&gt;
More information can be found about this in [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD64 Architecture Programmer's manual]&lt;br /&gt;
&lt;br /&gt;
===Optimization techniques on MOESI when implemented on AMD Phenom processors===&lt;br /&gt;
&lt;br /&gt;
In real machines, using some optimization techniques on the standard cache coherence protocol used, improves the performance of the machine. For example, [http://en.wikipedia.org/wiki/AMD_Phenom AMD Phenom] family of microprocessors (Family 0×10) which is AMD’s first generation to incorporate 4 distinct cores on a single die. It is the first to have a cache that all the cores share, using the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol with some optimization techniques incorporated. &lt;br /&gt;
&lt;br /&gt;
It focuses on a small subset of compute problems which behave like Producer and Consumer programs. In such a computing problem, a thread of a program running on a single core produces data, which is consumed by a thread that is running on a separate core. With such programs, it is desirable to get the two distinct cores to communicate through the shared cache, to avoid round trips to/from main memory. The '''MOESI''' protocol that the [http://en.wikipedia.org/wiki/AMD_Phenom AMD Phenom] cache uses for cache coherence can also limit bandwidth. Hence by keeping the cache line in the '''M''' state for such computing problems, we can achieve better performance.&lt;br /&gt;
&lt;br /&gt;
When the producer thread , writes a new entry, it allocates cache-lines in the '''M''' state. Eventually, these M-marked cache lines will start to fill the L3 cache. When the consumer reads the cache line, the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol changes the state of the cache line to the '''O''' state in the L3 cache and pulls down a '''shared (S)''' copy for its own use. Now, the producer thread circles the ring buffer to arrive back to the same cache line it had previously written. However, when the producer attempts to write new data to the owned (marked '''‘O’''') cache line, it finds that it cannot, since a cache line in the '''O''' state by the previous consumer read does not have sufficient permission for a write request (in the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]). To maintain coherence, the memory controller must initiate probes in the other caches (to handle any other S copies that may exist). This will slow down the process.&lt;br /&gt;
&lt;br /&gt;
Thus, it is preferable to keep the cache line in the '''M''' state in the L3 cache. In such a situation, when the producer comes back around the ring buffer, it finds the previously written cache line still in the'''M''' state, to which it is safe to write without coherence concerns. Thus better performance can be achieved by such optimization techniques to standard protocols when implemented in real machines.&lt;br /&gt;
&lt;br /&gt;
You can find more information on how this is implemented and various other ways of optimizations in this manual [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf Software Optimization guide for AMD 10h Processors].&lt;br /&gt;
&lt;br /&gt;
==Xerox Corporation==&lt;br /&gt;
===Dragon Protocol &amp;amp; Xerox Dragon Processors===&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' is an update based coherence protocol which does not invalidate other cached copies like what we have seen in the coherence protocols so far. Write propagation is achieved by updating the cached copies instead of invalidating them.  But the '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' does not update memory on a cache to cache transfer and delays the memory and cache consistency until the data is evicted and written back, which saves time and lowers the memory access requirements. Moreover only the written '''byte''' or the '''word''' is '''communicated''' to the '''other caches''' instead of the whole block which further '''reduces''' the '''bandwidth''' usage. It has the ability to detect dynamically, the sharing status of a block and use a write through policy for shared blocks and write back for currently non-shared blocks. The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' employs the following four states for the cache blocks: '''Shared Clean''', '''Shared Modified''', '''Exclusive''', and  '''Modified'''. &lt;br /&gt;
* '''Modified (M)''' and '''Exclusive (E)''' - these states have the same meaning as explained in the protocols above. &lt;br /&gt;
* '''Shared Modified (Sm)''' - Only one cache line in the system can be in the Shared Modified state. Potentially two or more caches    have this block and memory may or may not be up to date and this processor's cache had modified the block.&lt;br /&gt;
* '''Shared Clean (Sc)''' -  Potentially two or more caches have this block and memory may or may not be up to date(if no other cache has it in Sm state, memory will be up to date else it is not).&lt;br /&gt;
When a Shared Modified line is evicted from the cache on a cache miss only then is the block written back to the main memory in order to keep memory consistent. For more information on Dragon protocol, refer to Solihin textbook, page number 229. The state transition diagram has been given below for reference.&lt;br /&gt;
&lt;br /&gt;
[[Image:Dragon.jpg|frame|center|&amp;lt;b&amp;gt;Figure 9:&amp;lt;/b&amp;gt; Dragon Protocol State Diagram]]&lt;br /&gt;
&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' , was developed by Xerox Palo Alto Research Center ('''[http://en.wikipedia.org/wiki/Xerox_PARC Xerox PARC]'''), a subsidiary of Xerox Corporation.  This protocol was used in the '''[http://en.wikipedia.org/w/index.php?title=Xerox_Dragon&amp;amp;redirect=no Xerox PARC Dragon]''' multiprocessor workstation, a VLSI research computer that could support multiple processors on a central high bandwidth memory bus. The Dragon design implemented snoopy caches that provided the appearance of a uniform memory space to multiple processors. Here, each cache listens to 2 buses: the processor bus and the memory bus. The caches are also responsible for address translation, so the processor bus carries virtual addresses and the memory bus carries physical addresses.  The Dragon system was designed to support 4 to 8 Dragon processors. The memory bus used in the Xeron Dragon evolved to become the '''[http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=289691 XDBus]''' , a low-cost, synchronous, '''packet-switched VLSI bus''' designed for use in high-performance multiprocessors. This was used as the interconnect in many multiprocessor server systems like '''Cray Superserver 6400''', '''Sun Microsystems' SPARCcenter 2000''' and '''SPARCserver 1000'''  and '''Sun4d''' systems.&lt;br /&gt;
&lt;br /&gt;
=Cache Coherence Power Utilization=&lt;br /&gt;
A number of studies have been performed to reduce the power consumption of cache coherence protocols. In order to perform a solid comparison between the cache coherency protocols, one would need to develop a multi-core processor for each of the cache coherency protocols. Additionally, the hardware and software configuration would also need to be similar between each system (except for the hardware required to implement each of the different protocols). Unfortunately, there are no such processors available. This section will discuss power consumption in general terms, comparing to each of the protocols. Also, this section will briefly discussion some power optimization techniques.&lt;br /&gt;
&lt;br /&gt;
Bus transactions, in general, are costly for both performance and power consumption. Additionally, studies have been performed showing that unnecessary snooping can waste power. Power requirements are typically determined by the number of bus snoops and number of bus accesses by each processor. One study indicates that interchip bus communications can consume up to 20% of total chip power[[#References|&amp;lt;sup&amp;gt;[20]&amp;lt;/sup&amp;gt;]].&lt;br /&gt;
Using the examples from the class notes, we can analyze the relative power consumption between the protocols. The following table is a summary of various protocols showing the number of bus communications that occur for each processor action.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|'''Processor Action'''&lt;br /&gt;
|'''MSI Bus Actions'''&lt;br /&gt;
|'''MESI Bus Actions'''&lt;br /&gt;
|'''Dragon Bus Actions'''&lt;br /&gt;
|'''FireFly Bus Actions'''&lt;br /&gt;
|-&lt;br /&gt;
|R1&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|-&lt;br /&gt;
|W1&lt;br /&gt;
|BusRdX&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R3&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|-&lt;br /&gt;
|W3&lt;br /&gt;
|BusRdX&lt;br /&gt;
|BusRdX&lt;br /&gt;
|BusUpd/Upd&lt;br /&gt;
|BusUpd&lt;br /&gt;
|-&lt;br /&gt;
|R1&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R3&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R2&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 4:&amp;lt;/b&amp;gt; Summary of Bus Actions for Select Protocols&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
From the table above, we can see that MSI has a larger number of bus transactions than the Dragon protocol. Even though bus transactions are not power efficient, snooping can also be enhanced to improve power efficiency. The following section will discuss snoop filtering techniques.&lt;br /&gt;
&lt;br /&gt;
==Power Savings Using Snoop Filtering==&lt;br /&gt;
A number of studies have been performed to reduce the number of unnecessary snoops during cache transactions. Two such filtering techniques are serial snooping and Jetty. The following sections will briefly discuss these two filtering techniques and power savings achieved using these techniques. Studies show that as much as 90% of snoop broadcasts will result in a miss[[#References|&amp;lt;sup&amp;gt;[19]&amp;lt;/sup&amp;gt;]] in the other caches at the same level and require that the information be provided by the next level of cache or memory. As much as a 36% savings in power by filtering snoops using one of the following snoop filtering methods[[#References|&amp;lt;sup&amp;gt;[19]&amp;lt;/sup&amp;gt;]].&lt;br /&gt;
===Serial Snooping===&lt;br /&gt;
Serial snooping takes advantage of the fact that if a miss occurs in one cache, it is possible to find the block in one other cache without having to check all the caches. If the cache block is available in multiple caches, there is a high probability that the cache miss can find the data in a nearby cache. Alternatively, savings can be realized by searching a subset of the caches vice all the caches. One thing to note is that this is only effective for read misses. Write, an invalidation transaction needs to be transmitted to the other caches, thus a bus transaction is unavoidable.&lt;br /&gt;
===Jetty===&lt;br /&gt;
Jetty is a mechanism attached to each cache that verifies that a bus snoop is necessary. Jetty is used to filter L2 tag lookups. When a processor needs to perform a bus snoop, the Jetty is checked first. The Jetty can determine if a cache tag lookup is required. Since the Jetty is much smaller than the associated cache, less power is required to determine if a snoop is required.&lt;br /&gt;
&lt;br /&gt;
There are a couple of different Jetty schemes. There is the exclude-Jetty, include-Jetty, and hybrid-Jetty. The exclude-Jetty exploits the fact that if a cache block is snooped, it is highly likely the same cache block will be snooped in the near future. The exclude-Jetty keeps track of the tag lookups in a small table and can determine if a cache tag lookup is necessary.&lt;br /&gt;
&lt;br /&gt;
The include-Jetty keeps a superset of the blocks that are cached. If a miss occurs in the include-Jetty, then it can be guaranteed that the block is not stored in its associated cache.&lt;br /&gt;
&lt;br /&gt;
The hybrid-Jetty is simply a combinations of and include and exclude-Jetty. Both types of Jetty are present and when a lookup occurs, both Jettys are checked to determine if a cache lookup is necessary.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Cache_coherence Cache coherence]&lt;br /&gt;
# [http://www.intel.com/technology/quickpath/introduction.pdf Introduction to QuickPath Interconnect]&lt;br /&gt;
# [http://www.intel.com/technology/itj/2006/volume10issue02/art02_CMP_Implementation/p03_implementation.htm CMP Implementation in Intel Core Duo Processors]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Symmetric_multiprocessing Common System Interface in Intel Processors]&lt;br /&gt;
# [http://www.zak.ict.pwr.wroc.pl/nikodem/ak_materialy/Cache%20consistency%20&amp;amp;%20MESI.pdf Cache consistency with MESI on Intel processor]&lt;br /&gt;
# [http://techreport.com/articles.x/8236/2 AMD dual core Architecture]&lt;br /&gt;
# [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD64 Architecture Programmer's manual]&lt;br /&gt;
# [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf Software Optimization guide for AMD 10h Processors]&lt;br /&gt;
# [http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html Architecture of AMD 64 bit core]&lt;br /&gt;
# [http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=4913 Silicon Graphics Computer Systems]&lt;br /&gt;
# [http://books.google.com/books?id=g82fofiqa5IC&amp;amp;printsec=frontcover&amp;amp;dq=Parallel+computer+architecture:+a+hardware/software+approach+By+David+E.+Culler,+Jaswinder+Pal+Singh,+Anoop+Gupta&amp;amp;source=bl&amp;amp;ots=COrdamlfVn&amp;amp;sig=YcugVqbzTjHvlofvaFq6Ft_tjfY&amp;amp;hl=en&amp;amp;ei=0ZO6S4TJGcOclgejzI3BBw&amp;amp;sa=X&amp;amp;oi=book_result&amp;amp;ct=result&amp;amp;resnum=1&amp;amp;ved=0CAgQ6AEwAA#v=onepage&amp;amp;q=&amp;amp;f=false Parallel computer architecture: a hardware/software approach By David E. Culler, Jaswinder Pal Singh, Anoop Gupta]&lt;br /&gt;
# [http://www.freepatentsonline.com/5283886.html Three state invalidation protocols]&lt;br /&gt;
# [http://portal.acm.org/citation.cfm?id=1499317&amp;amp;dl=GUIDE&amp;amp;coll=GUIDE&amp;amp;CFID=83027384&amp;amp;CFTOKEN=95680533 Synapse tightly coupled multiprocessors: a new approach to solve old problems]&lt;br /&gt;
# [http://portal.acm.org/citation.cfm?id=6514Cache Coherence protocols: evaluation using a multiprocessor simulation model]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Xerox_Dragon Xerox Dragon]&lt;br /&gt;
# [http://thanaseto.110mb.com/courses/CSD-527-report-engl.pdf Coherence Protocols]&lt;br /&gt;
# [http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=289691 XDBus]&lt;br /&gt;
# [http://www.ece.wisc.edu/~wddd/2002/final/ekman.pdf Evaluation of Snoop-Energy Reduction Techniques for Chip-Multiprocessors]&lt;br /&gt;
# [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.79.7463&amp;amp;rep=rep1&amp;amp;type=pdf Power Efficient Cache Coherence]&lt;/div&gt;</summary>
		<author><name>Mqtran</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2011/ch8_mc&amp;diff=44454</id>
		<title>CSC/ECE 506 Spring 2011/ch8 mc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2011/ch8_mc&amp;diff=44454"/>
		<updated>2011-03-19T20:22:23Z</updated>

		<summary type="html">&lt;p&gt;Mqtran: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Introduction to bus-based cache coherence in real machines=&lt;br /&gt;
&lt;br /&gt;
Most parallel software in the commercial market relies on the shared-memory&lt;br /&gt;
programming model in which all processors access the same physical address space. The most common multiprocessors today use [http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP] architecture which use a common bus as the interconnect.  In the case of multicore processors (&amp;quot;chip multiprocessors,&amp;quot; or CMP) the [http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP] architecture applies to the cores treating them as separate processors. The key problem of shared-memory multiprocessors is providing a consistent view of memory with various cache hierarchies.  This is called '''''cache coherence problem'''''. It is  critical to  achieve correctness and performance-sensitive design point for supporting the shared-memory model. The cache coherence mechanisms not only govern communication in a shared-memory multiprocessor, but also typically determine how the memory system transfers data between processors, caches, and memory.&lt;br /&gt;
&lt;br /&gt;
[[Image:Busbased SMP.jpg|frame|center|&amp;lt;b&amp;gt;Figure 1:&amp;lt;/b&amp;gt; Typical Bus-Based Processor Model]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Cache Coherence in real machines=&lt;br /&gt;
==Summary of Cache Coherence Protocols==&lt;br /&gt;
At any point in logical time, the permissions for a cache block can allow either a single writer or multiple readers. The '''''coherence protocol''''' ensures the invariants of the states are maintained. The different coherent states used by most of the cache coherent protocols are shown in ''Table 1'':&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''States'''&lt;br /&gt;
|  '''Access Type'''&lt;br /&gt;
|  '''Invariant'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  read, write&lt;br /&gt;
|  all other caches in I state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  read&lt;br /&gt;
|  all other caches in I state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Owned'''&lt;br /&gt;
|  read&lt;br /&gt;
|  all other caches in I or S state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  read&lt;br /&gt;
|  no other cache in M or E state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|  -&lt;br /&gt;
|  -&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 1:&amp;lt;/b&amp;gt; States Used by the Cache Coherent Protocols&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
The first widely adopted approach to cache coherence is snooping on a bus. We will now discuss them in details in the following sections.&lt;br /&gt;
&lt;br /&gt;
===MESI &amp;amp; Intel Processors===&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' has a major drawback in that each read-write sequence incurs two bus transactions irrespective of whether the cache line is stored in only one cache or not. This is a huge setback for highly parallel programs that have little data sharing. '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol solves this problem by introducing the E ('''Exclusive''') state to distinguish between a cache line stored in multiple caches and a line stored in a single cache.&lt;br /&gt;
Let us briefly see how the MESI protocol works. For a more detailed version refer Solihin textbook pg. 215.&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' coherence protocol marks each cache line in of the Modified, Exclusive, Shared, or Invalid state. &lt;br /&gt;
* '''Invalid''' : The cache line is either not present or is invalid&lt;br /&gt;
* '''Exclusive''' : The cache line is clean and is owned by this core/processor only&lt;br /&gt;
* '''Modified''' :  This implies that the cache line is dirty and the core/processor has  exclusive ownership of the cache line,exclusive of the memory also.&lt;br /&gt;
* '''Shared''' : The cache line is clean and is shared by more than one core/processor&lt;br /&gt;
&lt;br /&gt;
In a nutshell, the '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol works as follows: &lt;br /&gt;
A line that is fetched, receives '''E''', or '''S''' state depending on whether it exists in other processors in the system. A cache line gets the '''M''' state when a processor writes to it; if the line is not in '''E''' or '''M'''-state prior to writing it, the cache sends a Bus Upgrade (BusUpgr) signal or as the Intel manuals term it, “Read-For-Ownership (RFO) request” that ensures that the line exists in the cache and is in the '''I''' state in all other processors on the bus (if any). The table is shown below to summarize '''[http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol'''.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''Cache Line State:'''&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''This cache line is valid?'''&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  No&lt;br /&gt;
|-&lt;br /&gt;
|  '''The memory copy is…'''&lt;br /&gt;
|  out of date&lt;br /&gt;
|  valid&lt;br /&gt;
|  valid&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''Copies exist in caches of other processors?'''|  No&lt;br /&gt;
|  No&lt;br /&gt;
|  Maybe&lt;br /&gt;
|  Maybe&lt;br /&gt;
|-&lt;br /&gt;
|  '''A write to this line'''|  does not go to bus&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  goes to bus and updates cache&lt;br /&gt;
|  goes directly to bus&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 2:&amp;lt;/b&amp;gt; MESI Protocol Summary&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The transition diagram from the lecture slides is given below for reference.&lt;br /&gt;
&lt;br /&gt;
[[Image:MESI.jpg|frame|center|&amp;lt;b&amp;gt;Figure 4:&amp;lt;/b&amp;gt; MESI State Diagram]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
We will now discuss how processor vendors like '''Intel''', '''AMD''' and others maintain cache coherence using '''''snooping based coherence protocols'''''.  For more information on snooping based protocols, readers are referred to Solihin textbook Chapter 8.&lt;br /&gt;
&lt;br /&gt;
==SGI - Silicon Graphics, Inc==&lt;br /&gt;
===MSI &amp;amp; SGI IRIS 4D Processors===&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' is a three-state write-back '''invalidation protocol''' which is one of the earliest snooping-based cache coherence-protocols. It marks the cache line in '''Modified (M) ,Shared (S)''', and '''Invalid (I)''' state. '''Invalid''' means the cache line is either not present or is invalid state. If the cache line is clean and is shared by more than one processor , it is marked '''shared'''. If cache line is dirty and the processor has exclusive ownership of the cache line, it is present in '''Modified''' state. BusRdx causes other processors to invalidate (demote) its cache block to the '''I''' state. If it is present in the '''M''' state in another cache, it will flush. BusRdx, even if hit in '''S''' state, is promoted to '''M''' (upgrade) state.&lt;br /&gt;
&lt;br /&gt;
The following state transition diagram for MSI protocol explains the working of the protocol:&lt;br /&gt;
&lt;br /&gt;
[[Image:MSI.jpg|frame|center|&amp;lt;b&amp;gt;Figure 2:&amp;lt;/b&amp;gt; MSI State Diagram]]&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' protocol was first used in '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''' IRIS 4D series. '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''' produced a broad range of '''[http://en.wikipedia.org/wiki/MIPS_architecture MIPS]'''-based (Microprocessor without Interlocked Pipeline Stages) workstations and servers during the 1990s, running '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''''s version of UNIX System V, now called '''[http://en.wikipedia.org/wiki/IRIX IRIX]'''. The 4D-MP graphics superworkstation brought 40 MIPS(million instructions per second) of computing performance to a graphics superworkstation. The unprecedented level of computing and graphics processing in an office-environment workstation was made possible by the fastest available Risc microprocessors in a single shared memory multiprocessor design driving a tightly coupled, highly parallel graphics system. Aggregate sustained data rates of over one gigabyte per second were achieved by a hierarchy of buses in a balanced system designed to avoid bottlenecks.&lt;br /&gt;
&lt;br /&gt;
The multiprocessor bus used in 4D-MP graphics superworkstation is a pipelined, block transfer bus that supports the cache coherence protocol as well as providing 64 megabytes of sustained data bandwidth between the processors, the memory and I/O system, and the graphics subsystem. Because the sync bus provides for efficient synchronization between processors, the cache coherence protocol was designed to support efficient data sharing between processors. If a cache coherence protocol has to support synchronization as well as sharing, a compromise in the efficiency of the data sharing protocol may be necessary to improve the efficiency of the synchronization operations. Hence it uses the simple cache coherence protocol which is the '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' protocol.&lt;br /&gt;
&lt;br /&gt;
With the simple rules of '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' enforced by the hardware protocols of&lt;br /&gt;
the sync bus and the Multiprocessor bus, efficient synchronization and efficient data sharing are achieved in a simple shared memory model of parallel processing in the 4D-MP graphics superworkstation.&lt;br /&gt;
&lt;br /&gt;
==SYNAPSE Multiprocessor==&lt;br /&gt;
===Synapse protocol and Synapse multiprocessor===&lt;br /&gt;
From the state transition diagram of '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''', we observe that for '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' there is transition to the '''S''' state from the '''M''' state when a BusRd is observed for that block. The contents of the block is flushed to the bus before going to '''S''' state. It would look more appropriate to move to the '''I''' state thus giving up the block entirely in certain cases. This choice of moving to '''S''' or '''I''' reflects the designer's assertion that the original processor is more likely to continue reading the block than the new processor to write to the block. In synapse protocol, used in the early Synapse multiprocessor, made this alternate choice of going directly from the '''M''' state to the '''I''' state on a BusRd, assuming the migratory pattern would be more frequent. More details about this protocol can be found in these papers published in late 1980's [http://portal.acm.org/citation.cfm?id=6514Cache Coherence protocols: evaluation using a multiprocessor simulation model] and [http://portal.acm.org/citation.cfm?id=1499317&amp;amp;dl=GUIDE&amp;amp;coll=GUIDE&amp;amp;CFID=83027384&amp;amp;CFTOKEN=95680533 Synapse tightly coupled multiprocessors: a new approach to solve old problems]&lt;br /&gt;
&lt;br /&gt;
In the Synapse protocol, the '''M''' state is called the '''D''' (Dirty) state. The following is the state transition diagram for Synapse protocol which clearly shows its working.&lt;br /&gt;
&lt;br /&gt;
[[Image:Synapse1.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; Synapse State Diagram]]&lt;br /&gt;
&lt;br /&gt;
==Intel==&lt;br /&gt;
===MESI &amp;amp; Intel Processors===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The '''Pentium Pro''' microprocessor, introduced in 1992 was the '''first''' Intel architecture microprocessor to support symmetric multiprocessing ('''[http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP]''') in various multiprocessor configurations. '''[http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP]''' and '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol was the architecture used consistently until the introduction of the 45-nm Hi-k Core micro-architecture in '''Intel's (Nehalem-EP) quad-core x86-64'''. The 45-nm Hi-k Intel Core microarchitecture utilizes a new system of framework called the '''QuickPath Interconnect''' which uses point-to-point interconnection technology based on distributed shared memory architecture. It uses a modified version of '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol called '''MESIF''', by introducing an additional state, F, the forward state. &lt;br /&gt;
&lt;br /&gt;
The '''Intel architecture''' uses the '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol  as the '''basis''' to ensure cache coherence, which is true whether you're on one of the older processors that use a '''common bus''' to communicate or using the new Intel '''QuickPath''' point-to-point interconnection technology. &lt;br /&gt;
&lt;br /&gt;
Let us now walk through a briefing on the '''MESIF protocol''':&lt;br /&gt;
&lt;br /&gt;
The '''MESIF''' protocol, used in the latest Intel multi-core processors was introduced to '''accommodate the point-to-point''' links used in the QuickPath Interconnect. Using the '''MESI''' protocol in this architecture would send many redundant messages between different processors, often with unnecessarily high latency. For example, when a processor requests a cache line that is stored in multiple locations, every location might respond with the data. As the the requesting processor only needs a single copy of the data, the system would be '''wasting the bandwidth'''. &lt;br /&gt;
As a '''solution''' to this problem, an additional state, '''Forward state''', was added by slightly changing the role of the Shared state. Whenever there is a read request, only the cache line in the F state will respond to the request, while all the S state caches remain dormant.  Hence, by designating a single cache line to '''respond to requests''', coherency traffic is substantially reduced when multiple copies of the data exist. Also, on a read request, the F state transitions from F to S state. That is, when a cache line in the '''F''' state is '''copied''', the F state '''migrates''' to the '''newer copy''', while the '''older''' one drops back to '''S'''. Moving the new copy to the F state '''exploits''' both '''temporal and spatial locality'''. Because the newest copy of the cache line is always in the F state, it is very unlikely that the line in the F state will be evicted from the caches. This takes advantage of the temporal locality of the request. The second advantage is that if a particular cache line is in high demand due to spatial locality, the bandwidth used to transmit that data will be spread across several nodes.&lt;br /&gt;
All M to S state transition and E to S state transitions will now be from '''M to F''' and '''E to F'''.  &lt;br /&gt;
The '''F state''' is '''different''' from the '''Owned state''' of the MOESI protocol as it is '''not''' a '''unique''' copy because a valid copy is stored in memory. Thus, unlike the Owned state of the MOESI protocol, in which the data in the O state is the only valid copy of the data, the data in the F state can be evicted or converted to the S state, if desired. &lt;br /&gt;
&lt;br /&gt;
More information on the QuickPath Interconnect and MESIF protocol can be found at&lt;br /&gt;
'''[http://www.intel.com/technology/quickpath/introduction.pdf Introduction to QuickPath Interconnect]'''&lt;br /&gt;
&lt;br /&gt;
=== CMP Implementation in Intel Architecture ===&lt;br /&gt;
&lt;br /&gt;
Let us now see how Intel architecture using the [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol progressed from a uniprocessor architecture to a Chip MultiProcessor (CMP) using the bus as the interconnect. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Uniprocessor Architecture'''&lt;br /&gt;
&lt;br /&gt;
The diagram below shows the structure of the memory cluster in Intel Pentium M processor.&lt;br /&gt;
&lt;br /&gt;
[[Image:intel_cache1.jpg|frame|center|&amp;lt;b&amp;gt;Figure 5:&amp;lt;/b&amp;gt; Memory Structure of the Pentium M Processor]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In this structure we have,&lt;br /&gt;
* A unified on-chip '''L1 cache''' with the '''processor/core''',&lt;br /&gt;
* A '''Memory/L2 access control unit''', through which all the accesses to the L2 cache, main memory and IO space are made,&lt;br /&gt;
* The second level '''L2 cache''' along with the '''prefetch unit''' and&lt;br /&gt;
* '''Front side bus (FSB)''', a single shared bi-directional bus through which all the traffic is sent across.These wide buses bring in multiple data bytes at a time. &lt;br /&gt;
&lt;br /&gt;
As Intel explains it, using this structure, the processor requests were first sought in the '''L2 cache''' and only on a '''miss''', were they '''forwarded''' to the main '''memory''' via the front side bus ('''FSB'''). The '''Memory/L2 access control''' unit served as a central point for '''maintaining coherence''' within the core and with the external world. It '''contains''' a '''snoop control unit''' that receives snoop requests from the bus and performs the required operations on each cache (and internal buffers) in parallel. It also handles RFO requests (BusUpgr) and ensures the operation continues only after it guarantees that no other version on the cache line exists in any other cache in the system.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''CMP Architecture'''&lt;br /&gt;
&lt;br /&gt;
For CMP implementation, Intel chose the bus-based architecture using snoopy protocols vs the '''directory protocol''' because though directory protocol reduces the active power due to reduced snoop activity, it '''increased''' the '''design complexity''' and the '''static power''' due to larger tag arrays. Since Intel has a large market for the processors in the mobility family, directory-based solution was less favorable since battery life mainly depends on static power consumption and less on dynamic power.&lt;br /&gt;
Let us examine how '''CMP''' was implemented in '''Intel Core Duo''', which was one of the first dual-core processor for the budget/entry-level market. &lt;br /&gt;
The general CMP implementation structure of the Intel Core Duo is shown below&lt;br /&gt;
&lt;br /&gt;
[[Image:intel_cache2.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; Intel Core Duo CMP Implementation]]&lt;br /&gt;
&lt;br /&gt;
This structure has the following changes when compared to the uniprocessor memory cluster structure. &lt;br /&gt;
* '''L1 cache''' and the '''processor/core''' structure is '''duplicated''' to give 2 cores.&lt;br /&gt;
* The '''Memory/L2 access control''' unit is '''split''' into 2 logical units: '''L2 controller''' and '''bus controller'''. The L2 controller handles all '''requests to the L2''' cache from the core and the snoop requests from the FSB. The '''bus controller''' handles '''data and I/O requests''' to and from the FSB.&lt;br /&gt;
* The '''prefetching''' unit is extended to handle the hardware '''prefetches for each core separately'''.&lt;br /&gt;
* A '''new logical unit''' (represented by the hexagon) was added to maintain '''fairness between the requests''' coming from the different cores and hence balance the requests to L2 and memory.&lt;br /&gt;
&lt;br /&gt;
This new '''partitioned structure''' for the  memory/L2 access control unit '''enhanced''' the '''performance''' while '''reducing power consumption'''. &lt;br /&gt;
For more information on uniprocessor and multiprocessor implementation under the Intel architecture, refer to &lt;br /&gt;
[http://www.intel.com/technology/itj/2006/volume10issue02/art02_CMP_Implementation/p03_implementation.htm CMP Implementation in Intel Core Duo Processors]&lt;br /&gt;
&lt;br /&gt;
The '''Intel bus architecture''' has been '''evolving''' in order to accommodate the demands of scalability while using the '''same [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol'''; From using a '''single shared bus''' to '''dual independent buses (DIB)''' doubling the available bandwidth and to the logical conclusion of DIB with the introduction of '''dedicated high-speed interconnects (DHSI)'''. The DHSI-based platforms use four FSBs, one for each processor in the platform. In both DIB and DHSI, the snoop filter was used in the chipset to cache snoop information, thereby significantly reducing the broadcasting needed for the snoop traffic on the buses. With the production of processors based on next generation 45-nm Hi-k Intel Core microarchitecture, the [http://en.wikipedia.org/wiki/Xeon Intel Xeon] processor fabric will transition from a DHSI, with the memory controller in the chipset, to a distributed shared memory architecture using '''Intel QuickPath Interconnects using MESIF protocol'''.&lt;br /&gt;
&lt;br /&gt;
==AMD - Advanced Micro Devices Processors==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===MOESI &amp;amp; AMD Processors===&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/Opteron AMD Opteron] was AMD’s first-generation dual core which had two distinct [http://en.wikipedia.org/wiki/Athlon_64 K8 cores] together on a single die. Cache coherence produces bigger problems on such multiprocessors. It was necessary to use an appropriate coherence protocol to address this problem. The [http://en.wikipedia.org/wiki/Xeon Intel Xeon], which was the competitive counterpart from Intel to AMD dual core Opteron, used the [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol to handle cache coherence. [http://en.wikipedia.org/wiki/MESI_protocol MESI] came with the drawback of using much time and bandwidth in certain situations. &lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/MOESI_protocol MOESI] was AMD’s answer to this problem. [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] added a fifth state to [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol called the '''owned''' state. [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] addresses the bandwidth problem faced in MESI protocol when processor having invalid data in its cache wants to modify the data.  The processor seeking the data access will have to wait for the processor which modified this data to write back to the main memory, which takes time and bandwidth. This drawback is removed in MOESI by allowing dirty sharing.  When the data is held by a processor in the new state '''owned''', it can provide other processors the modified data without or even before writing it to the main memory. This is called '''''dirty sharing'''''. The processor with the data in the '''owned''' state stays responsible to update the main memory later when the cache line is evicted.&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/MOESI_protocol MOESI]  has become one of the most popular snoop-based protocols supported in AMD64 architecture.  AMD dual-core Opteron can maintain cache coherence in systems up to 8 processors using this protocol.&lt;br /&gt;
&lt;br /&gt;
The five different states of [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol are:&lt;br /&gt;
* '''Modified (M)''': The most recent copy of the data is present in the cache line. But it is not present in any other processor cache.&lt;br /&gt;
* '''Owned (O)''': The cache line has the most recent correct copy of the data. This can be shared by other processors. The processor in this state for this cache line is responsible to update the correct value in the main memory before it gets evicted.&lt;br /&gt;
* '''Exclusive (E)''': A cache line holds the most recent, correct copy of the data, which is exclusively present on this processor and a copy is present in the main memory.&lt;br /&gt;
* '''Shared (S)''': A cache line in the shared state holds the most recent, correct copy of the data, which may be shared by other processors.&lt;br /&gt;
* '''Invalid (I)''': A cache line does not hold a valid copy of the data.&lt;br /&gt;
&lt;br /&gt;
A detailed explanation of this protocol implementation on AMD processor can be found in the manual [http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html Architecture of AMD 64-bit core]&lt;br /&gt;
&lt;br /&gt;
The following table summarizes the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''Cache Line State:'''&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  '''Owner''' &lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''This cache line is valid?'''&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  No&lt;br /&gt;
|-&lt;br /&gt;
|  '''The memory copy is…'''&lt;br /&gt;
|  out of date&lt;br /&gt;
|  out of date&lt;br /&gt;
|  valid&lt;br /&gt;
|  valid&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''Copies exist in caches of other processors?'''&lt;br /&gt;
|  No&lt;br /&gt;
|  No&lt;br /&gt;
|  Yes(out of date values)|  Maybe&lt;br /&gt;
|  Maybe&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''A write to this line'''&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  does not go to bus|  does not go to bus&lt;br /&gt;
|  goes to bus and updates cache&lt;br /&gt;
|  goes directly to bus&lt;br /&gt;
|  -&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 3:&amp;lt;/b&amp;gt; MOESI Protocol Summary&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
State transition for [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]is as shown below : &lt;br /&gt;
&lt;br /&gt;
[[Image:MOESI_State_Transition_Diagram.jpg|frame|center|&amp;lt;b&amp;gt;Figure 7:&amp;lt;/b&amp;gt; [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]State transition Diagram]]&lt;br /&gt;
&lt;br /&gt;
===AMD Opteron memory Architecture===&lt;br /&gt;
&lt;br /&gt;
[[Image:Untitled.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; AMD Opteron memory Architecture]]&lt;br /&gt;
&lt;br /&gt;
The AMD processor’s high-performance cache architecture includes an integrated, 64-bit, dual-ported  128-Kbyte split-L1 cache with separate snoop port, multi-level translation lookaside buffers (TLBs), a scalable L2 cache controller with a 72-bit (64-bit data + 8-bit ECC) interface to as much as 8-Mbyte of industry-standard SDR or DDR SRAMs, and an integrated tag for the most cost-effective 512-Kbyte L2 configurations. The AMD Athlon processor’s integrated L1 cache comprises two separate 64-Kbyte, two-way set-associative data and instruction caches.&lt;br /&gt;
&lt;br /&gt;
More information about this can be found in [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD 64 bit Architecture Programmers's Manual]&lt;br /&gt;
&lt;br /&gt;
===Special Coherence Considerations in AMD64 architectures===&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
Instruction prefetching is a technique used to speedup the execution of the program. But in multiprocessors, prefetching comes at the cost of performance. Due to prefetching, the data can be modified in such a way that the memory coherence protocol will not be able to handle the effects. In such situations software must use serializing instructions or cache-invalidation instructions to guarantee subsequent data accesses are coherent. &lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
An example of this type of a situation is a page-table update followed by accesses to the physical pages referenced by the updated page tables. The physical-memory references for the page tables are different than the physical-memory references for the data. Because of prefetching, there maybe problem with correctness. The following sequence of events shows such a situation when software changes the translation of virtual-page A from physical-page M to physical-page N:&lt;br /&gt;
# The tables that translate virtual-page A to physical-page M are now held only in main memory. The copies in the cache ae invalidated.&lt;br /&gt;
# Page-table entry is changed by the software for virtual-page A in main memory to point to physical page N rather than physical-page M.&lt;br /&gt;
# Data in virtual-page A is accessed.&lt;br /&gt;
&lt;br /&gt;
Software expects the processor to access the data from physical-page N after the update. However, it is possible for the processor to prefetch the data from physical-page M before the page table for virtual page A is updated. Because the physical-memory references are different, the processor does not recognize them as requiring coherence checking and believes it is safe to prefetch the data from virtual-page A, which is translated into a read from physical page M. Similar behavior can occur when instructions are prefetched from beyond the page table update instruction.&lt;br /&gt;
&lt;br /&gt;
In order to prevent errors from occuring, there are special instructions provided by software like INVLPG or MOV CR3 instruction which is executed immediately after the page-table update to ensure that subsequent instruction fetches and data accesses use the correct virtual-page-to-physical-page translation. It is not necessary to perform a TLB invalidation operation preceding the table update.&lt;br /&gt;
&lt;br /&gt;
More information can be found about this in [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD64 Architecture Programmer's manual]&lt;br /&gt;
&lt;br /&gt;
===Optimization techniques on MOESI when implemented on AMD Phenom processors===&lt;br /&gt;
&lt;br /&gt;
In real machines, using some optimization techniques on the standard cache coherence protocol used, improves the performance of the machine. For example, [http://en.wikipedia.org/wiki/AMD_Phenom AMD Phenom] family of microprocessors (Family 0×10) which is AMD’s first generation to incorporate 4 distinct cores on a single die. It is the first to have a cache that all the cores share, using the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol with some optimization techniques incorporated. &lt;br /&gt;
&lt;br /&gt;
It focuses on a small subset of compute problems which behave like Producer and Consumer programs. In such a computing problem, a thread of a program running on a single core produces data, which is consumed by a thread that is running on a separate core. With such programs, it is desirable to get the two distinct cores to communicate through the shared cache, to avoid round trips to/from main memory. The '''MOESI''' protocol that the [http://en.wikipedia.org/wiki/AMD_Phenom AMD Phenom] cache uses for cache coherence can also limit bandwidth. Hence by keeping the cache line in the '''M''' state for such computing problems, we can achieve better performance.&lt;br /&gt;
&lt;br /&gt;
When the producer thread , writes a new entry, it allocates cache-lines in the '''M''' state. Eventually, these M-marked cache lines will start to fill the L3 cache. When the consumer reads the cache line, the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol changes the state of the cache line to the '''O''' state in the L3 cache and pulls down a '''shared (S)''' copy for its own use. Now, the producer thread circles the ring buffer to arrive back to the same cache line it had previously written. However, when the producer attempts to write new data to the owned (marked '''‘O’''') cache line, it finds that it cannot, since a cache line in the '''O''' state by the previous consumer read does not have sufficient permission for a write request (in the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]). To maintain coherence, the memory controller must initiate probes in the other caches (to handle any other S copies that may exist). This will slow down the process.&lt;br /&gt;
&lt;br /&gt;
Thus, it is preferable to keep the cache line in the '''M''' state in the L3 cache. In such a situation, when the producer comes back around the ring buffer, it finds the previously written cache line still in the'''M''' state, to which it is safe to write without coherence concerns. Thus better performance can be achieved by such optimization techniques to standard protocols when implemented in real machines.&lt;br /&gt;
&lt;br /&gt;
You can find more information on how this is implemented and various other ways of optimizations in this manual [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf Software Optimization guide for AMD 10h Processors].&lt;br /&gt;
&lt;br /&gt;
==Xerox Corporation==&lt;br /&gt;
===Dragon Protocol &amp;amp; Xerox Dragon Processors===&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' is an update based coherence protocol which does not invalidate other cached copies like what we have seen in the coherence protocols so far. Write propagation is achieved by updating the cached copies instead of invalidating them.  But the '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' does not update memory on a cache to cache transfer and delays the memory and cache consistency until the data is evicted and written back, which saves time and lowers the memory access requirements. Moreover only the written '''byte''' or the '''word''' is '''communicated''' to the '''other caches''' instead of the whole block which further '''reduces''' the '''bandwidth''' usage. It has the ability to detect dynamically, the sharing status of a block and use a write through policy for shared blocks and write back for currently non-shared blocks. The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' employs the following four states for the cache blocks: '''Shared Clean''', '''Shared Modified''', '''Exclusive''', and  '''Modified'''. &lt;br /&gt;
* '''Modified (M)''' and '''Exclusive (E)''' - these states have the same meaning as explained in the protocols above. &lt;br /&gt;
* '''Shared Modified (Sm)''' - Only one cache line in the system can be in the Shared Modified state. Potentially two or more caches    have this block and memory may or may not be up to date and this processor's cache had modified the block.&lt;br /&gt;
* '''Shared Clean (Sc)''' -  Potentially two or more caches have this block and memory may or may not be up to date(if no other cache has it in Sm state, memory will be up to date else it is not).&lt;br /&gt;
When a Shared Modified line is evicted from the cache on a cache miss only then is the block written back to the main memory in order to keep memory consistent. For more information on Dragon protocol, refer to Solihin textbook, page number 229. The state transition diagram has been given below for reference.&lt;br /&gt;
&lt;br /&gt;
[[Image:Dragon.jpg|frame|center|&amp;lt;b&amp;gt;Figure 9:&amp;lt;/b&amp;gt; Dragon Protocol State Diagram]]&lt;br /&gt;
&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' , was developed by Xerox Palo Alto Research Center ('''[http://en.wikipedia.org/wiki/Xerox_PARC Xerox PARC]'''), a subsidiary of Xerox Corporation.  This protocol was used in the '''[http://en.wikipedia.org/w/index.php?title=Xerox_Dragon&amp;amp;redirect=no Xerox PARC Dragon]''' multiprocessor workstation, a VLSI research computer that could support multiple processors on a central high bandwidth memory bus. The Dragon design implemented snoopy caches that provided the appearance of a uniform memory space to multiple processors. Here, each cache listens to 2 buses: the processor bus and the memory bus. The caches are also responsible for address translation, so the processor bus carries virtual addresses and the memory bus carries physical addresses.  The Dragon system was designed to support 4 to 8 Dragon processors. The memory bus used in the Xeron Dragon evolved to become the '''[http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=289691 XDBus]''' , a low-cost, synchronous, '''packet-switched VLSI bus''' designed for use in high-performance multiprocessors. This was used as the interconnect in many multiprocessor server systems like '''Cray Superserver 6400''', '''Sun Microsystems' SPARCcenter 2000''' and '''SPARCserver 1000'''  and '''Sun4d''' systems.&lt;br /&gt;
&lt;br /&gt;
=Cache Coherence Power Utilization=&lt;br /&gt;
A number of studies have been performed to reduce the power consumption of cache coherence protocols. In order to perform a solid comparison between the cache coherency protocols, one would need to develop a multi-core processor for each of the cache coherency protocols. Additionally, the hardware and software configuration would also need to be similar between each system (except for the hardware required to implement each of the different protocols). Unfortunately, there are no such processors available. This section will discuss power consumption in general terms, comparing to each of the protocols. Also, this section will briefly discussion some power optimization techniques.&lt;br /&gt;
&lt;br /&gt;
Bus transactions, in general, are costly for both performance and power consumption. Additionally, studies have been performed showing that unnecessary snooping can waste power. Power requirements are typically determined by the number of bus snoops and number of bus accesses by each processor. One study indicates that interchip bus communications can consume up to 20% of total chip power[[#References|&amp;lt;sup&amp;gt;[20]&amp;lt;/sup&amp;gt;]].&lt;br /&gt;
Using the examples from the class notes, we can analyze the relative power consumption between the protocols. The following table is a summary of various protocols showing the number of bus communications that occur for each processor action.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|'''Processor Action'''&lt;br /&gt;
|'''MSI Bus Actions'''&lt;br /&gt;
|'''MESI Bus Actions'''&lt;br /&gt;
|'''Dragon Bus Actions'''&lt;br /&gt;
|'''FireFly Bus Actions'''&lt;br /&gt;
|-&lt;br /&gt;
|R1&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|-&lt;br /&gt;
|W1&lt;br /&gt;
|BusRdX&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R3&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|-&lt;br /&gt;
|W3&lt;br /&gt;
|BusRdX&lt;br /&gt;
|BusRdX&lt;br /&gt;
|BusUpd/Upd&lt;br /&gt;
|BusUpd&lt;br /&gt;
|-&lt;br /&gt;
|R1&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R3&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R2&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 4:&amp;lt;/b&amp;gt; Summary of Bus Actions for Select Protocols&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
From the table above, we can see that MSI has a larger number of bus transactions than the Dragon protocol. Even though bus transactions are not power efficient, snooping can also be enhanced to improve power efficiency. The following section will discuss snoop filtering techniques.&lt;br /&gt;
&lt;br /&gt;
==Power Savings Using Snoop Filtering==&lt;br /&gt;
A number of studies have been performed to reduce the number of unnecessary snoops during cache transactions. Two such filtering techniques are serial snooping and Jetty. The following sections will briefly discuss these two filtering techniques and power savings achieved using these techniques. Studies show that as much as 90% of snoop broadcasts will result in a miss[[#References|&amp;lt;sup&amp;gt;[19]&amp;lt;/sup&amp;gt;]] in the other caches at the same level and require that the information be provided by the next level of cache or memory. As much as a 36% savings in power by filtering snoops using one of the following snoop filtering methods[[#References|&amp;lt;sup&amp;gt;[19]&amp;lt;/sup&amp;gt;]].&lt;br /&gt;
===Serial Snooping===&lt;br /&gt;
Serial snooping takes advantage of the fact that if a miss occurs in one cache, it is possible to find the block in one other cache without having to check all the caches. If the cache block is available in multiple caches, there is a high probability that the cache miss can find the data in a nearby cache. Alternatively, savings can be realized by searching a subset of the caches vice all the caches. One thing to note is that this is only effective for read misses. Write, an invalidation transaction needs to be transmitted to the other caches, thus a bus transaction is unavoidable.&lt;br /&gt;
===Jetty===&lt;br /&gt;
Jetty is a mechanism attached to each cache that verifies that a bus snoop is necessary. Jetty is used to filter L2 tag lookups. When a processor needs to perform a bus snoop, the Jetty is checked first. The Jetty can determine if a cache tag lookup is required. Since the Jetty is much smaller than the associated cache, less power is required to determine if a snoop is required.&lt;br /&gt;
&lt;br /&gt;
There are a couple of different Jetty schemes. There is the exclude-Jetty, include-Jetty, and hybrid-Jetty. The exclude-Jetty exploits the fact that if a cache block is snooped, it is highly likely the same cache block will be snooped in the near future. The exclude-Jetty keeps track of the tag lookups in a small table and can determine if a cache tag lookup is necessary.&lt;br /&gt;
&lt;br /&gt;
The include-Jetty keeps a superset of the blocks that are cached. If a miss occurs in the include-Jetty, then it can be guaranteed that the block is not stored in its associated cache.&lt;br /&gt;
&lt;br /&gt;
The hybrid-Jetty is simply a combinations of and include and exclude-Jetty. Both types of Jetty are present and when a lookup occurs, both Jettys are checked to determine if a cache lookup is necessary.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Cache_coherence Cache coherence]&lt;br /&gt;
# [http://www.intel.com/technology/quickpath/introduction.pdf Introduction to QuickPath Interconnect]&lt;br /&gt;
# [http://www.intel.com/technology/itj/2006/volume10issue02/art02_CMP_Implementation/p03_implementation.htm CMP Implementation in Intel Core Duo Processors]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Symmetric_multiprocessing Common System Interface in Intel Processors]&lt;br /&gt;
# [http://www.zak.ict.pwr.wroc.pl/nikodem/ak_materialy/Cache%20consistency%20&amp;amp;%20MESI.pdf Cache consistency with MESI on Intel processor]&lt;br /&gt;
# [http://techreport.com/articles.x/8236/2 AMD dual core Architecture]&lt;br /&gt;
# [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD64 Architecture Programmer's manual]&lt;br /&gt;
# [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf Software Optimization guide for AMD 10h Processors]&lt;br /&gt;
# [http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html Architecture of AMD 64 bit core]&lt;br /&gt;
# [http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=4913 Silicon Graphics Computer Systems]&lt;br /&gt;
# [http://books.google.com/books?id=g82fofiqa5IC&amp;amp;printsec=frontcover&amp;amp;dq=Parallel+computer+architecture:+a+hardware/software+approach+By+David+E.+Culler,+Jaswinder+Pal+Singh,+Anoop+Gupta&amp;amp;source=bl&amp;amp;ots=COrdamlfVn&amp;amp;sig=YcugVqbzTjHvlofvaFq6Ft_tjfY&amp;amp;hl=en&amp;amp;ei=0ZO6S4TJGcOclgejzI3BBw&amp;amp;sa=X&amp;amp;oi=book_result&amp;amp;ct=result&amp;amp;resnum=1&amp;amp;ved=0CAgQ6AEwAA#v=onepage&amp;amp;q=&amp;amp;f=false Parallel computer architecture: a hardware/software approach By David E. Culler, Jaswinder Pal Singh, Anoop Gupta]&lt;br /&gt;
# [http://www.freepatentsonline.com/5283886.html Three state invalidation protocols]&lt;br /&gt;
# [http://portal.acm.org/citation.cfm?id=1499317&amp;amp;dl=GUIDE&amp;amp;coll=GUIDE&amp;amp;CFID=83027384&amp;amp;CFTOKEN=95680533 Synapse tightly coupled multiprocessors: a new approach to solve old problems]&lt;br /&gt;
# [http://portal.acm.org/citation.cfm?id=6514Cache Coherence protocols: evaluation using a multiprocessor simulation model]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Xerox_Dragon Xerox Dragon]&lt;br /&gt;
# [http://thanaseto.110mb.com/courses/CSD-527-report-engl.pdf Coherence Protocols]&lt;br /&gt;
# [http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=289691 XDBus]&lt;br /&gt;
# [http://www.ece.wisc.edu/~wddd/2002/final/ekman.pdf Evaluation of Snoop-Energy Reduction Techniques for Chip-Multiprocessors]&lt;br /&gt;
# [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.79.7463&amp;amp;rep=rep1&amp;amp;type=pdf Power Efficient Cache Coherence]&lt;/div&gt;</summary>
		<author><name>Mqtran</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2011/ch8_mc&amp;diff=44453</id>
		<title>CSC/ECE 506 Spring 2011/ch8 mc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2011/ch8_mc&amp;diff=44453"/>
		<updated>2011-03-19T20:08:51Z</updated>

		<summary type="html">&lt;p&gt;Mqtran: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Introduction to bus-based cache coherence in real machines=&lt;br /&gt;
&lt;br /&gt;
Most parallel software in the commercial market relies on the shared-memory&lt;br /&gt;
programming model in which all processors access the same physical address space. The most common multiprocessors today use [http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP] architecture which use a common bus as the interconnect.  In the case of multicore processors (&amp;quot;chip multiprocessors,&amp;quot; or CMP) the [http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP] architecture applies to the cores treating them as separate processors. The key problem of shared-memory multiprocessors is providing a consistent view of memory with various cache hierarchies.  This is called '''''cache coherence problem'''''. It is  critical to  achieve correctness and performance-sensitive design point for supporting the shared-memory model. The cache coherence mechanisms not only govern communication in a shared-memory multiprocessor, but also typically determine how the memory system transfers data between processors, caches, and memory.&lt;br /&gt;
&lt;br /&gt;
[[Image:Busbased SMP.jpg|frame|center|&amp;lt;b&amp;gt;Figure 1:&amp;lt;/b&amp;gt; Typical Bus-Based Processor Model]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Cache Coherence in real machines=&lt;br /&gt;
==Summary of Cache Coherence Protocols==&lt;br /&gt;
At any point in logical time, the permissions for a cache block can allow either a single writer or multiple readers. The '''''coherence protocol''''' ensures the invariants of the states are maintained. The different coherent states used by most of the cache coherent protocols are as shown in ''Table 1'':&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''States'''&lt;br /&gt;
|  '''Access Type'''&lt;br /&gt;
|  '''Invariant'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  read, write&lt;br /&gt;
|  all other caches in I state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  read&lt;br /&gt;
|  all other caches in I state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Owned'''&lt;br /&gt;
|  read&lt;br /&gt;
|  all other caches in I or S state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  read&lt;br /&gt;
|  no other cache in M or E state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|  -&lt;br /&gt;
|  -&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 1:&amp;lt;/b&amp;gt; States Used by the Cache Coherent Protocols&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
The first widely adopted approach to cache coherence is snooping on a bus. We will now discuss how some real time machines by '''Intel''', '''AMD''' and other processors maintain cache coherence using '''''snooping based coherence protocols'''''.  For more information on snooping based protocols refer to Solihin text book Chapter 8.&lt;br /&gt;
&lt;br /&gt;
==SGI - Silicon Graphics, Inc==&lt;br /&gt;
===MSI &amp;amp; SGI IRIS 4D Processors===&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' is a three-state write-back '''invalidation protocol''' which is one of the earliest snooping-based cache coherence-protocols. It marks the cache line in '''Modified (M) ,Shared (S)''', and '''Invalid (I)''' state. '''Invalid''' means the cache line is either not present or is invalid state. If the cache line is clean and is shared by more than one processor , it is marked '''shared'''. If cache line is dirty and the processor has exclusive ownership of the cache line, it is present in '''Modified''' state. BusRdx causes other processors to invalidate (demote) its cache block to the '''I''' state. If it is present in the '''M''' state in another cache, it will flush. BusRdx, even if hit in '''S''' state, is promoted to '''M''' (upgrade) state.&lt;br /&gt;
&lt;br /&gt;
The following state transition diagram for MSI protocol explains the working of the protocol:&lt;br /&gt;
&lt;br /&gt;
[[Image:MSI.jpg|frame|center|&amp;lt;b&amp;gt;Figure 2:&amp;lt;/b&amp;gt; MSI State Diagram]]&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' protocol was first used in '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''' IRIS 4D series. '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''' produced a broad range of '''[http://en.wikipedia.org/wiki/MIPS_architecture MIPS]'''-based (Microprocessor without Interlocked Pipeline Stages) workstations and servers during the 1990s, running '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''''s version of UNIX System V, now called '''[http://en.wikipedia.org/wiki/IRIX IRIX]'''. The 4D-MP graphics superworkstation brought 40 MIPS(million instructions per second) of computing performance to a graphics superworkstation. The unprecedented level of computing and graphics processing in an office-environment workstation was made possible by the fastest available Risc microprocessors in a single shared memory multiprocessor design driving a tightly coupled, highly parallel graphics system. Aggregate sustained data rates of over one gigabyte per second were achieved by a hierarchy of buses in a balanced system designed to avoid bottlenecks.&lt;br /&gt;
&lt;br /&gt;
The multiprocessor bus used in 4D-MP graphics superworkstation is a pipelined, block transfer bus that supports the cache coherence protocol as well as providing 64 megabytes of sustained data bandwidth between the processors, the memory and I/O system, and the graphics subsystem. Because the sync bus provides for efficient synchronization between processors, the cache coherence protocol was designed to support efficient data sharing between processors. If a cache coherence protocol has to support synchronization as well as sharing, a compromise in the efficiency of the data sharing protocol may be necessary to improve the efficiency of the synchronization operations. Hence it uses the simple cache coherence protocol which is the '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' protocol.&lt;br /&gt;
&lt;br /&gt;
With the simple rules of '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' enforced by the hardware protocols of&lt;br /&gt;
the sync bus and the Multiprocessor bus, efficient synchronization and efficient data sharing are achieved in a simple shared memory model of parallel processing in the 4D-MP graphics superworkstation.&lt;br /&gt;
&lt;br /&gt;
==SYNAPSE Multiprocessor==&lt;br /&gt;
===Synapse protocol and Synapse multiprocessor===&lt;br /&gt;
From the state transition diagram of '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''', we observe that for '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' there is transition to the '''S''' state from the '''M''' state when a BusRd is observed for that block. The contents of the block is flushed to the bus before going to '''S''' state. It would look more appropriate to move to the '''I''' state thus giving up the block entirely in certain cases. This choice of moving to '''S''' or '''I''' reflects the designer's assertion that the original processor is more likely to continue reading the block than the new processor to write to the block. In synapse protocol, used in the early Synapse multiprocessor, made this alternate choice of going directly from the '''M''' state to the '''I''' state on a BusRd, assuming the migratory pattern would be more frequent. More details about this protocol can be found in these papers published in late 1980's [http://portal.acm.org/citation.cfm?id=6514Cache Coherence protocols: evaluation using a multiprocessor simulation model] and [http://portal.acm.org/citation.cfm?id=1499317&amp;amp;dl=GUIDE&amp;amp;coll=GUIDE&amp;amp;CFID=83027384&amp;amp;CFTOKEN=95680533 Synapse tightly coupled multiprocessors: a new approach to solve old problems]&lt;br /&gt;
&lt;br /&gt;
In the Synapse protocol, the '''M''' state is called the '''D''' (Dirty) state. The following is the state transition diagram for Synapse protocol which clearly shows its working.&lt;br /&gt;
&lt;br /&gt;
[[Image:Synapse1.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; Synapse State Diagram]]&lt;br /&gt;
&lt;br /&gt;
==Intel==&lt;br /&gt;
===MESI &amp;amp; Intel Processors===&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' has a major drawback in that each read-write sequence incurs two bus transactions irrespective of whether the cache line is stored in only one cache or not. This is a huge setback for highly parallel programs that have little data sharing. '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol solves this problem by introducing the E ('''Exclusive''') state to distinguish between a cache line stored in multiple caches and a line stored in a single cache.&lt;br /&gt;
Let us briefly see how the MESI protocol works. For a more detailed version refer Solihin textbook pg. 215.&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' coherence protocol marks each cache line in of the Modified, Exclusive, Shared, or Invalid state. &lt;br /&gt;
* '''Invalid''' : The cache line is either not present or is invalid&lt;br /&gt;
* '''Exclusive''' : The cache line is clean and is owned by this core/processor only&lt;br /&gt;
* '''Modified''' :  This implies that the cache line is dirty and the core/processor has  exclusive ownership of the cache line,exclusive of the memory also.&lt;br /&gt;
* '''Shared''' : The cache line is clean and is shared by more than one core/processor&lt;br /&gt;
&lt;br /&gt;
In a nutshell, the '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol works as follows: &lt;br /&gt;
A line that is fetched, receives '''E''', or '''S''' state depending on whether it exists in other processors in the system. A cache line gets the '''M''' state when a processor writes to it; if the line is not in '''E''' or '''M'''-state prior to writing it, the cache sends a Bus Upgrade (BusUpgr) signal or as the Intel manuals term it, “Read-For-Ownership (RFO) request” that ensures that the line exists in the cache and is in the '''I''' state in all other processors on the bus (if any). The table is shown below to summarize '''[http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol'''.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''Cache Line State:'''&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''This cache line is valid?'''&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  No&lt;br /&gt;
|-&lt;br /&gt;
|  '''The memory copy is…'''&lt;br /&gt;
|  out of date&lt;br /&gt;
|  valid&lt;br /&gt;
|  valid&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''Copies exist in caches of other processors?'''|  No&lt;br /&gt;
|  No&lt;br /&gt;
|  Maybe&lt;br /&gt;
|  Maybe&lt;br /&gt;
|-&lt;br /&gt;
|  '''A write to this line'''|  does not go to bus&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  goes to bus and updates cache&lt;br /&gt;
|  goes directly to bus&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 2:&amp;lt;/b&amp;gt; MESI Protocol Summary&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The transition diagram from the lecture slides is given below for reference.&lt;br /&gt;
&lt;br /&gt;
[[Image:MESI.jpg|frame|center|&amp;lt;b&amp;gt;Figure 4:&amp;lt;/b&amp;gt; MESI State Diagram]]&lt;br /&gt;
&lt;br /&gt;
The '''Pentium Pro''' microprocessor, introduced in 1992 was the '''first''' Intel architecture microprocessor to support symmetric multiprocessing ('''[http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP]''') in various multiprocessor configurations. '''[http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP]''' and '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol was the architecture used consistently until the introduction of the 45-nm Hi-k Core micro-architecture in '''Intel's (Nehalem-EP) quad-core x86-64'''. The 45-nm Hi-k Intel Core microarchitecture utilizes a new system of framework called the '''QuickPath Interconnect''' which uses point-to-point interconnection technology based on distributed shared memory architecture. It uses a modified version of '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol called '''MESIF''', by introducing an additional state, F, the forward state. &lt;br /&gt;
&lt;br /&gt;
The '''Intel architecture''' uses the '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol  as the '''basis''' to ensure cache coherence, which is true whether you're on one of the older processors that use a '''common bus''' to communicate or using the new Intel '''QuickPath''' point-to-point interconnection technology. &lt;br /&gt;
&lt;br /&gt;
Let us now walk through a briefing on the '''MESIF protocol''':&lt;br /&gt;
&lt;br /&gt;
The '''MESIF''' protocol, used in the latest Intel multi-core processors was introduced to '''accommodate the point-to-point''' links used in the QuickPath Interconnect. Using the '''MESI''' protocol in this architecture would send many redundant messages between different processors, often with unnecessarily high latency. For example, when a processor requests a cache line that is stored in multiple locations, every location might respond with the data. As the the requesting processor only needs a single copy of the data, the system would be '''wasting the bandwidth'''. &lt;br /&gt;
As a '''solution''' to this problem, an additional state, '''Forward state''', was added by slightly changing the role of the Shared state. Whenever there is a read request, only the cache line in the F state will respond to the request, while all the S state caches remain dormant.  Hence, by designating a single cache line to '''respond to requests''', coherency traffic is substantially reduced when multiple copies of the data exist. Also, on a read request, the F state transitions from F to S state. That is, when a cache line in the '''F''' state is '''copied''', the F state '''migrates''' to the '''newer copy''', while the '''older''' one drops back to '''S'''. Moving the new copy to the F state '''exploits''' both '''temporal and spatial locality'''. Because the newest copy of the cache line is always in the F state, it is very unlikely that the line in the F state will be evicted from the caches. This takes advantage of the temporal locality of the request. The second advantage is that if a particular cache line is in high demand due to spatial locality, the bandwidth used to transmit that data will be spread across several nodes.&lt;br /&gt;
All M to S state transition and E to S state transitions will now be from '''M to F''' and '''E to F'''.  &lt;br /&gt;
The '''F state''' is '''different''' from the '''Owned state''' of the MOESI protocol as it is '''not''' a '''unique''' copy because a valid copy is stored in memory. Thus, unlike the Owned state of the MOESI protocol, in which the data in the O state is the only valid copy of the data, the data in the F state can be evicted or converted to the S state, if desired. &lt;br /&gt;
&lt;br /&gt;
More information on the QuickPath Interconnect and MESIF protocol can be found at&lt;br /&gt;
'''[http://www.intel.com/technology/quickpath/introduction.pdf Introduction to QuickPath Interconnect]'''&lt;br /&gt;
&lt;br /&gt;
=== CMP Implementation in Intel Architecture ===&lt;br /&gt;
&lt;br /&gt;
Let us now see how Intel architecture using the [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol progressed from a uniprocessor architecture to a Chip MultiProcessor (CMP) using the bus as the interconnect. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Uniprocessor Architecture'''&lt;br /&gt;
&lt;br /&gt;
The diagram below shows the structure of the memory cluster in Intel Pentium M processor.&lt;br /&gt;
&lt;br /&gt;
[[Image:intel_cache1.jpg|frame|center|&amp;lt;b&amp;gt;Figure 5:&amp;lt;/b&amp;gt; Memory Structure of the Pentium M Processor]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In this structure we have,&lt;br /&gt;
* A unified on-chip '''L1 cache''' with the '''processor/core''',&lt;br /&gt;
* A '''Memory/L2 access control unit''', through which all the accesses to the L2 cache, main memory and IO space are made,&lt;br /&gt;
* The second level '''L2 cache''' along with the '''prefetch unit''' and&lt;br /&gt;
* '''Front side bus (FSB)''', a single shared bi-directional bus through which all the traffic is sent across.These wide buses bring in multiple data bytes at a time. &lt;br /&gt;
&lt;br /&gt;
As Intel explains it, using this structure, the processor requests were first sought in the '''L2 cache''' and only on a '''miss''', were they '''forwarded''' to the main '''memory''' via the front side bus ('''FSB'''). The '''Memory/L2 access control''' unit served as a central point for '''maintaining coherence''' within the core and with the external world. It '''contains''' a '''snoop control unit''' that receives snoop requests from the bus and performs the required operations on each cache (and internal buffers) in parallel. It also handles RFO requests (BusUpgr) and ensures the operation continues only after it guarantees that no other version on the cache line exists in any other cache in the system.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''CMP Architecture'''&lt;br /&gt;
&lt;br /&gt;
For CMP implementation, Intel chose the bus-based architecture using snoopy protocols vs the '''directory protocol''' because though directory protocol reduces the active power due to reduced snoop activity, it '''increased''' the '''design complexity''' and the '''static power''' due to larger tag arrays. Since Intel has a large market for the processors in the mobility family, directory-based solution was less favorable since battery life mainly depends on static power consumption and less on dynamic power.&lt;br /&gt;
Let us examine how '''CMP''' was implemented in '''Intel Core Duo''', which was one of the first dual-core processor for the budget/entry-level market. &lt;br /&gt;
The general CMP implementation structure of the Intel Core Duo is shown below&lt;br /&gt;
&lt;br /&gt;
[[Image:intel_cache2.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; Intel Core Duo CMP Implementation]]&lt;br /&gt;
&lt;br /&gt;
This structure has the following changes when compared to the uniprocessor memory cluster structure. &lt;br /&gt;
* '''L1 cache''' and the '''processor/core''' structure is '''duplicated''' to give 2 cores.&lt;br /&gt;
* The '''Memory/L2 access control''' unit is '''split''' into 2 logical units: '''L2 controller''' and '''bus controller'''. The L2 controller handles all '''requests to the L2''' cache from the core and the snoop requests from the FSB. The '''bus controller''' handles '''data and I/O requests''' to and from the FSB.&lt;br /&gt;
* The '''prefetching''' unit is extended to handle the hardware '''prefetches for each core separately'''.&lt;br /&gt;
* A '''new logical unit''' (represented by the hexagon) was added to maintain '''fairness between the requests''' coming from the different cores and hence balance the requests to L2 and memory.&lt;br /&gt;
&lt;br /&gt;
This new '''partitioned structure''' for the  memory/L2 access control unit '''enhanced''' the '''performance''' while '''reducing power consumption'''. &lt;br /&gt;
For more information on uniprocessor and multiprocessor implementation under the Intel architecture, refer to &lt;br /&gt;
[http://www.intel.com/technology/itj/2006/volume10issue02/art02_CMP_Implementation/p03_implementation.htm CMP Implementation in Intel Core Duo Processors]&lt;br /&gt;
&lt;br /&gt;
The '''Intel bus architecture''' has been '''evolving''' in order to accommodate the demands of scalability while using the '''same [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol'''; From using a '''single shared bus''' to '''dual independent buses (DIB)''' doubling the available bandwidth and to the logical conclusion of DIB with the introduction of '''dedicated high-speed interconnects (DHSI)'''. The DHSI-based platforms use four FSBs, one for each processor in the platform. In both DIB and DHSI, the snoop filter was used in the chipset to cache snoop information, thereby significantly reducing the broadcasting needed for the snoop traffic on the buses. With the production of processors based on next generation 45-nm Hi-k Intel Core microarchitecture, the [http://en.wikipedia.org/wiki/Xeon Intel Xeon] processor fabric will transition from a DHSI, with the memory controller in the chipset, to a distributed shared memory architecture using '''Intel QuickPath Interconnects using MESIF protocol'''.&lt;br /&gt;
&lt;br /&gt;
==AMD - Advanced Micro Devices Processors==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===MOESI &amp;amp; AMD Processors===&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/Opteron AMD Opteron] was AMD’s first-generation dual core which had two distinct [http://en.wikipedia.org/wiki/Athlon_64 K8 cores] together on a single die. Cache coherence produces bigger problems on such multiprocessors. It was necessary to use an appropriate coherence protocol to address this problem. The [http://en.wikipedia.org/wiki/Xeon Intel Xeon], which was the competitive counterpart from Intel to AMD dual core Opteron, used the [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol to handle cache coherence. [http://en.wikipedia.org/wiki/MESI_protocol MESI] came with the drawback of using much time and bandwidth in certain situations. &lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/MOESI_protocol MOESI] was AMD’s answer to this problem. [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] added a fifth state to [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol called the '''owned''' state. [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] addresses the bandwidth problem faced in MESI protocol when processor having invalid data in its cache wants to modify the data.  The processor seeking the data access will have to wait for the processor which modified this data to write back to the main memory, which takes time and bandwidth. This drawback is removed in MOESI by allowing dirty sharing.  When the data is held by a processor in the new state '''owned''', it can provide other processors the modified data without or even before writing it to the main memory. This is called '''''dirty sharing'''''. The processor with the data in the '''owned''' state stays responsible to update the main memory later when the cache line is evicted.&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/MOESI_protocol MOESI]  has become one of the most popular snoop-based protocols supported in AMD64 architecture.  AMD dual-core Opteron can maintain cache coherence in systems up to 8 processors using this protocol.&lt;br /&gt;
&lt;br /&gt;
The five different states of [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol are:&lt;br /&gt;
* '''Modified (M)''': The most recent copy of the data is present in the cache line. But it is not present in any other processor cache.&lt;br /&gt;
* '''Owned (O)''': The cache line has the most recent correct copy of the data. This can be shared by other processors. The processor in this state for this cache line is responsible to update the correct value in the main memory before it gets evicted.&lt;br /&gt;
* '''Exclusive (E)''': A cache line holds the most recent, correct copy of the data, which is exclusively present on this processor and a copy is present in the main memory.&lt;br /&gt;
* '''Shared (S)''': A cache line in the shared state holds the most recent, correct copy of the data, which may be shared by other processors.&lt;br /&gt;
* '''Invalid (I)''': A cache line does not hold a valid copy of the data.&lt;br /&gt;
&lt;br /&gt;
A detailed explanation of this protocol implementation on AMD processor can be found in the manual [http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html Architecture of AMD 64-bit core]&lt;br /&gt;
&lt;br /&gt;
The following table summarizes the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''Cache Line State:'''&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  '''Owner''' &lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''This cache line is valid?'''&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  No&lt;br /&gt;
|-&lt;br /&gt;
|  '''The memory copy is…'''&lt;br /&gt;
|  out of date&lt;br /&gt;
|  out of date&lt;br /&gt;
|  valid&lt;br /&gt;
|  valid&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''Copies exist in caches of other processors?'''&lt;br /&gt;
|  No&lt;br /&gt;
|  No&lt;br /&gt;
|  Yes(out of date values)|  Maybe&lt;br /&gt;
|  Maybe&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''A write to this line'''&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  does not go to bus|  does not go to bus&lt;br /&gt;
|  goes to bus and updates cache&lt;br /&gt;
|  goes directly to bus&lt;br /&gt;
|  -&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 3:&amp;lt;/b&amp;gt; MOESI Protocol Summary&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
State transition for [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]is as shown below : &lt;br /&gt;
&lt;br /&gt;
[[Image:MOESI_State_Transition_Diagram.jpg|frame|center|&amp;lt;b&amp;gt;Figure 7:&amp;lt;/b&amp;gt; [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]State transition Diagram]]&lt;br /&gt;
&lt;br /&gt;
===AMD Opteron memory Architecture===&lt;br /&gt;
&lt;br /&gt;
[[Image:Untitled.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; AMD Opteron memory Architecture]]&lt;br /&gt;
&lt;br /&gt;
The AMD processor’s high-performance cache architecture includes an integrated, 64-bit, dual-ported  128-Kbyte split-L1 cache with separate snoop port, multi-level translation lookaside buffers (TLBs), a scalable L2 cache controller with a 72-bit (64-bit data + 8-bit ECC) interface to as much as 8-Mbyte of industry-standard SDR or DDR SRAMs, and an integrated tag for the most cost-effective 512-Kbyte L2 configurations. The AMD Athlon processor’s integrated L1 cache comprises two separate 64-Kbyte, two-way set-associative data and instruction caches.&lt;br /&gt;
&lt;br /&gt;
More information about this can be found in [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD 64 bit Architecture Programmers's Manual]&lt;br /&gt;
&lt;br /&gt;
===Special Coherence Considerations in AMD64 architectures===&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
Instruction prefetching is a technique used to speedup the execution of the program. But in multiprocessors, prefetching comes at the cost of performance. Due to prefetching, the data can be modified in such a way that the memory coherence protocol will not be able to handle the effects. In such situations software must use serializing instructions or cache-invalidation instructions to guarantee subsequent data accesses are coherent. &lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
An example of this type of a situation is a page-table update followed by accesses to the physical pages referenced by the updated page tables. The physical-memory references for the page tables are different than the physical-memory references for the data. Because of prefetching, there maybe problem with correctness. The following sequence of events shows such a situation when software changes the translation of virtual-page A from physical-page M to physical-page N:&lt;br /&gt;
# The tables that translate virtual-page A to physical-page M are now held only in main memory. The copies in the cache ae invalidated.&lt;br /&gt;
# Page-table entry is changed by the software for virtual-page A in main memory to point to physical page N rather than physical-page M.&lt;br /&gt;
# Data in virtual-page A is accessed.&lt;br /&gt;
&lt;br /&gt;
Software expects the processor to access the data from physical-page N after the update. However, it is possible for the processor to prefetch the data from physical-page M before the page table for virtual page A is updated. Because the physical-memory references are different, the processor does not recognize them as requiring coherence checking and believes it is safe to prefetch the data from virtual-page A, which is translated into a read from physical page M. Similar behavior can occur when instructions are prefetched from beyond the page table update instruction.&lt;br /&gt;
&lt;br /&gt;
In order to prevent errors from occuring, there are special instructions provided by software like INVLPG or MOV CR3 instruction which is executed immediately after the page-table update to ensure that subsequent instruction fetches and data accesses use the correct virtual-page-to-physical-page translation. It is not necessary to perform a TLB invalidation operation preceding the table update.&lt;br /&gt;
&lt;br /&gt;
More information can be found about this in [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD64 Architecture Programmer's manual]&lt;br /&gt;
&lt;br /&gt;
===Optimization techniques on MOESI when implemented on AMD Phenom processors===&lt;br /&gt;
&lt;br /&gt;
In real machines, using some optimization techniques on the standard cache coherence protocol used, improves the performance of the machine. For example, [http://en.wikipedia.org/wiki/AMD_Phenom AMD Phenom] family of microprocessors (Family 0×10) which is AMD’s first generation to incorporate 4 distinct cores on a single die. It is the first to have a cache that all the cores share, using the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol with some optimization techniques incorporated. &lt;br /&gt;
&lt;br /&gt;
It focuses on a small subset of compute problems which behave like Producer and Consumer programs. In such a computing problem, a thread of a program running on a single core produces data, which is consumed by a thread that is running on a separate core. With such programs, it is desirable to get the two distinct cores to communicate through the shared cache, to avoid round trips to/from main memory. The '''MOESI''' protocol that the [http://en.wikipedia.org/wiki/AMD_Phenom AMD Phenom] cache uses for cache coherence can also limit bandwidth. Hence by keeping the cache line in the '''M''' state for such computing problems, we can achieve better performance.&lt;br /&gt;
&lt;br /&gt;
When the producer thread , writes a new entry, it allocates cache-lines in the '''M''' state. Eventually, these M-marked cache lines will start to fill the L3 cache. When the consumer reads the cache line, the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol changes the state of the cache line to the '''O''' state in the L3 cache and pulls down a '''shared (S)''' copy for its own use. Now, the producer thread circles the ring buffer to arrive back to the same cache line it had previously written. However, when the producer attempts to write new data to the owned (marked '''‘O’''') cache line, it finds that it cannot, since a cache line in the '''O''' state by the previous consumer read does not have sufficient permission for a write request (in the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]). To maintain coherence, the memory controller must initiate probes in the other caches (to handle any other S copies that may exist). This will slow down the process.&lt;br /&gt;
&lt;br /&gt;
Thus, it is preferable to keep the cache line in the '''M''' state in the L3 cache. In such a situation, when the producer comes back around the ring buffer, it finds the previously written cache line still in the'''M''' state, to which it is safe to write without coherence concerns. Thus better performance can be achieved by such optimization techniques to standard protocols when implemented in real machines.&lt;br /&gt;
&lt;br /&gt;
You can find more information on how this is implemented and various other ways of optimizations in this manual [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf Software Optimization guide for AMD 10h Processors].&lt;br /&gt;
&lt;br /&gt;
==Xerox Corporation==&lt;br /&gt;
===Dragon Protocol &amp;amp; Xerox Dragon Processors===&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' is an update based coherence protocol which does not invalidate other cached copies like what we have seen in the coherence protocols so far. Write propagation is achieved by updating the cached copies instead of invalidating them.  But the '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' does not update memory on a cache to cache transfer and delays the memory and cache consistency until the data is evicted and written back, which saves time and lowers the memory access requirements. Moreover only the written '''byte''' or the '''word''' is '''communicated''' to the '''other caches''' instead of the whole block which further '''reduces''' the '''bandwidth''' usage. It has the ability to detect dynamically, the sharing status of a block and use a write through policy for shared blocks and write back for currently non-shared blocks. The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' employs the following four states for the cache blocks: '''Shared Clean''', '''Shared Modified''', '''Exclusive''', and  '''Modified'''. &lt;br /&gt;
* '''Modified (M)''' and '''Exclusive (E)''' - these states have the same meaning as explained in the protocols above. &lt;br /&gt;
* '''Shared Modified (Sm)''' - Only one cache line in the system can be in the Shared Modified state. Potentially two or more caches    have this block and memory may or may not be up to date and this processor's cache had modified the block.&lt;br /&gt;
* '''Shared Clean (Sc)''' -  Potentially two or more caches have this block and memory may or may not be up to date(if no other cache has it in Sm state, memory will be up to date else it is not).&lt;br /&gt;
When a Shared Modified line is evicted from the cache on a cache miss only then is the block written back to the main memory in order to keep memory consistent. For more information on Dragon protocol, refer to Solihin textbook, page number 229. The state transition diagram has been given below for reference.&lt;br /&gt;
&lt;br /&gt;
[[Image:Dragon.jpg|frame|center|&amp;lt;b&amp;gt;Figure 9:&amp;lt;/b&amp;gt; Dragon Protocol State Diagram]]&lt;br /&gt;
&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' , was developed by Xerox Palo Alto Research Center ('''[http://en.wikipedia.org/wiki/Xerox_PARC Xerox PARC]'''), a subsidiary of Xerox Corporation.  This protocol was used in the '''[http://en.wikipedia.org/w/index.php?title=Xerox_Dragon&amp;amp;redirect=no Xerox PARC Dragon]''' multiprocessor workstation, a VLSI research computer that could support multiple processors on a central high bandwidth memory bus. The Dragon design implemented snoopy caches that provided the appearance of a uniform memory space to multiple processors. Here, each cache listens to 2 buses: the processor bus and the memory bus. The caches are also responsible for address translation, so the processor bus carries virtual addresses and the memory bus carries physical addresses.  The Dragon system was designed to support 4 to 8 Dragon processors. The memory bus used in the Xeron Dragon evolved to become the '''[http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=289691 XDBus]''' , a low-cost, synchronous, '''packet-switched VLSI bus''' designed for use in high-performance multiprocessors. This was used as the interconnect in many multiprocessor server systems like '''Cray Superserver 6400''', '''Sun Microsystems' SPARCcenter 2000''' and '''SPARCserver 1000'''  and '''Sun4d''' systems.&lt;br /&gt;
&lt;br /&gt;
=Cache Coherence Power Utilization=&lt;br /&gt;
A number of studies have been performed to reduce the power consumption of cache coherence protocols. In order to perform a solid comparison between the cache coherency protocols, one would need to develop a multi-core processor for each of the cache coherency protocols. Additionally, the hardware and software configuration would also need to be similar between each system (except for the hardware required to implement each of the different protocols). Unfortunately, there are no such processors available. This section will discuss power consumption in general terms, comparing to each of the protocols. Also, this section will briefly discussion some power optimization techniques.&lt;br /&gt;
&lt;br /&gt;
Bus transactions, in general, are costly for both performance and power consumption. Additionally, studies have been performed showing that unnecessary snooping can waste power. Power requirements are typically determined by the number of bus snoops and number of bus accesses by each processor. One study indicates that interchip bus communications can consume up to 20% of total chip power[[#References|&amp;lt;sup&amp;gt;[20]&amp;lt;/sup&amp;gt;]].&lt;br /&gt;
Using the examples from the class notes, we can analyze the relative power consumption between the protocols. The following table is a summary of various protocols showing the number of bus communications that occur for each processor action.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|'''Processor Action'''&lt;br /&gt;
|'''MSI Bus Actions'''&lt;br /&gt;
|'''MESI Bus Actions'''&lt;br /&gt;
|'''Dragon Bus Actions'''&lt;br /&gt;
|'''FireFly Bus Actions'''&lt;br /&gt;
|-&lt;br /&gt;
|R1&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|-&lt;br /&gt;
|W1&lt;br /&gt;
|BusRdX&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R3&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|-&lt;br /&gt;
|W3&lt;br /&gt;
|BusRdX&lt;br /&gt;
|BusRdX&lt;br /&gt;
|BusUpd/Upd&lt;br /&gt;
|BusUpd&lt;br /&gt;
|-&lt;br /&gt;
|R1&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R3&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R2&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 4:&amp;lt;/b&amp;gt; Summary of Bus Actions for Select Protocols&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
From the table above, we can see that MSI has a larger number of bus transactions than the Dragon protocol. Even though bus transactions are not power efficient, snooping can also be enhanced to improve power efficiency. The following section will discuss snoop filtering techniques.&lt;br /&gt;
&lt;br /&gt;
==Power Savings Using Snoop Filtering==&lt;br /&gt;
A number of studies have been performed to reduce the number of unnecessary snoops during cache transactions. Two such filtering techniques are serial snooping and Jetty. The following sections will briefly discuss these two filtering techniques and power savings achieved using these techniques. Studies show that as much as 90% of snoop broadcasts will result in a miss[[#References|&amp;lt;sup&amp;gt;[19]&amp;lt;/sup&amp;gt;]] in the other caches at the same level and require that the information be provided by the next level of cache or memory. As much as a 36% savings in power by filtering snoops using one of the following snoop filtering methods[[#References|&amp;lt;sup&amp;gt;[19]&amp;lt;/sup&amp;gt;]].&lt;br /&gt;
===Serial Snooping===&lt;br /&gt;
Serial snooping takes advantage of the fact that if a miss occurs in one cache, it is possible to find the block in one other cache without having to check all the caches. If the cache block is available in multiple caches, there is a high probability that the cache miss can find the data in a nearby cache. Alternatively, savings can be realized by searching a subset of the caches vice all the caches. One thing to note is that this is only effective for read misses. Write, an invalidation transaction needs to be transmitted to the other caches, thus a bus transaction is unavoidable.&lt;br /&gt;
===Jetty===&lt;br /&gt;
Jetty is a mechanism attached to each cache that verifies that a bus snoop is necessary. Jetty is used to filter L2 tag lookups. When a processor needs to perform a bus snoop, the Jetty is checked first. The Jetty can determine if a cache tag lookup is required. Since the Jetty is much smaller than the associated cache, less power is required to determine if a snoop is required.&lt;br /&gt;
&lt;br /&gt;
There are a couple of different Jetty schemes. There is the exclude-Jetty, include-Jetty, and hybrid-Jetty. The exclude-Jetty exploits the fact that if a cache block is snooped, it is highly likely the same cache block will be snooped in the near future. The exclude-Jetty keeps track of the tag lookups in a small table and can determine if a cache tag lookup is necessary.&lt;br /&gt;
&lt;br /&gt;
The include-Jetty keeps a superset of the blocks that are cached. If a miss occurs in the include-Jetty, then it can be guaranteed that the block is not stored in its associated cache.&lt;br /&gt;
&lt;br /&gt;
The hybrid-Jetty is simply a combinations of and include and exclude-Jetty. Both types of Jetty are present and when a lookup occurs, both Jettys are checked to determine if a cache lookup is necessary.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Cache_coherence Cache coherence]&lt;br /&gt;
# [http://www.intel.com/technology/quickpath/introduction.pdf Introduction to QuickPath Interconnect]&lt;br /&gt;
# [http://www.intel.com/technology/itj/2006/volume10issue02/art02_CMP_Implementation/p03_implementation.htm CMP Implementation in Intel Core Duo Processors]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Symmetric_multiprocessing Common System Interface in Intel Processors]&lt;br /&gt;
# [http://www.zak.ict.pwr.wroc.pl/nikodem/ak_materialy/Cache%20consistency%20&amp;amp;%20MESI.pdf Cache consistency with MESI on Intel processor]&lt;br /&gt;
# [http://techreport.com/articles.x/8236/2 AMD dual core Architecture]&lt;br /&gt;
# [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD64 Architecture Programmer's manual]&lt;br /&gt;
# [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf Software Optimization guide for AMD 10h Processors]&lt;br /&gt;
# [http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html Architecture of AMD 64 bit core]&lt;br /&gt;
# [http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=4913 Silicon Graphics Computer Systems]&lt;br /&gt;
# [http://books.google.com/books?id=g82fofiqa5IC&amp;amp;printsec=frontcover&amp;amp;dq=Parallel+computer+architecture:+a+hardware/software+approach+By+David+E.+Culler,+Jaswinder+Pal+Singh,+Anoop+Gupta&amp;amp;source=bl&amp;amp;ots=COrdamlfVn&amp;amp;sig=YcugVqbzTjHvlofvaFq6Ft_tjfY&amp;amp;hl=en&amp;amp;ei=0ZO6S4TJGcOclgejzI3BBw&amp;amp;sa=X&amp;amp;oi=book_result&amp;amp;ct=result&amp;amp;resnum=1&amp;amp;ved=0CAgQ6AEwAA#v=onepage&amp;amp;q=&amp;amp;f=false Parallel computer architecture: a hardware/software approach By David E. Culler, Jaswinder Pal Singh, Anoop Gupta]&lt;br /&gt;
# [http://www.freepatentsonline.com/5283886.html Three state invalidation protocols]&lt;br /&gt;
# [http://portal.acm.org/citation.cfm?id=1499317&amp;amp;dl=GUIDE&amp;amp;coll=GUIDE&amp;amp;CFID=83027384&amp;amp;CFTOKEN=95680533 Synapse tightly coupled multiprocessors: a new approach to solve old problems]&lt;br /&gt;
# [http://portal.acm.org/citation.cfm?id=6514Cache Coherence protocols: evaluation using a multiprocessor simulation model]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Xerox_Dragon Xerox Dragon]&lt;br /&gt;
# [http://thanaseto.110mb.com/courses/CSD-527-report-engl.pdf Coherence Protocols]&lt;br /&gt;
# [http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=289691 XDBus]&lt;br /&gt;
# [http://www.ece.wisc.edu/~wddd/2002/final/ekman.pdf Evaluation of Snoop-Energy Reduction Techniques for Chip-Multiprocessors]&lt;br /&gt;
# [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.79.7463&amp;amp;rep=rep1&amp;amp;type=pdf Power Efficient Cache Coherence]&lt;/div&gt;</summary>
		<author><name>Mqtran</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2011/ch8_mc&amp;diff=44452</id>
		<title>CSC/ECE 506 Spring 2011/ch8 mc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2011/ch8_mc&amp;diff=44452"/>
		<updated>2011-03-19T20:03:39Z</updated>

		<summary type="html">&lt;p&gt;Mqtran: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Introduction to bus-based cache coherence in real machines=&lt;br /&gt;
&lt;br /&gt;
Most parallel software in the commercial market relies on the shared-memory&lt;br /&gt;
programming model in which all processors access the same physical address space. The most common multiprocessors today use [http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP] architecture which use a common bus as the interconnect.  In the case of multicore processors (&amp;quot;chip multiprocessors,&amp;quot; or CMP) the [http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP] architecture applies to the cores treating them as separate processors. The key problem of shared-memory multiprocessors is providing a consistent view of memory with various cache hierarchies.  This is called '''''cache coherence problem'''''. It is  critical to  achieve correctness and performance-sensitive design point for supporting the shared-memory model. The cache coherence mechanisms not only govern communication in a shared-memory multiprocessor, but also typically determine how the memory system transfers data between processors, caches, and memory.&lt;br /&gt;
&lt;br /&gt;
[[Image:Busbased SMP.jpg|frame|center|&amp;lt;b&amp;gt;Figure 1:&amp;lt;/b&amp;gt; Typical Bus-Based Processor Model]]&lt;br /&gt;
&lt;br /&gt;
At any point in logical time, the permissions for a cache block can allow either a single writer or multiple readers. The '''''coherence protocol''''' ensures the invariants of the states are maintained. The different coherent states used by most of the cache coherent protocols are as shown in ''Table 1'':&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''States'''&lt;br /&gt;
|  '''Access Type'''&lt;br /&gt;
|  '''Invariant'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  read, write&lt;br /&gt;
|  all other caches in I state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  read&lt;br /&gt;
|  all other caches in I state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Owned'''&lt;br /&gt;
|  read&lt;br /&gt;
|  all other caches in I or S state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  read&lt;br /&gt;
|  no other cache in M or E state&lt;br /&gt;
|-&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|  -&lt;br /&gt;
|  -&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 1:&amp;lt;/b&amp;gt; States Used by the Cache Coherent Protocols&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=Cache Coherence in real machines=&lt;br /&gt;
==Summary of Cache Coherence Protocols==&lt;br /&gt;
The first widely adopted approach to cache coherence is snooping on a bus. We will now discuss how some real time machines by '''Intel''', '''AMD''' and other processors maintain cache coherence using '''''snooping based coherence protocols'''''.  For more information on snooping based protocols refer to Solihin text book Chapter 8.&lt;br /&gt;
&lt;br /&gt;
==SGI - Silicon Graphics, Inc==&lt;br /&gt;
===MSI &amp;amp; SGI IRIS 4D Processors===&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' is a three-state write-back '''invalidation protocol''' which is one of the earliest snooping-based cache coherence-protocols. It marks the cache line in '''Modified (M) ,Shared (S)''', and '''Invalid (I)''' state. '''Invalid''' means the cache line is either not present or is invalid state. If the cache line is clean and is shared by more than one processor , it is marked '''shared'''. If cache line is dirty and the processor has exclusive ownership of the cache line, it is present in '''Modified''' state. BusRdx causes other processors to invalidate (demote) its cache block to the '''I''' state. If it is present in the '''M''' state in another cache, it will flush. BusRdx, even if hit in '''S''' state, is promoted to '''M''' (upgrade) state.&lt;br /&gt;
&lt;br /&gt;
The following state transition diagram for MSI protocol explains the working of the protocol:&lt;br /&gt;
&lt;br /&gt;
[[Image:MSI.jpg|frame|center|&amp;lt;b&amp;gt;Figure 2:&amp;lt;/b&amp;gt; MSI State Diagram]]&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' protocol was first used in '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''' IRIS 4D series. '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''' produced a broad range of '''[http://en.wikipedia.org/wiki/MIPS_architecture MIPS]'''-based (Microprocessor without Interlocked Pipeline Stages) workstations and servers during the 1990s, running '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''''s version of UNIX System V, now called '''[http://en.wikipedia.org/wiki/IRIX IRIX]'''. The 4D-MP graphics superworkstation brought 40 MIPS(million instructions per second) of computing performance to a graphics superworkstation. The unprecedented level of computing and graphics processing in an office-environment workstation was made possible by the fastest available Risc microprocessors in a single shared memory multiprocessor design driving a tightly coupled, highly parallel graphics system. Aggregate sustained data rates of over one gigabyte per second were achieved by a hierarchy of buses in a balanced system designed to avoid bottlenecks.&lt;br /&gt;
&lt;br /&gt;
The multiprocessor bus used in 4D-MP graphics superworkstation is a pipelined, block transfer bus that supports the cache coherence protocol as well as providing 64 megabytes of sustained data bandwidth between the processors, the memory and I/O system, and the graphics subsystem. Because the sync bus provides for efficient synchronization between processors, the cache coherence protocol was designed to support efficient data sharing between processors. If a cache coherence protocol has to support synchronization as well as sharing, a compromise in the efficiency of the data sharing protocol may be necessary to improve the efficiency of the synchronization operations. Hence it uses the simple cache coherence protocol which is the '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' protocol.&lt;br /&gt;
&lt;br /&gt;
With the simple rules of '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' enforced by the hardware protocols of&lt;br /&gt;
the sync bus and the Multiprocessor bus, efficient synchronization and efficient data sharing are achieved in a simple shared memory model of parallel processing in the 4D-MP graphics superworkstation.&lt;br /&gt;
&lt;br /&gt;
==SYNAPSE Multiprocessor==&lt;br /&gt;
===Synapse protocol and Synapse multiprocessor===&lt;br /&gt;
From the state transition diagram of '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''', we observe that for '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' there is transition to the '''S''' state from the '''M''' state when a BusRd is observed for that block. The contents of the block is flushed to the bus before going to '''S''' state. It would look more appropriate to move to the '''I''' state thus giving up the block entirely in certain cases. This choice of moving to '''S''' or '''I''' reflects the designer's assertion that the original processor is more likely to continue reading the block than the new processor to write to the block. In synapse protocol, used in the early Synapse multiprocessor, made this alternate choice of going directly from the '''M''' state to the '''I''' state on a BusRd, assuming the migratory pattern would be more frequent. More details about this protocol can be found in these papers published in late 1980's [http://portal.acm.org/citation.cfm?id=6514Cache Coherence protocols: evaluation using a multiprocessor simulation model] and [http://portal.acm.org/citation.cfm?id=1499317&amp;amp;dl=GUIDE&amp;amp;coll=GUIDE&amp;amp;CFID=83027384&amp;amp;CFTOKEN=95680533 Synapse tightly coupled multiprocessors: a new approach to solve old problems]&lt;br /&gt;
&lt;br /&gt;
In the Synapse protocol, the '''M''' state is called the '''D''' (Dirty) state. The following is the state transition diagram for Synapse protocol which clearly shows its working.&lt;br /&gt;
&lt;br /&gt;
[[Image:Synapse1.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; Synapse State Diagram]]&lt;br /&gt;
&lt;br /&gt;
==Intel==&lt;br /&gt;
===MESI &amp;amp; Intel Processors===&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' has a major drawback in that each read-write sequence incurs two bus transactions irrespective of whether the cache line is stored in only one cache or not. This is a huge setback for highly parallel programs that have little data sharing. '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol solves this problem by introducing the E ('''Exclusive''') state to distinguish between a cache line stored in multiple caches and a line stored in a single cache.&lt;br /&gt;
Let us briefly see how the MESI protocol works. For a more detailed version refer Solihin textbook pg. 215.&lt;br /&gt;
&lt;br /&gt;
'''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' coherence protocol marks each cache line in of the Modified, Exclusive, Shared, or Invalid state. &lt;br /&gt;
* '''Invalid''' : The cache line is either not present or is invalid&lt;br /&gt;
* '''Exclusive''' : The cache line is clean and is owned by this core/processor only&lt;br /&gt;
* '''Modified''' :  This implies that the cache line is dirty and the core/processor has  exclusive ownership of the cache line,exclusive of the memory also.&lt;br /&gt;
* '''Shared''' : The cache line is clean and is shared by more than one core/processor&lt;br /&gt;
&lt;br /&gt;
In a nutshell, the '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol works as follows: &lt;br /&gt;
A line that is fetched, receives '''E''', or '''S''' state depending on whether it exists in other processors in the system. A cache line gets the '''M''' state when a processor writes to it; if the line is not in '''E''' or '''M'''-state prior to writing it, the cache sends a Bus Upgrade (BusUpgr) signal or as the Intel manuals term it, “Read-For-Ownership (RFO) request” that ensures that the line exists in the cache and is in the '''I''' state in all other processors on the bus (if any). The table is shown below to summarize '''[http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol'''.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''Cache Line State:'''&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''This cache line is valid?'''&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  No&lt;br /&gt;
|-&lt;br /&gt;
|  '''The memory copy is…'''&lt;br /&gt;
|  out of date&lt;br /&gt;
|  valid&lt;br /&gt;
|  valid&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''Copies exist in caches of other processors?'''|  No&lt;br /&gt;
|  No&lt;br /&gt;
|  Maybe&lt;br /&gt;
|  Maybe&lt;br /&gt;
|-&lt;br /&gt;
|  '''A write to this line'''|  does not go to bus&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  goes to bus and updates cache&lt;br /&gt;
|  goes directly to bus&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 2:&amp;lt;/b&amp;gt; MESI Protocol Summary&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The transition diagram from the lecture slides is given below for reference.&lt;br /&gt;
&lt;br /&gt;
[[Image:MESI.jpg|frame|center|&amp;lt;b&amp;gt;Figure 4:&amp;lt;/b&amp;gt; MESI State Diagram]]&lt;br /&gt;
&lt;br /&gt;
The '''Pentium Pro''' microprocessor, introduced in 1992 was the '''first''' Intel architecture microprocessor to support symmetric multiprocessing ('''[http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP]''') in various multiprocessor configurations. '''[http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP]''' and '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol was the architecture used consistently until the introduction of the 45-nm Hi-k Core micro-architecture in '''Intel's (Nehalem-EP) quad-core x86-64'''. The 45-nm Hi-k Intel Core microarchitecture utilizes a new system of framework called the '''QuickPath Interconnect''' which uses point-to-point interconnection technology based on distributed shared memory architecture. It uses a modified version of '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol called '''MESIF''', by introducing an additional state, F, the forward state. &lt;br /&gt;
&lt;br /&gt;
The '''Intel architecture''' uses the '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol  as the '''basis''' to ensure cache coherence, which is true whether you're on one of the older processors that use a '''common bus''' to communicate or using the new Intel '''QuickPath''' point-to-point interconnection technology. &lt;br /&gt;
&lt;br /&gt;
Let us now walk through a briefing on the '''MESIF protocol''':&lt;br /&gt;
&lt;br /&gt;
The '''MESIF''' protocol, used in the latest Intel multi-core processors was introduced to '''accommodate the point-to-point''' links used in the QuickPath Interconnect. Using the '''MESI''' protocol in this architecture would send many redundant messages between different processors, often with unnecessarily high latency. For example, when a processor requests a cache line that is stored in multiple locations, every location might respond with the data. As the the requesting processor only needs a single copy of the data, the system would be '''wasting the bandwidth'''. &lt;br /&gt;
As a '''solution''' to this problem, an additional state, '''Forward state''', was added by slightly changing the role of the Shared state. Whenever there is a read request, only the cache line in the F state will respond to the request, while all the S state caches remain dormant.  Hence, by designating a single cache line to '''respond to requests''', coherency traffic is substantially reduced when multiple copies of the data exist. Also, on a read request, the F state transitions from F to S state. That is, when a cache line in the '''F''' state is '''copied''', the F state '''migrates''' to the '''newer copy''', while the '''older''' one drops back to '''S'''. Moving the new copy to the F state '''exploits''' both '''temporal and spatial locality'''. Because the newest copy of the cache line is always in the F state, it is very unlikely that the line in the F state will be evicted from the caches. This takes advantage of the temporal locality of the request. The second advantage is that if a particular cache line is in high demand due to spatial locality, the bandwidth used to transmit that data will be spread across several nodes.&lt;br /&gt;
All M to S state transition and E to S state transitions will now be from '''M to F''' and '''E to F'''.  &lt;br /&gt;
The '''F state''' is '''different''' from the '''Owned state''' of the MOESI protocol as it is '''not''' a '''unique''' copy because a valid copy is stored in memory. Thus, unlike the Owned state of the MOESI protocol, in which the data in the O state is the only valid copy of the data, the data in the F state can be evicted or converted to the S state, if desired. &lt;br /&gt;
&lt;br /&gt;
More information on the QuickPath Interconnect and MESIF protocol can be found at&lt;br /&gt;
'''[http://www.intel.com/technology/quickpath/introduction.pdf Introduction to QuickPath Interconnect]'''&lt;br /&gt;
&lt;br /&gt;
=== CMP Implementation in Intel Architecture ===&lt;br /&gt;
&lt;br /&gt;
Let us now see how Intel architecture using the [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol progressed from a uniprocessor architecture to a Chip MultiProcessor (CMP) using the bus as the interconnect. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Uniprocessor Architecture'''&lt;br /&gt;
&lt;br /&gt;
The diagram below shows the structure of the memory cluster in Intel Pentium M processor.&lt;br /&gt;
&lt;br /&gt;
[[Image:intel_cache1.jpg|frame|center|&amp;lt;b&amp;gt;Figure 5:&amp;lt;/b&amp;gt; Memory Structure of the Pentium M Processor]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In this structure we have,&lt;br /&gt;
* A unified on-chip '''L1 cache''' with the '''processor/core''',&lt;br /&gt;
* A '''Memory/L2 access control unit''', through which all the accesses to the L2 cache, main memory and IO space are made,&lt;br /&gt;
* The second level '''L2 cache''' along with the '''prefetch unit''' and&lt;br /&gt;
* '''Front side bus (FSB)''', a single shared bi-directional bus through which all the traffic is sent across.These wide buses bring in multiple data bytes at a time. &lt;br /&gt;
&lt;br /&gt;
As Intel explains it, using this structure, the processor requests were first sought in the '''L2 cache''' and only on a '''miss''', were they '''forwarded''' to the main '''memory''' via the front side bus ('''FSB'''). The '''Memory/L2 access control''' unit served as a central point for '''maintaining coherence''' within the core and with the external world. It '''contains''' a '''snoop control unit''' that receives snoop requests from the bus and performs the required operations on each cache (and internal buffers) in parallel. It also handles RFO requests (BusUpgr) and ensures the operation continues only after it guarantees that no other version on the cache line exists in any other cache in the system.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''CMP Architecture'''&lt;br /&gt;
&lt;br /&gt;
For CMP implementation, Intel chose the bus-based architecture using snoopy protocols vs the '''directory protocol''' because though directory protocol reduces the active power due to reduced snoop activity, it '''increased''' the '''design complexity''' and the '''static power''' due to larger tag arrays. Since Intel has a large market for the processors in the mobility family, directory-based solution was less favorable since battery life mainly depends on static power consumption and less on dynamic power.&lt;br /&gt;
Let us examine how '''CMP''' was implemented in '''Intel Core Duo''', which was one of the first dual-core processor for the budget/entry-level market. &lt;br /&gt;
The general CMP implementation structure of the Intel Core Duo is shown below&lt;br /&gt;
&lt;br /&gt;
[[Image:intel_cache2.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; Intel Core Duo CMP Implementation]]&lt;br /&gt;
&lt;br /&gt;
This structure has the following changes when compared to the uniprocessor memory cluster structure. &lt;br /&gt;
* '''L1 cache''' and the '''processor/core''' structure is '''duplicated''' to give 2 cores.&lt;br /&gt;
* The '''Memory/L2 access control''' unit is '''split''' into 2 logical units: '''L2 controller''' and '''bus controller'''. The L2 controller handles all '''requests to the L2''' cache from the core and the snoop requests from the FSB. The '''bus controller''' handles '''data and I/O requests''' to and from the FSB.&lt;br /&gt;
* The '''prefetching''' unit is extended to handle the hardware '''prefetches for each core separately'''.&lt;br /&gt;
* A '''new logical unit''' (represented by the hexagon) was added to maintain '''fairness between the requests''' coming from the different cores and hence balance the requests to L2 and memory.&lt;br /&gt;
&lt;br /&gt;
This new '''partitioned structure''' for the  memory/L2 access control unit '''enhanced''' the '''performance''' while '''reducing power consumption'''. &lt;br /&gt;
For more information on uniprocessor and multiprocessor implementation under the Intel architecture, refer to &lt;br /&gt;
[http://www.intel.com/technology/itj/2006/volume10issue02/art02_CMP_Implementation/p03_implementation.htm CMP Implementation in Intel Core Duo Processors]&lt;br /&gt;
&lt;br /&gt;
The '''Intel bus architecture''' has been '''evolving''' in order to accommodate the demands of scalability while using the '''same [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol'''; From using a '''single shared bus''' to '''dual independent buses (DIB)''' doubling the available bandwidth and to the logical conclusion of DIB with the introduction of '''dedicated high-speed interconnects (DHSI)'''. The DHSI-based platforms use four FSBs, one for each processor in the platform. In both DIB and DHSI, the snoop filter was used in the chipset to cache snoop information, thereby significantly reducing the broadcasting needed for the snoop traffic on the buses. With the production of processors based on next generation 45-nm Hi-k Intel Core microarchitecture, the [http://en.wikipedia.org/wiki/Xeon Intel Xeon] processor fabric will transition from a DHSI, with the memory controller in the chipset, to a distributed shared memory architecture using '''Intel QuickPath Interconnects using MESIF protocol'''.&lt;br /&gt;
&lt;br /&gt;
==AMD - Advanced Micro Devices Processors==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===MOESI &amp;amp; AMD Processors===&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/Opteron AMD Opteron] was AMD’s first-generation dual core which had two distinct [http://en.wikipedia.org/wiki/Athlon_64 K8 cores] together on a single die. Cache coherence produces bigger problems on such multiprocessors. It was necessary to use an appropriate coherence protocol to address this problem. The [http://en.wikipedia.org/wiki/Xeon Intel Xeon], which was the competitive counterpart from Intel to AMD dual core Opteron, used the [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol to handle cache coherence. [http://en.wikipedia.org/wiki/MESI_protocol MESI] came with the drawback of using much time and bandwidth in certain situations. &lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/MOESI_protocol MOESI] was AMD’s answer to this problem. [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] added a fifth state to [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol called the '''owned''' state. [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] addresses the bandwidth problem faced in MESI protocol when processor having invalid data in its cache wants to modify the data.  The processor seeking the data access will have to wait for the processor which modified this data to write back to the main memory, which takes time and bandwidth. This drawback is removed in MOESI by allowing dirty sharing.  When the data is held by a processor in the new state '''owned''', it can provide other processors the modified data without or even before writing it to the main memory. This is called '''''dirty sharing'''''. The processor with the data in the '''owned''' state stays responsible to update the main memory later when the cache line is evicted.&lt;br /&gt;
&lt;br /&gt;
[http://en.wikipedia.org/wiki/MOESI_protocol MOESI]  has become one of the most popular snoop-based protocols supported in AMD64 architecture.  AMD dual-core Opteron can maintain cache coherence in systems up to 8 processors using this protocol.&lt;br /&gt;
&lt;br /&gt;
The five different states of [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol are:&lt;br /&gt;
* '''Modified (M)''': The most recent copy of the data is present in the cache line. But it is not present in any other processor cache.&lt;br /&gt;
* '''Owned (O)''': The cache line has the most recent correct copy of the data. This can be shared by other processors. The processor in this state for this cache line is responsible to update the correct value in the main memory before it gets evicted.&lt;br /&gt;
* '''Exclusive (E)''': A cache line holds the most recent, correct copy of the data, which is exclusively present on this processor and a copy is present in the main memory.&lt;br /&gt;
* '''Shared (S)''': A cache line in the shared state holds the most recent, correct copy of the data, which may be shared by other processors.&lt;br /&gt;
* '''Invalid (I)''': A cache line does not hold a valid copy of the data.&lt;br /&gt;
&lt;br /&gt;
A detailed explanation of this protocol implementation on AMD processor can be found in the manual [http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html Architecture of AMD 64-bit core]&lt;br /&gt;
&lt;br /&gt;
The following table summarizes the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|  '''Cache Line State:'''&lt;br /&gt;
|  '''Modified'''&lt;br /&gt;
|  '''Owner''' &lt;br /&gt;
|  '''Exclusive'''&lt;br /&gt;
|  '''Shared'''&lt;br /&gt;
|  '''Invalid'''&lt;br /&gt;
|-&lt;br /&gt;
|  '''This cache line is valid?'''&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  Yes&lt;br /&gt;
|  No&lt;br /&gt;
|-&lt;br /&gt;
|  '''The memory copy is…'''&lt;br /&gt;
|  out of date&lt;br /&gt;
|  out of date&lt;br /&gt;
|  valid&lt;br /&gt;
|  valid&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''Copies exist in caches of other processors?'''&lt;br /&gt;
|  No&lt;br /&gt;
|  No&lt;br /&gt;
|  Yes(out of date values)|  Maybe&lt;br /&gt;
|  Maybe&lt;br /&gt;
|  -&lt;br /&gt;
|-&lt;br /&gt;
|  '''A write to this line'''&lt;br /&gt;
|  does not go to bus&lt;br /&gt;
|  does not go to bus|  does not go to bus&lt;br /&gt;
|  goes to bus and updates cache&lt;br /&gt;
|  goes directly to bus&lt;br /&gt;
|  -&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 3:&amp;lt;/b&amp;gt; MOESI Protocol Summary&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
State transition for [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]is as shown below : &lt;br /&gt;
&lt;br /&gt;
[[Image:MOESI_State_Transition_Diagram.jpg|frame|center|&amp;lt;b&amp;gt;Figure 7:&amp;lt;/b&amp;gt; [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]State transition Diagram]]&lt;br /&gt;
&lt;br /&gt;
===AMD Opteron memory Architecture===&lt;br /&gt;
&lt;br /&gt;
[[Image:Untitled.jpg|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; AMD Opteron memory Architecture]]&lt;br /&gt;
&lt;br /&gt;
The AMD processor’s high-performance cache architecture includes an integrated, 64-bit, dual-ported  128-Kbyte split-L1 cache with separate snoop port, multi-level translation lookaside buffers (TLBs), a scalable L2 cache controller with a 72-bit (64-bit data + 8-bit ECC) interface to as much as 8-Mbyte of industry-standard SDR or DDR SRAMs, and an integrated tag for the most cost-effective 512-Kbyte L2 configurations. The AMD Athlon processor’s integrated L1 cache comprises two separate 64-Kbyte, two-way set-associative data and instruction caches.&lt;br /&gt;
&lt;br /&gt;
More information about this can be found in [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD 64 bit Architecture Programmers's Manual]&lt;br /&gt;
&lt;br /&gt;
===Special Coherence Considerations in AMD64 architectures===&lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
Instruction prefetching is a technique used to speedup the execution of the program. But in multiprocessors, prefetching comes at the cost of performance. Due to prefetching, the data can be modified in such a way that the memory coherence protocol will not be able to handle the effects. In such situations software must use serializing instructions or cache-invalidation instructions to guarantee subsequent data accesses are coherent. &lt;br /&gt;
&amp;lt;br /&amp;gt;&lt;br /&gt;
An example of this type of a situation is a page-table update followed by accesses to the physical pages referenced by the updated page tables. The physical-memory references for the page tables are different than the physical-memory references for the data. Because of prefetching, there maybe problem with correctness. The following sequence of events shows such a situation when software changes the translation of virtual-page A from physical-page M to physical-page N:&lt;br /&gt;
# The tables that translate virtual-page A to physical-page M are now held only in main memory. The copies in the cache ae invalidated.&lt;br /&gt;
# Page-table entry is changed by the software for virtual-page A in main memory to point to physical page N rather than physical-page M.&lt;br /&gt;
# Data in virtual-page A is accessed.&lt;br /&gt;
&lt;br /&gt;
Software expects the processor to access the data from physical-page N after the update. However, it is possible for the processor to prefetch the data from physical-page M before the page table for virtual page A is updated. Because the physical-memory references are different, the processor does not recognize them as requiring coherence checking and believes it is safe to prefetch the data from virtual-page A, which is translated into a read from physical page M. Similar behavior can occur when instructions are prefetched from beyond the page table update instruction.&lt;br /&gt;
&lt;br /&gt;
In order to prevent errors from occuring, there are special instructions provided by software like INVLPG or MOV CR3 instruction which is executed immediately after the page-table update to ensure that subsequent instruction fetches and data accesses use the correct virtual-page-to-physical-page translation. It is not necessary to perform a TLB invalidation operation preceding the table update.&lt;br /&gt;
&lt;br /&gt;
More information can be found about this in [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD64 Architecture Programmer's manual]&lt;br /&gt;
&lt;br /&gt;
===Optimization techniques on MOESI when implemented on AMD Phenom processors===&lt;br /&gt;
&lt;br /&gt;
In real machines, using some optimization techniques on the standard cache coherence protocol used, improves the performance of the machine. For example, [http://en.wikipedia.org/wiki/AMD_Phenom AMD Phenom] family of microprocessors (Family 0×10) which is AMD’s first generation to incorporate 4 distinct cores on a single die. It is the first to have a cache that all the cores share, using the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol with some optimization techniques incorporated. &lt;br /&gt;
&lt;br /&gt;
It focuses on a small subset of compute problems which behave like Producer and Consumer programs. In such a computing problem, a thread of a program running on a single core produces data, which is consumed by a thread that is running on a separate core. With such programs, it is desirable to get the two distinct cores to communicate through the shared cache, to avoid round trips to/from main memory. The '''MOESI''' protocol that the [http://en.wikipedia.org/wiki/AMD_Phenom AMD Phenom] cache uses for cache coherence can also limit bandwidth. Hence by keeping the cache line in the '''M''' state for such computing problems, we can achieve better performance.&lt;br /&gt;
&lt;br /&gt;
When the producer thread , writes a new entry, it allocates cache-lines in the '''M''' state. Eventually, these M-marked cache lines will start to fill the L3 cache. When the consumer reads the cache line, the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol changes the state of the cache line to the '''O''' state in the L3 cache and pulls down a '''shared (S)''' copy for its own use. Now, the producer thread circles the ring buffer to arrive back to the same cache line it had previously written. However, when the producer attempts to write new data to the owned (marked '''‘O’''') cache line, it finds that it cannot, since a cache line in the '''O''' state by the previous consumer read does not have sufficient permission for a write request (in the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]). To maintain coherence, the memory controller must initiate probes in the other caches (to handle any other S copies that may exist). This will slow down the process.&lt;br /&gt;
&lt;br /&gt;
Thus, it is preferable to keep the cache line in the '''M''' state in the L3 cache. In such a situation, when the producer comes back around the ring buffer, it finds the previously written cache line still in the'''M''' state, to which it is safe to write without coherence concerns. Thus better performance can be achieved by such optimization techniques to standard protocols when implemented in real machines.&lt;br /&gt;
&lt;br /&gt;
You can find more information on how this is implemented and various other ways of optimizations in this manual [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf Software Optimization guide for AMD 10h Processors].&lt;br /&gt;
&lt;br /&gt;
==Xerox Corporation==&lt;br /&gt;
===Dragon Protocol &amp;amp; Xerox Dragon Processors===&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' is an update based coherence protocol which does not invalidate other cached copies like what we have seen in the coherence protocols so far. Write propagation is achieved by updating the cached copies instead of invalidating them.  But the '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' does not update memory on a cache to cache transfer and delays the memory and cache consistency until the data is evicted and written back, which saves time and lowers the memory access requirements. Moreover only the written '''byte''' or the '''word''' is '''communicated''' to the '''other caches''' instead of the whole block which further '''reduces''' the '''bandwidth''' usage. It has the ability to detect dynamically, the sharing status of a block and use a write through policy for shared blocks and write back for currently non-shared blocks. The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' employs the following four states for the cache blocks: '''Shared Clean''', '''Shared Modified''', '''Exclusive''', and  '''Modified'''. &lt;br /&gt;
* '''Modified (M)''' and '''Exclusive (E)''' - these states have the same meaning as explained in the protocols above. &lt;br /&gt;
* '''Shared Modified (Sm)''' - Only one cache line in the system can be in the Shared Modified state. Potentially two or more caches    have this block and memory may or may not be up to date and this processor's cache had modified the block.&lt;br /&gt;
* '''Shared Clean (Sc)''' -  Potentially two or more caches have this block and memory may or may not be up to date(if no other cache has it in Sm state, memory will be up to date else it is not).&lt;br /&gt;
When a Shared Modified line is evicted from the cache on a cache miss only then is the block written back to the main memory in order to keep memory consistent. For more information on Dragon protocol, refer to Solihin textbook, page number 229. The state transition diagram has been given below for reference.&lt;br /&gt;
&lt;br /&gt;
[[Image:Dragon.jpg|frame|center|&amp;lt;b&amp;gt;Figure 9:&amp;lt;/b&amp;gt; Dragon Protocol State Diagram]]&lt;br /&gt;
&lt;br /&gt;
The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' , was developed by Xerox Palo Alto Research Center ('''[http://en.wikipedia.org/wiki/Xerox_PARC Xerox PARC]'''), a subsidiary of Xerox Corporation.  This protocol was used in the '''[http://en.wikipedia.org/w/index.php?title=Xerox_Dragon&amp;amp;redirect=no Xerox PARC Dragon]''' multiprocessor workstation, a VLSI research computer that could support multiple processors on a central high bandwidth memory bus. The Dragon design implemented snoopy caches that provided the appearance of a uniform memory space to multiple processors. Here, each cache listens to 2 buses: the processor bus and the memory bus. The caches are also responsible for address translation, so the processor bus carries virtual addresses and the memory bus carries physical addresses.  The Dragon system was designed to support 4 to 8 Dragon processors. The memory bus used in the Xeron Dragon evolved to become the '''[http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=289691 XDBus]''' , a low-cost, synchronous, '''packet-switched VLSI bus''' designed for use in high-performance multiprocessors. This was used as the interconnect in many multiprocessor server systems like '''Cray Superserver 6400''', '''Sun Microsystems' SPARCcenter 2000''' and '''SPARCserver 1000'''  and '''Sun4d''' systems.&lt;br /&gt;
&lt;br /&gt;
=Cache Coherence Power Utilization=&lt;br /&gt;
A number of studies have been performed to reduce the power consumption of cache coherence protocols. In order to perform a solid comparison between the cache coherency protocols, one would need to develop a multi-core processor for each of the cache coherency protocols. Additionally, the hardware and software configuration would also need to be similar between each system (except for the hardware required to implement each of the different protocols). Unfortunately, there are no such processors available. This section will discuss power consumption in general terms, comparing to each of the protocols. Also, this section will briefly discussion some power optimization techniques.&lt;br /&gt;
&lt;br /&gt;
Bus transactions, in general, are costly for both performance and power consumption. Additionally, studies have been performed showing that unnecessary snooping can waste power. Power requirements are typically determined by the number of bus snoops and number of bus accesses by each processor. One study indicates that interchip bus communications can consume up to 20% of total chip power[[#References|&amp;lt;sup&amp;gt;[20]&amp;lt;/sup&amp;gt;]].&lt;br /&gt;
Using the examples from the class notes, we can analyze the relative power consumption between the protocols. The following table is a summary of various protocols showing the number of bus communications that occur for each processor action.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
{| class=&amp;quot;wikitable&amp;quot; border=&amp;quot;1&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
|'''Processor Action'''&lt;br /&gt;
|'''MSI Bus Actions'''&lt;br /&gt;
|'''MESI Bus Actions'''&lt;br /&gt;
|'''Dragon Bus Actions'''&lt;br /&gt;
|'''FireFly Bus Actions'''&lt;br /&gt;
|-&lt;br /&gt;
|R1&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|-&lt;br /&gt;
|W1&lt;br /&gt;
|BusRdX&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R3&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|-&lt;br /&gt;
|W3&lt;br /&gt;
|BusRdX&lt;br /&gt;
|BusRdX&lt;br /&gt;
|BusUpd/Upd&lt;br /&gt;
|BusUpd&lt;br /&gt;
|-&lt;br /&gt;
|R1&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R3&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|-&lt;br /&gt;
|R2&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|BusRd/Flush&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;b&amp;gt;Table 4:&amp;lt;/b&amp;gt; Summary of Bus Actions for Select Protocols&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
From the table above, we can see that MSI has a larger number of bus transactions than the Dragon protocol. Even though bus transactions are not power efficient, snooping can also be enhanced to improve power efficiency. The following section will discuss snoop filtering techniques.&lt;br /&gt;
&lt;br /&gt;
==Power Savings Using Snoop Filtering==&lt;br /&gt;
A number of studies have been performed to reduce the number of unnecessary snoops during cache transactions. Two such filtering techniques are serial snooping and Jetty. The following sections will briefly discuss these two filtering techniques and power savings achieved using these techniques. Studies show that as much as 90% of snoop broadcasts will result in a miss[[#References|&amp;lt;sup&amp;gt;[19]&amp;lt;/sup&amp;gt;]] in the other caches at the same level and require that the information be provided by the next level of cache or memory. As much as a 36% savings in power by filtering snoops using one of the following snoop filtering methods[[#References|&amp;lt;sup&amp;gt;[19]&amp;lt;/sup&amp;gt;]].&lt;br /&gt;
===Serial Snooping===&lt;br /&gt;
Serial snooping takes advantage of the fact that if a miss occurs in one cache, it is possible to find the block in one other cache without having to check all the caches. If the cache block is available in multiple caches, there is a high probability that the cache miss can find the data in a nearby cache. Alternatively, savings can be realized by searching a subset of the caches vice all the caches. One thing to note is that this is only effective for read misses. Write, an invalidation transaction needs to be transmitted to the other caches, thus a bus transaction is unavoidable.&lt;br /&gt;
===Jetty===&lt;br /&gt;
Jetty is a mechanism attached to each cache that verifies that a bus snoop is necessary. Jetty is used to filter L2 tag lookups. When a processor needs to perform a bus snoop, the Jetty is checked first. The Jetty can determine if a cache tag lookup is required. Since the Jetty is much smaller than the associated cache, less power is required to determine if a snoop is required.&lt;br /&gt;
&lt;br /&gt;
There are a couple of different Jetty schemes. There is the exclude-Jetty, include-Jetty, and hybrid-Jetty. The exclude-Jetty exploits the fact that if a cache block is snooped, it is highly likely the same cache block will be snooped in the near future. The exclude-Jetty keeps track of the tag lookups in a small table and can determine if a cache tag lookup is necessary.&lt;br /&gt;
&lt;br /&gt;
The include-Jetty keeps a superset of the blocks that are cached. If a miss occurs in the include-Jetty, then it can be guaranteed that the block is not stored in its associated cache.&lt;br /&gt;
&lt;br /&gt;
The hybrid-Jetty is simply a combinations of and include and exclude-Jetty. Both types of Jetty are present and when a lookup occurs, both Jettys are checked to determine if a cache lookup is necessary.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Cache_coherence Cache coherence]&lt;br /&gt;
# [http://www.intel.com/technology/quickpath/introduction.pdf Introduction to QuickPath Interconnect]&lt;br /&gt;
# [http://www.intel.com/technology/itj/2006/volume10issue02/art02_CMP_Implementation/p03_implementation.htm CMP Implementation in Intel Core Duo Processors]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Symmetric_multiprocessing Common System Interface in Intel Processors]&lt;br /&gt;
# [http://www.zak.ict.pwr.wroc.pl/nikodem/ak_materialy/Cache%20consistency%20&amp;amp;%20MESI.pdf Cache consistency with MESI on Intel processor]&lt;br /&gt;
# [http://techreport.com/articles.x/8236/2 AMD dual core Architecture]&lt;br /&gt;
# [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD64 Architecture Programmer's manual]&lt;br /&gt;
# [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf Software Optimization guide for AMD 10h Processors]&lt;br /&gt;
# [http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html Architecture of AMD 64 bit core]&lt;br /&gt;
# [http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=4913 Silicon Graphics Computer Systems]&lt;br /&gt;
# [http://books.google.com/books?id=g82fofiqa5IC&amp;amp;printsec=frontcover&amp;amp;dq=Parallel+computer+architecture:+a+hardware/software+approach+By+David+E.+Culler,+Jaswinder+Pal+Singh,+Anoop+Gupta&amp;amp;source=bl&amp;amp;ots=COrdamlfVn&amp;amp;sig=YcugVqbzTjHvlofvaFq6Ft_tjfY&amp;amp;hl=en&amp;amp;ei=0ZO6S4TJGcOclgejzI3BBw&amp;amp;sa=X&amp;amp;oi=book_result&amp;amp;ct=result&amp;amp;resnum=1&amp;amp;ved=0CAgQ6AEwAA#v=onepage&amp;amp;q=&amp;amp;f=false Parallel computer architecture: a hardware/software approach By David E. Culler, Jaswinder Pal Singh, Anoop Gupta]&lt;br /&gt;
# [http://www.freepatentsonline.com/5283886.html Three state invalidation protocols]&lt;br /&gt;
# [http://portal.acm.org/citation.cfm?id=1499317&amp;amp;dl=GUIDE&amp;amp;coll=GUIDE&amp;amp;CFID=83027384&amp;amp;CFTOKEN=95680533 Synapse tightly coupled multiprocessors: a new approach to solve old problems]&lt;br /&gt;
# [http://portal.acm.org/citation.cfm?id=6514Cache Coherence protocols: evaluation using a multiprocessor simulation model]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]&lt;br /&gt;
# [http://en.wikipedia.org/wiki/Xerox_Dragon Xerox Dragon]&lt;br /&gt;
# [http://thanaseto.110mb.com/courses/CSD-527-report-engl.pdf Coherence Protocols]&lt;br /&gt;
# [http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&amp;amp;arnumber=289691 XDBus]&lt;br /&gt;
# [http://www.ece.wisc.edu/~wddd/2002/final/ekman.pdf Evaluation of Snoop-Energy Reduction Techniques for Chip-Multiprocessors]&lt;br /&gt;
# [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.79.7463&amp;amp;rep=rep1&amp;amp;type=pdf Power Efficient Cache Coherence]&lt;/div&gt;</summary>
		<author><name>Mqtran</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2011/ch2a_mc&amp;diff=43706</id>
		<title>CSC/ECE 506 Spring 2011/ch2a mc</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Spring_2011/ch2a_mc&amp;diff=43706"/>
		<updated>2011-02-12T23:15:34Z</updated>

		<summary type="html">&lt;p&gt;Mqtran: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;=Introduction=&lt;br /&gt;
The Graphical Processing Unit (GPU) is a dedicated super-threaded, massively data parallel co-processor. Unlike the CPU, GPUs are designed to be highly parallel, have a high computational throughput, and high memory throughput. CPUs are architected to perform well for single and multi-threaded applications. A number of programming APIs have been introduced to allow programmers to harness the power of the GPU to perform parallel tasks. Two such architectures are OpenCL and Compute Unified Device Architecture (CUDA).&lt;br /&gt;
&lt;br /&gt;
=OpenCL=&lt;br /&gt;
&lt;br /&gt;
==Programming Model==&lt;br /&gt;
&lt;br /&gt;
As of version 1.1 of the OpenCL specification[[#References|&amp;lt;sup&amp;gt;[1]&amp;lt;/sup&amp;gt;]], the programming model of OpenCL is a hybrid of task parallelism and data parallelism. We will first describe the key concepts of OpenCL:&lt;br /&gt;
&lt;br /&gt;
===Platform Model===&lt;br /&gt;
&lt;br /&gt;
[[Image:OpenCL_Fig1.png|frame|center|&amp;lt;b&amp;gt;Figure 1:&amp;lt;/b&amp;gt; OpenCL Platform Model [[#References|&amp;lt;sup&amp;gt;[1]&amp;lt;/sup&amp;gt;]]]]&lt;br /&gt;
&lt;br /&gt;
As shown in Figure 1, the platform for running OpenCL programs somewhat resembles a network of computer clusters. The parallel is relatively close: each Compute Device behaves like a cluster, which consists of computers (in the form of Compute Unit - CU), and each Compute Unit can contain multiple Processing Element(PE), much like a computer can contain multiple CPUs.&lt;br /&gt;
&lt;br /&gt;
===Execution Model===&lt;br /&gt;
&lt;br /&gt;
[[Image:OpenCL_Fig2.png|frame|center|&amp;lt;b&amp;gt;Figure 2:&amp;lt;/b&amp;gt; Execution Model [[#References|&amp;lt;sup&amp;gt;[1]&amp;lt;/sup&amp;gt;]]]]&lt;br /&gt;
&lt;br /&gt;
Figure 2 depicts the conceptual model of execution. There is ''host program'' executes on the host and manages the execution of multiple ''compute kernels''. Each compute kernel can execute in parallel, on separate ''work-item''. Work-items close together can then be grouped into ''work-group''. This execution model closely matches the platform model described above, as each PE often executes one kernel, and one workgroup is often handled by one CU.&lt;br /&gt;
&lt;br /&gt;
===Memory Model===&lt;br /&gt;
&lt;br /&gt;
The memory model of OpenCL reflects the design of the Platform Model and Execution Model. Specifically, there are four levels of memory, as shown in the table below:&lt;br /&gt;
&lt;br /&gt;
{| border=&amp;quot;1&amp;quot; align=&amp;quot;center&amp;quot; style=&amp;quot;text-align:center;&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!Memory Regions&lt;br /&gt;
! Accessible by&lt;br /&gt;
|-&lt;br /&gt;
|Global Memory&lt;br /&gt;
|All work-items in all work-groups&lt;br /&gt;
|-&lt;br /&gt;
|Constant Memory&lt;br /&gt;
|All work-items in all work-groups&lt;br /&gt;
|-&lt;br /&gt;
|Local Memory&lt;br /&gt;
|All work-items in a work-group&lt;br /&gt;
|-&lt;br /&gt;
|Private Memory&lt;br /&gt;
|Private to a work-item&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Programming Model===&lt;br /&gt;
To take advantage of OpenCL architecture, two programming models can be used. The first one is data parallel programming model and the other one is task parallel programming model.&lt;br /&gt;
In the data parallel programming model, every computer kernel executes the same block of code, but on different data. Therefore, conceptually there is one global program counter for all computer kernels. The programmer can choose to manually partition the kernels into group, or delegate this task to the OpenCL middleware.&lt;br /&gt;
Beside the data parallel programming model, programmer can choose to use the task parallel programming model. In this case, each PE will execute a separate compute kernel and parallelism is achieved by running multiple kernels on separate work-item.&lt;br /&gt;
&lt;br /&gt;
==Implementation==&lt;br /&gt;
===AMD Implementation===&lt;br /&gt;
The first GPU generation from AMD that supports OpenCL 1.1 is the Radeon HD 5000 series. Latest generations also support OpenCL 1.1, at the same time significantly improve performance due to architectural refinements. The table below will summarize key characteristics of Radeon HD 6000 GPUs&lt;br /&gt;
&lt;br /&gt;
{| border=&amp;quot;1&amp;quot; align=&amp;quot;center&amp;quot; style=&amp;quot;text-align: center; width: auto&amp;quot;&lt;br /&gt;
|-&lt;br /&gt;
!rowspan=2 style=&amp;quot;width:12em&amp;quot;|Model&lt;br /&gt;
!colspan=2 style=&amp;quot;text-align:center&amp;quot;|Clock rate&lt;br /&gt;
!rowspan=2|Config core&lt;br /&gt;
!colspan=3 style=&amp;quot;text-align:center&amp;quot;|Memory&lt;br /&gt;
!colspan=2|TDP (W)&lt;br /&gt;
!rowspan=2|Double-precision FP&lt;br /&gt;
|-&lt;br /&gt;
!Core (MHz)&lt;br /&gt;
!Memory (MHz)&lt;br /&gt;
!Bandwidth (GB/s)&lt;br /&gt;
!Bus type&lt;br /&gt;
!Bus width (bit)&lt;br /&gt;
!Idle&lt;br /&gt;
!Max.&lt;br /&gt;
|- valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Radeon HD 6450&lt;br /&gt;
|625-750&lt;br /&gt;
|533-800 800-900&lt;br /&gt;
|160:8:4&lt;br /&gt;
|8.5-12.8 25.6-28.8&lt;br /&gt;
|DDR3, GDDR5&lt;br /&gt;
|64&lt;br /&gt;
|?&lt;br /&gt;
|31&lt;br /&gt;
|No&lt;br /&gt;
|- valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Radeon HD 6570&lt;br /&gt;
|650&lt;br /&gt;
|900 1000&lt;br /&gt;
|480:24:8&lt;br /&gt;
|28.8 64&lt;br /&gt;
|GDDR3 GDDR5&lt;br /&gt;
|128&lt;br /&gt;
|?&lt;br /&gt;
|?&lt;br /&gt;
|No&lt;br /&gt;
|- valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Radeon HD 6670&lt;br /&gt;
|800&lt;br /&gt;
|1000&lt;br /&gt;
|480:24:8&lt;br /&gt;
|64&lt;br /&gt;
|GDDR5&lt;br /&gt;
|128&lt;br /&gt;
|?&lt;br /&gt;
|63&lt;br /&gt;
|No&lt;br /&gt;
|- valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Radeon HD 6750&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|720:36:16&lt;br /&gt;
|up to 73.6&lt;br /&gt;
|GDDR5&lt;br /&gt;
|128&lt;br /&gt;
|16&lt;br /&gt;
|86&lt;br /&gt;
|No&lt;br /&gt;
|- valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Radeon HD 6770&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|800:40:16&lt;br /&gt;
|up to 76.8&lt;br /&gt;
|GDDR5&lt;br /&gt;
|128&lt;br /&gt;
|18&lt;br /&gt;
|108&lt;br /&gt;
|No&lt;br /&gt;
|- valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Radeon HD 6850&lt;br /&gt;
|775&lt;br /&gt;
|1000&lt;br /&gt;
|960:48:32&lt;br /&gt;
|128&lt;br /&gt;
|GDDR5&lt;br /&gt;
|256&lt;br /&gt;
|19&lt;br /&gt;
|127&lt;br /&gt;
|No&lt;br /&gt;
|- valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Radeon HD 6870&lt;br /&gt;
|900&lt;br /&gt;
|1050&lt;br /&gt;
|1120:56:32&lt;br /&gt;
|134.4&lt;br /&gt;
|GDDR5&lt;br /&gt;
|256&lt;br /&gt;
|19&lt;br /&gt;
|151&lt;br /&gt;
|No&lt;br /&gt;
|- valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Radeon HD 6950&lt;br /&gt;
|800&lt;br /&gt;
|1250&lt;br /&gt;
|1408:88:32&lt;br /&gt;
|160&lt;br /&gt;
|GDDR5&lt;br /&gt;
|256&lt;br /&gt;
|20&lt;br /&gt;
|200&lt;br /&gt;
|563&lt;br /&gt;
|- valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Radeon HD 6970&lt;br /&gt;
|880&lt;br /&gt;
|1375&lt;br /&gt;
|1536:96:32&lt;br /&gt;
|176&lt;br /&gt;
|GDDR5&lt;br /&gt;
|256&lt;br /&gt;
|20&lt;br /&gt;
|250&lt;br /&gt;
|675&lt;br /&gt;
|- valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Radeon HD 6990&lt;br /&gt;
|?&lt;br /&gt;
|?&lt;br /&gt;
|3072:?:?&lt;br /&gt;
|?&lt;br /&gt;
|GDDR5&lt;br /&gt;
|2x 256&lt;br /&gt;
|?&lt;br /&gt;
|~300&lt;br /&gt;
|Yes&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;center&amp;gt;&amp;lt;b&amp;gt;Table 1:&amp;lt;/b&amp;gt; 1 AMD Radeon HD 6000 Series[[#References|&amp;lt;sup&amp;gt;[2]&amp;lt;/sup&amp;gt;]]&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
As can be seen from table one, GPUs can varied of multiple parameters, which lead to difference in performance. Top-of-the-line model like Radeon HD 6970 is equipped with more cores (PE), wider memory bus bandwidth and faster clock rate. As a result, it is much faster than a low end model with significantly reduced configurations.&lt;br /&gt;
&lt;br /&gt;
According to specification published by AMD[[#References|&amp;lt;sup&amp;gt;[3]&amp;lt;/sup&amp;gt;]], Radeon HD GPU organization has significant similarity with OpenCL platform model described above. The similarity can be seen from the figure below.&lt;br /&gt;
&lt;br /&gt;
[[Image:OpenCL_Fig3.png|frame|center|&amp;lt;b&amp;gt;Figure 3:&amp;lt;/b&amp;gt; AMD HD 6900 Series Block Diagram]]&lt;br /&gt;
&lt;br /&gt;
This is, however, not by chance, but by design as the closeness between the conceptual model and the implementation assists in the development process and improves performance.&lt;br /&gt;
&lt;br /&gt;
===NVidia Implementation===&lt;br /&gt;
&lt;br /&gt;
The first NVidia GPU generation to support OpenCL 1.1 is GeForce 400 series. Their architecture is shown in the following figure:&lt;br /&gt;
&lt;br /&gt;
[[Image:OpenCL_Fig4.png|frame|center|&amp;lt;b&amp;gt;Figure 4:&amp;lt;/b&amp;gt; NVidia Fermi Architecture[[#References|&amp;lt;sup&amp;gt;[4]&amp;lt;/sup&amp;gt;]]]]&lt;br /&gt;
&lt;br /&gt;
As shown in figure four, NVidia Implementation follows almost the same design, with slightly different variations. Each Core is essentially a PE; which are grouped into Streaming Multiprocessor (SM). Cores have access to two level caches and a register file, similar to AMD’s design. The differences apparently are in terminology and are not fundamental.&lt;br /&gt;
&lt;br /&gt;
===Sample Application===&lt;br /&gt;
OpenCL applications are mainly implemented in C; a C++ wrapper built on top of C is also available. According to the OpenCL 1.1 specification, the OpenCL C language is based on ISO C99, with extensions designed for parallel computing[[#References|&amp;lt;sup&amp;gt;[1]&amp;lt;/sup&amp;gt;]]. The following is sample application to compute a Fast Fourier Transformation (FFT)[[#References|&amp;lt;sup&amp;gt;[5]&amp;lt;/sup&amp;gt;]]:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
// create a compute context with GPU device&lt;br /&gt;
context = clCreateContextFromType(NULL, CL_DEVICE_TYPE_GPU, NULL, NULL, NULL);&lt;br /&gt;
&lt;br /&gt;
// create a command queue&lt;br /&gt;
queue = clCreateCommandQueue(context, NULL, 0, NULL);&lt;br /&gt;
&lt;br /&gt;
// allocate the buffer memory objects&lt;br /&gt;
memobjs[0] = clCreateBuffer(context, CL_MEM_READ_ONLY | CL_MEM_COPY_HOST_PTR, sizeof(float)*2*num_entries, srcA, NULL);&lt;br /&gt;
memobjs[1] = clCreateBuffer(context, CL_MEM_READ_WRITE, sizeof(float)*2*num_entries, NULL, NULL);&lt;br /&gt;
&lt;br /&gt;
// create the compute program&lt;br /&gt;
program = clCreateProgramWithSource(context, 1, &amp;amp;fft1D_1024_kernel_src, NULL, NULL);&lt;br /&gt;
&lt;br /&gt;
// build the compute program executable&lt;br /&gt;
clBuildProgram(program, 0, NULL, NULL, NULL, NULL);&lt;br /&gt;
&lt;br /&gt;
// create the compute kernel&lt;br /&gt;
kernel = clCreateKernel(program, &amp;quot;fft1D_1024&amp;quot;, NULL);&lt;br /&gt;
&lt;br /&gt;
// set the args values&lt;br /&gt;
clSetKernelArg(kernel, 0, sizeof(cl_mem), (void *)&amp;amp;memobjs[0]);&lt;br /&gt;
clSetKernelArg(kernel, 1, sizeof(cl_mem), (void *)&amp;amp;memobjs[1]);&lt;br /&gt;
clSetKernelArg(kernel, 2, sizeof(float)*(local_work_size[0]+1)*16, NULL);&lt;br /&gt;
clSetKernelArg(kernel, 3, sizeof(float)*(local_work_size[0]+1)*16, NULL);&lt;br /&gt;
&lt;br /&gt;
// create N-D range object with work-item dimensions and execute kernel&lt;br /&gt;
global_work_size[0] = num_entries;&lt;br /&gt;
local_work_size[0] = 64;&lt;br /&gt;
clEnqueueNDRangeKernel(queue, kernel, 1, NULL, global_work_size, local_work_size, 0, NULL, NULL);&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The compute kernel is specified in the variable fft1D_1024_kernel_src, its source code is provided below:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
// This kernel computes FFT of length 1024. The 1024 length FFT is decomposed into&lt;br /&gt;
// calls to a radix 16 function, another radix 16 function and then a radix 4 function&lt;br /&gt;
__kernel void fft1D_1024 (__global float2 *in, __global float2 *out,&lt;br /&gt;
__local float *sMemx, __local float *sMemy) {&lt;br /&gt;
int tid = get_local_id(0);&lt;br /&gt;
int blockIdx = get_group_id(0) * 1024 + tid;&lt;br /&gt;
float2 data[16];&lt;br /&gt;
&lt;br /&gt;
// starting index of data to/from global memory&lt;br /&gt;
in = in + blockIdx; out = out + blockIdx;&lt;br /&gt;
globalLoads(data, in, 64); // coalesced global reads&lt;br /&gt;
fftRadix16Pass(data); // in-place radix-16 pass&lt;br /&gt;
twiddleFactorMul(data, tid, 1024, 0);&lt;br /&gt;
&lt;br /&gt;
// local shuffle using local memory&lt;br /&gt;
localShuffle(data, sMemx, sMemy, tid, (((tid &amp;amp; 15) * 65) + (tid &amp;gt;&amp;gt; 4)));&lt;br /&gt;
fftRadix16Pass(data); // in-place radix-16 pass&lt;br /&gt;
twiddleFactorMul(data, tid, 64, 4); // twiddle factor multiplication&lt;br /&gt;
localShuffle(data, sMemx, sMemy, tid, (((tid &amp;gt;&amp;gt; 4) * 64) + (tid &amp;amp; 15)));&lt;br /&gt;
&lt;br /&gt;
// four radix-4 function calls&lt;br /&gt;
fftRadix4Pass(data); // radix-4 function number 1&lt;br /&gt;
fftRadix4Pass(data + 4); // radix-4 function number 2&lt;br /&gt;
fftRadix4Pass(data + 8); // radix-4 function number 3&lt;br /&gt;
fftRadix4Pass(data + 12); // radix-4 function number 4&lt;br /&gt;
&lt;br /&gt;
// coalesced global writes&lt;br /&gt;
globalStores(data, out, 64);&lt;br /&gt;
}&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
As can be seen from the above example, OpenCL C program has a clear control flow. The host program first creates a global share memory area and initializes the environment. It then instructs the driver to compile the compute kernel from OpenCL C source code to machine code specific to the hardware PEs. [[#References|&amp;lt;sup&amp;gt;[3]&amp;lt;/sup&amp;gt;]] The compute kernels are then enqueued to run on the Compute Device. When the results are available the host program will be notified.&lt;br /&gt;
Developing a compute kernel is a relatively straightforward process. Data is first loaded from global memory to local memory. The kernels will then perform computation on this chunk of data. The result will be written back to global memory.&lt;br /&gt;
&lt;br /&gt;
=Compute Unified Device Architecture (CUDA)=&lt;br /&gt;
CUDA is one of the parallel architectures available to modern GPUs. CUDA a proprietary architecture developed by NVIDIA. CUDA was introduced with NVIDIA’s GeForce 8, February 2007[[#References|&amp;lt;sup&amp;gt;[6]&amp;lt;/sup&amp;gt;]], series of video cards. This architecture gives programmers access to the GPUs multicore processor for performing math intensive operations. These operations include physics modeling (PhysX), physical modeling, image processing, matrix algebra, etc. &lt;br /&gt;
These GPUs are specifically design to perform many floating point and integer operations simultaneously. CUDA is capable of handling millions of threads simultaneously with little overhead to manage this large number of threads.&lt;br /&gt;
&lt;br /&gt;
==CUDA Architecture==&lt;br /&gt;
Figure 5 shows the typical arrangement on for a GPU multiprocessor. This figure shows the general flow path of data through the GPU. Data flows from the host to the thread execution manager, which spawns and schedules the threads to each stream processor (SP). Each multi-processor, in this figure, contains eight stream processors. Each stream processor has its own memory, texture filter (TF). Each pair of processors has a shared L1 cache. Global memory is a shared memory is shared amongst all the stream processors.&lt;br /&gt;
&lt;br /&gt;
[[Image:Cuda_Fig1.png|frame|center|&amp;lt;b&amp;gt;Figure 5:&amp;lt;/b&amp;gt; GPU Multiprocessor Arrangement[[#References|&amp;lt;sup&amp;gt;[7]&amp;lt;/sup&amp;gt;]]]]&lt;br /&gt;
&lt;br /&gt;
==CUDA Threads==&lt;br /&gt;
In CUDA programming, serial operations are still handled by the host CPU (main processor) while parallelizable kernels are handed off to the GPU for processing. It is important to understand the layout of the CUDA architecture and memory. Figure 6 shows a simplified block diagram of a typical CUDA thread model&lt;br /&gt;
&lt;br /&gt;
[[Image:Cuda_Fig2.png|frame|center|&amp;lt;b&amp;gt;Figure 6:&amp;lt;/b&amp;gt; CUDA Thread Model[[#References|&amp;lt;sup&amp;gt;[7]&amp;lt;/sup&amp;gt;]]]]&lt;br /&gt;
&lt;br /&gt;
Each kernel is assigned a grid. Each grid contains a number of blocks. Each block contains threads (512 maximum per block).&lt;br /&gt;
&lt;br /&gt;
==CUDA Programming==&lt;br /&gt;
Programming using CUDA is accomplished via language extensions or wrappers. These extensions are available for a number of common programming langauages such as:&lt;br /&gt;
&lt;br /&gt;
[http://www.hoopoe-cloud.com/Solutions/Fortran/Default.aspx FORTRAN]&lt;br /&gt;
&lt;br /&gt;
[http://www.jcuda.org/jcuda/JCuda.html Java]&lt;br /&gt;
&lt;br /&gt;
[http://psilambda.com/download/kappa-extras Ruby]&lt;br /&gt;
&lt;br /&gt;
[http://mathema.tician.de/software/pycuda Python]&lt;br /&gt;
&lt;br /&gt;
[http://psilambda.com/download/kappa-for-perl Perl]&lt;br /&gt;
&lt;br /&gt;
[http://www.hoopoe-cloud.com/Solutions/CUDA.NET/Default.aspx .NET]&lt;br /&gt;
&lt;br /&gt;
[http://www.accelereyes.com/ MATLAB]&lt;br /&gt;
&lt;br /&gt;
[http://reference.wolfram.com/mathematica/CUDALink/tutorial/Overview.html Mathematica]&lt;br /&gt;
&lt;br /&gt;
Coding using CUDA is fairly straightforward. The listing below[[#References|&amp;lt;sup&amp;gt;[8]&amp;lt;/sup&amp;gt;]] shows a simple program that will square each value in a matrix.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
&amp;lt;nowiki&amp;gt;#include &amp;quot;&amp;lt;/nowiki&amp;gt;stdafx.h&amp;quot;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;nowiki&amp;gt;#include &amp;amp;lt;&amp;lt;/nowiki&amp;gt;stdio.h&amp;amp;gt;&lt;br /&gt;
&amp;lt;nowiki&amp;gt;#include &amp;amp;lt;&amp;lt;/nowiki&amp;gt;cuda.h&amp;amp;gt;&lt;br /&gt;
&lt;br /&gt;
// Kernel that executes on the CUDA device&lt;br /&gt;
&lt;br /&gt;
__global__ void square_array(float *a, int N)&lt;br /&gt;
&lt;br /&gt;
{&lt;br /&gt;
  int idx = blockIdx.x * blockDim.x + threadIdx.x;&lt;br /&gt;
&lt;br /&gt;
  if (idx&amp;lt;nowiki&amp;gt;&amp;amp;lt;N) a[&amp;lt;/nowiki&amp;gt;idx&amp;lt;nowiki&amp;gt;] = a[&amp;lt;/nowiki&amp;gt;idx&amp;lt;nowiki&amp;gt;] * a[&amp;lt;/nowiki&amp;gt;idx];&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
// main routine that executes on the host&lt;br /&gt;
int main(void)&lt;br /&gt;
{&lt;br /&gt;
  float *a_h, *a_d;  // Pointer to host &amp;amp; device arrays&lt;br /&gt;
  const int N = 10;  // Number of elements in arrays&lt;br /&gt;
&lt;br /&gt;
  size_t size = N * sizeof(float);&lt;br /&gt;
&lt;br /&gt;
  a_h = (float *)malloc(size);        // Allocate array on host&lt;br /&gt;
&lt;br /&gt;
  cudaMalloc((void **) &amp;amp;a_d, size);   // Allocate array on device&lt;br /&gt;
&lt;br /&gt;
  // Initialize host array and copy it to CUDA device&lt;br /&gt;
&lt;br /&gt;
  for (int i=0; i&amp;amp;lt;N; i++)&lt;br /&gt;
    a_h&amp;lt;nowiki&amp;gt;[i] = (float&amp;lt;/nowiki&amp;gt;)i;&lt;br /&gt;
  &lt;br /&gt;
  cudaMemcpy(a_d, a_h, size, cudaMemcpyHostToDevice);&lt;br /&gt;
&lt;br /&gt;
  // Do calculation on device:&lt;br /&gt;
  int block_size = 4;&lt;br /&gt;
  int n_blocks = N/block_size + (N%block_size == 0 ? 0:1);&lt;br /&gt;
&lt;br /&gt;
  square_array &amp;amp;lt;&amp;amp;lt;&amp;amp;lt; n_blocks, block_size &amp;amp;gt;&amp;amp;gt;&amp;amp;gt; (a_d, N);&lt;br /&gt;
&lt;br /&gt;
  // Retrieve result from device and store it in host array&lt;br /&gt;
  cudaMemcpy(a_h, a_d, sizeof(float)*N, cudaMemcpyDeviceToHost);&lt;br /&gt;
&lt;br /&gt;
  // Print results&lt;br /&gt;
  for (int i=0; i&amp;amp;lt;N; i++)&lt;br /&gt;
    printf(&amp;quot;%d %f\n&amp;quot;, i, a_h&amp;lt;nowiki&amp;gt;[i]);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
  // Cleanup&lt;br /&gt;
  free(a_h);&lt;br /&gt;
&lt;br /&gt;
  cudaFree(a_d);&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&lt;br /&gt;
# http://www.khronos.org/registry/cl/specs/opencl-1.1.pdf&lt;br /&gt;
# http://en.wikipedia.org/wiki/Comparison_of_AMD_graphics_processing_units#Northern_Islands_.28HD_6xxx.29_series&lt;br /&gt;
# http://developer.amd.com/gpu/AMDAPPSDK/assets/AMD_HD_6900_Series_Instruction_Set_Architecture.pdf&lt;br /&gt;
# http://www.nvidia.com/content/PDF/fermi_white_papers/NVIDIA_Fermi_Compute_Architecture_Whitepaper.pdf&lt;br /&gt;
# http://en.wikipedia.org/wiki/Opencl&lt;br /&gt;
# http://en.wikipedia.org/wiki/CUDA&lt;br /&gt;
# http://courses.engr.illinois.edu/ece498/al&lt;br /&gt;
# http://llpanorama.wordpress.com/2008/05/21/my-first-cuda-program&lt;/div&gt;</summary>
		<author><name>Mqtran</name></author>
	</entry>
</feed>