DE10085385B3 - Vierfach gepumpte Bus-Architektur und Protokoll - Google Patents

Vierfach gepumpte Bus-Architektur und Protokoll Download PDF

Info

Publication number
DE10085385B3
DE10085385B3 DE10085385T DE10085385T DE10085385B3 DE 10085385 B3 DE10085385 B3 DE 10085385B3 DE 10085385 T DE10085385 T DE 10085385T DE 10085385 T DE10085385 T DE 10085385T DE 10085385 B3 DE10085385 B3 DE 10085385B3
Authority
DE
Germany
Prior art keywords
data
address
bus
signal
subscriber
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE10085385T
Other languages
English (en)
Other versions
DE10085385T1 (de
Inventor
Gurbir Singh
Robert J. Grenier
Stephen S. Pawlowski
David L. Hill
Donald D. Parker
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE10085385T1 publication Critical patent/DE10085385T1/de
Application granted granted Critical
Publication of DE10085385B3 publication Critical patent/DE10085385B3/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38Information transfer, e.g. on bus
    • G06F13/42Bus transfer protocol, e.g. handshake; Synchronisation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38Information transfer, e.g. on bus
    • G06F13/42Bus transfer protocol, e.g. handshake; Synchronisation
    • G06F13/4204Bus transfer protocol, e.g. handshake; Synchronisation on a parallel bus
    • G06F13/4208Bus transfer protocol, e.g. handshake; Synchronisation on a parallel bus being a system bus, e.g. VME bus, Futurebus, Multibus
    • G06F13/4217Bus transfer protocol, e.g. handshake; Synchronisation on a parallel bus being a system bus, e.g. VME bus, Futurebus, Multibus with synchronous protocol

Abstract

Ein bidirektionaler Mehrpunkt-Prozessorbus ist mit einer Vielzahl von Busteilnehmern verbunden. Busdurchsatz kann gesteigert werden, indem der Bus in einem quad-pumped Signalisierungsmodus angesteuert wird, in dem vielfache Informationselemente auf dem Bus durch ein Treiberteilnehmer mit einer Rate angesteuert werden, die ein Vielfaches von der Frequenz von dem Bustakt ist. Der Treiberteilnehmer aktiviert ebenfalls ein Abtastsignal, um Abtastpunkt für die Informationselemente zu bestimmen. Ein Adress-Informationselement für eine Anforderung kann zum Beispiel unter Verwendung eines double-pumped Signalisierungsmodus angesteuert werden, in dem zwei Adress-Informationselemente während eines Bustaktzyklus angesteuert werden. Daten-Informationselemente für eine Datenleitungsübertragung können zum Beispiel unter Verwendung eines quad-pumped Signalisierungsmodus angesteuert werden, in dem vier Daten-Informationselemente während eines Bustaktzyklus angesteuert werden. Vielfache Abtastsignale können in einer versetzten oder gestaffelten Anordnung temporär aktiviert werden, um die Frequenz von den Abtastsignalen zu verringern. Abtastsymmetrie kann unter Verwendung nur eines Flankentyps (zum Beispiel entweder die ansteigenden Flanken oder die fallenden Flanken) von den Abtastsignalen zum Bestimmen der Abtastpunkte verbessert werden.

Description

  • Die Erfindung betrifft Prozessoren und insbesondere eine vierfach gepumpte Bus-Architektur und Protokoll.
  • Mit steigender Komplexität und Anforderungen heutiger Software und Anwendungen ergibt sich eine Nachfrage nach Prozessoren, die gesteigerten Durchsatz und Bandbreite bereitstellen. Es können eine oder mehrere Quellen existieren, die bewirken können, die Computerleistung zu begrenzen, wie zum Beispiel Eingabe/Ausgabe-(I/O)-Geschwindigkeit oder Bandbreite, Speichergröße etc. Eine Quelle, die normalerweise Computerleistung begrenzt oder drosselt, ist die Geschwindigkeit und Bandbreite des Prozessorbusses oder Frontside-Busses, das ist der Bus, der zwischen einem oder mehreren Prozessoren und dem Chipsatz bereitgestellt wird. Einige Pentium-Prozessoren (wie zum Beispiel ein Pentium Pro Prozessor der Intel Corporation) schließen einen 64 Bit Datenbus ein und können 8 Bytes pro Prozessor-Taktzyklus übertragen und können eine 32 Byte Cache-Zeile (Cache Line) in 4 Taktzyklen übertragen. Wenn der Prozessortakt (beispielsweise) mit 100 MHz bereitgestellt wird, würde die Datenübertragungsrate daher 800 MBytes pro Sekunde betragen. Vielfältige Details der Architektur des Pentium Pro Prozessors können in dem ”Pentium Pro Family Developer's Manual, Volume 1: Specifications”, Januar 1996, ISBN 1-55512-259-0 gefunden werden. Während für viele Anwendungen eine Datenübertragungsrate von 800 MBytes pro Sekunde ausreichend ist, besteht ein Bedarf für einen Prozessorbus, der eine verbesserte Datenübertragungsrate oder Bandbreite bereitstellt.
  • Die US 5,919,254 beschreibt zum Beispiel ein Verfahren und eine Vorrichtung zum Übertragen von Daten zwischen Busteilnehmern in einem Computer, der einen mit einem Bustakt betriebenen Bus aufweist. Das Übertragungsverfahren nach US 5,919,254 sieht die Möglichkeit vor, dass eine Transaktionsanforderung von einem anfordernden Teilnehmer die Anzeige einer Vielzahl von Datenbreiten umfasst, die der anfordernden Teilnehmer verarbeiten kann. In Reaktion auf die Transaktionsanforderung wird die Datenübertragung entsprechend einer Datenbreite konfiguriert. Die Datenübertragung auf dem Datenbus kann dabei in Abhängigkeit von der Datenbreite Quell-synchron oder Bus-synchron durchgeführt werden.
  • Die EP 0 579515 A1 beschreibt eine Datenübertragungsverfahren mittels einer asynchrone Busschnittstelle, die einfach oder mehrfach-breite Datenübertragungen durchführen kann. Eine Bustransaktion enthält Adressen/Befehls-Informationen und einzelne oder mehrere aufeinanderfolgende Datenübertragungen, die mittels eines Datenimpulses bewerkstelligt werden, wobei jede Datenübertragung in Abhängigkeit vom Zyklustyp eine andere Laufzeitverzögerung aufweisen kann. Der Zyklustyps einer Übertragung wird aus den Adressen/Befehls-Informationen bestimmt und individuell zeitlich gesteuerte Slave-Datenquittungssignale werden für jede Datenübertragung einer Transaktion als Antwort auf den Datenimpuls und den Zyklustyp asynchron erzeugt.
  • Insbesondere ist es eine Aufgabe der vorliegenden Erfindung, ein Verfahren zur Datenübertragung bereitzustellen, das sicherstellt, dass bei verbesserter Datenübertragungsrate oder Bandbreite für die Übertragung von Dateninformationen über einen Datenbus die Datenübertragungsrate oder Bandbreite für die Übertragung von Adressinformationen nicht limitierend wirkt.
  • Die Aufgabe wird gemäß den in dem Gegenstand der unabhängigen Ansprüche definierten Merkmalen gelöst.
  • Gemäß einem Aspekt der vorliegenden Erfindung wird ein Verfahren zum Übertragen von Informationen über einen Mehrpunkt-Bus von einem Treiberteilnehmer an einen oder mehrere Empfängerteilnehmer bereitgestellt. Ein gemeinsamer Bustakt wird sowohl dem Treiberteilnehmer und dem einen oder mehreren Empfängerteilnehmer bereitgestellt. Eine Bustransaktion wird von dem Treiberteilnehmer an den einen oder die mehreren Empfängerteilnehmer ausgegeben, wobei der Treiberteilnehmer vielfache Informationselemente für eine Anforderung auf einem Adressbus mit einer Rate ansteuert, die ein Vielfaches der Frequenz von dem Bustakt ist, und der Treiberteilnehmer ein erstes Abtastsignal bzw. Strobesignal aktiviert, um zu bestimmen, wann der eine oder die mehreren Empfängerteilnehmer die Adress-Informationselemente abtasten soll, die auf dem Adressbus angesteuert werden. Der Treiberteilnehmer steuert ferner vielfache Daten-Informationselemente zum Übermitteln von Daten an den einen oder die mehreren Empfängerteilnehmer auf einem Datenbus mit einer Rate an, die ein Vielfache der Frequenz von dem Bustakt aber unterschiedlich von der Rate des Adressbusses ist, und der Treiberteilnehmer aktiviert ein zweites Abtastsignal bzw. Strobesignal, um zu bestimmen, wann der eine oder die mehreren Empfängerteilnehmer die Informationselemente abtasten sollen, die auf dem Datenbus angesteuert werden.
  • Weitere Aspekte der vorliegenden Erfindung betreffen eine Vorrichtung und ein System, die angepasst sind, das vorstehend beschriebene Verfahren auszuführen.
  • Das Vorstehende und ein besseres Verständnis der vorliegenden Erfindung wird durch die folgende genauere Beschreibung exemplarischer Ausführungsformen und die Ansprüche ersichtlich werden, wenn sie in Verbindung mit den begleitenden Zeichnungen gelesen werden, die alle einen Teil der Offenbarung dieser Erfindung bilden. Während das Vorstehende und folgend niedergeschriebene und dargestellte Offenbarung sich auf das Offenbaren von beispielhaften Ausführungsformen der Erfindung richtet, soll klar verstanden werden, dass dergleichen nur als illustrativ und beispielhaft und nicht darauf beschränkt zu verstehen ist. Das Wesen und der Schutzbereich der vorliegenden Erfindung sind nur auf die Begriffe der angefügten Ansprüche beschränkt.
  • Das Folgende stellt eine kurze Beschreibung der Zeichnungen dar, wobei:
  • 1 ein Blockdiagramm ist, das einen Computer gemäß einer beispielhaften Ausführungsform der vorliegenden Erfindung darstellt.
  • 2 ist ein Diagramm, das einen Prozessorbus gemäß einer beispielhaften Ausführungsform darstellt.
  • 3 ist ein Zeitabfolge-Diagramm, das beispielhaft Beziehungen für Bustransaktions-Phasen für zwei beispielhafte Transaktionen gemäß einer Ausführungsform darstellt.
  • 4 ist ein beispielhaftes Zeitabfolge-Diagramm, das ein Beispiel für ein Betreiben des Signalisierungsmodus für einen gemeinsamen Takt gemäß einer Ausführungsform darstellt.
  • 5 ist ein Zeitabfolge-Diagramm, das das Betreiben eines Beispiels für einen vierfach gepumpten Signalisierungsmodus gemäß einer Ausführungsform darstellt.
  • 6 ist ein Zeitabfolge-Diagramm, das das Betreiben eines Beispiels für einen zweifach gepumpten Signalisierungsmodus gemäß einer Ausführungsform darstellt
  • 7 ist ein Diagramm, das die minimale Latenzzeit oder Verzögerung zwischen Transaktionsphasen darstellt.
  • 8 ist ein Blockdiagramm einer Vorrichtung zum Übertragen von Informationen zwischen Teilnehmern gemäß einer Ausführungsform.
  • 9 ist ein Blockdiagramm einer Vorrichtung zum Übertragen von Informationen zwischen Teilnehmern gemäß einer anderen Ausführungsform.
  • I. Einleitung
  • Gemäß einer Ausführungsform ist ein Prozessorbus mit einer Vielzahl von Busteilnehmern verbunden. Der Bus ist skalierbar, da einige Signaltypen unter Verwendung eines Signalisierungsmodus für einen gemeinsamen Takt übertragen werden, während andere Signaltypen unter Verwendung eines multi-pumped Signalisierungsmodus übertragen werden.
  • In einem Signalisierungsmodus für einen gemeinsamen Takt können Signal (wie zum Beispiel Taktsignale) auf dem Bus mit einer Rate angesteuert werden, die im Wesentlichen die Gleiche wie die Frequenz eines gemeinsamen Bustakts ist. In diesem Modus bestimmen die Flanken von dem Bustakt Punkte, um die auf dem Bus angesteuerten Signale abzutasten.
  • Der Busdurchsatz kann durch Betreiben des Busses in dem multi-pumped Signalisierungsmodus gesteigert werden, in dem vielfache Informationselemente auf dem Bus durch einen Treiberteilnehmer mit einer Rate angesteuert werden, die ein Vielfaches von der Frequenz von dem Bustakt ist. Der Treiberteilnehmer aktiviert temporär ebenfalls ein Abtastsignal, um Abtastpunkte für die Informationselemente zu bestimmen, die in dem multi-pumped Signalisierungsmodus angesteuert werden. Informationselemente für eine Anforderung können zum Beispiel unter Verwendung eines double-pumped Signalisierungsmodus angesteuert werden, in dem zwei Informationselemente während eines Bustaktzyklus angesteuert werden. Datenelemente für eine Datenleitungsübertragung können zum Beispiel unter Verwendung eines quad-pumped Signalisierungsmodus angesteuert werden, in dem vier Datenelemente während eines Bustaktzyklus angesteuert werden. Vielfache Abtastsignale können temporär in einer versetzten oder gestaffelten Anordnung aktiviert werden, um die Frequenz der Abtastsignale zu verringern. Die Symmetrie der Abtastung kann durch Verwendung nur eines Flankentyps (zum Beispiel entweder die ansteigenden Flanken oder die fallenden Flanken) der Abtastsignale verbessert werden, um die Abtastpunkte zu bestimmen. Zusätzlich können die Latenzzeiten zwischen Transaktionsphasen modifiziert werden, um die maximale Geschwindigkeit des Busses genauer anzupassen, der in dem quad-pumped Signalisierungsmodus arbeitet.
  • II. Architektur
  • 1 ist ein Blockdiagramm, das einen Computer gemäß einer beispielhaften Ausführungsform der vorliegenden Erfindung darstellt. Der Computer umfasst einen oder mehrere Prozessoren, die einen Prozessor 110, einen Prozessor 112 und einen Prozessor 114 umfassen. Jeder Prozessor umfasst ebenfalls einen internen Cache (nicht gezeigt).
  • Jeder Prozessor ist ebenfalls mit dem gemeinsamen Prozessorbus 117 (ebenfalls als der Hostbus oder der Frontside-Bus bekannt) verbunden. 2 ist ein Diagramm, das den Prozessorbus 117 gemäß einer beispielhaften Ausführungsform darstellt. Der Prozessorbus 117 umfasst, wie in 2 gezeigt, einen Steuerbus 202, einen Adressbus 204 und einen Datenbus 206. Gemäß einer Ausführungsform schließt der der 64 Datenleitungen D[63:0] umfassende Datenbus 206 viele Signale ein. Der 36 Adressleitungen A[35:0] umfassende Adressbus 204 schließt ebenfalls viele Signale ein. Der Prozessorbus 117 schließt einen Bustakt (BCLK) ein. Der Bustakt ist ein gemeinsamer und wird allen Teilnehmern über den Steuerbus 202 des Prozessorbusses 117 bereitgestellt. Der Steuerbus 202 schließt ebenfalls viele Signale ein. Der Adressbus 204, der Steuerbus 202 und der Datenbus 206 sind vorzugsweise jeweils bidirektionale Mehrpunkt-Datenbusse. Gemäß einer Ausführungsform bedeutet der Begriff ”Mehrpunkt”, dass die Busse mit drei oder mehr Busteilnehmern verbunden sind, im Gegensatz zu einem Punkt-zu-Punkt Bus, der nur zwischen zwei Busteilnehmern geschaltet ist.
  • Eine Systemschnittstelle 116 (oder Chipsatz) ist ebenfalls mit dem Prozessorbus 117 verbunden, um zahlreiche anderen Komponenten an dem Prozessorbus 117 anzuschließen. Die Systemschnittstelle 116 umfasst eine Speicher-Steuereinheit 118, um ein Hauptspeicher-Subsystem 122 an den Prozessorbus 117 anzuschließen. Das Hauptspeicher-Subsystem 122 umfasst typischerweise eine oder mehrere Speicherkarten und eine Steuerschaltung. Die Systemschnittstelle 116 umfasst ebenfalls eine Eingangs/Ausgangs(I/O)-Steuereinheit 120, um eine oder mehrere I/O-Brücken oder I/O-Vorrichtungen an den Prozessorbus 117 anzuschließen. In diesem in 1 gezeigten beispielhaften Computer umfasst die I/O-Steuereinheit 120 eine I/O-Brücke 124 an den Prozessorbus 117. Die I/O-Brücke 124 arbeitet als eine Busbrücke, um die Systemschnittstelle 116 und einen I/O-Bus anzupassen. Ein oder mehrere I/O-Steuereinheit und I/O-Vorrichtungen können mit dem I/O-Bus 130 verbunden werden, so wie zum Beispiel I/O-Steuereinheit 132 und I/O-Steuereinheit 134. Der I/O-Bus 130 kann ein Peripheral Component Interconnect (PCI) Bus oder ein anderer I/O-Bustyp sein.
  • III. Teilnehmer
  • Busteilnehmer geben Transaktionen auf den Prozessorbus 117 aus, um Daten und Systeminformationen zu übermitteln. Ein Busteilnehmer ist irgendeine Vorrichtung, die mit dem Prozessorbus 117 verbunden ist. Es können verschiedene Busteilnehmer-Klassifikationen vorhanden sein:
    • 1) Zentralteilnehmer: handhabt Rücksetzen, Hardware-Konfiguration und Initialisierung, spezielle Transaktionen und zentrale Hardware-Fehlererfassung und Handhabung. Beispielsweise ein Prozessor.
    • 2) I/O-Teilnehmer: schließt I/O-Vorrichtungen unter Verwendung von I/O-Adressen an. Kann eine Busbrücke an einen anderen für I/O-Vorrichtungen verwendeten Bus sein, wie zum Beispiel eine PCI-Brücke.
    • 3) Speicherteilnehmer: stellt Zugriff auf den Hauptspeicher bereit, wie zum Beispiel der Speicher-Steuereinheit 118.
  • Ein spezieller Busteilnehmer kann eine oder mehrere von verschiedenen Rollen in einer Transaktion aufweisen:
    • 1) Anfordernder (requesting) Teilnehmer: Der Busteilnehmer, der die Transaktion ausgibt.
    • 2) Adressierter Teilnehmer: Der Teilnehmer, der durch die Transaktion adressiert wird. Ebenfalls als Zielteilnehmer bezeichnet. Eine Speicher- oder I/O-Transaktion wird an den Speicher- oder I/O-Teilnehmer adressiert, der die spezifizierte Speicher- oder I/O-Adresse erkennt.
    • 3) Snooping Teilnehmer: Ein zwischenspeichernder Busteilnehmer, der Bustransaktionen überwacht (snoop), um die Cache-Kohärenz aufrechtzuerhalten.
    • 4) Antwortender (responding) Teilnehmer: Das Teilnehmer, der die Antwort auf die Transaktion (typischerweise der adressierte Teilnehmer) bereitstellt. Gemäß einer Ausführungsform steuert der antwortende Teilnehmer die Antwort auf dem Steuerbus unter Verwendung der Antwortabtastsignale RS[2:0] an.
  • IV. Operationen, Transaktionen und Phasen
  • Gemäß einer Ausführungsform ist die Busaktivität auf dem Prozessorbus 117 hierarchisch in Operationen, Transaktionen und Phasen eingeteilt.
  • Eine Operation ist ein Busverfahren, das für Software atomar erscheint (zum Beispiel, erscheint unteilbar zu sein oder erscheint zu einem Zeitpunkt stattzufinden), auch wenn sie nicht atomar auf dem Bus 117 sein kann. Eine Operation kann aus einer einzelnen Bustransaktion bestehen, kann aber manchmal vielfache Bustransaktionen oder eine Bustransaktion mit vielfachen Datenübertragungen einbeziehen. Beispiele schließen eine Leseoperation, eine Schreiboperation, eine gesperrte Lese-Modifizier-Schreib-Operation und zeitversetzte Operationen ein.
  • Eine Transaktion ist ein Satz von Busaktivitäten, die eine einzelne Busanforderung betreffen. Eine Transaktion beginnt mit einer Busarbitrierung und das Aktiv-Setzen des ADS#-Signals (das anzeigt, dass eine Adresse angesteuert werden wird) und einer Transaktionsadresse. Transaktionen werden angesteuert, um zum Beispiel Daten zu übertragen, um Erkundigungen über einen geänderten Cache-Status einzuholen oder um dem System Informationen bereitzustellen.
  • Eine Phase verwendet einen spezifischen Satz von Signalen, um einen speziellen Informationstyp zu übermitteln. Die Phasen können einschließen: Arbitrierung, Request, Snoop (snoop), Request und Daten. Nicht alle Transaktionen beinhalten alle Phasen und einige Phasen können überlappend sein. Die Arbitrierungs-Phase ist, in der die Busteilnehmer bestimmen, wer der nächste Besitzer des Busses sein wird (ein Teilnehmer muss den Bus besitzen, bevor er eine Transaktion ausgibt). Die Request-Phase ist die Phase, in der die Transaktion auf den Bus ausgegeben wird. Die Snoop-Phase ist die Phase, in der für Cache-Kohärenz gesorgt wird. Die Response-Phase ist die Phase, in der der adressierte oder Ziel-Teilnehmer eine Transaktionsantwort auf dem Bus ansteuert. In der Daten-Phase steuert an oder akzeptiert der anfordernde oder antwortende oder snooping Teilnehmer die Transaktionsdaten.
  • Vier Steuersignale, die über den Prozessorbus 117 übertragen werden, schließen einen Bustakt BCLK[1:0], das Initialisierungssignal INIT# und das Rücksetz-Signal RESET# ein. Der Bustakt BCLK[1:0] ist der differentielle Bustakt und kann durch einen Taktchip oder eine Taktschaltung erzeugt werden. Die zwei Bustaktsignale, BCLK[1:0] sind logisch identisch und werden physikalisch als zwei getrennte Signale geführt, um die Zeitverschiebung zu vermindern. Gemäß einer Ausführungsform steuern alle Teilnehmer ihre Ausgaben eines gemeinsamen Takts und speichern ihre Eingaben eines gemeinsamen Takts auf der ansteigenden Flanke von dem Bustakt. Jeder Prozessor steuert seinen internen Takt aus dem Bustakt BCLK-Signal durch Multiplizieren und/oder Dividieren der Bustaktfrequenz mit einer Zahl oder Zahlen.
  • Gemäß einer Ausführungsform setzt das RESET#-Eingangs-Signal alle Teilnehmer in einen bekannten Zustand zurück und invalidiert ihre internen Caches. Modifizierte oder dirty Cache-Zeilen-Inhalte sind verloren. Nachdem RESET# inaktiv gesetzt wird, beginnt jeder Prozessor die Bearbeitung mit einem Einschalt-Rücksetz-Vektor, der während der Konfiguration festgelegt wird.
  • Gemäß einer Ausführungsform setzt das INIT#-Eingabe-Signal alle Prozessoren zurück ohne auf ihre internen Cache oder ihre Fließkomma-Register zu wirken. Jeder Prozessor beginnt die Bearbeitung mit einem Einschalt-Rücksetz-Vektor, der während der Konfiguration festgelegt wird.
  • 3 ist ein Zeitabfolge-Diagramm, das beispielhafte Bustransaktionsphasen-Beziehungen für zwei beispielhafte Transaktionen gemäß einer Ausführungsform darstellt. Die Zyklen (1, 2, 3, 4, ... 17) von dem Bustakt (BCLK[1:0]) sind oben gezeigt. Die Rechtecke mit einer Nummer 1 zeigen verschiedene Phasen für Transaktion 1 an, während die Rechtecke mit einer Nummer 2 Phasen für Transaktion 2 anzeigen. Wie in 3 zu erkennen ist, sind die Transaktionen pipelineartig bereitgestellt. Zum Beispiel tritt für Transaktion 1 die Arbitrierung in Buszyklen 1 und 2 ein, die Anforderung tritt in Zyklen 2 und 3 ein, das Snooping tritt in Zyklen 6 und 7 ein und die Antwort und Datenübertragung tritt in Zyklen 13 und 14 ein. Es kann daher erkannt werden, dass eine Antwort- und Datenübertragung viele Bustaktzyklen nach der ursprünglichen Request-Phase auftreten kann. Ebenfalls kann ein Überlappen von Phasen verschiedener Transaktionen vorkommen. Zum Beispiel tritt die Arbitrierungs-Phase für Transaktion 2 ungefähr zur selben Zeit wie die Request-Phase für Transaktion 1 ein.
  • V. Signalisierungsmodi
  • Gemäß einer Ausführungsform ist der Prozessorbus 117 skalierbar und unterstützt zwei Signalisierungsmodi. Der erste ist ein Signalisierungsmodus für einen gemeinsamen Takt, in dem alle Signalaktivierungs- und Abtast- oder Speicherpunkte gemäß einem gemeinsamen Bustakt (BCLK#) auftreten, der kontinuierlich allen Teilnehmern bereitgestellt wird. Der Bustakt wird typischerweise durch einen Taktchip oder eine Taktschaltung erzeugt, die auf einer Mutterplatine bereitgestellt sind, und gemeinsam für alle Prozessoren oder Teilnehmer in einem Computer sind. Auf Signaltaktung in Bezug auf den gemeinsamen Bustakt wird als Signalisierungsmodus für einen gemeinsamen Takt (1×) Bezug benommen. Gemäß einer Ausführungsform werden viele Steuersignale, die über den Steuerbus bereitgestellt werden, unter Verwendung des Signalisierungsmodus für einen gemeinsamen Takt (1×) übertragen.
  • Ein zweiter Signalisierungsmodus ist ein multi-pumped Signalisierungsmodus, der eine Informations-Übertragungsrate erlaubt, die ein Vielfaches der Übertragungsrate ist, die durch den Signalisierungsmodus für den gemeinsamen Takt unterstützt wird. Gemäß einer Ausführungsform kann daher der multi-pumped Signalisierungsmodus Informationsübertragung über den Prozessorbus 117 zwischen den Teilnehmern mit einer Rate unterstützen, die ein Vielfaches der Frequenz von dem gemeinsamen (d. h. System) Bustakt ist. Zum Beispiel kann der multi-pumped Signalisierungsmodus zum Beispiel einen double-pumped Signalisierungsmodus bereitstellen, der es erlaubt Informationen mit der doppelten (2×) Rate der gemeinsamen Taktfrequenz zu übertragen, oder kann einen quad-pumped Signalisierungsmodus bereitstellen, der für eine Informationsübertragung mit dem Vierfachen (4×) der Bustaktfrequenz sorgt. Um die Übertragung von Informationen mit solchen Raten oder Frequenzen zu erleichtern, die größer sind als der gemeinsame Bustakt, geben die Treiberteilnehmer ein begleitendes Signal aus oder stellen dies zur Verfügung, das als ein Zeitabfolge-”Abtastsignal” bzw. Timing-„Strobe” bekannt ist, das von dem Empfänger als eine Referenz zum Erfassen oder Speichern der multi-pumped Informationen verwendet wird.
  • Der Ausdruck „aktiv setzen” bedeutet, dass ein Signal auf seinem aktiven Pegel angesteuert wird (d. h. für ein aktiv niederpegliges Signal auf Null angesteuert wird), und der Ausdruck „inaktiv setzen” bedeutet, dass das Signal auf seinem inaktiven Pegel angesteuert wird. Die Quadrat-, Kreis- und Dreiecks-Symbole werden in einigen Zeitabfolge-Diagrammen verwendet, die nachstehend beschrieben werden, um anzuzeigen, wenn spezielle Signale angesteuert oder abgetastet werden. Das Quadrat zeigt an, dass ein Signal in diesem Taktzyklus angesteuert (aktiv gesetzt, eingeleitet) wird. Der Kreis zeigt an, dass ein Signal in diesem Taktzyklus abgetastet (überwacht, gespeichert) wird. Der Kreis wird typischerweise verwendet, um einen Abtastpunkt basierend auf einer ansteigenden (oder fallenden) Flanke von dem Bustakt (BCLK) in dem Signalisierungsmodus für den gemeinsamen Takt (1×) zu zeigen. Das Dreieck zeigt an, dass ein Signal basierend auf einer ansteigenden oder fallenden Flanke von einem begleitenden Signal abgetastet oder erfasst wird, das als ein ”Abtastsignal” bzw. „Strobe” bezeichnet wird. Das Abtastsignal kann vorzugsweise nur während der Übertragung von Informationen (zum Beispiel Daten, Adressen, andere Informationen) über den Prozessorbus typischerweise in einem multipumped Modus an oder aktiviert sein.
  • A. Signalisierungsmodus für einen gemeinsamen Takt
  • Gemäß einer Ausführungsform des Signalisierungsmodus für den gemeinsamen Takt (1×) werden alle Teilnehmer auf dem Prozessorbus 117 benötigt, um ihre aktiven Ausgabewerte und für Abtastung benötigenden Eingabewerte anzusteuern. Gemäß einer Ausführungsform sollte jeder Eingabewert während eines gültigen Abtastintervalls auf einer ansteigenden Flanke von dem Bustakt abgetastet werden und seine Wirkung oder Ergebnis nicht früher als die nächste ansteigende Bustaktflanke auf den Bus 117 ausgegeben werden. Dieser beispielhafte Ansatz gestattet einen ganzen Bustaktzyklus für Interkomponenten-Kommunikation (Signalübertragung und Fortpflanzung) und mindestens einen ganzen Bustaktzyklus an dem Empfänger, um die Signale zu interpretieren und zu berechnen und eine Antwort auszugeben. Nachdem ein Teilnehmer Daten auf denn Prozessorbus in einem oder mehreren Buszyklen angesteuert hat, ergibt sich resultierend eine Pause von einem Bustaktzyklus (zum Beispiel ein toter Zyklus oder ein inaktiver Zyklus), bevor ein anderer Teilnehmer den Prozessorbus 117 ansteuert.
  • 4 ist ein beispielhaftes Zeitabfolge-Diagramm, das eine beispielhafte Operation des Signalisierungsmodus für den gemeinsamen Takt (1×) gemäß einer Ausführungsform darstellt. Die Signale sind wie sie auf dem Prozessorbus 117 auftreten gezeigt. Vier Zyklen von dem Bustakt (BCLK) sind gezeigt. Zwei zusätzliche beispielhafte Signale sind ebenfalls gezeigt, die A# und B# einschließen, die irgendein Typ von Signalen sein können. Zum Beispiel kann A# ein erstes Steuersignal von einem ersten Teilnehmer sein, während B# ein zweites Signal von einem zweiten Teilnehmer sein kann. Das erste und zweite Steuersignal kann zum Beispiel als ein Teil eines Aushandel oder Busprotokolls bereitgestellt sein.
  • Wie in 1 gezeigt, wird das Signal A# auf der ansteigenden Flanke des Taktzyklus 1 angesteuert (aktiv gesetzt) (wie durch das Quadrat in A# gezeigt) und wird ist an dem Empfänger auf einer ansteigenden Flanke zu Beginn von Bustaktzyklus 2 (wie durch den Kreis für A# gezeigt) gespeichert. Taktzyklus 1 ist daher für die Signalfortpflanzung bereitgestellt. Während A# zu Beginn von Zyklus 1 aktiv gesetzt wird, wird es auf dem Bus bis zum Beginn von Zyklus 2 nicht beobachtet. Dann gibt es eine Pause oder einen inaktiven Taktzyklus (während Bustaktzyklus 2 für logische Verzögerungen und für den Empfänger, um die Signale zu interpretieren). Der Empfänger steuert an oder setzt das B#-Signal zu Beginn von Bustaktzyklus 3 (wie durch das Quadrat für B# gezeigt) aktiv, das durch die anderen Teilnehmer zu Beginn von Zyklus 4 (wie durch den Kreis für B# gezeigt) überwacht und erfasst wird.
  • Gemäß einer Ausführungsform schließt ein Prozessor eine 64-Byte Cache-Zeile ein (anstatt einer 32-Byte Cache-Zeile, die in einigen Pentium Prozessoren verwendet wird). Wenn Daten unter Verwendung des Signalisierungsmodus für den gemeinsamen Takt (1×) und 64 Datenbusleitungen übertragen werden, könnten also 64 Bytes (eine Cache-Zeile) von Daten in 8 Bustaktzyklen angesteuert oder übertragen werden. Es kann jedoch in vielen Anwendungen wünschenswert sein, eine schnellere Datenübertragungsrate oder größere Bandbreite bereitzustellen.
  • B. Multi-pumped Signalisierungsmodus
  • In vielen Fällen können, die Länge des Prozessorbusses 117, elektrische Beschränkungen (die die Lantenzzeit für die Signalfortpflanzung über den Bus einschließen) ein Vergrößern der Prozessorbusfrequenz ausschließen. Gemäß einer Ausführungsform steigert daher das multipumped Signalisierungsprotokoll eher die Datenübertragungsrate (über den Signalisierungsmodus für den gemeinsamen Takt), indem die geeignete Bus-Signalgruppe (zum Beispiel Adressbus oder Datenbus) mit einer Vielfachen der Frequenz von dem Bustakt (BCLK) betrieben wird, als die Prozessorbus-Taktfrequenz zu erhöhen.
  • 1. Ein Beispiel eines quad-pumped Signalisierungsmodus
  • In dem quad-pumped Signalisierungsmodus wird die geeignete Bus-Signalgruppe bei dem Vierfachen (4×) der Frequenz von dem Bustakt (BCLK) betrieben. In anderen Worten, in dem quad-pumped Signalisierungsmodus werden vier Informationselemente auf dem Prozessorbus 117 in einem Bustaktzyklus angesteuert (der die Zeit ist, die benötigt würde, ein Informationselement in dem gemeinsamen Takt oder 1× Signalisierungsmodus anzusteuern).
  • 5 ist ein Zeitabfolge-Diagramm, das eine Operation eines beispielhaften quad-pumped Signalisierungsmodus gemäß einer Ausführungsform darstellt. Obwohl der quad-pumped Signalisierungsmodus für irgendeinen Typen von Signalen verwendet werden kann, wird das quad-pumped Signalisierungsprotokoll verwendet, um Daten gemäß einer beispielhaften Ausführungsform zu übertragen. Zwei Bustaktzyklen und ein Abschnitt eines dritten Bustaktzyklus sind in 5 gezeigt. Im äußersten Fall ist die Flugzeit (oder Signalfortpflanzungszeit) über den Prozessorbus 117 so, dass ein zweites Informationselement auf dem Prozessorbus 117 durch den Treiber (d. h. der Teilnehmer, der Informationen auf dem Prozessorbus ansteuert) angesteuert werden kann, bevor das erste Informationselement von dem Empfänger (empfangender Teilnehmer) gespeichert worden ist.
  • Gemäß einer Ausführungsform sendet oder steuert der Treiber (oder das Treiberteilnehmer) ein neues Informationselement auf der ansteigenden Flanke und den 25%, 50% und 75% Punkten von dem Bustakt-(BCLK)Zyklus.
  • Der Empfänger sendet ebenfalls ein begleitendes Zeitabfolge-Signal, das als ein Datenabtastsignal bekannt ist, das anzeigt, wann der Empfänger die Daten antasten oder erfassen sollte. Das Abtastsignal wird vorzugsweise nur, wenn Informationen unter Verwendung des multi-pumped Signalisierungsmodus gesendet werden, gesendet oder angesteuert (aktiviert).
  • Da die Daten und die Abtastsignale durch den gleichen Treiber oder Quelle erzeugt werden, haben die Daten und die Abtastsignale den gleichen Pfad. Resultierend sollten das Abtastsignal und die Datensignale den gleichen Pfad haben und daher ungefähr die gleiche Verzögerung. Ein Vorteil, der durch den Treiber oder die Quelle erreicht wird, die sowohl ein Abtastsignal als auch Daten senden, ist also, dass die Datensignale und die Abtastsignale in Phase (oder synchron) an jedem Teilnehmer auf dem Bus 117 ankommen. Auf diese Technik eines Treibers, der sowohl die Daten als auch ein Zeitabfolge-Abtastsignal sendet, kann daher als eine Quell-synchrone Übertragung Bezug genommen werden. In dem quad-pumped Signalisierungsmodus sollte es vier Datenabtastsignale (zum Beispiel vier Zeitabfolge-Abtastsignal-Flanken, die jede einen Informations-Abtast- oder Erfassungspunkt bestimmt) in jedem Bustaktzyklus geben, eine für jedes der vier Datenelemente. Probleme können leider bei Erzeugung eines Abtastsignals mit relativ hohen Frequenzen auftreten. Bei hohen Taktgeschwindigkeiten kann der Unterschied zwischen der Rate der ansteigenden Flanke und der Rate der fallenden Flanke bedeutsam sein. Zusätzlich kann es schwierig sein, ein Taktsignal oder Abtastsignal mit einem 50% Arbeitszyklus bereitzustellen. Bei einigen hohen Taktfrequenzen sollten folglich nicht sowohl die ansteigende Flanke als auch die fallende Flanke des Abtastsignals verwendet werden, um Abtastpunkte zu bestimmen, da dies Asymmetrie verursachen oder einen Grad von Unsicherheit in der Zeitabfolge einführen kann. Es kann eher vorteilhaft sein, nur eine der zwei Flanken des Abtastsignals zu verwenden (d. h. verwende nur die ansteigenden Flanken oder nur die fallenden Flanken der Abtastsignale, um die vierfach gepumpten Daten anzutasten oder zu erfassen), um symmetrischere oder gleichförmige Abtastsignal-Zeitabfolge oder Abtastintervalle zu erhalten.
  • Wenn nur eine der Flanken des Abtastsignals verwendet werden, würde dies typischerweise eine Taktfrequenz erfordern, die ein Vielfaches der Bustaktfrequenz ist. Im Fall von quad-pumped Daten (vier Datenelemente pro Taktzyklus) sollte die Abtastsignaltaktfrequenz das Vierfache (4×) der Bustaktfrequenz sein, wenn nur eine Flanke für die Zeitabfolge verwendet wird.
  • Wenn die Prozessortaktfrequenz 100 MHz beträgt (zum Beispiel) würde dies leider eine Abtastsignalfrequenz benötigen, die 400 MHz (in diesem Beispiel) beträgt. Eine Abtastsignalfrequenz, die das Vierfache der Bustaktfrequenz ist, kann jedoch auf Verzögerungen stoßen, die sich von den übermitteln Daten oder Informationen unterscheiden, die die Abfolge der Daten und des Abtastsignals an dem Empfänger betreffen könnten. Solch eine Fehlabfolge zwischen dem übertragenen Abtastsignal und den übertragenen Daten kann dazu führen, dass der Empfänger fehlerhafte oder inkorrekte Daten erfasst. Zusätzlich kann die Signalabschwächung bei solchen hohen Frequenzen (zum Beispiel 400 MHz) signifikant höher sein.
  • Gemäß einer Ausführungsform werden deshalb vielfache Datenabtastsignale verwendet, um die vier Abtastsignale pro Bustaktzyklus bereitzustellen, ohne eine Abtastsignalfrequenz zu verwenden, die das Vierfache (4×) der Bustaktfrequenz ist. Gemäß einer Ausführungsform werden zwei Datenabtastsignale (DSTBp# und DSTBn#) bereitgestellt, jedes mit der zweifachen Frequenz von dem Bustakt. Wenn die Bustaktfrequenz 100 MHz beträgt, weisen daher die zwei Datenabtastsignale jeweils eine Frequenz von 200 MHz auf, wenn sie durch den Treiber (oder den Treiberteilnehmer) aktiviert oder erzeugt werden. Vier Datenabtastsignale könnten alternativ verwendet werden (jedes mit der gleichen Frequenz wie der Bustakt, wenn es aktiviert wird), wobei jedes ein Abtastsignal oder eine fallende Flanke pro Bustaktzyklus bereitstellt.
  • Unter wiederholter Bezugnahme auf das Zeitabfolge-Diagramm von 5 sendet oder steuert der Treiber ein neues Informations- oder Datenelement auf der ansteigenden Flanke und den 25%, 50% und 75% Punktes des Bustaktzyklus 1 an. Die Datenelemente sind als D1, D2, D3 und D4 für die vier Datenelemente in diesem Beispiel bezeichnet. Diese Ausführungsform verwendet ebenfalls zwei Datenabtastsignale, die DSTBp# und DSTBn# einschließen. Gemäß einer Ausführungsform werden die zwei Datenabtastsignale zueinander phasenverschoben (oder in einer gestaffelten oder einer versetzten Anordnung) erzeugt. Dies erlaubt einem der beiden Abtastsignale, Abtastpunkte für die ungeraden Datenelemente (zum Beispiel D1, D3, D5, ...) zu bestimmen und das andere Abtastsignal für die geraden Datenelemente (zum Beispiel D2, D4, D6, ...) verwendet zu werden.
  • Obwohl nur zwei Abtastsignale in dem Beispiel von 5 gezeigt sind, kann irgendeine Anzahl von Abtastsignalen verwendet werden, um Abtastpunkte für die Daten einer Quell-synchronen Übertragung zu bestimmen. Wie vorstehend bemerkt, kann es besonders vorteilhaft sein, vielfache Abtastsignale bereitzustellen, so dass nur eine der zwei Flanken der Abtastsignale verwendet werden können, um Abtastpunkte (oder Abtastsignale bzw. Strobes) zu bestimmen, während die Frequenz der Abtastsignale gesenkt wird. Zum Beispiel, wenn ein 6×-pumped Protokoll verwendet wird (anstatt quad-pumped), könnten drei Abtastsignale verwendet werden, wobei alle drei Abtastsignale gleichartig versetzt oder gestaffelt sein könnten, so dass Abtastsignal 1 für die Datenelemente D1 und D4 verwendet werden könnte, Abtastsignal 2 für die Datenelemente D2 und D5 und Abtastsignal 3 für die Datenelemente D3 und D6, etc.
  • Gemäß einer Ausführungsform wird nur eine der zwei Flanken der Abtastsignale verwendet, um Datenabtastpunkte zu bestimmen oder zu synchronisieren. In dieser speziellen Ausführungsform werden die fallenden Flanken der zwei Datenabtastsignale verwendet, um Punkte zum Abtasten der Informationen oder Daten zu bestimmen. Die Datenabtastsignale (oder fallende Flanken der Datenabtastsignale) sind in jedem der vier Informations- oder Datenelemente mittig angeordnet. Die vier fallenden Flanken (der Abtastsignale) der Datenabtastsignale treten daher bei den 12.5%, 37.5% 62.5% und 87.5% Punkten von dem Bustakt-(BCLK)-Zyklus auf. Die zwei Abtastsignale stellen deshalb gleichmäßig beabstandete Abtastsignale oder fallende Flanken bereit.
  • Wie in 5 gezeigt, wird ein DRDY# auf dem Bus 117 zu Beginn von Bustaktzyklus 1 (wie durch das Quadrat für DRDY# gezeigt) angesteuert. DRDY# zeigt an, dass gültige Daten auf dem Prozessorbus 117 gelegt sind und abzutasten oder zu erfassen sind. Das erste Datenelement (D1) wird durch den Treiber auf dem Prozessorbus 117 mit der ansteigenden Flanke von Bustaktzyklus 1 (wie durch das erste Rechteck für D#@Treiber gezeigt) angesteuert. Ein erstes Datenabtastsignal (DSTBp#) wird dann durch den Treiber an dem 12.5% Punkt von dem ersten Bustaktzyklus aktiviert, wie durch das erste Quadrat in DSTBp# (@Treiber) gezeigt. Das Abtastsignal (oder fallende Flanke) für das erste Datenelement (D1) ist daher in dem ersten Datenelement mittig angeordnet. Sobald ein Abtastsignal aktiviert worden ist oder angeschaltet ist, ist es typischerweise weiterhin aktiviert, bis die Daten auf den Bus angesteuert worden sind.
  • Ein zweites Datenelement wird durch den Treiber an dem 25% Punkt des Bustaktzyklus 1 angesteuert, wie durch das zweite Rechteck für D# (@Treiber) gezeigt. Das zweite Datenabtastsignal (DSTBn#) wird an dem 37.5% Punkt von Bustaktzyklus 1 aktiviert und stellt eine fallende Flanke (oder Abtastsignal) bereit, die mittig in dem zweiten Datenelement (D2) angeordnet ist. Die dritten und vierten Datenelemente (D3 bzw. D4) werden in gleicher Weise an dem 50% Punkt und dem 75% Punkt von Bustaktzyklus 1 angesteuert. Entsprechende Datenabtastsignale (fallende Flanken der Datenabtastsignale) werden durch den Treiber an dem 62.5% Punkt (durch das DSTBp#-Abtastsignal) und dem 87.5% Punkt (durch das DSTBn#-Abtastsignal) angesteuert oder bereitgestellt. Da die Datenabtastsignale mit einer Frequenz bereitgestellt werden, die das Zweifache (2×) der Frequenz von dem Bustakt ist, stellt jedes Datenabtastsignal ein Abtastsignal oder fallende Flanke jeden 1/2 Bustaktzyklus bereit. Das DSTBp#-Abtastsignal stellt daher fallende Flanken oder Abtastsignale an den 12.5% und 62.5% Punkten des Bustaktzyklus bereit, während das DSTBp#-Abtastsignal fallende Flanken oder Abtastsignale an den 37.5% und 87.5% Punkten des Bustaktzyklus bereitstellt. Daher kann erkannt werden, dass die zwei Datenabtastsignale (DSTBp# und DSTBn#) gestaffelt oder zueinander phasenverschoben sind. Dies erlaubt alternierende Abtastsignale, um eine fallende Flanke (oder Abtastsignal) jedes Viertel eines Bustaktzyklus (zwischen beiden Datenabtastsignalen) bereitzustellen. Dies stellt vier Abtastsignale oder fallende Flanken pro Bustaktzyklus zur Verfügung, um Abtast- oder Erfassungspunkt für die vier Datenelemente pro Bustaktzyklus zu bestimmen, während die Frequenz jedes Abtastsignals verringert ist. Zudem ist Zeitabfolge und Schaltung vereinfacht, da die gleiche Flanke (in diesem Beispiel die fallende Flanke) als das Abtastsignal in jedem Datenabtastsignal verwendet wird.
  • Gemäß einer Ausführungsform sollte die Latenzzeit der Informationsübermittlung von dem Treiberteilnehmer zu irgendeinem Empfänger geringer oder gleich einem Bustakt minus der Eingangswert-Speicher-Vorbereitungszeit sein, um eine korrekte Operation zu gewährleisten. Dies beugt Konflikt auf den Datenleitungen für die folgende Daten-Phase vor, wenn der Empfänger der Besitzer des Busses während der nächsten Phase wird.
  • 5 zeigt ebenfalls das Erfassen der Daten an dem Empfänger. Nachdem die Signale (Daten und Datenabtastsignale) durch den Treiber angesteuert sind, breiten sich diese Signale den Prozessorbus 117 hinunter fort und erreichen das Ziel oder den Empfänger. Das erste Datenelement wird an dem Empfänger wie durch das D#(@Empfänger) Signal gezeigt empfangen. Das erste Datenelement (D1) wird bei das ersten Abtastsignal abgetastet oder erfasst, die die erste fallende Flanke von DSTBp#(@Empfänger) ist. Das erste Dreieck für das DSTBp#(@Empfänger) bestimmt das Abtastsignal oder den Punkt zum Abtasten oder Erfassen des ersten Datenelements und das zweite Dreieck für das DSTBp#(@Empfänger) bestimmt einen Punkt oder ein Abtastsignal zum Abtasten des dritten Datenelements an dem Empfänger. Die zwei Dreiecke für das zweite Datenabtastsignal (DSTB(@Empfänger)) bestimmt in gleicher Weise die Punkte für den Empfänger, um das zweite und vierte Datenelement (D2, D4) abzutasten oder zu erfassen.
  • Wie in 5 gezeigt wird, kann das erste Datenelement D1 in den Empfänger nach der ansteigenden Flanke zu Beginn von Takt 2 und nicht früher als der 12.5% Punkt von Taktzyklus 2 (der nächste Taktzyklus) abgetastet oder erfasst (freigegeben) werden. (Die Begriffe ”erfassen”, und ”abtasten” und ”speichern”, wie sie hier verwendet werden, werden im weitesten Sinne gebraucht, um ungefähr das Gleiche auszudrücken). Die Daten für alle Datenelemente werden jedoch erst mit der ansteigenden Flanke von Bustakt 3 in dem Empfänger gespeichert. Während das Datenelement D1 nahe des Beginns von Bustaktzyklus 2 empfangen und erfasst wird, sind daher erst zu Beginn von Bustaktzyklus 3 alle Daten dem Empfänger verfügbar gemach. Der empfangende Teilnehmer umfasst vorzugsweise einen FIFO (Erste hinein, Erste heraus) Puffer, der ausreichend ist, acht Datenelemente zu speichern. Der acht Datenelemente FIFO ist ausreichend groß, um vier Datenelemente einer Datenübertragung und die nächsten vier Elemente für die nächste Übertragung zu speichern. Dies erlaubt, vier neue Datenelemente zu empfangen und zu erfasst, während die vorhergehenden vier Datenelemente von dem FIFO und dem Empfänger entnommen oder ausgegeben werden. Der Nettoeffekt beträgt das Vierfache der Bandweite des Signalisierungsmodus für den gemeinsamen Takt mit dem Effekt von zusätzlicher Latenzzeit für die erste Signalgruppe, die innerhalb des Empfängers oder der Vorrichtung gespeichert wird.
  • Gemäß einer Ausführungsform werden zusätzlich vielfache Leitungen verwendet, um vielfache Kopien von jedem der zwei Datenabtastsignale (DSTBp# und DSTBn#) zu tragen. Gemäß einer Ausführungsform gibt es vier DSTBn#-Signale und vier DSTBp#-Signale, wie es in der folgenden Tabelle ausgedrückt ist. Beispielhafte Ausführungsform eines Datenabtast-Bereichs
    Datensignale Abtastsignale
    D[15:0]# DSTBp0#, DSTBn0#
    D[31:16]# DSTBp1#, DSTBn1#
    D[47:32]# DSTBp2#, DSTBn2#
    D[63:48]# DSTBp3#, DSTBn3#
  • Die vier DSTBp#-Signale sind logisch identisch, ebenso wie es die vier DSTBn#-Signale sind, aber jedes der Datenabtastsignale wird mit einer Teilmenge der Anforderungssignale (d. h. einer Teilmenge der Datenleitungen) physikalisch geführt, um die Zeitverschiebung oder Fehlabfolge zwischen den Daten und den Datenabtastsignalen zu verringern.
  • 8 ist ein Blockdiagramm einer Vorrichtung zum Übertragen von Informationen zwischen Teilnehmern gemäß einer Ausführungsform. Ein erster Busteilnehmer 802 ist mit einem zweiten Busteilnehmer 832 verbunden. Der erste Busteilnehmer 802 umfasst einen Datenabtastsignal-Generator 1/Empfänger 1, um ein erstes Datenabtastsignal (zum Beispiel DSTBp#) über eine erste bidirektionale Datenabtastsignal-Leitung 820 zu erzeugen und zu empfangen, und einen Datenabtastsignal-Generator 2/Empfänger 2, um ein zweites Datenabtastsignal (zum Beispiel DSTBn#) über eine zweite bidirektionale Datenabtastsignal-Leitung 822 zu erzeugen und zu empfangen. Busteilnehmer 802 umfasst ebenfalls einen Bus-Sende/Empfänger 806, der einen Sendeschaltkreis zum Übertragen oder Ansteuern von Datensignalen auf dem Datenbus oder den Datensignal-Leitungen 826 und einen Empfangsschaltkreis zum Empfangen von Datensignalen über die Datensignal-Leitungen 826. Der zweite Busteilnehmer 832 umfasst in gleicher Weise einen Datenabtastsignal-Generator 1 und einen Datenabtastsignal-Generator 2, um zwei Datenabtastsignale auf den Datenabtastsignal-Leitungen 820 bzw. 822 zu erzeugen. Ein gemeinsamer (oder System-)Bustakt-Generator 810 stellt den gemeinsamen oder System-Bustakt den Busteilnehmern 802 und 832 zur Verfügung.
  • 2. Anpassen der Geschwindigkeit des Adressbusses an den Datenbus
  • Gemäß einer Ausführungsform wird die Cache-Zeilen-Größe auf 64 KBytes vergrößert (die Cache-Zeilen-Größe in einigen Pentium Prozessoren beträgt 32 Kbyte). Unter Verwendung des quad-pumped Signalisierungsprotokolls und einer Datenbusbreite mit 64 Datenleitungen, kann eine Cache-Zeile (oder 64 KByte) somit in zwei Bustaktzyklen übertragen oder übermittelt werden: 64 KByte = (2 Zyklen) × (4 Pumpvorgänge/Zyklus)(8 Bytes pro Pumpvorgang).
  • In einigen Pentium Prozessoren wird jedoch eine Anforderung (die eine Adresse umfasst) in drei Bustaktzyklen übermittelt. Die drei Bustaktzyklen für die Request-Phase für einige Pentium Prozessoren umfassen folgendes:
    • Zyklus 1: Teilphase a – eine Adresse (bereitgestellt über den Adressbus) und ein Anforderungstyp (zum Beispiel lesen, schreiben).
    • Zyklus 2: Teilphase b – zusätzliche Details für die Anforderung, die Bytefreigaben, Länge etc. einschließen (bereitgestellt über die Adressleitungen oder den Adressbus)
    • Zyklus 3 ein Totzyklus oder Bearbeitungszyklus, der es Signalen auf dem Bus erlaubt, in den Ruhezustand zurückzukehren, um anderen Teilnehmern zu gestatten den Bus anzusteuern.
  • Gemäß einer Ausführungsform kann daher eine Cache-Zeile in zwei Bustaktzyklen über den Datenbus übermittelt werden. Die Adress- und Anforderungs-Zeitabfolge benötigt jedoch in einigen Pentium Prozessoren drei Bustaktzyklen, um eine Anforderung zu übermitteln. Die Adressbus-Zeitabfolge oder die Bandbreite stimmt somit nicht mit der Geschwindigkeit des verbesserten quad-pumped Datenbusses wie in der vorstehenden Ausführungsform beschrieben überein (siehe 5). Eine der knapperen und wertvolleren Ressourcen ist die Datenbusbreite und Datenbusbandbreite. Gemäß einer Ausführungsform kann es somit besser für die Datenbusbandbreite sein, den Prozessorbus und nicht die Adressbusbandbreite zu begrenzen oder zu drosseln. Um zu verhindernden, dass der Adressbus den Prozessorbus verlangsamt oder drosselt, kann es deshalb wünschenswert sein, die Adress- und Anforderungs-Zeitabfolge auf dem Adressbus anzupassen, um zumindest die Bandbreite oder die Geschwindigkeit des Datenbusses (in diesem Beispiel für die Übertragung einer Cache-Zeile auf dem Datenbus) anzupassen.
  • Gemäß einer Ausführungsform wurden deshalb die Zeitabfolge und die Geschwindigkeit der Request-Phase, die über den Adressbus bereitgestellt werden, angepasst, um die Gesamtgeschwindigkeit des Datenbusses in Übereinstimmung zu bringen. Es ist wünschenswert, den Totzyklus oder den Bearbeitungszyklus zu erhalten. Gemäß einer beispielhaften Ausführungsform wurde daher der Adressbus double-pumped betrieben werden, um zwei Informationselemente (Teilphase a und Teilphase b der Anforderung) in einem Bustaktzyklus bereitzustellen.
  • 3. Ein Beispiel eines double-pumped Signalisierungsmodus
  • Gemäß einer Ausführungsform betreibt ein double-pumped Signalisierungsmodus im Allgemeinen die geeignete Bus-Signalisierungsgruppe mit der Zweifachen (2×) Frequenz von dem Bustakt (BCLK). 6 ist ein Zeitabfolge-Diagramm, das eine Operation eines beispielhaften double-pumped Signalisierungsmodus gemäß einer Ausführungsform darstellt. Der Adressbus ist double-pumped in dieser Ausführungsform, während irgendwelche Signale double-pumped sein können.
  • Unter Bezug auf 6 geht das ADS#-Signal zu Beginn der Request-Phase auf niedrigen Pegel. In dem double-pumped Signalisierungsmodus werden zwei Informationselemente auf dem Bus in der Zeit angesteuert, die es benötigt, ein Element unter Verwendung des Signalisierungsmodus für den gemeinsamen Takt (d. h. während eines Bustaktzyklus) anzusteuern. Aufgrund der Flugzeit (oder Signalfortpflanzungszeit auf dem Prozessorbus 117) kann die zweite Signalgruppe oder Informationselemente an dem Treiber angesteuert werden, bevor das erste Element von dem(n) Empfänger(n) gespeichert wird. Gemäß einer Ausführungsform sendet der Treiber ein neues Informationselement auf der ansteigenden Flanke und dem 50% Punkt des Bustaktzyklus.
  • Wie in 6 gezeigt, wird eine Teilphase a der Anforderung (Aa), die die Transaktionsadresse bereitstellt, auf der ersten Hälfte von Bustaktzyklus 1 gesendet, der mit der fallenden Flanke zu Beginn des Bustaktzyklus 1. Teilphase b der Anforderung (Ab), die zusätzliche Details für die Transaktion bereitstellt, wird auf der zweiten Hälfte von Bustaktzyklus 1 gesendet, der an dem 50% Punkt von Bustaktzyklus 1 beginnt. Diese zwei Informationselemente sind in 6 als zwei Rechtecke für Aa und Ab für die A#(@Treiber) Leitungen gezeigt. (Aa zeigt Teilphase a der Anforderung an, die über die Adressleitungen bereitgestellt wird, während Ab Teilphase b der Anforderung anzeigt, die über die Adressleitungen bereitgestellt wird). Der Adressbus ist daher double-pumped, da zwei Informationselemente (Aa und Ab) während eines Bustaktzyklus übermittelt oder gesendet werden.
  • Da Informationen für die Anforderung unter Verwendung eines double-pumped Signalisierungsmodus (zwei Informationselemente pro Bustaktzyklus) gesendet werden, werden die Informationen zusätzlich vorzugsweise als eine Quell-synchrone Übertragung gesendet. Zusätzlich zu den zwei Informationselementen angesteuert oder aktiviert der Treiber daher ebenfalls ein Adressabtastsignal, um zwei Adressabtastsignale pro Bustaktzyklus (wenn aktiviert) bereitzustellen. Die Adressabtastsignale stellen bereit oder bestimmen Punkte, um die zwei Informationselemente (Aa und Ab) abzutasten, die auf dem Adressbus gesendet werden.
  • Gemäß einer Ausführungsform wird ein Adress-abtastsignal (ADSTB#) verwendet, das die gleiche Frequenz wie der Bustakt (BCLK) aufweist. Um jedoch zwei Abtastsignale während des einen Bustaktzyklus bereitzustellen, werden sowohl fallende Flanken als auch ansteigende Flanken des Adressabtastsignals als Abtastsignale oder um Abtastpunkte für die zwei Informationselemente zu bestimmen verwendet, die über den Adressbus bereitgestellt werden. Wie in 6 gezeigt, aktiviert der Treiber ein Adressabtastsignal (ADSTB#) an dem 25% Punkt von Bustaktzyklus 1, der in der Mitte von Informationselement 1 (Aa) liegt. Gemäß einer Ausführungsform wird das Adressabtastsignal für das erste Informationselement (Aa oder Teilphase a der Anforderung) als die fallende Flanke des ADSTB#-Signals (das an dem 25% Punkt von Bustaktzyklus 1 angesteuert wird) bereitgestellt, während das Adressabtastsignal für das zweite Informationselement (Ab oder Teilphase b der Anforderung) als die ansteigende Flanke des ADSTB#-Signals (das an dem 75% Punkt von Bustaktzyklus 1 angesteuert wird) bereitgestellt wird.
  • Obwohl das Adressabtastsignal eine Frequenz aufweist, die die Gleiche wie der Bustakt ist, sollte der Bustakt nicht als das Abtastsignal für die Informationselemente verwendet werden, da das Bustaktsignal ansteigende und fallende Flanken nicht zu den geeigneten Zeitpunkten bereitstellt. Das Bustaktsignal ist außerdem immer aktiviert (im Gegensatz zu einem Abtastsignal, das nur während einer Quell-synchronen Übertragung aktiviert ist). Das Adressabtastsignal wird verwendet, um Abtastsignale oder Abtastpunkte für die zwei Informationselemente bereitzustellen, da das Adressabtastsignal aktiviert (angeschaltet) und deaktiviert (abgeschaltet) werden ungeachtet des Zustands oder der Phase von dem Bustakt. Indem die Abtastsignale von der gleichen Quelle wie die Informationen angesteuert wird, stimmt die Verzögerung der Abtastsignale mit der Verzögerung der Informationen überein und ermöglichen somit, dass sich zu gleichen Zeit mehr als ein Bit auf einer Leitung befindet.
  • Die Informationselemente (Aa und Ab) und das Adressabtastsignal breiten sich entlang des Prozessorbusses 117 aus und erreichen den Empfänger zu Beginn von Bustaktzyklus 2. Wie in 6 gezeigt, wird das erste Informationselement (Aa) auf der fallenden Flanke von dem ADSTB#(@Empfänger)-Signal erfasst oder abgetastet und das zweite Informationselement wird auf der ansteigenden Flanke des ADSTB#(@Empfänger)-Signals erfasst oder abgetastet, wie durch die zwei Dreiecke auf dem ADSTB#(@Empfänger)-Signal gezeigt. Es kann daher erkannt werden, dass der Empfänger die Daten oder Informationen in vorbestimmter Weise erfasst, basierend auf einer Anzeige von dem Treiber wann die Daten gültig sind (und erfasst werden sollten).
  • Gemäß einer Ausführungsform sollte die Latenzzeit der Datenübertragung von dem Treiberteilnehmer zu irgendeinem Empfänger geringer oder gleich einem Bustaktzyklus minus der Eingangswert-Speicher-Vorbereitungszeit sein. Dies sollte Konflikt auf den Adressleitungen (oder dem Adressbus) und anderen Leitungen für die zweite oder nachfolgende Phase vorbeugen, wenn der Empfänger der Besitzer des Busses während der nächsten Phase wird. Der Nettoeffekt beträgt das Zweifache der Bandbreite des Signalisierungsmodus für den gemeinsamen Takt mit dem Effekt von zusätzlicher Latenzzeit für die erste Signalgruppe, die innerhalb der Komponente oder dem Empfänger gespeichert wird.
  • Gemäß einer Ausführungsform umfasst der Empfänger ein vier Elemente FIFO Puffer, um vier Informationselemente zu speichern, die über den Adressbus während der Request-Phase übertragen werden. Dies ermöglicht, dass Elemente von Teilphase a und Teilphase b einer Anforderung in dem FIFO empfangen und erfasst werden, während zur gleichen Zeit ermöglicht wird, dass Elemente von Teilphase a und Teilphase b einer vorherigen Anforderung aus dem FIFO ausgelesen und von dem Empfänger gespeichert werden.
  • Gemäß einer Ausführungsform wird ein einzelnes Adressabtastsignal mit der gleichen Frequenz wie der Bustakt verwendet, um die Abtastsignale für die zwei Informationselemente bereitzustellen, die über den Adressbus übermittelt werden. Bei diesen Frequenzen für die Adresstastsignale (die gleiche Frequenz wie das Bustaktsignal) ist Signalabschwächung kein Problem. Irgendwelche Asymmetrien in dem Abtastsignalarbeitszyklus stellt außerdem kein Problem dar, da nur zwei Informationselemente pro Bustaktzyklus übermittelt werden. Ein einzelnes Adressabtastsignal mit der gleichen Frequenz wie der Bustakt, bei dem sowohl die fallenden als auch de ansteigenden Flanken als Abtastsignale verwendet werden, kann für das Adressabtastsignal verwendet werden.
  • Vielfache (oder zwei) Adressabtastsignale können alternativ mit nur einer der Flanken von jedem Adressabtastsignal verwendet werden, das als ein Abtastsignal eingesetzt wird. Zum Beispiel könnte ein erstes Adressabtastsignal, das (mit einer fallenden Flanke) an dem 25% Punkt von Zyklus 1 aktiviert wird, und ein zweites Adressabtastsignal, das (mit einer fallenden Flanke) an dem 75% Punkt aktiviert wird, verwendet werden. Die Aktivierungspunkte der zwei Adress Abtastsignale würden daher versetzt oder gestaffelt sein. Da nur zwei Elemente während eines Bustaktzyklus angesteuert werden, könnte die Frequenz der Adressabtastsignale gewählt werden, um gleiche der Bustaktfrequenz oder einer anderen Frequenz zu sein.
  • 9 ist ein Blockdiagramm einer Vorrichtung zum Übertragen von Informationen zwischen Teilnehmern gemäß einer anderen Ausführungsform. Ein erster Busteilnehmer 802 ist mit einem zweiten Busteilnehmer 832 verbunden. Der erste Busteilnehmer 802 umfasst einen Adressabtastsignal-Generator 940, um ein Adressabtastsignal (zum Beispiel ADSTB#) auf einer bidirektionalen Adress-Abtastsignalleitung 920 zu erzeugen. Busteilnehmer 802 umfasst ebenfalls einen Bus-Sende/Empfänger 906 ein, der einen Sendeschaltkreis zum Übermitteln oder Ansteuern von Adress- und anderen Signalen auf dem Adressbus oder den Adresssignal-Leitungen 926 und einen Empfangsschaltkreis zum Empfangen von Signalen, die über die Adresssignal-Leitungen 926 empfangen werden. Der zweite Busteilnehmer 832 umfasst in gleicher Weise einen Adress-Abtastsignal-Generator 942 zum Erzeugen eines Adressabtastsignals auf der bidirektionalen Adress-Abtastsignalleitung 920. Der zweite Busteilnehmer 832 umfasst ebenfalls einen Bus-Sende/Empfänger 936, der einen Empfangsschaltkreis und einen Sendeschaltkreis zum Übermitteln von Signalen bzw. Empfangen von Signalen über die Adresssignal-Leitungen 926 einschließt.
  • Wie vorstehend beschrieben, kann eine Datenübertragung einer Cache-Zeile in zwei Bustaktzyklen unter Verwendung des quad-pumped Signalisierungsmodus übermittelt werden, und eine Adressanforderung kann in zwei Bustaktzyklen unter Verwendung des quad-pumped Signalisierungsmodus übermittelt werden. Sowohl der Adressbus als auch der Datenbus weisen den gleichen Spitzendurchsatz auf, der einen ausgewogenen Prozessorbus bereitstellt. Wenn nicht anders bemerkt, werden die meisten wenn nicht alle verbleibenden Signale unter Verwendung des Signalisierungsmodus für den gemeinsamen Takt (1×) übermittelt.
  • VII. Neuabstimmen des Busprotokolls auf die neue Überlagerungsrate von 2 Taktzyklen
  • Wie vorstehend beschrieben stellt der Prozessorbus gesteigerte Anforderung und Datenbandbreite durch die Verwendung von vielfach gepumpten Signalisierungsprotokollen bereit. Diese Steigerung in der Anforderungsbandbreite (auf dem Adressbus) und der Datenbandbreite (auf dem Datenbus) wird erreicht, ohne die Datenbusbreite (64 Leitungen) zu vergrößern, ohne eine kostspielige Taktung oder Führungstopologie zu verwenden und unter Beibehaltung des gleichen Basistyps von Busprotokoll wie er in einigen Pentium Prozessoren eingesetzt wird.
  • In einigen Pentium Prozessoren wird ein Signalisierungsmodus für einen gemeinsamen Takt verwendet, um acht Datenbytes pro Bustaktzyklus bei Einsatz von 64 Datenleitungen zu übertragen, die es erlauben, eine 32 Bytes Cache-Zeile in vier Bustaktzyklen zu übertragen. Gemäß einer Ausführungsform der Erfindung wird die Cache-Zeile auf 64 Bytes vergrößert und ein quad-pumped Signalisierungsmodus (der 32 Bytes pro Bustaktzyklus überträgt) kann eingesetzt werden, um eine 64 Byte Cache-Zeile in zwei Bustaktzyklen zu senden. In einigen Pentium Prozessoren wird zusätzlich eine Anforderung in drei Bustaktzyklen übertragen, die Teilphase a in Bustaktzyklus 1, Teilphase b in Zyklus 2 und einen Bearbeitungszyklus (oder Totzyklus) für Zyklus 3 einschließen. Gemäß einer Ausführungsform der Erfindung wird ein double-pumped Signalisierungsmodus auf dem Adressbus verwendet, um sowohl Teilphase a als auch b der Anforderung in einem einzelnen Bustaktzyklus zu übertragen oder übermitteln. Dies vermindert die Länge der Request-Phase auf zwei Bustaktzyklen, die die Länge einer Cache-Zeilen-Übertragung (ebenfalls zwei Bustaktzyklen) in Übereinstimmung bringt. Da eine Request-Phase eine Länge von zwei Bustaktzyklen aufweist und eine Cache-Zeilen-Übertragung zwei Bustaktzyklen benötigt, kann daher die Überlagerungsrate oder die Überlagerungsfrequenz des Prozessorbusses im Allgemeinen als zwei Bustaktzyklen betrachtet werden.
  • Gemäß einer Ausführungsform der Erfindung wird das Busprotokoll neu abgestimmt oder modifiziert, um die Latenzzeit oder Verzögerung zwischen dem Beginn von aufeinander folgenden Phasen einzustellen, um die neue Überlagerungsfrequenz von zwei Bustaktzyklen für den Prozessorbus genauer in Übereinstimmung zu bringen. 7 ist ein Diagramm, das die minimale Latenzzeit oder Verzögerung zwischen Transaktionsphasen (die Arbitrierungs-, Request-, Snoop- und Response-Phase einschließen) darstellt. Arbitrierungs-(Arb), Request-(Req), Snoop- und Response-(Resp)Phasen sind für zwei Transaktionen (Transaktion 1 und Transaktion 2) gezeigt. Zahlen sind gezeigt, um eine Latenzzeit oder Verzögerung zwischen Phasen anzuzeigen. Die ersten Nummer zeigt die minimale Zahl von Bustaktzyklen zwischen dem Beginn von Phasen an, wie in einigen Pentium Prozessoren implementiert, während die zweite Nummer (die in Klammern gesetzt ist) die neue minimale Latenzzeit zwischen Phasen an, nachdem das Busprotokoll eingestellt oder neu abgestimmt wird, um die neue Überlagerungsfrequenz von zwei Bustaktzyklen genauer in Übereinstimmung zu bringen. Wenn nur eine Nummer gezeigt ist, zeigt dies an, dass es keine Änderung in der Verzögerung oder Latenzzeit zwischen Phasen wie zwischen einigen Pentium Prozessoren und einer Ausführungsform der Erfindung gibt.
  • Wie vorstehend bemerkt, beträgt die Latenzzeit zwischen den Phasen, die in 7 gezeigt sind, typischerweise zwei Bustaktzyklen. Unter Bezugnahme auf 7 verbleibt die minimale Latenzzeit zwischen dem Beginn einer Arbitrierungs-Phase und dem Beginn einer Request-Phase für eine Transaktion (zum Beispiel Transaktion 1) unverändert bei zwei Bustaktzyklen. Die minimale Latenzzeit von dem Beginn einer Request-Phase zu dem Beginn einer Snoop-Phase einer Transaktion wird von vier Bustaktzyklen auf drei Zyklen verringert. Die minimale Latenzzeit zwischen dem Beginn einer Snoop-Phase zu dem Beginn einer Response-Phase verbleibt unverändert bei zwei Bustaktzyklen. Die minimale Latenzzeit zwischen dem Beginn einer Request-Phase und wann ein Zielteilnehmer das TRDY#-Signal aktiv setzen kann wird von drei auf zwei Bustaktzyklen verringert. Die minimale Latenzzeit eines Aktiv-Setzen des TRDY#-Signals zu dem Beginn der Response-Phase verbleibt unverändert bei zwei Bustaktzyklen.
  • Die minimale Latenzzeit zwischen der gleichen oder entsprechenden Phasen aufeinander folgender Transaktion wird modifiziert, um die Überlagerungsfrequenz von zwei Taktzyklen genauer in Übereinstimmung zu bringen. Unter wiederholter Bezugnahme auf 7 wird die minimale Latenzzeit zwischen aufeinanderfolgender Phasen (zum Beispiel minimale Latenzzeit zwischen Beginn von Arbitrierungs-Phase von Transaktion 1 und dem Beginn von Arbitrierungs-Phase von Transaktion 2) von drei Bustaktzyklen auf zwei Zyklen verringert. Die minimale Latenzzeit zwischen aufeinanderfolgender Request-Phasen wird von drei Bustaktzyklen auf zwei verringert. Die minimale Latenzzeit zwischen aufeinanderfolgender Snoop-Phasen wird von drei Bustaktzyklen auf zwei verringert. Und die minimale Latenzzeit zwischen aufeinanderfolgender Response-Phasen wird von drei Bustaktzyklen auf zwei verringert.
  • Jede der Phasen wird im Weiteren mit einer kurzen Erklärung einiger Änderungen oder Modifikationen an dem Busprotokoll für jene Phase beschrieben, die zu einer Verringerung in der Latenzzeit zwischen den Phasen beiträgt (wo eine Verringerung in der Latenzzeit auftritt).
  • Wenn ein anfordernder Teilnehmer den Bus nicht besitzt, beginnen Transaktionen mit einer Arbitrierungs-Phase, in der ein anfordernder Teilnehmer Besitzer des Busses wird. Nachdem der anfordernde Teilnehmer Busbesitzer ist, tritt die Transaktion in die Request-Phase ein. In einer ersten Teilphase (Teilphase a) der Request-Phase wird ein ADS#-Signal (das eine gültige Adresse anzeigt) gemeinsam mit der Transaktionsadresse und ausreichenden Informationen angesteuert, um Snooping und Speicherzugriff zu beginnen. In der zweiten Teilphase (Teilphase b) der Request-Phase werden verschiedene zusätzliche Informationen für die Anforderung auf dem Bus 117 angesteuert, die Bytefreigaben (die anzeigen, welche Datenbytes auf den Datenleitungen bereitgestellt werden), eine zeitversetzte ID, Transaktionslänge und andere Transaktionsinformationen einschließen. Die erste und zweite Teilphase werden während einem Bustaktzyklus angesteuert. Gemäß einer Ausführungsform werden folglich die Anforderungsinformationen (zum Beispiel viele von ihnen werden über den Adressbus bereitgestellt) bezeichnet, eine 2× Datenübertragungsrate zu besitzen.
  • Gemäß einer Ausführungsform weist jede Transaktion eine Snoop-Phase auf. Die Snoop-Ereignisse von der Snoop-Phase zeigen an, ob die Adresse, die für eine Transaktion angesteuert wird, auf eine gültige oder modifizierte (dirty) Cache-Zeile in irgendeinem Cache eines Busteilnehmers verweist. Die Snoop-Ereignisse zeigen ebenfalls an, ob eine Transaktion ordnungsgemäß abgeschlossen werden wird oder für eine mögliche außerordentliche Fertigstellung verzögert werden kann. Ein Teilnehmer kann eine Transaktion verzögern, wenn er nicht bereit ist zu snoopen, indem die Snoop-Phase unter Verwendung eines Snoop-Stopps gedehnt wird.
  • Jede der Phasen wird beschrieben werden und die Unterschiede, die implementiert sind, um die Latenzzeit zwischen den Phasen zu verringern (wo möglich) hervorgehoben.
    • 1) Arbitrierungs-Phase: Keine Transaktionen können ausgegeben werden, bis der Busteilnehmer Besitzer des Prozessorbusses 117 ist. Eine Transaktion muss diese Phase nur dann aufweisen, wenn der Teilnehmer, der die Transaktion auf dem Prozessorbus 117 ansteuern will, den Bus 117 nicht schon besitzt. Gemäß einer Ausführungsform wird ein Busarbitrierungsprotokoll bereitgestellt, das zwei Klassen von Busteilnehmer unterstützt: symmetrische Teilnehmer und Prioritätsteilnehmer. Prozessoren auf dem Bus 117 arbitrieren typischerweise als symmetrischer Teilnehmer. Der Prioritätsteilnehmer (zum Beispiel Systemschnittstelle 116) arbitriert normalerweise im Auftrag des I/O-Subsystems (I/O-Brücke 124 oder I/O-Teilnehmer) und des Speicher-Subsystems (Speicherteilnehmer, die in dem Hauptspeicher-Subsystem 122 angeordnet sind).
  • Eine beispielhafte Signalgruppe, die verwendet werden kann, um den Busbesitz zu arbitrieren, ist nachfolgend gezeigt (Wie hier verwendet, zeigt das # Zeichen aktiv niederpegliges Signale an) Beispielhafte-Arbitrierungs-Signale
    Pin/Signalname Pin Mnemonik Signal Mnemonik
    Busanforderung eines symmetrischen Teilnehmers BR[3:0]# BREQ[3:0]#
    Busanforderung eines Prioritätsteilnehmers BPRI# BPRI#
    blockiere nächste Anforderung BNR# BNR#
    Sperren LOCK# LOCK#
  • Der Prozessorbus 117 ermöglicht einer Vielzahl von Teilnehmern, gleichzeitig um den Bus 117 zu arbitrieren. Die symmetrischen Teilnehmer arbitrieren um den Bus 117 basierend auf dem zyklischen Multiplex-(bzw. Round-Robin)Rotations-Prioritäts-Schema. Das Arbitrierungs-Schema gewährleistet einen fairen Zugriff auf eine Request-Phase für alle symmetrischen Teilnehmer. Jeder symmetrische Teilnehmer weist eine eindeutige Teilnehmer-ID auf, die beim Rücksetzen zugewiesen wird (zum Beispiel Teilnehmer 0, 1, 2, 3) und Arbitrierung findet in kreisförmiger Abfolge statt. Nach dem Rücksetzen, weist Teilnehmer 0, gefolgt von Teilnehmer 1, 2 und 3, die höchste Priorität auf. Jeder symmetrische Teilnehmer bewahrt eine gemeinsame Rotations-ID, die die symmetrische Teilnehmer-ID des letzten Busbesitzers wiedergibt. Bei jedem Rotationsereignis wird der symmetrische Teilnehmer mit der höchsten Priorität der Besitzer und kann in die Request-Phase eintreten, wenn es keinen anderen Vorgang höher Priorität gibt, der die Benutzung des Busses verhindert. Der (die) Prioritätsteilnehmer weist(en) höhere Priorität als der symmetrische Besitzer auf.
  • Ein symmetrischer Teilnehmer fordert den Bus an, indem er sein BREQ#-Signal aktiv setzt. Basierend auf dem Wert, der auf BREQ[3:0] abgetastet wird und dem letzten symmetrischen Busbesitzer, können alle Teilnehmer gleichzeitig den nächsten symmetrischen Busbesitzer bestimmen. Ein Prioritätsteilnehmer fordert den Bus an, indem er BPRI# aktiv setzt, das sich temporär über das Arbitrierungs-Schema hinwegsetzt, da kein anderer symmetrischer Teilnehmer eine andere ungesperrte Bustransaktion ausgibt, bis BPRI# als inaktiv abgetastet wird. Der Prioritätsteilnehmer ist immer der nächste Busbesitzer. Das BNR#-Signal kann durch irgendeinen Busteilnehmer aktiv gesetzt werden, um weitere Transaktionen zu blockieren, auf dem Bus ausgegeben zu werden (wird normalerweise verwendet, wenn Systemressourcen wie zum Beispiel Puffer gefüllt sind und keine anderen Transaktionen unterbringen). Das Aktiv-Setzen des LOCK#-Signals zeigt an, dass das ein Busteilnehmer eine atomare Abfolge von Bustransaktionen ausführt, die nicht unterbrochen werden dürfen.
  • Der Prioritätsteilnehmer kann BPRI# inaktiv setzen und Busbesitz in dem gleichen Zyklus freigeben, dass er seine letzte Anforderung erzeugt. In einigen Pentium Prozessoren muss, nachdem das BPRI#-Signal aktiv gesetzt wird, das BPRI#-Signal für ein Minimum von zwei Bustaktzyklen inaktiv gesetzt werden. Dies bringt die alte 3 Bustaktzyklenrate (in einigen Pentium Prozessoren) in Übereinstimmung und derart bereitgestellte symmetrische Teilnehmer und Prioritätsteilnehmer gleichen den Zugriff auf den Bus aus. Gemäß einer Ausführungsform wird das Protokoll geändert, um zu veranlassen, dass das BPRI#-Signal nur für ein Minimum von einer Bustaktzyklus inaktiv gesetzt werden muss, nachdem es gültig gesetzt ist. Diese Änderung in einer aktuellen Ausführungsform unterstützt eine Überlagerungsrate von zwei Bustaktzyklen, ein Bustaktzyklus für Aktiv-Setzen und ein Zyklus für Inaktiv-Setzen.
  • Wie bemerkt, kann das BNR#-Signal verwendet werden, um weitere Anforderungen zu verzögern, zum Beispiel, wenn ein Teilnehmer nicht ausreichend Ressourcen zur Verfügung hat, um eine andere Transaktion zu unterstützen. Gemäß einer Ausführungsform ist ein Anforderungs-Stopp-Protokoll implementiert und ist basierend auf drei Zuständen bestimmt:
    • 1) Frei: In diesem Zustand ist die Fähigkeit eines Teilnehmer Anforderungen auszugeben, nicht durch das BNR# Anforderungs-Stopp-Protokoll begrenzt, sondern ist nur durch seinen Besitz des Busses und durch die Anforderungsrate begrenzt. In einigen Pentium Prozessoren tritt der BNR# Abtastpunkt in den freien Zustand drei Taktzyklen auf, nachdem ADS# als aktiv gesetzt abgetastet wird. Gemäß einer Ausführungsform wird der BNR# Abtastpunkt eingestellt, um zwei Taktzyklen (eher als drei), nachdem das ADS# als aktiv gesetzt abgetastet wird, aufzutreten. Wenn ein Teilnehmer beabsichtigt, eine neue Anforderungserzeugung in dem freien Zustand zu stoppen, steuert der Teilnehmer in dem Taktzyklus vor einem gültigen BNR# Abtastpunkt von ADS# BNR# aktiv an. In dem nächsten Taktzyklus überwachen alle Teilnehmer ein aktives BNR# an einem BNR# Abtastpunkt und einen Übergang in den Stopp-Zustand.
    • 2) Gedrosselt: Ein Teilnehmer kann eine Anforderung in diesem Zustand ausgeben, sobald er sich im Besitz des Busses befindet und die maximale ADS Anforderungsrate erhalten wurde. Der BNR# Abtastpunkt befindet sich in dem ersten Taktzyklus des gedrosselten Zustands. Wenn im gedrosselten Zustand, falls BNR# an dem BNR# Abtastpunkt als aktiv abgetastet wird, wird der Zustand in den gestoppten Zustand überführt. Falls BNR# an dem BNR# Abtastpunkt als inaktiv abgetastet wird, wird der Zustand in den freien Zustand überführt.
    • 3) Gestoppt: In diesem Zustand kann ein Teilnehmer bis BNR#, das an dem BNR# Abtastpunkt abgetastet wird, inaktiv wird keine Anforderung ausgeben. Der BNR# Abtastpunkt beginnt in dem Bustaktzyklus, wenn in den gestoppten Zustand eingetreten wird und jeder andere Taktzyklus, solange BNR# an seinem Abtastpunkt als aktiv abgetastet wird. Ein Anforderungs-Stopp-Zustand wird immer eingeleitet, um nach einem Rücksetz-Ereignis (entweder ein INIT# oder RESET#) zu stoppen. Ein Teilnehmer kann den gestoppten Zustand ausdehnen, indem er BNR# jeden zweiten Taktzyklus (vor dem gültigen Abtastpunkt) aktiv setzt. Wenn BNR# während des gestoppten Zustands nicht als aktiv abgetastet wird, wird der Anforderungs-Stopp-Zustand in den gedrosselten Zustand überführt.
  • Das Erfordernis das BPRI#-Signal nur für ein Minimum von einem Taktzyklus (eher als zwei), nachdem es aktiv gesetzt wurde, inaktiv gesetzt zu werden und das Einstellen des BNR# Abtastpunkts in dem freien Zustand, um zwei Taktzyklen (eher als drei), nachdem das ADS#-Signal als aktiv gesetzt abgetastet wurde, aufzutreten, verringert also die minimale Latenzzeit zwischen dem Beginn aufeinander folgender Arbitrierungs-Phase von drei Bustaktzyklen auf zwei Bustaktzyklen.
    • 2) Request-Phase: Die Request-Phase ist die Phase in der die Transaktion tatsächlich ausgegeben oder auf dem Bus angesteuert wird. Gemäß einer Ausführungsform dauert die Request-Phase einen gemeinsamen Bustaktzyklus. Die Request-Phase schließt zwei Teilphasen ein, die die Teilphasen a (während der ersten Hälfte der Request-Phase) und die Teilphase b (während der zweiten Teilphase der Request-Phase) einschließen. Anforderungsinformationen werden während der Request-Phase übermittelt, die die Transaktionsadresse einschließen. Die Request-Phase beginnt mit dem Aktiv-Setzen des ADS#-Signals, das Adressabtastsignal. Hier ist eine beispielhafte Gruppe von Signalen, die verwendet werden können um eine Anforderung zu übermitteln.
    Beispielhafte Anforderungssignale
    Pin-Name Pin-Mnemonik Signal-Name Signal-Mnemonik Anzahl
    Adressabtast-Signal ADS# Adressabtast-Signal ADS# 1
    Anforderungs-Kommando REQ[4:0]# Anforderungc REQa[4:0]# 5
    erweiterte Anforderungb REQb[4:0]#
    Anforderungs-Abtastsignale ADSTB[1:0]# Anforderungs-Abtastsignale ADSTB[1:0]# 2
    Adresse A[35:3]# Adressec Aa[35:3]# 33
    Reserviertb Ab[35:32]#
    Attributeb ATTR[7:0] oder Ab[31:24]#
    Verzögerungs-IDb DID[7:0]# oder Ab[23:16]#
    Bytefreigabenb BE[7:0]# oder Ab[15:8]#
    erweiterte Funktionenb EXF[4:0]# oder Ab[1:0]#
  • Bemerkungen:
    • a. Diese Signale werden auf dem angezeigten Pin während der ersten Teilphase (Teilphase a) der Request-Phase angesteuert.
    • b. Diese Signale werden auf dem angezeigten Pin während der zweiten Teilphase (Teilphase b) der Request-Phase angesteuert.
  • Die Transaktionsadresse wird auf Aa[35:3] (wobei das ”A” Adressleitungen oder Adressbus 204 anzeigt und ”a” Signale anzeigt, die während Teilphase a übermittelt werden) und zusätzliche Informationen (zum Beispiel Bytefreigaben, Attribute, erweiterte Funktionen), die die Transaktion beschreiben, werden auf Ab[35:3] (wobei ”b” anzeigt, dass die zusätzlichen Informationen über die Adressleitungen während Teilphase b übermittelt werden) übermittelt. Das Aktiv-Setzen von ADS# definiert den Beginn der Request-Phase. ADSTB[1:0]# sollte vorzugsweise einmal in jedem Bustaktzyklus, indem ADS# aktiv gesetzt ist, umgeschaltet werden, und nicht in irgendeinem anderen Zyklus. Die REQa[4:0]# und REQb[4:0] bestimmen den Transaktionstyp.
  • Gemäß einer Ausführungsform kann die Anforderung auf dem Prozessorbus angesteuert werden:
    • 1) Taktzyklus nach Besitzüberwachung; und
    • 2) zwei oder mehr Takte nach ADS# Aktiv-Setzen für eine vorhergehende Transaktion; und
    • 3) BNR# wird als inaktiv überwacht; und
    • 4) LOCK#, wenn nicht durch diesen Teilnehmer aktiviert, wird als inaktive überwacht.
  • Einige Pentium Prozessoren benötigen eine minimale Verzögerung von drei Taktzyklen nach Aktiv-Setzen von ADS# der vorhergehenden Transaktion, bevor die Anforderung auf dem Bus angesteuert werden kann. Um die minimale Latenzzeit zwischen den Request-Phasen von aufeinander folgenden Transaktionen von drei Taktzyklen auf zwei Taktzyklen zu verringern, kann ein Teilnehmer die Anforderung auf dem Bus nach nur zwei Bustaktzyklen gemäß einer Ausführungsform ansteuern, nachdem das ADS#-Signal von der vorhergehenden Transaktion aktiv gesetzt wurde. Wie vorstehend bemerkt bestimmt das ADS#-Signal den Beginn der Request-Phase und zeigt an, dass Teilphase a der Request-Phase auf dem Prozessorbus angesteuert wird, der eine Adresse (die über den Adressbus bereitgestellt wird) und eine Anforderung (die über die REQ#[4:0] Leitungen bereitgestellt wird) einschließt.
    • 3) Snoop-Phase: Gemäß einer Ausführungsform unterstützt der Prozessorbus Cache-Kohärenz für vielfache zwischenspeichernde Teilnehmer. Kohärenz (oder Datenkonsistenz) stellt sicher, dass ein System oder Computer mit vielfachen Ebenen von Cache und Speicher und vielfachen zwischenspeichernden Teilnehmern ein Modell eines gemeinsam genutzten Speichers aufweisen, in dem vorzugsweise kein Teilnehmer jemals veraltete (oder inkorrekte) Daten liest und Vorgänge können, wie benötigt, in serielle Folge gebracht werden. Eine Zeile ist die Vorrichtung zum Zwischenspeichern in dem zwischenspeichernden Teilnehmer. Gemäß einer Ausführungsform hat eine Cache-Zeile 64 Bytes, aber andere Größen an Cache-Zeilen können verwendet werden.
  • Das Cache-Protokoll bringt Zustände mit Zeilen in Verbindung und definiert Regeln, die Zustandsübergänge regeln. Jede Zeile weist einen Zustand in jedem Cache auf. Gemäß einer Ausführungsform gibt es vier Zeilenzustände, die einschließen: M (modifiziert bzw. Modified), der anzeigt, dass die Zeile in diesem Cache ist und einen aktuelleren Zeilenwert als im Speicher beinhaltet und die Zeile in allen anderen Teilnehmern inaktiv ist; E (exklusiv bzw. Exclusive), der anzeigt, dass die Zeile in diesem Cache ist und den gleichen Wert wie im Speicher aufweist und inaktiv in allen anderen Teilnehmern ist; S (gemeinsam bzw. Shared), der anzeigt, dass die Zeile in diesem Cache ist, den gleichen Wert wie im Speicher aufweist und in anderen Teilnehmern vorhanden sein kann und I (inaktiv bzw. Invalid), der anzeigt, dass die Zeile in diesem Cache nicht verfügbar ist und von einem anderen Cache oder Teilnehmer abgerufen werden sollte.
  • Die Snoop-Phase ist die Phase, in der für Cache-Kohärenz gesorgt wird. Das Folgende ist eine beispielhafte Liste von Snoop-Signalen, die während der Snoop-Phase verwendet werden können: Beispielhafte Snoop-Signale
    Signal-Funktion Pin-Name Treiber
    Halten einer nicht-modifizierten Cache-Zeile HIT# Teilnehmer mit gemeinsamer Zeile (shared line)
    Treffer auf eine modifizierten Cache-Zeile HITM# Teilnehmer mit dirty Zeile (dirty line)
    Zurückstellen der Transaktions-Fertigstellung DEFER# antwortender Teilnehmer
  • In der Snoop-Phase steuern alle zwischenspeichernden Teilnehmer ihre Snoop-Ergebnisse an und nehmen an Cache-Kohärenz-Auflösung teil. Die Teilnehmer erzeugen von nahezu allen Speichertransaktionen, die nicht ihre eigenen sind, interne Snoop-Ergebnisse. Alle zwischenspeichernden Teilnehmer (snooping Teilnehmer) steuern ihre Snoop-Ergebnisse auf dem Bus in dieser Phase unter Verwendung der HIT#- und HITM#-Signale an. HIT# wird während der Snoop-Phase aktiv gesetzt, um anzuzeigen, dass eine Kopie einer Cache-Zeile, die die angeforderten Daten enthält, sich in einem anderen Cache eines Teilnehmers auf dieser Schnittstelle befindet. HITM# wird während der Snoop-Phase aktiv gesetzt, um anzuzeigen, dass eine modifizierte Kopie die Cache-Zeile, die die angefragten Daten enthält, sich in einem anderen Cache eines Teilnehmers auf dieser Schnittstelle befindet. Wenn HIT# und HITM# gleichzeitig durch ein Teilnehmer während einer Snoop-Phase aktiv gesetzt werden, dann ist ein Snoop-Stopp aufgetreten und die aktuelle Snoop-Phase sollte verlängert werden. DEFER# wird während der Snoop-Phase aktiv gesetzt, um anzuzeigen, dass nicht gewährleistet ist, dass die aktuelle Transaktion fertiggestellt wird.
  • In einigen Pentium Prozessoren werden die Snoop-Ergebnisse vier Taktzyklen, nachdem das ADS#-Signal aktiv gesetzt ist, und mindestens drei Taktzyklen von der Snoop-Phase der vorhergehenden Transaktion an angesteuert. Gemäß einer Ausführungsform werden jedoch diese minimalen Latenzzeiten modifiziert, um genauer mit der neuen Überlagerungsfrequenz des Prozessorbusses übereinzustimmen. Gemäß einer Ausführungsform können jetzt die Snoop-Ergebnisse drei Taktzyklen, nachdem das ADS#-Signal aktiv gesetzt wird (d. h. drei Bustaktzyklen nach dem Beginn der Request-Phase) und mindestens zwei Taktzyklen nach der Snoop-Phase der vorhergehenden Transaktion (d. h. mindestens zwei Taktzyklen, nachdem die Snoop-Ergebnisse auf dem Bus für die vorhergehende Transaktion angesteuert werden) angesteuert werden. Die maximale Aktivierungsrate für HIT#-/HITM#-/DEFER#-Signale (Snoop-Ergebnis) wird von einmal alle drei Bustaktzyklen auf einmal alle zwei Bustaktzyklen modifiziert. Beachte, dass die Latenzzeit vom Ende der Request-Phase (Teilphase B) zu der Snoop-Phase die gleiche verbleibt, da die Request-Phase um einen Zyklus verkürzt wird.
    • 4) Response-Phase: In dieser Phase steuern der Antwortteilnehmer die Transaktionsantwort auf dem Prozessorbus an. Anforderungen, die in der Request-Phase eingeleitet werden, gehen in eine ordentliche Warteschlange ein, die von jedem Busteilnehmer unterhalten wird. Der antwortende Teilnehmer ist der Teilnehmer, der für die Fertigstellung der Transaktion an der Spitze der ordentlichen Warteschlange verantwortlich ist. Der antwortende Teilnehmer ist die Vorrichtung oder der Teilnehmer, der während der Request-Phase durch die Transaktion adressiert wird. Nachstehend findet sich eine beispielhafte Gruppe von Signalen, die in der Response-Phase verwendet werden können:
    Beispielhafte Antwortsignale
    Typ Signal-Namen Anzahl
    Antwort-Status RS[2:0]# 3
    Antwort-Parität RSP# 1
    Ziel bereit TRDY# 1
  • Die Transaktionsantwort ist auf den RS[2:0]#-Signalen kodiert. Beispiele möglicher Antworten umfassen: eine normale Datenantwort (in der der antwortende Teilnehmer benötigt wird, gelesene Daten gleichzeitig mit der Antwort zu übertragen), eine Wiederholantwort (wenn DEFER# während der Snoop-Phase aktiv gesetzt ist, das anzeigt, dass die Transaktion wiederholt werden muss), eine aufgeschobene Antwort (wobei der Antwortteilnehmer oder antwortende Teilnehmer zusichert, die Transaktion in der Zukunft mit Einsatz der verzögerten Wiederholtransaktion fertigzustellen), eine keine-Daten-Antwort (wobei keine Daten durch den adressierte Teilnehmer rückübertragen werden), etc. TDRY# wird durch den antwortenden Teilnehmer aktiv gesetzt, um anzuzeigen, dass er bereit ist, Schreib- oder Rückschreib-Daten zu akzeptieren, etc. Die RSP#-Signale stellen die Parität für die RS-Signale bereit.
  • In einigen Pentium Prozessoren kann die Antwort nach einem Minimum von drei Bustaktzyklen nach der Response-Phase der vorhergehenden Transaktion angesteuert werden. Gemäß einer Ausführungsform, wird diese minimale Latenzzeit zwischen Response-Phase aufeinander folgender Transaktionen eingestellt, um mit der neuen Überlagerungsfrequenz des Prozessorbusses genauer übereinzustimmen. Gemäß einer Ausführungsform kann eine Antwort nach einem Minimum von zwei Bustaktzyklen nach der Antwort der vorhergehenden Transaktion angesteuert werden. Diese minimale Latenzzeit unterliegt typischerweise anderen Zwängen, die diese Latenzzeit verlängern können. Aufgrund des double-pumped Signalisierungsmodus, der für die Anforderungssignale verwendet wird, kann eine Antwort einmal alle zwei Bustaktzyklen (verglichen mit einmal alle drei Bustaktzyklen für einige Pentium Prozessoren) angesteuert werden.
  • Eine Transaktion, die durch eine Anforderung eingeleitet wird, ist eine Transaktion, bei der der Anforderungs-Teilnehmer Schreibdaten zu übertragen hat. Der adressierte Teilnehmer setzt TRDY# aktiv, um seine Fähigkeit anzuzeigen, Daten von dem Anforderungs-Teilnehmer zu empfangen, der beabsichtigt eine Schreiboperation durchzuführen. In einigen Pentium Prozessoren kann das TRDY#-Signal nach einem Minimum von drei Bustaktzyklen nach dem Aktiv-Setzen von ADS#-Signal für die gleiche Transaktion aktiv gesetzt werden. Es gibt typischerweise andere Zwänge, die diese Latenzzeit verlängern können. Diese Latenzzeit wird modifiziert, um genauer mit der neuen Überlagerungsfrequenz von Prozessorbus übereinzustimmen. Gemäß einer Ausführungsform kann der adressierte Teilnehmer das TRDY#-Signal nach einem Minimum von zwei Bustaktzyklen nach Aktiv-Setzen von ADS#-Signal für die gleiche Transaktion aktiv setzen. Beachte, dass die Latenzzeit von dem Ende der Request-Phase zu TRDY# unverändert bleibt.
    • 5) Daten-(Übertragungs-)Phase: Während der Daten-Phase werden Daten zwischen unterschiedlichen Busteilnehmern über den Prozessorbus 117 übertragen. Basierend auf der Request-Phase enthält eine Transaktion entweder eine ”Anforderungs-eingeleitete” (Schreib) Datenübertragung, eine ”Antwort-eingeleitete” (Schreib) Datenübertragung oder keine Datenübertragung. Die Daten-Phase kann mit der Request-Phase für eine Transaktion überlappen.
  • Nachstehend ist eine beispielhafte Liste von Signalen aufgeführt, die in der Daten-Phase verwendet werden können: Beispielhafte Datensignale
    Type Signal-Namen Anzahl
    Daten bereit DRDY# 1
    Datenbus beschäftigt DBSY# 1
    Datenabtastsignale DSTBp[3:0]# DSTBp[3:0]# 8
    Daten D[63:0]# 64
    Daten-Invertierung DINV[3:0]# 4
    Daten-Parität DP[3:0]# 4
  • DRDY# zeigt an, dass gültige Daten auf den Bus 117 gelegt sind und gespeichert werden müssen. Der Datenbusbesitzer setzt DRDY# für jeden Bustaktzyklus aktiv, in dem gültige Daten zu übertragen sind. DRDY# kann inaktiv gesetzt werden, um Wartezustände in die Daten-Phase einzufügen. DBSY# kann verwendet werden, den Datenbus vor dem ersten DRDY# Aktiv-Setzen und zwischen aufeinander folgenden DRDY# Aktiv-Setzen für eine vielfachen Bustakt-Datenübertragung anzuhalten. DINV[3:0]# werden verwendet, um anzuzeigen, dass die Datenbits durch die Datenquelle invertiert wurden.
  • Die Datensignale D[63:0]# des Datenbus 206 (2) stellen einen 64-Bit Datenpfad zwischen Busagenten bereit. Für eine teilweise Übertragung, die I/O Lesen und I/O Schreib-Transaktionen einschließt, bestimmt die Bytefreigabe (BE[7:0]#), welche Bytes des Datenbus die gültigen Daten enthalten werden.
  • Gemäß einer Ausführungsform können Daten unter Verwendung eines quad-pumped (d. h. 4×) Quell-synchron gespeicherten Protokolls übertragen werden, in dem die Datensignale D[63:0]# verwendet werden, um vier 8-Byte Datenelemente in einem einzelnen Bustaktzyklus zu übertragen. Die ersten 8-Bytes (in bündelweiser Anordnung) werden in dem ersten Viertel des Bustakts, das zweiten 8-Byte Element in dem zweiten Viertel von dem Bustakt, das dritten 8-Byte Element in dem dritten Viertel von dem Bustakt und das vierten 8-Byte Element in dem vierten Viertel von dem Bustakt übertragen. Die Daten können in dem ersten Viertel von dem Bustakt übertragen werden, wenn die zu übertragenen Daten eine Länge von 1 bis 8 Bytes aufweisen und die Daten können in den ersten zwei Vierteln von dem Bustakt übertragen werden, wenn die Daten eine Länge von 9–16 Bytes aufweisen.
  • Zahlreiche Ausführungsformen der vorliegenden Erfindung sind ausdrücklich dargestellt und/oder hier beschrieben.

Claims (71)

  1. Verfahren zum Übermitteln von Informationen über einen Mehrpunktbus von einem Treiberteilnehmer (802) zu einem oder mehreren Empfängerteilnehmern (832), umfassend: – Bereitstellen eines gemeinsamen Bustaktes (BCLK) sowohl dem Treiberteilnehmer (802) als auch dem einen oder den mehreren Empfängerteilnehmern (832); – Ausgeben einer Bustransaktion von dem Treiberteilnehmer (802) an den einen oder die mehreren Empfängerteilnehmer (832), umfassend: – Ansteuern vielfacher Adress-Informationselemente (Aa, Ab) durch den Treiberteilnehmer (802) für eine Anforderung (REQ) auf einem Adressbus (926) mit einer Rate, die ein Vielfaches der Frequenz des Bustaktes (BCLK) ist; – Aktivieren eines ersten Abtastsignals (ADSTB) durch den Treiberteilnehmer (802), um zu bestimmen, wann der eine oder die mehreren Empfängerteilnehmer (832) die Adress-Informationselemente (Aa, Ab) abtasten sollen, die auf dem Adressbus (926) angesteuert werden; – Ansteuern vielfacher Daten-Informationselemente (D1, D2, D3, D4) durch den Treiberteilnehmer (802) zum Übermitteln von Daten an den einen oder die mehreren Empfängerteilnehmer (832) auf einem Datenbus (826) mit einer Rate, die ein Vielfaches der Frequenz des Bustaktes (BCLK) aber Näher als die Rate des Adressbusses (926) ist, wobei mit der Anforderung (REQ), die eine Adresse und eine Datenlänge umfasst, mehrere Daten-Informationselemente (D1, D2, D3, D4) adressiert werden; und – Aktivieren eines zweiten Abtastsignals (DSTBp#, DSTBn#) durch den Treiberteilnehmer (802), um zu bestimmen, wann der eine oder die mehreren Empfängerteilnehmer (832) die Daten-Informationselemente (D1, D2, D3, D4) abtasten sollen, die auf dem Datenbus (826) angesteuert werden.
  2. Verfahren gemäß Anspruch 1, wobei der Treiberteilnehmer (802), der vielfache Adress-Informationselemente (Aa, Ab) für die Anforderung (RQE) auf dem Adressbus (926) ansteuert, den Treiberteilnehmer (802) umfasst, der mindestens zwei Adress-Informationselemente (Aa, Ab) für die Anforderung auf dem Adressbus (926) mit einer Rate ansteuert, die mindestens das Zweifache (2×) der Frequenz des Bustaktes (BCLK) ist.
  3. Verfahren gemäß Anspruch 2, wobei der Treiberteilnehmer (802), der vielfache Adress-Informationselemente (Aa, Ab) für eine Anforderung (REQ) auf dem Adressbus (926) ansteuert, den Treiberteilnehmer (802) umfasst, der zwei Adress-Informationselemente (Aa, Ab) für die Anforderung (REQ) auf einem Adressbus (926) mit einer Rate ansteuert, die das Zweifache (2×) der Frequenz des Bustaktes ist (BCLK).
  4. Verfahren gemäß Anspruch 2, wobei der Treiberteilnehmer (802), der vielfache Daten-Informationselemente (D1, D2, D3, D4) auf dem Datenbus (826) ansteuert, den Treiberteilnehmer (802) umfasst, der mindestens vier Daten-Informationselemente (D1, D2, D3, D4) auf dem Datenbus (826) mit einer Rate ansteuert, die mindestens das Vierfache (4×) der Frequenz des Bustaktes (BCLK) ist.
  5. Verfahren gemäß Anspruch 4, wobei der Treiberteilnehmer (802), der vielfache Daten-Informationselemente (D1, D2, D3, D4) auf dem Datenbus (826) ansteuert, den Treiberteilnehmer (802) umfasst, der vier Daten-Informationselemente (D1, D2, D3, D4) auf dem Datenbus (826) mit einer Rate ansteuert, die das Vierfache (4×) der Frequenz des Bustaktes (BCLK) ist.
  6. Verfahren gemäß Anspruch 1, wobei der Treiberteilnehmer (802), der ein zweites Abtastsignal (DSTBp#, DSTBn#) aktiviert, den Treiberteilnehmer (802) umfasst, der mindestens zwei phasenungleiche Abtastsignale (DSTBp#, DSTBn#) aktiviert, um zu bestimmen, wann der Empfängerteilnehmer (832) die Daten-Informationselemente (D1, D2, D3, D4) abtasten soll, die auf dem Datenbus (826) angesteuert werden.
  7. Verfahren gemäß Anspruch 6, wobei nur ein Flankentyp der Abtastsignale (DSTBp#, DSTBn#) verwendet wird, um zu bestimmen, wann der Empfängerteilnehmer (826) die Daten-Informationselemente (D1, D2, D3. D4) abtasten soll, die auf dem Datenbus (826) angesteuert werden.
  8. Verfahren gemäß einem der Ansprüche 1 bis 7, umfassend: – Bereitstellen einer Vielzahl von komplementären Abtastsignal-Paaren (DSTBp#, DSTBn#) in einer Daten-Phase; – Bereitstellen von vier Daten-Informationselementen (D1, D2, D3. D4) pro Bustaktzyklus (BCLK) durch den Treiberteilnehmer (802), die in einer Quell-synchronen Weise in Verbindung mit der Vielzahl von komplementären Abtastsignal-Paaren (DSTBp#, DSTBn#) übertragen werden.
  9. Verfahren gemäß Anspruch 8, wobei das Bereitstellen von vier Daten-Informationselementen (D1, D2, D3. D4) umfasst: – Bereitstellen eines ersten Daten-Informationselements (D1), das auf eine erste Flanke eines ersten Typs eines Ersten eines Paars von Datenabtastsignalen (DSTBp#, DSTBn#) synchronisiert ist; – Bereitstellen eines zweiten Daten-Informationselements (D2), das auf eine erste Flanke des ersten Typs eines Zweiten des Paars von Datenabtastsignalen (DSTBp#, DSTBn#) synchronisiert ist; – Bereitstellen eines dritten Daten-Informationselements (D3), das auf eine zweite Flanke des ersten Typs des Ersten des Paars von Datenabtastsignalen (DSTBp#, DSTBn#) synchronisiert ist; – Bereitstellen eines vierten Daten-Informationselements (D4), das auf eine zweite Flanke des ersten Typs eines Zweiten des Paars von Datenabtastsignalen (DSTBp#, DSTBn#) synchronisiert ist.
  10. Verfahren gemäß Anspruch 9, wobei der erste Typ von Flanke eine fallende Flanke ist.
  11. Verfahren gemäß einem der Ansprüche 8 bis 10, ferner umfassend. – Bereitstellen einer Vielzahl von Adressabtastsignalen (ADSTB); – Bereitstellen zweier Anforderungselemente und zweier Adresselemente (Aa, Ab) pro Bustaktzyklus, die in einer Quell-synchronen Weise in Verbindung mit der Vielzahl von Adressabtastsignalen (ADSTB) übertragen werden.
  12. Verfahren gemäß Anspruch 11, wobei die Bereitstellung zweier Anforderungselemente und zweier Adress-Informationselemente (Aa, Ab) umfasst: – Bereitstellen eines ersten Adress-Informationselements (Aa) und eines ersten Anforderungselements (REQa), die auf eine erste Flanke von mindestens einem der Vielzahl von Adressabtastsignalen (ADSTB) synchronisiert sind; – Bereitstellen eines zweiten Adress-Informationselements (Ab) und eines zweiten Anforderungselements (REQb), die auf eine zweite Flanke von dem mindestens einen der Vielzahl von Adressabtastsignalen (ADSTB) synchronisiert sind.
  13. Verfahren gemäß Anspruch 12, wobei die erste Flanke eine fallende Flanke eines Adressabtastsignals (ADSTB) ist und die zweite Flanke eine ansteigende Flanke eines Adressabtastsignals (ADSTB) ist.
  14. Verfahren gemäß einem der Ansprüche 1 bis 12, umfassend: – Aktiv-Setzen eines ersten Anforderungssignals (REQ) als ein Teil von einer ersten Arbitrierungs-Phase (ARB) von einer ersten Transaktion; – Aktiv-Setzen eines zweiten Anforderungssignals (REQ) als ein Teil von einer zweiten Request-Phase (REQ) von der zweiten Transaktion in einer pipelineartigen Weise vor Beendigung von der ersten Transaktion; – Aktiv-Setzen des Adressabtastsignals (ADSTB) als ein Teil einer Request-Phase von der ersten Transaktion; – Empfangen eines Signals zum Blockieren einer nächsten Anforderung (BRN) zwei Bustaktzyklen nach dem Aktiv-Setzen des Adressabtastsignals (ADSTB); und – Antworten auf das Signal zum Blockieren einer nächsten Anforderung (BNR).
  15. Verfahren gemäß Anspruch 14, wobei das erste Anforderungssignal durch einen ersten Busteilnehmer aktiv gesetzt wird und wobei das zweite Anforderungssignal durch einen zweiten Busteilnehmer aktiv gesetzt wird.
  16. Verfahren gemäß Anspruch 14, wobei das erste Anforderungssignal und das zweite Anforderungssignal durch einen ersten Busteilnehmer aktiv gesetzt werden.
  17. Verfahren gemäß Anspruch 14, wobei Antworten umfasst: – Überführen in einen Stopp-Zustand (STALL) und danach Verbleiben in dem Stopp-Zustand, wenn das Signal zum Blockieren einer nächsten Anforderung (BNR) an einem Abtastpunkt für das Signal zum Blockieren einer nächsten Anforderung (BNR) alle zweit Takte aktiv gesetzt verbleibt, wobei der Stopp-Zustand (STALL) den Busteilnehmer vom Ausgeben von Busanforderungen abhält.
  18. Verfahren gemäß Anspruch 14, wobei das Antworten umfasst: – Überführen von einem freien Zustand in einen Drossel-Zustand (THROTTLE), wenn der Busteilnehmer sich in dem freien Zustand befand, wenn das Signal zum Blockieren einer nächsten Anforderung (BNR) empfangen wurde; – Oberführen von dem Drossel-Zustand (THROTTLE) in einen Stopp-Zustand (STALL), wenn das Signal zum Blockieren einer nächsten Anforderung (BNR) zwei Takte später aktiv gesetzt verbleibt; – Verbleiben in dem Drossel-Zustand (THROTTLE), wenn das Signal zum Blockieren einer nächsten Anforderung (BNR) an einem Abtastpunkt des Signals zum Blockieren einer nächsten Anforderung (BNR) alle zwei Takte aktiv gesetzt verbleibt, wobei der Stopp-Zustand (STALL) den Busteilnehmer vom Ausgeben von Busanforderungen abhält.
  19. Verfahren gemäß einem der Ansprüche 1 bis 18, ferner umfassend: – Initiieren einer ersten Request-Phase für eine erste Transaktion; – Initiieren einer zweiten Request-Phase für eine zweite Transaktion in einer pipelineartigen Weise vor Fertigstellung der ersten Transaktion, wobei die zweite Request-Phase für die zweite Transaktion zwei Buszyklen nach der ersten Request-Phase für die erste Transaktion initiiert wird gemessen an einem Aktiv-Setzen eines zweiten Adressabtastsignals (ASTB) für die zweite Transaktion, das zwei Buszyklen nach einem Aktiv-Setzen eines ersten Adressabtastsignals (ASTB) auftritt.
  20. Verfahren gemäß Anspruch 19, wobei das Bereitstellen von zwei Anforderungselementen (REQa, REQb) und zwei Adress-Informationselementen (Aa, Ab) umfasst: – Bereitstellen eines ersten Adress-Informationselements (Aa) und eines ersten Anforderungselements (REQa), die auf eine erste Flanke von mindestens einer von der Vielzahl von Adressabtastsignalen (ADSTB) synchronisiert sind; – Bereitstellen eines zweiten Adress-Informationselements (Ab) und eines zweiten Anforderungselements (REQb), die auf eine zweite Flanke von mindestens einem von der Vielzahl von Adressabtastsignalen (ADSTB) synchronisiert sind.
  21. Verfahren gemäß einem der Ansprüche 1 bis 20, wobei der Bus in zwei Signalisierungsmodi für unterschiedliche Typen von Signalen betreibbar ist, wobei der Bus einen bidirektionalen Mehrpunkt-Adressbus (926) und einen bidirektionalen Mehrpunkt-Datenbus (826) einschließt, wobei die Signalisierungsmodi einschließen: – einen Signalisierungsmodus mit einem gemeinsamen Takt, in dem Signale auf dem Bus mit einer Rate angesteuert werden können, die im Wesentlichen gleich der Frequenz des Bustaktes (BCLK) ist, wobei der Bustakt (BCLK) Punkte bestimmt, um Informationselemente abzutasten, die in dem Signalisierungsmodus angesteuert werden; und – einen multi-pumped Signalisierungsmodus, in dem Informationselemente durch einen Treiberteilnehmer (802) auf mindestens einem von entweder dem Adressbus (926) oder dem Datenbus (826) mit einer Rate angesteuert werden können, die ein Vielfaches der Frequenz des Bustaktes (BCLK) ist und in dem ein oder mehrere Abtastsignale (ADSTB, DSTBp#, DSTBp#) durch den Treiberteilnehmer (802) aktiviert werden, um Abtastpunkte für Informationselemente zu bestimmen, die in dem multi-pumped Signalisierungsmodus angesteuert werden.
  22. Verfahren gemäß Anspruch 21, wobei nur ein Flankentyp des einen oder der mehreren Abtastsignale (DSTBp#, DSTBp#) verwendet wird, um Abtastpunkte für die Informationselemente zu bestimmen.
  23. Verfahren gemäß Anspruch 21, wobei das eine oder die mehreren Abtastsignale (ADSTB, DSTBp#, DSTBp#) eine Vielzahl von Abtastsignalen (DSTBp#, DSTBp#) umfassen, wobei die Vielzahl von Abtastsignalen (DSTBp#, DSTBp#) in einer phasenungleichen oder gestaffelten Anordnung aktiviert werden.
  24. Verfahren gemäß Anspruch 21, wobei das eine oder die mehreren Abtastsignale (ADSTB, DSTBp#, DSTBp#) Abtastpunkte bestimmen, die im Wesentlichen zu jedem der Informationselemente mittig angeordnet sind.
  25. Busteilnehmer, umfassend: eine Steuerschnittstelle, an der ein gemeinsamer Bustakt bereitgestellt wird; eine Adressbus-Schnittstelle, über die der Treiberteilnehmer (802) eine Anforderung (REQ) auf dem Adressbus (926) unter Verwendung eines multi-pumped Signalisierungsmodus ansteuern kann, indem Adress-Informationselemente (Aa, Ab) von der Anforderung (REQ) mit einer Rate übertragen werden, die ein Vielfaches einer Frequenz des Bustaktes (BCLK) ist, und indem der Treiberteilnehmer (802) temporär ein Adressabtastsignal (ADSTB) auf einer Adress-Abtastsignalleitung (920) aktivieren kann, um Abtastpunkte für die Adress-Informationselemente (Aa, Ab) zu bestimmen, die auf einen Adressbus (926) angesteuert werden; und eine Datenbus-Schnittstelle, über die der Treiberteilnehmer (802) Daten unter Verwendung eines multi-pumped Signalisierungsmodus übertragen kann, indem Daten-Informationselemente (D1, D2, D3, D4) durch den Treiberteilnehmer (802) auf einem Datenbus (826) mit einer Rate betrieben werden, die ein Vielfaches der Frequenz des Bustaktes (BCLK) aber höher als die Rate des Adressbusses (926) ist, wobei die Anforderung (REQ), die eine Adresse und eine Datenlänge umfasst, mehrere Daten-Informationselemente (D1, D2, D3, D4) adressieren kann, und indem der Treiberteilnehmer (802) ebenfalls temporär eine Vielzahl von Daten-Abtastsignalen (DSTBp#, DSTBn#) in einer gestaffelten oder versetzten Anordnung auf einer Vielzahl von Daten-Abtastsignalleitungen (820, 822) aktivieren kann, um Abtastpunkte zum Abtasten von Daten-Informationselementen (D1, D2, D3, D4) zu bestimmen
  26. Busteilnehmer nach Anspruch 25, wobei die Steuerschnittstelle, die Adressbus-Schnittstelle und die Datenbus-Schnittstelle geeignet sind, in zumindest einer Arbitrierungs-Phase, Request-Phase und Snoop-Phase zu arbeiten.
  27. Busteilnehmer nach Anspruch 26, wobei die Steuerschnittstelle, die Datenbus-Schnittstelle und die Adressbus-Schnittstelle geeignet sind, Transaktionen in einer pipelineartigen Weise bereitzustellen.
  28. Busteilnehmer nach Anspruch 25, wobei das erste Vielfache ein Zweifaches (2×) der Taktfrequenz (BCLK) ist und das zweite Vielfache der Taktfrequenz eine Vierfaches (4×) der Taktfrequenz (BCLK) ist.
  29. Busteilnehmer gemäß Anspruch 25, wobei die Adressbus-Schnittstelle einen mittig angeordneten Adressabtastsignal-Übergang für jedes Adresselement (Aa, Ab) ansteuert, wobei die Datenbus-Schnittstelle einen mittig angeordneten Datenabtastsignal-Übergang für jedes Datenelement (D1, D2, D3, D4) ansteuert.
  30. Busteilnehmer nach Anspruch 29, wobei die Datenbus-Schnittstelle zum Erzeugen von ersten, zweiten, dritten und vierten Datenelementen (D1, D2, D3, D4) in einer ersten Signalerzeugungs-Zeitperiode angepasst ist, und wobei die Adressbus-Schnittstelle zum Erzeugen von ersten und zweiten Adresselementen (Aa, Ab) in einer zweiten Signalerzeugungs-Zeitperiode angepasst ist, wobei die erste Signalerzeugungs-Zeitperiode und die zweite Signalerzeugungs-Zeitperiode jeweils gleich einem Takt des Taktsignals (BCLK) sind, wobei: eine erste Flanke eines ersten Datenabtastsignals (DSTBp#) an einem 12,5-Prozentpunkt der ersten Signalerzeugungs-Zeitperiode anzuordnen ist; eine erste Flanke eines zweiten Datenabtastsignals (DSTBn#) an einem 37,5-Prozentpunkt der ersten Signalerzeugungs-Zeitperiode anzuordnen ist; eine zweite Flanke des ersten Datenabtastsignals (DSTBp#) an einem 67,5-Prozentpunkt der ersten Signalerzeugungs-Zeitperiode anzuordnen ist; eine zweite Flanke des zweiten Datenabtastsignals (DSTBn#) an einem 87,5-Prozentpunkt der ersten Signalerzeugungs-Zeitperiode anzuordnen ist; das erste Datenelement (D1) zu Beginn der ersten Signalerzeugungs-Zeitperiode zu erzeugen ist; das zweite Datenelement (D2) an einem 25-Prozentpunkt der ersten Signalerzeugungs-Zeitperiode zu übertragen ist; das dritte Datenelement (D3) an einem 50-Prozentpunkt der ersten Signalerzeugungs-Zeitperiode zu übertragen ist; das vierte Datenelement (D4) an einem 75-Prozentpunkt der ersten Signalerzeugungs-Zeitperiode zu übertragen ist; eine erste Flanke eines Adressabtastsignals (ADSTB) bei 25 Prozent der zweiten Signalerzeugungs-Zeitperiode anzuordnen ist; eine zweite Flanke des Adressabtastsignals (ADSTB) bei 75 Prozent der zweiten Signalerzeugungs-Zeitperiode anzuordnen ist; das erste Adresselement (Aa) zu Beginn der zweiten Signalerzeugungs-Zeitperiode zu übertragen ist; und das zweite Adresselement (Ab) bei 50 Prozent der zweiten Signalerzeugungs-Zeitperiode zu übertragen ist.
  31. Busteilnehmer nach Anspruch 29, wobei die Adressbus-Schnittstelle zum Ansteuern des Adressabtastsignals (ADSTB) mit der Taktfrequenz vorgesehen ist, wobei das erste Adressabtastsignals (ADSTB) einen ersten Adressabtastsignal-Übergang einer ersten Polarität aufweist, um mittig zu einem ersten Adresselement (Aa) angeordnet zu sein, und einen zweiten Adressabtastsignals-Übergang einer zweiten Polarität aufweist, um mittig zu einem zweiten Adresselement (Ab) angeordnet zu sein, wobei das zweite Adresselement (Ab) dem ersten Adresselement (Aa) folgt, und wobei die Datenbus-Schnittstelle zum Ansteuern von vier aufeinanderfolgenden Datenelementen (D1, D2, D3, D4) und eines ersten Datenabtastsignals (DSTBp#) und eines zweiten Datenabtastsignals (DSTBn#) angepasst ist, und wobei eine erste Flanke eines ersten Typs des ersten Datenabtastsignals (DSTBp#) mit einem ersten Datenelement (D1) mittig anzuordnen ist, wobei eine erste Flanke der ersten Polarität des zweiten Datenabtastsignals (DSTBn#) mittig mit dem zweiten Datenelement (D2) anzuordnen ist, eine zweite Flanke des ersten Typs des ersten Datenabtastsignals (DSTBp#) mittig mit dem dritten Datenelement (D3) anzuordnen ist und eine zweite Flanke des ersten Typs des zweiten Datenabtastsignals (DSTBn#) mittig mit einem vierten Datenelement (D4) anzuordnen ist.
  32. Busteilnehmer gemäß Anspruch 25, ferner umfassend: eine Adress-Erzeugungslogik mm Ansteuern von zwei Adresselementen (Aa, Ab) während einer Dauer eines Takts des Taktsignals (BCLK), wobei die Adress-Erzeugungslogik zum Erzeugen eines ersten Adressabtastsignals (ADSTB) angepasst ist, um einen ersten Adressabtastsignal-Übergang bei einer Erst-Adresselement-Mitte eines Ansteuerfensters des ersten Adresselements (Aa) aufzuweisen, in dem die ersten Adresselemente angesteuert werden, wobei die Adress-Erzeugungslogik zum Erzeugen des Adressabtastsignals (ADSTB) vorgesehen ist, um einen zweiten Übergang bei einer Zweit-Adresselement-Mitte eines Ansteuerfensters des zweiten Adresselements (Ab) aufzuweisen, in dem die zweiten Adresselemente (Ab) angesteuert werden; und eine Daten-Erzeugungslogik zum Ansteuern von vier Datenelementen (D1, D2, D3, D4) während einer zweiten Dauer eines Takts des Taktsignals, wobei die Daten-Erzeugungslogik zum Erzeugen eines ersten Datenabtastsignals (DSTBp#) vorgesehen ist, um einen ersten Übergang des ersten Datenabtastsignals (DSTBp#) bei einer Erst-Datenelement-Mitte eines Ansteuerfensters des ersten Datenelements (D1) aufzuweisen, in dem das erste Datenelement (D1) angesteuert wird, und wobei die Daten-Erzeugungslogik zum Erzeugen eines zweiten Datenabtastsignals (DSTBn#) vorgesehen ist, um einen ersten Übergang des zweiten Datenabtastsignals (DSTBn#) bei einer Zweit-Datenelement-Mitte eines Ansteuerfensters des zweiten Datenelements (D2) aufzuweisen, in dem ein zweites Datenelement (D2) angesteuert wird, und wobei die Daten-Erzeugungslogik zum Erzeugen des ersten Datenabtastsignals (DSTBp#) vorgesehen ist, um einen zweiten Übergang des ersten Datenabtastsignals (DSTBp#) bei einer Dritt-Datenelement-Mitte eines Ansteuerfensters des dritten Datenelements (D3) aufzuweisen, in dem das dritte Datenelement (D3) angesteuert wird, und wobei die Daten-Erzeugungslogik zum Erzeugen des zweiten Datenabtastsignals (DSTBn#), vorgesehen ist, um einen zweiten Übergang des zweiten Datenabtastsignals (DSTBn#) bei einer Viert-Datenelement-Mitte eines Ansteuerfensters des vierten Datenelements (D4) aufzuweisen, in dem ein viertes Datenelement (D4) angesteuert wird.
  33. Busteilnehmer nach Anspruch 32, wobei ein erster Übergang des ersten Datenabtastsignals (DSTBp#) und ein zweiter Übergang des ersten Datenabtastsignals (DSTBp#) von einer ersten Polarität sind und das erste Datenabtastsignal (DSTBp#) einen Übergang entgegengesetzter Polarität nach dem ersten Übergang des ersten Datenabtastsignals (DSTBp#) und vor dem zweiten Übergang des ersten Datenabtastsignals (DSTBp#) aufweist.
  34. Busteilnehmer nach Anspruch 32, wobei das erste Datenabtastsignal (DSTBp#) und das zweite Datenabtastsignal (DSTBn#) eine Frequenz von dem Zweifachen (2×) der Bus-Taktsignalfrequenz (BCLK) aufweisen.
  35. Busteilnehmer nach Anspruch 32, wobei die ersten und zweiten Übergänge der ersten und zweiten Datenabtastsignale (DSTBp#, DSTBn#) alle entweder ansteigende oder fallende Flanken sind.
  36. Busteilnehmer nach Anspruch 33, wobei der erste Adressabtastsignal-Übergang von einem entweder ansteigenden oder fallenden ersten Typ ist und der zweite Adressabtastsignal-Übergang von einem zweiten Typ ist, der der Andere der Ansteigenden oder Fallenden ist, entgegengesetzt zu dem ersten Adressabtastsignal-Übergang.
  37. Busteilnehmer nach Anspruch 36, wobei die Steuerschnittstelle vorgesehen ist, ein gemeinsames Taktsteuersignal in einer Adress-Phase zu übertragen, die ebenso ein Erzeugen der zwei Adresselemente (Aa, Ab) umfasst, und ein zweites gemeinsames Taktsteuersignal in einer Daten-Phase zu erzeugen, die ebenso ein Ansteuern der vier Datenelemente (D1, D2, D3, D4) umfasst.
  38. Busteilnehmer gemäß Anspruch 25, ferner umfassend: eine Vielzahl von Datenpins; eine Vielzahl von Adresspins; einen Adress-Abtastsignalpin; eine Adress-Abtastsignal-Erzeugungslogik zum Erzeugen eines Adressabtastsignals (ADSTB) an dem Adress-Abtastsignalpin, das eine Adress-Abtastsignalfrequenz aufweist, die ein Vielfaches der Bus-Taktfrequenz (BCLK) ist; und eine Adress-Übermittlungslogik zum Übermitteln der Adresselemente an die Vielzahl von Adresspins, wobei die Adresselemente (Aa, Ab) mit vorbestimmten Flanken des Adressabtastsignals (ADSTB) synchronisiert sind.
  39. Vorrichtung zum Übermitteln von Informationen, umfassend: – eine Vielzahl von Teilnehmern (802, 832), wobei mindestens einer von den Teilnehmern (802, 832) ein Busteilnehmer (802) nach Anspruch 25 ist; – ein bidirektionaler Mehrpunkt-Bus, der mit den Teilnehmern (802, 832) verbunden ist, wobei der Bus einen Steuerbus, einen Adressbus (926) und einen Datenbus (826) einschließt, wobei der Steuerbus eine gemeinsame Bustaktleitung, die an alle Teilnehmer einen gemeinsamen Bustakt bereitstellt, eine Adressabtastsignalleitung (920) und eine Vielzahl von Datenabtastsignalleitungen (820, 822) einschließt.
  40. Vorrichtung gemäß Anspruch 39, wobei der Treiberteilnehmer (802) ferner umfasst: – eine Vielzahl von Datenpins; – eine Vielzahl von Daten-Abtastsignalpins; – eine Vielzahl von Adresspins; – einen Adress-Abtastsignalpin; – einen Pin für einen gemeinsamen Takt für das Bustaktsignal (BCLK) mit der Bustaktfrequenz; – eine Daten-Abtastsignal-Erzeugungslogik, um ein erstes Datenabtastsignal (DSTBp#) und ein zweites Datenabtastsignal (DSTBn#) an einem ersten Daten-Abtastsignalpin und einem zweiten Daten-Abtastsignalpin zu erzeugen, wobei das erste Datenabtastsignal (DSTBp#) und das zweite Datenabtastsignal (DSTBn#) eine Daten-Abtastsignalfrequenz von dem Zweifachen (2×) der Bustaktfrequenz (BCLK) aufweisen; – eine Adress-Abtastsignal-Erzeugungslogik, um ein erstes Adressabtastsignal (ADSTB) an dem Adress-Abtastsignalpin mit einer Adress-Abtastsignalfrequenz zu erzeugen, die die Gleiche ist wie die Bustaktfrequenz (BCLK); – eine Daten-Übermittlungslogik, um Daten-Informationselemente (D1, D3), die auf eine erste Flanke des ersten Datenabtastsignals (DSTBp#) synchronisiert sind, an der Vielzahl von Datenpins zu übermitteln, und Daten-Informationselemente (D2, D4), die auf eine erste Flanke des zweiten Datenabtastsignals (DSTBn#) synchronisiert sind, ebenfalls an der Vielzahl von Datenpins zu übermitteln; – eine Adress-Übermittlungslogik, um Adresselemente (Aa), die auf eine erste Flanke des Adressabtastsignals (ADSTB) synchronisiert sind, an der Vielzahl von Adresspins zu übermitteln, und um Adresselemente (Ab), die auf eine zweite Flanke des Adressabtastsignals (ADSTB) synchronisiert sind, ebenfalls an der Vielzahl von Adresspins zu übermitteln.
  41. Vorrichtung gemäß Anspruch 40, die ferner umfassen: – eine Vielzahl von Anforderungspins; wobei die Adress-Übermittlungslogik angepasst ist, Anforderungselemente (REQa), die auf eine erste Flanke des ersten Adressabtastsignals (ADSTB) synchronisiert sind, an der Vielzahl von Anforderungspins zu übermitteln, und Anforderungselemente (REQb), die auf eine zweite Flanke des ersten Adressabtastsignals (ADSTB) synchronisiert sind, ebenfalls an der Vielzahl von Anforderungspins zu übermitteln.
  42. Vorrichtung gemäß Anspruch 41, wobei der Busteilnehmer (802) angepasst ist, ein Paar von Abtastsignalen (DSTBp#, DSTBn#) an jeden von sechzehn Datenpins zu liefern, und angepasst ist, zwei Adressabtastsignale (ADSTB) zu liefern, ein für jeden von zwei Teilsätzen der Vielzahl von Adresspins und der Vielzahl von Anforderungspins.
  43. Vorrichtung gemäß Anspruch 41, wobei die erste Flanke des ersten Datenabtastsignals (DSTBp#) eine fallende Flanke ist und wobei die erste Flanke des zweiten Datenabtastsignals (DSTBn#) eine fallende Flanke ist.
  44. Vorrichtung gemäß Anspruch 41, wobei das erste Datenabtastsignal (DSTBp#) und das zweite Datenabtastsignal (DSTBn#) komplementäre Abtastsignale sind.
  45. Vorrichtung gemäß Anspruch 44, das ferner umfasst: – eine Vielzahl von Steuerpins, um unter Verwendung eines Protokolls mit einem gemeinsamen Takt zu kommunizieren, vorzugsweise um eine Vielzahl von Signalen zu übertragen, die vorgesehen sind, synchron mit dem Bustaktsignal angesteuert zu werden.
  46. Vorrichtung gemäß Anspruch 41, wobei das Adressabtastsignal (ADSTB) zwei im Wesentlichen identische Adressabtastsignale umfasst.
  47. Vorrichtung gemäß Anspruch 46, wobei ein Erstes der zwei im Wesentlichen identischen Adressabtastsignale an einen ersten Teilsatz der Vielzahl von Adresspins und der Vielzahl von Anforderungspins synchronisiert übertragen wird, und wobei ein Zweites der zwei identischen Adressabtastsignale an einen zweiten Teilsatz der Vielzahl von Adresspins und der Vielzahl von Anforderungspins synchronisiert übertragen wird, wobei der zweite Teilsatz aus verbleibenden der Vielzahl von Adresspins und der Vielzahl von Anforderungspins besteht, die nicht in dem ersten Teilsatz sind.
  48. Vorrichtung gemäß Anspruch 40, die ferner umfasst: – eine Daten-Abtastsignal-Empfangslogik, um ein drittes Datenabtastsignal und ein viertes Datenabtastsignal an dem ersten Daten-Abtastsignalpin und dem zweiten Daten-Abtastsignalpin zu empfangen, wobei das drittes Datenabtastsignal und das vierte Datenabtastsignal die Daten-Abtastsignalfrequenz von dem Doppelten (2×) der Bustaktfrequenz (BCLK) aufweisen; – eine Adress-Abtastsignal-Empfangslogik, um ein zweites Adressabtastsignal an dem Adress-Abtastsignalpin mit der Adress-Abtastsignalfrequenz zu empfangen, die die Gleiche wie die Bustaktfrequenz (BCLK) ist; – eine Daten-Empfangslogik, um Daten-Informationselemente, die auf eine erste Flanke des dritten Datenabtastsignals synchronisiert sind, an der Vielzahl von Datenpins zu empfangen, und um Daten-Informationselemente, die auf eine erste Flanke des vierten Datenabtastsignals synchronisiert sind, ebenfalls an der Vielzahl von Datenpins zu empfangen; – eine Adress-Empfangslogik, um Adresselemente, die auf eine erste Flanke des zweiten Adressabtastsignals synchronisiert sind, an der Vielzahl von Adresspins zu empfangen, und um Adresselemente, die auf eine zweite Flanke des zweiten Adressabtastsignals synchronisiert sind, ebenfalls an der Vielzahl von Adresspins zu empfangen.
  49. Vorrichtung gemäß Anspruch 46, wobei der Busteilnehmer irgendeiner von einem oder mehreren von einem Satz von Busteilnehmern (802, 832) ist, bestehend aus: – einem Chipsatz; – einem Prozessor; – einer Speicher-Steuereinheit; – einem zentralen Teilnehmer; – einem I/O Teilnehmer.
  50. Vorrichtung gemäß einem der Ansprüche 40 bis 49, umfassend: – die Vielzahl von Datenpins, die vorzugsweise Datenpins D[63:0] einschließen; – die Daten-Abtastsignal-Erzeugungslogik, um vier Paare an Datenabtastsignalen zu erzeugen, wobei jedes der vier Paare von Datenabtastsignalen ein erstes Datenabtastsignal und ein zweites Datenabtastsignal aufweist, wobei das erste Datenabtastsignal und das zweite Datenabtastsignal von jedem der Paare von Datenabtastsignalen eine Daten-Abtastsignalfrequenz von dem Doppelten der Bustaktfrequenz (BCLK) aufweisen; – die Daten-Übermittlungslogik, um für jedes der vier Paare von Datenabtastsignalen und auf verschiedenen Teilsätzen der Vielzahl von Datenpins zu übermitteln: – erste Daten-Informationselemente, die auf eine fallende Flanke des ersten Datenabtastsignals synchronisiert sind, an einem Teilsatz der Vielzahl von Datenpins; – zweite Daten-Informationselemente, die auf eine fallende Flanke des zweiten Datenabtastsignals synchronisiert sind, ebenfalls an dem Teilsatz der Vielzahl von Datenpins.
  51. Vorrichtung gemäß Anspruch 50, ferner umfassend: – die Adress-Übermittlungslogik, um erste Adresselemente, die auf eine fallende Flanke des Adressabtastsignals synchronisiert sind, an der Vielzahl von Adresspins zu übermitteln, und zweite Adresselemente, die auf eine ansteigende Flanke des Adressabtastsignals synchronisiert sind, ebenfalls an der Vielzahl von Adresspins zu übermitteln.
  52. Vorrichtung gemäß Anspruch 51, ferner umfassend: – eine Vielzahl von Anforderungspins, die vorzugsweise Anforderungspins REQ[3:0] umfassen; – die Adress-Übermittlungslogik, um ebenfalls erste Anforderungselemente, die auf die fallende Flanke des Adressabtastsignals synchronisiert sind, an der Vielzahl von Anforderungspins zu übermitteln, und um zweite Anforderungselemente, die auf die ansteigende Flanke des Adressabtastsignals synchronisiert sind, ebenfalls an der Vielzahl von Anforderungspins zu übermitteln.
  53. Vorrichtung gemäß Anspruch 52, wobei die Vielzahl von Steuerpins Pins für einen Satz von Signalen umfasst, die einschließen: – ADS#; – BNR#; – BPRI#; – mindestens einen Busanforderungspin; – DBSY#; – DEFER#; – DP[3:0]#; – DRDY#; – HIT#; – HITM#; – INIT#; und – TRDY#.
  54. Vorrichtung gemäß einem der Ansprüche 40 bis 53, ferner umfassend: – einen Pin für ein Signal zum Blockieren einer nächsten Anforderung (BNR); – eine Arbitrierungs-Logik, die in der Lage ist, eine Arbitrierungs-Phase (ARB) nach zwei Takten einer vorherigen Arbitrierungs-Phase (ARB) einzuleiten, und die in der Lage ist, ein Signal zum Blockieren einer nächsten Anforderung (BNR) an dem Pin für das Signal zum Blockieren einer nächsten Anforderung (BNR) zu empfangen, das zwei Bustaktzyklen nach Aktiv-Setzen des Adressabtastsignals (ADSTB) an dem Adress-Abtastsignalpin auftritt, und die in der Lage ist, auf das Signal zum Blockieren einer nächsten Anforderung (BNR) zu antworten.
  55. Vorrichtung gemäß Anspruch 54, wobei die Arbitrierungs-Logik vorgesehen ist, um auf das Signal zum Blockieren einer nächsten Anforderung (BNR) durch Überführen in einen Stoppzustand (STALL) zu antworten und danach in dem Stopp-Zustand (STALL) zu verbleiben, wenn das Signal zum Blockieren einer nächsten Anforderung (BNR) aktiv gesetzt verbleibt, wobei der Stopp-Zustand (STALL) den Busteilnehmer vom Ausgeben von Busanforderungen abhält.
  56. Vorrichtung gemäß Anspruch 54, wobei der Busteilnehmer (802) ein Prioritätsteilnehmer ist, wobei der Prioritätsteilnehmer ferner umfasst: – einen Busanforderungspin eines Prioritätsteilnehmers, wobei die Arbitrierungs-Logik in der Lage ist, ein Busanforderungssignal eines Prioritätsteilnehmers mit einer minimalen Zeit für Inaktiv-Setzen von einem Bustaktzyklus aktiv zu setzen.
  57. Vorrichtung gemäß Anspruch 56, wobei die Arbitrierungs-Logik vorgesehen ist, um auf das Signal zum Blockieren einer nächsten Anforderung (BNR) durch Überführen von einem freien Zustand in einen Drossel-Zustand (THROTTLE) zu antworten, wenn der Busteilnehmer (802) sich in dem freien Zustand befand, als das Signal zum Blockieren einer nächsten Anforderung (BNR) empfangen wurde, und durch Überführen von dem Drossel-Zustand (THROTTLE) in einen Stopp-Zustand (STALL) zu antworten, wenn das Signal zum Blockieren einer nächsten Anforderung zwei Takte später aktiv gesetzt verbleibt und danach in dem Stopp-Zustand (STALL) zu verbleiben, wenn das Signal zum Blockieren einer nächsten Anforderung (BNR) an dem Abtastpunkt zum Blockieren einer nächsten Anforderung (BNR) alle zwei Takte aktiv gesetzt verbleibt, wobei der Stopp-Zustand (STALL) den Busteilnehmer (802) vom Ausgeben von Busanforderungen abhält.
  58. Vorrichtung gemäß Anspruch 56, umfassend: – eine Request-Logik, die in der Lage ist, eine zweite Request-Phase für eine zweite Transaktion zwei Takte nach einer ersten Request-Phase für eine erste Transaktion einzuleiten, indem eine Vielzahl von Anforderungssignalen an der Vielzahl von Anforderungssignalpins aktiv gesetzt wird und ein Adressabtastsignal der zweiten Transaktion an dem Adress-Abtastsignalpin für die zweite Transaktion zwei Buszyklen nach dem Aktiv-Setzen eines ersten Adressabtastsignal der ersten Transaktion an dem Adress-Abtastsignalpin für die erste Transaktion auftritt; – Adress- und Anforderungs-Übermittlungs-Logik, um eine Vielzahl von Anforderungssignalen und eine Vielzahl von Adresssignalen bei einem Vielfachen von einer Bustaktfrequenz (BCLK) in einer Quell-synchronen Weise zu übermitteln.
  59. Vorrichtung gemäß Anspruch 58, wobei nur eine Flanke der Datenabtastsignale (DSTBp#, DSTBn#) verwendet wird, um Abtastpunkte zum Abtasten der Daten-Informationselemente (D1, D2, D3, D4) zu bestimmen.
  60. Vorrichtung gemäß Anspruch 59, wobei die eine Flanke der Datenabtastsignale (DSTBp#, DSTBn#), um Abtastpunkte für die Daten-Informationselemente (D1, D2, D3, D4) zu bestimmen, nur die ansteigende Flanke der Datenabtastsignale (DSTBp#, DSTBn#) einschließt.
  61. Vorrichtung gemäß Anspruch 59, wobei die eine Flanke der Datenabtastsignale (DSTBp#, DSTBn#), um Abtastpunkte für die Daten-Informationselemente zu bestimmen, nur die fallende Flanke der Datenabtastsignale (DSTBp#, DSTBn#) einschließt.
  62. Vorrichtung gemäß Anspruch 59, wobei die Daten-Informationselemente (D1, D2, D3, D4) durch den Treiberteilnehmer (802) auf dem Datenbus (826) mit einer Rate betrieben werden, die mindestens das Vierfache (4×) der Frequenz des Bustaktes (BCLK) ist.
  63. System, umfassend: einen Bus umfassend: – eine Vielzahl von Datenleitungen (826); – eine Vielzahl von Daten-Abtastsignalleitungen (820, 822); – eine Vielzahl von Adressleitungen (926); – eine Adress-Abtastsignalleitung (920); – eine Bustaktleitung; einen ersten Teilnehmer (802) gemäß Anspruch 25, ferner umfassend: – eine Vielzahl von Datenpins des ersten Teilnehmers (802), die mit der Vielzahl von Datenleitungen (826) verbunden ist; – eine Vielzahl von Daten-Abtastsignalpins des ersten Teilnehmers (802), die mit der Vielzahl von Daten-Abtastsignalleitungen (820, 822) verbunden ist; – eine Vielzahl von Adresspins des ersten Teilnehmers (802), die mit der Vielzahl von Adressleitungen (926) verbunden ist; – ein Adress-Abtastsignalpin des ersten Teilnehmers (802), der mit der Adress-Abtastsignalleitung (920) verbunden ist; – einen Pin für einen gemeinsamen Takt des ersten Teilnehmers (802), der verbunden ist, um ein Bustaktsignal mit der Frequenz des Bustaktes zu empfangen; einen zweiten Teilnehmer (832), umfassend – eine Vielzahl von Datenpins des zweiten Teilnehmers (832), die mit der Vielzahl von Datenleitungen (826) verbunden ist; – eine Vielzahl von Daten-Abtastsignalpins des zweiten Teilnehmers (832), die mit der Vielzahl von Daten-Abtastsignalleitungen (820, 822) verbunden ist; – eine Vielzahl von Adresspins des zweiten Teilnehmers (832), die mit der Vielzahl von Adressleitungen (926) verbunden ist; – ein Adress-Abtastsignalpin des zweiten Teilnehmers (832), der mit der Adress-Abtastsignalleitung (920) verbunden ist; – einen Pin für einen gemeinsamen Takt des zweiten Teilnehmers (832), der verbunden ist, um das Bustaktsignal mit der Bustaktfrequenz zu empfangen; wobei der zweite Teilnehmer (832) die Adress-Informationselemente (Aa, Ab) auf dem Adressbus (926) abtastet, die auf das Adressabtastsignal (ADSTB) auf der Adress-Abtastsignalleitung (920) synchronisiert sind, wobei der zweite Teilnehmer (832) die Daten-Informationselemente (D1, D2, D3, D4) auf dem Datenbus (826) abtastet, die auf die Vielzahl von Datenabtastsignalen (DSTBp#, DSTBn#) auf den Daten-Abtastsignalleitungen (820, 822) synchronisiert sind.
  64. System gemäß 63, wobei die Vielzahl von Daten-Abtastsignalpins des ersten Teilnehmers (802) einen ersten Daten-Abtastsignalpin des ersten Teilnehmers (802) und einen zweiten Daten-Abtastsignalpin des ersten Teilnehmers (802) umfasst; wobei der ersten Teilnehmer (802) umfasst: – eine Daten-Abtastsignal-Erzeugungslogik des ersten Teilnehmers (802), um ein erstes Datenabtastsignal (DSTBp#) des ersten Teilnehmers (802) an dem ersten Daten-Abtastsignalpin des ersten Teilnehmers (802) und ein zweites Datenabtastsignal des ersten Teilnehmers (802) an dem zweiten Daten-Abtastsignalpin des ersten Teilnehmers (802) zu erzeugen, wobei das erste Datenabtastsignal des ersten Teilnehmers (802) und das zweite Datenabtastsignal des ersten Teilnehmers (802) eine Daten-Abtastsignalfrequenz von dem Doppelten der Bustaktfrequenz aufweist; – eine Adress-Abtastsignal-Erzeugungslogik des ersten Teilnehmers (802), um ein Adressabtastsignal des ersten Teilnehmers (802) an dem Adress-Abtastsignalpin des ersten Teilnehmers (802) mit einer Adress-Abtastsignalfrequenz zu erzeugen, die die Gleiche ist wie die Bustaktfrequenz; – eine Daten-Übermittlungslogik (806) des ersten Teilnehmers (802), um erste Daten-Informationselemente zu übermitteln, die auf eine erste fallende Flanke des ersten Datenabtastsignals (DSTBp#) des ersten Teilnehmers (802) an der Vielzahl von Datenpins des ersten Teilnehmers (802) synchronisiert sind, und zweite Daten-Informationselemente zu übermitteln, die auf eine erste fallende Flanke des zweiten Datenabtastsignals (DSTBn#) des ersten Teilnehmers (802) ebenfalls an der Vielzahl von Datenpins des ersten Teilnehmers (802) synchronisiert sind, und dritte Daten-Informationselemente zu übermitteln, die auf eine zweite fallende Flanke des ersten Datenabtastsignals (DSTBp#) des ersten Teilnehmers (802) an der Vielzahl von Datenpins des ersten Teilnehmers (802) synchronisiert sind, und vierte Daten-Informationselemente zu übermitteln, die auf eine zweite fallende Flanke des zweiten Datenabtastsignals (DSTBn#) des ersten Teilnehmers (802) ebenfalls an der Vielzahl von Datenpins des ersten Teilnehmers (802) synchronisiert sind; – eine Adress-Übermittlungslogik (906) des ersten Teilnehmers (802), um erste Adresselemente zu übermitteln, die auf eine fallende Flanke des Adressabtastsignals (ADSTB) des ersten Teilnehmers (802) an der Vielzahl von Adresspins synchronisiert sind und zweite Adresselemente zu übermitteln, die auf eine ansteigende Flanke des Adressabtastsignals (ADSTB) des ersten Teilnehmers (802) ebenfalls an der Vielzahl von Adresspins synchronisiert sind; wobei die Vielzahl von Daten-Abtastsignalpins des zweiten Teilnehmers (832) einen erster Daten-Abtastsignalpin des zweiten Teilnehmers (832) und einen zweiten Daten-Abtastsignalpin des zweiten Teilnehmers (832) umfasst; wobei der zweite Teilnehmer (832) umfasst: – eine Daten-Abtastsignal-Empfangslogik des zweiten Teilnehmers (832), um das erste Daten-Abtastsignal (DSTBp#) des ersten Teilnehmers (802) und das zweite Datenabtastsignal (DSTBn#) des ersten Teilnehmers (820) an der Vielzahl von Daten-Abtastsignalpins des zweiten Teilnehmers (832) zu empfangen; – eine Adress-Abtastsignal-Empfangslogik des zweiten Teilnehmers (832), um das Adressabtastsignal (ADSTB) des ersten Teilnehmers (802) an dem Adress-Abtastsignalpin des zweiten Teilnehmers (832) zu empfangen; – eine Daten-Empfangslogik (836) des zweiten Teilnehmers (832), um die ersten Daten-Informationselemente zu empfangen, die auf die erste fallende Flanke des ersten Datenabtastsignals (DSTBp#) des ersten Teilnehmers (802) an der Vielzahl von Datenpins des zweiten Teilnehmers (832) synchronisiert sind, und die zweiten Daten-Informationselemente zu empfangen, die auf die erste fallende Flanke des zweiten Datenabtastsignals (DSTBn#) des ersten Teilnehmers (802) ebenfalls an der Vielzahl von Datenpins des zweiten Teilnehmers (832) synchronisiert sind, und die dritten Daten-Informationselemente zu empfangen, die auf die zweite fallende Flanke des ersten Datenabtastsignals (DSTBp#) des ersten Teilnehmers (802) an der Vielzahl von Datenpins des zweiten Teilnehmers (832) synchronisiert sind, und die vierten Daten-Informationselemente zu empfangen, die auf die zweite fallende Flanke des zweiten Datenabtastsignals (DSTBn#) des ersten Teilnehmers (802) ebenfalls an der Vielzahl von Datenpins des zweiten Teilnehmers (832) synchronisiert sind; – eine Adress-Empfangslogik (936) des zweiten Teilnehmers (832), um Adress-Informationselemente zu empfangen, die auf die erste Flanke des Adressabtastsignals (ADSTB) des ersten Teilnehmers (802) an der Vielzahl von Adresspins des zweiten Teilnehmers (832) synchronisiert sind, und um Adresselemente zu empfangen, die auf die zweite Flanke des Adressabtastsignals (ADSTB) des ersten Teilnehmers (802) ebenfalls an der Vielzahl von Adresspins synchronisiert sind.
  65. System gemäß Anspruch 64, wobei der zweite Teilnehmer (832) ferner umfasst: – eine Daten-Abtastsignal-Erzeugungslogik des zweiten Teilnehmers (832), um ein erstes Datenabtastsignal (DSTBp#) des zweiten Teilnehmers an dem ersten Daten-Abtastsignalpin des zweiten Teilnehmers (832) und ein zweites Datenabtastsignal (DSTBn#) des zweiten Teilnehmers (832) an dem zweiten Daten-Abtastsignalpin des zweiten Teilnehmers (832) zu erzeugen, wobei das erste Datenabtastsignal (DSTBp#) des zweiten Teilnehmers (832) und das zweit Datenabtastsignal (DSTBn#) des zweiten Teilnehmers (832) eine Daten-Abtastsignalfrequenz von dem Doppelten (2×) der Bustaktfrequenz (BCLK) aufweist; – eine Adress-Abtastsignal-Erzeugungslogik des zweiten Teilnehmers (832), um ein Adressabtastsignal (ADSTB) des zweiten Teilnehmers (832) an dem Adress-Abtastsignalpin des zweiten Teilnehmers (832) mit einer Adress-Abtastsignalfrequenz zu erzeugen, die die Gleiche wie die Bustaktfrequenz (BCLK) ist; – eine Daten-Übermittlungslogik des zweiten Teilnehmers (832), um Daten-Informationselemente (D1, D3) zu übermitteln, die auf eine erste Flanke des ersten Datenabtastsignals (DSTBp#) des zweiten Teilnehmers (832) an der Vielzahl von Datenpins des zweiten Teilnehmers (832) synchronisiert sind, und Daten-Informationselemente (D2, D4) zu übermitteln, die auf eine erste Flanke des zweiten Datenabtastsignals (DSTBn#) des zweiten Teilnehmers (832) ebenfalls an der Vielzahl von Datenpins des zweiten Teilnehmers (832) synchronisiert sind; – eine Adress-Übermittlungslogik des zweiten Teilnehmers, um Adresselemente (Aa) zu übermitteln, die auf eine erste Flanke des Adressabtastsignal (ADSTB) des zweiten Teilnehmers (832) an der Vielzahl von Adresspins synchronisiert sind, und Adresselemente (Ab) zu übermitteln, die auf eine zweite Flanke des Adressabtastsignals (ADSTB) des zweiten Teilnehmers (832) ebenfalls an der Vielzahl von Adresspins synchronisiert sind.
  66. System gemäß Anspruch 64, wobei der erste Teilnehmer (802) ferner umfasst: – eine Daten-Abtastsignal-Empfangslogik des erste Teilnehmers (802), um das erste Datenabtastsignal (DSTBp#) des ersten Teilnehmers (802) und das zweite Datenabtastsignal (DSTBn#) des ersten Teilnehmers (802) an der Vielzahl von Daten-Abtastsignalpins des erste Teilnehmers zu empfangen; – eine Adress-Abtastsignal-Empfangslogik des erste Teilnehmers (802), um das Adressabtastsignal (ADSTB) des ersten Teilnehmers (802) an dem Adress-Abtastsignalpin des erste Teilnehmers (802) zu empfangen; – eine Daten-Empfangslogik des ersten Teilnehmers (802), um Daten-Informationselemente (D1, D3) zu empfangen, die auf die erste Flanke des ersten Datenabtastsignals (DSTBp#) des ersten Teilnehmers (802) an der Vielzahl von Datenpins des ersten Teilnehmers (802) synchronisiert sind, und die Daten-Informationselemente (D2, D4) zu empfangen, die auf die erste Flanke des zweiten Datenabtastsignals (DSTBn#) des ersten Teilnehmers (802) ebenfalls an der Vielzahl von Datenpins des ersten Teilnehmers (802) synchronisiert sind; – eine Adress-Empfangslogik des ersten Teilnehmers (802), um Adresselemente (Aa) zu empfangen, die auf die erste Flanke des Adressabtastsignals (ADSTB) des ersten Teilnehmers (802) an der Vielzahl von Adresspins des ersten Teilnehmers (802) synchronisiert sind und um Adresselemente (Ab) zu empfangen, die auf die zweite Flanke des Adressabtastsignals (ADSTB) des ersten Teilnehmers (802) ebenfalls an der Vielzahl von Adresspins synchronisiert sind.
  67. System gemäß einem der Ansprüche 63 bis 66, wobei der erste Teilnehmer (802) ein Prozessor ist und wobei der zweite Teilnehmer ein Chipsatz (832) ist.
  68. System gemäß einem der Ansprüche 63 bis 67, ferner umfassend: – einen Steuerbus, über den eine Vielzahl von Steuersignale auf das eine oder die mehreren Bustaktsignale synchronisiert übermittelt werden.
  69. System gemäß einem der Ansprüche 63 bis 68, wobei Informationen über den Datenbus (826), den Adressbus (926) und den Anforderungsbus in einer Quell-synchronen Weise übermittelt werden,
  70. System gemäß einem der Ansprüche 63 bis 68, wobei einer der Teilnehmer (802, 832) ein Busteilnehmer ist, der ferner umfasst: – ein Pin für ein Signal zum Blockieren einer nächsten Anforderung (BNR); – ein Eingangspin für eine Busanforderung eines Prioritätsteilnehmers (BPRI); – eine Busteilnehmer-Arbitrierungslogik, die in der Lage ist, eine Arbitrierungs-Phase (ARB) zwei Takte nach von einer vorherigen Arbitrierungs-Phase (ARB) einzuleiten, und in der Lage ist, ein Signal zum Blockieren einer nächsten Anforderung (BNR) an dem Pin für das Signal zum Blockieren einer nächsten Anforderung (BNR) zu empfangen, das zwei Bustaktzyklen nach dem Aktiv-Setzen des Adressabtastsignals (ADSTB) an dem Pin für Signal zum Blockieren einer nächsten Anforderung (BNR) auftritt, und auf das Signal zum Blockieren einer nächsten Anforderung (BNR) zu antworten; wobei der andere Teilnehmer der Prioritätsbusteilnehmer ist, der umfasst: – einen Pin für eine Busanforderung eines Prioritätsteilnehmers (BPRI); – eine Prioritätsbusteilnehmer-Arbitrierungslogik, die in der Lage ist, ein Busanforderungssignal eines Prioritätsteilnehmers (BPRI) auf dem Pin für die Busanforderung des Prioritätsteilnehmers mit einer minimalen Zeit für ein Inaktiv-Setzen von einem Bustaktzyklus aktiv zu setzen.
  71. System gemäß einem der Ansprüche 63 bis 69, umfassend: – den einen oder die mehreren Busteilnehmer, umfassend: – eine Vielzahl von -Anforderungs-Signalpins; – eine Anforderungs-Logik, die in der Lage ist, eine zweite Request-Phase (REQ) zwei Takte nach einer ersten Request-Phase (REQ) einzuleiten, indem eine Vielzahl von Anforderungssignalen (Req) an der Vielzahl von Anforderungssignalpins aktiv gesetzt wird und ein Adressabtastsignal (ADSTB) einer zweiten Transaktion an dem Adress-Abtastsignalpin für die zweite Transaktion zwei Buszyklen nach Aktiv-Setzen eines Adressabtastsignals (ADSTB) der zweiten Transaktion für eine erste Transaktion an dem Adress-Abtastsignalpin auftritt; – eine Adress- und Anforderungs-Übermittlungslogik, um die Vielzahl von Anforderungssignalen und eine Vielzahl von Adresssignalen mit einem Vielfachen von einer Bustaktfrequenz (BCLK) in einer Quell-synchronen Weise zu übermitteln.
DE10085385T 1999-12-29 2000-12-29 Vierfach gepumpte Bus-Architektur und Protokoll Expired - Fee Related DE10085385B3 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US09/474,058 US6609171B1 (en) 1999-12-29 1999-12-29 Quad pumped bus architecture and protocol
US09/474,058 1999-12-29
PCT/US2000/035520 WO2001048621A1 (en) 1999-12-29 2000-12-29 Quad pumped bus architecture and protocol

Publications (2)

Publication Number Publication Date
DE10085385T1 DE10085385T1 (de) 2002-12-19
DE10085385B3 true DE10085385B3 (de) 2011-12-08

Family

ID=23882019

Family Applications (2)

Application Number Title Priority Date Filing Date
DE60037036T Expired - Lifetime DE60037036T2 (de) 1999-12-29 2000-12-29 Vier-gepumpte busarchitektur-/protokoll
DE10085385T Expired - Fee Related DE10085385B3 (de) 1999-12-29 2000-12-29 Vierfach gepumpte Bus-Architektur und Protokoll

Family Applications Before (1)

Application Number Title Priority Date Filing Date
DE60037036T Expired - Lifetime DE60037036T2 (de) 1999-12-29 2000-12-29 Vier-gepumpte busarchitektur-/protokoll

Country Status (16)

Country Link
US (6) US6609171B1 (de)
EP (2) EP1242898B1 (de)
JP (1) JP4194274B2 (de)
KR (1) KR100565101B1 (de)
CN (4) CN100375075C (de)
AT (1) ATE377797T1 (de)
AU (1) AU2463101A (de)
BR (1) BRPI0016834B1 (de)
DE (2) DE60037036T2 (de)
GB (1) GB2374264B (de)
HK (1) HK1046964B (de)
RU (1) RU2271566C2 (de)
SG (2) SG123610A1 (de)
TW (1) TW559704B (de)
WO (1) WO2001048621A1 (de)
ZA (1) ZA200203946B (de)

Families Citing this family (98)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6609171B1 (en) * 1999-12-29 2003-08-19 Intel Corporation Quad pumped bus architecture and protocol
US6965648B1 (en) * 2000-05-04 2005-11-15 Sun Microsystems, Inc. Source synchronous link integrity validation
US6745268B1 (en) * 2000-08-11 2004-06-01 Micron Technology, Lnc. Capacitive multidrop bus compensation
US6816932B2 (en) * 2000-10-06 2004-11-09 Broadcom Corporation Bus precharge during a phase of a clock signal to eliminate idle clock cycle
US6678767B1 (en) * 2000-10-06 2004-01-13 Broadcom Corp Bus sampling on one edge of a clock signal and driving on another edge
US6993612B2 (en) * 2000-12-07 2006-01-31 Micron Technology, Inc. Arbitration method for a source strobed bus
US6901475B2 (en) * 2000-12-07 2005-05-31 Micron Technology, Inc. Link bus for a hub based computer architecture
US7676588B2 (en) * 2001-10-05 2010-03-09 International Business Machines Corporation Programmable network protocol handler architecture
DE50113128D1 (de) 2001-12-03 2007-11-22 Infineon Technologies Ag Datenübertragungseinrichtung
US7000065B2 (en) * 2002-01-02 2006-02-14 Intel Corporation Method and apparatus for reducing power consumption in a memory bus interface by selectively disabling and enabling sense amplifiers
US6983348B2 (en) * 2002-01-24 2006-01-03 Intel Corporation Methods and apparatus for cache intervention
US7085889B2 (en) * 2002-03-22 2006-08-01 Intel Corporation Use of a context identifier in a cache memory
CN100354843C (zh) * 2002-05-24 2007-12-12 皇家飞利浦电子股份有限公司 具有停顿装置的伪多端口数据存储器
AU2003240948A1 (en) * 2002-05-28 2003-12-12 Cadence Design Systems, Inc. Assertion-based transaction recording
TWI282513B (en) * 2002-06-12 2007-06-11 Mediatek Inc A pre-fetch device of instruction for an embedded system
TW579467B (en) * 2002-07-24 2004-03-11 Via Tech Inc Method for blocking request to bus
US6956789B2 (en) * 2002-09-16 2005-10-18 Texas Instruments Incorporated Cycle ready circuit for self-clocking memory device
US7234034B2 (en) * 2002-09-16 2007-06-19 Texas Instruments Incorporated Self-clocking memory device
US7200730B2 (en) * 2002-09-16 2007-04-03 Texas Instruments Incorporated Method of operating a memory at high speed using a cycle ready status output signal
US8185602B2 (en) 2002-11-05 2012-05-22 Newisys, Inc. Transaction processing using multiple protocol engines in systems having multiple multi-processor clusters
US7051229B2 (en) * 2002-12-03 2006-05-23 Alcatel Canada Inc. Logical bus overlay for increasing the existing system bus data rate
US20040128416A1 (en) 2002-12-11 2004-07-01 Tsvika Kurts Apparatus and method for address bus power control
US7216240B2 (en) * 2002-12-11 2007-05-08 Intel Corporation Apparatus and method for address bus power control
US7152167B2 (en) * 2002-12-11 2006-12-19 Intel Corporation Apparatus and method for data bus power control
US20040117708A1 (en) * 2002-12-16 2004-06-17 Ellis David G. Pre-announce signaling for interconnect built-in self test
US6922769B2 (en) * 2002-12-23 2005-07-26 Intel Corporation Apparatus and method for reduction of power consumption in OS that use flat segmentation memory model
US20040153611A1 (en) * 2003-02-04 2004-08-05 Sujat Jamil Methods and apparatus for detecting an address conflict
US7054988B2 (en) * 2003-04-17 2006-05-30 Lsi Logic Corporation Bus interface for processor
US7478025B1 (en) * 2003-04-18 2009-01-13 Unisys Corporation System and method to support dynamic partitioning of units to a shared resource
US20040230188A1 (en) * 2003-05-12 2004-11-18 Iulian Cioanta Treatment catheters with thermally insulated regions
US7287126B2 (en) * 2003-07-30 2007-10-23 Intel Corporation Methods and apparatus for maintaining cache coherency
US7665069B2 (en) * 2003-10-31 2010-02-16 Sonics, Inc. Method and apparatus for establishing a quality of service model
US9087036B1 (en) 2004-08-12 2015-07-21 Sonics, Inc. Methods and apparatuses for time annotated transaction level modeling
US8504992B2 (en) * 2003-10-31 2013-08-06 Sonics, Inc. Method and apparatus for establishing a quality of service model
US7113000B2 (en) * 2003-12-10 2006-09-26 Hewlett-Packard Development Company, L.P. Bus agent having multiple reference levels
US7178048B2 (en) * 2003-12-23 2007-02-13 Hewlett-Packard Development Company, L.P. System and method for signal synchronization based on plural clock signals
US7057414B2 (en) * 2004-01-07 2006-06-06 International Business Machines Corporation Avoiding oscillation in self-synchronous bi-directional communication system
US20050262376A1 (en) * 2004-05-21 2005-11-24 Mcbain Richard A Method and apparatus for bussed communications
US7539800B2 (en) * 2004-07-30 2009-05-26 International Business Machines Corporation System, method and storage medium for providing segment level sparing
US20060036826A1 (en) * 2004-07-30 2006-02-16 International Business Machines Corporation System, method and storage medium for providing a bus speed multiplier
US7296129B2 (en) * 2004-07-30 2007-11-13 International Business Machines Corporation System, method and storage medium for providing a serialized memory interface with a bus repeater
US7224595B2 (en) 2004-07-30 2007-05-29 International Business Machines Corporation 276-Pin buffered memory module with enhanced fault tolerance
US7389375B2 (en) * 2004-07-30 2008-06-17 International Business Machines Corporation System, method and storage medium for a multi-mode memory buffer device
US20060075164A1 (en) * 2004-09-22 2006-04-06 Ooi Eng H Method and apparatus for using advanced host controller interface to transfer data
US7331010B2 (en) 2004-10-29 2008-02-12 International Business Machines Corporation System, method and storage medium for providing fault detection and correction in a memory subsystem
US7277988B2 (en) * 2004-10-29 2007-10-02 International Business Machines Corporation System, method and storage medium for providing data caching and data compression in a memory subsystem
US7512762B2 (en) 2004-10-29 2009-03-31 International Business Machines Corporation System, method and storage medium for a memory subsystem with positional read data latency
US7395476B2 (en) * 2004-10-29 2008-07-01 International Business Machines Corporation System, method and storage medium for providing a high speed test interface to a memory subsystem
US7356737B2 (en) * 2004-10-29 2008-04-08 International Business Machines Corporation System, method and storage medium for testing a memory module
US7299313B2 (en) * 2004-10-29 2007-11-20 International Business Machines Corporation System, method and storage medium for a memory subsystem command interface
US7441060B2 (en) * 2004-10-29 2008-10-21 International Business Machines Corporation System, method and storage medium for providing a service interface to a memory system
US7305574B2 (en) * 2004-10-29 2007-12-04 International Business Machines Corporation System, method and storage medium for bus calibration in a memory subsystem
TWI256558B (en) * 2004-11-02 2006-06-11 Via Tech Inc Method for coordinating bus data transmission specification and CPU and bridge chip used in the same
TWI304935B (en) * 2004-11-02 2009-01-01 Via Tech Inc Method for determining data transmission specification and combination of bridge chipset and memory used in the same
TWI268427B (en) * 2004-11-02 2006-12-11 Via Tech Inc Coordinating method of bus data transmission specification
US20060161743A1 (en) * 2005-01-18 2006-07-20 Khaled Fekih-Romdhane Intelligent memory array switching logic
US20060171233A1 (en) * 2005-01-18 2006-08-03 Khaled Fekih-Romdhane Near pad ordering logic
US7340568B2 (en) * 2005-02-11 2008-03-04 International Business Machines Corporation Reducing number of rejected snoop requests by extending time to respond to snoop request
KR100606244B1 (ko) * 2005-02-11 2006-07-28 삼성전자주식회사 데이터 스트로브 신호에 동기 되어 전송되는 데이터의 캡쳐 방법 및 이를 위한 데이터 캡쳐 회로
US7529955B2 (en) 2005-06-30 2009-05-05 Intel Corporation Dynamic bus parking
US7543094B2 (en) 2005-07-05 2009-06-02 Via Technologies, Inc. Target readiness protocol for contiguous write
US7457901B2 (en) * 2005-07-05 2008-11-25 Via Technologies, Inc. Microprocessor apparatus and method for enabling variable width data transfers
CN100461142C (zh) * 2005-07-05 2009-02-11 威盛电子股份有限公司 微处理器、处理器总线系统、及执行稀疏写入处理的方法
US7502880B2 (en) * 2005-07-11 2009-03-10 Via Technologies, Inc. Apparatus and method for quad-pumped address bus
US7441064B2 (en) * 2005-07-11 2008-10-21 Via Technologies, Inc. Flexible width data protocol
US7444472B2 (en) * 2005-07-19 2008-10-28 Via Technologies, Inc. Apparatus and method for writing a sparsely populated cache line to memory
CN100435123C (zh) * 2005-07-19 2008-11-19 威盛电子股份有限公司 用于稀疏线写操作的装置和方法
US7590787B2 (en) * 2005-07-19 2009-09-15 Via Technologies, Inc. Apparatus and method for ordering transaction beats in a data transfer
US7444448B2 (en) 2005-08-03 2008-10-28 Via Technologies, Inc. Data bus mechanism for dynamic source synchronized sampling adjust
US20070073977A1 (en) * 2005-09-29 2007-03-29 Safranek Robert J Early global observation point for a uniprocessor system
US7634609B2 (en) * 2005-09-29 2009-12-15 Via Technologies, Inc. Data transmission coordinating method
US7757031B2 (en) * 2005-10-24 2010-07-13 Via Technologies, Inc. Data transmission coordinating method and system
US7478259B2 (en) 2005-10-31 2009-01-13 International Business Machines Corporation System, method and storage medium for deriving clocks in a memory system
US7685392B2 (en) * 2005-11-28 2010-03-23 International Business Machines Corporation Providing indeterminate read data latency in a memory system
US7636813B2 (en) * 2006-05-22 2009-12-22 International Business Machines Corporation Systems and methods for providing remote pre-fetch buffers
US7594055B2 (en) * 2006-05-24 2009-09-22 International Business Machines Corporation Systems and methods for providing distributed technology independent memory controllers
US7584336B2 (en) * 2006-06-08 2009-09-01 International Business Machines Corporation Systems and methods for providing data modification operations in memory subsystems
US7669086B2 (en) 2006-08-02 2010-02-23 International Business Machines Corporation Systems and methods for providing collision detection in a memory system
US7581073B2 (en) * 2006-08-09 2009-08-25 International Business Machines Corporation Systems and methods for providing distributed autonomous power management in a memory system
US20080062892A1 (en) * 2006-09-07 2008-03-13 Honeywell International Inc. High speed bus protocol with programmable scheduler
US7870459B2 (en) * 2006-10-23 2011-01-11 International Business Machines Corporation High density high reliability memory module with power gating and a fault tolerant address and command bus
US7477522B2 (en) * 2006-10-23 2009-01-13 International Business Machines Corporation High density high reliability memory module with a fault tolerant address and command bus
US8868397B2 (en) * 2006-11-20 2014-10-21 Sonics, Inc. Transaction co-validation across abstraction layers
KR100903381B1 (ko) * 2006-11-24 2009-06-23 주식회사 하이닉스반도체 반도체 메모리 장치 및 그의 구동 방법
KR20080047027A (ko) * 2006-11-24 2008-05-28 주식회사 하이닉스반도체 반도체 메모리 장치 및 그 구동 방법
KR100915811B1 (ko) * 2006-12-07 2009-09-07 주식회사 하이닉스반도체 반도체 메모리 장치의 데이터 입출력 제어 신호 생성 회로
US7721140B2 (en) 2007-01-02 2010-05-18 International Business Machines Corporation Systems and methods for improving serviceability of a memory system
US7603526B2 (en) * 2007-01-29 2009-10-13 International Business Machines Corporation Systems and methods for providing dynamic memory pre-fetch
US20090132747A1 (en) * 2007-11-19 2009-05-21 International Business Machines Corporation Structure for universal peripheral processor system for soc environments on an integrated circuit
US8139697B2 (en) * 2008-01-29 2012-03-20 United Microelectronics Corp. Sampling method and data recovery circuit using the same
US8020167B2 (en) * 2008-05-05 2011-09-13 Dell Products L.P. System and method for automatic throttling of resources in an information handling system chassis
KR101642833B1 (ko) * 2010-02-05 2016-07-26 삼성전자주식회사 클럭 임베디드 인터페이스 방법, 그 방법을 이용하는 송수신기 및 디스플레이 장치
WO2012127599A1 (ja) * 2011-03-22 2012-09-27 富士通株式会社 入出力制御装置,情報処理システム,及びログ採取プログラム
US8312176B1 (en) * 2011-06-30 2012-11-13 International Business Machines Corporation Facilitating transport mode input/output operations between a channel subsystem and input/output devices
US8683096B2 (en) * 2012-06-27 2014-03-25 Intel Corporation Configuration of data strobes
US20140233582A1 (en) * 2012-08-29 2014-08-21 Marvell World Trade Ltd. Semaphore soft and hard hybrid architecture
US9755818B2 (en) * 2013-10-03 2017-09-05 Qualcomm Incorporated Method to enhance MIPI D-PHY link rate with minimal PHY changes and no protocol changes
CN105390982B (zh) * 2015-11-24 2018-07-17 国家电网公司 基于仿生视觉分析的输电设备总线型评价系统

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0579515A1 (de) * 1992-07-17 1994-01-19 Digital Equipment Corporation Schnittstelle für asynchronen Bus zur Minimisierung von Übertragungszeiten
US5919254A (en) * 1997-06-25 1999-07-06 Intel Corporation Method and apparatus for switching between source-synchronous and common clock data transfer modes in a multiple processing system

Family Cites Families (61)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4763243A (en) * 1984-06-21 1988-08-09 Honeywell Bull Inc. Resilient bus system
US4858173A (en) * 1986-01-29 1989-08-15 Digital Equipment Corporation Apparatus and method for responding to an aborted signal exchange between subsystems in a data processing system
JPS62280948A (ja) * 1986-05-29 1987-12-05 Fanuc Ltd バス調停方式
US5341487A (en) * 1991-12-20 1994-08-23 International Business Machines Corp. Personal computer having memory system with write-through cache and pipelined snoop cycles
US5280587A (en) * 1992-03-31 1994-01-18 Vlsi Technology, Inc. Computer system in which a bus controller varies data transfer rate over a bus based on a value of a subset of address bits and on a stored value
JP3369227B2 (ja) * 1992-11-09 2003-01-20 株式会社東芝 プロセッサ
US5615343A (en) 1993-06-30 1997-03-25 Intel Corporation Method and apparatus for performing deferred transactions
US5568620A (en) 1993-06-30 1996-10-22 Intel Corporation Method and apparatus for performing bus transactions in a computer system
TW255022B (de) 1993-06-30 1995-08-21 Intel Corp
US5784579A (en) * 1994-03-01 1998-07-21 Intel Corporation Method and apparatus for dynamically controlling bus access from a bus agent based on bus pipeline depth
TW400483B (en) 1994-03-01 2000-08-01 Intel Corp High performance symmetric arbitration protocol with support for I/O requirements
US5550988A (en) * 1994-03-01 1996-08-27 Intel Corporation Apparatus and method for performing error correction in a multi-processor system
US5548733A (en) 1994-03-01 1996-08-20 Intel Corporation Method and apparatus for dynamically controlling the current maximum depth of a pipe lined computer bus system
US5572703A (en) * 1994-03-01 1996-11-05 Intel Corporation Method and apparatus for snoop stretching using signals that convey snoop results
GB2318487B (en) 1994-03-01 1998-12-16 Intel Corp High performance symmetric arbitration protocol with support for I/O requirements
DE69531933T2 (de) 1994-03-01 2004-08-12 Intel Corp., Santa Clara Busarchitektur in hochgradiger pipeline-ausführung
US5535340A (en) * 1994-05-20 1996-07-09 Intel Corporation Method and apparatus for maintaining transaction ordering and supporting deferred replies in a bus bridge
US6029217A (en) * 1994-10-03 2000-02-22 International Business Machines Corporation Queued arbitration mechanism for data processing system
US5596729A (en) * 1995-03-03 1997-01-21 Compaq Computer Corporation First arbiter coupled to a first bus receiving requests from devices coupled to a second bus and controlled by a second arbiter on said second bus
US5925099A (en) * 1995-06-15 1999-07-20 Intel Corporation Method and apparatus for transporting messages between processors in a multiple processor system
US5710906A (en) * 1995-07-07 1998-01-20 Opti Inc. Predictive snooping of cache memory for master-initiated accesses
KR0164395B1 (ko) * 1995-09-11 1999-02-18 김광호 반도체 메모리 장치와 그 리이드 및 라이트 방법
US5696910A (en) * 1995-09-26 1997-12-09 Intel Corporation Method and apparatus for tracking transactions in a pipelined bus
US5948094A (en) 1995-09-29 1999-09-07 Intel Corporation Method and apparatus for executing multiple transactions within a single arbitration cycle
US5812803A (en) * 1995-09-29 1998-09-22 Intel Corporation Method and apparatus for controlling data transfers between a bus and a memory device using a multi-chip memory controller
US5778438A (en) * 1995-12-06 1998-07-07 Intel Corporation Method and apparatus for maintaining cache coherency in a computer system with a highly pipelined bus and multiple conflicting snoop requests
US5838995A (en) * 1995-12-18 1998-11-17 International Business Machines Corporation System and method for high frequency operation of I/O bus
US5802132A (en) * 1995-12-29 1998-09-01 Intel Corporation Apparatus for generating bus clock signals with a 1/N characteristic in a 2/N mode clocking scheme
WO1997030399A1 (en) * 1996-02-20 1997-08-21 Intergraph Corporation High-availability super server
JP3643425B2 (ja) * 1996-02-29 2005-04-27 富士通株式会社 データ処理方法、データ処理装置及びインターフェイスコントローラ
AU3587097A (en) * 1996-09-06 1998-03-26 Intel Corporation A data flow control mechanism for a bus supporting two-and three-agent transactions
US5867728A (en) * 1996-12-17 1999-02-02 Compaq Computer Corp. Preventing corruption in a multiple processor computer system during a peripheral device configuration cycle
US6012118A (en) 1996-12-30 2000-01-04 Intel Corporation Method and apparatus for performing bus operations in a computer system using deferred replies returned without using the address bus
US5870567A (en) * 1996-12-31 1999-02-09 Compaq Computer Corporation Delayed transaction protocol for computer system bus
US6065101A (en) * 1997-06-12 2000-05-16 International Business Machines Corporation Pipelined snooping of multiple L1 cache lines
US6336159B1 (en) 1997-06-25 2002-01-01 Intel Corporation Method and apparatus for transferring data in source-synchronous protocol and transferring signals in common clock protocol in multiple agent processing system
US5991855A (en) * 1997-07-02 1999-11-23 Micron Electronics, Inc. Low latency memory read with concurrent pipe lined snoops
US5978869A (en) 1997-07-21 1999-11-02 International Business Machines Corporation Enhanced dual speed bus computer system
US6108736A (en) * 1997-09-22 2000-08-22 Intel Corporation System and method of flow control for a high speed bus
US5964856A (en) * 1997-09-30 1999-10-12 Intel Corporation Mechanism for data strobe pre-driving during master changeover on a parallel bus
US6260091B1 (en) * 1997-10-20 2001-07-10 Intel Corporation Method and apparatus for performing out-of-order bus operations in which an agent only arbitrates for use of a data bus to send data with a deferred reply
US6092156A (en) 1997-11-05 2000-07-18 Unisys Corporation System and method for avoiding deadlocks utilizing split lock operations to provide exclusive access to memory during non-atomic operations
KR100255664B1 (ko) 1997-12-29 2000-05-01 윤종용 반도체 집적회로의 클락 포워딩 회로 및 클락포워딩 방법
US6006291A (en) * 1997-12-31 1999-12-21 Intel Corporation High-throughput interface between a system memory controller and a peripheral device
US6041380A (en) * 1998-01-21 2000-03-21 Micron Electronics, Inc. Method for increasing the number of devices capable of being operably connected to a host bus
US6223238B1 (en) * 1998-03-31 2001-04-24 Micron Electronics, Inc. Method of peer-to-peer mastering over a computer bus
US6172937B1 (en) * 1998-05-13 2001-01-09 Intel Corporation Multiple synthesizer based timing signal generation scheme
US6108721A (en) * 1998-06-29 2000-08-22 Hewlett-Packard Company Method and apparatus for ensuring data consistency between an i/o channel and a processor
US6275890B1 (en) * 1998-08-19 2001-08-14 International Business Machines Corporation Low latency data path in a cross-bar switch providing dynamically prioritized bus arbitration
US6205506B1 (en) * 1998-08-25 2001-03-20 Stmicroelectronics, Inc. Bus interface unit having multipurpose transaction buffer
US6449677B1 (en) * 1998-09-03 2002-09-10 Compaq Information Technologies Group, L.P. Method and apparatus for multiplexing and demultiplexing addresses of registered peripheral interconnect apparatus
US6102118A (en) * 1998-12-30 2000-08-15 Moore; Curt A. Multi-purpose adjustable centralizer system with tool
TW514788B (en) * 1999-04-23 2002-12-21 Via Tech Inc Method of delayed transaction in bus system and device using the method
US6272604B1 (en) * 1999-05-20 2001-08-07 International Business Machines Corporation Contingent response apparatus and method for maintaining cache coherency
US6487621B1 (en) * 1999-08-17 2002-11-26 Compaq Information Technologies Group, L.P. Architecture, system and method for ensuring an ordered transaction on at least one of a plurality of multi-processor buses that experience a hit-to-modified snoop cycle
US6615323B1 (en) * 1999-09-02 2003-09-02 Thomas Albert Petersen Optimizing pipelined snoop processing
US6591321B1 (en) * 1999-11-09 2003-07-08 International Business Machines Corporation Multiprocessor system bus protocol with group addresses, responses, and priorities
US6609171B1 (en) * 1999-12-29 2003-08-19 Intel Corporation Quad pumped bus architecture and protocol
US6681293B1 (en) * 2000-08-25 2004-01-20 Silicon Graphics, Inc. Method and cache-coherence system allowing purging of mid-level cache entries without purging lower-level cache entries
US6901475B2 (en) * 2000-12-07 2005-05-31 Micron Technology, Inc. Link bus for a hub based computer architecture
US6651122B2 (en) * 2000-12-07 2003-11-18 Micron Technology, Inc. Method of detecting a source strobe event using change detection

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0579515A1 (de) * 1992-07-17 1994-01-19 Digital Equipment Corporation Schnittstelle für asynchronen Bus zur Minimisierung von Übertragungszeiten
US5919254A (en) * 1997-06-25 1999-07-06 Intel Corporation Method and apparatus for switching between source-synchronous and common clock data transfer modes in a multiple processing system

Also Published As

Publication number Publication date
KR100565101B1 (ko) 2006-03-30
RU2002120499A (ru) 2004-03-10
US20010037421A1 (en) 2001-11-01
CN1415095A (zh) 2003-04-30
SG123610A1 (en) 2006-07-26
DE60037036D1 (de) 2007-12-20
ATE377797T1 (de) 2007-11-15
JP4194274B2 (ja) 2008-12-10
TW559704B (en) 2003-11-01
US6807592B2 (en) 2004-10-19
DE10085385T1 (de) 2002-12-19
WO2001048621A1 (en) 2001-07-05
US6907487B2 (en) 2005-06-14
EP1881414A3 (de) 2008-07-30
US20020038397A1 (en) 2002-03-28
DE60037036T2 (de) 2008-08-21
JP2003518693A (ja) 2003-06-10
GB2374264B (en) 2004-04-07
CN1558337A (zh) 2004-12-29
EP1242898A1 (de) 2002-09-25
CN1900924A (zh) 2007-01-24
HK1046964A1 (en) 2003-01-30
US20020029307A1 (en) 2002-03-07
CN1900924B (zh) 2010-05-12
US20020147875A1 (en) 2002-10-10
BR0016834A (pt) 2002-09-10
CN1815463B (zh) 2014-03-05
CN100375075C (zh) 2008-03-12
EP1242898B1 (de) 2007-11-07
US6880031B2 (en) 2005-04-12
EP1881414A2 (de) 2008-01-23
US6804735B2 (en) 2004-10-12
GB2374264A (en) 2002-10-09
SG123609A1 (en) 2006-07-26
ZA200203946B (en) 2003-01-02
US20010037424A1 (en) 2001-11-01
US6609171B1 (en) 2003-08-19
RU2271566C2 (ru) 2006-03-10
GB0216035D0 (en) 2002-08-21
AU2463101A (en) 2001-07-09
BRPI0016834B1 (pt) 2015-08-11
KR20020089308A (ko) 2002-11-29
CN1815463A (zh) 2006-08-09
US6601121B2 (en) 2003-07-29
HK1046964B (zh) 2004-07-23
CN1230762C (zh) 2005-12-07

Similar Documents

Publication Publication Date Title
DE10085385B3 (de) Vierfach gepumpte Bus-Architektur und Protokoll
DE69531933T2 (de) Busarchitektur in hochgradiger pipeline-ausführung
DE69936060T2 (de) Verfahren und Vorrichtung für eine verbesserte Schnittstelle zwischen Computerkomponenten
DE69233655T2 (de) Mikroprozessorarchitektur mit der Möglichkeit zur Unterstützung mehrerer verschiedenartiger Prozessoren
DE69729243T2 (de) Multiprozessorsystem mit Vorrichtung zur Optimierung von Spin-Lock-Operationen
DE19580990C2 (de) Verfahren und Einrichtung zum Ausführen verzögerter Transaktionen
DE69634358T2 (de) Verzögerungsverringerung in der übertragung von gepufferten daten zwischenzwei gegenseitig asynchronen bussen
DE69721643T2 (de) Multiprozessorsystem ausgestaltet zur effizienten Ausführung von Schreiboperationen
DE69724353T2 (de) Mehrrechnersystem mit einem Drei-Sprung-Kommunikationsprotokoll
DE60013470T2 (de) Gerät zur initialisierung einer rechnerschnittstelle
DE69632450T2 (de) Flexible Slave-Schnittstelle mit hoher Geschwindigkeit für parallelen gemeinsamen Bus zum lokalen Cachepuffer
DE69724354T2 (de) Ein Mehrprozessorrechnersystem mit lokalen und globalen Adressräumen und mehreren Zugriffsmoden
DE69722079T2 (de) Ein Mehrrechnersystem mit Anordnung zum Durchführen von Blockkopieroperationen
DE19580707C2 (de) PCI-ZU-ISA-Interrupt-Protokoll-Konverter und -Auswahlmechanismus
DE69733384T2 (de) Prozessoruntersystem für den Gebrauch mit einer universellen Rechnerarchitektur
DE69628609T2 (de) Distribuiertes Pipeline-Busarbitrierungssystem
DE69636452T2 (de) Mehrprozessor-cachespeicherkohärenzprotokoll für einen lokalbus
DE69634182T2 (de) Direktspeicherzugriffssteuerung mit programmierbarer Zeitsteuerung
DE3909948A1 (de) Mikrocomputersystem mit mehrfachbus und buszuteilung
DE19983443B4 (de) Außer-der-Reihe-Snooping für Multiprozessor-Computersysteme
DE69822866T2 (de) System und verfahren zum beenden von lock-step-sequenzen in einem multiprozessorsystem
DE69726302T2 (de) Busschnittstellensteuerungsschaltung
DE60017774T2 (de) Verfahren und vorrichtung zur unterstützung von mehrtaktübertragung in einem rechnersystem mit einer punkt-zu-punkt halb-duplex verbindung
DE4018481A1 (de) Mikroprozessor hold- und lock-schaltung
EP0512685B1 (de) Quadraturbusprotokoll zum Ausführen von Transaktionen in einer Rechneranordnung

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8172 Supplementary division/partition in:

Ref document number: 10066374

Country of ref document: DE

Kind code of ref document: P

Q171 Divided out to:

Ref document number: 10066374

Country of ref document: DE

Kind code of ref document: P

8172 Supplementary division/partition in:

Ref document number: 10085614

Country of ref document: DE

Kind code of ref document: P

Q171 Divided out to:

Ref document number: 10085614

Country of ref document: DE

Kind code of ref document: P

8172 Supplementary division/partition in:

Ref document number: 10085613

Country of ref document: DE

Kind code of ref document: P

Q171 Divided out to:

Ref document number: 10085613

Country of ref document: DE

Kind code of ref document: P

8172 Supplementary division/partition in:

Ref document number: 10085502

Country of ref document: DE

Kind code of ref document: P

Q171 Divided out to:

Ref document number: 10085502

Country of ref document: DE

Kind code of ref document: P

R016 Response to examination communication
R016 Response to examination communication
R018 Grant decision by examination section/examining division
R020 Patent grant now final

Effective date: 20120309

R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee