Hallo zusammen, ich arbeite an einem Projekt wo ich ziemlich viele komplexe VHDL-Module zusammen schalte. Es handelt sich um Ethernet-MACs, Memory-Controller usw. Die Komponenten an sich wurden von jemand anderem schon getestet, aber ich füge die in meinem Projekt jetzt anders zusammen und baue was damit. Ich frage mich jetzt - wenn ich die Komponenten zusammenschalte, wie teste ich das dann am Schluss, ob das auch richtig funktioniert? Klar kann ich einen Funktionstest durchführen, auch Dauertest mit Protokollierung usw., aber eine VHDL-Testbench zu schreiben schon alleine für einen Ethernet-MAC scheint mir sehr komplex. Zumal der MAC alleine ja gar nicht interessant ist, sondern ich will ja prüfen ob mein so zusammengebautes System funktioniert... Die einzelnen Module wurden mit SystemVerilog getestet, das erscheint mir aber sehr komplex, ausserdem habe ich keinen Rechner mit der dazu passenden SW. Gibt es da noch andere, ggf. einfachere Möglichkeiten das zu testen? Oder darf man, wenn man weiss dass die einzelnen Komponenten i.O. sind, einfach am Schluss einen Funktionstest machen. Gruss
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?
Thread beobachten
Seitenaufteilung abschaltenBitte 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.