ARM vs FPGA

[XBert]

Hi Leute,
In meinem nächsten (Langzeit-) Projekt möchte ich Kamera-Daten (doppelte Hd-Auflösung, 2560×720 bei 60fps) manipulieren. Mit "manipulieren" meine ich vorerst nur so etwas wie Filter anwenden, oder Kantenfindung und natürlich komprimieren, später vielleicht aber auch aufwendigere Dinge wie Color-Segmentation o.Ä.
Das schreit natürlich nach einem sehr leistungsfähigen Controller.
Meine Frage ist daher: Soll ich einen FPGA oder einen ARM-Prozessor verwenden (einarbeiten müsste ich mich in beide).
Ich hoffe es kann mir jemand helfen meine Vorteil/Nachteil Liste zu ergänzen:

Vorteile FPGA:
1) echt-parallele Verarbeitung
2) Algorithmus wird praktisch in Hardware realisiert -> schnell
Nachteile FPGA:
1) neu zu lernende Sprache (VHDL)
2) teuer (darum werd ich wohl ohnehin nicht herumkommen)
3) geringe Taktfrequenz (laut Mikrocontroller.net 300-600MHz [ist das überhaupt aussagekräftig?])

Vorteile ARM:
1) relativ einfach in C zu programmieren (es könnte z.b der Linux-Kernel compiliert werden)
2) günstiger
3) hohe Taktfrequenz (je nach Modell natürlich)
Nachteile ARM:
1) kein echtes parallel processing

LG XBert

[BlackDevil]

Ein ARM mit Realzeit Betriebssystem ist schon nicht langsam. Mit einem Embedded Linux hast du da ggf. auch vorteile.

Und unterschätz das Platinen Layout bei solch hohen Frequenzen nicht. Vor allendingen wenn du über 600MHz und in die Ghz Region gehst

[XBert]

Bei meinem ersten Prototypen werde ich ein fertiges Board verwenden. Insofern ist mir das Layout vorerst egal.
Allerdings ist mein Endziel natürlich ein eigen designtes Board, das möglichst klein werden soll.
Und damit ist natürlich auch wichtig welcher Controller mit weniger externen Komponenten auskommt.

Ich frage mich im Moment aber auch wie portable VHDL ist??
Denn wenn ich drauf kommen sollte, dass mir die Rechenleistung des FPGA nicht reicht, wäre ich nicht sehr erfreut alles von Grund auf neu machen zu müssen nur um einen schnelleren Controller verwenden zu können.

LG

[Richard]

Vor einigen Jahren war in der C`t ein Bericht über eine Software welche
aus C-Code einen Code für FPGA`s erzeugt hat. Denmach reicht es also
wenn man mit C klarkommt. Wie solche Software jetzt heißt und was diese
kostet? Ich könnte mir aber vorstellen das die FPGA Hersteller da mehr
wissen.....die wollen Verkaufen.

Gruß Richard

[rideyourstyle]

Wie wärs mit einem DSP? Ich denke für das Bearbetein von Videodaten ist das die beste Variante. (Speicher, Rechnengeschwindigkeit, Libs?)

Es würde auch ARM mit FPGA in einem Chip geben. FPGA- Teil für schnelle Rechnungen und ARM fürs "einfache" Programmieren :-|

[Besserwessi]

Eine ARM CPU wird dafür zu langsam sein. Das klingt nach einer Aufgabe für eine großes / schnellers FPGA, einen high-end DSP (mehrere Kerne), oder auch eine Kombination. Mit nur einem ARM sollte man es leichter angehen (z.B. VAG Auflösung bei 25 fps).

[Vitis]

Das sind dann mal locker 110 Megabyte / Sekunde?¿

Das nenn ich ehrgeizig mit ARM .... nee, das wird mit
FPGA einfacher. Bin auch grad an so ner Geschichte dran,
allerdings kleinere Auflösung und FPGA ...
Parallel die Daten rein und direkt durch in DRAM, bei Frame Ende
Daten durchshiften und Sobel per Byteshifts, Daten wieder raus
in anderen Rambereich, dann einfach per µC durch den FPGA
durch auf den höheren RAM-Bereich zugreifen.

Es mag auch anders gehen, aber n ARM7 oder ARM9 halt ich
für wenig wahrscheinlich das der die IO-Operationen schafft.
Die Rechenoperationen kann gehen, aber es müssen ja auch Ports
gelesen bzw. geschrieben werden ...

[Richard]

Ich habe gerade vor kurzen eine Videoüberwachung in betrieb
genommen, 16 Kameras (pro Karte) mit 50 F/s + Audio. Wobei sich
die Kameras die Zeit teilen, es sind also je nach Kamera Anzahl auch
höhere Farmraraten möglich.....Ich habe allerdings nicht darauf geachtet
was für Chips dort verwendet wurden, und wahrscheinlich sind die auch
abgeschliffen? Aber die Leistung ist schon echt guuuuut. Ich vermute
das da auch FPG`s eingesetzt sind, die Chips sind enorm Groß was eine
hohe Anzahl von Elementen/Transistoren vermuten Lässt.

Gruß Richard

[XBert]

Wie wärs mit einem DSP?

Welchen?? ich kenne nur solche, die das Bild komprimieren und weitergeben.

Das sind dann mal locker 110 Megabyte / Sekunde?¿

Nur wenn 1 Pixel = 1 Byte sind. Ich rechne eher mit 12-14Bit pro Pixel -> und daher eher mit 200Mb/s.
Das wird vermutlich eine Riesenaufgabe das über USB 2.0 zu bringen.....
Ich fürchte ebenfalls, dass ich einen USB 3.0 Controller brauche, weil eventuell die Kompression(ohne zu großem Verlust) nicht gut genug ist, und bei USB 2.0 maximal 500mA Strom gezogen werden dürfen, aber alleine vom Sensor schon 600mA gebraucht werden. (man könnte aber auch die Stromversorgung von 2 USB 2.0 Ports verwenden, oder eben einen USB 3.0 Port)

Aber eure Antworten bestärken meine Vermutung, dass es wohl nur mit einem FPGA funktionieren könnte;

LG

[Besserwessi]

Wenn es ein DSP sein sollte, dann ungefähr so etwas.
http://focus.ti.com/docs/prod/folder...20dm6467t.html

oder ein größerer Bruder, wenn mehr gemacht werden soll.

Die Programmierung ist aber auch beim DSP nicht einfach.