Prozessor Core debuggen - wie?

[Sebastian B. (sfreak)]

Hi,

ihr habe vielleicht schon meine Hilfeschreibe bzgl. LM32 auf 
Xilinx-FPGAs gelesen. Der laeuft nun erstmal. Jetzt mache ich mir ueber 
Software Gedanken. Bevor ich zum LM32 komme habe ich mir erstmal 
angeschaut wie das ganze fuer den Microblaze laeuft:

Ich habe davon gelesen man in den Xilinx-Tools "BSCAN" instanziieren 
kann um eigene Komponenten daran anzuschliessen. Handelt sich dabei 
tatsaechlich um den "normalen" JTAG Port ueber den auch der ganze FPGA 
programmiert wird (das nehme ich jetzt mal an)?

Fuer Xilinx-Chips und den Microblaze Prozessor ist wohl EDK das Tool der 
Wahl zum Programmieren und Debuggen (habe es zugegebenermassen noch 
nicht benutzt). Allerdings finde ich die Doku dazu eher verwirrend da 
sie hauptsaechlich aus (fuer mich noch) unverstaendlichen Abkuerzungen 
besteht. Wuerde ganz gerne erstmal das Grundprinzip verstehen... kennt 
jemand eine gute Einfuehrung?

Soweit ich den Grobaufbau verstanden habe (TMS, TCK weggelassen):

  Platine    |   FPGA
             |       ______________ 
             |      |              |
 JTAG TDI ---+------+ TDI  MDM     +---- Microblaze
             |   /--+ TDO (BSCAN?) |
             |   |  |______________| 
             |   |
             |   |    _____________________________________________
             |   |   |                                             |
             |   \---+ TDI  FPGA JTAG Logik                        |
      TDO ---+-------+ TDO  (boundary scan, Konfiguration ...)     |
             |       |_____________________________________________|
             |
             |

Wie schaut es mit Altera und Lattice aus? Haben die auch so eine 
erweiterbare JTAG-Chain?

Welche anderen Debug-Moeglichkeiten gibt es und wo/wieso werden sie 
eingesetzt?

Gruesse,
Sebastian

[Duke Scarring (Gast)]

So wie ich das verstanden habe, kommst Du mit BSCAN nicht an das 
komplette JTAG-Interface ran, sondern nur an die USER1 und USER2 
Leitung. (Bzw. nur die sind zum Daten transferieren vorhanden.)

Über diese Leitungen kannst Du bitseriell Daten übertragen. Bei Xilinx 
gibt es auch eine Appnote, in der diese Datenübertrageun beschrieben ist 
und zum Update eines BRAMs genutzt wird.

Das ganze Debugging vom EDK, was über JTAG abgewickelt wird ist 
proprietär und vermutlich auch nicht wirklich dokumentiert.

Ich verwende zum Debuggen den LogicAnalyzer von 
http://www.sump.org/projects/analyzer/ mit einem vorgeschalteten 
Multiplexer um mehr Eingangskanäle zu haben.

Duke

[Christian R. (supachris)]

Du kannst/musst den MicroBlaze über der normalen JTAG Anschluss des FPGA 
Debuggen. Musst halt im EDK beim Zusammenstellen des Systems dieses 
JTAG-Debug-Modul mit einbinden. Ohne EDK geht da sowieso überhaupt nix, 
also freunde dich schon mal mit dem Ding an. Und ja, es ist verwirrend 
und wenig dokumentiert, deshalb erst mal die Beispiel-Designs anschauen. 
Noch verwirrender wird´s, wenn man eine Logik im FPGA mit dem Prozessor 
verbinden will, und das dann auch noch möglichst schnelle Übertragung 
sein soll. Ich sitze gerade an einer LocalLink Implementierung, um im 
Virtex 4 Daten von einem anderen FPGA per DMA an den GbE-MAC zu 
schicken. Nix dokumentiert, und das auch noch falsch. LocalLink Spec 
darf ich nicht runterladen, obwohl wir registriert sind und 
Wartungsvertrag für EDK, ISE und Modelsim haben. Naja. Ein Spaß....

[Sebastian B. (sfreak)]

Hi,

scheint als wuerde es mit dem FPGA-JTAG doch nicht so einfach klappen 
wie ich gehofft hatte. Hab es auch nach stundenlanger Suche nicht 
geschafft irgendwelche hilfreiche Dokumantation aufzutun, allerdings ist 
"jtag" in Kombination mit xilinx/fpga/softcore/... auch kein besonders 
guter Suchbegriff... gibt's eine sinnige Bezeichnung fuer Debugging von 
CPUs im FPGA?

Das EDK/XPS hab ich mir inzwischen auch mal angesehen. Ganz nett, aber 
so weit weg von der Hardware will ich eigentlich gar nicht :-) Ausserdem 
hilft  mir das Tool bei Verwendung von nicht-Xilinx Cores natuerlich 
herzlich wenig. Aber so hab ich zumindest mal einen Eindruck bekommen 
was im Idealfall moeglich ist.

Welche Moeglichkeiten zum Debuggen gibt es denn fuer andere Cores, ich 
denke da an die dutzenden von Prozessoren auf opencores.org, da wird ja 
sicher auch nicht jede Software auf Anhieb funktionieren. Aber 
saemtliche Projekte bei opencores haben die Gemeinsamkeit das die Doku 
nochmal um Groessenordnungen schlechter ist als bei den grossen 
Herstellern... schwer da einen Einstieg zu finden.

Hat jemand da Erfahrung und mag mich in die richtige Richtung weisen?

Sebastian

[Christian R. (supachris)]

Also ob die Cores auf open-Core debuggbar sind, das weiß ich nicht. Die 
Debug-Logik muss ja dann extra implementiert sein. Ich kann dir nur 
helfen, was den MicroBlace oder den echten PPC405 betrifft. Das geht für 
einfache Sachen recht simpel im EDK/XPS. Debuggen mit der Eclipse geht 
auch ziemlich gut (wenn man den USB Programmer hat). Sehr weit entfernt 
von der Hardware ist das auch nicht, eigene Cores lassen sich (wenn man 
das System erst mal verstanden hat) recht simpel einbinden. Externe Pins 
vergeben und interne Bus-verbindungen (PLB, FSL, LocalLink....) gehen 
nach einer gewissen Einarbeitung auch recht gut.

[Günter -. (guenter)]

Genau hab ich mich damit aber auch noch nicht beschäftigt. Hier ist der 
Projektlink zu einem Debuginterface auf OpenCores:

http://www.opencores.org/projects.cgi/web/DebugInterface/overview

Eine andere Möglichkeit von der ich mal gelesen habe ist GDB zu 
verwenden. Es gibt da einen GDB-Stub der auf dem Zielsystem läuft. Der 
GDB-Stub kann über UART oder TCP/IP mit GDB verbunden werden.

Dann gibt es da noch openOCD http://openocd.berlios.de/web/, das auch 
mit GDB zusammen zu arbeiten scheint.

[Sebastian B. (sfreak)]

Günter -.. wrote:
> Eine andere Möglichkeit von der ich mal gelesen habe ist GDB zu
> verwenden. Es gibt da einen GDB-Stub der auf dem Zielsystem läuft. Der
> GDB-Stub kann über UART oder TCP/IP mit GDB verbunden werden.

In das Thema musste ich mich erstmal einlesen. Habe gdb zwar schon oft 
benutzt, mit aber nie Gedanken gemacht was eigentlich intern passiert. 
Sehr interessant!

Zum Thema gdb-stubs:
http://www.embedded.com/1999/9909/9909feat2.htm
http://www.embedded.com/1999/9911/9911feat3.htm
http://www.redhat.com/support/wpapers/cygnus/cygnus_gdb/

Das scheint soweit ich es bisher beurteilen kann meine beste Chance zu 
sein da voellig unabhaengig von FPGA und Hersteller-Tools und 
-Restriktionen. Habe nun festgestellt das es fuer den LM32 Prozessor 
sogar schon einen gdb-stub gibt (im soc-lm32), nur ist der offenbar 
nicht fertig. Daran weiter zu arbeiten traue ich mir noch nicht so ganz 
zu aber mal sehen, ich werde einen Blick drauf werfen.

DebugInterface und OpenOCD werd ich mir auch noch anschauen.

Vielen Dank fuer den Tipp!
Fuer weitere Ideen bin ich natuerlich immer noch zu haben :-)

[Sebastian B. (sfreak)]

Noch zu gdb-stubs:
http://sourceware.org/gdb/current/onlinedocs/gdb_18.html

[Klaus Rindtorff (Gast)]

Noch eine weitere Idee:
Wenn es im wesentlichen um das online debuggen der software geht und 
eine VGA display schon Teil des designs ist, kann man die wichtigsten 
Daten einfach mit in die VGA Ausgabe einblenden. Dazu ein hold-signal 
für die CPU und ein single-step button und fertig ist der debugger. 
Kostet zwar etwas an FPGA resourcen, ist aber dafür recht konfortabel. 
Hat sich bei meinem core gut bewährt.

MfG, Klaus