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.
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.
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
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.
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
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.
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
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.
> 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.
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
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.
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
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 ;)
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
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
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
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
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.
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.
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
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
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.
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
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.
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.
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?
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"... ;-)
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?
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.
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.
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.
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.