DE60306937T4 - Synchronisierung von pipelines in einem datenverarbeitungsgerät - Google Patents

Synchronisierung von pipelines in einem datenverarbeitungsgerät Download PDF

Info

Publication number
DE60306937T4
DE60306937T4 DE60306937T DE60306937T DE60306937T4 DE 60306937 T4 DE60306937 T4 DE 60306937T4 DE 60306937 T DE60306937 T DE 60306937T DE 60306937 T DE60306937 T DE 60306937T DE 60306937 T4 DE60306937 T4 DE 60306937T4
Authority
DE
Germany
Prior art keywords
pipeline
coprocessor
queue
stage
token
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60306937T
Other languages
English (en)
Other versions
DE60306937D1 (de
DE60306937T2 (de
Inventor
Martin Robert Great Shelford EVANS
Ian Victor Fulbourn DEVEREUX
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.)
ARM Ltd
Original Assignee
ARM Ltd
Advanced Risc Machines Ltd
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 ARM Ltd, Advanced Risc Machines Ltd filed Critical ARM Ltd
Publication of DE60306937T2 publication Critical patent/DE60306937T2/de
Application granted granted Critical
Publication of DE60306937T4 publication Critical patent/DE60306937T4/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3867—Concurrent instruction execution, e.g. pipeline or look ahead using instruction pipelines
    • G06F9/3869—Implementation aspects, e.g. pipeline latches; pipeline synchronisation and clocking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G06F9/3842—Speculative instruction execution
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3877—Concurrent instruction execution, e.g. pipeline or look ahead using a slave processor, e.g. coprocessor
    • G06F9/3879—Concurrent instruction execution, e.g. pipeline or look ahead using a slave processor, e.g. coprocessor for non-native instruction execution, e.g. executing a command; for Java instruction set
    • G06F9/3881—Arrangements for communication of instructions and data

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Advance Control (AREA)
  • Multi Processors (AREA)

Description

  • Gebiet der Erfindung
  • Die vorliegende Erfindung bezieht sich auf eine Technik zum Erzielen einer Synchronisierung zwischen Pipelines in einer Datenverarbeitungsvorrichtung.
  • Beschreibung des Standes der Technik
  • Es ist bekannt, eine Datenverarbeitungsvorrichtung mit einem Hauptprozessor zu versehen, der die Form eines Pipelineprozessors annimmt, welcher eine Mehrzahl von Pipelinestufen hat. Dies ermöglicht es, daß zu irgendeinem Zeitpunkt mehrere Befehle in der Ausführung durch den Hauptprozessor sein können. Während der Ausführung irgend eines besonderen Befehles durchläuft dieser Befehl die verschiedenen Pipelinestufen des Hauptprozessors, wobei die Ausführung dieses Befehls typischerweise abgeschlossen wird, wenn der Befehl durch die letzte Pipelinestufe des Hauptprozessors verarbeitet worden ist, wobei zu diesem Zeitpunkt der Zustand der Datenverarbeitungsvorrichtung aktualisiert wird, um das Ergebnis der Ausführung dieses Befehls wiederzugeben. Als ein Beispiel können die Inhalte von einem oder mehreren Registern einer Registerbank, welche für den Hauptprozessor zugänglich sind, abhängig von dem Ergebnis des Ausführungsbefehls aktualisiert werden.
  • Es ist auch bekannt, eine Datenverarbeitungsvorrichtung mit einem oder mehreren Coprozessoren für die Ausführung bestimmter Coprozessorbefehle vorzusehen, welche in einer Folge von Befehlen erscheinen, die durch die Datenverarbeitungsvorrichtung ausgeführt werden sollen. In Situationen, in welchen der Hauptprozessor eine Pipelinearchitektur hat, ist es üblich, daß der Coprozessor auch eine Pipelinearchitektur hat und damit auch eine Mehrzahl von Pipelinestufen hat, durch welche ein Coprozessorbefehl verarbeitet wird, um den Coprozessorbefehl auszuführen. Typischerweise ist jeder Coprozessorbefehl dafür ausgelegt, daß er sowohl durch die Pipeline des Hauptprozessors als auch durch die Pipeline des Coprozessors geleitet wird. Der Coprozessor soll mehr oder weniger im Gleichschritt mit dem Hauptprozessor arbeiten und dementsprechend müssen Schritte unternommen werden, um die Coprozessorpipeline mit der Hauptprozessorpipeline synchronisiert zu halten.
  • Das Erfordernis der Synchronisation ergibt sich aus der Tatsache, daß eine Interaktion zwischen den verschiedenen Pipelinestufen des Hauptprozessors und den verschiedenen Pipelinestufen des Coprozessors während der Ausführung eines Coprozessorbefehls erforderlich ist. Beispielsweise können Coprozessorbefehle durch den Hauptprozessor gelöscht werden, wenn ein Zustandscode bzw. ein Bedingungscode, der durch den Coprozessorbefehl angegeben wird, nicht erfüllt ist, oder die gesamte Coprozessorpipeline muß gespült bzw. geleert werden für den Fall einer falsch vorhergesagten Verzweigung, die dazu geführt hat, daß der Coprozessorbefehl ausgeführt wird. Weiterhin müssen möglicherweise Daten zwischen dem Hauptprozessor und dem Coprozessor für den Fall ausgetauscht werden, daß die Coprozessorbefehle Lade- oder Speicheroperationen definieren.
  • Bisher sind Coprozessorpipelines mit der Hauptprozessorpipeline synchronisiert gehalten worden, indem Signale mit einem festen Zeittakt von einer Pipeline an die andere weitergeleitet wurden, wie es in der US-A-5,860,000 offenbart wird. Diese Signale verursachen hauptsächlich Stops in einer Pipeline, wenn die andere Pipeline anhält, um eine Synchronisierung aufrechtzuerhalten. Es gibt jedoch andere verkomplizierende Faktoren, wenn beispielsweise die Hauptpipeline den Coprozessorbefehl löschen muß oder wenn die Pipelines gespült werden müssen, was die Wechselwirkungen zwischen dem Hauptprozessor und dem Coprozessor beträchtlich komplizierter macht, wenn sie über Stops miteinander wechselwirken. Da die Länge der Pipelineprozessoren angewachsen ist, ist es immer schwieriger geworden, eine Synchronisierung zwischen Pipelines unter Verwendung dieses Schemas einer engen Ankopplung, welches das Weiterleiten von Signalen mit einem festen Zeittakt zwischen den Pipelines beinhaltet, zu erzielen.
  • Eine Haupteinschränkung, die der Coprozessorschnittstelle auferlegt ist, besteht darin, daß sie während einer Verzögerung über zwei Zyklen arbeiten muß, d. h. irgendein Signal, welches von dem Hauptprozessor an den Coprozessor oder umgekehrt weitergeleitet wird, muß einen vollständigen Taktzyklus erhalten, um von dem einen zu dem anderen überzugehen und kann damit nicht vor dem folgenden Taktzyklus in Aktion treten. Dies bedeutet, daß ein Signal, welches die Schnittstelle überschreitet, aus einem Register auf einer Seite der Schnittstelle ausgetaktet werden muß und direkt in ein anderes Register auf der anderen Seite eingetaktet werden muß und daß kein kombinatorischer Prozeß dazwischen kommen darf. Diese Einschränkung ergibt sich aus der Tatsache, daß der Hauptprozessor (der hier auch als der Prozessorkern bezeichnet wird) und der Coprozessor um einen beträchtlichen Abstand voneinander entfernt angeordnet sein können und daß großzügige Zeittoleranzen zum Auffangen der Signallaufzeiten zugelassen werden müssen. Dies gilt insbesondere in Situationen, in welchen der Coprozessor getrennt von dem Entwurf bzw. Modell des Hauptprozessors entwickelt wurde, beispielsweise von einem Dritten. Diese Verzögerung in der Signallaufzeit macht es schwierig, unter Verwendung der vorstehend beschriebenen Synchronisierungstechnik einer engen Kopplung die Pipelinesynchronisierung aufrecht zu erhalten.
  • Dementsprechend wäre es wünschenswert, eine verbesserte Technik für das Erhalten einer Synchronisation zwischen Pipelines in einer Datenverarbeitungsvorrichtung bereitzustellen.
  • Zusammenfassung der Erfindung
  • Gemäß einem ersten Aspekt stellt die vorliegende Erfindung eine Datenverarbeitungsvorrichtung bereit, welche aufweist: einen Hauptprozessor, der in der Weise betreibbar ist, daß er eine Folge von Befehlen ausführt, wobei der Hauptprozessor eine erste Pipeline aufweist, die eine erste Mehrzahl von Pipelinestufen hat, einen Coprozessor, der in der Weise betreibbar ist, daß er Coprozessorbefehle in der Folge von Befehlen ausführt, wobei der Coprozessor eine zweite Pipeline aufweist, die eine zweite Mehrzahl von Pipelinestufen hat, und wobei jeder Coprozessorbefehl in der Weise ausgestaltet ist, daß er sowohl durch die erste Pipeline als auch durch die zweite Pipeline hindurch geleitet wird, und zumindest eine Synchronisierungsschlange, welche eine vorbestimmte Pipelinestufe in einer der Pipelines mit einer Partnerpipelinestufe in der anderen der Pipelines verbindet, wobei die vorbestimmte Pipelinestufe in der Weise betreibbar ist, daß sie bewirkt, daß ein Token in der Synchronisierungsschlange angeordnet wird, wenn ein Coprozessorbefehl ausgeführt wird, und wobei die Partnerpipelinestufe in der Weise betreibbar ist, daß sie diesen Coprozessorbefehl nach Empfang des Token von der Synchronisierungsschlange verarbeitet, wodurch die erste und die zweite Pipeline zwischen der vorbestimmten Pipelinestufe und der Partnerpipelinestufe synchronisiert werden.
  • Gemäß der vorliegenden Erfindung wird eine Datenverarbeitungsvorrichtung bereitgestellt mit zumindest einer Synchronisierungsschlange, die eine vorbestimmte Pipelinestufe in einer der Pipelines mit einer Partnerpipelinestufe in der anderen der Pipelines verbindet bzw. ankoppelt. Die vorbestimmte Pipelinestufe ist dafür ausgelegt, daß sie bewirkt, daß ein Token in der Synchronisierungsschlange angeordnet wird, wenn ein Coprozessorbefehl ausgeführt wird, und die Partnerpipelinestufe ist dann in der Weise betreibbar, daß sie diesen Coprozessorbefehl nach Empfang des Token von der Synchronisierungsschlange verarbeitet, wodurch die erste und die zweite Pipelinestufe an diesem Punkt synchronisiert werden.
  • Die Erfindung stellt damit eine auf Token beruhende Pipelinesynchronisationstechnik bereit, die einen gewissen Schlupf zwischen den beiden Pipelines zuläßt, indem eine strenge Synchronisierung auf allen Stufen nicht erforderlich ist, wobei jedoch sichergestellt wird, daß die Pipelines für kritische Informationsübertragungen korrekt synchronisiert sind. Die Technik der Erfindung kann als ein datengetriebenes, lose gekoppeltes Synchronisierungsschema betrachtet werden, im Gegensatz zu dem durch eine Steuerung getriebenen, eng gekoppelten Schema nach dem Stand der Technik, welches das Weiterleiten von Signalen mit festen Zeittakten zwischen den Pipelines beinhaltet.
  • Während es möglich ist, daß in gewissen Ausführungsformen möglicherweise nur eine einzelne Synchronisierungsschlange vorhanden ist, weisen bevorzugte Ausführungsformen der Datenverarbeitungsvorrichtung darüber hinaus eine Mehrzahl derartiger Synchronisierungsschlangen auf, wobei jede Synchronisierungsschlange eine vorbestimmte Pi pelinestufe in einer der Pipelines mit einer Partnerpipelinestufe in der anderen der Pipelines verbindet.
  • In bevorzugten Ausführungsformen ist eine der Synchronisierungsschlangen, von denen es zumindest eine gibt, eine Befehlsschlange, wobei die vorbestimmte Pipelinestufe sich in der ersten Pipeline befindet und dafür ausgelegt ist zu bewirken, daß ein Token, das einen Coprozessorbefehl kennzeichnet, in der Befehlsschlange angeordnet wird, während die Partnerpipelinestufe sich in der zweiten Pipeline befindet und in der Weise betreibbar ist, daß sie nach Empfang des Token mit der Verarbeitung des Coprozessorbefehles beginnt, der durch das Token identifiziert bzw. gekennzeichnet ist.
  • Bezüglich der Befehlsschlange sind sowohl die vorbestimmte Pipelinestufe als auch die Partnerpipelinestufe vorzugsweise eine der ersten Pipelinestufen in ihren jeweiligen Pipelines. Genauer gesagt ist in bevorzugten Ausführungsformen die vorbestimmte Pipelinestufe eine Stufe in der ersten Pipeline für das Heranholen bzw. Vorabheranholen und die Partnerpipelinestufe ist eine Decodierstufe in der zweiten Pipeline, wobei diese Decodierstufe in der Weise betreibbar ist, daß sie nach Empfang des Token den Coprozessorbefehl decodiert.
  • In derartigen bevorzugten Ausführungsformen ist die Heranholstufe in der ersten Pipeline vorzugsweise in der Weise betreibbar, daß sie bewirkt, daß ein Token in der Befehlsschlange für jeden Befehl in der Folge von Befehlen angeordnet wird und die Decodierstufe in der zweiten Pipelinestufe ist dafür ausgelegt, jeden Befehl nach Empfang des zugehörigen Token zu decodieren, um festzustellen, ob dieser Befehl ein Coprozessorbefehl ist, der eine weitere Verarbeitung durch den Coprozessor erfordert.
  • Es versteht sich, daß es als eine Alternative zu dem obigen Ansatz möglich wäre, statt dessen zuzulassen, daß jeder der Befehle erst durch die Decodierstufe der ersten Pipeline decodiert wird und dann über die Befehlsschlange nur diejenigen Befehle weiterzuleiten, die tatsächlich Coprozessorbefehle sind, die durch den Coprozessor zu behandeln bzw. zu bearbeiten sind. In diesem Fall liegt es auf der Hand, daß die vorbestimmte Pipelinestufe entweder die Decodierstufe oder eine auf die Decodierstufe folgende Stufe der ersten Pipeline sein müßte.
  • In bevorzugten Ausführungsformen ist eine der Synchronisierungsschlangen, von denen es zumindest eine gibt, eine Löschschlange, wobei die vorbestimmte Pipelinestufe sich in der ersten Pipeline befindet und dafür ausgelegt ist, daß sie bewirkt, daß in der Löschschlange ein Token angeordnet wird, welches angibt bzw. kennzeichnet, ob ein Coprozessorbefehl an einer vorbestimmten Pipelinestufe gelöscht werden soll, und die Partnerpipelinestufe befindet sich in der zweiten Pipeline und ist in der Weise betreibbar, daß sie nach Empfang des Token aus der Löschschlange, und falls das Token den Hinweis gibt, daß der Coprozessorbefehl gelöscht werden soll, bewirkt, daß der Coprozessorbefehl gelöscht wird.
  • Der Hauptprozessor möchte also möglicherweise einen Befehl löschen, den er bereits an den Coprozessor weitergeleitet hat. Dies kann beispielsweise geschehen, wenn der Befehl irgendeinen seiner Zustandscodes nicht erfüllt, was erfordert, daß die Ausführung des Befehls sowohl im Hauptprozessor als auch im Coprozessor gelöscht wird. Die Löschschlange trägt diese Information von dem Hauptprozessor herüber zu dem Coprozessor.
  • In der bevorzugten Ausführungsform ist bezüglich der Löschschlange die vorbestimmte Pipelinestufe eine Ausgabestufe in der ersten Pipeline und die Partnerpipelinestufe ist eine Stufe, welche auf eine Ausgabestufe in der zweiten Pipeline folgt. Genauer gesagt ist in bevorzugten Ausführungsformen die Partnerpipelinestufe eine erste Ausführungsstufe der Coprozessorpipeline.
  • In bevorzugten Ausführungsformen ist die Partnerpipeline nach Empfang des Token von der Löschschlange und falls das Token angibt, daß der Coprozessorbefehl gelöscht werden soll, in der Weise betreibbar, daß sie den Coprozessorbefehl aus der zweiten Pipeline entfernt. Es versteht sich, daß es eine Anzahl von Arten gibt, auf welche der Befehl aus der zweiten Pipeline gelöscht oder ausgespült werden kann. Beispielsweise könnte es möglich sein, den Befehl tatsächlich mit unmittelbarer Wirkung aus der Pipeline zu entfernen. In bevorzugten Ausführungsformen jedoch läßt man statt dessen den Befehl durch einige der verbleibenden Stufen der Pipeline weiterlaufen, jedoch mit einem gesetzten Flag (Anzeigeelement), welches anzeigt, daß der Befehl nicht ausgeführt werden soll, so daß der Befehl nach wie vor Token von den Schlangen aufnehmen kann.
  • In bevorzugten Ausführungsformen ist zumindest eine der Synchronisierungsschlangen, von denen es zumindest eine gibt, eine Abschlußschlange, wobei die vorbestimmte Pipelinestufe sich in der ersten Pipeline befindet und dafür ausgelegt ist zu bewirken, daß in der Abschlußschlange ein Token angeordnet wird, welches die Erlaubnis für einen Coprozessorbefehl der vorbestimmten Pipelinestufe kennzeichnet, daß er in einen Ruhezustand versetzt werden soll, um zu bewirken, daß der Coprozessorbefehl in den Ruhezustand versetzt wird.
  • Die Abschlußschlange hält damit die Synchronisierung am Ende der Pipeline aufrecht, indem sie für jeden Befehl in der Coprozessorpipeline die Erlaubnis erteilt, in den Ruhezustand einzutreten. In bevorzugten Ausführungsformen wird die Länge der Coprozessorpipeline bestimmt durch das Erfordernis, den Ruhezustand eines Coprozessorbefehls lange genug zu verzögern, um die Aufnahme der entsprechenden Token zu ermöglichen, die aus dem Ende der Abschlußschlange austreten.
  • Bezüglich der Abschlußschlange ist die vorbestimmte Pipelinestufe vorzugsweise eine Rückschreibestufe in der ersten Pipeline und die Partnerpipelinestufe ist vorzugsweise eine Rückschreibstufe in der zweiten Pipeline.
  • In bevorzugten Ausführungsformen ist eine der zumindest einen Synchronisierungsschlangen eine Längenschlange, wobei die vorbestimmte Pipelinestufe sich in der zweiten Pipeline befindet und dafür ausgelegt ist, daß sie für einen vektorisierten Coprozessorbefehl bewirkt, daß in der Längenschlange ein Token angeordnet wird, welches die Längeninformation für den vektorisierten Coprozessorbefehl kennzeichnet, und die Partnerpipelinestufe befindet sich in der ersten Pipeline und ist in der Weise betreibbar, daß sie bei Empfang des Token aus der Längenschlange die Längeninformation als Faktor in die weitere Verarbeitung des vektorisierten Coprozessorbefehls innerhalb der ersten Pipeline einbringt.
  • Einige Coprozessorbefehle können vektorisiert werden, indem sie ermöglichen, daß mehrere Wiederholungen des Befehls innerhalb eines einzelnen Befehls spezifiziert werden. Typische Beispiele wären Lade- oder Speicherbefehle, wobei ein vektorisierter Lade- oder ein vektorisierter Speicherbefehl ermöglicht, daß mehrere Datenwerte in einem einzelnen Befehl übertragen werden. Dies beinhaltet typischerweise die Übertragung mehrerer Worte von Daten zwischen einem Satz von Registern in dem Coprozessor und einem zusammenhängenden Satz von Speicherstellen in dem Speicher oder umgekehrt. Wenn der Coprozessor einen Coprozessorbefehl decodiert hat, so weiß er, wie lang ein vektorisierter Lade- oder Speichervorgang sein wird und diese Information wird an den Hauptprozessor als ein Synchronisierungstoken über die Längenschlange zurückgesendet.
  • Bezüglich der Längenschlange ist in bevorzugten Ausführungsformen die vorbestimmte Pipelinestufe eine Decodierstufe in der zweiten Pipeline und die Partnerpipelinestufe ist eine erste Ausführungsstufe in der ersten Pipeline.
  • In bevorzugten Ausführungsformen der vorliegenden Erfindung ist die eine oder zumindest eine der mehreren Synchronisierungsschlangen eine Annahmeschlange, wobei die vorbestimmte Pipelinestufe sich in der zweiten Pipeline befindet und dafür ausgelegt ist zu bewirken, daß in der Annahmeschlange ein Token angeordnet wird, welches angibt, ob ein Coprozessorbefehl in der vorbestimmten Pipelinestufe für die Ausführung durch den Coprozessor angenommen werden soll, und die Partnerpipelinestufe befindet sich in der ersten Pipeline und ist in der Weise betreibbar, daß sie bei Empfang des Token von der Annahmeschlange und wenn das Token angibt, daß der Coprozessorbefehl nicht angenommen werden soll, bewirkt, daß der Coprozessorbefehl durch den Hauptprozessor zurückgewiesen wird.
  • Der Coprozessor kann an der vorbestimmten Pipelinestufe entscheiden, daß er einen ansonsten gültigen Coprozessorbefehl nicht annehmen kann und er leitet diese Information als ein Synchronisierungstoken über die Annahmeschlange an den Hauptprozessor weiter. Wenn ein Befehl durch den Coprozessor nicht angenommen werden kann, spricht man dazu, daß er "abgeprallt" ist. In bevorzugten Ausführungsformen entfernt der Coprozessor, wenn er einen Befehl abprallen läßt, diesen nicht aus seiner Pipeline, sondern wandelt ihn in einen "Phantom"-Befehl um, der sicherstellt, daß die Ausführung dieses Befehls nicht abgeschlossen wird.
  • Bezüglich der Annahmeschlange ist in bevorzugten Ausführungsformen die vorbestimmte Pipelinestufe eine Ausgabestufe in der zweiten Pipeline und die Partnerpipelinestufe ist eine zweite Ausführungsstufe in der ersten Pipeline.
  • Weiterhin ist die Partnerpipelinestufe vorzugsweise in der Weise betreibbar, daß sie bei Empfang des Token von der Annahmeschlange und wenn das Token angibt, daß der Coprozessorbefehl nicht angenommen werden kann, den Coprozessorbefehl aus der ersten Pipeline entfernt. Wie zuvor bezüglich der Löschschlange erwähnt, gibt es eine Anzahl von Arten, auf welche ein Befehl aus einer Pipeline entfernt oder ausgespült werden kann. In bevorzugten Ausführungsformen ist die Partnerpipelinestufe in der ersten Pipeline in der Weise ausgelegt, daß sie bei Empfang eines Token aus der Annahmeschlange, der anzeigt, daß der entsprechende Coprozessorbefehl nicht angenommen werden soll, erlaubt, daß der Befehl durch einige der verbleibenden Stufen der ersten Pipeline weitergeleitet wird, jedoch mit einem gesetzten Flag, um anzuzeigen, daß der Befehl nicht ausgeführt werden soll.
  • Ebenso wie bei den oben beschriebenen verschiedenen Steuerschlangen, die in bevorzugten Ausführungsformen der Erfindung verwendet werden können, können auch eine oder mehrere Synchronisierungsschlangen vorgesehen werden, um als Datenschlangen zwischen dem Hauptprozessor und dem Coprozessor zu wirken. Genauer gesagt ist in bevorzugten Ausführungsformen die mindestens eine oder eine der mehreren Synchronisierungsschlangen eine Speicherschlange, die verwendet wird, wenn der Coprozessorbefehl ein Speicherbefehl ist, der in der Weise betreibbar ist, daß er bewirkt, daß Datenobjekte von dem Coprozessor an den für den Hauptprozessor zugänglichen Speicher übertragen werden, wobei die vorbestimmte Pipelinestufe sich in der zweiten Pipeline befindet und dafür ausgelegt ist, daß sie, wenn sie einen der Speicherbefehle verarbeitet, bewirkt, daß ein Token in der Speicherschlange angeordnet wird, welches jedes zu übertragende Datenobjekt kennzeichnet, und die Pipelinestufe befindet sich in der ersten Pipeline und ist in der Weise betreibbar, daß sie bei Empfang jedes Token aus der Speicherschlange bewirkt, daß das entsprechende Datenobjekt in den Speicher übertragen wird.
  • In bevorzugten Ausführungsformen ist bezüglich der Speicherschlange die vorbestimmte Pipelinestufe eine Ausgabestufe in der zweiten Pipeline und die Partnerpipelinestufe ist eine Adreßerzeugungsstufe in der ersten Pipeline.
  • Einige Übertragungen bzw. Transfers können einen einzelnen Wert oder einen Vektor betreffen. Im letzteren Fall wandelt der Coprozessor einen Mehrfachtransfer effektiv in eine Serie von Einzeltransfers über, indem er den Befehl in der Ausgabeschlange der zweiten Pipeline wiederholt. Dies erzeugt eine Instanz des Speicherbefehls für jeden zu übertragenden Gegenstand. Der Befehl bleibt in der Coprozessorausgabestufe, während er wiederholt ausgeführt wird, und erzeugt Kopien von sich selbst, die sich entlang der Pipeline bewegen. Der erste der wiederholten Befehle wird als der "Kopf" bezeichnet und die anderen werden jeweils als "Schwanz" bezeichnet.
  • In bevorzugten Ausführungsformen ist die eine oder eine der mehreren Synchronisierungsschlangen eine Ladeschlange, die verwendet wird, wenn der Coprozessorbefehl ein Ladebefehl ist, der in der Weise betreibbar ist, daß er bewirkt, daß Datenobjekte aus dem für den Hauptprozessor zugänglichen Speicher in den Coprozessor übertragen werden, wobei die Pipelinestufe sich in der ersten Pipeline befindet und dafür ausgelegt ist, daß sie, wenn sie einen der Ladebefehle verarbeitet, bewirkt, daß in der Ladeschlange ein Token angeordnet wird, welches jedes zu übertragende Datenobjekt identifiziert, und die Partnerpipelinestufe befindet sich in der zweiten Pipeline und ist in der Weise betreibbar, daß sie bei Empfang jedes Token aus der Ladeschlange bewirkt, daß das entsprechende Datenobjekt an den Coprozessor übertragen wird.
  • In bevorzugten Ausführungsformen ist hinsichtlich der Ladeschlange die vorbestimmte Speicherstufe eine Rückschreibestufe in der ersten Pipeline und die Partnerpipelinestufe ist eine Rückschreibestufe in der zweiten Pipeline.
  • Ebenso wie bei Speicherbefehlen können Ladebefehle Übertragungen eines einzelnen Datenwertes oder, über einen Vektorladebefehl, mehrerer Datenwerte angeben. Demnach werden in bevorzugten Ausführungsformen Ladedaten über die Schnittstelle durch die Rückschreibestufe des Hauptprozessors gesendet und von der Rückschreibestufe der Coprozessorpipeline empfangen. In bevorzugten Ausführungsformen erreicht, da die Coprozessorpipeline über die Ausgabestufe hinaus nicht anhalten kann, mit Ausnahme des Wartens auf ein Abschlußtoken, welches erlaubt, daß die Befehle in der Rückschreibestufe in den Ruhezustand versetzt werden, immer der Ladebefehl immer die Rückschreibestufe der Coprozessorpipeline synchron zu der Ankunft der Daten bei dem Coprozessor. Demnach wird in bevorzugten Ausführungsformen die Ladeschlange einfach durch einen Doppelpuffer gebildet, der verwendet wird, um die Daten mit der Ankunft des Ladebefehls in der Rückschreibestufe neu auszurichten.
  • In bevorzugten Ausführungsformen können, wie bereits erwähnt, der Ladebefehl und der Speicherbefehl vektorisierte Coprozessorbefehle sein, welche mehrere Datenobjekte definieren, die übertragen werden sollen, und die Vorrichtung weist weiterhin eine Strom- bzw. Flußsteuerlogik auf, die zumindest entweder der Ladeschlange oder der Speicherschlange zugeordnet ist und in der Weise betreibbar ist, daß sie ein Steuersignal an die vorbestimmte Pipelinestufe sendet, um die Ausgabe von Token durch die vorbestimmte Pipelinestufe zu stoppen, während festgestellt wird, daß die zugehörige Lade- oder Speicherschlange möglicherweise voll wird.
  • Die Stromsteuerlogik ermöglicht es, daß der Datenstrom angehalten wird, wenn die empfangende Pipeline nicht in der Lage ist, die Daten zu verarbeiten. In bevorzugten Ausführungsformen wird die Stromsteuerlogik für die Speicherschlange bereitgestellt, wobei die Stromsteuerlogik in der Weise betreibbar ist, daß sie das Steuersignal nach Empfang einer Anzeige von dem Hauptprozessor ausgibt, daß die Partnerpipelinestufe ein Datenobjekt nicht annehmen kann. In Anbetracht der bereits erwähnten Tatsache, daß in bevorzugten Ausführungsformen der Ladebefehl immer die Rückschreibestufe der Coprozessorpipeline synchron mit der Ankunft der Daten an dem Coprozessor über die Ladeschlange erreicht, besteht in bevorzugten Ausführungsformen kein Bedarf an einer der Ladeschlange zugeordneten Stromsteuerlogik. Es versteht sich jedoch, daß in Implementierungen, in welchen eine solche Synchronisierung nicht garantiert werden kann, die Stromsteuerlogik dann ebenfalls auch für die Ladeschlange bereitgestellt werden könnte, falls erforderlich.
  • In bevorzugten Ausführungsformen erfordert das Speichern von Daten eine Stromsteuerung, um zu ermöglichen, daß die Ladespeichereinheit des Hauptprozessors den Datenstrom von dem Coprozessor anhält. Dies geschieht durch Senden eines Stopsignals an den Coprozessor. Wenn in bevorzugten Ausführungsformen dieses Signal zwei Taktzyklen benötigt, um den Coprozessor zu erreichen, so wird es vorzugsweise erzeugt, sobald ein Risiko besteht, daß die Speicherschlange voll werden könnte. Bei einer relativ kurzen Schlange wird dieses Risiko real, sobald die Ladespeichereinheit des Hauptprozessors ein Datenobjekt nicht annehmen kann und demnach wird in bevorzugten Ausführungsformen das Stopsignal an den Coprozessor gesendet, sobald die Ladespeichereinheit des Hauptprozessors Daten nicht annehmen kann.
  • Manchmal ist es erforderlich, daß der Hauptprozessor in der Lage ist, Befehle in der Coprozessorpipeline zu identifizieren bzw. zu kennzeichnen. Dies ist beispielsweise für das Spülen erforderlich, so daß der Hauptprozessor dem Coprozessor anzeigen kann, welche Befehle ausgespült werden sollen. Der Hauptprozessor gibt daher jedem an den Coprozessor gesendeten Befehl ein Tag (einen Anhänger), das in bevorzugten Ausführungsformen aus einem Vorrat von Werten entnommen wird, welcher groß genug ist, so daß alle Tags in der Pipeline jederzeit eindeutig sind.
  • In bevorzugten Ausführungsformen enthält jedes Token ein Tag, welches den Coprozessorbefehl identifiziert, auf welchen das Token sich bezieht.
  • Dementsprechend ist in bevorzugten Ausführungsformen der Hauptprozessor in der Weise betreibbar, daß, wenn es erforderlich ist, Coprozessorbefehle sowohl aus der ersten als auch aus der zweiten Pipeline auszuspülen, er ein Spülsignal an den Coprozessor rundsendet, welches das Tag kennzeichnet, das sich auf den ältesten Befehl bezieht, der ausgespült werden soll, wobei der Coprozessor in der Lage ist, diesen ältesten Befehl anhand des Tags zu identifizieren und aus der zweiten Pipeline diesen ältesten Befehl und alle späteren Befehle innerhalb des Coprozessors auszuspülen.
  • Weiterhin werden in bevorzugten Ausführungsformen die mindestens eine oder eine oder mehrere der Synchronisierungsschlangen in Reaktion auf das Spülsignal ausgespült, wobei das Tag verwendet wird, um zu kennzeichnen, welche Token innerhalb der Schlange ausgespült werden sollen.
  • In bevorzugten Ausführungsformen wird der Spülmechanismus vereinfacht, wenn aufeinanderfolgende Coprozessorbefehle zusammenhängende bzw. kontinuierlich aufeinanderfolgende Tags haben. Dies wird in bevorzugten Ausführungsformen erreicht, indem die Tagnummer lediglich dann schrittweise erhöht wird, wenn der Befehl, der an den Coprozessor weitergeleitet wird, ein Coprozessorbefehl ist. Dies geschieht nach dem Senden des Befehls und demnach ändert sich das Tag, nachdem ein Coprozessor gesendet worden ist und nicht vorher. In bevorzugten Ausführungsformen ist es nicht möglich, das Tag um eine Stufe bzw. einen Schritt heraufzusetzen, bevor der Befehl gesendet wird, da der Hauptprozessor noch keine Zeit gehabt hat, den Befehl zu decodieren, um festzustellen, um welche Art von Befehl es sich handelt. Wenn die Coprozessordecodierungsstufe die Befehle, die keine Coprozessorbefehle sind, entfernt, so verbleibt darin ein Befehlsstrom, der zusammenhängende bzw. aufeinanderfolgende Tags hat.
  • Es versteht sich, daß die Synchronisierungsschlangen eine Vielfalt von Formen annehmen können. In bevorzugten Ausführungsformen weist jedoch jede Synchronisierungsschlange einen First-In-First-Out(FIFO)-Puffer auf, der eine vorbestimmte Anzahl von Einträgen zum Speichern von Token hat. In bevorzugten Ausführungsformen hat jede der Schlangen außer der Ladeschlange drei Einträge oder "Slots" für das Speichern von Token. Wie zuvor bereits erwähnt, wird die Ladeschlange bevorzugte Ausführungsformen vorzugsweise mit einem Doppelpuffer versehen.
  • In gewissen Ausführungsformen kann eine Mehrzahl von Coprozessoren bereitgestellt werden, wobei jede Synchronisierungsschlange eine Pipelinestufe in dem Hauptprozessor mit einer Pipelinestufe in einem der Coprozessoren verbindet. Aus Gründen der Ökonomie wird in bevorzugten Ausführungsformen sichergestellt, daß so wenig wie möglich von der Coprozessorschnittstelle dupliziert wird. Insbesondere sollten die Coprozessoren in bevorzugten Ausführungsformen die Längen-, Annahme- und Speicherdatenschlangen, die durch den Hauptprozessor aufrecht erhalten werden, gemeinsam verwenden. Wenn diese Schlangen gemeinsam verwendet werden, kann zu einem gegebenen Zeitpunkt jeweils nur ein Coprozessor die Schlangen verwenden, was am einfachsten dadurch sichergestellt wird, daß man nur einem Coprozessor erlaubt, zu irgendeinem gegebenen Zeitpunkt aktiv zu sein. Dieses ist jedoch im allgemeinen keine wesentliche Einschränkung, da allgemein gesprochen zu einem gegebenen Zeitpunkt nur ein Coprozessor in Gebrauch ist. Genauer gesagt wird ein Prozessor typischerweise über eine Treibersoftware getrieben bzw. angesteuert, die nur einen Coprozessor ansteuert. Aufruf an die Treibersoftware und Antworten von dieser stellen generell sicher, daß es mehrere Kernbefehle zwischen der Verwendung eines Coprozessors und der Verwendung eines anderen Coprozessors gibt.
  • Es versteht sich, daß die auf Token basierende Pipelinesynchronisierungstechnik der vorliegenden Erfindung sowohl auf asynchrone als auch auf synchrone Modelle von Datenverarbeitungsvorrichtungen anwendbar ist. In bevorzugten Ausführungsformen ist jedoch die Datenverarbeitungsvorrichtung ein synchrones Modell, so daß die Anordnung der Token in der Schlange durch die vorbestimmte Pipelinestufe und der Empfang aus der Schlange durch die Partnerpipelinestufe auf die wechselnden Flanken eines Taktzyklus hin bewirkt werden.
  • Unter einem zweiten Aspekt gesehen, stellt die vorliegende Erfindung ein Verfahren zur Synchronisierung zwischen Pipelines in einer Datenverarbeitungsvorrichtung bereit, wobei die Datenverarbeitungsvorrichtung einen Hauptprozessor aufweist, der in der Weise betreibbar ist, daß er eine Folge von Befehlen ausführt, und einen Coprozessor aufweist, der in der Weise betreibbar ist, daß er Coprozessorbefehle in der Folge von Befehlen ausführt, wobei der Hauptprozessor eine erste Pipeline aufweist, die eine erste Mehrzahl von Pipelinestufen hat, und der Coprozessor eine zweite Pipeline aufweist, die eine zweite Mehrzahl von Pipelinestufen hat, und wobei jeder Coprozessorbefehl in der Weise ausgelegt ist, daß er sowohl durch die erste Pipeline als auch durch die zweite Pipeline geleitet wird, wobei das Verfahren die Schritte aufweist: (a) Verbinden einer vorbestimmten Pipelinestufe in einer der Pipelines mit einer Partnerpipelinestufe in der anderen der Pipelines über eine Synchronisierungsschlange, (b) Anordnen eines Token in der Synchronisierungsschlange, wenn die vorbestimmte Pipelinestufe einen Coprozessorbefehl verarbeitet, (c) nach Empfang des Token von der Synchronisierungsschlange durch die Partnerpipelinestufe Verarbeiten des Coprozessorbefehls innerhalb der Partnerpipelinestufe, wodurch die Synchronisierung der ersten und zweiten Pipelines zwischen der vorbestimmten Pipelinestufe und der Partnerpipelinestufe erhalten wird.
  • Kurzbeschreibung der Figuren
  • Die vorliegende Erfindung wird lediglich beispielhaft unter Bezug auf eine bevorzugte Ausführungsform derselben beschrieben, wie sie in den beigefügten Figuren veranschaulicht wird, wobei:
  • 1 ein Blockdiagramm eines Systems ist, in welchem die Synchronisierungstechniken von bevorzugten Ausführungsformen der vorliegenden Erfindung implementiert sein können,
  • 2A ein Diagramm ist, welches schematisch einen Pipelineprozessor gemäß bevorzugten Ausführungsformen der vorliegenden Erfindung zeigt,
  • 2B ein Diagramm ist, welches schematisch einen Pipelinecoprozessor gemäß bevorzugten Ausführungsformen der vorliegenden Erfindung zeigt,
  • 3 ein Diagramm ist, welches schematisch die Pipelinestufen des Prozessorkerns, die Pipelinestufen des Coprozessors und die Synchronisierungssteuerschlangen veranschaulicht, welche eine Kommunikation zwischen diesen gemäß bevorzugten Ausführungsformen der vorliegenden Erfindung bereitstellen,
  • 4 ein detaillierteres Blockdiagramm ist, welches die verschiedenen Pipelines und die sie verbindenden Schlangen darstellt,
  • 5 ein Diagramm ist, welches schematisch die Kommunikation zwischen der Ladespeichereinheit des Hauptprozessors und der Coprozessorpipeline für Lade- und Speichervorgänge zeigt,
  • 6 ein Diagramm ist, welches den Aufbau der Schlangen gemäß bevorzugten Ausführungsformen der vorliegenden Erfindung zeigt,
  • 7 ein Zeitablaufdiagramm ist, welches das Lesen und Schreiben einer Schlange zeigt,
  • 8 ein Diagramm ist, welches das Konzept der Stromsteuerung veranschaulicht, wie es in bevorzugten Ausführungsformen der vorliegenden Erfindung verwendet wird,
  • 9 ein Diagramm ist, welches veranschaulicht, wie die Befehlsschlange in einer bevorzugten Ausführungsform der vorliegenden Erfindung implementiert wird,
  • 10 ein Diagramm ist, welches schematisch den Normalbetrieb der Wechselwirkungen zwischen den Kern- und Coprozessorpipelines zeigt,
  • 11 ein Diagramm ist, welche darstellt, wie Kern- und Coprozessorpipelines sich verhalten, wenn der Coprozessor in seiner Ausgabestufe gemäß einer Ausführungsform der vorliegenden Erfindung anhält,
  • 12 ein Diagramm ist, welches veranschaulicht, wie die Kern- und Coprozessorpipelines sich verhalten, wenn ein Coprozessorbefehl gemäß einer Ausführungsform der vorliegenden Erfindung durch den Kern in seiner Ausgabestufe gelöscht wird,
  • 13 ein Diagramm ist, welches darstellt, wie die Kern- und Coprozessorpipelines sich verhalten, wenn ein Coprozessorbefehl gemäß einer Ausführungsform der vorliegenden Erfindung von dem Coprozessor abprallt,
  • 14 ein Diagramm ist, welches die Art und Weise zeigt, in welcher die Pipeline mit einem Befehl umgehen, der durch den Kern gelöscht wird und den außerdem der Coprozessor gemäß einer Ausführungsform der vorliegenden Erfindung abprallen läßt,
  • 15 ein Diagramm ist, welches zeigt, wie die Kern- und Coprozessorpipelines sich verhalten, wenn der Kern gemäß einer Ausführungsform der vorliegenden Erfindung ein Spülsignal an den Coprozessor sendet,
  • 16 ein Diagramm ist, welches schematisch den in einer Ausführungsform der vorliegenden Erfindung verwendeten Schlangenspülansatz darstellt,
  • 17 ein Diagramm ist, welches eine Befehlswiederholung für einen vektorisierten Ladebefehl "C" gemäß einer Ausführungsform der vorliegenden Erfindung zeigt,
  • 18 ein Diagramm ist, welches schematisch das Puffern von Ladedaten gemäß einer Ausführungsform der vorliegenden Erfindung zeigt, und
  • 19 ein Diagramm ist, welches darstellt, wie ein Ladebefehl in dem Kern in die Ladespeichereinheit des Kernes eintritt und die Erzeugung eines Objektes von Ladedaten auslöst, welches dann gemäß einer Ausführungsform der Erfindung an den Coprozessor weitergeleitet wird.
  • BESCHREIBUNG BEVORZUGTER AUSFÜHRUNGSFORMEN
  • 1 ist ein Blockdiagramm, welches ein Datenverarbeitungssystem veranschaulicht, in welchem die Synchronisierungstechniken bevorzugter Ausführungsformen der vorliegenden Erfindung verwendet werden können. Wie in 1 dargestellt, ist ein Prozessorkern 40 mit einem Befehlscache oder einer anderen Speichereinrichtung 10 verbunden, wobei der Prozessorkern 40 auf erforderliche Befehle daraus Zugriff hat. Innerhalb des Prozessorkerns 40 ist eine Heranholeinheit 20 vorgesehen, um über einen Pfad 50 Anforderungen nach Befehlen auszugeben, die durch die Heranholeinheit als diejenigen bestimmt werden, die für den mit Pipeline versehenen Prozessor 30 erforderlich sind. Der Befehlsspeicher 10, aus welchem die Befehle geholt werden, liefert dann die Befehle über den Pfad 60 an die Heranholeinheit 20, wobei sie von dort über Pfad 70 in den Pipelineprozessor 30 geleitet werden. Wenn Befehle ausgeführt werden, bildet der Pipelineprozessor 30 eine Schnittstelle zu Registern der Registerbank 35, die Datenwerte enthält, die durch die Befehle manipuliert werden sollen. Ladebefehle können verwendet werden, um Datenwerte aus dem Datenspeicher 87 in die Registerbank zu laden, und Speicherbefehle können verwendet werden, um Datenwerte aus der Registerbank 35 in dem Datenspeicher 87 zu speichern. Datenverarbeitungsbefehle können dann mit den Datenwerten ausgeführt werden, die in bestimmten Registern der Registerbank 35 gespeichert sind.
  • Einige Befehle in der Folge von Befehlen, die durch die Heranholeinheit herangeholt wurden, können Verzweigungsbefehle sein, die dafür ausgelegt sind, eine Veränderung in dem Befehlsstrom zu bewirken. Einige Verzweigungsbefehle spezifizieren die Zieladresse für die Verzweigung innerhalb des Opcodes (Operationscodes) des Befehles selbst und demnach kann eine gewisse Vorhersage dieser Verzweigungsbefehle erfolgen, um die Heran holeinheit 20 dabei zu unterstützen zu entscheiden, welcher Befehl im Anschluß an einen solchen Verzweigungsbefehl herangeholt werden soll. Solche Verzweigungsvorhersage wird durch die Verzweigungsvorhersagelogik 25 ausgeführt. Wenn die Verzweigungsvorhersagelogik 25 vorhersagt, daß ein solcher Verzweigungsbefehl ausgeführt wird und daß demnach die Abzweigung genommen wird, wird die Heranholeinheit 20 so ausgelegt, daß sie als den nächsten Befehl den durch die Zieladresse angegebenen Befehl holt. Wenn umgekehrt die Verzweigungsvorhersagelogik 25 vorhersagt, daß der Verzweigungsbefehl nicht ausgeführt werden wird, und daß dementsprechend die Abzweigung nicht genommen wird, holt die Heranholeinheit 20 als nächsten Befehl den Befehl bei der nächstfolgenden Adresse in dem Befehlsspeicher 10.
  • Offensichtlich ist es wichtig, daß dann, wenn innerhalb des Pipelineprozessors 30 letztlich entschieden wird, ob irgendwelche derartige Verzweigungsbefehle ausgeführt werden, die relevante Information an die Heranholeinheit 20 zurückgeleitet wird, wenn die Heranholeinheit 20 irgendeine Aktion unternehmen soll. Beispielsweise ist es für vorhersehbare Verzweigungsbefehle notwendig, die Heranholeinheit 20 zu informieren, wenn die getroffene Vorhersage falsch war. Wenn beispielsweise die Verzweigungsvorhersagelogik 25 vorhergesagt hat, daß die Abzweigung genommen wird und damit den Befehl von der Zieladresse geholt hat, wenn dann jedoch der Befehl anschließend durch den Pipelineprozessor 30 ausgeführt wird, so wird festgestellt, daß die Verzweigungsanweisung tatsächlich nicht ausgeführt werden soll, so muß eine Wiederherstellungsadresse als ein Zwangs-PC-Signal über den Pfad 80 ausgegeben werden, und in diesem Fall ist die Wiederherstellungsadresse die nächstfolgende Adresse, die auf den Verzweigungsbefehl folgt. In ähnlicher Weise muß, wenn die Verzweigungsvorhersagelogik 25 vorhergesagt hat, daß der Verzweigungsbefehl nicht ausgeführt wird, tatsächlich jedoch der Pipelineprozessor 30 anschließend bestimmt, daß er ausgeführt werden soll, wiederum eine Wiederherstellungsadresse über den Pfad 80 an die Heranholeinheit 20 ausgegeben werden, wobei in diesem Fall die Wiederherstellungsadresse die Zieladresse für die Verzweigung ist. Anderenfalls ist, für den Fall, daß die Verzweigungsvorhersage korrekt war, keine weitere Aktion erforderlich und kein Zwangs-PC-Signal muß über den Pfad 80 an die Heranholeinheit 20 ausgegeben werden.
  • Ein Grund dafür, daß Verzweigungsbefehle tatsächlich nicht ausgeführt werden, liegt darin, daß Verzweigungsbefehle oftmals als bedingte Befehle bzw. Anweisungen spezifiziert sind, die nur dann ausgeführt werden, wenn zum Zeitpunkt der Ausführung eine bestimmte Bedingung bzw. ein bestimmter Zustand vorliegt. Diese unterschiedlichen Zustände werden unter Bezug auf einen Satz von Zustandscodes spezifiziert und geben damit an, daß eine oder mehrere der Zustandscodes einen bestimmten Wert haben müssen, wenn der Befehl ausgeführt werden soll. Wenn es möglich ist, gewisse Vorhersagen über den Status der Zustands- bzw. Bedingungscodes zu machen und dementsprechend eine Vorhersage zu tref fen, ob ein Verzweigungsbefehl ausgeführt werden wird, kann letztlich nur dann, wenn der Verzweigungsbefehl einen vorbestimmten Punkt innerhalb des Pipelineprozessors 30 erreicht hat, die vollständige Auswertung der Zustands- bzw. Bedingungscodes vorgenommen werden, da die Zustandscodes durch einzelne Befehle für den Zustandscode in der Befehlssequenz aktualisierbar sind und damit der Status der Zustandscodes sich im Verlaufe der Zeit verändert.
  • Gewisse Befehle innerhalb der Befehlssequenz können auch Coprozessorbefehle sein, die innerhalb des Pipelineprozessors 130 des Coprozessors 110 ausgeführt werden sollen. Derartige Coprozessorbefehle werden über den Pfad 95 an den Pipelineprozessor 130 des Coprozessors 110 ausgegeben. Der Pipelineprozessor 130 führt dann den Coprozessorbefehl aus, ruft die Coprozessorregister 120 auf, soweit dies erforderlich ist, und, wenn die Ergebnisse des Coprozessorbefehles an den Kern 40 zurückgegeben werden müssen, so werden sie über den Pfad 100 zurückgegeben.
  • Auch wenn der Coprozessorbefehl über den Pfad 95 an den Coprozessor weitergeleitet wird, so wird er auch über die verschiedenen Pipelinestufen des Pipelineprozessors 30 des Kerns 40 weitergeleitet, um beispielsweise eine Feststellung zu treffen, ob dieser Coprozessorbefehl tatsächlich ausgeführt werden sollte, wenn dieser Coprozessorbefehl ein bedingter Coprozessorbefehl ist, der von dem Status der Zustandscodes zum Zeitpunkt der Ausführung abhängig ist. Steuersignale werden zwischen dem Pipelineprozessor 30 und dem Pipelineprozessor 130 über vorbestimmte Schlangen weitergeleitet, um sicherzustellen, daß das Fortschreiten eines Coprozessorbefehls durch beide Pipelines an den erforderlichen Punkten synchron bleibt. Dieser Vorgang wird später noch genauer erläutert.
  • 2A ist ein Blockdiagramm, welches gemäß bevorzugten Ausführungsformen der vorliegenden Erfindung die verschiedenen Pipelinestufen der innerhalb des Pipelineprozessors 30 nach 1 vorgesehenen Pipeline bereitstellt. Bei der Stufe 190 wird ein Befehl 20 herangeholt, woraufhin er in der Decodierstufe 200 decodiert wird und anschließend an eine Ausgabestufe 210 weitergeleitet wird, wo die für den Befehl erforderlichen Daten von geeigneten Registern der Registerbank 35 erhalten werden.
  • An diesem Punkt verzweigt der Prozessor in zwei untergeordnete Pipelines, wobei die erste untergeordnete Pipeline die Pipelinestufen 220, 230, 240 und 250 enthält und die zweite untergeordnete Pipeline die Pipelinestufen 260, 270, 280 und 290 enthält. Die erste Teilpipeline ist eine Lade-/Speicherpipeline 222, die hier auch als eine Lade-/Speichereinheit (LSU) bezeichnet wird. Die Lade-/Speicherpipeline wird verwendet, um Lade- oder Speicheranweisungen zu verarbeiten und dementsprechend wird ein Lade- oder Speicherbefehl von der Pipelinestufe 210 in die Pipelinestufe 220 geleitet. Der bei der Pipelinestufe 220 durchgeführte Prozeß besteht darin, die für den Speicherzugriff erforderliche Adresse zu erzeugen, die verwendet wird, um den Lade- oder Speichervorgang zu bewirken. Dieser Prozeß umfaßt typischerweise das Addieren der Werte von zwei Registern oder das Addieren des Wertes eines Registers mit einem spontanen bzw. unmittelbar vorliegenden Wert, der innerhalb des Befehls angegeben wird, etc. Stufen 230 und 240 sind zwei Speicherpipelinestufen, während welcher der aufgrund des Lade- oder Speicherbefehls erforderliche Speicherzugriff stattfindet. In bevorzugten Ausführungsformen der Erfindung, wie sie in 2A dargestellt sind, gibt es zwei Speicherstufen 230, 240, da Lade- und Speichervorgänge in derartigen Ausführungsformen typischerweise zumindest zwei Taktzyklen benötigen.
  • Wenn der Speicherzugriff abgeschlossen ist, so bewegt sich der Befehl von der Pipelinestufe 240 des Speichers 2 in die Rückschreibestufe 250, die auch als eine Ruhestandsstufe bezeichnet wird. In der Rückschreibestufe wird die Registerbank 35 für das Aktualisieren vorbereitet, um das Ergebnis des Lade- oder Speichervorganges zu reflektieren, wobei diese Aktualisierung am Ende der Rückschreibestufe stattfindet.
  • Irgendwelche arithmetischen Logikbefehle, wie z. B. Additions- oder Subtraktionsbefehle, werden von der Pipelinestufe 210 in die Pipelinestufe 260 der zweiten untergeordneten Pipeline 262 geleitet (die hier auch als die ALU-Pipeline bezeichnet wird), wobei diese Stufe eine Verschiebungslogik bereitstellt, um irgendeine erforderliche Verschiebung der Operanden zu ermöglichen, die ausgeführt werden soll. Der Befehl wird dann in die Pipelinestufe 270 geleitet, welche eine arithmetische Logikeinheit für die Ausführung dieses arithmetischen Logikbefehls beinhaltet. Nach dieser Ausführungsstufe wird der Befehl an die Sättigungsstufe 280 der Pipeline weitergeleitet, wo irgendeine erforderliche Sättigung des Ergebnisses durchgeführt wird. Beispielsweise erfordern einige arithmetische Logikbefehle, daß das Ergebnis bis auf eine vorbestimmte Anzahl von Bits gesättigt bzw. aufgefüllt wird und damit beispielsweise erfordert, daß ein 16 Bit-Ergebnis auf ein 9 Bit-Ergebnis gesättigt wird. Ein solcher Prozeß wird innerhalb der Pipelinestufe 280 ausgeführt. Nach irgendeiner erforderlichen Sättigung wird der Befehl dann an die Rückschreibestufe 290 weitergeleitet, die hier auch als eine Ruhestandsstufe bezeichnet wird. Wie zuvor bereits unter Bezug auf die Rückschreibestufe 250 beschrieben, besteht der Zweck der Rückschreibestufe darin, den Zustand der Datenverarbeitungsvorrichtung zu aktualisieren und insbesondere die Registerbank 35 zu aktualisieren, was das Ergebnis der Ausführung des Befehls in der Rückschreibestufe betrifft.
  • 2B veranschaulicht die verschiedenen Pipelinestufen der innerhalb des Pipelineprozessors 130 des Coprozessors 110 nach 1 gemäß bevorzugten Ausführungsformen der vorliegenden Erfindung vorgesehenen Pipeline. Die ersten beiden Stufen sind eine Decodierstufe 205 und eine Ausgabestufe 215. Der Befehl durchläuft dann fünf Ausführungsstufen 225, 235, 245, 255 und 265, woraufhin der Befehl in eine Rückschreibestufe 275 eintritt, wo die Coprozessorregister 120 mit Blick auf das Ergebnis der Ausführung des Coprozessorbefehls in der Rückschreibestufe aktualisiert werden.
  • Wie noch genauer unter Bezug auf die verbleibende Diagramme diskutiert wird, werden verschiedene Schlangen zwischen bestimmten Pipelinestufen des Prozessorkerns und des Coprozessors bereitgestellt, um zu ermöglichen, daß eine Synchronisierung zwischen den Pipelinestufen stattfindet, die jeweils durch eine Schlange verbunden sind, welche das Token-basierte Schema nutzen. Genauer gesagt können eine oder mehrere Steuerschlangen 285 zwischen der ALU-Pipeline 262 und der Coprozessorpipeline bereitgestellt werden und zusätzlich können eine oder mehrere Datenschlangen 295 zwischen der LSU-Pipeline 222 und dem Kern sowie der Coprozessorpipeline vorgesehen werden.
  • Eine Beschreibung der auf Token beruhenden Pipelinesynchronisierungstechnik, die in bevorzugten Ausführungsformen der vorliegenden Erfindung verwendet wird, um sicherzustellen, daß die Pipelines für kritische Informationsübertragungen korrekt synchronisiert sind, wird nunmehr unter Bezug auf die 3 bis 19 bereitgestellt. In der folgenden Beschreibung wird der Hauptprozessor als der Kern bezeichnet und der Coprozessor wird auch als "GCP" oder als ursprünglicher Coprozessor bezeichnet. Die Beschreibung der 3 bis 19 wird unter Bezug auf die folgenden numerierten Paragraphen bereitgestellt.
  • 1 EINLEITUNG
  • Der Kern muß möglicherweise Befehle an eine Anzahl von Coprozessoren weiterleiten und Daten mit diesen austauschen. Diese Coprozessoren sollen mehr oder weniger im Gleichschritt mit dem Kern laufen und weisen in ähnlicher Weise wie der Kern eine Pipelineanordnung auf. Befehle werden aus der Heranholstufe der Kernpipeline geleitet, um durch den Coprozessor decodiert zu werden, welcher dann den decodierten Befehl auf seine Pipeline schickt. Coprozessorbefehle können durch den Kern gelöscht werden, wenn ein Zustandscode fehlerhaft ist oder die gesamte Coprozessorpipeline im Falle einer falsch vorhergesagten Verzweigung gespült wird. Das Laden und Speichern von Daten muß auch zwischen der Kern-LSU und der Coprozessorpipeline weitergeleitet werden.
  • Eine Haupteinschränkung, welcher die Coprozessorschnittstelle unterliegt, besteht darin, daß sie über eine Verzögerung von zwei Zyklen arbeiten muß, d. h. irgendein Signal, welches von dem Kern an den Coprozessor oder umgekehrt geleitet wird, muß einen vollständigen Taktzyklus erhalten, um von dem einen zu dem anderen weiterzuschreiten. Dies bedeutet, daß ein Signal, welches die Schnittstelle durchläuft, aus einem Register auf einer Seite der Schnittstelle ausgetaktet und direkt in ein anderes Register auf der anderen Seite eingetaktet werden muß, wobei kein kombinatorischer Prozeß dazwischen kommen darf. Diese Einschränkung entsteht aufgrund der Tatsache, daß der Kern und der Coprozessor einen beträchtlichen Abstand voneinander haben können und daß großzügige Zeittoleranzen gewährt werden müssen, um Signallaufzeiten zu berücksichtigen. Diese Verzögerung in dem Signallauf macht es schwierig, eine Pipelinesynchronisierung aufrecht zu erhalten, was ein eng gekoppeltes Synchronisationsverfahren ausscheiden läßt.
  • Die folgende Beschreibung erläutert ein Token-basiertes Pipelinesynchronisationsverfahren, das einen gewissen Schlupf zwischen den beiden Pipelines erlaubt, während es doch sicherstellt, daß die Pipelines für kritische Transfers von Informationen korrekt ausgerichtet bzw. synchronisiert sind.
  • 2 BESCHREIBUNG
  • Die GCP-Schnittstelle bewirkt eine lose Synchronisierung zwischen den beiden Pipelines durch Austauschen von Token von einer Pipeline zu der anderen. Diese Token durchlaufen Schlangen zwischen den Pipelines und können zusätzliche Information tragen. In vielen Fällen besteht der primäre Zweck einer Schlange darin, Information über den Befehl, der verarbeitet wird, zu tragen, oder um eine Pipeline über Ereignisse zu informieren, die in der anderen auftreten. Token werden erzeugt, wann immer ein Coprozessorbefehl aus einer relevanten Pipelinestufe in die nächste Stufe geleitet wird. Diese Token werden durch die Partnerstufe in der anderen Pipeline aufgenommen und werden verwendet, um zu ermöglichen, daß der entsprechende Befehl in dieser Stufe sich weiterbewegt. Die Bewegung von Coprozessorbefehlen durch jede Pipeline wird durch die Bewegung von Token entlang der verschiedenen Schlangen, welche die Pipelines verbinden, exakt angepaßt. Die generische Coprozessorschnittstelle ist demnach datengesteuert, anstatt durch eine Steuerung gesteuert zu werden.
  • 2.1 Coprozessorbefehle
  • Die GCP muß möglicherweise eine Anzahl von Befehlen ausführen, die aus einem Satz von Befehlen genommen werden, welche für Coprozessoren spezifisch sind. Ein gegebener Coprozessor darf möglicherweise nicht alle möglichen Coprozessorbefehle ausführen und kann bzw. muß diejenigen Befehle zurückweisen, die er nicht handhaben kann. Tabelle 1 unten listet alle Coprozessorbefehle auf, die durch einen bestimmten Prozessorkern unterstützt werden, nämlich einen der ARM-Prozessorkerne, welche von ARM Limited in Cambridge, Vereinigtes Königreich, entwickelt wurden, und sie liefert eine kurze Beschreibung jedes Befehls.
    Befehl Datentransfer vektorisiert Beschreibung
    CDP keiner nein verarbeitet Information, die sich bereits im Coprozessor befindet
    MRC speichern nein überträgt Information von dem Coprozessor an die Kernregister
    MCR laden nein überträgt Information aus den Kernregistern zu dem Coprozessor
    MRRC speichern nein überträgt Information von dem Coprozessor an ein Paar von Registern in dem Kern
    MCRR laden nein überträgt Information von einem Paar von Registern im Kern zu dem Coprozessor
    STC speichern ja überträgt Information von dem Coprozessor in den Speicher – kann wiederholt werden, um einen Vektor zu übertragen
    LDC laden ja überträgt Information von dem Speicher in den Coprozessor – kann wiederholt werden, um einen Vektor zu übertragen
    Tabelle 1 – Coprozessorbefehle
  • Die Coprozessorbefehle fallen in drei Hauptgruppen, nämlich Ladevorgänge, Speichervorgänge und Verarbeiten von Befehlen. Die Lade- und Speicherbefehle ermöglichen, daß Information zwischen dem Kern und dem Coprozessor weitergeleitet bzw. ausgetauscht wird. Einige können vektorisiert sein, d. h. sie ermöglichen, daß mehrere Werte in einem einzelnen Befehl übertragen werden. Dies umfaßt typischerweise die Übertragung mehrerer Worte von Daten zwischen einem Satz von Registern in dem Coprozessor und einem zusammenhängenden Satz von Speicherstellen in dem Speicher. Andere Befehle, z. B. MCR und MRC ermöglichen die Übertragung von Daten zwischen dem Kern und den Coprozessorregistern. Der CDP-Befehl steuert die Ausführung einer spezifizierten Operation mit Daten, die bereits innerhalb des Coprozessors vorhanden sind, Schreiben des Ergebnisses zurück in ein Coprozessorregister oder Verändern des Zustandes des Coprozessors auf irgendeine andere Art und Weise. Welche Operation ausgeführt werden soll, kann durch Opcodefelder (Operationscodefelder) innerhalb des Befehls angegeben werden.
  • Die Kernpipeline handhabt alle Befehle, und zwar sowohl Kern- als auch Coprozessorbefehle. Der Coprozessor andererseits behandelt nur Coprozessorbefehle, so daß die Coprozessorpipeline wahrscheinlich für einen beträchtlichen Teil der Zeit leer ist.
  • 2.2 Coprozessorpipeline
  • Die GCP-Pipeline ist der Kernpipeline sehr ähnlich, jedoch fehlen ihr die Heranholstufen. Befehle werden statt dessen von dem Kern in die Decodierstufe der GCP-Pipeline weitergeleitet. Die Decodierstufe decodiert dann den Befehl, und weist Befehle, die keine Co prozessorbefehle sind und irgendwelche Coprozessorbefehle, die nicht die passende Coprozessornummer enthalten, zurück. Die Länge irgendeiner vektorisierten Datenübertragung wird ebenfalls an diesem Punkt festgestellt und an den Kern zurückgesendet. Der decodierte Befehl läuft dann in die Ausgabestufe. Diese Stufe entscheidet, ob diese bestimmte Instanz des Befehls angenommen werden kann. Falls nicht, möglicherweise weil sie ein nicht existierendes Register anspricht, läßt sie den Befehl abprallen und teilt dem Kern mit, daß er nicht angenommen werden kann. Wenn der Befehl sowohl gültig ist als auch ausführbar ist, so durchläuft er die Ausführungspipeline EX1 bis EX6. Am Grund der Pipeline, in EX6 (die hier auch als die Rückschreibe(WB)-Stufe bezeichnet wird) wartet der Befehl darauf, in den Ruhezustand versetzt zu werden, was er tun kann, wenn er ein passendes Token von einer anderen Schlange empfängt, die durch den Kern versorgt wird.
  • 2.3 Token-basierte Pipelinesynchronisierung
  • 3 zeigt die Kern- und GCP-Pipelines und die Synchronisierungsschlangen, die eine Kommunikation zwischen diesen bilden. Jede Schlange ist als ein sehr kurzer First-In-First-Out(FIFO)-Puffer implementiert. Es ist keine ausdrückliche Stromsteuerung für die Schlangen erforderlich, da die Pipelinelängen zwischen den Schlangen die Anzahl von Objekten begrenzen, die irgendeine Schlange zu irgendeinem gegebenen Zeitpunkt halten kann. Die dargestellte Geometrie erfordert, daß nicht mehr als drei Stufen bzw. Positionen oder Slots in jeder Schlange verfügbar sind. Die einzige Statusinformation, die erforderlich ist, ist ein Flag, welches anzeigt, wenn die Schlange leer ist. Dies muß nur durch das Empfangsende der Schlange überwacht werden und es wird hierdurch festgelegt, ob die zugehörige Pipelinestufe sich weiter bewegen kann. Irgendwelche Information, welche von der Schlange getragen wird, kann gleichzeitig gelesen und bearbeitet werden.
  • Die Operation der Pipelinesynchronisierung wird durch Beschreiben des Zweckes jeder der Schlangen beschrieben.
  • 2.3.1 Befehlsschlange
  • Der Kern leitet jeden Befehl, der seine Heranholstufe 190 verläßt, in die Befehlsschlange 300. Im Idealfall sollte er nur die Coprozessorbefehle weiterleiten, hat jedoch in dieser Stufe noch nicht die Zeit gehabt, den Befehl zu decodieren. Es bleibt den GCP überlassen, den Befehl bei Ankunft in seiner eigenen Decodierstufe 205 zu decodieren und die Befehle, die keine Coprozessorbefehle sind, zurückzuweisen. Dies kann er ohne Meldung ("schweigend") tun, da der Kern keine Bestätigung der Entfernung dieser Befehle benötigt, weil er in seiner Decodierstufe 200 den Typ jedes Befehls bestimmt. Die Befehlsschlange 300 hat eine Länge von drei Positionen bzw. Slots.
  • 2.3.2 Löschschlange
  • Möglicherweise möchte der Kern einen Befehl löschen, den er bereits an den Coprozessor weitergeleitet hat. Dies kann geschehen, falls der Befehl seine Zustandscodes nicht erfüllt, was es erfordert, daß der Befehl aus dem Befehlsstrom sowohl in dem Kern als auch in dem Coprozessor entfernt wird. Die Löschschlange 310 trägt diese Information herüber zu dem Coprozessor; sie hat eine Länge von drei Slots.
  • 2.3.3 Abschlußschlange
  • Die Abschlußschlange 320, die eine Länge von drei Slots hat, hält die Synchronisierung am Ende der Pipeline aufrecht, indem sie für jeden Befehl in der Coprozessorpipeline die Erlaubnis bereitstellt, in den Ruhezustand zu treten. Die Länge der Coprozessorpipeline wird durch das Erfordernis bestimmt, den Ruhezustand eines Coprozessorbefehls lange genug zu verzögern, um Token, die am Ende der Abschlußschlange 320 erscheinen, aufzunehmen bzw. zu erfüllen. Lade- und Speicherbefehle benutzen die Abschlußschlangen nicht, so daß nur CDP-Befehle diese Schlange benötigen. Wie Lade- und Speicherbefehle in den Ruhezustand treten, wird in einem späteren Abschnitt erläutert.
  • 2.3.4 Längenschlange
  • Wenn ein Coprozessor einen Befehl decodiert hat, so weiß er, wie lang ein vektorisierter Lade- oder Speichervorgang sein wird. Diese Information wird mit dem Synchronisierungstoken über die Längenschlange 330 übermittelt. Im allgemeinen dauert es länger, einen Befehl zu empfangen, ihn zu decodieren und die Länge zu liefern, als den Befehl außen durch die Kernpipeline aus der Heranholstufe 190 in die EX1-Stufe 260 (die hier auch als die Verschiebestufe bezeichnet wird) weiterzuleiten, wo die Information benötigt wird. Die Verzögerung in der Ankunft des Token an der EX1-Stufe des Kernes bewirkt, daß diese Stufe für einen Zyklus anhält. Dies fügt einen zusätzlichen Zyklus zu der Ausführung eines Coprozessorbefehls hinzu. Glücklicherweise tritt dieser Nachteil nicht für jeden Coprozessorbefehl auf und die Gründe hierfür werden in einem späteren Abschnitt erläutert. Die Längenschlange hat eine Länge von drei Slots.
  • 2.3.5 Annahmeschlange
  • Der Coprozessor kann in der Ausgabestufe entscheiden, daß er einen Befehl nicht annehmen kann und leitet diese Information mit dem Synchronisierungstoken die Annahmeschlange 340 entlang. Wenn die EX2-Stufe 270 des Kernes (die hier auch als die ALU-Stufe bezeichnet wird) ein Token empfängt, welches ihm mitteilt, den entsprechenden Befehl zurückzuweisen, so entfernt er den Befehl aus der Pipeline durch Löschen der EX2-Stufe. Die Annahmeschlange hat eine Länge von drei Slots.
  • 2.3.6 Rundsenden des Spülens
  • Wenn eine Verzweigung falsch vorhergesagt wurde, so kann es nötig sein, daß der Kern beide Pipelines spülen muß. Da diese Aktion potentiell die gesamte Pipeline beeinflußt, wird sie nicht in einer Schlange weitergeleitet, sondern wird von dem Kern an den Coprozessor rundgesendet, wobei sie denselben Zeitablaufbeschränkungen wie die Schlangen ausgesetzt ist. Wenn das Spülsignal von dem Coprozessor empfangen wurde, so bewirkt es, daß die Pipeline und die Befehlsschlange 300 bis hin zu dem Befehl, welcher das Spülen ausgelöst hat, gelöscht wird.
  • 4 zeigt eine detailliertere Ansicht des Kernes und der Pipelinestufen und der Schlangen, welche die beiden miteinander verbinden. Die Lade-/Speichereinheit (LSU) 222 ist ebenfalls dargestellt. Die LSU nimmt Datenspeicherungen aus dem Coprozessor über eine Speicherschlange 400 an und erzeugt Ladedaten, die über eine Ladeschlange 410 an den Coprozessor zu senden sind.
  • Die Befehlsschlange 300 und die Coprozessordecodierstufe 205 sind getrennt dargestellt, tatsächlich bilden sie jedoch in bevorzugten Ausführungsformen einen einzigen Block. Der Grund hierfür wird in Abschnitt 2.5.4 erläutert.
  • 2.4 Datenübertragung
  • Die meisten Coprozessorbefehle führen zu einer Übertragung von Daten über die Schnittstelle, entweder in Form von Einzelwerten oder als Vektoren. Pfade sind daher für die Datenweiterleitung erforderlich. Diese Pfade ermöglichen es, daß die Kern-LSU 222 mit der Coprozessorpipeline kommuniziert. Der Coprozessor hat im allgemeinen keine getrennte LSU und dementsprechend wird die Erzeugung von Daten für Speichervorgänge und der Empfang von Ladedaten direkt durch die Pipeline ausgeführt.
  • 5 zeigt eine Skizzierung der Kommunikation zwischen der Kern-LSU 222 und der Coprozessorpipeline.
  • Lade- und Speichervorgänge werden in den folgenden Abschnitten getrennt beschrieben.
  • 2.4.1 Ladevorgänge
  • Zu ladende Daten werden über die Schnittstelle durch die WB-Stufe 250 der Kern-LSU 222 gesendet und von der EX6-Stufe 275 (d. h. der WB-Stufe) der Coprozessorpipeline empfangen, wie es in 5 dargestellt ist. Da die Coprozessorpipeline über die Ausgabestufe hinaus nicht anhalten kann, mit Ausnahme des Wartens auf ein Abschlußtoken, welches es dem Befehl in EX6 ermöglicht, in den Ruhezustand zu treten, erreicht der Ladebefehl EX6 immer synchron mit dem Eintreffen der Daten den Coprozessor. Die Ladeschlange kann demnach durch einen Doppelpuffer 410 implementiert werden, der dazu dient, die Daten mit der Ankunft des Ladebefehls im EX6 neu auszurichten. Dieser Doppelpuffer 410 ist in 4 dargestellt.
  • 2.4.2 Speichervorgänge
  • Da die Kern-LSU möglicherweise nicht in der Lage ist, eine Annahme von Daten, so wie sie eintreffen, zu garantieren, ist eine Speicherschlange 400 erforderlich. Diese Schlange verbindet die DC1-Stufe 230 (die hier auch als die Speicher 1-Stufe bezeichnet wird) der LSU 222 mit der Ausgabestufe 215 des Coprozessors. Da unterschiedliche Datenmengen übertragen werden können, ist eine Stromsteuerung auf der Speicherschlange 400 erforderlich, um der LSU 222 zu ermöglichen, zeitweise die Übertragung von Daten zu stoppen. Dies wird später noch genauer erläutert.
  • 2.5 VERWALTUNG DER TOKENSCHLANGE
  • Die Tokenschlangen (d. h. alle Schlangen außer der Ladeschlange 410), die allesamt eine Länge von drei Slots haben und in identischer Weise funktionieren, sind als kurze FIFOs implementiert. Die meisten Schlangen erfordern keine Stromsteuerung aufgrund der selbstbeschränkenden Art der synchronisierten Pipelines, jedoch muß die Speicherdatenschlange 400 in der Lage sein, den Strom von Information von dem Coprozessor in diese Schlange zu steuern. Die Form der Schlangen und die Hinzufügung einer Stromsteuerung werden in den folgenden Abschnitten erläutert.
  • 2.5.1 Implementierung der Schlangen
  • Die Schlangen-FIFOs können in Form von drei Registern 600, 610, 620 implementiert sein, wobei der aktuelle Ausgang durch Verwenden von Multiplexern 660, 670 ausgewählt wird. 6 veranschaulicht diese Anordnung. Die Schlange besteht aus drei Registern 600, 610, 620, welchen jeweils ein Flag 630, 640 bzw. 650 zugeordnet ist, das anzeigt, ob das Register gültige Daten enthält. Neue Daten werden in die Schlange verschoben, indem sie in den Puffer A geschrieben werden, d. h. in das Register 600, und sie bewegen sich weiter entlang der Schlange, solange das nächste Register leer ist oder gerade leer wird. Wenn die Schlange voll ist, besetzen die ältesten Daten, die damit die ersten sind, die aus der Schlange gelesen werden, den Puffer C und die neuesten besetzen den Puffer A.
  • Die Multiplexer 660, 670 wählen auch das aktuelle Flag aus, welches dann anzeigt, ob der ausgewählte Ausgang gültig ist.
  • 2.5.2 Modifizierung der Schlangen
  • Mit jedem Zyklus wird in die Schlange geschrieben, wobei der Puffer A 600 die Daten annimmt, welche über die Schnittstelle ankommen und das Flag 630 des Puffers A das Gültigkeitsbit annimmt, welches zu den Daten gehört. Solange die Schlange noch nicht voll ist, führt dieses zu keinerlei Verlust an Daten, da der Inhalt des Puffers A während desselben Zyklus in den Puffer B 610 verschoben wird. Wenn die Schlange voll ist, so wird ein Laden des Puffers A 600 verhindert, um einen Verlust von Daten zu vermeiden. Auf jeden Fall erfordert, wie bereits erwähnt, die Geometrie der in den 3 und 4 dargestellten Pipelines, daß nicht mehr als drei Slots in jeder Schlange verfügbar sind und auf diese Weise sollten durch die Schnittstelle keine gültigen Daten geliefert werden, wenn die Schlange voll ist, damit kein Datenverlust auftreten kann. Der Zustand der drei Pufferflags 630, 640, 650 wird verwendet, um zu entscheiden, welcher Puffer während jedes Zyklus den Ausgangswert der Schlange bereitstellt. Der Ausgangswert wird immer durch den Puffer bereit gestellt, welcher die ältesten Daten enthält. Dies ist der Puffer C, wenn er gefüllt ist, oder Puffer B, oder, wenn dieser leer ist, Puffer A. Ein einfacher Prioritätsencoder, welcher die drei Flags betrachtet, kann die korrekten Auswahlsignale für die Multiplexer zuführen. Der Zustand der drei Flags kann außerdem festlegen, wie Daten von einem Puffer in einen anderen in der Schlange verschoben werden. Tabelle 2 zeigt, wie die drei Flags decodiert werden können ("X" zeigt einen Zustand, der irrelevant ist).
    Flag C Flag B Flag A S1 S0 Bemerkungen
    0 0 0 x x Schlange ist leer
    0 0 1 0 0 B ← A
    0 1 0 0 1 C ← B
    0 1 1 0 1 C ← B, B ← A
    1 0 0 1 x
    1 0 1 1 x B ← A
    1 1 0 1 x
    1 1 1 1 x Schlange ist voll – Eingabe verhindert
    Tabelle 2 – Adressierung der Schlangenpuffer
  • Es versteht sich, daß neue Daten in den Puffer A verschoben werden können, vorausgesetzt, die Schlange ist nicht voll, selbst wenn sein Flag gesetzt ist, da der aktuelle Inhalt des Puffers A in den Puffer B verschoben wird.
  • Wenn die Schlange gelesen wird, muß das Flag, welches zu dem Puffer gehört, der die Information bereitstellt, gelöscht werden. Dieser Vorgang kann mit einer Eingangsoperation kombiniert werden, so daß der Puffer am Ende des Zyklus überschrieben wird, während dessen er den Ausgangswert der Schlange bereitstellt. Dies kann implementiert werden durch Verwenden eines Lesefreischaltsignals, um das Flag der ausgewählten Stufe zu maskieren, was sie für den Eingangswert verfügbar macht. 7 liefert eine Veranschaulichung des Lesens und Schreibens einer Schlange.
  • Vier gültige Eingangsgrößen ("Eins", "Zwei", "Drei" und "Vier") werden in die Schlange geschrieben und in den Puffer A 600 getaktet, wenn sie ankommen. Die 4 zeigt, wie diese Eingangswerte von Puffer zu Puffer weitergetaktet werden, bis der erste Eingangswert den Puffer C 620 erreicht hat. An diesem Punkt ist ein Lesen aus der Schlange erforderlich. Da der Puffer C voll ist, wird er ausgewählt, um die Daten zuzuführen. Während er gelesen wird, ist er frei, einen weiteren Eingangswert aufzunehmen und empfängt auf diese Weise den Wert "Zwei" von dem Puffer B, welcher den Wert "Drei" von dem Puffer A empfängt. Da der Puffer A durch Schreiben in dem Puffer B freigemacht wird, kann er den Wert "Vier" von dem Eingang annehmen.
  • 2.5.3 Stromsteuerung
  • Wie zuvor bereits angezeigt, erfordert das Speichern von Daten eine Stromsteuerung, um zu ermöglichen, daß der Kern-LSU 222 den Strom von Daten aus dem Coprozessor anhält. Dies geschieht durch Senden eines Stopsignals an den Coprozessor. Da dieses Signal zwei Taktzyklen benötigt, um den Coprozessor zu erreichen, muß es erzeugt werden, sobald ein Risiko besteht, daß die Speicherschlange 400 voll wird. Mit einer Schlangenlänge von drei wird dieses Risiko real, sobald die Kern-LSU ein Datenobjekt nicht annehmen kann. Das Stopsignal wird demnach immer dann an den Coprozessor gesendet, wenn die LSU Daten nicht annehmen kann. Wegen der Verzögerung sendet der Coprozessor weiterhin Daten für zwei weitere Zyklen, nachdem das Stopsignal erzeugt wurde. Wenn außerdem ein Objekt "in Bewegung" ist, wenn das Stopsignal gesendet wird, muß die Schlange drei Objekte annehmen, nachdem dieses gesendet wurde. 8 veranschaulicht diese Situation.
  • Die LSU nimmt die ersten beiden Übertragungen A und B an. Sie ist jedoch nicht in der Lage, das dritte Objekt C anzunehmen und erzeugt bei Punkt 800 das Stop-Signal. Zu dem Zeitpunkt, zu welchem dieses Signal den Coprozessor am Punkt 810 erreicht, hat er drei weitere Objekte C, D und E gesendet und hat bereits ein sechstes Objekt, F, auf der Schnittstelle plaziert. Nachdem der Coprozessor nunmehr das Stop-Signal empfangen hat, läßt er das Objekt F auf der Schnittstelle. Da die LSU 222 dieses neue Objekt sieht und nicht in der Lage ist, es anzunehmen, setzt sie an Punkt 820 ein Flag "anhängig", um seine Gegenwart aufzuzeigen. Wenn die LSU in der Lage ist, weitere Daten anzunehmen, so beginnt sie damit, die Schlange zu entleeren und hebt das Stop-Signal an Punkt 830 wieder auf. Zu dem Zeitpunkt, zu welchem die Aufhebung an Punkt 840 den Coprozessor erreicht, entleert sich die Schlange und der normale Dienst kann wieder aufgenommen werden.
  • 2.5.4 Befehlsdecodierung
  • Der Kern leitet jeden aus dem Speicher herangeholten Befehl über die GCP-Schnittstelle weiter, wo er in die Befehlsschlange 300 eintritt. Im Idealfall sollte er nur die Coprozessorbefehle weiterleiten, hat jedoch in dieser Stufe noch keine Zeit gehabt, den Befehl zu decodieren. Es bleibt dem GCP überlassen, den Befehl nach Ankunft in seiner eigenen Decodierstufe 205 zu decodieren und die Befehle zurückzuweisen, die keine Coprozessorbefehle sind. Er kann dies still (ohne Meldung) tun, da der Kern keine Bestätigung für das Entfernen dieser Befehle benötigt, weil er bis dahin in seiner eigenen Decodierstufe 200 den Typ jedes Befehls bereits festgestellt hat. Dies bedeutet, daß der von dem Kern empfangene Befehl decodiert werden muß, sobald er in die Befehlsschlange eingetreten ist. Die Befehlsschlange 300 ist demnach eine modifizierte Version der Standardschlange, welche einen Befehlsdecoder 205 beinhaltet. 9 zeigt, wie die Befehlsschlange implementiert sein kann.
  • Der Decoder 205 decodiert den in den Puffer A 900 geschriebenen Befehl, sobald er eingetroffen ist, und die nachfolgenden Puffer B 910 und C 920 empfangen eine decodierte Version des Befehls in dem Puffer A. Das A-Flag 930 zeigt nunmehr an, daß die Daten in A gültig sind und auch einen Coprozessorbefehl repräsentieren. Demnach werden Befehle, die keine Coprozessorbefehle sind oder die nicht erkannt werden, sofort aus der Befehlsschlange entfernt und niemals weitergeleitet. Der Coprozessor vergleicht auch das Coprozessornummernfeld in einem Coprozessorbefehl und vergleicht das Feld bzw. diese Nummer mit seiner eigenen. Wenn die Nummern nicht zusammenpassen, ist der Befehl ungültig.
  • 2.6 Markierung von Befehlen
  • Manchmal ist es notwendig, daß der Kern in der Lage ist, Befehle in der Coprozessorpipeline zu identifizieren. Dies ist erforderlich für das Spülen (welches im Einzelnen später noch beschrieben wird), so daß der Kern dem Coprozessor anzeigen kann, welche Befehle gespült werden müssen. Der Kern gibt daher jedem Befehl, der an den Coprozessor gesendet wird, ein Tag (einen Anhänger), welches aus einem Vorrat von Werten entnommen wird, der groß genug ist, so daß zu irgendeinem Zeitpunkt alle Tags in der Pipeline eindeutig sind. Sechzehn Tags sind ausreichend viel, um dies in bevorzugten Ausführungsformen zu erreichen, was ein Tagfeld von vier Bits erfordert. Jedesmal, wenn einem Befehl ein Tag zugewiesen wird, wird die Tagnummer Modulo 16 erhöht, um das nächste Tag zu erzeugen.
  • Der Spülmechanismus wird vereinfacht, wenn aufeinanderfolgende Coprozessorbefehle unmittelbar aufeinanderfolgende Tags haben. Dies wird erreicht, indem die Tagnummer nur dann heraufgesetzt wird, wenn der Befehl, der an den Coprozessor weitergeleitet wird, ein Coprozessorbefehl ist. Dies geschieht nach dem Senden des Befehls, so daß das Tag sich verändert, nachdem ein Coprozessorbefehl gesendet worden ist, und nicht vorher. Es ist nicht möglich, das Tag um einen Schritt heraufzusetzen, bevor der Befehl gesendet wird, da der Kern noch nicht die Zeit gehabt hat, den Befehl zu decodieren, um festzustellen, um welche Art von Befehl es sich handelt. Wenn die Coprozessordecodierstufe 205 die Befehle, die keine Coprozessorbefehle sind, entfernt hat, so verbleibt in ihr ein Befehlsstrom, der aufeinanderfolgende Tags trägt. Die Tags können auch verwendet werden, um zu verifizieren, daß die Folge von Token, die sich entlang der Schlangen bewegen, mit der Folge von Befehlen zusammenpaßt, die sich entlang der Kern- und Coprozessorpipelines bewegen.
  • 3 BETRIEBSWEISE
  • Die Art und Weise, in welcher die GCP-Schnittstelle funktioniert, wird nun durch Veranschaulichung der verschiedenen Operationen erläutert, die ausgeführt werden können, sowie der Ereignisse, die stattfinden können. Die Figuren, die zu den Erläuterungen gehören, zeigen das Weiterleiten von Token entlang der verschiedenen Schlangen über die Schnittstelle zwischen den beiden Pipelines. Die Identität jeder Schlange kann abgeleitet werden durch Beobachten des Start- und Endpunkts und gemäß 3.
  • 3.1 Normalbetrieb
  • 10 zeigt den Normalbetrieb der Kern- und Coprozessorpipelines.
  • Im Normalbetrieb leitet der Kern sämtliche Befehle herüber zu dem Coprozessor über die Befehlsschlange 300 und setzt dann das Tag um einen Schritt herauf, wenn der Befehl ein Coprozessorbefehl war. Der Coprozessor decodiert den Befehl, verwirft ihn, wenn es sich nicht um einen Coprozessorbefehl handelt oder wenn er die falsche Coprozessornummer enthält. Jeder Coprozessorbefehl durchläuft dann die Pipeline und sendet ein Token über die Längenschlange 330, während er sich in die Ausgabestufe bewegt. Der Befehl bleibt dann in der Ausgabestufe, bis er ein Token von der Löschschlange 310 empfangen hat. Wenn das Löschtoken nicht anfordert, daß der Befehl gelöscht wird, so bewegt er sich weiter zu der EX1-Stufe und ordnet ein Token auf der Annahmeschlange 340 an. Der Befehl bewegt sich dann entlang der Pipeline, bis er die EX6-Stufe erreicht hat. An diesem Punkt wartet er darauf, ein Token von der Abschlußschlange 320 zu empfangen, was ihm erlaubt, in den Ruhezustand überzutreten.
  • 10 zeigt, wie die Zeit, die erforderlich ist, damit der Coprozessor mit einem Token entlang der Längenschlange 310 reagiert, bewirkt, daß die Kernpipeline in ihrer EX1-Stufe wegen des Befehls A anhält, während sie auf das Token wartet. Diese Verzögerung bewirkt ihrerseits, daß der Befehl B in der Coprozessorpipeline Stufe EX1 auf das durch den Kern gesendete Token wartet, wenn B seine Ausgangsstufe verläßt. Der Befehl B kommt demnach bei EX6 verspätet an und befindet, daß das Token in der Abschlußschlange dort schon während eines Zyklus gewartet hat. Zu dem Zeitpunkt, zu welchem der Befehl C am Grund bzw. Ende der Pipeline ankommt, sind die beiden Pipelines wieder synchronisiert.
  • Es ist klar anhand der 10, daß die Ausführung einer Coprozessorpipeline einen Zeitverlust von einem Zyklus verursacht, während ein Befehl in der Ausgabestufe des Kernes anhält bzw. wartet. Die nächsten zwei Befehle ziehen jedoch aus diesem Warten einen Vorteil, so daß der Nachteil abgemildert wird bzw. sich verteilt. Wenn alle Befehle, welche die Pipeline durchlaufen, Coprozessorbefehle wären, gäbe es ein Anhalten bzw. eine Unterbrechung bei jedem dritten Befehl, so daß im Ergebnis dieser Nachteil ein Drittel eines Zyklus pro Coprozessorbefehl ausmacht. Wenn Coprozessorbefehle in der Pipeline selten sind, tritt andererseits der Nachteil bzw. die Verzögerung bei einem einzelnen Zyklus bei jedem Coprozessorbefehl auf. Die durchschnittliche Zeitverzögerung nimmt daher ab, wenn der Anteil von Coprozessorbefehlen ansteigt.
  • 3.2 Unterbrechungen
  • 11 zeigt, wie die Kern- und Coprozessorpipelines sich verhalten, wenn der Coprozessor in seiner Ausgabestufe anhält bzw. unterbricht.
  • Das Weiterleiten des Coprozessorbefehls A durch die Pipelines beginnt auf normale Weise mit einem Austauschen von Token, während der Befehl aus der Ausgabestufe des Kernes und der Decodierstufe des Coprozessors austritt. Der Befehl hält dann in der Ausgabestufe des Coprozessors an, verzögert das Weiterleiten des Token an die EX2-Stufe des Kernes über die Annahmeschlange 340, welche deshalb anhält bzw. unterbricht, während sie darauf wartet. Wenn der Befehl sich schließlich in die EX1-Stufe des Coprozessors weiter bewegt, nimmt er das Token, welches zuvor über die Löschschlange 310 durch den Befehl plaziert wurde, während er die Ausgabestufe des Kerns verlassen hat, auf.
  • 11 zeigt auch, wie die Pipelines selbst die Anzahl von Objekten beschränken, die zu irgendeinem gegebenen Zeitpunkt in einer Schlange warten können. Während der Befehl A in EX2 angehalten wird und auf ein Token wartet, das auf der Annahmeschlange 340 erscheinen soll, verhindert er, daß sich der Befehl C weiter bewegt und ein Token auf die Löschschlange 310 setzt, obwohl der Befehl B dies bereits getan hat. Die Anzahl von Objekten, die in der Löschschlange wartet, ist demnach auf zwei beschränkt. Ähnliche Mechanismen arbeiten in den anderen Schlangen, welche Token zwischen den Pipelines weiterleiten.
  • 3.3 Löschen
  • 12 zeigt, wie die Kern- und Coprozessorpipelines sich verhalten, wenn ein Coprozessorbefehl durch den Kern in seiner Ausgabestufe gelöscht wird.
  • Der Befehl C durchläuft normalerweise die Kernpipeline und sendet ein Token über die Befehlsschlange 300, bis er die Ausgabestufe erreicht. An diesem Punkt sendet er ein Token über die Löschschlange 310, welches anzeigt, daß der Befehl gelöscht werden sollte. Nachdem dies geschehen ist, wandelt er sich in ein Phantom innerhalb der Kernpipeline um (wie es durch die Schattierung angezeigt wird) und durchläuft die Pipeline wie normal, bis zur EX2-Stufe. Er tut dies derart, daß er die durch sein Gegenstück in der Coprozessorpipeline über die Längenschlange 330 und die Annahmeschlange 340 gesendeten Token aufnehmen kann. Diese sind bereits gesendet worden, bevor der Befehl in der Coprozessorschlange des Token aus der Löschschlange 310 liest. Dies hält die Weiterleitung von Token über die Löschschlange korrekt, indem sicher gestellt wird, daß jeder sendende Befehl einen entsprechenden empfangenden Befehl in der anderen Pipeline hat. Der Befehl C kann schließlich erlöschen, wenn er die EX2-Stufe des Kernes verläßt, da er nicht mehr für die Aufnahme von Token benötigt wird. Der Befehl in der Coprozessorpipeline erlischt unmittelbar nach dem Aufnehmen des Löschtoken aus der Löschschlange 310 in der EX1-Stufe.
  • 3.4 Abprallen (Bounces)
  • 13 zeigt, wie sich die Kern- und Coprozessorpipelines verhalten, wenn der Coprozessor einen Coprozessorbefehl abprallen läßt (nicht annimmt).
  • Der Befehl C durchläuft die Coprozessorpipeline in einer normalen Weise, indem er ein Token an die Längenschlange 330 weiterleitet, bis er die Ausgabestufe erreicht hat. An diesem Punkt sendet er ein Token über die Annahmeschlange 340, welches anzeigt, daß der Befehl durch den Coprozessor nicht angenommen wird. Wenn dies geschehen ist, so wandelt er sich in ein Phantom um und geht weiter die Pipeline entlang wie normal, bis er die Stufe EX1 verläßt, wenn er erlischt. Er tut dies so, daß er das Token, welches durch sein Gegenstück in der Kernpipeline durch die Löschschlange 310 gesendet wurde, aufnehmen kann. Der Befehl in der Kernpipeline erlischt unmittelbar nach dem Aufnehmen des Annahmetoken aus der Annahmeschlange 340 in der EX2-Stufe.
  • Das Verhalten von Befehlen, die in der Coprozessorpipeline abprallen, ist nahezu dasselbe wie bei denjenigen, die in der Kernpipeline gelöscht werden und eine gute Veranschaulichung dieses Mechanismus wird durch die Art und Weise geliefert, in welcher die Pipelines mit einem Befehl umgehen, der durch den Kern gelöscht wird und den der Coprozessor abprallen läßt. 14 zeigt diese Situation.
  • In dieser Situation haben beide Pipelines ein Phantom erzeugt, dessen einziger Zweck darin besteht, Token von der anderen Pipeline aufzunehmen oder, im Fall des Coprozessors, ein Tag für eine Übereinstimmung während eines Spülens bereitzustellen. Jeder empfängt ein Token, das ihm mitteilt, daß er erlöschen soll, jedoch ist diese Information redundant, weil er als Phantom bereits verfallen ist.
  • 3.5 Spülen
  • 15 zeigt, wie die Kern- und Coprozessorpipelines sich verhalten, wenn der Kern ein Spülsignal an den Coprozessor sendet.
  • Ein Spülen kann ausgelöst werden durch den Kern in jeder Stufe von der Ausgabe bis einschließlich EX4. Diese Information könnte durch eine Serie von Schlangen an die Coprozessorpipeline weitergeleitet werden, jedoch würde dieses Schema zu einer unnötigen Vermehrung bzw. Aufweitung von Schlangen führen. Statt dessen wird ein Markieren (mit Tag versehen) verwendet, so daß ein einzelnes Rundsendesignal an den Coprozessor gesendet werden kann, welches den zu spülenden Befehl kennzeichnet, indem das entsprechende Tag gesendet wird. Der Coprozessor muß dann alle Befehle finden, die dasselbe Tag haben oder später liegen als das zu spülende Tag und sie entfernen. Im Gegensatz zu Token, die eine Schlange durchlaufen, hat ein Spülsignal eine feste Verzögerung, so daß die Zeitablaufbeziehung zwischen einem Spülen in dem Kern und einem Spülen in dem Coprozessor exakt bekannt ist.
  • In 15 löst der Befehl C ein Spülen aus, wenn er die EX1-Stufe in dem Kern erreicht hat. Er erlischt daher bei dem nächsten Zyklus und nimmt alle Befehle mit sich, die in der Pipeline auf ihn folgen. Während er erlischt, sendet er ein Rundesendesignal 450 (welches durch den gestrichelten Pfeil in der Figur angedeutet wird) an die Coprozessorpipeline. Wenn der Coprozessor dieses Signal empfängt, so durchsucht er die Pipeline nach passenden Tags und entfernt alle Befehle von diesem Punkt an aufwärts, welche im Falle der 15 die Befehle C, D und F sind (ein Kernbefehl in der Decodierstufe, der in diesem Fall schon dabei war zu erlöschen). Die Befehle A und B durchlaufen die Pipeline weiter, da sie vor dem Spülpunkt liegen.
  • Die meisten der Tokenschlangen müssen ebenfalls gespült werden und dies kann ebenfalls unter Verwendung der an jedem Befehl angehängten Tags geschehen. Wenn eine Übereinstimmung festgestellt wurde, bevor die Stufe am Empfangsende einer Tokenschlange durchlaufen wurde, so wird die Tokenschlange einfach gelöscht. Ansonsten muß sie ordnungsgemäß gespült werden, indem die Tags in der Schlange zur Übereinstimmung gebracht werden. Dieser Vorgang muß mit allen Schlangen mit Ausnahme der Abschlußschlange 320 durchgeführt werden, einschließlich der Speicherschlange 400. Der Coprozessor muß deshalb die Befehlsschlange 300 und die Löschschlange 310 spülen und der Kern muß die Längenschlange 330, die Annahmeschlange 340 und die Speicherschlange 400 spülen.
  • Der Spülvorgang kann durch den Coprozessor ausgeführt werden, sobald das Spülsignal empfangen wurde und er wird vereinfacht, da die Schlangen keine andere Operation ausführen. Dies bedeutet, daß das Spülen nicht mit Aktualisierungen von Schlangen kombi niert werden muß. Eine Betrachtung der 15 zeigt, daß es einen einzigen Zyklus im Anschluß an ein Spülen gibt, in welchem nichts geschieht, was die gelöschten Schlangen beeinflußt, was eine gute Gelegenheit ist, den Vorgang des Schlangenspulens auszuführen. Dies gilt jedoch nicht für die Lade- oder Speicherschlangen, was später noch diskutiert wird.
  • Zu einem Spülbefehl gehört ein Tagwert, welcher anzeigt, wo das Spülen beginnen sollte. Dieser paßt zu einem Tag, das durch jeden Befehl getragen wird. Wenn die Schlange gespült werden soll, wird jeder Puffer mit demselben oder einem neueren Tag gelöscht. 16 bietet eine Darstellung des Schlangespülens.
  • Jeder Puffer 600, 610, 620 in der Schlange hat einen Tagvergleicher 604, 614, 624, der zu ihm gehört. Das Spültag 632 wird zu (von) jedem Vergleicher geliefert, damit es mit dem Tag 602, 612, 622 verglichen wird, das zu jedem gültigen Befehl gehört, der in der Schlange gehalten wird. Wenn das Tag eines Puffers größer ist als oder gleich ist wie das Spültag, so muß das gesamte Flag des Puffers in der Schlange gelöscht werden, um anzuzeigen, daß er nunmehr leer ist.
  • 3.6 Ruhezustand
  • Wenn ein Befehl den Grund bzw. das Ende der Coprozessorpipeline erreicht hat, so möchte er in den Ruhezustand eintreten. Wie er in den Ruhrzustand eintritt, hängt von der Art des Befehles ab und davon, ob er wiederholt wird oder nicht. Ein CDP-Befehl kehrt in den Ruhezustand, wenn er ein Token in der Abschlußschlange 320 findet, das zu ihm paßt.
  • Die Bedingungen, unter welchen Lade- und Speicherbefehle in den Ruhezustand eintreten, werden in späteren Abschnitten diskutiert.
  • 4 DATENÜBERTRAGUNGEN
  • 4.1 Allgemeines
  • Datenübertragungen bzw. Datentransfers werden durch die LSU 222 auf der Kernseite und durch die Pipeline selbst auf der Coprozessorseite verwaltet. Übertragungen können für einen einzelnen Wert oder einen Vektor erfolgen. In letzterem Fall wandelt der Coprozessor einen Mehrfachtransfer effektiv in eine Serie einzelner Transfers um, indem der Befehl in der Ausgabestufe wiederholt wird. Dies erzeugt eine Instanz des Lade- oder Speicherbefehls für jedes zu übertragende Objekt. Der Befehl bleibt in der Ausgabestufe des Coprozessors, während er wiederholt wird und erzeugt Kopien von sich selbst. Für Ladevorgänge durchlaufen diese die Pipeline, so daß sie jedes Datenobjekt aus der Ladeschlange 410 aufnehmen können, wenn es in der EX6-Stufe ankommt. Für Speichervorgänge laufen die wiederholten Befehle nicht aus der Ausgabestufe heraus, sondern verschwinden ebenso wie sie erzeugt werden, wodurch sie Speicherdaten bei jeder Wiederholung für die Anordnung in der Speicherschlange 400 erzeugen. 17 zeigt ein Beispiel eines Ladebefehls C. Der erste der wiederholten Befehle (in dem oberen Feld dargestellt) ist der Kopf und die anderen (in dem unteren Feld dargestellt) bilden den Schwanz. In dem dargestellten Beispiel beträgt die Vektorlänge 4, so daß es einen Kopf und drei Schwänze gibt.
  • Nur der Kopfbefehl ist in den Tokenaustausch mit der Kernpipeline involviert, welcher Befehle nicht auf diese Weise wiederholt, wobei die Schwanzbefehle die Coprozessorpipeline still durchlaufen. Wenn ein wiederholter Ladebefehl gelöscht wird oder gespült wird, müssen alle Schwanzbefehle (welche dasselbe Tag tragen) aus der Pipeline entfernt werden. Nur der Kopfbefehl wird zu einem Phantom, wenn er gelöscht wird, die Schwänze werden vollständig entfernt.
  • 4.2 Ladevorgänge
  • Ladedaten kommen aus der WB-Stufe 250 der Kern-LSU 222 und werden von der EX6-Stufe 275 des Coprozessors aus der Ladeschlange 410 empfangen bzw. aufgenommen. Jedes Objekt in einem vektorisierten Ladevorgang wird durch eine Instanz des wiederholten Ladebefehls aufgenommen. Der Zeitablauf in der Pipeline ist derart, daß ein Ladebefehl immer bereit ist oder in EX6 soeben angekommen ist, um jedes Datenobjekt aufzunehmen. Wenn ein Ladebefehl in EX6 angekommen ist, jedoch die Ladeinformation noch nicht erschienen ist, muß der Ladebefehl in EX6 anhalten und auch den Rest der Coprozessorpipeline anhalten bzw. unterbrechen. Ein Ladebefehl kehrt demnach in den Ruhezustand ein, wenn er auf Ladedaten trifft.
  • 4.2.1 Laden von Puffern
  • Um eine korrekte Ausrichtung der Ladedaten mit dem Ladebefehl in der EX6-Stufe des Coprozessors zu erreichen, müssen die Daten doppelt gepuffert werden, wenn sie bei dem Coprozessor ankommen. 18 bietet eine entsprechende Darstellung.
  • Die Puffer der Ladedaten funktionieren als Pipelineregister und erfordern demnach keine Stromsteuerung und müssen auch keinerlei Tags tragen. Das einzige Erfordernis sind die Daten und ein gültiges Bit. Jedes Objekt an Ladedaten, welches aus der WB-Stufe 250 der Kern-LSU 222 herauskommt, wird in einem Kernpuffer 1000 angeordnet, wobei sein entsprechendes Gültigkeitsbit in dem Puffer 1030 gespeichert wird. Das Datenobjekt und das zugehörige Gültigkeitsbit werden dann über die Schnittstelle an den GCP weitergeleitet, wo sie ihrerseits die Puffer 1010, 1040 und 1020, 1050 durchlaufen. 19 zeigt, wie ein Ladebefehl in dem Kern in die Kern-LSU eintritt und die Erzeugung eines Objektes von Ladedaten auslöst, welches dann über den Kernschnittstellenpuffer 1010 und die Doppelpuffer 1020, 1030 des GCP an den Coprozessor weiterläuft und den Coprozessorladebefehl bei EX6 trifft.
  • Damit diese Form des Datenpuffers für Ladetransfers arbeitet, ist es erforderlich, daß die beiden Pipelines in der Weise synchronisiert werden, daß Befehle in dem Coprozessor EX6 immer gemeinsam mit oder vor der Ankunft des entsprechenden Befehles in der EX4-Stufe des Kerns ankommen. Es ist außerdem erforderlich, daß die Token, die sich durch die Abschlußschlange 320 von dem Kern bewegen, zur gleichen Zeit ankommen, wie die entsprechenden Ladedatenobjekte an dem Ende der Pipelinepuffer der Ladedaten ankommen. Diese Bedingungen sind erfüllt, vorausgesetzt, daß die Coprozessorpipeline nur nach der Ausgabestufe in Reaktion auf das Fehlen eines Token in der Abschlußschlange 320 anhält bzw. unterbricht und vorausgesetzt, daß die LSU 222 das Token aus der Annahmeschlange 340 sieht, bevor sie zuläßt, daß sich ein Ladebefehl von seiner ADD-Stufe 220 aus weiterbewegt. Zusätzlich müssen WB-Unterbrechungen das Senden von Ladedaten von der LSU verzögern.
  • 4.2.2 Spülvorgänge
  • Kein Spülen, welches die EX4-Stufe 290 des Kernes nicht betrifft, kann die Ladedatenpuffer beeinflussen und der Ladetransfer kann normal abgeschlossen werden. Wenn durch einen Befehl in der EX4-Stufe des Kernes ein Löschen ausgelöst wird, so ist dies kein Ladebefehl, da Ladebefehle kein Löschen auslösen können. Irgendwelche Coprozessorladebefehle hinter dem Spülpunkt werden feststellen, daß sie angehalten bzw. unterbrochen sind, wenn sie bis zu der EX6-Stufe 275 der Coprozessorpipeline gelangen, und zwar wegen Fehlens eines Abschlußtoken, so daß keine Datentransfers stattgefunden haben. Irgendwelche Daten in den Ladedatenpuffern 410 löschen natürlicherweise während der Totperiode des Spulens, während die Pipeline erneut geladen wird.
  • 4.2.3 Löschvorgänge
  • Wenn ein Ladebefehl gelöscht wird, müssen sowohl der Kopf als auch jegliche Schwänze entfernt werden, wobei nur der Kopf durch ein Phantom ersetzt wird. Da das Löschen in der EX1-Stufe 225 des Coprozessors geschieht, haben keine Datenübertragungen stattgefunden und müssen keine besonderen Maßnahmen getroffen werden, um mit dem Laden von Daten umzugehen.
  • 4.2.4 Ruhezustand
  • Wenn ein Ladebefehl den Grund bzw. das Ende der Coprozessorpipeline erreicht hat, so muß er am Ende des Ladedatenpuffers 410 ein Datenobjekt finden. Wenn der Befehl ein Kopfbefehl ist, so muß er auch ein Token in der Abschlußschlange 320 finden. Schwanzbefehle erfordern nur, daß Ladedaten vorhanden sind, erfordern jedoch kein Token aus der Abschlußschlange.
  • 4.3 Speichervorgänge
  • Speicherdaten kommen aus der Ausgabestufe 215 des Coprozessors und werden durch die DC1-Stufe 230 der Kern-LSU empfangen. Jedes Objekt eines vektorisierten Speichervorgangs wird erzeugt, während der Speicherbefehl in der Ausgabestufe des Coprozessors wiederholt abläuft. Die wiederholten Speicherbefehle finden keine weitere Verwendung und werden nicht durch die Coprozessorpipeline weitergeleitet. Nur der Kopfbefehl durchläuft die Pipeline. Dies bedeutet, daß eine Speicherwiederholung, wenn sie einmal begonnen wurde, nicht stoppt, bis sie ausdrücklich durch den Kern gestoppt wird. Insbesondere wird, wenn der Speicherkopfbefehl in der EX1-Stufe der Coprozessorpipeline angehalten wird, die Iteration fortgesetzt und bleibt sie durch das Anhalten bzw. durch die Unterbrechung unbeeinflußt.
  • 4.3.1 Speicherdatenschlange
  • Wenn die Speicherdatenübertragung zu jedem beliebigen Zeitpunkt durch die LSU 222 gestoppt werden kann, so ist eine Speicherdatenschlange 400 erforderlich. Weiterhin ist, da Speicherdatenvektoren eine beliebige Länge haben können, eine Stromsteuerung erforderlich und dies ist bereits in Abschnitt 2.5.3 erläutert worden. Eine Schlangenlänge von drei Slots ist soeben ausreichend, um die Verwendung einer Stromsteuerung ohne Datenverlust zu ermöglichen.
  • 4.3.2 Spülvorgänge
  • Wenn ein Speicherbefehl in einen Spülvorgang einbezogen ist, muß die Speicherdatenschlange 400 durch den Kern gelöscht werden. Da die Schlange sich weiterhin mit ihren zwei Zyklen füllt, nachdem der Kern dem Coprozessor das Spülen angezeigt hat (wegen der Verzögerung der Signalausbreitung), muß der Kern eine Verzögerung um zwei Zyklen warten, bevor er die Speicherdatenschlange 400 spült. Die Totzeit nach dem Spülen ist bei weitem ausreichend, damit dies geschehen kann.
  • 4.3.3 Löschvorgänge
  • Wenn der Kern einen Speicherbefehl löscht, so weiß er, daß der Befehl gelöscht wird, bevor er damit beginnt, Speicherdaten aufzunehmen. Zu dem Zeitpunkt, zu welchem der Coprozessor das Löschsignal empfängt und darauf reagiert, hat er bereits ein Datenobjekt in die Speicherdatenschlange 400 gesendet. Der Kern muß deshalb dieses einzelne Objekt nach dem Löschen entfernen und abfertigen. Dies kann geschehen durch Senden eines einzelnen Speicherbefehlphantoms durch die LSU 222, um die toten Daten aufzunehmen. Al ternativ kann die Ausgabestufe in der Löschschlange vorausschauen, um festzulegen, daß der Speicherbefehl nicht gelöscht wird, bevor er begonnen hat, Daten zu senden.
  • 4.3.4 Ruhezustand
  • Speicherbefehle verwenden nicht die Abschlußtokenschlange 320 und gehen daher in den Ruhezustand, sobald sie den Grund bzw. das Ende der Coprozessorpipeline erreicht haben.
  • 5 MEHRERE COPROZESSOREN
  • Es können mehr als ein Coprozessor an dem Kern angeordnet sein und deshalb sind möglicherweise einige Einrichtungen erforderlich, um mit mehreren Prozessoren umzugehen. Aus ökonomischen Gründen ist es wichtig sicherzustellen, daß so wenig wie möglich von der Coprozessorschnittstelle dupliziert wird. Insbesondere sollten die Coprozessoren die Längenschlange 330, die Annahmeschlange 340 und die Speicherdatenschlange 400 gemeinsam verwenden, welche durch den Kern verwaltet werden. Wenn diese Schlangen gemeinsam verwendet werden, kann zu einem gegebenen Zeitpunkt jeweils nur ein Coprozessor die Schlangen verwenden. Dies wird am einfachsten dadurch sichergestellt, daß man zu jedem Zeitpunkt jeweils nur einen Coprozessor aktiv sein läßt. Dies ist keine ernsthafte Einschränkung, da, allgemein gesprochen, zu irgend einem gegebenen Zeitpunkt jeweils nur ein Coprozessor in Gebrauch sein sollte. Typischerweise wird ein Prozessor durch eine Treibersoftware angesteuert, die nur einen Coprozessor treibt bzw. ansteuert. Aufrufe an die Treibersoftware und Antworten von derselben stellen sicher, daß es mehrere Kernbefehle zwischen der Verwendung eines Coprozessors und der Verwendung eines anderen Coprozessors gibt.
  • 5.1 Gesichtspunkte der wechselseitigen Verbindung
  • Wenn zu einem gegebenen Zeitpunkt jeweils nur ein Coprozessor mit dem Kern kommunizieren darf, können alle Coprozessoren die GCP-Schnittstellensignale von dem Kern gemeinsam verwenden. Signale von den Coprozessoren an den Kern können einfach über eine ODER-Schaltung verbunden sein, vorausgesetzt, daß jeder Coprozessor seine Ausgänge auf Null hält, wenn er nicht aktiv ist.
  • 5.2 Coprozessorauswahl
  • Coprozessoren werden durch ein Signal von dem Kern freigeschaltet. In bevorzugten Ausführungsformen gibt es sechzehn dieser Signale, eines für jeden Coprozessor, und nur eines kann zu irgendeinem gegebenen Zeitpunkt aktiv sein. Zusätzlich umfassen Befehle an die Coprozessoren die Coprozessornummer, was es dem Coprozessor ermöglicht, Befehle zurückzuweisen, die nicht mit seiner eigenen Nummer zusammenpassen, ebenso wie Kernbefehle zurückzuweisen.
  • 5.3 Umschalten zwischen Coprozessoren
  • Wenn der Kern einen Coprozessorbefehl decodiert, der gegenüber dem zuletzt angesprochenen für einen anderen Coprozessor bestimmt ist, so hält er diesen Befehl an, bis der vorhergehende Coprozessorbefehl in den Ruhezustand getreten ist. Dies stellt sicher, daß sämtliche Aktivität in dem aktuell ausgewählten Coprozessor beendet ist. Die Coprozessorauswahl wird dann umgeschaltet, wodurch der letzte aktive Coprozessor abgeschaltet und der neue Coprozessor aktiviert wird. Der Coprozessor, der möglicherweise den neuen Coprozessorbefehl empfangen hat, hat ihn ignoriert und ist abgeschaltet. Der Befehl muß deshalb durch den Kern erneut versendet werden und wird nunmehr durch den neu aktivierten Coprozessor angenommen.
  • Auch wenn eine besondere Ausführungsform der Erfindung hier beschrieben wurde, so ist es offensichtlich, daß die Erfindung nicht darauf beschränkt ist und daß viele Modifikationen und Ergänzungen innerhalb des Schutzumfanges der Erfindung vorgenommen werden können. Beispielsweise könnten verschiedene Kombinationen der Merkmale der folgenden abhängigen Ansprüche mit Merkmalen der unabhängigen Ansprüche vorgenommen werden, ohne vom Schutzumfang der vorliegenden Erfindung abzuweichen.

Claims (41)

  1. Datenverarbeitungsvorrichtung, welche aufweist: einen Hauptprozessor (40), der derart betreibbar ist, daß er eine Folge von Befehlen ausführt, wobei der Hauptprozessor eine erste Pipeline (30) aufweist, die eine erste Mehrzahl von Pipelinestufen hat, einen Coprozessor (110), der in der Weise betreibbar ist, daß er Coprozessorbefehle in der Folge von Befehlen ausführt, wobei der Coprozessor eine zweite Pipeline (130) aufweist, die eine zweite Mehrzahl von Pipelinestufen hat, und wobei jeder Coprozessorbefehl in der Weise ausgelegt ist, daß er sowohl durch die erste Pipeline als auch durch die zweite Pipeline geführt wird, und dadurch gekennzeichnet, daß zumindest eine Synchronisierungsschlange (300, 310, 320, 330, 340, 400, 410), welche einen First-In-First-Out-(FIFO-)Puffer aufweist, der eine vorbestimmte Mehrzahl von Einträgen hat und eine vorbestimmte Pipelinestufe in einer der Pipelines mit einer Partnerpipelinestufe in der anderen der Pipelines verbindet, wobei die vorbestimmte Pipelinestufe in der Weise betreibbar ist, daß sie bewirkt, daß ein Token in einem Eintrag der Synchronisierungsschlange angeordnet wird, wenn ein Coprozessorbefehl ausgeführt wird, wobei der Token ein Tag enthält, welches den Coprozessorbefehl eindeutig identifiziert, auf welchen der Token sich bezieht, und die Partnerpipeline in der Weise betreibbar ist, daß sie nach Empfang des Token aus der Synchronisierungsschlange den Coprozessorbefehl verarbeitet, um dadurch die erste und die zweite Pipeline zwischen der vorbestimmten Pipelinestufe und der Partnerpipelinestufe zu synchronisieren, ohne Signale mit fester Zeitgebung zwischen den Pipelines zu übertragen.
  2. Datenverarbeitungsvorrichtung nach Anspruch 1, welche weiterhin eine Mehrzahl der Synchronisierungsschlangen aufweist, wobei jede der Synchronisierungsschlangen eine vorbestimmte Pipelinestufe in einer der Pipelines mit einer Partnerpipelinestufe in der anderen der Pipelines verbindet.
  3. Datenverarbeitungsvorrichtung nach Anspruch 1 oder Anspruch 2, wobei eine der zumindest einen Synchronisierungsschlangen eine Befehlsschlange (300) ist, wobei die vorbestimmte Pipelinestufe (190) sich in der ersten Pipeline befindet und so ausgelegt ist, daß sie veranlaßt, daß ein Token, welcher einen Coprozessorbefehl identifiziert, in der Befehlsschlange angeordnet wird, und wobei die Partnerpipelinestufe (205) sich in der zweiten Pipeline befindet und nach Empfang des Token in der Weise betreibbar ist, daß sie mit dem Verarbeiten des durch den Token identifizieren Coprozessorbefehls beginnt.
  4. Datenverarbeitungsvorrichtung nach Anspruch 3, wobei die vorbestimmte Pipelinestufe eine Heranholstufe (190) in der ersten Pipeline ist, und die Partnerpipelinestufe eine Decodierstufe (205) in der zweiten Pipeline ist, wobei diese Decodierstufe in der Weise betreibbar ist, daß sie nach Empfang des Token den Coprozessorbefehl decodiert.
  5. Datenverarbeitungsvorrichtung nach Anspruch 4, wobei die Heranholstufe der ersten Pipeline in der Weise betreibbar ist, daß sie bewirkt, daß ein Token in der Befehlsschlange für jeden Befehl in der Folge von Befehlen angeordnet wird, und die Decodierstufe in der zweiten Pipeline dafür ausgelegt ist, nach Empfang des zugehörigen Token jeden Befehl zu decodieren, um festzustellen, ob dieser Befehl ein Coprozessorbefehl ist, der eine weitere Verarbeitung durch den Coprozessor erfordert.
  6. Datenverarbeitungsvorrichtung nach einem der vorstehenden Ansprüche, wobei eine der zumindest einen Synchronisierungsschlangen eine Löschschlange (310) ist, wobei die vorbestimmte Pipelinestufe (210) sich in der ersten Pipeline befindet und dafür ausgelegt ist, zu veranlassen, daß ein Token in der Löschschlange angeordnet wird, welcher kennzeichnet, ob ein Coprozessorbefehl an der vorbestimmten Pipelinestufe gelöscht werden soll, und wobei die Partnerpipelinestufe (225) sich in der zweiten Pipeline befindet und in der Weise betreibbar ist, daß sie bei Empfang des Token aus der Löschschlange und für den Fall, daß der Token kennzeichnet, daß der Coprozessorbefehl gelöscht werden soll, bewirkt, daß der Coprozessorbefehl gelöscht wird.
  7. Datenverarbeitungsvorrichtung nach Anspruch 6, wobei die vorbestimmte Pipelinestufe eine Ausgabestufe (210) in der ersten Pipeline ist, und die Partnerpipelinestufe eine Stufe (225) ist, die in der zweiten Pipeline auf eine Ausgabestufe folgt.
  8. Datenverarbeitungsvorrichtung nach Anspruch 6 oder 7, wobei die Partnerpipelinestufe in der Weise betreibbar ist, daß sie nach Empfang eines Token aus der Löschschlange und für den Fall, daß der Token kennzeichnet, daß der Coprozessorbefehl gelöscht werden soll, den Coprozessorbefehl aus der zweiten Pipeline entfernt.
  9. Datenverarbeitungsvorrichtung nach einem der vorstehenden Ansprüche, wobei eine der zumindest einen Synchronisierungsschlangen eine Abschlußschlange (320) ist, wobei die vorbestimmte Pipelinestufe (290) sich in der ersten Pipeline befindet und dafür ausgelegt ist, zu bewirken, daß ein Token in der Abschlußschlange angeordnet wird, welcher die Erlaubnis kennzeichnet, daß ein Coprozessorbefehl an der vorbestimmten Pipelinestufe aus der zweiten Pipeline in einen Ruhezustand versetzt wird, und die Partnerpipelinestufe (275) sich in der zweiten Pipeline befindet und in der Weise betreibbar ist, daß sie nach Empfang des Token von der Abschlußschlange und für den Fall, daß der Token angibt, daß der Coprozessorbefehl in einen Ruhezustand versetzt werden kann, bewirkt, daß der Coprozessorbefehl in einen Ruhezustand versetzt wird.
  10. Datenverarbeitungsvorrichtung nach Anspruch 9, wobei die vorbestimmte Pipelinestufe eine Zurückschreibestufe (290) in der ersten Pipeline ist und die Partnerpipelinestufe eine Zurückschreibestufe (275) in der zweiten Pipeline ist.
  11. Datenverarbeitungsvorrichtung nach einem der vorstehenden Ansprüche, wobei eine der zumindest einen Synchronisierungsschlangen eine Längenschlange (330) ist, die vorbestimmte Pipelinestufe (205) sich in der zweiten Pipeline befindet und dafür ausgelegt ist, daß sie für einen vektorisierten (als Vektor ausgestalteten) Coprozessorbefehl bewirkt, daß ein Token in der Längenschlange angeordnet wird, welcher Längeninformation für den vektorisierten Coprozessorbefehl angibt, und wobei die Partnerpipelinestufe (260) sich in der ersten Pipeline befindet und in der Weise betreibbar ist, daß sie nach Empfang des Token aus der Längenschlange die Längeninformation bei der weiteren Verarbeitung des vektorisierten Coprozessorbefehls der ersten Pipeline berücksichtigt.
  12. Datenverarbeitungsvorrichtung nach Anspruch 11, wobei die vorbestimmte Pipelinestufe eine Decodierstufe (205) in der zweiten Pipeline ist, und die Partnerpipelinestufe eine erste Ausführungsstufe (260) in der ersten Pipeline ist.
  13. Datenverarbeitungsvorrichtung nach einem der vorstehenden Ansprüche, wobei eine der zumindest einen Synchronisierungsschlangen eine Annahmeschlange (340) ist, wobei die vorbestimmte Pipelinestufe (215) sich in der zweiten Pipeline befindet und dafür ausgelegt ist, daß sie bewirkt, daß in der Annahmeschlange ein Token angeordnet wird, welcher kennzeichnet, ob ein Coprozessorbefehl in der vorbestimmten Pipelinestufe für die Ausführung durch den Coprozessor angenommen werden soll, und die Partnerpipelinestufe (270) sich in der ersten Pipeline befindet und in der Weise betreibbar ist, daß sie nach Empfang des Token aus der Annahmeschlange und für den Fall, daß der Token angibt, daß der Coprozessorbefehl nicht angenommen werden soll, bewirkt, daß der Coprozessorbefehl durch den Hauptprozessor zurückgewiesen wird.
  14. Datenverarbeitungsvorrichtung nach Anspruch 13, wobei die vorbestimmte Pipelinestufe eine Ausgabestufe (215) in der zweiten Pipeline ist und die Partnerpipelinestufe eine zweite Ausführungsstufe (270) in der ersten Pipeline ist.
  15. Datenverarbeitungsvorrichtung nach Anspruch 13 oder 14, wobei die Partnerpipelinestufe so betreibbar ist, daß sie bei Empfang des Token aus der Annahmeschlange und für den Fall, daß der Token kennzeichnet, daß der Coprozessorbefehl nicht angenommen werden soll, den Coprozessorbefehl aus der ersten Pipeline entfernt.
  16. Datenverarbeitungsvorrichtung nach einem der vorstehenden Ansprüche, wobei eine der zumindest einen Synchronisierungsschlangen eine Speicherschlange (400) ist, die verwendet wird, wenn der Coprozessorbefehl eine Speicheranweisung ist und in der Weise betreibbar ist, daß sie bewirkt, daß Datenobjekte von dem Coprozessor in einen Speicher übertragen werden, auf den der Hauptprozessor Zugriff hat, wobei die vorbestimmte Pipelinestufe (215) sich in der zweiten Pipeline befindet und dafür ausgelegt ist, zu bewirken, wenn einer der Speicherbefehle verarbeitet wird, daß in der Speicherschlange ein Token angeordnet wird, welcher jedes Datenobjekt, das übertragen werden soll, kennzeichnet, und wobei die Partnerpipelinestufe (230) sich in der ersten Pipeline befindet und in der Weise betreibbar ist, daß sie nach Empfang jedes Token von der Speicherschlange bewirkt, daß das entsprechende Datenobjekt an den Speicher übertragen wird.
  17. Datenverarbeitungsvorrichtung nach Anspruch 16, wobei die vorbestimmte Pipelinestufe eine Ausgabestufe (215) in der zweiten Pipeline ist und die Partnerpipelinestufe eine Adreßerzeugungsstufe (230) in der ersten Pipeline ist.
  18. Datenverarbeitungsvorrichtung nach einem der vorstehenden Ansprüche, wobei eine der zumindest einen Synchronisierungsschlangen eine Ladeschlange (410) ist, die verwendet wird, wenn der Coprozessorbefehl ein Ladebefehl ist, der in der Weise betreibbar ist, daß er bewirkt, daß Datenobjekte von einem Speicher, auf welchen der Hauptprozessor Zugriff hat, an den Coprozessor übertragen werden, wobei die vorbestimmte Pipelinestufe (250) sich in der ersten Pipeline befindet und dafür ausgelegt ist, zu bewirken, wenn einer der Ladebefehle verarbeitet wird, daß ein Token in der Ladeschlange angeordnet wird, welcher jedes Datenobjekt kennzeichnet, das übertragen werden soll, und wobei die Partnerpipelinestufe (275) sich in der zweiten Pipeline befindet und in der Weise betreibbar ist, daß sie nach Empfang jedes Token von der Ladeschlange bewirkt, daß das entsprechende Datenobjekt an den Coprozessor übertragen wird.
  19. Datenverarbeitungsvorrichtung nach Anspruch 17, wobei die vorbestimmte Pipelinestufe eine Zurückschreibestufe (250) in der ersten Pipeline ist und die Partnerpipelinestufe eine Zurückschreibestufe (275) in der zweiten Pipeline ist.
  20. Datenverarbeitungsvorrichtung nach Anspruch 18, soweit dieser von Anspruch 16 abhängig ist, wobei der Ladebefehl und der Speicherbefehl vektorisierte Coprozessorbefehle sein kön nen, welche mehrere Datenobjekte definieren, die übertragen werden sollen, und wobei die Vorrichtung weiterhin eine Flußsteuerlogik aufweist, die zumindest entweder der Ladeschlange oder der Speicherschlange zugeordnet ist und die in der Weise betreibbar ist, daß sie ein Steuersignal an die vorbestimmte Pipelinestufe sendet, um die Ausgabe von Token durch die vorbestimmte Pipelinestufe zu stoppen, während festgestellt wird, daß die zugehörige Lade- oder Speicherschlange möglicherweise voll wird.
  21. Datenverarbeitungsvorrichtung nach Anspruch 20, wobei die Flußsteuerlogik für die Speicherschlange vorgesehen ist, und wobei die Flußsteuerlogik in der Weise betreibbar ist, daß sie das Steuersignal ausgibt, nachdem sie eine Anzeige von dem Hauptprozessor empfangen hat, daß die Partnerpipelinestufe kein Datenobjekt annehmen kann.
  22. Datenverarbeitungsvorrichtung nach Anspruch 21, wobei die Ladeschlange ein Doppelpuffer ist.
  23. Datenverarbeitungsvorrichtung nach Anspruch 1, wobei der Hauptprozessor in der Weise betreibbar ist, daß er, wenn es notwendig ist, Coprozessorbefehle sowohl aus der ersten als auch aus der zweiten Pipeline auszuspülen, ein Spülsignal an den Coprozessor sendet, welches das Tag angibt, das sich auf den ältesten Befehl bezieht, der ausgespült werden muß, wobei der Coprozessor in der Weise betreibbar ist, daß er den ältesten Befehl anhand des Tags identifiziert und aus der zweiten Pipeline den ältesten Befehl und alle späteren Befehle innerhalb des Coprozessors ausspült bzw. entfernt.
  24. Datenverarbeitungsvorrichtung nach Anspruch 23, wobei eine oder mehrere der zumindest einen Synchronisierungsschlangen in Reaktion auf das Spülsignal ausgespült werden, wobei das Tag verwendet wird, um zu identifizieren, welche Token innerhalb der Schlange ausgespült bzw. entfernt werden sollen.
  25. Datenverarbeitungsvorrichtung nach einem der vorstehenden Ansprüche, wobei eine Mehrzahl der Coprozessoren vorgesehen ist, wobei jede Synchronisierungsschlange eine Pipelinestufe in dem Hauptprozessor mit einer Pipelinestufe in einem der Coprozessoren verbindet.
  26. Datenverarbeitungsvorrichtung nach einem der vorstehenden Ansprüche, wobei die Datenverarbeitungsvorrichtung eine synchrone Ausgestaltung hat, so daß bewirkt wird, daß die Token in der Schlange durch die vorbestimmte Pipelinestufe angeordnet werden und von der Schlange durch die Partnerpipelinestufe nach bzw. bei Änderungsflanken eines Taktsignals empfangen werden.
  27. Verfahren zur Synchronisierung zwischen Pipelines in einer Datenverarbeitungsvorrichtung, wobei die Datenverarbeitungsvorrichtung einen Hauptprozessor (40) aufweist, der in der Weise betreibbar ist, daß er eine Folge von Befehlen ausführt, und einen Coprozessor (110) aufweist, der in der Weise betreibbar ist, daß er Befehle des Coprozessors in der Folge von Befehlen ausführt, wobei der Hauptprozessor eine erste Pipeline (30) aufweist, die eine erste Mehrzahl von Pipelinestufen hat, und der Coprozessor eine zweite Pipeline (130) aufweist, welche eine zweite Mehrzahl von Pipelinestufen hat, und wobei jeder Coprozessorbefehl derart ausgelegt ist, daß er sowohl durch die erste Pipeline als auch durch die zweite Pipeline hindurchgeführt wird, wobei das Verfahren dadurch gekennzeichnet ist, daß es die Schritte aufweist: (a) Verbinden einer vorbestimmten Pipelinestufe in einer der Pipelines mit einer Partnerpipelinestufe in der anderen der Pipelines über eine Synchronisierungsschlange (300, 310, 320, 330, 340, 400, 410), welche einen First-In-First-Out-(FIFO-)Puffer aufweist, der eine vorbestimmte Mehrzahl von Einträgen hat, (b) Anordnen eines Token in einem Eintrag der Synchronisierungsschlange, wenn die vorbestimmte Pipelinestufe einen Coprozessorbefehl verarbeitet, wobei der Token ein Tag enthält, welches den Coprozessorbefehl eindeutig kennzeichnet, auf welchen der Token sich bezieht, (c) nach Empfang des Token von der Synchronisierungsschlange durch die Partnerpipelinestufe Verarbeiten des Coprozessorbefehls innerhalb der Partnerpipelinestufe, wodurch man eine Synchronisierung der ersten und der zweiten Pipelines zwischen der vorbestimmten Pipelinestufe und der Partnerpipelinestufe erhält, ohne daß Signale mit fester Zeitgebung zwischen den Pipelines übertragen werden.
  28. Verfahren nach Anspruch 27, wobei eine Mehrzahl der Synchronisierungsschlangen vorgesehen ist und wobei die Schritte (a) bis (c) für jede Synchronisierungsschlange ausgeführt werden.
  29. Verfahren nach Anspruch 27 oder 28, wobei eine der zumindest einen Synchronisierungsschlangen eine Befehlsschlange (300) ist, wobei die vorbestimmte Pipelinestufe (190) sich in der ersten Pipeline befindet und die Partnerpipelinestufe (205) sich in der zweiten Pipelinestufe befindet, wobei das Verfahren die Schritte aufweist: in Schritt (b) Anordnen eines Token in der Befehlsschlange, welcher einen Coprozessorbefehl identifiziert, und in Schritt (c) nach Empfang des Token Beginnen mit der Verarbeitung des Coprozessorbefehls in der Partnerpipelinestufe, der durch den Token identifiziert wurde.
  30. Verfahren nach einem der Ansprüche 27 bis 29, wobei eine der zumindest einen Synchronisierungsschlangen eine Löschschlange (310) ist und wobei die vorbestimmte Pipelinestufe (210) sich in der ersten Pipeline und die Partnerpipelinestufe (225) sich in der zweiten Pipeline befindet, wobei das Verfahren die Schritte aufweist: in Schritt (b) Anordnen eines Token in der Löschschlange, welcher kennzeichnet, ob ein Coprozessorbefehl an der vorbestimmten Pipelinestufe gelöscht werden soll, und in Schritt (c) nach Empfang des Token von der Löschschlange durch die Partnerpipelinestufe und für den Fall, daß der Token kennzeichnet, daß der Coprozessorbefehl gelöscht werden soll, Bewirken, daß der Coprozessorbefehl gelöscht wird.
  31. Verfahren nach einem der Ansprüche 27 bis 30, wobei eine der zumindest einen Synchronisierungsschlangen eine Abschlußschlange (320) ist, wobei die vorbestimmte Pipelinestufe (290) sich in der ersten Pipeline befindet und die Partnerpipelinestufe (275) sich in der zweiten Pipeline befindet, wobei das Verfahren die Schritte aufweist: in Schritt (b) Anordnen eines Token in der Abschlußschlange, welcher die Erlaubnis für einen Coprozessorbefehl an der vorbestimmten Pipelinestufe angibt, daß er aus der zweiten Pipeline in einen Ruhezustand versetzt wird, und in Schritt (c) nach Empfang des Token von der Abschlußschlange durch die Partnerpipelinestufe und für den Fall, daß der Token angibt, daß der Coprozessorbefehl in den Ruhezustand versetzt werden kann, Bewirken, daß der Coprozessorbefehl in den Ruhezustand versetzt wird.
  32. Verfahren nach einem der Ansprüche 27 bis 31, wobei eine der zumindest einen Synchronisierungsschlangen eine Längenschlange (330) ist, wobei die vorbestimmte Pipelinestufe (205) sich in der zweiten Pipeline befindet und die Partnerpipelinestufe (260) sich in der ersten Pipeline befindet, und wobei das Verfahren die Schritte aufweist: in Schritt (b) für einen vektorisierten Coprozessorbefehl Anordnen eines Token in der Längenschlange, welcher eine Längeninformation für den vektorisierten Coprozessorbefehl angibt, und in Schritt (c) nach Empfang des Token von der Längenschlange durch die Partnerpipelinestufe Berücksichtigen der Längeninformation bei der weiteren Verarbeitung des vektorisierten Coprozessorbefehls in der ersten Pipeline.
  33. Verfahren nach einem der Ansprüche 27 bis 32, wobei eine der zumindest einen Synchronisierungsschlange eine Annahmeschlange (340), wobei die vorbestimmte Pipelinestufe (215) sich in der zweiten Pipeline befindet und die Partnerpipelinestufe (270) sich in der ersten Pipeline befindet, wobei das Verfahren die Schritte aufweist: in Schritt (b) Anordnen eines Token in der Annahmeschlange, welcher angibt, ob ein Coprozessorbefehl in der vorbestimmten Pipelinestufe für die Ausführung durch den Coprozessor angenommen werden soll, und in Schritt (c) nach Empfang des Token von der Annahmeschlange durch die Partnerpipelinestufe und für den Fall, daß der Token angibt, daß der Coprozessorbefehl nicht angenommen werden soll, daß der Coprozessorbefehl durch den Hauptprozessor abgewiesen wird.
  34. Verfahren nach einem der Ansprüche 27 bis 33, wobei eine der zumindest einen Synchronisierungsschlangen eine Speicherschlange (400) ist, die verwendet wird, wenn der Coprozessorbefehl ein Speicherbefehl ist, der in der Weise betreibbar ist, daß er bewirkt, daß Datenobjekte von dem Coprozessor in den durch den Hauptprozessor zugänglichen Speicher übertragen werden, wobei die vorbestimmte Pipelinestufe (215) sich in der zweiten Pipeline befindet und die Partnerpipelinestufe (230) sich in der ersten Pipeline befindet, wobei das Verfahren die Schritte aufweist: in Schritt (b), wenn einer der Speicherbefehle verarbeitet wird, Anordnen eines Token in der Speicherschlange, welcher jedes Datenobjekt kennzeichnet, das übertragen werden soll, und in Schritt (c), nach Empfang jedes Token aus der Speicherschlange durch die Partnerpipelinestufe, Bewirken, daß das entsprechende Datenobjekt an den Speicher übertragen wird.
  35. Verfahren nach einem der Ansprüche 27 bis 34, wobei eine der zumindest einen Synchronisierungsschlangen eine Ladeschlange (410) ist, die verwendet wird, wenn der Coprozessorbefehl ein Ladebefehl ist, der in der Weise betreibbar ist, daß er bewirkt, daß Datenobjekte aus dem für den Hauptprozessor zugänglichen Speicher an den Coprozessor übertragen werden, wobei die vorbestimmte Pipelinestufe (250) sich in der ersten Pipeline befindet und die Partnerpipelinestufe (275) sich in der zweiten Pipeline befindet, wobei das Verfahren die Schritte aufweist: in Schritt (b), wenn einer der Ladebefehle verarbeitet wird, Anordnen eines Token in der Ladeschlange, welcher jedes zu übertragende Datenobjekt identifiziert, und in Schritt (c), nach Empfang jedes Token aus der Ladeschlange durch die Partnerpipelinestufe, Bewirken, daß das entsprechende Datenobjekt an den Coprozessor übertragen wird.
  36. Verfahren nach Anspruch 35, soweit dieser von Anspruch 34 abhängig ist, wobei der Ladebefehl und der Speicherbefehl Coprozessorbefehle in Vektorform sein können, welche mehrere zu übertragende Datenobjekte definieren, und wobei das Verfahren weiterhin den Schritt aufweist: (d) mindestens entweder für die Ladeschlange oder für die Speicherschlange Senden eines Steuersignals an die vorbestimmte Pipelinestufe, um die Ausgabe von Token durch die vorbestimmte Pipelinestufe zu stoppen, während festgestellt wird, daß die zugehörige Lade- oder Speicherschlange möglicherweise voll wird.
  37. Verfahren nach Anspruch 36, wobei Schritt (d) für die Speicherschlange ausgeführt wird, und wobei in Schritt (d) das Verfahren den Schritt aufweist, daß das Steuersignal nach Empfang einer Anzeige von dem Hauptprozessor ausgegeben wird, so daß die Partnerpipelinestufe kein Datenobjekt annehmen kann.
  38. Verfahren nach Anspruch 27, wobei dann, wenn es notwendig ist, Coprozessorbefehle sowohl aus der ersten als auch aus der zweiten Pipeline herauszuspülen bzw. zu löschen, das Verfahren weiterhin die Schritte aufweist: Senden eines Spülsignals von dem Hauptprozessor an den Coprozessor, welches das Tag kennzeichnet, das sich auf den ältesten Befehl bezieht, der ausgespült werden muß, innerhalb des Coprozessors Identifizieren des ältesten Befehls anhand des Tags und Ausspülen des ältesten Befehls und aller späteren Befehle innerhalb des Coprozessors aus der zweiten Pipeline.
  39. Verfahren nach Anspruch 38, welches weiterhin den Schritt aufweist, daß eine oder mehrere der zumindest einen Synchronisierungsschlangen in Reaktion auf das Spülsignal ausgespült werden, wobei das Tag verwendet wird, um zu kennzeichnen, welche Token innerhalb der Schlange ausgespült werden sollen.
  40. Verfahren nach einem der Ansprüche 27 bis 39, wobei eine Mehrzahl der Coprozessoren vorgesehen ist, wobei jede Synchronisierungsschlange eine Pipeline in dem Hauptprozessor mit einer Pipelinestufe in einem der Coprozessoren verbindet.
  41. Verfahren nach einem der Ansprüche 27 bis 40, wobei die Datenverarbeitungsvorrichtung eine synchrone Auslegung hat, so daß bei Wechselflanken eines Taktzyklus die Token in der Schlange durch die vorbestimmte Pipelinestufe angeordnet und aus der Schlange durch die Partnerpipelinestufe empfangen werden.
DE60306937T 2002-09-04 2003-06-04 Synchronisierung von pipelines in einem datenverarbeitungsgerät Expired - Lifetime DE60306937T4 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB0220559A GB2392742B (en) 2002-09-04 2002-09-04 Synchronisation between pipelines in a data processing apparatus
GB0220559 2002-09-04
PCT/GB2003/002411 WO2004023290A1 (en) 2002-09-04 2003-06-04 Synchronisation between pipelines in a data processing apparatus

Publications (2)

Publication Number Publication Date
DE60306937T2 DE60306937T2 (de) 2007-02-15
DE60306937T4 true DE60306937T4 (de) 2009-03-05

Family

ID=9943500

Family Applications (2)

Application Number Title Priority Date Filing Date
DE60306937A Expired - Lifetime DE60306937D1 (de) 2002-09-04 2003-06-04 Synchronisierung von pipelines in einem datenverarbeitungsgerät
DE60306937T Expired - Lifetime DE60306937T4 (de) 2002-09-04 2003-06-04 Synchronisierung von pipelines in einem datenverarbeitungsgerät

Family Applications Before (1)

Application Number Title Priority Date Filing Date
DE60306937A Expired - Lifetime DE60306937D1 (de) 2002-09-04 2003-06-04 Synchronisierung von pipelines in einem datenverarbeitungsgerät

Country Status (13)

Country Link
US (1) US7490221B2 (de)
EP (1) EP1535144B3 (de)
JP (1) JP3981378B2 (de)
KR (1) KR100983786B1 (de)
CN (1) CN100367193C (de)
AU (1) AU2003241029A1 (de)
DE (2) DE60306937D1 (de)
GB (1) GB2392742B (de)
IL (2) IL165381A0 (de)
MY (1) MY131233A (de)
RU (1) RU2005109409A (de)
TW (1) TWI309019B (de)
WO (1) WO2004023290A1 (de)

Families Citing this family (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7590823B1 (en) * 2004-08-06 2009-09-15 Xilinx, Inc. Method and system for handling an instruction not supported in a coprocessor formed using configurable logic
US7546441B1 (en) 2004-08-06 2009-06-09 Xilinx, Inc. Coprocessor interface controller
US7590822B1 (en) * 2004-08-06 2009-09-15 Xilinx, Inc. Tracking an instruction through a processor pipeline
US7346759B1 (en) 2004-08-06 2008-03-18 Xilinx, Inc. Decoder interface
US7603544B2 (en) * 2004-12-23 2009-10-13 Intel Corporation Dynamic allocation of a buffer across multiple clients in multi-threaded processor without performing a complete flush of data associated with allocation
US7328331B2 (en) * 2005-01-25 2008-02-05 Hewlett-Packard Development Company, L.P. Method and system of aligning execution point of duplicate copies of a user program by copying memory stores
JP4527571B2 (ja) * 2005-03-14 2010-08-18 富士通株式会社 再構成可能演算処理装置
JP3867804B2 (ja) * 2005-03-22 2007-01-17 セイコーエプソン株式会社 集積回路装置
US7493471B2 (en) * 2005-10-31 2009-02-17 Sun Microsystems, Inc. Coprocessor receiving renamed register identifier from master to complete an operation upon register data ready
US7490223B2 (en) * 2005-10-31 2009-02-10 Sun Microsystems, Inc. Dynamic resource allocation among master processors that require service from a coprocessor
US7668186B1 (en) * 2006-03-07 2010-02-23 Xilinx, Inc. Token ecosystem for buffer management
US8145882B1 (en) * 2006-05-25 2012-03-27 Mips Technologies, Inc. Apparatus and method for processing template based user defined instructions
US7647475B2 (en) * 2006-09-06 2010-01-12 Mips Technologies, Inc. System for synchronizing an in-order co-processor with an out-of-order processor using a co-processor interface store data queue
US8032734B2 (en) * 2006-09-06 2011-10-04 Mips Technologies, Inc. Coprocessor load data queue for interfacing an out-of-order execution unit with an in-order coprocessor
US7594079B2 (en) 2006-09-29 2009-09-22 Mips Technologies, Inc. Data cache virtual hint way prediction, and applications thereof
US20080082793A1 (en) * 2006-09-29 2008-04-03 Mips Technologies, Inc. Detection and prevention of write-after-write hazards, and applications thereof
US9946547B2 (en) 2006-09-29 2018-04-17 Arm Finance Overseas Limited Load/store unit for a processor, and applications thereof
US8407451B2 (en) 2007-02-06 2013-03-26 International Business Machines Corporation Method and apparatus for enabling resource allocation identification at the instruction level in a processor system
US8006068B1 (en) * 2007-04-18 2011-08-23 Xilinx, Inc. Processor access to data cache with fixed or low variable latency via instructions to an auxiliary processing unit
US7984272B2 (en) * 2007-06-27 2011-07-19 International Business Machines Corporation Design structure for single hot forward interconnect scheme for delayed execution pipelines
US7769987B2 (en) * 2007-06-27 2010-08-03 International Business Machines Corporation Single hot forward interconnect scheme for delayed execution pipelines
JP2009054032A (ja) * 2007-08-28 2009-03-12 Toshiba Corp 並列プロセッサ
US7788470B1 (en) * 2008-03-27 2010-08-31 Xilinx, Inc. Shadow pipeline in an auxiliary processor unit controller
JP5493837B2 (ja) * 2009-12-25 2014-05-14 富士通株式会社 演算処理装置、情報処理装置及び演算処理装置のパイプライン制御方法
US9304774B2 (en) * 2011-02-04 2016-04-05 Qualcomm Incorporated Processor with a coprocessor having early access to not-yet issued instructions
JP5870994B2 (ja) * 2011-03-04 2016-03-01 日本電気株式会社 デッドロック回避方法、デッドロック回避機構
JP2012252374A (ja) * 2011-05-31 2012-12-20 Renesas Electronics Corp 情報処理装置
KR101849702B1 (ko) 2011-07-25 2018-04-17 삼성전자주식회사 외부 인트린직 인터페이스
US10534606B2 (en) 2011-12-08 2020-01-14 Oracle International Corporation Run-length encoding decompression
WO2013184139A1 (en) * 2012-06-08 2013-12-12 Hewlett-Packard Development Company, L.P. Accessing memory
US9378023B2 (en) 2012-06-13 2016-06-28 International Business Machines Corporation Cross-pipe serialization for multi-pipeline processor
US9582287B2 (en) * 2012-09-27 2017-02-28 Intel Corporation Processor having multiple cores, shared core extension logic, and shared core extension utilization instructions
US20140281429A1 (en) * 2013-03-14 2014-09-18 Qualcomm Incorporated Eliminating redundant synchronization barriers in instruction processing circuits, and related processor systems, methods, and computer-readable media
CN103383641A (zh) * 2013-04-19 2013-11-06 中国科学院自动化研究所 一种多流水线同步装置
EP3037957A4 (de) * 2013-08-19 2017-05-17 Shanghai Xinhao Microelectronics Co. Ltd. Puffersystem und verfahren auf der basis eines befehlscachespeichers
US9325520B2 (en) * 2013-09-06 2016-04-26 Huawei Technologies Co., Ltd. System and method for an asynchronous processor with scheduled token passing
US10318305B2 (en) * 2013-09-06 2019-06-11 Huawei Technologies Co., Ltd. System and method for an asynchronous processor with pepelined arithmetic and logic unit
US11113054B2 (en) 2013-09-10 2021-09-07 Oracle International Corporation Efficient hardware instructions for single instruction multiple data processors: fast fixed-length value compression
EP2940575B1 (de) * 2014-05-02 2018-05-09 Nxp B.V. Steuerungsschaltungen, Datenschnittstellenblöcke und Verfahren zur Übertragung von Daten
US20150378900A1 (en) * 2014-06-27 2015-12-31 International Business Machines Corporation Co-processor memory accesses in a transactional memory
US11132203B2 (en) * 2014-08-14 2021-09-28 Texas Instruments Incorporated System and method for synchronizing instruction execution between a central processor and a coprocessor
US9870339B2 (en) * 2015-06-26 2018-01-16 Intel Corporation Hardware processors and methods for tightly-coupled heterogeneous computing
US10120683B2 (en) * 2016-04-27 2018-11-06 International Business Machines Corporation Supporting even instruction tag (‘ITAG’) requirements in a multi-slice processor using null internal operations (IOPs)
US10599488B2 (en) 2016-06-29 2020-03-24 Oracle International Corporation Multi-purpose events for notification and sequence control in multi-core processor systems
US10380058B2 (en) * 2016-09-06 2019-08-13 Oracle International Corporation Processor core to coprocessor interface with FIFO semantics
US10783102B2 (en) 2016-10-11 2020-09-22 Oracle International Corporation Dynamically configurable high performance database-aware hash engine
GB2563384B (en) 2017-06-07 2019-12-25 Advanced Risc Mach Ltd Programmable instruction buffering
US10552162B2 (en) 2018-01-22 2020-02-04 International Business Machines Corporation Variable latency flush filtering
GB2570729B (en) * 2018-02-06 2022-04-06 Xmos Ltd Processing system
CN110896406A (zh) * 2018-09-13 2020-03-20 华为技术有限公司 数据存储方法、装置及服务器
CN111258657B (zh) * 2020-01-23 2020-11-20 上海燧原智能科技有限公司 流水线控制方法及相关设备
US11734017B1 (en) 2020-12-07 2023-08-22 Waymo Llc Methods and systems for processing vehicle sensor data across multiple digital signal processing cores virtually arranged in segments based on a type of sensor
US11301410B1 (en) * 2020-12-13 2022-04-12 Advanced Mciro Devices, Inc. Tags for request packets on a network communication link
CN112738469A (zh) * 2020-12-25 2021-04-30 浙江合众新能源汽车有限公司 图像处理方法、设备、系统和计算机可读介质
US20220247564A1 (en) * 2021-02-01 2022-08-04 Protegrity Corporation Parallel tokenization of floating point information in a distributed network environment

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2564805B2 (ja) * 1985-08-08 1996-12-18 日本電気株式会社 情報処理装置
US5241635A (en) * 1988-11-18 1993-08-31 Massachusetts Institute Of Technology Tagged token data processing system with operand matching in activation frames
US5197140A (en) * 1989-11-17 1993-03-23 Texas Instruments Incorporated Sliced addressing multi-processor and method of operation
US5430850A (en) * 1991-07-22 1995-07-04 Massachusetts Institute Of Technology Data processing system with synchronization coprocessor for multiple threads
US6112017A (en) * 1992-06-30 2000-08-29 Discovision Associates Pipeline processing machine having a plurality of reconfigurable processing stages interconnected by a two-wire interface bus
US6240508B1 (en) * 1992-07-06 2001-05-29 Compaq Computer Corporation Decode and execution synchronized pipeline processing using decode generated memory read queue with stop entry to allow execution generated memory read
US5572704A (en) * 1993-12-15 1996-11-05 Silicon Graphics, Inc. System and method for controlling split-level caches in a multi-processor system including data loss and deadlock prevention schemes
US5860000A (en) 1996-01-31 1999-01-12 Hitachi Micro Systems, Inc. Floating point unit pipeline synchronized with processor pipeline
US6674536B2 (en) * 1997-04-30 2004-01-06 Canon Kabushiki Kaisha Multi-instruction stream processor
WO1999004334A1 (en) 1997-07-16 1999-01-28 California Institute Of Technology Improved devices and methods for asynchronous processing
US6477638B1 (en) * 1999-10-01 2002-11-05 Hitachi, Ltd. Synchronized instruction advancement through CPU and FPU pipelines

Also Published As

Publication number Publication date
CN1678988A (zh) 2005-10-05
MY131233A (en) 2007-07-31
DE60306937D1 (de) 2006-08-31
TWI309019B (en) 2009-04-21
IL165381A (en) 2010-04-15
JP2005538439A (ja) 2005-12-15
RU2005109409A (ru) 2005-09-10
GB2392742A (en) 2004-03-10
EP1535144B1 (de) 2006-07-19
GB2392742B (en) 2005-10-19
EP1535144A1 (de) 2005-06-01
US7490221B2 (en) 2009-02-10
US20040044878A1 (en) 2004-03-04
DE60306937T2 (de) 2007-02-15
JP3981378B2 (ja) 2007-09-26
GB0220559D0 (en) 2002-10-09
KR20050057199A (ko) 2005-06-16
AU2003241029A1 (en) 2004-03-29
EP1535144B3 (de) 2009-02-18
WO2004023290A1 (en) 2004-03-18
CN100367193C (zh) 2008-02-06
KR100983786B1 (ko) 2010-09-28
TW200409023A (en) 2004-06-01
IL165381A0 (en) 2006-01-15

Similar Documents

Publication Publication Date Title
DE60306937T4 (de) Synchronisierung von pipelines in einem datenverarbeitungsgerät
DE69629495T2 (de) Vereinheitlichter multifunktions-operationsverteiler für die ungeordnete befehlsexekution in einem superskalaren prozessor
DE4129614C2 (de) System und Verfahren zur Datenverarbeitung
DE69831344T2 (de) Effiziente verarbeitung von gebündelten sprungbefehlen
DE102018126005A1 (de) Synchronisation in einer Multi-Kachel-, Multi-Chip-Verarbeitungsanordnung
DE19506435C2 (de) Verfahren und Einrichtung zum Vermeiden von Rückschreibkonflikten zwischen einen gemeinsamen Rückschreibpfad verwendenden Ausführungseinheiten
DE19983476B4 (de) Verfahren und Schaltungsanordnung zur Einplanung von Operationen unter Verwendung einer Abhängigkeitsmatrix
DE4302495C2 (de) Einrichtung und Verfahren zum Bestimmen der Länge eines Befehls in einem sequentiellen Befehlsstrom
DE102014011332B4 (de) Priorisieren von anweisungen basierend auf typ
DE2855106A1 (de) Einrichtung zur durchfuehrung von instruktionsverzweigungen
DE102004013676B4 (de) Schaltung in einem Prozessor zur Steuerung einer iterativen Ausführung einer Gruppe von Programmanweisungen
DE102018126001A1 (de) Synchronisation in einem Multi-Kachel-Verarbeitungsarray
DE69734403T2 (de) Verfahren im bezug auf die behandlung von konditionellen sprüngen in einer multietagen-pipeline-struktur
DE19983589B4 (de) Hochfrequenz-Pipeline-Entkopplungswarteschlangengestaltung
DE3914265C2 (de)
DE3116100C2 (de) Datenverarbeitungseinheit
DE602004008911T2 (de) Verfahren und system um die reihenfolge von paketen mit hilfe eines zwischenspeichers zu gewährleisten
DE3638572C2 (de)
DE102018126004A1 (de) Synchronisation in einer Multi-Kachel-Verarbeitungsanordnung
DE102008022080A1 (de) Nachrichten-Warteschlangensystem für eine parallel integrierte Schaltkreisarchitektur und zugehöriges Betriebsverfahren
DE19855806A1 (de) Vorrichtung und Verfahren zum Durchführen von Unterprogrammaufruf- und Rücksprungoperationen
DE102014000382A1 (de) Vorhersage indirekter Abzweigungen
DE3508640A1 (de) Computersystem zur implementierung eines ereignisgesteuerten simulationsalgorithmus
DE112020004065T5 (de) Komplexe Daisy-Chain-Befehle
DE19842254A1 (de) Datenverarbeitungsgerät