-
Die
vorliegende Erfindung bezieht sich auf ein Multiprozessorsystem.
-
Die
vorliegende Erfindung bezieht sich außerdem auf ein Verfahren zum
Betrieb eines Multiprozessorsystems.
-
Bei
vielen Produkten, die auf Standards wie MPEG-x, DVB, DAB und UMTS
beruhen, bestimmen Signalverarbeitungsfunktionen die Anforderungen
an das Leistungsvermögen.
Daher ist es erforderlich, die Signalverarbeitungskomponenten bei
diesen Produkten auf effiziente Weise zu implementieren. Aufgrund
neu aufkommender Standards und sich ändernder Marktanforderungen
erfordert die Implementierung Flexibilität und auch Skalierbarkeit.
Eine natürliche
Möglichkeit
zur Modellierung dieser Anwendungen besteht in einer Makropipeline-Anordnung,
da Ströme
von Daten verarbeitet werden; bei dieser Anordnung sind die Funktionen (Aufgaben)
die Stufen, und zwischen den Stufen sind Puffer vorgesehen, um die
Pipeline zu bilden. Dies stellt eine Möglichkeit dar, Parallelität auf Aufgabenebene
(Task-level parallelism, TLP) zu nutzen, da alle Stufen parallel
arbeiten können.
-
Ein
Multiprozessorsystem mit einer Vielzahl von Prozessoren ist für die Implementierung
einer derartigen Makropipeline sehr gut geeignet. Ein Multiprozessorsystem
kann mehrere Arten von Prozessoren umfassen, zum Beispiel programmierbare
Prozessoren, z.B. RISC-Prozessoren oder VLIW-Prozessoren, oder spezielle
Hardware. Ein Prozessor kann eine bestimmte Aufgabe ausführen, oder
im Zeitanteilsverfahren (time-sharing) mehr als eine Aufgabe. Da
die Komplexität
der Signalverarbeitungsfunktionen und ihrer Implementierung in einem
Multiprozessorsystem immer mehr zunimmt, wird es zunehmend schwieriger,
ein derartiges System zu prüfen
und Fehler darin zu beheben.
-
Die
Erfindung hat zur Aufgabe, ein Multiprozessorsystem zu schaffen,
bei dem auf relativ einfache Weise Fehler beseitigt werden können, und
ein Verfahren zum Betrieb des Multiprozessorsystems, das die Fehlerbeseitigung
erleichtert.
-
Ein
erfindungsgemäßer Multiprozessor
mit diesem Zweck ist in Anspruch 1 geltend gemacht. Ein erfindungsgemäßes Verfahren
mit diesem Zweck ist in Anspruch 8 geltend gemacht.
-
In
einer auf einem Multiprozessorsystem implementierten Makropipeline
müssen
Daten zwischen den Prozessoren ausgetauscht werden, z.B. über einen
Puffer. Es wird ein Synchronisierungsprotokoll benötigt, um
die Datenerzeugung eines ersten Prozessors mit der Datenaufnahme
eines zweiten Prozessors, der in der Pipeline auf den ersten Prozessor
folgt, zu synchronisieren. Ein derartiges Synchronisierungsprotokoll
nutzt Synchronisierungsinformationen, z.B. ein Paar Semaphoren.
Zum Beispiel gibt ein erster Semaphor die Anzahl der Pufferelemente
an, die dem ersten Prozessor zum Schreiben neuer Daten zur Verfügung stehen,
und ein zweiter Semaphor gibt die Anzahl der Pufferelemente an,
die dem zweiten Prozessor zum Lesen zur Verfügung stehen. Ein derartiges
System ist in dem Dokument WO-A-99 22296 beschrieben.
-
In
einer Implementierung, die einen speziellen Prozessor umfasst, werden
die Verwaltungsinformationen vorzugsweise gespeichert, wo dies am
wichtigsten ist. Wenn zum Beispiel der spezielle Prozessor dafür eingerichtet
ist, Daten in den Puffer zu schreiben, sollte der erste Semaphor
schnell auf diesen Prozessor zugreifen, z.B. in Form eines speziellen
Registers. Wenn jedoch eine Fehlerbeseitigung im System erforderlich ist
oder das System getestet werden muss, zum Beispiel um Engpässe in der
Pipeline zu finden, ist es sehr schwierig, diesen verstreuten Informationen
nachzuspüren.
Erfindungsgemäß wird daher
eine Kopie von mindestens einem Teil dieser Verwaltungsinformationen
in dem gemeinsam genutzten Speicher gehalten. Auf diese Weise wird
die Analyse der Systemfunktion wesentlich vereinfacht, da mehr relevante
Informationen in gruppierter Form zur Verfügung stehen. Und da sich diese
Informationen im Speicher befinden, sind sie für einen Software-Debugger zugänglich.
-
Es
ist zu beachten, dass in dem Dokument
US 6.173.307 B1 ein Multiprozessorsystem
mit einer kreisförmigen
Schlange beschrieben wird, die von mehreren Erzeugern und mehreren
Verbrauchern gemeinsam genutzt wird. Es kann jedem beliebigen Erzeuger
oder Verbraucher erlaubt werden, jeden beliebigen Erzeuger oder
Verbraucher zu einem beliebigen Zeitpunkt vorzubelegen, ohne die
Korrektheit der Schlange zu stören.
-
Es
ist weiterhin zu beachten, dass in dem Dokument
US 4.916.658 ein Gerät mit einem
dynamisch gesteuerten Puffer beschrieben wird. Der Puffer eignet
sich zum Speichern von Datenwörtern
bestehend aus mehreren Speicherplätzen zusammen mit Schaltungen,
die einen ersten Indikator bereitstellen, der den nächsten Speicherplatz
zum Speichern angibt, einen zweiten Indikator, der den nächsten Speicherplatz
zum Abrufen angibt und Schaltungen, die die Anzahl der zum Speichern
und die Anzahl der zum Abru fen verfügbaren Speicherplätze bereitstellt.
-
In
einem Multiprozessorsystem können
die Prozessoren mehr als eine Aufgabe ausführen, weil die Anzahl der Aufgaben
größer sein
kann als die Anzahl der Prozessoren. Außerdem kann das Multiprozessorsystem
dynamisch rekonfiguriert werden, z.B., um an eine sich ändernde
Bitrate eines durch das System verarbeiteten Datenstroms angepasst
zu werden. In diesen Fällen
ist eine Ausführungsform
des erfindungsgemäßen Multiprozessorsystems
vorteilhaft, wie sie in Anspruch 2 geltend gemacht wird. Wenn das
System dynamisch rekonfiguriert wird, kann der Wechsel des Kommunikationspartners
einer bestimmten Aufgabe von einer Hardware-Aufgabe (unter Verwendung
verteilter Informationen, z.B. in einer Schale (engl. „shell") gespeichert) zu
einer Software-Aufgabe (unter Verwendung zentralisierter Informationen
in einem gemeinsam genutzten Speicher) wesentlich reibungsloser
erfolgen, weil beide Formate bereits nebeneinander bestehen. Bei
Multitasking-Hardware-Vorrichtungen hat jede Aufgabe ihre private
Kopie der Verwaltungsinformationen der benutzten Puffer in der Schale
(in Registern) gespeichert. Dadurch vergrößert sich die Schale. Dies
kann vermieden werden, indem die Register von den Aufgaben gemeinsam
genutzt werden. Jedes Mal, wenn eine Aufgabe ausgelagert wird, muss
der aktuelle Zustand ihrer Puffer jedoch explizit im Speicher gespeichert
werden, und jedes Mal, wenn sie erneut geplant wird, müssen alle
Zustände
wiederhergestellt werden. Dies hat negative Auswirkungen auf die
Laufzeitleistung. Indem während
der gesamten Zeit eine zentralisierte Kopie der Puffer-Verwaltungsinformationen
im Speicher gehalten wird, braucht der Pufferzustand beim Umschalten
von Aufgaben nicht gespeichert zu werden, weil er bereits vorhanden
und aktuell ist.
-
In
Anspruch 3 wird eine erste Implementierung des Synchronisierungsprotokolls
beschrieben. In dieser Ausführungsform
führt jeder
der Prozessoren einen jeweiligen Synchronisierungszähler. Ein
erzeugender Prozessor (der also Token schreibt) führt einen
ersten Synchronisierungszähler
Np und ein verbrauchender Prozessor (der diese Informationen liest)
führt einen
zweiten Synchronisierungszähler
Nc. Unter der Voraussetzung, dass der für den Informationsaustausch
verwendete Puffer eine Größe Nb hat,
beläuft
sich die Anzahl N1 der dem ersten Prozessor zur Verfügung stehenden
Token auf N1 = Nc – Np mod
Nb, (1)und
die Anzahl der Token N2, die dem zweiten Prozessor zur Verfügung stehen,
ist N2 = Np – Nc mod
Nb. (2)
-
Jedes
Mal, wenn der erzeugende Prozessor ein Token geschrieben hat und
dieses für
den verbrauchenden Prozessor freigibt, aktualisiert er den ersten
Synchronisierungszähler
Np, und jedes Mal, wenn der verbrauchende Prozessor ein Token gelesen
hat und es für
den erzeugenden Prozessor freigibt, aktualisiert er den zweiten
Synchronisierungszähler
Nc.
-
Ein
Prozessor kann jederzeit die Anzahl der von ihm nutzbaren Token
prüfen,
indem er einen ersten Befehl (Forderung) ausgibt. Dadurch wird überprüft, ob hierfür ein Pufferraum
zur Verfügung
steht, indem beide Synchronisierungszähler verglichen werden. Der
erste Prozessor nutzt für
die Überprüfung Gleichung
1 und der zweite Prozessor Gleichung 2.
-
Der
zweite Befehl (Freigabe) führt
zu einer Inkrementierung des dem Prozessor zugeordneten Synchronisierungszählers um
die Anzahl der freigegebenen Token.
-
Der
erste und der zweite Befehl können
in der Form eines Funktionsaufrufs in Software implementiert oder
mittels eines speziellen Signals in Hardware implementiert werden.
-
Eine
besondere Ausführungsform
wird in Anspruch 4 beschreiben. In dieser Ausführungsform kann der mindestens
eine Prozessor eine Zone in dem Puffer reservieren, die er nach
Belieben nutzen kann, z.B. für
den Direktzugriff oder für
die vorübergehende
Speicherung von Daten.
-
Statt
die Anzahl der freigegebenen Token zu führen, wie in der Ausführungsform
aus Anspruch 3, ist es alternativ möglich, die Anzahl der in einem
Zähler
zur Verfügung
stehenden Token zu führen.
In diesem Fall wird der Zähler
für die
Anzahl der zum Schreiben zur Verfügung stehenden Token durch
den verbrauchenden Prozessor inkrementiert und durch den erzeugenden
Prozessor dekrementiert. Der Zähler
für die
Anzahl der zum Lesen zur Verfügung
stehenden Token wird durch den erzeugenden Prozessor inkrementiert
und durch den verbrauchenden Prozessor dekrementiert. Diese Ausführungsform
wird in Anspruch 5 beschrieben.
-
Obwohl
die Kopie in dem gemeinsam genutzten Speicher durch arbiträre Mittel
geführt
werden könnte, wird
bevorzugt, dass der spezielle Prozessor auch die Kopie in dem gemeinsam
genutzten Speicher aktualisiert. Der spezielle Prozessor „weiß", zu welchem Zeitpunkt
die Änderungen
in den Verwaltungsinformationen auftreten.
-
Der
Puffer befindet sich vorzugsweise in dem gemeinsam genutzten Speicher,
z.B. unter Nutzung des gleichen Speichers, der für die Kopie der Verwaltungsinformationen
verwendet wird.
-
Eine
mit einem Prozessor gekoppelte Schale erleichtert das Multitasking, indem
sie die Anzahl der Unterbrechungen verringern kann, die durch den
Prozessor selbst behandelt werden müssen. Dadurch braucht ein im
Leerlauf befindlicher Prozessor weniger häufig unnötigerweise aktiviert zu werden
oder ein Prozessor eine andere Aufgabe, die er gerade ausführt, zu
unterbrechen. Auf diese Weise wird die Effizienz des Prozessors
verbessert.
-
Es
sind je nach Art der Unterbrechungssignale und ihrer Codierung mehrere
Optionen für
die Implementierung einer derartigen Schale zur Auswahl von Unterbrechungssignalen
möglich.
Bei einer Ausführungsform
geben die Unterbrechungssignale einen Datenkanal des Prozessors
an. Eine praktische Möglichkeit,
dies zu implementieren, besteht darin, Bits in einem Register entsprechenden
Eingangskanälen
des Prozessors zuzuweisen. Zum Beispiel könnte ein 32-Bit-Register 32
Eingangskanäle
unterstützen,
wobei zum Beispiel Kanal 0 das Bit 0 zugewiesen wird, Kanal 1 das
Bit 1 des Registers zugewiesen wird, usw. Wenn ein anderer Prozessor
ein für
Kanal k des Prozessors bestimmtes Unterbrechungssignal sendet, wird
das entsprechende Bit k des Signalregisters gesetzt. Die Schale
des empfangenden Prozessors kann spezielle Unterbrechungssignale
mit Hilfe eines Maskenregisters auswählen, in dem jedes Bit für einen
bestimmten Kanal darstellt, ob der Prozessor die Unterbrechung ignorieren
möchte
oder nicht. Wenn zum Beispiel das Bit, das Kanal zwei entspricht,
maskiert wird, wird dieses Signal keine Unterbrechung im Prozessor
bewirken und es wird kein Wake-up erfolgen. In diesem Beispiel könnte der
Prozessor mit dem Verarbeiten beschäftigt sein, in dem alle Bits maskiert
werden, oder der Prozessor/die Aufgabe könnte auf ein volles/leeres
Token auf Kanal 1 warten, wobei er in diesem Fall nicht daran interessiert
ist, was auf Kanal 2 geschieht.
-
Das
Signal und das Maskenregister könnten
eine willkürliche
Anzahl von Bits haben, abhängig
von der Anzahl der zu unterstützenden
Kanäle.
Alternativ ist es möglich,
jeden Kanal durch eine Anzahl zu unterstützen und eine Liste oder Verweistabelle
zu verwenden, um festzustellen, ob der Prozessor für diesen
Kanal unterbrochen werden sollte oder nicht. Dies ist jedoch eine
komplexere Lösung.
-
Statt
ein Unterbrechungssignal durch seine Kanalzahl zu identifizieren,
könnte
es durch eine Aufgabenzahl identifiziert werden. In dieser Ausführungsform
setzen alle Kanäle
mit Signalen für
eine spezielle Aufgabe das gleiche Bit in dem Signalregister der
Schale. Auf diese Weise könnte
eine Anzahl von Aufgaben, die der Anzahl von Bits in dem Signalregister
entspricht, eindeutig adressiert werden, während jede Aufgabe mehr als
einen Kanal haben kann. Das Warten ist etwas weniger spezifisch
als bei eindeutiger Ka nalidentifizierung, aber die Anzahl unnötiger Wake-ups
ist immer noch klein und mit begrenzter Hardware können mehr
Kanäle unterstützt werden.
-
Natürlich braucht
die Aufgabenzahl nicht mit der Bitzahl identisch zu sein (es ist
nur einfach, wenn dies der Fall ist), solange die Relation definiert
ist. Außerdem
ist es auch möglich,
dass sich (Gruppen von) Aufgaben die gleiche Signal-Unterbrechungs-Zahl teilen.
-
Statt
die durch den Empfänger
ausgeführte
Aufgabe zu identifizieren, könnten
die Aufgabenidentifizierungszahl des Senders signalisiert werden.
In diesem Fall kann der empfangende Prozessor Unterbrechungssignale
von einer bestimmten Aufgabe auswählen statt für eine bestimmte
Aufgabe. Dies kann von der Anzahl der externen Aufgaben und der
Anzahl der Aufgaben von persönlichen
Präferenz
des Prozessors oder davon abhängen,
was als am nützlichsten/effizientesten
erscheint.
-
Diese
und andere Aspekte der Erfindung werden in der Zeichnung beschrieben.
Es zeigen:
-
1 schematisch
ein Datenverarbeitungsgerät;
-
2 schematisch
eine Möglichkeit,
mit der Synchronisierungszähler
Partitionen eines Puffers angeben;
-
3 eine
Synchronisierungsschale für
einen Prozessor; und
-
4 eine
Kanalsteuereinheit.
-
1 zeigt
ein Datenverarbeitungsgerät
mit mindestens einem ersten 1.6 und einem zweiten Verarbeitungsmittel 1.3.
Das erste Verarbeitungsmittel, ein anwendungsspezifischer Prozessor 1.6,
ist in der Lage, Daten bereitzustellen, indem es Token in einem
Puffermittel zur Verfügung
stellt, das sich im Speicher 1.5 befindet. Die Token können von
dem zweiten Verarbeitungsmittel 1.3, einem digitalen Signalprozessor,
zur weiteren Verarbeitung gelesen werden. Das Datenverarbeitungsgerät umfasst
weiterhin einen RISC-Prozessor 1.1, einen VLIW-Prozessor 1.2 und
einen ASIP 1.4. Der VLIW-Prozessor 1.2, der DSP 1.3,
der ASIP 1.4, der Speicher 1.5 und der ASIC 1.6 sind über einen
ersten Bus 1.7 miteinander gekoppelt. Der RISC-Prozessor 1.1 ist
mit einem zweiten Bus 1.8 gekoppelt, der seinerseits über eine
Brücke 1.9 mit
dem ersten Bus 1.7 gekoppelt ist. Ein weiterer Speicher 1.10 und
Peripheriegeräte 1.11 sind
mit dem zweiten Bus 1.8 verbunden. Die Prozessoren können Hilfseinheiten
haben. Zum Beispiel umfasst der RISC-Prozessor 1.1 einen
Anweisungs-Cache 1.1.1 und Daten-Cache 1.1.2.
Auf ähnliche
Weise hat der VLIW- Prozessor
einen Anweisungs-Cache 1.2.1 und Daten-Cache 1.2.2.
Der DSP 1.3. umfasst einen Anweisungs-Cache 1.3.1,
einen lokalen Speicher 1.3.2 und einen Adressdecodierer 1.3.3.
Der ASIP 1.4 umfasst einen lokalen Speicher 1.4.1 und
Adressdecodierer 1.4.2. Der ASIC 1.6 umfasst einen
lokalen Speicher 1.6.1 und Adressdecodierer 1.6.2.
Den Verarbeitungsmitteln 1,6, 1.3 ist ein jeweiliger
Synchronisierungsindikator zugeordnet. Beide Synchronisierungsindikatoren
sind sowohl für
das erste 1.6 als auch für das zweite Verarbeitungsmittel 1.3 zugänglich.
Der erste Synchronisierungsindikator ist mindestens von dem ersten
Verarbeitungsmittel 1.6 modifizierbar und von dem zweiten
Verarbeitungsmittel 1.3 lesbar. Der zweite Synchronisierungsindikator
ist mindestens von dem zweiten Verarbeitungsmittel 1.3 modifizierbar
und von dem ersten Verarbeitungsmittel 1.6 lesbar.
-
Jeder
der Synchronisierungsindikatoren wird durch einen Zähler dargestellt.
Der Zähler,
der den ersten Synchronisierungsindikator darstellt (writec), gibt
die Anzahl der von dem ersten Verarbeitungsmittel 1.6 geschriebenen
Token an. Der Zähler,
der den zweiten Synchronisierungsindikator darstellt (readc), gibt
die Anzahl der von dem zweiten Verarbeitungsmittel 1.3 gelesenen
Token an.
-
Für den Fachkundigen
bieten sich verschiedene Optionen, um die Anzahl von Token durch
einen Zähler
anzugeben, solange ein Vergleich der Zählerwerte die Berechnung der
Anzahl Token ermöglicht,
die für
jeden der Prozessoren zur Verfügung
stehen. Zum Beispiel könnte
der Zählerwert
gleich der Anzahl Token mod n sein, wobei n ein ganzzahliger Wert
ist. Andernfalls könnte
jeder Schritt des Zählers
eine feste Anzahl Token darstellen, oder ein Token könnte durch
eine Anzahl von Schritten des Zählerwertes
dargestellt werden.
-
In
einer praktischen Ausführungsform
sind die Zähler
ein Zeiger auf die Adresse, bis zu der die Puffermittel für den anderen
Prozessor zur Verfügung
gestellt werden. Dies ist in 2 schematisch
dargestellt. Diese Figur zeigt schematisch einen Pufferraum 2.1 innerhalb
des Speichers 1.5, der von dem ersten Verarbeitungsmittel 1.2 zum
Bereitstellen der Daten für
das zweite Verarbeitungsmittel 1.3 genutzt wird. Der Pufferraum 2.1 ist
als zyklischer Puffer angeordnet. Der Pufferraum 2.1 umfasst
eine erste Zone 2.2 und eine zweite Zone 2.4,
die von dem ersten Verarbeitungsmittel 1.2 geschriebene
Daten enthält,
welche jetzt für
das zweite Verarbeitungsmittel 1.3 zur Verfügung stehen.
Der Pufferraum 2.1 umfasst weiterhin eine dritte Zone 2.3,
die dem ersten Verarbeitungsmittel zur Verfügung steht, um neue Daten zu
schreiben. Der Erzeuger-Zähler
writec gibt das Ende der ersten Zone 2.2 an und der Verbraucher-Zähler readc
zeigt auf das Ende der zweiten Zone 2.3.
-
Ein
Bereich 2.6 innerhalb der ersten Zone 2.2 und
der zweiten Zone 2.4 ist durch den Reservierungszähler readrsvc
in Kombination mit dem Synchronisierungszähler readc reserviert. Ein
Bereich 2.5 innerhalb der dritten Zone 2.3 ist
durch den Reservierungszähler
writersvc in Kombination mit dem Synchronisierungszähler writec
reserviert. Wie unter Bezugnahme auf die 3 und 4 veranschaulicht
wird, werden die Synchronisierungsinformationen mit dem ersten Synchronisierungszähler writec,
dem zweiten Synchronisierungszähler
readc und den Reservierungszählern
readrsvc und writersvc in Kombination mit anderen Informationen in
einer Kanalsteuereinheit einer Synchronisierungsschale gespeichert,
die mit der anwendungsspezifischen Vorrichtung 1.6 (in 3 mit 3.1 bezeichnet)
gekoppelt ist.
-
Bezug
nehmend auf 3 ist die anwendungsspezifische
Vorrichtung 3.1 über
eine Synchronisierungsschale 3.2 mit dem Bus 3.3 gekoppelt.
Auf diese Weise ist die anwendungsspezifische Vorrichtung 3.1 verantwortlich
für die
Berechnungsaufgaben, und die Synchronisierungsschale führt die
Kommunikationsaufgaben aus. Zu diesem Zweck umfasst die Synchronisierungsschale 3.2 einen
Busadapter 3.4, ein Signalregister 3.5 zum Speichern
der Identität
der Aufgaben, für
die die Synchronisierungsschale 3.2 eine Nachricht erhalten
hat. Die Synchronisierungsschale 3.2 umfasst weiterhin
Kanalsteuereinheiten 3.6, 3.7. Diese dienen zum
Umwandeln von Befehlen des Prozessors 3.1 in Signale für den Bus 3.3. Üblicherweise
wird eine anwendungsspezifische Vorrichtung 3.1 weniger
Aufgaben parallel ausführen
als dies der Fall bei einem programmierbaren Prozessor 3.1 ist.
-
4 zeigt
eine detailliertere Darstellung einer Kanalsteuereinheit 4.1 der
Synchronisierungsschale. Die Kanalsteuereinheit 4.1 umfasst
eine generische Bus-Master-Slave-Einheit 4.2,
eine Registerdatei 4.3 und eine Steuereinheit 4.4.
-
Der
Busadapter 3.4 und die generische Bus-Master-Slave-Einheit 4.2 koppeln
zusammen die Kanalsteuereinheit 4.1 mit dem Bus. Der Busadapter 3.4 sorgt
für eine
Anpassung von einem bestimmten Verbindungsnetzwerk, z.B. einem PI-Bus
oder einem AHB-Bus, an eine generische Schnittstelle. Die generische Bus-Master-Slave-Einheit 4.2 sorgt
für eine
Anpassung der Synchronisierungssignale an die genannte generische
Schnittstelle. Auf diese Weise ist es möglich, verschiedene Typen von
Kanalsteuereinheiten und verschiedene Busse mit einer relativ geringen
Anzahl von verschiedenen Komponenten zu unterstützen.
-
Die
Registerdatei 4.3 speichert die Synchronisierungsinformationen.
-
Falls
die Vorrichtungssynchronisierungsschnittstelle eines Prozessors 3.1 das
Signal Claim (Forderung) ausgibt, um eine Anzahl von schreibbaren
oder lesbaren Token im Puffer zu beanspruchen, überprüft die Steuereinheit 4.4,
ob diese Anzahl zur Verfügung
steht, indem sie den lokal gespeicherten Wert des Remnte-Zählers Remotec
mit seinem Reservierungszähler
localrsvc vergleicht. Die Bezeichnung remotec bedeutet writec für einen
Eingangskanal und readc für
einen Ausgangskanal. Die Bezeichnung localrsvc bezieht sich auf
readrsvc für
einen Eingangskanal und writersvc für einen Ausgangskanal.
-
Wenn
die Überprüfung bestätigend verläuft, wird
die Adresse eines Token Token Address zurückgesendet. Im anderen Fall
könnte
die Adresse der Obergrenze des für
den Prozessor 3.1 reservierten Pufferraums zurückgesendet
werden. Das Signal Token Valid gibt an, ob die Anforderung von Token
bestätigt
wurde, und die Synchronisierungsschnittstelle des Prozessors kann
das Signal Claim (Forderung) wieder anheben. Auf diese Weise kann
dem Prozessor bei jedem Zyklus eine Token-Adresse bereitgestellt
werden. Wenn das Ergebnis der ersten Verifizierung negativ ist,
liest die Kanalsteuereinheit 4.1 den durch die Adresse
remotecaddr angegebenen Remote-Zähler
und ersetzt den lokal gespeicherten Wert remotec durch den an dieser Adresse
gespeicherten Wert. Die Steuereinheit 4.4 überprüft jetzt
wieder, ob die beanspruchte Anzahl von Token zur Verfügung steht.
-
Wenn
die Anforderung fehlschlägt,
könnte
die Kanalsteuereinheit 4.1 entweder den Remote-Zähler regelmäßig in einem
Abfragebetrieb abfragen oder auf eine Unterbrechung durch den Prozessor
warten, mit dem sie in einem Unterbrechungsmodus kommuniziert. In
der Zwischenzeit kann sie mit einer anderen Aufgabe fortfahren.
Die Registerdatei in der Kanalsteuereinheit umfasst den Zeiger sgnl_reg_addr,
der die Signalregisteradresse der anderen Vorrichtung angibt, mit
der der Prozessor kommuniziert. Ein unterbrechender Prozessor kann
in dem Signalregister einer Vorrichtung einen Hinweis auf die Aufgabe
oder den Kanal hinterlassen, für
den die Unterbrechung stattfand.
-
Die
Variable inputchannel im Register gibt der Kanalsteuereinheit an,
ob der gegenwärtige
Kanal ein Eingangs- oder ein Ausgangskanal ist und welche dieser
Betriebsarten für
diesen Kanal ausgewählt
wird. Die Variablen maxtoken und tokensize geben die Gesamtzahl
der in dem Puffer zur Verfügung
stehenden Token bzw. die Größe der Token
in Bytes an.
-
Nach
einer erfolgreichen Anforderung wird die variable localrsvc entsprechend
der angeforderten Anzahl Token aktualisiert.
-
Anstelle
der variablen remotec könnte
die Registerdatei eine Variable um fassen, die die bei der letzten Verifizierung
berechnete Anzahl der verfügbaren
Token angibt.
-
Falls
der Prozessor 3.1 Release_req signalisiert, wird der lokale
Zähler
localc entsprechend dieser Anfrage aktualisiert. Dieser lokale Zähler localc
ist readc für
einen Eingangskanal und writec für
einen Ausgangskanal. Optional kann das Signal Release_req hoch gehalten
werden, so dass es dem Prozessor 3.1 erlaubt wird, die
Token jederzeit freizugeben. Dieses Signal könnte jedoch verwendet werden,
um ein Überfluten
der Steuereinheit zu verhindern, wenn sie kaum Zugriff auf den Bus
bekommt.
-
Alternativ
könnte
der Synchronisierungsprozess in Software impleinentiert werden,
indem eine Anforderungs- und eine Freigabefunktion verwendet wird.
Durch Ausführen
der Anforderungsfunktion fordert ein Prozessor eine Anzahl von Token
für einen
bestimmten Kanal an und wartet, bis die Funktion die Tokenadresse zurücksendet.
Durch Ausführen
der Freigabefunktion gibt der Prozessor eine Anzahl von Token für einen
bestimmten Kanal frei. Es könnten
separate Funktionen für
die Anforderung von Token zum Schreiben oder von Token zum Lesen
existieren. Auf ähnliche
Weise könnten
separate Funktionen für
die Freigabe verwendet werden.
-
Erfindungsgemäß wird eine
Kopie von mindestens einem Teil der Synchronisierungsinformationen
in dem gemeinsam genutzten Speicher geführt.
-
Die
als Kopie geführten
Informationen können
jegliche Informationen umfassen, die nützlich sind, um den Betrieb
des speziellen Prozessors nachzuvollziehen, zum Beispiel einen Wert
des Synchronisierungszählers,
der durch diesen Prozessor geführt
wird.
-
Die
Kopie in dem gemeinsam genutzten Speicher könnte beispielsweise gemäß der folgenden
Datenstruktur wie in der Sprache C spezifiziert vorgesehen sein:
-
Abgesehen
von den Synchronisierungszählerwerten
writec und readc und den Reservierungszählerwerten writersvc und readrsvc
umfasst diese Datenstruktur die folgenden Daten.
-
id
ist ein Wert, der den Kanal identifiziert, um ein Verarbeitungsschema
einschließlich
einer Vielzahl von Kanälen
zu ermöglichen,
zum Beispiel einen ersten Kanal zum Übertragen von Daten von einem
ersten Verarbeitungsmittel an ein zweites Verarbeitungsmittel, einen
zweiten Kanal zum Übertragen
von Daten von dem zweiten Verarbeitungsmittel an das erste Verarbeitungsmittel
und einen dritten Kanal zum Übertragen
von Daten von dem zweiten Verarbeitungsmittel an ein drittes Verarbeitungsmittel.
-
Der
Wert maxtokens gibt die Größe des Puffers
an, d.h. als Anzahl von Token, die in dem Puffer gespeichert werden
können.
-
Der
Wert flags gibt Eigenschaften des Kanals an, z.B., ob die Synchronisierung
auf Abfrage oder Unterbrechung basiert, und ob die Kanalpuffer direkt
oder indirekt zugewiesen sind. Als Alternative kann entschieden
werden, dem Kanal vorgegebene Eigenschaften zu verleihen, z.B. die
Implementierung auf eine unterbrechungsbasierende Synchronisierung
mit direkt zugewiesenen Puffern zu begrenzen. In diesem Fall kann
der Wert flags weggelassen werden.
-
Producer
und consumer sind Zeiger auf die Struktur, die die Aufgabe des ersten
Verarbeitungsmittels, des Erzeugers, und die Aufgabe des zweiten
Verarbeitungsmittels, des Verbrauchers, beschreibt.
-
Die
Aufgabenstruktur kann zum Beispiel enthalten
- – einen
Identifizierer für
die Aufgabe (wessen Aufgabenstruktur es ist)
- – einen
Funktionszeiger (wenn es eine Aufgabe auf einem eingebetteten Prozessor
ist; anschließend
kann nach dem Booten die root_task auf diese Funktion springen und
die Anwendung starten. Andernfalls leer.
- – einen
Vorrichtungstyp: um anzugeben, auf welcher Art von Vorrichtung die
Aufgabe laufen sollte.
-
Dies
ist für
den Bootvorgang von Nutzen: eine Aufgabe, die auf einem DSP oder
auf einem eingebetteten Prozessor läuft, muss auf unterschiedliche
Weise initialisiert werden als eine Aufgabe, die auf spezieller Hardware
läuft.
Indem man einen bedeutenderen Vorrichtungstyp hat, ist es leicht,
die geeignete Bootprozedur auszuwählen.
- – eine Vorrichtungsnummer:
Diese macht es möglich,
z.B. den ersten Hardware-Coprozessor von dem zweiten zu unterscheiden.
Dies kann erfolgen, indem ihnen eine eindeutige Nummer gegeben wird.
- – Anzahl
der Kanäle
- – eine
Liste der Zeiger auf Kanal-Datenstrukturen.
-
Wenn
z.B. eine UNIX-Aufgabe gestartet wird, kann sie auf diese Weise
zuerst ihre Aufgabenstruktur lesen und dann alle Informationen über alle
Kanäle,
die mit dieser Aufgabe verbunden sind. Das macht den Bootvorgang
wesentlich einfacher und verhindert, dass bei jedem Hinzufügen einer
Aufgabe ein Steuerungsprozess modifiziert werden muss, damit alle
Aufgaben die geeigneten Datenstrukturen laden. Die Ganzzahl token_size
gibt die Größe der Token
an, die über
den Kanal ausgetauscht werden.
-
Der
Zeiger bufbaseaddr bezieht sich auf die Basisadresse des Puffers
im Speicher.
-
Die
Zeiger CHP_channel_hwT·pchanregs
und CHP_channel_hwT·cchanregs
vereinfachen den Zugriff auf die Register einer Kanalsteuereinheit
durch Software. Es handelt sich einfach um Zeiger auf die physikalischen
Orte der Hardware-Register. Wenn eines der Felder 0 ist, bedeutet
dies, dass die entsprechende Aufgabe eine Software-Aufgabe ist.
-
Der
Vollständigkeit
halber besprechen wir auch den Fall, in dem zwei Hardware-Aufgaben
kommunizieren. In diesem Fall wird signaladdr des Erzeugers auf
die Adresse des Signalregisters in der Synchronisierungsschale des
Verbrauchers gesetzt und remotecaddr wird auf die Adresse des locale-Registers
der Verbraucher-Kanalsteuereinheit
gesetzt. Eine weitere Option besteht darin, remotecaddr auf das
Feld readc im Kanaldatensatz im gemeinsam genutzten Speicher zu
setzen, jedoch hat dies den Nachteil, dass der Wert des gelesenen
Remote-Zählers
leicht überholt
sein kann, weil die Schale des Verbrauchers den Speicher etwas später aktualisiert
als ihr lokales Register. Die Einstellung der Register für den Verbraucher
erfolgt genau andersherum.
-
Die
dynamische Neukonfiguration zieht eine Änderung der Topologie der Aufgabengraphik
nach sich, die eine bestimmte Anwendung darstellt. Das bedeutet
zum Beispiel, dass Aufgaben angehalten und entfernt werden können, und
dass bestimmte Kanäle
erneut mit anderen Aufgaben verbunden werden können. Das interessanteste Szenario
in diesem Zusammenhang ist, wenn ein bestimmter Kanal auf einer
Seite (Erzeuger oder Verbraucher) erneut mit einer anderen Aufgabe
verbunden wird und diese eine andere Implementierung aufweist. Zum
Beispiel war eine Erzeuger-Aufgabe (Hardware) mit einer Hardware-Verbraucher-Aufgabe
verbunden, und nach der Umkonfigurierung muss sie mit einer Software-Aufgabe
kommunizieren. In diesem Fall kann die Software-Aufgabe den Kanal
sofort nutzen, weil der Kanaldatensatz bereits vorhanden und aktuell ist.
Für die
Hardware-Aufgabe müssen
mehrere Felder in ihren Kanal-Verwaltungsregistern geändert werden, nämlich signaladdr
wird auf die Signalsteuereinheit-Adresse der CPU gesetzt, auf der
die neue Software-Aufgabe läuft.
-
remotecaddr
wird auf die Adresse des Feldes readc im Kanaldatensatz gesetzt.
Es ist zu beachten, dass dieser Schritt nicht erforderlich ist,
wenn er zuvor bereits der Fall war, obwohl zwei Hardware-Aufgaben kommunizierten.
-
Um
zu vermeiden, dass die Hardware-Aufgabe diese Register benutzt,
während
sie aktualisiert werden, wird sie zuerst angehalten und nach Abschluss
der Aktualisierungen wieder fortgesetzt.
-
Das
Umschalten des Kommunikationspartners einer Aufgabe von einer Hardware-Aufgabe
auf eine andere Hardware-Aufgabe lässt sich ebenfalls auf einfache
Weise mit einem Kanaldatensatz im Speicher ausführen. Die Register der Kanalsteuereinheit
der neuen Aufgabe werden einfach aus dem gemeinsam genutzten Speicher
hochgeladen, bevor gestartet wird.
-
Es
können
mehrere Aufgaben auf eine einzelne Hardware-Vorrichtung abgebildet
werden, z.B. DCT und IDCT. Beide Aufgaben können unterschiedliche Eingangs- und Ausgangskanäle haben
und benötigen
daher separate Kanalsteuereinheiten und Register. Oder wir können die
gleiche Gruppe von Registern in der Vorrichtungsschale benutzen,
um die Kanäle
für beide
Aufgaben zu implementieren, wodurch die Chipfläche reduziert wird. Ohne eine
Kopie der Verwaltungsinformationen im Speicher ist es erforderlich,
dass wenn eine Aufgabe ausgelagert wird, die Verwaltungsinformationen
ihrer Kanäle
explizit im Speicher gespeichert werden müssen, und nachdem sie wieder
geplant ist, können
die Verwaltungsinformationen der entsprechenden Kanäle aus dem
Speicher wieder in die Register zurückgebracht werden.
-
Bei
dem vorgeschlagenen Lösungsansatz
ist immer ein „Schattenstatus" der Kanalregister
im Speicher vorhanden, so dass die Aufgabenumschaltvorgänge in der
Hardware-Vorrichtung beschleunigt werden, weil der Status der Kanalverwaltungsinformationen
nicht gespeichert zu werden braucht. Außerdem bemerkt die Aufgabe,
die mit der ausgelagerten Aufgabe kommuniziert, niemals diese Aufgabenumschaltung,
weil sie weiterhin mit dem Kanaldatensatz des gemeinsam genutzten
Speichers arbeiten kann.
-
Es
ist anzumerken, dass der Schutzumfang der Erfindung nicht auf die
hier beschriebenen Ausführungsformen
beschränkt
ist. Ebenso wenig wird der Schutzumfang der Erfindung durch die
Bezugszeichen in den Ansprüchen
beschränkt.
Die Verwendung des Wortes "umfassen" (Englisch: "comprising") schließt das Vorhandensein
von anderen als in einem Anspruch erwähnten Elementen nicht aus.
Die Verwendung des Wortes "ein" oder "eine" (Englisch: "a" or "an") vor einem Element
schließt
das Vorhandensein einer Vielzahl (mehrerer) derartiger Elemente
nicht aus. Mittel, die einen Teil der Erfindung bilden, können sowohl
in Form spezieller Hardware oder in Form eines programmierten Universalprozessors
implementiert sein. Die Erfindung liegt in jedem neuen Merkmal oder
Merkmalkombination.
-
Text in der
Zeichnung
-
1
-
-
- RISC
- RISC
- Instr. Cache
- Anweisungs-Cache
- Data Cache
- Daten-Cache
- Memory (interface)
- Speicher (Schnittstelle)
- Peripheral
- Peripheriegeräte
- Bridge
- Brücke
- Addr. Dec.
- Adressdecodierer
- Local Mem.
- Lokaler Speicher
-
3
-
-
- Synchronization shell
- Synchronisierungsschale
- Bus
- Bus
- Bus adapter
- Busadapter
- Signal reg.
- Signalregister
- Channel controller
[Input]
- Kanalsteuereinheit
(Eingang)
- Channel controller
[Output]
- Kanalsteuereinheit
(Ausgang)
- Sync. IF
- Synch.-Schnittstelle
- Application specific
device
- Anwendungsspezifische
Vorrichtung
-
4
-
-
- Device synchronization
interface
- Vorrichtungssynchronisierungsschnittstelle
- Token address
- Token-Adresse
- Token valid
- Token gültig
- Release req.
- Freigabe-Aufforderung
- Release ack.
- Freigabe-Bestätigung
- Controller
- Steuereinheit
- Channel controller
- Kanalsteuereinheit
- Register file
- Registerdatei
- Generic bus Master
slave
- Generischer Bus Master-Slave
- Generic bus interface
- Generischer Bus Schnittstelle
- Local/localrsvc
- = readc/readrsvc für einen
Eingangskanal
Writec/writersvc für einen Ausgangskanal
- Remotec
- = writec für einen
Eingangskanal
Readc für
einen Ausgangskanal
