mikrocontroller.net

Forum: FPGA, VHDL & Co. Softcore - was bringts?


Autor: ThE ImAgEr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Manuel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, wenn men jetzt Entwickler eines µC ist  - dann macht das schon sinn. 
Sonst aber eigentlich wenig.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: Matthias G. (mgottke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael Sauron (Firma: www.das-labor.org) (laborsauron)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>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

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rick Dangerus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mine Fields (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ü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.

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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"

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Mine Fields (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 FPGA

Lothar 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?

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.