Wie wir alle wissen kann man in FPGAs auch Mikrocontroller
implementieren, z.B. den Microblaze. Wenn ich mir ansehe wie viele
Ressourcen so ein Controller im FPGA benötigt, kommen in mir immer
Zweifel auf, ob das denn wirklich sinnvoll ist.
Was sind denn typische Anwendungsfälle, wo ein FPGA mit Softcore-uC die
ideale Lösung ist? Könnte da jemand Beispiele nennen?
ThE ImAgEr schrieb:> Was sind denn typische Anwendungsfälle, wo ein FPGA mit Softcore-uC die> ideale Lösung ist? Könnte da jemand Beispiele nennen?
Ob nun ideal oder nicht - jedenfalls sind die Wittig/Welec-DSOs ein hier
nicht ganz unbekanntes Beispiel. Alternative wäre wohl nur, den
Prozessor auszulagern um FPGA-Ressourcen zu sparen.
Käme eigentlich alles in Frage, was aus Performancegründen nicht ohne
FPGA auskommt, aber ein nicht unerhebliches Benutzerinterface hat.
> Wenn ich mir ansehe wie viele Ressourcen so ein Controller> im FPGA benötigt...
Viel ist relativ. Ein Microblaze-Core braucht ca. 10% eines 3S1600E, das
man für Stückzahlen in der Gegend von 10-15EUR bekommt. Der verliert
sich quasi dadrin... Und wenn man sehr spezialisierte HW drumherum
braucht, also ohnehin ein FPGA her muss, spart man sich die extra CPU.
Kommt einfach auf das Problem an ;)
Hier ist noch so ein Beispiel, was mit anderen off-the-shelf-Chips wohl
nicht so gegangen wäre:
http://www.baycom.de/wiki/index.php/Products::netceiver
@ Georg A. (Gast)
>Viel ist relativ. Ein Microblaze-Core braucht ca. 10% eines 3S1600E, das>man für Stückzahlen in der Gegend von 10-15EUR bekommt.
Ein KOMPLETTEN uC mit 32 Bit gibt es heute schon für 1EUR.
> Der verliert>sich quasi dadrin...
Aber der Speicher ist knapp.
>Und wenn man sehr spezialisierte HW drumherum>braucht, also ohnehin ein FPGA her muss, spart man sich die extra CPU.
Die kostet als IC deutlich weniger, und man bekommt ordentlich viel
Flash.
>Kommt einfach auf das Problem an ;)
Ja, aber zu 90% ist eine Soft-CPU nur Spielerei.
MfG
Falk
Es gibt schon noch ein paar weiter Vorteile eine CPU im FPGA zu
plazieren:
- Spart Platz auf der LP und vereinfacht das Layout
- Man kann userspezifische Asemblerbefehle programmieren um
Aufgabenspezifische Probleme schneller lösen zu können.
- Die Anbindung an die im FPGA befindlichen Schaltungsteile sind
wesentlich schneller.
- Man kann auch ein Multi-Prozessorsystem entwerfen, in dem die
Verbindung unter den CPUs sehr schnell ist.
- Kleine 8-Bit CPUs (oder sogar 4-Bit CPUs) benötigen sehr wenige
Ressourcen und sind oft bestens geeignet komplexe FSMs zu ersetzen.
Aber wie schon erwähnt, so eine CPU mit genügend Flash und RAM neben den
FPGA zu setzen würde ich jederzeit bevorzugen wenn es nicht zwingende
Gründe gibt diese im FPGA zu integrieren. In den meisten Fällen spart
man noch nicht einmal, da meist ein externer RAM benötigt wird. Da kann
man dann auch gleich die CPU anstelle des RAMs daneben setzen.
>>Und wenn ... ohnehin ein FPGA her muss, spart man sich die extra CPU.>Die kostet als IC deutlich weniger...
Billiger als Kostenlos ? das wird schwierig
>Man kann userspezifische Asemblerbefehle programmieren
Können ja, wollen nein. Wenn es Zeitkritisch wird, gehört es in den FPGA
teil.
Mein ganz spezieller Liebling ist der Picoblaze, belegt nur 92 Slices.
Ist also extrem Klein und kostet keinen Pfennig
Laborsauron
> Ein KOMPLETTEN uC mit 32 Bit gibt es heute schon für 1EUR.
Schön (die PICs, oder?), aber das ist IMO das Low-End. Das hat auch mehr
Bezug auf die ursprüngliche Bedeutung von uC (also gepimpter 8051) und
weniger die heutige Flexibilität eines Application-Specific-SoC. Aber
was ist, wenn ich für gute Performance bzw. ein vernünftiges OS ein
SDRAM/DDR-Speicherinterface brauche? Wird schon teuerer. Oder PCI? Dann
wirds schon sehr dünn. Oder eben in das Gesamtsystem integrierte HW mit
komplexeren DMA-Maschinen für Data-Acquisition?
> Die kostet als IC deutlich weniger, und man bekommt ordentlich viel> Flash.
Das Flash, das man auf den uCs typischerweise findet, ist auch nicht
riesig bzw. verteuert die CPU ungemein. Für grosse Sachen gehts nur
extern, dann kann ich mir das interne auch gleich sparen.
> Ja, aber zu 90% ist eine Soft-CPU nur Spielerei.
Die richtige Problemanalyse ist entscheidend. Ein Microblaze mit UART,
SRAM und ein paar Leds ist nett, aber nicht produktrelevant. Da kann ich
dann auch wirklich die unzähligen ARMs und 32er-PICs nehmen. Aber kennst
du einen COTS-Chip mit dem das obige NetCeiver-Ding so machbar wäre?
Es hat z.B. einen Vorteil, wenn externe Hardware am FPGA konfiguiert
werden muss. Dann ist die getestete Hardware im FPGA immer gleich. Hier
reicht meisst ein 8bit Softcore aus.
Ein Beispiel ist das LCD display.
Eine andere Anwedung ist, wenn man eine spezielle Auswertelogik benötigt
mit einer standardisierten Schnittstelle. Dann wird die Schnittstelle
wird als Softcore hinterlegt. Dafür gibt es bereits meistens C code und
das alles in VHDL neu zu schreiben wäre mit unter ein zu hoher Aufwand.
Also an Schnittstellen mit einem Datenprotokoll, da macht es Sinn.
Außerdem läßt sich so ein Microblaze in größeren FPGAs sehr schön als
"programmierbarer Debugger" verwenden.
Wenn man alle benötigten Register im Design per Memorymap les- und
schreibbar macht, kann man sehen, ob es im FPGA noch genauso tut, wie im
Simulator.
Rick
Überall, wo sowieso ein FPGA verwendet wird und man relativ wenig
Rechenleistung braucht, kann ein Softcore sinnvoll sein. Schließlich
spart man sich nicht nur den Prozessor, sondern auch durch die
Außenbeschaltung einiges an Bauteilen und Platz auf der Platine. Das
gilt natürlich nur, wenn man externes Flash und Speicher sowieso
braucht.
Wenn man dann sich noch Skaleneffekte zunutze macht, ist der größere
FPGA noch nicht einmal teurer als ein kleiner FPGA. Man bekommt aber
natürlich auch einen Softcore in einen relativ kleinen FPGA. Wenn man
für seine Logik nur einen Bruchteil des FPGA braucht, ist das auch eine
Möglichkeit. Für beide Varianten kenne ich reale Beispiele.
Bei einer professionellen Entwicklung hat man weder Zeit noch Geld für
Spielereien. Die gibts vielleicht im Bastelbereich, aber der macht nicht
die 90% aus, die hier mal in den Raum gestellt wurden.
Es gibt noch eine Reihe von Vorteilen:
- Materialdisposition und Langzeitverfuegbarkeit
Sollte der FPGA einmal nicht mehr zu bekommen sein, so kann bei Auswahl
des richtigen Softcores einfach in die naechst neuere FPGA Architektur
migriert werden, samt CPU.
Das wiegt je nach Firma/Produkt selbst einen Mehrpreis in der Hardware
auf und ob es zu selbigen kommt ist von vielen Faktoren abhaengig und
nicht selten schlaegt der Zeiger pro SoftSPU im FPGA aus...
Vorschreiber haben auch schon Vorteile im Bereich des PCB Platzbedarf
und Routing beschrieben. Daneben kann dann auch ein kleinerer FPGA
ausreichen (Gehaeuse).
Ausserdem koennen deutlich schnellere Anbindungen von CPU und
Pheripherie (im FPGA) erfolgen. So sind Busspeeds innerhalb des FPGAs
von rund 100MHz moeglich. Microcontroller mit aehnlich leistungsfaehigen
Bussen sind spaerlich gesaeht und garantiert nicht im Bereich von <2$
auf dem Board.
Typische Anwendung:
Alles Aufgaben erledigen, welche nicht in einem Taktzyklus abgearbeitet
sein muss, aber der FPGA Entwickler keine Lust oder Zeit hat das in
einer Statemaschine hart zu kodieren...
Gruss
Andreas
> Sollte der FPGA einmal nicht mehr zu bekommen sein, so kann bei Auswahl> des richtigen Softcores einfach in die naechst neuere FPGA Architektur> migriert werden, samt CPU.
Definiere einfach.
> Es gibt noch eine Reihe von Vorteilen:
Aber der absolute Nachteil bleibt die dramatisch schlechte
Ressourcennutzung auf dem FPGA: Selbst wenn das Ding zu 100% voll ist,
liegen garantiert noch 2/3 der darin verbauten Flipflops nutzlos herum
(z.B. weil für einen 32-Bit-Vergleicher etliche LUTs
hintereinandergeschaltet werden...).
Ich würde sagen, man kann alles schönrechnen und sich irgendwelche
Argumente herzitieren, aber für eine richtig breite Anwendung ist ein
FPGA zu schade für einen Softcore...
>>> Wenn man für seine Logik nur einen Bruchteil des FPGA braucht ...
... dann ist das FPGA zu groß.
BTW: so eine ähnliche Diskussion wie hier gibts im
Beitrag "Multicoresystem auf FPGA"
Hallo Lothar,
> Definiere einfach
Eine einfache Migration haengt z.B. davon ab, ob die eingesetzte CPU auf
der gewuenschten Zielarchitektur vorhanden ist.
z.B. ist der Microblaze(und der NIOS) (fuer den Normalsterblichen) nicht
im Source verfuegbar und unter den neuesten FPGAs nicht mehr in allen
aelteren Varianten verfuegbar ( Stichwort Pipelinelaenge), womit ggfls.
latente Bugs in der Software zu Tage treten koennen.
Eine einfache Portierung ist deshalb am ehesten bei Sourceoffenen
Softcores zu erwarten (NULL-Aufwand).
>>> Wenn man für seine Logik nur einen Bruchteil des FPGA braucht ...
... dann ist das FPGA zu groß.
Nicht aber unbedingt teurer, (leichter zu beschaffen, bereits im System
der Firma angelegt, noch ausreichend im Lager...) als die naecht
kleinere Alternative
Es gibt sicherlich oftmals einige Gruende Pro SoftCPU.
P.S. Dein Beispiel mit dem 32Bit Comperator ist im uebrigen ein Argument
PRO SOFT-CPU brauch ich die Resource 32Bit Comperator oder allegemeiner
eine ALU doch nur 1x...
Lothar Miller schrieb:> ... dann ist das FPGA zu groß.
Nein. Wenn du sowieso schon pro Jahr 100k von einem FPGA verbaust, wirst
du für 1k keinen kleineren FPGA einführen, weil der dann teurer ist.
Lothar Miller schrieb:> dramatisch schlechte Ressourcennutzung auf dem FPGALothar Miller schrieb:> ist ein FPGA zu schade für einen Softcore...
Das sind keine Argumente gegen einen Softcore. Was interessiert es mich,
ob man in reiner Hardware eine CPU mit der Hälfte der Gatter umgesetzt
werden kann, wenn der Softcore die Anforderungen meiner Anwendung
erfüllt?
Mal eine Frage am Rande: Wer von euch setzt denn überhaupt professionell
FPGA ein, um zu solchen Schlüssen zu kommen?
Ich setze FPGAs und Softcores "professionell" ein, was auch immer das
heißen mag.
Früher habe ich noch versucht als "main"-CPU irgendeinen AVR für
zweimarkfufzig zu nehmen. Weil eben die FPGA-Ressoursen zu teuer waren.
Mittlerweile ist in jedem Design ein Softcore drin (NIOS). Sei es um
komplexere Statemachines oder auch einfach zum GPIO verwalten.
Für die Entwicklung hat es enorme Vorteile, weil man alles in einem hat
und sich nicht auch noch um den "anderen" Prozessor kümmern muss. Für
die Produktion ist es sowieso praktisch -- ein
Programmierfile/JTAG-Stecker/...
Was ich (noch) nicht mache ist, z.B. ucLinux oder komplexere Sachen auf
NIOS, aber auch das wird bald kommen. Die FPGAs sind ja ehe groß genug.
Sicherlich, ein 400 MHz ARM-Bolide kostet nur 5 Euro oder so und dafür
kriege ich nicht mal Konfigurationsspeicher für ein FPGA, aber den
möchte ich mit Soft-CPUs auch gar nicht ausstechen.
Grüße,
Kest
p.s.: @Falk:
übrigens, dass eine Soft-CPU nur Spielerei ist bin ich gar nicht
einverstanden ;-)
Um mal meinen Senf dazuzugeben :
Ich nutze zwar bisher noch keine SoftCores, habe das aber in Zukunft
vor.
Ich denke das es immer auf den Anwendungsfall ankommt, aber wenn der
FPGA noch genügend Chip-Fläche hat und ein externer Prozessor zuviel
Geld/Platz benötigt würde es sich ja anbieten einen SoftCore zu
verwenden.
Als reinen Ersatz für eine CPU ist ein FPGA sicherlich zu "schade", aber
sobald eigene Logik drin ist die sich nicht auf einem externen Prozessor
abbilden lässt (z.b. VGA-Erzeugung, MiniLA, Pattern-Generator,
Encrypt/Decrypt usw ...) würde die Wahl auch eher auf einen SoftCore
fallen (es sei denn er passt definitiv nicht in den FPGA).
> Mal eine Frage am Rande: Wer von euch setzt denn überhaupt professionell> FPGA ein, um zu solchen Schlüssen zu kommen?
Ich.
Aber der Rechnerkern ist ein (ETX-, Qseven-, COM-Express-)PC, denn
billiger ist Rechenleistung (incl. Peripherie) nicht zu bekommen. Und
auf dem FPGA wird nur spezielle Hardware abgebildet, die entweder
maschinenspezifisch oder ganz einfach tatsächlich so ohne weiteres nicht
erhältlich ist. Aber ich wäre mir nicht zu schade, einen AVR mit auf die
Platine zu setzen, wenn es Sinn machen würde. Diesen uC bekommt nämlich
sogar ein Praktikant nach 4 Wochen Einarbeit programmiert. Bei einem
FPGA wäre ich mir da nicht so sicher.
> Wenn du sowieso schon pro Jahr 100k von einem FPGA verbaust...
So weit reicht es nicht, da gehört ja jedesmal noch eine Maschine dazu
;-)
> ... wirst du für 1k keinen kleineren FPGA einführen, weil der> dann teurer ist.
Klarer Fall von "falsch verhandelt" ;-)
> Das sind keine Argumente gegen einen Softcore.
Garantiert aber auch nicht dafür... :-/
> Es gibt sicherlich oftmals einige Gruende Pro SoftCPU.
Das ja, aber ich habe noch keinen Fall für unsere Hardware gefunden, wo
es sich tatsächlich rechnet. Und zwar unbeschönigt und mit einem
passenden Prozessor als Vergleich (du darfst natürlich nicht einen AVR
gegen einen Microblaze ausspielen...). Und bitte die Lizenzen und
Wartungskosten usw. usf. nicht vergessen (und genausowenig die dafür
nötigen Spezialisten, denn du brauchst neben dem Programmierer auch
einen ausgewiesenen Hardwarespezialisten).
> P.S. Dein Beispiel mit dem 32Bit Comperator ist im uebrigen ein Argument> PRO SOFT-CPU brauch ich die Resource 32Bit Comperator oder allegemeiner> eine ALU doch nur 1x...
Man kann es drehen und wenden wie man will... :-o
BTW: der Platz auf einer Platine ist nur in sehr ausgewählten
Ausnahmefällen wirklich ein Thema.
@ Lothar Miller (lkmiller) Benutzerseite
>BTW: der Platz auf einer Platine ist nur in sehr ausgewählten>Ausnahmefällen wirklich ein Thema.
Im Handy . . .
duckundwech
Falk
Hallo Lothar,
>BTW: der Platz auf einer Platine ist nur in sehr ausgewählten Ausnahmefällen
wirklich ein Thema.
So sehr ausgewaehlt sind die Faelle nun gar nicht mehr, ich betreue
aktuell mehrere Projekte bei denen der Platz einer zus. CPU und eines
potentiell mehrpinnigen FPGAs durchaus DIE entscheidende Rolle gespielt
hat.
Keines davon war ein Handy, wie unser in Deckung gegangener Freund
bereits erwaehnt hat. Ein Board ist sogar mit run 30*40cm doppelseitig
mit FBGAs ebstueckt nicht wirklich klein...
In Anmerkung zu Com-Express und Co (welche ich auch einsetze),
wuerden die heutigen Programmierer nur noch etwas besser Ihr Handwerk
verstehen, so braeuchte man oftmals nicht unbedingt einen x86(Boliden),
sondern wuerde mit einem schlanken 32Bit Risc auskommen...
Fuer ein (Atom) Qseven Modul wirst Du sicherlich um $200 los, da spielt
der FPGA Preis +/- ein paar zehn Dollar keine Rolle mehr. Haette ich
Maschinen fuer die naechsten 10Jahre am Laufen zu halten, so waere mir
ein Environment lieber, dass komplett im HDL Source vorliegt...
Aber der Kunde ist Koenig...
>Und bitte die Lizenzen und>Wartungskosten usw. usf. nicht vergessen (und genausowenig die dafür nötigen
Spezialisten, denn du brauchst neben dem Programmierer auch einen ausgewiesenen
Hardwarespezialisten).
den brauchst Du beim Einsatz eines FPGAs auf jeden Fall. Und den Einsatz
der Der Tools haben selbst meine Studenten in einigen Arbeitstunden
intus.
Im Bezug auf die Kosten, so kommt es darauf an, was fuer eine CPU
eingesetzt wird: Microblaze und NIOS sind hier sicherlich die
Schlechteste Wahl auf TotalCost of Ownership, (jaehrliche Lizenskosten,
kein Source, Synthesefaehigkeit der Netlist in Folgeversionen ungewiss).
Alternativen waeren hier: OPENRISC, MICO32 (Lizensbedingungen gelockert
und im Source vorhanden) u.a.
Hier ergeben sich Folgekosten, wie Sie mit der reinen
Softwareentwicklung vergleichbar sind, sobald im Gesamtsystem eh ein
FPGA vorhanden ist...
Gruss
Andreas