Forum: FPGA, VHDL & Co. Taugt dieses FPGa Board was?


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 M. (Gast)


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

Ebay-Artikel Nr. 141809459257

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.

von Tobias L. (murxwitz)


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

von Rote T. (tomate)


Bewertung
0 lesenswert
nicht lesenswert
Wenn man das gleiche Board vom Chinesen direkt kauft, kostet es nur halb 
so viel ;)

von Andreas R. (daybyter)


Bewertung
0 lesenswert
nicht lesenswert
Dieses Board hab ich und find es auch nicht schlecht:

Ebay-Artikel Nr. 200942146349

Brauchst noch einen USB Blaster dazu.

von 1N 4. (1n4148)


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

von M. (Gast)


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

von mhm (Gast)


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

von 1N 4. (1n4148)


Bewertung
0 lesenswert
nicht lesenswert
> Warum kaufen immer alle zunächst Eval-Boards?

Weil Erfolgserlebnisse, und sei es nur ein Lauflicht oder eine 
VGA-Ausgabe, die Motivation ungemein steigern?

von Hurra (Gast)


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

von mhm (Gast)


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

von Falk B. (falk)


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

von Markus F. (mfro)


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

von Falk B. (falk)


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

von peter (Gast)


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

von P. K. (pek)


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

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]
  • [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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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