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