DE69616402T2 - Schnelle Zweitor-Cachesteuerungsschaltung für Datenprozessoren in einem paketvermittelten cachekohärenten Multiprozessorsystem - Google Patents

Schnelle Zweitor-Cachesteuerungsschaltung für Datenprozessoren in einem paketvermittelten cachekohärenten Multiprozessorsystem

Info

Publication number
DE69616402T2
DE69616402T2 DE69616402T DE69616402T DE69616402T2 DE 69616402 T2 DE69616402 T2 DE 69616402T2 DE 69616402 T DE69616402 T DE 69616402T DE 69616402 T DE69616402 T DE 69616402T DE 69616402 T2 DE69616402 T2 DE 69616402T2
Authority
DE
Germany
Prior art keywords
cache
upa
data
port
system controller
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE69616402T
Other languages
English (en)
Other versions
DE69616402D1 (de
Inventor
Zahir Ebrahim
Satyanarayana Nishtala
Kevin Normoyle
William C. Van Loo
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sun Microsystems Inc
Original Assignee
Sun Microsystems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sun Microsystems Inc filed Critical Sun Microsystems Inc
Publication of DE69616402D1 publication Critical patent/DE69616402D1/de
Application granted granted Critical
Publication of DE69616402T2 publication Critical patent/DE69616402T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0815—Cache consistency protocols
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0804—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches with main memory updating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0815—Cache consistency protocols
    • G06F12/0817—Cache consistency protocols using directory methods
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0815—Cache consistency protocols
    • G06F12/0831—Cache consistency protocols using a bus scheme, e.g. with bus monitoring or watching means
    • G06F12/0833—Cache consistency protocols using a bus scheme, e.g. with bus monitoring or watching means in combination with broadcast means (e.g. for invalidation or updating)

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Static Random-Access Memory (AREA)

Description

  • Die vorliegende Erfindung bezieht sich allgemein auf Multiprozessor- Computersysteme, in denen die Prozessoren sich Speicherkapazitäten teilen, und im Besonderen auf ein Multiprozessor-Computersystem, das Cache-Interferenzen aufgrund cachekohärenter Transaktionen durch das Vorhandensein von Cache-Controllern für jeden Datenprozessor verringert, wobei die Cache-Controller in einem ersten Modus eine gewöhnliche Einsichtnahme in die Cache-Lines vornehmen und in einem zweiten Modus auf eine bestimmte Cache-Line zugreifen können, ohne die gesamte Adresse analysieren zu müssen.
    • Hintergrund der Erfindung
  • Die Notwendigkeit, "Cachekohärenz" in Multiprozessorsystemen zu erhalten, ist bekannt. "Cachekohärenz" zu erhalten bedeutet im Mindesten, daß jedesmal, wenn Daten von einem Prozessor in einen bestimmten Bereich eines gemeinsamen Adreßbereichs geschrieben werden, die Caches aller anderen Prozessoren, in denen Daten für denselben Adreßbereich gespeichert sind, entweder ungültig gemacht oder mit den neuen Daten überschrieben werden.
  • Es gibt zwei primäre Systemarchitekturen, die für die Erhaltung von Cachekohärenz genutzt werden. Die eine, hier als Cache-Snoop-Architektur bezeichnet, erfordert, daß die Caches aller Datenprozessoren jeweils eine Schaltung für das Überwachen eines gemeinsamen Adreßbusses sowie diverse Steuerleitungen beinhalten, um zu erkennen, wenn im gemeinsamen Speicher enthaltene Daten mit neuen Daten überschrieben werden, wobei festgestellt wird, ob im Cache des jeweiligen Datenprozessors in diesem Speicherbereich ein Eintrag verzeichnet ist und dessen Cache-Inhalt und/oder das entsprechende Cache-Tag aktualisiert werden, wenn im Cache gespeicherte Daten durch einen anderen Prozessor ungültig gemacht werden. In der Cache-Snoop-Architektur ist also jeder Datenprozessor dafür zuständig, seinen eigenen Cache in einem Zustand zu halten, der mit denen der anderen Caches übereinstimmt.
  • In einer zweiten Cachekohärenz-Architektur, hier als Memory-Directory-Port- Architektur bezeichnet, beinhaltet der Hauptspeicher für jeden Datenblock einen Satz Zustandsbits, die anzeigen, welche Datenprozessoren, wenn überhaupt, diesen Datenblock in ihrem Cache gespeichert haben. In den Zustandsbits des Hauptspeichers können zusätzliche Informationen gespeichert sein, wie z. B. darüber, welcher Prozessor als der "Besitzer" des Datenblocks gilt, wenn die Cachekohärenz-Architektur das Speichern solcher Informationen erfordert.
  • In der vorliegenden Erfindung gewährleistet ein System-Controller die Cachekohärenz zwischen den Cache-Speichern verschiedener Datenprozessoren, indem er einen Duplikatsatz der Cache-Tags speichert und anhand dieser Duplikate der Cache-Tags feststellt, welche Cache-Speicher Daten enthalten, die den jeweiligen von den Datenprozessoren durchgeführten Speichertransaktion entsprechen. Der System-Controller stellt fest, wann der Inhalt einer Cache-Line in einem Cache-Speicher ungültig gemacht werden muß, und wann eine Cache-Line in einem Cache-Speicher als Datenquelle für von einem anderen Datenprozessor angeforderte Daten dienen muß. Die Cache-Tag-Duplikat-Architektur eliminiert die Notwendigkeit der Busüberwachung durch die Datenprozessoren, ohne daß dabei die mit der Memory-Directory-Port-Architektur verbundenen Verzögerungen auftreten.
  • In Fig. 11 ist ein vereinfachtes Blockdiagramm einer bekannten Cache- Speichervorrichtung 400 aus dem Stand der Technik dargestellt, die an einen Datenprozessor 402 angeschlossen ist. Der Cache-Speicher beinhaltet ein Cache-Line-Array 404 und ein Cache-Tag-Array 406. Das Cache-Line-Array 404 beinhaltet 2CS Cache-Lines 410, wobei CS die Anzahl der für das eindeutige Identifizieren einer Cache-Line 410 nötigen Adreßbits ist. In jeder Cache-Line 410 ist ein Datenblock festgelegter Größe, z. B. 64 Bytes, gespeichert. Das Cache-Tag-Array 406 beinhaltet 2CS Cache-Tags 412.
  • Die Cache-Schaltung 414 steuert die Funktion des Cache-Speichers 400. Eine Komparatorschaltung 416 vergleicht einen Bereich der in einer Cache-Speicher-Anforderung angegebenen Adresse mit dem in einem ausgewählten Cache-Tag 412 gespeicherten Adreß- Tag und überprüft den in dem ausgewählten Cache-Tag enthaltenen Cache-Zustandswert, um festzustellen, ob das Adreß-Tag gültig ist.
  • Die Zustandsaktualisierungsschaltung 418 ist eine Schaltung für das Aktualisieren der Adresse und Information über den Cache-Zustand, die in dem Cache-Tag 412 gespeichert sind, das von der in einer Cache-Speicher-Anforderung angegebenen Adresse ausgewählt wird. Die Cache-Line-Zugriffs-/Aktualisierungs-Schaltung 420 ist eine Schaltung zum Lesen und Schreiben von Daten aus der bzw. in die Cache-Line 410, die von der in einer Cache- Speicher-Anforderung angegebenen Adresse ausgewählt wird.
  • Ein "Cache-Miss" ist definiert als das Unvermögen, einen bestimmten Datenblock in einem Cache-Speicher zu lokalisieren. Ist in einer Cache-Speicher-Anforderung die Adresse eines Datenblocks angegeben, der nicht im Cache-Speicher gespeichert ist, so spricht man vom Auftreten eines Cache-Miss.
  • Ein "Cache-Hit" ist definiert als das Lokalisieren eines bestimmten Datenblocks in einem Cache-Speicher. Ist in einer Cache-Speicher-Anforderung die Adresse eines Datenblocks angegeben, der im Cache-Speicher gespeichert ist, so wird die Speicher- Anforderung vom Cache-Speicher bearbeitet, und man spricht vom Auftreten eines Cache- Hit.
  • Da die vorliegende Erfindung ein System und Verfahren beinhaltet, die beim Auftreten eines Cache-Hit Cache-Speicheroperationen um einen oder zwei Taktzyklen beschleunigen, ist die Schaltung für die Reaktion auf einen Cache-Miss durch das Weiterleiten der Speicherzugriffs-Anforderung an eine andere Speichervorrichtung, wie z. B. einen großen Cache-Speicher oder den Hauptspeicher des Systems, in Fig. 11 nicht dargestellt.
  • Eine Cache-Speicherzugriffsoperation in einem Standard Cache-Speicher 400 aus dem Stand der Technik wie dem in Fig. 11 gezeigten beginnt, ungeachtet dessen, ob es sich um eine Lese- oder Schreiboperation handelt, folgendermaßen. Dem Cache-Speicher 400 werden von einem Datenprozessor 402 oder einer anderen Vorrichtung ein Adreßwert und ein Befehlssignal übermittelt. Der Adreßwert enthält eine Sequenz von Adreßbits, die hier in drei Gruppen unterteilt werden: {A}, {B} und {C}. Der volle Adreßwert, der dem Cache-Speicher übermittelt wird, wird als {A B C} dargestellt, wobei {A} die signifikantesten Adreßbits repräsentiert, {B} einen Satz Adreßbits mittlerer Signifikanz, und {C} einen Satz am wenigstens signifikanter Adreßbits repräsentiert.
  • Die Merkmale des Oberbegriffs von Anspruch 1 sind in "A Second Level Cache Controller for a Super-Scolar Sparc Processor", Compcon 92, San Francisco, 24. - 28. Februar 1992, no. contr. 37, S. 142-151 dargestellt.
  • Als Beispiel sei angenommen, daß ein System einen 41-Bit-Adreßwert PA< 40 : 0> nutzt, wobei PA für "physikalische Adresse" steht, und wobei jeder einzelne Adreßwert ein bestimmtes Byte im Hauptspeicher des Systems darstellt. Beinhaltet dieses System einen Datenprozessor mit einem Cache-Speicher 400, der eine Cache-Line der Größe 64 Byte und einen Cache-Speicher der Größe 512 KByte hat, dann stellt {A} die 21 signifikantesten Adreßbits PA< 40 : 19> , {B} die 13 Adreßbits mittlerer Signifikanz PA< 18 : 6> und {C} die 6 am wenigsten signifikanten Adreßbits PA< 5 : 0> dar.
  • Der Cache-Speicher 400 in diesem Beispiel hat 213 Cache-Lines 410 und 2¹³ entsprechende Cache-Tags 412. In jedem Cache-Tag 412 ist ein Cache-Line Zustandswert und ein Adreß-Tag gespeichert. Der Cache-Line Zustandswert zeigt an, ob die entsprechende Cache-Line gültige Daten enthält, und ob der in der entsprechenden Cache-Line 410 gespeicherte Datenblock ausschließlich in diesem Cache-Speicher gespeichert ist oder mit wenigstens einem anderen Cache-Speicher geteilt wird. Der Cache-Zustandswert zeigt auch an, ob die entsprechende Cache-Line modifizierte Daten enthält, die in den Hauptspeicher zurückgeschrieben werden müssen, wenn der in der Cache-Line 410 gespeicherte Datenblock aus dem Cache-Speicher entfernt wird. Das Adreß-Tag im Cache-Tag 412 enthält die {A}- Adreßbits PA< 40 : 19> , die neben der Position des Cache-Tag im Cache-Tag-Array 406 den Basisort des Datenblocks im Hauptspeicher eindeutig identifizieren.
  • In einem gewöhnlichen Cache-Speicher beginnt jede Cache-Speicheroperation mit den {B}-Adreßbits, durch die ein entsprechendes aus 2B Cache-Tags im Cache-Tag-Array ausgewählt und auf dieses zugegriffen und die entsprechende Cache-Line 410 im Cache-Line- Array angesteuert wird. Eine Komparatorschaltung vergleicht das Adreß-Tag in dem Cache- Tag, auf das zugegriffen wurde, mit den {A}-Adreßbits und den Cache-Line-Zustandswert mit einem Cache-Zustandswert, der als "ungültig" definiert ist. Stimmt das Adreß-Tag mit den {A}-Adreßbits überein und der Cache-Zustandswert ist nicht ungültig, dann handelt es sich um einen Cache-Hit. Ein Cache-Hit/Miss-Signal wird an die Zustandsaktualisierungsschaltung 418 und die Cache-Line-Zugriffs-/Aktualisierungsschaltung 420 übertragen, so daß diese Schaltungen die anstehende Cache-Speicheranforderung entsprechend verarbeiten können.
  • Bei zum Beispiel einer Leseanforderung (auch als Ladeanforderung bekannt) kann bei Auftreten eines Cache-Miss die Anforderung nicht abgearbeitet werden, weshalb diese an eine andere, größere Speichervorrichtung weitergeleitet wird, während bei Auftreten eines Cache-Hit die Leseanforderung abgearbeitet wird. Bei einer Schreibanforderung wird bei Auftreten eines Cache-Hit die Schreibtransaktion abgearbeitet, indem Daten in die ausgewählte Cache-Line 410 geschrieben und der im entsprechenden Cache-Tag 412 gespeicherte Zustandswert, wenn nötig, aktualisiert wird, um anzuzeigen, daß in der Cache- Line 412 modifizierte Daten gespeichert sind.
  • Tritt beim Abarbeiten einer Schreibanforderung ein Cache-Miss auf, und ist das entsprechende Cache-Tag 412 ungültig, dann können Daten in die entsprechende Cache-Line 410 geschrieben und im Cache-Tag ein neuer Zustandswert gespeichert werden. Tritt jedoch für eine Schreibanforderung ein Cache-Miss auf, und der im entsprechenden Cache-Tag 412 gespeicherte Zustandswert zeigt an, daß die Cache-Line sowohl gültig als auch modifiziert ist, dann wird der gegenwärtig in der Cache-Line gespeicherte Datenblock entfernt und muß in den Hauptspeicher zurückgeschrieben werden.
  • Die Schritte "Cache-Tag-Einsicht" und "Vergleichen" nehmen üblicherweise einen oder zwei Taktzyklen des Datenprozessors in Anspruch, in Abhängigkeit von der konkreten Gestaltung der Cacheschaltung 414. Wird die Cache-Zugriffsanforderung auf den Cache- Speicher 400 durch den Datenprozessor 402 initiiert, dann sind die Schritte "Cache-Tag- Einsicht" und "Vergleichen" notwendig. Ein Zugriff auf den Cache-Speicher durch den Datenprozessor 402 ist erheblich schneller als ein Zugriff auf den Hauptspeicher, selbst mit den Verzögerungen, die durch die Schritte "Cache-Tag-Einsicht" und "Vergleichen" verursacht werden.
  • Wird jedoch eine Cache-Speicherzugriffsanforderung auf den Cache 414 von einer anderen Datenprozessorvorrichtung initiiert, so entstehen mehrere zusätzliche Verzögerungen, durch die die Speicherzugriffszeit weit näher an der Zugriffszeit auf den Hauptspeicher liegt, als an der üblichen Zugriffszeit auf einen Cache-Speicher. Die vorliegende Erfindung stellt eine Zweitor-Cachesteuerungsschaltung dar, die die Zugriffszeit auf einen entfernt gelegenen Cache-Speicher um einen oder zwei Taktzyklen verringert, indem das Vergleichen der Cache-Tags beim Zugreifen auf den Cache-Speicher eliminiert wird, sofern durch die entfernt gelegene zugreifende Vorrichtung gewährleistet ist, daß der durch die Transaktion angeforderte Datenblock gegenwärtig im Cache-Speicher gespeichert ist. Kann die entfernt gelegene zugreifende Vorrichtung dies nicht gewährleisten, so verwendet der Cache-Controller das Standard-Zugriffsverfahren auf den Cache-Speicher. Die entfernt gelegene zugreifende Vorrichtung zeigt an, ob diese Gewährleistung besteht, indem sie bei jeder Cache-Speicher-Zugriffsanforderung ein bestimmtes Cache-Zugriffs- Betriebsarten-Flag setzt.
    • Zusammenfassung der Erfindung
  • Die Erfindung ist in Anspruch 1 definiert.
  • Zusammenfassend handelt es sich bei der vorliegenden Erfindung um ein Multiprozessor-Computersystem mit mehreren Subsystemen und einem an einen System- Controller gekoppelten Hauptspeicher. Ein Verbindungsmodul stellt entsprechend den vom System-Controller empfangenen Verbindungs-Steuersignalen eine Verbindung zwischen Hauptspeicher und Subsystemen her.
  • Mindestens zwei der Subsysteme sind Datenprozessoren, von denen jeder einen entsprechenden Cache-Speicher hat, in dem verschiedene Datenblocks sowie ein Satz Master- Cache-Tags (Etags) gespeichert sind, einschließlich eines Cache-Tags für jeden im Cache- Speicher gespeicherten Datenblock.
  • Jeder Datenprozessor hat ein Master-Interface, um Speichertransaktionsanforderungen an den System-Controller zu versenden, und um vom System-Controller den Speicher- Transaktionsanforderungen anderer Datenprozessoren entsprechende Cachezugriffsanforderungen zu empfangen.
  • Der System-Controller hat ein entsprechendes an jeden Datenprozessor gekoppeltes Interface zum Empfangen und Versenden von Speicherzugriffsanforderungen von den und an die entsprechenden Datenprozessoren.
  • Die Cache-Speicher aller Datenprozessoren haben eine Zweitor-Cachesteuerungsschaltung zum Empfangen von Zugriffsanforderungen. Ein erster Port empfängt Zugriffsanforderungen vom entsprechenden Datenprozessor, und ein zweiter Port empfängt Zugriffsanforderungen vom System-Controller. Alle Zugriffsanforderungen an den Cache- Speicher beinhalten einen Adreßwert, während Zugriffsanforderungen vom System- Controller auch ein Betriebsarten-Flag beinhalten.
  • Ein Komparator im Cache-Controller verarbeitet den in jeder Zugriffsanforderung enthaltenen Adreßwert und generiert ein Hit/Miss-Signal, das anzeigt, ob der dem Adreßwert entsprechende Datenblock im Cache-Speicher gespeichert ist.
  • Der Cache-Controller beinhaltet ferner eine Zugriffsschaltung mit zwei Betriebsarten, einschließlich einer ersten Standard-Betriebsart, in der dem Schreib-/Lesezugriff auf den Cache-Speicher das Generieren des Hit/Miss-Signal durch den Komparator in Reaktion auf den Adreßwert der Zugriffsanforderung vorangeht, und einer zweiten beschleunigten Betriebsart, in der der Schreib-/Lesezugriff auf den Cache-Speicher initiiert wird, ohne daß darauf gewartet werden muß, daß der Komparator den Adreßwert der Zugriffsanforderung verarbeitet. Die Zugriffsschaltung verarbeitet in der ersten Betriebsart alle Zugriffsanforderungen des an den Cache-Speicher gekoppelten Datenprozessors sowie Zugriffsanforderungen des System-Controllers, wenn das Betriebsarten-Flag einen ersten Wert hat. In der zweiten Betriebsart verarbeitet es Zugriffsanforderungen des System- Controllers, wenn das Betriebsarten-Flag einen zweiten Wert hat, der sich vom ersten Wert unterscheidet.
    • Kurzbeschreibung der Figuren
  • Weitere Gegenstände und Merkmale der Erfindung gehen in Verbindung mit den Figuren aus der nachfolgenden ausführlichen Beschreibung und den Ansprüchen hervor. Die Figuren zeigen:
  • Fig. 1 ein Blockschaltbild eines Computersystems, das die vorliegende Erfindung beinhaltet,
  • Fig. 2 ein Blockschaltbild eines Computersystems mit der Adreßbus- und Datenbuskonfiguration einer Ausführung der Erfindung,
  • Fig. 3 die Signalleitungen eines Ports gemäß einer bevorzugten Ausführung der Erfindung,
  • Fig. 4 ein Blockschaltbild der Schnittstellen und Port-ID-Register in einem Port gemäß einer bevorzugten Ausführung der Erfindung,
  • Fig. 5 ein Blockschaltbild eines Computersystems, das die vorliegende Erfindung beinhaltet, in dem die Anforderungs- und Datenwarteschlangen während einer Datentransferaktion dargestellt sind,
  • Fig. 6 ein Blockschaltbild des System-Controller-Konfigurationsregisters in einer bevorzugten Ausführung der vorliegenden Erfindung,
  • Fig. 7 ein Blockschaltbild eines cachenden UPA-Master-Ports und des Cache- Controllers im entsprechenden UPA-Modul,
  • Fig. 8 einen vereinfachten Ablaufplan typischer Schreib-/Lese-Datenflußtransaktionen in einer bevorzugten Ausführung der vorliegenden Erfindung,
  • Fig. 9 den Rückschreibe-Puffer und die temporären Dtag-Puffer für das abwickeln kohärenter Cache-Rückschreibe-Operationen,
  • Fig. 10 das Datenpaketformat für ein Anforderungspaket für eine kohärente Speichertransaktion,
  • Fig. 11 ein Blockschaltbild für einen standardgemäßen Cache-Speicher aus dem Stand der Technik und einen Cache-Speicher-Controller,
  • Fig. 12 ein Blockschaltbild eines Multiprozessorsystems, in dem die Datenprozessoren den Cache-Speicher-Controller der vorliegenden Erfindung beinhalten.
    • Beschreibung der bevorzugten Ausführungsform Terminologieverzeichnis:
  • Cachekohärenz: Aufrechterhaltung der Übereinstimmung sämtlicher Kopien aller Datenblöcke.
  • Tag: Ein Tag ist eine Aufzeichnung in einem Cache-Index, die den Zustand einer Cache-Line anzeigt und in der die höherwertigen Adreßbits der Adresse des in der Cache-Line gespeicherten Datenblocks gespeichert sind.
  • Etag: Primäranordnung von Cache-Tags für einen Cache-Speicher. Das Datenprozessormodul in einem UPA-Port greift auf die Etag- Anordnung zu und aktualisiert diese.
  • Dtag: Im System-Controller abgelegte Kopie der Cache-Tag-Anordnung.
  • Interconnect: Anordnung von Systemkomponenten, die Datenprozessoren, Ein- (Verbindungsmodul)Ausgabe-Prozessoren und deren Ports miteinander verbinden. In der bevorzugten Ausführung der Erfindung beinhaltet das "Interconnect" den System-Controller 110, das Verbindungsmodul 112, die Datenbusse 116, die Adreßbusse 114 und die Antwortbusse 120 (für S_REPLYs) und 122 (für P-REPLYs).
  • Victim: Aus einer Cache-Line entfernter Datenblock.
  • Dirty Victim: Datenblock, der vom entsprechenden Datenprozessor aktualisiert wurde, bevor er im Cache durch einen anderen Datenblock entfernt wurde. Dirty Victims müssen für gewöhnlich in den Hauptspeicher zurückgeschrieben werden, in der vorliegenden Erfindung kann jedoch auf das Zurückschreiben verzichtet werden, wenn der selbe Datenblock vor Aktivierung der Rückschreibe-Transaktion von einem anderen Datenprozessor ungültig gemacht wird.
  • Line: Speichereinheit in einem Cache-Speicher, in der ein einzelner Datenblock gespeichert ist.
  • Ungültig machen: (Invalidierung) Verändern des Zustands einer Cache-Line zu "ungültig" durch Schreiben des entsprechenden Zustandswerts in das Tag der Cache- Line.
  • Master-Klasse: Unabhängige Anforderungs-Warteschlange im UPA-Port für einen Datenprozessor. Ein Datenprozessor mit einem UPA-Port mit K Master-Klassen kann in jeder der K Master-Klassen Transaktionsanforderungen ausgeben. Jede Master-Klasse hat ihren eigenen Anforderungs-FIFO-Puffer für die Ausgabe von Transaktionsanforderungen an den System-Controller sowie ihren eigenen individuellen Eingangsdatenpuffer für ankommende Datenpakete als Rückmeldung auf Transaktionsanforderungen und ihren eigenen Ausgangsdatenpuffer für das Speichern von zu übertragenden Datenpaketen.
  • Zurückschreiben: (Writeback) Kopieren modifizierter Daten von einem Cache-Speicher in den Hauptspeicher.
    • Abkürzungsverzeichnis:
  • DVMA: Direct virtual memory access (wie DMA, hier direkter Speicherzugriff)
  • DVP: Dirty Victim pending
  • I/O: Ein-/Ausgabe
  • IVP: Empfehlung zum Ungültigmachen
  • MOESI: die 5 Etag-Zustände: exclusive modified (M), shared modified (O), exclusive clean (E), shared clean (S), invalid (I)
  • MOSI: die 4 Dtag-Zustände: exclusive and potentially modified (M), shared modified (O), shared clean (S), invalid (I)
  • NDP: kein Daten-Tag vorhanden
  • PA[xxx]: physikalische Adresse [xxx]
  • SC: System-Controller
  • UPA: Universelle Port-Architektur
  • In Fig. 1 ist ein Multiprozessor-Computersystem 100 dargestellt, in dem die Computerarchitektur der vorliegenden Erfindung verwirklicht ist. Das Multiprozessor- Computersystem 100 beinhaltet eine Anordnung von "UPA-Modulen". Die UPA-Module 102 beinhalten Datenprozessoren und Slave-Vorrichtungen wie Ein-/Ausgabeelemente und ähnliches. Jedes UPA-Modul 102 hat einen Port 104, hier UPA-Port genannt, wobei "UPA" "universelle Port-Architektur" bedeutet. Zur Vereinfachung werden UPA-Module und ihre entsprechenden Ports häufig mit dem Sammelbegriff "Ports" oder "UPA-Ports" bezeichnet, wobei davon ausgegangen wird, daß der betreffende Port oder UPA-Port sowohl einen Port als auch das entsprechende UPA-Modul beinhaltet.
  • Das System 100 enthält weiter einen Hauptspeicher 108, der in mehrere Speicherbanken 109 Bank&sub0; bis Bankm unterteilt werden kann, einen System-Controller 110 und ein Verbindungsmodul 112 für die Verbindung zwischen den Ports 104 und dem Hauptspeicher 108. Das Verbindungsmodul 112 kann, gesteuert vom Datenweg-Installationssignal des System-Controllers 110, einen Datenweg zwischen einem beliebigen Port 104 und jedem beliebigen anderen Port 104 bilden, oder zwischen einem beliebigen Port 104 und jeder beliebigen Speicherbank 109. Das Verbindungsmodul 112 kann einfach ein einzelner gemeinsamer Datenbus mit ansteuerbaren Zugriffsports für jeden UPA-Port und einem Speichermodul sein, oder es kann ein etwas komplexerer Kreuzschienenschalter mit m Ports für m Speicherbanken und n Ports für n UPA-Ports sein, oder eine Kombination aus beiden. Die vorliegende Erfindung ist nicht von der Art des verwendeten Verbindungsmoduls 112 abhängig, somit kann die vorliegende Erfindung mit vielen verschiedenen Verbindungsmodul-Konfigurationen angewendet werden.
  • Ein UPA-Port 104 ist mit dem Verbindungsmodul 112 und dem System-Controller 110 durch einen paketvermittelten Adreßbus 114 bzw. einen paketvermittelten Datenbus 116 verbunden, die beide unabhängig voneinander funktionieren. Ein UPA-Modul koppelt sich logisch an einen UPA-Port an. Das UPA-Modul 102 kann einen Datenprozessor, einen Ein- /Ausgabecontroller mit Schnittstellen zu Ein-/Ausgabebussen oder einen Bildspeicher-Puffer enthalten. Die UPA-Verbindungsarchitektur der bevorzugten Ausführung unterstütz bis zu 32 UPA-Ports sowie mehrere Adreß- und Datenbusse zur Verbindung. Bis zu 4 UPA-Ports 104 können den selben Adreßbus 114 teilen, wobei der Zugang durch ein Buszuteilungsprotokoll geregelt wird.
  • Der System-Controller 110 ist eine zentrale Steuerschaltung, die folgende Funktionen ausübt:
  • - Kohärenzkontrolle;
  • - Steuerung von Speicher und Datenweg; und
  • - Ansteuern der riegelartigen Konnektivität für mehrere Adreßbusse.
  • Der System-Controller 110 steuert das Verbindungsmodul 112 und koordiniert den Datentransfer zwischen zwei UPA-Ports 104 oder zwischen einem UPA-Port 104 und dem Speicher 108. Die Architektur der vorliegenden Erfindung unterstützt eine beliebige Anzahl von Speicherbanken 109. Der System-Controller 110 steuert die zeitliche Koordination des Speicherzugriffs in Verbindung mit der Datenwegvergabe, um eine maximale Nutzung beider Ressourcen zu gewährleisten.
  • Der System-Controller 110, das Verbindungsmodul 112 und der Speicher 108 befinden sich in der "Verbindungs-Domäne" und sind durch ihre entsprechenden UPA-Ports 104 an UPA-Module 102 gekoppelt. Die Verbindungs-Domäne ist völlig synchron mit einem zentral verteilten Systemtaktsignal, das von einem Systemtaktgeber 118 generiert und auch an die UPA-Module 104 ausgegeben wird. Wenn dies gewünscht ist kann jedes UPA-Modul 102 seinen eigenen internen Taktgeber mit dem Verbindungstaktgeber des Systems synchronisieren. Wenn nicht anders angegeben wird, wenn in dieser Schrift von "Taktsignalen" die Rede ist, auf den Systemtaktgeber Bezug genommen.
  • Jeder UPA-Adreßbus 114 ist ein 36-Bit bidirektionaler paketvermittelter Anforderungsbus mit 1-Bit ungerader Parität. Er überträgt die Adreßbits PA[40 : 4] mit einem 41-Bit physikalischen Adreßraum sowie die Transaktions-Identifikations-Information.
  • Wie in Fig. 1 und 2 gezeigt kann es in dem System mehrere Adreßbusse 114 geben, mit bis zu 4 UPA-Ports 104 auf jedem Adreßbus 114. Die genaue Anzahl der Adreßbusse variiert und ist generell von den Geschwindigkeitsanforderungen des Systems abhängig. Da das Erhöhen der Anzahl der Ports auf einem Adreßbus 114 die Signalübertragung über diesen Adreßbus verlangsamt, wird die maximale Anzahl der Ports je Adreßbus durch die für den Adreßbus erforderliche Geschwindigkeit der Signalübertragung bestimmt.
  • Die Datenwegschaltung (d. h. das Verbindungsmodul 112) und die Adreßbusse 114 sind (voneinander) unabhängig skalierbar. Dadurch ist es möglich, die Anzahl der Adreßbusse für eine bestimmte Anzahl von Prozessoren zu erhöhen oder zu verringern und dadurch die Geschwindigkeits-/Kosten-Abstimmung der Übertragung von Transaktionsanforderungen über die Adreßbusse zu optimieren, und zwar vollkommen unabhängig von Entscheidungen bezüglich der Geschwindigkeits-/Kosten-Abstimmung bezüglich der Konstruktion des Verbindungsmoduls 112.
  • In Fig. 3 ist die Gesamtheit der Signale dargestellt, die von einem UPA-Port mit allen vier Schnittstellen (siehe unten) gemäß der bevorzugten Ausführung der Erfindung empfangen und gesendet werden. Tabelle 1 ist eine Kurzbeschreibung jedes der in Fig. 3 dargestellten Signale.
    • Tabelle 1 Definition der UPA-Port-Schnittstellensignale Signal Beschreibung Datenbussignale
  • UPA_Databus[128] 128-Bit Datenbus. In Abhängigkeit von der erforderlichen Geschwindigkeit und der verwendeten Bustechnologie kann ein System einen 128-Bit Datenbus für jeden UPA-Port haben, oder jeder Datenbus kann von mehreren Ports genutzt werden.
  • UPA_ECC[16] Bus zum Übertragen von Fehlerkorrekturcodes (Error Correction Code). UPA ECC< 15 : 8> überträgt den ECC für UPA Databus< 127 : 64> . UPA ECC< 7 : 0> überträgt den ECC für UPA Databus< 63 : 0> .
  • UPA_ECC_Valid ECC gültig. Einseitig gerichtetes Signal vom System- Controller an jeden UPA-Port, wird vom System- Controller ausgegeben um anzuzeigen, ob der ECC für die Daten auf dem Datenbus gültig ist.
    • Adreßbussignale
  • UPA_Addressbus[36] 36-Bit paketvermittelter Transaktionsanforderungsbus. Siehe Paketformat in Fig. 9A, 9B und 9C.
  • UPA_Req_In[3] Buszuteilungsanforderungsleitungen für bis zu 3 weitere UPA-Ports, die evtl. diesen UPA Addressbus teilen.
  • UPA_Req_Out Buszuteilungsanforderung von diesem UPA-Port.
  • UPA_SC_Req_In Buszuteilungsanforderung vom System-Controller.
  • UPA_Arb_Reset_L Rücksetzen der Buszuteilung, wird gleichzeitig mit
  • UPA_Reset_L ausgegeben.
  • UPA_AddrValid Zwischen dem System-Controller und jedem UPA-Port gibt es eine separate, bidirektionale Leitung für das Signal "Adresse gültig". Angesteuert wird sie von dem Port, der die Buszuteilung erhält, oder vom System- Controller, wenn dieser den Adreßbus ansteuert.
  • UPA_Data_Stall Datenstausignal, wird vom System-Controller an jeden UPA-Port ausgegeben um während der Übertragung eines Datenpakets anzuzeigen, ob es zwischen den Quad- Wörtern eines Datenpakets einen Datenstau gibt.
    • Antwortsignale
  • UPA_P_Reply[5] Antwortpaket des Ports, wird von einem UPA-Port direkt an den System-Controller ausgegeben. Jedem UPA-Port ist ein UPA_P_Reply-Bus zugewiesen.
  • UPA_S_Reply[6] Antwortpaket des System-Controllers, wird vom System- Controller direkt an den UPA-Port ausgegeben. Jedem UPA-Port ist ein UPA_S_Reply-Bus zugewiesen.
    • Diverse Signale
  • UPA_PortID[5] Identifikationssignal des festverdrahteten 5-Bit-UPA-Ports.
  • UPA_Reset_L Rücksetzen. Wird vom System-Controller nach dem Einschalten sowie bei jedem schwerwiegenden Rücksetzen des Systems ausgegeben.
  • UPA_Sys_Clk[2] Differentialer UPA-Systemtakt, wird vom Systemtaktgeber an alle UPA-Ports ausgegeben.
  • UPA_CPU_Clk[2] Differentialer Prozessortakt, wird von der Systemtaktsteuerung nur an die UPA-Ports von Prozessoren ausgegeben.
  • UPA_Speed[3] Nur für die UPA-Ports der Prozessoren, in diesem festverdrahteten 3-Bit Signal ist die maximale Geschwindigkeit, mit der der UPA-Port fungieren kann, kodiert.
  • UPA_IO_Speed Wird nur von den Ein-/Ausgabe-UPA-Ports verwendet, in diesem Signal ist die maximale Geschwindigkeit, mit der der UPA-Port fungieren kann, kodiert.
  • UPA_Ratio Nur für die UPA-Ports der Prozessoren, in diesem Signal ist das Verhältnis des Systemtakts zum Prozessortakt kodiert, es wird vom Prozessor genutzt, um bei Verwendung synchroner interner Schnittstellen Systemtakt und Prozessortakt intern zu synchronisieren.
  • UPA_JTAG[5] JTAG-Abtaststeuersignale, TDI, TMS, TCLK, TRST L und TDO. TDO wird vom UPA-Port ausgegeben, die anderen sind Eingangssignale.
  • UPA_Slave_Int_L Interrupt, für UPA-Ports, die nur als Slave fungieren. Diese Leitung geht vom UPA-Port an den System-Controller.
  • UPA_XIR_L XIR-Rücksetzsignal, wird vom System-Controller ausgegeben, um ein XIR-Rücksetzen zu signalisieren.
  • Ein gültiges Paket auf dem UPA-Adreßbus 114 wird vom Absender (d. h. dem UPA- Port 104 oder dem System-Controller 110) identifiziert, indem er das Signal UPA_Addr_valid ausgibt.
  • Der System-Controller 110 ist mit jedem UPA-Adreßbus 114 im System 100 verbunden. Alle UPA-Adreßbusse 114 werden den UPA-Ports 104 und dem System- Controller 110 über ein Buszuteilungsprotokoll zugewiesen.
  • UPA-Ports kommunizieren nicht direkt mit anderen UPA-Ports über einen gemeinsamen Adreßbus 114. Stattdessen wird, wenn ein anfordernder UPA-Port ein Anforderungspaket generiert und damit den Zugriff auf einen angesteuerten UPA-Port anfragt, vom System-Controller 110 ein Slave-Zugriff auf den angeforderten UPA-Port gewährt, indem das Anforderungspaket zurückgeschickt und der Ziel-UPA-Port durch das Signal UPA-Addr_valid markiert wird.
  • Ferner wird der UPA-Adreßbus nicht von einem UPA-Port "abgehört", um die Cachekohärenz aufrechtzuerhalten. Der System-Controller 110 hört den UPA-Adreßbus für die UPA-Ports ab, deren UPA-Module einen Cache-Speicher beinhalten, der ein Schreib- Invalidierungs-Cachekohärenzprotokoll wie unten beschrieben verwendet.
  • Die mit einem UPA-Port 104 verbundenen UPA-Adreßbusse 114 und UPA- Datenbusse 116 sind voneinander unabhängig. Eine Adresse wird mit ihren Daten nach den unten beschriebenen Regeln assoziiert.
  • Der UPA-Datenbus ist ein bidirektionaler 128-Bit Quad-Wort Datenbus, plus 16 zusätzlicher EEC- (Fehlerkorrekturcode-) Bits. Ein "Wort" ist hier definiert als eine 32-Bit, 4- Byte Dateneinheit. Ein Quad-Wort besteht aus 4 Wörtern oder 16 Bytes. In manchen Ausführungen können alle oder manche der Datenbusse 116 im System 100 bidirektionale 64- Bit 2-Wort bidirektionale Datenbusse sein, plus 8 Zusatzbits für den Fehlerkorrekturcode. Die ECC-Bits werden für den 128-Bit breiten Datenbus in zwei 8-Bit Hälften unterteilt. Obwohl der 64-Bit breite UPA-Datenbus halb so viele Signalleitungen hat, kann er die gleiche Anzahl von Bytes pro Transaktion übertragen wie der 128-Bit breite UPA-Datenbus, jedoch in der doppelten Anzahl von Taktzyklen. In der bevorzugten Ausführung ist die kleinste Einheit der kohärenten Datenübertragung 64 Byte, wobei vier Übertragungen zu 16 Bytes während 4 aufeinanderfolgender System-Taktzyklen über den 128-Bit UPA-Datenbus erforderlich sind.
  • Ein als "Master" fungierender UPA-Port, auch UPA-Master-Port genannt, ist hier definiert als ein Port, der eine Datenübertragungstransaktion initiieren kann. Alle UPA- Module von Datenprozessoren müssen einen als Master fungierendes UPA-Port 104 haben.
  • Es ist zu beachten, daß Grafikvorrichtungen, die über manche Fähigkeiten von Datenprozessoren verfügen können, üblicherweise nur eine Slave-Schnittstelle haben. Slave- Schnittstellen sind nachfolgend beschrieben. In dieser Schrift ist ein "Datenprozessor" definiert als programmierbarer Computer oder programmierbare Datenverarbeitungsvorrichtung (z. B. ein Mikroprozessor), der/die Daten sowohl von einem Hauptspeicher lesen als auch in einen Hauptspeicher schreiben kann. Ein "Datenprozessor" ist meistens, aber nicht immer, mit einem Cache-Speicher verbunden. Ein Ein-/Ausgabe-Controller ist zum Beispiel ein Datenprozessor, und sein UPA-Port ist ein Master-UPA-Port. Oft ist es jedoch so, daß ein Ein-/Ausgabe-Controller keinen Cache-Speicher hat (oder zumindest keinen Cache-Speicher, der Daten im kohärenten Bereich speichern kann).
  • Ein cachender UPA-Master-Port ist ein Master-UPA-Port für einen Datenprozessor, der ebenfalls einen kohärenten Cache hat. Der cachende UPA-Master-Port ist am Cachekohärenzprotokoll beteiligt.
  • Ein "Slave"-UPA-Port ist hier definiert als unfähig, Datentransfer-Transaktionen zu initiieren, sondern bei solchen Transaktionen als Empfänger zu fungieren. Ein Slave-Port reagiert auf Anforderungen des System-Controllers. Der einem Slave-Ports zugeordnete Adreßraum ist für programmierte Ein-/Ausgabeoperationen vorgesehen. Ein "Slave-Port" in einem Master-UPA-Port (d. h. eine Slave-Schnittstelle in einem Master-UPA-Port) wickelt auch Rückkopier-Anforderungen für Cache-Blöcke sowie Interrupt-Transaktionen im UPA- Port eines Datenprozessors ab.
  • Jede 8-Bit-Gruppe des ECC überträgt den Shigeo Kaneda 64-Bit SEC-DED-S4ED Code. Das Interconnect generiert weder den ECC, noch überprüft es ihn. Jeder Daten ausgebende UPA-Port generiert die entsprechenden ECC-Bits, und der die Daten empfangende UPA-Port überprüft die ECC-Bits. UPA-Ports mit der Fähigkeit, als Master zu fungieren, unterstützen den ECC. Nur als Slave fungierende UPA-Ports mit einem Bildspeicher-Puffer müssen den ECC nicht unterstützen (siehe UPA_ECC_Valid - Signal).
  • Der UPA-Datenbus 116 ist kein modulübergreifend genutzter gemeinsamer Datenbus. Wie in Fig. 1 und 2 dargestellt kann das System mehr als einen UPA-Datenbus 116 enthalten, die genaue Anzahl hängt von der konkreten Ausführung ab. Daten werden auf dem 128-Bit breiten UPA-Datenbus immer in Einheiten von 16 Byte pro Taktzyklus übertragen, und auf dem 64-Bit breiten UPA-Datenbus in Einheiten von 16 Byte pro zwei Taktzyklen.
  • Die Größe jeder Cache-Line beträgt in der bevorzugten Ausführung 64 Byte, oder sechzehn 32-Bit-Wörter. Wie im folgenden noch erläutert werden wird ist 64 Byte die kleinste Datenübertragungs-Einheit für alle Transaktionen, die mit dem Übertragen von gecachten Daten zusammenhängen. Daraus folgt, daß jedes Datenpaket aus gecachten Daten, das über das Interconnect übertragen wird, aus 64 Bytes besteht. Bei der Übertragung nicht gecachter Daten können 1 bis 16 Byte in einem einzelnen Quad-Wort übertragen werden, gekennzeichnet durch eine 16-Bit Bytemaske, die anzeigt, welche Bytes im Quad-Wort die zu übertragenden Daten enthalten.
  • Der System-Controller 110 teilt durch ein Signal, das hier S_REPLY heißt, eine Datenübertragung auf einem UPA-Datenbus 116 zu. Für die Übertragung von Blöcken wird, falls aufeinanderfolgende Quad-Wörter nicht in aufeinanderfolgenden Taktzyklen aus dem Speicher gelesen oder in diesen geschrieben werden können, das Signal UPA_Data_Stall vom System-Controller 110 an den UPA-Port ausgegeben.
  • Für kohärente Blocklese- und Rückkopier-Transaktionen von 64-Byte Datenblöcken wird das Quad-Wort (16 Bytes), das die physikalischen Adreßbits PA[5 : 4] trägt, zuerst abgeschickt, und die nachfolgenden Quad-Wörter werden in der in Tabelle 2 dargestellten Reihenfolge übertragen. Das die Adresse tragende Quad-Wort wird zuerst übertragen, so daß der anfordernde Datenprozessor das die Adresse tragende Quad-Wort empfangen und mit dessen Verarbeitung beginnen kann, bevor er das letzte Quad-Wort aus dem entsprechenden Datenblock empfangen hat. Verzögerungen aufgrund der Cache-Aktualisierungs-Transaktion können auf diese Weise verringert werden. Das Lesen und Schreiben von nicht gecachten Datenblöcken der Größe 64 Byte ist immer auf den Grenzwert 64 Byte für die Blockgröße ausgerichtet (PA[5 : 4] = 0 · 0).
  • Es ist zu bemerken, daß diese Datenpakete der Größe 64 Byte ohne eine angehängte Adresse, ein Adreß-Tag oder Transaktions-Tag verschickt werden. Die Daten und Informationen zur Adresse werden davon getrennt über unabhängige Busse übertragen. Dieser Ansatz ist effizient, um jedoch eingehende Datenpakete mit Cache-Miss Datenanforderungen abzugleichen, muß eine bestimmte Reihenfolge eingehalten werden: Die Reihenfolge, in der Datenpakete an einen UPA-Port übertragen werden, muß die gleiche sein wie die der Übertragung der entsprechenden Anforderungen innerhalb einer Master-Klasse. (Bei Datenanforderungen in verschiedenen Master-Klassen sind an die Reihenfolge keine Bedingungen geknüpft.) Wird diese Bedingung eingehalten, dann muß jedes eingehende Datenpaket die Antwort auf die am längsten anstehende Cache-Miss Transaktionsanforderung für die entsprechende Master-Klasse sein. Tabelle 2
    • Anforderungs- und Antwortnachrichten
  • Transaktionen werden durch "Anforderungs"-Nachrichten initiiert und nach Erhalt einer "Antwort"-Nachricht ausgeführt. Alle Anforderungen von UPA-Ports sind hier mit P_REQ gekennzeichnet, was für "Port-Anforderung" ("Port Request") steht. Eine Port- Anforderung wird über den Adreßbus 114 des UPA-Ports übertragen. Wird der Adreßbus 114 von mehr als einem Port genutzt, dann überträgt der anfordernde Port seine Anforderung erst, nachdem er in der Buszuteilung an der Reihe ist.
  • Jede Portanforderung wird vom System-Controller 110 durch eine hier als S_REPLY bezeichnete Antwortnachricht bestätigt. Es gibt einen dafür bestimmten Punkt-zu-Punkt 5-Bit System-Antwortbus, den S_REPLY-Bus 120, für jeden UPA-Port, über den einseitig gerichtet 5-Bit Antwortnachrichten vom System-Controller 110 an jeden UPA-Port gesendet werden. Der System-Controller 110 setzt über den S_REPLY-Bus 120 einen Antwortcode ab, um den Eingang einer Transaktionsanforderung zu bestätigen, und um das Aussenden und Übertragen von Daten auf den bzw. dem UPA-Datenbus 116 zu koordinieren. Konkret generiert der System-Controller 110 eine Nachricht S_REPLY als Antwort auf eine P_REQ entweder dann, wenn der System-Controller 110 bereit ist, den für die angeforderte Transaktion nötigen Datenweg aufzubauen, oder, falls die Transaktion keinen Datentransfer erfordert (z. B. wenn eine Ungültigmachung angefordert ist) nachdem die angeforderte Transaktion ausgeführt ist. Die Nachricht S_REPLY wird vom System-Controller praktisch gleichzeitig mit dem Absenden der entsprechenden Setup-Signale an das Verbindungsmodul 112 generiert.
  • Jede vom System-Controller 110 initiierte Transaktion wird initiiert durch das Absenden einer Nachricht S_REQ (d. h. der Anforderung des System-Controllers) über den Adreßbus 114, der an den UPA-Port 104, an den die Anforderung gerichtet ist, angeschlossen ist. Vom System-Controller 110 initiierte Transaktionen sind in der Regel "verschachtelte Transaktionen", die vom System-Controller 110 als Antwort auf eine Transaktionsanforderung eines UPA-Ports ausgeführt werden. Zum Beispiel kann eine bestimmte von einem UPA-Port angeforderte Speichertransaktion es erfordern, daß alle Cache-Einträge anderer UPA-Ports für den angeforderten Datenblock ungültig gemacht werden, bevor der System- Controller den angeforderten Datenblock an den Cache des anfordernden UPA-Ports übertragen kann. Das Ungültig machen der Caches wird vom System-Controller ausgeführt, indem Transaktionsanforderungen an alle UPA-Ports versendet werden, in deren Caches der angeforderte Datenblock gespeichert ist.
  • Jeder UPA-Port 104 hat einen bestimmten Punkt-zu-Punkt 5-Bit Port-Antwort-Bus, P_REPLY, 122, der von diesem Port genutzt wird, um Anforderungen des System-Controllers zu bestätigen.
  • Alle Anforderungen des System-Controllers werden an den "Slave-Port" Bereich des Empfänger-UPA-Ports verschickt. Zur Bestätigung einer vom System-Controller 110 empfangenen Transaktion verschickt der Slave-Port des UPA-Ports über den P_REPLY-Bus 122 einen Antwortcode, der anzeigt: bei einer Leseanforderung: daß die angeforderten Daten bereit stehen; bei einer Schreibanforderung: daß die übertragenen Daten angenommen wurden; bei einer Invalidierungsanforderung: daß die Cache-Invalidierung ausgeführt ist; und bei Interrupt-Anforderungen: daß der Interrupt abgearbeitet wurde.
  • Der System-Controller 110 löst in Reaktion auf die vom UPA-Slave-Port erhaltene Bestätigungsnachricht P_REPLY die Übertragung seiner Nachricht S_REPLY an den anfordernden UPA-Port aus.
    • Cache-Speicher, Tags und Snoop-Bus
  • Wie in Fig. 1 dargestellt gibt es für jedes UPA-Modul 102, das einen Cache-Speicher 130 beinhaltet, einen Primär-Cache-Index 132 mit einer Anordnung von Pimär-Cache-Tags, genannt Etags. In den meisten Ausführungen ist der Cache-Speicher 130 ein "Sekundär- Cache" oder ein "Tertiär-Cache", da im UPA-Modul 102 des Datenprozessors 178 (siehe Fig. 4) üblicherweise ein Primär- oder Sekundär-Cache integriert ist. Duplikate von Cache-Tags werden lediglich für den äußersten kohärenten Direct-Mapped-Cache eines jeden Datenprozessors beibehalten, alle anderen Caches niedrigerer Ordnung werden als zum UPA- Port gehörig betrachtet und durch den UPA-Port durch perfekte Integration kohärent gehalten.
  • Für jede Line des Cache-Speichers 130 gibt es ein Etag, und in jeder Line des Caches ist ein 64-Byte (16-Wort) Datenblock gespeichert. In der bevorzugten Ausführung ist in jedem Etag der Tag-Zustand und ein Satz von Adreßbits gespeichert, die die Adresse des in der Cache-Line gespeicherten 64-Byte Blocks markieren.
  • Wie eben erwähnt beträgt die Größe eines Cache-Blocks 64 Byte. Die Einheit der Cachekohärenz ist ebenfalls 64 Byte. Die Caches der verschiedenen UPA-Ports können unterschiedlich groß sein. Zudem werden in der bevorzugten Ausführung in Datenprozessoren und Ein-/Ausgabe-UPA-Ports nur Direct-Mapped-Caches verwendet. Die Ein-/Ausgabe- UPA-Ports können eine beliebige unter verschiedenen Strukturen von Cache-Speichern haben. Die Unterstützung solcher Cache-Speicher Strukturen durch den System-Controller wird durch spezielle Kopien von Tags einer gleichartigen Struktur im System-Controller realisiert. In der bevorzugten Ausführung verfügt der Ein-/Ausgabe-UPA-Port über mehrere vollassoziative kohärente Puffer mit einer entsprechenden Anzahl von Dtags im System- Controller.
  • Standardgemäß hängt die Anzahl der zum Identifizieren eines Datenblocks nötigen Adreßbits von der Größe des Cache-Speichers und des in diesen eingemappten Adreßraums ab. Für einen Adreßraum der Größe 8 Gigabyte und einen Direct-Mapped-Cache-Speicher der Größe 512 Kbyte werden zum Beispiel 14 Adreßbits benötigt, um den Datenblock in jeder Line des Cache-Speichers zu markieren. Das bedeutet, daß bei einer 33-Bit Adresse PA[32 : 0] für ein bestimmtes Byte und einer 27-Bit Adresse PA[32 : 6] für den entsprechenden 64-Byte Datenblock, der in einem 512 Kilobyte Cache-Speicher mit 64-Byte Lines gespeichert ist, die 14 signifikantesten Adreßbits PA[32 : 19] der vollständigen Adresse des Datenblocks im Cache-Tag gespeichert werden, um den Datenblock zu markieren, und die nächsten 13 Bits PA[18 : 6] der Adresse des Datenblocks bestimmen, in welcher Cache-Line der Datenblock gespeichert ist. Im System 100 mit einem 1 Terrabyte kohärenten Adreßraum PA[39 : 0] und einem 512 Kilobyte Direct-Mapped-Cache-Speicher 130 müssen in jedem Etag die 21 signifikantesten Bits der vollständigen, in der entsprechenden Line des Cache-Speichers gespeicherten Adresse des Datenblocks gespeichert sein.
  • Die Anzahl der im Cache-Index gespeicherten Adreßbits und damit die Größe des Caches für jeden Master-UPA-Port wird durch die Initialisierungssoftware des Systems bestimmt, indem die ID-Register 158 jedes UPA-Ports, wie im folgenden noch beschrieben wird, geprüft werden.
  • Um Interferenzen zwischen Snoop-Vorgang und dem Zugreifen eines Ports auf seinen koährenten Cache in Multiprozessor-Systemen zu vermeiden, wird ein duplikater Tag-Satz (Dtags) 134, in dem die Etags 132 des UPA-Moduls gespiegelt sind, vom System-Controller 110 für jedes UPA-Modul aufbewahrt, das einen Cache-Speicher hat, der mit den anderen Cache-Speichern im System 100 kohärent gehalten werden muß. Die Dtags 134 unterstützen Direct-Mapped-Cache-Speicher. Pür jeden Etag-Eintrag gibt es einen entsprechenden Dtag- Eintrag, so daß das Überprüfen der Dtags dem System-Controller 110 den Zustand des entsprechenden Etags für einen Datenblock korrekt anzeigt, ohne daß der Zugriff eines Prozessors auf seine Etags gestört werden müßte.
  • Der Snoop-Bus 140 ist ein Adreßbus, der alle relevanten physikalischen Adreßbits PA[40 : 6] übertragen kann, die der Größe des cachebaren Adreßraums im System (Größe des Hauptspeichers) entsprechen. Der Snoop-Bus beinhaltet ferner zwei bidirektionale Bit- Leitungen, eine Leitung für das Match-Signal und eine Schreibsteuerungsleitung für jede Dtag-Anordnung 134. Die beiden Bit-Leitungen übertragen beim Lesen der Dtags einen 2- Bit-kodierten Cache-Line Zustand von der Dtag-Anordnung 134 zum System-Controller 110, und sie übertragen einen 2-Bit-kodierten aktualisierten Cache-Line Zustand, wenn der System-Controller 110 die Dtags aktualisiert. Die Match-Leitung für eine bestimmte Dtag- Anordnung überträgt ein Match-Signal, das anzeigt, ob die Adresse auf dem Snoop-Bus 140 mit der Adresse eines im entsprechenden Cache-Speicher gespeicherten Datenblocks übereinstimmt. Das Match-Signal ist dem Hit/Miss-Signal des Cache äquivalent, das vom Primär-Cache-Index des Cache-Speichers in Reaktion auf die gleiche Adresse generiert wird, mit dem Unterschied, daß das Match-Signal von der Dtag-Anordnung generiert wird, ohne in den Primärindex des Cache-Speichers (d. h. die Etag-Anordnung) einzugreifen.
  • Der Snoop-Bus 140 ist vom Adreßbus 114 und dem Datenbus 116 unabhängig skalierbar. Die Anzahl der verwendeten parallelen Snoop-Busse 140 und die Anzahl der Dtag- Anordnungen 134, die jeden Snoop-Bus 140 beladen, kann also einzig durch die erforderliche Geschwindigkeit der Dtag-Einsicht und der Aktualisierungs-Operationen bestimmt werden, völlig unabhängig von den Geschwindigkeitsanforderungen des Adreßbusses 114 und des Datenbusses 116.
    • Ausführung der UPA-Ports
  • Jeder UPA-Port 104 ist durch einen einmaligen 5-Bit Wert gekennzeichnet, der Port- ID oder UPA_Port_ID (siehe Fig. 3) genannt wird. Dadurch sind in einem System 100 maximal 32 UPA-Ports möglich.
  • Wie in Fig. 4 dargestellt kann jeder UPA-Port vier funktionelle Schnittstellen haben: ein Master-Interface 150, ein Slave-Interface 152, ein Interrupter-Interface 154 und ein Interrupt-Handler-Interface 156. Alle UPA-Ports haben das UPA-Slave-Interface 152 und ein Port-ID-Register 158. Das Port-ID-Register 158 wird vom UPA-Port 104 genutzt, um dem System-Controller 110 seine Kapazitäten mitzuteilen.
  • Wie in Fig. 4 dargestellt schließen diese Schnittstellen eine Anzahl von Warteschlangen mit ein. Das Slave-Interface 152 hat eine Warteschlange für eingehende Anforderungen zum Empfang von Transaktionsanforderungen (PREQ, SREQ), Interrupt- Anforderungen (INT) und mit den Anforderungen verbundene Daten (PREQ_DQ, INT_DQ). Das Master-Interface 150 hat die Warteschlangen C0, C1 für abgehende Anforderungen und beinhaltet wahlweise die Warteschlangen für eingehende und abgehende Daten IDQ0, ODQ0, IDQ1, ODQ1 für jede Master-Klasse.
  • Manche der nachfolgenden Erläuterungen beziehen sich auf bestimmte Transaktions- und Antwortnachrichten. Die Gesamtheit solcher Transaktions- und Antwortnachrichten ist im Kapitel "Genaue Beschreibung der Transaktionen" in diesem Dokument dargestellt. Das Port-ID-Register 158 hat folgende Felder:
  • - Das ID-Feld 160 ist ein 16-Bit Feld das das mit dem Port verbundene UPA-Modul kennzeichnet, davon sind 6 Bits für eine Herstelleridentifikation vorgesehen (Kennzeichnung durch Sun Microcystems, Inc.), 6 Bits für den Modul- oder Prozessortyp (Kernzeichnung durch den Hersteller), und 4 Bits für die Versions- oder Neuauflage-Nr. des Moduls (Kennzeichnung durch den Hersteller).
  • - Das UPACAP-Feld 161 ist ein 5-Bit Kennzeichnungsfeld für die Angabe der Fähigkeiten des UPA-Ports.
  • - UPACAP[0] bedeutet, daß die UPA ein Master-Interface hat.
  • - UPACAP[1] bedeutet, daß das UPA-Modul einen Cache hat (der aus dem UPA-Port einen "CacheMaster" macht).
  • - UPACAP[2] bedeutet, daß der UPA-Port ein Interrupter-Interface hat, das das Signal UPA_Slave_Int_L nutzt. Dieses Bit wird primär von UPA-Ports gesetzt, die ausschließlich als Slave fungieren. Die Software kennzeichnet diesen UPA-Port als Target-MID, das mit einem Interrupt-Handler verbunden ist.
  • - UPACAP[3] bedeutet, daß der UPA-Port ein Interrupter-Interface hat, das das Transaktionsanforderungsprotokoll P_INT_REQ nutzt. Die Software kennzeichnet diesen UPA-Port als Target-MID, das mit einem Interrupt-Handler verbunden ist.
  • - UPACAP[4] bedeutet, daß der UPA-Port ein Interrupt-Handler-Interface hat. Der System-Controller leitet die Interrupt-Anforderungen P_INT_REQ nur dann von anderen UPA-Ports an diesen Port weiter, wenn dieses Bit gesetzt ist.
  • - Das Feld ECCNotValid 162 ist ein 1-Bit Feld, das anzeigt, daß dieser UPA-Port den ECC nicht unterstützt. Dieses Feld ist auf 0 · 0 gesetzt, wenn der UPA-Port beim Aussenden von Daten den ECC generieren kann. Es ist auf 0 · 1 gesetzt, wenn der UPA-Port das Generieren des ECC beim Aussenden von Daten nicht unterstützt, sondern der System- Controller 110 benötigt wird, um dem Empfänger-UPA-Port anzuzeigen, daß die ECC- Kontrolle deaktiviert werden soll. Ist ECCNotValid auf 0 · 1 gesetzt, dann wird vom UPA-Port weder die ECC-Kontrolle auf dem UPA-Datenbus, noch die Paritätskontrolle auf dem UPA- Adreßbus unterstützt.
  • - Das Feld ONEREAD 164 ist ein 1-Bit Feld, das anzeigt, daß dieser UPA-Port lediglich eine anstehende Slave-Lese-Transaktionsanforderung P_REQ zu einem Zeitpunkt unterstützt. Ist das Feld ONEREAD gesetzt, so kann dieser UPA-Port die Nachrichten P_RAB_REPLY und P_RASP_REPLY nicht ausgeben, sondern muß die Antwortnachricht P_RASB_REPLY nutzen. Daraus folgt, daß, wenn das Feld ONEREAD gesetzt ist, dieser UPA-Port die an ihn gerichteten Transaktionsanforderungen P_NCRD_REQ und P_BCBRD_REQ für einen Slave-Zugriff mit P_RASB beantworten muß. Wie im folgenden noch erläutert verwahrt der System-Controller Informationen über MID, Klasse und Größe, die für solche Transaktionen benötigt werden, für den UPA-Port. Die Transaktionsanforderungsnachricht P_NCRD_REQ und die Antwortnachricht P_RASB werden ebenfalls im folgenden noch genauer beschrieben.
  • - Das Feld PREQ_RQ[3 : 0] 166 ist ein 4-Bit Feld, in dem die Größe der Warteschlange 167 für PREQRQ im Slave-Interface 152 kodiert ist. Dieses Feld markiert die maximale Anzahl der (in 2 Zyklen) eingehenden Transaktionsanforderungspakete P_REQ, die das UPA- Slave-Interface 152 gleichzeitig aufnehmen kann. Der Mindestwert von PREQ_RQ ist 0 · 1, da jeder UPA-Port zumindest den Slave-Lesezugriff auf seine Port-ID-Register unterstützten muß.
  • - Das Feld PREQ_DQ[5 : 0] 168 ist ein 6-Bit Feld, in dem die Größe der Warteschlange 169 für PREQ_DQ kodiert ist. In diesem Feld ist die Anzahl der eingehenden Quad-Wörter (16-Byte Einheiten) markiert, die der UPA-Slave-Port in seiner P_REQ Warteschlange 169 für das Schreiben von Daten aufnehmen kann. Die PREQ_DQ Warteschlange für dass Schreiben von Daten muß für die maximale Anzahl der Anforderungen, die in der Anforderungswarteschlange PREQ_RQ stehen können, Datenblöcke (64 Byte) erfassen können. Daraus folgt, daß die Größe der Daten-Warteschlange PREQ_DQ immer das vierfache der im Feld 166 PREQ_RQ festgelegten Größe beträgt, außer wenn PREQ_DQ auf 0 · 0 gesetzt werden kann, wenn der UPA-Port den Slave-Schreibzugriff nicht unterstützt.
  • - Das Feld PINT_RDQ[1 : 0] 170 ist ein 2-Bit Feld, in dem die Größen der Warteschlangen 171, 172 für INT_RQ und INT_DQ kodiert sind. Das Feld PINT_RDQ 170 ist nur dann gültig, wenn der UPA-Port ein Interrupt-Handler-Interface 156 hat. Die Größe der Warteschlange für Interupt-Anforderungen, INT_RQ 171, entspricht dem Binärwert dieses Felds plus 1. Die maximale Größe der Warteschlange für Interrupt-Anforderungen beträgt 4 Interrupt-Anforderungen. Zusammengefaßt markiert dieses Feld die Anzahl der (in 2 Zyklen) eingehenden Anforderungen P_INT_REQ, die der UPA-Slave-Port aufnehmen kann, sowie die Anzahl der 64-Byte Interrupt-Datenblöcke, die das UPA-Slave-Interface aufnehmen kann.
  • Bezüglich des Felds UPACAP ist zu sagen, daß es kein Maskenbit gibt, das die Fähigkeiten des Slave anzeigt, da jeder UPA-Port ein Slave-Interface haben muß, damit die Port-ID-Register gelesen werden können. Im folgenden werden einige Beispiele für Einstellungen des Felds UPACAP gezeigt. Bei einem UPA-Port mit allen Funktionen, wie z. B. einem Prozessormodul, ist die UPACAP-Maske auf O · 1B gesetzt. Bei einem nur als Slave fungierenden UPA-Port wie z. B. einem Graphikbauelement, der nur für Slave-Zugriff gemappt ist und nicht unterbrechen kann, ist die UPACAP-Maske auf 0 · 0 gesetzt. Bei einem intelligenten, nur als Slave fungierenden UPA-Port, der Interrupts generiert (mit UPA_Slave- Int) ist die UPACAP-Maske auf 0 · 04 gesetzt. Bei einem Ein-/Ausgabe-UPA-Port, der DVMA-Operationen (direkter virtueller Speicherzugriff) ausführen kann, keinen Cache hat und Interrupt-Anforderungs-Transaktionen P_INT_REQ generiert ist die UPACAP-Maske auf 0 · 9 gesetzt.
    • Master Interface
  • Das Vorhandensein eines Master-Interface 150 ist optional. Hat ein UPA-Port ein UPA-Master-Interface so kann er Transaktionsanforderungen (P_REQ) initiieren. Ein UPA- Port 104 mit einem Master-Interface 150 wird hier als Master-Port bezeichnet.
  • Das UPA-Modul für einen Master-Port kann einen physikalisch adressierten kohärenten Cache haben, in diesem Falle spricht man von einem Cache-Master-Port. Der Cache ist am "MOESI-Cachekohärenzprotokoll" beteiligt (das im folgenden noch näher erläutert wird) und reagiert auf Rückkopier-Invalidierungsanforderungen des System- Controllers 110. Der kohärente Cache schließt alle anderen nebengeordneten lokalen Caches im UPA-Modul vollständig ein. In der bevorzugten Ausführung kann in jedem cachenden UPA-Master-Port höchstens ein Dirty Victim - Rückschreibetransaktion anstehen, zum Teils deshalb, weil die Cache-Speicher aller Datenprozessoren nur einen einzigen Rückschreibe- Puffer haben (siehe Puffer 280 in Fig. 8), und zum Teil um die komplexe Steuerlogik, die das Vorhandensein mehrerer Rückschreibe-Puffer erfordern würde, zu umgehen.
  • In anderen Ausführungen, in denen der Datenprozessor mehrere Aufgaben und Cache- Misses oder Prefetches ausgeben kann, können im Datenprozessor mehrere Rückschreibe- Puffer und im System-Controller eine entsprechende Anzahl temporärer Dtag-Puffer vorhanden sein. Die hier beschriebenen Logikprotokolle zur Behandlung von Rückschreibetransaktionen funktionieren mit jeder beliebigen Anzahl von anstehenden Rückschreibetransaktionen des UPA-Ports.
  • Ein UPA-Master-Interface 150 hat für zwei "Klassen" von Transaktionsanforderungen bis zu zwei unabhängige Warteschlangen C0 und C1 für abgehende Anforderungen. C0 und C1 werden auch "Master-Klassen" genannt, da es sich dabei um Klassen von Transaktionen handelt, die von UPA-Master-Ports initiiert werden. Das UPA-Master-Interface kann Transaktionsanforderungen aus jeder beliebigen Klasse ausgeben. Die Klasse, der die Anforderung angehört, wird dem System-Controller durch ein bestimmtes Bit in jedem Transaktionsanforderungs-Paket angezeigt. Die Port-Identifikation des UPA-Ports ist ebenfalls im Transaktions-Paket enthalten, und zwar im MID-Feld (siehe nachfolgendes Kapitel "Transaktionen"). Ferner kann das Master-Interface 150 für jede der Transaktionsklassen Warteschlangen für eingehende und abgehende Daten beinhalten, die mit IDQ0, ODQ0, und IDQ1, ODQ1 bezeichnet sind.
  • Der Zweck des Vorhandenseins von zwei oder mehr Transaktionsklassen (hier als Master-Klassen bezeichnet) besteht darin, die parallele Verarbeitung von Speichertransaktionen zu verstärken, indem jeder Datenprozessor anzeigen kann, welche Speichertransaktionen sequentiell geordnet sein müssen, und welche nicht. Transaktionen eines Datenprozessors, die der selben Master-Klasse angehören, sind "streng geordnet", d. h. daß die Transaktionen innerhalb jeder Klasse in der Reihenfolge ausgeführt werden müssen, in der der Datenprozessor die Speicheranforderungen in der betreffenden Klasse generiert. Bei Speichertransaktionen in verschiedenen Klassen ist keine bestimmte Ordnung erforderlich. Gibt der Datenprozessor also Speichertransaktions-Anforderungen T1-1, T1-2 und T1-3 in dieser Reihenfolge in Klasse 1 aus, und Speichertransaktionen T2-1 und T2-2 in dieser Reihenfolge in Klasse 2, dann muß der System-Controller die Transaktionen T1-1, T1- 2 und T1-3 in der selben Reihenfolge ausführen, in der sie generiert wurden. Der System- Controller muß gleichermaßen die Transaktionen T2-1 und T2-2 in der selben Reihenfolge ausführen, in der sie generiert wurden, er kann jedoch die Transaktionen T2-1 und T2-2 in Bezug auf die Transaktionen T1-1, T1-2 und T1-3 zu jeder beliebigen Zeit ausführen.
  • Daten-Warteschlangen werden in der bevorzugten Ausführung genutzt, um das Abwickeln von Datentransfers zu vereinfachen. Warteschlangen für abgehende Daten werden immer mit zu übertragenden Daten gefüllt, bevor die entsprechende Transaktions- Anforderung oder Antwortnachricht übertragen wird. Auf diese Weise wird bei Übertragung einer Anforderungsnachricht für eine Datenschreib-Transaktion oder einer Antwortnachricht "Daten bereitgestellt" durch einen UPA-Port dem Verbindungsmodul versichert, daß die entsprechenden Daten für die sofortige Übertragung bereitstehen. Warteschlangen für eingehende Daten, die meist optional sind, werden üblicherweise durch FIFO (first-in firstout) -Puffer realisiert, die unabhängig von den Zuständen aller anderer Logikschaltungen gefüllt werden können. Daraus folgt, daß, wenn ein UPA-Port Warteschlangen für eingehende Daten hat, weder das UPA-Modul (z. B. ein Datenprozessor), noch sein UPA-Port das Handshake-Protokoll für das Empfangen von Datenpaketen ausführen müssen. Vielmehr werden die Daten einfach vom Verbindungsmodul in der Warteschlange für eingehende Daten abgelegt, und der entsprechende UPA-Port oder sein UPA-Modul verarbeitet die Daten, sobald die erforderlichen Ressourcen verfügbar sind.
  • Die S_REPLYs für Transaktionen in jeder Master-Anforderungsklasse werden vom System-Controller 110 an den anfordernden Master-UPA-Port in der selben Reihenfolge ausgegeben, in der die Transaktions-Anforderungen ursprünglich vom anfordernden UPA- Port ausgegeben wurden. Diese Bedingung wird im System-Controller verwirklicht durch (A) Behandeln jeder Anforderungs-Warteschlange SCIQ0/1 einer Master-Klasse als first-in firstout - Puffer, so daß die Transaktionen innerhalb jeder Master-Anforderungs-Klasse vom System-Controller genau in der Reihenfolge aktiviert werden, in der die Transaktions- Anforderungen ausgegeben wurden, und (B) dadurch, daß innerhalb einer Menge aktiver Transaktionen die S_REPLYs für Transaktionen, die von der selben Master-Klasse im selben UPA-Port angefordert wurden, in der gleichen Reihenfolge ausgegeben werden, in der diese Transaktionen aktiviert wurden.
  • Wie oben ausgeführt bestehen zwischen den beiden Transaktions-Anforderungs- Klassen C0, C1 bezüglich der Reihenfolge keine Bedingungen. Die S_REPLY für eine Anforderung aus einer Klasse kann früher oder später eintreffen als die S_REPLY für eine Anforderung aus der zweiten Klasse, ungeachtet der Reihenfolge, in der diese Anforderungen dem System-Controller übertragen wurden.
  • Bezüglich der Anforderungen verschiedener Master-UPA-Ports sind ebenfalls keine Bedingungen an die Reihenfolge gestellt. Lese-/Schreib-Anforderungen von verschiedenen Master-UPA-Ports, die an das Slave-Interface eines UPA-Ports gerichtet sind, können vom Slave-Interface des UPA-Ports in beliebiger Reihenfolge ausgeführt werden, Anforderungen des selben Master-UPA-Ports aus der selben Master-Anforderungs-Klasse müssen jedoch vom Slave-Interface des UPA-Ports in der Reihenfolge ausgeführt werden, in der sie vom Slave-Interface des UPA-Ports empfangen wurden.
  • Bezüge auf Ein-/Ausgabevorrichtungen sind sequenziell beständig. Das Slave-UPA- Interface sortiert Transaktionen nach den Adressen der Vorrichtungen. Bezüge auf die selbe Ein-/Ausgabevorrichtung (oder einen vorbestimmten Adreßbereich) müssen in der Reihenfolge ausgeführt werden, in der sie beim UPA-Slave-Interface eintreffen. Es sind jedoch keine Bedingungen an die Reihenfolge von Bezugnahmen auf verschiedene Ein- /Ausgabevorrichtungen gerichtete Bezüge gestellt, die vom selben UPA-Slave-Interface abgehen (wie z.B in einer Busbrücke), und das UPA-Slave-Interface kann an verschiedene Ein-/Ausgabevorrichtungen (oder verschiedene vorbestimmte Adreßbereiche) gerichtete Transaktionen parallel verarbeiten.
  • Jedes UPA-Modul muß alle Transaktions-Anforderungen, die eine bestimmte Reihenfolge einhalten müssen, in ein und dieselbe Master-Anforderungs-Klasse einordnen. Die Klassen aller Prozessor-UPA-Module werden vorzugsweise wie folgt gekennzeichnet:
  • - Klasse 0 wird für Lesetransaktionen aufgrund von Cache-Misses und das Laden von Blöcken verwendet.
  • - Klasse 1 wird für Rückschreibe-Anforderungen, Schreib-Invalidierungs- Anforderungen, das Speichern von Blöcken, Interrupt-Anforderungen und nicht gecachte Lese-/Schreib-Anforderungen verwendet.
  • Das Zuordnen von Speichertransaktionen zu Klassen macht es möglich, daß durch Cache-Misses verursachte Speichertransaktionen durch andere Transaktionen nicht blockiert werden und ist besonders dann notwendig, wenn der Datenprozessor mehrere anstehende Aufgaben und/oder Prefetching unterstützt. Dadurch wird, neben weiteren Vorteilen, eine geringstmögliche Wartezeit für Cache-Inhalte gewährleistet.
  • Das Verbindungsmodul kann die parallele Verarbeitung von Transaktionen maximieren und macht es möglich, daß diese - außer bei Transaktionen vom selben UPA-Port und der selben UPA-Klasse - in beliebiger Reihenfolge ausgeführt werden. Zum Aufrechterhalten der Kohärenz, und zum Erzielen von Sequenzbeständigkeit werden programmierseitig die Speichermodelle TSO (Total Store Order), PSO (Partial Store Order) und RMO (Relaxed Memory Order) sowie das Speichermodell (Strong Sequential Order) für den Ein-/Ausgabebereich unterstützt, ohne daß tatsächlich die Hardware des Verbindungsmoduls sequenzbeständig gemacht werden müßte.
  • Ein UPA-Master-Port ist einzig für das Sortieren seiner internen Speichervorgänge auf Grundlage seines Speichermodells zuständig, und es kann jede beliebige Kombination von Transaktionen aus jeder beliebigen Anforderungsklasse ausgeben, die die Anforderungen seines Speichermodells erfüllt. Der Datenprozessor des UPA-Ports kann die beiden Master- Klassen dafür nutzen, Transaktionen zu parallelisieren und so zu ordnen, wie es sein lokales Speichermodell erfordert. Alle Beschränkungen und Synchronisierungen werden vom Datenprozessor auf Grundlage seines Speichermodells hergestellt, bevor es die Transaktionen aus den Master-Klassen ausgibt.
  • Alle Datentransaktionen werden immer vollständig durchgeführt, und es gibt kein Wiederhol-NACK vom System-Controller 110 an den Master-UPA-Port (mit Ausnahme einer Interrupt-Transaktion).
  • Der UPA-Master-Port darf keinen Lese-/Schreib-Slave-Zugriff auf seinen eigenen Slave-Port vornehmen, auch darf er keinen Datenblock anfordern, der bereits in seinem Cache gespeichert ist oder Interrupts an sich selbst abschicken. Rückschleifen werden von der bevorzugten Ausführung der vorliegenden Erfindung aufgrund von Einschränkungen der Elektrik in Verbindung mit den Konnektoren nicht unterstützt. Die Verwendung von Rückschleifen wird jedoch durch die System-Architektur der vorliegenden Erfindung nicht logisch verhindert. Die S_REPLY-, Datentransfer- und Cachekohärenzprotokolle sind tatsächlich so konstruiert, daß sie Rückschleifen unterstützen.
    • Slave-Interface
  • Alle UPA-Ports haben ein Slave-Interface 152, und alle UPA-Ports verwenden das Port-ID-Register 158. Ein Slave-Interface 152 kann nur auf Transaktionen antworten, sie aber nicht initiieren. Ein Slave-Interface 152 wird hier manchmal auch "Slave-Port" genannt. Mit Slave-Port ist hier stets das Slave-Interface eines UPA-Ports gemeint, unabhängig davon, ob der UPA-Port ein Master-UPA-Port ist.
  • Ein UPA-Slave-Interface 152 auf einem cachenden Master-UPA-Port gestattet dem UPA-Port, vom System-Controller 110 Rückkopier-Invalidierungs-Anforderungen zu empfangen.
  • Ein UPA-Slave-Interface 152 gestattet einem UPA-Port, Interrupt-Paket- Transaktionen zu empfangen, wenn das Slave-Interface Teil eines UPA-Ports ist, der ein Interrupt-Handler-Interface 156 hat.
  • Ein UPA-Slave-Interface hat einen nicht gecachten Adreßraum, und es gestattet den programmierten Ein-/Ausgabe- (PIO) Lese- und Schreibzugriff auf Bauelemente und Register, einschließlich des Lesens seines Port-ID-Registers 158, auf dem UPA-Modul von Master-UPA-Ports. Jedem UPA-Slave-Interface ist ein 8-Gigabyte nicht gecachter Adreßraum zugeordnet. Wird von einem UPA-Port das an ihn gerichtete Signal UPA Addr Valid registriert und das signifikanteste Adreßbit PA[40] ist gleich 1, dann stellen die physikalischen Adreßbits PA[32 : 4] des Transaktionsanforderungs-Pakets Adressen im nicht gecachten Adreßraum dar.
  • Die Architektur des UPA-Verbindungsmoduls legt weder den Adreßraum des gesamten Systems fest, noch die Adressen-Dekodierung der Systemregister, mit Ausnahme des Port-ID-Registers 158.
  • Ein UPA-Slave-Interface verarbeitet PIO Lese-/Schreib-Transaktionsanforderungen aus der selben Master-Klasse eines Master-UPA-Ports in der selben Reihenfolge, in der diese Anforderungen empfangen werden. D. h. es verschickt P_REPLY-Nachrichten für diese Transaktionsanforderungen in der Reihenfolge, in der die Transaktionsanforderungen empfangen wurden. Es muß jedoch keine Reihenfolge einhalten, wenn es sich um Anforderungen aus verschiedenen Master-Klassen eines UPA-Ports handelt, oder um Anforderungen von verschiedenen UPA-Ports.
  • Ist das UPA-Slave-Interface mit der Schnittstelle für einen Ein-/Ausgabebus verbunden, dann muß die Schnittstelle für den Ein-/Ausgabebus ebenfalls die Reihenfolge der von ihr empfangenen Transaktionen für jede einzelne Adresse oder jeden einzelnen Adreßbereich einhalten. Folgt zum Beispiel auf eine Schreibtransaktion zu Adresse A (oder zu Bauelement A) auf dem Ein-/Ausgabebus eine Lesetransaktion zu Adresse A (oder zu Bauelement A) auf dem selben Ein-/Ausgabebus, dann darf die Schnittstelle für den Ein- /Ausgabebus die Lese-Transaktion nicht vor der Schreib-Transaktion anordnen. Folgt jedoch auf eine Schreibtransaktion zu Adresse A (oder zu Bauelement A) eine Lesetransaktion von Adresse B (oder zu Vorrichtung B), dann ist die Reihenfolge der Verarbeitung durch die Schnittstelle für den Ein-/Ausgabebus beliebig. Der genaue Reihenfolge-Mechanismus auf dem Ein-/Ausgabebus kann zwischen verschiedenen Ausführungen der Schnittstelle für den Ein-/Ausgabebus variieren. Die Verwendung eines Blockierbits oder einer blockierenden Bitmap-Struktur ähnlich der oben für die Reihenfolge der Klassen beschriebenen ist jedoch sowohl für das klassenbasierende Ordnen als auch für das Ordnen aufgrund der Ein- /Ausgabeadresse möglich.
  • Ein UPA-Slave-Interface kann nicht gewährleisten, daß eine Schreib-Transaktion vollständig ausgeführt wird. Folgt auf eine Schreibtransaktion eine Lesetransaktion (durch den selben Prozessor), dann wird das Ergebnis der letzten Schreibtransaktion ausgegeben, wenn der Bereich existiert. Da jedoch das Lesen von und Schreiben in Register von Ein- /Ausgabebauelementen für die jeweilige Ausführung spezifische Nebeneffekte haben kann, ist die Semantik von jedem Ein-/Ausgabebauelement abhängig.
  • Ein Master-UPA-Port kommuniziert mit einem Slave-UPA-Port nur über das Verbindungsmodul 112, selbst wenn die beiden den selben UPA-Adreßbus nutzen.
  • Ein nur als Slave fungierender UPA-Port (ein UPA-Port, der kein Master-Interface hat), kann eine dafür bestimmte Interrupt-Ader nutzen, um dem System-Controller einen Interrupt zu signalisieren. Der System-Controller generiert dann für ihn ein Interrupt-Paket und verschickt dieses an einen Interrupt-Hander-UPA-Port.
  • Der System-Controller 110 bearbeitet die Flußsteuerung von Anforderungen an das Slave-Interface eines UPA-Ports, indem er die maximale Größe der in den Fig. 4 und 5 dargestellten drei Warteschlangen für beim Slave ankommende Anforderungen (PREQ_RQ, SREQ_RQ, INT_RQ) und der beiden Daten-Warteschlangen (PREQ_DQ, INT_DQ) kennt. Die Port-ID-Register 158 für jeden UPA-Port legen die maximale Anzahl anstehender Transaktions-Anforderungen jeder Art fest, die gleichzeitig in den Warteschlangen gespeichert sein kann und bestimmen somit, wie viele solcher Anforderungen sie vom System-Controller 110 erhalten können, bevor ein Teil dieser Anforderungen abgearbeitet ist. Das Port-ID-Register 158 legt auch die maximale Anzahl der Quad-Wörter (16-Byte Einheiten) fest, die jede Daten-Warteschlange aufnehmen kann.
  • Die Schnittstelle 152 des UPA-Slave-Port kann empfangene Transaktionen nicht mit "Wiederholung NACK" beantworten. Um die Notwendigkeit solcher negativer Rückmeldungen zu umgehen, gibt der System-Controller 110 nicht mehr Anforderungen an das UPA-Slave-Interface aus, als die Warteschlangen des Slave-Interface aufnehmen können. Die vom UPA-Slave-Interface ausgegebene P_REPLY, die bestätigt, daß eine vorangegangene Transaktion vollständig ausgeführt ist, teilt dem System-Controller 110 mit, daß die Warteschlange des Slave-UPA-Port für eingehende Anforderungen wieder eine Anforderung dieser Art aufnehmen kann.
  • Die maximale Größe der Warteschlange 174 für Anforderungen des System- Controllers SREQ-RQ im Slave-Port-Interface 152 ist in der bevorzugten Ausführung auf 1 festgelegt. Bei einem Slave-UPA-Port kann es also höchstens eine anstehende S_REQ geben.
  • Die Nutzung lediglich einer einzigen Warteschlange 174 für eingehende Anforderungen SREQ_RQ, ohne daß dabei die Leistung des Systems beeinträchtigt wird, ist deshalb möglich, weil alle S_REQ-Anforderungen beim Slave-Interface höchste Priorität genießen und so schnell abgearbeitet werden, daß es nicht nötig ist, 5 REQ-Anforderungen in einer Warteschlange zu speichern. In der bevorzugten Ausführung, wie in Fig. 7 dargestellt, ist der Cache-Controller 176 in jedem cachenden UPA-Master-Port 104 eine Zweitor- Steuerungsschaltung, so daß der Cache-Controller Cachezugangs-Anforderungen sowohl vom Datenprozessor 178 des Ports, als auch aus der Anforderungswarteschlange SREQ-RQ entgegennehmen kann, wobei eine SREQ-RQ vor dem Datenprozessor die höhere Priorität genießt. Bei dieser Konfiguration werden SREQs aus der Anforderungswarteschlange 174 für SREQ-RQs im allgemeinen von jedem Slave-Interface innerhalb von 2 bis 5 System- Taktzyklen abgearbeitet. Wurde z. B. eine einzelne Lese-/Modifizier-/ oder Schreib-Operation im Cache-Speicher vom Datenprozessor 178 unmittelbar einen Taktzyklus vor dem Absetzen der SREQ begonnen, dann kann es 3 zusätzliche System-Taktzyklen dauern, bis diese Cache- Transaktion zu Ende geführt ist, danach wird SREQ abgearbeitet, üblicherweise innerhalb von 2 System-Taktzyklen.
  • Zudem kann unter Verwendung der oben beschriebenen Methodologie der Zweitor- Cachesteuerungsschaltung eine Rückkopier-Anforderung von einem Datenprozessor 178 zu einem anderen in ungefähr der gleichen Zeitspanne durchgeführt werden, die für das Laden aus dem Hauptspeicher benötigt wird, wenn beim Verbindungsmodul keine konkurrierende Speichertransaktion anliegt. Konkret dauert in der bevorzugten Ausführung das Laden aus dem Hauptspeicher ca. 8 System-Taktzyklen, und das Rückkopieren vom Cache-Speicher eines Datenprozessors in den Cache-Speicher eines anderen Datenprozessors dauert ebenfalls ca. 8 System-Taktzyklen, wenn keine konkurrierenden Speichertransaktionen anliegen.
  • In den meisten Ausführungen muß jedes UPA-Slave-Interface Paritätskontrollen bei Transaktions-Anforderungen durchführen, die es über den UPA-Adreßbus empfangen hat, und es muß alle Paritätsfehler mit einer P_REPLY-Nachricht für schwerwiegende Fehler melden. Bei den meisten Ausführungen muß jedes UPA-Slave-Interface 152 auch durch eine ECC-Kontrolle bei Schreibtransaktionen feststellen, ob der ECC gültig ist, und es muß Datenfehler protokollieren und melden.
    • Interrupter-Interface
  • Das Vorhandensein eines Interrupter-Interface 154 ist optional. Unterstützt der UPA- Port ein Master-Interface 150, dann kann es von jeder beliebigen Master-Klasse im Master- UPA-Port eine Interrupt-Paket-Transaktion an einen Ziel-Slave-UPA-Port abschicken, der als Interrupt-Handler fungiert.
  • Ein Interrupter-Interface in einem Master-UPA-Port generiert Interrupts, indem es eine P_INT_REQ-Transaktion initiiert (siehe nachfolgendes Kapitel "Transaktionen"). Der Master-UPA-Port generiert ein Interrupt-Paket für einen bestimmten Ziel-UPA-Port, der als Interrupt-Handler fungiert, indem er im Anforderungspaket ein Target-ID< 4 : 0> markiert. Das Target-ID ist das gleiche wie das individuelle 5-Bit UPA_Port_ID des Ziel-UPA-Ports. Ein Interrupt, der von einem UPA-Port an sich selbst abgeschickt wird, wird vom UPA-Interface in der bevorzugten Ausführung aus Gründen, die mit den elektrischen KonnekPortsn zusammenhängen, nicht unterstützt, er könnte aber in anderen Ausführungen der vorliegenden Erfindung unterstützt werden.
  • Das Target-ID eines (oder mehrerer) als Interrupt-Handler fungierender UPA-Ports wird jedem nicht-Prozessor-Interrupter-UPA-Port durch die Initialisierungssoftware des Systems zugeordnet. Der nicht-Prozessor-Interrupter-UPA-Port kann dann Interrupt- Transaktionen nur an die zugeordneten Target-IDs senden. Ein Prozessor-UPA-Port kann Interrupt-Transaktionen an jedes beliebige Interrupt-Handler-Target-ID senden (für Softwareaufrufe von einem Prozessor zum anderen).
  • Das Target-ID< 4 : 0> für jede Interrupt-Transaktions-Anforderung P_INT-REQ wird im physikalischen Adreßfeld PA< 18 : 14> im ersten Zyklus des 2-Zyklen-Jnterrupt-Pakets übertragen (siehe Fig. 9 C). Der UPA-Port kann die P_INT_REQ jeder beliebigen Master- Anforderungs-Klassse zuordnen. Die Zuordnung zu einer bestimmten Klasse ist nicht erforderlich. In der bevorzugten Ausführung wird es jedoch der Klasse 1 zugeordnet, um Transaktionen von Cache-Inhalten nicht zu blockieren.
  • Empfängt der UPA-Port, der die Interrupt-Transaktion initiiert hat, eine Antwortnachricht S_INAK (auch als Antwortnachricht NACK bekannt), dann entfernt der anfordernde UPA-Port die Interrupt-Daten aus seiner Warteschlange für Ausgangsdaten und die Anforderung P_INT_REQ aus der Warteschlange der Master-Anforderungs-Klasse; nach mehreren Back-off-Intervallen wird ein erneuter Versuch unternommen.
  • Empfängt der UPA-Port eine Antwortnachricht S_WAB, die aussagt, daß die 64 Byte der Interrupt-Daten auf dem UPA-Datenbus verschoben werden sollen, dann ist gewährleistet, daß sowohl die P_INT_REQ als auch die Daten vom System-Controller an den Ziel-UPA- Port übertragen werden (wie eine nicht gecachte Block-Schreib-Transaktion), wenn das Ziel ein gültiger Interrupt-Handler ist. Ist das Ziel kein Interrupt-Handler, dann kann es vom System-Controller annulliert (und ein Zustands-Bit gesetzt) werden, oder der Empfänger- UPA-Port kann es (stillschweigend) annullieren.
  • Ein Interrupter kann mehrere "Rücken-an-Rücken" (Back-to-Back) P_INT_REQs mit verschiedenen Ziel-IDs an veschiedene Ziel-UPA-Ports verschicken. Kann das Interrupt- Paket vom System-Controller ausgeliefert werden, dann wird es angenommen. Ansonsten gibt der System-Controller die Nachricht NACK aus.
  • Gibt ein Interrupter mehrere Back-to-Back - P_INT_REQ-Transaktionen an verschiedene UPA-Ports aus, dann ist nicht gewährleistet, daß diese in der Reihenfolge ihrer Ausgabe angeliefert werden. Back-to-Back - P_INT_REQs mit dem selben Ziel-ID werden jedoch vom System-Controller in der Reihenfolge ihrer Ausgabe beim Ziel-UPA-Port angeliefert, vorausgesetzt, daß Interrupt-Anforderungen, die vom System-Controller 110 mit NACK beantwortet werden, vom UPA-Interrupter-Interface noch einmal in ihrer ursprünglichen Reihenfolge ausgegeben werden.
  • Unterstützt der UPA-Port kein Master-Interface, benötigt jedoch ein Interrupt- Interface 154, dann wird das Interrupt-Interface 154 durch eine bestimmte Ader (in Fig. 3 als UPA_Slave_Int_L gekennzeichnet) angeschlossen, um dem System-Controller 110 einen einzelnen Interrupt mit Priorität zu signalisieren. Der System-Controller 110 veranlaßt dann, daß ein Interrupt-Paket generiert und an einen Interrupt-Handler-UPA-Port verschickt wird. In Slave-UPA-Ports mit einem Interrupter-Interface kann kein zweiter Interrupt auf der Leitung UPA_Slave_Int_L abgesetzt werden, bevor der Interrupt-Handler den Interrupt durch einen Slave-Schreibzugriff auf ein vorbestimtes Interrupt-Lösch-Register im Slave- UPA-Port gelöscht hat. Zudem steht für Interrupts, die über die Leitung UPA_Slave_Int_L generiert werden, nur ein einziges Interrupt-Prioritäts-Niveau zur Verfügung.
    • Interrupt-Handler-Interface
  • Ein UPA-Port kann ein Interrupt-Handler 156 sein. Ein UPA-Modul eines Datenprozessors unterstützt normalerweise das Interrupt-Handler-Interface. Um als Interrupt- Handler fungieren zu können muß ein UPA-Port die in Fig. 16 dargestellten Warteschlangen INT und INT_DQ unterstützen. Die Warteschlange für INT-Anforderungen kann maximal 4 Interrupts aufnehmen.
  • Eine sich in der Warteschlange für INT-Anforderungen befindende P_INT_REQ wird vom Prozessor geprüft. In der bevorzugten Ausführung wird eine Unterbrechungs- Steuerungssoftware aktiviert. Nachdem der Interrupt-Handler den Interrupt abgearbeitet hat, veranlaßt sie den UPA-Port, die Antwortnachricht P_REPLY zu generieren, um dem System- Controller anzuzeigen, daß die P_INT_REQ abgearbeitet ist und nun eine weitere P_INT_REQ in der Warteschlange für eingehende Interrupt-Anforderungen aufgenommen werden kann. In der bevorzugten Ausführung wird die P_REPLY generiert, sobald die Software einen Eintrag in das "Interrupt-Lösch-Register" des Interrupt-Handler-Interface schreibt.
    • Register des System-Controllers
  • Wie in Fig. 5 dargestellt verfügt der System-Controller 110 über getrennte Warteschlangen für eingehende Transaktions-Anforderungen in jeder Master-Klasse (SCIQ0, SCIQ1) sowie über eine Warteschlange (SCRQ) für sowohl Anforderungen, die er selbst generiert, als auch Anforderungen, die er an UPA-Ports weitereleitet. Der System-Controller 110 verfügt weiter über ein Register SC ID 180, um den UPA-Ports seine Kapazitäten mitzuteilen, über ein Register SC Config 190, und über ein Array 200 für die Zustände noch nicht abgearbeiteter Transaktionen. Das Register SC Config 190 speichert die Kapazitäten aller UPA-Ports des Systems, und es verfolgt, wie viele Transaktions-Anforderungen gegenwärtig in den Eingangs-Warteschlangen aller UPA-Ports 104 gespeichert sind. Über das Array 200 für die Zustände noch nicht abgearbeiteter Transaktionen verfolgt der System- Controller alle inaktiven und aktiven noch anstehenden Transaktionen.
  • Das Register SC ID 180 hat folgende Felder:
  • - Das Feld ID 181 ist ein 16-Bit Feld, das den System-Controller kennzeichnet.
  • - Das Feld UPANUM 182 ist ein 5-Bit Maskenfeld, das die maximale Anzahl der UPA- Ports anzeigt, die der System-Controller unterstützen kann.
  • - Das Feld SCIQ0[3 : 0] 183 ist ein 4-Bit Feld, das die Anzahl der (2-Zyklen) Anforderungspakete anzeigt, die in der Warteschlange der Klasse 0 für eingehende Anforderungen SCIQ 0 eines bestimmten UPA-Ports gespeichert werden können.
  • - Das Feld SCIQ 1[3 : 0] 184 ist ein 4-Bit Feld, das die Anzahl der (2-Zyklen) Anforderungspakete anzeigt, die in der Warteschlange der Klasse 1 für eingehende Anforderungen SCIQ 1 eines bestimmten UPA-Ports gespeichert werden können. Für jeden Master-UPA-Port gibt es einen eigenen Satz von SCIQ0- und SCIQ1- Registern, um die Größe der Warteschlangen für eingehende Anforderungen SCIQ0 und SCIQ1 jedes solchen Master-UPA-Ports anzuzeigen.
  • Wie in Fig. 6 dargestellt beinhaltet das Register SC Config 190 eine Zeile oder Aufzeichnung 192 für jeden UPA-Port, der vom System-Controller 110 unterstützt werden kann. Die Position einer Zeile im Register SC Config entspricht der Port-ID des zugehörigen UPA-Ports. Die erste Zeile des Registers SC Config 190 enthält die Konfigurationsdaten des UPA-Ports mit der Port-ID 00000, die zweite Zeile enthält die Konfigurationsdaten des UPA- Ports mit der Port-ID 00001, und so weiter. Jede solche Aufzeichnung wird hier eine "Port- Aufzeichnung im Register SC Confg" genannt. Eine Port-Aufzeichnung im Register SC Config 190 hat folgende Felder:
  • - "Kopie des UPA_Port_ID_Reg" 193 ist wortgetreu eine Kopie des Port-ID-Registers des entsprechenden UPA-Ports.
  • - Das Feld Cache Index Maske (CIM) 194 markiert die Anzahl von Block-Einträgen oder Lines eines Etags im kohärenten Cache des entsprechenden UPA-Ports, falls vorhanden. Dieses Feld zeigt dem System-Controller an, wie viele niederwertige Adreßbits der physikalischen Adresse PA[40 : 6] für Adreßvergleiche bei Ausführung des Cachekohärenzproto-kolls zu verwenden sind. Dieses Feld ist nur bei Cache-Master-UPA- Ports gültig.
  • - Das Feld InCnt 195 beinhaltet die Anzahl von Interrupt-Anforderungen, die der System-Controller 110 an den entsprechenden UPA-Port weitergeleitet hat und die noch vom UPA-Port bestätigt werden müssen. Der System-Controller blockiert die Übertragung weiterer Interrupt-Anforderungen an diesen UPA-Port, wenn der in diesem Feld eingetragene Wert dem des Feldes PINT_RDQ[1 : 0] 170 in der Kopie 193 des UPA_Port ID-Registers entspricht.
  • - Das Feld PReqCnt 196 beinhaltet die Anzahl von Port-Transaktions-Anforderungn, die der System-Controller 110 an den entsprechenden UPA-Port weitergeleitet hat und die noch vom UPA-Port bestätigt werden müssen. Der System-Controller blockiert die Übertragung weiterer Port-Transaktions-Anforderung an diesen UPA-Port, wenn der in diesem Feld eingetragene Wert dem des Feldes PREQ_RQ[3 : 0] 166 in der Kopie 193 des UPA-Port-ID-Registers entspricht.
  • - Das Feld SReqCnt 197 beinhaltet die Anzahl von Transaktions-Anforderungen des System-Controllers, die an den entsprechenden UPA-Port verschickt wurden und die noch vom UPA-Port bestätigt werden müssen. Der System-Controller blockiert die Übertragung weiterer System-Controller-Transaktions-Anforderungen an diesen UPA-Port, wenn der in diesem Feld eingetragene Wert 1 ist, da die Kapazität der Warteschlangen der Slave- Interfaces für SREQ nicht größer als 1 ist.
    • Datenfluß
  • In den Fig. 5 und 7 ist der charakteristische Datenfluß beim Lesen von Speichern und Schreiben in Speicher dargestellt. Obwohl in den Figuren nicht eigens gezeigt, hat der System-Controller 110 für jeden Master-UPA-Port einen eigenen Satz von Warteschlangen SCIQ 0 und SCIQ 1 für eingehende Anforderungen. Zudem muß angemerkt werden, daß das Ablaufdiagramm in Fig. 8 nicht alle Schritte aller Datentransfer-Transaktionen beinhaltet. Es zeigt lediglich die Schritte, die bei den meisten Datentransfer-Transaktionen gleich sind. Weitere Einzelheiten aller definierter Datentransfer-Transaktionen sind im Kapitel "Detaillierte Beschreibung von Transaktionen" dargestellt.
  • Der UPA-Master-Port gibt über seinen UPA-Adreßbus eine Lese-/Schreib- Transaktions-Anforderung (P_REQ) an den System-Controller 110 aus (210), die der System- Controller in eine seiner beiden Warteschlangen für eingehende Anforderungen aufnimmt (212). Handelt es sich um eine kohärente Anforderung (214), dann nimmt der System- Controller 110 über den Snoop-Bus eine Dtag-Einsicht (Snoop) vor, auf die eine Dtag- Aktualisierungs-Operation folgt (216). Gleichzeitig mit der Dtag-Einsicht startet der System- Controller einen Speicherzyklus, wenn eine Lese-Transaktion einer im Hauptspeicher gespeicherten Adresse ausgeführt wird (217).
  • Bei einer "Snoop-Operation" wird gleichzeitig auf alle mit dem Snoop-Bus 140 verbundenen Dtag-Arrays 134 zugegriffen um festzustellen, ob in einem oder mehreren der Dtag-Arrays 134 ein gültiger Eintrag für eine bestimmte Adresse gespeichert ist. Jedes Dtag- Array 134 reagiert auf eine Snoop-Operation mit der Ausgabe eines 2-Bit-Zustandswerts sowie eines Hit/kein Hit - Bit. Der von einem Dtag-Array ausgegebene 2-Bit-Zustandswert zeigt nur dann den Zustand eines Dtag an, wenn das Hit/kein Hit - Bit anzeigt, daß im Dtag- Array 134 ein passender Eintrag gefunden wurde. Wird in einem Dtag-Array ein "Hit" aufgespürt, dann nimmt das "Hit"-Bit einen Wert an, der "wahr" anzeigt, und der 2-Bit Dtag- Zustandswert ist nicht gleich 00.
  • In Abhängigkeit von der spezifischen anliegenden Transaktions-Anforderung können, wenn in einem der Dtag-Arrays 134 ein "Hit" aufgespürt wird, Daten aus dem Cache- Speicher eines der Master-UPA-Ports ausgelesen werden, die Cache-Einträge in manchen oder allen der Cache-Speicher, die für diese spezifische Adresse Daten speichern, können ungültig gemacht werden, oder die Tag-Zustände eines oder mehrerer Einträge in den Dtag- Arrays und Etag-Arrays können, wie im folgenden noch beschrieben, auf andere Weise aktualisiert werden.
  • Wird bei einer kohärenten Lese-Transaktion durch die Snoop-Operation festgestellt, daß die Daten aus dem Speicher stammen, weil (A) für die spezifische Adresse in den Dtag- Arrays 134 keine "Hits" ermittelt wurden (222), oder (B) alle den Cache-Hits entsprechenden Dtags sich im nicht modifizierten S- (Shared Clean) Zustand befinden und es sich bei der Transaktion nicht um eine Lesen-zum-Übernehmen (read to own, RDO), Transaktion handelt (223), dann wird vom System-Controller 110 über das Verbindungsmodul 112 ein Datenweg vom Hauptspeicher zum anfordernden UPA-Port angelegt (224). Der System-Controller 110 schickt eine S_REPLY-Nachricht an den anfordernden UPA-Port (226), wenn gemäß der vergangenen Zeit der anfordernde UPA-Port den der bestimmten Adresse entsprechenden Datenblock erhalten haben müßte (228).
  • Eine kohärente Leseoperation vom Cache eines anderen UPA-Port ist dann nötig, wenn ein Cache-Hit für einen Cache-Speicher in einem Datenprozessor festgestellt wurde (222), der nicht der anfordernde Prozessor ist, und wenn entweder (A) das Dtag des nicht anfordernden Datenprozessors sich im Zustand O oder M befindet und der Datenblock als modifiziert gekennzeichnet ist, oder (B) die Lesetransaktion eine "Lesen-zum-Übernehmen"- Transaktion (P_RDO_REQ) (223) ist.
  • Stellt der System-Controller fest (222, 223), daß ein Datenblock aus dem Cache eines anderen UPA-Port entnommen werden muß, dann sendet der System-Controller 110 eine Rückkopier-Anforderung S_REQ an das Slave-Interface des Quell-UPA-Ports und bricht den Speicherzyklus ab (240). In Systemen mit mehr als zwei Datenprozessoren sendet der System-Controller auch eine Invalidierungs-Transaktions-Anforderung (S_INV_REQ) an alle cachenden UPA-Master-Ports außer dem Quell-UPA-Port, für die ein Cache-Hit ermittelt wurde (240).
  • Stehen die Daten bereit, dann gibt der Slave-UPA-Port eine P_REPLY an den System- Controller 110 aus (242). Der System-Controller 110 verschickt dann Steuersignale an das Verbindungsmodul 112, um einen Datenweg vom Quell-UPA-Port zum anfordernden UPA- Port zu bilden (244). Der System-Controller 110 verschickt auch eine S_REPLY an das Slave-Interface des Quell-UPA-Ports, damit dieser die angeforderten Daten auf den UPA- Datenbus verschiebt, und er verschickt eine S_REPLY an den anfordernden UPA-Master-Port (246), damit dieser die Daten von seinem UPA-Datenbus entnehmen kann (228).
  • Bei einer typischen kohärenten Schreib (P_WR_REQ) - Transaktion werden vom System-Controller Invalidierungs-Anforderungen an die Cache-Speicher verschickt, in denen Datenblöcke gespeichert sind, die mit dem, der in den Hauptspeicher geschrieben wird, identisch sind (218). Der System-Controller verschickt auch eine S_REPLY an den anfordernden UPA-Port (230), damit dieser die Daten für die Schreiboperation zur Verfügung stellt (232), nachdem vom System-Controller 110 über das Verbindungsmodul 112 ein Datenweg vom anfordernden UPA-Port zum Hauptspeicher hergestellt und der Hauptspeicher º dafür vorbereitet wurde, die Daten einzuschreiben (220).
  • Rückschreibe-Transaktionen (P_WRB_REQ) werden anders behandelt als andere kohärente Schreib-Transaktionen. Erweist sich durch die Einsichtnahme in die Dtags (Snoop), daß das Dtag, das der Adresse der Rückschreibe-Transaktions-Anforderung entspricht, ungültig ist (250), dann bedeutet das, daß ein anderer Datenprozessor eine Transaktion durchgeführt hat, die das Ungültigmachen des mit dieser Adresse versehenen Datenblocks erforderte. In diesem Falle wird die Rückschreibe-Transaktion vom System-Controller aufgehoben, indem dieser eine Rückschreibe-Lösch-Antwortnachricht (S_WBCAN) an den anfordernden UPA-Port schickt (251); woraufhin der anfordernde UPA-Port den Inhalt seines Rückschreibe-Puffers 280 ungültig macht (siehe Fig. 9).
  • Wird die Rückschreibe-Transaktion nicht gelöscht (250), dann stellt der System- Controller einen Datenweg vom anfordernden UPA-Port zum Hauptspeicher her (252) und verschickt eine Bestätigungsnachricht für das Schreiben des Blocks (S_WAB) an den anfordernden Datenprozessor (253), die diesen anweist, den Datenblock an den Hauptspeicher auszugeben (253, 254).
  • Wie in Fig. 8D dargestellt, werden bei einer Dtag-Aktualisierung (216) neue Dtag- Werte meist in dem Dtag-Eintrag gespeichert, der bei einer Dtag-Einsichtnahme gelesen wird. Bezüglich Lese/Rückschreib-Transaktionspaaren gibt es jedoch zwei Ausnahmen.
  • Ist bei einer Dtag-Aktualisierung für eine Rückschreibe-Transaktion im temporären Puffer des Dtag DtagTB für den anfordernden Prozessor gerade ein gültiger Wert gespeichert (255), dann bedeutet das, daß die mit der aktuellen Rückschreibe-Transaktion verbundene Lese-Transaktion zu Ende geführt ist (d. h. sie wurde vor der Rückschreibe-Transaktion beendet). In diesem Falle wird durch die nach der Rückschreibe-Transaktion durchgeführte Dtag-Aktualisierung (256) der Inhalt des DtagTB in das Dtag übertragen, das der in der Rückschreibe-Anforderung enthaltenen Adresse entspricht. Enthält der DtagTB gerade keinen gültigen Wert (255), dann bedeutet das, daß die damit verbundene Lesetransaktion noch nicht zu Ende geführt ist. In diesem Falle wird durch die Dtag-Aktualisierung für die Rückschreibe- Transaktion das Dtag ungültig gemacht, das der in der Rückschreibe-Transaktions- Anforderung enthaltenen Adresse entspricht.
  • Es ist zu beachten, daß, wenn beim Löschen einer Rückschreibe-Transaktion das Bit für "DtagTB gültig" auf "wahr" gesetzt wird, bei der Dtag-Aktualisierung weiterhin der Inhalt des DtagTB in das Dtag der entsprechenden Cache-Line kopiert wird. Die Dtags für alle anderen Datenprozessoren werden weder geprüft, noch durch die Rückschreibe-Transaktiongeändert.
  • Beim Durchführen der Dtag-Aktualisierung für eine Lese-Transaktion wird, wenn das Bit DVP (dirty victim pending) auf "1" gesetzt und die Einsichtnahme in die Dtags für den anfordernden Prozessor anzeigt, daß die entsprechende Rückschreibe-Transaktion noch ansteht (also der Dtag-Zustand für den angeforderten Datenblock nicht gleich I ist) (258), der neue Dtag-Zustand für den angeforderten Datenblock im temporären Puffer des Dtag (DtagTB) gespeichert, bis die Rückschreibeaktion durchgeführt ist (259a). Im anderen Falle (also wenn der Dtag-Zustand für den angeforderten Datenblock gleich I ist) ist die Rückschreibe-Transaktion vor der Lese-Transaktion durchgeführt worden, und der durch die Transaktion hervorgerufene neue Dtag-Wert wird direkt in das Dtag für den angeforderten Datenblock geschrieben (259b).
  • Bei Transaktionen des Typs "Lesen zum Verwerfen" wird keine Dtag-Aktualisierung durchgeführt, da diese Transaktionen den Inhalt der Cache-Speicher von UPA-Modulen nicht beeinflussen. Dementsprechend sollte das DVP-Bit bei Transaktionen des Typs "Lesen zum Verwerfen" nicht gesetzt werden, da durch solche Transaktionen keine Datenblöcke in Cache- Speichern ersetzt werden.
  • In Fig. 8A und 8B ist eine typische nicht gecachte Slave-Lese-Sequenz von einem anderen UPA-Port dargestellt, die folgendermaßen vor sich geht. Der UPA-Master-Port gibt über seinen UPA-Adreßbus eine Leseanforderung (P_REQ) an den System-Controller 110 aus (210, 212). Nachdem er die Adresse dekodiert und festgesellt hat, daß diese sich nicht im kohärenten Bereich befindet (214), verschickt der System-Controller 110 die P_REQ über den UPA-Adreßbus des Ziel-UPAs (nachdem er den Zugriff auf diesen angefordert hat) an das Slave-Interface des Ziel- (adressierten) UPA-Ports (260). Sobald die angeforderten Daten zur Übertragung bereitstehen gibt der Ziel-UPA-Port die Nachricht P_REPLY an den System- Controller 110 aus (261). Der System-Controller 110 stellt im Verbindungs-Modul 112 einen Datenweg vom Ziel-UPA-Port zum anfordernden UPA-Port her (262), gibt die Nachricht S_REPLY an den Ziel-UPA-Port aus, damit dieser die angeforderten Daten auf seinen UPA- Datenbus verschiebt, und gibt die Nachricht S_REPLY and den anfordernden UPA-Master- Port aus (263), damit dieser die Daten über seinen UPA-Datenbus in Empfang nimmt (264).
  • Eine typische nicht gecachte Slave-Schreib-Sequenz an einen anderen UPA-Port geht folgendermaßen vor sich. Der UPA-Master-Port gibt über seinen UPA-Adreßbus eine Schreib-Anforderung (P_REQ) an den System-Controller 110 aus (210, 212). Nachdem er die Adresse dekodiert und festgesellt hat, daß diese sich nicht im kohärenten Bereich befindet (214), verschickt der System-Controller 110 die P_REQ an den UPA-Port, an den sich die Anforderung richtet, über den UPA-Adreßbus dieses Ports (nachdem er den Zugriff auf diesen angefordert hat) (250). Der System-Controller 110 stellt im Verbindungs-Modul 112 einen Datenweg vom anfordernden UPA-Port zum Ziel-UPA-Port her (266), gibt die Nachricht S_REPLY an den anfordernden Master-Port aus, damit dieser die angeforderten Daten auf seinen UPA-Datenbus verschiebt, und gibt die Nachricht S_REPLY and den Ziel-UPA-Port aus, damit dieser die Daten über seinen UPA-Datenbus in Empfang nimmt (267). Der anfordernde Master-Port bewertet die Transaktion als vollendet, wenn er die Nachricht S_EPLY erhalten und die Daten übertragen hat. Der Ziel-UPA-Port gibt jedoch die Nachricht P_REPLY aus, wenn er die ausgegebenen Daten fertig verarbeitet hat (268), was zum Zwecke der Flußkontrolle wichtig ist, da die P_REPLY dem System ermöglicht, seinen Zählerstand PReqCnt für Anforderungen, die in den Warteschlangen des UPA-Port-Slaves für eingehende Anforderungen und Daten anstehen, zu vermindern.
  • Es ist anzumerken, daß, da die Adreß- und Datenwege voneinander unabhängig sind, und da die Slave-Interfaces der UPA-Ports Warteschlangen sowohl für eingehende Anforderungen und eingehende Daten beinhalten, das Anforderungs-Paket und die diesem entsprechenden Daten in beliebiger Reihenfolge an das Slave-Interface des UPA-Ports übertragen werden können, d. h. die Daten können vor der Adresse übertragen werden und umgekehrt. Werden die Daten dem Slave-Interface vor dem entsprechenden Anforderungs- Paket angeliefert, dann stehen die angelieferten Daten einfach so lange in der Warteschlange des Slave-Interfaces für eingehende Daten an, bis das Slave-Interface bereit ist, diese zu verarbeiten.
  • Hat das Slave-Interface die Daten und die Transaktions-Anforderung aus seiner Warteschlange genommen, dann gibt es die Nachricht P_REPLY and den System-Controller 110 aus, um anzuzeigen, daß es für eine weitere Slave-Transaktion bereit ist. An diesem Punkt betrachtet der System-Controller 110 die Transaktion als vollendet.
  • Zur Flußkontrolle gehört, daß das Quell-Bauelement (A) die maximale Größe der stromabgelegenen Warteschlange immer im voraus kennt, und (B) die verbleibende Kapazität in dieser Warteschlange überwacht. Die Maximalgröße der Warteschlangen wird von der Initialisierungs-Software beim Systemstart statisch festgelegt, von den UPA-Port-ID- Registern 158 für alle UPA-Ports, und vom SC-ID-Register 180 im System-Controller, und werden in die Flußkontroll-Register für die stromaufgelegene Warteschlange geschrieben. Die Flußkontroll-Register im System-Controller sind (A) die Größenparameter der Warteschlange PREQ_RQ und PINT_RDQ, die in der Kopie 193 des UPA-Port-ID-Registers im System- Controller gespeichert sind, und (B) die Zähler IntCnt, PReqCnt und SReqCnt 194, 195 und 196 im Register SC Config 190. Weitere Flußkontroll-Register im System sind die Register 270, 272 im Master-Interface 150 des UPA-Ports. Im Einzelnen schließt, wie in Fig. 5 zu sehen ist, jedes Master-Interface 150 jedes UPA-Ports 104 zwei Register 270-0, 270-1 mit ein, die die Größen der Anforderungs-Warteschlangen der Master-Klassen C0 und C1 für diesen UPA-Port im System-Controller anzeigen, und zwei Zähler 272-0, 272-1, die die Anzahl gegenwärtig anstehender Anforderungen in jeder der beiden Anforderungs- Warteschlangen der beiden Master-Klassen anzeigen. Die Werte für die Größen der Warteschlangen im SC-ID-Register SCIQ0, SCIQ1 (183, 184) für jeden UPA-Master-Port werden in die Größenregister 270 jedes entsprechenden UPA-Port-Master-Interfaces beim Systemstart durch die Initialisierungssoftware kopiert.
  • Die Ausgangswarteschlangen für Daten und Anforderungen unterliegen keinen bestimmten Einschränkungen bezüglich der Größe oder sonstigen Anforderungen, mit der Ausnahme, daß jede solche Warteschlange groß genug sein muß, um die maximale Anzahl von Anforderungen oder Datenpaketen aufzunehmen, die das entsprechende Bauelement entgegennehmen kann. Ferner sind diese Größenwerte, da die Größen der Warteschlangen für ausgehende Daten und Anforderungen für andere Bauelemente im System zum Zwecke der Flußkontrolle nicht relevant sind, nicht in den Konfigurationsregistern vermerkt, auf die die Initialisierungssoftware zugreift.
  • Nach der Software-Initialisierung gibt die nächstgelegene Warteschlange nicht mehr Anforderungen an die unmittelbar unter ihr gelegene Warteschlange aus, als diese ihrer Kapazität nach aufnehmen kann. Eine S_REPLY vom System-Controller 110 an den UPA- Port zeigt dem UPA-Port an, daß der System-Controller 110 in der entsprechenden Warteschlange einen Platz für eine weitere Anforderung frei gemacht hat und für eine weitere Master-Anforderung für diese Warteschlange bereit ist. Eine P_REPLY von einem UPA-Port an den System-Controller 110 zeigt diesem an, daß der UPA-Slave-Port in seiner entsprechenden Warteschlange einen Platz für eine weitere Anforderung frei gemacht hat und für eine weitere Slave-Anforderung bereit ist.
  • Ein stromaufgelegenes Bauelement wie z. B. ein UPA-Port kann, ohne auf eine Antwortnachricht warten zu müssen, in schneller Folge eine Reihe von Transaktionen übermitteln, bis die Kapazität einer stromabgelegenen Warteschlange erreicht ist, dann muß es wenigstens eine S_REPLY oder P_REPLY abwarten, bevor weitere Anforderungen an die stromabgelegene Warteschlange übermittelt werden.
  • Die Flußkontrolle ist in Fig. 5 graphisch dargestellt. Die Warteschlangen für eingehende Anforderungn SCIQ0 und SCIQ1 des System-Controllers 110 sind in Bezug auf die Anforderungs-Warteschlangen der UPA-Master-Klassen C0 und C1 stromabgelegen (umgekehrt betrachtet sind C0 und C1 stromaufgelegen). Dementsprechend sind alle Warteschlangen im UPA-Slave-Interface für den System-Controller 110 stromabgelegen.
    • Übersicht über das Cachekohärenz-Modell
  • Das in der vorliegenden Erfindung verwendete Cachekohärenz-Protokoll ist ein Modell der Punkt-zu-Punkt Schreib-Invalidierung. Es basiert auf den 5 "MOESI"-Zuständen, die in den Cache-Tags (Etags) eines cachenden UPA-Master-Ports gespeichert sind. (In einer weiteren Ausführung der Erfindung werden, wie im folgenden noch beschrieben wird, vier "MESI"-Zustände Für Systeme verwendet, die mit dem Protokoll der "reflektierenden Speicher" arbeiten). Das Cachekohärenz-Protokoll funktioniert nur mit physikalisch indizierten Caches mit physikalischen Identifizierungskennzeichen (Physically Indexed Physically Tagged, PIPT). Der UPA-Cachekohärenz-Bereich ist auf die physikalisch adressierten Caches beschränkt. Ein virtuell adressierter Primär-Cache, falls vorhanden, muß vom UPA-Modul selbst kohärent gehalten werden. Ein Etag hat folgende Cache-Zustände (Wechsel eines Etag-Zustands siehe Fig. 10):
  • - Invalid (I): Der Cache-Index und der Inhalt der Cache-Line sind ungültig.
  • - Shared Clean (S): Der Datenblock, der in der diesem Etag entsprechenden Cache-Line gespeichert ist, wurde (A) von dem an diesen Cache gekoppelten Datenprozessor nicht modifiziert, und kann (B) in einem oder mehreren weiteren Cache-Speichern gespeichert werden.
  • - Exclusive Clean (E): Der Datenblock, der in der diesem Etag entsprechenden Cache- Line gespeichert ist, wurde nicht von dem an diesen Cache gekoppelten Datenprozessor modifiziert und ist in keinem weiteren Cache-Speicher gespeichert.
  • - Shared Modified (O): Der Datenblock, der in der diesem Etag entsprechenden Cache- Line gespeichert ist, wurde von dem an diesen Cache gekoppelten Datenprozessor modifiziert und kann in einem oder mehreren weiteren Cache-Speichern gespeichert werden.
  • - Exclusive Modified (M): Der Datenblock, der in der diesem Etag entsprechenden Cache-Line gespeichert ist, wurde von dem an diesen Cache gekoppelten Datenprozessor modifiziert und ist in keinem weiteren Cache-Speicher gespeichert.
  • In einer weiteren Ausführung der vorliegenden Erfindung wird, für Systeme, die mit Protokollen der "reflektierenden Speicher" arbeiten, werden nur 4 "MESI" Zustände verwendet. Der O-Zustand wird deshalb nicht benötigt, weil in einem reflektierenden- Speichersystem immer dann, wenn ein erster Datenprozessor für einen Datenblock, der im Cache eines zweiten Datenprozessors im M-Zustand (Exclusive Modified) gespeichert ist, einen Cache-Miss verzeichnet, bei der Rückkopier-Operation, durch die der Datenblock vom zweiten in den ersten Datenprozessor kopiert wird, auch der modifizierte Datenblock in den Hauptspeicher kopiert wird. Im Falle einer regulären Rückkopier-Operation ist bei Beendigung der Transaktion der Datenblock in beiden Datenprozessoren im S- (Shared Clean) Zustand gespeichert. Im Falle einer Rückkopier- und Invalidierungs-Operation befindet sich das Etag des anfordernden Datenprozessors für diesen Datenblock im E- (Exclusive Clean) Zustand, und das entsprechende Etag des anderen Datenprozessors ist ungültig. In einem Multiprozessor-System mit reflektierenden Speichern wird ein Datenblock also nie geteilt, solange er sich in einem modifzierten Zustand befindet. Die Eliminierung des O-Zustandes wird dem Datenprozessor vom System-Controller durch eine bestimmte Rückkopier-Transaktion angezeigt, die S_CPB_MSI_REQ heißt (an Stelle von S_CPB_REQ) und den Datenprozessor veranlaßt, die M &rarr; 5 -Umwandlung anstatt der M &rarr; O - Umwandlung durchzuführen.
  • Die Einheit der Cachekohärenz ist eine Blockgröße von 64 Bytes. Bei kohärenten Lese-/Schreib-Transaktionen werden Daten ausschließlich in Blöcken von 64 Bytes unter Verwendung von 4 Quad-Wörtern übertragen
  • Es gibt keine Anforderung an die Mindest- oder Höchstgröße eines Caches. Die Größe des Caches in einem UPA-Master-Port wird durch die Initialisierungssoftware des Systems bestimmt, und die Anzahl der Bits im Cache-Index wird in eine Cache-Index-Maske (CIM) 194 im Register SC Config 190 des System-Controllers geschrieben.
  • Der System-Controller 110 (SC) hält die Cachekohärenz von UPA-Master-Caches aufrecht, indem er in Reaktion auf Lese- oder Schreibzugriff auf geteilte oder modifizierte Datenblöcke anderer UPA-Ports Rückkopier-Invalidierungs-Transaktionen an spezifische UPA-Ports übermittelt. Wird ein Datenblock von einem UPA-Port zum ersten Mal angesteuert, dann wird der Datenblock diesem UPA-Port exklusiv zugeordnet, so daß er später direkt von diesem UPA-Port beschrieben werden kann, ohne daß dieser beim Verbindungsmodul den Schreibzugriff anfordern muß. Wird dieser Block später von einem anderen UPA-Port angesteuert, dann schickt der System-Controller 110 die entsprechende Rückkopier-Invalidierung an den ersten UPA-Port und führt einen Cache-zu-Cache Datentransfer zum anfordernden UPA-Port durch. Allgemein gewährleistet der System- Controller 110 den exklusiven Besitz von Speicherinhalten, indem alle weiteren Kopien der Daten ungültig gemacht werden, bevor dem anfordernden UPA-Master-Port der Schreibzugriff gestattet wird, und bei jedem nachfolgenden Laden oder Speichern durch jeden anderen UPA-Master-Port wird immer auf den aktuellen Wert dieser Daten zugegriffen, ungeachtet dessen, welcher Master diese Daten zuletzt gespeichert hat.
  • In einer weiteren "Ausführungs-" Variante ist es dem die Speicherung ausführenden Prozessor gestattet fortzufahren, noch bevor alle andern Kopien ungültig gemacht sind. In einer solchen Ausführung können sich anderen Prozessoren in ihren Caches vorübergehend weiterhin die alten Werte zeigen, bis die anstehende Invalidierungs-Transaktion wirksam wird. Die Speicher-Misses von Prozessoren mit anstehenden Invalidierungen werden jedoch verzögert, und das Verbindungsmodul hält sie so lange zurück, bis die Invalidierungen in diesen Prozessoren vollendet sind. Durch diese Verbesserung muß der System-Controller nicht warten, bis alle Invalidierungs-Antwortnachrichten eingegangen sind. Aber auch in dieser verbesserten Version sind Speicherinhalte immer noch exklusiv (d. h. nur ein Prozessor kann zu einem Zeitpunkt einen Cache-Block beschreiben), und es gibt zu keiner Zeit vorübergehende Zustände zwischen zwei Speicherungen des selben Datenblocks durch zwei Prozessoren.
  • Wie in den Fig. 7 und 9 zu sehen ist beschränkt das Cachekohärenz-Protokoll der vorliegenden Erfindung anstehende Rückkopier-Invalidierungs-Transaktionen vom System- Controller 110 zum UPA-Port auf eine Transaktion pro UPA-Port, und der UPA-Port muß die Anforderung mit hoher Priorität abarbeiten, indem er dieser den Vorzug vor dem lokalen Zugriff auf den kohärenten Cache einräumt.
  • Das Cachekohärenz-Protokoll unterstützt Writeback-Caches und beschränkt anstehende Dirty-Victim-Rückschreibe-Transaktionen auf eine solche Transaktion pro UPA- Port. Um die Bearbeitung des UPA-Ports von zum Dirty Victim gewordenen Lines zu vereinfachen, die im kohärenten Bereich gespeichert bleiben müssen, bis die Rückschreibe- Transaktion beendet ist, gestattet das Cachekohärenz-Protokoll dem UPA-Master-Port nicht, die Rückschreibe-Transaktion zu widerrufen, wenn das Dirty Victim vor deren Beendigung ungültig gemacht wird. Statt dessen ist der System-Controller dafür zuständig zu veranlassen, daß das Rückschreiben abgebrochen (gelöscht) werden muß, wenn die Rückschreibe- Transaktion auftaucht.
  • In einer weiteren Ausführung wird das gleichzeitige Ausführen mehrerer Rückschreibe-Transaktionen unterstützt, indem in den Prozessoren mehrere Rückschreibe- Puffer sowie eine gleich große Anzahl von temporären Dtag-Puffern im System-Controller vorhanden sind. Das Protokoll ist auch für das gleichzeitige Ausführen mehrerer Rückschreibe-Transaktionen verwendbar. In der bevorzugten Ausführung wird nur mit einer anstehenden Rückschreibe-Transaktion gearbeitet, weil der bevorzugte Datenprozessor nicht mehrere anstehende Cache-Miss-Transaktionen ausgibt. Für die alternative Ausführung müßte ein Datenprozessor verwendet werden, der mit mehreren anstehenden Cache-Misses arbeitet. Um in Multiprozessor-Systemen Snoop-Interferenzen mit dem Zugriff eines Prozessors auf seinen kohärenten Cache zu vermeiden wird vom System-Controller 110 für jeden cachenden Master-UPA-Port eine Kopie des Cache-Indexes (genannt Dtag-Index) unterhalten, in der die Dtag-Anordnung (Dtags) kopiert ist, die eine Spiegelung der Etags des UPA-Ports darstellt. Die Dtags verwenden 4 "MOSI"-Cache-Zustände, wobei die E- und M- Zustände der Etags zusammengeführt sind. Die Dtags unterstützen Direct-Mapped-Caches. Für jeden Etag-Eintrag gibt es einen entsprechenden Dtag-Eintrag, so daß bei einer Einsichtnahme in die Dtags durch den System-Controller 110 der Zustand des entsprechenden Etags für einen Datenblock korrekt angezeigt wird, ohne daß dabei der Zugriff eines Prozessors auf seine Etags gestört wird. Die Dtags können folgende Zustände einnehmen:
  • - Invalid (I): Die Inhalte von Cache-Index und Cache-Line sind ungültig.
  • - Shared Clean (S): Der in der Cache-Line, die diesem Etag entspricht, gespeicherte Datenblock wurde (A) von dem an diesen Cache gekoppelten Datenprozessor nicht modifiziert, und kann (B) in einem oder mehreren weiteren Cache-Speichern gespeichert sein.
  • - Shared Modified (O): Der in der Cache-Line, die diesem Etag entspricht, gespeicherte Datenblock wurde von dem an diesen Cache gekoppelten Datenprozessor modifiziert und kann in einem oder mehreren weiteren Cache-Speichern gespeichert sein.
  • - Exclusive and Potentially Modifed (M): Der in der Cache-Line, die diesem Etag entspricht, gespeicherte Datenblock kann von dem an diesen Cache gekoppelten Datenprozessor modifiziert worden sein und ist in keinem weiteren Cache-Speicher gespeichert.
  • Der E-Zustand wird in den Dtags aus folgendem Grund nicht verwendet. Wenn ein Datenprozessor einen Cache-Miss verzeichnet und mit der "Lesen-zum-Übernehmen" Transaktions-Anforderung Daten anfordert, dann empfängt der UPA-Port des Datenprozessors das angeforderte Datenpaket und setzt seinen Etag-Zustand auf M, während das entsprechende Dtag vom System-Controller ebenfalls auf den Zustand M gesetzt wird. Der System-Controller "nimmt" also "an", daß der Datenprozessor den angeforderten Datenblock modifizieren wird und speichert für die Cache-Line einen Zustandswert ab, der anzeigt, daß der Datenblock modifiziert worden ist, noch der Datenprozessor den angeforderten Datenblock tatsächlich modifiziert haben kann. Daraus folgt, daß, wenn ein Datenprozessor einen Datenblock modifiziert, den er auf eine Transaktionsanforderung P_RDO_REQ erhalten hat, dann ist es nicht nötig, daß er eine Transaktion an den System- Controller verschickt, da im entsprechenden Dtag des System-Controllers für die Cache-Line · schon der M-Zustand verzeichnet ist. Hinzu kommt, daß, wenn aufgrund einer fehlgeschlagenen Ladeanforderung ein Datenblock im Cache eines anfordernden Datenprozessors mit einem Etag im E-Zustand und einem Dtag im M-Zustand abgespeichert wird, der Datenprozessor keine Transaktionsanforderung an den System-Controller ausgibt, wenn er den Datenblock danach modifiziert, weil sich das Dtag schon im M-Zustand (Exclusive Modified) befindet. Das Integrieren des E-Zustands des Dtags in den M-Zustand wird hier als "first write" - Verbesserung bezeichnet, hierdurch wird die Anzahl der Transaktionen, die von jedem Datenprozessor generiert werden müssen, erheblich reduziert.
  • Wie oben beschrieben wird in Systemen, die das Protokoll der "reflektierenden Speicher" verwenden, der O-Zustand nicht benötigt, da ein modifzierter Datenblock niemals geteilt wird. Daraus folgt, daß in einem Multiprozessor-System mit reflektierenden Speichern für Dtags nur 3 "MSI"-Zustände verwendet werden.
  • Der System-Controller unterstützt das Cachen durch einen Ein-/Ausgabe-UPA-Port. Hat der Ein-/Ausgabe-UPA-Port z. B. N voll assoziative Cache-Puffer, dann hat der System- Controller eine entsprechende Anzahl voll assoziativer Dtags. Die Unterstützung des Cache- Speichers eines Ein-/Ausgabe-UPA-Ports durch den System-Controller ist von den Ein- /Ausgabebussen und der mit dem Ein-/Ausgabe-UPA-Port verbundenen Ein-/Ausgabe unabhängig.
  • Wie in Fig. 9 zu sehen ist verfügt die vorliegende Erfindung über einen speziellen Mechanismus für das Rückschreiben verschobener Cache-Datenblocks, genannt "Dirty Victims", wobei sich "dirty" auf den Umstand bezieht, daß der verschobene Datenblock modifizierte Daten enthält, die von dem mit dem UPA-Port verbundenen Datenprozessor geschrieben wurden, und "Victim" sich auf das Verschieben eines Cache-Datenblocks beim Zugriff des Datenprozessors auf andere Daten bezieht, die in der selben Cache-Line abgebildet sind wie der Datenblock, der verschoben wird. Der Cache-Rückschreibe- Mechanismus der vorliegenden Erfindung macht es möglich, daß die Rückschreibe- Transaktion unabhängig von der Transaktion durchgeführt wird, mit der ein neuer Datenblock in der Cache-Line gespeichert wird, die vorher durch das Dirty Victim besetzt war, wodurch die üblicherweise mit Rückschreibe-Transaktionen verbundenen Anforderungen an die Reihenfolge vermieden werden.
  • In Fig. 9 sind die Etags 132 des Prozessors dargestellt, sowie der eine Rückschreibe- Puffer 280 des Prozessors, die kopierten Einträge in den Dtag-Arrays des System-Controllers 110, und die temporären Dtag-Puffer (DtagTBs) 282 innerhalb des System-Controllers für jeden cachenden UPA-Master-Port. Der DtagTB fungiert als der n+1ste Dtag-Eintrag (wobei n die Anzahl der Etag-Einträge im Etag-Array ist) und speichert vorübergehend den Dtag- Zustand für einen neuen Cache-Block, wenn ein Cache-Miss einen "dirty" Block aus dem Cache verschiebt. Die Cache-Fill (Lese-) Transaktion wird unabhängig von der Rückschreibe- Transaktion des Dirty Victim durchgeführt, um unerwünschte Cache-Misses zu minimieren.
  • Wird die Lese-Transaktion zuerst beendet, dann wird die Information über den entsprechenden neuen Dtag-Zustand im DtagTB gespeichert. Sobald dann die Rückschreibe- Transaktions-Anforderung für den Dirty-Victim-Block ausgeführt ist und die Dtag- Aktualisierung für die Rückschreibe-Transaktion durchgeführt wird, wird der Inhalt des DtagTB auf den Dtag-Eintrag für die entsprechende Cache-Line für diesen Prozessor übertragen. Die Übertragung vom DtagTB auf das Dtag ist eine Dtag-Aktualisierung. Wird die Rückschreibe-Transaktion zuerst beendet, dann wird der DtagTB nicht benötigt.
  • Immer dann, wenn das dem DtagTB entsprechende Zustandsbit gesetzt wird, wird der DtagTB in alle Dtag-Einsichtnahmen und alle Dtag-Aktualisierungen mit eingeschlossen. Es ist beispielsweise möglich, daß eine durch eine Cache-Fill-Operation aktualisierte Cache-Line durch eine nachfolgende Transaktion modifiziert oder ungültig gemacht wird, allerdings noch bevor die entsprechende Rückschreibe-Transaktion durchgeführt ist. Deshalb wird der DtagTB in jeder Hinsicht genauso behandelt, wie jeder andere Dtag-Eintrag, wenn das zugehörige Zustandsbit gesetzt ist und die ausgeführte Transaktion keine Rückschreibe- Transaktion ist. Die Dtag-Aktualisierung für eine Rückschreibe-Transaktion bedingt, wie oben dargestellt, daß der Inhalt des DtagTB in das reguläre Dtag-Array übertragen wird.
  • In Fig. 9 sind zwei Datenprozessoren 102-1 und 102-k zu sehen, die den selben Datenblock A cachen. Bei Prozessor 1 ist Block A im O-Zustand (shared modified), und bei Prozessor k ist er im S-Zustand (shared clean). Prozessor 1 mach Block A für einen neuen Datenblock B zum Victim und verschiebt den "dirty" Block A in seinen Rückschreibe-Puffer 280-1, damit er in den Speicher geschrieben wird. Der System-Controller 110 hält den Dtag- Zustand für Block B im DtagTB 282-1 fest, kennzeichnet den Puffer 282-1 als gültig und wartet auf die Rückschreibe-Transaktion. Sollte Prozessor k ebenfalls Block A für Block B zum Victim machen, dann würde in den Etags und in den Dtags für Prozessor k Block A einfach durch Block B überschrieben werden, und der Rückschreibe-Puffer sowie der DtagTB in Prozessor k würden nicht für eine Transaktion verwendet werden, da die Victim-Cache- Line in Prozessor leer wäre.
  • Im folgenden ist eine Beispielsequenz für Ereignisse in einem System dargestellt, in dem das Cachekohärenz-Protokoll der vorliegenden Erfindung sowie die zentralen Tag- Kopien wie in Fig. 9 dargestellt verwendet werden.
  • Wie in Fig. 8 gezeigt gibt ein UPA-Master-Port ein Signal aus, um die Zuteilung des UPA-Adreßbusses anzufordern (vorausgesetzt, daß ein gemeinsamer UPA-Adreßbus verwendet wird). Der UPA-Master-Port erhält schließlich die Buszuteilung und schiebt ein Anforderungspaket auf den UPA-Adreßbus (210).
  • Der System-Controller 110 empfängt die Anforderung (212), entschlüsselt die Transaktionsart und die im Anforderungspaket enthaltene physikalische Adresse und bestimmt, ob es sich um eine kohärente Lese- oder Schreib-Transaktions-Anforderung handelt (214), der System-Controller nimmt für eine Einsichtnahme die vollständige Adresse in der Snoop-Pipeline auf (216). Die Transaktion zählt nun als aktiviert, und sie bleibt aktiv, bis die mit ihr einhergehende Aktualisierung für diese Transaktion beendet ist und die Nachricht S_REPLY an den anfordernden UPA-Master-Port verschickt wird. Solange die Transaktion aktiv ist verhindert der System-Controller, daß weitere eingehende Transaktionen mit dem gleichen Cache-Index aktiv werden. Das Blockieren von Transaktionen wird im nachfolgenden Kapitel "Aktivierung von Transaktionen" noch ausführlich beschrieben.
  • Befindet sich die in der kohärenten Transaktion angegebene Adresse im Hauptspeicher, dann initiiert der System-Controller auch den Speicherzyklus (217). Befindet sich die angegebene Adresse nicht im Hauptspeicher, dann wird die kohärente Transaktion mit einer Fehlermeldung beendet.
  • Der System-Controller führt alle Ergebnisse der Einsichtnahme in die Dtags zusammen und legt im nächsten Zyklus fest, wo die Daten für ein Lese-Transaktion entnommen werden (222, 223). Sind die Daten dem Hauptspeicher zu entnehmen, dann fährt der System-Controller mit dem Speicherzyklus fort. Sind die Daten dem Cache eines anderen Master-UPA-Ports zu entnehmen, dann bricht der System-Controller den Speicherzyklus ab und sendet eine S_REQ an mindestens einen der UPA-Ports, die über eine Kopie der angeforderten Cache-Line verfügen (240). Die Art der einem Quell-UPA-Port übermittelten S_REQ hängt von der Art der P_REQ des anfordernden UPA-Ports ab: für eine Anforderung P_RDO_REQ ist die dem Quell-Port übermittelte S_REQ eine S_CPI_REQ; für eine P_RDS_REQ oder P_RDSA_REQ ist die übermittelte S_REQ eine S_CPB_REQ; für eine P_RDD_REQ ist die übermittelte S_REQ eine S_CPD_REQ.
  • Wird vom anfordernden UPA-Port die Exklusivbenutzung des bestimmten Datenblocks angefordert (d. h. die Anforderung ist eine P_RDO REQ-Anforderung), dann werden S_REQ-Invalidierungs-Anforderungen an alle Ports verschickt, die über eine Kopie der angeforderten Cache-Line verfügen. Der System-Controller wartet auf eine P_REPLY von den UPA-Ports, an die eine S_REQ verschickt wurde, und generiert erst dann die S_REPLY für den anfordernden UPA-Port (246).
  • Davon abweichend kann der System-Controller 110 die S_REPLY für den anfordernden UPA-Port generieren, nachdem er die P_REPLY vom Quell-UPA-Port erhalten hat, ohne die P_REPLYs von anderen UPA-Ports, an die eine S_REQ verschickt wurde, abzuwarten. Die kohärente Lese-Transaktion wird jedoch nicht durchgeführt und aus dem Array 200 des System-Controllers für den Zustand noch anstehender Transaktionen, in dem aktive Transaktionen verzeichnet sind, entfernt, bevor der System-Controller alle P_REPLYs Von den UPA-Ports, an die eine S_REQ verschickt wurde, erhalten hat. Diese zweite Methode wird bevorzugt, da sie Wartezeiten verringert. Der anfordernde Datenprozessor erhält die angeforderten Daten früher, wenn das zweite Cachekohärenz-Protokoll verwendet wird. Zudem werden die Cache-Invalidierungs-S_REQ-Transaktionen parallel zur Datenübertragung an den anfordernden UPA-Port durchgeführt, wobei die verfügbaren Ressourcen des Systems effizient genutzt werden.
  • Die Dtags werden gleichzeitig für alle UPA-Ports geschrieben, die bei der Einsichtnahme einen Treffer gemeldet haben. Die MOSI-Zustandsbits in den Dtags werden mit dem neuen Wert aktualisiert.
  • Stehen die Daten für die Übertragung zum anfordernden UPA-Port bereit, dann verschickt der System-Controller die bestätigende S_REPLY an den anfordernden UPA-Port, und die Daten werden über den UPA-Datenbus entweder aus dem Quell-Cache oder aus dem Hauptspeicher übertragen.
  • Ist die aktive Anforderung eine Rückschreibe-Anforderung, dann werden die Einsichtnahme in die Dtags und deren Aktualisierung nur für den anfordernden Master-UPA- Port durchgeführt, und zwar vor dem Generieren der S_REPLY für diesen, mit der entweder die Daten auf den UPA-Bus verschoben werden oder die Rückschreibe-Transaktion abgebrochen wird.
  • Ist die aktive Transaktion eine Schreib-Invalidierungs-Anforderung, dann werden Einsichtnahme und Aktualisierung genauso durchgeführt, wie bei einer kohärenten Lese- Anforderung. Der System-Controller verschickt eine Invalidierungs-S_REQ an alle UPA- Ports, die bei der Einsichtnahme einen Treffer gemeldet haben. Die S_REPLY an den anfordernden Master-UPA-Port, die bewirkt, daß die Daten auf den UPA-Datenbus verschoben werden, wird zurückgehalten, bis alle P_REPLY-Bestätigungen für Invalidierungen eingegangen sind. Davon abweichend kann der System-Controller 110 die S_REPLY an den anfordernden UPA-Port generieren, nachdem er, wenn überhaupt, nur vom Quell-UPA-Port die P_REPLY erhalten hat, ohne auf die P_REPLYs der anderen UPA-Ports, an die S_REQs verschickt wurden, abzuwarten. Die kohärente Schreib-Transaktion wird jedoch nicht beendet und aus dem Array 200 des System-Controllers für den Zustand noch anstehender Transaktionen, in dem aktive Transaktionen verzeichnet sind, entfernt, bevor der System-Controller alle P_REPLYs von den UPA-Ports, an die eine S_REQ verschickt wurde, erhalten hat. Diese zweite Methode wird bevorzugt, da sie Wartezeiten verringert.
  • In Fig. 10 ist das Datenpaket-Format kohärenter P_REQ und S_REQ - Transaktions- Anforderungs-Pakete dargestellt. Das NDP (No Dtag Present) - Bit in S_REQ - Anforderungspaketen wird vom System-Controller nur in solchen Systemen gesetzt (d. h. auf "1"), die keine Dtags verwenden. In Systemen, die Dtags verwenden, wird das NDP-Bit gelöscht (d. h. auf "0" gesetzt). Die Cache-Controller in allen Datenprozessoren prüfen in jeder empfangenen S_REQ das NDP-Bit um festzustellen, ob ein standardgemäßer Cache-Zugriffs- Modus oder ein beschleunigter Cache-Zugriffs-Modus zu verwenden ist.
    • Zweitor-Cachesteuerun Sschaltung
  • Die Funktionsweise eines standardgemäßen Controllers aus dem Stand der Technik wurde im vorangegangenen Text beschrieben, im Kapitel "Hintergrund der Erfindung", unter Bezugnahme auf Fig. 11.
  • In Fig. 12 ist ein Blockdiagramm einer Zweitor-Cachespeichervorrichtung 440 dargestellt, die mit einem Datenprozessor 402 und einem System-Controller 110 verbunden ist. Der Cache-Speicher beinhaltet ein Cache-Line-Array 404 und ein Cache-Tag-Array 406. Das Cache-Line-Array 404 beinhaltet 2CS Cache-Lines 410, wobei CS die Anzahl der Adreßbits ist, die benötigt wird, um eine Cache-Line 410 eindeutig zu identifizieren. In jeder Cache-Line 410 ist ein Datenblock von festgelegter Größe gespeichert, wie z. B. 64 Bytes. Das Cache-Tag-Array 406 beinhaltet 2CS Cache-Tags 412.
  • Die Cache-Schaltung 444, auch Cache-Controller genannt, steuert die Funktion des Cache-Speichers 440. Eine Komparatorschaltung 445 vergleicht einen Bereich der in einer an den Cache-Speicher gerichteten Anforderung enthaltenen Adresse mit dem in einem ausgewählten Cache-Tag 412 gespeicherten Adreß-Tag, und sie überprüft den im ausgewählten Cache-Tag enthaltenen Cache-Zustandswert um festzustellen, ob das Adreß- Tag gültig ist.
  • Die Zustandsaktualisierungsschaltung 448 ist eine Schaltung für das Aktualisieren der Adresse und der Information über den Cache-Zustand, die in dem Cache-Tag 412 gespeichert sind, das von der in einer Cachespeicher-Anforderung enthaltenen Adresse ausgewählt wird. Die Cache-Line-Zugriffs-/Aktualisierungs-Schaltung 450 ist eine Schaltung für das Lesen und Schreiben von Daten aus einer bzw. in die Cache-Line 410, die von der in einer Cachespeicher-Anforderung enthaltenen Adresse ausgewählt wird.
  • Der Cache-Controller 444 beinhaltet eine Arbiter-Schaltung 446, die vom System- Controller 110 und vom Datenprozessor 402 kommende Speicherzugriffs-Anforderungen koordiniert. Ein Demultiplexer 452 verbindet den internen Datenbus 454 des Cache- Controllers mit entweder einem zum Datenprozessor 402 gehörigen Datenbus 456 oder einem zum Verbindungsmodul gehörigen Datenbus 458, je nachdem, von welchem Bauelement die gerade vom Cache-Controller 444 abgearbeitete Cache-Zugriffsanforderung stammt. Die vom Demultiplexer 452 hergestellte Datenbusverbindung basiert auf einem DP/SC - Betriebsartensignal, das vom Arbiter 446 generiert wird.
  • Da die vorliegende Erfindung ein System und ein Verfahren zum Beschleunigen von Cachespeicher-Operationen durch einen Taktzyklus oder zwei Taktzyklen im Falle eines Cache-Hits darstellt, ist in Fig. 12 die Schaltung für das Beantworten eines Cache-Miss durch Weiterleiten der Speicherzugriffs-Anforderung an eine andere Speichervorrichtung, wie z. B. den Hauptspeicher des Systems, nicht gezeigt.
  • Wird entweder vom Datenprozessor 402 oder dem System-Controller 110 eine Cachespeicher-Zugriffsoperation initiiert, dann werden dem Cache-Speicher 440 ein Adreßwert und ein Steuersignal übermittelt. Der Adreßwert beinhaltet eine Sequenz von Adreßbits, die hier zum besseren Verständnis in die drei Gruppen {A}, {B} und {C} unterteilt werden. Der volle Adreßwert, der dem Cache-Speicher übermittelt wird, wird in dieser Schrift als {ABC} dargestellt, wobei {A} die signifikantesten Adreßbits repräsentiert, {B} eine Menge von Adreßbits mittlerer Signifikanz, und {C} eine Menge der am wenigsten signifikanten Adreßbits repräsentiert.
  • Als Beispiel sei angenommen, das ein System, das einen 41-Bit-Adreßwert PA< 40 : 0> verwendet, wobei PA "physikalische Adresse" bedeutet, und wobei jeder einzelne Adreßwert ein bestimmtes Byte im Hauptspeicher des Systems darstellt. Hat nun dieses System einen Datenprozessor mit einem Cache-Speicher 440, dessen Cache-Line-Größe 64 Byte und dessen Cache-Speichergröße 512 KByte beträgt, dann repräsentiert {A} die 21 signifikantesten Adreßbits PA< 40 : 19> , {B}die 13 Adreßbits mittlerer Signifikanz PA< 18 : 6> und {C} die 6 am wenigsten signifikanten Adreßbits PA< 5 : 0> .
  • Der Cache-Speicher 440 in diesem Beispiel hat 2~3 Cache-Lines 410 und 213 entsprechende Cache-Tags 412. In jedem Cache-Tag 412 sind der Zustandswert einer Cache- Line und ein Adreß-Tag gespeichert. Der Zustandswert der Cache-Line zeigt an, ob in der entsprechenden Cache-Line gültige Daten gespeichert sind und ob der in der entsprechenden Cache-Line 410 gespeicherte Datenblock ausschließlich in diesem Cache-Speicher enthalten ist oder mit mindestens einem anderen Cache-Speicher geteilt wird. Der Cache-Zustandswert zeigt auch an, ob in der entsprechenden Cache-Line modifizierte Daten gespeichert sind, die in den Hauptspeicher zurückgeschrieben werden müssen, wenn der in der Cache-Line 410 gespeicherte Datenblock aus dem Cache-Speicher entfernt wird. Das Adreß-Tag im Cache- Tag 412 beinhaltet die {A}-Adreßbits PA< 40 : 19> , die neben der Position des Cache-Tag im Cache-Tag-Array 406 den Basisort des Datenblocks im Hauptspeicher eindeutig identifizieren.
  • In der vorliegenden Erfindung haben alle Cache-Speicher von Datenprozessoren zwei Ports. Dadurch können sowohl der Datenprozessor 402 und der System-Controller 110 Speicherzugriffs-Anforderungen an den Cache-Speicher 440 des Datenprozessors verschicken. In der vorliegenden Erfindung haben Cache-Zugriffsanforderungen des System- Controllers (die im S_REQ-Puffer 442 abgelegt werden) immer Priorität vor Cache- Zugriffsanforderungen des Datenprozessors 402. Immer dann, wenn eine Cache- Zugriffsanforderung vom Arbiter 446 zur Verarbeitung ausgewählt wird, wird die ausgewählte Anforderung zu Ende verarbeitet. Ist diese Anforderung beendet, dann wird, wenn sowohl vom Datenprozessor als auch vom System-Controller Anforderungen anstehen, vorn Arbiter 446 immer die Anforderung des System-Conirollers ausgewählt und an die andere Cache-Schaltung innerhalb des Cache-Controllers 444 weitergeleitet. Der Arbiter 446 ist also eine Kodiervorrichtung mit festgelegter Priorität. Der Arbiter gibt an den Demultiplexer 452 ein DP/SC - Betriebsartensignal aus, das die Lenkung von Datensignalen zu und vom internen Datenbus 454 des Cache-Controllers steuert.
  • Es gibt zwei bevorzugte Ausführungen des System-Controllers: Die eine enthält Dtags wie oben beschrieben, die andere enthält keine Dtags. Wie in Fig. 10 dargestellt ist in jeder Cache-Speicher-Zugriffsanforderung (an anderen Stellen dieser Schrift auch S_REQs genannt) des System-Controllers 110 an einen beliebigen UPA-Port ein NDP (no Dtag present) -Betriebsartenflag enthalten. Das NDP-Flag wird in Systemen, in denen der System- Controller Dtags enthält, auf "0" gesetzt, in Systemen, in denen der System-Controller keine Dtags enthält, wird es auf "1" gesetzt. Das NDP-Flag ist ein Betrietriebsarten-Flag, da es in den Cache-Controllern aller an den System-Controller 110 gekoppelten Datenprozessoren 402 die Betriebsart steuert.
  • Wie in Fig. 12 zu sehen ist haben die Cache-Controller aller an den System-Controller gekoppelten Datenprozessoren zwei Betriebsarten: Eine Standard-Betriebsart, bei der ein Cache-Hit/Miss - Signal generiert wird, bevor eine Lese-/Schreib-Transaktion zu den Cache- Speicher-Arrays 404, 406 fortgesetzt werden kann, und eine beschleunigte Betriebsart, bei der die Schaltung für das Generieren des Cache-Hit/Miss - Signals unterdrückt wird und der Zugriff auf das Cache-Speicher-Array fortgesetzt wird, ohne das Cache-Hit/Miss - Signal abzuwarten, wodurch die Verarbeitung der Cache-Zugriffsanforderung um einen oder zwei Taktzyklen beschleunigt wird.
  • Im Einzelnen sind die Cache-Speicher-Operationen, die durch das Setzen des NDP auf "0" beschleunigt werden, der Schreib-Zugriff auf das Cache-Tag-Array 406 zum Speichern von aktualisierten Cache-Zustandswerten und neuen Adreß-Tag-Werten, sowie der Lese- /Schreibzugriff auf das Cache-Line-Array 404 für sowohl das Lesen von Daten aus dem Cache-Speicher und das Schreiben von Daten in den Cache-Speicher. Es ist zu bemerken, daß ein Lesezugriff auf das Cache-Tag-Array 406 immer unmittelbar nach der Initialisierung der Verarbeitung aller Zugriffsanforderungen erfolgt und deshalb ein Lesezugriff auf das Cache- Tag-Array 406 durch die vorliegende Erfindung nicht beschleunigt wird.
  • Jedes Mal, wenn ein System-Controller, der Dtags verwendet, über den UPA-Port 104 eine Cache-Zugriffsanforderung auf den Cache-Speicher verschickt, dann hat es das entsprechende Dtags im Dtag-Array 134 für den Datenprozessor 402 bereits eingesehen und anhand des Dtag festgestellt, daß der Datenblock, auf den zugegriffen werden soll, gegenwärtig im Cache-Speicher 440 des Datenprozessors 402 gespeichert ist. Anders ausgedrückt verschickt der System-Controller 110 niemals eine Cache-Speicher- Zugriffsanforderung an einen UPA-Port 104, bevor es anhand der Dtags 134 bereits festgestellt hat, daß der Datenblock, auf den sich der in der Zugriffsanforderung enthaltene Adreßwert bezieht, in dem vom UPA-Port 104 unterstützten Cache-Speicher 440 enthalten ist.
  • Daraus folgt, daß der Cache-Controller 444 des Empfänger-UPA-Ports 104 nicht feststellen muß, ob ein Cache-Hit vorliegt, wenn er vom System-Controller eine Cache- Zugriffsanforderung enthält, bei der das NDP-Bit gleich "0" ist.
  • Andererseits ist es möglich, daß, wenn ein System-Controller, der keine Dtags verwendet, eine Cache-Zugriffsanforderung auf einen Cache-Speicher 440 über dessen UPA- Port 104 verschickt, der Cache-Speicher 440 den der Cache-Zugriffsanforderung entsprechenden Datenblock nicht enthält. Deshalb muß der Cache-Speicher 440 seine standardgemäße Cache-Hit/Miss - Kontrolle durchführen, bevor eine solche Cache- Zugriffsanforderung verarbeitet wird.
  • Wie in Fig. 12 dargestellt empfängt der Arbiter 446 Cache-Zugriffsanforderungen und gibt in Reaktion auf diese vier Signale aus: eine Adresse {ABC}, eine Transaktionsart (auch Befehl genannt), ein NDP-Betriebsartenflag und ein DP/SC - Betriebsartensignal. Das NDP- Betriebsartenflag wird an den Komparator 445 sowie an clie Zustands-Aktualisierungs- Schaltung 448 und die Cache-Line-Zugriffs-/Aktualisierungs-Schaltung 450 übermittelt. Das NDP-Betriebsartenflag ist für Zugriffsanforderungen des Datenprozessors immer auf "1" gesetzt, bei Zugriffsanforderungen des System-Controllers wird es auf den Wert gesetzt, den das darin enthaltene NDP-Flag hat.
  • Ist das NDP-Betriebsartenflag auf "1" gesetzt, dann funktionieren die Teilschaltungen des Cache-Controllers 444, die den Komparator 445, die Zustands-Aktualisierungs-Schaltung 448 und die Cache-Line-Zugriffs-/Aktualisierungsschaltung 450 beinhalten, in ihrer standardgemäßen Betriebsart, die im Kapitel "Hintergrund der Erfindung" unter Bezugnahme auf Fig. 11 beschrieben ist.
  • Ist das NDP-Betriebsartenflag auf "0" gesetzt, darm wird die standardgemäße Betriebsart des Komparators445 unterdrückt und statt dessen die Ausgabe des Cache-Hit/Miss - Signals durch den Komparator 445 unmittelbar auf den Hit-Wert (also "1") gesetzt. Ist das NDP-Betriebsartenflag auf "0" gesetzt, dann wird die Funktion der Zustands-Aktualisierungs- Schaltung 448 und der Cache-Line-Zugriffs-/Aktualisierungsschaltung 450 beschleunigt. Konkret bedeutet das, daß die Zustands-Aktualisierungs-Schaltung 448 und die Cache-Line- Zugriffs-/Aktualisierungsschaltung 450 standardgemäß einen sich über mehrere Taktzyklen erstreckenden Wartezustand einnehmen, während sie darauf warten, daß die {B}-Adreßbits auf einen der Cache-Tags und eine der Cache-Lines zugreifen und der Komparator 445 ein Hit/Miss - Signal generiert. Die Dauer dieses Wartezustands wird um einen oder zwei Taktzyklen - je nach Schaltung und Taktzyklus, die konkret verwendet werden - verringert, wenn das NDP-Betriebsartenflag auf "1" gesetzt ist. Daraus folgt, daß die Funktion des Cache-Speichers in jedem der Datenprozessoren 402 für vom System-Controller empfangene S_REQs beschleunigt wird, wenn der System-Controller Dtags verwendet.
  • Wird von einem System-Controller, der Dtags verwendet, eine Rückkopier- Transaktion (z. B. einer S_CPB_REQ - Cache-Zugriffsanforderung) initiiert, dann werden die Daten, die in der Cache-Line gespeichert sind, die durch die in der Cache- Zugriffsanforderung enthaltenen {B}-Adreßbits identifiziert wird, von einem Quell-Cache- Speicher 440 an den anfordernden Datenprozessor ausgegeben, ohne das entsprechende Adreß-Tag und den im Cache-Tag gespeicherten Cache-Line-Zustandswert zu prüfen. Auf ähnliche Weise wird in einer Cache-Line-Invalidierungs-Transaktion (z. B. einer S_INV_REQ - Cache-Zugriffsanforderung) in dem von den {B}-Adreßbits identifizierten Cache-Tag ein neuer Cache-Zustandswert, der einen ungültigen Zustandswert anzeigt, gespeichert, ohne das entsprechende Adreß-Tag zu prüfen.
    • Weitere Ausführungen
  • Ungeachtet dessen, daß die vorliegende Erfindung unter Bezugnahme auf einige wenige konkrete Ausführungen beschrieben wurde, ist die Beschreibung als Veranschaulichung der Erfindung zu verstehen, nicht aber als Begrenzung des Inhalts der Erfindung. Einem Fachmann können sich verschiedene Modifikationen erschließen, die innerhalb des Umfangs der in den nachfolgenden Patentansprüchen definierten Erfindung liegen.

Claims (2)

1. Cache-Speicher-Steuerungsschaltung (112) zum Steuern des Zugriffs auf ein Cache- Memory-Array (410) zum Speichern eines Datenblocksatzes, mit:
zwei Ports (104-1, 104-N) zum Empfangen von Zugriffsanforderungen (210), mit einem ersten Port (104-1) zum Empfangen von Zugriffsanforderungen von einer ersten Vorrichtung (102-1) und einem zweiten Port (104-N) zum Empfangen von Zugriffsanforderungen von einer zweiten Vorrichtung (102-N), die eine andere ist als die erste Vorrichtung; wobei alle Zugriffsanforderungen der ersten Vorrichtung und der zweiten Vorrichtung einen Adreßwert haben, von denen jeder einen ersten Satz von signifikantesten Adreßbits ({A}) und einen zweiten Satz von Cache-Index- Adreßbits ({B}) hat;
einem Generator (445) zum Generieren eines "Hit/Miss"-Signals für die Verarbeitung des in jeder Zugriffsanforderung enthaltenen Adreßwerts, um ein Hit/Miss-Signal zu generieren, das anzeigt, ob in der Cache-Speicher-Vorrichtung ein Datenblock gespeichert ist, der diesem Adreßwert entspricht; gekennzeichnet durch:
eine Zugriffsschaltung (450) mit zwei Betriebsarten, einer ersten Standard- Betriebsart, bei der dem Schreib-/Lesezugriff auf das Cache-Memory-Array das Generieren des Hit/Miss - Signals durch den Generator für das Hit/Miss-Signal als Reaktion auf den Adreßwert der Zugriffsanforderung vorangeht, und einer zweiten beschleunigten Betriebsart, bei der die Funktion des Generators für das Hit/Miss- Signal unterdrückt und der Schreib-/Lesezugriff auf das Cache-Memory-Array initialisiert wird, ohne die Verarbeitung des Adreßwerts der Zugriffsanforderung durch den Generator für das Hit/Miss-Signal abzuwarten; die Zugriffsanforderungen der zweiten Vorrichtung ferner mit einem Betriebsarten-Flag (NDP), wobei die Zugriffsschaltung in der ersten Betriebsart alle Zugriffsanforderungen der ersten Vorrichtung verarbeitet sowie Zugriffsanforderungen der zweiten Vorrichtung, wenn das Betriebsarten-Flag einen ersten Wert aufweist, in der zweiten Betriebsart verarbeitet sie Zugriffsanforderungen der zweiten Vorrichtung, wenn das Betriebsarten-Flag einen zweiten Wert aufweist, der sich von dem ersten Wert unterscheidet.
2. Cache-Speicher Vorrichtung mit einer Cache-Memory-Steuerungsschaltung nach Anspruch 1, ferner mit:
einem Cache-Line-Array mit 2N Cache-Lines zum Speichern von 2N Datenblöcken; und
einem Cache-Tag-Array mit 2N Cache-Tags, wobei jedes Cache-Tag den Zustandswert einer Cache-Line bezeichnet sowie eine Adressenmarkierung für eine entsprechende aus den 2N Cache-Lines.
DE69616402T 1995-03-31 1996-03-28 Schnelle Zweitor-Cachesteuerungsschaltung für Datenprozessoren in einem paketvermittelten cachekohärenten Multiprozessorsystem Expired - Fee Related DE69616402T2 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US41551595A 1995-03-31 1995-03-31

Publications (2)

Publication Number Publication Date
DE69616402D1 DE69616402D1 (de) 2001-12-06
DE69616402T2 true DE69616402T2 (de) 2002-07-18

Family

ID=23646003

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69616402T Expired - Fee Related DE69616402T2 (de) 1995-03-31 1996-03-28 Schnelle Zweitor-Cachesteuerungsschaltung für Datenprozessoren in einem paketvermittelten cachekohärenten Multiprozessorsystem

Country Status (4)

Country Link
US (1) US5644753A (de)
EP (1) EP0735487B1 (de)
JP (1) JPH09114736A (de)
DE (1) DE69616402T2 (de)

Families Citing this family (89)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE69616402T2 (de) * 1995-03-31 2002-07-18 Sun Microsystems, Inc. Schnelle Zweitor-Cachesteuerungsschaltung für Datenprozessoren in einem paketvermittelten cachekohärenten Multiprozessorsystem
US5887146A (en) * 1995-08-14 1999-03-23 Data General Corporation Symmetric multiprocessing computer with non-uniform memory access architecture
US5765196A (en) * 1996-02-27 1998-06-09 Sun Microsystems, Inc. System and method for servicing copyback requests in a multiprocessor system with a shared memory
JP3707854B2 (ja) * 1996-03-01 2005-10-19 株式会社東芝 キャッシュ機能を有するコンピュータ及びキャッシュメモリ制御方法
US5748934A (en) * 1996-05-31 1998-05-05 Hewlett-Packard Company Operand dependency tracking system and method for a processor that executes instructions out of order and that permits multiple precision data words
US5829034A (en) * 1996-07-01 1998-10-27 Sun Microsystems, Inc. Method and apparatus for a coherence transformer with limited memory for connecting computer system coherence domains
US5940860A (en) * 1996-07-01 1999-08-17 Sun Microsystems, Inc. Methods and apparatus for substantially memory-less coherence transformer for connecting computer node coherence domains
US5860109A (en) * 1996-07-01 1999-01-12 Sun Microsystems, Inc. Methods and apparatus for a coherence transformer for connecting computer system coherence domains
US6049847A (en) * 1996-09-16 2000-04-11 Corollary, Inc. System and method for maintaining memory coherency in a computer system having multiple system buses
US5897656A (en) * 1996-09-16 1999-04-27 Corollary, Inc. System and method for maintaining memory coherency in a computer system having multiple system buses
US5963973A (en) * 1996-12-16 1999-10-05 Bull Hn Information Systems Inc. Multiprocessor computer system incorporating method and apparatus for dynamically assigning ownership of changeable data
US6122711A (en) * 1997-01-07 2000-09-19 Unisys Corporation Method of and apparatus for store-in second level cache flush
US6032226A (en) * 1997-04-14 2000-02-29 International Business Machines Corporation Method and apparatus for layering cache and architectural specific functions to expedite multiple design
US5909561A (en) * 1997-04-14 1999-06-01 International Business Machines Corporation Apparatus and method for separately layering cache and architectural specific functions in different operational controllers to facilitate design extension
US6061755A (en) * 1997-04-14 2000-05-09 International Business Machines Corporation Method of layering cache and architectural specific functions to promote operation symmetry
US6003152A (en) * 1997-06-30 1999-12-14 Sun Microsystems, Inc. System for N-bit part failure detection using n-bit error detecting codes where n less than N
US6279065B1 (en) * 1998-06-03 2001-08-21 Compaq Computer Corporation Computer system with improved memory access
US6493802B1 (en) 1998-06-18 2002-12-10 Compaq Information Technologies Group, L.P. Method and apparatus for performing speculative memory fills into a microprocessor
US6651144B1 (en) * 1998-06-18 2003-11-18 Hewlett-Packard Development Company, L.P. Method and apparatus for developing multiprocessor cache control protocols using an external acknowledgement signal to set a cache to a dirty state
US6510164B1 (en) 1998-11-16 2003-01-21 Sun Microsystems, Inc. User-level dedicated interface for IP applications in a data packet switching and load balancing system
US6272136B1 (en) 1998-11-16 2001-08-07 Sun Microsystems, Incorporated Pseudo-interface between control and switching modules of a data packet switching and load balancing system
US6424621B1 (en) 1998-11-17 2002-07-23 Sun Microsystems, Inc. Software interface between switching module and operating system of a data packet switching and load balancing system
US6272522B1 (en) 1998-11-17 2001-08-07 Sun Microsystems, Incorporated Computer data packet switching and load balancing system using a general-purpose multiprocessor architecture
US6662173B1 (en) * 1998-12-31 2003-12-09 Intel Corporation Access control of a resource shared between components
US6289420B1 (en) * 1999-05-06 2001-09-11 Sun Microsystems, Inc. System and method for increasing the snoop bandwidth to cache tags in a multiport cache memory subsystem
US6557048B1 (en) * 1999-11-01 2003-04-29 Advanced Micro Devices, Inc. Computer system implementing a system and method for ordering input/output (IO) memory operations within a coherent portion thereof
US6622218B2 (en) * 2000-06-10 2003-09-16 Hewlett-Packard Development Company, Lp. Cache coherence protocol engine and method for efficient processing of interleaved memory transactions in a multiprocessor system
US6725341B1 (en) * 2000-06-28 2004-04-20 Intel Corporation Cache line pre-load and pre-own based on cache coherence speculation
US6851035B1 (en) * 2000-07-28 2005-02-01 Marconi Communications, Inc. Method and apparatus for storing data packets with a packet boundary indicator
US6826619B1 (en) 2000-08-21 2004-11-30 Intel Corporation Method and apparatus for preventing starvation in a multi-node architecture
US6671799B1 (en) 2000-08-31 2003-12-30 Stmicroelectronics, Inc. System and method for dynamically sizing hardware loops and executing nested loops in a digital signal processor
US6754807B1 (en) 2000-08-31 2004-06-22 Stmicroelectronics, Inc. System and method for managing vertical dependencies in a digital signal processor
US6487643B1 (en) 2000-09-29 2002-11-26 Intel Corporation Method and apparatus for preventing starvation in a multi-node architecture
US6772298B2 (en) 2000-12-20 2004-08-03 Intel Corporation Method and apparatus for invalidating a cache line without data return in a multi-node architecture
US7234029B2 (en) * 2000-12-28 2007-06-19 Intel Corporation Method and apparatus for reducing memory latency in a cache coherent multi-node architecture
US6791412B2 (en) * 2000-12-28 2004-09-14 Intel Corporation Differential amplifier output stage
US20020087775A1 (en) * 2000-12-29 2002-07-04 Looi Lily P. Apparatus and method for interrupt delivery
US20020087766A1 (en) * 2000-12-29 2002-07-04 Akhilesh Kumar Method and apparatus to implement a locked-bus transaction
US6721918B2 (en) 2000-12-29 2004-04-13 Intel Corporation Method and apparatus for encoding a bus to minimize simultaneous switching outputs effect
US6721813B2 (en) * 2001-01-30 2004-04-13 Advanced Micro Devices, Inc. Computer system implementing a system and method for tracking the progress of posted write transactions
US6971098B2 (en) 2001-06-27 2005-11-29 Intel Corporation Method and apparatus for managing transaction requests in a multi-node architecture
US7227870B2 (en) * 2001-11-20 2007-06-05 Broadcom Corporation Systems including packet interfaces, switches, and packet DMA circuits for splitting and merging packet streams
US7394823B2 (en) * 2001-11-20 2008-07-01 Broadcom Corporation System having configurable interfaces for flexible system configurations
US7206879B2 (en) * 2001-11-20 2007-04-17 Broadcom Corporation Systems using mix of packet, coherent, and noncoherent traffic to optimize transmission between systems
US6748479B2 (en) 2001-11-20 2004-06-08 Broadcom Corporation System having interfaces and switch that separates coherent and packet traffic
US6912602B2 (en) * 2001-11-20 2005-06-28 Broadcom Corporation System having two or more packet interfaces, a switch, and a shared packet DMA circuit
US7752281B2 (en) * 2001-11-20 2010-07-06 Broadcom Corporation Bridges performing remote reads and writes as uncacheable coherent operations
US6704833B2 (en) * 2002-01-04 2004-03-09 Hewlett-Packard Development Company, L.P. Atomic transfer of a block of data
US6993631B2 (en) * 2002-05-15 2006-01-31 Broadcom Corporation L2 cache maintaining local ownership of remote coherency blocks
US6965973B2 (en) * 2002-05-15 2005-11-15 Broadcom Corporation Remote line directory which covers subset of shareable CC-NUMA memory space
US7003631B2 (en) * 2002-05-15 2006-02-21 Broadcom Corporation System having address-based intranode coherency and data-based internode coherency
US7266587B2 (en) * 2002-05-15 2007-09-04 Broadcom Corporation System having interfaces, switch, and memory bridge for CC-NUMA operation
US20040199727A1 (en) * 2003-04-02 2004-10-07 Narad Charles E. Cache allocation
US7636815B1 (en) 2003-04-09 2009-12-22 Klaiber Alexander C System and method for handling direct memory accesses
US8751753B1 (en) 2003-04-09 2014-06-10 Guillermo J. Rozas Coherence de-coupling buffer
US7496715B1 (en) * 2003-07-16 2009-02-24 Unisys Corporation Programmable cache management system and method
US8427490B1 (en) 2004-05-14 2013-04-23 Nvidia Corporation Validating a graphics pipeline using pre-determined schedules
JP4673585B2 (ja) * 2004-08-05 2011-04-20 富士通株式会社 メモリシステム制御装置およびメモリシステム制御方法
US8624906B2 (en) * 2004-09-29 2014-01-07 Nvidia Corporation Method and system for non stalling pipeline instruction fetching from memory
US8683184B1 (en) * 2004-11-15 2014-03-25 Nvidia Corporation Multi context execution on a video processor
US7483422B2 (en) * 2005-02-10 2009-01-27 International Business Machines Corporation Data processing system, method and interconnect fabric for selective link information allocation in a data processing system
US7451231B2 (en) * 2005-02-10 2008-11-11 International Business Machines Corporation Data processing system, method and interconnect fabric for synchronized communication in a data processing system
US20060176890A1 (en) * 2005-02-10 2006-08-10 International Business Machines Corporation Data processing system, method and interconnect fabric for improved communication in a data processing system
US7971002B1 (en) 2005-04-07 2011-06-28 Guillermo Rozas Maintaining instruction coherency in a translation-based computer system architecture
US9092170B1 (en) 2005-10-18 2015-07-28 Nvidia Corporation Method and system for implementing fragment operation processing across a graphics bus interconnect
JP4791195B2 (ja) * 2006-01-30 2011-10-12 パナソニック株式会社 ダイナミック回路
WO2007096999A1 (ja) * 2006-02-24 2007-08-30 Fujitsu Limited 切り離し装置および切り離し方法
US20080056230A1 (en) * 2006-08-29 2008-03-06 Santhanakrishnan Geeyarpuram N Opportunistic channel unblocking mechanism for ordered channels in a point-to-point interconnect
US8677091B2 (en) 2006-12-18 2014-03-18 Commvault Systems, Inc. Writing data and storage system specific metadata to network attached storage device
US20090006777A1 (en) * 2007-06-28 2009-01-01 Donley Greggory D Apparatus for reducing cache latency while preserving cache bandwidth in a cache subsystem of a processor
US20090006756A1 (en) * 2007-06-29 2009-01-01 Donley Greggory D Cache memory having configurable associativity
US8683126B2 (en) * 2007-07-30 2014-03-25 Nvidia Corporation Optimal use of buffer space by a storage controller which writes retrieved data directly to a memory
US8698819B1 (en) 2007-08-15 2014-04-15 Nvidia Corporation Software assisted shader merging
US8659601B1 (en) 2007-08-15 2014-02-25 Nvidia Corporation Program sequencer for generating indeterminant length shader programs for a graphics processor
US9024957B1 (en) 2007-08-15 2015-05-05 Nvidia Corporation Address independent shader program loading
US8411096B1 (en) 2007-08-15 2013-04-02 Nvidia Corporation Shader program instruction fetch
US8780123B2 (en) * 2007-12-17 2014-07-15 Nvidia Corporation Interrupt handling techniques in the rasterizer of a GPU
US9064333B2 (en) 2007-12-17 2015-06-23 Nvidia Corporation Interrupt handling techniques in the rasterizer of a GPU
US8923385B2 (en) * 2008-05-01 2014-12-30 Nvidia Corporation Rewind-enabled hardware encoder
US8681861B2 (en) * 2008-05-01 2014-03-25 Nvidia Corporation Multistandard hardware video encoder
US8489851B2 (en) * 2008-12-11 2013-07-16 Nvidia Corporation Processing of read requests in a memory controller using pre-fetch mechanism
US20110208898A1 (en) * 2010-02-23 2011-08-25 Samsung Electronics Co., Ltd. Storage device, computing system, and data management method
US8543770B2 (en) 2010-05-26 2013-09-24 International Business Machines Corporation Assigning memory to on-chip coherence domains
KR20120094778A (ko) * 2011-02-17 2012-08-27 삼성전자주식회사 캐시 레이턴시 저감을 위한 캐시 메모리 제어방법 및 캐시 메모리 시스템
JP5549694B2 (ja) * 2012-02-23 2014-07-16 日本電気株式会社 超並列計算機、同期方法、同期プログラム
DE112013007751B3 (de) * 2012-10-22 2023-01-12 Intel Corporation Hochleistungs-Zusammenschaltungs-Bitübertragungsschicht
US10210087B1 (en) 2015-03-31 2019-02-19 EMC IP Holding Company LLC Reducing index operations in a cache
US10922228B1 (en) 2015-03-31 2021-02-16 EMC IP Holding Company LLC Multiple location index
US10042576B2 (en) * 2016-08-17 2018-08-07 Advanced Micro Devices, Inc. Method and apparatus for compressing addresses

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4228503A (en) * 1978-10-02 1980-10-14 Sperry Corporation Multiplexed directory for dedicated cache memory system
JP2822588B2 (ja) * 1990-04-30 1998-11-11 日本電気株式会社 キャッシュメモリ装置
US5388224A (en) * 1992-04-24 1995-02-07 Digital Equipment Corporation Processor identification mechanism for a multiprocessor system
DE69616402T2 (de) * 1995-03-31 2002-07-18 Sun Microsystems, Inc. Schnelle Zweitor-Cachesteuerungsschaltung für Datenprozessoren in einem paketvermittelten cachekohärenten Multiprozessorsystem

Also Published As

Publication number Publication date
EP0735487B1 (de) 2001-10-31
US5644753A (en) 1997-07-01
EP0735487A2 (de) 1996-10-02
JPH09114736A (ja) 1997-05-02
EP0735487A3 (de) 1996-10-16
DE69616402D1 (de) 2001-12-06

Similar Documents

Publication Publication Date Title
DE69616402T2 (de) Schnelle Zweitor-Cachesteuerungsschaltung für Datenprozessoren in einem paketvermittelten cachekohärenten Multiprozessorsystem
DE69724353T2 (de) Mehrrechnersystem mit einem Drei-Sprung-Kommunikationsprotokoll
DE69721643T2 (de) Multiprozessorsystem ausgestaltet zur effizienten Ausführung von Schreiboperationen
DE69722079T2 (de) Ein Mehrrechnersystem mit Anordnung zum Durchführen von Blockkopieroperationen
DE69906585T2 (de) Datenverarbeitungssystem mit nichtuniformen speicherzugriffen (numa) mit spekulativer weiterleitung einer leseanforderung an einen entfernten verarbeitungsknoten
DE102007030116B4 (de) Snoop-Filter mit ausschließlicher Inhaberschaft
DE69724354T2 (de) Ein Mehrprozessorrechnersystem mit lokalen und globalen Adressräumen und mehreren Zugriffsmoden
DE3486161T2 (de) Datenverarbeitungssystem mit Datenkohärenz.
DE69327387T2 (de) An einen paketvermittelten Bus gekoppelte Nachschreibsteuerungsschaltung für eine Cachespeichersteuerungsschaltung
DE69900797T2 (de) Cache-Speicherkohärenzprotokoll mit unabhängiger Implementierung von optimierten Cache-Speicheroperationen
DE69524564T2 (de) Kohärenz- und synchronisationsmechanismus für ein-/ausgangkanalsteuereinheiten in einem datenverarbeitungssystem
US6055605A (en) Technique for reducing latency of inter-reference ordering using commit signals in a multiprocessor system having shared caches
DE69729243T2 (de) Multiprozessorsystem mit Vorrichtung zur Optimierung von Spin-Lock-Operationen
DE102009023898B4 (de) Optimierung von gleichzeitigen Zugriffen in einem verzeichnisbasierten Kohärenzprotokoll
US6209065B1 (en) Mechanism for optimizing generation of commit-signals in a distributed shared-memory system
US6286090B1 (en) Mechanism for selectively imposing interference order between page-table fetches and corresponding data fetches
DE69323790T2 (de) Verfahren und Vorrichtung für mehreren ausstehende Operationen in einem cachespeicherkohärenten Multiprozessorsystem
JP3644587B2 (ja) 共用介入サポートを有する不均等メモリ・アクセス（ｎｕｍａ）・データ処理システム
DE69727856T2 (de) Multiprozessorsystem mit Konsistenzfehler-Registrierung mit entsprechendem Verfahren
DE69621311T2 (de) Cachespeicherkohärenzverfahren und-system
DE60204213T2 (de) Level 2 Cache mit lokaler Beibehaltung von Kohärenzblöcken
DE69722512T2 (de) Mehrrechnersystem mit einem die Anzahl der Antworten enthaltenden Kohärenzprotokoll
DE69736544T2 (de) Verfahren zur Verminderung der Anzahl von Kohärenz-Zyklen in einem verzeichnisbasierten Cachekohärenz-Speichersystem unter Verwendung eines Speicherzustands-Cachespeichers
DE102013201079A1 (de) Mechanismus des Weiterleitungsfortschritts für Speichervorgänge beim Vorhandensein einer Überlastung in einem System, das Belastungen durch Zustandsänderungen begünstigt
JPH10187645A (ja) プロセス・ノードの多数のサブノード内にコヒーレンス状態で格納するように構成されたマルチプロセス・システム

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee