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.
Alternativ: OpenCL oder CUDA und das ganze auf der Grafikkarte parallelisieren
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.
:
Bearbeitet durch User
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!)
natürlich sollte es nicht 1Gbit sondern 8Gbit DDR Speicher sein.
> 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).
:
Bearbeitet durch Admin
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.
Anfangen kannst du im Simulator. Das sollte auch bei einem Design, das in Hardware laufen soll, der erste Schritt sein.
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.
:
Bearbeitet durch User
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.