Forum: FPGA, VHDL & Co. Rumgefragt: Verwendung 'reiner' FPGA's heute (2020)


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.
von Fpgakuechle K. (fpgakuechle) Benutzerseite


Lesenswert?

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?

: Bearbeitet durch User
Beitrag #6426553 wurde von einem Moderator gelöscht.
von Gustl B. (gustl_b)


Lesenswert?

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
von S. R. (svenska)


Lesenswert?

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.

von Gustl B. (-gb-)


Lesenswert?

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.

von Nun. (Gast)


Lesenswert?

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.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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
von MaWin (Gast)


Lesenswert?

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.

von Gustl B. (gustl_b)


Lesenswert?

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.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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
von S. R. (svenska)


Lesenswert?

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.

von Nun. (Gast)


Lesenswert?

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.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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...  ;-)

von Gustl B. (-gb-)


Lesenswert?

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.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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.

von dfIas (Gast)


Lesenswert?

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.

von ktorkkelson (Gast)


Lesenswert?

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ß

von Gustl B. (-gb-)


Lesenswert?

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

von ktorkkelson (Gast)


Lesenswert?

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.

von S. R. (svenska)


Lesenswert?

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.

von Gustl B. (-gb-)


Lesenswert?

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?

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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
von FPGA (Gast)


Lesenswert?

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.

von Nun. (Gast)


Lesenswert?

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...

von ktorkkelson (Gast)


Lesenswert?

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)

von Christoph Z. (christophz)


Lesenswert?

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.

von Weltbester FPGA-Pongo (Gast)


Lesenswert?

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.

von Weltbester FPGA-Pongo (Gast)


Lesenswert?

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.

von Gustl B. (-gb-)


Lesenswert?

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.

von Duke Scarring (Gast)


Lesenswert?

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

von Gustl B. (-gb-)


Lesenswert?

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.

von Christoph Z. (christophz)


Lesenswert?

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).

von Markus K. (markus-)


Lesenswert?

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.

von Fitzebutze (Gast)


Lesenswert?

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..

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]
  • [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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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