Ich arbeite zur Zeit an einem Projekt, bei dem es um die Implementierung eines MIPS-Prozessors für Verschlüsselungen geht (Elliptic Curve). Mein Projekt (SystemVerilog) habe ich mir grob in folgende Teile aufgeteilt: 1) Entwicklung und Testen eines Single-Cycle MIPS (keine Pipelines) 2) Erweiterung um eine 5-stufige Pipeline 3) ECC-Verschlüsselungszeug, darum gehts es hier aber eher weniger Nun habe ich eine Rohversion des Single-Cycle MIPS-Prozessors fertig und es geht langsam ans testen. Dabei schreibe ich Assembler-Code, welches ein spezielles Szenario testen soll. Der Code wird dann mit einem cross-compiler für MIPS (gcc-mips) in Maschinen Code gewandelt, beim starten des Programms in den Programmspeicher eingelesen und dann rattert der Prozessor durch die Befehle und ich schaue mir dann die Waveforms an und vergleiche, mit dem was ich erwarte. Dieser Weg funktioniert .... naja es dauert jedoch ziemlich lange. Hätte jemand eine Idee, wie das ganze beschleunigt werden könnte? Was ich mir gedacht habe wäre z.B. eine Anzahl von Testassemblerprogrammen zu haben und diese nacheinander auf meinem MIPS-Prozessor auszuführen (quasi auf einem Rutsch und nicht jedes mal die Simulation neu starten für das neue Testprogramm). Nach jedem ausgeführten Test soll dann z.B. etwas wie ein Hexdump der aktuellen Register-Werte gespeichert werden und das vergleiche ich mit den erwarteten Register-Werten die ich mir für jeden Test einmal in einer Datei gespeichert habe. Meine Frage nun wäre ... ist sowas generell möglich mit SystemVerilog und Modelsim ? Oder hat jemand sogar bessere Varianten das ganze halbwegs bequem und automatisiert zu testen? Mein aktueller Weg dauert zu lange und vor allem wenn ich später an weiteren Komponenten Pipelines / Verschlüsselung arbeite wäre es gut Tests zu haben die man einfach alle auf einmal ausführen kann um sicher zu sein, dass die neu entwickelten Komponenten das alte Verhalten nicht verändert haben. LG
Ja so eine Mips kostet Zeit bis in die Nacht. Beitrag 2:15 Ich bin bei 2. (5-stufige Pipeline) und kann mitfühlen, allerdings habe ich VHDL genutzt. http://www.dossmatik.de/mais-cpu.html Das automatische Testen ist sehr interessant. Ich hatte das Rechenwerk in einer Cosimulation abgetesten. Das hatte ich mit dem Interface VHPI erschlagen. Die Rechenoperationen habe ich mit einer C Funktion nachgeschrieben und parallel laufen lasen und bei einem Verstoß hatte ich einen Output am Bildschirm oder einen Eintrag in ein File. Das hatte eine Weile parallel laufen lassen und hatte auch paar mal zugeschlagen. Damit habe ich aber nicht den Decoder oder andere Elemente (write back) überprüft.
Moin, ah, mal wieder ein Klassiker :-) > > 1) Entwicklung und Testen eines Single-Cycle MIPS (keine Pipelines) > 2) Erweiterung um eine 5-stufige Pipeline Ich würde raten, gleich mit der Pipeline anzufangen. Den 'branch delay slot' in Multi-Cycle-Methode (das meintest du doch, oder?) zu emulieren, macht kaum Sinn. Ich habe erst mit einer 3-Stufen-Pipe angefangen und die WB-Sachen und Hazard/Bypass-Logik später aufgebohrt. Auf welcher FPGA-Technologie soll das laufen? Du solltest von vornerein max. Speed und Register-Implementierung (Distributed RAM oder emuliertes 3-Port register ram file) festlegen und deine Pipeline drauf optimieren. Das eine bremst je nach WB-Strategie, das andere frisst Resourcen. > > Meine Frage nun wäre ... ist sowas generell möglich mit SystemVerilog > und Modelsim ? Oder hat jemand sogar bessere Varianten das ganze > halbwegs bequem und automatisiert zu testen? Mein aktueller Weg dauert > zu lange und vor allem wenn ich später an weiteren Komponenten > Pipelines / Verschlüsselung arbeite wäre es gut Tests zu haben die man > einfach alle auf einmal ausführen kann um sicher zu sein, dass die neu > entwickelten Komponenten das alte Verhalten nicht verändert haben. > Ich habe den Ansatz bei den div. CPUs per vereinfachte/virtualisierte In Circuit Emulation gewählt. Damit kannst du nächtelang deine Simulation mit Testvektoren fernsteuern und gcc-Regresstests fahren, wie auch gegen funktionierende CPU-Emulationen (qemu MIPS) verifizieren. Das geht automatisiert per gdb-Script. Das läuft recht ordentlich. Modelsim hat VPI/FLI, aber das ist etwas eingeschränkt nutzbar und kann IMHO weniger als das freie GHDL/ghdlex. Die Verilog-Seite kannst du mit Aufbohren von Icarus über VPI ev. abdecken, aber wie gut das läuft, keine Ahnung. Der grosse Knackpunkt ist, das Debug-Interface richtig einzudesignen, aber da gilt die Regel: Wenn dein Prozessor ein funktionierendes Exception-Handling hat, kann er auch In Circuit Emulation. Wenn die "bewiesen" ist, hast du deine Testbench recht flott auf einem brauchbaren Stand. Dann musst du nur noch die Exception/Interrupt-events und Prioritäten im Zusammenhang mit ICE verifizieren. Wenn du in die harte Entwicklung/Verifikation mit niedrigem Budget gehen willst, empfehle ich ein Redesign in MyHDL. (Es amortisiert sich wirklich). Das läuft bisschen auf eine zweistufige Sache hinaus: 1) Verifikation der Basis-Ops und Funktionalität in Python/MyHDL (a la System Verilog) 2) Verifikation auf HDL-Level per Co-Simulation (quasi identisch zu Regresstests auf der realen HW) Hätte einiges an Doku und Links zu Material dazu, aber eben nur für die VHDL-Ausgabe-Seite. Zu GHDL Cosim gibts hier noch etwas olle Info: http://tech.section5.ch/news/?p=124 Grüsse, - Strubi
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.