-
Gebiet der
Erfindung
-
Die
Erfindung betrifft eine MAP-Codierung ("MAP = Maximum A Posteriori") und Architekturen
dafür. MAP
wird üblicherweise
beim Kanalcodieren der Übertragung
digitaler Daten verwendet. Stand der Technik sind bei der Kanalcodierung
serielle, parallele und hybrid konkatenierte Codes. Die Codekonkatenation
ist ein effektives Mittel zum Verbessern des Codiergewinns bei einem
moderaten Anstieg der Decodierkomplexität. Konkatenierte Codes bestehen
aus mehreren Komponentencodes. Der Decoder umfasst dementsprechend mehrere
konkatenierte Komponentendecoder. Das Informationshandover wird
am besten mit Soft-Decision durchgeführt, im Gegensatz zu Hard-Decision.
Im Gegensatz zu Hard-(Decision)-Ausgaben,
die nur Anzeigen, von welchen Symbolen der Komponentendecoder annimmt,
dass sie gesendet wurden, enthalten Soft-(Decision)-Ausgaben auch
eine Messung für
diese Annahme. Offensichtlich kann ein Decoder Vorgänger- Softdecisions wesentlich
besser auswerten als Harddecisions, da ein Hard-Decision-Handover
das Verwerfen möglicherweise
nützlicher
Informationen bedeutet. Neben dem konkatenierten Kanaldecodieren
werden Soft-Informationen auch für
andere kürzlich
vorgeschlagene Konkatenationsschemata benötigt: Konkateniertes Kanal- und
Quelldecodieren sowie konkateniertes Ausgleichs- und Kanaldecodieren.
-
Der
MAP-Decodieralgorithmus ist ein Maximum-Likelihood-Decodierverfahren,
das die Wahrscheinlichkeit von Symbol-(oder Bit-)Fehlern minimiert.
Mit anderen Worten, ein MAP-Decoder findet das wahrscheinlichste
Informationsbit, das übertragen
worden ist, eine empfangene verrauschte oder verzerrte Sequenz vorausgesetzt,
wodurch die Bitfehlerrate ("BER
= Bit Error Rate")
minimiert wird.
-
Dies
unterscheidet ihn von einem Viterbi-Decoder, der die wahrscheinlichste
codierte Sequenz findet. Vor allem bietet der MAP-Decoder inhärent einen
Soft-Ausgang, der auf effektive Weise zum Decodieren konkatenierter
Codes verwendet werden kann.
-
Die
Verwendung des MAP-Algorithmus optimiert den Codiergewinn im Gegensatz
zu dem SOVA ("SOVA
= Soft-Output Viterbi Algorithm"/Soft-Ausgabe-Viterbi-Algorithmus)
(siehe die Veröffentlichung
von J. Hagenauer und P. Hoeher "A
Viterbi Algorithm with Soft-Decision Outputs and its Applications" in Proc. Globecom '98, Seiten 1680–1686, November
1989), der qualitativ schlechtere Soft-Ausgaben liefert. Dies ist
insbesondere für
die neuesten iterativen Codierkonkatenationsschemata wichtig, zum
Beispiel für
die so genannten "Turbo-Codes" (siehe die Veröffentlichung
von C. Berrou, A. Glavieux, und P. Thitimajshima "Near Shannon Li mit
Error-Correcting Coding and Decoding: Turbo-Codes" in Proc. ICC '93, Seiten 1064–1070, Genf, Schweiz,
Mai 1993).
-
Hintergrund
der Erfindung
-
In
letzter Zeit wird in digitalen Kommunikationen das MAP oft für den Viterbi-Algorithmus
(oder für
den Soft-Output-VA)
aufgrund dessen besseren Decodierleistung eingesetzt. Zukünftige Multimediaanwendungen benötigen hohe
Datenraten. Obwohl sie im Vergleich mit Softwarelösungen eine
geringere Flexibilität
aufweisen, sind Hardwareimplementationen von berechnungsintensiven
Digitalsignalverarbeitungsalgorithmen oft aufgrund der hohen Durchsatzanforderungen
obligatorisch. Implementationen mit niedrigem Energieverbrauch (Leistungsverbrauch)
sind für
batteriegespeiste tragbare Geräte
notwendig. Demnach sind Hochgeschwindigkeits-MAP-Implementationen
mit niedrigem Energieverbrauch ein wichtiger Baustein für tragbare Multimediageräte. Der
Energieverbrauch von Hochgeschwindigkeitsimplementationen wird in
erster Linie durch die Speichergröße bestimmt.
-
Architekturversuche
haben gezeigt, dass bis zu 50–80
Prozent der Bereichskosten in (anwendungsspezifischen) Architekturen
zur Echtzeitsignalverarbeitung aufgrund der Speichereinheiten anfallen.
Die Leistungskosten werden sogar noch stärker durch die Speicherung
und durch die Übermittlungen
von komplexen Datentypen dominiert. Kleinere On-Chip-Speicher werden, wenn auf sie in
FIFO-Weise ("FIFO
= First-In First-Out"/"Zuerst hinein zuerst
heraus") zugegriffen
wird, oft als Registerketten implementiert, die aufgrund der hohen
Takt-Nutzlast und Schaltaktivität
leistungshungrig sind. Der Energieverbrauch hängt linear sowohl von der Schaltrate
als auch von der -kapazität
ab und kann demzufolge sehr effektiv durch das Minimieren der FIFO-Speichergröße reduziert
werden. Demnach ist die Speicherübermittlungs-
und -größenoptimierung
auf Architekturebene eine notwendige Vorbedingung dafür, bereichs-
und energieeffiziente Hochgeschwindigkeits-Decoderimplementationen
zu erhalten. Dies gilt insbesondere für einen Hochgeschwindigkeits-MAP-Decoder,
der ziemlich viel Speicher für
die Vorwärts-Rückwärtsstruktur
des Algorithmus und aufgrund eines starken Pipelinings benötigt.
-
Der
MAP-Algorithmus ist gut bekannt und wird hier im Detail nicht erläutert (mehr
Details kann man in den zwei zuletzt erwähnten Publikationen in dem
Abschnitt "Hintergrund
der Erfindung" finden).
-
Der
MAP-Algorithmus berechnet die Wahrscheinlichkeit des Quellsymbols
Ik an dem Index k, wobei k die Position
des Quellsymbols Ik innerhalb eines Satzes
von Quellsymbolen anzeigt, in Abhängigkeit von dem Wissen um
die empfangene verzerrte Symbolsequenz z0 N =
(z0, z1, ..., zk, ..., zN):
P(Ik|z0 N) (1)
-
Die
Ausgabe des MAP-Algorithmus Λk = log{Pr(Ik = 1|z0 N)/Pr(Ik =
0|z0 N)} (2)wird LLR
("LLR = Log-Likelihood
Ratio"/Logarithmisches
Wahrscheinlichkeitsverhältnis)
bezeichnet. Die Berechnung von P(Ik|z0 N) wird durch das
Bestimmen der Wahrscheinlichkeit durchgeführt, einen bestimmten Codiererzustand
m nach dem Empfang von k Symbolen z0 k-1 = (z0, z1, ..., zk-1): erreichen: αk(m)
= Pr{m|z0 k-1} (3)und der Wahrscheinlichkeit,
von dem Codiererzustand m' zu
dem Endzustand mit den Symbolen zk+1 N: zu gelangen: βk+1(m')
= Pr{zk+1 N|m'} (4)
-
Die
Wahrscheinlichkeit des Übergangs
m zu m' unter Verwendung
des Quellsymbols Ik unter dem Wissen um
das empfangene Symbol zk wird γk genannt: γk(m,
m', Ik)
= Pr{m, m', Ik|zk}. (5)
-
Die
Wahrscheinlichkeiten α und β kann man
rekursiv über γk finden,
die eine Funktion des empfangenen Symbols und des Kanalmodells sind.
Mit der Kenntnis um diese Werte für jedes m, m' ist die Wahrscheinlichkeit,
das Symbol Ik in Schritt k gesendet zu haben,
die Summe über
alle Pfade unter Verwendung des Symbols Ik. ϕ(Ik) ist der Satz aller Übergänge mit dem Symbol Ik:
-
-
Diese
Gleichung gilt sowohl für
NSC- als auch für
RSC-Codes. RSC-Codes
sind für
Turbocodieren wesentlich.
-
Die
Rekursionsformeln für
die Vorwärtspfadmetriken
lauten αk(m)
= Σm'αk-1(m')·γk-1(m', m, Ik). (7)
-
Für die Rückwärtspfadmetriken βk(m)
= Σm'γk(m,
m', Ik)·βk+1(m'). (8)
-
Und
für die "Soft-Ausgaben" (Log-Likelihood
Ratio) Λk =
log(Σ(m,m')α(m)γk 1(m, m',
Ik)βk+1(m')/Σ(m,m')αk(m)γk 0(m, m',
Ik)βk+1(m')) (9)
-
Es
wurde in P. Robertson, P. Höher,
und E. Villeburn "Optimal
and Sub-Optimal Maximum a Posteriori Algorithms Suitable for Turbo
Decoding" ETT, 8
(2) : 119–125,
1997, gezeigt, dass es Vorteilhaft ist, in MAP-Algorithmus in der
Logarithmikdomäne
(Log-MAP) zu implementieren, um numerische Probleme zu vermeiden, ohne
das Decodierleistungsverhalten zu verschlechtern. Dies vereinfacht
die arithmetischen Operationen: Die Multiplikation wird zur Addition
und die Addition wird zu dem max*-Operator. Für den gesamten Rest dieses Dokumentes
werden die Definitionen δ =
log α, ε = log β, μ = log γ zur vereinfachten
Notierung eingeführt.
-
MAP-Algorithmusimplementationen
auf kundenspezifischer Hardware wurden in H. David, G. Gehnen, und
H. Meyr, "MAP Channel
Decoding: Algorithm and VLSI Architecture" in VLSI Signal Processing VI, Seiten
141–149,
IEEE, 1993 dargestellt. Deren Architektur wird im Folgenden als
D-Architektur bezeichnet. Eine neuere Herangehensweise wurde durch
A. Worm, H. Lamm, und N. Wehn, "A
High-Speed MAP Architecture with Optimized Memory Size and Power
Consumption", in
Proc. SiPS 2000, Oktober 2000, durchgeführt. Diese Architektur wird
im Folgenden als X-Architektur bezeichnet.
-
Bei
Hochgeschwindigkeitsarchitekturen kann der Frame in eine Anzahl
von Fenstern unterteilt, jedes W Schritte breit (W wird die Fensterbreite
genannt). Jedes Fenster kann unabhängig von den anderen verarbeitet
werden, wodurch ein hoher Grad von Parallelität zur Verfügung gestellt wird. In 1 ist ein Daten-Abhängigkeits-Graph 10 der
D-Architektur für
eines dieser Fenster mit W = 6 gezeigt. Diese Zeichnung D wurde gewählt, da
die Rhombusform in dem unteren Teil des Fensters einem Diamanten
gleicht. Als Referenz ist ein Trellis 12 mit einer Einflusslänge ("constraint length") K = 3 oben stehend
gezeigt. Das Trellis 12 eines Faltungscodes ist das entrollte
Codierer-Zustandsdiagramm, in dem Knoten, die dem gleichen Zustand
entsprechen, verbunden sind. Während
des übrigen
Teils dieses Dokumentes wird eine Code-Einflusslänge von K = 3 lediglich beispielhaft
angenommen, wo dies anwendbar ist. Die Trellis-Schritte zwischen
den Trellis-Zuständen
sind von links nach rechts nummeriert; der Trellis-Schritt besitzt
die Nummer des Trellis-Zustandes, von dem aus er startet. In dem
Daten-Abhängigkeits-Graphen 10 schreitet
die Zeit von oben nach unten voran. Der Daten-Abhängigkeits-Graph 10 veranschaulicht
den Datenfluss zwischen arithmetischen Einheiten. Dies impliziert
eine zeitliche Reihenfolge der Berechnung. Es gibt unterschiedliche
arithmetische Einheiten für
die Vorwärtsakquisition 14 (untenstehend
erläutert),
Rückwärtsakquisition 16,
Vorwärtsrekursion 18,
Rückwärtsrekursion 20,
Vorwärtsrekursion
mit LLR-Berechnung 22 und Rückwärtsrekursion mit LLR-Berechnung 24.
Die Daten-Abhängigkeits-Grenzen 26 entsprechen
verschiedenen Werten. Beispielsweise entsprechen 2 K 1-Werte jeder δ- und ε-Grenze des Daten-Abhängigkeits-Graphen;
eine jeweilige Anzahl an Werten entspricht jeder μ-Grenze.
Beispielsweise entspricht die Zweigmetrik μk dem
Trellis-Schritt k, der bei dem Trellis-Zustand k beginnt und die üblicherweise
mittels einer separaten Hardware-Einheit (nicht abgebildet) berechnet
wird.
-
Der
Algorithmus arbeitet wie folgt: Innerhalb des Fensters 28 starten
die Vorwärts-
und Rückwärtsrekursion
gleichzeitig an unterschiedlichen Trellis-Schritten, k – M und
k + M. Die Zweigmetriken μk-M ... μk+M-1 werden als vorberechnet angenommen.
Die Pfadmetriken δ und ε, die an
die sem Zustand unbekannt sind, werden, auf einen beliebigen Wert
gesetzt, während
der ersten M Rekursionen in Richtung zuverlässiger Werte konvergieren (M
wird die Akquisitionstiefe genannt). Diese Phase wird die Akquisitionsphase
genannt und kann gleich der Hälfte
der Fensterbreite W sein, d. h. W = 2 M. Mittels eines Codierers
werden vernünftige
Werte für
die Akquisitionslänge
M bestimmt, z. B. M = 10–20
für einen
Code mit Einflusslänge
K = 3. Am Ende der Akquisitionsphase, wie durch den Pfeil 30 angezeigt,
sind die Pfadmetriken verlässlich
geworden und die Werte können
gespeichert werden. Nach weiteren M Schritten haben beide Rekursionen
das Ende des Fensters 28 erreicht und werden in der nächsten Fensterarchitektur
(nicht abgebildet) fortgesetzt: εk-M und δk+M werden in das linke bzw. rechte benachbarte
Fenster bei 32, 34 eingespeist; man erhält δk-M und εk+M aus
diesen Fenstern; und die Rekursion fährt mit der gleichzeitigen
Berechnung der Ausgaben Lk fort. Entsprechend dem Hardwaredesign
gemäß dem Stand
der Technik werden alle Fenster eines Frames in einer Parallel-zu-Parallel-Hardware für jedes
Fenster verarbeitet. Auf diese Weise treten keine zeitlichen Probleme
bei einem Pfadmetrikaustausch zwischen benachbarten Fenstern auf.
Mit Ausnahme der richtigen Initialisierung der Pfadmetriken sind
an keinem Ende eines Frames spezielle Anordnungen notwendig.
-
Die
D-Architektur von Dawid et al. ist auf Hochgeschwindigkeit getrimmt.
Die verbesserte X-Architektur von Worm et al. verbessert zusätzlich den
Energieverbrauch bei einem Beibehalten des Durchsatzes. Diese Architekturen
zielen jedoch auf sehr hohe Durchsatzraten, das Teilen von arithmetischen
Einheiten oder die Verarbeitung unterschied licher Fenster in den
gleichen arithmetischen Einheiten ist nicht gezeigt oder implementiert.
-
Diese
Erfindung betrifft MAP-Architekturen, die eine optimierte Durchsatzreduzierung
("optimized troughput
down scaling") ermöglichen.
Es ist ein Ziel der vorliegenden Erfindung, eine Vorrichtung und
ein Verfahren zum Verbessern einer Hochgeschwindigkeits-MAP-Architektur
("MAP = Maximum
A Posteriori") mit
optimierter Speichergröße und optimiertem
Energieverbrauch zur Verfügung
zu stellen. Es ist ein weiteres Ziel der vorliegenden Erfindung,
eine verbesserte Hochgeschwindigkeits-MAP-Architektur für ein effektives
Pipelining zur Verfügung
zu stellen. Es ist ein weiteres Ziel der vorliegenden Erfindung,
eine Architektur für
ein gemeinsames Benützen
von Hardware für
aufeinander folgende Verarbeitungsdaten desgleichen Datenblocks oder
Frames nachfolgend zur Verfügung
zu stellen.
-
Zusammenfassung
der Erfindung
-
Gemäß der Erfindung
wird eine Hochgeschwindigkeits-MAP-Architektur
("MAP = Maximum
A Posteriori") mit
optimierter Speichergröße und optimiertem
Energieverbrauch zur Verfügung
gestellt, wie in den unabhängigen
Ansprüchen
beansprucht. Das Basisprinzip der Erfindung wird hier als das gemeinsame
Benützen von
Fenstern bezeichnet.
-
Kurze Beschreibung
der Zeichnungen
-
Die
Erfindung wird nun lediglich beispielhaft unter Bezugnahme auf die
begleitenden Zeichnungen beschrieben, in denen:
-
1 einen detaillierten Daten-Abhängigkeits-Graph
der D-Architektur (ein Fenster) gemäß dem Stand der Technik zeigt;
-
2 eine
X-Architektur für
M = 6, μ =
2, gemäß der Erfindung
zeigt;
-
3 die
gemeinsame Verwendung arithmetischer Einheiten zeigt;
-
4 die
gemeinsame Verwendung von Fenstern zeigt;
-
5 dreimal
ein Fenster in einer Architektur zeigt, um die Rekursion in beiden
Richtungen zu erläutern;
-
6 Wrapping-fähige X-Architekturen,
Typ I und II, zeigt;
-
7 Wrapping-fähige X-Architekturen,
Typ III und IV, zeigt;
-
8 Wrapping-fähige D-Architekturen,
Typ I und II;
-
9 Wrapping-fähige D-Architekturen,
Typ III und IV, zeigt;
-
10 ein
Ablaufdiagramm eines Verfahrens zeigt, das das gemeinsame Verwenden
von Fenstern gemäß der Erfindung
beschreibt;
-
11 ein Ablaufdiagramm eines Verfahrens
zeigt, das das gemeinsame Verwenden von Arithmetikeinheiten gemäß der Erfindung
beschreibt.
-
Beschreibung
bevorzugter Ausführungsformen
-
Um
einen maximalen Durchsatz zu erreichen, müssen Architekturen vollständig gepipelined
sein. Die Lebensdauern der Werte entsprechen dann direkt der jeweiligen
Anzahl an Pipelinestufen. Dies wird während des übrigen Teils dieses Abschnittes
angenommen.
-
In
den vorhergehenden Abschnitten wurde angenommen, dass die Länge der
Rekursionspfade, die zuverlässige
Werte erstellen (was gleich der Fensterbreite W ist), das zweifache
der Akquisitionstiefe M ist, d. h. W = 2 M. Im Allgemeinen notiert
man W = ηM. 2 zeigt
eine X-Architektur 40 mit vollständigem Pipelining gemäß der Erfindung
mit M = 6 und η =
2, die eine Alternative zu der D-Architektur darstellt, deren Daten-Abhänigigkeits-Graph
in 1 gezeigt ist. In 2 bezeichnen
kurze horizontale und diagonale Striche 42, 44 Pipelineregister,
die entlang der Daten-Abhängigkeits-Grenzen
und zwischen den arithmetischen Einheiten angeordnet sind, um eine
FIFO-Funktionalität
zu realisieren.
-
Jeder
Strich zeigt an, dass ein oder mehrere Werte in einem Register für eine Zeiteinheit/Taktzyklus gespeichert
werden. Der Vorteil der X-Architektur besteht darin, dass sie weniger
Register als die D-Architektur zum Speichern von Δ- und E-Werte
benötigt.
Die Architektur implementiert einen entsprechenden Daten-Abhängigkeits-Graph
und führt
Register ein. Mit den Registern wird der Datenfluss zeitlich in
Zeiteinheiten (Taktzyklen) geplant.
-
Für eine feste
Fensterbreite ist η invers
proportional zu M. Für η < 2 kreuzen die Akquisitionspfade
die Fensterbegrenzungen und müssen
in den benachbarten Fenstern gestartet werden. Vernünftige Werte
für die Akquisitionslänge M werden
durch den Codierer bestimmt, z. B. M = 10–20 für einen Code mit der Einflusslänge K =
3. Unterschiedliche η beeinflussen
offensichtlich die Speichergröße, die
Latenz der Architektur und die arithmetische Anforderung.
-
Für Implementationen
mit vollständigem
Pipelining werden die Datenabhängigkeiten
auf FIFOs (beispielsweise Registerketten) abgebildet, so dass die
Speicherverwendung eine lineare Funktion der Abhängigkeitslänge ist. Es gibt einen Pipeline-Schritt
zwischen aufeinander folgenden Vorwärts- und Rückwärtsrekursionen. Demnach weist
die Architektur von der ersten Akquisition bis zum letzten Ergebnis
eine Latenz von I = (η +
1)M – 1
auf. Diese Architektur mit vollständigem Pipelining akzeptiert
für jeden
Zyklus einen neuen Frame: Bis zu (η + 1)M Frames werden gleichzeitig
verarbeitet. Beispielsweise berechnen in 2 die Arithmetikeinheiten 46, 48 Werte
für den
gleichen Frame in dem gleichen Zyklus.
-
Jedes
Fenster benötigt
Informationen von seinen linken und rechten benachbarten Fenstern.
Die Architektur eines Fensters muss demnach horizontal wiederholt
werden, um die Blockbreite aufzufüllen. Demnach verarbeitet die
gesamte Architektur bei jedem Zyklus einen Block mit Eingabedaten.
Diese Technik ergibt einen sehr hohen Durchsatz, der möglicherweise
für viele
Anwendungen zu hoch ist. Eine optimierte Architektur (d. h., der
Architekturdurchsatz sollte nicht wesentlich höher als der Systemdurchsatz
sein) für
einen moderaten Durchsatz kann durch das gemeinsame Verwenden von
arithmetischen Einheiten innerhalb eines Fensters oder durch das
gemeinsame Verwenden von Fenstern abgeleitet werden. (Das Reduzieren
der Taktgeschwindigkeit ist auch eine Alternative, dies ergibt aber
eine ineffiziente Architektur.)
-
3 beschreibt
die gemeinsam verwendenden arithmetischen Einheiten gemäß der Erfindung
durch das Vergleichen einer Mitbenutzungs-X-Architektur 50 und
einer Nicht-Mitbenutzungs-X-Architektur 52.
In der Architektur 50 werden zwei aufeinander folgende
Rekursionsschritte auf der gleichen Arithmetikeinheit durchgeführt, z.
B. der Arithmetikeinheit 54, 55 oder 56.
Die Register 57 stellen die Zeitgebung oder das Einspeisen in
den richtigen Taktzyklus zur Verfügung. Die Pfeile 58 bezeichnen
Linien zum Einspeisen der Rekursionswerte, die durch eine Arithmetikeinheit
erzeugt wurden, als Eingabe für
die gleiche Arithmetikeinheit und Pfeile 59 bezeichnen
Linien zum Übergeben
der Rekursionswerte, die durch eine Arithmetikeinheit erzeugt wurden. Dies
reduziert die Pipelinelänge,
erhöht
aber das Dateninitialisierungsintervall um θ (d. h. das Intervall zwischen
zwei aufeinander folgenden Datenlesevorgängen an den Pipelineeingängen). In
diesem Beispiel ergibt dies einen Einheit-Mitbenutzungsfaktor von θ = 2, da
die Anzahl an arithmetischen Einheiten halbiert wird, sie aber durch
Multiplexer verstärkt
werden müssen.
Wie in 3 abgebildet verhält sich die Mitbenutzungsarchitektur
wie eine Architektur mit geringerer Fensterbreite ηM/θ. Demnach
wird die Menge an Speicher ebenfalls reduziert. Es sei bemerkt,
dass in 3 keine Unterscheidung in der
Zeichnung zwischen den verschiedenen Arten von arithmetischen Einheiten
aus Gründen
der Einfachheit gemacht wurde.
-
Zusätzliche
Register wurden eingeführt,
um eine rechteckige Struktur zu erreichen, die alle μ Werte eines
Fensters parallel in einem Taktzyklus lesen kann und alle LLR-Werte eines Fensters
parallel in einem Taktzyklus ausgibt.
-
4 zeigt
eine Fenstermitbenutzungsarchitektur 60 und eine Angabe 62,
was das nachfolgende Einspeisen von Fenstern des gleichen Frames
oder Datenblocks 64 in die Architektur 60 erläutert. Des
Weiteren zeigen die Pfeile 66, 68 das Einspeisen
von ε- und δ-Werten zu
den benachbarten logischen Fenstern. Insbesondere wird der δ-Wert, der
sich in der Architektur 60 auf der rechten Seite befindet,
Pfeil 68, dem rechten benachbarten Fenster auf dessen linker
Seite eingespeist. Der ε-Wert,
der sich auf der Architektur 60 auf der linken Seite befindet,
wird, Pfeil 66, dem linken benachbarten Fenster auf dessen
rechter Seite eingespeist.
-
Verschiedene
Fenster müssen
auf einem Hardwarefenster gemeinsam benützt werden, wenn die Anzahl
an Fenstern, die in der Hardware eingebaut sind, kleiner ist als
die Anzahl an Fenstern eines Frames. In diesem Beispiel befindet
sich ein Fenster in der Hardware. Die Konzepte der Erfindung sind
auch auf verschiedene Hardwarefenster anwendbar. Im Fall eines Hardwarefensters
muss ein Frame in die Pipeline Fenster für Fenster eingebracht werden,
wie in 4 abgebildet. Dieses Schema wird hier "Wrapping" genannt, da der Datenaustausch
von Vorwärts-
und Rückwärtsrekursionswerten
an den Fensterbegrenzungen um die Architektur gewickelt ("Wrapped") ist.
-
Wenn
keine δ-
oder ε-Werte
verfügbar
sind, d. h. an der Begrenzung eines Frames, speisen die Multiplexer 70 bzw. 72 stattdessen
einen Initialwert ein.
-
Die
Erfindung steht dem Problem gegenüber, dass bei einem gegebenen
Fenster innerhalb einer Warteschlange von Fenstern das vorhergehende
Fenster bereits berechnet ist, aber dessen nachfolgendes Fenster
noch nicht berechnet ist. Dies bedeutet, dass die Rekursionswerte
an der Fensterbegrenzung von dem vorhergehenden Fenster verfügbar sind,
aber nicht von dem nachfolgenden Fenster verfügbar sind.
-
5 zeigt
drei Ansichten 71, 73, 75 einer MAP-Architektur 70.
Die Architektur 70 weist eine Hardwarebreite von einem
Fenster auf, d. h. eine Anzahl von W arithmetischen Einheiten 72,
die LLR Werte erzeugen und eine ent sprechende Anzahl von weiteren
arithmetischen Einheiten 74. Die Architektur 70 ist
in drei Ansichten 71, 73, 75 gezeigt,
die jede um einen Taktzyklus zu ihrem Nachbar verschoben ist. Alle
drei enthalten die gleichen Daten in den Einheiten und Registern
und zeigen die gleichen Momentaufnahmen.
-
Dies
dient dazu, um zu visualisieren, dass Daten zwischen Fenstern an
Fensterbegrenzungen ausgetauscht werden. In diesem Beispiel sollte
klar sein, dass die Fenster eines Frames nachfolgend in der in 4 gezeigten
Reihenfolge verarbeitet werden, d. h., von links nach rechts. Der
Fachmann weiß,
wie die Architektur für
eine unterschiedliche Verarbeitungsreihenfolge zu implementieren
ist. Unterschiedliche Arten von arithmetischen Einheiten werden
in gleicher Weise als Kreise aus Gründen der Einfachheit gezeigt.
-
Die
Register 77 sind ähnlich
in 3 gezeigt, auch in einem rechteckförmigen Muster,
was die Zeitgebung oder das Einspeisen in den richtigen Taktzyklus
zur Verfügung
stellt.
-
In
einer Ansicht sind die arithmetischen Einheiten zur gleichen Zeit
(Momentaufnahme) gezeigt. Die arithmetischen Einheiten in der gleichen
horizontalen Reihe innerhalb einer Momentaufnahme verarbeiten Daten
des gleichen Fensters. Die arithmetischen Einheiten in der Reihe
darüber
verarbeiten Daten des nachfolgenden Fensters. In einem vorhergehenden
Taktzyklus wäre
eine Momentaufnahme ähnlich,
aber jede arithmetische Einheit würde Daten des vorhergehenden
Fensters verarbeiten.
-
Die
Erfindung stellt eine Architektur mit Pipelining zur Verfügung, was
den Datenaustausch von Rekursionsdaten zwischen folgenden Fenstern
auf korrekte Weise sowohl in Vorwärts- als auch in Rückwärtsrichtung
erlaubt, obwohl die Fensterdaten in unterschiedlichen Positionen
in der Architektur verarbeitet werden. Um einen korrekten Datenaustausch
zu erläutern,
hebt die horizontale Linie 76 quer über die Ansichten 71, 73, 75 in
der Ansicht 71 die arithmetischen Einheiten hervor, die
Daten des Fensters 1 verarbeiten,
in der Ansicht 73 die
arithmetischen Einheiten hervor, die Daten des Fensters 2 verarbeiten,
und
in der Ansicht 75 die arithmetischen Einheiten
hervor, die Daten des Fensters 3 verarbeiten (die Fensternummern
sind hier willkürlich
gewählt,
die Fensternummern 1, 2 und 3 sind aufeinander folgend)
-
Es
werden jetzt unter Hinwendung auf den Vorwärtsrekursionsdatenaustausch
von dem Fenster 1 zu dem Fenster 2 die arithmetische Einheit 78 betrachtet,
die Daten des Fensters 2 verarbeitet. Die arithmetische Einheit 78 empfängt Fensterausgangsdaten
der arithmetischen Einheit 80, die in dem vorhergehenden
Zyklus Daten des Fensters 1 verarbeitet hat (und in dem momentanen
Zyklus auch Daten des Fensters 2 verarbeitet).
-
Unter
Hinwendung auf den Vorwärtsrekursions-Datenaustausch
von dem Fenster 2 zu dem Fenster 3 wird die Arithmetikeinheit 82 betrachtet,
die Daten des Fensters 2 verarbeitet. Die Arithmetikeinheit 82 überträgt Ausgabedaten
des Fensters 2 zu der Arithmetikeinheit 84, die in dem
nachfolgenden Zyklus Daten des Fensters 3 verarbeitet (und in dem
momentanen Zyklus Daten des Fensters 2 verarbeitet).
-
Unter
Hinwendung auf den Rückwärtsrekursions-Datenaustausch
von dem Fenster 2 zu dem Fenster 1 wird die Arithme tikeinheit 86 betrachtet,
die Daten des Fensters 1 verarbeitet. Die Arithmetikeinheit 86 empfängt Ausgabedaten
des Fensters 2 der Arithmetikeinheit 88, die in dem vorhergehenden
Zyklus Daten des Fensters 2 verarbeitet hat (und in dem momentanen
Zyklus Daten des Fensters 3 verarbeitet).
-
Unter
Hinwendung auf den Rückwärtsrekursions-Datenaustausch
von dem Fenster 3 zu dem Fenster 2 wird die Arithmetikeinheit 90 betrachtet,
die Daten des Fensters 3 verarbeitet. Die Arithmetikeinheit 90 überträgt Ausgangsdaten
des Fensters 2 zu der Arithmetikeinheit 92, die in dem
nachfolgenden Zyklus Daten des Fensters 2 verarbeitet (und in dem
momentanen Zyklus Daten des Fensters 1 verarbeitet).
-
Demnach
wurde der vollständige
Datenaustausch, der das Fenster 2 entsprechend der Linie 76 in
Ansicht 2 einbezieht, für
die X-Architektur gezeigt. Aufgrund der nachfolgenden Verarbeitung
von Fenstern impliziert dies die gleiche Funktionalität für alle anderen
Fenster.
-
Dies
ermöglicht
das gemeinsame Verwenden von Fenstern bei denen sowohl Vorwärts- als
auch Rückwärtsrekursion
involviert ist, gemäß der vorliegenden
Erfindung. Pfeile zeigen Linien zum Einspeisen der Rekursionswerte,
die durch eine Arithmetikeinheit als Eingabe für die gleiche Arithmetikeinheit
erzeugt wurden; und Pfeile zeigen Linien zum Übergeben der Rekursionswerte,
die durch eine Arithmetikeinheit erzeugt wurden.
-
Die
Fenstermitbenutzungs-X-Architektur gemäß der Erfindung kann als ein
System zum Decodieren von Daten unter Verwendung eines MAP-Algorithmus
beschrieben werden, wobei Daten eines Datenblocks in nachfolgende
Fenster aufgeteilt werden, Daten über Breiten eines Fensters
parallel verarbeitet werden. Das System umfasst:
eine Mehrzahl
von Arithmetikeinheiten zum Verarbeiten von Eingabedaten in sukzessiven
Stufen, einschließlich
erster Vorwärtsrekursions-Arithmetikeinheiten 80; 82,
die eine Vorwärtsrekursion
durchführen
und erste Vorwärtsrekursionswerte
unter Verwendung von Bits eines ersten Datenfensters erzeugen; zweiter
Vorwärtsrekursions-Arithmetikeinheiten 78; 84,
die eine zweite Vorwärtsrekursion
durchführen
und zweite Vorwärtsrekursionswerte
unter Verwendung von Bits eines zweiten Datenfensters erzeugen;
erster Rückwärtsrekursions-Arithmetikeinheiten 86; 92,
die eine Rückwärtsrekursion
durchführen
und erste Rückwärtsrekursionswerte unter
Verwendung von Bits des ersten Datenfensters erzeugen, und zweiter
Rückwärtsrekusions-Arithmetikeinheiten 88; 90,
die eine zweite Rückwärtsrekursion
durchführen
und zweite Rückwärtsrekursionswerte
unter Verwendung von Bits des zweiten Datenfensters erzeugen;
eine
Mehrzahl von Speichereinheiten 77 zum Speichern von Werten,
die durch verschiedene der Arithmetikeinheiten erzeugt wurden, zur
Verwendung durch andere der Arithmetikeinheiten;
Mittel zum Übergeben
der ersten Vorwärtsrekursionswerte
von einer vordefinierten der ersten Vorwärtsrekursions-Arithmetikeinheiten 80; 82,
an eine vordefinierte der zweiten Vorwärtsrekursions-Arithmetikeinheiten 78; 84;
und
Mittel zum Übergeben
der zweiten Rückwärtsrekursionswerte
von einer vordefinierten der zweiten Rückwärtsrekursions-Arithmetikeinheiten 88; 90 an
eine vordefinierte der ersten Rückwärtsrekursions-Arithmetikeinheiten 86; 92;
wobei
aufeinander folgende Fenster innerhalb des Systems zum Verarbeiten
gepipelined werden.
-
Der
Fachmann weiß,
dass es in dieser Ansicht von Belang ist, die Zeit/den Taktzyklus
mit einer Momentaufnahme dahingehend zu erläutern, welche Fensterdaten
gerade in einer bestimmten Einheit verarbeitet werden. In dem obigen
Beispiel waren Dreitaktzyklen und drei Fenster lediglich zur Erläuterung
unter zur Hilfenahme der Ansichten 71, 73, 75 involviert.
-
Die
Vorwärtsrekursion
und die Rückwärtsrekursion
starten gleichzeitig und treffen sich nach der gleichen Anzahl von
Rekursionsschritten.
-
Die
folgenden Figuren zeigen die Implementation in unterschiedlichen
speziellen Fällen.
-
6 zeigt
die Implementation für
eine X-Architektur vom Typ 1: gleiche Fensterbreite, eine arithmetische
Einheit auf einer Begrenzung des Fensters;
Typ 2: gleiche Fensterbreite,
zwei arithmetische Einheiten auf jeder Begrenzung des Fensters. 5 entspricht
Typ 2 der 6.
-
7 zeigt
die Implementierung für
eine X-Architektur
vom
Typ 3: ungleiche Fensterbreite, eine arithmetische Einheit
auf einer Begrenzung des Fensters;
Typ 4: ungleiche Fensterbreite,
zwei arithmetische Einheiten auf jeder Begrenzung des Fensters.
-
8 zeigt
die Implementierung für
eine D-Architektur vom
Typ 1: gleiche Fensterbreite, eine arithmetische
Einheit auf einer Begrenzung des Fensters;
Typ 2: gleiche Fensterbreite,
zwei arithmetische Einheiten auf jeder Begrenzung des Fensters.
-
9 zeigt
die Implementierung für
eine D-Architektur vom
Typ 3: ungleiche Fensterbreite, eine
arithmetische Einheit auf einer Begrenzung des Fensters;
Typ
4: ungleiche Fensterbreite, zwei arithmetische Einheiten auf jeder
Begrenzung des Fensters.
-
10 zeigt
ein Ablaufdiagramm 100 eines Verfahrens zum Decodieren
von Daten unter Verwendung eines MAP-Algorithmus in einer Hardware,
die Daten eines Fensters eines Datenblocks parallel gemäß der Erfindung
verarbeitet. Dieses Verfahren kann man als das gemeinsame Verwenden
von Fenstern verstehen. Das Verfahren umfasst die Schritte:
- – Definieren
eines ersten Datenfensters und eines nachfolgenden zweiten Datenfensters
innerhalb des Datenblocks von sequentiellen Eingabedaten, die zu
decodieren sind, Schritt 102;
- – Laden
von Bits des ersten Datenfensters und des zweiten Datenfensters,
Schritt 104;
- – Durchführen einer
Vorwärtsrekursion
und Erzeugen erster Vorwärtsrekursionswerte
unter Verwendung der Bits des ersten Datenfensters und zweiter Vorwärtsrekursionswerte
unter Verwendung von Bits des zweiten Datenfensters, Schritt 106;
- – Durchführen einer
Rückwärtsrekursion
und Erzeugen erster Rückwärtsrekursionswerte
unter Verwendung von Bits des ersten Datenfensters und zweiter Rückwärtsrekursionswerte
unter Verwendung von Bits des zweiten Datenfensters, Schritt 108;
und
- – Berechnen
von Ausgabewerten unter Verwendung zumin dest der Vorwärtsrekursionswerte
und der Rückwärtsrekursion,
Schritt 110. In dem Verfahren startet die Vorwärtsre kursion
mit dem Erzeugen der ersten Vorwärtsrekursionswerte
und übergibt
die ersten Vorwärtsrekursionswerte
zum Erzeugen der zweiten Vorwärtsrekursionswerte.
Die Rückwärtsrekursion
startet mit dem Erzeugen der zweiten Rückwärtsrekursionswerte und übergibt
zweite Rückwärtsrekursionswerte
zum Erzeugen der ersten Rückwärtsrekursionswerte.
