Forum: FPGA, VHDL & Co. VHDL Testbenches


von Neuling (Gast)


Lesenswert?

Hallo zusammen,

Ich habe eine Frage zur Testbench in VHDL.
Unser Prof hat ganz klassisch die Component eingefügt und anschließend 
diese nach dem Begin mittels Port_map aufgerufen. Anschließend verwendet 
unser Prof eine Process um die Stimuli zu setzen. Dies macht er indem er 
die Eingabeparameter  setzt. Eine Zeile darunter setzt er folgenden 
Befehl "Wait for 20 ns" und dann kommen wieder Änderungen der Eingabe 
Parameter etc.

Meine Frage ist nun: Wie funktioniert das?!? Läuft das alles in 
durchgehend in 2 "Threads", sodass wenn die Eingabeparameter in der 
Process geändert werden, diese auch automatisch den Aufruf der Port_map 
ändern?
Stehe da ein wneig auf dem Schlauch.

: Verschoben durch Moderator
von Dussel (Gast)


Lesenswert?

Anscheinend hast du Hardwarebeschreibung nicht verstanden.
Port Map wird nicht aufgerufen, das ist einfach angeschlossen. In der 
Simulation wird natürlich intern schon aufgerufen, aber das, was man von 
außen als aufrufen bezeichnen kann, passiert erst im Prozess.

Die Signale werden über die Port Map an die Entity übergeben, die damit 
irgendwas macht. In der Testbench werden diesen Signalen Werte 
zugewiesen. Nach der Zuweisung wird mit wait for eine zetilang gewartet, 
bevor der nächste Wert zugewiesen wird. Sonst würden alle Werte 
gleichzeitig zugewiesen und man würde in der Simulation nur die letzten 
Werte der Signal sehen.

Die Port Map ist bildlich nur das Steckerfeld, in dem man Leitungen in 
die entsprechenden Anschlüsse steckt.

von S. R. (svenska)


Lesenswert?

Außerdem gibt's hier ein VHDL/FPGA-Forum, da bist du mit solchen Fragen 
besser aufgehoben.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Neuling schrieb:
> Meine Frage ist nun: Wie funktioniert das?!? Läuft das alles in
> durchgehend in 2 "Threads", sodass wenn die Eingabeparameter in der
> Process geändert werden, diese auch automatisch den Aufruf der Port_map
> ändern?
Das "läuft" ja nur im Simulator, und der darf muss keine Echtzeit 
können, sondern darf beliebig langsam sein.

Deshalb rechnet der einfach mit "seiner" Simulationszeit (manens NOW). 
Und wenn sich zu einem bestimmten Zeitpunkt was tun soll, dann triggert 
der die Berechnung der betroffenen Prozesse oder nebenläufigen 
Anweisungen an. Und so kann die Berechnung eines einzigen Zeitpunkts 
(NOW bleibt solange unverändert) ruhig ein beliebige Zeit lang dauern...

Dazu z.B. auch das hier:
https://www.aldec.com/en/support/resources/documentation/articles/1165

: Bearbeitet durch Moderator
von Vancouver (Gast)


Lesenswert?

@Neuling

du denkst noch zu sehr in Softwarekategorien. Stell Dir vor, du hast 
zwei Bauteile, die auf einer Platine durch Leitungen miteinander 
verbunden sind. Das eine Bauteil ist die Component, das andere der 
Prozess. Die Portmap sagt, welcher Anschluss der Component mit welcher 
Leitung verbunden ist. Nach dem Einschalten erzeugt das eine Bauteil 
Signale und schickt es an das andere.

Das, und nichts anderes, beschreibt der VHDL-Code, und genau das 
versucht der Simulator nachzubilden. Ob er dazu intern einen oder 
mehrere Threads verwendet, ist unerheblich, das hat auf die Simulation 
keine Auswirkung.
Halt dir immer vor Augen, dass Du eine Hardwarestruktur beschreibst, 
kein Programm. Es gibt mehrere Komponenten, die unabhängig voneineander 
ihren Job machen und sich über Signale unterhalten.

von Vancouver (Gast)


Lesenswert?

Oh, es sei denn, Du interessierst Dich dafür, wie ein VHDL-Simulator 
intern funktioniert. Das ist dann eine ganz andere Geschichte, über die 
ein Hardwaredesigner aber meistens gar nichts wissen will.

von J. S. (engineer) Benutzerseite


Lesenswert?

Vancouver schrieb:
> Das ist dann eine ganz andere Geschichte, über die
> ein Hardwaredesigner aber meistens gar nichts wissen will.

Dazu gibt es ein nettes Buch von Klas ten Hagen, indem u.a. darauf 
eingegangen wird. Das Ziel ist dabei z.B. die Beschreibung so zu 
optimieren, dass der Compiler effizient arbeitet.

Grundsätzlich ist es natürlich schon so, dass dies zu keinen anderen 
Ergebnissen führt. Allerdings gibt es im Bereich Simulation so ein paar 
Dinge, um die Parallelität der Beschreibung einerseits und die 
sequenzielle Abarbeitung mit einander sinnvoll zu verheiraten, dass es 
funzt.

Da kann es im Einzelfall nötig sein, den Simulator mal 0 ps warten zu 
lassen.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Jürgen S. schrieb:
> Da kann es im Einzelfall nötig sein, den Simulator mal 0 ps warten zu
> lassen.
Wenn man sich dabei in den Kopf ruft, dass vorhergehende Zuweisungen von 
Werten an ein Signal erst beim nächsten "wait" (oder alternativ am Ende 
eines Prozesses) übernommen werden, dann wird ein "wait for 0 ns;" 
gleich wesentlich nachvollziehbarer...

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
Noch kein Account? Hier anmelden.