Ein Reihe von Personen haben in der Vergangenheit ihre Projekte in
Sachen SoftCore vorgestellt. Die Projekte reichen von 8Bit-CPUs für
retro bis 32 Bit-CPUs. Was es noch nicht gibt sind echte 64-Bit CPUs mit
paralleler Verarbeitunsmöglichkeit und Datenübergabe an die 64-Bit Busse
der streaming interfaces. Auch was die Genauigkeit von Berechungen
angeht, wäre eine CPU nötig, die das kann.
Ich habe eine einfache 64-Bit-ALU zusammengeschrieben, die Befehle
laden, multiplizieren und addieren kann. Auf der Basis möchte ich
weiterarbeiten und suche Mitwirkende.
Klaus L. schrieb:> Was es noch nicht gibt sind echte 64-Bit CPUs mit> paralleler Verarbeitunsmöglichkeit und Datenübergabe an die 64-Bit Busse> der streaming interfaces.
Was ist mit OpenSPARC?
Hi,
eine 'general purpose' 64 bit CPU auf nem mid-end-FPGA laufen zu lassen
finde ich begrenzt sinnvoll. Für knackige Berechnungen füttere ich
ansich lieber einen dedizierten Coprozessor. Das ist deutlich einfacher
zu implementieren, die MIPS32-Architektur kann ich dazu empfehlen.
Es gibt zwar einige spannende superskalare Pipeline-Architekturen, aber
die verbrauchen eine Menge Resourcen plus einiges an Hazard-Logik.
Schon der OpenSPARC ist ziemlich schwergewichtig. Ob's das bringt?
Ich habe in meinem MIPS-Design nen dicken Bus reingezogen (faktisch 4*32
bit), da geht dann gleichzeitige CPU-Verarbeitung, während zwei
DMA-Channel aus dedizierten Memory-Banken die Daten durch den Coproz
schleifen. Ist maximal performant, und bleibt kompatibel (keine neuen
Assembler-Befehle nötig). Was man bei ner neuen Architektur nämlich echt
nicht vergessen sollte: Die Toolchain. Es kostet nen Profi etwa ein
Jahr, bis gas/GCC usw sauber implementiert sind, zu schweigen von der
politischen Zusatzarbeit alles nach "upstream" zu kriegen.
Trotzdem würde ich keinen bremsen wollen, ne eigene CPU zu schreiben.
Man lernt einiges...nur das mit den Mitstreitern klappt nach meiner
Erfahrung höchst selten wirklich gut.
64-Bit Prozessoren braucht man hauptsächlich, um in Prozessen mehr
Speicher adressieren zu können als 2-4GB. Mit der reinen Rechenleistung
hat die Frage nach 32- vs. 64-Bit Breite bei Integers meist recht wenig
zu tun.
Um Rechenleistung eines Prozessors klassischer Struktur kann es in FPGAs
ohnehin nicht gehen. Das können Intel&Co besser. Erst mit Auslagerung
von Spezialaufgaben in dementsprechende Module ergibt das in FPGAs einen
Sinn.
Was den Spass am Design angeht - inwieweit ergibt es da einen
Unterschied, ob man das für 32 oder 64 Bits macht? Ausser in der Grösse
des benötigten FPGAs. Die Prinzipien sind identisch.
Es ist ja nicht so, dass es keine Std-64Bit-CPUs gäbe.
FPGA hat den Vorteil ein Design zu machen, für das (fast) jede Std-CPU
und/oder Std-DSP viel schlechter wäre. Also ua massive parallelis.
MCUA schrieb:> Es ist ja nicht so, dass es keine Std-64Bit-CPUs gäbe.> FPGA hat den Vorteil ein Design zu machen, für das (fast) jede Std-CPU> und/oder Std-DSP viel schlechter wäre. Also ua massive parallelis.
da bin ich aber mal skeptisch. Ich bezweifle, dass du eine
'Standard-CPU' im FPGA schneller hinkriegst als im speziellen
Design/Technologie. Was A.K. da geschrieben hat, das unterschreibe ich
sofort. Wenn du im FPGA >50% der Laufzeit nur ins Routing stecken musst,
dann kannst du gegen eine spezielle Implementierung nicht anstinken. Du
kannst im FPGA nur Sachen besser machen, die es in einem 'speziellen'
Chip ueberhaupt nicht gibt.
Aber noch mal zum eigentlichen Thread-Thema: Ist nicht 64bit, sondern
nur 32bit. Schaut euch mal den ORSOC an (OR1000 oder sowas, bei open
cores). Hat zumindest den Vorteil, dass das Teil von gcc und auch vom
Linux-Kernel out-of-the-box unterstuetzt wird. D.h. die ganze Toolchain
ist bereits vorhanden. Wenn schon CPU im FPGA, dann sowas. Da gibt es
naemlich auch eine Community dahinter.
Ansonsten bleiben im FPGA fuer mich persoenlich nur kleine 8bit ATMega
oder sowas wie Picoblaze.
Nur meine 2cents zum Thema...
>> Es ist ja nicht so, dass es keine Std-64Bit-CPUs gäbe.>> FPGA hat den Vorteil ein Design zu machen, für das (fast) jede Std-CPU>> und/oder Std-DSP viel schlechter wäre. Also ua massive parallelis.>da bin ich aber mal skeptisch. Ich bezweifle, dass du eine>'Standard-CPU' im FPGA schneller hinkriegst als im speziellen>Design/Technologie.
Sagte ich doch gar nicht. (Natürlich ist ein CPU-Kern im FPGA fast immer
schlechter, als die CPU als sep Chip gemacht).
Ich sagte durch parallelis. im FPGA kann man (je nach Appl) mehr
Leistung rausholen, als es (für die gleiche Appl) eine Std-CPU bieten
könnte.
Ua aus diesem Grund gibs ja FPGAs.
A. K. schrieb:> Was den Spass am Design angeht - inwieweit ergibt es da einen> Unterschied, ob man das für 32 oder 64 Bits macht? Ausser in der Grösse> des benötigten FPGAs. Die Prinzipien sind identisch.
Vielleicht müsste man dazu noch genauer spezifizieren, was alles an der
CPU auf 64 Bit aufgebohrt werden soll...
1) Die von dir angesprochene Adressierung
2) Datenbreite (grössere Integer bzw. Busdurchsatz)
3) Opcodes (ev. Parallel-Instruktionen/SIMD, )
Nur an (1) und (2) zu drehen, ist nicht so spannend. An (3) hingegen
schon. Zum Beispiel kann man zwei Decode/Execute-Instanzen parallel auf
low und high-Word (untere und obere 32 bit) ansetzen und mit einer
Hazard-Logik die Problemfälle ausklamüsern. Der Gewinn an Speed besteht
dann darin, Code möglichst so zu generieren, dass diese "superskalare
Pipeline" schön balanciert belastet ist und kein Pfad auf den andern
warten muss.
Allerdings wird die Haz-Logik meist so 'teuer', dass sich eine
solchermassen gestrickte Alleskönner-CPU auf dem FPGA im Anwendungsfall
kaum rechnet. Wenn man aber sowieso keinen C-Compiler oder Assembler für
die Allgemeinheit bauen muss, kann man sich prima für einen Spezialzweck
eine schnelle Rechenpipeline, die durch lange Microcode-Instruktionen
gespiesen wird, bauen. Diese durch einen klassischen 32-Bitter (ev.
fertig angeboten vom Hersteller) anzusteuern, ist deutlich weniger
aufwendig.
Denn was bringt es, wenn das FPGA bei 64 bit Busbreite in allen obigen
Punkten 1-3 so voll ist, dass die Kiste nur noch bei 40MHz läuft, die 32
bit-Version aber locker 100 MHz schafft. Spätestens da ist einem dann
klar, dass das ganze eher ein Spass akademischer Natur war (zumindest
für die Nutzer, die nicht auf den grössten Virtexen herumspielen
dürfen).
> Ich habe eine einfache 64-Bit-ALU zusammengeschrieben, die Befehle> laden, multiplizieren und addieren kann. Auf der Basis möchte ich> weiterarbeiten und suche Mitwirkende.
Eine ALU ist schnell geschrieben. Ich hatte auch bei meiner Mais-CPU die
ALU schnell zusammen.
http://www.dossmatik.de/mais-cpu.html
Interessant und auch schwierig sind die Datenströme zur CPU und von der
CPU weg zu bekommen. Dann noch Ausnahmen für Sprünge und Ausnahmen für
Bustransfers. Da gibt es Flaschenhälse ohne Ende. Und zum Schluß muss es
noch für Außenstehende beherrschbar und verständlich sein.
Die 64bit sind höchsten für 2-3Variablen interessant. Dafür eine gesamte
CPU auf 64bit auszurichten halte ich auch etwas für übertrieben.
René D. schrieb:> Die 64bit sind höchsten für 2-3Variablen interessant. Dafür eine gesamte> CPU auf 64bit auszurichten halte ich auch etwas für übertrieben.
In den 80ern dachte man, 256k seien für einen Computer vollkommen
ausreichend und es werde nie eine Anwendung geben, die mehr benötigt.
FPGA-Progger schrieb im Beitrag #3312893:
> In den 80ern dachte man, 256k seien für einen Computer vollkommen> ausreichend und es werde nie eine Anwendung geben, die mehr benötigt.
Da wußte man noch nicht das die Welt Klicki-Bunti und HD-Video machen
will...
Duke
> In den 80ern dachte man, 256k seien für einen Computer vollkommen> ausreichend und es werde nie eine Anwendung geben, die mehr benötigt.
Ja zum Mars will der Mensch auch fliegen. 64bit in allen Ehren, im FPGA
als Universal CPU wird das keine Rakete.
FPGA-Progger schrieb im Beitrag #3312893:
>> Die 64bit sind höchsten für 2-3Variablen interessant. Dafür eine gesamte>> CPU auf 64bit auszurichten halte ich auch etwas für übertrieben.> In den 80ern dachte man, 256k seien für einen Computer vollkommen> ausreichend und es werde nie eine Anwendung geben, die mehr benötigt.
Nein, in dem Zitat geth nicht um 256k sondern um 640kB die lt. Bill
Gates 1981 genug wären für jeden. Und die begrenzung auf 640 rührt
weniger von der CPU her, als von der Speicheraufteilung von MS-DOS, die
eben nur 640k für User-Applikationen bereitstellen (der rest war für
BIOS, Mem-mapped IO). Schon mit einer RAM-Disk war diese Beschränkung
aufhebbar.
Wer hört schon auf Gates...
Mal zurück zum Thema: Ich bin eigentlich ziemlich entschlossen, das zu
bauen. Es gibt auch Applikationen dafür. Ich möchte da nicht zuviel
erzählen, aber es gibt eine sehr interessante Applikation. Eine die die
Rechenbreite braucht.
Klaus L. schrieb:> aber es gibt eine sehr interessante Applikation. Eine die die> Rechenbreite braucht.
Natürlich gibt es Applikationen, wo 64-Bit Rechenbreite benötigt wird.
Dennoch ist meist ein kleiner Softcore mit Coprozessor sinnvoller (und
wahrscheinlich auch schneller) als eine 64-Bit CPU als Softcore im FPGA.
Gystav Gyrator schrieb:> Nein, in dem Zitat geth nicht um 256k sondern um 640kB die lt. Bill> Gates 1981 genug wären für jeden.
Dieses Zitat wird ihm nachgesagt, er bestreitet es aber glaubhaft:
http://www.nybooks.com/articles/archives/2002/mar/14/hes-got-mail/?page=2
Und tatsächlich ist die PC-Architektur aber auch gleich sowas von
vermurkst, dass sich jeder wundern müsste, warum das mit dem Booten
heute schon wieder mal geklappt hat...
Alexander F. schrieb:> Dennoch ist meist ein kleiner Softcore mit Coprozessor sinnvoller (und> wahrscheinlich auch schneller) als eine 64-Bit CPU als Softcore im FPGA.
Nee, definitiv nicht :-)
Klaus L. schrieb:> Ich habe eine einfache 64-Bit-ALU zusammengeschrieben, die Befehle> laden, multiplizieren und addieren kann. Auf der Basis möchte ich> weiterarbeiten und suche Mitwirkende.
Öh ja und was ist daran so toll?
Man braucht ja nur die Registerbreiten der 8Bitter ändern und hat 64Bit
... Wüsste nicht, was an einer Alu jetzt so speziell ist (wenn der ganze
Rest außenrum fehlt)
Moin,
ja, 64 bit. Macht sicher Sinn bei ner Coprozessor-ALU, aber damit ist
dann schon Schluss, 64-Bit-Busse, womöglich mehrkanalig, in ein FPGA zu
drücken, macht keinen Sinn. Geschweige denn 64-Bit Addressierung.
Also, was ist daran neu und toll? <kommentar boshaft="1">Erst mal
schauen, was die anderen für Ideen haben?</kommentar>
fj83f893hj schrieb:> Klaus L. schrieb:>> Ich habe eine einfache 64-Bit-ALU zusammengeschrieben, die Befehle>> laden, multiplizieren und addieren kann. Auf der Basis möchte ich>> weiterarbeiten und suche Mitwirkende.>> Öh ja und was ist daran so toll?>> Man braucht ja nur die Registerbreiten der 8Bitter ändern und hat 64Bit> ... Wüsste nicht, was an einer Alu jetzt so speziell ist (wenn der ganze> Rest außenrum fehlt)
Du musst die 64er ALU erstmal haben, um entsprechend multiplizieren und
divideren zu können, weil es sonst wie bei CPUs in 32Bit emuliert wird
und dann saulangsam wird.
Klaus L. schrieb:> Alexander F. schrieb:>> Dennoch ist meist ein kleiner Softcore mit Coprozessor sinnvoller (und>> wahrscheinlich auch schneller) als eine 64-Bit CPU als Softcore im FPGA.> Nee, definitiv nicht :-)
Sorry, aber wenn man auf eine spezielle Anwendung rauswill, ist eine 64
bit general purpose CPU sicher nicht der effizenteste Weg. Dafür baut
man, wie schon einige Male erwähnt, eigene Co-Prozessoren.
Und für General Purpose ist der FPGA wiederum nicht die Platform der
Wahl.
Klaus L. schrieb:> Du musst die 64er ALU erstmal haben, um entsprechend multiplizieren und> divideren zu können, weil es sonst wie bei CPUs in 32Bit emuliert wird> und dann saulangsam wird.
Was wird in CPUs in 32 Bits emuliert?
Ein kombinatorischer Multiplizierer in einer CPU ist üblicherweise nicht
Teil einer ALU selbst, sondern eine separate Einheit, ggf. mit der ALU
assoziiert.
Andreas Fischer schrieb:> Beitrag "64/128 Bit Softcore"> Den Bedarf sehe ich absolut.
Wofür denn?
Und letztlich geht es nur darum: welche Stückzahlen?
Eies ist sicher: wenn du da viele Nullen bieten kannst, dann wird dir
einer solche Bausteine anbieten...
BTW: bitte nicht jeden alten Thread zum Thema wieder herauskramen. Einer
reicht...
Mir ist auch nicht so ganz einsichtig, wozu man eine Soft-CPU
ausgerechnet als RISC ausführen soll. Welche Befehlsebenen sollen da
implementiert werden?
Im Prinzip haben wir doch eine RISC CPU in Form von direkt
instanziierbarem VHDL. Da gibt es plus, minus, mal, geteilt und alles,
was das Herz begehrt. (ok, "geteilt" ist nicht so einfach).
Wenn, CPU dann bitte mit ausreichend komplexen Funktionen.
Allen Unkenrufen zum Trotz, habe ich das System nun fertiggestellt. Die
Alu kann sogar 96Bit gleichzeitig berechnen, schafft also 48
Bit-Multiplikationen. Realisiert, als Mehrfach-CPU in einem aktuellen
Altera FPGA der höheren Klassen. Läuft auf 333 MHz Taktfrequenz.
Realisiert, als Mehrfach-CPU in einem aktuellen
> Altera FPGA der höheren Klassen. Läuft auf 333 MHz Taktfrequenz.
Toll und jetzt?
Es gibt rund um das Thema eine Menge Akademische Meldungen. Es ist keine
Implementation aufgetaucht und hat den Markt aufgeräumt. Weil es einfach
keinen allgemeinen Kundennutzen gab.
Bitte wieder melden, wenn du eine C-Compiler hast.
Also wenn man nun unbedingt eine 64Bit CPU reinprügeln will, dann den
MIPS64 nachbauen.
Gibts dann schonmal nen Compiler für.
Aber wozu?
Den Softcore 64Bitter steckt jeder Hardcotre 32Bitter in die Tasche.
Also wenn du CPU Power nebem dem FPGA Design brauchst -> ZYNQ oder das
ALtera pendant dazu.
Hat also nur Lernzwecke wenn mans unbedingt machen will, was ja auch
nicht schlecht ist.
René D. schrieb:> Toll und jetzt?
Ich glaube, man muss das im Zusammenhang mit dem Doppelposting hier
sehen:
Beitrag "Re: 64/128 Bit Softcore"
Dort erklärt er, was das Dingens kann. Allerdings fehlt auch da, wie er
programmiert wird. Als nächstes wird irgendwo ein Compiler-Projekt
iniziert werden - pass auf :D
Klaus L. schrieb:> Alu kann sogar 96Bit gleichzeitig berechnen, schafft also 48> Bit-Multiplikationen. Läuft auf 333 MHz Taktfrequenz.
Also 48x48? Mit welcher Latenz? 333 wäre gerade EIN multiplier, oder?
