Vorausetzungen in FPGA

Domi F. schrieb:
> https://www.mikrocontroller.net/articles/FPGA

War nicht so recht die erhoffte Antwort.

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.

Zum Einlesen:

"Free Range VHDL" von Bryan Mealy und Fabrizio Tappero.

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