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
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.
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.
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...
;-)
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.
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.
