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
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
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?
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
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/
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
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
@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
Hier gibts die Übersicht über Xilinx-CPLDs und deren Bauformen: http://www.xilinx.com/products/silicon_solutions/fpgas/product_tables.htm#Spartan3 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?
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).
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
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
>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.
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
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
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
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
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
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
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
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
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
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. :)
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
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 ...
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
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
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
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/kurzanleitung/vhdl.pdf 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
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
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.
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
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...
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
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.
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
Bei Trenz Electronic steht das Spartan-3E Starter Kit auch schon im Shop drin. 159 Bin ich auch ganz heiss drauf :-)
<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.
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
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...
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
<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?).
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
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
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
>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 :)
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!
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.