190 likes | 323 Views
AutoVision – eine situationsadaptive SoC Architektur für videobasierte Fahrerassistenzsysteme. Dipl.-Ing. Christopher Claus Prof. Dr.-Ing. Walter Stechele. Agenda. Video-basiertes Fahrerassistenzsystem: AutoVision AutoVision bisher: Rekonfigurationszeiten & overhead
E N D
AutoVision – eine situationsadaptiveSoC Architektur für videobasierte Fahrerassistenzsysteme Dipl.-Ing. Christopher Claus Prof. Dr.-Ing. Walter Stechele
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
Region to enhance contrast AutoVision Prozessor • 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 TunnelE. I/O TaillightE. PPC1 PPC0 Video IF EdgeEng EdgeEng PLB ShapeEng Coproc0 Coproc1 EdgeEng ICAP MEM IF EdgeEng ShapeEng ShapeEng Virtex II Pro FPGA Coprozessor Konfigurationen
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
Demonstratoraufbau • Optimierung und Anpassung der AdressEngine an LIS-IPIF • Optimierung und Anpassung der TaillightEngine (8-fache Beschleunigung) -> Demonstration • Konzeption und Implementierung der ShapeEngine (Eckendetektor) -> Demonstration • Speicher Optimierung, kompakte Engines • Optimierung des Videointerface • Rekonfigurationsgrenzen stehen noch nicht fest TaillightEngine
Demonstratoraufbau Framebuffer RAM DVI or VGA XC2VP30 Video in PLBICAP Video out SDRAM Contr. SDRAM PPC0 PPC1 LISIPIF LISIPIF LISIPIF PLB PLB2OPB LISIPIF LISIPIF OPB2PLB DCR Busmacro Busmacro OPB SysACE Cntrl Engine 0 Engine 1 Reconfigurable part SysAce Compact Flash
AddresEngine (Aufbau & Performanz) f(HW _Accelerator):f(Pentium4) = 1:30 ! P L B Input FSM Input Local Mem Matrix LIS IPIF Output FSM Output Local Mem Userlogic 7x7 Neighborhood CP Cur. Max.
Optical Flow Finden von Korrespondenzen Frame t+1 Frame t
Optical Flow Finden von Korrespondenzen 184 78 25 1 1 0 11001111 164 72 14 1 x 0 132 109 84 1 1 1 Signaturvektor (Darstellung eines Pixels und seiner Umgebung) Census- werte Grauwerte [1] Fridtjof Stein: “Efficient Computation of Optical Flow Using the Census Transform”, DAGM-Symposium, August 30 - September 1, Tübingen, Germany, 2004, 79-86
Optical Flow Signatur = Adresse Frm. t Frm. t+1 Cnt. Softwareversion (70 ms) n 00000000 m x,y x,y 0 00000001 x,y x,y 1 . . . • 3 Schritte: • Glättungsfilter • Censustransformation • Korrespondenzsuche Frame t n 10101010 x,y x,y 3 10101011 x,y x,y 4 . . . m Frame t+1 11111110 x,y x,y 2 11111111 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?
Optical Flow Signatur = Value Hardwareversion (4 ms) n n … 01011100 . . . . 01000011 . . m … m 01011101 01100011 • 3 Schritte: • Glättungsfilter • Censustransformation • Korrespondenzsuche = ? Frame t n n … 01011100 . . . . 01000011 . . m m … 01011101 01100011 Frame t+1 • 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
Optical Flow - Implemenierung P L 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 Userlogic3 64
Optical Flow - Implemenierung P L B Input FSM Input Local Mem Matrix 64 LIS IPIF Block 1 8 Userlogic1 Int. Local Mem 1 Matrix 64 Block 2 32 Userlogic2 Int. Local Mem 2 Matrix Block 2 64 Output FSM Output Local Mem Userlogic3 Block 3
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
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
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
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)
Speicherminimierung 0 1023 8x1024x32 bit = 16X512x32 bit = 16 BRAMs 0 32 32 7 Local Input Memory BRAM 512x32 bit … 0 0 0 1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0 1023 0 … 1 0 1 1 1 2 1 3 1 4 1 5 1 6 1 7 1 8 1 1023 … 2 0 2 1 2 2 2 3 2 4 2 5 2 6 2 7 2 8 2 1023 64 … 3 0 3 1 3 2 3 3 3 4 3 5 3 6 3 7 3 8 3 1023 … 4 0 4 1 4 2 4 3 4 4 4 5 4 6 4 7 4 8 4 1023 … 5 0 5 1 5 2 5 3 5 4 5 5 5 6 5 7 5 8 5 1023 … 6 0 6 1 6 2 6 3 6 4 6 5 6 6 6 7 6 8 6 1023 1023 … 7 0 7 1 7 2 7 3 7 4 7 5 7 6 7 7 7 8 7 1023 0 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%