Eine kleine Grundsatzfrage zu CPUs in FPGAs - konkret zum ARM-CORE:
Gate Arrays haben heute integrierte ARM-CPUs und dies gleich im
4er-Satz, wie man von Xilinx weiß. Ich kenne mich damit nicht so
umfänglich aus, suche diesbezüglich vor allem nach Infos hinsichlich
Sicherheitsaspekten. Was ich von meiner Arbeit kenne, ist dass
zusätzliche Datensicherheit einerseits Redundanz in der HW fordert und
zum anderen aber auch Rechenpower.
Wie sieht es damit aus? Aus den Datenblättern entnehme ich, dass die
ARMs in den FPGAs nicht mit den Taktfrequenzen arbeiten, die man von
Solo-Bausteinen gewohnt ist. Haben die noch andere Nachteile?
Wie sind die intern verschaltet? Gibt es da Vorteile gegeneinüber einem
Selbstbau System aus massiv gebauten Kernstrukturen, also 4 Solo
arbeitenden ARMs auf einer Platine? Ich nehme an, dass es von der
Signalqualität "innen" besser und einfacher ist. Kann ich mit einer so
aufgezogenen 4-fach ARM Stuktur extern dieselben IO-Datenraten
erreichen, wie mit einer internen Koppelung?
Gibt es jemanden, der ein mehrfach-Kern-System auf so einen FPGA
portiert hat und dazu einiges berichten kann?
Ein Beispiel:
Wie ich sehe, hat z.B. jeder der Kerne zwar Zugriff auf denselben Bus,
kann aber nicht parallel auf das DDR-RAM, weil es nur eines davon extern
verkoppelt gibt. Das scheint mir schon ein Flaschenhals zu sein, der
sich mit einer externen Struktur umgehen liesse.
Ge. B. schrieb:> Wie sind die intern verschaltet?
Kannst ja mal beginnen im Technical Reference Manual zu wühlen:
https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdfGe. B. schrieb:> Wie ich sehe, hat z.B. jeder der Kerne zwar Zugriff auf denselben Bus,> kann aber nicht parallel auf das DDR-RAM, weil es nur eines davon extern> verkoppelt gibt. Das scheint mir schon ein Flaschenhals zu sein, der> sich mit einer externen Struktur umgehen liesse.
Von was für Anwendungsfeldern Reden wir hier bzw. was ist heisst bei dir
"Was ich von meiner Arbeit kenne"?
In deiner Frage kommen viele Aspekte zusammen und ich weiss nicht worauf
das hinauslaufen soll um dann gezielt antworten zu können.
Ge. B. schrieb:> Gibt es da Vorteile gegeneinüber einem> Selbstbau System aus massiv gebauten Kernstrukturen, also 4 Solo> arbeitenden ARMs auf einer Platine?
4 Solo Prozessoren ist nicht dasselbe wie ein Quad—Core Prozessor,
völlig anders zu programmieren da es keinen geteilten Speicher gibt.
Vorteile externe Prozessoren
- Speicherbandbreite
- mehr Rechenpower, aber im Ernst Quad-A53 (Intel und Xilinx) plus
Dual-R5 (nur Xilinx) reichen nicht?
Vorteile interne Prozessoren
- Platzbedarf
- Bandbreite zum FPGA
Ge. B. schrieb:> Was ich von meiner Arbeit kenne, ist dass> zusätzliche Datensicherheit einerseits Redundanz in der HW fordert und> zum anderen aber auch Rechenpower.>> Wie sieht es damit aus?
Richtig. Je nach Sicherheitslevel, dass du erreichen willst/musst,
bleibt dir ggf. gar nichts anderes übrig als mehrere Chips einzusetzen.
Das muss man für die Anwendung entscheiden. Du hast ja in deinem PC auch
keine 2 CPUs drin (wahrscheinlich).
Ge. B. schrieb:> Wie sind die intern verschaltet? Gibt es da Vorteile gegeneinüber einem> Selbstbau System aus massiv gebauten Kernstrukturen, also 4 Solo> arbeitenden ARMs auf einer Platine?
Ja. Dadurch, dass du einen Quadcore Prozessor bspw. hast, ist es möglich
ein Linux auf den vier Kernen laufen zu lassen anstatt 4 getrennter
Applikationen. Wobei das u.U. auch wünschenswert sein kann. Ich habe auf
einem FPGA-SOC schon auf 2 Kernen Linux laufen gehabt und in den anderen
2 liefen Bare-Metal Firmwares für Echtzeit-Anwendungen. Der Vorteil
eines echten Quad-Cores ist, dass die Cores untereinander noch speziell
verschaltet sind und dadurch bspw durch eine Snoop-Control-Unit
sichergestellt wird, dass die Caches der Kerne synchron sind etc.
Anderer Vorteil sind die Kosten. Wenn ich vier ARMs auf eine Platine mit
Speicher, Nahbeschaltung, Versorgung etc. hängen will + einen FPGA ist
es garantiert teurer als einen SoC zu nehmen.
Ge. B. schrieb:> Wie ich sehe, hat z.B. jeder der Kerne zwar Zugriff auf denselben Bus,> kann aber nicht parallel auf das DDR-RAM, weil es nur eines davon extern> verkoppelt gibt. Das scheint mir schon ein Flaschenhals zu sein, der> sich mit einer externen Struktur umgehen liesse.
Ist bei fast jedem Prozessor ein "Flaschenhals". Auch bei einem
Single-Core ARM. Selbst DDR3 ist im Vergleich zum Core teilweise grottig
lahm. Die Performance kommt durch gutes Caching und Dinge wie
Branch-Prediction etc. Ebenso hilft die Hyperskalarität der modernen
CPUs dabei, längere Speicherzugriffe mit anderen Befehlen überbrücken zu
können(, wenn man da nicht alzuviele Bugs in seiner CPU hat. Siehe
Meltdown, Spectre etc...)
Die bandbreite zwischen FPGA und Prozessorsystem in einem SoC wirst du
so quasi auf einer Platine nicht hinbekommen. Mein Cyclone V SoC hier
(altes Modell) hat einen 128 bit breiten AXI zwischen FPGA und
Prozessor. Dazu kommt noch, dass man sich quais um die Signale keine
Gedanken machen muss, da sie bereits auf dem Chip korrekt designt wurden
und funktionieren. Ein solches Speicherinterface auf PCB zu routen
kostet viele Nerven und ggf. viele Iterationen.
M. H. schrieb:> Ist bei fast jedem Prozessor ein "Flaschenhals".M. H. schrieb:> Die bandbreite zwischen FPGA und Prozessorsystem in einem SoC wirst du> so quasi auf einer Platine nicht hinbekommen. Mein Cyclone V SoC hier> (altes Modell) hat einen 128 bit breiten AXI zwischen FPGA und> Prozessor.
Kann man RAM, das man am PL Teil des SoCs anbindet auch als RAM für die
CPU verwenden?
Normalerweise haben CPUs ja "nur" Interfaces/Hardwarecontroller für
D-RAM drinnen, aber das hat eben lange Zugriffslatenzen und ist auch nur
dann richtig schnell wenn viele Daten am Stück übertragen werden. An den
PL Teil, also an das FPGA kann man aber auch SRAM anschließen und das
ist sehr schnell bei zufälligen Zugriffen. Es wäre also für manche
Anwendungen vielleicht sinnvoll den CPUs im SoC ein schnelles SRAM zu
geben.
Geht das, oder kann so ein ARM im SoC nur das als RAM verwenden was
direkt an ihm angebunden ist über den eingebauten DRAM Controller?
Das PS kann über AXI auf die PL zugreifen. Dort kannst du beliebige
AXI-Slaves instanziieren. Auch Zugriff auf BRAM, LUTRAM, Register,
PL_RAM etc. ist so vom ARM aus möglich. Wir dann einfach in den
Adressraum des ARMs eingeblendet.
Ich bin heute gut drauf. deswegen gibt es das jetzt vorgekaut. Aber das
hätte man mit minimalem Leseaufwand auch aus den Hochglanzfolien der SoC
Hersteller lesen können. Ich beziehe mich hier auf einen cyclone V SoC
von Intel/Altera. Prinzipiell ist das auch bei Xilinx so.
Diese besitzt ein HPS (Hard Processor System) mit einem Cortex A9
Dual-Core.
Im Bild "altera-soc.png" siehst man den groben Aufbau. Der SoC besteht
aus 2 Teilen. Dem Hard Processor System (HPS) und dem FPGA-Teil. Beide
sind durch Interfaces miteinander verbunden. Es ist durch die saubere
Trennung möglich den HPS und FPGA auch unabhängig voneinander zu nutzen.
Im Bild "hps.png" ist ein genauerer Teil des HPS zu sehen und auch die
einzelnen Interfaces zum FPGA-Teil.
Es sind mehrere Interfaces zu sehen. Diese umfassen:
1) HPS to FPGA und Lightweight HPS to FPGA AXI Interfaces. Das sind
Interfaces, mit denen aus dem Prozessorsystem auf FPGA-Logik zugegriffen
werden kann. Die Peripherie im FPGA-Teil wird hierbei in den Speicher
des HPS gemappt. So wie jedes andere Peripheriemodul auch. Das Mapping
in den Speicher ist in der Grafik memory-mapping.png dargestellt. Da ist
in der ganz rechten Spalte der Speicher, den die CPU sieht, gezeigt und
in welchen Speicherbereichen die Interfaces zum FPGA liegen. H to F =
HPS to FPGA etc...
2) Es gibt ein FPGA to HPS Interface. Das ist quasi das gleiche nur
andersrum. Dadurch ist es prinzipiell möglich aus dem FPGA-Teil auf
Peripheriemodule im HPS (wie Timer, Uart, SPI, GPIO etc.) zuzugreifen.
3) In diesem SoC gibt es noch einen direkten Link zwischen FPGA-Teil und
dem RAM-Controller im HPS, damit RAM Zugriffe die Bus-Matrix nicht
strapazieren.
4) Config-interfaces: Es ist über ein Peripheriemodul im HPS möglich den
FPGA-Teil des FPGAs zu konfigurieren.
5) Interrupts. Es ist eine Hand voll Interruptleitungen vom FPGA Teil an
den Cortex-A9 Prozessor vorhanden, damit Peripheriemodule im FPGA
Interrupts in der CPU auslösen können.
Wie du sehen kannst, ist das HPS mehr als nur ein einfacher Prozessor.
Es ist quasi von sich aus schon ein System on Chip. (Ich halte die
bezeichnung SoC, imho, für totalen Schwachsinn, da alles was mehr als 4
Pins hat heutzutage eigentlich ein System auf einem chip ist... Das ist
halt Buzzword-Bingo). Das HPS beinhaltet neben dem Prozessor + Memory
Controller noch verschiedene Peripheriemodule wie Ethernet, Uart, CAN,
GPIOs, SDIO für eine SD-Karte und USB...
Mit dem gesamten SoC hast du somit quasi einen kompletten modernen
ARM-Controller inklusive Peripherie mit der Option dir noch zusätzliche
Peripherie in einem FPGA direkt an den internen Adressbus zu basteln.
das nächste Mal kannst du dir das Datenblatt ja selbst herunterladen und
Bilder schauen. Für die obigen Informationen ist es größtenteils
nichtmal nötig den Text zu lesen.
