mikrocontroller.net

Forum: FPGA, VHDL & Co. Einfach zu implementierende CPU in VHDL


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
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
von Christoph db1uq K. (christoph_kessler)


Bewertung
0 lesenswert
nicht lesenswert
FÜr freie Implementierungen ist Opencores eine gute Adresse:
https://opencores.org/
z.B. 197 Prozessor-Projekte

von Bit Spalter (Gast)


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

von Fitzebutze (Gast)


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

von Weltbester FPGA-Pongno (Gast)


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

von sucher (Gast)


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

von Holger K. (holgerkraehe)


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

von Fitzebutze (Gast)


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

von Michael B. (laberkopp)


Bewertung
0 lesenswert
nicht lesenswert
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
von Holger K. (holgerkraehe)


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

von Duke Scarring (Gast)


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

von Halligalli (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Mein gedachter Hardware-Tile/Sprite-Renderer von 
Beitrag "Bauen oder nicht bauen ?"  scheint niemanden zu 
beeindrucken, doch vielleicht hast du Lust das zu entwickeln  :-)

von Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)


Bewertung
2 lesenswert
nicht lesenswert
Halligalli schrieb:
> scheint niemanden zu
> beeindrucken

Hab ich gerade gelesen... steht nur Quatsch drin.

von Halligalli (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
Ist schon in Ordnung...ich habe sowieso das Gefühl das diese Technologie 
nicht freigegeben ist wegen Patenten und so...

von Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)


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

von Holger K. (Gast)


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

von Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite


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

von Halligalli (Gast)


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

von Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite


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

von Halligalli (Gast)


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

von S. R. (svenska)


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

von foobar (Gast)


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

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Space Invaders! Wie süss! Ich hätte nicht übel Lust, auch mal wieder 
sowas zu bauen.

von Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)


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

von Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)


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

von Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)


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

von Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)


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

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
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
von Fitzebutze (Gast)


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

von Holger K. (Gast)


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

von Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite


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

von foobar (Gast)


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

von Fitzebutze (Gast)


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

von S. R. (svenska)


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

von Jürgen S. (engineer) Benutzerseite


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

von Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite


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

von Bert (Gast)


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

von Ralfi (Gast)


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

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
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
von Jürgen S. (engineer) Benutzerseite


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

von Andreas R. (daybyter)


Bewertung
0 lesenswert
nicht lesenswert
Gibt es hier einen Fortschritt bzgl zpu und sdram Einbindung? Hab auch 
eine zpu implementiert und häng an der sdram Einbindung.

von Holger K. (holgerkraehe)


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

von Markus F. (mfro)


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

von Holger K. (holgerkraehe)


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

von Martin S. (strubi)


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

von Andreas R. (daybyter)


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

von Martin S. (strubi)


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

von Andreas R. (daybyter)


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

von Holger K. (holgerkraehe)


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

von Martin S. (strubi)


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

von Andreas R. (daybyter)


Angehängte Dateien:

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

von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
Hi Andreas,

Auch wenn ich SystemVerilog nich wirklich gut lesen kann: sieht sehr 
aufgeräumt und elegant aus. Kann icarus das verarbeiten / simulieren?

von Andreas R. (daybyter)


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

von Harald (Gast)


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

von Andreas R. (daybyter)


Bewertung
0 lesenswert
nicht lesenswert
Kollege aus dem f64 hat ne 6502 CPU gebastelt. Vielleicht könnte er 
helfen?

von Jürgen S. (engineer) Benutzerseite


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

von Christian G (Gast)


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

von Andreas R. (daybyter)


Bewertung
0 lesenswert
nicht lesenswert
Wieviel LE brauchst Du für die CPU? Ein Kollege hat sowas gerade in so 
einem 15,- Cyclone 2 Board laufen.

von Christian G (Gast)


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

von Andreas R. (daybyter)


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

von Christian G (Gast)


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

von Andreas R. (daybyter)


Bewertung
0 lesenswert
nicht lesenswert
Evtl. kannst Du einige LE sparen, wenn Du Register, Cache usw ins 
Blockram verschiebst.

von Fitzebutze (Gast)


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

von FPGAzumSpass (Gast)


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

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.