mikrocontroller.net

Forum: FPGA, VHDL & Co. FPGA - Wie einsteigen?


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


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

von Gerd E. (robberknight)


Bewertung
0 lesenswert
nicht lesenswert
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
von S. R. (svenska)


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

von Carsten (Gast)


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

von Carsten (Gast)


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

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Carsten schrieb:
> Punch Driven Components
> Many-Thread-Umgebungen

-v bitte?

von Carsten (Gast)


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

von Carsten (Gast)


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

von Markus F. (mfro)


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

von Tipp (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe mit einem De0Nano-Board von Altera/Intel angefangen und es 
bisher nicht bereut.
Das was bisher nicht funktionierte lag immer an mir....

von C. A. Rotwang (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Vancouver (Gast)


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

von Frank J. (glorfindel)


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

von S. R. (svenska)


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

von Vancouver (Gast)


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

von Frank K. (fchk)


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

von W.S. (Gast)


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

von Dussel (Gast)


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

von S. R. (svenska)


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

von C. A. Rotwang (Gast)


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

von Vancouver (Gast)


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

von Christoph Z. (christophz)


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

von Frank K. (fchk)


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

von Christoph Z. (christophz)


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

von Alex D (Gast)


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

von Lothar M. (lkmiller) (Moderator) Benutzerseite


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

von Vancouver (Gast)


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

von Lothar M. (lkmiller) (Moderator) Benutzerseite


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


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

von Josef G. (bome) (Gast)


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

von Andreas R. (daybyter)


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

von vancouver (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Josef G. (bome) schrieb:
> Ich hab nie was simuliert. Weiss gar nicht wie das geht.

Sagte der Pilot kurz vor der Bruchlandung.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

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