Hallo zusammen, ich möchte furchtbar gerne mal in das Thema FPGA rein schnuppern, aber dafür nicht 100e von Euros ausgeben. Ich habe keine Ahnung von dem Thema, und Google meint so statistisch, Xilinx wäre wohl eine gute Wahl zum Einstieg. Bei eckstein-shop haben ich Waveshare Core3S250E XILINX Spartan-3E XC3S250E FPGA Development Core Board gefunden, für bezahlbare Kosten. Aber was brauche ich da noch? Wenn ich das richtig verstanden habe, sollte ich mich intensiv mit VHDL und/oder Verilog beschäftigen? Kriegt man da erstmal ein kostenloses Toolchain hin? Oder ist das Thema so "pro", dass es gleich was kosten muss, um Erfolge zu erzielen? Falls ja, wo liegen eurer Erfahrung nach die Kosten in etwa? Für Dummie-Links und so bin ich immer dankbar ^-^ Carsten
Schau Dir mal den Icebreaker an, der ist extra zum FPGA-Einstieg gedacht. Gibt viele Tutorials extra für den, das Board ist mit den PMOD-Anschlüssen schön flexibel und Programmier/Debugmäßig ist alles an Bord. Ist halt Lattice und nicht Xilinx, und der FPGA ist eher klein. Das macht aber für den Anfang eigentlich nix aus, Du wirst nicht gleich mit einem riesigen SoC-Design mit mehreren Softprozessorcores, AXI-Bussen und sonstwas starten wollen. Siehe: https://www.crowdsupply.com/1bitsquared/icebreaker-fpga und hier der deutsche Shop: https://1bitsquared.de/products/icebreaker
:
Bearbeitet durch User
Carsten schrieb: > Aber was brauche ich da noch? Du brauchst ein Development-Board und einen Programmer. In meinem Fall ist das ein Spartan6-Board und ein Xilinx DLC9LP(-Klon), die ich günstig vom Aliexpress erstanden habe. Dazu brauchst du dann noch die Toolchain von Xilinx. Für Spartan3 und Spartan6 ist das ISE. Die WebPACK-Edition ist kostenlos und kann für beide Generationen verwendet werden (allerdings m.W. nicht die wirklich dicken FPGAs). Beachte, dass Xilinx ISE 14.7 (die letzte Version, ISE wird nicht weiterentwickelt) nicht direkt unter Windows 10 funktioniert. Es gibt zwar eine Windows 10-kompatible Version, aber die unterstützt keine Spartan3 mehr. Du wirst also etwas basteln müssen, wenn du Windows 10 hast, aber es geht. Für Linux gibt es nur eine Version, dafür muss man dann an anderen Stellen basteln. Carsten schrieb: > Wenn ich das richtig verstanden habe, sollte ich mich > intensiv mit VHDL und/oder Verilog beschäftigen? Wie intensiv du das machst, ist deine Sache. :-) Carsten schrieb: > Falls ja, wo liegen eurer Erfahrung nach > die Kosten in etwa? Man kommt mit den kostenlosen Editionen inzwischen schon recht weit. Ich hatte mal einen Xilinx Zynq 7020 in den Fingern (schon ziemlich groß, mit Dualcore ARM9-Prozessoren) und das ging auch mit der kostenlosen Toolchain (für die 7er-Generation ist das Vivado).
Gerd E. schrieb: > Du wirst nicht gleich mit > einem riesigen SoC-Design mit mehreren Softprozessorcores, AXI-Bussen > und sonstwas starten wollen. Sicher nicht, Gerd, weil ich nichtmal weiß, was AXI-Busse sind ^^ Danke für deinen Tipp, und jetzt gurgel ich mal nach AXI-Bussen :)
Carsten schrieb: > jetzt gurgel ich mal nach AXI-Bussen Okay, AXI-Busse sind geil... ^^ An so was in der Art bastele ich schon eine Weile in Software in Sachen Punch Driven Components in Many-Thread-Umgebungen auf größeren µCs. Allein das ist ja schon ein Thema für viele lange Abende.
S. R. schrieb: > -v bitte? Sorry, teilweise meine eigene Namensgebung. Zur Erklärung: Es gibt Framework-Beschreibungen etwa von Ralf Westphal, die sich mit ereignisbasierter Programmierung beschäftigen. In nicht-Real-Time-Umgebungen wie Windows oder Standard-*Uxen werden Ereignisse aber wie Stiefkinder behandelt. "Ein Ereignis ist eingetroffen? Okay, ich kümmere mich darum, wenn ich Lust dazu habe." Das ist, wie wenn ein Smombie auf der Straße angesprochen wird. Drei Sekunden später: "Hä?" Darum nenne ich es in Echtzeit-Umgebungen "Punch", weil auf einen Punch reagierst du garantiert sofort. Und mit Many-Thread-Umgebung will ich aussagen, dass viele viele viele Threads die Kerne belästigen, etwa beim RasPi den pigpiod, wenn viel Interaktion mit der realen Welt passiert. Oder im Automotive-Bereich oder oder oder. Bau und code dir mal ein Oszilloskop, das auf Trigger reagiert mit sagen wir mal 16 Kanälen. Das sind many threads! ;)
@svenska: Vielen Dank auch dir für deine ausgiebige Antwort :) Ich bin halt wegen der Marktanteile auf Xilinx gekommen, aber das muss ja nichts heißen. Klingt aber gut gut, was du schreibst. Ich will einfach klein anfangen, aber am besten mit einem Stück Hardware, das Potenzial hat, von sich aus und zur Motivation. Den Weltbeherrschungs-FPGA-i-nator baue ich dann in der nächsten Iteration ^^
Carsten schrieb: > aber > dafür nicht 100e von Euros ausgeben. Wenn Du günstig einsteigen willst, nimm' ein 15€ Board bei eBay 222882868419 (z.B.). Die Dinger sind zwar schon etwas älter und nicht der letzte Schrei, kommen aus China (warten ist also angesagt), aber günstiger kommst Du nicht zu einem FPGA Lernobjekt. Altera Quartus II 13.0 ist kostenlos bei Intel runterzuladen.
Ich habe mit einem De0Nano-Board von Altera/Intel angefangen und es bisher nicht bereut. Das was bisher nicht funktionierte lag immer an mir....
Hier im Forum ist mal ausführlich das MAX1000 besprochen worden, das ist für Dich genau richtig: https://shop.trenz-electronic.de/de/TEI0001-03-08-C8-MAX1000-IoT-Maker-Board-8KLE-8-MByte-RAM?c=455 Beitrag "MAX1000 Erfahrungen" Beitrag "Pinübersicht max1000" Beitrag "FPGA IoT Maker Board" Beitrag "MAX1000 allererste Schritte" Beitrag "MAX1000 SDRAM" Beitrag "Quartus findet Programmer nicht mehr auf MAX1000"
Carsten schrieb: > Wenn ich das richtig verstanden habe, sollte ich mich intensiv mit VHDL > und/oder Verilog beschäftigen? Ja. Genau genommen ist das die große Hürde beim Einstieg, besonders wenn Du keinen Background in Digitalhardware hast. Ich würde erstmal Gehversuche mit einer HDL Deiner Wahl und einem OpenSource-Simulator machen, z.B. GHDL für VHDL oder Icarus oder Verilator für (System)Verilog. Du kannst dir zwar jetzt ein Board kaufen, aber bis du damit etwas Sinnvolles machen kannst außer die mitgelieferten Demos mit blinkenden LEDs laufen zu lassen, vergeht ein bisschen Zeit. Solange liegt das Teil in der Ecke und vertaubt. Du wirst ohnehin viel mehr Zeit mit Simulationen verbingen als mit der eigentlichen FPGA-Hardware. Gerade Anfänger fabrizieren mit VHDL oftmals haarsträubenden Unsinn, der auf keinem FPGA funktionierent. Bevor jetzt wieder irgend jemand beleidigt ist: bei mir war es genauso. Man muss erstmal die Programmiererdenke aus dem Kopf bekommen, dann läuft's irgendwann.
Moinsen, schau Dir doch mal das Trenz-Board an. Die haben eine prima Wiki-Seite, du kannst für Lau die Xilinx Tools verwenden ... ich fand es zum Einstieg sehr gut. Hat den Formfaktor eines RaspBerry. http://shop.trenz-electronic.de/de/TE0726-03M-ZynqBerry-Modul-mit-Xilinx-Zynq-7010-in-Raspberry-Pi-Formfaktor?showb2c=1&gclid=EAIaIQobChMInJj-2L2U6AIVBrDtCh3AcQgdEAQYAiABEgJb0PD_BwE Glück Auf!
Vancouver schrieb: > Gerade Anfänger fabrizieren mit VHDL oftmals > haarsträubenden Unsinn, der auf keinem FPGA funktionierent. Genau deswegen ist ein reales FPGA-Board sinnvoll, denn damit kann man verifizieren, wenn man die Simulation nicht versteht.
S. R. schrieb: > Genau deswegen ist ein reales FPGA-Board sinnvoll, denn damit kann man > verifizieren, wenn man die Simulation nicht versteht. Das meinst du jetzt aber ironisch, oder? Das ist so, als würde man ein Haus einfach mal drauflos bauen, weil man die Berechnung der Statik nicht versteht. Wenn es zusammenkracht, dann sieht man ja gleich, was man falsch gemacht hat, also sch**ß auf die Statik.
Carsten schrieb: > ich möchte furchtbar gerne mal in das Thema FPGA rein schnuppern, aber > dafür nicht 100e von Euros ausgeben. Ich habe keine Ahnung von dem > Thema, und Google meint so statistisch, Xilinx wäre wohl eine gute Wahl > zum Einstieg. Bei eckstein-shop haben ich Waveshare Core3S250E XILINX > Spartan-3E XC3S250E FPGA Development Core Board gefunden, für bezahlbare > Kosten. Aber was brauche ich da noch? Der kleinste und einfachste Baustein ist ein Xilinx 9536. Gibts in verschiedenen Ausführungen, sowohl für 5V als auch 3.3V. PLCC-Gehäuse, geht mit passendem Sockel auf eine Lochraster-Platine. Dazu ein DLC9-Clone vom Chinamann und ein alte ISE Version (ISE 13). VOn diesem Baustein gibts auch größere Versionen - 9572 und 95144. Andere Alternative: Lattice MachXO oder MachXO2. Davon gibt es Versionen mit eingebautem LDO, d.h. Du brauchst nur 3.3V, und das wars. Keinen externen Speicher, keine drei Versorgungsspannungen wie bei Spartan 3, von hand lötbares TQFP100 Gehäuse, und die Chips fangen bei etwa 2.30€ bei Digikey an. Programmieren kannst Du die Dinger mit einem beiliebigen FTDI FT2232 Breakout-Board. Die Software ist zwar nicht frei, aber kostenlos. Damit kommst Du dann schon richtig weit. VHDL musst Du natürlich können, aber auch da gibts alles Mögliche an Büchern und Tutorials. fchk
Frank K. schrieb: > Andere Alternative: Lattice MachXO oder MachXO2. Naja, wenn's denn unbedingt sowas sein soll. Farnell weist den mickrigsten den sie haben (LCMXO256C-3TN100I) zu Netto 3.19€ aus - und das Ding hat mal bloß 256 LUT's. Carsten schrieb: > ich möchte furchtbar gerne mal in das Thema FPGA rein schnuppern, aber > dafür nicht 100e von Euros ausgeben. Ich habe keine Ahnung von dem > Thema,... Nun, das ist keine guter Zustand. Was genau stellst du dir denn eigentlich vor? Nur ein bissel in Verilog oder VHDL herumdaddeln? Oder kannst du dir irgend ein konkretes Vorhaben vorstellen? Normalerweise geht man ja so vor, daß man ein Vorhaben hat und dazu prüft, ob und wie man Teile davon per CPLD oder FPGA machen kann. Das ist ein Unterschied, denn CPLD's funktionieren sofort, FPGA's müssen erst noch gebootet werden. Einige wenige haben den "Boot"-Speicher im Gehäuse mit drin, die meisten brauchen aber einen externen Speicher dafür. Nach meiner Ansicht ist reines Trockenschwimmen mit einem FPGA auf einem Evalboard schon bald recht langweilig. Interessanter und lehrreicher wird es, wenn man ein echtes Projekt durchzieht. Und bedenke, daß du mit kleinen FPGA's, die nur 256 LUT's drin haben, nicht wirklich viel machen kannst. W.S.
Vancouver schrieb: > Du wirst ohnehin viel mehr Zeit mit Simulationen verbingen als mit der > eigentlichen FPGA-Hardware. Wenn man nicht vom Vorgänger Timingprobleme irgendwo im Projekt geerbt hat… Ich persönlich würde eher Intel als Xilinx benutzen. Die sind beide weit verbreitet, aber Quartus funktioniert meiner Erfahrung nach besser. Das ist übersichtlicher, stabiler und besser organisiert. Vivado kann das zwar natürlich auch alles, aber meiner Erfahrung nach eher irgendwie.
Vancouver schrieb: >> Genau deswegen ist ein reales FPGA-Board sinnvoll, denn damit kann man >> verifizieren, wenn man die Simulation nicht versteht. > > Das meinst du jetzt aber ironisch, oder? Das ist so, als würde man ein > Haus einfach mal drauflos bauen, weil man die Berechnung der Statik > nicht versteht. Wenn es zusammenkracht, dann sieht man ja gleich, was > man falsch gemacht hat, also sch**ß auf die Statik. Richtig. Und als Lernerfahrung ist das auch nützlich. Es gibt einen Unterschied zwischen "ich bau jetzt aus Lego mal das auf, von dem ich glaube, dass es halten sollte" und "ich bin in China und baue mal ein sechsstöckiges Hotel". Es gibt hier im Forum oft genug die Aussage "wenn du das so machst, dann stimmen Simulation und Synthese nicht überein". Also ist die Simulation nicht das Allheilmittel, vor allem wenn man keine Ahnung hat.
Vancouver schrieb: > S. R. schrieb: >> Genau deswegen ist ein reales FPGA-Board sinnvoll, denn damit kann man >> verifizieren, wenn man die Simulation nicht versteht. > > Das meinst du jetzt aber ironisch, oder? Das ist so, als würde man ein > Haus einfach mal drauflos bauen, weil man die Berechnung der Statik > nicht versteht. Wenn es zusammenkracht, dann sieht man ja gleich, was > man falsch gemacht hat, also sch**ß auf die Statik. ??? Also IMHO ist das mit dem realen Board keinesfalls Ironie. Auch beim Häuserbau kann man sehr wohl statisch einwandfreie Wohnquader konstruieren die schwer realisierbar oder praktisch unbewohnbar sind. Bei der FPGA-Entwicklung wären das Designs die schwer verifizier-/testbar sind und die Probleme, die nicht unbedingt im HDL-Code 'lauern' sondern im FPGA-Architektur Frontend wie beispielsweise Pinning-Assignments, IO-Constraints, etc. pp.. Gerade Testbarkeit an realer Hardware war lange Zeit das Argument für Altera/intel, da dort der 'eingebaute Logiganalyzer' bereits in der kostenlosen Variante verfügbar ist, während bei Xilinx für Chipscope eine Lizenz erforderlich ist. Und schon eine einfache Blink-LED erleichtert das debugging ungemein, weil damit auf den ersten Blick klar wird, ob die komplette toolchain und die 'FPGA-Grundversorgung' (wie Takt, Power On Reset) überhaupt tut.
C. A. Rotwang schrieb: > Bei der FPGA-Entwicklung wären das Designs die schwer > verifizier-/testbar sind und die Probleme, die nicht unbedingt im > HDL-Code 'lauern' sondern im FPGA-Architektur Frontend Bevor ein Design auf der realen Hardware getestet wird, sollte es im Simulator mindestens zu 90% verifiziert sein. Wenn es schon rein funktional noch Unsicherheiten gibt, kannst du dir später auf dem FPGA einen Wolf debuggen, weil du nicht weißt, ob der Fehler im Sourcecode steckt oder vom Timing/Pinmapping/falscher Resetpolarität verursacht wird. Wo fängst du dann an zu suchen? Und siehe da, es stellt sich raus, die meisten Fehler dieser Art wären bei einer gründlicheren funktionalen Simulation gar nicht erst aufgepoppt. Zu meiner Schande muss ich gestehen, dass mir das auch heute noch hin und wieder passiert. Als Anfänger steht man dann wie ein Ochs vorm Berg. Und bevor man sich dann gleich am Anfang in einen ILA-Core einarbeiten muss, wäre es doch sinnvoller, sich mal intensiv mit der Simulation zu beschäftigen. Der Simulator kann bis aufs letzte Bit zeigen, was abläuft, im FPGA ist das nur noch mühevoll und mit vielen vielen Bitfiles möglich. Wenn man einen LA braucht, um funktionale Bugs im Design aufzudecken, hat man in den meisten Fällen schon einen entscheidenden Fehler gemacht. Schmankerl am Rande: Vor einiger Zeit hattem wir ein Projekt mit einem Kunden, der genau so vorgegangen ist: Simulation von FPGA-Designs ist Zeitverschwendung. Wenns nicht klappt, debuggen wir es mit mit dem ILA und machen dann ein neuens Design. Ein Softwareprogramm testet man schließlich auch direkt auf dem Controller und nicht erst im Simulator. Und bei diesem Projekt ging es um Videokompression auf einem Virtex-7 mit knackigen Timingsonstraints, also kein Kinderkram, Durchlaufzeit im Vivado jedesmal über vier Stunden, und meistens nur, weil man ein anderes Signal tracen wollte. Es war ein einziges Desaster. Ich empfehle jedem Anfänger, sich erstmal auf das HDL-Design und die funktionale Simulation zu beschränken. An Anfang kennen die meisten ja nicht einmal den Unterschied zwischen synthetisierbarem und Verifikationscode. Da werden dann fröhlich Testbenches mit GHz-Clockgeneratoren und File-IO synthetisiert. Und blöderweise läuft das Design dann nicht auf dem FPGA, obwohl man es 1:1 vom C-Code in VHDL übersetzt hat, und auf dem Microcontroller läuft es doch auch. Schließlich verliert man die Lust und das Teil liegt in der Ecke. Schade, schade.
Vancouver schrieb: > Ich empfehle jedem Anfänger, sich erstmal auf das HDL-Design und die > funktionale Simulation zu beschränken. An Anfang kennen die meisten ja > nicht einmal den Unterschied zwischen synthetisierbarem und > Verifikationscode. Da werden dann fröhlich Testbenches mit > GHz-Clockgeneratoren und File-IO synthetisiert. Ich sehe deinen Punkt und wir alle hier sind uns einig, dass Simulation nicht nur wichtig ist, sondern essentiell und schon zu beginn ausprobiert und geübt werden muss. Interessant finde ich am zitierten Abschnitt, dass du selber das Problem beschreibst, wenn Anfänger zu spät den eigenen Code synthetisieren wollen. Natürlich lässt sich ein Design synthetisieren, ohne dass ein Board auf dem Tisch liegt, aber das macht doch einfach keinen Spass :-) (Sinnvoll ist es natürlich trotzdem z. B. nach einer erfolgreichen Simulation auch noch eine Synthese zu machen, bevor der Code eingecheckt wird. Been there - done that, Simulation war gut und trotzdem broken code eingechecked). Also: In kurzen Zyklen jeweils Design machen, Test schreiben, Simulieren bis läuft, Synthetisieren und sich dann freuen, dass es auf der Hardwäre läuft. PS: Dabei fällt mir gerade auf, dass dies ja genau den Agile Ansatz beschreibt. Gilt Agile darum nun als didaktisch Wertvoll? ;-)
W.S. schrieb: > Und bedenke, daß du mit kleinen FPGA's, die nur 256 LUT's drin haben, > nicht wirklich viel machen kannst. Das würde ich jetzt nicht so gering schätzen. Ich würde mir gerne die Dinger im TQFP-48 wünschen, so als Nachfolger der isp-lsi. Um etwas diskrete Logik zusammenzufassen, sind diese Teile ideal, und das ist auch der Zielmarkt dafür. Natürlich bekommst Du da keinen Prozessor hineinsynthetisiert, aber ich persönlich brauche das auch nicht. Und wenn, dann gibts dafür die passenden Zielobjekte, die dann aber auch gleich einen viel größeren Aufwand bedeuten. Und für den Einstieg finde ich diese DInger auch nicht so verkehrt. fchk
Frank K. schrieb: > Das würde ich jetzt nicht so gering schätzen. Ich würde mir gerne die > Dinger im TQFP-48 wünschen, so als Nachfolger der isp-lsi. Um etwas > diskrete Logik zusammenzufassen, sind diese Teile ideal, und das ist > auch der Zielmarkt dafür. Die ispMACH 4000 gibt es in TQFP-48. Die ice40 FPGAs gibt es auch in Varianten mit wenig Anschlüssen aber die sind nicht mehr von Handlötbar (uBGA 0.4 mm Raster...)
Christoph Z. schrieb: > Die ispMACH 4000 gibt es in TQFP-48. Die ice40 FPGAs gibt es auch in > Varianten mit wenig Anschlüssen aber die sind nicht mehr von Handlötbar > (uBGA 0.4 mm Raster...) Bei den ice40 gibts den kleinsten (384LUTs, keine PLL) auch im QFN32 Gehäuse
Christoph Z. schrieb: > Also: In kurzen Zyklen jeweils Design machen, Test schreiben, Simulieren > bis läuft, Synthetisieren und sich dann freuen, dass es auf der Hardwäre > läuft. Und dann an den kleinen Schritten und vor Allem(!) anfänglich auch kleinen "Projekten" die Grundlagen und die verschiedensten Winkel und die Möglichkeiten des FPGAs kennenlernen. Das so oft beobachtete Vorgehen "ich baue einen Prozessor mit über DMA angekoppeltem Display samt sonstiger Peripherie" scheitert so garantiert, wie am Morgen die Sonne aufgeht. Also mit einfachen Sachen anfangen: LED-Blinker, LED-Lauflicht (in verschiedesten Varianten mit Multiplexer, Schieberegister, RAM, ...), dann eine serielle Schnittstelle, dann die Anseuerung eines VGA-Monitors, darauf dann Pingpong spielen, dann ein LCD-Textdisplay ansteuern, dann ruhig mal eine Ampel oder einen Kaffeeautomaten mit Rückgeld, und, und, und... Und dann, ein paar Monate später, hat man einen gewissen Fundus an "Beispielen", von denen man weiß, dass sie funktionieren. Und man hat halbwegs fundiertes Grundlagenwissen aufgebaut anhand von Sachen, die z.B. wie die serielle Schnittstelle ind Datenbüchern von Mikrocontrollern ausführlich beschrieben sind. Natürlich muss man diese Komponenten auch tatsächlich verstanden haben. Denn was ich nicht verstanden habe, das kann ich nicht "beschreiben". Und VHDL ist eben eine "Beschreibungssprache". > Also: In kurzen Zyklen jeweils Design machen, Test schreiben, Simulieren > bis läuft, Synthetisieren und sich dann ... immer wieder mal den RTL-Schaltplan und das Syntheseergebis genauer anschauen, um zu kontrollieren, ob das Design annähernd so viele Ressourcen (vorrangig Flipflops) braucht, wie man selbst erwartet, dass dafür nötig sind. Wenn man z.B. irgendwas mit einem 16 Bit-Zähler und einer FSM mit 16 Zuständen baut, dann darf dieses Design nicht weniger und auch nicht arg viel mehr als 20 Flipflops verbrauchen. Sonst könnte es sein, dass der Synthesizer die verfasste VHDL-Beschreibung nicht richtig "verstanden" hat.
Christoph Z. schrieb: > Interessant finde ich am zitierten Abschnitt, dass du selber das Problem > beschreibst, wenn Anfänger zu spät den eigenen Code synthetisieren > wollen. Es ist glaube ich kein guter Ansatz, sich vom Synthesetool sagen zu lassen, ob der eigene Code synthesefähig ist. Dass man eine File-IO oder after-Statements synthetisieren kann, sollte schon lange klar sein, bevor man die Synthese anwirft. Es geht bei einem Anfänger darum, dass er den grundsätzlichen Aufbau eines FPGA-Designs versteht. Wie baut man Register, Zähler, Statemachines, arithmtische Pipelines usw, das ganze Handwerkszeug. Da macht man am Anfang sehr viele Fehler und ich meine, das Ausprobieren auf dem FPGA hilft da nicht wirklich weiter. Das Ergebnis wird sein, dass der FPGA nichts oder das Falsche macht, und man hat keine Ahnung, warum. In der Simulation sieht man den Fehler hingegen, wenn man weiß, wo man suchen muss. Als ich noch Vorlesungen betreut habe, haben unsere Studenten das ganze Semester über eine Übung nach der anderen auf dem Simulator gemacht. Am Ende kannten sie ganz genau den Unterschied zwischen Testbench, DUT und Verification IP. Erst dann kam das Praktikum auf der Hardware. Das ist der weitaus bessere Weg, als eine Horde Ahnungsloser ins Labor zu lassen... > Natürlich lässt sich ein Design synthetisieren, ohne dass ein Board auf > dem Tisch liegt, aber das macht doch einfach keinen Spass :-) Ja, da hast du wohl recht :-) Wenn das Teil da liegt, dann kitzelt es in den Fingern. Aber das verleitet halt auch schnell zum eine ziellosen Trial-and-Error-Vorgehen. Die meisten FPGA-Designer, die ich kenne (einschließlich mir selbst) arbeiten bei einem neuen Design anfangs nur am Simulator, meistens für ziemlich lange Zeit, um sich endlose Debugging-Sessions im Labor zu ersparen. Wenn das Design zum ersten mal auf der realen Hardware läuft, ist typsicherweise schon 90% der Arbeit gemacht. Natürlich treten irgendwann immer Probleme auf, die man im Simulator nicht nachbilden kann, und dann muss doch der LA ran. Aber das sollte der letzte Schritt sein. Aber nun ja, ich will niemanden davon abhalten, sich gleich am Anfang ein Evalboard zu kaufen. Es führt halt nur häufig zu Enttäuschungen, wenn dann anfangs so garnichts funktionieren will und man mehr Zeit mit Experimenten an der Toolchain verbringt als mit der systematischen Fehlersuche im Design.
Vancouver schrieb: > Aber nun ja, ich will niemanden davon abhalten, sich gleich am Anfang > ein Evalboard zu kaufen. Ich würde aber ein Board mit wenig Klimbim empfehlen. Denn sonst braucht der Code zum Abschalten des Klimbims in der Beschreibung zehnmal soviel Platz wie das, was man eigentlich machen will. Dann verliert man ratzfatz den Überblick. Und wenn man das Abschalten der Komponenten nicht macht, dann kann es bei manchen Boards passieren, dass mehrere IC-Ausgänge gleichzeitig auf die selbe Leitung treiben und das Teil auf die Dauer kaputtgeht. Vancouver schrieb: > Als ich noch Vorlesungen betreut habe, haben unsere Studenten das ganze > Semester über eine Übung nach der anderen auf dem Simulator gemacht. Das wäre mir zu trist und es geht eben nur, wenn man fachliche Betreuung hat, die einen zeitnah wieder einjustiert, wenn man sich verlaufen hat. Zum selber Lernen muss man eine blinkende LED simulieren und dann auf der realen Hardware sehen. Man muss ein Lauflicht simulieren und es dann auch gleich laufen sehen. Denn dann habe ich noch Zeit, zu erkennen, ob ich zwar tadellos simulierbaren Code wie z.B. "LED <= not LED after 500 ms;" schreibe, den aber derzeit kein Synthesizer in Hardware abgebildet bekommt. Ich wollte zu meinem vorigen Post noch Beispiele zur Ampel und zum Kaffeeautomaten zeigen, habs aber verdingbimselt. Hier jetzt der Link zum Beitrag "Ampelsteuerung" mit Links zum Thema... ;-)
:
Bearbeitet durch Moderator
Frank K. schrieb: > Das würde ich jetzt nicht so gering schätzen. Naja..naja. Ich hatte mal mit nem XC95144XL + RAM eine komplette Ansteuerung für TFT's gemacht, von 480x272 bis 640x480 und hatte noch eine Ahandvoll MC's übrig. Ein werter Kollege wollte das mit einem FPGA von Altera aus der 3000 LUT Riege nachvollziehen und ist damit gescheitert.. allerdings schätze ich, daß das nicht am FPGA lag. Dennoch: bei den CPLD'S haben die OR-Gatter vor den FF mit ihren riesigen AND-Gattern davor schon eine Menge Funktionalität, die ich mal als Äquivalent für die 8 fache Menge LUT's einschätze. Das ergäbe so etwa mal ganz grob geschätzt, daß ein FPGA mit 256 LUT einem FGA mit 32 MC entsprechen würde. Mal abgesehen davon, daß der TO sich nicht wieder gemeldet hat. Ansonsten könnten wir nämlich etwas mehr über seine Beweggründe etc. wissen. Ich vermute mal, der TO hat noch nie einen programmierbaren Logikchip in der Hand gehabt, will aber dieses Gebiet der Elektronik nicht igenorieren und hat als einziges das Wort "FPGA" als zeitgemäß im INet gelesen. Wenn diese Vermutuung stimmt, würde ich ihm anraten, zu allererst das Verwenden von CPLD's zu üben. Das ist noch sehr überschaubar und man kann als allererstes mal nen kleinen Frequenzzähler als einfaches Anfangs-Objekt damit bauen. So ein FPGA mit 144 Makrozellen würde völlig ausreichen. Und die Dinger sind heuer billig bei Ali zu kriegen, brauchen außer Vcc eigentlich garnix drumherum, brauchen nicht zu booten und sind auch per jtag leicht zu brennen. Und: man kann damit alles das üben, was man später für FPGA's benötigen würde - wenn einem nach dem Hereinschnuppern dieses Gebiet zusagt. Und wenn's nix ist für den TO, dann ist der gehabte Aufwand so etwa zu 30 Euro anzusetzen: je 10 Euro für nen China-Xilinx-Brenner, ne Handvoll Leiterplatten und ne Handvoll Chips. W.S.
Christoph Z. schrieb: > Ich sehe deinen Punkt und wir alle hier sind uns einig, dass > Simulation nicht nur wichtig ist, sondern essentiell und > schon zu beginn ausprobiert und geübt werden muss. Ich hab nie was simuliert. Weiss gar nicht wie das geht.
Wir haben einen Thread zu den mini dev Boards im forum64 gemacht. Damit kann man vga out, eine cpu und vieles mehr bauen. Und für 15,- kann man nicht viel falsch machen.
Josef G. (bome) schrieb: > Ich hab nie was simuliert. Weiss gar nicht wie das geht. Sagte der Pilot kurz vor der Bruchlandung.
Wenn man heute anfängt mit FPGAs, sollten man gleich einen aktuellen FPGA nehmen, welcher auch noch länger supportet wird. Also kein Spartan3 oder Spartan6...alles veraltet. Der Ice von Lattice ist eher ein Exote, nicht verbreitet in der Industrie und etwas ausgefallene Programmierumgebung. Aktuell ist zum Beispiel MAX10 von Intel und der perfekte Einstieg. Mit dem MAX1000 Board bekommst du viele Beispiele, hast den Programmier/Debugger gleich mit auf dem Board. Für 22€ verdammt günstig. Damti wirst du bestimmt glücklich. :-)
Christian schrieb: > Also kein Spartan3 oder Spartan6...alles veraltet. Der Ice von Lattice > ist eher ein Exote, nicht verbreitet in der Industrie und etwas > ausgefallene Programmierumgebung. Nonsense. Der ICE40 ist millionenfach in Handies verbaut. Ueber ICEcube kann man sich streiten, ok. Ansonsten: yosys-Support tut prima. Und der Spartan6 ist mitnichten veraltet. Auch der wird noch in grossen Stückzahlen verbaut, und das noch vermutlich min. 15 Jahre. Und einem Einsteiger Quartus empfehlen? Im Ernst jetzt?
Fitzebutze schrieb: > Und einem Einsteiger Quartus empfehlen? Im Ernst jetzt? Bei diesem Beitrag von Christian und dem ähnlichen Beitrag von Martin in einem anderen Thread handelt es sich um versteckte Werbung für den MAX1000. Alle paar Wochen werden alte Threads hervorgeholt und das MAX1000 empfohlen, wenn es auch nur im entferntesten zum Thema des Threads passt. Mich würde schon mal interessieren wer da dahintersteckt. Da das immer am Wochenende geschieht, wird es wohl nicht eine offizielle Werbemassnahme von Arrow oder Trenz sein.
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.