DE69709078T2

DE69709078T2 - Verwaltungssystem zur datenverarbeitung

Info

Publication number: DE69709078T2
Application number: DE69709078T
Authority: DE
Inventors: Paul Rowland; Robert Whittaker
Original assignee: Imagination Technologies Ltd
Current assignee: Imagination Technologies Ltd
Priority date: 1996-04-04
Filing date: 1997-04-04
Publication date: 2002-10-31
Anticipated expiration: 2017-04-05
Also published as: GB9607153D0; GB2311882A; ES2171919T3; JP3559046B2; DE69709078D1; JP2000509528A; US5968167A; WO1997038372A1; EP0891588B1; EP0891588A1; GB2311882B

Description

Die vorliegende Erfindung betrifft ein Datenverarbeitungsmanagementsystem des Typs, der mit Echtzeit- Multimediaeingaben und -verarbeitung verwendet werden kann.

HTNTERGRUND DER ERFINDUNG

Die Benutzerschnittstelle mit Computern wurde kontinuierlich weiterentwickelt, von Fernschreibtastaturen zu Tastatur- und Zeichenendgeräten bis hin zur (grafischen Benutzeroberfläche) GUI, die zur Zeit für die Mehrzahl von Computerbenutzern die Standardschnittstelle ist. Fortgesetzt wird diese Entwicklung mit Sound und 3D-Grafik, die immer alltäglicher werden, und dem Aufkommen von 3D-Sound und virtueller Realität. Ihnen gemeinsam ist eine größere Komplexität der Mensch-Computer-Schnittstelle, die durch eine damit einhergehende Zunahme der dem Benutzer präsentierten Datentypen erreicht wird. PC-(Personal Computer)-Anwendungen nutzen diese Verschiebung aus und verlassen sich in zunehmendem Maße auf die Verfügbarkeit von Sound und 3D-Grafik zum Erreichen ihres vollen Potentials.
Das hat dazu geführt, dass Chip- und Platinenhersteller Produkte mit kombinierter Funktionalität zum Bearbeiten von mehr als einem Datentyp anbieten, z. B. 2-D-Grafik und Sound oder 2-D- und MPEG-(Motion Picture Experts Gtoup)-Wiedergabe. Es ist wichtig, zu beachten, dass diese Produkte bisher für jeden Datentyp separate Funktionseinheiten benutzen.
In jüngerer Zeit sind programmierbare SIMD-Architekturen (SIMD - Single Instruction Multiple Data: Datenverarbeitung mit singulärem Befehls- und parallelem Datenstrang) (z. B. Chromatics MPACT) aufgekommen. Diese Architekturen verwenden identische Verarbeitungselemente, die den gleichen Befehl zum parallelen Durchführen der gleichen Verarbeitung an einer Anzahl von Datenblöcken ausführen. Dieser Ansatz funktioniert gut mit Daten, die leicht partitioniert werden können, um die Durchführung einer gemeinsamen Funktion zuzulassen, z. B. Blockverarbeitung bei Datenkomprimierung wie MPEG, aber nicht flexibel genug sind, um einen kompletten allgemeinen Algorithmus auszuführen, was oftmals konditionelle Flussregelung innerhalb der Datenverarbeitung erfordert.
DSP-Anbieter (DSP: Digitaler Signalprozessor) haben auch versucht, diesen Markt mit MIMD-Geräten (MIMD: Multiple Instruction Multiple Data - parallele Verarbeitung, bei der mehrere Prozessoren gleichzeitig Befehle ausführen und auf Daten operieren) (z. B. TI320C80 von Texas Instruments) anzusprechen, die die erforderliche Flexibilität zum Verarbeiten der verschiedenen Datentypen bieten. Da die Architektur Universal-DSP-Kerne nachbildet, die einen weit größeren Grad an Flexibilität beibehalten, als für die Anwendung erforderlich ist, ist der resultierende Chip ein kostspieliger Baustein, der für allgemeine PC- und Verbraucherzwecke zu teuer ist.
CPU-(Zentraleinheit)-Anbieter, die mit schnellen RISC-CPU für Universalprogramme und die Multimediaverarbeitung werben, können (und wollen) ihre Architektur nicht gefährden, um mehr als nur einige multimediaspezifischen Befehle zu unterstützen, und erreichen daher nicht die erforderlichen Leistungspegel zu angemessenen Kosten. Da die CPU typischenfalls auch für den Betrieb eines Nicht-Echtzeit-Betriebssystems verwendet wird, kann sie auch keine Verarbeitung mit geringer Latenz erbringen.
Dedizierte Multimedia-CPU (z. B. Trimedia von Philips), die mehrere Verarbeitungseinheiten steuernde VLIW-(Very Long Instruction Words)-Befehle verwenden, können ihre Verarbeitungsleistung nicht effizient ausschöpfen, weil jeder Befehl für ein einziges Task (und einen einzigen Datentyp) dediziert ist, und sind daher nicht in der Lage, alle verfügbaren Verarbeitungseinheiten optimal zu nutzen. Beispielsweise kann ein für eine 3D-Grafik-Operation dedizierter VLIW-Befehl für MPEG-Bewegungserkennung (Motion Estimation) bestimmte Hardware nicht vorteilhaft nutzen. Die Anzahl von Verarbeitungseinheiten und somit die Skalierbarkeit wird durch die VLIW-Wortlänge ebenfalls begrenzt.
US 5.487.153-A legt ein SIMD-System offen. Da jede Verarbeitungseinheit den gleichen Prozess durchführen soll, ist das System davon abhängig, dass Dateneingabe für jede Verarbeitungseinheit verfügbar ist, um die Verarbeitung durchzuführen. Wenn keine Daten zur Verfügung stehen, hört die Ausführung auf.

ZUSAMMENFASSUNG DER ERFINDUNG

Bevorzugte Ausgestaltungen der vorliegenden Erfindung beziehen sich auf den Bedarf für eine Vorrichtung, die alle Multimediadatentypen auf eine Weise verarbeitet, die Systemkosten minimiert und künftige Entwicklungen in Multimedia- und den verwandten Industrienormen berücksichtigt. Sie sehen eine Architektur vor, die hinsichtlich Verarbeitungsleistung, Echtzeit-Ein-/Ausgabe-Unterstützung und bezüglich der Anzahl gleichzeitig durchführbarer Aktivitäten skalierbar ist.
Alle Multimediadatentypen können als Datenströme betrachtet werden, die sich für einen Vektorverarbeitungsansatz anbieten. Einige dieser Ströme sind in Echtzeit (z. B. von einem Audio- oder Videoeingang) und benötigen als solche entweder dedizierte Pufferung oder Verarbeitung mit geringer Latenz zum Vermeiden von Datenverlust. Jeder Datenstrom erfordert auch eine Hardware- Ressource, so dass er verarbeitet werden kann.
Eine bevorzugte Ausgestaltung der Erfindung hat einen Echtzeit-Verarbeitungskern geringer Latenz, der nur für Daten- Ein-/-Ausgabe und Task-Scheduling zuständig ist. Das vermeidet die Notwendigkeit unnötiger und kostspieliger Pufferung. Außerdem beinhaltet sie ein Verfähren der dynamischen Ressourcenprüfung, um sicherzustellen, dass nur Tasks laufen, für die die erforderlichen Ressourcen verfügbar sind.
Das Gleichgewicht zwischen Hostverarbeitungsleistung, Speicherkosten und Siliziumkosten ändert sich auch ständig. Das bedeutet, dass die optimale Arbeitsteilung zwischen einem Hostprozessor und einem Multimedia-Coprozessor sich mit der Zeit ebenfalls ändert. Diese Vorrichtung ist programmierbar, damit die Arbeitsteilung nach Bedarf geändert werden kann.
Die Skalierbarkeit paralleler Verarbeitungsvorrichtungen ist ein Problem für Hardware-Design und unterstützende Software. Wenn mehr Verarbeitungseinheiten zu einer Vorrichtung hinzugefügt werden, wird die Taskaufteilung zwischen den Verarbeitungseinheiten schwieriger, was entweder zu abnehmenden Umsatz oder zu einem exponentiellen Wachstum der Anzahl von Verbindungen zwischen Funktionseinheiten führt. Derartige Änderungen resultieren meist auch in Änderungen am Programmierungsmodell für die Vorrichtung, die grundlegende Änderungen an der unterstützenden Software erfordern.
Bevorzugte Ausgestaltungen der Erfindung behandeln diese Probleme mit einer einheitlichen skalierbaren Architektur, bei der alle Elemente skaliert werden können, ohne eine explosionsartige Zunahme der Verbindungen zwischen Funktionseinheiten zu schaffen und ohne das für die Softwareverbindung mit der Vorrichtung präsentierte Programmierungsmodell zu ändern.
Fig. 1 zeigt die Grundarchitektur der Vorrichtung.
Die Vorrichtung wurde als eine umkonfigurierbare Maschine konzipiert, passend für alle derzeiten und zukünftigen, zum Verarbeiten von Multimediadaten erforderlichen Algorithmen. Die von ihr geleistete Arbeit ist in zwei Kategorien aufgeteilt. Ein Multimediasteuerungskern (Media Control Core) führt sowohl Echtzeit-Scheduling als auch Ein-/Ausgabeverarbeitung durch, während die rechnungsintensive Datenverarbeitung von einer oder mehr zusätzlichen Datenverarbeitungseinheiten durchgeführt wird.
Diese Arbeitsteilung ist eine der grundlegenden Charakteristiken der Architektur.
Die Datenverarbeitung besteht aus einer Anzahl von Schritten:
Parameterabruf und Parametrierung
Datenabruf und -verarbeitung
Datenspeicherung
Um einen hohen Datenverarbeitungsdurchsatz effizient zu erzielen, muss ein Prozessor die obigen Vorgänge an einem angemessen großen Datensatz durchführen. Wenn der Datensatz zu klein ist, verwendet der Prozessor einen zu großen Anteil seiner Leistung auf kontextbezogenes Multitasking zwischen Tasks und der resultierenden Notwendigkeit, den Zustand eines Threads zu sichern und umzuspeichern.
Da der Multimediasteuerungskern nur für Anfragen zum Transferieren von Daten zwischen E/A-Ports und Speicher (damit die Datenverarbeitung durchgeführt werden kann) erforderlich ist, kann er zwischen jedem Taktzyklus kontextbezogenen zwischen Tasks umschalten, das beseitigt dann die Notwendigkeit großer Datenpuffer zum Unterstützen von Echtzeit-Ein-/Ausgabe. Datenverarbeitungseinheiten können Daten effizient verarbeiten, indem sie einen wesentlichen Teil eines Algorithmus an Daten ohne Unterbrechung durchführen.
Diese Verarbeitungselemente werden von einem skalierbaren Cache mit mehreren Datenbanken unterstützt, der durch Cache- Speichern von Datensätzen, die für die aktiven ausgeführten Algorithmen benötigt werden, effizienten Datentransfer und effiziente Datenverarbeitung unterstützt.
Die Erfindung wird in den anhängigen Ansprüchen, auf die jetzt Bezug zu nehmen ist, in ihren verschiedenen Aspekten ausführlicher definiert.
Im Folgenden wird eine bevorzugte Ausgestaltung der Erfindung unter Bezugnahme auf die Figuren beispielhaft im Detail beschrieben. Dabei zeigt:
Fig. 1 ein Blockdiagramm einer Ausgestaltung der Erfindung;
Fig. 2 ein Blockdiagramm des Multimediasteuerungskerns von Fig. 1;
Fig. 3 ein Blockdiagramm einer zweiten Ausgestaltung der Erfindung;
Fig. 4 ein Blockdiagramm der Steuerwerkbefehls-Pipeline des Multimediasteuerungskerns;
Fig. 5 ein Blockdiagramm der Innenarchitektur einer der Datenbanken in Fig. 4;
Fig. 6 eine Darstellung in Blockform, wie die Ressourcenprüfung und somit die Prozessauswahl vom Multimediasteuerungskern durchgeführt wird, und
Fig. 7 ein Blockdiagramm, das zeigt, wie der Zugang zum Banken-Cache-Speicher in Fig. 1 erfolgt.
Die Grundarchitektur der Ausgestaltung der Erfindung wird in Fig. 1 gezeigt. Den Mittelpunkt des Systems bildet ein Multimediasteuerungskern (MCC - Media Control Core) 2. Dieser ist ein fein strukturierter Multithreading-Prozessor. Dieser hat eine Mehrzahl von Eingaben und Ausgaben, die an Echtzeit- Dateneingabe- und -ausgabegeräte 4 gekoppelt werden können. Dabei kann es sich z. B. um Videoquellen, Audioquellen, Videoausgänge, Audioausgänge, Datenquellen, Speichergeräte usw. handeln. In einem einfachen Beispiel würden nur eine Eingabe und eine Ausgabe vorgesehen.
An den Multimediasteuerungskern 2 ist auch eine Mehrzahl von Datenverarbeitungseinheiten 6 gekoppelt. Diese weisen jeweils einen Datenverarbeitungskern 8 auf, der die Verarbeitung von Daten über die Daten-Pipeline 10 steuert. Der Kern 8 decodiert und ordnet Mikrobefehle sequentiell für die Pipeline 10.
Ebenfalls mit dem Multimediasteuerungskern 2 gekoppelt ist ein Cache-Speicher mit mehreren Banken, aus dem von Multimediasteuerungskern 2 und Datenverarbeitungseinheiten 6 Daten abgerufen werden können und in die vom Multimediasteuerungskern 2, von den Datenverarbeitungseinheiten 6 Daten geschrieben werden können.
Der Multimediasteuerungskern ist eine fein strukturierte Multithreading-Verarbeitungseinheit, die Daten von Eingaben zu Datenverarbeitungskernen oder zum Speicher leitet und Daten an Ausgaben liefert. Er ist so angeordnet, dass er bei jedem Taktzyklus kontextbezogen zwischen Tasks umschalten kann. Das wird dadurch erzielt, dass bei jedem Taktzyklus geprüft wird, für welche der möglichen Operationen, die er durchführen könnte, alle Ressourcen verfügbar sind, um jene Tasks durchzuführen, und welcher von diesen die höchste Priorität hat. Wenn ausreichend Verarbeitungsleistung bereitgestellt wäre, könnte er zum Beginnen des Ablaufs von mehr als einer Operation bei jedem Taktzyklus angeordnet werden.
Diese Ressourcenprüfung gewährleistet, dass alles vorliegt, was zum Durchführen eines bestimmten Task erforderlich ist. Dazu gehören externe Ressourcen, wie z. B. ob Daten an einem Eingabeport (z. B. Videodaten) verfügbar sind oder ob ein Datenspeichergerät oder eine Ausgabe verfügbar ist. Außerdem gehören dazu interne Ressourcen, wie Datenbanken für Zwischenspeicherung, verfügbare Verarbeitungskerne, die zur Zeit nicht an anderen Daten arbeiten, oder zuvor verarbeitete Daten, die für eine bestimmte neue Verarbeitungsoperation benötigt werden. Der Multimediasteuerungskern hat die Aufgabe, Daten von einer Eingabe zu einer geeigneten Datenverarbeitungseinheit 6 zu lenken, damit die Verarbeitung stattfinden kann, und leitet Daten bei Bedarf zu einer Ausgabe, wobei er erforderlichenfalls den Cache nutzt. Wenn die Ausführung eines Befehlssatzes an einer Verarbeitungseinheit begonnen hat, kann der MCC die verschiedenen Threads, die er ausführen kann, und die dafür verfügbaren Ressourcen erneut betrachten, während das Programm auf der Datenverarbeitungseinheit weiterhin ausgeführt wird.
Die Ressourcen- und Prioritätsprüfung des Multimediasteuerungskerns bedeutet, dass Tasks, die als Echtzeitdaten dienen, wie z. B. Videoeingabe, ohne die großen Speicherpuffer durchgeführt werden können, die bei aktuellen Echtzeiteingaben gewöhnlich benötigt werden. Bei Operationen wie z. B. Videoeingabe prüft der Multimediasteuerungskern nach, ob Daten am Ein-/Ausgabeport verfügbar sind, und, wenn dies der Fall ist, empfängt er diese Daten und sendet sie entweder zu einem Teil des Mehrbanken-Caches oder zu Datenspeicherregistern in Vorbereitung auf die Verarbeitung durch eine der Datenverarbeitungseinheiten 6.
Die Datenverarbeitungseinheiten 6 sind alle unter der Kontrolle und dem Scheduling des Multimediasteuerungskerns 2. In dem in Fig. 1 gezeigten Beispiel bestehen die Einheiten aus einer Verarbeitungs-Pipeline (Daten-Pipeline 10), die sich aus einer Anzahl von Verarbeitungsgliedern zusammensetzt, wie Multiplikatoren, Addierer, Verschieber usw. unter der Kontrolle eines assoziierten Datenverarbeitungskerns 8, der eine Befehlsfolge zum Durchführen eines Datenverarbeitungsalgorithmus ausführt. Jeder dieser Datenverarbeitungskerne hat seine eigenen Mikrobefehls-ROM- und/oder -RAM-Speicherbefehlsfolgen zum Durchführen bestimmter Datenprozesse. Der Multimediasteuerungskern ruft die Datenverarbeitungseinheit 6 zum Durchführen ihrer bestimmten Ablauffolge auf, z. B. indem er ein Adressen-Offset in ihren Mikrobefehls-ROM überträgt und sie anweist, mit der Ausführung zu beginnen. Sie führt dann einen bestimmten Prozess an Daten aus Mehrbanken-Cache oder an Daten, die von einer der Eingaben zum Multimediasteuerungskern an ihm weitergeleitet wurden, durch, bis er beendet ist, dann sendet sie ein Signal an den Multimediasteuerungskern, dass ihre Verarbeitung abgeschlossen ist.
Der Mehrbanken-Cache 12 von Fig. 1 wird für Speicherzugriffe verwendet, und diese werden alle durch diese Bank hindurch Cache-gespeichert. Der Cache ist in eine Mehrzahl von Banken 14 unterteilt, die jeweils programmiert werden können, so dass sie mit den Anforderungen eines der durchgeführten Datenverarbeitungstasks übereinstimmen. Beispielsweise könnte eine Cache-Bank für das Caching von Struktur-Maps aus dem Hauptspeicher zur Verwendung bei 3D- Grafik-Rendering dediziert sein. Die Verwendung dieser Programmierbarkeit der Cache-Banken erlaubt die bestmögliche Verwendung eines Chipspeichers und ermöglicht die Durchführung von dynamischer Cache-Allozierung, wodurch die jeweils beste Leistung unter den betreffenden Bedingungen erzielt wird.
Darüber hinaus lässt es die Verwendung von mehreren Cache- Banken zu, dass der Cache nichtblockierend ist. Das heißt, wenn eine der Cache-Banken eine Anforderung behandelt, die sie gegenwärtig nicht erfüllen kann, wie z. B. einen Lesebefehl, wenn diese Daten gegenwärtig nicht verfügbar sind, dann kann ein anderer Verarbeitungs-Thread, der eine separate Cache-Bank benutzt, ausgeführt werden.
Die gesamte Vorrichtung, wie in Fig. 1 gezeigt, ist skalierbar und kann auf einem einzigen Siliziumplättchen als eine integrierte Schaltung konstruiert werden. Der Multimediasteuerungskern 1 ist auf eine Weise skalierbar, die unter Bezugnahme auf Fig. 2 im Folgenden beschrieben wird. Wenn der Multimediasteuerungskern vergrößert wird, kann er weitere Datenverarbeitungseinheiten 6 unterstützen, während er das gleiche Programmiermodell für die Multimediasteuerung verwendet. Es können auch mehr Cache-Banken zur Unterstützung der weiteren Datenverarbeitungseinheiten hinzugefügt werden, wodurch die Effektivität des Datendurchsatzes zum Multimediasteuerungskern und den Datenverarbeitungseinheiten erhöht wird. Weil das Programmiermodell der Vorrichtung nicht verändert wird, kann dadurch ein hoher Grad an Abwärtskompatibilität erreicht werden.
Der Multimediasteuerungskern wird in Fig. 2 detaillierter gezeigt. Er setzt sich zusammen aus einem Steuerwerk 16, einem Satz von Lese-/Schreibeinheiten 18, einem Satz von Programmzählerbanken 20, einem Satz von Adressenbanken 22, einem Satz von Datenbanken 24 und einem Satz von Ein-/Ausgabe- Banken 26. Diese Banken sind von einem Multimediasteuerungskern-Statusbus 28, einem Multimediasteuerungskern-Steuerbus 29 und einer Multimediasteuerungskern-Datenverbindung 30 miteinander gekoppelt. Die Multimediasteuerungskern-Datenverbindung dient zum Senden von Daten zwischen den diversen verschiedenen Banken und der Statusbus stellt Daten wie den Ein-/Ausgabeportstatus und den Status von Datenverarbeitungseinheiten, zu denen der Multimediassteuerungskern Befehle und Daten senden kann, bereit.
Außerdem ist ein Speicherblock 32, der Mikrocode-Befehle in ROM und RAM speichert, mit dem Steuerwerk 16 der oben aufgeführten Einheiten 18 bis 26 gekoppelt.
Alle Kernkomponenten, 18 bis 26, mit Ausnahme des Steuerwerks haben das gleiche grundlegende Schnittstellenmodell, welches das Lesen von Daten aus ihnen, das Schreiben in sie hinein und das Durchführen von Operationen zwischen in ihnen gespeicherten Daten erlaubt. Jede Bank besteht aus einer fest gekoppelten Lokalspeicher- Registerdatei mit einer Verarbeitungseinheit oder einer arithmetisch-logischen Einheit (ALU).
Das Steuerwerk (16) dient zum Steuern der Ausführung des Multimediasteuerungskerns. Bei jedem Taktzyklus prüft es die Verfügbarkeit aller Ressourcen (z. B. Ein-/Ausgabeportstatus, Status der Datenverarbeitungseinheiten usw.) unter Verwendung von vom Multimediasteuerungs-Statusbus 28 bereitgestellten Statusinformationen im Vergleich mit den zum Ausführen jedes Programms unter seiner Kontrolle benötigten Ressourcen. Dann startet es die Ausführung des Befehls für den Programm-Thread der höchsten Priorität, dessen Ressourcen alle verfügbar sind.
Die Programmzählerbank dient zum Speichern von Programmzählern für jeden Verarbeitungs-Thread, der vom Multimediasteuerungskern unterstützt wird. Sie besteht aus einem Register für jeden der Verarbeitungs-Threads, welche der Multimediasteuerungskern unterstützen kann, und eine ALU, die alle Operationen auf den Programmzählern für Programmprogression, Schleifendurchlauf, Verzweigungen usw. durchführt. Die Datenbanken 24 werden für allgemeine Operationen an Daten zum Steuern des Programmablaufs innerhalb des Multimediasteuerungskerns verwendet. Sie sind eine allgemeine Ressource, die von jedwedem Verarbeitungs-Thread, der im MCC ausgeführt wird, nach Bedarf verwendet werden kann.
Die Adressenbanken 22 dienen zum Speichern und Manipulieren von Adressen für Befehle und für Daten und sind ebenfalls eine allgemeine MCC-Ressource, ähnlich wie die Datenbanken 24.
Die Ein-/Ausgabebanken 26 bilden eine Schnittstelle zwischen dem Multimediasteuerungskern und den Echtzeitdatenströmen für Ein-/Ausgabe, die vom MCC unterstützt werden. Ihr Status zeigt die Verfügbarkeit von Daten an einem Port, z. B. Videoeingang, an oder die Fähigkeit eines Ports zum Bewältigen der auszugebenden Daten. Sie können wahlweise auch die Fähigkeit haben, Daten beim Hinein- oder Herausübertragen umzuwandeln, z. B. Bitstopfen eines Datenstroms.
Die Lese-/Schreibbanken 18 bilden eine Schnittstelle zwischen Multimediasteuerungskern und Speicher (über den Mehrbanken-Cache). Da zu jedem beliebigen Zeitpunkt mehr als ein Verarbeitungs-Thread ausgeführt werden kann, ist mehr als eine Lese-/Schreibeinheit erforderlich, um das Blockieren von Speicheranfragen zu vermeiden.
Der Multimediasteuerungskern ist bezüglich aller wichtigen Aspekte skalierbar. Da er aus Banken aufgebaut ist, die Speicher (Registerdateien) und Verarbeitung (ALU) lokalisieren, können zusätzliche Banken hinzugefügt werden, ohne irgendwelche nicht zu bewältigende Leit- und Verbindungsprobleme aufzuwerfen. Die Anzahl der Verarbeitungs- Threads, die unterstützt werden könnten, kann durch Hinzufügen von Registern zur Programmzählerbank und entsprechendes Modifizieren des Steuerwerks erhöht werden. Die Anzahl von Ein-/Ausgabeströmen, die vom MCC unterstützt werden können, kann durch Hinzufügen weiterer Ein-/Ausgabebanken erhöht werden.
Der Datendurchsatz kann durch Hinzufügen weiterer Lese- /Schreibeinheiten 18 vergrößert werden, und die MCC- Verarbeitungsleistung insgesamt kann durch Hinzufügen weiterer Daten- und Adressenbanken 24, 22 gesteigert werden.
In Fig. 3 wird ein Blockdiagramm einer spezifischen Implementierung des Datenverarbeitungsmanagementsystems gezeigt. Der MCC dient in diesem als eine Mehrzahl von Echtzeit-Datenein-/-ausgabeports und steuert Datenverarbeitungseinheiten zum Verarbeiten von von ihnen erhaltenen und an sie ausgegebenen Daten.
In der Figur wird ein Videoeingang 34 und ein Audioeingang 36 gezeigt, die über assoziierte Präprozessoren 38 und 40 mit dem Multimediasteuerungskern gekoppelt sind. Ein entsprechender Videoausgang 42 und Audioausgang 44 sind über Postprozessoren 46 beziehungsweise 48 mit dem Multimediasteuerungskern 2 gekoppelt. Die Video- und Audioein- und -ausgänge können digitale Ein- und Ausgänge sein.
Wie in Fig. 1 ist der Multimediasteuerungskern 2 mit einem mehrere Banken umfassenden Cache 12 gekoppelt, der in diesem Fall die Haupt-Cache-Bank genannt wird. Eine Datenverarbeitungseinheit 6, die einen sekundären Kern 8 und eine Daten-(Media-)Pipeline 10 aufweist, sind direkt mit dem Multimediasteuerungskern gekoppelt und werden zum Verarbeiten von ihnen zugeführten Daten verwendet.
Mit dem Multimediakern 2 ist auch eine Verarbeitungseinheit 50 verbunden, die einen Digital-Analog- Wandler-Speisungskern (DAC-Speisungskern) 52 und eine DAC- Speisungspipeline 54 aufweist, welche Daten an einen Digital- Analog-Wandler 56 liefert. Zweck dessen ist die Erzeugung einer Grafikausgabe. Zu diesem Zweck ruft die Verarbeitungseinheit 50 Daten über die Frame-Pufferschnittstelle 58 ab, und Systembus 60 für den Hostcomputer-Video-Adapter (VGA - Video Graphics Adapter) wird nur für Kompatibilität beibehalten. Somit werden Echtzeitdaten an den Video- und Audioeingängen eingespeist und können an den Video- und Audioausgängen ausgesendet werden, während die Grafikausgabe vom DAC 56 gesendet werden kann.
Daten für die Grafikausgabe können durch Verarbeiten von Nicht-Echtzeitdaten von einer Quelle wie einem Grafik-Frame- Speicher erzeugt werden, zu dem eine Verbindung über die Frame-Pufferschnittstelle 58, 3D-Daten oder Echtzeit-Video in Fig. 3 gezeigt wird.
Der sekundäre Kern 8 und die Mediapipeline 10 ist ein Beispiel einer Datenverarbeitungseinheit, die Audio, 3D, 2D, Videoskalierung, Video-Decodierung usw. verarbeiten kann. Diese könnte aus jedem Typ von allgemeinem Prozessor gebildet werden.
Der DAC-Speisungskern und die DAC-Speisungspipeline ist für die Verarbeitung von Daten aus einer Anzahl von Frame- Puffern zur Erzeugen von RGB-Daten für einen DAC dediziert. Er kann pixelweise zwischen Quellenpuffern umschalten, wodurch aus einer Anzahl von Videoformaten wie YUV entnommene Daten konvertiert und Quellendaten aus mehreren Frame-Puffern durch Mischen oder Farb- oder Chroma-Einblendung kombiniert werden.
Jeder Kern hat einen assoziierten Mikrocodespeicher, der von ROM und RAM gebildet wird, die zum Zweck der Deutlichkeit hier nicht abgebildet sind, aber vom Prozessor auszuführende Befehle speichert. Die Cache-Banken 12 haben Schnittstellen mit dem Multimediasteuerungskern und den Datenverarbeitungseinheiten 6 und 50. Außerdem sind sie über eine Adressenumsetzungseinheit 64 mit dem Systembus verbunden. Außerdem sind sie mit der Frame-Pufferschnittstelle 58 verbunden zum Schreiben von Daten in einen oder mehr Frame- Puffer und zum Lesen von Daten aus einem oder mehr Frame- Puffern.
Eine Datenbank 24 ist in Fig. 5 abgebildet. Sie umfasst eine Registerdatei 72, eine ALU 74 und eine multiplexierte Eingabe 76. Der Betrieb der Datenbank wird von einer Anzahl von Bits in einem Mikrobefehl kontrolliert, die mit WE, W, R1 und R2 gekennzeichnet sind und die in die Registerdatei eingegeben werden. Das Ergebnis des Mikrobefehls, der von der ALU ausgeführt wird, wird als Statusbits H S Z verfügbar gemacht, die zum Steuerwerk des Multimediasteuerungskerns geleitet werden, um Verzweigungen und bedingte Befehle zu implementieren.
Die Registerdatei ist konstruiert, damit bei jedem Taktzyklus zwei Operanden von der Eingabe abgerufen werden können und ein Operand zur Ausgabe geschrieben werden kann. Der Dateneingabeport 78 und der Datenausgabeport 80 erlauben die Kommunikation mit anderen Daten über den Multimediasteuerungskern-Datenbus 30, mit dem sie verbunden sind. Der Datenfluss in Fig. 5 verläuft somit vertikal nach unten durch das Diagramm, während der Fluss der Steuerinformationen von links nach rechts ist, wobei er aus Steuerbits vom Steuerwerk und an das Steuerwerk zurückgesendeten Statusbits, die den Status der Datenbank reflektieren, gebildet ist.
Eine Mehrzahl dieser Datenbanken werden verwendet, und jede hat die gleiche Form, d. h. jede hat ihre eigene Registerdatei, die fest an eine ALU gekoppelt ist, wie in Fig. 5 gezeigt. Diese Anordnung unter Verwendung einer Mehrzahl von fest gekoppelten Registern und ALUs, vorzugsweise in einer Eins-zu-Eins-Beziehung, unterscheidet sich von Ausgestaltungen von Mehrfach-ALUs vom Stand der Technik, bei denen komplexes Multiplexieren zwischen Registerbanken und Mehrfach-ALUs erforderlich ist.
Allgemein führen diese Datenbanken Mehrzweckoperationen an Daten durch, wodurch sie den Programmablauf innerhalb des MCC steuern, und können von jedwedem Verarbeitungs-Thread, der im MCC ausgeführt wird, verwendet werden.
Die Adressenbanken 22, die Programmzählerbanken 20 und die E/A-Banken 26 und die Lese-/Schreibeinheiten 18 sind sich in Aufbau und Betrieb alle ähnlich, sind aber in separaten Einheiten angeordnet, damit ihre Implementierung optimiert werden kann, wodurch die Art und Weise reflektiert wird, auf welche sie benutzt werden.
Die Adressenbanken speichern und manipulieren Adressen für Datenzugriffe in den Speicher (nicht abgebildet). Sie sind insofern etwas einfacher als die Datenbanken, als sie vorzeichenlose Akkumulatoren verwenden und keine Bedingungscodes zum Zurücksenden über den Statusbus an das Steuerwerk T6 erzeugen.
Die Programmzählerbank dient zum Speichern des Programmzählers für jeden Verarbeitungs-Thread, der vom Multimediasteuerungskern unterstützt wird. Die Anzahl der Register in der Bank der in Fig. 5 gezeigten Art entspricht somit der Anzahl von Verarbeitungs-Threads, welche der MCC unterstützen kann. Wie bei den Adressenbanken wird die ALU zum Programmieren von Zähleroperationen verwendet und ist vorzeichenlos. Sie erzeugt keine Bedingungscodes zum Zurücksenden an das Steuerwerk 2.
Die E/A-Banken dienen als Schnittstelle zu E/A-Ports und enthalten weder Register noch ALUs. Sie haben eine Schnittstelle zu vom MCC unterstützten Echtzeitdatenströmen. Ein Statussignal zeigt die Verfügbarkeit von Daten an einem Port an oder die Fähigkeit eines Ports, Daten zu nehmen. Sie können wahlweise die Fähigkeit aufweisen, die Daten bei der Übertragung umzuwandlen.
Die Lese-/Schreibeinheiten haben eine Schnittstelle zur Cache-Bank 12. Sie haben weder Register noch ALUs. Eine Leseeinheit akzeptiert eine Adresse und setzt, wenn die Daten zurückgesendet werden, ein Daten-gültig-Statusbit. Eine Schreibeinheit akzeptiert Adressen und Daten. Mehrere Lese- und Schreibeinheiten werden verwendet, um sicherzustellen, dass, wenn ein Cachezugang blockiert, dann ein anderer Thread durch eine andere Lese-/Schreibeinheit weiter ausgeführt werden kann.
Ein Befehlspuffer mit dem Steuerwerk (nicht abgebildet) für jeden Datenverarbeitungsthread speichert den nächsten Mikrobefehl und die nächsten Befehlsoperanden dieses Threads. Der Befehl und die Operanden beinhalten Bits, welche die Ressourcen beschreiben, die zum Ausführen dieses Befehls erforderlich sind. Dieser Ressourcenbedarf wird zusammen mit Statusbits, die den aktuellen Status des Multimediasteuerungskerns 2, der externen E/A-Ports 20 und der Datenverarbeitungseinheiten 6, 50 beschreiben, in die Ressourcenprüfungslogik des Steuerwerks eingespeist. Einfache Kombinationslogik, wie z. B. ein Array von logischen Gattern, bestimmt, ob ein Befehl ausgeführt werden kann oder nicht, und ein Festprioritätsselektor im Steuerwerk 16 leitet dann den ausführbaren Thread mit der höchsten Priorität in die Datenwegsteuerungspipeline (in Fig. 4 gezeigt) ein, um die Ausführung dieses Programmthreads zu starten. Das Task des Threads könnte "Videodaten überprüfen", "gespeicherte Audiodaten verarbeiten" usw. sein.
Normalerweise fordert ein Befehl an, dass der nächste Befehl seines Threads aus dem Speicher gelesen wird, wenn er ausgeführt wird. Der Befehl wird aus dem Speicher gelesen (Programmzähler zeigt auf ihn), der einen Befehls- Operationscode und Operanden enthält. Das Operationscodefeld des Befehls wird benutzt, um in den Mikrobefehls-ROM zu indizieren, um den nächsten Befehl abzurufen, und der resultierende Mikrobefehl wird zusammen mit den Befehlsoperandenfeldern in den Befehlspuffer des Threads eingespeichert.
Ressourcenprüfung und Priorität werden in Fig. 6 ausführlicher dargestellt. Für die drei illustrierten Threads werden globale Statusinformationen aus den notwendigen Datenbanken, den notwendigen Adressenbanken, Leitsteuerdaten vom Steuerwerk 16 und Ausführungsabhängigkeitsdaten von anderen Prozessen empfangen, von denen ein bestimmter Thread abhängt. Alle diese Informationen werden an einen Ressourcenprüfer 80 gesendet, der sie mit Daten aus E/-Ports, dem Status der verschiedenen Pipelinedatenbanken und dem Status der verschiedenen Datenverarbeitungseinheiten kombiniert. Das geschieht für jeden möglichen Thread. Wenn dieser Datenverarbeitungsthread ausgeführt werden kann, dann wird an einem Prioritätsselektor 82 eine Ausgabe erzeugt. Dieser hat Informationen über die Priorität jedes der unterstützten Datenverarbeitungs-Threads und kann als Folge dessen den Thread mit der höchsten Priorität für die Ausführung auswählen. Beispielsweise würde einer Echtzeitdateneingabe, wie z. B. einem Video, eine hohe Priorität verliehen, und diese würde einer Hintergrund- Verarbeitungsoperation gegenüber Vorrang erhalten.
Da der nächste Befehl für einen Thread bereits in einem Befehlspuffer bereitgestellt ist, ist dieser Befehl immer für die Ressourcenprüfung und die Prioritätsauswahl verfügbar. Somit geht durch das Prüfen des Status jedes Taktzyklus keine Ausführungszeit verloren.
Die in Fig. 4 gezeigte Datenwegsteuerungspipeline funktioniert, indem Felder eines Mikrobefehlswortes auf verschiedenen Tiefen in eine Pipeline gegeben werden dürfen. Das erlaubt es einem Mikrobefehl, den Datenfluss durch die Pipeline über eine Anzahl von Takten hinweg zu steuern und somit die Pipeline-Datenverarbeitung zu steuern.
Die Schaltungsanordnung von Fig. 4 umfasst einen 1-zu-4- Decoder 90, der an seinem Enable-Eingang den Ausgang eines AND-Gatters 92 erhält. Die Eingänge hierzu sind ein Steuerbit vom Mikrocodebefehl und ein Bedingungscode, der für die bedingte Ausführung von Befehlen verwendet wird. Ein Paar Zeitsteuerungsbits vom Mikrocodebefehl sind die Ausgangsauswahleingänge zum Decoder 90. Die vier Ausgänge des Decoders 90 bilden Eingänge über ODER-Gatter 94 zu vier Verzögerungsgliedern 96, die als ein Schieberegister angeordnet sind. Die Ausgänge vom Decoder 90 sind in Gattern 94 mit den Ausgängen vom vorhergehenden Flipflop 96 im Register (Ausgang vom ersten Fliflop 96) ODER-verknüpft. Bits werden von einem Taktgeber 98 entlang dem Register getaktet, bis sie als ein Ausgangssteuerbit auftauchen, das die Ausführung des Mikrocodebefehls beginnt.
So wird ein Steuerbit in die richtige Position in seiner Scheduling-Pipeline eingefügt, so dass es zum erforderlichen Taktzyklus an der Zielbank ankommt. Begrifflich besteht eine solche Befehlsbit-Pipeline für alle Mikrocode-Steuerbits, um aber den Umfang der zum Implementieren der Steuerpipeline benötigten Logik zu begrenzen, gibt es Begrenzungen an den Taktzyklen, auf die einige Felder des Mikrocodes platziert werden können.
Die bedingte Ausführung wird durch Spezifizieren einer bedingten Operation und Erzeugen des Zustandsbits erreicht. Es werden zwei Arten von bedingter Operation unterstützt. Die erste ist, den Schreib-Enable-Impuls zu einer Bank mit dem Bedingungscode von der gleichen oder einer anderen Bank zu qualifizieren. Die zweite ist, zu spezifizieren, dass ein Mikrobefehlswort erneut ausgeführt würde (anstatt der nächsten Befehl aus dem Programmzähler), wenn ein bestimmter Bedingungscode echt ist. Um die Anzahl von Möglichkeiten für Bedingungscodes zu begrenzen, können in diesen bedingten Operationen nur Datenbank-Bedingungscodes verwendet werden.

Beispielhaftes Mikrobefehlsformat

Folgendes gibt ein Beispiel eines Mikrobefehlsformats für diese Architektur und erläutert, wie es zum Erzielen von Multithreading auf einer zyklusweisen Basis verwendet wird.
In Fig. 6 wird eine Anzahl von Thread-Mikrobefehlen gezeigt. Jeder enthält Folgendes:
Steuerfelder für jede Bank, z. B. Registerauswahlbits und ALU-Steuerbits;
Befehlszeitsteuerungsbits für jede Bank - diese werden unten erklärt;
Leitsteuerbits, die das Leiten von Daten zwischen Banken steuern;
Kernsteuerbits, wie z. B. ob der Befehl bedingt wiederholt werden sollte und ob er Sofortdatenoperanden enthält.
Zur Durchführung dürfen Befehle über eine Anzahl von Taktzyklen ausgeführt werden. Der Zeitpunkt, an dem Teile des Befehls ausgeführt werden, wird von Verzögerungsbits innerhalb des Banksteuerfeldes gesetzt, welche die Position bestimmen, in der die Steuerbits in der Steuerwerk-Befehlspipeline platziert werden (Fig. 6).
Weil die Steuerbits in der Befehlspipeline platziert wurden, die den zukünftigen Zustand des Multimediasteuerungskerns repräsentiert, kann die Steuerwerklogik sicherstellen, dass die Befehlsverzögerung bei der Ressourcenprüfung berücksichtigt wird und dass ein Befehl an keinem der Taktzyklen, in denen er ausgeführt wird, Konflikte verursacht.

Ausführungsabhängigkeiten

Um die Komplexität des Hardware-Designs niedrig zu halten, dürfen Befehle über eine Anzahl von Taktzyklen hinweg ausgeführt werden. Die Zeit, zu der Teile des Befehls ausgeführt werden, wird von Verzögerungsbits innerhalb des Banksteuerfeldes bestimmt.
Um sicherzustellen, dass diese Befehlsverzögerung für jeden Takt berücksichtigt wird, wenn die Ressourcenprüfung durchgeführt wird, und dass die Operation beim korrekten Zyklus erfolgt, wird der den Verzögerungsbits entsprechende Operationscode in einen Satz von Latches eingespeist, die bei jedem Zyklus getaktet werden. Die Ausgänge dieser Latches repräsentieren den zukünftigen Zustand der Datenpipeline und werden in die Ressourcenprüfungslogik eingespeist, um sicherzustellen, dass ein Befehl an keinem der Taktzyklen, in denen er ausgeführt wird, Konflikte verursacht.

Banken-Cache

Der Mehrbanken-Cache besteht aus einer Anzahl von Cache- Banken und hat Schnittstellen zu Verarbeitungseinheiten und Speicher, wie in Fig. 7 gezeigt. Um ein beliebig skalierbares Gerät zu unterstützen, wird eine Mehrzahl von Cache-Banken benutzt. Die Verwendung jeder Bank wird von einem Cache- Zuordner 86 gesteuert, der mit einem Cache-Benutzer wie einer Leseeinheit oder einer Schreibeinheit assoziiert ist. Diese können programmierbar gesteuert werden, um die Cache-Banken in verschiedenen Konfigurationen zu verwenden. Beispielsweise kann eine Bank für Kommandodaten, eine weitere für 3D-Textur- Maps und eine dritte für 2D-Parameter verwendet werden. Die Fähigkeit zum Konfigurieren der Cache-Banken ist für das Erreichen einer guten Speicherleistung wichtig.
Jeder Port, wie eine Leseeinheit 88 oder eine Schreibeinheit 90, die Zugang zum Cache benötigt, ist mit einem Zuordnermodul 86 verbunden. Diese Module untersuchen die Speicheranfrage, die vom Port gemacht wird, und leiten die Anfrage an die zutreffende Cache-Bank. Die vom Port gesendete Adresse wird mit einem Basisbereichsregisterpaar im Schreibzuordner verglichen, um zu bestimmen, ob die Adresse in einen bestimmten Bereich fällt oder nicht. Bei einer Übereinstimmung wird die Abfrage dann zur Cache-Bank weitergeleitet. Gibt es keine Übereinstimmung, wird eine Vorgabe-Cache-Bank benutzt. Das umfasst einfach das Durchleiten der Anfrage zum Speichersubsystem.
Es kann mehr als ein Satz Basis- und Bereichsregister verwendet werden, je nach den Speichererfordernissen des am Port angeschlossenen Moduls.
Nicht alle bereitgestellten Cache-Banken müssen von jedem bestimmten Zuteiler aus zugänglich sein. Einige Ports benötigen mehr Flexibilität als andere. Diese Tatsache ermöglicht die leichte Skalierung (Vergrößerung) der Anzahl von Cache-Banken, während die Zunahme von zwischen Zuteilern und Cache-Banken erforderlichen Verbindungen eingeschränkt wird. Ein Satz Cache-Speicher könnte also zum Abwickeln von Videoeingabeanfragen und Audioeingaben und -ausgaben alloziert werden, während andere hauptsächlich für Datenabrufe aus dem Hauptspeicher alloziert werden könnten.
Jede Cache-Bank ist über einen Zuteiler 94 mit Lese- und Schreibzuordnern verbunden. Dieser erhält Anfragen für Zugang von allen Zuordnern und kann dann bestimmen, welcher Zuordner zu dieser bestimmten Cache-Bank Zugang erhalten soll. Erreicht wird das dadurch, dass jedem Port eine Priorität zugeteilt und veranlasst wird, dass der Zuteiler einfach die ausstehende Anfrage der höchsten Priorität verarbeitet.
Das System kann auf andere Arten von Eingaben wie MPEG und Videokonferenzen erweitert werden.

Claims

1. Datenverarbeitungsmanagementsystem zum Ausführen unabhängiger Anweisungs-Threads, das Folgendes umfasst:

eine Mehrzahl von Dateneingaben (4),

eine Mehrzahl von Datenausgaben (4),

eine Mehrzahl von Datenverarbeitungs-(8)-einrichtungen, die jeweils Datenverarbeitungsvorgänge durchführen können, welche wenigstens einen der Anweisungs-Threads bilden,

einen Datenspeicher (12) und

eine Steuereinrichtung (2),

wobei die Steuereinrichtung (2) Folgendes beinhaltet:

Mittel zum Leiten von Daten zwischen einer ausgewählten Dateneingabe, einer ausgewählten Datenausgabe, einer ausgewählten Datenverarbeitungseinrichtung und dem Datenspeicher in einem oder mehr auswählbaren Leitvorgängen,

Mittel zum Veranlassen, dass die ausgewählte Datenverarbeitungseinrichtung, gestützt auf einen ausgewählten Anweisungs-Thread, einen von einer Anzahl vorbestimmter Datenverarbeitungsvorgänge beginnt,

Mittel zum wiederholten Bestimmen, welche Leitvorgänge und welche Datenverarbeitungsvorgänge durchgeführt werden können,

Mittel zum Beginnen der Ausführung von wenigstens einem der so bestimmten Leit- oder Datenverarbeitungsvorgänge, die durchgeführt werden können.

2. Datenverarbeitungsmanagementsystem nach Anspruch 1 mit Mitteln, um jedem Leit- und Datenverarbeitungsvorgang, der durchgeführt werden kann, eine Priorität zuzuordnen, und einer Einrichtung zum Bestimmen, welchem der Leitvorgänge und Datenverarbeitungsvorgänge, die durchgeführt werden können, die höchste Priorität zugeordnet wurde, wobei das Mittel zum Beginnen der Ausführung zum Beginnen mit dem Ausführen des Vorgangs mit der höchsten zugeordneten Priorität geregelt ist.

3. Datenverarbeitungsmanagementsystem nach Anspruch 1 oder 2, bei dem die wenigstens eine Dateneingabe eine Echtzeiteingabe ist und dem Vorgang des Empfangens von Daten an dieser Eingabe die höchste Priorität zugeordnet wurde.

4. Datenverarbeitungsmanagementsystem nach Anspruch 3, bei dem die Echtzeitdateneingabe eine Videodateneingabe ist.

5. Ein Datenverarbeitungsmanagementsystem nach Anspruch 3, bei dem die Echtzeitdateneingabe eine Audioeingabe ist.

6. Datenverarbeitungsmanagementsystem nach einem der Ansprüche 2 bis 5, bei dem die Einrichtung zum wiederholten Bestimmen, welche Leitvorgänge und welche Datenverarbeitungsvorgänge durchgeführt werden können, diese Bestimmung mit jedem Taktzyklus trifft.

7. Datenverarbeitungsmanagementsystem nach einem der Ansprüche 2 bis 6, bei dem die Einrichtung zum Bestimmen, welchem der so bestimmten Vorgänge die höchste Priorität zugeordnet wurde, diese Bestimmung mit jedem Taktzyklus einer mit der Steuereinrichtung assoziierten Takteinrichtung durchführt.

8. Datenverarbeitungsmanagementsystem nach Anspruch 6 oder Anspruch 7, bei dem der Beginn des so bestimmten Vorgangs mit der höchsten zugeordneten Priorität an einem nachfolgenden Taktzyklus stattfindet.

9. Datenverarbeitungsmanagementsystem nach einem der vorangehenden Ansprüche, bei dem die Mittel zum Bestimmen, welche Leit- und Datenverarbeitungsvorgänge durchgeführt werden können, diese Bestimmung anhand von über einen Statusbus erhaltenen und durch interne und/oder externe Ressourcen erzeugten Ressourcenstatusbits treffen.

10. Datenverarbeitungsmanagementsystem nach einem der vorangehenden Ansprüche, bei dem die Datenverarbeitungseinrichtung einen Speicher mikrocodierter Anweisungen hat, die sich auf einen von der Verarbeitungseinrichtung durchzuführenden Verarbeitungsvorgang beziehen.

11. Datenverarbeitungsmanagementsystem nach Anspruch 10, bei dem die Steuereinrichtung die Ausführung des Verarbeitungsvorgangs durch Bereitstellen eines Adressenoffsets in den Mikrocodeanweisungsspeicher der Datenverarbeitungseinrichtung beginnt.

12. Datenverarbeitungsmanagementsystem nach einem der vorangehenden Ansprüche, bei dem der Datenspeicher einen Cache-Speicher aufweist.

13. Datenverarbeitungsmanagementsystem nach Anspruch 12, bei dem der Cache-Speicher eine Mehrzahl von Cache-Speicherbanken umfasst.

14. Datenverarbeitungsmanagementsystem nach Anspruch 1, bei dem jeder Teil des Systems, der Zugriff auf den Cache-Speicher hat, mit einer Cache-Speicher-Allozierungseinrichtung assoziiert ist, die programmierbar ist, um Zugriff auf verschiedene Cache-Speicherbanken zuzulassen.

15. Datenverarbeitungsmanagementsystem nach einem der vorangehenden Ansprüche, bei dem die Steuereinrichtung einen Satz Datenbanken aufweist, und zum Durchführen von Vorgängen an Daten innerhalb der Steuereinrichtung.

16. Datenverarbeitungsmanagementsystem nach einem der vorangehenden Ansprüche, bei dem die Steuereinrichtung einen Satz Adressenbanken aufweist, eine für jeden der vom System durchzuführenden Datenverarbeitungsvorgänge.

17. Datenverarbeitungsmanagementsystem nach einem der vorangehenden Ansprüche, bei dem die Steuereinrichtung eine Programmzählerbank zum Speichern der aktuellen Programmadresse für jeden Datenverarbeitungsvorgang jedes Anweisungs-Threads aufweist.

18. Datenverarbeitungsmanagementsystem nach einem der vorangehenden Ansprüche, bei dem die Steuereinrichtung einen Satz Eingabe-/Ausgabebanken zum Verbinden mit der Mehrzahl von Eingabe-/Ausgabeeinrichtungen aufweist.

19. Datenverarbeitungsmanagementsystem nach einem der vorangehenden Ansprüche, bei dem die Steuereinrichtungen Lese- /Schreibeinheiten zum Verbinden mit dem Speicher aufweisen.

20. Datenverarbeitungsmanagementsystem nach Anspruch 13, bei dem jede Datenbank eine arithmetisch-logische Einheit (ALU) und eine nur mit dieser ALU assoziierte Registerdatei aufweist.

21. Datenverarbeitungsmanagementsystem nach einem der Ansprüche 15 bis 20, bei dem die Datenbanken, die Adressenbanken, die Programmzählerbanken, die Eingabe- /Ausgabebanken und die Lese-/Schreibbanken alle mit einem gemeinsamen Statusbus, einer gemeinsamen Datenverbindung und einem gemeinsamen Steuerbus verbunden sind.

22. Verfahren zum Ausführen unabhängiger Anweisungs-Threads, bei dem zu verarbeitende Daten an jedem Anweisungs-Thread von einer von einer Mehrzahl von Dateneingaben bereitgestellt werden und Daten, die als Folge der Verarbeitung des Anweisungs-Threads produziert werden, zu einer Mehrzahl von Datenausgaben übertragen werden, wobei das Verfahren die folgenden Schritte aufweist:

Leiten von Daten zwischen einer ausgewählten Dateneingabe, einer ausgewählten Datenausgabe, einer ausgewählten Datenverarbeitungseinrichtung und einem Datenspeicher in einem oder mehr auswählbaren Leitvorgängen,

Veranlassen, dass eine Mehrzahl von Datenverarbeitungseinrichtungen, gestützt auf einen ausgewählten Anweisungs-Thread, einen von einer Anzahl von vorbestimmten Datenverarbeitungsvorgängen beginnt,

wiederholtes Bestimmen, welche Leitvorgänge und welche Datenverarbeitungsvorgänge gebildet werden können, und

Beginnen der Ausführung von wenigstens einem der so bestimmten Leit- oder Datenverarbeitungsvorgänge, die durchgeführt werden können.

23. Verfahren nach Anspruch 22, das den Schritt des Zuordnens einer Priorität zu jedem Leit- and Datenverarbeitungsvorgang, der durchgeführt werden kann, und des Bestimmens, welchem der Leitvorgänge und der Datenverarbeitungsvorgänge, die durchgeführt werden können, die höchste Priorität zugeordnet wurde, aufweist und bei dem der Schritt des Beginnens der Ausführung zum Beginnen der Ausführung des Vorgangs mit der höchsten zugeordneten Priorität geregelt ist.

24. Verfahren nach Anspruch 22 oder 23, bei dem der Schritt des Bestimmens, welche Leitvorgänge und welche Datenverarbeitungsvorgänge durchgeführt werden können, diese Bestimmung mit jedem Taktzyklus trifft.

25. Verfahren nach Anspruch 23 oder Anspruch 24, bei dem der Schritt des Bestimmens, welchem Datenverarbeitungsvorgang oder Leitvorgang die höchste Priorität zugeordnet wurde, diese Bestimmung an einem nachfolgenden Taktzyklus trifft.

26. Verfahren nach Anspruch 24 oder Anspruch 25, bei dem der Schritt des Beginnens des Vorgangs mit der höchsten zugeordneten Priorität an einem nachfolgenden Taktzyklus stattfindet.

27. Verfahren nach einem der Ansprüche 22 bis 26, bei dem der Schritt des Bestimmens, welche Leitvorgänge und Datenverarbeitungsvorgänge durchgeführt werden können, anhand von über einen Statusbus erhaltenen und durch interne und/oder externe Ressourcen erzeugten Ressourcenstatusbits erfolgt.