DE19983506B3

DE19983506B3 - Verfahren zum Betreiben eines zeitlich gemultiplexten Adress- und Datenbusses in einem Computersystem und Busschnittstelle hierfür

Info

Publication number: DE19983506B3
Application number: DE19983506T
Authority: DE
Inventors: Tsvika Kurts
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 1998-08-28
Filing date: 1999-08-18
Publication date: 2013-08-22
Anticipated expiration: 2019-08-19
Also published as: KR100393168B1; GB2357870B; US6209053B1; CN1265301C; DE19983506T1; CN1342287A; WO2000013092A3; AU5680799A; GB0104703D0; GB2357870A; WO2000013092A2; HK1035046A1; TW455768B; KR20010073009A

Abstract

Verfahren zum Betreiben eines zeitlich gemultiplexten Adress- und Datenbusses in einem Computersystem, dessen Busleitungen im zeitlichen Multiplex entweder mit Adressleitungen oder mit Datenleitungen eines Busteilnehmers gekoppelt werden können, wobei der Datenaustausch zwischen den Busteilnehmern in Form von mehrere Phasen umfassenden Bustransaktionen stattfindet, wobei sich ein Busteilnehmer in einer Zuteilungsphase um den Busbesitz bewirbt und in einer Anforderungsphase Adressinformationen auf den Bus ausgibt, wobei in einer Datenphase Daten über den Bus übertragen werden, wobei sich die Phasen verschiedener Bustransaktionen überlappen können, so dass sich eine Anforderungsphase einer Bustransaktion, bei der Adressinformationen auf den Bus ausgegeben werden sollen und eine Adressbuszugriffsanforderung auftritt, mit einer Datenphase einer anderen Transaktion, bei der Daten über den Bus übertragen werden sollen und eine Datenbuszugriffsanforderung auftritt, überlappen können, wobei das Verfahren die Schritte umfasst: Entscheiden einer Zuteilung zwischen einer Adressbuszugriffsanforderung und einer Datenbuszugriffsanforderung, die um einen Zugriff auf den gemultiplexten Bus konkurrieren, in Übereinstimmung mit einem vorgegebenen Kriterium; und Gewähren des gemultiplexten Busses entweder der Adress- oder der Datenbuszugriffsanforderung in Übereinstimmung mit dem Ausgang der Zuteilungsentscheidung, wobei die Busleitungen in Übereinstimmung mit dem Ausgang der Zuteilungsentscheidung entweder mit den Adressleitungen oder mit den Datenleitungen des Busteilnehmers gekoppelt werden.

Description

Die vorliegende Erfindung betrifft ein Verfahren zum Betreiben eines zeitlich gemultiplexten Adress- und Datenbusses in einem Computersystem, dessen Busleitungen im zeitlichen Multiplex entweder mit Adressleitungen oder mit Datenleitungen eines Busteilnehmers gekoppelt werden können. Ferner betrifft die Erfindung eine Busschnittstelle eines Busteilnehmers, die mit einem zeitlich gemultiplexten Adress- und Datenbus in einem Computersystem gekoppelt werden soll, dessen Busleitungen im zeitlichen Multiplex entweder mit Adressleitungen oder mit Datenleitungen der Busschnittstelle gekoppelt werden können. Schließlich betrifft die Erfindung einen Busteilnehmer mit einer solchen Busschnittstelle.
Die Kommunikation zwischen Einrichtungen in einem Computersystem wird typischerweise unter Verwendung eines oder mehrerer Busse ausgeführt, die diese Einrichtungen miteinander verbinden. Diese Busse können speziell zugeordnete Busse sein, die zwei Einrichtungen miteinander koppeln, oder nicht speziell zugeordnete Busse, die von einer Reihe von Einheiten und Einrichtungen (d. h. Busteilnehmern) im Multiplex genutzt werden. Darüber hinaus können Busse in einem Computersystem der Übertragung einer speziellen Art von Informationen gewidmet sein. Derartige Bussysteme sind beispielsweise von Klaus Dembowski in „Computerschnittstellen und Bussysteme”, Heidelberg, Hüthig, 1997, beschrieben. Die Patentschrift US 4,766,536 beschreibt ein Computersystem mit einem Systembus, der mehrere Prozessoren miteinander verbindet, wobei ein Datenbus im zeitlichen Multiplex sowohl Daten als auch zur Arbitrierung verwendete Informationen übertragen kann. Die Patentschrift US 5,347,648 offenbart ein Computersystem mit einem zeitlich gemultiplexten Adress-/Daten-Bus, bei dem eine Zuteilungsentscheidung zwischen verschiedenen Busteilnehmern durchgeführt wird. Die sich um den Buszugriff bewerbenden Bustransaktionen der verschiedenen Teilnehmer können Bustransaktionen umfassen, bei denen entweder nur Adressen oder sowohl Adressen als auch Daten im Multiplex über dieselben Busleitungen übertragen werden.
Die von der Intel Corporation in Santa Clara, Kalifornien, entwickelte x86-Mikroprozessorarchitektur enthält ein 3-Bus-System mit Adress-, Daten- und Steuerbus für die Übertragung von Adressen, Daten bzw. Steuersignalen.
Bei Computersystemen, die fortgeschrittene Architekturen und Prozessoren, wie beispielsweise den Pentium Pro- oder Pentium II-Prozessor, benutzen, treten Bustransaktionen in einer verschachtelten (Pipeline) Weise auf. Insbesondere kann es sein, dass ein nächster Speicherzugriff gestartet wird, nachdem eine vorhergehende Transaktionsanforderung ausgegeben worden ist, und sämtliche Komponenten oder Phasen einer Bustransaktion brauchen nicht abgeschlossen zu sein, bevor eine weitere Bustransaktion initiiert werden kann. Dementsprechend können Anforderungen aus zahlreichen Busteilnehmern zu einem beliebigen Zeitpunkt anhängig sein. Die pipeline-artige Verschachtelung der Bustransaktionen wird durch separate Daten- und Adressbusse erleichtert. Während eine Adresse einer Anforderung auf einen Adressbus gesendet wird, können Daten (oder Signale), die zu einer zuvor auf dem Adressbus ausgegebenen Adresse gehören, auf dem Datenbus zurückgegeben werden.
Um einen erhöhten Datendurchsatz zu erleichtern, können Computersysteme Burst-Datenübertragungen (Bündeldatenübertragungen) ermöglichen, bei denen eine Adresse auf einem Adressbus ausgegeben wird und Daten aus dem adressierten Ort sowie aus einer Anzahl von unmittelbar nachfolgenden Orten, wie sie beispielsweise von dem Intel-Burst-Reihenfolgeschema definiert sind, zurückgegeben werden. Beispielsweise kann während einer Burst-Cache-Übertragung eine vollständige Zeile Daten (z. B. 32 Bytes) aus einem Cache-Speicher auf einen Datenbus in Erwiderung einer einzigen auf den Adressbus gebrachten Adresse gebracht werden. Bei vielen Computersystemen können solche Burst-Cache-Übertragungen für einen beträchtlichen Teil der Aktivität auf den Bussen in dem Computersystem verantwortlich sein. In diesen Situationen ist es klar, dass der Adressbus im Vergleich zu dem Datenbus unterbenutzt ist.
Aufgabe der Erfindung ist es daher, die Leitungen des Busses besser auszunutzen.
Diese Aufgabe wird erfindungsgemäß durch ein Verfahren zum Betreiben eines zeitlich gemultiplexten Adress- und Datenbusses mit den Merkmalen des Anspruchs 1, eine Busschnittstelle eines Busteilnehmers mit den Merkmalen des Anspruchs 10 und einen Busteilnehmer mit den Merkmalen des Anspruchs 19 gelöst.
Das Verfahren zum Betreiben eines gemultiplexten Adress- und Datenbusses in einem Computersystem umfasst den Schritt der Zuteilungsentscheidung zwischen einer Adressbuszugriffsanforderung und einer Datenbuszugriffsanforderung, die um einen Zugriff auf den gemultiplexten Bus konkurrieren. Diese Entscheidung wird in Übereinstimmung mit einem vorgegebenen Kriterium getroffen. Der gemultiplexte Bus wird dann entweder der Adress- oder der Datenanforderung in Abhängigkeit von dem Ausgang der Zuteilungsentscheidung gewährt.
Vorteilhafte und/oder bevorzugte Ausführungsformen der Erfindung sind in den Unteransprüchen gekennzeichnet.
Weitere Merkmale der vorliegenden Erfindung werden aus den begleitenden Zeichnungen und aus der folgenden detaillierten Beschreibung ersichtlich.
Die vorliegende Erfindung wird beispielhaft und in nicht einschränkender Weise anhand der Figuren der begleitenden Zeichnungen veranschaulicht, in welchen gleiche Bezugszeichen auf ähnliche Elemente verweisen und in welchen:
1A und 1B Blockdarstellungen eines Computersystems sind, in welchem ein Ausführungsbeispiel der vorliegenden Erfindung implementiert sein kann.
2 ist eine Blockdarstellung, die einen externen Bus veranschaulicht, der einen Prozessor und einen weiteren externen Busteilnehmer koppelt.
3 ist ein Zeitdiagramm, das sechs Phasen veranschaulicht, die in einer Transaktion des externen Busses enthalten sein können.
4 ist ein Zeitdiagramm, das Signalübergänge für eine Rücken-an-Rücken-Lese-Zeile-Transaktion auf dem beispielhaften externen Bus zeigt.
5 ist eine Blockdarstellung, die einen adaptiven gemultiplexten 128-Bit-Bus in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung veranschaulicht, der einen Prozessor und einen externen Busteilnehmer koppelt, die jeweils eine Externe-Bus-Logik, ebenfalls gemäß einem Ausführungsbeispiel der vorliegenden Erfindung, enthalten.
6 ist ein Blockschaltbild, das eine Schaltung gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt, welche in der in 5 gezeigten Externe-Bus-Logik enthalten sein kann.
7 ist ein Zeitdiagramm, das gemäß einem Ausführungsbeispiel der vorliegenden Erfindung Übergänge von Signalen in der Externe-Bus-Logik und auf einem gemultiplexten Bus veranschaulicht.
8 ist ein Ablaufdiagramm, das ein Verfahren zum Betreiben eines gemultiplexten Adress- und Datenbusses in einem Computersystem gemäß einem Ausführungsbeispiel der vorliegenden Erfindung veranschaulicht.
9A–9C sind Ablaufdiagramme, die drei beispielhafte Zuteilungsentscheidungsschemata mit Übereinstimmung mit jeweiligen Ausführungsbeispielen der vorliegenden Erfindung veranschaulichen, die in dem in 8 veranschaulichten Verfahren benutzt werden können.
Es werden ein Verfahren und eine Einrichtung zum Betreiben eines gemultiplexten Adress- und Datenbusses in einem Computersystem beschrieben. In der folgenden Beschreibung werden aus Gründen der Erläuterung zahlreiche spezielle Details angegeben, um ein besseres Verständnis der vorliegenden Erfindung zu erreichen. Für einen Fachmann ist es jedoch klar, dass die vorliegende Erfindung auch ohne diese speziellen Details ausgeführt werden kann.
Computersystemüberblick
1A und 1B sind Blockdarstellungen eines Computersystems 10, in dem ein Ausführungsbeispiel der vorliegenden Erfindung implementiert sein kann. Das Computersystem 10 enthält einen oder mehrere Prozessoren 12, die bzw. der ein Mikroprozessor einer komplexen Befehlssatz-Datenverarbeitung (CISC), ein Mikroprozessor einer Datenvereinbarung mit reduziertem Befehlssatz (RISC), ein Mikroprozessor mit einem sehr langen Befehlswort (VLIW) oder irgendeine andere Prozessoreinrichtung sein kann. Bei einem Ausführungsbeispiel der Erfindung kann jeder der Prozessoren 12 ein von der Intel Corporation in Santa Clara, Kalifornien, hergestellter Pentium Pro- oder Pentium II-Mikroprozessor sein. Jeder der Prozessoren 12 ist über eine zugehörige Externer-Bus-Schnittstelle 15 mit einem externen Bus 14 gekoppelt (der auch als ”Frontseitenbus (FSB)” bezeichnet wird). Ferner ist gezeigt, dass ein eine Externer-Bus-Schnittstelle 19 enthaltender weiterer Teilnehmer 17 mit dem externen Bus 14 gekoppelt ist.
Außerdem ist eine Steuereinrichtung 16 mit dem externen Bus 14 über eine Externer-Bus-Schnittstelle 18, die in der Steuereinrichtung 16 enthalten ist, gekoppelt. Der externe Bus 14 und die Externer-Bus-Schnittstellen 15 und 18 können bei einer ersten Frequenz (d. h. 66 oder 100 MHz) betrieben werden und somit eine eigenständige Taktdomäne bilden. Ferner ist gezeigt, dass die Steuereinrichtung 16 eine Hauptspeicherschnittstelle 20 enthält, durch welche die Steuereinrichtung 16 mit einem Hauptspeicher 22 gekoppelt ist. Der Hauptspeicher 22 und die Hauptspeicherschnittstelle 20 können eine eigenständige Taktdomäne bilden oder können in die Taktdomäne des externen Busses 14 und der Externer-Bus-Schnittstelle 18 integriert sein.
Die Steuereinrichtung 16 enthält ferner eine Peripheriekomponentenverbindungs(PCI)-Schnittstelle 24, wie sie durch die am 1. Juni 1995 veröffentlichte PCI Local Bus Specification, Revision 2.1, definiert ist, durch welche die Steuereinrichtung mit einem PCI-Bus 26 gekoppelt ist. Bei einem Ausführungsbeispiel arbeiten die PCI-Schnittstelle 24 und der PCI-Bus 26 bei einer Frequenz von 33 MHz und bilden demzufolge eine weitere eigenständige Taktdomäne. Eine spezielle Grafikschnittstelle, welche bei dem Ausführungsbeispiel eine Beschleunigter-Grafik-Port(AGP)-Schnittstelle 28 umfasst, koppelt die Steuereinrichtung 16 mit einem Grafikbus, welcher bei dem Ausführungsbeispiel ein AGP-Bus 30 ist. Der AGP-Bus 30 dient ausschließlich der Übertragung von Adress- und Dateninformationen zwischen der Steuereinrichtung 16 und einem speziellen Grafikprozessor 32. Die AGP-Schnittstelle 28 arbeitet in Übereinstimmung mit der am 1. August 1996 veröffentlichten AGP Interface Spezifikation, Revision 1.0. Der Grafikprozessor 32 kann das Intel-i740-Grafikbeschleunigerchip enthalten. Der Grafikprozessor 32 ist mit einem speziellen und lokalen Grafikspeicher 34 gekoppelt und mit einer Anzeigeeinheit 36, welche ein Computermonitor oder ein Fernsehapparat sein kann. Bei einem Ausführungsbeispiel arbeiten die AGP-Schnittstelle 28 und der AGP-Bus 30 bei einer Frequenz von 66 MHz und bilden dementsprechend eine weitere eigenständige Taktdomäne.
Die Schnittstellen 18, 20, 24 und 28 der Steuereinrichtung 16 können sich jeweils in einer verschiedenen und eigenständigen Taktdomäne aufhalten. Um die Übertragung von Signalen zwischen den Taktdomänen, in welchen sich die verschiedenen Schnittstellen aufhalten, zu erleichtern, enthält die Steuereinrichtung 16 eine Übertragungslogik 38. Die Übertragungslogik 38 enthält ferner eine Schaltung zum Synchronisieren von Taktsignalen, die die Taktdomänen der externen und AGP-Schnittstellen takten.
Das Computersystem 10 enthält ferner eine Brücke 40, welche die Kommunikation zwischen dem PCI-Bus 26 und einem herkömmlichen Bus 42 erleichtert. Der herkömmliche Bus 42 kann ein Industriestandardarchitektur(ISA)-Bus sein, wie er von der ISA-Busspezifikation P996 definiert ist. Es ist klar, dass der herkömmliche Bus 42 alternativ irgendein herkömmlicher Bus sein kann, wie beispielsweise ein erweiterter Industriestandardarchitektur(EISA)-Bus oder ein Micro Channel Architecture(MCA)-Bus. Ferner ist gezeigt, dass die Brücke 40 über einen universellen seriellen Bus (USB) 44 mit einer USB-Einrichtung 46 gekoppelt ist, die beide mit der am 15. Januar 1996 veröffentlichten USB-Spezifikation, Revision 1.0, kompatibel sind. Ferner ist gezeigt, dass die Brücke 40 ein Integrated Device Electronics(IDE)-Gerät 48, welches typischerweise eine Massenspeichereinrichtung in Form eines Plattenlaufwerks ist, mit dem Computersystem 10 koppelt. Zugehörige PCI- und ISA-Einrichtungen 50 und 52 sind als mit dem PCI-Bus 26 und dem ISA-Bus 42 verbunden gezeigt. Es ist klar, dass eine beliebige Anzahl von PCI-Einrichtungen 50 und ISA-Einrichtungen 52 mit den jeweiligen Bussen 26 und 42 gekoppelt sein können und beliebige einer Reihe von Peripherieeinrichtungen sein können, die Speicher-, Eingabe-, Audio-, Anzeige- oder Netzwerkeinrichtungen einschließen.
Protokolle des externen Busses
2 ist eine Blockdarstellung, die eine vereinfachte Darstellung des externen Busses 14 zur Verfügung stellt, welcher als mit einem Prozessor 12 und mit einem weiteren externen Busteilnehmer 21 gekoppelt gezeigt ist, wobei der weitere externe Busteilnehmer 21 ein weiterer Prozessor oder eine beliebige andere Einrichtung sein kann, die mit dem externen Bus 14 gekoppelt ist. Der externe Bus 14 genügt der Spezifikation des externen Busses für den Pentium Pro- oder Pentium II-Prozessor, wobei in diesem Fall der externe Bus 14 einen 36-Bit-Adressbus 14a, einen 64-Bit-Datenbus 14b und Steuersignale 14c enthält. Der Prozessor 12 und der externe Busteilnehmer 21 enthalten jeweils eine Externer-Bus-Logik (IBL) 60, die näher in dem US-Patent Nr. 5,535,345 (Fisch et al.) beschrieben ist, welche hiermit durch Bezugnahme aufgenommen wird. Die Externer-Bus-Logik 60, die in dem Prozessor 12 und dem Teilnehmer 21 enthalten ist, schafft die physikalische und logische Schnittstelle zwischen der jeweiligen Einrichtung und dem externen Bus derart, dass das Auftreten externer Bustransaktionen über den externen Bus 14 ermöglicht wird. Für die Zwecke dieser Beschreibung ist der Begriff ”Transaktion” als Busaktivität definiert, die sich auf eine einzige Buszugriffsanforderung bezieht. Eine Transaktion kann mit einer Buszuteilungsentscheidung und dem Anlegen eines Signals ADS# und der Weiterleitung einer Transaktionsadresse beginnen. Eine Transaktion, wie sie von den Spezifikationen der Intel-Architektur (IA) definiert ist, kann bis zu 6 Phasen umfassen, wobei jede Phase einen speziellen Satz von Signalen verwendet, um eine spezielle Art von Informationen zu übermitteln. 3 ist ein Zeitdiagramm, das sechs Transaktionsphasen für zwei Transaktionen (d. h. Transaktionen 1 und 2) veranschaulicht. Insbesondere umfasst jede Transaktion die folgenden Phasen:

1. Eine Zuteilungsphase (arbitration phase) 72;
2. Eine Anforderungsphase 74;
3. Eine Fehler-Phase 76;
4. Eine Snoop-Phase 78;
5. Eine Antwortphase 80; und
6. Eine Datenübertragungsphase 82.

Wie es aus 3 ersichtlich ist, werden Bustransaktionen in einer Weise verschachtelt, dass sich die verschiedenen Phasen der jeweiligen Transaktionen überlappen. Wenn ein anfordernder Teilnehmer den Bus nicht besitzt, beginnt eine Transaktion mit der Zuteilungsphase 72, in welcher der anfordernde Teilnehmer (z. B. der Prozessor 12 oder der Externer-Bus-Teilnehmer 21) in Besitz des Busses gelangt. Anschließend tritt die Transaktion in die Anforderungsphase 74 ein, in der der Busbesitzer Anforderungs- und Andressinformationen auf den Bus ausgibt. Die oben beschriebenen Phasen sind selbstverständlich bloß als Beispiel gedacht. Eine beliebige der Phasen (z. B. die Fehler-Phase 76) können bei einer Transaktion fortgelassen werden.
Jetzt wird insbesondere auf 4 Bezug genommen, welche ein Zeitdiagramm 90 veranschaulicht, das Signalübergänge für eine Rücken-an-Rücken-Zeilenlesetransaktion (back-to-back read line transaction) voller Geschwindigkeit in einem beispielhaften externen Bus 14 zeigt. Die in dem Zeitdiagramm 90 veranschaulichten Signale umfassen ein Taktsignal (CLK) 92, ein Adress-Strobe-Signal (ADS#) 94, Anforderungssignale 96, ein Treffer-auf-eine-modifizierte-Cache-Zeile-Signal (HIT#) 98, ein Zielbereit-Signal (TRDY#; target ready) 100, ein Datenbus-besetzt-Signal (DBSY#; data bus busy) 102, ein Datensignal (D[63:0]#) 104, ein Daten-bereit-Signal (DRDY#; data ready) 108 und ein Antwortstatus-Signal (RS[2:0]44; response status) 108.
Die in 3 veranschaulichte Anforderungsphase 74 ist von zwei Takten Dauer, wie es durch die Übergänge der Anforderungssignale 96 in 4 veranschaulicht ist. In einem ersten Takt (z. B. T1) der Anforderungsphase 74 wird das ADS#-Signal 94 auf niedrig gezogen, und Transaktionsadressinformationen (z. B. das Anforderungssignal 96) werden auf den Adressbus 14a gebracht. Dies ist als Anforderungsphase A (REQA) angezeigt. In einem zweiten Takt (z. B. T2) werden weitere Informationen auf den Adressbus 14a gebracht. Diese weiteren Informationen können Bytefreigabeinformationen, zurückgestellte ID-Informationen und die Länge der relevanten Transaktion betreffende Informationen umfassen. Dies ist als Anforderungsphase B (REQB) angezeigt.
Die Fehler-Phase 76 zeigt irgendwelche durch die Anforderung ausgelösten Paritätsfehler an. Jede Transaktion, die nicht aufgrund der Anzeige eines Fehlers in der Fehler-Phase 76 abgebrochen worden ist, umfasst eine Snoop-Phase 78, welche vier oder mehr Takte, nachdem die Anforderungsphase 74 beginnt, auftritt. Die in der Snoop-Phase 78 erzeugten Ergebnisse werden zurück an die Externer-Bus-Logik 60 berichtet und zeigen an, ob die für die Transaktion ausgegebene Adresse auf eine gültige oder modifizierte (dirty) Cache-Zeile in irgendeinem Bus-Teilnehmer-Cache Bezug nimmt. Die Snoop-Phase 78 zeigt darüber hinaus an, ob es wahrscheinlich ist, dass eine Transaktion in der Reihenfolge bezüglich zuvor ausgegebener Transaktionen abgeschlossen wird, abgebrochen und später erneut versucht wird, oder für einen möglichen Außer-der-Reihe-Abschluss zurückgestellt wird, wenn sie mit einem Prozessor gekoppelt ist, der einen Außer-der-Reihe-Abschluss von Transaktionsanforderungen auf dem Bus gestattet. Das HIT#-Signal 98 wird auf niedrigen Pegel gezogen, um anzuzeigen, dass eine Transaktion auf eine modifizierte Cache-Zeile in einem Cache eines Busteilnehmers Bezug nimmt.
In der Antwortphase 80 berichten Teilnehmer an dem externen Bus an die Externer-Bus-Logik 60 Informationen, die anzeigen, ob die Transaktion erfolgreich war oder fehlschlug, ob garantiert werden kann, dass die Transaktion in der Reihenfolge abgeschlossen wird, ob der Abschluss der Transaktion vorübergehend zurückgestellt werden muss, ob die Transaktion erneut versucht wird und ob die Transaktion die Datenübertragungsphase 82 enthält. Sofern die Transaktion eine Datenübertragungsphase 82 enthält (d. h., der anfordernde Teilnehmer zu schreibende Daten übertragen möchte oder zu lesende Daten angefordert hat), tritt die Transaktion in die Datenübertragungsphase 82 ein.
Es wird wiederum auf 4 Bezug genommen. Während einer Rücken-an-Rücken-Zeilenlesetransaktion voller Geschwindigkeit wird ein Block (chunk) (d. h. 64 Bits) Daten während jeder der vier nachfolgenden Taktperioden (d. h. T7–T11) übertragen.
Aus 4 ist ersichtlich, dass während Zeilenlesetransaktionen voller Geschwindigkeit, welche regelmäßig in Computersystemen auftreten, eine Zwei-Takte-Anforderungsphase 74 eine Vier-Takte-Datenübertragungsphase 82 erzeugt. Demzufolge ist der Adressbus vergleichsweise wenig benutzt (under-utilized), und es tritt zwischen den Anforderungsphasen eine Bandbreitenverschwendung auf, wie es bei 110 in 4 angezeigt ist.
Gemultiplexter Adress- und Datenbus
Es wird auf 5 Bezug genommen, in der ein Paar von Teilnehmern des externen Busses in Form eines Prozessors 12 und eines Externer-Bus-Teilnehmers 21 gezeigt ist, die über einen gemultiplexten Adress- und Datenbus 120 gekoppelt werden sollen, der gemäß einem Ausführungsbeispiel der vorliegenden Erfindung konstruiert ist. Der gemultiplexte Bus 120 ist ein 128-Bit-Bus. Jedoch sind die Lehren der vorliegenden Erfindung in gleicher Weise auf Busse anderer Größen anwendbar, die 32-, 64- und 256-Bit-Busse einschließen. Der Prozessor 12 und der Externer-Bus-Teilnehmer 21 enthalten jeweils eine Externer-Bus-Logik (EBL) 60 gemäß einem Ausführungsbeispiel der vorliegenden Erfindung, die die Kommunikation des jeweiligen Prozessors 12 und des Busteilnehmers 21 über den gemultiplexten Bus 120 ermöglicht. Die vorliegende Erfindung schlägt das Ersetzen eines externen Busses, wie beispielsweise des in 2 gezeigten Busses 14, der einen Adressbus, einen Datenbus und Steuersignale umfasst, durch einen zeitlich gemultiplexten Bus, wie beispielsweise den in 5 gezeigten gemultiplexten Bus 120, vor, bei dem die gesamten 128 Bits des gemultiplexten Busses 20 im wesentlichen zu jedem Zeitpunkt einer bestimmten Funktion gewidmet sind. Im Gegensatz zu dem Bus 14, bei dem jedes Bit des Busses 14 dem Übertragen eines vorgegebenen Datentyps gewidmet ist, können demzufolge einige oder sämtliche Bits des gemultiplexten Busses 120 verschiedene Informationsarten (d. h. Adressen, Daten oder Steuerinformationen) zu verschiedenen Zeitpunkten führen. Insbesondere durch zeitliches Multiplexen des gemultiplexten Busses 120 zum Übertragen von Adress- oder Dateninformationen auf eine adaptive oder intelligente Weise versucht die vorliegende Erfindung die vergleichsweise geringe Benutzung eines speziellen Adressbusses 14a, wie sie oben unter Bezugnahme auf 4 erläutert worden ist, anzugehen.
6 veranschaulicht ein Blockschaltbild, das eine Schaltungsanordnung zeigt, welche gemäß einem Ausführungsbeispiel der vorliegenden Erfindung in die Externer-Bus-Logik 60 aufgenommen werden kann, um die Funktionalität des gemultiplexten Busses 120 auf eine Weise zeitlich zu multiplexen, die die Minderausnutzung der Bandbreite des Busses 120 reduziert. Die Externer-Bus-Logik 60 kann in einen beliebigen mit dem externen Bus gekoppelten Busteilnehmer integriert sein, wie beispielsweise in einen Prozessor, eine Busbrücke, einen Controller oder irgendeinen anderen externen Busteilnehmer. So wie sie gezeigt ist, enthält die Externer-Bus-Logik 60 ein Paar 2-zu-1-Multiplexer (MUXs) 140a und 140b. Der MUX 140a ist so eingekoppelt, dass er Adress- und Datenausgabesignale 142a bzw. 144a empfängt. Jedes der Adress- und Datenausgabesignale 144a und 142a kann die gesamte Bandbreite des gemultiplexten Busses 120 benutzen und kann somit in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung 128 Bits belegen. Demzufolge kann das Anforderungssignal einschließlich der Transaktionsadresse, das eine 2-Takt-Anforderungsphase 74 (d. h. REQA und REQB) benötigt, wie es bei 90 in 4 veranschaulicht ist, aus der Externer-Bus-Logik 60 in einem einzigen Taktzyklus ausgesendet werden, da diese Anforderungssignale nicht mehr auf einen Adressbus, wie beispielsweise den Adressbus 14a, der in 2 gezeigt ist und nur 36 Bits breit ist, beschränkt ist.
In ähnlicher Weise ist während einer Datenübertragungsphase 82 die Externer-Bus-Logik 60 nicht länger auf die Übermittlung von vier 64-Bit-Blöcken (chunks) Daten während vier aufeinanderfolgender Taktperioden über einen 64-Bit-Datenbus 14b, wie sie bei 104 in 4 veranschaulicht ist, beschränkt. Insbesondere kann die Externer-Bus-Logik 60 gemäß der Erfindung vier Datenblöcke über zwei aufeinanderfolgende Taktzyklen aussenden. Auf eine ähnliche Weise ermöglicht der MUX 140b es der Externer-Bus-Logik 60 Adress- und Dateneingabesignale 144b und 142b, die unter Verwendung der gesamten Bandbreite des gemultiplexten Busses 120 übermittelt werden, zu empfangen.
Zur Auswahl zwischen der Anforderungsausgabe 142a und der Datenausgabe 144a kann der Multiplexer 140a durch Anlegen und Wegnehmen eines Auswahlsignals in Form eines Richtungssignals (ADIR#) 146 gesteuert werden. Das Richtungssignal (ADIR#) 146 wird von der Auswahllogik 148 angelegt bzw. weggenommen, welche eine Entscheidungslogik 150 enthält. Die Auswahllogik 148 ist so eingekoppelt, dass sie sowohl ein Busanforderungssignal (BREQ#) 152 als auch ein Frühe-Daten-bereit-Signal (EARLY_DRDY) 154 empfängt, deren Anlegen von der Auswahllogik 148 als Adress- bzw. Datenbusanforderungen interpretiert wird.
Das BREQ#-Signal 152 ist ein Bus-Master-Signal eines symmetrischen Teilnehmers, wodurch ein symmetrischer Externer-Bus-Teilnehmer sich um den externen Bus bewirbt. Insbesondere bei einem Computersystem symmetrischer Teilnehmer, das vier externe Busteilnehmer enthält, legt ein spezieller Busteilnehmer ein BREQ#-Signal 152 auf einer speziellen Ausgangsleitung an und empfängt BREQ#-Signale von den anderen drei Teilnehmern als Eingangssignale. Die symmetrischen Teilnehmer unterstützen eine Buszuteilungsentscheidung auf der Grundlage eines umlaufenden (round-robin) Mechanismus. Ein rotierender ID wird von den vier symmetrischen Busteilnehmern verwendet, um den Teilnehmer mit der geringsten Priorität bei dem nächsten Zuteilungsentscheidungsereignis zu verfolgen. Ein Zuteilungsereignis tritt auf, wenn einer der symmetrischen Busteilnehmer sein BREQ#-Signal 152 auf einem leeren (untätigen) Bus anlegt oder wenn ein aktueller Busbesitzer sein BREQ#-Signal 152 wegnimmt, um den Busbesitz an einen neuen Busbesitzer freizugeben. Das von der Auswahllogik 148, wie sie in 6 veranschaulicht ist, empfangene BREQ#-Signal 152 ist das Ausgabesignal BREQ# 152 eines Busteilnehmers, in dem die relevante Externer-Bus-Logik 60 enthalten ist. Demzufolge gestattet das Anlegen des BREQ#-Signals 152 es der Auswahllogik 148, nicht nur zu bestimmen, dass ein zugeordneter Busteilnehmer die Kontrolle über den externen gemultiplexten Bus 120 anfordert, sondern darüber hinaus auch, dass nach der Zuteilungsentscheidungsphase 72 einer Transaktion eine Anforderungsphase 74 (in welcher Adressinformationen auf den externen gemultiplexten Bus 120 gebracht werden) erforderlich wird. Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung wird das Anlegen des BREQ#-Signals 152 durch die Auswahllogik 148 als Adressbuszugriffsanforderung gewertet.
Das EARLY_DRDY-Signal 154 ist ein Frühe-Daten-bereit-Signal, das von einem Busteilnehmer, in dem die Externer-Bus-Logik enthalten ist, angelegt werden kann und das anzeigt, dass der Busteilnehmer gültige Daten auf den externen gemultiplexten Bus 120 zu bringen wünscht. Das Anlegen des EARLY_DRDY-Signals 154 zeigt an, dass ein Busteilnehmer in die Datenübertragungsphase 82 einer Transaktion einzutreten wünscht. Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung wird das Anlegen des EARLY_DRDY-Signals 154 von der Auswahllogik 148 als Datenbuszugriffsanforderung interpretiert.
Es ist darüber hinaus gezeigt, dass jeder der Multiplexer 140a und 140b einen ENABLE-Eingang (Freigabeeingang) aufweist, über welchen der jeweilige Multiplexer entweder freigegeben oder gesperrt werden kann. Der ”Ausgabe”-Multiplexer 140a wird durch Anlegen des BREQ#-Signals 152 oder des EARLY_DRDY-Signals 154 freigegeben, wobei das Anlegen dieser Signale anzeigt, dass die die Externer-Bus-Logik 60 enthaltende Einrichtung eine Datenausgabe oder eine Anforderungsausgabe auszugeben wünscht. Andererseits wird der ”Eingabe”-Multiplexer 140b durch Anlegen eines BREQ#-Signals 153 oder eines EARLY_DRDY-Signals 155, die einer anderen Einrichtung zugeordnet sind, die Zugriff auf den gemultiplexten Bus 120 hat, freigegeben, wobei das Anlegen eines der beiden Signale 153 oder 154 anzeigt, dass diese andere Einrichtung eine Anforderungs- oder Datenausgabe auszugeben wünscht, die eine Eingabe an die die Externer-Bus-Logik 60 enthaltende Einrichtung enthalten kann.
Durch Überwachen der Signale 152 und 154 ist die Auswahllogik 148 somit in der Lage zu erfassen, wenn ein der Externer-Bus-Logik 60 zugeordneter Busteilnehmer einen Zugriff auf den gemultiplexten Bus 120 benötigt, und ob es Zweck dieses Zugriffs ist, eine Anforderungsphase oder eine Datenübertragungsphase einer Transaktion auszuführen (d. h. eine Adress- oder eine Datenzugriffsanforderung zu bedienen).
Wenn entweder eine Adress- oder eine Datenbuszugriffsanforderung durch Anlegen entweder des BREQ#-Signals 152 oder des EARLY_DRDY-Signals 154 erfasst wird, und keine Konkurrenz zwischen einer solchen Zugriffsanforderung und einer Zugriffsanforderung des entgegengesetzten Typs (d. h. Konkurrenz zwischen einer Adressbusanforderung und einer Datenbusanforderung) auftritt, dann gewährt die Auswahllogik 148 einfach den gemultiplexten Bus 120 der jeweiligen Zugriffsanforderung. Insbesondere gewährt die Auswahllogik 148 den gemultiplexten Bus 120 einer Anforderungsausgabe 142a und einer Anforderungseingabe 142b in Erwiderung des Anlegens des Signals BREQ# 152, indem das ADIR#-Signal 146 weggenommen wird (d. h., indem das ADIR#-Signal 146 auf hohen Pegel angesteuert wird). Alternativ gewährt die Auswahllogik 148 den gemultiplexten Bus 120 einer Datenausgabe 144a oder einer Dateneingabe 144b in Erwiderung des Anlegens des Signals EARLY_DRDY 154, indem das ADIR#-Signal 146 angelegt wird (d. h., indem das Signal ADIR# 146 auf niedrigen Pegel gesteuert wird).
Sollte andererseits eine Konkurrenz zwischen Adress- und Datenbuszugriffsanforderungen auftreten, dient die Zuteilungsentscheidungslogik 150 dazu, zwischen diesen konkurrierenden Buszugriffsanforderungen zu entscheiden. Eine Konkurrenz zwischen Adress- und Datenbuszugriffsanforderungen kann auftreten, wenn beispielsweise das BREQ#-Signal 152 und das EARLY_DRDY-Signal 154 gleichzeitig angelegt werden oder wenn es eine ausstehende Buszugriffsanforderung des einen Typs gibt und eine Buszugriffsanforderung des entgegengesetzten Typs vor dem Bedienen der anhängigen Anforderung empfangen wird. Wenn eine Bustransaktion (entweder Daten oder Adresse) zu dem Zeitpunkt erfolgt, zudem die Konkurrenz auftritt, sollte die Zuteilungsentscheidungslogik einen Abschluss der Transaktion gestatten, bevor sie die Zuteilungsentscheidungsoperation vornimmt.
Es ist gezeigt, dass die Zuteilungsentscheidungslogik 150 mit drei Registern gekoppelt ist, nämlich einem Schwellenwertregister 156, einem Anforderungszählregister 158 und einem Snoop-Zählregister 160. Das Anforderungszählregister 158 hält eine interne Anforderungszählung (z. B. den von den IA-Architektur-Prozessoren gehaltenen Wert ”RCNT”), um die Anzahl der auf dem gemultiplexten Bus 120 ausstehenden Transaktionen nachzuhalten. Die interne Anforderungszählung wird jeweils um 1 inkrementiert, wenn eine neue Transaktion, die von einem beliebigen Busteilnehmer herrührt, in eine Anforderungsphase 74 eintritt. Ferner wird die interne Anforderungszählung um 1 dekrementiert, wenn eine ausstehende Transaktion die Antwortphase 80 abschließt oder in der Fehler-Phase 76 abgebrochen wird. Bei einem Ausführungsbeispiel wird die interne Anforderungszählung darüber hinaus während des Rücksetzens und der Businitialisierung auf Null initialisiert und kann einen Wert von 0 bis 7 enthalten, wobei 7 die Maximalanzahl von auf dem gemultiplexten Bus 120 ausstehenden Transaktionen ist.
Das Snoop-Zählregister 160 hält eine interne Snoop-Zählung (z. B. den von IA-Prozessoren gehaltenen Wert ”SCNT”), um die Anzahl der ausstehenden Transaktionen auf dem gemultiplexten Bus 120, die noch die Snoop-Phase 78 abschließen müssen, nachzuhalten. Die interne Snoop-Zählung wird um 1 inkrementiert, wenn eine neue Transaktion in die Anforderungsphase 74 eintritt, und wird um 1 dekrementiert, wenn eine ausstehende Transaktion die Snoop-Phase 78 abschließt oder in der Fehler-Phase 76 abgebrochen wird. Bei einem Ausführungsbeispiel wird die interne Snoop-Zählung während des Rücksetzens und der Businitialisierung auf 0 initialisiert und kann einen Wert zwischen 0 und 7 haben.
Das Schwellenwertregister 156 speichert einen oder mehrere Schwellenwerte, die mit dem in dem Anforderungszähl- und Snoop-Zähl-Register 158 und 160 gespeicherten Werten der internen Anforderungszählung und internen Snoop-Zählung von der Zuteilungsentscheidungslogik 150 für die Zwecke der Zuteilungsentscheidung zwischen konkurrierenden Adress- und Datenbuszugriffsanforderungen verglichen werden. Bei einem Ausführungsbeispiel der vorliegenden Erfindung kann die Zuteilungsentscheidungslogik 150 den Anforderungszählwert (d. h. die Anzahl der ausstehenden Datentransaktionen auf dem gemultiplexten Bus) mit einer Datenschwellenwertzahl vergleichen, die in dem Schwellenwertregister 156 gehalten wird. Wenn die Anzahl der ausstehenden Datentransaktionen auf dem gemultiplexten Bus die Datenschwellenwertnummer überschreitet, dann gewinnt eine Datenbuszugriffsanforderung das Zuteilungsereignis. Bei einem weiteren Ausführungsbeispiel der vorliegenden Erfindung kann die Zuteilungsentscheidungslogik 150 die interne Snoop-Zählung, die in dem Snoop-Zählregister 160 gehalten wird, (d. h. die Anzahl der ausstehenden Snoop-Transaktionen auf dem gemultiplexten Bus 120) mit einer in dem Schwellenwertregister 156 gehaltenen Snoop-Schwellenwertzahl vergleichen. Sollte die Anzahl der ausstehenden Snoop-Transaktionen die Snoop-Schwellenwertzahl überschreiten, dann gewinnt wiederum eine Datenbuszugriffsanforderung das Zuteilungsereignis. Es ist schnell klar, dass viele andere Zuteilungsentscheidungsschemata verschiedene Permutationen und Kombinationen der internen Anforderungszählung und der internen Snoop-Zählung verwendet werden können, um zwischen konkurrierenden Adress- und Datenbuszugriffsanforderungen zu entscheiden.
Obwohl gezeigt ist, dass die Register 156, 158 und 160 von der Zuteilungsentscheidungslogik 150 getrennt angeordnet sind, können einige oder sämtliche dieser Register in die Zuteilungsentscheidungslogik 150 aufgenommen werden. Das Schwellenwertregister 156 ist darüber hinaus programmierbar, so dass die darin gespeicherten Schwellenwerte (z. B. die Datenschwellenwertzahl oder die Snoop-Schwellenwertzahl) dynamisch programmierbar sind. Beispielsweise können die in dem Schwellenwertregister 156 gehaltenen Schwellenwerte durch entweder ein Betriebssystem oder ein Anwendungsprogramm eines Computersystems, in dem die Externer-Bus-Logik 60 arbeitet, eingestellt werden. Beispielsweise kann es sein, dass ein bestimmtes Anwendungsprogramm wünscht, Datenbuszugriffsanforderungen die Priorität zu geben, wobei in diesem Fall das Anwendungsprogramm auf das Schwellenwertregister 156 zugreifen kann und darin eine niedrige Datenschwellenwertzahl speichern kann. Darüber hinaus können die in dem Register 156 gespeicherten Schwellenwertzahlen während der Ausführung eines Anwendungsprogramms dynamisch änderbar oder programmierbar sein. Beispielsweise kann ein Anwendungsprogramm einen oder mehrere in dem Register 156 gespeicherte Schwellenwerte auf der Grundlage verschiedener weiterer Parameter ändern, die von dem Anwendungsprogramm während der Ausführung überwacht werden.
Bei einem alternativen Ausführungsbeispiel kann die Zuteilungsentscheidungslogik 150 ein ”statisches” Zuteilungsentscheidungsschema benutzen, bei dem einer anhängigen Zugriffsanforderung eines Anforderungstyps (entweder einer anhängigen Datenanforderung oder einer Adressanforderung) gegenüber dem jeweils anderen Anforderungstyp stets der Zugriff bevorzugt gewährt wird. In diesem Fall werden der Anforderungszähl- und der Snoop-Zähl-Wert ignoriert und spielen keine Rolle bei dem Zuteilungsentscheidungsprozess.
Bei einem weiteren Ausführungsbeispiel der vorliegenden Erfindung ermöglicht die Externer-Bus-Logik 60 eine vollständige Kompatibilität mit herkömmlichen Bussen (wie beispielsweise dem Pentium Pro-Bus), indem eine selektive Sperrung der Auswahllogik 148 ermöglicht wird, bei welcher der Zugriff auf den Bus 120 nicht über die Multiplexer 140a und 140b zur Verfügung gestellt wird, sondern statt dessen über eine in dem Pentium Pro genutzte Schnittstelle.
7 ist ein Zeitdiagramm, das in Übereinstimmung mit einem Ausführungsbeispiel der vorliegenden Erfindung Übergänge von Signalen innerhalb der Externer-Bus-Logik 60 und des in 5 gezeigten gemultiplexten Busses 120 in einem Multiprozessor(MP)-System veranschaulicht. Insbesondere veranschaulicht 7 ein Taktsignal 92 des externen Busses, das Richtungssignal (ADIR#) 146, das Adress-Strobe-Signel (ADS#) 94, gemultiplexte Bussignale 170 und interne Anforderungs- und Snoop-Zähl-Signale 172.
Wie bei 174 angezeigt, definiert das Anlegen des ADS#-Signals 94, wie es in 4 gezeigt ist, den Beginn einer Anforderungsphase 74 einer Transaktion, in Erwiderung dessen die Externer-Bus-Logik 60 in der Lage ist, gleichzeitig zwei ”Sätze” von Anforderungssignalen (d. h. REQAB1) auf den gemultiplexten Bus 120 auszugeben, wie es bei 176 gezeigt ist. Die Fähigkeit der Externer-Bus-Logik 60, gleichzeitig zwei ”Sätze” von Anforderungssignalen auszugeben, ist möglich, da die vollständige 128-Bit-Bandbreite des gemultiplexten Busses 120 für Anforderungssignale während der Anforderungsphase 74 verfügbar ist. Es sei ferner angemerkt, dass das ADIR#-Signal 176 während der Anforderungsphase 74 nicht angelegt ist (d. h. es ist auf hohem Pegel). Es wird wieder auf 6 Bezug genommen; es ist klar, dass die Anforderungsausgabe 142a entsprechend von dem Multiplexer 140a zur Aussendung auf den gemultiplexten Bus 120 ausgewählt wird. Zu Beginn des Taktzyklus T4 legt die Auswahllogik 148 das ADIR#-Signal 146 an, wie es bei 178 gezeigt ist, wobei das Anlegen dieses Signals den Beginn der Datenübertragungsphase 82 anzeigt. Zu diesem Zeitpunkt wird das ADS#-Signal 94 entsprechend weggenommen. Es wird wieder auf 6 Bezug genommen; das Anlegen des ADIR#-Signals 146 veranlasst den Multiplexer 140b, die Dateneingabe 144 zur Weiterleitung auf dem gemultiplexten Bus 120 auszuwählen.
Nach der Ausgabe der zwei ”Sätze” von Anforderungssignalen (d. h. REQAB1) auf den gemultiplexten Bus 120, wie bei 176 angezeigt, kann eine Datenantwort (nicht notwendigerweise in Beantwortung der bei 176 angezeigten Anforderung) in Form eines ersten 128-Bit-Blocks (chunk) auf den gemultiplexten Bus 120 gebracht werden, wie es bei 180 während eines halben Taktes gezeigt ist. Bei 182 wird ein zweiter 128-Bit-Block in ähnlicher Weise auf den gemultiplexten Bus 120 übermittelt. Die bei 180 und 182 angezeigten Datenantworten können in Beantwortung einer früheren Transaktion ausgegeben werden, die durch eine mit dem gemultiplexten Bus 120 gekoppelte erste Einrichtung ausgegeben wurde. Bei 184 und 186 werden zwei weitere Datenantworten in Form von 128-Bit-Blöcken (chunks) auf den gemultiplexten Bus 120 in Beantwortung einer von einer mit dem gemultiplexten Bus gekoppelten zweiten Einrichtung, beispielsweise einem Prozessor, ausgegebenen früheren Transaktion weitergeleitet. Auf eine ähnliche Weise können zwei (nicht gezeigte) 128-Bit-Blöcke, die die Datenantwort auf die bei 176 angezeigte Anforderung enthalten, auf dem gemultiplexten Bus 120 zu irgendeinem späteren Zeitpunkt weitergeleitet werden. Die bei 180–186 angezeigten Datenantworten sind von früheren (nicht gezeigten) Anforderungen abhängig, die ähnlich der Anforderung 176 sind und die auf den gemultiplexten Bus 120 von einer einzigen oder zwei verschiedenen mit dem gemultiplexten Bus 120 gekoppelten Einrichtungen gebracht wurden.
Es sei ferner angemerkt, dass gezeigt ist, dass der interne Anforderungszählwert ”RCNT” nach dem Ausgeben der Anforderung bei 176 gleich ”2” ist, wobei dies anzeigt, dass zwei Transaktionen gegenwärtig auf dem gemultiplexten Bus 120 ausstehen.
Da sowohl während der Anforderungsphase 74 als auch der Datenübertragungsphase 82 die volle 128-Bit-Bandbreite des gemultiplexten Busses 120 verfügbar ist, gestattet die vorliegende Erfindung, dass die Anforderungsphase 74 auf eine einzige Taktperiode abgekürzt wird, im Unterschied zu den zwei Taktperioden bei dem von dem Pentium Pro-Mikroprozessor benutzten Protokoll des externen Busses. Die Datenübertragungsphase 82 wird auf zwei aufeinanderfolgende Taktperioden abgekürzt, im Unterschied zu den vier aufeinanderfolgenden Taktperioden in dem Busprotokoll des externen Pentium Pro-Busses. Während ein zeitliches Multiplexen der Anforderungs- und Datenphasen auf einem einzigen Bus die Parallelität (und Pipelinetiefe) des von dem Pentium Pro-Mikroprozessor benutzten externen Busses reduziert, wird darauf vertraut, dass die vorliegende Erfindung zu einem erhöhten Busdurchsatz führt, insbesondere bei Architekturen, wo Transaktionen voller Geschwindigkeit vorherrschend sind.
Der gemultiplexte Bus 120 kann eine Kompatibilität mit dem externen Busprotokoll des Pentium Pro-Prozessors erreichen, indem die Leitungen [A3...A36] den Leitungen [AD0...AD31] des gemultiplexten Busses zugewiesen werden. Darüber hinaus können die Anforderungsleitungen [REQ0...4] den Leitungen [AD32...AD36] und die Datenleitungen [D0...D64] den Leitungen [AD64...AD127] zugewiesen werden. Der Multiplexer 140 würde bei diesem Szenarium Eingaben nur aus den Anforderungsausgängen 142a akzeptieren, während die Datenausgabe 144a gesperrt wäre. Darüber hinaus würde das Signal ADIR# 146 gesperrt werden und Adressen als 32-Bit-Doppelworte ausgegeben werden. So könnte eine herkömmliche Pentium Pro-Bustransaktion über den gemultiplexten Bus 120 ausgegeben werden. Eine solche Kompatibilität würde darüber hinaus beim Einschalten/Rücksetzen zu konfigurieren sein, da eine Benachrichtigung der Chipsätze und der Peripherieeinrichtungen bezüglich der Konfiguration des gemultiplexten Busses 120 zu erfolgen hätte.
8 ist ein Ablaufdiagramm, das ein Verfahren 179 gemäß einem Ausführungsbeispiel der Erfindung zum Betreiben eines gemultiplexten Adress- und Datenbusses 120 in einem Computersystem veranschaulicht. Das Verfahren 179 beginnt bei 181 und setzt sich zum Schritt 183 fort, bei dem eine Zugriffsanforderung auf den gemultiplexten Bus (entweder eine Adress- oder eine Datenbuszugriffsanforderung) empfangen wird. Bei einem Ausführungsbeispiel der Erfindung wird der Empfang einer Buszugriffsanforderung festgestellt, indem das Anlegen entweder des BREQ#-Signals 152 oder des EARLY_DRDY-Signals 154 von der Auswahllogik 148 erfasst wird. Am Entscheidungsblock 185 wird eine Feststellung darüber getroffen, ob eine Konkurrenz zwischen der im Schritt 183 empfangenen Buszugriffsanforderung und irgendeiner weiteren anhängigen oder gleichzeitig empfangenen Buszugriffsanforderung des entgegengesetzten Typs vorhanden ist. Bei einem Ausführungsbeispiel kann die Auswahllogik 148 bestimmen, ob eine Konkurrenz zwischen Adress- und Datenbuszugriffsanforderungen besteht. Wenn dies nicht der Fall ist, fährt das Verfahren 179 zum Schritt 187 fort, wo der Zugriff auf den gemultiplexten Bus 120 der im Schritt 183 empfangenen Buszugriffsanforderung gewährt wird. Insbesondere kann die Auswahllogik 148 den Zugriff auf den gemultiplexten Bus 120 entweder der Anforderungsausgabe 142a oder der Datenausgabe 144a gewähren, indem das Signal ADIR# 146 angelegt oder weggenommen wird.
Sollte sich andererseits am Entscheidungsblock 185 herausstellen, dass eine Konkurrenz zwischen anhängigen Adress- und Datenbuszugriffsanforderungen besteht, fährt das Verfahren 179 zum Schritt 190 fort, bei dem ein Zuteilungsentscheidungsschema implementiert wird, um zwischen konkurrierenden Buszugriffsanforderungen zu entscheiden. Insbesondere entscheidet die Zuteilungsentscheidungslogik 150 in Übereinstimmung mit einem einer Reihe von Schemata, um zu bestimmen, welcher der konkurrierenden Adress- und Datenbuszugriffsanforderungen Priorität gegeben werden sollte. Beim Schritt 192 wird der gewinnenden Buszugriffsanforderung der Zugriff auf den gemultiplexten Bus 120 gewährt. Insbesondere kann die Auswahllogik 148 das ADIR#-Signal 146 gemäß dem Ausgang des Zuteilungsentscheidungsschemas anlegen oder wegnehmen. Das Verfahren 179 endet dann im Schritt 194.
Es sei angemerkt, dass das Verfahren 179 nicht während aktiver Daten- oder Adressübertragungen implementiert wird und dass das ADIR#-Signal nicht während einer Daten- oder Adresstransaktion angelegt oder weggenommen werden darf. Das Verfahren 179 wird während der ”Anforderungs”-Aktivität (z. B. der Anforderungsphase 74) durchgeführt, die nur einen Taktzyklus lang sein darf, um den Besitzer des Busses 120 während des nächsten Taktzyklus zu bestimmen.
9A–9C sind Ablaufdiagramme, die drei beispielhafte adaptive Zuteilungsentscheidungsschemata veranschaulichen, die beim Schritt 190 in dem in 8 veranschaulichten Verfahren 179 benutzt werden können. Selbstverständlich könnte auch eine statische Zuteilungsentscheidung benutzt werden. Es wird zunächst auf 9A Bezug genommen; das Zuteilungsentscheidungsschema 190 beginnt beim Schritt 200 und fährt dann zum Schritt 202 fort, in dem eine Bestimmung über die Anzahl der ausstehenden Datentransaktionen auf dem externen gemultiplexten Bus 120 getroffen wird. Bei einem Ausführungsbeispiel liest die Zuteilungsentscheidungslogik 150 die in dem Anforderungszählregister 158 gehaltene interne Anforderungszählung, um die Anzahl der ausstehenden Datentransaktionen zu bestimmen.
Im Schritt 204 wird eine Datenschwellenwertzahl bestimmt. Bei einem Ausführungsbeispiel kann die Zuteilungsentscheidungslogik 150 eine Datenschwellenwertzahl lesen, die in dem Schwellenwertregister 156 gehalten wird. Wie oben erwähnt, kann diese Datenschwellenwertzahl dynamisch geändert werden, beispielsweise durch ein Betriebssystem oder ein Anwendungsprogramm, die in dem Computersystem ausgeführt werden.
Beim Entscheidungskasten 206 wird von der Zuteilungsentscheidungslogik 150 bestimmt, ob die Anzahl der ausstehenden Datentransaktionen die Datenschwellenwertzahl überschreitet. Wenn dies der Fall ist, zeigt dies an, dass ein Rückstau von Datentransaktionen aufgetreten ist und dass jetzt den Datentransaktionen der Vorzug gegeben werden sollte, um diesen Rückstau zu löschen. Dementsprechend fährt in diesem Fall das Zuteilungsentscheidungsschema 190 zum Schritt 208 fort, bei dem eine konkurrierende Datenbuszugriffsanforderung als gewinnende Buszugriffsanforderung gekennzeichnet wird. Das Verfahren endet dann im Schritt 210.
Sollte sich andererseits beim Entscheidungsblock 206 herausstellen, dass die Anzahl der ausstehenden Datentransaktionen (z. B. RCNT) nicht die Datenschwellenwertzahl überschreitet, fährt das Zuteilungsentscheidungsschema 190 zum Schritt 212 fort, bei dem eine konkurrierende Adressbuszugriffsanforderung als gewinnende Anforderung gekennzeichnet wird. Das Zuteilungsentscheidungsschema 190 fährt dann vom Schritt 212 zum Schritt 210 fort.
9B veranschaulicht ein alternatives Zuteilungsentscheidungsschema 190, das im wesentlichen dem in 9A veranschaulichten Schema entspricht, sich aber dadurch unterscheidet, dass eine Anzahl von ausstehenden Snoop-Transaktionen bestimmt und mit einer Snoop-Schwellenwertzahl verglichen wird, um zu bestimmen, welche der konkurrierenden Adress- und Datenbuszugriffsanforderungen als gewinnende Anforderung gekennzeichnet wird.
9C veranschaulicht ein weiteres Ausführungsbeispiel eines Zuteilungsentscheidungsschemas 190, das im wesentlichen eine Kombination der in den 9A und 9B veranschaulichten Zuteilungsentscheidungsschemata darstellt. Vom Schritt 240 fährt das Zuteilungsentscheidungsschema 190 zum Schritt 242 fort, wo eine Bestimmung sowohl der Anzahl der ausstehenden Daten- als auch der Snoop-Transaktionen auf dem gemultiplexten Bus vorgenommen wird. Anschließend, beim Schritt 244, werden sowohl die Daten- als auch die Snoop-Schwellenwertzahl bestimmt. Am Entscheidungsblock 246 wird eine erste Bestimmung vorgenommen, ob die Anzahl der ausstehenden Datentransaktionen die Datenschwellenwertzahl überschreitet. Wenn dies der Fall ist, fährt das Verfahren zum Schritt 248 fort, bei dem eine konkurrierende Datenbuszugriffsanforderung als gewinnende Anforderung gekennzeichnet wird. Sollte andererseits beim Entscheidungsblock 246 festgestellt werden, dass die Anzahl der ausstehenden Datentransaktionen nicht die Datenschwellenwertzahl überschreitet, fährt das Zuteilungsentscheidungsschema 190 zum Entscheidungsblock 252 fort, bei dem eine Bestimmung vorgenommen wird, ob die Anzahl der ausstehenden Snoop-Transaktionen die Snoop-Transaktionsschwellenwertzahl überschreitet. Wenn dies der Fall ist, fährt das Zuteilungsentscheidungsschema 190 wiederum zum Schritt 148 fort, in dem die konkurrierende Datenbuszugriffsanforderung als gewinnende Anforderung gekennzeichnet wird. Sollte andererseits die Anzahl der ausstehenden Snoop-Transaktionen die Snoop-Schwellenwertzahl nicht überschreiten, fährt das Zuteilungsentscheidungsschema 190 vom Entscheidungsblock 252 zum Schritt 254 fort, in dem eine konkurrierende Adressbuszugriffsanforderung als gewinnende Anforderung gekennzeichnet wird. Das Zuteilungsentscheidungsschema 190 endet dann im Schritt 250.
Das in 9C veranschaulichte Zuteilungsentscheidungsschema 190 gestattet einen höheren Grad der Abstimmung und des Zuschneidens des Zuteilungsentscheidungsschemas beispielsweise durch ein Anwendungsprogramm, um die Ausgabe des externen gemultiplexten Busses 120 für die jeweilige Anwendung zu optimieren. Die ”Abstimmung” des Zuteilungsentscheidungsschemas 190 wird durchgeführt, indem Daten- und/oder Snoop-Schwellenwertzahlen eingestellt werden, die für das jeweilige Anwendungsprogramm optimiert sind.
Die Erfindung erstreckt sich auf weitere Zuteilungsentscheidungsschemata, bei denen entweder eine Daten- oder eine Adressanforderung als gewinnende Anforderung als Standardausgang des Zuteilungsentscheidungsschemas erkannt wird. Bei diesen Schemata werden weitere Faktoren (z. B. die Anzahl der ausstehenden Bustransaktionen) nicht berücksichtigt.
Die Zuteilungsentscheidungslogik 150 kann darüber hinaus in der Lage sein, ein beliebiges oder mehrere der oben erörterten Zuteilungsentscheidungsschemata zu implementieren, und programmierbar sein, um zwischen einer Anzahl der Zuteilungsentscheidungsschemata, die implementiert werden können auszuwählen. Die Auswahl des von der Zuteilungsentscheidungslogik 150 benutzten Zuteilungsentscheidungsschemas kann durch ein Betriebssystem oder ein sich in dem Computersystem aufhaltendes Anwendungsprogramm vorgenommen werden.
Während die vorliegende Erfindung als bezüglich eines externen Busses implementiert beschrieben worden ist, können die Lehren der vorliegenden Erfindung darüber hinaus auf einen Backside-Bus zwischen einem Prozessor und einem Cache angewendet werden.

Claims

Verfahren zum Betreiben eines zeitlich gemultiplexten Adress- und Datenbusses in einem Computersystem, dessen Busleitungen im zeitlichen Multiplex entweder mit Adressleitungen oder mit Datenleitungen eines Busteilnehmers gekoppelt werden können, wobei der Datenaustausch zwischen den Busteilnehmern in Form von mehrere Phasen umfassenden Bustransaktionen stattfindet, wobei sich ein Busteilnehmer in einer Zuteilungsphase um den Busbesitz bewirbt und in einer Anforderungsphase Adressinformationen auf den Bus ausgibt, wobei in einer Datenphase Daten über den Bus übertragen werden, wobei sich die Phasen verschiedener Bustransaktionen überlappen können, so dass sich eine Anforderungsphase einer Bustransaktion, bei der Adressinformationen auf den Bus ausgegeben werden sollen und eine Adressbuszugriffsanforderung auftritt, mit einer Datenphase einer anderen Transaktion, bei der Daten über den Bus übertragen werden sollen und eine Datenbuszugriffsanforderung auftritt, überlappen können, wobei das Verfahren die Schritte umfasst: Entscheiden einer Zuteilung zwischen einer Adressbuszugriffsanforderung und einer Datenbuszugriffsanforderung, die um einen Zugriff auf den gemultiplexten Bus konkurrieren, in Übereinstimmung mit einem vorgegebenen Kriterium; und Gewähren des gemultiplexten Busses entweder der Adress- oder der Datenbuszugriffsanforderung in Übereinstimmung mit dem Ausgang der Zuteilungsentscheidung, wobei die Busleitungen in Übereinstimmung mit dem Ausgang der Zuteilungsentscheidung entweder mit den Adressleitungen oder mit den Datenleitungen des Busteilnehmers gekoppelt werden.
Verfahren nach Anspruch 1, wobei der Schritt der Zuteilungsentscheidung die Schritte des Bestimmens, ob eine Anzahl ausstehender Datentransaktionen auf dem gemultiplexten Bus eine vorgegebene Schwelle überschreitet, umfasst.
Verfahren nach Anspruch 1, wobei der Schritt der Zuteilungsentscheidung den Schritt des Bestimmens, ob eine Anzahl ausstehender Snoop-Transaktionen auf dem gemultiplexten Bus eine vorgegebene Schwelle überschreitet, umfasst.
Verfahren nach Anspruch 1, wobei der Schritt der Zuteilungsentscheidung das Erkennen der Datenanforderung als gewinnende Anforderung in dem Zuteilungsentscheidungsschritt ohne Berücksichtigung weiterer Faktoren umfasst.
Verfahren nach Anspruch 1, wobei der Schritt der Zuteilungsentscheidung das Erkennen der Adressanforderung als gewinnende Anforderung in dem Zuteilungsentscheidungsschritt ohne Berücksichtigung weiterer Faktoren umfasst.
Verfahren nach Anspruch 1, umfassend den Schritt des Modifizierens des vorgegebenen Kriteriums.
Verfahren nach Anspruch 6, wobei das vorgegebene Kriterium von einem Betriebssystem, das auf dem Computersystem betrieben wird, modifiziert wird.
Verfahren nach Anspruch 6, wobei das vorgegebene Kriterium durch ein in dem Computersystem ausgeführtes Anwendungsprogramm modifiziert wird.
Verfahren nach Anspruch 6, enthaltend den Schritt des Modifizierens einer Schwellenzahl, mit welcher die Anzahl der ausstehenden Transaktionen auf dem gemultiplexten Bus während des Zuteilungsentscheidungsschrittes verglichen wird.
Busschnittstelle eines Busteilnehmers, die mit einem zeitlich gemultiplexten Adress- und Datenbus in einem Computersystem gekoppelt werden soll, dessen Busleitungen im zeitlichen Multiplex entweder mit Adressleitungen oder mit Datenleitungen der Busschnittstelle gekoppelt werden können, wobei der Datenaustausch auf dem Bus in Form von mehrere Phasen umfassenden Bustransaktionen stattfindet, wobei sich ein Busteilnehmer in einer Zuteilungsphase um den Busbesitz bewirbt und in einer Anforderungsphase Adressinformationen auf den Bus ausgibt, wobei in einer Datenphase Daten über den Bus übertragen werden, wobei sich die Phasen verschiedener Bustransaktionen überlappen können, so dass sich eine Anforderungsphase einer Bustransaktion, bei der Adressinformationen auf den Bus ausgegeben werden sollen und eine Adressbuszugriffsanforderung auftritt, mit einer Datenphase einer anderen Transaktion, bei der Daten über den Bus übertragen werden sollen und eine Datenbuszugriffsanforderung auftritt, überlappen können, wobei die Busschnittstelle aufweist: eine Zuteilungsentscheidungslogik für die Zuteilungsentscheidung zwischen einer Adressbuszugriffsanforderung und einer Datenbuszugriffsanforderung, die um einen Zugriff auf den gemultiplexten Bus konkurrieren, gemäß einem vorgegebenen Kriterium; und eine Auswahllogik zum Gewähren des gemultiplexten Busses entweder der Adress- oder der Datenanforderung in Übereinstimmung mit dem Ausgang der Zuteilungsentscheidung, wobei die Busleitungen in Übereinstimmung mit dem Ausgang der Zuteilungsentscheidung entweder mit den Adressleitungen oder mit den Datenleitungen der Busschnittstelle gekoppelt werden.
Busschnittstelle nach Anspruch 10, wobei die Zuteilungsentscheidungslogik so konfigurierbar ist, dass sie zwischen der Adressanforderung und der Datenanforderung in Übereinstimmung mit irgendeinem einer Mehrzahl von Zuteilungsentscheidungsschemata entscheidet.
Busschnittstelle nach Anspruch 11, wobei die Zuteilungsentscheidungslogik von einem Betriebssystem und/oder einem Anwendungsprogramm des Computersystems konfigurierbar ist.
Busschnittstelle nach Anspruch 10, wobei die Zuteilungsentscheidungslogik dem Bestimmen einer Anzahl ausstehender Datentransaktionen auf dem gemultiplexten Bus und einer Datenschwellenwertzahl und dem Bestimmen, ob die Anzahl der ausstehenden Datentransaktionen auf dem gemultiplexten Bus die Datenschwellenwertzahl überschreitet, dient.
Busschnittstelle nach Anspruch 10, wobei die Zuteilungsentscheidungslogik zum Bestimmen einer Anzahl ausstehender Snoop-Transaktionen auf dem gemultiplexten Bus und einer Snoop-Schwellenwertzahl und zum Bestimmen, ob die Anzahl der ausstehenden Snoop-Transaktionen auf dem gemultiplexten Bus die Snoop-Schwellenwertzahl überschreitet, dient.
Busschnittstelle nach Anspruch 10, wobei die Zuteilungsentscheidungslogik dem Erkennen der Datenanforderung als gewinnende Anforderung in der Zuteilungsentscheidung ohne Berücksichtigung weiterer Faktoren dient.
Busschnittstelle nach Anspruch 10, wobei die Zuteilungsentscheidungslogik dem Erkennen der Adressanforderung als gewinnende Anforderung in der Zuteilungsentscheidung ohne Berücksichtigung weiterer Faktoren dient.
Busschnittstelle nach Anspruch 10, enthaltend ein Register zum Speichern einer Schwellenwertzahl, auf das von der Zuteilungsentscheidungslogik zur Entscheidung zwischen der Adressanforderung und der Datenanforderung zugegriffen werden kann, wobei die Schwellenwertzahl dynamisch änderbar ist.
Busteilnehmer, der mit einem zeitlich gemultiplexten Adress- und Datenbus in einem Computersystem gekoppelt werden soll, wobei der Busteilnehmer eine Busschnittstelle nach einem der Ansprüche 10–17 enthält.