Untersuchung zur hardwareunterstützten Entwurfsverifikation von Stream-basierten Kommunikations- und Verarbeitungsalgorithmen

Transkript

1 Fakultät Informatik Institut für Technische Informatik, Professur für VLSI-Entwurfssysteme, Diagnostik und Architektur Untersuchung zur hardwareunterstützten Entwurfsverifikation von Stream-basierten Kommunikations- und Verarbeitungsalgorithmen Diplomverteidigung Jan Schirok Dresden,

2 Gliederung Motivation Simulation im Entwurf Simulationsplattform Ergebnisse Zusammenfassung und Ausblick TU Dresden, Diplomverteidigung Schirok Folie 2 von 16

3 Motivation Simulation ist essentieller Bestandteil im Entwurf integrierter Schaltkreise Fokus: Schaltungssimulation auf Register-Transfer-Ebene (RTL) Steigende Komplexität integrierter Schaltkreise Geschwindigkeit der softwarebasierten, sequentiellen Simulatoren sinkt Zahl der Simulationsläufe steigt Notwendigkeit einer Simulationsbeschleunigung Unterstützung durch an Host-PC angebundene FPGA-basierte Hardware Problemstellung: Kommunikation zwischen Hard- und Software Einschränkung des Anwendungsbereichs Stream-basierte Kommunikations- und Verarbeitungsalgorithmen Latenzverdeckung der Kommunikation zwischen Hard- und Software möglich TU Dresden, Diplomverteidigung Schirok Folie 3 von 16

4 Simulation im Entwurf RTL Schaltungssimulation Systembeschreibung auf Register-Transfer-Ebene Komponenten in Hardwarebeschreibungssprache Verschiedene Anwendungsfälle Verifikation erfordert sehr hohe Simulationsgeschwindigkeit Fehlersuche benötigt zusätzlich Sichtbarkeit in das System und geringe Vorbereitungsdauer Nutzung von FPGAs zur Beschleunigung der Simulation Synthese der RTL Beschreibung in FPGA Strukturen Stimulation und Auslesen der Module: Ein- und Ausgänge im FPGA auf Signal-/Portebene Kopplung an Host-PC z.b. in Form einer Einsteckkarte TU Dresden, Diplomverteidigung Schirok Folie 4 von 16

5 Simulation im Entwurf Hardwarebeschleunigung Partitionierung in Hardware- und Softwareteil Systemszenario (Hardware: RTL-basiertes System, Software: Stimuli und Vergleich der Ausgangsdaten) Komponentenszenario: Teil komponente 1 Software Testbench Externe Kommunikation Hardware Simuliertes System ohne Teilkomponente 1 Teil komponente 2 Referenz =? Repräsentation des simulierten Systems ohne Teilkomponente 1 in der Testbench Teil komponente 3 Teil komponente 4 TU Dresden, Diplomverteidigung Schirok Folie 5 von 16

6 Simulation im Entwurf Kommunikation Externe Kommunikation zwischen Hard- und Software Interne Kommunikation zwischen Partitionen (Teil der Modellierung) Verschiedene Muster der internen Kommunikation Einfaches Request Response Schema Signaländerung in jedem Takt möglich (intern) Stimulation Takt Auslesen (extern) Aktionsbasierte Kommunikation Nur Stimulation und Auslesen falls notwendig Transaktionsbasierte Kommunikation Transaktionen verarbeiten, Anfragen senden, Antworten empfangen Externe Kommunikation kritisch für Simulationsgeschwindigkeit Nutzung der Muster der internen Kommunikation zur Verringerung des Datenaufkommens der externen Kommunikation und zur Simulationsbeschleunigung TU Dresden, Diplomverteidigung Schirok Folie 6 von 16

7 Simulationsplattform Eigenschaften PCI Express Einsteckkarte mit Altera Stratix II GX FPGA Einbindung der Hardwareplattform in Linux als Kernelmodul Kopplung an ModelSim SE per Foreign Language Interface Umsetzung der Kommunikationsmuster in zwei Prototypen Einfaches Request Response Schema und aktionsbasierte Kommunikation übertragen Signaldaten Bitebenenprototyp Transaktionsbasierte Kommunikation überträgt Anfragen und Antworten Transaktionsbasierter Prototyp Richtung der Aktionen bzw. Anfragen festgelegt (Hardware zu Software) TU Dresden, Diplomverteidigung Schirok Folie 7 von 16

8 Simulationsplattform Bitebenenprototyp Übertragung von Eingangs-/Ausgangssignalen der Partitionen pro simuliertem Takt Aktionsbasierte Kommunikation: taktweise Aktionen und erwartete Reaktionen Phasen ohne Aktionen oder erwartete Reaktionen erfordern keine taktweise Kommunikation (höhere Granularität) Unterstützung dieser Phasen durch zwei Parameter NREAD: Maximale Anzahl gleichzeitig übertragener Takte NSKIP: Maximale Anzahl übersprungener Takte Anzahl der übertragenen bzw. übersprungenen Takte wird zusätzlich durch eintretende Aktionen und erwartete Reaktionen begrenzt Standardfall: NREAD=1, NSKIP=0, Übertragung in jedem Takt TU Dresden, Diplomverteidigung Schirok Folie 8 von 16

9 Simulationsplattform Transaktionsbasierter Prototyp Übertragung von Transaktionen Anfragen von Hardwarepartition Antworten von Softwarepartition Angepasste, zyklengenaue Busadapter notwendig Kommunikation mit Busadaptern innerhalb der Hardware FIFO-basiert Nebenläufigkeit der Hardwarepartition zum softwarebasierten Simulator möglich Softwarebasierter Simulator Simulationshardware Software Partition Busadapter Software Anfragen Antworten Busadapter Hardware Hardware Partition Interne Kommunikation Externe Kommunikation Interne Kommunikation TU Dresden, Diplomverteidigung Schirok Folie 9 von 16

10 Ergebnisse Gewähltes Beispiel Dekodierung von Ogg Theora Videodaten Quelloffenes, eingebettetes System auf Basis des Leon3 Prozessors Beschleunigung der Videodekodierung durch Theora Komponente IDCT (Inverse Discrete Cosine Transform): Teiloperation der Dekodierung als Softwarepartition Software Testbench Hardware Hardwarepartition Theora Komponente IDCT Vergleich Ausgangsdaten Externe Kommunikation IDCT interface_vga APB Leon3 SoC TU Dresden, Diplomverteidigung Schirok Folie 10 von 16

11 Ergebnisse Simulationsgeschwindigkeit / Kommunikationsmuster Geschwindigkeit rein softwarebasierter Simulation: 77,4 Takte pro Sekunde Erreichte Geschwindigkeiten der untersuchten Kommunikationsmuster: 200 Minimum Maximum Simulationsgeschwindigkeit [1000 Takte / Sekunde] Einf. Req. Resp. Aktionsbasiert Transaktionsbasiert Verwendetes Kommunikationsmuster TU Dresden, Diplomverteidigung Schirok Folie 11 von 16

12 Ergebnisse Einfluss der Parameter beim Bitebenenprototyp Weite Geschwindigkeitsspanne durch Variation von NSKIP/NREAD erreichbar NREAD=1, NSKIP=0 entspricht einfachem Request Response Schema Simulationsgeschwindigkeit [1000 Takte / Sekunde] NSKIP=0 NSKIP=10 NSKIP=100 NSKIP=1000 NSKIP= NREAD=1 NREAD=4 NREAD=15 NREAD Parameter TU Dresden, Diplomverteidigung Schirok Folie 12 von 16

13 Ergebnisse Einfluss des softwarebasierten Simulators Vergleich zwischen ModelSim und Testprogramm mit geringer Rechenzeit Kommunikation ist in beiden Fällen Teil der Messung Simulationsgeschwindigkeit ohne software basierten Simulator [1000 Takte / Sekunde] /0 15/0 Mit ModelSim Ohne ModelSim 1/ /10000 NREAD/NSKIP des Bitebenenprototypen TU Dresden, Diplomverteidigung Schirok Folie 13 von 16

14 Zusammenfassung Beschleunigung der Simulation auf RT Ebene erreicht Günstig für Verifikation und Fehlersuche Sicht in Teilkomponenten durch Komponentenszenario Fehlersuche in diesen Teilkomponenten Geringe Vorbereitungsdauer bei Änderungen in der Softwarepartition Untersuchung verschiedener Kommunikationsmuster Request Response Schema: universell, geringste Beschleunigung Aktionsbasierte Kommunikation: parametrierbar, mittlere Beschleunigung Transaktionsbasierte Kommunikation: hohe Anforderungen an simuliertes System, höchste Beschleunigung Latenzverdeckung gegenüber Request Response Schema Aktionsbasierte Kommunikation erscheint für Simulationen auf RT Ebene als günstigste Variante TU Dresden, Diplomverteidigung Schirok Folie 14 von 16

15 Ausblick Potential der Hardwarelösung bei aktions- und transaktionsbasierter Kommunikation nicht ausgeschöpft Verallgemeinerung der Kommunikationsmuster auf weitere Algorithmenklassen Nutzung der Simulationsbeschleunigung zur Messung von Systemeigenschaften (Latenzen, Durchsätze) Weiterführende Untersuchungen der Simulation mit nebenläufiger Hardwarepartition Kombination des transaktionsbasierten Prototypen mit datenflussbasierten Simulatoren TU Dresden, Diplomverteidigung Schirok Folie 15 von 16

16 Vielen Dank für Ihre Aufmerksamkeit. TU Dresden, Diplomverteidigung Schirok Folie 16 von 16

17 TU Dresden, Diplomverteidigung Schirok Folie 16 von 16

18 RX Deskriptor RX Daten Empfänger (RX) PCI Express x4 PCI Express Core Interrupt FIFO RX Paketinfo Zentrale Steuerung State C State A FSM State B Taktsteuerung, Rücksetzen Aktivierung DMA Ereignisse Kapselung der Hardware Partition Actio, Reactio, Timeout DMA Steuerung FIFO DMA Info Schreib /Leseadresse, Steuerung Konfigurationsdaten FIFO RX Daten interner Adress / Datenbus Eingangs / Ausgangsdaten DMA Adressen FIFO TX Paketinfo FIFO TX Daten Sender (TX) TX Deskriptor TX Daten TU Dresden, Diplomverteidigung Schirok Folie 16 von 16

19 _ Nebenläufige Simulation Software Hardware Testbench Zur Software nebenläufiges System Teil komponente 1 B F M externe Kommunikation (Transaktionen) B F M Teil komponente 2 externe Komponente 1 Referenz =? Teil komponente 3 Teil komponente 4 externe Komponente 2 TU Dresden, Diplomverteidigung Schirok Folie 16 von 16

20 _ Aktionsbasierte Kommunikation Voraussetzungen Definition von Aktion (bzw. Anfrage) z.b. Reset-Eingang eines Zählers, Chip Enable Leitung am Speicherbaustein. Definition von Reaktion (bzw. Antwort) z.b. Increment eines Zählers, Setzen der Datenleitungen durch den Speicherbaustein Richtung von Aktion und Reaktion festgelegt Keine selbstinitiierte Reaktion (nur erwartete) Phasen ohne Aktion und erwartete Reaktion: überspringen z.b. kein Buszugriff Phasen mit Aktion ohne erwartete Reaktion: zusammenhängend übertragen z.b. nur Schreibzugriffe Phasen mit erwarteter Reaktion: Einzelübertragung, Reaktion erwarten z.b. Lesezugriff TU Dresden, Diplomverteidigung Schirok Folie 16 von 16