mikrocontroller.net

Forum: FPGA, VHDL & Co. Freier + kleiner Softcore gesucht.


Autor: M. H. (bambel2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Vancouver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Schlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast dir schon mal den LEON angeschaut?

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: K. Ein Wei-Chei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Strubi (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Mr.Mr. (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Strubi hat den 16-bit neo430 ja schon angesprochen, hier der Link zum 
Projekt:

https://github.com/stnolting/neo430

Autor: einer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da schon geschaut?
FPGA Soft Core

Autor: foobar (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Barrex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert

Autor: Uwe S. (lzmr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
:D

Autor: M. H. (bambel2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Georg A. (georga)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Georg A. (georga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: einer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wäre schon interessant, wofür der TO sich nun entschieden hat.

Autor: egon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sigint 1. (sigint)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: egon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Sigint
magst du vielleicht noch den Namen posten von deinem 6502 Core? Denn 
hätte man eine alternative je nach dem was man braucht.

Autor: Sigint 1. (sigint)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: egon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sigint Thx ;)

Bist in der Demoscene?

Autor: Philipp M. (aktiver_mitleser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sigint 1. (sigint)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: egon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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?

Autor: Sigint 1. (sigint)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: egon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Tim T. (tim_taylor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: einer (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.