Kann ein Spartan-3A / AN / E eine Kantenerkennung für eine 5MP-Kamera implementieren

Ich denke darüber nach, mich für ein FPGA-Starterkit zu entscheiden, ich habe die Xilinx-Website durchsucht und festgestellt, dass die Spartan 3-Serie recht sparsam ist - Spartan3AN, Spartan3A und Spartan3E. Das Spartan 3AN scheint ein neues Board zu sein.

Kann das Spartan FPGA die Verarbeitung einer 5-MegaPixel-Kamera verarbeiten, die Schnittstelle wären 8-Bit-Paralleldaten in Roh-RGB und eine Kantenerkennung 15 Mal pro Sekunde?

Könnte etwas Arbeit erfordern, aber ja, sollte funktionieren.
@Kellenjb: Hat es nicht genügend Gates, um den Algorithmus zu erstellen? Was ist das eigentliche Problem, um es bei einem Spartaner zum Laufen zu bringen?
@ Kevin Boyd - Das hängt von Ihrem Algorithmus ab.
Grundsätzlich ist diese Frage nicht zu beantworten. VIEL mehr Details sind erforderlich. Grundsätzlich ist es nicht möglich, eine abschließende Antwort zu geben, bis Sie den Kantenerkennungsalgorithmus tatsächlich geschrieben haben. Nur so können Sie bestimmen, wie viele Logikelemente Sie für Ihr Design benötigen und wie groß Ihr FPGA daher sein muss.
Es kann möglich sein, eine Schätzung vorzunehmen, aber dafür müssten wir mehr darüber wissen, was Sie tun. Es gibt viele Kantenerkennungsalgorithmen (Canny, Sobel usw.). Auch Umweltaspekte kommen in Betracht. Wie viel Vorverarbeitung ist erforderlich? Haben Sie die vollständige Kontrolle über die Beleuchtung oder stecken Sie mit der Umgebungsbeleuchtung fest? Wie gut ist Ihr Programmierer? Sie können den Mist aus Ihrem Layout und VHDL/Verilog optimieren, aber es braucht jemanden mit etwas Geschick, um dies zu tun.
Benötigen Sie außerdem wirklich die 5 mpix? In vielen industriellen CV-Anwendungen erfolgt die eigentliche Verarbeitung auf stark herunterskalierten (~200x200 px Bilder) Bildern, da mehr Präzision einfach nicht erforderlich ist. Jetzt viel Präzision brauchen Sie? Außerdem werden die Bilddaten vor der Verarbeitung auf mindestens Graustufen und wahrscheinlich auf reines Schwarzweiß (möglicherweise mit einem adaptiven Schwellenwert) reduziert. Machen Sie also etwas Cleveres mit Farbe, was eine RGB-Kamera erfordert, oder würde eine Graustufenkamera, vielleicht mit einem Farbfilter auf dem Objektiv, funktionieren?
en.wikipedia.org/wiki/Edge_detection ist ein guter Ausgangspunkt, um zu verstehen, wie dieses Zeug funktioniert
@Kevin Sie sollten Ihre Meinung dazu abgeben, was Fake Name erwähnt hat. Ich glaube nicht, dass Sie eine gute Antwort erhalten werden, ohne seine Punkte anzusprechen. Weil Sie seine Punkte nicht angesprochen hatten, habe ich mich so vage geäußert.
@Fake Name: Im Moment brauche ich das 5mp-Pix. Möglicherweise wäre es im Moment der beste Weg, den gesamten Prozess in VHDL/Verilog zu simulieren und zu sehen, wie viele Logikblöcke ich benötigen würde. Danke für die Kommentare.
xilinx.com/support/documentation/application_notes/xapp462.pdf sagt, dass der i/p-Frequenzbereich zum Frequenzsynthesizer 1 bis 280 MHz beträgt und der maximale Frequenzbereich 280 * 32/1 = 8960 MHz beträgt. Selbst wenn der Takt 50 MHz beträgt, sollte ich eine Ausgabe von 50 * 32 = 1600 MHz erhalten. Verstehe ich diese Zahlen also falsch?

Antworten (2)

In Bezug auf die Schnittstelle zur Kamera und das Eintakten von Daten ist das in Ordnung, es kann damit umgehen. Es kann möglicherweise nicht mit den Geschwindigkeiten umgehen, an denen Sie interessiert sind.

5 MP * 3 (Farben, RGB) * 15 (mal pro Sekunde) = 225 * e6. (bei 24 Bit Farbtiefe)

Das bedeutet, dass Sie eine Taktrate von mindestens 225 MHz benötigen, vorausgesetzt, Sie können Daten auf jedem Taktsignal verschieben, was je nach Sensor möglicherweise nicht der Fall ist. Daher müssen Sie diese Zahl möglicherweise auf ca. 450-500 MHz verdoppeln

Der Spartan, den Sie betrachten, hat ein Taktsignal von 50 MHz.

Die kurze Antwort lautet also nein, nicht bei diesen Geschwindigkeiten.

Die andere Überlegung, die Sie anwenden müssen, ist, wie viele Logikblöcke Ihre Logik benötigt. Um dies herauszufinden, schreiben Sie Ihre Implementierung in VHDL/Verilog, simulieren und dann synthetisieren. Lesen Sie die Ausgaben des Tools und es wird Ihnen sagen, wie viele Logikblöcke Sie benötigen, und wählen Sie dann ein geeignetes FPGA aus, das 50 % mehr Logikblöcke hat, um unbrauchbare Blöcke aufgrund von Routing-Einschränkungen zu ermöglichen, und Ihnen etwas Raum zum Wachsen gibt.

Außerdem müssen Sie RAM oder eine andere Art von Speicher berücksichtigen und wie Sie diese Bursts speichern. Wenn Sie 1 Sekunde lang mit 15 fps aufnehmen, benötigen Sie 225 MB, was viel RAM für ein eingebettetes System ist.

Nach dem Speichern im RAM müssen Sie in irgendeiner Form in das ROM spülen (z. B. Compact Flash).

50-MHz-Oszillator - die PLLs können das FPGA viel höher bringen. Und der 3A Starter wird mit einem 133-MHz-Oszillator geliefert, um seine DDR2-Ports zu speisen. Es könnte also die E / A übernehmen, hängt jedoch von mehr Designaspekten ab. Je nach Algorithmus kann der 3A-DSP besser abschneiden.
Sie haben Recht mit der PLL und sie schneller laufen zu lassen, das wird möglich sein. Es ist jedoch möglicherweise immer noch nicht schnell genug für die zu übertragende Datenmenge, außerdem verfügt das Gerät nicht über genügend integrierten RAM, weniger als 2 MB, und das Entwicklungskit unterstützt 64 MB, was nicht ausreicht.
Wir sind also wieder bei hängt vom Algorithmus ab. Ein Kantenerkennungsalgorithmus könnte möglicherweise mit nur wenigen Abtastzeilen Speicher davonkommen, aber das setzt voraus, dass er die Daten auch mit sehr geringer Verzögerung ausgibt. Kevin Boyd hat weder angegeben, dass eine Aufzeichnung notwendig ist, noch irgendwelche zusätzlichen Details. Ich denke, immer noch nicht genug Informationen.
Nein, wir sind nicht vom Algorithmus abhängig. Dieses Demoboard hat nicht genug RAM, um Bilder wirklich lange speichern zu können, maximal vier Frames, was 375 ms entspricht. Ohne zu überlegen, ob die Kantenerkennung passt, ist das Demoboard nicht geeignet.
@smashtastic: Mit Ihren Berechnungen scheint die Geschwindigkeit des Spartan3a für die 5MP @ 15fps nicht ausreichend zu sein. Kann der Spartan3A DSP die Arbeit erledigen (wie von LoneTech vorgeschlagen)? Wenn 15 fps nicht machbar sind, ist es möglich, 5 fps vom Spartan3A zu bekommen? In Bezug auf den Arbeitsspeicher Wenn die Demo nicht geeignet ist, kann der Spartan3A-FPGA mit> 50 MHz ausgeführt werden, wenn ich meinen eigenen Prototyp mache, und kann er mit beispielsweise 1 GB externem Arbeitsspeicher verbunden werden?
In Bezug auf den Arbeitsspeicher Wenn die Demo nicht geeignet ist, kann der Spartan3A-FPGA mit> 50 MHz ausgeführt werden, wenn ich meinen eigenen Prototyp mache, und kann er mit beispielsweise 1 GB externem Arbeitsspeicher verbunden werden?
Kann der Spartan3A extern @100MHz getaktet werden, damit die interne PLL dann höhere Frequenzen erzeugen kann oder sind wir auf 133MHz begrenzt.
Er kann extern höher getaktet werden und ist auch nicht auf 133MHz begrenzt - genau das nutzt der zweite externe Oszillator auf dem 3A Starter Board. Grenzen hängen von der logischen Komplexität ab, aber Pipelining kann sie ziemlich weit nach oben treiben. Die eigentliche Frage ist immer noch, was mit den Daten nach dem Lesen zu tun ist. Sie können sicherlich eine Verbindung zu beliebig viel RAM herstellen, aber irgendwann möchten Sie die Daten irgendwo verwenden.
Denken Sie daran, dass Sie auch einen SDRAM/SDR/DDR/DDR2-Controller in das FPGA einbauen müssen ...
Kevin, können Sie Ihre Anforderungen klarer darstellen, insbesondere wie lange Sie Bursts mit 15 fps aufnehmen möchten, welche Verarbeitung Sie gegebenenfalls auf dem FPGA durchführen möchten und was Ihr nichtflüchtiger Speicher ist.
@Smashtastic: Folgendes habe ich in letzter Zeit gedacht. Anstatt alles in Echtzeit zu machen, würde ich 5MP @ 15fps für etwa 15 Sekunden erwerben, die Daten in den RAM puffern und die gepufferten Daten gleichzeitig in eine MMC oder einen Flash-Speicher eintauchen, wenn man bedenkt, dass die MMC langsamer ist. Wenn ich Daten direkt von der Kamera nehmen und in den Blitz leiten könnte, wäre das wunderbar. Ich frage mich jedoch, ob MMC oder eine andere Flash-Technologie diese Datenraten erreichen kann? Nach der Erfassung der Frames kann ich dann die Bildbearbeitung durchführen und ggf. erneut aufnehmen.

Wir wissen einfach (noch) nicht genug aus der Frage und den Kommentaren. Intern könnte ein Chip der Spartan 3-Familie wahrscheinlich die Kantenerkennung übernehmen, aber das Lesen des Bildsensors mit dieser Geschwindigkeit ist eher eine offene Frage - es hängt mehr von der Sensorschnittstelle und dem Platinenlayout ab. Dann stellt sich die Frage, was mit all den Daten zu tun ist - es ist machbar, sie einfach wieder auszuspeisen, möglicherweise über breitere Verbindungen, aber das FPGA selbst kann sie sicherlich nicht speichern.

Leider wird diese Frage immer mehr zu einer Diskussion, für die diese Seite nicht gedacht ist. Wir müssen immer wieder graben, um die neuen Kommentare zu finden. Um eine nachweislich richtige Antwort zu geben, müssten wir die Hälfte der Designarbeit leisten – bis hin zur Komponentenauswahl und dem Datenfluss des Algorithmus.

Ist etwas falsch daran, in diesem Forum zu diskutieren? Ich verstehe, dass die Absicht darin besteht, Fragen und Antworten zu haben, um mehr Benutzer und Verkehr anzuziehen, aber die Diskussion der technischen Details hilft dem OP immer noch, seine Lösung zu erarbeiten. Ich bin sicher, wenn das OP alle zusätzlichen Fragen beantworten könnte, würden sie in diesem Forum nichts fragen, da die Antwort im Designprozess herausgekommen wäre. nur ein paar gedanken....
An Diskussionen an sich ist nichts auszusetzen - nur das Layout ist nicht sehr gut darin. Es scheint Pläne zu geben, die Funktion (Chat-Funktion unter Reputation) hinzuzufügen, aber sie ist noch nicht fertig. Ich hätte es verlinkt, aber es scheint in der Closed Beta zu sein. electronic.stackexchange.com/privileges/chat-rooms