Hallo zusammen,
ich versuche gerade mit Xilinx einen Microblaze zu programmieren, den
mit von mir erstellten Peripherie über einen FSL kommunizieren zu lassen
und das ganze in ISIM zu simulieren. Die von mir erstellten Teile
funktionieren auch, aber ich habe das Gefühl, dass der Microblaze nicht
mein C-Programm ausführt. Ich habe zum testen was ganz einfaches
geschrieben, damit er einfach nur einen Wert über den FSL an meine
Peripherie schickt, einfach um in ISIm zu sehen, ob er was macht. Aber
da tut sich leider nichts.
Kann ISIM keine programmierten Microblazes simulieren oder gibt es etwas
wichtiges zu beachten?
Vielen Dank schonmal und freundliche Grüße,
fls
Ich selbst starte ihn nirgendwo, aber das mache ich auf dem FPGA ja auch
nicht. Ich hatte die Hoffnung, dass wenn ISIM mir alles simuliert, dass
es dann auch den C-Code startet. Gibt es dafür also gar keine
Möglichkeit?
Ich glaube ich habe irgendwo im Internet was gelesen, dass man mit einem
bestimmten Zusautzprogramm in Modelsim den Zustand des Prozessors sich
anzeigen lassen kann. Also bei welchem Schritt er ist. Dafür müsste ja
auch der C-Code simuliert werden. Verstehe ich das ganze falsch und man
kann das überhaupt nicht simulieren oder nur nicht mit ISIM?
Grüße
fls
mir ist keine möglichkeit bekannt den c code zu simulieren. Wenn du isim
startest und in einer vhdl testbench deinen Prozessor mit einbindest,
ist ja auch erstmal nur der Prozessor drin, ohne irgendeinem c code, ich
wüsste nicht wie mann diesen auch reinbringen sollte. Der c code wird,
nachdem der vhdl code ordnungsgemäß simuliert wurde und funktioniert, im
sdk debugt.
Vielen Dank für die Antwort matzunami!
Das C-Programm funktioniert auf dem FPGA, mir geht es jetzt weniger um
debuggen. Ich würde mir gerne anschauen, wie das Zeitverhalten von dem
Zusammenspiel zwischen Prozessor und meiner eigenen IP ist. Also zB nach
wie lange es dauert bis ich eine Antwort bekomme, nachdem ich Daten
losgeschickt habe.
Wenn sonst noch jemand eine Idee hat ob und wie man das hinbekommen kann
würde ich mich freuen.
Grüße
fls
Danke für den Tipp, ich werde es mir mal anschauen.
Bis jetzt habe ich mit Chipscope allerdings noch keine Erfahrung, kann
ich damit auch das Zeitverhalten erfasssen oder beeinflusst Chipscope
den Prozess? Verändere ich also durch das Messen das Verhalten?
Hast du ERfahrung wie viel aufwendiger die Generierung durch Chipscope
wird?
also chipscope an sich ist recht simpel in der Verwendung. Ich hatte
allerdings auch einmal ein Design, das den FPGA schon reichlich
ausgefüllt hat. Der chipscope core hat mir da das timing meines
eigentlichen Designs kaputt gemacht (Timingerrors). Ich hab mich da
allerdings nicht weiter damit befasst und hab die entsprechenden Signale
auf I/Os gelegt und mit dem Oszi gemessen. An sich ist dein
Zeitverhalten ja in Contraints festgelegt und wenn diese nach dem
einbinden des chipscope cores immer noch eingehalten werden ist alles
ok. Gerade in der Erfassung reeller Taktzeiten (also von Signal wird
High gesetzt, wie lange dauert in der Hardware wirklich die reaktion
drauf), ist chipscope sehr nützlich. Die Messsignale werden im internen
bram gespeichert, also solltest du noch einige davon übrig haben.
also du kannst entweder manuell eine icon und ila instanz erzeugen in
deinem code und die signale darauf legen oder aus der chipscope software
heraus auswählen welche signal du ansehen möchtest und zu welcher clock
die synchron sind, dann baut er das automatisch mit ein.
Früher oder Später sollte man sich mit ChipScope / SignalTap befassen,
da das ein wichtiges Debugging bzw. Analyse Tool ist.
Spätestens dann wenn die Synthesezeit < Simulationszeit ist ;)
@fls:
Um nochmal auf Deinen ursprünglichen Weg zurückzukommen.
Ich simuliere mir auch meine embedded Prozessoren inklusive C-Programm.
Im Modelsim geht es, das sollte auch im ISIM gehen.
Allerdings mußt Du Dir überlegen, an welcher Stelle im Flow der Seicher
mit dem Programm gefüllt wird. Für die Synthese wird üblicherweise der
Weg gegangen, das bit-File mit Hilfe des bmm-Files zu aktualisieren.
Für die Simulation mußt Du den Speicher anders füllen. M.E. ging das mit
den BRAM-Init-Strings, die da auch irgendwo mit erzeugt werden.
Duke
Wenn dies möglich ist würde mich das auch interessieren... könntest du
die Vorgehensweise eventuell etwas genauer beschreiben? Bzw. kennst du
eine Dokumentation, wo dies näher beschrieben wird?
gruß
matzunami
@matzunami:
Da ich momentan keinen Microblaze benutzen kann, verwende ich die ZPU.
Dort habe ich hier einen etwas anderen Ansatz:
1. langsamen Flow, Simulation
gcc -> zpuromgen -> xst -> ... -> bitgen -> impact bzw.
gcc -> zpuromgen -> vcom
2. schneller Flow (nur update der Software)
gcc -> data2mem -> impact
Schau Dir mal die Dokumentation von data2mem an. Da steht auch der
Simulationsflow als "use-case" drin.
Duke
@ Duke
Das sind ja mal gute Nachrichten, dass man es doch simulieren kann.
Ich habe mir jetzt auch die Data2mem-Dokumentation durchgelesen, aber
ich werde irgendwie nicht schlau aus der ganzen Sache.
Normalerweise erzeuge ich mir ja im XPS mit den Menüpunkten Generate...
Netlist/Bitstream/Libraries usw. die Dateien um sie dann auf den FPGA zu
laden.
Für die Simulation erzeuge ich mir in XPS mit Generate Simulation HDL
Files die nötigen DAteien und öffne damit dann den ISIM.
Kannst du mir nochmal genau sagen, wo ich jetzt was hinzufügen muss, um
den Speicher mit den BRAM-Init-Strings füllen kann?
Ich bin über jede Hilfe dankbar, weil im Moment stehe ich total auf dem
Schlauch.
@ matzunami
Wenn es bei dir jetzt auch klappt, würde ich mich von dir natürlich
genauso über Tipps freuen.
Vielen Dank schonmal und viele Grüße,
fls
Ich muss die problematik etwas nach hinten verschieben, da ich momentan
keine Zeit für hab. Werd mir das aber bei gelegenheit auf alle fälle mal
anschauen.
