Hallo Leute, ich will mich in das Gebiet FPGA einarbeiten. Da ich leider absoluter Neuling bin, wollte ich erst einmal fragen, was ich an Vorkentnisse benötige? Weiterhin schrecken viele vor FPGA ab, warum eig.? Vielen Dank für eure Antworten.
Domi F. schrieb: > https://www.mikrocontroller.net/articles/FPGA War nicht so recht die erhoffte Antwort.
> Da ich leider absoluter Neuling bin, wollte ich erst einmal fragen, was > ich an Vorkentnisse benötige? Weiterhin schrecken viele vor FPGA ab, > warum eig.? Grundlagen Digitaltechnik. Vorhandene Programmierkenntnisse sind eher hinderlich.
Sascha W schrieb: > Domi F. schrieb: >> https://www.mikrocontroller.net/articles/FPGA > > War nicht so recht die erhoffte Antwort. Naja. Das ist bedauerlich. Allerdings musst Du auch mal die andere Seite betrachten. Die Frage: "Was muss ich alles wissen" ist so ziemlich die unspezifischste, die man stellen kann; dass was man eine "Rundumschlagfrage" nennt. Die Antwort wäre ungefähr das Inhaltsverzeichnis von einem halben Dutzend Büchern. Das kann man nicht jedes mal hinschreiben. Deswegen gibt es den verlinkten Artikel (und weitere im Netz) die Dir zumindest mal einen Überblick darüber geben, was Du nicht weißt. Siehe dazu auch: https://www.mikrocontroller.net/articles/Netiquette oder auch: http://uwiatwerweisswas.schmusekaters.net/Uwi/Wie%20man%20Fragen%20richtig%20stellt.pdf Besser sind spezifische Fragen: Welches Buch, welchen Artikel sollte ich zuerst lesen? Und in dem man Dir den Link schreibt, hat man diese nicht-gestellte Frage beantwortet.
Sascha W schrieb: > ich will mich in das Gebiet FPGA einarbeiten. Dann würde ich das FPGA-Forum bevorzugen. Hier im Microcontrollerforum ist das nur ein Randthema. Streng genommen machen hier eigentilch nur Fragen Sinn, die in beide Welten passen, also das Zusammenspiel von Controller und PLD und / oder das Thema uC-Core im FPGA, was u.a. mein Thema wäre.
Sascha W schrieb: > Domi F. schrieb: >> https://www.mikrocontroller.net/articles/FPGA > > War nicht so recht die erhoffte Antwort. Sorry, aber ich finde der µC-Artikel beschreibt die Grundlagen ziemlich gut... Besonders kannst du bei "Siehe auch..." weitere nützliche Links finden und dich weiterklicken. Ich habe aber die Vermutung, dass du entweder einer der wenigen Menschen dieser Erde bist die den eigentlich richtigen Plural "FPGA" verwenden, oder du aber eigentlich VHDL meinst. (Letzteres ist eher der Fall, liest sich irgendwie so,...) Falls dem so ist: - https://www.mikrocontroller.net/articles/VHDL - https://www.mikrocontroller.net/articles/VHDL_Schnipsel - https://www.mikrocontroller.net/articles/Rechnen_in_VHDL - http://mikro.ee.tu-berlin.de/~kds/text_all.pdf (UNI) Ich selbst hatte VHDL/FPGA-Design an der Uni, aber ich bin zu faul die von meinem Prof referenzierten Bücher rauszusuchen, wenns ein schnelles googlen auch tut. Viel Spass beim lesen!
:
Bearbeitet durch User
Ok vielen Dank erst mal für eure Antworten. Warum sind denn vorhandene Programmierkentnisse eher hinderlich?
Sascha W schrieb: > Ok vielen Dank erst mal für eure Antworten. > > Warum sind denn vorhandene Programmierkentnisse eher hinderlich? Das wird gesagt, und trifft meiner Meinung nach tendentiell zu, weil die meisten VHDL-Anfänger mit Programmierkenntnissen dazu neigen, die Beschreibung einer Hardware als imperatives Programm anzusehen. Das liegt daran, dass die Syntax von VHDL z.B. Pascal oder C sehr ähnlich ist. Die Semantik, d.h. die (Be-)Deutung allerdings ist eine wesentlich andere: Die Beschreibung einer Struktur. Das muss man sich, mit vorherigen Programmierkenntnissen immer wieder bewusst machen, weil man, - das geht mehr oder minder jedem so -, dazu neigt auch VHDL-Beschreibungen so zu lesen, als würden sie sequentiell ausgeführt. Das führt häufig zu Widersprüchen, wenn zwei Prozesse auf die gleichen Signale zugreifen und man denkt, "das kann doch nicht sein". Der Begriff "Prozess" selbst ist, meiner Meinung nach, schon etwas irreführend für Leute mit imperativen Erfahrungen. Deswegen sieht man hier auch häufig die Warnung, das mit VHDL keine Programme sondern Strukturen beschrieben werden.
Sascha W schrieb: > Ok vielen Dank erst mal für eure Antworten. > > Warum sind denn vorhandene Programmierkentnisse eher hinderlich? Weil man eben nicht programmiert. Eigentlich bildet man eine Digitalschaltung in einer Beschreibungssprache ab. Und wenn man also dann schon programmiert hat und Strukturen wie Schleifen ohne nachzudenken anwendet wird das nicht funktionieren. Wenn man HDL lernt ist es eigentlich am hilfreichsten vorher nur Grundkenntnise der Digitaltechnik zu haben, das bringt einen nicht in die Verlegenheit Strategien aus der Softwareentwicklung anwenden zu wollen. Preview-Kommentar: Staubfänger war schneller und etwas korrekter und präziser. Hinweis: VHDL ist da zum Glück noch etwas weiter weg, es ist sehr verlockend in Verilog C-Code zu schreiben (sieht man an diversen englischen FPGA-Hilfethreads hier im Forum).
Man kann vielleicht noch hinzufügen, dass man als VHDL-Anfänger mit imperativen Erfahrungen letztlich nicht darum herumkommt, ab und zu mal in diese Falle zu tappen. Das wohl schärfste Problem ist, das insbesondere "Verhaltensbeschreibungen" durchaus sinnvoll als imperativ zu deuten sind. Tatsächlich aber werden auch sie in Strukturen übersetzt. Letztlich geht das auch nicht anders, denn im FPGA werden Strukturen erzeugt, kein Mechanismus, der Anweisungen interpretiert und ausführt. Ein ausdrücklich beschriebener Aspekt von VHDL, der mit diesem Thema zusammenhängt sind die "concurrent statements". Achte mal auf diese Stichwort. Man muss auch sagen, dass in der Mehrzahl der Text über VHDL keine strikte Unterscheidung zwischen "Programm" und "Strukturbeschreibung" durchgehalten wird. Wenn auch im Detail immer wieder der Unterschied klar wird, so sind gerade in einleitenden Sätzen Phrasen wie "VHDL is a programming language" usw. zu lesen.
Noch was, dann bin ich still: Ich empfinde es als Vorteil, dass ich, zwar mit großem Interesse für uP usw. angefangen habe, aber zu allererst herausfinden wollte, wie ein uP funktioniert und nicht zuerst wie man ihn programmiert. Der Unterschied ist vielleicht nicht ganz offensichtlich, aber ich denke ich kann ihn erklären: Ein uP hat selbst eine innere Struktur. Register, ALU und Verbindungen zwischen ihnen und ein Steuerwerk, dass diese Verbindungen und die Wirkung der ALU kontrolliert. Was dann Eingabe und Ausgabe verbindet ist der Ablauf der Steuerschritte. Und da ist der wesentliche Punkt: Ein Programm schreiben heisst zunächst, den Ablauf dieser Steuerschritte zu beschreiben. Man bildet eine Folge von Rechenoperationen und Entscheidungen. Und das ist einen Schritt tiefer die Manipulation einer konfigurierbaren (und ständig neu konfigurierten) Struktur. In Assembler ist man gezwungen, sich immer dieser Tatsache bewusst zu sein. Es gibt nur eine begrenzte Anzahl Register. Es gibt nur bestimmte Operationen. Alles andere muss man aus Schritten zusammensetzen. Wenn man hingegen mit einer höheren imperativen Sprache beginnt, fokussiert man fast unwillentlich auf das Problem: z.B. wie eine Mittelwertberechnung abläuft oder eine Temperatur von Celsius in Fahrenheit umzurechnen ist. Man verwendet munter Variablen und Kontrollflussanweisungen und Bedingungen und der Compiler nimmt einem die Arbeit ab, zu bestimmen, wie das letztlich als elementare Anweisungen aussieht, welche die Struktur steuern (Assembler). Compiler selbst sind (bis auf wenige Ausnahmen) nicht so entworfen, dass die Steuerung der Struktur im Vordergrund steht, sondern die Wirkung auf Daten und Kontrollfluss. OK. Jetzt wird es vielleicht zu abstrakt. Jedenfalls wollte ich sagen, wer mit uP anfängt und sich mit deren Struktur auseinandersetzt, ist sich öft bewusster, was der Unterschied zwischen Strukturbeschreibung und Ablaufbeschreibung ist.
Sascha W schrieb: > Warum sind denn vorhandene Programmierkentnisse eher hinderlich? Weil man beim FPGA-design kein Programm sondern eine digitale Schaltung entwirft. Vorgehen FPGA (vereinfacht): *Blockbild zeichnen: verwendete Symbole: Counter, FF, Muxer, Logikwolke, Memory,FSM *Blockbild mit den passenden VHDL-templates beschreiben *Syntax fehlerfrei machen -> Simulation -> funktionale Fehler fixen *Synthese/Map/P&R _> synthese-Errors beseitigen -> downloadfile erzeugt Vorgehen Programmieren: *Grob Programmablauf im Kopf haben *mit if/then/case/etc. Programm als variablenzuweisung und routinenaufruf runtschreiben *compile bis swyntax error raus, dann debug. -> da gibt es bis auf die keywords if/then/else keine Gemeinsamkeiten , das eine implementiert ein Blockbild aus digitalen Blöcken, das andere einen Programmablauf aus Variablenzuweisung.
WOW.....vielen Dank für eure Hilfe und Hinweise. Ich bin nach wie vor davon überzeugt, sodass ich mich nun in dieses Gebiet einarbeiten werde. Viele Grüße
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.