mikrocontroller.net

Forum: FPGA, VHDL & Co. OS für Ultrascale


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.
Autor: Ika-Russe (Gast)
Datum:

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

Autor: Dergute W. (derguteweka)
Datum:

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

Autor: Tobias B. (Firma: www.elpra.de) (ttobsen)
Datum:

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

Autor: Elbi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das sind ARM-CPUs, oder?

Da gibt es ein https://en.wikipedia.org/wiki/Arch_Linux_ARM

Geht das vielleicht da drauf?

Autor: Timmo H. (masterfx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nimm doch Petalinux von xilinx. Damit arbeite ich auch auf meinem Zynq.

Autor: Tobias B. (Firma: www.elpra.de) (ttobsen)
Datum:

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

Autor: Dergute W. (derguteweka)
Datum:

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

Autor: S. R. (svenska)
Datum:

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

Autor: So wird's gemacht (Gast)
Datum:

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

Autor: Dergute W. (derguteweka)
Datum:

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

Autor: Tobias B. (Firma: www.elpra.de) (ttobsen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Elbi (Gast)
Datum:

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

Autor: Elbi (Gast)
Datum:

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

Autor: Timmo H. (masterfx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: So wird's gemacht (Gast)
Datum:

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

Autor: So wird's gemacht (Gast)
Datum:

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

Autor: S. R. (svenska)
Datum:

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

Autor: YAG (Gast)
Datum:

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

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.

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