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
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.
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.
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.
Hängt von der Anwendung ab. In Smartphones sind meines Wissens keine FPGAs drin, sondern spezielle DSPs, welche große Datenmengen von den Kamerasensoren nehmen, sehr viel Bildaufbereitung damit treiben und im Zweifelsfall auch codieren/komprimieren. Dazu kommen neuerdings "Neuroblöcke", mit denen Gesichts- oder Objekterkennung gemacht werden. Wie das im Rest der Bilder-und-Videowelt aussieht, weiß ich nicht. Ich sehe aber einiges an Bastelkram mit Raspberry Pi und vergleichbaren Systemen.
:
Bearbeitet durch User
Tobias N. schrieb: > Wurden die FPGAs durch Video-DSPs wirklich so verdrängt, wie The Expert > es postuliert? Immer haeufiger kommen MPSoCs Systeme mit FPGA, GPU und CPU (z.B. von Xilinx die Zynq Ultrascale+) zum Einsatz. Damit lassen sich dann wirklich komplexe Dinge anstellen und man kann je nach Anforderung des entsprechenden Video Algorithmus diesen in dem einen oder anderen Teilsystem laufen lassen. Diese Teile sind jedoch relativ teuer, gross und "hungrig". Im Broadcast Bereich und der Medizintechnik (z.B. Endoskopie) sind diese FPGAs (besser gesagt MPSoCs) genau das richtige. Kleine Stueckzahlen und hohe Verkaufspreise rechtfertigen da eigentlich immer deren Verwendung (sofern man auch auf die Processing Power angewiesen ist). Diese Entwicklung sieht man auch im SDR Bereich. Mittlerweile bietet Xilinx die RFSoCs an, welche sauschnelle ADCs und DACs beinhalten. Man kann momentan wirkluch den Trend erkennen, dass man versucht moeglichst viele Funktionen in einen Chip zu bekommen (was ich als Entwickler natuerlich klasse finde :-)). Liegt unter anderem auch darin, dass die Strukturgroessen im Silizium immer kleiner werden, die Chips aber nicht wirklich mitziehen koennen (hauptsaechlich wegen dem Wire Bonding fuer die Highspeed Schnittstellen). Anstatt jetzt immer mehr und mehr Logikzellen in die Chips zu packen, werden neue Funktionen in Hardware gegossen, z.B. H.264/H.265 Decoder/Encoder (wobei nur ein Teil des Codings in Hardware ist, ein Teil ist immer noch in FPGA Logik, inkl. die Anbindung zum SDRAM).
:
Bearbeitet durch User
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..
Tobias N. schrieb: > Wurden die FPGAs durch Video-DSPs wirklich so verdrängt, wie The Expert > es postuliert? Bei bestimmten Lösungen ist das aus Kostengründen durchaus der Fall. Man kommt aber heute um so rascher an Bandbreitenprobleme. FPGAs sind daher zumindest immer noch nötig, wenn es um das Anbinden von schnellen Bild-Sensoren und -Wandlern geht. Auch zwischen DSP und FPGA gibt es limits. Die Lösung bringen SoC-Systeme, in denen die CPUs zwar nicht so schnell sind wie externe DSPs, aber eine breitbandige Anbindung zum FPGA-Teil hin haben, die sich so zwischen 2 Bausteinen schlecht oder gar nicht realisieren ließe. Bringt man nun noch die Initiative ins Spiel, dass "normale" PC-CPUs FPGA-Strukturen bekommen, würde ich den Markt so darstellen, dass die 3 Bausteinfamilien aufeinander zu wachsen. Wahrscheinlich gibt es in einigen Jahren keinen strukturellen Unterschied mehr zwischen klassischen CPUs und FPGA-basierten SoC-Systemen. Es gibt nur noch Unterschiede im Ausbau bez. internem RAM, Anschlussfähigkeit von Speicher (= Anzahl interne Controller) und integrierter Peripherie. Das übliche Zeug wie USB, Ethernet, LVDS-SERDES werden die alle serienmäßig haben.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.