DE60028992T2 - Leistungssteuerungsverfahren für ein rechnersystem mit einer knotenpunktarchitektur - Google Patents

Leistungssteuerungsverfahren für ein rechnersystem mit einer knotenpunktarchitektur Download PDF

Info

Publication number
DE60028992T2
DE60028992T2 DE60028992T DE60028992T DE60028992T2 DE 60028992 T2 DE60028992 T2 DE 60028992T2 DE 60028992 T DE60028992 T DE 60028992T DE 60028992 T DE60028992 T DE 60028992T DE 60028992 T2 DE60028992 T2 DE 60028992T2
Authority
DE
Germany
Prior art keywords
hub
interface
agent
computer system
hub agent
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60028992T
Other languages
English (en)
Other versions
DE60028992D1 (de
Inventor
J. David Sacramento HARRIMAN
I. David Folsom POISNER
Jeff Gold River RABE
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Application granted granted Critical
Publication of DE60028992D1 publication Critical patent/DE60028992D1/de
Publication of DE60028992T2 publication Critical patent/DE60028992T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3234—Power saving characterised by the action undertaken
    • G06F1/325—Power saving in peripheral device
    • G06F1/3253—Power saving in bus
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multi Processors (AREA)
  • Stored Programmes (AREA)
  • Information Transfer Systems (AREA)
  • Power Sources (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

  • GEBIET DER ERFINDUNG
  • Die vorliegende Erfindung betrifft den durchschnittlichen Leistungsverbrauch eines Computersystems. Im Besonderen betrifft die vorliegende Erfindung die Reduzierung des Leistungsverbrauchs in einem Computersystem mit einer Hub-Schnittstellenarchitektur.
  • STAND DER TECHNIK
  • Dem Stand der Technik entsprechende Computersysteme beruhen für gewöhnlich auf Bussen wie etwa dem Peripheral Component Interconnect (PCI) Bus gemäß der Specification Revision 2.1, ein von der PCI Special Interest Group, Portland, Oregon, entwickelter Bus, der es Chipsatzkomponenten eines Computersystems ermöglicht, miteinander zu kommunizieren. Zum Beispiel kann eine von einem Prozessor stammende Transaktion, die an ein Plattenlaufwerk gerichtet ist, zuerst einer ersten Chipsatzkomponente zugeführt werden, die als Intermediär zwischen dem Prozessorbus und einem PCI-Bus dient. Die erste Chipsatzkomponente würde danach die Transaktion über den PCI-Bus einer zweiten System-Chipsatzkomponente zuführen, welche die Transaktion danach dem Plattenlaufwerk zustellen würde.
  • Busse, wie etwa der PCI-Bus stellen eine Kommunikation mit andern Computersystemvorrichtungen bereit, wie etwa Grafiksteuereinheiten und Netzwerkadaptern. Da Busse, wie etwa der PCI-Bus, eine Schnittstellenverbindung mit einer Vielzahl von Komponentenarten vorsehen, die alle unterschiedliche Voraussetzungen bzw. Anforderungen aufweisen, wobei die Busse nicht unbedingt diesbezüglich optimiert sind, dass sie eine Kommunikation zwischen Chipsatzkomponenten ermöglichen. Ferner müssen die Hersteller von Chipsätzen, die auf standardisierten Bussen, wie etwa dem PCI-Bus, basieren, Busstandards bzw. Busnormen einhalten, um eine Kompatibilität mit anderen Komponenten zu gewährleisten, und wobei es den Herstellern nicht frei steht, größere Änderungen bezüglich der Art und Weise der Kommunikation der Chipsatzkomponenten untereinander vorzunehmen.
  • Ein weiteres Thema, mit dem sich die Hersteller von Chipsatzkomponenten bei der Entwicklung und Herstellung von Chipsatzkomponenten auseinandersetzen müssen, ist die erforderliche Einhaltung standardisierter Versorgungs- und Signalgebungsspannungen, wenn man sich in Bezug auf die Kommunikation zwischen Chipsatzkomponenten auf Busse wie den PCI-Bus verlässt, wodurch die Hersteller in bestimmte Entwicklungsvorgänge und Fertigungstechnologien fest integriert werden. Somit wäre es wünschenswert, eine flexible Schnittstelle bereitzustellen, die eine optimale Kommunikation zwischen Chipsatzkomponenten bereitstellt. Darüber hinaus wäre es wünschenswert, ein Verfahren und eine Vorrichtung zur Reduzierung der Durchschnittsleistung an mit einer Schnittstelle gekoppelte Chipsatzkomponenten bereitzustellen.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Vorgesehen ist gemäß einem ersten Aspekt der vorliegenden Erfindung ein Verfahren zur Reduzierung des Leistungsverbrauchs eines Computersystems gemäß dem gegenständlichen Anspruch 1.
  • Vorgesehen ist gemäß einem zweiten Aspekt der vorliegenden Erfindung ein Computersystem gemäß dem gegenständlichen Anspruch 9.
  • Gemäß einem Ausführungsbeispiel wird ein Verfahren zur Reduzierung des Leistungsverbrauchs eines Computersystems mit einer Hub-Schnittstellenarchitektur offenbart. Das Verfahren umfasst den Einsatz in einem ersten Leistungszustand und den Übergang in einen zweiten Leistungszustand nach dem Detektieren, dass keine Anforderungen für einen Zugriff auf einen ersten Bus ausstehen.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Die Erfindung ist in den Abbildungen der beigefügten Zeichnungen beispielhaft und ohne einzuschränken veranschaulicht, wobei die gleichen bzw. ähnlichen Elemente mit den gleichen Bezugsziffern bezeichnet sind. In den Zeichnungen zeigen:
  • 1 ein Blockdiagramm eines Ausführungsbeispiels eines Computersystems;
  • 2 ein Blockdiagramm eines Ausführungsbeispiel eines Speichersteuerhubs (Memory Control Hub bzw. MCH) und eines Ein-Ausgabe-Steuerhubs (Input/Output Control Hub bzw. ICH), die über einen Hub-Schnittstellenbus verbunden sind;
  • 3 ein Blockdiagramm eines Ausführungsbeispiels einer Steuereinheit;
  • 4 ein Flussdiagramm eines Ausführungsbeispiels für den Übergang eines Computersystems in einen niedrigen Leistungszustand;
  • 5 ein Flussdiagramm eines Ausführungsbeispiels für den Übergang eines Computersystems aus einem niedrigen Leistungsmodus in einen 1x Modus;
  • 6 ein Flussdiagramm eines Ausführungsbeispiels für den Übergang eines Computersystems aus einem niedrigen Leistungsmodus in einen 4x Modus;
  • 7 ein Zeitsteuerungsdiagramm einer Aufteilungstransaktion, die durch ein Ausführungsbeispiel einer Schnittstelle implementiert wird;
  • 8 ein Zeitsteuerungsdiagramm der Arbitrierung und Übermittlung von Datenpaketen gemäß einem Ausführungsbeispiel;
  • 9 ein Zeitsteuerungsdiagramm der Flusssteuerung von Datenpaketen gemäß einem Ausführungsbeispiel;
  • 10 ein Flussdiagramm der Schritte der Reaktion auf Ablaufsteuerungsoperationen gemäß einem Ausführungsbeispiel;
  • 11 die physikalische Signalschnittstelle gemäß einem Ausführungsbeispiel; und
  • 12 ein Zeitsteuerungsdiagramm der quellensynchronen Taktung gemäß einem Ausführungsbeispiel.
  • GENAUE BESCHREIBUNG DER ERFINDUNG
  • Beschrieben werden ein Verfahren und eine Vorrichtung für den Übergang in und aus einem niedrigen Leistungszustand in einem Computersystem mit einer Hub-Schnittstellenarchitektur. In der folgenden genauen Beschreibung der vorliegenden Erfindung sind zahlreiche besondere Einzelheiten ausgeführt, um ein umfassendes Verständnis der vorliegenden Erfindung zu vermitteln. Für den Fachmann auf dem Gebiet ist es jedoch ersichtlich, dass die vorliegende Erfindung auch ohne die besonderen Einzelheiten ausgeführt werden kann. In anderen Fällen wurden allgemein bekannte Strukturen und Vorrichtungen in Blockdiagrammdarstellung dargestellt und nicht im Detail, um die vorliegende Erfindung nicht unnötig zu verschleiern.
  • Die Abbildung aus 1 zeigt ein Blockdiagramm eines Ausführungsbeispiels eines Computersystems 100. Das Computersystem 100 weist eine Zentraleinheit (CPU) 102 auf, die mit dem Bus 105 gekoppelt ist. In einem Ausführungsbeispiel handelt es sich bei der CPU 102 um einen Prozessor der Pentium® Prozessorfamilie, zu der die Familie der Pentium® II Prozessoren und die Familie der Pentium® III Prozessoren zählen, die von der Intel Corporation, Santa Clara, Kalifornien, USA, erhältlich sind. Alternativ können auch andere CPUs verwendet werden.
  • Ein Memory Control Hub (MCH) 110 ist ebenfalls mit dem Bus 105 gekoppelt. Der MCH 110 kann eine Speichersteuereinheit 112 aufweisen, die mit einem Hauptsystemspeicher 115 gekoppelt ist. Der Hauptsystemspeicher 115 speichert Daten und Befehlsfolgen, die durch die CPU 102 oder jede andere in dem System 100 enthaltene Vorrichtung ausgeführt werden. In einem Ausführungsbeispiel umfasst der Hauptsystemspeicher 115 einen dynamischen Direktzugriffsspeicher (DRAM), wobei der Hauptsystemspeicher 115 aber auch unter Verwendung anderer Speicherarten implementiert werden kann. Weitere Vorrichtungen können ebenfalls mit dem Bus 105 gekoppelt werden, wie etwa mehrere CPUs und/oder mehrere Systemspeicher.
  • Der MCH 110 kann auch eine Grafikschnittstelle 113 aufweisen, die mit einem Grafikbeschleuniger 130 gekoppelt ist. In einem Ausführungsbeispiel ist die Grafikschnittstelle 113 mit dem Grafikbeschleuniger 130 über einen Accelerated Graphics Port (AGP) gekoppelt, der gemäß der Schnittstelle AGP Specification Revision 2.0 arbeitet, entwickelt von der Intel Corporation, Santa Clara, Kalifornien, USA. Zudem weist der MCH 110 eine Hub-Schnittstellensteuereinheit 120 auf. Die Schnittstellensteuereinheit 120 wird zur Kopplung des MCH 110 mit einem Ein-Ausgabe-Steuerhub (ICH) 140 über eine Hub-Schnittstelle A eingesetzt. Der ICH 140 stellt eine Schnittstelle mit Ein-Ausgabe-Vorrichtungen (E/A-Vorrichtungen) in dem Computersystem 100 bereit. Der ICH 140 weist ferner eine Hub-Schnittstellensteuereinheit 120 auf, die zur Kopplung mit dem MCH 110 verwendet wird.
  • Gemäß einem Ausführungsbeispiel der Erfindung kann der ICH 140 auch andere Schnittstellensteuereinheiten 120 aufweisen. Zum Beispiel kann eine zweite Schnittstellensteuereinheit 120 über eine Hub-Schnittstelle B mit einer Netzwerkschnittstelle 160 gekoppelt werden. Darüber hinaus kann eine dritte Schnittstellensteuereinheit 120 mit einer Brücke 165 gekoppelt werden. Die Brücke 165 kann eine Schnittstelle zwischen dem ICH 140 und einem Systembus bereitstellen. Die Brücke 165 ist über eine Hub-Schnittstelle C mit einem ICH 140 gekoppelt. In einem Ausführungsbeispiel handelt es sich bei dem Systembus, der mit der Brücke 165 gekoppelt ist, um einen externen PCI-Bus. Ein Durchschnittsfachmann auf dem Gebiet erkennt, dass die Hub-Schnittstellensteuereinheiten 120 auch mit anderen Vorrichtungen bzw. Bausteinen gekoppelt werden können.
  • Vorrichtungen, die über eine Hub-Schnittstelle miteinander gekoppelt sind, können als Hub-Schnittstellenagenten bezeichnet werden. Ein Hub-Schnittstellenagent, der näher an der CPU 102 in dem Computersystem 100 in Bezug auf die Verlaufstrecke positioniert ist, kann als ein Upstream-Agent bezeichnet werden, während ein Agent, der weiter von der CPU 102 entfernt ist, als ein Downstream-Agent bezeichnet wird. Zum Beispiel ist für die MCH 110/ICH 140 Hub-Schnittstelle MCH 110 der Upstream-Agent, und ICH 140 ist der Downtream-Agent.
  • Der ICH 140 kann auch eine interne PCI-Brücke 146 aufweisen, die eine Schnittstelle mit einem PCI-Bus 142 bereitstellt. Die PCI-Brücke 146 stellt einen Datenpfad zwischen der CPU 102 und Peripheriegeräten bereit. Zu den Vorrichtungen, die mit dem PCI-Bus 142 gekoppelt werden können, zählen eine Audio-Vorrichtung 150 und ein Plattenlaufwerk 155. Der Durchschnittsfachmann auf dem Gebiet wird jedoch anerkennen, dass die CPU 102 und der MCH 110 zur Gestaltung eines einzigen Chips kombiniert werden können. Ferner kann in anderen Ausführungsbeispielen der MCH 110 einen Grafikbeschleuniger 130 aufweisen.
  • Die Abbildung aus 2 zeigt ein Blockdiagramm eines Ausführungsbeispiels des MCH 110, der mit dem ICH 140 über die Hub-Schnittstelle A gekoppelt ist. Eine Hub-Schnittstelle ist ein Mechanismus zur Verbindung der Hauptbausteine der Kernlogik eines Computersystems, wie etwa des Computersystems 100, über einen verhältnismäßig schmalen Datenpfad mit verhältnismäßig hoher Bandbreite. Zwischen einzelnen Komponenten in dem Computersystem 100, wie etwa zwischen MCH 110 und ICH 140, wird die Verbindung Punkt-zu-Punkt implementiert. Gemäß einem Ausführungsbeispiel wird die Übertragung von Daten bzw. Informationen über den Hub-Schnittstellenbus unter Verwendung eines Split Transaction Protokolls auf Paketbasis erreicht. Nähere Einzelheiten zu Hub-Schnittstellen sind nachstehend im Text beschrieben.
  • Der Hub-Schnittstellenbus umfasst einen bidirektionalen Datenpfad 251, ein Stopp-Signal 253, ein A Anforderungssignal (RQA) 254, ein B Anforderungssignal (RQB) 255, ein Taktsignal (CLK) 257 und Daten-Strobe-Signale (STROBE) 258. Gemäß einem Ausführungsbeispiel weist der Datenpfad 251 eine Breite von 8 Bit auf. Der Datenpfad 251 kann jedoch jede Breite aufweisen, die einer Zweierpotenz entspricht. Das Stopp-Signal 243 ist ein für die Ablaufsteuerung verwendetes bidirektionales Signal. Das Signal RQA 254 und das Signal RQB 255 sind Anforderungssignale, die bei normalem Systembetrieb geltend gemacht bzw. aktiviert werden, um die Steuerung des Hub-Schnittstellenbusses anzufordern. Darüber hinaus können sie Signale RQA 254 und RQB 255 in verschiedenen Operationen des Power Management eingesetzt werden, wie dies nachstehend im Text beschrieben ist.
  • STROBE-Signale 258 werden zum Synchronisieren on Daten in einen Hub-Agenten während dem Betrieb in einem quellensynchronen Modus verwendet. Gemäß einem Ausführungsbeispiel können die STROBE-Signale 258 Daten auf dem Vierfachen der Frequenz des Taktsignals takten. Zum Beispiel können STROBE-Signale 258 auf dem Achtfachen des Taktsignals 257 ausgeführt werden. Ferner kann die Hub-Schnittstelle A andere Signalpfade aufweisen, wie etwa ein Rücksetz- bzw. Rückstellsignal zum Zurücksetzen des Systems 100.
  • Wie dies bereits vorstehend im Text beschrieben worden ist, ist die Hub-Schnittstelle A über Schnittstellensteuereinheiten 120 in jedem Agent mit den Agenten gekoppelt. Die Schnittstellensteuereinheiten 120 steuern die Interaktion zwischen den Hub-Schnittstellenagenten. Die Schnittstellensteuereinheiten 120 weisen eine Steuerlogik 260 auf. Die Abbildung aus 3 zeigt ein Blockdiagramm eines Ausführungsbeispiels der Steuerlogik 260. Die Steuerlogik 260 weist einen Schnittstellen-Master 362, eine Auswahlschaltung 364, Register 366 und einen Impulsformer 368 auf. Der Schnittstellen-Master 362 in jedem Agenten führt eine Arbitrierung bezüglich der Herrschaft der Hub-Schnittstelle durch. Die Aktivierung des Signals RQA 254 oder des Signals RQB 255 stellt ein Arbitrierungsereignis dar.
  • Bei jedem Arbitrierungsereignis überprüft die Arbitrierungseinheit 362 in den Upstream- und Downstream-Agenten sowohl das Signal RQA 254 als auch das Signal RQB 255 und bestimmt die Herrschaft über die Hub-Schnittstelle unabhängig und gleichzeitig. Wenn die Schnittstelle ruht, gewinnt der erste der Upstream- und Downstream-Agenten die Herrschaft, der sein Anforderungssignal behauptet (RQA 254 bzw. RQB 255). Wenn die Upstream- und Downstream-Agenten gleichzeitig die Herrschaft anfordern, wenn sich die Hub-Schnittstelle im Ruhezustand befindet, so gewinnt der Hub-Agent die Herrschaft, der zuletzt behandelt worden ist.
  • Die Auswahleinheit 364 empfängt asynchrone Impulse über die Hub-Schnittstelle und überträgt diese Impulse an Schnittstellen-Steuereinheiten 120, die mit anderen Hub-Schnittstellen gekoppelt sind. Zum Beispiel kann ein über die Hub-Schnittstelle A von dem MCH 110 an dem ICH 140 empfangener Impuls über die Hub-Schnittstelle B durch die Auswahleinheit 364 zu der Netzwerkschnittstelle 160 übertragen werden. Gemäß einem Ausführungsbeispiel handelt es sich bei der Auswahleinheit 364 um einen Multiplexer. In anderen Ausführungsbeispielen kann die Auswahleinheit 364 unter Verwendung einer Auswahlschaltkreisanordnung implementiert werden, wie etwa einen Nur-Lesespeicher (ROM als englische Abkürzung von Read Only Memory).
  • Die Register 366 speichern über eine Hub-Schnittstelle an einem Agenten empfangene Daten. In einem Ausführungsbeispiel weisen die Register 366 zwei Reihen bzw. Bänke auf (Bank A und Bank B) mit Signalspeichern bzw. Latches von zweiunddreißig Bit. Die Reihen A und B weisen jeweils ein Flag-Bit auf, das anzeigt, ob sie Daten enthalten. Der Impulsformer 368 empfängt asynchrone Impulse über die Hub-Schnittstelle A. Da die asynchronen Impulse, die durch die Auswahleinheit 364 übertragen werden, zu schmal werden können, erzeugt der Impulsformer 368 den Impuls neu, bevor dieser zu einer folgenden bzw. nachgeschalteten Hub-Schnittstelle übertragen wird. Gemäß einem Ausführungsbeispiel wird der Impulsformer 368 unter Verwendung eines Impulsverstärkers in Agenten implementiert, die eine Brückenfunktion aufweisen (d.h. Agenten, die mit einer Downstream-Hub-Schnittstelle gekoppelt sind). Alternativ kann der Impulsformer 368 unter Verwendung einer asynchronen Logik implementiert werden, wie zum Beispiel von Rücksetz-Setz-Latches. Die Beschreibung der Schnittstellensteuereinheiten 120 und Steuereinheiten 260 ist zwar auf MCH 110 und ICH 140 Agenten, die mit der Hub-Schnittstelle A gekoppelt sind, beschränkt, wobei die vorstehende Beschreibung aber auch für Agenten an anderen Hub-Schnittstellen gilt (z.B. die Schnittstellensteuereinheit 120 an der Hub-Schnittstelle B).
  • In erneutem Bezug auf die Abbildung aus 2 ist der ICH 140 mit einem Taktgenerator 280 gekoppelt. Der Taktgenerator 280 erzeugt synchronisierende Taktimpulse, welche die fundamentale Zeitsteuerung bzw. Taktung und die interne Betriebsfrequenz für Komponenten in dem Computersystem 100 bereitstellen. In einem Ausführungsbeispiel handelt es sich bei dem ICH 140 um einen Taktsteuerungsagenten in dem Computersystem 100, der den Betrieb des Taktgenerators 280 und anderer Synchronisierungsvorrichtungen in dem System 100 steuert.
  • Gemäß einem weiteren Ausführungsbeispiel unterstützen die Hub-Schnittstellen verschiedene Betriebsmodi des Computersystems 100. Zum Beispiel können die Hub-Schnittstellen einen niedrigen Leistungsmodus oder einen hohen Leistungsmodus unterstützen. In dem niedrigen Leistungsmodus werden Datenübertragungen in dem Computersystem 100 mit einem einfachen Vielfachen einer externen Bus- und Taktfrequenz (1x Modus) ausgeführt. In dem hohen Leistungsmodus werden Datentransaktionen in dem Computersystem 100 mit einem vierfachen Vielfachen der externen Bus- und Taktfrequenz (4x Modus) ausgeführt. Die erforderliche Frequenzmultiplikation zum Erreichen des 4x Modus wird implementiert, indem eine analoge Phasenregelschleife (PLL) in jeden Hub-Schnittstellen-Agenten enthalten ist. Alternativ kann eine einzige PLL 4x Modus Impulse an verschiedene Komponenten in dem System 100 bereitstellen.
  • Ein Nachteil des Betriebs der Hub-Schnittstellen in dem 4x Modus ist es, dass eine höhere Leistungsmenge durch das Computersystem 100 verbraucht wird. Obwohl in dem 1x Modus weniger Leistung verbraucht wird, können erhebliche Energiemengen verschwendet werden, wenn eine oder mehrere Hub-Schnittstellen nicht eingesetzt werden, während das System 100 in einem hochgefahrenen Zustand betrieben wird. Dies kann für tragbare Computer besonders nachteilig sein, welche ihre Leistung über Batterien bzw. Akkus erhalten. Um ein Computersystem 100 somit energieeffizienter zu gestalten, arbeiten die Hub-Schnittstellen in einem Modus mit deaktiviertem Takt (Niederleistung). In dem niedrigen Leistungsmodus werden der Systemtakt und die PLL abgeschaltet, und der Schnittstellenbetrieb wird unterbrochen, um den Leistungsverbrauch in dem Computersystem 100 weiter zu reduzieren.
  • Die Abbildung aus 4 zeigt ein Ausführungsbeispiel der Sequenz für die Übertragung aus den 1x oder 4x Modi in den Niederleistungsmodus in dem Computersystem 100. In dem Verfahrensblock 410 bestimmt die CPU 310, dass keine Anforderungen für einen Zugriff auf die Hub-Schnittstelle A ausstehen. In dem Verfahrensblock 420 werde die Schnittstellen-Master 362 deaktiviert, um es zu verhindern, dass ein Zugriff auf die Hub-Schnittstelle A dem MCH 110 oder dem ICH 140 gewährt wird, mit Ausnahme der nachstehend beschriebenen Nachrichten für die Sequenz zum Power Management. In dem Verfahrensblock 430 beginnt der ICH 140 mit der Niederleistungsmodussequenz mit der Geltendmachung bzw. Aktivierung eines Signals, das die CPU 102 in einen heruntergefahrenen Zustand versetzt. Als Reaktion darauf überträgt die CPU 102 ein Quittungs- bzw. Bestätigungssignal, das über die Hub-Schnittstelle A zu dem ICH 140 ausgebreitet wird. In dem Verfahrensblock 440 überträgt der ICH 140 an alle mit dem ICH 140 verbundenen Hub-Schnittstellenagenten, dass der Systemcomputer 100 für den Eintritt in den niedrigen Leistungsmodus bereit ist. Zum Beispiel werden Signale an den MCH 110, die Netzwerkschnittstelle 160 und die Brücke 165 übertragen, die anzeigen, dass bald in den Abschaltmodus eingetreten wird. Ferner übertragen Hub-Schnittstellenagenten, die mit dem ICH 140 gekoppelt sind, die auch mit einem Downstream-Agenten gekoppelt sind, das Niederleistungsmodussignal an den Downstream-Agenten.
  • In dem Verfahrensblock 450 empfängt der ICH 140 Quittungssignale von allen Hub-Schnittstellenagenten, die anzeigen, dass die Agenten für den Eintritt in den Niederleistungsmodus bereit sind. In dem Verfahrensblock 460 hält der ICH 140 den Taktgenerator 280 an. Ferner werden alle PLLs der Agenten angehalten, wenn das System 100 in dem 4x Modus arbeitet oder in einem anderen Modus, der eine PLL erfordert (z.B. ein 8x Modus). Gemäß einem Ausführungsbeispiel werden der Taktgenerator 280 und die PLLs durch die Torsteuerung der entsprechenden Ausgänge angehalten. In dem Verfahrensblock 470 treten alle Hub-Schnittstellenagenten in den Niederleistungsmodus ein. Das Computersystem 100 behält den Niederleistungsmodus bei, bis der ICH 140 eine Anforderung empfängt, die es anzeigt, dass ein Verlassen des Niederleistungsmodus erforderlich ist.
  • Die Abbildung aus 5 zeigt ein Flussdiagramm eines Ausführungsbeispiels der Operationen für den Übergang des Computersystems 100 aus einem Niederleistungsmodus in einen 1x Modus. In dem Verfahrensblock 510 wird ein asynchrones Signal über ein Signal RQA 254 an dem ICH 140 empfangen. Da sich das System 100 in dem Niederleistungsmodus befindet, interpretiert der ICH 140 das empfangene asynchrone Signal als Anzeichen für eine Notwendigkeit zum Verlassen des Niederleistungsmodus. Der MCH 110 kann zum Beispiel das asynchrone Signal an den ICH 140 übertragen, wenn für die Grafikschnittstelle 113 ein Zugriff auf dem Hauptspeicher 115 erforderlich ist. In anderen Ausführungsbeispielen kann ein asynchrones Signal zu dem MCH 110 übertragen werden, wenn der Agent den Niederleistungsmodus verlassen muss. Das Signal wird in der Folge über den MCH 110 an den ICH 140 übertragen.
  • In dem Verfahrensblock 520 überträgt der ICH 140 das asynchrone Signal an andere Hub-Agenten in dem System 100 über das Signal RQB 255 auf jedem Hub-Schnittstellen-Bus. Nach dem Empfang des Signals von dem MCH 110 leitet der ICH 140 zum Beispiel das Signal über die entsprechenden Hub-Schnittstellenbusse B bzw. C an die Netzwerkschnittstelle 160 und die Brücke 165 weiter. Die asynchronen Signale können an dem Impulsformer 368 neu erzeugt werden, bevor sie über die Auswahleinrichtung 364 zu den anderen Hub-Agenten übertragen werden. In dem Verfahrensblock 530 gibt der ICH 140 den Taktgenerator 280 frei. In dem Verfahrensblock 540 gibt der ICH 140 die CPU 102 durch Deaktivierung des Signals frei, das die CPU 102 in der Abschaltfolge abgeschaltet hat. In dem Verfahrensblock 50 beginnen alle Hub-Schnittstellenagenten mit dem Betrieb in dem 1x Modus.
  • Die Abbildung aus 6 zeigt ein Flussdiagramm für ein Ausführungsbeispiel der Operationen für den Übergang des Computersystems 100 aus einem Niederleistungsmodus in einen 4x Modus. In dem Verfahrensblock 605 tritt ein auslösendes Ereignis ein, das es erforderlich macht, dass das Computersystem 100 aufwacht (z.B. ein Benutzer drückt auf eine Taste einer Tastatur in dem Computersystem 100). In dem Verfahrensblock 610 wird ein asynchrones Signal als das Signal RQA 254 an dem ICH 140 empfangen. In dem Verfahrensblock 620 überträgt der ICH 140 das asynchrone Signal an andere Hub-Agenten in dem System 100 als ein Signal RQA 254 auf jedem Hub-Schnittstellenbus.
  • In dem Verfahrensblock 630 gibt der ICH 140 den Taktgenerator 280 frei. Darüber hinaus werden die PLLs in jedem Hub-Agenten freigegeben. Da jeder Agent eine eigene PLL aufweist, kann eine Synchronisierung der PLLs auf jeder Seite einer Hub-Schnittstelle erforderlich sein. Somit überträgt in dem Verfahrensblock 640 der Upstream-Agent nach dem Aufwachen an jeder Hub-Schnittstelle ein kleines Datenpaket über den Datenpfad 251 zu dem Downstream-Agent. Aufgrund der Verzögerung zwischen dem Zeitpunkt, zu dem ICH 140 den Taktgenerator 280 und die PLLs freigibt und dem Zeitpunkt der tatsächlichen Aktivierung wird das Datenpaket zu den Downstream-Agenten getaktet, und zwar durch die STROBE-Signale 258 unter Verwendung von quellensynchronen Datenübertragungen. Das Datenpaket wird in den Downstream-Agenten in dem Register A der Register 366 gespeichert. Der Downstream-Agent kann nach dem Empfang des Datenpakets aufwachen oder nicht aufwachen, da die Takte eventuell noch nicht aktiviert worden sind.
  • Nach dem Aufwachen überprüft ein Downstream-Agent das Register A, um zu bestätigen, ob das Flag-Bit in dem Register A gesetzt ist, wodurch angezeigt wird, dass das Datenpaket empfangen worden ist. Wenn die Daten empfangen worden sind, überträgt der Downstream-Agent ein Quittungssignal an den Upstream-Agenten, Verfahrensblock 650. Wenn die Daten hingegen noch nicht empfangen worden sind, so ist der Downstream-Agent zuerst aufgewacht und muss auf den Empfang der Daten warten. Nachdem die Daten empfangen worden sind, überträgt der Downstream-Agent in dem Verfahrensblock 650 ein Quittungssignal zu dem Upstream-Agenten. Foglich weiß jeder Agent, wann der andere wach und bereit für den Betrieb in dem 4x Modus ist. In dem Verfahrensblock 560 gibt der ICH 140 die CPU 102 frei, indem das Signal deaktiviert wird, das die CPU 102 in der Abschaltfolge abgeschaltet hat. In dem Verfahrensblock 670 beginnen alle Hub-Schnittstellenagenten mit dem Betrieb in dem 4x Modus.
  • In erneutem Bezug auf die Abbildung aus 2 stellen die Hub-Agenten eine zentrale Verbindung zwischen zwei oder mehr separaten Bussen und/oder andersartigen Kommunikationsleitungen bereit. Durch den Einsatz der Hub-Schnittstelle, um den MCH 110 und den ICH 140 miteinander zu verbinden, wird ein verbesserter Zugriff zwischen den E/A-Komponenten und dem CPU/Speicherteilsystem bereitgestellt (z.B. erhöhte Bandbreite, Protokollunabhängigkeit und niedrigere Latenz). Darüber hinaus kann die Hub-Schnittstelle auch die Skalierbarkeit eines Computersystems verbessern (z.B. das Upgrading von einer Basis-Desktopplattform auf Highend-Desktopplattformen oder eine Workstation-Plattform), indem ein Backbone für die E/A-Bausteinblöcke bereitzustellen.
  • Zur Bereitstellung einer verbesserten Schnittstelle weist die Hub-Schnittstelle ein oder mehrere einzigartige Merkmale auf. In einem Ausführungsbeispiel werden Transaktionen über die Hub-Schnittstelle unter Verwendung eines Split Transaction Protokolls auf Paketbasis übertragen. Zum Beispiel wird ein Anforderungspaket für den Beginn einer Transaktion eingesetzt, und ein separates Vollendungspaket kann in der Folge zum Abschluss einer Transaktion eingesetzt werden, sofern dies erforderlich ist.
  • Die Abbildung aus 7 veranschaulicht ein Beispiel für eine Split Transaktion über die Hub-Schnittstelle. Wie dies in der Abbildung aus 7 veranschaulicht ist, gewinnt ein Hub-Agent anfänglich durch Arbitrierung 702 die Herrschaft über die Hub-Schnittstelle. Nach der Arbitrierung folgt eine Anforderungsphase 704. Bei Bedarf (z.B. im Falle der Rückgabe von Daten für eine Lesetransaktion) folgt auf die Anforderungsphase eine Vollendungs- bzw. Abschlussphase 708. Vor der Abschlussphase führt der ansprechende Hub-Agent jedoch eine Arbitrierung 706 um die Herrschaft der Hub-Schnittstelle durch.
  • Zwischen dem Zeitpunkt der Übertragung eines Anforderungspakets und eines entsprechenden Abschlusspakets über die Hub-Schnittstelle können verschiedene, nicht im Verhältnis zueinander stehende Pakete gemäß vorbestimmten Sortierregeln über die Hub-Schnittstelle übertragen werden, wie dies nachstehend im Text näher beschrieben ist. Zum Beispiel kann im Falle einer Leseanforderung von einem Peripheriegerät an den Speicher die Bereitstellung der angeforderten Daten mehrere Taktzyklen in Anspruch nehmen, bis die Daten für die Rückgabe in einem Abschlusspaket bereit stehen. Während dem Zeitraum, der erforderlich ist, um die angeforderten Daten zu erhalten, können separate, zueinander nicht im Verhältnis stehende Abschluss- und/oder Anforderungspakete, die in einer Warteschlange/Pipeline des MCH 110 warten, zu dem ICH 140 übertragen werden.
  • Ferner wird gemäß der Abbildung aus 7 jede Anforderung oder jeder Abschluss als ein Paket über die Schnittstelle übertragen. Bei Schreibtransaktionen sind Daten der Anforderung zugeordnet. Bei Lesetransaktionen sind Daten dem Abschluss bzw. der Vollendung zugeordnet. In einigen Fällen gibt es mehr als einen Abschluss für eine Anforderung, wenn das Abschlusspaket getrennt bzw. gelöst ist, wobei es effektiv in mehrere Abschlusspakete aufgeteilt wird.
  • In einem Ausführungsbeispiel verwendet die Hub-Schnittstelle darüber hinaus Transaktionsdeskriptoren zum Leiten des Verkehrs an der Hub-Schnittstelle sowie zum Identifizieren der Attribute einer Transaktion. Die Deskriptoren können zum Beispiel zum Definieren einer Transaktion als isochron oder asynchron verwendet werden, die danach folglich gemäß einem vordefinierten Protokoll behandelt werden kann.
  • In einem Ausführungsbeispiel wird die Bandbreite der Schnittstelle ferner teilweise durch das Übertragen der Datenpakete über einen quellensynchronen Taktmodus erhöht. In einem Ausführungsbeispiel stellt die Hub-Schnittstelle ferner eine höhere Bandbreite bereit, trotz des Einsatzes einer schmalen Verbindung (z.B. weniger Stifte/Anschlussflächen).
  • In alternativen Ausführungsbeispielen kann hingegen eine Hub-Schnittstelle mit weniger als allen der vorstehend beschriebenen einzigartigen Merkmale implementiert werden, ohne dabei vom Umfang der Erfindung abzuweichen. Ferner kann die Hub-Schnittstelle auch dazu eingesetzt werden, Brücken und/oder andere Komponenten in einem Chipsatz oder außerhalb eines Chipsatzes miteinander zu verbinden, ohne dabei vom Umfang der vorliegenden Erfindung abzuweichen.
  • TRANSAKTIONS-, PROTOKOLL- UND PHYSIKALISCHE SCHICHTEN
  • Zur besseren Veranschaulichung wird die Hub-Schnittstelle in drei Teilen beschreiben: einer Transaktionsschicht, einer Protokollschicht und einer physikalischen schicht. Die Unterscheidungen zwischen den Schichten dienen jedoch der Veranschaulichung und schränken nicht ein, und somit soll kein spezielles bevorzugtes Ausführungsbeispiel nahe gelegt werden.
  • TRANSAKTIONSSCHICHT
  • In einem Ausführungsbeispiel der Hub-Schnittstelle unterstützt die Transaktionsschicht das Leiten separater Transaktionen, die über die Hub-Schnittstelle übertragen werden (die aus einem oder mehreren Paketen bestehen kann). In einem Ausführungsbeispiel erzeugt die Transaktionsschicht der Hub-Schnittstelle zum Beispiel Transaktionsdeskriptoren, die in den Anforderungs- und Datenpaketen enthalten sind. Die Transaktionsdeskriptoren können zur Unterstützung der Arbitrierung zwischen Warteschlagen in einem Hub-Agent (z.B. MCH) eingesetzt werden und/oder zum Erleichtern des Leitens von Anforderungen und Datenpaketen durch die Hub-Schnittstelle.
  • In einem Ausführungsbeispiel unterstützen die Transaktionsdeskriptoren zum Beispiel das Leiten von Abschlusspaketen zurück zu dem die Anforderung einleitenden Agenten auf der Basis anfänglich bereitgestellter (in einem Anforderungspaket) Routing-Informationen. Die Transaktionsdeskriptoren unterstützen ferner die Reduzierung oder Minimieren unter Umständen die Paketdecodierungslogik in den Hub-Agenten.
  • In alternativen Ausführungsbeispielen sehen die Transaktionsdeskriptoren ferner die Fähigkeit zur Unterscheidung der Behandlung von Anforderungen auf der Basis ihrer entsprechenden Transaktionsattribute vor. Die in den Transaktionsdeskriptoren identifizierten Transaktionsattribute können Operationen zum Beispiel als isochron identifizieren (d.h. Operationen, die feste Datenmengen regelmäßig bewegen, wie z.B. Video- oder Audio-Echtzeit-Operationen). Folglich können die durch die Transaktionsattribute identifizierten Operationen gemäß einem entsprechenden vorbestimmten Routing- Protokoll behandelt werden, um eine bestimmte Art der Operation zu unterstützen (z.B. isochron).
  • In einem Ausführungsbeispiel weisen die Transaktionsdeskriptoren zwei Felder auf: ein Routing-Feld und ein Attributfeld. In alternativen Ausführungsbeispielen können mehr oder weniger Felder eingesetzt werden, um eine oder mehrere Funktionen der Transaktionsdeskriptoren bereitzustellen, ohne dabei vom Umfang der Erfindung abzuweichen.
  • In einem Ausführungsbeispiel handelt es sich bei dem Routing-Feld um ein Feld mit sechs Bit zum Routing von Paketen, wie dies nachstehend in Tabelle 1 abgebildet ist. Die Größe des Routing-Felds sowie des Attributfelds kann gemäß dem Umfang der Erfindung variieren.
  • Tabelle 1: Routing-Feld des Transaktionsdeskriptors
    Figure 00190001
  • Wie dies in Tabelle 1 dargestellt ist, werden drei Bit des Routing-Felds für die Hub ID verwendet, welche den Hub-Agenten identifiziert, der die Transaktion eingeleitet hat. In alternativen Ausführungsbeispielen können für die Bereitstellung einer Hub-Schnittstellenhierarchie, die 8 überschreitet, weitere Bits in dem Routing-Feld verwendet werden können.
  • Zum Beispiel können in einem System mehrere Hub-Schnittstellenhierarchien existieren, wobei in diesem Fall der Agent am oberen Ende der Hierarchien in der Lage sein sollte, Vollendungen bzw. Abschlüsse zurück zu der Basis der Hierarchie zu leiten. In diesem Zusammenhang umfasst „Hierarchie" mehrere verbundene Hub-Schnittstellensegmente, beginnend von einem Hub-Schnittstellen-„Root"-Agenten (z.B. einem MCH). Zum Beispiel kann das Computersystem 100 nur eine einzige Hub-Schnittstellenhierarchie aufweisen. Die Abbildung aus 1 veranschaulicht hingegen ein Beispiel für das Computersystem 100 auf der Basis mehrerer Hub-Schnittstellenhierarchien. In Ausführungsbeispielen, die nur eine Hub-Schnittstellenhierarchie implementieren, kann ein Standardwert von „000" in dem Hub ID-Feld verwendet werden.
  • Die verbleibenden drei Bit des Routing-Felds können zum Identifizieren interner Pipes/Warteschlangen in einem Hub-Schnittstellenagenten eingesetzt werden. Zum Beispiel kann der E/A-Steuer-Hub Verkehr auf einem internen USB-Host-Controller (USB als englische Abkürzung von Universal Serial Bus) und Bus Matering ID-Verkehr bzw. BM-ID-Verkehr über separte „Pipes" bzw. Leitungen unterstützen. Die Pipe ID kann dazu eingesetzt werden, mit dem Behandlungsagenten (z.B. MCH) kommunizieren, dass durch verschiedene „Pipes" initiierter Verkehr verschiedene Attribute aufweist und gemäß einem vorbestimmten Protokoll behandelt werden kann. Wenn ein Hub-Schnittstellenagent keine separaten internen Pipes bzw. Leitungen implementiert, so kann er einen Standardwar von „000" in dem Pipe ID-Feld verwenden.
  • In einem alternativen Ausführungsbeispiel weisen die Transaktionsdeskriptoren ferner ein Attributfeld auf. In einem Ausführungsbeispiel stellt das Attributfeld einen Wert von drei Bit dar, der spezifiziert, wie eine Transaktion behandelt werden soll, wenn sie von einem Ziel-Hub-Schnittstellenagenten empfangen wird. In einigen Fällen unterstützt das Attributfeld ein System bei der Unterstützung anspruchsvoller Anwendungsarbeitslasten, die auf der Bewegung und Verarbeitung von Daten mit bestimmten Anforderungen bzw. Voraussetzungen basiert oder auf anderen unterscheidenden Merkmalen bzw. Eigenschaften.
  • Zum Beispiel kann das Attributfeld die isochrone Datenbewegung zwischen Vorrichtungen unterstützen, wie diese von einigen wenigen in letzter Zeit entwickelten externen Bussen eingesetzt wird. Derartige Datenbewegungsanforderungen müssen beibehalten werden, wenn Daten zwischen E/A-Vorrichtungen und dem CPU/Speicherteilsystem durch die Hub-Schnittstelle fließen.
  • In alternativen Ausführungsbeispielen können weitere Transaktionsattribute die Fähigkeit zur Unterscheidung zwischen „abgehörtem" Verkehr, bei dem die Cache-Kohärenz durch Hardware (d.h. einen Chipsatz) durchgesetzt wird, und „nicht abgehörtem" Verkehr, der auf Softwaremechanismen basiert, um die Datenkohärenz in dem System zu gewährleisten. Ferner stellt ein „ausdrücklich vorab erfassbarer" Hinweis ein weiteres mögliches Attribut dar, um eine Form des Lese-Cachings zu bilden und um eine effizientere Nutzung der Hauptspeicherbandbreite zu ermöglichen.
  • Sortierregeln
  • Die Transaktionsdeskriptoren können auch zur Unterstützung der Sortierregeln zwischen über die Hub-Schnittstelle übertragenen Transaktionen verwendet werden. In einem Ausführungsbeispiel werden zum Beispiel Transaktionen mit identischen Transaktionsdeskriptoren in starker Reihenfolge ausgeführt (d.h. First come, First serve).
  • Transaktionen mit dem gleichen Routing-Feld jedoch mit unterschiedlichen Attributfeldern können jedoch im Verhältnis zueinander neu angeordnet werden. In einem Ausführungsbeispiel müssen isochrone Transaktionen zum Beispiel im Verhältnis zu asynchronen Transaktionen nicht stark sortiert bzw. angeordnet werden.
  • In einem Ausführungsbeispiel der Hub-Schnittstelle können Datenübertragungen darüber hinaus über Anforderungen entweder in die gleiche Richtung oder in die entgegengesetzte Richtung fortschreiten. In eine Richtung fließende Leseabschlüsse können Leseanforderungen passieren, die in die gleiche Richtung verlaufen. Und Schreibanforderungen können Leseanforderungen passieren, die in die gleiche Richtung strömen.
  • In alternativen Ausführungsbeispielen können auch die Sortier- oder Anordnungsregeln für über die Hub-Schnittstelle verlaufende Transaktionen innerhalb des Umfangs der Erfindung variieren. In einem Ausführungsbeispiel implementiert die Hub-Schnittstelle zum Beispiel die durch Peripheral Component Interconnect (PCI) (Revision 2.2) bereitgestellten Sortierungsregeln für die Bestimmung des Verkehrsflusses über die Hub-Schnittstelle in entgegengesetzte Richtungen.
  • PROTOKOLLSCHICHT
  • In einem Ausführungsbeispiel verwendet die Hub-Schnittstelle ein Protokoll auf Paketbasis mit zwei Arten von Paketen: Anforderung und Vollendung bzw. Abschluss. Ein Anforderungspaket wird für jede Hub-Schnittstellentransaktion verwendet. Abschlusspakete werden bei Bedarf eingesetzt, um zum Beispiel Lesedaten zurückzugeben oder um die Erfüllung bestimmter Arten von Schreibtransaktionen zu quittieren (z.B. E/A-Schreibtransaktionen und Speicherschreibtransaktionen mit angefordertem Abschluss). Abschlusspakete sind ihren entsprechenden Anforderungspaketen über Transaktionsdeskriptoren und Sortierung bzw. Anordnung zugeordnet, wie dies bereits vorstehend im Text in Bezug auf die Transaktionsschicht beschrieben worden ist.
  • Darüber hinaus verwendet die Hub-Schnittstelle in einem Ausführungsbeispiel ein Arbitrierungsprotokoll, das symmetrisch und verteilt ist. Zum Beispiel steuert jeder Hub-Agent ein Anforderungssignal, das von dem anderen Agenten beobachtet wird, der an der gleichen Schnittstelle angebracht ist. Ein Einräumungssignal wird nicht verwendet, und Agenten bestimmen die Herrschaft der Schnittstelle unabhängig.
  • In einem Ausführungsbeispiel wird ferner kein ausdrückliches Framing-Signal eingesetzt. Es existiert ein impliziertes Verhältnis zwischen dem Arbitrierungsereignis, das einem Agenten die Herrschaft über die Schnittstelle verleiht, und dem Beginn der Übermittlung seitens des Agenten. In einem alternativen Ausführungsbeispiel können Framing- bzw. Rahmensignale eingesetzt werden, ohne dabei vom Umfang der Erfindung abzuweichen.
  • Das Ende der Paketübertragung erfolgt, wenn ein Hub-Schnittstellenagent, der die Herrschaft über die Schnittstelle besitzt (z.B. gerade Daten überträgt) seine Steuerung der Schnittstelle aufgibt, indem ein Anforderungssignal deaktiviert wird. In einem Ausführungsbeispiel wird die Ablaufsteuerung ferner durch den Einsatz eines Signals STOP erreicht, um Pakete erneut zu versuchen oder zu trennen, wie dies nachstehend im Text näher beschrieben ist.
  • Paketdefinition
  • In einem Ausführungsbeispiel der Hub-Schnittstelle werden Daten mit einer Mehrfachrate (z.B. 1x, 4x, 8x) des Hub-Schnittstellentakts (HLCK) übertragen, bei dem es sich in einem Ausführungsbeispiel um einen gemeinsamen Takt handelt, den die durch die Hub-Schnittstelle verbundenen Hub-Agenten gemeinsam nutzen. Die Daten werden über einen Datensignalpfad (PD) der Hub-Schnittstelle übertragen, der eine „Schnittstellenbreite" einer bestimmten Zweierpotenz aufweist (z.B. 8, 16, 24, 32). Folglich kann die Hub-Schnittstelle unterschiedliche Datenübertragungsgranulitäten (d.h. Übertragungsbreiten) aufweisen, abhängig von der Übertragungsrate und der Breite des Datensignalpfads. Zum Beispiel für eine Schnittstellenbreite von acht Bit in dem 4x Modus entspricht die Übertragungsbreite 32 Bit je HLCK. Durch Veränderung der Übertragungsrate und/oder der Schnittstellenbreite des Datensignalpfads kann folglich die Übertragungsbreite (d.h. die Anzahl der je HLCK übertragenen Byte) skaliert werden.
  • In einem Ausführungsbeispiel können Pakete ferner größer sein als die Übertragungsbreiten. Folglich werden die Pakete in mehreren Abschnitten (d.h. Paketbreiten) übertragen. In einem Ausführungsbeispiel werden die Pakete in Paketbreiten mit der Größe von Doppelwörtern (32 Bit) aufgeteilt.
  • Bei einer Übertragungsbreite von 32 Bit werden die Bytes einer Paketbreite an der Schnittstelle beginnend mit dem wertniedrigsten Byte (Byte 0) und abschließend mit dem werthöchsten Byte (Byte 3) dargestellt, wie dies in der folgenden Tabelle 2 dargestellt ist. Bei einer Übertragungsbreite von 64 Bit (z.B. eine Schnittstelle, die im 4x Modus eine Breite von sechzehn Bit aufweist) wird das wertniedrigste Doppelwort (Paketbreite) auf den unteren Bytes des Datensignals übertragen (z.B. PD[0:7]), und das werthöhere Doppelwort wird parallel auf den oberen Bytes des Datensignals übertragen (z.B. PD[15:8]). Die beiden Beispiele sind nachstehend in Tabelle 2 dargestellt.
  • Tabelle 2: Anordnung der Byte-Übertragung vor Schnittstellenbreiten von 8 und 16 Bit
    Figure 00250001
  • Die Protokollschicht der Hub-Schnittstelle ist auch für das Framing bzw. Einrahmen der Daten verantwortlich. Dabei definieren die durch die Hub-Schnittstelle implementierten Framing-Regeln wie eine oder mehrere Paketbreiten auf eine Reihe von Übertragungsbreiten abgebildet werden. Zur Vereinfachung des Parsing der Pakete in Paketbreiten werden in einem Ausführungsbeispiel der Hub-Schnittstelle die folgenden drei Framing-Regeln implementiert: ein Header-Abschnitt eines Pakets beginnt an dem ersten Byte einer Übertragungsbreite ein Datenabschnitt eines Pakets (falls vorhanden) beginnt an dem ersten Byte einer Übertragungsbreite; und ein Paket belegt eine integrale Zahl von Übertragungsbreiten.
  • Alle verfügbaren Übertragungsbreiten, die nicht von einem Paket verbraucht werden, können mit einer unechten Doppelwort-Übertragung (DW als Abkürzung von Doppelwort) gefüllt werden, und sie werden von dem empfangenden Hub-Agenten ignoriert. In alternativen Ausführungsbeispielen können mehr, weniger und/oder sich unterscheidende Framing-Regeln von der Hub-Schnittstelle gemäß dem Umfang der vorliegenden Erfindung eingesetzt werden.
  • Die folgenden Tabellen 3 und 4 veranschaulichen Beispiele für die vorstehend aufgeführten Framing-Regeln für den Fall einer Übertragungsbreite von 64 Bit:
  • Tabelle 3: Anforderung unter Verwendung einer 32-Bit-Adressierung und mit drei Daten-Doppelwörtern
    Figure 00260001
  • Tabelle 4: Anforderung unter Verwendung einer 64-Bit-Adressierung und mit drei Daten-Doppelwörtern
    Figure 00260002
  • Anforderungspakete
  • Das Paket-Headerformat für Anforderungspakete gemäß einem Ausführungsbeispiel ist in den nachstehenden Tabellen 5 und 6 dargestellt. In den Beispielen aus den Tabellen 5 und 6 entspricht der Basis-Header einem Doppelwort, wobei für eine 32-Bit-Adressierung ein zusätzliches Doppelwort erforderlich ist, und wobei zwei zusätzliche Doppelwörter für den 64-Bit-Adressierungsmodus erforderlich sind. Die Felder der Header gemäß den Abbildungen der Tabellen 5 und 6 sind unter den Tabellen beschrieben.
  • In alternativen Ausführungsbeispielen der Hub-Schnittstelle können die Felder in dem Header des Anforderungspakets variieren, ohne dabei vom Umfang der Erfindung abzuweichen. Der Header kann zum Beispiel ein zusätzliches Feld, weniger Felder oder andere Felder an Stelle der nachstehend abgebildeten Felder aufweisen. Ferner kann auch die Codierung der Felder variieren, ohne dabei vom Umfang der Erfindung abzuweichen.
  • Tabelle 5: Format des Headers des Anforderungspakets für eine 32-Bit-Adressierung
    Figure 00270001
  • Tabelle 6: Format des Headers des Anforderungspakets für eine 64-Bit-Adressierung
    Figure 00270002
  • Transaktionsdeskriptor
  • Die Felder Transaktionsdeskriptor-Routing und Attribut gemäß der vorstehenden Beschreibung
  • rq/cp
  • Anforderungspakete sind mit einer „0" identifiziert und Abschlusspakete an dieser Stelle mit einer „1".
  • cr
  • Abschluss erforderlich („1") oder kein Abschluss erforderlich („0")
  • r/w
  • Lesen („0") oder Schreiben („1"). Dieses Feld zeigt an, ob Daten in einem Abschluss (Lesen) oder einer Anforderung (Schreiben) enthalten sind.
  • Adressformat (af)
  • Das Adressierungsformat ist entweder impliziert („0") oder 32/64 Bit („1").
  • Lock (lk)
  • Flag bzw. Flagge zum Anzeigen, dass eine Anforderung Teil einer gesperrten bzw. verriegelten Folge ist. Anforderungen und Abschlüsse in einer verriegelten Folge weisen dieses Bit als gesetzt auf. Hub-Agenten, die Verriegelungen nicht verstehen, ignorieren diese Flagge und füllen das Feld mit einer „0" aus.
  • Datenlänge
  • Die Datenlänge ist in Doppelwörtern gegeben, die so codiert sind, dass die dargestellte Anzahl der Doppelwörter dieser Anzahl plus eins entspricht. Somit stellt „000000" ein Doppelwort dar.
  • Raum
  • Das Feld wählt die Art des Zielraums für die Anforderung aus. In einem Ausführungsbeispiel zählen zu den möglichen Zielräumen Speicher („00") und EA („01").
  • 1. DW BF
  • Bytefreigaben für das erste Doppelwort für jede Lese- oder Schreibanforderung an Speicher oder EA. Bytefreigaben sind aktiv niedrig. Wenn nur ein Doppelwort für eine Anforderung gegeben ist, wird dieses Bytefreigabefeld verwendet. In einem Ausführungsbeispiel ist es unzulässig, eine Speicher- oder EA-Lese- oder Schreibanforderung auszugeben, wenn keine Bytes freigegeben sind.
  • Letztes DW BF
  • Bytefreigaben für das letzte Doppelwort jeder Lese- oder Schreibanforderung. Bytefreigaben sind aktiv niedrig. Wenn nur ein Doppelwort für eine Anforderung gegeben ist, muss dieses Feld inaktiv sein („1111"). Bytefreigaben können unterbrochen sein (z.B. „0101"). Dieses Feld wird nie mit speziellen Zyklen verwendet, da es das Feld „Besondere Zykluscodierung" überschneidet.
  • Adr.[31:2]
  • Die 32-Bit-Adresse wird erzeugt, als befände sie sich an PCI für die gleiche Art von Zyklus. Dieses Doppelwort ist für die 32- und 64-Bit-Adressiermodi enthalten (jedoch nicht für den implizierten Adressierungsmodus).
  • Erweiterte Adresse (ea)
  • Zeigt eine 32-Bit-Adressierung („0") oder eine 64-Bit-Adressierung („1") an.
  • Konfig.typ (ct)
  • Nur für Konfigurationszyklen wird dieses Bit zum Anzeigen des Konfigurationszyklustyps Typ 0 („0") oder Typ 1 („1") verwendet. Da Konfigurationszyklen immer mit einer 32-Bit-Adressierung ausgeführt werden, wird dieses Bit durch das Bit „Erweiterte Adresse" überlappt.
  • Adr.[63:32]
  • Obere Adressbits für den 64-Bit-Adressierungsnsodus. Dieses Doppelwort ist für den 64-Bit-Adressierungsmodus enthalten.
  • Abschlusspakete
  • Das Header-Format für ein Abschlusspaket ist gemäß einem Ausführungsbeispiel nachstehend in Tabelle 7 dargestellt. In einem Ausführungsbeispiel handelt es sich bei dem Header um ein Doppelwort. Die Felder der Header gemäß der Darstellung in Tabelle 8 sind nach der Tabelle beschrieben.
  • In alternativen Ausführungsbeispielen der Hub-Schnittstelle können die in dem Header für ein Abschlusspaket enthaltenen Felder jedoch variieren, ohne dabei vom Umfang der Erfindung abzuweichen. Der Header kann zum Beispiel ein zusätzliches Feld, weniger Felder oder andere Felder an Stelle der nachstehend beschriebenen und dargestellten Felder aufweisen. Ferner kann auch die Codierung der Felder variieren, ohne dabei vom Umfang der Erfindung abzuweichen.
  • Tabelle 7: Header-Format des Abschlusspakets
    Figure 00300001
  • Transaktionsdeskriptor
  • Die Felder Transaktionsdeskriptor-Routing und Attribut gemäß der vorstehenden Beschreibung in dem Transaktionsabschnitt.
  • rq/cp
  • Abschlusspakete sind an dieser Stelle mit einer „1" identifiziert.
  • r/w
  • Lesen („0") oder Schreiben („1"). Dieses Feld zeigt an, ob Daten in einem Abschluss (Lesen) oder einer Anforderung (Schreiben) enthalten sind.
  • Lock (lk)
  • Flag bzw. Flagge zum Anzeigen, dass ein Abschluss Teil einer gesperrten bzw. verriegelten Folge ist. Anforderungen und Abschlüsse in einer verriegelten Folge weisen dieses Bit als gesetzt auf. Agenten, die Verriegelungen nicht verstehen, ignorieren diese Flagge und füllen das Feld mit einer „0" aus.
  • Datenlänge
  • Die Datenlänge ist in Doppelwörtern gegeben, die so codiert sind, dass die dargestellte Anzahl der Doppelwörter dieser Anzahl plus eins entspricht. Somit stellt „00000" ein Doppelwort dar.
  • Abschlussstatus
  • Zeigt einen Abschlussstatus unter Verwendung vorbestimmter Daten an.
  • Reserviert
  • Alle reservierten Bits sind auf „0" gesetzt.
  • In einem Ausführungsbeispiel der Hub-Schnittstelle können Abschlüsse von Speicherlesevorgängen weniger als die ganze Menge der angeforderten Daten bereitstellen, sofern die ganze Anforderung letztlich abgeschlossen wird. In ähnlicher Weise können Abschlüsse für Speicherschreibvorgänge anzeigen, dass weniger als die ganze Anforderung abgeschlossen bzw. vollendet worden ist. Dies kann vorgenommen werden, um eine bestimmte Latenzanforderung einer Hub-Schnittstelle für eine bestimmte Plattform zu erfüllen.
  • Für eine Anforderung, die einen Abschluss bzw. eine vollständige Ausführung erfordert, erhält darüber hinaus in einem Ausführungsbeispiel der Initiator Informationen zu der Anforderung, die in einem Puffer des einleitenden Hub-Agenten gespeichert werden können. Diese Informationen können zum Beispiel den Transaktionsdeskriptor, die Größe des Pakets, den Verriegelungsstatus, Routing-Informationen, etc. aufweisen. Beim Empfang des Abschlusses bzw. der Abschlüsse passt der Initiator ferner den Abschluss bzw. die Abschlüsse an die entsprechende Anforderung an. Im Falle von mehreren Abschlüssen sammelt der Initiator eine Zählwert der abgeschlossenen Daten für die ursprüngliche Anforderung, bis die ursprüngliche Anforderung vollständig ausgeführt ist.
  • Schnittstellen-Arbitrierung und Paket-Framing
  • Wenn die Schnittstelle in einem Ausführungsbeispiel der Hub-Schnittstelle im Ruhezustand weilt, wird die Geltendmachung bzw. Behauptung einer Anforderung von einem mit der Schnittstelle verbundenen Hub-Agenten als ein Arbitrierungsereignis angesehen. Der erste Agent, der eine Anforderung abgibt, erlangt die Herrschaft über die Schnittstelle. Wenn Agenten gleichzeitig die Herrschaft anfordern, wenn sich die Hub-Schnittstelle im Ruhezustand befindet, so gewinnt der zuletzt behandelte Hub-Agent die Herrschaft. In einem Ausführungsbeispiel verfolgen alle Hub-Agenten den zuletzt behandelten Status (z.B. über eine Statusflagge eines internen Registers). In einem alternativen Ausführungsbeispiel können gemäß dem Umfang der vorliegenden Erfindung alternative Arbitrierungsroutinen eingesetzt werden.
  • Nachdem ein Hub-Agent die Herrschaft über die Schnittstelle erlangt hat, behält er die Herrschaft über die Schnittstelle, bis er die Transaktion abgeschlossen hat oder bis eine zugeordnete Zeitbandbreite abgelaufen ist. In einem Ausführungsbeispiel ist zum Beispiel ein Zeitscheibenzähler in jedem Hub-Agenten bereitgestellt, um die Bandbreitenzuweisung zu steuern und um die Dauer der Herrschaft des Agenten über die Schnittstelle einzuschränken. Die einem Hub-Agenten zugeteilte Zeit (d.h. ein Zeitscheibenwert) kann für an der gleichen Schnittstelle angebrachte Hub-Schnittstellenagenten unterschiedlich oder identisch sein. Der Zeitscheibenzähler startet nach der Erlangung der Herrschaft über die Schnittstelle und zählt Hub-Schnittstellen-Basistaktperioden.
  • In einem Ausführungsbeispiel ist jeder Hub-Agent für die Verwaltung seiner eigenen Zeitscheibenzuordnung zuständig. In einem Ausführungsbeispiel kann ein entsprechender Zeitscheibenwert über ein Hub-Schnittstellen-Befehlsregeister für jede Schnittstelle in jedem Hub-Agenten programmiert werden.
  • Die Abbildung aus 8 veranschaulicht ein Beispiel für die Arbitrierung der Hub-Schnittstelle zwischen dem Hub-Agenten A und dem Agenten B und die Übertragung von zwei Paketen. Das Beispiel veranschaulicht die Arbitrierung aus einem ruhenden Schnittstellenzustand, wobei die Schnittstelle danach in den Ruhezustand zurückkehrt. In dem veranschaulichten Beispiel verwendet die Schnittstelle ferner einen 4x Datenübertragungsmodus mit einem Datensignalpfad (PD) von acht Bit. In dem in der Abbildung aus 8 veranschaulichten Beispiel ist der Agent A der zuletzt behandelte (MRS) Agent. Folglich aktiviert der Agent A sein externes Anforderungssignal (RQA) und tastet den Zustand des Anforderungssignal de Agenten B (RQB) an der Taktflanke 1 ab (die inaktiv dargestellt ist), bevor die Paketübertragung von der gleichen Flanke beginnt.
  • In einem Ausführungsbeispiel gibt es eine Verzögerung von zwei takten bevor die übertragenen Daten (d.h. die Daten von dem Agent A) in dem Empfänger zur Verfügung (d.h. Agent B) stehen, beginnend ab der Taktflanke 3. Das erste Paket besteht aus zwei Doppelwörtern 802 und 804 und erfordert zwei Basistakte für die Übertragung in dem 4x Modus. Das zweite Paket stellt drei Doppelwörter 806, 808 und 810 dar, und es erfordert drei Basistakte in dem 4x Modus.
  • Ablaufsteuerung
  • In einem Ausführungsbeispiel können Pakete durch einen empfangenden Agenten erneut versucht oder getrennt werden, und zwar aufgrund des Fehlens eines Anforderungswarteschlangenraums, eines Datenpufferraums oder aus einem anderen Grund. In einem Ausführungsbeispiel wird die Ablaufsteuerung unter Verwendung eines Signals STOP erreicht.
  • Die Abbildung aus 9 veranschaulicht ein Beispiel für den Einsatz des Signals STOP. Gemäß der Veranschaulichung aktiviert der Agent A sein externes Anforderungssignal (RQA) und tastet den Zustand des Anforderungssignals des Agenten B (RQB) an der Taktflanke 1 ab (die inaktiv dargestellt ist), bevor die Übertragung des Pakets von der gleichen Flanke beginnt (z.B. Taktflanke 1).
  • Nach einer Verzögerung um zwei Takte stehen die von Agent A übertragenen Daten intern in dem Empfänger an Agent B zur Verfügung, beginnend von Taktflanke 3. In einem Ausführungsbeispiel nach dem Empfang der von dem Agent A übertragenen Daten existiert die erste Möglichkeit für Agent B zur Erlangung der Ablaufsteuerung durch Aktivierung des Signals STOP auf Taktflanke 4, wie dies in der Abbildung aus 9 dargestellt ist.
  • Wenn ferner die Herrschaft des PD-Signals von einem Hub-Agenten auf einen anderen wechselt, wird auch die Herrschaft über das Signal STOP ausgetauscht, und zwar nach einer vorbestimmten Anzahl von Takten. In einem Ausführungsbeispiel wird das Signal STOP ferner auf Basistakten abgetastet, die der finalen Übertragung einer Paketbreite entsprechen. In einem 4x Modus (unter Verwendung eines PD-Signals mit einer Breite von acht Bit) wird das Signal STOP zum Beispiel bei jedem Basistakt abgetastet. In einem 1x Modus wird das Signal STOP hingegen bei jedem vierten Takt abgetastet (wobei der Anfang einer Transaktion als Bezugspunkt verwendet wird).
  • nach dem Empfang eines Signals STOP bestimmt der Hub-Agent, der das Signal STOP empfängt, ob das Übertragen zusätzlicher Pakete erneut versucht werden soll. Die Abbildung aus 10 zeigt ein Flussdiagramm der Schritte, die ein Hub-Agent ausführt, wenn bestimmt wird, ob dieser das Senden eines Pakets erneut versuchen soll, nachdem ein Signal STOP empfangen worden ist, gemäß einem Ausführungsbeispiel der Erfindung.
  • In dem Schritt 1002 empfängt ein aktuell Pakete übertragender Hub-Agent ein Signal STOP. Als Reaktion darauf bestimmt der Hub-Agent, der das STOP Signal empfängt, in dem Schritt 1004, ob der andere Agent (der das STOP Signal aktiviert hat) die Herrschaft der Schnittstelle anfordert, indem das Anforderungssignal der anderen Hub-Agenten abgetastet wird (z.B. RQB).
  • Wenn der Empfänger des Signals STOP bestimmt, dass der Agent, der das Signal STOP übermittelt hat, keine Herrschaft über die Schnittstelle anfordert, kann der aktuelle Eigentümer der Schnittstelle in dem Schritt 1006 versuchen, nach der Erholung von dem STOP ein Paket zu übertragen. Wenn andererseits bestimmt wird, dass der Agent, der das Signal STOP aktiviert hat, die Herrschaft anfordert, bestimmt der aktuelle Eigentümer in dem Schritt 1008, ob die Zeitscheibe abgelaufen ist.
  • Wenn die Zeitscheibe für den aktuellen Eigentümer der Schnittstelle abgelaufen ist, gibt der aktuelle Eigentümer in dem Schritt 1010 die Herrschaft auf. Wenn die Zeitscheibe für den aktuellen Eigentümer nicht abgelaufen ist, kann der aktuelle Eigentümer ein Paket mit einem Attribut übertragen, das sich von dem unterbrochenen Paket unterscheidet. Im Besonderen bestimmt der aktuelle Eigentümer in dem Schritt 1012, ob dieser ein Paket mit einem Attibuttyp aufweist, der sich von dem anderer Pakete unterscheidet, die in der vorliegenden Arbitrierungssitzung erneut versucht worden sind (d.h. die Verweildauer des aktuellen Eigentümers), die übertragen werden muss.
  • Wenn der aktuelle Eigentümer ein Paket mit einem anderen Attribut aufweist, kann der aktuelle Eigentümer in dem Schritt 1014 versuchen, das Paket zu übertragen. Ansonsten gibt der aktuelle Eigentümer die Herrschaft über die Schnittstelle frei.
  • PHYSIKALISCHE SCHNITTSTELLE
  • In einem Ausführungsbeispiel implementiert die Hub-Schnittstelle eine physikalische Schnittstelle, die auf einer Grundfrequenz von entweder 66 MHz oder 100 MHz arbeitet. Andere Frequenzen können ebenfalls verwendet werden. In einem Ausführungsbeispiel verwendet die physikalische Schnittstelle ferner eine quellensynchrone (SS) Datenübertragungstechnik, die eine Quadtaktung bzw. Vierfachtaktung für die Datenübertragung auf dem 4X des Grundtaktes der Hub-Schnittstelle aufweisen kann. In einem Ausführungsbeispiel mit einer 8-Bit-Datenschnittstelle (z.B. PD), die auf einer Grundfrequenz von 66 MHz oder 100 MHz arbeitet, kann somit eine entsprechende Bandbreite von 266 Megabyte pro Sekunde (MB/Sek.) bzw. 400 MB/Sek. erreicht werden.
  • In einem Ausführungsbeispiel unterstützt die Hub-Schnittstelle ferner einen Spannungsbetrieb von 1,8 Volt und basiert auf einer CMOS-Signalgebung. In alternativen Ausführungsbeispielen kann die Schnittstelle hingegen auf alternative Frequenzen arbeiten und/oder Datenschnittstellen mit alternativen Größen können eingesetzt werden, um variable Bandbreiten bereitzustellen sowie um alternative Betriebsspannungen zu unterstützen, auf der Basis einer alternativen Signalverarbeitung, ohne dabei vom Umfang der vorliegenden Erfindung abzuweichen.
  • Externe Signaldefinition
  • Die Abbildung aus 11 veranschaulicht die physikalische Signalschnittstelle der Hub-Schnittstelle zwischen zwei Agenten gemäß einem Ausführungsbeispiel. Wie dies in der Abbildung aus 11 dargestellt ist, verwendet die physikalische Schnittstelle der Hub-Schnittstelle einen bidirektionalen Datenbus von acht Bit (PD[7:0]) mit einem differentiellen Paar von quellensynchronen Strobe-Signalen (PSTRBN, PSTRBP) für die Datentaktung. In einem alternativen Ausführungsbeispiel kann die Schnittstelle breiter gestaltet werden. Wie dies in der Abbildung aus 11 dargestellt ist, kann zum Beispiel ein zusätzlicher Datenbus von acht Bit (PD[15:8]) in verbindung mit einem zusätzlichen Paar von quellensynchronen Strobe-Signalen (PUSTRBN, PUSTRBP) verwendet werden. In einem alternativen Ausführungsbeispiel können ferner unidirektionale Datensignale verwendet werden.
  • Darüber hinaus verbindet ein unidirektionales Arbitrierungssignal jeden Agenten mit dem anderen (RQA, RQB), und ein bidirektionales STOP-Signal wird von dem empfangenden Agenten dazu verwendet, den Datenfluss zu steuern, wie dies bereits vorstehend im Text beschrieben worden ist. Zusätzliche Schnittstellensignale weisen ein Systemzurücksetzungssignal (Reset), einen gemeinsames Taktsignal (HLCLK) und Spannungsreferenzsignale (HLVREF) auf. Ebenfalls enthalten sind Signale für jeden Hub-Agenten (ZCOMP) zur Anpassung dessen Treiberausgangsimpedanz mit dem entsprechenden Wert zur Kompensation für Fertigungs- und Temperaturschwankungen.
  • Die in der Schnittstelle aus 11 dargestellten physikalischen Signale sind in der nachstehenden Tabelle 8 näher beschrieben. In alternativen Ausführungsbeispielen der Hub-Schnittstelle können die Signale in der physikalischen Schnittstelle schwanken, ohne dabei vom Umfang der vorliegenden Erfindung abzuweichen. Zum Beispiel kann die physikalische Schnittstelle mehr, weniger oder andere Signale aufweisen, die von den Signalen aus der Abbildung aus 11 abweichen, und in der Abbildung aus 8 näher beschrieben sind.
  • Tabelle 8: Hub-Schnittstellensignale für 8-Bit-Agenten
    Figure 00380001
  • Figure 00390001
  • Figure 00400001
    • 1ASTS = Aktiv erhaltener Tri-State.
    • 2SS = Quellensynchrones Modulsignal.
    • 3CC = Gemeinsames Taktmodussignal.
    • 4In einem Ausführungsbeispiel stellt Reset ein systemweites Signal dar; es wird von einer Komponente des Systems ausgegeben und in eine oder mehrere andere Komponente(n) eingegeben. Ferner ist Reset asynchron in Bezug auf HLCLK.
  • Betrieb im gemeinsamen Taktübertragungsmodus
  • In einem Ausführungsbeispiel werden viele der über die Hub-Schnittstelle übertragenen Signale gemäß einem gemeinsamen Taktmodus übertragen. Im Besonderen erfolgt eine Referenz der Zeitsteuerung der Signale, die über den gemeinsamen Taktmodus übertragen werden, mit einem einzelnen Takt (z.B. dem Takt der Hub-Schnittstelle). In alternativen Ausführungsbeispielen können die Signale mit dem Systemtakt verbunden sein, außerhalb der Hub-Schnittstellenagenten. Ferner können mehr als ein Hub-Schnittstellensegment in einem System enthalten sein, wobei in diesem Fall verschiedene Basistakte für die verschiedenen Segmente verwendet werden können. Zum Beispiel kann eine Komponente sowohl eine Basis-Hub-Schnittstelle von 66 MHz als auch eine Basis-Hub-Schnittstelle von 100 MHz implementieren.
  • Betrieb im quellensynchronen Übertragungsmodus
  • In einem Ausführungsbeispiel werden Pakete/Daten unter Verwendung eines quellensynchronen Taktmodus übertragen, der eine Technik zur Multiplikation der Datenübertragungsrate der Daten bereitstellt. In einem Ausführungsbeispiel unter Verwendung eines 4X quellensynchronen Taktmodus mit einem Datensignalpfad von acht Bit erfordert die Übertragung eines Doppelwortes (d.h. vier Byte) zum Beispiel nur einen Hub-Schnittstellen-Taktzyklus (HLCK). Alternativ würde die Übertragung eines Doppelwortes unter Verwendung eines 1X quellensynchronen Taktmodus auf einem Datensignalpfad von acht Bit für die vollständige Ausführung einen vollständigen Taktzyklus der Hub-Schnittstelle erfordern.
  • Im Besonderen werden in einem Ausführungsbeispiel der quellensynchronen Übertragung Strobes (z.B. PSTRBN/PSTRBP) mit einer Datenübertragung gemäß einem vorbestimmten Taktverhältnis zwischen den Strobes und den Daten übermittelt. Die Strobes werden danach zum Speichern der Daten in dem empfangenden Hub-Agent verwendet.
  • Im Besonderen werden in einem Ausführungsbeispiel die Flanken der Strobes PSTRBP/PSTRBN von dem empfangenden Hub-Agenten verwendet, um das Vorhandensein und die Zeitsteuerung der über die Datensignalpfade übertragenen Daten verwendet. Wie dies zum Beispiel in dem Zeitsteuerungsdiagramm aus 12 veranschaulicht ist, entspricht in einem Ausführungsbeispiel eine erste Datenübertragung der ansteigenden Flanke von PSTRBP und der abfallenden Flanke von PSTRBN. Eine zweite Datenübertragung entspricht der ansteigenden Flanke von PSTRBN und der abfallenden Flanke von PSTRBP.
  • Wie dies ferner in der Abbildung aus 12 dargestellt ist, sind in einem Ausführungsbeispiel ferner die Sendeflanken der Strobes PSTRBP/PSTRBN nahe der Mitte des gültigen Datenfensters positioniert. Folglich erhält der empfangende Agent ein Eingangsdaten-Abtastfenster zur Berücksichtigung verschiedener Systemtaktschrägläufe. In einem Ausführungsbeispiel werden ferner ein Minimum für gültige Daten vor der Strobe-Flanke (tDvb) und ein Minimum für gültige Daten nach der Strobe-Flanke (tDva) ebenfalls durch den empfangenden Hub-Agenten verwendet, um die übertragenen Daten zu identifizieren und zwischenzuspeichern. Nachdem der empfangende Hub-Agent die eingehenden Daten zwischengespeichert hat, werden die Daten für eine kurze Dauer gespeichert, um die Daten mit dem Hub-Schnittstellentakt (HLCK) neu zu synchronisieren, bevor sie gemeinsam mit dem Hub-Agenten übertragen werden.
  • Für einen Durchschnittsfachmann auf dem Gebiet werden sicher zahlreiche Abänderungen und Modifikationen der vorliegenden Erfindung nach dem Lesen der vorstehenden Beschreibung deutlich, so dass hiermit festgestellt wird, dass jedes der speziellen dargestellten und beschriebenen Ausführungsbeispiele zu Veranschaulichungszwecken keine einschränkende Funktion besitzt. Somit schränken Einzelheiten der verschiedenen Ausführungsbeispiele nicht den Umfang der Ansprüche ein, welche die Merkmale definieren, die als die Erfindung gelten.

Claims (18)

  1. Verfahren zur Reduzierung des Leistungsverbrauchs eines Computersystems (100) mit einer ersten Hub-Schnittstellenarchitektur, welche folgendes umfasst: Hub-Schnittstellen (A, B, C) zur Verbindung von Hauptbausteinen der Kernlogik des Computersystems, eine Zentraleinheit (102) und erste und zweite Hub-Agenten (140, 110), die mit der ersten Hub-Schnittstelle (A) gekoppelt sind, wobei die ersten und zweiten Hub-Agenten Schnittstellen-Master (362) aufweisen, die so angeordnet sind, dass sie das Eigentum an der ersten Hub-Schnittstelle (A) arbitrieren, wobei das Verfahren folgendes umfasst: das Arbeiten in einem ersten Leistungszustand; das Deaktivieren (420) der Schnittstellen-Master (362) innerhalb der ersten und zweiten Hub-Agenten (140, 110) nach dem Detektieren (410), dass keine Anforderungen für den Zugriff auf die erste Hub-Schnittstelle (A) ausstehen; das Übergehen (470) in einen zweiten Leistungszustand, um den Leistungsverbrauch des Computersystems zu reduzieren, indem die Zentraleinheit (102) in einen Zustand mit geringerer Leistungsaufnahme versetzt wird; und das Torsteuern (460) eines mit dem ersten Hub-Agenten (140) gekoppelten Taktgenerators (280).
  2. Verfahren nach Anspruch 1, wobei das Verfahren ferner folgendes umfasst: das Übermitteln (440) einer Anzeige an einen dritten Hub-Agenten (160, 165), dass das Computersystem (100) in einen zweiten Leistungszustand übergeht (470); und das Empfangen (450) eines Quittungssignals von dem dritten Hub-Agenten (160, 165) durch den ersten Hub-Agenten (140).
  3. Verfahren nach Anspruch 2, wobei das Verfahren ferner folgendes umfasst: das Empfangen (510) eines asynchronen Signals (254) an dem ersten Hub-Agenten (140), wodurch angezeigt wird, dass das Computersystem (100) zurück in den ersten Leistungszustand übergeht; das Aufheben der Torsteuerung (530) des Taktgenerators (280); das Versetzen der CPU (102) in einen hohen Leistungszustand; und das Übergehen (550) in den ersten Leistungszustand.
  4. Verfahren nach Anspruch 3, wobei das Verfahren des Empfangens des asynchronen Signals (254) folgendes umfasst: das Empfangen des asynchronen Signals an dem ersten Hub-Agenten (140) von dem dritten Hub-Agenten (160, 165) über eine zweite Hub-Schnittstelle (B, C); und das Übermitteln des asynchronen Signals von dem ersten Hub-Agenten (140) zu dem zweiten Hub-Agenten (110).
  5. Verfahren nach Anspruch 1, wobei das Verfahren ferner das Anhalten von Phasenregelschleifen (PLLs) innerhalb der ersten, zweiten und dritten Hub-Agenten (140, 110, 160, 165) umfasst.
  6. Verfahren nach Anspruch 5, wobei das Verfahren ferner folgendes umfasst: das Empfangen (610) eines asynchronen Signals von dem ersten Hub-Agenten (140), wodurch angezeigt wird, dass das Computersystem (100) wieder zurück in den ersten Leistungszustand übergeht; das Aufheben der Torsteuerung (630) des Taktgenerators; das Aufheben der Torsteuerung (630) der PLLs in den ersten und zweiten Hub-Agenten; das Versetzen (660) der CPU in einen hohen Leistungszustand; und das Übergehen (670) in den ersten Leistungszustand.
  7. Verfahren nach Anspruch 6, wobei das Verfahren ferner folgendes umfasst: das Übermitteln eines Datenpakets von dem zweiten Hub-Agenten (110) an den ersten Hub-Agenten über die erste Hub-Schnittstelle (A), nachdem der Taktgenerator (280) und die PLLs gestartet worden sind; und das Übermitteln eines Quittungssignals von dem ersten Hub-Agenten (140) an den zweiten Hub-Agenten (110).
  8. Verfahren nach Anspruch 7, wobei das Verfahren ferner folgendes umfasst: das Übermitteln eines Datenpakets von dem ersten Hub-Agenten (140) an einen dritten Hub-Agenten (160, 165) über eine zweite Hub-Schnittstelle (B, C); und das Übermitteln eines Quittungssignals von dem dritten Hub-Agenten (160, 165) an den ersten Hub-Agenten (140).
  9. Computersystem (100), das folgendes umfasst: eine Zentraleinheit (CPU) (107); eine erste Hub-Schnittstelle (A) zur Verbindung von Hauptbausteinen einer Kernlogik des Computersystems, die mit ersten und zweiten Hub-Agenten (140) gekoppelt ist, wobei die ersten und zweiten Hub-Agenten Schnittstellen-Master (362) aufweisen, die so angeordnet sind, dass sie das Eigentum an der ersten Hub-Schnittstelle (A) arbitrieren, dadurch gekennzeichnet, dass das Computersystem (100) so angeordnet ist, dass es aus einem ersten Leistungszustand in einen zweiten Leistungszustand übergeht, um den Leistungsverbrauch des Computersystems zu reduzieren, nachdem die CPU bestimmt hat, dass keine Anforderungen für einen Zugriff auf die erste Hub-Schnittstelle (A) ausstehen; wobei: die Schnittstellen-Master (362) in den ersten und zweiten Hub-Agenten (140, 110) deaktiviert (420) werden, nachdem detektiert (410) worden ist, dass keine Anforderungen für einen Zugriff auf die erste Hub-Schnittstelle (A) ausstehen; die Zentraleinheit (CPU) (102) in einen niedrigen Leistungszustand versetzt (430) wird; und wobei ein Taktgenerator (280), der mit dem ersten Hub-Agenten (140) gekoppelt ist, torgesteuert (460) wird.
  10. Computersystem nach Anspruch 9, wobei der erste Hub-Agent (140) folgendes umfasst: eine Schnittstellensteuereinheit (120); und einen Phasenregelkreis (PLL).
  11. Computersystem nach Anspruch 10, wobei die Schnittstellensteuereinheit (120) folgendes umfasst: einen Schnittstellen-Master (362); eine Auswahlschaltkreisanordnung (364); eine Registerreihe (366); und einen Impulsformer (368).
  12. Computersystem nach Anspruch 11, wobei dieses ferner einen Taktgenerator (280) umfasst, der mit dem ersten Hub-Agenten (140) gekoppelt ist, wobei der Schnittstellen-Master (362), die CPU (102) und der Taktgenerator (280) deaktiviert werden, nachdem detektiert worden ist, dass keine Anforderungen für einen Zugriff auf die erste Hub-Schnittstelle ausstehen.
  13. Computersystem nach Anspruch 9, wobei das System ferner einen zweiten Hub-Agenten (110) umfasst, der mit der ersten Hub-Schnittstelle (A) gekoppelt ist, wobei der erste Hub-Agent (140) an den zweiten Hub-Agenten (110) übermittelt, dass das Computersystem aus dem ersten Leistungszustand in den zweiten Leistungszustand übergeht.
  14. Computersystem nach Anspruch 13, wobei das System ferner folgendes umfasst: eine zweite Hub-Schnittstelle (B, C), die mit dem ersten Hub-Agenten (140) gekoppelt ist; und einen dritten Hub-Agenten (160, 165), der mit der zweiten Hub-Schnittstelle (B, C) gekoppelt ist, wobei der erste Hub-Agent (140) über die zweite Hub-Schnittstelle (B, C) an den dritten Hub-Agenten (160, 165) übermittelt, dass das Computersystem (100) aus dem ersten Leistungszustand in den zweiten Leistungszustand übergeht.
  15. Computersystem nach Anspruch 13, wobei das Computersystem aus dem zweiten Leistungszustand in den ersten Leistungszustand übergeht, nachdem der zweite Hub-Agent (110) ein asynchrones Signal von dem ersten Hub-Agenten (140) empfangen hat.
  16. Computersystem nach Anspruch 14, wobei das Computersystem aus dem zweiten Leistungszustand in den ersten Leistungszustand übergeht, nachdem der zweite Hub-Agent (110) ein asynchrones Signal von dem dritten Hub-Agenten (160, 165) empfangen hat.
  17. Computersystem nach Anspruch 12, wobei es sich bei dem zweiten Hub-Agenten (110) um einen Memory Control Hub (MCH) handelt, und wobei es sich bei dem ersten Hub-Agenten (140) um einen Input/Output Control Hub (ICH) handelt.
  18. Computersystem nach Anspruch 9, wobei der erste Hub-Agent (140) immer dann einen asynchronen Impuls an den zweiten Hub-Agent (110) übermittelt, wenn die ersten und zweiten Hub- Agenten wieder zurück in den ersten Leistungszustand übergehen.
DE60028992T 1999-10-07 2000-09-26 Leistungssteuerungsverfahren für ein rechnersystem mit einer knotenpunktarchitektur Expired - Lifetime DE60028992T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US414999 1995-03-31
US09/414,999 US6480965B1 (en) 1999-10-07 1999-10-07 Power management method for a computer system having a hub interface architecture
PCT/US2000/040998 WO2001025886A2 (en) 1999-10-07 2000-09-26 Power management method for a computer system having a hub interface architecture

Publications (2)

Publication Number Publication Date
DE60028992D1 DE60028992D1 (de) 2006-08-03
DE60028992T2 true DE60028992T2 (de) 2007-02-01

Family

ID=23643929

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60028992T Expired - Lifetime DE60028992T2 (de) 1999-10-07 2000-09-26 Leistungssteuerungsverfahren für ein rechnersystem mit einer knotenpunktarchitektur

Country Status (8)

Country Link
US (1) US6480965B1 (de)
EP (1) EP1222516B1 (de)
AT (1) ATE331245T1 (de)
AU (1) AU1962401A (de)
DE (1) DE60028992T2 (de)
HK (1) HK1045201B (de)
TW (1) TW476026B (de)
WO (1) WO2001025886A2 (de)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7039047B1 (en) 1999-11-03 2006-05-02 Intel Corporation Virtual wire signaling
US6633987B2 (en) * 2000-03-24 2003-10-14 Intel Corporation Method and apparatus to implement the ACPI(advanced configuration and power interface) C3 state in a RDRAM based system
US7099318B2 (en) * 2001-12-28 2006-08-29 Intel Corporation Communicating message request transaction types between agents in a computer system using multiple message groups
US7114038B2 (en) * 2001-12-28 2006-09-26 Intel Corporation Method and apparatus for communicating between integrated circuits in a low power mode
US7469350B2 (en) * 2005-12-22 2008-12-23 Ncr Corporation Power control interface for a self-service apparatus
US8566628B2 (en) * 2009-05-06 2013-10-22 Advanced Micro Devices, Inc. North-bridge to south-bridge protocol for placing processor in low power state
US20110112798A1 (en) * 2009-11-06 2011-05-12 Alexander Branover Controlling performance/power by frequency control of the responding node
EP2391056B1 (de) * 2010-05-26 2013-08-21 Samsung Electronics Co., Ltd. Medienspieler und Verfahren zur Rückholung aus dem Ruhemodus
US8438416B2 (en) * 2010-10-21 2013-05-07 Advanced Micro Devices, Inc. Function based dynamic power control
RU2617549C2 (ru) * 2011-07-06 2017-04-25 Телефонактиеболагет Л М Эрикссон(Пабл) Способ управления обменами транзакциями между двумя интегральными схемами

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5687388A (en) 1992-12-08 1997-11-11 Compaq Computer Corporation Scalable tree structured high speed input/output subsystem architecture
US5675813A (en) 1995-10-26 1997-10-07 Microsoft Corporation System and method for power control in a universal serial bus
US5799196A (en) 1996-07-02 1998-08-25 Gateway 2000, Inc. Method and apparatus of providing power management using a self-powered universal serial bus (USB) device
KR100218003B1 (ko) * 1997-04-22 1999-09-01 윤종용 Usb 허브 전원을 이용한 디스플레이 장치의 전원 제어장치 및 제어방법
US6151262A (en) * 1998-10-28 2000-11-21 Texas Instruments Incorporated Apparatus, system and method for control of speed of operation and power consumption of a memory
US6141283A (en) * 1999-04-01 2000-10-31 Intel Corporation Method and apparatus for dynamically placing portions of a memory in a reduced power consumption state

Also Published As

Publication number Publication date
AU1962401A (en) 2001-05-10
TW476026B (en) 2002-02-11
US6480965B1 (en) 2002-11-12
EP1222516B1 (de) 2006-06-21
WO2001025886A2 (en) 2001-04-12
DE60028992D1 (de) 2006-08-03
ATE331245T1 (de) 2006-07-15
WO2001025886A3 (en) 2002-02-14
WO2001025886A9 (en) 2002-08-01
HK1045201A1 (en) 2002-11-15
HK1045201B (zh) 2006-11-10
EP1222516A2 (de) 2002-07-17

Similar Documents

Publication Publication Date Title
DE60013470T2 (de) Gerät zur initialisierung einer rechnerschnittstelle
DE69936060T2 (de) Verfahren und Vorrichtung für eine verbesserte Schnittstelle zwischen Computerkomponenten
DE60037036T2 (de) Vier-gepumpte busarchitektur-/protokoll
DE69832410T2 (de) Pipeline-kommunikationssystem mit fester latenz-zeit unter verwendung von dynamischer echtzeit-bandbreitenzuweisung
DE69322248T2 (de) Reservierung, die den normalen vorrang von mikroprozessoren in multiprozessorrechnersystemen annulliert
DE3889366T2 (de) Interface für ein Rechnersystem mit reduziertem Befehlssatz.
DE69322310T2 (de) Busarchitektur für integrierten Daten/- und Videospeicher
DE19900369B4 (de) Vorrichtung zum Anschluß an einen Universal Serial Bus (USB) und Verfahren zum Betreiben eines Steuerendpunktes an einem Universal Serial Bus (USB)
DE69836437T2 (de) Speichersystem mit speichermodul mit einem speichermodul-steuerbaustein
DE69733857T2 (de) Steuerungsübertragungsbus für Netzwerkgeräte
DE69032783T2 (de) CPU-Bussteuerschaltung
DE3752205T2 (de) Multiprozessor-Busprotokoll
DE69108434T2 (de) Mehrgruppen-Signalprozessor.
DE19982854B4 (de) Verfahren und Einrichtung zum Minimieren von Leerlaufbedingungen eines asynchronen Sendefifos und von Überlaufbedingungen eines Empfangsfifos
DE60017774T2 (de) Verfahren und vorrichtung zur unterstützung von mehrtaktübertragung in einem rechnersystem mit einer punkt-zu-punkt halb-duplex verbindung
DE69432401T2 (de) Vorrichtung zur Integrierung von Bus-Master-Besitzrecht von Lokalbuslast
DE4142756A1 (de) Datenweg-einrichtung zur kopplung zweier busse
DE69622830T2 (de) Asynchrone Busbrücke
DE102005009021A1 (de) Vereinheitliche USB OTG-Steuerungseinheit
DE60028992T2 (de) Leistungssteuerungsverfahren für ein rechnersystem mit einer knotenpunktarchitektur
DE69214702T2 (de) Speicherzugriff für die Datenübertragung in einer Ein-Ausgabevorrichtung
DE602004012310T2 (de) Speicherschnittstelle für systeme mit mehreren prozessoren und einem speichersystem
DE69717232T2 (de) Fehlertolerantes Bussystem
DE102018005759A1 (de) Verbinden von beschleunigerressourcen unter verwendung einesswitches
DE60029118T2 (de) Asynchrone zentralisierte multikanal-dma-steuerung

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8328 Change in the person/name/address of the agent

Representative=s name: HEYER, V., DIPL.-PHYS. DR.RER.NAT., PAT.-ANW., 806