Ich versuche mich gerade in das Thema VHDL einzuarbeiten. Ich möchte eine Testbench schreiben, welches nicht nur die Signale der Entity Simuliert, sondern auch die "internen" Signale. ( in meinem Programm: x1,x2,x3,p1,p2,p3,d ) Mein VHDL Programm schaut so aus: library IEEE; use IEEE.STD_LOGIC_1164.all; entity Modul1 is port ( a,b,s0,s1,s2,s3 : in BIT; y : out BIT ); end Modul1; architecture Verhalten of Modul1 is signal x1,x2,x3,p1,p2,p3,d : BIT; begin x1 <= s0 xor s3; p1 <= not a and not b and x1; d <= p1 or p2 or p3; p2 <= a and not b and x2; x2 <= s1 xor s3; x3 <= s2 xor s3; p3 <= not a and not b and x3; y <= d xor s3; end Verhalten; Wie schaut das Testbench Grundgerüst dafür aus, das sämtliche Signale verwendet ? Stimuli ist egal.
Ist das in VHDL überhaupt möglich auf interne Signal zu zugreifen? Soweit ich weiß must du interne Signale rausführen um auf sie zugreifen zu können.
#Ist das in VHDL überhaupt möglich auf interne Signal zu zugreifen? #Soweit ich weiß must du interne Signale rausführen um auf sie zugreifen #zu können. In VHDL ja, im Simulator nein. IMHO stützen alle VHDL Simulatoren die Manipulation und Beobachtung von internen Signalen. Die testbench wird gern in tcl geschrieben und die Signale per Pfad addressiert. Also so entity_ganzoben/module1/submoduleA.interners_signal
#Soweit ich weiß must du interne Signale rausführen um auf sie #zugreifen zu können. Kann man dann in der Testbench diese Signal herausführen (Entity erweitern) ? das eigentliche modul mit der logik sollte seine entity behalten, ich möchte ja nur die internen signale simulieren. ist vhdl diesbezüglich so schwach?, kann ich mir irgendwie nicht vorstellen...
Du kannst Dir jedes interne Signal im Simulator anschauen. Dazu muss es natürlich NICHT über die Entity rausgelegt werden. Füge einfach x1, x2 usw. in Dein wave-Fenster im Modelsim ein und schau Dir das Ergebnis an. Etwas komplizierter wird es, wenn Du interne Signale per Stimuli von "ganz oben" mit Werten belegen willst, aber auch dafür gibt es Möglichkeiten. Schau in der Doku zum ModelSim nach.
#Füge einfach x1, x2 usw. in Dein wave-Fenster im Modelsim ein # und schau Dir das Ergebnis an. Eigentlich wollte ich diese abhängigkeit von einem Simulator vermeiden. Kann man nicht einfach für eine Architecture mehrere Entitys verwenden ? Dann könnte man eine Entity für die Simulation, bei der alle Signal herausgeführt sind festlegen und eine für die synthese. in der testbench verwendet man dann eine instanz der "test-entity" zusammen mit der passenden architektur.
"Eigentlich wollte ich diese abhängigkeit von einem Simulator vermeiden." Meinst Du damit, dass Du ModelSim nicht verwenden möchtest oder dass Du keine Lust hast, die Waveforms anzuschauen ? (Letzteres kann ich verstehen) Was soll denn mit den herausgeführten Signalen passieren ? Willst Du dort automatische Tests mitlaufen lassen oder Datenströme in Textfiles rausschreiben ? ModelSim (zumindest meine ALTERA-Version) bietet "SignalSpy", damit kann man auch interne Signale abfragen usw. - ist aber Simulator-abhängig. Wenn Du die Simulation über ein TCL-Script startest, kannst Du mit examine Signale abfragen (bin jetzt aber net ganz sicher, ob nur welche in der TB oder auch "weiter unten") Verschiedene Entitys halte ich nicht für sinnvoll, da würde ich lieber einzelne Testbenches für interne Module aufsetzen und diese möglichst umfangreich per TCL-Script durchtesten. In der Top-Entity werden die Module dann nur noch verbunden bzw. Signale an FPGA-Pins geführt.
>Eigentlich wollte ich diese abhängigkeit von einem Simulator
vermeiden.
Ich kenne keinen Simulator mit dem man die internen Signale nicht
anschauen kann. Wäre ja auch ziemlicher Schwachsinn.
#Meinst Du damit, dass Du ModelSim nicht verwenden möchtest #oder dass Du keine Lust hast, die Waveforms anzuschauen ? #(Letzteres kann ich verstehen) Genau um das geht es, ich möchte prinzipiell mit "assert" und "report" Konstrukten arbeiten, um bestimmte bedingungen zu prüfen. Bei den ganzen Waveforms bekommt man schnell nen knoten im Kopf. irgendwie würd ich gern an vhdl festhalten und so wenig wie möglich extra know how in simulatorspezifische dinge stecken...
Ich kann nur von der Arbeit an unserem Institut sprechen... Aber da wird bestimmt mind. genausoviel Zeit wie du mit VHDL arbeitest für die Verifikation benötigt. Also das fänge bei geeigneten Stimuli an,geht über TCL und diverse do Files und hört bei Simulatorspezifischen Sachen auf. Die VHDL Modelle sind oft das kleinere "Übel". Das Ding zu verifizieren ist oft um Längen aufwendiger. Da reichen oft assert Anweisungen nicht aus, wer will schon Seitenweise reports durchackern um einen Fehler zu finden. Du kannst aber auch für interne Signale mit asserts arbeiten. Das is doch kein Problem, oder?
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.