Forum: FPGA, VHDL & Co. FPGA oder Mikrocontroller?


von Harald F. (hfl)


Lesenswert?

Hallo an Alle!

Neulich hat Karl die Frage in die Runde geworfen, wie man ein 
Modellbauservo mit einem FPGA ansteuern kann und ob das überhaupt 
sinnvoll ist. Recht unisono kam von mehreren Forumsteilnehmern die 
Antwort, dass man so etwas doch eher mit einem Mikrocontroller erledigt. 
Diese Sichtweise würde ich gerne in diesem Thread diskutieren.

Damit das eine interessante Diskussion wird, vertrete ich jetzt mal eine 
etwas radikale These: Warum einen Mikrocontroller und Software nehmen, 
wenn man etwas direkt in Hardware lösen kann? Der üblichen Sichtweise 
"Ich nehme ein FPGA nur dort, wo ich mit meinem Mikrocontroller aus 
Geschwindigkeitsgründen nicht mehr hinkomme" halte ich entgegen "Ich 
nehme Software nur dort, wo eine sequenzielle Bearbeitung notwendig ist, 
z.B. bei der Abarbeitung eines seriellen Protokolls. Alles andere wird 
direkt in Hardware erledigt."

Ich möchte einen Grund anführen, warum meine radikale These sinnvoll 
ist. Software ist einfach um mindestens eine Größenordnung 
fehlerträchtiger als Hardware. Naturlich nicht Software an sich, aber 
die Methode, wie Software entwickelt wird. Man tippt etwas in der IDE 
zusammen, kompiliert in Sekundenschnelle, schaut ob's in der Realität 
geht, und fertig ist die Laube. Nach jeder Änderung wird nur geprüft, ob 
die geänderte Funktion korrekt tut, die anderen Sachen werden nicht mehr 
überprüft, denn das nervt spätestens nach dem dritten Durchgang.

Ganz anders hingegen der Designflow beim Hardaredesign: Dort existiert 
eine Testbench, die das Modell des FPGA in der Simulation verifiziert, 
bevor es überhaupt kompiliert wird. Fehler werden gesucht und auch 
gefunden. Bei Änderungen werden alle ungeänderten Teile genauso intensiv 
geprüft wie die geänderten Teile. Der Regressionstest ist Pflicht.

Dieser ASIC-Designflow ist unschlagbar, und er ist fest mit dem 
Hardwaredesign verbunden. Etwas Vergleichbares gibt es in der Software 
nicht. Würde man Mikrocontroller ohne diesen ASIC-Designflow entwickeln, 
dann würde keiner weiter als drei Befehle nach Reset kommen. Also 
votiere ich dafür, soviel wie möglich in Hardware zum implementieren.

So, und nun verrupft mir mal meine These.

von Dennis (Gast)


Lesenswert?

Harald Flügel schrieb:
> So, und nun verrupft mir mal meine These.

aber gerne, ich werfe mal den ersten Stein: Kosten. uC kostet in Mengen 
fast nichts, C kann jeder Entwickler, Enwicklungszeit sehr kurz... usw. 
Ein FPGA statt uC ist aus der reinen Kostenbetrachtungsebene her selten 
sinnvoll weil zu teuer.

von Valko Z. (hydravliska)


Lesenswert?

Ich beschaeftige mich gerade mit einem MicroBlaze Projekt, wo ich ein 
Simulink IP Core eingebunden habe. Die Daten werden dann per USB 
ausgelesen.

Dafuer ein Simulation zu erstellen ist es mir nicht gelunden(Es gibt 
viele Module die ich zumindest nicht weiss wie ich die simulieren kann).
Die Implementierung bei EDK dauert schon ziemlich lange und ein Hardware 
Fehler zu beseitigen ist schon nicht so einfach. Allein man kommt nicht 
gleich auf die Fehlerquelle.

Wenn man das allein mit ein mC loesen kann ist meiner Meinung nach schon 
Zeitsparrend.

Ich bin trotzdem FPGA fan :)

Gruss,
Valentin

von Andreas S. (andreas) (Admin) Benutzerseite


Lesenswert?

Harald Flügel schrieb:
> Damit das eine interessante Diskussion wird, vertrete ich jetzt mal eine
> etwas radikale These: Warum einen Mikrocontroller und Software nehmen,
> wenn man etwas direkt in Hardware lösen kann?

Weil ein FPGA keine "direkte" Hardware ist. Alles in allem dürftest du 
im FPGA mehr Logik-Overhead haben als mit einem Mikrocontroller. 
Praktisch wirst du das an den Kosten und am Energiebedarf merken.

Selbst gegenüber direkter Umsetzung der Funktion in echte Hardware 
(ASIC) haben Mikrocontroller den Vorteil, dass Logikressourcen wie ALUs 
mehrfach verwendet werden, statt u.U. zigmal nebeneinander zu 
existieren.

Auch wenn automatische Tests auch bei Mikrocontrollern möglich sind, 
grundsätzlich stimmt es natürlich dass die strikte Trennung von 
Funktionsblöcken das automatische Testen erleichtert. Das erkaufst du 
dir aber wie schon gesagt dadurch, dass du eine Menge Logik 
verschwendest indem du z.B. mehrere ALUs realisierst. Sobald du anfängst 
Ressourcen zwischen Funktionen zu teilen, verlierst du den Vorteil der 
Übersichtlichkeit und Testbarkeit gegenüber dem Mikrocontroller.

von Duke Scarring (Gast)


Lesenswert?

Der Testaufwand für FPGA-Designs ist höher und sorgt dort auch für 
bessere Qualität (wenn wirklich getestet wird).
Im Gegensatz dazu ist eine Software schneller entwickelt.

Duke

von Xenu (Gast)


Lesenswert?

Tag Harald,

leider ist Deine These falsch.

"Software ist einfach um mindestens eine Größenordnung
fehlerträchtiger als Hardware."

Nein, ist sie nicht. Software ist bloß fast immer komplexer
als Hardware. Und je komplexer, desto fehleranfälliger.
Hardware, die genauso komplex ist wie äquivalente Software ist
auch genauso fehlerträchtig.

Selbst für Intel-Prozessoren gibt es ja schon eine Ewigkeit
Microcode-Updates - wieso wohl?

Und ein Betriebssystem in Hardware habe ich bisher noch nicht gesehen.

von Marcus H. (mharnisch) Benutzerseite


Lesenswert?

Ich kann meinen Vorschreibern nur beipflichten, dass die Verwendung
eines µC, vor allem aus Kostengründen, aber nicht zuletzt wegen seiner
Flexibilität, Vorteile hat. Brachliegende Logik interessiert mich
weder beim FPGA, noch beim µC, solange die Einflüsse auf Preis,
Geschwindigkeit, und Stromverbrauch vernachlässigbar sind.

Harald Flügel schrieb:

> Ganz anders hingegen der Designflow beim Hardaredesign: Dort existiert
> eine Testbench, die das Modell des FPGA in der Simulation verifiziert,
> bevor es überhaupt kompiliert wird. Fehler werden gesucht und auch
> gefunden. Bei Änderungen werden alle ungeänderten Teile genauso intensiv
> geprüft wie die geänderten Teile. Der Regressionstest ist Pflicht.

Wie Du selber formulierst, hängt es im Wesentlichen vom Designflow ab,
wie zuverlässig ein System verifiziert wird. Du kannst prinzipiell
Software genauso ausführlich testen wie Hardware.

> Dieser ASIC-Designflow ist unschlagbar, und er ist fest mit dem
> Hardwaredesign verbunden.

Warum?

Ausgerechnet den FPGA Bereich als vorbildlich hinzustellen halte ich
hier für sehr gewagt, vor allem wenn man das mal aus der Perspektive
moderner Verifikationsmethodik betrachtet.

Gruß
Marcus

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Andreas Schwarz schrieb:
> Weil ein FPGA keine "direkte" Hardware ist. Alles in allem dürftest du
> im FPGA mehr Logik-Overhead haben als mit einem Mikrocontroller.
Insbesondere, wenn dann noch ein Softcore statt des uCs am werkeln 
ist...

Beim Vergleich uC <-> FPGA gibt es ein
Killerargument gegen FPGAs: Kosten.
Und eines für FPGAs: Geschwindigkeit.

Und für ein Modellbauservo brauche ich keine Geschwindigkeit.

von Entwickler (Gast)


Lesenswert?

> Man tippt etwas in der IDE zusammen, kompiliert in Sekundenschnelle,
> schaut ob's in der Realität geht, und fertig ist die Laube. Nach
> jeder Änderung wird nur geprüft, ob die geänderte Funktion korrekt
> tut, die anderen Sachen werden nicht mehr überprüft,

So kann man "entwickeln", wenn man meint, es geht aber auch anders. Aber 
das ist ein anderes Thema.

Aber die bittere Realität ist doch: In über 80% der Fälle sind 
Mikrocontroller-Programme nur erweiterte Prototypen die nie wieder 
angefasst werden. Die Software läuft in einer kontrollierten Umgebung 
unter immer gleichen Bedingugen. Die Software kann dann voll mit Fehlern 
sein die eben in dieser kontrollierten Umgebung nicht getriggert werden. 
Wenn der Funktionsumfang eines Mikrocontrollers hinreichend klein ist, 
kann man durch einfaches ausprobieren des Produktes schnell feststellen 
ob es "geht" oder nicht.

Von daher: Die Welt ist eben böse. Die technische beste Lösung setzt 
sich sehr selten durch. Stattdessen setzen sich in der Regel die 
pragmatischen Lösungen oder die Lösungen mit dem gerade noch 
toleriebaren Verhältnis von Qualität und Preis durch.

von Harald F. (hfl)


Lesenswert?

Nochmals Hallo an Alle!

Vielen Dank für eure Antworten. Es sind mehr als ich zu hoffen wagte und 
sie sind alle sehr fundiert. Ich hatte mit mehr flaming gerechnet und 
freue mich, dass es das nicht gegeben hat. Gutes Forum!

Ich fasse dann mal kurz zusammen: Der Hauptgrund, eine Aufgabe mittels 
eines Mikrocontrollers und Software zu lösen, sind die Herstellkosten 
einer solchen Lösung im Vergleich zu einer Hardwarelösung im FPGA. 
Außerdem (und jetzt werde ich etwas polemisch) ist das schnell gemacht 
und C kann jeder Depp. Das ist ja genau der Stein meines Anstoßes. 
Embedded Systeme mit einem hohen Anteil an Software werden oftmals nur 
unzureichend getestet. Warum ist das so? Meine These ist, dass der 
Designflow in der Softwareentwicklung für eingebettete Systeme die 
Verifikation einfach nicht vorsieht. Man kann Software durch Augenschein 
testen, und das wird auch gemacht. Hingegen ist in der 
Hardwareentwicklung (und ich unterscheide da FPGA und ASIC nicht) eine 
Testbench unabdingbar, sonst ist man verratzt. Frei erhältliche Tools 
für die Hardwareentwicklung bieten die Möglichkeit der Simulation, diese 
werden genutzt, weil es anders gar nicht geht, wenn die Logik aus mehr 
als zwei UND-Gattern besteht. Wo ist dieses Tool für die Software?

@ Markus: Du schriebst (Zitat): Wie Du selber formulierst, hängt es im 
Wesentlichen vom Designflow ab, wie zuverlässig ein System verifiziert 
wird. Du kannst prinzipiell Software genauso ausführlich testen wie 
Hardware. (Zitat Ende )

Wie? Und wird das auch auf breiter Front gemacht?

Grüße,
Harald

von Verwirrter Anfänger (Gast)


Lesenswert?

Harald Flügel schrieb:
> ... Frei erhältliche Tools
> für die Hardwareentwicklung bieten die Möglichkeit der Simulation, diese
> werden genutzt, weil es anders gar nicht geht, wenn die Logik aus mehr
> als zwei UND-Gattern besteht. Wo ist dieses Tool für die Software?
>

Ich komm nur aus der Softwareecke, und habe mich bis jetzt noch nicht 
viel mit FPGAs, etc beschäftigt, aber Software zu simulieren kommt mir 
ein wenig komisch vor. Letztendlich besteht zwischen der Simulation 
eines Programmes und dem "normalen" Ausführen des Programmes für mich 
kaum ein Unterschied.
Allerdings gibt es für die verschieden Mikrocontroller durchaus 
Simulatoren, z.B. eingebaut im AVR Studio.

Wenn man der Simulation nicht traut, oder es keine gibt, gibt es über 
JTAG, debugWire, etc oft auch andere Möglichkeiten den Ablauf eines 
Programmes zu kontrollieren. Wenn man nur abstrahierte Module testen 
will, dann kann man die teilweise auch auf dem PC ausführen und einfach 
per gdb beliebig viel Unsinn machen.

Unter einer Testbench für Software stell ich mir sowas wie Unittests 
vor. Ich bin zwar kein großer Freund davon, aber wenn man gute 
Modularität hat, kann das einiges bringen. Hierzu gibt es ja mit 
boundary testing und ähnlichen Prinzipien auch ein paar Methoden 
möglichst effektiv zu testen.

Softwareverifikation ist ein riesiger Themenbereich, angefangen bei 
Tools die einem Hilfestellung dazu geben, welche Situationen man genauer 
kontrollieren sollte, über automatische Verifizierung bis hin zu den 
verschiedenen Prozessen und Modellen für den gesamten 
Entwicklungsprozess.

Ich denke das größte Probleme ist das man selbst entscheiden kann, 
wieviel einem ein fehlerfreies Endprodukt wert ist, und oft gibt es 
einen Punkt, wo der weitere Aufwand einfach zu groß wird, oder die Zeit 
nicht mehr reicht.

Wenn es darum geht wirklich fehlerfreien code zu kriegen, würde ich mal 
als erstes zu NASA schauen, die schaffen durchaus mal ein paar 10 000 - 
100 0000 Zeilen code ohne Fehler zu produzieren.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Harald Flügel schrieb:
> Embedded Systeme mit einem hohen Anteil an Software werden oftmals
> nur unzureichend getestet. Warum ist das so?
1. weil man es hinterher sehr leicht wieder ändern kann.
2. es kann nachträglich ohne Probleme geändert werden.
3. es wird sehr gern "nach Bedarf" programmiert, weil
4. die Anforderungen erst im Verlauf des Projekt definiert werden, weil
5. vorher kein anständiges Pflichtenheft erstellt wird.

Der Extremfall:
Ein SPS-Programmierer setzt sich an seine fertig montierte Anlage. Er 
schaltet die SPS ein und legt das zu transportierende Paket auf das 
Band. Jetzt bekommt er erst mal das Band zum Laufen, die SPS muß das 
Band einschalten. Am Ende des Bandes soll das Teil von einem Auswerfer 
weggeschoben werden. Da muß also jetzt erst noch ein Lichttaster 
montiert werden, der diese Aktion auslöst...
So bugsiert der gute Mann Schritt für Schritt sein Paket durch die 
Anlage und wenn das mal funktioniert, dann wird das mit mehreren Paketen 
nacheinander probiert.

> wirklich fehlerfreien code zu kriegen, würde ich mal als erstes zu
> NASA schauen, die schaffen durchaus mal ein paar 10 000 -
> 100 0000 Zeilen code ohne Fehler zu produzieren.


Aber in der 100 0001 Zeile ist dann der Fehler, und damit schmeissen sie 
ihre Sonde gleich mal auf den Mars...
http://www-i2.informatik.rwth-aachen.de/i2/fileadmin/user_upload/documents/PDF-Informationen/vorbesprechung_bugs09.pdf

von D. I. (Gast)


Lesenswert?

Verwirrter Anfänger schrieb:

>
> Wenn es darum geht wirklich fehlerfreien code zu kriegen, würde ich mal
> als erstes zu NASA schauen, die schaffen durchaus mal ein paar 10 000 -
> 100 0000 Zeilen code ohne Fehler zu produzieren.

Wenn man von Überläufen oder Vorzeichenfehlern in der Vergangenheit mal 
absieht ;)

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

In dem von mir geposteten Link
http://www-i2.informatik.rwth-aachen.de/i2/fileadmin/user_upload/documents/PDF-Informationen/vorbesprechung_bugs09.pdf
findet sich dann übrigens auch diese Passage:
1
Korrekte Sprache wird vorausgesetzt:
2
≥ 10 Fehler pro Seite ⇒ Abbruch der Korrektur
Was mir zu Denken gibt, ist dass in der Ausarbeitung zu einem Seminar 
für Softies  "Proseminar Berüchtigte Fehler in Softwaresystemen" in der 
"Software Modeling and Verification Group" pro Seite immerhin 9 Fehler 
erlaubt und als "korrekte Sprache" definiert sind...  :-o

von Marcus H. (mharnisch) Benutzerseite


Lesenswert?

Harald Flügel schrieb:
> @ Markus: Du schriebst (Zitat): Wie Du selber formulierst, hängt es im
> Wesentlichen vom Designflow ab, wie zuverlässig ein System verifiziert
> wird. Du kannst prinzipiell Software genauso ausführlich testen wie
> Hardware. (Zitat Ende )

> Wie?

Prinzipiell genauso wie mit VHDL. Ist ja schließlich auch nur Software 
:-) (war das nicht gerade Thema in einem anderen Thread?)

> Und wird das auch auf breiter Front gemacht?

Natürlich nicht! Aber auch Hardware wird nur soweit getestet wie es 
sinnvoll erscheint. Das ist doch alles lediglich Ergebnis einer 
Kosten/Nutzenanalyse. Selbstverständlich gibt es die theoretische 
Möglichkeit ein Programm formal zu analysieren (Stand der Technik in der 
Hardware Verifikation), oder durch aufwändige Mechanismen mit 
hinreichender Überdeckung zu verifizieren. Ob sich das im Einzelfall 
lohnt ist die Frage. Je leichter mir die Änderung fällt und je geringer 
das Risiko, desto weniger Aufwand stecke ich in die Verifikation. Ich 
habe den Eindruck gewonnen, dass sich das bereits im FPGA Bereich 
bemerkbar macht.

Und, um auf die ursprüngliche Frage zurückzukommen, das Verwenden eines 
FPGA anstelle eines µC mit Software wegen der angeblich sichereren 
Programmierung ist eine klare Verwechslung von Kausalität mit 
Korrellation.

Gruß
Marcus

von zachso (Gast)


Lesenswert?

also, das mit der testbench... na ja. erst mal gibts sowas fuer grosse 
softwareprojekte auch (gcc zum beispiel hat da was) und dann muss das 
auch geschrieben werden, manche leute (auch ich hin und wieder) haben da 
lieber mehr UCF-files wo dann die ausgaenge auf andere pins gehn, 
haengen da einen LA dran und ueberpruefen dann haendisch einfach schnell 
obs ungefaehr passt. richtige tbs werden erst geschriben wenns echt zu 
gross wird oder unuebersichtlich oder die pins des LA nicht reichen...

und ja: professionell geht anders, aber was solls? ich hab auch schon in 
firmen mitgemacht wo einfach chipscope benutzt wurde, das geht auch. nur 
fuer hobby ist das halt zu teuer

von Duke Scarring (Gast)


Lesenswert?

zachso schrieb:
> ich hab auch schon in
> firmen mitgemacht wo einfach chipscope benutzt wurde, das geht auch. nur
> fuer hobby ist das halt zu teuer

Einmal das, und zum Anderen ist das bei Synthesezeiten, die mehrere 
Stunden dauern auch nur noch der Notnagel.

Duke

von Dogbert (Gast)


Lesenswert?

Harald Flügel schrieb:
> Warum einen Mikrocontroller und Software nehmen,
> wenn man etwas direkt in Hardware lösen kann?

Q: Warum überhaupt etwas von Hand tun weil man doch für alles eine 
Maschine entwickeln könnte?

A: Weil vieles von Hand billiger und schneller geht.

von Harald F. (hfl)


Lesenswert?

Nochmals Hallo an Alle!

Ich möchte euch ein weiteres Mal für die profunden Beiträge zu diesem 
Diskussionsfaden danken. Und ich denke auch, wir kommen der Sache so 
langsam auf den Grund.

@ Verwirrter Anfänger (Letztendlich besteht zwischen der Simulation 
eines Programms und dem "normalen" Ausführen des Programms für mich kaum 
ein Unterschied.)
Es geht, das sieht Du völlig richtig, nicht darum, die Ausführung eines 
Programms zu simulieren. Kurz zur Begriffsklärung: Beim FPGA-Design 
„modelliert“ man eine digitale Schaltung und „programmiert“ eine 
Testumgebung dazu, die das zeitliche Verhalten von Eingangssignalen am 
FPGA festlegt und beschreibt, wie das erwartete Verhalten des FPGAs auf 
diese Einganssignale aussehen soll. Das ist mehr als ein Unittest in der 
Software, denn dabei testet man ja „nur“ Units, während das Testprogramm 
für das FPGA das gesamte Design ins Visier nimmt.

@ Marcus (Und wird das auch auf breiter Front gemacht? Natürlich nicht!) 
Und (... ist eine klare Verwechslung von Kausalität mit Korrelation.)
Ich bin offensichtlich nicht gebildet genug, dem Argument zu folgen. 
Nach meinem Dafürhalten ist beim FPGA-Design die Verifikation mittels 
Testbench gang und gäbe, wohingegen in der Softwareentwicklung 
Verifikation per Augenschein Usus ist. Insofern ist allein die Wahl des 
Lösungsansatzes (HW/SW) ein Präjudiz für die Wahrscheinlichkeit von 
Fehlern. Und, um auf den Ursprung der Diskussion zurückzukommen: Karl 
wollte ein Modellbauservo ansteuern. Eine passendere Aufgabenstellung 
für eine softwarefreie Lösung kann ich mir nicht vorstellen.

@ alle
Das Dilemma (und ich sehe hier ein solches) liegt meiner Einschätzung 
nach darin, dass E-Technik-Studenten während ihrer Studienzeit zwar 
Java, C und VHDL gepriesen bekommen, aber wohl zu wenig 
Entwurfsmethodik. Entwickeln ohne automatisierte und wiederholbare 
Verifikation ist Teufelszeug und führt früher oder später ins Verderben. 
Beim Hardware- bzw. FPGA-Design kann man mit kostenlosen Tools eine 
vollständige Verifikation machen und wer mal ein größeres FPGA-Design 
oder ein ASIC-Design gemacht hat, der weiß: Man muss. Ich will ja nicht 
Aufgabenstellungen, die nach einer Softwarelösung rufen, im FPGA 
erschlagen. Mein Credo ist: Lasst der Software, was der Software ist, 
und löst Hardwareaufgaben in Hardware. Mit den modernen Tools ist das 
schnell gemacht, hoch flexibel und dank der Verifikation wenig 
fehlerträchtig.

von Marcus H. (mharnisch) Benutzerseite


Lesenswert?

Harald Flügel schrieb:
> @ Marcus (Und wird das auch auf breiter Front gemacht? Natürlich nicht!)
> Und (... ist eine klare Verwechslung von Kausalität mit Korrelation.)
> Ich bin offensichtlich nicht gebildet genug, dem Argument zu folgen.

Diese Schlussfolgerung hätte ich jetzt nicht getroffen. Deinen 
Ausführungen nach, sollte allein die Wahl des Zielsystems automatisch zu 
einer besseren Verifikation führen. Die Beobachtung unterschiedlicher 
Höhe des Aufwands kann ich natürlich auch machen, teile allerdings nicht 
die Haltung, es handele sich dabei um eine Art Naturgesetz.

Nach Deinen Ausführungen wird der selbe Entwickler ein besser 
verifiziertes Ergebnis allein dadurch erhalten, dass die selbe Aufgabe 
mit einem FPGA gelöst wird, statt mit einem µC.

> Karl wollte ein Modellbauservo ansteuern. Eine passendere Aufgabenstellung
> für eine softwarefreie Lösung kann ich mir nicht vorstellen.

Eine passendere Aufgabenstellung für eine Softwarelösung kann ich mir 
nicht vorstellen :-)

Gruß
Marcus

von Harald F. (hfl)


Lesenswert?

Hallo Marcus,

ja, ich habe tatsächlich die Hoffung, dass ein und derselbe Entwickler 
mit einer Hardwarelösung ein besser verifizierteres Ergebnis abliefern 
wird als mit einer Softwarelösung. Voraussetzung ist natürlich, das die 
Frau oder der Mann echt fit ist, sowohl in HW als auch in SW denken kann 
und die Tools beherrscht. Vielleicht ist da aber auch der Wunsch der 
Vater des Gedankens bzw. der Hoffnung, das kann gut sein. Einige 
Diskussionsbeiträge lassen mich inzwischen ein bisschen zweifeln. Es 
scheint tatsächlich auch professionelle HW-Entwickler zu geben, die 
FPGA-Designs ohne Testbench machen. Hätt ich nicht gedacht.

Komischerweise sind sich alle einig, dass es die NASA nicht bis zum Mond 
geschafft hätte, wenn es damals schon Windows gegeben hätte. Beim 
Anspruch an die Verifikation der selbst geschriebenen Software machen 
die meisten dann aber schnell Abstriche. Ist's vielleicht doch nur der 
Kostendruck und die Tatsache, dass eine Softwarelösung augenscheinlich 
schnell funktioniert?

Wie auch immer. Ich danke euch allen nochmals für die 
Diskussionsbeiträge.

Grüße,
Harald

von Frank B. (foobar)


Lesenswert?

Harald Flügel schrieb:
> Kurz zur Begriffsklärung: Beim FPGA-Design
> „modelliert“ man eine digitale Schaltung und „programmiert“ eine
> Testumgebung dazu, die das zeitliche Verhalten von Eingangssignalen am
> FPGA festlegt und beschreibt, wie das erwartete Verhalten des FPGAs auf
> diese Einganssignale aussehen soll. Das ist mehr als ein Unittest in der
> Software, denn dabei testet man ja „nur“ Units, während das Testprogramm
> für das FPGA das gesamte Design ins Visier nimmt.

Das ist normalerweise nicht so, zumindest kenne ich das nicht so aus der 
Praxis. Man schreibt Testbenchs für einzelne Module des FPGAs, selten 
für das gesamte FPGA, zumindest ich mache das so. Und ich kenne 
Entwickler, die schreiben gar keine FPGA-Testbenchs und wundern sich 
dann darüber, daß sie soviel Zeit damit verbringen, merkwürdigen Fehlern 
per Chipscope und richtigem Scope hinterherzujagen :-)

> Und, um auf den Ursprung der Diskussion zurückzukommen: Karl
> wollte ein Modellbauservo ansteuern. Eine passendere Aufgabenstellung
> für eine softwarefreie Lösung kann ich mir nicht vorstellen.

Wie kommst du darauf? Ein Modellbauservo braucht nur eine relativ 
langsame Signalverarbeitung, da braucht man keinen schnellen 
hochparallelen FPGA.

Und Software kann man auch professionell entwicklen, wie hier bereits 
erwähnt wurde. Unit-Tests, leicht geschrieben mit 
http://sourceforge.net/projects/cppunit/ usw., Simulation der 
Programmlogik durch Hardwareabstraktion auf dem PC mit Regressiontests, 
durchdachte klar strukturierte, objektoriente und dokumentierte 
Entwicklung, sind für mich üblich. Das unterscheidet sich aber nicht von 
FPGAs. Es gibt bei beiden Techniken den Ansatz "programmieren wir mal 
was und probieren solange herum, bis es halbwegs läuft".

> @ alle
> Das Dilemma (und ich sehe hier ein solches) liegt meiner Einschätzung
> nach darin, dass E-Technik-Studenten während ihrer Studienzeit zwar
> Java, C und VHDL gepriesen bekommen, aber wohl zu wenig
> Entwurfsmethodik. Entwickeln ohne automatisierte und wiederholbare
> Verifikation ist Teufelszeug und führt früher oder später ins Verderben.
> Beim Hardware- bzw. FPGA-Design kann man mit kostenlosen Tools eine
> vollständige Verifikation machen und wer mal ein größeres FPGA-Design
> oder ein ASIC-Design gemacht hat, der weiß: Man muss. Ich will ja nicht
> Aufgabenstellungen, die nach einer Softwarelösung rufen, im FPGA
> erschlagen. Mein Credo ist: Lasst der Software, was der Software ist,
> und löst Hardwareaufgaben in Hardware. Mit den modernen Tools ist das
> schnell gemacht, hoch flexibel und dank der Verifikation wenig
> fehlerträchtig.

Eine formale Verifikation von FPGAs ist sehr aufwendig und immer noch 
keine Garantie dafür, daß es am Ende in richtiger Hardware läuft, z.B. 
wenn man bei den Testbenchs asynchrone Signale nicht beachtet oder keine 
zeitaufwendige Gate-Level Simulation durchführt. Ich würde dir 
empfehlen, mal selber etwas per FPGA zu implementieren und dann dasselbe 
in normalen C. Du scheinst da noch nicht viel Erfahrung mit zu haben.

Insgesamt ist es mit FPGAs im allgemeinen viel aufwänder, eine gegebene 
Aufgabe zu implementieren, als per Software. Besser einen schnelleren 
oder besseren Microcontroller kaufen, wenn man keine saubere Ansteuerung 
für den Servoantrieb hinbekommt, oder in Kombination mit einem kleinen 
FPGA oder CPLD, für die Echtzeitaufgaben und die weniger zeitkritischen 
Aufgaben weiterhin per Microcontroller lösen.

Gibt natürlich auch interessante Ansätze, einen Microcontroller in einem 
FPGA zu synthesieren. Wenn sich das von den Kosten des Gesamtsystems her 
rechnet, man also ohnehin einen FPGA braucht, dann kann sowas insgesamt 
eine sehr gute Lösung werden.

von Harald F. (hfl)


Lesenswert?

Hallo Frank,

ich muss Dich enttäuschen. Deine Annahme, dass ich ein Greenhorn in 
Sachen FPGA bin, ist leider falsch. Ich arbeite seit 25 Jahren mit 
programmierbarer Logik, von den schnuckeligen kleinen PALs vom MMI bis 
hoch zu Stratix FPGA mit zigtausenden Logikelementen, ASIC-Design 
ebenfalls mit inbegriffen. Das aber nur am Rande.

Ich bin allerdings davon ausgegangen, dass die von mir und den 
Entwicklern in meiner Umgebung angewandte Methode (Testbench über das 
ganze FPGA) die Regel ist. Wenn ich da falsch liege, dann verstehe ich 
einige eurer Einwände. Dann ist die HW-Lösung wirklich kein Jota besser 
als die SW-Lösung. Ich hoffe aber nicht, dass das wirklich so ist. 
Vielleicht melden sich ja noch ein paar andere Forumsteilnehmer und 
sagen uns etwas über ihre Arbeitsweise.

Mein Aufruf (Macht nur das in Software, wofür man Software braucht) ist 
ja nur dann sinnvoll, wenn Hardware gleichbedeutend mit "besser 
getestet" ist. Das ist meine Grundannahme. Deshalb besser getestet, weil 
es einfach und mit kostenloser Profi-Software machbar ist. Im Falle des 
Modellbauservos nehme ich folgendes an:

Bei einer HW-Lösung wird der Entwickler ein FPGA-Design anfertigen und 
eine Testbench drumrum schreiben, die z.B. automatisch die Periodendauer 
verifiziert und den aktuellen Auslenkwinkel des Servos anzeigt. Dann 
werden Stimuli ersonnen, auf das Design losgelassen, und die in der 
Testbench enthaltenen Vergleiche prüfen die korrekte Reaktion des 
Designs auf die Stimuli. Erst dann wird das Ganze in die Realität 
portiert.

Bei einer SW-Lösung wird sich der Entwickler die Keil IDE nehmen und mit 
dem Configuration Wizard eine PWM zusammenklicken. Dann schließt er das 
Servo an ein EVA-Board an und schaut, ob es sich korrekt bewegt. (Das 
Servo, nicht das Board). Ob er sich bei der Programmierung der PWM 
vertan hat und das Servo nur aus Gutmütigkeit korrekt tut, das wird 
nicht geprüft. Erst der 20-ste Anwender wird den Fehler merken und 
melden. Dann ist der Entwickler aber im Urlaub oder bereits nicht mehr 
in der Firma.

Das sind jedenfalls Erfahrungswerte aus meinem Entwicklerleben. Im 
meiner letzten Firma war es Pflicht, stets eine funktionierende, 
selbsttestende Testbench für sein FPGA-Design zu haben. Top Level, 
versteht sich. Jeder wusste außerdem von den Kollegen, wo die Designs im 
Netzwerk waren. Den ModelSim zu starten, "do test_all.do" einzugeben, 
und damit einen detaillierten Blick in das Design werfen, das konnte 
jeder bei jedem FPGA-Design aller Kollegen. War ich da auf der Insel der 
Glückseligen?

Grüße,
Harald

von Frank B. (foobar)


Lesenswert?

Also eine PWM programmieren sind ja meist nur eine handvoll Register, 
wenn der Microcontroller das unterstützt. Daher Grenzfälle überprüfen, 
ein paar Stichproben innerhalb der erlaubten Grenzen und man kann sicher 
sein, daß es immer läuft. Könnte man sogar einen kleinen Selbsttest 
schreiben, der auf der Zielhardware ablaufen kann, um ganz sicher zu 
sein, daß der Configuration Wizard keinen Mist gebaut hat, oder auch bei 
Neucompilierung mit einer neuen Compiler Version, oder bei neuen 
Chip-Revisionen, noch alles läuft. Da ist man gegenüber FPGAs flexibler, 
da sowas bei FPGAs teure Gatter kosten würde und aufwendiger zu 
implementieren ist. Und solche Tests könnten genauso Pflicht sein, wie 
Testbenchs für FPGA-Designs zu schreiben. Software ist nicht 
gleichbedeutend damit, daß man schludrig entwickeln muss :-)

Wie sieht das bei einem FPGA aus? Ok, du hast eine Testbench, die die 
Fälle testet, die du vorgesehen hast. Bei einem Microcontroller dagegen 
ist die PWM teilweise millionenfach von vielen Anwendern und vom 
Hersteller getestet, in den unterschiedlichsten Szenarien, also eine 
harte IP, auf die man (meist) vertrauen kann. Gerade bei FPGAs habe ich 
schon erlebt, daß die Testbench wunderbar funktioniert, es aber in 
realer Hardware zeitweise aussteigt, weil man z.B. einen asynchronen 
Eingang vergessen hat zu synchronisieren, oder sogar auch schon wegen 
Fehler der recht komplexen Synthesesoftware. Kann sein, daß die richtig 
teuren Tools sowas automatisch erkennen und fehlerfreier sind, Quartus 
und die dazu frei erhältliche Modelsim-Variante gehören nicht dazu.

Hängt aber auch immer vom Einsatzgebiet ab. Eine PWM ist sicherlich auch 
gut per FPGA implementierbar, ein Warenwirtschaftssystem, komplexe GUI 
usw., eher nicht. Ein guter Mix zwischen Software und (programmierbarer) 
Hardware, sofern sinnvoll, macht ein gutes System aus.

Und ja, du hast Glück gehabt, daß Testbenches Pflicht waren. Ist glaube 
gerade bei kleineren FPGA Designs bis Cyclone-Größe (sprich Spartan bei 
Xilinx) vielfach leider nicht üblich.

Was meinst du mit Designs im Netzwerk wiederfinden? Du hast doch 
bestimmt ein Versionsmanagment System eingesetz, mit definierten 
Release-Management usw.? Ich bin ja eher der Software-Mensch und mache 
Hardware nur nebenbei, aber sowas ist bei den Firmen, für die ich 
arbeite, eins der ersten Dinge, die ich aufsetze.

von anwender (Gast)


Lesenswert?

Jetzt kommt es aber auch bei den Testroutinen für die FPGAs darauf an, 
ob sie die Zielanwendung wirklich 100% erfassen. Soll zum Beispiel ein 
Datenstrom decodiert werden, der von der Norm aus bestimmte Freiheiten 
hat, dann müsste man wirklich alle Varianten austesten, die möglich 
sind, und nicht nur die wahrscheinlichen. Und ob sich der Entwickler der 
Testroutinen die Arbeit macht, alle diese Varianten zu modellieren, das 
ist fraglich.
Endeffekt: Ein Produkt, das zwar das Pflichtenheft des Entwicklers 
einhält, aber in der Praxis bisweilen versagt.
Will damit sagen: Fehlerfreiheit bei den FPGAs ist nur innerhalb des in 
sich geschlossenen Designprozesses des Bauteils gegeben. Sagt aber noch 
lange nichts aus, ob sich das Gesamtprodukt in der Praxis bewährt. Und 
letztlich geht es um ein bezahlbares und brauchbares Produkt.

von Zwölflieter (Gast)


Lesenswert?

FPGAs haben immer viel mehr Pins als mit der enthaltenen Logik nutzbar 
sind; überspitzt gesagt. Wo ist der FPGA mit 30 Pins aber der Logik von 
200?

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Zwölflieter schrieb:
> Wo ist der FPGA mit 30 Pins aber der Logik von 200?
Xilinx hatte da die Spartan 3 Familie aufgeteilt in verschiedene 
Untergruppen:
- das Standard S3
- das "LowCost" S3E mit viel Logik (im Vergleich zu den Pins)
http://www.elektronikpraxis.vogel.de/pld/articles/34426/
- das S3A mit viel IO (im Vergleich zur Logik)
http://www.elektronikpraxis.vogel.de/pld/articles/50193/

> Wo ist der FPGA mit 30 Pins aber der Logik von 200?
So ein Ding gibt es nicht, weil es vermutlich keinen Sinn hat. Irgendwie 
brauche ich für eine typische IO-Applikation bei einem FPGA meistens 
alle Pins und bekomme es gerade so "voll"... ;-)

von hitecing (Gast)


Lesenswert?

Harald Flügel schrieb:
> Neulich hat Karl die Frage in die Runde geworfen, wie man ein
> Modellbauservo mit einem FPGA ansteuern kann
Hast Du das nun auch getan?

> "Ich nehme ein FPGA nur dort, wo ich mit meinem Mikrocontroller aus
> Geschwindigkeitsgründen nicht mehr hinkomme"
99% der Welt macht es umgekehrt. Du bist aber oggenbar FPGA Enthusiast, 
da mag das ok sein.

> Ganz anders hingegen der Designflow beim Hardaredesign: Dort existiert
> eine Testbench, die das Modell des FPGA in der Simulation verifiziert,
Das gibt es in der Software nicht?

Hast Du ein Motortestmodell für einen Servomotor? Sowas gibt es in 
MATLAB, in C aber nicht in VDHL.

>Der Regressionstest ist Pflicht
Den gibt es in der Software nicht?

von Jonny (Gast)


Lesenswert?

>99% der Welt macht es umgekehrt.

häääähh?

von Bildverwursteler (Gast)


Lesenswert?

Jonny schrieb:
>>99% der Welt macht es umgekehrt.
>
> häääähh?
Man muss die These von Harald Flügel lesen um den Satz zuverstehen. Es 
geht darum immer einen Mikrocontroller zu nehmen, es sei, denn, man MUSS 
den FPGA nehmen. Schon allein wegen der Kosten des Bauteils stellt sich 
die Frage eigentlich nicht. Alles, was mit einem Controller geht, ist 
auch damit zu realisieren.

Gerade in der Bildverarbeitung muss viel Verifiziert werden und das ist 
in Software schlecht zu machen. Daher ist man auf das Compilieren und 
Testen angewiesen und das geht mit Controllern immer besser. Mam schlägt 
nur allenthalben gegen einen harten Anschlag der sich nur noch in 
Hardware überwinden lässt.

von Michael F. (mfuhrmann)


Lesenswert?

Bildverwursteler schrieb:
> Gerade in der Bildverarbeitung muss viel Verifiziert werden und das ist
> in Software schlecht zu machen. Daher ist man auf das Compilieren und
> Testen angewiesen und das geht mit Controllern immer besser. Mam schlägt
> nur allenthalben gegen einen harten Anschlag der sich nur noch in
> Hardware überwinden lässt.

Das "compilieren und testen" führt aber oftmals durch die ungenügende 
Testabdeckung zur grenzwertigen Qualität von Embedded-Software.

Eigene Erfahrung als Hardwareentwickler in einer Firma mit >1k 
Mitarbeiter:

Der Hardwareentwickler (ich) sieht für ein Design mit einem Cortex-M ein 
Trace-Interface auf der Platine vor, um den Softwerkern das Leben zu 
erleichtern. Effektiv genutzt wird eine blinkende LED und 
"printf-Debugging". Dafür gibt es dann wöchentlich neue 
Softwareversionen, weil man Schritt für Schritt Bugs und anderes 
sonderbares Verhalten entdeckt. Weiterhin war die Software über die 
Jahre so gewachsen, dass viel (ungenutzte) Altlasten mitgeschleift 
wurden, an die sich niemand mehr herangetraut hat.

Fazit von meiner Seite: Meine Hardware war fix und musste zum 
Serienstart fehlerfrei, bzw. ausreichend evaluiert sein, weil ich 
ansonsten in die Hölle gekommen wäre. Diesen "Leidensdruck" gibt es bei 
den meisten Softwerkern nicht, weil man ja nachträglich auch noch 
Updates installieren kann und dadurch die Software beim Kunden reifen 
kann.

von Bronco (Gast)


Lesenswert?

Michael Fuhrmann schrieb:
> Diesen "Leidensdruck" gibt es bei
> den meisten Softwerkern nicht, weil man ja nachträglich auch noch
> Updates installieren kann und dadurch die Software beim Kunden reifen
> kann.

Ich wage mal zu behaupten, daß das von der Qualitätspolitik des 
Arbeitgebers abhängt.
In der Automobilindustrie sind Rückrufe rufschädigend und teuer 
(aufgrund der Menge an Fahrzeugen), egal ob hardware- oder 
softwarebedingt.

von Michael F. (mfuhrmann)


Lesenswert?

Nur, wenn wirklich die K*cke am dampfen ist, kommt es zum Rückruf. Wenn 
bei einem Werkstattbesuch unzählige Megabytes an Softwareupdate ins Auto 
gepumpt werden, bekommt man es nicht so offensichtlich mit ;-)

Wenn man möchte, hat man mit den modernen Controllern genügend 
Möglichkeiten zur Validierung und Fehlersuche, nur wird so neumodischer 
Kram (z.B. Trace, ARM DS-5 Streamline, ...) oftmals nicht genutzt, weil 
man ja schon immer die blinkende LED und die Terminalausgaben per printf 
genutzt hat...

In der FPGA Entwicklung ist das Bewußtsein der Entwickler oftmals 
anders, da es solche Sachen, wie Einzelschritt im FPGA nicht gibt und 
man sich vorher Gedanken machen muss, wie man sein Design vernünftig 
validieren kann.

von Bronco (Gast)


Lesenswert?

Michael Fuhrmann schrieb:
> Möglichkeiten zur Validierung und Fehlersuche, nur wird so neumodischer
> Kram (z.B. Trace, ARM DS-5 Streamline, ...) oftmals nicht genutzt

Ist Trace neumodischer Kram?
Als ich vor 100 Jahren mit 8051 und Hitec-Emulatoren gearbeitet hab, war 
Trace eigentlich Mittel der Wahl ;)

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
Noch kein Account? Hier anmelden.