www.mikrocontroller.net

Forum: FPGA, VHDL & Co. FPGA für 3D Berechnungen


Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen!
Ich plane zur zeit mit meinem Kumpel eine Art Grafikkarte für einen AVR
zu realisieren. Unseres Ziel wäre es eine, 3D fähige Karte zu schaffen,
die wir in Software bereits zum laufen gebracht haben (aber nur sehr
langsam^^). Da wir nicht das Budget für leistungsstarke MCU´s haben
(leider erst 16 )-: ), würden wir die notwendigen Berechnungen gerne
mit FPGA realsisieren. Wir haben zwar Ahnung von C und ASM, doch leider
nur sehr wenig Ahnung von FPGA´s und VHDL usw., deshalb wissen wir nicht
was man solchen FPGA von Xillinx und co für 5-6€ zumuten kann? Unser
Hauptproblem ist das Multiplizieren von 24bit "Variablen". Unser
Prgramm verzichtet komplett auf Fließkomma, was die Sache
wahrscheinlich stark vereinfacht. Da wir sehr viele dieser
Multiplikationen benötigen, haben wir uns überlegt mehrere FPGA´s
parallel arbeiten zu lassen. Doch wie viele 24bit
Multiplikationenwürden sich mit so einem 5-6€ FPGA pro Sekunde ungefähr
realisieren lassen? Könnte man auch mehrere dieser Einheiten in einem
FPGA unterbringen?

Wir würden uns sehr über eure Hilfe freuen
Gruß Martin + Lars

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so, bins nochmal!

Natürlich würden auch CPLD´s gehen, wir wissen halt nicht, was bessern
geeignet ist und ob wir überhaupt näherungsweise an die benötigte
Leistung herankommen!

Gruß Martin + Lars

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CPLDs sind zu klein für eure Anwendung.

FPGAs bekommt man privat aber kaum für 5-6€ und außerdem sind sie nur
in SMD verfügbar. Könnt Ihr ein 200poliges Gehäuse löten?

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht ist das was für euch:
http://icculus.org/manticore/

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, danke schonmal für eure Hilfe!!

Der Link ist schonmal sehr interessant. Das ist ja schonmal ein Beweis,
dass es möglich sein muss, sowas zu realisieren^^.

Die 5-6€ waren auf die CPLD´s bezogen, hab aber ausversehen FPGA
geschrieben, deswegen auch der 2. Post! Die 200 Pins sind schon
abschreckend, doch der Vater von meinem Kumpel lötet viel mit SMD, der
kann uns da bestimmt helfen. Ich habe jetzt noch nicht genau gerechnet,
wie viel Leitung wir brauchen, aber er sollte schon paar Millionen 24bit
Multiplikationen pro Sekunde schaffen. Da man die einzelnen Vektoren der
Vertexes alle parallel transformieren usw. kann, wäre es denkbar mehrere
solcher Multiplikatoren, Addierer parallel arbeiten zu lassen. Ist dass
alles zu hoch gegriffen, oder glaub ihr, dass sowas realisierbar ist?
Was würde so ein FPGA ungefähr kosten?

Gruß Martin

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem mit den grossen, schnellen FPGAs ist, dass sie nur in BGA
Gehäusen zu haben sind. Ein Spartan3S400 mit über 400 Pins
beispielsweise liegt so bei ca. 30.- Dann ist das Teil aber noch nicht
auf einem Board. Auch da gibt's Probleme. Mit einem einfachen homemade
PCB wird das nix. Da müssen schon 4 Lagen inkl. Groundplane her.
Ich würd euch raten kauft euch für 100-150 Euro ein fertiges Eval-Board
mit nem schicken FPGA drauf, da wisst ihr dann, dass es auch garantiert
funktioniert.

Gibt's z.B. hier:

http://www.xilinx.com/
http://www.nuhorizons.com/devboards/
http://www.digilentinc.com/
http://www.altium.com/Products/AltiumDesigner/LiveDesign/

Autor: Breti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kann Euch sagen, dass die Xilinx FPGA 18x18bit Multiplizierer in
Hardware eingebaut haben. Der Spartan3 200 hat davon 12 Stück (das ist
der, der auf dem Dev Kit für 99$ drauf ist).

Gruß,
       Thomas

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh, 400 Pin BGA is näturlich bischen arg viel^^
Man könnte theoretisch die kommplette transformation und Umrechnung der
3D-Vertex-Daten in 2D-Koordianten in einem FPGA erledigen und einfach
mehrere "Pipelines" parallel arbeiten lassen, dass wäre auch das
Bussystem sehr einfach, denn man bräuchte nur einen Bus zum
Vertex-Daten Speicher und einen zum Ausgangpuffer, der die 2D
Koordinaten usw. enthält, aus der dann auch ein kleiner CPLD oder
ähnliches in der Lage sein soltle die eigentlichen Dreiecke zu
zeichnen. Dann würde ja auch ein FPGA mit 40-50 Pins reichen, sofern
die Ressourcen reichen. Würde nicht so ein Spartan3 mit 144 Pins
ausreichen, oder besitzt der zu wenig Logikzellen? Ich kenne mich
leider nicht damit aus.

Trtzdem vielen Danke für deine Hilfe!
Gruß Martin

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Breti
Hey Danke, das wäre schonmal ein guter Ansatz!
Liefert dieser 18x18bit Multiplizierer auch ein 36bit Ergebniss, oder
auf 18bit gekürzt, wie ich es schon bei machen MCU erlebt hab?
Wie schnell sind die so, konnt im Datenblatt noch nix dazu finden?
Gruß Martin

Autor: Markus K. (markus-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier gibts die Übersicht über Xilinx-CPLDs und deren Bauformen:
http://www.xilinx.com/products/silicon_solutions/f...

Ein Spartan3-200 gibts auch im 100-poligen Gehäuse, allerdings bleibt
das Problem mit der Platine bestehen. Ein fertiges Board zu nehmen ist
sicher die sinnvollste Lösung.

Die 18x18 Multiplikation hat ein 36Bit Ergebnis:
http://direct.xilinx.com/bvdocs/appnotes/xapp467.pdf

Zur Geschwindigkeit: Beim Virtex4 hat hat Xilinx mal Werbung gemacht,
er könne bis zu 250 Milliarden MACs (Multiplikationen+Addition) pro
Sekunde durchführen (natürlich nur der größte und teuerste Chip).

Ihr solltet auch an den Speicher denken. Reicht der interne SPeicher
der FPGAs oder müßt Ihr externen anbinden?

Autor: Markus K. (markus-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das sollte natürlich "Xilinx-FPGAs" heißen.

Es gibt übrigens auch Evaluation-Kits mit VGA-Ausgang. Dann könntet Ihr
das Bild auch gleich mit dem FPGA ausgeben (wobei die meist eh' nur aus
ein paar Widerständen bestehen).

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
250 Milliarden MAC´s wären für unser Projekt denke ich zu viel, da wir
nicht Millionen von Polygonen pro Sekunde rendern wollen^^

Aber wenn dort bis 250 Milliarden drin sind, sollte man mit so einem
Spartan 3 doch locker 10 Millionen Multiplikationen schaffen, was uns
denke ich ausreichen würde, außer wir wollen noch Texturen auch die
Polygonen legen.
Ich hatte mir vorher den 3S400 angeschaut, da er 16 Multiplikatoren
hat, deswegen die 144 Pins!

Ich werde mir dass ganze nochmal genau durchlesen!
Nochmals Danke

Gruß Martin + Lars

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

also erstmal sage ich, dass ich die Idee gut finde

Aber ein Paar Fragen:
wozu eine Grafikkarte für AVR? -> meiner Meinung nach vollkommener
Blödsinn, denn so eine Grafikkarte ist um Größenordnungen schneller und
komplexer als AVR
Ich sage euch, ihr braucht Speicher, und das nicht zu knapp. Am besten
SDRAM
10 Mil Mult/sec ist zwar nicht sehr viel, aber wie kommen die Daten zum
FPGA? Über welche Busse? Vom AVR aus? Rechne mal aus, wieviele Daten für
z.B. ein Rechteck übertragen werden müssen.

Aber okay, es sei dahingestellt, ob man sowas braucht oder nicht ;-)
Aus dem sportlichen Interesse, würde ich es auch probieren :-o

ASM und C bringt bei FPGAs ncihts. Ihr solltet tiefer in die Materie
einsteigen, sonst habt ihr keine Chance.

Was ich machen würde, ist einfach Microblaze/Picoblaze/Nios oder wie
auch immer zu nehmen, und Pixel für Pixel zeichnen. Da könnt ihr C und
ASM nehmen und ggf. eigene Instruktionen implementieren.

Falls ihr Fragen habt, stellt einfach - ihr müsst ja ein Rad nicht neu
erfinde ;-)

Gruß
Kest

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach, noch was hinterher:

wie wäre es mit OpenGL? :-o :-)

Kest

Autor: alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>10 Mil Mult/sec ist zwar nicht sehr viel, aber wie kommen die Daten
zum
>FPGA? Über welche Busse? Vom AVR aus? Rechne mal aus, wieviele Daten
>für
>z.B. ein Rechteck übertragen werden müssen.

Das ist richtig, dass es eine hohe Datenrate erfordert, aber da man die
Grafikkarte selber zusammenbastelt, kann man auch das Protokoll zwischen
dem AVR und dem FPGA beliebig gestalten, z.B. statt die Daten für ein
ganzes Rechteck, "nur" die Koordinaten der Eckpunkte vom AVR zum FPGA
übertragen und im FPGA dann das Rechteck berechnen und im Speicher
ablegen...
Ich denke, dass das Ziel, gleich mit 3D-Operationen anzufangen, zu hoch
gesetzt ist. Ich würde am Besten mit primitiven Funktionen anfangen, wie
Punkte, Geraden, Kreise usw., schauen wie man sie auf dem FPGA
realisieren könnte. Wie hoch ist der Auffand, vielleicht ist
Microblaze/Picoblaze/Nios doch besser als selber einen Automaten zu
programmieren.
In OpenGL fängt man meines Wissens auch mit Punkten an und wie man die
Punkte verbindet usw.

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit Übertragung von "nur" Eckkoordinaten habe ich auch so
gemeint.

Aber trotzdem ist das halt viel zu viel - denn für 3D müssen schon
viele Dreiecke übertragen werden...

Langsam fange ich an zu denken, dass es machbar ist. Aber nur unter
Zuhilefnahme von einem Sofprozessors.
Ich könnte es mir so vorstellen, dass man erst die ganzen Displaylisten
lädt (also einen Satz aus Dreiecken) und dann noch, genau wie bei OpenGL
nur Matrizen überträgt, wie alles dargestellt werden soll. Aber es wird
arschlangsam - mit einem AVR, möchte mir jetzt zwar nicht Mühe machen
alles auszurechnen, wieviele Zyklen was braucht, aber mit 15 MHz oder
so wird es nichts :-/

Kest

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen!

Ok, eine 3D-Fähige Graka für einen AVR ist schon etwas übertrieben,
aber wir haben noch ein zweites Projekt in der Mache. Wir versuchen
ähnlich wie es Dennis Kuschel mit seine MyCPU geschafft hat eine CPU
nur aus einzelnen Gattern aufzubauen. Die Simulation sieht schon ganz
gut aus, leider nur noch zu langsam^^ Hierfür wäre diese 3D Karte auch
ganz geschickt, damit man diese eigene CPU nicht komplett umsonst
aufbaut, sondern um auch bischen was damit anfangen zu können. Aber
wieder zum eigentlichen Thema:

Die Vertex(Eckpunkt)-Daten werden von einem AVR, oder was auch immer in
einen Dual Port RAM geladen. Jetzt muss der FPGA diese Daten "nur"
laden, was bei den von uns angepeilten maximalen 30000 Vertexes nicht
all zu viel Verkehr bedeuten sollte. Wir haben mal so 20Mbyte/sek
angepeilt, was sich doch noch realisieren lassen sollte, oder?
Bewegungen und co. die auf Objekte angewandt werden sollen, werden
sollten auch vom FPGA erledigt werden, da ein AVR dafür sicherlich
deutlich zu langsam wäre.

Wenn die Daten erstmal in dem FPGA angekommen sind, muss er ja nur noch
ein paar Rotationen und Verschiebungen vornehmen, was auch zu schaffen
sein sollte. Soll ich mal posten, wie wir uns den Ablauf der
Konvertierung der 3D zu 2D Daten vorgestellt haben?

Weiterhin bräcuhte man noch einen schnellen Speicher, der als z-Buffer
arbeitet und dann halt noch die Einheit, die aus den nun 2D Eckdaten
Dreiecke zeichnet. Hierfür habe wir leider noch keinen schnellen
Algorythmus gefunden.

Wenn denn noch "Rechenleitung" übrig sein sollte, könnte man ja auch
noch anstatt die Dreiecke nur in einer Farbe zu zeichnen, eine
Texturierungseinheit hinzufügen. Wenn dann noch etwas übrig ist, könnte
man noch über Lichtquellen nachdenken, was ich aber eher für
unwahrscheinlich halte.

Ich freue mich sehr über eure Hilfe und dass ihr glaub, dass es möglich
sein könnte^^

Gruß Martin + Lars

Autor: anderer Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1. Man kann keine genauen Angaben zu der Geschwindigkeit der 18x18
Multiplizierer machen. Es wird zwar eine Geschwindigkeit angegeben, die
gilt aber nur für eine optimale Schaltung. Dies bedeutet der FPGA ist
fast leer und besitzt nur die eine Schaltung. Dadaurch können die
internen Verdrahtungen der Logikelemente optimal durchgeführt werden.
Doch auch selbst dann erreicht man die angegebene Geschwindigkeit nur
wenn man Zeiten für die einzelnen Netze vorgiebt. Dies ist jedoch schon
sehr aufwendig.

2. Wenn das komplette Projekt erstellt ist, dann erstellt man das File
für den FPGA. Das Synthesetool seigt einem dann den maximal möglichen
Takt an, mit dem das System betrieben werden kann. Nimmst Du einen
höheren, dann kann das gesamte System asynchron kaufen.

3. Der FPGA wird am besten mit VDHL programmiert (in Fachkreisen auch
"konfiguriert" genannt, da man die Schaltung aus vorhandener Logik
zusammenstellt)  Er so erzielt man ein gutes Timing. Einen
Mikroprozessor im FPGA zu implementieren halte ich für falsch. Dann
kann man auch gleich einen kaufen. Die laufen immerhin auch schon mit
über 100MHz.

4.Der Absolute Vorteil vom FPGA ist, das Du alle Multiplizierer
gleichzeitig rechnen lassen kannst (parallele Prozesse jeder Prozess
bekommt den gleichen Takt, so das alle gleichzeitig ausgeführt werden).
Beim Mikroprozessor wird dies immer nacheinander ausgeführt. Die Kunst
ist es die 18x18 Multiplizierer schnell genug mit Daten zu versorgen.
Der Bus zum RAM wird der Flashenhals werden. Da nur einer gleichzeitig
darauf zugreifen kann. Du hast aber viele Muliplizierer die mit ca. 50
oder 100MHz arbeiten. Das bedeutet wenn du 12 Multiplizierer hast, dann
must Du mit 100MHz * 12 auf den Speicher zugreifen. Das ist zu schnell.
Der FPGA hat jedoch selber interne RAM-Blöcke. Diese kannst Du so
auslegen wie DU möchtest (Busbreide der Adress und Datenleitungen).
Mein Tip ist nimm für jeden Muktiplizieren einen eigenen RAM-Block
(einfach Modul aus der Bibliothek auf den Schaltplan ziehen) Erstelle
ein VHDL-Modul und verbinde die ganzen Leitungen miteinander.

Als besten FPGA für Deine Anwendung würde ich Dir zum Xilinx XC3S400
mit 144Pins raten. Das Löten wird echt schwer. Deshalb unbedingt ein
Kit kaufen. Zudem must Du sonst noch die ganze externe Beschaltung
machen und das wird einfach zu viel Arbeit.

Grüsse

Micahel

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey, danke!

Ich habe mir zu VHDL schonmal ein paar Tutorials durchgelesen, bin aber
immer ziemlich früh hängen geblieben, da ich spätestens mit dem Ablauf
der "Kompilierung" & Synthese nicht mehr durchgestiegen bin. Das
bedeutet noch viel Arbeit für uns^^

Der Ram könnte schon ein großes Problem werden, jedoch müssen nicht für
jede Multiplikation neue Daten geladen werden, da die Berechnung pro
Vertex oder Polygon mehr als eine Multipliaktion in Anspruch nimmt.
Trtzdem wird ein höherer Datenverkehr, als ich oben geschrieben hatte
zu stande kommen, da ich nur die rohen Koordinaten der Vertexes
miteingezogen hatte. Mann könnte doch die Daten in einen SDRAM legen,
aus dem man die Daten immer mit kompletter Burstlength läd mit z.B.
16bit breite, dann kommt auch eine ordentliche Bandbreite bei raus.
Diese Daten könnte man ja in den FPGA internen RAM Modulen ablegen
(brauchen die eigentlich nicht zu viel Kapazität?).

Das nächste Problem, nämlich die Bildausgabe, könnte man auch mit einem
SDRAM realisieren, wobei dann schon viele Pins draufgehen und der
Lötaufwand recht groß werden dürfte....
Außerdem bräuchte man vielleicht noch einen Texturspeicher, denn man
aber in den Bildspeicher legen könnte, da der Ausgangpuffer eh nur
einen Bruchteil des Speicher belgen sollte.

Den S400 hatte ich auch schon im Visier, da er noch 2 weitere
Multiplikatoren und auch mehr Ressourcen besitzt.

Gäbe es noch eine andere Denkbare Lösung, um das ganze zu vereinfachen
oder zu beschleunigen?
Und außerdem, ist sowas als Anfangprojekt überhaupt zu schaffen?

Gruß Martin

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gleich zu der letzten Deiner Frage:

nein, es ist als Anfangsprojekt nicht zu schaffen (das sagt euch jeder
anderer auch)

Sucht euch was anderes, was ihr machen wollt. Wenn mit FPGAs, dann was
anderes - einfaches. Wenn mit 3D-Grafikkarte, dann vielleicht andere
Chips (Procesorren), oder gleich DirectX, OpenGL und Co

Kest

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, dachte mir schon fast, dass es nicht funktionieren würde, nachdem
was ich hier alles so gelesen habe.
Aber was schätzt ihr, wie viel Einarbeitungszeit man benötigt, wenn man
das Programm, also auch den Ablauf, wie es funktionieren soll schon
fertig hat und auch weis, wie es funktionieren muss?

Außerdem wäre ich sehr an einem Einsteigerboard für FPGA interessiert.
Was haltet ihr von dem Spartan 3 Starter Kit für 99$?
Wäre das gut für anfänger geeignet und könnte man darauf auch später
die 3D-Karte aufbauen, oder ist der S200 dafür zu unterdimensioniert?

Außerdem würde es mich interessieren, was dieses Einsteigerpaket hier
in Deutschland so ungeähr kostet und wo es gut zu beziehen ist?

Wenn ihr Vorschläge für andere Boards habt, dann immer her damit (-;
Gruß Martin + Lars

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, noch was vergessen!

Ist es eigentlich auch möglich in dem FPGA einen Controller zu
implementieren und nebenbei noch eine 3D-Engine laufen zu lassen? Wäre
sehr geschickt, denn dann könnte man, falls es mal soweit kommt, noch
einfache Effekte wie Kreis, Rechteck usw. von diesem berechnen lassen.

Gruß Martin + Lars

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also wenn man "Ahnung" von FPGAs hat und Zeit, dann sage ich mal, dass
man in ...ähh... nee, zur einer Aussage lasse ich mich nicht hinreißen
;-)

Ich habe etwas ähnliches in Java mal geschrieben. Also quasi jeden
einzelnen Punkt selber gezeichnet und ganze Beleuchtung noch dazu. Es
waren halt 5 fps, aber es sah schick aus :-) Dabei habe ich aber
doubles und floats benutzt - für FPGA ungeegent.

Und überhaupt ist im FPGA alles anders - Datenfluß meine ich. Aber das
muss man erst kapieren, ist schwer zu erklären

Ein Starter Kit ist ein Anfang, aber wenn Du etwas wartest (scheiße,
sage es shcon seit Monaten :-@), dann kommt im Februar neues von Xilinx
raus, der hat dann SDRAM und USB und Ethernet und ist auch 3S500E, also
etwas größer - für 149$

Den alten, für 99$ bekommt man z.B. bei segor (glaube ich), aber für
ca. 120 €

Zu den zweiten Frage, ob man einen Controller drauflaufen lassen kann:
das meinte ich mit SoftCPUs.
Du kannst einfach einen Prozessor implementieren, den Du mit C
programmieren kannst (oder eben ASM). Da könntest Du Deine ganzen
Routinen (Dreieck, Beleuchtung, 3D) berechnen. Ist halt C. Wenn Du
bestimmte Operationen brauchst, z.B. Matrizen berechnen in einem Takt
;-), dann kannst du sie extra implementieren (mit VHDL), und dann aus C
raus darauf zugreifen. Vieles wird Dir damit abgenommen, aber halt nicht
alles. So ein Soft-CPU läuft langsamer als sonst.
Google einfach nach NIOS, Microblaze, Picoblaze oder schaue bei
www.opencores.org vorbei. Kannst auch AVR-Core herunterladen und auch
im FPGA implementieren. HAst dann AVR und Deine 3D Karte in einem
FPGA...

Na ja... lange Geschichte

Kest

Autor: Daniel R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zum VHDL und FPGAs:
Das lernt man nicht mal so nebenbei in 3 Wochen wie C. Da steckt viel
viel mehr dahinter. Programmierkenntnisse nützen gar nichts, da alles
komplett anders abläuft. Einarbeitungszeit kann man so nicht sagen.
Einer, der schon 10 Jahre Hardwareentwickler ist wird da nicht so lange
brauchen... Jeder andere braucht da jedoch eine Ewigkeit(im Vergleich
zur Einarbeitungszeit in C).
Mach dir um die Größe des XC3S200 mal keine Sorgen. Den wirst du erst
in 5 Jahren mal voll kriegen. Das Xilinx Spartan3 STK für 99$ ist sehr
gut. Kann ich nur empfehlen.

Weiterhin empfehle ich:
Fangt erst mal klein an. Macht mal ne LED auf dem Board an oder lasst
eine blinken...glaubt mir, das ist am Anfang, wenns einem niemand zeigt
schon eine richtige Herausforderung.

Viel Spass!

Daniel

Autor: A. N. (netbandit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich empfehle dir das Buch "VHDL-Synthese" das ist sehr gut
geschrieben und vor allem praxismah. Schon nach dem ersten Kapitel
blinkten bei mir die ersten LEDs so wie ich es wollte :)

Nach 2 Tagen hatte ich meinen ersten 3bit Zähler und nach 4 Tagen einen
beliebig tief definierbaren Zähler.
Nach einer Woche stand mein erster Zustandsautomat.

Die schwierigkeit bei VHDL ist nicht den Syntax zu erlernen sondern das
was da hinter steht zu verstehen. Allerdings glaube ich, dass hier auch
die Übung den Meister macht.

Im übrigen sitze ich inzwischen länger an der Einarbeitung in die
Xilinx ISE bzw. in ModelSim als in die Einarbeitung in VHDL. :)

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit VHDL habe ich ja schonmal angefangen und war auch schon recht weit,
halt nur Online-Tutorials. Der Unterschied ist meiner Meinung nach
halt, dass man wissen muss, wie die verschiedenen Hardwareabschnitte
miteinander komunizieren und auch arbeiten, was man bei C und ASM zum
Glück nicht muss*g*. Das Problem war bis jetzt, dass ich mit den Tools
nicht zurecht kam, aber mit so nem Startkit wird ma sich da schon
schnell dran gewönen.
Wahrscheinlich werde ich warten, bis dieses Board 150$ herauskommt,
wobei ich über den S500 noch nix unter der Sparte Spartan3 finden
konnte, aber das is ja ein anderes Problem...

Habe mir auch mal Microblaze angeschaut und bischen so durchgelesen. Da
ist ja eine FPU mit integriert, die auch recht zugig arbeitet, was die
Cyclen angeht, wobei ich mich frage, auf was sich diese Cyclen
beziehen?? Ist das die Frequenz, mit der der FPGA getaktet ist?

Fließkomma hätte auch deutliche vorteile, da viele Berechnungen
einfacher zu bewältigen wären, als mit Interger. Wäre es außerdem
möglich die FPU so zusagen zu "extrahieren" und dann "Kopien" davon
einzufügen, die sich dann halt anders ansprechen lassen, aber parallel
arbeiten können, oder ist in einem S400-S500 dafür nicht genug Platz
zur Verfügung? Wenn das gehen würde, könnte man ja wie oben geschrieben
Funktionen, die Matrizen beötigen in sehr wenigen Takten durchführen,
wodurch man deutlich mehr Polygone darstellen könnte, als wir uns
erhofft hatten.
Außerdem ist die Performance für Spartan3 mit 92 DMIPS angegeben, aber
nur für den S1500. Kann man davon ausgehen, dass der S400-S500 deutlich
langsamer ist, oder schenken die sich fast nichts??

Danke nochmal an euch alle, für eure Unterstützung!!
Gruß Martin

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Außerdem ist die Performance für Spartan3 mit 92 DMIPS angegeben, aber
nur für den S1500. Kann man davon ausgehen, dass der S400-S500
deutlich
langsamer ist, oder schenken die sich fast nichts??

Genauer stehen die 92DMIPS für einen S3-1500-5 auf 100MHz. Wieveil
resourcen noch frei waren (Füllgrad) ist unbekannt. Ich schätze nur 20%
des Test-FPGA's waren vom design belegt.

Die Frage ist, ob die 100MHz auch für andere Chips erreichbar sind.
Das ist eher eine Frage der Auslastung. Ich hab mal einen S3-1000-4
gesehen, der bei 60% Füllgrad die 100 Mhz für den uBlaze schaffte, bei
96% nur noch 85Mhz. Ein Wechsel auf den schnelleren speedgrade -5
liessen noch 92 MHz erreichen. Also für 100 Mhz sollte Dein chip
höchstens zu 60% voll sein, etwas Luft hast du bei speedgrade -5 aber
auch da sind sind die 100 Mhz nicht immer drin. Werte für die FPU habe
ich nicht.

und 92 DMIPS entsprechen einen Pentium P66 von 1993 ...

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt keinen 500 in der Spartan3 Familie,
was Du suchst ist der 500 der Spartan3E Familie (XC3S500E), dafür
hats Datenblätter bei Xilinx

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah, danke, das mit dem S500E hab ich grad gemerkt, aber du warst
schneller*g*

20% Des Chips sind ja noch recht wenig, des heißt, mann könnte noch
mehrere FPU´s hinzufügen, ohne den FPGA so voll zustopfen, dass er wie
du gesagt hast, die 100Mhz Grenze nichtmehr schafft.

Naja, dann werd ich ´mich jetzt mal nach dem oben genannten Buch oder
was ähnlichem und so nem Board umschauen.

Gruß Martin

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also ich an eurer stelle würd mir einen arm7tdmi hernehmen der ein
ext-mem interface hat.. (z.b lpc22xx) der kann 32*32bit=>64bit in 4
zyklen multiplizieren (geht auch noch schneller weil er
earlytermination kennt... sprich 8*8bit dauert 1nen zyklus ,)...

die dinger kannst bis 60Mhz takten => 15millionen multiplikationen
theoretisch.. mit daten schieben wirst das zwar nie erreichen aber es
gibt ja auch noch schnelleres...

und in den fpga packst dann  den bitmap=>vga converter.. das sollte
doch schon genug aufwand sein glaubich...

nebenbei ist ein arm eine 32bit maschine.. also ist das ding mit deinen
24bit variablen mehr als zufrieden (btw 24*24bit müsste übrigens nur 3
zyklen beim multiplizieren dauern so wich ich das verstanden hab)..

den fpga mit sdram controller packst an extmem ding vom arm .. dann
hast du bis zu 3*16MB ram zur verfügung und dank fpga alles billiger
sdram...

und wenn du ganz lustig sein willst machst du dann eben noch einen
vga-output mit dem fpga...

sollte doch auch genug aufwand sein und ist glaubich.. und falls du
doch mal einen 3d-beschleuniger drantun willst... der arm hat genug
leistung um dir die daten dafür auch wirklich liefern zu können.. ich
mein zero waitstates bei 60Mhz takt und das bei 32bit
speicherinterface.. das sollte doch reichen ;D

73
73

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Hans!

Das ganze mit einem ARM anzugehen hatten wir uns auch überlegt, aber da
wir mit diesen schon viel gemacht haben, wollten wir uns mal in ein
neues Thema einarbeiten.
Als 32-bit Maschine bietet er sich natürlich schon an, aber der FPGA
mit FPU hat doch deutliche Vorteile, was z.B. Trigonometrische
Funktionen angeht, die sich mit ARM nur sehr langsam verarbeiten lassen
würde. Und da zumindest ich es nicht eilig habe, werde ich mich auf
jeden Fall mal in diese FPGA´s oder besser VHDL einarbeiten und dann
kann ich immernoch schauen, was mir einfacher erscheint, oder mit was
man bessere Ergebnisse erzielen kann.

Wenn wir schon bei VHDL sind, kennt jemand dieses Tutorial?

http://tams-www.informatik.uni-hamburg.de/vhdl/doc...

Wenn ja, was haltet ihr davon? Naja, hab ich wenigstens was zu lesen,
bis ich mir ein Buch gekauft hab*g*

Trotzdem Danke für deine Hilfe!
Gruß Martin

Autor: bla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke!
Da war ich vorher schon, aber die Seite ging ned, scheinen den Fehler
behoben zu haben. Werd ich auch mal anschauen.

Mir is aber noch ne andere Idee gekommen:

Der VHDL Code kann ja soweit ich des verstanden hab in einen Schaltpla
gewandelt werden, oder? Ist es auch möglich einen Schaltplan zu
erstellen und darauf dann den "Code" für den FPGA zu gewinnen? Wäre
spitze, denn die CPU die wir entworfen haben wäre ziemlich groß, wenn
man sie mit TLL-IC´s aufbauen würde und da würde so ein FPGA ganz gut
passen.....

Gruß Martin

Autor: fpgaküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm also FPGA <-> Schaltplan heisst RTL view oder schematic entry.

Tools die aus jedem schaltplan VHDL code generieren kenn ich nicht,
üblich war in der Anfangszeit der sog. schematic entry für FPGA's.
also Kästchen verdrahten Knopf drücken und schwerleserlichen Code
erhalten. In der ISE/Webpack ist vielleicht sowas drin, aber da müsstet
ihr den schaltplan nochmal reinhacken. Im weiteren Einsatz war der
VHDL-Designer von Mentor Graphics, auch so VHDL Maltool.
Hat sich aber nicht durchgesetzt, da ineffizient (schlecht FPGA spezif.
Tricks nutzbar) und schwer wartbar.

Die andere Richtung (RTL-view) kommt zu dokuzwecken und analyse (wie
sage ich der synthese das ich ein FF und kein Latch haben will).
Eigentlich jedes Synthesetools macht das. Eine Zwei tool übersetzung
ist zu vermeiden, also ein Tool für VHDL-RTL Bildchen und ein anderes
für
VHDL-FPGA. In der Regel übersetzen beide den code auf eigene Weise und
es ist unbekannt, was nun wirklich im FPGA werkelt.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo fpgaküchle!

Ich habe halt hier im Forum gelesen, dass machne Leute ihre CPLD´s
konfigurieren, deshalb hab ich auch gedacht, dass es mit FPGA´s gehen
müsste. Es war sogar ein Xilinx CPLD und das ISEweb Pack.

http://www.mikrocontroller.net/articles/CPLD

Hier steht ja auch, dass man den CPLD aus einem Schaltplan heraus
konfigurieren kann. Wenn ich dich nicht falsch verstanden habe, hast du
ja beschrieben, dass der Schaltplan in VHDL übersetzt werden soll, was
ich eigentlich garnicht vor hatte, aber vielleicht hab ich dich falsch
verstanden.

Kanns eigentlichs ein, dass das Forum in letzter Zeit ziemlich viele
Ausfälle hat??

Gruß Martin

Autor: T.M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, das geht auch mit FPGAs. Wenn ihr schon nen Schaltplan habt ok, aber
sonst würde ich sowas nicht empfehlen. Ich selber hab noch nie mit dem
Schematic Editor von Xilinx gearbeitet, bin aber schonmal bei dem von
Lattice verrückt geworden. Da hat man viel Probleme sich in die
Bedienung des Programms einzuarbeiten, bevor man produktiv tätig wird.
Ich kann mir nicht vorstellen, dass es bei dem Webpack anders is...

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Schaltplan steht sowit, bis auf ein paar Änderungen, die noch
vorgenommen werden müssen. Wäre es dann noch möglich, Cores, wie
UART/SPI usw. von OpenCores mit in diese Schaltung einzubinden? Müsste
doch theoretisch gehen, weil man VHDL ja auch in diese Schematics
"zerlegen" lassen kann. Das wäre dann natürlich perefekt, denn man
könnte sich schon ordentlich in die Materie FPGA einarbeiten und nach
und nach noch VHDL oder so erlernen...

Gruß Martin

Autor: T.M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sowas geht bestimmt. Bei Lattice geht es auf jeden Fall, da erstellt man
im Schematic sogenannte Black Boxes, die man dann mit VHDL-Code
ausarbeiten kann. Man muss dabei nur die im Schematic festgelegten
Schnittstellen beachten. Ich habe aber wie gesagt im Webpack noch nie
damit gearbeitet, da ich immer von grundauf alles in VHDL mache.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann hoff ich mal, dass dieses 150$ Board auch hier bald rauskommt,
damit wir dann mal loslegen können.
Um VHDL werden wir denk ich mal höchst wahrscheinlich nicht herum
kommen, aber für den Anfang denke ich mal, das diese Schaltplan
Geschichte ausreichen wird!

Also, nochmal danke an euch alle!!!
Gruß Martin

Autor: T.M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei Trenz Electronic steht das Spartan-3E Starter Kit auch schon im Shop
drin. 159€ Bin ich auch ganz heiss drauf :-)

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
<Kanns eigentlichs ein, dass das Forum in letzter Zeit ziemlich viele
<Ausfälle hat??

Bestätigt, manchmal hilft es statt
www.mikrocontroller.net

www.mikrocontroller.net/forum

zu tippern.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bis jetzt musst ich die Variante zum Glück nicht benutzen, aber wenn man
direkt den Link zu dem Thread eingibt bekommt man nur einen Fehler 500
vorgesetzt*g*

Zu Trenz Electronic:

Hab mir den Onlineshop mal angeschaut, die Auswahl is zwar nicht die
Größte, aber die ganzen Module sehen recht nett aus. Jedoch kostet das
Spartan 3E Board über 180€, wenn ich mich nicht täusche. Die 159€ sind
ohne Mehrwertsteuer, die 180€ stehen knapp darunter! Werds mir aber
denk mal trotzdem kaufen^^

Gruß Martin

Autor: T.M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
N ada könnte man ja fast über eine Bestellung direkt aus USA bei Xilinx
/ Digilent nachdenken. Vielleicht kommen ja paar Leute zusammen? Bei
mir scheitert sowas nämlich immer an fehlender Kreditkarte...

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wäre, wenns nich teurer wid, als bei "Trenc Electronics" dabei..
Ist das dann auch das Deutsche Kit oder bekommt man da nur das
Englische?

Mit 16 Jahren ergibt sich bei mir leider das selbe Problem, was die
Kreditkarte angeht*g*

Gruß Martin

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
<N ada könnte man ja fast über eine Bestellung direkt aus USA bei
Xilinx
</ Digilent nachdenken. Vielleicht kommen ja paar Leute zusammen? Bei
<mir scheitert sowas nämlich immer an fehlender Kreditkarte...

Ebenfalls Interesse, bitte starte einen entsprechenden thread im
passenden Forum
(Markt oder Sonstiges  was passt besser?).

Autor: rain (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
servus!

Welche Auflösungsmodi möchtest du denn verwenden.

Ein kleines bzgl benötigten Speicher:

erforderlicher Speicher für 1 Frame = "Anzahl Pixel/Zeile  Zeile 
Bit/Pixel"

Bsp. für Vga auflösung mit nur 16 Farben:

VGA Auflösung mit 16 Farben: 640  480  4 Bit = 1,2 Mbit = 153 kByte
Speicher!!

Rechne das mal hoch, wenn du z.b.: SXGA mit 32Mio Farben betreiben
willst!!


Bzgl. VHDL:

Arbeite dich erst mal ein in die Materie, denn hier läuf vieles anders
als in Programmiersprachen. Man programmiert halt Hardware.


Ansonste noch viel spaß an fpga's

mfg

Autor: Lupin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum baust du die Grafikkarte nicht komplett mit logik ICs so wie du es
mit der CPU vor hast?

Am besten sorgst du auch noch dafür, dass das Teil dann auch PC
kompatibel ist damit windows drauf läuft. Wenn deine Mutti dann aber
nach drei jahren in dein Zimmer kommt und dich unter 'ner Million von
logik ICs begraben findet soll sie sich nicht wundern :P

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
hier wurde zwar schon ne Weile nix mehr geschrieben, aber vielleicht
interessierts ja noch.
Erstmal muss ich sagen, dass ich diese Idee ziemlich gut finde, da ich
vor ca. einem Monat selbst eine Software zum Rendern geschrieben habe,
die durch Bump Mapping usw. leider nur noch auf etwas über 1fps
kommt^^. Das Problem mit einem FPGA anzugehen halte ich für recht
schwierig, obwohl ich schon länger mit FPGA´s arbeite. Die Idee mit
einem ARM das ganze zu lösen halte ich für deutlich besser, nur hat man
hier das gleiche Problem, was man auch bei einem FPGA nur mit großem
Leistungverlust erreichen könnte und das wären Fließkommazahlen, auf
die man bei 3D Programmen meiner Meinung nach nur sehr schwer
verzichten kann. Ein besseres Ergenbis würde man daher bestimmt mit
einem DSP erreichen, oder aber mit einem ARM9 mit FPU, wobei es
deutlich schnellere DSP´s gibt, die auch nicht die Welt kosten. Z.B.
könnte man einem ADSP 21262 mit 200Mhz und FPU nutzen, der bei Digikey
zur Zeit ca. 23€ kostet (kommt da noch Zoll oder ähnliches drauf?).
Wäre für eure Zwecke, da ihr keine Szenenbelichtung usw. als Notwendig
angegeben, vielleicht sogar ausreichend. Aber wie gesagt, es gibt noch
deutlich schnellere DSP´s.
Wäre das nicht eine denkbare Lösung?? Die Bildausgabe usw. könntet ihr
ja immernoch mit einem FPGA regeln, um somit mal was neues kennen zu
lernen, wobei ein DSP glaub ich schon neu genug ist^^.

Gruß Markus

Autor: Lupin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Erstmal muss ich sagen, dass ich diese Idee ziemlich gut finde, da
>ich vor ca. einem Monat selbst eine Software zum Rendern geschrieben
>habe,die durch Bump Mapping usw. leider nur noch auf etwas über 1fps
>kommt^^.

Auf einem AVR? :)

für 3D braucht man keine flieskommaberechnungen. Yeti3D ist zB eine
multiplatform engine die ganz ohne auskommt und sehr schnell ist
(leider gibt es die website davon nicht mehr).

Das problem bei mikrocontrollern ist, dass man die ganze
hardwareansteuerung auch noch machen muss... da wäre eine FPGA Lösung
sinnvoller (also ein prozessor im FPGA und Ansteuerung der Peripherie
wird durch Logik erledigt). Leider gibt es keinen richtig guten und
freien CPU Kern den man in einem FPGA implementieren kann (soweit ich
weiss). Der ARM kern kostet ja ein bischen :)

Autor: Blackfarmer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

hab gerade das komplette Forum durchgelesen und ich kann euch nur
empfehlen, dass wenn ihr wirklich die Grafikkarte realisieren wollt
euch mal intensiv in die Grundlagen der Digitaltechnik einarbeitet!
FPGA besteht halt nur aus viel tausenden von FlipFlops und Logikgatter
die dementsprechend verdrahtet werden. Letztendlich spielt man sich
beim FPGA auf Bitebene und da soll man schon verstanden haben, wie zum
Beispiel Zaehler aufgebaut sind. Es ist kein Problem einzelne Bloecke
in einem FPGA zu integrieren (Memory Controller, Effect Engine,
Schnittstellen, ...) solange man beachtet, dass alles parallel laeuft
und es irgendwie synchroniesieren muss damit alles richtig
funktionert.
Dazu kommt noch logikspezifische Probleme wie zum Beispiel Hazzards,
die gerne mal eine Logikschaltung komplett aus dem Ruder bringen
koennen und unerwartete Fehler verursachen, wo man ewig danach suchen
kann.
Wenn ihr wirklich was komplexes mit einem FPGA oder aehnliches machen
wollt, muesst ihr wirklich verstanden haben, was jede Zeile in eurer
Hardwarebeschreibung (kein Quellcode wie bei C oder asm) macht.
Was bei FPGAs noch zu beachten ist, wenn er zu 19% ausgelastet ist,
dann kann diese Schaltung nicht zu 5 mal im FPGA implementieren, auch
wenn man unter 100% bleibt - es ist sehr schwer ueber 85% noch wirklich
viel sinnvolles zu implementieren. Meistens kann man da nur noch kleine
Aenderungen machen, die dann funktionieren oder nicht.

Will euch jetzt nicht abschrecken! Als kleine Motivation, man kann in
so einem FPGA komplette MPEG de/encoder mit Effektengines realisieren
und das ganze in Echtzeit. Die Teile sind nunmal superschnell und
Leistungsfaehig!

Also Viel Spass beim basteln!

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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.