DE69733623T2

DE69733623T2 - Snoopbus für zerteite transaktionen und arbitrierungsverfahren

Info

Publication number: DE69733623T2
Application number: DE69733623T
Authority: DE
Inventors: Erik Hagersten; Ashok Singhal; David Broniarczyk; Fred Cerauskis; Jeff Price; Leo Yuan; Gerald Cheng; Drew Doblar; Steve Fosth; Nalini Agarwai; Kenneth Harvey; Bjorn Liencres
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1996-03-15
Filing date: 1997-03-14
Publication date: 2006-05-18
Anticipated expiration: 2017-03-15
Also published as: WO1997034237A2; WO1997034237A3; JP2003030131A; JPH11501141A; EP0832459A1; EP0832459B1; DE69733623D1

Description

GEBIET DER ERFINDUNG
Die Erfindung betrifft eine Computerbusarchitektur im Allgemeinen und im speziellen Verfahren für Vorrichtungen zum Implementieren eines geteilten Transaktionsabhörbusses, die diesen abhören, und ein Protokoll für solch einen Bus, zum Erweitern der Kohärenzdomäne über einen Bus hinaus, zum Optimieren globaler Datenantworten, zum Arbitrieren für einen Zugang auf eine gemeinsam genutzte Ressource, und zum Bereitstellen einer einer kurzen Latenz Vorrang gebenden Round-Robin-Arbitrierung eines Zugriffs auf eine geteilte bzw. gemeinsam genutzte Ressource im System.
HINTERGRUND DER ERFINDUNG
Moderne Computersysteme, die Server, Workstations und ähnliches enthalten, haben typischer Weise einige Geräte, so wie Eingabe-/Ausgabe ("I/O" oder "IO") Einheiten, die Leitungen eines Speichers zwischenspeichern bzw. cachen können, oder Zentralprozessoreinheiten (central processors units, "CPUs") oder Mikroprozessoren, und verknüpfte verteilte CPU-Direktzugriffsspeichereinheiten ("RAM"). (Wie hier verwendet, sollen die Begriffe "CPU" und "Gerät" austauschbar verwendet sein.) Die verschiedenen Geräte können miteinander und mit einem RAM kommunizieren durch einen oder mehrere Busse, die verschiedene Information tragen können, die Anforderungen, Befehle, Speicheradressen, Daten und ähnliches enthalten, zwischen den verschiedenen Geräten. Solch eine Information wird in Paketen über eine Busleitung übermittelt, die typischerweise viele Bits breit ist, zum Beispiel 64 Bits oder acht Bytes bei einer Übermittlungsrate, die von der Systemtaktfrequenz betroffen ist.
Der Hauptspeicher eines Computersystems hat üblicherweise eine große Speicherkapazität und ist aber relativ langsam beim Zugreifen auf Daten. Zum Erreichen eines schnelleren Zugriffs auf Daten und zum weniger häufigen Zugreifen auf einen Hauptspeicher haben viele Geräte einen kleinen schnellen Lokalspeicher, Cache genannt. Dieser Cache bzw. Zwischenspeicher wird verwendet zum Speichern einer Kopie von häufig und kürzlich verwendeten Daten, so dass das Gerät auf den Cache anstelle des Hauptspeichers zugreifen kann.
Einige Techniken sind im Fachgebiet bekannt, wodurch ein Gerät Daten zu einer Speicherstelle schreibt, die in seinem Cache sind. In einem sogenannten "Durchschreibe"-Cache ("write through" cache) können Daten sowohl zu dem Cache als auch zum Hauptspeicher geschrieben werden. Alternativ, in einem "Zurückschreib"-(oder "Zurückkopier")-Cache ("write back" cache, "copy back" cache), können die Daten nur zu dem Cache geschrieben werden. In einem Zurückschreib-Cache sind die Daten im Hauptspeicher "gegenstandslos" bzw. "stale" darin, dass sie nicht länger korrekt sind, und nur der Cache hält eine korrekte Kopie der Speicherstelle. Die modifizierte Kopie von Daten in dem Cache wird "unsauber" bzw. "dirty" genannt. Wenn die unsauberen Daten von dem Cache entfernt werden müssen (zum Platzmachen für eine Kopie einer unterschiedlichen Speicherstelle), müssen die unsauberen Daten zurück zum Speicher geschrieben werden. Obwohl die vorliegende Erfindung bezüglich eines Computersystems beschrieben ist, das Zurückschreib-Caches verwendet, könnte die Erfindung auch verallgemeinert werden zum Gebrauch mit Durchschreib-Caches.
Verständlicherweise ist Cache-Kohärenz wichtig. Wenn mehrfache Geräte lokale Kopien derselben Speicherstelle in ihren Caches haben, schreibt ein korrekter Systembetrieb vor, dass alle Geräte dieselben Daten in ihren Caches observieren müssen (da sie zum Halten von Kopien derselben Speicherstelle bestimmt sind). Aber wenn ein oder mehrere Geräte zu ihrer lokalen Kopie der Daten in ihren Caches schreiben, können alle Geräte nicht länger dieselben Daten beobachten. Cache-Kohärenz ist die Aufgabe eines Sicherstellens, dass alle Geräte dieselben Daten in ihren Caches für dieselbe Speicherstelle beobachten. Dies wird getan durch Aktualisieren von Kopien der Daten in allen anderen Caches, oder durch Löschen von Kopien der Daten in allen anderen Caches, wenn irgendein Gerät Daten in seinem Cache modifiziert. Obwohl die vorliegende Erfindung bezüglich eines Gebrauchs mit einem System beschrieben ist, das den zweiten Typ einer Cache-Kohärenz verwendet, kann tatsächlich jeder Kohärenztyp verwendet werden. Man beachte, dass wenn Zurückschreib-Caches verwendet werden, wenn Geräte eine Kopie einer Speicherstelle kopieren wollen, die unsauber in einem anderen Cache ist, die Daten von dem Cache mit den unsauberen Daten erhalten werden müssen, und nicht vom Speicher (da die Daten im Speicher gegenstandslos sind).
Ein sogenanntes Abhörprotokoll (snooping protocol) ist eine übliche Technik zum Implementieren einer Cache-Kohärenz. Jeder Cache hält den Zustand für jede der Speicherstellen in dem Cache aufrecht. Wenn ein Gerät wünscht, eine Speicherstelle zu lesen oder darauf zu schreiben, sendet es seine Anforderung aus, üblicherweise über einen Bus. Diese Anforderung wird beobachtet und überprüft gegenüber dem Zustand durch alle Geräte, z.B. wird die Anforderung "abgehört". Für Lese-Anforderungen antworten Caches mit unsauberen Kopien mit Daten im Gegenteil zu Speicher. Für Schreibanforderungen machen alle anderen Caches ihre Kopie der Daten ungültig oder aktualisieren diese.
Transaktionen involvieren üblicherweise eine Anforderung mit der Adresse, gefolgt durch eine Antwort mit den Daten. In sogenannten "leitungsvermittelten" Bussen muss eine Transaktion vollendet sein, bevor eine nachfolgende Transaktion starten kann. Wenn eine große Verzögerung zwischen der Anforderung und der Antwort vorliegt, bleibt der Bus für die Dauer der Verzögerung im Leerlauf, mit einem resultierenden Verlust von Busbandbreite. Im Gegensatz dazu ermöglichen sogenannte "geteilte Transaktions-" (split transaction) (oder "paketvermittelte") Busse Anforderungen und Antworten für andere Transaktionen zwischen der Anforderung und Antwort für eine gegebene Transaktion. Dies ermöglicht, dass die volle Bandbreite des Busses genutzt wird, selbst wenn Verzögerungen zwischen der Anforderung und der Antwort für eine gegebene Transaktion vorliegen.
Eine CPU, die Daten von einer Speicherstelle lesen möchte, oder Daten zu einer Speicherstelle schreiben möchte, wird typischerweise zuerst ein anforderungsartiges Signal zu dem System aussenden, über einen Systembus. Jedoch können andere Geräte ebenso dasselbe Signal zur selben Zeit über den Bus aussenden müssen. Da aber nur ein Signalwert zu einer Zeit auf dem Bus übermittelt werden kann, müssen die Geräte für die Verwendung des Busses arbitrieren, und ein Arbitrierungsimplementierender Mechanismus wird bereitgestellt. Ferner ist der gemeinsame Systembus, der diese Anforderungen und die Daten und andere Signale trägt, eine endliche Ressource, deren Übermittlungsbandbreite durch die Anzahl von Bitleitungen und die Systemtaktrate fixiert ist.
Der gemeinsame Systembus, der diese Anforderungen und die Daten und andere Signale trägt, ist eine endliche Ressource, dessen Übermittlungsbandbreite durch die Anzahl von Bitleitungen und die Systemtaktrate fixiert ist. Selbst mit einem raschen Mechanismus zum Arbitrieren möglicher widerstreitender Anforderungen und zum Bewilligen von Zugriffsanforderungen, ist ein Maximieren des Bussystemdurchsatzes und einer Antwort eine Herausforderung. Arbitrierungsmethoden nach dem Stand der Technik legen zum Beispiel eine Latenzstrafe von zwei Taktzyklen oder mehr auf.
Systeme nach dem Stand der Technik sind komplex aufgrund der Notwendigkeit eines Handelns mit eine gemeinsamen Adresse involvierende mehrfachen Transaktionen. Zum Reduzieren solcher Mehrdeutigkeiten müssen solche Systeme "schwebende" ("pending") oder "transiente" Zustände definieren, was eine weitere Komplexität zu der gesamten Implementierung beiträgt. Versuche nach dem Stand der Technik, eine Flusssteuerung aufzuerlegen und Kollisionsmehrdeutigkeiten zu vermeiden in solchen Systemen, sind auch beschwerlich.
In manchen Systemen, wo eine Datenanforderung nicht unmittelbar auf die Anforderung folgend vollendet ist, müssen komplizierte Mechanismen eingesetzt werden zum Sicherstellen, dass die Anforderung letzten Endes vollendet ist. In einem System, in dem Speicher verteilt ist, ist es herausfordernd, eine Kohärenzdomäne rasch aufrechtzuerhalten, z.B. Speicherplatz, der immer kohärent auf rechterhalten ist. Eine Transaktionsanforderung zum Lesen von Daten von einer Speicherstelle, die gegenwärtig ungültige Daten hält, kann nicht rasch vollendet werden nach dem Stand der Technik. Zuerst muss die Speicherstelle mit gültigen Daten umgeschrieben werden, und dann können die gültigen Daten zu dem Anforderer bereitgestellt werden. Prozeduren nach dem Stand der Technik zum Implementieren dieser Prozesse in einem abhörenden geteilten Transaktionsbussystem sind komplex und zeitraubend.
Die Architektur für ein geteiltes Transaktionsabhörbussystem sollte sich vorzugsweise hergeben zum Verwenden in einem System, das mehrere solche Bussysteme erfordert, zum Beispiel ein Netzwerk mit mehrfachen Workstations. In einem ein einzelnes Bussystem umfassenden Computersystem bestimmt die Reihenfolge, in der Transaktionen auf dem Adressbus platziert werden, eine absolute Temporal- oder Zeitbeziehung. Wenn eine durch eine CPU A initiierte Transaktion auf dem Bus vor einer durch CPU B initiierten Transaktion erscheint, betrachtet das Computersystem Transaktion A unwiderruflich als Transaktion B vorhergehend. Unglücklicherweise halten solche stark vereinfachenden Annahmen nicht länger in einem System, welches eine Vielzahl von solchen Computersystemen beinhaltet, mit einer Vielzahl von Bussystemen. Solch ein Beispiel kann ein Netzwerk sein, das mindestens zwei Workstations umfasst.
In einem Sub-Computersystem mit einem einzelnen Bussystem kann eine eindeutige Reihenfolge von Transaktionen durch die Temporalreihenfolge definiert sein, in der Adresspakete auf dem Adressbus innerhalb des Bussystems erscheinen. In einem System, das eine Vielzahl von solchen Sub-Systemen umfasst und das eine Vielzahl von solchen Bussystemen hat, ist es jedoch sowohl erforderlich als auch sehr schwierig, eine globale Reihenfolge für Transaktionen zu definieren. Eine CPU im Sub-System 1 will zum Beispiel Daten zu einer Speicherstelle schreiben, die in irgendeinem Sub-System sein könnte, einschließlich Sub-System 1. Zu exakt derselben Zeit könnte eine CPU in einem anderen Sub-System Daten zu derselben oder anderen Speicherstelle schreiben wollen. Die Frage ist dann, wie eine globale Ordnung zwischen diesen zwei gleichzeitigen Transaktionen definiert werden kann.
Die resultierende Ungewissheit kann Probleme beim Ausführen von Routinen schaffen, in denen eine Transaktionsreihenfolge kritisch sein kann. Ferner kann die Unfähigkeit zum effektiven Definieren einer globalen Transaktionsreihenfolge in dem Stand der Technik für solche Systeme auch in einer Systemblockade resultieren. Somit gibt es einen Bedarf für einen Mechanismus zum raschen Ausführen eines Unterstützens der kohärenten Domäne in einem Computersystem, einschließlich ein Abhören des geteilten Transaktionsbussystems einsetzende Computersysteme. Wenn gültige Daten geschrieben werden zum Aktualisieren eines Speichers, der ungültige Daten enthält, die Gegenstand einer Anforderung sind, sollte solch ein Mechanismus vorzugsweise gleichzeitig die Originale der Daten-involvierenden Transaktion erneut ausgeben.
Wie bemerkt, ist ein Mechanismus erforderlich zum Arbitrieren eines Zugriffs auf gemeinsam genutzte Ressourcen, so wie den Systembus. In dem sogenannten fairen Algorithmus nach dem Stand der Technik bewilligt der Arbitrierer einen Buszugriff auf CPUs in der Reihenfolge, in der die Anforderungen ankommen. Somit wird ein Zugriff der CPU bewilligt, deren Anforderung die längste Zeit schwebend bzw. anhängig gewesen ist. Keine Priorität einer Wichtigkeit ist den individuellen CPU-Anforderungen zugewiesen, und das alleinige Kriterium ist die Zeitreihenfolge der verschiedenen Anforderungen. Ein Vorteil des fairen Algorithmus ist, dass es keinen Bedarf gibt, eine mit den verschiedenen CPU-Anforderungen verknüpfte komplizierte Vergangenheit zu speichern.
Ein anderes Verfahren nach dem Stand der Technik ist der sogenannte Round-Robin-Algorithmus, bei dem eine zyklische Reihenfolge unter den CPUs definiert ist, so dass die Identität der favorisiertesten Anforderer-CPU sich bewegt. Das heißt, wenn CPU N die jüngste Arbitrierungsbewilligung empfing, dann soll CPU N + 1 die nächste Bewilligung empfangen, wenn CPU N + 1 eine Anforderung erklärt bzw. geltend macht. Während Round-Robin-Algorithmen bei Computersystemarchitekten Gefallen gefunden haben, sind solche Algorithmen schwierig zu implementieren mit einer geringen Logiktiefe. Jedoch verbraucht die Verwendung von Round-Robin einer tiefen hierarchischen Ebene zu viele Taktzyklen, um den Bewilligungsgewinner zu bestimmen, weil Gewinner bei jedem einer Vielzahl von niedrigeren Ebenen bestimmt werden müssen, wonach ein Gewinner bestimmt wird aus den Gewinnern einer niedrigeren Ebene. Während ein schnellerer aber relativ "flacher" oder nicht-hierarchischer Round-Robin implementiert werden kann, in dem keine Logiktiefe ist, z.B. alle Anforderungen auf einer gemeinsamen Logikebene verarbeitet werden, existiert immer noch eine Logikgatterkomplexität.
Ein anderer Algorithmus nach dem Stand der Technik gibt den verschiedenen CPUs statisch Vorrang. Somit wird CPU 0 permanent eine höchste Priorität zugewiesen, CPU 1 wird die nächsthöchste Priorität zugewiesen und so weiter. Als ein Ergebnis kann CPU 2 eine Arbitrierungsbewilligung nicht empfangen, wenn nicht weder CPU 0 noch CPU 1 gegenwärtig einen Buszugriff anfordern. Diese Methode eines statischen Vorranggebens hat den Vorteil, dass sie besonders einfach zu implementieren ist.
Bei Verwenden irgendeiner der obigen Techniken, während die anfordernde CPU, die eine Buszugriffsbewilligung von dem Arbitrierer empfängt, Zugriff erlangt, müssen die Anforderungen von anderen anfordernden CPUs in einem blockierten oder schwebenden Zustand warten. Dieser Zustand fährt so lange fort, bis die anfordernde CPU ihre Arbitrierungsbewilligung empfängt, ihre Daten oder gewünschte Adressen oder andere Signale auf dem Bus platziert und somit ihre Transaktion vollendet.
In dem Stand der Technik, ungeachtet des Mechanismus, der verwendet wird zum Arbitrieren konkurrierender Anforderungen für einen Zugriff auf den Bus, würde eine Arbitrierungsleitung für Daten verwendet werden, und eine zweite Arbitrierungsleitung würde für Adressen verwendet werden. Während der Zeit von Arbitrierung, Bewilligung und Zugriff durch die den Bewilligungszugriff gewinnende CPU sind andere schwebende Anforderungen wie bemerkt temporär geblockt während eines Wettkampfs bzw. einer Konkurrenz der ersten bewilligten Anforderung.
Während solche Techniken arbeiten, kann die Latenzstrafe übermäßig sein, darin dass viele Taktzyklen passieren müssen zwischen einer ersten CPU-Anforderung, einer Bewilligung einer Arbitrierung zu dieser CPU, einem CPU-Zugriff auf dem Bus und dann einer Bewilligung einer Arbitrierung und eines Buszugriffs für den nächsten Anforderer zum Empfangen eines Buszugriffs. Somit gibt es einen Bedarf für ein Verfahren und eine Vorrichtung zum Arbitrieren eines Zugriffs auf einen Bus, in welchem Blockiermechanismen nicht verwendet werden und in welchem eine minimale Latenzzeit erreicht wird.
Ferner gibt es einen Bedarf für ein Architekturprotokoll für ein Bussystem, das geteilte Transaktionen und Abhören erlaubt. Vorzugsweise sollte solch eine Architektur eine große Anzahl von CPUs und beträchtlich Speicher unterstützen, während eines Bereitstellens von guter Busbandbreite und geringer Latenz. Mehrere Transaktionen sollten gleichzeitig fortschreiten dürfen, und eine einfache Flusssteuerung sollte bereitgestellt werden ohne Auferlegen von Blockieren, mehrfachen Wiederversuchszyklen, schwebenden oder transienten Zuständen. Solch ein Protokoll sollte größeren Systemen erlauben, einiger solcher geteilter Transaktionsabhörbussysteme zu enthalten. Die vorliegende Erfindung stellt solch ein Arbitrierungsverfahren und -Vorrichtung bereit, als auch ein Verfahren und eine Vorrichtung zum Implementieren eines solchen gewünschten Abhörens auf einem geteilten Transaktionsbus, und stellt solch einen Bus und ein Protokoll für denselben bereit.
EP 0 559 409 offenbart ein Datenverarbeitungssystem und ein Verfahren zum Durchführen eines Abhörwiederversuchsprotokolls mit Verwenden eines Arbiters. Mehrfache Busmaster sind an mehrfache gemeinsam genutzte Busse gekoppelt. Jeder Busmaster kann eine Bustransaktion initiieren ("Initiierungs-Master"), oder die Bustransaktion abhören ("Busabhör-Master"), die auf einem gemeinsam genutzten Bus auftreten. Wenn ein initiierender Prozessor einen Zugriff auf eine unsaubere Cache-Leitung in einem Speicher anfordert, macht ein Abhörbus-Master ein Signal eines Wiederversuchs einer gemeinsam genutzten Adresse geltend, um den initiierenden Prozessor zu informieren, den Besitz des gemeinsam genutzten Busses abzugeben und die Bustransaktion wieder zu versuchen. Beim Detektieren des Signals eines Wiederversuchs einer gemeinsam genutzten Adresse entfernen alle möglichen Bus-Master ihre Busanforderungen und ignorieren irgendwelche Busanforderungen von dem Arbiter, und ermöglichen somit das Abhörverarbeiten, welches das ARTRY*-Signal geltend machte, um den Besitz des gemeinsam genutzten Busses zu erlangen, um das Abhörzurückkopieren durchzuführen. Der Arbiter stellt eine einfache Arbitrierungsunterstützung bereit, um zu garantieren, dass die Aktualisierung des Speichers 18 die höchste Priorität unter den Mastern hat.
WO 9524678 offenbart ein Computersystem, das einen gepipelineten Bus einschließt, der Datenkohärenz aufrechterhält, Lang-Latenz-Transaktionen unterstützt und eine Prozessorreihenfolge wie beschrieben bereitstellt. Das Computersystem beinhaltet Busagenten mit In-Reihenfolge-Warteschlangen, die mehrfache unerledigte Transaktionen über einen Systembus verfolgen, und die Abhören durchführen in Antwort auf Transaktionsanforderungen, die die Abhörergebnisse und modifizierte Daten innerhalb einer Transaktion bereitstellen. Zusätzlich unterstützt das System Lang-Latenz-Transaktionen durch Bereitstellen zurückgestellter Identifizierer während Transaktionsanforderungen, die verwendet werden zum erneuten Starten von zurückgestellten Transaktionen.
EP 0,669,578 offenbart eine Kohärenzmethode im Gebrauch mit einem System mit einem Bus, einem Hauptspeicher, einer Hauptspeichersteuereinheit zum Zugreifen auf den Hauptspeicher als Antwort auf auf dem Bus empfangene Transaktionen und einen Satz von an den Bus gekoppelten Prozessormodulen. Jedes Prozessormodul hat einen Cache-Speicher und ist fähig zum Übermitteln von kohärenten Transaktionen auf dem Bus zu anderen Prozessormodulen und zu der Hauptspeichersteuereinheit. Jedes Prozessormodul detektiert auf dem Bus ausgegebene kohärente Transaktionen und führt Cache-Kohärenzüberprüfungen für jede der kohärenten Transaktionen durch. Jedes Prozessormodul hat eine Kohärenzwarteschlange zum Speichern aller auf dem Bus ausgegebenen Transaktionen und zum Durchführen von Kohärenzüberprüfungen für die Transaktionen in einer Zuerst-Rein, Zuerst-Raus-Reihenfolge. Wenn ein Modul eine kohärente Transaktion auf einem Bus übermittelt, platziert es seine Transaktion in seine eigene Kohärenzwarteschlange.
ZUSAMMENFASSUNG DER ERFINDUNG
Die vorliegende Erfindung betrifft Verfahren und Vorrichtungen zum Implementieren eines geteilten Transaktionsabhörbusses und eines Busprotokolls und eines Busabhörens. Ein geteiltes Transaktionsabhörbusprotokoll und eine Architektur sind bereitgestellt zum Gebrauch in einem System, das einen oder viele solcher Busse hat.
Gemäß der vorliegenden Erfindung sind ein geteiltes Transaktionsbusprotokoll und ein System gemäß dem beigefügten Anspruch 1 bereitgestellt, und ein Verfahren zum Betreiben eines geteilten Transaktionsbusses gemäß dem beigefügten Anspruch 13. Bevorzugte Ausführungsformen sind in den abhängigen Ansprüchen definiert.
Andere Merkmale und Vorteile der Erfindung werden aus der folgenden Beschreibung ersichtlich werden, in der die bevorzugten Ausführungsformen detailliert bekannt gemacht worden sind, in Verbindung mit den begleitenden Zeichnungen.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1 veranschaulicht einen Teil eines lokalen Netzwerksystems, in welchem mehrfache Bussysteme sind, wobei jedes Bussystem Schnittstellen bildet zu Board-befestigten Geräten, gemäß einer bevorzugten Ausführungsform, mit der die vorliegende Erfindung betrieben ist;
2 ist eine detaillierte Beschreibung einer Steckleiterplatte wie in 1 gezeigt;
3 ist eine detaillierte Beschreibung eines Pufferns innerhalb einer Platinenadresssteuereinheit, so wie in 1 gezeigt;
4 veranschaulicht eine Latenz zwischen einem Treiben des Daten-ID-Busses bzw. DataID-Busses und Treiben des Daten-Busses bzw. Data-Busses für das System von 1;
5 veranschaulicht eine Latenz, die mit Adressbus- und Signalbusparitätsvergleichen für das System von 1 verknüpft ist;
6 veranschaulicht ein Signalzeitverhalten, das mit einem Verfahren einer Schnell-Modus-Arbitrierung verknüpft ist, die nicht zu der vorliegenden Erfindung gehört;
7 veranschaulicht ein Signalzeitverhalten, das mit einem Verfahren einer Schnell-Modus-Arbitrierung verbunden ist in der Gegenwart einer Kollision, nicht zu der vorliegenden Erfindung gehörend;
8 ist eine detaillierte Veranschaulichung einer Adresssteuer-Arbitrierungseinheit für das System von 1, nicht zu der vorliegenden Erfindung gehörend.
DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM
Hinsichtlich der vorliegenden Erfindung gibt es einige Facetten, einschließlich Bereitstellen einer geteilten Transaktionsabhörbusarchitektur und eines Protokolls, so wie Abhören auf einem geteilten Transaktionsbus. Obwohl ein geteiltes Transaktionsabhörbussystem gemäß der vorliegenden Erfindung typischerweise in einem System ohne andere Bussysteme verwendet werden kann, kann die vorliegende Erfindung auch in größeren Systemen betrieben werden, die einige solcher geteilten Transaktionsabhörbussysteme beinhalten. Die vorliegende Erfindung stellt auch eine niedrige Latenz bereit, einen verteilten hierarchischen Round-Robin-Typ-Mechanismus zum raschen Arbitrieren eines Zugriffs auf eine gemeinsam genutzte Systemressource in einer Computerumgebung, nämlich einen durch viele CPUs gemeinsam genutzten Adressbus.
In einer bevorzugten Ausführungsform, in einem bevorzugten abhörenden geteilten Transaktionsbussystem, stecken CPU-Geräte enthaltende Leiterplatten und verteilter Speicher in der Busschnittstelle. Bussystemebene-Busse können durch eine globale Netzwerkschnittstelle gekoppelt sein, um ein Sammelsystem zu bilden. Bei der Sub-Systemebene stecken Leiterplatten, die Geräte einschließen, z.B. CPUs und/oder verteilten Speicher, in einem oder mehreren geteilten Transaktionsabhörbussystemen. Jede Leiterplatte enthält vorzugsweise weiter Dateneingabe- und Ausgabepuffer einschließlich eines Bit-Slice-Datenpuffers und eines DTAG-RAM-Puffers, Anforderungsmarkierungswarteschlangen einschließende Warteschlangen und eine Adresssteuereinheit, die einen Arbitrierungsmechanismus implementiert, der über mögliche konkurrierende Anforderungen von verschiedenen Geräten zum Zugreifen auf das Bussystem entscheidet. Vorzugsweise ist ein einziger Arbitrierungsbus gemultiplext, um Adressbus- und Datenbusanforderungstransaktionen zu tragen, und eine Zeit zwischen einer Anforderung und einer Antwort ist variabel aber vorzugsweise so kurz wie zwei Taktzyklen. Adress- und Datenbustransaktionen sind vorzugsweise jede zwei Taktzyklen lang.
Eine mit jeder Adresssteuereinheit verknüpfte kohärente Eingangswarteschlange (Coherent Input Queue, "CIQ") enthält Transaktionen, die durch verknüpfte Geräte angefordert sind, deren Transaktionen über den Bus oder das Sammelsystem (hier im nachfolgenden "Bus/Sammelbus") geltend gemacht werden sollen. Alle Geräte hören den Adressbus ab zum Lernen von Paketadressen und Leiterplattenmarkierungsspeicher ("Gerät-Ebenen-Markierungen" bzw. "Vorrichtungs-Ebenen-Markierungen") ("device-level tags"), ob die identifizierte Leitung besessen oder gemeinsam genutzt bzw. geteilt ist. Eine Platine mit einer zwischengespeicherten bzw. gecacheten Kopie der Leitung macht ein Geteiltsignal geltend, und eine die Leitung besitzende Platine macht ein Besitzsignal geltend. Empfang eines Ignorierungssignals verhindert ein Laden von Transaktionen in die kohärente Eingangswarteschlange, was ein Auftreten der Transaktion auf dem Systembus zurückstellt, bis ein Ignorieren nicht länger geltend gemacht ist. Wenn entgeltend bzw. nicht-geltend gemacht, ist dieselbe Transaktion, die auf die Originalstelle im verteilten Speicher zuzugreifen versucht, in die CIQ geladen und kann auf dem Bus/Sammelbus-System als eine gültige Transaktion erscheinen, wodurch die Transaktionsreihenfolge wie gewünscht verändert ist.
In einer Ausführungsform stellt die globale Netzwerksschnittstelle einen Mechanismus bereit, der ein IGNORIEREN-Signal erzeugt, und der Speicher einschließt, der eine Tabelle von Zustandsinformation für alle Cache-Leitungen in unter den verschiedenen Leiterplatten verteilten Speichersystem startet. Eine Transaktion wird ignoriert werden, wenn der globale Netzwerkschnittstellenmechanismus bestimmt, dass ein globales Transaktions-Neuordnen auferlegt werden muss. Ein geltend gemachtes IGNORIEREN-Signal verhindert ein Laden solcher Transaktionen in die CIQ, was verhindert, dass die Transaktion zu dieser Zeit geordnet wird. Die Transaktion kann später erneut ausgegeben werden ohne Geltendmachung des IGNORIEREN-Signals. Auf diese Weise erlaubt die vorliegende Erfindung, dass ein optimales globales Transaktions-Neuordnen ausgeführt wird. Aber für solch globales Neuordnen könnte ein Antworten auf eine Datenanfordernde geltend gemachte Transaktion darin resultieren, dass der Anforderer mit einer gegenstandslosen Version der gewünschten Daten beliefert wird.
Besitz der angeforderten Speicherleitung wird unmittelbar bei einer Zeit einer Anforderung übertragen, zum Beispiel, bevor die angeforderten Daten empfangen sind durch die anfordernden Geräte. Die vorliegende Erfindung implementiert eine Markierungspipelineumgehung, und geltend gemachte Anforderungen werden in eine Warteschlange eingereiht, so dass Zustandstransaktionen auf dem Adressbus atomar, logisch, ohne Abhängigkeit von der Anforderung auftreten. Nachfolgende Anforderungen für dieselben Daten werden markiert, so dass sie die Verantwortlichkeit des Besitzer-Anforderers werden, selbst wenn die gewünschten Daten noch nicht übertragen worden sind. Zum Unterstützen eines hohen Durchsatzes werden Aktivitäten eines nachfolgenden Anforderers nicht angehalten beim Warten auf eine Bewilligung und Vollendung einer früheren Anforderungstransaktion. Prozessor-Ebenen-Cache verändert den Zustand beim Empfang von Transaktionsdaten.
Gemäß einer nicht zu der vorliegenden Erfindung gehörenden Anordnung ist eine neue Transaktion für Schreibtypoperationen eine ReadToShareFork-Transaktion. Diese Transaktion ermöglich dem System, gleichzeitig gültige Daten zu einer angeforderten Speicheradresse zu schreiben, die gegenwärtig gegenstandslose oder korrupte Daten hält, und schnell zu bewirken, dass die Daten zu dem originalen bzw. ursprünglichen Anforderer geliefert oder durch diesen aufgenommen bzw. geholt werden. Kohärenz ist somit in einem verteilten Speichersystem aufrecht erhalten, während ermöglicht ist, dass die ursprüngliche angeforderte Transaktion im Wesentlichen früher vollendet werden kann, als das in dem Stand der Technik der Fall sein könnte.
Wenn gültige Daten zu einer angeforderten Speicherstelle geschrieben sind zum Speicheraktualisieren, wird die unerledigte Transaktion zum Lesen der Daten zum Wiederausgeben veranlasst, mit Verwenden derselben Speicheradresse und Transaktions-Quellen-ID-Information (transaction SourceID information). Jedoch treten beide "Transaktionen" gleichzeitig auf durch in der Hauptsache gleichzeitiges Senden der gültigen Daten zu zwei Bestimmungsorten.
In einem anderen Aspekt werden ein geteiltes Transaktionsabhörbusprotokoll und eine Architektur bereitgestellt zum Gebrauch in einem System mit einem oder vielen solchen Bussen. Leiterplatten, die Geräte beinhalten, z.B. CPUs und/oder verteilten Speicher, stecken in einem oder mehreren geteilten Transaktionsabhörbussystemen. Jede Leiterplatte enthält vorzugsweise ferner Dateneingangs- und Ausgangspuffer, die Bit-Slice-Datenpuffer und einen DTAG-RAM-Puffer enthalten, Anforderungsmarkierungswarteschlangen enthaltende Warteschlangen, und eine Adresssteuereinheit, die einen Arbitrierungsmechanismus implementiert, der ein Urteil fällt über mögliche konkurrierende Anforderungen von verschiedenen Geräten zum Zugreifen auf das Bussystem.
Vorzugsweise ist ein einzelner Arbitrierungsbus gemultiplext zum Tragen von Adressbus- und Datenbusanforderungstransaktionen, und Adress- und Datenbustransaktionen sind jede Zweier-Zyklen lang. Der Adressbus und Arbitrierungsbus sind jeder in demselben Zyklus getrieben, was eine Bandbreite unterstützt. Die Zeit zwischen einer Anforderung und einer Antwort ist variabel, aber kann so kurz wie zwei Takt-Zyklen sein.
In einem Computersystem, in welchem viele CPUs auf einen geteilten bzw. gemeinsam genutzten Systembus zugreifen können, der separate Adress- und Arbitrierungsbusse beinhaltet, unter anderen Bussen, muss der Zugriff auf den Adressbus rasch arbitriert werden. Die vorliegende Erfindung stellt auch einen Round-Robin-Typ-Arbitrierungsmechanismus einer verteilten niedrigen Latenz bereit, der die Vorteile einer Vorrang gegebenen Arbitrierung bereitstellt, aber auf eine hierarchische Weise. In der bevorzugten Implementierung ist ein elementarer Zweier-Takt-Zyklus verwendet, wobei jedes Adressbuspaket und jedes Datenbuspaket zwei Zyklen erfordern.
Vorzugsweise sind zwei CPUs und verknüpftes RAM auf jeder von einer Vielzahl von Karten bereitgestellt, die in dem geteilten bzw. gemeinsam genutzten Systembus im Betrieb eingesteckt werden können. Jede Karte beinhaltet eine Adresssteuereinheit, die den Arbitrierungsmechanismus mit einer Zwei-Ebenen-Hierarchie implementierende Logik enthält: Einen einzelnen Kopf-Arbitrierer und vorzugsweise vier Blatt-Arbitrierer. Zwischen dem Kopf-Arbitrierer und jedem Blatt-Arbitrierer gibt es eine aufwärts gerichtete Anforderungsleitung ("rout"), eine aufwärts gerichtete Gewinner-nach-rechts (winner-to-the-right, "wrgt") Leitung, und eine abwärts gerichtete Bewilligungsleitung ("win"). Jeder Blatt-Arbitrierer hat vier Anforderungseingangsleitungen (request in lines, "rin"), wobei jede solche Leitung zu einer einzelnen durch diesen Blatt-Arbitrierer bedienten CPU gekoppelt ist.
Eine CPU, die für den Adressbuszugriff arbitrieren möchte, initiiert, eine Anforderung an den Kopf-Arbitrierer durch die rin-Leitung zu dem Blatt-Arbitrierer, an den sie gekoppelt ist. Jeder lokale Blatt-Arbitrierer arbitriert unter den Null bis vier Anforderungen, die auf seinen rin-Leitungen vorliegen können und entscheidet über den Gewinner unter seinen Anforderern und gibt ein Signal auf der rout-Leitung an den Kopf-Arbitrierer aus, der anzeigt, dass er eine Zugriff-wünschende CPU hat. Den rin-Leitungen wird Vorrang gegeben, so dass vom Prioritätsbegriff her gilt CPU0>CPU1>CPU2>CPU3. Ein Zeigermechanismus eines letzten Gewinners (Last Winner, "LW") ist in jedem Blatt-Arbitrierer anwesend und bewegt sich nach rechts nach einer Arbitrierungsgewährung, deren Positionsänderung zu dem Kopf-Arbitrierer über die wrgt-Ausgabeleitung gekoppelt ist. Aus der Perspektive des Kopf-Arbitrierers wird den Blatt-Arbitrierern Vorrang gegeben, so dass der erste Blatt-Arbitrierer eine Priorität hat über den zweiten Blatt-Arbitrierer, der Priorität hat über den dritten Blatt-Arbitrierer, der Priorität hat über den vierten Blatt-Arbitrierer.
Die Adresssteuereinheit einer jeden Karte kommuniziert mit dem Arbitrierungsbus (unter anderen Bussen), was dem Arbitrierungsmechanismus erlaubt, auf jeder Karte gleichzeitig und synchron alle Arbitrierungsanforderungen und Kopf-Arbitriererbewilligungen zu sehen, und identische LW-Zustände zu haben.
Blatt-Ebene-Arbitrierung ist autonom und geschieht parallel. Wenn zum Beispiel CPU0 das letzte Mal eine Blatt-Ebene-Arbitrierung gewann, ist sie nun ausgeschlossen und Blatt-Arbitrierer 1 wird eine Bewilligung für seine CPU1 anfordern, wenn er Zugriff anfordert. Innerhalb des zweiten Blatt-Arbitrierers, wenn CPU5. letztes Mal gewann, ist sie ausgeschlossen und CPU6 kann nun gewinnen (wenn sie anfordert). Bei der Kopf-Arbitrierer-Ebene, wenn der erste Blatt-Arbitrierer letztes Mal eine Bewilligung gewann, ist er nun ausgeschlossen, und der zweite Blatt-Arbitrierer gewinnt, das heißt, dass dessen CPU6 die Arbitrierungsbewilligung gewinnen kann.
Letzter-Gewinner-Zeiger werden synchron einmal pro Systemtaktzyklus zurückgestellt. Eine niedrige Latenz ergibt sich bei der bevorzugten Ausführungsform, weil ein Adresspaket gleichzeitig mit Arbitrierung für den Adressbus ausgesendet werden kann. Dies ist schneller als Methoden nach dem Stand der Technik von zuerst Arbitrieren und dann Ausgeben des Adresspaketes. Die Arbitrierung ist verteilt darin, dass jede Adresssteuerung eine autonome Arbitrierungseinheit enthält. Während eine Blatt-Ebene-Arbitrierung unterwegs ist, kann der Kopf-Arbitrierer von seinem LW-Zeiger entscheiden, welcher Blatt-Arbitrierer die Arbitrierungsbewilligung gewinnen soll.
Zum Veranschaulichen des allgemeinsten Falles zeigt 1 ein elektronisches globales Netzwerksystem 10, das einen globalen Netzwerkschnittstellenmechanismus 15 beinhaltet, zu welchem eine Vielzahl von geteilten Bussystemen 20, 20', etc. gekoppelt ist. (Während nur zwei Bussysteme zur einfachen Veranschaulichung gezeigt sind, sollte verstanden werden, dass mehr als zwei solcher Systeme vorliegen können.) Jedes geteilte Bussystem umfasst mehrere Busse (noch zu beschreiben), die durch eine Schnittstellenarchitektur 30, 30' über eine Vielzahl von Leitungen, z.B. 40-N, an jede einer Vielzahl von vorzugsweise identischen Einsteckkarten 50-N gekoppelt sind.
Schnittstellenmechanismus 15 enthält einen Ignorierungssignalgeneratormechanismus 17 und Speicher, der eine Tabelle 19 aller Cache-Leitungen in dem unter Boards 50-N, 50'N etc. verteilten Speicher speichert.
In der bevorzugten Ausführungsform ist System 10 eine Computer-Workstation und Schnittstelle 30 definiert ein geteiltes Transaktionsabhörbussytem mit Ungültigkeitserklärungs-basierter Cache-Kohärenz zwischen Boards 50-N.
Insgesamt kann die Ansammlung von Bussystemen 20, 20' etc. als ein Sammelbussystem 20'' für das gesamte System 10 bezeichnet werden. Es sollte verstanden werden, dass die hier beschriebene vorliegende Erfindung jedoch auch für ein System verwendet werden kann, in welchem ein einzelnes Bussystem 20 und eine einzelne Busschnittstelle 30 vorliegt.
In einem ein einzelnes Bussystem, z.B. Bus 20, umfassendes Computersub-System bestimmt die Reihenfolge, in welcher Transaktionen auf dem Adressbus platziert sind, eine absolute und eindeutige Temporalbeziehung. Somit, wenn eine durch CPU A (z.B. ein Typ eines Gerätes) initiierte Transaktion auf dem Bus vor einer durch CPU B initiierten Transaktion erscheint, betrachtet das Computersystem unwiderruflich Transaktion A als Transaktion B vorhergehend. Unglücklicherweise halten solche stark vereinfachenden Annahmen nicht länger im System 10, welches eine Vielzahl von solchen Computersub-Systemen enthält, mit einem Merkmal von Bussystemen, die zusammen Sammelbussystem 20'' bilden. Es ist die Aufgabe vom Ignorierungsmechanismus 17, eine optimale globale Transaktionsreihenfolge für Gesamtsystem 10 zu definieren.
Leiterplatten 50-N sind innerhalb von System 10 zusammengeschaltet und stecken physikalisch in einem von vorzugsweise 16 identischen Platteneinsteckplätzen, von denen vorzugsweise acht auf jeder Seite einer mit jedem Computersub-System verknüpften Centerplane sind. Irgendeiner der Steckplätze kann durch eine Einsteckleiterplatte gefüllt sein, die mehrfache CPUs und verknüpftes RAM enthält, oder ein Eingabe-/Ausgabe ("I/O" oder "IO") Gerät, das vorzugsweise zwei S-Busse (Sbuses) enthält. Wie viel später hier beschrieben, können die Boards 50-N eingesteckt werden, während System 10 hochgefahren ist oder "spannungsführend" bzw. "heiß" ist. In der bevorzugten Ausführungsform ist die Centerplane-Taktrate ungefähr 83,3 Mhz und die verknüpfte Busdatenbandbreite ist ungefähr 2,67 GB/sec.
Jede Leiterplatte enthält vorzugsweise eine oder zwei Universal-Anschluss-Architektur (Universal Port Architecture "UPA") kompatible CPU-Geräte, z.B. Geräte mit einer spezifischen Schnittstelle, und vorzugsweise einen Schreiblesespeicher (Random Access Memory, "RAM").
2 veranschaulicht Bussystem 20 und eine typische Einsteckleiterplatte 50-N in weiterem Detail. In 2 bezeichnen durchgezogene Weglinien Datenpfade und gestrichelte Weglinien (z.B. von Adresssteuereinheit 180 zu Adressbus 60) bezeichnen Adresspfade. Wie hier beschrieben implementiert eine verteilte Arbitrierungs-("ARB")Einheit 186 innerhalb von Adresssteuereinheit 180 einen Aspekt der vorliegenden Erfindung.
2 veranschaulicht Bussystem 20 und eine typische Einsteckleiterplatte 50-N in weiterem Detail. In 2 bezeichnen durchgezogene Weglinien Datenpfade und gestrichelte Weglinien (z.B. von Adresssteuereinheit 180 zu Adressbus 60) bezeichnen Adresspfade. Eine vorzugsweise Arbitrierungs-("ARB")Einheit 186 innerhalb von Adresssteuereinheit 180 arbitriert einen Zugriff auf einen verknüpften Adressbus. Innerhalb von Arbitrierungseinheit 186 stellen Elemente A, B, C und D Blatt-Ebene-Arbitrierer dar, und Element E stellt einen Kopf-Ebene-Arbitrierer dar. Jeder Blatt-Ebene-Arbitrierer arbitriert für einen Buszugriff bei der Blatt-Ebene, und der Kopf-Ebene-Arbitrierer arbitriert einen Buszugriff unter wettstreitenden Blatt-Ebene-Gewinnern.
Wie in 2 gezeigt, enthält jede Platte 50-N eine vorzugsweise bitgestückelte (bit-sliced) Datenpuffersteuereinheit 140, die mit Datenbus 70 kommuniziert (über eine Leitung im Leitungsbündel 40-N), als auch mit Board-RAM 150-N, und UPA CPU-Geräten 160-N und/oder 170-N oder I/O-Einheiten. Datenpuffereinheit 140 enthält vorzugsweise 8 bitgestückelte integrierte Schaltkreis (Integrated Circuit) ("IC") Chips, die Daten zwischen Übertragungen zwischen UPA-Anschlüssen, Speicher und Bussystem 40 puffern.
Jedes Board 50-N enthält weiter eine Adresssteuereinheit 180, die mit allen Signalen kommuniziert (über Leitungen im Leitungsbündel 40-N), außer Datenbus-Signalen (DataBus), z.B. mit Adressbus (Address Bus) 60, mit Daten-ID-Bus (DataID Bus) 90, mit dem Arbitrierungsbus (Arbitration Bus) 80 und mit den Konfigurationssignalen 130. In Adresssteuereinheit 180 sind eine Kohärenzeingangswarteschlange (Coherent-In Queue, bzw. "CIQ") 182, ein Warteschlangenpuffer (Queue Buffer) ("QB") 184 und ein verteilter Arbitrierungsmechanismus ("ARB") 186 enthalten, gemäß der vorliegenden Erfindung.
Adresssteuereinheit 180 erzeugt Steuersignale, die über Pfad 190 zu der Datensteuereinheit (Data Controller) 140 übertragen sind. Signalzeitverhalten auf dem Datenbus 70, dem Adressbus/Zustandsbus (AddressBus/State Bus) 60, dem Arbitrierungsbus 80, und dem Daten-ID-Bus (Data ID Bus) 90 sind ausersehen zum Erlauben solchen Multiplex-Partitionierens von Daten- und Adresspfaden.
Wie in 2 gezeigt, kommuniziert Adresssteuereinheit 180 auch mit Board-RAM-Einheit 150-N und mit jedem UPA CPU-Gerät 160-N, 170-N durch angemessene Adresspfade. Pfade 200, 210 koppeln die Adresssteuereinheit zu einer sogenannten Dtag-RAM-Einheit 220.
Ein "Gerät" kann eine I/O-Einheit bezeichnen, die Leitungen von Speicher zwischenspeichern bzw. cachen kann. Ein Hauptspeicher für ein einen Cache-Block oder eine Cache-Leitung enthaltendes Board wird als die "Heimat" ("home") für die Leitung bezeichnet. Ein kohärent aufrecht erhaltener Speicherraum, Caches einschließlich, wird als eine kohärente Domäne bezeichnet. Im Gegensatz dazu ist eine nicht-kohärente Domäne ein Speichergebiet, das Kopien von Speicher halten kann ohne Aufrechterhalten einer Kohärenz für die gespeicherten Daten, z.B. Streaming-Puffer und sogenannte "bcopy"-Puffer.
In System 10 und Schnittstelle 30, mit welchen die vorliegende Erfindung vorzugsweise betrieben wird, ist es wichtig, ein korrektes Cache-kohärentes Verhalten und Speicherordnen sicherzustellen. Dieses zu tun, legt Anforderungen für Signalzeitverhalten und Codieren für die verschiedenen von Boards zu dem Bussystem gekoppelten Signale auf, und erlegt auch Anforderungen auf Systemleiterplatten- Ebene auf. Schnittstellensystem 30 ist eher mit Zwischen-Board-Kohärenz beschäftigt, als sicherzustellen, dass Zwischen-Gerät-Kohärenz sichergestellt ist.
3 veranschaulicht eine typische Adresssteuereinheit 180 im weiteren Detail. Alle Gerätanforderungen werden an Adressbus 60 ausgegeben in Reihenfolge wie durch eine Anforderungsausgangswarteschlange (Request Out Queue, "ROQ") 176 dargestellt. Anders als die verallgemeinerte Schnittstelle, die außerhalb der Reihenfolge ankommende Antworten erlaubt, wenn System 10 mit UPA-Schnittstellengeräten verwendet wird, erlegt die UPA-Schnittstelle Reihenfolgenbeschränkungen auf. Anforderungen wird eine UPA-Klasse (0 oder 1) zugewiesen, und Antworten für Anforderungen in derselben Klasse müssen in Reihenfolge der Anforderungen sein. Jedoch können Antworten auf Anforderungen in unterschiedlichen Klassen in irgendeiner Reihenfolge ankommen. Warteschlangen C0Q 174 und C1Q haben die Aufgabe eines Sicherstellens, dass Antworten auf UPA-Anforderungen derselben Klasse in Reihenfolge ankommen.
Alle kohärenten Anforderungen und für ein Gerät relevante Unterbrechungen (einschließlich fremder kohärenter Anforderungen und ihrer eigenen kohärenten Anforderungen) werden in einer Kohärenzeingangswarteschlange (Coherent In Queue, "CIQ") 182 platziert, nachdem sie durch Dtags von DTAG RAM 220 "gefiltert" sind. Ein Markierungsvergleich zwischen Inhalten von Adresssteuereinheit DTAG-Speicher 220 und einer Bus-Ebene-RAM-Darstellung von Markierungen ermöglicht Filtern, um rasch eine Anforderung zu identifizieren, die z.B. gegenstandslose (z.B. nicht gegenwärtig gültige) Daten von einer gegebenen Speicheradresse sucht.
In dem Kontext eines Gerätes ist eine lokale Anforderung eine Anforderung von dem Gerät selbst, wohingegen eine fremde Anforderung eine zu diesem Gerät gerichtete Anforderung von einem anderen Gerät ist. Alle Gerät-Eingangs-/Ausgangs- ("PIO")Anforderungen sind in einer Lokal-PIO-Warteschlange (Local PIO Queue, "LPIOQ") 183 platziert, und alle fremden PIO-Anforderungen zu dem Gerät sind in der Fremd-PIO-Warteschlange (Foreign PIO Queue, "FPIOQ") 184 platziert, wie in 3 gezeigt. Allgemein sind Transaktionen in Reihenfolge verarbeitet, startend von dem Kopf einer Warteschlange.
Zu und von Gerät 160-N gehende Daten werden in zwei Puffern (z.B. nicht Warteschlangen) Datenausgangspuffer (Date Out Buffer, "DOB") 186 und Dateneingangspuffer (Data In Buffer, "DIB") 187 gepuffert, wie in 3 gezeigt.
Adresssteuereinheit 180 enthält auch einen Dtags-Puffer 220, eine zum Abhören für ein unsauberes Opfer (dirty victim) verwendete DVICT-Markierung 179, eine DEKODIEREN-Einheit (DECODE unit) 185 und einen V-Puffer (Vbuffer) 188, der verwendet ist zum Optimieren eines Zurückkopierens und der Leistung von Cacheverlusten mit unsauberem Opfer. EP-A-793178 mit dem Titel "Using a writeback buyer to improve copyback performance", zugeteilt an den Bevollmächtigten der vorliegenden Erfindung, offenbart eine Ausführungsform eines V-Puffers und eines Zurückkopieroptimierungsverfahrens, mit dem die vorliegende Erfindung betrieben werden kann, obwohl andere Puffer und Verfahren anstelle dessen verwendet werden können. Wie in 3 gezeigt, enthält Adresssteuereinheit 180 auch eine Arbitrierungseinheit 186 und eine Speichersteuereinheit 189.
Übersicht von in der bevorzugten Ausführungsform verwendeten Signalgruppen:
In System 30 gibt es vorzugsweise acht Signalgruppen, einschließlich einem Adressbus (Address Bus) 60, einem Datenbus (Data Bus) 70, einem Arbitrierungsbus (Arbitration Bus) 80, einem Daten-ID-Bus (DataID Bus) 90, einem Zustandssignalbus (State Signals bus) 100, Status-Signalbus (Status Signals bus) 110, Paritätsbitsignalbus (Parity Bit signals bus) 120 und Konfigurationssignalbus (Configuration Signal bus) 130. In der Praxis sind einige dieser logischen Signalgruppen zeitlich gemultiplext auf denselben Bussignaldrähten.
Ein ADRESSBUS 60 (ADDRESS BUS) ist verwendet zum Aussenden von Befehlen von einem Quellenleiterplattengerät und zum Aussenden von vorzugsweise 41-Bitadressen von einem anfordernden Board zu allen Boards im System 10. Ein Quellen-ID-Feld (SourceID field) in dem Adressbus ist verwendet zum eindeutigen Markieren jeder Transaktion. Der Begriff "Transaktion" bezieht sich auf ein Adressbuspaket und sein entsprechendes gültiges Datenbuspaket. Im System 30 ist ein Protokoll im Wesentlichen vereinfacht durch Übertragen eines Besitzes von Cache-Leitungen auf Adressbuspaketen, und nicht auf Datenbuspaketen, wie üblicherweise in dem Stand der Technik gehandhabt. Somit können Boards 50-N Leitungen besitzen, selbst bevor sie tatsächlich Daten für die Leitung haben. Der Adressbus definiert auch eine globale Reihenfolge, die verwendet werden kann zum Implementieren von spezifischen Speichermodellen, die bei der Systemebene spezifiziert sein können, zum Beispiel eine Gesamtspeicherreihenfolge (Total Store Order, "TSO"), Teilspeicherreihenfolge (Partial Store Order, "PSO"), und gelockerte Speicherreihenfolge (Relaxed Memory Order, "RMO"), deren spezifische Speichermodelle in der SPARC V9 Architekturbuchspezifikation (SPARC V9 architecture book specification) definiert sind, veröffentlicht durch und verfügbar von SPARC International, Inc.
System 30 verwendet vorzugsweise einen Zweier-Zyklus (im Gegensatz zu einem Einer-Zyklus) Adresspaket, um Boards ein Abhören von allen Adressbustransaktionen zu erlauben. Jedes Abhören erfordert einen Zyklus zum Lesen einer Markierung und einen Zyklus zum Schreiben der Markierung, resultierend in insgesamt zwei Zyklen. Ein Zweier-Zyklus-Protokoll ist ähnlich für Datenbuspakete verwendet.
Ein DATENBUS (DATA BUS) 70 ist verwendet zum Übertragen von Daten zwischen zwei Boards, wobei die Datenbuspakete in beliebiger Reihenfolge auf dem Datenbus auftreten dürfen, ohne sich auf das durch die Geräte beobachtete Speichermodell auszuwirken. Eine Datenübertragung kann vom Lesetyp sein von einer Antworteinheit zur Einleitungseinheit, oder kann vom Schreibtyp sein von einer Einleitungseinheit zur Antworteinheit. Ein ein Adressbuspaket ausgebendes (z.B. aussendendes) Board wird die "Einleitungseinheit" der Transaktion genannt. Das Board, das die angeforderten Daten für eine Lesetyptransaktion bereitstellt, oder die Daten für eine Schreibtypoperation annimmt, wird "Antworteinheit" genannt. Eine Antworteinheit und eine Einleitungseinheit können tatsächlich dasselbe Board sein.
Ein Datenbuspaket ist zwei Zyklen lang, ohne Erfordernis von leeren Zyklen zwischen Datenbuspaketen. Für jeden Zyklus trägt der Datenbus vorzugsweise 256 Bits von Daten (plus Fehlerkorrekturcode (Error Correction Code, "ECC")). Somit trägt ein Datenbuspaket vorzugsweise 64 Bytes von Daten.
Ein ARBITRIERUNGSBUS (ARBITRATION BUS) 80 ist verwendet zum Arbitrieren für den Adressbus 60 und Datenbus 70, wobei für eine solche Arbitrierung abwechselnde bzw. alternierende Zyklen verwendet werden. Somit wechseln aufeinanderfolgende Zyklen zwischen Adresse ("A") und Daten ("D").
DATEN-ID-BUS (DATA ID BUS) 90 trägt die Quellen-ID (SourceID) des Adressbuspaketes, das das Datenbuspaket eingeleitet hat, und ist verwendet vor irgendeiner Datenbusübertragung. Bus 90 ist verwendet zum Anpassen von Datenbusübertragungen mit Adressbuspaketen, um ein Treiben der angemessenen Daten auf dem Datenbus zu erlauben, oder ein Laden der Daten in einen angemessenen Speicherpuffer zu erlauben.
ZUSTANDSSIGNALE (STATE SIGNALS) 100 sind Leitungen, die den Zustand der durch das Adressbuspaket adressierten Leitung anzeigen. Diese Leitungen beinhalten GETEILT- (SHARED), BESITZ- (OWNED), ABGEBILDET- (MAPPED), und IGNORIEREN- (IGNORE) Signale und sind hier in Tabelle 7 bekannt gemacht. Wie hier beschrieben, ist das IGNORIEREN-Signal vorzugsweise verwendet zum Implementieren von optimalem globalen Transaktionsordnen.
Die STATUS-SIGNALE (STATUS SIGNALS) 110 beinhalten zwei Leitungen zum Anzeigen von Fehlern in Transaktionen, gültigem ECC auf dem Bus, und Aufhebung einer Antwort (Datenbuspaket).
Die PARITÄTSBITSIGNALE (PARITY BIT SIGNALS) 120 sind verwendet zum Detektieren von Fehlern in dem Arbitrierungsbus, den Zustandssignalen, den Status-Signalen und dem Daten-ID-Bus. (Der Adressbus ist vorzugsweise geschützt durch seine eigenen Paritätsleitungen und der Datenbus trägt ECC.)
Die KONFIGURATIONSSIGNALE (CONFIGURATION SIGNALS) 130 umfassen Einrichtungen, so wie Takte, Reset, JTAG und andere Implementierungs-abhängige Signale, zum Beispiel die Trigger- und Belegt- (Engaged) Signale, die für eine Fähigkeit zum Einstecken von Leiterplatten im Betrieb verwendet sind.
Tabelle 1 fasst die im System 30 verwendeten Signalgruppen zusammen.
TABELLE 1 – Signalgruppenzusammenfassung
Adressbus-Signalgruppen-Definitionen:
ADRESSBUS 60 besteht vorzugsweise aus 43 Signaldrähten einschließlich einem Paritätssignal. Tabelle 2 zeigt Adressbuspaketfelder, wobei ein Adressbuspekt in zwei aufeinanderfolgenden Zyklen getrieben wird.
TABELLE 2 – Adressbusfelder
Das gemultiplexte Shared-Feld und das Ignore-Feld sind logisch nicht ein Teil des Adressbusses (obwohl sie sich dieselben Anschlüsse teilen), und sind nicht Einleitungseinheit-getrieben mit dem Rest des Adressbusses. Jedoch sind alle anderen Felder durch die Einleitungseinheit getrieben. Die Paritätsbits sind einen Zyklus später als die Adressbusfelder getrieben, die sie schützen. Somit schützt das Parity0-Feld die im Zyklus 0 getriebenen Adressbusfelder, wohingegen das Parityl-Feld die im Zyklus 1 getriebenen Adressbusfelder schützt. Ein Treiben des Paritätsfeldes einen Zyklus später stellt Zeit bereit zum Berechnen einer Parität. Das Reserved-Feld ist vorzugsweise nicht durch die Einleitungseinheit getrieben.
Das Parityl-Feld schützt nicht die Shared- oder Ignore-Felder, weil sie nicht durch die Einleitungseinheit getrieben sind. Anstelle dessen sind die Shared- und Ignore-Felder durch das ParityD-Signal geschützt, hier später beschrieben.
Weil Markierungslesen und -schreiben zwei Taktzyklen in Anspruch nimmt, erfordert jedes Adressbuspaket zwei Zyklen, um Boards ein Abhören von allen Adressbustransaktionen zu erlauben.
In einer bevorzugten Ausführungsform enthält das Address-Feld Bits 40:4 der physikalischen Adresse. Bits 3:0 sind nicht erforderlich, da alle Information, die sie enthalten, von dem ByteMask-Feld verfügbar ist. Das ByteMask-Feld ist verwendet zum Spezifizieren irgendeiner Anzahl von 16 Bytes für ReadIO- und WriteIO-Transaktionen.
In Tabelle 2 ist das Victim-Bit verwendet in ReadToShare-, ReadToShareAlways- und ReadToOwn-Transaktionen, um anzuzeigen, dass der mit der Transaktion verknüpfte Cacheverlust ein unsauberes Opfer (dirty victim) hat. Das Victim-Bit kann verwendet sein für Unterbrechungspakete bzw. Interrupt-Pakete zum Codieren einer speziellen Unterbrechungsquelle. Dieses Bit ist nicht in irgendeiner anderen Transaktion verwendet, und ist als eine 0 getrieben.
Das Port-Feld zeigt die Gerätenummer innerhalb des Boards an, und in Systemen mit meistens zwei Geräten pro Board, reicht ein Ein-Bit-Port-Feld aus.
Die Paritätsbits codieren eine gerade Parität auf den Adressbusfeldern, wie in Tabelle 3 gezeigt. Parität ist einen Zyklus nach den Feldern getrieben, die sie schützen, um ausreichend Zeit für eine Paritätsberechnung zu ermöglichen.
TABELLE 3 – Paritätsabdeckung für den Adressbus
In Tabelle 3 ist das SourceID-Feld verwendet zum eindeutigen Markieren eines Adressbuspaketes. Die Antworteinheit wird die SourceID auf dem Daten-ID-Bus platzieren, um die Adressbus- und Datenbuspakete anzupassen. Das SourceID-Feld hat zwei Unterfelder. Ein BoardID[6:3]-Unterfeld identifiziert das Board, und ein TransactionID[2:0]-Unterfeld identifiziert die Transaktion innerhalb des Boards. Eine TransactionID von 0 ist reserviert für Leerlauf, was jedem Board erlaubt, bis zu sieben ausstehende Transaktionen zu habe. Alle ausstehenden Transaktionen haben eindeutige SourceIDs, aber die Wahl einer TransactionID ist implementierungsabhängig.
Befehlsfelder:
Tabelle 4 veranschaulicht Befehlsfeldcodierungen, die im System 30 verwendet sind.
TABELLE 4 – Befehlsfeldcodierungen
Datenbus-SignalGruppen-Definitionen:
Die Signalgruppendefinitionen für den Datenbus 90 werden nun im Detail beschrieben werden. Jeder Datenbus hat Felder, wie in Tabelle 5 gezeigt.
TABELLE 5 – Datenbusfelder
Daten sind vorzugsweise geschützt durch einen unabhängigen SEC-DED-S4ED-Fehlerkorrekturcode, entwickelt durch Kaneda, obwohl andere Formen eines Schutzes anstelle dessen verwendet werden könnten. In der bevorzugten Ausführungsform ist ein 8-Bit-ECC-Feld mit jedem 64-Bit-Datenfeld verknüpft. Wie in Tabelle spezifiziert.
TABELLE 6 – Datenbus-ECC-Verteilung
Datenbuspakete sind zwei Zyklen (64 Bytes) lang, ohne Erfordernis von Leerlaufzyklen zwischen benachbarten Datenbuspaketen.
Die Datenreihenfolge auf dem Datenbus ist für Blockübertragungen durch Address[5] bestimmt, mit einem 32-Byte-ausgerichteten Datenquantum, das die vorzugsweise zuerst bereitgestellte Adresse enthält. Wenn Address[5] 0 ist, wird der erste Datenzyklus Bytes 0 bis 31 enthalten, und der nächste Datenzyklus wird Bytes 32 bis 63 enthalten. Wenn Address[5] 1 ist, wird der erste Datenzyklus Bytes 32 bis 63 enthalten, und der nächste Zyklus wird Bytes 0 bis 31 enthalten.
Für Nicht-Block-Übertragungen (ReadIO, WriteIO) sind die Daten in Bytes 0 bis 16 vom ersten Datenzyklus platziert, und individuelle Bytes sind in dem ByteMask-Feld spezifiziert, anderswo hier beschrieben. In jedem Datenzyklus sind die Bytes in einer Reihenfolge, so dass das niedrigst nummerierte Byte die höchste nummerierten Bits belegt.
Daten-ID-Bus-Signalgruppen:
Die Signalgruppen für den Daten-ID-Bus (DataID bus) werden nun beschrieben werden. Der Daten-ID-Bus ist 7 Bits breit und ist zum Anpassen von Datenbuspaketen mit frühreren Adressbuspaketen verwendet. Da die Daten-ID nur in abwechselnden Taktzyklen getrieben ist, kann sie sich Signalanschlüsse in Multiplex-Weise mit einer Anzahl von anderen Signalen teilen, wie in Tabelle 2 gezeigt.
Tabelle 7 zeigt die Daten-ID-Bus-Felder, die in der bevorzugten Ausführungsform verwendet sind.
TABELLE 7 – Daten-ID-Bus-Felder
Aus 4 ist ersichtlich, dass Daten-ID-Bus 90 fünf Taktzyklen getrieben ist, bevor die erste Daten-ID auf dem Datenbus 70 verfügbar gemacht ist. Diese Fünf-Zyklen-Latenz ist benötigt zum Bereitstellen von ausreichend Zeit zum Treiben der angemessenen bzw. passenden Daten.
In 4 enthält jede Adresssteuereinheit 180 mindestens ein selbstgehaltenes oder zwischengespeichertes Taktregister (Latched Clock Register, "LCR"). Die Nomenklatur "180*" für die Adresssteuereinheit am weitesten rechts bezeichnet, das diese Adresssteuereinheit physikalisch auf einer Leiterplatte 50-N lokalisiert sein könnte, die anders ist als die die anfordernde oder einleitende CPU enthaltende Karte. Im Schlitz oder Taktzyklus "0" platziert der Anforderer, der eine Datenbus-Arbitrierung (wird noch beschrieben) gewann, seine DATEN-ID auf DATEN-ID auf DATEN-ID-Bus 90, und im Zyklus "1" ist diese Information zur Adresssteuereinheit 180* gekoppelt. Im Zyklus 2 koppelt das mit Adresssteuereinheit 180* verknüpfte Ausgangs-LCR die DATEN-ID zu einem Eingangs- LCR, das mit der Bit-gestückelten Datenpuffersteuereinheit 140 auf der anfordernden Leiterplatte verknüpft ist. Innerhalb von 140 liegt eine Zweier-Zyklus-Latenz vor, und bei Taktzyklus 5 ist die DATEN-ID zu DATEN-Bus 70 geschrieben.
Separate Arbitrierung für einen Zugriff auf den Daten-ID-Bus ist nicht erforderlich, weil der "Gewinner" der Datenbusarbitrierung auch der implizite Gewinner der Arbitrierung für den Daten-ID-Bus ist.
Arbitrierungsbus-Signalgruppen:
Steckleiterplatten 50-N verwenden Arbitrierungsbus 80, um Zugriff zu dem Adressbus 60 und Datenbus 90 zu erlangen, wobei abwechselnde Adress- ("A") und Daten- ("D") Zyklen auf dem Arbitrierungsbus verwendet sind für eine Arbitrierung zwischen dem Adressbus und dem Datenbus. Zugriff zu dem Daten-ID-Bus und Status-Signalen ist implizit zusammen mit dem Datenbus erhalten. Wie durch Tabelle 8 gezeigt, besteht der Arbitrierungsbus vorzugsweise aus drei Feldern.
TABELLE 8 – Arbitrierungsbusfelder
Pro Leiterplatte ist eine Anforderungsleitung zugeteilt, und ein verteilter Arbitrierungsalgorithmus ist vorzugsweise für die Arbitrierung verwendet. Jedes Buszugriff-suchende Board macht seine Anforderungsleitung geltend und liest alle anderen Anforderungsleitungen. Eine Arbitrierung für einen Adressbuszugriff ist bestimmt in einer verteilten Weise innerhalb von ARB-Einheit 186, die in Adresssteuereinheit 180 von jeder Leiterplatte 50-N gefunden werden kann. Der Gewinner einer Arbitrierung ist einen Zyklus, nachdem die Anforderungen getrieben sind, bestimmt. Der Bus (Adressbus oder Datenbus) können in dem nächsten Zyklus getrieben sein.
ARB-Einheit 186 in der Adresssteuereinheit 180 auf jedem Board bewirkt, dass alle Boards einen identischen hierarchischen Round-Robin-Typ-Arbitrierungsalgorithmus ausführen, so dass die Zustände von jeder ARB-Einheit 186 in Synchronisation miteinander bleiben. Das ArbSync-Signal, das nur durch ein Board (typischerweise Firmware-gewählt) getrieben ist, stellt einen Mechanismus für Boards bereit zum Synchronisieren von deren Arbitrierungszustandsmaschinen. ArbSync ist zu abwechselnden 1- und 0-Werten getrieben, was abwechselnde Adress- bzw. Datenarbitrierungszyklen anzeigt. In einer bevorzugten Ausführungsform kann ein ArbSynctreibendes Board einen Arbitrierungs-Reset bewirken durch Treiben desselben Wertes für zwei Zyklen. (ArbSync ist auch nützlich zum Hardware-Debuggen).
Weil eine Datenbusarbitrierung beginnen kann, bevor die Daten verfügbar sind, kann die Arbitrierungslatenz normalerweise überlappt sein. Dieses erlaubt einer Datenbusarbitrierung, eine einfache Auswahl eines Gewinners zwei Zyklen später zu verwenden.
Das FlowControl-Feld ist verwendet zum Anhalten von Datenbusarbitrierungsanforderungen für gewisse Typen von Transaktionen.
Flusssteuerung:
Das FlowControl-Signal bzw. Flusssteuerungssignal wird nun beschrieben werden. FlowControl ist vorzugsweise ein verdrahtetes-ODER-Signal, das durch irgendeine Anzahl von Boards getrieben sein kann, um deren Bedarf an einem Flusssteuern der Adressbuspakete anzuzeigen. Aufgrund der elektrischen Eigenschaften einer Draht-ODER-Leitung sollte FlowControl als ein asynchrones Signal behandelt werden.
Boards sollten nicht Anforderungen tätigen für den Adressbus, zum Einleiten von Transaktionen, anders als Admin, ReadIO oder WriteIO, zwei Zyklen beginnend, nachdem FlowControl beobachtet ist, wie geltend gemacht. Zwei Zyklen, nachdem eine Flusssteuerung rückgängig gemacht bzw. entwertet ist, können Boards Anforderungen für den Adressbus tätigen, um irgendeinen Transaktionstyp einzuleiten bzw. zu initiieren. Eine Flusssteuerung ist unnötig für Admin-, ReadIO- oder WriteIO-Transaktionen. Flusssteuerung ist auch unnötig für den Datenbus und sollte während des Datenbusarbitrierungszyklus ignoriert sein. Dies ist so, weil für Lesetypübertragungen die Einleitungseinheit immer Raum in ihrem DIB 187 haben sollte, und für Schreibtypübertragungen kann die Antworteinheit immer ein DataCancel geltend machen, falls ihr Raum zum Annehmen der Daten fehlen sollte.
Übersicht von Transaktionen gemäß der bevorzugten Ausführungsform:
Jede Transaktion involviert ein Aussende-Adressbuspaket und ein gültiges Punkt-zu-Punkt-Datenbuspaket. Wie später hier beschrieben, kann ein ungültiges Datenbuspaket vorliegen, das aufgehoben ist. Es ist der Zweck einer verteilten ARB-Einheit 186, rasch und mit minimaler Verzögerung Anforderungen zu arbitrieren, die durch irgendeine der CPU-Geräte auf irgendeinem der Steck-Boards 50-N ausgegeben sind, und rasch ein Bewilligungssignal zu dem Board-befestigten Gerät auszugeben, dass die Arbitrierung gewinnt.
Lesetyp-Transaktion:
Eine typische Lesetyp-Transaktion tritt wie folgt auf:

(1) Eine CPU auf dem Einleitungseinheit-Board arbitriert für den Adressbus, den Arbitrierungsbus verwendend;
(2) Die Einleitungseinheit treibt den Adressbus mit einer Adresse, einem Befehl und einer Source-ID;
(3) Alle Boards kommunizieren mit dem Adressbus und "belauschen" bzw. "hören" die Adresse ab. Nach einer dem Adresszyklus folgenden fixierten Verzögerung treiben alle Boards Zustandssignale, die den Zustand der Leitung bei der Zeit anzeigen, wenn die Adresse auf dem Adressbus war. Wenn notwendig, aktualisieren die Boards ihre Cache-Markierungen in ihrer Board-befestigten DTAG-RAM-Einheit 220 (siehe 2) zu einem späteren Zyklus für Adressbuspakete, wobei keine Markierungsaktualisierung durch Datenbuspakete bewirkt wird;
(4) Das antwortende Board arbitriert für den Datenbus, den Arbitrierungsbus und die verteilte ARB-Einheit 186 verwendend. Mit verteilt ist gemeint, dass jede Adresssteuereinheit 180 auf jeder Einsteckleiterplatte eine ARB-Einheit 186 enthält, deren Zustand identisch ist zu dem von jeder anderen ARB-Einheit;
(5) Das antwortende Board treibt den Daten-ID-Bus mit der SourceID von dem Adressbuspaket;
(6) Das antwortende Board treibt die Status-Signale;
(7) Die Antworteinheit treibt die zwei Datenbuszyklen;
(8) Die Daten sind zu dem Bestimmungsort geladen.

System 30 definiert Transaktionen einer kleinen Menge, die Lesetyp-Transaktionen beinhalten (die in Datenübertragungen von Antworteinheit-zu-Einleitungseinheit resultieren) und Schreibtyptransaktionen (die in Datenübertragungen von Einleitungseinheit zu Antworteinheit resultieren). Zusammen umfassen diese Transaktionen ReadToShare, ReadToShareAlways, ReadToOwn, ReadStream, ReadIO und ReadBlockIO, WriteBack, WriteStream, WriteIO und WriteBlockIO, Interrupt, ReadToShareFork, und Admin (eine Quasi-Transaktion). Bevorzugte spezifische Codierungen für diese Transaktionen sind in Tabelle 3 gezeigt.
Lesetyp-Transaktionsmenge:
Die Lesetyp-Transaktionsmenge beinhaltet (i) ReadToShare und ReadToShareAlways-Transaktionen, (ii) ReadToOwn-Transaktion, (iii) die ReadStream-Transaktion, (iv) ReadIO- und ReadBlockIO-Transaktionen. Die Aktionen, die für jede Transaktion durch die Einleitungseinheit und Antworteinheit erforderlich sind, als auch die Abhöroperationen, die erforderlich sind durchgeführt zu werden, werden nun beschrieben werden. Es wird bemerkt, dass während minimale Eigenschaften für die Zustandsmaschine existieren, spezifische Cache-Zustände und spezifische Übergänge nicht erzwungen sind. Es wird auch bemerkt, dass Speicherordnen und Cache-Kohärenz sowohl von der Architektur des Systems, mit dem System 30 verwendet ist, als auch von der Spezifikation für die Geräteschnittstelle, z.B. einer UPA-Typ-Schnittstellen-Spezifikation, abhängen.
(i) ReadToShare- und ReadToShareAlways-Transaktionen
ReadToShare- und ReadToShareAlways-Transaktionen sind verwendet, um Cache-Leseverluste in Geräten zu befriedigen. Die ReadToShare-Transaktion ist durch ein Board eingeleitet, wenn das Board eine Leitung cachen bzw. zwischenspeichern möchte, zu der es später schreiben möchte. Was Abhören betrifft, macht der Heimatspeicher für diese Adresse ein Mapped geltend. Wenn Mapped nicht geltend gemacht ist, wird die Einleitungseinheit nicht eine Antwort erwarten und wird zu dem Gerät einen Fehler zurückgeben. Alle Boards hören das Adressbuspaket ab und machen ein Shared geltend, wenn sie eine gechachete bzw. zwischengespeicherte Kopie der Leitung haben. Ein Board, das die Leitung besitzt, gibt ebenso ein Owned aus und antwortet der Einleitungseinheit. Es kann höchstens ein Besitzer für die Leitung vorhanden sein. Ein Board kann Ignore geltend machen, wenn es zuerst eine andere Transaktion ausgeben will. Wenn die Einleitungseinheit mehrere Geräte hat, dann könnte die Transaktion als Antwort auf einen Cache-Verlust in einem Gerät eingeleitet bzw. initiiert sein, während die angeforderte Leitung in einem anderen Gerät auf demselben Board gecached bzw. zwischengespeichert sein könnte. In diesem Fall macht die Einleitungseinheit ein Shared geltend. Ähnlich, wenn die Leitung durch ein anderes Gerät auf demselben Board besessen ist, macht die Einleitungseinheit Owned geltend, in welchem Fall die Einleitungseinheit und die Antworteinheit auf demselben Board sind.
Bezüglich einer Antworteinheit, wenn ein Board eine angeforderte Cache-Leitung besitzt, antwortet es der Transaktion. Wenn kein Board die Cache-Leitung besitzt, dann antwortet die Heimat bzw. Home für die Leitung. Zum Minimieren einer Speicherlatenz kann der Speicher seine Antwort beginnen, einschließlich Arbitrieren für den Datenbus und Treiben des Daten-ID-Busses, bevor das Owned-Signal gültig ist. Wenn die Leitung auf einem anderern Board besessen ist, hebt der Speicher sein Datenbuspaket auf durch Geltendmachen eines DataCancel bzw. Daten-Aufheben. Wenn Ignore geltend gemacht ist, und Speicher bereits seine Antwort begonnen hat, dann hebt die Antworteinheit ihr Datenbuspaket auf. Speicher gibt vorzugsweise nicht die Daten-ID für eine spekulative Antwort aus, die später als 11 Zyklen aufgehoben werden könnte, nach dem ersten Zyklus des entsprechenden Adressbuspaketes. Was Cache-Zustände betrifft, wenn Shared geltend gemacht ist, setzt die Einleitungseinheit den Zustand für die Leitung, um anzuzeigen, dass sie geteilt ist. Wenn ein Board die Leitung besitzt, dann bleibt es der Besitzer für diese Leitung.
Wenn kein anderes Board die Leitung gemeinsam nutzt bzw. teilt, kann die Einleitungseinheit wählen, Besitzer für diese Leitung zu werden, was eine stärkere Bedingung darstellt, als wenn die Leitung besessen wäre. Dies ist nützlich, weil das erste Schreiben zu einer Cache-Leitung effizienter gemacht werden kann, eine Prozedur vorteilhafter Weise verwendet in dem UPA-Protokoll. Wenn diese Implementierungsprozedur verwendet ist, weiß die Einleitungseinheit nicht, bis nach einem Empfang eines Shared-Signals, ob es den Besitz der Leitung annehmen werden wird. Aber wenn Besitz angenommen ist, tut die Einleitungseinheit so, zurückwirkend zu der Zeit, wo das Adressbuspaket auf dem Adressbus war. Dies ist jedoch dadurch möglich, dass die Einleitungseinheit nur das Owned-Signal nach dem Owned-Signal für ihre eigene Transaktion geltend macht, zu welcher Zeit sie weiß, ob sie der Besitzer sein wird. Wenn Ignore geltend gemacht ist, ändert sich der Zustand der Leitung nicht.
Die ReadToShareAlways-Transaktion kann im Wesentlichen identisch zu der ReadToShare-Transaktion sein, aus der Perspektive von System 30. Die Einleitungseinheit gibt ReadToShareAlways aus, wenn sie eine Leitung cachen bzw. zwischenspeichern möchte, zu der sie ein Schreiben nicht beabsichtigt. Es ist empfohlen, dass die Einleitungseinheit nicht der Besitzer für die Leitung wird, selbst wenn kein anderes Board Shared geltend macht.
(ii) Die ReadToOwn-Transaktion
Die ReadToOwn-Transaktion ist verwendet zum Befriedigen von Cache-Schreibeverlusten. Ein Board, das eine Verantwortlichkeit übernimmt zum Bereitstellen einer Leitung von seinem Cache zu anderen Boards, wird als ein "Besitzer" bezeichnet. Ein Board fordert Besitz an durch Einleiten bzw. Initiieren einer ReadToOwn-Transaktion, um ein Besitzer zu werden. Die ReadToOwn-Transaktion ist eingeleitet durch ein Board, das einen exklusiven Besitz der Cache-Leitung haben möchte, so dass es zu dieser schreiben kann. Dieselbe Transaktion ist verwendet, ungeachtet, ob die Einleitungseinheit eine gültige gecachete bzw. zwischengespeicherte Kopie der Leitung hat.
Bezüglich eines Abhörens und der ReadToOwn-Transaktion macht das Board, das dieser Adresse entsprechenden Speicher hat, Mapped geltend. Andernfalls, wenn Mapped nicht geltend gemacht ist, wird die Einleitungseinheit nicht eine Antwort erwarten und wird einen Fehler zu dem Gerät zurückgeben. Alle Boards hören das Adressbuspaket ab, und ein die Leitung besitzendes Board macht ein Owned geltend und wird der Einleitungseinheit antworten. Es kann höchstens ein Besitzer für die Leitung vorhanden sein. Wenn die Einleitungseinheit bereits eine gültige Kopie der Leitung hat, kann sie die Daten nicht brauchen, aber verwendet die ReadToOwn-Transaktion zum Erhalten eines exklusiven Besitzes der Leitung. In diesem Fall kann die Einleitungseinheit auch ein Shared geltend machen zum Sperren bzw. Hemmen der Antwort von anderem Cache oder Speicher, der die Leitung besitzen kann.
Wenn ein Board die angeforderte Cache-Leitung besitzt, und es die Owned-Leitung geltend macht, antwortet das Board der ReadToOwn-Transaktion. Wenn Owned nicht geltend gemacht ist, dann antwortet der Speicher für die Leitung. Zum Minimieren einer Speicherlatenz kann der Speicher seine Antwort beginnen, einschließlich Arbitrieren für den Datenbus und Treiben des Daten-ID-Busses, bevor das Owned-Signal gültig ist. Der Speicher hebt sein Datenbuspaket auf durch Geltendmachen von DataCancel, wenn Owned geltend gemacht ist. Wenn Ignore geltend gemacht ist und Speicher bereits seine Antwort begonnen hat, dann hebt die Antworteinheit ihr Datenbuspaket auf. Wie bemerkt, sollte Speicher nicht die Daten-ID für eine spekulative Antwort ausgeben, die später als 11 Zyklen aufgehoben werden könnte, nach dem ersten Zyklus des entsprechenden Adressbuspaketes.
Was Cache-Zustände und die ReadToOwn-Transaktion betrifft, nimmt die Einleitungseinheit Besitz der Cache-Leitung an, unmittelbar nachdem ihr Adressbuspaket auf dem Adressbus erscheint. Alle anderen Boards als das Einleitungseinheits-Board machen bzw. erklären ihre Kopien von dieser Cache-Leitung für ungültig. Der Cache-Leitungsbesitzer (wenn einer vorliegt, und es nicht die Einleitungseinheit ist) erklärt bzw. macht seine Kopien dieser Leitung auch ungültig und antwortet der Einleitungseinheit, und das Datenpaket von der Antworteinheit wird die exklusive Kopie dieses Caches. Wenn die Einleitungseinheit mehrere Geräte hat, erklärt die Einleitungseinheit die Kopie der Cache-Leitung in allen Geräten für ungültig, die anders sind als das Gerät, zu wessen Gunsten die ReadToOwn-Transaktion eingeleitet wurde. Dem Gerät, zu dessen Gunsten die Transaktion eingeleitet wurde, sollten Daten von der Antworteinheit als die exklusive Kopie der Cache-Leitung gegeben werden. Wenn Ignore geltend gemacht ist, ändert sich der Zustand der Leitung nicht.
Besitz ist bestimmt beim Anfordern einer Leitung und nicht beim Empfang der Daten für die Leitung, und somit kann ein Besitzer die Leitung tatsächlich noch nicht in seinem eigenen Cache haben. Es kann höchstens ein Benutzer zu einer gegebenen Zeit für eine Leitung vorhanden sein. Dieses Kohärenzprotokoll unterscheidet sich von den meisten Kohärenzprotokollen nach dem Stand der Technik darin, dass es zwischen dem "Besitzer" und einem "Schreiber" unterscheidet. Der Begriff "Schreiber" bezieht sich auf ein Board mit einer potentiell unsauberen Kopie der Leitung. Der Schreiber braucht nicht der Besitzer zu sein, weil sich der Besitz überträgt, sobald wie ein anderes Board Besitz anfordert. Als solches kann der Schreiber fortfahren, zu der Leitung zu schreiben, bis er die Leitung zu einem anderen Board liefert. Es kann höchstens ein Schreiber für eine Leitung zu irgendeiner Zeit vorhanden sein.
(iii) Die ReadStream-Transaktion
Die ReadStream-Transaktion ist verwendet zum Lesen des Blocks von Daten vom Speicher in eine nicht-kohärente Domäne, so wie bcopy oder Streaming-Puffer. Wie hier verwendet, bezeichnet der Begriff "Block" oder "Leitung" 64-Byte-ausgerichtete Daten, die normalerweise mit einem Cache-Block verknüpft sind. Die ReadStream-Transaktion ist eingeleitet durch ein Board, wenn das Board eine Leitung von der kohärenten Domäne in eine nicht-kohärente Domäne lesen will. Was Abhören betrifft, macht das Board, das dieser Adresse entsprechenden Speicher hat, ein Mapped geltend, andernfalls wird die Einleitungseinheit nicht eine Antwort erwarten und wird einen Fehler zu dem Gerät zurückgeben. Alle Boards hören das Adressbuspaket ab. Ein Board, das die Leitung besitzt, macht ein Owned geltend und antwortet der Einleitungseinheit, wobei höchstens ein Besitzer für die Leitung vorliegt. Ein Board kann ein Ignore geltend machen, wenn es zuerst eine andere Transaktion ausgeben möchte.
Bezüglich einer Antworteinheit, wenn ein Board die angeforderte Cache-Leitung besitzt, antwortet es der ReadStream-Transaktion, und wenn kein Board die Cache-Leitung besitzt, dann antwortet die Heimat für die Leitung. Zum Minimieren einer Speicherlatenz kann die Heimat ihre Antwort (einschließlich Arbitrieren für den Datenbus und Treiben des Daten-ID-Busses) beginnen, bevor das Owned-Signal gültig ist. Wenn die Leitung auf einem anderen Board besessen ist, hebt die Heimat ihr Datenbuspaket auf durch Geltendmachen von DataCancel bzw. Daten-Aufheben. Wenn Ignore geltend gemacht ist, und Speicher bereits seine Antwort begonnen hat, dann hebt die Antworteinheit ihr Datenbuspaket auf. Speicher sollte nicht die Daten-ID für eine spekulative Antwort ausgeben, die später als 11 Zyklen aufgehoben werden könnte, nach dem ersten Zyklus des entsprechenden Adressbuspaketes. Die ReadStream-Transaktion bewirkt keine Änderung der Cache-Leitungszustände.
(iv) ReadIO und ReadBlockIO
ReadIO- und ReadBlockIO-Transaktionen sind verwendet zum Lesen von Eingangs-/Ausgangs-("IO" oder "I/O")Raum. Die ReadIO-Transaktion ist verwendet für Byte-, Halbwort-, Wort-, Doppelwort-, Vierwort- und Byte-maskierte Lesezugriffe, wohingegen das ReadBlockIO verwendet ist zum Lesen von 64-Byte-Blöcken. Ein Board leitet diese Transaktionen ein, wenn es Speicher vom IO-Raum lesen möchte. Die ReadBlockIO-Transaktion ist verwendet zum Lesen eines vorzugsweise 64-Byte-Blocks, und ReadIO ist verwendet zum Lesen irgendeiner Kombination von vorzugsweise 16 Bytes, angezeigt durch ByteMask von dem in dem Adressfeld spezifizierten 16-Byte-ausgerichteten Adressbereich.
Kein Abhören ist erforderlich für die ReadIO- und ReadBlockIO-Transaktionen, aber alle Boards werden die Adressen decodieren, um zu bestimmen, ob sie antworten sollten. Höchstens ein Board kann antworten, und ein Board, das ein Antworten beabsichtigt, wird ein Mapped bzw. Abgebildet geltend machen. Wenn Mapped bzw. Abgebildet nicht geltend gemacht ist, wird die Einleitungseinheit nicht eine Antwort erwarten und wird einen Fehler zu dem Gerät zurückgeben. Ignore bzw. Ignorieren kann nicht für die ReadIO- und ReadBlockIO-Transaktionen geltend gemacht werden. Bezüglich dieser zwei Transaktionen wird ein Board, das die angeforderte IO-Adresse enthält, die Antworteinheit. Diese Transaktionen bewirken keine Veränderung in den Cache-Leitungszuständen.
Schreibtyptransaktion:
Die Schreibtyptransaktionsmenge, beinhaltet (v) WriteBack, (vi) WriteStream, (vii) WriteIO und WriteBlockIO, (viii) Interrupt, (ix) ReadToShareFork und (x) Admin. Diese Transaktionstypen werden nun im Detail beschrieben werden.
(v) WriteBack
Die WriteBack-Transaktion ist verwendet zum Zurückschreiben eines unsauberen Opfers zum Speicher. WriteBack-Transaktionen sind Block-ausgerichtet und sind eingeleitet durch ein Board, wenn es eine unsaubere Leitung zum Speicher speichern möchte. Bezüglich Abhören macht der Heimatspeicher für die Adresse ein Mapped geltend. Die Einleitungseinheit hört das Paket ab und macht Owned geltend, wenn die Leitung nicht besessen ist, was anzeigt, das die Leitung durch eine frühere Transaktion für ungültig erklärt wurde, und das WriteBack ist aufgehoben. Ein Board kann Ignore geltend machen, wenn es zuerst eine andere Transaktion ausgeben möchte.
Bezüglich der Antworteinheit wird die Heimat für die angeforderte Speicheradresse die Antworteinheit. Wie alle Schreibtypoperationen sind Daten zuerst durch die Einleitungseinheit "abgegeben". Wenn die Antworteinheit die Daten nicht annehmen kann, macht sie DataCancel geltend. Die Antworteinheit nimmt dann die Verantwortlichkeit an für ein "Aufnehmen" bzw. "Holen" der Daten. Dieses impliziert, dass die Antworteinheit Schreibtypoperationen verfolgt bzw. sich über diese auf dem Laufenden hält, die sie "aufnehmen" bzw. "holen" werden wird. Die Einleitungseinheit sollte bereit sein, mit den Daten zu antworten, wenn die Einleitungseinheit den Datenbus mit der angemessenen Daten-ID treibt, um Daten zu "holen". Wenn die Einleitungseinheit Owned geltend macht für das Zurückschreiben, tritt die volle Schreibtypdatenübertragung auf, aber die Daten sind nicht zum Speicher geschrieben. Wenn Ignore geltend gemacht ist, sind Datenpakete nicht ausgegeben. Was Cache-Zustände betrifft, tritt die Einleitungseinheit den Besitz für die Leitung ab, wenn das Adresspaket für die WriteBack-Transaktion ausgegeben ist. Diese Transaktion sollte nicht eingeleitet sein (oder sollte durch die Einleitungseinheit aufgehoben sein durch Geltendmachen von Owned), wenn ein anderes Board eine ReadToOwn- oder ReadStream-Transaktion zuerst einleitet. In solch einem Fall wird die Einleitungseinheit die WriteBack-Transaktion aufheben durch Geltendmachen von Owned.
Sobald das WriteBack-Adressbuspaket ausgegeben ist, ist der Speicher für die Leitung verantwortlich zum Antworten auf nachfolgende Anforderung für die Leitung, bis ein anderes Board Besitzer wird. Diese Verantwortlichkeit existiert, selbst wenn das Datenbuspaket noch nicht empfangen worden ist durch den Speicher. Demgemäss verfolgt die Heimat ausstehende WriteBack-Transaktionen und Verzögerungsantworten für Leitungen mit ausstehenden WriteBack-Transaktionen. Dies wird getan, weil die Heimat mit den Daten von dem WriteBack antworten wird, eher als mit ihrer eigenen gegenstandslosen Kopie der Daten. Wenn Ignore geltend gemacht ist, ändert sich der Zustand der Leitung nicht.
Wie hier verwendet, ist ein "Opfer" ("victim") eine Cache-Leitung, die für eine Ersetzung durch neue, zu schreibende Daten identifiziert ist. Die Daten in der Opfer-Cache-Leitung sind "sauber", wenn der Hauptspeicher bereits die Daten enthält, und sind "unsauber", wenn die Cache-Leitung (aber nicht der Hauptspeicher) aktualisiert worden ist, in welchem Fall ein Zurückschreiben benötigt ist zum Aktualisieren des Hauptspeichers.
(vi) WriteStream
Die WriteStream-Transaktion ist verwendet zum Schreiben von neuen Daten zu einem Block eines Speichers von einer nicht-kohärenten Domäne, so wie bcopy-Puffern oder Streaming-IO-Puffern. Die WriteStream-Transaktion ist eingeleitet durch ein Board, wenn es neue Daten zu einer Leitung vom Speicher von einer nicht-kohärenten Domäne schreiben möchte, so wie bcopy-Puffern oder Streaming-IO-Puffern. Alle Boards hören das Adressbuspaket ab, und wenn ein Board (einschließlich der Einleitungseinheit) eine Kopie der Leitung hat, wird es seine Kopie für ungültig erklären. Shared- oder Owned-Signale sollten nicht geltend gemacht werden, und das Board mit dieser Adresse entsprechendem Speicher macht Mapped geltend. Ein Board kann Ignore geltend machen, wenn es zuerst eine andere Transaktion ausgeben möchte.
Die Heimat für die angeforderte Speicheradresse wird die Antworteinheit. Die Einleitungseinheit wird zuerst versuchen, die Daten "abzugeben" zu der Antworteinheit durch Arbitrieren für den Datenbus und Treiben der Daten. Wenn sie nicht bereit ist zum Annehmen der Daten, macht die Antworteinheit ein DataCancel geltend. Die Antworteinheit wird dann jedoch die Daten "aufnehmen" bzw. "holen" durch Arbitrieren des Datenbusses und Treiben der angemessenen Daten-ID. Dieses impliziert, dass die Antworteinheit Schreibtypoperationen verfolgt, die sie "holen" werden wird. Die Einleitungseinheit sollte bereit sein, mit Daten zu antworten, wenn die Einleitungseinheit den Datenbus mit der angemesenen Daten-ID treibt, um Daten zu "holen". Wenn Ignore geltend gemacht ist, sind keine Datenpakete ausgegeben. Alle Boards sollten ihre Kopien der Cache-Leitung für ungültig erklären. Wenn Ignore geltend gemacht ist, verändert sich der Zustand der Leitung nicht.
(vii) WriteIO und WriteBlockIO
WriteIO und WriteBlockIO-Transaktionen sind hier verwendet zum Speichern von Daten zum Eingangs-/Ausgangsraum. Ein Board leitet ein WriteIO und WriteBlockIO ein, wenn es Daten zu Eingangs-/Ausgangsraum schreiben will. Die WriteBlockIO-Transaktion ist vorzugsweise verwendet zum Schreiben eines 64-Byte-Blocks. Die WriteIO-Transaktion ist verwendet zum Schreiben irgendeiner Kombination von 16 Bytes, angezeigt durch die ByteMask bzw. Byte-Maske von dem in dem Adressfeld spezifizierten 16-Byte-ausgerichtete Adressbereich. Kein Abhören ist erforderlich für diese Transaktionen, aber alle Boards werden die Adressen decodieren, um zu bestimmen, ob sie antworten sollen. Höchstens ein Board kann antworten, und wenn ein Board beabsichtigt, zu antworten, macht es Mapped geltend. Ignore sollte für diese Transaktionen nicht geltend gemacht werden.
Das Board, das die angeforderte IO-Adresse enthält, wird die Antworteinheit. Die Einleitungseinheit versucht zuerst, Daten zu der Antworteinheit "abzugeben" durch Arbitrieren für den Datenbus und Treiben der Daten. Wenn die Antworteinheit nicht bereit ist, die Daten anzunehmen, macht sie DataCancel geltend und "holt" dann die Daten durch Arbitrieren des Datenbusses und Treiben der angemessenen Daten-ID. Dies impliziert, dass die Antworteinheit Schreibtypoperationen verfolgen wird, die es "holen" bzw. "aufnehmen" wird. Die Einleitungseinheit ist vorzugsweise bereit zum Antworten mit den Daten, wenn die Einleitungsantwort den Datenbus mit der angemessenen Daten-ID zum "Holen" der Daten treibt. Diese Transaktionen bewirken keine Änderung in den Cache-Leitungszuständen.
(viii) Interrupt
Die Interrupt-Transaktion ist eine Schreibtyptransaktion, für die das Datenbuspaket verwendet ist zum Schreiben eines mit dem Interrupt verknüpften sogenannten "mondo-Vektors" zu dem Bestimmungsort. Das Datenbuspaket enthält die Interrupt-Vektor-Information. Die Interrupt-Transaktion ist eingeleitet durch ein Board, wenn es einen Interrupt-Vektor zu einem anderen Board senden will. Das Interrupt-Ziel ist spezifiziert in dem Adressfeld und ist Implementierungsabhängig. In der bevorzugten Ausführungsform ist die Interrupt-Ziel-ID auf denselben Adressbits getragen wie in UPA spezifiziert, nämlich PA<18:14>.
Kein Abhören ist erforderlich für die Interrupt-Transaktion, aber alle Boards decodieren die Adresse, um zu bestimmen, ob sie antworten sollen. Ein Board, das der beabsichtigte Bestimmungsort des Interrupts ist, macht Mapped geltend. Wenn der Bestimmungsort des Interrupts den Interrupt nicht annehmen kann, macht er das Shared-Signal geltend, und die Transaktion ist aufgehoben. Ein Board kann Ignore geltend machen, wenn es zuerst eine andere Transaktion ausgeben will. Das Board, das durch das Adressbuspaket adressiert ist, wird die Antworteinheit, es sei denn, es macht das Shared-Signal geltend, um anzuzeigen, dass der Interrupt nicht angenommen wurde. Die Einleitungseinheit wird zuerst versuchen, die Daten zu der Antworteinheit "abzugeben" durch Arbitrieren für den Datenbus und Treiben der Daten. Wenn die Antworteinheit nicht bereit ist, die Daten anzunehmen, wird sie ein DataCancel geltend machen. Dann "holt" jedoch die Antworteinheit die Daten durch Arbitrieren des Datenbusses und Treiben der angemessen Daten-ID. Somit wird die Antworteinheit Schreibtypoperationen verfolgen, die sie "holen" bzw. "aufnehmen" wird. Die Einleitungseinheit sollte bereit sein, mit den Daten zu antworten, wenn die Einleitungseinheit den Datenbus mit der angemessenen Daten-ID zum "Holen" der Daten treibt. Wenn Ignore geltend gemacht ist, sind keine Datenpakete ausgegeben. Wenn Ignore nicht geltend gemacht ist, sondern Shared geltend gemacht ist, dann wird die Einleitungseinheit nicht das Datenpaket "abgeben" ausgeben, es sei denn, dass Victim-Bit ist gesetzt, in welchem Fall, sie das Datenpaket abgeben wird. Kein Board sollte DataCancel geltend machen für dieses Paket, und die Daten können einfach fallengelassen werden. Die Interrupt-Transaktion bewirkt keine Änderung in Cache-Leitungszuständen.
(ix) ReadToShareFork
Die ReadToShareFork-Transaktion ist nicht in dem Stand der Technik bekannt, aber gehört nicht zu der vorliegenden Erfindung. Ferner ist diese Transaktion hilfreich mit einer Netzwerkkonfiguration, in welcher einige Bussysteme 20 anwesend sind, wobei jedes Bussystem seine eigene Schnittstelleneinheit 30 hat, Leiterplatten 50, und verknüpfte Elemente. Diese Transaktion ist verwendet zum Unterstützen von verteiltem gemeinsam genutzten bzw. geteiltem Speicher (Distributed Shared Memory, "DSM"), und ist als eine WriteBack-Transaktion behandelt durch einen Speicher und als eine ReadToShareAlways-Transaktion durch andere Geräte. Die Einleitungseinheit für die ReadToShareFork-Transaktion ist logisch die Einleitungseinheit der ursprünglichen ReadToShare- oder ReadToShareAlways-Transaktion, für die Ignore geltend gemacht wurde. Diese Transaktion ist jedoch durch das Gerät geltend gemacht, das Ignore geltend machte. Die Einleitungseinheit der ursprünglichen Transaktion behandelt diese als eine ReadToShare-Transaktion, wohingegen die Heimat (Home) diese als eine WriteBack-Transaktion behandelt. Die Transaktion wird dieselbe Transaktions-ID wie die originale bzw. ursprüngliche ReadToShare- oder ReadToShareAlways-Transaktion verwendet.
Die ReadToShareFork-Transaktion ist abgehört wie eine ReadToShare-Transaktion. Ein Gerät mit einer gemeinsam genutzten bzw. geteilten Kopie der Cache-Leitung kann auch Shared geltend machen. Die Antwort für die ReadToShareFork-Transaktion ist ausgegeben durch das Gerät, das die Transaktion ausgab, z.B. das Gerät, das Ignore geltend machte. Wenn der Speicher die Daten nicht annehmen kann, wird er DataCancel geltend machen und später die Daten holen bzw. aufnehmen. Die Einleitungseinheit der ursprünglichen Transaktion wird die Daten von dem ersten Datenpaket nehmen (wenn die Heimat nicht DataCancel geltend machte) oder von dem zweiten Datenpaket (wenn die Heimat DataCancel geltend machte). Die Cache-Zustandswechsel sind dieselben, wie die von der ReadToShare-Transaktion.
In der Praxis arbeitet ReadToShareFork mit dem Ignorieren-Signal zusammen zum Implementieren der vorliegenden Erfindung. Wie bemerkt, kann eine Anforderer-CPU ihre Anforderung nicht unmittelbar bewilligt bekommen, aber fährt fort, andere Aufgaben (im Gegensatz zum Anhalten) zu verarbeiten. Somit kann der Anforderer versucht haben, Daten von einer ungültige Daten haltenden Speicheradresse zu lesen, welche Transaktion nicht in die verknüpfte Kohärenz-Eingangs-Warteschlange geladen werden kann, weil Ignore geltend gemacht worden ist. Man nehme an, dass schließlich solch eine Schreib-Transaktion die Speicherstelle mit gültigen Daten aktualisiert, woraufhin die ursprüngliche Transaktion erneut über den Systembus ausgegeben ist (z.B. gelesen von derselben spezifischen Speicherstelle) mit Verwenden derselben Quellen-ID.
Schreiben zu einer Speicherstelle ist relativ Zeitverbrauchend, und verbraucht z.B. vielleicht 10 Taktzyklen. In dem Stand der Technik könnten gültige Daten zu der spezifischen Speicherstelle geschrieben werden, nach welchem dem Anforderer, der die Daten lesen möchte, erlaubt würde, so zu tun. Jedoch würde ein Erhalten der Daten und ein lokales Speichern dieser noch einmal 10 Zyklen davon in Anspruch nehmen.
Gemäß der vorliegenden Erfindung kann das ReadToShareFork gleichzeitig (a) gültige Daten zu einer angeforderten ungültige Daten enthaltenden Speicherstelle schreiben und (b) die gültigen Daten zu dem Anforderer zurückgeben, dessen Anforderung für die Daten noch aussteht. Somit, eher als Vollenden der ausstehenden Anforderung in ungefähr zwanzig Taktzyklen, ist die Anforderung innerhalb von ungefähr zehn Taktzyklen zur selben Zeit bewilligt, die die Daten in der relevanten angeforderten Speicherstelle aktualisiert sind. Man beachte, dass von dem Standpunkt einer Speichersteuereinheit her das ReadToShareFork so erscheint, als ob es eine Schreib-Transaktion implementiert. Von dem Standpunkt einer Adresssteuereinheit jedoch erscheint das ReadToShareFork, als ob es eine Lese-Transaktion implementiert.
Mit Verweis auf 6 beachte man bei Schlitz 0, dass die vorliegende Erfindung gleichzeitig für einen Adressbuszugriff arbitrieren und eine ReadToShareFork-Transaktion (abgekürzt "RTS") ausgeben kann. Im Zeitschlitz oder Zeitzyklus 1 sendet die Schnittstelleneinheit eine SourceID, die identisch ist zu der SourceID, die zuvor in Verknüpfung mit einer Transaktion verwendet ist, die einem Ignorieren-Signal unterworfen wurde. So früh wie drei Taktzyklen, seitdem die Adressbustransaktion gesendet wurde, kann die Schnittstelleneinheit für den Datenbus arbitrieren zum Senden von mit der ReadToShareFork-Transaktion verknüpften gültigen Datenwerten. Somit ist in 6 bei Schlitz 5 die Daten-ID (DataID) gesendet, die identisch zu der SourceID sein wird.
Bei Zeitschlitz 8 in 6 kann ein Pufferspeicher optional ein Status-Signal ausgeben, was seinen Empfang von noch weiteren Daten anhält, z.B., wenn er zu nah an einer Speicherverstopfung ist. (Zeitlich später kann die Statuseinleitende Speichereinheit für den Datenbus arbitrieren, wenn sich die Verstopfungslage klärt, und wird die ursprüngliche Daten-ID senden.) Wenn ein haltendes Status-Signal nicht ausgegeben ist, erscheinen Daten (d0) auf dem Datenbus, beginnend bei Zeitschlitz 10. Da die vorliegende Erfindung vorzugsweise Zweier-Zyklen für Daten verwendet, fahren die Daten in Zeitschlitz 11 (d1) fort.
Aus der Perspektive vom Speicher sind die Daten auf dem Datenbus bei Zeitschlitz 10, 11 als Schreibdaten behandelt. Jedoch aus der Perspektive der Steuereinheit des anfordernden Prozessors sind solche Daten als Lesedaten betrachtet. Diese Dichtomie oder "Gabelung" ermöglicht es, dass dieselben Daten gleichzeitig zu zwei separaten Bestimmungsortstellen gesendet werden, zu der passenden Speicheradresse, an welcher eine ungültige Version der Daten existiert hat, und zu der anfordernden CPU. Der Datenempfänger weiß eigentlich nicht, von wo die Daten mit der gewünschten Daten-ID-Quellen-ID- Übereinstimmung (DataID-SourceID-Übereinstimmung) kommen, noch kümmert er sich darum.
Somit implementiert das ReadToShareFork einen Mechanismus, durch welchen eine einzelne an das Bussystem gekoppelte Datenquelle gleichzeitig eine Speicherstelle mit gültigen Daten aktualisieren und ebenso eine Lese-Anforderung befriedigen kann. Diese gleichzeitige Prozedur ist implementiert durch den Behelf eines Gebens eines Duplikats der ursprünglichen Anforderung oder Anforderungs-ID auf den Adressbus, woraufhin der ursprüngliche Anforderer anschließend die nun gültigen Daten holen kann. Diese Prozedur kann implementiert sein mit anderen als dem Ignorieren-Signal-Mechanismus. Ferner könnte eine Adresssteuereinheit veranlasst sein, unmittelbar ein ReadToShareFork auf dem Bus zu platzieren. Diese Prozedur könnte auftreten, wenn die Adresssteuereinheit wüsste, dass die Speicheraktualisierung notwendig wäre und eine frühere Antwort in der System-weiten Sequenz von Transaktionsreihenfolgen erlangen sollte.
(x) Admin-Funktion:
Admin ist nicht strengstens eine Transaktion, weil es nur ein Adressbuspaket involviert, aber kein Antwort-Datenbuspaket. Da keine Daten erwartet sind, wird eine Quellen-ID (SourceID) von 0 verwendet werden. Admin ist verwendet für eine spezielle administrative Synchronisation unter Boards. Admin-Adressbuspakete werden unterschiedlich von allen anderen Paketen gehandhabt. Diese Pakete sind nicht in irgendwelche Warteschlangen platziert, und ihre Verarbeitung ist Implementierungs-abhängig. Ignore bzw. Ignorieren sollte nicht für Admin-Pakete geltend gemacht werden. Tabelle 9 zeigt das Adressfeld in dem Admin-Adressbuspaket-codierenden Admin-Typ.
TABELLE 9 – Admin-Codierungen
In Tabelle 9 ist der XIR-Admin-Typ verwendet zum Aussenden eines XIR-Interrupts zu allen Boards. Der XIR-Interrupt stellt einen Mechanismus bereit zum Unterbrechen von CPUs zum Betreiben von System-Debuggen. Der Wakeup-Admin-Typ ist verwendet zum Aussenden eines Aufweck-Ereignisses zu allen Boards, ein Ereignis, das verwendet ist bei aktiver Leistungsverwaltung zum Synchronisieren eines Aufweckens von runtergefahrenen Geräten.
Überblick eines bevorzugten Arbitrierungsmechanismus:
System 30 kann einige Verfahren einer Adressbus-Arbitrierung unterstützen zum Reduzieren einer Arbitrierungslatenz einschließlich einer sogenannten Schnell/Langsam-Arbitrierung und einer sogenannten Buspark-Arbitrierung. Diese zwei Verfahren beschreiben, wie die Leiterplatten sich verhalten, sobald sie einen Gewinner ausgewählt haben. Beim Auswählen eines Gewinners aus den Anforderungen der mehreren Boards nutzt jedes dieser Verfahren vorzugsweise dasselbe Round-Robin-Vorrang-gegebene Verfahren, gemäß der vorliegenden Erfindung.
Bei dem Buspark-Verfahren wird dem vorherigen Gewinner erlaubt, den Bus unmittelbar zu treiben, wohingegen alle anderen Geräte arbitrieren müssen, vorzugsweise unter Verwenden von Round-Robin, um der nächste Gewinner zu werden. Bei dem Schnell/Langsam-Verfahren kann System 30 dynamisch die Modi umschalten. Wenn der Modus schnell ist, dann kann irgendein Board den Adressbus unmittelbar zusammen mit seiner Anforderung treiben, z.B. in demselben Taktzyklus. Aber wenn eine Kollision vorliegt (z.B. zwei oder mehr Anforderungen sind im schnellen Modus geltend gemacht), dann schaltet der Modus auf langsam um, und der Gewinner wird mit Verwenden von Round-Robin bestimmt. Genauer genommen, wenn mehrere Boards den Adressbus gleichzeitig treiben, ist die resultierende Kollision detektiert und das Paket ist verworfen. In dem nächsten Zyklus überprüfen alle Boards die Anforderungsleitungen zum Sicherstellen, dass nicht mehr als ein Board den Adressbus zur selben Zeit trieb. Wenn mehrere Boards den Adressbus gleichzeitig trieben, ist die Adresse ignoriert, und die Arbitrierung schaltet zu dem Langsam-Modus-Verfahren um. Wenn keine Anforderungen vorliegen, dann kehrt die Arbitrierung zum schnellen Modus zurück. Im System 30 steuert Firmware vorzugsweise, welches Arbitrierungsverfahren in einem gegebenen System verwendet ist. Mehreren gleichzeitigen Bustreibern auferlegte elektrische Einschränkungen regen an, dass das Schnell/Langsam-Arbitrierungsverfahren am Besten verwendet ist für kleinere Systeme mit kürzeren Centerplanes.
Schnell/Langsam-Arbitrierung ist in U.S.-Patent Nr. 5,664,121 offenbart, mit dem Titel DUAL MODE ARBITRATION APPARATUS AND METHOD FOR REDUCING LATENCY BY ALLOWING THE POSSIBILITY OF SIMULTANEOUS REQUEST AND ACCESS FOR A SHARED BUS, zugewiesen an den Bevollmächtigten dieser Anmeldung, und eingereicht am 7. November 1995.
Arbitrierungsanforderungen sind zustandslos, und die Anforderungsleitung ist auf dem Arbitrierungsbus getrieben, bis das anfordernde Board eine Arbitrierung gewinnt. Im schnellen Modus ist die Anforderung mit der Adresse gegenwärtig, wohingegen im langsamen Modus die gewinnende Anforderung gegenwärtig ist auf dem Adressbus zwei Zyklen vor der Adresse.
Die Auswahl einer Adressbusarbitrierung eines schnellen und eines langsamen Modus kann durch den folgenden Algorithmus beschrieben werden. S stelle eine Zustandsvariable dar, die eine langsame Arbitrierung darstellt, T stelle den aktuellen Taktzyklus dar (z.B. die Zeit, die der neue Zustand berechnet ist), und T-1 stelle die Zeit dar, bei der der vorherige Arbitrierungsanforderungszyklus stattfand (z.B. zwei Systemtaktzyklen früher).
Beim Arbitrierungssynchronisations-Reset, setze S=0;
Wenn (S==0) und (höchstens eine Anforderung bei T-1 gemacht wurde), dann
S=0.
andernfalls
wenn (keine Anforderungen wurden bei T-1 gemacht), dann
S=0;
andernfalls
S=1.
Details eines Vorrang-gegebenen Round-Robin-Arbitrierungsmechanismus:
Das Round-Robin-Arbitrierungsverfahren stellt sicher, dass eine Leiterplatte immer ein Voreinstellungsgewinner sein wird. Dieser Gewinner kann den Adressbus treiben und wird auch seine Anforderungsleitung in demselben Zyklus treiben. Alle anderen Boards können den Adressbus treiben, nur nach Gewinnen einer Arbitrierung. Bei irgendeinem Adressarbitrierungszyklus, wenn Anforderungen von anderen Boards als dem Voreinstellungsgewinner vorliegen, ist ein neuer Voreinstellungsgewinner gewählt und kann sein Adressbuspaket zwei Zyklen treiben, nach Tätigen seiner Anfangsanforderung. Wenn keine Anforderungen von anderen Boards vorliegen, bleibt der Voreinstellungsgewinner derselbe. Anfangs ist Board 0 der Voreinstellungsgewinner.
8 veranschaulicht eine bevorzugte Implementierung einer Adressarbitrierung, die nicht zu der vorliegenden Erfindung gehört, deren logische Implementierung in 9 gezeigt ist. 8 ist etwas vereinfacht darin, dass jede verteilte Arbitrierereinheit sechzehn Eingänge hat, von denen einer von dem mit der Einheit verknüpften Knoten kommt, und ein einzelnes Gewinnerausgangssignal, wobei der äußere Gewinner aus Signalen intern zu der Arbitrierungseinheit ist.
Wie in 2 und 8 gezeigt, ist der Vorrang-gegebene Round-Robin-Arbitrierungs-Mechanismus vorzugsweise als ARB-Einheiten 186 unter Adresssteuereinheiten 180 auf jeder Leiterplatte 50-N verteilt. Jede Adresssteuereinheit sieht dieselbe Information, z.B. an sie getätigte Anforderungen als auch bis zu 15 andere Anforderungen, die existieren können. Ferner ist jede Adresssteuereinheit in demselben Zustand und tätigt autonom niedrige, Blatt-Ebene- und Kopf-Arbitrierungs-Ebene-Zugriffsbewilligungen.
Wie gezeigt, enthält Adresssteuereinheit 186 auf jeder Leiterplatte eine Logik, die eine Zwei-Ebenen-hierarchische Arbitrierung ("ARB") Einheit 186 implementiert, die mit den Busleitungen und Adresssteuereinheiten (Address Controllers, "ACs") kommuniziert, die Zugriff zu dem Adressbus anfordern können. Jede ARB-Einheit 186 enthält vorzugsweise vier identische Blatt-Arbitrierer 260-A (oder "A"), 260-B (oder einfach "B"), 260-C ("C") und 260-D ("D"), gekoppelt an einen Kopf-Arbitrierer 250 ("E") innerhalb derselben Adresssteuereinheit 180 auf derselben Leiterplatte. Zwischen dem Kopf-Arbitrierer und jedem Blatt-Arbitrierer ist eine aufwärts gerichtete Anforderungsleitung ("rout"), eine aufwärts gerichtete Gewinner-nach-Rechts ("wrgt") Leitung und eine abwärts gerichtete Bewilligungsleitung ("win").
Wie in 8 und 9 gezeigt, hat jeder Blatt-Arbitrierer vier Anforderungseingangsleitungen ("rin"), wobei eine jede solche Leitung an eine einzelne durch diesen Blatt-Arbitrierer bediente Adresssteuereinheit gekoppelt ist. Wie in 2 gezeigt, hat der Arbitrierungsbus vorzugsweise 18 Leitungen, 16 davon, wovon vier zu jedem Blatt-Arbitrierer als "rin"-Leitungen gehen, wobei z.B. eine solche Anforderungseingangsleitung jeder von 16 Adresssteuereinheiten gewidmet ist (siehe auch 9). Die verbleibenden zwei Arbitrierungsbusleitungen sind verwendet zum Sicherstellen einer passenden Flusssteuerung (z.B. eines Mechanismus zum Halten von Bewilligungen, wenn die gemeinsam genutzte bzw. geteilte Arbitrierungsbus-Ressource temporär nicht verfügbar ist) und zum Bereitstellen von Phaseninformation, die identifiziert, ob das System gegenwärtig in einem Adress- ("A") oder Daten- ("D") Zyklus ist. Jede Adresssteuereinheit sieht somit sechzehn Eingangsanforderungssignale (rin) und wird sechzehn Gewinnerausgangssignale (wout) ausgeben.
Wie in 8 und 9 implementiert, ist eine Arbitrierung 16-wegig, Vier-Blatt-Ebene-4-Weg-Arbitrierer 260-A, 260-B, 260-C, 260-D umfassend, die jeder Arbitrierungsanforderungen beurteilen unter bis zu vier widerstreitenden CPU-Geräten. Ein fünfter Kopf-Arbitrierer 250 entscheidet, welcher der vier Blatt-Arbitrierer nun einen Adressbuszugriff einem Anforderer bewilligen kann. Unter Verwendung dieser offenbarten Ausführungsform verhält sich die in 8 gezeigte Zwei-Ebenen-hierarchische Struktur funktional wie ein einzelner großer 16-Wege-Vorrang-gegebener Arbitrierer.
Innerhalb einer Adresssteuereinheit 180 sind Arbitrierungsanforderungen einem Leiterplatten-lokalisierten Blatt-Arbitrierer unter Verwenden der rin-Leitungen vorgelegt. Genauer genommen werden zwei mit der Leiterplatte (z.B. 160-N, 170-N in 2) verknüpfte CPUs für eine Zugriffsanforderung arbitrieren unter Verwenden einer rin-Leitung auf der Karte, wohingegen 15 Anforderungen von CPUs jenseits der Karte über den Arbitrierungsbus und 15 rin-Leitungen kommen werden. Der Blatt-Ebenen-Arbitrierungsgewinner wird sein Adresspaket zu einem Karten-Ebenen-Bus senden, zum Einreihen innerhalb von Warteschlangenpuffer 184 in der Adresssteuereinheit 180 für diese Karte.
In 8 bedient zum Beispiel Blatt-Arbitrierer A Anforderungen zum Zugreifen auf den Adressbus von einer von vier CPUs, hier mit μp0, μp1, μp2 und μp3 bezeichnet. Wie in 9 gezeigt, tätigen die CPU-Geräte ihre Blatt-Arbitrierungsanforderungen über rin-Eingangsleitungen, welche an den Arbitrierungsbus gekoppelt sind. Anforderungen von diesen Geräten ist Vorrang gegeben, so dass mit zum Beispiel Verwenden von Blatt-Arbitrierer A eine Anforderung von μp0 oder CPU0 eine Priorität hat über eine Anforderung von μp1 oder CPU1, die eine Priorität hat über eine Anforderung von μp2 oder CPU2, die eine Priorität hat über eine Anforderung von μp3 oder CPU 3.
Es wird zu würdigen gewusst werden, dass jeder Blatt-Arbitrierer unabhängig funktionieren kann zum Bestimmen eines möglichen Gewinners unter seinen bis zu vier Anforderern. Jeder Blatt-Arbitrierer wählt einen "möglichen" Gewinner aus, und der endgültige Gewinner ist ausgewählt durch den Kopf-Arbitrierer unter den konkurrierenden möglichen Blatt-Ebenen-Gewinnern. Nur der eine Bewilligung von dem Kopf-Arbitrierer erhaltende Blatt-Arbitrierer wird seinem "möglichen" Gewinner erlauben, der endgültige Bewilligungsgewinner zu sein. Als solches ist die Kopf-Arbitrierer-Bewilligung verwendet als ein Qualifizierer bei den Blatt-Ebenen-Arbitrierern. Dieses Verfahren stellt vorteilhafter Weise eine ziemlich geringe Latenz dem 16-Wege-Arbitrierungsverfahren bereit.
Das oben beschriebene Arbitrierungsverfahren ist Round-Robin-getätigt durch Bereitstellen eines Letzter-Gewinner-(Last Winner, "LW") Zeigerzustandes bei jeder Blatt-Ebenen- und Kopf-Arbitrierer-Einheit. Der LW-Zeiger zeichnet auf, welcher mit jeder Arbitrierungseinheit verknüpfte Anforderer der letzte Gewinner war bei dieser Einheit. Wie in 8 gezeigt, enthalten somit Blatt-Arbitrierer A, B, C, D und Kopf-Arbitrierer E jeder einen identischen LW-Zeiger-Mechanismus, der rechts gerichtet (z.B. Abnehmen in einer Priorität) inkrementiert mit jeder Arbitrierungsbewilligung bei dieser Ebene.
Jeder Blatt-Arbitrierer A, B, C, D arbitriert unter Konkurrenten, die basierend auf einer Priorität von jedem Konkurrenten und einer Letzter-Gewinner-(Last Winner, bzw. "LW") Vergangenheit von Zuschlägen bei dieser Ebene dargeboten sind. Der Kopf-Arbitrierer E enthält einen LW-Zeiger, der zu dem zuletzt gewinnenden Blatt-Arbitrierer zeigt. Kopf-Arbitrierer E entscheidet, welcher der Blatt-Ebenen-Gewinner eine Bewilligung einer Arbitrierung gewinnen soll, basierend auf einer relativen Priorität der Blatt-Arbitrierer und auf einer LW-Vergangenheit von Bewilligungszuschlägen bei der Kopf-Arbitrierungs-Ebene. Die verschiedenen mit jeder Arbitrierungseinheit verknüpften LW-Zeiger ändern einen Zustand synchron wie benötigt.
Unter Verwenden des Vorrang gegebenen Round-Robin-Verfahrens, wenn mehrfache Anforderungen vorliegen, ist ein neuer Voreinstellungs-Arbitrierungsgewinner ausgewählt. Wenn ein Board eine Arbitrierung gewinnt, wird das gewinnende Board die niedrigste Priorität in dem nächsten Zustand haben.
Wenn zum Beispiel CPU5 im Blatt-Arbitrierer B das letzte Gerät war, dass eine Arbitrierungsbewilligung bei dieser Ebene gewonnen hat, dann zeigt LW 270 zu CPU5. Eine nächste Arbitrierungsbewilligung innerhalb von Blatt-Arbitrierer B wird zu CPU6 oder CPU7 gehen, z.B. Geräte "rechts" des letzten Gewinners, es sei denn, weder CPU6 noch CPU7 machen eine Anforderung geltend, aber CPUS tut dieses. Somit, es sei denn weder CPU6 noch CPU7 machen eine Anforderung geltend, können CPU4 und CPUS nicht Kandidaten für eine Zugriffsbewilligung sein. Wenn weder CPU6 noch CPU7 eine Anforderung tätigten, und CPU4 und CPU5 beide Anforderungen tätigten, würden in diesem Beispiel CPU4 bei der Blatt-Arbitrierungs-Ebene B gewinnen, weil sie eine höhere Priorität als CPU5 hat.
Eine CPU, die für einen Adressbuszugriff arbitrieren möchte, leitet eine Anforderung ein zum Kopf-Arbitrierer 250 durch ihre Eingangsanforderungs-"rin"-Leitung zu dem Blatt-Arbitrierer, an den sie gekoppelt ist (siehe 9). Jeder lokale Blatt-Arbitrierer arbitriert unter null bis vier Anforderungen, die vorliegen können, auf seinen rin-Leitungen und entscheidet über den Gewinner unter seinen Anforderern. Die Entscheidung ist basiert auf der gespeicherten LW-Information und der Priorität von den konkurrierenden Anforderungen und ist autonom getätigt. Jede Adresssteuereinheit 180 auf jeder Leiterplatte 50-N sieht dieselbe Information für alle Zeiten, da die Anforderungs-Information zu allen Einheiten 180 über Arbitrierungsbus 80 gekoppelt ist, und jede Steuereinheit 180 wird denselben Zustand haben. LW ist vorzugsweise Bit-maskiert implementiert mit drei Bits, nämlich rgt (für "right" bzw. "rechts"), wie folgt:
Gemäß der vorliegenden Erfindung, wenn rgt[n] gesetzt ist, wird Arbitrierungsleitung n eine höhere Priorität haben als Arbitrierungsleitung n-1. Wenn rgt[1] gesetzt ist, dann wird rin[1] eine höhere Priorität haben als rin[0]. Wenn ein Blatt-Ebenen-Arbitrierer einen Gewinner bewilligt hat, werden seine Anforderungsleitungen zur Rechten nun die höchste Priorität haben. Wenn irgendeine dieser rin-Leitungen Zugriff zu der gemeinsam genutzten bzw. geteilten Ressource anfordert, macht der Blatt-Ebenen-Arbitrierer das Gewinner-Nach-Rechts-Signal wrgt zu dem Kopf-Ebenen-Arbitrierer geltend. Dieses stellt sicher, dass diesem Blatt-Arbitrierer noch einmal die geteilte Ressource bewilligt werden wird.
Somit, im Blatt-Arbitrierer A, wenn CPU0 letztes Mal gewann, und CPU1 nun nicht anfordert, aber CPU2 und CPU3 jede einen Adressbuszugriff anfordern, dann gewinnt CPU2, weil ihre Priorität die von CPU3 überschreitet. Jeder Blatt-Arbitrierer macht eine ähnliche Entscheidung unter seinen Konkurrenten und gibt ein Signal auf einer "rout"-Leitung an den Kopf-Arbitrierer 250 aus, die anzeigt, dass er eine Zugriffwünschende CPU hat. Jeder Blatt-Arbitrierer sendet auch an den Kopf-Arbitrierer ein Gewinner-Nach-Rechts-Signal ("wrgt"). Der wrgt-geltend machende Blatt-Arbitrierer hat die höchste Priorität bei dem Kopf-Arbitrierer und ihm wird Zugriff zu dem Bus bewilligt werden.
Aus der Perspektive vom Kopf-Arbitrierer 250 wird den Blatt-Arbitrierern Vorrang gegeben, so dass der erste Blatt-Arbitrierer A Priorität hat über den zweiten Blatt-Arbitrierer B, der Priorität hat über den dritten Blatt-Arbitrierer C, der Priorität hat über den vierten Blatt-Arbitrierer D. Für den Kopf-Arbitrierer ist es irrelevant, welche mit einem gegebenen Blatt-Arbitrierer verknüpfte CPU eine Arbitrierung bei der Blatt-Arbitrierungs-Ebene "gewonnen" haben könnte. Die alleinig benötigte Information ist, welcher der vier Blatt-Arbitrierer gegenwärtig ein Zugriff suchendes Gerät hat.
Bei der Kopf-Arbitrierer- und bei den Blatt-Arbitrierer-Ebenen wird der LW-Zeiger die strikt Vorrang gegebene Reihenfolge überwinden. Wenn ein durch Blatt-Arbitrierer A anforderndes Gerät zuletzt die Kopf-Arbitrierer-ausgegebene Bewilligung gewann, dann werden Blatt-Arbitrierer zur "Rechten" des letzten Gewinners A, z.B. B oder C oder D, eine höhere Priorität haben als A. Wenn jedoch Blatt-Arbitrierer A das wrgt-Signal geltend macht, wird er die höchste Priorität erhalten. Wie es auch der Fall ist für die Blatt-Arbitrierungs-Ebene-LW-Mechanismen, läuft der LW-Zeiger nicht um, und die LW-Zeiger sind einmal pro System-Taktzyklus wie benötigt synchron zurückgesetzt. Beim Einschalten von System 10 und bei Einschiebung einer Leiterplatte sind die LW-Zeiger zurückgesetzt auf ihren Voreinstellungswert. Die LW- Zustandsänderungen (z.B. rechts inkrementieren) treten vorzugsweise bei jedem 12-ns-Taktzyklus auf synchrone Weise auf.
In der bevorzugten Implementierung ist ein ArbSync-Signal (hier anderswo beschrieben) nur durch ein Board getrieben und stellt den Mechanismus für eine Zwischen-Board-Synchronisierung von Arbitrierungszustandsmaschinen bereit.
Der Kopf-Arbitrierer tätigt eine Bewilligungsentscheidung basierend auf den Inhalten seiner eigenen LW-Zustandsmaschine und auf der Priorität der einkommenden Anforderungen auf den "rout"-Leitungen von den Blatt-Arbitrierern. Die endgültige Bewilligungsentscheidung ist rasch getätigt und zu den Blatt-Arbitrierern runtergereicht unter Verwenden von Gewinner-Raus- oder "win"-Leitungen über den Arbitrierungsbus. Wenn zum Beispiel CPU0 letztes Mal eine Blatt-Ebene-Arbitrierung gewann, hat sie nun die niedrigste Priorität, und Blatt-Arbitrierer A wird eine Bewilligung für seine CPU1 empfangen, wenn sie Zugriff anfordert. Innerhalb von Blatt-Arbitrierer B, wenn CPU5 letztes Mal gewann, hat sie nun die niedrigste Priorität, und CPU6 kann nun gewinnen (wenn sie anfordert). Bei der Kopf-Arbitrierer-Ebene, wenn Blatt-Arbitrierer A letztes Mal eine Bewilligung gewann, hat er nun die niedrigste Priorität, und in diesem Beispiel gewinnt Blatt-Arbitrierer B, was heißt, dass seine CPU6 die Arbitrierungsbewilligung gewinnen kann.
Vorzugsweise Verwendete Zustandssignal-Typen:
Die vier Zustandssignal-Typen, Shared, Owned, Mapped und Ignore werden nun im weiteren Detail bezüglich Tabelle 10 beschrieben werden.
TABELLE 10 – Bedeutung von Shared- und Owned-Signalen

¹ Wenn Shared/Geteilt geltend gemacht ist auf einer RTO, darf ein die Daten besitzender Cache nicht antworten und wird die Antwort aufheben

Das Shared-("S")-Zustands-Signal:
Es gibt sechzehn Shared-("S")-Signale, eines pro Board. Jedes Board treibt sein eigenes Shared-Signal und liest alle anderen Shared-Signale. Wie in Tabelle 2 bemerkt, sind Shared-Signale gemultiplext auf Adressbusanschlüssen. Das Shared-Signal ist fünf Zyklen nach dem ersten Zyklus des Adressbuszyklus geschrieben, mit dem es verknüpft ist.
Das Owned-("O")-Zustands-Signal:
Das Owned-Zustands-Signal ist sechs Zyklen nach dem ersten Zyklus des verknüpften Adressbuspakets getrieben, und ist auf dem Daten-ID-Bus gemultiplext (siehe 6).
Die Shared- und Owned-Zustands-Leitungen sollen getrieben werden, selbst wenn das Board augenblicklich nicht die Daten für die Leitung hat. Ein Board ist der Besitzer für eine Leitung, von der Zeit es eine ReadToOwn-Transaktion auf dem Adressbus einleitet bis zu der Zeit, bis zu der es den Besitz abgibt. Besitz ist aufgegeben, wenn das Board eine WriteBack-Transaktion für die Leitung auf dem Adressbus einleitet, oder wenn ein anderes Board eine ReadToOwn- oder eine WriteStream-Transaktion für die Leitung auf dem Adressbus einleitet.
Ähnlich soll ein Board eine Leitung haben zum Geltendmachen des Shared-Signals von der Zeit, wenn es die ReadToShare- oder die ReadToShareAlways-Transaktion auf dem Adressbus einleitet. Das Board behält diese Leitung bei, so lange, bis die Leitung im Cache ersetzt ist, oder bis ein anderes Board eine ReadToOwn- oder WriteStream-Transaktion für die Leitung einleitet.
Jede Einsteckleiterplatte hat vorzugsweise mehrere Geräte und wird für alle seine Geräte tätig sein. Ein Board wird deshalb die Shared- und Owned-Signale für seine eigenen Transaktionen geltend machen, wenn die Leitung geteilt oder besessen ist durch irgendeines seiner Geräte.
Das Mapped-("M")-Zustands-Signal:
Das Mapped-Zustands-Signal ist verwendet, um der Einleitungseinheit anzuzeigen, dass eine Transaktion eine Antwort empfangen wird. Wenn Mapped nicht geltend gemacht ist, weiß die Einleitungseinheit, dass sie nicht eine Antwort empfangen wird und dass der passende Fehler berichtet werden sollte. Das Mapped-Signal ermöglicht vorzugsweise, dass ausreichend lange Timeouts als fatale Hardwarefehler behandelt werden, eher als nicht-fatale-Fehler. Das Mapped-Signal ist sechs Zyklen nach dem ersten Zyklus des verknüpften Adressbuspaketes getrieben (siehe 6). Wie durch Tabelle 6 bemerkt, ist Mapped auf dem Daten-ID-Bus gemultiplext.
Für alle Transaktionen zu zwischenspeicherbarem Raum (d.h. RTS, RTSA, RTSF, RTO, TS, WB, WS) ist Mapped geltend gemacht durch das Board, das die entsprechende Speicherleitung hat, selbst wenn die Leitung durch einen Cache bzw. Zwischenspeicher zu dieser Zeit besessen ist. Für Interrupt-Transaktionen macht der Bestimmungsort des Interrupts bzw. der Unterbrechung (wenn irgendwelche vorliegen) Mapped geltend, selbst wenn der Bestimmungsort den Interrupt bzw. die Unterbrechung zu dieser Zeit nicht annehmen kann. Für nicht-zwischenspeicherbare Lese- und Schreibtransaktionen wird ein Board Mapped geltend machen, wenn es die Antworteinheit für diese Transaktion ist. Mapped ist vorzugsweise nicht geltend gemacht für Admin-Pakete.
Das Ignore-("I")-Zustands-Signal:
Ignoriermechanismus 17 und Speichereinheit 19, in der globalen Netzwerkschnittstelleneinheit 15 in 1 gezeigt, werden nun beschrieben werden bezüglich eines optimalen Neuordnens von Adresstransaktionspaketen global über Sammelbus-System 20''. Genauer genommen, wie in 1 gezeigt, koppelt die globale Netzwerkschnittstelle 15 Bussysteme 20, 20', die mit den verschiedenen Computersub-Systemen verknüpft sind, Gesamtsystem 10 umfassend, und bildet ein Sammelbus-System 20''. Schnittstelle 15 ist zu Sammelbus-System 20'' gekoppelt und überwacht alle Adressbustransaktionen, die durch Bussystem 20'' getragen werden sollen. Die verschiedenen Transaktionen, die von irgendeinem Gerät/Geräten auf irgendwelchen mit irgendwelchen Unter-Systemen verknüpften Leiterplatten herrühren können, sind vorzugsweise alle zur globalen Netzwerkschnittstelle 15 gesendet, worauf eine globale Transaktionsreihenfolge definiert wird. Solch eine globale Reihenfolge bzw. solch ein globales Ordnen ist dann über das Sammelbus-System 20'' zurück zu den Adresssteuereinheiten kommuniziert auf den zu System 10 gekoppelten verschiedenen Leiterplatten. Andere die Funktionen des Ignoriermechanismus betreffende Details können auch in WO-A-9734237 gefunden werden, eingereicht zum selben Datum hiermit, mit dem Titel "METHOD AND APPARATUS EXTENDING COHERENCE DOMAIN BEYOND A COMPUTER SYSTEM BUS", zugeteilt an den Bevollmächtigten.
Wie weiter beschrieben in der oben erwähnten Patentanmeldung resultiert ein globales Neuordnen von Transaktionen aus dem Gebrauch des Ignore-Signals. Die vorliegende Erfindung erkennt, dass es vorzugsweise unnötig ist, jede einzelne Transaktion neu zu ordnen. Somit wird ein IGNORE-Signal innerhalb vom Global-Netzwerk-Schnittstellenmechanismus 15 geltend gemacht, zu dem Sammelbus-System 20'', wenn immer eine Adressbustransaktion wahrgenommen ist, die neugeordnet werden muss. Ein typischer Kandidat für eine solche neuordnungsfähige Transaktion würde der Fall sein einer CPU-Anforderung für Daten von einer Adressstelle, wobei die gespeicherten Daten nicht gültig in dem Speicher sind. Solchen Transaktionen zu erlauben, anderweitig aufzutreten, würde unähnliche Versionen von Daten bekannt machen, zu dem Schaden von System 10. Innerhalb von der globalen Netzwerkschnittstelleneinheit 15 enthält eine dynamisch aufrechterhaltene Tabelle 19 alle Cache-Leitungen bzw. Zwischenspeicherleitungen innerhalb des Speichers, der unter den verschiedenen System 10 umfassenden Leiterplatten verteilt ist. Für jede Zwischenspeicherleitung in dem verteilten Speichersystem hält globale Netzwerkschnittstelleneinheit 15 Zweier-Bits eines verknüpften Zustandes, was vier Zustände definiert, nämlich INVALID bzw. UNGÜLTIG, SHARED bzw. GETEILT, OWNER bzw. BESITZER, oder MODIFIER bzw. MODIFIZIERER. Innerhalb von Sammelbus 20'' zeigen die verschiedenen ZUSTANDSSIGNALE 100 den Zustand der durch das Adressbuspaket adressierten Leitung an und stellen diese wie in Tabelle 10 gezeigten vier Zustandssignale bereit.
Das Ignore-Signal kann verwendet werden, um Adressbustransaktionen logisch neu zu ordnen, um verteilten gemeinsam genutzten bzw. geteilten Speicher zu implementieren. Ignore ermöglicht einem Board, das verteilten geteilten Speicher implementiert, eine unterschiedliche Transaktion einzufügen, vor der Transaktion, vor welcher es Ignore geltend machte, und dann erneut die Transaktion auszugeben. Das Ignore-Signal ist gemultiplext in einen Pin bzw. Anschluss des Adressbusses, wie durch Tabelle 2 gezeigt, und ist fünf Zyklen nach dem ersten Adresszyklus gültig (siehe 6). Wenn Ignore gültig gemacht ist, ist das Adresspaket ignoriert durch alle Geräte, außer dem Ignorieren geltend machendem Gerät. Das Ignore-geltend machende Gerät sollte später dieselbe (oder äquivalente) Transaktion erneut ausgeben mit derselben Transaktions-ID. In der bevorzugten Ausführungsform kann Ignore nur für kohärente Transaktionen und Interrupts bzw. Unterbrechungen geltend gemacht werden, und kann nicht für IO-Lese-, IO-Schreibe-, oder Admin-Pakete geltend gemacht werden.
Wenn eine CPU eine Cache-Leitung anfordert, die in dem Invalid-Zustand ist, z.B. Daten sucht, die in einem Speicher nicht gültig sind, gibt der Ignoriermechanismus ein IGNORE-Signal über die ZUSTANDS-Leitungen innerhalb des Sammelbusses 20 aus. Die verschiedenen ZUSTANDS-Signale, festgehalten innerhalb der Zustandstabelle in der globalen Netzwerkschnittstelle, haben die präzise selben Zustände wie die DTAG-RAM-Einheiten 220 innerhalb der verschiedenen Leiterplatten. Da es möglich ist, dass Daten ungültig sein können, die in einer bestimmten Stelle innerhalb des verteilten Speichers für System 10 gespeichert sind, wird das verknüpfte ZUSTANDS-Signal für diese Zwischenspeicherleitung ungültig sein, und somit wird das IGNORE-Signal geltend gemacht werden.
Wenn das IGNORE-Signal geltend gemacht ist, ist der praktische Effekt, dass alle an den Sammelbus gekoppelten Adresssteuereinheiten 180 funktionieren, als ob die Subjekttransaktion nicht aufgetreten wäre. Auf die Subjektspeicheradresse (in welcher eine ungültige Version der gewünschten Daten beibehalten ist) kann noch zugegriffen werden, aber zu keinem praktischen Zweck, da eine andere Speicherstelle (die anderswo physikalisch sein kann) die gültige Version der gewünschten Daten hält. Wenn irgendeine CPU oder ein anderes Gerät versucht, auf eine mit einem ungültigen Zustand verknüpfte Zwischenspeicherleitung zuzugreifen, wie angedeutet durch eine verknüpfte Speicher-MARKIERUNG (memory TAG, oder "MTAG"), wird die globale Netzwerkschnittstelle veranlassen, dass das IGNORE-Signal geltend gemacht wird.
Wie bezüglich 6 bemerkt, sind Zustandssignale IGNORE und SHARED "(I,S)" geltend gemacht mit gemeinsamem Timing fünf Zyklen, nachdem eine Transaktion den relevanten Adressbus treibt, der mit dem das anfordernde CPU-Gerät enthaltenden Sub-System gekoppelt ist. Somit liegt in der bevorzugten Ausführungsform eine Fünf-Zyklus-Latenz vor, bevor das IGNORE-Signal geltend gemacht ist. Interessanterweise wird die mit der das anfordernde Gerät enthaltende Leiterplatte verknüpfte Adresssteuereinheit 180 auf dem Sammelbus die Transaktion nicht einmal sehen, die sie angefordert hat. Dieses ist so, weil innerhalb jeder Adresssteuereinheit eine kohärente Eingangswarteschlange 182 (Coherent Input Queue, "CIQ"), als auch eine Pufferwarteschlange 184 ist. Jede Adresssteuereinheit lädt in ihre verknüpfte CIQ alle kohärenten Transaktionen, an der sie interessiert ist, z.B. ihre eigenen Transaktionen.
In der bevorzugten Ausführungsform blockiert ein geltend gemachtes IGNORE-Signal alle Adresssteuereinheiten vom Hinzufügen einer IGNORE-gekennzeichneten Transaktion in eine kohärente Eingangswarteschlange jeder Adresssteuereinheit. Somit kann nicht einmal die mit einem anfordernden Gerät verknüpfte Adresssteuereinheit eine IGNORE-gekennzeichnete Transaktion in ihre eigene kohärente Eingangswarteschlange laden. Der praktische Effekt ist, dass die IGNORE-gekennzeichnete Transaktion nicht geltend gemacht wird auf dem Sammelbus-System, und somit in einem Temporal- oder Zeitsinn die Transaktion noch nicht aufgetreten ist. Die Transaktion wird erneut ausgegeben werden durch das Gerät, das das IGNORE-Signal geltend machte.
Somit kann in 6 Zeitschlitz 0 eine Anfangsausgabe einer gültigen Adressanforderung darstellen. Alternativ kann Zeitschlitz 0 eine nachfolgende erneute Ausgabe derselben Anforderung bezeichnen, deren Anfangsausgabe durch ein IGNORE-Signal verhindert wurde, das ein Laden der Transaktion in die relevante kohärente Eingangswarteschlange innerhalb der verknüpften Adresssteuereinheit verhinderte.
Eine individuelle Adresssteuereinheit kann von der mit einer Transaktion verknüpften Quellen-ID (SourceID)lernen, auf dem Sammelbus auftretend, ob eine gegebene Transaktion relevant ist für diese Adresssteuereinheit, z.B. für ein Gerät, das mit der Leiterplatte verknüpft ist, auf der die Adresssteuereinheit existiert. Ferner kann die Adresssteuereinheit von dem Sammelbus lernen, ob die Zwischenspeicherleitung bzw. Cache-Leitung für eine Subjekttransaktion in einem ungewöhnlichen Zustand ist, zum Beispiel durch ein anderes Gerät, das eine Zwischenspeicherleitung anfordert, für die die Adresssteuereinheit eine modifizierte Kopie hält.
Vorzugsweise verwendete Statussignale:
Die bevorzugte Ausführungsform stellt drei Statussignale bereit: ECCValid, DCESel, und DataCancel/Error. Diese Signale sind für einen Zyklus getrieben, zwei Zyklen vor dem ersten Datenzyklus des entsprechenden Datenbuspaketes. Alle drei Statussignale sind auf dem Daten-ID-Bus wie in Tabelle 6 gezeigt gemultiplext.
Das ECCValid-Statussignal zeigt an, ob die ECC-Felder in dem Datenbuspaket gültig sind zum Erlauben eines Verwendens von Geräten, die unfähig sind zum ECC-Generieren. ECCValid hat nur eine Bedeutung für nicht-zwischengespeicherte Operationen und Unterbrechungen, und hat keine Bedeutung für zwischenspeicherbare Transaktionen. In der bevorzugten Ausführungsform sollten alle zwischenspeicherbaren Transaktionen ein gültiges ECC haben, da Speicher nicht verfolgt, welche Daten ein gültiges ECC haben.
Das DCESel-Statussignal zeigt an, ob das Data-Cancel/Error bzw. Daten-Aufheben/Fehler als DataCancel bzw. Datenaufheben oder Error bzw. Fehler behandelt werden soll, wie unten in Tabelle 11 beschrieben.
TABELLE 11 – Data/Cancel/Error-Codierung
DataCancel ist verwendet zum Aufheben eines Datenbuspaketes. Aber solch eine Betätigung hebt nur das Datenbuspaket auf und hebt nicht die Transaktion auf. Diese Prozedur ist verwendet, wenn ein Datenbuspaket ungültig ist, oder wenn eine "abgegebene" Schreib-Typ-Operation die Daten nicht annehmen kann. Diese zwei Fehlercodierungen erlauben vorteilhafter Weise Geräten, zwischen zwei Fehlertypen zu unterscheiden, somit der UPA-Zusammenschalt-Architektur entsprechend.
Genauer genommen kann ein ungültiges Datenpaket von Lese-Transaktionen für in einem Zwischenspeicher bzw. Cachebesessenen Leitungen resultieren, wenn der Speicher seine Antwort beginnt, bevor das Owned-Signal verfügbar ist. Diese Lage kann zum Beispiel in einem Versuch resultieren, Speicherlatenz zu reduzieren.
Alternativ, wenn eine Schreibtypoperation durch die Einleitungseinheit "abgegeben" ist, kann der Bestimmungsort die Daten nicht annehmen. Der Bestimmungsort hebt dann das Datenbuspaket auf und nimmt die Verantwortlichkeit an zum "Holen" der Daten, eine hier später beschriebene Prozedur bezüglich von WriteStream-, WriteIO-, und WriteBlockIO-Operationen.
In der bevorzugten Ausführungsform verwendete Paritätssignale:
Vorzugsweise verwendet System 30 zwei Paritätssignale, ParityA und ParityD, zum Schützen der Zustands-, Status-, Daten-ID-, und Arbitrierungssignale, wobei beide Paritätsbits eine gerade Parität codieren.
ParityA ist verwendet zum Schützen von Signalgruppen, die während "Adresszyklen" getrieben sind, z.B. Zyklen, während derer eine Datenbusarbitrierung getrieben ist. Diese Signalgruppen beinhalten das Reserved-Bit in dem Adressbus, Owned-, Mapped-, ECCVAlid-, DCESel-, und DataCancel/Error-Signale, die auf dem Daten-ID-Bus gemultiplext sind, und die Arbitrierungssignale.
ParityD ist verwendet zum Schützen von Signalgruppen, die während "Datenzyklen" getrieben sind, z.B. Zyklen, während derer eine Datenbusarbitrierung getrieben ist. Diese Signalgruppen beinhalten Daten-ID, das Ignore-Signal, Shared-Leitungen und Arbitrierung. Da sie in beiden Zyklen getrieben sind, wird gewürdigt werden, dass Arbitrierungssignale durch beide Paritätsfelder geschützt sind. ParityA und ParityD sind beide auf dem Daten-ID-Bus gemultiplext und sind durch höchstens ein Board getrieben, wobei Software das Board zum Treiben der Parität auswählt.
5 veranschaulicht Signal-Timings für ParityA und ParityD. Wie gezeigt, ist ParityD um einen Zyklus verzögert von den Signalen, die es schützt, weil ParityD in demselben Zyklus wie ParityA getrieben ist. Mit System 30 verwendbare Konfigurationssignale beinhalten Takte, JTAG, und andere Implementierungs-abhängige Signale.
ReadToShare-Transaktions-Timing:
6 veranschaulicht Signal-Timing-Beziehungen für eine ReadToShare-Transaktion, die durch Board 1 eingeleitet ist (z.B. eine erste Leiterplatte (50-1 in 1) für Adresse A, deren Heimat im Board 2 ist (z.B. 50-2)). In 6 und 7 sind die fixierten Timing-Beziehungen veranschaulicht durch nummerierte durchgezogene Pfeile, wobei Kausal-Variabel-Timing-Kausal-Beziehungen mit gestrichelten Pfeilen gezeigt sind. Wie bemerkt, bezeichnen "A" und "D" Adress- und Datenzyklusteile des Haupttaktsignals.
Das Beispiel von 6 zeigt die schnellsten (z.B. minimalen) Timing-Werte für diese Beziehungen für eine Lese-Typ-Transaktion. In einer Schreib-Typ-Operation wird die Einleitungseinheit auch für den Datenbus arbitrieren. Somit ist in einer Schreibtypoperation das schnellste Timing für das Datenbuspaket zwei Zyklen früher.

(1) In dem Beispiel von 6 nimmt Board 1 den Vorteil einer schnellen Arbitrierung für den Adressbus und treibt den ersten und zweiten Adressbuszyklus als auch seine Arbitrierungsleitungen, in Zyklus 0. Das Adressbuspaket ist mit Quellen-ID (SourceID) i markiert (getrieben in dem nächsten Zyklus). Hätten mehrere Boards gleichzeitig die Adress- und Arbitrierungsbusse getrieben, würde der Adressbus ignoriert werden für diese Zyklen. Ein Arbitrierungsgewinner würde bestimmt werden, und der Gewinner würde stattdessen den Adressbus im Zyklus 2 treiben, wie durch 7 veranschaulicht.
(2) Fünf Zyklen, nachdem der Adresszyklus auf dem Adressbus erscheint, machen alle Boards angemessene Werte für das Shared-Signal und das Ignore-Signal geltend, zusammen bezeichnet als "S,I" in 6 und 7.
(3) Einen Zyklus, nach dem Shared-Signal, d.h. sechs Zyklen nach dem ersten Adressbuszyklus, machen die Boards den angemessenen Wert für das Owned-Signal geltend (siehe 6).
(4) Board 2, da es die Heimat von Adresse A ist, decodiert die Adresse und tätigt eine Arbitrierungsanforderung für den Datenbus im Zyklus 3. Wenn es die Arbitrierung gewinnt, wird es den Daten-ID-Bus 2 Zyklen später mit der Quellen-ID i treiben.
(5) Drei Zyklen nach Treiben des Daten-ID-Busses treibt Board 2 die Statussignale. DataCancel kann notwendig sein, zum Beispiel, wenn die Heimat (Board 2) den Datenbus anfordert, Speicherlatenz zu reduzieren. Beim Tätigen solcher einer Anforderung, nimmt die Heimat an, dass sie das bereitstellen werden wird, Heimat wird seine Anforderung aufheben, wenn tatsächlich ein anderes Board der Besitzer ist.
(6) Zwei Zyklen nach Treiben der Statussignale, treibt Board 2 den ersten von zwei Datenzyklen (d0, d1) auf dem Datenbus.

Arbitrierungs-Timing:
6 und 7 veranschaulichen eine Schnell-Modus-Arbitrierung, wobei kreuzschraffierte Adressbuszyklen in 7 eine Kollision mit Board 4 bezeichnen. In diesem Beispiel gewinnt Board 1 die Arbitrierung und treibt den Adressbus wieder im Zyklus 2. Board 4 arbitriert für den Adressbus wieder im Zyklus 2 und treibt den Adressbus wieder im Zyklus 4. Die durch Board 4 eingeleitete nachfolgende Transaktion ist in 6 durch schattierte bzw. schraffierte Blocks angezeigt.
Datenübertragungen und Transaktions-ID-Verwaltung:
Datenübertragungen sind entweder vom Lese-Typ oder Schreibe-Typ. Lese-Typübertragungen involvieren Datenübertragung von der Antworteinheit zu der Einleitungseinheit, wohingegen Schreib-Typübertragungen Datenübertragungen von der Einleitungseinheit zu der Antworteinheit involvieren.
Lese-Typ-Datenübertragungen:
Lese-Typ-Datenübertragungen involvieren eine Antworteinheit, die Speicher oder ein Gerät sein kann. Für zwischenspeicherbare Übertragungen kann ein Speicher spekulativ ein Datenpaket starten durch Ausgeben einer Daten-ID, aber schließlich das Datenpaket durch Geltendmachen von DataCancel aufheben. (Siehe die hier früher erfolgte Beschreibung bezüglich Statussignalen und Tabellen 7 und 10.) Ein spekulativer Start und nachfolgende Aufhebung kann eine Latenz minimieren für den allgemeinen Fall, in welchem zwischenspeicherbare Lese-Anforderungen vom Speicher befriedigt werden. Aufhebung kann aus verschiedenen Gründen resultieren, einschließlich Geltendmachung von Ignore oder Owned für das Adresspaket, oder das Adresspaket war ein RTO und die Einleitungseinheit machte Shared geltend (in welchem Fall die Einleitungseinheit nicht irgendeine Antwort erwartet).
Wenn Speicher ein Datenpaket aufheben muss, gibt er die Daten-ID für dieses Paket innerhalb von 11 Zyklen des ersten Adressbuszyklus für die Transaktion aus (wie hier im Nachfolgenden beschrieben unter Regeln für Transaktions-IDs). Wenn die Antworteinheit ein Gerät ist, eher als Speicher, dann ist das Datenpaket nicht aufgehoben.
Schreib-Typ-Datenübertragungen:
Schreib-Typ-Datenübertragungen involvieren zuerst ein "Abgeben" von Daten durch die Einleitungseinheit, z.B. arbitriert die Einleitungseinheit für den Datenbus und treibt die Daten zu der Antworteinheit. Wie hier früher bezüglich von Statussignalen beschrieben wurde, wenn die Antworteinheit nicht bereit ist zum Annehmen der Daten, macht die Antworteinheit DataCancel geltend, um das Datenpaket aufzuheben. Die Antworteinheit nimmt dann die Verantwortlichkeit an zum "Holen" der Daten und wird Schreib-Typ-Transaktionen verfolgen, deren Datenbuspakete sie aufgehoben hat. Wenn die Antworteinheit bereit ist zum Annehmen der Daten, arbitriert sie für den Datenbus und erhält die Daten von der Einleitungseinheit, die bereit sein sollte zum Liefern der Daten. Wenn Ignore geltend gemacht ist für eine Schreib-Typ-Transaktion, sollten keine Datenpakete ausgegeben werden.
Alternativ, wenn eine angemessene Unterstützung für das Gerätschnittstellenprotokoll bereitgestellt würde, könnte das Protokoll für Schreib-Typ-Transaktionen vereinfacht werden. Wenn zum Beispiel der Mechanismus zum Erhalten von Schreibdaten von dem Gerät sich von dem Mechanismus zum Bestätigen einer Vollendung der Schreib-Operationen unterscheiden würde, könnte man dann den Bestimmungsort der Schreib-"Holen"-Daten haben. In diesem Fall gäbe es keinen Bedarf, dass "Abgeben", gefolgt durch das "Holen", zu spezifizieren. Jedoch stellt vorzugsweise das UPA-Protokoll ein gemeinsames S_REPLY bereit, was dazu dient, die Schreibdaten von dem Gerät zu erhalten, und auch Vollendung des Schreibens zu signalisieren.
Die Regeln für Transaktions-IDs werden nun beschrieben werden. Jedes Board hat sieben eindeutige Transaktions-IDs. Zum Sicherstellen, dass Transaktions-IDs eindeutig Transaktionen spezifizieren, sollten die Boards die folgenden Regeln beachten.
Board-Regeln bezüglich Aufrechterhalten von eindeutigen IDs:

(1) Die Daten-ID für eine Antwort für eine Transaktion sollte nicht früher auftreten als der dritte Zyklus nach dem ersten Zyklus des entsprechenden Adressbuspaketes;
(2) Für Schreib-Typ-Transaktionen, in denen Ignore geltend gemacht ist, sollten keine Datenpakete ausgegeben werden. Jedoch ist diese Regel nur relevant für Systeme, in denen Ignore geltend gemacht ist (z.B. einem verteilten geteilten Speicher oder DSM-System). In der bevorzugten Ausführungsform ist ein Modus-Bit verwendet, um Datenpakete abzuhalten von einem Ausgeben von Schreibtypoperationen, bis der Wert von Ignore bekannt ist;
(3) Für WriteBack-Transaktionen, für welche die Einleitungseinheit Owned geltend macht und für welche Ignore nicht geltend gemacht ist, wird die Einleitungseinheit das Datenbuspaket senden. Das Heimat-Board wird entweder das Paket annehmen oder DataCancel geltend machen. Wenn es DataCancel geltend macht, wird das Heimat-Board die Daten mit einem anderen Datenpaket "holen". In jedem Fall wird die Heimatstelle nicht Speicher-schreiben und lediglich die Daten verwerten;
(4) Für Interrupt-Transaktionen, für welche Shared geltend gemacht ist, und für welche Ignore nicht geltend gemacht ist, kann die Einleitungseinheit das Datenpaket senden. Wenn die Einleitungseinheit das Datenpaket sendet, kann die Antworteinheit die Daten verwerfen, aber sollte nicht DataCancel geltend machen;
(5) Eine Transaktions-ID kann erneut verwendet werden für eine neue Transaktion, die zwei Zyklen nach dem DataCancel-Zeitschlitz für die Antwort zu der vorherigen Transaktion startet, wenn die Transaktion nicht aufgehoben wurde;

Für einige Transaktionen kann die Einleitungseinheit nicht länger eine gültige Antwort erwarten, noch könnten Antworteinheiten Datenpakete ausgeben, die sie nachfolgend aufheben. Weil die Einleitungseinheit nicht eine Antwort erwartet, könnte die Einleitungseinheit möglicherweise eine neue Transaktion mit Verwenden derselben Transaktions-ID einleiten. Zum Beispiel braucht eine ReadToOwn-Transaktion, für welche die Einleitungseinheit Shared geltend macht, nicht eine gültige Antwort. Ein weiteres Beispiel sei eine Speicher-Lese-Operation, für welche ein Board Owned geltend macht und mit den Daten antwortet, so dass keine Antwort vom Speicher dann erforderlich ist.
Board-Regeln bezüglich eines Nicht-Fehlinterpretierens einer aufgehobenen Antwort:
Um ein Missverstehen der aufgehobenen Antwort auf die erste Transaktion für eine Antwort zu der nachfolgenden Transaktion mit derselben Transaktions-ID zu vermeiden, sollten Boards die folgenden zwei Regeln beachten. (Die folgenden Regeln treffen nicht auf Transaktions-IDs zu, für die es keine Möglichkeit gibt einer nachfolgenden aufgehobenen Antwort.)

(6) Die ID für eine Lese-Typ-Transaktion, für welche eine aufgehobene Antwort vorliegen könnte, sollte nicht erneut verwendet werden, bis 14 Zyklen nach dem ersten Adressbuszyklus der ursprünglichen Transaktion. Anders gesagt, gibt es sechs Adressbuspaketschlitze nach dem ursprünglichen Adressbuspaket, für welche die ID nicht benutzt werden kann;
(7) Ein Board sollte nicht auf dem Daten-ID-Bus antworten mit der ID für irgendeine Transaktion, die es später als den 11-ten Zyklus nach dem ersten Zyklus des entsprechenden Adressbuspaketes aufheben werden wird. Wenn das Board nicht eine Antwort verhindert kann, sollte es einen Leerlauf-Daten-ID-Code verwenden, eher als die Transaktions-ID der ursprünglichen Transaktion.

Transaktions-Ordnen:
Bezüglich des Ordnens und einer Flussteuerung stellt der Adressbus vorzugsweise eine einzige globale Reihenfolge bereit, die verschiedene Anordnungen verwenden können, um ihre spezifischen Speichermodelle zu implementieren. Somit kann ein Implementierungs-spezifisches Ordnen variieren. Wie hier später beschrieben, kann System 30 mit UPA-spezifizierten Geräten verwendet werden.
Cache-Kohärenz:
Cache-Kohärenz wird nun beschrieben werden. Ein verwendetes Protokoll erlaubt Boards, Zurückschreib-Zwischenspeicher mit einem Ungültigkeitserklärungs-basierten und Besitz-basierten Cache-Kohärenzprotokoll zu implementieren.
Verständlicherweise kann es schwierig sein, mit solchen Protokollen ein korrektes Verhalten sicherzustellen, da Besitz von einem Board zu einem anderen übertragen wird. In alternativen Protokollen wird ein Besitz zusammen mit den Daten übertragen (d.h. zusammen mit der Antwort), aber es wird erwartet, dass der korrekte Besitzer immer auf Anforderungen antwortet. Sicherstellen einer ordnungsgemäßen-Antwort kann schwierig sein, wenn Anforderungen innerhalb eines schmalen Fensters der tatsächlichen Übertragung von Daten kommen.
System 30 überwindet diese Schwierigkeit durch Unterscheiden zwischen dem Besitzer und dem Schreiber für eine Leitung. Ein Board wird der Besitzer, sobald es den Besitz anfordert, mit Verwenden des ReadToOwn-Adressbuspaketes. Andererseits ist der Schreiber das Board, das tatsächlich die Daten für die Leitung hat, die unsauber sein kann. Sofern die Leitung nicht geteilt bzw. gemeinsam genutzt ist, kann der Schreiber zu der Leitung schreiben.
Urheberschaft (z.B. Schreiben) folgt Besitz von Board zu Board. Dies stellt sicher, dass die Reihenfolge von Schreibvorgängen dieselbe ist, wie die globale Reihenfolge zu ReadToOwn-Transaktionen auf dem Adressbus. Besitz ist zu einem anderen Board übertragen mit ReadToOwn-Einleitungen und ist zu der Heimat der Leitung abgegeben mit der WriteBack-Einleitung des eigenen Boards. Besitz ist auch abgegeben, wenn ein anderes Board eine WriteStream-Transaktion einleitet. Urheberschaft ist übertragen oder ist abgegeben mit Antworten, die die aktuellen Daten tragen. In der Praxis braucht die Zeitperiode, während welcher ein Board ein Besitzer für eine Leitung ist, nicht mit der Zeitperiode überlappen, während welcher das Board der Schreiber für die Leitung ist.
Der Besitzer kann andere Anforderungen für die Leitung empfangen, selbst, bevor er tatsächlich die Daten empfängt. Vom Besitzer wird gefordert, alle solche Anforderungen zu verfolgen, und schließlich auf alle Anforderungen zu antworten, in der Reihenfolge, nach dem Schreiber werden.
Vorzugsweise wird von den folgenden Geltendmachungen gefordert, wahr zu sein für das beschriebene System 30:

(1) Es gibt höchstens einen Besitzer für eine Leitung zu jeder Zeit;
(2) Es gibt höchstens einen Schreiber für eine Leitung zu jeder Zeit;
(3) Ein Board wird der Besitzer für eine Leitung, bevor es der Schreiber für die Leitung werden kann;
(4) Wenn kein Schreiber für eine Leitung vorliegt, ist die Leitung auf dem neuesten Stand in ihrem Heimatspeicher; und
(5) die Reihenfolge, in der Besitz von Board zu Board übertragen wird, ist dieselbe, wie die Reihenfolge, in welcher die Urheberschaft von Board zu Board übertragen wird.

Ungültigkeitserklärung:
Ungültigkeitserklärung wird nun beschrieben werden. Das ReadToOwn-Adressbuspaket fordert auch alle Boards bis auf die Einleitungseinheit an, ihre Kopien einer Cache-Leitung für ungültig zu erklären. Im Gegensatz dazu, gemäß alternativen Ungültigkeitserklärungsprotokollen nach dem Stand der Technik, ist eine Ungültigkeitserklärung nicht als vollständig betrachtet, bis alle Boards ihre Vollendung einer Ungültigkeitserklärung bestätigen. Jedoch sind solche Protokoll schwierig effizient zu implementieren in einem großen System, so wie Systemen, mit welchen die vorliegende Erfindung bereits ausgeübt werden kann.
Da System 30 vorzugsweise implementiert ist, vollendet die Antwort (vom Besitzer oder von der Heimat, wenn kein Besitzer vorliegt) die Transaktion ohne Warten auf Bestätigungen von anderen Boards. Jedoch werden Ungültigkeitserklärungen in allen Boards mit der Leitung in einer Warteschlange eingereiht. Da alle kohärenten Bustransaktionen von einem Board in Reihenfolge von der Warteschlange vollendet werden, wird eine Ungültigkeitserklärung vor irgendwelchen nachfolgenden kohärenten Transaktionen vollendet sein.
Ähnlich zum Besitz wird eine Leitung geteilt mit einem ReadToShare- oder ReadToShareAlways-Adressbuspaket, eher als mit einem Antwort-Datenbuspaket.
Cache-Kohärenz und Ordnen für die bevorzugte Ausführungsform der vorliegenden Erfindung mit Verwenden von UPA-Geräten werden nun mit Verweis auf 3 beschrieben werden. Weil UPA-Spezifikationen dem Fachmann in dem relevanten Fachgebiet bekannt sind, werden sie hier nicht zur Schau gestellt. In der bevorzugten Ausführungsform unterstützt System 30 UPA-Schnittstellen-erfüllende Geräte, aber unterscheidet sich in manchen Wegen von "UPA Interconnect Architecture". Somit sollte man den Unterschied zwischen UPA-Zusammenschalt-Architekturspezifikation (z.B. einer Spezifikation für eine bestimmte Systemimplementierung als ein Ganzes) und einer zukünftigen "UPA Interface"-Spezifikation (z.B. einer Spezifikation für die Schnittstelle zwischen den UPA-Geräten und dem System) erkennen. "UPA Interconnect Architecture" kann für sich übermäßig einschränkend sein beim Ermöglichen von effizienten Implementierungen von größeren Systemen 10, so wie hier bevorzugt. Solche übertriebenen Einschränkungen beinhalten Warten auf Bestätigungen für Ungültigkeitserklärungen von allen Geräten vor Bestätigen der die Ungültigkeitserklärung bewirkenden Transaktion, als auch verschiedenen Index- und Adress-Blockierregeln.
Laut UPA-Spezifizierung ist Warten auf Bestätigungen für Ungültigkeitserklärungen von allen Geräten vor Bestätigen der die Ungültigkeitserklärung bewirkenden Transaktion relativ einfach. Für kleine Systeme wird Komplexität vermieden, weil die Systemsteuereinheit (System Controller, "SC") vorzugsweise ein einzelner Chip ist mit Punkt-zu-Punkt-Verbindungen zu jedem UPA-Anschluss in dem System, aber es ist schwierig, dieses effizient für ein größeres System zu tun. In Schnittstelle 30 wartet Adresssteuereinheit 180 jedoch nicht auf Bestätigungen für Ungültigkeitserklärungen, schon bekannte Speichermodelle sind noch implementiert, einschließlich zum Beispiel des Sun Microsystems SunS-Speichermodells. Bezüglich verschiedener Index- und Adressblockierregeln, da eine UPA-Spezifikation SC eine einzelne zentralisierte Entität ist, kann Index- und Adressblockieren unkompliziert für kleine Systeme sein. (Eine Implementierung ist schwieriger für ein größeres System, in welchem eine Einzel-Chip-SC undurchführbar ist.) Wie bemerkt, implementiert Schnittstelle 30 nicht ein Index- oder Adressblockieren und erfordert dieses auch nicht.
Schnittstelle 30 vereinfacht ferner andere Aspekte, die unnötiger Weise in der "UPA Interconnect Architecture" spezifiziert sind. Zum Beispiel ist ein einfaches Drei-Zustand-Dtag-Protokoll eingesetzt, das nur O-, S-, und I-Zustände hat. Dieses Protokoll ist für alle praktischen Zwecke äquivalent zu dem UPA-spezifizierten MOESI-Dtag-Programm. Interface 30 erlaubt auch einen Modus, in welchem ein MOESI-Etags-Protokoll zu einem MOSI-Protokoll geändert werden kann, durch Behandeln aller ReadToShare-Transaktionen als ReadToShareAlways-Transaktionen.
UPA-Gerät-Transaktions-Ordnen:
Der Adressbus kann einen Punkt definieren, an welchem eine einzelne globale Reihenfolge von allen Transaktionen aufgebaut sein kann, einem sogenannten "Punkt einer globalen Sichtbarkeit". Solch ein einzelnes globales Ordnen erlaubt vorzugsweise ein Implementieren einer Speicherreihenfolge, so wie der Sun Microsystems-Speicherreihenfolge, mit Verwenden der in 3 gezeigten Warteschlangen, welche Warteschlangen nur für ein UPA-Gerät (z.B. eine CPU) sind, und nicht für Speicher.
Im System 30 sind alle Gerätanforderungen ("P_REQs") an Adressbus 60 in Reihenfolge ausgegeben, wie dargestellt durch eine Anforderungsausgangswarteschlange (Request Out Queue, "ROQ") 176 in 3. Alle für das Gerät relevanten kohärenten Anforderungen und Unterbrechungen (einschließlich fremde kohärente Anforderungen und seine eigenen kohärenten Anforderungen) sind in der kohärenten Eingangswarteschlange (Coherent In Queue, "CIQ") 182 platziert, nachdem sie durch Dtags von DTAG-RAM 220 "gefiltert" werden. Alle Gerät-PIO-Anforderungen sind in der Lokal-PIO-Warteschlange (Local PIO Queue, "LIOPQ") 183 platziert und alle fremden PIO-Anforderungen für das Gerät sind in der Fremd-PIO-Warteschlange (Foreign PIO Queue, "FPIOQ") 184 platziert, wie in 3 gezeigt. Allgemein werden Transaktionen von jedem dieser Warteschlangen in Reihenfolge von dem Kopf der Warteschlange gehandhabt. Eine Ausnahme sind WriteBacks von dem Gerät, für welche eine spezielle Optimierung implementiert ist. WriteBacks und Opferung (Victimization) (einschließlich der Funktionen der Dvict- und Vbuffer-Blöcke) sind hier weiter beschrieben.
Zusätzlich, wie in 3 gezeigt, sind Gerät-P_REQs in zwei Warteschlangen platziert, C0Q 174 und C1Q 175, abhängig von der UPA-Klasse. Die Warteschlangen C0Q und CIQ arbeiten, um die Reihenfolge von S_REPLYs gemäß der Reihenfolge von P_REQs aufrecht zu erhalten für jede Klasse, wie gefordert durch die UPA-Spezifizierung.
Zu und von Gerät 160-N gehende Daten sind in zwei Puffern (z.B. wahren Puffern, nicht Warteschlangen) Datenausgangspuffer (Data Out Buffer, "DOB") 186 und Dateneingangspuffer (Data In Buffer, "DIB") 187 gepuffert, so wie in 3 gezeigt. Daten brauchen nicht in derselben Reihenfolge wie das Adressbuspaket gesendet oder empfangen sein, und die Reihenfolge von Datenbuspaketen ist nicht auf die Speicherreihenfolge bezogen.
Ordnen von kohärenten Transaktionen:
Nun wird Ordnen von kohärenten Transaktionen beschrieben werden. Alle kohärenten Transaktionen sind in derselben Reihenfolge geordnet, wie sie auf dem Adressbus erscheinen, unabhängig von der UPA-Klasse. Die Transaktionen werden in der Reihenfolge von dem Kopf einer kohärenten Eingangswarteschlange (Coherent Input Queue, "CIQ") 182 bedient, wie in 2 und 3 gezeigt. Die verschiedenen kohärenten Transaktionen werden nun individuell beschrieben werden.
Bezüglich lokalen ReadToShare-, ReadToShareAlways-, und ReadStream-Transaktionen wartet eine Adresssteuereinheit 180 darauf, dass die Daten für diese Transaktionen ankommen, und gibt dann S_REPLY an das Gerät gefolgt durch die Daten aus.
Fremdes ReadToShare, ReadToShareAlways und ReadStream sind Transaktionen, für welche die Adresssteuereinheit die Owned-Leitung geltend machte und folglich die Daten bereitstellen wird. Man beachte, dass das Gerät inzwischen die P_WB_REQ auf der UPA ausgegeben haben kann. Dieser Fall als auch der Fall eines SYSIO (welcher keine CopyBack S_REQs annehmen kann) werden nun unten separat beschrieben werden. Adresssteuereinheit 180 gibt die angemessene CopyBack S_REQ an das Gerät aus (S_CPB_REQ für ReadToShares und ReadToShareAlways, S_CPD_REQ für ReadStream), wartet auf das P_SACK oder P_SACKD P_REPLY, gibt das S_CRAB S_REPLY aus und lädt die Daten in den DOB. In diesem Augenblick kann die Transaktion aus der kohärenten Eingangswarteschlange 182 entfernt werden. Unter vorzugsweise Verwenden von verteilten Round-Robin-ARB-Einheiten 186 arbitriert Adresssteuereinheit 180 für den Datenbus und überträgt die Daten später. Jedoch können alternative Arbitrierungsverfahren verwendet werden.
Die Lokal-ReadToOwn-Transaktion involviert eine Betrachtung von zwei Fällen. In einem Fall hat das Gerät nicht eine gültige Kopie der Daten, ein Fall, der wie andere lokale Lesevorgänge behandelt wird, oben beschrieben. Adresssteuereinheit 180 wartet darauf, dass die im Dateneingangspuffer (Data Input Buffer, "DIB") 187 verfügbar sind, gibt das S_RBU S_REPW aus und stellt dann die Daten bereit. Im zweiten Fall hat das Gerät eine gültige Kopie der Daten. Hier gibt die Adresssteuereinheit 180 ein S_OAK S_REPLY an das Gerät aus, ohne auf die Daten zu warten. Weil die Adresssteuereinheit Shared geltend machte, werden weder Speicher noch ein anderer die Daten besitzender Zwischenspeicher bzw. Cache mit Daten antworten.
Die Fremd-ReadToOwn-Transaktion stellt auch zwei Fälle zur Betrachtung. Im ersten Fall ist das Gerät nicht der Besitzer, oder die Einleitungseinheit machte das Shared-Signal geltend, um anzuzeigen, dass sie bereits die Daten hat.
Adresssteuereinheit 180 wird ein S_INV_REQ an das Gerät ausgeben und auf P_REPLY warten, und keine Daten sind übertragen. Im zweiten Fall ist das Gerät der Besitzer, und die Einleitungseinheit macht nicht ihr Shared-Signal geltend. Nun geht Adresssteuereinheit 180 die P_CPI_REQ an Gerät 160-N, wartet auf das P_REPLY, gibt das S_CRAB S_REPLY aus und lädt die Daten in Datenausgangspuffer (Data Out Buffer, "DOB") 186. In diesem Augenblick kann die Transaktion von der Warteschlange entfernt werden. Vorzugsweise ist ARB-Einheit 186 innerhalb von Adresssteuereinheit 180 verwendet zum Arbitrieren für den Datenbus und überträgt die Daten zu der Einleitungseinheit später. (Während ARB-Einheit 186 schnell ist, ist ihre geringe Latenz von geringer Bedeutung für eine Datenbusarbitrierung als für eine Adressbusarbitrierung in der bevorzugten Ausführungsform).
Die Lokal-WriteStream-Transaktion stellt zwei Fälle zur Betrachtung bereit. Im ersten Fall ist die Leitung in dem Gerät gültig. Die Adresssteuereinheit wird zuerst die Leitung in dem Gerät für ungültig erklären durch Erzeugen eines S_INV_REQ, auf die P_SACK/P_SACKD warten, und dann das S_WAB ausgeben zum Erlangen der Daten. Im zweiten Fall ist die Leitung nicht gültig in dem Gerät. Die Adresssteuereinheit kann das S_WAB ausgeben und Daten von dem Gerät erlangen. Die Transaktion kann dann von der Warteschlange entfernt sein, mit einer später auftretenden tatsächlichen Datenübertragung.
Für die Fremd-WriteStream-Transaktion erklärt die Zugriffssteuereinheit die Leitung in dem Gerät für ungültig durch Ausgeben eines S_INV_REQ, und Warten auf die P_SACK/P_SACKD. Die Transaktion kann dann von der CIQ entfernt sein.
Bezüglich der Lokal-Unterbrechungs-Transaktion, wenn der Bestimmungsort der Unterbrechung die Unterbrechung nicht annehmen kann, würde sie das Shared-Signal geltend machen. In diesem Fall gibt die AC ein S_INACK zu dem Gerät aus.
Andernfalls gibt die Adresssteuereinheit ein S_WAB aus, und lädt die Unterbrechungsdaten in den DOB für eine nachfolgende Übertragung zu dem Bestimmungsort. In der bevorzugten Implementierung sollte ein Gerät nicht eine Unterbrechung an sich selbst senden; sollte solch eine Unterbrechung gesendet werden, werden ein System-Timeout und Reset folgen.
Bezüglich der Fremd-Unterbrechungs-Transaktion, wenn die Adresssteuereinheit die Shared-Leitung für die Unterbrechung geltend machte, kann diese Transaktion verworfen sein. Andernfalls erwartet die Adresssteuereinheit die Daten, gibt die P_INT_REQ an das Gerät aus, gibt die S_WIB S_REPLY aus und überträgt die Daten. In diesem Augenblick ist die Transaktion von der Warteschlange entfernt. Das Gerät kann die P_IAK viel später ausgeben (möglicherweise durch eine Softwareaktion), und die Adresssteuereinheit sollte nicht andere Transaktionen abwürgen, während sie auf das P_IAK wartet.
Opferung (Victimization) und Lokal-WriteBack-Transaktionen:
Die Opferung bzw. Victimization und Lokal-WriteBack-Transaktionen werden nun mit Verweis auf 3 beschrieben. Für jeden UPA-Anschluss hat eine Adresssteuerung eine einzelne Markierung ("Dvict") 179 zum Abhören bzw. Lauschen für ein unsauberes Opfer, und einen einzelnen markierten Puffer ("Vbuffer") 188, um die Leistung von Cache-Verlusten mit unsauberen Opfern zu optimieren. Wenn eine Opferungs-Transaktion auf der UPA ausgegeben ist (d.h. ein Lesen mit dem gesetzten DVP-Bit), hat die entsprechende Transaktion innerhalb der vorliegenden Erfindung auch das Opfer-Bit bzw. Victim-Bit gesetzt. Für solche Transaktionen kopiert die Einleitungseinheit die entsprechende Opfer-Markierung von den Dtags zu Dvict. Abhören auf Dvict ist ähnlich wie auf Dtags durchgeführt. Fremde Anforderungen für die Leitung in Dvict können darin resultieren, dass die angemessene _REQ (CPB, CPI, INV) in die Warteschlange im CIQ eingereiht werden, und die Dvict-Markierung kann durch fremde Transaktionen 8RTO, WS) in der vorliegenden Erfindung für ungültig erklärt sein, ähnlich wie für Dtags.
WriteBacks bzw. Zurückschreiben erklärt vorzugsweise eine übereinstimmende Markierung in Dtags oder Dvict der Einleitungseinheit für ungültig. Abhören von Dtags als auch von Dvict erlaubt, dass WriteBacks durch die UPA ausgegeben sind vor oder nach der Opferungs-Lese-Transaktion. WriteBacks sind durch die Einleitungseinheit abgehört, so dass das WriteBack bzw. Zurückschreiben aufgehoben sein kann, wenn eine vorherige fremde Transaktion die Leitung für ungültig erklärte, die zurückgeschrieben wird. Dies ist erreicht durch die Einleitungseinheit, die Owned geltend macht, wenn die Leitung nicht in ihren Dtags oder Dvict besessen ist, wenn ein WriteBack bzw. Zurückschreiben in der vorliegenden Erfindung erscheint.
Wenn eine Transaktion ein sauberes Opfer hat (z.B. das DVP-Bit ist nicht gesetzt in der UPA P_REQ), ist die Markierung für das saubere Opfer nicht in Dvict kopiert. Der UPA-Anschluss wird S_REQs für das saubere Opfer senden, von fremden Transaktionen resultierend, vor der Opferungs-Lese-Transaktion erscheinend. Da die Lese-Anforderungen in der CIQ erscheinen nach den fremden Transaktionen, ist es sichergestellt, dass die Adresssteuereinheit nicht S_REQs für das saubere Opfer nach dem S_REPLY für das Lesen weiterleiten wird.
Bei der UPA-Schnittstelle sind WriteBacks bzw. Zurückschreiben etwas unterschiedlich von anderen Transaktionen aus Leistungserwägungen gehandhabt, als auch, um das SYSIO zu handhaben, welches nicht S_REQs annehmen kann (Copybacks bzw. Zurückkopieren oder Ungültigkeitserklärungen).
Wenn keine ausstehenden P_REQs von dem Gerät in derselben Klasse wie der P_WB_REQ vorliegen, wartet die Adresssteuereinheit darauf, dass irgendwelche ausstehenden S_REPLYs vollenden, und gibt dann das S_REPLY zu dem Gerät aus, möglicherweise bevor die Transaktion auf der vorliegenden Erfindung erscheint. Die Adresssteuereinheit 180 puffert die Daten in dem DOB 186 und erhält die Markierung für die Leitung in dem Vbuffer 188 aufrecht (siehe 3). In diesem Augenblick ist der Besitzer die Adresssteuereinheit und nicht das Gerät. Die Adresssteuereinheit wird alle fremden Anforderungen für die Leitung bedienen, ohne S_REQs-Anforderungen an das Gerät auszugeben. Dies ist getan durch Überprüfen von Zurückkopier/Ungültigkeitserklärungs-Anforderungen bei dem Kopf der Warteschlange mit bzw. gegen die Markierung im Vbuffer 188, und Daten sind von den im DOB 186 gehaltenen WriteBack-Daten geliefert. Die WriteBack-Transaktion ist auch von der vorliegenden Erfindung in CIQ 182 Warteschlangen eingereiht. Sobald die WriteBack-Transaktion den Kopf von CIQ 182 erreicht, sind per Definition alle fremden Anforderungen für die Leitung bedient worden. In diesem Augenblick kann die Transaktion von der Warteschlange entfernt sein und die Adresssteuereinheit gibt den "Besitz" ab durch Ungültigerklären von Vbuffer 188.
Wenn ausstehende P_REQs von derselben Klasse vorliegen, oder wenn Vbuffer bereits durch ein ausstehendes WriteBack verwendet wird, dann kann die Adresssteuereinheit nicht unmittelbar das S_REPLY für das WriteBack ausgeben. In diesem Fall ist das WriteBack zusammen mit den anderen kohärenten Transaktionen in der CIQ-Warteschlangen eingereiht, und wird Reihenfolge behandelt. Man beachte, da dieser Fall nicht für SYSIO auftritt, S_REPLY für WriteBacks von SYSIO unmittelbar ausgegeben werden wird, und keine S_REOs werden zu dem SYSIO gesendet. Fremde WriteBacks sind irrelevant für UPA-Geräte und sind nicht in CIQ gestellt.
Vbuffer 188 ist auch verwendet zum Optimieren von Copyback-Anforderungen bzw. Zurückkopier-Anforderungen, um eine Leistung während eines fremden kohärenten Lesens zu optimieren. Wenn Vbuffer nicht verwendet wird, ist in der Praxis die Markierung für ein fremdes Lesen (für welches eine Zurückkopier-Anforderung an die UPA gesendet ist) im Vbuffer gehalten, und die entsprechenden Daten sind in dem DOB gehalten. Wenn ein nachfolgendes fremdes Lesen den Vbuffer trifft, kann es befriedigt sein, ohne eine Zurückkopier-Anforderung zu dem Cache. Dieses hilft der Leistung, wenn mehrere Prozessoren eine gemeinsame Leitung anfordern, die in einem anderen Cache besessen ist. Dies ist ein übliches Auftreten, und kann auftreten zum Beispiel, wenn viele Prozessoren auf einen Spinlock warten. Sobald der den Spinlock haltende Prozessor den Spinlock freigibt durch Schreiben zu diesem, werden andere Prozessoren diese Leitung nicht kriegen und Anforderungen zu derselben durch den den Lock freigebenden Prozessor besessene Cache-Leitung tätigen.
Ordnen von PIO-Transaktionen wird nun beschrieben. Lokale PIO-Transaktionen sind in die LPQ platziert und sind gehandhabt, wenn sie den Kopf der Warteschlange erreichen. Lese-Transaktionen warten auf die Daten, bevor die Adresssteuereinheit das S_REPLY ausgibt. Für Schreib-Transaktionen gibt die Adresssteuereinheit das S_REPLY aus und lädt die Daten in den DOB, mit einer später auftretenden, tatsächlichen Datenübertragung.
Fremde PIO-Transaktionen sind in eine separate FPQ-Warteschlange platziert und sind gehandhabt, wenn sie den Kopf der Warteschlange erreichen. Fremde Lesevorgänge sind ausgegeben als P_NCRD_REC2 oder P_NCBRD_REQ, und die Daten sind erhalten mit der gewöhnlichen P_REPLY/S_REPLY-Sequenz. Wie immer folgt die tatsächliche Datenübertragung der Einleitungseinheit später. Mehrfache fremde Schreibvorgänge können zu einem Gerät ausgegeben sein, und Daten sind auch übertragen zu dem Gerät mit dem S_REPLY. In diesem Augenblick kann die Transaktion von der Warteschlange entfernt sein, aber die Adresssteuereinheit wird die S_REPLYs verfolgen für eine Flusssteuerung zu dem UPA-Anschluss.
UPA-Klassen und Ordnen von S_REPLYs involvieren die Erwartung von UPA-Geräten, das S_REPLYs zu ihren P_REQs innerhalb jeder Klasse in derselben Reihenfolge sein werden wie die P_REQs. Aber wo Transaktionsordnen aufrechterhalten ist nicht basierend auf Klassen, sondern eher darauf, ob die Operation in die CIQ oder die LPQ geht, erfordert die Adresssteuereinheit einen Mechanismus, um sicherzustellen, dass die S_REPLYs in der angemessenen Reihenfolge gegeben sind. Die C0Q- und C1Q-Warteschlangen stellen diesen Mechanismus bereit. Ein S_REPLY für eine lokale Transaktion bei dem Kopf der CIQ kann nur ausgegeben sein, wenn es auch bei dem Kopf von C0Q oder C1Q vorliegt. Andernfalls sollte zuerst einer Transaktion von der LPQ ein S_REPLY ausgegeben werden. Ähnlich sollte ein S_REPLY für eine lokale Transaktion, die bei dem Kopf der LPQ ist, nur ausgegeben sein, wenn sie auch bei dem Kopf der C0Q-Warteschlange oder C1Q-Warteschlange ist; andernfalls sollte einer Transaktion von der CIQ zuerst ein S_REPLY ausgegeben werden.
In der vorliegenden Erfindung dienen UPA-Klassen keiner nützlichen Funktion und komplizieren in der Tat den Entwurf, wie zum Beispiel in einem Fall eines Deadlocks (unten beschrieben). Die mit einer S_REPLY verknüpfte P_REQ ist implizit in der UPA aufgrund eines Erfordernisses, das S_REPLYs innerhalb jeder Klasse geordnet sein sollen. Wenn ein unterschiedlicher Mechanismus zum in Übereinstimmung bringen von Systembestätigungen mit Gerätanforderungen existierte, könnte man UPA-Klassen vollständig eliminieren, und somit den Entwurf der vorliegenden Erfindung vereinfachen.
Ein Deadlock kann resultieren aufgrund nicht-zwischenspeicherbarer und zwischenspeicherbarer Lesevorgänge derselben Klasse. Genauer genommen kann ein Deadlock auftreten, wenn das Folgende auftritt: Ein erstes UPA-Gerät gibt zuerst eine nicht-zwischenspeicherbarere Lese-Anforderung aus (NCRD, NCBRD), und gibt dann eine nicht-zwischenspeicherbare Lese-Anforderung aus (RDS, RDSA, RDO oder RDD), und beide Anforderungen sind ausstehend, und die nicht-zwischenspeicherbaren Lese-Anforderungen und die nicht-zwischenspeicherbaren Lese-Anforderungen sind in derselben Klasse, und die nicht-zwischenspeicherbare Lese-Anforderung ist zu einem IO-Bus (z.B. SBus) gerichtet auf einem zweiten UPA-Gerät, und ein Master auf demselben IO-Bus hat eine DMA-zwischenspeicherbare Lese-Anforderung ausgegeben, die in einem ersten UPA-Gerät besessen ist. Diese Anforderung erscheint innerhalb der vorliegenden Erfindung nach der zwischenspeicherbaren Lese-Anforderung von der ersten UPA, und der IO-Bus wird nicht einen erneuten Versuch ausgeben für den DMA-zwischenspeicherbaren Lesevorgang auf dem IO-Bus.
In dem beschriebenen Deadlock-Fall ist dem nicht-zwischenspeicherbaren Lesen von der ersten UPA das S_REPLY zuerst ausgegeben wegen der Klassenreihenfolge, aber Daten werden nicht erhalten werden, weil die DMA-Anforderung den IO-Bus hält. Die DMA-Anforderung kann nicht vollendet werden, weil sie hinter der zwischenspeicherbaren Lese-Anforderung ist, die nicht vollendet werden kann, weil das S_REPLY für die nicht-zwischenspeicherbare Lese-Anforderung zuerst gegeben sein sollte. Zum Vermeiden dieses Deadlocks wird ein Board in der vorliegenden Erfindung nicht eine zwischenspeicherbare Anforderung ausgeben, wenn eine nicht-zwischenspeicherbare Lese-Anforderung derselben Klasse bereits aussteht. (In der gegenwärtig bevorzugten Ausführungsform ist nur ein ausstehendes Lesen zu einer Zeit erlaubt, wodurch dieses Problem beseitigt ist.)
Flusssteuerung für CIQ-Transaktionen ist in der vorliegenden Erfindung implementiert mit Verwenden eines einzelnen FlowControl-Signals in dem Arbitrierungsbus. Beginnend zwei Zyklen, nachdem das FlowControl-Signal wie geltend gemacht beobachtet ist, sind keine neuen Transaktionen eingeleitet, die in der CIQ platziert sein würden.
Ein Flusssteuerungsmechanismus ist erforderlich, weil es möglich ist, dass die CIQ in einem Gerät blockiert sein kann (z.B. wartend auf eine Antwort auf eine durch das Gerät ausgegebene Lese-Anforderung). Während dieser Zeit können Adressbuspakete von anderen Geräten die CIQ füllen. Man beachte, dass in der vorliegenden Ausführungsform, während die gesamte Anzahl von ausstehenden Transaktionen auf 112 begrenzt ist durch die sieben ausstehenden Transaktions-IDs pro Board, Pakete in der CIQ von Transaktionen sein können, die bereits "vollendet" haben, und somit nicht länger "ausstehend" sind aus dem Blickpunkt der Einleitungseinheit und der Antworteinheit. Beispiele dafür sind ReadToOwn- oder WriteStream-Pakete für Daten, die in dem Gerät für ungültig erklärt werden sollen. Weder die Einleitungseinheit noch die Antworteinheit brauchen darauf zu warten, dass die tatsächliche Ungültigkeitserklärung in allen anderen Boards vollendet wird.
Zum Vermeiden eines Deadlocks sollte sichergestellt sein, dass die Sperrung irgendeiner Warteschlange, in deren Namen FlowControl geltend gemacht ist, schließlich aufgehoben wird. Aus diesem Grund ist FlowControl nicht geltend gemacht im Namen von FPQ, da IO-Raum-Anforderungen für ein Gerät durch eine frühere DMA-Anforderung von diesem Gerät blockiert sein können. Wenn FlowControl geltend gemacht ist, und die Transaktion für die DMA-Anforderung noch nicht eingeleitet worden ist, dann wird die Transaktion niemals eingeleitet werden, einen Deadlock verursachend. Folglich ist FlowControl vorzugsweise geltend gemacht zugunsten der CIQ, aber nicht zugunsten der FPQ. Somit sollte die FPQ ausreichend groß sein, um die maximale Anzahl von ausstehenden IO-Raum-Zugriffen von allen Geräten unterzubringen.
Flusssteuerung für LPQ ist unnötig in der bevorzugten Ausführungsform, da die Anzahl von ausstehenden Anforderungen von irgendeinem Gerät gegenwärtig durch die Transaktions-ID auf sieben begrenzt ist.
Flusssteuerung für Unterbrechungen wird nun beschrieben werden. Das P_IAK für eine zu einem Gerät gelieferte Unterbrechung kann wesentlich verzögert sein. Da nachfolgende Unterbrechungen nicht gegenwärtig zu dem Gerät geliefert sein werden, sollte daher ein Mechanismus bereitgestellt sein, um Unterbrechungen davon abzuhalten, andere Transaktionen oder Gerät abzuwürgen. In der bevorzugten Ausführungsform erhält jede Adresssteuereinheit einen Zähler für die Anzahl von ausstehenden Unterbrechungen aufrecht, die zu jedem seiner UPA-Anschlüsse ausgegeben sind. Wenn die Anzahl gleich ist zu der Anzahl von Unterbrechungen, die das Gerät annehmen kann, macht die Adresssteuereinheit das Shared-Signal für alle nachfolgenden Unterbrechungen geltend, was anzeigt, dass der Sender es erneut versuchen sollte. Der Zähler ist mit jeder angenommenen Unterbrechung inkrementiert und dekrementiert mit jedem empfangenen P_IAK. Man beachte, dass die CIQ nicht abgewürgt werden sollte durch Warten auf das P_IAK.
Die vorliegende Erfindung kann viel Überlappung zwischen mehreren ausstehenden Transaktionen unterbringen. In der vorliegenden Ausführungsform kann jeder UPA-Anschluss bis zu acht ausstehenden Transaktionen haben (ausstehend insofern, als die UPA betroffen ist), und keine Unterscheidung wird UPA-Klassen gemacht. Das UPA-Gerät muss mit der Anzahl von ausstehenden Anforderungen pro Klasse programmiert sein, und Firmware kann vorzugsweise die acht Anforderungen zwischen Klasse 0 und Klasse 1 auf irgendeine Weise zuteilen.
Da jeder Anschluss eine einzelne Dvict-Markierung hat, nachdem ein Lesen mit einem unsauberen Opfer ausgegeben ist, sollte WriteBack für dieses Lesen ausgegeben sein, bevor das nächste Lesen mit einem unsauberen Opfer ausgegeben werden kann. Jedoch erlaubt dieses noch, dass mehrere WriteBacks und mehreres Lesen mit unsauberen Opfern auf der UPA ausstehend ist, vorausgesetzt, dass sie "gepaart" sind, so dass nur eine Dvict-Markierung ausreicht. Es gibt keine weiteren Einschränkungen hinsichtlich der Anzahl von ausstehenden Lese-Anforderungen oder der Anzahl von ausstehenden unsauberen Opfern.
Es wird bemerkt, dass die UPA-Zusammenschalt-Spezifizierung einschränkender ist und ermöglicht, dass mehreres Lesen mit unsauberen Opfern und mehrere WriteBacks ausstehend sind, nur wenn sie angemessen "gepaart" sind und in derselben Klasse sind. In der vorliegenden Erfindung ist nur die "Gepaart"-Bedingung erforderlich, ohne eine Unterscheidung zu machen hinsichtlich der UPA-Klasse. Dies impliziert, dass zukünftige Ausführungsformen der vorliegenden Erfindung mehrere Cache-Verluste mit unsauberen Opfern ausgeben könnten, und noch eine gute Leistung aufrechterhalten könnten durch Halten von WriteBacks in einer unterschiedlichen Klasse von den Opferungs-Lese-Anforderungen.
Es wird erkannt werden, dass Schnittstelle 30 einige Vorteile über Bus-basierte Protokolle nach dem Stand der Technik bietet. Im Gegensatz zu dem Stand der Technik sind keine schwebenden Zustände erforderlich. Somit kann die Markierungszustandsmaschine eine einfache, fixierte Pipeline sein, deren Transaktionen einzig von Adresspaketen und deren Abhörinformation abhängen. Im weiteren Gegensatz brauchen Transaktionen, die mit schwebenden Transaktionen interagieren, nicht blockiert zu sein. Stattdessen behandelt Schnittstelle 30 solche Wechselwirkungen mit Verwenden einer einfachen Pipeline-Umgehung in der Markierungs-Pipeline.
Wie bemerkt kann jedes Board bis zu sieben ausstehende Transaktionen in der bevorzugten Ausführungsform der vorliegenden Erfindung haben, eine Grenze, gegenwärtig auferlegt durch die Transaktions-ID-Größe. Diese sieben ausstehenden Transaktionen sind gemeinsam genutzt bzw. geteilt durch die zwei UPA-Anschlüsse, ohne fixierte Zuteilung zu irgendeinem Anschluss, z.B. könnten alle sieben ausstehenden Transaktionen durch denselben UPA-Anschluss verwendet sein.
Mit weiterem Verweis auf 1 können die verschiedenen Boards 50-N vorzugsweise in Groundplane-Schlitze eingefügt werden, während System 10 läuft, ein sogenanntes "Hot Plug" bzw. "im Betrieb einstecken". Um ein Verursachen von Störspitzen auf Signalanschlüssen während eines Einsteckens eines Boards im Betrieb zu vermeiden, haben Boards 50-N vorzugsweise Verbindungsanschlüsse mit unterschiedlicher Länge. Board-Anschlüsse für Vorladungsleistung und Masse sind länger gemacht als andere Pins, um ursprünglich einen Kontakt herzustellen und das Board auf normale Betriebspegel vorzuladen, bevor irgendwelche anderen Board-Anschlüsse einen elektrischen Kontakt herstellen. Zusätzlich ist ein Satz von langen "Trigger"-Anschlüssen bereitgestellt zum Sicherstellen eines frühen elektrischen Kontakts, so dass das eingefügte Board ein Trigger-Signal geltend macht. Das Trigger-Signal ist eine frühe Warnung an andere Boards 50-N im System 10, das die Signal-Anschlüsse des neu eingefügten Boards bald elektrischen Kontakt herstellen werden.
Nach einer 16-Zyklus-Verzögerung machen die anderen Boards eine interne Pause geltend, die diese davon abhält, neue Anforderungen auf dem Bus zu tätigen, ihre internen Master-Anschluss-Timeout-Zähler werden angehalten, und ein interner programmierbarer Zähler wird gestartet. Die anderen Boards machen auch Trigger geltend zum Entprellen des Trigger-Signals, aber wenn Trigger entgeltend gemacht wird vor der 16-Zyklus-Verzögerung, wird der Zähler erneut gestartet. Wenn der interne Zähler abläuft, machen die Boards Trigger entgeltend, was fortwährend geltend gemacht ist durch das eingesteckte Board. Die Boards machen auch ein internes Frozen-Signal geltend, um das Bus-Anschauen zu stoppen. Die Zählerverzögerung ermöglicht den Boards, bereits gestartete Transaktionen zu vollenden und dann den Bus zu ignorieren, so dass irgendwelche Störspitzen keine Fehler verursachen. Die Zählerverzögerung ist vorzugsweise versetzt gemäß der Board-Anzahl, um gleichzeitige Freigabe des Trigger-Signals durch alle Treiber zu vermeiden. Rauschen von normalen Kontaktstart-herstellenden Signal-Anschlüssen und ein Satz von sogenannten Belegt-Anschlüssen bzw. Engaged-Pins zeigt dem Board an, das eingesteckt wird, dass die normalen Signal-Anschlüsse belegt werden. Dies startet eine Verzögerung in dem Board, das eingesteckt wird, und Rauschen von normalen Signal-Anschlüssen, die einen Kontakt herstellen, hört auf. Nachdem die Verzögerung von dem Engaged-Signal abläuft, macht das Board, das eingesteckt wird, Trigger entgeltend, und die anderen Boards in dem System machen internes Frozen entgeltend, um ein Anschauen des Busses erneut zu starten.
Zum Anpassen an mechanische Toleranzen haben die Boards-Stecker vorzugsweise einen Trigger-Anschluss auf jedem Ende des Steckers, und einen Engaged-Pin auf jedem Ende des Steckers. Das Trigger-Signal ist das logische ODER der zwei Trigger-Anschlüsse, wohingegen ein Engaged-Signal das logische UND der zwei Engaged-Anschlüsse ist.
Timing-Randbedingungen sind für das Kompensieren von Störspitzen während eines Einsteckens im Betrieb auferlegt. In der folgenden Notation entspricht Ti einer geordneten Ereignisnummer i. Zeitintervall T4–T3 sollte ausreichend sein, um alle ausstehenden Bustransaktionen zu vollenden, und ist ungefähr 10 ms in der bevorzugten Ausführungsform. Zeitintervall T2–T1 sollte ausreichend sein für die Leistung des eingefügten Boards ausreichend hoch zu laden, um Trigger geltend zu machen. Von Kontakt-herstellenden Signal-Anschlüssen resultierendes Rauschen sollte nicht vor der Zeit T5 starten, was bedeutet, dass die programmierbare Verzögerung kurz genug sein sollte zum Sicherstellen, dass Signalanschlüsse keinen Kontakt in dieser Zeit herstellen können. Durch Kontakt-herstellende Signal-Anschlüsse verursachtes Rauschen sollte vor Zeit T8 enden, was impliziert, dass Verzögerung T6–T8 (eine Verzögerung, die auf dem Board fixiert ist, das eingesteckt wird) ausreichend lang sein sollte, das Rauschen von Signal-Anschlüssen aufhört. Dies erlegt eine niedrigere Grenze der Geschwindigkeit auf, mit welcher das Board eingesteckt wird, und Verzögerung T8–T6 sollte ausreichend lang sein, um sicherzustellen, dass dies nicht eine tatsächliche Randbedingung ist.

Claims

Ein Computersystem mit einem geteilten Transaktionsbussystem, mindestens einer Speichereinheit (150-N), und einer Vielzahl von an das geteilte Transaktionsbussystem gekoppelten Vorrichtungen (50-N), wobei mindestens eine der Vorrichtungen konfiguriert ist zum Beginnen und/oder Erwidern einer Transaktion mit einem Adressbuspaket und einem Datenbuspaket, wobei jede der Vorrichtungen verknüpft ist mit einer Adresssteuereinheit (180), und wobei das geteilte Transaktionsbussystem enthält: einen Adressbus (60), der zum Mitführen eines mit mindestens einer Transaktion verknüpften Adressbuspakets konfiguriert ist; einen Datenbus (70), der zum Mitführen eines mit mindestens einer Transaktion verknüpften Datenbuspakets konfiguriert ist; eine Vielzahl von Zustandsignalleitungen (100), die den Zustand der durch das Adressbuspaket adressierten Leitung anzeigen, wobei das Computersystem gekennzeichnet ist durch einen an jede der Vorrichtungen gekoppelten gemultiplexten Arbitrierungsbus (80), der zum Mitführen von Adress- und Datenbustransaktions-Anforderungen konfiguriert ist, um Zugriff auf den Adressbus (60) und den Datenbus (90) zu erlangen mit alternierenden Adress- und Datenzyklen auf dem gemultiplexten Arbitrierungsbus beim Arbitrieren zwischen dem Adressbus und dem Datenbus, wobei für jede Transaktion ein Adressbuspaket auf dem Adressbus (60) getrieben wird und eine entsprechende Anforderung auf dem Arbitrierungsbus (80) getrieben wird, während eines selben Zyklus durch die Adresssteuereinheit von mindestens einer der Vorrichtungen; und wobei jede Vorrichtung den Adressbus (60) abhört zum Erlernen, ob eine identifizierte Speicherleitung besessen oder geteilt wird durch die jeweilige Vorrichtung, woraufhin ein Besitz- oder Geteiltsignal auf der entsprechenden Zustandsignalleitung des geteilten Transaktionsbussystems (20) geltend gemacht wird.
Das System nach Anspruch 1, wobei jedes Adressbuspaket zwei Taktzyklen lang ist, jedes Datenbuspaket zwei Taktzyklen lang ist, und Adressbus- und Datenbusarbitrierung auf dem Arbitrierungsbus (80) mit jedem Taktzyklus alternieren.
Das System nach Anspruch 1, wobei: das Computersystem Zwischenspeicherleitungen und einen Busebene-Markierungsspeicher (220) enthält, der Zustandsinformation für jede der Zwischenspeicherleitungen speichert, wobei der Busebene-Markierungsspeicher (220) durch die Vorrichtungen (160-N) zum Abhören verwendet wird; jede Vorrichtung (160-N) beinhaltet einen Vorrichtungsebene-Markierungsspeicher, der Zustandsinformation für jede der mit einer der Vorrichtungen (160-N) verknüpften Zwischenspeicherleitungen speichert; und einen Mechanismus zum Vergleichen einer Zustandsinformation in dem Busebene-Markierungsspeicher und in dem Vorrichtungsebene-Markierungsspeicher zum Identifizieren einer Anforderung, die ein Kandidat für ein Neuordnen ist.
Das System nach Anspruch 1 oder 2 oder 3, wobei die Vorrichtung (160-N) mindestens eine Eigenschaft hat ausgewählt von einer Gruppe bestehend aus (a) die Vorrichtung (160-N) enthält eine Zentralverarbeitungseinheit, (b) die Vorrichtung (160-N) enthält eine Eingabe-/Ausgabe-Vorrichtung, (c) die Vorrichtung (160-N) ist auf einer Leiterplatte (50-N) implementiert, die eine Adresssteuereinheit (180) enthält mit einem Mechanismus, der Anforderungen zum Zugreifen auf den Adressbus (60) arbitriert, (d) die Vorrichtung (160-N) auf einer Leiterplatte (50-N) implementiert ist, die eine kohärente Eingangswarteschlange (182) enthält, in die alle für die mit der Leiterplatte (50-N) verknüpften Vorrichtung angeforderten kohärenten Transaktionen vor Geltendmachung geladen werden, außer wenn das Computersystem ein Zeit-multiplexbares Ignorierungssignal geltend macht, wobei beim Nicht-Geltendmachen des Ignorierungssignals die Transaktion dann wieder ausgegeben wird, und, außer wenn ein Ignorierungssignal relevant für die wiederausgegebene Transaktion geltend gemacht wird, die wieder ausgegebene Transaktion in die kohärente Eingangswarteschlange geladen wird und auf dem geteilten Transaktionsbussystem als eine gültige Transaktion erscheinen wird, und (e) die Vorrichtung (160-N) auf einer Leiterplatte (50-N) implementiert ist, die Speicher (220-N) enthält und die die Vorrichtung Transaktionsadressdaten und auf der Leiterplatte Speicher abhört zum Erkennen eines Besitzzustands oder eines Geteiltzustands.
Das System nach Anspruch 1, ferner enthaltend: einen Daten-ID-Bus (90), der eine Daten-ID mitführt, die eindeutig auf eine Transaktionsanforderung reagierende Daten identifiziert; wobei das Adressbuspaket für jede Transaktion eine Quellen-ID enthält, die eine Leiterplatte (50-N) eindeutig identifiziert, die die Vorrichtung (160-N) enthält, die die Transaktion eingeleitet hat, und wobei die Quellen-ID ferner die Transaktion eindeutig identifiziert; und wobei die Daten-ID und die Quellen-ID dem Bussystem ermöglichen, Pakete auf dem Datenbus (70) mit früher auf dem Adressbus (60) platzierten Paketen anzupassen.
Das System nach Anspruch 1, wobei: ein Einleiten der Vorrichtung (160-N) Daten abgeben kann; und wenn ein Erwidern der Vorrichtung (160-N) gegenwärtig die Daten nicht annehmen kann, ein Datenaufhebungssignal geltend gemacht wird, woraufhin die erwidernde Vorrichtung (160-N) die Verantwortung für ein Aufnehmen bzw. Holen der Daten annimmt.
Die Vorrichtung nach Anspruch 6, wobei: ein Erwidern der Vorrichtung (160-N) ferner Schreibtyp-Operationen verfolgt, die sie aufnehmen bzw. holen soll; und ein Einleiten der Vorrichtung (160-N) mit den Daten erwidert, wenn das Erwidern der Vorrichtung (160-N) ein angemessenes Daten-ID-Signal auf dem Datenbus (70) treibt, wobei die Daten dadurch aufgenommen bzw. geholt werden.
Das System nach Anspruch 1, ferner eine Warteschlange (184) beinhaltend, in der geltend gemachte Anforderungen in der Warteschlange eingereiht werden, so dass Zustandstransaktionen auf dem Adressbus (60) atomar, logisch, ohne Abhängigkeit von einer Antwort darauf auftreten; wobei der geteilte Transaktionsbus ohne Blockieren einer Transaktionsanforderung funktioniert.
Das System nach Anspruch 1 oder 4, ferner einen Mechanismus zum Übertragen eines Besitzes der identifizierten Speicherleitung zu der Vorrichtung (160-N) in einem Paket auf dem Adressbus (60), wobei ein Besitz übertragen wird, auch wenn mit der verknüpften Transaktion verknüpfte Daten bisher übertragen sind, wobei die Vorrichtung (160-N) mit dem Besitz verantwortlich ist für ein Erwidern auf eine nachfolgende Anforderung für die Speicherleitung.
Das System nach Anspruch 3 oder 4, ferner beinhaltend: einen Mechanismus, der es ermöglicht, eine Transaktion in die kohärente Eingangswarteschlange (182) zu laden, wenn eine Gleichheit eines Zustands in dem Busebene-Markierungsspeicher (220) und in dem Vorrichtungsebene-Markierungsspeicher vorliegt, aber Verhindern eines solchen Ladens andernfalls; und eine Markierungspipelineumgehung, so dass Zustandstransaktionen auf dem Adressbus (60) atomar, logisch, ohne Abhängigkeit von einer Antwort darauf auftreten.
Das System nach Anspruch 7, wobei, wenn das Einleiten der Vorrichtung (160-N) ein Besitzsignal für eine Zurückschreibtransaktion geltend macht, eine Datenübertragung ohne Schreiben der Daten zu Speicher (150-N) auftritt, und das Einleiten der Vorrichtung (160-N) den Besitz einer geeigneten Speicherleitung abgibt, wenn ein Adresspaket für die Zurückschreibtransaktion ausgegeben wird.
Das System nach Anspruch 11, wobei die die Zurückschreibtransaktion ausgebende Vorrichtung (160-N) die Zurückschreibtransaktion aufhebt beim Auftreten mindestens eines Ereignisses, das aus einer Gruppe ausgewählt ist, bestehend aus (i) die mit der Vorrichtung (160-N) verknüpften Busebene-Markierungen zeigen an, dass die Vorrichtung (160-N) nicht der Besitzer ist, (ii) ein Besitztyp-Signal geltend gemacht wird, und (iii) ein Ignorierungssignal geltend gemacht wird.
Ein Verfahren zum Implementieren eines geteilten Transaktionsbussystems zum Gebrauch mit einem Computersystem mit mindestens einer Speichereinheit (220) und einer Vielzahl von Vorrichtungen (160-N), wobei mindestens eine von der Vielzahl von Vorrichtungen fähig ist zum Einleiten und/oder Erwidern auf eine Transaktion, ein Adressbuspaket und ein Datenbuspaket umfassend, wobei jede Vorrichtung (160-N) mit einer Adresssteuereinheit (180) verknüpft ist, und wobei das geteilte Transaktionsbussystem einen Adressbuspakete mitführenden Adressbus (60), einen zum Mitführen eines Datenbuspaketes konfigurierten Datenbus (70), verknüpft mit mindestens einer Transaktion, und eine Vielzahl von Zustandssignalleitungen (100) beinhaltet, die den Zustand der durch das Adressbuspaket adressierten Leitungen anzeigen, wobei das Verfahren die folgenden Schritte umfasst: Einleiten einer Transaktionsanforderung; Treiben eines Adressbuspakets auf einem Adressbus als Antwort auf ein Einleiten der Transaktionsanforderung, wobei der Adressbus konfiguriert ist zum Mitführen eines mit mindestens einer Transaktion verknüpften Adressbuspakets, gekennzeichnet durch die Schritte von Treiben der Transaktionsanforderung durch die Adresssteuereinheit der mindestens einen der Vorrichtungen auf einem mit jeder der Vorrichtungen gekoppelten gemultiplexten Arbitrierungsbus (80) während des Zyklus, in dem das Adressbuspaket auf dem Adressbus (60) getrieben wird; wobei der gemultiplexte Arbitrierungsbus konfiguriert worden ist zum Mitführen von Adress- und Datenbustransaktionsanforderungen mit alternierenden Adress- und Datenzyklen auf dem gemultiplexten Arbitrierungsbus beim Arbitrieren zwischen dem Adressbus und dem Datenbus; Abhören des Adressbusses (60) zum Erlernen, ob eine identifizierte Speicherleitung besessen oder geteilt ist, in Antwort auf ein Platzieren der Transaktionsanforderung auf dem Arbitrierungsbus (80); und Geltendmachen eines angemessenen Besitz- oder Geteiltsignals auf einer entsprechenden Zustandssignalleitung des geteilten Transaktionsbussystems als Antwort auf das Abhören.
Das Verfahren nach Anspruch 13, wobei jedes Adressbuspaket zwei Taktzyklen lang ist, jedes Paket von Transaktionsdaten zwei Taktzyklen lang ist, und Adressbus- und Datenbusarbitrierung auf dem Arbitrierungsbus (80) mit jedem Taktzyklus alternieren.
Das Verfahren nach Anspruch 13, wobei: das Computersystem Zwischenspeicherleitungen und einen Busebene-Markierungsspeicher (220) beinhaltet, der Zustandsinformation für jede der Zwischenspeicherleitungen speichert, wobei der Busebene-Markierungsspeicher (220) verwendet wird durch die Vorrichtungen (160-N) zum Abhören; jede Vorrichtung einen Vorrichtungsebene-Markierungsspeicher beinhaltet, der Zustandsinformation für jede der mit einer der Vorrichtungen verknüpften Zwischenspeicherleitungen speichert; und das geteilte Transaktionsbussystem ferner einen Mechanismus beinhaltet zum Vergleichen von Zustandsinformation in dem Busebene-Markierungsspeicher (220) und in dem Vorrichtungsebene-Markierungsspeicher zum Identifizieren einer Anforderung, die ein Kandidat zum Neuordnen ist.
Das Verfahren nach Anspruch 13 oder 14 oder 15, wobei die Vorrichtung (160-N) mindestens eine Eigenschaft hat, die aus einer Gruppe ausgewählt ist, bestehend aus (a) die Vorrichtung enthält eine Zentralprozessoreinheit, (b) die Vorrichtung enthält eine Eingabe-/Ausgabe-Vorrichtung, (c) die Vorrichtung ist auf einer Leiterplatte (50-N) implementiert, die eine Adresssteuereinheit (180) enthält mit einem Mechanismus, der Anforderungen zum Zugreifen auf den Adressbus arbitriert, (d) die Vorrichtung ist auf einer Leiterplatte (50-N) implementiert, die eine kohärente Eingangswarteschlange (182) enthält, in die alle kohärenten Transaktionen, die für die mit der Leiterplatte (50-N) verknüpften Vorrichtung (160-N) angefordert sind, vor Geltendmachung geladen werden, außer wenn das Computersystem ein Zeit-multiplexbares Ignorierungssignal geltend macht, wobei bei einer Nicht-Geltendmachung des Ignorierungssignals die Transaktion dann wieder ausgegeben wird, und außer wenn ein für die wiederausgegebene Transaktion relevantes Ignorierungssignal geltend gemacht ist, die wieder ausgegebene Transaktion in die kohärente Eingangswarteschlange geladen wird und auf dem geteilten Transaktionsbussystem als eine gültige Transaktion erscheinen wird, und (e) die Vorrichtung auf einer Leiterplatte (50-N) implementiert ist, die Speicher (220) enthält, und die Vorrichtung Transaktionsadressdaten und auf der Leiterplatte Speicher abhört zum Erkennen eines Besitz- oder Geteiltzustands.
Das Verfahren nach Anspruch 13, wobei das System ferner einen Daten-ID-Bus enthält, der eine Daten-ID mitführt, die auf eine Transaktionsanforderung reagierende Daten eindeutig identifiziert; wobei das Adressbuspaket für jede Transaktion eine Quellen-ID enthält, die die Leiterplatte (50-N) eindeutig identifiziert, die die Vorrichtung (160-N) enthält, die die Transaktion einleitete, und die Quellen-ID ferner die Transaktion eindeutig identifiziert; und wobei die Daten-ID und die Quellen-ID dem Bussystem ermöglichen, Pakete auf dem Datenbus (170) mit früher auf dem Adressbus (60) platzierten Paketen anzupassen.
Das Verfahren nach Anspruch 13, wobei: ein Einleiten der Vorrichtung (160-N) Daten abgeben kann; und wenn ein Erwidern der Vorrichtung (160-N) gegenwärtig die Daten nicht annehmen kann, ein Datenaufhebungssignal geltend gemacht wird, woraufhin die erwidernde Vorrichtung (160-N) Verantwortung zum Aufnehmen bzw. Holen der Daten annimmt.
Das Verfahren nach Anspruch 18, wobei: ein Erwidern der Vorrichtung (160-N) ferner Schreibtyp-Operationen verfolgt, die sie aufnehmen bzw. holen soll; und ein Einleiten der Vorrichtung (160-N) mit den Daten erwidert, wenn das Erwidern der Vorrichtung (160-N) ein angemessenes Daten-ID-Signal auf dem Datenbus (70) treibt, wobei die Daten dadurch aufgenommen bzw. geholt werden.
Das Verfahren nach Anspruch 13, wobei das geteilte Transaktionsbussystem ferner eine Warteschlange (184) enthält, in der geltend gemachte Anforderungen in der Warteschlange eingereiht werden, so dass Zustandstransaktionen auf dem Adressbus (60) atomar, logisch, ohne Abhängigkeit von einer Antwort darauf auftreten; wobei der geteilte Transaktionsbus ohne Blockieren einer Transaktionsanforderung funktioniert.
Das Verfahren nach Anspruch 13 oder 16, wobei das geteilte Transaktionsbussystem ferner einen Mechanismus enthält zum Übertragen eines Besitzes der identifizierten Speicherleitung zu der Vorrichtung in einem Paket auf dem Adressbus (60), wobei der Besitz übertragen wird, auch wenn mit der verknüpften Transaktion verknüpfte Daten bisher übertragen sind, wobei die Vorrichtung (160-N) mit dem Besitz verantwortlich ist für ein Erwidern auf eine nachfolgende Anforderung für die Speicherleitung.
Das Verfahren nach Anspruch 15 oder 16, wobei das geteilte Transaktionsbussystem ferner enthält: einen Mechanismus, der es ermöglicht, eine Transaktion in die kohärente Eingangswarteschlange zu laden, wenn eine Gleichheit eines Zustands in dem Busebene-Markierungsspeicher und in dem Vorrichtungsebene-Markierungsspeicher vorliegt, aber Verhindern eines solchen Ladens andernfalls; und eine Markierungspipelineumgehung, so dass Zustandstransaktionen auf dem Adressbus (60) atomar, logisch, ohne Abhängigkeit von einer Antwort darauf auftreten.
Das Verfahren nach Anspruch 19, wobei, wenn das Einleiten der Vorrichtung (160-N) ein Besitzsignal für eine Zurückschreibtransaktion geltend macht, eine Datenübertragung ohne Schreiben der Daten zu dem Speicher auftritt, und das Einleiten der Vorrichtung den Besitz einer angemessenen Speicherleitung abgibt, wenn ein Adressbuspaket für die Zurückschreibtransaktion ausgegeben wird.
Das Verfahren nach Anspruch 23, wobei die die Zurückschreibtransaktion ausgebende Vorrichtung (160-N) die Zurückschreibtransaktion aufhebt beim Auftreten mindestens eines Ereignisses, das aus einer Gruppe ausgewählt ist, bestehend aus (i) die mit der Vorrichtung (160-N) verknüpften Busebene-Markierungen zeigen an, dass die Vorrichtung (160-N) nicht der Besitzer ist, (ii) ein Besitztyp-Signal wird geltend gemacht, und (iii) ein Ignorierungssignal wird geltend gemacht.