Hallo zusammen, bevor ich zur eigentlichen Frage komme, kurz zu deren Hintergrund: Ich bin aktuell E-Technik Masterstudent im 3. Semester und bin auf der Suche nach einem spannenden Projekt (vllt. für meine Masterarbeit) mit gewissem Anwendungsbezug an der Schnittstelle zwischen FPGA und CPU. In den letzten zwei Semestern habe ich an einem ziemlich coolen Software Defined Radio Projekt gearbeitet, woraus nun ein vollständig in C++ programmierte Linux Anwendung entstanden ist (aktuell läuft die auf einem standard PC mit x86 CPU - ist aber vollständig Cross-Platform fähig aufgebaut), welche in Echtzeit Daten von einem Ettus SDR-Frontend streamt, diese dann verarbeitet und anschließend Messergebnisse auf einer selbst eintwickelten GUI in Echtzeit grafisch darstellt. Im kommenden Semester möchte ich mich im Thema 3D-Grafikprogrammierung via OpenGL einarbeiten und die aktuellen 2D Plots in der GUI durch anschaulichere 3D Plots ersetzen. Im Anschluss fände ich es nun spannend die PC-Anwendung in ein eingebettetes System zu portieren. Dazu kommt mir ein FPGA/ARM SoC eigentlich perfekt vor, das gesamte Ettus Frontend könnte durch direkt an den FPGA angekoppelte Wandler ersetzt werden, die DSP-Algorithmen sind hochgradig parallelisierbar und könnten somit auch vollständig auf FPGA-Logik umgesetzt werden. Der ARM könnte anschließend sich nur noch um die Darstellung der (nahezu unveränderten) GUI kümmern. Wie aber oben beschrieben, wird die GUI bald 3D-Elemente enthalten, die auf die GPU zugreifen. Zwar ist das keine immens anspruchsvolle 3D Anwendung, dennoch bin ich mir unsicher wie gut diese performt, wenn sie alleine in Software auf einem 1-1,5GHz Dual Core ARM, wie er in den mir bekannten SoCs aktuell zu finden ist, umgesetzt wird. Daher meine Frage: Ist irgendjemandem ein SoC bekannt, welches neben dem ARM noch eine GPU der "Smartphone-Klasse" enthält, vielleicht so etwas wie der VideoCore im Raspberry Pi? Oder gibt es GPU IP-Cores, welche neben der DSP-Anwendung in FPGA-Logik umgesetzt werden können und an den ARM angekoppelt werden können? Falls es die Wahl gibt, fühle ich mich bei Altera mehr "zu Hause", da ich mit deren Entwicklungstools schon etwas mehr gearbeitet habe, das soll aber kein ausschlaggebendes Kriterium sein. Ich bin gespannt auf die Antworten!
Ich spiele mich gerade mit dem Teil herum: https://de.aliexpress.com/item/ICore3-ARM-FPGA-dual-core-Ethernet-high-speed-USB-STM32F407-IPC/32848272705.html?spm=a2g0x.search0104.3.15.1466b46bvnjJ15&ws_ab_test=searchweb0_0,searchweb201602_4_10065_10344_10068_10547_10342_10343_10340_10548_10341_10084_10083_10618_10304_10307_10302_5722315_10313_10059_10534_100031_10103_441_10624_442_10623_10622_10621_10620_10142,searchweb201603_40,ppcSwitch_5&algo_expid=99627478-7aa8-4a83-85c7-2af0948557e4-2&algo_pvid=99627478-7aa8-4a83-85c7-2af0948557e4&priceBeautifyAB=0 Es verbindet einen Altera FPGA mit einem dualcore STM32 ARM. Oder meinst du was richtig leistungsstärkeres? Dann gibt es diese ZYNQ, die sind halt auf Xilinx Basis ... Aber dafür Cortex A9 dualcore https://de.aliexpress.com/item/Xilinx-FPGA-Board-Artix7-Artix-7-Development-Board-XC7A35T-Core-Board-with-64Mbit-SPI-Flash-456Mbit/32800950361.html?spm=a2g0s.13010208.99999999.262.c2cEIR Ansonsten halt die üblichen Raspberry + FPGA Zusatz Karte Lösungen
:
Bearbeitet durch User
Thomas W. schrieb: > Oder meinst du was richtig leistungsstarkes? > > Dann gibt es diese ZYNQ, die sind halt auf Xilinx Basis ... > Aber dafür Cortex A9 dualcore > > https://de.aliexpress.com/item/Xilinx-FPGA-Board-Artix7-Artix-7-Development-Board-XC7A35T-Core-Board-with-64Mbit-SPI-Flash-456Mbit/32800950361.html?spm=a2g0s.13010208.99999999.262.c2cEIR Jo, so etwas in der Art meinte ich mit FPGA/ARM SoC. Solche Teile kenne ich, was ich suche wäre etwas vergleichbares, aber halt dann noch mit einer an diesen DualCore ARM angebundene GPU und - hatte ich gar nicht erwähnt - am besten natürlich mit irgendeinem Display-Ausgang (HDMI?) der an diese GPU angebunden ist um direkt ein Display zur Darstellung der GUI anzukoppeln.
Thomas W. schrieb: > Es verbindet einen Altera FPGA mit einem dualcore STM32 ARM. Nö, der F407 ist ein normaler Single-Core M4 mit 168 MHz.
Janos B. schrieb: > Ist irgendjemandem ein SoC bekannt, welches neben dem ARM noch eine GPU > der "Smartphone-Klasse" enthält, vielleicht so etwas wie der VideoCore > im Raspberry Pi? Oder gibt es GPU IP-Cores, welche neben der > DSP-Anwendung in FPGA-Logik umgesetzt werden können und an den ARM > angekoppelt werden können? Was hindert Dich daran einen solchen Core selbst zu schreiben? Diese Video-Cores sind in der Regel DSP-Cores mit a bisserl hardcoded Firmware also kein Hexenwerk. Ansonsten schau mal bei opencores: https://opencores.org/projects
Thomas W. schrieb: > Ansonsten halt die üblichen Raspberry + FPGA Zusatz Karte Lösungen In die Richtung habe ich noch nicht gedacht, ich denke aber solche Lösungen werden kaum eine so leistungsfähige Schnittstelle zwischen FPGA und ARM haben, wie ich sie mir vorstelle. Da soll schon ordentlich Bandbreite zwischen den Devices möglich sein.
Thomas W. schrieb: > Ich spiele mich gerade mit dem Teil herum: > > https://de.aliexpress.com/item/ICore3-ARM-FPGA-dual-core-Ethernet-high-speed-USB-STM32F407-IPC/32848272705.html?spm=a2g0x.search0104.3.15.1466b46bvnjJ15&ws_ab_test=searchweb0_0,searchweb201602_4_10065_10344_10068_10547_10342_10343_10340_10548_10341_10084_10083_10618_10304_10307_10302_5722315_10313_10059_10534_100031_10103_441_10624_442_10623_10622_10621_10620_10142,searchweb201603_40,ppcSwitch_5&algo_expid=99627478-7aa8-4a83-85c7-2af0948557e4-2&algo_pvid=99627478-7aa8-4a83-85c7-2af0948557e4&priceBeautifyAB=0 Gibt es dazu auch englische Dokumentation, Schematic? Wie ist die Anbindung ARM<>FPGA realisiert? Danke, Lars.
bitwurschtler schrieb: > Was hindert Dich daran einen solchen Core selbst zu schreiben? Diese > Video-Cores sind in der Regel DSP-Cores mit a bisserl hardcoded Firmware > also kein Hexenwerk. Ansonsten schau mal bei opencores: > https://opencores.org/projects Ganz ehrlich: Ich hätte massig Respekt davor, zu versuchen mir eine GPU, die irgendwie an den AXI-Bus angebunden ist und unter Linux via OpenGL nutzbar ist selbst zu schreiben! Ich denke nicht, dass das so einfach ist... Wäre auf jeden Fall aktuell auch nicht mein kernziel so etwas selbst zu entwickeln, dann lieber nochmal nach einer besser geeigneten Plattform umsehen. Ich habe mich schon etwas nach IP Cores umgesehen, bisher bin ich aber auf noch nichts in der Richtung gestoßen - will aber nicht bedeuten, dass es so etwas nicht gibt
Janos B. schrieb: > Da soll schon ordentlich > Bandbreite zwischen den Devices möglich sein. Welche Bandbreite brauchst du denn? Für HD-Videostreaming reichen 6 Mbit/sec, das sollte doch mit zwei Handvoll RasPi-Pins machbar sein?!
Was war bei den ZYNQs das Problem, habe noch nicht verstanden, was du da anderes brauchst? Die haben doch GPUs drauf? https://www.xilinx.com/products/silicon-devices/soc/zynq-ultrascale-mpsoc.html
bitwurschtler schrieb: > Welche Bandbreite brauchst du denn? Alleine für die rohen, unbearbeiteten Samples, welche ich neben dem ausgewerteten Ergebnis gerne darstellen möchte, kommem mit einer Bandbreite von ca. 8 Gbit/s an (aktuell via 10GBit Ethernet an den PC angeschlossen). Natürlich kann hier noch ordentlich Datenreduktion im FPGA betrieben werden, aber prinzipiell wäre es schön die FPGA-Logik wirklich so eng wie möglich an den ARM anbinden zu können, um sich alle Optionen im Systemdesign offen zu lassen. ISM schrieb: > Was war bei den ZYNQs das Problem, habe noch nicht verstanden, was du da > anderes brauchst? Die haben doch GPUs drauf? > > https://www.xilinx.com/products/silicon-devices/soc/zynq-ultrascale-mpsoc.html Gar kein Problem - genau das habe ich gesucht! Unglaublich dass ich das bei meiner Google-Recherche nicht gefunden habe, diese Mali GPU ist genau so etwas woran ich dachte. Perfekt, damit wäre mein Ziel erreicht. Aus dem Altera/Intel Portfolio gibt es aber kein vergleichbares Device? Oder bin ich nur zu blöd die Websites nach den richtigen Stichwörter abzuscannen?
:
Bearbeitet durch User
Janos B. schrieb: >> Was hindert Dich daran einen solchen Core selbst zu schreiben? Diese >> Video-Cores sind in der Regel DSP-Cores mit a bisserl hardcoded Firmware >> also kein Hexenwerk. Ansonsten schau mal bei opencores: >> https://opencores.org/projects > > Ganz ehrlich: Ich hätte massig Respekt davor, zu versuchen mir eine GPU, > die irgendwie an den AXI-Bus angebunden ist und unter Linux via OpenGL > nutzbar ist selbst zu schreiben! Und selbst wenn er in endlicher Zeit damit zu einem nutzbaren Ergebnis käme hätte er wahrscheinlich in dem Moment schon längst den Rahmen seiner Masterarbeit gesprengt bevor er auch nur mit der eigentlichen Anwendung angefangen hat.
Bernd K. schrieb: > Und selbst wenn er in endlicher Zeit damit zu einem nutzbaren Ergebnis > käme hätte er wahrscheinlich in dem Moment schon längst den Rahmen > seiner Masterarbeit gesprengt bevor er auch nur mit der eigentlichen > Anwendung angefangen hat. Ja das stimmt, ich dachte die "FPGA-Programmierung" also IP-Core Entwicklung wäre die eigentliche Aufgabe der Masterarbeit, ist ja schließlich eine Masterarbeit im Bereich Elektrotechnik. Für die Graphik/GUI-Programmierung hätt ich eher einen Informatik-Studenten rangesetzt. >aber prinzipiell wäre es schön die FPGA-Logik >wirklich so eng wie möglich an den ARM anbinden zu können, um sich alle >Optionen im Systemdesign offen zu lassen. Leider meint "alle Optionen offen lassen" oft auch "alle Probleme möglich lassen". Eine Datenfilterung/-Reduktion möglichst früh reduziert das Problem oft erheblich und oft ist die Reduktion nüchtern betrachtet verlustfrei weil die entfernten Daten im wesentlichen informationsloses Rauschen sind. Also bspw. für einen Barcode-Scanner ist es nicht nötig die Sensordaten mit 24 bit Farbtiefe durch System zu schleifen. Aber bei ner Masterarbeit hatt man selten die Position gegenüber dem Betreuer auf eine sinnvolle Problemreduktion hinzuarbeiten.
https://hackaday.io/project/11815-quicksilver-neo-open-source-gpu Das erscheint einigermassen realistisch für aktuelle FPGAs
bitwurschtler schrieb: > Ja das stimmt, ich dachte die "FPGA-Programmierung" also IP-Core > Entwicklung wäre die eigentliche Aufgabe der Masterarbeit, ist ja > schließlich eine Masterarbeit im Bereich Elektrotechnik. Für die > Graphik/GUI-Programmierung hätt ich eher einen Informatik-Studenten > rangesetzt. Ja sicher auch ein wirklich spannendes Thema komplett für sich, aber definitiv nicht das was ich vorhabe und wonach ich gefragt habe. Die GUI ist ja auch schon gegeben, stellt also kein Zentrum der Arbeiten dar, wichtig ist also nur eine Architektur vorliegen zu haben, auf der die bestehende GUI ohne riesiges gebastel portierbar ist. Meine Freude beginnt dann eigentlich beim portieren der DSP-Algorithmen ins FPGA, das ist dann eher wieder eine E-Techniker Baustelle, der Rest ist nur hübsches User Inferface um die Messung bedienbar und visualisiert zu bekommen. bitwurschtler schrieb: > Leider meint "alle Optionen offen lassen" oft auch "alle Probleme > möglich lassen". Eine Datenfilterung/-Reduktion möglichst früh reduziert > das Problem oft erheblich und oft ist die Reduktion nüchtern betrachtet > verlustfrei weil die entfernten Daten im wesentlichen informationsloses > Rauschen sind. Also bspw. für einen Barcode-Scanner ist es nicht nötig > die Sensordaten mit 24 bit Farbtiefe durch System zu schleifen. Natürlich sollte es auch klar sein, dass ich nicht immer alle Daten benötige und dass Datenreduktion natürlich auch einen ordentlichen Geschwindigkeitsvorteil bringen kann. Und eigentlich ging es darum hier doch auch gar nicht. Es gibt halt auch Fälle in denen es definitiv nötig ist, alles mitzunehmen. In meinem Beispiel wäre das, die Rohdaten zur späteren Auswertung zusätzlich noch auf eine am ARM angebundene SSD zu speichern. Dann muss ich die volle Datenbandbreite vom FPGA in den ARM rüber bekommen. Ich denke schon, dass ich eine recht gute Vorstellung davon habe wie das System für meine Idee auszusehen hat. Markus F. schrieb: > https://hackaday.io/project/11815-quicksilver-neo-open-source-gpu > > Das erscheint einigermassen realistisch für aktuelle FPGAs Ah auch interessant, danke für den Link. Aber ich denke da nun ein Device mit hartem GPU direkt im SoC gefunden wurde, ist die Suche nach einem GPU IP Core auch schon fast wieder abgeschlossen. Also ich habe durch diesen thread gefunden was ich wollte - ausschließlich ein Altera Device mit gleicher Ausstattung würde mich noch glücklicher machen, aber im Endeffekt ist das oben verlinkte Xilinx schon richtig gut!
:
Bearbeitet durch User
Lars R. schrieb: > Thomas W. schrieb: >> Ich spiele mich gerade mit dem Teil herum: >> >> > https://de.aliexpress.com/item/ICore3-ARM-FPGA-dual-core-Ethernet-high-speed-USB-STM32F407-IPC/32848272705.html?spm=a2g0x.search0104.3.15.1466b46bvnjJ15&ws_ab_test=searchweb0_0,searchweb201602_4_10065_10344_10068_10547_10342_10343_10340_10548_10341_10084_10083_10618_10304_10307_10302_5722315_10313_10059_10534_100031_10103_441_10624_442_10623_10622_10621_10620_10142,searchweb201603_40,ppcSwitch_5&algo_expid=99627478-7aa8-4a83-85c7-2af0948557e4-2&algo_pvid=99627478-7aa8-4a83-85c7-2af0948557e4&priceBeautifyAB=0 > > Gibt es dazu auch englische Dokumentation, Schematic? > > Wie ist die Anbindung ARM<>FPGA realisiert? > > Danke, Lars. Ja Doku ist vorhanden, Demo Code gibt es. Die Anbindung ist parallel, sehr breit. Dieselbe wie schon beim iCore1 und 2. Sie haben auch einen Namen dafür, fällt mir gerade nicht ein.
Moin janos, hast du dir denn schon Gedanken gemacht, wie du deine Daten in den ARM SoC reinkriegst? Wenn ich da schon lese, dass einige Leut tolle Tips wie "GPU selber schreiben" parat haben, mein Einwurf, der nicht pessimistisch klingen soll: Es ist bereits schon eine rechte Knacknuss, grössere Datenmengen abrissfrei in ein Linux-System reinzukriegen. D.h. du musst dich allenfalls schon mit Kerneltreiber-Hacking und DMA-Details des Zynq herumschlagen, bevor's an OpenGL geht. Das sind mehrere Baustellen. Auf die GPU würde ich mich jetzt auch nicht so fixieren, sofern du nicht zigtausend Polygone animieren musst. Ein bisschen 3D-Waterfall geht auch locker ohne GPU, aber vielleicht hast du ja mehr vor... Dann hoffe ich mal, dass du einige Mitstreiter hast, denn der Teufel steckt immer im Detail, und die besten Pläne haken jeweils an den Details fest...
Hi Strubi, genau das was du beschreibst ist die Herausforderung, auf die ich Bock habe. Ich bin mir ziemlich im klaren darüber, dass das ein ganz schönes gefrickel wird, vor allem nachdem ich mich genau in die von dir beschriebenen Thematiken schon einmal oberflächlich eingelesen habe. Und genau aus diesem Grund sehe ich es so, dass ich mir eine Plattform wünsche, bei der ich meine Zeit genau in die Lösung dieser Details investieren kann und an dem Punkt auch ordentlich viel lernen kann und mich dann aber nicht, nachdem ich das alles irgendwann am Laufen habe mich ärgern muss, dass plötzlich die Hardware zu schlapp ist um meine GUI darzustellen. So ähnlich tatsächlich schon erlebt. Daher die Überlegung, dass eine mit einem Cross-Platform fähiges GUI-Framework mit OpenGL-Unterstützung etnwickelte Oberfläche zumindest in der Theorie relativ einfach von einem standard Linux PC auf einen ARM mit einer dafür passenden Linux Distribution umziehen können sollte, solang der ARM die passenden Ressourcen bereithält (dazu zähle ich jetzt mal die GPU) und für das Linux die passenden Treiber verfügbar sind. Sollte dann am Ende herauskommen, dass mein ARM mit GPU völlig oversized war ist das deutlich angenehmer daraus Potenzial für ein Downgrade abzuleiten, als anders herum an dem Punkt, der mich eigentlich weniger interessiert, hängen zu bleiben.
Janos B. schrieb: > in der Theorie relativ einfach von einem standard Linux PC auf einen ARM > mit einer dafür passenden Linux Distribution umziehen können sollte, > solang der ARM die passenden Ressourcen bereithält (dazu zähle ich jetzt > mal die GPU) und für das Linux die passenden Treiber verfügbar sind. "Theorie" :-) Nur so am Rande: Ich musste gerade etwa ein halbes Jahr warten, bis für eine SoC Plattform ein fehlerfreies Board-Supply-Package (was nicht sporadisch rebootet) rauskam. Das kann dir bei der Qualität der Xilinx-BSPs auch locker passieren. Ich würde dann einfach sicherstellen, dass auch deine Betreuer und Mitstreiter min. 1 Jahr an der Sache dranbleiben können und allfällige Projekt-Deadlines auf einzelne möglichst reduzierte Meilensteine abgesteckt sind. Denn die kernige, akademisch wertvolle Problematik zu lösen ist doch wichtiger als die wirbelige 3D-Grafik für die Präsentation, auch wenn das inzwischen oft anders gesehen wird.
Und man muss zusehen, dass man nicht zufällig ein board hat, bei dem nach 1 Jahr die Lizenz abläuft und es wertlos wird :-) Wie sieht es diesbezüglich bei dem o.g. board aus? Kann man die MALI CPU auch noch mit der Web-Version beackern?
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.