Hallo, ich schildere mal mein Anliegen: Ich habe ein FPGA System. Der FPGA ist momentan festgelegt auf einen MAX10 mit 4000LE. Durch Migration sind aber auch mehr möglich. Das Design umfasst momentan ein kleines Bussystem, an dem verschiedene Module hängen. Für einige sequenzielle Abarbeitungen stelle ich gerade fest, dass das als State-machine im FPGA zu unangenehm wird und auch schlecht änderbar/wartbar ist. Deshalb will ich noch einen kleinen Softcore einbauen. Einen NIOS-Prozessor möchte ich nicht verwenden, da ich das Design gerne auch Altera-unabhängig hätte und auch lieber frei verfügbare Dinge einsetze. Außerdem ist der NIOS ziemlich groß und für diese Aufgabe überdimensioniert. Das interne Bussystem besteht momentan aus einem eigenen Bus. Allerdings sind diese simplen Busse ja eh alle ziemlich gleich, sodass es problemlos möglich sein sollte über ein wenig Glue-Logic etwas mit Avalon oder Wishbone anzuschließen. Meine Spezifikationen zur CPU sind folgende: 1. Wenn möglich in VHDL (ich verwende GHDL zum simulieren und kann kein Verilog/mixed language). Das ist aber kein muss. Wäre nur schön :) 2. Wie oben geschrieben, ein Interface, das sich ohne sehr große Mühe anbasteln lässt. AXI3 oder sowas würde ich gerne vermeiden. 3. Was die "Bitbreite" angeht bin ich offen. Momentan ist der interne Bus 32 bit. Da aber 32 bit Prozessoren in der Regel auch größer sind, darf es gerne ein 8 bitter sein, der dann eben über Glue-Logic angebaut wird. 4. Der Core benötigt keine fancy Features wie MMU, MPU. Selbst auf Interrupts kann ich verzichten. Er muss lediglich nach dem Reset einige Speicherbereiche lesen/schreiben und einige Abläufe koordinieren. Um eine Hausnummer zu liefern: Ein AVR-Befehlssatz ohne Multiplizierer ist absolut ausreichend. 5. Zur SW-Entwicklung wäre mir ein GCC oder sowas recht. (Mit Linkerskripten etc kenne ich mich aus). sollte es keinen GCC geben, wäre zumindest ein unter Linux lauffähiger/kompilierbarer Assembler wünschenswert. Die Abläufe, die ich programmieren will, sind auch noch in Assembler überschaubar. Erfahrungen mit Cores habe ich hauptsächlich mit den "Klicki-Bunti" teilen von Altera/xilinx (Nios und Microblaze), aber auch schon von Hand mit einem OR1200. Kennt jemand einen simplen Core für mich?
Vielleicht suchst Du sowas: https://github.com/pulp-platform/zero-riscy Ist leider kein VHDL sondern Systemverilog, aber es gibt ein passenden GCC. Für die anderen Fragen (Bus etc) musst Du mal in die Doku schauen.
Wie wäre es mit PicoRV32? Sehr einfaches Interface, sehr hohe Taktfrequenz (allerdings mehrere Takte/Befehl), sehr klein und formal gegen die Spezifikation verifiziert. Ist allerdings Verilog. Nachtrag: https://github.com/cliffordwolf/picorv32
:
Bearbeitet durch User
M. H. schrieb: > Kennt jemand einen simplen Core für mich? Check opencores.org bzgl. Wishbone-komponenten und system https://opencores.org/projects?expanded=System%20on%20Chip oder die Klassiker der Computerkids: http://www.syntiac.com/fpga64.html Da macht dir opa noch was in Sachen Hardwarenahes Programmieren vor.
Klingt nach einer guten Anwendung fuer den Picoblaze, oder eine der frei verfuegbaren Nachimplementierungen (Pacoblaze, Nanoblaze, Pauloblaze, etc). Sind nur in assembly programmierbar, das dafuer recht gut, insbesondere mit opbasm.
M. H. schrieb: > > Kennt jemand einen simplen Core für mich? Moin, wenn es maximal kompakt/stromsparend aber nicht sonderlich schnell sein muss, noch einige ghdl-kompatible Optionen: - ZPU-Architektur (da gibt es auch einige schnelle Varianten von) - msp430-kompatibler neo430 Punkto Befehlssatzdichte sind die beiden meine heimlichen 'Testsieger'. Den neo430 habe ich als Default-Testlauf mal in einen Docker-Container gepackt (macht sich prima für CI/Regresstests in der Cloud), siehe auch https://hub.docker.com/r/hackfin/masocist/. Ist aber eher was für Linux-affine, die weniger auf Klickibunti als auf "make all" gepolt sind.
Strubi hat den 16-bit neo430 ja schon angesprochen, hier der Link zum Projekt: https://github.com/stnolting/neo430
Wenn du es wirklich klein haben willst oder nicht mehr viel Platz übrig ist: die J1 Forth-CPU (200 Zeilen Verilog) http://www.excamera.com/sphinx/fpga-j1.html Wird z.B. im Gameduino als Coprozessor in der "Grafikkarte" benutzt: http://www.excamera.com/sphinx/gameduino/coprocessor.html
ARM bietet einen freien Zugang zum ARM Cortex M0 IP. Ob das aber in Verilog oder VHDL erhältlich ist, kann ich nicht mit Sicherheit sagen. https://www.arm.com/about/newsroom/arm-offers-free-access-to-cortex-m0-processor-ip-to-streamline-embedded-soc-design.php
Mais CPU http://www.dossmatik.de/mais-cpu.html Ist ein MIPS I (32bit) Softcore Aus der Alu könnte man einfach die Multiplikationsunit rausnehmen. oder noch weitere Befehle aus der ALU. Die CPU lässt sich unter GHDL simulieren. Mehr als genüge GHDL genutzt in der Entwicklung. Das Interfache ist einfach gehalten. > 5. Zur SW-Entwicklung wäre mir ein GCC oder sowas recht. (Mit > Linkerskripten etc kenne ich mich aus). sollte es keinen GCC geben, wäre > zumindest ein unter Linux lauffähiger/kompilierbarer Assembler > wünschenswert. Die Abläufe, die ich programmieren will, sind auch noch > in Assembler überschaubar. GCC / Binutils läuft.
Vielen Dank für eure reichlichen Beiträge. Ich werde mir einiges davon in nächster Zeit mal ansehen. Vorzugsweise die Dinge in VHDL, da diese für mich auch gut simulierbar sind.
Am einfachsten ein freier 8051 in VHDL z.B. https://www.oreganosystems.at/products/ip-cores/8051-ip-core
Lothar schrieb: > Am einfachsten ein freier 8051 in VHDL z.B. ... oder einfach mal mit einem 10er Fräser in die Kniescheibe und Milch reinkippen. Könnte sogar weniger Spätschäden hinterlassen ;) Irgendwann muss man den 8051 einfach mal sterben lassen. Er war grossartig seiner Zeit, aber es gibt keinen Grund mehr, diesen verkannten RISC-Prozessor (viele Register, wenig Befehle, keiner davon kann irgendwas...) wie einen Zombie am Leben zu lassen.
Georg A. schrieb: > Irgendwann muss man den 8051 einfach mal sterben lassen 8051 sind überall drin. In neuesten Glasfaser-Repeatern: https://www.silabs.com/products/mcu/8-bit/efm8-laser-bee In USB Controllern: http://www.genesyslogic.com/en/product_view.php?show=48 usw.
Ja, Asbest hat man früher auch überall reingekippt. Ein Wunder, dass es nicht auch in Babynahrung war. Ich habe lange genug den 8051 gewürgt, in Assembler, mit sdcc, und auch mit dem Drecks-Keil-C-Compiler, der jede Version ein anderes simples C-Konstrukt fehlerhaft übersetzt hat. Das tut einfach nur weh, ich brauch das nicht mehr.
Georg A. schrieb: > Ja, Asbest hat man früher auch überall reingekippt. > Ein Wunder, dass es nicht auch in Babynahrung war. Immerhin war es in Babypuder drin... Lothar schrieb: > 8051 sind überall drin. Das macht ihn aber nicht zu einer besonders geeigneten Architektur für Neuentwicklungen... es sei denn, man hat zufällig viel Erfahrung damit, keine Lust zu wechseln und bevorzugt eine ziemlich patent- und lizenzfreie Umgebung.
Der 8051 ist in der Tat eine denkbar schlechte Architektur fürs FPGA. Würde ich auch eher als CISC als RISC sehen, das Kriterium dazu sollte man ev. nicht an der Anzahl der Befehle festknoten. Wenn man den 8051 pipelined hinkriegen will, frisst er mehr Resourcen als ein 32 bit MIPS. Macht nicht wirklich Sinn, da der TO ja was kompaktes braucht. Da schiessen so einige "Tips" oben etwas dran vorbei. Generell sehe ich kaum noch einen Grund, eine 8Bit-Registermaschine aufs FPGA zu packen, da brockt man sich nur eine Menge Aerger ein, wenn's mal doch komplexer mit der Peripherie (Networking, DMA ...) wird.
Wäre schon interessant, wofür der TO sich nun entschieden hat.
Moin, für mein Project werde ich den Mcl65 verwenden. Ist ein Softcore für den 6502. http://www.microcorelabs.com/mcl65.html Wie man in den Videos sieht funktioniert er auch als Ersatz in Geräten und ist Cycleexcat ok für Dich vielleicht nicht so interessant. Ist zwar Verilog aber besteht hauptsächlich aus Microcode. Der Verilog-Code recht klein (weniger als 500 Zeilen). Auch generell sehr klein auf dem Chip... Gruß Egon
@egon: Der MCL65 ist echt interesannt. Leider verbraucht der relativ viele Speicherresourcen. Dafür allerdings wenig Logik. Ein 6502 belegt aber sowieso nicht viel Logik. Ich hab nen 6502 in Verilog gefunden, der nur ca. 1200LEs in nem Cyclone2 belegt. Mir geht vor den LEs meistens der RAM aus. Trotzdem finde ich das Mikrocodekonzept sehr nett.
@Sigint magst du vielleicht noch den Namen posten von deinem 6502 Core? Denn hätte man eine alternative je nach dem was man braucht.
Logisch... hab das ganz vergessen: https://github.com/Arlet/verilog-6502 Hab mit diesem Core mal folgendes Teil in nen FPGA gebracht: http://www.6502asm.com/ http://sigint112.blaucloud.de/index.php/s/FNpk70OXQp0pQU3 :-D
:
Bearbeitet durch User
M. H. schrieb: > 1. Wenn möglich in VHDL (ich verwende GHDL zum simulieren und kann kein > Verilog/mixed language). Das ist aber kein muss. Wäre nur schön :) Nur so nebenbei: erlaubt deine Quartus-Lizenz mixed-language? Das war früher in den kostenlosen Lizenzen nicht mit dabei. Dann fallen alle Verilog-Cores leider raus.
@egon: Leider nicht. Ich liebe die Demoszene... bin aber nicht ansatzweise gut genug in ASM und C. Das Demo ist ein Beispiel von 6502asm. Ich hab das nur genutzt um mein SOC zu testen. Wobei SOC etwas übertrieben ist: Das ist nur die 6502 mit RAM, ein 32x32 VGA-Framebuffer und etwas IO-Hardware. Gerade genug, um die Beispiele laufen zu lassen. Das Programm wird beim konfigurieren des FPGA ins RAM geladen.
@Sigint nicht gut genug... Ach was ;) Reine Übungssache ich mach in der Richtung recht viel (->Orb... bin aber mehr 8/16 bit mässig unterwegs)... Ich bin mal gespannt wie schnell man die Softcores laufen lassen kann (Sparten 3 bei mir) wenn mein Board fertig ist. Womit war den Test damals?
@egon: Bist du ein Mitglied von Orb? :-) Ich kann mich leider nur mit großer Mühe auf eine Sache konzentrieren... deshalb komme ich nicht wirklich vorwärts beim coden. Es gibt einfach zu viele interesannte Sachen, von denen ich mich ablenken lasse. Im Moment z.B. die CH55x Mikrocontroller. ;-) Das SoC hab ich damals auf einem Cyclone I realisiert, glaube ich. Hab hier einige Cyclone I bis IV rumliegen. Die Teile sind mittlerweile zu günstig... da muss ich immer zugreifen. Wobei ich mich jetzt auf die ICE40 eingeschossen habe. YOSYS+ARACHNE_PNR+ICESTORM. Ich glaube, die Geschwindigkeit hängt immer stark vom Core ab. Ich betreibe den 6502 meistens mit 1MHz. Ich teste im Moment nur.
@Sigint yup @Orb ich mach mit 4mat die vc20 und c64 Sachen. Das Problem mit dem zu viele interessante Sachen kenne ich. Ich muss mich auch immer bremsen um nicht wieder was neues anzufangen ;) Leider dauert auch immer alles ewig. Das Spartan-Projekt hab ich vor 4 Jahren angefangen. Hab aber wenig Zeit leider. Den Cyclone 1 kenn ich gar nicht. Ich bin mehr mit Xilinx ICs unterwegs. Aber ist wohl von den Möglichkeiten dem Spartan 3 ähnlich vermute ich. ICE40 sagt mir auch gar nichts ;) Ich hab vor einiger Zeit mal zugeschlagen und hab gut 20 Spartan 3 die muss ich erstmal verbauen. Ich hab mal nen kleine Test gemacht also der Mcl65 würd wohl bei meinem Spartan 3 mit knapp unter 80mhz laufen. Ok meisst braucht man ja eh nicht so viel Speed ist ja eh nur für Sachen wo es nicht auf Geschwindigkeit ankommt.
Und wie wärs mit ner eigenen 8(?)-Bit CPU? Du könntest dich auf die benötigten Befehle beschränken und es damit ganz klein halten.
René D. schrieb: > Mais CPU > > http://www.dossmatik.de/mais-cpu.html > > Ist ein MIPS I (32bit) Softcore > > Aus der Alu könnte man einfach die Multiplikationsunit rausnehmen. > oder noch weitere Befehle aus der ALU. Nur leider hat der MIPS GCC kein Flag für MulDIV Software Emulation wie bei AVR oder ARM. Weil son MIPS immer Punktrechnung kann. Auch wenns bei vielen MIPS nur ein serieller MulDiv Rechner ist ;)
Der TO hat sich lange nicht mehr gemeldet. Wahrscheinlich hat er sich längst entschieden für bo8 und traut sich wegen Mobbing-Gefahr nicht, sich dazu zu bekennen.
Bitte 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.