(Semi-)Automatisiertes Testen eines Prozessors (MIPS)

[Max M. (dertyp)]

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

[René D. (Firma: www.dossmatik.de) (dose)]

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.

[Martin S. (strubi)]

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