Slide von der diesjährigen FPGA Conference: 84% der FPGA designs werden fehlerhaft ausgeliefert und 70% der FPGA-Entwicklungen liegen hinter dem Zeitplan. Bei aller selbstkritischen Betrachtung, zeigt es IMHO eher das Planungen/Aufwandsabschätzungen sehr unrealistisch sind und bug-freiheit nicht unbedingt ein Kriterium für den Erfolg ist. (Die Angabenwurden zum Anfang eines Vortrages über "Debug/Verification FPGA - Lint" gemacht.)
Angehängte Dateien:
-
AllBuggy.jpg
71 KB
Außerdem sind 100% aller Statistiken, die ich nicht selbst erstellt habe, entweder gefälscht oder frei erfunden.
Bradward B. schrieb: > zeigt es IMHO eher das Planungen/Aufwandsabschätzungen sehr > unrealistisch sind Na ja, das Ergebnis von Scrum halt. Vorher keine Ahnung und dann nachreichen, dazuwünschen, dranflicken. Wenn vorher klar beschrieben wäre, was implementiert werden soll, dann wurde man auch ein Ergebnis in den Händen halten. Früher gab es den Begriff der "eleganten Lösung": Die war dann gegeben, wenn mit minimalem Zeit- und Kostenaufwand die bestmögliche Lösung erzielt wurde. Bei den heutigen Schlipsträgern und Anzugständern ist genau das aber nicht erwünscht, kostet es doch Monate satten Gehalts, wenn ein Problem vorzeitig und womöglich zur Zufriedenheit des Auftraggebers gelöst wird. Unser Land lebt mittlerweile davon, Probleme zu züchten und zu verwalten, anstatt sie erfolgreich zu lösen.
Jaha, früher war alles besser. Da haben wir monatelang Pflichtenhefte erstellt, dann Architekturdokumente geschrieben, darausndann Grob- und Feinspezifikationen abgeleitet. Nach 2 Jahren wussten wir dann ganz genau, dass wir noch 1 Jahr für die Implementierung und ein weiteres für alle Compliance-Tests brauchen würden. Und waren dann auch fast pünktlich. Nach weiteren 2 Jahren war das Produkt dann auch so, wie es der Kunde wirklich haben wollte. Heute sind wir nach einem halben Jahr mit einem MVP auf dem Markt und nach 2 Jahren ist das Produkt etabliert. V-Modell vs Agile halt.
:
Bearbeitet durch User
Bradward B. schrieb: > Slide von der diesjährigen FPGA Conference: > 84% der FPGA designs werden fehlerhaft ausgeliefert und 70% der > FPGA-Entwicklungen liegen hinter dem Zeitplan. Was soll ich mit so einer Aussage/Zahl jetzt anfangen? Ein Marketing-Aufknuepfer fuer eine statische Analyse-Methode? Ansonsten ist das Phaenomen relativ allgemeingueltig auf Software anwendbar, ob V-Modell oder agil spielt vermutlich nicht mal mehr gross die Rolle, es wird halt einfach nicht ausreichend getestet, oder noch besser, der Kunde streicht diese rund 50% an im Projekt allozierter Zeit fuer Testphase weg, damit's weniger kostet. Dazu kommt halt auch noch, dass die HDL-Verifikationsmethoden modernen Testansaetzen 20 Jahre hinterherhinken. Gottseidank gibt es immer noch Firmen, die klassische Meilensteine abfruehstuecken und die Grenzen zwischen Prototyp und Produkt ganz klar definieren. Aber wehe, es rueckt da die naechste Generation ins Management vor...
Bradward B. schrieb: > Slide von der diesjährigen FPGA Conference: > 84% der FPGA designs werden fehlerhaft ausgeliefert und 70% der > FPGA-Entwicklungen liegen hinter dem Zeitplan. Das heißt dass 16% der Impementierungen fehlerfrei sind und 30% der Projekte innerhalb des Zeitplans angeschlossen werden? Von solchen Zahlen kann man hier in der Firma nur träumen. Hier sind alle Projekte hinter dem Zeitplan und in jeder Implementierung findet man den einen oder anderen Bug.
:
Bearbeitet durch User
> Was soll ich mit so einer Aussage/Zahl jetzt anfangen? Die zeigen halt wie gut und zuverlaessig FPGA sind weil 99% aller Anwendungen mit Microcontrollern bei der Auslieferung noch Bugs enthalten. Da sind FPGAs schonmal deutlich besser. :-D > Hier sind alle Projekte hinter dem Zeitplan und in jeder Implementierung > findet man den einen oder anderen Bug. Yep! Aber da braucht man sich gar nicht an die eigene Nase packen. Ich brauch nur ein beliebiges von mir in den letzten 5Jahren gekauftes Geraet, TV, Radio, Handy, Messgeraete, usw anschauen und finde IMMER Bugs. Der Welt war noch okay als es nur maskenprogrammierte Controller gab. Weil da allen vor der Bestellung der Arsch auf Grundeis ging und sie SEHR genau ueber Fehler nachgedacht haben. Heute: Oh koennte ein Bug drin sein? Egal, naechste Firmware... Vanye
Vanye R. schrieb: > Der Welt war noch okay als es nur maskenprogrammierte Controller gab. > Weil da allen vor der Bestellung der Arsch auf Grundeis ging und sie > SEHR genau ueber Fehler nachgedacht haben. Vielleicht auch weil in diese Controller auch einfach nur sehr simple Programme rein passten? So eine heutige Megabytes große Firmware mit Frameworks, RTOS, Protokollstacks hat einfach viel mehr Möglichkeiten für Fehler, gerade auch wenn diese externen Komponenten proprietär sind und man sie nicht prüfen/reparieren kann. Vanye R. schrieb: > Ich brauch nur ein beliebiges von mir in den letzten 5Jahren gekauftes > Geraet, TV, Radio, Handy, Messgeraete, usw anschauen und finde IMMER > Bugs. Auf wie viele Bugs in einem Kfz- Motorsteuergerät oder ABS-Steuergerät (nein, keine Infotainment-Sachen) bist du bisher gestoßen, die dann auch wirklich nicht der Spezifikation entsprechen?
> Auf wie viele Bugs in einem Kfz- Motorsteuergerät oder ABS-Steuergerät > (nein, keine Infotainment-Sachen) bist du bisher gestoßen, die dann auch > wirklich nicht der Spezifikation entsprechen? ABS nutzt man ja wenig, aber jetzt wo du es sagst, ich hab mich letztes bei Regen mal um 360Grad gedreht wegen Aquaplaning, (mir ist aber nix passiert) da hat das System wohl verwirrende Info vom Drehratensensor bekommen und auch die Raeder werden sich mal kurz rueckwaerts gedreht haben und ABS und DSC haben sich bis zum naechsten Motorstart abgeschaltet. Aber sowas mach ich natuerlich nicht jeden Tag. Aber mein Regensensor hat einen lustig Bug. Man kann/muss den ueber einen Hebel einschalten und er macht dann was er soll, also die Scheiben wischen. Macht man das Auto aus und wieder an ist die Funktion weg. Man muss dann den Hebel einmal auf aus und dann wieder auf an stellen damit es wieder geht. Vanye
Vanye R. schrieb: > da hat das System wohl verwirrende Info vom Drehratensensor bekommen Na dann ist es aber kein Software Bug. Vanye R. schrieb: > Aber mein Regensensor hat einen lustig Bug Na das ist aber eine Komfort Funktion
Na, warum heißen die wohl field programmable gate array und nicht factory programmable gate array? „Lass mal erstmal ausliefern. Den Fehler können wir dann im nächsten Release beheben.“
Da kann man natuerlich nicht widersprechen. :-D Vanye
Philip S. schrieb: > Lass mal erstmal ausliefern. Den Fehler können wir dann im nächsten > Release beheben.“ Ich habe schon erlebt, dass komplett funktionslose Geräte ausgeliefert wurden, nur um den vertraglichen Termin einzuhalten. Die ersten Nachfragen kamen aber erst ein Vierteljahr später, solange hat sich der Kunde nicht um seine Lieferung gekümmert....
> Ich habe schon erlebt, dass komplett funktionslose Geräte ausgeliefert > wurden, nur um den vertraglichen Termin einzuhalten. Haha, bei sowas war ich auch mal dabei. (nicht in meiner aktuellen Firma) > Die ersten Nachfragen kamen aber erst ein Vierteljahr später In meinem Fall war der Kunde darüber informiert und wollte das auch so, wegen seltsamer Budget-Regelungen beim Staat...
Niklas G. schrieb: > Auf wie viele Bugs in einem Kfz- Motorsteuergerät oder ABS-Steuergerät > (nein, keine Infotainment-Sachen) bist du bisher gestoßen, die dann auch > wirklich nicht der Spezifikation entsprechen? Ein paar hundert. Kommt halt drauf an, wo man arbeitet.
Michael B. schrieb: > Ein paar hundert. > > Kommt halt drauf an, wo man arbeitet. In Laberstadt können das leicht auch ein paar Tausend werden.
Bradward B. schrieb: > 84% der FPGA designs werden fehlerhaft ausgeliefert und 70% der > FPGA-Entwicklungen liegen hinter dem Zeitplan. Hm, wo kommen denn die Daten genau her ? bzw. wer kennt denn die genauen maturity states aller FPGA-Designs, die so umherschwirren? Abgesehen davon stimme ich dem generellen Tenor der Aussage zu und liefere eine Begründung für die häufigen Zeitüberzüge: Die meisten Planer in dem Bereich sind Projektleiter, die selber nur kurz in dem Thema selber aktiv waren, oft ein fachfremdes Studium hatten, sich das selber beigebracht haben und die Details gnadenlos unterschätzen. Das kennt man. Zu der Bugdichte muss man mal die Frage stellen, wo die denn liegen: In der Umsetzung (würde man ja mit dem Simulator am Arbeitsplatz abfangen können) oder doch eher in den Konzepten und der Zusammenarbeit mit anderen Komponenten? Da heute viel SW obendrauf kommt und hier komplexere Handlungsabläufe eine Rolle spielen, kommt es da auf einen guten (Echzeit-)Systementwurf an. Den können aber viele nicht, weil sie das nie erlernt haben, da "selber reingearbeitet". Das wird auch nicht an allen Unis gemacht. Als Folge liefert da jeder Insellösungen und es bedarf sehr aufwändiger Verifikationen um Probleme zu finden. Oft genug sind die Leute auch nicht in der Lage, die Fälle zu antizipieren und zu modellieren. Dann fällt es eben erst im Betriebsfall beim Kunden auf. Da fehlt es auch einfach ein wenig an der Ausbildung und den Fähigkeiten der FPGA-Systemplaner.
:
Bearbeitet durch User
Fehlerfreie Softwareprojekte gibt es praktisch nicht. Und was den Zeitplan angeht, ist es in der Regel so, daß er anfangs auf zahlreichen unklaren Annahmen beruht, die im Laufe des Projektes geändert werden. Oft werden zwischendurch auch die Anforderungen geändert. Ein gerissener Zeitplan ist selten ein Indiz für mangelhafte Umsetzung, sondern für falsche Einschätzung im Vorfeld.
:
Bearbeitet durch User
>> Ich habe schon erlebt, dass komplett funktionslose Geräte ausgeliefert >> wurden, nur um den vertraglichen Termin einzuhalten. >> Die ersten Nachfragen kamen aber erst ein Vierteljahr später > > In meinem Fall war der Kunde darüber informiert und wollte das auch so, > wegen seltsamer Budget-Regelungen beim Staat... Hm, vielleicht weil manche Projekte über den "Geldmittelabfluss" gesteuert überwacht werden. Da ist irgendwann mal vereinbart wurdendas jedes Quartal xy Mio überwiesen werden und Nachweis über deen Verbrauch (Stundenabrechnung) zu erbringen ist. Wird das Budget nicht über den Mittelabluss wie gaplant entlerrt sorgt man sich über Terminverschiebung ... Terminplanung ist IMHO mehr Werkzeug als leistungs-kennziffer ... die Softwareabteilung muss halt in der Lage sein zeitnah das von der Hardware-abteilung zugeliefrete FPGA-Board zu übernehmen resp. an den µC etc darauf/daran weiterzuentwickeln. Und nicht, das die HW-Abteilung grad mit Produktion und Inbetriebnahme fertig zu sein hat, wenn die SW und andere folgenden Gewerke grad Zeit dafür haben könnten. Liefer-Termine sind IMHO besser als "IST-Wert" denn als "SOLL-Wert" anzusehen.
:
Bearbeitet durch User
J. S. schrieb: > Bradward B. schrieb: >> 84% der FPGA designs werden fehlerhaft ausgeliefert und 70% der >> FPGA-Entwicklungen liegen hinter dem Zeitplan. > > Hm, wo kommen denn die Daten genau her ? bzw. wer kennt denn die genauen > maturity states aller FPGA-Designs, die so umherschwirren? Die stammen wohl von sehr geduldigen Papier; Unis und staatlich nahe Unternehmen erzeugen sowas immer mal wieder, wobei viel Statistik noch aus der Ära stammt in der man die "Softwarekrise" thematisierte, also vor etlichen Jahrzehnten. > Zu der Bugdichte muss man mal die Frage stellen, wo die denn liegen: In > der Umsetzung (würde man ja mit dem Simulator am Arbeitsplatz abfangen > können) oder doch eher in den Konzepten und der Zusammenarbeit mit > anderen Komponenten? ... > Dann fällt es eben erst im Betriebsfall beim Kunden auf. Da > fehlt es auch einfach ein wenig an der Ausbildung und den Fähigkeiten > der FPGA-Systemplaner. Ja, eigentlich sind andere Kriterien im Fokus zu halten: Testabdeckung, Systemkomplexität, Fehlertoleranz Manche Projektleiter gehen davon aus das man fehler "heraustesten" kann, also egal wie "shitty" Spec und Architectur ist, lang genug getestet kriegt man schon Kundenzufriedenheit rein. Andere dagegen setzen eher auf einfache Systeme bei denen nicht viel schief laufen kann und legen die "Architektur" soaus, das im "Brandfall" nicht viel passiert resp. man sich in Sicherheit bringen kann. Beispielsweise "reset" - der Bediener muss in der Lage sein, bei Fehlverhalten der Maschine zügig neu anfangen zu können resp. die Maschine in einen Zustand zu versetzten in der diese auf Benutzereingaben reagiert.
Ich habe mittlerweile einiges an (Software)-projekten begleitet und die größte Gefahr für Terminverzug und Bugs war meistens die Selbstüberschätzung und Verbohrtheit von Entwicklern. Da wird gemauert und Projektpläne werden sabotiert weil man der Meinung ist man wüsste besser was wie und warum implementiert werden soll. Da werden die eigenen Aufwände völlig unrealistisch eingeschätzt und falsche Rückmeldungen an die Projektleitung gegeben. Da werden vorhandene Lösungen ignoriert und einfach weggeschmissen weil einem irgendwas nicht passt oder weil es jemand anderes implementiert hat. Alles schon gehabt, auch ich selber. Manche lernen und werden erwachsen, manche ändern sich nie. Projektleiter sein bei solchen Entwicklern ist dann echt kein Spaß.
Richard W. schrieb: > Projektleiter sein bei solchen Entwicklern ist dann echt kein Spaß Vor allem, wenn man, so wie du, nicht die leiseste Ahnung von Programmieren hat. Die korrekte Antwort, wenn man einen Programmierer fragt, wie lange es dauert, den Fehler zu beheben oder das feature zu implementieren, lautet nämlich 'keine Ahnung, weisst du wir lange die Suche nach der Nadel im Heuhaufen dauert'. Aber so was akzeptieren die dümmsten der dummen Projektleiter ja nicht, also bekommen sie irgendeine Zahl genannt, UND ZWAR MEIST EINE ZU NIEDRIGE, man will den Projektleiter ja nicht verärgern. Und an statt dass der Projektleiter aus Erfahrung die Zeit mit 10 multipliziert (90% schafft man in 10% der Zeit aber die letzten 10% brauchen 90% der Zeit), addiert er optimistisch 5+5+5=10, man muss halt bloss die Peitsche stärker schwingen. Richard W. schrieb: > gemauert und Projektpläne werden sabotiert weil man der Meinung ist man > wüsste besser was wie und warum implementiert werden soll Sie wissen es besser. Dein Projektplan ist das Dumme. Fremder code ist meist so schwer zu verstehen, dass es 10 x länger dauert ihn einzusetzen, als neu zu schreiben. Allerdings nur für die ersten 90% (siehe oben). Die restlichen 10% dauern dann eben wieder, aber da jeder Projektleiter so geil ist gleich Ergebnisse zu sehen, fährt man mit abgelieferten 90% besser. Du bist wirklich ein Paradebeispiel dafür, was in der Softwareentwicklung falsch läuft.
So sehen Bilder aus, die von russischen Spionen kommen, die schnell im Vorbeilaufen noch eben rasch einen Schnappschuss...
Auch wenn das Niveau oben wieder ins unterguertelige absinkt: Lasst die designierten Projektleiter halt einfach das Testen, aber nicht die Vorgabe eines Zeitplans uebernehmen. Dann sind sie immerhin verstaendige Projektleiter. Ein guter Projektleiter wiederum nimmt Ruecksicht auf die Belange aelterer Entwicklerkollegen, die mit modernen Softwaremethoden nicht klarkommen und holt sich notfalls ein paar Human Interfaces dazu, die zwischen retro und Industrie 4.0 die Bruecken schlagen und ab und an eine Runde Eis spendieren. NB: Ich hatte eine Weile lang den Spass, als externer Feuerwehrmann solche kraenkelnden Projekte zum Abschluss zu bringen, damit keine dicken Konventionalstrafen eines riesigen A-Konzerns faellig wurden. Wirklich, viele Probleme loesen sich mit einer Runde Eis, und damit, dass bestehende Hierarchien/Blockaden durch die Externen umgangen werden koennen. Alles andere ist einfach nur polemisches Gelaber aus dem Frustrationsbuero/Besserwisseretage, mit Verlaub. Viel mehr wuerde mich interessieren, wer noch ausgiebig statische Code-Analyse a la lint in der HDL benutzt, reicht jetzt aber auch wieder mit der Trollwiese.
Vanye R. schrieb: > Aber mein Regensensor hat einen lustig Bug. Man kann/muss den ueber > einen Hebel einschalten und er macht dann was er soll, also die Scheiben > wischen. Macht man das Auto aus und wieder an ist die Funktion weg. Man > muss dann den Hebel einmal auf aus und dann wieder auf an stellen damit > es wieder geht. VW, oder? Meiner macht das auch.
Martin S. schrieb: > Human Interfaces dazu, die zwischen retro und Industrie 4.0 die Bruecken > schlagen Sowas wie RFC 1149?
> VW, oder? Meiner macht das auch.
Noe, BMW. Aber vielleicht kommt ja beides von Bosch oder so...
Vanye
Mein alter Citroen, den ich kürzlich nach 16 Jahren verkauft habe, hatte das selbe Feature mit dem Regensensor. In der Werkstatt hatte mir einmal jemand erklärt das sei Absicht, damit sich der Fahrer nicht erschreckt, wenn plötzlich unerwartet der Scheibenwischer anspringt...
Vancouver schrieb: > In der Werkstatt hatte mir einmal > jemand erklärt das sei Absicht, damit sich der Fahrer nicht erschreckt, Vielleicht um den Fahrer vor Regressansprüchen von AnDerAmpelUngewolltScheibenPutzern zu schützen, wie man sie in manchen Ländern sieht?
Bei meinem VW (BJ 2016) funktioniert der Regensensor immer, der wird nur in der Waschanlage ausgeschaltet. Er hat aber einen anderen lustigen Bug: Um von Stellung "P" des Automatikgetriebes wegezuschalten, muss man auf der Bremse stehen. Das funktioniert auch. Löst man die Bremse aber dann zu früh, dann fährt das Auto schlicht nicht los, weil es nicht einkuppelt. Sieht immer blöd aus wenn man Gas gibt und nicht vom Fleck kommt. Nochmaliges Bremsenbetätigen hilft dann.
Klaus schrieb: > Das funktioniert auch. Löst man die Bremse aber dann zu früh, dann fährt > das Auto schlicht nicht los, weil es nicht einkuppelt. Sieht immer blöd > aus wenn man Gas gibt und nicht vom Fleck kommt. > Nochmaliges Bremsenbetätigen hilft dann. ... und löst beim Hintermann Panik aus ;)
Markus F. schrieb: > und löst beim Hintermann Panik aus Wieso? Ist es so überraschend, dass jemand auf dem Parkplatz stehend die Bremse betätigt?
Nemopuk schrieb: > Markus F. schrieb: >> und löst beim Hintermann Panik aus > > Wieso? Ist es so überraschend, dass jemand auf dem Parkplatz stehend die > Bremse betätigt? Auf dem Parkplatz stehend nicht. Aber durch die Waschanlage geht man ja normalerweise auf N und muß am Ende erst auf die Bremse, um nach D zu kommen und loszufahren. Das kann durchaus den Hintermann etwas überraschen.
Das wichstige wäre, dass man Fachfremde und Amateure vom Projekt möglichst lange fernhält. Es braucht nur ein oder zwei Profis. Die machen 99% der Arbeit. Das Preisschild draufpappen kann dann der BWLer.
Bradward B. schrieb: > Slide von der diesjährigen FPGA Conference: > 84% der FPGA designs werden fehlerhaft ausgeliefert und 70% der > FPGA-Entwicklungen liegen hinter dem Zeitplan. Das wundert nicht, bei der Masse, die sich heute FPGA-Entwickler schimpft. Meistens Autodidakten, die aus der C-Ecke kommen und von Elektronik nichts verstehen. Digitaltechnik haben sie nicht erlernt, kennen die Mechanismen nicht und programmieren state machines. Dann arbeiten sie viel mit Code-Generatoren und wundern sich, daß nichts zusammenpasst und die Elektronik nicht spielt.
Rolf schrieb: > wundern sich, daß nichts > zusammenpasst und die Elektronik nicht spielt. Was nicht "spielt" wird nicht verkauft. Es gelangt aber jede Menge Zeug in den Handel, das nicht zuverlässig funktioniert.
> Das wundert nicht, bei der Masse, die sich heute FPGA-Entwickler > schimpft. Meistens Autodidakten, die aus der C-Ecke kommen und von > Elektronik nichts verstehen. Kann man IMHO gut unterscheiden, bei Personen mit Elektrotechnik Abschluß stehen die Chancen gut, das sie gut FPGA-Projekte "können", bei denen mit "Informatik"-Abschluß deutlich ungünstiger, etwas besser falls man sich auf "Technische Informatik" spezialisiert hat. Altersmäßig eher die beruflich Etablierten (35+), ob man jetzt FPGA's im Selbstversuch gelernt hat oder es in Schulung, Uni vorgekaut bekommen hat ... ... da kennt sich nach meiner Erfahrungen der "Praktiker" besser aus. Da FPGA-Methologie relativ neu ist, ist die Vorbereitung durch ein Hochschulstudium eh nicht so "umfassend", Autodidaktisch erworbene Wissensteile oder "training on the job" eher besser oder gar unverzichtbar.
Niklas G. schrieb: >> und programmieren state machines > Was nutzen denn die Experten statt State Machines? Endliche Automaten, aber die gibt es nur auf deutsch. :-)
:
Bearbeitet durch User
100% meiner Programme sind State Machines. Seit 43 Jahren.
Tja, die Leute Bradward B. schrieb: > mit "Informatik"-Abschluß wissen dass alle digitalen Computer und FPGAs endliche Automaten sind, da sie alle nur endlich viel Speicher haben...
Niklas G. schrieb: > Was nutzen denn die Experten statt State Machines? Man kann eine Aufgabe parallel als Baum verteilen oder nacheinander abarbeiten. Ich sehe immer mehr Rechnungen von FPGA-Entwicklern, die die Aufgaben zyklisch mit einer FSM abarbeiten, also nacheinander. Es ist ihnen nicht bewusst, daß dann dort alle Teile nur einmal aktiv werden, aber trotzdem immer zu allen Zeiten vorhanden sind. Viele dieser Rechnungen lassen sich als Sequenz formulieren. Allerdings muss man dann auf die Verzögerungen in den Pfaden achtgeben, dass sie passen. Allein die Pfade in MATLAB reichen dann nicht. Daher machen sie es gerne automatisch. Leider kann der Automat (MATLAB) das nicht immer perfekt und man baut es zweimal: Beitrag "Re: Effizienz von MATLAB und HLS bei VHDL" Diese dort beschriebene Aufteilung der Aufgaben in Planer, Systemingenieur, Umsetzer und Programmierer ist dann auch ein starker Grund für den (thread Titel) "Projektverzug".
Rolf schrieb: > die die Aufgaben zyklisch mit einer FSM abarbeiten, also nacheinander. > Es ist ihnen nicht bewusst, daß dann dort alle Teile nur einmal aktiv > werden, aber trotzdem immer zu allen Zeiten vorhanden sind. Aha, aber State Machines sind an sich dennoch nicht verkehrt. Ich kann mir auch nicht so ganz vorstellen warum Informatiker etwas unnötig in Schritte aufteilen würden, Kombinatorik ist ja normalerweise bekannt.
IMHO recht Interessierte Diskussion um die FSM-Implementierung, hab dieses Teithema mal in einen extra thread abgespaltet: Beitrag "Unterschiede Implementierung FSM (Zustandsautomat) in µC und FPGA"
Rolf schrieb: > Man kann eine Aufgabe parallel als Baum verteilen oder nacheinander > abarbeiten. Ich sehe immer mehr Rechnungen von FPGA-Entwicklern, die die > Aufgaben zyklisch mit einer FSM abarbeiten, also nacheinander. Es ist > ihnen nicht bewusst, daß dann dort alle Teile nur einmal aktiv werden, > aber trotzdem immer zu allen Zeiten vorhanden sind. Vielleicht sollte man mal ueber einen generellen Paradigmenwechsel nachdenken und zum Aspekt einer moeglichst generischen, a priori Target-agnostischen Beschreibungssprache von der Unterscheidung HW/SW wegkommen. Oder mal anders, was das eigentliche Thema angeht, im Sinne eines optimalen Workflows: - Der kreative Akademiker prototypt den Algorithmus in Python/Julia/Matlab, etc. - Der Umsetzer macht daraus die 'synthetisierbare' Beschreibung - Das Framework setzt die Beschreibung in die Zielsprache/Logik um - Die Verifikation ist moeglichst automatisiert Es obliegt dem Umsetzer, einen seriell notierten Algorithmus in eine Form zu bringen, aus dem entweder eine Pipeline oder eine FSM, oder eine C(++)-Routine generiert wird. Leider macht es die klassische 'HLS' anders, und scheitert schon an einfachen Algorithmen. Und wenn sie nicht scheitert, bleibt noch ein riesiger Berg an Verifikationsarbeit und muehsamer Co-Simulation, nicht zuletzt Optimierung auf Hardware-Randbedingungen. Aus klassischer HDL-Sicht ist es extrem muehsam, eine Rechenaufgabe beliebig zu multiplexen, also im Graubereich zwischen voll-FSM und voll-pipelined zu arbeiten. Gerade wenn man die Resourcen voll ausnutzen oder die Anzahl schon vordefinieren will/muss (wie z.B. harte Multiplier), schreibt die HDL-Coderin je nach Zielarchitektur ihren Code um und verifiziert ihn abermals. Seltenst sieht man hier die flexiblen Microcode-Ansaetze von der HDL-Seite, das machen die SW-Cracks die Nvidia gut kennen typischerweise besser. Die steuern auch als Berater die Projekte jeweils so, dass sie nicht zu den 70% des Ursprungsthreads fuehren.
> Vielleicht sollte man mal ueber einen generellen Paradigmenwechsel > nachdenken und zum Aspekt einer moeglichst generischen, a priori > Target-agnostischen Beschreibungssprache Hm, Agnostiker sind doch "Leugner", also will man Lösungsansätze (für eine bestimmte Zielarchitektur(Target)) die das Target an sich verleugnen resp. ignorieren ?! Ob so ne Haltung auf Dauer gut geht, irgendwann ist man doch beim Target. Man kann es auch vorsichtiger formulieren, ein Agnostiker ist einer der annimt das es kein "Target" geben könnte. Oder alle Individuen so behandelt als wäre sie nur eine Drohne von vielen (siehe Borgs).
Niklas G. schrieb: > Was nutzen denn die Experten statt State Machines? eine klassische elektronische Aufgabe mit µC hat trotzdem viel Kombinatorik bzw. parallele Aufgaben, die mit Gattern (Glue-Logic) oder analogen Schaltungen realisiert werden. Der SW-Entwickler "kümmert" sich somit "nur" um die FSM. Mit FPGAs statt µC kann eine großer Teil der Glue-Logic entfallen. Es könnte auch ein großer Teil der FSM durch Kombinatorik ersetzt werden. Die Ansätze sind aber so verschieden, dass dies für autodidaktische Programmierer nicht offensichtlich ist. Der Unterschied ist vielleicht ähnlich groß wie zwischen Funktionaler- und Imperativer Programmierung
Bruno V. schrieb: > eine klassische elektronische Aufgabe mit µC hat trotzdem viel > Kombinatorik bzw. parallele Aufgaben, die mit Gattern (Glue-Logic) oder > analogen Schaltungen realisiert werden Gerade kombinatorische Logik lässt sich wunderbar im Mikrocontroller umsetzen sofern man keine extremen Anforderungen an die Geschwindigkeit/Latenz hat. Bruno V. schrieb: > Es könnte auch ein großer Teil der FSM durch Kombinatorik ersetzt werden Klingt eher als sei eine FSM von Anfang an verkehrt gewesen. Was würde man im Mikrocontroller als FSM umsetzen das man dann im FPGA kombinatorisch machen würde?
Bradward B. schrieb: > Hm, Agnostiker sind doch "Leugner", also will man Lösungsansätze (für > eine bestimmte Zielarchitektur(Target)) die das Target an sich > verleugnen resp. ignorieren ?! > > Ob so ne Haltung auf Dauer gut geht, irgendwann ist man doch beim > Target. Auf der Modellierungsebene ignoriert man die Target-Architektur in der Tat, aber verleugnet sie nicht. Das ist leider bei den klassischen HDL so richtig mangelhaft, sie sind zwar gewissermassen befreit von Package/Timing-Constraints, aber mit `pragma`s und `attribute`s wieder nonportabel. Also schreibt man je nach Architektur V*-HDL im duemmsten Fall aufwendig um. Der Target-Kram braucht einfach mehr Abstraktion. Oder die klassischen Faelle mit Reset-Verdrahtung, Initialwerte (ASIC vs FPGA), oder Zaehler - letztere ein gutes Beispiel, wo eine Abstraktion sehr viel Sinn macht anstatt eine `c <= c + 1` Notation. Schlussendlich ein Softwareproblem von: - Notation - Transpilation in eine HDL, C, CUDA-Pipeline, usw.
Niklas G. schrieb: > Was würde > man im Mikrocontroller als FSM umsetzen das man dann im FPGA > kombinatorisch machen würde? Eine Multiplikation kann man kombinatorisch in einem Takt realisieren, oder in n Schritte zerlegen, mit n = z.B. Anzahl der Bits oder Anzahl der Bytes. Ähnlich bei vielen Arten von Switch/Case.
Bruno V. schrieb: > Eine Multiplikation kann man kombinatorisch in einem Takt realisieren, > oder in n Schritte zerlegen, Ja, aber das würde man auf dem uC wohl kaum in Software als FSM implementieren. Selbst wenn man einen uC ohne Hardware Multiplikation hat und diese in Software umsetzt würde wohl keiner auf die Idee kommen das 1:1 nach HDL zu portieren. Außerdem würde ich das nicht als FSM bezeichnen, weil aus "Code-Sicht" alle Zustände gleich behandelt werden, das ist eher eine Schleife, die man nicht naiv 1:1 portieren würde. Bruno V. schrieb: > Ähnlich bei vielen Arten von Switch/Case. Ja aber das heißt hier erstmal nix. Wenn man Switch-Case nutzt um eine FSM zu implementieren die eine Anlage zwischen verschiedenen Zuständen umschaltet (Aus-Standby-An-Fehler...) und in Abhängigkeit vom Zustand verschiedene Dinge tut, kann man das in HDL eigentlich nur genau auch so umsetzen - Kombinatorik alleine kann den Zustand nicht modellieren. Also mir fehlt hier ein konkretes Beispiel für etwas, das man auf dem Mikrocontroller als FSM implementieren würde, aber im FPGA als Kombinatorik. Und eben wirklich als FSM im Code (z.B. eine Funktion mit Switch-Case die als Reaktion auf irgendein Ereignis aufgerufen wird), und nicht einfach eine Schleife die mehrere gleichartige Schritte direkt (!) hintereinander abarbeitet wie bei Software-Multiplikation, Vektor-Multiplikation für DSP o.ä.
:
Bearbeitet durch User
> Auf der Modellierungsebene ignoriert man die Target-Architektur in der > Tat, aber verleugnet sie nicht. Das ist leider bei den klassischen HDL > so richtig mangelhaft, sie sind zwar gewissermassen befreit von > Package/Timing-Constraints, aber mit `pragma`s und `attribute`s wieder > nonportabel. Also eher "Abstraktion" ?! > Also schreibt man je nach Architektur V*-HDL im duemmsten Fall aufwendig > um. Man schreibt ne zweite architecture zu der man mit ner "for -use" clause wechseln kann. Es liegt halt IMHO daran, das manche eben nicht wissen, das es für das gleiche Problem unterschiedliche Implementationen gibt die auch auf dem selbsen chip unterschiedlich groß und schnell sein können. So muß ein Zähler nicht stur 8-7-6-5-4-3-2-1-0 rattern (binary), es könnte auch 256 - 128 - 64 - 32 - 16 - 8 -4 - 2 - 1 - 0 sein (shift register), halt eben deterministisch undidentifizierbar (unterscheidbare Elemente mit definierte Abfolge). Aber soviel Abstraktion ist oft zuviel verlangt.
:
Bearbeitet durch User
Moin, Naja. Von dem, was ich so in meiner Umgebung mitgekriegt habe, oder selbst an Problemen hatte, kann ich eher nicht bestaetigen, dass der Gesamterfolg/Misserfolg zum Grossteil am Aufbau von FSMs oder Zaehlerdesign liegt. Alleine schon das Beschraenken auf die FPGA-Entwicklung ist fuer die Praxis eher negativ, es sei denn, man verkauft IP-Cores. Was aber wohl eher wenige machen. Ich vermute ganz stark, dass die grosse Masse an Projekten halt auch ein FPGA beinhaltet. Und da ist's fuer den Erfolg des Ganzen imho deutlich wichtiger, dass eher so Design-Geschichten passen, also SW-Entwickler, HW-Entwickler, FPGA-"Programmierer" :-) und Layouter extrem gut zusammenarbeiten und nicht jeder am liebsten dem anderen evtl. Mehrarbeit zuschustern will, um selbst weniger Stunden aufs Projekt buchen zu koennen. Auch die Verteilung: wer macht was in Software, was wird ins FPGA gegossen, was in "echter" HW - ist doch viel entscheidender fuer den Erfolg eines Projekts als ob die FSM jetzt one-hot ist oder nicht, und die sollte von Anfang an einigermassen passen, d.h. da muss auch einer den Hut aufhaben, der Ahnung hat. Konnte da am Nachbartisch mal so einer Verzweiflung wochenlang zuschauen. Weil's ja eine gute Idee ist, z.b. Ethernet-FCS im FPGA und nicht von einer CPU zu berechnen, wenn man da die Packerl zum PHY schleust, ist's aber z.B. gar keine gute Idee das auch mit dem CRC von DVB-P/SI-Tables zu machen, wenn man die dann in einen MPEGTS muxen will. Da ist's erheblich simpler, das die Software machen zu lassen, die die Tabellen vorher eh schon zusammensetzt. Muss man halt wissen, bevor man sich einen Wolf beim hardwarebescheiben einer Terror-CRC-Maschine holt. Oder wenn der Layouter 8 Hispeed-Lanes swappen muss, weil der Softwerker keine Ahnung/keinen Bock hat, das durch das Setzen eines Bits in einem Statusregister zu erledigen, oder der FPGA-Mensch durch cleveres Sortieren seiner Pins, dann sorgt das fuer Verzoegerungen und Probleme (z.B. EMV). Gruss WK
Dergute W. schrieb: > Und da ist's fuer den Erfolg des Ganzen imho deutlich wichtiger, dass > eher so Design-Geschichten passen, also SW-Entwickler, HW-Entwickler, > FPGA-"Programmierer" :-) Tja, also die gleichen Probleme wie bei allen anderen Arten von Projekten 😁
> Naja. Von dem, was ich so in meiner Umgebung mitgekriegt habe, oder > selbst an Problemen hatte, kann ich eher nicht bestaetigen, dass der > Gesamterfolg/Misserfolg zum Grossteil am Aufbau von FSMs oder > Zaehlerdesign liegt. Naja, offiziel heisst es immer "Der IC ist zu langsam, zu klein, oder die Entwicklung ist zu komplex". Aber mit der Ansage, wo konkret im Design der ursächliche Flaschenhals steckt, tut man sich gerne schwer, auch weil außer dem FPGA-Experten dieses "Detail" eh keiner versteht. Zu Zeiten von Spartan3/6 Designs und früher hatte man öfters mit Architekturangepassten Designs die angepeilte Taktrate/Speedgrad "retten" können, oder musste nicht auf den nächstgrösseren FPGA wechseln. Bspw. hatte ich mal ein Kameradesign, bei dem "umständlich" ein Header vor das eugentliche Image per FSM zusammengestückelt wurde. Das umgeschrieben war das design einige Prozente kleiner und die Compile-zeit halbiert. Natürlich gabs statt Dank einem Tritt in den Hintern, weil der Gruppenleiter (der die erste Version geschrieben hatte) jetzt "dumm" da stand... Mein Eindruck ist, das man heute weniger Probleme hat, schnellere/größere und damit auch teure IC's einzusetzen. Auch sind die Compiler "verständlicher" geworden. Kann aber sein, das mit der Migration zu "Chinesischen" und damit zu FPGA's die näher am klassischen Low-Cost Design des Spartan-3 wieder die Implementierung auf geringe Ressourcenbedarf und kurze Signalpfade optimiert. > Oder wenn der Layouter 8 Hispeed-Lanes swappen muss, weil der Softwerker > keine Ahnung/keinen Bock hat, das durch das Setzen eines Bits in einem > Statusregister zu erledigen, oder der FPGA-Mensch durch cleveres > Sortieren seiner Pins, Dem cleveren Sortieren sind immer öfters Grenzen durch Eigenheiten der IO-Bänke gesetzt, die irgendwo in einer Fußnote auf Seite xyz des Datenblattes erwähnt werden. Und ja dem Layouter kann man als FPGA-Experte kräftig helfen, von man sich dem quasi auf dem Schoß setzt und demm klarmacht, wo dem FPGA als "elektronisches Langloch" die konkrete Pin-Auswahl "egal" ist.
Richard W. schrieb: > die größte Gefahr für Terminverzug und Bugs war meistens die > Selbstüberschätzung und Verbohrtheit von Entwicklern. Da wird gemauert > und Projektpläne werden sabotiert weil man der Meinung ist man wüsste > besser was wie und warum implementiert werden soll. Interessant ist, daß Entwickler fast Dasselbe sagen, so etwa: Die größte Gefahr für Terminverzug und Bugs war meistens die Selbstüberschätzung und Verbohrtheit von Projektleitern. Da wird voreilig gepant und losgelegt, Projektpläne werden mittendrin geändert und komische Vorgaben gemacht, weil man der Meinung ist, man wüsste alles besser, was wie implementiert werden soll. :D
Bradward B. schrieb: > Und ja dem Layouter kann man als > FPGA-Experte kräftig helfen, von man sich dem quasi auf dem Schoß setzt > und demm klarmacht, wo dem FPGA als "elektronisches Langloch" die > konkrete Pin-Auswahl "egal" ist. Man muss mehr tun: Der Layouter (vor allem wenn er als Schaltungsdesigner Bauteile funktionell tauschen muss, wegen Platz und Verfügbarkeit) sowie der FPGA-Entwickler müssen beide ihre REQs ausdrücklich formulieren und einfließen lassen. D.h. der FPGA-Entwickler muss sich beim Beschalten des FPGA-Typs eine Vorstellung über die Lage und Platzierung der anderen Bauteile machen, damit er gleich die richtigen Bänke wählt, weil das eben nicht Logikdesign, sondern Layout ist. Das gilt auch für PLLs, Transceiver und PHYs und OSCs. Der Layouter muss wiederum Vorgaben machen, welche Seiten des FPGA er von Steckern, die high speed Signale führen, noch sinnvoll erreichen kann, wenn er das alles platizert hat. Im Prinzip muss das in die Gehäuseauswahl einfließen! Wenn das steht, gibt es einen Konzept-Freeze, d.h. Schaltungskonept und Bauteile stehen. Dazu ist es nötig, das beides parallel zu fahren und auch etwas zu loopen! Am Ende muss der FPGA Designer ein IO-Design machen und prüfen, ob es routet, es dem Layouter übergeben. Der muss es importieren und alles drum herum vorplatzieren. Dann tauscht er die Leitungen, wo er das muss und kann, um es zu optimieren. Dann checkt der FPGA-Mann, ob das routbar ist, mit den Takteingängen passt und vom timing her geht - inklusive der Modelle der Chips drum herum, Busaktivität und Umschalten von Multiplexern wie I2C-MUX, RAMs. Das muss er bis dahin gebaut haben und simulieren können. Enthalten sind dann auch funktionelle Änderungen wegen Tausch von Signalen an Steckern. Wenn das alles so machbar ist und funktioniert, gibt es ein funktionelles Schaltungs-Freeze. Ansonsten muss man nochmal ins Konzept. Es kann z.B. sein, daß man nicht ausreichend kurze Leitungen bekommt, dass das simulierte Layout, soweit es die kritischen Sachen drin hat, so nicht EMV-fähig ist, daß es mit dem Strom nicht passt der irgendwo zu hoch ist und stört oder Abstände nicht einzuhalten sind, etc ... Wenn dieser loop durch ist, gibt es den Layout-Freeze, d.h. so wie das routing auf dem PCB, an den Steckern, der backplane und im FPGA im Zusammenspiel mit anderen FPGAs auf anderen Karten geplant ist, wird es funktionieren. Darin inbegriffen Bestell- und Lieferbarkeit aller Chips, Abzeichnung der Kostenentwürfe durch die GL und erfolgte Funktionsprüfung, ob alles, was in den REQs steht, von der SW auch gemacht werden kann, weil alle Leitungen und Verbindungen dafür bereit stehen und die Busse die Datenraten können. Idealerweise ist das Layout dann auch HF-technisch simuliert und der Strombedarf der FPGAs geschätzt, damit die Bankversorgung abgezeichnet werden kann und die fetten Regler ins Layout passen, nichts schwingt etc. Das erfordert sinnvollerweise einiges an Wissen um Layout-Themen beim FPGA-Designer - gerade im Bezug auf high speed busse, Verdrahtungsanforderungen, Lagenaufbau des PCBs, sowie die Wirkung von Steckern und Vias auf die Signale. Wenn man den Layouter damit alleine lässt, kriegt man gfs Gemüse zurück! Was man hier auch sehen kann, ist die gegenseitige Abhängigkeit und die Dauer, bis das alles steht. Daher ist es wichtig von vorn herein die Funktion alle vor Augen zu haben, die sich Systemplaner wünscht. Da hinterher was nachträglich reinwerfen, führt oft dazu, daß man weiter vorn wieder einspringen muss. Demgegenüber stehen aber Bestell- und Produktionszeiten von PCBs und Bestückung. Ich sage das vor allem im Hinblick auf das Thema Scrum, weil sich das immer mehr in die HW-Entwicklung einschleicht, bis zum Schluss an Funktionen zu bauen, Konzepte zu ändern und nochwas nachzufordern, weil man sich an die 2-Wochen-Planungs-Taktik gewöhnt hat und FPGAs ja jederzeit änderbar sind.
:
Bearbeitet durch User
Nemopuk schrieb: > Fehlerfreie Softwareprojekte gibt es praktisch nicht. Eine Aussage, die Softwareentwickler in die Welt gesetzt haben, welche intellektuell nicht in der Lage sind, ihre Sachen so zu planen und partionieren, dass sie modular testbar werden oder bleiben. Ich lasse die Aussage nur dann zu, wenn man annimmt, dass man für die Tests nicht genug Zeit (zugestanden bekommen) hat, die Kosten zu hoch sind und das Produkt nicht mehr marktfähig wäre oder man systematisch eine Unsicherheit mitschleppt, weil man Fremdsoftware wie LIBs (bei FPGAs eben Cores) drin hat, die man nicht vollständig durchschaut und nicht runterbrechen kann, weil man nicht dran kommt. Generell ist aber jede Software sehr wohl testbar! Für das, was ich in einer Stunde an Code schreibe, kann ich in einer 2. Stunde auch einen Test schreiben, der alle Fälle abdeckt. Also Eingänge vollständig füttert. Sowas kann man zeigen. Beim FPGA haben wir Testbenches, die alle Fälle von Eingängen durchlaufen können, um den Ausgang zu verifizieren. Das erfordert nur, die Module ausreichend klein anzulegen. Auch das ist wissenschaftlich untersucht, belegt und gezeigt. Oft muss man nicht einmal alle theoretischen Fälle untersuchen, sondern er reichen Bereiche. Untestbar wird Software und VHDL immer (nur) dann, wenn es im Block zu groß ist oder man Produktionsfehler hat. ASICs z.B. sind von Außen eben irgendwann nicht mehr testbar. Die Innereien sind aber vollständig simulierbar. Das gilt auch für FPGAs.
:
Bearbeitet durch User
J. S. schrieb: > Generell ist aber jede Software sehr wohl testbar! Für das, was ich in > einer Stunde an Code schreibe, kann ich in einer 2. Stunde auch einen > Test schreiben, der alle Fälle abdeckt. Also Eingänge vollständig > füttert Wie machst du das z.B. für folgendes Programm:
1 | uint64_t mul (uint64_t a, uint64_t b) { |
2 | return a*b; |
3 | }
|
Da gibt es 2^128 Fälle. Unter der Annahme, dass man einen Fall pro Nanosekunde testen kann, braucht man also ungefähr 10^22 Jahre zum testen. Viele Softwares sind jedoch noch viel, viel komplexer und haben noch viel mehr mögliche Fälle. Wir erinnern uns z.B. an den Intel Fdiv Bug; ganz bestimmte Fälle wurden nicht getestet, und das Ergebnis war fehlerhaft.
> Da gibt es 2^128 Fälle. Unter der Annahme, dass man einen Fall pro > Nanosekunde testen kann, braucht man also ungefähr 10^22 Jahre zum > testen. Wenn man zugrundeliegende FPGA-Hardware kennt, kann man gezielt Tespattern ("Corner Case") entwickeln die ohne BruteForce auskommen. Hier beispielsweise könnte man mit Zweierpotenzen die Schaltknoten prüfen. Siehe: https://en.wikipedia.org/wiki/Automatic_test_pattern_generation > Wir erinnern uns z.B. an den Intel Fdiv Bug; ganz bestimmte Fälle wurden > nicht getestet, und das Ergebnis war fehlerhaft. Nicht ganz, das ergebnis ist nicht falsch sondern mit geringerer Genauigkeit. Und es wurde beim Test der Fehler gefunden und in der laufenden Produktion korrigiert. Aber es gab (anfänglich) keinen Rückruf für die Prozessoren mit "Kinderkrankheiten". https://de.wikipedia.org/wiki/Pentium-FDIV-Bug#Ursache_des_Fehlers
:
Bearbeitet durch User
Niklas G. schrieb: > Wie machst du das z.B. für folgendes Programm: > >
1 | uint64_t mul (uint64_t a, uint64_t b) { |
2 | > return a*b; |
3 | > } |
>
Es ist zunächst hinreichend, dass die Testsuite alle möglichen Codepfade
im zu testenden Code durchläuft (Metrik Testabdeckung) und dafür darf
man die darunter liegende Schicht als valide annehmen. Also in der
Theorie.
In der Praxis sieht man das selten, weil der Aufwand immer und überall
unterschätzt wird bzw. sich die Entwickler und Entwicklerinnen
verzetteln, Funktionen erst Last Minute zum Review stellen und man dann
irgendwas ohne Testfälle durchwinkt.
Man ist schon froh wenn man ein paar Blackboxtests für das Gesamtprodukt
hat und die grundsätzliche Funktion einigermaßen sicherstellen kann. Ich
bin immer wieder erstaunt wenn ich sehe dass Kunden im eingebetteten
Bereich gar nicht automatisiert testen, ja noch nicht mal die Entwickler
gegenseitig ihren Code reviewen.
Bradward B. schrieb: > Wenn man zugrundeliegende FPGA-Hardware kennt, kann man gezielt > Tespattern ("Corner Case") entwickeln die ohne BruteForce auskommen. War jetzt mal ganz allgemein von Logik ausgegangen, das Prinzip gilt auch für normale Firmware auf CPUs, FPGAs und ASICs. Es kann immer einen ganz skurrilen Corner Case geben der nicht abgedeckt wurde. Alexander schrieb: > Es ist zunächst hinreichend, dass die Testsuite alle möglichen Codepfade > im zu testenden Code durchläuft (Metrik Testabdeckung) Naja, nur weil einmal alle Instruktionen der Firmware durchlaufen wurden, wurden dennoch nicht alle möglichen Fälle geprüft, also alle möglichen Werte aller Prozessorregister, Speicherstellen etc. Alexander schrieb: > Ich bin immer wieder erstaunt wenn ich sehe dass Kunden im eingebetteten > Bereich gar nicht automatisiert testen, ja noch nicht mal die Entwickler > gegenseitig ihren Code reviewen. Das verwundert mich mittlerweile überhaupt nicht mehr. Selbst Firmen die sicherheitskritische Anlagen herstellen (SIL etc) machen das teilweise nicht. All das beantwortet nicht die Frage, wie J.S. alle Fälle abdeckt, also alle 2^128 aus dem Beispiel: J. S. schrieb: > Für das, was ich in einer Stunde an Code schreibe, kann ich in einer 2. > Stunde auch einen Test schreiben, der alle Fälle abdeckt. Also Eingänge > vollständig füttert.
J. S. schrieb: >> Fehlerfreie Softwareprojekte gibt es praktisch nicht. > Eine Aussage, die Softwareentwickler in die Welt gesetzt haben, welche > intellektuell nicht in der Lage sind, ihre Sachen so zu planen und > partionieren, dass sie modular testbar werden oder bleiben. Vorsicht, der Shitstorm lässt nicht lange auf sich warten. Man kann schon massive formale Prover-Systeme mit C++-Konstrukten aufsetzen und sich darauf ausruhen. Spaetestens mit der Zielplattform wird es dann komplex: kaum ein CPU-Kern kommt vollstaendig verifiziert daher - geht oft schlicht gar nicht, siehe 2^128-Argument von oben. Und dann kommt noch ein OS dazu.. Bei komplexen Softwareprojekten wie auch Hardware ist es schlicht nicht mehr moeglich, alle Schichten zu verifizieren. Man zieht halt irgendwo einen Strich, wie: - TueV sagt, ist SILx konform - Formale Verifikation sagt: Berechnung ok, Corner cases abgedeckt - valgrind findet keine Memoryloecher oder Eignerschafts-Probleme Alle andere pauschalisierenden Aussagen kann man sich sparen, das fuehrt immer wieder zu besagtem Roeschtigraben, wie es die Schweizer formulieren - und der ist auch die haeufigste Ursache dafuer, dass komplexere Projekte immer wieder an der Hochnaesigkeit von 'Experten' auf beiden Seiten gemaess des Thread-Ursprungs kranken. Generell koennte man aber mehr co-simulieren, und da stelle ich eine hohe Ignoranz gegenueber neuartigen Softwaremethoden fest.
Niklas G. schrieb: > Alexander schrieb: >> Es ist zunächst hinreichend, dass die Testsuite alle möglichen Codepfade >> im zu testenden Code durchläuft (Metrik Testabdeckung) > > Naja, nur weil einmal alle Instruktionen der Firmware durchlaufen > wurden, wurden dennoch nicht alle möglichen Fälle geprüft, also alle > möglichen Werte aller Prozessorregister, Speicherstellen etc. > Die Frage ist doch: was soll den getestet werden? Willst du die Multiplikationseinheit eines Prozessors validieren? Dann ganz bestimmt nicht mit einer C/C++ Funktion wie: > uint64_t mul (uint64_t a, uint64_t b) { > return a*b; > } Oder willst du verifizieren, dass der Compiler richtig arbeitet? Dann ganz bestimmt nicht indem du obige Funktion kompilierst und dann mit allen Eingabewerten fütterst. Compilertests schauen üblicherweise ob das Frontend den gewünschten IR Code emittiert bzw. für einen bestimmten IR Code der erwünschte Maschinencode erzeugt wird. Beim Testen von Software wird man selten alle möglichen Eingangswerte durchlaufen. Vielleicht bei Flugzeugsteuerungen, aber dort ist das Testen dann auch 90% vom Entwicklungsbudget. Und auch das Ziel, alle möglichen Codepfade zu durchlaufen wird man eher selten verfolgen weil das Kunden nicht bezahlt wird. In der Praxis, wenn es gut läuft, hat man wenigstens ein System mit dem man automatisiert sein Gedamtprodukt als Black- oder Greybox testen kann. Wenn dann ein Bug gefunden wird, wird der als neuer Testfall aufgenommen um sicherzustellen dass der nie wieder kommt. Das ist beim testen von Hardwareinheiten vielleicht ein bisschen anders wo man wirklich alles durchklappern will. Aber da implementiert man auch auf Logikebene und da ergibt ein solches Vorgehen Sinn.
Martin S. schrieb: > an kann schon massive formale Prover-Systeme mit C++-Konstrukten > aufsetzen und sich darauf ausruhen. Spaetestens mit der Zielplattform > wird es dann komplex: kaum ein CPU-Kern kommt vollstaendig verifiziert Stop! DAS ist nicht durch die SW-Entwicklung verursacht. Meine Aussage war, ddaß man die SW, VHDL vollständig testen kann. Im Weiteren habe ich genau diesen Punkt einer nicht funktionellen HW erwähnt. Das Thema hier dreht sich aber um die Bugs im VHDL. Ok, nun kann man sagen, dass der Prozessor-Bug auch Verilog-bedingt sein könnte, wäre aber der Hersteller. Alexander schrieb: Wie machst du das z.B. für folgendes Programm: >uint64_t mul (uint64_t a, uint64_t b) { > return a*b; >} Indem man es digital differenziert! >Da gibt es 2^128 Fälle. ... die sich auf wenige Bereiche abbilden lassen, nämlich die Vereinigungsmenge der Operationen, die sich a) durch den Definitionsbereich (Eingang) und Wertebereich (Ausgang) ergeben und b) unterschiedlicher Behandlung bedürfen. Wenn nämlich der DEF von -57% ... +60% läuft, dann ergeben sich genau 5 Bereich, nämlich die beiden bitgenauen Werte, die gerade noch gelten, alles dazwischen und die beiden drunter und drüber. Das Gleiche macht man mit dem Ausgang: Der läuft von Überlauf bis Unterlauf der Rechnung. In einigen Fällen muss der Bereich dazwischen zwischen POS und NEG unterschieden werden. -> Maximal 5x5 = 25 Bereiche zu testen, bzw 36 Das ist das was unten mit "corner cases" genannt war. Wenn man einen solchen MUL dann komplett simuliert hat, was durchaus sinnvoll ist, wenn man ihn in VHDL aus verschiedenen Elementen 25x18 zusammensetzen musste und die Einschränkungen und Limiter appliziert, dann kann der für andere Simulationen als 1:1 MUL angenommen werden, der korrekt rechnet und alle seine Werte limitiert. Das wiederum kann man auch nutzen: In meinem Synthesizer wird z.B. immer ein Unterlauf und Überlauf-Bit mitgeschleppt, das zeigt, ob der Wert am Anschlag war. So kann die nächste Stufe auch korrekt arbeiten, macht keinen Mist und bekommt keine Werte, die dann intern unbemerkt überlaufen. Z.B. laufen MIDI Parameter genau von -1000 ... +1000 statt 1023 und die 24 Bitwerte von -8,000 Mio bis + 8,000 Mio statt 8,3xxx. Die 7999999 ist dann der letzte korrekte Wert der noch linear war.
:
Bearbeitet durch User
J. S. schrieb: > Wenn nämlich der DEF von -57% ... +60% läuft, dann ergeben sich genau 5 > Bereich, nämlich die beiden bitgenauen Werte, die gerade noch gelten, > alles dazwischen und die beiden drunter und drüber. Was wenn man sich bei der Bestimmung dieser Bereiche verrechnet und einen Fall vergisst zu testen? Man sollte doch alles testen.
Nun ja, wie ich schrieb, nutze ich ja 999 und 1000, da gibt es nicht viel zu berechnen, weil die Werte definiert sind und nur eingetragen werden. D.h. da gibt es ein maximals Ergebnis von 1Mio+1, wenn einer der beiden 1000+1 hatten = Überlauf. Der Rest ist linear. Gleichwohl kann man den gesamten MUL einmal durchlaufen lassen. Wo es interessant ist, sind meine zusammengesetzen Sinuswellen, die Pulse- und Logarithmusfunktionen und vor allem die bandbegrenzten Rechtecke. Die gibt es aber als bitgenaue Exceldateien, die man mit dem output von Modelsim vergleichen kann. Interessant sind auch da wieder die Bereiche am Maximum, ob der additive Sinus wirklich genau durch N bzw N-1 geht, ob er voll symmetrisch um 0 ist und ob die Phasen sich spiegeln lassen. Diesbezüglich empfehle ich im Übirgen mal den DDS-Sinus von großen X anzusehen. Da staunt man ...
:
Bearbeitet durch User
J. S. schrieb: > Nun ja, wie ich schrieb, nutze ich ja 999 und 1000, da gibt es nicht > viel zu berechnen. Gleichwohl kann man den gesamten MUL einmal > durchlaufen lassen Könntest du noch mal verständlich erklären, wie du einen beliebigen Algorithmus - nicht nur eine Multiplikation, sondern irgendwas beliebig komplexes - vollständig testest, wenn der gültige Eingabebereich >= 128bit groß ist?
J. S. schrieb: > Meine Aussage > war, ddaß man die SW, VHDL vollständig testen kann. Das kann man gerade dann, wenn fuer eine Blackbox bewiesen ist, dass mit einer einfachen Coverage und einer beliebigen Sequenz von Eingangsdaten alle Zustaende abgedeckt sind. Das kann man in der Theorie schon induktiv alles herzimmern, nur passt das Endprodukt je nach Komplexitaet auf keinen uC mehr. Deine Aussage ist in der Praxis schlicht pauschaler Unfug. Es bricht sich schlussendlich auf eine Komplexitaet herunter. Einen CPU-Kern in HDL, 32-Bit/pipelined/cache kriegst du auch im Zimmerl auch nicht komplett innert vernuenftiger Zeit verifiziert, schon gar nicht mit einer klassischen Testbench. So gesehen schenkt sich HW und SW schon lange nix mehr...
> All das beantwortet nicht die Frage, wie J.S. alle Fälle abdeckt, also > alle 2^128 aus dem Beispiel: Das ist doch unnötig. Als in der Grundschule der Mathelehrer seine Schüler testete, ob sie Zehnstelligen Zahlen miteinander schriftlich multiplizieren können, hatt er sie auch nicht 10²⁰ Aufgaben rechnen lassen. Er läßt sich 9867540132 x 8573904612 zeigen und wusste das sie es können oder wo die geistigen Defizite (kleines 1x1, Addition, Übertrag, Schema ...) liegen. Hier ähnlich. Klar könnte der Mossad o.ä. die Multiplikation angezapft haben und bei einer bestimmtem Kombi den Sprengsatz unter dem Stuhl zünden, aber das ist wohl eher ein unrealistiches Beispiel. Und wenn man partout nicht entfehlern kann/mag kann man ja über Redundanz Fehlberechnungen erkennen. Also alternatives Berechnungsverfahren in einem zweiten Compiler in einer anderen Programmierersprach von einem ausländischen Team programmiert. Wenn das nicht übereinstimmt, ist ein Fehler erkannt. Komplexitätsverringerung wurde auch schon gemnannt, also wenn man nicht den Arsch in der Hose oder das Hirn im Schädel hat um die die Korrektheit einer 64x64 MUltiplikation zu erklären, dann beschränkt man eben die Argumente auf 32, 16 oder 8 bit - je nach Leistungsklasse des Programmieres.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.