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.
Egal wieviel Bit, ohne vernünftigen (C)Compiler ist das alles nicht wirklich sinnvoll...
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.
:
Bearbeitet durch User
Schön, dass das aufgegriffen wurde. Ich hatte selbst schon mal nach soetwas gesucht: Beitrag "64/128 Bit Softcore" Den Bedarf sehe ich absolut.
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.
Hier gibt es den Archimedes : https://github.com/mist-devel/mist-binaries/tree/master/cores Läuft auf dem MIST : http://lotharek.pl/product.php?pid=96 GRuss
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?
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.