Hallo, ich bin gerade dabei mir eine USART-Schnittstelle in VHDL zu programmerien. Jetzt stoße ich zum erstenmal wirklich auf das Problem der Designverfikation. Bisher habe ich mir die Signale angesehen. Jetzt wird das aber auch immer komplexer. Problem 1.) Ich konnte noch nicht rausfinden, wie ich im ModelSim input-Signale verändern kann. Hab' bisher im Testbenchgenerator (Project Navigator) mir eine testbench erstellen lassen, diese war aber dann im ModelSim nicht mehr zu verändern. Problem 2.) Wie schreibe ich mir meine eigne Testbench??? Habt Ihr vielleicht ein gutes Einsteiger Tutorial oder einen Link... oder sonstige Tips?? Problem 3.) In einem Thread schreibt Ihr was von TCL, ich hab' mit dieser Skript-Sprache mal rumgespielt, aber ich sehe da nicht wirklich eine Verbindung zu ModelSim bzw. einer Testbench. Ich bin echt dankbar für gut Tutorials, weil lesen kann ich ja auch ;-) Sebastian
Ein Buch das mir gut gefällt zu dem Thema ist: Writing Testbenches Functional Verification of HDL Models Second Edition Janick Bergeron Kluwer Academic Publisher Der Author hat auch eine Webseite.
Also ichhabe das ganze mit .do files gemacht. Such mal einfach nach Modelsim do-files oder der gleichen bei google. Ich hatte mal nen tutorial dafür. Ixch schau mal ob ich das noch finde. Ist aber sehr einfach ein dofile zu erstellen.
Nein, eine Testbench sollte man nicht mit .do files bauen. Eine Testbench ist eine VHDL Top-Level Einheit, das keine Eingangs- und Ausgangssignale hat. Deine Testbench enthält mindestens eine Instanz deines USART-Moduls ( meist DUT = "device under test" genannt). Deine Testbench generiert nun ALLE Input-Signale für das DUT und verifiziert Output-Signale, welche Dir wichtig erscheinen. Weil die Testbench selbst keine Input-Signale hat, brauchst Du vom Modelsim aus auch keine Input-signale zu ändern. In deinem Fall generiert die Testbench sicherlich den Takt. Falls Du den Sender testen willst, wird deine Testbench dann den zu sendenden Character an die USART legen, und ein Strobe- oder ein Write-Signal pulsen, mit dem die USART merkt, daß jetzt Daten zu senden sind. Ein zweiter Programmteil deiner Testbench (ab besten ein eigener Prozess) wartet auf die Ausgangssignale deiner USART, also auf das Start-Bit und fängt dann an die Bit einzulesen. Im Prinzip wie Dein USART Empfänger. Ist der Character vollständig empfangen, vergleicht die Testbench ob das empfangene Zeichen gleich dem gesendeten ist. Die ganze Sache wird dann mit anderen Zeichen beliebig oft wiederholt. Tritt ein Fehler auf, dann generiert die Testbench einen Fehler (assert statement). Werden alle Zeichen fehlerfrei gesendet, dann stoppt die Testbench indem sie alle Signale blockiert, also auch den Takt, oder einfacher indem sie ein assert statement ausführt, das den Simulator stoppt. Beim Erstellen Deiner Testbench darfst Du mehr Eigenschaften von VHDL verwenden als in deiner USART, weil die Testbench nicht synthetisiert werden muß. Du kannst z.B. verzögerte Zuweisungen verwenden, also : signal <= '1' after 2400 ns; Grüße Klaus
Danke für Eure Antworten. Also ich hab' mich auch ein wenig angelesen. Ich schreibe zuerst einen VHDL-Schaltungsblock (z.B. UART-RX) für das Device (FPGA). Anschließend muss ich nochmals eine eingenstänidig Testbench in VHDL schreiben, die mir dann meine Schaltung (UART-RX) testen kann. Verstehe ich das richtig ??????????????? Irgendwie habe ich das Gefühl, dass das keine lustige Abend-Hobby-Geschichte mehr ist. Mit Controllern spielen ist da echt zig-fach einfacher..... :-(. Aber da muss man durch :-! Sebastian Wäre super, wenn mal jemand eine primitivst Testbench für eine OR- Schaltung oder ähnliches posten könnte.
Hm, das ist ein weites Feld, jeder meint unter Testbench was anderes. Also letzlich geht es um Testen des FPGA-Designs, bevor das in den FPGA geladen wird. Also erstmal schauen was der Code macht. Üblicherweise braucht man dazu stimuli (Eingangsignale) und einen vergleich ob die Ausgangssignale so sind wie sie sein sollten. Einfach ist eine neue VHDL entity zu schreiben in deren architecture das design als component eingebunden wird. Dazu kommt ein prozess der den Takt erzeugt: signal tb_clk : std_logix := '0'; process begin tb_clk <= not tb_clk after 5 ns; --100Mhz Takt end process; und .. dut: mein design Port Map( .... clk => tb_clk, ... ) codeschnippsel ohne syntaxgarantie. Jetzt kannst du im Simulator schon mal schauen wie der takt schaltet. Da aber die anderen Eingangsignale keinen Wert haben, wird an den Ausgängen nur 'U' oder 'X' zu sehen sein. per "force im simulator oder zuweisungen in der architecture bekommen die eingangsignale werde zugewiesen und die Ausgangsignale haben sinnvolle Werte. Die ausgangsignale kannst Du dir im Wave-fenster des simulators anschauen. Jetzt willst du natürlich nicht nur einen Satz an Eingangssignalen (neudeutsch Inputvector) testen, sondern wissen was passiert wenn die Eingangsgrößen wechseln. Also schreibst Du processe die nacheinander verschiedene Muster (neudeutsch eingangspattern) an das testdesign legen. Das geht natürlich auch per tcl und force kommandos. Oder du liest eine textdatei per VHDL ein in der die verschiedenen Signale gesetzt werden. Oder du lässt den simulator eine paar us simulieren und setzt per Mausklickiklackie neue Eingangsignale. Im wavefenster kontrollierts jedesmal per scharfes hinsehen ob die Ausgangssignale so sind wie gewünscht. Auf die dauer ist scharfes hinsehen nicht genug. Jetzt ist es an der zeit ein Modell zu schreiben (VHDL oder simulatorsprache) das Aus und Eingänge überwacht und fehlermeldungen generiert (vhdl: assert) wenn was nicht stimmt. Im Hobbybereich genügt meist scharfes Hinsehen und es finden sich auch kostenlose VHDL Modelle. Im ASIC- bereich wo ein Fehler Millionen für neue Chips kostet reicht Hinsehen nix. Dort läuft der Simulator nächtelang und auf einen Schaltungsentwerfer(designer) kommen meherer Verifikanten die Modelle und Prüfroutienen schreiben um den Designer die Bugs auszubügeln. Ich leg mal ein (fehlerhaftes) design plus testbench dazu. Das Ganze ist eine Digitaluhr an einem alphanumerischen Display. Als Eingangsignal hats also nur quarztakt und reset. Überprüft wird durch scharfes Hinsehen, die testbench (cpld_lcd_tb.vhd) hat also nur 50 zeilen. Dafür muss man genau im waveformfenster hinschauen.
Hallo zusammen, so ich gebe zu ich hatte eine kleine Motivationskrise. Sich diese riesige Entwicklungsumgebung plus VHDL autodidaktisch beizubringen ist nicht immer lustig. Aber ich bin wieder am Ball. Ich denke ich habe VHDL und die Entwicklungsumgebung langsam aber sicher verinnerlicht :-). Auch den letzten Punkt den Simulator + Testbench beherrsche ich jetzt langsam und nicht umgekehrt. (Simulator beherrscht mich). Im Anhang hab' ich mal meinen primitiv Counter und die dazu gehörige Testbench gehängt. Es ist eigentlich super einfach, wenn man mal weiß wie's geht ;-)... Sebastian
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.