DE60221406T2

DE60221406T2 - Mehrprozessor-infrastruktur zur bereitstellung einer flexiblen bandweitenzuteilung über mehrere instanziierungen separater datenbusse, steuerbusse und unterstützungsmechanismen

Info

Publication number: DE60221406T2
Application number: DE60221406T
Authority: DE
Inventors: Mark Uxbridge Rosenbluth; Gilbert Framingham WOLRICH; Debra Sudbury BERNSTEIN; Myles Charlestown WILDE; Matthew Worcester ADILETTA
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2001-08-27
Filing date: 2002-08-27
Publication date: 2008-04-17
Anticipated expiration: 2022-08-28
Also published as: US7225281B2; EP1421504A1; DE60221406D1; AU2002339857A1; ATE368259T1; WO2003019399A9; CA2458572A1; TWI249674B; WO2003019399A8; WO2003019399A1; CA2458572C; EP1421504B1; US20030105899A1

Description

Allgemeiner Stand der Technik
Herkömmliche Bus-Schemata definieren einen Bus als eine unteilbare Einheit. Obgleich Befehle und Daten über separate physische Kanäle übertragen werden können, um die Gleichzeitigkeit zu verbessern, verknüpfen die Busprotokolle die Kanäle. Die Befehle enthalten eine feste Anzahl vorgegebener Felder mit Befehlsinformationen, wie zum Beispiel Adresse, Länge (Anzahl der Datenbytes) und Operationsart (zum Beispiel Lesen, Schreiben, Cachezeilenlöschung und so weiter).
In Romilly Bowden: "What is HART?", Romilly's Hart and Fieldbus Web Site, [Online] 1997, XP002219605, ist ein "Highway Addressable Remote Transducer" (HART) beschrieben, bei dem es sich um ein digitales Kommunikationsprotokoll handelt, das für Messungen in technischen Prozessen vorgesehen ist.
US-A-4045782 beschreibt ein mikroprogrammiertes Prozessorsystem, wobei mehrere Makroinstruktionen in einem adressierbaren Speicher gespeichert sind, der zum Stand der Technik in Bezug auf diese Erfindung gehört.
Herkömmliche Bus-Schemata können keine Befehle ausgeben, die durch Busmaster erzeugt werden und die durch Busziele für jedes Ziel einzeln interpretiert werden.
Beschreibung der Zeichnungen
1 ist ein Blockschaubild eines Verarbeitungssystems, das mit einer Busarbitrierlogik arbeitet, um den Informationsaustausch zwischen Busmastern und Buszielen zu unterstützen.
2 ist ein detailliertes Blockschaubild des Verarbeitungssystems (von 1), das verschiedene Busse, einschließlich Befehls- und Push-/Pullbusse, und zugeordnete Arbiter der Busarbitrierlogik zeigt.
3 ist eine Veranschaulichung eines beispielhaften Formats eines Befehls, der über den Befehlsbus transportiert wird.
4 ist ein Schaubild eines beispielhaften Befehlsbusdatenpfades des Verarbeitungssystems.
5 ist ein Schaubild eines beispielhaften Pushbusdatenpfades des Verarbeitungssystems.
6 ist ein Schaubild eines beispielhaften Pullbusdatenpfades des Verarbeitungssystems.
Detaillierte Beschreibung
Die Erfindung ist wie in den Ansprüchen 1, 10, 11, 18 und 20 dargelegt.
Wenden wir uns 1 zu, wo ein System 10 gezeigt ist, das mehrere erste Einheiten 12, die als Master 12a, 12b, 12c, ..., 12j gezeigt sind, und mehrere zweite Einheiten 14, die als Ziele 14a, 14b, 14c, ..., 14k gezeigt sind, enthält, die die Busarbitrierlogik 16 benutzen, um den Informationsaustausch über ein Bussystem 17 zu steuern. Gemeinsam bilden das Bussystem 17 und die Busarbitrierlogik 16 eine Busstruktur 18. Die Komponenten der Busarbitrierlogik 16 enthalten einen Befehlsbusarbiter 19, einen Pushbusarbiter 20 und einen Pullbusarbiter 22. Diese Arbiter 19, 20, 22 sind dem Betrieb der verschiedenen Busse in dem Bussystem 17 zugeordnet, wie unter Bezug auf die 2-6 beschrieben ist.
Der Master 12 kann Bauelemente wie zum Beispiel Prozessoren (zum Beispiel Allzweckmikroprozessoren, eingebettete Mikrocontroller) und externe Buscontroller enthalten. Die Ziele 14 können Speicherressourcen (zum Beispiel Schnittstellen zu DRAM, SRAM), E/A-Ressourcen (zum Beispiel Schnittstellen zu Medien, Medienschaltnetzen) sowie anderen Arten von Systemressourcen enthalten. Ein Master kann auch als ein Ziel dienen. Zum Beispiel könnte ein Buscontroller, der es dem System ermöglicht, mit einem Host- oder sonstigen System über einen externen Bus zu kommunizieren, die Funktionen sowohl des Masters als auch des Ziels ausführen.
Der Einfachheit halber sind nur zwei der Master, Master 0 und 1, und drei der Ziele, Ziele 0-2, in den 2-6 gezeigt. Einer der Master, Master 0, ist als ein Gerät gezeigt, das sowohl als ein Master als auch als ein Ziel dienen kann.
Wenden wir uns 2 zu, wo das System 10 drei separate Busstrukturen enthält: einen Befehlsbus 30 (in Strichlinien dargestellt), einen Pushbus 32 und einen Pullbus 34. Die jeweiligen Arbitriereinheiten 19, 20 und 24 sind dem Befehlsbus 30, dem Pushbus 32 bzw. dem Pullbus 34 zugeordnet und steuern deren Verwendung. Der Befehlsbus 30 enthält auf der Master-Seite der Arbitrierlogik einen ersten Befehlsbus 36 und auf der Ziel-Seite des Arbiters einen zweiten Befehlsbus 37. Der masterseitige Befehlsbus 36 enthält einen entsprechenden Befehlsbus für jeden Master, zum Beispiel Befehlsbusse 36a und 36b für Master 12a bzw. und Master 12b.
Der Pushbus 32 enthält einen ersten Pushbus (Ziel-Seite) 38 und einen zweiten Pushbus (Master-Seite) 40. Der Pullbus enthält einen ersten Pullbus (Ziel-Seite) 42 und einen zweiten Pullbus 44 (Master-Seite). Auf der Ziel-Seite werden der Ziel-Pushbus 38 und der Ziel-Pullbus 42 von den Zielen dafür benutzt, Befehle und Daten zwischen den Zielen und dem Pushbusarbiter 20 bzw. dem Pullbusarbiter 22 zu transportieren.
Die Master 12a und 12b benutzen den Befehlsbusarbiter 19 zum Arbitrieren für die Benutzung des Befehlsbusses 30 und insbesondere des zielseitigen Befehlsbusses 37. Die Ziele 14a, 14b, 14c benutzen jeweils den Pushbusarbiter 20 und den Pullbusarbiter 22 zum Arbitrieren für die Benutzung des masterseitigen Pushbusses 40 bzw. des Pullbusses 34. Die Steuersignale in Verbindung mit der Busarbitrierung (nicht gezeigt) werden später unter Bezug auf die 4-6 besprochen.
Wenden wir uns 3 zu, wo ein beispielhaftes Format eines Befehls 50 gezeigt ist, der über den Befehlsbus 30 transportiert wird. Der Befehl 50 ist in mehrere Felder 52a, 52b, 52c, ..., 52p unterteilt, die codierte Informationen transportieren. Die Felder 52 können unterschiedliche Breiten haben. Die Felder 52 enthalten ein Ziel-ID-Feld 52a und ein Operations-(oder Befehls-)Artfeld 52b. Jedes Ziel 14 hat eine einmalige, festverdrahtete Identifikationsnummer ("ID"). Das Ziel-ID-Feld 52a zeigt anhand der ID an, welches der Ziele den Befehl entgegennehmen soll. Die Master 12 senden einen Befehl im Format des Befehls 50 an alle Ziele 14, welche die Ziel-ID parallel decodieren, um festzustellen, ob der Befehl 50 für die gedacht ist. Ein Satz Codes, die den Ziel-IDs für einen beispielhaften Satz Ziele entsprechen, ist in TABELLE 1 gezeigt:

Code Ziel

00 0000 Keines (kein Befehl auf dem Befehlsbus)

00 0001 Medienschnittstelle

00 0010 SRAM-Schnittstelle

00 0011 DRAM-Schnittstelle

00 1001 Buscontroller

00 0100 Hash-Einheit

TABELLE 1
Das Operationsartfeld 52b spezifiziert eine Operationsart.

Jedes Ziel interpretiert die Operationsart, die durch den Code in dem Operationsartfeld 52b spezifiziert wird, um die auszuführende Operation zu bestimmen. Der Wert in dem Operationsartfeld 52b bestimmt, wie Werte in anderen Feldern durch jedes Ziel zu interpretieren sind. Die Operationsart kann so viele verschiedene Codierungen von Informationen wie Operationsarten enthalten, die die meisten (wenn nicht gar alle) Ziel-Einheiten unterstützen, zum Beispiel Lesen und Schreiben. Eines oder mehrere der Felder 52c-52p können – je nach dem Wert im Operationsartfeld – auch als Operationsart-Erweiterung verwendet werden. Eine beispielhafte Codierung für einige Befehlsarten, die durch die in TABELLE 1 oben gezeigten Ziele unterstützt werden, sind in TABELLE 2 gezeigt:

Code	DRAM-Schnittstelle	SRAM-Schnittstelle	Hash-Einheit	Medien-Schnittstelle	Buscontroller
0000	Lesen	Lesen	Hash	Lesen	Lesen
0001	Schreiben	Schreiben	Reserviert	Schreiben	Schreiben
0010	Empfange Puffer-Lesen	Tausch	Reserviert	Reserviert	Reserviert
0011	Übertrage_ Puffer-Schreiben	Bits setzen	Reserviert	Reserviert	Reserviert
0100	Kontrollstatusregister (KSR)-Lesen	Bits löschen	Reserviert	Reserviert	Reserviert
0101	KSR-Schreiben	Hinzufügen	Reserviert	Reserviert	Reserviert

TABELLE 2

Die übrigen Felder 52c bis 52p (entsprechend den Feldern Feld_1, Feld_2, ..., Feld_N) speichern andere Parameter, die von den Zielen 14 verwendet werden, wie zum Beispiel Adresse und Burst-Zählwert. Zum Beispiel, und wie in dem Befehlsformat von 3 gezeigt, wird Feld 3 verwendet, um eine Push/Pull-ID 53 zu spezifizieren, die unter anderen Informationsarten eine Quelle oder einen Bestimmungsort 54 identifiziert. Die Push/Pull-ID 53 wird über den Befehlsbus 30 an das Ziel 14 übermittelt und durch das Ziel an den Pushbusarbiter oder den Pullbusarbiter übermittelt, wenn der Befehl bedient wird. Der Pushbusarbiter bzw. der Pullbusarbiter wiederum übermittelt die Push/Pull-ID an die entsprechende Quelle (im Fall einer Pulloperation) oder den entsprechenden Bestimmungsort (im Fall einer Pushoperation) als eine Adresse. Die Definition von Feldern in dem Push/Pull-ID-Feld kann von der spezifizierten Quelle oder dem spezifizierten Bestimmungsort abhängen. Außerdem kann eines oder können mehrere der Felder 1 bis N auf der Grundlage der Operationsart anderweitig verwendet werden. Zum Beispiel kann ein Feld Byte-Masken für eine Schreib-Operationsart und eine Prioritätsstufe für eine Lese-Operationsart anzeigen.
Gemäß dem Busprotokoll von System 10 interpretiert jedes Ziel, das einen Befehl in Form des Befehls 50 empfängt, die Felder 52 für jedes Ziel einzeln. Dies ermöglicht es den Zielen, einen reichhaltigen Satz Funktionen bereitzustellen, wie zum Beispiel Lesen-Modifizieren-Schreiben mit programmierbarem Modifizieren, Datentransformation (zum Beispiel Ausführen eines Hash an Operanden und Rückmeldung des Ergebnisses) und schnelles Schreiben (Nutzen einiger Felder des Befehls, um Daten zu spezifizieren, und anderer, um eine Adresse zu spezifizieren, wodurch die Latenz und die Ressourcennutzung eines Datenbusses entfällt).
Die Master 12 geben Befehle an die Ziele 14 auf der Grundlage einer Instruktionsausführung oder eines sonstigen geeigneten Mechanismus' aus. Wenn zum Beispiel der Master ein Buscontroller ist, so kann er Befehle als ein Ergebnis einer DMA-Operation ausgeben, oder wenn durch ein anderes Gerät an dem Bus, den er steuert, auf ihn zugegriffen wird.
Wenden wir uns 4 zu, wo ein Befehlsbusdatenpfad 60 gezeigt ist. Der Befehlsarbiter 19 enthält eine Arbitriereinheit 62, die ein Befehlswarteschlange-voll-Signal 64 als Eingang von jedem der Ziele 14 empfängt. Das Befehls warteschlange-voll-Signal 64 zeigt an, wenn eine Schwellenfülle einer Befehlswarteschlange 66 in jedem Ziel erreicht ist. Die Arbitriereinheit 62 empfängt Befehlsanforderungen über Befehlsanforderungseingangsleitungen 68 von den Mastern 12 und übermittelt auf Gewährungsausgabeleitungen 70 an die Master 12 Gewährungen der Befehlsbusanforderungen durch die Master 12.
Jeder Busmaster 12, der einen Befehl auf dem Befehlsbus 30 absetzen möchte, sendet zuerst eine Anforderung an die Arbitriereinheit 60 auf einer jeweiligen der Eingangsleitungen 68. Diese Anforderung zeigt die ID des Ziels an, mit dem der Master kommunizieren möchte. Wie zuvor erwähnt, empfängt die Arbitriereinheit 62 auch Signale von jedem Ziel 14, die anzeigen, ob die Befehlswarteschlange 66 dieses Ziels voll ist oder nicht. Die Arbitriereinheit 62 verwendet die Befehlswarteschlange-voll-Informationen zum Verhindern von Gewährungen an die Befehlsanforderer, wenn die Befehlswarteschlange des Ziels, das sie brauchen, voll ist, während sie Anforderern für andere Ziele gestattet, Gewährungen zu erhalten. Das Arbitrierungsschma der Arbitriereinheit 62 kann zum Beispiel ein Reigenschema sein und kann eine programmierbare Priorität für bestimmte Master verwenden. Das Arbitrierungsschema der Arbitriereinheit 62 gewährt situationsabhängig einem anderen Busmaster Zugriff, wenn eine von zwei Bedingungen eintritt: Ein Master ist dafür vorgesehen, Zugriff gewährt zu bekommen, aber es steht keine Anforderung an; oder ein Master ist dafür vorgesehen, Zugriff gewährt zu bekommen, aber die Befehlswarteschlange des angeforderten Ziels ist voll.
Wenn die Arbitriereinheit 62 einer Busanforderung eines Masters stattgegeben hat, so überträgt dieser Master einen Befehl auf einem entsprechenden der Masterbefehlsbusse 36 an den Befehlsbusarbiter 19. Der Befehlsbusarbiter 19 enthält auch einen Multiplexer (MUX) 72, der einen Befehl von einem Master empfängt und von der Arbitriereinheit 62 in die Lage versetzt wurde, die Übertragung des Befehls über den Befehlsbus 37 an die Ziele zu steuern.
5 zeigt Details eines Pushbusdatenpfades 80. Der Pushbusarbiter 20 enthält mehrere Pushbefehlswarteschlangen 82a, 82b, 82c, 82d, eine für jedes unterstützte Ziel, die mit einem Multiplexer (MUX) 84 und einer Pushbusarbitriereinheit 86 verbunden sind. Die Pushbefehlswarteschlangen 82a, 82b, 82c, 82d sind mit entsprechenden Zielen 14a, 14b, 14c bzw. Ziel-"Master 12a" (für Operationen, bei denen der Master 0 als ein Ziel fungiert) durch Gruppen von Pushdatenbussen 88 und Pushbefehlsbussen 90, eine Gruppe für jedes Ziel in dem System, verbunden, das heißt, Busse 88a und 90a für Ziel 14a, Busse 88b und 90b für Ziel 14, Busse 88c und 90c für Ziel 14c und Busse 88d und 90d für Master 12a (als ein Ziel). Der zielseitige Bus 38 enthält auch ein Pushbefehlswarteschlange-voll-Signal (Push_CmdQ_Full) 91, um einem Ziel anzuzeigen, dass seine entsprechende Pushbefehlswarteschlange einen vorgegebenen Füllgrad erreicht hat. Der masterseitige Pushbus 40 (von 2) enthält einen Push-ID-Bus 92 und einen Pushdatenbus 94.
Nachdem ein Ziel, das einen Befehl empfangen und decodiert hat, der an dieses Ziel gerichtet war, sendet angeforderte Daten an eine entsprechende der Warteschlangen 82 auf dem entsprechenden Pushdatenbus 88. Somit speichern die Pushbefehlswarteschlangen eine Kombination aus Pushdaten und Pushbefehlen. Die Pushbefehle enthalten Push-IDs, die an die Arbitriereinheiten 86 übermittelt werden.
Daten, die in Einträgen der Pushbefehlswarteschlangen 82 gespeichert sind, werden in den MUX 84 eingespeist. Die Arbitriereinheit 86 wählt eine der Pushbefehlswarteschlangen 82 aus. Die Arbitriereinheit 86 übermittelt somit ein Auswahlsignal 96 an den MUX 84, um den MUX 84 in die Lage zu versetzen, als Ausgang (zum Übertragen auf dem Pushdatenbus 94) Daten aus der ausgewählten Pushbefehlswarte schlange bereitzustellen, und überträgt die Push-ID aus der ausgewählten Pushbefehlswarteschlange auf dem Push-ID-Bus 92.
Wenden wir uns 6 zu, wo ein Pullbusdatenpfad 100 gezeigt ist. Auf der Ziel-Seite des Pullbusarbiters 22 sind die Ziele 14 durch den Pullbus 42 (von 2) mit dem Pullbusarbiter 22 verbunden. Die Master 12 sind durch den masterseitigen Pullbus 44 (von 2) mit dem Pullbusarbiter 22 verbunden. Die Ziele 14 sind Endpunkte, und die Master 12 sind Quellen für eine Pulloperation.
Der Pullbusarbiter 22 enthält einen Multiplexer (MUX) 102, eine Arbitriereinheit 104 und Pullbefehlswarteschlangen 106a, 106b, 106c, 106d, eine für jedes unterstützte Ziel, die mit der Pullbusarbitriereinheit 104 verbunden sind. Die Pullbefehlswarteschlangen 106a, 106b, 106c, 106d sind mit entsprechenden Zielen 14a, 14b, 14c bzw. Ziel-"Master 12a" (für Operationen, bei denen der Master 0 als ein Ziel fungiert) durch Pulldatenbusse 108a, 108b, 108c bzw. 108d und Pullbefehlsbusse 110a, 110b, 110c bzw. 110d verbunden. Gemeinsam bilden die Busse 108, 110 den zielseitigen Pullbus 42. Der Arbiter 22 übermittelt auch ein Pullbefehlswarteschlange-voll-Signal (Pull_CmdQ_Full) 111 an ein Ziel, um dem Ziel anzuzeigen, dass die entsprechende Pullbefehlswarteschlange 106 fast voll ist, und ein Signal Take Data 112, um einem Ziel anzuzeigen, dass Pulldaten zu dem Ziel übertragen wurden.
Der masterseitige Pullbus 44 enthält einen Pulldatenbus 112a für den Master 12a und einen Pulldatenbus 113b für den Master 12b. Der Pulldatenbus 113 wird von den Mastern verwendet, um Pulldaten an den Arbiter 22, oder genauer gesagt, an den Multiplexer 102 zu senden. Der Pullbus 44 enthält auch einen Pull-ID-Bus 114 und ein Pull-ausgeführt-Signal (Pull_Sig_Done) 116, die es dem Arbiter 22 ermögli chen, während einer Pull-(oder Schreib-)Operation Informationen an den Master zu übermitteln.
Jedes der Ziele verwendet einen (nicht gezeigten) Datenpuffer zum Speichern von Pull-(oder Schreib-)Daten. Das Ziel empfängt den Befehl 50 über den Befehlsbus 37 (in den 2 und 4 gezeigt) und bestimmt anhand des Operationenartfeldes 52b (3) des Befehls, dass die Operation eine Pulloperation ist. Wenn das Ziel in dem Datenpuffer Platz für die Menge an Daten hat, die in dem Befehl spezifiziert ist, so arbitriert es für das Benutzen des Pulldatenbusses 34. Die Informationen, die die Position der Daten spezifizieren (das heißt, welcher Master und welche Speicherposition durch den Master für die Daten verwendet werden), wurden in dem Pull-ID-Feld 53 des Befehls 50 dargestellt. Weil sich diese Informationen in einem Befehlsfeld befinden, braucht die Einheit, die als die Quelle der Pulsdaten identifiziert wurde, nicht der Master zu sein, der den Befehl sandte. Die Quelle kann jede adressierbare Einheit sein, die einen Pfad zu dem Pulldatenbus 108 hat.
Jedes Ziel sendet die volle Pull-ID und Länge (aus dem Befehl 50 gewonnen) für Informationen, die es zu dem Ziel ziehen möchte. Das Ziel muss Pufferplatz für die Pulldaten frei haben, wenn es die Pull-ID über den entsprechenden Pullbefehlsbus 110 aufdrückt.
Die Pull-ID wird in eine entsprechende der Pullbefehlswarteschlangen 106 in dem Pullbusarbiter 22 eingereiht, sofern nicht das Pull_CmdQ_Full-Signal 111 für diese Pullbefehlswarteschlange aufgedrückt wird. Das Aufdrücken des Pull_CmdQ_Full-Signals 111 zeigt an, dass die Pullbefehlswarteschlange 106 für dieses konkrete Ziel eine vorgegebene Füllschwelle erreicht hat.
Die Arbitriereinheit 104 arbitriert zwischen den momentan gültigen Pull-IDs, die in die Pullbefehlswarteschlangen 106 eingereiht wurden, um ein Ziel, oder genauer gesagt, eine Pull-ID, die durch dieses Ziel eingereiht wurde, auszuwählen. Das Arbitrierungsschema kann eines aus einer Anzahl allgemein bekannter Schemata sein, zum Beispiel das Reigenmodell oder ein auf Priorität basierendes Schema. Die Arbitriereinheit 104 sendet die ausgewählte Pull-ID über den Pull-ID-Bus 114 an die entsprechende Quelle. Der Pullbusarbiter 22 drückt das Take_Data-Signal 112 auf das ausgewählte Ziel auf. Die Quelle übermittelt die Pulldaten an den MUX 102, der in die Lage versetzt wird, die Pulldaten auf dem Pulldatenbus 108 durch die Arbitriereinheit 104 über das Steuersignal 119 zu senden. Die Arbitriereinheit 104 drückt das Pull_done-Signal 116 auf die Quelle auf.
Somit untersteht der Schreibdatentransport der Steuerung durch das Ziel. Das Ziel einer Schreiboperation zieht die Schreib- oder Pulldaten über den Pullbus 34, wenn es sie braucht, anstatt sie zur selben Zeit wie die Schreiboperationenart gesendet zu bekommen. Darum kann das Ziel interne Puffer für die Pulldaten zuweisen, je nachdem, wann das Ziel die Daten braucht und Pufferplatz frei hat. Des Weiteren, wie zuvor angesprochen, kann das Ziel Schreibdaten auch von einer anderen Quelle als dem Befehlsinitiator erhalten, wie durch Informationen in dem Befehl angewiesen.
Die Architektur des Systems 10 ermöglicht eine flexible Bandbreitenzuteilung über mehrere Instanziierungen der verschiedenen Busse und Arbiter. Weil es separate Busse für Befehle, Pulldaten und Pulldaten gibt, können die Busse inkrementell nach Bedarf hinzugefügt werden.
Kehren wir zu 4 zurück. Wenn die Steuerbandbreite für eine Anwendung nicht ausreicht, so könnten eine oder mehrere zusätzliche Kopien des Befehlsbusses 37 und Arbiters 19 zu dem System hinzugefügt werden. Jeder Arbiter 19 könnte eine Teilmenge der Master unterstützen (zum Beispiel könnte in einer Vier-Master-Implementierung, bei der zwei Arbiter verwendet werden, jeder Arbiter ein anderes Paar der Master unterstützen), aber die Ziele würden Befehle von allen Mastern empfangen.
Für eine höhere Datenbusbandbreite könnten Kopien des Pushbusses und des Pullbusses, zusammen mit der entsprechenden Arbitrierlogik, hinzugefügt werden. Zum Beispiel könnten, mit Blick zurück auf 5, zusätzliche masterseitige Busse 40 und Arbiter 20 zu dem System hinzugefügt werden. Der Pushdatenbus 88 und der Befehlsbus 90 jedes Ziels wären mit jedem der Arbiter verbunden, so dass kein Ziel mehr als eine einzige Gruppe Pushdaten-/Befehlsbusse anzusteuern brauchte. Jeder Arbiter würde die Master (Bestimmungsorte) kennen, mit denen er verdrahtet ist, und die Daten und IDs entsprechend einreihen. Jeder Arbiter 20 und zugeordnete Bus 40 könnten mit einer Teilmenge der Quellen verbunden sein.
Wenden wir uns 6 zu, wo Kopien des zielseitigen Pullbusses 42 und der zugeordneten Arbitrierlogik zu dem System hinzugefügt werden könnten. Jeder Arbiter 22 und Bus 42 wäre mit jedem der Ziele verbunden. Jeder Arbiter 22 und zugeordnete Bus 44 könnte eine Teilmenge der Quellen unterstützen. Die Pullbusanordnung würde insofern der Pushbusanordnung ähneln, als jedes Ziel nur eine einzige Kopie der Pull-ID zu allen Arbitern zu übermitteln brauchte. Es werden jedoch einmalige Kopien der Pulldaten benötigt, da es möglich ist, dass an den Pullbussen während desselben Zyklus' gültige Daten anliegen. Im Fall von sowohl Push- als auch Pullbussen wären alle Arbiter mit allen Zielen verbunden, wodurch Daten zwischen jedem Master und jedem Ziel bewegt werden könnten.
Es liegen noch weitere Ausführungsformen innerhalb des Geltungsbereichs der folgenden Ansprüche.

Claims

Verfahren zum Bereitstellen einer flexiblen Bandbreitenzuteilung über mehrere Instanziierungen separater Busse, wobei das Verfahren Folgendes umfasst: Übermitteln eines Befehls (50), der eine Zielidentifikation (52a) enthält, zwischen einem oder mehreren Busmastern (12) und Buszielen (14) über eine Busstruktur (18), wobei der Befehl Informationen enthält, die durch eines der Busziele anhand der Zielidentifikation unterschiedlich interpretiert werden, dadurch gekennzeichnet, dass die Busstruktur (18) Folgendes enthält: einen separaten Befehlsbus (30), Pushbus (32), Pullbus (34), und Arbiter (19, 20, 22), die Folgendes enthalten: einen Befehlsarbiter (19), der dem Befehlsbus (30) zugeordnet ist, wobei die Busmaster (12) den Befehlsarbiter (19) dafür verwenden, um für eine Nutzung des Befehlsbusses (30) zu arbitrieren; einen Pusharbiter (20), der dem Pushbus (32) zugeordnet ist, und einen Pullarbiter (22), der dem Pullbus (34) zugeordnet ist, wobei die Busziele (14) den Pusharbiter (20) und den Pullarbiter (22) verwenden, um den Pushbus (32) bzw. den Pullbus (34) zu verwenden.
Verfahren nach Anspruch 1, wobei die Zielidentifikation (52a) ein Feld in dem Befehl (50) ist.
Verfahren nach Anspruch 1, wobei das Übermitteln enthält, den Befehl (50) an alle Busziele (14) über den Befehlsbus (30) zu senden, so dass jedes Busziel feststellen kann, ob der Befehl für das betreffende Ziel gedacht ist.
Verfahren nach Anspruch 1, wobei das in dem Befehl (50) identifizierte Busziel (14) die Übermittlung von Informationen über den Pushbus (32) zu einem der Busmaster (12) für eine Pushoperation zu steuern.
Verfahren nach Anspruch 4, wobei der eine der Busmaster (12) in dem Befehl (50) mittels eines Identifikators in einem Bestimmungsortfeld (54) in dem Befehl identifiziert wird.
Verfahren nach Anspruch 1, wobei das in dem Befehl (50) identifizierte Busziel (14) dafür geeignet ist, die Übermittlung von Informationen über den Pullbus (34) von einem der Busmaster (12) zu dem Busziel (14) für eine Pulloperation zu steuern.
Verfahren nach Anspruch 6, wobei der eine der Busmaster (12) in dem Befehl (50) durch einen Identifikator in einem Quellenfeld (54) in dem Befehl identifiziert wird.
Verfahren nach Anspruch 1, wobei der Befehl (50) so formatiert ist, dass er eine von mehreren Operationsarten spezifiziert, und der Befehl wenigstens ein Feld enthält, das entsprechend der einen der mehreren Operationsarten, die im dem Befehl spezifiziert ist, interpretiert wird.
Verfahren nach Anspruch 1, das mehrere Einheiten (12, 14) umfasst, wobei wenigstens eine der Einheiten einmal als einer der Busmaster (12) fungiert und ein anderes Mal als eines der Busziele (14) fungiert.
Gegenstand zum Bereitstellen einer flexiblen Bandbreitenzuteilung über mehrere Instanziierungen separater Busse, wobei der Gegenstand Folgendes umfasst: ein Speichermedium, auf dem Anweisungen gespeichert sind, die, wenn sie durch eine Maschine ausgeführt werden, Folgendes zum Ergebnis haben: Übermitteln eines Befehls (50) über eine Busstruktur (18) zu Buszielen (14), wobei der Befehl so formatiert ist, dass er eines der Busziele identifiziert und Informationen enthält, die anhand dessen, welches der Busziele identifiziert wird, unterschiedlich interpretiert werden, dadurch gekennzeichnet, dass die Busstruktur (18) Folgendes enthält: einen separaten Befehlsbus (30), Pushbus (32), Pullbus (34), und Arbiter (19, 20, 22), die Folgendes enthalten: einen Befehlsarbiter (19), der dem Befehlsbus (30) zugeordnet ist, wobei ein oder mehrere Busmaster (12) den Befehlsarbiter (19) dafür verwenden, um für eine Nutzung des Befehlsbusses (30) zu arbitrieren; einen Pusharbiter (20), der dem Pushbus (32) zugeordnet ist, und einen Pullarbiter (22), der dem Pullbus (34) zugeordnet ist, wobei die Busziele (14) den Pusharbiter (20) und den Pullarbiter (22) verwenden, um den Pushbus (32) bzw. den Pullbus (34) zu verwenden.
Vorrichtung (10) zum Bereitstellen einer flexiblen Bandbreitenzuteilung über mehrere Instanziierungen se parater Busse, wobei die Vorrichtung Folgendes umfasst: mehrere Einheiten (12, 14); eine Busstruktur (18) zum Ermöglichen eines Kommunikationsaustauschs zwischen den an die Busstruktur angeschlossenen Einheiten, wobei eine oder mehrere der Einheiten Busmaster (12) sind und andere der Einheiten Busziele (14) sind, wobei die Busmaster betreibbar sind, einen Befehl (50) über die Busstruktur an Busziele zu senden, wobei der Befehl so formatiert ist, dass er eines der Busziele identifiziert und Informationen enthält, die anhand dessen, welches der Busziele identifiziert wird, unterschiedlich interpretiert werden, dadurch gekennzeichnet, dass die Busstruktur (18) Folgendes enthält: einen separaten Befehlsbus (30), Pushbus (32), Pullbus (34), und Arbiter (19, 20, 22), die Folgendes enthalten: einen Befehlsarbiter (19), der dem Befehlsbus (30) zugeordnet ist, wobei die Busmaster (12) den Befehlsarbiter (19) dafür verwenden, um für eine Nutzung des Befehlsbusses (30) zu arbitrieren; einen Pusharbiter (20), der dem Pushbus (32) zugeordnet ist, und einen Pullarbiter (22), der dem Pullbus (34) zugeordnet ist, wobei die Busziele (14) den Pusharbiter und den Pullarbiter (22) verwenden, um den Pushbus (32) bzw. den Pullbus (34) zu verwenden.
Vorrichtung (10) nach Anspruch 11, wobei der Befehl (50) über den Befehlsbus (30) an alle Busziele (14) gesendet wird und jedes Busziel feststellt, ob der Befehl für das betreffende Ziel gedacht ist.
Vorrichtung (10) nach Anspruch 11, wobei das in dem Befehl (50) identifizierte Busziel (14) dafür geeignet ist, die Übermittlung von Informationen über den Pushbus (32) zu einem der Busmaster (12) für eine Pushoperation zu steuern.
Vorrichtung (10) nach Anspruch 13, wobei der eine der Busmaster (12) in dem Befehl (50) mittels eines Identifikators in einem Bestimmungsortfeld (54) in dem Befehl identifiziert wird.
Vorrichtung (10) nach Anspruch 11, wobei das in dem Befehl (50) identifizierte Busziel (14) dafür geeignet ist, die Übermittlung von Informationen über den Pullbus (34) von einem der Busmaster (12) zu dem Busziel für eine Pulloperation zu steuern.
Vorrichtung (10) nach Anspruch 15, wobei der eine der Busmaster (12) in dem Befehl (50) durch einen Identifikator in einem Quellenfeld (54) in dem Befehl identifiziert wird.
Vorrichtung (10) nach Anspruch 11, wobei der Befehl (50) so formatiert ist, dass er eine von mehreren Operationsarten spezifiziert, und der Befehl wenigstens ein Feld enthält, das entsprechend der einen der mehreren Operationsarten im dem Befehl interpretiert wird.
Vorrichtung (10) zum Bereitstellen einer flexiblen Bandbreitenzuteilung über mehrere Instanziierungen se parater Busse, wobei die Vorrichtung Folgendes umfasst: einen Busmaster (12), der dafür geeignet ist, einen Befehl (50) über eine Busstruktur (18) an Busziele (14) zu senden, wobei der Befehl (50) so formatiert ist, dass er eines der Busziele identifiziert und Informationen enthält, die anhand dessen, welches der Busziele identifiziert wird, unterschiedlich interpretiert werden, dadurch gekennzeichnet, dass die Busstruktur (18) Folgendes enthält: einen separaten Befehlsbus (30), Pushbus (32), Pullbus (34), und Arbiter (19, 20, 22), die Folgendes enthalten: einen Befehlsarbiter (19), der dem Befehlsbus (30) zugeordnet ist, wobei der Busmaster (12) und mindestens ein weiterer Busmaster den Befehlsarbiter (19) dafür verwenden, um für eine Nutzung des Befehlsbusses (30) zu arbitrieren; einen Pusharbiter (20), der dem Pushbus (32) zugeordnet ist, und einen Pullarbiter (22), der dem Pullbus (34) zugeordnet ist, wobei die Busziele (14) den Pusharbiter (20) und den Pullarbiter (22) verwenden, um den Pushbus (32) bzw. den Pullbus (34) zu verwenden.
Vorrichtung (10) nach Anspruch 18, wobei der Befehl (50) so formatiert ist, dass er eine von mehreren Operationsarten spezifiziert, und der Befehl wenigstens ein Feld enthält, das entsprechend der einen der mehreren Operationsarten, die im dem Befehl spezifiziert ist, interpretiert wird.
Vorrichtung (10) zum Bereitstellen einer flexiblen Bandbreitenzuteilung über mehrere Instanziierungen separater Busse, wobei die Vorrichtung Folgendes umfasst: ein Busziel (14), das dafür geeignet ist, einen Befehl (50) von einem Busmaster (12) über eine Busstruktur (18) zu empfangen, wobei der Befehl so formatiert ist, dass er das Busziel, das den Befehl empfängt, identifiziert; und eine Logik in dem Busziel zum Interpretieren von Informationen, die von dem identifizierten Busziel empfangen werden, wobei die Logik in dem Busziel die Informationen anders interpretiert als eine entsprechende Logik in einem anderen Busziel, das an die Busstruktur angeschlossen ist, dadurch gekennzeichnet, dass die Busstruktur (18) Folgendes enthält: einen separaten Befehlsbus (30), Pushbus (32), Pullbus (34), und Arbiter (19, 20, 22), die Folgendes enthalten: einen Befehlsarbiter (19), der dem Befehlsbus (30) zugeordnet ist, wobei der Busmaster (12) und mindestens ein weiterer Busmaster, die an die Busstruktur angeschlossen sind, den Befehlsarbiter (19) dafür verwenden, um für eine Nutzung des Befehlsbusses (30) zu arbitrieren; und einen Pusharbiter (20), der dem Pushbus (32) zugeordnet ist, und einen Pullarbiter (22), der dem Pullbus (34) zugeordnet ist, wobei das Busziel (14) und mindestens ein weiteres Busziel, die an die Busstruktur angeschlossen sind, den Pusharbiter (20) und den Pullarbiter (22) verwenden, um den Pushbus (32) bzw. den Pullbus (34) zu verwenden.
Vorrichtung (10) nach Anspruch 20, wobei eine Logik den Befehl (50) verarbeitet, der so formatiert ist, dass er eine von mehreren Operationsarten spezifiziert, und der Befehl wenigstens ein Feld enthält, das entsprechend der einen der mehreren Operationsarten, die im dem Befehl spezifiziert ist, interpretiert wird.