Rumgefragt: Verwendung 'reiner' FPGA's heute (2020)

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.

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.

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.

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.

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

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

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.

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.

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.

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.