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.
Falls du ein paar Euro mehr ausgeben kannst: https://shop.trenz-electronic.de/de/26958-Arty-Artix-7-35T-Arty-FPGA-Evaluation-Kit aktuelle FPGA-Generation Schnellerer Speicher DDR3 Programmer onboard komplette Lizenz (incl. Microblaze Softcore) und dokumentiert und mit Beispielen: http://store.digilentinc.com/arty-board-artix-7-fpga-development-board-for-makers-and-hobbyists/
Wenn man das gleiche Board vom Chinesen direkt kauft, kostet es nur halb so viel ;)
Dieses Board hab ich und find es auch nicht schlecht: http://www.ebay.com/itm/ALTERA-FPGA-Cyslonell-EP2C5T144-Minimum-System-Learning-Board-Development-Board-/200942146349?hash=item2ec915d32d:g:Zu0AAOxy9tpR-ixN Brauchst noch einen USB Blaster dazu.
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.
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.