AutoVision – eine situationsadaptive SoC Architektur für videobasierte Fahrerassistenzsysteme

Technische Universität München

Lehrstuhl für integrierte SystemeProf. Dr. sc. techn. Andreas Herkersdorf Arcisstrasse 2180290 Munich, Germany

http://www.lis.ei.tum.de

AutoVision – eine situationsadaptiveSoC Architektur für videobasierte

Fahrerassistenzsysteme

Dipl.-Ing. Christopher ClausProf. Dr.-Ing. Walter Stechele

2


AutoVision - 27.5.2008

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

Shape Engine

Tunnel Engine

Cont/Edge Engine

TaillightEngine

PPC

HighwayX X

Tunnel entrance

X X X

Inside tunnel

X X

Region to enhance contrast

DDR SDRAM

TunnelE.

TaillightE.

EdgeEng

EdgeEng

Virtex II Pro FPGA

PPC1 I/O

PPC0 Video IF

PLB

Coproc0 ShapeEng Coproc1 EdgeEng ICAP MEM IF

EdgeEng

ShapeEng ShapeEng

CoprozessorKonfigurationen

• 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

4



Interconnect

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

Bitstream im Memory

5



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

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)

TaillightEngine

Alte AdressEngine Neue Addressengine

# an Bildzeilen (8bbp) 8 8

# an Slices 134 (0%) 221 (1%)

# an BRAMs 16 (11%) 4 (2%)

6



Demonstratoraufbau

PLB

OPB

XC2VP30

Reconfigurable part

SDRAM Contr. SDRAM

Video in

SysAce Compact Flash

DCR

Framebuffer RAM

DVI or

VGA

LISIPIFPPC1 PPC0

PLBICAP

LISIPIF

Video out

LISIPIF

Busmacro

LISIPIF

Engine 1

Busmacro

LISIPIF

Engine 0

OPB2PLBPLB2OPB

SysACECntrl

7



AddresEngine (Aufbau & Performanz)

PLB

InputFSM

LIS IPIF

InputLocal Mem

Matrix

UserlogicOutput

Local MemOutput

FSM

Resolution Total Pixels

Theor. Processing time HW (100 MHz, 7x7Matrix)

Meas. Processing Time HW (100 MHz, 7x7 Matrix)

Theor. Processing Time SW (3 GHz, 7x7 Matrix)

320 x 240 76.800 0.768 ms 0.801 ms 1.254 ms

640 x 480 307.200 3.072 ms 3.145 ms 5.017 ms

1024 x 768 786.400 7.864 ms 7.94 ms 12.845 ms

1024 x 1024 1.048.000 10.48 ms 10.566 ms 17.126 ms

1920 x 1080

(HDTV) 2.073.600 20.736 ms ??? ms 33.869 ms

CP

7x7 Neighborhood

Cur. Max.

f(HW _Accelerator):f(Pentium4) = 1:30 !

8



Optical Flow

Frame t

Frame t+1

Finden vonKorrespondenzen

9



Optical Flow

[1] Fridtjof Stein: “Efficient Computation of Optical Flow Using the Census Transform”, DAGM-Symposium, August 30 - September 1, Tübingen, Germany, 2004, 79-86

18478 25

16472 14

13210984

Grauwerte

1 1 0

1 x 0

1 1 1

Census-werte

11001111

Signaturvektor(Darstellung eines Pixels und seiner Umgebung)

Finden von Korrespondenzen

10



Optical FlowSoftwareversion (70 ms)

x,y 01

Signatur=

Adresse

34

21

.

.

.

.

.

.

0000000000000001

1111111011111111

x,y

x,yx,y

x,yx,y x,y

x,y

x,yx,y

x,yx,y

Cnt.Frm.t

Frm.t+1

1010101010101011

Frame t

Frame t+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!!!

3 Schritte:• Glättungsfilter• Censustransformation• Korrespondenzsuche

-> tatsächlich?

n

m

n

m

11



Optical FlowHardwareversion (4 ms)

01011100

Signatur=

Value

Frame t

Frame t+1

3 Schritte:• Glättungsfilter• Censustransformation• Korrespondenzsuche

01011101 01100011

01000011…

…

.

...

..

n

m

n

m

01011100

01011101 01100011

01000011…

…

.

...

..

n

m

n

m

= ?

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

PLB

InputFSM

LIS IPIF

InputLocal Mem

Matrix

Userlogic1Output

Local MemOutput

FSM

InputFSM

LIS IPIF

InputLocal Mem

Matrix

Userlogic2Output

Local MemOutput

FSM

InputFSM

LIS IPIF

InputLocal Mem

Matrix

Userlogic3Output

Local MemOutput

FSM

64

64 8

32

64

64

64

64 64

13



Optical Flow - Implemenierung

PLB

InputFSM

LIS IPIF

InputLocal Mem

Matrix

Int. Local Mem 1

Matrix

Int. Local Mem 2

Matrix

Userlogic3Output

Local MemOutput

FSM

Userlogic1

Userlogic2

Block 1

Block 2

Block 2

Block 3

64

64

8

32

64

14



KooperationenRekonfiguration:• 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-erBMW

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

32 320 1023 8x1024x32 bit

= 16X512x32 bit= 16 BRAMs

00

01

02

03

04

05

06

07

08

01023

10

11

12

13

14

15

16

17

18

11023

20

21

22

23

24

25

26

27

28

21023

30

31

32

33

34

35

36

37

38

31023

40

41

42

43

44

45

46

47

48

41023

50

51

52

53

54

55

56

57

58

51023

60

61

62

63

64

65

66

67

68

61023

70

71

72

73

74

75

76

77

78

71023

……………………

BRAM 512x32 bitLocal Input Memory

64

0 1 2 3 4 5 6 7

0

1023

32 Bit Pixel 8x1024x32 bit= 16X512x32 bit= 16 BRAMs (Soll)Auslastung 100%

8 Bit Pixel 8x1024x8 bit= 4X512x32 bit= 4 BRAMs (Soll)Auslastung 25%

0

7

Documents

AutoVision – eine situationsadaptive SoC Architektur für videobasierte Fahrerassistenzsysteme