Ich habe eine Frage, wie testet Ihr eueren Code? Wenn ich in C etwas schreibe, baue ich Debuginformationen ein, die per #Define zu- bzw. abschaltbar sind. VHDL Code testet man mit einer Testbench in einem Simulator. Da gibt es ein Taktdiagramm und man kann alle Signale verfolgen. Das ist soweit klar. VHDL bietet auch die Möglichkeit von File Operationen. Hier kann man zusätzliche Outputs über read/write Zugriffe in Dateien oder die Standardausgabe ausgeben. Solche Ausgaben würde ich an verschiedenen Stellen in meinen VHDL Code ausgeben. Leider gibt es kein Define in VHDL, zum an zuschalten der Debuginformationen. Oder ignorieren die Fitprogramme Filezugriffe und es wird automatisch beim Fitten übergangen? Ich habe keine Ahnung, wie so etwas am günstigen läuft. Falls jemand hier ein paar Kniffe aus dem Nähkästchen hat, wäre das schön. Danke Rene
man kann mit --rtl_synthesis on/off direktiven auszeichnen welche codeteile bei der synthese nicht berücksichtigt werden sollen
Da müssen doch die Generics von unten überall durchgefädelt werden. Ich hatte z.B. an eine Funktion oder eine Prozedure in einem Packgage gedacht. Dann müsste nur in der Funktion/Prozedure etwas auskommentiert werden. Mal sehen was noch für Ideen kommen.
Ich glaube, Du verfolgt den falschen Debug-Ansatz. Einmal wird VHDL mittels Simulator und Beobachten der Signale im Wave-Fenster debugt, das kennst Du ja schon. Damit korrigiert man meisten Überlegungsfehler, wenn man sieht, dass ein Signal doch nicht so kommt wie man es sich vorstellt. Die zweite Methode funktioniert mit einer Testbench. Dabei wird das zu testende Modul von AUSSEN mit Signalen gefüttert, und die zurückgelieferten Signale mittels VHDL-Mitteln auf korrektheit geprüft. Diese Testbench ist nicht synthetisierbar, deshalb kann man dort alle Möglichkeiten wie File-IO, asserts usw. verwenden. Im zu testenden Modul (DUT) wird nichts geändert, die Beobachtung und die Berechnung der Korrektheit erfolgt immer von außen. Es gibt aber von manchen Simulatoren Spezial-Werkzeuge, mit denen man von der Testbench aus Signale innerhalb des DUTs lesend beobachten kann, ohne dass man dazu das zu beobachtende Signal über ein Port nach außen führen muß. Suche einmal ein bischen nach Testbench und VHDL, das ist der korrekte Ansatz für das Debugging. Vielleicht hilft Dir aber auch, dass man bei einem VHDL Simulator an bestimmten Stellen Breakpoints setzen kann und dann den Code schrittweise ausführen kann. Von der Methode mit "printf"s im VHDL Code kann ich Dir nur stark abraten.
dito, kann mich nur dem Vorredner anschliessen, anglotzen der Waveforms ist nur was fuer 'die Erstinbetriebnahme'. Ansonsten fuer die Module (koennen auch mehrere sein) eine saubere Testbench, die idealerweise Pseudo-Random Stimuli generiert. In der Testbench wird aus diesen Stimuli auch das erwartete Ergebnis berechnet (am besten von einer zweiten Person, um grobe Missverstaendnisse auszuschliessen) und dann wird mit 'assert' gnadenlos bei jedem Fehler angehalten. Das bedeutet natuerlich etwas Aufwand, weil die 'low-level' Testbenches beim wachsen des Designs mitgepflegt werden muessen. Aber dann erzeugt dir ein 'vsim -c -do xxxxx_tb.do' ueber alle Testbenches auch ein sicheres Gefuehl, dass dein Design allen Anforderungen entspricht. Meine Meinung: So und nicht anderst. Und schon gar nicht mit irgend einem proprietaeren Sch$%^^ der beim Wechsel der Plattform nicht mehr funktioniert!
PS: Und neben 'vsim -c ......' laeuft dann bei mir auch noch ein 'ghdl -r <xxxx_tb>' um auch Ungereimtheiten mit den Simulatoren auszuschliessen.
Berndl du hast schon was neues reingebracht. Das assert!! Auch schon angelesen. Wie funktioniert das assert? An das habe ich auch schon gedacht. Nur fehlen mir dafür die praktischen Beispiele. Ich hätte auch solche assert mit Erwartungswerten gefüllt. Wie Statemachine hat einen unzulässigen Zustand erreicht. Kann man assert im Code außerhalb der Testbench benutzen? Und zwar so, dass der Code syntheisierbar bleibt? Leider hören an dieser Stelle die teueren Bücher immer auf. PS: Ich habe auch GHDL ;-)
> Leider hören an dieser Stelle die teueren Bücher immer auf.
Dann benutzt Du die falschen teuren Bücher ;)
Die Behandlung von assert-Anweisungen durch ein Synthese-Tool wird im
Synthese-Standard NICHT festgelegt. d.h. es kommt auf das
Synthese-Tool an was es damit macht. Allerdings ist mir kein einziges
Tool bekannt das die assert-Anweisungen beachtet. Sie werden
ignoriert...
Es ist sicher hier etwas anders die Sache zu betrachten. VHDL ist eine Beschreibungssprache. Nur ein Teil des Sprachumfanges ist synthetisierbar. Es steht nicht immer explizit dahinter ob diese Anweisung von einem Synthese-tool oder einem Simulation-tool umgesetzt wird. >Mathi --Dann benutzt Du die falschen teuren Bücher ;) Was empfiehlst du denn zu lesen? Als Gutes Buch kann ich "FPGA Prototyping by VHDL Examples" von PONG p.CHU empfehlen. Leider benutzt der Autor kein assert und das Inhaltsverzeichnis ist zu schlecht. Da muss man immer zu lange suchen.
Wenn es um reines VHDL geht, dann den "Designer's Guide to VHDL". Alles andere beschäftigt sich mehr oder weniger nur mit dem Synthese-Subset. Und auch nur mit dem was man oft benötigt. > Es ist sicher hier etwas anders die Sache zu betrachten... Warauf willst Du hinaus?
Mathi schrieb: > Wenn es um reines VHDL geht, dann den "Designer's Guide to VHDL". > Alles andere beschäftigt sich mehr oder weniger nur mit dem > Synthese-Subset. Und auch nur mit dem was man oft benötigt. > Das Buch habe ich auch. Bin beim durchkämpfen. >> Es ist sicher hier etwas anders die Sache zu betrachten... > > Warauf willst Du hinaus? Es sind unterschiedliche Ansätze ob es was zum Simulieren gibt oder in den FPGA rein soll. Für mich ist die Simulation eine Unterstützung.
> Es sind unterschiedliche Ansätze ob es was zum Simulieren gibt oder in > den FPGA rein soll. Naja, das kann man anders sehen. Aber vor allem muss es kein FPGA sein ;) ASIC ist viel spannender... > Das Buch habe ich auch. Bin beim durchkämpfen. Da steht das drinnen. Im Anhang zum Synthese-Standard. Das was du da findest sollte von jedem Tool unterstützt werden.
>Wie funktioniert das assert? An das habe ich auch schon gedacht. Nur >fehlen mir dafür die praktischen Beispiele. Naja, ganz einfaches Beispiel: Du hast auf deinem Design einen SPI-Master, der einen externen Mehrkanal-ADC zyklisch einlesen soll. Der SPI-Master hat als Eingaenge eine Clock, evtl. einen Reset, dann die SPI-Signale nCS, SCK, MOSI, MISO. Er muss deinem Design natuerlich auch sowas wie adc0_wert, adc1_wert, adc0_valid, adc1_valid 'nach oben' durchreichen. Diese SPI-Master Component kommt in eine TB rein. Eine weitere Component in der TB ist dein externer ADC. Der wird mit deinem SPI-Master in der TB verdrahtet und hat noch zwei weitere Eingaenge adc0_tb_wert und adc1_tb_wert. Den kannst du mit der fuer die Simulation verfuegbaren VHDL Statements sehr einfach stricken, also z.B. erkennst du mit einem process und 'wait until falling_edge(SCK)' dass du ein Bit vom Master empfaengst, dito mit rising_edge fuer dein Ausgangsbit. In der TB selber hast du jetzt eine procedure, die dir fuer den Master einen Request generiert und gleichzeitig auch die erwartete Response. Dazu nehme ich typischerweise pseudo-random Werte. Eine weitere procedure stimuliert nun deinen SPI-Master mit request0 und merkt sich den. Beim naechsten request1 wird dir der ADC die response0 zurueck geben. Dann einfach ein 'assert response0_expected=response0' und schon hast du's. Die TB ist typischerweise deutlich umfangreicher als dein Design, aber du wirst das System dann eben auch besser verstehen. Die ganzen request/response Sequenzen kannst du dann in einer loop zig-tausendmal laufen lassen und immer neue pseudo-random Daten generieren. >Ich hätte auch solche assert mit Erwartungswerten gefüllt. Wie >Statemachine hat einen unzulässigen Zustand erreicht. Wenn deine Component ein Signal 'fsm_invalid' nach aussen/oben gibt und du die Logik dazu in der Component hast, dann kannst du das mit dem obigen Ansatz ja machen. Ich greife in keiner TB auf ein Signal innerhalb einer Component zu, sondern nur auf die I/Os der Components. >Kann man assert im Code außerhalb der Testbench benutzen? >Und zwar so, dass der Code syntheisierbar bleibt? klar, wie oben schon angemerkt mit --rtl_synthesis on/off. Aber dann ist der Design den du simulierst nicht mehr der Design den du implementierst. Ob du das willst musst du selbst entscheiden. >Für mich ist die Simulation eine Unterstützung. Fuer mich ist Simulation ein KO-Kriterium fuer den Release. Was nicht richtig simuliert ist, geht auch nicht raus...
Danke berndl > Die TB ist typischerweise deutlich umfangreicher als dein Design, aber > du wirst das System dann eben auch besser verstehen. Das ist eine ganz neue Erkenntnis. Bis jetzt habe ich ohne Simulator gearbeit. Dabei habe ich sogar gute Sachen geschafft. Ich habe die Pakete geteilt und in der Hardware getestet. Für ASIC ist es klar da kann man nicht groß anders testen. Jetzt bin ich eben an meine Grenzen gekommen und nutzt die Simulation. Dass jetzt die Simulation in den Vordergrund rückt, ist noch etwas ungewohnt. Habt Ihr noch das Standardbuch für Verilog als Empfehlung? Ich kann Verilog code lesen, doch wenn ich selber mit Verilog arbeite, kommt nichts gescheites heraus.
> Ich hätte auch solche assert mit Erwartungswerten gefüllt. Wie > Statemachine hat einen unzulässigen Zustand erreicht. Wenn du für deine FSM 6 Zustände definierst und alle im Automaten verwendest, gibt es keinen ungültigen Zustand. Siehe dazu den Beitrag "Typedefinition mit 3 Zustaenden" >>>> Wenn ich in C etwas schreibe, baue ich Debuginformationen ein... Die Debug-Strategie bei Hardware (du debuggst keineswegs nur deinen VHDL-Code, sondern das, was daraus gemacht wird), ist eine komplett andere als bei Software (dort wird gern nach dem Try-And-Error Verfahren programmiert). Mit einer Verhaltenssimulation findest du 90% der Fehler und brauchst dafür 10% der Debug-Gesamtzeit. Mit dem Oszi/LA findest du 10% der Fehler und brauchst dafür 90% der Debug-Gesamtzeit. > Fuer mich ist Simulation ein KO-Kriterium fuer den Release. Was nicht > richtig simuliert ist, geht auch nicht raus... Na, dann möchte ich aber hoffen, dass die Testbench die Umwelt korrekt abbildet. Denn eine Frage dürfte doch sein: wer testet eigentlich die Testbench? Denn eigentlich dürftest du selber niemals eine TB für deinen Code schreiben. Sondern du darfst bestenfalls eine Schnittstellenbeschreibung abgeben. Ich zeige dir gerne in 0,nichts ein Design, das problemlos durchsimuliert, aber gleich nach dem Einschalten einen Fehler zeigen wird. Du brauchst dazu nur einen entsprechenden Taktdomänenübergang... > Fuer mich ist Simulation ein KO-Kriterium fuer den Release. Was nicht > richtig simuliert ist, geht auch nicht raus. Das hört sich an, als ob alle deine Designs in der Version 1.0 stabil laufen. Tun sie das? ;-)
>Naja, das kann man anders sehen. Aber vor allem muss es kein FPGA sein >;) >ASIC ist viel spannender... Oh ja, und viel teurer ... es sei denn man arbeitet an der Uni ;O) SuperWilly
>Na, dann möchte ich aber hoffen, dass die Testbench die Umwelt korrekt >abbildet. Denn eine Frage dürfte doch sein: wer testet eigentlich die >Testbench? >Denn eigentlich dürftest du selber niemals eine TB für deinen Code >schreiben. Sondern du darfst bestenfalls eine Schnittstellenbeschreibung >abgeben. Richtig, aber manchmal/oefters/immer muss man die TB selber machen, weil es sonst keinen anderen gibt. Umso wichtiger, dass man sich im Vorfeld klar darueber wird, was eigentlich zu tun ist. Ein Interface das ich selber nicht richtig kapiere kann ich auch in der TB nicht nachbilden. Du sagst ja selbst, das merkt man dann beim ersten HW-Test... >Das hört sich an, als ob alle deine Designs in der Version 1.0 stabil >laufen. Tun sie das? ;-) Jein! Sie laufen in der Simulation. Wenn es dann in der echten HW nicht tut, dann liegt ein falsches Verstaendnis des I/F vor oder ein Timing-Problem (was man auch sehr gut mit VHDL simulieren kann) oder ein 'sonstiges' Schnittstellenproblem. Aber ich weiss durch die Simulation, wie mein eigener Design sich verhaelt. Und da ich ueblicherweise nur synchrone Designs mache (ich synchronisiere wenn immer moeglich konsequent auf einen Chiptakt ein), dann weiss ich sehr schnell wo ich anfangen muss zu suchen wenn mal was nicht tut... Beispiel letzte Woche: Ein halbes Jahr (mit ~halber Kraft) den Design gebaut und simuliert. Ein paar Tage vorher zum ersten mal reingeflasht, tat alles. Dann Inbetriebnahme im System: Tat alles. Da werden sicher noch ein paar Sachen hochkommen, aber erstmal koennen die Kollegen mit dem Design arbeiten. Und ich weiss, dass z.B. meine externe SPI (ich bin Slave, an LVDS ueber 2.5m Kabel angebunden) wunderbar funktioniert. Wenn jetzt noch das Backend (Anbindung an uC und dahinter das grosse System) getestet wird und tut (SW ist noch nicht fertig), dann kann man richtig loslegen. Und ja, vermutlich habe ich bei einigen Dingen noch ein falsches Verstaendnis gehabt und deshalb falsch implementiert. Aber das spielt sich dann auf meinem FPGA innerhalb meiner 100MHz Clock-Domain ab. Das muessen dann eben die Systemtests aufzeigen... Aber nochmal: Ohne meine Simulation die fehlerfrei laeuft geht nichts raus! Diese schnelle Bastelei fuehrt zu 2 Stunden Testzeit und dann meist zu einer Taskforce weil's nicht so tut wie's soll... Ich habe, bevor ich FPGAs gemacht habe, ASICs gemacht. Vielleicht daher die Simulationsneurose...
PS: >Ich zeige dir gerne in 0,nichts ein Design, ... ????? >Ich zeige dir gerne in 0,nichts ein Design, das problemlos >durchsimuliert, aber gleich nach dem Einschalten einen Fehler zeigen >wird. Du brauchst dazu nur einen entsprechenden Taktdomänenübergang... Deine TB kann aber auch sehr einfach unterschiedliche Clocks an DUT und Stimuli-Generator anlegen und zusaetzlich auch noch Signallaufzeiten (variabel!) enthalten. Das sind maximal 50 Zeilen VHDL!
>> in 0,nichts ein Design, ... > ????? in Null Komma Nichts aka. Von jetzt auf Nachher ;-)
>>> in 0,nichts ein Design, ... >> ????? >in Null Komma Nichts >aka. Von jetzt auf Nachher ;-) Autsch, den hab' ich nicht begriffen :o)
Nur so als Hinweis für den OP: Es gibt eine Art printf-Package für VHDL (pck_fio). Damit lassen sich insb. zeitliche Abläufe oder umfangreiche Berechnungsergebnisse wesentlich besser debuggen und dokumentieren als mit dem Wellenformgewusel. Insbesondere kann man damit Ausgaben produzieren, die man recht einfach mit den Sollvorgaben aus einem (C/whatever)-Modell vergleichen kann. Gerade wenn das Timing unwichtig ist und nur die Ergebnisse zählen, ist das eine recht angenehme Methode...
Lothar Miller schrieb: >> Ich hätte auch solche assert mit Erwartungswerten gefüllt. Wie >> Statemachine hat einen unzulässigen Zustand erreicht. > Wenn du für deine FSM 6 Zustände definierst und alle im Automaten > verwendest, gibt es keinen ungültigen Zustand. Siehe dazu den > Beitrag "Typedefinition mit 3 Zustaenden" Ungültig ist falsch. Es gibt Zustände die nur während der Intialisierung durchlaufen, werden sollen. Halt die Grundkonfiguration der externe Chips einrichten. Ich hätte z.B. ein Logfile in welcher Reihenfolge die Zustände durchlaufen werden als sehr sinnvoll erachtet. Er gibt nur bestimmt Übergänge. Ab einer gewissen Komplexität ist eine Statmaschine so kompiziert, das bei einer Erweiterung schnell alles über den Haufen geworfen werden kann. >>>>> Wenn ich in C etwas schreibe, baue ich Debuginformationen ein... > Die Debug-Strategie bei Hardware (du debuggst keineswegs nur deinen > VHDL-Code, sondern das, was daraus gemacht wird), ist eine komplett > andere als bei Software (dort wird gern nach dem Try-And-Error Verfahren > programmiert). C geht mir besser von der Hand und auch der Debugger ist unschlagbar. Adress und Pointeroperationen, dynamischer Speicher, Strukturen. Notfall kann man Objektorientiert nach oben mit C++ weiter gehen. Sicher ist C nicht besonders lesbar auf den ersten Blick. Um C kommt keiner herum. Bald laufen auf den Dinger häufiger Soft CPUs. Wenn ich so ein Mathematische Problem habe, dann muss ich ein Bauchgefühl bekommen. Andere benötigen eben Programming by Maus Matlab/Simulink. Der C code ist der Erste Schuß und kommt später in den Eimer. Danach schreibe ich erst es in VHDL. Sicher ist es doppelte Arbeit. Ich würde sagen es lohnt sich, weil bei dem Programmieren in C bekomme ich meine Ideen. . Mit dem Oszi/LA findest du 10% der > Fehler und brauchst dafür 90% der Debug-Gesamtzeit. Ich habe lange so gearbeitet. Sicher sehr uneffektiv, gebe ich zu. Dafür habe ich dabei eine Menge gelernt. Jetzt ist es Zeit, dass ich davon wegkomme und ein anders Level der Programmierung erreiche.
Um nochmal auf die Wertigkeit von TB und UUT zurück zu kommen. An 1. Stelle steht die Schnittstellenbeschreibung. Und noch bevor die das eigentliche Design geschreiben wird, kann oder sollte die zugehörige TB entstehen. Ich gebe zu, dass ich das aber auch noch nicht in der Reihenfolge gemacht habe. Aber gerade wenn man gezwungen ist zu seiner UUT selbst die TB zu schreiben, dann ist das der bessere Weg. Ansonsten kann die TB ja parallel zur UUT erfolgen.
Ich habe selber noch einen hammerharten Link zu dem Thema gefunden. http://www.stefanvhdl.com/ Das sollte in jedem Buch stehen.
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.