Hallo Leute,
ich habe einen Algorithmus für eine relativ effiziente Objekterkennung
bzw. Szenario-Analyse entwickelt. Ich verwende dafür momentan einen
Windows-Rechner mit .Net (C#) und eine Axis Kamera als Lieferant für die
Bilder. Diesen Algorithmus halte ich für effizienter als andere
Algorithmen, da er komplett parallelisiert ist. Auf der Windows Kiste
läuft das Teil momentan bei mir mit 128 Threads auf 8 CPUs.
Der geschriebene Code ist momentan so halbwegs optimiert, deshalb sehe
ich keine weitere Möglichkeit mehr, einen Geschwindigkeitsgewinn zu
erreichen. Deshalb habe ich momentan an FPGAs gedacht. Denn wenn ich
dort einen neuen Parallelprozess erstelle, dann ist es ein reiner
Geschwindigkeitsgewinn, da wird nicht die Performance eines anderen
Prozesses abgezwackt, wie bei einer normalen CPU (unter Last).
Doch leider habe ich keine Ahnung, was ich für ein FPGA brauche, da ich
absolut nicht einschätzen kann, wieviele Logic Blocks ich brauche. Als
ich damals noch am Fraunhofer gearbeitet habe, hatte "die andere
Abteilung" so schöne FPGA Boards für afaik 6k€, mit denen die Leute
Bildanalyse gemacht haben. Das Geld habe ich da einfach nicht. Kann mir
von euch jemand ein Entwicklungs-Board empfehlen, mit dem ich zumindest
mal die ersten Entwicklungsschritte machen kann? Wichtig ist nur, dass
es Ethernet hat, um die Bilder der Kamera zu empfangen.
Was sollen wir dir jetzt dazu sagen? Ohne den genauen Algorithmus zu
kennen ist es absolut sinnlos sich darüber Gedanken zu machen.
Probier halt einfach mal aus, den Algorithmus auf einen beliebigen FPGA
zu portieren und dann schauste, was du brauchst. Das geht alles, ohne
auch nur ein Stück Hardware in der Hand zu haben.
MfG
Marius
Gute Einsteigerboards sind z.B. die Boards von Digilent (Nexys4 oder
Atlys) bzw. ein ähnliches von Altera (DE2).
Einfacher wäre bestimmt die Verwendung einer anderen Kamera, die die
Bilder nicht über Ethernet liefert, da man daran wahrscheinlich schon
einige Monate, als Anfänger wahrscheinlich eher ein Jahr, arbeitet.
Für das DE2 gibt es ein Kameramodul, das verwenden wir an der Uni im
Labor ebenfalls für Objekterkennung.
Es gibt einige Firmen, die an Systemen arbeiten und/oder gearbeitet
haben, die parallel arbeitende Software-Strukturen in FPGAs realiseren
(sollen) und immer ergab sich am Ende das Bild, dass die Algorithmen nur
schneller wurden, weil z.B. 8 FPGAs 64 CPUs emulierten. Effektiv sind
diese Implementierungen nur dann, wenn schon viel C Code vorliegt
und/oder die C-Strukturen so sind, dass virtuelle Tiefen berechnet
werden müssen. Dann ist die Portierung auf einen FPGA sinnvoll.
Richtig vernünftig wird das aber nie, weil FPGAs andere Möglichkeiten
der Parallelität haben, die von C-Software nicht genutzt werden kann und
die folglich nicht implementiert ist. Software von C-Entwicklern taugt
also nicht für die Portierung in einen FPGA. Dann ginge es schon eher in
die GPU-Sparte. Dort ist man entsprechend weit, die Anbindung ist auf C
ausgelegt und die Geschichte ist viel effektiver, als auf einem FPGA,
weil viel mehr Units zur Verfügung stehen.
Das Beste ist nach wie vor eine spezialisierte Lösung im FPGA, der die
GPU-Lösungen nochmal um Faktor 5-10 schlagen kann, weil er flexible
Strukturen zulässt. Allerdings sind diese dann auch entsprechend teuer.
Zusammenfassen würde ich sagen:
1. Einfache, langsame Bildverarbeitung auf preiswerten PC-Plattformen in
C/C++, super günstig, bei Nutzung des PCs als GUI-Plattform die beste
Lösung bis zu einer definierten Bandbreitengrenze
2. Komplexe Bildverarbeitung auf GPUs, immer noch in C, etwas
ineffektiver, als Intel-CPU, dafür aber mit viel Parallelität erheblich
höhrere Rechenleistungen möglich, Strukturen noch einigermassen
handhabbar, Libs verfügbar, im Falle der Doppelnutzung von PC und Graka
auch finanziell sehr effektiv, bei Spezial-Graka weniger effektiv
3. Ultimative Bildverarbeitung auf FPGAs mit erheblich höheren
Bandbreiten und Datendurchsatz, falls GPU nicht reicht oder Graka nicht
möglich, oder BV-Algo ohnehin nicht als SW vorliegt,
Bei Punkt 3 hat man eben die Option, auch einen kleinen Mini-FPGA in den
Datenstrom zu schalten und Vorverarbeitung zu machen, die weder mit GPU
noch mit CPU möglich wäre und vom Platz her schon nicht ginge. Dafür
kostet der FPGA auch soviel wie eine ganze Graka und ein grosser FPGA
soviel wie ein Server.
Sieh Dir mal die NVIDA Seiten an. Die haben da Libs für GPU.
Gregor schrieb:> Wichtig ist nur, dass> es Ethernet hat, um die Bilder der Kamera zu empfangen.
Ethernet haben die FPGAs alle. Die haben sowieso alle alles. Dein
Ethernetcontroller ist da in VHDL gemacht. Das ist dann "wie in der
Hardware" ein Modul. Jeder Pin (außer Power- bzw. GND-Pin) ist am FPGA
alles, einfach alles. Deinen Ethernetcontroller wirst du kaufen müssen.
Das ganze nennt sich IP (intellectual property) und wird von jedem
FPGA-Hersteller geliefert (gegen gute Preise). Alternativ kannst du dir
auch bei Drittfirmen (Vector, Mentor, ...) den Ethernetstack kaufen,
Preise sind 5- bis 6-stellig. Die kann man dann aber sofort verwenden.
Out of the box. Wir haben auf der Arbeit einen recht günstigen (~5k€)
von Altera gekauft, 1 Mannjahr Entwicklungszeit von 2 FPGA-Spezialisten
und das Ding rennt wie der Teufel (Gigabit-Ethernet). --> du brauchst
eine andere Kamera oder Linux wo der Ethernetstack schon drin ist. Es
gibt auch FPGAs mit SoC in einem Gehäuse. Das wäre evtl. was für dich.
Peter schrieb:> Es gibt auch FPGAs mit SoC in einem Gehäuse.
Hier wäre als bekannter Vertreter die Zynq-Plattform von Xilinx zu
nennen.
Es gibt auch schon mehrere Eval-Boards mit Zynq, etwa das Zedboard. Auch
von Digilent wurde bereits eines angekündigt.
Der Vorteil dabei ist, dass man die Vorteile eines SoC und eines FPGA
praktisch vereint hat. Auf dem SoC Teil läuft eine Linux, über einen Bus
wird mit dem Logikteil kommuniziert. So wäre es möglich, die Bilddaten
über Ethernet zu empfangen, dann mit eigenen Recheneinheiten in Hardware
zu verarbeiten und wieder an das Linuxsystem zurückzugeben.
Gregor schrieb:> Der geschriebene Code ist momentan so halbwegs optimiert, deshalb sehe> ich keine weitere Möglichkeit mehr, einen Geschwindigkeitsgewinn zu> erreichen.
SSE, SSE2, SSE3, AVX und wie das alles heisst nutzt Du schon (für die
kritischsten Schleifen per Hand in Assembler geschrieben meine ich)...
Peter schrieb:> Jeder Pin (außer Power- bzw. GND-Pin) ist am FPGA> alles, einfach alles. Deinen Ethernetcontroller wirst du kaufen müssen.> Das ganze nennt sich IP (intellectual property) und wird von jedem> FPGA-Hersteller geliefert (gegen gute Preise).
Darf ich mal fragen, wieso ich den Ethernet Controller als IP kaufen
muss und nicht als Chip? Ich meine z.B. Chips wie den RTL8169SB von
Marvell. Oder die ENC28J60 Schnittstelle, mit der ich per SPI sprechen
kann.
Grendel schrieb:> SSE, SSE2, SSE3, AVX und wie das alles heisst nutzt Du schon (für die> kritischsten Schleifen per Hand in Assembler geschrieben meine ich)...
Nein, wie gesagt, der Code ist momentan in C# geschrieben. Ich stehe
momentan eben an der Stelle, an der ich mich für eine Architektur
entscheiden muss.
Nehme ich jetzt wirklich die CPU und optimiere alles darauf, dann bin
ich vll. doppelt so schnell, wie jetzt.
Entscheide ich mich für eine GPU und optimiere dafür alles, dann habe
ich evtl. einen Faktor 8-10. Ja, auch das habe ich auch schon
ausprobiert mit einer relativ neuen Nvidia Gamer GraKa. Nur das Problem
ist, dass da einfach Schluss ist. Wieviele GraKas kann ich in den
Rechner reinwerfen? 4? Dann bin ich bei einem Faktor 40, was schon nicht
schlecht ist.
Wenn ich nun aber einen FPGA nehme, dann kann ich damit eine bestimmte
Anzahl an Kernen umsetzen, die imho durch die LBs begrenzt wird. Aber
ich kann zig FPGAs auf ein Board drauflöten. Und damit würde alles
skalieren.
Gregor schrieb:> Wenn ich nun aber einen FPGA nehme, dann kann ich damit eine bestimmte> Anzahl an Kernen umsetzen, die imho durch die LBs begrenzt wird. Aber> ich kann zig FPGAs auf ein Board drauflöten. Und damit würde alles> skalieren.
Naja, das ist aber eine sehr einfache Sicht auf die Dinge. Die Daten
müssen schließlich auch aufbereitet und entsprechend verteilt und wieder
zusammengefasst werden, das macht dann im Zweifelsfall einen wesentlich
größeren Aufwand als der Algo an sich. Das wird schon innerhalb eine
FPGA lustig, bei mehreren FÜGA noch viel spannender.
Mit C# bist du erst mal an der untersten Stufe angekommen, was man
geschwindigkeitsmäßig am PC machen kann. Langsamer ist ja nur noch
Python usw. Wenn du das erst mal in C++ mit Teilen in ASM wie oben
beschrieben umgesetzt hast, dann schau mal weiter. Und auf der GPU
rechnen ist auch kein allseligmachendes Mittel. Die Daten wollen auch da
erst mal hin geschaufelt werden, und das ist immer der Flaschenhals.
Für einen Anfänger ist das Projekt einige Nummern zu groß. Sowas macht
man als erfahrener FPGA Designer auch nicht mal eben nebenbei.
Wie gesagt, ohne den Algorithmus zu kennen kann man zu deinem Wunsch
keine Aussage machen. Ich wünsch dir schon jetzt viel Spaß als FPGA
Neuling mit DDRx-RAM Speicher zu begnügen. Auch wenn es hier schon
fertige IPs gibt, die auf den meisten Evalboards vernünftig laufen, so
hast du immer noch das Datenhandling. Und wenn du sprichst, dass du
mehrere (>8? Einheiten) umsetzen willst, und dann womöglich noch auf nur
ein Speicherinterface zugreifen kannst, dann wird hier ganz schön
sportlich. Im PC bekommst du von dieser Arbeit nicht wirklich viel mit,
außer das deine fps in den Keller geht.
Versuch mal grob deinen Algorithmus darzustellen, dann kann man neben
den Logikblöcken auch erstmal den wichtigeren Faktor - Speicher -
analysieren. Außer dein Algorithmus läuft in einem z. B. 3x3 Kernel,
alles on the fly, so dass man nur 3 Zeilen bräuchte, dann wärs einfach,
aber davon gehe ich jetzt mal nicht aus.
FPGAs ist kein PC, wo man einfach mal so sein "Programm" reinhackt und
schaut ob's richtige rauskommt. Das Debuggen und alles ist viel
schwieriger und und und.
Aber laß dich nicht abbringen, ich wünsche dir schon jetzt viel Spaß
dabei ;-)
Christian R. schrieb:> Mit C# bist du erst mal an der untersten Stufe angekommen, was man> geschwindigkeitsmäßig am PC machen kann.
Das würde ich nicht wirklich sagen. Hier ist mal ein Vergleich von C#
und C++
http://www.codeproject.com/Articles/212856/Head-to-head-benchmark-Csharp-vs-NET
C++ ist da nur an einigen Stellen um einen Faktor von 2-3 schneller, als
C#. Und für einen Faktor 2 brauche ich nicht einmal mit der Optimierung
anzufangen.
Christian R. schrieb:> Für einen Anfänger ist das Projekt einige Nummern zu groß. Sowas macht> man als erfahrener FPGA Designer auch nicht mal eben nebenbei.
Es soll ja auch nicht im Nebenbei passieren. kA, vielleicht stelle ich
es mir nur zu einfach vor. Das Knight-Rider Lauflicht hatte ich während
meines Studiums jedenfalls ganz schnell fertig.
Zoe schrieb:> Versuch mal grob deinen Algorithmus darzustellen, dann kann man neben> den Logikblöcken auch erstmal den wichtigeren Faktor - Speicher -> analysieren.
Ich habe gerade versucht, den Algorithmus mal eben kurz zusammen zu
fassen. Aber wenn ich sage, dass ich einen Kantendetektor auf ein
Farbbild in voller Auflösung loslasse, dann kann man ihn auch auf
verschiedenste Arten implementieren. Und nur den Kantendetektor grob
darzustellen, würde den Rahmen hier total sprengen. Und würde imho eher
darauf hinauslaufen, dass ich mit einem Farbbild arbeite und nicht mit
einem Graustufen-Bild und dass ich es doch mal kleiner machen soll.
Ich brauche für ein Bild rund 600MB Speicher. Und wenn ich davon
ausgehe, dass rund 10 Bilder in der Pipe gleichzeitig sind, dann brauche
ich ca. 6-8GB.
Aber ist es wirklich so ein Problem zu sagen, dass ich aus dem Speicher
gerne die Bits haben möchte, die an Stelle xyz anfangen und die nächsten
2 MB?
Gregor schrieb:> Aber ist es wirklich so ein Problem zu sagen, dass ich aus dem Speicher> gerne die Bits haben möchte, die an Stelle xyz anfangen und die nächsten> 2 MB?
Für den PC nicht, für den FPGA aber schon. Denn die müssen dann in
kleinen Stücken aus dem externen DDRx RAM geholt werden. Noch bezahlbare
(<2k€) FPGAs haben ein paar wenige MB internen Block RAM, der auch
entsprechend schnell arbeiten kann. Alles andere muss durch das externe
Speicherinterface. Klar, bei großen FPGAs gibts davon auch mehrere, aber
trotzdem bleibt der Speicher der Flaschenhals.
Wahlfreier Zugriff auf riesige Datenmengen ist etwas, was mit FPGAs
nicht optimal machbar ist, (paralleles) Streaming von hohen Datenraten
dagegen geht viel besser als mit einem PC.
6-8 DDR3-RAM mit 1Gbit Tiefe => sei mir nicht böse, aber vergiss dein
vorhaben das mit einem FPGA zu implementieren. Konzentrier dich hier
lieber auf eine effektive Grafikkartenlösung.
Wenn du es trotzdem mit einem FPGA machen willst, dann freu ich mich
schon auf die Ergebnisse, die wir in ca. 1,5 Jahren erhalten werden
(vorrausgesetzt du hast Zugriff auf eine fertige Hardware!)
> Wir haben auf der Arbeit einen recht günstigen (~5k€)> von Altera gekauft, 1 Mannjahr Entwicklungszeit von 2 FPGA-Spezialisten> und das Ding rennt wie der Teufel
Wieso brauchst Du noch ein Mannjahr um einen E-Stack zu bedienen?
Und 1GB ist nicht "Teufel" sondern 10% vom Stand der Technik.
> Ich brauche für ein Bild rund 600MB Speicher. Und wenn ich davon> ausgehe, dass rund 10 Bilder in der Pipe gleichzeitig sind, dann> brauche ich ca. 6-8GB.
Du scheinst viel auf dem RAM rumzurechnen. Das was da parallel läuft
muss also regelmässig aufs RAM raus. Das kann im FPGA kaum schneller
gehen, es sei denn Du baust Deinen Algo so, dass er parallele RAMs
verwendet.
Bei der BV wird übrigens in erster Line mit pipes gearbeitet.
Kantenerkennung machen wir in allen Lagen mit einem Speicher von weniger
als einem Drittel Bild als Puffer. Im Extremfall sind insgesamt weniger,
als 2ms Bild im FPGA und/oder dem RAM unterwegs. Der Rest hängt im
Blockram und den Registerzellen. Das muss auch so sein, weil die Daten,
die reingehen, auch raus müssen. Wozu also mehrere Bilder speichern?
Einen Doppelbildspeicher + Puffer habe ich nur gebraucht, wenn ich
Bilder komprimieren, drehen oder wegen Datenverlustrisiken bei der
Übertragung vorhalten musste.
Machst Du das in Echtzeit mit Bildfolgen oder offline mit nur einem
Bild?
Die 8 GB DDR-RAM sind kein Problem, wenn man genug FPGAs parallel hat.
Statt einem fetten Virtex reichen da auch 4 kleine Spartane mit jeweils
2 Chips am Controller. Ist billiger und performanter. 4 sind es wegen
der 4 Farben bei jeweils alternierenden Pixeln in unterschiedliche RAMs
+ Schatten-RAMs, um in jedem der 4 DDR-RAMs Zugriff auf jeweils alle
Nachbarpixel einer Farbe zu haben. Insgesamt laufen 4 Farben mit 120 Hz
Bildfrequenz bei 1024x1024 pixel ein.
Wenn der TE aber noch keine Bildverarbeitung im FPGA gemacht hat, kriegt
er auch nach 1,5 Jahren nichts hin. Bei solchen Designs verrennen sich
viele Anfänger gerne.
Gregor schrieb:> Ich brauche für ein Bild rund 600MB Speicher.> Und wenn ich davon ausgehe, dass rund 10 Bilder in der Pipe> gleichzeitig sind, dann brauche ich ca. 6-8GB.
und
> ich habe einen Algorithmus für eine relativ effiziente Objekterkennung> bzw. Szenario-Analyse entwickelt.
Effizient in welcher Hinsicht?
Rechenleistung wars ja schonmal nicht und Speicherbedarf/Bandbreite
kanns eigentlich auch nicht sein ;-P ;-)
Überleg Dir erstmal was Du überhaupt wirklich für eine Datenrate
brauchst.
Müssen die 600MByte für jeden Frame tatsächlich vollständig in den
Speicher geschrieben und gelesen werden? D.h. also bei 30fps ca. 36
GByte/s effektive Bandbreite?
Dem was Bildverarbeiter geschrieben hat stimme ich zu: Für FPGAs
solltest Du den Algo möglichst umstrukturieren um die Speicherzugriffe
zu reduzieren (ist auch für den PC nicht verkehrt ;-) ).
Beim FPGA musst Du einige Teilergebnisse evtl. gar nicht in den externen
Speicher schreiben sondern kannst die einfach direkt zur nächsten Stufe
weiterschicken ohne diesen Umweg.
Das würde die Sache entspannen.
Der FPGA kann ganz andere Sachen als eine CPU, deshalb muss man die
Algorithmusen an FPGA Strukturen optimieren. Das ist, wo liegt ein Draht
zwischen den Gattern. Egal welche Programmiersprache du benutzt.
Und jeder Draht kann zu Signalfluß beitragen.
Die Daten im Draht haben auch eine zeitliche Gültigkeit, weil im
nächsten Takt bereits ein neuer Wert anliegen kann.
Du schreibst eben wie ein Wilder im RAM rum. Dann ist der Wert im RAM
auch der gültige Wert.
Man muss für die FPGA Programmierung eine andere Vorstellung bekommen.
Das dauer ca. 1Jahr.
Eine reine Portierung eines C(#,++) ist nicht der erwartet Erfolg, es
sind schon mehrere Versuche in der Richtung unternommen. Es gibt einfach
keine Software zu Hardware Translation.
Ich habe so was auch mal vorgehabt. Letztendlich hate auch ich auch
keine sinnvolle/preiswerte/zufriedenstellende Hardware gefunden.
Nach dem ich mehrere Algorithmen im FPGA geschrieben habe, z.B. JPEG
Decoder, habe ich eine CPU auf dem FPGA vermisst.
Das können ganz einfach Sachen/Problem in der zulösenden Aufgabe sein,
wie z.B. ein Initialisierung eines Sensors. Dabei die Kalibrierwerte aus
dem Sensor EPROM auslesen und mit einer Korrekturformel vom Hersteller
umrechnen. Bei einem Mikrocontroller ist das kein Problem. Dagegen bei
einem FPGA ist das so einfach nicht möglich.
Deshalbe habe ich mir eine CPU in VHDL geschrieben.
http://www.dossmatik.de/mais-cpu.html
Sicher kann man die auch mehrfach in ein FPGA einbinden.
Der Geschwindigkeitsvoteil im FPGA kommt erst duch die
"Hardwaroptimierung" zum tragen. Eine effektive Möglichkeit ist das
"Pipelining". Ebenfall in der Mais-CPU verwendet.
Gregor schrieb:> Diesen Algorithmus halte ich für effizienter als andere Algorithmen, da> er komplett parallelisiert ist
Bildverarbeitungsalgorithmen sind i.d.R. einfach parallelisierbar. Im
Zweifelsfall verarbeitet man halt mehrere Bilder parallel.
> Der geschriebene Code ist momentan so halbwegs optimiert, deshalb sehe> ich keine weitere Möglichkeit mehr, einen Geschwindigkeitsgewinn zu> erreichen.
Vor einer vernünftigen CPU-Implementierung überhaupt eine
FPGA-Implementierung in Erwägung zu ziehen macht keinen Sinn. Ist der
Algorithmus einfach so in plain C# runtergeschrieben? Dann besteht da
noch ein riesiges Optimierungspotential durch Vektorisierung. Dafür
schreibt man heutzutage kein Assembler mehr, sondern verwendet eine
Bibliothek wie Intel IPP, und nutzt damit automatisch alle Features
moderner CPUs (AVX).
Grendel schrieb:> Effizient in welcher Hinsicht?
Effizient in der Erkennungsgeschwindigkeit. Also wie lange es dauert,
bis ein auftauchendes (Teil-)Objekt erkannt wurde.
Grendel schrieb:> Müssen die 600MByte für jeden Frame tatsächlich vollständig in den> Speicher geschrieben und gelesen werden? D.h. also bei 30fps ca. 36> GByte/s effektive Bandbreite?
Eine tatsächliche effektive Bandbreite anzugeben, ist da leider nicht
ohne Weiteres möglich. Es kommt eben auf die Bilder an, die die Kamera
liefert. Wenn jetzt vor der Kamera nichts passiert, dann brauche ich
keine 600MB pro Bild, sondern ca. 20MB und kann zwischendurch auch mal
Frames rauswerfen. (Wenn ich Frame 1 einer Sekunde nichts passiert ist,
im Frame 15 auch nichts und im Frame 30 ebensowenig, dann ist die
Wahrscheinlichkeit, dass in den dazwischen liegenden Frames nichts
passiert ist, relativ groß.)
Wenn jetzt aber etwas passiert, dann brauche ich tatsächlich die rund
600MByte. Allerdings auch keine 30fps, sondern 10.
René D. schrieb:> Man muss für die FPGA Programmierung eine andere Vorstellung bekommen.> Das dauer ca. 1Jahr.> Eine reine Portierung eines C(#,++) ist nicht der erwartet Erfolg, es> sind schon mehrere Versuche in der Richtung unternommen. Es gibt einfach> keine Software zu Hardware Translation.
Kannst du das bitte etwas ausführen? Denn momentan gehe ich davon aus,
dass ich jeden Algorithmus auch in TTL umsetzen kann. Während meines
Studiums musste ich CRC mit TTL nachbilden (in einer
Simulationssoftware). Das war die erste Aufgabe nach dem Spielen mit
LEDs. Und zum Schluss des Praktikums haben wir AES umgesetzt, einen
Block verschlüsselt und wieder entschlüsselt. In TTL, FFS und
Schieberegistern.
Und ich finde, dass momentan so der richtige Zeitpunkt ist, um den Code
in Logik-Bausteinen nachzubauen.
Wie ich schon sagte, verstehe ich momentan nicht, wieso einige der
Meinung sind, dass die Umsetzung auf einem FPGA in Logik irgendwie etwas
komplexes sein sollte und wieso man ein Mannjahr braucht, um einen
IP-Core fürs Gigabit-Ethernet auf dem FPGA einzubinden, dass er nutzbar
ist. Die Hiwis bei uns am Fraunhofer haben nach wenigen Wochen schon
relativ schöne Sachen mit den Chips machen, inkl. Bildverarbeitung von
irgendwelchen realtime Daten (afaik über Firewire).
Ich glaube, ich werde es nur verstehen können, wenn ich mal in die
FPGA-Welt mal eintauche. Jetzt wäre nur mal die Frage nach einem
passenden Board, um mal in die Welt einzutauchen und etwas
herumzuspielen.
Gregor schrieb:> Effizient in der Erkennungsgeschwindigkeit. Also wie lange es dauert,> bis ein auftauchendes (Teil-)Objekt erkannt wurde.
Kannst Du das irgendwie quantitativ ausdrücken? Welche Übereinstimmung
führt zu wieviel Bedarf an Zeit?
Gregor schrieb:> Wie ich schon sagte, verstehe ich momentan nicht, wieso einige der> Meinung sind, dass die Umsetzung auf einem FPGA in Logik irgendwie etwas> komplexes sein sollte und wieso man ein Mannjahr braucht
Diese Aussage war jetzt aber wirklich gut.
Es geht nicht ausschließlich darum, ob ein Algorithmus umgesetzt
werden kann, sondern wie er das kann und wie effizient...
> Die Hiwis bei uns am Fraunhofer haben nach wenigen Wochen schon relativ> schöne Sachen mit den Chips machen, inkl. Bildverarbeitung von> irgendwelchen realtime Daten (afaik über Firewire).
Ist dir bewusst, dass solche Institute hochwertige Lizenzen oft einfach
so zum "Herumspielen" nachgeworfen bekommen?
> Ich glaube, ich werde es nur verstehen können, wenn ich mal in die> FPGA-Welt mal eintauche.
Das glaube ich auch.
> Jetzt wäre nur mal die Frage nach einem passenden Board, um mal in die> Welt einzutauchen und etwas herumzuspielen.
Kauf irgendeines, das dir gerade so gefällt (das muss nicht gleich DDR3
drauf haben) und fang damit an. Wenn du nach ein paar Monaten siehst,
dass es "zu klein" ist, kannst du es ohne nennsweten Wertverlust wieder
verkaufen.
Von 0 auf 100 in einem Jahr ist noch optimistisch geschätzt!
Ich mache schon ein Paar Jahre Bildverarbeitung im FPGA und kann Dir
sagen, dass sogar so einfache Sachen, wie Kantenerkennung nicht ohne
sind! Es reicht lange noch nicht, zu wissen, wie das theoretisch
funktioniert und welche Algos es da gibt. Viel mehr, muss man das Gefühl
bekommen, wie das im FPGA repräsentiert wird und was machbar oder auch
nicht ist. Die Aufgabenstellung: gehe alle Pixel im Bild durch und suche
das Maximum kann einem schon das Genick brechen. Wenn das Bild ins
Onchip Ram passt -- ist alles in Ordnung, wenn aber nicht, dann gute
Nacht.
Ich würde Dir empfehlen Deinen Algo in kleinere Promlemstellungen zu
brechen. Was ist wovon abhängig, muss man Zeilenweise lesen? Kann man
die Zeile verwerfen, die prozessiert wurde oder braucht man diese für
den nächsten Schritt... und und und...
Besorge Dir ein einfaches Board und implementiere etwas ganz ganz
einfaches! Mit der Zeit wirst Du das Gefühl dafür bekommen, wie ein FPGA
"funktioniert".
Grüße
Kest
Hallo Gregor,
an deiner Stelle würde ich erst damit beginnen deinen Algorithmus in
eine Hardwarebeschreibungssprache (VHDL/Verilog) zu übertragen. Das
kannst du beispielsweise mit dem Xilinx Web-Pack oder den Altera Tools
machen. Diese gibt in der Grundausführung meist umsonst.
Wenn du dein Design übertragen und entsprechend Simuliert hast, dann
kannst du dein Design durch die Synthese für den FPGA übersetzen. Im
Synthesetool kannst du bereits mehrere gängige Eval-Boards einstellen
(zumindest bei den Xilinx Tools). So kannst du herausfinden, auf welchen
FPGA-Typ dein Design passt, ohne dir schon ein Eval-Board kaufen zu
müssen.
HTI schrieb:> Kannst Du das irgendwie quantitativ ausdrücken? Welche Übereinstimmung> führt zu wieviel Bedarf an Zeit?
Eine Testanwendung hängt gerade bei mir am Haus und schaut auf die
Grundstücksgrenze und die Einfahrt. Je nachdem, wieviel Auto im ersten
analysiertem Frame zu sehen ist, brauche ich ab da momentan 100-130ms um
zu erkennen, dass es ein Auto ist. Dass es ein bestimmtes, gelerntes
Auto ist, den erwarteten Fahrtweg zu analysieren (das Auto will
tatsächlich reinfahren und nicht nur irgendwo in der Nähe halten) und
das Kennzeichen zu prüfen. Nach 100-130ms geht das Signal an den
Tor-Öffner.
Zweites Beispiel:
Jemand läuft am Zaun entlang und greift oder steigt über den Zaun. Da
bin ich momentan bei ca. 80ms Reaktionszeit.
Vor allem sind die Zeiten und Erkennungsraten stabil und brechen nicht
zusammen, wenn ein Vogel vorbeifliegt oder ein Insekt oder Spinne sich
auf das Glas der Kamera setzt.
> René D. schrieb:>> Man muss für die FPGA Programmierung eine andere Vorstellung bekommen.>> Das dauer ca. 1Jahr.>> Eine reine Portierung eines C(#,++) ist nicht der erwartet Erfolg, es>> sind schon mehrere Versuche in der Richtung unternommen. Es gibt einfach>> keine Software zu Hardware Translation.>> Kannst du das bitte etwas ausführen?
Solange du noch halbwegs ein Zusammenhang zwischen den Ein- und
Ausgängen besteht, hat man schnell eine Idee für ein Fehlerbild. Deshalb
sind auch deine ersten Schritte in kurzer Zeit von Erfolg.
Wenn du in einem größeren Softwareprojekt ein Problem hast, dann nimmst
du die Verfolgung mit dem Debugger auf. So ein Tool zum Aufschalten gibt
es nicht im FPGA. Dann fängt man an einen Draht aus der Mitte
herauszuhäckeln und dann hast du ein bit Debuginformation.
Auch deine Statemachine wirst du in mehrere Kleinere zerhacken müssen.
Und die werden sich verhaken, weil es Dummerweise wieder ein
unbetrachteten Zustand gibt, den man aber gerade ausgeschlossen hat.
Wie verwaltet man größer Projekt. Das musst du alles lernen.
Und so mal googln nach Code ist auch meist ohne Erfolg.
Was ist denn mit dem Parallella von Adapteva?
Waere das nicht mal einen Blick wert?
Habe gerade den link nicht parat, findet sich aber leicht bei Google
oder Youtube.
Mark
René D. schrieb:> Wenn du in einem größeren Softwareprojekt ein Problem hast, dann nimmst> du die Verfolgung mit dem Debugger auf.
Im Simulator geht das mit VHDL auch, allerdings sind die Wege weiter, da
neben Abläufen ja auch die funktionellen Strukturen des (eigenen!) Codes
nachvollzogen werden müssen.
> So ein Tool zum Aufschalten gibt es nicht im FPGA.
Nun ja, für die algorithmische Ebene und die SW täte es ja der Simulator
und für lolevel der Signalanalyzer. Du hast aber Recht: Das ist ein
zunehmender Punkt im FPGA Bereich. Wo wir hinkommen müssen und was
vielleicht ein Ansatzpunkt für Softcoreentwickler ;-) wäre, ist in
meinen Augen ein System, das die SW-Abläufe stärker abstrahiert
realisiert und sie damit auf den SW-Plattformen testbar macht,
gleichzeitig aber einen Block bereitstellt, der in das FPGA
synthetisiert wird, um es real zu Testen. Die Testmuster müssen quasi
INNEN im FPGA erzeugt werden. Bislang kann man das effektiv nur von
Aussen durch Anlegen von Testmustermengen an den Eingängen oder durch
passives Beobachten der Schaltung per LA vollziehen.
Alles andere an Testsystemen muss derzeit per Hand eingebaut werden. Nun
ist das freilich nicht so, dass das nicht ginge. Im Gegenteil: Man kann
zu dem operational code auch noch test code implementieren und es gibt
sogar Vorlesungen zu dem Thema. Da ist Vieles möglich. Allerdings ist
das nicht so weit verbreitet und oft wird die Notwedigkeit vom
Autraggeber nicht gesehen.
