Hallo allerseits, ich mache seit ein Paar Jahren sporadisch kleinere Projekte mit VHDL und falle dabei regelmäßig auf diese Nase. Suche dann Stunden oder Tage lang in überquellenden Waveform-Plots nach dem entscheidenden off-by-one Fehler oder dem einen Takt Verzögerung in irgendeiner State Machine, den ich nicht berücksichtigt habe... Sicherlich wird man da mit mehr Erfahrung schneller und sicherer, was mich aber am meisten stört, ist das viele Waveform-Anstarren. Ich würde gerne die gängisten Problemfälle (z.B. FIFO overflow, underrun...) in automatischen Testbenches prüfen, damit ich es wenigstens merke wenn ich bei der Weiterentwicklung etwas kaputt spiele. Bei Software kann man das ja auch recht komfortabel mit Unit Tests anstellen. Kennt jemand ein gutes Buch, das praktische Tipps und Beipiele liefert, wie man mit VHDL einigermaßen kompakte automatische (self-checking) Testbenches hinbekommt? Meine Testbenches erzeugen meist nur Stimuli, der Rest ist dann das o.g. Waveform-Anstarren. Das muss doch irgendwie besser gehen... Sebastian
Buch kenne ich keines... Was du aber machen kannst: * Eine 'component' in einer TB mit Eingaben beaufschlagen und die erwarteten Ausgaben ueberpruefen (z.B. mit 'assert') * Wenn die 'component' tiefer im Design vergraben ist, dann halt das gleiche auf etwas abstrakterer Ebene (also nicht mehr auf die Nanosekunde genau), auch wieder mit z.B. 'assert' checken Deine Eingaben (Stimuli) kannst du a) deterministisch machen und b) mit random pattern, da wird halt das ueberpruefen der Ausgaben leicht ein echter Moloch an TB-code. Um in die Denke ueberhaupt mal rein zu kommen, kann ich nur empfehlen: Mal eine 'tricky' component mal so mit einer TB zu beharken. Du wirst dann auch schnell feststellen, dass die Anzahl Codezeilen fuer die TB die des Designs locker uebersteigen... Und dann gilt es halt in Zukunft, ein gesundes Mass zu finden (was mache ich mit TB, was mit der echten HW). Nicht umsonst sind bei den Chip-/Logic-Designern in den Firmen die 'Simulanten' meist die groessere Truppe...
> Meine Testbenches erzeugen meist nur Stimuli, > der Rest ist dann das o.g. Waveform-Anstarren. Dito... Heute erst wieder den ganzen Tag nur auf die grünen Waveforms gestarrt. Ich muss sagen, dass richtiges Testen teils anspruchsvoller ist als das Erstellen des Designs. Ich gehe da bislang auch noch nicht richtig ran fürchte ich. Ich erzeuge Stimuli, welche nicht alle Fälle abdeckt und hoffe meist, dass ich nichts Wichtiges übersehen habe. Meine Testbenches sehen noch ziemlich simpel gestrickt aus. Dann gibt es ja auch noch zig zustände in welchen das System sich grade befinden kann. Diverse Konfigurationen werden dann auch noch mit nem Softcoreprozessor vorgegeben und und und... Hätte an einem Buch sicher auch interesse...
Buff schrieb: >> Meine Testbenches erzeugen meist nur Stimuli, >> der Rest ist dann das o.g. Waveform-Anstarren. > > Dito... Heute erst wieder den ganzen Tag nur auf die grünen Waveforms > gestarrt. Ich muss sagen, dass richtiges Testen teils anspruchsvoller > ist als das Erstellen des Designs. Naja, als Designer sagst du dir: Ich habe diese und jene Inputs und muss eine Funktion (einen Output) bringen. Als Tester/Simulant (nicht abwertend gemeint!) siehst du: Ich habe 2-hoch-saumaessig-viele Eingangskombinationen, wie kriege ich die alle getestet? Das ist die andere Seite der Medaille... > > Ich gehe da bislang auch noch nicht richtig ran fürchte ich. Ich erzeuge > Stimuli, welche nicht alle Fälle abdeckt und hoffe meist, dass ich > nichts Wichtiges übersehen habe. Meine Testbenches sehen noch ziemlich > simpel gestrickt aus. > > Dann gibt es ja auch noch zig zustände in welchen das System sich grade > befinden kann. Diverse Konfigurationen werden dann auch noch mit nem > Softcoreprozessor vorgegeben und und und... Dann kann so etwas wie 'formale Verifikation' weiter helfen. Aber da wird es dann auch recht schnell ziemlich kompliziert. Fuer 'normale' FPGA-Designs ist da immer der Spagat, was in Simulation und was in echter HW testen. Im Chip-Design gelten andere Massstaebe, ein 'Schuss in den Ofen' kostet da richtig viel Geld... Aber auch moderne SoC funktionieren nur deshalb fuer relativ wenig Geld, weil eben auf 'Unit-Simulation' mehr Wert/Beachtung gelegt wird. > > Hätte an einem Buch sicher auch interesse... Ich hab' so den Verdacht, die Typen, die so ein Buch schreiben koennen, die verdienen in der Zeit mit 'doing' mehr Geld. Und Hochschulprofs sind da glaube ich echt zu weit entfernt, als dass da mal was aus der Richtung kommen koennte. Theorien und Papers gibts genug, aber leider i.A. nicht fuer uns 'kleine Schlucker'...
Schwieriges Thema :-( Und wirklich gute Literatur darüber ist schwer zu finden... oder sauteuer und recht komplex, so dass sie als Einstieg nur bedingt taugt. Was Berndl sagt, kann ich nur unterstreichen. Man muss immer den Spagat zwischen endlichem Testaufwand und erreichter Testtiefe machen. Und man muss sich einfach darüber im Klaren sein, dass man mit jeder Testbench nur an der Oberfläche der Möglichkeiten kratzt. Aber dennoch kann man die Testfälle natürlich mehr oder weniger schlau festlegen. Wenn du z.B. weisst, dass du einen FIFO im System hast, dann weisst du auch, welche Betriebszustände z.B. einen Überlauf produzieren könnten. Genau diese Fälle gilt es zu identifizieren und per Stimulus zu provozieren. In der Regel hat das dann auch eine Auswirkung am äußeren Verhalten des DUT, welches dann von der Testbench ausgewertet werden kann. Ich gehe das Thema dann meistens so an, dass ich mir erst überlege, welche Testfälle ich gerne durchspielen würde. Anahnd dieser identifiziere ich dann bestimmte Funktionen, die immer wieder benötigt werden. z.B. ein Schreibzugriff auf eine bestimmte Adresse (Falls dein Design ein Prozessorinterface hat). Für diese Funktion baue ich mir dann eine Funktion oder Procedure die genau das macht. Dann hat man einen Punkt erreicht, wo man schon ein wenig abstrakter bestimmte Testfälle erzeugen kann und nicht jedes Signal immer und immer wieder einzeln setzen und zurücksetzen muss. Die Überwachung und Auswertung der "Antworten" des Systems kann man auf vielerlei Arten durchführen. z.B. kann man überlegen, ob es Zustände der Ausgänge gibt die NIEMALS auftreten dürfen. Das können sowohl bestimmte Kombinationen von Ausgangssignalen sein, oder auch zeitliche Abfolgen von Signalen. Für diese Fälle kann man sich, ich nenne es immer "Monitore" basteln, die, jeder für sich, in einem separaten Prozess abgebildet werden. Diese Monitore "überwachen" dauernd die Ausgänge des Systems und identifizieren die unzulässigen Betriebszustände und schmeißen einen Assert, wenn der Fall eintritt. Diese Prozesse können ungesteuert vom aktuellen Systemzustand laufen, da sie die Fälle abdecken, die unahbhängig vom Sytemzustand niemals auftreten dürfen. Das heißt, sie laufen einfach immer parallel "im Hintergrund mit". Die anderen Fälle kann man durch Anlegen eines Stimulus (z.B. unter Verwendung einer der oben beschriebenen Funktionen) erzeugen, die Reaktionszeit des DUT abwarten und danach die Antwort des Systems lesen und mit dem Sollwert vergleichen. Diese Abfolgen aus Stimulus anlegen und Response auswerten werden dann alle in EINEM Prozess nacheinander abgearbeitet. Zyklisch wiederkehrende Stimulus (wie z.B. der Systemtakt) können aber sinnvollerweise in einem separaten Prozess beaufschlagt werden. Falls du mit Modelsim arbeitest, bietet der die Möglichkeit, sogar auf interne Signale des Designs zuzugreifen. Stichwort hierzu ist "init_signal_spy()". Wobei ich damit sparsam wäre, da das was Modelsim-Spezielles ist, was dann nicht auf jedem anderen Simulator funktioniert. Die von Berndl vorgeschlagene Methode, für einzelne Complonentes separate Testbenches zu schreiben und diese getrennt zu testen, kann ich auch empfehlen. Der Komplexitätsgrad sinkt und die Testtiefe steigt, da man an einer interne Component ggf. leichter bestimmte Zustände erzeugen kann, als das dann "von außen" der Fall wäre. Ich weiss nicht, ob dir das alles jetzt wirklich weiter hilft, aber letztendlich gibt es meiner Meinung nach kein gernelles "Kochrezept" für den Aufbau einer Testbench, sondern muss von Fall zu Fall neu entschieden werden. Ach ja: In einer Testbench ist natürlich jede "Sauerei" erlaubt: exzessives Nutzen von Variablen, Schleifen, wait for, etc... Hier ist man ganz gut bedient, wenn man wieder ein bisschen mehr die Software-Denke einschaltet :-)
Sebastian B. schrieb: > Kennt jemand ein gutes Buch, das praktische Tipps und Beipiele liefert, > wie man mit VHDL einigermaßen kompakte automatische (self-checking) > Testbenches hinbekommt? Meine Testbenches erzeugen meist nur Stimuli, > der Rest ist dann das o.g. Waveform-Anstarren. Das muss doch irgendwie > besser gehen... http://www.amazon.de/Writing-Testbenches-Functional-Verification-Models/dp/1402074018 Wenn es mehr um eine HDL-übergreifende Darstellung zu Chip-Verification gehen soll: http://www.amazon.de/Comprehensive-Functional-Verification-Complete-Industry/dp/0127518037/ref=sr_1_1?s=books-intl-de&ie=UTF8&qid=1414093278&sr=1-1&keywords=Comprehensive+Functional MfG,
Fpga Kuechle schrieb: > http://www.amazon.de/Writing-Testbenches-Functional-Verification-Models/dp/1402074018 Das Buch hatten wir in meiner alten Firma.. definitiv ein sehr gutes Buch, aber ich habe es bewussst nicht vorgeschlagen, da der Inhalt nicht gerade aus der "... für Dummies"-Reihe ist und meines Erachtens für jemanden, der bisher nur durch Anstarren von Waveforms "getestet" hat, schon eher schwere Kost sein dürfte.
Schlumpf schrieb: > Die von Berndl vorgeschlagene Methode, für einzelne Complonentes > separate Testbenches zu schreiben und diese getrennt zu testen, kann ich > auch empfehlen. So und nur so, kann man die Funktion komplett testen. Ansonsten multiplizieren sich die Kombinationen gegenseitig hoch und es wird unübersichtlich. Ausserdem können so die Module leichter simuliert und dokumentiert werden.
Hartwarenersteller schrieb: > So und nur so, kann man die Funktion komplett testen. Ganz so krass würde ich es nicht formulieren. 1. Kann die Funktion ab einem gewissen Komplexitätsgrad sowieso nie komplett in vernünftiger Zeit getestet werden, da die Kombinationsmöglichkeiten sehr schnell gegen undendlich gehen. 2. Ist es unter Umständen unnötig, Betriebszustände einer Component zu testen, von denen man weiss, dass diese Zustände im kompletten System nicht herbeiführbar sind. Denn können sie per se im System nicht auftreten, dann muss man sie auch nicht isoliert an der Component testen. Wäre der Zustand aber von außen im System herbeiführbar, und somit relevant, dann kann er auch von außen stimuliert werden. ABER: Es kann aufwändiger sein, diesen Zustand von außen zu stimuieren, als direkt an den Schnittstellen der Component. Am Ende muss aber meines Erachtens immer eine Simulation des gesamten Designs erfolgen. Ist ja nicht auszuschließen, dass man beim Zusammensetzen der Components einen Fehler gemacht hat.
Ein Buch das in das Thema einführt kenne ich bis jetzt auch nicht, habe mich daher auch selber auf das Niveau von Schlumpf hinaufarbeiten müssen. Die Idee mit den parallel mitlaufenden "Monitoren" benutze ich auch, brauchte aber eine weile bis ich selber darauf kam :-) (heissen bei mir einfach "Observer"). Teilweise habe ich die auch zu "Virtual instruments" ausgebaut um gezielt Puls-Pausen Verhältnisse, Pulslängen etc. auszumessen. Was es aber gibt, sind Kurse zum Thema. Z. B. diesen (wurde anfang Jahr auch in Deutschland angeboten, aber leider abgesagt wegen zu wenig Teilnehmern): http://synthworks.com/vhdl_testbench_verification.htm
>Was es aber gibt, sind Kurse zum Thema. Z. B. diesen (wurde anfang Jahr >auch in Deutschland angeboten, aber leider abgesagt wegen zu wenig >Teilnehmern): Jaja, erstens zu teuer und zweitens nichts Neues und drittens wollte der Type auch mal ein Buch schreiben... da hätte er sicherlich mehr mit verdient ...
> http://www.amazon.de/Writing-Testbenches-Functiona... Eventuell wäre hier sogar die erste Ausgabe besser geeignet (und wahrscheinlich billiger), da sie sich auf "reines" Verilog und VHDL bezieht und nicht durch HVLs wie Vera und Specman "Verwirrung" stiftet.
Marcus Harnisch schrieb: >> http://www.amazon.de/Writing-Testbenches-Functiona... > > Eventuell wäre hier sogar die erste Ausgabe besser geeignet (und > wahrscheinlich billiger), da sie sich auf "reines" Verilog und VHDL > bezieht und nicht durch HVLs wie Vera und Specman "Verwirrung" stiftet. hmm, bei mir hier ein 'toter Link'... Hallo Marcus, du bist nicht mehr bei Doulous? Du hast hier immer sehr fundierte Kommentare zu VHDL und Verilog abgegeben, schade. Hoffe du hast was 'gescheites' gefunden...
berndl schrieb: > hmm, bei mir hier ein 'toter Link'... Der vollständige Link wurde ja schon weiter oben gepostet. Ich hab nur zitiert. > du bist nicht mehr bei Doulous? Du hast hier immer sehr fundierte > Kommentare zu VHDL und Verilog abgegeben, schade. Bin wieder in der Entwicklung, aber das schließt die Kommentare nicht aus. Erstens hab ich ja nicht plötzlich alles vergessen und außerdem gehört das immer noch zum Tagesgeschäft. > Hoffe du hast was 'gescheites' gefunden... Kann nicht klagen :)
Schlumpf schrieb: > Ach ja: In einer Testbench ist natürlich jede "Sauerei" erlaubt: > exzessives Nutzen von Variablen, Schleifen, wait for, etc... > Hier ist man ganz gut bedient, wenn man wieder ein bisschen mehr die > Software-Denke einschaltet :-) Achja, das kann ich nur unterstreichen! Dafuer wurde VHDL eingentlich auch mal erfunden...
Zum testen schreibe ich auch manchmal in eine Datei. Darin kann man auch die Zeit schreiben. Wenn man so dir kritischen Zeiten erfasst, muss man nicht die ganzen Diagramme durchforsten.
berndl schrieb: > Achja, das kann ich nur unterstreichen! Dafuer wurde VHDL eingentlich > auch mal erfunden... Richtig, ursprünglich lag der Fokus von VHDL darin, das Verhalten einer Schaltung zu spezifiziern und zu beschreiben. Was aber nicht automatisch heißt, dass das mit Konstrukten geschenen muss, die auch synthetisierbar sind. Es diente eher dazu, das Verhalten einer Schaltung zu modellieren. Da ergibt sich dann auch noch eine weitere Methode, wie man eine Testbench aufbauen kann. Wenn man das Verhalten des DUT noch einmal in nicht synthetisierbarem VHDL modelliert, kann man parallel das DUT und das nicht synthetisierbare Modell mit dem identischen Stimulus beaufschlagen und prüfen, ob sich das "Modell" und der Code zur Implementierung gleich verhalten. Aber das ist dann schon eine sehr aufwändige Methode. Kann aber durchaus sinnvoll sein, wenn bei komplexeren Systemen mehrere Funtionseinheiten erst einmal abstrakt in VHDL modelliert werden, um das korrekte Zusammespiel der Einheiten zu simuliern. Dabei kann in einem frühen Stadium bereits festgestellt werden, ob die Spezifikation überhaupt so umgesetzt werden kann. In diesem Fall liegen dann bereits Modelle vor, gegen die dann der Code, der zur Implementierung dient, getestet werden kann. Aber das nur der Vollständigkeit halber. Die Methode ist schon echt aufwändig.
Schlumpf schrieb: > Wenn man das Verhalten des DUT noch einmal in nicht synthetisierbarem > VHDL modelliert, kann man parallel das DUT und das nicht > synthetisierbare Modell mit dem identischen Stimulus beaufschlagen und > prüfen, ob sich das "Modell" und der Code zur Implementierung gleich > verhalten. siehe z.B. hier: http://www.stefanvhdl.com/ Da findet sich noch mehr interessantes
Schlumpf schrieb: > Wenn man das Verhalten des DUT noch einmal in nicht synthetisierbarem > VHDL modelliert, Dafür nutze ich lieber eine Alternative, wie Python oder Matlab. Duke
Duke Scarring schrieb: > Schlumpf schrieb: >> Wenn man das Verhalten des DUT noch einmal in nicht synthetisierbarem >> VHDL modelliert, > > Dafür nutze ich lieber eine Alternative, wie Python oder Matlab Ist matlab mit einem Hobbyisten Budget möglich? Also statt 2-3 guter fachbucher könnte man auch 200€ für eine Lizenz ausgeben, bezweifle aber das das genügt.
Ladislaus Lamda schrieb: > Ist matlab mit einem Hobbyisten Budget möglich? Das kann ich nicht beurteilen. Es soll wohl Bücher mit passender Lizenz geben. Außerdem gibt (OpenSource-)Alternativen zu Matlab. Aber damit verlassen wir das ursprüngliche Thema völlig... Duke
Ich habe eine alte Studentenversion von Matlab, die konnte man damals im Buchladen ohne Studentenausweis kaufen. Für 99 DM, auf Disketten... Schau mal nach bei mathworks, ob es sowas ähnliches noch gibt, sonst halt Scilab/Octave. Wolfram Research hat eine Mathematica Gratisversion für den Raspberry Pi. Aber das scheint mir einen anderen Bereich der Mathematiksoftware abzudecken.
Sebastian B. schrieb: > Kennt jemand ein gutes Buch, das praktische Tipps und Beipiele liefert, > wie man mit VHDL einigermaßen kompakte automatische (self-checking) > Testbenches hinbekommt? Meine Testbenches erzeugen meist nur Stimuli Link: https://www.aldec.com/en/products/fpga_simulation/active-hdl Das Forum und die diversen Tools dazu, bzw. negativ Tests. Einfach mal durchlesen, bzw. habe ich mir die Videos dazu angeschaut. Einfach klasse gemacht. Viel Erfolg. Gruss Holger.
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.