DE69822591T2

DE69822591T2 - System und Verfahren zur Kontextumschaltung über vorbestimmte Unterbrechungspunkte

Info

Publication number: DE69822591T2
Application number: DE69822591T
Authority: DE
Inventors: Francky Catthoor; Stefan Janssens; Miguel Miranda; Hugo De Man
Original assignee: Interuniversitair Microelektronica Centrum vzw IMEC
Current assignee: Interuniversitair Microelektronica Centrum vzw IMEC
Priority date: 1997-11-19
Filing date: 1998-11-17
Publication date: 2005-03-24
Anticipated expiration: 2018-11-18
Also published as: EP0918280A1; US6223274B1; EP0918280B1; DE69822591D1

Description

Die vorliegende Erfindung bezieht sich auf Prozessoren und eine Prozessororganisation für die Ausführung von datendominierten Programmen, und insbesondere darauf, eine Kombination der Flexibilität von Software-Prozessoren und der Geschwindigkeit und Kosteneffizienz von zweckbestimmten Hardware-Prozessoren zu schaffen. Insbesondere betrifft die vorliegende Erfindung flexible, wiederbenutzbare, spezifisch angepasste Prozessoren und Verfahren zur Benutzung derselben.
Technischer Hintergrund der Erfindung
Eine typische Beispielanwendung für datendominiertes Verarbeiten ist (MPEG-basierte) Videokompression. Es wurden viele angepasste Hardware-Architekturen zur Bewegungsschätzung und andere MPEG-Teilsysteme vorgeschlagen. Für solche Anwendungen wird die Verwaltung und Reduzierung der Leistungsaufnahme ein wichtiger Punkt sein. Es sind zwei Beispiele von auf MPEG2 spezifisch angepassten Prozessoren bekannt, die eine vergleichbare CMOS-Technologie nutzen und die folgenden Merkmale aufweisen:

– SGS: 4 chip set, 20 W @ 27 MHz, flexible zentralisierte Bus/Speicher-Organisation, 64 Mbit externes RAM.
– Mitsubishi: 3 chip set, 8,5 W @ 8 MHz, stark spezifisch angepasst, verteilte Organisation, 44 Mbit externes DRAM.

Beide haben eine sich deutlich unterscheidende Datentransfer- und Speicherorganisation. Daher wird die Flexibilität und Einfachheit der Ausführung des gemeinsamen Bussystems (shared bus system) mit einem höheren Strombudget erkauft. Ein ziemlich allgemeines Modell (Vorlage), das hauptsächlich den Datentransfer und die Speicherarchitektur für solche HW-Lösungen schematisch beschreibt, ist in 1 gezeigt. Die Hauptspeicherarchitektur ist von der Verarbeitungskapazität (Datenprozessoren DP) getrennt, welche eine angepasste Speicherverwaltungseinheit (MMU) und einige lokale Puffer zum Steuern des Datenstroms zwischen der Hauptverarbeitungskapazität und dem Speicher aufweist. Die Vor- und Nachteile dieses Ansatzes sind:

1. –: Die Ausführung ist schwierig (MMU, Steuerung, Schnittstellen); eine Unterstützung in der Design-Ausbeutung (design exploration support) ist derzeit sehr auf Systemniveau begrenzt (nur die "Integration" wurde angegangen);
2. ––: anwendungsspezifisch, kann daher nicht geändert werden, nachdem der Chip hergestellt wurde;
3. –: Stromaufnahme noch immer zu hoch aufgrund einer strikten Speicherhierarchie und zentralen Busarchitektur;
4. +: akzeptable Fläche aufgrund logischer Synthese und manuell geschriebenem strukturiertem VHDL;
5. ++: sehr gute Geschwindigkeit außer Transfer-Aufschlag (transfer overhead) für datendominierte Systeme.

Obwohl der Engpass in der Leistungsaufnahme für spezifisch angepasste Prozessoren durch eine Kombination von globalen und aggressiven Datenfluss- und Schleifentransformationen auf Systemniveau verbunden mit einer stark partitionierten, angepassten Speicherorganisation ohne Nachteile bei der Fläche oder Geschwindigkeit zu einem erheblichen Maße verringert werden kann, ist dasselbe für die derzeitige Generation von programmierbaren Prozessorlösungen nicht richtig.
Viele dieser Architekturen wurden für die Video- und Bildverarbeitung vorgeschlagen. In der Literatur wird die Stromverwaltung und Stromreduzierung für diese Prozessoren kaum behandelt, wird jedoch als wachsendes Problem von der Industrie angesehen (zumindest auf der "Konsumentenseite"). Einige neuere kommerzielle Multimedia-orientierte Prozessoren sind vertrieben oder angekündigt worden: TI-C80 und kürzlich C60, Philips-TriMedia, Chromatic-Mpact, Nvidia NV1, NEC PIP-RAM. Einige andere superskalare/VLIW-Prozessoren sind mit einem erweiterten Befehlssatz für Multimedia-Anwendungen angekündigt: Intel (MMX), SGI/MIPS (MDMX), HP (MAX), DEC (MVI), Sun (VVIS), AMD (MMX), IBM (Java). Es sind auch einige weitere zweckbestimmte domänenspezifische ASIP-Prozessoren vorgeschlagen worden, so wie die MIPS MPEG2-Maschine, welche einen Multi-RISC, mehrere Speicher und ein programmierbares Netzwerk aufweist.
Eine relativ allgemeine schematische Beschreibung solcher Prozessoren ist in 2 gezeigt. Der Hauptspeicher ist über Daten-Caches mit separatem Speicher und Befehls-Cache für die Programmanweisungen zugreifbar. Die Vor- und Nachteile dieses Ansatzes sind:

1. ++: Angemessene Entwurfszeit für Anwendungsingenieur. Relativ einfaches Programmieren für die Prozessordatenpfade (arithmetische Operationen). Die Transfer- und Speicherorganisation ist jedoch fast immer der Hardware überlassen (Cache-Steuerungen und MMU), um die Abbildungskomplexität für den Programmierer/Compiler zu reduzieren.
2. +: Volle Flexibilität bei Anwendungen, wobei jedoch der Geschwindigkeitsengpass in vielen Fällen ein Problem bleibt.
3. ––: Große Leistungsaufnahme wegen aufwändiger Datentransfers (lange "Strecken" und feste Speicherhierarchie), von denen viele nicht wirklich notwendig sind. Letztere tauchen zusätzlich z. B. aufgrund der nicht optimalen Echtzeit-Cache-Steuerung auf, welche typischerweise einen Overhead bzw. Aufschlag in doppelten Datentransfers von dem Hauptspeicher für wiederbenutzte Daten mit langen Lebenszeiten verursacht, oder aufgrund der spekulativen Ausführung in vielen Prozessoren, wie es in der Zweigbestimmungseinheit entschieden wird.
4. ––: Die größte Fläche des Chips/Boards wird von Speichern und Bussen eingenommen. Ebenso ist die Adress- und Steuerkomplexität hoch.
5. ––: Noch immer zu geringe Geschwindigkeit für anspruchsvolle Anwendungen, sodass Parallelprozessoren benötigt werden. Parallelprozessoren sind jedoch wegen der Datenkommunikation sehr schwierig effizient zu programmieren.

Um eine parallele Verarbeitung durchzuführen (siehe 3), konzentriert sich der derzeitige Ansatz fast vollständig auf arithmetische Operationen: Mehrere parallele Datenprozessoren arbeiten auf einem gemeinsamen Cache (multiskalar), oder einige "vollständige" Prozessoren arbeiten auf einem gemeinsamen Hauptspeicher. Der Grund für die Auswahl der Option "einziger virtueller Adressraum" für den Hauptspeicher besteht lediglich in der Einfachheit des Kompilierens der Anwendungen auf der Parallelarchitektur. Diese Wahl führt jedoch zu einigen Nachteilen, z. B. wird der Stromaufnahme-Overhead wegen der physikalischen Speicherorganisation mit großen Speichern und vielen globalen Verbindungen noch größer. Es ist also auch die Fläche negativ beeinflusst wegen der Komplexität der internen Speicherorganisation, da alles gemeinsam genutzt werden muss. Dies geschieht einerseits aufgrund des Buskommunikations-Overhead, der zur Minderung des Performance-Engpasses benötigt wird, und andererseits aufgrund der Notwendigkeit, global zugeteilte Daten ebenso in den lokalen (Cache-)Speichern für die Prozessoren zu duplizieren. Der Geschwindigkeitsengpass wird nur teilweise durch das Vorhalten von Parallelizität gemindert, weil es üblicherweise nicht möglich ist, die benötigen Daten parallel zu den arithmetischen Operationen aufgrund des beschränkten I/O und der Speicherbandbreite zu erhalten. Dadurch werden Leerzyklen in den Datenpfaden (NOPs) erzeugt.
In der Vergangenheit wurden viele Arbeiten zu Cache-Kohärenz-Protokollen und ebenso zu Parallelprozessoren veröffentlicht. Im Parallel-Compiler-Bereich sind jedoch meistens Probleme der Lastbalancierung für arithmetische Operationen behandelt worden, weil der allgemeine Ansatz von dem Hardware-Cache-Mechanismus abhängt. Einige wenige haben das Datenlokalisierungsproblem zum Erreichen einer besseren Cache-Benutzung angesprochen. Die herkömmlichen programmierbaren Architekturen und herkömmliche (parallele) Compiler werden zu schweren Problemen bei der Wärmedissipation führen.
Wenn man den Stand der Technik zu zweckbestimmten (HW-) und programmierbaren Befehlssatz-(SW-)Prozessoren für datendominierte Multimedia-Anwendungen betrachtet, wird deutlich, dass viele der Architekturkomponenten zum Lösen der Datentransfer- und Speicherprobleme vorgesehen sind. Bei sowohl HW als auch SW ist der Hauptenergieaufwand (und weitestgehend ebenso der Flächenaufwand) in den Speicherinhalten und der (Bus-)Kommunikations-Hardware zu finden. Auf der HW-Seite wurden mehrere Vorgehensweisen bezüglich der Speicherverwaltung auf Systemebene vorgeschlagen, die große Einsparungen im Stromverbrauch und ebenso der Fläche versprechen und trotzdem die einschränkenden Bedingungen für den Echtzeitbetrieb erfüllen. Leider sind auf der SW-Seite solche Vorgehensweisen an sich nicht anwendbar, und auch bei einer Anpassung wird der Programmierungs-Overhead im Datentransfer und der Speicherarchitektur verglichen mit der HW-Lösung zu dem (großen) in Kauf zu nehmenden Nachteil im Stromverbrauch führen. Sie zeigen verschiedene Charakteristiken in Bezug auf Strom und Geschwindigkeitseffizienz gegenüber Einflüssen auf die Prozessorarchitektur und der Entwurfszeit.
In 4 ist die Sicht auf die oberste Ebene einer typischen heterogenen Systemarchitektur mit sowohl zweckbestimmter, spezifisch angepasster Hardware (Beschleunigerdatenpfad, zweckbestimmter Prozessor und Glue Logic) als auch programmierbarer Prozessoren (DSP und RISC-Kerne, Hauptprozessor) in einem Zielanwendungsbereich gezeigt. Architekturexperimente haben gezeigt, dass 50–80% des Flächenaufwandes in (anwendungsspezifischen) Architekturen für Echtzeit-multidimensionale Signalverarbeitung durch die Speichereinheiten gegeben ist, d. h. Einzel- oder Multiport-RAMs, Pointer-adressierte Speicher und Register-Dateien. Der Energieaufwand sowohl für spezifisch angepasste HW- und für SW-Prozessoren ist noch stärker durch Speicherung und Transfers von komplexen Datentypen dominiert. Daher bildet die Organisation des globalen Datentransfers und Speichers zusammen mit den dazugehörenden algorithmischen Transformationen die dominierenden Faktoren bei Entscheidungen für den Entwurf von Architekturen auf Systemebene. Für solche Anwendungen ist die Datentransfer- und Speicherarchitektur für SW-Prozessoren, d. h. die vorhandenen Speichereinheiten und die (Bus-)Kommunikations-Hardware zwischen ihnen zusammen mit deren Benutzung bei einer vorgegebenen Anwendung, ineffizient stromverbrauchend.
Ziel der Erfindung
Es ist eine Aufgabe der vorliegenden Erfindung, die Probleme mit herkömmlichen programmierbaren (Parallel-)Prozessoren zu beheben und eine System-on-a-Chip-Lösung mit einer flexiblen Zusammenstellung von Hardware-(HW-) und Software-(SW-)Prozessoren zu schaffen.
Es ist ferner eine Aufgabe der vorliegenden Erfindung, einen (viel) größeren Teil der Anwendung in Stromverbrauchs-/Flächen-/zeiteffizienter HW auszuführen, während weitestgehend die Flexibilität einer traditionellen SW-Ausführung beibehalten wird.
Es ist noch eine weitere Aufgabe der vorliegenden Erfindung, einen wiederverwendbaren, spezifisch angepassten Prozessor zu schaffen, der mit veränderten Anwendungen, die von der ursprünglich vorgesehenen Anwendung für den Prozessor abweichen, wieder benutzt werden kann, ohne dass dabei der Aufschlag an Aufwand einer vollständig programmierbaren Lösung entsteht.
Literaturhinweise
Technische Literatur, die zum Verständnis der vorliegenden Erfindung beitragen kann, ist: R. W. Brodersen, "The Network Computer and its Future", Proc. IEEE Int. Solid-State Circ. Conf., San Francisco, CA, S. 32–36, Feb. 1997, F. Catthoor, F. Franssen, S. Wuytack, L. Nachtergaele, H. De Man, "Global communication and memory optimizing transformations for low power signal processing systems", IEEE workshop on VLSI signal processing, La Jolla CA, Okt. 1994, P. Chatterjee, "Gigachips: deliver affordable digital multi-media for work and play via broadband network and set-top box", Proc. IEEE Int. Solid-State Circ. Conf., San Francisco, CA, S. 26–30, Feb. 1995; K. Danckaert, F. Catthoor, H. De Man, "System level memory optimization for hardware-software co-design", Proc. IEEE Intnl. Workshop on Hardware/Software Co-design, Braunschweig, Germany, S. 55–59, März 1997; R. Gonzales, M. Horowitz, "Energy dissipation in general-purpose microprocessors", IEEE J. Solid-state Circ., Band SC-31, Nr. 9, S. 1277–1283, Sep. 1996; T. Halfhill, J. Montgomery, "Chip fashion: multi-media chips", Byte Magazine, S. 171–178, Nov. 1995; C. Kulkarni, F. Catthoor, H. De Man, "Cache Optimization for Multimedia Compilation on Embedded Processors for Low Power", submitted to Intnl. Parallel Proc. Symp. (IPPS), Orlanda FA. April 1997; P. Lippens, J. van Meerbergen, W. Verhaegh, A. van der Werf, "Allocation of multiport memories for hierarchical data streams", Proc. IEEE Int. Conf. Comp. Aided Design, Santa Clara, CA, Nov. 1993; T. H. Meng, B. Gordon, E. Tsern, A. Hung, "Portable video-on-demand in wireless communication", special issue on "Low power electronics", Proc. of the IEEE, Band 83, Nr. 4, S. 659–680, April 1995; D. Moolenaar, L. Nachtergaele, F. Catthoor, H. De Man, "System-level power exploration for MPEG-2 decoder on embedded cores: a systematic approach", Proc. IEEE Wsh. on Signal Processing Systems (SIPS), Leicester, UK, Nov. 1997; L. Nachtergaele, F. Catthoor, F. Balasa, F. Franssen, E. de Greef, H. Samson, H. De Man, "Optimisation of memory organisation and hierarchy for decreased size and power in video and image processing systems", Proc. Intnl. Workshop on Memory Technology, Design and Testing, San Jose, CA, S. 82–87, Aug. 1995; L. Nachtergaele, F. Catthoor, B. Kapoor, D. Moolenaar, S. Janssens, "Low power storage exploration for H.263 video decoder", IEEE workshop on VLSI signal processing, Monterey, CA, Okt. 1996; D. A. Patterson und J. L. Hennessy, "Computer Organisation and Design: the Hardware/Software Interface", Morgan Kaufmann Publishers, NY, 1994; P. Pirsch, N. Demassieux, W. Gehrke, "VLSI architectures for video compression – a survey", Proc. of the IEEE, invited paper, Band 83, Nr. 2, S. 220–246, Feb. 1995; V. Tiwari, S. Malik, A. Wolfe, "Power analysis of embedded software: a first step towards software power minimization", Proc. IEEE Int. Conf. Comp. Aided Design, Satan Clara, CA, S. 384–390, Nov. 1994; I. Verbauwhede, F. Catthoor, J. Vandewalle, H. De Man, "Background memory management for the synthesis of algebraic algorithms on multi-processor DSP chips", Proc. VLSI'89, Int. Conf. on VLSI, München, Deutschland, S. 209–218, Aug. 1989; S. Wuytack, F. Catthoor, L. Nachtergaele, H. De Man, "Power Exploration for Data Dominated Video Applications", Proc. IEEE Intnl. Symp. on Low Power Design, Monterey, S. 359–364, Aug. 1996.
Zusammenfassung der Erfindung
Die vorliegende Erfindung weist eine programmierbare Verarbeitungsmaschine auf, wobei die Verarbeitungsmaschine einen spezifisch angepassten Prozessor, einen anpassbaren Prozessor und einen Datenspeicher, der gemeinsam von den beiden Prozessoren nutzbar ist, aufweist, wobei der spezifisch angepasste Prozessor eine Abfolge aus einer Mehrzahl von Routinen ausführt und der anpassbare Prozessor ein programmierbarer Prozessor oder ein wiederkonfigurierbarer Logikschaltkreis ist, mit:
einer Steuereinrichtung zum Überwachen des spezifisch angepassten Prozessors während der Ausführung eines ersten Programmteils zum Auswählen eines aus einem Satz von vorangepassten Verfahrensunterbrechungspunkten in einer ersten Routine und zum Umschalten von Kontext von dem spezifisch angepassten Prozessor zu dem anpassbaren Prozessor an dem gewählten Unterbrechungspunkt.
Die vorliegende Erfindung schafft ferner ein Verfahren für den Betrieb einer programmierbaren Verarbeitungsmaschine, wobei die Verarbeitungsmaschine einen spezifisch angepassten Prozessor, einen anpassbaren Prozessor und einen Datenspeicher, der gemeinsamen von den beiden Prozessoren nutzbar ist, aufweist, wobei der spezifisch angepasste Prozessor eine Abfolge von Routinen aus einer Mehrzahl von vorangepassten Routinen ausführt und der anpassbare Prozessor ein programmierbarer Prozessor und ein wiederkonfigurierbarer Logikschaltkreis ist, und das Verfahren die Schritte aufweist: Überwachen des spezifisch angepassten Prozessors während des Ausführens eines ersten Programmteils zum Auswählen eines aus einem Satz von vorangepassten Prozessunterbrechungspunkten in einer ersten Routine; und
Umschalten von Kontext von dem spezifisch angepassten Prozessor zu dem anpassbaren Prozessor an dem ausgewählten Unterbrechungspunkt. Das Verfahren weist als einen folgenden Schritt das Ausführen eines zweiten Programmteils auf dem anpassbaren Prozessor auf, wobei zumindest ein Teil von ersten Daten benutzt wird, die in dem Datenspeicher durch die Ausführung des ersten Programmteils auf dem spezifisch angepassten Prozessor belassen sind.
Die vorliegende Erfindung liefert außerdem eine Prozessorarchitektur mit einer Hierarchie von Cache-Speichern, wobei die Cache-Speicher während der Laufzeit flexibel konfigurierbar sind. Diese Prozessorarchitektur kann vorteilhafterweise in dem oben genannten Verfahren und der Vorrichtung verwendet werden. Bei dieser Prozessorarchitektur können die flexibel konfigurierbaren Cache-Speicher flexible Bypasse über eine wählbare Kombination von Cache-Ebenen der Hierarchie aufweisen. In dieser Prozessorarchitektur können die flexibel konfigurierbaren Cache-Speicher außerdem Mittel aufweisen, die es erlauben, dass Signale in einer auswählbaren Cache-Ebene der Cache-Ebenen der Hierarchie für mehr als einen Zyklus verbleiben. In dieser Prozessorarchitektur können die flexibel konfigurierbaren Cache-Speicher ebenfalls Mittel aufweisen, die es ermöglichen, dass verschiedene Cache-Ebenen der Cache-Speicherhierarchie zu einem einzigen Speicher zusammengefasst werden, so dass die Größe jeder einzelnen Cache-Ebene daraus auswählbar ist. Bei dieser Prozessorarchitektur können die flexibel konfigurierbaren Cache-Speicher ferner Mittel zum Aufteilen des Caches in Bänke und Mittel zum auswählbaren Zusammenstellen der Bänke zu auswählbar zugreifbaren Cache-Partitionen aufweisen. Bei dieser Prozessorarchitektur können die flexibel konfigurierbaren Cache-Speicher auch Mittel aufweisen, die eine Auswahl des Grades der Assoziativität für jede Cache-Ebene ermöglichen.
Die vorliegende Erfindung wird nun unter Bezugnahme auf die folgenden Zeichnungen beschrieben.
Kurzbeschreibung der Zeichnungen
1 ist eine schematische Darstellung eines herkömmlichen Hardware-Architekturmodells.
2 ist eine schematische Darstellung eines herkömmlichen Software-Architekturmodells.
3 ist eine schematische Darstellung eines herkömmlichen Architekturmodells: parallele SW
4 zeigt eine typische heterogene System-on-a-Chip-Architektur für Multimedia-Anwendungen, mit zweckbestimmter Hardware (anwendungsspezifische Beschleunigerdatenpfade und Logik), einem programmierbaren Prozessor (DSP-Kern und Steuerung) und einer aufwandsdominanter, verteilter Speicherorganisation.
5 zeigt ein Zusammenspiel von SW- und HW-Partitionen mit zwischenliegenden Puffern.
6 zeigt eine schematische Darstellung einer Architektur gemäß einer Ausführungsform der vorliegenden Erfindung.
7 zeigt ein Zusammenspiel (co-operation) von SW- und HW-Partitionen mit nur einem Hauptspeicherbereich, der gemäß der Ausführungsform von 6 gemeinsam benutzt wird.
8 zeigt ein Zusammenspiel von IP und CP, mit 4 Phasen, wenn sich die Kontextumschaltung für das Modul M3 in dem auf den CP abgebildeten Originalalgorithmus ereignen muss, bei einer Ausführungsform der vorliegenden Erfindung.
9 zeigt ein Zusammenspiel von IP und CP: Überwachen von Merkern von bedingenden Zweigen gemäß einer Ausführungsform der vorliegenden Erfindung. Im Allgemeinen müssen nur Teile dieser Merker von dem IP abgefragt werden, um der aktuellen Trace bzw. Spur zu folgen.
10 zeigt eine Architektur auf Systemebene gemäß einer weiteren Ausführungsform der vorliegenden Erfindung für kooperatives Adressieren.
11 zeigt schematisch eine Kontextumschaltung für eine Master-Master-kooperative cACU gemäß einer weiteren Ausführungsform der vorliegenden Erfindung.
12 zeigt schematisch ein Master-Master-Protokoll gemäß einer Ausführungsform der vorliegenden Erfindung für Normalbetriebsmodus.
13 zeigt eine Interrupt-Prozedur für bedingende Trace-Überwachung einer cACU durch den IP gemäß einer Ausführungsform der vorliegenden Erfindung.
14A und B zeigen normale und modifizierte Betriebsmodi mit einer Kontextumschaltung für eine Master-Slave-kooperative cACU gemäß einer Ausführungsform der vorliegenden Erfindung.
15 zeigt eine Schnittstellenarchitektur zwischen einer cACU und einem IP für einen Master-Slave-Normalbetriebsmodus gemäß einer Ausführungsform der vorliegenden Erfindung.
16 zeigt einen schematischen Überblick einer Pipeline-cACU gemäß einer Ausführungsform der vorliegenden Erfindung.
17 zeigt eine Speicherabfrage für eine Ausführungsform der vorliegenden Erfindung mit einer Master-Slave-Architektur.
18 zeigt den zeitlichen Ablauf für die Dateneingabe für die Ausführungsform von 17.
19 ist der zeitliche Ablauf für Speichereinschreiben für die Ausführungsform von 17.
20 zeigt eine weitere Architektur für eine Ausführungsform der vorliegenden Erfindung mit HW- und SW-Kernen, die sich mehrere ausgewählte Einheiten in der zweckbestimmten Speicherhierarchie teilen.
21 zeigt ein Zusammenspiel von SW- und HW-Partitionen mit verschiedenen Einheiten in der zweckbestimmten Speicherhierarchie, die gemäß der Ausführungsform, wie sie in 20 gezeigt ist, gemeinsam benutzt wird.
22 zeigt eine weitere Modifikation der Ausführungsform von 20 mit einem Stromaufnahme-effizienten Schaltbaum.
23 zeigt flexible Wechselwirkung zwischen einer zweckangepassten ACU und programmierbarer ACU gemäß einer Ausführungsform der vorliegenden Erfindung.
24 zeigt ein Architekturmodell: SW/HW für eine weitere Ausführungsform der vorliegenden Erfindung.
25 zeigt ein Beispiel einer Ausführungsform mit einem ASIP gemäß einer Ausführungsform der vorliegenden Erfindung.
Ausführliche Beschreibung der Erfindung und bevorzugte Ausführungsformen
Die vorliegende Erfindung weist eine Architektur und Design-Methodik auf, die für die Aufnahme sowohl von zweckbestimmten HW- als auch flexiblen SW-Einheiten zusammen auf einem Einzelchipsystem und wie die Steuerung zu organisieren ist, um eine außergewöhnliche Flexibilität und Wiederprogrammierbarkeit ohne eine erhöhte Stromaufnahmecharakteristik des Designs zu schaffen, nützlich ist. Dies liefert eine sehr (viel) kosteneffektivere Alternative zu herkömmlichen Lösungen, wobei beispielsweise vollständig programmierbare SW-Komponenten eingesetzt werden, um Flexibilität zu erreichen.
Das Zieleinsatzgebiet der vorliegenden Erfindung sind alle Echtzeit-datendominierten Anwendungen, welche große Mengen von komplexen Datentypen behandeln. Dies geschieht sowohl in Echtzeit-multidimensionalen Signalverarbeitungsanwendungen (RMSP), wie Video und Bildverarbeitung (die indizierte Feldsignale verarbeitet, üblicherweise in Zusammenhang mit Schleifen), als auch in anspruchsvollen Kommunikationsnetzwerk-Protokollen (die große Sätze von Einträgen, welche in Tabellen und Zeigern organisiert sind, behandeln). Beide Klassen von Anwendungen beinhalten viele wichtige Anwendungen, z. B. Videocodierung, medizinische Bildarchivierung, Multimedia-Endgeräte, künstliches Sehvermögen, xDSL-Modems, ATM-Netzwerke und LAN/WAN-Technologie. Experimente haben deutlich die datendominierte Eigenschaft von ausschlaggebenden Modulen in diesen Anwendungen gezeigt.
Als Ausgangspunkt für die Ausführungsformen der vorliegenden Erfindung werden einige Annahmen und Grundtatsachen verwendet. Der Stromverbrauch von Prozessoren steigt stark an und bewegt sich rasch in die Speicherung (Daten- und Programmspeicher) und teilweise auch in Transfers (Kommunikation und I/O), wie bereits oben gezeigt wurde. Durch das Benutzen eines einfachen Hardware-Befehlscaches kann der Beitrag des Mikrocodes in der Zielvorgabe für die Stromaufnahme für Multimedia- Anwendungen vernachlässigbar gehalten werden, weil diese hauptsächlich aus stark verschachtelten Schleifen mit relativ großen Grenzen bestehen. Daher kann die meiste Zeit die Verbindung zu dem Hauptprogrammspeicher heruntergefahren werden. Dann wird angenommen, dass das Cache verteilt ist und die verschiedenen Teile so nahe wie möglich zu den Stellen auf dem Chip angeordnet sind, wo die decodierten Steuerbits in dem Prozessor benutzt werden müssen, d. h. nahe der funktionellen Einheit (FU), für die das eingesetzte Befehlsfeld gilt. Ansonsten nimmt die Verteilung eines weiten Steuerbusses (insbesondere für Prozessoren mit besonders großer Befehlsweite, "very large instruction width processors") zu viel On-Chip Leistung auf. Hierbei sollte Acht gegeben werden, unnötigen doppelten Decodierzuschlag an den funktionellen Einheiten (FU) lokal zu vermeiden, so sollte eine gute gruppenweise Anordnung dieser Einheiten, die ein lokales Cache und den entsprechenden Decoder teilen, angestrebt werden. Moderne Off-Chip-(S)DRAMS bieten bereits stromsparende Lösungen, jedoch ist dies nur möglich, wenn sie im Burst-Mode mit großen Datenbreiten arbeiten. Dies ist nicht mit der eigentlichen Nutzung der Daten in den Prozessordatenpfaden kompatibel, so dass eine hierarchische und typischerweise leistungshungrige zwischenliegende bzw. intermediäre Speicherorganisation benötigt wird, um den zentralen DRAM mit den Datenanfrage- und Bandbreitenanforderungen der Prozessordatenpfade abzugleichen. Das Absenken des Stromverbrauchs in schnellen wahlfreien Speichern ist sättigend, weil bereits die meisten Schaltungs- und Technologietricks angewendet wurden und die grundlegende verbleibende Einschränkung im Transport der Daten und der Steuerung (wie Adressen und interne Signale) über große On-Chip-Strecken liegt.
Aus der Beobachtung, dass der Stromverbrauch von SW-Lösungen und ebenso die Geschwindigkeitsleistung gegenüber der HW-Entsprechung erheblich schlechter sind (in der Praxis werden 2 bis 3 Größenordnungen von Unterschieden in dem Produkt aus Energieverbrauch und Verzögerung beobachtet), können einige einzelne Schlüsselpunkte der vorliegenden Erfindung aus einem oder mehreren der folgenden Punkte zusammengefasst werden:

– Einführen eines Synchronisationsprotokolls zwischen einem zweckbestimmten HW-Prozessor (CP) und einem programmierbaren Befehlssatzprozessor (IP) zur Unterstützung einer sehr geschwindigkeits- und energieeffizienten Kontextumschaltung zwischen den beiden Seiten (erste Ausführungsform). Dies bietet etwas Flexibilität, die Arbeitsweise nach dem endgültigen Design zu ändern, z. B. geschieht die Ausführung aller Tasks bzw. Aufgaben anfänglich auf dem CP, und die notwendigen modifizierten Routinen werden dann zu dem IP verschoben (für den modifizierten Betrieb) unter der Bedingung, dass die Daten für diese Routinen in dem gemeinsam benutzten Adressraum des IPs und des CPs zugänglich sind.
– Und/oder Bereitstellen von verschiedenen Alternativen zum Abgleichen des Protokolls auf verschiedene existierende SW-Prozessorarchitekturen mit Befehlssätzen (Varianten der ersten Ausführungsform).
– Und/oder Vergrößern des geteilten Adressraumes von IP und CP auf eine energie- und geschwindigkeitseffiziente Weise durch Anwenden eines speziellen Schaltnetzwerks (zweite Ausführungsform). Dies reduziert die Granularität, mit der Kontextumschaltungen geschehen können, und dies kann daher den Aufschlag durch Verschieben von Operationen an den IP deutlich reduzieren.
– Und/oder Bereitstellen einer Design-Methodik, die an datendominierten Anwendungen orientiert ist, zum Entscheiden, welche Kompromisse zwischen den vielen Varianten im Zusammenspiel bzw. in der Kooperation zwischen IP und CP eingegangen werden.
– Und/oder Einführen eines domänenspezifischeren Speichers und Kommunikationsorganisation auf der IP-Seite (dritte Ausführungsform). Dadurch wird eine stark verteilte und teilweise spezifisch angepasste Speicher-/Bus-/Adress-Architektur eingebunden, welche den Datentransfer und die Speicherung für die datendominierten Routinen auf stärker energie- und geschwindigkeitseffiziente Weise gestaltet.
– Und/oder Ermöglichen von flexibleren, wiederverwendbaren Komponenten durch das Zufügen eines kleinen IP-Prozessors, der auf die oben beschriebene Weise mit dem spezifisch angepassten Prozessor kooperiert. Das Verhalten der wiederverwendbaren Komponente kann dennoch teilweise bei deren Einbetten modifiziert werden, ohne einen deutlichen Verlust in Energie- und Geschwindigkeitseffizienz in Kauf zu nehmen (vierte Ausführungsform).

Die herkömmliche Konfiguration zur Kooperation bzw. dem Zusammenspiel zwischen Algorithmusteilen, die SW- und HW-Prozessoren zugeordnet sind, ist in 5 gezeigt. Die Partitionierung zwischen den SW-Prozessoren SW 1, 2 und den Hardware-Prozessoren 3, 4 ist üblicherweise nicht vollständig, so dass typischerweise die Puffer 5–8 an den Rändern zwischen den SW- und HW-Prozessoren 1–4 angeordnet sind, um einen Datensequenzversatz um diese Schnittstellen herum zu kompensieren. Es kann Systemebenen-Speichermanagement (SLMM) genutzt werden, um eine Trennung zwischen HW- und SW-Prozessoren einfacher zu entwerfen. SLMM kann entsprechend der Schnitte, die zwischen SW und HW gemacht werden können, einige Randbedingungen für die genauen Stellen in dem globalen Algorithmus bedingen (z. B. durch einen Steuerungs-/Datenflussgraph oder CDFG). Programmcode-Transformationen, Speicherzuordnung und Cache-Speicheroptimierung können mit der vorliegenden Erfindung vorteilhaft verknüpft werden, um eine optimale HW/SW-Partitionierung und ein HW- und/oder SW-Prozessorspeicherdesign zu schaffen, siehe beispielsweise US 6,064,819 , Titel: "Control flow and memory management and optimisation", und US 5,742,814 , Titel: "Background memory allocation for multi-dimensional signal processing", die korrespondierende eingereichte europäische Patentanmeldung EP 867 808 , "Method and apparatus for size optimisation of storage units" und die Artikel "Code transformations for low power caching on embedded processors", Kulkarni et al., Int. Parallel Proc. Symposium (IPPS), Orlando, Florida, S. 292–297, April 1998; "Efficient functional validation of system loop transformations for multi-media applications", Cupak et al., Proc. Electronic Circuits and system conference, Bratislava, Slavkia, S. 39–43, Sep. 1997; "Functionalvalidation of system level loop transformations for power efficient caching", Cupak et al. Proc. Wsh. on System Design Automation, Dresden, Deutschland, März 1998.
Erste Ausführungsform
Gemäß einer ersten Ausführungsform der vorliegenden Erfindung wird eine Prozessorarchitekturlösung vorgeschlagen, um einen energieeffizienteren, flexiblen Prozessor zu erreichen, beispielsweise auf einem programmierbaren Prozessor oder einem wiederkonfigurierbaren Logikschaltkreis. Der Einfluss auf die Prozessorarchitektur ist sehr niedrig und bedingt lediglich die Bereitstellung einiger Befehle in dem Prozessorbefehlssatz, um eine feinmaschige Synchronisierung und einen Datenaustausch mit der spezifisch angepassten Hardware-Seite zu ermöglichen. Im Allgemeinen ist die Wiederbenutzung von bestehenden Prozessorkernen, die intern so wenig wie möglich modifiziert werden, während dennoch die gewünschten Energie- und Geschwindigkeitsvorteile erreicht werden, ein Vorteil dieser Ausführungsform. Um teilweises Stromsparen zu ermöglichen und einen Teil des Datentransfer-bezogenen (Leistungs-/Stromverbrauchs-)Engpasses zu beheben, können einer oder mehrere spezifisch angepasste Prozessoren 21 (CP) mit einem oder mehreren On-Chip-Prozessorkernen 22 (Befehlssatzprozessor, IP) kombiniert werden, was zu der schematisch gezeigten Lösung in 6 führt. Es wird angenommen, dass sowohl IP 22 wie auch CP 21 eine selektive Power-up/down- bzw. Hoch- und Herunterfahrmöglichkeit aufweisen. Diese Lösung kann durch das Installieren eines speziellen Wechselwirkungsprotokolls zwischen den SW- (IP, 22) und HW-Teilen (CP, 21) und durch geeignetes Verteilen der Aufgaben bzw. Tasks über die Befehlssatzprozessoren (IP, 22) und den spezifisch angepassten Prozessoren (CP, 21) in Abhängigkeit von den gegebenen Anwendungsvorgaben während der Laufzeit wiederprogrammierbar ausgeführt werden. Diese Situation ist recht verschieden von den kürzlich eingeführten herkömmlichen HW-"Slave"-Prozessoren, die mit SW-Master-Prozessoren oder den auf MMX-Typen-SIMD-basierten funktionellen Einheiten, welche in herkömmlichen RISC-Prozessoren eingebettet sind, kooperieren. Es sei auch anzumerken, dass die ursprüngliche CP-Architektur (6) vollständig auf die entsprechende Anwendung optimiert ist (es müssen keine Kompromisse eingegangen werden), so dass im Vergleich zu einer IP-Abbildungslösung (auch wenn diese vollständig optimiert ist) typischerweise eine Steigerung um ein bis zwei Größenordnungen in Bezug auf Energie- und Flächeneffizienz dieser Lösung erwartet werden kann.
Anfänglich werden alle datendominierten Aufgaben dem CP 22 zugewiesen. Falls eine Änderung an einen oder an mehrere (kleine) Teile des ursprünglichen Algorithmus angebracht werden müssen, wird diese Routine zu IP 21 verschoben. Dies bedingt eine Kontextumschaltung, wobei die relevanten Daten zwischen dem IP 21 und dem CP 22 übergeben werden müssen. Bei vielen herkömmlichen Ansätzen geschieht dies durch Übergeben einer Nachricht, was das Kopieren von Daten aus dem CP-Speicherbereich in den IP-Bereich bedeutet. Dies hat zu viele Datentransfers und einen Leistungsverlust zur Folge. Die erste Ausführungsform verfolgt eine Philosophie des gemeinsam benutzten Speichers. Falls der Einfluss auf die IP-Architektur so niedrig wie möglich gehalten werden soll, kann dies durch Belassen der relevanten Daten in dem Hauptspeicherbereich 23 des IPs 22 und durch gemeinsames Benutzen dieses mit dem CP 21 (6) erreicht werden. Dies bedeutet auch, dass die bevorzugten Punkte im Algorithmus, an denen der Kontext umgeschaltet werden kann, mit den Zuständen, wo alle relevanten, nicht temporären Daten in dem Hauptspeicher 23 vorliegen, zusammenfallen. Das bedeutet, dass eine Kontextumschaltung zwischen CP 21 und IP 22 am effizientesten ist, wenn keine Daten in den IP 22 kopiert werden müssen, sondern die für den IP 22 notwendigen Daten zum Fortsetzen dessen Verarbeitung zu dem Zeitpunkt der Kontextumschaltung in dem gemeinsamen Speicher 23 zugänglich sind. Dies führt deutlich zu einer Einschränkung der Energie- und Geschwindigkeitseffizienz dieser Ausführungsform: Zusätzlich zu den Anweisungen des Algorithmus, die verschoben werden müssen, weil sie modifiziert sind, muss auch der darum herum angeordnete Code bis zu den Punkten verschoben werden, wo die relevanten Daten gemeinsam benutzt werden, sowohl rückwärts (zu den Eingaben) und vorwärts (zu den Ausgaben). Dies ist in 7 in Form eines Diagramms beschrieben. Die Verarbeitung auf HW2 kann zu SW2 umgeschaltet werden, wenn die relevanten Daten für die neuen Routinen auf SW2 über die Zugänge 9 auf den Hauptspeicher 23 zugänglich sind. Offensichtlich wird hier ein Kompromiss eingegangen. Falls sehr wenige Punkte in dem Algorithmus vorliegen, an denen alle notwendigen Daten in dem Hauptspeicher 23 zugänglich sind, ist die Granularität sehr grob, und der Geschwindigkeits- und Energieaufschlag durch das Bewegen von Code von HW 21 zu SW 22 ist wegen des großen Unterschiedes im Energie-Verzögerungsprodukt zwischen diesen zwei Lösungen erheblich. Durch das Ergänzen von zusätzlichem Code in dem Anfangsteil, der dem CP 21 zugeordnet ist, kann mehr Freiraum und eine etwas feinere Granularität geschaffen werden, wobei CP 21 Kopien der relevanten Daten in dem Hauptspeicher 23 macht. Allerdings wird dann ein Aufschlag in Datentransfer und Speicherung auf der HW-Seite zugefügt. Gemäß einem Aspekt der ersten Ausführungsform des vorliegenden Erfindung wird der Hardware-Controller des CP 21 "intelligenter" gestaltet, sodass er nur dann diese Kopien zufügen kann, wenn sie wirklich benötigt werden (z. B. wenn der Zugangspunkt für eine Kontextumschaltung benötigt wird). Unter diesem Gesichtspunkt der vorliegenden Erfindung kann der Aufschlag bzw. Overhead stark vermieden werden. Wenn einige der Routinen in dem CP 21 von dem IP 22 übernommen werden müssen, beginnt die Gesamteffizienz nachzugeben, jedoch verbleibt diese Ausführungsform sehr vorteilhaft, solange ein kleiner Teil, d. h. nicht mehr als etwa 10%, des Algorithmus von CP 21 nach IP 22 transferiert werden muss.
Da es nicht einfach ist, einen besten Kompromiss zwischen diesen konkurrierenden Punkten auszuloten, wird vorzugsweise eine Werkzeugunterstützung (tool support) bereitgestellt wird, um Energie- und Geschwindigkeitsabschätzungen auf Systemebene zum Vergleichen der vielen verschiedenen Alternativen vorzuhalten. Insbesondere kann die Methodik zur Bestimmung des Kompromisses gemäß einer weiteren Ausführungsform der vorliegenden Erfindung geschehen:

1. Bestimmen der optimiertesten Datentransfer- und Speicherarchitektur (DTSA) in der anfänglichen HW-Lösung. Außerdem Berechnung der Energie-/Flächen-/Zeiteigenschaften dieser DTSA unter Benutzung von existierenden bekannten Schätzwerten.
2. Modifizieren der anfänglichen DTSA durch Zufügen z. B. von Zusatzkopien des Hauptspeichers 23 oder Verändern der genauen Wechselwirkung zwischen dem IP 22 und dem CP 21. Erneutes Berechnen der E/F/Z-Eigenschaften und Entscheiden, ob die Modifikationen akzeptabel sind.
3. Verschieben einiger Routinen von CP 21 zu IP 22 und Berechnen der E/F/Z-Eigenschaften. Bestimmen des endgültigen Kompromisses zwischen dem größeren folgenden Verlust, der mit der größeren Granularität zusammenhängt, und dem größeren anfänglichen Verlust, der mit Zusatzkopien (potenziell teilweise reduziert durch einen komplexeren Hardware-Controller bzw. Hardware-Steuerung) zusammenhängt.

Es ist zu beachten, dass dem IP 22 nicht notwendigerweise nur die Aufgabe des Back-ups des CP 21 zugeordnet sein muss, wenn die Routinen verschoben werden müssen. Es kann zeitlich mit anderen normalen Aufgaben, die der SW zugeordnet sind, gemultiplext werden. Jedoch, je weniger Zeit er mit normalen Aufgaben nicht in Betrieb ist, desto weniger Freiraum besteht selbstverständlich, um Routinen von der CP-Seite aus zu verschieben. Also muss auch hier ein Kompromiss im Design eingegangen werden. Falls der IP 22 vollständig dem CP 21 gewidmet ist, sollte der Flächenaufschlag im Vergleich zu dem CP 21 vernünftig sein. In diesem Fall fällt die bevorzugte Wahl auf einen dazu zugeordneten ASIP (application-specific instruction-set processor = anwendungsspezifischer Befehlssatzprozessor), welcher zur Unterstützung der Routinentypen, welche in dem CP 21 vorliegen, zweckbestimmt ist. Solch ein ASIP kann sehr flächengünstig gebaut werden, und auch der Stromverbrauch kann angemessener gehalten werden als typischerweise für bestehende Multimedia-Prozessoren für den allgemeinen Gebrauch benötigt wird. Falls der IP 22 auch aus anderen Gründen (tasks) benötigt wird, wird der Flächenzuschlag sowieso zumutbarer. Es ist zu beachten, dass, um eine vollständige Energieeffizienz zu erhalten, sowohl CP 21 wie auch IP 22 vorzugsweise wirkungsvolle Stromsparmodi aufweisen, so dass sie keinen Strom verbrauchen, solange sie nicht nützliche Operationen ausführen. Dies kann die Anwendung von Clock-Gating-Maßnahmen beinhalten. Auch das Taktverteilungsnetzwerk ist vorzugsweise für den CP 21 und den IP 22 getrennt. Die 2 Takte können zur globalen Synchronisation von demselben Master-Takt abgeleitet werden, falls dies gewünscht ist, es ist jedoch nicht wesentlich. Prinzipiell kann das "synchrone Inseln in einem asynchronen Meer"-Konzept angewendet werden, wo 2 Master-Takte vorhanden sind und wo die lokale Synchronisation zwischen den verschiedenen synchronen Inseln durch Handshaking und eventuell einen kleinen Puffer gewährleistet ist. Selbstverständlich ist die durchschnittliche Rate, mit der Daten kommuniziert werden, vorzugsweise auf beiden Seiten der asynchronen Schnittstelle identisch, um einen nicht annehmbaren Pufferaufschlag zu vermeiden.
Diese erste Ausführungsform ist einfach auf eine Situation erweiterbar, wo mehrere CPs 21 vorliegen, jeder mit seinem eigenen angepassten Master-Controller. In diesem Fall muss der IP (welcher ebenfalls mehrfach vorliegen kann) diesem gleichzeitig folgen. Dieser Umstand ist selbstverständlich dann erforderlich, falls der ursprüngliche Algorithmus gleichzeitige Prozesse beinhaltet. Insbesondere, falls diese nicht statisch während des HW-Abbildens zeitlich eingeplant werden können, ist dies unvermeidbar. Die dynamisch zeitlich eingeplanten Prozesse sind dann vorzugsweise auf verschiedene CPs 21 verschoben, welche auf die übliche Art und Weise miteinander interagieren, um den Algorithmus auszuführen, welche jedoch individuell durch die IP(s) 22 mit dem speziellen Protokoll gemäß der vorliegenden Erfindung überwacht werden.
Ein beispielhaftes Protokoll für die Unterstützung der obigen Wechselwirkung kann 4 Phasen aufweisen und wie folgt (siehe 8) aussehen. Angenommen, eine Routine 34 oder ein Teil einer Routine muss von dem CP 21 zu dem IP 22 (M3 in 9) verschoben werden. Daraus wird der allgemeine Fall einfach abgeleitet. Es ist zu beachten, dass der Designer vollständig Kenntnis hat und steuern kann, was der CP 21 enthält und welches Programm auf dem IP 22 abläuft.
Dies ist wichtig, um eine effektive Synchronisation zu erreichen. Im Folgenden ist eine Beschreibung von weiteren Gesichtspunkten dieser Ausführungsform dargestellt.

1. Damit der IP 22 nicht zu wenig ausgelastet wird oder der Zeitverlust vergrößert wird während die Routine von CP 21 zum IP 22 verschoben wird, ist der IP 22 vorzugsweise vollständig mit dem CP 21 synchronisiert. Dies ist wichtig, um eine relativ feinkörnige Kontextumschaltung zwischen CP 21 und IP 22 zu erreichen. Falls die auf dem CP 21 und IP 22 ablaufenden Routinen sehr einfach sind und keine komplexen Datentypen aufweisen, ist das vorgeschlagene Protokoll üblicherweise zu aufwändig, und ein einfacheres (modifiziertes) Master-Slave-Protokoll kann, wie es in den unten angegebenen Beispielen erklärt ist, welche als Modifikationen des ersten Ausführungsbeispieles beschrieben sind, angewendet werden. Wenn der Code auf dem CP 21 nicht datenabhängig ist, kann dies einfach erreicht werden, weil der genaue Zyklus, in dem die Kontextumschaltung geschehen soll, bekannt ist. Der IP 22 kann einen Zähler (z. B. durch eine Interrupt-Routine ausgeführt) aufweisen, welcher sicherstellt, dass er die Kontextumschaltung an dem richtigen Zyklus startet. Diese Situation liegt jedoch oft bei komplexen Multimedia-Routinen nicht vor, wofür die vorliegende Ausführungsform hauptsächlich vorgesehen ist. Diese Anwendungen enthalten viele datenabhängige Bedingungen, insbesondere wegen des Umschaltens zwischen verschiedenen Betriebsmodi. Diese Bedingungen sind oft relativ grobkörnig. Um den Übergang des CP 21 durch seine Codes zu verfolgen, liefert der CP 21 dem IP 22 entsprechend einer Ausführungsform der vorliegenden Erfindung gerade genügend Daten, die ihn in die Lage versetzen, den Kontextumschaltpunkt zu bestimmen. Beispielsweise werden genügend Daten darüber geliefert, welche der datenabhängigen Zweige genommen wurden, so dass der exakte Zyklus zum Steuern des Zählers in der Interrupt-Routine für die Kontextumschaltung anhand von Merkern berechnet werden kann. Die Merker bzw. Flags können durch das Laden von geeigneten Merkern in Register 29, welche Teil des IP-Registerraumes (siehe 9) sind, zugänglich gemacht werden. Falls auf solche Register 29 in dem IP 22 nicht von außerhalb zugreifbar ist, kann dies alternativ durch Schreiben auf den Hauptspeicher 23 erfolgen, wobei jedoch der Aufschlag durch das Zugreifen auf diese einfachen Merker viel größer ist und der Zeitverlust der Kontextumschaltungen deutlich ansteigt. Der IP 22 überprüft diese Merker regelmäßig, um den Fortschritt des CP 21 zu verfolgen. Das Zeitfenster 29b, in dem diese Merker zugänglich sind, ist üblicherweise relativ groß, insbesondere wenn genügend Registerzellen vorhanden sind (siehe 9), sodass der zeitliche Ablauf des genauen Zyklus des Zugriffs nicht kritisch ist und auf einen geeigneten Zeitpunkt festgesetzt werden kann, während andere gleichzeitige Aufgaben ausgeführt werden. Dies kann beispielsweise geschehen, wenn der Teil der IP-Einheit 22, welcher die Überwachung der Register übernimmt, wegen einiger Datenabhängigkeiten in dem ausführenden Task, welcher alles bis auf die Speichertransfereinheit des IP 22 aufhält, im Leerlauf ist. Die während des vollständigen Überwachungsprozesses (welcher üblicherweise häufig ausgeführt werden muss) abgelaufene Zeit sollte jedoch auf ein Minimum reduziert werden, damit der Aufschlag bei diesem Protokoll minimiert wird. Vorzugsweise geschieht eine dichtere (häufigere) Kontrolle des Status der Merker kurz vor der festgesetzten Kontextumschaltung (siehe 8, erhöhtes Überwachen im Prozess 32 kurz vor Kontextumschaltung auf neuen Code 33), um dem CP-Fortschritt nahe zu folgen. Es ist anzumerken, dass eine Reihe von vereinfachenden Fällen existieren, wovon jeder einen einzelnen Gesichtspunkt der ersten Ausführungsform der vorliegenden Erfindung darstellt. Z. B. muss das Überwachen nicht Zweige aufweisen, die nicht wieder zu dem Pfad konvergieren, welcher zu der ausgewählten Kontextumschaltung führt. Dies ist klar, weil sie nie den Zyklus der ausgewählten Kontextüberwachung beeinflussen können. Auch wenn bestimmte Pfade wieder konvergieren, müssen die entsprechenden Merker nicht überwacht werden, solange der IP 22 den genauen Zyklus prüft, in dem der Wiederkonvergenzpunkt in dem CP 21 überquert wird. Dies erfordert eine kontinuierliche Abfrage über einen bestimmten Zeitraum, jedoch kann es dies wert sein, falls ein ausreichender Umfang von Überwachungen der Merker zu anderen Zeiten ignoriert werden kann und falls während des Zeitraums, in dem die Abfrage geschehen sollte, die Hardware des IP 22, welche die Abfrage durchführt, nicht sowieso beschäftigt ist. Es sei beispielsweise angenommen, dass der oberste Zweig mit den Optionen 0, 1, 2 in 9 und alle seine Unterzweige (3 .. 15) wiederkonvergieren, bevor der mit 0 bezeichnete Rand unterhalb der gestrichelten horizontalen Linie in 3, 4, 5 aufspaltet. Es sei ebenfalls angenommen, dass die Kontextumschaltung gerade nach der Bezeichnung 5 unterhalb der gestrichelten Linie erfolgt. Es kann dann lohnenswert sein, den Zyklus zu überprüfen, wenn der Zweig 0 an der gestrichelten Linie aufgespaltet wird. Es tritt eine abschließende Vereinfachung auf, wenn an einem bestimmten Knoten auf dem Pfad zu der Kontextumschaltung alle wiederkonvergierenden Pfade auf diesem Knoten genau dieselbe Anzahl von Zyklen haben. In diesem Fall spielt es keine Rolle, welche Zweigoption zuvor ausgewählt wurde. In der Praxis tritt eine solche Situation selten zufällig auf, sie kann jedoch gezielt durch Addieren von NOPs auf Nichtgleichgewichtspfade in Richtung der Wiederkonvergenzknoten erreicht werden. Der Aufwand dieser NOPs sollte mit dem Aufwand zur Überwachung der beteiligten Merker verglichen werden, sodass wieder ein Kompromiss im Design auftritt.
2. In dem Zyklus, in dem die Kontextumschaltung beginnen soll, welcher nun datenabhängig ist und welcher mit einem Punkt in dem Algorithmus zusammenfällt, an dem alle relevanten Daten zur Benutzung nach der Kontextumschaltung für den 22 in dem Hauptspeicher 23 erhältlich sind, unterbricht der IP 22 den CP 21 durch Senden eines geeigneten Ereignisses an den Master-Controller des CP 21. Dieser CP-Controller stoppt die Ausführung auf dem CP 21, und der CP 21 geht in einen Stromsparmodus.
3. Dann führt der IP 22 den geeigneten modifizierten Code aus, angefangen bei den Daten, welche an den Hauptspeicheradressen, welche beim Zusammenstellen des CP 21 vorbestimmt wurden. Nach dem Ausführen dieses Codes speichert er die Ergebnisse ebenfalls an vorbestimmte Adressen zurück in den Hauptspeicher 23 (siehe 8), wobei diese Daten für den CP 21 zur Aufnahme der weiteren Verarbeitung bereitliegen. Dies erfordert vorzugsweise das Vorhandensein eines DMA-(Direct-Memory-Access = Direktspeicherzugriffs)-Modus 24 (siehe 6) oder eines Modus, der äquivalent zu einem direkten Adresszugriffsmodus ist. Dann startet der IP 22 den CP Master-Controller und liefert ihm Informationen darüber, wie viele "Schritte" in dem ursprünglich zugewiesenen Code übersprungen werden sollen. Dies kann wieder auf verschiedene Wegen geschehen, wobei jeder ein einzelner Gesichtspunkt der vorliegenden Erfindung ist. Der energie- und zeiteffizienteste Weg besteht wahrscheinlich darin, ihm spezielle Daten (Konstanten) zu senden, welche direkt von dem CP-Controller in den gewünschten Zustand seines Master-Zustandsgraphen codiert werden können. Es ist anzumerken, dass dieser Zustandsgraph nur einen begrenzten Satz von Zuständen beinhalten muss, nämlich diejenigen, welche all denjenigen Punkten im Algorithmus entsprechen, an denen die Kontextumschaltungen erlaubt sind. Diese Daten können durch zweckbestimmte Befehle, welche dem IP-Befehlssatz zugefügt sind, gesendet werden, oder es kann auf einen bereits bestehenden IP-Befehl zum Ausgeben von Konstanten auf den externen I/O-Bus zurückgegriffen werden. Gemäß der vorliegenden Erfindung kann dies sogar der Adressbus sein, wobei ein "Sofortadressierungs"-Modus genutzt wird. Alternativ kann der geeignete Programmzähler-(PC-)Wert von dem Speicherraum des IPs in den CP heruntergeladen werden. Das erfordert, dass alle möglichen PC-Werte in dem Hauptspeicher 23 vorhanden sind und einige Adressen und Speicherzyklen zur Ausführung dieses Prozesses benötigt werden. Dies ist üblicherweise weniger effizient und verursacht mehr Aufschlag auf das Protokoll.
4. Der CP 21 nimmt dann wieder seinen Normalbetrieb auf und fährt mit dem Algorithmus beginnend von den neuen Daten, welche in dem gemeinsam benutzten Hauptspeicher 23 abgelegt sind, fort. Der IP 22 geht in Stromsparmodus oder fährt fort/beginnt mit einer gleichzeitigen Aufgabe, welche der SW (1 in 7) zugewiesen ist.

Der Einfluss auf die CP 21- und die IP 22-Architekturen kann wie folgt zusammengefasst werden:

1. Der CP 21 benötigt einen zusätzlichen Master-Controller, welcher den oben genannten Zustandsgraphen, welcher nur die Punkte der potenziellen Kontextumschaltungen aufweist, umleitet. In einer Ausführungsform muss er ebenfalls die Merker an den IP 22 senden, um die datenabhängigen Zweige zu verfolgen. Er sollte auch aufgrund der von dem IP gesendeten "Überspringzustands"-Informationen zu den geeigneten neuen Zuständen springen können, nachdem der IP 21 seinen modifizierten Code beendet hat. Solch ein Master-Controller verbraucht sehr wenig Fläche und Energieaufschlag, und die Entwurfszeit ist sehr begrenzt, da er einfach aus einer Vorlage für eine verhaltensgesteuerte finite Zustandsmaschine (behavioral final state machine, FSM) abgeleitet werden kann. Die hauptsächliche Design-Zeit wird in der oben genannten Kompromissabwägung verbraucht, wo die Punkte von möglichen Kontextumschaltungen gesetzt werden sollen, jedoch auch diese Zeit kann (sehr) durch geeignete Design-Werkzeug Unterstützung zur Untersuchungsrückkopplung reduziert werden. hs müssen besonders genaue Höchstniveau-Zeitablauf- und Energieabschätzungen bereitgestellt werden, wodurch das Risiko einer (viel) weniger optimalen Auswahl begünstigt ist.
2. Der IP 22 hat vorzugsweise Register 29 zum Verfolgen der datenabhängigen Kontextumschaltungsmerker. Ferner muss er in der Lage sein, Daten über die zu überspringenden Zustände und den Power-down/up des CP 21 senden zu können, vorzugsweise durch direkt übermittelte Konstanten (und nicht über die Speichereinheiten 23).
3. Um die Wechselwirkung zwischen dem IP 22 und dem CP 21 vollständig zu synchronisieren, ist es wichtig, dass an kritischen Zeitpunkten, d. h. besonders am Beginn und Ende der Kontextumschaltung, der Zeitablauf des IP 22 streng kontrolliert werden kann. Daher sollte soweit als möglich die Benutzung der Hardware-Interrupt-Kanäle und des Hardware-bezogenen Caching, was einen schwer kontrollierbaren Zeitaufschlag bedingt, vermieden werden, insbesondere während der Phase 3 des Protokolls. Dadurch wird auch der globale Zeitverlust einer jeden Kontextumschaltung reduziert. Daher sollte der IP 22 vorzugsweise ein Software-gesteuertes Caching und eine sehr strenge Zeitablaufsteuerung unterstützen, damit die strikte Synchronisation mit dem CP 21 erleichtert wird. Es sollte ebenfalls DMA 24 für die Hauptspeicher oder ein äquivalenter Zugangsmodus vorhanden sein.
4. In Abhängigkeit von dem, was der vorhandene Befehlssatz bietet und wie kritisch die Zeitanforderungen für die Anwendung sind, können an der Befehlssatzprozessor-(IP 22-)Architektur Änderungen angebracht werden, um die Koordination mit dem CP 21 wie oben beschrieben zu verbessern. Selbst dann wird dieser Aufschlag bzw. Overhead im Allgemeinen klein bleiben. Viele Multimedia-Prozessoren oder sogar RISCs bieten eine ausreichende Befehlsvariabilität, um sogar ohne Änderungen das Protokoll auf angemessene Weise zu unterstützen. Falls ein ASIP genutzt werden kann, ist der Aufwandsaufschlag für das Anbringen dieser Modifikation vernachlässigbar, wie es unten anhand einer spezifisch angepassten ACUs in Wechselwirkung mit einem ASIP veranschaulicht ist.

Falls der Datenpfad des CP 21 (stark) gepipelined ist, sind mindestens drei Lösungen (von denen einige kombiniert werden können) vorhanden, um dies zu bewältigen, wovon jede Lösung einen Einzelgesichtspunkt der vorliegenden Erfindung darstellt:

1. Der IP 22 kann einfach warten bis die CP-Pipelines mit dem Bereitstellen der notwendigen Daten beendet sind und kann dann diese aus dem gemeinsam benutzten Adressraum 23 herauslesen. Das bedeutet etwas Aufschlag im Zeitablauf (Verzögerungen) und einige zusätzliche unnötige Operationen, die in den CP-Pipelines begonnen werden und zu einem kleinen Stromverlust führen. Es sei ebenfalls zu beachten, dass angenommen wird, dass die Daten in dem gemeinsam benutzten Adressraum 23 genügend lange vorhanden sind, um dem IP 22 das Lesen zu ermöglichen, was einfach erreichbar ist, weil der CP 21 in jedem Fall nicht aktiv ist.
2. Falls der Hardware-Controller des CP 21 etwas angepasst wird, kann er die unnötigen Operationen vermeiden, weil er zuvor das Signal zum Anhalten der Normaloperationen erhält.
3. Üblicherweise hat der IP 22 eine relativ kleine Busbandbreite auf den gemeinsamen Adressraum 23 verfügbar, was bedeutet, dass die Daten sowieso nicht alle zur selben Zeit herausgelesen werden können. Daher ist es üblicherweise die beste Wahl, mit dem Auslesen der Daten so bald zu beginnen, wie die ersten Pipelines beendet sind. Während die weiteren Daten aus den Pipelines kommen, können sie auch durch den IP 22 gelesen werden. Die Entscheidung zwischen den Alternativen hängt von dem Aufschlag in E/F/Z und der Entwurfszeit ab, und von dem System-Designer muss erneut ein Kompromiss gemacht werden.

Bei der herkömmlichen HW-SW-Kooperation werden nur "Slave"-HW-Beschleunigerdatenpfade oder -prozessoren in die Architektur eingefügt. Dies führt zu einer Master-Slave-(M-S-)Wechselwirkung. Es gibt zwei Hauptkategorien:

1. Es werden dem IP-Befehlssatz zweckbestimmte HW-Befehle zugefügt. Beispiele sind u. a. Intel's Pentium MMX oder die Erweiterungen in anderen RISCs, welche oben diskutiert wurden. Hier ist die Granularität der Umschaltung zwischen SW und HW auf die Ebene von relativ einfachen arithmetischen Befehlen begrenzt. In diesem Fall geht der Leistungs- und Geschwindigkeitsvorteil in einem Multimedia-Kontext weitestgehend verloren, weil der IP-Controller wiederum für den gesamten Datentransfer und Speicheraufgaben, welche die Hauptleistungs-(und Geschwindigkeits-)Engpässe für datendominierte Routinen aufweisen, verantwortlich ist. Das bedeutet auch, dass ein sehr intensives Zusammenspiel von Steuersignalen und anderen Daten zwischen den CP- und IP-Modulen erforderlich ist. Dies führt regelmäßig zu Engpässen. Es sei z. B. ein Teil eines Video-Verarbeitungsalgorithmus betrachtet, wo zunächst Daten in einer spaltenbasierten Form (aus Teilen) der Bilderrahmen und dann in einer spaltenbasierten Weise abgespeichert (und geholt) werden müssen. Für die erweiterten Multimedia-Befehle, welche fast immer darauf angewiesen sind, n Worte parallel zu verarbeiten, welche in 32- oder 64-Bit-Datenpaketen gepackt sind, bedeutet dies, dass die erste n-Wort-Packung zeilenweise geschehen muss und dann spaltenweise.
2. Verwendung eines spezifisch angepassten Beschleunigungsprozessors in Kombination mit einem Prozessor. Ein Beispiel ist die Verwendung der Direct-X-Technologie von MicroSoft^TM, wobei das Betriebssystem die HW auf einer angepassten Graphikkarte zur Ausbildung der Graphik-Pipeline benutzen kann, oder es kann dies in SW ausführen, wenn das vorhandene HW-Verhalten nicht für die gegebene Anwendung geeignet ist. Ein weiteres Beispiel ist das Vorliegen von HW-Beschleunigern auf vielen Multimedia-Prozessoren. Diese sind üblicherweise zur Graphikverarbeitung vorgesehen oder zum Beschleunigen von MPEG-Komponenten, wie Variable Längendekodierung (Variable Length Decoding), DCT und Ähnliches. Auch die Benutzung eines ARM-Prozessors und mehrerer Catheral-3-Beschleuniger (mit einem lokalen Controller) in einigen neueren VSDM-Experimenten unterstreichen dies. Alle diese HW-Einheiten haben einen Slave-Controller, wobei ihnen ein anfänglicher "Anstoß" den Beginn erlauben. Dies ist jedoch nicht ausreichend, um die feinkörnige Kontextumschaltung in der vorliegenden Ausführungsform zu ermöglichen. Die Steuerung ist auf die Granularität der "Slave-Routine" beschränkt, welche auf dem Beschleuniger ausgeführt wird, welche beispielsweise die H263-Bewegungsschätzung in einem MPEG4-Kontext sein könnte. In diesem Fall erfordert eine kleine Änderung innerhalb dieser 20+-Seitenroutine, dass die vollständige Routine auf die IP-Seite umgeschaltet wird, wo die herkömmlichen, leistungsaufnehmenden Datentransfer- und Speicherarchitekturen genutzt werden. Falls der HW-Prozessor in viele verschiedene Teile zur Vermeidung dieser Inflexibilität aufgebrochen wird, wird die Wechselwirkung des einzelnen IPs mit der Vielzahl von CPs zum Engpass in Bezug sowohl auf die Leistung (Kommunikation) als auch auf die Geschwindigkeit für datendominierte Anwendungen.

Eine wichtige Variante der zweiten Ausführungsform beinhaltet die Verwendung einer Master-Master-(M-M-)Wechselwirkung zwischen zwei vollständig erwachsenen, einzelstehenden "Stand-alone"-Controllern, wobei die IP-Seite die "allgemeinen" Steuerungen ausführt und die CP-Seite "anstößt", welche dann "auf intelligente Weise" auf diese Ereignisse basierend reagiert. Dies kann aus den oben genannten Gründen nicht durch die Verwendung von Slave-HW-Controllern nachempfunden werden. Es ist jedoch anzumerken, dass die Slave-befehlsbasierten oder prozessorbasierten Ansätze üblicherweise sehr akzeptabel in einem Kontext sind, wo hauptsächlich skalare oder Steuerverarbeitung durchgeführt werden muss, solange der Zeitausschlag der häufigen Wechselwirkung zwischen der CP- und IP-Seite annehmbar ist. Von dieser Situation rührt das Master-Slave-(M-S-)Konzept her, wobei bedauerlicherweise der Ansatz misslingt, wenn er auf komplexe datendominierte Routinen angewendet wird. Daher kann sich der Designer immer dann, wenn die Vorteile des M-M-Protokolls nicht klar sind (die Einsparungen sollten sorgfältig ausgewertet werden und die notwendigen Kompromisse zwischen den verschiedenen Design-Faktoren gemacht werden), dem M-S-Protokoll zuwenden. Dies wird in den Beispielen der spezifisch angepassten ACU-Wechselwirkung mit einem ASIP-Prozessor deutlich, sowohl für die M-M-(Master-Master-) als auch die M-S-(Master-Slave-)Ausführungsformen der vorliegenden Erfindungen wie es detailliert im Folgenden erläutert ist. Einer der Gründe, weshalb das M-M-Protokoll unvorteilhaft sein kann, liegt dann vor, wenn die Kosten der Synchronisation in feinkörniger Weise im Vergleich mit den erwarteten Einsparungen zu hoch werden. In den unten angegebenen Beispielen kooperiert eine spezifisch angepasste ACU mit einem verteilten. Controller mit einem ASIP-Master-Controller durch Zufügen eines speziellen Stand-alone-Controllers in die spezifisch angepasste ACU. Letzteres ermöglicht ein ähnliches Wechselwirkungsprotokoll wie es oben beschrieben, jedoch stärker zweckbestimmt (stripped down) ist. Daher kann der Zeitablaufplan des Assembler-Codes auf dem ASIP unabhängig von dem (vorbestimmten) HW-Laufplan erstellt werden, d. h. die HW kann teilweise an das ASIP-Timing angepasst werden. Dieses Zusammenspiel zwischen einer spezifisch angepasste ACU und einem ASIP wurde in den folgenden Beispielen zu einer flexiblen Kooperation zwischen jedem IP (mit Controller + ACUs + ALUs) und einer spezifisch angepassten ACU verallgemeinert. Die experimentellen Ergebnisse zeigen, dass der Ansatz mit einem vernachlässigbaren Flächen-/Energiezuschlag in der zusätzlichen Controller-Hardware funktioniert und dass die Kontextumschaltung zwischen CP und IP ohne einen echten Zyklusaufschlag geschehen kann. Dies erlaubt eine besonders feinkörnige Wechselwirkung.
Die erste Ausführungsform kann in Bezug auf ihren Gesamteinfluss wie folgt bewertet werden:

1. +: Flexibilität ist dort, wo sie gewünscht wird, bei einer Kompilierzeit mit annehmbarem Aufschlag in Geschwindigkeit und Leistung verglichen mit einer vollständig angepassten HW-Lösung erreichbar. Die sich ergebende Lösung ist viel effizienter als eine herkömmliche Lösung, wo der gesamte Code in Software geschrieben würde, um volle Flexibilität zu gewährleisten. Offensichtlich ist die Menge an Modifikationen in dem Programm durch den Aufschlag in der HW-SW-Kontextumschaltung und dadurch, wie viele (Ersatz-)Befehle der SW-Prozessorkern aufnehmen kann, begrenzt. In der Praxis wird dies jedoch selten ein Problem sein, weil die Hauptaufgabe darin besteht, Fehlerreparaturen (bug fixes) aufzunehmen, späte Änderungen in den durch Marketing bestimmten Anforderungen oder in den Multimedia-Standards aufzunehmen. Diese Modifikationen sind in ihrem Umfang fast immer sehr begrenzt.
2. +: Energie ist immer dann ziemlich gut optimiert, wenn in der ursprünglichen, vollständigen SW-Abbildung ein hoher Verbrauch vorlag, weil der größte Teil des datendominierten Codes auf stark optimierter HW-Architektur abläuft.
3. +: Geschwindigkeit aus denselben Gründe wie bei Energie ziemlich gut optimiert.
4. +: Flächenaufwand größer als HW-Lösung, weil ebenfalls ein (kleiner) SW-Prozessorkern vorgehalten werden muss, welcher jedoch von mehreren CPs geteilt werden kann.
5. –: Größere Entwurfszeit. Das Programmieren des IPs ist schwieriger (sorgfältige Synchronisation notwendig), im CP relativ komplexe Kompromisse zwischen Flexibilität und wo die Knoten im Algorithmus mit möglichen Schnitten anzubringen sind. Dieser Nachteil in der Entwurfszeit kann nahezu vollständig behoben werden durch die Verfügbarkeit einer Bibliothek mit Vorlagen, welche in den IP-Code einzufügen sind und mit Entwurfsuntersuchungsunterstützung zum Finden von guten Kompromissen in dem CP. Die Energie-Verzögerungs-Verbesserung kann im Vergleich zu einer vollständigen SW-Lösung bemerkenswert sein (zumindest eine Größenordnung, falls gut optimiert), und dies ohne echten Nachteil in der Flexibilität.

Beispiele für die erste Ausführungsform und davon abgeleitete Modifikationen
Datentransfer- und speicherintensive Anwendungen sind durch einen großen Umfang an Datenfluss- (Laden/Speichern) und Kontrollflussoperationen (Schleifen und bedingungsabhängige Zweige) gekennzeichnet, die Hintergrundspeicher (d. h. Video-RAM, Daten-Cache) erfordern. Hinter diesen Operationen verbirgt sich viel Arithmetik (Adressausdrücke und Bedingungstests), die sich auf die Berechnung und Auswahl der verschiedenen Zeiger bezieht, welche für die Speicherung notwendig sind. Diese Arithmetik, nämlich die Adressierung, wird bei dem Gesamtarithmetikaufwand dominant. Typischerweise schließt die Adressierung viele lineare und nichtlineare (z. B. polynominale) arithmetische Ausdrücke ein, wie man es in Spitzenmultimedia- und mobilen Kommunikationsanwendungen findet. In anderen Fällen schließt sie eine große Menge von relativ einfachen (linearen) arithmetischen Ausdrücken ein, die unter extrem strengen Randbedingungen ausgewertet werden müssen, wie man es in Netzwerkprotokoll-Verarbeitungsanwendungen (d. h. LAN/WAN, ATM) findet. Daher ist aufgrund der Komplexität ein großer Umfang von Arithmetik eingeschlossen, und wegen der sehr strengen Timing-Randbedingungen wird die Adressierung die hauptsächliche Ursache von Aufschlag in dem gesamten Ausführungsaufwand: Leistungsaufnahme, und insbesondere Geschwindigkeit.
Der Aufschlag an Aufwand dieser Arithmetik kann in der Praxis sehr effizient durch Ausnutzung von spezifisch angepassten Ausführungsalternativen reduziert werden. Dies gilt insbesondere für die Adressierung, bei der die Möglichkeiten, Systemebenenähnlichkeiten und Regelmäßigkeiten sowohl in Steuer- und Datenflüssen auszunutzen, bei weitem größer sind als in den "rein" Datenpfad-bezogenen Operationen, wodurch Durchbrüche in Geschwindigkeitsverbesserungen mit sehr niedrigem Einfluss auf Fläche und Energieverbrauch möglich werden.
Bei der Adressierung ist das meiste der Arithmetik zur Kompilierungszeit bekannt (naheliegend). Daher kann sie lokal in der Nähe der Speicheradressports erfolgen. Somit kann durch die Verwendung einer verteilten (spezifisch angepassten) Adressierungsarchitektur gemäß einer weiteren Ausführungsform der vorliegenden Erfindung ein erheblicher Anteil des Routing-Aufschlages, der typischerweise in speicherdominanten Architekturen vorliegt, vermieden werden. Jedoch erfordert diese Ausführungsform, dass die Adressierungseinheit von dem Systemprozessor physikalisch entkoppelt ist, beispielsweise bei einer spezifisch angepasste Adressberechnungseinheit (cACU, custom Adress Calculation Unit). Diese Partitionierungsstrategie führt üblicherweise zu besseren Gesamtresultaten, obwohl eine kleine Überlappung der Funktionalität in der Steuerlogik besteht. Z. B. gemäß einem Gesichtspunkt dieser Ausführungsform das gelegentliche Duplizieren von Zweigen, welche sowohl von dem Systemprozessor und der verteilten, spezifisch angepassten Adressberechungseinheit (cACU) berechnet werden. Auch die Komplexität des Systemcontrollers wird positiv beeinflusst, weil das meiste des Steuerflusses der Adressierung, zumindest der Offensichtliche, direkt durch die cACU verwaltet wird, wodurch der Systemprozessor-Controller von dieser Aufgabe befreit wird.
Jedoch wird durch das Entkoppeln der Adressierungsfunktionalität nicht nur an Effizienz gewonnen. Es bietet auch die Möglichkeit, flexiblere und (potenziell) ökonomischere Ausführungsalternativen (jede ist ein Gesichtspunkt der vorliegenden Erfindung) für die nicht adressbezogene Funktionalität auszuwählen und sie gleichzeitig mit energiegünstigen und Höchstleistungsumsetzungszielen für die Adressierung zu verbinden, und sie hat einen sehr geringen Einfluss auf die Prozessorarchitektur.
Gemäß eines weiteren Gesichtspunktes dieser Ausführungsform bieten anwendungsspezifische Befehlssatzprozessoren (ASIPs, Application Specific Instruction-set Processors) eine sehr feinkörnige (gleichzeitige) Kooperation mit der cACU durch ihre Einflussnahme sowohl auf den Befehlssatz als auch auf den Compiler. Für andere Befehlssatzprozessoren (IP) (RISC/DSP-Kerne und Multimedia-Prozessoren) kann das Vorhalten eines genügend großen Befehlssatzes zur Wiederbenutzung einiger der bestehenden Befehle (es werden insgesamt 3 benötigt, wie es in der ausführlichen Beschreibung dieser Ausführungsform der Erfindung beschrieben ist) ausreichend sein, um eine feinkörnige Kooperation zu erreichen.
Auch nachdem der Chip gefertigt wurde, besteht Flexibilität gemäß dieses Gesichtspunktes der zweiten Ausführungsform, weil jede neue oder modifizierte Adressierungsfunktionalität wieder von dem IP übernommen werden kann. Diese Lösung bleibt so lange effizient, wie der Umfang an zu modifizierender Adressfunktionalität nicht zu groß ist (typischerweise weniger als 10 bis 20%).
Die folgenden Ausführungsformen können eine effiziente, feinkörnige Kooperation zwischen einer cACU 31 und einem generischen IP 32 (10) bieten. Die Vorgehensweise ist teilweise aus dem Wechselwirkungsprotokoll, welches in der Beschreibung der zweiten Ausführungsform der Erfindung obig vorgeschlagen wurde, abgeleitet worden. Die Verwendung von verteilten, spezifisch angepassten Adressberechnungseinheiten (cACUs) 31 gemäß dieser Ausführungsform der vorliegenden Erfindung ermöglicht es, sehr strenge Zyklusvorgaben sowohl für die Speicheradressierungs-bezogene Arithmetik und den Steuerfluss mit sehr geringem Flächen-Energieaufschlag zu erfüllen. Dies gilt insbesondere für speicherintensive Anwendungen, die ziemlich viel komplexe Indizierung bedingen. In den meisten Fällen muss jedoch ein gewisser Grad von Flexibilität vorgehalten werden, um späte Änderungen oder Herstellungsspezifikationsänderungen aufzunehmen. Die benötigte Flexibilität kann durch Schaffen einer Methodik für feinkörnige Kontextumschaltung zwischen der cACU 35 und dem programmierbaren, Befehlssatz-basierten Prozessor (IP) 32 erreicht werden. Diese Ausführungsformen basieren auf zwei feinkörnigen, kooperativen Modellen für die Adressierung, erstens ein gleichzeitiges Master-Master-Modell, und zweitens ein nicht gleichzeitiges Master-Slave-Modell. Diese feinkörnige Kontextumschaltung erlaubt die Aufnahme neuer Funktionalität bei minimalem Energiezyklusaufschlag, so dass die Einsparung beim Verschieben einiger Adressen von dem IP 32 zu der cACU 31 weitestgehend aufrechterhalten wird.
Das Entkoppeln (von Teilen) der Adressfunktionalität von dem Rest des Systems bietet den Vorteil eines vollständig gleichzeitigen (Master-Master-)Kooperationsmodells gemäß dieses Gesichtspunktes der ersten Ausführungsform der vorliegenden Erfindung. Daher können dem IP 32 andere Aufgaben zugeordnet werden, während die cACU 31 die Verwaltung des (verteilten) Speichers 33 selbst übernimmt. Falls andererseits die cACU 31 nur ein "Slave" wäre, würde der IP 32 eine bedeutende Anzahl von Zyklen aufwenden, um lediglich die cACU 31 steuern, und wäre im Leerlauf, so lange wie die cACU 31 mit der eigentlichen Berechnung beschäftigt ist. Es ist bemerkenswert, dass der IP 32 ebenso einige der Speicherzugriffe selbst verwalten kann, insbesondere diejenigen, welche eine "einfache, billige" Adressierung erfordern, wodurch die Aufwandsdominanten der cACU 31 überlassen werden und ein gemischtes Kooperationsmodell ermöglicht wird.
Für Fälle, in denen nur wenige cACU-Operationen begonnen werden müssen, ist eine nicht gleichzeitige (Master-Slave-)Kooperation durch explizites Pipelining des cACU-Betriebs mit anderen IP-Operationen einige Zyklen bevor der Adresswert benötigt wird möglich. Für diesen Fall sind jedoch ausführliche Timing-(Zeitablaufs-)Informationen der IP-Operationen notwendig, welche zur Kompilierungszeit nicht immer abfragbar sind und welche durch ein vollständig gleichzeitiges Modell vermieden werden können. Für das gleichzeitige (Master-Master-)Modell werden hauptsächlich lediglich die Timing-Informationen über den eigentlichen Speichertransfer benötigt. Es ist dann nicht erforderlich, die IP-Zeitablaufsteuerung zu Pipeline-Betriebsabläufen zur expliziten Synchronisation mit der cACU 31 zu zwingen.
Sowohl Master-Master- als auch Master-Slave-Kooperationsmodelle für einen IP und eine cACU sind unabhängig voneinander in der vorliegenden Erfindung als Modifikationen der ersten Ausführungsform enthalten.
Um einen weiteren Aufschlag in der Kommunikation zu vermeiden, muss die Abfolge, in der die Speichertransfers von der cACU 31 verwaltet auftreten, zuvor entschieden werden, wodurch zur Kompilierungszeit die Abfolge der Ereignisse, welche auf dem Adressbus geschehen, bekannt sind. Ansonsten ist die Verwendung eines Master-Slave-Modells das einzig mögliche Kooperationsmodell, wobei der Master-IP 32 der Slave-cACU 31 angeben muss (mittels eines codierten Befehls), welche Adressausdrücke an dem Adressport bereitgestellt werden müssen, wodurch den IP-Ressourcen eine zusätzliche Last angetragen wird. Dieses Vorgehen gilt sowohl für Master-Master- als auch für Master-Slave-Modelle.
Um die vollständige Kooperation zwischen der cACU 31 und dem IP 32 zu erlauben, kann ein Kommunikationskanal 34 (siehe 10) zur Laufzeitkommunikation der Datenabhängigkeiten vorgesehen sein. Dieser Kanal 34 kann auf diesen bestimmten Zweck zugeschnitten werden. Für DSP- und RISC-Kerne kann einer dieser vorhandenen Datenbusse oder zugewiesene I/O-Ports benutzt werden. Der Vorteil der Verwendung eines zugeschnittenen Kanals 34 für die Kommunikation besteht darin, dass ein Beaufschlagen der existierenden Datenbusse vermieden wird. Daher wird der Zeitablaufsteuerung für die Speichertransfers mehr Freiheit überlassen.
Dieser Kommunikationskanal 34 ist auf zwei Zwecke zugeschnitten:

1. die Kommunikation der Daten, welche benötigt werden, um die cACU 31 über die Berechnung von bestimmten Adressausdrücken, die nicht-offensichtlichen Bedingungen unterliegen, entscheiden zu lassen; und
2. die Unterstützung der Adressumwegarithmetik (address indirection arithmetic)

Die gesamte Kommunikation zwischen dem Systemprozessor 32 und der cACU 31 ist daher hauptsächlich darauf zugeschnitten, nur Laufzeitdatenabhängigkeiten aufzulösen und explizit die Entwicklung beider Fäden bzw. Threads der Steuerung (des IP 32 und der cACU 31) zu synchronisieren. Für das Master-Master-Modell ist diese explizite Synchronisation auf bestimmte Punkte eingeschränkt, wo die eigentliche Funktionalität modifiziert werden muss (nämlich zu einer Kontextumschaltung), wie dies oben bezüglich der zweiten Ausführungsform der vorliegenden Erfindung beschrieben ist, d. h. eine Kontextumschaltung geschieht immer dann, wenn eine neue Funktionalität zugefügt oder bezüglich der ursprünglichen Version der Anwendung modifiziert wird, was bedeutet, dass einige Teile der ursprünglichen Funktionalität, welche der cACU 31 zugewiesen ist, von dem IP 32 (in einer modifizierten Form) übernommen werden.
Manchmal muss der IP 32 der Umleitung auf die cACU 31 folgen, insbesondere wenn datenabhängige bedingende Zweige lokal in der cACU 31 entschieden werden und die Kontextumschaltung innerhalb eines oder mehrerer von diesen erfolgen muss. Normalerweise hat der umgeleitete Pfad nicht ausgewogene bedingende bzw. konditionelle Threads zur Folge. Dadurch wird es sehr schwierig vorherzusehen, wann die Kontextumschaltung erfolgen sollte. Um gleichzeitig die nicht ausgewogene Entwicklung abzugleichen, sind verschiedene Entwurfsoptionen möglich, welche allesamt Teilaspekte dieser Ausführungsform der vorliegenden Erfindung sind:

1. Verwenden von zyklusrichtigen "Spiegeln" der bedingenden Bäume sowohl in cACU 31 als auch IP 32. Diese Lösung kann ineffizient sein, weil beide Spiegelkopien mit derselben Rate fortschreiten müssten. Daher wird entweder die Geschwindigkeitsleistung der cACU 31 begrenzt, um den langsameren IP 32 aufzunehmen, oder die Taktfrequenz des IP 32 muss ansteigen, wodurch die Gesamtleistungsaufnahme negativ beeinflusst wird.
2. Überwachenlassen der Zweigentwicklung der cACU 31 durch den IP 32. Dies kann sowohl durch Abfragen oder Software-Interrupt-basierte Mechanismen erfolgen, wobei beides Einzelaspekte dieser Ausführungsform der vorliegenden Erfindung sind. In beiden Fällen lädt die cACU 31 die geeigneten Merker (es wird ein Merker pro bedingendem Zweig genommen) in die Register, welche Teil des IP-Registerraumes sind, wie es in der obigen ersten Ausführungsform vorgeschlagen ist.

Diese Architektur erlaubt die Definition eines synchronen kooperativen Modells, welches hauptsächlich durch die Ordnung der Speicherzugriffe, welche der spezifisch angepassten Adressierung unterstellt sind, eingeschränkt wird. Andererseits können sowohl Leistungs- wie auch Aufwands-(Flächen/Energie-)Wirkungsgrade sehr beschränkt sein. Auch die Verwendung von abhängigen Takten, die aus demselben Systemtakt 35 abgeleitet sind, wird aus Gründen der Effizienz in der Synchronisation auf hohem Niveau zwischen Threads und Steuerung (der IP 32 und die cACU 31) benötigt. In den Master-Master-Architekturen beeinflusst dies die Synchronisation beider Zeitabläufe (IP 32 und cACU 31). In dem Master-Slave-Fall beeinflusst es das Pipelining der Operationen beider Blöcke. Im Falle von abhängigen Takten, die Taktversatzproblemen unterliegen, ist es möglich, ein Niedrigniveau-asynchrones Protokoll für die Kommunikation der Datenabhängigkeiten unabhängig von dem gewählten Modell zu benutzen.
Ein erstes Modell erlaubt eine gleichzeitige Master-Master-Entwicklung von den zwei Threads der Steuerung (einer für cACU 31 und einer für den IP 32). Dieses Modell ist ein Spezialfall des spezifisch angepassten Blocks, welcher in allgemeinerer Form oben in der ersten Ausführungsform der vorliegenden Erfindung beschrieben ist und für eine cACU 31 als eine individuelle Ausführungsform der vorliegenden Erfindung verbessert wurde. In diesem Fall geschieht die Synchronisation implizit durch Schätzen/Steuern, die vergangene Zeit zwischen den Speichertransfers ist jedoch zu der Kompilationszeit abhängig von der spezifisch angepassten Adressierung. Typischerweise dominieren bei Datentransfer-intensiven Anwendungen die Speicherzugriffe auf die langsameren Speicher das gesamten Systemtiming. Daher besteht eine Möglichkeit darin, sich auf den Speichertransfer zu konzentrieren und anzunehmen, dass der Compiler die Transfers zeitlich so plant, dass sie in derselben Ordnung wie in dem Originalalgorithmus verbleiben. Daher ist es durch die Steuerung des Compilers (wie es für einige ASIPs der Fall ist) möglich, vorherzusagen, wann der Speichertransfer stattfindet. Eine weitere Möglichkeit besteht darin, diese Zeitablaufinformation durch Analyse der Ausgabe des Zeitablaufplanes des Compilers zu sammeln. Dabei ist anzumerken, dass es nicht notwendig ist, alle Details des Zeitablaufplanes zu erhalten, sondern lediglich diejenigen, welche sich auf die Speicherzugriffsoperationen beziehen, die der spezifisch angepassten Adressierung unterliegen. In beiden Fällen werden keine Kontrollflussentscheidungen während der Laufzeit belassen (z. B. Hardware-Cache, Interrupts, etc.), um Modifikationen an dem Zeitablaufplan nach der Kompilierung zu verhindern.
Das zweite Modell erlaubt ebenfalls die gleichzeitige Kooperation zwischen den zwei Blöcken, wobei die Synchronisation jedoch durch die Verwendung eines Master-Slave-Modells explizit ist, wobei der IP 32 der Master des Steuerflusses ist. Der Vorteil dieses Modells liegt in dem einfachen Design. Der Nachteil besteht darin, dass der IP 32 mehr mit dem Steuern der cACU 31 beschäftigt ist und so keine anderen Aufgaben ausführen kann, während die cACU 31 mit der eigentlichen Adressberechnung beschäftigt ist oder während die Wechselwirkung auf Transferdaten abläuft.
Die Betriebsmodi des ersten Modells, d. h. ein Master-Master-Modell, wird nun (siehe 12A und B) als Ausführungsform der vorliegenden Erfindung beschrieben. Der zuerst beschriebene Modus ist der Normalbetriebsmodus (= normal operation mode). Dieser ist für die erste funktionelle Version der Anwendung vorgesehen, wo die cACU 31 implizit mit dem IP 32 an den Punkten, wo die Speicherzugriffe gemäß der spezifisch angepassten Adressierung erfolgen, synchronisiert ist.
Der zweite Betriebsmodus (modifizierter Betriebsmodus = modified operation mode) ist für "modifizierte" Versionen der ursprünglichen Funktionalität vorgesehen. Hier wird eine explizite Synchronisation für die Punkte, an denen die Kontextumschaltung erfolgt, bereitgestellt.
Während des Normalbetriebsmodus (11A) muss der IP 32 an die cRCU 31 alle notwendigen Datenabhängigkeiten kommunizieren, welche für die Adressumleitung oder die abhängigen Zweige notwendig sind. Diese Abhängigkeiten werden in einer vorgesehenen Registerdatei 38 innerhalb der cACU 31 (10) gespeichert. Der IP 32 "unterrichtet" die cACU 31 darüber, durch Aktivieren einer speziellen Steuerleitung (die data_ready-Leitung von 12 und 11) dass eine Datenabhängigkeit übertragen wurde.
Die cACU 31 startet die Berechnung der nächsten Adresse innerhalb der/des nächsten Zyklus/Zyklen, sobald die Datenabhängigkeiten, welche für die Berechnung der nächsten Adresse benötigt werden, empfangen wurden. Die cACU 31 "weiß", wie viele Datenabhängigkeiten während der Laufzeit kommuniziert werden müssen, weil der Zustandsstatus ihrer Master-Controller 37 bekannt ist und die Anzahl der Datenabhängigkeiten, welche für diesen bestimmten Zustand benötigt werden, auch zur Kompilierungszeit bekannt ist. Daher ist es notwendig, zur Kompilierungszeit zu wissen, in welchem genauen Zyklus jede der Datenabhängigkeiten kommuniziert wird. Die einzige Einschränkung für dieses Protokoll besteht darin, dass der IP 32 mit dem Kommunizieren aller Datenabhängigkeiten für den eigentlichen Speichertransfer beginnen muss, sobald der vorhergehende Speichertransfer geschehen ist.
Um einen weiteren Kompromiss zwischen Energie, Zyklus und Fläche während des Entwurfs der cACU 31 zu erlauben, kann der Adressausdruck in Unterausdrücke aufgespalten werden. Dann wird jeder Unterausdruck innerhalb eines Taktzyklus berechnet, und das Teilresultat ist in einem internen Register gespeichert. Da die cACU 31 auch zur Kompilierungszeit "weiß", wie viele teilweise Datenabhängigkeiten für die eigentliche teilweise Berechnung benötigt werden, ist es daher immer möglich, abzuwarten, bis alle teilweisen Datenabhängigkeiten transferiert wurden, und nur dann die teilweisen Berechnungen stufenweise durchzuführen.
Vorzugsweise sollte die relative Ordnung der kommunizierten Datenabhängigkeiten zur Kompilierungszeit bekannt sein, um einen Aufschlag in der Registerdatei zu verhindern, welche für das Abspeichern dieser Abhängigkeiten innerhalb der cACU 31 vorgesehen ist. Diese Bedingung ist jedoch nicht erforderlich, falls die Größe der Registerdatei 38 groß genug gemacht werden kann. Entsprechend dieser Ordnung platziert der cACU-Master-Controller die empfangenen Daten in die entsprechenden Register 38 immer dann, wenn der IP 32 der cACU 31 "mitteilt", dass ein neuer Datenwert in dem Kommunikationskanal bereitsteht. Dies wird möglich, weil sowohl der IP 32 als auch die cACU 31 "wissen", welches der nächste Vorgang (oder ein Satz aus möglichen Vorgängen im Falle von bedingenden Zweigen) ist, der auf dem Adressbus vorliegt. Daher kann die Zuweisung der Daten des Registers 38 zur Kompilierungszeit bestimmt werden.
Sobald der IP 32 alle für die Berechnung der nächsten Adresse notwendigen Datenabhängigkeiten mitgeteilt hat (inklusive derjenigen, welche für die Auswahl der bedingenden Zweige notwendig sind), fährt die cACU 31 fort, die Adresswerte in dem Zyklus bereitzustellen, in dem der IP 32 den eigentlichen Speichertransfer durchführen muss. Dies kann geschehen, ohne dass der IP 32 wissen muss, welches das eigentliche Buszugriffsprotokoll des zugegriffenen Speichers ist. Die cACU 31 nimmt dem IP 32 die Details des Transfers ab, insbesondere das Protokoll zwischen den Daten und den Adressbussen des zugegriffenen Speichers 42. Dies kann auf eine allgemeinere, spezifisch angepasste Speicherverwaltungseinheit (cMMU, customized Memory Management Unit) (selbst eine Ausführungsform der vorliegenden Erfindung) erweitert werden, welche nicht nur die Adressierung selbst durchführt, sondern auch die Übertragungen steuert, welche beim Verschieben von Daten von einer Speicherhierarchieebene zu einer anderen auftreten (ähnlich einem spezifisch angepassten Software-steuerbaren Cache).
Die Hauptvoraussetzung, eine vollständige Synchronisation zwischen dem IP 32 und der cACU 31 zu erreichen, besteht darin, die Entwicklung des IP 32 zur Kompilierungszeit für die Timing-Schätzung vollständig zu steuern. Deshalb sollten weder eine Laufzeitunterbrechung noch Laufzeit-Caching-Entscheidungen an den kritischen Zeiten der Wechselwirkung erlaubt sein. Dies kann sehr einfach erreicht werden, wenn ein ASIP als IP 32 eingesetzt wird, aber auch andere Kerne, wie DSPs oder auch Befehlssatz-basierte Mikrocontroller (ARM, etc.) können benutzt werden, indem (vorübergehend) ihre Laufzeiteigenschaften deaktiviert werden.
Der Normalbetriebsmodus ist in 11A dargestellt. Jeder Teil eines Codes zwischen zwei aufeinander folgenden Speichertransfers (nur denjenigen, welche zur Ausführung in der Hardware vorgesehen sind) definiert einen Superzustandsmodus. Die Entwicklung der Superzustände ist sowohl dem IP 32 wie auch der cACU 31, wie oben beschrieben wurde, bekannt. Der eigentliche Speichertransfer löst den Übergang zwischen Superzuständen aus. Alle notwendigen Datenabhängigkeiten werden innerhalb jedes Superzustandes ausgetauscht.
Die Synchronisation mit dem IP 32 geschieht implizit, weil die von dem IP 32 benötigte Zeit zum Berechnen des Codes für jeden Superzustand bekannt ist und zur Kompilierungszeit (T1, T2, T3, ...) steuerbar ist. Der IP 32 verhindert implizit die Planung von einer Operation bezüglich des komplexen Adressausdruckes in seiner eigenen ACU 45, weil ein entsprechender Lade-/Speicher(load/store)-Befehl zur Ausführung des eigentlichen Transfers benutzt wird. Die interne IP ACU (IP-ACU) 45 kann jedoch dazu benutzt werden, eine andere Adressberechnung anzustoßen, die genügend einfach ist, um dem IP 32 zugeordnet zu bleiben. Lediglich die cACU 31 muss den Zugriff der IP-ACU 45 auf den gemeinsam benutzten Adressbus deaktivieren, um Datenkollisionen (siehe 12) zu verhindern.
Sobald der Speichertransfer geschieht, ist die IP-ACU 45 wieder für den IP-Controller 44 zugänglich. Es ist auch zu beachten, dass die IP-Ablaufsteuerung 44 zwischen Superzuständen vollständig frei darin ist, jede Operation in ihrer internen ACU 45 für Speicherzugriffe vorzusehen, welche nicht ursprünglich von der cACU 31 verwaltet werden (z. B. diejenigen, die sehr effizient innerhalb der IP-ACU 45 ausgeführt werden können).
Veränderungen in der Ursprungsversion der Funktionalität, welche innerhalb der cACU 31 festgelegt ist, können sehr leicht in den programmierbaren Block (IP 32) eingefügt werden, solange die Prozedur zum Durchführen einer Kontextumschaltung von der cACU 31 auf den IP 32 vorgesehen ist. Dieses Verfahren wurde im Allgemeinen oben für die erste Ausführungsform der vorliegenden Erfindung beschrieben ist und wird hier für den Fall der Adressierung vertieft. Dieser funktionelle Modus ist als der modifizierte Betriebsmodus bekannt.
Das Verfahren zur Durchführung einer Kontextumschaltung beginnt immer dann, wenn der IP 32 der cACU 31 "mitteilt", dass eine Anzahl von Speichertransfers übersprungen werden sollte (skip-acu(2) in 11B). Dann überspringt die cACU 31 die spezifizierte Anzahl von Superzuständen und geht in einen Stromsparmodus. Sobald der modifizierte Code ausgeführt wurde, synchronisiert die IP 32 wieder mit der cACU 31 (start-acu), um hochzufahren, und setzt mit dem Normalbetriebsmodus fort. Der IP 32 kann die Entwicklung der bedingungsabhängigen Zweige der cACU 31 überwachen, indem er die vorgesehenen Merkerregister abfragt. Um eine derartige Überwachung ohne zu großen Aufschlag zu ermöglichen, ist die cACU 31 vorzugsweise in der Lage, auf den IP-Registerraum in dem Controller 44 zuzugreifen. Ansonsten muss die Übermittlung des bedingenden Zweigzustandes über Speicher 42 oder durch Einführen eines neuen Kommunikationsprotokolls über den bereits vorhandenen gemeinsam benutzten Datenbus 46 erfolgen, wodurch der cACU 31 erlaubt wird, Daten auf den Bus 46 abzuladen (siehe auch Beschreibung der ersten Ausführungsform oben).
Ein gleichzeitiges Überwachen der bedingten Umleitung der cACU 31 ist möglich, indem dem IP 32 erlaubt wird, den Status (Merker) der bedingten Zweige, welche in die cACU 31 abgebildet werden, zu überwachen, wie es bezüglich der ersten Ausführungsform der vorliegenden Erfindung oben beschrieben wurde. Die Überwachung der bedingten Umleitungen kann geschehen, indem dem IP 32 (zum Beginn eines Superzustandes, wo die Kontextumschaltung geschehen sollte) erlaubt wird, ein spezielles Register 47 zu befragen, worin jedes Bit den Zustand des Zweiges anzeigt, welcher ausgewählt wurde (siehe 13). Um ein Aufblähen der Registergröße zu vermeiden, könnte eine Anzahl dieser Register 47 benutzt werden, welche dann von verschiedenen Teilen des IP-Codes benutzt werden könnten. 13 zeigt eine Situation, in der eines dieser Register 47 zugewiesen wurde. Alternativ wird es von verschiedenen Codeblöcken gemeinsam benutzt, um das Zeitfenster, in dem verschiedene Merker der bedingenden Zweige der cACU 31 überwacht werden können, zu vergrößern. Dadurch wird deutlich ein Kompromiss zwischen der Registergrößer, der Anzahl der Register 47 und der Größe des Zeitfensters, welches für die Merkerüberwachung verfügbar ist, möglich, wie es oben in der ersten Ausführungsform der vorliegenden Erfindung diskutiert ist.
Um die Kontextumschaltung genau dann durchzuführen, bevor die cACU 31 gerade den Zweig, den der IP 32 übernehmen möchte, nimmt, wird ein Software-gesteuerter Interrupt benutzt. In diesem Fall besteht das Problem für den IP 32 darin, zu "wissen", in welchem genauen Zyklus er die cACU 31 unterbrechen sollte. Dieses Problem kann gelöst werden, falls die bedingenden Zweige, die einer Kontextumschaltung unterliegen, innerhalb der cACU 31 gleich ausbalanciert sind (dieselbe Anzahl von Zyklen). Daher ist der Zeitpunkt, an dem der Speichertransfer geschehen sollte, unabhängig von dem verfolgten Pfad immer derselbe und zur Kompilierungszeit bekannt.
Intern kann der IP 32 den Zeitpunkt der Unterbrechung steuern, indem er einen existierenden zweckbestimmten Timer nutzt. Falls der Kontext des Merkerregisters 47 anzeigt, dass der zu modifizierende Zweig benutzt werden soll, wird die cACU 31 angewiesen, die entsprechende Anzahl von Superzuständen zu überspringen. 13 zeigt ein Beispiel dieses Verfahrens.
Es gibt verschiedene Möglichkeiten, die bedingenden Zweige, die in der der cACU 31 zugewiesenen Funktionalität vorliegen, auszugleichen. Dies hängt davon ab, wie groß die Differenz in den Zyklen zwischen den bedingenden Zweigen (Zweigabstand) ist. Falls die Abstände klein genug sind, kann das Aufspalten der Adressausdrücke, die in den Transferzweigen vorliegen, in Unterausdrücke und das Ausführen der Berechnung in mehreren Zyklen (ein Zyklus pro Unterausdruck) eine Lösung darstellen. Im Falle, dass entweder dieser Ansatz zu einer zu großen Fläche und/oder einem Energieaufschlag führt oder dass der "Abstand" in den Zyklen zwischen den Zweigen zu groß ist, können alternativ "Dummy"-Operationen (No-Operations: NOPs) in die schnelleren Zweige eingefügt werden (wie bei der NOP-Variante der ersten Ausführungsform oben beschrieben). Das Zufügen von NOPs kann jedoch auch zu einem Energieaufschlag führen, wenn es zu intensiv benutzt wird.
Die Interrupt-basierte Vorgehensweise kann mit Merkerabfragen kombiniert werden (was nicht zu einem Leistungsabfall beiträgt), um den IP 32 graduell die Entwicklung der cACU 31 überwachen zu lassen. Lediglich an den kritischen Punkten, die nahe der Kontextumschaltung liegen, kann der IP 32 einen Countdown für den Zeitpunkt, an dem der Interrupt stattfinden soll, starten.
Falls ein Master-Master-Protokoll benötigt wird, kann es vorteilhaft sein, die cACU 31 alle Aufgaben übernehmen zu lassen (einschließlich der Berechnung der bedingenden Zweige). In diesem Fall kann ein ähnliches Vorgehen zur Überwachung des Status der cACU 31 angewendet werden, wie es in der ersten Ausführungsform der Erfindung vorgeschlagen wurde, den von der cACU 31 ausgewählten Zweig von dem IP überwachen zu lassen.
Um zu vermeiden, dass der IP-Compiler die Speichertransferoperationen erneut anordnet, sobald er wiederkompiliert wird, und dadurch die Reihenfolge der Speichertransfers verändert, die ursprünglich in dem Code vorliegen, welcher "nach" der Kontextumschaltung angeordnet ist (siehe 11), sind mindestens zwei Alternativen möglich, wiederum abhängig vom Typ des benutzten IPs (ASIP oder DSP/RISC-Kerne).
Für DSP/RISC-Kerne, in denen es nicht möglich ist, die Zeitablaufsteuerung einzuschränken, könnte eine Option darin bestehen, Cluster von Superzuständen innerhalb von Funktionen zu sammeln und Funktionsaufrufe von dem Hauptcode aus auszuführen. Weil Compiler Operationen nicht über deren Zweck hinausgehend zeitlich planen, verbleibt dann der gesamte Code, der zum Umfang des Funktionsaufrufes gehört, "unberührt".
Dennoch kann dies zu zu viel Aufschlag führen, falls die Menge an Superzuständen zu groß ist (zu kleine Funktionen müssen konform eingesetzt werden, um eine effiziente Kompilierung zu haben). Wenn es zu viele Superzustände gibt, besteht eine andere Möglichkeit darin, der cACU-Zeitablaufsteuerung (oder dem IP-Compiler) Sequenzbedingungen zu stellen. Die Machbarkeit dessen hängt von der eingesetzten Zeitablaufsteuerung ab.
Der Normalbetriebsmodus in einem vollständigen Master-Slave-Schema (14A) ist für eine weitere Ausführungsform der vorliegenden Erfindung vorgesehen, wobei die cACU 31 explizit mit dem IP 32 synchronisiert ist. Das Master-Slave-Schema ist sehr nützlich, wenn der Synchronisationsaufschlag für das Master-Slave-Protokoll sehr niedrig ist, oder wenn der IP 32 sowieso nichts Sinnvolles während dieser Zyklen machen kann. Es ist auch brauchbar, wenn sehr wenig oder keine Steuerung der IP-Zeitablaufsteuerung zur Kompilierungszeit möglich ist (was bei einigen RISC-Kernen der Fall ist). Für dieses kooperative Modell sind sowohl der Normal- als auch der modifizierte Betriebsmodus sehr ähnlich denjenigen, welche für die Master-Master-Architektur vorgeschlagen wurden, jedoch ist jetzt eine der Steuerleitungen, welche von dem IP-Controller benötigt werden, verschieden (next-addr in 15). Diese Leitung ist für die Ausführung des expliziten Synchronisationsmechanismus zuständig. Diese Steuerleitung wird einen Zyklus bevor der IP-Controller 44 die eigentliche Lade-/Speicheroperation ansetzt eingerichtet.
Vorzugsweise sollte für die Master/Slave-Architektur der Lade-/Speichervorgang, welcher gemäß der spezifischen Adressierung für den Transfer genutzt wird, von dem typischerweise sonst eingesetzten Laden des Adresswertes von der IP-ACU 45 unterschiedlich sein. Dies ist notwendig, um dem IP 31 die Benutzung seiner internen ACU 45 für andere "einfache" Zugriffe zu erlauben. Viele Kerne haben genügend Anweisungen vorrätig, sodass eine existierende Lade-/Speicheroperation (load/store) wieder benutzt werden kann.
Es sei zu beachten, dass es für dieses Modell nicht notwendig ist, der cACU 31 anzuzeigen, wann die Kontextumschaltung beendet ist, da die cACU 31 bei jedem Zugriff explizit wieder vollständig synchronisiert wird.
Der Hauptnachteil des Master-Slave-Schemas ist die Unmöglichkeit, gleichzeitig Tasks sowohl in IP 32 als auch cACU 31 auszuführen, wie es bevorzugt in der ersten Ausführungsform der vorliegenden Erfindung der Fall ist. Dies führt zu einem zusätzlichen notwendigen Schritt, um das Kooperationsprotokoll zu vervollständigen (siehe 15, Schritt 2). Die cACU 31 muss "feststellen", wann eine Adresse bereitgestellt werden muss (next-addr), und dies erfordert einen zusätzlichen Schritt in dem Protokoll. Während dieses Schrittes wird die cACU 31 aktiv und der IP bis zur Vervollständigung der Adressberechnung (die üblicherweise innerhalb eines Taktzyklus erfolgen kann) in den Leerlauf versetzt. Dies steht im Gegensatz zu der Master-Master-Ausführungsform, wo keine explizite Synchronisation benötigt wird. Diese Leerlaufzeit ist akzeptabel, wenn nicht zu komplexe oder zu häufige Adressen von der cACU 31 bereitgestellt werden.
Um die vollständigen Normal- und modifizierten Betriebsmodi sowie die bereits existierende Lade-/Speicheroperation durchzuführen, werden drei Anweisungen benötigt. Zwei davon, data-ready und skip-acu(#states), sind in beiden Ausführungsformen gemeinsam: Master-Master und Master-Slave. Die Semantik der dritten Anweisung unterscheidet sich jedoch leicht. In beiden Modellen "bedeutet" die dritte Anweisung, dass eine Aktion in der cACU 31 gestartet werden sollte. In dem Master-Master-Modell löst die "Start"-Aktion den Steuer-Thread des cACU 31 (start-acu) aus oder setzt ihn fort. Bei dem Master-Slave-Modell löst sie lediglich einen Superzustandsübergang von dem entsprechenden Steuer-Thread aus.
Bei der Verwendung eines ASIPs können die neuen Anweisungen leicht eingearbeitet werden, und der entsprechende Compiler kann ohne großen Aufschlag modifiziert werden. Für feste Architekturen (DSPs und RISC-Kerne) ist der vorhandene Befehlssatz üblicherweise groß genug, um einige existierende Anweisungen wieder zu verwenden, die die gewünschte Semantik nachbilden. Die next-addr-Anweisung, welche für das Master-Slave-Modell benötigt wird, kann beispielsweise durch eine einfache Lade-/Speicheroperation mit etwas Steuerlogik, die das next-addr auslöst, sobald das Laden/Speichern decodiert wurde, immitiert werden. Ein weiteres Beispiel ist die ARM-Architektur, welche zwei Anweisungen zum Kommunizieren einer Datenabhängigkeit an einen Co-Prozessor bereitstellt. Diese können wiederverwendet werden, um die Operation in dem Co- Prozessor auszuführen, der wiederbenutzt werden könnte, d. h. für die data-ready- bzw. die start-acu-Operationen.
Es ist immer möglich, die I/O-Abbildungseinrichtung des IP 32 zu nutzen (typischerweise durch RISC-Kerne zum Aktivieren von Peripherieeinrichtungen benutzt) und die benötigten Kommandos bzw. Befehle in dem Datenbus 46 so zu platzieren, dass die ACU 31 unterbrochen wird und die Decodierung des Kommandos fortsetzt. In diesem Fall wird jedoch zu dem Protokoll ein zusätzlicher Aufschlag an Zyklen addiert, wodurch es nur annehmbar wird, falls die Gesamtzyklusvorgaben noch immer eingehalten werden.
Um den Aufschlag an Registern 38 in dem cACU-Master-Controller 37 zu reduzieren, sollte die Abfolge, in der die Datenabhängigkeiten kommuniziert werden, festgelegt werden und zur Kompilierzeit sowohl den cACU- als auch den IP-Zeitablaufsteuerungen 37, 44 bekannt sein. Die Verbindung zwischen den einzelnen Registern 38 der cACU 31 und der Eingabe der entsprechenden anwendungsspezifischen Einheiten wird zur Kompilierzeit festgelegt (ein Register für jede Eingabe). Die Zuordnung von Datenabhängigkeiten zu den einzelnen Register 38 wird zum Kompilierzeitpunkt entschieden (geordnete Kommunikation von Abhängigkeiten) und während der Laufzeit durchgeführt. Datenabhängigkeiten, die während mehr als einer folgenden Kontextumschaltung zugänglich sein müssen, müssen nicht mitgeteilt werden, wobei deren Wert in dem entsprechenden Register aufrechterhalten wird.
In der folgenden Ausführungsform ist eine Schnittstelle zwischen einem ASIP und einer cRCU 50 anhand der Master- Slave-Ausführungsform (16) beschrieben. In der ersten Stufe müssen die verschiedenen Adressausdrücke aus der optimierten Hochsprachenbeschreibung (z. B. C) zusammen mit den notwendigen Datentransfers vom ASIP zur ACU 50 extrahiert werden. Weil die endgültige Abfolge in diesem Fall nicht bekannt ist, wird die relative Ordnung dieser Aktionen ebenso aus der optimierten Datei extrahiert, entsprechend dem normalen verfahrensmäßigen Ausführungsfluss des Codes. Die Speicherzugriffs- und Datentransferaktionen entsprechen den Funktionsabruf-/Steuersignalen from-ato() und to-ato().
In dieser ACU 50 können zwei verschiedene Unteraufgaben bzw. Subtasks isoliert werden: die Verarbeitung der mitgeteilten Daten und die Erzeugung von Adressen. Die Zuweisung dieser beiden verschiedenen Unteraufgaben auf zwei separate "globale" Controller 51, 52 erzeugt in Bezug auf zusätzliche Logik kaum Aufschlag:

a) Die Kommunikation der notwendigen Daten von ASIP-Prozessor zu ACU 50 geschieht unabhängig von der Erzeugung der Adressen.
b) Beide Prozesse haben in Bezug auf Schleifenstruktur und FSM-Zustände kaum Gemeinsamkeiten (keine Möglichkeit des Teilens von gemeinsamen Faktoren zu einem gewichtigen Maß).
c) Sie sind beide verschiedenen Befehlsworten des Prozessors zugeordnet, wodurch es möglich ist, verschiedene Steuersignale an beide zuzuordnen.

Der große Vorteil des Aufteilens des Controllers besteht darin, dass das Routing stärker lokalisiert werden kann und die interne Logik globaler optimiert werden kann. Tatsächlich haben Experimente gezeigt, dass die Logiksynthese stark von der Größe der eingegebenen VHDK-Spezifikation abhängig ist, wodurch eine aufwandsgünstigere Logik entsteht, wenn diese Partitionierung vorgenommen wird.
16 zeigt einen globalen Überblick einer ACU 50 und ihrer Ports. Eingänge sind: CLOCK, addresstick, datatick und databus, der einzige Ausgang ist address, wobei darstellen: CLOCK: der Takt des ASIPs. Adresstick Dies signalisiert der ACU 50, dass eine Adresse berechnet werden sollte. Der Zyklus, bevor die Daten eines Lese- oder Schreibvorgangs stabilisiert wurden, dieses Signal sollte bei einer positiven Taktflanke gesetzt werden. Der Beginn der Berechnungen wird durch die ansteigende Taktflanke des CLOCK und einem High-Wert von adresstick ausgelöst. Die Adresse sollte in der Zeit td (17) berechnet werden, wonach der Adressbus abgekoppelt wird. Dieses Steuersignal von dem ASIP ist mit der speziellen Lade-/Speicheranweisung für die from-ato()-Funktionsaufrufe zugeordnet. Datatick: Dieses zeigt der ACU an, dass gültige Daten auf dem Datenbus 54 vorliegen. Dieses Signal sollte bei einer positiven Taktflanke zum Zeitpunkt, an dem Daten gelesen werden (18), gesetzt werden. Dieses Steuersignal ist den to-ato()-Funktionsaufrufen zugeordnet. Databus: Der Datenbus 54 ist der ASIP-Datenpfad. Da die Breite des echten Busses 54 noch nicht bekannt ist, wird nur die relevante Breite ausgeführt. Address: der Adressbus 55, mit dem die ACU 50 verbunden ist. Da die endgültige Breite des Busses ebenso wenig bekannt ist, wird nur die gerade benötigte Teilbreite ausgebildet. Die Verbindung ist durch eine Tri-state-Logik gesichert, welche den Bus treibt, solange das Signal DRIVE High ist. Dieses Signal wird an der positiven Taktflanke High, wenn addresstick High ist, und geht bei einer positiven Taktflanke auf Low, wenn adresstick Low ist (17 und 19).
Zweite Ausführungsform
Die erste Ausführungsform weist noch immer eine relativ begrenzte Flexibilität in den spezifisch angepassten Punkten zum Einfügen einer Kontextumschaltung auf. Dieses Problem kann durch das Zulassen eines größeren Einflusses auf die IP-Architektur gelöst werden. Um dies zu erreichen, kann der Adressraum des IPs derart erweitert werden, dass er auch eine Unterauswahl der spezifisch angepassten Speicher in dem CP aufnimmt. Gemäß einer zweiten Ausführungsform der vorliegenden Erfindung wird dem programmierbaren Prozessor erlaubt, auf eine Unterauswahl der spezifisch angepassten Speicher innerhalb der spezifisch angepassten Hardware-Organisation (über einen gemeinsam benutzten Adressraum und ein zweckbestimmtes Schaltnetzwerk) zuzugreifen, um einen energiegünstigeren flexiblen Prozessor zu erhalten. Eine ausführliche Anordnung eines IP 62 und eines angepassten Hardware-Teils 61 ist lediglich beispielhaft in 20 gezeigt. Welche Speicher 66 auszuwählen sind, ist klarerweise eine wichtige Design-Entscheidung. Wieder ist ein Kompromiss zwischen zusätzlichem Aufschlag, um dem IP 62 den Zugriff auf diese Speicher 66 zu erlauben, und reduziertem Aufschlag beim Verschieben von Code von CP 61 zu IP 62 beteiligt. Diese Ausführungsform erlaubt eine Reduzierung der Granularität des Randes (9' – SW2 in 21) um die modifizierten Routinen (SW2 ausführend in 21) auf einen sehr strikten Kontext. Im Ergebnis ist mit dem Verschieben des modifizierten Codes von CP 61 zu IP 62 praktisch kein Nachteil in der Leistungsaufnahme verbunden, ausgenommen für die Instruktionen, welche modifiziert und nicht vermieden werden können (im Gegensatz zu der zweiten Ausführungsform). Es ist zu beachten, dass der Zugriff auf die in dem Hauptspeicher 62 gespeicherten Daten am besten durch DMA-Kanäle 64 geschieht (oder einen äquivalenten Zugriffsmodus), um die leistungsverbrauchenden Daten-Caches 67 zu umgehen. Die Leistungsaufnahme in der zweckangepassten Speicherorganisation 66 des CP 61 ist typischerweise mindestens um eine Größenordnung niedriger, als es in der sehr flexiblen Speicherpipeline des IP 62 erreicht werden kann. Dies erfordert jedoch weitere Veränderungen in dem IP-Befehlssatz, weil auch spezielle Schalter 69 gesteuert werden müssen, die den Zugriff zwischen den zentralen IP-Datenbussen 65 und den ausgewählten CP-Speichern 66 verwalten. Vorzugsweise wird hier wegen des großen Aufschlags in der Leistung bei diesem Fall kein allgemeiner N × N-Cross-Bar-Schalter verwendet. Ein stromverbrauchsgünstiger Vorschlag dafür ist in der 22 dargestellt, die Teil des CP 61 ist und daher vollständig eingestellt werden kann. Eine effektive Lösung ist der Einsatz eines Multiplexer-Baumes 71, 72 mit so vielen Ausgängen L wie Speichereinheiten 66₁ –66₃ vorhanden sind, auf die in der angepassten Speicherhierarchie 66 des CP 61 zugegriffen werden muss, und mit so vielen Eingängen R wie Datenbussen 73, 74 für den IP 62 vorhanden sind. In der Praxis müssen maximal R Daten gleichzeitig bereitgestellt werden, was zur weiteren Vereinfachung des Baumes genutzt werden kann. Um außerdem einen Aufschlag in der Leistungsaufnahme während des normalen CP- und IP- Betriebs zu vermeiden, ist dieser Baum 71, 72 von den IP-Datenbussen 73, 74 und den CP-Speichereinheiten 66 mittels Schaltern 69₁ , 69₂ entkoppelt. Diese sollten möglichst nahe dem IP-Datenbus und den CP-Speichern platziert werden, um ein kostengünstiges Entkoppeln der Schaltnetzwerkkapazität während des Normalbetriebs zu ermöglichen. Diese Schalter 69 werden nur dann selektiv hochgefahren, wenn sie während des Wechselwirkungsprotokolls benötigt werden. Auch das Umleiten des Adressbusses (Rerouting) kann auf ähnliche Weise wie in den Beispielen der ersten Ausführungsform (12 und 15) wie oben angegeben flexibel und effizient organisiert werden. Die Architektur erlaubt eine flexible Wechselwirkung zwischen der spezifisch angepasste ACU 31 und der ACU 45 des IPs, wie es in den 23 und 16 gezeigt ist. Die Leistungsfähigkeit des Architekturmodells der zweiten Ausführungsform kann wie folgt zusammengefasst werden:

1. ++: Flexibilität ist erreichbar, wo bei Kompilierzeit erwünscht mit geringem Aufschlag in Geschwindigkeit und Leistungsaufnahme verglichen mit einer vollständig angepassten HW-Lösung. Die resultierende Lösung ist viel effizienter als eine konventionelle Lösung, wo der gesamte Code zum Sicherstellen voller Flexibilität in Software vorgesehen würde. Die Menge an Modifikationen in dem Programm ist selbstverständlich wieder durch den Aufschlag in der HW-SW-Kontextumschaltung und wie viele (Ersatz-)Befehle der SW-Prozessorkern aufnehmen kann begrenzt. In der Praxis wird dies hier jedoch selten ein Problem sein.
2. ++: Leistung sehr gut optimiert, immer dann, wenn ein hoher Verbrauch bei der ursprünglichen Software-Abbildung vorlag, weil der datendominierte Code praktisch vollständig auf stark optimierter HW-Architektur abläuft.
3. ++: Geschwindigkeit sehr gut optimiert wegen derselben Gründe wie bei Leistung.
4. –: Flächenaufwand größer als HW-Lösung, weil auch ein (kleiner) SW-Prozessorkern vorgesehen sein muss, und wegen des zusätzlichen Schaltnetzwerks. Da jedoch mehrfache Metallschichten verfügbar sind, sollte dieser Aufschlag wegen des Schalternetzwerks sehr vernünftig sein. Im Prinzip kann der CP auch als Aufschlag zu einem bereits existierenden IP angesehen werden. Der Flächenaufschlag ist dann immer noch auf die "kleineren" Speicher begrenzt (die großen werden gemeinsam mit dem normalen IP benutzt), auf einige Datenpfade und zweckangepasste Steuerung, die sich in der Vergangenheit als sehr flächeneffizient erwiesen hat. Außerdem wird nicht erwartet, dass die Fläche dieser Komponentenarten in einem System-on-a-Chip-Zusammenhang in tiefen Submikronchips ein großes Problem darstellt, wo Transistoren solange sie effizient zur Stromversorgung benutzt werden relativ günstig sind.
5. ––: Größere Entwurfszeit. Das Programmieren des IPs ist schwieriger (sorgfältige Synchronisation benötigt und Steuerung von "gemeinsam benutzten" Adressraum mit Schaltern); relativ komplexe einzugehende Kompromisse im CP zwischen Flexibilität und wo im Algorithmus Knoten mit möglichen Schnitten anzubringen sind oder welche Speicher in den gemeinsam benutzten Adressraum anzuordnen sind. Dieser Nachteil in der Entwurfszeit kann weitestgehend behoben werden mit der Verfügbarkeit von einer Bibliothek aus Vorlagen zum Einfügen in den IP-Code und mit Entwurfsverfolgungsunterstützung, um einen guten Kompromiss in der CP zu finden.

Insgesamt führt die zweite Ausführungsform zu einer sehr energieaufwandsgünstigen Lösung, die dennoch vollständig flexibel ist. Sie weist außerdem deutliche Geschwindigkeitsvorteile im Vergleich zur herkömmlichen Lösung auf, bei der alle "flexiblen" Aufgaben auf den IP abgebildet werden. Daher wird die Energie-Verzögerungs-Verbesserung verglichen mit einer vollständigen Software-Lösung außergewöhnlich sein (bei guter Optimierung ein bis zwei Größenordnungen). Der einzig echte physikalische Aufwand liegt in der zusätzlichen Fläche, die zumutbar gehalten werden kann. Der Hauptengpass besteht daher in der zusätzlichen Entwurfszeit, die aufgewendet werden muss und die mittels Bibliotheks- und Werkzeugunterstützung reduziert werden sollte, um eine ausgedehnte Nutzung dieses Ansatzes zu ermöglichen. Bei sowohl den ersten und den zweiten Ausführungsformen können die Prozessorkern-Datenpfade genutzt werden, um beliebige nicht-datendominierte Teile auszubilden, welche flexibel, kompatibel mit konventionellen HW-SW-Co-Design-Methodiken sein müssen. Wie in den derzeitigen kernbasierten Ansätzen werden zentrale Busse und ein mikrocodierter Controller für den Arithmetikteil verwendet. Auch die vollständig datenabhängigen Teile (welche nur während der Laufzeit in Form von Datentransfer und Speicherung verwaltet werden können) und die zum Zeitpunkt der Chip-Prozessierung noch unbekannten Teile müssen noch der SW-Seite zugeordnet werden. Hierbei ist eine Laufzeit-Hardware-Steuerung für den Cache-Zugriff auf die Hauptspeicher verantwortlich, wobei ein (großer) Preis insbesondere bezüglich Leistungsaufnahme selbst bei Multimedia-Prozessoren nach dem Stand der Technik bezahlt werden muss. Um außerdem das Energie-Verzögerungs-Produkt für diese Situationen zu verringern, wird nun eine dritte Ausführungsform der vorliegenden Erfindung beschrieben.
Dritte Ausführungsform
Bei einer dritten Ausführungsform der vorliegenden Erfindung werden Leistungsaufnahme-effizientere, vollständig programmierbare (parallele) Prozessoren beschrieben, in denen die vollständige Datentransfer- und Speicherorganisation des programmierbaren Prozessors modifiziert ist, um eine bessere Anpassung bezüglich der Anforderung eines bestimmten Multimedia-Zielanwendungsbereiches zu erreichen. Letzteres erfordert viel größere Investitionen in neue SW-Prozessor-Entwurfsmöglichkeiten und fortgeschrittene Compiler-Technologie. Der Vorschlag besteht darin, viel mehr Anwendungsbereich-spezifische Zweckanpassung in die Datentransfer- und Speicherarchitektur von Multimedia-Prozessoren zu integrieren, wie es in 24 gezeigt ist. Diese Ausführungsform der vorliegenden Erfindung kann vorteilhafterweise mit einem spezifisch angepassten Prozessor verwendet werden. Beispielsweise kann die IP-Architektur, welche schematisch in 24 gezeigt ist, vorteilhaft mit dem spezifisch angepassten Prozessor 2, wie er in 6 gezeigt ist, zum Ersetzen des IP 22 kombiniert werden. Einzelne Aspekte dieser Zweckanpassung bestehen in:

1) Zufügen von flexiblen Bypassen nicht nur über ein einzelnes Cache-Niveau, sondern über eine beliebige Kombination von Cache-Niveaus. Dies erlaubt das Vermeiden von aufwändigem Kopieren immer dann, wenn dies für ein bestimmtes Signal in der Multimedia-Anwendung nicht notwendig ist.
2) Zulassen, dass Signale "ständig" in einem der intermediären Cache-Niveaus verbleiben anstelle lediglich in dem Hauptspeicher. Dies unterscheidet sich (viel flexibler) vom Verwenden beispielsweise eines Vorabrufpuffers (prefetch buffer), wie es in einer Anzahl von neueren Prozessoren, wie dem MIPS RISC, auftritt. Dadurch können mittelgroße Signale in leistungseffektiveren kleineren Speichern anstelle in dem Hauptspeicher behalten werden, auch wenn auf sie im Verlaufe des Programms nur unregelmäßig zugegriffen wird.
3) Zulassen, dass verschiedene Cache-Niveaus in einem einzelnen Speicher zusammengefasst werden (mit verschiedenen internen Bänken), so dass die Größe jedes Niveaus vollständig flexibel ist, solange die Summe unterhalb eines bestimmten Maximums liegt. Dies bedeutet, dass Cache-Größen und auch die Anzahl der für den Programmierer zugänglichen Niveaus vollständig an die abzubildende Anwendung angepasst werden können.
4) Erlauben von flexiblen Zeilengrößen durch das Partitionieren des Caches in verschiedene Bänke, die dann in dem "physikalisch adressierten" Cache für einen bestimmten Block des Algorithmus zusammengefasst werden. Die unbenutzten Bänke werden einfach heruntergefahren, oder mit etwas größerem Hardware-Aufschlag können sie sogar zeitweise einem anderen Cache-Niveau für den Algorithmenblock zugewiesen werden. Dieses Schema kann auch erweitert werden, um das Clustering bzw. das Zusammenfassen von Bänken (und daher die Zeilengröße) für jedes Signal individuell zu verändern.
5) Zulassen einer Änderung des Grades der Assoziativität (innerhalb eines gegebenen Unterbereiches) für ein bestimmtes Cache-Niveau. Idealerweise sollte auch der Fall des direkten Abbildens vorhanden sein. Tatsächlich haben Experimente gezeigt, dass die Leistung für eine bestimmte Routine in der Anwendung stark von dem Assoziationsgrad abhängt. Daher sollte diese Assoziativität für verschiedene Routinen geändert werden.
6) Veränderung der Anzahl von parallelen Pfaden zwischen dem Hauptspeicher und den Prozessoren mittels eines teilweise spezifisch angepassten, teilweise steuerbaren Routing-Netzwerkes. Dieses Netzwerk kann beispielsweise auf ähnliche leistungseffiziente Weise wie das Schaltnetzwerk 71, 72 von 22 der dritten Ausführungsform ausgeführt sein.
7) Zulassen einer Kombination von programmierbaren (Befehlssatz-basierten) ACUs und stark spezifisch angepassten ACUs (siehe Variante der zweiten Ausführungsform), um die Adresserzeugung für komplexere Adressausdrücke zu beschleunigen. Dies ist sowohl für die Cache-Niveaus als auch zum Steuern des Off-Chip-Hauptspeichers nützlich.

Die Umsetzung der dritten Ausführungsform erfolgt teilweise unter Inkaufnahme reduzierter Flexibilität verglichen mit universell einsetzbaren RISCs, erfordert jedoch insbesondere eine große Investition in neues Prozessor-Architekturdesign und in Compiler-Technologie. Jedoch werden die potenziellen Einsparungen noch größer als in den zuvor beschriebenen Ausführungsformen ausfallen. Kürzlich wurden von einigen Firmen sehr einsatzspezifische Prozessoren für eine begrenzte Klasse von Anwendungen vorgeschlagen. Ein Beispiel ist die programmierbare MIPS-MPEG2-Maschine. Diese Prozessoren weisen noch immer einen begrenzten Umfang auf, und der Datentransfer- und Speicherengpass wurde eigentlich nicht gelöst, insbesondere bezüglich der Leistung. Die Leistungsfähigkeit des Architekturmodells nach der dritten Ausführungsform kann wie folgt zusammengefasst werden:

1. ++(+): Flexibilität ist erreichbar, sogar wenn zur Kompilierzeit keine Kenntnis darüber herrscht, welcher der genaue Arithmetik-/Logik-/lokale Steuerteil des Algorithmusverhaltens ist, welcher auszuführen ist. Es genügt die Kenntnis, welche Typen von komplexen Datenstrukturen vorliegen und welche Abhängigkeiten zwischen diesen in den erwarteten Algorithmen sind. Auf Grundlage dessen muss die spezifische Anpassung der Speichereinheiten und des Zwischenverbindungsnetzwerkes bestimmt werden.
2. ++(+): Leistungsaufnahme ist immer dann stark optimiert, wo große Verbrauche stattfinden, d. h. für die Hauptdatentransfers in dem Algorithmus auf die Hauptspeicher- und Kommunikationsressourcen. Selbstverständlich geschieht dies nur, falls genügend spezifische Anpassung in der Datentransfer- und Speicherarchitektur bezüglich der tatsächlich ausgeführten Algorithmen möglich ist.
3. –. Zusätzliche Fläche aufgrund der spezifischen Anpassung von Speicher- und Kommunikationshierarchie und deren Steuerung.
4. ++(+): Geschwindigkeit ist (viel) besser als der geläufige Multimedia-Prozessor, insbesondere in Bezug auf Speicherung/Transfers. Dies gilt wieder nur, falls genügend spezifische Anpassung bezüglich der tatsächlich ausgeführten Algorithmen möglich ist.
5. –––: Viel größere Entwurfszeit. Programmieren sehr schwierig (z. B. komplexe MMU, Steuerung, Schnittstellen), und Entwurfsverfolgungsunterstützung kann zum Ausfindigmachen einer akzeptablen Architekturlösung erforderlich sein. Bei diesem Fall ist die bestehende DTSE-Methodik sicherlich mangelhaft für die Unterstützung dieser stark programmierbaren Architekturdefinition. Es kann höchstens als eine Teilgrundlage zum Aufbau eines Multimedia-Precompilers benutzt werden, der das Abbilden der datendominierten Module auf die neue Prozessorarchitektur übernimmt. Schließlich wird viel intensivere Kompilierzeitanalyse, als derzeit in der Literatur vorhanden, für den vollständigen Anwendungscode einschließlich der datenabhängigen Fälle benötigt.

Vierte Ausführungsform
Gemäß einer vierten Ausführungsform der vorliegenden Erfindung wird "Wiederverwendung" in dem Entwurfsverfahren mit den Grundideen der obigen Ausführungsformen verknüpft. Gemäß einem Gesichtspunkt dieser Ausführungsform werden flexible HW-SW-Mischansätze vorgeschlagen, die die "Wiederbenutzung von Komponentendesign" (in Gesamtzusammenhang mit einem gewerblichen Rechtsschutz) unter einem anderen Gesichtspunkt betrachten, was viel dehnbarer ist als die Wiederbenutzung von einer vorbestimmten, vollständig festgelegten Komponente. Ein in der Vergangenheit nicht veränderbarer großer Hardware-Block (CP) kann nun durch einen kleinen IP oder einen IP, der die oben diskutierten Modifikationen bezüglich der ersten bis dritten Ausführungsform unterstützt, begleitet sein. Beide können dann, wie in Bezug auf die erste und zweite Ausführungsform diskutiert, kooperieren, um ihn in den gewünschten Kontext besser einzupassen. In der herkömmlichen Herangehensweise muss solch ein CP-Block "perfekt" passen, was die Möglichkeiten der Wiederverwendung einschränkt: Alternativ ist die Wiederverwendung mit einer Fehlanpassung zwischen Modulen verbunden, die mittels Puffern zwischen diesen Modulen aufgefangen werden muss, wobei die Module die Daten zu einer für das folgende Modul geeigneten Form wiederverarbeiten müssen. Dies erzeugt einen ziemlich großen Aufschlag in Zusammenhang mit dem CP (z. B. Systempuffer). In der vorliegenden Ausführungsform kann der CP ohne zu viel Aufschlag flexibel adaptiert werden, so dass er perfekt in seine Umgebung einmodelliert ist. Es können sogar einige kleine interne Modifikationen an ihm durchgeführt werden, falls sein funktionelles Verhalten aufgrund von veränderten Standards oder Fehlerbehebungen aktualisiert werden soll. Eine inverse diskrete Cosinus-Transformation (IDCT) ist beispielsweise als zwei 1-D IDCT-Blöcke 84, 86 ausgedrückt, wobei jeder einen Satz von skalaren Daten zum Zusammenstellen in einen Ausgangsskalar (25) verarbeitet. Es sei angenommen, dass sich der Eingangspuffer 82 von vertikalem (V) in horizontales (H) Blockformat wandelt, und dass sich der Ausgangspuffer 87 von V nach H wandelt. Typischerweise ist der Aufwand für diese Puffer relativ hoch, und Experimente haben beispielsweise gezeigt, dass die Leistungsaufnahme von einem 1D IDCT-Datenpfad und -Steuermodul etwa dieselbe ist wie der des Transponierpuffers 85. Falls das 2D IDCT-Modul 83 von einem IP 89 gemäß der vorliegenden Erfindung unterstützt wird, kann die Sättigungsarithmetik für die Aufnahme der teilweisen Zeilen- oder Spaltenergebnisse für einen bestimmten Satz von Zeilen oder Spalten (z. B. die endgültigen), sogar nachdem der wieder verwendbare Block entworfen und ausgeführt wurde, modifiziert werden. Die Eingangs- und Ausgangspuffer 82, 87 können durch Vereinigung mit dem Transponierpuffer 85 entfernt werden, indem die entsprechenden Änderungen in dem lokalen Code, der auf den Transponierpuffer 85 zugreift, angebracht werden. Dies kann einige Kontextumschaltungen zwischen IP 89 und CP 83 erfordern, jedoch ist es das Endergebnis wert. Bei einer herkömmlichen Wiederverwendungsstrategie würde die Adressierung der Flüsse (streams) in dem VHDL-Code für die 1D IDCT-Module 84, 86 integriert werden, und ein vollständiger Neuentwurf wäre zur Vermeidung des Pufferns erforderlich.
Obwohl die besonderen Ausführungsformen anhand von bestimmten Anwendungen und Architekturen beschrieben wurden, liegen Modifikationen und Veränderungen der gezeigten Ausführungsformen innerhalb des Rahmens der Erfindung. Durch die dargestellten Beispiele sind keine Einschränkungen im Schutzumfang der vorliegenden Erfindung beabsichtigt, und die vorliegende Erfindung wird lediglich durch den Schutzumfang der beigelegten Ansprüche begrenzt.

Claims

Programmierbare Verarbeitungsmaschine, wobei die Verarbeitungsmaschine einen spezifisch angepassten Prozessor (21) aufweist, einen anpassbaren Prozessor (22) und einen Datenspeicher (23), der gemeinsam von den zwei Prozessoren (21, 22) nutzbar ist, wobei der spezifisch angepasste Prozessor (21) eine Abfolge von Routinen aus einer Mehrzahl von vorangepassten Routinen ausführt, und der anpassbare Prozessor (22) ein programmierbarer Prozessor oder ein wiederkonfigurierbarer Logikschaltkreis ist, mit: einer Steuereinrichtung (21) zum Überwachen des spezifisch angepassten Prozessors während der Ausführung eines ersten Programmteils, zum Auszuwählen eines aus einem Satz von vorangepassten Verfahrensunterbrechungspunkten in einer ersten Routine, und zum Umschalten von Kontext von dem spezifisch angepassten Prozessor zu dem anpassbaren Prozessor zu dem gewählten Unterbrechungspunkt.
Verarbeitungsmaschine nach Anspruch 1, wobei der Datenspeicher (23) zumindest Teil eines lokalen Datenspeichers (27) des spezifisch angepassten Prozessors (21) ist.
Verarbeitungsmaschine nach Anspruch 1 oder 2, wobei der Datenspeicher (23) ein Datenspeicher ist, der gemeinsam von dem spezifisch angepassten (21) und dem anpassbaren (22) Prozessor genutzt ist.
Verarbeitungsmaschine nach einem der vorhergehenden Ansprüche, wobei der programmierbare Prozessor eine Zähleinrichtung zum Bestimmen des Zeitpunktes einer Kontextumschaltung aufweist.
Verarbeitungsmaschine nach einem der vorhergehenden Ansprüche, wobei der spezifisch angepasste Prozessur (21) zum Bereitstellen von Informationen an den anpassbaren Prozessor (22) eingestellt ist, wobei die Informationen ausreichen, den Zeitpunkt der Kontextumschaltung zu bestimmen.
Verarbeitungsmaschine nach einem der vorhergehenden Ansprüche, wobei der anpassbare Prozessor (22) zum Überwachen der Zweigentwicklung in dem spezifisch angepassten Prozessor (21) eingestellt ist.
Verarbeitungsmaschine nach einem der vorhergehenden Ansprüche, wobei der anpassbare Prozessor (22) eine Hierarchie von Cache-Speichern (27) aufweist, wobei die Cache-Speicher (27) während der Laufzeit flexibel konfigurierbar sind.
Verarbeitungsmaschine nach einem der vorhergehenden Ansprüche, wobei der Zugriff des anpassbaren Prozessors (22) auf den gemeinsam nutzbaren Datenspeicher (23) von einem Netzwerk bereitgestellt ist.
Verarbeitungsmaschine nach Anspruch 8, wobei das schaltende Netzwerk so eingestellt ist, dass es nur Zugriff auf den Datenspeicher (23) bei der Kontextumschaltung ermöglicht, und dass außerhalb der Kontextumschaltung der anpassbare (22) und/oder spezifisch angepasste (21) Prozessor nicht kapazitiv durch die Zugriffsleitungen geladen wird.
Verfahren zum Bereitstellen einer programmierbaren Verarbeitungsmaschine, wobei die Verarbeitungsmaschine einen spezifisch angepassten Prozessor (21), einen anpassbaren Prozessor (22) und einen Datenspeicher, der gemeinsam von den beiden Prozessoren (21, 22) nutzbar ist, aufweist, wobei der spezifisch angepasste Prozessor (21) eine Abfolge von Routinen aus einer Mehrzahl von vorangepassten Routinen ausführt und der anpassbare Prozessor (22) ein programmierbarer Prozessor oder ein wiederkonfigurierbarer Logikschaltkreis ist, mit den Schritten: Überwachen des spezifisch angepassten Prozessors (21) während des Ausführens eines ersten Programmteils zum Auswählen eines aus einem Satz von vorangepassten Prozessunterbrechungspunkten in einer ersten Routine; Umschalten von Kontext von dem spezifisch angepassten Prozessor (21) zu dem anpassbaren Prozessor (22) an dem ausgewählten Unterbrechungspunkt.
Verfahren nach Anspruch 10, ferner mit dem Schritt: Ausführen eines zweiten Programmteils auf dem anpassbaren Prozessor (22), wobei zumindest ein Teil von ersten Daten, die in dem Datenspeicher (23) durch die Ausführung des ersten Programmteils auf dem spezifisch angepassten Prozessor (21) belassen sind.
Verfahren nach Anspruch 11, ferner mit den Schritten: Vervollständigen der Ausführung des zweiten Programmteils auf dem anpassbaren Prozessor (22), so dass zweite Daten in dem Datenspeicher (23) belassen werden; und Umschalten von Kontext auf den spezifisch angepassten Prozessor (21) und weiteres Ausführen eines dritten Programmteils, wobei zumindest ein Teil der zweiten Daten benutzt wird.
Verfahren nach Anspruch 12, wobei der anpassbare Prozessor (22) den spezifisch angepassten Prozessor (21) anweist, eine bestimmte Anzahl von Prozessschritten zu überspringen, bevor der spezifisch angepasste Prozessor (21) das Verarbeiten der zweiten Daten beginnt.
Verfahren nach einem der Ansprüche 10 bis 13, wobei der spezifisch angepasste Prozessor (21) nach der Kontextumschaltung auf den anpassbaren Prozessor (22) heruntergefahren wird.
Ein spezifisch angepasster Prozessor (21), der zum Ausführen einer Abfolge von Routinen aus einer Mehrzahl von vorangepassten Routinen eingestellt ist, wobei der spezifisch angepasste Prozessor (21) eine Steuereinrichtung zum Überwachen der Ausführung eines Prozesses, welches auf dem spezifisch angepassten Prozessor (21) läuft, und die zum Auswählen eines aus einem Satz von vorangepassten Prozessunterbrechungspunkten in dem Prozess und zum Anhalten des spezifisch angepassten Prozessors (21) an einem der Unterbrechungspunkte eingestellt ist.
Spezifisch angepasster Prozessor nach Anspruch 15, wobei der spezifisch angepasste Prozessor (21) zur Ausgabe von Informationen, die ausreichen, um den Zeitpunkt einer Kontextumschaltung zu bestimmen, eingestellt ist.
Spezifisch angepasster Prozessor nach Anspruch 15 oder 16, ferner mit zumindest einem Schalter zu einer selektiven Zugriffsfreigabe auf einen Teil des Datenspeichers (27), der ein Lokaler des spezifisch angepassten Prozessor (21) ist.