Testen komplexen VHDL-Codes

Hmmm, vielleicht mit der Methode des scharfen Hinsehens. Es gibt Leute, 
die überlegen sich das sehr genau, was sie dort machen.

Na ja, eine allgemeingültige Antwort darauf zu geben, dürfte schwer 
sein.
Letztendlich musst du entscheiden, was du "darfst" und was nicht. Du 
musst wissen, wie tief du dein System testen willst.
Im einfachsten Fall bist du dir sicher, dass du alles richtig gemacht 
hast und testest gar nichts. Im anderen Extrem testest du alles (was 
sowieso niemal gelingt, da die Anzahl der Testfälle ins Unendliche gehen 
würden).

Irgenddwo dazwischen liegt die Wahrheit.
Es ist durchaus legitim, ein komplexes System durch Test auf der realen 
Hardware auf Funktionalität zu prüfen. Hier kann man sich sinnvolle Test 
überlegen, indem man z.B. das Design so stimuliert, dass der gesamte 
Speicher mit Zufallszahlen beschrieben wird und diese wieder ausgelesen 
werden. Dadruch kann man erkennen, ob der Memorycontroller richtig 
funktioniert. Ebenso kann man mit dem Mac-Controller verfahren.
Ggf kann man auch mal den Oszi an ein paar Signale hängen und schauen, 
ob die Timings passen.

Wenn du aber intern jede Konstallation prüfen willst, da du davon 
ausgehst, dass etwas anders synthetisiert wurde, als du es dir 
vielleicht gedacht hast, dann wirst du wohl um eine recht mächtige 
Testbench nicht herumkommen.

Oli P. schrieb:
> ich arbeite an einem Projekt wo ich ziemlich viele komplexe VHDL-Module
> zusammen schalte.
Soll das ganze 'nur' im FPGA laufen oder auch als ASIC gefertigt werden?

Ich würde mir eine Systemtestbench (also mit allen Modulen) bauen und 
erstmal den 'normalen' Betriebszustand zu simulieren.
Wenn das geht, kannst Du die immer noch genügen Testfälle einfallen 
lassen.

Wenn es auf dem FPGA läuft, finde ich es wichtig Fehlerfälle auch in der 
Simulation nachstellen zu können. Das ist dann ein guten Ausgangspunkt 
für die Fehlersuche.

Duke

Ich halte es genau so wie Duke. Leider ist es manchmal nicht sehr leicht 
(bis unmöglich) alle Schnitstellen mit realitätgetreuen Stimuli zu 
versorgen und die Simulation eines komplexen Systems kann auch mal ein 
paar Tage dauern. Aber wenn man dann im realen Design mal einen schwer 
zu findenden Fehler hat kann eine gute Simulationsumgebung viel wert 
sein.
Daneben habe ich aber immer auch Testbenches für die meisten Submodule. 
Für Schnittstellen wie Ethernet bietet sich ein Loopback-Test an.

Hallo zusammen,

danke für die Antworten.
Nun gut, ich denke ich werde mich fürs erste mit einem Funktionstest 
begnügen. Die Testbench für den MAC oder so ist nicht in einem Tag 
geschrieben, geschweige denn die Testfälle definiert.... das traue ich 
mir nicht zu, daher spare ich mir das noch auf. SystemVerilog scheint 
auch etwas schwieriges zu sein, mit dem hat der Kollege hier die 
einzelnen IPs getestet...


Andere Frage noch -
für ein Bastelprojekt zu Hause möchte ich was am AXI Bus eines ARM 
anschliessen. Gibts irgendwo einen Beispiel VHDL Code, wie man das 
macht? Sehr wohl habe ich eine ausführliche Spec vom AXI, ist ja offen 
und kannn man von ARM runterladen, aber wie ich das jetzt in VHDL 
ummünzen soll, ist mir noch nicht so klar ...

Ich rate auch zu Systemtestbenches, und auf jedenfalls Selbst-Checkend! 
Ich habe erst ab diesem Punkt mich VHDL-Prozeduren beschäftigt.

Hier ist VHDL gut gesetzt von der Sprache. Die Verilognutzer drängt es 
in diesem Fall immer mehr zu SystemVerilog (was auch in Ordnung ist).

Ich gehe so voran:
Erstelle eine Looptest-Umgebung mit zwei Units für einen Looptest. Falls 
dies vom Prinzip nicht funktioniert, dann ein Stimulator und ein Checker 
auf dein DUT bzw. Referenzdesign. In jedem Falls liegen beide Domänen in 
getrennten Prozessen.

Als Nächstes stimulierst du mit Prozeduren in den Prozessen, um die 
Anwendungsfälle abzudecken. Das sieht in etwa so aus.

ProzessA (DUT)
-Testfall_1A
--SendeDaten
---Konfiguriere
----Interface_Schreibprozedur
----Interface_Schreibprozedur
---SendeDies
----Interface_Schreibprozedur
----Interface_Schreibprozedur
---SendeDas
----Interface_Schreibprozedur
----Interface_Schreibprozedur

-Testfall_2A
..

ProzessB (Referenz)
-Testfall_1B
--EmpfangeDaten (ok/fail)
---Konfiguriere
----Interface_Schreibprozedur
----Interface_Schreibprozedur
---TuDies
----Interface_Schreibprozedur
---TuDas
----Interface_Schreibprozedur
----Interface_Schreibprozedur

-Testfall_2B
..


Das funktioniert meiner Meinung nach wunderbar.

Hi,

ich hatte dasselbe Problem mit einer ziemlich komplexen SoC-Geschichte. 
Ansich wollte ich nach Schema F vorgehen und das ganze Zusammenspiel der 
Komponenten direkt mit einem eingebetteten Soft-Prozessor abhaken.
Mit den klassischen Simulatoren (Isim, Modelsim) gabs da so einige 
Probleme bzw. Limitierungen.
Im Endeffekt habe ich das Problem auf zwei Arten lösen können:
1) GHDL und ghdlex (per ghdlex kann eine Python-Testbench mit der 
VHDL-Simulation kommunizieren, cool ist auch die Möglichkeit von GHDL, 
reine Software-Modelle einzuschleifen, wie ein virtuelles 
Ethernet-Interface)
2) Funktionale Simulation (nicht 100% timing-genau, aber zyklengenau) 
mit MyHDL

MyHDL nimmt einem echt viel Arbeit beim Testbenching ab. Der 
Entwicklungsflow ist ein bisschen ein anderer.. Man muss u.U. von Anfang 
an aufpassen, ob sich der Code auch korrekt in synthetisierbares VHDL 
konvertiert (wo gewünscht).

Hoffe, das hilft als Input weiter.

>Mit den klassischen Simulatoren (Isim, Modelsim) gabs da so einige
>Probleme bzw. Limitierungen.

Welche Probleme bzw. Limitierungen waren das genau?