Hallo liebes Forum, ich bin sehr neu hier (in diesem Forum und leider auch in dem Thema VHDL und FPGA). Derzeit fertige ich eine Abschlussarbeit in dem Bereich an (was habe ich mir nur dabei gedacht ;-) ), und brauche als Neuling jedoch etwas inspiration. Vielleicht kann mir ja hier jemand helfen. Meine Aufgabe ist es, in VHDL eine Möglichkeit zu Entwickeln, den Überlauf von Int-Variablen zu erkennen und dann auch zu beheben (z.B. über die Sättigungsarithmetik). Das ist soweit erstmal klar. Allerdings soll ich auch die Fehlerbehandlung umsetzen, sprich den Benutzer darüber Informieren, dass ein Überlauf statt fand. Hier habe ich noch Probleme. Soweit ich das Verstanden habe, können pro Takt mehrere Fehler anliegen, wobei pro Takt immer nur ein Fehler behandelt werden kann. Ist das richtig? Ich habe viel im Internet recherchiert zum Thema "FPGA Fehlerbehandlung" oder "VHDL Fehlerbehandlung" aber wirklich kaum etwas gefunden, was mir weiter hilft. Die Befehle "assert" und "report" kann ich ja für die Ausgabe eines Fehlers verwenden, aber was mache ich, wenn mehrere Fehler anliegen (Verteiltes Fehlermanagement)? Wie gesagt besitze ich gar keine Vorkenntnisse auf diesem Gebiet. Kann mir daher jemand ein Buch oder andere Informationsquelle empfehlen, wie man in der VHDL / FPGA Welt mit Fehlern umgeht (Stichwort: Verteiltes Fehlermanagement)? Ich denke, dass ich aus Unwissenheit auch nicht die richtigen Suchworte benutzt habe. Hier wäre ich für Eure Tipps sehr dankbar. Vielen Dank für Eure Anregungen! :) Liebe Grüße Willi
Warum? Aktuelle Werkzeuge können das doch schon und warnen auch entsprechend. Im FPGA macht das natürlich keinen Sinn mehr. Wer seinen Code baut und alle Warnungen ignoriert dem ist nicht zu helfen.
> Meine Aufgabe ist es, in VHDL eine Möglichkeit zu Entwickeln, den > Überlauf von Int-Variablen zu erkennen und dann auch zu beheben (z.B. > über die Sättigungsarithmetik). Das ist soweit erstmal klar. Nix ist klar, sobald etwas über das Language Reference Manual LRM hinaus geht. Und bei VHDL gibt es diverse Versionen, in den alten gibt es keinen integer grösser als 32 bit und die tools knallen entsprechend messages raus. https://docs.amd.com/r/en-US/ug901-vivado-synthesis/64-bit-Integers (VHDL-2029) > Thema "FPGA Fehlerbehandlung" > oder "VHDL Fehlerbehandlung" aber wirklich kaum etwas gefunden, was mir > weiter hilft. Die Befehle "assert" und "report" kann ich ja für die > Ausgabe eines Fehlers verwenden, aber was mache ich, wenn mehrere Fehler > anliegen (Verteiltes Fehlermanagement)? > Wie gesagt besitze ich gar keine Vorkenntnisse auf diesem Gebiet. Kann > mir daher jemand ein Buch oder andere Informationsquelle empfehlen, wie > man in der VHDL / FPGA Welt mit Fehlern umgeht (Stichwort: Verteiltes > Fehlermanagement)? Naja, die Fehlerdefinition des VHDL-Anwenders unterscheidet sich doch erheblich von der was man von C her kennt. VHDL ähnelt da eher ADA, jedenfalls kennt es die mechanismen der "range". Wie die range-Überprüfung realisiert ist unterscheidet sich aber gern tool -spezifisch. https://www.google.com/search?q=VHDL+range+check eine Vorgehensweise wäre, auf integer zu verzichten und stadessen std_logic_vector resp signed und unsigned aus der IEE1164 zu verwenden. Und wenn integer benutzt wird, dann ohnehin in Verbindung mit "range". https://www.allaboutcircuits.com/technical-articles/integer-and-its-subtypes-in-vhdl/ Generelle Richtlinien wie man eine hohe "Fehlerarmut" in FPGA-Code erreicht sind in der DO-254 gegeben. Aber vielleicht "Fehlermanagment" hier eher "Design-verification" ?! https://www.doulos.com/knowhow/vhdl/the-open-source-vhdl-verification-methodology-osvvm/ PS: Die 32bit-Überlauf-Problematik des Types integer betrifft nicht nur Variablen wie im Topic unterschwellig behauptet sondern auch signals und constants. Wobei man bei letzteren weniger vom "Überlauf" sprechen kann, da statisch.
:
Bearbeitet durch User
Gerade bei INT-Variablen und Signalen ist es doch ein Leichtes, diese schon per Definition einzuschränken. Freilich braucht es dazu eine Vorstellung, in welchem range man sich faktisch bewegt. Ich mache solche Berechungen mit Excel, definiere MIN und MAX-Werte, die man in einer "header"-Datei ablegen und bei Bedarf als Initialwert oder Resetwert zuweisen kann. Ferner dienen diese den Überlauf-Vergleichen, die in rechnenden pipeline öfters nötig sind. Um einen funktionellen (nicht einen durch Programmierfehler erzeugen "technischen") Überlauf zu handhaben, empfehle ich die "N+1"-Strategie: Wenn durch Einstellungen und äußere Einflüsse Übersteuerungen stattfinden, setzt man den Wert einfach auf MAX+1 oder MIN-1 im Negativen. Damit hat man an jeder Stelle in der Rechnung die Möglichkeit, das Signal entsprechend zu behandeln, also entweder den MAX+1 weiterzugegeben, oder das Signal einfach weiterzubearbeiten. Das mache ich z.B. in Video- und Audio-Chains so. So kommt dann doch wieder ein sinnvolles Sample heraus, wenn man möchte.
Willi schrieb: > Meine Aufgabe ist es, in VHDL eine Möglichkeit zu Entwickeln, den > Überlauf von Int-Variablen zu erkennen und dann auch zu beheben (z.B. > über die Sättigungsarithmetik). Das ist soweit erstmal klar. Wenn du dich auf die eigentliche Problematik fokussieren willst, solltest du dir die intbv-Klasse von MyHDL mal zugute fuehren. Darauf basierend haben einige Leute adaptive Fixpoint-Arithmetiken entwickelt, bei denen viele Idiotien von VHDL oder Verilog gar nicht mehr zur Last fallen und manche Fehleranalysen nicht mehr notwendig sind. Leider muss man sich dabei durch diverse Forks graben und im Hinterkopf behalten, dass der MyHDL-Hauptzweig bedingt brauchbar ist, man muss also mit dem Status Quo in ausgerollter Ausgabe (d.h. nicht modular) in VHDL abfinden, inkl. einiger Bugs, die wohl nicht mehr gefixt werden. Entschädigt wird man dafuer mit einer ausgereiften Moeglichkeit der Co-Simulation von Python mit dem synthetisierbaren Ergebnis. Man kann sich natuerlich aus akademischer Motivation heraus auch spezifischen VHDL-Klassen widmen, schlaegt sich dann mit einem Haufen anderer Probleme herum, die nicht zielfuehrend sind. Und schlussendlich muessen die Tools damit klarkommen (was sie meist wie z.B. Vivado mit Vorbehalt tun).
Wow, vielen Dank für die schnellen Antworten. Das hilft schon mal etwas weiter. Beim lesen der Antworten ist mir aufgefallen, dass meine Fragestellung etwas missverständlich war. Die Überwachung und Behandlung des Überlaufes soll deswegen gemacht werden, weil es auf eine zuvor gemachte Arbeit aufbaut: nämlich einen VHDL Compiler zu Entwickeln. Der Compiler existiert nun, aber die Funktion der Überlaufbehandlung fehlt in der Umsetzung noch. Die soll ich nun implementieren. Das größere Problem für mich ist aber die Fehlerbehandlung an sich auf Grund der Gleichzeitigkeit. Habt ihr hierzu vielleicht eine Idee oder Begriffe, nach denen es sich zu Suchen lohnt?
> Beim lesen der Antworten ist mir aufgefallen, dass meine Fragestellung > etwas missverständlich war. Die Überwachung und Behandlung des > Überlaufes soll deswegen gemacht werden, weil es auf eine zuvor gemachte > Arbeit aufbaut: nämlich einen VHDL Compiler zu Entwickeln. Der Compiler > existiert nun, Was ist den der Output dieses VHDL-Compilers ? * Eine Architekturunäbhangiges EDIF-Netzliste ? * runtime-code für simulator ?
:
Bearbeitet durch User
Wenn du dich schon nur auf die Fehlerfortpflanzung fokussieren willst, wuerde ich erst einmal die Basics (mit dem akademischen Betreuer) klaeren, naemlich ob der "VHDL-Compiler" (Was macht der genau, s.o.) einen Simulatorkern hat, der Mechanismen zur Backtrace (sowohl zeitlich, als auch in der Hierarchie) bereitstellt ("Backtrace" waere dein Stichwort). Sonst schreibst du naemlich mal eben den Simulator auch noch um. Kann man machen, aber sich auch dabei verheizen lassen. Ansonsten: CIRCT/MLIR schon auf dem Schirm gehabt? Dann solltest du vielleicht noch erwaehnen, wie deine Verifikation aussehen soll (statische Analyse versus Simulation mit vollständiger Abdeckung aller bedingten Spruenge). Letzteres kommt allenfalls "kostenlos", je nach Compiler-Backend. Ansonsten ist eine vernuenftige Backtrace ein spannendes Thema, an dem die meisten "billigen" Simulatoren kranken, da gab es hier vor kurzem einen Thread zum Thema IDE. Wegen der eingeschraenkten prozeduralen Moeglichkeiten der V*-Sprachen ist das leider recht aufwendig zu implementieren. Aber da du offenbar auf die VHDL-Kröte festgelegt bist, musst du die wohl schlucken.
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.