mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik CPLD oder FPGA oder µC?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Jan (Gast)
Datum:

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

Autor: Logopäde (Gast)
Datum:

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

Autor: Tobias B. (Firma: www.elpra.de) (ttobsen)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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. :-(

Autor: Olaf (Gast)
Datum:

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

Autor: Logopäde (Gast)
Datum:

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

Autor: Tobias B. (Firma: www.elpra.de) (ttobsen)
Datum:

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

Autor: Jan (Gast)
Datum:

Bewertung
-9 lesenswert
nicht lesenswert
Man merkt schon, dass die Luft im Forum dünn wird, wenn man mehr wissen 
will, als wie man richtig LEDs anschliesst!

Autor: avr (Gast)
Datum:

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

Autor: Blokus (Gast)
Datum:

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

Autor: Pep (Gast)
Datum:

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

Autor: Axel S. (a-za-z0-9)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Logopäde schrieb:
> Tobias B. schrieb:
>> Hardware hat ja
>> keine Bugs.
>
> Nein das siehst du komplett falsch

Dein Ironiedetektor ist karpott

Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-) Youtube-Video "Sarcasm Sign - The Big Bang Theory HD"

Autor: Bernfried (Gast)
Datum:

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

Autor: Peter D. (peda)
Datum:

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

Autor: Peter D. (peda)
Datum:

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

Autor: avr (Gast)
Datum:

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

Autor: Peter D. (peda)
Datum:

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

Autor: Olaf (Gast)
Datum:

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

Autor: avr (Gast)
Datum:

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

Autor: Micha W. (blackxiiv)
Datum:

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

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]
  • [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.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.