Hallo zusammen Ich würde gerne ein Spiel mit VGA Ausgabe in VHDL beschreiben. Dazu habe ich ein DE0-CV Board von Terasic zur Verfügung. Spiel: simple 2D grafik (Farbe) mit einigen animierten sprites und einem bewegbaren "Helden". Idealerweise Gegner. Verschiedene Objekte zur interaktion wie z.B. Münzen oder Leitern. Nachdem ich mich ein wenig mit VHDL beschäftigt habe, denke ich dass es Sinn mach, folgende Teile in reinem VHDL zu beschreiben: - Generierung der Maps - Auslesung des Tiles aus dem Speicher - Animation von Sprites - Darstellung der Charakter - Ausgabe bzw. erzeugung der VGA Signale - Ausgabe der Tonsignale Jedoch habe ich das Gefühl (leider bisher zu Wenig Erfahrungswerte vorhanden), dass die Implementierung der Spielelogik einfacher in einer Hochsprache wie C zu implmenetieren wäre. Deshalb habe ich mir gedacht, dass es eventuell das "einfachste" sein dürfte, eine simple CPU für die Spielelogik in das FPGA zu integrieren. Diese würde die Bedientasten auswerten und über entsprechende Adressen dem FPGA bzw. der "Draw-Engine" mitteilen, welche Sprites wie zu verschieben sind. Nun die Frage an die Experten: a) ist meine vorläufige Erkentniss die Logik in eine CPU auszulagern der richtige Ansatz? b) Ich habe nach meiner Recherche die ZPU gefunden. Diese scheint relativ gut dokumentiert zu sein und es scheint auch ein relativ einfaches Tutorial vorhanden zu sein (https://www.mikrocontroller.net/articles/ZPU:_Softcore_Implementierung_auf_Spartan-3_FPGA) Gibt es einfachere CPU implementationen für diesen Anwendungsfall? Umgebung: Quartus Danke schonmal
:
Bearbeitet durch User
FÜr freie Implementierungen ist Opencores eine gute Adresse: https://opencores.org/ z.B. 197 Prozessor-Projekte
Holger K. schrieb: > Jedoch habe ich das Gefühl (leider bisher zu Wenig Erfahrungswerte > vorhanden), dass die Implementierung der Spielelogik einfacher in einer > Hochsprache wie C zu implmenetieren wäre. Ach Gottchen, die ersten Videospiele gab es vor Erfindung des Mikrocontrollers. Da eine reine FPGA-Implementierung von Pong: https://www.heise.de/ct/ausgabe/2015-22-Mit-FPGAs-Retro-Chips-implementieren-Teil-2-2825191.html Da eine von breakout: http://jrward.org/breakout.html
> > a) ist meine vorläufige Erkentniss die Logik in eine CPU auszulagern der > richtige Ansatz? Ab einer gewissen Komplexität schon, da bist du mit SW einfach schneller. > > b) Ich habe nach meiner Recherche die ZPU gefunden. Diese scheint > relativ gut dokumentiert zu sein und es scheint auch ein relativ > einfaches Tutorial vorhanden zu sein > (https://www.mikrocontroller.net/articles/ZPU:_Soft...) > Gibt es einfachere CPU implementationen für diesen Anwendungsfall? > Wenn GCC-Support die Mindestanforderung ist: Kaum. Einfacher sind nur noch div. Forth-CPUs wie die J1. Sonst ist die ZPU Arch in einigen Nischenanwendungen sehr populär und es gibt auch ein paar Weiterentwicklungen. Wenn du dich aber pur auf Sprites et al fokussieren willst: Was ist mit zB. minimig?
Wenn man FPGAs für Video benutzt, muss man schon in HW denken und arbeiten. Soll das hingegen so, wie der TE das formuliert, in SW geschehen, ist eine Realisation einer CPU im FPGA der falsche Weg. Dann lieber eine richtig schnelle CPU. Ein moderner FPGA treibt "eine Art von AVR" mit 300 MHz an. Da macht das Sinn, weil die effektive Leistungs dieses AVRs bei etwa 100MHz liegt. Eine 32 Bit-CPU in SW kriegt man auch maximal auf die halbe effektive Taktfrequenz, aufgrund der Komplexität aber nur mit 200MHz und weniger. Diese 100MHz packen auch externe CPUs locker und leicht. Und sie sind billiger. Und wer meint, man kann in einen FPGA je mehrere CPUs verstecken, kommt trotzdem drauf, dass 2-3 CPUs auf dem PCB effektiver sind. Auch was die Entwicklungs-Resourcen, IDE, Debugging angeht.
Holger K. schrieb: > Spiel: simple 2D grafik (Farbe) mit einigen animierten sprites und einem > bewegbaren "Helden". Idealerweise Gegner. Verschiedene Objekte zur > interaktion wie z.B. Münzen oder Leitern. > - Generierung der Maps > - Auslesung des Tiles aus dem Speicher > - Animation von Sprites > - Darstellung der Charakter > - Ausgabe bzw. erzeugung der VGA Signale > - Ausgabe der Tonsignale https://www.mikrocontroller.net/articles/16/32Bit_Computer/Konsole
Vielen Dank für eure Antworten. Besonders das letzte Projekt sieht sehr interessant aus. Es geht hier bei diesem Projekt vorallem auch um den Lerneffekt. Da keine unumgänglichen Einwende gegen die Verwendung einer (Z)CPU gekommen sind, werde ich diesen Weg weiter verfolgen.
Weltbester FPGA-Pongno schrieb im Beitrag #5553346: > Wenn man FPGAs für Video benutzt, muss man schon in HW denken und > arbeiten. Soll das hingegen so, wie der TE das formuliert, in SW > geschehen, ist eine Realisation einer CPU im FPGA der falsche Weg. Dann > lieber eine richtig schnelle CPU. > Dem muss ich widersprechen. Hast du die Idee des TE komplett durchgelesen? > Ein moderner FPGA treibt "eine Art von AVR" mit 300 MHz an. Da macht das > Sinn, weil die effektive Leistungs dieses AVRs bei etwa 100MHz liegt. > > Eine 32 Bit-CPU in SW kriegt man auch maximal auf die halbe effektive > Taktfrequenz, aufgrund der Komplexität aber nur mit 200MHz und weniger. > > Diese 100MHz packen auch externe CPUs locker und leicht. > Und sie sind billiger. > Unter Umständen nicht mal das. > Und wer meint, man kann in einen FPGA je mehrere CPUs verstecken, kommt > trotzdem drauf, dass 2-3 CPUs auf dem PCB effektiver sind. > Muss ich auch widersprechen. Auch da gibt es Fälle, wo sich das gegenüber einem STM32 rechnet. > Auch was die Entwicklungs-Resourcen, IDE, Debugging angeht. OpenSource ist was schönes, die HDL-Leute müssen sich nur noch dran gewöhnen. Insgesamt hat sich der Aufwand für mich gelohnt.
Holger K. schrieb: > Gibt es einfachere CPU implementationen für diesen Anwendungsfall? Nimm eine CPU für die Beispielprogramme, ein Crossassembler und ein Crosscompiler für eine Hochsprache wie C schon existeren, sonst musst du die auch noch schreiben was 10 x mehr Arbeit ist als die CPU gleich vernünftig zu realisieren (die dann sowieso derbe Macken hat und praktisch unbrauchbar ist). Sicher tut es ein AVR/68HC08/8051 core, recht einfach aber nicht fertig auch ein INS8060 SC/MP doch für den fehlt schon ein C Compiler.
:
Bearbeitet durch User
Michael B. schrieb: > Nimm eine CPU für die Beispielprogramme, ein Crossassembler und ein > Crosscompiler für eine Hochsprache wie C schon existeren, sonst musst du > die auch noch schreiben was 10 x mehr Arbeit ist als die CPU gleich > vernünftig zu realisieren (die dann sowieso derbe Macken hat und > praktisch unbrauchbar ist). Gut, dann binn ich mit der ZPU weiterhin bestens bedient. Die hat nämlich all dies.
Holger K. schrieb: > Gut, dann binn ich mit der ZPU weiterhin bestens bedient. > Die hat nämlich all dies. Melde Dich hier, wenn es irgendwo klemmt. Unter welchem Betriebssystem entwickelst Du? Duke
Mein gedachter Hardware-Tile/Sprite-Renderer von Beitrag "Bauen oder nicht bauen ?" scheint niemanden zu beeindrucken, doch vielleicht hast du Lust das zu entwickeln :-)
Halligalli schrieb: > scheint niemanden zu > beeindrucken Hab ich gerade gelesen... steht nur Quatsch drin.
Ist schon in Ordnung...ich habe sowieso das Gefühl das diese Technologie nicht freigegeben ist wegen Patenten und so...
Halligalli schrieb: > ich habe sowieso das Gefühl das diese Technologie > nicht freigegeben ist wegen Patenten und so Auch völliger Quatsch - schau Dir beliebige Arcade-Schaltpläne aus den 80ern an. Fast alle zeigen Dir, wie man aus RAM, ROM und Logik das entsprechende Schaltwerk für Tilemap, Sprites und Textlayer baut. Das ist kein Geheimnis - alle Arcadespiele haben das in der Zeit so gemacht. Allerdings ist es nicht gerade unkompliziert - alleine die Logiksteuerung besteht schon mal aus ca. 40-50 TTL-Bausteinen...
Duke Scarring schrieb: > Holger K. schrieb: >> Gut, dann binn ich mit der ZPU weiterhin bestens bedient. >> Die hat nämlich all dies. > Melde Dich hier, wenn es irgendwo klemmt. > > Unter welchem Betriebssystem entwickelst Du? > > Duke Danke für das Angebot. Aktuell unter Windows. Wobei ich für die kompilierung des ZPU Codes durchaus auch auf Linux ausweichen könnte. Würde jedoch zuerst die Lösung mit Cygwin versuchen. Halligalli schrieb: > Mein gedachter Hardware-Tile/Sprite-Renderer von > Beitrag "Bauen oder nicht bauen ?" scheint niemanden zu > beeindrucken, doch vielleicht hast du Lust das zu entwickeln :-) Habe ich bisher noch nicht gelesen. Wolfgang R. schrieb: > Hab ich gerade gelesen... steht nur Quatsch drin. Was genau ist daran Quatsch? Wolfgang R. schrieb: > Auch völliger Quatsch - schau Dir beliebige Arcade-Schaltpläne aus den > 80ern an. Fast alle zeigen Dir, wie man aus RAM, ROM und Logik das > entsprechende Schaltwerk für Tilemap, Sprites und Textlayer baut. > > Das ist kein Geheimnis - alle Arcadespiele haben das in der Zeit so > gemacht. Könntest du das Prinzip vielleicht in ein bis zwei Sätzen versuchen zusammenzufassen? Dies könnte mir eventuell einiges an Arbeit ersparen. Man muss ja nicht immer wieder das Rad neu erfinden. Bei diesem Projekt geht es hauptsächlich darum etwas zu tun und nicht etwas neuartiges zu erfinden. Eine Website mit knappen knackigen Infos wäre auch hilfreich. Danke
Um ein bisserl Spielelogik neben der Video/Soundtechnik zu machen: Für den Assemblerfreund, allerdings Xilinx proprietär: https://de.wikipedia.org/wiki/PicoBlaze Wenn es Dir aber nur um VHDL geht - einfach machen. Eine VGA-Karte zu implementieren ist sozusagen das "Hello World" in der FPGA-Welt. :) Allerdings gibt es seit Aufkommen z.B. der STM32 Familie keinen Grund mehr, dafür überhaupt ein FPGA einzusetzen. Ein nutzbarer Lerneffekt wäre sicher vorhanden, wenn Du ein Spiel auf einem STM32 implementieren würdest. Die Videoausgabe läuft in DMA/ISR, die CPU steht quasi voll für Spielelogik und Videotechnik zur Verfügung. Ganz easy: STM32L432KB - 256kB Flash, 64kB RAM. Fang mal mit Snake an und mach dann PacMan.
Wolfgang R. schrieb: > Auch völliger Quatsch - schau Dir beliebige Arcade-Schaltpläne aus den > 80ern an. Fast alle zeigen Dir, wie man aus RAM, ROM und Logik das > entsprechende Schaltwerk für Tilemap, Sprites und Textlayer baut. > > Das ist kein Geheimnis - alle Arcadespiele haben das in der Zeit so > gemacht. > > Allerdings ist es nicht gerade unkompliziert - alleine die > Logiksteuerung besteht schon mal aus ca. 40-50 TTL-Bausteinen... Mir fiel gerade ein riesen Stein vom Herzen ...oder wie man so sagt...ich schob schon Panik :-)
Huhu Wolfgang! Wolfgang R. schrieb: > Halligalli schrieb: >> ich habe sowieso das Gefühl das diese Technologie >> nicht freigegeben ist wegen Patenten und so > > Auch völliger Quatsch - schau Dir beliebige Arcade-Schaltpläne aus den > 80ern an. Fast alle zeigen Dir, wie man aus RAM, ROM und Logik das > entsprechende Schaltwerk für Tilemap, Sprites und Textlayer baut. > > Das ist kein Geheimnis - alle Arcadespiele haben das in der Zeit so > gemacht. > > Allerdings ist es nicht gerade unkompliziert - alleine die > Logiksteuerung besteht schon mal aus ca. 40-50 TTL-Bausteinen... Hinter mir hängt der Schaltplan vom Original-PacMan an der Wand. Am besten gefällt mir immer noch die Farberzeugung aus dem (waren es 32 Byte?) PROM. Die ganze Grafiklogik hat aber die arme Z80 machen müssen. Frage: welches Spiel hast Du im Auge, wenn Du an "Tilemap, Sprites und Textlayer" in Gattergrabbauweise denkst? Was wäre denn da die älteste Dir bekannte Arkademaschine, am besten aus Deiner Sammlung? Danke Dir, marcus
http://www.dustmop.io/blog/2015/04/28/nes-graphics-part-1/ Von dieser Seite hauptsächlich kam die Inspiration für den Hardware-Tile-Renderer. Ich weiss aber immer noch nicht ob er in Gänze machbar ist. Ich müsste mich an den Zeichentisch setzen ...hüstel...den Wohnzimmertisch :-) Hauptsächlich geht es um Zähler, deren aktueller Wert sich bei jedem Pixel ändert. Diese Zähler benutzt man um Daten zu dem aktuellen Pixel aus Speichern zu lesen, Zb. die Farbe. Dabei muss man erst eine Tile-Karte auslesen weil dort das höherwertige Adressbit im Detailspeicher steht zwecks Kompression/Speichereinsparung, da das ganze Tile diesen höheren Adresswert teilt. Gleichzeitig muss auch aus der Tile-Farbkarte eine Referenz auf für dieses Tile zu benutzende Palette(n) usw. ausgelesen werden. Später wird alles zusammengewurstelt und entschieden ob der Pixel durchsichtig ist oder in einer Farbe gezeichnet werden muss. Ich vermute eine Pipeline müsste Y-Form haben damit Tile-Details und Farbreferenz gleichzeitig ausgelesen werden und dann letztendlich zusammgeführt werden. Das ist leider nur spekulativ bis man es zeichnet...
Wenn es dir einfach nur darauf ankommt, eine kleine CPU in den FPGA zu bekommen, dann kannst du dir z.B. PicoRV32 anschauen: https://github.com/cliffordwolf/picorv32 Das Interface ist extrem einfach zu benutzen. Der Core ist zwar in Verilog, aber nur eine Datei und du kannst ihn in VHDL direkt benutzen (einfach als "component" beschreiben). Dafür bekommst du eine normale 32 Bit-Architektur mit voller Unterstützung für gcc/binutils.
Schau dir mal die J1 CPU an und den daraus entwickelten GameDuino - geht ziemlich genau in deine Richtung. http://www.excamera.com/sphinx/fpga-j1.html http://www.excamera.com/sphinx/gameduino/index.html PS: Ich find die CPU affentittengeil ;-)
Space Invaders! Wie süss! Ich hätte nicht übel Lust, auch mal wieder sowas zu bauen.
Holger K. schrieb: > Könntest du das Prinzip vielleicht in ein bis zwei Sätzen versuchen > zusammenzufassen? Das Prinzip lässt sich nicht in zwei Sätzen beschreiben - es ist zu komplex. Grundlegend sind die alten CPUs (6502, Z80, 6809) zu langsam, um Sprites direkt in den Bildschirmspeicher zu schreiben. Also Schreibt man nur Objektnummer und Koordinaten in ein Object RAM. Eine reine Hardwarelogik generiert daraus ein Bild, in dem sie Grafikdaten aus EPROMs in ein Line Buffer transferiert, der dann seriell als Videosignal rausgetackert wird. Da hat die CPU schon lange nichts mehr mit zu tun. Die Objektdaten werden im Allgemeinen in der Zeilen-Austastlücke geschrieben, damit nichts flackert...
Marcus H. schrieb: > Frage: welches Spiel hast Du im Auge, wenn Du an "Tilemap, Sprites und > Textlayer" in Gattergrabbauweise denkst? Was wäre denn da die älteste > Dir bekannte Arkademaschine, am besten aus Deiner Sammlung? Frogger ist ein guter Anfang, wenn auch noch etwas rudimentär. Dazu gibt es auch einen guten Schaltplan! http://www.wolfgangrobel.de/arcadereps/frogger.htm Ich glaube, die alten Gremlin Sachen von 1976 sind meine ältesten Arcadeplatinen mit 8080 CPU: http://www.wolfgangrobel.de/arcadereps5/comotion.htm Und dann hab ich natürlich noch ältere Discrete Arcade-Sachen ohne CPU: Blockbuster: http://www.wolfgangrobel.de/arcadereps3/blockbuster.htm Paddle Battle (1973) http://www.wolfgangrobel.de/arcadereps/paddle.htm
Holger K. schrieb: > Wolfgang R. schrieb: >> Hab ich gerade gelesen... steht nur Quatsch drin. > > Was genau ist daran Quatsch? Quatsch daran ist, dass in dem Thread nur tolle Ideen skizziert wurden, dafür null sachdienliche Umsetzungen. Das Prinzip ist seit 40 Jahren bekannt, Schaltungen dafür gibt es. Und die sind komplizierter, als dass man sie auf einem Bierdeckel zeichnen könnte... Alleine die pixelgenaue Positionierung der Sprites benötigt vorladbare Zähler und Addierer! Da bekommt man einen Knoten in den Hirnwindungen, wenn man in sowas Fehler suchen und finden muss... Und das mache ich seit über 5 Jahren!
Jürgen S. schrieb: > Space Invaders! Wie süss! Space Invaders (Taito/Midway) hat übrigens einen 8080 als CPU und benutzt keine Sprites / Tiles! Hier wird direkt in den Videospeicher geschrieben. Deswegen ist das Spiel auch so grottenlangsam und wird schneller, je mehr Gegner man abgeschossen hat... quasi einen Bug zum Feature gemacht! http://www.wolfgangrobel.de/arcadereps5/invasion.htm
S. R. schrieb: > Wenn es dir einfach nur darauf ankommt, eine kleine CPU in den FPGA zu > bekommen, dann kannst du dir z.B. PicoRV32 anschauen: > > https://github.com/cliffordwolf/picorv32 Danke für den Vorschlag. Sieht interessant aus. Habe schon ein paar Mal etwas über RISC-V gelesen. Leider fehlt mir die nötige Erfahrung um einzuschätzen, woe die Unterschiede zwischen der ZPU und der RISC-V liegen. Die ZPU hat ja ebenfalls ein GCC Compiler. Zur ZPU gibt es zudem noch ein Tutorial im Mikrocontroller.net forum bzw. auf der Seite. foobar schrieb: > Schau dir mal die J1 CPU an und den daraus entwickelten GameDuino > - geht > ziemlich genau in deine Richtung. > > http://www.excamera.com/sphinx/fpga-j1.html > http://www.excamera.com/sphinx/gameduino/index.html > > PS: Ich find die CPU affentittengeil ;-) Das sieht ja wirklich sehr gut aus! Vielen Dank für den Link. Wolfgang R. schrieb: > Grundlegend sind die alten CPUs (6502, Z80, 6809) zu langsam, um Sprites > direkt in den Bildschirmspeicher zu schreiben. Also Schreibt man nur... In etwa so habe ich mir das vorgestellt. Was mir allgemein Auffält ist, das sehr vielen Projekte in Verilog und nicht in VHDL geschrieben sind. Warum lernt man dann an den Hochschulen VHDL? Zudem fällt mir auf dass überdurchschnittlich viele Projekte mit Xilinx FPGAs arbeiten. Warum denn das? Wir haben einen Altera Cyclone. Altera Projekte habe ich kaum angetroffen.
:
Bearbeitet durch User
Holger K. schrieb: > Leider fehlt mir die nötige Erfahrung um einzuschätzen, woe die > Unterschiede zwischen der ZPU und der RISC-V liegen. Die ZPU hat den deutlich kompakteren Befehlssatz und einige Vorteile was "Fehlerfortpflanzung" angeht. Dafür ist es eigentlich eine Stackmaschine und dementsprechend (abhängig von Konfiguration) langsamer als eine Registerbasierte wie die Risc-V. Letztere ist eigentlich nix neues, im Prinzip die MIPS-Arch politisch etwas anders aufgerollt. Wenn du genug RAM für Programmcode hast, kannst du dir genauso eine von den zig RiscV-Implementierungen anlachen, wie die f32c, die auch Videokram und RAM-Ansteuerung mitbringt.
Fitzebutze schrieb: > Wenn du genug RAM für Programmcode hast, kannst du dir genauso eine von > den zig RiscV-Implementierungen anlachen, wie die f32c, die auch > Videokram und RAM-Ansteuerung mitbringt. Danke für deine Antwort. Ich habe 504kBit RAM bzw. 63kByte. Ich denke das sollte für die meisten kleineren Anwendungen genügen. Ansonsten gibt es noch ein SDRAM on Board. Weiss jemand direkt so heraus, wie komplex die Anbindung einer RISC-V CPU an ein SDRAM ist, vorausgesetzt es gibt bereits einen funktionierenden SDRAM Controller ?
Wolfgang R. schrieb: > Marcus H. schrieb: >> Frage: welches Spiel hast Du im Auge, wenn Du an "Tilemap, Sprites und >> Textlayer" in Gattergrabbauweise denkst? Was wäre denn da die älteste >> Dir bekannte Arkademaschine, am besten aus Deiner Sammlung? > > Frogger ist ein guter Anfang, wenn auch noch etwas rudimentär. > > Dazu gibt es auch einen guten Schaltplan! > > http://www.wolfgangrobel.de/arcadereps/frogger.htm http://www.classicgaming.cc/classics/frogger/about Brutal! Was für ein cooles Multiprozessorsystem. Den Schaltplan könnte Holger doch gleich in VHDL abpinseln und ein paar VHDL-Z80A anschrauben. Und dann schauen, ob sich die ROMs genauso verhalten wie im MAME. :) Als Zwischenstufe (und VHDL Einsteiger) wäre es wohl sinnvoll eine PacMan Emulation vorzuschalten. Davon kann dann viel wiederverwendet werden.
> Deshalb habe ich mir gedacht, dass es eventuell das "einfachste" sein > dürfte, eine simple CPU für die Spielelogik in das FPGA zu integrieren. > > Diese würde die Bedientasten auswerten und über entsprechende Adressen > dem FPGA bzw. der "Draw-Engine" mitteilen, welche Sprites wie zu > verschieben sind. > ... RISC-V Und dafür willst du ne moderne 32bit-CPU einsetzen, die um Größenordnungen komplexer ist als der Rest deines Projekts? Mit "simple" hat das überhaupt nichts mehr zu tun. Fang doch erstmal mit etwas Übersichtlicherem an ...
Holger K. schrieb: > Ansonsten gibt es noch ein SDRAM on Board. > Weiss jemand direkt so heraus, wie komplex die Anbindung einer RISC-V > CPU an ein SDRAM ist, vorausgesetzt es gibt bereits einen > funktionierenden SDRAM Controller ? Es gibt ein paar brauchbare SDRAM-Controller, z.b. der von "hamster_nz", und bei der f32c ist auch einer dabei, Qualität unbekannt. Ich würde allerdings von externem SDRAM für dein Vorhaben erst mal absehen. Oder du nimmst was fertiges, was schon funktioniert. Die ersten Hürden sind gross, ich würde mich an deiner Stelle erst mal auf was gut simulierbares fokussieren, oder den Standard-Krempel in Betracht ziehen (Nios/Soc-Builder). Und n Tip: Achte auf brauchbare Debugger (selten...)
Holger K. schrieb: > Leider fehlt mir die nötige Erfahrung um einzuschätzen, woe die > Unterschiede zwischen der ZPU und der RISC-V liegen. Die ZPU ist eine Stackmaschine mit Fokus auf FPGA-Implementierung und kleinem Code, RISC-V ist eine relativ normale RISC-Architektur. PicoRV32 implementiert RISC-V effizient auf einem FPGA. Im Prinzip ist es egal, welches von beiden zu benutzt. Holger K. schrieb: > Was mir allgemein Auffält ist, das sehr vielen Projekte > in Verilog und nicht in VHDL geschrieben sind. > Warum lernt man dann an den Hochschulen VHDL? Das hängt mit der Verbreitung zusammen. In Europa dominiert VHDL, in den USA dominiert Verilog. Dementsprechend hängt die Sprache eines Projekts eher davon ab, wo der Autor herkommt bzw. wo er gelernt hat. :-) Holger K. schrieb: > Zudem fällt mir auf dass überdurchschnittlich viele Projekte > mit Xilinx FPGAs arbeiten. Kleine Boards mit Spartan3 oder Spartan6 gibt es billig aus China, außerdem hat Xilinx (gefühlt) bessere Kontakte in oder bessere Angebote für die Hochschulen. Holger K. schrieb: > Ich habe 504kBit RAM bzw. 63kByte. Ich denke das sollte für die > meisten kleineren Anwendungen genügen. Bedenke, dass du die nicht vollständig nutzen kannst. Ein 36 Bit breites BRAM kann man zwar mit 32 Bit nutzen, verliert aber die ungenutzten 4 Bits. Außerdem wirst vermutlich auch FIFOs oder andere Cores benutzen wollen, die ebenfalls BRAM benutzen. Der PicoRV32 benutzt (glaube ich) ein BRAM für die Register. Holger K. schrieb: > Weiss jemand direkt so heraus, wie komplex die Anbindung > einer RISC-V CPU an ein SDRAM ist, vorausgesetzt es gibt > bereits einen funktionierenden SDRAM Controller ? Das hängt von den verwendeten Cores ab. PicoRV32 nutzt ein sehr einfaches Interface und hat zu jeder Zeit maximal einen Request aktiv. Wie ein SDRAM-Controller seine Ansteuerung haben will, ist ebenfalls unterschiedlich. Außerdem kommt PicoRV32 mit einem AXI-Interface, kann also problemlos mit einem AXI-SDRAM-Controller verheiratet werden. Ich glaube aber, dass AXI eher was für Xilinx ist. foobar schrieb: > Und dafür willst du ne moderne 32bit-CPU einsetzen, die um > Größenordnungen komplexer ist als der Rest deines Projekts? Er wollte doch keine CPU entwickeln, sondern nur für seine eigene Entwicklung benutzen. Dafür sind fertige, leicht ansteuerbare Cores super geeignet.
Wolfgang R. schrieb: > Die Objektdaten > werden im Allgemeinen in der Zeilen-Austastlücke geschrieben, damit > nichts flackert... Das ist einer der gernst gemachtesten Fehler der 80er: Dann kriegst Du ein schiefes Bild, weil Teile des Angreifers um ein Pixel versetzt sind. Leider ist das bei der groben Auflösung des Bildes eines C64 deutlich sichtbar. Der "schlaue Entwickler" hat das so gemacht, dass er die Sprites und auch andere Objekte nur in den Bereichen des Bildes aktualisiert hat, wenn sie gerade nicht dargestellt wurden. Also nicht zeilenlückenorientiert oder zwanghaft Vertikallücke, sondern jederzeit, nur halt nicht wenn kritisch. Und die (Achtung Wortwitz) "Elite" der Programmierer hat es hinbekommen, ein Echtzeittiming zu definieren, welches es zuließ, alles genau einmal im Bildlauf zu aktualiseren und damit sowohl ein Übergehen als auch Doppelsprünge zu verhindern, womit sich der gleichmässigste machbare Bewegungsablauf realisieren ließ. Die von mir damals erdachte und auch publizierte Lösung war die, die Reihenfolge der Abarbeitung der "threads" im sequenziellen Programm entsprechend dynamisch umzusortieren, d.h. es gab Abfragen, ob ein bestimmter Bearbeitungsblock gemacht wurde und das Kriterium (eine Nummer) wurde mit einem jeweils aktualisierten Zähler verglichen, auf den die Bearbeitungszeit des Blocks (die in ASM ja deterministisch ist) aufaddiert worden war. Damit gelang eine Echtzeitschätzung und jeder Block "wusste", wie weit das Bild in Y fortgeschritten war. Zum Schluss war ich soweit, dass die Blöcke es selber entscheiden konnten und einfach ihre Bearbeitung ausgelassen haben, wenn die Aktualisierung zu einem ungünstigen Zeitpunkt erfolgt ist, ihren Zähler nach hinten gesetzt haben und die Bearbeitung an den Folgeblock weitergegeben haben. Wenn dann die Gesamtzeit noch nicht erfüllt war, wurde wieder nach oben gesprungen, bis Gesamtzeit = berechnete Zeit war. Dann ging es mit einem neuen Bild los. Finale Lösung war, einzelnen Blöcken ein Mehrfaches an Zeit zu geben, damit sie öfters drankamen, z.B, die Berechnung von Schüssen, die sich schnell bewegen mussten. Auf die Weise konnte man bis an die Leistungsgrenze des Loops gehen, neue "tasks" reinwerfen, ohne über das timing nachdenken zu müssen. Ein Echtzeit-Multitasking der 80er sozusagen :-) Im Vergleich zu den Ergebnissen anderer Programmierer hat bei mir nie was geruckelt oder gezittert. "Bätschi" würde eine deutsche Politikerin jetzt sagen :-)
Jürgen S. schrieb: ... > Im Vergleich zu den Ergebnissen anderer Programmierer hat bei mir nie > was geruckelt oder gezittert. ... Ich bin ein bisserl zu jung, um auf dem C64 vernünftige Sachen gemacht zu haben. Was von Dir müssten wir kennen? Irgendwas, das man im Emulator anschauen könnte? Ich dachte immer, im HSYNC wurde eher Kleinkram gemacht (Palette umschalten, oder so) und die dicken Dinger im VSYNC? Allerdings hatten die alten Rechner wohl auch mehr Bildschirmrand, so dass da mehr Zeit war.
Fitzebutze schrieb: > Es gibt ein paar brauchbare SDRAM-Controller, z.b. der von "hamster_nz", > und bei der f32c ist auch einer dabei, Qualität unbekannt. Den hatte ich schon probiert zu implementiert. Ging eh nicht.
Holger K. schrieb: > - Generierung der Maps > - Auslesung des Tiles aus dem Speicher > - Animation von Sprites > - Darstellung der Charakter > - Ausgabe bzw. erzeugung der VGA Signale > - Ausgabe der Tonsignale Wofür genau soll für diese Aufgaben eine CPU implementiert werden? > - Animation von Sprites Ich nehme an, die Bewegung als solche wäre Aufgabe einer CPU. Aber Auslesen aus dem Speicher sehe ich im Zusammenhang mit der Videotakterzeugung. Eine echte recht leistungsfähige CPU lässt sich bei der Firma Xilinx z.B. implementieren durch den Microblaze. Der ist im Gegensatz zu früher mittlerweilse nicht mehr kostenpflichtig.
Ralfi schrieb: > Wofür genau soll für diese Aufgaben eine CPU implementiert werden? Bitte lies doch den kompletten Post, bevor du daraus zittierst. Zwei Zeilen über deinem zitierten Text steht: Holger K. schrieb: > Nachdem ich mich ein wenig mit VHDL beschäftigt habe, denke ich dass es > Sinn mach, folgende Teile in reinem VHDL zu beschreiben: > > - Generierung der Maps >...
:
Bearbeitet durch User
Soll das nun wirklich eine "einfach zu implementierende" oder nicht vielleicht doch eine "einfach zu verwendende" CPU sein? Einfachsten zu verwenden sind die drop in fähigen Softcores, z.B. PICOBLAZE.
Gibt es hier einen Fortschritt bzgl zpu und sdram Einbindung? Hab auch eine zpu implementiert und häng an der sdram Einbindung.
Andreas R. schrieb: > Gibt es hier einen Fortschritt bzgl zpu und sdram Einbindung? Hab > auch > eine zpu implementiert und häng an der sdram Einbindung. Das Projekt ist am laufen. Bisher noch keine vorzeigbaren Resultate was die Einbindung betrifft. Wie hast du die ZPU integriert bzw wie bist du vorgegangen? Hast du dazu das "tutorial" von Mikrocontroller wiki benutzt? Hier gibt es einen, meiner Meinung nach, relativ einfachen, gut verständlichen SD-RAM Controller http://codehackcreate.com/archives/444
Holger K. schrieb: > Hier gibt es einen, meiner Meinung nach, relativ einfachen, gut > verständlichen SD-RAM Controller Der ist tatsächlich relativ simpel, bleibt aber bezüglich der Performance deutlich hinter den technischen Möglichkeiten, weil er auf Bursting verzichtet.
Markus F. schrieb: > Holger K. schrieb: >> Hier gibt es einen, meiner Meinung nach, relativ einfachen, gut >> verständlichen SD-RAM Controller > > Der ist tatsächlich relativ simpel, bleibt aber bezüglich der > Performance deutlich hinter den technischen Möglichkeiten, weil er auf > Bursting verzichtet. Ich denke aber um ein Gefühl für das Thema SD-Ram zu erhalten und für den ersten Einstieg ist dieser wahrscheinlich recht gut geeignet. Ausbauen kann man ja meistens immer noch :)
Moin, portiert doch sonst einfach den ZPUino mit dem SDRAM-Controller. Da gibt's einige Leute, die damit auch Arcade-Fun machen. Wenn das RAM nicht reicht, kann man auch read-only Daten (Bitmaps) aus dem SPI-Flash oder mit MMC-Controller von der SDCARD (mit etwas höherer Bandbreite) cachen. Manche SPI-Flashes kann man so schnell auslesen, dass es für VGA-Blitting reicht.
Holger K. schrieb: > Andreas R. schrieb: >> Gibt es hier einen Fortschritt bzgl zpu und sdram Einbindung? Hab >> auch >> eine zpu implementiert und häng an der sdram Einbindung. > Wie hast du die ZPU integriert bzw wie bist du vorgegangen? Ich hab am Ende meine eigene ZPU Implementierung geschrieben, weil ich es einfach nicht geschafft hab, eine andere Implementierung einfach zu integrieren. Hat aber den Vorteil gehabt, dass ich z.B. lernen konnte, wie man einen Mikrocode aufbaut. > Hast du dazu das "tutorial" von Mikrocontroller wiki benutzt? Nein. Ich hab hauptsächliche auf den zpuino & Co Seiten gelesen. > Hier gibt es einen, meiner Meinung nach, relativ einfachen, gut > verständlichen SD-RAM Controller > > http://codehackcreate.com/archives/444 Vielen Dank! Ja, der sieht so verständlich aus, dass man darauf evtl. was aufbauen könnte. Wobei wir bisher eher Verilog nehmen, aber das könnte man ja entweder portieren oder halt als VHDL File ins Projekt einbinden. Ciao, Andreas
Hi Andreas, scheint doch jetzt mehrere Leute zu geben, die an der ZPU-Arch rumbasteln. Hast Du dazu was publiziert? Der Ansatz mit Mikrocode ist recht heiss, besonders, wenn du noch Pipelining einbaust.
Ich tausch die Sources nur mit Freunden, weil ja noch nix läuft. Kann sie Dir auch gern geben, wenn es Dir hilft. Meine Version ist eher auf Kompaktheit optimiert, weil ich damit ein Trading System initialisieren möchte. Da ist mir Performance eher egal, aber ich brauch meine LEs halt später für die Handelsalgorithmen.
Andreas R. schrieb: > Ich tausch die Sources nur mit Freunden, weil ja noch nix läuft. > Kann > sie Dir auch gern geben, wenn es Dir hilft. > Meine Version ist eher auf Kompaktheit optimiert, weil ich damit ein > Trading System initialisieren möchte. Da ist mir Performance eher egal, > aber ich brauch meine LEs halt später für die Handelsalgorithmen. Ich wäre sehr daran interessiert.
Andreas R. schrieb: > Ich tausch die Sources nur mit Freunden, weil ja noch nix läuft. > Kann > sie Dir auch gern geben, wenn es Dir hilft. > Meine Version ist eher auf Kompaktheit optimiert, weil ich damit ein > Trading System initialisieren möchte. Da ist mir Performance eher egal, > aber ich brauch meine LEs halt später für die Handelsalgorithmen. Lass mich raten: Blockchain-Transaktionen? Ich habe ansich mein working horse für schnelle Netzwerk-Aktivitäten schon (ZPUng), aber bin immer mal neugierig, was andere so an Kompaktheit raushauen.
Nein, ich will zwar auch Cryptowährung traden, aber Blockchain ist mir dann doch zu langsam. Ich interessiere mich eher für Forex Arbitrage und ähnliches. Will mich da in Richtung FPGA weiterbilden. Hab mal nen Stand von mir attached. Aber ich bin ja noch Anfänger, also werdet ihr von meinen Sources wohl kaum was lernen können.
Hi Andreas, Auch wenn ich SystemVerilog nich wirklich gut lesen kann: sieht sehr aufgeräumt und elegant aus. Kann icarus das verarbeiten / simulieren?
Keine Ahnung. Ich nehm immer diese alte Quartus2 13.0sp1 (IIRC?) Version, weil ich noch so ein ep2c5t144 Mini-Dev Board habe. Mein Kollege, mit dem ich mich regelmässig austausche (mangels sonstiger FPGA Anfängergruppen o.ä.) benutzt Icarus, und nachdem er mir damals die ersten Sources geschickt hatte, fiel uns auf, dass Icarus wohl einige sehr triviale Fehler in den Sources nicht bemängelt hatte, und Quartus diese (zu recht) nicht synthetisieren konnte. Weiss nicht, ob er noch Icarus benutzt oder jetzt auch Quartus2.
Holger K. schrieb: > Ich würde gerne ein Spiel mit VGA Ausgabe in VHDL beschreiben. Ich hätte was Ähnliches auf der TODO-Liste. Würde mich freuen, wenn wir uns austauschen könnten! Ich suche u.a. eine Emulation für die 6502-CPUs aus dem VC20.
Kollege aus dem f64 hat ne 6502 CPU gebastelt. Vielleicht könnte er helfen?
Fitzebutze schrieb: > Ab einer gewissen Komplexität schon, da bist du mit SW einfach > schneller. Die Herausforderungen bei der Spieleentwicklung waren aber immer die Echtzeitthemen, Konsistenz von Grafik und Aktion, Darstellung von Schüssen und Figuren. Da wurde verglichen, gezählt und aktualisiert. Bei CPUs entsteht immer das Problem, der scheinbaren und tatsächlichen Gleichzeitigkeit. Zu lösen ist das nur mit Tricks, Kompromissen und Überabtastung. Mit Hardware tut man sich da einfach leichter, auch wenn ihrgendwelche Zähler, Buchstaben und Strings in C einfacher zu verwalten sind. Es ist zweckmäßiger sich auf die Echtzeit zu konzentrieren und sich dort die Arbeit zu erleichtern. Für die komplexeren Sachen schreibt man sich eine engine ohne den overhead.
Das sagt man so leicht, ne eigene kleine cpu basteln... Hatte mir auch so ein projekt selbst auferlegt weil mir der nios e einfach zu langsam war, ich keine Ahnung hatte und was besseres wollte ohne teure Lizenzen kaufen zu müssen. 32 bit SOC, einfache Isa, avalon interface weil ich auch quartus benutze und mit dem qsys ding so easy Zugriff auf funktionierende sdram controller, pios etc habe. Als es in der Simulation dann lief und ich mehr testen wollte war dann aber der Mangel an Hochsprachen compilern wie c die meine CPU auch unterstützen der ausschlaggebende Punkt umzubauen und eine risc-v isa (rv32i) zu implementieren. Die ersten Tests laufen schon in der Simulation (Modelsim) aber da geht wohl noch einiges an Zeit drauf bevor man es richtig nutzen kann. Wenn es nur darum geht die games zu programmieren und zocken zu können würde ich dann auch wohl lieber was fertiges nehmen wo du dir einigermaßen sicher sein kannst das es funktioniert.
Wieviel LE brauchst Du für die CPU? Ein Kollege hat sowas gerade in so einem 15,- Cyclone 2 Board laufen.
Andreas R. schrieb: > Wieviel LE brauchst Du für die CPU? Ein Kollege hat sowas gerade in so > einem 15,- Cyclone 2 Board laufen. ...kann ich gar nicht beantworten, bis jetzt existierts nur im Simulator, gibt noch keinen Sytheseversuch und abschätzen kann ich das nicht. Ich hoffe aber das es in den Chip vom de0-nano board passt. Den meisten Platz verschlingen warscheinlich die 4 Stufige Pipeline und die avalon pipelined master und die qsys Komponenten (sd-ram controller). Ansich sind die ALU, instruction fetcher, decoder etc. sehr simpel aufgebaut, das drumherum war komplizierter.
Ah...wir haben SRam. Das ist einfacher anzusteuern. Da spart man den SD-Ram Controller. Kannst ja mal synthetisieren. Wenns unter 4,5k LE sind, passt es in das mini-dev Board.
Andreas R. schrieb: > Kannst ja mal synthetisieren. Wenns unter 4,5k LE > sind, passt es in das mini-dev Board. öh nee nicht wirklich: Total logic elements 8,488 / 22,320 ( 38 % ) Total registers 2637 und ne fmax von 54MHz (slow model) angepeilt war 100MHz ... wie gesagt da geht noch etwas Zeit ins Land bis es wirklich nutzbar ist.
Evtl. kannst Du einige LE sparen, wenn Du Register, Cache usw ins Blockram verschiebst.
Ich kann jetzt nur für Xilinx und Lattice sprechen, aber die Cores die ich kenne sollten etwa im Bereich von 1000 LUTs (6-LUT) und unter 400 Registern zu schaffen sein. Das Register-File (Tri-Port-RAM, faktisch) kann man schon ins BRAM verfrachten, aber dabei gehen dann halt recht Resourcen drauf.
Kommt doch immer darauf an was man will. Hardware Dividierer? 32 Bit Barrelshifter in einem Takt? Pipelining? Wie viele Register? In meinem aktuellen Hobbyprojekt stecken - 6 Stück 32 Bit RISC mit Dividierer, Barrelshifter, 256 Registern,Instruktion- sowie Datacache, Sprungvorhersage - 1 x Z80 - 1 x ARM7TDMI - 3 verschiedene Spriteengines - Ansteuerung für VGA, Sound, SDCard, SRAM, SDRAM, Flash, Seriell, Kleinkram - Alles getaktet auf 100 Mhz Zusammen in 80000LE, Kostenpunkt für ein FPGA Board der Größe knapp über 100€. Wofür soll man sich da selbst kasteien? Wer so viel Zeit reinsteckt tut sich nicht unbedingt einen Gefallen ein paar Euro am FPGA Board zu sparen. Warscheinlich sind die Stromkosten durch Synthese und Simulation größer als die Kosten fürs Board.
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.