DE69531933T2 - Busarchitektur in hochgradiger pipeline-ausführung - Google Patents

Busarchitektur in hochgradiger pipeline-ausführung Download PDF

Info

Publication number
DE69531933T2
DE69531933T2 DE69531933T DE69531933T DE69531933T2 DE 69531933 T2 DE69531933 T2 DE 69531933T2 DE 69531933 T DE69531933 T DE 69531933T DE 69531933 T DE69531933 T DE 69531933T DE 69531933 T2 DE69531933 T2 DE 69531933T2
Authority
DE
Germany
Prior art keywords
transaction
phase
bus
data
snoop
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 - Lifetime
Application number
DE69531933T
Other languages
English (en)
Other versions
DE69531933D1 (de
Inventor
V. Nitin SARANGDHAR
Gurbir Singh
Konrad Lai
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.)
Intel Corp
Original Assignee
Intel Corp
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 Intel Corp filed Critical Intel Corp
Publication of DE69531933D1 publication Critical patent/DE69531933D1/de
Application granted granted Critical
Publication of DE69531933T2 publication Critical patent/DE69531933T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14Handling requests for interconnection or transfer
    • G06F13/16Handling requests for interconnection or transfer for access to memory bus
    • G06F13/18Handling requests for interconnection or transfer for access to memory bus based on priority control
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/08Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0815Cache consistency protocols
    • G06F12/0831Cache consistency protocols using a bus scheme, e.g. with bus monitoring or watching means

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)

Description

  • HINTERGRUND DER ERFINDUNG
  • Dies ist ein Teilfortsetzungsanmeldung der US-Patentanmeldung mit der Seriennummer 08/206.382, die am 01.03.1994 angemeldet wurde.
  • Gebiet der Erfindung
  • Die beschriebene Erfindung bezieht sich im allgemeinen auf das Gebiet der Computersysteme. Insbesondere bezieht sie sich auf eine tief pipeline-verschachtelte Busarchitektur zur Verwendung in einem Multiprozessor-Computersystem.
  • Verwandte Technik
  • Es ist allgemein bekannt, daß ein Computersystem mehrere Komponenten enthält, wie beispielsweise, aber nicht ausschließlich, Mikroprozessoren, Speichereinheiten sowie Eingabe/Ausgabe-Einrichtungen (I/O-Einrichtungen) (die hiernach allgemein „Teilnehmer" genannt werden). Diese Teilnehmer tauschen normalerweise Information über einen Systembus aus. Da die Gesamtleistung des Computersystems direkt von der Austauschrate (d. h. Geschwindigkeit, Effizienz usw.) des Systembusses abhängt, sind viele Versuche unternommen worden, um ihre Effizienz zu verbessern.
  • Ein herkömmliches Verfahren zur Verbesserung der Leistung des Systembusses ist das Pipelining bzw. die pipelineartige Verschachtelung. Pipelining ist der Prozess des Zulassens des Anfangens neuer Bustransaktionen, bevor die vorhergehenden Bustransaktionen abgeschlossen sind. Dieser Prozess hat sich als effektiv gezeigt, weil er Zeitverzögerungen zwischen Anforderungen zum Lesen oder Schreiben von Daten und den tatsächlichen von anderen Transaktionen zu verwendenden Lese- oder Schreibtransaktionen erlaubt. Diese Zeitverzögerungen werden durch verschiedene Antwortfähigkeiten der Teilnehmer erzeugt. Durch Pipelining wird der Systembus daher effizienter verwendet, was zu einer besseren Gesamtsystemleistung führt.
  • Verschiedene andere Entwicklungen beim Design von Computersystemen machen den Prozess, bei dem Daten über den Systembus übertragen werden, kompliziert, obwohl die Gesamtleistung verbessert wird. Es ist daher schwieriger, Pipelining zu unterstützen.
  • Ein Beispiel einer solchen Entwicklung ist „Multi-Processing". Multi-Processing ist die Verwendung mehrerer Mikroprozessoren in einem einzigen Computersystem, wobei jeder Mikroprozessor seine Tasks gleichzeitig mit den übrigen Mikroprozessoren ausführt. Ein Computersystem mit „n" Mikroprozessoren kann theoretisch „n"-mal so viele Tasks ausführen – und daher „n"-mal schneller sein – als ein Computer mit einem einzigen Prozessor.
  • Bei Multiprocessing muß die aktuellste Fassung von Daten immer lokalisierbar sein und jeder Prozessor muß sicher sein, daß ihm eine Fassung der aktuellsten Daten bereitgestellt wird, wenn er einen Task ausführen muß. Dies wird „Datenkohärenz" genannt. Die Schaffung der Datenkohärenz macht jedoch das Pipelining von Bustransaktionen schwieriger, weil es oft schwierig ist, zu entscheiden, wo die aktuellste Datenfassung lokalisiert werden kann, wenn mehrere Transaktionen ausstehend sind. Die übliche Antwort auf dieses Dilemma ist das Abbrechen der Durchführung der Bustransaktion, bis der Teilnehmer, der die Daten cache-speichert, sie an den Speicher schreiben kann. Diese Antwort beseitigt aber im wesentlichen die Vorteile, die ursprünglich vom Pipelining gewonnen wurden.
  • Ein weiteres Verfahren, das zur Verbesserung der Leistung des Systembusses separat verwendet wird, ist die „Prozessor-Ordnung"-Unterstützung in einem Multiprozessor-System. Die Prozessor-Ordnung impliziert, daß Transaktionen, die von ir gendeinem Prozessor in dem Computersystem erzeugt werden, in der gleichen Reihenfolge von allen Teilnehmern in diesem Computersystem beobachtet werden. In einer pipelineverschachtelten Umgebung, in der die Transaktionen abgebrochen werden dürfen, muß es einen Satz von Protokollen geben, um die Prozessor-Ordnung sicherzustellen.
  • Ein weiteres Verfahren zur Verbesserung der Leistung eines Systems ist die Verwendung zurückgestellter Transaktionen. Eine zurückgestellte Transaktion erlaubt, daß Transaktionen, die zum Zeitpunkt der Anforderung nicht vervollständigt werden können, durch die Komponente an dem Bus zurückgestellt werden, die für das Bereitstellen der Daten verantwortlich ist (d. h. durch den „antwortenden Teilnehmer"). Wenn die Daten verfügbar werden, initiiert der antwortende Teilnehmer eine neue Transaktion, die an die die Daten anfordernde Komponente (d. h. an den „anfordernden Teilnehmer") gerichtet ist. Dies verhindert, daß der Bus mit wiederholten fehlgeschlagenen Anforderungen nach noch nicht verfügbaren Daten von dem anfordernden Teilnehmer überfüllt wird.
  • Die Verwendung zurückgestellter Transaktionen zur Erhöhung der Effizienz eines Systemsbusses kann mit der Verwendung mehrerer Mikroprozessoren in einem Computersystem kollidieren, weil der Speicherplatz der aktuellsten Datenfassung während der Zurückstellung der Transaktion im Wechseln begriffen sein kann. Die Verwendung mehrerer Mikroprozessoren in einem Computersystem kollidiert wiederum mit der effizienteren Verwendung des Bussystems.
  • Wegen der verschiedenen Konflikte zwischen diesen Verfahren, die separat zur Erhöhung der Effizienz eines Computerbusses verwendet werden, und den für ein Multiprozessor-System erforderlichen Bedingungen hat die Gesamteffizienz eines Multiprozessor-Computersystems nie ihr Maximalpotential erreicht. Falls jedoch ein Systembus entwickelt werden könnte, der eine hoch pipeline-verschachtelte Architektur bereitstellt, während mehrere Mikroprozessoren mit MESI-Cache-Kohärenz, Prozessor-Ordnung und Unterstützung von zurückgestellten Transaktionsantworten unterstützt werden, könnte ein Computersystem näher bei dem Maximalpotential arbeiten.
  • „Fixed Length Pipelined Bus Protocol for Snoop Cache", IBM TECHNICAL DISCLOSURE BULLETIN, Band 34, Nr. 1, 1. Juni 1991, Seite 254 – 256, offenbart ein Busprotokoll zum Pipelining von Snoop-Bus-Übertragungszyklen mit Aufrechterhalten der Snoop-Cache-Kohärenz ohne Störung des Pipeline-Ablaufs. Dieses Protokoll verbessert die Busbandbreite für einen Snoop-Speicherbus. Für diese Lösung benötigt der pipeline-verschachtelte Bus-Snoop-Zyklus jedoch Wartezyklen, insbesondere wenn Zugriffe auf dieselbe Cache-Zeile nacheinander erfolgen. Die Bus-Snoop-Operation und die Datenübertragung müssen außerdem die gleiche Anzahl von Zyklen belegen, was zur Reduzierung der Gesamteffizienz des Computersystems führt.
  • Ein weiteres Beispiel einer bekannten Anordnung ist in dem US 5.367.660 offenbart.
  • ZUSAMMENFASSENDE DARSTELLUNG DER ERFINDUNG
  • Die beschriebene Erfindung ist ein Verfahren und ein System zum Austausch von Nachrichten und Daten zwischen mehreren Komponenten in einem Einprozessor- oder vorzugsweise in einem Multiprozessor-Computersystem.
  • Gemäß der vorliegenden Erfindung wird ein Verfahren zum Unterstützen einer Mehrzahl von mehrphasigen Bustransaktionen zur Übertragung von Daten in einem Computersystem mit einem Bus bereitgestellt, der die mehreren mehrphasigen Bustransaktionen pipeline-artig verschachtelt und eine Mehrzahl von Teilnehmern, einschließlich einer zweiten Mehrzahl von Mikroprozessoren, von denen wenigstens ein Mikroprozessor einen Cache enthält, miteinander koppelt, umfassend:
    Aufrechterhalten einer Kohärenz der Daten durch den wenigstens einen Mikroprozessor, der während einer Snoop-Phase jeder der mehreren mehrphasigen Bustransaktionen eine Cache-Snoop-Operation ausführt; und
    Zurückstellen wenigstens einer Transaktion der mehreren mehrphasigen Bustransaktionen, ohne die Pipeline-Verschachtelung des Busses zu unterbrechen, bis entweder eine zurückgestellte Erwiderungstransaktion bei Erlangung eines Zugriffs auf die Daten initiiert wird oder bis die wenigstens eine Transaktion erneut gestartet wird.
  • Gemäß der vorliegenden Erfindung wird ferner ein Computersystem bereitstellt, aufweisend:
    Busmittel zum Übertragen von Daten, um eine Mehrzahl von mehrphasigen Bustransaktionen zu unterstützen, die wenigstens eine erste und eine zweite mehrphasige Bustransaktion einschließen; und
    Teilnehmermittel zum Initiieren einer Busanforderung für die wenigstens eine erste und zweite mehrphasige Bustransaktion, zum Aufrechterhalten der Kohärenz der Daten, indem eine Cache-Snoop-Operation während einer Snoop-Phase jeder der mehreren mehrphasigen Bustransaktionen ausgeführt wird, und zum Zurückstellen wenigstens einer Transaktion der mehreren mehrphasigen Bustransaktionen, ohne die Pipeline-Verschachtelung der Busmittel zu unterbrechen, bis entweder eine zurückgestellte Erwiderungstransaktion bei Erlangung eines Zugriffs auf die Daten initiiert wird oder bis die wenigstens eine Transaktion erneut gestartet wird.
  • Gemäß der vorliegenden Erfindung wird ferner ein Verfahren zum Unterstützen einer Mehrzahl mehrphasiger Bustransaktionen zur Übertragung von Daten in einem Computersystem bereitgestellt, wobei das Computersystem einen Bus enthält, der die mehreren mehrphasigen Bustransaktionen pipeline-verschachtelt und eine Mehrzahl von Teilnehmern miteinander koppelt, umfassend:
    Empfangen einer Mehrzahl von Anforderungsphasen für die mehreren mehrphasigen Bustransaktionen, während welcher die jeweiligen Bustransaktionen initiiert werden, wobei jede Anforderungsphase ein Adreß-Strobe-Signal, eine Adresse und eine Mehrzahl von Anforderungssignalen, die eine Art der Anforderung für die der Anforderungsphase zugeordnete Bustransaktion anzeigen, einschließt;
    Überwachen einer Mehrzahl von Steuersignalen während einer Snoop-Phase jeder der mehreren mehrphasigen Bustransaktionen;
    Zurückstellen wenigstens einer Transaktion der mehreren mehrphasigen Bustransaktionen, ohne die Pipeline-Verschachtelung des Busses zu unterbrechen, indem ein Zurückstellungssignal während der Snoop-Phase der wenigstens einen Transaktion angelegt wird;
    Beseitigen der Zurückstellung der wenigstens einen Transaktion, sofern ein erstes Signal der mehreren Steuersignale angelegt und ein zweites Signal der mehreren Steuersignale während der Snoop-Phase der wenigstens einen Transaktion weggenommen wird;
    Ausdehnen der Snoop-Phase in Erwiderung eines Anlegens der mehreren Steuersignale für die wenigstens eine Transaktion der mehreren mehrphasigen Bustransaktionen, um die Snoop-Phase um wenigstens einen weiteren Buszyklus vorübergehend auszudehnen; und
    Bereitstellen einer Mehrzahl von Antwortphasen, indem in jeder Antwortphase eine Mehrzahl von Antwortsignalen angelegt wird, um ein Ergebnis für eine Transaktion zu liefern, wobei dann, wenn das Zurückstellungssignal in der jeweiligen Snoop-Phase angelegt wurde und eine Zurückstellung ausgeführt wird, eine eine zurückgestellte Transaktion anzeigende Antwort von den mehreren Antwortsignalen in der jeweiligen Antwortphase zur Verfügung gestellt wird, und wobei ferner eine erste Anforderungsphase und eine zweite Anforderungsphase vor dem Bereitstellen einer ersten Antwortphase, die der ersten Anforderungsphase entspricht, empfangen werden.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • Die Merkmale und Vorteile der vorliegenden Erfindung werden anhand der nachfolgenden detaillierten Beschreibung der vorliegenden Erfindung klar, in der
  • 1 eine Blockdarstellung eines Bus-Clusters mit mehreren Teilnehmern zeigt, die die Pipeline-Verschachtelung von Transaktionen auf einem Systembus initiieren und steuern.
  • 2 zeigt ein allgemeines Phasen-Zeitdiagramm, das die Phasen veranschaulicht, die von zwei von dem Systembus gemäß 1 unterstützten pipeline-verschachtelten Transaktionen angenommen werden.
  • 3 zeigt ein veranschaulichendes Zeitdiagramm von Informationssignalen, die sich beim Unterstützen einer anforderungsinitiierten „Schreib"-Transaktion durch den Systembus gemäß 1 ausbreiten.
  • 4 zeigt ein veranschaulichendes Zeitdiagramm von Informationssignalen, die sich beim Unterstützen einer antwortinitiierten „Lese"-Transaktion durch den Systembus gemäß 1 ausbreiten.
  • 5 zeigt ein veranschaulichendes Zeitdiagramm von Informationssignalen, die sich durch den Systembus gemäß 1 beim Unterstützen einer Implizites-Rückschreiben-Transaktion ausbreiten, die während einer Lesetransaktion ausgeführt wird.
  • 6 zeigt ein veranschaulichendes Zeitdiagramm von Informationssignalen, die sich durch den Systembus gemäß 1 beim Unterstützen einer Implizites-Rückschreiben-Transaktion ausbreiten, die während einer Schreibtransaktion ausgeführt wird.
  • 7 zeigt ein veranschaulichendes Zeitdiagramm von Informationssignalen, die sich beim Unterstützen mehrerer Teil-Cache-Zeilen-Lesetransaktionen durch den Systembus gemäß 1 ausbreiten.
  • 8 zeigt ein veranschaulichendes Zeitdiagramm von Informationssignalen, die sich beim Unterstützen mehrerer Cache-Zeilen-Lesetransaktionen vom gleichen Teilnehmer durch den Systembus gemäß 1 ausbreiten.
  • 9 zeigt ein veranschaulichendes Zeitdiagramm von Informationssignalen, die sich beim Unterstützen mehrerer Teil-Cache-Zeilen-Schreibtransaktionen durch den Systembus gemäß 1 ausbreiten.
  • 10 zeigt ein veranschaulichendes Zeitdiagramm des pipeline-verschachtelten Busses gemäß 1, der mehrere Cache-Zeilen-Schreibtransaktionen unterstützt.
  • 11 zeigt ein veranschaulichendes Zeitdiagramm von Informationssignalen, die sich durch den Systembus gemäß 1 beim Unterstützen von zwei sequentiellen Bustransaktionen ausbreiten, die Besitz anfordern, um dieselben Daten zu modifizieren.
  • 12 zeigt ein veranschaulichendes Zeitdiagramm von Informationssignalen, die sich beim Unterstützen einer Zurückgestellt-Antwort für die Transaktion der zurückgestellten Erwiderung durch den Systembus gemäß 1 ausbreiten.
  • 13 zeigt ein veranschaulichendes Zeitdiagramm von Informationssignalen, die sich beim Unterstützen der Snoop-Verantwortlichkeit für eine zurückgestellte Transaktion durch den Systembus gemäß 1 ausbreiten.
  • 14 zeigt eine Blockdarstellung, die eine In-der-Reihenfolge-Warteschleife veranschaulicht, die in den Teilnehmern gemäß 1 zur Verwendung bei der Überwachung eines Zustands des Systembusses gemäß 1 implementiert ist.
  • 15 zeigt eine veranschaulichende Blockdarstellung einer Puffer-Struktur, die in einem der Mikroprozessoren gemäß 1 verwendet wird.
  • DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
  • Ein Verfahren und Einrichtungen zum effizienten Betrieb eines pipeline-verschachtelten Systembusses zum Aufrechterhalten der Datenkohärenz und Bereitstellen einer Prozessor-Ordnung-Unterstützung ohne Unterbrechung des Pipelinings werden beschrieben. In der nachfolgenden detaillierten Beschreibung werden zahlreiche spezielle Details und veranschaulichende Zeitdiagramme von verschiedenen Bustransaktionen angegeben, um die vorliegende Erfindung vollständig zu beschreiben. Für einen Fachmann ist es jedoch klar, daß die vorliegende Erfindung ohne diese speziellen Details ausgeführt werden kann, und es stattdessen für sie einen breiten Anwendungsbereich bei dem Einsatz in einem beliebigen Computersystem gibt.
  • In der detaillierten Beschreibung werden einige Begriffe häufig verwendet, um bestimmte Eigenschaften von Komponenten in dem Computersystem zu beschreiben. Diese Begriffe schließen einander nicht aus. Ein „anfordernder Teilnehmer" ist der Teilnehmer, der eine Anforderung, typischerweise Daten zu lesen oder zu schreiben, initiiert. Ein „antwortender Teilnehmer" ist ein Teilnehmer, der durch das Bereitstellen der Daten auf die Anforderung antwortet. Ein „cache-speichernder Teilnehmer" ist ein Teilnehmer, der Cache-Fähigkeiten besitzt, z. B. ein Mikroprozessor. Ein eine „Snoop-Operation ausführender Teilnehmer" ist ein Teilnehmer, der in seinem internen Speicher nach Datenanforderungen durch eine Bustransaktion nachsieht (snoop) und der normalerweise einer der cache-speichernden Teilnehmer ist. Allgemeinere Begriffe sind beispielsweise ein „empfangender" Teilnehmer, der ein Teilnehmer ist, der Daten empfängt, normalerweise aus einer Schreibtransak tion, sowie ein „Datenübertragungs"-Teilnehmer, der ein anfordernder Teilnehmer, ein antwortender Teilnehmer oder ein eine Snoop-Operation ausführender Teilnehmer ist, der die Daten über den Systembus überträgt.
  • 1 ist eine Blockdarstellung eines Bus-Clusters 15 mit vier Mikroprozessoren 2, 4, 6 und 8 sowie einer I/O-Brücke 10 und einer Speichersteuereinrichtung 12, die mit dem Systembus 20 gekoppelt sind. Jeder der oben identifizierten „Teilnehmer" kann Daten oder Nachrichten über den Bus senden und/oder empfangen. Bei dieser Ausführungsform schafft die I/O-Brücke 10 einen Kommunikationspfad zwischen dem Systembus 20 und mehreren mit einem I/O-Bus 22 gekoppelten Peripheriegeräten, einschließlich, aber nicht ausschließlich einer Anzeigeeinrichtung 23, einer alphanumerischen Eingabeeinrichtung 21, einer Massenspeichereinrichtung 26 und einer Hardcopy-Einrichtung 27. Bei dem gleichen Ausführungsbeispiel ist die Steuerspeichereinrichtung 12 mit einem Satz dynamischer Speicher mit wahlfreiem Zugriff (DRAM) 19 gekoppelt, aber andere Speichereinrichtungen sind auch möglich. Darüber hinaus ist eine Cluster-Brücke 14 mit dem Systembus 20 und einer Cluster-Verbindung 16 gekoppelt, die erlaubt, daß der Bus-Cluster mit den übrigen Bus-Clustern 17a17m („m" = beliebig) kommuniziert.
  • Die Signalleitungen sowie die Logik des Systembusses 20 sind unter Verwendung der Gunning Transceiver Logic (GTL) von Xerox® Corporation implementiert, die für einen niedrigen Energieverbrauch und eine niedrige elektromagnetische Beeinflussung sorgt. Die Verwendung dieser Technologie erlaubt, daß bis zu 8 Teilnehmer mit dem Systembus 20 gekoppelt werden, während eine Bustaktgeschwindigkeit von bis zu 100 MHz beibehalten wird. Die verschiedenen Ausführungsformen haben verschiedene Taktgeschwindigkeiten, wie beispielsweise 33,3 MHz, 44,4 MHz und 66,7 MHz, aber andere Taktgeschwindigkeiten können ebenfalls verwendet werden. Diese Taktgeschwindigkeiten erlauben, daß die Erfindung in Computersysteme mit verschiedenen Hardware-Fähigkeiten integriert werden kann.
  • 2 ist ein Zeitdiagramm, das die Phasen von zwei vom Systembus gemäß 1 unterstützten Transaktionen veranschaulicht. Jede Bustransaktion umfaßt sechs Phasen, die angemessen von einer ausgewählten Anzahl von („T1", „T2" usw. genannten) Taktzyklen eines Systemtaktes „CLK" 29 getrennt werden; diese sechs Phasen sind die Zuteilungsentscheidungsphase, die Anforderungsphase, die Fehlerphase, die Snoop-Phase, die Datenphase und die Antwortphase. Die Absicht ist es, daß diese Phasen nach Bedarf mit verschiedenen Zeitelementen angeordnet werden können.
  • In der Zuteilungsentscheidungsphase wird der Busbesitz während der übrigen Phasen entschieden. In der Anforderungsphase stellt der Teilnehmer, der „im Besitz" des Systembusses der Zuteilungsentscheidungsphase ist, die Informationen zur Verfügung, die die übrigen Teilnehmer benötigen, um mit der vom anfordernden Teilnehmer gewünschten Transaktion anzufangen. Diese Informationen umfassen eine eventuelle Adresse der zu manipulierenden Daten sowie einen Code, der die auszuführende Operation anzeigt. Ein in der Anforderungsphase erfaßter Paritätsfehler wird veranlassen, daß ein Fehlersignal in der Fehlerphase angelegt wird. In der Snoop-Phase werden die Ergebnisse der von den cache-speichernden Teilnehmern auf dem Systembus ausgeführten Snoop-Operationen angelegt. In der Datenphase wird eine angeforderte Datenübertragung ausgeführt. Die Transaktion wird von der Bus-Pipeline entfernt, und die Ergebnisse dieser Transaktion werden in der Antwortphase angelegt. Wie es nachstehend erläutert wird, werden in jeder Phase verschiedene Signale verwendet, um Informationen zu liefern.
  • Bei der bevorzugten Ausführungsform sind die unterstützten Transaktionsarten beispielsweise, aber nicht ausschließlich,
    • (i) Cache-Zeilen-Lese- und -Schreib-Operationen, wobei eine Cache-Zeile aus 32 Bytes oder vier 8-Byte-„Chunks" besteht,
    • (ii) 8- und 16-Byte-Lese- und-Schreib-Operationen (die Teil-Cache-Zeilen-Lese- und -Schreib-Operationen genannt werden),
    • (iii) Cache-Zeilen-Lese-und-Invalidier-Operationen und (iv) Cache-Zeilen-Invalidier-Operationen. Eine Invalidier-Transaktion veranlaßt, daß weitere cache-speichernde Teilnehmer ihre angeforderte Daten speichernde Cache-Zeile in einen „Ungültig"-Zustand bringen (siehe die nachstehende Definition des Begriffs „ungültig"), so daß der anfordernde Teilnehmer den exklusiven Besitz der angeforderten Daten in seinem eigenen Cache erlangen kann. Obwohl diese Transaktionen diejenigen sind, die bei einer Ausführungsform der Erfindung unterstützt werden, können andere Ausführungsformen einen anderen Satz von Transaktionen verwenden und weiterhin die Erfindung enthalten.
  • Bei der Ausführung der Buszuteilungsentscheidung vertraut jeder Teilnehmer der 1 auf vier Gruppen von Zuteilungsentscheidungssignalen, nämlich auf die BR[3:0]#-, BPRI#-, BNR#- und LOCK#-Signale. Die BR[3:0]#-Signale sind Busanforderungssignale, die zum Empfangen und Senden von Busbesitz-Anforderungen verwendet werden. Das BPRI#-Signal ist ein Prioritäts-Anforderungssignal, das verwendet wird, um anzuzeigen, daß ein Teilnehmer Busbesitz-Anforderungen von einem Busteilnehmer hoher Priorität empfängt. Ein LOCK#-Signal ist ferner ein Bus-Verriegelt-Transaktionssignal, das von einem Teilnehmer verwendet wird, um allen übrigen Teilnehmern zu signalisieren, daß der Busbesitz gegenwärtig verriegelt ist, d. h. daß der Busbesitz nicht geändert werden kann, solange ein Teilnehmer das LOCK#-Signal angelegt hat. Das BNR#-Signal wird von einem Teilnehmer angelegt, um vorübergehend die übrigen Teilnehmer aufzufordern, neue Bustransaktionen anzulegen.
  • In der Anforderungsphase werden die Signale ADS#, REQ[4:0]#, A[35:3]#, AP[1:0]# und RP# verwendet, um eine neue Bustransaktionsanforderung zu erzeugen. Das Anlegen des ADS#- Signals zeigt an, daß die übrigen Signale in der Anforderungsphase gültig sind. Die REQ[4:0]#-Signale zeigen an, welche Art von Anforderung in einer Bustransaktion gestellt wird. Die A[35:3]#-Signale zeigen gegebenenfalls die von der angeforderten Bustransaktion angezielte Adresse an. Die RP#- und AP[1:0]#-Signale stellen Paritätsschutz für die Signale REQ[4:0]# bzw. A[35:3]# zur Verfügung. Bei dieser Anwendung sind die Signale ADS#, REQ[4:0]#, AC[35:3]#, AP[1:0]# und RP# gültig für zwei aufeinanderfolgende Taktzyklen, die anfangen, wenn das ADS#-Signal angelegt ist. Zur leichteren Bezugnahme wird ein im ersten Taktzyklus angelegtes Signal mit dem Anhang „a" und ein im zweiten Taktzyklus angelegtes Signal mit dem Anhang „b" versehen. Das im ersten Taktzyklus angelegte REQ0#-Signal wird beispielsweise „REQa0#" genannt. Entsprechend wird das im zweiten Taktzyklus angelegte REQ0#-Signal „REQb0#" genannt.
  • In der Fehlerphase wird das AERR#-Signal angelegt, falls die angeforderten Signale einen Paritätsfehler enthalten. Durch das Anlegen des AERR#-Signals wird die stattfindende Transaktion abgebrochen und der die Transaktion ausgebende Teilnehmer aufgefordert, diese ab der Zuteilungsentscheidungsphase erneut zu starten. Das Anlegen des AERR#-Signals führt ferner dazu, daß alle Teilnehmer ihren Zuteilungsentscheidungszustand erneut synchronisieren, um eine „automatische Korrektur" wegen Paritätsfehlern aufgrund von Zuteilungsentscheidungsfehlern zu erlauben.
  • In der Snoop-Phase werden bei der bevorzugten Ausführungsform die HIT#- und HITM#-Signale verwendet, um die Snoop-Ergebnisse zu liefern. Das HIT#-Signal wird von jedem cachespeichernden Teilnehmer mit den angeforderten Daten in dem (nachstehend definierten) Geteilt- oder Exklusiv-Zustand angelegt, um dem anfordernden Teilnehmer anzuzeigen, daß die angeforderten Daten in einem Geteilt-Zustand in seinen Cache ein gegeben werden sollten. Das HITM#-Signal wird von einem cachespeichernden Teilnehmer angelegt, der die angeforderten Daten in dem (nachstehend definierten) Modifiziert-Zustand aufweist. Falls das HITM#-Signal in der Snoop-Phase angelegt wird, werden der anfordernde Teilnehmer, der die Snoop-Operation ausführende Teilnehmer sowie der Speicherteilnehmer benachrichtigt, daß eine spezielle Implizites Rückschreiben genannte Transaktion stattfinden muß, so daß die Datenkohärenz bewahrt werden kann, was nachfolgend unter Bezug auf 6 und 7 näher erläutert wird.
  • Sollte ein Teilnehmer zur Vervollständigung einer Snoop-Operation zusätzliche Zeit benötigen, können das HIT#- und das HITM#-Signal gleichzeitig angelegt werden, um die Snoop-Phase um zwei Zyklen zu verzögern. Dies wird das Pipelining vorübergehend anhalten, aber nicht erfordern, daß es leergespült (flushed) wird. Falls der antwortende Teilnehmer feststellt, daß die angeforderten Daten nicht sofort verfügbar sind, kann ein DEFER#-Signal zusätzlich angelegt werden, das ermöglicht, daß der antwortende Teilnehmer die Transaktion später erneut startet und die angeforderten Daten liefert oder daß der anfordernde Teilnehmer die Transaktion erneut versucht.
  • Die Antwortphase zeigt das Ende einer Transaktion an und daß die antwort-/snoop-initiierte Datenphase angefangen hat. Das Signal RS[2:0]# wird verwendet, um eine codierte Nachricht zu senden, die anzeigt, daß in die Antwortphase eingetreten wurde und wie die Ergebnisse der Transaktion sind. Die „Antwortergebnisse" sind in der nachstehenden Tabelle A aufgeführt: TABELLE A – ANTWORTERGEBNISSE
    Figure 00140001
    Figure 00150001
  • Die Antwortergebnisse bleiben „untätig", bis eins der RS[2:0]#-Signale angelegt wird. Die „Neu-Versuch"-Antwort wird nur erlaubt, wenn das DEFER#-Signal (mit dem HITM#-Signal als inaktiv) in der Snoop-Phase angelegt wird. Der antwortende Teilnehmer informiert durch die Neu-Versuch-Antwort den anfordernden Teilnehmer, daß die Transaktion erneut versucht werden muß. Die „Hard-Fehlschlag"-Antwort ist eine gültige Antwort, die einen Transaktionsfehler anzeigt. Der anfordernde Teilnehmer muß eine Wiederherstellungsaktion durchführen. Die „Keine-Daten"-Antwort wird benötigt, wenn keine Daten von dem adressierten Teilnehmer zurückgesendet werden und die DEFER#- und HITM#-Signale in der Snoop-Phase inaktiv sind. Die „Implizites-Rückschreiben"-Antwort wird notwendig, wenn das HITM#-Signal in der Snoop-Phase angelegt wird. Der die Snoop-Operation ausführende Teilnehmer muß die in einem Modifiziert-Zustand vorgefundene Cache-Zeile übertragen. Der Speicherteilnehmer muß die Antwort treiben und die modifizierte Cache-Zeile akzeptieren. Die „Normale-Daten"-Antwort wird notwendig, wenn die Busanforderung in der Anforderungsphase eine Lese-Antwort benötigt und sowohl das HITM#-Signal als auch das DEFER#-Signal in der Snoop-Phase weggenommen wurden. Im Falle der „Normale-Daten"-Antwort muß der antwortende Teilnehmer die Lese-Daten zusammen mit der Antwort übertragen.
  • In der Datenphase werden mehrere Busleitungen angesteuert, nämlich die den D[63:0]#-, DEP[7:0]#-, DRDY#- und DBSY#-Signalen zugeordneten Busleitungen. Die D[63:0]#-Signale sind Datensignale, die je ein Datenbit durch 64 Datenleitungen ausbreiten sollen. Die DEP[7:0]#-Signale sind Paritätssignale, die zusammen mit den D[63:0]#-Signalen verwendet werden. Die DRDY#- und DBSY#-Signale werden verwendet, um die Verwendung der Datenleitungen D[63:0]# zu koordinieren und steuern. Alle Datenphasen-Bussignale, d. h. die DBSY#-, DRDY#-, D[63:0]#- und DEP[7:0]#-Signale, werden von dem Datenübertragungsteilnehmer getrieben bzw. gesteuert. Um im Taktzyklus „n" Daten auf die Leitungen D[63:0]# zu bringen, muß der Datenübertragungsteilnehmer das im Taktzyklus „n – 1" weggenommene DBSY#-Signal beobachten, das anzeigt, daß die Datenleitungen während der nächsten Transaktion frei sein werden. Das DRDY#-Signal wird angelegt, wenn gültige Daten auf die Datenleitungen D[63:0]# gebracht werden. Darüber hinaus wird ein Bussignal „TRDY#" irgendwann vor der Datenphase für anforderungs-initiierte („Schreib")-Transaktionen von dem antwortenden Teilnehmer angelegt, um anzuzeigen, daß der antwortende Teilnehmer bereit ist, Daten von dem anfordernden Teilnehmer zu empfangen. Das TRDY#-Signal wird außerdem verwendet, um die Bereitschaft zum Empfangen von Daten von einem die Snoop-Operation ausführenden Teilnehmer anzuzeigen, der während einer Implizites-Rückschreiben-Transaktion modifizierte Daten enthält.
  • Die nachfolgenden Protokollregeln diktieren die Verwendung der oben aufgeführten Steuersignale, die wiederum verwendet werden, um eine Datenübertragung in der Datenphase zu ordnen. Die Protokollregeln für die Anforderungsphase werden ebenfalls erläutert, da die Wechselwirkung zwischen der Anforderungsphase und der Datenphase wichtig ist, um einen reibungslosen Übergang von der einen Transaktion zur nächsten zu gewährleisten.
  • In Erwiderung einer n. anforderungs-initiierten („Schreib")-Transaktion wird, wenn die Transaktion Schreibdaten zu übertragen hat, ein anforderungs-initiiertes TRDY#-Signal mindestens drei Taktzyklen nach dem ersten Taktzyklus der Anforderungsphase und mindestens einen Takzyklus nach der Antwortphase der vorherigen n – 1. Transaktion angelegt. Der antwortende Teilnehmer ist für das Anlegen des TRDY#-Signals verantwortlich. Das Anlegen eines snoop-initiierten TRDY#-Signals ist ebenfalls unumgänglich, falls die Snoop-Ergebnisse für die n. Transaktion das Anlegen eines HITM#-Signals anzeigen. Das Anlegen des snoop-initiierten TRDY#-Signals zeigt dem die Snoop-Operation ausführenden Teilnehmer an, daß der antwortende Teilnehmer bereit ist, Daten eines Impliziten Rückschreibens zu akzeptieren.
  • Das TRDY#-Signal kann weggenommen werden, wenn ein inaktives DBSY#-Signal sowie ein aktives TRDY#-Signal für einen Taktzyklus beobachtet werden. Falls beobachtet wurde, daß das DBSY#-Signal bei dem Taktzyklus inaktiv war, in dem das TRDY#-Signal angelegt wurde, und falls der nächste Taktzyklus sich drei Taktzyklen vom Anlegen des vorherigen TRDY#-Signals befindet, kann das TRDY#-Signal nach einem Taktzyklus weggenommen werden. Das TRDY#-Signal muß nicht weggenommen werden, ehe die Antwortergebnisse zur Verfügung gestellt werden, es sei denn, daß in einer Schreibtransaktion ein Implizites Rücksschreiben verlangt worden ist, wobei das TRDY#-Signal möglichst schnell weggenommen werden muß, um das Anlegen ein zweites Mal zu erlauben, was für das Implizite Rückschreiben erforderlich ist.
  • Die Antwortergebnisse (Antwortphase) werden für die n. Transaktion bereitgestellt, wenn die Snoop-Ergebnisse für die n. Transaktion zur Verfügung gestellt worden sind und wenn die Antwortergebnisse für die vorherige n – 1. Transaktion zur Verfügung gestellt worden sind. Falls die Transaktion Schreibda ten enthält, kann die Antwortphase nur stattfinden, wenn das TRDY#-Signal ist und beobachtet worden ist, während das DBSY#-Signal inaktiv ist. Falls die Transaktion Schreibdaten enthält und ein Implizites Rückschreiben erfordert, kann die Antwortphase nur stattfinden, wenn das TRDY#-Signal zweimal angelegt und beobachtet worden ist, während das DBSY#-Signal inaktiv ist. Falls die Antwortergebnisse eine Normale-Daten-Antwort anzeigen, kann die Antwortphase nur stattfinden, falls das in einer früheren Transaktion angelegte DBSY#-Signal inaktiv ist.
  • Im allgemeinen muß ein Teilnehmer, der auf ein TRDY#-Signal antwortet, entweder die Daten liefern oder ein DBSY#-Signal anlegen, und zwar einen Taktzyklus, nachdem das TRDY#-Signal als aktiv und das DBSY#-Signal als inaktiv beobachtet wurde. Das DBSY#-Signal kann angelegt werden, um die Datenleitungen zu „halten", falls die Daten noch nicht zur Verfügung stehen. Falls der die Daten zur Verfügung stellende Teilnehmer das TRDY#-Signal beobachtet hat, kann er anfangen, diese Daten einen Taktzyklus vor der Wegnahme des DBSY#-Signals zu schreiben, falls er der Teilnehmer ist, der gegenwärtig das DBSY#-Signal anlegt, und er kann die Wegnahme dieses Signals vorhersagen. Lese-Übertragungen müssen in dem Taktzyklus anfangen, in dem die Antwortphase angesteuert wird. Dieses Protokoll kann durch eine Serie von veranschaulichenden Diagrammen von verschiedenen Operationen gezeigt werden.
  • Durch die Verwendung des MESI-Cache-Protokolls hält der bei der bevorzugten Ausführungsform der Erfindung verwendete Systembus die Datenkohärenz aufrecht. Das MESI-Cache-Protokoll erfordert, daß jeder cache-speichernde Teilnehmer auf dem Systembus jede von ihm cache-gespeicherte Datenzeile einem von vier Zuständen zuordnet. Diese vier Zustände sind „Modifiziert", „Exklusiv", „Geteilt" und „Ungültig" (MESI = Modified, Exclusive, Shared, Invalid). Genau genommen zeigt eine Cache-Zeile im Modifiziert-Zustand an, daß die Daten von dem cache speichernden Teilnehmer geändert worden sind und sich daher von den Daten unterscheiden, die vom Speicherteilnehmer zur Verfügung gestellt werden. Falls das System korrekt arbeitet, werden diese Daten im Modifiziert-Zustand die aktuellste Fassung der verfügbaren Daten sein. Darüber hinaus zeigt eine Cache-Zeile im Exklusiv-Zustand an, daß der cache-speichernde Teilnehmer Daten hat, die mit den im Speicherteilnehmer gespeichterten identisch sind und daß kein anderer cache-speichernder Teilnehmer gegenwärtig dieselben Daten cache-speichert. Eine Cache-Zeile im Geteilt-Zustand zeigt an, daß ihr cache-speichernder Teilnehmer, weitere cache-speichernde Teilnehmer sowie der Speicherteilnehmer eine aktuelle Fassung der Daten besitzen. Eine Cache-Zeile im Ungültig-Zustand zeigt an, daß die Daten in der Cache-Zeile ungültig sind. Das MESI-Cache-Protokoll kann dadurch von jeder Transaktion auf dem Systembus verwendet werden, daß von jedem cache-speichernden Teilnehmer gefordert wird, auf der Basis der in der Anforderungsphase bereitgestellten Informationen eine Snoop-Operation auszuführen und danach die Ergebnisse dieser Snoop-Phase anzulegen.
  • 3 ist ein Zeitdiagramm, das eine anforderungs-initi- ierte Datenübertragung oder eine Schreibtransaktion veranschaulicht, in der „Tn" einen n. Taktzyklus eines Systembustaktes („CLK") anzeigt. ADS# und REQa0# sind die Signale, die verwendet werden, um eine Transaktionsanforderung zu initiieren. Während der Anwendung werden alle Ereignisse einen Taktzyklus eher angelegt, als sie beobachtet werden. Das ADS#-Signal ist beispielsweise zum Zeitpunkt T2 als auf niedrigen Pegel gehend gezeigt oder beobachtet. Dies ergibt sich daraus, daß das ADS#-Signal von einem Teilnehmer als logisch niedrig im Taktzyklus T1 angelegt wird. Diese Konvention wird verwendet, weil es einen Taktzyklus dauert, bis die Transaktionen über den ganzen Bus beobachtet werden. Kreise sollen die Beobachtung eines Signals und Vierecke das Anlegen anzeigen.
  • Es wird weiterhin auf 3 Bezug genommen. Eine anforderungsinitiierte Transaktion beginnt, wenn ein anfordernder Teilnehmer Kontrolle über den Systembus erlangt und in der Anforderungsphase einer Transaktion eine Schreibanforderung ausgibt, so wie es durch das Anlegen der Signale ADS# und REQa0# zum Zeitpunkt T2 angezeigt wird. Der anfordernde Teilnehmer wartet danach, bis das TRDY#-Signal vom dem Teilnehmer angelegt wird, der zum Zeitpunkt T5 diese Daten empfangen wird, d. h. normalerweise die mit dem DRAM gekoppelte Speichersteuereinrichtung. Da das Signal HITM# nicht in der Snoop-Phase im Taktzyklus T6 angelegt wird, ist keine Implizites-Rückschreiben-Transaktion erforderlich. Wenn das TRDY#-Signal angelegt ist, bestimmt der anfordernde Teilnehmer, ob das DBSY#-Signal angelegt ist, was zum Zeitpunkt T4 und T5 nicht der Fall ist, und fängt an, bei dem Taktzyklus T6 Daten zu liefern, indem das DRDY#-Signal angelegt wird und Daten in der Datenphase gleichzeitig auf die Leitungen D[63:0]# gebracht werden. Dies wird im Taktzyklus T7 beobachtet.
  • Da die Transaktion eine Teil-Cache-Zeilen-Schreiboperation mit einem einzigen 8-Byte Chunk ist, muß das DBSY#-Signal nicht angelegt werden, weil die Datenleitungen D[63:0]# in dem nächsten Taktzyklus zur Verfügung stehen werden. Sollte die Transaktion mehrere 8-Byte Chunks umfassen, wäre das DBSY#-Signal zum Zeitpunkt T6 angelegt worden und bis zu einem Taktzyklus vor der Bereitstellung des letzten Chunks angelegt geblieben. Die Antwortergebnisse werden für eine Schreibtransaktion angelegt, nachdem das TRDY#-Signal angelegt und mit dem inaktiven DBSY#-Signal beobachtet ist.
  • 4 ist ein Zeitdiagramm einer antwort-initiierten („Lese")-Transaktion mit Datenübertragung. Die Lesetransaktion beginnt, wenn in der Anforderungsphase einer Bustransaktion eine Leseanforderung gestellt wird, wie es durch das Anlegen des ADS#-Signals und die Wegnahme des REQa0#-Signals zum Zeitpunkt T2 gezeigt ist. Wenn die Leseanforderung gestellt ist, wartet der anfordernde Teilnehmer, bis das DRDY#-Signal angelegt ist, was anzeigt, daß gültige Daten auf den Systembus gebracht worden sind, und beginnt dann, die Daten zu lesen. In einer antwort-initiierten Transaktion braucht das TRDY#-Signal nicht angelegt zu werden. Da die Transaktion eine Teil-Cache-Zeilen-Leseoperation mit zwei 8-Byte Chunks ist, wird das DBSY#-Signal bis T8 angelegt, d. h. bis einen Taktzyklus vor dem Taktzyklus, in dem der zweite Chunk geliefert wird. In einer Lesetransaktion werden die Antwortergebnisse angelegt einen Taktzyklus, nachdem die Snoop-Ergebnisse beobachtet werden und das DBSY#-Signal als inaktiv beobachtet wird.
  • 5 ist ein Zeitdiagramm einer antwort-initiierten Transaktion mit einer Datenübertragung, die ein Implizites Rückschreiben umfaßt. Die Transaktion beginnt mit dem Anlegen des ADS#-Signals und der Wegnahme des REQa0#-Signals zum Zeitpunkt T2, was eine Lesetransaktion anzeigt. Ein cache-speichernder Teilnehmer sieht in seinem eigenen Cache nach, und falls er erfaßt, daß er die aktuellste Fassung der angeforderten Daten besitzt, zeigt er seinen Besitz dieser Daten an, indem er zum Zeitpunkt T6 in der Snoop-Phase der Transaktion das HITM#-Signal anlegt. Der die Snoop-Operation ausführende Teilnehmer wird dann für das Bereitstellen der Daten an den anfordernden Teilnehmer verantwortlich. Wenn das HITM#-Signal angelegt ist, wird der antwortende Teilnehmer für das Anlegen des TRDY#-Signals verantwortlich, um die Daten von dem cache-speichernden Teilnehmer zu empfangen, obwohl dies vorher nicht erforderlich war. Dies passiert bei T7 und wird bei T8 beobachtet. Der die Snoop-Operation ausführende Teilnehmer erfaßt das Anlegen des TRDY#-Signals und beginnt, Daten zu liefern, indem er Daten auf die Leitungen D[63:0]# bringt und DBSY# sowie DRDY# anlegt. Da der cache-speichernde Teilnehmer an dieser Stelle nur bei jedem zweiten Taktzyklus Chunks von Daten bereitstellen kann, wird das DRDY#-Signal nur bei jedem zweiten Taktzyklus angelegt, und das DBSY# wird einen Taktzyklus vor dem letzten bei T16 beobachteten Chunk von Daten als weggenommen beobachtet. Die Anforderungsergebnisse werden bei Taktzyklus T9 angelegt und bei T10 beobachtet, nachdem bei Taktzyklus T8 das TRDY# als angelegt und das DBSY# als weggenommen beobachtet wird.
  • 6 ist ein veranschaulichendes Zeitdiagramm, das zeigt, wie ein Implizites Rückschreiben während einer Schreibtransaktion stattfindet. Wenn ein Implizites Rückschreiben während einer Schreibtransaktion stattfindet, sind zwei Datenübertragungen erforderlich. Die erste ist die normale anforderungsinitiierte Schreiboperation und die zweite das Implizite Rückschreiben. Der empfangende Teilnehmer, d. h. üblicherweise der Speicherteilnehmer, empfängt beide Schreiboperationen und verschmilzt die Informationen zu einer Cache-Zeile, die in den Speicher eingegeben wird.
  • Wenn die Schreibanforderung zum Zeitpunkt T2 durch das Anlegen des ADS#- und des REQa0#-Signals ausgegeben wird, legt der antwortende Teilnehmer nach drei Taktzyklen bei T5 ein erstes TRDY#-Signal an. Das HITM#-Signal wird bei T6 beobachtet, was anzeigt, daß ein Implizites Rückschreiben erforderlich wird. Das Anlegen dieses zweiten TRDY#-Signals, was auch vom empfangenden Teilnehmer ausgeführt wird, wird bei T8 beobachtet und findet statt, nachdem die Snoop-Ergebnisse bei T6 beobachtet werden und nachdem das erste TRDY#-Signal bei T6 weggenommen worden ist, so daß zwischen den beiden Zeitpunkten des Anlegens unterschieden werden kann. Der anfordernde Teilnehmer beginnt nach dem Anlegen des ersten TRDY#-Signals bei T5, Daten zu liefern, indem er die DRDY#- und DBSY#-Signale anlegt und Daten auf die Leitungen D[63:0]# bringt. Der die Snoop-Operation ausführende Teilnehmer muß warten, bis er erfaßt, daß DBSY# bei T8 weggenommen ist, was anzeigt, daß die anforderungs-initiierte Datenübertragung abgeschlossen ist, ehe er wiederum DBSY# bei T10 anlegt, was anzeigt, daß er Daten liefern möchte. Es sei angemerkt, daß die Daten erst bei T12 bereitgestellt werden, obwohl DBSY# bei T10 angelegt wird, was durch das Anlegen des DRDY#-Signals anzeigt wird. Sollte der die Snoop-Operation ausführende Teilnehmer keine Daten haben, würde er DBSY# nicht bei T10 anlegen, weshalb keine Datenübertragung stattfinden würde. Die Antwortergebnisse werden bei T10 auf den Systembus gebracht, was eine Implizites-Rückschreiben-Antwort anzeigt.
  • 7 ist ein Zeitdiagramm, das mehrere Teil-Zeilen-Lesetransaktionen zeigt, die in einer stationären Weise stattfinden. Da nur ein Chunk von Daten während jeder Transaktion geschrieben wird, wird das DBSY#-Signal nie angelegt. wie es im Diagramm gezeigt ist, kann eine Leseoperation in diesem stationären Zustand bei jedem dritten Taktzyklus stattfinden.
  • 8 zeigt das stationäre Verhalten der Voll-Cache-Zeilen-Leseoperationen, die hintereinander (back-to-back) aus demselben Teilnehmer heraus stattfinden. Die Antwort- und Datenübertragungen für Transaktion 1 finden bei T8, d. h. zwei Taktzyklen nach der Snoop-Phase, statt. Die Daten werden in 4 aufeinanderfolgenden Zwei-Taktzyklen-Zeitrahmen übertragen. DBSY# wird bei T8 für Transaktion 1 angelegt und bleibt bis T11, d. h. bis zu dem Taktzyklus vor der letzten Datenübertragung, angelegt. Aufeinanderfolgende Datenübertragungen können nur ohne einen Zwischen-Turn-Around-Zyklus stattfinden, falls die Daten von demselben Teilnehmer bereitgestellt werden, weil der Teilnehmer die Wegnahme des DBSY#-Signals bei den Taktzyklen T11 und T15 vorhersehen und die Datenphase für die nächste Transaktion einleiten kann, ohne einen Taktzyklus zu verlieren. TRDY# wird nicht angelegt, weil es sich um Lesetransakti onen handelt und weil die Snoop-Ergebnisse keine Implizites-Rückschreiben-Datenübertragungen anzeigen. Es sei angemerkt, daß die erste Datenübertragung in dem Taktzyklus der Antwortphase stattfinden muß, was durch das Anlegen der Signale RS[2:0]# angezeigt wird. Das DBSY#-Signal für die vorherige Transaktion muß weggenommen werden, ehe die Antwort für die aktuelle Transaktion angesteuert werden kann, wenn die Antwort entweder eine „Normale-Daten"-Antwort oder eine Implizites-Rückschreiben-Antwort ist.
  • 9 zeigt das stationäre Verhalten des Systembusses mit partiellen Schreibtransaktionen voller Geschwindigkeit. Die erste Transaktion findet auf einem untätigen Systembus statt und sieht aus wie die einfache Schreibtransaktion in 3. Das TRDY#-Signal wird bei T5, d. h. drei Zyklen nach der Wegnahme des ADS#- und des REQ[4:0]#-Signals, angelegt. Die Antwortergebnisse werden bei T8 angelegt, nachdem ein inaktives HITM#-Signal bei T6 beobachtet wurde, was anzeigt, daß kein Implizites Rückschreiben stattfindet. Bei T5 wird TRDY# als aktiv und DBSY# als inaktiv beobachtet. Die Datenübertragung kann daher bei T7 anfangen, so wie es durch das Anlegen des DRDY#-Signals angezeigt wird. Da die Datenübertragung nur einen Taktzyklus dauert, wird das DBSY#-Signal nicht angelegt. Das TRDY#-Signal für die zweite Transaktion muß warten, bis die Antwortergebnisse für die erste Transaktion abgetastet sind. Das TRDY#-Signal wird nach dem Taktzyklus angelegt, bei dem die Antwortergebnisse beobachtet werden. Da die Snoop-Ergebnisse für die zweite Transaktion bei T9 beobachtet worden sind, kann die Antwort bei T11 angesteuert werden. Bei T10 wird das TRDY#-Signal beobachtet bei weggenommenem DBSY#, und die Daten werden bei T12 angesteuert.
  • 10 zeigt das stationäre Verhalten des Busses bei Vollzeilen-Schreibtransaktionen voller Geschwindigkeit mit Datenübertragungen zwischen nur zwei Teilnehmern. Die erste Transaktion findet auf dem untätigen Systembus statt. Das TRDY#-Signal wird bis T6 verzögert. Die Antwortergebnisse können bei T8 angesteuert werden, nachdem das HITM#-Signal bei T6 als inaktiv beobachtet wurde, was anzeigt, daß kein Implizites Rückschreiben stattfindet, werden aber in diesem Beispiel bei T9 angesteuert. Bei T6 wird TRDY# als aktiv und DBSY# als inaktiv beobachtet. Die Datenübertragung kann daher bei T8 anfangen, so wie es durch das Anlegen des DBSY#-Signals angezeigt ist.
  • Das TRDY#-Signal für die zweite Transaktion kann einen Taktzyklus nach dem Ansteuern der Antwortergebnisse angesteuert werden, falls RS[2:0]# und TRDY# beide von demselben Teilnehmer kommen. Eine besondere Optimierung kann erreicht werden, falls derselbe Teilnehmer beide anforderungs-initiierten Datenübertragungen treibt. Da der anfordernde Teilnehmer DBSY# bei T11 wegnimmt, das TRDY#-Signal für Transaktion 2 als angelegt abtastet und die Datenübertragung für Transaktion 2 besitzt, kann er die nächste Datenübertragung bei T12, d. h. einen Taktzyklus nach der Wegnahme des DBSY#-Signals, ansteuern. Bei T12 tastet der die Daten empfangende Teilnehmer TRDY# als aktiv und DBSY# als inaktiv ab und akzeptiert die Datenübertragung, die bei T12 anfängt. Da die Snoop-Ergebnisse für die Transaktion 2 bei T9 beobachtet wurden, kann der antwortende Teilnehmer ungehindert die Antwort bei T12 ausgeben.
  • Es sei angemerkt, daß der anfordernde Teilnehmer keine warte-Zustände einschiebt. Bei diesem Szenarium wird das Back-End des Busses schließlich das Front-End drosseln, aber die volle Busbandbreite ist erreichbar. Bei einer Ausführungsform schiebt der Mikroprozessor immer einen Turn-Around-Zyklus zwischen den Übertragungen der Schreibdaten ein, obwohl dies bei einigen Fällen vermieden werden kann.
  • Um die Datenkohärenz zwischen zwei pipelineverschachtelten Transaktionen während einer Implizites-Rückschreiben- Transaktion zu erhalten, nimmt der Teilnehmer, der ursprünglich die Transaktion anforderte (d. h. der anfordernde Teilnehmer), die Snoop-Verantwortung für die Cache-Zeile auf, nachdem die Snoop-Phase dieser ersten Transaktion beobachtet wurde. Der anfordernde Teilnehmer beobachtet auch immer die Antwortphase, um zu bestimmen, ob das Implizite Rückschreiben, d. h. eine snoop-initiierte Übertragung, zusätzliche Daten enthält, die über das angeforderte hinausgehen. Falls die ursprüngliche Anforderung beispielsweise eine Teil-Zeilen-Lesetransaktion ist, d. h. eine Transaktion, die nur einen Teil einer vollen Cache-Zeile benötigt, erhält der anfordernde Teilnehmer die benötigten Daten aus dem ersten 8-Byte Chunk des Cache-Zeilen-Rückschreibes, das 32 Bytes enthält. Falls die ursprüngliche Anforderung eine Lesezeile- oder eine Lies-und-Invalidiere-Zeile-Transaktion (d. h. eine Transaktion, die all die übrigen cache-speichernden Teilnehmer darüber informiert, daß sie die Daten in einen ungültigen Zustand bringen sollen) ist, absorbiert der anfordernde Teilnehmer die ganze Zeile. Falls die ursprüngliche Anforderung eine Invalidiere-Zeile-Transaktion ist und die Zeile in einem anderen Cache modifiziert wird, aktualisiert der anfordernde Teilnehmer seine interne Cache-Zeile mit der aktualisierten Cache-Zeile, die er in der snoopinitiierten Datenphase empfangen hat. Falls die urspüngliche Invalidiere-Zeile-Transaktion eine Zurückgestellte Erwiderung empfängt, zeigt ein HITM#-Signal in der Snoop-Phase der Zurückgestellten Erwiderung an, daß Daten zurückkommen werden, und der anfordernde Teilnehmer aktualisiert seinen internen Cache mit den Daten. Wenn der anfordernde Teilnehmer die Snoop-Verantwortlichkeit für eine Cache-Zeile annimmt und in Erwiderung einer nachfolgenden Transaktion sofort diese Verantwortlichkeit wieder abgibt, kann er die Cache-Zeile für genau eine interne Verwendung benutzen, bevor eine Implizites Rückschreiben ausgeführt wird.
  • Während einer Lese-/Schreibtransaktion kann der anfordernde Teilnehmer nicht nur andere Teilnehmer in deren Caches nachsehen (snoop) lassen, sondern auch in seinem eigenen Cache nachsehen. Dieses Selbst-Snooping erlaubt, daß der anfordernde Teilnehmer für seine eigene Transaktions-Anforderung nachsieht, und daß die Snoop-Ergebnisse in der Snoop-Phase präsentiert werden. Sollte der Snoop im Cache des anfordernden Teilnehmers eine „modizierte" Cache-Zeile treffen, legt der anfordernde Teilnehmer das HITM#-Signal an und wird für die snoopinitiierte Datenphase verantwortlich. Der Speicherteilnehmer unterscheidet nicht zwischen einem Impliziten Rückschreiben wegen Selbst-Snoopings und einem Impliziten Rückschreiben aufgrund normalen Snoopings. In beiden Fällen bleibt der adressierte Speicherteilnehmer der antwortende Teilnehmer, und er empfängt auch das Implizite Rückschreiben und verschmilzt sie mit allen Schreibdaten.
  • Wenn der anfordernde Teilnehmer beispielsweise auf eine bestimmte Art von Daten, die sogenannte Bus-Verriegelung-Variable, zugreift, wird die Cache-Zeile aus dem internen Cache als ein Teil der Bus-Verriegelung-Transaktion geopfert, ohne daß ein internes Cache-Nachschlagen vor dem Ausgeben der Bustransaktion erforderlich ist. Die Transaktion braucht daher Selbst-Snooping. Selbst-Snooping wird auch benötigt, falls ein Seitentabelleneintrag (d. h. ein Seiten-Attribut) die Variable, auf die zugegriffen wird, als nicht-cache-speicherbar (d. h. Daten, die nicht im Cache-Speicher gespeichert werden sollten) definiert. In diesem Fall wird die Transaktion an den Systembus ausgegeben, ohne daß ein internes Cache-Nachschlagen ausgeführt wird. Aufgrund von Seitentabellen-Aliasing oder aus anderen Gründen kann die Cache-Zeile noch in dem internen Cache sein. In diesem Fall wird sie als Teil der Bustransaktion aus dem Cache zurückgeschrieben.
  • Wie es kurz erläutert wurde, ist der die Snoop-Operation ausführende Teilnehmer der Teilnehmer, der das HITM#-Signal in der Snoop-Phase der Transaktion anlegt. Der die Snoop-Operation ausführende Teilnehmer hat auch gewisse Verantwortlichkeiten bezüglich des Aufrechterhaltens der Datenkohärenz zwischen zwei pipeline-verschachtelten Transaktionen während einer Implizites-Rückschreiben-Transaktion. Nach dem Anlegen des HITM#-Signals akzeptiert der die Snoop-Operation ausführende Teilnehmer die Verantwortung für das Implizite Rückschreiben der Transaktion. Der die Snoop-Operation ausführende Teilnehmer wartet auf das snoop-initiierte Anlegen des TRDY#-Signals durch den Speicherteilnehmer und beginnt die Implizites-Rückschreiben-Datenübertragung mit dem Anlegen des DBSY#-Signals genau zwei Takte nach dem aktiven TRDY# (und dem inaktiven DBSY#), das mit dem Anlegen der Implizites-Rückschreiben-Antwort durch den Speicherteilnehmer synchronisiert ist.
  • Ob ein TRDY#-Anlegen snoop- oder anforderungs-initiiert ist, wird von der Art der Anforderung enstschieden, aus der die Transaktion herrührt. Für eine Schreibtransaktion erfordert das erste TRDY#-Anlegen immer Übertragung von Schreibdaten (anforderungs-initiierte Datenübertragung), und das zweite TRDY#-Anlegen erfordert optional die Implizites-Rückschreiben-Datenübertragung (snoop-initiierte Datenübertragung). Falls die Snoop-Transaktion eine volle Cache-Zeile schreibt, kann der die Snoop-Operation ausführende Teilnehmer die Implizites-Rückschreiben-Daten senden, muß aber nicht.
  • Der Teilnehmer, an den die Transaktion ursprünglich gerichtet war, d. h. üblicherweise der Teilnehmer, der den DRAM steuert, wird der adressierte Speicherteilnehmer genannt. Der adressierte Teilnehmer hat ebenfalls gewisse Verantwortlichkeiten bezüglich des Aufrechterhaltens der Datenkohärenz zwischen zwei pipeline-verschachtelten Transaktionen während eines Impliziten Rückschreibens. Wenn der adressierte Speicher teilnehmer in der Snoop-Phase ein aktives HITM#-Signal beobachtet hat, verbleibt er der antwortende Teilnehmer, aber er ändert seine Antwort in eine Implizites-Rückschreiben-Antwort. Falls die Transaktion eine anforderungs-initiierte Datenübertragung (Schreiboperation) enthält, verbleibt er verantwortlich für das TRDY#-Anlegen, um anzuzeigen, daß die Übertragung von Schreibdaten anfangen kann.
  • Falls die Snoop-Transaktion eine anforderungs-initiierte Datenübertragung ist und eine snoop-initiierte Datenübertragung (d. h. Rückschreiben einer modifizierten Zeile) umfaßt, wird die Transaktion zwei Datenübertragungen umfassen. Wenn das TRDY#-Signal angelegt und das anforderungs-initiierte TRDY#-Signal vollständig weggenommen ist, legt der Speicherteilnehmer ein snoop-initiiertes TRDY# an, wenn er einen freien Cache-Zeilen-Puffer hat, um das Modifizierte-Zeilen-Rückschreiben zu empfangen. Genau zwei Takte nach dem aktiven TRDY# und dem inaktiven DBSY# steuert der Speicherteilnehmer die Implizites-Rückschreiben-Antwort an, die mit dem DBSY#-Anlegen von dem die Snoop-Operation ausführenden Teilnehmer für die Implizites-Rückschreiben-Datenübertragung des Teilnehmers synchronisiert ist. Darüber hinaus ist der Speicherteilnehmer für das Verschmelzen der Schreibdaten mit der Rückschreiben-Cache-Zeile verantwortlich. Der Speicherteilnehmer aktualisiert dann den Hauptspeicher mit den aktuellsten Cache-Zeilen-Daten. Falls die Snoop-Transaktion eine vollständige Cache-Zeile schreibt, können Implizites-Rückschreiben-Daten dabei sein, müssen aber nicht. Falls DBSY# nicht genau zwei Takte nach dem aktiven TRDY# und dem inaktiven DBSY# angelegt wird, gibt es keine Implizites-Rückschreiben-Daten.
  • 11 ist ein Zeitdiagramm, das die Situation veranschaulicht, in der zwei sequentielle (d. h. back-to-back) pipelineverschachtelte Transaktionen denselben Datenspeicherplatz anfordern, und somit, wie die Datenkohärenz erhalten bleibt, während Pipelining aufrechterhalten wird. Ein erster Busteilnehmer („A1") initiiert bei Taktzyklus T2 eine erste Invalidiere-Zeile-Transaktion durch das Anlegen eines logisch niedrigen ADS#-Signals. Eine Invalidiere-Zeile-Transaktion signalisiert allen übrigen Speicherteilnehmern auf dem Systembus, daß sie diesen Datenspeicherplatz in einen ungültigen Zustand bringen sollen, weil A1 diese Daten modifizieren möchte. Drei Zyklen später macht ein zweiter Busteilnehmer („A2") eine Anforderung für dieselbe Adresse, was ebenfalls durch ein logisch niedriges ADS#-Signal angezeigt wird. Bei dem bevorzugten Ausführungsbeispiel des die Erfindung enthaltenden Systembusses beobachtet A1 diese zweite Anforderung und bestimmt, daß sie für den gleichen Datenspeicherplatz bestimmt ist, der auch in der ersten Transaktion angefordert wurde. Da A1 nach der Snoop-Phase der ersten Transaktion Besitz dieses Datenplatzes annimmt, wird A1 das richtige Snoop-Ergebnis liefern, indem er in der Snoop-Phase der zweiten Transaktion ein HITM#-Signal anlegt.
  • Durch das Anlegen des HITM#-Signals in der Snoop-Phase der zweiten Transaktion werden A2 sowie die übrigen Speicherteilnehmer auf dem Systembus darüber benachrichtigt, daß A1 in der Datenphase die erforderlichen Daten bereitstellen wird. Die Antwortphase der ersten Transaktion findet während Taktzyklus T8 statt, was die Vollendung der ersten Transaktion anzeigt. Bei Taktzyklus T11 zeigt A2 durch das Anlegen des TRDY#-Signals an, daß er bereit ist, die adressierten Daten zu empfangen. Zwei Taktzyklen später beginnt A1, die Daten bereitzustellen, indem er RS[2:0]#, DBSY# und D[63:0]# anlegt. Die Datenkohärenz bleibt somit in zwei pipeline-verschachtelten Transaktionen erhalten, die dieselben Daten anfordern.
  • Transaktionen langer Verzögerung werden auch bei der bevorzugten Ausführungsform der Erfindung unterstützt. Jeder Teilnehmer, der für das Bereitstellen der angeforderten Daten verantwortlich ist, aber dies zum Zeitpunkt der Anforderung nicht tun kann, kann in der Snoop-Phase ein DEFER#-Signal anlegen, es sei denn, daß die die Anforderung enthaltenden Informationenen anzeigten, daß das DEFER#-Signal nicht geeignet war. Dies ist ein Beispiel einer Transaktion langer Verzögerung. Vorausgesetzt, daß kein weiterer Teilnehmer ein HITM#-Signal anlegt, wird dies dazu führen, daß ein spezieller Zurückstellungs-Code in der Antwortphase der gegenwärtigen Transaktion eingegeben wird und daß die Datenübertragung verschoben wird, bis der antwortende Teinehmer (d. h. der Teilnehmer, der das DEFER#-Signal anlegt) bestimmt, daß er die Daten liefern kann und eine neue Operation einleitet. Die Verschiebe-Operation ist nützlich, weil sie anfordernde Teilnehmer daran hindert, periodische Anforderungen nach noch nicht verfügbaren Daten ausgeben zu müssen. Dies eliminiert unnötige Bustransaktionen und kann in einigen Fällen Konkurrenzzustände verhindern, bei denen einige Teilnehmer ihre Priorität dadurch verlieren müssen, daß sie erfolglose Neuversuchstransaktionen ausgeben.
  • Genau ein Teilnehmer ist der Speicherteilnehmer oder der I/O-Teilnehmer bei einer Zurückgestellt-Operation. Damit dieser speicher-adressierte Teilnehmer mit einer Zurückgestellt-Antwort erwidern kann, wird das DEFER#-Signal in der Snoop-Phase der Transaktion angelegt. Diese Aktion zeigt dem anfordernden Teilnehmer früher an, daß die Transaktion zurückgestellt werden kann und ein In-der-Reihenfolge-Abschluß nicht gewährleistet werden kann. Der anfordernde Teilnehmer muß daher damit aufhören, nachfolgende von der Reihenfolge abhängige Transaktionen auszugeben, bis die zurückgestellte Operation erfolgreich abgeschlossen ist. Es sei angemerkt, daß ein in der Snoop-Phase aktives HITM#-Signal ein aktives DEFER#-Signal überschreibt, weil ein anderer cache-speichernder Teilnehmer die Verantwortung für den In-der-Reihenfolge-Abschluß der Transaktion mit einem Impliziten Rückschreiben übernommen hat.
  • Genau wie bei der Implizites-Rückschreiben-Transaktion ist es entscheidend, die Speicherreihenfolge einzuhalten und die Snoop-Verantwortlichkeiten in einer Zurückgestellt-Operation eindeutig zu definieren, um sicherzustellen, daß eine zurückgestellte Operation ausgeführt werden kann, während die Bus-Pipeline-Verschachtelung aufrechterhalten bleibt und die Datenkohärenz in dem Multiprozessorsystem erhalten bleibt. Wenn ein DEFER#-Signal für eine Transaktion in der Snoop-Phase angelegt ist, und falls die Verantwortung bei dem Speicherteilnehmer oder dem I/O-Teilnehmer (HITM# inaktiv) bleibt, übernimmt dieser Teilnehmer ebenfalls die Snoop-Verantwortlichkeit für die Cache-Zeile (anstelle von dem anfordernden Teilnehmer) für die nachfolgenden Zugriffe auf diese Zeile. Es sei angemerkt, daß das DEFER#-Signal ferner in der Snoop-Phase angelegt wird, falls der adressierte Teilnehmer beabsichtigt, mit einer Neuversuch-Antwort zu antworten (wobei er auch annimmt, daß das HITM#-Signal inaktiv ist). Wenn das DEFER#-Signal für eine Transaktion angelegt und HITM# inaktiv ist, wird der Speicher oder I/O-Teilnehmer aufgefordert, entweder die Transaktion (durch eine Neuversuch-Antwort) zu annullieren oder eine Zurückgestellt-Antwort in der Antwortphase zu geben.
  • 12 veranschaulicht eine Zurückgestellte Antwort, der die entsprechende Zurückgestellte Erwiderung für eine Leseoperation folgt. Bei T2 legt der anfordernde Teilnehmer das ADS#-Signal an und gibt das REQ[4:0]#-Signal aus, wenn er eine Lese-Zeile-Anforderung ausgibt. Bei T5 und T6 in der Snoop-Phase bestimmt der Teilnehmer, an den die Anforderung adressiert war (d. h. der „antwortende Teilnehmer"), daß die Transaktion nicht in der Reihenfolge beendet werden kann und legt daher das DEFER#-Signal bei T6 an. Da das HITM#-Signal bei T6 als inaktiv beobachtet wurde, sendet der antwortende Teilneh- mer eine „Zurückgestellt"-Antwort zurück, indem er bei T8 die entsprechende Codierung auf RS[2:0]# anlegt.
  • Vor T10 erhält der antwortende Teilnehmer die für die zurückgestellte Anforderung erforderlichen Daten. Bei T10 gibt der ursprüngliche antwortende Teilnehmer eine Zurückgestellte-Erwiderung-Transaktion aus, indem er den Wert verwendet, der von den Geräte-Identifizierungs-„DID[7:0]#"-Signalen in der ursprünglichen Transaktion als die Adresse latch-gespeichert wurde. Bei T13 steuert der antwortende Teilnehmer einen gültigen Pegel auf das HIT#-Signal, um den endgültigen Cache-Zustand der zurückgegebenen Zeile anzuzeigen. Der ursprüngliche anfordernde Teilnehmer nimmt die Snoop-Verantwortlichkeit an. Bei T15 steuert der ursprüngliche anfordernde Teilnehmer eine normale Abschluß-Antwort an und leitet die Datenphase ein.
  • Bei T11 beobachtet der ursprüngliche anfordernde Teilnehmer die Zurückgestellte-Erwiderung-Transaktion. Er vergleicht das DID[7:0]#-Signal mit dem Zurückgestellt-Identifizierer, der mit der ursprünglichen Anforderung in seiner Warteschlange ausstehender Transaktionen gespeichert wurde. Der ursprüngliche anfordernde Teilnehmer beobachtet bei T14 den endgültigen Zustand der zurückgegebenen Cache-Zeile. Bei T16 beobachtet er die Transaktionsantwort und entfernt die Transaktion aus der Warteschlange ausstehender Transaktionen sowie aus einer in 14 gezeigten In-der-Reihenfolge-Warteschlange („IOQ"). Dadurch wird der ganze Ablauf der zurückgestellten Operation vervollständigt.
  • Um die Datenkohärenz aufrechtzuerhalten, muß der Snoop-Besitz in einer Zurückstellungsoperation eindeutig definiert werden. Nach dem Anlegen des DEFER#-Signals in der Snoop-Phase einer Cache-Zeile-Transaktion akzeptiert der antwortende Teilnehmer ebenfalls den Snoop-Besitz dieser Cache-Zeile in einem Bus-Cluster wie dem in 1 gezeigten. Wenn daher auf dieselbe Cache-Zeile im Bus-Cluster nachfolgend zugegriffen wird, kann der antwortende Teilnehmer zwei potentielle Aktionen einleiten, nämlich (i) Daten und (ii) Neuversuch. Eine Neuversuch-Antwort wird in der Antwortphase von dem antwortenden Teilnehmer ausgegeben, um die Konflikttransaktion zu annullieren. Dieser Mechanismus stellt ein Mittel zur Verfügung, mittels dessen ein Teilnehmer funktionell korrektes Verhalten bereitstellen kann. Der antwortende Teilnehmer kann optional vermeiden, mehrere Neuversuch-Anforderungen zu bekommen, indem er ein DEFER#-Signal ausgibt und die volle Verantwortung für den Zustand der Cache-Zeile in dem Bus-Cluster übernimmt. Der antwortende Teilnehmer gibt die Zurückgestellte-Erwiderung-Transaktion an den ersten anfordernden Teilnehmer aus. Bevor er dem nächsten anfordernden Teilnehmer eine zurückgestellte Erwiderung zurückgibt, gibt er eine derselben Cache-Zeile Invalidiere-Transaktion aus, um ausdrücklich die Cache-Zeile aus dem Cache des ersten anfordernden Teilnehmers zu invalidieren, falls dies für den Abschluß der zweiten Anforderung durch zurückgestellte Erwiderung erfordert wird.
  • Als Ergebnis einer Anforderung von einem weiteren mit dem beschriebenen Cluster gekoppelten Systembus kann der antwortende Teilnehmer außerdem vor der Vollendung der zurückge- stellten Erwiderung der urspünglichen Anforderung eine Invalidiere-Zeile-Transaktion initiieren. In diesem Fall hat er eine von dem Systembus einlaufende Transaktion vor einer von dem Bus ausgehenden Transaktion geordnet. Dieser Mechanismus wird von Cluster-Brücken (wie z. B. der Cluster-Brücke der 1) als ein Mechanismus verwendet, um den Konkurrenzzustand zwischen Konfliktzugriffen auf dieselbe Cache-Zeile aus mehreren Bus-Clustern zu eliminieren, und erlaubt, daß mehrere Bus-Cluster verbunden werden.
  • 13 veranschaulicht den Effekt des Aufgreifens des Snoop-Besitzes durch den antwortenden Teilnehmer, wenn er eine zurückgestellte Antwort an die erste Invalidiere-Zeile-Anfor derung gibt. Bei Fehlen der zurückgestellten Antwort geht der Snoop-Besitz sofort auf den anfordernden Teilnehmer über. Bei T2 legt der anfordernde Teilnehmer („1") das ADS#-Signal an und steuert das REQ[4:0]#-Signal an, um eine erste Invalidiere-Zeile-Anforderung auszugeben. Bei T5 legt ein anderer anfordernder Teilnehmer („2") das ADS#-Signal an und steuert das REQ[4:0]#-Signal an, um eine zweite Invalidiere-Zeile-Anforderung an dieselbe Cache-Zeile auszugeben.
  • Der Speicherteilnehmer legt das DEFER#-Signal in der Snoop-Phase und die Zurückgestellt-Antwort in der Antwortphase an, um anzuzeigen, daß die erste Invalidiere-Zeile-Anforderung eine zurückgestellte Antwort erhalten wird. Er beobachtet außerdem die zweite Invalidiere-Zeile-Anforderung und bemerkt, daß die angeforderte Adresse dieselbe ist wie eine Cache-Zeile, für die er das DEFER#-Signal angelegt hat. Nachdem er die Konfliktadresse bemerkt hat, legt er das DEFER#-Signal in der Snoop-Phase und die Neuversuch-Antwort in der Antwortphase an, um anzuzeigen, daß die zweite Antwort erneut versucht wird. Alle nachfolgenden Versuche des anderen anforderden Teilnehmers, die zweite Anforderung wieder auszugeben, erhalten eine Neuversuch-Antwort vom Speicherteilnehmer.
  • Bei T6 beobachtet der anfordernde Teilnehmer, daß das DEFER#-Signal aktiv ist, und bemerkt, daß die Transaktion nicht für den In-der-Reihenfolge-Abschluß festgeschrieben worden ist. Er akzeptiert den Besitz der Cache-Zeile nicht. Er legt daher nicht das HITM#-Signal bei T8, d. h. in der Snoop-Phase der zweiten Transaktion, an. Bei T9 beobachtet der andere anfordernde Teilnehmer, daß das DEFER#-Signal aktiv ist, und er bemerkt, daß die Transaktion nicht für den In-der-Reihenfolge-Abschluß festgeschrieben worden ist; er verbleibt daher im Ungültig-Zustand für die Cache-Zeile.
  • Wenn der Speicherteilnehmer den Besitz der Cache-Zeile in dem Bus-Cluster erhalten hat, initiiert er eine Zurückge stellte-Erwiderung-Transaktion 2d bei T14. Bei T15 gibt der andere anfordernde Teilnehmer wieder eine Anforderung „2r" aus. Diesmal erzeugt der Speicherteilnehmer keine Neuversuch-Antwort für die Transaktion „2r". Nachdem der anfordernde Teilnehmer, der bei T17 den Cache-Zeile-Besitz aufgegriffen hat, die Anforderung „2r" beobachtet hat, vollendet er diese in ähnlicher Weise wie 12.
  • 14 ist eine Blockdarstellung einer In-der-Reihenfolge-Warteschleife, die in jedem mit dem pipelineverschachtelten Bus gekoppelten Teilnehmer enthalten ist. Um mehrere ausstehende Transaktionen auf dem Systembus zu unterstützen, muß jeder Teilnehmer gewisse Mindestinformationen verfolgen können, so daß die Informationen, die zu einem bestimmten Zeitpunkt auf den Systembus gebracht werden, identifiziert werden können, und die an der Transaktion beteiligten Teilnehmer bekannt werden. Die In-der-Reihenfolge-Warteschleife („IOQ") 100 speichert diese Informationen. Die IOQ 100 enthält mehrere Transaktionsregister, beispielsweise acht Transaktionsregister 101108, zwei Warteschlangen-Zeigerregister 110 und 112, ein Snoop-Zeigerregister 113 und ein „Leer"-Register 114. Der Pfeil 115, der vom Boden der IOQ 100 bis zu ihrer Spitze verläuft, zeigt an, daß die IOQ 100 zirkular ist, so daß, wenn ein erstes Warteschlangen-Zeigerregister (d. h. „Anforderungs"-Register) 110 auf das Transaktionsregister 108 zeigt und wenn das Anforderungsregister 110 inkrementiert wird, es auf das Transaktionsregister 101 zeigen wird.
  • Obwohl bei der bevorzugten Ausführungsform acht Transaktionsregister verwendet werden, können mehr oder weniger Register verwendet werden. Die Transaktionsregister 101108 enthalten Felder, wie z. B. ein Datenübertragungsfeld, um anzuzeigen, daß es eine Datenübertragung unterstützt, ein Implizites-Rückschreiben-Feld, um das Anlegen des HITM#-Signals durch einen cache-speichernden Teilnehmer für die Transaktion anzu zeigen, ein Lese-/Schreibfeld, um anzuzeigen, daß es sich um eine Lese- oder Schreibtransaktion handelt, sowie weitere ähnliche Felder.
  • Da die Bustransaktionen auf den Systembus ausgegeben werden, werden sie in das Transaktionsregister eingegeben, auf das das Anforderungsregister 110 zeigt, und danach wird das Anforderungsregister 110 inkrementiert. Nach dem Empfang der Antwortphase für eine Transaktion wird die Transaktion an der Spitze der IOQ 100 entfernt und ein zweites Warteschlangen-Zeigerregister („Antwortregister") 112 wird inkrementiert. Das Antwortregister 112 läuft dem Anforderungsregister 110 immer nach. Darüber hinaus zeigt das Snoop-Zeigerregister 113 auf die Transaktion, für die gerade nachgesehen wird.
  • Wenn beide Warteschlangen-Zeigerregister 110 und 112 auf dasselbe Transaktionsregister zeigen und wenn das Leer-Register 114 inaktiv ist, ist die IOQ 100 voll. Falls aber das Leer-Register 114 aktiv ist, ist die IOQ 100 leer. Falls keine Transaktionen ausstehend sind, wird das Leer-Register 114 gesetzt. Abgesehen von einem Paritätsfehler, empfangen die Transaktionen ihre Antworten und Daten in der Reihenfolge, in der sie ausgegeben werden, so daß jede Transaktion an der Spitze der IOQ 100 die nächste ist, die in die Antwort- und Datenphasen eintritt, die die letzten Phasen vor Vollendung der Transaktion sind.
  • Jeder Teilnehmer speichert vorzugsweise mindestens die folgenden Informationen in seiner IOQ: die Anzahl ausstehender Transaktionen, welche Transaktion als nächste nachzusehen ist, welche Transaktion als nächste eine Antwort empfangen soll, und ob die Transaktion an oder von diesem Teilnehmer ausgegeben wurde. Weitere teilnehmer-spezifizische Businformationen müssen ebenfalls verfolgt werden, aber nicht jeder Teilnehmer muß diese Informationen verfolgen. Ein anfordernder Teilnehmer könnte beispielsweise verfolgen, wie viele Transaktionen er noch ausgeben kann (Anmerkung: bei der bevorzugten Ausführungsform kann der Mikroprozessor vier ausstehende Transaktionen haben), ob diese Transaktion eine Lese- oder Schreibtransaktion ist, und ob er Daten bereitstellen oder akzeptieren muß. Ein antwortender Teilnehmer könnte verfolgen, ob er die Antwort für die Transaktion an der Spitze der IOQ besitzt, ob diese Transaktion Implizites-Rückschreiben-Daten enthält, ob dieser Teilnehmer die Rückschreibdaten empfangen muß, ob die Transaktion eine Leseoperation ist, ob dieser Teilnehmer die Datenübertragung besitzt, ob die Transaktion eine Schreiboperation ist, so daß er die Daten akzeptieren muß, und ob Pufferressourcen verfügbar sind, so daß der Teilnehmer gegebenenfalls weitere Transaktionen anhalten kann. Ein die Snoop-Operation ausführender Teilnehmer könnte verfolgen, ob die Transaktion nachgesehen werden muß, ob die Snoop-Phase erweitert werden muß, ob diese Transaktion Implizites-Rückschreiben-Daten enthält, die von diesem Teilnehmer bereitgestellt werden müssen, und wie viele Snoop-Anforderungen es in der Warteschlange gibt. Darüber hinaus könnten Teilnehmer, deren Transaktionen zurückgestellt werden können, die Zurückgestellt-Transaktion und ihre Teilnehmer-ID sowie die Verfügbarkeit der Pufferressourcen verfolgen. Bei der bevorzugten Ausführungsform kann diese Art von Transaktionsinformationen dadurch verfolgt werden, daß mehrere Warteschlangen oder eine alles umfassende IOQ implementiert werden/wird.
  • Es gibt gewisse weitere Situationen, in denen es Zugriffskonflikte geben kann, die die Cache-Kohärenz gefährden. Diese entstehen hauptsächlich, wenn eine ausgehende Transaktion dieselbe Adresse wie die gegenwärtige Bustransaktion hat. Um dies besser zu verstehen, wird die bei der bevorzugten Ausführungsform der Erfindung verwendete konzeptuelle Pufferstruktur, in der die ausgehenden Transaktionen gespeichert werden, zuerst beschrieben; danach wird der zur Lösung der Konflikte verwendete Lösungsansatz beschrieben.
  • 15 zeigt die bei einer Ausführungsform der Erfindung verwendete Prozessor-Pufferstruktur. Da die Zuteilungsentscheidungs- und Antwortzeiten von kurzer Dauer sind, müssen die meisten Teilnehmer auf dem Bus eine solche Prozessor-Pufferstruktur haben. Es ist davon auszugehen, daß die tatsächliche Implementierung der Prozessor-Pufferstruktur nicht genau so ist, wie es in 15 gezeigt ist, aber die Implementierung zeigt den Charakter und die Funktion der Prozessor-Pufferstruktur. Die Puffer ausstehender Anforderungen enthalten Anforderungen, die an den lokalen Bus ausgegangen sind, aber die Transaktion ist nicht vollendet. Alle Anforderungen in den Puffern müssen nachgesehen werden, um korrekte Zeilen-Zustände sicherzustellen. Die Puffer ausgehender Anforderungen enthalten die Anforderungen, die im Begriff sind, auf den Systembus auszugehen. Falls die Adresse der gegenwärtigen Bustransaktion von einem anderen Teilnehmer mit einer Anforderung in den Puffern übereinstimmt, müssen die nachstehend beschriebenen Aktionen ausgeführt werden, so daß die Konflikte gelöst werden können.
  • Wenn die Adresse der gegenwärtigen Busanforderung mit der einer der Anforderungen in den Puffern ausgehender Anforderungen übereinstimmt, gibt es einen Konflikt in demselben Bus-Cluster. Da alle betroffenen Prozessoren sich an demselben Bus aufhalten, muß eine Zugriffsreihenfolge festgelegt werden. Falls die ausgehende Anforderung eine Lese- oder eine Teil-Zeilen-Schreib-Anforderung ist, wird keine besondere Aktion nötig, weil die Anforderung des entfernten Teilnehmers nicht den Lese-/Schreibfehlversuch des lokalen Teilnehmers oder die Teil-Schreib-Anforderungen beeinflußt.
  • Falls die ausgehende Anforderung eine Zeilen-Invalidiere-Transaktion ohne eine Lese-Operation ist, dann muß die ausgehende Zeilen-Invalidiere-Anforderung in eine Lese-und-Invalidiere-Zeile-Anforderung umgewandelt werden, falls die gegenwärtige Busanforderung von einem anderen Teilnehmer eine Invalidiere-Zeile ist, weil die gegenwärtige Anforderung von dem anderen Teilnehmer die gegenwärtige, in dem lokalen Cache angeordnete Zeile invalidiert. Falls die gegenwärtige Busanforderung von dem anderen Teilnehmer eine Lies-Zeile oder eine Lies-Teil-Zeile ist, ist keine besondere Aktion nötig, da die Anforderung des entfernten Teilnehmers nicht zur Entfernung der lokalen Cache-Zeile führt.
  • Falls die ausgehende Anforderung eine Rückschreibe-Zeile-Transaktion ist und falls die gegenwärtige Busanforderung eine Lies-Zeile, eine Lies-Teil-Zeile, eine Lies-Invalidiere-Zeile, eine Invalidiere-Zeile, eine Schreib-Teil-Zeile oder eine BLR-Lies-Zeile-Transaktion ist, wird das Rückschreiben in ein Implizites Rückschreiben umgewandelt und die ausgehende Anforderung wird dann entfernt. Falls die gegenwärtige Busanforderung eine Schreibe-Zeile-Transaktion ist, wird die Implizites-Rückschreiben-Datenübertragung günstigenfalls annulliert, weil die gegenwärtige Busanforderung die ganze Zeile überschreibt.
  • Zusätzlich zum Bereitstellen eines pipelineverschachtelten Busses, der zurückgestellte Transaktionen sowie eine Datenkohärenz auch für Multiprozessoren anbietet, erlaubt das beschriebene Bussystem eine Prozessorordnung. Die Prozessorordnung wird durch die Technik erreicht, daß jeder Mikroprozessor alle Anforderungen nach reihenfolge-abhängigen Operationen zurückstellt, bis die Operationen, von denen sie abhängig sind, beobachtet werden und über den Punkt hinausgegangen sind, an dem sie annulliert werden können (d. h. die Snoop-Phase). Abhängige Operationen sind Operationen, die auf andere zu berechnende Daten einwirken. In einem pipeline-verschach telten System kann dies ein Problem sein, weil ein Prozessor zwei sequentielle (d. h. back-to-back) Befehle anfordern und dann in einer späteren Phase entweder durch Zurückstellung oder Neuversuch den einen annullieren lassen kann. Dies ist ein wahrscheinliches Ereignis, da die bei der bevorzugten Ausführungsform verwendeten Mikroprozessoren spekulative Befehle ausgeben, die mit beachtlicher Wahrscheinlichkeit annulliert werden. Um einen anderen Teilnehmer an dem Ausgeben einer nachfolgenden Transaktion zu hindern, bei der er dann die erforderlichen Daten nicht erhalten kann, müssen Back-to-Back-Schreiboperationen warten, bis die Snoop-Phase erreicht und kein DEFER#-Signal angelegt worden ist. Im Gegensatz zu den anderen Transaktionen, die alle drei Taktzyklen angelegt werden können, können die Back-to-Back-Schreiboperationen daher nur alle sechs Taktzyklen angelegt werden.
  • Damit sind ein Verfahren und Einrichtungen zum Bereitstellen eines hoch pipeline-verschachtelten Bussystems beschrieben worden, das für Multiprozessoren geeignet ist und das Transaktionen mit langer Verzögerung erlaubt. Es ist für einen Fachmann klar, daß nicht nur die offenbarte Ausführungsform der Erfindung, sondern mehrere möglich sind. Ganz -allgemein soll die hierin beschriebene beispielhafte Ausführungsform nur zur Veranschaulichung der Erfindung dienen und den Schutzbereich nicht einschränken. Die Erfindung sollte daher anhand der nachfolgenden Ansprüche gemessen werden.

Claims (17)

  1. Ein Verfahren zum Unterstützen einer Mehrzahl von mehrphasigen Bustransaktionen zur Übertragung von Daten in einem Computersystem mit einem Bus (20), der die mehreren mehrphasigen Bustransaktionen pipeline-artig verschachtelt und eine Mehrzahl von Teilnehmern (2, 4, 6, 8, 10, 12) einschließlich einer zweiten Mehrzahl von Mikroprozessoren (2, 4, 6, 8), von denen wenigstens ein Mikroprozessor (2) einen Cache enthält, miteinander koppelt, umfassend: Aufrechterhalten einer Kohärenz der Daten durch den wenigstens einen Mikroprozessor, der während einer Snoop-Phase jeder der mehreren mehrphasigen Bustransaktionen eine Cache-Snoop-Operation ausführt; und Zurückstellen wenigstens einer Transaktion der mehreren mehrphasigen Bustransaktionen, ohne die Pipeline-Verschachtelung des Busses (20) zu unterbrechen, bis entweder eine zurückgestellte Erwiderungstransaktion bei Erlangung eines Zugriffs auf die Daten initiiert wird oder bis die wenigstens eine Transaktion neu gestartet wird.
  2. Das Verfahren nach Anspruch 1, wobei das Aufrechterhalten der Kohärenz ferner das Bereitstellen der Daten während einer Datenphase, die ihrer zugehörigen Snoop-Phase unmittelbar nachfolgt, umfaßt, sofern der Cache des Mikroprozessors (2) die Daten gemäß einem MESI-Protokoll in einem „Modifiziert"-Zustand speichert.
  3. Das Verfahren nach Anspruch 2, wobei das Aufrechterhalten der Kohärenz vor dem Bereitstellen der Daten während der Datenphase ferner umfaßt: Anlegen einer ersten Steuersignalleitung des Busses (20) während der Snoop-Phase, wenn der wenigstens eine Mikropro zessor erfaßt, daß der Cache die Daten in dem „Modifiziert"-Zustand enthält.
  4. Das Verfahren nach Anspruch 3, wobei die erste Steuersignalleitung eine HITM#-Steuerleitung ist.
  5. Das Verfahren nach Anspruch 3, wobei das Aufrechterhalten der Kohärenz nach dem Anlegen der ersten Steuersignalleitung und vor dem Bereitstellen der Daten während der Datenphase ferner umfaßt: Anlegen einer zweiten Steuersignalleitung des Busses (20) während der Snoop-Phase, sofern der wenigstens eine Mikroprozessor erfaßt, daß der Cache die Daten in einem „Geteilt"-Zustand und alternativ in einem „Exklusiv"-Zustand enthält.
  6. Das Verfahren nach Anspruch 3, wobei die erste Steuersignalleitung eine HIT#-Steuerleitung ist.
  7. Das Verfahren nach Anspruch 1, wobei das Zurückstellen der wenigstens einen Transaktion ferner umfaßt: Ausgeben eines Zurückgestellt-Signals (DEFER#) durch einen Teilnehmer (2, 4, 6, 8, 10, 12) während der Snoop-Phase, das anzeigt, daß die wenigstens eine Transaktion zurückgestellt wird; und Speichern eines Zurückgestellt-Identifizierers durch den Teilnehmer (2, 4, 6, 8, 10, 12) während einer Antwortphase, wobei der Zurückgestellt-Identifizierer als Anforderungsadresse für die zurückgestellte Erwiderungstransaktion verwendet wird.
  8. Das Verfahren nach Anspruch 7, wobei das Zurückstellen der wenigstens einen Transaktion ferner umfaßt: Ausgeben des von dem Teilnehmer (2, 4, 6, 8, 10, 12) gespeicherten Zurückgestellt-Identifizierers, nachdem der Teilneh mer (2, 4, 6, 8, 10, 12) rechtzeitig die Informationen zur Verfügung stellen kann, um die zurückgestellte Erwiderungstransaktion zu beginnen, um die wenigstens eine Transaktion abzuschließen.
  9. Das Verfahren nach Anspruch 1, ferner umfassend: Bereitstellen einer Prozessorordnung der Mehrzahl von mehrphasigen Bustransaktionen, indem gefordert wird, daß die zweite Mehrzahl von Mikroprozessoren (2, 4, 6, 8) das Anfordern einer mehrphasigen Bustransaktion, die von einer der mehreren mehrphasigen Bustransaktionen abhängig ist, zurückstellt, bis die wenigstens eine Transaktion nicht zurückgestellt oder abgebrochen werden kann.
  10. Das Verfahren nach Anspruch 1, wobei das Ausrechterhalten der Kohärenz ferner ein im wesentlichen gleichzeitiges Anlegen einer ersten und einer zweiten Steuersignalleitung (HITM#, HIT#) des Busses (20) umfaßt, um die Pipeline-Verschachtelung vorübergehend anzuhalten.
  11. Das Verfahren nach Anspruch 1, wobei das vorübergehende Anhalten der Pipeline-Verschachtelung für zwei Zyklen erfolgt.
  12. Ein Computersystem, aufweisend: Busmittel (20) zum Übertragen von Daten, um eine Mehrzahl von mehrphasigen Bustransaktionen zu unterstützen, die wenigstens eine erste und eine zweite mehrphasige Bustransaktion einschließen; und Teilnehmermittel (2, 4, 6, 8, 10, 12) zum Initiieren einer Busanforderung für die wenigstens eine erste und zweite mehrphasige Bustransaktion, zum Aufrechterhalten der Kohärenz der Daten, indem eine Cache-Snoop-Operation während einer Snoop-Phase jeder der mehreren mehrphasigen Bustransaktionen ausgeführt wird, und zum Zurückstellen wenigstens ei ner Transaktion der mehreren mehrphasigen Bustransaktionen, ohne die Pipeline-Verschachtelung der Busmittel (20) zu unterbrechen, bis entweder eine zurückgestellte Erwiderungstransaktion bei Erlangung eines Zugriffs auf die Daten initiiert wird oder bis die wenigstens eine Transaktion neu gestartet wird.
  13. Das Computersystem nach Anspruch 12, wobei die Teilnehmermittel (2, 4, 6, 8, 10, 12) die Kohärenz aufrechterhalten, indem ein dem Busmittel (20) zugehöriges erstes Steuersignal (HITM#) während der Snoop-Phase angelegt wird, wenn erfaßt wird, daß der interne Cache der Teilnehmermittel (2, 4, 6, 8, 10, 12) die Daten in einem „Modifiziert"-Zustand enthält.
  14. Das Computersystem nach Anspruch 12, wobei die Teilnehmermittel (2, 4, 6, 8, 10, 12) die Kohärenz aufrechterhalten, indem ein erstes Steuersignal (HITM#) und ein zweites Steuersignal (HIT#), die den Busmitteln (20) zugeordnet sind, während der Snoop-Phase im wesentlichen gleichzeitig angelegt werden, um die Pipeline-Verschachtelung der mehreren mehrphasigen Bustransaktionen über die Busmittel (20) vorübergehend anzuhalten.
  15. Das Computersystem nach Anspruch 12, wobei die Teilnehmermittel (2, 4, 6, 8, 10, 12) die wenigstens eine Transaktion zurückstellen, indem: ein Zurückgestellt-Signal während der Snoop-Phase ausgegeben wird, welches anzeigt, daß die wenigstens eine Transaktion zurückgestellt wird, und ein Zurückgestellt-Idenitifizierer durch den Teilnehmer (2, 4, 6, 8, 10, 12) während einer Antwortphase gespeichert wird, wobei der Zurückgestellt-Identifizierer als Anforderungsadresse für die zurückgestellte Erwiderungstransaktion verwendet wird.
  16. Das Computersystem nach Anspruch 12, wobei die Teilnehmermittel (2, 4, 6, 8, 10, 12) ferner eine Prozessorordnung der Mehrzahl mehrphasiger Bustransaktionen zur Verfügung stellen, indem eine Zurückstellung einer mehrphasigen Bustransaktion, die von einer der mehreren mehrphasigen Bustransaktion abhängig ist, gefordert wird, bis die wenigstens eine Transaktion nicht zurückgestellt oder abgebrochen werden kann.
  17. Ein Verfahren zum Unterstützen einer Mehrzahl mehrphasiger Bustransaktionen zur Übertragung von Daten in einem Computersystem, wobei das Computersystem einen Bus (20) enthält, der die mehreren mehrphasigen Bustransaktionen pipeline-verschachtelt und eine Mehrzahl von Teilnehmern miteinander koppelt, umfassend: Empfangen einer Mehrzahl von Anforderungsphasen für die mehreren mehrphasigen Bustransaktionen, während welcher die jeweiligen Bustransaktionen initiiert werden, wobei jede Anforderungsphase ein Adreß-Strobe-Signals (ADS#), eine Adresse und eine Mehrzahl von Anforderungssignalen (REQ[4:0]#), die eine Art der Anforderung für die der Anforderungsphase zugeordnete Bustransaktion anzeigen, einschließt; Überwachen einer Mehrzahl von Steuersignalen (HIT#, HITM#) während einer Snoop-Phase jeder der mehreren mehrphasigen Bustransaktionen; Zurückstellen wenigstens einer Transaktion der mehreren mehrphasigen Bustransaktionen, ohne die Pipeline-Verschachtelung des Busses (20) zu unterbrechen, indem ein Zurückstellungssignal (DEFER#) während der Snoop-Phase der wenigstens einen Transaktion angelegt wird; Beseitigen der Zurückstellung der wenigstens einen Transaktion, sofern ein erstes Signal (HITM#) der mehreren Steuersignale angelegt und ein zweites Signal (HIT#) der mehreren Steuersignale während der Snoop-Phase der wenigstens einen Transaktion weggenommen wird; Ausdehnen der Snoop-Phase in Erwiderung eines Anlegens der mehreren Steuersignale (HIT#, HITM#) für die wenigstens eine Transaktion der mehreren mehrphasigen Bustransaktionen, um die Snoop-Phase um wenigstens einen weiteren Buszyklus vorübergehend auszudehnen; und Bereitstellen einer Mehrzahl von Antwortphasen, indem in jeder Antwortphase eine Mehrzahl von Antwortsignalen (RS[2:0]#) angelegt wird, um ein Ergebnis für eine Transaktion zu liefern, wobei dann, wenn das Zurückstellungssignal (DEFER#) in der jeweiligen Snoop-Phase angelegt wurde und eine Zurückstellung ausgeführt wird, eine eine zurückgestellte Transaktion anzeigende Antwort von den mehreren Antwortsignalen (RS[2:0]#) in der jeweiligen Antwortphase zur Verfügung gestellt wird, und wobei ferner eine erste Anforderungsphase und eine zweite Anforderungsphase vor dem Bereitstellen einer ersten Antwortphase, die der ersten Anforderungsphase entspricht, empfangen werden.
DE69531933T 1994-03-01 1995-03-01 Busarchitektur in hochgradiger pipeline-ausführung Expired - Lifetime DE69531933T2 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US20638294A 1994-03-01 1994-03-01
US206382 1994-03-01
US39096995A 1995-02-21 1995-02-21
US390969 1995-02-21
PCT/US1995/002505 WO1995024678A2 (en) 1994-03-01 1995-03-01 Highly pipelined bus architecture

Publications (2)

Publication Number Publication Date
DE69531933D1 DE69531933D1 (de) 2003-11-20
DE69531933T2 true DE69531933T2 (de) 2004-08-12

Family

ID=26901290

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69531933T Expired - Lifetime DE69531933T2 (de) 1994-03-01 1995-03-01 Busarchitektur in hochgradiger pipeline-ausführung

Country Status (8)

Country Link
US (1) US5796977A (de)
EP (2) EP1215584A3 (de)
JP (1) JP3660679B2 (de)
KR (1) KR100360064B1 (de)
AU (1) AU1973595A (de)
BR (1) BR9506997A (de)
DE (1) DE69531933T2 (de)
WO (1) WO1995024678A2 (de)

Families Citing this family (60)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5615343A (en) 1993-06-30 1997-03-25 Intel Corporation Method and apparatus for performing deferred transactions
JP3872118B2 (ja) * 1995-03-20 2007-01-24 富士通株式会社 キャッシュコヒーレンス装置
US5673413A (en) * 1995-12-15 1997-09-30 International Business Machines Corporation Method and apparatus for coherency reporting in a multiprocessing system
WO1997034237A2 (en) * 1996-03-15 1997-09-18 Sun Microsystems, Inc. Split transaction snooping bus and method of arbitration
US5983326A (en) * 1996-07-01 1999-11-09 Sun Microsystems, Inc. Multiprocessing system including an enhanced blocking mechanism for read-to-share-transactions in a NUMA mode
KR100454652B1 (ko) * 1997-04-11 2005-01-13 엘지전자 주식회사 하이파이버스시스템의주기억장치
US6260117B1 (en) 1997-09-18 2001-07-10 International Business Machines Corporation Method for increasing efficiency in a multi-processor system and multi-processor system with increased efficiency
US6070231A (en) * 1997-12-02 2000-05-30 Intel Corporation Method and apparatus for processing memory requests that require coherency transactions
US6029225A (en) * 1997-12-16 2000-02-22 Hewlett-Packard Company Cache bank conflict avoidance and cache collision avoidance
US6292906B1 (en) * 1997-12-17 2001-09-18 Intel Corporation Method and apparatus for detecting and compensating for certain snoop errors in a system with multiple agents having cache memories
US6460119B1 (en) * 1997-12-29 2002-10-01 Intel Corporation Snoop blocking for cache coherency
US6138218A (en) * 1998-02-17 2000-10-24 International Business Machines Corporation Forward progress on retried snoop hits by altering the coherency state of a local cache
US6330591B1 (en) * 1998-03-09 2001-12-11 Lsi Logic Corporation High speed serial line transceivers integrated into a cache controller to support coherent memory transactions in a loosely coupled network
US6269360B1 (en) * 1998-04-24 2001-07-31 International Business Machines Corporation Optimization of ordered stores on a pipelined bus via self-initiated retry
US6546429B1 (en) * 1998-09-21 2003-04-08 International Business Machines Corporation Non-uniform memory access (NUMA) data processing system that holds and reissues requests at a target processing node in response to a retry
US6216190B1 (en) * 1998-09-30 2001-04-10 Compaq Computer Corporation System and method for optimally deferring or retrying a cycle upon a processor bus that is destined for a peripheral bus
US7555603B1 (en) * 1998-12-16 2009-06-30 Intel Corporation Transaction manager and cache for processing agent
US6732208B1 (en) 1999-02-25 2004-05-04 Mips Technologies, Inc. Low latency system bus interface for multi-master processing environments
US6397304B1 (en) * 1999-06-16 2002-05-28 Intel Corporation Method and apparatus for improving system performance in multiprocessor systems
US6490642B1 (en) 1999-08-12 2002-12-03 Mips Technologies, Inc. Locked read/write on separate address/data bus using write barrier
US6493776B1 (en) 1999-08-12 2002-12-10 Mips Technologies, Inc. Scalable on-chip system bus
US6393500B1 (en) 1999-08-12 2002-05-21 Mips Technologies, Inc. Burst-configurable data bus
US6681283B1 (en) 1999-08-12 2004-01-20 Mips Technologies, Inc. Coherent data apparatus for an on-chip split transaction system bus
US6604159B1 (en) 1999-08-12 2003-08-05 Mips Technologies, Inc. Data release to reduce latency in on-chip system bus
US6519685B1 (en) 1999-12-22 2003-02-11 Intel Corporation Cache states for multiprocessor cache coherency protocols
US6681320B1 (en) 1999-12-29 2004-01-20 Intel Corporation Causality-based memory ordering in a multiprocessing environment
US6609171B1 (en) 1999-12-29 2003-08-19 Intel Corporation Quad pumped bus architecture and protocol
US6438737B1 (en) 2000-02-15 2002-08-20 Intel Corporation Reconfigurable logic for a computer
US6745297B2 (en) * 2000-10-06 2004-06-01 Broadcom Corporation Cache coherent protocol in which exclusive and modified data is transferred to requesting agent from snooping agent
US6546468B2 (en) * 2000-12-27 2003-04-08 International Business Machines Corporation Multiprocessor system snoop scheduling mechanism for limited bandwidth snoopers performing directory update
US6601145B2 (en) 2000-12-27 2003-07-29 International Business Machines Corporation Multiprocessor system snoop scheduling mechanism for limited bandwidth snoopers that uses dynamic hardware/software controls
US6742160B2 (en) 2001-02-14 2004-05-25 Intel Corporation Checkerboard parity techniques for a multi-pumped bus
US6546470B1 (en) 2001-03-12 2003-04-08 International Business Machines Corporation Multiprocessor system snoop scheduling mechanism for limited bandwidth snoopers with banked directory implementation
US6546469B2 (en) 2001-03-12 2003-04-08 International Business Machines Corporation Multiprocessor system snoop scheduling mechanism for limited bandwidth snoopers
US7076627B2 (en) 2001-06-29 2006-07-11 Intel Corporation Memory control for multiple read requests
US7114038B2 (en) * 2001-12-28 2006-09-26 Intel Corporation Method and apparatus for communicating between integrated circuits in a low power mode
US7085889B2 (en) 2002-03-22 2006-08-01 Intel Corporation Use of a context identifier in a cache memory
US7343395B2 (en) * 2002-03-29 2008-03-11 Intel Corporation Facilitating resource access using prioritized multicast responses to a discovery request
EP1376373B1 (de) * 2002-06-20 2006-05-31 Infineon Technologies AG Anordnung von zwei Geräten, verbunden durch einen Kreuzvermittlungsschalter
US8185602B2 (en) 2002-11-05 2012-05-22 Newisys, Inc. Transaction processing using multiple protocol engines in systems having multiple multi-processor clusters
US6986010B2 (en) * 2002-12-13 2006-01-10 Intel Corporation Cache lock mechanism with speculative allocation
US7043656B2 (en) * 2003-01-28 2006-05-09 Hewlett-Packard Development Company, L.P. Methods and apparatus for extending a phase on an interconnect
US20040226011A1 (en) * 2003-05-08 2004-11-11 International Business Machines Corporation Multi-threaded microprocessor with queue flushing
US7747733B2 (en) 2004-10-25 2010-06-29 Electro Industries/Gauge Tech Power meter having multiple ethernet ports
US20060143384A1 (en) * 2004-12-27 2006-06-29 Hughes Christopher J System and method for non-uniform cache in a multi-core processor
US7788240B2 (en) * 2004-12-29 2010-08-31 Sap Ag Hash mapping with secondary table having linear probing
US7360008B2 (en) * 2004-12-30 2008-04-15 Intel Corporation Enforcing global ordering through a caching bridge in a multicore multiprocessor system
US7886086B2 (en) * 2005-02-03 2011-02-08 International Business Machines Corporation Method and apparatus for restricting input/output device peer-to-peer operations in a data processing system to improve reliability, availability, and serviceability
US8490107B2 (en) 2011-08-08 2013-07-16 Arm Limited Processing resource allocation within an integrated circuit supporting transaction requests of different priority levels
US10862784B2 (en) 2011-10-04 2020-12-08 Electro Industries/Gauge Tech Systems and methods for processing meter information in a network of intelligent electronic devices
US10771532B2 (en) 2011-10-04 2020-09-08 Electro Industries/Gauge Tech Intelligent electronic devices, systems and methods for communicating messages over a network
US20170063566A1 (en) * 2011-10-04 2017-03-02 Electro Industries/Gauge Tech Internet of things (iot) intelligent electronic devices, systems and methods
US11816465B2 (en) 2013-03-15 2023-11-14 Ei Electronics Llc Devices, systems and methods for tracking and upgrading firmware in intelligent electronic devices
US11734396B2 (en) 2014-06-17 2023-08-22 El Electronics Llc Security through layers in an intelligent electronic device
US10958435B2 (en) 2015-12-21 2021-03-23 Electro Industries/ Gauge Tech Providing security in an intelligent electronic device
US11754997B2 (en) 2018-02-17 2023-09-12 Ei Electronics Llc Devices, systems and methods for predicting future consumption values of load(s) in power distribution systems
US11734704B2 (en) 2018-02-17 2023-08-22 Ei Electronics Llc Devices, systems and methods for the collection of meter data in a common, globally accessible, group of servers, to provide simpler configuration, collection, viewing, and analysis of the meter data
US11686594B2 (en) 2018-02-17 2023-06-27 Ei Electronics Llc Devices, systems and methods for a cloud-based meter management system
US11863589B2 (en) 2019-06-07 2024-01-02 Ei Electronics Llc Enterprise security in meters
US11941428B2 (en) 2021-04-16 2024-03-26 Apple Inc. Ensuring transactional ordering in I/O agent

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5353416A (en) * 1989-10-25 1994-10-04 Zenith Data Systems Corporation CPU lock logic for corrected operation with a posted write array
JPH04119445A (ja) * 1990-09-11 1992-04-20 Canon Inc 計算機システム
US5339399A (en) * 1991-04-12 1994-08-16 Intel Corporation Cache controller that alternately selects for presentation to a tag RAM a current address latch and a next address latch which hold addresses captured on an input bus
US5218564A (en) * 1991-06-07 1993-06-08 National Semiconductor Corporation Layout efficient 32-bit shifter/register with 16-bit interface
US5327570A (en) * 1991-07-22 1994-07-05 International Business Machines Corporation Multiprocessor system having local write cache within each data processor node
US5345569A (en) * 1991-09-20 1994-09-06 Advanced Micro Devices, Inc. Apparatus and method for resolving dependencies among a plurality of instructions within a storage device
GB2260628A (en) * 1991-10-11 1993-04-21 Intel Corp Line buffer for cache memory
US5353415A (en) * 1992-10-02 1994-10-04 Compaq Computer Corporation Method and apparatus for concurrency of bus operations
US5420991A (en) * 1994-01-04 1995-05-30 Intel Corporation Apparatus and method for maintaining processing consistency in a computer system having multiple processors

Also Published As

Publication number Publication date
JPH09510308A (ja) 1997-10-14
US5796977A (en) 1998-08-18
EP0748481A1 (de) 1996-12-18
EP1215584A3 (de) 2004-04-21
EP0748481A4 (de) 2000-07-05
EP1215584A2 (de) 2002-06-19
BR9506997A (pt) 1997-11-18
WO1995024678A2 (en) 1995-09-14
EP0748481B1 (de) 2003-10-15
KR100360064B1 (ko) 2003-03-10
DE69531933D1 (de) 2003-11-20
AU1973595A (en) 1995-09-25
JP3660679B2 (ja) 2005-06-15
WO1995024678A3 (en) 1995-10-12

Similar Documents

Publication Publication Date Title
DE69531933T2 (de) Busarchitektur in hochgradiger pipeline-ausführung
DE69721643T2 (de) Multiprozessorsystem ausgestaltet zur effizienten Ausführung von Schreiboperationen
DE10085385B3 (de) Vierfach gepumpte Bus-Architektur und Protokoll
DE69729243T2 (de) Multiprozessorsystem mit Vorrichtung zur Optimierung von Spin-Lock-Operationen
DE69724354T2 (de) Ein Mehrprozessorrechnersystem mit lokalen und globalen Adressräumen und mehreren Zugriffsmoden
DE69722079T2 (de) Ein Mehrrechnersystem mit Anordnung zum Durchführen von Blockkopieroperationen
DE69724353T2 (de) Mehrrechnersystem mit einem Drei-Sprung-Kommunikationsprotokoll
DE19782177B4 (de) Verfahren zur Durchführung von TLB-Shootdown-Operationen in einem Multiprozessorsystem
DE69727856T2 (de) Multiprozessorsystem mit Konsistenzfehler-Registrierung mit entsprechendem Verfahren
DE69722512T2 (de) Mehrrechnersystem mit einem die Anzahl der Antworten enthaltenden Kohärenzprotokoll
DE69233655T2 (de) Mikroprozessorarchitektur mit der Möglichkeit zur Unterstützung mehrerer verschiedenartiger Prozessoren
DE69721891T2 (de) Deterministisches Kohärenzprotokoll für verteilten Multicache-Speicher
DE69636452T2 (de) Mehrprozessor-cachespeicherkohärenzprotokoll für einen lokalbus
DE69822534T2 (de) Gemeinsame Speicherbenutzung mit variablen Blockgrössen für symmetrische Multiporzessor-Gruppen
DE69628127T2 (de) Verfahren und Gerät um die Kohärenz in einem Multiprozessorsystem anzuzeigen
DE112012005210B4 (de) Bereitstellen eines gemeinsamen Caching-Agenten für ein Kern- und integriertes Ein-/Ausgabe-(IO)-Modul
DE4218003C2 (de) Cache-Steuereinrichtung für ein sekundäres Cache-Speichersystem
DE69936060T2 (de) Verfahren und Vorrichtung für eine verbesserte Schnittstelle zwischen Computerkomponenten
DE19983737B3 (de) System zum Neuordnen von Befehlen, die von einer Speichersteuerung zu Speichervorrichtungen ausgegeben werden, unter Verhinderung von Kollision
DE102009022151B4 (de) Verringern von Invalidierungstransaktionen aus einem Snoop-Filter
DE102013218370B4 (de) Akquirierung spekulativer Genehmigung für gemeinsam genutzten Speicher
DE10262164B4 (de) Computersystem mit einer hierarchischen Cacheanordnung
DE112017001959T5 (de) Cachespeicher-Zugriff
DE102009023898A1 (de) Optimierung von gleichzeitigen Zugriffen in einem verzeichnisbasierten Kohärenzprotokoll
DE112013000891T5 (de) Verbessern der Prozessorleistung für Befehlsfolgen, die Sperrbefehle enthalten

Legal Events

Date Code Title Description
8364 No opposition during term of opposition