<?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=Arangan</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=Arangan"/>
	<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Special:Contributions/Arangan"/>
	<updated>2026-08-10T21:10:10Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.41.0</generator>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_2_1r&amp;diff=6107</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 2 1r</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_2_1r&amp;diff=6107"/>
		<updated>2007-10-20T03:39:53Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* External links */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
In parallel systems, data can be obtained from a variety of sources, which includes local or remote memory modules, secondary storage devices and network interfaces. It would be beneficial if certain aspects of mechanisms that are required to gain access to data are standardized such that it allows easily expandable and flexible designs. Various portions of a parallel system may be modified or even upgraded without any effect on the rest of the design if the system adheres to such standards. Also, utilization of standard interfaces forwards the integration of components and subsystems from several different vendors into efficient and usable parallel systems. The Scalable Coherent Interface is one such standard which facilitates the implementation of large-scale cache-coherent parallel systems.&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
===Goals of SCI===&lt;br /&gt;
&lt;br /&gt;
*High Performance – For distributed or parallel applications, high communication performance must be obtained when using SCI. Usual aspects of such performance would be a low latency, low CPU overhead for operations dealing with communication and high sustained throughput.&lt;br /&gt;
&lt;br /&gt;
*Scalability – This is addressed in many ways. Some are&lt;br /&gt;
**Performance scalability – as the number of nodes being added to the system increases.&lt;br /&gt;
**Interconnect Distance scalability&lt;br /&gt;
**Memory System scalability – chiefly of cache coherence protocols, which should not have limitations to the number of processors or modules in memory that it can handle.&lt;br /&gt;
**Technological scalability – utilization of similar mechanisms in large, small-scale, loosely-coupled or tightly-coupled systems. Also, when new advances are made in technology, it must have the ability to readily make use of such advances.&lt;br /&gt;
**Economic scalability – use of similar components and mechanisms in high-end, low-volume systems as well as low-end, high-volume systems.&lt;br /&gt;
**Addressing capability has no short term practical limits.&lt;br /&gt;
&lt;br /&gt;
*Coherent Memory System – For the purpose of reduction of Average Access Time to data, caches are becoming more important each day for microprocessors.&lt;br /&gt;
&lt;br /&gt;
*Interface Characteristics – This specifies a standard interface to an interconnect that makes several devices to be connected or attached together and to interoperate.&lt;br /&gt;
&lt;br /&gt;
===Operation===&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
===Applications===&lt;br /&gt;
&lt;br /&gt;
1. SCI-based CC-NUMA machines&lt;br /&gt;
&lt;br /&gt;
SCI is attached to the memory bus of a node. Here, SCI can take part in and &amp;quot;export&amp;quot; cache coherence and memory traffic on the bus and make the memory of the node visible to other nodes. Each node's memory address range can be scaled to span a global address space, giving coherent and transparent access to anywhere in the system to requesting processors. This method is used to form a large-scale cache-coherent shared-memory system, known as a CC-NUMA machine.&lt;br /&gt;
&lt;br /&gt;
2. SGI Origin 2000&lt;br /&gt;
&lt;br /&gt;
This would seem to be the only commercial alternative to CC-Numa machines. The Origin 2000 is an advanced version of the SCI-based CC-NUMA machines but has its origins in the Stanford DASH project. Cache coherence is maintained here with a bit-vector directory scheme.&lt;br /&gt;
&lt;br /&gt;
3. S3.mp&lt;br /&gt;
&lt;br /&gt;
This was a project by SUN to connect off-the-shelf workstations and make this interconnection into a large-scale cache-coherent multiprocessor. This has an invalidation based protocol which notes the nodes that share a memory block and stores such information in linked lists. The nodes in this project were spatially distributed and were connected together using arbitrary topologies.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Performance &amp;amp; Correctness (Coherence &amp;amp; Consistency) requirement for the protocol necessitates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
=== Need for Busy state ===&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
In Origin, there are 3 busy states indicates that the directory has received the request but is waiting for completion hence another request for the same block won't be accepted.&lt;br /&gt;
# Busy read&lt;br /&gt;
# Busy read exclusive or upgrade&lt;br /&gt;
# Busy uncached read:  In case of DMA, if the memory block is being read, no other processor should be allowed to get write access to it.&lt;br /&gt;
&lt;br /&gt;
=== Poison state ===&lt;br /&gt;
&lt;br /&gt;
To improve locality, origin relies on page migration. Hardware keeps reference counts on each page. On every access of memory count is incremented and compared with home node. If count is more than programmable threshold, hardware interrupts one of the local processors to copy the page. Block transfer engine “poison” the source page. Subsequent accesses by other processors receive a bus error and that removes the TLB entry for that location, read the location from the page table &amp;amp; update the TLB with new location. This approach is called - “Lazy TLB shootdown” which reduces the overall cost of migrating memory and changing the virtual-to-physical address mappings.&lt;br /&gt;
&lt;br /&gt;
=== Additional states ===&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
*The “fresh” state shows that memory still has an up-to-date copy of the block, even if the block        has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
*The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
3. The SGI Origin: A ccnuma Highly Scalable Server&lt;br /&gt;
 Laudon, J.; Lenoski, D.;&lt;br /&gt;
 Computer Architecture, 1997. Conference Proceedings. The 24th Annual International Symposium on&lt;br /&gt;
 June 2-4, 1997 Page(s):241 - 251 &lt;br /&gt;
&lt;br /&gt;
4. The Scalable Coherence Interface&lt;br /&gt;
 David.B.Gustavson&lt;br /&gt;
 September 1991&lt;br /&gt;
 &amp;quot;The Scalable Coherence Interface and related standard projects&amp;quot;&lt;br /&gt;
&lt;br /&gt;
5. An analysis of the Scalable Coherent Interface&lt;br /&gt;
 Eric Rotenberg&lt;br /&gt;
 June 1995&lt;br /&gt;
 An Analytical model of the SCI Coherence protocol&lt;br /&gt;
&lt;br /&gt;
6. Interfaces and Standards : SCI&lt;br /&gt;
 Behrooz. Parhami&lt;br /&gt;
 1999&lt;br /&gt;
 Introduction to Parallel Processing: Algorithms and Architectures&lt;br /&gt;
&lt;br /&gt;
7. SCI: Scalable Coherent Interface&lt;br /&gt;
 Hermann Hellwagner&lt;br /&gt;
 1999&lt;br /&gt;
 SCI: Scalable Coherent Interface - Architecture and software for high-performance Compute Clusters&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
1. The Stanford Dash multiprocessor&lt;br /&gt;
 Lenoski, D.; Laudon, J.; Gharachorloo, K.; Weber, W.-D.; Gupta, A.; Hennessy, J.; Horowitz, M.; Lam, M.S.;&lt;br /&gt;
 Computer&lt;br /&gt;
 IEEE Volume 25,  Issue 3,  March 1992 Page(s):63 - 79&lt;br /&gt;
 Digital Object Identifier 10.1109/2.121510&lt;br /&gt;
&lt;br /&gt;
2. SCI: Scalable Coherent Interface&lt;br /&gt;
 Hermann Hellwagner&lt;br /&gt;
 1999&lt;br /&gt;
 SCI: Scalable Coherent Interface - Architecture and software for high-performance Compute Clusters&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;br /&gt;
&lt;br /&gt;
[http://www.scizzl.com/WhatIsSCI.html www.scizzl.com/WhatIsSCI.html] - What is SCI ?&lt;br /&gt;
&lt;br /&gt;
[http://www.dolphinics.com/corporate/scitech.html www.dolphinics.com/corporate/scitech.html] - The SCI technology provided by Dolphin Interconnect Solutions Inc&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_2_1r&amp;diff=6106</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 2 1r</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_2_1r&amp;diff=6106"/>
		<updated>2007-10-20T03:38:41Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* External links */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
In parallel systems, data can be obtained from a variety of sources, which includes local or remote memory modules, secondary storage devices and network interfaces. It would be beneficial if certain aspects of mechanisms that are required to gain access to data are standardized such that it allows easily expandable and flexible designs. Various portions of a parallel system may be modified or even upgraded without any effect on the rest of the design if the system adheres to such standards. Also, utilization of standard interfaces forwards the integration of components and subsystems from several different vendors into efficient and usable parallel systems. The Scalable Coherent Interface is one such standard which facilitates the implementation of large-scale cache-coherent parallel systems.&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
===Goals of SCI===&lt;br /&gt;
&lt;br /&gt;
*High Performance – For distributed or parallel applications, high communication performance must be obtained when using SCI. Usual aspects of such performance would be a low latency, low CPU overhead for operations dealing with communication and high sustained throughput.&lt;br /&gt;
&lt;br /&gt;
*Scalability – This is addressed in many ways. Some are&lt;br /&gt;
**Performance scalability – as the number of nodes being added to the system increases.&lt;br /&gt;
**Interconnect Distance scalability&lt;br /&gt;
**Memory System scalability – chiefly of cache coherence protocols, which should not have limitations to the number of processors or modules in memory that it can handle.&lt;br /&gt;
**Technological scalability – utilization of similar mechanisms in large, small-scale, loosely-coupled or tightly-coupled systems. Also, when new advances are made in technology, it must have the ability to readily make use of such advances.&lt;br /&gt;
**Economic scalability – use of similar components and mechanisms in high-end, low-volume systems as well as low-end, high-volume systems.&lt;br /&gt;
**Addressing capability has no short term practical limits.&lt;br /&gt;
&lt;br /&gt;
*Coherent Memory System – For the purpose of reduction of Average Access Time to data, caches are becoming more important each day for microprocessors.&lt;br /&gt;
&lt;br /&gt;
*Interface Characteristics – This specifies a standard interface to an interconnect that makes several devices to be connected or attached together and to interoperate.&lt;br /&gt;
&lt;br /&gt;
===Operation===&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
===Applications===&lt;br /&gt;
&lt;br /&gt;
1. SCI-based CC-NUMA machines&lt;br /&gt;
&lt;br /&gt;
SCI is attached to the memory bus of a node. Here, SCI can take part in and &amp;quot;export&amp;quot; cache coherence and memory traffic on the bus and make the memory of the node visible to other nodes. Each node's memory address range can be scaled to span a global address space, giving coherent and transparent access to anywhere in the system to requesting processors. This method is used to form a large-scale cache-coherent shared-memory system, known as a CC-NUMA machine.&lt;br /&gt;
&lt;br /&gt;
2. SGI Origin 2000&lt;br /&gt;
&lt;br /&gt;
This would seem to be the only commercial alternative to CC-Numa machines. The Origin 2000 is an advanced version of the SCI-based CC-NUMA machines but has its origins in the Stanford DASH project. Cache coherence is maintained here with a bit-vector directory scheme.&lt;br /&gt;
&lt;br /&gt;
3. S3.mp&lt;br /&gt;
&lt;br /&gt;
This was a project by SUN to connect off-the-shelf workstations and make this interconnection into a large-scale cache-coherent multiprocessor. This has an invalidation based protocol which notes the nodes that share a memory block and stores such information in linked lists. The nodes in this project were spatially distributed and were connected together using arbitrary topologies.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Performance &amp;amp; Correctness (Coherence &amp;amp; Consistency) requirement for the protocol necessitates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
=== Need for Busy state ===&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
In Origin, there are 3 busy states indicates that the directory has received the request but is waiting for completion hence another request for the same block won't be accepted.&lt;br /&gt;
# Busy read&lt;br /&gt;
# Busy read exclusive or upgrade&lt;br /&gt;
# Busy uncached read:  In case of DMA, if the memory block is being read, no other processor should be allowed to get write access to it.&lt;br /&gt;
&lt;br /&gt;
=== Poison state ===&lt;br /&gt;
&lt;br /&gt;
To improve locality, origin relies on page migration. Hardware keeps reference counts on each page. On every access of memory count is incremented and compared with home node. If count is more than programmable threshold, hardware interrupts one of the local processors to copy the page. Block transfer engine “poison” the source page. Subsequent accesses by other processors receive a bus error and that removes the TLB entry for that location, read the location from the page table &amp;amp; update the TLB with new location. This approach is called - “Lazy TLB shootdown” which reduces the overall cost of migrating memory and changing the virtual-to-physical address mappings.&lt;br /&gt;
&lt;br /&gt;
=== Additional states ===&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
*The “fresh” state shows that memory still has an up-to-date copy of the block, even if the block        has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
*The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
3. The SGI Origin: A ccnuma Highly Scalable Server&lt;br /&gt;
 Laudon, J.; Lenoski, D.;&lt;br /&gt;
 Computer Architecture, 1997. Conference Proceedings. The 24th Annual International Symposium on&lt;br /&gt;
 June 2-4, 1997 Page(s):241 - 251 &lt;br /&gt;
&lt;br /&gt;
4. The Scalable Coherence Interface&lt;br /&gt;
 David.B.Gustavson&lt;br /&gt;
 September 1991&lt;br /&gt;
 &amp;quot;The Scalable Coherence Interface and related standard projects&amp;quot;&lt;br /&gt;
&lt;br /&gt;
5. An analysis of the Scalable Coherent Interface&lt;br /&gt;
 Eric Rotenberg&lt;br /&gt;
 June 1995&lt;br /&gt;
 An Analytical model of the SCI Coherence protocol&lt;br /&gt;
&lt;br /&gt;
6. Interfaces and Standards : SCI&lt;br /&gt;
 Behrooz. Parhami&lt;br /&gt;
 1999&lt;br /&gt;
 Introduction to Parallel Processing: Algorithms and Architectures&lt;br /&gt;
&lt;br /&gt;
7. SCI: Scalable Coherent Interface&lt;br /&gt;
 Hermann Hellwagner&lt;br /&gt;
 1999&lt;br /&gt;
 SCI: Scalable Coherent Interface - Architecture and software for high-performance Compute Clusters&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
1. The Stanford Dash multiprocessor&lt;br /&gt;
 Lenoski, D.; Laudon, J.; Gharachorloo, K.; Weber, W.-D.; Gupta, A.; Hennessy, J.; Horowitz, M.; Lam, M.S.;&lt;br /&gt;
 Computer&lt;br /&gt;
 IEEE Volume 25,  Issue 3,  March 1992 Page(s):63 - 79&lt;br /&gt;
 Digital Object Identifier 10.1109/2.121510&lt;br /&gt;
&lt;br /&gt;
2. SCI: Scalable Coherent Interface&lt;br /&gt;
 Hermann Hellwagner&lt;br /&gt;
 1999&lt;br /&gt;
 SCI: Scalable Coherent Interface - Architecture and software for high-performance Compute Clusters&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;br /&gt;
&lt;br /&gt;
[http://www.scizzl.com/WhatIsSCI.html] - What is SCI ?&lt;br /&gt;
&lt;br /&gt;
[http://www.dolphinics.com/corporate/scitech.html] - The SCI technology provided by Dolphin Interconnect Solutions Inc&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_2_1r&amp;diff=6105</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 2 1r</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_2_1r&amp;diff=6105"/>
		<updated>2007-10-20T03:35:12Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* External links */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
In parallel systems, data can be obtained from a variety of sources, which includes local or remote memory modules, secondary storage devices and network interfaces. It would be beneficial if certain aspects of mechanisms that are required to gain access to data are standardized such that it allows easily expandable and flexible designs. Various portions of a parallel system may be modified or even upgraded without any effect on the rest of the design if the system adheres to such standards. Also, utilization of standard interfaces forwards the integration of components and subsystems from several different vendors into efficient and usable parallel systems. The Scalable Coherent Interface is one such standard which facilitates the implementation of large-scale cache-coherent parallel systems.&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
===Goals of SCI===&lt;br /&gt;
&lt;br /&gt;
*High Performance – For distributed or parallel applications, high communication performance must be obtained when using SCI. Usual aspects of such performance would be a low latency, low CPU overhead for operations dealing with communication and high sustained throughput.&lt;br /&gt;
&lt;br /&gt;
*Scalability – This is addressed in many ways. Some are&lt;br /&gt;
**Performance scalability – as the number of nodes being added to the system increases.&lt;br /&gt;
**Interconnect Distance scalability&lt;br /&gt;
**Memory System scalability – chiefly of cache coherence protocols, which should not have limitations to the number of processors or modules in memory that it can handle.&lt;br /&gt;
**Technological scalability – utilization of similar mechanisms in large, small-scale, loosely-coupled or tightly-coupled systems. Also, when new advances are made in technology, it must have the ability to readily make use of such advances.&lt;br /&gt;
**Economic scalability – use of similar components and mechanisms in high-end, low-volume systems as well as low-end, high-volume systems.&lt;br /&gt;
**Addressing capability has no short term practical limits.&lt;br /&gt;
&lt;br /&gt;
*Coherent Memory System – For the purpose of reduction of Average Access Time to data, caches are becoming more important each day for microprocessors.&lt;br /&gt;
&lt;br /&gt;
*Interface Characteristics – This specifies a standard interface to an interconnect that makes several devices to be connected or attached together and to interoperate.&lt;br /&gt;
&lt;br /&gt;
===Operation===&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
===Applications===&lt;br /&gt;
&lt;br /&gt;
1. SCI-based CC-NUMA machines&lt;br /&gt;
&lt;br /&gt;
SCI is attached to the memory bus of a node. Here, SCI can take part in and &amp;quot;export&amp;quot; cache coherence and memory traffic on the bus and make the memory of the node visible to other nodes. Each node's memory address range can be scaled to span a global address space, giving coherent and transparent access to anywhere in the system to requesting processors. This method is used to form a large-scale cache-coherent shared-memory system, known as a CC-NUMA machine.&lt;br /&gt;
&lt;br /&gt;
2. SGI Origin 2000&lt;br /&gt;
&lt;br /&gt;
This would seem to be the only commercial alternative to CC-Numa machines. The Origin 2000 is an advanced version of the SCI-based CC-NUMA machines but has its origins in the Stanford DASH project. Cache coherence is maintained here with a bit-vector directory scheme.&lt;br /&gt;
&lt;br /&gt;
3. S3.mp&lt;br /&gt;
&lt;br /&gt;
This was a project by SUN to connect off-the-shelf workstations and make this interconnection into a large-scale cache-coherent multiprocessor. This has an invalidation based protocol which notes the nodes that share a memory block and stores such information in linked lists. The nodes in this project were spatially distributed and were connected together using arbitrary topologies.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Performance &amp;amp; Correctness (Coherence &amp;amp; Consistency) requirement for the protocol necessitates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
=== Need for Busy state ===&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
In Origin, there are 3 busy states indicates that the directory has received the request but is waiting for completion hence another request for the same block won't be accepted.&lt;br /&gt;
# Busy read&lt;br /&gt;
# Busy read exclusive or upgrade&lt;br /&gt;
# Busy uncached read:  In case of DMA, if the memory block is being read, no other processor should be allowed to get write access to it.&lt;br /&gt;
&lt;br /&gt;
=== Poison state ===&lt;br /&gt;
&lt;br /&gt;
To improve locality, origin relies on page migration. Hardware keeps reference counts on each page. On every access of memory count is incremented and compared with home node. If count is more than programmable threshold, hardware interrupts one of the local processors to copy the page. Block transfer engine “poison” the source page. Subsequent accesses by other processors receive a bus error and that removes the TLB entry for that location, read the location from the page table &amp;amp; update the TLB with new location. This approach is called - “Lazy TLB shootdown” which reduces the overall cost of migrating memory and changing the virtual-to-physical address mappings.&lt;br /&gt;
&lt;br /&gt;
=== Additional states ===&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
*The “fresh” state shows that memory still has an up-to-date copy of the block, even if the block        has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
*The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
3. The SGI Origin: A ccnuma Highly Scalable Server&lt;br /&gt;
 Laudon, J.; Lenoski, D.;&lt;br /&gt;
 Computer Architecture, 1997. Conference Proceedings. The 24th Annual International Symposium on&lt;br /&gt;
 June 2-4, 1997 Page(s):241 - 251 &lt;br /&gt;
&lt;br /&gt;
4. The Scalable Coherence Interface&lt;br /&gt;
 David.B.Gustavson&lt;br /&gt;
 September 1991&lt;br /&gt;
 &amp;quot;The Scalable Coherence Interface and related standard projects&amp;quot;&lt;br /&gt;
&lt;br /&gt;
5. An analysis of the Scalable Coherent Interface&lt;br /&gt;
 Eric Rotenberg&lt;br /&gt;
 June 1995&lt;br /&gt;
 An Analytical model of the SCI Coherence protocol&lt;br /&gt;
&lt;br /&gt;
6. Interfaces and Standards : SCI&lt;br /&gt;
 Behrooz. Parhami&lt;br /&gt;
 1999&lt;br /&gt;
 Introduction to Parallel Processing: Algorithms and Architectures&lt;br /&gt;
&lt;br /&gt;
7. SCI: Scalable Coherent Interface&lt;br /&gt;
 Hermann Hellwagner&lt;br /&gt;
 1999&lt;br /&gt;
 SCI: Scalable Coherent Interface - Architecture and software for high-performance Compute Clusters&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
1. The Stanford Dash multiprocessor&lt;br /&gt;
 Lenoski, D.; Laudon, J.; Gharachorloo, K.; Weber, W.-D.; Gupta, A.; Hennessy, J.; Horowitz, M.; Lam, M.S.;&lt;br /&gt;
 Computer&lt;br /&gt;
 IEEE Volume 25,  Issue 3,  March 1992 Page(s):63 - 79&lt;br /&gt;
 Digital Object Identifier 10.1109/2.121510&lt;br /&gt;
&lt;br /&gt;
2. SCI: Scalable Coherent Interface&lt;br /&gt;
 Hermann Hellwagner&lt;br /&gt;
 1999&lt;br /&gt;
 SCI: Scalable Coherent Interface - Architecture and software for high-performance Compute Clusters&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;br /&gt;
&lt;br /&gt;
[www.scizzl.com/WhatIsSCI.html] - What is SCI ?&lt;br /&gt;
&lt;br /&gt;
[www.dolphinics.com/corporate/scitech.html] - The SCI technology provided by Dolphin Interconnect Solutions Inc&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_2_1r&amp;diff=6104</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 2 1r</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_2_1r&amp;diff=6104"/>
		<updated>2007-10-20T03:34:22Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* External links */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
In parallel systems, data can be obtained from a variety of sources, which includes local or remote memory modules, secondary storage devices and network interfaces. It would be beneficial if certain aspects of mechanisms that are required to gain access to data are standardized such that it allows easily expandable and flexible designs. Various portions of a parallel system may be modified or even upgraded without any effect on the rest of the design if the system adheres to such standards. Also, utilization of standard interfaces forwards the integration of components and subsystems from several different vendors into efficient and usable parallel systems. The Scalable Coherent Interface is one such standard which facilitates the implementation of large-scale cache-coherent parallel systems.&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
===Goals of SCI===&lt;br /&gt;
&lt;br /&gt;
*High Performance – For distributed or parallel applications, high communication performance must be obtained when using SCI. Usual aspects of such performance would be a low latency, low CPU overhead for operations dealing with communication and high sustained throughput.&lt;br /&gt;
&lt;br /&gt;
*Scalability – This is addressed in many ways. Some are&lt;br /&gt;
**Performance scalability – as the number of nodes being added to the system increases.&lt;br /&gt;
**Interconnect Distance scalability&lt;br /&gt;
**Memory System scalability – chiefly of cache coherence protocols, which should not have limitations to the number of processors or modules in memory that it can handle.&lt;br /&gt;
**Technological scalability – utilization of similar mechanisms in large, small-scale, loosely-coupled or tightly-coupled systems. Also, when new advances are made in technology, it must have the ability to readily make use of such advances.&lt;br /&gt;
**Economic scalability – use of similar components and mechanisms in high-end, low-volume systems as well as low-end, high-volume systems.&lt;br /&gt;
**Addressing capability has no short term practical limits.&lt;br /&gt;
&lt;br /&gt;
*Coherent Memory System – For the purpose of reduction of Average Access Time to data, caches are becoming more important each day for microprocessors.&lt;br /&gt;
&lt;br /&gt;
*Interface Characteristics – This specifies a standard interface to an interconnect that makes several devices to be connected or attached together and to interoperate.&lt;br /&gt;
&lt;br /&gt;
===Operation===&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
===Applications===&lt;br /&gt;
&lt;br /&gt;
1. SCI-based CC-NUMA machines&lt;br /&gt;
&lt;br /&gt;
SCI is attached to the memory bus of a node. Here, SCI can take part in and &amp;quot;export&amp;quot; cache coherence and memory traffic on the bus and make the memory of the node visible to other nodes. Each node's memory address range can be scaled to span a global address space, giving coherent and transparent access to anywhere in the system to requesting processors. This method is used to form a large-scale cache-coherent shared-memory system, known as a CC-NUMA machine.&lt;br /&gt;
&lt;br /&gt;
2. SGI Origin 2000&lt;br /&gt;
&lt;br /&gt;
This would seem to be the only commercial alternative to CC-Numa machines. The Origin 2000 is an advanced version of the SCI-based CC-NUMA machines but has its origins in the Stanford DASH project. Cache coherence is maintained here with a bit-vector directory scheme.&lt;br /&gt;
&lt;br /&gt;
3. S3.mp&lt;br /&gt;
&lt;br /&gt;
This was a project by SUN to connect off-the-shelf workstations and make this interconnection into a large-scale cache-coherent multiprocessor. This has an invalidation based protocol which notes the nodes that share a memory block and stores such information in linked lists. The nodes in this project were spatially distributed and were connected together using arbitrary topologies.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Performance &amp;amp; Correctness (Coherence &amp;amp; Consistency) requirement for the protocol necessitates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
=== Need for Busy state ===&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
In Origin, there are 3 busy states indicates that the directory has received the request but is waiting for completion hence another request for the same block won't be accepted.&lt;br /&gt;
# Busy read&lt;br /&gt;
# Busy read exclusive or upgrade&lt;br /&gt;
# Busy uncached read:  In case of DMA, if the memory block is being read, no other processor should be allowed to get write access to it.&lt;br /&gt;
&lt;br /&gt;
=== Poison state ===&lt;br /&gt;
&lt;br /&gt;
To improve locality, origin relies on page migration. Hardware keeps reference counts on each page. On every access of memory count is incremented and compared with home node. If count is more than programmable threshold, hardware interrupts one of the local processors to copy the page. Block transfer engine “poison” the source page. Subsequent accesses by other processors receive a bus error and that removes the TLB entry for that location, read the location from the page table &amp;amp; update the TLB with new location. This approach is called - “Lazy TLB shootdown” which reduces the overall cost of migrating memory and changing the virtual-to-physical address mappings.&lt;br /&gt;
&lt;br /&gt;
=== Additional states ===&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
*The “fresh” state shows that memory still has an up-to-date copy of the block, even if the block        has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
*The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
3. The SGI Origin: A ccnuma Highly Scalable Server&lt;br /&gt;
 Laudon, J.; Lenoski, D.;&lt;br /&gt;
 Computer Architecture, 1997. Conference Proceedings. The 24th Annual International Symposium on&lt;br /&gt;
 June 2-4, 1997 Page(s):241 - 251 &lt;br /&gt;
&lt;br /&gt;
4. The Scalable Coherence Interface&lt;br /&gt;
 David.B.Gustavson&lt;br /&gt;
 September 1991&lt;br /&gt;
 &amp;quot;The Scalable Coherence Interface and related standard projects&amp;quot;&lt;br /&gt;
&lt;br /&gt;
5. An analysis of the Scalable Coherent Interface&lt;br /&gt;
 Eric Rotenberg&lt;br /&gt;
 June 1995&lt;br /&gt;
 An Analytical model of the SCI Coherence protocol&lt;br /&gt;
&lt;br /&gt;
6. Interfaces and Standards : SCI&lt;br /&gt;
 Behrooz. Parhami&lt;br /&gt;
 1999&lt;br /&gt;
 Introduction to Parallel Processing: Algorithms and Architectures&lt;br /&gt;
&lt;br /&gt;
7. SCI: Scalable Coherent Interface&lt;br /&gt;
 Hermann Hellwagner&lt;br /&gt;
 1999&lt;br /&gt;
 SCI: Scalable Coherent Interface - Architecture and software for high-performance Compute Clusters&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
1. The Stanford Dash multiprocessor&lt;br /&gt;
 Lenoski, D.; Laudon, J.; Gharachorloo, K.; Weber, W.-D.; Gupta, A.; Hennessy, J.; Horowitz, M.; Lam, M.S.;&lt;br /&gt;
 Computer&lt;br /&gt;
 IEEE Volume 25,  Issue 3,  March 1992 Page(s):63 - 79&lt;br /&gt;
 Digital Object Identifier 10.1109/2.121510&lt;br /&gt;
&lt;br /&gt;
2. SCI: Scalable Coherent Interface&lt;br /&gt;
 Hermann Hellwagner&lt;br /&gt;
 1999&lt;br /&gt;
 SCI: Scalable Coherent Interface - Architecture and software for high-performance Compute Clusters&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;br /&gt;
&lt;br /&gt;
www.scizzl.com/WhatIsSCI.html - What is SCI ?&lt;br /&gt;
&lt;br /&gt;
www.dolphinics.com/corporate/scitech.html - The SCI technology provided by Dolphin Interconnect Solutions Inc&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_2_1r&amp;diff=6103</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 2 1r</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_2_1r&amp;diff=6103"/>
		<updated>2007-10-20T03:31:22Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* Applications */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
In parallel systems, data can be obtained from a variety of sources, which includes local or remote memory modules, secondary storage devices and network interfaces. It would be beneficial if certain aspects of mechanisms that are required to gain access to data are standardized such that it allows easily expandable and flexible designs. Various portions of a parallel system may be modified or even upgraded without any effect on the rest of the design if the system adheres to such standards. Also, utilization of standard interfaces forwards the integration of components and subsystems from several different vendors into efficient and usable parallel systems. The Scalable Coherent Interface is one such standard which facilitates the implementation of large-scale cache-coherent parallel systems.&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
===Goals of SCI===&lt;br /&gt;
&lt;br /&gt;
*High Performance – For distributed or parallel applications, high communication performance must be obtained when using SCI. Usual aspects of such performance would be a low latency, low CPU overhead for operations dealing with communication and high sustained throughput.&lt;br /&gt;
&lt;br /&gt;
*Scalability – This is addressed in many ways. Some are&lt;br /&gt;
**Performance scalability – as the number of nodes being added to the system increases.&lt;br /&gt;
**Interconnect Distance scalability&lt;br /&gt;
**Memory System scalability – chiefly of cache coherence protocols, which should not have limitations to the number of processors or modules in memory that it can handle.&lt;br /&gt;
**Technological scalability – utilization of similar mechanisms in large, small-scale, loosely-coupled or tightly-coupled systems. Also, when new advances are made in technology, it must have the ability to readily make use of such advances.&lt;br /&gt;
**Economic scalability – use of similar components and mechanisms in high-end, low-volume systems as well as low-end, high-volume systems.&lt;br /&gt;
**Addressing capability has no short term practical limits.&lt;br /&gt;
&lt;br /&gt;
*Coherent Memory System – For the purpose of reduction of Average Access Time to data, caches are becoming more important each day for microprocessors.&lt;br /&gt;
&lt;br /&gt;
*Interface Characteristics – This specifies a standard interface to an interconnect that makes several devices to be connected or attached together and to interoperate.&lt;br /&gt;
&lt;br /&gt;
===Operation===&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
===Applications===&lt;br /&gt;
&lt;br /&gt;
1. SCI-based CC-NUMA machines&lt;br /&gt;
&lt;br /&gt;
SCI is attached to the memory bus of a node. Here, SCI can take part in and &amp;quot;export&amp;quot; cache coherence and memory traffic on the bus and make the memory of the node visible to other nodes. Each node's memory address range can be scaled to span a global address space, giving coherent and transparent access to anywhere in the system to requesting processors. This method is used to form a large-scale cache-coherent shared-memory system, known as a CC-NUMA machine.&lt;br /&gt;
&lt;br /&gt;
2. SGI Origin 2000&lt;br /&gt;
&lt;br /&gt;
This would seem to be the only commercial alternative to CC-Numa machines. The Origin 2000 is an advanced version of the SCI-based CC-NUMA machines but has its origins in the Stanford DASH project. Cache coherence is maintained here with a bit-vector directory scheme.&lt;br /&gt;
&lt;br /&gt;
3. S3.mp&lt;br /&gt;
&lt;br /&gt;
This was a project by SUN to connect off-the-shelf workstations and make this interconnection into a large-scale cache-coherent multiprocessor. This has an invalidation based protocol which notes the nodes that share a memory block and stores such information in linked lists. The nodes in this project were spatially distributed and were connected together using arbitrary topologies.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Performance &amp;amp; Correctness (Coherence &amp;amp; Consistency) requirement for the protocol necessitates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
=== Need for Busy state ===&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
In Origin, there are 3 busy states indicates that the directory has received the request but is waiting for completion hence another request for the same block won't be accepted.&lt;br /&gt;
# Busy read&lt;br /&gt;
# Busy read exclusive or upgrade&lt;br /&gt;
# Busy uncached read:  In case of DMA, if the memory block is being read, no other processor should be allowed to get write access to it.&lt;br /&gt;
&lt;br /&gt;
=== Poison state ===&lt;br /&gt;
&lt;br /&gt;
To improve locality, origin relies on page migration. Hardware keeps reference counts on each page. On every access of memory count is incremented and compared with home node. If count is more than programmable threshold, hardware interrupts one of the local processors to copy the page. Block transfer engine “poison” the source page. Subsequent accesses by other processors receive a bus error and that removes the TLB entry for that location, read the location from the page table &amp;amp; update the TLB with new location. This approach is called - “Lazy TLB shootdown” which reduces the overall cost of migrating memory and changing the virtual-to-physical address mappings.&lt;br /&gt;
&lt;br /&gt;
=== Additional states ===&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
*The “fresh” state shows that memory still has an up-to-date copy of the block, even if the block        has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
*The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
3. The SGI Origin: A ccnuma Highly Scalable Server&lt;br /&gt;
 Laudon, J.; Lenoski, D.;&lt;br /&gt;
 Computer Architecture, 1997. Conference Proceedings. The 24th Annual International Symposium on&lt;br /&gt;
 June 2-4, 1997 Page(s):241 - 251 &lt;br /&gt;
&lt;br /&gt;
4. The Scalable Coherence Interface&lt;br /&gt;
 David.B.Gustavson&lt;br /&gt;
 September 1991&lt;br /&gt;
 &amp;quot;The Scalable Coherence Interface and related standard projects&amp;quot;&lt;br /&gt;
&lt;br /&gt;
5. An analysis of the Scalable Coherent Interface&lt;br /&gt;
 Eric Rotenberg&lt;br /&gt;
 June 1995&lt;br /&gt;
 An Analytical model of the SCI Coherence protocol&lt;br /&gt;
&lt;br /&gt;
6. Interfaces and Standards : SCI&lt;br /&gt;
 Behrooz. Parhami&lt;br /&gt;
 1999&lt;br /&gt;
 Introduction to Parallel Processing: Algorithms and Architectures&lt;br /&gt;
&lt;br /&gt;
7. SCI: Scalable Coherent Interface&lt;br /&gt;
 Hermann Hellwagner&lt;br /&gt;
 1999&lt;br /&gt;
 SCI: Scalable Coherent Interface - Architecture and software for high-performance Compute Clusters&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
1. The Stanford Dash multiprocessor&lt;br /&gt;
 Lenoski, D.; Laudon, J.; Gharachorloo, K.; Weber, W.-D.; Gupta, A.; Hennessy, J.; Horowitz, M.; Lam, M.S.;&lt;br /&gt;
 Computer&lt;br /&gt;
 IEEE Volume 25,  Issue 3,  March 1992 Page(s):63 - 79&lt;br /&gt;
 Digital Object Identifier 10.1109/2.121510&lt;br /&gt;
&lt;br /&gt;
2. SCI: Scalable Coherent Interface&lt;br /&gt;
 Hermann Hellwagner&lt;br /&gt;
 1999&lt;br /&gt;
 SCI: Scalable Coherent Interface - Architecture and software for high-performance Compute Clusters&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_2_1r&amp;diff=6102</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 2 1r</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_2_1r&amp;diff=6102"/>
		<updated>2007-10-20T03:30:53Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* Scalable Coherent Interface (SCI) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
In parallel systems, data can be obtained from a variety of sources, which includes local or remote memory modules, secondary storage devices and network interfaces. It would be beneficial if certain aspects of mechanisms that are required to gain access to data are standardized such that it allows easily expandable and flexible designs. Various portions of a parallel system may be modified or even upgraded without any effect on the rest of the design if the system adheres to such standards. Also, utilization of standard interfaces forwards the integration of components and subsystems from several different vendors into efficient and usable parallel systems. The Scalable Coherent Interface is one such standard which facilitates the implementation of large-scale cache-coherent parallel systems.&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
===Goals of SCI===&lt;br /&gt;
&lt;br /&gt;
*High Performance – For distributed or parallel applications, high communication performance must be obtained when using SCI. Usual aspects of such performance would be a low latency, low CPU overhead for operations dealing with communication and high sustained throughput.&lt;br /&gt;
&lt;br /&gt;
*Scalability – This is addressed in many ways. Some are&lt;br /&gt;
**Performance scalability – as the number of nodes being added to the system increases.&lt;br /&gt;
**Interconnect Distance scalability&lt;br /&gt;
**Memory System scalability – chiefly of cache coherence protocols, which should not have limitations to the number of processors or modules in memory that it can handle.&lt;br /&gt;
**Technological scalability – utilization of similar mechanisms in large, small-scale, loosely-coupled or tightly-coupled systems. Also, when new advances are made in technology, it must have the ability to readily make use of such advances.&lt;br /&gt;
**Economic scalability – use of similar components and mechanisms in high-end, low-volume systems as well as low-end, high-volume systems.&lt;br /&gt;
**Addressing capability has no short term practical limits.&lt;br /&gt;
&lt;br /&gt;
*Coherent Memory System – For the purpose of reduction of Average Access Time to data, caches are becoming more important each day for microprocessors.&lt;br /&gt;
&lt;br /&gt;
*Interface Characteristics – This specifies a standard interface to an interconnect that makes several devices to be connected or attached together and to interoperate.&lt;br /&gt;
&lt;br /&gt;
===Operation===&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
===Applications===&lt;br /&gt;
&lt;br /&gt;
1. SCI-based CC-NUMA machines ===&lt;br /&gt;
&lt;br /&gt;
SCI is attached to the memory bus of a node. Here, SCI can take part in and &amp;quot;export&amp;quot; cache coherence and memory traffic on the bus and make the memory of the node visible to other nodes. Each node's memory address range can be scaled to span a global address space, giving coherent and transparent access to anywhere in the system to requesting processors. This method is used to form a large-scale cache-coherent shared-memory system, known as a CC-NUMA machine.&lt;br /&gt;
&lt;br /&gt;
2. SGI Origin 2000 ===&lt;br /&gt;
&lt;br /&gt;
This would seem to be the only commercial alternative to CC-Numa machines. The Origin 2000 is an advanced version of the SCI-based CC-NUMA machines but has its origins in the Stanford DASH project. Cache coherence is maintained here with a bit-vector directory scheme.&lt;br /&gt;
&lt;br /&gt;
3. S3.mp ===&lt;br /&gt;
&lt;br /&gt;
This was a project by SUN to connect off-the-shelf workstations and make this interconnection into a large-scale cache-coherent multiprocessor. This has an invalidation based protocol which notes the nodes that share a memory block and stores such information in linked lists. The nodes in this project were spatially distributed and were connected together using arbitrary topologies.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Performance &amp;amp; Correctness (Coherence &amp;amp; Consistency) requirement for the protocol necessitates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
=== Need for Busy state ===&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
In Origin, there are 3 busy states indicates that the directory has received the request but is waiting for completion hence another request for the same block won't be accepted.&lt;br /&gt;
# Busy read&lt;br /&gt;
# Busy read exclusive or upgrade&lt;br /&gt;
# Busy uncached read:  In case of DMA, if the memory block is being read, no other processor should be allowed to get write access to it.&lt;br /&gt;
&lt;br /&gt;
=== Poison state ===&lt;br /&gt;
&lt;br /&gt;
To improve locality, origin relies on page migration. Hardware keeps reference counts on each page. On every access of memory count is incremented and compared with home node. If count is more than programmable threshold, hardware interrupts one of the local processors to copy the page. Block transfer engine “poison” the source page. Subsequent accesses by other processors receive a bus error and that removes the TLB entry for that location, read the location from the page table &amp;amp; update the TLB with new location. This approach is called - “Lazy TLB shootdown” which reduces the overall cost of migrating memory and changing the virtual-to-physical address mappings.&lt;br /&gt;
&lt;br /&gt;
=== Additional states ===&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
*The “fresh” state shows that memory still has an up-to-date copy of the block, even if the block        has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
*The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
3. The SGI Origin: A ccnuma Highly Scalable Server&lt;br /&gt;
 Laudon, J.; Lenoski, D.;&lt;br /&gt;
 Computer Architecture, 1997. Conference Proceedings. The 24th Annual International Symposium on&lt;br /&gt;
 June 2-4, 1997 Page(s):241 - 251 &lt;br /&gt;
&lt;br /&gt;
4. The Scalable Coherence Interface&lt;br /&gt;
 David.B.Gustavson&lt;br /&gt;
 September 1991&lt;br /&gt;
 &amp;quot;The Scalable Coherence Interface and related standard projects&amp;quot;&lt;br /&gt;
&lt;br /&gt;
5. An analysis of the Scalable Coherent Interface&lt;br /&gt;
 Eric Rotenberg&lt;br /&gt;
 June 1995&lt;br /&gt;
 An Analytical model of the SCI Coherence protocol&lt;br /&gt;
&lt;br /&gt;
6. Interfaces and Standards : SCI&lt;br /&gt;
 Behrooz. Parhami&lt;br /&gt;
 1999&lt;br /&gt;
 Introduction to Parallel Processing: Algorithms and Architectures&lt;br /&gt;
&lt;br /&gt;
7. SCI: Scalable Coherent Interface&lt;br /&gt;
 Hermann Hellwagner&lt;br /&gt;
 1999&lt;br /&gt;
 SCI: Scalable Coherent Interface - Architecture and software for high-performance Compute Clusters&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
1. The Stanford Dash multiprocessor&lt;br /&gt;
 Lenoski, D.; Laudon, J.; Gharachorloo, K.; Weber, W.-D.; Gupta, A.; Hennessy, J.; Horowitz, M.; Lam, M.S.;&lt;br /&gt;
 Computer&lt;br /&gt;
 IEEE Volume 25,  Issue 3,  March 1992 Page(s):63 - 79&lt;br /&gt;
 Digital Object Identifier 10.1109/2.121510&lt;br /&gt;
&lt;br /&gt;
2. SCI: Scalable Coherent Interface&lt;br /&gt;
 Hermann Hellwagner&lt;br /&gt;
 1999&lt;br /&gt;
 SCI: Scalable Coherent Interface - Architecture and software for high-performance Compute Clusters&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_2_1r&amp;diff=6101</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 2 1r</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_2_1r&amp;diff=6101"/>
		<updated>2007-10-20T03:30:05Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* Examples */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
In parallel systems, data can be obtained from a variety of sources, which includes local or remote memory modules, secondary storage devices and network interfaces. It would be beneficial if certain aspects of mechanisms that are required to gain access to data are standardized such that it allows easily expandable and flexible designs. Various portions of a parallel system may be modified or even upgraded without any effect on the rest of the design if the system adheres to such standards. Also, utilization of standard interfaces forwards the integration of components and subsystems from several different vendors into efficient and usable parallel systems. The Scalable Coherent Interface is one such standard which facilitates the implementation of large-scale cache-coherent parallel systems.&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
===Goals of SCI===&lt;br /&gt;
&lt;br /&gt;
*High Performance – For distributed or parallel applications, high communication performance must be obtained when using SCI. Usual aspects of such performance would be a low latency, low CPU overhead for operations dealing with communication and high sustained throughput.&lt;br /&gt;
&lt;br /&gt;
*Scalability – This is addressed in many ways. Some are&lt;br /&gt;
**Performance scalability – as the number of nodes being added to the system increases.&lt;br /&gt;
**Interconnect Distance scalability&lt;br /&gt;
**Memory System scalability – chiefly of cache coherence protocols, which should not have limitations to the number of processors or modules in memory that it can handle.&lt;br /&gt;
**Technological scalability – utilization of similar mechanisms in large, small-scale, loosely-coupled or tightly-coupled systems. Also, when new advances are made in technology, it must have the ability to readily make use of such advances.&lt;br /&gt;
**Economic scalability – use of similar components and mechanisms in high-end, low-volume systems as well as low-end, high-volume systems.&lt;br /&gt;
**Addressing capability has no short term practical limits.&lt;br /&gt;
&lt;br /&gt;
*Coherent Memory System – For the purpose of reduction of Average Access Time to data, caches are becoming more important each day for microprocessors.&lt;br /&gt;
&lt;br /&gt;
*Interface Characteristics – This specifies a standard interface to an interconnect that makes several devices to be connected or attached together and to interoperate.&lt;br /&gt;
&lt;br /&gt;
===Operation===&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Performance &amp;amp; Correctness (Coherence &amp;amp; Consistency) requirement for the protocol necessitates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
=== Need for Busy state ===&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
In Origin, there are 3 busy states indicates that the directory has received the request but is waiting for completion hence another request for the same block won't be accepted.&lt;br /&gt;
# Busy read&lt;br /&gt;
# Busy read exclusive or upgrade&lt;br /&gt;
# Busy uncached read:  In case of DMA, if the memory block is being read, no other processor should be allowed to get write access to it.&lt;br /&gt;
&lt;br /&gt;
=== Poison state ===&lt;br /&gt;
&lt;br /&gt;
To improve locality, origin relies on page migration. Hardware keeps reference counts on each page. On every access of memory count is incremented and compared with home node. If count is more than programmable threshold, hardware interrupts one of the local processors to copy the page. Block transfer engine “poison” the source page. Subsequent accesses by other processors receive a bus error and that removes the TLB entry for that location, read the location from the page table &amp;amp; update the TLB with new location. This approach is called - “Lazy TLB shootdown” which reduces the overall cost of migrating memory and changing the virtual-to-physical address mappings.&lt;br /&gt;
&lt;br /&gt;
=== Additional states ===&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
*The “fresh” state shows that memory still has an up-to-date copy of the block, even if the block        has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
*The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
3. The SGI Origin: A ccnuma Highly Scalable Server&lt;br /&gt;
 Laudon, J.; Lenoski, D.;&lt;br /&gt;
 Computer Architecture, 1997. Conference Proceedings. The 24th Annual International Symposium on&lt;br /&gt;
 June 2-4, 1997 Page(s):241 - 251 &lt;br /&gt;
&lt;br /&gt;
4. The Scalable Coherence Interface&lt;br /&gt;
 David.B.Gustavson&lt;br /&gt;
 September 1991&lt;br /&gt;
 &amp;quot;The Scalable Coherence Interface and related standard projects&amp;quot;&lt;br /&gt;
&lt;br /&gt;
5. An analysis of the Scalable Coherent Interface&lt;br /&gt;
 Eric Rotenberg&lt;br /&gt;
 June 1995&lt;br /&gt;
 An Analytical model of the SCI Coherence protocol&lt;br /&gt;
&lt;br /&gt;
6. Interfaces and Standards : SCI&lt;br /&gt;
 Behrooz. Parhami&lt;br /&gt;
 1999&lt;br /&gt;
 Introduction to Parallel Processing: Algorithms and Architectures&lt;br /&gt;
&lt;br /&gt;
7. SCI: Scalable Coherent Interface&lt;br /&gt;
 Hermann Hellwagner&lt;br /&gt;
 1999&lt;br /&gt;
 SCI: Scalable Coherent Interface - Architecture and software for high-performance Compute Clusters&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
1. The Stanford Dash multiprocessor&lt;br /&gt;
 Lenoski, D.; Laudon, J.; Gharachorloo, K.; Weber, W.-D.; Gupta, A.; Hennessy, J.; Horowitz, M.; Lam, M.S.;&lt;br /&gt;
 Computer&lt;br /&gt;
 IEEE Volume 25,  Issue 3,  March 1992 Page(s):63 - 79&lt;br /&gt;
 Digital Object Identifier 10.1109/2.121510&lt;br /&gt;
&lt;br /&gt;
2. SCI: Scalable Coherent Interface&lt;br /&gt;
 Hermann Hellwagner&lt;br /&gt;
 1999&lt;br /&gt;
 SCI: Scalable Coherent Interface - Architecture and software for high-performance Compute Clusters&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_2_1r&amp;diff=6098</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 2 1r</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_2_1r&amp;diff=6098"/>
		<updated>2007-10-20T03:28:25Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* 4. S3.mp */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
In parallel systems, data can be obtained from a variety of sources, which includes local or remote memory modules, secondary storage devices and network interfaces. It would be beneficial if certain aspects of mechanisms that are required to gain access to data are standardized such that it allows easily expandable and flexible designs. Various portions of a parallel system may be modified or even upgraded without any effect on the rest of the design if the system adheres to such standards. Also, utilization of standard interfaces forwards the integration of components and subsystems from several different vendors into efficient and usable parallel systems. The Scalable Coherent Interface is one such standard which facilitates the implementation of large-scale cache-coherent parallel systems.&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
===Goals of SCI===&lt;br /&gt;
&lt;br /&gt;
*High Performance – For distributed or parallel applications, high communication performance must be obtained when using SCI. Usual aspects of such performance would be a low latency, low CPU overhead for operations dealing with communication and high sustained throughput.&lt;br /&gt;
&lt;br /&gt;
*Scalability – This is addressed in many ways. Some are&lt;br /&gt;
**Performance scalability – as the number of nodes being added to the system increases.&lt;br /&gt;
**Interconnect Distance scalability&lt;br /&gt;
**Memory System scalability – chiefly of cache coherence protocols, which should not have limitations to the number of processors or modules in memory that it can handle.&lt;br /&gt;
**Technological scalability – utilization of similar mechanisms in large, small-scale, loosely-coupled or tightly-coupled systems. Also, when new advances are made in technology, it must have the ability to readily make use of such advances.&lt;br /&gt;
**Economic scalability – use of similar components and mechanisms in high-end, low-volume systems as well as low-end, high-volume systems.&lt;br /&gt;
**Addressing capability has no short term practical limits.&lt;br /&gt;
&lt;br /&gt;
*Coherent Memory System – For the purpose of reduction of Average Access Time to data, caches are becoming more important each day for microprocessors.&lt;br /&gt;
&lt;br /&gt;
*Interface Characteristics – This specifies a standard interface to an interconnect that makes several devices to be connected or attached together and to interoperate.&lt;br /&gt;
&lt;br /&gt;
===Operation===&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Performance &amp;amp; Correctness (Coherence &amp;amp; Consistency) requirement for the protocol necessitates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
=== Need for Busy state ===&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
In Origin, there are 3 busy states indicates that the directory has received the request but is waiting for completion hence another request for the same block won't be accepted.&lt;br /&gt;
# Busy read&lt;br /&gt;
# Busy read exclusive or upgrade&lt;br /&gt;
# Busy uncached read:  In case of DMA, if the memory block is being read, no other processor should be allowed to get write access to it.&lt;br /&gt;
&lt;br /&gt;
=== Poison state ===&lt;br /&gt;
&lt;br /&gt;
To improve locality, origin relies on page migration. Hardware keeps reference counts on each page. On every access of memory count is incremented and compared with home node. If count is more than programmable threshold, hardware interrupts one of the local processors to copy the page. Block transfer engine “poison” the source page. Subsequent accesses by other processors receive a bus error and that removes the TLB entry for that location, read the location from the page table &amp;amp; update the TLB with new location. This approach is called - “Lazy TLB shootdown” which reduces the overall cost of migrating memory and changing the virtual-to-physical address mappings.&lt;br /&gt;
&lt;br /&gt;
=== Additional states ===&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
*The “fresh” state shows that memory still has an up-to-date copy of the block, even if the block        has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
*The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== 1. DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
=== 2. SCI-based CC-NUMA machines ===&lt;br /&gt;
&lt;br /&gt;
SCI is attached to the memory bus of a node. Here, SCI can take part in and &amp;quot;export&amp;quot; cache coherence and memory traffic on the bus and make the memory of the node visible to other nodes. Each node's memory address range can be scaled to span a global address space, giving coherent and transparent access to anywhere in the system to requesting processors. This method is used to form a large-scale cache-coherent shared-memory system, known as a CC-NUMA machine.&lt;br /&gt;
&lt;br /&gt;
=== 3. SGI Origin 2000 ===&lt;br /&gt;
&lt;br /&gt;
This would seem to be the only commercial alternative to CC-Numa machines. The Origin 2000 is an advanced version of the SCI-based CC-NUMA machines but has its origins in the Stanford DASH project. Cache coherence is maintained here with a bit-vector directory scheme.&lt;br /&gt;
&lt;br /&gt;
=== 4. S3.mp ===&lt;br /&gt;
&lt;br /&gt;
This was a project by SUN to connect off-the-shelf workstations and make this interconnection into a large-scale cache-coherent multiprocessor. This has an invalidation based protocol which notes the nodes that share a memory block and stores such information in linked lists. The nodes in this project were spatially distributed and were connected together using arbitrary topologies.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
3. The SGI Origin: A ccnuma Highly Scalable Server&lt;br /&gt;
 Laudon, J.; Lenoski, D.;&lt;br /&gt;
 Computer Architecture, 1997. Conference Proceedings. The 24th Annual International Symposium on&lt;br /&gt;
 June 2-4, 1997 Page(s):241 - 251 &lt;br /&gt;
&lt;br /&gt;
4. The Scalable Coherence Interface&lt;br /&gt;
 David.B.Gustavson&lt;br /&gt;
 September 1991&lt;br /&gt;
 &amp;quot;The Scalable Coherence Interface and related standard projects&amp;quot;&lt;br /&gt;
&lt;br /&gt;
5. An analysis of the Scalable Coherent Interface&lt;br /&gt;
 Eric Rotenberg&lt;br /&gt;
 June 1995&lt;br /&gt;
 An Analytical model of the SCI Coherence protocol&lt;br /&gt;
&lt;br /&gt;
6. Interfaces and Standards : SCI&lt;br /&gt;
 Behrooz. Parhami&lt;br /&gt;
 1999&lt;br /&gt;
 Introduction to Parallel Processing: Algorithms and Architectures&lt;br /&gt;
&lt;br /&gt;
7. SCI: Scalable Coherent Interface&lt;br /&gt;
 Hermann Hellwagner&lt;br /&gt;
 1999&lt;br /&gt;
 SCI: Scalable Coherent Interface - Architecture and software for high-performance Compute Clusters&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
1. The Stanford Dash multiprocessor&lt;br /&gt;
 Lenoski, D.; Laudon, J.; Gharachorloo, K.; Weber, W.-D.; Gupta, A.; Hennessy, J.; Horowitz, M.; Lam, M.S.;&lt;br /&gt;
 Computer&lt;br /&gt;
 IEEE Volume 25,  Issue 3,  March 1992 Page(s):63 - 79&lt;br /&gt;
 Digital Object Identifier 10.1109/2.121510&lt;br /&gt;
&lt;br /&gt;
2. SCI: Scalable Coherent Interface&lt;br /&gt;
 Hermann Hellwagner&lt;br /&gt;
 1999&lt;br /&gt;
 SCI: Scalable Coherent Interface - Architecture and software for high-performance Compute Clusters&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_2_1r&amp;diff=6096</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 2 1r</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_2_1r&amp;diff=6096"/>
		<updated>2007-10-20T03:27:46Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* 3. SGI Origin 2000 */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
In parallel systems, data can be obtained from a variety of sources, which includes local or remote memory modules, secondary storage devices and network interfaces. It would be beneficial if certain aspects of mechanisms that are required to gain access to data are standardized such that it allows easily expandable and flexible designs. Various portions of a parallel system may be modified or even upgraded without any effect on the rest of the design if the system adheres to such standards. Also, utilization of standard interfaces forwards the integration of components and subsystems from several different vendors into efficient and usable parallel systems. The Scalable Coherent Interface is one such standard which facilitates the implementation of large-scale cache-coherent parallel systems.&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
===Goals of SCI===&lt;br /&gt;
&lt;br /&gt;
*High Performance – For distributed or parallel applications, high communication performance must be obtained when using SCI. Usual aspects of such performance would be a low latency, low CPU overhead for operations dealing with communication and high sustained throughput.&lt;br /&gt;
&lt;br /&gt;
*Scalability – This is addressed in many ways. Some are&lt;br /&gt;
**Performance scalability – as the number of nodes being added to the system increases.&lt;br /&gt;
**Interconnect Distance scalability&lt;br /&gt;
**Memory System scalability – chiefly of cache coherence protocols, which should not have limitations to the number of processors or modules in memory that it can handle.&lt;br /&gt;
**Technological scalability – utilization of similar mechanisms in large, small-scale, loosely-coupled or tightly-coupled systems. Also, when new advances are made in technology, it must have the ability to readily make use of such advances.&lt;br /&gt;
**Economic scalability – use of similar components and mechanisms in high-end, low-volume systems as well as low-end, high-volume systems.&lt;br /&gt;
**Addressing capability has no short term practical limits.&lt;br /&gt;
&lt;br /&gt;
*Coherent Memory System – For the purpose of reduction of Average Access Time to data, caches are becoming more important each day for microprocessors.&lt;br /&gt;
&lt;br /&gt;
*Interface Characteristics – This specifies a standard interface to an interconnect that makes several devices to be connected or attached together and to interoperate.&lt;br /&gt;
&lt;br /&gt;
===Operation===&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Performance &amp;amp; Correctness (Coherence &amp;amp; Consistency) requirement for the protocol necessitates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
=== Need for Busy state ===&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
In Origin, there are 3 busy states indicates that the directory has received the request but is waiting for completion hence another request for the same block won't be accepted.&lt;br /&gt;
# Busy read&lt;br /&gt;
# Busy read exclusive or upgrade&lt;br /&gt;
# Busy uncached read:  In case of DMA, if the memory block is being read, no other processor should be allowed to get write access to it.&lt;br /&gt;
&lt;br /&gt;
=== Poison state ===&lt;br /&gt;
&lt;br /&gt;
To improve locality, origin relies on page migration. Hardware keeps reference counts on each page. On every access of memory count is incremented and compared with home node. If count is more than programmable threshold, hardware interrupts one of the local processors to copy the page. Block transfer engine “poison” the source page. Subsequent accesses by other processors receive a bus error and that removes the TLB entry for that location, read the location from the page table &amp;amp; update the TLB with new location. This approach is called - “Lazy TLB shootdown” which reduces the overall cost of migrating memory and changing the virtual-to-physical address mappings.&lt;br /&gt;
&lt;br /&gt;
=== Additional states ===&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
*The “fresh” state shows that memory still has an up-to-date copy of the block, even if the block        has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
*The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== 1. DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
=== 2. SCI-based CC-NUMA machines ===&lt;br /&gt;
&lt;br /&gt;
SCI is attached to the memory bus of a node. Here, SCI can take part in and &amp;quot;export&amp;quot; cache coherence and memory traffic on the bus and make the memory of the node visible to other nodes. Each node's memory address range can be scaled to span a global address space, giving coherent and transparent access to anywhere in the system to requesting processors. This method is used to form a large-scale cache-coherent shared-memory system, known as a CC-NUMA machine.&lt;br /&gt;
&lt;br /&gt;
=== 3. SGI Origin 2000 ===&lt;br /&gt;
&lt;br /&gt;
This would seem to be the only commercial alternative to CC-Numa machines. The Origin 2000 is an advanced version of the SCI-based CC-NUMA machines but has its origins in the Stanford DASH project. Cache coherence is maintained here with a bit-vector directory scheme.&lt;br /&gt;
&lt;br /&gt;
=== 4. S3.mp ===&lt;br /&gt;
&lt;br /&gt;
This was a project by SUN to connect off-the-shelf workstations and make this interconnection into a large-scale cache-coherent multiprocessor. This has an invalidation based protocol which notes the nodes that ahre a memory block and stores such information in linked lists. The nodes in this project were spatially distributed and were connected together using arbitrary topologies.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
3. The SGI Origin: A ccnuma Highly Scalable Server&lt;br /&gt;
 Laudon, J.; Lenoski, D.;&lt;br /&gt;
 Computer Architecture, 1997. Conference Proceedings. The 24th Annual International Symposium on&lt;br /&gt;
 June 2-4, 1997 Page(s):241 - 251 &lt;br /&gt;
&lt;br /&gt;
4. The Scalable Coherence Interface&lt;br /&gt;
 David.B.Gustavson&lt;br /&gt;
 September 1991&lt;br /&gt;
 &amp;quot;The Scalable Coherence Interface and related standard projects&amp;quot;&lt;br /&gt;
&lt;br /&gt;
5. An analysis of the Scalable Coherent Interface&lt;br /&gt;
 Eric Rotenberg&lt;br /&gt;
 June 1995&lt;br /&gt;
 An Analytical model of the SCI Coherence protocol&lt;br /&gt;
&lt;br /&gt;
6. Interfaces and Standards : SCI&lt;br /&gt;
 Behrooz. Parhami&lt;br /&gt;
 1999&lt;br /&gt;
 Introduction to Parallel Processing: Algorithms and Architectures&lt;br /&gt;
&lt;br /&gt;
7. SCI: Scalable Coherent Interface&lt;br /&gt;
 Hermann Hellwagner&lt;br /&gt;
 1999&lt;br /&gt;
 SCI: Scalable Coherent Interface - Architecture and software for high-performance Compute Clusters&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
1. The Stanford Dash multiprocessor&lt;br /&gt;
 Lenoski, D.; Laudon, J.; Gharachorloo, K.; Weber, W.-D.; Gupta, A.; Hennessy, J.; Horowitz, M.; Lam, M.S.;&lt;br /&gt;
 Computer&lt;br /&gt;
 IEEE Volume 25,  Issue 3,  March 1992 Page(s):63 - 79&lt;br /&gt;
 Digital Object Identifier 10.1109/2.121510&lt;br /&gt;
&lt;br /&gt;
2. SCI: Scalable Coherent Interface&lt;br /&gt;
 Hermann Hellwagner&lt;br /&gt;
 1999&lt;br /&gt;
 SCI: Scalable Coherent Interface - Architecture and software for high-performance Compute Clusters&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_2_1r&amp;diff=6094</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 2 1r</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_2_1r&amp;diff=6094"/>
		<updated>2007-10-20T03:27:04Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* Examples */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
In parallel systems, data can be obtained from a variety of sources, which includes local or remote memory modules, secondary storage devices and network interfaces. It would be beneficial if certain aspects of mechanisms that are required to gain access to data are standardized such that it allows easily expandable and flexible designs. Various portions of a parallel system may be modified or even upgraded without any effect on the rest of the design if the system adheres to such standards. Also, utilization of standard interfaces forwards the integration of components and subsystems from several different vendors into efficient and usable parallel systems. The Scalable Coherent Interface is one such standard which facilitates the implementation of large-scale cache-coherent parallel systems.&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
===Goals of SCI===&lt;br /&gt;
&lt;br /&gt;
*High Performance – For distributed or parallel applications, high communication performance must be obtained when using SCI. Usual aspects of such performance would be a low latency, low CPU overhead for operations dealing with communication and high sustained throughput.&lt;br /&gt;
&lt;br /&gt;
*Scalability – This is addressed in many ways. Some are&lt;br /&gt;
**Performance scalability – as the number of nodes being added to the system increases.&lt;br /&gt;
**Interconnect Distance scalability&lt;br /&gt;
**Memory System scalability – chiefly of cache coherence protocols, which should not have limitations to the number of processors or modules in memory that it can handle.&lt;br /&gt;
**Technological scalability – utilization of similar mechanisms in large, small-scale, loosely-coupled or tightly-coupled systems. Also, when new advances are made in technology, it must have the ability to readily make use of such advances.&lt;br /&gt;
**Economic scalability – use of similar components and mechanisms in high-end, low-volume systems as well as low-end, high-volume systems.&lt;br /&gt;
**Addressing capability has no short term practical limits.&lt;br /&gt;
&lt;br /&gt;
*Coherent Memory System – For the purpose of reduction of Average Access Time to data, caches are becoming more important each day for microprocessors.&lt;br /&gt;
&lt;br /&gt;
*Interface Characteristics – This specifies a standard interface to an interconnect that makes several devices to be connected or attached together and to interoperate.&lt;br /&gt;
&lt;br /&gt;
===Operation===&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Performance &amp;amp; Correctness (Coherence &amp;amp; Consistency) requirement for the protocol necessitates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
=== Need for Busy state ===&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
In Origin, there are 3 busy states indicates that the directory has received the request but is waiting for completion hence another request for the same block won't be accepted.&lt;br /&gt;
# Busy read&lt;br /&gt;
# Busy read exclusive or upgrade&lt;br /&gt;
# Busy uncached read:  In case of DMA, if the memory block is being read, no other processor should be allowed to get write access to it.&lt;br /&gt;
&lt;br /&gt;
=== Poison state ===&lt;br /&gt;
&lt;br /&gt;
To improve locality, origin relies on page migration. Hardware keeps reference counts on each page. On every access of memory count is incremented and compared with home node. If count is more than programmable threshold, hardware interrupts one of the local processors to copy the page. Block transfer engine “poison” the source page. Subsequent accesses by other processors receive a bus error and that removes the TLB entry for that location, read the location from the page table &amp;amp; update the TLB with new location. This approach is called - “Lazy TLB shootdown” which reduces the overall cost of migrating memory and changing the virtual-to-physical address mappings.&lt;br /&gt;
&lt;br /&gt;
=== Additional states ===&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
*The “fresh” state shows that memory still has an up-to-date copy of the block, even if the block        has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
*The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== 1. DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
=== 2. SCI-based CC-NUMA machines ===&lt;br /&gt;
&lt;br /&gt;
SCI is attached to the memory bus of a node. Here, SCI can take part in and &amp;quot;export&amp;quot; cache coherence and memory traffic on the bus and make the memory of the node visible to other nodes. Each node's memory address range can be scaled to span a global address space, giving coherent and transparent access to anywhere in the system to requesting processors. This method is used to form a large-scale cache-coherent shared-memory system, known as a CC-NUMA machine.&lt;br /&gt;
&lt;br /&gt;
=== 3. SGI Origin 2000 ===&lt;br /&gt;
&lt;br /&gt;
This would seem to be the only commercial alternative to CC-Numa machines. The Origin 2000 is an advanced version of the SCI-ased CC-NUMA machines but has its origins in the Stanford DASH project. Cache coherence is maintained here with a bit-vector directory scheme.&lt;br /&gt;
&lt;br /&gt;
=== 4. S3.mp ===&lt;br /&gt;
&lt;br /&gt;
This was a project by SUN to connect off-the-shelf workstations and make this interconnection into a large-scale cache-coherent multiprocessor. This has an invalidation based protocol which notes the nodes that ahre a memory block and stores such information in linked lists. The nodes in this project were spatially distributed and were connected together using arbitrary topologies.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
3. The SGI Origin: A ccnuma Highly Scalable Server&lt;br /&gt;
 Laudon, J.; Lenoski, D.;&lt;br /&gt;
 Computer Architecture, 1997. Conference Proceedings. The 24th Annual International Symposium on&lt;br /&gt;
 June 2-4, 1997 Page(s):241 - 251 &lt;br /&gt;
&lt;br /&gt;
4. The Scalable Coherence Interface&lt;br /&gt;
 David.B.Gustavson&lt;br /&gt;
 September 1991&lt;br /&gt;
 &amp;quot;The Scalable Coherence Interface and related standard projects&amp;quot;&lt;br /&gt;
&lt;br /&gt;
5. An analysis of the Scalable Coherent Interface&lt;br /&gt;
 Eric Rotenberg&lt;br /&gt;
 June 1995&lt;br /&gt;
 An Analytical model of the SCI Coherence protocol&lt;br /&gt;
&lt;br /&gt;
6. Interfaces and Standards : SCI&lt;br /&gt;
 Behrooz. Parhami&lt;br /&gt;
 1999&lt;br /&gt;
 Introduction to Parallel Processing: Algorithms and Architectures&lt;br /&gt;
&lt;br /&gt;
7. SCI: Scalable Coherent Interface&lt;br /&gt;
 Hermann Hellwagner&lt;br /&gt;
 1999&lt;br /&gt;
 SCI: Scalable Coherent Interface - Architecture and software for high-performance Compute Clusters&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
1. The Stanford Dash multiprocessor&lt;br /&gt;
 Lenoski, D.; Laudon, J.; Gharachorloo, K.; Weber, W.-D.; Gupta, A.; Hennessy, J.; Horowitz, M.; Lam, M.S.;&lt;br /&gt;
 Computer&lt;br /&gt;
 IEEE Volume 25,  Issue 3,  March 1992 Page(s):63 - 79&lt;br /&gt;
 Digital Object Identifier 10.1109/2.121510&lt;br /&gt;
&lt;br /&gt;
2. SCI: Scalable Coherent Interface&lt;br /&gt;
 Hermann Hellwagner&lt;br /&gt;
 1999&lt;br /&gt;
 SCI: Scalable Coherent Interface - Architecture and software for high-performance Compute Clusters&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_2_1r&amp;diff=6080</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 2 1r</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_2_1r&amp;diff=6080"/>
		<updated>2007-10-20T03:16:51Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* 1 DASH Cache Coherence Protocol */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
In parallel systems, data can be obtained from a variety of sources, which includes local or remote memory modules, secondary storage devices and network interfaces. It would be beneficial if certain aspects of mechanisms that are required to gain access to data are standardized such that it allows easily expandable and flexible designs. Various portions of a parallel system may be modified or even upgraded without any effect on the rest of the design if the system adheres to such standards. Also, utilization of standard interfaces forwards the integration of components and subsystems from several different vendors into efficient and usable parallel systems. The Scalable Coherent Interface is one such standard which facilitates the implementation of large-scale cache-coherent parallel systems.&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
===Goals of SCI===&lt;br /&gt;
&lt;br /&gt;
*High Performance – For distributed or parallel applications, high communication performance must be obtained when using SCI. Usual aspects of such performance would be a low latency, low CPU overhead for operations dealing with communication and high sustained throughput.&lt;br /&gt;
&lt;br /&gt;
*Scalability – This is addressed in many ways. Some are&lt;br /&gt;
**Performance scalability – as the number of nodes being added to the system increases.&lt;br /&gt;
**Interconnect Distance scalability&lt;br /&gt;
**Memory System scalability – chiefly of cache coherence protocols, which should not have limitations to the number of processors or modules in memory that it can handle.&lt;br /&gt;
**Technological scalability – utilization of similar mechanisms in large, small-scale, loosely-coupled or tightly-coupled systems. Also, when new advances are made in technology, it must have the ability to readily make use of such advances.&lt;br /&gt;
**Economic scalability – use of similar components and mechanisms in high-end, low-volume systems as well as low-end, high-volume systems.&lt;br /&gt;
**Addressing capability has no short term practical limits.&lt;br /&gt;
&lt;br /&gt;
*Coherent Memory System – For the purpose of reduction of Average Access Time to data, caches are becoming more important each day for microprocessors.&lt;br /&gt;
&lt;br /&gt;
*Interface Characteristics – This specifies a standard interface to an interconnect that makes several devices to be connected or attached together and to interoperate.&lt;br /&gt;
&lt;br /&gt;
===Operation===&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Performance &amp;amp; Correctness (Coherence &amp;amp; Consistency) requirement for the protocol necessitates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
=== Need for Busy state ===&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
In Origin, there are 3 busy states indicates that the directory has received the request but is waiting for completion hence another request for the same block won't be accepted.&lt;br /&gt;
# Busy read&lt;br /&gt;
# Busy read exclusive or upgrade&lt;br /&gt;
# Busy uncached read:  In case of DMA, if the memory block is being read, no other processor should be allowed to get write access to it.&lt;br /&gt;
&lt;br /&gt;
=== Poison state ===&lt;br /&gt;
&lt;br /&gt;
To improve locality, origin relies on page migration. Hardware keeps reference counts on each page. On every access of memory count is incremented and compared with home node. If count is more than programmable threshold, hardware interrupts one of the local processors to copy the page. Block transfer engine “poison” the source page. Subsequent accesses by other processors receive a bus error and that removes the TLB entry for that location, read the location from the page table &amp;amp; update the TLB with new location. This approach is called - “Lazy TLB shootdown” which reduces the overall cost of migrating memory and changing the virtual-to-physical address mappings.&lt;br /&gt;
&lt;br /&gt;
=== Additional states ===&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
*The “fresh” state shows that memory still has an up-to-date copy of the block, even if the block        has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
*The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== 1. DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
=== 2. SCI-based CC-NUMA machines ===&lt;br /&gt;
&lt;br /&gt;
SCI is attached to the memory bus of a node. Here, SCI can take part in and &amp;quot;export&amp;quot; cache coherence and memory traffic on the bus and make the memory of the node visible to other nodes. Each node's memory address range can be scaled to span a global address space, giving coherent and transparent access to anywhere in the system to requesting processors. This method is used to form a large-scale cache-coherent shared-memory system, known as a CC-NUMA machine.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
3. The SGI Origin: A ccnuma Highly Scalable Server&lt;br /&gt;
 Laudon, J.; Lenoski, D.;&lt;br /&gt;
 Computer Architecture, 1997. Conference Proceedings. The 24th Annual International Symposium on&lt;br /&gt;
 June 2-4, 1997 Page(s):241 - 251 &lt;br /&gt;
&lt;br /&gt;
4. The Scalable Coherence Interface&lt;br /&gt;
 David.B.Gustavson&lt;br /&gt;
 September 1991&lt;br /&gt;
 &amp;quot;The Scalable Coherence Interface and related standard projects&amp;quot;&lt;br /&gt;
&lt;br /&gt;
5. An analysis of the Scalable Coherent Interface&lt;br /&gt;
 Eric Rotenberg&lt;br /&gt;
 June 1995&lt;br /&gt;
 An Analytical model of the SCI Coherence protocol&lt;br /&gt;
&lt;br /&gt;
6. Interfaces and Standards : SCI&lt;br /&gt;
 Behrooz. Parhami&lt;br /&gt;
 1999&lt;br /&gt;
 Introduction to Parallel Processing: Algorithms and Architectures&lt;br /&gt;
&lt;br /&gt;
7. SCI: Scalable Coherent Interface&lt;br /&gt;
 Hermann Hellwagner&lt;br /&gt;
 1999&lt;br /&gt;
 SCI: Scalable Coherent Interface - Architecture and software for high-performance Compute Clusters&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
1. The Stanford Dash multiprocessor&lt;br /&gt;
 Lenoski, D.; Laudon, J.; Gharachorloo, K.; Weber, W.-D.; Gupta, A.; Hennessy, J.; Horowitz, M.; Lam, M.S.;&lt;br /&gt;
 Computer&lt;br /&gt;
 IEEE Volume 25,  Issue 3,  March 1992 Page(s):63 - 79&lt;br /&gt;
 Digital Object Identifier 10.1109/2.121510&lt;br /&gt;
&lt;br /&gt;
2. SCI: Scalable Coherent Interface&lt;br /&gt;
 Hermann Hellwagner&lt;br /&gt;
 1999&lt;br /&gt;
 SCI: Scalable Coherent Interface - Architecture and software for high-performance Compute Clusters&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_2_1r&amp;diff=6078</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 2 1r</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_2_1r&amp;diff=6078"/>
		<updated>2007-10-20T03:16:22Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* SCI-based CC-NUMA machines */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
In parallel systems, data can be obtained from a variety of sources, which includes local or remote memory modules, secondary storage devices and network interfaces. It would be beneficial if certain aspects of mechanisms that are required to gain access to data are standardized such that it allows easily expandable and flexible designs. Various portions of a parallel system may be modified or even upgraded without any effect on the rest of the design if the system adheres to such standards. Also, utilization of standard interfaces forwards the integration of components and subsystems from several different vendors into efficient and usable parallel systems. The Scalable Coherent Interface is one such standard which facilitates the implementation of large-scale cache-coherent parallel systems.&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
===Goals of SCI===&lt;br /&gt;
&lt;br /&gt;
*High Performance – For distributed or parallel applications, high communication performance must be obtained when using SCI. Usual aspects of such performance would be a low latency, low CPU overhead for operations dealing with communication and high sustained throughput.&lt;br /&gt;
&lt;br /&gt;
*Scalability – This is addressed in many ways. Some are&lt;br /&gt;
**Performance scalability – as the number of nodes being added to the system increases.&lt;br /&gt;
**Interconnect Distance scalability&lt;br /&gt;
**Memory System scalability – chiefly of cache coherence protocols, which should not have limitations to the number of processors or modules in memory that it can handle.&lt;br /&gt;
**Technological scalability – utilization of similar mechanisms in large, small-scale, loosely-coupled or tightly-coupled systems. Also, when new advances are made in technology, it must have the ability to readily make use of such advances.&lt;br /&gt;
**Economic scalability – use of similar components and mechanisms in high-end, low-volume systems as well as low-end, high-volume systems.&lt;br /&gt;
**Addressing capability has no short term practical limits.&lt;br /&gt;
&lt;br /&gt;
*Coherent Memory System – For the purpose of reduction of Average Access Time to data, caches are becoming more important each day for microprocessors.&lt;br /&gt;
&lt;br /&gt;
*Interface Characteristics – This specifies a standard interface to an interconnect that makes several devices to be connected or attached together and to interoperate.&lt;br /&gt;
&lt;br /&gt;
===Operation===&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Performance &amp;amp; Correctness (Coherence &amp;amp; Consistency) requirement for the protocol necessitates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
=== Need for Busy state ===&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
In Origin, there are 3 busy states indicates that the directory has received the request but is waiting for completion hence another request for the same block won't be accepted.&lt;br /&gt;
# Busy read&lt;br /&gt;
# Busy read exclusive or upgrade&lt;br /&gt;
# Busy uncached read:  In case of DMA, if the memory block is being read, no other processor should be allowed to get write access to it.&lt;br /&gt;
&lt;br /&gt;
=== Poison state ===&lt;br /&gt;
&lt;br /&gt;
To improve locality, origin relies on page migration. Hardware keeps reference counts on each page. On every access of memory count is incremented and compared with home node. If count is more than programmable threshold, hardware interrupts one of the local processors to copy the page. Block transfer engine “poison” the source page. Subsequent accesses by other processors receive a bus error and that removes the TLB entry for that location, read the location from the page table &amp;amp; update the TLB with new location. This approach is called - “Lazy TLB shootdown” which reduces the overall cost of migrating memory and changing the virtual-to-physical address mappings.&lt;br /&gt;
&lt;br /&gt;
=== Additional states ===&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
*The “fresh” state shows that memory still has an up-to-date copy of the block, even if the block        has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
*The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== 1 DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
=== 2. SCI-based CC-NUMA machines ===&lt;br /&gt;
&lt;br /&gt;
SCI is attached to the memory bus of a node. Here, SCI can take part in and &amp;quot;export&amp;quot; cache coherence and memory traffic on the bus and make the memory of the node visible to other nodes. Each node's memory address range can be scaled to span a global address space, giving coherent and transparent access to anywhere in the system to requesting processors. This method is used to form a large-scale cache-coherent shared-memory system, known as a CC-NUMA machine.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
3. The SGI Origin: A ccnuma Highly Scalable Server&lt;br /&gt;
 Laudon, J.; Lenoski, D.;&lt;br /&gt;
 Computer Architecture, 1997. Conference Proceedings. The 24th Annual International Symposium on&lt;br /&gt;
 June 2-4, 1997 Page(s):241 - 251 &lt;br /&gt;
&lt;br /&gt;
4. The Scalable Coherence Interface&lt;br /&gt;
 David.B.Gustavson&lt;br /&gt;
 September 1991&lt;br /&gt;
 &amp;quot;The Scalable Coherence Interface and related standard projects&amp;quot;&lt;br /&gt;
&lt;br /&gt;
5. An analysis of the Scalable Coherent Interface&lt;br /&gt;
 Eric Rotenberg&lt;br /&gt;
 June 1995&lt;br /&gt;
 An Analytical model of the SCI Coherence protocol&lt;br /&gt;
&lt;br /&gt;
6. Interfaces and Standards : SCI&lt;br /&gt;
 Behrooz. Parhami&lt;br /&gt;
 1999&lt;br /&gt;
 Introduction to Parallel Processing: Algorithms and Architectures&lt;br /&gt;
&lt;br /&gt;
7. SCI: Scalable Coherent Interface&lt;br /&gt;
 Hermann Hellwagner&lt;br /&gt;
 1999&lt;br /&gt;
 SCI: Scalable Coherent Interface - Architecture and software for high-performance Compute Clusters&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
1. The Stanford Dash multiprocessor&lt;br /&gt;
 Lenoski, D.; Laudon, J.; Gharachorloo, K.; Weber, W.-D.; Gupta, A.; Hennessy, J.; Horowitz, M.; Lam, M.S.;&lt;br /&gt;
 Computer&lt;br /&gt;
 IEEE Volume 25,  Issue 3,  March 1992 Page(s):63 - 79&lt;br /&gt;
 Digital Object Identifier 10.1109/2.121510&lt;br /&gt;
&lt;br /&gt;
2. SCI: Scalable Coherent Interface&lt;br /&gt;
 Hermann Hellwagner&lt;br /&gt;
 1999&lt;br /&gt;
 SCI: Scalable Coherent Interface - Architecture and software for high-performance Compute Clusters&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_2_1r&amp;diff=6076</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 2 1r</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_2_1r&amp;diff=6076"/>
		<updated>2007-10-20T03:16:05Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* Examples */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
In parallel systems, data can be obtained from a variety of sources, which includes local or remote memory modules, secondary storage devices and network interfaces. It would be beneficial if certain aspects of mechanisms that are required to gain access to data are standardized such that it allows easily expandable and flexible designs. Various portions of a parallel system may be modified or even upgraded without any effect on the rest of the design if the system adheres to such standards. Also, utilization of standard interfaces forwards the integration of components and subsystems from several different vendors into efficient and usable parallel systems. The Scalable Coherent Interface is one such standard which facilitates the implementation of large-scale cache-coherent parallel systems.&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
===Goals of SCI===&lt;br /&gt;
&lt;br /&gt;
*High Performance – For distributed or parallel applications, high communication performance must be obtained when using SCI. Usual aspects of such performance would be a low latency, low CPU overhead for operations dealing with communication and high sustained throughput.&lt;br /&gt;
&lt;br /&gt;
*Scalability – This is addressed in many ways. Some are&lt;br /&gt;
**Performance scalability – as the number of nodes being added to the system increases.&lt;br /&gt;
**Interconnect Distance scalability&lt;br /&gt;
**Memory System scalability – chiefly of cache coherence protocols, which should not have limitations to the number of processors or modules in memory that it can handle.&lt;br /&gt;
**Technological scalability – utilization of similar mechanisms in large, small-scale, loosely-coupled or tightly-coupled systems. Also, when new advances are made in technology, it must have the ability to readily make use of such advances.&lt;br /&gt;
**Economic scalability – use of similar components and mechanisms in high-end, low-volume systems as well as low-end, high-volume systems.&lt;br /&gt;
**Addressing capability has no short term practical limits.&lt;br /&gt;
&lt;br /&gt;
*Coherent Memory System – For the purpose of reduction of Average Access Time to data, caches are becoming more important each day for microprocessors.&lt;br /&gt;
&lt;br /&gt;
*Interface Characteristics – This specifies a standard interface to an interconnect that makes several devices to be connected or attached together and to interoperate.&lt;br /&gt;
&lt;br /&gt;
===Operation===&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Performance &amp;amp; Correctness (Coherence &amp;amp; Consistency) requirement for the protocol necessitates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
=== Need for Busy state ===&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
In Origin, there are 3 busy states indicates that the directory has received the request but is waiting for completion hence another request for the same block won't be accepted.&lt;br /&gt;
# Busy read&lt;br /&gt;
# Busy read exclusive or upgrade&lt;br /&gt;
# Busy uncached read:  In case of DMA, if the memory block is being read, no other processor should be allowed to get write access to it.&lt;br /&gt;
&lt;br /&gt;
=== Poison state ===&lt;br /&gt;
&lt;br /&gt;
To improve locality, origin relies on page migration. Hardware keeps reference counts on each page. On every access of memory count is incremented and compared with home node. If count is more than programmable threshold, hardware interrupts one of the local processors to copy the page. Block transfer engine “poison” the source page. Subsequent accesses by other processors receive a bus error and that removes the TLB entry for that location, read the location from the page table &amp;amp; update the TLB with new location. This approach is called - “Lazy TLB shootdown” which reduces the overall cost of migrating memory and changing the virtual-to-physical address mappings.&lt;br /&gt;
&lt;br /&gt;
=== Additional states ===&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
*The “fresh” state shows that memory still has an up-to-date copy of the block, even if the block        has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
*The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== 1 DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
=== SCI-based CC-NUMA machines ===&lt;br /&gt;
&lt;br /&gt;
SCI is attached to the memory bus of a node. Here, SCI can take part in and &amp;quot;export&amp;quot; cache coherence and memory traffic on the bus and make the memory of the node visible to other nodes. Each node's memory address range can be scaled to span a global address space, giving coherent and transparent access to anywhere in the system to requesting processors. This method is used to form a large-scale cache-coherent shared-memory system, known as a CC-NUMA machine.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
3. The SGI Origin: A ccnuma Highly Scalable Server&lt;br /&gt;
 Laudon, J.; Lenoski, D.;&lt;br /&gt;
 Computer Architecture, 1997. Conference Proceedings. The 24th Annual International Symposium on&lt;br /&gt;
 June 2-4, 1997 Page(s):241 - 251 &lt;br /&gt;
&lt;br /&gt;
4. The Scalable Coherence Interface&lt;br /&gt;
 David.B.Gustavson&lt;br /&gt;
 September 1991&lt;br /&gt;
 &amp;quot;The Scalable Coherence Interface and related standard projects&amp;quot;&lt;br /&gt;
&lt;br /&gt;
5. An analysis of the Scalable Coherent Interface&lt;br /&gt;
 Eric Rotenberg&lt;br /&gt;
 June 1995&lt;br /&gt;
 An Analytical model of the SCI Coherence protocol&lt;br /&gt;
&lt;br /&gt;
6. Interfaces and Standards : SCI&lt;br /&gt;
 Behrooz. Parhami&lt;br /&gt;
 1999&lt;br /&gt;
 Introduction to Parallel Processing: Algorithms and Architectures&lt;br /&gt;
&lt;br /&gt;
7. SCI: Scalable Coherent Interface&lt;br /&gt;
 Hermann Hellwagner&lt;br /&gt;
 1999&lt;br /&gt;
 SCI: Scalable Coherent Interface - Architecture and software for high-performance Compute Clusters&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
1. The Stanford Dash multiprocessor&lt;br /&gt;
 Lenoski, D.; Laudon, J.; Gharachorloo, K.; Weber, W.-D.; Gupta, A.; Hennessy, J.; Horowitz, M.; Lam, M.S.;&lt;br /&gt;
 Computer&lt;br /&gt;
 IEEE Volume 25,  Issue 3,  March 1992 Page(s):63 - 79&lt;br /&gt;
 Digital Object Identifier 10.1109/2.121510&lt;br /&gt;
&lt;br /&gt;
2. SCI: Scalable Coherent Interface&lt;br /&gt;
 Hermann Hellwagner&lt;br /&gt;
 1999&lt;br /&gt;
 SCI: Scalable Coherent Interface - Architecture and software for high-performance Compute Clusters&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_2_1r&amp;diff=6070</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 2 1r</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_2_1r&amp;diff=6070"/>
		<updated>2007-10-20T01:15:51Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* Further reading */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
In parallel systems, data can be obtained from a variety of sources, which includes local or remote memory modules, secondary storage devices and network interfaces. It would be beneficial if certain aspects of mechanisms that are required to gain access to data are standardized such that it allows easily expandable and flexible designs. Various portions of a parallel system may be modified or even upgraded without any effect on the rest of the design if the system adheres to such standards. Also, utilization of standard interfaces forwards the integration of components and subsystems from several different vendors into efficient and usable parallel systems. The Scalable Coherent Interface is one such standard which facilitates the implementation of large-scale cache-coherent parallel systems.&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
===Goals of SCI===&lt;br /&gt;
&lt;br /&gt;
*High Performance – For distributed or parallel applications, high communication performance must be obtained when using SCI. Usual aspects of such performance would be a low latency, low CPU overhead for operations dealing with communication and high sustained throughput.&lt;br /&gt;
&lt;br /&gt;
*Scalability – This is addressed in many ways. Some are&lt;br /&gt;
**Performance scalability – as the number of nodes being added to the system increases.&lt;br /&gt;
**Interconnect Distance scalability&lt;br /&gt;
**Memory System scalability – chiefly of cache coherence protocols, which should not have limitations to the number of processors or modules in memory that it can handle.&lt;br /&gt;
**Technological scalability – utilization of similar mechanisms in large, small-scale, loosely-coupled or tightly-coupled systems. Also, when new advances are made in technology, it must have the ability to readily make use of such advances.&lt;br /&gt;
**Economic scalability – use of similar components and mechanisms in high-end, low-volume systems as well as low-end, high-volume systems.&lt;br /&gt;
**Addressing capability has no short term practical limits.&lt;br /&gt;
&lt;br /&gt;
*Coherent Memory System – For the purpose of reduction of Average Access Time to data, caches are becoming more important each day for microprocessors.&lt;br /&gt;
&lt;br /&gt;
*Interface Characteristics – This specifies a standard interface to an interconnect that makes several devices to be connected or attached together and to interoperate.&lt;br /&gt;
&lt;br /&gt;
===Operation===&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Performance &amp;amp; Correctness (Coherence &amp;amp; Consistency) requirement for the protocol necessitates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
=== Need for Busy state ===&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
In Origin, there are 3 busy states indicates that the directory has received the request but is waiting for completion hence another request for the same block won't be accepted.&lt;br /&gt;
# Busy read&lt;br /&gt;
# Busy read exclusive or upgrade&lt;br /&gt;
# Busy uncached read:  In case of DMA, if the memory block is being read, no other processor should be allowed to get write access to it.&lt;br /&gt;
&lt;br /&gt;
=== Poison state ===&lt;br /&gt;
&lt;br /&gt;
To improve locality, origin relies on page migration. Hardware keeps reference counts on each page. On every access of memory count is incremented and compared with home node. If count is more than programmable threshold, hardware interrupts one of the local processors to copy the page. Block transfer engine “poison” the source page. Subsequent accesses by other processors receive a bus error and that removes the TLB entry for that location, read the location from the page table &amp;amp; update the TLB with new location. This approach is called - “Lazy TLB shootdown” which reduces the overall cost of migrating memory and changing the virtual-to-physical address mappings.&lt;br /&gt;
&lt;br /&gt;
=== Additional states ===&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
*The “fresh” state shows that memory still has an up-to-date copy of the block, even if the block        has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
*The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== 1 DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
3. The SGI Origin: A ccnuma Highly Scalable Server&lt;br /&gt;
 Laudon, J.; Lenoski, D.;&lt;br /&gt;
 Computer Architecture, 1997. Conference Proceedings. The 24th Annual International Symposium on&lt;br /&gt;
 June 2-4, 1997 Page(s):241 - 251 &lt;br /&gt;
&lt;br /&gt;
4. The Scalable Coherence Interface&lt;br /&gt;
 David.B.Gustavson&lt;br /&gt;
 September 1991&lt;br /&gt;
 &amp;quot;The Scalable Coherence Interface and related standard projects&amp;quot;&lt;br /&gt;
&lt;br /&gt;
5. An analysis of the Scalable Coherent Interface&lt;br /&gt;
 Eric Rotenberg&lt;br /&gt;
 June 1995&lt;br /&gt;
 An Analytical model of the SCI Coherence protocol&lt;br /&gt;
&lt;br /&gt;
6. Interfaces and Standards : SCI&lt;br /&gt;
 Behrooz. Parhami&lt;br /&gt;
 1999&lt;br /&gt;
 Introduction to Parallel Processing: Algorithms and Architectures&lt;br /&gt;
&lt;br /&gt;
7. SCI: Scalable Coherent Interface&lt;br /&gt;
 Hermann Hellwagner&lt;br /&gt;
 1999&lt;br /&gt;
 SCI: Scalable Coherent Interface - Architecture and software for high-performance Compute Clusters&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
1. The Stanford Dash multiprocessor&lt;br /&gt;
 Lenoski, D.; Laudon, J.; Gharachorloo, K.; Weber, W.-D.; Gupta, A.; Hennessy, J.; Horowitz, M.; Lam, M.S.;&lt;br /&gt;
 Computer&lt;br /&gt;
 IEEE Volume 25,  Issue 3,  March 1992 Page(s):63 - 79&lt;br /&gt;
 Digital Object Identifier 10.1109/2.121510&lt;br /&gt;
&lt;br /&gt;
2. SCI: Scalable Coherent Interface&lt;br /&gt;
 Hermann Hellwagner&lt;br /&gt;
 1999&lt;br /&gt;
 SCI: Scalable Coherent Interface - Architecture and software for high-performance Compute Clusters&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_2_1r&amp;diff=6015</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 2 1r</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_2_1r&amp;diff=6015"/>
		<updated>2007-10-19T22:34:44Z</updated>

		<summary type="html">&lt;p&gt;Arangan: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
In parallel systems, data can be obtained from a variety of sources, which includes local or remote memory modules, secondary storage devices and network interfaces. It would be beneficial if certain aspects of mechanisms that are required to gain access to data are standardized such that it allows easily expandable and flexible designs. Various portions of a parallel system may be modified or even upgraded without any effect on the rest of the design if the system adheres to such standards. Also, utilization of standard interfaces forwards the integration of components and subsystems from several different vendors into efficient and usable parallel systems. The Scalable Coherent Interface is one such standard which facilitates the implementation of large-scale cache-coherent parallel systems.&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
===Goals of SCI===&lt;br /&gt;
&lt;br /&gt;
*High Performance – For distributed or parallel applications, high communication performance must be obtained when using SCI. Usual aspects of such performance would be a low latency, low CPU overhead for operations dealing with communication and high sustained throughput.&lt;br /&gt;
&lt;br /&gt;
*Scalability – This is addressed in many ways. Some are&lt;br /&gt;
**Performance scalability – as the number of nodes being added to the system increases.&lt;br /&gt;
**Interconnect Distance scalability&lt;br /&gt;
**Memory System scalability – chiefly of cache coherence protocols, which should not have limitations to the number of processors or modules in memory that it can handle.&lt;br /&gt;
**Technological scalability – utilization of similar mechanisms in large, small-scale, loosely-coupled or tightly-coupled systems. Also, when new advances are made in technology, it must have the ability to readily make use of such advances.&lt;br /&gt;
**Economic scalability – use of similar components and mechanisms in high-end, low-volume systems as well as low-end, high-volume systems.&lt;br /&gt;
**Addressing capability has no short term practical limits.&lt;br /&gt;
&lt;br /&gt;
*Coherent Memory System – For the purpose of reduction of Average Access Time to data, caches are becoming more important each day for microprocessors.&lt;br /&gt;
&lt;br /&gt;
*Interface Characteristics – This specifies a standard interface to an interconnect that makes several devices to be connected or attached together and to interoperate.&lt;br /&gt;
&lt;br /&gt;
===Operation===&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Performance &amp;amp; Correctness (Coherence &amp;amp; Consistency) requirement for the protocol necessitates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
=== Need for Busy state ===&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
In Origin, there are 3 busy states indicates that the directory has received the request but is waiting for completion hence another request for the same block won't be accepted.&lt;br /&gt;
# Busy read&lt;br /&gt;
# Busy read exclusive or upgrade&lt;br /&gt;
# Busy uncached read:  In case of DMA, if the memory block is being read, no other processor should be allowed to get write access to it.&lt;br /&gt;
&lt;br /&gt;
=== Poison state ===&lt;br /&gt;
&lt;br /&gt;
To improve locality, origin relies on page migration. Hardware keeps reference counts on each page. On every access of memory count is incremented and compared with home node. If count is more than programmable threshold, hardware interrupts one of the local processors to copy the page. Block transfer engine “poison” the source page. Subsequent accesses by other processors receive a bus error and that removes the TLB entry for that location, read the location from the page table &amp;amp; update the TLB with new location. This approach is called - “Lazy TLB shootdown” which reduces the overall cost of migrating memory and changing the virtual-to-physical address mappings.&lt;br /&gt;
&lt;br /&gt;
=== Additional states ===&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
*The “fresh” state shows that memory still has an up-to-date copy of the block, even if the block        has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
*The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== 1 DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
3. The SGI Origin: A ccnuma Highly Scalable Server&lt;br /&gt;
 Laudon, J.; Lenoski, D.;&lt;br /&gt;
 Computer Architecture, 1997. Conference Proceedings. The 24th Annual International Symposium on&lt;br /&gt;
 June 2-4, 1997 Page(s):241 - 251 &lt;br /&gt;
&lt;br /&gt;
4. The Scalable Coherence Interface&lt;br /&gt;
 David.B.Gustavson&lt;br /&gt;
 September 1991&lt;br /&gt;
 &amp;quot;The Scalable Coherence Interface and related standard projects&amp;quot;&lt;br /&gt;
&lt;br /&gt;
5. An analysis of the Scalable Coherent Interface&lt;br /&gt;
 Eric Rotenberg&lt;br /&gt;
 June 1995&lt;br /&gt;
 An Analytical model of the SCI Coherence protocol&lt;br /&gt;
&lt;br /&gt;
6. Interfaces and Standards : SCI&lt;br /&gt;
 Behrooz. Parhami&lt;br /&gt;
 1999&lt;br /&gt;
 Introduction to Parallel Processing: Algorithms and Architectures&lt;br /&gt;
&lt;br /&gt;
7. SCI: Scalable Coherent Interface&lt;br /&gt;
 Hermann Hellwagner&lt;br /&gt;
 1999&lt;br /&gt;
 SCI: Scalable Coherent Interface - Architecture and software for high-performance Compute Clusters&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
1. The Stanford Dash multiprocessor&lt;br /&gt;
 Lenoski, D.; Laudon, J.; Gharachorloo, K.; Weber, W.-D.; Gupta, A.; Hennessy, J.; Horowitz, M.; Lam, M.S.;&lt;br /&gt;
 Computer&lt;br /&gt;
 IEEE Volume 25,  Issue 3,  March 1992 Page(s):63 - 79&lt;br /&gt;
 Digital Object Identifier 10.1109/2.121510&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5920</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 8 38</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5920"/>
		<updated>2007-10-18T23:15:09Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* References */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
In parallel systems, data can be obtained from a variety of sources, which includes local or remote memory modules, secondary storage devices and network interfaces. It would be beneficial if certain aspects of mechanisms that are required to gain access to data are standardized such that it allows easily expandable and flexible designs. Various portions of a parallel system may be modified or even upgraded without any effect on the rest of the design if the system adheres to such standards. Also, utilization of standard interfaces forwards the integration of components and subsystems from several different vendors into efficient and usable parallel systems. The Scalable Coherent Interface is one such standard which facilitates the implementation of large-scale cache-coherent parallel systems.&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
===Goals of SCI===&lt;br /&gt;
&lt;br /&gt;
*High Performance – For distributed or parallel applications, high communication performance must be obtained when using SCI. Usual aspects of such performance would be a low latency, low CPU overhead for operations dealing with communication and high sustained throughput.&lt;br /&gt;
&lt;br /&gt;
*Scalability – This is addressed in many ways. Some are&lt;br /&gt;
**Performance scalability – as the number of nodes being added to the system increases.&lt;br /&gt;
**Interconnect Distance scalability&lt;br /&gt;
**Memory System scalability – chiefly of cache coherence protocols, which should not have limitations to the number of processors or modules in memory that it can handle.&lt;br /&gt;
**Technological scalability – utilization of similar mechanisms in large, small-scale, loosely-coupled or tightly-coupled systems. Also, when new advances are made in technology, it must have the ability to readily make use of such advances.&lt;br /&gt;
**Economic scalability – use of similar components and mechanisms in high-end, low-volume systems as well as low-end, high-volume systems.&lt;br /&gt;
**Addressing capability has no short term practical limits.&lt;br /&gt;
&lt;br /&gt;
*Coherent Memory System – For the purpose of reduction of Average Access Time to data, caches are becoming more important each day for microprocessors.&lt;br /&gt;
&lt;br /&gt;
*Interface Characteristics – This specifies a standard interface to an interconnect that makes several devices to be connected or attached together and to interoperate.&lt;br /&gt;
&lt;br /&gt;
===Operation===&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Performance &amp;amp; Correctness (Coherence &amp;amp; Consistency) requirement for the protocol necessitates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
=== Need for Busy state ===&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
In Origin, there are 3 busy states indicates that the directory has received the request but is waiting for completion hence another request for the same block won't be accepted.&lt;br /&gt;
# Busy read&lt;br /&gt;
# Busy read exclusive or upgrade&lt;br /&gt;
# Busy uncached read:  In case of DMA, if the memory block is being read, no other processor should be allowed to get write access to it.&lt;br /&gt;
&lt;br /&gt;
=== Poison state ===&lt;br /&gt;
&lt;br /&gt;
To improve locality, origin relies on page migration. Hardware keeps reference counts on each page. On every access of memory count is incremented and compared with home node. If count is more than programmable threshold, hardware interrupts one of the local processors to copy the page. Block transfer engine “poison” the source page. Subsequent accesses by other processors receive a bus error and that removes the TLB entry for that location, read the location from the page table &amp;amp; update the TLB with new location. This approach is called - “Lazy TLB shootdown” which reduces the overall cost of migrating memory and changing the virtual-to-physical address mappings.&lt;br /&gt;
&lt;br /&gt;
=== Additional states ===&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
*The “fresh” state shows that memory still has an up-to-date copy of the block, even if the block        has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
*The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== 1 DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
3. The SGI Origin: A ccnuma Highly Scalable Server&lt;br /&gt;
 Laudon, J.; Lenoski, D.;&lt;br /&gt;
 Computer Architecture, 1997. Conference Proceedings. The 24th Annual International Symposium on&lt;br /&gt;
 June 2-4, 1997 Page(s):241 - 251 &lt;br /&gt;
&lt;br /&gt;
4. The Scalable Coherence Interface&lt;br /&gt;
 David.B.Gustavson&lt;br /&gt;
 September 1991&lt;br /&gt;
 &amp;quot;The Scalable Coherence Interface and related standard projects&amp;quot;&lt;br /&gt;
&lt;br /&gt;
5. An analysis of the Scalable Coherent Interface&lt;br /&gt;
 Eric Rotenberg&lt;br /&gt;
 June 1995&lt;br /&gt;
 An Analytical model of the SCI Coherence protocol&lt;br /&gt;
&lt;br /&gt;
6. Interfaces and Standards : SCI&lt;br /&gt;
 Behrooz. Parhami&lt;br /&gt;
 1999&lt;br /&gt;
 Introduction to Parallel Processing: Algorithms and Architectures&lt;br /&gt;
&lt;br /&gt;
7. SCI: Scalable Coherent Interface&lt;br /&gt;
 Hermann Hellwagner&lt;br /&gt;
 1999&lt;br /&gt;
 SCI: Scalable Coherent Interface - Architecture and software for high-performance Compute Clusters&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
1. The Stanford Dash multiprocessor&lt;br /&gt;
 Lenoski, D.; Laudon, J.; Gharachorloo, K.; Weber, W.-D.; Gupta, A.; Hennessy, J.; Horowitz, M.; Lam, M.S.;&lt;br /&gt;
 Computer&lt;br /&gt;
 IEEE Volume 25,  Issue 3,  March 1992 Page(s):63 - 79&lt;br /&gt;
 Digital Object Identifier 10.1109/2.121510&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5919</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 8 38</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5919"/>
		<updated>2007-10-18T23:14:43Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* References */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
In parallel systems, data can be obtained from a variety of sources, which includes local or remote memory modules, secondary storage devices and network interfaces. It would be beneficial if certain aspects of mechanisms that are required to gain access to data are standardized such that it allows easily expandable and flexible designs. Various portions of a parallel system may be modified or even upgraded without any effect on the rest of the design if the system adheres to such standards. Also, utilization of standard interfaces forwards the integration of components and subsystems from several different vendors into efficient and usable parallel systems. The Scalable Coherent Interface is one such standard which facilitates the implementation of large-scale cache-coherent parallel systems.&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
===Goals of SCI===&lt;br /&gt;
&lt;br /&gt;
*High Performance – For distributed or parallel applications, high communication performance must be obtained when using SCI. Usual aspects of such performance would be a low latency, low CPU overhead for operations dealing with communication and high sustained throughput.&lt;br /&gt;
&lt;br /&gt;
*Scalability – This is addressed in many ways. Some are&lt;br /&gt;
**Performance scalability – as the number of nodes being added to the system increases.&lt;br /&gt;
**Interconnect Distance scalability&lt;br /&gt;
**Memory System scalability – chiefly of cache coherence protocols, which should not have limitations to the number of processors or modules in memory that it can handle.&lt;br /&gt;
**Technological scalability – utilization of similar mechanisms in large, small-scale, loosely-coupled or tightly-coupled systems. Also, when new advances are made in technology, it must have the ability to readily make use of such advances.&lt;br /&gt;
**Economic scalability – use of similar components and mechanisms in high-end, low-volume systems as well as low-end, high-volume systems.&lt;br /&gt;
**Addressing capability has no short term practical limits.&lt;br /&gt;
&lt;br /&gt;
*Coherent Memory System – For the purpose of reduction of Average Access Time to data, caches are becoming more important each day for microprocessors.&lt;br /&gt;
&lt;br /&gt;
*Interface Characteristics – This specifies a standard interface to an interconnect that makes several devices to be connected or attached together and to interoperate.&lt;br /&gt;
&lt;br /&gt;
===Operation===&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Performance &amp;amp; Correctness (Coherence &amp;amp; Consistency) requirement for the protocol necessitates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
=== Need for Busy state ===&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
In Origin, there are 3 busy states indicates that the directory has received the request but is waiting for completion hence another request for the same block won't be accepted.&lt;br /&gt;
# Busy read&lt;br /&gt;
# Busy read exclusive or upgrade&lt;br /&gt;
# Busy uncached read:  In case of DMA, if the memory block is being read, no other processor should be allowed to get write access to it.&lt;br /&gt;
&lt;br /&gt;
=== Poison state ===&lt;br /&gt;
&lt;br /&gt;
To improve locality, origin relies on page migration. Hardware keeps reference counts on each page. On every access of memory count is incremented and compared with home node. If count is more than programmable threshold, hardware interrupts one of the local processors to copy the page. Block transfer engine “poison” the source page. Subsequent accesses by other processors receive a bus error and that removes the TLB entry for that location, read the location from the page table &amp;amp; update the TLB with new location. This approach is called - “Lazy TLB shootdown” which reduces the overall cost of migrating memory and changing the virtual-to-physical address mappings.&lt;br /&gt;
&lt;br /&gt;
=== Additional states ===&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
*The “fresh” state shows that memory still has an up-to-date copy of the block, even if the block        has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
*The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== 1 DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
3. The SGI Origin: A ccnuma Highly Scalable Server&lt;br /&gt;
 Laudon, J.; Lenoski, D.;&lt;br /&gt;
 Computer Architecture, 1997. Conference Proceedings. The 24th Annual International Symposium on&lt;br /&gt;
 June 2-4, 1997 Page(s):241 - 251 &lt;br /&gt;
&lt;br /&gt;
4. The Scalable Coherence Interface&lt;br /&gt;
 David.B.Gustavson&lt;br /&gt;
 September 1991&lt;br /&gt;
 &amp;quot;The Scalable Coherence Interface and related standard projects&amp;quot;&lt;br /&gt;
&lt;br /&gt;
5. An analysis of the Scalable Coherent Interface&lt;br /&gt;
 Eric Rotenberg&lt;br /&gt;
 June 1995&lt;br /&gt;
 An Analytical model of the SCI Coherence protocol&lt;br /&gt;
&lt;br /&gt;
6. Interfaces and Standards : SCI&lt;br /&gt;
 Behrooz. Parhami&lt;br /&gt;
 1999&lt;br /&gt;
 Introduction to Parallel Processing: Algorithms and Architectures&lt;br /&gt;
&lt;br /&gt;
7. SCI: SCalable Coherent Interface&lt;br /&gt;
 Hermann Hellwagner&lt;br /&gt;
 1999&lt;br /&gt;
 SCI: Scalable Coherent Interface - Architecture and software for high-performance Compute Clusters&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
1. The Stanford Dash multiprocessor&lt;br /&gt;
 Lenoski, D.; Laudon, J.; Gharachorloo, K.; Weber, W.-D.; Gupta, A.; Hennessy, J.; Horowitz, M.; Lam, M.S.;&lt;br /&gt;
 Computer&lt;br /&gt;
 IEEE Volume 25,  Issue 3,  March 1992 Page(s):63 - 79&lt;br /&gt;
 Digital Object Identifier 10.1109/2.121510&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5918</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 8 38</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5918"/>
		<updated>2007-10-18T23:09:01Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* Introduction */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
In parallel systems, data can be obtained from a variety of sources, which includes local or remote memory modules, secondary storage devices and network interfaces. It would be beneficial if certain aspects of mechanisms that are required to gain access to data are standardized such that it allows easily expandable and flexible designs. Various portions of a parallel system may be modified or even upgraded without any effect on the rest of the design if the system adheres to such standards. Also, utilization of standard interfaces forwards the integration of components and subsystems from several different vendors into efficient and usable parallel systems. The Scalable Coherent Interface is one such standard which facilitates the implementation of large-scale cache-coherent parallel systems.&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
===Goals of SCI===&lt;br /&gt;
&lt;br /&gt;
*High Performance – For distributed or parallel applications, high communication performance must be obtained when using SCI. Usual aspects of such performance would be a low latency, low CPU overhead for operations dealing with communication and high sustained throughput.&lt;br /&gt;
&lt;br /&gt;
*Scalability – This is addressed in many ways. Some are&lt;br /&gt;
**Performance scalability – as the number of nodes being added to the system increases.&lt;br /&gt;
**Interconnect Distance scalability&lt;br /&gt;
**Memory System scalability – chiefly of cache coherence protocols, which should not have limitations to the number of processors or modules in memory that it can handle.&lt;br /&gt;
**Technological scalability – utilization of similar mechanisms in large, small-scale, loosely-coupled or tightly-coupled systems. Also, when new advances are made in technology, it must have the ability to readily make use of such advances.&lt;br /&gt;
**Economic scalability – use of similar components and mechanisms in high-end, low-volume systems as well as low-end, high-volume systems.&lt;br /&gt;
**Addressing capability has no short term practical limits.&lt;br /&gt;
&lt;br /&gt;
*Coherent Memory System – For the purpose of reduction of Average Access Time to data, caches are becoming more important each day for microprocessors.&lt;br /&gt;
&lt;br /&gt;
*Interface Characteristics – This specifies a standard interface to an interconnect that makes several devices to be connected or attached together and to interoperate.&lt;br /&gt;
&lt;br /&gt;
===Operation===&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Performance &amp;amp; Correctness (Coherence &amp;amp; Consistency) requirement for the protocol necessitates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
=== Need for Busy state ===&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
In Origin, there are 3 busy states indicates that the directory has received the request but is waiting for completion hence another request for the same block won't be accepted.&lt;br /&gt;
# Busy read&lt;br /&gt;
# Busy read exclusive or upgrade&lt;br /&gt;
# Busy uncached read:  In case of DMA, if the memory block is being read, no other processor should be allowed to get write access to it.&lt;br /&gt;
&lt;br /&gt;
=== Poison state ===&lt;br /&gt;
&lt;br /&gt;
To improve locality, origin relies on page migration. Hardware keeps reference counts on each page. On every access of memory count is incremented and compared with home node. If count is more than programmable threshold, hardware interrupts one of the local processors to copy the page. Block transfer engine “poison” the source page. Subsequent accesses by other processors receive a bus error and that removes the TLB entry for that location, read the location from the page table &amp;amp; update the TLB with new location. This approach is called - “Lazy TLB shootdown” which reduces the overall cost of migrating memory and changing the virtual-to-physical address mappings.&lt;br /&gt;
&lt;br /&gt;
=== Additional states ===&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
*The “fresh” state shows that memory still has an up-to-date copy of the block, even if the block        has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
*The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== 1 DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
3. The SGI Origin: A ccnuma Highly Scalable Server&lt;br /&gt;
 Laudon, J.; Lenoski, D.;&lt;br /&gt;
 Computer Architecture, 1997. Conference Proceedings. The 24th Annual International Symposium on&lt;br /&gt;
 June 2-4, 1997 Page(s):241 - 251 &lt;br /&gt;
&lt;br /&gt;
4. The Scalable Coherence Interface&lt;br /&gt;
 David.B.Gustavson&lt;br /&gt;
 September 1991&lt;br /&gt;
 &amp;quot;The Scalable Coherence Interface and related standard projects&amp;quot;&lt;br /&gt;
&lt;br /&gt;
5. An analysis of the Scalable Coherent Interface&lt;br /&gt;
 Eric Rotenberg&lt;br /&gt;
 June 1995&lt;br /&gt;
 An Analytical model of the SCI Coherence protocol&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
1. The Stanford Dash multiprocessor&lt;br /&gt;
 Lenoski, D.; Laudon, J.; Gharachorloo, K.; Weber, W.-D.; Gupta, A.; Hennessy, J.; Horowitz, M.; Lam, M.S.;&lt;br /&gt;
 Computer&lt;br /&gt;
 IEEE Volume 25,  Issue 3,  March 1992 Page(s):63 - 79&lt;br /&gt;
 Digital Object Identifier 10.1109/2.121510&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5917</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 8 38</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5917"/>
		<updated>2007-10-18T22:34:38Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* Need for Busy state */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
===Goals of SCI===&lt;br /&gt;
&lt;br /&gt;
*High Performance – For distributed or parallel applications, high communication performance must be obtained when using SCI. Usual aspects of such performance would be a low latency, low CPU overhead for operations dealing with communication and high sustained throughput.&lt;br /&gt;
&lt;br /&gt;
*Scalability – This is addressed in many ways. Some are&lt;br /&gt;
**Performance scalability – as the number of nodes being added to the system increases.&lt;br /&gt;
**Interconnect Distance scalability&lt;br /&gt;
**Memory System scalability – chiefly of cache coherence protocols, which should not have limitations to the number of processors or modules in memory that it can handle.&lt;br /&gt;
**Technological scalability – utilization of similar mechanisms in large, small-scale, loosely-coupled or tightly-coupled systems. Also, when new advances are made in technology, it must have the ability to readily make use of such advances.&lt;br /&gt;
**Economic scalability – use of similar components and mechanisms in high-end, low-volume systems as well as low-end, high-volume systems.&lt;br /&gt;
**Addressing capability has no short term practical limits.&lt;br /&gt;
&lt;br /&gt;
*Coherent Memory System – For the purpose of reduction of Average Access Time to data, caches are becoming more important each day for microprocessors.&lt;br /&gt;
&lt;br /&gt;
*Interface Characteristics – This specifies a standard interface to an interconnect that makes several devices to be connected or attached together and to interoperate.&lt;br /&gt;
&lt;br /&gt;
===Operation===&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Performance &amp;amp; Correctness (Coherence &amp;amp; Consistency) requirement for the protocol necessitates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
=== Need for Busy state ===&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
In Origin, there are 3 busy states indicates that the directory has received the request but is waiting for completion hence another request for the same block won't be accepted.&lt;br /&gt;
# Busy read&lt;br /&gt;
# Busy read exclusive or upgrade&lt;br /&gt;
# Busy uncached read:  In case of DMA, if the memory block is being read, no other processor should be allowed to get write access to it.&lt;br /&gt;
&lt;br /&gt;
=== Poison state ===&lt;br /&gt;
&lt;br /&gt;
To improve locality, origin relies on page migration. Hardware keeps reference counts on each page. On every access of memory count is incremented and compared with home node. If count is more than programmable threshold, hardware interrupts one of the local processors to copy the page. Block transfer engine “poison” the source page. Subsequent accesses by other processors receive a bus error and that removes the TLB entry for that location, read the location from the page table &amp;amp; update the TLB with new location. This approach is called - “Lazy TLB shootdown” which reduces the overall cost of migrating memory and changing the virtual-to-physical address mappings.&lt;br /&gt;
&lt;br /&gt;
=== Additional states ===&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
*The “fresh” state shows that memory still has an up-to-date copy of the block, even if the block        has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
*The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== 1 DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
3. The SGI Origin: A ccnuma Highly Scalable Server&lt;br /&gt;
 Laudon, J.; Lenoski, D.;&lt;br /&gt;
 Computer Architecture, 1997. Conference Proceedings. The 24th Annual International Symposium on&lt;br /&gt;
 June 2-4, 1997 Page(s):241 - 251 &lt;br /&gt;
&lt;br /&gt;
4. The Scalable Coherence Interface&lt;br /&gt;
 David.B.Gustavson&lt;br /&gt;
 September 1991&lt;br /&gt;
 &amp;quot;The Scalable Coherence Interface and related standard projects&amp;quot;&lt;br /&gt;
&lt;br /&gt;
5. An analysis of the Scalable Coherent Interface&lt;br /&gt;
 Eric Rotenberg&lt;br /&gt;
 June 1995&lt;br /&gt;
 An Analytical model of the SCI Coherence protocol&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
1. The Stanford Dash multiprocessor&lt;br /&gt;
 Lenoski, D.; Laudon, J.; Gharachorloo, K.; Weber, W.-D.; Gupta, A.; Hennessy, J.; Horowitz, M.; Lam, M.S.;&lt;br /&gt;
 Computer&lt;br /&gt;
 IEEE Volume 25,  Issue 3,  March 1992 Page(s):63 - 79&lt;br /&gt;
 Digital Object Identifier 10.1109/2.121510&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5916</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 8 38</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5916"/>
		<updated>2007-10-18T22:34:24Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* Scalable Coherent Interface (SCI) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
===Goals of SCI===&lt;br /&gt;
&lt;br /&gt;
*High Performance – For distributed or parallel applications, high communication performance must be obtained when using SCI. Usual aspects of such performance would be a low latency, low CPU overhead for operations dealing with communication and high sustained throughput.&lt;br /&gt;
&lt;br /&gt;
*Scalability – This is addressed in many ways. Some are&lt;br /&gt;
**Performance scalability – as the number of nodes being added to the system increases.&lt;br /&gt;
**Interconnect Distance scalability&lt;br /&gt;
**Memory System scalability – chiefly of cache coherence protocols, which should not have limitations to the number of processors or modules in memory that it can handle.&lt;br /&gt;
**Technological scalability – utilization of similar mechanisms in large, small-scale, loosely-coupled or tightly-coupled systems. Also, when new advances are made in technology, it must have the ability to readily make use of such advances.&lt;br /&gt;
**Economic scalability – use of similar components and mechanisms in high-end, low-volume systems as well as low-end, high-volume systems.&lt;br /&gt;
**Addressing capability has no short term practical limits.&lt;br /&gt;
&lt;br /&gt;
*Coherent Memory System – For the purpose of reduction of Average Access Time to data, caches are becoming more important each day for microprocessors.&lt;br /&gt;
&lt;br /&gt;
*Interface Characteristics – This specifies a standard interface to an interconnect that makes several devices to be connected or attached together and to interoperate.&lt;br /&gt;
&lt;br /&gt;
===Operation===&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Performance &amp;amp; Correctness (Coherence &amp;amp; Consistency) requirement for the protocol necessitates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
=== Need for Busy state ===&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In Origin, there are 3 busy states indicates that the directory has received the request but is waiting for completion hence another request for the same block won't be accepted.&lt;br /&gt;
# Busy read&lt;br /&gt;
# Busy read exclusive or upgrade&lt;br /&gt;
# Busy uncached read:  In case of DMA, if the memory block is being read, no other processor should be allowed to get write access to it.&lt;br /&gt;
&lt;br /&gt;
=== Poison state ===&lt;br /&gt;
&lt;br /&gt;
To improve locality, origin relies on page migration. Hardware keeps reference counts on each page. On every access of memory count is incremented and compared with home node. If count is more than programmable threshold, hardware interrupts one of the local processors to copy the page. Block transfer engine “poison” the source page. Subsequent accesses by other processors receive a bus error and that removes the TLB entry for that location, read the location from the page table &amp;amp; update the TLB with new location. This approach is called - “Lazy TLB shootdown” which reduces the overall cost of migrating memory and changing the virtual-to-physical address mappings.&lt;br /&gt;
&lt;br /&gt;
=== Additional states ===&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
*The “fresh” state shows that memory still has an up-to-date copy of the block, even if the block        has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
*The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== 1 DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
3. The SGI Origin: A ccnuma Highly Scalable Server&lt;br /&gt;
 Laudon, J.; Lenoski, D.;&lt;br /&gt;
 Computer Architecture, 1997. Conference Proceedings. The 24th Annual International Symposium on&lt;br /&gt;
 June 2-4, 1997 Page(s):241 - 251 &lt;br /&gt;
&lt;br /&gt;
4. The Scalable Coherence Interface&lt;br /&gt;
 David.B.Gustavson&lt;br /&gt;
 September 1991&lt;br /&gt;
 &amp;quot;The Scalable Coherence Interface and related standard projects&amp;quot;&lt;br /&gt;
&lt;br /&gt;
5. An analysis of the Scalable Coherent Interface&lt;br /&gt;
 Eric Rotenberg&lt;br /&gt;
 June 1995&lt;br /&gt;
 An Analytical model of the SCI Coherence protocol&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
1. The Stanford Dash multiprocessor&lt;br /&gt;
 Lenoski, D.; Laudon, J.; Gharachorloo, K.; Weber, W.-D.; Gupta, A.; Hennessy, J.; Horowitz, M.; Lam, M.S.;&lt;br /&gt;
 Computer&lt;br /&gt;
 IEEE Volume 25,  Issue 3,  March 1992 Page(s):63 - 79&lt;br /&gt;
 Digital Object Identifier 10.1109/2.121510&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5915</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 8 38</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5915"/>
		<updated>2007-10-18T22:33:42Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* Scalable Coherent Interface (SCI) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
===Goals of SCI===&lt;br /&gt;
&lt;br /&gt;
*High Performance – For distributed or parallel applications, high communication performance must be obtained when using SCI. Usual aspects of such performance would be a low latency, low CPU overhead for operations dealing with communication and high sustained throughput.&lt;br /&gt;
&lt;br /&gt;
*Scalability – This is addressed in many ways. Some are&lt;br /&gt;
**Performance scalability – as the number of nodes being added to the system increases.&lt;br /&gt;
**Interconnect Distance scalability&lt;br /&gt;
**Memory System scalability – chiefly of cache coherence protocols, which should not have limitations to the number of processors or modules in memory that it can handle.&lt;br /&gt;
**Technological scalability – utilization of similar mechanisms in large, small-scale, loosely-coupled or tightly-coupled systems. Also, when new advances are made in technology, it must have the ability to readily make use of such advances.&lt;br /&gt;
**Economic scalability – use of similar components and mechanisms in high-end, low-volume systems as well as low-end, high-volume systems.&lt;br /&gt;
**Addressing capability has no short term practical limits.&lt;br /&gt;
&lt;br /&gt;
*Coherent Memory System – For the purpose of reduction of Average Access Time to data, caches are becoming more important each day for microprocessors.&lt;br /&gt;
&lt;br /&gt;
*Interface Characteristics – This specifies a standard interface to an interconnect that makes several devices to be connected or attached together and to interoperate.&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Performance &amp;amp; Correctness (Coherence &amp;amp; Consistency) requirement for the protocol necessitates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
=== Need for Busy state ===&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In Origin, there are 3 busy states indicates that the directory has received the request but is waiting for completion hence another request for the same block won't be accepted.&lt;br /&gt;
# Busy read&lt;br /&gt;
# Busy read exclusive or upgrade&lt;br /&gt;
# Busy uncached read:  In case of DMA, if the memory block is being read, no other processor should be allowed to get write access to it.&lt;br /&gt;
&lt;br /&gt;
=== Poison state ===&lt;br /&gt;
&lt;br /&gt;
To improve locality, origin relies on page migration. Hardware keeps reference counts on each page. On every access of memory count is incremented and compared with home node. If count is more than programmable threshold, hardware interrupts one of the local processors to copy the page. Block transfer engine “poison” the source page. Subsequent accesses by other processors receive a bus error and that removes the TLB entry for that location, read the location from the page table &amp;amp; update the TLB with new location. This approach is called - “Lazy TLB shootdown” which reduces the overall cost of migrating memory and changing the virtual-to-physical address mappings.&lt;br /&gt;
&lt;br /&gt;
=== Additional states ===&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
*The “fresh” state shows that memory still has an up-to-date copy of the block, even if the block        has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
*The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== 1 DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
3. The SGI Origin: A ccnuma Highly Scalable Server&lt;br /&gt;
 Laudon, J.; Lenoski, D.;&lt;br /&gt;
 Computer Architecture, 1997. Conference Proceedings. The 24th Annual International Symposium on&lt;br /&gt;
 June 2-4, 1997 Page(s):241 - 251 &lt;br /&gt;
&lt;br /&gt;
4. The Scalable Coherence Interface&lt;br /&gt;
 David.B.Gustavson&lt;br /&gt;
 September 1991&lt;br /&gt;
 &amp;quot;The Scalable Coherence Interface and related standard projects&amp;quot;&lt;br /&gt;
&lt;br /&gt;
5. An analysis of the Scalable Coherent Interface&lt;br /&gt;
 Eric Rotenberg&lt;br /&gt;
 June 1995&lt;br /&gt;
 An Analytical model of the SCI Coherence protocol&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
1. The Stanford Dash multiprocessor&lt;br /&gt;
 Lenoski, D.; Laudon, J.; Gharachorloo, K.; Weber, W.-D.; Gupta, A.; Hennessy, J.; Horowitz, M.; Lam, M.S.;&lt;br /&gt;
 Computer&lt;br /&gt;
 IEEE Volume 25,  Issue 3,  March 1992 Page(s):63 - 79&lt;br /&gt;
 Digital Object Identifier 10.1109/2.121510&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5914</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 8 38</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5914"/>
		<updated>2007-10-18T22:32:59Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* Additional states */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
Goals of SCI&lt;br /&gt;
&lt;br /&gt;
*High Performance – For distributed or parallel applications, high communication performance must be obtained when using SCI. Usual aspects of such performance would be a low latency, low CPU overhead for operations dealing with communication and high sustained throughput.&lt;br /&gt;
&lt;br /&gt;
*Scalability – This is addressed in many ways. Some are&lt;br /&gt;
**Performance scalability – as the number of nodes being added to the system increases.&lt;br /&gt;
**Interconnect Distance scalability&lt;br /&gt;
**Memory System scalability – chiefly of cache coherence protocols, which should not have limitations to the number of processors or modules in memory that it can handle.&lt;br /&gt;
**Technological scalability – utilization of similar mechanisms in large, small-scale, loosely-coupled or tightly-coupled systems. Also, when new advances are made in technology, it must have the ability to readily make use of such advances.&lt;br /&gt;
**Economic scalability – use of similar components and mechanisms in high-end, low-volume systems as well as low-end, high-volume systems.&lt;br /&gt;
**Addressing capability has no short term practical limits.&lt;br /&gt;
&lt;br /&gt;
*Coherent Memory System – For the purpose of reduction of Average Access Time to data, caches are becoming more important each day for microprocessors.&lt;br /&gt;
&lt;br /&gt;
*Interface Characteristics – This specifies a standard interface to an interconnect that makes several devices to be connected or attached together and to interoperate.&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Performance &amp;amp; Correctness (Coherence &amp;amp; Consistency) requirement for the protocol necessitates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
=== Need for Busy state ===&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In Origin, there are 3 busy states indicates that the directory has received the request but is waiting for completion hence another request for the same block won't be accepted.&lt;br /&gt;
# Busy read&lt;br /&gt;
# Busy read exclusive or upgrade&lt;br /&gt;
# Busy uncached read:  In case of DMA, if the memory block is being read, no other processor should be allowed to get write access to it.&lt;br /&gt;
&lt;br /&gt;
=== Poison state ===&lt;br /&gt;
&lt;br /&gt;
To improve locality, origin relies on page migration. Hardware keeps reference counts on each page. On every access of memory count is incremented and compared with home node. If count is more than programmable threshold, hardware interrupts one of the local processors to copy the page. Block transfer engine “poison” the source page. Subsequent accesses by other processors receive a bus error and that removes the TLB entry for that location, read the location from the page table &amp;amp; update the TLB with new location. This approach is called - “Lazy TLB shootdown” which reduces the overall cost of migrating memory and changing the virtual-to-physical address mappings.&lt;br /&gt;
&lt;br /&gt;
=== Additional states ===&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
*The “fresh” state shows that memory still has an up-to-date copy of the block, even if the block        has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
*The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== 1 DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
3. The SGI Origin: A ccnuma Highly Scalable Server&lt;br /&gt;
 Laudon, J.; Lenoski, D.;&lt;br /&gt;
 Computer Architecture, 1997. Conference Proceedings. The 24th Annual International Symposium on&lt;br /&gt;
 June 2-4, 1997 Page(s):241 - 251 &lt;br /&gt;
&lt;br /&gt;
4. The Scalable Coherence Interface&lt;br /&gt;
 David.B.Gustavson&lt;br /&gt;
 September 1991&lt;br /&gt;
 &amp;quot;The Scalable Coherence Interface and related standard projects&amp;quot;&lt;br /&gt;
&lt;br /&gt;
5. An analysis of the Scalable Coherent Interface&lt;br /&gt;
 Eric Rotenberg&lt;br /&gt;
 June 1995&lt;br /&gt;
 An Analytical model of the SCI Coherence protocol&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
1. The Stanford Dash multiprocessor&lt;br /&gt;
 Lenoski, D.; Laudon, J.; Gharachorloo, K.; Weber, W.-D.; Gupta, A.; Hennessy, J.; Horowitz, M.; Lam, M.S.;&lt;br /&gt;
 Computer&lt;br /&gt;
 IEEE Volume 25,  Issue 3,  March 1992 Page(s):63 - 79&lt;br /&gt;
 Digital Object Identifier 10.1109/2.121510&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5913</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 8 38</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5913"/>
		<updated>2007-10-18T22:32:44Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* Additional states */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
Goals of SCI&lt;br /&gt;
&lt;br /&gt;
*High Performance – For distributed or parallel applications, high communication performance must be obtained when using SCI. Usual aspects of such performance would be a low latency, low CPU overhead for operations dealing with communication and high sustained throughput.&lt;br /&gt;
&lt;br /&gt;
*Scalability – This is addressed in many ways. Some are&lt;br /&gt;
**Performance scalability – as the number of nodes being added to the system increases.&lt;br /&gt;
**Interconnect Distance scalability&lt;br /&gt;
**Memory System scalability – chiefly of cache coherence protocols, which should not have limitations to the number of processors or modules in memory that it can handle.&lt;br /&gt;
**Technological scalability – utilization of similar mechanisms in large, small-scale, loosely-coupled or tightly-coupled systems. Also, when new advances are made in technology, it must have the ability to readily make use of such advances.&lt;br /&gt;
**Economic scalability – use of similar components and mechanisms in high-end, low-volume systems as well as low-end, high-volume systems.&lt;br /&gt;
**Addressing capability has no short term practical limits.&lt;br /&gt;
&lt;br /&gt;
*Coherent Memory System – For the purpose of reduction of Average Access Time to data, caches are becoming more important each day for microprocessors.&lt;br /&gt;
&lt;br /&gt;
*Interface Characteristics – This specifies a standard interface to an interconnect that makes several devices to be connected or attached together and to interoperate.&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Performance &amp;amp; Correctness (Coherence &amp;amp; Consistency) requirement for the protocol necessitates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
=== Need for Busy state ===&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In Origin, there are 3 busy states indicates that the directory has received the request but is waiting for completion hence another request for the same block won't be accepted.&lt;br /&gt;
# Busy read&lt;br /&gt;
# Busy read exclusive or upgrade&lt;br /&gt;
# Busy uncached read:  In case of DMA, if the memory block is being read, no other processor should be allowed to get write access to it.&lt;br /&gt;
&lt;br /&gt;
=== Poison state ===&lt;br /&gt;
&lt;br /&gt;
To improve locality, origin relies on page migration. Hardware keeps reference counts on each page. On every access of memory count is incremented and compared with home node. If count is more than programmable threshold, hardware interrupts one of the local processors to copy the page. Block transfer engine “poison” the source page. Subsequent accesses by other processors receive a bus error and that removes the TLB entry for that location, read the location from the page table &amp;amp; update the TLB with new location. This approach is called - “Lazy TLB shootdown” which reduces the overall cost of migrating memory and changing the virtual-to-physical address mappings.&lt;br /&gt;
&lt;br /&gt;
=== Additional states ===&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
**The “fresh” state shows that memory still has an up-to-date copy of the block, even if the block        has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
**The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== 1 DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
3. The SGI Origin: A ccnuma Highly Scalable Server&lt;br /&gt;
 Laudon, J.; Lenoski, D.;&lt;br /&gt;
 Computer Architecture, 1997. Conference Proceedings. The 24th Annual International Symposium on&lt;br /&gt;
 June 2-4, 1997 Page(s):241 - 251 &lt;br /&gt;
&lt;br /&gt;
4. The Scalable Coherence Interface&lt;br /&gt;
 David.B.Gustavson&lt;br /&gt;
 September 1991&lt;br /&gt;
 &amp;quot;The Scalable Coherence Interface and related standard projects&amp;quot;&lt;br /&gt;
&lt;br /&gt;
5. An analysis of the Scalable Coherent Interface&lt;br /&gt;
 Eric Rotenberg&lt;br /&gt;
 June 1995&lt;br /&gt;
 An Analytical model of the SCI Coherence protocol&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
1. The Stanford Dash multiprocessor&lt;br /&gt;
 Lenoski, D.; Laudon, J.; Gharachorloo, K.; Weber, W.-D.; Gupta, A.; Hennessy, J.; Horowitz, M.; Lam, M.S.;&lt;br /&gt;
 Computer&lt;br /&gt;
 IEEE Volume 25,  Issue 3,  March 1992 Page(s):63 - 79&lt;br /&gt;
 Digital Object Identifier 10.1109/2.121510&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5912</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 8 38</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5912"/>
		<updated>2007-10-18T22:32:12Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* Scalable Coherent Interface (SCI) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
Goals of SCI&lt;br /&gt;
&lt;br /&gt;
*High Performance – For distributed or parallel applications, high communication performance must be obtained when using SCI. Usual aspects of such performance would be a low latency, low CPU overhead for operations dealing with communication and high sustained throughput.&lt;br /&gt;
&lt;br /&gt;
*Scalability – This is addressed in many ways. Some are&lt;br /&gt;
**Performance scalability – as the number of nodes being added to the system increases.&lt;br /&gt;
**Interconnect Distance scalability&lt;br /&gt;
**Memory System scalability – chiefly of cache coherence protocols, which should not have limitations to the number of processors or modules in memory that it can handle.&lt;br /&gt;
**Technological scalability – utilization of similar mechanisms in large, small-scale, loosely-coupled or tightly-coupled systems. Also, when new advances are made in technology, it must have the ability to readily make use of such advances.&lt;br /&gt;
**Economic scalability – use of similar components and mechanisms in high-end, low-volume systems as well as low-end, high-volume systems.&lt;br /&gt;
**Addressing capability has no short term practical limits.&lt;br /&gt;
&lt;br /&gt;
*Coherent Memory System – For the purpose of reduction of Average Access Time to data, caches are becoming more important each day for microprocessors.&lt;br /&gt;
&lt;br /&gt;
*Interface Characteristics – This specifies a standard interface to an interconnect that makes several devices to be connected or attached together and to interoperate.&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Performance &amp;amp; Correctness (Coherence &amp;amp; Consistency) requirement for the protocol necessitates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
=== Need for Busy state ===&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In Origin, there are 3 busy states indicates that the directory has received the request but is waiting for completion hence another request for the same block won't be accepted.&lt;br /&gt;
# Busy read&lt;br /&gt;
# Busy read exclusive or upgrade&lt;br /&gt;
# Busy uncached read:  In case of DMA, if the memory block is being read, no other processor should be allowed to get write access to it.&lt;br /&gt;
&lt;br /&gt;
=== Poison state ===&lt;br /&gt;
&lt;br /&gt;
To improve locality, origin relies on page migration. Hardware keeps reference counts on each page. On every access of memory count is incremented and compared with home node. If count is more than programmable threshold, hardware interrupts one of the local processors to copy the page. Block transfer engine “poison” the source page. Subsequent accesses by other processors receive a bus error and that removes the TLB entry for that location, read the location from the page table &amp;amp; update the TLB with new location. This approach is called - “Lazy TLB shootdown” which reduces the overall cost of migrating memory and changing the virtual-to-physical address mappings.&lt;br /&gt;
&lt;br /&gt;
=== Additional states ===&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
The “fresh” state shows that memory still has an up-to-date copy of the block, even if the block        has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== 1 DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
3. The SGI Origin: A ccnuma Highly Scalable Server&lt;br /&gt;
 Laudon, J.; Lenoski, D.;&lt;br /&gt;
 Computer Architecture, 1997. Conference Proceedings. The 24th Annual International Symposium on&lt;br /&gt;
 June 2-4, 1997 Page(s):241 - 251 &lt;br /&gt;
&lt;br /&gt;
4. The Scalable Coherence Interface&lt;br /&gt;
 David.B.Gustavson&lt;br /&gt;
 September 1991&lt;br /&gt;
 &amp;quot;The Scalable Coherence Interface and related standard projects&amp;quot;&lt;br /&gt;
&lt;br /&gt;
5. An analysis of the Scalable Coherent Interface&lt;br /&gt;
 Eric Rotenberg&lt;br /&gt;
 June 1995&lt;br /&gt;
 An Analytical model of the SCI Coherence protocol&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
1. The Stanford Dash multiprocessor&lt;br /&gt;
 Lenoski, D.; Laudon, J.; Gharachorloo, K.; Weber, W.-D.; Gupta, A.; Hennessy, J.; Horowitz, M.; Lam, M.S.;&lt;br /&gt;
 Computer&lt;br /&gt;
 IEEE Volume 25,  Issue 3,  March 1992 Page(s):63 - 79&lt;br /&gt;
 Digital Object Identifier 10.1109/2.121510&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5911</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 8 38</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5911"/>
		<updated>2007-10-18T22:30:30Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* Scalable Coherent Interface (SCI) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
Goals of SCI&lt;br /&gt;
&lt;br /&gt;
#High Performance – For distributed or parallel applications, high communication performance must be obtained when using SCI. Usual aspects of such performance would be a low latency, low CPU overhead for operations dealing with communication and high sustained throughput.&lt;br /&gt;
&lt;br /&gt;
#Scalability – This is addressed in many ways. Some are&lt;br /&gt;
*Performance scalability – as the number of nodes being added to the system increases.&lt;br /&gt;
*Interconnect Distance scalability&lt;br /&gt;
*Memory System scalability – chiefly of cache coherence protocols, which should not have limitations to the number of processors or modules in memory that it can handle.&lt;br /&gt;
*Technological scalability – utilization of similar mechanisms in large, small-scale, loosely-coupled or tightly-coupled systems. Also, when new advances are made in technology, it must have the ability to readily make use of such advances.&lt;br /&gt;
*Economic scalability – use of similar components and mechanisms in high-end, low-volume systems as well as low-end, high-volume systems.&lt;br /&gt;
*Addressing capability has no short term practical limits.&lt;br /&gt;
&lt;br /&gt;
#Coherent Memory System – For the purpose of reduction of Average Access Time to data, caches are becoming more important each day for microprocessors.&lt;br /&gt;
&lt;br /&gt;
#Interface Characteristics – This specifies a standard interface to an interconnect that makes several devices to be connected or attached together and to interoperate.&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Performance &amp;amp; Correctness (Coherence &amp;amp; Consistency) requirement for the protocol necessitates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
=== Need for Busy state ===&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In Origin, there are 3 busy states indicates that the directory has received the request but is waiting for completion hence another request for the same block won't be accepted.&lt;br /&gt;
# Busy read&lt;br /&gt;
# Busy read exclusive or upgrade&lt;br /&gt;
# Busy uncached read:  In case of DMA, if the memory block is being read, no other processor should be allowed to get write access to it.&lt;br /&gt;
&lt;br /&gt;
=== Poison state ===&lt;br /&gt;
&lt;br /&gt;
To improve locality, origin relies on page migration. Hardware keeps reference counts on each page. On every access of memory count is incremented and compared with home node. If count is more than programmable threshold, hardware interrupts one of the local processors to copy the page. Block transfer engine “poison” the source page. Subsequent accesses by other processors receive a bus error and that removes the TLB entry for that location, read the location from the page table &amp;amp; update the TLB with new location. This approach is called - “Lazy TLB shootdown” which reduces the overall cost of migrating memory and changing the virtual-to-physical address mappings.&lt;br /&gt;
&lt;br /&gt;
=== Additional states ===&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
The “fresh” state shows that memory still has an up-to-date copy of the block, even if the block        has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== 1 DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
3. The SGI Origin: A ccnuma Highly Scalable Server&lt;br /&gt;
 Laudon, J.; Lenoski, D.;&lt;br /&gt;
 Computer Architecture, 1997. Conference Proceedings. The 24th Annual International Symposium on&lt;br /&gt;
 June 2-4, 1997 Page(s):241 - 251 &lt;br /&gt;
&lt;br /&gt;
4. The Scalable Coherence Interface&lt;br /&gt;
 David.B.Gustavson&lt;br /&gt;
 September 1991&lt;br /&gt;
 &amp;quot;The Scalable Coherence Interface and related standard projects&amp;quot;&lt;br /&gt;
&lt;br /&gt;
5. An analysis of the Scalable Coherent Interface&lt;br /&gt;
 Eric Rotenberg&lt;br /&gt;
 June 1995&lt;br /&gt;
 An Analytical model of the SCI Coherence protocol&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
1. The Stanford Dash multiprocessor&lt;br /&gt;
 Lenoski, D.; Laudon, J.; Gharachorloo, K.; Weber, W.-D.; Gupta, A.; Hennessy, J.; Horowitz, M.; Lam, M.S.;&lt;br /&gt;
 Computer&lt;br /&gt;
 IEEE Volume 25,  Issue 3,  March 1992 Page(s):63 - 79&lt;br /&gt;
 Digital Object Identifier 10.1109/2.121510&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5910</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 8 38</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5910"/>
		<updated>2007-10-18T22:28:56Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* Scalable Coherent Interface (SCI) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
Goals of SCI&lt;br /&gt;
&lt;br /&gt;
High Performance – For distributed or parallel applications, high communication performance must be obtained when using SCI. Usual aspects of such performance would be a low latency, low CPU overhead for operations dealing with communication and high sustained throughput.&lt;br /&gt;
&lt;br /&gt;
Scalability – This is addressed in many ways. Some are&lt;br /&gt;
Performance scalability – as the number of nodes being added to the system increases.&lt;br /&gt;
*Interconnect Distance scalability&lt;br /&gt;
*Memory System scalability – chiefly of cache coherence protocols, which should not have limitations to the number of processors or modules in memory that it can handle.&lt;br /&gt;
*Technological scalability – utilization of similar mechanisms in large, small-scale, loosely-coupled or tightly-coupled systems. Also, when new advances are made in technology, it must have the ability to readily make use of such advances.&lt;br /&gt;
*Economic scalability – use of similar components and mechanisms in high-end, low-volume systems as well as low-end, high-volume systems.&lt;br /&gt;
*Addressing capability has no short term practical limits.&lt;br /&gt;
&lt;br /&gt;
Coherent Memory System – For the purpose of reduction of Average Access Time to data, caches are becoming more important each day for microprocessors.&lt;br /&gt;
&lt;br /&gt;
Interface Characteristics – This specifies a standard interface to an interconnect that makes several devices to be connected or attached together and to interoperate.&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Performance &amp;amp; Correctness (Coherence &amp;amp; Consistency) requirement for the protocol necessitates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
=== Need for Busy state ===&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In Origin, there are 3 busy states indicates that the directory has received the request but is waiting for completion hence another request for the same block won't be accepted.&lt;br /&gt;
# Busy read&lt;br /&gt;
# Busy read exclusive or upgrade&lt;br /&gt;
# Busy uncached read:  In case of DMA, if the memory block is being read, no other processor should be allowed to get write access to it.&lt;br /&gt;
&lt;br /&gt;
=== Poison state ===&lt;br /&gt;
&lt;br /&gt;
To improve locality, origin relies on page migration. Hardware keeps reference counts on each page. On every access of memory count is incremented and compared with home node. If count is more than programmable threshold, hardware interrupts one of the local processors to copy the page. Block transfer engine “poison” the source page. Subsequent accesses by other processors receive a bus error and that removes the TLB entry for that location, read the location from the page table &amp;amp; update the TLB with new location. This approach is called - “Lazy TLB shootdown” which reduces the overall cost of migrating memory and changing the virtual-to-physical address mappings.&lt;br /&gt;
&lt;br /&gt;
=== Additional states ===&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
The “fresh” state shows that memory still has an up-to-date copy of the block, even if the block        has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== 1 DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
3. The SGI Origin: A ccnuma Highly Scalable Server&lt;br /&gt;
 Laudon, J.; Lenoski, D.;&lt;br /&gt;
 Computer Architecture, 1997. Conference Proceedings. The 24th Annual International Symposium on&lt;br /&gt;
 June 2-4, 1997 Page(s):241 - 251 &lt;br /&gt;
&lt;br /&gt;
4. The Scalable Coherence Interface&lt;br /&gt;
 David.B.Gustavson&lt;br /&gt;
 September 1991&lt;br /&gt;
 &amp;quot;The Scalable Coherence Interface and related standard projects&amp;quot;&lt;br /&gt;
&lt;br /&gt;
5. An analysis of the Scalable Coherent Interface&lt;br /&gt;
 Eric Rotenberg&lt;br /&gt;
 June 1995&lt;br /&gt;
 An Analytical model of the SCI Coherence protocol&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
1. The Stanford Dash multiprocessor&lt;br /&gt;
 Lenoski, D.; Laudon, J.; Gharachorloo, K.; Weber, W.-D.; Gupta, A.; Hennessy, J.; Horowitz, M.; Lam, M.S.;&lt;br /&gt;
 Computer&lt;br /&gt;
 IEEE Volume 25,  Issue 3,  March 1992 Page(s):63 - 79&lt;br /&gt;
 Digital Object Identifier 10.1109/2.121510&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5909</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 8 38</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5909"/>
		<updated>2007-10-18T22:24:33Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* Scalable Coherent Interface (SCI) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
Goals of SCI&lt;br /&gt;
&lt;br /&gt;
High Performance – For distributed or parallel applications, high communication performance must be obtained when using SCI. Usual aspects of such performance would be a low latency, low CPU overhead for operations dealing with communication and high sustained throughput.&lt;br /&gt;
&lt;br /&gt;
Scalability – This is addressed in many ways. Some are&lt;br /&gt;
•Performance scalability – as the number of nodes being added to the system increases.&lt;br /&gt;
•Interconnect Distance scalability&lt;br /&gt;
•Memory System scalability – chiefly of cache coherence protocols, which should not have limitations to the number of processors or modules in memory that it can handle.&lt;br /&gt;
•Technological scalability – utilization of similar mechanisms in large, small-scale, loosely-coupled or tightly-coupled systems. Also, when new advances are made in technology, it must have the ability to readily make use of such advances.&lt;br /&gt;
•Economic scalability – use of similar components and mechanisms in high-end, low-volume systems as well as low-end, high-volume systems.&lt;br /&gt;
•Addressing capability has no short term practical limits.&lt;br /&gt;
&lt;br /&gt;
Coherent Memory System – For the purpose of reduction of Average Access Time to data, caches are becoming more important each day for microprocessors.&lt;br /&gt;
&lt;br /&gt;
Interface Characteristics – This specifies a standard interface to an interconnect that makes several devices to be connected or attached together and to interoperate.&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Performance &amp;amp; Correctness (Coherence &amp;amp; Consistency) requirement for the protocol necessitates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
=== Need for Busy state ===&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In Origin, there are 3 busy states indicates that the directory has received the request but is waiting for completion hence another request for the same block won't be accepted.&lt;br /&gt;
# Busy read&lt;br /&gt;
# Busy read exclusive or upgrade&lt;br /&gt;
# Busy uncached read:  In case of DMA, if the memory block is being read, no other processor should be allowed to get write access to it.&lt;br /&gt;
&lt;br /&gt;
=== Poison state ===&lt;br /&gt;
&lt;br /&gt;
To improve locality, origin relies on page migration. Hardware keeps reference counts on each page. On every access of memory count is incremented and compared with home node. If count is more than programmable threshold, hardware interrupts one of the local processors to copy the page. Block transfer engine “poison” the source page. Subsequent accesses by other processors receive a bus error and that removes the TLB entry for that location, read the location from the page table &amp;amp; update the TLB with new location. This approach is called - “Lazy TLB shootdown” which reduces the overall cost of migrating memory and changing the virtual-to-physical address mappings.&lt;br /&gt;
&lt;br /&gt;
=== Additional states ===&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
The “fresh” state shows that memory still has an up-to-date copy of the block, even if the block        has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== 1 DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
3. The SGI Origin: A ccnuma Highly Scalable Server&lt;br /&gt;
 Laudon, J.; Lenoski, D.;&lt;br /&gt;
 Computer Architecture, 1997. Conference Proceedings. The 24th Annual International Symposium on&lt;br /&gt;
 June 2-4, 1997 Page(s):241 - 251 &lt;br /&gt;
&lt;br /&gt;
4. The Scalable Coherence Interface&lt;br /&gt;
 David.B.Gustavson&lt;br /&gt;
 September 1991&lt;br /&gt;
 &amp;quot;The Scalable Coherence Interface and related standard projects&amp;quot;&lt;br /&gt;
&lt;br /&gt;
5. An analysis of the Scalable Coherent Interface&lt;br /&gt;
 Eric Rotenberg&lt;br /&gt;
 June 1995&lt;br /&gt;
 An Analytical model of the SCI Coherence protocol&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
1. The Stanford Dash multiprocessor&lt;br /&gt;
 Lenoski, D.; Laudon, J.; Gharachorloo, K.; Weber, W.-D.; Gupta, A.; Hennessy, J.; Horowitz, M.; Lam, M.S.;&lt;br /&gt;
 Computer&lt;br /&gt;
 IEEE Volume 25,  Issue 3,  March 1992 Page(s):63 - 79&lt;br /&gt;
 Digital Object Identifier 10.1109/2.121510&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5908</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 8 38</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5908"/>
		<updated>2007-10-18T22:23:46Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* Scalable Coherent Interface (SCI) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
Goals of SCI&lt;br /&gt;
&lt;br /&gt;
High Performance – For distributed or parallel applications, high communication performance must be obtained when using SCI. Usual aspects of such performance would be a low latency, low CPU overhead for operations dealing with communication and high sustained throughput.&lt;br /&gt;
&lt;br /&gt;
Scalability – This is addressed in many ways. Some are&lt;br /&gt;
•	Performance scalability – as the number of nodes being added to the system increases.&lt;br /&gt;
•	Interconnect Distance scalability&lt;br /&gt;
•	Memory System scalability – chiefly of cache coherence protocols, which should not have limitations to the number of processors or modules in memory that it can handle.&lt;br /&gt;
•	Technological scalability – utilization of similar mechanisms in large, small-scale, loosely-coupled or tightly-coupled systems. Also, when new advances are made in technology, it must have the ability to readily make use of such advances.&lt;br /&gt;
•	Economic scalability – use of similar components and mechanisms in high-end, low-volume systems as well as low-end, high-volume systems.&lt;br /&gt;
•	Addressing capability has no short term practical limits.&lt;br /&gt;
&lt;br /&gt;
Coherent Memory System – For the purpose of reduction of Average Access Time to data, caches are becoming more important each day for microprocessors.&lt;br /&gt;
&lt;br /&gt;
Interface Characteristics – This specifies a standard interface to an interconnect that makes several devices to be connected or attached together and to interoperate.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Performance &amp;amp; Correctness (Coherence &amp;amp; Consistency) requirement for the protocol necessitates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
=== Need for Busy state ===&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
In Origin, there are 3 busy states indicates that the directory has received the request but is waiting for completion hence another request for the same block won't be accepted.&lt;br /&gt;
# Busy read&lt;br /&gt;
# Busy read exclusive or upgrade&lt;br /&gt;
# Busy uncached read:  In case of DMA, if the memory block is being read, no other processor should be allowed to get write access to it.&lt;br /&gt;
&lt;br /&gt;
=== Poison state ===&lt;br /&gt;
&lt;br /&gt;
To improve locality, origin relies on page migration. Hardware keeps reference counts on each page. On every access of memory count is incremented and compared with home node. If count is more than programmable threshold, hardware interrupts one of the local processors to copy the page. Block transfer engine “poison” the source page. Subsequent accesses by other processors receive a bus error and that removes the TLB entry for that location, read the location from the page table &amp;amp; update the TLB with new location. This approach is called - “Lazy TLB shootdown” which reduces the overall cost of migrating memory and changing the virtual-to-physical address mappings.&lt;br /&gt;
&lt;br /&gt;
=== Additional states ===&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
The “fresh” state shows that memory still has an up-to-date copy of the block, even if the block        has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== 1 DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
3. The SGI Origin: A ccnuma Highly Scalable Server&lt;br /&gt;
 Laudon, J.; Lenoski, D.;&lt;br /&gt;
 Computer Architecture, 1997. Conference Proceedings. The 24th Annual International Symposium on&lt;br /&gt;
 June 2-4, 1997 Page(s):241 - 251 &lt;br /&gt;
&lt;br /&gt;
4. The Scalable Coherence Interface&lt;br /&gt;
 David.B.Gustavson&lt;br /&gt;
 September 1991&lt;br /&gt;
 &amp;quot;The Scalable Coherence Interface and related standard projects&amp;quot;&lt;br /&gt;
&lt;br /&gt;
5. An analysis of the Scalable Coherent Interface&lt;br /&gt;
 Eric Rotenberg&lt;br /&gt;
 June 1995&lt;br /&gt;
 An Analytical model of the SCI Coherence protocol&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
1. The Stanford Dash multiprocessor&lt;br /&gt;
 Lenoski, D.; Laudon, J.; Gharachorloo, K.; Weber, W.-D.; Gupta, A.; Hennessy, J.; Horowitz, M.; Lam, M.S.;&lt;br /&gt;
 Computer&lt;br /&gt;
 IEEE Volume 25,  Issue 3,  March 1992 Page(s):63 - 79&lt;br /&gt;
 Digital Object Identifier 10.1109/2.121510&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5884</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 8 38</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5884"/>
		<updated>2007-10-18T01:24:22Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* References */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Correctness (Coherence &amp;amp; Consistency) requirement necessiates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
The “fresh” state shows that memory still has an up-to-date copy of the block, even if the block        has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== 1 DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
3. The Scalable Coherence Interface&lt;br /&gt;
 David.B.Gustavson&lt;br /&gt;
 September 1991&lt;br /&gt;
 &amp;quot;The Scalable Coherence Interface and related standard projects&amp;quot;&lt;br /&gt;
&lt;br /&gt;
4. An analysis of the Scalable Coherent Interface&lt;br /&gt;
 Eric Rotenberg&lt;br /&gt;
 June 1995&lt;br /&gt;
 An Analytical model of the SCI Coherence protocol&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5850</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 8 38</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5850"/>
		<updated>2007-10-17T22:41:10Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* Why additional states are necessary? */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Correctness (Coherence &amp;amp; Consistency) requirement necessiates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
The “fresh” state shows that memory still has an up-to-date copy of the block, even if the block        has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== 1 DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5849</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 8 38</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5849"/>
		<updated>2007-10-17T22:34:15Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* Why additional states are necessary? */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Correctness (Coherence &amp;amp; Consistency) requirement necessiates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
 a. The “fresh” state shows that memory still has an up-to-date copy of the block, even if the         block has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
 b. The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== 1 DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5848</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 8 38</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5848"/>
		<updated>2007-10-17T22:33:21Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* Why additional states are necessary? */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Correctness (Coherence &amp;amp; Consistency) requirement necessiates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
    a. The “fresh” state shows that memory still has an up-to-date copy of the block, even if the         block has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
    b. The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== 1 DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5847</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 8 38</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5847"/>
		<updated>2007-10-17T22:32:06Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* Why additional states are necessary? */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
= Scalable Coherent Interface (SCI) =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
= Simple Scalable Coherent Interface (SSCI) =&lt;br /&gt;
&lt;br /&gt;
In directory-based approach, Every memory block has associated directory information; it keeps track of copies of cached blocks and their states. On a miss, it finds the directory entry, looks it up, and communicates only with the nodes that have copies (if necessary).&lt;br /&gt;
&lt;br /&gt;
There are mainly two approaches: Full-bit vector: For k processors, it maintains k presence bit and 1 dirty bit at the home node. Cache state is represented the same way as in bus-based designs (MSI, MESI, etc.). It has three cache states: EM (exclusive or modified), S (shared), U (unowned). Limitation is - Number of presence bits needed grows as the number of processors.&lt;br /&gt;
&lt;br /&gt;
Memory-based schemes store the information about all cached copies at the home node of the block. Cache-based schemes distribute information about copies among the copies themselves. The home contains a pointer to one cached copy of the block. Each copy contains the identity of the next node that has a copy of the block. The location of the copies is therefore determined through network transactions.&lt;br /&gt;
&lt;br /&gt;
Simple SCI (SSCI) retains similarity with full-bit vector protocol: MESI states in the cache; U, S, EM states in the memory directory; It replaces the presence bits with a pointer.&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
Correctness (Coherence &amp;amp; Consistency) requirement necessiates the additional states in the protocol.&lt;br /&gt;
&lt;br /&gt;
On a scalable multiprocessors without coherent caches, the main-memory module determined the ordering of writes. The order that writes become visible to all processors is the order in which they reached memory.&lt;br /&gt;
&lt;br /&gt;
e.g. If two processors issue read-exclusive requests for a particular word, the home will provide the requestors with the location of&lt;br /&gt;
the dirty node. But which request will reach the dirty node first cannot be guaranteed. This creates the need for additional busy state in the directory. &lt;br /&gt;
&lt;br /&gt;
This can be solved by &lt;br /&gt;
# holding requests at home or requestor node and serve them in the order of their arrival&lt;br /&gt;
# If the block is busy, reject any further request to it &amp;amp; that request will be retried later&lt;br /&gt;
# If directory is busy forward request to dirty node &amp;amp; dirty node will serialize the request execution&lt;br /&gt;
&lt;br /&gt;
In non-coherent scalable multiprocessors, &lt;br /&gt;
# For write atomicity in invalidation based protocol, current owner of block has to wait until it recieve all invalidation acks and then only it can read/write new value.&lt;br /&gt;
# For write completion, current owner of the block need to wait for ack from memory&lt;br /&gt;
&lt;br /&gt;
Additional states can be introduced into the sharing list. The SSCI protocol has only one kind of sharing list state : dirty. More options can be introduced into the list to improve performance of the overall shared multiprocessors. Although additional states do increment the complexity of the protocol being utilized and implemented, it would be very much beneficial to the system when the overall performance of the system is increased. The question “Why Additional States are necessary” is answered alongside the introduction of each new state i.e. explanation for the necessity of each and every state has been provided.&lt;br /&gt;
&lt;br /&gt;
Having the following states implemented in the protocol can improve performance.&lt;br /&gt;
&lt;br /&gt;
1. “fresh” and “gone” – Main memory may still be able to respond to a requesting processor if the memory can differentiate between ‘cached and unmodified’ and ‘cached and modified’. Even if the cached value is elsewhere, memory may still be able to respond to the request if the data remains unmodified.&lt;br /&gt;
&lt;br /&gt;
a. The “fresh” state shows that memory still has an up-to-date copy of the block, even if the block has been cached and is being shared between processors. As long as the value remains unmodified by any of the processors sharing the data, the memory can keep responding by returning the requested data to the requesting processor.&lt;br /&gt;
&lt;br /&gt;
b. The “gone” state indicates that the block has been cached and has been modified. This shows that main memory cant return the data anymore, but has to return the pointer that points to the head of the list.&lt;br /&gt;
&lt;br /&gt;
2. “clean lists” – Although the introduction of these states increase the complexity of handling each access, it does help with the overall performance. In this case, it may be helpful to differentiate the types of read accesses to the cache. One type of read access would be a ‘normal read-only’. Another type of read would be a ‘read with intent to modify later’. The memory in the state is ‘fresh’ when a read-fresh takes place. A read-clean leaves the memory in the ‘gone’ state. Just as with the dirty state, the read-clean allows a write to the block to proceed immediately. When a block is replaced in the cache and the cache is in the ‘clean’ state, no data needs to be written to memory. But with the dirty state, a write-back would be required even if the data had not been modified.&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
=== 1 DASH Cache Coherence Protocol ===&lt;br /&gt;
&lt;br /&gt;
DASH (Directory Architecture for SHared memory) is a scalable shared-memory multiprocessor currently being developed at Stanford’s Computer Systems Laboratory. DASH protocol uses point-to-point messages sent between the processors and memories to keep caches consistent.&lt;br /&gt;
&lt;br /&gt;
The DASH coherence protocol is an invalidation-based ownership protocol. A memory block can be in one of three states as indicated by the associated directory entry: (i) uncached-remote, that is not cached by any remote cluster; (ii) shared-remote, that is cached in an unmodified state by one or more remote clusters; or (iii) dirty-remote, that is cached in a modified state by a single remote cluster.&lt;br /&gt;
&lt;br /&gt;
Please see in the figures below: Left - Flow of Read Request to remote memory with directory in dirty-remote state. Right - Flow of Read-Exclusive Request to remote memory with directory in shared-remote state.&lt;br /&gt;
&lt;br /&gt;
[[Image:DASH.jpg]]&lt;br /&gt;
&lt;br /&gt;
Write back request: A dirty cache line that is replaced must be written back to memory. If the home of the memory block is the local cluster, then the data is simply written back to main memory. If the home cluster is remote, then a message is sent to the remote&lt;br /&gt;
home which updates the main memory and marks the block uncached-remote.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
1 The DASH Cache Coherence Protocol&lt;br /&gt;
 Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta, John Hennessy&lt;br /&gt;
 May 1990&lt;br /&gt;
 ACM SIGARCH Computer Architecture News , Proceedings of the 17th annual international symposium on Computer Architecture ISCA '90,&lt;br /&gt;
 Volume 18 Issue 3a&lt;br /&gt;
 Publisher: ACM Press&lt;br /&gt;
&lt;br /&gt;
2.  1596-1992 IEEE standard for scalable coherent interface (SCI).&lt;br /&gt;
 E-ISBN: 0-7381-1204-6&lt;br /&gt;
 Year: 1993&lt;br /&gt;
 Sponsored by: IEEE Computer Society&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5797</id>
		<title>CSC/ECE 506 Fall 2007/wiki3 8 38</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki3_8_38&amp;diff=5797"/>
		<updated>2007-10-17T18:21:02Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* SCI */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;''Wiki: SCI. The IEEE Scalable Coherent Interface is a superset of the SSCI protocol we have been considering in class. A lot has been written about it, but it is still difficult to comprehend. Using SSCI as a starting point, explain why additional states are necessary, and give (or cite) examples that demonstrate how they work. Ideally, this would still be an overview of the working of the protocol, referencing more detailed documentation on the Web.''&lt;br /&gt;
&lt;br /&gt;
__TOC__&lt;br /&gt;
&lt;br /&gt;
= Introduction =&lt;br /&gt;
&lt;br /&gt;
= SCI =&lt;br /&gt;
&lt;br /&gt;
The scalable coherent interface has now become a chief hardware based approach to the cache coherence problem in shared memory multiprocessors. SCI is a directory based invalidate coherence protocol. The state of a cache block is distributed to the sharers of that block. Limits that are inherent in bus technology are easily avoided by SCI. The SCI protocol is to provide scalability, coherence and an interface. Scalability is to guarantee that the same mechanisms can be used in single processor systems and large highly parallel multiprocessors. Coherence is to guarantee efficient and integral use of cache memories in distributed shared memory. An interface provides a communication architecture that has multiple values to be brought into a single system and provide smooth inter-operation.&lt;br /&gt;
&lt;br /&gt;
In SCI, every interface does not wait for the signal to propagate before it begins to send the next signal. Also, SCI utilizes multiple links so that, concurrently, several transfers can take place.&lt;br /&gt;
&lt;br /&gt;
Usually, a directory entry is in either of the two states : ‘home’ or ‘gone’. If the state is in ‘home’, then memory can immediately satisfy requests to a block as the block has not been cached by any processor. If the state is ‘gone’, then the block has been cached by a processor and might even be modified. Now, the directory contains a pointer to the first processor in the sharing list for this particular block. Hence, on requesting the data, memory returns the pointer to the first processor on the shared list rather than the data itself. The processor asking for the block now forwards its request to the processor on the top of the shared list. Now, the requesting processor adds itself into the shared list as the new head of the list.&lt;br /&gt;
&lt;br /&gt;
In the SCI protocol, any coherent transaction has three phases.&lt;br /&gt;
&lt;br /&gt;
Memory read – When a processor misses in its cache, It asks for the block in the home directory in memory. If the state of the memory is ‘home’, then the main memory replies with the block to the requesting processor. If the state is ‘gone’, then the main memory returns the head of the shared list of processors for that particular block. Then, memory updates its pointer and puts the requesting processor as the new head.&lt;br /&gt;
&lt;br /&gt;
Cache read – When memory returns a pointer toe the requesting processor instead of data, the processor forwards its request for the block to the head of the doubly linked list. When the cache receives, the head of the list returns the data which might have been modified. The head of the list changes its backward pointer to the requesting processor’s node. Now, the requesting processor becomes the head of the list and it has the cache block.&lt;br /&gt;
&lt;br /&gt;
Cleanup – If the cache miss from the requesting processor is a store, the processor has to first invalidate all other cached copies and then only proceed with the store. The new head gives an invalidate request to the next address on the list i.e. to its next processor. This processor invalidates and gives back a pointer to the next processor on its list. The head of the list uses this new pointer and sends it an invalidate request. This goes on until a NULL pointer is returned. This is the cleanup process for invalidation of other cache copies of the block.&lt;br /&gt;
&lt;br /&gt;
= SSCI =&lt;br /&gt;
&lt;br /&gt;
== Why additional states are necessary? ==&lt;br /&gt;
&lt;br /&gt;
== Examples ==&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&lt;br /&gt;
= Further reading =&lt;br /&gt;
&lt;br /&gt;
= External links =&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_10_aj&amp;diff=3286</id>
		<title>CSC/ECE 506 Fall 2007/wiki1 10 aj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_10_aj&amp;diff=3286"/>
		<updated>2007-09-10T21:55:39Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* Systolic Architecture */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''( Section 1.2.6)'''&lt;br /&gt;
&lt;br /&gt;
== New developments in dataflow and systolic architectures ==&lt;br /&gt;
&lt;br /&gt;
In the 1980s, a steady progress of parallel computing gave way for various unique parallel architectures that underwent extensive research but were not truly implemented to its full extent as when compared to architectures such as Shared Address Programming, Message Passing and Data Parallel Processing. Such architectures are still in its infancy and though its concepts have been utilized in various approaches for increasing processing efficiency; the actual architectural implementation is not widely employed for the sake of parallel computing.&lt;br /&gt;
&lt;br /&gt;
Two such architectures are Dataflow Architecture and Systolic Architecture.&lt;br /&gt;
&lt;br /&gt;
== Dataflow Architecture ==&lt;br /&gt;
&lt;br /&gt;
'''Developments in Dataflow Architecture'''&lt;br /&gt;
&lt;br /&gt;
(Reference: Based on ideas presented in the Wikipedia article at: http://en.wikipedia.org/wiki/Dataflow_architecture )&lt;br /&gt;
&lt;br /&gt;
Dataflow architectures (from a hardware standpoint) was an important research topic in the 1970s and early 1980s. Interest in the field has subsided in recent years due to the inability to resolve certain inherent problems in the Dataflow architectural model. To understand, this, the Dataflow concept is summarized below.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Summary of the Dataflow Idea'''&lt;br /&gt;
&lt;br /&gt;
In its essence, a Dataflow architecture executes instructions based on whether the input arguments to the instructions are available. There is no program counter as present in a Von Neumann computer. To indicate the dependency of instructions, tags were used. When the tags contained simple memory addresses, the design was a static Dataflow machine. However, static designs couldn’t allow for multiple instances of a routine. &lt;br /&gt;
&lt;br /&gt;
Dynamic Dataflow machines used Content-Addressable memory (CAM)(i.e. the tags were stored in memory) to solve this problem.&lt;br /&gt;
The programs were loaded in the CAM. When the tagged operands of an instruction became available, the CAM would send it to an '''execution unit'''. After execution, the output data and it’s tags were sent back to the CAM (as a '''data token'''). The CAM would then execute the next instruction whose dependencies had been satisfied.&lt;br /&gt;
&lt;br /&gt;
Since, the CAM could identify instructions whose tags were not dependant on any unexecuted instruction, parallelization was possible.&lt;br /&gt;
There were however, major problems related to -&lt;br /&gt;
&lt;br /&gt;
1) broadcasting the data tokens in a massively parallel system efficiently.&lt;br /&gt;
&lt;br /&gt;
2) dispatching instruction tokens in a massively parallel system efficiently.&lt;br /&gt;
&lt;br /&gt;
3) A real program had a huge number of dependencies. Building a CAM large enough for this proved difficult.&lt;br /&gt;
&lt;br /&gt;
Due to these issues, new developments in this area were largely stagnant.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''New Developments in the Dataflow Architectural Model'''&lt;br /&gt;
&lt;br /&gt;
(Referenced from: http://en.wikipedia.org/wiki/Out-of-order_execution)&lt;br /&gt;
1) A subset of the Dataflow model - '''Out of order execution''' is widely used in present day architecture. It uses the conventional Von Neumann Architecture to run '''Execution Windows''' in the usual order. Within the Window however, instructions are run according to the Dataflow Paradigm thus enabling parallelization and efficient utilization of CPU cycles.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
(Referenced form: http://wavescalar.cs.washington.edu/)&lt;br /&gt;
2)The WaveScalar Instruction Set Architecture and Execution Model, currently being developed at the University of Washington attempts at building an architectural model that can work with current Imperative languages.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
(Referenced from: http://portal.acm.org/citation.cfm?id=1032450 &amp;amp; http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&amp;amp;arnumber=1332593&amp;amp;isnumber=29428)&lt;br /&gt;
&lt;br /&gt;
3)Calstrom and Boden propose a '''packet instruction set computer (PISC) architecture''' which would employ dataflow architecture for network processors. They detailed a 40 gb/s network processor using Dataflow architecture.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
(Referenced from: http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel2/3036/8629/00379757.pdf?isnumber=&amp;amp;arnumber=379757)&lt;br /&gt;
4) Data flow architecture is also being evaluated for DSP processors as outlined in the referenced paper by Lee et al. Their proposed design was for a static Dataflow processor with 9 parallel processors for the multi-standard video codec processor.&lt;br /&gt;
&lt;br /&gt;
== Systolic Architecture ==&lt;br /&gt;
&lt;br /&gt;
'''Emergence of Systolic Arrays'''&lt;br /&gt;
&lt;br /&gt;
During the 1980s, tremendous technological advances were being made in the field of VLSI circuits, which led to the birth of several different concepts of highly parallel computing systems. One particular approach to such parallelism was using Systolic arrays, which constituted of a high number of processing elements known as cells, which were interconnected for local communication. This model utilizes a pipe-network arrangement of data processing units. Whenever a data object arrives, an operation is triggered in a data processing unit, unlike a central processing unit which has program counters. Several data streams are sent and received by a systolic array and several data counters are required to propagate data streams. This simple methodology facilitates parallelism.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Definition, Function and Applications'''&lt;br /&gt;
&lt;br /&gt;
They are called systolic arrays; because data, similar to human blood circulation, circulates within the array and also may interact with other data. Some results that have been computed in certain cells are pumped into new cells as input, similar to the heart (Hence the analogy to a systolic mechanism of parallelism). H. T. Kung and Charles E. Leiserson invented the concept of systolic arrays being utilized as agents for parallel processing.&lt;br /&gt;
&lt;br /&gt;
The Systolic Architecture is a mesh-like, interconnected set of processing elements, or cells, which interact with each other and pass on results that become inputs for the next computational time-step. Such proximity of high performance processors provide a highly required space efficiency, which is usually the main factor in parallel architecture. The structure of such systolic arrays may be non linear and multi-directional pathways may exist between processing elements. Even though this architecture is quite similar to Single-Instruction-Multiple-Data, unlike SIMD, each processing element is capable of processing a unique, different operation. The main feature of systolic architecture is that its highly specialized computations can be performed on simple parallel processors and localized communication patterns.&lt;br /&gt;
&lt;br /&gt;
The systolic array is an architectural concept that is highly suited for very high integration technology. Communication between these mesh-connected processors occurs only amongst neighbors. Both control and data flow are local. Each processor has a communication register that can be read by any of its neighbors.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A Systolic array is a network of processing elements that has features like&lt;br /&gt;
&lt;br /&gt;
• Modularity : each systolic array element is a module&lt;br /&gt;
&lt;br /&gt;
• Synchrony : a global clock times the data through the network&lt;br /&gt;
&lt;br /&gt;
• Locality (both spatial and temporal) : cells have local communication and a unit time delay&lt;br /&gt;
&lt;br /&gt;
• Regularity : processing elements are homogeneously interconnected&lt;br /&gt;
&lt;br /&gt;
• Parallel Computing and Pipelinability : architecture achieves high speed&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The two main Systolic Architectural Features are&lt;br /&gt;
&lt;br /&gt;
• Balancing Computation with I/O.&lt;br /&gt;
&lt;br /&gt;
• Concurrency and Communication.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
But other notable features of the architecture are its cost effectiveness, its regular &amp;amp; simple design, the modularity in arrays is quite high, the number of processors working simultaneously is high and also the local communication is fast – making overall execution time much faster.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''Types of Systolic Arrays''&lt;br /&gt;
&lt;br /&gt;
1.	Single Dimensional Input/Output Linear Array&lt;br /&gt;
        - This is usually utilized for single input/output&lt;br /&gt;
        [[Image:Systolic01.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
2.	Two Dimensional Input/Output Linear Array&lt;br /&gt;
        - This allows for more input/output and control over a linear array&lt;br /&gt;
        [[Image:Systolic02.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
3.	Perimeter Input/Output Planar Array&lt;br /&gt;
        - This topology allows input/output through its boundary or perimeter cells only&lt;br /&gt;
        [[Image:Systolic03.jpg]]&lt;br /&gt;
  &lt;br /&gt;
&lt;br /&gt;
4. 	Three Dimensional Input/Output Focal Plane Array&lt;br /&gt;
        - This facilitates input/output to each and every systolic cell in the array&lt;br /&gt;
        [[Image:Systolic04.jpg]]	 &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A few applications of Systolic Arrays&lt;br /&gt;
&lt;br /&gt;
•	Matrix Multiplication &lt;br /&gt;
&lt;br /&gt;
•	Solution of linear equations to problems in image processing&lt;br /&gt;
&lt;br /&gt;
•	Computer graphics&lt;br /&gt;
&lt;br /&gt;
•	Cryptography&lt;br /&gt;
&lt;br /&gt;
•	Computer tomography&lt;br /&gt;
&lt;br /&gt;
•	Matrix Inversion and Decomposition&lt;br /&gt;
&lt;br /&gt;
•	Convolution&lt;br /&gt;
&lt;br /&gt;
•	Polynomial Evaluation&lt;br /&gt;
&lt;br /&gt;
•	Lattice filters for seismic and speech signal processing&lt;br /&gt;
&lt;br /&gt;
•	Artificial Neural Networks&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
For a complete explanation on the invention of systolic arrays, utilize the following link : http://www.patentstorm.us/patents/4727503-fulltext.html&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''New Developments'''&lt;br /&gt;
&lt;br /&gt;
''iWarp''&lt;br /&gt;
&lt;br /&gt;
In 1989, the Intel Corporation launched the iWarp as a product and produced more than 1500 iWarp systems. The underlying architecture was based on systolic arrays and data streams being utilized for sending and receiving data between elements on the system. Even though the system was well suited for several applications, Intel stopped actively marketing the product in the mid-90s. It is still a useful tool for research in the parallel computing direction and it was one of the first successful steps towards true parallelism in the early ages of parallel computing.&lt;br /&gt;
&lt;br /&gt;
''Image Processing and Morphology''&lt;br /&gt;
&lt;br /&gt;
A two-dimensional systolic array consisting of cells can be implemented, based on parallel modules which provide internal pipeline operation where every cell can be configured according to a control word. Also, the array can be provided with a group of image buffers, that can reduce the number of accesses to data memory may also extend the array capabilities, allowing the possibility of chaining interconnection of multiple processing blocks.&lt;br /&gt;
&lt;br /&gt;
''Digital Signal Processors''&lt;br /&gt;
&lt;br /&gt;
Low cost, systolic architectural microprocessors utilizes a DSP systolic array, which makes it possible to build low cost ICs capable of providing high speed digital video services. This requires high processing capabilities, and parallelism is a requirement in such areas. Systolic architectures are better suited for such purposes as they are of much lower cost due to their space-efficiency and interconnectivity.&lt;br /&gt;
&lt;br /&gt;
''Tilera Tile64''&lt;br /&gt;
&lt;br /&gt;
Arranged in a two dimensional grid, the Tilera 64 is a tile that has 64 processing elements or cells which are interconnected through a five way switch and it provides a two level hierarchical cache. The architecture is completely based on systolic arrays and this sixty-four element multi-core processor is being released in September 2007. It is already predicted to be utilized extensively in the field of embedded systems for advanced networking, unified thread management, digital video, web services, etc.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Why Systolic Architecture has not truly evolved with time'''&lt;br /&gt;
(to the extent of other architectures, is because)&lt;br /&gt;
&lt;br /&gt;
1.	Global Synchronization takes more time due to signal delays within the network&lt;br /&gt;
&lt;br /&gt;
2.	Bandwidth requirements are tremendous for both processor and memory&lt;br /&gt;
&lt;br /&gt;
3.	Fault tolerance is very poor as interconnection protocols are lacking&lt;br /&gt;
&lt;br /&gt;
Also, a certain ‘parallel overhead’ point occurs in Systolic Arrays where beyond that point, adding more processors does not increase the efficiency of processing as it would normally be expected. There may even be a point beyond which adding more processors may lead to slower execution time for the architecture.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''References'''&lt;br /&gt;
&lt;br /&gt;
1. (Reference: Based on ideas presented in the Wikipedia article at:http://en.wikipedia.org/wiki/Systolic_array)&lt;br /&gt;
&lt;br /&gt;
2. Systolic Algorithms: Concepts, Synthesis and Evolution - Siang W.Song, University of Sau Paulo, Department Of Computer Science&lt;br /&gt;
http://citeseer.ist.psu.edu/cache/papers/cs/30734/http:zSzzSzwww.ime.usp.brzSz~songzSzpaperszSzcimpa.pdf/systolic-algorithms-concepts-synthesis.pdf&lt;br /&gt;
&lt;br /&gt;
3. Instruction Systolic Array (ISA) - H.W. Lang, FH Flensburg&lt;br /&gt;
http://www.iti.fh-flensburg.de/lang/papers/isa/isa1.htm&lt;br /&gt;
&lt;br /&gt;
4. Systolic Arrays : Patent Description&lt;br /&gt;
http://www.patentstorm.us/patents/4727503-fulltext.html&lt;br /&gt;
&lt;br /&gt;
5. iWarp&lt;br /&gt;
http://www.cs.cmu.edu/~iwarp/&lt;br /&gt;
&lt;br /&gt;
6. Tilera Tile64&lt;br /&gt;
http://www.tilera.com/products/processors.php&lt;br /&gt;
&lt;br /&gt;
7. FPGA-Based Customizable Systolic Architecture for Image Processing Applications : Proceedings of the 2005 International Conference on Reconfigurable Computing and FPGAs (ReConFig'05) on Reconfigurable Computing and FPGAs - Griselda Saldana, Miguel Arias-Estrada (IEEE Computer Society)&lt;br /&gt;
&lt;br /&gt;
8. Summary of Systolic Architectures (Slides) - Syeda Mohsina Afroze&lt;br /&gt;
http://web.cecs.pdx.edu/~mperkows/temp/May13/070-Systolic-Processors.pdf&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_10_aj&amp;diff=3045</id>
		<title>CSC/ECE 506 Fall 2007/wiki1 10 aj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_10_aj&amp;diff=3045"/>
		<updated>2007-09-06T02:58:02Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* Systolic Architecture */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''( Section 1.2.6)'''&lt;br /&gt;
&lt;br /&gt;
== New developments in dataflow and systolic architectures ==&lt;br /&gt;
&lt;br /&gt;
In the 1980s, a steady progress of parallel computing gave way for various unique parallel architectures that underwent extensive research but were not truly implemented to its full extent as when compared to architectures such as Shared Address Programming, Message Passing and Data Parallel Processing. Such architectures are still in its infancy and though its concepts have been utilized in various approaches for increasing processing efficiency; the actual architectural implementation is not widely employed for the sake of parallel computing.&lt;br /&gt;
&lt;br /&gt;
Two such architectures are Dataflow Architecture and Systolic Architecture.&lt;br /&gt;
&lt;br /&gt;
== Dataflow Architecture ==&lt;br /&gt;
&lt;br /&gt;
'''Developments in Dataflow Architecture'''&lt;br /&gt;
&lt;br /&gt;
(Reference: Based on ideas presented in the Wikipedia article at: http://en.wikipedia.org/wiki/Dataflow_architecture )&lt;br /&gt;
&lt;br /&gt;
Dataflow architectures (from a hardware standpoint) was an important research topic in the 1970s and early 1980s. Interest in the field has subsided in recent years due to the inability to resolve certain inherent problems in the Dataflow architectural model. To understand, this, the Dataflow concept is summarized below.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Summary of the Dataflow Idea'''&lt;br /&gt;
&lt;br /&gt;
In its essence, a Dataflow architecture executes instructions based on whether the input arguments to the instructions are available. There is no program counter as present in a Von Neumann computer. To indicate the dependency of instructions, tags were used. When the tags contained simple memory addresses, the design was a static Dataflow machine. However, static designs couldn’t allow for multiple instances of a routine. &lt;br /&gt;
&lt;br /&gt;
Dynamic Dataflow machines used Content-Addressable memory (CAM)(i.e. the tags were stored in memory) to solve this problem.&lt;br /&gt;
The programs were loaded in the CAM. When the tagged operands of an instruction became available, the CAM would send it to an '''execution unit'''. After execution, the output data and it’s tags were sent back to the CAM (as a '''data token'''). The CAM would then execute the next instruction whose dependencies had been satisfied.&lt;br /&gt;
&lt;br /&gt;
Since, the CAM could identify instructions whose tags were not dependant on any unexecuted instruction, parallelization was possible.&lt;br /&gt;
There were however, major problems related to -&lt;br /&gt;
&lt;br /&gt;
1) broadcasting the data tokens in a massively parallel system efficiently.&lt;br /&gt;
&lt;br /&gt;
2) dispatching instruction tokens in a massively parallel system efficiently.&lt;br /&gt;
&lt;br /&gt;
3) A real program had a huge number of dependencies. Building a CAM large enough for this proved difficult.&lt;br /&gt;
&lt;br /&gt;
Due to these issues, new developments in this area were largely stagnant.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''New Developments in the Dataflow Architectural Model'''&lt;br /&gt;
&lt;br /&gt;
(Referenced from: http://en.wikipedia.org/wiki/Out-of-order_execution)&lt;br /&gt;
1) A subset of the Dataflow model - '''Out of order execution''' is widely used in present day architecture. It uses the conventional Von Neumann Architecture to run '''Execution Windows''' in the usual order. Within the Window however, instructions are run according to the Dataflow Paradigm thus enabling parallelization and efficient utilization of CPU cycles.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
(Referenced form: http://wavescalar.cs.washington.edu/)&lt;br /&gt;
2)The WaveScalar Instruction Set Architecture and Execution Model, currently being developed at the University of Washington attempts at building an architectural model that can work with current Imperative languages.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
(Referenced from: http://portal.acm.org/citation.cfm?id=1032450 &amp;amp; http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&amp;amp;arnumber=1332593&amp;amp;isnumber=29428)&lt;br /&gt;
&lt;br /&gt;
3)Calstrom and Boden propose a '''packet instruction set computer (PISC) architecture''' which would employ dataflow architecture for network processors. They detailed a 40 gb/s network processor using Dataflow architecture.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
(Referenced from: http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel2/3036/8629/00379757.pdf?isnumber=&amp;amp;arnumber=379757)&lt;br /&gt;
4) Data flow architecture is also being evaluated for DSP processors as outlined in the referenced paper by Lee et al. Their proposed design was for a static Dataflow processor with 9 parallel processors for the multi-standard video codec processor.&lt;br /&gt;
&lt;br /&gt;
== Systolic Architecture ==&lt;br /&gt;
&lt;br /&gt;
'''Emergence of Systolic Arrays'''&lt;br /&gt;
&lt;br /&gt;
During the 1980s, tremendous technological advances were being made in the field of VLSI circuits, which led to the birth of a several different concepts of highly parallel computing systems. One particular approach to such parallelism was using Systolic arrays, which constituted of a high number of processing elements known as cells, which were interconnected for local communication. This model utilizes a pipe-network arrangement of data processing units. Whenever a data object arrives, an operation is triggered in a data processing unit, unlike a central processing unit which has program counters. Several data streams are sent and received by a systolic array and several data counters are required to propagate data streams. This simple methodology facilitates parallelism.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Definition, Function and Applications'''&lt;br /&gt;
&lt;br /&gt;
They are called systolic arrays; because data, similar to human blood circulation, circulates within the array and also may interact with other data. Some results that have been computed in certain cells are pumped into new cells as input, similar to the heart (Hence the analogy to a systolic mechanism of parallelism). H. T. Kung and Charles E. Leiserson invented the concept of systolic arrays being utilized as agents for parallel processing.&lt;br /&gt;
&lt;br /&gt;
The Systolic Architecture is a mesh-like, interconnected set of processing elements, or cells, which interact with each other and pass on results that become inputs for the next computational time-step. Such proximity of high performance processors provide a highly required space efficiency, which is usually the main factor in parallel architecture. The structure of such systolic arrays may be non linear and multi-directional pathways may exist between processing elements. Even though this architecture is quite similar to Single-Instruction-Multiple-Data, unlike SIMD, each processing element is capable of processing a unique, different operation. The main feature of systolic architecture is that its highly specialized computations can be performed on simple parallel processors and localized communication patterns.&lt;br /&gt;
&lt;br /&gt;
The systolic array is an architectural concept that is highly suited for very high integration technology. Communication between these mesh-connected processors occurs only amongst neighbors. Both control and data flow are local. Each processor has a communication register that can be read by any of its neighbors.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A Systolic array is a network of processing elements that has features like&lt;br /&gt;
&lt;br /&gt;
• Modularity : each systolic array element is a module&lt;br /&gt;
&lt;br /&gt;
• Synchrony : a global clock times the data through the network&lt;br /&gt;
&lt;br /&gt;
• Locality (both spatial and temporal) : cells have local communication and a unit time delay&lt;br /&gt;
&lt;br /&gt;
• Regularity : processing elements are homogeneously interconnected&lt;br /&gt;
&lt;br /&gt;
• Parallel Computing and Pipelinability : architecture achieves high speed&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The two main Systolic Architectural Features are&lt;br /&gt;
&lt;br /&gt;
• Balancing Computation with I/O.&lt;br /&gt;
&lt;br /&gt;
• Concurrency and Communication.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
But other notable features of the architecture are its cost effectiveness, its regular &amp;amp; simple design, the modularity in arrays is quite high, the number of processors working simultaneously is high and also the local communication is fast – making overall execution time much faster.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''Types of Systolic Arrays''&lt;br /&gt;
&lt;br /&gt;
1.	Single Dimensional Input/Output Linear Array&lt;br /&gt;
        - This is usually utilized for single input/output&lt;br /&gt;
        [[Image:Systolic01.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
2.	Two Dimensional Input/Output Linear Array&lt;br /&gt;
        - This allows for more input/output and control over a linear array&lt;br /&gt;
        [[Image:Systolic02.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
3.	Perimeter Input/Output Planar Array&lt;br /&gt;
        - This topology allows input/output through its boundary or perimeter cells only&lt;br /&gt;
        [[Image:Systolic03.jpg]]&lt;br /&gt;
  &lt;br /&gt;
&lt;br /&gt;
4. 	Three Dimensional Input/Output Focal Plane Array&lt;br /&gt;
        - This facilitates input/output to each and every systolic cell in the array&lt;br /&gt;
        [[Image:Systolic04.jpg]]	 &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A few applications of Systolic Arrays&lt;br /&gt;
&lt;br /&gt;
•	Matrix Multiplication &lt;br /&gt;
&lt;br /&gt;
•	Solution of linear equations to problems in image processing&lt;br /&gt;
&lt;br /&gt;
•	Computer graphics&lt;br /&gt;
&lt;br /&gt;
•	Cryptography&lt;br /&gt;
&lt;br /&gt;
•	Computer tomography&lt;br /&gt;
&lt;br /&gt;
•	Matrix Inversion and Decomposition&lt;br /&gt;
&lt;br /&gt;
•	Convolution&lt;br /&gt;
&lt;br /&gt;
•	Polynomial Evaluation&lt;br /&gt;
&lt;br /&gt;
•	Lattice filters for seismic and speech signal processing&lt;br /&gt;
&lt;br /&gt;
•	Artificial Neural Networks&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
For a complete explanation on the invention of systolic arrays, utilize the following link : http://www.patentstorm.us/patents/4727503-fulltext.html&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''New Developments'''&lt;br /&gt;
&lt;br /&gt;
''iWarp''&lt;br /&gt;
&lt;br /&gt;
In 1989, the Intel Corporation launched the iWarp as a product and produced more than 1500 iWarp systems. The underlying architecture was based on systolic arrays and data streams being utilized for sending and receiving data between elements on the system. Even though the system was well suited for several applications, Intel stopped actively marketing the product in the mid-90s. It is still a useful tool for research in the parallel computing direction and it was one of the first successful steps towards true parallelism in the early ages of parallel computing.&lt;br /&gt;
&lt;br /&gt;
''Image Processing and Morphology''&lt;br /&gt;
&lt;br /&gt;
A two-dimensional systolic array consisting of cells can be implemented, based on parallel modules which provide internal pipeline operation where every cell can be configured according to a control word. Also, the array can be provided with a group of image buffers, that can reduce the number of accesses to data memory may also extend the array capabilities, allowing the possibility of chaining interconnection of multiple processing blocks.&lt;br /&gt;
&lt;br /&gt;
''Digital Signal Processors''&lt;br /&gt;
&lt;br /&gt;
Low cost, systolic architectural microprocessors utilizes a DSP systolic array, which makes it possible to build low cost ICs capable of providing high speed digital video services. This requires high processing capabilities, and parallelism is a requirement in such areas. Systolic architectures are better suited for such purposes as they are of much lower cost due to their space-efficiency and interconnectivity.&lt;br /&gt;
&lt;br /&gt;
''Tilera Tile64''&lt;br /&gt;
&lt;br /&gt;
Arranged in a two dimensional grid, the Tilera 64 is a tile that has 64 processing elements or cells which are interconnected through a five way switch and it provides a two level hierarchical cache. The architecture is completely based on systolic arrays and this sixty-four element multi-core processor is being released in September 2007. It is already predicted to be utilized extensively in the field of embedded systems for advanced networking, unified thread management, digital video, web services, etc.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Why Systolic Architecture has not truly evolved with time'''&lt;br /&gt;
(to the extent of other architectures, is because)&lt;br /&gt;
&lt;br /&gt;
1.	Global Synchronization takes more time due to signal delays within the network&lt;br /&gt;
&lt;br /&gt;
2.	Bandwidth requirements are tremendous for both processor and memory&lt;br /&gt;
&lt;br /&gt;
3.	Fault tolerance is very poor as interconnection protocols are lacking&lt;br /&gt;
&lt;br /&gt;
Also, a certain ‘parallel overhead’ point occurs in Systolic Arrays where beyond that point, adding more processors does not increase the efficiency of processing as it would normally be expected. There may even be a point beyond which adding more processors may lead to slower execution time for the architecture.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''References'''&lt;br /&gt;
&lt;br /&gt;
1. (Reference: Based on ideas presented in the Wikipedia article at:http://en.wikipedia.org/wiki/Systolic_array)&lt;br /&gt;
&lt;br /&gt;
2. Systolic Algorithms: Concepts, Synthesis and Evolution - Siang W.Song, University of Sau Paulo, Department Of Computer Science&lt;br /&gt;
http://citeseer.ist.psu.edu/cache/papers/cs/30734/http:zSzzSzwww.ime.usp.brzSz~songzSzpaperszSzcimpa.pdf/systolic-algorithms-concepts-synthesis.pdf&lt;br /&gt;
&lt;br /&gt;
3. Instruction Systolic Array (ISA) - H.W. Lang, FH Flensburg&lt;br /&gt;
http://www.iti.fh-flensburg.de/lang/papers/isa/isa1.htm&lt;br /&gt;
&lt;br /&gt;
4. Systolic Arrays : Patent Description&lt;br /&gt;
http://www.patentstorm.us/patents/4727503-fulltext.html&lt;br /&gt;
&lt;br /&gt;
5. iWarp&lt;br /&gt;
http://www.cs.cmu.edu/~iwarp/&lt;br /&gt;
&lt;br /&gt;
6. Tilera Tile64&lt;br /&gt;
http://www.tilera.com/products/processors.php&lt;br /&gt;
&lt;br /&gt;
7. FPGA-Based Customizable Systolic Architecture for Image Processing Applications : Proceedings of the 2005 International Conference on Reconfigurable Computing and FPGAs (ReConFig'05) on Reconfigurable Computing and FPGAs - Griselda Saldana, Miguel Arias-Estrada (IEEE Computer Society)&lt;br /&gt;
&lt;br /&gt;
8. Summary of Systolic Architectures (Slides) - Syeda Mohsina Afroze&lt;br /&gt;
http://web.cecs.pdx.edu/~mperkows/temp/May13/070-Systolic-Processors.pdf&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_10_aj&amp;diff=3042</id>
		<title>CSC/ECE 506 Fall 2007/wiki1 10 aj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_10_aj&amp;diff=3042"/>
		<updated>2007-09-06T02:52:05Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* Systolic Architecture */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''( Section 1.2.6)'''&lt;br /&gt;
&lt;br /&gt;
== New developments in dataflow and systolic architectures ==&lt;br /&gt;
&lt;br /&gt;
In the 1980s, a steady progress of parallel computing gave way for various unique parallel architectures that underwent extensive research but were not truly implemented to its full extent as when compared to architectures such as Shared Address Programming, Message Passing and Data Parallel Processing. Such architectures are still in its infancy and though its concepts have been utilized in various approaches for increasing processing efficiency; the actual architectural implementation is not widely employed for the sake of parallel computing.&lt;br /&gt;
&lt;br /&gt;
Two such architectures are Dataflow Architecture and Systolic Architecture.&lt;br /&gt;
&lt;br /&gt;
== Dataflow Architecture ==&lt;br /&gt;
&lt;br /&gt;
'''Developments in Dataflow Architecture'''&lt;br /&gt;
&lt;br /&gt;
(Reference: Based on ideas presented in the Wikipedia article at: http://en.wikipedia.org/wiki/Dataflow_architecture )&lt;br /&gt;
&lt;br /&gt;
Dataflow architectures (from a hardware standpoint) was an important research topic in the 1970s and early 1980s. Interest in the field has subsided in recent years due to the inability to resolve certain inherent problems in the Dataflow architectural model. To understand, this, the Dataflow concept is summarized below.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Summary of the Dataflow Idea'''&lt;br /&gt;
&lt;br /&gt;
In its essence, a Dataflow architecture executes instructions based on whether the input arguments to the instructions are available. There is no program counter as present in a Von Neumann computer. To indicate the dependency of instructions, tags were used. When the tags contained simple memory addresses, the design was a static Dataflow machine. However, static designs couldn’t allow for multiple instances of a routine. &lt;br /&gt;
&lt;br /&gt;
Dynamic Dataflow machines used Content-Addressable memory (CAM)(i.e. the tags were stored in memory) to solve this problem.&lt;br /&gt;
The programs were loaded in the CAM. When the tagged operands of an instruction became available, the CAM would send it to an '''execution unit'''. After execution, the output data and it’s tags were sent back to the CAM (as a '''data token'''). The CAM would then execute the next instruction whose dependencies had been satisfied.&lt;br /&gt;
&lt;br /&gt;
Since, the CAM could identify instructions whose tags were not dependant on any unexecuted instruction, parallelization was possible.&lt;br /&gt;
There were however, major problems related to -&lt;br /&gt;
&lt;br /&gt;
1) broadcasting the data tokens in a massively parallel system efficiently.&lt;br /&gt;
&lt;br /&gt;
2) dispatching instruction tokens in a massively parallel system efficiently.&lt;br /&gt;
&lt;br /&gt;
3) A real program had a huge number of dependencies. Building a CAM large enough for this proved difficult.&lt;br /&gt;
&lt;br /&gt;
Due to these issues, new developments in this area were largely stagnant.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''New Developments in the Dataflow Architectural Model'''&lt;br /&gt;
&lt;br /&gt;
(Referenced from: http://en.wikipedia.org/wiki/Out-of-order_execution)&lt;br /&gt;
1) A subset of the Dataflow model - '''Out of order execution''' is widely used in present day architecture. It uses the conventional Von Neumann Architecture to run '''Execution Windows''' in the usual order. Within the Window however, instructions are run according to the Dataflow Paradigm thus enabling parallelization and efficient utilization of CPU cycles.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
(Referenced form: http://wavescalar.cs.washington.edu/)&lt;br /&gt;
2)The WaveScalar Instruction Set Architecture and Execution Model, currently being developed at the University of Washington attempts at building an architectural model that can work with current Imperative languages.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
(Referenced from: http://portal.acm.org/citation.cfm?id=1032450 &amp;amp; http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&amp;amp;arnumber=1332593&amp;amp;isnumber=29428)&lt;br /&gt;
&lt;br /&gt;
3)Calstrom and Boden propose a '''packet instruction set computer (PISC) architecture''' which would employ dataflow architecture for network processors. They detailed a 40 gb/s network processor using Dataflow architecture.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
(Referenced from: http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel2/3036/8629/00379757.pdf?isnumber=&amp;amp;arnumber=379757)&lt;br /&gt;
4) Data flow architecture is also being evaluated for DSP processors as outlined in the referenced paper by Lee et al. Their proposed design was for a static Dataflow processor with 9 parallel processors for the multi-standard video codec processor.&lt;br /&gt;
&lt;br /&gt;
== Systolic Architecture ==&lt;br /&gt;
&lt;br /&gt;
'''Emergence of Systolic Arrays'''&lt;br /&gt;
&lt;br /&gt;
During the 1980s, tremendous technological advances were being made in the field of VLSI circuits, which led to the birth of a several different concepts of highly parallel computing systems. One particular approach to such parallelism was using Systolic arrays, which constituted of a high number of processing elements known as cells, which were interconnected for local communication. This model utilizes a pipe-network arrangement of data processing units. Whenever a data object arrives, an operation is triggered in a data processing unit, unlike a central processing unit which has program counters. Several data streams are sent and received by a systolic array and several data counters are required to propagate data streams. This simple methodology facilitates parallelism.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Definition, Function and Applications'''&lt;br /&gt;
&lt;br /&gt;
They are called systolic arrays; because data, similar to human blood circulation, circulates within the array and also may interact with other data. Some results that have been computed in certain cells are pumped into new cells as input, similar to the heart (Hence the analogy to a systolic mechanism of parallelism). H. T. Kung and Charles E. Leiserson invented the concept of systolic arrays being utilized as agents for parallel processing.&lt;br /&gt;
&lt;br /&gt;
The Systolic Architecture is a mesh-like, interconnected set of processing elements, or cells, which interact with each other and pass on results that become inputs for the next computational time-step. Such proximity of high performance processors provide a highly required space efficiency, which is usually the main factor in parallel architecture. The structure of such systolic arrays may be non linear and multi-directional pathways may exist between processing elements. Even though this architecture is quite similar to Single-Instruction-Multiple-Data, unlike SIMD, each processing element is capable of processing a unique, different operation. The main feature of systolic architecture is that its highly specialized computations can be performed on simple parallel processors and localized communication patterns.&lt;br /&gt;
&lt;br /&gt;
The systolic array is an architectural concept that is highly suited for very high integration technology. Communication between these mesh-connected processors occurs only amongst neighbors. Both control and data flow are local. Each processor has a communication register that can be read by any of its neighbors.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A Systolic array is a network of processing elements that has features like&lt;br /&gt;
&lt;br /&gt;
• Modularity : each systolic array element is a module&lt;br /&gt;
&lt;br /&gt;
• Synchrony : a global clock times the data through the network&lt;br /&gt;
&lt;br /&gt;
• Locality (both spatial and temporal) : cells have local communication and a unit time delay&lt;br /&gt;
&lt;br /&gt;
• Regularity : processing elements are homogeneously interconnected&lt;br /&gt;
&lt;br /&gt;
• Parallel Computing and Pipelinability : architecture achieves high speed&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The two main Systolic Architectural Features are&lt;br /&gt;
&lt;br /&gt;
• Balancing Computation with I/O.&lt;br /&gt;
&lt;br /&gt;
• Concurrency and Communication.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
But other notable features of the architecture are its cost effectiveness, its regular &amp;amp; simple design, the modularity in arrays is quite high, the number of processors working simultaneously is high and also the local communication is fast – making overall execution time much faster.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''Types of Systolic Arrays''&lt;br /&gt;
&lt;br /&gt;
1.	Single Dimensional Input/Output Linear Array&lt;br /&gt;
        - This is usually utilized for single input/output&lt;br /&gt;
        [[Image:Systolic01.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
2.	Two Dimensional Input/Output Linear Array&lt;br /&gt;
        - This allows for more input/output and control over a linear array&lt;br /&gt;
        [[Image:Systolic02.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
3.	Perimeter Input/Output Planar Array&lt;br /&gt;
        - This topology allows input/output through its boundary or perimeter cells only&lt;br /&gt;
        [[Image:Systolic03.jpg]]&lt;br /&gt;
  &lt;br /&gt;
&lt;br /&gt;
4. 	Three Dimensional Input/Output Focal Plane Array&lt;br /&gt;
        - This facilitates input/output to each and every systolic cell in the array&lt;br /&gt;
        [[Image:Systolic04.jpg]]	 &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A few applications of Systolic Arrays&lt;br /&gt;
&lt;br /&gt;
•	Matrix Multiplication &lt;br /&gt;
&lt;br /&gt;
•	Solution of linear equations to problems in image processing&lt;br /&gt;
&lt;br /&gt;
•	Computer graphics&lt;br /&gt;
&lt;br /&gt;
•	Cryptography&lt;br /&gt;
&lt;br /&gt;
•	Computer tomography&lt;br /&gt;
&lt;br /&gt;
•	Matrix Inversion and Decomposition&lt;br /&gt;
&lt;br /&gt;
•	Convolution&lt;br /&gt;
&lt;br /&gt;
•	Polynomial Evaluation&lt;br /&gt;
&lt;br /&gt;
•	Lattice filters for seismic and speech signal processing&lt;br /&gt;
&lt;br /&gt;
•	Artificial Neural Networks&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
For a complete explanation on the invention of systolic arrays, utilize the following link : http://www.patentstorm.us/patents/4727503-fulltext.html&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''New Developments'''&lt;br /&gt;
&lt;br /&gt;
''iWarp''&lt;br /&gt;
&lt;br /&gt;
In 1989, the Intel Corporation launched the iWarp as a product and produced more than 1500 iWarp systems. The underlying architecture was based on systolic arrays and data streams being utilized for sending and receiving data between elements on the system. Even though the system was well suited for several applications, Intel stopped actively marketing the product in the mid-90s. It is still a useful tool for research in the parallel computing direction and it was one of the first successful steps towards true parallelism in the early ages of parallel computing.&lt;br /&gt;
&lt;br /&gt;
''Image Processing and Morphology''&lt;br /&gt;
&lt;br /&gt;
A two-dimensional systolic array consisting of cells can be implemented, based on parallel modules which provide internal pipeline operation where every cell can be configured according to a control word. Also, the array can be provided with a group of image buffers, that can reduce the number of accesses to data memory may also extend the array capabilities, allowing the possibility of chaining interconnection of multiple processing blocks.&lt;br /&gt;
&lt;br /&gt;
''Digital Signal Processors''&lt;br /&gt;
&lt;br /&gt;
Low cost, systolic architectural microprocessors utilizes a DSP systolic array, which makes it possible to build low cost ICs capable of providing high speed digital video services. This requires high processing capabilities, and parallelism is a requirement in such areas. Systolic architectures are better suited for such purposes as they are of much lower cost due to their space-efficiency and interconnectivity.&lt;br /&gt;
&lt;br /&gt;
''Tilera Tile64''&lt;br /&gt;
&lt;br /&gt;
Arranged in a two dimensional grid, the Tilera 64 is a tile that has 64 processing elements or cells which are interconnected through a five way switch and it provides a two level hierarchical cache. The architecture is completely based on systolic arrays and this sixty-four element multi-core processor is being released in September 2007. It is already predicted to be utilized extensively in the field of embedded systems for advanced networking, unified thread management, digital video, web services, etc.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Why Systolic Architecture has not truly evolved with time'''&lt;br /&gt;
(to the extent of other architectures, is because)&lt;br /&gt;
&lt;br /&gt;
1.	Global Synchronization takes more time due to signal delays within the network&lt;br /&gt;
&lt;br /&gt;
2.	Bandwidth requirements are tremendous for both processor and memory&lt;br /&gt;
&lt;br /&gt;
3.	Fault tolerance is very poor due as interconnection protocols are lacking&lt;br /&gt;
&lt;br /&gt;
Also, a certain ‘parallel overhead’ point occurs in Systolic Arrays where beyond that point, adding more processors does not increase the efficiency of processing as it would normally be expected. There may even be a point beyond which adding more processors may even lead to slower execution time for the architecture.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''References'''&lt;br /&gt;
&lt;br /&gt;
1. (Reference: Based on ideas presented in the Wikipedia article at:http://en.wikipedia.org/wiki/Systolic_array)&lt;br /&gt;
&lt;br /&gt;
2. Systolic Algorithms: Concepts, Synthesis and Evolution - Siang W.Song, University of Sau Paulo, Department Of Computer Science&lt;br /&gt;
http://citeseer.ist.psu.edu/cache/papers/cs/30734/http:zSzzSzwww.ime.usp.brzSz~songzSzpaperszSzcimpa.pdf/systolic-algorithms-concepts-synthesis.pdf&lt;br /&gt;
&lt;br /&gt;
3. Instruction Systolic Array (ISA) - H.W. Lang, FH Flensburg&lt;br /&gt;
http://www.iti.fh-flensburg.de/lang/papers/isa/isa1.htm&lt;br /&gt;
&lt;br /&gt;
4. Systolic Arrays : Patent Description&lt;br /&gt;
http://www.patentstorm.us/patents/4727503-fulltext.html&lt;br /&gt;
&lt;br /&gt;
5. iWarp&lt;br /&gt;
http://www.cs.cmu.edu/~iwarp/&lt;br /&gt;
&lt;br /&gt;
6. Tilera Tile64&lt;br /&gt;
http://www.tilera.com/products/processors.php&lt;br /&gt;
&lt;br /&gt;
7. FPGA-Based Customizable Systolic Architecture for Image Processing Applications : Proceedings of the 2005 International Conference on Reconfigurable Computing and FPGAs (ReConFig'05) on Reconfigurable Computing and FPGAs - Griselda Saldana, Miguel Arias-Estrada (IEEE Computer Society)&lt;br /&gt;
&lt;br /&gt;
8. Summary of Systolic Architectures (Slides) - Syeda Mohsina Afroze&lt;br /&gt;
http://web.cecs.pdx.edu/~mperkows/temp/May13/070-Systolic-Processors.pdf&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_10_aj&amp;diff=3034</id>
		<title>CSC/ECE 506 Fall 2007/wiki1 10 aj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_10_aj&amp;diff=3034"/>
		<updated>2007-09-06T02:45:56Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* Systolic Architecture */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''( Section 1.2.6)'''&lt;br /&gt;
&lt;br /&gt;
== New developments in dataflow and systolic architectures ==&lt;br /&gt;
&lt;br /&gt;
In the 1980s, a steady progress of parallel computing gave way for various unique parallel architectures that underwent extensive research but were not truly implemented to its full extent as when compared to architectures such as Shared Address Programming, Message Passing and Data Parallel Processing. Such architectures are still in its infancy and though its concepts have been utilized in various approaches for increasing processing efficiency; the actual architectural implementation is not widely employed for the sake of parallel computing.&lt;br /&gt;
&lt;br /&gt;
Two such architectures are Dataflow Architecture and Systolic Architecture.&lt;br /&gt;
&lt;br /&gt;
== Dataflow Architecture ==&lt;br /&gt;
&lt;br /&gt;
'''Developments in Dataflow Architecture'''&lt;br /&gt;
&lt;br /&gt;
(Reference: Based on ideas presented in the Wikipedia article at: http://en.wikipedia.org/wiki/Dataflow_architecture )&lt;br /&gt;
&lt;br /&gt;
Dataflow architectures (from a hardware standpoint) was an important research topic in the 1970s and early 1980s. Interest in the field has subsided in recent years due to the inability to resolve certain inherent problems in the Dataflow architectural model. To understand, this, the Dataflow concept is summarized below.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Summary of the Dataflow Idea'''&lt;br /&gt;
&lt;br /&gt;
In its essence, a Dataflow architecture executes instructions based on whether the input arguments to the instructions are available. There is no program counter as present in a Von Neumann computer. To indicate the dependency of instructions, tags were used. When the tags contained simple memory addresses, the design was a static Dataflow machine. However, static designs couldn’t allow for multiple instances of a routine. &lt;br /&gt;
&lt;br /&gt;
Dynamic Dataflow machines used Content-Addressable memory (CAM)(i.e. the tags were stored in memory) to solve this problem.&lt;br /&gt;
The programs were loaded in the CAM. When the tagged operands of an instruction became available, the CAM would send it to an '''execution unit'''. After execution, the output data and it’s tags were sent back to the CAM (as a '''data token'''). The CAM would then execute the next instruction whose dependencies had been satisfied.&lt;br /&gt;
&lt;br /&gt;
Since, the CAM could identify instructions whose tags were not dependant on any unexecuted instruction, parallelization was possible.&lt;br /&gt;
There were however, major problems related to -&lt;br /&gt;
&lt;br /&gt;
1) broadcasting the data tokens in a massively parallel system efficiently.&lt;br /&gt;
&lt;br /&gt;
2) dispatching instruction tokens in a massively parallel system efficiently.&lt;br /&gt;
&lt;br /&gt;
3) A real program had a huge number of dependencies. Building a CAM large enough for this proved difficult.&lt;br /&gt;
&lt;br /&gt;
Due to these issues, new developments in this area were largely stagnant.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''New Developments in the Dataflow Architectural Model'''&lt;br /&gt;
&lt;br /&gt;
(Referenced from: http://en.wikipedia.org/wiki/Out-of-order_execution)&lt;br /&gt;
1) A subset of the Dataflow model - '''Out of order execution''' is widely used in present day architecture. It uses the conventional Von Neumann Architecture to run '''Execution Windows''' in the usual order. Within the Window however, instructions are run according to the Dataflow Paradigm thus enabling parallelization and efficient utilization of CPU cycles.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
(Referenced form: http://wavescalar.cs.washington.edu/)&lt;br /&gt;
2)The WaveScalar Instruction Set Architecture and Execution Model, currently being developed at the University of Washington attempts at building an architectural model that can work with current Imperative languages.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
(Referenced from: http://portal.acm.org/citation.cfm?id=1032450 &amp;amp; http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&amp;amp;arnumber=1332593&amp;amp;isnumber=29428)&lt;br /&gt;
&lt;br /&gt;
3)Calstrom and Boden propose a '''packet instruction set computer (PISC) architecture''' which would employ dataflow architecture for network processors. They detailed a 40 gb/s network processor using Dataflow architecture.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
(Referenced from: http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel2/3036/8629/00379757.pdf?isnumber=&amp;amp;arnumber=379757)&lt;br /&gt;
4) Data flow architecture is also being evaluated for DSP processors as outlined in the referenced paper by Lee et al. Their proposed design was for a static Dataflow processor with 9 parallel processors for the multi-standard video codec processor.&lt;br /&gt;
&lt;br /&gt;
== Systolic Architecture ==&lt;br /&gt;
&lt;br /&gt;
'''Emergence of Systolic Arrays'''&lt;br /&gt;
&lt;br /&gt;
During the 1980s, tremendous technological advances were being made in the field of VLSI circuits, which led to the birth of a several different concepts of highly parallel computing systems. One particular approach to such parallelism was using Systolic arrays, which constituted of a high number of processing elements known as cells, which were interconnected for local communication. This model utilizes a pipe-network arrangement of data processing units. Whenever a data object arrives, an operation is triggered in a data processing unit, unlike a central processing unit which has program counters. Several data streams are sent and received by a systolic array and several data counters are required to propagate data streams. This simple methodology facilitates parallelism.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Definition, Function and Applications'''&lt;br /&gt;
&lt;br /&gt;
They are called systolic arrays; because data, similar to human blood circulation, circulates within the array and also may interact with other data. Some results that have been computed in certain cells are pumped into new cells as input, similar to the heart (Hence the analogy to a systolic mechanism of parallelism). H. T. Kung and Charles E. Leiserson invented the concept of systolic arrays being utilized as agents for parallel processing.&lt;br /&gt;
&lt;br /&gt;
The Systolic Architecture is a mesh-like, interconnected set of processing elements, or cells, which interact with each other and pass on results that become inputs for the next computational time-step. Such proximity of high performance processors provide a highly required space efficiency, which is usually the main factor in parallel architecture. The structure of such systolic arrays may be non linear and multi-directional pathways may exist between processing elements. Even though this architecture is quite similar to Single-Instruction-Multiple-Data, unlike SIMD, each processing element is capable of processing a unique, different operation. The main feature of systolic architecture is that its highly specialized computations can be performed on simple parallel processors and localized communication patterns.&lt;br /&gt;
&lt;br /&gt;
The systolic array is an architectural concept that is highly suited for very high integration technology. Communication between these mesh-connected processors occurs only amongst neighbors. Both control and data flow are local. Each processor has a communication register that can be read by any of its neighbors.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A Systolic array is a network of processing elements that has features like&lt;br /&gt;
&lt;br /&gt;
• Modularity : each systolic array element is a module&lt;br /&gt;
&lt;br /&gt;
• Synchrony : a global clock times the data through the network&lt;br /&gt;
&lt;br /&gt;
• Locality (both spatial and temporal) : cells have local communication and a unit time delay&lt;br /&gt;
&lt;br /&gt;
• Regularity : processing elements are homogeneously interconnected&lt;br /&gt;
&lt;br /&gt;
• Parallel Computing and Pipelinability : architecture achieves high speed&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The two main Systolic Architectural Features are&lt;br /&gt;
&lt;br /&gt;
• Balancing Computation with I/O.&lt;br /&gt;
&lt;br /&gt;
• Concurrency and Communication.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
But other notable features of the architecture are its cost effectiveness, its regular &amp;amp; simple design, the modularity in arrays is quite high, the number of processors working simultaneously is high and also the local communication is fast – making overall execution time much faster.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''Types of Systolic Arrays''&lt;br /&gt;
&lt;br /&gt;
1.	Single Dimensional Input/Output Linear Array&lt;br /&gt;
        - This is usually utilized for single input/output&lt;br /&gt;
        [[Image:Systolic01.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
2.	Two Dimensional Input/Output Linear Array&lt;br /&gt;
        - This allows for more input/output and control over a linear array&lt;br /&gt;
        [[Image:Systolic02.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
3.	Perimeter Input/Output Planar Array&lt;br /&gt;
        - This topology allows input/output through its boundary or perimeter cells only&lt;br /&gt;
        [[Image:Systolic03.jpg]]&lt;br /&gt;
  &lt;br /&gt;
&lt;br /&gt;
4. 	Three Dimensional Input/Output Focal Plane Array&lt;br /&gt;
        - This facilitates input/output to each and every systolic cell in the array&lt;br /&gt;
        [[Image:Systolic04.jpg]]	 &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A few applications of Systolic Arrays&lt;br /&gt;
&lt;br /&gt;
•	Matrix Multiplication &lt;br /&gt;
&lt;br /&gt;
•	Solution of linear equations to problems in image processing&lt;br /&gt;
&lt;br /&gt;
•	Computer graphics&lt;br /&gt;
&lt;br /&gt;
•	Cryptography&lt;br /&gt;
&lt;br /&gt;
•	Computer tomography&lt;br /&gt;
&lt;br /&gt;
•	Matrix Inversion and Decomposition&lt;br /&gt;
&lt;br /&gt;
•	Convolution&lt;br /&gt;
&lt;br /&gt;
•	Polynomial Evaluation&lt;br /&gt;
&lt;br /&gt;
•	Lattice filters for seismic and speech signal processing&lt;br /&gt;
&lt;br /&gt;
•	Artificial Neural Networks&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
For a complete explanation on the invention of systolic arrays, utilize the following link : http://www.patentstorm.us/patents/4727503-fulltext.html&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''New Developments'''&lt;br /&gt;
&lt;br /&gt;
''iWarp''&lt;br /&gt;
&lt;br /&gt;
In 1989, the Intel Corporation launched the iWarp as a product and produced more than 1500 iWarp systems. The underlying architecture was based on systolic arrays and data streams being utilized for sending and receiving data between elements on the system. Even though the system was well suited for several applications, Intel stopped actively marketing the product in the mid-90s. It is still a useful tool for research in the parallel computing direction and it was one of the first successful steps towards true parallelism in the early ages of parallel computing.&lt;br /&gt;
&lt;br /&gt;
''Image Processing and Morphology''&lt;br /&gt;
&lt;br /&gt;
A two-dimensional systolic array consisting of cells can be implemented, based on parallel modules which provide internal pipeline operation where every cell can be configured according to a control word. Also, the array can be provided with a group of image buffers, that can reduce the number of accesses to data memory may also extend the array capabilities, allowing the possibility of chaining interconnection of multiple processing blocks.&lt;br /&gt;
&lt;br /&gt;
''Digital Signal Processors''&lt;br /&gt;
&lt;br /&gt;
Low cost, systolic architectural microprocessors utilizes a DSP systolic array, which makes it possible to build low cost ICs capable of providing high speed digital video services. This requires high processing capabilities, and parallelism is a requirement in such areas. Systolic architectures are better suited for such purposes as they are of much lower cost due to their space-efficiency and interconnectivity.&lt;br /&gt;
&lt;br /&gt;
''Tilera Tile64''&lt;br /&gt;
&lt;br /&gt;
Arranged in a two dimensional grid, the Tilera 64 is a tile that has 64 processing elements or cells which are interconnected through a five way switch and it provides a two level hierarchical cache. The architecture is completely based on systolic arrays and this sixty-four element multi-core processor is being released in September 2007. It is already predicted to be utilized extensively in the field of embedded systems for advanced networking, unified thread management, digital video, web services, etc.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Why Systolic Architecture has not truly evolved with time'''&lt;br /&gt;
(to the extent of other architectures, is because)&lt;br /&gt;
&lt;br /&gt;
1.	Global Synchronization takes more time due to signal delays within the network&lt;br /&gt;
&lt;br /&gt;
2.	Bandwidth requirements are tremendous for both processor and memory&lt;br /&gt;
&lt;br /&gt;
3.	Fault tolerance is very poor due as interconnection protocols are lacking&lt;br /&gt;
&lt;br /&gt;
Also, a certain ‘parallel overhead’ point occurs in Systolic Arrays where beyond that point, adding more processors does not increase the efficiency of processing as it would normally be expected. There may even be a point beyond which adding more processors may even lead to slower execution time for the architecture.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''References'''&lt;br /&gt;
&lt;br /&gt;
1. (Reference: Based on ideas presented in the Wikipedia article at:http://en.wikipedia.org/wiki/Systolic_array)&lt;br /&gt;
&lt;br /&gt;
2. Systolic Algorithms: Concepts, Synthesis and Evolution - Siang W.Song, University of Sau Paulo, Department Of Computer Science&lt;br /&gt;
http://citeseer.ist.psu.edu/cache/papers/cs/30734/http:zSzzSzwww.ime.usp.brzSz~songzSzpaperszSzcimpa.pdf/systolic-algorithms-concepts-synthesis.pdf&lt;br /&gt;
&lt;br /&gt;
3. Instruction Systolic Array (ISA) - H.W. Lang, FH Flensburg&lt;br /&gt;
http://www.iti.fh-flensburg.de/lang/papers/isa/isa1.htm&lt;br /&gt;
&lt;br /&gt;
4. Systolic Arrays : Patent Description&lt;br /&gt;
http://www.patentstorm.us/patents/4727503-fulltext.html&lt;br /&gt;
&lt;br /&gt;
5. iWarp&lt;br /&gt;
http://www.cs.cmu.edu/~iwarp/&lt;br /&gt;
&lt;br /&gt;
6. Tilera Tile64&lt;br /&gt;
http://www.tilera.com/products/processors.php&lt;br /&gt;
&lt;br /&gt;
7. FPGA-Based Customizable Systolic Architecture for Image Processing Applications : Proceedings of the 2005 International Conference on Reconfigurable Computing and FPGAs (ReConFig'05) on Reconfigurable Computing and FPGAs - Griselda Saldana, Miguel Arias-Estrada (IEEE Computer Society)&lt;br /&gt;
&lt;br /&gt;
8. Summary of Systolic Architectures (Slides)&lt;br /&gt;
http://web.cecs.pdx.edu/~mperkows/temp/May13/070-Systolic-Processors.pdf&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_10_aj&amp;diff=3033</id>
		<title>CSC/ECE 506 Fall 2007/wiki1 10 aj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_10_aj&amp;diff=3033"/>
		<updated>2007-09-06T02:45:14Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* Systolic Architecture */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''( Section 1.2.6)'''&lt;br /&gt;
&lt;br /&gt;
== New developments in dataflow and systolic architectures ==&lt;br /&gt;
&lt;br /&gt;
In the 1980s, a steady progress of parallel computing gave way for various unique parallel architectures that underwent extensive research but were not truly implemented to its full extent as when compared to architectures such as Shared Address Programming, Message Passing and Data Parallel Processing. Such architectures are still in its infancy and though its concepts have been utilized in various approaches for increasing processing efficiency; the actual architectural implementation is not widely employed for the sake of parallel computing.&lt;br /&gt;
&lt;br /&gt;
Two such architectures are Dataflow Architecture and Systolic Architecture.&lt;br /&gt;
&lt;br /&gt;
== Dataflow Architecture ==&lt;br /&gt;
&lt;br /&gt;
'''Developments in Dataflow Architecture'''&lt;br /&gt;
&lt;br /&gt;
(Reference: Based on ideas presented in the Wikipedia article at: http://en.wikipedia.org/wiki/Dataflow_architecture )&lt;br /&gt;
&lt;br /&gt;
Dataflow architectures (from a hardware standpoint) was an important research topic in the 1970s and early 1980s. Interest in the field has subsided in recent years due to the inability to resolve certain inherent problems in the Dataflow architectural model. To understand, this, the Dataflow concept is summarized below.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Summary of the Dataflow Idea'''&lt;br /&gt;
&lt;br /&gt;
In its essence, a Dataflow architecture executes instructions based on whether the input arguments to the instructions are available. There is no program counter as present in a Von Neumann computer. To indicate the dependency of instructions, tags were used. When the tags contained simple memory addresses, the design was a static Dataflow machine. However, static designs couldn’t allow for multiple instances of a routine. &lt;br /&gt;
&lt;br /&gt;
Dynamic Dataflow machines used Content-Addressable memory (CAM)(i.e. the tags were stored in memory) to solve this problem.&lt;br /&gt;
The programs were loaded in the CAM. When the tagged operands of an instruction became available, the CAM would send it to an '''execution unit'''. After execution, the output data and it’s tags were sent back to the CAM (as a '''data token'''). The CAM would then execute the next instruction whose dependencies had been satisfied.&lt;br /&gt;
&lt;br /&gt;
Since, the CAM could identify instructions whose tags were not dependant on any unexecuted instruction, parallelization was possible.&lt;br /&gt;
There were however, major problems related to -&lt;br /&gt;
&lt;br /&gt;
1) broadcasting the data tokens in a massively parallel system efficiently.&lt;br /&gt;
&lt;br /&gt;
2) dispatching instruction tokens in a massively parallel system efficiently.&lt;br /&gt;
&lt;br /&gt;
3) A real program had a huge number of dependencies. Building a CAM large enough for this proved difficult.&lt;br /&gt;
&lt;br /&gt;
Due to these issues, new developments in this area were largely stagnant.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''New Developments in the Dataflow Architectural Model'''&lt;br /&gt;
&lt;br /&gt;
(Referenced from: http://en.wikipedia.org/wiki/Out-of-order_execution)&lt;br /&gt;
1) A subset of the Dataflow model - '''Out of order execution''' is widely used in present day architecture. It uses the conventional Von Neumann Architecture to run '''Execution Windows''' in the usual order. Within the Window however, instructions are run according to the Dataflow Paradigm thus enabling parallelization and efficient utilization of CPU cycles.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
(Referenced form: http://wavescalar.cs.washington.edu/)&lt;br /&gt;
2)The WaveScalar Instruction Set Architecture and Execution Model, currently being developed at the University of Washington attempts at building an architectural model that can work with current Imperative languages.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
(Referenced from: http://portal.acm.org/citation.cfm?id=1032450 &amp;amp; http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&amp;amp;arnumber=1332593&amp;amp;isnumber=29428)&lt;br /&gt;
&lt;br /&gt;
3)Calstrom and Boden propose a '''packet instruction set computer (PISC) architecture''' which would employ dataflow architecture for network processors. They detailed a 40 gb/s network processor using Dataflow architecture.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
(Referenced from: http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel2/3036/8629/00379757.pdf?isnumber=&amp;amp;arnumber=379757)&lt;br /&gt;
4) Data flow architecture is also being evaluated for DSP processors as outlined in the referenced paper by Lee et al. Their proposed design was for a static Dataflow processor with 9 parallel processors for the multi-standard video codec processor.&lt;br /&gt;
&lt;br /&gt;
== Systolic Architecture ==&lt;br /&gt;
&lt;br /&gt;
'''Emergence of Systolic Arrays'''&lt;br /&gt;
&lt;br /&gt;
During the 1980s, tremendous technological advances were being made in the field of VLSI circuits, which led to the birth of a several different concepts of highly parallel computing systems. One particular approach to such parallelism was using Systolic arrays, which constituted of a high number of processing elements known as cells, which were interconnected for local communication. This model utilizes a pipe-network arrangement of data processing units. Whenever a data object arrives, an operation is triggered in a data processing unit, unlike a central processing unit which has program counters. Several data streams are sent and received by a systolic array and several data counters are required to propagate data streams. This simple methodology facilitates parallelism.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Definition, Function and Applications'''&lt;br /&gt;
&lt;br /&gt;
They are called systolic arrays; because data, similar to human blood circulation, circulates within the array and also may interact with other data. Some results that have been computed in certain cells are pumped into new cells as input, similar to the heart (Hence the analogy to a systolic mechanism of parallelism). H. T. Kung and Charles E. Leiserson invented the concept of systolic arrays being utilized as agents for parallel processing.&lt;br /&gt;
&lt;br /&gt;
The Systolic Architecture is a mesh-like, interconnected set of processing elements, or cells, which interact with each other and pass on results that become inputs for the next computational time-step. Such proximity of high performance processors provide a highly required space efficiency, which is usually the main factor in parallel architecture. The structure of such systolic arrays may be non linear and multi-directional pathways may exist between processing elements. Even though this architecture is quite similar to Single-Instruction-Multiple-Data, unlike SIMD, each processing element is capable of processing a unique, different operation. The main feature of systolic architecture is that its highly specialized computations can be performed on simple parallel processors and localized communication patterns.&lt;br /&gt;
&lt;br /&gt;
The systolic array is an architectural concept that is highly suited for very high integration technology. Communication between these mesh-connected processors occurs only amongst neighbors. Both control and data flow are local. Each processor has a communication register that can be read by any of its neighbors.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A Systolic array is a network of processing elements that has features like&lt;br /&gt;
&lt;br /&gt;
• Modularity : each systolic array element is a module&lt;br /&gt;
&lt;br /&gt;
• Synchrony : a global clock times the data through the network&lt;br /&gt;
&lt;br /&gt;
• Locality (both spatial and temporal) : cells have local communication and a unit time delay&lt;br /&gt;
&lt;br /&gt;
• Regularity : processing elements are homogeneously interconnected&lt;br /&gt;
&lt;br /&gt;
• Parallel Computing and Pipelinability : architecture achieves high speed&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The two main Systolic Architectural Features are&lt;br /&gt;
&lt;br /&gt;
• Balancing Computation with I/O.&lt;br /&gt;
&lt;br /&gt;
• Concurrency and Communication.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
But other notable features of the architecture are its cost effectiveness, its regular &amp;amp; simple design, the modularity in arrays is quite high, the number of processors working simultaneously is high and also the local communication is fast – making overall execution time much faster.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''Types of Systolic Arrays''&lt;br /&gt;
&lt;br /&gt;
1.	Single Dimensional Input/Output Linear Array&lt;br /&gt;
        - This is usually utilized for single input/output&lt;br /&gt;
        [[Image:Systolic01.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
2.	Two Dimensional Input/Output Linear Array&lt;br /&gt;
        - This allows for more input/output and control over a linear array&lt;br /&gt;
        [[Image:Systolic02.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
3.	Perimeter Input/Output Planar Array&lt;br /&gt;
        - This topology allows input/output through its boundary or perimeter cells only&lt;br /&gt;
        [[Image:Systolic03.jpg]]&lt;br /&gt;
  &lt;br /&gt;
&lt;br /&gt;
4. 	Three Dimensional Input/Output Focal Plane Array&lt;br /&gt;
        - This facilitates input/output to each and every systolic cell in the array&lt;br /&gt;
        [[Image:Systolic04.jpg]]	 &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A few applications of Systolic Arrays&lt;br /&gt;
&lt;br /&gt;
•	Matrix Multiplication &lt;br /&gt;
&lt;br /&gt;
•	Solution of linear equations to problems in image processing&lt;br /&gt;
&lt;br /&gt;
•	Computer graphics&lt;br /&gt;
&lt;br /&gt;
•	Cryptography&lt;br /&gt;
&lt;br /&gt;
•	Computer tomography&lt;br /&gt;
&lt;br /&gt;
•	Matrix Inversion and Decomposition&lt;br /&gt;
&lt;br /&gt;
•	Convolution&lt;br /&gt;
&lt;br /&gt;
•	Polynomial Evaluation&lt;br /&gt;
&lt;br /&gt;
•	Lattice filters for seismic and speech signal processing&lt;br /&gt;
&lt;br /&gt;
•	Artificial Neural Networks&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
For a complete explanation on the invention of systolic arrays, utilize the following link : http://www.patentstorm.us/patents/4727503-fulltext.html&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''New Developments'''&lt;br /&gt;
&lt;br /&gt;
''iWarp''&lt;br /&gt;
&lt;br /&gt;
In 1989, the Intel Corporation launched the iWarp as a product and produced more than 1500 iWarp systems. The underlying architecture was based on systolic arrays and data streams being utilized for sending and receiving data between elements on the system. Even though the system was well suited for several applications, Intel stopped actively marketing the product in the mid-90s. It is still a useful tool for research in the parallel computing direction and it was one of the first successful steps towards true parallelism in the early ages of parallel computing.&lt;br /&gt;
&lt;br /&gt;
''Image Processing and Morphology''&lt;br /&gt;
&lt;br /&gt;
A two-dimensional systolic array consisting of cells can be implemented, based on parallel modules which provide internal pipeline operation where every cell can be configured according to a control word. Also, the array can be provided with a group of image buffers, that can reduce the number of accesses to data memory may also extend the array capabilities, allowing the possibility of chaining interconnection of multiple processing blocks.&lt;br /&gt;
&lt;br /&gt;
''Digital Signal Processors''&lt;br /&gt;
&lt;br /&gt;
Low cost, systolic architectural microprocessors utilizes a DSP systolic array, which makes it possible to build low cost ICs capable of providing high speed digital video services. This requires high processing capabilities, and parallelism is a requirement in such areas. Systolic architectures are better suited for such purposes as they are of much lower cost due to their space-efficiency and interconnectivity.&lt;br /&gt;
&lt;br /&gt;
''Tilera Tile64''&lt;br /&gt;
&lt;br /&gt;
Arranged in a two dimensional grid, the Tilera 64 is a tile that has 64 processing elements or cells which are interconnected through a five way switch and it provides a two level hierarchical cache. The architecture is completely based on systolic arrays and this sixty-four element multi-core processor is being released in September 2007. It is already predicted to be utilized extensively in the field of embedded systems for advanced networking, unified thread management, digital video, web services, etc.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Why Systolic Architecture has not truly evolved with time'''&lt;br /&gt;
(to the extent of other architectures is because)&lt;br /&gt;
&lt;br /&gt;
1.	Global Synchronization takes more time due to signal delays within the network&lt;br /&gt;
&lt;br /&gt;
2.	Bandwidth requirements are tremendous for both processor and memory&lt;br /&gt;
&lt;br /&gt;
3.	Fault tolerance is very poor due as interconnection protocols are lacking&lt;br /&gt;
&lt;br /&gt;
 &lt;br /&gt;
Also, a certain ‘parallel overhead’ point occurs in Systolic Arrays where beyond that point, adding more processors does not increase the efficiency of processing as it would normally be expected. There may even be a point beyond which adding more processors may even lead to slower execution time for the architecture.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''References'''&lt;br /&gt;
&lt;br /&gt;
1. (Reference: Based on ideas presented in the Wikipedia article at:http://en.wikipedia.org/wiki/Systolic_array)&lt;br /&gt;
&lt;br /&gt;
2. Systolic Algorithms: Concepts, Synthesis and Evolution - Siang W.Song, University of Sau Paulo, Department Of Computer Science&lt;br /&gt;
http://citeseer.ist.psu.edu/cache/papers/cs/30734/http:zSzzSzwww.ime.usp.brzSz~songzSzpaperszSzcimpa.pdf/systolic-algorithms-concepts-synthesis.pdf&lt;br /&gt;
&lt;br /&gt;
3. Instruction Systolic Array (ISA) - H.W. Lang, FH Flensburg&lt;br /&gt;
http://www.iti.fh-flensburg.de/lang/papers/isa/isa1.htm&lt;br /&gt;
&lt;br /&gt;
4. Systolic Arrays : Patent Description&lt;br /&gt;
http://www.patentstorm.us/patents/4727503-fulltext.html&lt;br /&gt;
&lt;br /&gt;
5. iWarp&lt;br /&gt;
http://www.cs.cmu.edu/~iwarp/&lt;br /&gt;
&lt;br /&gt;
6. Tilera Tile64&lt;br /&gt;
http://www.tilera.com/products/processors.php&lt;br /&gt;
&lt;br /&gt;
7. FPGA-Based Customizable Systolic Architecture for Image Processing Applications : Proceedings of the 2005 International Conference on Reconfigurable Computing and FPGAs (ReConFig'05) on Reconfigurable Computing and FPGAs - Griselda Saldana, Miguel Arias-Estrada (IEEE Computer Society)&lt;br /&gt;
&lt;br /&gt;
8. Summary of Systolic Architectures (Slides)&lt;br /&gt;
http://web.cecs.pdx.edu/~mperkows/temp/May13/070-Systolic-Processors.pdf&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_10_aj&amp;diff=3032</id>
		<title>CSC/ECE 506 Fall 2007/wiki1 10 aj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_10_aj&amp;diff=3032"/>
		<updated>2007-09-06T02:44:27Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* Systolic Architecture */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''( Section 1.2.6)'''&lt;br /&gt;
&lt;br /&gt;
== New developments in dataflow and systolic architectures ==&lt;br /&gt;
&lt;br /&gt;
In the 1980s, a steady progress of parallel computing gave way for various unique parallel architectures that underwent extensive research but were not truly implemented to its full extent as when compared to architectures such as Shared Address Programming, Message Passing and Data Parallel Processing. Such architectures are still in its infancy and though its concepts have been utilized in various approaches for increasing processing efficiency; the actual architectural implementation is not widely employed for the sake of parallel computing.&lt;br /&gt;
&lt;br /&gt;
Two such architectures are Dataflow Architecture and Systolic Architecture.&lt;br /&gt;
&lt;br /&gt;
== Dataflow Architecture ==&lt;br /&gt;
&lt;br /&gt;
'''Developments in Dataflow Architecture'''&lt;br /&gt;
&lt;br /&gt;
(Reference: Based on ideas presented in the Wikipedia article at: http://en.wikipedia.org/wiki/Dataflow_architecture )&lt;br /&gt;
&lt;br /&gt;
Dataflow architectures (from a hardware standpoint) was an important research topic in the 1970s and early 1980s. Interest in the field has subsided in recent years due to the inability to resolve certain inherent problems in the Dataflow architectural model. To understand, this, the Dataflow concept is summarized below.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Summary of the Dataflow Idea'''&lt;br /&gt;
&lt;br /&gt;
In its essence, a Dataflow architecture executes instructions based on whether the input arguments to the instructions are available. There is no program counter as present in a Von Neumann computer. To indicate the dependency of instructions, tags were used. When the tags contained simple memory addresses, the design was a static Dataflow machine. However, static designs couldn’t allow for multiple instances of a routine. &lt;br /&gt;
&lt;br /&gt;
Dynamic Dataflow machines used Content-Addressable memory (CAM)(i.e. the tags were stored in memory) to solve this problem.&lt;br /&gt;
The programs were loaded in the CAM. When the tagged operands of an instruction became available, the CAM would send it to an '''execution unit'''. After execution, the output data and it’s tags were sent back to the CAM (as a '''data token'''). The CAM would then execute the next instruction whose dependencies had been satisfied.&lt;br /&gt;
&lt;br /&gt;
Since, the CAM could identify instructions whose tags were not dependant on any unexecuted instruction, parallelization was possible.&lt;br /&gt;
There were however, major problems related to -&lt;br /&gt;
&lt;br /&gt;
1) broadcasting the data tokens in a massively parallel system efficiently.&lt;br /&gt;
&lt;br /&gt;
2) dispatching instruction tokens in a massively parallel system efficiently.&lt;br /&gt;
&lt;br /&gt;
3) A real program had a huge number of dependencies. Building a CAM large enough for this proved difficult.&lt;br /&gt;
&lt;br /&gt;
Due to these issues, new developments in this area were largely stagnant.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''New Developments in the Dataflow Architectural Model'''&lt;br /&gt;
&lt;br /&gt;
(Referenced from: http://en.wikipedia.org/wiki/Out-of-order_execution)&lt;br /&gt;
1) A subset of the Dataflow model - '''Out of order execution''' is widely used in present day architecture. It uses the conventional Von Neumann Architecture to run '''Execution Windows''' in the usual order. Within the Window however, instructions are run according to the Dataflow Paradigm thus enabling parallelization and efficient utilization of CPU cycles.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
(Referenced form: http://wavescalar.cs.washington.edu/)&lt;br /&gt;
2)The WaveScalar Instruction Set Architecture and Execution Model, currently being developed at the University of Washington attempts at building an architectural model that can work with current Imperative languages.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
(Referenced from: http://portal.acm.org/citation.cfm?id=1032450 &amp;amp; http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&amp;amp;arnumber=1332593&amp;amp;isnumber=29428)&lt;br /&gt;
&lt;br /&gt;
3)Calstrom and Boden propose a '''packet instruction set computer (PISC) architecture''' which would employ dataflow architecture for network processors. They detailed a 40 gb/s network processor using Dataflow architecture.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
(Referenced from: http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel2/3036/8629/00379757.pdf?isnumber=&amp;amp;arnumber=379757)&lt;br /&gt;
4) Data flow architecture is also being evaluated for DSP processors as outlined in the referenced paper by Lee et al. Their proposed design was for a static Dataflow processor with 9 parallel processors for the multi-standard video codec processor.&lt;br /&gt;
&lt;br /&gt;
== Systolic Architecture ==&lt;br /&gt;
&lt;br /&gt;
'''Emergence of Systolic Arrays'''&lt;br /&gt;
&lt;br /&gt;
During the 1980s, tremendous technological advances were being made in the field of VLSI circuits, which led to the birth of a several different concepts of highly parallel computing systems. One particular approach to such parallelism was using Systolic arrays, which constituted of a high number of processing elements known as cells, which were interconnected for local communication. This model utilizes a pipe-network arrangement of data processing units. Whenever a data object arrives, an operation is triggered in a data processing unit, unlike a central processing unit which has program counters. Several data streams are sent and received by a systolic array and several data counters are required to propagate data streams. This simple methodology facilitates parallelism.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Definition, Function and Applications'''&lt;br /&gt;
&lt;br /&gt;
They are called systolic arrays; because data, similar to human blood circulation, circulates within the array and also may interact with other data. Some results that have been computed in certain cells are pumped into new cells as input, similar to the heart (Hence the analogy to a systolic mechanism of parallelism). H. T. Kung and Charles E. Leiserson invented the concept of systolic arrays being utilized as agents for parallel processing.&lt;br /&gt;
&lt;br /&gt;
The Systolic Architecture is a mesh-like, interconnected set of processing elements, or cells, which interact with each other and pass on results that become inputs for the next computational time-step. Such proximity of high performance processors provide a highly required space efficiency, which is usually the main factor in parallel architecture. The structure of such systolic arrays may be non linear and multi-directional pathways may exist between processing elements. Even though this architecture is quite similar to Single-Instruction-Multiple-Data, unlike SIMD, each processing element is capable of processing a unique, different operation. The main feature of systolic architecture is that its highly specialized computations can be performed on simple parallel processors and localized communication patterns.&lt;br /&gt;
&lt;br /&gt;
The systolic array is an architectural concept that is highly suited for very high integration technology. Communication between these mesh-connected processors occurs only amongst neighbors. Both control and data flow are local. Each processor has a communication register that can be read by any of its neighbors.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A Systolic array is a network of processing elements that has features like&lt;br /&gt;
&lt;br /&gt;
• Modularity : each systolic array element is a module&lt;br /&gt;
&lt;br /&gt;
• Synchrony : a global clock times the data through the network&lt;br /&gt;
&lt;br /&gt;
• Locality (both spatial and temporal) : cells have local communication and a unit time delay&lt;br /&gt;
&lt;br /&gt;
• Regularity : processing elements are homogeneously interconnected&lt;br /&gt;
&lt;br /&gt;
• Parallel Computing and Pipelinability : architecture achieves high speed&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The two main Systolic Architectural Features are&lt;br /&gt;
&lt;br /&gt;
• Balancing Computation with I/O.&lt;br /&gt;
&lt;br /&gt;
• Concurrency and Communication.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
But other notable features of the architecture are its cost effectiveness, its regular &amp;amp; simple design, the modularity in arrays is quite high, the number of processors working simultaneously is high and also the local communication is fast – making overall execution time much faster.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''Types of Systolic Arrays''&lt;br /&gt;
&lt;br /&gt;
1.	Single Dimensional Input/Output Linear Array&lt;br /&gt;
        - This is usually utilized for single input/output&lt;br /&gt;
        [[Image:Systolic01.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
2.	Two Dimensional Input/Output Linear Array&lt;br /&gt;
        - This allows for more input/output and control over a linear array&lt;br /&gt;
        [[Image:Systolic02.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
3.	Perimeter Input/Output Planar Array&lt;br /&gt;
        - This topology allows input/output through its boundary or perimeter cells only&lt;br /&gt;
        [[Image:Systolic03.jpg]]&lt;br /&gt;
  &lt;br /&gt;
&lt;br /&gt;
4. 	Three Dimensional Input/Output Focal Plane Array&lt;br /&gt;
        - This facilitates input/output to each and every systolic cell in the array&lt;br /&gt;
        [[Image:Systolic04.jpg]]	 &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A few applications of Systolic Arrays&lt;br /&gt;
&lt;br /&gt;
•	Matrix Multiplication &lt;br /&gt;
&lt;br /&gt;
•	Solution of linear equations to problems in image processing&lt;br /&gt;
&lt;br /&gt;
•	Computer graphics&lt;br /&gt;
&lt;br /&gt;
•	Cryptography&lt;br /&gt;
&lt;br /&gt;
•	Computer tomography&lt;br /&gt;
&lt;br /&gt;
•	Matrix Inversion and Decomposition&lt;br /&gt;
&lt;br /&gt;
•	Convolution&lt;br /&gt;
&lt;br /&gt;
•	Polynomial Evaluation&lt;br /&gt;
&lt;br /&gt;
•	Lattice filters for seismic and speech signal processing&lt;br /&gt;
&lt;br /&gt;
•	Artificial Neural Networks&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
For a complete explanation on the invention of systolic arrays, utilize the following link : http://www.patentstorm.us/patents/4727503-fulltext.html&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''New Developments'''&lt;br /&gt;
&lt;br /&gt;
''iWarp''&lt;br /&gt;
&lt;br /&gt;
In 1989, the Intel Corporation launched the iWarp as a product and produced more than 1500 iWarp systems. The underlying architecture was based on systolic arrays and data streams being utilized for sending and receiving data between elements on the system. Even though the system was well suited for several applications, Intel stopped actively marketing the product in the mid-90s. It is still a useful tool for research in the parallel computing direction and it was one of the first successful steps towards true parallelism in the early ages of parallel computing.&lt;br /&gt;
&lt;br /&gt;
''Image Processing and Morphology''&lt;br /&gt;
&lt;br /&gt;
A two-dimensional systolic array consisting of cells can be implemented, based on parallel modules which provide internal pipeline operation where every cell can be configured according to a control word. Also, the array can be provided with a group of image buffers, that can reduce the number of accesses to data memory may also extend the array capabilities, allowing the possibility of chaining interconnection of multiple processing blocks.&lt;br /&gt;
&lt;br /&gt;
''Digital Signal Processors''&lt;br /&gt;
&lt;br /&gt;
Low cost, systolic architectural microprocessors utilizes a DSP systolic array, which makes it possible to build low cost ICs capable of providing high speed digital video services. This requires high processing capabilities, and parallelism is a requirement in such areas. Systolic architectures are better suited for such purposes as they are of much lower cost due to their space-efficiency and interconnectivity.&lt;br /&gt;
&lt;br /&gt;
''Tilera Tile64''&lt;br /&gt;
&lt;br /&gt;
Arranged in a two dimensional grid, the Tilera 64 is a tile that has 64 processing elements or cells which are interconnected through a five way switch and it provides a two level hierarchical cache. The architecture is completely based on systolic arrays and this sixty-four element multi-core processor is being released in September 2007. It is already predicted to be utilized extensively in the field of embedded systems for advanced networking, unified thread management, digital video, web services, etc.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''Why Systolic Architecture has not truly evolved with time''&lt;br /&gt;
(to the extent of other architectures is because)&lt;br /&gt;
1.	Global Synchronization takes more time due to signal delays within the network&lt;br /&gt;
2.	Bandwidth requirements are tremendous for both processor and memory&lt;br /&gt;
3.	Fault tolerance is very poor due as interconnection protocols are lacking&lt;br /&gt;
 &lt;br /&gt;
Also, a certain ‘parallel overhead’ point occurs in Systolic Arrays where beyond that point, adding more processors does not increase the efficiency of processing as it would normally be expected. There may even be a point beyond which adding more processors may even lead to slower execution time for the architecture.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''References'''&lt;br /&gt;
&lt;br /&gt;
1. (Reference: Based on ideas presented in the Wikipedia article at:http://en.wikipedia.org/wiki/Systolic_array)&lt;br /&gt;
&lt;br /&gt;
2. Systolic Algorithms: Concepts, Synthesis and Evolution - Siang W.Song, University of Sau Paulo, Department Of Computer Science&lt;br /&gt;
http://citeseer.ist.psu.edu/cache/papers/cs/30734/http:zSzzSzwww.ime.usp.brzSz~songzSzpaperszSzcimpa.pdf/systolic-algorithms-concepts-synthesis.pdf&lt;br /&gt;
&lt;br /&gt;
3. Instruction Systolic Array (ISA) - H.W. Lang, FH Flensburg&lt;br /&gt;
http://www.iti.fh-flensburg.de/lang/papers/isa/isa1.htm&lt;br /&gt;
&lt;br /&gt;
4. Systolic Arrays : Patent Description&lt;br /&gt;
http://www.patentstorm.us/patents/4727503-fulltext.html&lt;br /&gt;
&lt;br /&gt;
5. iWarp&lt;br /&gt;
http://www.cs.cmu.edu/~iwarp/&lt;br /&gt;
&lt;br /&gt;
6. Tilera Tile64&lt;br /&gt;
http://www.tilera.com/products/processors.php&lt;br /&gt;
&lt;br /&gt;
7. FPGA-Based Customizable Systolic Architecture for Image Processing Applications : Proceedings of the 2005 International Conference on Reconfigurable Computing and FPGAs (ReConFig'05) on Reconfigurable Computing and FPGAs - Griselda Saldana, Miguel Arias-Estrada (IEEE Computer Society)&lt;br /&gt;
&lt;br /&gt;
8. Summary of Systolic Architectures (Slides)&lt;br /&gt;
http://web.cecs.pdx.edu/~mperkows/temp/May13/070-Systolic-Processors.pdf&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_10_aj&amp;diff=3030</id>
		<title>CSC/ECE 506 Fall 2007/wiki1 10 aj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_10_aj&amp;diff=3030"/>
		<updated>2007-09-06T02:42:38Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* Systolic Architecture */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''( Section 1.2.6)'''&lt;br /&gt;
&lt;br /&gt;
== New developments in dataflow and systolic architectures ==&lt;br /&gt;
&lt;br /&gt;
In the 1980s, a steady progress of parallel computing gave way for various unique parallel architectures that underwent extensive research but were not truly implemented to its full extent as when compared to architectures such as Shared Address Programming, Message Passing and Data Parallel Processing. Such architectures are still in its infancy and though its concepts have been utilized in various approaches for increasing processing efficiency; the actual architectural implementation is not widely employed for the sake of parallel computing.&lt;br /&gt;
&lt;br /&gt;
Two such architectures are Dataflow Architecture and Systolic Architecture.&lt;br /&gt;
&lt;br /&gt;
== Dataflow Architecture ==&lt;br /&gt;
&lt;br /&gt;
'''Developments in Dataflow Architecture'''&lt;br /&gt;
&lt;br /&gt;
(Reference: Based on ideas presented in the Wikipedia article at: http://en.wikipedia.org/wiki/Dataflow_architecture )&lt;br /&gt;
&lt;br /&gt;
Dataflow architectures (from a hardware standpoint) was an important research topic in the 1970s and early 1980s. Interest in the field has subsided in recent years due to the inability to resolve certain inherent problems in the Dataflow architectural model. To understand, this, the Dataflow concept is summarized below.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Summary of the Dataflow Idea'''&lt;br /&gt;
&lt;br /&gt;
In its essence, a Dataflow architecture executes instructions based on whether the input arguments to the instructions are available. There is no program counter as present in a Von Neumann computer. To indicate the dependency of instructions, tags were used. When the tags contained simple memory addresses, the design was a static Dataflow machine. However, static designs couldn’t allow for multiple instances of a routine. &lt;br /&gt;
&lt;br /&gt;
Dynamic Dataflow machines used Content-Addressable memory (CAM)(i.e. the tags were stored in memory) to solve this problem.&lt;br /&gt;
The programs were loaded in the CAM. When the tagged operands of an instruction became available, the CAM would send it to an '''execution unit'''. After execution, the output data and it’s tags were sent back to the CAM (as a '''data token'''). The CAM would then execute the next instruction whose dependencies had been satisfied.&lt;br /&gt;
&lt;br /&gt;
Since, the CAM could identify instructions whose tags were not dependant on any unexecuted instruction, parallelization was possible.&lt;br /&gt;
There were however, major problems related to -&lt;br /&gt;
&lt;br /&gt;
1) broadcasting the data tokens in a massively parallel system efficiently.&lt;br /&gt;
&lt;br /&gt;
2) dispatching instruction tokens in a massively parallel system efficiently.&lt;br /&gt;
&lt;br /&gt;
3) A real program had a huge number of dependencies. Building a CAM large enough for this proved difficult.&lt;br /&gt;
&lt;br /&gt;
Due to these issues, new developments in this area were largely stagnant.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''New Developments in the Dataflow Architectural Model'''&lt;br /&gt;
&lt;br /&gt;
(Referenced from: http://en.wikipedia.org/wiki/Out-of-order_execution)&lt;br /&gt;
1) A subset of the Dataflow model - '''Out of order execution''' is widely used in present day architecture. It uses the conventional Von Neumann Architecture to run '''Execution Windows''' in the usual order. Within the Window however, instructions are run according to the Dataflow Paradigm thus enabling parallelization and efficient utilization of CPU cycles.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
(Referenced form: http://wavescalar.cs.washington.edu/)&lt;br /&gt;
2)The WaveScalar Instruction Set Architecture and Execution Model, currently being developed at the University of Washington attempts at building an architectural model that can work with current Imperative languages.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
(Referenced from: http://portal.acm.org/citation.cfm?id=1032450 &amp;amp; http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&amp;amp;arnumber=1332593&amp;amp;isnumber=29428)&lt;br /&gt;
&lt;br /&gt;
3)Calstrom and Boden propose a '''packet instruction set computer (PISC) architecture''' which would employ dataflow architecture for network processors. They detailed a 40 gb/s network processor using Dataflow architecture.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
(Referenced from: http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel2/3036/8629/00379757.pdf?isnumber=&amp;amp;arnumber=379757)&lt;br /&gt;
4) Data flow architecture is also being evaluated for DSP processors as outlined in the referenced paper by Lee et al. Their proposed design was for a static Dataflow processor with 9 parallel processors for the multi-standard video codec processor.&lt;br /&gt;
&lt;br /&gt;
== Systolic Architecture ==&lt;br /&gt;
&lt;br /&gt;
'''Emergence of Systolic Arrays'''&lt;br /&gt;
&lt;br /&gt;
During the 1980s, tremendous technological advances were being made in the field of VLSI circuits, which led to the birth of a several different concepts of highly parallel computing systems. One particular approach to such parallelism was using Systolic arrays, which constituted of a high number of processing elements known as cells, which were interconnected for local communication. This model utilizes a pipe-network arrangement of data processing units. Whenever a data object arrives, an operation is triggered in a data processing unit, unlike a central processing unit which has program counters. Several data streams are sent and received by a systolic array and several data counters are required to propagate data streams. This simple methodology facilitates parallelism.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Definition, Function and Applications'''&lt;br /&gt;
&lt;br /&gt;
They are called systolic arrays; because data, similar to human blood circulation, circulates within the array and also may interact with other data. Some results that have been computed in certain cells are pumped into new cells as input, similar to the heart (Hence the analogy to a systolic mechanism of parallelism). H. T. Kung and Charles E. Leiserson invented the concept of systolic arrays being utilized as agents for parallel processing.&lt;br /&gt;
&lt;br /&gt;
The Systolic Architecture is a mesh-like, interconnected set of processing elements, or cells, which interact with each other and pass on results that become inputs for the next computational time-step. Such proximity of high performance processors provide a highly required space efficiency, which is usually the main factor in parallel architecture. The structure of such systolic arrays may be non linear and multi-directional pathways may exist between processing elements. Even though this architecture is quite similar to Single-Instruction-Multiple-Data, unlike SIMD, each processing element is capable of processing a unique, different operation. The main feature of systolic architecture is that its highly specialized computations can be performed on simple parallel processors and localized communication patterns.&lt;br /&gt;
&lt;br /&gt;
The systolic array is an architectural concept that is highly suited for very high integration technology. Communication between these mesh-connected processors occurs only amongst neighbors. Both control and data flow are local. Each processor has a communication register that can be read by any of its neighbors.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A Systolic array is a network of processing elements that has features like&lt;br /&gt;
&lt;br /&gt;
• Modularity : each systolic array element is a module&lt;br /&gt;
&lt;br /&gt;
• Synchrony : a global clock times the data through the network&lt;br /&gt;
&lt;br /&gt;
• Locality (both spatial and temporal) : cells have local communication and a unit time delay&lt;br /&gt;
&lt;br /&gt;
• Regularity : processing elements are homogeneously interconnected&lt;br /&gt;
&lt;br /&gt;
• Parallel Computing and Pipelinability : architecture achieves high speed&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The two main Systolic Architectural Features are&lt;br /&gt;
&lt;br /&gt;
• Balancing Computation with I/O.&lt;br /&gt;
&lt;br /&gt;
• Concurrency and Communication.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
But other notable features of the architecture are its cost effectiveness, its regular &amp;amp; simple design, the modularity in arrays is quite high, the number of processors working simultaneously is high and also the local communication is fast – making overall execution time much faster.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''Types of Systolic Arrays''&lt;br /&gt;
&lt;br /&gt;
1.	Single Dimensional Input/Output Linear Array&lt;br /&gt;
        - This is usually utilized for single input/output&lt;br /&gt;
        [[Image:Systolic01.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
2.	Two Dimensional Input/Output Linear Array&lt;br /&gt;
        - This allows for more input/output and control over a linear array&lt;br /&gt;
        [[Image:Systolic02.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
3.	Perimeter Input/Output Planar Array&lt;br /&gt;
        - This topology allows input/output through its boundary or perimeter cells only&lt;br /&gt;
        [[Image:Systolic03.jpg]]&lt;br /&gt;
  &lt;br /&gt;
&lt;br /&gt;
4. 	Three Dimensional Input/Output Focal Plane Array&lt;br /&gt;
        - This facilitates input/output to each and every systolic cell in the array&lt;br /&gt;
        [[Image:Systolic04.jpg]]	 &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A few applications of Systolic Arrays&lt;br /&gt;
&lt;br /&gt;
•	Matrix Multiplication &lt;br /&gt;
&lt;br /&gt;
•	Solution of linear equations to problems in image processing&lt;br /&gt;
&lt;br /&gt;
•	Computer graphics&lt;br /&gt;
&lt;br /&gt;
•	Cryptography&lt;br /&gt;
&lt;br /&gt;
•	Computer tomography&lt;br /&gt;
&lt;br /&gt;
•	Matrix Inversion and Decomposition&lt;br /&gt;
&lt;br /&gt;
•	Convolution&lt;br /&gt;
&lt;br /&gt;
•	Polynomial Evaluation&lt;br /&gt;
&lt;br /&gt;
•	Lattice filters for seismic and speech signal processing&lt;br /&gt;
&lt;br /&gt;
•	Artificial Neural Networks&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
For a complete explanation on the invention of systolic arrays, utilize the following link : http://www.patentstorm.us/patents/4727503-fulltext.html&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''New Developments'''&lt;br /&gt;
&lt;br /&gt;
''iWarp''&lt;br /&gt;
&lt;br /&gt;
In 1989, the Intel Corporation launched the iWarp as a product and produced more than 1500 iWarp systems. The underlying architecture was based on systolic arrays and data streams being utilized for sending and receiving data between elements on the system. Even though the system was well suited for several applications, Intel stopped actively marketing the product in the mid-90s. It is still a useful tool for research in the parallel computing direction and it was one of the first successful steps towards true parallelism in the early ages of parallel computing.&lt;br /&gt;
&lt;br /&gt;
''Image Processing and Morphology''&lt;br /&gt;
&lt;br /&gt;
A two-dimensional systolic array consisting of cells can be implemented, based on parallel modules which provide internal pipeline operation where every cell can be configured according to a control word. Also, the array can be provided with a group of image buffers, that can reduce the number of accesses to data memory may also extend the array capabilities, allowing the possibility of chaining interconnection of multiple processing blocks.&lt;br /&gt;
&lt;br /&gt;
''Digital Signal Processors''&lt;br /&gt;
&lt;br /&gt;
Low cost, systolic architectural microprocessors utilizes a DSP systolic array, which makes it possible to build low cost ICs capable of providing high speed digital video services. This requires high processing capabilities, and parallelism is a requirement in such areas. Systolic architectures are better suited for such purposes as they are of much lower cost due to their space-efficiency and interconnectivity.&lt;br /&gt;
&lt;br /&gt;
''Tilera Tile64''&lt;br /&gt;
&lt;br /&gt;
Arranged in a two dimensional grid, the Tilera 64 is a tile that has 64 processing elements or cells which are interconnected through a five way switch and it provides a two level hierarchical cache. The architecture is completely based on systolic arrays and this sixty-four element multi-core processor is being released in September 2007. It is already predicted to be utilized extensively in the field of embedded systems for advanced networking, unified thread management, digital video, web services, etc.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''References'''&lt;br /&gt;
&lt;br /&gt;
1. (Reference: Based on ideas presented in the Wikipedia article at:http://en.wikipedia.org/wiki/Systolic_array)&lt;br /&gt;
&lt;br /&gt;
2. Systolic Algorithms: Concepts, Synthesis and Evolution - Siang W.Song, University of Sau Paulo, Department Of Computer Science&lt;br /&gt;
http://citeseer.ist.psu.edu/cache/papers/cs/30734/http:zSzzSzwww.ime.usp.brzSz~songzSzpaperszSzcimpa.pdf/systolic-algorithms-concepts-synthesis.pdf&lt;br /&gt;
&lt;br /&gt;
3. Instruction Systolic Array (ISA) - H.W. Lang, FH Flensburg&lt;br /&gt;
http://www.iti.fh-flensburg.de/lang/papers/isa/isa1.htm&lt;br /&gt;
&lt;br /&gt;
4. Systolic Arrays : Patent Description&lt;br /&gt;
http://www.patentstorm.us/patents/4727503-fulltext.html&lt;br /&gt;
&lt;br /&gt;
5. iWarp&lt;br /&gt;
http://www.cs.cmu.edu/~iwarp/&lt;br /&gt;
&lt;br /&gt;
6. Tilera Tile64&lt;br /&gt;
http://www.tilera.com/products/processors.php&lt;br /&gt;
&lt;br /&gt;
7. FPGA-Based Customizable Systolic Architecture for Image Processing Applications : Proceedings of the 2005 International Conference on Reconfigurable Computing and FPGAs (ReConFig'05) on Reconfigurable Computing and FPGAs - Griselda Saldana, Miguel Arias-Estrada (IEEE Computer Society)&lt;br /&gt;
&lt;br /&gt;
8. Summary of Systolic Architectures (Slides)&lt;br /&gt;
http://web.cecs.pdx.edu/~mperkows/temp/May13/070-Systolic-Processors.pdf&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_10_aj&amp;diff=3029</id>
		<title>CSC/ECE 506 Fall 2007/wiki1 10 aj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_10_aj&amp;diff=3029"/>
		<updated>2007-09-06T02:42:14Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* Systolic Architecture */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''( Section 1.2.6)'''&lt;br /&gt;
&lt;br /&gt;
== New developments in dataflow and systolic architectures ==&lt;br /&gt;
&lt;br /&gt;
In the 1980s, a steady progress of parallel computing gave way for various unique parallel architectures that underwent extensive research but were not truly implemented to its full extent as when compared to architectures such as Shared Address Programming, Message Passing and Data Parallel Processing. Such architectures are still in its infancy and though its concepts have been utilized in various approaches for increasing processing efficiency; the actual architectural implementation is not widely employed for the sake of parallel computing.&lt;br /&gt;
&lt;br /&gt;
Two such architectures are Dataflow Architecture and Systolic Architecture.&lt;br /&gt;
&lt;br /&gt;
== Dataflow Architecture ==&lt;br /&gt;
&lt;br /&gt;
'''Developments in Dataflow Architecture'''&lt;br /&gt;
&lt;br /&gt;
(Reference: Based on ideas presented in the Wikipedia article at: http://en.wikipedia.org/wiki/Dataflow_architecture )&lt;br /&gt;
&lt;br /&gt;
Dataflow architectures (from a hardware standpoint) was an important research topic in the 1970s and early 1980s. Interest in the field has subsided in recent years due to the inability to resolve certain inherent problems in the Dataflow architectural model. To understand, this, the Dataflow concept is summarized below.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Summary of the Dataflow Idea'''&lt;br /&gt;
&lt;br /&gt;
In its essence, a Dataflow architecture executes instructions based on whether the input arguments to the instructions are available. There is no program counter as present in a Von Neumann computer. To indicate the dependency of instructions, tags were used. When the tags contained simple memory addresses, the design was a static Dataflow machine. However, static designs couldn’t allow for multiple instances of a routine. &lt;br /&gt;
&lt;br /&gt;
Dynamic Dataflow machines used Content-Addressable memory (CAM)(i.e. the tags were stored in memory) to solve this problem.&lt;br /&gt;
The programs were loaded in the CAM. When the tagged operands of an instruction became available, the CAM would send it to an '''execution unit'''. After execution, the output data and it’s tags were sent back to the CAM (as a '''data token'''). The CAM would then execute the next instruction whose dependencies had been satisfied.&lt;br /&gt;
&lt;br /&gt;
Since, the CAM could identify instructions whose tags were not dependant on any unexecuted instruction, parallelization was possible.&lt;br /&gt;
There were however, major problems related to -&lt;br /&gt;
&lt;br /&gt;
1) broadcasting the data tokens in a massively parallel system efficiently.&lt;br /&gt;
&lt;br /&gt;
2) dispatching instruction tokens in a massively parallel system efficiently.&lt;br /&gt;
&lt;br /&gt;
3) A real program had a huge number of dependencies. Building a CAM large enough for this proved difficult.&lt;br /&gt;
&lt;br /&gt;
Due to these issues, new developments in this area were largely stagnant.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''New Developments in the Dataflow Architectural Model'''&lt;br /&gt;
&lt;br /&gt;
(Referenced from: http://en.wikipedia.org/wiki/Out-of-order_execution)&lt;br /&gt;
1) A subset of the Dataflow model - '''Out of order execution''' is widely used in present day architecture. It uses the conventional Von Neumann Architecture to run '''Execution Windows''' in the usual order. Within the Window however, instructions are run according to the Dataflow Paradigm thus enabling parallelization and efficient utilization of CPU cycles.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
(Referenced form: http://wavescalar.cs.washington.edu/)&lt;br /&gt;
2)The WaveScalar Instruction Set Architecture and Execution Model, currently being developed at the University of Washington attempts at building an architectural model that can work with current Imperative languages.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
(Referenced from: http://portal.acm.org/citation.cfm?id=1032450 &amp;amp; http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&amp;amp;arnumber=1332593&amp;amp;isnumber=29428)&lt;br /&gt;
&lt;br /&gt;
3)Calstrom and Boden propose a '''packet instruction set computer (PISC) architecture''' which would employ dataflow architecture for network processors. They detailed a 40 gb/s network processor using Dataflow architecture.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
(Referenced from: http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel2/3036/8629/00379757.pdf?isnumber=&amp;amp;arnumber=379757)&lt;br /&gt;
4) Data flow architecture is also being evaluated for DSP processors as outlined in the referenced paper by Lee et al. Their proposed design was for a static Dataflow processor with 9 parallel processors for the multi-standard video codec processor.&lt;br /&gt;
&lt;br /&gt;
== Systolic Architecture ==&lt;br /&gt;
&lt;br /&gt;
'''Emergence of Systolic Arrays'''&lt;br /&gt;
&lt;br /&gt;
During the 1980s, tremendous technological advances were being made in the field of VLSI circuits, which led to the birth of a several different concepts of highly parallel computing systems. One particular approach to such parallelism was using Systolic arrays, which constituted of a high number of processing elements known as cells, which were interconnected for local communication. This model utilizes a pipe-network arrangement of data processing units. Whenever a data object arrives, an operation is triggered in a data processing unit, unlike a central processing unit which has program counters. Several data streams are sent and received by a systolic array and several data counters are required to propagate data streams. This simple methodology facilitates parallelism.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Definition, Function and Applications'''&lt;br /&gt;
&lt;br /&gt;
They are called systolic arrays; because data, similar to human blood circulation, circulates within the array and also may interact with other data. Some results that have been computed in certain cells are pumped into new cells as input, similar to the heart (Hence the analogy to a systolic mechanism of parallelism). H. T. Kung and Charles E. Leiserson invented the concept of systolic arrays being utilized as agents for parallel processing.&lt;br /&gt;
&lt;br /&gt;
The Systolic Architecture is a mesh-like, interconnected set of processing elements, or cells, which interact with each other and pass on results that become inputs for the next computational time-step. Such proximity of high performance processors provide a highly required space efficiency, which is usually the main factor in parallel architecture. The structure of such systolic arrays may be non linear and multi-directional pathways may exist between processing elements. Even though this architecture is quite similar to Single-Instruction-Multiple-Data, unlike SIMD, each processing element is capable of processing a unique, different operation. The main feature of systolic architecture is that its highly specialized computations can be performed on simple parallel processors and localized communication patterns.&lt;br /&gt;
&lt;br /&gt;
The systolic array is an architectural concept that is highly suited for very high integration technology. Communication between these mesh-connected processors occurs only amongst neighbors. Both control and data flow are local. Each processor has a communication register that can be read by any of its neighbors.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A Systolic array is a network of processing elements that has features like&lt;br /&gt;
&lt;br /&gt;
• Modularity : each systolic array element is a module&lt;br /&gt;
&lt;br /&gt;
• Synchrony : a global clock times the data through the network&lt;br /&gt;
&lt;br /&gt;
• Locality (both spatial and temporal) : cells have local communication and a unit time delay&lt;br /&gt;
&lt;br /&gt;
• Regularity : processing elements are homogeneously interconnected&lt;br /&gt;
&lt;br /&gt;
• Parallel Computing and Pipelinability : architecture achieves high speed&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The two main Systolic Architectural Features are&lt;br /&gt;
&lt;br /&gt;
• Balancing Computation with I/O.&lt;br /&gt;
&lt;br /&gt;
• Concurrency and Communication.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
But other notable features of the architecture are its cost effectiveness, its regular &amp;amp; simple design, the modularity in arrays is quite high, the number of processors working simultaneously is high and also the local communication is fast – making overall execution time much faster.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''Types of Systolic Arrays''&lt;br /&gt;
&lt;br /&gt;
1.	Single Dimensional Input/Output Linear Array&lt;br /&gt;
        - This is usually utilized for single input/output&lt;br /&gt;
        [[Image:Systolic01.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
2.	Two Dimensional Input/Output Linear Array&lt;br /&gt;
        - This allows for more input/output and control over a linear array&lt;br /&gt;
        [[Image:Systolic02.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
3.	Perimeter Input/Output Planar Array&lt;br /&gt;
        - This topology allows input/output through its boundary or perimeter cells only&lt;br /&gt;
        [[Image:Systolic03.jpg]]&lt;br /&gt;
  &lt;br /&gt;
&lt;br /&gt;
4. 	Three Dimensional Input/Output Focal Plane Array&lt;br /&gt;
        - This facilitates input/output to each and every systolic cell in the array&lt;br /&gt;
        [[Image:Systolic04.jpg]]	 &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A few applications of Systolic Arrays&lt;br /&gt;
&lt;br /&gt;
•	Matrix Multiplication &lt;br /&gt;
&lt;br /&gt;
•	Solution of linear equations to problems in image processing&lt;br /&gt;
&lt;br /&gt;
•	Computer graphics&lt;br /&gt;
&lt;br /&gt;
•	Cryptography&lt;br /&gt;
&lt;br /&gt;
•	Computer tomography&lt;br /&gt;
&lt;br /&gt;
•	Matrix Inversion and Decomposition&lt;br /&gt;
&lt;br /&gt;
•	Convolution&lt;br /&gt;
&lt;br /&gt;
•	Polynomial Evaluation&lt;br /&gt;
&lt;br /&gt;
•	Lattice filters for seismic and speech signal processing&lt;br /&gt;
&lt;br /&gt;
•	Artificial Neural Networks&lt;br /&gt;
&lt;br /&gt;
For a complete explanation on the invention of systolic arrays, utilize the following link : http://www.patentstorm.us/patents/4727503-fulltext.html&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''New Developments'''&lt;br /&gt;
&lt;br /&gt;
''iWarp''&lt;br /&gt;
&lt;br /&gt;
In 1989, the Intel Corporation launched the iWarp as a product and produced more than 1500 iWarp systems. The underlying architecture was based on systolic arrays and data streams being utilized for sending and receiving data between elements on the system. Even though the system was well suited for several applications, Intel stopped actively marketing the product in the mid-90s. It is still a useful tool for research in the parallel computing direction and it was one of the first successful steps towards true parallelism in the early ages of parallel computing.&lt;br /&gt;
&lt;br /&gt;
''Image Processing and Morphology''&lt;br /&gt;
&lt;br /&gt;
A two-dimensional systolic array consisting of cells can be implemented, based on parallel modules which provide internal pipeline operation where every cell can be configured according to a control word. Also, the array can be provided with a group of image buffers, that can reduce the number of accesses to data memory may also extend the array capabilities, allowing the possibility of chaining interconnection of multiple processing blocks.&lt;br /&gt;
&lt;br /&gt;
''Digital Signal Processors''&lt;br /&gt;
&lt;br /&gt;
Low cost, systolic architectural microprocessors utilizes a DSP systolic array, which makes it possible to build low cost ICs capable of providing high speed digital video services. This requires high processing capabilities, and parallelism is a requirement in such areas. Systolic architectures are better suited for such purposes as they are of much lower cost due to their space-efficiency and interconnectivity.&lt;br /&gt;
&lt;br /&gt;
''Tilera Tile64''&lt;br /&gt;
&lt;br /&gt;
Arranged in a two dimensional grid, the Tilera 64 is a tile that has 64 processing elements or cells which are interconnected through a five way switch and it provides a two level hierarchical cache. The architecture is completely based on systolic arrays and this sixty-four element multi-core processor is being released in September 2007. It is already predicted to be utilized extensively in the field of embedded systems for advanced networking, unified thread management, digital video, web services, etc.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''References'''&lt;br /&gt;
&lt;br /&gt;
1. (Reference: Based on ideas presented in the Wikipedia article at:http://en.wikipedia.org/wiki/Systolic_array)&lt;br /&gt;
&lt;br /&gt;
2. Systolic Algorithms: Concepts, Synthesis and Evolution - Siang W.Song, University of Sau Paulo, Department Of Computer Science&lt;br /&gt;
http://citeseer.ist.psu.edu/cache/papers/cs/30734/http:zSzzSzwww.ime.usp.brzSz~songzSzpaperszSzcimpa.pdf/systolic-algorithms-concepts-synthesis.pdf&lt;br /&gt;
&lt;br /&gt;
3. Instruction Systolic Array (ISA) - H.W. Lang, FH Flensburg&lt;br /&gt;
http://www.iti.fh-flensburg.de/lang/papers/isa/isa1.htm&lt;br /&gt;
&lt;br /&gt;
4. Systolic Arrays : Patent Description&lt;br /&gt;
http://www.patentstorm.us/patents/4727503-fulltext.html&lt;br /&gt;
&lt;br /&gt;
5. iWarp&lt;br /&gt;
http://www.cs.cmu.edu/~iwarp/&lt;br /&gt;
&lt;br /&gt;
6. Tilera Tile64&lt;br /&gt;
http://www.tilera.com/products/processors.php&lt;br /&gt;
&lt;br /&gt;
7. FPGA-Based Customizable Systolic Architecture for Image Processing Applications : Proceedings of the 2005 International Conference on Reconfigurable Computing and FPGAs (ReConFig'05) on Reconfigurable Computing and FPGAs - Griselda Saldana, Miguel Arias-Estrada (IEEE Computer Society)&lt;br /&gt;
&lt;br /&gt;
8. Summary of Systolic Architectures (Slides)&lt;br /&gt;
http://web.cecs.pdx.edu/~mperkows/temp/May13/070-Systolic-Processors.pdf&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=File:Systolic04.jpg&amp;diff=3027</id>
		<title>File:Systolic04.jpg</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=File:Systolic04.jpg&amp;diff=3027"/>
		<updated>2007-09-06T02:41:15Z</updated>

		<summary type="html">&lt;p&gt;Arangan: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=File:Systolic03.jpg&amp;diff=3025</id>
		<title>File:Systolic03.jpg</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=File:Systolic03.jpg&amp;diff=3025"/>
		<updated>2007-09-06T02:40:53Z</updated>

		<summary type="html">&lt;p&gt;Arangan: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=File:Systolic02.jpg&amp;diff=3024</id>
		<title>File:Systolic02.jpg</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=File:Systolic02.jpg&amp;diff=3024"/>
		<updated>2007-09-06T02:40:37Z</updated>

		<summary type="html">&lt;p&gt;Arangan: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=File:Systolic01.jpg&amp;diff=3021</id>
		<title>File:Systolic01.jpg</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=File:Systolic01.jpg&amp;diff=3021"/>
		<updated>2007-09-06T02:40:04Z</updated>

		<summary type="html">&lt;p&gt;Arangan: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_10_aj&amp;diff=3017</id>
		<title>CSC/ECE 506 Fall 2007/wiki1 10 aj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_506_Fall_2007/wiki1_10_aj&amp;diff=3017"/>
		<updated>2007-09-06T02:39:10Z</updated>

		<summary type="html">&lt;p&gt;Arangan: /* Systolic Architecture */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''( Section 1.2.6)'''&lt;br /&gt;
&lt;br /&gt;
== New developments in dataflow and systolic architectures ==&lt;br /&gt;
&lt;br /&gt;
In the 1980s, a steady progress of parallel computing gave way for various unique parallel architectures that underwent extensive research but were not truly implemented to its full extent as when compared to architectures such as Shared Address Programming, Message Passing and Data Parallel Processing. Such architectures are still in its infancy and though its concepts have been utilized in various approaches for increasing processing efficiency; the actual architectural implementation is not widely employed for the sake of parallel computing.&lt;br /&gt;
&lt;br /&gt;
Two such architectures are Dataflow Architecture and Systolic Architecture.&lt;br /&gt;
&lt;br /&gt;
== Dataflow Architecture ==&lt;br /&gt;
&lt;br /&gt;
'''Developments in Dataflow Architecture'''&lt;br /&gt;
&lt;br /&gt;
(Reference: Based on ideas presented in the Wikipedia article at: http://en.wikipedia.org/wiki/Dataflow_architecture )&lt;br /&gt;
&lt;br /&gt;
Dataflow architectures (from a hardware standpoint) was an important research topic in the 1970s and early 1980s. Interest in the field has subsided in recent years due to the inability to resolve certain inherent problems in the Dataflow architectural model. To understand, this, the Dataflow concept is summarized below.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Summary of the Dataflow Idea'''&lt;br /&gt;
&lt;br /&gt;
In its essence, a Dataflow architecture executes instructions based on whether the input arguments to the instructions are available. There is no program counter as present in a Von Neumann computer. To indicate the dependency of instructions, tags were used. When the tags contained simple memory addresses, the design was a static Dataflow machine. However, static designs couldn’t allow for multiple instances of a routine. &lt;br /&gt;
&lt;br /&gt;
Dynamic Dataflow machines used Content-Addressable memory (CAM)(i.e. the tags were stored in memory) to solve this problem.&lt;br /&gt;
The programs were loaded in the CAM. When the tagged operands of an instruction became available, the CAM would send it to an '''execution unit'''. After execution, the output data and it’s tags were sent back to the CAM (as a '''data token'''). The CAM would then execute the next instruction whose dependencies had been satisfied.&lt;br /&gt;
&lt;br /&gt;
Since, the CAM could identify instructions whose tags were not dependant on any unexecuted instruction, parallelization was possible.&lt;br /&gt;
There were however, major problems related to -&lt;br /&gt;
&lt;br /&gt;
1) broadcasting the data tokens in a massively parallel system efficiently.&lt;br /&gt;
&lt;br /&gt;
2) dispatching instruction tokens in a massively parallel system efficiently.&lt;br /&gt;
&lt;br /&gt;
3) A real program had a huge number of dependencies. Building a CAM large enough for this proved difficult.&lt;br /&gt;
&lt;br /&gt;
Due to these issues, new developments in this area were largely stagnant.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''New Developments in the Dataflow Architectural Model'''&lt;br /&gt;
&lt;br /&gt;
(Referenced from: http://en.wikipedia.org/wiki/Out-of-order_execution)&lt;br /&gt;
1) A subset of the Dataflow model - '''Out of order execution''' is widely used in present day architecture. It uses the conventional Von Neumann Architecture to run '''Execution Windows''' in the usual order. Within the Window however, instructions are run according to the Dataflow Paradigm thus enabling parallelization and efficient utilization of CPU cycles.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
(Referenced form: http://wavescalar.cs.washington.edu/)&lt;br /&gt;
2)The WaveScalar Instruction Set Architecture and Execution Model, currently being developed at the University of Washington attempts at building an architectural model that can work with current Imperative languages.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
(Referenced from: http://portal.acm.org/citation.cfm?id=1032450 &amp;amp; http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&amp;amp;arnumber=1332593&amp;amp;isnumber=29428)&lt;br /&gt;
&lt;br /&gt;
3)Calstrom and Boden propose a '''packet instruction set computer (PISC) architecture''' which would employ dataflow architecture for network processors. They detailed a 40 gb/s network processor using Dataflow architecture.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
(Referenced from: http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel2/3036/8629/00379757.pdf?isnumber=&amp;amp;arnumber=379757)&lt;br /&gt;
4) Data flow architecture is also being evaluated for DSP processors as outlined in the referenced paper by Lee et al. Their proposed design was for a static Dataflow processor with 9 parallel processors for the multi-standard video codec processor.&lt;br /&gt;
&lt;br /&gt;
== Systolic Architecture ==&lt;br /&gt;
&lt;br /&gt;
'''Emergence of Systolic Arrays'''&lt;br /&gt;
&lt;br /&gt;
During the 1980s, tremendous technological advances were being made in the field of VLSI circuits, which led to the birth of a several different concepts of highly parallel computing systems. One particular approach to such parallelism was using Systolic arrays, which constituted of a high number of processing elements known as cells, which were interconnected for local communication. This model utilizes a pipe-network arrangement of data processing units. Whenever a data object arrives, an operation is triggered in a data processing unit, unlike a central processing unit which has program counters. Several data streams are sent and received by a systolic array and several data counters are required to propagate data streams. This simple methodology facilitates parallelism.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Definition, Function and Applications'''&lt;br /&gt;
&lt;br /&gt;
They are called systolic arrays; because data, similar to human blood circulation, circulates within the array and also may interact with other data. Some results that have been computed in certain cells are pumped into new cells as input, similar to the heart (Hence the analogy to a systolic mechanism of parallelism). H. T. Kung and Charles E. Leiserson invented the concept of systolic arrays being utilized as agents for parallel processing.&lt;br /&gt;
&lt;br /&gt;
The Systolic Architecture is a mesh-like, interconnected set of processing elements, or cells, which interact with each other and pass on results that become inputs for the next computational time-step. Such proximity of high performance processors provide a highly required space efficiency, which is usually the main factor in parallel architecture. The structure of such systolic arrays may be non linear and multi-directional pathways may exist between processing elements. Even though this architecture is quite similar to Single-Instruction-Multiple-Data, unlike SIMD, each processing element is capable of processing a unique, different operation. The main feature of systolic architecture is that its highly specialized computations can be performed on simple parallel processors and localized communication patterns.&lt;br /&gt;
&lt;br /&gt;
The systolic array is an architectural concept that is highly suited for very high integration technology. Communication between these mesh-connected processors occurs only amongst neighbors. Both control and data flow are local. Each processor has a communication register that can be read by any of its neighbors.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A Systolic array is a network of processing elements that has features like&lt;br /&gt;
&lt;br /&gt;
• Modularity : each systolic array element is a module&lt;br /&gt;
&lt;br /&gt;
• Synchrony : a global clock times the data through the network&lt;br /&gt;
&lt;br /&gt;
• Locality (both spatial and temporal) : cells have local communication and a unit time delay&lt;br /&gt;
&lt;br /&gt;
• Regularity : processing elements are homogeneously interconnected&lt;br /&gt;
&lt;br /&gt;
• Parallel Computing and Pipelinability : architecture achieves high speed&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The two main Systolic Architectural Features are&lt;br /&gt;
&lt;br /&gt;
• Balancing Computation with I/O.&lt;br /&gt;
&lt;br /&gt;
• Concurrency and Communication.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
But other notable features of the architecture are its cost effectiveness, its regular &amp;amp; simple design, the modularity in arrays is quite high, the number of processors working simultaneously is high and also the local communication is fast – making overall execution time much faster.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''Types of Systolic Arrays''&lt;br /&gt;
&lt;br /&gt;
1.	Single Dimensional Input/Output Linear Array&lt;br /&gt;
        - This is usually utilized for single input/output&lt;br /&gt;
        [[Image:Systolic01.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
2.	Two Dimensional Input/Output Linear Array&lt;br /&gt;
        - This allows for more input/output and control over a linear array&lt;br /&gt;
        [[Image:Systolic02.jpg]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
3.	Perimeter Input/Output Planar Array&lt;br /&gt;
        - This topology allows input/output through its boundary or perimeter cells only&lt;br /&gt;
        [[Image:Systolic03.jpg]]&lt;br /&gt;
  &lt;br /&gt;
&lt;br /&gt;
4. 	Three Dimensional Input/Output Focal Plane Array&lt;br /&gt;
	- This facilitates input/output to each and every systolic cell in the array&lt;br /&gt;
        [[Image:Systolic04.jpg]]	 &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A few applications of Systolic Arrays&lt;br /&gt;
•	Matrix Multiplication &lt;br /&gt;
•	Solution of linear equations to problems in image processing&lt;br /&gt;
•	Computer graphics&lt;br /&gt;
•	Cryptography&lt;br /&gt;
•	Computer tomography&lt;br /&gt;
•	Matrix Inversion and Decomposition.&lt;br /&gt;
•	Convolution&lt;br /&gt;
•	Polynomial Evaluation&lt;br /&gt;
•	Lattice filters for seismic and speech signal processing&lt;br /&gt;
•	Artificial Neural Networks&lt;br /&gt;
&lt;br /&gt;
For a complete explanation on the invention of systolic arrays, utilize the following link : http://www.patentstorm.us/patents/4727503-fulltext.html&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''New Developments'''&lt;br /&gt;
&lt;br /&gt;
''iWarp''&lt;br /&gt;
&lt;br /&gt;
In 1989, the Intel Corporation launched the iWarp as a product and produced more than 1500 iWarp systems. The underlying architecture was based on systolic arrays and data streams being utilized for sending and receiving data between elements on the system. Even though the system was well suited for several applications, Intel stopped actively marketing the product in the mid-90s. It is still a useful tool for research in the parallel computing direction and it was one of the first successful steps towards true parallelism in the early ages of parallel computing.&lt;br /&gt;
&lt;br /&gt;
''Image Processing and Morphology''&lt;br /&gt;
&lt;br /&gt;
A two-dimensional systolic array consisting of cells can be implemented, based on parallel modules which provide internal pipeline operation where every cell can be configured according to a control word. Also, the array can be provided with a group of image buffers, that can reduce the number of accesses to data memory may also extend the array capabilities, allowing the possibility of chaining interconnection of multiple processing blocks.&lt;br /&gt;
&lt;br /&gt;
''Digital Signal Processors''&lt;br /&gt;
&lt;br /&gt;
Low cost, systolic architectural microprocessors utilizes a DSP systolic array, which makes it possible to build low cost ICs capable of providing high speed digital video services. This requires high processing capabilities, and parallelism is a requirement in such areas. Systolic architectures are better suited for such purposes as they are of much lower cost due to their space-efficiency and interconnectivity.&lt;br /&gt;
&lt;br /&gt;
''Tilera Tile64''&lt;br /&gt;
&lt;br /&gt;
Arranged in a two dimensional grid, the Tilera 64 is a tile that has 64 processing elements or cells which are interconnected through a five way switch and it provides a two level hierarchical cache. The architecture is completely based on systolic arrays and this sixty-four element multi-core processor is being released in September 2007. It is already predicted to be utilized extensively in the field of embedded systems for advanced networking, unified thread management, digital video, web services, etc.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''References'''&lt;br /&gt;
&lt;br /&gt;
1. (Reference: Based on ideas presented in the Wikipedia article at:http://en.wikipedia.org/wiki/Systolic_array)&lt;br /&gt;
&lt;br /&gt;
2. Systolic Algorithms: Concepts, Synthesis and Evolution - Siang W.Song, University of Sau Paulo, Department Of Computer Science&lt;br /&gt;
http://citeseer.ist.psu.edu/cache/papers/cs/30734/http:zSzzSzwww.ime.usp.brzSz~songzSzpaperszSzcimpa.pdf/systolic-algorithms-concepts-synthesis.pdf&lt;br /&gt;
&lt;br /&gt;
3. Instruction Systolic Array (ISA) - H.W. Lang, FH Flensburg&lt;br /&gt;
http://www.iti.fh-flensburg.de/lang/papers/isa/isa1.htm&lt;br /&gt;
&lt;br /&gt;
4. Systolic Arrays : Patent Description&lt;br /&gt;
http://www.patentstorm.us/patents/4727503-fulltext.html&lt;br /&gt;
&lt;br /&gt;
5. iWarp&lt;br /&gt;
http://www.cs.cmu.edu/~iwarp/&lt;br /&gt;
&lt;br /&gt;
6. Tilera Tile64&lt;br /&gt;
http://www.tilera.com/products/processors.php&lt;br /&gt;
&lt;br /&gt;
7. FPGA-Based Customizable Systolic Architecture for Image Processing Applications : Proceedings of the 2005 International Conference on Reconfigurable Computing and FPGAs (ReConFig'05) on Reconfigurable Computing and FPGAs - Griselda Saldana, Miguel Arias-Estrada (IEEE Computer Society)&lt;br /&gt;
&lt;br /&gt;
8. Summary of Systolic Architectures (Slides)&lt;br /&gt;
http://web.cecs.pdx.edu/~mperkows/temp/May13/070-Systolic-Processors.pdf&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=File:Systolic04.JPG&amp;diff=3014</id>
		<title>File:Systolic04.JPG</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=File:Systolic04.JPG&amp;diff=3014"/>
		<updated>2007-09-06T02:37:20Z</updated>

		<summary type="html">&lt;p&gt;Arangan: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=File:Systolic03.JPG&amp;diff=3013</id>
		<title>File:Systolic03.JPG</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=File:Systolic03.JPG&amp;diff=3013"/>
		<updated>2007-09-06T02:37:04Z</updated>

		<summary type="html">&lt;p&gt;Arangan: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=File:Systolic02.JPG&amp;diff=3012</id>
		<title>File:Systolic02.JPG</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=File:Systolic02.JPG&amp;diff=3012"/>
		<updated>2007-09-06T02:36:55Z</updated>

		<summary type="html">&lt;p&gt;Arangan: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Arangan</name></author>
	</entry>
</feed>