Durch das hier Beitrag "Marke Eigenbau: SoC-Imitat" bin ich auf die Zynqs gekommen und möchte mich mit Ultrascale-FPGAs befassen. Ich hätte gerne den Tipp eines Experten, welches OS dafür bestenfalls in Frage käme. Wir sprechen vom OS, dass auf den RPUs laufen soll, nicht von dem, was ich für den Entwicklungs-PC verwende. (Dort läuft u.a BSD / Ubuntu). Benutzt zufällig jemand Ubuntu auf FPGAs?
Ika-Russe schrieb: > Wir sprechen vom OS, dass auf den RPUs laufen soll Wassn ne RPU? Ueblicherweise laeuft auf CPUs in FPGAs gerne mal ueberhaupt kein OS (Bare Metal) oder irgendein Linux. Wenn man nicht so recht weiss, welche Geschmacksrichtung, dann nimmt man genau das des jeweiligen Herstellers. Gruss WK
Kommt halt darauf an was du machen moechtest. Auf den RPUs kann man z.B. ganz gut mit FreeRTOS arbeiten falls man Threading braucht und auf den APUs dann ein Linux packen. Man kann auch auf den APUs mit FreeRTOS arbeiten oder auch auf jeweils ohne alles. Da sind keine Grenzen gesetzt. Was auch geht ist, die Kerne zu mischen, Stichwort Hypervisor: https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841668/Multi-OS+Support+AMP+Hypervisor Ob man auf den RPUs mit Linux gluecklich wird, kann ich nicht beurteilen. Noch nie gemacht, weil man die in der Regel fuer sicherheitskritische Anwendungen verwenden und dann gerne mit einem RTOS arbeit, bzw. gleich ganz auf Threading verzichtet. Alles in allem: Den Moeglichkeiten sind praktisch unbegrenzt und was die jeweils beste Loesung ist, haengt immer sehr stark von derAnwendung ab.
Das sind ARM-CPUs, oder? Da gibt es ein https://en.wikipedia.org/wiki/Arch_Linux_ARM Geht das vielleicht da drauf?
Elbi schrieb: > Das sind ARM-CPUs, oder? > > Da gibt es ein https://en.wikipedia.org/wiki/Arch_Linux_ARM > > Geht das vielleicht da drauf? Klar, muss man aber wohl ein bisschen Fleissarbeit reinstecken. Das Zedboard wird auf jedenfall mal unterstuetzt: https://archlinuxarm.org/platforms/armv7/xilinx/zedboard Ich wuerde aber auch erstmal zum Petalinux raten. Der TO hat aber explizit nach den RPUs gefragt, da wird es natuerlich entsprechend aufwendig ein Linux drauf zu bekommen.
Moin, OK, hab' mal geguckt, das mit RPU und APU scheint mir ja reines Marketingblubber von Xilinx zu sein. Das sind halt ARM-Prozessoren. Punkt. Natuerlich wird man da auch irgendein "Marken"-Linux, wie z.b. Arch oder Raspbian oder sonstwas drauf ans Laufen bringen, wenn man sich anstrengt. Aber wozu? Wenn ich irgendein Produkt mit so einem Xilinx-Apparillo entwickle, sollen dann die Kunden da mit sudo apt-get gedoens oder Aehnlichem draufrumschraddeln? Wohl eher nicht. Da wirds darum gehen, dass man ein ziemlich auf die jeweilige Aufgabe spezialisiertes und miniaturisiertes Linux - wenns denn unbedingt ein Linux sein muss - draufbringt und nicht eine komplette Distribution mit allem Furz und Feuerzeug. Gruss WK
Dergute W. schrieb: > OK, hab' mal geguckt, das mit RPU und APU scheint mir ja reines > Marketingblubber von Xilinx zu sein. Das sind halt ARM-Prozessoren. Es gibt einen absolut relevanten Unterschied: APU: ARM Cortex-A53 RPU: ARM Cortex-R5 Letzterer ist für Linux ungeeignet, da keine MMU. FreeRTOS wird unterstützt.
Dergute W. schrieb: > OK, hab' mal geguckt, das mit RPU und APU scheint mir ja reines > Marketingblubber von Xilinx zu sein. Das sind halt ARM-Prozessoren. > Punkt. Du bist ein Depp - Ausrufezeichen ! Bei ARM gibt es Cortex. und bei Cortex gibt es A R und M. Cortex-R ist für (harte) Echtzeit-und sicherheitskritische Anwendungen gedacht. Etwas was man mit Cortex-A eher nicht realisieren kann. Wer mal ein bißchen mit RasPi in Richtung embedded Echtzeit eignung probiert hat weiss das. https://en.wikipedia.org/wiki/ARM_Cortex-R https://de.wikipedia.org/wiki/ARM_Cortex-A Beitrag "Raspberry Pi - Echtzeitsystem?"
So wird's gemacht schrieb: > Du bist ein Depp - Ausrufezeichen ! Axo, na dann ist's ja gut. Ich hab' mir schon Sorgen gemacht. https://en.wikipedia.org/wiki/%CE%9CClinux#Supported_architectures WK
Dergute W. schrieb: > OK, hab' mal geguckt, das mit RPU und APU scheint mir ja reines > Marketingblubber von Xilinx zu sein. Das sind halt ARM-Prozessoren. > Punkt. Sorry, die Aussage ist komplett unqualifiziert. Nicht nur, dass wie schon erlaeutert die verschiedene ARM Architekturen unterschiedliche Staerken und schwaechen haben, auch die Anbindung zum restlichen Zynq System und den Kernen untereinander unterscheiden sich stark. Die Datenblaetter und User Guides sind umfangreich und gerade wenn man wenige Vorkenntnisse hat nur schwer nachvollziehbar. Daher kann ich nur empfehlen mal folgendes PLC2 Seminar zu besuchen: https://www.plc2.com/training/detail/semsearch/xilinx-zynq-ultrascale-mpsoc-silica/ Um einen Ueberblick ueber die Zynq Ultrascale+ Architektur zu bekommen, ist das wirklich sehr hilfreich.
:
Bearbeitet durch User
Tobias B. schrieb: > Ich wuerde aber auch erstmal zum Petalinux raten. Dazu würde ich wiederum nicht raten. Ein Kollege hier kotz damit schon seit Wochen rum und bekommt es kaum ans Laufen. Grund ist die mangelnde Dokumenation von Xilinx. S. R. schrieb: > Letzterer ist für Linux ungeeignet, da keine MMU. Braucht man die unbedingt für harte Echtzeit? So wird's gemacht schrieb: > Cortex-R ist > für (harte) Echtzeit-und sicherheitskritische Anwendungen gedacht. Etwas > was man mit Cortex-A eher nicht realisieren kann. Da möchte ich gerne nachfragen: Wenn die A (A53) nicht primär für harte Echtzeit geeignet sind (warum nicht?), wie passt das dann mit der Aussage der PLC2-Webseite zusammen: "Die Realtime Processing Unit RPU bietet zudem optimale harte Echtzeitverarbeitung bei geringer Verlustleistung, ebenfalls mit flexibler Peripherieanbindung wie auch zur programmierbaren Logik." Welches System / welcher Teil ist denn nun der für Echtzeit besser geeignete und warum?
Und dann noch das: Zitat von der PLC2-Seite: "Mit Hypervisor Technologie in der APU können auch zeitleich mehrere Betriebssysteme parallel betrieben laufen,oder auch protected CPU Systeme konfiguriert werden, für eine leistungsfähige Software Verarbeitung." Mal abgesehen von dem schlimmen Deutsch verstehe ich das inhaltlich nicht! Wie(so) werden mehrere OS gestartet? Wie werden "protected" System gestartet (ich nehme an, die wirken isoliert von den anderen) und wieso soll das effektiver sein? Man benutzt doch MultiCore um effektiv zu werden.
Es hängt halt davon ab was man machen will. Die Zynq Ultrascale haben halt den Vorteil dass man völlig felxibel ist. Man hat ne APU für den weniger zeitkritischen Anteile (z.B. einfache Anbindung an an Standard-Interfaces via Linux etc) und einen zeitkritischen Anteil via Bare-Metal oder RTOS (RPU) und die harte Echtzeit Anforderungen wandern halt ins FPGA. Und wer möchte hat halt auch noch HW für h.264/h.265
:
Bearbeitet durch User
Elbi schrieb: > Wenn die A (A53) nicht primär für harte Echtzeit geeignet sind (warum > nicht?), Beim RasPi sinds einfach Erfahrungswerte, da schwanken die Response-zeiten wie ein besutrunkener Seemann bei schwerer See. Wenn man sich die Architekturunterschiede wie oben verlinkt anschaut, dann könnte hierfür "Deterministic interrupt handling as well as fast non-maskable interrupts" das Geheimnis sein warum der -R besser für harte Echtzeit geeignet ist als der -A mit seinen "nested IRQ". Die getrennten Memory maps sind wohl vorrangig für sicherheitsrelevante Apps gedacht, können aber auch für Echtzeit gut sein, weil die Traps nach Speicherverletzungen entfallen. In die selbe Kerbe schlägt "Increased exception handling in hardware", auch ein -R feature. Beim -A wird halt viel vom OS abgehandelt, was der -R flott per HW abfrühstückt. Intressant auch die Möglichkeit Cache nicht zu benutzen um vorhersehbare und Kontextunabhängige Speicherzugriffszeiten zu garantieren http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0338g/Chdhbjjb.html
Elbi schrieb: > "Mit Hypervisor Technologie in der APU können auch zeitleich mehrere > Betriebssysteme parallel betrieben laufen,oder auch protected CPU > Systeme konfiguriert werden, für eine leistungsfähige Software > Verarbeitung." > > Mal abgesehen von dem schlimmen Deutsch verstehe ich das inhaltlich > nicht! Der Inhalt steckt in dem nicht zitierten folgenden Satz: "Auch Safety und Secure Anforderungen werden nach Sicherheitstandards unterstützt." Mehrerer OS/parallel arbeitende geschützte CPU starten macht unter dem Aspekt von Redundanz und Überwachung Sinn. Der -R wird eben für Sicherheitsanwendungen (Medizintechnik) vermarktet. Und da braucht man zuweilen CPU's die am selben Problem arbeiten und deren Output uberwacht wird. Ist dieser nicht mehr gleich, ist irgendwas nicht mehr deterministisch und das Gerät schaltet in den FallBack. https://history.nasa.gov/computers/Ch4-4.html
Elbi schrieb: >> Letzterer ist für Linux ungeeignet, da keine MMU. > Braucht man die unbedingt für harte Echtzeit? Nein, aber Linux macht ohne MMU deutlich weniger Spaß. >> für (harte) Echtzeit-und sicherheitskritische Anwendungen gedacht. Etwas >> was man mit Cortex-A eher nicht realisieren kann. > Da möchte ich gerne nachfragen: > > Wenn die A (A53) nicht primär für harte Echtzeit geeignet sind (warum > nicht?), wie passt das dann mit der Aussage der PLC2-Webseite zusammen: > > "Die Realtime Processing Unit RPU bietet zudem optimale harte > Echtzeitverarbeitung bei geringer Verlustleistung, ebenfalls mit > flexibler Peripherieanbindung wie auch zur programmierbaren Logik." Lies genauer: Die Webseite spricht von der RPU, da ist der R5 drin. Nicht der A53. > Welches System / welcher Teil ist denn nun der für Echtzeit besser > geeignete und warum? RPU = Cortex-R5 = Echtzeit APU = Cortex-A53 = Rechenleistung
Elbi schrieb: > Dazu würde ich wiederum nicht raten. Ein Kollege hier kotz damit schon > seit Wochen rum und bekommt es kaum ans Laufen. Grund ist die mangelnde > Dokumenation von Xilinx. Was für Probleme kann man haben das PetaLinux auf den Ultrascale+ zu bekommen? Für mich nicht ganz nachvollziehbar. Sowohl YOCTO als auch PetaLinux draufzubekommen ist doch nicht wirklich kompliziert. Oder macht ihr da schon was ganz besonders kompliziertes? Was man halt schon hat, bei so einem Chip muss man für alles halt mal mit einer Woche statt mit drei-vier Stunden wie bei einem Cortex-M rechnen. Dessen sollte man sich bewußt sein ... vor allem sollten sich die Führungskräfte dessen bewußt sein. Man vergleiche nur die MALI, A-53, SMMU, USB Erratas mit dem eines Cortex-M. Für die "kleinen" Module kommen ja die kurzen Erratas dann ja noch oben drauf. Ich war hier am anfang ein Gegner des ZYNQ Ultrascale+. Inzwischen hat das zu ist ganz interessant gewechselt und vielleicht heiße ich irgendwann sogar die Entscheidung gut. Für die RPU natürlich FreeRTOS, µC-OS2 (beide für Port ein Morgenblock 4h), embOS (gibts bestimmt auch für R5), ... Insbesondere ein Port von Cortex-M7 zu R5 sollte ja pillepalle sein. Insgesamt ist der R5 inkl. MPU von seiner Architektur noch sehr überschaubar und der Port kein größeres Thema. Auf dem A53 inkl. MMU finde ich das doch etwas komplizierter aber ist auch noch handelbar. Dort kann man ja auch für komplexe bedingte Kalkulationen einen Kern dem Linux entziehen. Die Frage ist da nur ob man für die Aufgabe dann wirklich ein OS braucht, aber für die Kommunikationsschicht ist es meist noch ganz nett.
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.