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.pdf 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. 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.
Christoph Z. schrieb: > In deiner Frage kommen viele Aspekte zusammen und ich weiss nicht worauf > das hinauslaufen soll um dann gezielt antworten zu können. Auch mein problem, vielleicht kannst du das an dem Blockbild: https://images4.programmersought.com/847/92/924bc8e94e6a2c852ac780369a0d4a8f.JPEG erklären. Unten Mitte ist das Interface zum externen Speicher, in der Mitte dieverse Dtenstromverteiler, oben die 4 A5 ARM's (Mitte) und die zwei ARM Cortex R5-Cores mit Caches. Falls das zu complex ist, dann fang mit dem Ur-Zybo (ohne Ultrascale) an, der hat 'nur' zwei ARM Cores und ein Super (Free) Buch dazu: http://www.zynqbook.com/ https://www.avnet.com/wps/wcm/connect/onesite/49a70564-f742-49ed-a3f6-84b074d2e1d0/Xilinx-zynq-7000-bd.jpg?MOD=AJPERES&CACHEID=ROOTWORKSPACE.Z18_NA5A1I41L0ICD0ABNDMDDG0000-49a70564-f742-49ed-a3f6-84b074d2e1d0-lQ8O-0i
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.
Angehängte Dateien:
-
altera-soc.png
72 KB -
hps.png
100 KB -
memory-mapping.png
58 KB
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.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.