Servus, vor Kurzem wurde hier genannt, das es kaum noch/keine Nachfrage nach reinen FPGA's gäbe: Beitrag "Re: Zusammenfassung FPGA" Falls man das auf Xilinx beziehe würde da bedeutens, das die zu grossen Teilen Zynqs (FPGA+ ARM-CPU's) verkaufen und eher weniger Spartans, Artixe, etc.. Und falls dann doch die Nicht-SOPC benutzt werden, dann werkelt dort immer ein Softcore (Microblaze, NIOS). Das deckt sich nicht mit meinen Erfahrungen, deshalb stelle ich das hier zur Diskussion und verbinde das mit einer zweiten Frage, zu welchem Anteil jetzt die µC-Programmierung die Arbeit eines FPGA-Entwicklers ausmacht. Angefangen vom Aufsetzen des Prozessorsystems (Qsys,Vivado-Blockdesign), Generierung BSP bis zum Abschluss der µC-Firmware Entwicklung und Test. Meine Erfahrung: Reine Zybo-designs bis auf Akademischen Bereich (bspw. Doktorandenprojekte) noch nahezu Null, aber steigend. Noch einige Max10/Cyc10 Designs ohne NIOS am Start (bspw. Automotive Ethernet testboxen) erlebt, sogar noch ein Re-Design mit mehreren Cyclone II. Bei sicherheitskritischen Anwendungen tut man sich sehr schwer mit SOPC-FPGA's (IMHO noch kein Produkt mit Zynq für Avionic zertifiziert). Oft wird dem FPGA ein DSP/Mediaprozessor 'zur Seite' gestellt, das macht eine weitere CPU im FPGA unnötig. Beim Altera/intel ist der NIOS sehr gut eingeführt, während der mikroblaze eher einen schlechten Start mit dem eDK erwischte. Dann hatt Xilinx mit Vivado etwas aufgeholt. Die Nachfrage nach FPGA-Entwicklungen ohne Anteil in der Softwareentwicklung für NIOS, µBlaze, o.ä. ist stark gesunken, aber Erfahrungen mit diesen Teilaspekt ist (noch) nicht zwingend für FPGA-Entwickler gefordert. -- Aber wie gesagt, das ist keine pauschale Feststellung, lediglich individuelle Erfahrung. Wie sieht es in anderen Bereichen der Industrie aus?
Beitrag #6426553 wurde von einem Moderator gelöscht.
Da sollte man erstmal definieren was ein reines FPGA ist. In so einem Artix sind SerDes, BRAM, MMCM, DSP drinnen. Als reines FPGA würde ich etwas bezeichnen was nur aus LUTs und FFs besteht.
:
Bearbeitet durch User
Gustl B. schrieb: > Als reines FPGA würde ich etwas bezeichnen > was nur aus LUTs und FFs besteht. Dann wird die Luft tatsächlich sehr dünn. Wenn du zumindest BRAMs hinzu nimmst, findest du relativ viele kleine FPGAs, die als Steuerungen in diversem Kleingerät (z.B. Embedded Controller in Notebooks) dienen.
Genau. Wenn man es anders definiert und sagt alles ist ein reines FPGA was keine CPU enthält, dann gibt es da sehr viele Modelle und Anwendungsfälle. Bei meinen Basteleien verwende ich auch keine CPU weil man das was gemacht werden soll auch wunderbar in VHDL beschreiben kann. Ich wüsste ja gerne mal so als Hausnummer welchen Anteil der Soft-CPUs man im gleichen FPGA (also ohne auf größere Modelle auszuweichen) durch VHDL ersetzen könnte.
Zu den Anteilen kann ich nicht viel sagen, hab allerdings schon Zynq in Automotive Anwendungen gesehen. Allgemein dazu: Wenn man etwas (komplexes) in Software umsetzen kann, dann macht das die Sache meistens wesentlich einfacher und günstiger. Alles in HDL beschreiben dauert lange und man braucht Spezialisten --> teure Entwicklung. Dürfte daher auch wirtschaftliche Gründe haben wenn Firmen versuchen möglichst viel in Software zu erschlagen.
Gustl B. schrieb: > In so einem Artix sind SerDes, BRAM, MMCM, DSP drinnen. Als reines FPGA > würde ich etwas bezeichnen was nur aus LUTs und FFs besteht. Als "reines" FPGA-Design würde ich etwas bezeichnen, das nur die "üblichen" FPGA-nahen Komponenten verwendet und ohne Prozessorkern (ob Soft oder Hard) auskommt. Nun. schrieb: > Allgemein dazu: Wenn man etwas (komplexes) in Software umsetzen kann, > dann macht das die Sache meistens wesentlich einfacher und günstiger. Weil man die Programmierer für Software an jeder Ecke bekommt. Für die wird dann allerdings zuallererst ein Prozessor im FPGA benötigt (dessen Implementierung ist die Aufgabe des FPAG-Spezialisten), dann programmieren sie für den wie üblich ihre Software und nennen sich fürderhin "FPGA-Entwickler". Gustl B. schrieb: > Ich wüsste ja gerne mal so als Hausnummer welchen Anteil der Soft-CPUs > man im gleichen FPGA (also ohne auf größere Modelle auszuweichen) durch > VHDL ersetzen könnte. Genau 100%. Denn wenn schon ein universeller konfigurierbarer Zustandsautomat aka. Prozessorkern in das FPGA passt, dann passt logischerweise auch ein für die selbe Aufgabe speziell optimierter Zustandsautomat in das selbe FPGA. Nun. schrieb: > Dürfte daher auch wirtschaftliche Gründe haben wenn Firmen versuchen > möglichst viel in Software zu erschlagen. Auch ich nehme einen fertigen Prozessor mit fertigem 3D-Grafikinterface und ein paar MB Flash für zwofuffzich, wenn ich damit ein Problem erledigen kann. Eine Lösung mit FPGA in HDL wäre in diesem Fall immer zu teuer. Der Witz beginnt genau an der Stelle, wo keiner der marktüblichen Prozessoren/µC die Aufgabe lösen kann. Dann wird ein kleinerer Prozessor/µC genomen und die zeitkritische Aufgabe(n) im zugeschalteten FPGA erledigt.
:
Bearbeitet durch Moderator
Fpgakuechle K. schrieb: > Wie sieht es in anderen Bereichen der Industrie aus? Meine Auto-Dashcam basiert auf einem FPGA. Ausser externem Speicher und Spannungsregler kein weiterer Chip, daher wird da ein uC SOC drin sein. Bei der ganzen Internet- und Telefonüberwachung wird man aber reine FPGA bevorzugen.
Lothar M. schrieb: > Genau 100%. > Denn wenn schon ein universeller konfigurierbarer Zustandsautomat aka. > Prozessorkern in das FPGA passt, dann passt logischerweise auch ein für > die selbe Aufgabe speziell optimierter Zustandsautomat in das selbe > FPGA. Nein das glaube ich so pauschal nicht. Denn auf einem uC im FPGA kann man mehr Komplexität abfeiern (die Software) als man in VHDL Beschreibung in das gleiche FPGA bauen kann. Wenn auf dem uC nur ein kleines Programm läuft, dann kann man das direkt als Zustandsautomat beschreiben und es passt ist FPGA. Wenn da aber ein dickes Programm läuft, dann wird der Zustandsautomat auch dick. Das passt dann nicht mehr ins FPGA. Also ab einer bestimmten Softwarekomplexität ist ein uC im FPGA kleiner als der Zustandsautomat den man bräuchte um die Software in Hardware abzubilden.
Gustl B. schrieb: > Wenn da aber ein dickes Programm läuft, dann wird der Zustandsautomat > auch dick. Ich hatte nicht geschrieben, dass ich den bisherigen sequentiellen Code in VHDL beschreiben und parallel implementieren würde. Natürlich würde ich die "Befehlsliste" für meine schlanke "Prozessor-FSM" auch in einem RAM ablegen. Sowas mache ich derzeit auch mit kleinen "Prozessoren": es gibt einen RAM-Block, wo "Befehle" abgelegt werden können, die der "Prozessor" nacheinander abarbeitet. Die "Programmiersprache", also die "Befehle" für diesen Prozessor sind dann im einfachsten Fall nur ein paar Steuerflags, die nacheinander abgefragt und abgearbeitet werden.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Sowas mache ich derzeit auch mit kleinen "Prozessoren": es > gibt einen RAM-Block, wo "Befehle" abgelegt werden können, > die der "Prozessor" nacheinander abarbeitet. Also effektiv implementierst du für jede Anwendung einen Prozessor mit eigenem, angepassten Befehlssatz. > Die "Programmiersprache", also die "Befehle" für diesen Prozessor > sind dann im einfachsten Fall nur ein paar Steuerflags, die > nacheinander abgefragt und abgearbeitet werden. Was mich zu der Frage führt: Wie programmierst du diese Prozessoren? Hast du da einen angepassten Assembler (oder sogar Compiler), oder schreibst du die Hexwerte manuell ins RAM? Gibt's da gebrauchbare Tools? Lothar M. schrieb: > Genau 100%. Ich bin mir relativ sicher, dass der Hardcore in einem Xilinx Zynq nicht in den Chip passen würde, wenn man die SoC-Fläche durch FPGA-Fläche ersetzen würde. Zumindest las ich Gustls Frage so. MaWin schrieb: > Bei der ganzen Internet- und Telefonüberwachung wird > man aber reine FPGA bevorzugen. Warum das? In meiner Welt braucht man für Internet- und Telefonüberwachung einen Netzwerkzugang, und den bekommt man in Software wesentlich angenehmer hin als in VHDL oder Verilog. Außerdem lässt sich mit einem SoC bereits am Überwachungspunkt ordentlich filtern, um Bandbreite und Speicherplatz zu sparen - die KI läuft im FPGA, die Entscheidungsfindung im SoC.
S. R. schrieb: > Ich bin mir relativ sicher, dass der Hardcore in einem Xilinx Zynq nicht > in den Chip passen würde, wenn man die SoC-Fläche durch FPGA-Fläche > ersetzen würde. Erstens das und zweitens wären erreichbare Taktfrequenz und Energieeffizienz nichtmal ansatzweise so gut.
S. R. schrieb: > Ich bin mir relativ sicher, dass der Hardcore in einem Xilinx Zynq nicht > in den Chip passen würde, wenn man die SoC-Fläche durch FPGA-Fläche > ersetzen würde. Zumindest las ich Gustls Frage so. Ich hatte das nur auf die angesprochenen Soft-CPUs bezogen. Ein dedizierter CPU-Kern mit den Strukturen eines FPGAs nachgebaut wird in allen Belangen hoffnungslos unterlegen sein. Ganz voran die Chipfläche. Denn wenn man sich ansieht, wie viele Konfigurationsbits (= einzelne Flipflops) im Routing und in den Logikzellen richtig gesetzt oder gelöscht werden müssen um letztlich 1 Flipflop an die richtige Stelle im Design zu bekommen, dann wird der Flächenbedarf locker auf das zigfache anwachsen. > Also effektiv implementierst du für jede Anwendung einen Prozessor mit > eigenem, angepassten Befehlssatz. Ja. > Hast du da einen angepassten Assembler (oder sogar Compiler), oder > schreibst du die Hexwerte manuell ins RAM? Normalerweise wird die "Arbeitsliste" von Hand reingehackt. > Gibt's da gebrauchbare Tools? Ich habe aber schon mal den Assembler von dort angepasst: https://tams.informatik.uni-hamburg.de/lectures/mikroProj/assem/assem.html Trotzdem wird der Weg schnell steinig... ;-)
Lothar M. schrieb: > Ich hatte nicht geschrieben, dass ich den bisherigen sequentiellen > Code in VHDL beschreiben und parallel implementieren würde. Das würde mich aber mal interesseieren. Es gibt viele Board Demos mit Microblaze bei denen der fast nix macht. Aber es braucht eben doch viel FPGA Platz weil da dann z. B. ein UART mit AXI, die CPU, BRAM, ... verbaut werden. Oft sieht das für mich so aus als könnte man das auch mit ein paar Zeilen VHDL erschlagen und dabei FPGA Platz einsparen. Da würde mich interessieren wie das so in der Industrie ist, also wie oft anteilich lieber eine CPU ins FPGA verbaut wird obwohl man das auch wunderbar mit etwas HDL hätte machen können. Mir ist klar, dass der Weg über die CPU und Software vermutlich schneller geht und kleine FPGAs nicht mehr teuer sind.
Gustl B. schrieb: > also wie oft anteilich lieber eine CPU ins FPGA verbaut wird obwohl man > das auch wunderbar mit etwas HDL hätte machen können. In einem von 10 Designs läuft ein picoblaze. Das wars. Die restlichen Designs sind alle so, dass das FPGA sowas wie ein "Hardwareanbindungs-Coprozessor" ist. Die SW läuft auf einem X86 oder einem i.MX6 im ms Takt mit +-250µs Jitter. Alles, was feiner granuliert oder mit weniger Jitter ablaufen muss, kommt ins FPGA.
Lothar M. schrieb: > Die restlichen Designs sind alle so, dass das FPGA sowas wie ein > "Hardwareanbindungs-Coprozessor" ist. "Glue Logic" genannt. Man muss auch den Entwicklungsaufwand mit zwei Baustellen, H/W & S/W, gegen Stückkosten bei großen Serien beachten. Oder bekommt man die CPUs inzwischen zum gleichen Preis als Zugabe? Bislang hatte man CPU plus Glue Logic getrennt. Insofern ist das schon eine konsequente Integration. Ich komme aus dem Space-Bereich, wo wir solche CPU-Kombinationen wegen der Strahlungsempfindlichkeit (noch) nicht einsetzen können. Anfangs durften die Anti-Fuse-FPGAs von Actel/Matsushita (heute Microchip/Microsemi) verplant werden, mittlerweile auch eingeschränkt Flash-Typen oder RAM-konfigurierbare mit Scrubbing-Technik. Restrisiko bleibt, muss durch Redundanz kleingerechnet werden. Es können auch nicht alle Features wie SERDES, PLLs etc. verwendet werden. Block-RAM ja, aber in Verbindung mit EDACs. Für alles andere TMR. Die Auswahl an FPGAs bleibt für Space übersichtlich. Am meisten verbaut wurde und wird die RTAX-Reihe von Microsemi. Xilinx hat inzwischen ebenfalls RH oder RT im Programm.
Hallo zusammen, letzte Woche habe ich eine Präsentation von Lattice verfolgt. Laut eigener Aussage verkauft Lattice weltweit mehr FPGAs als die restliche Konkurrenz (Xilinx, Intel, Microchip) zusammen. Da Lattice keinerlei SoC-Variante in seinem Produktportfolio führt, sollte der Anteil "reiner" FPGAs dementsprechend immer noch sehr hoch sein. (Hnweis: das Verwenden einer 8 bit-/32 bit Soft-CPU zähle ich hier noch zu einer reinen FPGA-Entwicklung). Mit SoC & ACAP lässt sich Marketing-technisch natürlich mehr herausholen, ist meiner Erfahrung nach aber kein Hochvolumen-Produkt. Gruß
ktorkkelson schrieb: > Laut eigener Aussage verkauft Lattice weltweit mehr FPGAs als die > restliche Konkurrenz (Xilinx, Intel, Microchip) zusammen. Gut möglich. Apple hat (vielleicht immer noch) lange Zeit FPGAs von denen in Macs verbaut. Und sogar in machen iPhones. https://de.ifixit.com/Teardown/iPhone+7+Teardown/67382
Gustl B. schrieb: > > Gut möglich. Apple hat (vielleicht immer noch) lange Zeit FPGAs von > denen in Macs verbaut. Und sogar in machen iPhones. > https://de.ifixit.com/Teardown/iPhone+7+Teardown/67382 Ein Lattice Product Manager meinte, sie machen einen riesen Umsatz im "Second-Source"-Geschäft mit Ersatzdisplays für Apple iPhones. Chinesische Firmen setzen den Lattice Crosslink FPGA ein, um ihre eigenen günstigen Displays als "original" Apple-Displays auszugeben.
Lothar M. schrieb: >> Hast du da einen angepassten Assembler (oder sogar Compiler), oder >> schreibst du die Hexwerte manuell ins RAM? > Normalerweise wird die "Arbeitsliste" von Hand reingehackt. Danke für die Aufklärung. Also hauptsächlich statische Ablaufsteuerung, weniger dynamische Programmsteuerung, weil die bei dir dann extern in einer "richtigen" CPU liegt. Habt ihr über solche SoC+FPGA-Kombinationen nachgedacht, um die Extra-CPU zu sparen? Warum kommen die für euch nicht in Frage? Als gute Gründe fallen mir höchstens "Preis" und "Herstellerabhängigkeit" ein, aber letzteres hat man wegen der Duopolstellung (Xilinx/Altera) sowieso - und bei den anderen Herstellern gibt es die Option nicht.
S. R. schrieb: > SoC+FPGA-Kombinationen Ein interessanter Punkt. So wie ich das sehe gibt es bisher FPGA ganz ohne CPU, dann FPGA mit Soft-CPU und danach dann gleich FPGA mit eingebauter Hard-CPU (SoC). Allerdings ist da ein großer Leistungsunterschied zwischen Soft-CPU und SoC. Also von mir als Laie gefühlt. Das Zwischensegment wie PIC32/STM32 + FPGA bieten weder Xilinx noch Intel. Ist diese Wahrnehmung korrekt?
S. R. schrieb: > Also hauptsächlich statische Ablaufsteuerung, weniger dynamische > Programmsteuerung Ja, der Ablauf wird meist nur beim Konfigurationswechsel nennenswert geändert. > Habt ihr über solche SoC+FPGA-Kombinationen nachgedacht, um die > Extra-CPU zu sparen? Im Grunde nicht ernsthaft. > Warum kommen die für euch nicht in Frage? Weil es keinen SoC mit einem Intel x86 gibt. Na gut, so langsam kommen die ARM Prozessoren in die Designs , aber wenn ich die Leistungsfähigkeit ż. B. eines i. MX6 Quadcores will, dann wird die SoC Luft wieder dünn oder teuer. Und RAM und Flash muss trotzdem außen dran. > Als gute Gründe fallen mir höchstens "Preis" und > "Herstellerabhängigkeit" ein In der Tat wurden schon einige Designs von X nach L migriert, ohne dass die Software geändert werden musste.
:
Bearbeitet durch Moderator
ktorkkelson schrieb: > Gustl B. schrieb: > >> >> Gut möglich. Apple hat (vielleicht immer noch) lange Zeit FPGAs von >> denen in Macs verbaut. Und sogar in machen iPhones. >> https://de.ifixit.com/Teardown/iPhone+7+Teardown/67382 > > Ein Lattice Product Manager meinte, sie machen einen riesen Umsatz > im "Second-Source"-Geschäft mit Ersatzdisplays für Apple iPhones. > Chinesische Firmen setzen den Lattice Crosslink FPGA ein, > um ihre eigenen günstigen Displays als "original" Apple-Displays > auszugeben. Lustig - da ist ja wirklich ein FPGA drinnen. Mir hat das vor Jahren schonmal jemand erzählt, Apple hätte in ihren iPad / iPhones kleine FPGAs für die Displayansteuerung drinnen um flexibel in der Displayansteuerung zu bleiben, damit man sich nicht abhängig macht von einem LCD Lieferanten. Ich habe das damals als Quatsch abgetan, weil ich dachte, dass da eh ein Standard-Interface wie DSI oder LVDS etc. genutzt wird. Ist ja aber doch was dran.
FPGA schrieb im Beitrag #6429997: > Ist ja aber doch was dran. Wird auch in anderen Mobilgeräten verwendet, nicht nur bei Apple. Das ist der Grund warum Lattice bei den ICE40 so verrückt kleine Packages anbietet wie 2x2 mm 36-ball WLCSP mit 0.35mm Pitch...
FPGA schrieb im Beitrag #6429997: > Ich habe das damals als Quatsch abgetan, weil ich dachte, dass da eh ein > Standard-Interface wie DSI oder LVDS etc. genutzt wird. > Ist ja aber doch was dran. Der FPGA wird einfach direkt auf den Camera-Flex gelötet. Dort nimmt er die DSI-Nachrichten entgegen und ersetzt die Display-ID und sendet diese mit der "original" Apple Display-ID an das z.B. iPhone weiter. ;o)
Gustl B. schrieb: > Da würde mich interessieren wie das so in der Industrie ist, also wie > oft anteilich lieber eine CPU ins FPGA verbaut wird obwohl man das auch > wunderbar mit etwas HDL hätte machen können. Es gibt nicht "die Industrie". Je nach Branche gibt es ganz andere Randbedingungen die bei der Systementwicklung mit hinein spielen. Auch bauen verschiedene Hersteller in der gleichen Branche Systeme zum Teil komplett anders. Junge Firmen bauen anders als Alteingesessene. Etc. S. R. schrieb: > Als gute Gründe fallen mir höchstens "Preis" und > "Herstellerabhängigkeit" ein, aber letzteres hat man wegen der > Duopolstellung (Xilinx/Altera) sowieso - und bei den anderen Herstellern > gibt es die Option nicht. Beim Pico-/Microblaze würde ich dir recht geben mit der Herstellerabhängigkeit. Würde ich persönlich genau deswegen nicht wählen, weil ich einer der grössten Potentiale vom Soft-core (Langfristig) verbaue (Ja, ich weiss, es gibt open source compatible Cores, aber dann kann ich ja von Anfang an schon was offenes nehmen). SoCs wie den Zynq baut man ein, wenn man eh schon eine FPGA lastige Firma ist und entsprechen der Wechsel als kleiner Schritt empfunden wird oder wenn es wirklich kleiner, besser, billiger ist als eine getrennte Lösung. Soft-cores habe ich bisher dann angetroffen, wenn ein dicker FPGA für die Hauptfunktion nötig war und dieses Geld eh schon ausgegeben war, dann lässt sich noch etwas sparen (vielleicht). Ich mein, was ersetzt man mit einem Soft-core? Z. B. einen STM32F0.. der 3€ kostet. Wehe ich will richtiges USB oder Ethernet da wird dann die Soft-core Lösung unrentabel im Vergleich. Microcontroller sind einfach sooo billig und wie schon geschrieben wurde ist es auch einfacher Entwickler dafür zu finden. Gustl B. schrieb: > Allerdings ist da ein großer Leistungsunterschied zwischen Soft-CPU und > SoC. Also von mir als Laie gefühlt. Das Zwischensegment wie PIC32/STM32 > + FPGA bieten weder Xilinx noch Intel. Hier noch ein bisschen mehr Marktübersicht (auch zum Zitat von oben): - Microchip SmartFusion und SmartFusion2 mit Cortex-M3, Einzelpreis 15€ bei Mouser (gibts seit 2011 oder so) - Microchip Polarfire SOC mit Quad-core 64 bit Risc-V (early access programm) - Quicklogic EOS S3, Cortex-M4 mit bisschen FPGA drumherum (gerade rausgekommen) - NanoXplore NG-LARGE, Cortex-R5 für Housekeeping etc. in diesem sonst grossen (Space-grade) FPGA.
Nachdem die ARM-Prozessoren massenweise in FPGAs drinne sind, war es eigentlich klar, dass man die dann auch nimmt. Von einer Veränderung der Entwicklung zu reden, halte ich aber für den falschen Denkansatz. Die Menge, an "FPGA-Programmieren", also das, was in die Logik kommt und was IO und Elektronik angeht, bleibt ja dieselbe. Man hat eben das, was davpr als Microcontroller-Technik danaben sass, nun mit drin und muss es mit berücksichtigen. Was man aber sagen muss: Immer mehr nennen das Hineinwerfen fertiger Cores und deren Konfiguration mit einem Baukastensystem "FPGA-Programmieren". Das ist zwar formal korrekt, verstellt aber den Blick auf die Fakten, nämlich dass damit die vormalig so benannten Entwicklungsthemen nicht weniger werden. Ich habe aber den Eindruck, dass heute von den Unkundigen alles in einen Topf geworfen wird und dann das Core-Bauskasten-Basteln zum Kern der Thematik gemacht wird. Dabei ist es eigentlich nichts anderes, als man zuvor händisch mit CoreGen und Megawizzard gemacht hat und das ist der einfache Teil der Entwicklung. Die pauschale Nutzung von Fertigbauteilen führt aber dazu, dass Silizum verschwendet wird, was eigentlich nur bei Kleinserien und Prototypen finanziell tragbar ist, weil die Entwicklung schneller geht. Sobald aber eine Serie hergestellt werden soll, ist die "alte" Technik wieder wichtig. Und es gibt da ein weiteres Problem: Weil immer mehr C-Programmierer in die FPGAs drängen, neigen sie dazu, Lösungen zu erfinden, die eben in Abläufen gelöst werden. Es fehlt das Parallele Denken. Und die Kenntnis über Digitalschaltungen fehlt vollständig. Da kommen dann schon abenteuerliche Lösungen heraus, die extrem aufwändig und umständlich sind. Und schon bei der Baukastentechnik sehe ich, dass der Aufwand für das Konzeptionieren, das Konfigurieren und Einbauen im Aufwand so derat Zeit einnimmt, dass eine einfache Lösung in VHDL, die perfekt angepasst wäre, sogar schneller fertig gewesen wäre. Besonders fatal ist es, wenn erst eine Voreinwicklung mit schneller Bautechnik gemacht wird, bei die Softie-Erstellungstechnik zum Einsatz kommt und dann merkt, dass es kostentechnisch nicht hinhaut und man zuviel Hardware braucht. Dann muss nochmal gebaut werden. Deshalb sehe ich dieses Thema sehr kritisch. Es kommt insgesamt darauf an, dass die Partitionierung der Aufgaben und der Elektronik in FPGA und ARM so vorgenommen wird, dass man dort zielführend in die richtige Niesche kommt und nicht etwa doppelt baut oder sich in die Ecke putzt. Da kenne ich gerade aus der jüngeren Vergangenheit mehrere Firmen, die hart aufgeschlagen sind, weil ihnen dann die ARM Power ausgegangen ist oder die DDR-Banbreite, weil zuviel Multitaksing und zuviel Pufferung drin war, nur - weil man es einfach schnell zusammenstecken konnte und der Erbauer die Erfahrung nicht hat und keine Alternativen sah.
Und ein Satz noch, weil oben Zynq angesprochen wurde: Das sieht sehr bequem aus auf den ersten Blick, aber dieser Universambaustein ist eben in Sachen FPGA und ARM begrenzt. Externe ARMs sind massiv schneller und auch im Deisgnprozess besser austauschbar. Wenn z.B. ein Software ausgebaut wird, kann man eben mal schnell den Prozessor rauswerfen und gegen die schnellere Type austauschen. Dasselbe gilt umsomehr für den FPGA. In nicht wenigen Fällen, in denen wir hart durchgerechnet haben, war der Bau oder der Kauf einer Zusatzplatine, auf denen FPGA und ARM getrennt aufgesteckt waren, nicht nur die leistungsfähigere, sondern auch die billigere Alternative. Hinzu kommt dass die Tollchain für klassische ARMs von ganz anderer Qualtität ist, als der Mix, der sich aus externer EDK + Xilinx-Gedöhns ergibt. Das EDK von Xilinx alleine zu nutzen, also auf Verfikations- und Debug-Funktionen zu verzichten, ist nochmal risikoreicher. Aus Entwicklersicht, sind solche all-inklusive-FPGA-SoCs eine feine Sache, aber als Projektleiter muss man das etwas größer und weiter beschauen. Pflegbarkeit, Prüfbarkeit und Skalierbarkeit sind bei manuell zusammengesetzten Platinen allemal besser. Oftmals ist es ja schon so, dass wir einfache FPGAs ohne Transceiver nehmen, weil die billiger sind und dann die Trans-Funktion mit externen Bausteinen lösen, weil es kaum teurer - elektrotechnisch aber besser ist. Das ist so wie mit dem Ethernet: Wenn du Standard brauchts, nimmst du einen MACPHY im Prozessorsystem. Wenn es schnell und stabil sein soll, einen externen Chip.
Weltbester FPGA-Pongo schrieb im Beitrag #6430971: > Die pauschale Nutzung von > Fertigbauteilen führt aber dazu, dass Silizum verschwendet wird, was > eigentlich nur bei Kleinserien und Prototypen finanziell tragbar ist, > weil die Entwicklung schneller geht. Sehe ich auch so, aber so wird das eben "gelehrt". Nein, ist nicht der richtige Begriff, aber ... sagen wir es so, wenn man als FPGA Neuling aufschlägt, sich ein Board kauft und die Tutorials macht, dann lernt man genau das. Da sollen Bytes über UART empfangen und über 8 LEDs ausgegeben werden? Klar, da nehmen wie einen Microblaze, DDR-RAM, UART mit AXI und einen GPIO-Controller.
Weltbester FPGA-Pongo schrieb im Beitrag #6430985: > Das sieht sehr bequem aus auf den ersten Blick, aber dieser > Universambaustein ist eben in Sachen FPGA und ARM begrenzt. Externe > ARMs sind massiv schneller und auch im Deisgnprozess besser > austauschbar. Wenn z.B. ein Software ausgebaut wird, kann man eben mal > schnell den Prozessor rauswerfen und gegen die schnellere Type > austauschen. Dasselbe gilt umsomehr für den FPGA. Prinzipiell gebe ich Dir recht, aber welche Transferraten schafft man dann noch zwischen ARM und FPGA? Und mit welchem Aufwand an Datenleitungen? Ohne jetzt den Zynq über den grünen Klee loben zu wollen, aber da hat man mit einem Baustein eine Transferkapazität zwischen RAM und Logik von bis zu 3,5 GByte/s (4xHPP@214MHz): http://www.redaktion.tu-berlin.de/fileadmin/fg196/publication/mgoebel_fccm2015.pdf Oder wenn man es etwas langsamer angehen lässt, 1,6 GByte/s (@125MHz): https://dl.acm.org/doi/abs/10.1145/2513683.2513688 Und mal eben schnell den Prozessor oder den FPGA tauschen? Da hast du eine gute Designabteilung zur Hand. Die Betonung liegt hier auf 'eben schnell'. Solche Sprüche kommen i.d.R. von denen, die nicht dafür verantwortlich sind, das der Kram hinterher auch läuft. Duke
Duke Scarring schrieb: > zwischen RAM und Logik Da hängt das RAM aber an den Hardware Speicherinterfaces die dem PS (CPU) im Zynq zugeordnet sind und nicht am PL Teil. Wenn ich das richtig verstanden habe, dann kann man weiterhin auch RAM direkt an den PL Teil des Zynqs hängen ohne den Umweg über den PS Teil. Da limitieren dann irgendwann die verfügbaren IOs.
Gustl B. schrieb: > Da hängt das RAM aber an den Hardware Speicherinterfaces die dem PS > (CPU) im Zynq zugeordnet sind und nicht am PL Teil. Ja, aber über die Multi-master fähigen High-Performance AXI Ports die zum Speicherinterface gehen, kannst du aus der PL heraus direkt aufs externe RAM zugreifen ohne das der ARM was machen muss. (ug585, Seite 27) Wenns noch schneller sein soll kannst du dich vom PL heraus auch an die Cache-coherent Schnittstelle hängen und so kleine Datenmengen ganz schnell dem ARM zur Verfügung stellen (oder umgekehrt).
Weltbester FPGA-Pongo schrieb im Beitrag #6430985: > Und ein Satz noch, weil oben Zynq angesprochen wurde: > > Das sieht sehr bequem aus auf den ersten Blick, aber dieser > Universambaustein ist eben in Sachen FPGA und ARM begrenzt. Externe > ARMs sind massiv schneller und auch im Deisgnprozess besser > austauschbar. Wenn z.B. ein Software ausgebaut wird, kann man eben mal > schnell den Prozessor rauswerfen und gegen die schnellere Type > austauschen. Dasselbe gilt umsomehr für den FPGA. Welcher ARM ist denn massiv schneller? Klar, ein Snapdragon 865, aber ob man den wohl bekommt, wenn man weniger als 1 Mio Stück im Jahr nimmt? So ein i.MX 8QuadMax kostet auch eher mehr als ein kleiner Zynq. Wenn Dir der FPGA im Zynq zu klein ist, dann gibts den auch in deutlich größer, aber natürlich nicht in beliebigen Geschmacksrichtungen.
Nun. schrieb: > Wird auch in anderen Mobilgeräten verwendet, nicht nur bei Apple. > Das ist der Grund warum Lattice bei den ICE40 so verrückt kleine > Packages anbietet wie 2x2 mm 36-ball WLCSP mit 0.35mm Pitch... Aus eigener Erfahrung (Reverse Engineering): Einige Serien von Huawei-Geräten hatten ICE40 verbaut. Damit ist Lattice elegant ins Massengeschäft eingestiegen. Betreffend Embargo durch den vom dümmsten Präsidenten der Welt angeführten Nation musste man allerdings kreativ werden..
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.