VHDL: Testbench für interne Signale

[AlexejW (Gast)]

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.

[Alban (Gast)]

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.

[FPGAküchle (Gast)]

#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

[AlexejW (Gast)]

#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...

[FPGA-User (Gast)]

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.

[AlexejW (Gast)]

#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.

[FPGA-User (Gast)]

"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.

[Xenu (Gast)]

>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.

[AlexejW (Gast)]

#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...

[T.M. (Gast)]

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?