mikrocontroller.net

Forum: FPGA, VHDL & Co. Bildverarbeitung mit einem FPGA


Autor: Sebastian Reichert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

laut euren Seiten zu FPGAs und DSPs sind letztere das ideale Werkzeug
um Digitale Signalverarbeitung (und speziell auch Bildverarbeitung)
durchzuführen. Wie gut eignen sich hierzu FPGAs, wenn ich möglichst
schnell (Graustufen-)Bilder, die von einem CCD-Chip kommen, verarbeiten
will(FFT, Mustererkennung, o.ä.)?
Wie sieht es bei den genannten Architekturen hinsichtlich der
Speicherintensität des Prozesses aus?
Grundsätzlich würde ich das ganze natürlich erst mal auf einem PC
testen, aber mir geht es nur mal generell um die Realisierbarkeit.
vielen Dank schon im Voraus..

Gruß
Sebastian

Autor: Jürgen Schuhmacher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sebastian Reichert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jürgen Schuhmacher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sebastian Reichert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jürgen Schuhmacher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus Falser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klaus Falser (Gast)
Datum:

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

Klaus

Autor: Jürgen Schuhmacher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sebastian Reichert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jürgen Schuhmacher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Natan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?

Autor: D. I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Natan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: D. I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bildverarbeiter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Pumpernickel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine damalige Aussage "nicht so effektiv" bezog sich nicht auf den 
Vergleich FPGA/DSP sondern auf die Art, wie der Sensor angebunden ist: 
Üblicherweise wird bei "normalen Sensoren" Pixel für Pixel ausgegeben, 
wie ein Monitor sie benötigt, um das Bild direkt darzustellen.

Leistungsstarke Sensoren mit hoher Auflösung haben dagegen oft mehrere 
parallel Ausgänge mit denen die Pixel gruppenweise ausgegeben werden 
können Die zu prozessieren gelingt nur mit FPGAs effektiv und gegenüber 
dem eindimensionalen Ausgang dann auch richtig schnell.

Im eindimensionalen Fall packen das Video-DSPs auch noch, wenn sie 
schnell genug arbeiten - sie sind ja im Vergleich viel höher getaktet, 
als FPGAs. Die Frage ist halt immer, was "Echtzeit" im konkreten Fall 
heisst.

Autor: The Expert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.