Ich habe mir jetzt mal FPGAs und CPLDs angeschaut. So wie ich das verstanden habe, nimmt man die, wenn man Berechnungen oder Schaltungen in hoher Geschwindigkeit braucht. Aber gibt es auch Anwendungen im Low-Speed Bereich? Also eine Anwendung, die vom Speed her auch ein atmega schaffen würde, aber für die der Profi trotzdem einen FPGA nimmt? Ich weiss, dass ein FPGA bzw. CPLD echt parallel arbeiten kann, während ein µC immer sequentiell arbeitet. Aber gibt es echte Real World Szenarien?
Jan schrieb: > Aber gibt es auch Anwendungen im Low-Speed Bereich? Also eine Anwendung, > die vom Speed her auch ein atmega schaffen würde, aber für die der Profi > trotzdem einen FPGA nimmt? Ich weiss, dass ein FPGA bzw. CPLD echt > parallel arbeiten kann, während ein µC immer sequentiell arbeitet. Aber > gibt es echte Real World Szenarien? Ja.
Spontan fallen mir 2 ein: 1.) Wenn man einen hoeheren Grad an Rekonfigurierbarkeit braucht als es ein uC bieten kann. Z.B. man hat ein Basis Board mit einem FPGA, das man durch Addon Boards generisch halten moechte. Da ist ein FPGA super, da im Gegensatz zum uC die Schnittstellen-Typen an den verschiedenen Pins praktisch frei konfigurierbar sind. 2.) Ein ganz ekliges Szenario das allerdings haeufiger mal vorkommt, vorallem in sicherheitskritischen Anwendungen. Man nimmt einen FPGA anstatt einem uC und spart sich somit in manchen Bereichen (z.B. Medizin) die Softwarezulassung. Der FPGA wird als Hardware Baustein deklariert, Risikomanagment ist zufrieden, abgehakt. Hardware hat ja keine Bugs. Ich persoenlich verteufle das zwar, aber leider wird es gemacht und leider nicht zu wenig. :-(
> im Gegensatz zum uC die Schnittstellen-Typen an den verschiedenen Pins > praktisch frei konfigurierbar sind. Interessanterweise werden Mikrocontroller da auch immer flexibler. > Man nimmt einen FPGA anstatt einem uC und spart sich somit in manchen > Bereichen (z.B. Medizin) die Softwarezulassung. Interessant! Ich haette nicht gedacht das dies moeglich ist. Ich sehe zwischen einem Stueck VHDL und einem Stueck C ueberhaubt keinen Unterschied was die Moeglichkeit angeht da lustige Fehler einzubauen. Ich vermute mal das hat seine Ursache darin das man bei den Hardwaretest davon ausgeht alle Fehler zu finden weil der FPGA sein Verhalten nicht aendert. Wird natuerlich spaetestens dann absurd wenn man eine eigene CPU im FPGA programmiert hat. Olaf
Tobias B. schrieb: > Hardware hat ja > keine Bugs. Nein das siehst du komplett falsch, Hardware hat auch ihre Bugs, Ist aber vorhersehbarer im Zeitverhalten als Software (Stichwort Bitbanging) bis in den ns Bereich und ist oftmals weniger komplex (1k Gatter CPLD versus 100k+ LoC für embedded). Bei vieler Software weiss man garnicht mehr was sie eigentlich alles im Hintergrund tut um trotz GHz-Prozesser bestenfalls im ms-Bereich verlässlich antworten zu können.
Olaf schrieb: > Interessant! Ich haette nicht gedacht das dies moeglich ist. Ich sehe > zwischen einem Stueck VHDL und einem Stueck C ueberhaubt keinen > Unterschied was die Moeglichkeit angeht da lustige Fehler einzubauen. Jep, weswegen ich das auch wirklich verteufle. Evtl. ist das auch einfach historisch bedingt, zu Zeiten als man FPGAs noch nicht wirklich als Kernbaustein im Sinn hatte. Olaf schrieb: > Ich vermute mal das hat seine Ursache darin das man bei den Hardwaretest > davon ausgeht alle Fehler zu finden weil der FPGA sein Verhalten nicht > aendert. Das ist der Punkt weswegen ich sogar behaupten wuerde, dass die FPGA Verifikation aufwendiger ist, als die eines uC Systems. Da man prinzipiell nur Falsifizieren kann, sind gerade Timing Probleme zum Teil sogut wie unmoeglich im Labor zu finden. Wenn der MTBF entstsprechend hoch ist, faellt ein Problem erst im Feld auf, wenn genuegend Geraete draussen sind. Beim uC hat wenigstens der Hersteller mit seinen Moeglichkeiten (hoffentlich) eine entsprechend aufwendige Hardware Verifikation durchgefuehrt, sodass ich mich auf die Verifikation des Codes konzentrieren kann. Olaf schrieb: > Wird natuerlich spaetestens dann absurd wenn man eine eigene > CPU im FPGA programmiert hat. Das gilt dann natuerlich nicht mehr, das bekommst nicht mehr durchgewunken. Da machen auch schon kleine Picoblazes Probleme. Es reicht dann aber den uC Teil getrennt vom restlichen System zu betrachten, zu verifizieren und eine Risikoanalyse zu machen. Logopäde schrieb: > Nein das siehst du komplett falsch, Hardware hat auch ihre Bugs, Ist > aber vorhersehbarer im Zeitverhalten als Software Stimme ich zu, zumindest wird das in der Zulassung so gesehen. In der Praxis ist das jedoch nicht der Fall. Wenn ich sehe dass zum Teil keinerlei Timing Constraints gesetzt werden, dann kann ein FPGA sogar deutlich undeterministischer werden als jeder Prozessor.
Man merkt schon, dass die Luft im Forum dünn wird, wenn man mehr wissen will, als wie man richtig LEDs anschliesst!
Eine weitere Anwendung kann auch Low-Power sein. Mit Low-Power FPGA von z.B. Microsemi oder Lattice kann man durchaus (z.B. kombinatorische) Probleme lösen, bei denen ein Mikrocontroller zuviel Strom benötigt. AVRs gehören da übrigens ganz schnell dazu. Die sind auf MIPS/MHz bezogen nicht sehr effizient.
Wenn du schweineviele I/O Leitungen hast die möglicherweise synchron getaktet werden sollen kommt eigentlich nur ein cpld/fpga in betracht (bis 1000 pins oder so)
Jan schrieb: > Aber gibt es auch Anwendungen im Low-Speed Bereich? Also eine Anwendung, > die vom Speed her auch ein atmega schaffen würde, aber für die der Profi > trotzdem einen FPGA nimmt? Ich weiss, dass ein FPGA bzw. CPLD echt > parallel arbeiten kann, während ein µC immer sequentiell arbeitet. Das "echt parallel arbeiten" Können bringt ja bei Low-Speed Anwendungen die "auch ein ATMega schaffen würde" gar keinen Vorteil. Vorteile bringen hier nur die totale Pin-Konfigurierbarkeit und mögliche große Pin-Anzahl. Im Zweifelsfall ist für Low-Speed jeder Mikrocontroller trotzdem die bessere Lösung weils einfach keinen der raren FPGA-Spezialisten braucht.
Logopäde schrieb: > Tobias B. schrieb: >> Hardware hat ja >> keine Bugs. > > Nein das siehst du komplett falsch Dein Ironiedetektor ist karpott
Axel S. schrieb: > Logopäde schrieb: >> Tobias B. schrieb: >>> Hardware hat ja >>> keine Bugs. >> >> Nein das siehst du komplett falsch > > Dein Ironiedetektor ist karpott Als Entwicklungssingenieur im Sicherheitskritischen Bereich kann man sich keine Ironie leisten. Und im Sinne der Kundenzufriedenheit auch in einer Branche mit weniger lebensgefährdeteb Applikationen auch nicht. Ausserdem ist Lenard grad auf Konferenz und kann nicht immer passende Tipps geben ;-) https://youtu.be/SPmxsRDSmTc?t=110
C.Rotwang schrieb: >Als Entwicklungssingenieur im Sicherheitskritischen Bereich kann man >sich keine Ironie leisten. Und im Sinne der Kundenzufriedenheit auch in >einer Branche mit weniger lebensgefährdeteb Applikationen auch nicht. Nein, als Entwicklungsingenieur im sicherheitskritischen Bereich kann man das Ganze nur mit Zynismus ertragen, wenn man den Unterschied zwischen der Absicht der Formalismen und dem tatsächlichen Sicherheitsgewinn erleben darf.
Tobias B. schrieb: > Der FPGA wird als Hardware Baustein > deklariert, Risikomanagment ist zufrieden, abgehakt. Dann muß man aber schon große Scheuklappen tragen. Das Hauptproblem bei FPGAs ist, daß man sie nach jedem Power-on/-fail erstmal konfigurieren muß. D.h. man braucht eine bombensichere Power-on/-fail Erkennung, die unter allen Umständen das korrekte Laden der SRAM-Zellen absichert. Für hohe Anforderungen nimmt man dazu einen MC, der den FPGA nach dem Laden zurückliest und dann startet. Es gibt auch ganz wenige spezielle FPGAs, die den Flash onboard haben und die SRAM-Zellen zyklisch damit vergleichen.
avr schrieb: > Eine weitere Anwendung kann auch Low-Power sein. Mit Low-Power FPGA von > z.B. Microsemi oder Lattice kann man durchaus (z.B. kombinatorische) > Probleme lösen, bei denen ein Mikrocontroller zuviel Strom benötigt. > AVRs gehören da übrigens ganz schnell dazu. Kannst Du das mal begründen? Die AVRs kann man sehr bequem in Power-Down setzen (<1µA). Mit den Pin-Change-Interrupts wachen sie bei Änderungen an den Eingängen auf, machen ihr Ding und gehen wieder schlafen. Ein Power-Schalter ist überflüssig. Auch brauchen sie keinen stromfressenden Spannungsregler, z.B. an einem Li-Ion-Akku (2,5..4,3V), da Weitbereich (1,8..5,5V).
Peter D. schrieb: > Kannst Du das mal begründen? Muss man das denn? Die Hersteller werden nicht aus Spaß Ultra-Low-Power FPGAs anbieten. Es geht eher um Anwendungen in denen der Mikrocontroller eben nicht zwischendurch schlafen kann. Dann braucht ein AVR gleich ein paar mA. Das kann z.B. bei Logikschaltungen der Fall sein oder bei schnellen Reaktionszeiten. Konkrete Anwendungen hab ich nicht, da ich selbst vor dem Problem noch nicht stand, aber ich weiß, dass es ein Einsatzzweck ist.
avr schrieb: > Dann braucht ein AVR gleich ein paar mA. Nö, beim internen 128kHz Takt sinds typisch 30µA [1,8V]. Außerdem kann man noch einen Vorteiler einschalten und den Idle-Mode nehmen. Der Strom ist weitgehend linear zur Taktfreqenz und im Idle ~30% gegenüber Aktive.
> Nö, beim internen 128kHz Takt sinds typisch 30µA [1,8V]. Das ist ja schon relativ viel. Schaut mal hier: https://www.renesas.com/us/en/solutions/key-technology/sotb/products.html Allerdings brauchst du bei SIL ja mehrere Controller die sich gegenseitig ueberwachen. Da stellt sich die Frage ob man da vielleicht mit einem FPGA auskommen kann weil man da alles aufteilt. Weiss das einer was? Ich denke auch das FPGAs bei Anwendungen im Vorteil sein koennten die zwar sehr Rechnenaufwendig sind, aber nicht oft. Also sagen wir mal einmal pro Sekunde eine dicke FFT und dann abschalten. Da ist es doof wenn der Mikrocontroller 500ms fuer rechnen muss. Olaf
Peter D. schrieb: > Nö, beim internen 128kHz Takt sinds typisch 30µA [1,8V]. Außerdem kann > man noch einen Vorteiler einschalten und den Idle-Mode nehmen. > Der Strom ist weitgehend linear zur Taktfreqenz und im Idle ~30% > gegenüber Aktive. Und bei 128kHz kann er schnell reagieren und hat eine ordentliche Rechenleistung zur Verfügung? Dann nenn mir doch mal eine Lösung für folgendes Problem: Ein externes Signal triggert 1000 mal pro Sekunde eine Berechnung, die durchgeführt werden muss. Die Berechnung besteht aus 8 Instruktionen und muss innerhalb 1us durchgeführt werden. Verfügbare Leistung 50uW. Ein iCE40LP384 schafft das. Es geht bei solchen Anwendungen darum, dass der Mikrocontroller eben nicht mehr richtig schlafen kann, weil die Latenz anders nicht mehr einzuhalten ist oder um Probleme, die ein Mikrocontroller einfach schlecht lösen kann.
Grüße, Disclaimer Nur die Frage vom TO gelesen. Wenn Zeit keine Rolle spielt ist es egal - offensichtlich! Will man Ergebnisse zur Laufzeit aktualisieren?! Maybe gruß, michi (:
Thread beobachten
Seitenaufteilung abschaltenBitte 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.