Anwendung der Methoden des Hardware/Software Codesigns am Beispiel eines MPEG1 Layer III Dekoders

1
Anwendung der Methoden des Hardware/Software
Codesigns am Beispiel eines MPEG1 Layer III
Dekoders

• Design-Space-Exploration, Prozessorarchitekturen,
  Hardwareoptimierung

2
Überblick

• Architektur des FPGA
• Algorithmus der IMDCT
• Modellalternativen
• 3.1. Vorüberlegungen
• 3.2. Erste Implementierung (ohne Pipeline)
• 3.3. Zweite Implementierung (mit Pipeline)
• 3.4. Kommunikation
• D/A-Controller

3
1. Architektur des FPGA

• 2304 CLBs (entsprechend ca. 40000 Logikgattern)
• FreeRAM-Zellen (ca. 2 kB SRAM, die gleichmässig
  über die gesamte Fläche des FPGA verteilt sind)
• 5 Lagen von Routing-Ressourcen (jeweils 1 lokaler
  und 2 Express-Busse)
• Direkte Verbindung jeder Zelle mit den acht
  benachbarten Zellen

4
Routing-Ressourcen

• Verbindungen einer FPGA-Zelle Struktur einer
  Lage von Bus-Ressourcen

5
Figaro Hardware-Makros

• Effiziente Implementierungen häufig verwendeter
  funktionaler Einheiten
• von Hand geroutet und optimiert
• Ausnutzung der Direktverbindungen zwischen
  benachbarten Zellen
• Folgendes Beispiel vergleicht die Ergebnisse für
  einen 24 Bit Ripple-Carry-Addierer

Variante Fläche (in Zellen) Max. Taktfrequenz (in MHz)
RTL Makro 75 25 13 35
6
2. Algorithmus der IMDCT

• Formel

Anzahl der nötigen Berechnungen kann durch
Dezimierung im Zeitbereich (Algorithmus von B. G.
Lee) deutlich reduziert werden. Dabei wird eine
N-Punkte DCT durch zwei Transformationen der
Länge N/2 ersetzt.
Struktur der Butterfly-Operationen
7
3. Behandelte Modellalternativen

• Zwei verschiedene Ansätze für die Implementierung
  der zeitkritischen und rechenintensiven Teile der
  Dekodierung in Hardware
• Implementierung eines kleinen DSP-Kerns, der
  durch ein im SRAM abgelegtes Programm gesteuert
  wird
• Implementierung eines DSP-Kerns mit mehrstufiger
  Pipeline (erhält den Befehlsdurchsatz bei
  längerer Befehlsausführungszeit)

8
DSP

• Ansatz
• Implementierung eines kleinen Prozessorkerns, der
  in Aufbau und Befehlssatz an die gewünschten
  Berechnungen angepasst ist
• Steuerung durch ein im SRAM gespeichertes
  Programm
• AVR legt fertige Daten im SRAM ab, von wo sie der
  DSP übernimmt
• DSP speichert die ausgabefertigen Samples in
  einem Ringpuffer, der vom D/A-Controller
  ausgelesen wird

9
3.1. Durch die Hardware gegebene Einschränkungen

• Nur ein 8 Bit breiter Bus zwischen SRAM und FPGA
• Speicherzugriffe benötigen 2 Takte, da Daten und
  Befehle 16 Bit umfassen

10
Zahlenformat

• Festlegung der Bitbreite auf 16 Bit
• 8 Bit bieten zu geringe Auflösung und verursachen
  daher zu viele Rechenungenauigkeiten
• 24 Bit benötigen 3 Takte Zugriffszeit, was
  Echtzeitfähigkeit verhindert
• Nach Ermittlung des nötigen Wertebereichs wurde
  folgendes Format gewählt, um möglichst hohe
  Rechengenauigkeit zu erreichen

11
Benötigter Befehlssatz

• Addition, Subtraktion, Multiplikation, MAC
• Befehle zum Verschieben von Registerinhalten
• Lade- / Speicherbefehle
• Sprungbefehle
• Adressbefehle

12
3.2. Erste DSP-Version(ohne Pipelining)

• 3 Registerbänke (je eine für die beiden Operanden
  und eine für das Ziel)
• 20 Bit Akkumulator
• 16 Bit Multiplizierer
• 20 Bit Addierer/Subtrahierer
• Register für Adresszeiger
• Befehlsregister
• Hilfsregister für Kontrollsignale etc.

13
Aufbau des Datenpfades
14
Bewertung

• Ergebnis
• Keine Echtzeitfähigkeit
• Ursachen
• 55 der Durchlaufzeiten durch Routingressourcen
• Knapp 50 der Logikverzögerung für Multiplexoren
  und Adressdekodierung

15
3.3. Zweite DSP-Version(mit Pipelining)

• Überlegungen zur Reduzierung der langen
  Signallaufzeiten
• Vermeidung von überflüssigen bzw. Verkleinerung
  der benötigten Multiplexoren
• Erhöhung der maximalen Taktfrequenz durch
  Einführen einer mehrstufigen Pipeline

16
Aufbau der Pipeline

• Die meisten Befehle benötigen für ihre Ausführung
  6 Takte.
• Da allerdings immer 3 Befehle gleichzeitig
  bearbeitet werden, bleibt der Befehlsdurchsatz
  gegenüber der ersten Prozessorversion unverändert

17
Pipeline-Stalls 1

• Da während des Normalbetriebes in jedem Takt ein
  Befehl aus dem SRAM geladen wird, erfordern
  Datenzugriffe auf das SRAM ein Anhalten der
  Pipeline.

18
Pipeline-Stalls 2

19
Pipeline-Stalls 3

• Ein weiterer Stall ist nötig, falls der DSP ein
  noch nicht verarbeitetes Datum im Ringpuffer
  überschreiben will

20
Änderungen zur Erhöhung der Rechengenauigkeit

• Verzicht auf Saturierung des Multiplikationsergebn
  isses beim MAC-Befehl
• Verbreiterung von Akku und Addierer

Zahlendarstellungen der verschiedenen
Arbeitsschritte des MAC-Befehls
21
Aufbau des Datenpfades
22
Besonderheiten des Prozessors

• Das Ergebnis einer Instruktion steht erst dem
  übernächsten Befehl zur Verfügung die direkt
  nachfolgende Instruktion kann dieses Ergebnis
  nicht benutzen, da kein Forwarding in der
  Hardware implementiert ist
• Besteht eine Datenabhängigkeit, so muss eine
  NOP-Instruktion eingefügt werden
• Instruktion nach Sprung wird immer ausgeführt
• Nach Sprungbefehl kein LDA-Befehl möglich

23
3.4. Kommunikation

• Kommunikation mit AVR
• AVR legt berechnete Daten im SRAM ab, von wo sie
  der DSP liest
• Mitteilung über bereitliegende Daten mit Hilfe
  von shared variables im SRAM
• Kommunikation mit D/A-Controller
• spezielle Adressleitung vom D/A-Controller teilt
  dem DSP mit, welche Speicherzelle gerade
  ausgelesen wird

24
4. D/A-Controller

• Der D/A-Controller besteht aus einer einfachen
  FSM, die Samples aus dem Ringpuffer ausliest und
  bitweise mit den nötigen Kontrollsignalen an den
  D/A-Wandler schickt

Ausgabeformat des D/A-Controllers
25
Berechnung der Ringpuffergröße

• Zu überbrückender Zeitraum
• Zeit für komplette IMDCT Zeit für einen
  Durchlauf der Polyphasenfilterung
• 32156 Takte (96586 Takte / 18) 37522 Takte
• 37522 Takte / 12 MHz 3,13 ms
• Nötige Anzahl an Speicherplätzen
• Benötigte Zeit Wiedergabefrequenz
• 3,13 ms 22,05 kHz 70 Speicherplätze
• Da die Anzahl der Speicherplätze eine
  Zweierpotenz sein muss, wurde der Puffer für 128
  Samples ausgelegt.