Hallo, ich versuche mich in stereo vision verarbeitung mit low-cost FPGAs einzuarbeiten. Da meine ich bisher nur mit mikrocontrollern/embedded PCs gearbeitet habe, stellen sich mir einige grundlegende Fragen: Für die Einbindung der cameras würde ich gerne die MIPI CSI-2 Schnittstelle verwenden. Bei der Suche nach FPGAs habe ich keine physikalische implementierung von CSI-2 on chip gefunden. Einige Anbieter bieten jedoch CSI-2 IP cores an. 1. Kann ich davon ausgehen, dass die IP-cores keine Informationen zur physikalischen Schnittstellen Implementierung beinhalten, da diese exklusive beim MIPI Konsortium "gekauft" werden müssen. 2. Gibt es einen FPGA logiksimulator, mit dem ein Kameradatenstream simuliert werden kann. 3. Habt ihr Erfahrungswerte bezüglich Größe/Umfang/DSP Blöcke im Falle, dass ich zwei HD Kameras mit mindestens 1280 × 720 Pixeln anbinden und die Disparity Matrix berechnen möchte. 4. Preis/Leistungstechnisch finde ich die IGLOO2 FPGAs from Microsemi interessant. Jedoch arbeiten die meisten meiner Bekannten mit ALTERA/XILINX. Hat jemand zu den Microsemi FGPAs Erfahrungswerte oder Empfehlungen für andere low-cost (<10€) FPGAs für solch ein Projekt. Vielen Dank schonmal im Voraus!
Nachdem was sich dort finden lässt: http://www.cypress.com/file/126136/download braucht CSI-2 bis zu 5 differentiale (LVDS?) lanes x1 Gigabit per second. Das ist ganz schön fix, das kann nicht jeder FPGA, eventuell brauchst du einen FPGA mit MGT (MulitGigabitTransceiver). IGLOO2 könnte diesbezüglich ab M2GL010 passen, allerdings haben Videoanwendung oft auch hohen bedarf an Speicher, beispielsweise um eine Line zu buffern oder einen größerenen Filterkernel. Mit dem on-board FPGA-Speicher kommt man nicht weit da braucht es ein schnelles Speicherinterface.
Jan D. schrieb: > Kann ich davon ausgehen, dass die IP-cores keine Informationen zur > physikalischen Schnittstellen Implementierung beinhalten, > da diese exklusive beim MIPI Konsortium "gekauft" werden müssen. MIPI ist m.W. keine freie Schnittstelle, daher gibt es dort keine Datenblätter (die vom Laster gefallenen mal ausgenommen). Das heißt auch, dass du dir einen fertigen Core kaufen musst. Jan D. schrieb: > Gibt es einen FPGA logiksimulator, mit dem ein Kameradatenstream > simuliert werden kann. Jeder VHDL- oder Verilog-Simulator kann das. Du musst nur einen Kameradatenstrom zum Einfüttern haben, natürlich nicht live. Zum Rest kann ich nichts sagen.
Jan D. schrieb: > Habt ihr Erfahrungswerte bezüglich Größe/Umfang/DSP Blöcke im Falle, > dass ich zwei HD Kameras mit mindestens 1280 × 720 Pixeln anbinden > und die Disparity Matrix berechnen möchte. Mit ein bißchen suchen findet sich dieses IGLOO2 Referenzdesign. Das sollte doch die ersten Fragen nach Ressourcenbedarf beantworten: https://www.microsemi.com/document-portal/doc_view/136292-ac460-building-mipi-csi-2-applications-using-smartfusion2-and-igloo2-fpgas-application-note
Moin, > ich versuche mich in stereo vision verarbeitung mit low-cost FPGAs > einzuarbeiten. Da meine ich bisher nur mit mikrocontrollern/embedded PCs > gearbeitet habe, stellen sich mir einige grundlegende Fragen: > > Für die Einbindung der cameras würde ich gerne die MIPI CSI-2 > Schnittstelle verwenden. Bei der Suche nach FPGAs habe ich keine > physikalische implementierung von CSI-2 on chip gefunden. > Einige Anbieter bieten jedoch CSI-2 IP cores an. > > 1. > Kann ich davon ausgehen, dass die IP-cores keine Informationen zur > physikalischen Schnittstellen Implementierung beinhalten, > da diese exklusive beim MIPI Konsortium "gekauft" werden müssen. Guck mal bei Lattice Semi. Da gibt's Referenzdesigns. Gekauft werden muss bei mipi.org nicht zwingend, man muss das alberne Klüngelspielchen ja nicht mitmachen. Es ist schlussendlich nur LVDS. Schwieriger wird es teils bei der Ansteuerungen der Sensoren. Es ist aber nicht verboten, sich die Informationen "um die Ecke" zu besorgen oder aus alten non-mipi Datenblättern zu erraten. > > 2. > Gibt es einen FPGA logiksimulator, mit dem ein Kameradatenstream > simuliert werden kann. > Ich habe sowas auf GHDL-Basis, wo man per virtuellem Sensor (FIFO plus etwas Timing) PNGs reinfüttern kann. Da kannst du dann die MIPI-Bridge einklinken, allerdings nicht als Verilog. Wenn dir das was bringt und sich dein Arbeitgeber OpenSource-affin ist, melde dich, ansonsten macht es sicher auch Sinn, seinen eigenen Simulator zu schreiben. > 3. > Habt ihr Erfahrungswerte bezüglich Größe/Umfang/DSP Blöcke im Falle, > dass ich zwei HD Kameras mit mindestens 1280 × 720 Pixeln anbinden > und die Disparity Matrix berechnen möchte. > Das kommt ganz auf deinen Algorithmus an. Voraussetzung ist schon mal, dass die Kamerasensoren synchronisiert sind, oder die Puffer-Logic drangebaut ist, wie bei einer Lösung von Lattice. Hast du bereits eine SW-Implementierung? Der Knackpunkt ist ob RAM oder nicht RAM, und was für RAM. Das kostet u.U. erheblich Zusatzaufwand oder du musst Core IP zukaufen. Bevor du nicht schon auf einem Kit eine Referenzanwendung laufen hast, ist das ein gehöriges von 0 auf 100-Ding. Wieviel Zeit hast du? Ist das überhaupt "Forschung"? > 4. > Preis/Leistungstechnisch finde ich die IGLOO2 FPGAs from Microsemi > interessant. Jedoch arbeiten die meisten meiner Bekannten mit > ALTERA/XILINX. Hat jemand zu den Microsemi FGPAs Erfahrungswerte > oder Empfehlungen für andere low-cost (<10€) FPGAs für solch ein > Projekt. > Deine Anwendung beisst sich irgendwie mit low cost... Du hast schon mal das Problem, dass du schnelle I/Os und DSP slices (da siehts bei den MachXO* mau aus) als Minimalanforderung hast. Und die passenden Kits für stereo vision sind dünn gesäht. Warum Lattice bei der Auswahl oft vergessen geht, ist merkwürdig, die gelten zwar als "klein", aber haben IMHO, was low cost Vision-Interfacing geht, die Nase vorn.
Strubi schrieb: > Warum Lattice bei der Auswahl oft vergessen geht, ist merkwürdig, die > gelten zwar als "klein", aber haben IMHO, was low cost > Vision-Interfacing geht, die Nase vorn. Wie schaut es da eigentlich mit den aktuellen Versionen von Diamond aus, taugt das was im Vergleich zu Vivado/Quartus? Extrem schade finde ich, dass bei Lattice scheinbar weniger IP kostenlos mit dabei ist, da muss man ja sogar für DDR3 (was gerade für BV wichtig ist) schon min. nen Tausender zahlen wie es aussieht... ist das dann wenigstens keine zeitliche begrenzte Lizenz? Und wenn man die schnellen SerDes braucht, muss man sich jedes Jahr eine neue Lizenz für nen weiteren Tausender kaufen? Ist irgendwie unpraktisch (wenns nur einmalig wäre - OK). Ansonsten sehen die Steine von Lattice IMHO durchaus brauchbar aus.
Mac G. schrieb: > Strubi schrieb: >> Warum Lattice bei der Auswahl oft vergessen geht, ist merkwürdig, die >> gelten zwar als "klein", aber haben IMHO, was low cost >> Vision-Interfacing geht, die Nase vorn. > > Wie schaut es da eigentlich mit den aktuellen Versionen von Diamond aus, > taugt das was im Vergleich zu Vivado/Quartus? Leider sieht es da nicht so gut aus, seit Jahren immer wieder gemeldete Bugs v.a. unter Linux bleiben unbearbeitet und man muss sich drum herumarbeiten. Aber ähnlich wie bis etwa ISE v13, ab da wurde es ja deutlich besser (von isim abgesehen). Dafür ist Synplify wieder deutlich netter als xst. > Extrem schade finde ich, dass bei Lattice scheinbar weniger IP kostenlos > mit dabei ist, da muss man ja sogar für DDR3 (was gerade für BV wichtig > ist) schon min. nen Tausender zahlen wie es aussieht... ist das dann > wenigstens keine zeitliche begrenzte Lizenz? Weiss ich nicht. Ich denke, das kann man immer mengenmässig auch aushandeln. Ein Tausender ist jetzt aber nicht viel, wenn's denn funktioniert. Hatte mal vor Jahren nen DDR2-Core angetestet, der flog aus verschiedenen Gründen in die Ecke, das ging dann mit dem X-MIG besser. > Und wenn man die schnellen SerDes braucht, muss man sich jedes Jahr eine > neue Lizenz für nen weiteren Tausender kaufen? > Ist irgendwie unpraktisch (wenns nur einmalig wäre - OK). Ja, da fangen leider oft die Killerkriterien an, gerade wenn DDR2/3 ins Spiel kommt, landet dann im Produkt doch ein schöne Tochter einer anderen Mutter, weil der Teufel mal wieder im Detail liegt. Um mal schnell ein proof of concept hinzulegen, ist Lattice aber eine gute Wahl. Da die Technologien bei den hauseigenen ORCA-abkömmlingen immer irgendwie ähnlich zu Xilinx sind, tritt man da auch kaum wo in die Nesseln. > > Ansonsten sehen die Steine von Lattice IMHO durchaus brauchbar aus. Den ECP5 finde ich mal richtig gut. Da sind offenbar alle Leckerli von MachXO* und ECP3(4) gut verwurstet worden. Jetzt müssten sie nur noch mutiger sein, und das nervige Lizenzgetue, zumindest was kleine Bausteine angeht, über Bord werfen. Für 900 USD würde man bei einer fehlerhaften Software doch etwas mehr Support erwarten (wenn auch nur einen bruchteiligen Gegenwert, daran gemessen, dass offenbar vielen der outgesourcen First-Level-Supporter deutlich Fachwissen fehlt).
Mac G. schrieb: > Extrem schade finde ich, dass bei Lattice scheinbar weniger IP kostenlos > mit dabei ist, da muss man ja sogar für DDR3 (was gerade für BV wichtig > ist) schon min. nen Tausender zahlen wie es aussieht... ist das dann > wenigstens keine zeitliche begrenzte Lizenz? > Und wenn man die schnellen SerDes braucht, muss man sich jedes Jahr eine > neue Lizenz für nen weiteren Tausender kaufen? > Ist irgendwie unpraktisch (wenns nur einmalig wäre - OK). Im Moment gibt es die ECP5-5G Special Offer, das heißt die Diamond Software und die Connectivity IP (DDR3,Pcie usw.)für 99$. Es gibt da schonmal öfter bei Lattice solche Aktionen für 99$. Siehe http://www.latticesemi.com/Products/FPGAandCPLD/ECP5ECP5GPromotion.aspx
Danke Strubi für die Infos! Strubi schrieb: > Den ECP5 finde ich mal richtig gut. Da sind offenbar alle Leckerli von > MachXO* und ECP3(4) gut verwurstet worden. Jetzt müssten sie nur noch > mutiger sein, und das nervige Lizenzgetue, zumindest was kleine > Bausteine angeht, über Bord werfen. Die Lizenzpolitik dürfte Lattice auch Kunden kosten. Wenn eine Mini-Firma vor 5 Jahren nämlich mal auf Xilinx gesetzt hat weil die Software komplett kostenlos war und nun tausende Chips kaufen würde... @Bastler: Nett, Danke für die Info. Das wäre für den Preis eigentlich voll in Ordnung wenn der immer so wäre. Aber FPGA-Projekte laufen ja doch eher langfristig. Ein Jahr ist schnell rum und wenn dann gerade keine Aktion läuft... nun. Und auch wenn man dann mal in drei Jahren nur mal schnell zwei drei Kleinigkeiten ändern möchte...
Mac G. schrieb: > Die Lizenzpolitik dürfte Lattice auch Kunden kosten. Wenn eine > Mini-Firma vor 5 Jahren nämlich mal auf Xilinx gesetzt hat weil die > Software komplett kostenlos war und nun tausende Chips kaufen würde... Die SW ist ja kostenlos für die "kleinen" Käfer, man muss nur jedes Jahr eine neue Lizenz beantragen. Und sonst haben sie offenbar ihre Marktlücke, da fallen ein paar verlorene Kunden kurzfristig nicht ins Gewicht. Nur langfristig könnte man sich an der Einsteigerbasis a la Altera (die hierzulande gerne die Hochschulen 'infiltrieren') etwas mehr Boden gutmachen.
Strubi schrieb: > Die SW ist ja kostenlos für die "kleinen" Käfer, man muss nur jedes Jahr > eine neue Lizenz beantragen. Ja das stimmt. Sogar für den ECP5U (was gegenüber der Situation beim ECP3 ja schonmal ein Fortschritt ist). Allerdings "klein": Bei Xilinx fangen die großen FPGAs die nicht mehr von der kostenlosen Software unterstützt werden erst da an, wo Lattice schon nix vergleichbares mehr hat ;-)
Und was ist die Lösung? Ich habe Lizenz für Quartus 12 und würde gerne keine Neuentwicklung mit Cyclone IV machen. Cyclone V ist leider schlechter als IV. Xilinx oder Lattice ist die Frage???
Jan D. schrieb: > Habt ihr Erfahrungswerte bezüglich Größe/Umfang/DSP Blöcke im Falle, > dass ich zwei HD Kameras mit mindestens 1280 × 720 Pixeln anbinden > und die Disparity Matrix berechnen möchte. Hängt das nicht vom verwendeten Algorithmus und der benötigten Framerate ab? Hier hat mal jemand eine Abschätzung für Semi Global Matching gemacht: http://samos-conference.com/Resources_Samos_Websites/Proceedings_Repository_SAMOS/2010/Files/2010-IC-14.pdf Das klingt aber nicht nach low cost.
Bitte 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.