Announcement: there is an English version of this forum on Dieser Artikel erschien im Embedded Projects Journal 14 auf Seite 19.
In diesem Artikel wird das Projekt eines Bastlers vorgestellt. Ausführliche und exakte Informationen sowie Downloads sind zu finden unter http://www.bomerenzprojekt.de...
Cool gratuliere dir :) Auch wenn dein Projekt hier im Forum nicht soviel Anklang fand.
Das "Abb.1: CPU" unter dem Foto ist natürlich Unsinn.
@ Josef G. (bome) Benutzerseite
>Das "Abb.1: CPU" unter dem Foto ist natürlich Unsinn.
So wie das Projekt und vor allem dessen Präsentation . . .
Die Sauerbierdrückerkolone ist mal wieder unterwegs.
Falk Brunner schrieb: > So wie das Projekt und vor allem dessen Präsentation . . . Na ja, schau es doch wie Warhol an: Lass doch dem Josef G. seine 15 Minuten Ruhm.
Josef Gnadl schrieb: > > Dieser Artikel erschien im Embedded Projects Journal 14 auf > Seite 19. > In diesem Artikel wird das Projekt eines Bastlers vorgestellt. > Ausführliche und exakte Informationen sowie Downloads sind zu finden > unter http://www.bomerenzprojekt.de. Hallo Josef, als Vollblut-FPGA -Emtwickler finde ich dein Projekt interessant und inspirierend. Eine 8 bit CPU im Eigenbau ist bei Hobbyprojekten schon Top, du siehst ja selbst, das es hier im Forum eher um Kleinkramprojekte wie Zähler, Adder oder I2C geht und aus eigener Erfahrung weiss ich das man mindestens 2 Wochen in den 8 bit core allein aufwendet. Besonders interesant finde ich das DDr2 Interface. Frustierend beim Picoblaze von Xilinx ist m. E. der Designflow von assemblercode zum bitfile, da hat xilinx immer mal wieder das Format eines zwischenfiles geändert und bei jedem SW-Update fängt man von vorn an. Für so ein "selbsterfahrungsprojekt" ist aus meiner Sicht der Nachbau eines bestehenden Systems (8 bit Homecomputer, VT100-Konsole) besser als von Grund auf alles selber zu bauen bzw zu beschreiben. Anschliessend kann man beim CPU design experimentieren, wie man (möglichst) binärkompatibel Ressourcen (Rechenzeit, LUT,FF, leistung) spart oder Debug/Profiling Features einbaut. Abfällige Bemerkungen über unsinnige Präsentation etc. kann man bedenkenlos ignorieren. Schließlich geht es hier Hardware-Entwicklung und nicht um Webdesign. MfG,
Das System gibt es nun auch als Konfiguration für das Spartan-3E Starter Board von Digilent. Siehe Seite Hawa der Projekt-Website.
Fritz Jaeger schrieb: > Vollblut-FPGA -Emtwickler finde ich dein Projekt interessant und > inspirierend. Das kann man unterschreiben > Eine 8 bit CPU im Eigenbau ist bei Hobbyprojekten schon > Top, du siehst ja selbst, das es hier im Forum eher um Kleinkramprojekte Das Forum ist kein Massstab. Es gibt zahllose Elektronikentwickler und auch FPGA-Entwickler, die das Forum auf grund wenig Mikrocontrollerbezug noch nie besucht haben oder wie ich sehr unregelmässig besuchen. Dies bedeutet nicht dass die keine Projekte bauen! Im Gegenteil 8Bit CPUs und RISC haben "wir" früher auch zusammengestöpselt, ich meinerseits schon vor 15 Jahren (in VHDL). > interesant finde ich das DDr2 Interface. In der Tat ist das ein kluger Ansatz, den verbauten Chip zu nutzen. Noch klüger wäre es ein passendes board mit SRAM Interaface zu nutzen, da man dann eine noch höhere Bandbreite bei wahfreiem Zugriff bekommt, wegen der geringeren Latenz. Als (ebenfalls) Vollblut FPGA-Mann bin ich da nämlich auf Bandbreite aus und DDR(1,2,3) ist einfach nur billiger, nicht aber besser für schnelle Anwendungen. Wie auch immer: Das Projekt verdient allein schon vom Aufwand her Respekt. Nutzbar ist es aber nicht, weil es Äquivalenzen in Massen gibt und nichts Neues bringt. Ich wäre dafür, einen skalierbaren 64 Bit Prozessor einzusetzen, den man mit einfachen Befehlen konfiguriren, also klein halten kann, und der die erforderliche Bandbreiten bei FPGA-Apps bringt. Einfach nur überhaupt Softcores in FPGAs zu stopfen ist fad und bleibt Spielbastelei ohne Nutzen. Das gilt in aller Regel auch für die hier erwähnten *blaze, die nach meiner Ansicht eher *snail heissen müssten, weil sie Systeme abbremsen, statt zu beschleunigen.
Moin, meine Meinung: es gibt hier oft halt zwei Lager, die Hobbyfrickler und die, die jeden Tag damit arbeiten (müssen). Den einen macht's furchtbar Spass, die andern nerven sich darüber. > > Wie auch immer: Das Projekt verdient allein schon vom Aufwand her > Respekt. Nutzbar ist es aber nicht, weil es Äquivalenzen in Massen gibt > und nichts Neues bringt. > Respekt haben sicher sowohl Profis als auch Hobbyisten vor dem Einsatz. Alleine schon, eine Sache mit Gegenwind durchzuziehen, erfordert, ich sag's mal nicht jugendfrei, kräftige behaarte Gonaden. Aber ich persönlich bin ein Fan von Standards und Lesbarkeit(!), weil ich mit dem 'Scheiss' auch arbeiten können muss. > Ich wäre dafür, einen skalierbaren 64 Bit Prozessor einzusetzen, den man > mit einfachen Befehlen konfiguriren, also klein halten kann, und der die > erforderliche Bandbreiten bei FPGA-Apps bringt. > Leider landet man da immer wieder faktisch beim hart-codierten Eigenbau-DSP. Es ist einfach nicht zu schaffen, eine konkurrenzfähige Multipurpose-CPU in einen bezahlbaren FPGA zu kriegen. Die meisten Lösungen bleiben da schlicht bei einem akademischen "proof of concept" stecken oder brauchen gleich einen dicken Virtex, o.ä. > Einfach nur überhaupt Softcores in FPGAs zu stopfen ist fad und bleibt > Spielbastelei ohne Nutzen. Das gilt in aller Regel auch für die hier > erwähnten *blaze, die nach meiner Ansicht eher *snail heissen müssten, > weil sie Systeme abbremsen, statt zu beschleunigen. Naja, es gibt schon einen Aspekt, man kann sich mit einfachen Softcores die Entwicklung massiv beschleunigen. Dafür ist der *blaze schon ok, deshalb, weil man die fertige Toolchain mit JTAG-Debugger mit dazubekommt. Das gleiche geht aber auch mit der ZPU und mit der MIPS-Architektur von René (Beitrag "Softcore 32bit"). So kombinere ich z.B. nen JPEG-Encoder mit soft core, der zunächst das Debuggen zur Laufzeit arg beschleunigt bzw. überhaupt ermöglicht und später die Initialisierung und Header-Generierung macht. Nur diverse Scherze wie Linux auf MicroBlaze zu packen hat für mich eher akademischen als praktischen Wert. Grüsse, - Strubi
Es gibt nun auch eine Konfiguration für das Nexys2 Board von Digilent. Siehe Seite Hawa der Projekt-Website.
Mal eine Frage: Lässt sich dein 8bitter gfs auf 64 Bit aufbohren? Wie aufwändig wäre das? Betroffen wären die Busanbindung, der Adress- und Datnezugriff und naturlich die ALU! Bei deren Implementierung könnte Ich was beisteuern!
Weltbester FPGA Pongo schrieb im Beitrag #2966861: > Lässt sich dein 8bitter gfs auf 64 Bit aufbohren? Von 64-Bitern verstehe ich nichts, da kann ich nichts dazu sagen. Aber ich glaube nicht, dass das geht. Die CPU ist aus meiner Sicht geradezu eine Verkörperung des 8bit-Prinzips.
Es gibt nun auch eine Realisierung auf dem Altera DE1 Board / Cyclone2 Starter Board. Siehe auch Beitrag "8bit-Computing mit FPGA"
Es gibt nun eine zur Verwendung als Softcore innerhalb eines FPGA optimierte Version der CPU, welche mit nur 1 Taktsignal auskommt. Die CPU steht unter Creative-Commons-Lizenz zur Verfügung. http://www.mikrocontroller.net/articles/8bit-CPU:_bo8
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.