Prioritäten
-
Die Priorität aus PACT18 und PACT19 wird beansprucht.
Definitionen
-
Einem rekonfigurierbaren Baustein (VPU) werden an den
Eingängen und/oder Ausgängen Speicher zugeordnet, um eine
Entkopplung der internen Datenverarbeitung und i. b. der
Rekonfigurationszyklen von den externen Datenströmen (zu/von Peripherie,
Speichern etc) zu erreichen.
-
Aufgabe der Erfindung ist es, Neues für die gewerbliche
Nutzung bereitzustellen.
-
Unter einer rekonfigurierbaren Architektur werden vorliegend
Bausteine (VPU) mit konfigurierbarer Funktion und/oder
Vernetzung verstanden, insbesondere integrierte Bausteine mit
einer Mehrzahl von ein- oder mehrdimensional angeordneten,
arithmetischen und/oder logischen und/oder analogen und/oder
speichernden und/oder intern/extern vernetzenden Baugruppen,
die direkt oder durch ein Bussystem miteinander verbunden
sind.
-
Zur Gattung dieser Bausteine zählen insbesondere systolische
Arrays, neuronale Netze, Mehrprozessor-Systeme, Prozessoren
mit mehreren Rechenwerken und/oder logischen Zellen und/oder
kommunikativen/peripheren Zellen (IO), Vernetzungs- und
Netzwerkbausteine, wie z. B. Crossbar-Schalter, ebenso wie bekannte
Bausteine der Gattung FPGA, DPGA, Chameleon, XPUTER, etc.
Hingewiesen wird insbesondere in diesem Zusammenhang auf die
folgenden Schutzrechte und Anmeldungen desselben Anmelders: P 44 16 881.0-53,
DE 197 81 412.3, DE 197 81 483.2,
DE 196 54 846.2-53, DE 196 54 593.5-53, DE 197 04 044.6-53,
DE 198 80 129.7, DE 198 61 088.2-53, DE 199 80 312.9,
PCT/DE 00/01869, DE 100 36 627.9-33, DE 100 28 397.7,
DE 101 10 530.4, DE 101 11 014.6, PCT/EP 00/10516,
EP 01 102 674.7, PACT02, PACT04, PACT05, PACT08, PACT10,
PACT11, PACT13, PACT21, PACT13, PACT18, PACT19, PACT16,
PACT25, PACT27. Diese sind hiermit zu Offenbarungszwecken
vollumfänglich eingegliedert.
-
Die o. g. Architektur wird beispielhaft zur Verdeutlichung
herangezogen und im folgenden VPU genannt. Die Architektur
besteht aus beliebigen arithmetischen, logischen (auch
Speicher) und/oder Speicherzellen und/oder Vernetzungszellen
und/oder kommunikativen/peripheren (IO) Zellen (PAEs), die zu
einer ein- oder mehrdimensionalen Matrix (PA) angeordnet sein
können, wobei die Matrix unterschiedliche beliebig
ausgestaltete Zellen aufweisen kann; auch die Bussysteme werden dabei
als Zellen verstanden. Der Matrix als ganzes oder Teilen
davon zugeordnet ist eine Konfigurationseinheit (CT), die die
Vernetzung und Funktion des PA beeinflußt.
Stand der Technik
-
Speicherzugriffsverfahren für rekonfigurierbare Bausteine,
die nach einem DMA-Prinzip arbeiten, sind aus PACT01 bekannt,
wobei eine oder mehrere DMAs dabei durch Konfiguration
entstehen. In PACT03 sind DMAs fest in die Interface-Baugruppen
implementiert und können durch das PA oder die CT angesteuert
werden.
-
In PACT04 ist das Beschreiben von internen Speichern durch
externe Datenströme und das Wiederauslesen der Speicherdaten
an externe Einheiten beschrieben.
-
PACT13 beschreibt erweiterte Speicherkonzepte entsprechend
PACT04, um eine einfacher zu programmierende und
leistungsfähigere Datenübertragung zu erreichen.
-
In [Chameleon] wird ein Speichersystem beschrieben, das in
wesentlichen Punkten PACT04 entspricht. Zusätzlich beschreibt
[Chameleon] ein Verfahren zum Entkoppeln von externen
Datenströmen von der internen Datenverarbeitung derart, dass ein
Double-Buffer-Verfahren verwendet wird und jeweils ein Buffer
die externen Daten aufnimmt/ausliest, während ein anderer die
die internen Daten aufnimmt/ausliest, sobald die Buffer
entsprechend ihrer Funktion voll/leer sind, werden die Buffer
umgeschaltet, d. h. die vormals für die internen Daten
zuständige leiten nunmehr ihre Daten an die Peripherie (lesen neue
Daten von der Peripherie), und die vormals für die externen
Daten zuständige leiten nunmehr ihre Daten an das PA (lesen
neue Daten von dem PA).
-
Das erfindungsgemäße Verfahren erlaubt im Gegensatz dazu eine
wesentlich einfachere Kontrolle der Buffer. Ebenfalls werden
nur halb so viele Buffer benötigt; die Hardwarekosten
reduzieren sich nach Schätzungen um 25% bis 50%. Die
Adressgenerierung und Programmierung ist einfacher; die Buffer sind für
den Programmierer transparent. Die Hardware ist einfacher zu
beschreiben und debuggen.
Beschreibung der Erfindung
-
Aus PACT01, PACT03, PACT13 sind verschiedene Speichersysteme
als Interface zur IO bekannt. Weiterhin ist aus PACT04 ein
Verfahren bekannt, bei dem 1. Daten nach deren Berechnung
innerhalb einer VPU gespeichert werden, 2. das Array
umkonfiguriert wird, 3. die Daten aus dem internen Speicher
ausgelesen werden und wieder in einen anderen internen Speicher
geschrieben werden 4. so lange, bis das vollständig berechnete
Ergebnis an die IO gesendet wird.
-
Mit anderen Worten besteht ein wesentliches Arbeitsprinzip
der VPU-Bausteine darin, Daten zwischen mehreren Speichern
hin und her zu kopieren, wobei während jedes Kopiervorganges
andere Operationen über den Daten durchgeführt werden.
Abhängig von der jeweiligen Applikation werden die Daten aus einem
oder mehreren Speichern gelesen und in einen oder mehrere
Speicher geschreiben.
-
Vorzugsweise werden aus Performancegründen die internen
Speicher der VPU verwendet; grundsätzlich sind auch externe
Speicher verwendbar.
-
In der VPU-Technologie werden zum Speichern von Datenströmen
und/oder Zuständen (Trigger, vgl. PACT08, PACT13) die
internen/externen Speicher (z. B. als FIFOs) verwendet und
entsprechende Adressgeneratoren eingesetzt. Jede sinnvolle
Speicherarchitektur kann algorithmenspezifisch fest implementiert
und/oder flexibel konfiguriert werden/sein.
Entkopplung externer Datenströme
-
Erfindungsgemäß werden die externen Datenströme durch FIFOs
(Input-/Output-FIFO, zusammengefaßt IO-FIFO), die zwischen
der IO und dem Array eingesetzt sind, entkoppelt.
-
Das Datenverarbeitungsverfahren funktioniert wie folgt:
Durch einen oder mehrere Input-FIFO werden die eingehenden
Daten von der Datenverarbeitung im Array entkoppelt.
-
Die Datenverarbeitung erfolgt in folgenden Schritten:
- 1. Das/die Input-FIFO wird/werden vom Array ausgelesen,
verarbeitet und in einen oder mehrere andere Speicher
(RAM-Bank1) geschrieben.
- 2. Das Array wird umkonfiguriert. RAM-Bank1 wird
ausgelesen; die Daten werden verarbeitet und in einen oder
mehrere weitere Speicher (RAM-Bank2) (oder alternativ
bereits an die Output-FIFOs gemäß Schritt 4) geschrieben.
- 3. Das Array wird wieder umkonfiguriert, und die Daten
werden wieder in eine Speicherbank geschrieben.
- 4. So lange, bis das Ergebnis an einen oder mehrere Output-
FIFO zum Ausgang gesendert wird.
- 5. Danach werden wieder neue Daten von dem/den Input-FIFO
ausgelesen und entsprechend verarbeitet, d. h. die
Datenverabeitung wird bei Schritt 1 fortgesetzt.
-
Durch eine multi-ported-FIFO-Eigenschaft der Input-/Output-
FIFOs (IO-FIFOs) kann die Datenverarbeitung dabei zeitgleich
mit dem Einschreiben bzw. Auslesen der jeweiligen FIFOs durch
die IO-Kanäle erfolgen.
-
Dadurch entsteht eine zeitliche Entkopplung, die die
Verarbeitung von konstanten Datenströmen derart ermöglicht, daß
lediglich eine Latenz aber keine Unterbrechung des
Datenstromes auftritt.
-
In einer optimierten Ausgestaltung können die IO-FIFOs derart
aufgebaut sein, dass entsprechend der Applikation die Anzahl
der IO-FIFOs und deren Tiefe gewählt werden kann. Mit anderen
Worten können IO-FIFOs (z. B. über Transmission-Gate,
Multiplexer/Demultioplexer etc) zerteilt oder zusammengefaßt
werden sodass mehr oder tiefere IO-FIFOs entstehen.
Beispielsweise können 8 FIFOs zu je 1024 Worten implementiert sein,
die derart konfiguriert werden, dass entweder 8 FIFOs á 1024
Worte oder 2 FIFOs á 4096 Worte oder z. B. 1 FIFO mit 4096
Worten und 4 mit 1024 Worten konfiguriert sind.
-
Ja nach Ausgestaltung des Systems und Anforderungen der
Algorithmen sind Modifikationen des beschriebenen
Datenverarbeitungsverfahrens möglich.
FIFO-RAM-Bank-Kopplung
-
Je nach Applikation ist es möglich, den Datentransfer mit den
IO-FIFOs über eine weitere Speicherstufe zu führen und erst
dann an die datenverarbeitenden PAEs (z. B. ALU-PAEs nach
PACT02) weiterzuleiten. Die zusätzliche Speicherstufe kann
insbesondere durch Speicher-PAEs (RAM-PAEs nach PACT04,
PACT13, PCT/EP 00/10516) erfolgen. Insbesondere die
Ausgestaltung der RAM-Banken erfolgt vorzugsweise durch RAM-PAEs.
-
Durch die Verwendung von multi-ported-Speichern für die RAM-
PAEs kann das Einschreiben bzw. Auslesen von Daten von/zu den
IO-FIFOs wiederum zeitgleich erfolgen, sodass die RAM-PAEs
ihrerseits wiederum eine FIFO-Eigenschaft aufweisen können.
RAM-PAEs als FIFO
-
Besonders unter Ausnutzung von multi-ported-Speichern für die
PAE-RAMs entsteht die Möglichkeit, auf explizite FIFO-Stufen
zu verzichten und eine entsprechende Anzahl PAE-RAMs als FIFO
zu konfigurieren und die Daten der IO an die entsprechenden
Ports der Speicher zu führen. Diese Ausgestaltung kann als
besonders kosteneffizient angesehen werden, da keinerlei
zusätzliche Speicher vorgesehen werden müssen, sondern die in
ihrer Funktion und/oder Vernetzung konfigurierbaren Speicher
der VPU-Architektur (vgl. PACT04, PACT13, PCT/EP 00/10516)
entsprechend des Charakters konfigurierbarer Prozessoren
konfiguriert werden.
-
Grundsätzlich soll angemerkt sein, dass RAM-PAEs nach PCT/EP 00/10516
zusammengefasst werden können, sodass grössere
Speicherblöcke entstehen bzw. dass die RAM-PAEs derart arbeiten,
dass die Funktion eines größeren Speichers entsteht (z. B. aus
2512-Wort-RAM-PAEs ein 1024-Wort-RAM-PAE).
Mux/Demux vor/nach dem FIFO
-
Eingehende bzw. ausgehende Datenströme können aus einem
Datensatz oder mehreren Datensätzen erfolgen. Beispielsweise
benötigt die Funktion:
zwei eingehende Datenströme (a und b) und einen ausgehenden
Datenstrom (x).
-
Die Anforderung kann z. B. durch zwei Ansätze erfüllt werden:
- a) Es werden exakt so viele IO-Kanäle implementiert, wie
Datenströme erforderlich sind (vgl. PACT01, PACT03), oder
- b) durch die Verwendung von internen Speichern zur
Entkopplung der Datenströme, quasi als Registersatz (vgl. PACT13,
PACT04). Die unterschiedlichen Datenströme werden z. B. durch
ein Zeitmultiplexverfahren zwischen einem oder mehrere
Speicher und der IO (z. B. Speicher, Peripherie, etc)
ausgetauscht. Intern können die Daten dann ggf. parallel mit
mehreren Speichern ausgetauscht werden, sofern die IO-Daten beim
Transfer zwischen diesen Speichern und der IO entsprechend
sortiert (gesplittet) werden.
-
Der Ansatz a) wird erfindungsgemäß dadurch unterstützt, dass
eine ausreichende Anzahl von IO-Kanälen und IO-FIFOs zur
Verfügung gestellt wird. Allerdings ist dieser einfache Ansatz
unbefriedigend, da eine nicht exakt bestimmbare,
algorithmenabhängige und zudem sehr kostenaufwendige Anzahl von IO-Kanälen
zur Verfügung gestellt werden muß.
-
Daher ist der Ansatz b) oder eine geeignete Mischung aus a)
und b) vorzuziehen, z. B. 2 IO-Kanäle, ein Input und ein
Output, wobei auf jedem Kanal die Datenströme ggf. gemultiplext
werden.
-
Dabei wird es erforderlich, Multiplexer bzw. Demultiplexer
vorzusehen und die Datenströme von einem Datenkanal
aufzutrennen (z. B. aus dem Input-Kanal muß a und b abgetrennt
werden) oder mehrere Ergebniskanäle auf einen Output-Kanal
zusammenzuführen.
-
Hierzu können ein oder mehrere Multiplexer/Demultiplexer
(MuxDemux-Stufe) an verschiedenen Positionen angeordnet
werden, abhängig von der hardwaretechnischen Realisierung bzw.
den auszuführenden Funktionen. Zum Beispiel kann:
- a) eine MuxDemux-Stufe zwischen Input-/Output-Interface und
der FIFO-Stufe (IO-FIFO und/oder PAE-RAM als FIFO);
- b) eine MuxDemux-Stufe nach der FIFO-Stufe (IO-FIFO und/oder
PAE-RAM als FIFO), also zwischen FIFO-Stufe und PA;
- c) eine MuxDemux-Stufe zwischen IO-FIFO und RAM-PAEs
geschaltet werden. Beliebige, weitere Ausgestaltungen sind
möglich und einem Fachmann offensichtlich.
-
Die MuxDemux-Stufe kann ihrerseits entweder in Hardware fest
implementiert werden oder durch die geeignete Konfiguration
von beliebigen, entsprechend ausgebildeten PAEs entstehen.
Die Stellung der Multiplexer/Demultiplexer der MuxDemux-Stufe
wird von der Konfiguration und/oder dem Array und/oder der IO
selbst vorgegeben, wobei diese auch dynamisch, z. B. anhand
des Füllgrades des/der FIFOs beeinflußt werden kann.
Adressgenerierung
-
Adressen für interne oder externe Speicher werden durch
Adressgeneratoren berechnet. Beispielsweise können Gruppen
von PAEs entsprechend konfiguriert werden und/oder explizite
und ggf. gesondert und speziell implementierte
Adressgeneratoren (z. B. DMA wie aus DE 44 16 881 bekannt oder innerhalb
von Interface-Zellen (wie aus PACT03 bekannt) eingesetzt
werden. Mit anderen Worten können entweder fest implementierte
Adressgeneratoren, die in einer VPU integriert sind, oder
extern realisiert sind verwendet werden, und/oder die Adressen
durch eine Konfiguration von PAEs entsprechend den
Anforderungen eines Algorithmus berechnet werden.
-
Vorzugsweise können einfache Adressgeneratoren fest in den
IO-Zellen implementiert sein (PACT03). Zur Generierung
komplexer Adresssequenzen (z. B. nicht linear, multidimensional
etc) werden PAEs entsprechend konfiguriert und mit den IO-
Zellen verbunden. Derartige Verfahren mit den entsprechenden
Konfigurationen sind aus PCT/EP 00/10516 bekannt.
-
Konfigurierte Adressgeneratoren können dabei einer anderen
Konfiguration (ID, vgl. PACT10, PACT13, PACT17) als die
Datenverarbeitung angehören. Damit ist eine Entkopplung der
Adressgenerierung von der Datenverarbeitung möglich, womit
beispielsweise Adressen bereits generiert und die
entsprechenden Daten bereits geladen werden können, bevor oder
während die datenverarbeitenden Konfiguration konfiguriert wird.
Entsprechend können Ergebnisdaten und deren Adressen noch
bearbeitet werden, während oder nachdem die
datenverarbeitende/-generierende Konfiguration entfernt wird. Insbesondere
ist es möglich, durch den Einsatz von Speichern und/oder
Puffern, wie z. B. die nachfolgend beschriebenen FIFOs die
Datenverarbeitung weiter von den Speicher- und/oder IO-Zugriffen
zu entkoppeln.
-
Besonders leistungsfähig ist eine Zusammenschaltung von fest
implementierten Adressgeneratoren (HARD-AG) (PACT03) und
konfigurierbaren Adressgeneratoren im PA (SOFT-AG) derart, dass
für die Realisierung einfacher Adressierungsschematas die
HARD-AG verwendet werden und komplizierte Sprünge durch die
SOFT-AG berechnet und dann an die HARD-AG geschrieben werden.
Mit anderen Worten können die einzelnen Adressgeneratoren
sich gegenseitig überladen und neu setzen.
IO-Zellen nach PACT03
-
Erfindungsgemäß wird weiterhin eine besondere Ausgestaltung
der IO-Zellen nach PACT03 vorgeschlagen. Dabei sind die
Zellen derart zu modifizieren, daß generierten Adressen i. B. in
SOFT-AG generierten Adressen ein bestimmtes Datenpaket
zugeordnet wird.
-
Für Schreibzugriffe (die VPU sendet Daten an externe IO, z. B.
Speicher/Peripherie o. ä.) ist es hinreichend, den Adressoutput
mit dem Datenoutput zu verknüpfen, d. h. ein Datentransfer mit
der IO findet exakt dann statt, wenn an der IO-Zelle ein
gültiges Adresswort und ein gültiges Datenwort ansteht, wobei
die beiden Worte von unterschiedlichen Quellen stammen
können. Zur Kennzeichnung der Gültigkeit kann beispielsweise ein
Handshake-Protokoll nach PACT02 oder PACT18 (RDY/ACK)
verwendet werden. Durch eine geeignete, logische Verknüpfung (z. B.
"AND") der RDY-Signale von Adresswort und Datenwort ist das
Vorhandensein beider gültiger Worte erkennbar, und der IO-
Zugriff kann durchgeführt werden. Mit der Durchführung des
IO-Zugriffes kann die Quittierung der Daten- und Adressworte
erfolgen, indem das entsprechende ACK für die beiden
Transfers generiert wird. Der IO-Zugriff, bestehend aus Adresse und
Daten sowie ggf. den dazugehörenden Statussignalen, kann
erfindungsgemäß in Output-FIFOs entkoppelt werden.
Bussteuersignale werden vorzugsweise in einer zwischen Output-FIFO und
externem Interface liegenden Schaltung generiert.
-
Für Lesezugriffe (die VPU empfängt Daten von externer IO,
z. B. Speicher/Peripherie o. ä.) werden zunächst die Adressen
für den Zugriff von einem Adressgenerator (HARD-AG und/oder
SOFT-AG) generiert und der Adresstransfer durchgeführt. Die
Lesedaten können im selben Takt oder bei hohen Frequenzen
auch gepipelinet einen oder mehrere Takte später eintreffen.
Sowohl die Adressen als auch die Daten können durch IO-FIFOs
entkoppelt werden.
-
Zur Quittierung der Daten kann das bekannte RDY/ACK-Protokoll
verwendet werden, das auch gepipelinet verwendet werden kann
(siehe PACT03, PACT07, PACT13, PACT17, PACT18).
-
Zur Quittierung der Adressen kann ebenfalls das bekannte
RDY/ACK-Protokoll verwendet werden. Eine Quittierung der
Adresse durch den Empfänger bewirkt jedoch eine sehr große
Latenzzeit, die sich negativ auf die Performance von VPUs
auswirken kann. Die Latenzzeit kann umgangen werden, indem
die IO-Zelle den Empfang der Adresse quittiert und die
Synchronisation des Eingangs der der Adresse zugeordneten Daten
mit dem Adresse übernimmt. Die Quittierung und
Synchronisation kann durch eine beliebige, geeignete Schaltung erfolgen.
Zwei mögliche Ausgestaltungen sind im Folgenden näher
ausgeführt:
a) FIFO
-
Ein FIFO speichert die ausgehenden Adresszyklen der externen
Bustransfers. Mit jedem als Antwort auf einen externen
Buszugriff eingehenden Datenwort wird der FIFO entsprechend
gelehrt. Durch den FIFO-Charakter entspricht die Reihenfolge
der ausgehenden Adressen der Reihenfolge der ausgehenden
Datenworte. Die Tiefe des FIFOs (also die Zahl der Einträge)
wird vorzugsweise an die Latenzzeit des externen Systems
angepaßt, sodass jede ausgehende Adresse ohne Latenz quittiert
werden kann und der optimale Datendurchsatz erreicht wird.
Eingehende Datenworte werden entsprechend des FIFO-Eintrags
quittiert. Wenn der FIFO voll ist, kann das externe System
keine weiteren Adressen mehr annehmen, und die aktuelle,
ausgehende Adresse wird so lange nicht quittiert und damit
gehalten, bis Datenworte eines vorhergehenden Bustransfers
eingegangen sind und ein FIFO-Eintrag entfernt wurde. Ist der FIFO
leer, wird kein gültiger Bustransfer ausgeführt, und ggf.
eintreffende Datenworte werden nicht quittiert.
b) Creditcounter
-
Jede ausgehende Adresse von externen Bustransfers wird
quittiert und zu einem Zähler dazuaddiert (Creditcounter).
Eingehende Datenworte als Antwort auf einen externen Bustransfer
werden von dem Zähler abgezogen. Erreicht der Zähler
einen definierten Höchswert, kann das externe System keine
weiteren Adressen mehr annehmen, und die aktuelle, ausgehende
Adresse wird so lange nicht quittiert und damit gehalten, bis
Datenworte eines vorhergehenden Bustransfers eingegangen sind
und der Zähler dekrementiert wurde. Ist der Zählerstand null,
wird kein gültiger Bustransfer ausgeführt, und ggf.
eintreffende Datenworte werden nicht quittiert.
Burst-Buszugriffe
-
Moderne Bussysteme und SoC-Bussysteme transferieren große
Datenmengen mittels Burst-Sequenzen. Dabei wird zunächst eine
Adresse übertragen und dann für eine Anzahl von Takten
ausschließlich Daten transferiert (siehe AMBA-Specification 2.0,
ARM Limited). Zur korrekten Durchführung von Burst-Zugriffen
sind mehrere Aufgaben zu lösen:
1. Erkennen von Burstzyklen
-
Lineare Buszugriffe, die in Bursts umgewandelt werden können,
müssen erkannt werden, um Bursttransfers auf dem externen Bus
auszulösen. Zur Erkennung linearer Adressfolgen kann ein
Zähler (TCOUNTER) eingesetzt werden, der zunächst mit einer
ersten Adresse eines ersten Zugriffes geladen wird und nach
jedem Zugriff linear auf/ab zählt. Sofern die darauffolgende
Adresse dem Zählerstand entspricht, liegt eine lineare und
burstfähige Reihenfolge vor.
2. Abbruch an Boundaries
-
Manche Bussysteme (z. B. AMBA) lassen Bursts (a) nur bis zu
einer bestimmten Länge bzw. (b) nur bis zu bestimmten
Adressgrenzen (z. B. 1024 Adress-Blöcke) zu. Für (a) kann ein
einfacher Zähler implementiert werden, der vom ersten
Buszugriff an die Anzahl der Datenübertragungen zählt und bei
einem bestimmten Wert, der der maximalen Länge der
Bursttransfers entspricht, z. B. mittels eins Vergleichers die
Boundarygrenze signalisiert. Für (b) kann das entsprechende Bit (z. B.
für 1024 Adress-Grenzen das 10.bit), das die Boundarygrenze
darstellt, zwischen TCOUNTER und der aktuellen Adresse
verglichen werden (z. B. mittels einer XOR-Funktion). Ist das Bit
in TCOUNTER ungleich dem Bit in der aktuellen Adresse, lag ein
Übergang über eine Boundarygrenze vor, der entsprechend
signalisiert wird.
3. Festlegen der Länge
-
Sofern das externe Bussystem keine Angabe zur Länge eines
Burstzyklus benötigt, ist es empfehlenswert, Bursttransfers
unbestimmter Länge durchzuführen (vgl. AMBA). Werden
Längenangaben erwartet und/oder bestimmte Burstlängen vorgegeben,
kann folgendermassen vorgegangen werden: Die zu übertragenden
Daten sind anhand der Anzahl der Lese/Schreib-Adressen im IO-
FIFO bekannt. Die Bustransfers können nunmehr derart in fixe
Burstlängen unterteilt werden, dass diese vor den einzelnen
Bursttransfers bekannt sind und bei der Einleitung der Bursts
angegeben werden können, wobei vorzugsweise zunächst
Bustransfers der maximalen Burstlänge gebildet werden, und wenn
die Anzahl der FIFO-Einträge nicht mehr ausreicht, jeweils
eine nächst kleinere Burstlänge verwendet wird. Beispielsweise
können 10 FIFO-Einträge bei einer maximalen Burstlänge von 4
mit 4,4,2 Bursttransfers übertragen werden.
4. Error Recovery
-
Manche externen Bussysteme (vgl. AMBA) sehen Verfahren zur
Fehlerbeseitigung vor, wobei beispielsweise fehlgeschlagene
Bustransfers wiederholt werden. Die Information, ob ein
Bustransfer fehlgeschlagen ist, wird am Ende eines Bustransfers
übertragen, quasi als Quittung für den Bustransfer. Um einen
Bustransfer zu wiederholen, ist es nunmehr erforderlich, dass
sämtliche Daten noch zur Verfügung stehen. Erfindungsgemäß
wird vorgeschlagen, dazu die FIFOs derart zu modifizieren,
dass der Lesezeiger vor jedem Bursttransfer gespeichert wird.
Sofern ein Fehler auftrat, wird der Lesezeiger wieder auf die
zuvor gespeicherte Position gesetzt, und der Bursttransfer
wiederholt. Trat kein Fehler auf, wird der nächste
Bursttransfer durchgeführt und der Lesezeiger entsprechend neu
gespeichert. Um zu verhindern, dass der Schreibzeiger in einen
aktuellen Bursttransfer gelangt und damit Werte überschrieben
werden, die evtl. bei einer Wiederholung des Bursttransfers
noch benötigt werden, wird der Vollzustand des FIFOs durch
den Vergleich des gespeicherten Lesezeigers mit dem
Schreibzeiger festgestellt. Das in PACT18 beschriebene FIFO-System
entspricht beispielsweise dieser Ausgestaltung. PACT18 ist zu
Offenbarungszwecken hiermit vollumfänglich eingegliedert.
Optimierte Speicherzugriffe
-
Eine Grundeigenschaft der rekonfigurierbaren VPU-Architektur
ist die Möglichkeit, Rekonfiguration und Datenverarbeitung zu
überlagern (vgl. PACT01, PACT02, PACT04, PACT05, PACT10,
PACT13, PACT17, PACT16). Mit anderen Worten kann:
- a) z. B. während einer Datenverarbeitung bereits die nächste
Konfiguration vorgeladen werden;
- b) z. B. während eine Anzahl von konfigurierbaren Elementen
einer bestimmten Konfiguration noch nicht konfiguriert sind,
bzw. gerade konfiguriert werden, die Datenverarbeitung in
anderen bereits konfigurierten Elementen bereits beginnen;
- c) z. B. die Konfigurationen verschiedener Aktivitäten derart
entkoppelt oder überlagert werden, dass diese unter optimaler
Performance gegeneinander zeitversetzt ablaufen (vgl. 8.1
Adressgenerierung).
-
Moderne Speicherprotokolle (z. B. SDRAM, DDRAM, RAMBUS) weisen
zumeist folgenden oder einen in der Wirkung ähnlichen Ablauf
auf:
- 1. Initialisierung eines Zugriffes mit Adressangabe.
- 2. Lange Latenzzeit.
- 3. Schnelle Übertragung von Datenblöcken, zumeist als Burst.
-
Diese Eigenschaft kann in der VPU-Technologie performance-
effizient ausgenutzt werden. Beispielsweise ist es möglich,
die Berechnung der Adresse und die Initialisierung des
Speicher-Zugriffes von der Datenverarbeitung derart zu trennen,
dass verschiedene (zeitliche) Konfigurationen entstehen. Zur
Optimierung der Performance wird folgendes Verfahren
vorgeschlagen:
Es soll die Applikation AP ausgeführt werden, die aus einer
Vielzahl von Konfigurationen (ap = 1. . .) besteht. Weiterhin
werden auf der VPU weiter Applikationen/Konfigurationen
ausgeführt, die unter WA zusammengefaßt sind:
- 1. zunächst werden (in einer ap. Konfiguration von AP) die
Lese-Adressen berechnet, die Datentransfers und die IO-FIFOs
initialisiert;
- 2. die für AP übertragenen und inzwischen in den IO-FIFOs
vorhanden Daten werden (in einer ap + 1. Konfiguration)
verarbeitet und ggf. in FIFOs/Puffer/Zwischenspeicher/etc.
abgelegt;
- 3. die Berechnung der Ergebnisse kann mehrere
Konfigurationszyklen (n) erfordern, an deren Ende die Ergebnisse in einem
IO-FIFO gespeichert sind;
- 4. die Adressen der Ergebnisse werden berechnet und der
Datentransfer initialisiert; dies kann parallel oder später in
derselben oder einer ap + n + 2. Konfiguration erfolgen; zugleich
oder zeitlich versetzt werden dann die Daten aus den IO-FIFOs
in die Speicher geschrieben.
-
Zwischen den Schritten 1-4 können beliebige Konfiguration aus
WA ausgeführt werden, sofern zwischen den Schritten eine
Wartezeit notwendig ist, da Daten noch nicht zur Verfügung
stehen.
-
Ebenfalls können während der Schritte 1-4 parallel zu der
Verarbeitung von AP Konfigurationen aus WA ausgeführt werden,
sofern AP die für WA benötigten Ressourcen nicht verwendet.
-
Dieser Ablauf kann insbesondere von dem
Datenverarbeitungsverfahren nach PACT19 effizient genutzt werden.
Besondere Erweiterungen von Compilern
-
Zur Generierung von Konfigurationen werden Compiler
eingesetzt, die auf einem beliebigen Rechnersystem ablaufen.
Typische Compiler sind z. B. C-Compiler oder für die
VPU-Technologie NML-Compiler. Besonders geeignete Compilerverfahren
sind z. B. in PACT11, PACT20, PACT27 beschrieben.
-
Der Compiler soll dabei folgende Besonderheiten beachten:
Trennung der Adressierung in:
- 1. externe Adressierung, also die Datentransfers mit
externen Baugruppen;
- 2. interne Adressierung, also die Datentransfers zwischen
PAEs, i. b. zwischen RAM-PAEs und ALU-PAEs;
- 3. desweiteren soll die zeitliche Entkopplung besondere
Beachtung finden.
-
Bustransfers werden in interne und externe Transfers zerlegt:
- 1. Externe Lesezugriffe werden in eine separate
Konfiguration übersetzt. Die Daten werden von einem externen Speicher
in einen internen transferiert.
- 2. Interne Zugriffe werden mit der Datenverarbeitung
gekoppelt, d. h. die internen Speicher werden für die
Datenverarbeitung gelesen, bzw. beschrieben.
- 3. Externe Schreibzugriffe werden in eine separate
Konfiguration übersetzt. Die Daten werden von einem internen
Speicher in einen externen transferiert.
-
Wesentlich ist, dass die bt1, bt2, bt3 in unterschiedliche
Konfigurationen übersetzt werden können und diese ggf. zu
einem unterschiedlichen Zeitpunkt ausgeführt werden.
-
Das Verfahren soll an dem nachfolgenden Beispiel verdeutlicht
werden:
-
Die Funktion wird vom Compiler in drei Teile bzw.
Konfigurationen (subconfig) transformiert:
example#dload: Lädt die Daten von extern (Speicher,
Peripherie etc.) und schreibt diese in interne Speicher. Interne
Speicher sind mit r# und dem Namen der ursprünglichen
Variable gekennzeichnet.
example#process: Entspricht der eigentlichen
Datenverarbeitung. Diese liest die Daten aus internem Operanden und
schreibt die Ergebnisse wieder in interne Speicher.
example#dstore: Schreibt die Ergebnisse aus dem internen
Speicher nach extern (Speicher, Peripherie etc.).
-
Ein wesentlicher Effekt des Verfahrens ist, dass anstatt i.j
= 100.100 = 10.000 externe Zugriffe nur i + j = 100 + 100 =
200 externe Zugriffe zum Lesen der Operanden ausgeführt
werden. Diese Zugriffe sind zudem noch vollkommen linear, was
die Transfergeschwindigkeit bei modernen Bussystemen (Burst)
und/oder Speichern (SDRAM, DDRAM, RAMBUS, etc) erheblich
beschleunigt.
-
Die internen Speicherzugriffe erfolgen parallel, da den
Operanden unterschiedliche Speicher zugewiesen wurden.
-
Zum Schreiben der Ergebnisse sind i = 100 externe Zugriffe
notwendig, die ebenfalls wieder linear mit maximaler
Performance erfolgen können.
-
Wenn die Anzahl der Datentransfers vorab nicht bekannt ist
(z. B. WHILE-Schleifen) oder sehr groß ist, kann ein Verfahren
verwendet werden, das bei Bedarf durch Unterprogrammaufrufe
die Operanden nachlädt bzw. die Ergebnisse nach extern
schreibt. Dazu werden die Zustände der FIFOs abgefragt:
"empty" wenn das FIFO leer ist, sowie "full" wenn das FIFO voll
ist. Entsprechend der Zustände reagiert der Programmfluß. Zu
bemerken ist, dass bestimmte Variablen (z. B. ai, bi, xi)
global definiert sind. Zu Performanceoptimierung kann ein
Scheduler entsprechend der bereits beschriebenen Verfahren die
Konfigurationen example#dloada, example#dloadb bereits vor
dem Aufruf von example#process bereits ausführen, sodass
bereits Daten vorgeladen sind. Ebenso kann example#dstore(n)
nach der Terminierung von example#process noch aufgerufen
werden, um r#x zu leeren:
-
Die Unterprogrammaufrufe und das Verwalten der globalen
Variablen sind für rekonfigurierbare Architekturen
vergleichsweise aufwendig. Daher kann die nachfolgende Optimierung
durchgeführt werden, in welcher sämtliche Konfigurationen
weitgehend unabängig ablaufen und nach vollständiger
Abarbeitung terminieren (terminate). Da die Daten b[j] mehrfach
erforderlich sind, muß example#dloadb entsprechend mehrfach
durchlaufen werden. Dazu werden beispielsweise zwei
Alternativen dargestellt:
Alternative 1: examplehdloadb terminiert nach jedem Durchlauf
und wird von example#process für jeden Neustart neu
konfiguriert.
Alternative 2: examplehdloadb läuft unendlich und wird von
examplehprocess terminiert.
-
Während "idle" ist eine Konfiguration untätig (wartend):
-
Zur Vermeidung von Wartezyklen können Konfigurationen auch
terminiert werden, sobald sie ihre Aufgabe nicht erfüllen
können. Die entsprechende Konfiguration wird von dem
rekonfigurierbaren Baustein entfernt, verbleibt jedoch im Scheduler.
Hierzu wird im Folgenden der Befehl "reenter" verwendet. Die
relevanten Variablen werden vor der Terminierung gesichert
und bei der wiederholten Konfiguration wiederhergestellt:
Begriffsdefinition für Systems on a Chip (SoC)
-
Für SoC sind die Begriffe "intern" und "extern" nicht in der
gewöhnlichen Terminologie verwendbar, wenn beispielsweise
eine VPU mit weiteren Baugruppen (z. B. Peripherie, anderen
Prozessoren und i. b. Speicher) auf einem einzigen Chip gekoppelt
wird.
-
Daher soll folgenden Begriffdefinition gelten:
intern: Innerhalb einer VPU-Architektur bzw. zur
VPU-Architektur und IP gehörende Bereiche.
extern: Außerhalb einer VPU-Architektur, d. h. alle sonstigen
Baugruppen z. B. Peripherie, anderen Prozessoren und i. b.
Speicher) auf einem SoC und/oder außerhalb des Chips, in dem
sich die VPU-Architektur befindet.