Forum: FPGA, VHDL & Co. VHDL Variablenüberlauf und Fehlerbehandlung

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.

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 ?

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.