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
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.
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.
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.
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.
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.
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.
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.
