DE19636381C1 - Bus mit anforderungsabhängiger Anpassung der in beiden Richtungen zur Verfügung stehenden Bandbreite - Google Patents

Description

Die Erfindung betrifft einen Bus zur Übertragung von Information in einem Datenverarbeitungssystem, sowie ein Verfahren zur Übertragung von Information über einen Bus in einem Datenverarbeitungssystem.

Um Informationen zwischen funktionalen Einheiten in einem Datenverarbeitungssystem zu übertragen, sind Bussysteme bekannt, die eine Datenübertragung lediglich in einer Richtung erlauben, sogenannte unidirektionale Busse.

Desweiteren ist bekannt, zwischen zwei funktionalen Einheiten A und B bidirektionale Busse zu verwenden, die zwei mögliche Übertragungsrichtungen aufweisen. Informationen können entweder auf der vollen Bandbreite des Busses von A nach B, oder aber von B nach A übertragen werden. Wenn also eine Informationsübertragung ansteht, muß der Sender zuerst das Senderecht auf dem Bus zugeteilt bekommen, bevor er die Daten übertragen kann.

Dieser Modus ist deshalb für die Übertragung zeitkritischer Commands wenig geeignet, da bis zur Zuteilung des "Right to send" Wartezeiten auftreten. Insbesondere zeitkritisch sind Kurzbefehle zur Synchronisation und zum Timing eines Protokollablaufs.

Man hat deshalb zur Übertragung dieser Befehle eigene Commandbusse sowie eine Vielzahl von Kontroll-Leitungen eingeführt. Dadurch war zwar eine korrekte Übermittlung der Commands unter Beachtung der zeitlichen Limits möglich, allerdings war der Aufwand an Leitungen für einen derartigen Bus erheblich.

Aus der US Patentschrift 4 250 547, "Information Processing Apparatus Capable Of Effecting Parallel Processings By Using A Divided Common Bus" von K. Matsumoto sind ein Bus und ein Datenübertragungsverfahren für einen Bus beschrieben, bei dem ein Bus (22, 23) entweder als für alle Busteilnehmer gemeinsamer Bus mit voller Bitbreite betrieben werden kann, oder dieser Bus in mindestens 2 Gruppen von Übertragungsleitungen geteilt werden kann, die unabhängig voneinander eine Datenübertragung durchführen. Dadurch ist es insbesondere möglich, eine Datenübertragung zwischen peripheren Eingabe-/Ausgabe-Einheiten und dem Hauptspeicher auf der einen Gruppe von Übertragungsleitungen durchzuführen, ohne die Ausführung eines Tasks auf dem an die zweite Gruppe von Übertragungsleitungen gekoppelten Prozessor unterbrechen zu müssen. Eine Verbindung zwischen den verschiedenen Gruppen von Busübertragungsleitungen kann mittels einer Treibereinheit hergestellt werden, so daß die CPU mit Hauptspeicher und Peripherie kommunizieren kann.

Insbesondere in Multiprozessorsystemen, wo viele Prozessoren über Prozessorbusse mit einem gemeinsamen L2-Cache verbunden werden müssen, sind die am L2 verfügbaren Pins knapp. Die Zahl dieser Pins kann aus verbindungstechnischen Gründen nicht beliebig vergrößert werden. Je besser man nun eine hohe Übertragungsbandbreite zwischen Cache und Prozessor mit einer geringen Zahl von Leitungen realisieren kann, desto mehr Prozessoren können an den L2 gekoppelt werden.

Aufgabe der Erfindung ist deshalb, einen Bus zur Verfügung zu stellen, der zum einen zeitkritische Befehle zwischen den Übertragungspartnern unter Beachtung der Zeitlimits übertragen kann, und der zum anderen die zur Verfügung stehenden Busleitungen in Hinblick auf die Übertragungsbandbreite optimal nutzt.

Diese Aufgabe wird erfindungsgemäß durch einen Bus gelöst, der einen ersten Zustand aufweist, in dem die Übertragungsleitungen in zwei Gruppen mit entgegengesetzter Übertragungsrichtung eingeteilt sind, wobei die Übertragungsrichtung mindestens einer Gruppe von Übertragungsleitungen umkehrbar ist, der einen zweiten Zustand aufweist, in dem die Übertragungsrichtung der zwei Gruppen von Übertragungsleitungen übereinstimmt, und der Mittel zum Umschalten des Busses zwischen dem ersten und dem zweiten Zustand aufweist.

Desweiteren wird die Aufgabe durch ein Verfahren gelöst, bei dem die Übertragungsleitungen des Busses in zwei Gruppen eingeteilt werden, und wobei von einem ersten Zustand, in dem die beiden Gruppen entgegengesetzte Übertragungsrichtung aufweisen, zu einem zweiten Zustand, in dem die Übertragungsrichtung der zwei Gruppen von Übertragungsleitungen übereinstimmt, umgeschaltet wird.

Im ersten Zustand des Busses können Befehle in beiden Richtungen verzögerungsfrei übertragen werden. Dadurch wird es möglich, den aufgesplitteten Bus zur Übertragung von Befehlen zu verwenden. Wenn eine Datenübertragung erfolgen soll, ist es möglich, zum zweiten Zustand des Busses überzugehen, bei dem die Übertragungsrichtung beider Gruppen von Busleitungen übereinstimmt. Dadurch können Daten bei Bedarf mit der vollen Bandbreite des Busses übertragen werden. Auf diese Weise ist eine flexible Anpassung der Busbandbreite an die jeweiligen Erfordernisse möglich.

Bei einer weiteren vorteilhaften Ausgestaltung der Erfindung sind die Übertragungsleitungen der einen Gruppe von Übertragungsleitungen bidirektionale Leitungen, deren Übertragungsrichtung umschaltbar ist, und die Übertragungsleitungen der anderen Gruppe von Übertragungsleitungen sind unidirektionale Leitungen, deren Übertragungsrichtung feststeht.

Der Vorteil dieser Ausführungsform ist, daß in einer Richtung des Busses von der halben Busbandbreite auf die volle Busbandbreite übergegangen werden kann. Insofern kann ein vorteilhafter Übertragungsmodus für diejenige Busrichtung vorgesehen werden, in der der Großteil des Datenaustauschs erfolgt. Dadurch, daß eine Bushälfte aus unidirektionalen Leitungen besteht, ist der Hardwareaufwand für die Implementierung dieser Lösung deutlich geringer als bei einem Bus gemäß dem Stand der Technik, bei dem alle Leitungen als bidirektionale Leitungen ausgeführt sein müssen.

Bei einer weiteren vorteilhaften Ausführungsform der Erfindung sind die Übertragungsleitungen beider Gruppen von Übertragungsleitungen bidirektionale Leitungen, deren Übertragungsrichtung umschaltbar ist.

Bei dieser Lösung kann in beiden Busrichtungen ein Übergang von einer Datenübertragung mit halber Bandbreite zu einer Datenübertragung mit voller Bandbreite stattfinden. Dies erlaubt eine besonders flexible Dimensionierung der für die Befehls- und Datenübertragung erforderlichen Bandbreite. Insbesondere in Systemen, in denen sich die zu übertragenden Datenmengen in der einen und der anderen Richtung ungefähr entsprechen, ist diese Lösung von Vorteil.

Bei einer weiteren Ausführungsform der Erfindung ist für die beiden Übertragungsrichtungen jeweils mindestens eine Tagleitung vorhanden, wobei der Status der Tagleitung den Typ der auf dem Bus übertragenen Information spezifiziert.

Auf diese Weise kann auf Empfängerseite eine typspezifische Verarbeitung der übertragenen Information erfolgen. Insbesondere ist es möglich, die empfangene Information sofort in die richtigen Register zu schreiben.

Bei einer weiteren Ausführungsform der Erfindung erfolgt die Umschaltung zwischen dem ersten und dem zweiten Zustand in Abhängigkeit vom Status der Tagleitungen.

Auf diese Art und Weise kann eine Anforderung, die volle Übertragungsbandbreite zugeteilt zu bekommen, zwischen den Partnern der Übertragung schnell übermittelt werden.

Bei einer weiteren Ausführungsform der Erfindung erfolgt die Umschaltung zwischen dem ersten und dem zweiten Zustand in Abhängigkeit von Informationen, die über den Bus übertragen werden.

Bei dieser Ausführungsform können Tagleitungen, die speziell für den Übergang des Busses vom ersten zum zweiten Zustand - und umgekehrt - verantwortlich sind, entfallen. Dadurch werden Pins gespart.

Bei einer weiteren vorteilhaften Ausführungsform findet die Übertragung von Tagsignalen über die Tagleitungen um einen Bruchteil eines Taktzyklus früher statt als die Übertragung der Information über den Bus.

Auf diese Art und Weise wird auf Empfängerseite die zur Verfügung stehende Zeit, um eine typspezifische Verarbeitung der ankommenden Bussignale zu veranlassen, vergrößert. Es ist auf diese Weise auch möglich, eine Vorverarbeitung der ankommenden Information zu veranlassen.

Bei einer weiteren vorteilhaften Ausführungsform der Erfindung wird für den Fall, daß sich der Bus im Grundzustand befindet, daß Information in der einen Übertragungsrichtung übertragen werden soll, daß aber der Bus in der entgegengesetzten Übertragungsrichtung noch aktiv ist, der Übergang vom ersten Zustand in den zweiten Zustand solange aufgeschoben, bis die Busaktivität in der entgegengesetzten Übertragungsrichtung abgeschlossen ist.

Der Vorteil dieser Ausführungsform ist, daß für den Fall, daß die eine Bushälfte noch belegt ist, eine Datenübertragung in Gegenrichtung mit halber Busbandbreite begonnen werden kann, und in dem Moment, in dem die Übertragung auf der Gegenseite abgeschlossen ist, auf die volle Busbandbreite übergegangen werden kann. Dies erlaubt eine sehr flexible Nutzung des Busses.

FIGURENBESCHREIBUNG

Fig. 1 zeigt eine Busstruktur, die aus einem bidirektionalen Datenbus, zwei unidirektionalen Commandbussen, sowie Kontroll-Leitungen in beiden Richtungen besteht.

Fig. 2A stellt die in Fig. 1 gezeigte Busstruktur noch einmal schematisch dar.

Fig. 2B zeigt die erfindungsgemäße Busstruktur, die einen bidirektionalen Bus zur Übertragung von Daten und Befehlen in beide Richtungen sowie Kontroll- bzw. Tag-Leitungen umfaßt.

Fig. 2C zeigt eine Sonderform der erfindungsgemäßen Busstruktur, bei der lediglich eine Bushälfte aus bidirektionalen Leitungen, die andere Bushälfte dagegen aus unidirektionalen Leitungen besteht.

Fig. 3A stellt dar, wie die einzelnen Tag-Leitungen den beiden Bushälften zugeordnet werden können.

Fig. 3B zeigt eine Möglichkeit, wie die auf dem Bus übertragene Information mittels der Tag-Leitungen codiert werden kann.

Fig. 4 zeigt eine technische Realisierung der in Fig. 2B vorgestellten Busstruktur.

Fig. 5 stellt eine technische Lösung für die in Fig. 2C gezeigte Sonderform des erfindungsgemäßen Busses dar.

Fig. 6A zeigt den Ablauf des Befehls "Cache Line Invalidate".

Fig. 6B ist die Response auf diesen Befehl dargestellt.

Fig. 7 stellt den Ablauf des Store-Befehls entsprechend der erfindungsgemäßen Lösung nach Fig. 2B dar.

Fig. 8 zeigt den Ablauf eines Store-Befehls, wenn eine Busstruktur gemäß Fig. 2C realisiert ist.

Fig. 9A zeigt den Ablauf des Fetch-Befehls.

Fig. 9B stellt den Ablauf der Response auf einen Fetch-Befehl sowie die Datenübertragung zur PU dar.

Fig. 10A zeigt die Übertragung des Control-Befehls durch den erfindungsgemäßen Bus.

Fig. 10B stellt die Response auf diesen Control-Befehl dar.

Fig. 11A stellt dar, wie mittels eines Sense-Befehls Information über den Status einer funktionellen Einheit angefordert werden kann.

Fig. 11B zeigt die Response auf einen Sense-Befehl.

Fig. 12 zeigt, wie der Übergang der Busstruktur vom Grundzustand zu einem Zustand voller Bandbreite für den Fall, daß eine Bushälfte noch aktiv ist, aufgeschoben werden kann.

Fig. 13A stellt dar, wie während einer Datenübertragung auf dem erfindungsgemäßen Bus die Übertragung eines OP_IM in der gleichen Richtung eingeschleift werden kann.

Fig. 13B zeigt, wie während einer Datenübertragung auf dem erfindungsgemäßen Bus, welche die gesamte Busbandbreite beansprucht, ein OP_IM in der Gegenrichtung übertragen werden kann.

Die zwischen den funktionalen Einheiten eines Computersystems übertragene Information kann in vier Gruppen gegliedert werden: Das sind zum einen die Befehle, durch die die von einer funktionelle Einheit auszuführenden Operationen spezifiziert werden. Zusammen mit diesen Befehlen werden Daten und Speicheradressen als Operanden der Befehle mit übertragen. Weiterhin existieren Kontrollsignale, mit denen zum einen der Status der an der Datenübertragung beteiligten funktionellen Einheiten mitgeteilt werden kann, zum anderen eine Synchronisation der Datenübertragung erfolgt.

Ein Bussystem in einem Computer muß nun alle vier genannten Informationstypen in beiden Richtungen übertragen können. Als Beispiel für ein derartiges Bussystem ist in Fig. 1 ein Prozessorbus gemäß dem Stand der Technik gezeigt. Dieser Prozessorbus verbindet einen Prozessor mit dem Second-Level-Cache (L2). Der gezeigte Bus ist in drei Segmente aufgeteilt:
in einen Datenbus zur Übertragung von Daten und/oder Adressen, in einen Commandbus zur Übertragung von Befehlen, sowie in Leitungen zur Übertragung von Kontrollinformation.

Der Datenbus ist dabei als bidirektionaler Bus ausgeführt. Dies bedeutet, daß beide an der Datenübertragung beteiligten Partner, der Prozessor und der Second-Level-Cache Chip, im Besitz des Senderechts auf den 64 Datenleitungen (102) sein können. Wenn der Prozessor Daten an den L2 übertragen will, so werden diese Daten zunächst in das Data-Out-Register 100 geschrieben, von wo aus sie - vorausgesetzt, der Prozessor hat das Senderecht - über den Sendetreiber 101, die Busleitungen 102 und den empfangsseitigen Treiber 103 zu den Data-In-Registern 106 auf der Empfängerseite, also auf der Seite des L2, übertragen werden.

Im umgekehrten Fall, wenn also der Second-Level-Cache das Recht zum Senden hat, gelangen die Daten über das Data-Out-Register 110 des L2, den sendeseitigen Treiber 109, die Busleitung 102 und den empfangsseitigen Treiber 108 zum Data-In-Register 111 des Prozessors. Die Verwaltung des Senderechts wird über eine Control Unit 104 vorgenommen, deren Ausgangssignal sowohl den prozessorseitigen Sende- und Empfangstreibern (107, 108), als auch den Sende- und Empfangstreibern (109, 103) auf der Cacheseite zugeführt wird. Je nachdem, welchen Pegel das Ausgangssignal der Control Unit 104 hat, werden entweder die beiden Treiber 101 und 103, oder aber die beiden Treiber 109 und 108 aktiviert. Das Ausgangssignal der Control Unit legt also die Datenübertragungsrichtung auf dem Datenbus fest.

Die Leitungen der beiden Command-Busse dagegen sind unidirektional ausgelegt, d. h., es ist von vornherein festgelegt, welcher der beiden an der Datenübertragung teilnehmenden Partner das Senderecht hat. Zur Übertragung von Commands vom Prozessor zum Second-Level-Cache wird das Command zunächst vom Prozessor in das sendeseitige Command-Register 120 geschrieben. Von dort wird es über die fünf Leitungen (121) des Command-Busses zum Second-Level-Cache übertragen, das ankommende Command wird in das dortige Command-Register 122 geschrieben, von wo aus es weiter verarbeitet werden kann. Entsprechend läuft die Übertragung von Commands vom Second-Level-Cache zum Prozessor ab. Wieder wird das Command zunächst in das sendeseitige Command-Register 123 geschrieben, von dort aus über die unidirektionalen Leitungen 124 zum Prozessor übertragen, und in das prozessorseitige Command-Register 125 geschrieben.

Desweiteren existieren eine ganze Reihe von unidirektionalen Kontroll-Leitungen vom Prozessor zum L2, und auch vom L2 zum Prozessor. So gibt es beispielsweise in beiden Richtungen je eine Kontroll-Leitung "address valid" (130, 138), welche anzeigt, daß auf dem bidirektionalen Bus valide Adreßdaten übertragen werden. In Analogie dazu gibt es in beiden Richtungen je eine Kontroll-Leitung "data valid", die anzeigt, daß die auf dem Bus übertragenen Daten valide sind. Die Übertragung eines Commands über den Command Bus wird angezeigt, indem das jeweilige Kontrollsignal "command valid" (131, 139) gesetzt wird. Desweiteren gibt es in jeder Richtung Request- und Response-Leitungen, Leitungen zum Anzeigen von Übertragungsfehlern, sowie weitere Kontroll-Leitungen, deren Aufgabe es ist, einen korrekten Ablauf des Busprotokolls zu gewährleisten.

Die Kontrollsignale werden vom Prozessor zum L2 übertragen, indem sie vom Prozessor in ein sendeseitiges Kontrollregister 126 geschrieben werden, von dort über eine sendeseitigen Treiber, über die jeweilige unidirektionale Kontroll-Leitung und den empfangsseitigen Treiber zum empfangsseitigen Kontrollregister 133, gelangen, aus dem sie vom L2 ausgelesen werden können. Die Übertragung von Kontrollsignalen vom L2 zum Prozessor verläuft analog.

In Fig. 2A ist die in Fig. 1 beschriebene Buskonfiguration, die dem Stand der Technik entspricht, noch einmal schematisch dargestellt. In Abhängigkeit von den Commands, die auf den beiden unidirektionalen Befehlsbussen 203 und 204 übertragen werden, und vom Status der Kontroll-Leitungen 200 wird das Senderecht auf dem bidirektionalen Daten- und Adreßbus zugeteilt. Für den bidirektionalen Bus gibt es zwei mögliche Zustände. Es seien A und B die beiden durch den bidirektionalen Bus verbundenen funktionalen Einheiten. Im ersten Zustand 201 ist die Einheit A im Besitz des Senderechts auf sämtlichen Busleitungen, so daß sie Daten an B mit der vollen Bandbreite des Busses übertragen kann. Im zweiten Zustand 202 ist die Einheit A im Empfangsmodus, das Senderecht hat nun die Einheit B.

Um vom ersten zum zweiten Zustand zu wechseln, oder umgekehrt, ist es erforderlich, die Richtung der Datenübertragung auf sämtlichen bidirektionalen Busleitungen umzukehren. Dies geschieht, indem das Ausgangssignal der BIDI Control Unit 104 invertiert wird; allerdings erfordert ein derartiges Umschalten der Übertragungsrichtung des Busses einige Prozessorcycles.

Um Signalleitungen einzusparen und den Bus besser auszunutzen, könnte man auf die Idee kommen, nicht nur Daten und Adressen, sondern auch die Befehle über den bidirektionalen Bus zwischen den Einheiten zu übertragen. Auf diese Weise könnten zwar die beiden unidirektionalen Befehlsbusse (203, 204) komplett entfallen, man müßte dies jedoch mit einem eklatanten Performanceverlust bezahlen. Wenn ein Kurzbefehl von A nach B gesandt werden soll, auf dem bidirektionalen Bus aber noch eine Datenübertragung von B nach A ausgeführt wird, so muß zunächst die Datenübertragung unterbrochen oder aber zu Ende ausgeführt werden, anschließend muß die Übertragungsrichtung des Busses geändert werden, und erst dann kann der Kurzbefehl von A nach B übermittelt werden. Die auf diese Weise erzeugten Verzögerungen lassen eine derartige Lösung als wenig vorteilhaft erscheinen.

In der erfindungsgemäßen Lösung, die in Fig. 2B vorgestellt wird, werden diese Probleme durch ein Aufsplitten des bidirektionalen Busses gelöst. Im Grundzustand des Busses ist für die eine Bushälfte 211 bzw. für den einen Teil der Busleitungen eine Datenübertragungsrichtung von Einheit A nach Einheit B vorgesehen, während auf der anderen Hälfte des Busses 212 bzw. auf dem anderen Teil der Busleitungen die Datenübertragung von B nach A erfolgt. Durch den so definierten Grundzustand können Befehle zwischen den beiden durch den Bus verbundenen funktionalen Einheiten auf sehr schnelle Art und Weise in beiden Richtungen ausgetauscht werden, da das zeitaufwendige Umschalten des Busses vollständig entfällt. Befehle, Daten und Adressen können auf diesem im Grundzustand gesplitteten Bus instantan, allerdings nur auf der halben Bandbreite des Busses übermittelt werden. Für kurze Befehle und geringe zu übertragende Datenmengen stellt die verminderte Bandbreite keinen eklatanten Nachteil dar. Lediglich bei großen Datenmengen, die zwischen den durch den Bus gekoppelten Einheiten ausgetauscht werden sollen, wäre eine Erhöhung der zur Verfügung stehenden Bandbreite vorteilhaft. Auf dem Prozessorbus, der einen Prozessor mit dem Cache verbindet, treten große Datenmengen lediglich im Zusammenhang mit dem Store- und dem Fetch-Befehl auf.

Erfindungsgemäß ist dazu vorgesehen, vom Grundzustand des Busses zu einem Zustand voller Bandbreite überzugehen, indem die Übertragungsrichtung auf der einen (211) oder der anderen (212) Hälfte des Busses in Anhängigkeit von den zu übertragenden Daten invertiert werden kann. Soll beispielsweise eine größere Datenmenge von A nach B übertragen werden, so wird die Übertragungsrichtung der Bushälfte 211 nicht geändert (213), die Übertragungsrichtung der Bushälfte 212 dagegen wird geändert (214). Auf diese Weise können Daten von A nach B über die volle Busbandbreite übertragen werden. Wenn die Datenübertragung beendet ist, wird die Datenübertragungsrichtung der Bushälfte 214 erneut umgekehrt (212), so daß wieder der Grundzustand erreicht wird.

Analog stellt sich der Fall dar, wenn eine Datenmenge von B nach A übertragen werden soll. In diesem Fall bleibt die Übertragungsrichtung auf der Bushälfte 212 unverändert (216), dagegen wird die Übertragungsrichtung auf der Bushälfte 211 geändert (215). Wieder kann durch diese flexible Bandbreitenanpassung im Bedarfsfall die volle Bandbreite zur Verfügung gestellt werden.

Auch bei diesem Buskonzept ist es erforderlich, zusätzlich zu den Befehlen, Daten und Adressen Kontrollsignale zu übertragen, um ein korrektes Timing des Protokollablaufs sicherzustellen. Dazu sind wiederum eigene Kontroll-Leitungen 210 vorgesehen. Allerdings kann die Zahl der notwendigen Kontroll-Leitungen gegenüber dem Stand der Technik deutlich reduziert werden. Der Grund dafür ist, daß das Senden und Empfangen von Befehlen, Daten und Adressen nun ja nicht völlig unabhängig voneinander stattfinden kann, sondern in einer bestimmten zeitlichen Reihenfolge auf ein und demselben Bus erfolgt. Insofern können während der Übertragung eines Befehls keine Daten übertragen werden, und der während der Übertragung von Daten liegt mit Sicherheit keine Adresse an. Daher ist es lediglich erforderlich, die auf dem Bus anliegende Information typgemäß zu spezifizieren, was durch Verwendung einer geeigneten Kodierung mit Hilfe einiger weniger Tag-Leitungen bewerkstelligt werden kann. Dadurch, daß Befehle, Daten und Adressen über einen gemeinsamen Bus übertragen werden und insofern zwingend serialisiert sind, kann also zusätzlich die Zahl der notwendigen Kontroll-Leitungen verringert werden.

Eine Variante der erfindungsgemäßen Lösung für ein neuartiges Buskonzept ist in Fig. 2C dargestellt. Analog zu Fig. 2B ist der Bus im Grundzustand in zwei Hälften (221, 222) gesplittet, wobei auf der einen Hälfte 221 eine Übertragung von A nach B, auf der anderen Hälfte 222 eine Übertragung von B nach A vorgesehen ist. Wieder kann eine Anpassung der Bandbreite in Abhängigkeit von den zu übertragenden Daten vorgenommen werden, im Unterschied von der in Fig. 2B gezeigten Lösung jedoch nur in einer Richtung: Lediglich die Übertragungsrichtung auf der Bushälfte 221 kann invertiert werden (223). Da die Übertragungsrichtung auf der Bushälfte 222 unverändert erhalten bleibt (224), können die Busleitungen dieser Bushälfte als unidirektionale Leitungen ausgelegt werden. Der Hardwareaufwand wird dadurch, daß lediglich eine Bushälfte bzw. ein Teil der Busleitungen bidirektional ausgeführt werden muß, deutlich verringert.

Genau wie bei der Lösung nach Fig. 2B kann auch bei der Lösung nach Fig. 2C die Zahl der erforderlichen Kontroll-Leitungen 220 gegenüber dem Stand der Technik deutlich verringert werden, da sich auch bei der in Fig. 2C gezeigten Busstruktur eine Serialisierung von Befehlen, Daten und Adressen zwingend ergibt. Eine geringe Zahl von Kontroll-Leitungen genügt, um den Typ der auf dem Bus anliegenden Information geeignet zu spezifizieren.

Will man das Konzept, lediglich eine Bushälfte bidirektional auszulegen, auf den Prozessorbus zwischen Prozessor und Cache anwenden, so stellt sich die Frage, für welche der beiden Datenübertragungsrichtungen die Möglichkeit der Nutzung der vollen Busbandbreite vorgesehen werden sollte. Die beiden für die Datenübertragung zwischen L2 und Prozessor relevanten Befehle sind "Store" und "Fetch". Aus statistischen Analysen ergibt sich, daß eine Datenübertragung aufgrund eines Fetch-Befehls mehr als doppelt so häufig erfolgt wie eine Datenübertragung aufgrund eines Store-Befehls. Insofern ist es sinnvoll, für den Datenübertragungsweg vom L2 zum Prozessor die Möglichkeit vorzusehen, auf volle Busbandbreite zu schalten, da dann der häufigere Fetch entsprechend schneller durchgeführt werden kann. Ein weiterer Grund, dies zu tun, ergibt sich daraus, daß der Prozessor nach Aussenden eines Fetch-Requests auf die angeforderten Daten wartet. Erst wenn die Daten eintreffen, kann der anfordernde Prozessor mit der Verarbeitung fortfahren. Daraus ergibt sich, daß sich die aufgrund eines Fetch-Befehls erfolgende Datenübertragung direkt auf die Performance auswirkt, und dies unterscheidet "Fetch" ganz wesentlich von "Store".

In Fig. 3A und 3B ist eine Möglichkeit gezeigt, wie der Typ der durch den erfindungsgemäßen Bus übertragenen Information mittels eigens dafür vorgesehener Tag-Leitungen spezifiziert werden kann. Dazu werden der Bushälfte A (303) die beiden Tag-Leitungen 1A und 2A (301), der Bushälfte B (304) die beiden Tag-Leitungen IB und 2B (302) zugeordnet. In Fig. 3B ist anhand eines Beispiels explizit gezeigt, wie die Art der übertragenen Information mit Hilfe der Tag-Leitungen kodiert werden kann. Das Kürzel OP_IM steht für "Immediate Operation" und bezeichnet Kurzbefehle, die keine weiteren Argumente bzw. Operanden erfordern. Wenn eine derartige "Immediate Operation" auf dem Bus übertragen wird, befindet sich die Tag-Leitung 1 (also die Leitung 1A für Bushälfte A (303) bzw. 1B für die Bushälfte B (304) ) auf "high", während sich die Tag-Leitung 2 (also die Tag-Leitung 2A für die Bushälfte A (303) bzw. die Tag-Leitung 2B für die Bushälfte B (304) ) auf "low" befindet.

Als "Operation Identifiers", abgekürzt OP_ID, werden alle Commands und Responses codiert, deren Übertragung mehr als einen Prozessorcycle erfordert. Auch Adreßinformation, die zusammen mit dem Command bzw. der Response übertragen wird, wird als "Operation Identifier" behandelt. Zur Tag-Codierung eines derartigen OP_ID werden beide Tag-Leitungen, die Tag-Leitung 1 sowie die Tag-Leitung 2, auf "high" gesetzt.

Falls im Anschluß an ein Command oder eine Response eine Datenübertragung auf dem Bus stattfindet, so wird dieser Informationstyp als "Data" codiert. Dazu wird Tag-Leitung 1 auf "low" gelegt, Tag-Leitung 2 auf "high".

Für den Fall, daß gerade keine Busaktivität vorliegt, sind beide Tag-Leitungen, die Tag-Leitung 1 sowie die Tag-Leitung 2, auf "low". Man bezeichnet diesen Busstatus als "No Operation", abgekürzt NOOP.

Um einen optimalen Datentransfer auf einem Bus zu gewährleisten, ist es erforderlich, die Bandbreite des Busses so auszulegen, daß der Bus nur zum Teil ausgelastet ist.

Andernfalls behindern sich Befehle und Datenübertragungen gegenseitig, und die Wartezeit, die ein Befehl durchlaufen muß, bevor er auf den Bus gegeben werden kann, wird im Durchschnitt zu hoch. Typischerweise ist ein Prozessorbus in einem Multiprozessorsystem nur zu etwa 30% ausgelastet, was bedeutet, daß der Bus während 70% der Zeit "idle" ist, sich also im Status "No Operation" befindet.

Die in Fig. 3B dargestellte Art und Weise, die auf einem Bus übertragene Information mit Hilfe von Tag-Leitungen zu spezifizieren, stellt nur eine von vielen möglichen Lösungen dar. So kann es aus Gründen der Übertragungseffizienz sinnvoll sein, einige der im Zusammenhang mit Fig. 1 beschriebenen Kontroll-Leitungen auch bei dem erfindungsgemäßen Buskonzept zu implementieren. Beispielsweise könnte es von Vorteil sein, zusätzlich zu den beschriebenen Tag-Leitungen eine Request- sowie eine Response-Line vorzusehen, welche anzeigen, ob es sich bei dem übertragenen OP_ID bzw. OP_IM um ein Command oder aber um eine Response auf ein Command handelt. Aus der in Fig. 3B skizzierten Lösung wird jedoch deutlich, daß man bereits mit sehr wenigen Tag-Leitungen eine Vielzahl von auf dem Bus übertragenen Informationstypen codieren kann.

In Fig. 4 ist eine Hardware-Implementierung des erfindungsgemäßen Buskonzepts dargestellt. Jede der beiden Bushälften besteht aus bidirektionalen Busleitungen, und insofern kann die Übertragungsrichtung jeder der beiden Bushälften umgeschaltet werden. Die dargestellte Lösung entspricht insofern der in Fig. 2B gezeigten Lösung (BIDI-BIDI Split Bus). Wenn die PU Befehle oder Daten an den L2 senden will, so schreibt sie die zu übermittelnde Information zunächst in die PU-seitigen Out-Register. Für jeden Informationstyp, für "Immediate Operations", für "Operation Identifiers" sowie für "Data" gibt es ein eigenes Out-Register (404, 405, 406). Der Informationstyp wird auch durch den Tag-Status angegeben, der im Tag-Register 401 gespeichert ist. Dieser Tag-Status steuert einen Selektor 408, durch den dasjenige Out-Register ausgewählt wird, dessen Inhalt über den halben Bus 409 übertragen werden soll. Damit auf dem Halbbus 409 eine Übertragung von der PU zum L2 möglich ist, ist es notwendig, daß der PU-seitige Sendetreiber 413 und der L2-seitige Empfangstreiber 415 durch ihre jeweiligen BIDI-Control Units 410 bzw. 411 aktiviert sind. Dies impliziert, daß die PU-seitigen Empfangstreiber 414 und die L2-seitigen Sendetreiber 416 desaktiviert sind, weil diese die Ausgangssignale 411, 412 der BIDI-Control Units an ihren invertierenden Eingängen anliegen haben. Die entsprechend dem Tag-Status durch den Selektor 408 ausgewählte Information wird nun über den PU-seitigen Treiber 413, den Halbbus 409 und den L2-seitigen Treiber 415 in ein empfangsseitiges In-Register geschrieben, wobei wieder der Status der Tag-Leitungen das passende In-Register selektiert. Zur Verfügung stehen ein Register für "Immediate Operations" 420, ein Register für "Operation Identifiers" 421, sowie ein Register für "Data" 422.

Die angekommenen Daten können dann auf der L2-Seite weiterverarbeitet werden. Dazu wird beispielsweise der Inhalt des Registers für "Immediate Operations" 420 einer Immediate Operation Decode Unit 424 zugeleitet, welche die ankommenden OP_IMs in Commands und Controls decodiert. Auf ähnliche Art und Weise können die "Operation Identifiers", welche ja für Commands, Responses und Adressen stehen können, decodiert werden.

Die Übertragung der Tag-Information von der PU zum Second Level Cache geschieht folgendermaßen: Die zwei Tag-Signale werden in das Tag-Register 401 geschrieben. Von dort aus werden sie über einen sendeseitigen Treiber, über die eigentlichen Tag-Leitungen 402 und einen empfangsseitigen Treiber zu einer Tag-Decode-Unit 403 übertragen. Der Status der Tag-Leitungen wird zum einen dem Selektor 408 mitgeteilt, der entsprechend dem Tag die zu übertragende Information auswählt, zum anderen dienen die Tag-Leitungen zur Selektion des passenden In-Registers auf Empfängerseite.

Es ist vorteilhaft, die Übertragung der Tag-Information mittels einer Early-Clock 400 zu takten, deren Taktimpulse um einen Bruchteil eines Cycles früher erfolgen als die Taktimpulse der System-Clock. Auf diese Art und Weise können die Übertragungspfade im Selektor 408 sowie das passende In-Register auf Empfangsseite bereits vor der eigentlichen Datenübertragung bestimmt werden, da diese Datenübertragung mit der System-Clock erfolgt. Die im Vergleich zum Datentransfer verfrühte Übertragung der Tag-Information hat also generell den Vorteil, bereits vor dem Ankommen der Busdaten Informationen über diese zur Verfügung zu stellen, um die ankommenden Daten sofort adäquat prozessieren zu können.

Im Grundzustand des Busses überträgt die erste Bushälfte 409 Informationen von der PU zum L2, während auf der zweiten Bushälfte 436 in Gegenrichtung, also vom L2 zur PU, übertragen wird. Wenn nun auf der PU-Seite Daten zur Übertragung anstehen, die mit der vollen Busbandbreite übertragen werden sollen, so muß die Übertragungsrichtung des Halbbusses 436 umgeschaltet werden. Dies geschieht dadurch, daß die Ausgangssignale 437, 438 der BIDI Control Units 410, 411 invertiert werden, so daß die Treiber 440 und 442, die vorher aktiv waren, deaktiviert werden, während die Treiber 439 und 441 in den aktiven Zustand übergehen. Die höherwertigen vier Datenbytes werden nach wie vor auf dem Halbbus 409 von der PU zum L2 übertragen. Die niederwertigen vier Datenbytes jedoch werden, nachdem sie in das "Data Low" Register 407 geschrieben wurden, über den Treiber 439, den Halbbus 436 und den Treiber 441 in das Empfangsregister "Data Low" 423 des L2 geschrieben, von wo aus sie weiter verarbeitet werden können. Nach Beendigung der Datenübertragung wird der Bus wieder in seinen Grundzustand geschaltet, die Übertragungsrichtung auf dem Halbbus 436 wechselt also wieder.

Die Übertragung in der Gegenrichtung, also vom L2 zur PU, geschieht analog. Auf L2-Seite stehen Out-Register für "Data High" 430, "Data Low" 431, "Operation Identifiers" 432 sowie "Immediate Operations" 433 zur Verfügung, in die die zu übertragende Information vom L2 geschrieben wird. Über den tag-gesteuerten Selektor 434, den Treiber 442, den Halbbus 436 sowie den Treiber 440 gelangen die Informationen dann zu den passenden prozessorseitigen In-Registern für "Data Low", für "Operation Identifiers" 452 sowie für "Immediate Operations" 453. Die Auswahl des dem zu übertragenden Informationstyp entsprechenden In-Registers geschieht in Abhängigkeit von dem dem Halbbus 436 zugeordneten Tag. Zwei Tag-Leitungen werden vom L2 über das Tag-Register 460, über die beiden unidirektionalen Tag-Leitungen 461 und den Tag-Decoder 462 zur PU übertragen.

Auch für Daten, die vom L2 zur PU übertragen werden sollen, gibt es die Möglichkeit, die volle Busbandbreite zu nutzen. Dazu wird der Halbbus 409 mittels der BIDI Controls 410, 411 umgepolt, anschließend können die höherwertigen vier Datenbytes über das Out-Register "Data High" (430), den Halbbus 409 und das In-Register "Data High" (450) zur PU übertragen werden. Die niederwertigen vier Datenbytes werden wie gehabt über den Halbbus 436 übertragen. Nach Abschluß der Datenübertragung vom L2 zur PU geht der Bus wieder in seinen Grundzustand über.

In Fig. 5 ist eine Hardwareimplementierung der in Fig. 2C dargestellten erfindungsgemäßen Lösung gezeigt. Hier ist die eine Bushälfte 508, die Daten und Commands von der PU zum L2 überträgt, bidirektional ausgeführt. Insofern kann die Übertragungsrichtung der Bushälfte 508 in Abhängigkeit von den Bandbreiteerfordernissen umgeschaltet werden; dies entspricht den beiden Zuständen 221 und 223 der bidirektionalen Bushälfte in Fig. 2C. Die andere Bushälfte 535 dagegen besteht aus unidirektionalen Datenleitungen, die Übertragungsrichtung vom L2 zur PU ist damit festgelegt. Sie entspricht der unidirektionalen Bushälfte 222, 224 in Fig. 2C.

Daten und Commands können also von der PU zum L2 immer nur über die halbe Busbandbreite übertragen werden. Dies geschieht, indem die PU die zu übertragende Information, also OP_IMs, OP_IDs und "Data", in die entsprechenden Out-Register 504, 505, 506 schreibt. Der Typ der zu übertragenden Information wird durch das Tag spezifiziert; dazu wird die entsprechende Kennung in das Tag-Register 501 geschrieben. Diese Tag-Information dient zum einen zur Selektion (507) des Registers, dessen Inhalt übertragen werden soll, zum anderen wird das Tag über zwei unidirektionale Tag-Leitungen 502 mittels der Early-Clock 500 zum L2-seitigen Tag Decoder 503 übertragen. Im Grundzustand werden durch den Halbbus 508 Daten und Commands von der PU zum L2 übertragen. Das Ausgangssignal 510 der BIDI Controls 509 aktiviert die beiden Treiber 511 und 513, während die beiden Treiber 512 und 514, an denen ein invertiertes BIDI Control Signal anliegt, desaktiviert werden. Die übertragene Information wird in Abhängigkeit vom Tag-Status in eines der drei zur Verfügung stehenden In-Register 520, 521, 522 geschrieben, auf die der L2 dann zugreifen kann, um die Information weiter zu verarbeiten. Da auch bei einer anstehenden Datenübertragung die zweite, unidirektionale Bushälfte nicht genutzt werden kann, ist es notwendig, sowohl die niederwertigen als auch die höherwertigen vier Bytes der Daten ("Low Data" und "High Data") über den Halbbus 508 zu übertragen.

In der umgekehrten Richtung, also vom L2 zu PU, ist dagegen die Nutzung beider Bushälften zur Datenübertragung möglich. Dazu müssen die Treiber 512 und 514 mittels der BIDI Controls 509 und 515 aktiviert werden, um vom Grundzustand zu einem Zustand voller Bandbreite überzugehen. Die niederwertigen vier Datenbytes werden in das Out-Register "Data Low" 531 geschrieben, die höherwertigen vier Bytes in das "Data High" Register 530. Der Inhalt des Registers "Data High" kann dann über den Halbbus 508 zum prozessorseitigen In-Register 536 übertragen werden, während der Inhalt des "Data Low" Registers 531 über den Selektor 534 und den Halbbus 535 zum In-Register 537 übertragen wird. Zur Übertragung von OP_IDs und OP_IMs ist die Nutzung der Bushälfte 508 nicht erforderlich; hier wird mit halber Bandbreite übertragen.

In den Fig. 6 bis 11 ist der Ablauf des typischen Datenverkehrs auf einem Prozessorbus zwischen Prozessor und L2-Cache dargestellt. Auch für den Fall, daß mehrere PUs über ihren jeweiligen Prozessorbus mit einem gemeinsamen L2-Cache verbunden sind (Multiprozessorsystem), läuft der Datenverkehr auf jedem der Prozessorbusse nach dem dargestellten Schema ab.

In Fig. 6A sendet der L2 über den Halbbus 601, der dem Halbbus 436 in Fig. 4 entspricht, das Command "Cache Line Invalidate" (602) an eine PU. Der Bus befindet sich im Grundzustand, eine Informationsübertragung in der Gegenrichtung, also auf der Bushälfte 600, findet nicht statt. Das Command "Cache Line Invalidate" wird vom L2 an sämtliche PUs ausgesendet, um die PUs zu einer Invalidierung der betroffenen Cache Line in den ihnen zugeordneten L1-Caches zu veranlassen. Eine Invalidierung der lokal abgespeicherten Instanzen der Cache Line kann notwendig werden, wenn einer der Prozessoren signalisiert hat, die Cache Line im L2 überschreiben zu wollen, also einen diese Cache Line betreffenden Store-Zugriff veranlassen möchte. Ein weiterer Grund kann sein, daß die im L2 gespeicherte Cache Line aufgrund eines Least Recently Used Algorithmus gelöscht werden soll. Zur Invalidierung der Cache Line in den den einzelnen Prozessoren zugeordneten L1 Caches ist es notwendig, den PUs neben dem Command "Cache Line Invalidate" auch die Speicheradresse der Cache Line mitzuteilen. Desweiteren wird dem Invalidierungsbefehl eine ID zugeordnet. Dieser Kurzbefehl wird der PU als "Immediate Operation" (OP_IM, 602) übermittelt. Als Antwort darauf sendet die PU eine Response (603) an den L2, welche wiederum die ID sowie die Cache Line Adresse enthält. Auch für die Übermittlung dieser Response ist, wie in Fig. 6B dargestellt, die halbe Busbandbreite völlig ausreichend; auch bei der Response auf das "Cache Line Invalidate" handelt es sich um eine "Immediate Operation".

Wenn von seiten einer PU ein Schreibzugriff auf den L2 bzw. das Memory durchgeführt werden soll, so sendet die PU einen Store-Befehl, zusammen mit den abgespeicherten Daten, an den L2. Der Ablauf des Store Commands ist in Fig. 7 für den Fall dargestellt, daß beide Bushälften 700 und 701 bidirektional ausgeführt sind und deshalb auch die Übertragungsrichtung der Bushälfte 701, die im Grundzustand Daten von der PU zum L2 überträgt, geändert werden kann. Dies entspricht der erfindungsgemäßen Lösung nach Fig. 2B. Zur Durchführung eines Store ist es erforderlich, in einem ersten Cycle (702) neben dem Command selbst Information über die Länge des sich anschließenden Datenpakets sowie eine ID zu übertragen. In einem zweiten Cycle (703) wird dann die Zieladresse im Memory, ab der mit dem Schreibvorgang begonnen werden soll, mitgeteilt. Es kann vorteilhaft sein, die Adresse im ersten Cycle zu übertragen, und Command, ID und Length erst im zweiten Cycle zu übermitteln, um die Zieladresse auf L2-Seite früher zur Verfügung zu stellen.

In den ersten beiden Cycles werden also Informationen übertragen, die die auszuführende Operation näher spezifizieren. Insofern werden die ersten beiden Cycles als OP_IDs codiert, und die dem Halbbus 700 zugeordneten Tag-Leitungen liegen beide auf "high". Ab dem dritten Cycle wird mit der eigentlichen Datenübertragung begonnen. Da zunächst nur die halbe Bandbreite zur Datenübertragung zur Verfügung steht, wird ein voller, 8 Byte umfassender Datenschuß aufgeteilt in seine höherwertigen 4 Bytes ("High Data", 704) und seiner niederwertigen 4 Bytes ("Low Data", 705). Diese werden dann sequentiell auf dem Halbbus übertragen. Die Codierung auf den Tag-Leitungen hat inzwischen von OP_ID zu "Data" gewechselt, d. h. Tag-Leitung 1 liegt auf "low", während Tag-Leitung 2 auf "high" liegt. Falls auf dem Halbbus 701, der im Grundzustand Informationen vom L2 zur PU überträgt, keine Aktivität vorliegt, kann die Übertragungsrichtung dieses Halbbusses umgeschaltet werden, um ihn für die Datenübertragung nutzen zu können. Ab dem Zeitpunkt, zu dem die Übertragungsrichtung des Halbbusses 701 umgeschaltet wird (708), ist die Übertragung eines vollen Datenschusses in einem Cycle möglich, "High Data" (706) wird auf dem Halbbus 700, "Low Data" (707) auf dem Halbbus 701 von der PU zum L2 übertragen. Auch die Tag-Codierung in dieser Übertragungsrichtung ist nun "Data". Mit dem Abschluß der Datenübertragung wechselt das Bussystem vom Zustand voller Bandbreite zurück zum Grundzustand, d. h. der Halbbus 701 überträgt wieder Informationen vom L2 zur PU.

Eine Abwandlung des in Fig. 7 gezeigten Store-Vorgangs für ein der Fig. 2C entsprechendes Bussystem, das eine bidirektionale und eine unidirektionale Bushälfte aufweist, ist in Fig. 8 dargestellt. Hier kann die Übertragungsrichtung des Halbbusses 800, der im Grundzustand Informationen von der PU zum L2 überträgt, geändert werden, während der Halbbus 801 unidirektional ist und Informationen nur vom L2 zur PU transferieren kann. Hier schließt sich an die ersten beiden OP_IDs 802 und 803 die eigentliche Datenübertragung an. Da lediglich ein Halbbus zur Verfügung steht, muß jeder Datenschuß in "High Data" (805 bzw. 807) und "Low Data" (806 bzw. 808) zerlegt werden.

In Fig. 9A und 9B ist der Ablauf eines Fetch-Vorgangs dargestellt. Wenn eine PU Daten benötigt, die sie nicht in ihrem lokalen L1-Cache vorfindet, so sendet sie einen Fetch über den Halbbus 900 an den L2. Das Fetch-Command besteht aus zwei "Operation Identifiers" (902 und 903), welche die ID des Fetch-Vorgangs, das Fetch-Command selbst, die Länge des angeforderten Datenpakets sowie die Startadresse der benötigten Daten enthalten. Zur Übertragung des Fetch befindet sich der Bus im Grundzustand. Nach Empfang des Fetch beginnt der L2 in seinem Directory nach der angeforderten Cacheline zu suchen. Wenn er fündig wird ("hit"), können die benötigten Daten sofort zur PU übertragen werden; falls der L2 nicht fündig wird ("miss"), muß die Cacheline erst vom Memory angefordert werden.

Statistisch betrachtet treten mehr als doppelt so viele Fetch-Vorgänge wie Store-Vorgänge auf. Der Datenübertragung aufgrund eines "Fetch" kommt also eine höhere Relevanz zu als den Datenübertragungen aufgrund von "Store". Hinzu kommt, daß die PU eine bestimmte Cacheline ja deshalb angefordert hat, um die für eine Operation benötigten Argumente zur Verfügung stellen zu können. Insofern kann die PU mit der weiteren Verarbeitung erst nach Erhalt der Cacheline fortfahren. Aus beiden Argumenten ergibt sich, daß für die Datenübertragung vom L2 zur PU die volle Bandbreite zur Verfügung stehen soll.

Es ist deshalb sowohl in der Buskonfiguration nach Fig. 2B als auch in der nach Fig. 2C vorgesehen, die Übertragungsrichtung für Informationen auf dem Halbbus 900 von der PU zum L2 abändern zu können. Dieser Halbbus 900 muß also bidirektional ausgeführt sein, während der Halbbus 901 unidirektional oder bidirektional ausgelegt sein kann.

In Fig. 9B ist die Response auf einen Fetch dargestellt. Nach der Umschaltung der Übertragungsrichtung (911) auf dem Halbbus 900 wird im ersten Cycle ein OP_ID 904 vom L2 zur PU übertragen. Dabei signalisieren die Tag-Leitungen, daß ein OP_ID vorliegt. In den nächsten Cycles findet dann die eigentliche Datenübertragung statt. Da die volle Busbandbreite zur Verfügung steht, können "High Data" (906, 908, 910) und "Low Data" (905, 907, 909) jeweils in einem Cycle übertragen werden, pro Cycle kann also ein Datenschuß übertragen werden. Die Tag-Leitungen zeigen dabei an, daß es sich bei der übertragenen Information um "Data" handelt. Nach Abschluß der Datenübertragung geht der Bus wieder in den Grundzustand über, indem die Übertragungsrichtung auf dem Halbbus 900 erneut wechselt.

Es stellt sich nun die Frage, wie das "Right to Send" auf den beiden Bushälften vergeben wird, welcher der beiden Busteilnehmer, PU und/oder L2, also den Input für die in Fig. 4 und 5 gezeigten BIDI Controls liefert. Eine Möglichkeit ist, entweder nur für die PU oder aber für PU und L2 eigene (unidirektionale) Leitungen vorzusehen, mit denen der jeweilige Busteilnehmer signalisiert, ob er bereit wäre, die ihm im Grundzustand zugeordnete Bushälfte dem anderen Partner zu überlassen oder nicht. Bei der in Fig. 9B dargestellten Fetch Response bedeutet dies, daß der L2 das Senderecht auf der Bushälfte 900, die im Grundzustand der PU zugeordnet ist, nur dann übernehmen kann, wenn die PU auf der ihr zugeordneten Leitung signalisiert, daß sie ihr Senderecht momentan nicht beanspruchen will. Wenn jedoch auf PU-Seite gerade eine Store-Operation zur Ausführung ansteht, so kann die PU verhindern, daß der L2 das Senderecht auf der Bushälfte 900 bekommt.

Eine derartige Lösung wäre für die in Fig. 2C gezeigte Buskonfiguration bereits völlig ausreichend. Bei der in Fig. 2B gezeigten Buskonfiguration ist auch eine eigene Kontrolleitung für den L2 vorzusehen, mit deren Hilfe der L2 verhindern kann, daß auf seiner Bushälfte die PU das Senderecht bekommt. Bei dem in Fig. 7 gezeigten Ablauf eines Store Commands könnte die PU die Bushälfte 701 also nur dann übernehmen, wenn der L2 signalisiert, daß er gerade nicht senden möchte.

Anstelle von eigenen Kontrolleitungen wäre auch der Austausch von "Immediate Operations" zwischen den Busteilnehmern möglich, um eine Änderung der Übertragungsrichtung auf einer Bushälfte anzufordern und/oder zu gestatten.

Die Umschaltung der Übertragungsrichtung einer Bushälfte erfordert mindestens zwei Prozessor-Cycles, weil die entsprechenden Sende- und Empfangstreiber aktiviert bzw. desaktiviert werden müssen. Um also gleich mit Beginn der "Response to Fetch" die volle Busbandbreite zur Verfügung zu haben, ist es sinnvoll, wenn die PU einige Cycles nach dem Absenden des "Fetch" (902, 903) mit dem Umschalten der Übertragungsrichtung der Bushälfte 900 beginnt. Auch das Durchsuchen der Directory auf L2-Seite sowie der Zugriff auf die angeforderte Cacheline erfordern einige Cycles. Insofern ist es möglich, die Umschaltung der Übertragungsrichtung (911) vor Beginn der "Fetch Response" abzuschließen, so daß von Anfang an die volle Busbandbreite zur Datenübertragung zur Verfügung steht. Es kann aber sinnvoll sein, der PU das Recht zu geben, für den Fall, daß ein Store zum L2 erfolgen soll, die Umschaltung zu verhindern. In diesem Fall würde die Übermittlung der Fetch Response zumindest zum Teil nur über den Halbbus 901 erfolgen.

Fig. 10A und 10B zeigen den Ablauf des Control Commands, mit dem die PU einen Schreibzugriff auf die Register von funktionalen Einheiten des Computersystems ausführen kann. Der Bus bleibt zur Übertragung des Control Commands im Grundzustand, die Übertragung des Commands erfolgt lediglich auf dem Halbbus (1000) von der PU zum L2. In den ersten beiden Cycles werden zwei OP_IDs (1002, 1003) übertragen, die die ID des Commands, das Control Command selbst, die Nummer des Chips, auf den zugegriffen werden soll, sowie die Registeradresse enthalten. Das Tag ist dabei im OP_ID Status.

Im Anschluß an diese beiden Cycles werden zweimal vier Byte an Daten übertragen, die die in die Chipregister zu schreibende Information enthalten. Da nur die halbe Bandbreite zur Verfügung steht, ist eine Aufteilung in "High Data" (1004) und "Low Data" (1005) erforderlich. Während der Übermittlung dieser Daten hat das Tag den Status "Data".

Fig. 10B zeigt die Response 1006 auf dieses Control Command, welche als "Immediate Operation" auf dem Halbbus (1001) vom L2 zur PU übertragen wird. Diese Response enthält die ID des Control Commands sowie die Kennung der PU, die das Control Command initiiert hat.

Wenn umgekehrt ein Registerinhalt eines zu einer funktionalen Einheit des Computersystems gehörigen Chips ausgelesen werden soll, sendet die PU einen Sense-Befehl an den L2. Dies ist in Fig. 11A dargestellt. Der auf dem Halbbus (1100) übertragene Sense-Befehl umfaßt zwei Cycles (1102, 1103), in denen die ID des Commands, das Command selbst, die Nummer des betroffenen Chips sowie die Registeradresse übermittelt werden. Während der Übermittlung zeigt das Tag die Codierung für OP_ID.

Mit der Response zu diesem Sense-Command wird der Status der ausgelesenen Register übermittelt. Dies ist in Fig. 11B dargestellt. Nach einem "Operation Identifier" (1104), der die ID sowie eine Kennung der PU enthält, werden zweimal vier Byte an Daten ("Low Data", 1105 und "High Data", 1106) an die PU übertragen. Diese Datenbytes enthalten den Status der ausgelesenen Register. Während die Tag-Leitungen während des Cycles 1104 OP_ID signalisieren, zeigen sie während der Cycles 1105 und 1106 an, daß "Data" übertragen wird.

In Fig. 12 ist die Situation dargestellt, daß der L2 an die PU eine "Fetch Response" zu übermitteln hat, der Halbbus 1200 von der PU zum L2 aber aktiv ist. In dem gezeigten Fall wird gerade ein Store-Befehl (1202) ausgeführt. Der L2 kann nun entweder mit der Datenübertragung warten, bis die Bushälfte 1200 wieder verfügbar ist, dann die Übertragungsrichtung der Bushälfte (1200) umschalten, und anschließend die Daten mit voller Bandbreite vom L2 zur PU übertragen. Alternativ kann aber auch auf der Bushälfte 1201 mit der Übertragung der "Fetch Response" (1203) begonnen werden, die Übertragung erfolgt daher zunächst mit halber Bandbreite. Sobald der Halbbus 1200 verfügbar ist, kann auch seine Übertragungsrichtung umgeschaltet werden (1204), anschließend kann die Datenübertragung vom L2 zur PU mit voller Bandbreite fortgesetzt werden. Auf diese Weise ist eine flexible Auslastung der zur Verfügung stehenden Bandbreite möglich.

In Fig. 13A ist die Situation dargestellt, daß die PU eine OP_IM an den L2 übermitteln will, die im Grundzustand dafür vorgesehene Bushälfte 1300 aber gerade nicht verfügbar ist. Im gezeigten Beispiel ist die Bushälfte 1300 durch die Übertragung eines Store-Befehls 1302 blockiert. Um nun mit der Übermittlung des OP_IM nicht bis zum Ende des Store-Befehls warten zu müssen, kann es vorteilhaft sein, die Datenübertragung zu unterbrechen (1306), den OP_IM 1303 zu übermitteln, und anschließend (1305) mit der Übertragung der Daten (1304) fortzufahren. Durch die Möglichkeit, eine OP_IM in den regulären Datenfluß einzuschleifen, wird ein beschleunigter Austausch von Kurzbefehlen zwischen PU und L2 möglich.

In Fig. 13B ist ein ähnlicher Fall dargestellt, bei dem ein OP_IM von der PU zum L2 übermittelt werden soll, obwohl beide Bushälften 1310 und 1311 durch eine "Fetch Response" (1312) blockiert sind. In diesem Fall muß zunächst die Datenübertragung durch die "Fetch Response" auf die halbe Bandbreite beschränkt werden. Anschließend kann die Übertragungsrichtung auf dem Halbbus 1310 invertiert werden (1313). Nach der Übertragung des OP_IM 1314 von der PU zum L2 wird die Übertragungsrichtung der Bushälfte 1310 erneut umgedreht, um wieder die volle Busbandbreite für die Fortsetzung der Fetch Response zur Verfügung zu haben. Auch diese Lösung dient einem beschleunigten Austausch von "Immediate Operations" zwischen PU und L2.

Claims (16)

1. Bus zur Übertragung von Information in einem Datenverarbeitungssystem, welcher mindestens zwei Übertragungsleitungen aufweist, gekennzeichnet durch
einen ersten Zustand, in dem die Übertragungsleitungen in zwei Gruppen mit entgegengesetzter Übertragungsrichtung eingeteilt sind, wobei die Übertragungsrichtung mindestens einer Gruppe von Übertragungsleitungen umkehrbar ist,
einen zweiten Zustand, in dem die Übertragungsrichtung der zwei Gruppen von Übertragungsleitungen übereinstimmt, und
Mittel zum Umschalten des Busses zwischen dem ersten und dem zweiten Zustand.

2. Bus nach Anspruch 1, dadurch gekennzeichnet, daß für die beiden Übertragungsrichtungen jeweils mindestens eine Tagleitung vorhanden ist,
wobei der Status der Tagleitung den Typ der auf dem Bus übertragenen Information spezifiziert.

3. Bus nach Anspruch 2, dadurch gekennzeichnet, daß die Umschaltung zwischen dem ersten und dem zweiten Zustand in Abhängigkeit vom Status der Tagleitungen erfolgt.

4. Bus nach Anspruch 1 und/oder 2, dadurch gekennzeichnet, daß die Umschaltung zwischen dem ersten und dem zweiten Zustand in Abhängigkeit von Information erfolgt, die über den Bus übertragen wird.

5. Bus nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, daß
die Übertragungsleitungen der einen Gruppe von Übertragungsleitungen bidirektionale Leitungen sind, deren Übertragungsrichtung umschaltbar ist, und
die Übertragungsleitungen der anderen Gruppe von Übertragungsleitungen unidirektionale Leitungen sind, deren Übertragungsrichtung feststeht.

6. Bus nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, daß die Übertragungsleitungen beider Gruppen von Übertragungsleitungen bidirektionale Leitungen sind, deren Übertragungsrichtung umschaltbar ist.

7. Bus nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, daß die Übertragung von Tagsignalen über die Tagleitungen um einen Bruchteil eines Taktzyklus früher stattfindet als die Übertragung der Information über den Bus.

8. Bus nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, daß
für den Fall, daß sich der Bus im ersten Zustand befindet, daß Information in der einen Übertragungsrichtung übertragen werden soll, daß aber der Bus in der entgegengesetzten Übertragungsrichtung noch aktiv ist,
der Übergang vom ersten Zustand in den zweiten Zustand solange aufgeschoben wird, bis die Busaktivität in der entgegengesetzten Übertragungsrichtung abgeschlossen ist.

9. Verfahren zur Übertragung von Information über einen Bus in einem Datenverarbeitungssystem, wobei der Bus mindestens zwei Übertragungsleitungen aufweist, wobei
die Übertragungsleitungen in zwei Gruppen eingeteilt werden,
und wobei von einem ersten Zustand, in dem die beiden Gruppen entgegengesetzte Übertragungsrichtung aufweisen, zu einem zweiten Zustand, in dem die Übertragungsrichtung der zwei Gruppen von Übertragungsleitungen übereinstimmt, umgeschaltet wird.

10. Verfahren nach Anspruch 9, dadurch gekennzeichnet, daß für die beiden Übertragungsrichtungen jeweils mindestens eine Tagleitung vorhanden ist,
wobei durch den Status der Tagleitung der Typ der auf dem Bus übertragenen Information spezifiziert wird.

11. Verfahren nach Anspruch 10, dadurch gekennzeichnet, daß in Abhängigkeit vom Status der Tagleitungen zwischen dem ersten und dem zweiten Zustand umgeschaltet wird.

12. Verfahren nach Anspruch 9 oder 10, dadurch gekennzeichnet, daß die Umschaltung zwischen dem ersten und dem zweiten Zustand in Abhängigkeit von Information erfolgt, die über den Bus übertragen wird.

13. Verfahren nach einem der Ansprüche 9 bis 12, dadurch gekennzeichnet, daß
die Übertragungsleitungen der einen Gruppe von Übertragungsleitungen bidirektionale Leitungen sind, deren Übertragungsrichtung umschaltbar ist, und
die Übertragungsleitungen der anderen Gruppe von Übertragungsleitungen unidirektionale Leitungen sind, deren Übertragungsrichtung feststeht.

14. Verfahren nach einem der Ansprüche 9 bis 12, dadurch gekennzeichnet, daß die Übertragungsleitungen beider Gruppen von Übertragungsleitungen bidirektionale Leitungen sind, deren Übertragungsrichtung umschaltbar ist.

15. Verfahren nach einem der Ansprüche 9 bis 14, dadurch gekennzeichnet, daß Tagsignale über die Tagleitungen um einen Bruchteil eines Taktzyklus früher übertragen werden als die Information über den Bus.

16. Verfahren nach einem der Ansprüche 9 bis 15, dadurch gekennzeichnet, daß
für den Fall, daß sich der Bus im ersten Zustand befindet, daß Information in der einen Übertragungsrichtung übertragen werden soll, daß aber der Bus in der entgegengesetzten Übertragungsrichtung noch aktiv ist,
der Übergang vom ersten Zustand in den zweiten Zustand solange aufgeschoben wird, bis die Busaktivität in der entgegengesetzten Übertragungsrichtung abgeschlossen ist.