ax8 soft core auf Spartan 3AN Devboard, Probleme mit erstem Testprogramm und Simulation

[Jay C. (jay_c)]

Hallo,

Ich würde mich sehr freuen, einen AVR-Kompatiblen Softprozessor für mein 
Projekt benutzen zu können. Ich möchte diesen dann mit meinem 
DDS-Generator Verbinden. Das ganze soll auf dem 3AN Entwicklungsboard 
funktionieren. Mit Verilog habe ich einige Sachen geschafft, VHDL ist 
mir noch gar nicht geläufig. Wahrscheinlich habe ich nur etwas dummes 
übersehen und hoffe jemand hier kann mir einen Tip geben.

Ich habe folgendes probiert:
- VHDL-Module des Core mit "add a copy of a source" in ein neues Projekt 
in ISE importiert.
- Benutze das top-level-Modul für den at90s2313, nachdem ich 
herausgefunden habe, dass avr-gcc für den kleinen nicht verwendbar ist.
- Kleines Testprogramm bestehend aus

DDRD=0xff;uin8_t count;while(1){PORTD=count++;_delay_ms(500);}

 compiliert. Im Makefile als target at90s2313 und 50 MHz angegeben
- Hexdatei mit hex2rom von diesem site umgewandelt: ./hex2rom test.hex 
ROM2313 10b16x > ROM2313.vhd
- ROM2313.vhd dem Projekt hinzugefügt
- Constraints file ucf clk mit 50 MHz Quelle verbunden, 8 LEDS, Reset_n 
Testweise auf einen Schalter gegeben, alles andere auf nicht benutzte 
Postensteckverbinder.
- Alles gut soweit, synthetisieren bis konfigurieren geht ohne Fehler.

Nun habe ich erst einmal ein Problem mit der Simulation. Die Simulation 
hört bei 350ns einfach auf mit der Meldung "Simulation stopped", egal 
was ich in den Process settings oder im Feld für die manuelle Eingabe 
einstelle.

Ich habe das so gemacht:

 (...)
initial begin
Clk=0;
Reset_n=0;
... andere =0 ..
#10 Reset_n = 1;
end

always #10 Clk=!Clk;
(...)

Wenn ich Reset sofort auf 1 setze und die Zeile mit der Zeitangabe 
weglasse, läuft die Simulation weiter wie gewollt, aber funktioniert 
nicht. (pc steht still) Wenn ich es so wie beschrieben mache, sehe ich 
dass der Programmzähler heraufzählt, und Daten aus dem "ROM" kommen, 
aber eben nicht was nach 350ns passiert. Der Port bleibt auf xxx 
undefiniert. Auf dem FPGA läuft natürlich auch nichts.

Was habe ich mir da vermasselt, oder welcher wahrscheinlich naive Fehler 
ist mir da unterlaufen?

Danke im Voraus für Eure Bemühungen!

[Duke Scarring (Gast)]

Jay Christnach schrieb:
> - Benutze das top-level-Modul für den at90s2313, nachdem ich
> herausgefunden habe, dass avr-gcc für den kleinen nicht verwendbar ist.
avr-gcc war für mich vor Jahren der Grund mit dem AX8 zu arbeiten.
Damit konnte ich zumindest die Softwaretoolchain beibehalten.
Oder war Deine Aussage nur ein Vertipper?!

Jay Christnach schrieb:
> hört bei 350ns einfach auf mit der Meldung "Simulation stopped"
Mit welchem Simulator arbeitest Du?
Welche Testbench verwendest Du?

Duke

[Jay C. (jay_c)]

Hallo Duke,

Danke für die Antwort.

Ich habe herausgefunden dass der AT90S1200 nicht mit dem C-compiler 
funktioniert. Man kann mit diesem nur assembler verwenden. Deshalb 
wollte ich den AT90S2313 probieren.

Ich benutze als Simulator ISim aus dem WebPack 14.2. Ich sehe an der 
waveform-Ausgabe, wenn ich den rom_data und rom_addr und sreg hinzufüge, 
dass der Prozessor zu funktionieren scheint. Dies allerdings nur für ein 
paar hundert ns (Zeit um ungefähr ein Dutzend Befehle zu laden). Wenn 
ich jetzt im drop-down im Simulator die Simulation länger laufen lassen 
will, bekomme ich nur die Meldung "#run 100ms" "INFO: Simulator has 
stopped". In den process properties steht, die Simulation solle für 1ms 
laufen, was sie aber nicht tut.

Als Anhang habe ich mal die Verilog test fixture beigefügt.

Mittlerweile habe ich noch einen Anlauf versucht und ein modifiziertes 
top-level modul verwendet. Wie hier beschrieben: 
http://www.sensicomm.com/main/projects/fpga/AX8_on_Xilinx.shtml#thebmmpage 
. Der Unterschied ist, dass der reset hier als high-aktiv umgewandelt 
wird, der Takt auf 1MHz heruntergeteilt wird und das ROM als Ram-bolck 
definiert ist.

Dies funktioniert bei mir sogar als Hardware und die LED's "zählen". Das 
im RAM-Block manuell einkodierte Testprogramm wird ausgeführt.

Aber auch hier bekomme ich die Simulation nicht zum funktionieren.

mit besten Grüßen

[Jay C. (jay_c)]

Neue Erkenntnis:

Mein mit hex2rom generiertes modul ist wohl nicht richtig.

Ich habe im log von ISIM eine "Array out of bounds" Fehlermeldung 
gefunden und siehe da: im Simulator sehe ich, dass die ROM-Adresse von 
0x00e nach 0x3fb springt. Diesen Index gibt es aber nicht in meiner 
ROM_TABLE. Diese ist viel zu kurz dafür. Das erklärt, wieso der 
Simulator dort abbricht.

Das ganze wird so langsam lehrreich. Ich muss mich jetzt erst mal mit 
den Interna des AVR (memory layout) und mit dem übersetzten Machinencode 
befassen.

Anhang: mein mit hex2rom generiertes "ROM".

[Duke Scarring (Gast)]

Aus welchem Code/hex-File generierst Du denn Dein rom-file?

Duke

[Jay C. (jay_c)]

Vielen Dank für die Hilfe, Duke. Mittlerweile habe ich es hingebogen 
bekommen. Die Endianness war falsch, sodass der Programmzähler ins Blaue 
Sprang, an eine Adresse, die nicht mehr im Array enthalten war.

mit
./hex2rom test.hex ROM2313 10l16x > ROM2313.vhd
hat es nun schliesslich geklappt.

Das ist nun das was ich haben wollte. Mir geht es erst einmal drum, das 
Ganze auch im Simulator verfolgen zu können. Später werde ich dann 
schauen, wie ich mit data2mem den RAM verändern kann, sodass ich nicht 
immer den ganzen Prozessor mit synthetisieren muss. Vielleicht kannst Du 
mir ja dazu einen Tipp geben.

schöne Grüße
Jay

[Duke Scarring (Gast)]

Jay Christnach schrieb:
> Später werde ich dann
> schauen, wie ich mit data2mem den RAM verändern kann, sodass ich nicht
> immer den ganzen Prozessor mit synthetisieren muss.

Ich versuche es mal in Kurzform:

1. Mit dem FPGA Editor (geht evtl. auch mit Planahead) rausbekommen, wie 
die BRAMs genannt werden, in denen ROM2313 zu liegen kommt, z.B.:

top/ax8/ROM2313/Mram_ram1
...
top/ax8/ROM2313/Mram_ram8

2. Ein bmm-File mit den passenden Instanznamen erstellen (rudimentäre 
Anleitung im data2mem user guide).

3. Translate/ngdbuild das bmm-File von Schritt 2 mitgeben:

ngdbuild -dd _ngo -nt timestamp -uc top.ucf -bm top.bmm -p $(DEVICE) top.ngc top.ngd

Daraufhin wird ein bmm-File erstellt (top_bd.bmm), in dem das Placement 
der BRAMs hinterlegt ist.

4. Wenn später 'nur' die Software geändert wird, ruft man data2mem mit 
der neuen Software und dem generierten bmm-File auf:

data2mem -bm top_bd.bmm -bd $(SOFTWARE)/*.elf -bt top.bit -o b top_softupdate.bit

Mit dem entstehenden bit-File kann impact das FPGA bestücken, oder ein 
mcs-File für den Flash draus bauen.

Ich hoffe ich habe nichts übersehen.

Duke