Hallo zusammen, ich suche eine Softcore Alternative für den NiosII. Ich kenne die FPGA Soft Core Seite hier: http://www.mikrocontroller.net/articles/FPGA_Soft_Core Ich suche eine 32-Bit Lösung mit Compiler und Debugger. Auch bei OpenCores habe ich geschaut, aber ich glaube eine Lösung mit Compiler und Debugger ist hier das OpenRISC Projekt. Weiterhin könnte auch soc-lm32 eine Alternative sein. Ich weiß aber nicht ob es hier auch einen Debugger für gibt. Plattform ist Altera, Compiler und Debugger müssen unter Windows laufen. Gibt es Erfahrungsberichte und Vorschläge von Eurer Seite? Viele Grüße, Michael
Michael Fischer schrieb: > Hallo zusammen, > > ich suche eine Softcore Alternative für den NiosII. > Ich kenne die FPGA Soft Core Seite hier: > http://www.mikrocontroller.net/articles/FPGA_Soft_Core > > Ich suche eine 32-Bit Lösung mit Compiler und Debugger. > Auch bei OpenCores habe ich geschaut, aber ich glaube > eine Lösung mit Compiler und Debugger ist hier das OpenRISC > Projekt. Weiterhin könnte auch soc-lm32 eine Alternative > sein. Ich weiß aber nicht ob es hier auch einen Debugger > für gibt. > > Plattform ist Altera, Compiler und Debugger müssen unter > Windows laufen. > > Gibt es Erfahrungsberichte und Vorschläge von Eurer Seite? > > Viele Grüße, > Michael Ja, die Mais-CPU geht. Ich habe dien Tools noch nie unter Windows gebaut. Kannst du den GCC und den GDB selber bauen? Das müsste am besten unter Cygwin gehen. Das es eine Makefile gesteuerte Geschichte ist. Ich muss heute Abend mal nachschauen, was ich für dich alles schon hätte.
René D. schrieb: > Michael Fischer schrieb: >> Hallo zusammen, >> >> ich suche eine Softcore Alternative für den NiosII. >> Ich kenne die FPGA Soft Core Seite hier: >> http://www.mikrocontroller.net/articles/FPGA_Soft_Core >> >> Ich suche eine 32-Bit Lösung mit Compiler und Debugger. >> Auch bei OpenCores habe ich geschaut, aber ich glaube >> eine Lösung mit Compiler und Debugger ist hier das OpenRISC >> Projekt. Weiterhin könnte auch soc-lm32 eine Alternative >> sein. Ich weiß aber nicht ob es hier auch einen Debugger >> für gibt. >> >> Plattform ist Altera, Compiler und Debugger müssen unter >> Windows laufen. >> >> Gibt es Erfahrungsberichte und Vorschläge von Eurer Seite? >> >> Viele Grüße, >> Michael > > Ja, die Mais-CPU geht. > Ich habe dien Tools noch nie unter Windows gebaut. > Kannst du den GCC und den GDB selber bauen? > Das müsste am besten unter Cygwin gehen. Das es eine Makefile gesteuerte > Geschichte ist. > > Ich muss heute Abend mal nachschauen, was ich für dich alles schon > hätte. Hi, Ich habe schon mehrmals erfolgreich gcc und gdb mit mingw32 übersetzt. Der Vorteil dabei ist, dass man nachher kein cygwin braucht um die laufen zu lassen. Ist vielleicht etwas für Dich. Gruß Martin
Michael Fischer schrieb: > Plattform ist Altera, Compiler und Debugger müssen unter > Windows laufen. > > Gibt es Erfahrungsberichte und Vorschläge von Eurer Seite? Ich habe mit der ZPU gute Erfahrungen gemacht, und inzwischen einige Cores um vernünftige JTAG-Debugger aufgebohrt. Allerdings sind das recht spezialisierte Lösungen geworden, deshalb auch nix OpenSource und auch teurer als die Lösungen der üblichen Verdächtigen. Für die lm32 gibt es auch Front-Ends, ich denke, beim milkymist-Projekt könntest du fündig werden. Ansonsten ist es bei den meisten FPGAs schwierig, eine vernünftig nutzbare JTAG-Lösung zu finden, da die Primitiven oft bisschen anders funktionieren als dokumentiert (ein Schelm, wer böses dabei denkt). Grüsse, - Strubi
Hallo zusammen, Danke für die Infos. GCC und GDB für Windows sollte eigentlich kein Problem sein. Da sollte ich Übung durch YAGARTO haben. Viele Grüße, Michael
Hallo Strubi, >Ansonsten ist es bei den meisten FPGAs schwierig, eine vernünftig >nutzbare JTAG-Lösung zu finden, da die Primitiven oft bisschen anders >funktionieren als dokumentiert (ein Schelm, wer böses dabei denkt). Das verstehe ich nicht so richtig. Beziehst Du dich hier auf den JTAG der FPGAs? Mir würde auch eine Lösung gefallen wo der JTAG der CPU nichts mit dem JTAG des FPGA zu tun hat. D.h. man hat einmal den originalen JTAG für das FPGA selbst. Und dann noch einen JTAG an der CPU. Viele Grüße, Michael
Hi Michael, > >>Ansonsten ist es bei den meisten FPGAs schwierig, eine vernünftig >>nutzbare JTAG-Lösung zu finden, da die Primitiven oft bisschen anders >>funktionieren als dokumentiert (ein Schelm, wer böses dabei denkt). > Das verstehe ich nicht so richtig. Beziehst Du dich hier auf den JTAG > der FPGAs? > Ja, die eingebaute harte JTAG-Primitive, die von Haus aus Boundary Scan und Programmierung des FPGA, usw. erledigt. Meist haben die zwei oder mehrere vom User nutzbare Register. Bei Xilinx Spartan6 ist das schon ganz brauchbar, leider für jede FPGA-Familie unterschiedlich implementiert. Bei Lattice ist das alles etwas generischer gehalten, dafür kann man beim Timing da einiges falschmachen. Bei Altera bin ich noch nicht tief genug vorgestossen. > Mir würde auch eine Lösung gefallen wo der JTAG der CPU nichts mit > dem JTAG des FPGA zu tun hat. D.h. man hat einmal den originalen JTAG > für das FPGA selbst. Und dann noch einen JTAG an der CPU. > So habe ich das anfangs bei der ZPU auch gemacht, bzw. mache das noch bei mehreren Cores in der Chain so, dass es neben dem System-JTAG zum Programmieren des FPGA noch einen als Soft-IP implementierten User-JTAG für die Multicoreseite gibt. Das ist dann komplett architekturunabhängig. Grüsse, - Strubi
Hallo Strubi, könntest Du so eine Lösung als OpenSource rausgeben, wäre das möglich? Das wäre dann ja auch eine allgemeine Lösung für die Mais und lm32 CPU. Wobei ich nicht weiß wie kompliziert es ist das JTAG Interface hier einzubinden. Was dann noch fehlt ist der "GDB-Proxy". Viele Grüße, Michael
Hi Michael, die ZPU-Emulationsanbindung ist OpenSource, eine host-seitige Emulations-Library ist da auch mit bei, ansonsten sind aber die Tools (wie der uniproxy für GDB <-> JTAG) und JTAG-Layer nicht offengelegt. Habe schlechte Erfahrungen mit div. Herstellern zum Thema Geben vs. Nehmen und Opensource-Lizenzen gemacht, in den Debug-Tools steckt sehr viel Arbeit, bis sie mal richtig stabil und schnell laufen. Darum kette ich die Software lieber an Projekte, ansonsten frisst mich der Support auf. Ansonsten gibt es aber auch Ansätze per OpenOCD, die sind oft nicht sonderlich robust, aber funktionieren für die meiste Entwicklung. Könnte sein, dass es da für die ZPU auch schon was gibt. Grüsse, - Strubi
Cortex-M1 ist auch eine schöne Idee. Aber ich glaube nicht das es hier eine freie Version gibt, oder? Entschuldigung, das hatte ich oben vergessen. Ich suche eine frei Alternative. Viele Grüße, Michael
:
Bearbeitet durch User
Hallo zusammen, Danke für die Antworten, ich werde es wohl mal mit dem lm32 versuchen. Viele Grüße, Michael
Hi Michael, kannst uns gerne auf dem Laufenden halten, wie das mit dem lm32 auf anderen Architekturen (mit JTAG) vonstatten geht. Ansich finde ich das Teil heiss (ist ja nahe an der MIPS-Architektur, aber beinhaltet doch einige Optimierungen). Leider konnte ich ihn - da Verilog - nicht ohne weiteres brauchen. Codegrösse war mir auch noch etwas ein Dorn im Auge, da hat die MIPS16-extension die Nase vorn. Grüsse, - Strubi
Hallo Strubi, MIPS16 sagt mir nichts. Wie groß ist denn bei Dir die CPU mit I/D Cache HW-Multiplyer und HW-Divider? Damit man mal eine Hausnummer zum Vergleichen gegenüber dem lm32 hat. Viele Grüße, Michael
:
Bearbeitet durch User
Hi Michael, die nackte CPU, ohne Cache und HW-Divider (Division wird intern emuliert) aufm Spartan6:
1 | Slice Logic Utilization: |
2 | Number of Slice Registers: 1,726 out of 54,576 3% |
3 | Number of Slice LUTs: 2,367 out of 27,288 8% |
Da sind jetzt noch die Register (64x32 bit) als distributed RAM mit drinne, wenn man die ins BRAM legt, sind's noch weniger, dafür geht die Taktfrequenz runter. MIPS16 ist ne Erweiterung, die die 32-bit-Opcodes in 16-Bit-Opcodes packt. Zudem sind noch einige Extras wie pc-relative Adressierung dabei, das kostet auch noch bisschen Logik. Am platzsparendsten war bisher die ZPU mit rund 660 Slices. Grüsse, - Strubi
Hi Strubi! Hast Du nun die MIPS16_extensions für den Mais implementiert, oder wie ist das zu verstehen? Und ist das auch mit JTAG debugbar?
Moin, die mips16-ASE bzw. der zugrundeliegende MIPS32-Core ist ein komplettes Redesign in Python (myHDL). Ist zum Mais ähnlich, aber hat eine etwas andere Pipeline und ist auf andere Decoder-Module umkonfigurierbar (DLX, lm32-Clone hab ich mal spasseshalber angefangen, aber nicht fertiggemacht). Leider funktioniert das Debuggen des mips16-Code nur bedingt optimal, das hat aber mit dem etwas wackligen Handling des ISA-Bits im GDB zu tun. Ansich sind die mips16-Erweiterungen nur sinnvoll, wenn man sehr abgespeckte Systeme benötigt, aber da kann man ev. auch gleich die Small-Variante der ZPU nehmen (sofern die Lahmheit letzterer nicht weh tut :-) ) Grüsse, - Strubi
Kennt jemand das hier: http://www.apollo-core.com/ - Compatible with MC68000 - Dual Integer Instruction Execution - Branch Cache - Full Harvard Architecture - 32bit Address bus - DDR DRAM Memory - 128 bit Deep Store Buffer - memory stream detection and prefetching
Hallo Strubi, >kannst uns gerne auf dem Laufenden halten, wie das mit dem lm32 auf >anderen Architekturen (mit JTAG) vonstatten geht. Im Prinzip hat jetzt mein TAP-Controller funktioniert. Ich konnte mit dem Lattice Programmer den IDCODE und auch mein USERCODE Register auslesen. Wenn ich dann aber den Lattice Debugger verwendet habe, gab es ein Problem das die CPU nicht erkannt wurde. Nach einem JTAG Trace habe ich festgestellt das z.B. IR-Register 0x00 und auch 0x32 angesprochen werden. Da ich hier keine Info habe was diese Register machen, komme ich auch nicht weiter. Weiterhin sieht es so aus als das bei normalen JTAG Zugriffen nTRST negative aktive ist. Wobei später wenn der Debugger läuft nTRST die Polarität wechselt, d.h. jetzt positive aktive. Da die nötigen Infos hier fehlen, werde ich mit JTAG beim lm32 nicht weitermachen. Ich glaube das JTAG für MIPS hier der bessere Weg sein könnte. Viele Grüße, Michael
:
Bearbeitet durch User
Michael Fischer schrieb: > Hallo Strubi, > >>kannst uns gerne auf dem Laufenden halten, wie das mit dem lm32 auf >>anderen Architekturen (mit JTAG) vonstatten geht. > > Im Prinzip hat jetzt mein TAP-Controller funktioniert. Ich konnte mit > dem Lattice Programmer den IDCODE und auch mein USERCODE Register > auslesen. Du hast also einen eigenen TAP Controller an normalen FPGA IOs implementiert? Ist sicher die einzige Möglichkeit ein Hersteller- und Deviceunabhängiges Interface zu machen. > > Wenn ich dann aber den Lattice Debugger verwendet habe, gab es ein > Problem das die CPU nicht erkannt wurde. Nach einem JTAG Trace habe > ich festgestellt das z.B. IR-Register 0x00 und auch 0x32 angesprochen > werden. Da ich hier keine Info habe was diese Register machen, komme > ich auch nicht weiter. 0x32 ist ER1, und dass das Zusammenspiel zwischen ER1,ER2 und jtagconn16 nicht dokumentiert ist, wurde schon erwähnt. Beitrag "Re: Verständnisproblem beim JTAG für LM32 (Lattice)" Da wäre also Reverseengenierung angesagt, wofür man natürlich einen Lattice FPGA bräuchte. Ist vermutlich nicht allzu schwer, da die prinzipielle Idee im obsoleten er1.v ja erklärt ist. > > Weiterhin sieht es so aus als das bei normalen JTAG Zugriffen nTRST > negative aktive ist. Wobei später wenn der Debugger läuft nTRST > die Polarität wechselt, d.h. jetzt positive aktive. > Lattice FPGAs verwenden nTRST nicht. > Da die nötigen Infos hier fehlen, werde ich mit JTAG beim lm32 nicht > weitermachen. > Schade, vor allem weil du bereits an der ersten vorhersehbaren Hürde aufgibst.
der TSK3000 ist lizenzfrei in eigenen Designs zu benutzen. Der Jtag Adapter hat einen Hard-Jtag Anschluss für die Konfiguration des FPGAs und einen SoftJtag für das Debuggen der TSK3000 CPU. Läuft auf allen gängigen FPGAs, es gibt dutzende Hardware und Software Komponenten für diese CPU inclusive. Gruß, dasrotemopped. PS: man muss natürlich eine Altium Lizenz haben .. (die FPGA Core version reicht, wenn man kein eigenes Board machen will, ist beim Nanoboard 3000 für ein Jahr inclusive, bei Farnell auf Lager)
Moin, also soweit ich mich erinnere (ist schon ein Jahr her) enthalten die nicht dokumentierten Module nur diverse Klimmzüge, um Reveal zusammen mit einem oder mehrerern lm32 irgendwie parallel zu betreiben. Da gibt es aber scheints einige Böcke im JTAGLServer (nicht offengelegt), von div. Lattice-Usern (no pun intended) gab es auch im Vorfeld leise Hinweise, dass das im Langzeitbetrieb nicht sonderlich stabil ist. Das lm32-System lief bei mir auch nicht auf Anhieb zufriedenstellend, drum habe ich erst gar nicht damit angefangen, genau auch aus dem Grund, dass ich ein herstellerunabhängiges SoC/Debugger-System 1:1 weiterverwenden wollte. Im Prinzip kann man mit geeignetem Multiplexen die ER1/ER2 (auf Xilinx USER1-USER4, je nach Plattform) eine Menge Register "tunneln". ER1 ist z.B. ein Control-Register mit einem "SELECT"-Bitfeld, je nach SELECT-Wert kann man in ER2 was anderes einblenden. Also kannst du dir auch auf simplerem Weg Multicore-Support oder dein eigenes 'Reveal' stricken. Wenn Du die Shift-Register an der ER1/ER2 chain richtig anbaust (mit erwähntem Abclock-Workaround), musst Du nur noch den lm32-TAP isolieren. Bist Du schon soweit vorgedrungen, wie die Emulation beim lm32 funktioniert? Gruss, - Strubi
Hallo Strubi, >Im Prinzip kann man mit geeignetem Multiplexen die ER1/ER2 (auf Xilinx >USER1-USER4, je nach Plattform) eine Menge Register "tunneln". Das ist richtig, dann hat man aber die Probleme das hier nicht mehr die Instruction 0x32 und 0x38 verwendet werden. D.h. man kann die Lattice Tools nicht mehr verwenden, oder kann man das da umstellen? >ER1 ist z.B. ein Control-Register mit einem "SELECT"-Bitfeld, je nach >SELECT-Wert kann man in ER2 was anderes einblenden. Das könnte ein Problem sein warum es bei mir nicht weiter ging. Aber wie wird aktuell die Umschaltung gemacht, wenn der alte Code, er1.v, nicht mehr verwendet wird? Ich muß aber auch zugeben das ich den Code in er1.v nicht verstanden habe. Gruß, Michael
Hi Michael, , > >>Im Prinzip kann man mit geeignetem Multiplexen die ER1/ER2 (auf Xilinx >>USER1-USER4, je nach Plattform) eine Menge Register "tunneln". > Das ist richtig, dann hat man aber die Probleme das hier nicht mehr die > Instruction 0x32 und 0x38 verwendet werden. D.h. man kann die Lattice > Tools nicht mehr verwenden, oder kann man das da umstellen? > Nee, umstellen kann man da nix, du kannst nur die 0x32 und 0x38 selber verwenden, alle andern sind hart codiert. Hab' es nicht ganz präzise ausgedrückt, deshalb ein Beispiel: Du implementierst z.B. auf 0x32 ein 16 bit langes Register, davon nutzt Du 4 Bit als SELECT. Je nach Wert in SELECT muxt du Register A, B, oder C, usw. in die 0x38 scan chain. Die A, B, C, .. können dann unterschiedliche Längen haben. Nicht alle JTAG-Tools kommen allerdings mit sich dynamisch jenach Registerwert unterschiedlichen Scanchain-Längen klar. Den JTAGLServer kannst du dann nicht mehr nutzen. Aber es ist kein riesen Ding, einen gdbproxy oder rproxy drauf anzupassen, auf den dann der lm32-gdb connected. >>ER1 ist z.B. ein Control-Register mit einem "SELECT"-Bitfeld, je nach >>SELECT-Wert kann man in ER2 was anderes einblenden. > Das könnte ein Problem sein warum es bei mir nicht weiter ging. Aber > wie wird aktuell die Umschaltung gemacht, wenn der alte Code, er1.v, > nicht mehr verwendet wird? > Wenn ich mich recht erinnere, gab es keine Umschaltung, es wurden einfach 16 Kanäle in die Scanchain reingemappt. Aber nagel mich da nich drauf fest. > Ich muß aber auch zugeben das ich den Code in er1.v nicht verstanden > habe. > Schmeiss einfach weg :-) Meist ist ein Neudesign gar keine so doofe Idee, grade wenn's um Debuggen geht. Konnte mit den .v-Files auch nix anfangen.. Grüsse, - Strubi
Hallo zusammen, ich bin auch an einem generischen Tap controller für den lm32 interessiert. Hier wurde ja offenbar schon eine lm32-Unterstützung in openocd eingebaut: http://git.serverraum.org/ Im Wesentlichen steht alles in diesem File hier: http://git.serverraum.org/?p=mw/openocd-lm32.git;a=blob;f=src/target/lm32.c;hb=HEAD
Hallo! Den allgemeinen TAP Controller gibt es quasi hier schon fertig: http://opencores.org/websvn,filedetails?repname=jtag&path=%2Fjtag%2Ftrunk%2Ftap%2Frtl%2Fverilog%2Ftap_top.v Es sollten lediglich die Boundary Scan und Mbist chains entfernt werden, da sie erstmal nicht notwenig wären. Folgende Signale müssen korrespondieren im Modul jtag_tap: shift <-> shift_dr_o update <-> update_dr_o tck <-> tck_pad_i(input) reset <-> aktuell nicht vorhanden. Assert, wenn in State Test Logic Reset tdo(input) <-> tdo_o(output) tdi(output) <-> debug_tdi_i(input)
Hallo! Ich habe mal einen allgemeinen JTAG TAP Controller basierend auf dem von opencores.org angehängt. Synthese für einen Virtex-5 lief durch. jtag_cores.v und lm32_top.v müssen natürlich entsprechend angepasst werden, um die JTAG-Signale für die I/O Pins durchzuschleifen.
:
Bearbeitet durch User
Hallo Christian, im offiziellen 0.8.0 Source kann ich aber nichts vom lm32 finden. Es sieht so aus als wenn hier keine Unterstützung vorhanden ist. Gruß, Michael
Was genau meinst Du mit "0.8.0 Source"? UPDATE: Ok, openocd-0.8.0 Dann müsste das lm32 target dort wieder eingeplegt werden.
:
Bearbeitet durch User
Hallo zusammen, da ich Euch in der letzten Zeit wegen JTAG gelöchert habe, gibt es nun von mir meine JTAG Umsetzung im Anhang. Weiterhin gibt es eine Beschreibung des Projektes auf meiner Webseite: http://www.emb4fun.de/fpga/jtag/index.html Viele Grüße, Michael
Thread beobachten
Seitenaufteilung abschaltenBitte 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.