Bildverarbeitung mit einem FPGA

Bildaufbereitung auf FPGA-Basis hat dann Vorteile, wenn man rudimentäre
Operationen (Glättung, Kantendetektion, LineInterplation etc.)
betreiben möchte. Zudem hat man dann Vorteil, wenn man parallel an den
Datenstrom des Chips drankkommt. Eine Grauinterpolation von virtuellen
Zeilen- oder die Auswertung bestimter CC-Typen mit integrierter
Interpolation durch Mehrfachabtastung lässt sich in einem FPGA
Punktweise parallelisieren: Für eine Überabtastung von 8 je Zeile hätte
man gerade einen Registerbedarf von z.B. 8x2048 LE-Zellen. Je nach Platz
könnte man die Interpolation dann auf z.B. 16 Punkte je Zeile
beschränken und benötigte nur 64 kleine Rechenwerke mit einem
Zeitbedarf von 16 x 8 x 8 Clks + Latenz. Auf diese Weise stünde das
Ergebnis eine Bildzeile später zur Verfügung. Das ist mit einem DSP
unmöglich. Der müsste jeden der 8x8=64 Virtuellen Punkte für jeden
Bildpunkt nacheinander rechnen.

Betrachtet man aber die reine Rechenleistung im 1:1-Vergleich, dann ist
der DSP architektonisch meist überlegen, besonders bei aufwändigen
Algorithmen. Zudem sind komplexe Oprationen in C sehr rasch zu
formulieren.

Man kann alles in einem FPGA unterbringen, egal, wie kompliziert alles
ist. Die Vorteile eines FPGA (Designs) ist, dass man die
Speicherbandbreite so auslegen kann, wie man lustig ist bzw. wie man
braucht.

Ich sitze gerade an einem Bildverarbeitungsdesign im FPGA
(Konzeptphase) und ich kann berichten, dass ich, wie Jürgen schon
gesagt hat, volle Kontrolle habe - ein DSP würde sowas nie im leben
schaffen (2 GPixel/s). So lange man nur kleine Bilder und nicht
Echtzeit hat, ist alles sowieso kein Problem.

Alles in einem würde ich sagen, dass ein FPGA nur in Verbindung mit
schnellem Speicher (mehrere Buffer) gute Dienste leistet.

Kest

Danke für die Antworten.
Bei deiner Antwort habe ich nicht alles 100%ig verstanden, Jürgen, aber
ich schätze mal eine Kreuzkorrelation von 2 Graustufenbildern fällt
nicht unter eine "rudimentäre Rechenoperation" oder?

Doch: Solche Aspekte wie "Pixel(t+1) heller als Pixel(t)" und "Pixel
(x-1) < Pixel (x)" können für alle Pixel in der pipeline parallel
prozessiert und mit einem clock ausgewertet werden. Die
Grauwertinterpolatin wiederum läuft ja auch nur über Additionen und
Teiler, wobei man hier schlauerweise natürlich 2,4 oder wie oben 8
nimmt: Während ein DSP bei Teilen durch 8 nämlich noch 3mal "rollen"
muss, braucht das umverdrahte Ergebnis im FPGA sogar überhauptkeine
Zeiz zum Teilen!

Die komplizierten Dinge sind REAL-Multiplaktionen und
Filteroperationen, die zudem noch auf den finalen Datenstrom angewendet
werden - also eindimensional laufen. Diese im FPGA zu machen, bringt
erstens nicht mehr viel, kostet aber unendliche Implementierungzeit.

Wie gesagt, es kommt darauf an, ob und wie Du an den Chip drankkommst:
Bildverarbeitung per FPGA, das aus einer ferigen Kamera mit ADC
gespeist wird, also nur einen sequentiellen Datenstrom erhält ist nicht
mehr so effektiv.

Also ich werde leider aus den ganzen Infos noch nicht ganz schlau. Ich
bin noch Laie auf dem Gebiet und deinen ersten Beitrag mit den
Zahlenbeispielen konnte ich nicht wirklich nachvollziehen, Jürgen.
Für mich widerspricht sich hier auch noch vieles; einerseits sagt ihr,
FPGAs sind sehr gut geeignet wenn die Daten parallel in den FPGA
gespeist werden können und auch in der Rubrik "DSP" auf dieser Seite
wird mal erwähnt, dass FPGAs noch mehr DSP-Rechenleistung bringen, weil
sie mehr MAC Befehle in einem Zyklus verarbeiten können.
Wenn ich aber auf Herstellerseiten recherchiere, sind DSPs für
Signalverarbeitung (u.a. Bildverarbeitung) das optimale, und FPGAs
können zu Optimierungszwecken mit ins System integriert werden.
Viele Fragen und Anliegen auf einmal - ich verlange jetzt auch nicht
eine umfangreiche Lösung, das is weng viel verlangt, aber vllt kennt
jemand z.B. zufällig eine Quelle wo DSPs und FPGAs genauer
gegenübergestellt werden - das technische Grundverständnis habe ich
eigentlich aus meinem Studium schon..


Gruß
Sebastian

Sagen wir es mal so: Grundsaätzlich sind FPGAs deutlich teuer, wenn man
eine definierte Gesamtrechenleistung eines DSPs realisieren will. Hat
man aber eine Minimalzeitanforderung, die von einem FPGA durch
teilweise ECHTES paralleles Arbeiten leichter erfüllt werden kann, dann
müsste man, um zum selben Ergebnis zu kommen, einen extrem
leistungsfähigen DSP heranziehen oder mehrere parallel schalten, was
wiederum deutlich teuer wäre.

Vielleicht hilft Dir weiter, wenn Du Dir überlegst, daß ein FPGA nur
dann richtig schnell sein kann, wenn alle zu verarbeitenden Daten im
FPGA Platz haben.
Nur dann kann das FPGA schnell darauf zugreifen.
Wenn Dein Algorithmus z.B. nur eine Zeile bearbeitet, dann geht das
locker.
Bei einer 2-dimensionale Korrelation über das ganze Bild brauchst Du
z.B. 800 x 600 x 8Bit/Pixel = 3.840.000 Bits an internem Speicher.
Das wird dann schon ein teureres FPGA.
Du kannst natürlich ein externes RAM an das FPGA anschließen, aber dann
werden wahrscheinlich zu Zugriffe auf die Daten die
Verarbeitungsgeschwindigkeit bestimmen und Du gewinnst nichts gegenüber
einem FPGA.

Grüße
Klaus

Muß natürlich heißen : Du gewinnst nichts gegenüber
einem DSP.

Klaus

Stimmt im Prinzip, aber ein schnelles RAM läuft mit mindestens dem
vollen FPGA-Takt mit und ist nicht wirklich langsamer als die block-RAM
Zellen im FPGA solange keine zweiter Fremdbus auf dem RAM rumnuckelt!
Zudem könnte man an einen breiten FPGA mit entsprechenden PINs mehrere
RAMs parallel anflanschen und gleichzeitg nutzen, indem man z.B.
Bildbereiche aufteilt und parallel rechnen lässt. Ferner ist eine
ühysikalische RAM-Duplikation dann sinnvoll, wenn man über pipelines
arbeitet und eingehende Daten sofort weiterleiten will: Es entfallen
Read/Write/Adressumschaltungen und wait state Situationen. Sowas haben
wir ja hier. Ferner muss im Brreich Video oft mit umschaltbaren
Shadow-RAMs gearbeitet werden: Mit einem FPGA kann ich sehr leicht und
verlustlos umschalten, ob ich zwei RAMS parallel fülle, alternierend
beschriebe bzw. lese oder im Pendelbetrieb Daten von einem ins andere
schaufele. All das geht mit einem DSP oder MC mit einem Daten-ADressbus
nicht bzw nur schön brav nacheinander.
Wenn man es trickreich macht, lassen sich sogar langsame RAMS mit
mehreren waitstates so zeitlich versetzt parallelsieren, daß man mit
JEDEM 100MHz FPGA-Takt Adressen für Quell- und Zielrams setzt und den
aktiuell verfügbaren DAten vorheriger Schritte einen
Verarbeitungsschritt in den Rechenstufen antriggert. Die wait states
und Verzögerungen infolge langsamer RAMSs und kombinatorischer- oder
delaybehafteter Rechenstufen tauchen dann nur als Latenz auf. Wenn ein
kompletter Schreib und Lesezyklus dann 10clks benötigt, hätte man bei
einem DSP 10 x Zahl der RAM-Zugriffe. Ein Zyklus von 1Mio Bildpunkten
wären bei einem FPGA dann aber nur rund 1Mio + 10clks!!!!

Das große Problem der FPGAs ist eben nur, daß die interne Hardware für
Multiplikationen etc. sehr begrenzt ist und schon bei sehr wenig
Algebra sofort erschöpft ist.

weiterhin vielen dank für die ganzen antworten ...
was bedeutet der letzte punkt bei dir genau, jürgen?
wo ist der FPGA schneller erschöpft als ein vergleichbarer DSP?
meinst du damit, dass z.B. eine komplizierte multiplikation durchaus
einen ganzen oder mehrere taktzyklen benötigen kann?

Sebastian

Nein, die konventionellen FPGAs haben z.B. eine Anzahl fest
eingebetteter DSP-Einheiten, die vorwiegend als Multiplizierer agieren.
Hat man einige rechenintensive Funktionen zusammen, sind die rasch
verbraucht. Weitere Funktionen werden über Software verdrahtet oder
über Multiplexing, was die Leitstung rapide senkt. Eine FPU eines DSP
z.B. hat da deutlich mehr Reserven.

Was konkret die Multiplikation angeht: Im Prinzip geht das bis zu
höchsten Taktraten innerhalt eines Clocks. Aber stelle dir mal einen
breiten Multiplizierer vor, der intern aus mehreren einzelnen Stufen
realsiert wird: Dort kommen noch Additionen hinzu. Zusammen mit der
Verdrahtung reicht es dann nicht mehr für hohe Taktraten.

Beispiel: Ich habe einen Aufbau vor einer DSP-Einheit, die eine
Amplitudenkorrektur (A = a x k, mit k = 0... 1,0) vornimmt: Die
arbeitet mit 48 Bit Genaugikeit (damit hinten noch 32 Bit rauskommen)
und lässt sich aktuell mit maximal knapp 100 MHz takten. Ich habe jetzt
zwei parallel geschaltet, um auf die Solldatenrate von 160MHz zu
kommen.

Am Besten, Du nimmst Dir mal eine kostenlose Webedition einer
Designsoftware und baust mal ein wenig rum. Die Synthese wirft Dir ja
dann aus, wie schnell die Architektur ist und welche Reserven genutzt
werden.

> mit 48 Bit Genaugikeit (damit hinten noch 32 Bit rauskommen)
> und lässt sich aktuell mit maximal knapp 100 MHz takten.

Auf welchen Chip bezieht sich das?

Jürgen Schuhmacher schrieb:
> Wie gesagt, es kommt darauf an, ob und wie Du an den Chip drankkommst:
> Bildverarbeitung per FPGA, das aus einer ferigen Kamera mit ADC
> gespeist wird, also nur einen sequentiellen Datenstrom erhält ist nicht
> mehr so effektiv.

Soso, also wenn ich einen Sobelfilter über ein Bild drüberziehe, welches 
ich Pixel für Pixel bekomme muss ich nur warten bis ich die ersten 3 
Zeilen gepuffert habe und dann kann ich ziemlich schnell den Rest 
berechnen ;) oder wenn man wirklich derbe ist versuche ich ein 
systolisches Array zu bauen.

Da Du schon auf einen 3 Jahre alten Beitrag antwortest, hätte ich auch 
eine Frage:

> wenn ich einen Sobelfilter über ein Bild drüberziehe, welches
> ich Pixel für Pixel bekomme muss ich nur warten bis ich die ersten
> 3 Zeilen gepuffert habe
Wie ist Deine Aussage zu verstehen?

Natan schrieb:
> Da Du schon auf einen 3 Jahre alten Beitrag antwortest, hätte ich auch
> eine Frage:
>
>> wenn ich einen Sobelfilter über ein Bild drüberziehe, welches
>> ich Pixel für Pixel bekomme muss ich nur warten bis ich die ersten
>> 3 Zeilen gepuffert habe
> Wie ist Deine Aussage zu verstehen?

Aufs Datum habe ich nicht geachtet, ich meinte dass es nicht stimmt dass 
man da massiv an Effektivität verliert

Ich habe einen solchen Filter im FPGA laufen und keine Probleme damit. 
Sehr effektiv und nutzvoll. Ich bevorzuge nur noch FPGAs, weil ich so im 
Nachhinein zeitkritische Anwendungen implementieren kann, die ich vorher 
nicht gesehen habe - oder der Kunde nicht gesehen hat. Wenn man eine CPU 
genommen hat, die am Anschlag war, ist Essig.

FPGAs sind einfach flexibler. Man kann schlimmstenfalls sogar noch 
Hardware addieren, indem man z.B. über einige Pins Rechenoperationen 
rausstreamed und extern in einem Zusatz FPGA rechnen lässt.

Das geht mit einem Prozessor nicht.

D. I. schrieb:
> Jürgen Schuhmacher
>> Bildverarbeitung per FPGA, das aus einer ferigen Kamera mit ADC
>> gespeist wird, also nur einen sequentiellen Datenstrom erhält ist nicht
>> so effektiv
> Soso, also wenn ich einen Sobelfilter über ein Bild drüberziehe, welches
> ich Pixel für Pixel bekomme muss ich nur warten bis ich die ersten 3
> Zeilen gepuffert habe und dann kann ich ziemlich schnell den Rest
Genau das ist der Vorteil des FPGA, dass er die Daten in Echtzeit 
speichern und verarbeiten kann, während der DSP das nicht kann. Ich 
würde daher auch sagen, dass der FPGA diesbezüglich durchaus effektiv 
ist, gerade bei sequenziellem Datenstrom.

In dem Zusammenhang noch eine Anmerkung von mir (wenn hier schon die 
Grundlagen erörtert werden):

Inzwischen (der Beitrag stammt ja von 2006) gibt es für FPGAs zahlreiche 
Cores mit BV-Algorithmen und Vorlagen, sowie Filtern und Convertern, die 
man einfach instanziieren kann, um sie zu verwenden. Ich kenne kaum noch 
eine BV-Applikation, die Bilder ohne FPGAs generiert oder prozessiert.

Pumpernickel schrieb:
> Inzwischen (der Beitrag stammt ja von 2006) gibt es für FPGAs zahlreiche
> Cores mit BV-Algorithmen und Vorlagen, sowie Filtern und Convertern, die
> man einfach instanziieren kann, um sie zu verwenden.
Die gab es damals auch schon :-)
Manche tun immer so, als seien FPGAs etwas Neues und letzte Woche erst 
erfunden worden. Schon vor 10 Jahren haben wir Bildverarbeitung mit 
FPGAs gemacht und vor 5 Jahren mit partiell rekonfigurierbaren V2Pro.

> Ich kenne kaum noch eine BV-Applikation, die Bilder ohne FPGAs
> generiert oder prozessiert.
Da kenne ich aber einige! FPGAs haben ihr einsatzgebiet, aber DSPs 
werden immer schneller und besetzten immer mehr Applikationen, die einst 
FPGAs vorbehalten waren. Schon mit einem schnuddeligen 500MHz-Blackfin 
hat man RAM und VideoDSP-Power genug, um rudimentäre Bildprozessierung 
zu betreiben.

Ich möchte in die Expertenrunde fragen, wie sich das heute entwickelt, 
hat. Gegenüber der Aussage zuletzt, sind wieder 5 Jahren vergangen.

Wurden die FPGAs durch Video-DSPs wirklich so verdrängt, wie The Expert 
es postuliert?

The Expert schrieb:
> aber DSPs werden immer schneller und besetzten immer mehr
> Applikationen, die einst FPGAs vorbehalten waren.

Ich habe nicht den Eindruck. Eher im Gegenteil.

S. R. schrieb:
> In Smartphones sind meines Wissens keine FPGAs drin, sondern spezielle

Einen ICE40 findest du noch öfters...der macht aber kaum BV, eher 
Signalwandlung.

Der Trend geht neben der oben erwähnten komplexen SoCs wohl auch 
vermehrt Richtung GPU und eigendesignte Spezial-DSP-Coprozessoren, 
zumindest beim massgeschneiderter BV, seit in einigen progressiveren 
Domänen nicht mehr nach reiner HW versus SW-Schule entwickelt wird. So 
ein paar Fernost-Firmen sind da recht pfiffig in der Entwicklung von 
Video-Encodern.

Da time to market beim DSP-Ansatz doch deutlich geringer ist und die 
Sache zudem recht flexibel ist ('mal eben zur Laufzeit Mikrocode 
updaten'), ist der klassische DSP sicher nicht vom Tisch, er findet sich 
allenfalls einfach im FPGA wieder. Wird aber kaum einer gross so 
anpreisen, da Developer-Communities Aufwand generieren..