Hallo,
ich wollte mich etwas mehr mit FPGAs beschäftigen und suche dafür ein
einsteiger Entwicklungsboard. Im Studium habe ich bereits mit einem
Spartan 3E gearbeitet aber wir haben immer nur Kleinigkeiten wie LEDs
per PWM ansteuen,.. gemacht.
Ich habe bei eBay ein Entwicklungsboard mit Programmer für 75€ gefunden.
http://www.ebay.de/itm/Xilinx-FPGA-USB-Development-board-Spartan-6-XC6SLX9-Download-Cable-Programmer-/141809459257?hash=item210480a039:g:E5wAAOSw8-tWa7Xp
Reicht das für den Anfang erstmal oder komme ich damit zu schnell an die
Grenzen? Taugt das ganze was? Eine wirkliche Dokumentation mit
Pinbelegung konnte ich nirgendwo finden!
Oder sollte ich lieber in ein teureres Board investieren?
Ein konkretes Projekt habe ich noch nicht, habe aber noch ein Puls
Sensor und andere Sachen, die ich sonst mit einenm µC umgesetzt hätte,
hier rumliegen.
Wäre schön wenn ihr mir da etwas weiterhelfen könntet.
Grundsätzlich ist das erstgenannte Board mit dem Spartan 6 für die
ersten Wochen/Monate geeignet, liegt hier auch rum. Gibts auch etwas
günstiger mit dem Cyclone IV von Altera.
Hab mich aufgrund günstiger FPGA-Boards mit dem Cyclone II u. IV dann
für Altera entschieden. Da hat aber jeder, der das aus Spass an der
Freud' macht seine eigenen Präferenzen.
Danke für die Antworten, ich werde wohl erstmal dieses Board hier
nehmen:
Tobias L. schrieb:> Falls du ein paar Euro mehr ausgeben kannst:> https://shop.trenz-electronic.de/de/26958-Arty-Artix-7-35T-Arty-FPGA-Evaluation-Kit
Auch wenn die anderen zum Teil deutlich günstiger sind, sollte ich mit
der Hardware erstmal ganz gut auskommen ohne erst selber anfagen zu
müssen irgendwelche eigenen Erweiterungsboards zu löten.
Warum kaufen immer alle zunächst Eval-Boards? Das ist meiner Meinung
nach nicht wirklich zielführend um sich mit FPGAs mal zu beschäftigen.
Bei der Arbeit mit FPGAs verbringt man sowieso die meiste Zeit am
Simulator und erst wenn das Design dort komplett läuft, wird es mal auf
der Hardware getestet. Falls es dort dann nicht tun sollte, wird in 95%
der Fälle so lange an der Simulation debugged, bis die Simulation mit
der Realität übereinstimmt. Die tatsächliche Hardware spielt also eine
ziemlich untergeordnete Rolle.
Ich würde daher zum Einstieg empfehlen einen Simulator der Wahl zu
nehmen (GHDL, Modelsim, ...) und einfach mal eine ganze Weile
rumzusimulieren. Und mit ganze Weile meine ich wirklich einige Monate.
Und wenn es dann immernoch Spaß macht, kann man Geld in die Hand nehmen
und ein Eval-Board kaufen. Zumal man dann viel besser in der Lage ist
abzuschätzen, WAS man den machen will und WIE VIEL Logik oder andere
Ressourcen das benötigt. Da muss man dann nicht auf die Erfahrung
anderer beruhen, sondern ist im Stande, das selbst abzuschätzen. Dafür
kann man auch mal mit einem Synthese-Tool rumspielen, die man sich
ebenfalls kostenlos runterladen kann.
> Warum kaufen immer alle zunächst Eval-Boards?
Weil Erfolgserlebnisse, und sei es nur ein Lauflicht oder eine
VGA-Ausgabe, die Motivation ungemein steigern?
mhm schrieb:> Warum kaufen immer alle zunächst Eval-Boards? Das ist meiner Meinung> nach nicht wirklich zielführend um sich mit FPGAs mal zu beschäftigen.> Bei der Arbeit mit FPGAs verbringt man sowieso die meiste Zeit am> Simulator und erst wenn das Design dort komplett läuft, wird es mal auf> der Hardware getestet. Falls es dort dann nicht tun sollte, wird in 95%
Ist so nicht zwingend!
Ich habe viel mit ALTERA gemacht (damals Cyclone II und Cyclone III),
und ich habe den Simulator genau einmal benutzt.
Hinuntergespielt, und dann erst mal 3 Wochen Debugging.
Alle weiteren Projekte habe ich "direkt am Ziel" entwickelt.
Mit Signaltap kann man genauso genau überall hineinkucken wie in der
Simulation.
Aber das "echte" board hatte halt auch alle echten stimuli. Die musste
ich mir nicht erst mal in den Simulator kloppen.
Mag sein, dass das bei größeren FPGA nicht mehr zielführend ist, aber
bei einem mit 8k LEs geht das super. Vor allem wenn man das Projekt
vorher ausmistet, dann geht auch die Synthese schneller.
Deine Arbeitsweise will ich damit aber nicht entwerten, ich kenne sehr
gute FPGA-Entwickler, die auch so arbeiten.
1N 4. schrieb:> Warum kaufen immer alle zunächst Eval-Boards?>> Weil Erfolgserlebnisse, und sei es nur ein Lauflicht oder eine> VGA-Ausgabe, die Motivation ungemein steigern?
Naja, ein Lauflicht oder eine "VGA-Ausgabe" (warum das btw so viele
Leute mit einem FPGA machen ist mir auch schleierhaft, zumal das Projekt
in der Regel beendet ist, wenn simpelste, einfarbige Muster auf dem
Monitor erscheinen) kann man genauso gut in der Simulation betrachten
und sich freuen. Mit dem großen Unterschied, dass das Design eben nicht
in einer "Blackbox" läuft, sondern man sich jedes Signal direkt ansehen
kann und somit viel schneller debugged. Und falls es wirklich blinkende
LEDs zur Motivation benötigt, sollte man sich überlegen, ob man nicht
lieber mit Mikrocontrollern bastelt...
Hurra schrieb:> mhm schrieb:> Warum kaufen immer alle zunächst Eval-Boards? Das ist meiner Meinung> nach nicht wirklich zielführend um sich mit FPGAs mal zu beschäftigen.> Bei der Arbeit mit FPGAs verbringt man sowieso die meiste Zeit am> Simulator und erst wenn das Design dort komplett läuft, wird es mal auf> der Hardware getestet. Falls es dort dann nicht tun sollte, wird in 95%>> Ist so nicht zwingend!>> Ich habe viel mit ALTERA gemacht (damals Cyclone II und Cyclone III),> und ich habe den Simulator genau einmal benutzt.> Hinuntergespielt, und dann erst mal 3 Wochen Debugging.>> Alle weiteren Projekte habe ich "direkt am Ziel" entwickelt.> Mit Signaltap kann man genauso genau überall hineinkucken wie in der> Simulation.>> Aber das "echte" board hatte halt auch alle echten stimuli. Die musste> ich mir nicht erst mal in den Simulator kloppen.>> Mag sein, dass das bei größeren FPGA nicht mehr zielführend ist, aber> bei einem mit 8k LEs geht das super. Vor allem wenn man das Projekt> vorher ausmistet, dann geht auch die Synthese schneller.>> Deine Arbeitsweise will ich damit aber nicht entwerten, ich kenne sehr> gute FPGA-Entwickler, die auch so arbeiten.
Disclaimer: Das folgende ist nicht als Angriff auf deine Arbeit gemeint!
Falls du mit der Arbeitsweise zum Ziel gekommen bist, dann galt meiner
Meinung nach einer oder mehrere der folgenden Punkte:
a) die Projekte waren lächerlich klein
b) du hast deutlich länger gebraucht als mit Simulation
c) du entwickelst beinahe fehlerfrei
Der dritte Punkt ist zwar möglich, aber unrealistisch - jeder macht
Fehler. Wahrscheinlicher sind a und b, womit wir wieder bei dem Punkt
sind, dass eine vernünftige Simulation zwingend notwendig ist, sofern
die Projekte nicht winzig sind (oder der Aufwand, die reale Umgebung in
der Simulation nachzubauen, enorm ist). Und gerade wenn man
professionell arbeitet (oder arbeiten will), dann sind die Projekte
zumeist nicht winzig. Außerdem habe ich die Erfahrung gemacht, dass das
Entwickeln der Simulationsumgebung zumeist recht trivial ist, sofern man
ein wenig nachdenkt. Viele Leute vergessen dabei anscheinend auch, dass
diese Umgebung keinen vollumfänglichen Test des Designs mit
Pass/Fail-Ergebnis können muss! Es reicht, wenn man Inputs des FPGAs
nachbildet und den Rest dann anhand Betrachten der Waveforms
verifiziert.
Zusammengefasst: Auf mich (und viele andere vermutlich auch) wirkt die
Arbeitsweise ohne Simulationsumgebung und mit Debuggen per LogicAnalyzer
direkt im FPGA äußert unprofessionell und sollte vermieden werden.
Deshalb von vorne herein nicht so angewöhnen. Und dazu verleitet das
Vorhandensein eines Eval-Boards eventuell. Deshalb mein Tip, zunächst
keines zu kaufen und sich eine vernünftige Art zu Entwickeln
zurechtlegen (jeder hat da seine eigene Art).
@ mhm (Gast)
>> Warum kaufen immer alle zunächst Eval-Boards?>>> Weil Erfolgserlebnisse, und sei es nur ein Lauflicht oder eine>> VGA-Ausgabe, die Motivation ungemein steigern?
EBEN!
>Naja, ein Lauflicht oder eine "VGA-Ausgabe" (warum das btw so viele>Leute mit einem FPGA machen ist mir auch schleierhaft,
Weil es was "greif" - und SICHTBARES ist.
>zumal das Projekt>in der Regel beendet ist, wenn simpelste, einfarbige Muster auf dem>Monitor erscheinen)
Nö.
>kann man genauso gut in der Simulation betrachten>und sich freuen.
Nö, Simulation ist abstrakt und trocken. Allein ein nicht
funktionierender VGA-Generator, welche bunte Muster erzeugt ist deutlich
induitiver als eine ebensolche nicht funktionierende Simulation.
Auch FPGA-INteressierte sind im Normalfall emotional befähigte Menschen
und keine abstrakten Logiker.
>Mit dem großen Unterschied, dass das Design eben nicht>in einer "Blackbox" läuft, sondern man sich jedes Signal direkt ansehen>kann und somit viel schneller debugged.
Stimmt, hat aber mit dem Erfolgserlebnis nix zu tun.
>Und falls es wirklich blinkende>LEDs zur Motivation benötigt, sollte man sich überlegen, ob man nicht>lieber mit Mikrocontrollern bastelt...>> Ich habe viel mit ALTERA gemacht (damals Cyclone II und Cyclone III),>> und ich habe den Simulator genau einmal benutzt.>> Hinuntergespielt, und dann erst mal 3 Wochen Debugging.
Aua.
>> Alle weiteren Projekte habe ich "direkt am Ziel" entwickelt.>> Mit Signaltap kann man genauso genau überall hineinkucken wie in der>> Simulation.
Nö. Das ist auch unprofessionell.
>> Aber das "echte" board hatte halt auch alle echten stimuli. Die musste>> ich mir nicht erst mal in den Simulator kloppen.
Mag sein und in einigen, wenigen Fällen vielleicht auch die bessere
Lösung. Allgemein aber eher nicht.
>> Mag sein, dass das bei größeren FPGA nicht mehr zielführend ist, aber
Eben.
>> bei einem mit 8k LEs geht das super. Vor allem wenn man das Projekt>> vorher ausmistet, dann geht auch die Synthese schneller.
Unwesentlich. Das ist im Prinzip wie bei den Stufen in der Entwicklung.
IN jeder Stufe wird die Fehler suche und Beseitigung um Faktor 10
teurer.
Konzept, Implementierung, Inbetriebnahme, Produktion
>> Deine Arbeitsweise will ich damit aber nicht entwerten, ich kenne sehr>> gute FPGA-Entwickler, die auch so arbeiten.
Jaja, auch Profis sind nur allzu oft bezahlte Frickler.
>Disclaimer: Das folgende ist nicht als Angriff auf deine Arbeit gemeint!
Warum so bescheiden, ode vielmehr so empfindlich? Kannst du keine
Gegenposition beziehen? Harmoniesüchtig?
>Falls du mit der Arbeitsweise zum Ziel gekommen bist, dann galt meiner>Meinung nach einer oder mehrere der folgenden Punkte:>a) die Projekte waren lächerlich klein>b) du hast deutlich länger gebraucht als mit Simulation>c) du entwickelst beinahe fehlerfrei
Genau.
>Der dritte Punkt ist zwar möglich, aber unrealistisch - jeder macht
Eben.
>Fehler. Wahrscheinlicher sind a und b, womit wir wieder bei dem Punkt>sind, dass eine vernünftige Simulation zwingend notwendig ist, sofern>die Projekte nicht winzig sind (oder der Aufwand, die reale Umgebung in>der Simulation nachzubauen, enorm ist). Und gerade wenn man>professionell arbeitet (oder arbeiten will), dann sind die Projekte>zumeist nicht winzig. Außerdem habe ich die Erfahrung gemacht, dass das>Entwickeln der Simulationsumgebung zumeist recht trivial ist, sofern man>ein wenig nachdenkt. Viele Leute vergessen dabei anscheinend auch, dass>diese Umgebung keinen vollumfänglichen Test des Designs mit>Pass/Fail-Ergebnis können muss! Es reicht, wenn man Inputs des FPGAs>nachbildet und den Rest dann anhand Betrachten der Waveforms>verifiziert.
Eben. In den seltesten Fällen braucht man eine 100% automatisch
auswertbare Testbench. Schon gar nicht beim FPGA.
Bei ASICs ist das ne andere Geschichte, dort MUSS man auf Teufel komm
raus jeden Mist, vor allem mögliche Fehlerszenarien simulieren.
>Zusammengefasst: Auf mich (und viele andere vermutlich auch) wirkt die>Arbeitsweise ohne Simulationsumgebung und mit Debuggen per LogicAnalyzer>direkt im FPGA äußert unprofessionell und sollte vermieden werden.
Sie ist es auch. Frickelei von Leuten, die einfach in ihrer
"Entwickler-Pupertät" stehen geblieben sind. Wir waren ja alle mal so
;-)
>Deshalb von vorne herein nicht so angewöhnen. Und dazu verleitet das>Vorhandensein eines Eval-Boards eventuell. Deshalb mein Tip, zunächst>keines zu kaufen und sich eine vernünftige Art zu Entwickeln>zurechtlegen (jeder hat da seine eigene Art).
Naja, das ist die hohe, abstrakte Schule. Man sollte sich schon ein
Board kaufen, so viel Spaß darf sein.
Da gibt's - wie so oft - die "reine Lehre" wohl nicht.
Wenn ich links ein DDRx-RAM, rechts eine MCU, unten ein PCI-Interface
und oben einen HDMI-Anschluss am FPGA habe (und für alle nur
unvollständige oder auch gar keine Modelle vom Hersteller, die also erst
selber schreiben muß), ist so was wie SignalTap ein Segen.
Die Gefahr, daß man mit einer fehlerhaften Simulationsumgebung (die zu
schreiben ja ebenso fehlerträchtig ist wie die eigentliche Schaltung)
tagelang in die falsche Richtung rennt, ist halt auch groß.
Ich jedenfalls mag es, hin und wieder "am echten Gerät" zu prüfen, ob
alles noch paßt.
@ Markus F. (mfro)
>Da gibt's - wie so oft - die "reine Lehre" wohl nicht.
Darum ghet es gar nicht.
>Die Gefahr, daß man mit einer fehlerhaften Simulationsumgebung (die zu>schreiben ja ebenso fehlerträchtig ist wie die eigentliche Schaltung)>tagelang in die falsche Richtung rennt, ist halt auch groß.
Angstmacherrei.
>Ich jedenfalls mag es, hin und wieder "am echten Gerät" zu prüfen, ob>alles noch paßt.
Das steht doch gar nicht im Widerspruch. Nur darf man nicht dem Irrtum
verfallen, daß man das alles viel besser und schneller mal schnell mit
dem Logicanalyzer hinfummelt.
Erst wenn die Simulation praktisch fehlerfrei läuft, lohnt es sich, das
auch real zu testen und dort dann ggf. Unterschiede zur Simulation zu
finden und zu beheben.
Die parallele Beschreibung direkt im FPGA kann man genauso gut
verfolgen und ausbessern wie bei einem Micro das Programm in der
Hardware.
Das saubere Beschreiben und Programmieren ist wichtig.
Die Simulation verschwendet nur Produktionskosten.
Wer den Fehler in der simulation nicht erkennt , läuft sich zu tode mit
seinem Projekt.
Gruss
peter schrieb:> Das saubere Beschreiben und Programmieren ist wichtig.
Ja, natürlich.
peter schrieb:> Die Simulation verschwendet nur Produktionskosten.
Wenn Du nach jeder Verbesserung mehr als 30' synthetisierst bevor Du auf
der Hardware zu debuggen beginnen kannst, nur um festzustellen, dass die
gewünschten Signale auf dem Analyzer nicht darzustellen sind, weil sie
leider wegsynthetisiert wurden und Du nochmals von vorne beginnst, dann
nenne ich DAS Verschwendung von Entwicklungskosten UND Zeit.
