Forum: FPGA, VHDL & Co. Anwendung mit 3D GUI auf FPGA/ARM SoC portieren - gibt es FPGA SoCs mit GPU oder GPU IP-Cores?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Janos B. (janos)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Thomas W. (diddl)


Bewertung
0 lesenswert
nicht lesenswert

: Bearbeitet durch User
von Janos B. (janos)


Bewertung
0 lesenswert
nicht lesenswert
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.

von PennenderPanda (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von bitwurschtler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Janos B. (janos)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Lars R. (lrs)


Bewertung
0 lesenswert
nicht lesenswert

von Janos B. (janos)


Bewertung
1 lesenswert
nicht lesenswert
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

von bitwurschtler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?!

von ISM (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Janos B. (janos)


Bewertung
1 lesenswert
nicht lesenswert
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
von Bernd K. (prof7bit)


Bewertung
2 lesenswert
nicht lesenswert
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.

von bitwurschtler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
https://hackaday.io/project/11815-quicksilver-neo-open-source-gpu

Das erscheint einigermassen realistisch für aktuelle FPGAs

von Janos B. (janos)


Bewertung
0 lesenswert
nicht lesenswert
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
von Thomas W. (diddl)


Bewertung
0 lesenswert
nicht lesenswert

von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Janos B. (janos)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Markus W. (elektrowagi78) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.