Dipl.-Ing. Christopher Claus Prof. Dr.-Ing. Walter Stechele

Präsentation zum Thema: "Dipl.-Ing. Christopher Claus Prof. Dr.-Ing. Walter Stechele"—  Präsentation transkript:

1 Dipl.-Ing. Christopher Claus Prof. Dr.-Ing. Walter Stechele
AutoVision – eine situationsadaptive SoC Architektur für videobasierte Fahrerassistenzsysteme Dipl.-Ing. Christopher Claus Prof. Dr.-Ing. Walter Stechele

2 Agenda Video-basiertes Fahrerassistenzsystem: AutoVision
AutoVision bisher: Rekonfigurationszeiten & overhead Demonstratoraufbau 2007/2008 HW Beschleunigung für Videoverarbeitung Optischer Fluß Kooperationen, Veröffentlichungen, Demonstratoren Zusammenfassung und Ausblick

3 AutoVision Prozessor Region to enhance contrast Video IF Coprozessor
Shape Engine Tunnel Engine Cont/Edge Engine Taillight Engine PPC Highway X Tunnel entrance Inside tunnel Algorithmen für video-bas. Fahrerassistenz nicht standardisiert -> flexible Plattform notwendig Austausch von HW Beschleunigern für Echtzeit- Videoverarbeitung Rekonfigurationsdurchsatz ca. 100 KB/ms (V2P) DMA Unterstützung der HW Beschleuniger HW/SW Aufteilung: Pixeloperations -> HW HL Algorithms -> SW (PPC) On-chip Rekonfiguration getriggert durch CPU Eine CPU für Bildverarbeitung, eine für Rekonfigurationmanagement DDR SDRAM Featurepoint extraction in HW -> high level algorithm in SW TunnelE. I/O PPC1 PPC0 Video IF TaillightE. PLB EdgeEng EdgeEng Coproc0 ShapeEng EdgeEng Coproc1 ICAP MEM IF EdgeEng ShapeEng ShapeEng Virtex II Pro FPGA Coprozessor Konfigurationen

4 AutoVision bisher: Rekonfigurationszeiten & overhead
1. Jahr: Reduktion von overhead aus Bitstreams -> Combitgen 2. Jahr: Optimierung der Speicheranbindung an ICAP -> PLB ICAP (V2P & V4) (Zusammen mit Combitgen 30-fache Beschleunigung möglich) 3.Jahr: Miniaturisierung von Videofilterengines -> optimale Ausnutzung von BRAMs 4. Jahr: Alternative on-chip Architekturen (Multi Port Memory Controller) ICAP Interconnect Bitstream im Memory

5 Demonstratoraufbau Alt Neu Auflösung 384x288 640x480 Auflösung max. 512x512 1024x1024 Pixel gesamt 110592 307200 Matrixgröße 11x11 15x15 Verarbeit-ungszeit 6.98 ms 3.18 ms Slices 2816 3300 BRAMS 19 12 (36) Optimierung und Anpassung der AdressEngine an LIS-IPIF Optimierung und Anpassung der TaillightEngine (8-fache Beschleunigung) -> Demonstration Konzeption und Implementierung der ShapeEngine (Eckendetektor) Speicher Optimierung, kompakte Engines Optimierung des Videointerface Rekonfigurationsgrenzen stehen noch nicht fest TaillightEngine Alte AdressEngine Neue Addressengine # an Bildzeilen (8bbp) 8 # an Slices 134 (0%) 221 (1%) # an BRAMs 16 (11%) 4 (2%)

6 Demonstratoraufbau PLB OPB Framebuffer RAM DVI or VGA Video in PLBICAP
XC2VP30 Video in PLBICAP Video out SDRAM Contr. SDRAM PPC1 PPC0 LISIPIF LISIPIF LISIPIF PLB PLB2OPB OPB2PLB LISIPIF LISIPIF DCR OPB Busmacro Busmacro SysACE Cntrl Engine 0 Engine 1 Reconfigurable part SysAce Compact Flash

7 AddresEngine (Aufbau & Performanz)
L B f(HW _Accelerator):f(Pentium4) = 1:30 ! Input FSM Input Local Mem Matrix LIS IPIF Output FSM Output Local Mem Userlogic Resolution Total Pixels Theor. Processing time HW (100 MHz, 7x7Matrix) Meas. Processing Time HW (100 MHz, 7x7 Matrix) Time SW (3 GHz, 320 x 240 76.800 0.768 ms 0.801 ms 1.254 ms 640 x 480 3.072 ms 3.145 ms 5.017 ms 1024 x 768 7.864 ms 7.94 ms ms 1024 x 1024 10.48 ms ms ms 1920 x 1080 (HDTV) ms ??? ms ms 7x7 Neighborhood Theoretical values when assuming that one pixel per clock cycle can be processed. This is usually not the case. The biggest problem is how to transfer the pixeldata from the memory to the processing unit (HW accelerator or GPP CPU). Due to the pipelined concept and a local memory inside the accelerator it is possible to process one pixel per clock cycle once the pipeline is filled. CP Cur. Max.

8 Optical Flow Finden von Korrespondenzen Frame t+1 Frame t

9 Optical Flow Finden von Korrespondenzen 11001111 Census-
184 78 25 1 1 164 72 14 1 x 132 109 84 1 1 1 Grauwerte Census- werte Signaturvektor (Darstellung eines Pixels und seiner Umgebung) [1] Fridtjof Stein: “Efficient Computation of Optical Flow Using the Census Transform”, DAGM-Symposium, August 30 - September 1, Tübingen, Germany, 2004, 79-86

10 Optical Flow Softwareversion (70 ms) n m 3 Schritte: Glättungsfilter
Signatur = Adresse Frm. t Frm. t+1 Cnt. Softwareversion (70 ms) n m x,y x,y x,y x,y 1 3 Schritte: Glättungsfilter Censustransformation Korrespondenzsuche . Frame t n x,y x,y 3 x,y x,y 4 . m Frame t+1 x,y x,y 2 x,y x,y 1 Probleme bei HW Implementierung: unzusammenhängende Speicherbereiche (kein bursting) möglich Counterupdate erfordert für jede Schreib- eine Leseoperation Bewegungsvektoren über ganzes Bild möglich (oft false positives) Algorithmus ungeeignet für Hardware!!! -> tatsächlich?

11 Optical Flow Hardwareversion (4 ms) n n m m 3 Schritte: = ?
Signatur = Value Hardwareversion (4 ms) n n … . . . . m m … 3 Schritte: Glättungsfilter Censustransformation Korrespondenzsuche = ? Frame t n n … m . . . . m … Frame t+1 Die schnellste Übertragungsmöglichkeit von Daten über den Bus ist »Direct Memory Access (DMA)«. Dabei übergibt die CPU dem DMA-Controller nur die Startadressen der Quelle und des Ziels, sowie die Blockgröße des zu übertragenden Datenpakets. Der DMA-Controller führt daraufhin den Transfer ohne weitere CPU-Belastung durch. Für einen Datentransfe bedeutet dies, dass große Bildpakete in 4-KByte-Pakete unterteilt werden. Für jedes dieser Datenpakete muss ein eigener DMATransfer aufgesetzt werden, da diese im physikalischen Adressraum nicht hintereinanderliegen. Die CPU ist somit durch die Datenübertragung blockiert und nicht in der Lage, eine Verarbeitung der Bilddaten durchzuführen. Deshalb kann ein Scatter-Gather-DMA-Transfer eingesetzt werden. Vor der Übertragung der Bilddaten wird eine Tabelle mit den physikalischen Startadressen der Blöcke auf die Bilderfassungskarte geladen. Die physikalischen Blöcke können dabei als »nicht verschiebbar« markiert werden, so dass die Tabelle nur einmalig geladen werden muss. Während der Übertragung holt sich der DMA-Controller die nötigen Adressen selbständig aus dieser Tabelle, und die Bilddaten können so kontinuierlich über den Bus geschoben werden. Die CPU bleibt durch diesen Transfer fast unbelastet und ist damit frei für ihre eigentliche Aufgabe: die Bildverarbeitung. Vorteile: Bursting möglich Kein kompliziertes Counterupdate erforderlich Bewegungsvektoren begrenzt durch Nachbarschaft Algorithmus in dieser Form ungeeignet für Software!!! Probleme für High level Tools

12 Optical Flow - Implemenierung
B Input FSM Input Local Mem Matrix 64 LIS IPIF 64 Output FSM Output Local Mem 8 Userlogic1 Input FSM Input Local Mem Matrix 64 LIS IPIF 64 Output FSM Output Local Mem 32 Userlogic2 Input FSM Input Local Mem Matrix 64 LIS IPIF 64 Output FSM Output Local Mem 64 Userlogic3

13 Optical Flow - Implemenierung
B Input FSM Input Local Mem Matrix 64 LIS IPIF Block 1 8 Userlogic1 Int. Local Mem 1 Matrix 64 Block 2 Userlogic2 32 Int. Local Mem 2 Matrix Block 2 64 Output FSM Output Local Mem Userlogic3 Block 3

14 Kooperationen Rekonfiguration:
Erlangen: “VideofilterEngines auf der ESM”, Raphael Polig, Matthias Kovatsch, Ulrich Batzer Dresden: Merker, Rullmann: Netzlistenvergleich Karlsruhe: Becker, Hübner, Braun: Studentenaustausch IBM: “HW Beschleunigung für die Berechnung von Optischen Masken auf einem rekonfigurierbaren Cell Blade”, Raphael Polig Informatik TUM, Lehrstuhl für Informatikanwendungen in der Medizin & Augmented Reality: “homography-based object tracking” Hardware Beschleunigung: Institut für Luft und Raumfahrttechnik (LRT): “HW Beschleunigung für still image compression - FPGAs im Orbit”, Stephan Schropp Robert Bosch GmbH: “FPGAs im Automobil”, Robert Hartl BMW: “Optical flow”, Andreas Laika BYU (Utah): “Optical flow“, Lei Jia

15 Publikationen Mai 07-Mai 08
J. Angermeier, U. Batzer, M. Majer, J. Teich, C. Claus, W. Stechele, "Reconfigurable HW/SW Architecture of a Real-Time Driver Assistance System", International Workshop on Applied Reconfigurable Computing (ARC2008), Imperial College London, U.K., March 26-28, 2008 N. Alt, C. Claus, W. Stechele, "Hardware/software architecture of an algorithm for vision-based real-time vehicle detection in dark environments", Design, Automation & Test in Europe (DATE 2008), Munich, March 10-14, 2008 M. Ihmig, N. Alt, C. Claus, A. Herkersdorf, "Resource-efficient Sequential Architecture for FPGA-based DAB Receiver", Workshop zu Software Radio “WSR 08”, Karlsruhe, March 5-6, 2008 C. Claus, W. Stechele, A. Herkersdorf, "Autovision-A Run-time Reconfigurable MPSoC Architecture for future Driver Assistance Systems", it - Information Technology Journal, Issue No. 3, June 20, 2007 C. Claus, W. Stechele, M. Kovatsch, J. Angermeier, J. Teich "A comparison of embedded reconfigurable video-processing architectures", submitted to the International Conference on Field Programmable Logic and Applications (FPL08), Heidelberg, Germany, September 08-10 C. Claus, B. Zhang, W. Stechele, L. Braun, M. Hübner and J. Becker "A multi-platform controller allowing for maximum dynamic partial reconfiguration throughput", submitted to the International Conference on Field Programmable Logic and Applications (FPL08), Heidelberg, Germany, September 08-10

16 Demonstratoren Cebit2008, FAU & TUM: Videofilter auf der ESM
(Bild oben) Date2008, KIT & TUM: Monday Tutorial (ohne Bild) Date2008, TUM, University Booth: TaillightEngine (Bild mitte) BMW & TUM: In-car Demonstrator (Bild unten) v.l.: W. Stechele, R. Polig, C. Claus, M. Kovatsch, M. Majer N. Alt AutoVision im 5-er BMW

17 Zusammenfassung & Ausblick
Minimierung des Ressourcenbedarfs bei gleichzeitiger Maximierung der Performance -> kürzere Rekonfigurationszeiten Neue hoch-performante Videofilter, output von Pixeln und features möglich Redesign von Bildverarbeitungsalgorithmen notwendig Alternative SoC Architektur (Bsp. MPMC statt PLB Anbindung der Engines, CPUs etc, Simulation und Implementierung) Demonstrator mit Reconfiguration (FPL08) SystemC Simulator (Rekonfigurationsdaten vs. Bilddaten)

18 Vielen Dank für ihre Aufmerksamkeit

19 Speicherminimierung 1023 8x1024x32 bit = 16X512x32 bit = 16 BRAMs 32
1023 8x1024x32 bit = 16X512x32 bit = 16 BRAMs 32 32 7 Local Input Memory BRAM 512x32 bit … 1 2 3 4 5 6 7 8 1023 … 1 1 1 2 1 3 1 4 1 5 1 6 1 7 1 8 1 1023 … 2 2 1 2 2 3 2 4 2 5 2 6 2 7 2 8 2 1023 64 … 3 3 1 3 2 3 3 4 3 5 3 6 3 7 3 8 3 1023 … 4 4 1 4 2 4 3 4 4 5 4 6 4 7 4 8 4 1023 … 5 5 1 5 2 5 3 5 4 5 5 6 5 7 5 8 5 1023 … 6 6 1 6 2 6 3 6 4 6 5 6 6 7 6 8 6 1023 1023 … 7 7 1 7 2 7 3 7 4 7 5 7 6 7 7 8 7 1023 1 2 3 4 5 6 7 32 Bit Pixel 8x1024x32 bit = 16X512x32 bit = 16 BRAMs (Soll) Auslastung 100% 8 Bit Pixel 8x1024x8 bit = 4X512x32 bit = 4 BRAMs (Soll) Auslastung 25%