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?
Ja, wenn men jetzt Entwickler eines µC ist - dann macht das schon sinn. Sonst aber eigentlich wenig.
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 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?
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
Bitte 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.