Hallo,
ich steige nach langer Zeit wieder in VHDL ein und möchte nun eine
Testbench erstellen. In meinem Projekt gibt es ein Top Modul, in welchem
eine Komponente erzeugt wird (MemCtrl). Im Prinzip soll ein Vermittler
zwischen einem Speicherkontroller (MIG) und dem Rest des Projekts
entstehen.
Diese Komponente generiert im Moment intern Daten, schickt sie an den
Speicherkontroller, welcher die Daten zum DDR3 schickt. Diese Daten
werden dann wieder gelesen und innerhalb der Komponente ausgewertet.
Letztlich wandern nur ein paar LED-Signale nach draußen, die mir
anzeigen ob alles OK ist oder nicht.
Die Komponente hat ein paar (für die Simulation unwichtige) Ports und
doch so einige Prozesse. Um erkennen zu können, ob die innere Logik der
Komponente mit all ihren Prozessen und Signalen das macht, was sie soll,
reicht es mir jedoch nicht, die Komponente von außen zu bespaßen und die
Outputs der Komponente zu beobachten. Teilweise finden manche
Operationen (bisher) sogar nur innerhalb der Komponente statt.
Stattdessen möchte ich gern jeden einzelnen Prozess innerhalb der
Komponente einem Test unterziehen. Wie geht das? Ich finde leider
überall nur, dass man Komponenten in einer TB instanziiert, für einzelne
Prozesse fand ich das bisher nicht. Oder habe ich etwas naheliegendes
übersehen?
Danke!
Möglicherweise sind assertions eine Möglichkeit, die Deinen Absichten
entgegenkommen. https://www.ics.uci.edu/~jmoorkan/vhdlref/assert.html
Ansonsten fällt mir nur ein, - in leider mühsamer Schreibarbeit -, jeden
zu testenden Prozess in einer eigenen Entity zu isolieren und diese
Entity jeweils in einer eigene Testbench zu testen.
Theoretisch wäre es möglich, mit einem VHDL-Parser wenigstens den ersten
Schritt zu automatisieren, in dem man ihn die enthaltenen Signale
erkennen und eine Entity und den Rumpf (im wesentlichen die
Instanziierung der Entity) der Testbench erzeugen lässt. Leider ist mir
kein solcher Parser bekannt.
Wenn ich einen eigenen Gedanken beifügen darf, würde ich in den Raum
stellen, dass die Formulierung der Tests "eigentlich" die Hauptarbeit
ist. Solche Halbautomatiken wie von mir erwähnt lohnen sich m.M.n. erst
bei sehr umfangreichen Projekten. Bei kleineren ist die Schreibarbeit
eigentlich CopyNPaste und eben die Erstellung der Testvektoren und der
erwarteten Resultate das "Problem".
Nun, vielleicht helfen die asserts ja schon weiter.
Sebastian schrieb:> Ich finde leider überall nur, dass man Komponenten in einer TB> instanziiert, für einzelne Prozesse fand ich das bisher nicht. Oder habe> ich etwas naheliegendes übersehen?
Man simuliert keine einzelnen "Prozesse", sondern man simuliert
Funktionseinheiten (=Entities). Und jeder (halbwegs sinnvolle und
ansehnliche) Funktionsblock wird für sich dann in einer Testbench
geprüft.
> reicht es mir jedoch nicht, die Komponente von außen zu bespaßen und die> Outputs der Komponente zu beobachten. Teilweise finden manche> Operationen (bisher) sogar nur innerhalb der Komponente statt.
Man kann mit jedem Simulator auch in die angehängten Untermodule sehen
und untersuchen, was da drin vorgeht. So habe ich z.B. dort eine DDFS
und eine PWM-Erzeugung in einem Modul SinusPWM zusammengefasst und
simuliert. Trotzdem kann ich von uassen nicht nur den PWMout ansehen,
sondern auch das, was im Modul SinusPWM vor sich geht:
http://www.lothar-miller.de/s9y/archives/57-Sinusausgabe-mit-PWM.html
Und natürlich könnte ich da noch tiefer hineinsehen in das PWM Modul und
in das DDFS Modul.
Gibt es nicht in einer neuen ('neu', 2008 oder so) VHDL-Version die
Möglichkeit, ohne Ports auf interne Signale zuzugreifen? Ich habe es
noch nicht benutzt und mir fällt der Name nicht ein, aber ich glaube,
sowas wurde für Assertion-basiertes Debuggen eingeführt.
Sebastian schrieb:> Diese Komponente generiert im Moment intern Daten, schickt sie an den> Speicherkontroller, welcher die Daten zum DDR3 schickt. Diese Daten> werden dann wieder gelesen und innerhalb der Komponente ausgewertet.> Letztlich wandern nur ein paar LED-Signale nach draußen, die mir> anzeigen ob alles OK ist oder nicht.https://en.wikipedia.org/wiki/Single-responsibility_principleSebastian schrieb:> Im Prinzip soll ein Vermittler zwischen einem Speicherkontroller (MIG) und > dem
Rest des Projekts entstehen.
Scheint für mich ein guter Moment zu sein, dein Design auf mehrere
Entities aufzuteilen, in den eigentlichen Vermittler (Ich nenn sowas
Wrapper) und verschiedene Funktionseinheiten, die du für deinen
Built-in-self-test (BIST) geschrieben hast. Die BIST Funktionsblöcke
lassen sich ja auch in der Simulation zum generieren/prüfen von Daten
nutzen.
Den Vivado Simulator. Das klappt super, einfach das interne Signal in
das Anzeigefenster ziehen, neu simulieren und fertig. Das reicht mir
fürs Erste. Die weitergehenden Konzepte der Simulation schaue ich mir
später an. Jetzt will ich erstmal mit dem Projekt vorankommen.
Eine eigene Frage?
Dieser Thread ist über 6 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
