VHDL Denken-wie?

[Fred (Gast)]

Hallo liebes Forum,
ich bin VHDL Anfänger und lese mich momentan in die Materie ein. Ich 
höre oft von Internetseiten oder anderen Infoquellen, dass wenn man mit 
VHDL abreitet, parallel Denken muss oder in "Hardware" denken.
Das verstehe ich nicht ganz.
Ist das auf die Nebenläufigkeit der Prozesse bezogen?

Fred

[$$$ (Gast)]

> in "Hardware" denken
Ja, ein typischer Informatik sieht: Oh, eine Programmiersprache.
Schreiben wir also ein Programm...
Und faellt damit natuerlich auf die [hier was passendes einsetzen].

Die
> Nebenläufigkeit der Prozesse
ist etwa so, wie bei einer diskret aufgebauten festverdrahteten
Logik die Gatter/Zaehler/Muxe auch selbststaendlich "nebenlaeufig"
arbeiten.

Es kann also nichts schaden, mal mit Gattern, Muxen, Schieberegistern
und dem ganzen anderen digitalem Gekroese mal selbst eine
Arbitrierungslogik fuer einen 2-Port statischen RAM aufzubauen.
Das in VHDL ist dann ein Kinderspiel.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Fred schrieb:
> in "Hardware" denken. Das verstehe ich nicht ganz. Ist das auf die
> Nebenläufigkeit der Prozesse bezogen?
Nein, damit ist gemeint, dass du dir die Schaltung, die du willst, 
aufmalen oder vorstellen kannst. Und dann kannst du sie mit der 
Hardwarebeschreibungssprache VHDL (oder auch Verilog) beschreiben.

Dass da dann irgendwas "nebenläufig" oder "parallel" ist, wundert dich 
dann nicht mehr, denn in deiner Skizze oder in deiner Vorstellung sind 
ja auch alle Hardwarekomponenten gleichzeitig und parallel vorhanden und 
aktiv!

Stell dir einfach mal 4 Logikgatter auf einer Platine vor. Die 
funktionieren ja auch alle gleichzeitig, ohne das da eines sein Ergebnis 
zuerst oder später "berechnet". Und mit VHDL beschreibst du dann genau 
diese 4 Logikgatter und der Synthesizer packt die ins FPGA. Das wars.

Wenn du anfängst, mit der Beschreibungssprache VHDL oder Verilog so zu 
"Programmieren" wie in einer sequentiellen Programmiersprache Basci, C, 
C++ usw, usf, dann wirst du dir früher oder später (eher das erstere) 
die Nase einklemmen...

[Random .. (thorstendb)]

Häufig fällt gedanklich man auf die [§%$*~], wenn man mehrere 
Zuweisungen untereinanderschreibt, in welchen Variablen von der Zeile 
drüber verwendet werden.
Hier wird nämlich in einem Schwung alles "von links nach rechts 
geschoben", d.h. bei b=a; c=b; bekommt c den alten Wert von b und nicht 
a.
(Ergänzung: wenn innerhalb einer getakteten Einheit, bei concurrent 
(wenn ich mich richtig erinnere) schwingt sich das dann irgendwie 
zurecht.)

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Random .. schrieb:
> Häufig fällt gedanklich man auf die [§%$*~], wenn man mehrere
> Zuweisungen untereinanderschreibt, in welchen Variablen von der Zeile
> drüber verwendet werden.
> Hier wird nämlich in einem Schwung alles "von links nach rechts
> geschoben", d.h. bei b=a; c=b; bekommt c den alten Wert von b und nicht a.
Genau das passiert bei der Verwendung von Variablen nicht. Hier haben 
zum Schluss alle 3 Variablen den selben Wert...

Nehmen wir mal diese Beschreibung:

:
   signal    as, bs, cs : std_logic;
:
   variable  av, bv, cv : std_logic;
:
   process begin
      wait until rising_edge(clk);
   
      bv := av;
      cv := bv;

      bs <= as;
      cs <= bs;
 
   end process;

Da ist nach dem Takt av = bv = cv, aber bs = as(alt) und cs = bs(alt).

Wer jetzt "schlau" denkt, dann nehme ich eben nur noch Variablen, dann 
kann ich wieder "programmieren", der sollte sich mal den Klassiker 
Beitrag "Variable vs Signal" ansehen...

Das überaus Schöne an Signalen ist, dass die Reihenfolge im Prozess 
schnurz ist, weil sie ja den (zuletzt) an sie zugewiesenen Wert erst am 
Ende des Prozesses (oder beim nächsten wait) übernehmen.

Diese beiden Prozesse ergeben also jeweils das selbe Resultat:

   signal    a, b, c, d : std_logic;

   process begin
      wait until rising_edge(clk);
   
      b <= a;
      c <= b;
      d <= c;
 
   end process;


   process begin
      wait until rising_edge(clk);
   
      d <= c;
      c <= b;
      b <= a;
 
   end process;

Random .. schrieb:
> schwingt sich das dann irgendwie zurecht
Da ist nichts, was irgendwelche "Schwingneigung" hat. Bestenfalls der 
Simulator muss auf dem selben Zeitpunkt (die Simulationsziet bleibt 
dabei also auf der selben ps stehen), die Prozesse mehrmals berechnen, 
weil sich durch einen anderen Prozess eines der Signale in der 
Sensitivliste eines bereits berechneten Prozesses ändert.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Und noch etwas:
ein Prozesss/Thread/Task ist in der Softwarewelt etwas recht 
schwergewichtiges, d.h. es werden Code, Stack, Ausführungszeit beim 
Erzeugen und bei jedem Kontextwechsel benötigt.

Ein Prozess in VHDL benötigt hingegen keine Ressourcen auf dem 
Zielsystem. Jede außerhalb eines Prozesses befindliche Anweisung muss 
sogar als eigener Prozess betrachtet werden. Wenn man sich erst einmal 
die Hardwaresicht angeeignet hat, "sieht" man man die 
process-Anweisungen.

Der Hauptgrund, weswegen ich fast ausschließlich VHDL und nicht Verilog 
verwende, besteht darin, dass Verilog zu C-ähnlich ist und ich die 
Gefahr sehe, solchen Code mit der Softwarebrille zu lesen und zu 
erstellen. Dies gilt insbesondere vor dem Hintergrund, dass ich sehr 
häufig zwischen HDL-Code und den zugehörigen Treibern in C/C++ hin- und 
herwechsele. Wenn ich z.B. ein Peripherieregister definiere, erstelle 
ich sofort auch die zugehörigen Bitdefinitionen in der C-Headerdatei und 
Low-Level-Zugriffsfunktionen.

[Schlumpf (Gast)]

Random .. schrieb:
> (Ergänzung: wenn innerhalb einer getakteten Einheit, bei concurrent
> (wenn ich mich richtig erinnere) schwingt sich das dann irgendwie
> zurecht.)

Innerhalb einer "getakteten Einheit" schwingt sich das nicht irgendwie 
zurecht, sondern es wird beschrieben, was genau bei der Taktflanke 
passieren soll.

So als kleine Gedankenstütze:

Alles, was innerhalb einer Architecture steht, "passiert" gleichzeitig 
und jederzeit
Alle Prozesse innerhalb einer Architecture "passieren" auch gleichzeitig 
und jederzeit
Innerhalb eines Prozesses passiert auch alles gleichzeitig und 
jederzeit.
Aber: Innerhalb eines Prozesses kann eine "getaktete Einheit" 
beschrieben werden. Innerhalb dieser passiert auch alles gleichzeitig, 
ABER nicht jederzeit, sondern nur mit der Taktflanke. In der Zeit 
zwischen den Flanken bleibt der letzte Wert einfach gespeichert. Damit 
werden also Register beschrieben.

Das ist jetzt natürlich eine stark vereinfachte, nicht 100%ig korrekte 
und auch sehr abstrakte  Erklärung, aber sie hilft vielleicht, in diese 
Art des Denkens hinein zu kommen.

Letztendlich "passiert" in dem Code nichts. Der Code beschreibt eine 
Hardware. Oder noch besser, er beschreibt ein Verhalten, das der 
Synthesizer dann in eine Hardware abbilden kann.

[Fred (Gast)]

Danke für eure Erklärungen.
Schlumpf schrieb:
> Innerhalb eines Prozesses kann eine "getaktete Einheit"

Da du es gerade Ansprichst, stellt sich mir noch die Frage, wie man 
einen sequentiellen und
kombinatorischen Prozess unterscheidet.

Habe mir schon hier https://www.mikrocontroller.net/articles/VHDL
die Grundregeln der Prozesse angeschaut und einigermaßen verstanden.
Aber wie erkenne ich ob es sich um einen seq. oder komb. Prozess handelt
und wann sollte man welchen nutzen?

Lothar M. schrieb:
> signal    a, b, c, d : std_logic;
>
>    process begin
>       wait until rising_edge(clk);

Dies müsste dann ein sequentieller Prozess sein, weil er ein
wait-Statement beinhaltet oder?
Und  kann man State machines in komb. als auch in seq. Prozessen
entwickeln?

[Fred (Gast)]

Ein Code mit State machines verwirrt mich irgendwie ein bisschen, weil 
es mir schwer fällt sie als Schaltung vorzustellen.

[Schlumpf (Gast)]

Das ist jetzt ein wenig kniffelig.

Ein Process wird tatsächlich "gedanklich" sequenziell durchgearbeitet. 
Also die darin beschriebene logische Denkweise ist tatsächlich 
sequenziell.
Hier kann die Reihenfolge der Zuweisungen zu einer Beeiflussung der 
Funktion führen.

Man verwendet also die Logik, die eine sequenzielle Beschreibung mit 
sich bringt, um eine Funktion darzustellen.
Das heißt aber nicht, dass in der Hardware eine sequenzielle Logik 
gebaut wird.
(hmm, schwer zu erklären)

Aber vielleicht so:
Ein kombinatorischer Prozess beschreibt mit sequenziellen 
Sprachelementen eine rein kombinatorische Logik.
(z.B ein Decoder oder Multiplexer)

Ein sequenzielle Prozess beschreibt eine sequenzielle Logik. Also eine 
Logik, die Register beinhaltet und somit auch in der Hardware zu einer 
sequenziellen Funktion führt (z.B. eine Zustandsmaschine oder ein 
Zähler)

[Michael B. (laberkopp)]

Fred schrieb:
> parallel Denken muss

'Zuweisungen' in VHDL

      a <= 1;
      b <= a;
      c <= a;

erfolgen nicht nacheinander, sondern alle gleichzeitig im dazugehörigen 
TAKT. Du darfst also nicht sequentiell denken "c wird 1" (im Beispiel 
oben) sondern es macht klack und rechts wird nach links übertragen, alle 
parallel zur selben Zeit, c ist also das alte a während das neue a 1 
wird, auch wenn die Ausdrücke viel komplexer sind.

Eine Schleife ist nicht eine Schleife in der etwas nacheinander über die 
Zeit beschrieben und durchgeführt wird, sondern eine Schleife baut 
replizierte Hardware, aus 1 bit FlipFlip wird so durch 8-fache 
Wiederholung ein 8 bit Register mit 8 FlipFlops, oder eben 
(2-dimensional 256) ein 64kbit Speicherarray, bei dem man GARANTIERT 
nicht alle 65536 einzelne Zellen im code hinschreiben will. Es ähnelt 
also der Aufgabe "Schreibe 100 mal ich soll nicht abgucken" an einen 
Programmierer:
FOR i=1 TO 100 DO
"ich soll nicht abgucken"
END FOR


> oder in "Hardware" denken

Such dir einfach die vorgefertigten VHDL Konstrukte für Gatter, Latches, 
Zähler, Multiplexer, eben alle 74TTL Bausteine aus der Doku raus, und es 
bleibt als Arbeit für dich nur noch die Verdrahtung der Bausteine durch 
Zusammenführung mehrerer Blöcke durch port/map als Aufgabe in VHDL.
Genau so einfach zu verstehen wie TTL Logik.

[Random .. (thorstendb)]

Schlumpf schrieb:
>> (Ergänzung: wenn innerhalb einer getakteten Einheit, bei concurrent
>> (wenn ich mich richtig erinnere) schwingt sich das dann irgendwie
>> zurecht.)

Ist etwas falsch rübergebracht.
Gemeint war: Wenn innerhalb einer getakteten Einheit wird li nach re 
geschoben. Wenn ausserhalb, dann ...
VHDL ist bei mir schon etwas her, aber dies ist einer der großen 
Fallstricke beim Einstieg gewesen :-)
Und ja, es war eher "signal" gemeint ^^

Man muss in VHDL sehr viel mehr parallel denken, im Gegensatz zur 
Softwareentwicklung. Nach einem kurzen Ausflug in VHDL bin ich aber seit 
Jahren ganz und gar in der Software gelandet (da aber auch parallel :-) 
)

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Fred schrieb:
> Lothar M. schrieb:
>> signal    a, b, c, d : std_logic;
>>
>>    process begin
>>       wait until rising_edge(clk);
> Dies müsste dann ein sequentieller Prozess sein, weil er ein
> wait-Statement beinhaltet oder?
Jeder Prozess ist "sequentiell", weil er im Simulator "von oben her 
Zeile für Zeile" berechnet wird. In der realen Hardware läuft da 
nichts "nacheinander". Und dann gibt es entwerde kombinatorische oder 
getaktete Prozesse. Kombinatorische Prozesse haben kein 'event oder 
rising_edge/falling_edge.

Sieh dir einfach den RTL Schaltplan an, den der Synthesizer aus deiner 
Beschreibung macht. Wenn dabei das herauskommt, was du erwartest, dann 
war die Beschreibung deiner Hardware korrekt.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Fred schrieb:
> Dies müsste dann ein sequentieller Prozess sein, weil er ein
> wait-Statement beinhaltet oder?

Nein, das entscheidende Kriterium für einen sequentiellen Prozess ist 
die Abfrage einer Flanke, also das rising_edge(x) bzw. falling_edge(). 
Auch der folgenden Prozess ist sequentiell:

process(clk, ...)
 begin
  if rising_edge(clk) then
    ...
  end if;
end process;

> Und  kann man State machines in komb. als auch in seq. Prozessen
> entwickeln?

Bei Verwendung der sog. Zwei-Prozess-Schreibweise besteht die FSM aus 
einem kombinatorischen und einem sequentiellen Prozess.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Ja, da haben wir eine hübsche Begriffsverwirrung um den Begriff 
"sequentiell".

Jeder Prozess wird sequentiell (= Zeile für Zeile) abgearbeitet, er 
muss aber nicht unbedingt eine sequentielle (= weiterschaltende, 
speichernde) Logik beschreiben und heißt dann kombinatorischer 
Prozess. Damit hängt es auch beim Letzten aus...  ;-)

Um dieser Verwirrung aus dem Weg zu gehen, lasse ich meinen Simulator 
alle Prozesse sequentiell von oben her abarbeiten. Egal ob sie 
kombinatorisch oder getaktet sind.

[Schlumpf (Gast)]

Beispiel:

Außerhalb eines process ist alles "gleichzeitig".

architecture Behavioral of xxx is
signal a, b, c : std_logic;
begin
  a <= b;
  a <= c;
end Behavioral;

Sowas geht nicht.. es ist außerhalb eines Process und damit sind alle 
Zuweisungen gleichzitig "gültig". Und a kann nicht gleichzeitig b und c 
sein. Das wäre ein "Kurzschluss".

Das Gleiche innerhalb eines Process:

architecture Behavioral of xxx is
signal a, b, c : std_logic;
begin
  process begin
  a <= b;
  a <= c;
  end process;
end Behavioral;

Das funktioniert. Hier wird a=c rauskommen. Denn hier gilt die 
sprachliche Logik der sequenziellen Darstellung. Wichtig ist aber beim 
Process, dass die letzte Zuweisung im Prozess die ist, die dann 
tatsächlich auch gilt.

Dieser Process beschreibt aber genau das gleiche wie folgendes 
Konstrukt:

architecture Behavioral of xxx is
signal a, b, c : std_logic;
begin
  a <= c;
end Behavioral;

In einem process, der sequenzielle Logik beschreibt, kommt der Takt mit 
ins Spiel:

architecture Behavioral of xxx is
signal a, b, c : std_logic;
begin
  process begin
  wait until rising_edge(CLK);
  a <= b;
  end process;
end Behavioral;

Hier erfolgt die Zuweisung nur, wenn CLK eine steigende Flanke hat. Für 
den Rest der Zeit bleibt der Wert einfach "gespeichert". Und das 
beschreibt ein Register und somit ein sequenzielles Logikelement.

[Schlumpf (Gast)]

Lothar M. schrieb:
> Ja, da haben wir eine hübsche Begriffsverwirrung um den Begriff
> "sequentiell"

Richtig, ich hab ja bereits versucht, es zu trennen, aber weiss nicht, 
ob mir das gelungen ist, es so rüber zu bringen, dass der Unterschied 
klar ist.

Schlumpf schrieb:
> Man verwendet also die Logik, die eine sequenzielle Beschreibung mit
> sich bringt, um eine Funktion darzustellen.
> Das heißt aber nicht, dass in der Hardware eine sequenzielle Logik
> gebaut wird.
> (hmm, schwer zu erklären)
>
> Aber vielleicht so:
> Ein kombinatorischer Prozess beschreibt mit sequenziellen
> Sprachelementen eine rein kombinatorische Logik.
> (z.B ein Decoder oder Multiplexer)
>
> Ein sequenzielle Prozess beschreibt eine sequenzielle Logik. Also eine
> Logik, die Register beinhaltet und somit auch in der Hardware zu einer
> sequenziellen Funktion führt (z.B. eine Zustandsmaschine oder ein
> Zähler)

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Dass es da eine so auffällige Doppeldeutigkeit/Doppelbedeutung des 
Wortes "sequentiell" gibt, wird mir jetzt erst so richtig bewusst. Kein 
Wunder hagelt es jeden Anfänger aus dieser Kurve...   ;-)

[Schlumpf (Gast)]

Lothar M. schrieb:
> wird mir jetzt erst so richtig bewusst
Das ist mir auch jetzt erst bewusst geworden, als ich über die Frage des 
TO nachdachte.. Dass es eigentlich total irreführend ist.

Ich hoffe, dem TO ist der Unterschied klar geworden.
Falls nicht, einfach nochmal nachfragen. Vielleicht kann es jemand noch 
geschickter erklären.

[Marcus H. (mharnisch)]

Dieses Rumreiten auf dem "in VHDL/Verilog programmiert man nicht" (mit 
wichtig erhobenem Zeigefinger) halte ich für ziemlichen Unsinn. 
Selbstverständlich programmiere ich in diesen Sprachen, sogar ständig, 
und ich falle nicht öfter auf die Fresse als mit anderen 
Programmiersprachen auch. Während des Lernprozesses muss man sich bei 
jeder Sprache an gewisse Eigenarten gewöhnen.

Andreas S. schrieb:
> Ein Prozess in VHDL benötigt hingegen keine Ressourcen auf dem
> Zielsystem.

In einer virtuellen Laufzeitumgebung (vulgo: Simulator) bedeutet die 
Implementierung der Nebenläufigkeit selbstverständlich einen gewissen 
Zusatzaufwand gegenüber einem einzelnen Prozess. Wie das genau 
abgebildet wird (OS thread, co-routine, was auch immer), ist freilich 
ein Implementierungsdetail das durch die Sprache selbst nicht vorgegeben 
wird.

An das Ziel, eine Untermenge dieser Programmiersprachen durch clevere 
Tricks in eine Schaltung zu synthetisieren, hat ja damals noch keiner 
gedacht... ;)

> [...] die Gefahr sehe, solchen Code mit der Softwarebrille [...] zu
> erstellen.

Bei manchem VHDL/Verilog Code der mir begegnet, würde ich mir das sehr 
wünschen.

[Frage (Gast)]

Schlumpf schrieb:
> Ich hoffe, dem TO ist der Unterschied klar geworden.
> Falls nicht, einfach nochmal nachfragen.

Ja habe es jetzt verstanden. Schreibe mir die wichtigen Aspekte nochmal 
raus. Danke für eure Hilfe.

[Michael W. (Gast)]

Fred schrieb:
> Ist das auf die Nebenläufigkeit der Prozesse bezogen?

Hast du dir mal die Mühe gemacht, die vielen Themen dazu hier 
durchzuarbeiten?

Oder dich mal mit digitaler Hardware befasst?

[PittyJ (Gast)]

Meiner Meinung nach hilft nur Üben. Bis man die Unterschiede zwischen 
Variable und Signal in VHDL und C wirklich verstanden hat, das braucht 
einige Zeit. Ohne Hardware, Simulator und tagelangen Üben geht da 
nichts.

Ich würde jedem Anfänger empfehlen, sich ein Devboard zu kaufen. Die 
gibt ja schobn für einen Hunderter. Und dann die einschlägigen Beispiele 
selber machen: Lauflicht, HD4470 Display, I2C Master ...

Und irgendwann dabei macht es 'klick'.

[Carl (Gast)]

Für mich war ganz klar das größte Problem, dass in den VHDL-Büchern zu 
wenig auf den Unterschied zwischen Simulation und Synthese eingegangen 
wird.

In den Büchern wird immer versucht, die Sprache so allgemein wie möglich 
zu erklären und das führt zur Vermischung der Simulationsbefehle mit den 
eigentlichen Synthesebefehlen, die gleich aussehen.

Die Bücher sollten aber anders Strukturiert sein. Es sollte klar erklärt 
werden, das VHDL ursprünglich für die Simulation gemacht wurde und erst 
später ersichtlich wurden, dass man um Schreibarbeit zu sparen damit 
auch gleich Synthesewerkzeuge machen könnte. Das führt dann zu dieser 
unglücklichen Vermischung.

z.B. Was sollen Empfindlichkeitslisten? Ich brauche sie nicht.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Carl schrieb:
> z.B. Was sollen Empfindlichkeitslisten?
Im Prinzip sind sie ein Teil der "Eigendokumentation", die man mit VHDL 
erreicht. Wenn ich schon in dieser Liste sehe, dass ein Signal, von dem 
ich die auswirkungen untersuche, dort nicht verwendet wird, dann muss 
ich mir den Prozess nicht anschauen.

> Ich brauche sie nicht.
Eigentlich "brauchst" du die strenge Typisierung von VHDL auch nicht. Es 
wäre doch ganz oft viel einfacher, wenn man von Strings bis zu einzelnen 
Bits einfach alles mischen und zuweisen könnte. Und solange der Compiler 
irgendeinen beliebigen Weg findet, das zu machen, meldet er keinen 
Fehler.
[/ironie off]

Denk doch einfach so: du brauchst die Sensitivlisten nicht, aber der 
Simulator braucht sie. Und wenn du da eine diesbezügliche Meldung vom 
Simulator oder vom Synthesizer bekommst, dann sollte dir das zu Denken 
geben. Denn offenbar versteht da einer was Anderes als von dir 
eigentlich beschrieben.

PittyJ schrieb:
> ... tagelangen Üben ...
> Und irgendwann dabei macht es 'klick'.
Bei mir hat das deutlich länger gebraucht...   ;-)

[Vancouver (Gast)]

Marcus H. schrieb:
> Dieses Rumreiten auf dem "in VHDL/Verilog programmiert man nicht" (mit
> wichtig erhobenem Zeigefinger) halte ich für ziemlichen Unsinn.

Tja, seltsam. Ich sehe tagtäglich, dass die Leute erst dann anfangen, 
korrekte VHDL-Modelle zu bauen, wenn sie den Unterschied zum 
Programmieren verstanden haben. Wenn ihnen klar geworden ist, dass sie 
eine Architektur beschreiben, und kein Programm, dass auf einer 
bestehenden Architektur läuft. Wenn sie kapiert haben, dass 
HDL-Modellierung und Programmierung kaum unterschiedlicher sein könnten, 
mit oder ohne Zeigefinger. Die Frage des TO ist ein perfektes Beispiel 
für dieses Missverständnis.

Wenn Programmieren für  Dich bedeutet, am Rechner zu sitzen und Befehle 
irgendeiner Sprache einzutippen, dann hast Du vermutlich recht.

[Schlumpf (Gast)]

Marcus H. schrieb:
> An das Ziel, eine Untermenge dieser Programmiersprachen durch clevere
> Tricks in eine Schaltung zu synthetisieren, hat ja damals noch keiner
> gedacht... ;)

Das würde ich so nicht sagen.

VHDL wurde als Spezifikationssprache erfunden, um das Verhalten von 
ASICs zu spezifizieren, bzw. zu beschreiben.

Dann wurden Simulatoren erfunden, um die Spezifikation zu "überprüfen".

Und im nächsten Schritt kam dann die Idee, daraus auch gleich die HW zu 
synthetisieren.

VHDL war nie als "Programmiersprache" gedacht, obwohl man sie natürlich 
theoretisch als eine missbrauchen könnte.

[Strubi (Gast)]

Und täglich grüsst das Murmeltier...
Das Thema wurde hier schon zigfach durchgekaut.

Schlumpf schrieb:
> VHDL wurde als Spezifikationssprache erfunden, um das Verhalten von
> ASICs zu spezifizieren, bzw. zu beschreiben.
>
> Dann wurden Simulatoren erfunden, um die Spezifikation zu "überprüfen".
>
> Und im nächsten Schritt kam dann die Idee, daraus auch gleich die HW zu
> synthetisieren.
>
> VHDL war nie als "Programmiersprache" gedacht, obwohl man sie natürlich
> theoretisch als eine missbrauchen könnte.

Also nochmal: Technisch gesehen ist VHDL immer noch eine 
Programmiersprache, da sind die Definitionen ganz eindeutig 
(Turing-Vollständigkeit), auch wenn da ein 'D' steht. Historisch ist 
halt nicht immer logisch. Die Historie lehrt uns nur, dass aus Ada 
irgendwann für einen speziellen Zweck VHDL wurde..

Macht auch Sinn, da man gewisse prozedurale Sachen eben programmieren 
WILL und eine Testbench durchaus einen prozeduralen (und allenfalls 
Turing-vollständigen) Charakter haben soll. So wird in VHDL also täglich 
'programmiert'.

Der Defizit der V*-Sprachen als pure Beschreibungs- oder 
Spezifikationssprache ist der, dass die Sprache abgesehen von der Syntax 
keine Spezifikation von Designregeln zulässt (im Gegensatz zu XML). Und 
genau da ist die Crux: eine eigentliche Programmiersprache in ein 
synthesefähiges Ding (Netzliste, == Beschreibungssprache!) zu 
übersetzen, ist ein softwaretechnischer Albtraum, da die Untermenge der 
synthesefähigen Konstrukte zumindest in VHDL recht gering ist. Ich habe 
mir den Aufwasch von HDL -> XML -> DRC mal gegeben, ist für ein kleines 
Team kaum zu bewältigen.

Marcus H. schrieb:
> An das Ziel, eine Untermenge dieser Programmiersprachen durch clevere
> Tricks in eine Schaltung zu synthetisieren, hat ja damals noch keiner
> gedacht... ;)

Sagen wir, die Idee ging grandios schief und wir müssen uns jetzt mit - 
böse gesagt- für heutige SW-Standards unzulänglichen Sprachen 
herumschlagen.

Generell gilt für beide HW/SW-Entwicklerlager: Wenn das Verständnis 
fehlt, fällt man als SW auf die Nase, wenn man die Elektronik nicht 
grundlegend kapiert. Die HW-Entwickler fallen handkehrum dann bei 
komplexen Projekten auf die Nase, wenn der betreffende Write-Only-Code 
kaum noch wartbar ist. Da darf man sich dann schon die Herangehensweise 
und Konzepte aus der SW-Welt wünschen. MyHDL ist da z.B. nahe dran, 
andere Ansätze wie Chisel leider eher "broken by design".

[Carl (Gast)]

>VHDL war nie als "Programmiersprache" gedacht, obwohl man sie natürlich
>theoretisch als eine missbrauchen könnte.

Wobei VHDL erstaunliche Ähnlichkeiten mit ADA hat.
GHDL ist in ADA programmiert:
https://github.com/ghdl/ghdl

[Christophz (Gast)]

Carl schrieb:
> Für mich war ganz klar das größte Problem, dass in den VHDL-Büchern zu
> wenig auf den Unterschied zwischen Simulation und Synthese eingegangen
> wird.

Genau darum mag ich das Buch "VHDL Synthese" von Reichard und Schwarz. 
Erst damit begriff ich, was ich da mit *HDL eigentlich tue.

Später im Leben braucht es dann noch andere Bücher/Quellen um die volle 
Mächtigkeit der Sprache nutzen zu können, was aber vor allem fürs 
schreiben von Testbenches das Leben einfacher macht.

Fred schrieb:
> Ein Code mit State machines verwirrt mich irgendwie ein bisschen, weil
> es mir schwer fällt sie als Schaltung vorzustellen.

Dazu lohnt sich wohl ein Blick in ein Digitaltechnikgrundlagenbuch oder 
ins Skript einer ersten Digitaltechnikvorlesung. Da kommt das immer vor.
Wer Bücher mag, kann sonst einen Blick ins "Vom Gatter bis zu VHDL" 
werfen.

[Hans Hämmerle (Gast)]

Carl schrieb:
>>VHDL war nie als "Programmiersprache" gedacht, obwohl man sie natürlich
>>theoretisch als eine missbrauchen könnte.
>
> Wobei VHDL erstaunliche Ähnlichkeiten mit ADA hat.
> GHDL ist in ADA programmiert:
> https://github.com/ghdl/ghdl

Das ist nicht erstaunlich, wenn man weiss das beide aus der selben 
"Quelle" stammen.

Ada und VHDL wurden von einer offiziellen Stelle initiert um den 
"Wildwuchs" an Programmier- und beschreibungssprachen einzudämmen indem 
man einen Standard für Software (Ada) und Hardware (VHDL) vorgibt. Die 
Behörde (DoD) sah sich immer weniger in der Lage die hunderte 
Entwicklungsumgebungen der extern vergebenen Projekte zu managen.

[Schlumpf (Gast)]

Strubi schrieb:
> Also nochmal: Technisch gesehen ist VHDL immer noch eine
> Programmiersprache,

Hab ich was Gegenteiliges behauptet?

Also nochmal:
VHDL wurde erfunden, um ASICS zu spezifizieren und nicht um zu 
programmieren.
Auch wenn hier was anderes behauptet wird.
Das wollte ich nur klar stellen.

Wenn VHDL alle Merkmale einer Programmiersprache erfüllt, dann kann man 
sie von mir aus auch als eine bezeichnen. Aber ERFUNDEN wurde sie nicht, 
um zu programmieren.

Man kann sich auch mit nem alten Socken den Arsch wischen und sagen: 
Wischt prima.. muss wohl Klopapier sein.
Kann man tun, aber war so eigentlich nicht gedacht.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Ich halt mich einfach mal aus der Diskussion VHDL /= VHPL raus.

Aber ich sage das mit der "Beschreibungssprache" explizit jedem meiner 
Praktikanten, nachdem ich sie mal eine Woche oder zwei Wochen mit VHDL 
drauflos "programmieren" gelassen habe. Und bei vielen höre ich dann 
richtig, wie der Groschen fällt...

[Schlumpf (Gast)]

Lothar M. schrieb:
> Aber ich sage das mit der "Beschreibungssprache" explizit jedem meiner
> Praktikanten, nachdem ich sie mal eine Woche oder zwei Wochen mit VHDL
> drauflos "programmieren" gelassen habe. Und bei vielen höre ich dann
> richtig, wie der Groschen fällt...

Und darum geht´s doch.. wenn man sich das vor Augen führt, dann hat man 
es begriffen.. Oder man "programmiert" halt seine FPGAs..
Spätestens bei ner Schleife, die man 10.000 mal durchläuft und sich 
wundert, warum der ganze Mist nicht mehr ins FPGA passt, fängt dann das 
Grübeln an.

Aber wie gesagt: Es sind Begriffe und über die kann man natürlich 
trefflich streiten.
Wer es lieber als eine Programmiersprache betrachten will, kann das 
natülich gerne tun. Formell hat er damit ja auch recht.

[Carl (Gast)]

Christophz schrieb
>Genau darum mag ich das Buch "VHDL Synthese" von Reichard und Schwarz.
>Erst damit begriff ich, was ich da mit *HDL eigentlich tue.

Das Buch habe ich auch schon länger und ich finde es als Lehrbuch völlig 
ungeeignet. Die Sprache ist akademisch holzig.
Am ehesten ist es wahrscheinlich als Nachschlagewerk zur Vorlesung 
geeignet.

Im Anhang die zwei Seiten, die die Hauptfrage des Thread-Erstellers hier 
beantworten sollen.

Fred, falls Du noch mit liest: Ist das verständlich?

[Fred (Gast)]

Carl schrieb:
> Fred, falls Du noch mit liest: Ist das verständlich?

Ja, danke dir.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Carl schrieb:
> Im Anhang die zwei Seiten, die die Hauptfrage des Thread-Erstellers hier
> beantworten sollen.
Viel interessanter und für den Fall des Groschens letztlich 
verantwortlich sind dann die Beispiele, bei denen als Ergebnis eben auch 
der RTL-Schaltplan gezeigt wird.
Dort z.B. auf den Seiten 25 und 26 für einen Multiplexer:
https://www.amazon.de/VHDL-Synthese-Entwurf-digitaler-Schaltungen-Systeme/dp/3110375052/ref=sr_1_1?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=17H6KTA0BS2EK&keywords=vhdl+synthese&qid=1558094594&s=gateway&sprefix=vhdl+synth%2Caps%2C146&sr=8-1#reader_3110375052

Und dass neben den "funktionierenden" Beschreibungen eben auch solche 
gezeigt werden, die nicht funktionieren (z.B. zwei Zuweisungen an das 
selbe Signal) und ausdrücklich auch auf Fehler hingewiesen wird, die 
auch mit einem Simulator nicht unbedingt zu finden sind (z.B. gegatete 
kombinatorische Schleifen).

[W.S. (Gast)]

Schlumpf schrieb:
> Und darum geht´s doch.. wenn man sich das vor Augen führt, dann hat man
> es begriffen.. Oder man "programmiert" halt seine FPGAs..

Natürlich programmiert man sein FPGA. WAS DENN SONST?? Einem Stück 
Materie, das ursprünglich garnichts kann, eine Funktionalität 
beizubringen, das nennt man Programmieren.

Was dich und Lothar offensichtlich immens stört, ist deine innere 
Schere, die dir sagt "Programmieren ist sequentielles Abarbeiten einer 
imperativen Programmiersprache" - weil du eben dabei NUR an die 
Turingmaschine und das Lochband als grundlegende Funktionalität denkst.

Das ist schlichtweg falsch und es wird auch nicht besser, wenn man 
insistierend drauf besteht, das Ganze in diesem Falle mit 
"..Beschreibungs.." zu umrunden. Abgesehen davon gibt es m.W. beides in 
VHDL: sowohl sequentiell als auch parallel/concurrent.

Mich stören an VHDL ganz andere Dinge - und das vehement. VHDL ist 
übertrieben formalistisch, im Mechanischen nennt man das überbestimmt. 
Etwa so wie bei Hallervorden mit dem Kirschkuchen ("ein Stück 
Kirschkuchen bitte - aber OHNE Gräten" - "bei und hat Kirschkuchen keine 
Gräten" - "ja eben, deswegen ein Stück Kirschkuche - ABER OHNE 
Gräten!"..usw)

Auf der anderen Seite ist VHDL extrem stupide, so daß man schreiben muß, 
was VHDL von einem erwartet - und nicht, was man an Funktionalität 
eigentlich haben will. Den Mumpitz bei den Standardlogikvektoren hatten 
wir ja schon vor langem durchgekäut. Man gibt zwar eine Ordnung an 
(Ottokar(0 to 15) oder so ähnlich), kann damit aber nichts rechnen, 
nicht einmal etwas vergleichen. Und das, obwohl man mit dem 0 to 15 eine 
Ordnung angegeben hat, also den enthaltenen Bits die Ordnungen 2^0 bis 
2^15 verpaßt hat.

Aber eigentlich alle Autoren reiten zu allererst auf dem 
"std_logic_vector" herum und sowas wie "unsigned" kommt entweder 
garnicht oder irgendwo viel weite rhinten vor.

Kurzum, das Allermiserabelste an VHDL sind die Tutorials und 
Schriften, die für Lernbegierige zur Einführung in diese 
Programmiersprache verfaßt wurden.

W.S.

[W.S. (Gast)]

Fred schrieb:
> ich bin VHDL Anfänger und lese mich momentan in die Materie ein. Ich
> höre oft von Internetseiten oder anderen Infoquellen, dass wenn man mit
> VHDL abreitet, parallel Denken muss oder in "Hardware" denken.
> Das verstehe ich nicht ganz.

Naja, mal hier eine Grob-Version:

Versuche mal innerlich, all die Funktionsblöcke in VHDL als diverse 
Arten TTL-Schaltkreise zu begreifen.

Wenn du eine Leiterplatte vollpackst mit TTL-Schaltkreisen und Strippen 
ziehst zwischen ihnen, dann ist es dort ja auch so, daß alle 
Schaltkreise parallel zueinander arbeiten und nicht ihre Funktion 
nacheinander ausüben. Ein jeder Schaltkreis reagiert für sich auf seine 
Eingangssignale.

Das ist eigentlich alles.

Und für ein geordnetes Funktionieren - sowohl für obige Leiterplatte als 
auch für ein FPGA - muß man die jeweiligen Einschwingzeiten der 
verschiedenen Schaltungen beachten. Je paralleler, desto weniger 
Gatterlaufzeiten hat man nacheinander.

W.S.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

W.S. schrieb:
> Mich stören an VHDL ganz andere Dinge
Darum soll es hier im Thread aber bitte nicht gehen.

BTW: warum beharren Ballonfahrer eigentlich so vehement darauf, dass 
sie nicht fliegen. Obwohl das von unten/aussen irgendwie ganz ähnlich 
aussieht?
;-)

[Schlumpf (Gast)]

W.S. schrieb:
> Natürlich programmiert man sein FPGA. WAS DENN SONST?? Einem Stück
> Materie, das ursprünglich garnichts kann, eine Funktionalität
> beizubringen, das nennt man Programmieren.

Der Töpfer programmiert dann also aus einem Haufen Ton eine schöne Vase 
und der Schmied aus Stahl eine Axt...

W.S. schrieb:
> Abgesehen davon gibt es m.W. beides in
> VHDL: sowohl sequentiell als auch parallel/concurrent.

Ändert leider nichts an der Sache. Weiter oben findest du auch die 
Erklärung, warum.

Kann es jeder nennen, wie er will. Hauptsache ist, dass alle begreifen, 
was sie da "programmieren". Und da scheint es bei vielen zu hapern.
Und DARUM geht´s.

Ich klinke mich auch aus dieser fruchtlosen Diskussion aus.

[Hans Hämmerle (Gast)]

Lothar M. schrieb:

> BTW: warum beharren Ballonfahrer eigentlich so vehement darauf, dass
> sie nicht fliegen. Obwohl das von unten/aussen irgendwie ganz ähnlich
> aussieht?
> ;-)

Weil sie andernfalls einen Pilotschein und die im Vorfeld nötige 
mehrjährige Ausbildung benötigen.
Für den Ballonfahrerschein bedarf es lediglich 60h Theorie und 20h 
Praxis, während es beim Pilotschein 45h Praxis und 100h Theorie sind. 
Für Instrumentenflug (gibbets bei ballon garnicht) kommen 200h Theorie 
drauf, für berufspiloten nochmal 200h.

Aus ähnlichen Beweggründen beharren Informatiker darauf, das FPGA's 
programmiert werden - damit sie sich auch ohne die mehrjährige 
Ausbildung resp. Befähigungsnachweis als Hardware-Digitalentwickler auf 
FPGA-Stellen bewerben können.

[Carl (Gast)]

>BTW: warum beharren Ballonfahrer eigentlich so vehement darauf, dass
>sie nicht fliegen. Obwohl das von unten/aussen irgendwie ganz ähnlich
>aussieht?
>;-)

Ja, das ist in der Tat der gleich Quatsch.

[Hans Hämmerle (Gast)]

Hans Hämmerle schrieb:
> Lothar M. schrieb:
>
>> BTW: warum beharren Ballonfahrer eigentlich so vehement darauf, dass
>> sie nicht fliegen. Obwohl das von unten/aussen irgendwie ganz ähnlich
>> aussieht?
>> ;-)
>
> Weil sie andernfalls einen Pilotschein und die im Vorfeld nötige
> mehrjährige Ausbildung benötigen.

Aus diesen Gründen hat es eben bei Larry nur zum Ballon "Fahren" 
(genaugenommen "Sitzen") gereicht - und nicht zum "Fliegen".

https://de.wikipedia.org/wiki/Larry_Walters

Und jetzt Schluss mit OT.

[Fred (Gast)]

Lothar M. schrieb:
> Viel interessanter und für den Fall des Groschens letztlich
> verantwortlich sind dann die Beispiele, bei denen als Ergebnis eben auch
> der RTL-Schaltplan gezeigt wird.

Danke für den nochmaligen Hinweis des RTL-Schaltplan(Tool). Ich denke 
bei mir hats jetzt Klick gemacht. Zumindest für das Verständnis über was 
man mit VHDL tut.

[Carl (Gast)]

W.S. schrieb:
>Den Mumpitz bei den Standardlogikvektoren hatten
>wir ja schon vor langem durchgekäut. Man gibt zwar eine Ordnung an
>(Ottokar(0 to 15) oder so ähnlich), kann damit aber nichts rechnen,
>nicht einmal etwas vergleichen. Und das, obwohl man mit dem 0 to 15 eine
>Ordnung angegeben hat, also den enthaltenen Bits die Ordnungen 2^0 bis
>2^15 verpaßt hat.

Der Thread dazu würde mich mal interessieren.

Der Filter von Lothar läuft ganz ohne Integer-Bibliothek mit 
std_logic-vector:

http://www.lothar-miller.de/s9y/archives/98-RC-Filter-im-FPGA.html

[berndl (Gast)]

W.S. schrieb:
> Mich stören an VHDL ganz andere Dinge - und das vehement. VHDL ist
> übertrieben formalistisch, im Mechanischen nennt man das überbestimmt.

kann man wohl so sehen. Im Gegenzug erlaubt es, dass man auch einen 
wilden Design eines nicht-mehr-Kollegen nach ein paar Jahren relativ 
schnell verstehen kann.
Deshalb finde ich VHDL besser als Verilog, das geht deutlich laxer mit 
Formalien um (und bei VHDL nutze ich wirklich meist VHDL93).

[Robert K. (Firma: Projektleiter Medizinsoftware) (robident)]

W.S. schrieb:
> Je paralleler, desto weniger
> Gatterlaufzeiten hat man nacheinander

Seit wann gibt es eine graduelle Abstufung der Parallelität?

[W.S. (Gast)]

Schlumpf schrieb:
> Der Töpfer programmiert dann also aus einem Haufen Ton eine schöne Vase
> und der Schmied aus Stahl eine Axt...

Quatsch. Der Töpfer und der Schmied geben dem Zeug nur eine passende 
Form, hauchen ihm aber keine Funktionalität ein. Der Programmierer tut 
das mit seinem FPGA jedoch sehr wohl: es kann anschließend auf 
irgendwelche Inputs intelligent reagieren (hoffentlich, wenn der 
Programierer nicht zu blöd war).



Carl schrieb:
> Ja, das ist in der Tat der gleich Quatsch.

Ähem.. nö, fliegen und schweben sind zwei völlig verschiedene Dinge.



Robert K. schrieb:
> Seit wann gibt es eine graduelle Abstufung der Parallelität?

Die gibt's schon immer. Wenn du dank LUT nur ein vierfach-AND haben 
kannst, im konkreten Falle aber ein Fünffach-AND brauchst, dann mußt du 
eben zwei LUT's hintereinander schalten. Das kostet Durchlaufzeit.



Lothar M. schrieb:
> Darum soll es hier im Thread aber bitte nicht gehen.

Lothar, es geht hier tatsächlich darum. Denn der TO braucht eine bessere 
Einführung als diejenigen, die man im Netz allenthalben so findet. VHDL 
könnte weitaus besser und verständlicher sein, wenn es eben bessere und 
sinnvollere, logischere und didaktisch verständlichere Lern-Unterlagen 
dazu gäbe.

Das ist der eigentliche Punkt. Hätte Fred eine bessere Literatur 
gefunden, dann hätte er hier garnicht erst angefragt.

W.S.

[Weltbester FPGA-Pongo (Gast)]

W.S. schrieb:
> Lothar, es geht hier tatsächlich darum. Denn der TO braucht eine bessere
> Einführung als diejenigen, die man im Netz allenthalben so findet. VHDL
> könnte weitaus besser und verständlicher sein, wenn es eben bessere und
> sinnvollere, logischere und didaktisch verständlichere Lern-Unterlagen
> dazu gäbe.

Wenn ich den thread so überfliege, dann braucht der TE und viele andere 
auf diesem level eine Berufsberatung. Wer solche Fragen stellt, ist für 
das Thema einfach nicht geeignet. Es macht keinen Sinn, sich VHDL 
reinzuziehen und dann zu hoffen, dass man irgendwie ein Verständnis 
aufbaut. Das Verständnis kommt von Alleine wenn man Hardware verstanden 
hat. Die ist nämlich immer parallel. Jedes Getriebe ist parallel.

[Schlumpf (Gast)]

W.S. schrieb:
> Quatsch. Der Töpfer und der Schmied geben dem Zeug nur eine passende
> Form, hauchen ihm aber keine Funktionalität ein. Der Programmierer tut
> das mit seinem FPGA jedoch sehr wohl: es kann anschließend auf
> irgendwelche Inputs intelligent reagieren (hoffentlich, wenn der
> Programierer nicht zu blöd war).

Schön, wenn das deine persönliche Definition von Funktion ist.
Aber ich würde das nicht so allgemein hinstellen.
Ne Axt hat für mich definitiv eine Funktion.

Aber ich wollte ja nur anhand eines Beispiels aufzeigen, wie absurd 
deine Defintion ist. Und sie wird durch diese weitere Definition auch 
nicht besser.

Dann baue ich halt aus lauter Rohteilen eine Dampfmaschine.. Sorry, ich 
programmiere eine Dampfmaschine.
Oder hat die gemäß deiner Definition auch keine Funktion?

Der Uhrmacher programmiert natürlich auch die mechanische Uhr usw..

Deine Definition ist Blödsinn. Sorry!

[Schlumpf (Gast)]

Und wenn ich einen Schaltplan und Layout erstelle und daraus ne 
Leiterplatte baue, dann ist das auch programmieren? Nicht dein Ernst, 
oder?
Ich hauche hier schließlich eine Funktion ein.
Erfüllt also alle Kriterien deiner Definition.
Also wenn ich in der Firma sage, dass ich den Schaltplan noch fertig 
programmiere, dann zeigen sie mir den Vogel.


Der Vergleich trifft es sogar am Besten, was man beim FPGA auch macht.

Oder kommt jetzt der Nachtrag, dass deine Definition natürlich nur für 
integrierte Schaltungen gilt?
Dann bist du aber maximal weit weg von deiner ursprünglichen, sehr 
allgemeinen Definition.

W.S. schrieb:
> Einem Stück Materie, das ursprünglich garnichts kann, eine
> Funktionalität beizubringen, das nennt man Programmieren.

[J. S. (engineer)]

> W.S. schrieb:
>> Einem Stück Materie, das ursprünglich garnichts kann, eine
>> Funktionalität beizubringen, das nennt man Programmieren.
Im konkreten Fall ja, im allgemeinen Fall nicht unbedingt. Das Wort 
"Programmieren" würde ich schon dahingehend eingrenzen, dass es für 
programmierbare Hardware und für Software gilt.

Schlumpf schrieb:
> Also wenn ich in der Firma sage, dass ich den Schaltplan noch fertig
> programmiere, dann zeigen sie mir den Vogel.
Wenn man es sachlich auffasst, dass das Wort "Programm" einfach 
"Vorschrift" heißt und verstanden hat, dass VHDL eine Software 
programmiert, nämlich die Schaltplanerstellungssoftware, die ich 
"virtueller Layouter nennen", dann wäre das Pflichtenheft deiner 
Baugruppe (und natürlich nicht die Baugruppe selbst) die Analogie zum 
VHDL. Ob man das Erstellen eines PHs als "Programmierung des 
Entwicklers" bezeichnen sollte, sei dahingestellt. Abstrahiert gedacht 
würde es stimmen :-)

[J. S. (engineer)]

Man braucht IMHO nicht unbedingt eine VHDL-Anleitungen, um etwa 
"parallel zu denken" oder dort einzusteigen. Ich habe keine gebraucht, 
viele Kollegen, die ich kenne, haben keine gebraucht und ich behaupte, 
dass andere VHDL-Experten hier im Forum - einschließlich Lothar - 
ebenfalls keine Anleitung gebraucht haben. Allenfalls braucht es mal 
einen guide, um eine Syntax nachzulesen, für einen Befehl, den man alle 
3 Jahre mal braucht. Functions oder die Formulierung eines konkreten 
Schleifenkontrukts mit generate sind solche Dinge. Die braucht man aber 
die erste Zeit nicht.

Vor allem braucht man sie zum Erlernen des Konzeptionierens nicht. Ich 
bin nach wie vor der Meinung dass der Zugung über die Sprache in dem 
Fall eher hinderlich ist. Ich habe mir das allererste mal einfach das 
VHDL eines Beispiels angesehen und bis auf wenige Punkte sofort 
verstanden, wofür die Befehle sind. Das ist mehr oder weniger 
selbsterklärend. Dieses Abstraktionsvermögen muss vorhanden sein. Die 
Sprache darf keine echte Anforderung sein.

Es kommt darauf an, ob man verstanden hat, wie digitale Logik 
funktioniert und wie der Zusammenhang zwischen diesen elementaren 
Funktionen ist. Speicher, Multiplexer, Decoder, Zähler und Kombinatorik 
müssen verstanden sein. Es müssen Konzepte her, wie man damit Rechner, 
Zähler, Steuereinheiten, Abläufe und Rechenpipelines baut. Dann ist es 
komplett egal, mit welcher Sprache ich das formuliere oder ob ich es mit 
Blöckchen male.

FPGAs zu bauen, ist wie eine kleine Fertigungsstraße zu bauen. Ein Rad 
muß ins andere greifen. D.h. man muss die Struktur und deren Ablauf 
planen. Dazu braucht man ein Blockdiagramm, Subdiagramme in Hierarchie, 
mehrere Ablaufpläne für die Blöckchen fürs Parallele. Das ist das 
Entscheidende und das geht komplett ohne VHDL.

Die konkrete Fragestellung macht IMO auch nicht so 100%ig. Bei der 
Formulierung von VHDL muss man nicht zwingend "parallel denken". Man 
muss einmal eine Abstraktionsebene nach oben und sich klar machen, dass 
man nicht den Ablauf in einer Schaltung festlegt, sondern eine 
Bauanleitung für die Schaltung scheibt. Die Beschreibung der Funktionen 
(= das Verhalten von Strukturen) erfolgt objektorientiert, ähnlich (ABER 
NICHT GENAU SO!) wie bei C++. Gleichwohl gibt es selbstredend Dinge, in 
die zeitlicher Folge beschrieben werden müssen, damit der Erbauer (die 
Synthesesoftware) richtig arbeitet. Man muss also durchaus sequenziell 
denken.

Ich habe das schon mehrfach geschrieben und wiederhole es nochmal:

VHDL ist eine Sammlung von Arbeitsanweisungen an einen virtuellen 
Schaltungsentwickler. Wenn man sich das vor Augen führt, entfallen schon 
einmal Vorstellungen hinsichtlich der Bedeutung bestimmter Sequenzen, 
d.h. es wird direkt sichtbar, wann es wichtig und wann es unwichtig ist, 
an welcher Stelle man etwas beschreibt. Es ist evident, was bei 
rauskommt, wenn ich eine Schleife schreibe, die den virtuellen 
Entwickler veranlasst, 10x etwas zu tun. Das kann - muss aber nicht - 
dazu führen, dass später der FPGA 10x etwas tut.

[J. S. (engineer)]

Zum anderen Punkt:

VHDL ist meines Erachtens nicht zu restriktiv. Eher im Gegenteil: Es 
wird vielzuviel zugelassen, was zu viele Wege offenlässt. Das dürfte den 
Anfänger dann am Meisten verwirren. Ich erinnere nur an die 
Fragestellung nach dem Sinn von Variablen. Eigentlich klar, wenn man das 
Prinzip verstanden hat, aber in keinster Weise geeignet, das Prinzip zu 
erklären. Auch die Kombination von Verhaltensbeschreibung und Struktur, 
die mangelnde Trennung von Logik und Physik ist stark 
verbesserungswürdig. Dass da Vieles nicht verstanden wurde sieht man an 
der pathologischen Wiederholung der tags "structural" und "behavioral" 
als Architekturname, wobei innen dann brutal drauf los gemixed wird.

Auf dem Programmiersektor hat die Einführung von C++ viel gebracht. 
Während bestimmte, immer wieder benötigte Dinge wie 
Multiprozessarchitekturen, dynamische Prozessabarbeitung, 
Unterbrechbarkeit und Koexistenz mit anderen Programmen in C immer 
händisch und damit von jedem anders realisiert wurden, ist das in C++ 
weitgehend standardisiert und eingepfercht worden. Man braucht nun zwar 
sehr viel mehr Sachwissen und Methodenverständnis, hat aber weniger 
Probleme mit Komplexität und ist viel kompatibler. Vor allem ist man 
besser struktiert, ohne es selber modularisieren zu müssen. Bjarne 
selbst hat dazu ja mal dargelegt, dass dies die ureigenste Intention bei 
der Formulierung von C++ war, abseits der Thematik der später 
vorgeschobenen Objektorientiertheit.

Da die FPGA-Systeme immer größer werden, ist gfs eine Anpassung auch in 
VHDL erforderlich. Ich empfehle "structured VHDL" mit lokalen Modulen 
und eindeutiger Definition von virtuellen und echten Ports, Trennung von 
Anweisungen zur Struktur einerseits und Verhalten andererseits, etc. Den 
Ansatz zum Modularisieren realisieren momentan viele Entwickler, indem 
sie FSMs auslagern, Module stark unterteilen und in unterschiedlichen 
files unterbringen und - soforn sie schlau ist - entsprechend mit den 
Namen der Ports umgehen. Weitere Ansätze wurden von u.a. Gaisler 
geliefert, wobei ich da nicht mir allem d'accord gehe.

Bessere Literatur dazu wäre auf den ersten Blick auch sicher hilfreich. 
Allerdings sehe ich das Problem eher darin, dass es auf der einen Seite 
durchaus gute Literatur zum FPGA-design gibt, auch zum Modellieren und 
zum geschickten Formulieren, bzw spezielle Lösungen anhand von 
Beispielen und starken Bezügen zur Digitaltechnik; - diese aber  von 
Vielen gar nicht genutzt werden. Stattdessen rennen sie ins Internet und 
laden irgendwo irgendwas, was andere mit Halbwissen hochgeladen haben. 
Oft hat dann jemand etwas kopiert, was schon 5mal kopiert wurde. Weil 
die Mittelmäßigen in der Mehrheit sind, verbreitet sich Halbwissen viel 
rasanter und dominiert. Das Thema VHDL und FPGA krankt mihin an dem 
selben Internet-Effekt wie die Medizin: Statt das Thema ordentlich zu 
studieren oder sich wenigstens ein Fachbuch zu holen, informiert man 
sich auf Webseiten mit Sekundärwissen, in Foren in denen Anfänger posten 
und neuerdings sogar auf facebook. Wer mal Zeit hat und Lust hat, kann 
sich ja mal den Spaß machen und in den einschlägigen Gruppen mitlesen. 
Da sind die wahren Lichtgestalten unterwegs. Es dauert nicht mehr lange 
und das Thema FPGA und Digitaldesign ist mit genau so vielen Mythen und 
falschen Pauschallösungen durchsetzt, wie das Thema Audio.

Und nun die Frage der Fragen:

Wie erstellt man eine Bauanleitung für einen analogen Audioverstärker 
und denkt dabei Parallel, sodass später alle Musikdaten von allen 
Kanälen verarbeitet werden können? Und wie wäre das nun bei einem 
digitalen Modell in VHDL?

[J. S. (engineer)]

Hans Hämmerle schrieb:
> Aus ähnlichen Beweggründen beharren Informatiker darauf, das FPGA's
> programmiert werden - damit sie sich auch ohne die mehrjährige
> Ausbildung resp. Befähigungsnachweis als Hardware-Digitalentwickler auf
> FPGA-Stellen bewerben können.

Auch wenn du mit deiner Vermutung nicht ganz realitätsfern bist, was das 
Einstellen von Softwareentwicklern angeht, würde ich doch wirklich 
raten, davon Abstand zu nehmen, andauernd das Wort "Programmieren" als 
Vorgang der Schaltungserstellung im Bereich FPGA zu verneinen.

Ich habe das Thema ja vor Längerem schon aufgriffen, mit anderen 
Editoren in der Wikipedia abgestimmt und nicht ohne Grund so 
eingetragen, wie es derzeit ist. Das ist einhellige Meinung und "widely 
agreed".

Auch wenn bei dem Wort "Programmieren" bei Vielen sofort der 
Programm-Code aufpoppt und der Hardwareentwickler einen Baustein vor 
sich sieht, ist das formal kein Widerspruch, denn der Vorgang des 
Beladens des FPGAs ist ein Programmiervorgang. Dass es eine Hardware 
ist, ist nicht von Belang, da eine Orangensortieranlage und ein Computer 
auch Hardware sind. Wer da einen Widerspruch sieht, hat ein 
Abstraktionsproblem:

Wie oben dargestellt, wird gerade durch die im Vergleich zu C 
umfangreiche(re) Beschreibung einer Schaltung, welche einen Ablauf und 
Struktur enthält, eine Programmierung geleistet, nämlich die der 
Synthesesoftware! Diese ist strukturell und von der Abstraktion her 
erheblich komplizierter, als ein Compiler und erfordert mehr 
Informationen. Diese Information ist a) eine Software und b) ist das 
Vorschreiben Derselben ein Programmiervorgang. Diese Software erzeugt im 
Übrigen auch keine Hardware, sondern erst mal eine Software, nämlich 
eine Netzliste.

Der Weg von VHDL zum FPGA ist also sogar weiter, als der von C zum 
Prozessor und er ist indirekter, weil eine virtuelle Schaltung erzeugt 
wird, die so nirgends existiert, sondern von einer weiteren Software 
erst in Hardware umgesetzt werden muss, z.B. in einen ASIC oder einen 
FPGA oder PLD. Es wird also nicht einmal eine direkte Hardware erstellt 
sondern nur das logische Abbild der Funktion einer Hardware. Das, was 
wir als Multiplexer oder Vergleicher sehen, als delay Flip Flop oder 
Registerbank, wird in Gleichungen überführt, um sie mit einer ganz 
anderen Hardware zu emulieren. Das muss man sich immer wieder 
klarmachen. Und selbst wenn man dies alles weglässt, und wirklich die 
LUTs einstellt, wäre dies ein Programmiervorgang, wie wir es vor 
("huch!) fast 30 Jahren an der Uni gelernt haben, mit PALs und GALs und 
mit EPROMs. Das war richtig harte Hardware und die wurde -> 
Programmiert. Und die Genrad-Software, in die wir die Gleichung 
eingetippt hatten, wurde auch -> Programmiert.

Es ist aber noch aus noch einem weiteren Punkt richtig:

Hinzu kommt, dass FPGAs heute strukturell so kompliziert sind, wie ein 
komplettes EVAL-board mit UC. Auch bei einem kompletten System wie einem 
Arduino spricht man typisch vom "Programmieren." Und letztlich haben 
FPGAs eben auch Softcores und Hardcores drin. Sowohl deren Ablauf (in C) 
als auch deren Verschaltung wird "programmiert".

Du solltest aber jetzt nicht traurig sein, dass die Softies "gewonnen" 
haben, denn die reine C-Geschichte ist kein bisschen qualifizierend für 
ein FPGA design, auch wenn das manch einer meint. Genausowenig ist aber 
auch die Kenntnis von VHDL ausreichend. Siehe Argumentation weiter oben.

[J. S. (engineer)]

Carl schrieb:
> z.B. Was sollen Empfindlichkeitslisten? Ich brauche sie nicht.

Der Sinn klingt z.B. in dem Beitrag über dem deinen an. Diese Liste ist 
genau dafür da, den Simulator zu steuern. Letztlich sind es die 
Variablen in der Simulationsoftware, die nach dem Compilieren über 
bleiben und deren Veränderung einen Funktionsaufruf auslösen, damit ein 
neues Simuergebnis berechnet wird. Das sind ja auch function calls in C. 
Das muss irgendwo mal getrackt und in einer Tabelle referenziert werden, 
damit die SW dies real dann auch tut. Inzwischen geht es einfacher, weil 
es in C++ formuliert wird und dann einfach einen thread generiert. Oder 
sagen wir, generieren könnte, wenn die SW schlau genug wäre. ModelSIM 
hat das immer noch nicht so recht drauf, wie ich meine.

Diese Liste kann ferner benutzt werden, um einfache Simulationen zu 
erzeugen, z.B. schreibt man einen Takt oder einen Pseudotakt (I2C) rein 
und triggert damit ein Datenformat, also eine Stimulation z.B. Auch ein 
FF kann damit am Einfachsten beschrieben werden, indem die Zuweisung Y 
<= X immer ausgeführt wird, wenn der Takt kommt. Irgendwelche Waits kann 
man sich dann sparen. Das hat Einfluss auf die Abarbeitung durch die SW. 
Von den Geschichten gibt es einige, auch Fachliteratur dazu.

[Carl (Gast)]

Jürgen S.:
>Der Sinn klingt z.B. in dem Beitrag über dem deinen an. Diese Liste ist
>genau dafür da, den Simulator zu steuern.
Ja, aber laut Buch
Beitrag "Re: VHDL Denken-wie?"
kann man mit- oder ohne Empfindlichkeitslisten "programmieren". Laut den 
Buchseiten ist eine Mischung beider Varianten nicht erlaubt.

Es scheint mir einen Paradigmenwechsel beim Coding zu geben: Der Trend 
geht weg von der Empfindlichkeitsliste hin zu

process
begin ..
wait until rising_edge( clk );
...

anstatt

process(clk)
begin
if (clk'event and clk='1') then
..

[Markus F. (mfro)]

Carl schrieb:
> Es scheint mir einen Paradigmenwechsel beim Coding zu geben:

Es dürfte helfen, sich mal die Implementierung der 
rising_edge()-Funktion in der std_logic_1164 Lib anzuschauen, dann wirst 
Du merken, daß von "Paradigmenwechsel" eigentlich keine Rede sein kann. 
So groß ist der Unterschied nun nicht. rising_edge() ist halt präziser 
gegenüber den std_logic 'Halbzuständen'.

Das Ganze ist wohl der Unfähigkeit von frühen Synthesewerkzeugen zu 
verdanken, die anfangs weder wait-Statements synthetisieren noch mit 
std_logic umgehen konnten.

Die 'if' (für Prozesse bzw. Hardware mit asynchronem Reset oder CLR) und 
'wait'-Formen haben weiterhin ihre Berechtigung (unabhängig davon, ob 
man rising_edge() benutzt oder explizit ausformuliert).

[C. A. Rotwang (Gast)]

Jürgen S. schrieb:
> Hans Hämmerle schrieb:
>> Aus ähnlichen Beweggründen beharren Informatiker darauf, das FPGA's
>> programmiert werden - damit sie sich auch ohne die mehrjährige
>> Ausbildung resp. Befähigungsnachweis als Hardware-Digitalentwickler auf
>> FPGA-Stellen bewerben können.
>
> Auch wenn du mit deiner Vermutung nicht ganz realitätsfern bist, was das
> Einstellen von Softwareentwicklern angeht, würde ich doch wirklich
> raten, davon Abstand zu nehmen, andauernd das Wort "Programmieren" als
> Vorgang der Schaltungserstellung im Bereich FPGA zu verneinen.
...
> Du solltest aber jetzt nicht traurig sein, dass die Softies "gewonnen"
> haben, denn die reine C-Geschichte ist kein bisschen qualifizierend für
> ein FPGA design, auch wenn das manch einer meint. Genausowenig ist aber
> auch die Kenntnis von VHDL ausreichend. Siehe Argumentation weiter oben.

Weder bin ich traurig, noch haben die Softies gewonnen. Im Teamwork und 
Arbeitsteilung gibt es keine einzelnen Gewinner...
Und ich weiss, das 'programmieren' also die Erstellung/Verteilung eines 
Programmes/Ablaufs auf tausende Weise realisiert werden kann: 
Web/Textilband-maschinen wurden mit gelochten Holzbrettern programmiert, 
ein Rundfunk-programm-direktor entwirft sein Rundfunkprogramm durch 
Zuruf zur Sekretärin, der Mechaniker feilt seine Nockenwellen für die 
Ventilsteuerung,...

https://de.wikipedia.org/wiki/Datei:CNAM-IMG_0527.jpg
https://de.wikipedia.org/wiki/Datei:Nockenwelle_ani.gif

Das Problem ist, das manche meinen man könnte das Programieren auf 
Softwareengineering, also die Erstellung textueller Ablauf-Kommandos 
reduzieren; und textuell ist alles gleich (BASIC, 
Mnemonics,C,Latex,HTML, Bewerbungsanschreiben).
Aber das stimmt in zweierlei Hinsicht nicht:
-so wie man kein vernünftiges Gespräch mit nem Buschneger in 
Schwarzafrika führen kann, wenn man lediglich seinen persönlichen 
Grossstadt-Ghetto-Slang anhand eines Lexik-LUT-Mappings in isiXhosa 
übertragt, sowenig kann man 'FPGA-vernünftiges' VHDL schreiben, wenn man 
lediglich ein Syntax/Lexik Mapping aus (Windows-App- aber auch 
lowlevel-embedded-C) vornimmt.

-zum FPGA-Entwurf gehört meiner Meinung nach auch die Inbetriebnahme/ 
Debugging am Target (Hardware) und damit verlässt man endgültig die 
Tätigkeit 'Textuelle Beschreibungen erstellen.'

Vielleicht ist das ja der Hauptpunkt, VHDL-Denken heisst eben ein 
FPGA-design am Target debuggen zu können. Aber vielleicht meint ja der 
TO ohnehin das zum VHDL und sonstigen Programmieren kein 
Debuggen/Verifizieren dazu gehört - weil richtige Programmiere - machen 
keine Fehler die man debuggen muesste. Dem entgegengesetzt die 
Lebensweisheit das auch Softwareentwickeln nur zu einem geringen Teil 
"Programmieren/Codieren" ist, aber zu einem größeren  Anteil 
Testen/berichtigen/Dokumentieren. Und auch wenn man das Debugging 
ausschliesslich am Simulator ausführt, auch dazu muss man 
Test/Debuggstrategien benutzen, die nicht zum Reportoire eines 
'Programm-Code-Erstellers' gehen wie Debug-Instrumentierung, 
Error-Injektion, Test-covery ermittlung, Absicherung clock domain 
crossings, ...

[Markus F. (mfro)]

C. A. Rotwang schrieb:
> Und auch wenn man das Debugging
> ausschliesslich am Simulator ausführt, auch dazu muss man
> Test/Debuggstrategien benutzen, die nicht zum Reportoire eines
> 'Programm-Code-Erstellers' gehen wie Debug-Instrumentierung,
> Error-Injektion, Test-covery ermittlung, Absicherung clock domain
> crossings, ...

Genau das läuft aber meist deutlich mehr auf "Programmieren" raus als 
der eigentliche Schaltungsentwurf ;)

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Carl schrieb:
> Ja, aber laut Buch
> Beitrag "Re: VHDL Denken-wie?"
> kann man mit- oder ohne Empfindlichkeitslisten "programmieren". Laut den
> Buchseiten ist eine Mischung beider Varianten nicht erlaubt.
Eine Sensitivliste ist ganz einfach nur ein "herausgezogenes wait 
until".

Du selbst hast es aufgezeigt, dabei aber noch zwei verwirrende Haken 
geschlagen und einen getakteten Prozess in zwei unterschiedlichen 
Varianten geschrieben. Nimm einfach mal einen kombinatorischen Prozess, 
dann ist das hier...:

process (a) begin
  :
  :
end process;

...exakt das selbe wie das hier:

process begin
  wait until a;
  :
  :
end process;

Allerdings bietet im Fall "kombinatorischer Prozess" die Sensitivliste 
einen Vorteil, denn wie würde man sowas mit wait until schreiben:

process (a, b, c, d) begin
  :
  :
end process;

Und das besonders, wenn a..d unterschiedliche Typen sind?

Jürgen S. schrieb:
> Man braucht IMHO nicht unbedingt eine VHDL-Anleitungen, um etwa
> "parallel zu denken" oder dort einzusteigen.
Korrekt. Der zielführende Weg ist nicht "VHDL-->Hardware" ("wie 
programmiere ich mit VHDL meine Hardware?"), sondern "Hardware-->VHDL" 
("wie beschreibe ich meine Hardware mit VHDL?"):
ich habe meine Hardware (oder wenigstens eine Struktur, von der ich 
weiß, dass ich sie mit ein wenig Zeit in Hardware umsetzen könnte) im 
Sinn, und beschreibe dann diese Struktur, diese Hardware mit VHDL.

Dass der Vorgang, den ich dabei auf meinem PC und meiner Zielhardware 
durchführe irgendwie genau gleich aussieht, wie das, was der 
Softwarekollege macht (Editieren, Übersetzen, Aufspielen, Testen,...), 
und dass hinterher ein programmierbarer Baustein mit dem Ergebnis 
meiner Arbeit programmiert wird, ist nur der Doppeldeutigkeit der 
Sprache geschuldet.

Um nachfolgenden Missverständnissen aus dem Weg zu gehen, verwende ich 
für meinen Teil der Arbeit am FPGA den Begriff "Beschreibung" statt 
"Programmierung":
ich programmiere meine gewüschte Funktion mit VHDL ins FPGA. Und 
hinterher programmiert der Softwarekollege anhand meines Datenblatts 
zum Registersatz dann auch das bereits programmierte FPGA: er 
programmiert Initialwerte und Daten in die Register, die ich ihm durch 
meine vorhergehende Programmierung zur Verfügung gestellt habe. Und 
wenn dann jemand sagt "da muss das Programm angepasst werden", dann 
fühlen wir uns beide angesprochen...

[Hallo (Gast)]

"FPGA programmieren" bezeichnet ansich ja nichts anderes als das fertige 
Design auf/ins Fpga zu laden ("flashen"). Die eigentliche Arbeit ist 
digitaler Schaltungsentwurf und diese "Denke"/Verständnis braucht man. 
Dieselbe Denke braucht man auch beim ASIC und da würde niemand auf die 
Idee kommen es programmieren zu nennen.

Am besten lernt man  IMO indem man sich ein paar TTL Bausteine nimmt und 
etwas am Steckbrett zusammenstöpselt und dann dieselbe Schaltung in der 
HDL seiner Wahl nachbaut.

[Hans Hämmerle (Gast)]

Markus F. schrieb:
> C. A. Rotwang schrieb:
>> Und auch wenn man das Debugging
>> ausschliesslich am Simulator ausführt, auch dazu muss man
>> Test/Debuggstrategien benutzen, die nicht zum Reportoire eines
>> 'Programm-Code-Erstellers' gehen wie Debug-Instrumentierung,
>> Error-Injektion, Test-covery ermittlung, Absicherung clock domain
>> crossings, ...
>
> Genau das läuft aber meist deutlich mehr auf "Programmieren" raus als
> der eigentliche Schaltungsentwurf ;)

Nö, debugging ist kein Monopol der Programmiererkaste, jeder muss die 
Kunst "Fehler erkennen, beheben und dabei besser werden" beherrschen.
Und in der VHDL-Entwicklung treten auchschon mal Fehler auf die ein 
Softwerker nicht mal von seinen Alpträumen her kennt.

[Schlumpf (Gast)]

Lothar M. schrieb:
> Korrekt. Der zielführende Weg ist nicht "VHDL-->Hardware" ("wie
> programmiere ich mit VHDL meine Hardware?"), sondern "Hardware-->VHDL"
> ("wie beschreibe ich meine Hardware mit VHDL?"):
> ich habe meine Hardware (oder wenigstens eine Struktur, von der ich
> weiß, dass ich sie mit ein wenig Zeit in Hardware umsetzen könnte) im
> Sinn, und beschreibe dann diese Struktur, diese Hardware mit VHDL.

100%ige Zustimmung!

[Yalu X. (yalu) (Moderator)]

Sich die ganze Angelegenheit als eine aus einzelnen Digital-ICs wie
bspw. Gatter, Flipflops, D-Register, Addierer usw. vorzustellen, ist
zumindest am Anfang sehr hilfreich. Einer, der vor seinem Einstig in die
FPGA-Technik schon Schaltungen aus Einzel-ICs entwickelt hat, wird
deswegen kaum Schwierigkeiten haben, sich die "FPGA-Denkweise"
anzueignen. Obwohl ich kein studierter Elektroingenieur, sondern nur
Elektronikbastler bin, hat sich für mich die Frage nach der richtigen
Denkweise im Zusammenhang mit FPGAs nie gestellt. Sie war einfach da.

Auch später ist diese Hardware-Denkweise für viele Anwendungen (bspw.
alles, was mit Kommunikationsschnittstellen zu tun hat) nützlich. Bei
der Implementierung sehr komplexer Algorithmen wird man versuchen,
zusätzlich noch eine abstraktere Sicht auf die Dinge zu bekommen. Das
ist ähnlich wie in der klassischen Softwareentwicklung, wo man auch
irgendwann aufhört, nur in Schritt-für-Schritt-Abläufen, Flussdiagrammen
u.ä. zu denken. Dieses abstraktere Denken kommt aber mit wachsender
Erfahrung ganz von selber. Man kann sie leider auch nur schwer an andere
vermitteln, da jeder seine individuell auf den eigenen Kopf abgestimmte
Denkmodelle entwickelt. Deswegen bringt es auch wenig, Bücher darüber zu
lesen (falls es solche überhaubt gibt).


Zur Diskussion, ob man die Anwendungsentwicklung auf Basis von FPGAs als
"Programmieren" bezeichnen kann oder nicht:

Eigentlich ist sie müßig, da es keine allgemein akzeptierte Definition
des Begriffs "Programmieren" gibt. Trotzdem ein paar Gedanken dazu:

Lassen wir einmal das Aufspielen der Konfiguration auf das FPGA, die man
auch als Programmieren bezeichnet, außen vor und beschränken uns auf den
Entwicklungsprozess, der zu dieser Konfiguration führt. Kann man diesen
Entwicklungsprozess als Programmieren bezeichnen?

Viele setzen Programmieren mit dem Schreiben von Software für einen
klassischen Prozessor in einer imperativen Sprache wie bspw. Basic,
Pascal, C oder Java gleich. Die Programmierung besteht hier aus der
Festlegung der einzelnen Rechenschritte und deren Abfolge bei der
Ausführung. Nach dieser Definition wäre die FPGA-Entwicklung kein
Programmieren.

Aber auch die Entwicklung in einer deklarativen Sprache wie bspw.
Prolog, Haskell und LabView wäre danach kein Programmieren. Ebenso
könnte danach die Entwicklung einer Software für massiv-parallele
Computer, bei der ein Großteil der Entwicklungsarbeit nicht in die
Programmierung der einzelnen Rechnerknoten, sondern in die Festlegung
der Vernetzung derselben sowie des Datenaustauschs zwischen denselben
fließt, nur eingeschränkt als Programmieren bezeichnet werden.

Da die im vorigen Abschnitt genannten Beispiele gemeinhin aber dennoch
als Programmierung angesehen wird, muss die Begriffsdefinition passend
dazu etwas weiter gefasst werden.

Nun ist es aber so, dass

- ein FPGA nicht anderes ist als ein extrem massiv-paralleler Computer
  (wenngleich mit sehr primitiven Rechnerknoten) und

- VHDL eine deklarative Sprachen ist, in der Anwendungen für diesen
  Computer geschrieben werden.

Warum sollte man also die Entwicklung in VHDL nicht als Programmieren
bezeichnen?

Ich persönlich finde in diesem Zusammenhang "programmieren" jedenfalls
treffender als bspw. "designen" (insbesondere in deutschsprachigem
Kontext).

[Schlumpf (Gast)]

Yalu X. schrieb:
> Da die im vorigen Abschnitt genannten Beispiele gemeinhin aber dennoch
> als Programmierung angesehen wird, muss die Begriffsdefinition passend
> dazu etwas weiter gefasst werden.

Bemüht man mal den Duden, dann beutet das Verb "programmieren" auch:
"Von vornherein auf etwas festlegen". (Beispiel: die Fußballmannschaft 
ist auf Erfolg programmiert)
Insofern programmiert man in VHDL, wenn man damit eine Struktur 
festlegt.

Yalu X. schrieb:
> Aber auch die Entwicklung in einer deklarativen Sprache wie bspw.
> Prolog, Haskell und LabView wäre danach kein Programmieren.

Na ja, in Labview wird ein step-by-step Ablauf programmiert. Also ein 
Programm erstellt. Wenn auch in einer grafischen Oberfläche, die den 
Anschein erweckt, hier würde irgendetwas parallel statt finden.
Aber am Ende wird daraus ein Programm, welches schrittweise auf einem 
Rechner abgearbeitet wird. (Ja ich weiss, dass es auch FPGA-Karten von 
NI gibt)

Letztendlich ist der Begriff auch zweitrangig. Solange jedem kar ist, 
dass er in VHDL kein "Programm" schreibt, dass dann auf einem FPGA 
abgearbeitet wird, sondern eine Schaltung beschreibt, die in einem FPGA 
implementiert wird.

Man könnte hier vermutlich bis ans Ende aller Tage diskutieren, ohne zu 
einem Ergebnis zu kommen. Denn tatsächlich richtig im Wortsinn sind 
beide Begriffe.

[Dussel (Gast)]

Schlumpf schrieb:
> Man könnte hier vermutlich bis ans Ende aller Tage diskutieren, ohne zu
> einem Ergebnis zu kommen.
Grundsätzlich ist es ja schon sinnvoll, dass man klarmacht, dass es kein 
klassisches Programmieren ist. Beim Umgang mit Anfängern kann es schon 
sinnvoll sein, das Wort Programmieren zu vermeiden.
Aber in großen Teilen ist die Diskussion das gleiche wie beim 
'Schraubendreher'. Während die einen mit Schraubenziehern tolle Dinge 
bauen, versuchen andere sich mit ihrem begrenzten Wissen hervorzuheben, 
weil sie ja im Gegensatz zur dummen Masse 'wissen', dass Schraubenzieher 
falsch sei.
Ich programmiere auf modernen Hochleistungs-FPGAs Prozessoren, während 
die, die das nicht können, über das Wort Programmieren diskutieren.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Schlumpf schrieb:
> dann beutet das Verb "programmieren"
Es mag schon durchaus sein, das "programmieren" alles Mögliche bedeutet. 
Aber der Begriff ist eben für den (sagen wir mal beispielsweise) 
"Betriebswirt" mit einer ziemlich speziellen Vorgehensweise vorbelegt. 
Und auch für Softwareentwickler ist das Wort "programmieren" sehr mit 
einer bestimmten Arbeitsstrategie (die nach meiner Beobachtung 
erstaunlich viel mit "Try&Error" zu tun hat) verwandt.

Und diese allgemein bekannten und mit dem Wort "programmieren" 
verbundenen Denkweisen und Strategien führen eben bei der 
FPGA-Entwicklung viele in die Irre. Einige davon tauchen dann hier mit 
ihren Fragen nach syntaktischen Feinheiten auf und/oder klammern sich an 
formalen Definitionen der Sprache fest. Ganz nach dem Motto: "Wenn ich 
diese Zeile dann fehlerfrei durch den Compiler/Synthesizer bekomme, dann 
muss das aber laufen!"

[Schlumpf (Gast)]

Ich stimme dir 100%ig zu, Lothar und sehe es genau so.

[Hans Hämmerle (Gast)]

Schlumpf schrieb:

> Bemüht man mal den Duden,

Bemüh mal lieber ein Wörterbuch der Herkunfstregion:
https://www.merriam-webster.com/dictionary/program

da findet sich:

b : to enter in a program
2 : to work out a sequence of operations to be performed by (a 
mechanism, such as a computer) : to provide with a program


Danach ist bereits das blosse Eingeben von Befehlen 'programmieren', 
also auch das 'Brennen eines Flash-Images'. Es kann aber auch der 
anspruchsvollen Entwurf einer Ablaufsteuerung bedeuten.

Insofern deckt das Berufsbild des Programmieres Tätigkeiten von IQ=94 
(Maschinist) bis IQ=130 (Ingenieur) ab. Der "Programmierer" wird 
übrigens bei IQ=110 einsortiert: 
https://luismanblog.wordpress.com/2017/04/21/welche-iq-sind-notwendig-um-bestimmte-berufe-ausfuhren-zu-konnen/

[Markus F. (mfro)]

Hans Hämmerle schrieb:
> Insofern deckt das Berufsbild des Programmieres Tätigkeiten von IQ=94
> (Maschinist) bis IQ=130 (Ingenieur)

Uiuiui.

Hochmut kommt vor dem Fall.

Ich kenne Ingenieure mit IQ deutlich unter 94 ebenso wie Maschinisten 
mit IQ > 130.

[Hans Hämmerle (Gast)]

Markus F. schrieb:
> Hans Hämmerle schrieb:
>> Insofern deckt das Berufsbild des Programmieres Tätigkeiten von IQ=94
>> (Maschinist) bis IQ=130 (Ingenieur)
>> 
https://luismanblog.wordpress.com/2017/04/21/welche-iq-sind-notwendig-um-bestimmte-berufe-ausfuhren-zu-konnen/
>
> Uiuiui.
>
> Hochmut kommt vor dem Fall.

Nix Hochmut - Statistik -> folge dem Link.

[W.S. (Gast)]

Lothar M. schrieb:
> Der zielführende Weg ist nicht "VHDL-->Hardware" ("wie
> programmiere ich mit VHDL meine Hardware?"), sondern "Hardware-->VHDL"
> ("wie beschreibe ich meine Hardware mit VHDL?"):
> ich habe meine Hardware (oder wenigstens eine Struktur, von der ich
> weiß, dass ich sie mit ein wenig Zeit in Hardware umsetzen könnte) im
> Sinn, und beschreibe dann diese Struktur, diese Hardware mit VHDL.


Genau DAS ist eigentlich die komplette Sinnenverwirrung des Lesers.

Damit das tief genug einsinkt:

"Hardware-->VHDL" ist FALSCH
"Idee-->VHDL-->Toolchain-->Hardware" ist RICHTIG

Du hast eben NICHT "deine Hardware.." im Sinn - sondern:

Du hast eine Idee, also eine Vorstellung über eine Funktionalität in 
deinem Sinn. Das ist es, was du hast.

Und diese Idee willst/mußt du auf eine Weise ausdrücken, so daß eine 
Toolchain sie in eine Struktur kompilieren kann, die einem Stück 
Silizium eingeprägt, selbiges dazu bringt, deine Idee in die Tat 
umzusetzen.

Du kannst dafür einen Schaltplan zeichnen oder deine Idee mit einer 
passenden Programmiersprache ausdrücken.

Korrekterweise müßte man sowas wie VHDL als 
Funktionsbeschreibungssprache oder Ideenbeschreibungssprache bezeichnen 
- aber dediziert NICHT als Hardwarebeschreibungssprache, denn das ist 
das Allerunlogischste, was es gibt. Siehe oben. Und das verwirrt jeden 
Anfänger!

Hardware würde man etwa so beschreiben:
Außen gibt es Pins, daran angeschlossen I/O-treiber, daran eine 
Schaltmatrix und quer über den Chip verteilt ganz viele LUT's... - Das 
wäre eine Hardware-Beschreibung und du merkst selber, wie ausgesprochen 
albern sowas wäre.

Und es hat auch überhaupt nichts mit dem Zweck von 
Verilog/VHDL/Schematics/Abel/Wahrheitstafeln/ sonstigen 
Logik-Formulierungen zu tun. Diese dienen zum Formulierungen von Ideen 
zum Zwecke deren Umsetzung in Hardware.

Genau deshalb mahne ich ja hier wiederholt an, in den Ausführungen 
logisch korrekt zu sein und sich um wirklich bessere Einführungen in die 
betreffenden Programmiersprachen zu kümmern. Angesichts deines hier von 
mir kritisierten Beitrages sehe ich eine erhebliche Notwendigkeit 
dafür.



Yalu X. schrieb:
> Sich die ganze Angelegenheit als eine aus einzelnen Digital-ICs wie
> bspw. Gatter, Flipflops, D-Register, Addierer usw. vorzustellen, ist
> zumindest am Anfang sehr hilfreich. Einer, der vor seinem Einstig in die
> FPGA-Technik schon Schaltungen aus Einzel-ICs entwickelt hat, wird
> deswegen kaum Schwierigkeiten haben, sich die "FPGA-Denkweise"
> anzueignen.

Das war und ist auch nicht im Geringsten angezweifelt worden.

Es ist ganz klar, daß jemand, der in seinem Leben schon mal 
Digitalelektronik mit TTL gemacht hat, und jemand, der sich wenigstens 
vorstellen kann, in einem FPGA ein integriertes Gegenstück zur 
Leiterplatte mit TTL drauf vor sich zu haben, die Angelegenheit rein 
sachlich von Anfang an richtig versteht.

Worum es hier geht, ist die Schwierigkeit, mit VHDL klarzukommen: "ich 
bin VHDL Anfänger und lese mich momentan in die Materie ein."

Hier geht es nicht um's Verstehen von FPGA's, sondern um die noch immer 
offensichtlich zu miese Literatur zum Verstehen von und dem richtigen 
Umgang mit VHDL.

Viele Leute wissen, was sie tun wollen und können das auch korrekt 
mittels Stromlaufplan ausdrücken, sie finden bloß keinen Zugang dazu, 
ihre Idee in VHDL auszudrücken.

Also schreibt lieber eine wirklich didaktisch gute und logisch 
aufgebaute Einführung anstatt euch hier darin zu ergehen, daß man ja 
selbst (damals..) durch schieres Draufgucken bereits die Sprache 
verstanden hatte und dieses auch von nachfolgenden Generationen 
erwartet.

Ein Wort noch zum Schluß: Es gibt in eigentlich allen beruflichen 
Sparten eine mit der Zeit wachsende Betriebsblindheit. Man hat sich an 
Dinge gewöhnt und hält sie mit Inbrunst für völlig selbstverständlich, 
obwohl sie keineswegs selbstverständlich sind, sondern lediglich aus 
einem ursprünglichen Agreement hervorgegangen sind.

Sich dessen nicht bewußt zu sein wie grad hier der Lothar gezeigt hat, 
ist für das Heranführen von Nachwuchs sehr hinderlich, weil unlogisch 
und verwirrend. Vorsicht! Betriebsblindheit trifft irgendwo jeden mal - 
auch mich. Eine Praktikantin hatte mich mal korrigiert, dahingehend, daß 
ich ja doch wohl "Meßgröße" gemeint hätte, als ich lustig von "Meßwert" 
geredet hatte. Sowas passiert garantiert jedem mal.

Ich halte es auch für sehr schlecht, mit "das ist hier eben so" zu 
argumentieren - stattdessen sollte es entweder mathematisch hergeleitet 
werden oder (wo das fehlschlägt wie z.B. in C) ganz klar herausgestellt 
werden, daß es eine Willkür war, dieses Ding so festzulegen, also ein 
(damaliges) Agreement vor sich zu haben.


W.S.

[J. S. (engineer)]

W.S. schrieb:
> Korrekterweise müßte man sowas wie VHDL als
> Funktionsbeschreibungssprache oder Ideenbeschreibungssprache bezeichnen
> - aber dediziert NICHT als Hardwarebeschreibungssprache, denn das ist
> das Allerunlogischste, was es gibt.

Dem Punkt mit der Ideensprache stimme ich zu, daher stelle ich ja das 
VHDL immer auf das Level eines Pflichtenheftes, welches die zu 
entwickelte Hardware beschreibt.

Aber:

Genau wie ein PH enthält VHDL eben nicht nur die Funktion der Hardware, 
sondern eben sehr viel der Struktur.

> Hardware würde man etwa so beschreiben:
> Außen gibt es Pins, daran angeschlossen I/O-treiber, daran eine

Genau das ist ja auch der Fall. Es ist heute vielleicht ein wenig 
versteckter, weil die tools standardisiert IOs verteilen, ohne dass man 
sie angibt. Aber sobald man etwas Spezielles will, muss man diese 
Hardware beschreiben.

VHDL ist eben beides.

> Schaltmatrix und quer über den Chip verteilt ganz viele LUT's... - Das
> wäre eine Hardware-Beschreibung und du merkst selber, wie ausgesprochen
> albern sowas wäre.

Das wird genau so gemacht, wenn man ein FPGA baut. Xilinx tut das so. 
Nur ist FPGA-bauen nicht das, was wir tun, wenn wir VHDL nutzen. Wir 
deklarieren die Funktion einer virtuellen Hardware. Diese wird aber 
ebenso beschrieben.

> Und es hat auch überhaupt nichts mit dem Zweck von
> Verilog/VHDL/Schematics/Abel/Wahrheitstafeln/ sonstigen
> Logik-Formulierungen zu tun. Diese dienen zum Formulierungen von Ideen
> zum Zwecke deren Umsetzung in Hardware.
Ich sehe hier keinen Widerspruch. Ob man Texte in Englisch, Grafiken im 
Editor, oder eine konkrete Formalsprache benutzt, um die Anforderungen 
an eine HW zu beschreiben, ist von der Abstraktion her Wurscht.

[Markus F. (mfro)]

Hans Hämmerle schrieb:
>
> Nix Hochmut - Statistik -> folge dem Link.

Statistik? Den Link habe ich verfolgt und mich nach wenigen Minuten 
angeekelt abgewandt. Der Herr hat mir eine zu meiner persönlichen zu 
stark abweichende (um nicht zu sagen, reichlich verkorkste) 
Weltanschauung.

[Hans Hämmerle (Gast)]

Markus F. schrieb:
> Der Herr hat mir eine zu meiner persönlichen zu
> stark abweichende (um nicht zu sagen, reichlich verkorkste)
> Weltanschauung.

Naja vielleicht passt ja diese Statistik besser in deine Filterblase:
https://qph.fs.quoracdn.net/main-qimg-5265052fdf5881ee4e76b107baccdbf5

Merke: verkorkst sind immer die anderen.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

W.S. schrieb:
> Du hast eine Idee, also eine Vorstellung über eine Funktionalität in
> deinem Sinn. Das ist es, was du hast.
Ich kann dir den Schaltplan von dem, was mir der Synthesizer zu liefern 
hat, nötigenfalls vorher auf ein Blatt Papier malen. Und wenn der 
Synthesizer dann statt der zu erwartenden x Flipflops eine deutlich 
abweichende Zahl y präsentiert, dann hat er meine Beschreibung nicht 
verstanden, ich habe ihm mein Ziel nicht deutlich genug beschrieben.

> Du kannst dafür einen Schaltplan zeichnen oder deine Idee mit einer
> passenden Programmiersprache ...
beschreiben.
Denn wenn ich eine Vorstellung von etwas habe und das jemandem mitteilen 
will, dann programmiere ich den Adressaten nicht, sondern ich beschreibe 
ihm, was mir im Kopf herumgeht.

> Korrekterweise müßte man sowas wie VHDL als
> Funktionsbeschreibungssprache oder Ideenbeschreibungssprache bezeichnen
> - aber dediziert NICHT als Hardwarebeschreibungssprache
Es ist eigentlich eine Systembeschreibungssprache, sie beschreibt die 
Architketur, den Aufbau eines Systems. Allerdings sind diese Systeme 
eben im speziellen Fall elektronische Hardware und nicht z.B. 
Wettersysteme oder Wirtschaftssysteme. Insofern ist das H in VHDL nicht 
falsch.

> Sich dessen nicht bewußt zu sein wie grad hier der Lothar gezeigt hat
Ich habe mich mal geraume Zeit gezwungen, FPGAs zu "programmieren" und 
dieses auch so kommuniziert. Es war verwirrend.

> Also schreibt lieber eine wirklich didaktisch gute und logisch
> aufgebaute Einführung
Du glaubst nicht, wie vielen die Codebeispiele auf meiner HP schon 
weiterhelfen.

[Vancouver (Gast)]

W.S. schrieb:

> "Hardware-->VHDL" ist FALSCH
> "Idee-->VHDL-->Toolchain-->Hardware" ist RICHTIG

Ohoh. Angenommen du willst einen IIR-Filter beschreiben. Was du als Idee 
bezeichnest, ist eine formale (i.e. mathematische) Beschreibung des 
Filters. Die kannst Du direkt in VHDL beschreiben, wenn Du willst. Wenn 
du Glück hast, kommt dabei ein funktionales Simulationsmodell ohne 
definiertes Zeitverhalten heraus, aber ganz sicher keine Struktur aus 
Technologielementen, die auf einen Chip oder FPGA gebacken werden kann.
Um das zu erreichen, brauchst du ein Modell der RTL-Ebene in deinem 
Kopf, und dieses Modell beschreibst du in VHDL.
Im Falle des Filters gibt es ganz nette Tools, die dir einen Teil der 
Arbeit abnehmen, weil Filterstrukturen im Prinzip immer die gleiche 
Architektur haben und sich recht straight-forward aus den Gleichungen 
ergeben (zumindest bei den Standardfällen). Gleiches gilt für 
Zustandsautomaten. Wenn Du aber z.B. einen RISC-V Prozessor 
implementieren willst, bringt dich die formale Beschreibung (in diesem 
Fall die ISA) nicht weiter. Da musst du dir selbst Gedanken machen um 
Pipelinestufen, Steuerwerke, ALUs, Interruptcontroller, 
Speichercontroller. Das nimmt dir kein Tool ab.

Die Vorgehensweise, eine "Idee" in einer Sprache zu formulieren  und 
dann den Make-Button zu drücken, ohne eine blassen Schimmer des 
Maschinenmodells haben zu müssen, das ist der typische Softwareflow. Der 
funktioniert im HDL-Design aber ganz und gar nicht. Das weiß jeder, der 
mal ein FPGA-Design "programmiert" hat und dann aus den Reports des 
Timing-Analyzers herauszufinden versucht, warum das Teil nur bei 5MHz 
funktioniert, aber nicht mehr bei den gewünschten 300. Und an welcher 
Stelle er sein "Programm" jetzt wie anfassen muss. Und woran das liegt, 
dass die asynchronen Eingangssignale einfach nicht korrekt im Register 
landen wollen.

> Hardware würde man etwa so beschreiben:
> Außen gibt es Pins, daran angeschlossen I/O-treiber, daran eine
> Schaltmatrix und quer über den Chip verteilt ganz viele LUT's... - Das
> wäre eine Hardware-Beschreibung und du merkst selber, wie ausgesprochen
> albern sowas wäre.

Üblicherweise versteht man unter einer Hardwarebeschreibung die 
RTL-Ebene. Alles was drunter kommt, ist technologieabhängig. Dummerweise 
musst du aber auch diese Dinge irgendwo beschreiben: Die Pins, die 
verwendeten Treiber, und in vielen Fällen auch einzelne LUTs oder 
spezielle IP-Blöcke. Da kommst du in VHDL nicht drumherum, und in der 
Ausgangsidee tauchen diese Details nirgendwo auf. Das ist nicht albern, 
sondern schlichtweg Teil des Entwurfs.

> Hier geht es nicht um's Verstehen von FPGA's, sondern um die noch immer
> offensichtlich zu miese Literatur zum Verstehen von und dem richtigen
> Umgang mit VHDL.

Hier geht es offensichtlich um das Verstehen von digitalem 
Hardwaredesign. VHDL ist dabei nur die eine Hälfte. Die andere Hälfte 
ist digitale Logik und RTL-Modellierung. Wer nicht weiß, was ein Latch 
oder ein Blockram ist, wird in VHDL keins beschreiben können. Insofern 
ist es vollkommen unsinnig, sich in VHDL einzuarbeiten (nach dem Motto 
yet another programming language) und die andere Hälfte zu ignorieren. 
So wird das numal nix.

[Hans Hämmerle (Gast)]

W.S. schrieb:
> Hier geht es nicht um's Verstehen von FPGA's, sondern um die noch immer
> offensichtlich zu miese Literatur zum Verstehen von und dem richtigen
> Umgang mit VHDL.

Es gibt gute Literatur zu VHDL, schon seit Jahrzehnten, musst halt nur 
die FPGA-Experten nach Empfehlung fragen:
https://www.youtube.com/watch?v=kobf8IOB0oA

Aber bei manchen leser ist halt Hopfen und Malz verloren.

[Schlumpf (Gast)]

W.S. schrieb:
> Genau DAS ist eigentlich die komplette Sinnenverwirrung des Lesers.
>
> Damit das tief genug einsinkt:
>
> "Hardware-->VHDL" ist FALSCH
> "Idee-->VHDL-->Toolchain-->Hardware" ist RICHTIG
>
> Du hast eben NICHT "deine Hardware.." im Sinn - sondern:
>
> Du hast eine Idee, also eine Vorstellung über eine Funktionalität in
> deinem Sinn. Das ist es, was du hast.

Ich hab die Hardware im Sinn. Und du kannst es von mir aus 
Betriebsblindheit nennen.
Spätestens dann, wenn man mit Domaincrossings zu tun hat etc, dann 
sollte man genau wissen, welches Register wann welche Daten kommen.
Sonst wirst du nie zuverlässige Constraints setzen können. Und wenn du 
davon nichts weisst, weil du nur Ideen beschreibst (oder programmierst), 
dann kannst du auch kein Constraints setzen.
Wer die Probleme der digitalen Schaltungstechnik beim Codieren außer 
acht lässt, fällt früher oder später garantiert auf die Nase.

Anderes Beispiel (was gerne gemacht wird):
Asynchroner Reset.
Die Idee, ein Register asynchron zurück zu setzen, ist aus 
Verhaltenssicht eine völlig legitime "Idee". Spielt ja auch funktional 
keine Rolle, ob der Reset asynchron oder synchron erfolgt.
Scheisse ist dann nur, wenn nach jedem 1000ten Reset die FSM (über deren 
Aufbau man natürlich auch nichts weiss, da man ja nur Ideen beschreibt), 
nicht los laufen mag.

Der, der weiss, was er da schaltungstechnisch beschrieben hat, weil er 
die Hardware im Kopf hat, weiss sehr schnell, wo sein Fehler ist.
Der, der Ideen in HDL klimpert und den Rest die Tools machen lässt, 
findet den Fehler nie. Weil er nämlich gar nicht weiss, was er da für 
einen schaltungstechnischen Mist zusammengebaut hat.

Daher sage ich (dass es tief genug einsinkt):

"Hardware-->VHDL": So wird ein Design stabil. Man muss nicht jedes 
Register kennen, aber man sollte eine sehr genaue Vorstellung davon 
haben, welche HARDWARE man mit seinem Code beschreibt.

"Idee-->VHDL-->Toolchain-->Hardware": Typisches Programmierer Vorgehen. 
Kann funktionieren, muss aber nicht. Und spätestens wenn es nicht 
funktioniert, dann steht der arme Kerl blöd da, weil er nicht versteht, 
was er eigentlich tut.

W.S. schrieb:
> Also schreibt lieber eine wirklich didaktisch gute und logisch
> aufgebaute Einführung anstatt euch hier darin zu ergehen, daß...

Man kann mit gefühlt 10% der Möglichkeiten von VHDL jede Hardware 
beschreiben. Man muss die Sprache also nicht in allen Einzelheiten 
erlernen, um gute Designs zu machen.
Ein winziges Subset reicht vollkommen aus. Und das sollte schnell 
erlernt sein. Man muss noch nicht mal wissen, wie man eine Schleife 
programmiert, um jede erdenkliche Hardware beschreiben zu können.

[Peter B. (funkheld)]

Diese Kacke mit dem Modell-Sim ist die größte Sünde auf Erden von dummen 
Professoren und Entwicklern dieses System.

In ASM mach ich auch nicht noch einmal ein Parallelprogramm ob mein 
vorheriges ASM funktioniert.

So etwas muss im Hauptprogramm enthalten sein , so das man das 
Zeitverhalten nicht noch erst mit einem neuen Programm suchen muss wo 
"lachnummer" wieder neue Fehler entstehen können.


Gruss

[FPGA zum Spass (Gast)]

Wer eine Simulation so versteht, der hat doch eh schon verloren.

Das trifft doch höchstens für Simulationen zu, wo ich ein Einzelmodul 
auf Korrektheit prüfe, z.b. einen komplexen Algorithmus.


Eine Simulation hat für mich aber auch noch andere Einsatzgebiete:

a) externe Hardware wie Rams, ICs, externe "Geräte" nachzubilden.
Wie soll das gehen, wenn nicht über die echten FPGA Pins?
Willst du ein SDRam oder DDRRam direkt im Controller nachbilden um zu 
schauen ob der Controller funktioniert?


b) mein (Debug-)Interface ohne Synthese in die "Hardware" zu bringen.
Konkret kann ich meine Applikationssoftware, welche später mit der 
Hardware interagiert, genauso an die Simulation anhängen, was im 
Fehlerfall doch enorm praktisch ist.



Oder mal anders gefragt: wenn du ein ASM Programm hast, das zwingend mit 
anderen kommuniziert und ohne diese Kommunikation genau GARNICHTS tut, 
testest du das auch im Einzelbetrieb?
Oder testest du vielleicht einfach garnichts? Das könnte natürlich 
sein...

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Peter B. schrieb:
> Diese Kacke mit dem Modell-Sim
Das ist jetzt ein schönes Beispiel der "Hardware 
programmieren"-Denkweise. Danke dafür... ;-)

> so das man das Zeitverhalten nicht noch erst mit einem neuen Programm
> suchen muss wo "lachnummer" wieder neue Fehler entstehen können.
Eigentlich ist es schade, dass es sowas wie "Simulation gegen ein Modell 
der Umwelt" für die Software nicht generell gibt. Da muss ich immer 
gleich auf die Hardware und dann mit dem LA messen, um zu sehen, ob mein 
Ablauf und das daraus resultierende zeitliche Verhalten stimmt.

Mit dem Simulator kann ich aber ganz ohne reale Hardware testen, ob 
meine Abläufe passen. Und im https://embdev.net/topic/474612 sieht man 
dann, dass das hinterher 1:1 zur realen Harware passt. Dort hat jemand 
in "Ganzweitweg" auf seiner Hardware mit der selben Beschreibung das 
exakt selbe zeitliche Verhalten wie ich hier ohne diese Hardware. Ich 
kann in diesen Code also eine Änderung einbauen, diese Änderung dann 
durch die Simulation prüfen und weiß dann auch ohne "Ausprobieren" 
genau, dass sich das hinterher auf der Hardware genau so verhalten wird. 
Mir gefällt das.

> In ASM mach ich auch nicht noch einmal ein Parallelprogramm ob mein
> vorheriges ASM funktioniert.
Das, was man in ASM programmieren kann, entspricht bestenfalls der 
Komplexität von einfachen CPLDs. Und die kann man zur Not dann auch ohne 
Simulation debuggen. Man muss dann eben wie bei der Software ein 
Zielsystem zur Hand haben und ausprobieren, ob was Funktionierendes 
herausgekommen ist.

[C. A. Rotwang (Gast)]

Peter B. schrieb:
> Diese Kacke mit dem Modell-Sim ist die größte Sünde auf Erden von dummen
> Professoren und Entwicklern dieses System.

Nachdem ich diesen Auswurf lesen musste, bereue ich es zutiefst, das ich 
ernsthaft versuchte,  dem Peter B. bei seinen Bemühungen zu 
unterstützen:
Beitrag "Re: Ich möchte bitte mal eine Core compilieren mit Quartus 18.1 Lite"

Ich werde diesen Fehler nicht wiederholen.

[Christophz (Gast)]

Der Versuch einer Zusammenfassung:

"Idee-->Vorstellung wie eine RTL Struktur dazu aussieht (Abstrahierte 
Hardware Sicht)-->VHDL-->Toolchain-->Reale Hardware"

[Vancouver (Gast)]

Wenn ich das hier so durchlese:

- VHDL ist eine extrem stupide Programmiersprache
- Simulation ist unnötiger Schnickschnack
- Zwischen HW- und SW-Entwicklung gibts keine Unterschiede

dann habe ich in der Vergangenheit alles fasch gemacht. Im Studium, in 
der DA und in den 22 Berufsjahren danach. Die Chips und FPGA-Designs, an 
denen ich mitgearbeitet habe, haben alle nur zufällig funktioniert, die 
die Leute, die dafür z.T. sehr viel Geld auf den Tisch gelegt haben, 
sind alle Idioten. Ich springe dann jetzt besser mal von der 
Gartenmauer, bevor ich noch mehr Schaden anrichte.

[VHDL hotline (Gast)]

Ich möchte noch einen Aspekt einbringen. Vielleicht erinnert sich noch 
einer an das Y-Diagramm aus Studienzeiten

https://de.wikipedia.org/wiki/Y-Diagramm

VHDL erlaubt eine Beschreibung von Hardware auf unterschiedlichen Ebenen 
und Sichtweisen dieses Diagramms. Daher KANN man bei der Beschreibung 
von einer wohlüberlegten Struktur ausgehen und das dann in VHDL gießen 
(meist Logik- bis algorithmische Ebene) oder man geht eben vom Verhalten 
aus und schaut, was der Synthesizer daraus macht. Der Synthesizer/PAR 
bildet das ganze auf Geometriesicht im FPGA ab.
Letztendlich muss man die unterschiedlichen Sichtweisen zusammen denken 
(bzw. ist auch die VHDL+constraints-Beschreibung meist eine Mischung), 
um eine Vorstellung zu haben, was bei einer bestimten Funktionalität 
(Verhalten) für eine Struktur entsteht bzw. welche Geometrie im FPGA 
genutzt werden kann. Das ist es, was "VHDL Denken" meiner Meinung nach 
ausmacht.

[Schlumpf (Gast)]

VHDL hotline schrieb im Beitrag #5851473:
> Vielleicht erinnert sich noch
> einer an das Y-Diagramm aus Studienzeiten

Sehr guter Einwand.
Und ich denke, anhand des Diagramms kann man einiges erklären und ggf 
Missverständnisse ausräumen.

In VHDL lassen sich alle Ebenen beschreiben. Es ist also nicht auf eine 
Ebene beschränkt.
Ebenso lassen sich Verhalten und Struktur in VHDL gut beschreiben.

Aber alle diese Ebenen beschreiben Hardware (in unterschiedlichsten 
Abstraktionsstufen)

Wie "tief" ich in meinem Design bei der Beschreibung abtauche, muss von 
Fall zu Fall entschieden werden und kann natürlich innerhalb eines 
Designs auch gemischt werden.
An manchen Stellen muss man sich um jedes Register und jede LUT Gedanken 
machen (Beschreibung auf Logikebene). An anderer Stelle kann man mehr 
den Tools überlassen (Beschreibung auf algorithmischer Ebene).

Wie abstrahiert oder detailliert das Bild der Hardware sein muss, ist 
von Fall zu Fall verschieden.
Ich muss also eine Vorstellung der Hardware haben, muss wissen, an 
welchen Stellen ich auf welchen Abstraktionsebenen Beschreiben muss. Und 
dieses Wissen kann ich nur haben, wenn ich die schaltungstechnischen 
Stolperstricke kenne und weiss, wo ich "genauer" hinschauen muss.
Wenn mir das alles klar ist, dann beschreibe ich in VHDL auf 
unterschiedlichsten Abstraktionsebenen die Hardware, die ich mir erdacht 
habe.

Aber alles ausschließlich auf System- oder algorithmischer Ebene zu 
beschreiben und den Rest den Tools zu überlassen, kann funktionieren - 
kann aber auch zu grauenhaften Designs führen, die instabil laufen (vgl 
die Beispiele mit Domain Crossings oder asynchronem Reset).

[Dussel (Gast)]

Vancouver schrieb:
> Ich springe dann jetzt besser mal von der
> Gartenmauer, bevor ich noch mehr Schaden anrichte.
Springen musst du nicht. Wir können ja eine Selbsthilfegruppe gründen. 
:D

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Schlumpf schrieb:
> Anderes Beispiel (was gerne gemacht wird):
> Asynchroner Reset.
> Die Idee, ein Register asynchron zurück zu setzen, ist aus
> Verhaltenssicht eine völlig legitime "Idee". Spielt ja auch funktional
> keine Rolle, ob der Reset asynchron oder synchron erfolgt.
> Scheisse ist dann nur, wenn nach jedem 1000ten Reset die FSM (über deren
> Aufbau man natürlich auch nichts weiss, da man ja nur Ideen beschreibt),
> nicht los laufen mag.

Es gibt eine noch schlimmere Variante, die ich selbst schon erlebt habe:
Der Produktmanager eines Kunden bestand darauf, dass auf der Baugruppe 
kein hochfrequenter Takt verwendet werden dürfe, da er irgendwo mit 
einem halben Ohr aufgeschnappt hatte, dass Takte zu EMV-Problemen 
können. Gleichzeitig verlangte er zwingend die Verwendung eines CPLD 
oder FPGA. Letztendlich musste ich ein taktartiges Konstrukt mit Hilfe 
einer Laufzeitleitung realisieren, die zwecks längerer Delays zweimal 
die Baustein verließ und über andere Pins zurückgekoppelt wurde. Das 
funktionierte sogar ausgesprochen zuverlässig, hat aber so gar nichts 
mehr mit synchronem Design zu tun.

Nachdem mehrere Baugruppen durch ähnliche Vorgaben ziemlich verhunzt 
wurden, konnte ich bei dem Kunden durchsetzen, dass der Produktmanager 
nur noch Spezifikationen erstellen darf und seine Detailkonzepte nur als 
Ideen oder Vorschläge anzusehen sind.

[Markus F. (mfro)]

Lothar M. schrieb:
> Eigentlich ist es schade, dass es sowas wie "Simulation gegen ein Modell
> der Umwelt" für die Software nicht generell gibt.

da ist unser Peter B. halt ein wenig auf dem Holzweg.

Jede nichttriviale, vernünftig entwickelte Softwareprojekt (jetzt meine 
ich "richtiges Programmieren") wird sich früher oder später mit dem 
Thema Unit-Tests beschäftigen müssen.

Da ist m.E. kein gar so großer Unterschied.

[Weltbester FPGA-Pongo (Gast)]

Andreas S. schrieb:
> Nachdem mehrere Baugruppen durch ähnliche Vorgaben ziemlich verhunzt
> wurden, konnte ich bei dem Kunden durchsetzen, dass der Produktmanager
> nur noch Spezifikationen erstellen darf und seine Detailkonzepte nur als
> Ideen oder Vorschläge anzusehen sind.

Glücklich, wenn man sich da durchsetzen kann. Leider stecken in vielen 
Firmen selbsternannte FPGA-Experten, die aus der Softwareecke kommen 
oder sonst woher. Die denken schwarz-weisß, haben bisweilen total 
absurde Vorstellungen, die darauf gründen, dass sie entweder persönlich 
wo reingefallen sind oder was aufgeschappt haben, oder ihnen irgendwas 
von Mathworks unter die Nase gerieben wurde. Dann meiden sie Dinge oder 
propagieren sie wie von Gott gegeben.

Daraus resultieren die abenteuerlichsten Vorgaben, die unweigerlich zu 
Konflikten führen, wenn der Entwickler anders denkt, oder nur andeutet, 
anders zu denken.

Ich hatte vor Jahren ein Einstellungsgespräch bei einer Firma im Ländle, 
die sich mit militärischer Signalverarbeitung befasst und u.a. 
Funkgeräte baut. Die suchte dringend nach fähigen Entwicklern und hat so 
hohe Ansprüche, dass sie nach eigenen Aussagen schon mehrfach welche 
wieder freisetzen mussten.

Dort traf ich im zweiten Gespräch auf den leitenden FPGA-Entwickler, der 
mir seine Vorstellungen von einem guten FPGA-Design erklärte und meine 
Meinung dazu hören wollte. Die habe ich ihm mitgeteilt und verdeutlicht, 
dass seine Art der Verifikation so eher wenig Sinn macht, nicht allviel 
überprüft, oft unlogisch und unnötig ist, während andere Dinge 
ausgelassen würden, die wichtiger sind, obwohl leicht und automatisiert 
machbar. Der hatte den Sinn und Zweck von Verifikation nicht verstanden 
und meinte, mit allein den constraints passe das schon. Diskusions und 
Vorgehensweisen waren recht antiquiert, erinnerten mich irgendwie an 
DDR-Mentalität.

Viele der Leitenden sind self-made-Entwickler, haben das nie richtig 
gelernt, sondern sich selber angeeignet und leben in einer Scheinwelt, 
die sie sich zusammengereimt haben. Da spielt auch mit, dass moderne 
Verfahren noch nicht gelehrt wurden, als die an den Hochschulen waren. 
Wenn dann nicht regelmäßig Personen reinkommen, die sie in der Spur 
halten, driften die komplett weg. Schwierig wird es natürlich, wenn 
infolge der Diskrepanzen erst gar keine gut Ausgebildeten und Erfahrenen 
reingenommen werden und sogar welche kündigen, um dem Quark zu 
entfliehen.

Da hält man sich dann lieber fern und verzichtet auf den Job. Im 
Nachhinein habe ich auch erfahren, dass der Leiter sowieso jemanden 
anderen aus einer anderen Abteilung haben wollte, aber nicht einstellén 
durfte. Der Grund war interessant: Der Typ war angeblich mit einer 
Chinesin zusammen und galt daher als unzuverlässig. Er könnte intern 
durch die Gesinnungsprüfung fallen.

[Weltbester FPGA-Pongo (Gast)]

Peter B. schrieb:
> So etwas muss im Hauptprogramm enthalten sein , so das man das
> Zeitverhalten nicht noch erst mit einem neuen Programm suchen muss wo
> "lachnummer" wieder neue Fehler entstehen können.

Wenn ich mich erinnere, was Herr Bierbach vor rund 2 Jahren so hier im 
Forum geschrieben hat, als er erstmal aufgetaucht ist und das Forum mit 
Anfängerfragen zugeplärrt hat, verwundert mich diese Haltung nicht.

Die Unsinnigkeit der Forderung und damit zugleich die Sinnhaftigkeit von 
Modelsim erschließlich sofort, wenn man den Vergleich von ASM zu VHDL in 
der richtigen Weise zieht:

C und ASM werden auch durch modellierung simuliert. In ASM nennt sich 
das tracen und haben wir schon am C64 mit einem Disassembler gemacht. In 
C lassen sich ebenfalls Simulatoren einsetzen. Das macht nur kaum 
jemand, weil sich C stufenförmig entwickeln lässt und mitsamt den 
vorcompilierten Libs recht rasch in ein ablauffähiges Programm 
übersetzen lässt, welches man laufen lassen kann. Da ist viel mit realem 
Tempo und Debugger machbar (und auch der braucht noch etwas Extra Code).

In FPGAs geht das so nicht. Das tun manche zwar, indem sie Code 
reinhacken und ohne Simulation austesten. Sie fühlen sich großartig, 
weil sie was Tolles zu können glauben (siehe den S.pezial I.ntegrations 
T.yp in meinem Beitrag eins weiter oben) aber sie verkennen, dass das 
extram umständlich und langsam ist, und dass sie viele mögliche Fehler 
übersehen, weil sie sie im Test gar nicht abbilden (können).

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Weltbester FPGA-Pongo schrieb im Beitrag #5857056:
> Der Grund war interessant: Der Typ war angeblich mit einer
> Chinesin zusammen und galt daher als unzuverlässig. Er könnte intern
> durch die Gesinnungsprüfung fallen.

Bei geheimschutzbetreuten Projekten, die eine Sicherheitsüberprüfung 
(Ü1/2/3) der eingesetzten Mitarbeiter benötigen, erstreckt sich diese 
auch auf den/die Lebenspartner(in). Mir sind auch zwei Fälle bekannt, in 
denen die Geheimschutzermächtigung ausschließlich auf Grund der 
Nationalität der jeweiligen Ehefrau bzw. Freundin versagt wurde. Bei so 
etwas hat der Arbeitgeber auch wenig mitzureden, sondern die Überprüfung 
und Ermächtigung erfolgen durch das Bundeswirtschaftsministerium, das 
ggf. mit anderen Behörden (Verfassungsschutz, usw.) zusammen arbeitet.

[Zyniqer (Gast)]

Andreas S. schrieb:
> Weltbester FPGA-Pongo schrieb im Beitrag #5857056:
>> Der Grund war interessant: Der Typ war angeblich mit einer
>> Chinesin zusammen und galt daher als unzuverlässig.
>
> Bei geheimschutzbetreuten Projekten, die eine Sicherheitsüberprüfung
> (Ü1/2/3) der eingesetzten Mitarbeiter benötigen, erstreckt sich diese
> auch auf den/die Lebenspartner(in).

Sicher? M.W. wird der Lebenspartner o.ä. erst für Ü2 und Ü3 
mitüberprüft:
https://www.juraforum.de/lexikon/sicherheitsueberpruefung

Ü1 ist Pillepalle.

>> Er könnte intern
>> durch die Gesinnungsprüfung fallen.

Nicht Gesinnungs- sondern Sicherheitsüberprüfung. Und ja, bei 
emotionaler und sexualler Abhängigkeit von einer Chinesin besteht schon 
das Risiko, das diese geleitet von (Rot-)Chinesischem Patriotismus, den 
von ihr abhängigen manipuliert. Oder im Sinne eines kleinen Nebenerwerbs 
Informationen abschöpft.

[Weltbester FPGA-Pongo (Gast)]

Zyniqer schrieb:
> Oder im Sinne eines kleinen Nebenerwerbs
> Informationen abschöpft.

Das erfordert aber die Mitwirkung des bei der Firma beschäftigten 
Eheparters, denn nur er könnte ja seine ausländische Frau einschleusen 
oder einweihen. Damit reduziert sich die Thematik darauf, nicht jedem 
x-beliebigen Mitarbeiter alles zugänglich zu machen und zugleich es zu 
verungmöglichen, dass Frauen mit in die Abteilung kommen.

Insoweit jemand mit etwas Wichtigem betraut ist, muss man sich ohnehin 
drauf verlassen, dass er nicht mitnimmt und das ist Vertrauenssache. 
Zwar kann man jemandem untersagen, daheim darüber zu sprechen, aber ob 
ob er sich dran hält, hängt nicht an der Nationalität der Partnerin. Es 
könnte jeder Spionage betreiben und direkt oder indirekt Informationen 
an Verwandte und Freund weitergeben und das gilt auch für fremde Mächte.

Lustigerweise ist es z.B. keinesweg untersagt, als Deutscher seine Firma 
zu verlassen, nach Russland oder China zu gehen und dort als 
Angestellter zu arbeiten und so sein Wissen zu nutzen. Rheinmetall 
suchte vor Kurzem Ingenieure für die Panzerfirma in Firma in Ismir. Das 
ist viel wahrscheinlicher, als dass einer während einer Tätigkeit 
parallel seine Firma torpediert.

Noch wahrscheinlicher ist es, irgendwo nach Verlassen in einer Firma zu 
arbeiten, die von Chinesen gekauft wird. Nehmen wir z.B. 
Robotikentwicklung bei KUKA: Einer der hauptverantworllichen 
Projektleiter für das HMI- und GUI-Thema kam von Rohde und Schwarz und 
war im A400M-Projekt aktiv. Der kennt alles, angefangen von Kosten, 
Abläufen, Methoden und Protokolle. Ein anderer, der weite Teile der 
Software und somit auch Teile der FPGA-Technologie betreut, kam von 
Eurocopter aus Donauwörth. Der kennt die redundanten Steuercodes für die 
Motorensicherheitsabschaltung. Andere kamen von der MTU und von Diehl. 
Auf die haben die Chinesen legal Zugriff und als Arbeitgeber sogar 
Anspruch auf das Wissen. Es kommt also auf die Einzelperson an, ob da 
jemand loyal bleibt oder nicht.

Hat nichts mit der Frau zu tun.

Zyniqer schrieb:
> Ü1 ist Pillepalle.
Die ganze Sache ist Pillepalle! Die Rüstungsfirmen selbst beschäftigen 
doch massenhaft Ausländer, die beste Kontakte nach daheim haben. EADS, 
ESG, Rheinmetall und MTU z.B. beschäftigen etliche Russen und 
Russlanddeutsche. Die telefonieren wärend der Arbeitszeit mit der Oma in 
Nowosibirsk und bereiten ihren halbjährigen Heimatbesuch vor, erzählen 
über das, was die Leute von Putin denken und verteidigen seine Haltung 
gegenüber Deutschland. Alles schon gehört. Auch Iraner, Pakistani und 
Inder habe ich schon an der Software arbeiten sehen. Nicht umsonst ist 
die Projektsprache oft genug Englisch. Ausserdem beschäftigen sie 
Freiberufler. Diese fluktuieren noch viel stärker, als die Angestellten 
und schleppen Wissen von a nach b.

[J. S. (engineer)]

Carl schrieb:
> Es scheint mir einen Paradigmenwechsel beim Coding zu geben: Der Trend
> geht weg von der Empfindlichkeitsliste hin zu

Langsam: Die Frage ob rising_edge oder Clock'event zu verwenden ist, ist 
eine Sache - die Frage ob mit oder ohne Parameterliste, eine andere.

Wenn bei der Umsetzung ein Signal nicht in der Liste steht, wird die 
Abhängigkeit für das spätere Anspringen driekt erst gar nicht erzeugt 
und nicht erst nicht dann nicht, wenn die Funktion betreten und 
analysiert wurde. Zudem ist das in einigen Fällen nicht durch Analyse 
eliminierbar, wenn Verknüpfungen zwischen Signalen bestehen und es nicht 
ohne Simulation klar ist, dass es keine funktionelle zeitliche 
Überlappung gibt (wie das die Synthese erkennen kann, wenn sie alles 
ausgerollte hat). Dann wird das jeweils zu Ausführungszeit entschieden 
und man hat den unnötigen Aufwand.

Die andere Fragestellung, ob "clock'event" oder "rising_edge" ist nicht 
zu beantworten, denn die sind nicht vollständig gegeneinander 
austauschbar. Das ist speziell bei physikalischen Sims zu unterscheiden. 
Dazu haben wir bereits aber threads gehabt. Siehe auch die Libraries und 
möglichen Belegungen der Signale.


Schlumpf schrieb:
> Aber alle diese Ebenen beschreiben Hardware (in unterschiedlichsten
> Abstraktionsstufen)

Naja, eine Schleife beschreibt zunächst nur einen Vorgang, den der 
Compiler ausführen soll. Da kommen gfs. 10 Leitungsverbindungen, 10 
platzierte Cores, aber auch 10 Berechnungsansätze oder Iterationen 
heraus, die ein Ergebnis liefern, welches weiter verwendet wird. 
Besonders die Hilfsrechnungen mit Variablen produzieren eher Vorgaben 
für Hardware und bei state machines sind wir zugegeben sehr weit weg von 
Hardware.

Daher wäre die korrekte Beschreibung "Beschreiben der Funktion der 
Hardware", also f(H). Dem trägt man in VHDL bekanntlich durch Einführung 
der Begriffe structural und bahavioral Rechnung. Da diese aber meist 
bedeutungsfrei oder gar sinnentstellend in der Architektur rumhängen, in 
welcher bunt gemixt allesmögliche formuliert wird, herrscht da eben 
leider keine Ordnung.

[W.S. (Gast)]

Schlumpf schrieb:
> Daher sage ich (dass es tief genug einsinkt):
>
> "Hardware-->VHDL": So wird ein Design stabil.

Sorry, aber das ist Babylon pur.

Du sagst "Hardware", meinst damit aber etwas grundsätzlich anderes als 
du sagst.

So werden dich eben 99.9% aller Studenten deftig mißverstehen.

Die sagen sich dann irgendwann - um überhaupt mental durchzukommen - 
"laß den ollen Zausel quatschen, wir hören ihm nicht weiter zu und 
verlassen uns fürderhin auf unsere eigene Empirie".

Warum können die Leute sich bloß nicht exakt audrücken und beharren 
allweil darauf, zu ihrer Idee einer Logik "Hardware" zu sagen?

Wenn ich mir z.B. nen CORDIC selber ausdenken will, dann denke ich zu 
allererst an den eigentliche Algorithmus (reinweg Gedanken), dann daran, 
wie ich ein dafür geeignetes Zahlenformat hinkriege (auch nur Gedanken), 
dann ob ich HW-multiplizierer zur Verfügung habe oder diesen Mist zu Fuß 
machen muß, dann wieviele Stufen ich tatsächlich benötige, den Rest kann 
man ja - wenn man sich nicht dämlich anstellt - ja prima verwenden, um 
die Stufenanzahl und damit die Taktanzahl für den ganzen Durchlauf 
drastisch zu reduzieren.

Das ist alles nur reines gedankliches Durchgehen dessen, was zum 
Realisieren der Idee vom CORDIC nötig ist, also Software.

Wo bleibt da die Hardware? Fast nirgendwo. An die LUT's denkt man da 
noch garnicht, allenfalls was man an fertig verdrahteten Baugruppen im 
Chip zur Verfügung hat. Die Hardware kommt wirklich erst ganz zum 
Schluß.

Ich ärgere mich immer über Leute, die irgend einen Spezial-Jargon 
daherreden, der zwar bekannte Wörter verwendet, damit aber völlig andere 
Dinge meint. Ist modernes Rotwelsch. Sowas wie "wo der Bartel den Most 
herholt" übersetzt sich nur für den Spitzbuben zu "wo das Brecheisen die 
Geldscheine herholt"

W.S.

[J. S. (engineer)]

W.S. schrieb:
> Warum können die Leute sich bloß nicht exakt audrücken und beharren
> allweil darauf, zu ihrer Idee einer Logik "Hardware" zu sagen?

Weil es einen Dualismus des Wortes "digitale Logik" gibt:

1) Logische Funktionen zur Informationsverarbeitung, definiert durch 
u.a. die Boolsche Algebra, Inkarnation: Und, Oder, Invertiert, Gleich, 
Ungleich

2) Logikbausteine der Elektronik zum Schaltungsdesign mit TTL und CMOS 
auf Gatterebene, Inkarnation durch Buffer, Inverter, Pins und eben die 
Gatter

Damit besteht an einigen Stellen eine Identität zwischen der 
Beschreibung von VHDL und Schaltungstechnik, an anderen nicht. Das 
bekommen manche halt nicht gebacken.

Richtig ist, beim inneren FPGA-Design, das nichts mit Physik zu tun hat, 
von Logikdesign zu sprechen, also dem Verknüpfen von Informationen und 
den Strom, Spannungen und auch Pegel außer Acht zu lassen. Daher sollte 
man es auch tunlichst unterlassen, von low-aktiven Signalen zu sprechen, 
die es real nicht gibt.

Richtig ist ferner, beim äußeren FPGA-Design, wenn es um Pins und Ports 
und die Pegel geht, von Hardwareentwicklung zu sprechen. Hier z.B. ( und 
nur hier!) treten lo-aktive Pins auf.

Diese Dinge sind aber eigentlich klar und eindeutig beschrieben und 
werden an Universitäten auch so gelehrt. Leider passen Viele nicht 
richtig auf und vermischen Definitionen. Kurze Zusammenfassung von Susi:

1) Funktionelles Design -> Software (Ablauf), Variablen, Funktionen, 
Methoden, Vorgänge sind z.B. "true / false" finden also statt oder 
nicht.

2) Logik Design -> Software mit Bezug zur Hardware (Gatterlogik), 
Signale sind 0 und 1

3) Physisches Design -> Hardware als Software beschrieben (Ports, PLL, 
Pegel) Leitungen sind "low high"

Alle 3 werden durch VHDL bedient. Leitungen gibt es im FPGA aber keine! 
Die werden nicht beschrieben.

W.S. schrieb:
> Das ist alles nur reines gedankliches Durchgehen dessen, was zum
> Realisieren der Idee vom CORDIC nötig ist, also Software.
JA!  Aber:

> Wo bleibt da die Hardware? Fast nirgendwo.
Solange du nur funktionelles VHDL und Cores entwickelst, nimmst du keine 
Rücksicht auf Hardware. Stimmt.

Das ist aber nur die Hälfe der Aufgaben beim FPGA-design.

> Die Hardware kommt wirklich erst ganz zum Schluss.
Sie kommt bei der Synthese. Spätestens dann, wenn das Logikdesign in die 
Hardware reingeworfen wird. Siehe meine Unterscheidung oben zum 
physischen design.

Entwicklung heißt aber auch Kosten, Rechenpower und Elektronik im Auge 
behalten. Diese wirken sich gleich zu Beginn auf die Konzepte aus und 
damit z.B. die Frage, ob dein Cordic wirklich die ideale Lösung ist oder 
man einen Sinus oder ATAN gfs doch in Hardware, also einem RAM baut.

[W.S. (Gast)]

Jürgen S. schrieb:
> Weil es einen Dualismus des Wortes "digitale Logik" gibt:

Ja, siehste. Ich sprach eigentlich von der Idee einer Logik. Also von 
der Idee, ein Funktionieren in die Tat umzusetzen. Nicht von digitaler 
Logik oder gar von schnöden TTL-Schaltkreisen.

Die Idee von einer Logik - wie sind hier ja Im FPGA/VHDL-Bereich - ist 
die gewünschte Funktion, also z.B. ein digital funktionierendes Radio 
mit dem ich dann auf Kurzwelle Radio Eriwan empfangen kann.

Man kann das nun verfeinern in digitale Baugruppen bis herunter zu den 
Basisfunktionen AND, OR usw. Aber das ist alles Idee bis hin zu dem 
Zustand, daß man die Idee technisch abbilden kann, es ist also Software. 
Alles, alles, alles.


Ich merke immer wieder, daß eben grad die Leute, die in FPGA-Gefilden 
arbeiten oder lehren, immense Schwierigkeiten haben, sich auszudrücken.

Deshalb werden sie von anderen Leuten, die nicht aus exakt dem gleichen 
Umfeld kommen, schlichtweg nicht oder komplett fehlverstanden.

Ebenso haben sie - wie wir hier gesehen haben - auch in umgekehrter 
Richtung ihre Schwierigkeiten, zu verstehen was andere Leute ihnen 
sagen.

Das ist offenbar genau so wie Rotwelsch und zugleich Spitzbube zu 
lernen. Nur eines von beiden geht offensichtlich nicht. Oder?

Ich sehe da nur ein trauriges Fazit: Die zugehörige Lehre ist nach wie 
vor von miserabler Qualität und sollte deutlich verbessert werden.

Aber dazu gehört eben auch, daß die FPGA-Rotwelsch sprechenden Leute, 
die zwar ihre Erfahrungen haben, diese jedoch nur in ihrem Rotwelsch 
ausdrücken können, sich bemühen sollten, normales Sprechen wieder zu 
erlernen, damit sie lehren können.

W.S.

[J. S. (engineer)]

W.S. schrieb:
> Ich merke immer wieder, daß eben grad die Leute, die in FPGA-Gefilden
> arbeiten oder lehren, immense Schwierigkeiten haben, sich auszudrücken.

> diese jedoch nur in ihrem Rotwelsch
> ausdrücken können, sich bemühen sollten, normales Sprechen wieder zu
> erlernen, damit sie lehren können.

Sehr weit ausgeholt.

Ich stimme dieser oft zitierten Meinung der angeblichen Nichtbefähigung 
von Entwicklern hinsichtlich ihres Ausdrucksvermögens inhaltlich bedingt 
zu, weise aber im konkreten Zusammenhang auf 2 klitzekleine Dinge hin:

1) Wenn wir uns in einem thread bewegen, der "VHDL Denken" heißt, dann 
haben wir eine genaue Vorstellung, was "Logik" meinen könnte.

2) Ich habe nicht ohne Grund weiter oben die 3 Ebenen des Entwickelns 
von Schaltungen aufgegriffen und dort im Punkt 1 von der funktionellen 
Logik gesprochen. Dort findest du das, was du mit dem "von der Idee 
einer Logik." meinst.

Logisch? :D

Im Übrigen bewegten wir uns beim aktuellen Tenor der Diskussion um die 
Frage "Software" <-> Hardware. (Lesefähigkeiten :D)

Gute Nacht

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Mich hat seinerzeit als Anfänger, der VHDL für die Hardwareentwicklung 
einzusetzen hatte, schon sehr gewundert, dass es in einem FPGA ein 
"after xx ns" gibt.
"Wie soll das gehen?" habe ich mich zurecht gefragt und dann 
herausgefunden, dass sowas simples wie

   led <= not led after 500 ms;    -- blinken

eben doch nicht geht. Oder eben nur im Simulator. Dort aber anstandslos.

So wie auch das hier

   :
   if rising_edge(button) or falling_edge(trigger) then
      wait for 10 ms;
      :

tadellos im Simulator läuft.

Ich kann mit solchen Konstrukten also tatsächlich irgendwelche Abläufe 
"programmieren", bekomme die aber niemals mit einer FPGA-Toolchain auf 
lauffähige Hardware umgesetzt.
Oder andersrum: diese Konstrukte "beschreiben" eine Hardware, die ich so 
nicht ins FPGA bekomme.

W.S. schrieb:
> Jürgen S. schrieb:
>> Weil es einen Dualismus des Wortes "digitale Logik" gibt:
> Ja, siehste. Ich sprach eigentlich von der Idee einer Logik. Also von
> der Idee, ein Funktionieren in die Tat umzusetzen. Nicht von digitaler
> Logik oder gar von schnöden TTL-Schaltkreisen.
Irgendwie scheint mir diese Diskussion samt Haarspalterei um den Begriff 
"Logik" bezeichnend für die Problematik zu sein. Man versucht unbedingt, 
Begriffe, die bereits anderweitig vorbelegt sind, auf das neue 
Aufgabengebiet umzubiegen.

Für mich ist nämlich die Logik lediglich ein Hilfsmittel wie Bleistift 
und Paier, um meine Idee zu realisieren: "Meine Idee ist, eine Funktion 
zu bekommen, also brauche ich logischerweise Dieses und Jenes."
Ich brauche aber in diesem sehr abstrakten und durchaus logischen 
Denkprozess noch keine Logik im Sinne eines digitalen Schaltkreises. Auf 
diese Doppeldeutigkeit wird dann schon in der ersten Zeile des 
"Logik"-Wikipedia-Artikels (https://de.wikipedia.org/wiki/Logik) 
hingewiesen.

In einem Thread, der sich mit "VHDL für FPGAs" befasst, sollte aber klar 
sein, dass mit "Logik" nicht die eher philosophische oder symbolische 
Logik wie in Wikipedia beschrieben gemeint ist, sondern dass hier mit 
"Logik" kombinatorische Schaltungen, die mit Logikgattern umgesetzt 
werden sollen, gemeint sind (https://de.wikipedia.org/wiki/Logikgatter).

W.S. schrieb:
> Aber das ist alles Idee bis hin zu dem Zustand, daß man die Idee
> technisch abbilden kann, es ist also Software.
> Alles, alles, alles.
Ist dann per dieser Definition auch eine beliebige mechanische Zeichnung 
eine Art "Software"? Und sind dann logischerweise die Konstrukteure auch 
"Programmierer"?

[C. A. Rotwang (Gast)]

W.S. schrieb:
> Jürgen S. schrieb:
>> Weil es einen Dualismus des Wortes "digitale Logik" gibt:
>
> Ja, siehste. Ich sprach eigentlich von der Idee einer Logik. Also von
> der Idee, ein Funktionieren in die Tat umzusetzen. Nicht von digitaler
> Logik oder gar von schnöden TTL-Schaltkreisen.
...
> Ich merke immer wieder, daß eben grad die Leute, die in FPGA-Gefilden
> arbeiten oder lehren, immense Schwierigkeiten haben, sich auszudrücken.
>
> Deshalb werden sie von anderen Leuten, die nicht aus exakt dem gleichen
> Umfeld kommen, schlichtweg nicht oder komplett fehlverstanden.
>
> Ebenso haben sie - wie wir hier gesehen haben - auch in umgekehrter
> Richtung ihre Schwierigkeiten, zu verstehen was andere Leute ihnen
> sagen.

Naja jedes Fachgebiet hat so seine eigene Begrifflichkeit, weil jedes 
Fachgebiet seine eigene Werkzeuge und Mittel hat die geforderte 
Applikation zu erstellen. Und es ist selbstverständlich, das die 
Beschreibung der Realisierung eben auf der Beschreibung der Anordnung 
der benutzen Mittel beruht. Das ist kein Rotwelsch, das ist einfach 
Domain-KnowHow (https://en.wikipedia.org/wiki/Domain_knowledge). Man 
kann eben keine Domain beherrschen ohne sich die Domain-Begriffe 
anzueignen.

Ist halt wie bei der sexuellen Aufklärung von Heranwachsenden. So grob 
kann man das mit sterilen, poetischen Vergleichen wie Bienen und Blüten 
umschreiben, aber ums wirklich anwendbar muss man ins 'Vulgäre' 
wechseln. Unabhängig davon, ob irgendwelche Elfenbeinturm-Luftikuse 
davon einen 'Knacks' wegbekommen oder nicht: 
https://www.youtube.com/watch?v=gjd6KWFi5NM

[Markus F. (mfro)]

Lothar M. schrieb:
> Ich kann mit solchen Konstrukten also tatsächlich irgendwelche Abläufe
> "programmieren", bekomme die aber niemals mit einer FPGA-Toolchain auf
> lauffähige Hardware umgesetzt.

Was ja nun letztendlich nur eine Einschränkung des Werkzeugs (Synthese) 
ist (die Sprache an sich kann's ja).

Ein C-Programmierer, der mit Fliesskommazahlen rechnen will, schreibt 
auch ganz selbstverständlich 3.0 * 2.5 hin, obwohl er (hoffentlich) 
weiß, daß sein mickriger 8051 gar keine Fliesskommaeinheit hat und der 
C-Compiler eine Softwareemulation dafür einfügen muß. Er nimmt einfach 
hin, daß sein Programm dadurch deutlich größer, langsamer und 
möglicherweise ungenauer wird.

VHDL-Synthese ist einfach (noch?) nicht so weit. Gut oder schlecht?

Wer sich jedenfalls von Anfang an beim Design auf das beschränkt, was 
die Synthese hergibt und nur in Schaltkreisen denkt, wird die 
Fähigkeiten der (Programmier-) Sprache VHDL nur zu einem sehr geringen 
Teil ausnutzen.

[C. A. Rotwang (Gast)]

Markus F. schrieb:

> Wer sich jedenfalls von Anfang an beim Design auf das beschränkt, was
> die Synthese hergibt und nur in Schaltkreisen denkt, wird die
> Fähigkeiten der (Programmier-) Sprache VHDL nur zu einem sehr geringen
> Teil ausnutzen.

Ja mei, als FPGA-Hardwareentwickler ist es nun mal der Job Hardware zu 
bauen die tut. Da sind alle anderen Aspekte eher störend. Und auch in 
der Softwareentwicklung wird mit Coding Standards/Styleguides die 
Möglichkeiten der Nutzung aller Sprachelemente bewusst eingeschränkt, 
bspw.:
https://www.gnu.org/prep/standards/html_node/Writing-C.html

Ziel der VHDL-Verwendung ist nun mal nicht möglichstweite Ausnutzung 
aller Möglichkeiten sondern sauberes Engineering. Also 
wartungsfreundlicher (vom Team verständlichen) Code schreiben, der 
möglichst 'robust' und frei an 'Trittfallen' und Randeffekten ist.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Markus F. schrieb:
> obwohl er (hoffentlich) weiß, daß sein mickriger 8051 gar keine
> Fliesskommaeinheit hat und der C-Compiler eine Softwareemulation dafür
> einfügen muß.
Ja, lustigerweise wissen das sogar frisch fertig studierte technische(!) 
Informatiker nicht mal. Persönlich kenne ich da einen Fall, wo für einen 
Abschlaussarbeit bestimmte Funktionen in einen STM32 reinzupacken waren. 
Ich hatte das Projekt zu betreuen und die Rechenleistung des µCs als 
"für die Aufgabe mit Reserven gut ausreichend" befunden.
Dann gings erst mal vielversprechend und überraschend zügig los, bis der 
werdende Bachelor kam und sagte: "Das Design passt nicht rein! Und das 
Ding ist zu langsam!"

Puh, Hitzewallungen und hektische Kontrolle der Abschätzung, aber keinen 
offensichtlichen Fehler in meinen Überlegungen gefunden. Also haben wir 
den Code mal tiefergehend zusammen angeschaut und ich habe ihm im 
erzeugten Assemblercode mal gezeigt, was da umständlich und 
ressourcenfressend umgesetzt wird. Letztlich hat sich herausgestellt, 
dass da tatsächlich noch in alle Richtungen (Speicher und Timing) viel 
Platz ist.

Ihm wurde die Abhängigkeit von Hardware und Software in den 
vorausgegangenen 3 Jahren offenbar nicht hinreichend verdeutlicht. Er 
hat "Programmieren" irgendwie losgelöst von "Hardware" betrachtet, oder 
ihm war die Verbindung und die Auswirkungen nicht klar.

Und auch, dass ein Zähler besser nicht als float umgesetzt und dann mit 
einem festen Wert verglichen wird, weil das "theoretisch" dann&wann 
schief geht, war ihm bekannt, weil es im Studium auch angesprochen 
wurde. Aber eben nur in der "Theorie". Und mental ist es offenbar 
verankert, dass "theoretische" Dinge praktisch nie vorkommen...

Markus F. schrieb:
> Wer sich jedenfalls von Anfang an beim Design auf das beschränkt, was
> die Synthese hergibt und nur in Schaltkreisen denkt, wird die
> Fähigkeiten der (Programmier-) Sprache VHDL nur zu einem sehr geringen
> Teil ausnutzen.
Er wird aber mit diesen (höchstens) 10% seine Hardware mit der 
(Beschreibungs-) Sprache VHDL so darstellen können, dass der Synthesizer 
sie ins FPGA bekommt.

Und es ist eben einfacher, erst mal mit diesen dafür nötigen 10% 
anzufangen, und dann das, was man aus den restlichen 90% für die 
Simulation braucht, noch zusätzlich zu lernen, als 100% von VHDL zu 
lernen und dann mühsam herauszufinden, welche 90% man nicht primär für 
das Hardwaredesign verwenden kann.

[Vancouver (Gast)]

Lothar M. schrieb:
> Er
> hat "Programmieren" irgendwie losgelöst von "Hardware" betrachtet, oder
> ihm war die Verbindung und die Auswirkungen nicht klar.

Das ist aber bei den meisten Softwareentwicklern so, jedenfalls 
außerhalb des Embedded-Bereiches. Der typische Business-ITler, der in 
Java irgendwelche Web-Microservices programmiert, ist von der Hardware 
so weit weg, dass sie ihm nur bewusst wird, wenn sie mal ausfällt. Was 
ja  grundsätzlich nicht verkehrt ist. Bei sehr komplexen Aufgaben ist 
eines hohes Maß an Abstraktion notwendig, sonst kommt man nicht in 
endlicher Zeit ans Ziel. Aber wenn ein SW-Entwickler, der bisher auf 
diesem Abstraktionsniveau gearbeitet  hat, jetzt einen uC programmieren 
soll, dann wird's echt lustig. Kenne ich von vielen Leuten, die aus der 
Matlab-Welt kommen und ihre zweifellos eleganten Algorithmen auf eine 
embedded-Plattform portieren sollen. Blut, Schweiß und Tränen. Von VHDL 
und FPGA ganz zu schweigen.

Umgekehrt ist es aber zugegeben auch nicht anders. Wenn ich hin und 
wieder mal Scilab zur Hand nehme oder C++ mit openMP oder in Python 
programmiere und daran denke, was da "behind the scenes" alles abläuft, 
dann wird mir schwindelig und ich versuche unbewusst, die gleichen 
Optimierungstechniken anzuwenden wie beim Baremetal-C-Code auf einem uC 
mit ein paar kByte Speicher. Was dann meistens völlig ins Leere läuft. 
Man muss einfach lernen, sich auf das jeweilige Abstraktionsniveau 
einstellen, auf dem man arbeitet.

[J. S. (engineer)]

Lothar M. schrieb:
> Ich kann mit solchen Konstrukten also tatsächlich irgendwelche Abläufe
> "programmieren", bekomme die aber niemals mit einer FPGA-Toolchain auf
> lauffähige Hardware umgesetzt.
> Oder andersrum: diese Konstrukte "beschreiben" eine Hardware, die ich so
> nicht ins FPGA bekomme.

Klar und das muss auch so sein, wenn man sich vor Augen führt, dass ich 
mit VHDL eben nicht Abläufe beschreibe/programmiere, die auf dem FPGA 
laufen, sondern Abläufe beschreibe/programmiere, die in der 
Synthesesoftware laufen.

Eigentlich ist es ein einfacher Gedankengang, zu erkennen, dass 
irgendwelche waits oder loops dann in der Software laufen und es egal 
ist, ob es sich um Synthese oder Simulaiton handelt. Man muss halt 
genauer hindenken, was passiert, wenn ich eine Simulation warten lasse 
und eine Synthese warten lasse. Im ersten Fall bekomme ich eine 
Zeitverzogerung, die sich auf das Simulationsverhalten auswirkt, im 
zweiten allerhöchsten eine langsamere Synthese. Man darf alsom getrost 
davon ausgehen, dass die Synthese ein wait richtigerweise überliest.

Und das gleiche kriege ich, wenn ich die beiden Softwareprogramme in 
eine Schleife schicke: Die Simulation looped ein paar mal und führt das 
aus, was drin steht und die Synthese tut das auch. Steht dann ein 
generate drin, bekomme ich in der Simulation n Stücke meines Codes 
aufgezogen und in der Synthese auch. Steht aber in der loop nur eine 
einzige Zuweisung drin, dann wird die in der Simulation 10x ausgeführt 
(wenn sie nicht wegoptmiert wird) und in der Synthese 10x redundant 
ausgeführt - führt eben zu einer einzigen, wenn sie nicht irgendwie 
divergiert.

Wenn ich einem Menschen 10x sage, "verlege eine Leitung" habe ich am 
Ende gfs auch nur eine einzige Leitung.


************************************************************************
Um den Programmierern den Denkanstoss zu geben, weise ich daher immer 
auf den Zusammenhang von VHDL zu einer ScriptSprache hin. Mit einem TCL 
kann man auch die Synthese steuern und wenn da drin steht, etwas 5x zu 
tun, gibt es eben 5 Cores, 5 Leitungen bzw auch 5 FPGAs, oder eben auch 
5x das Gleiche oder 5x exakt Dasselbe. Kein Mensch kommt dann auf die 
Idee, anzunehmen, dass der FPGA 5x etwas tun wird. Es ist der 
FPGA-Erbauer, der mit VHDL angewiesen wird, 5x etwas zu tun. Hat man das 
mal verinnerlicht, fallen 75% der Anfängerfragen zu der Bedeutung und 
Funktion bestimmter VHDL-Befehle direkt weg.

[W.S. (Gast)]

Lothar M. schrieb:
>> obwohl er (hoffentlich) weiß, daß sein mickriger 8051 gar keine
>> Fliesskommaeinheit hat und der C-Compiler eine Softwareemulation dafür
>> einfügen muß.
> Ja, lustigerweise wissen das sogar frisch fertig studierte technische(!)
> Informatiker nicht mal.

Tja.

Die auch hier in diesem Forum übliche Ausrede für Nichtwissen solcher 
Art ist "man muß das Rad ja nicht nochmal erfinden.."

Offensichtlich ist eben auch die Lehre bzw. das Studium innerlich 
versaut. Warum fängt man bei Informatik/Ingenieurs-Fächern nicht mit den 
Grundlagen an?

Also:
- zu allererst Schaltungen per TTL und Stromlaufpläne
- dann Assembler mit eine möglichst alten und einfach zu verstehenden 
Plattform (z.B. Z80)
- dann Gleitkommaformat erläutern und Softwarepaket für die 4 
Grundrechenarten durchkauen, bis es auch der Letzte kapiert hat, was es 
so alles braucht, bis ein u:= d*3.1415; als Maschinencode im Controller 
ist.
- und dann erst irgendwelche höheren Angelegenheiten, höhere 
Programmiersprachen und so.

Warum also wird von den Lehranstalten den Lernenden der notwendige 
Grundlagenstoff nicht in der gehörigen Tiefe und Reihenfolge 
beigebracht? Das ist doch ein Manko der Lehranstalten!

Ich würde die Studenten zu allererst mal ein CPLD mit Schematics des 
Webpacks von Xilinx programmieren lassen (wobei sie sich wohl über eben 
dieses Schematics zunächst schwarz ärgern werden) und dann erst ihnen 
erzählen, daß man das Gleiche auch verbal mit Hilfe einer entsprechenden 
Programmiersprache machen kann. So herum! Dann kommt vermutlich auch 
eher das RICHTIGE Verständnis für programmierbare Logik und deren 
Programmierung auf.

Mein Fazit: Die Ahnungslosigkeit der Absolventen ist der mangelnden 
Qualität des Lehrkörpers geschuldet, die sich zwar wie hier über die 
Bildungslücken der Absolventen lustig machen, aber zuvor es nicht 
geschafft haben, selbige zu schließen bzw. erst garnicht aufkommen zu 
lassen.

W.S.

[Carl (Gast)]

>- dann Assembler mit eine möglichst alten und einfach zu verstehenden
>Plattform (z.B. Z80)

Oder noch besser: Erst mal mit Röhren und dann Transistoren.

[Seriös statt Bös (Gast)]

Carl schrieb:

> Oder noch besser: Erst mal mit Röhren und dann Transistoren.

Mumpitz, es geht um integrierte Digitaltechnik, da brauchts von der 
Röhre garnichts und vom Transistor nur ein vereinfachtes Schaltermodel.

Jetzt ist erst Montag vormittag und nicht sonderlich heiß. Versucht doch 
bitte ernsthaft zu bleiben oder bleibt fern!

[Carl (Gast)]

>Mumpitz, es geht um integrierte Digitaltechnik, da brauchts von der
>Röhre garnichts und vom Transistor nur ein vereinfachtes Schaltermodel.

Es geht auch anders:
Beitrag "Reparaturanfrage CPU-Modellrechner Phywe"

[J. S. (engineer)]

Hier muss ich nochmal einhaken:

W.S. schrieb:
> Warum also wird von den Lehranstalten den Lernenden der notwendige
> Grundlagenstoff nicht in der gehörigen Tiefe und Reihenfolge
> beigebracht? Das ist doch ein Manko der Lehranstalten!

Kommt auf die Lehranstalt an! Und auch auf die Zeit! Bei uns 
(Universität Siegen) wurde das sehr wohl gemacht. Im C++ Kurs, im 
OS9-Kurs, im Unix-Kurs und auch im Bereich der Entwicklung mit GALs 
hatte man die Chance, genau das zu kapieren. Allerdings hatten die 
meisten das schon vorher kapiert, weil sie, wie ich, von Kindheit an mit 
8-Bit-Computern rumprogrammiert hatten - im Gegensatz zu den Jahrgängen 
der 70er und frühen 80er, die als Kinder keine Heimcomputer hatten.

Es könnte wohl sein, dass man Vieles davon dann im guten Glauben bei den 
90-Jahre-Studenten auch vorausgesetzt hat und später immer mehr 
übergangen hat, dabei aber verkannte, dass diese spätere Generation 
nicht mehr so viel gebastelt hat wie wir. Die sind meistens weiter oben 
eingestiegen, was Computer anging. Die PCs waren einfach auch nicht dazu 
angetan zu Programmieren.

Dann kam die "Hochschulreform" Mitte Ende der 90er und man hat 
"entrümpelt". Beim Zusammenkürzen- oder wie ich es nannte: 
"Verstümmelung der Ingenieursstudiengänge" - hat man dann viele 
Grundlagen wie technische Mechanik und Physik für die technischen 
Informatiker und Elektroniker mit Richtung Datenverarbeitung einfach 
rausgenommen. Dasselbe passierte mit den Grundlagen der Mikroelektronik. 
Wir haben noch gelernt, wie ein Transistor auf Physikebene funktioniert, 
wie man durch Vereinfachungen zu den reduzierten Gleichungen kommt, die 
man in Ersatzschaltungen findet (differentielle Stromverstärkung etc.). 
Wir hatten auch noch die Innereien von OPs. Die mehr informatiklastigen 
Studiengänge wurden davon weitgehend befreit, damit sie eher die 
Regelstudienzeiten einhalten konnten.

Dann kamen Anfang der 2000er auch noch die bachelor-Studiengänge und es 
wurde nochmal massiv zusammengekürzt! Alles, was vorher Diplom II war 
(universitärer Studiengang) ist weggefallen und Teile davon wurden als 
Zusatzqualifikation "Master" verkauft, den die bachelor machen konnten, 
welche aber auch schon ein stark reduziertes Studium haben, im Vergleich 
zu dem Diplom I (FH) vorher. Ich schätze den heutigen bachelor auf 
maximal 75% des vormaligen FH-Ingenieurs der 80er und frühen 90er. Den 
Master auf maximal 80% des Diplom-Ingenieurs aus der Zeit. Im 
Ausbildungsmenge x Ausbildungsqualität kommt das genau so hin, auch wenn 
es sich martialisch viel anhört.

Da spielt auch mit, dass heute sehr viel mehr Menschen Technik studieren 
und dies nur dadurch möglich ist, dass man von unten her durch Senkung 
des Abiturniveaus und Zugang für nicht-Abiturienten aufgefüllt hat (auch 
wenn das Manche nicht gerne hören werden). Und es spielt mit, dass 
einige Hochschulen ganze Semester aussparen, die Studies in die Firmen 
schicken und dies als Praxissemester verkaufen, wodurch das Studium 
angeblich praxisnäher wird. Dabei wird praktisch nur Lehrzeit 
weggenommen, wie wir damals zu 100% hatten, weil wir unsere halbes Jahr 
Minimalpraktium über die Ferien verteilt gemacht haben.

Gerade dieser Punkt ist nicht nur Augenwischerei sondern auch noch 
schädlich für die Studies, weil sie in diesem "Praxissemester" kaum 
etwas tun können, was sie später machen- und wenn, dann nicht in der 
Qualität, weil sie Vieles noch nicht richtig können. Da wird dann - 
gerade mit VHDL - erst mal viel falsch drauflos programmiert, ohne 
irgendwelche komplexen Inhalte verstanden zu haben, die erst am Ende des 
Studiums kommen, oder gekommen wären, wenn man ein richtiges Diplom 
hätte.

Der Sachverhalt beim Master ist leider auch der, dass ein System, 
welches von Anfang an auf 4 Jahre ausgelegt ist, viel methodischer und 
stabiler aufgesetzt werden kann, als wenn ich eine 2+2 Lösung mit 
Zwischenanschluss anbieten will, wo erst mal löchriges oberflächliches 
Wissen vermittelt wird, um hinterher die Lücken zu stopfen.

Dass das System nicht viel taugt und ineffektiv ist, konnte man gerade 
an unserer Uni sehr gut beobachten, weil es dort möglich war, mit einem 
FH-Diplom einer anderen Hochschule anzurücken und das fehlende 
Hauptstudium nachzuholen, was mutmaßlich schnell gehen sollte, soweit 
Inhalte real schon bekannt sind. So ganz schnell ging es bei den meisten 
dann doch nicht, viele packten es überhaupt nicht obwohl nur FH-ler mit 
mindestens 2.0 und besser zugelassen waren und wenn sie es packten, 
hatten sie insgesamt mehr Zeit aufgewendet.

Darüber ist man sich in den Hochschulen inzwischen auch einig und bietet 
nicht ohne Grund teilweise das echte Diplom wieder an.

[J. S. (engineer)]

Lothar M. schrieb:
> Markus F. schrieb:
>> obwohl er (hoffentlich) weiß, daß sein mickriger 8051 gar keine
>> Fliesskommaeinheit hat und der C-Compiler eine Softwareemulation dafür
>> einfügen muß.
> Ja, lustigerweise wissen das sogar frisch fertig studierte technische(!)
> Informatiker nicht mal.

Lustigerweise hatten wir genau so einen 8051er Programmierkurs. Ein 
Sommersemester lang, allemöglichen Sachen, inklusive 
Pseudo-Multi-Tasking-System mit 4 Prozessen parallel, die sich nicht 
gegenseitig aufhalten. Reader-Writer-Problem komplett in Assembler!

Dafür wäre heute keine Zeit mehr!

Selbst die C-Kurse wurden zusammengestrichen. Zu unserer Zeit gab es ein 
Script, in dem C erklärt wurde mit der Aufgabe, dass diejenigen, die das 
noch nicht können, es sich beibringen mögen - unter Zuhilfenahme von 
Büchern wie K & R aus der Bib. Fertig!

In den Kursen selbst wurden dann Inhalte, Strukturen und Methoden 
gelehrt. Compilerbau, Verkettete Listen, Mehrdimensionale 
Datenverwaltung, Treiber, Multithreading, System 5 IPC. Die Syntax dazu, 
erklärte sich so beiläufig.

Heute lernen die bachelor gerade das C++ selbst und dazu etwa die halbe 
Menge an Inhalten in etwa 75% der Zeit, wie wir damals. Klar kommt dann 
auch nur die Hälfte bei raus! Die Master machen dann in der Richtung 
kaum noch was. Stattdessen klicken sie ganze SOC-Systeme zusammen 
programmieren dann einfache Sachen.  Für mehr reicht die Zeit einfach 
nicht. Ein breit gefächertes Spektrum an Anwendungen, das es ermöglicht, 
einen Blick zu bekommen, wann man wie programmiert, wann man was 
einsetzt, das fehlt.

Es fehlt die Vernetzung des Wissens durch Parallelen aus anderen 
Gebieten wie Mechanik und Elektrik und damit die Transferleistung. Wie 
soll ein Softwareentwickler einen Bezug zu etwas bekommen, wenn er nie 
damit gearbeitet hat? ... wenn er die Dinge, die passieren und die das 
System, das er erstellt, erfassen und steuern soll, nicht einordnen 
kann, weil ihm die Theorie dazu fehlt? So bleibt er dann nur ein halber 
Programmierer, dem man sagen muss, was er programmieren soll.

Das heutige Studium ist viel zu oberflächlich! Angesichts der 
gestiegenen Komplexität müsste es aber eher tiefgründiger und damit 
sogar länger sein. Stattdessen hat man sich an die Billigausbildung 
anderer Staaten angepasst.

[Carl (Gast)]

>Das heutige Studium ist viel zu oberflächlich! Angesichts der
>gestiegenen Komplexität müsste es aber eher tiefgründiger und damit
>sogar länger sein. Stattdessen hat man sich an die Billigausbildung
>anderer Staaten angepasst.

Ich weiß nicht. In letzter Zeit hatte ich ein wenig mit FH-Studenten zu 
tun und mein Eindruck war so schlecht nicht.
Es ist ja auch so, dass sich die Technik wandelt und immer neuere 
Methoden hinzukommen. Also muss man auch einen Teil weg lassen, den die 
früheren Studenten gelernt hatten.
Oder wer kennt sich hier schon mit den algoritmischen Methoden der KI 
aus?
Das Wissen darüber werden die heutigen Studenten in naher Zukunft 
brauchen und es wird auch schon viel an den Hochschulen gelehrt.

[J. S. (engineer)]

Carl schrieb:
> Also muss man auch einen Teil weg lassen, den die
> früheren Studenten gelernt hatten.

Irgendwie ja, aber irgendwie auch nicht, denn die konkreten Algorithmen 
muss man sich ohnehin erst hinterher antun und wenn man grundsätzlich 
verstanden hat, wie man Algorithmen sinnvoll übersetzt, welche 
Fallstricke es gibt und wie man vorgeht, dann kann man das mit jeder 
Mathematik.

Was die dann im Einzelfall macht, ist von der Anwendung abhängig. Direkt 
anwenden kann man das Wissen so ohnehin nicht, weil das meistens in der 
Industrie schon jemand realisiert und eingebaut hat.

Man muss also immer Hinzulernen. Wenn aber die basics fehlen, stimmt das 
Gerüst nicht und ist nicht belastbar. Das Thema KI z.B. besteht ja nicht 
nur aus Algorithmen, sondern auch und vor Allem in der Erfassung von 
Information. Dazu gehören die Sensoren und Aktoren sowie die 
physikalische Umgebung, in der ein Roboter sich bewegen soll.

[Carl (Gast)]

>Man muss also immer Hinzulernen. Wenn aber die basics fehlen, stimmt das
>Gerüst nicht und ist nicht belastbar.

Die Frage ist halt, was das Grundgerüst ist und was man davon weg lassen 
kann.
Und man muss weg lassen, oder sind dir hier alle Techniken bekannt?:
http://gki.informatik.uni-freiburg.de/teaching/ss14/gki/lecture_de.html

[W.S. (Gast)]

Jürgen S. schrieb:
> Dann kam die "Hochschulreform" Mitte Ende der 90er und man hat
> "entrümpelt".

Danke für diesen ausführlichen Beitrag - wenngleich er mich auch 
ausgesprochen melancholisch stimmt.

Als Geräteentwickler in der Industrie habe ich im Laufe der Jahre 
durchaus gesehen, daß der Nachwuchs von Jahr zu Jahr immer unbedarfter 
wurde und mittlerweile an fast allen Stellen aus eigener Kraft nicht 
weiter kommt, weil das Grundlagenwissen fehlt. Aber daß es an den Uni's 
derart zugeht, ist zum Grausen kriegen.

Wo führt das hin? Industriebrache Deutschland? Innovationen und kluge 
Ideen ab demnächst nur noch aus Fernost? Hierzulande nur noch Leute, 
deren einzige Fähigkeit im Wischen über's Phone oder Steckbrett per 
Arduino besteht und die dediziert zu klein im Kopf sind, um echte 
Hochtechnologie selbst gestalten (und nicht nur benutzen) zu können?

Und ja, das Problem hat dann die Industrie, wenn da Jungspunde 
daherkommen, eine tolle Urkunde in der Tasche, aber nur Oberflächliches 
drauf haben, jedoch mit 63k/a einsteigen wollen, ohne daß da ein 
Gegenwert am Jahresende herumkommt - im Gegensatz zum Ö.D. kann 
unsereiner nicht ewig auf verkaufbare Ergebnisse warten. Es ist ein 
Jammertal. Auch für diejenigen, die deshalb wieder entlassen werden 
müssen und nicht begreifen können WARUM. Sind ja zumeist sympathische 
Leute..

OK, ich reg mich auf über lausiges Darbieten von VHDL in der Lehre, 
während eigentlich die Lausigkeit von viel größerem Maßstab ist. 
Grmpf...

Eines bleibt: Man kann es schaffen, die Lehre zu verbessern. Zeit ist 
da, auch öffentliche Gelder. Das ist was Anderes als in der Wirtschaft, 
wo einem die schieren Verkaufszahlen im Nacken sitzen und man keine 
Ressourcen hat, die Versäumnisse der Hochschulen auszuwetzen.

W.S.

[W.S. (Gast)]

Jürgen S. schrieb:
> Im C++ Kurs, im
> OS9-Kurs, im Unix-Kurs und auch im Bereich der Entwicklung mit GALs
> hatte man die Chance, genau das zu kapieren. Allerdings hatten die
> meisten das schon vorher kapiert, weil sie, wie ich, von Kindheit an mit
> 8-Bit-Computern rumprogrammiert hatten - im Gegensatz zu den Jahrgängen
> der 70er und frühen 80er, die als Kinder keine Heimcomputer hatten.

Braucht man einen C++ Kurs und einen OS9- und Unix-Kurs, wenn man 
eigentlich das strukturierte und logische Denken hätte erlernen sollen? 
Ich habe da erheblichste Zweifel. Das klingt mir wie die Diskussionen um 
Kicad: man hat dort zwar die Fundamente falsch oder garnicht gelegt, so 
daß der User die Zuordnung seiner Schematics zum Layout manuell 
vornehmen muß - befaßt sich aber mit einem tollen Push&Shove-Autorouter.

Nee, sehr frei nach Donald Zoppo: Grundlagen first.

Und diejenigen, die in den 70er Jahren geboren wurden, hatten in den 
frühen 80er Jahren einen ZX81 oder Spectrum oder was aus der 65xxer 
Riege. Aber abgesehen davon ist es eben immer wieder dasselbe: man darf 
sich in der Lehre eben nicht drauf verlassen, daß man deren Grundlagen 
weglassen darf, weil die Studenten einer bestimmten Epoche bereits 
einige empirische Erfahrungen intus haben. Die NochNichtWissenden 
wachsen jedes Jahr erneut heran und man muß eben deshalb auch jedes Jahr 
alle Grundlagen wiederholen. Ich erinnere mich da an meinen Mathekurs an 
der Uni: zu allererst kam er mir zu poplig vor, weil ich all diese 
Basics schon an der Schule hatte, aber schon nach 2 Wochen ging es damit 
steil aufwärts - aber stetig und ohne Sprünge oder Auslassungen. Und das 
mit dem "zu poplig" hatten wir alle sehr bald sehr zu revidieren. Aber 
es wurde eben NICHTS einfach so vorausgesetzt, sondern gründlich (aber 
mit Tempo) vom Urschleim an behandelt.

W.S.

[Duke Scarring (Gast)]

W.S. schrieb:
> Kicad: man hat dort zwar die Fundamente falsch oder garnicht gelegt, so
> daß der User die Zuordnung seiner Schematics zum Layout manuell
> vornehmen muß
Du wirst alt...

[J. S. (engineer)]

W.S. schrieb:
> Und diejenigen, die in den 70er Jahren geboren wurden, hatten in den
> frühen 80er Jahren einen ZX81 oder Spectrum oder was aus der 65xxer
> Riege.

Das war ja meine Generation. Ich sprach von denen, die 10 Jahre früher 
dran waren. Für die war Programmierung an der Uni neu. Die hatten keinen 
Heimcomputer und schon gar keinen PC. Die PCs standen damals in einigen 
wenigen Großfirmen und wurden von internen Mitarbeitern bedient. Daheim 
hatte keiner was. Selbst die Lehrer hatten nichts. Ich erinnere mich 
noch sehr gut an meinen Informatiklehrer, der ganz stolz auf seinen 
ersten VC-20 war und einen Tausender dafür gezahlt hatte. Ich hatte 
meinen zu 598,- beim Conrad bestellt und mich geärgert, dass er nach 6 
Wochen Lieferzeit beim Vobis zu 398,- zu kaufen war. Conrad hat damals 
auf Nachfrage dann den gleichen Preis gemacht.

Davor gab es nur einige PET 2001 an der Schule. An denen haben wir 
Pascal gelernt. Keine Ahnung, was die gekostet haben. Waren sicher 
teuer, da mit Bildschirm und Kassette zum Speichern! Und sie hatten 
mehre KB RAM! :D

Was ich sagen will:

Meine Generation hatte das Glück, genau passend mit den neuen 
Technologien aufzuwachsen, ohne was Wichtiges zu verpassen. Wir waren 
alt genug um noch Elektronik mitzubekommen und jung genug, um schon 
Computer mitzubekommen. Als ich an die Uni kam, kam z.B. gerade die 
erste Ausgabe von Kernighan Ritchie mit ANSI-C raus.


W.S. schrieb:
> Braucht man einen C++ Kurs und einen OS9- und Unix-Kurs, wenn man
> eigentlich das strukturierte und logische Denken hätte erlernen sollen?
Im Studiengang Technische Datenverarbeitung schon. An irgendwelchen 
Beispielen muss man die Strukturen ja auch testen. Und man sollte das 
Gelernte auch real umsetzen können. Im OS9-Labor wurden Treiber mit und 
für echte Hardware entwickelt und im UNIX das pipelining und 
multithreading, sowie Lösungen fürs Philosphenproblem real angewendet. 
Das sind ja die basics, die man braucht.

Die Hardware-Basics die du angesprochen hattest, gab es überdies. Wir 
haben Layouts mit Caddy gemacht, das konnte schon die angesprochene 
Zuordnung von SCH und Components. Mir ist auch nicht klar, warum das bei 
KiCAD so gelöst wurde.

Ach ja und um wieder näher zum Thema zu kommen: Wir hatten Ende der 80er 
auch die Chance, als erste mit FPGAs zu arbeiten. Die Firma Xilinx war 
damals gerade 4 Jahre alt :-)

[W.S. (Gast)]

Jürgen S. schrieb:
> Das war ja meine Generation. Ich sprach von denen, die 10 Jahre früher
> dran waren. Für die war Programmierung an der Uni neu. Die hatten keinen
> Heimcomputer und schon gar keinen PC.

Ach, weißt du, ich kenne das alles. Ich hatte zu meiner Studentenzeit so 
viel Lochband selber wieder aufgewickelt, daß es wohl mindestens zweimal 
um den Äquator gereicht hätte. Und die damaligen Rechner hatten 
Kernspeicher, wurden hauptsächlich in Assembler programmiert und per TTY 
bedient. Kenn ich alles noch.

Aber solche Historie ist auch überhaupt nicht das Thema - sondern ob 
sich eine Hochschule sträflicherweise darauf verläßt, daß die Studenten 
Vorkenntnisse besitzen, die deutlich über das Maß hinausgehen, was zum 
Abitur erforderlich ist. Ich hatte mal zum Schreiben von Dokumentationen 
den Rat bekommen, eine Dokumentation so zu schreiben, als ob sie für 
einen alten Advokaten bestimmt sei. Das ist ein außerordentlich GUTER 
Ratschlag. Der Kernpunkt ist, so zu schreiben (oder zu lehren), daß 
jemand ohne spezifische Vorkenntnisse (ausgenommen diejenigen, die 
eben zu einem Qualitäts-Abitur gehören), aber mit einem wachen und 
scharfen Verstand, mit schneller Auffassungsgabe und mit logischem 
Denkvermögen aus dem Dargebotenen alles davon verstehen kann.

Jürgen S. schrieb:
>> Braucht man einen C++ Kurs und einen OS9- und Unix-Kurs, wenn man
>> eigentlich das strukturierte und logische Denken hätte erlernen sollen?
> Im Studiengang Technische Datenverarbeitung schon. An irgendwelchen
> Beispielen muss man die Strukturen ja auch testen.

Ich bin da anderer Meinung. Ist sowas Inhalt von fakultativen 
Zusatzkursen oder Teil des Studienplanes? Wenn ersteres, dann OK, wenn 
letzteres, dann nicht. Wenn man einen Kurs über irgend ein "Ding" (egal 
ob hard- oder soft-) durchführt, dann läuft das immer nur darauf hinaus, 
das "Ding" vorzustellen und dazu zu sagen "das ist hier eben so". Selbst 
die Frage nach der Ableitung, also das Warum mündet immer nur in "weil 
das eben hier so ist". So etwas ist KEIN Beitrag zu einem wirklichen 
Ingenieurs-Studium, sondern eher ein Training für Kundendienstler, die 
in ihrem Arbeitsumfang keine kreative Tätigkeit haben wie der Ingenieur, 
der Architekt und so, sondern die zu Kunden fahren, um dort die "Dinge" 
in Ordnung zu bringen, zu reparieren oder zu warten, die von der Firma 
an den Kunden ausgeliefert worden sind.

Der Ingenieur braucht den kreativen und mit breitem Basiswissen 
versehenen Geist und der Kundendienstler die tiefere Kenntnis des 
Dinges, was er zu betreuen hat. Das ist ein himmelweiter Unterschied.

Jürgen S. schrieb:
> Wir hatten Ende der 80er
> auch die Chance, als erste mit FPGAs zu arbeiten

Tja, ich hatte damals noch mit Einmal-PAL's zu tun. Irre Stromschlucker! 
Später dann mit GAL's, womit ich einiges gemacht hatte - die digitalen 
Teile der Meßtechnik, aber auch sowas wie ne VGA für die damaligen 
EL-Displays. Später dann vor allem CPLD's. Auch privat. Ist schon ganz 
nett, wenn man das Frontend für seinen Frequenzzähler am Basteltisch mit 
einem kleinen 32er Coolrunner machen kann und damit bis über 720 MHz 
kommt. Da wird die Analogtechnik davor wieder zum Flaschenhals des 
Systems.

Aber ich sehe schon aus deinen Worten, daß es im Argen liegt - sowohl in 
der Lehre seitens der Lehrenden und deren Vorständen als auch bei den 
Studenten, die offenbar an einer Art Saturiertheit kranken und deswegen 
auf Gründlichkeit im Denken keinerlei Wert mehr legen. Final ist das ein 
Zeichen der Dekadenz einer Gesellschaft, so daß es Andere sind, die 
mittlerweile auf der Überholspur sind. Sowas hatte die Menschheit schon 
früher - aber Geschichtskenntnisse sind ja auch rar geworden. Bin 
neulich drüber gestolpert, wo jemand Biedermeier mit Jugendstil in einen 
Topf geworfen hat. Viel weiter als "jaja, war früher mal" reichen auch 
da die Kenntnisse nicht.

W.S.

[Dergute W. (derguteweka)]

Moin,

https://www.heise.de/newsticker/meldung/Von-Sokrates-zum-Smartphone-Warum-Menschen-auf-die-Jugend-schimpfen-4063892.html

SCNR,
WK

[Vancouver (Gast)]

Lol,der Artikel ist Klasse. Ich hab Tränen gelacht. Dabei haben die Kids 
nur den gleichen Unsinn im Kopf wie wir damals, sie nutzen eben dafür 
nur die Mittel von heute, die wir ihnen an die Hand gegeben haben. Wenn 
sich ein paar davon wirklich daneben benehmen, geht das fast immer auf 
das Konto der dekadenten Alten. Die meisten sind ganz OK. Es dauert halt 
a bisserl, bis der Schädel komplett gebootet hat.

[T.U.Darmstadt (Gast)]

Vancouver schrieb:
> Lol,der Artikel ist Klasse.

Tatsächlich nett, beleuchtet das Thema aber vor allem soziologisch. 
Sicher ist ein Teil des Niedergangs der Jugend reine 
Interpretationssache der Älteren, aber:

1) Abgänger von Universitäten sind keine Jugendliche, deren Hirn neu 
booten müsste. Der Bootvorgang, wie du es nennst, läuft in der Pubertät 
und sollte schon seit 10 Jahren abgeschlossen sein. Deshalb sehe ich in 
den 25ern erwachsene Menschen. Nicht wenige haben da bereits Kinder. Der 
Artikel trifft also auf Studenten nicht wirklich zu.

2) Die Altersentwicklung ist nicht linear, man lernt im hohen Alter 
langsamer und reift auch langsamer. Daher ist ein 25er einigermassen 
weit entsickelt und es sollte bei einen Absolventen eine gewisse Reife 
vorliegen, wenn er in den Job kommt. Und egal, wie die Jungen gestrickt 
sind: Wenn Dank G8 Abitur und verkürzer Studiengänge die Menschen 2-3 
jahre jünger sind, dann sind sie auch entsprechend weniger reif, wenn 
sie starten. Die Probleme die da entstehen sind bereits in anderen 
Artikeln soziologisch untersucht. Ich war nebenbei 27, als ich abging. 
Da gab es noch sowas wie Bund.

3) Der Versuch, den jungen Absolventen in der gleichen Zeit mehr 
reinzuprügeln, muss scheitern! Ich zähle mich daher nicht zu den 
Kritikern an den Jungen- sondern an unseren Bildungspolitikern. Ich sehe 
es an meiner Tocher: Die Reife, sich mit politischen Themen zu befassen, 
liegt vor. Ihr Leben kann sie managen und Verantwortung übernehmen, im 
Rahmen ihrer Möglichkeiten. Aber was das Studium angeht, rennt sie 
hilflos von einer Vorlesung in die andere, hat kaum Zeit, alles 
vorzubereiten und kommt gerade so mit. Sie hat Stress ohne Ende. Stress, 
der unter anderem auch davon kommt, dass es zu wenige Wohnungen und 
zuviele Studenten gibt. Sie muss weit und lange fahren und die Busse und 
Bahnen sind voll gestopft. In der Mensa und der Bibliothek muss sie 
25min anstehen, bevor sie rein- oder rauskommt und etwas bekommt. Mit 
dem Auto fahren geht auch nicht, weil Darmstadt komplett zu und Strassen 
dicht. Parkplätze in 2km Entfernung vom Campus.

>Re: VHDL Denken-wie?
Wann soll sie Ruhe finden, um zu denken und die Hausarbeiten zu machen? 
Im Bus gibt es nicht einmal einen Sitzplatz.

4) Diese enorme und nicht benötigte Zahl von Abbrechern und 
Studienprobierern (> 40%!!!!!) kann auf Dauer keine Gesellschaft 
vertragen. Sie kosten viel Geld, nehmen den anderen die Studienplätze 
weg und belegen die Wohnungen und Verkehrsmittel. Hinzu kommt, dass sie 
am Ende frustriert und unzufrieden sind mit ihrem Lebenswert und sich 
die Zeit nicht bezahlt macht. Am Ende fehlen dann Arbeitskräfte auf 
anderen Gebieten. Oder sie schaffen es gerade so und füllen die Klasse 3 
Jobs auf, bei denen unbedingt Studierte genommen werden müssen, die dann 
Technikeraufgaben machen, ohne sie dafür angemessen zu entlohnen. Da 
kommt dann auch ein Rentenproblem auf uns zu!

Ich halte es ebenfalls für nötig, das Studium und Abitur zu reformieren, 
damit den Jungen früher gezeigt wird, wo sie stehen und dass sie für ein 
technisches Studium nicht geeignet sind. Da muss mehr gefiltert werden. 
Ich denke auch, dass eine frühere Spezialisierung nötig ist. Im 
Studiengang Biologie meiner Tochter, hängen eine Reihe von Typen rum, 
die nicht einmal einen Bioleistungskurs hatten, geschweige denn einen 
Matheleistungskurs, der für die Richtung Bioinformatik aber sehr 
hilfreich wäre.

Auf die trifft 200% genau das zu, was W.S. und J.S. schreiben: Es fehlen 
die Grundlagen und sie müssen aufholen. Sie bremsen die anderen ab und 
haben den Hochschulzugang mit völlig anderen Kursen erworben, in einem 
Fall Musik, Deutsch und Sport. Irgendie stimmt da etwas nicht.

W.S. schrieb:
> auf Gründlichkeit im Denken keinerlei Wert mehr legen.

Inzwischen geht meine Kleine freitags in gar keine Vorlesung mehr, 
sondern räumt die Kurse nach hinten, um  Zeit zu haben, etwas Sinnvolles 
zu bearbeiten. Sind dann 3h täglich nutzlose Fahr- und Wartezeiten 
gespart.

[Hans Hämmerle (Gast)]

Thomas U. schrieb:
> Auf die trifft 200% genau das zu, was W.S. und J.S. schreiben: Es fehlen
> die Grundlagen und sie müssen aufholen. Sie bremsen die anderen ab und
> haben den Hochschulzugang mit völlig anderen Kursen erworben,

Grad das ist das Problem, zu glauben in der Schule lerne man 
VHDL-Denken.

Ich behaupte inzwischen die Generation C64 ist näher an den 
Hardware-grundlagen, weil die sich die Grundlagen auf Eigeninitiative, 
also an der Schule vorbei, angeeignet haben. Da hat im 64'er Magazin 
jeden Programmiererkurs durchgelesen, anderen Nerds (oder Papas) Löcher 
in den Bauch gefragt, Hacks auf gut Glück ausprobiert, Nächte vor der 
Kiste verbracht, ... .

Es braucht halt eine gewisse portion Ehrgeiz, den Drang etwas zu 
verstehen, um durch "opferung" von freizeit, das Mehrfache an lenpensum 
durchzuarbeiten, nicht nur die gesellschaftlich akzeptierte 
Minimal-portion.

[Vancouver (Gast)]

Hans Hämmerle schrieb:
> um durch "opferung" von freizeit,

Wieso Opferung? Die nächtlichen Z80-Assembler-Hacks waren die Vollendung 
der Freizeit :-)

Ich erinnere mich noch an meine Assembler-Divisionsroutine, die ich mit 
~15 geschrieben habe. Hat Tage gedauert, bis das richtig lief, mit 
nichts als einer Befehlsreferenz als Literatur und keinem Menschen in 
der Nähe, der auch nur annähernd verstanden hätte, was ich eigentlich 
machen wollte. Das war auf einem Triumph-Adler Alphatronic unter CP/M. 
Das Glücksgefühl damals war unbeschreiblich (das hat natürlich auch 
keiner verstanden).

[Hans Hämmerle (Gast)]

Vancouver schrieb:
> Ich erinnere mich noch an meine Assembler-Divisionsroutine, die ich mit
> ~15 geschrieben habe. Hat Tage gedauert, bis das richtig lief, mit
> nichts als einer Befehlsreferenz als Literatur und keinem Menschen in
> der Nähe, der auch nur annähernd verstanden hätte, was ich eigentlich
> machen wollte.

Schätze man muss den Jungelchens heute noch erklären, was eine 
Befehlsreferenz ist und das man das tatsächlich ohne Makro-Assembler und 
Mnemonics zusammbrachte:

http://www.manmrk.net/tutorials/TRS80/docs/z80chrt.gif

Thats it, alles was man zu assemblerprogrammierung braucht. Und nein, 
das ist kein Unicode-Unfall, das ist (Nerd-) lesbar!

Für den 6502 dann sogar in Farbe:
http://2.bp.blogspot.com/-4P2vylzFAyo/T1GDduB1klI/AAAAAAAAAKg/3XgPvJ7e0Ro/s1600/refcard.jpg

Und auf A4 ohne Lupe lesbar (ja damals waren die Augen noch schärfer)

[Vancouver (Gast)]

Hans Hämmerle schrieb:
> ohne Makro-Assembler und
> Mnemonics

Ich hatte tatsächlich schon einen Macroassembler. Ich musste in bisschen 
überlegen, wie der hieß:
http://altairclone.com/downloads/manuals/Microsoft%20M80%20Assembler.pdf

Ich stelle gerade mit Entsetzen fest, dass der von Microsoft war. Aber 
die waren damals noch ein unbeschriebenes Blatt...

Aber seien wir mal ehrlich: Mit dem Zeug haben sich damals auch nur ganz 
wenige beschäftigt. In meiner Klasse war ich einer von zwei, der Rest 
hatte mit Computern nix am Hut, und Informatik als Schulfach war noch 
nicht in Sicht.

Das ist heute nicht anders. Zwar haben alle ein Smartphone oder einen 
Daddel-PC, aber was darin abgeht wissen nur ein paar Freaks, und die 
hängen meistens im Bastelkeller rum und sind daher unsichtbar. Und 
Informatik in der Schule, das bedeutet Worxcel, HTML und bestenfalls 
Java oder Python.

[J. S. (engineer)]

Hans Hämmerle schrieb:
> Ich behaupte inzwischen die Generation C64 ist näher an den
> Hardware-grundlagen, weil die sich die Grundlagen auf Eigeninitiative,
> also an der Schule vorbei,

Sagen wir mal nicht "an der Schule vorbei" sondern "zusätzlich zur 
Schule". Wir hatten damals durchaus Informatik und Mathe mit Computern. 
Nach der PET2001-Ära wurden so um 1984 direkt C64 er angeschafft. 
Allerdings gab es da nur 2x die Woche Informatik mit insgesamt 3h. Das 
haben wir neben der Schule beim Spieleprogrammieren an einem Nachmittag 
getoppt.


Carl schrieb:
> Und man muss weg lassen, oder sind dir hier alle Techniken bekannt?:
> http://gki.informatik.uni-freiburg.de/teaching/ss14/gki/lecture_de.html

Es sind mehrere Aspekte:

1) Man musste deshalb weglassen, weil früher die Studiengänge 
ausgedehnter waren, was dazu geführt hat, dass viele zu weit überzogen 
hatten. Unser Schnitt lag bei 13,2 Semester für ein Studium, das in 8+1 
hätte absolviert werden sollen. Das hat so gut wie nie einer geschafft 
und wenn, dann nur mit einer theoretischen DA und dem Minimum an 
Fächern. Zusatzkurse, die man aus Interesse belegt hat, sind dann 
keinesfalls möglich.

2) Man musste weglassen, weil man ein bachelor-System aufgezogen hat, 
das in weniger Zeit, als der durchschnittliche FHler hatte, einen 
Studienabschluss produzieren sollte. Da alle zunächst den B machen und 
dann einen M draufsetzen, haben wir besagtes 2 Stufensystem. Das lässt 
sich aber in Breite und Tiefe hinsichtlich der Didaktik niemals so 
optimal verteilen, wie zwei paralle Studiengänge, die von vorn herein 
auf kurz und lang angelegt sind.

3) Ja, man muss auch weglassen, um Neues bringen zu können. Zustimmung! 
Fragt sich aber, ob man damit etwas verlieren muss. Das Einüben von 
Mathematik im C-Programm oder im VHDL kann an klassischer 
Regelungstechnik die Motoren steuert, genau so geübt werden, wie an 
einer FFT oder einem KI-Adaptions-Algorithmus. Das bedingt noch nicht, 
daß man Grundlagen verlieren muss. Die Grundlagen von Mathe, Elektro und 
Physik müssen sitzen. Jedenfalls beim Ingenieur (wir diskutieren ja 
VHDL). Das KI kann man diesbezüglich zumindest teilweise auch als 
Informatikthema werten. Die haben aber von Haus aus schon weniger 
Mechanik und Physik.

Was hier aber konkret kritisiert wurde, ist ja das Fehlen der jeweiligen 
studiengangspezifischen Basics. Und zum Thema VHDL und Hardware sehe ich 
definitiv die Mechanik und die Physik. Natürlich wird ein Ingenieur für 
Signalverarbeitung keine T-Träger für den Bau durchrechnen und er wird 
auch keine Festkörperschwingungen berechnen. Die Formeln und die Denke, 
die man sich bei der Typisierung und Charakterisierung solcher Systeme 
aber aneignet, lassen sich hervorragend übertragen und in 
Simulationssysteme überführen. Es sind ja am Ende immer wieder dieselben 
DGLs, die auftauchen und damit dieselbe Art von Filterung und 
Problemchen.

Und: Egal, ob ein Informatiker oder Mathematiker ganz oder teilweise ein 
theoretisches Gebiet abdecken kann oder sollte und damit viele 
technische Grundlagen für die SW erstmal gar nicht braucht, bleibt es 
ein Fakt, dass alles, was die meisten Mathematiker und Mathematiker in 
der Industrie produzieren, irgendwann in einem technischen Gerät landet. 
Und diese Geräte machen immer das gleiche: Es fließt mechanische oder 
elektrische Energie (= Information!) hinein, wird verrechnet und kommt 
hinten wieder raus. Als Bewegung, als Bild oder als Ton oder als Wert. 
Und da ist sofort die Physik im Spiel und als Zwischenschritt an jeder 
Ecke die Elektronik mit ihren Feldern, den Schwingungen, dem Rauschen, 
Zufall und allem was dazu gehört.

Je mehr man davon hat, desto solider ist das Wissen. Wenn das Fundament 
stimmt, kannst du dir praktisch alles draufladen, was du lernen 
möchtest. Du brauchst nur die Mathe dahinter zu verstehen.

Wenn aber in FHs oder jetzt dem bachlor viel theoretische Mathe, Physik 
und Elektrotechnik fehlt, dann sind die Denkstrukturen nicht da, viele 
der heutigen komplexen Anwendungen zu verstehen.

Ich sehe das sowohl bei industriellen Projekten als auch Studienarbeiten 
immer wieder, dass zwar aufwändige mathematische und signaltechnische 
Arbeiten abgeliefert werden, diese aber an den Notwendigkeiten völlig 
vorbei gehen, weil sie mit der realen Welt nicht zu tun haben.

Die massenhaften Sound- und Tonprojekte an den Hochschulen sind so ein 
Beispiel. Nichts davon kann ein Musiker verwenden, weil die Annahmen und 
Vorgaben schon falsch waren. Auf Bildverarbeitungs- und 
Regeltechnikthemen trifft es ebenso zu. Das was real wirklich Probleme 
macht, wird gar nicht erfasst und auch nicht weggeregelt, weil die 
Problemstellung nicht realitätsbezogen war.

[Hans Hämmerle (Gast)]

Jürgen S. schrieb:
> Hans Hämmerle schrieb:
>> Ich behaupte inzwischen die Generation C64 ist näher an den
>> Hardware-grundlagen, weil die sich die Grundlagen auf Eigeninitiative,
>> also an der Schule vorbei,
>
> Sagen wir mal nicht "an der Schule vorbei" sondern "zusätzlich zur
> Schule". Wir hatten damals durchaus Informatik und Mathe mit Computern.

Njein, schon Zeit nach der Schule zusätzlich, aber eben nicht wie in der 
Schule, also runtergeschluckt was in der Schule vorgekaut, sondern eben 
selbst durchgekämpft und ausprobiert und nicht heulend weggerannt wenn 
was nicht nach Schema F wie unterrichtet tat.

[J. S. (engineer)]

Und mit Bezug zum eigentlichen Thema: Klar, um VHDL zu denken und zu 
schreiben, braucht man erst einmal kein Elektronikwissen und schon gar 
keine Physik. Um aber mit dem VHDL irgendwas Interessantes zu machen, 
außer den Strukturen selbst (also Vernetzung von Components, 
Instanziierung von Modulen, Bildung von Zählern und Ergebnissen) braucht 
es starke Bezüge zu den Inhalten und das Verständnis für die 
Wirkungsketten. Wenn man mit der Digitaltechnik, Transistoren und 
Bauteilen hantiert hat, dann erklären sich eben solche Zusammenhänge, 
was da passiert und wenn man dann noch Halbleitertechnik kennt, dann 
hat man auch eine Idee, warum etwas passiert. Natürlich braucht 
Otto-Normal-Elektroniker keine Energiebänder, Besetzungsstatistik, 
Ladungsträgerbeweglichkeit und Lebensdauer, um eine Schaltung zu bauen, 
wenn die Randbedingungen klar sind.

Wenn du aber so etwas mal formuliert und berechnet hast, dann prägen 
sich die vielen Details ein, die ansonsten verborgen blieben und man 
erkennt sie wieder, wenn sie einem begegnen. Man kann vorhersehen und 
einschätzen,  wann eine simple Formel versagen wird, oder wann bei einem 
Test irgendetwas anderes herauskommt, als es im Buch steht. Und genau 
das passiert sofort, sobald man neue Schaltungen, Verfahren und 
Methoden in eine Elektronik umsetzen will. Wie oben schon angedeutet, 
sind es am Ende immer Messketten und das gilt auch für Schaltungen in 
FPGAs. Die Art dem Umsetzung mag bisweilen trivial sein, aber das was 
eingebaut werden muss, um sicher zu messen, zu rechnen und mit dem 
Reinkommenden umzugehen, muss irgendwann von irgendwem designed werden.

Mit VHDL oder C oder MATLAB löst man keine Konzeptproblem oder versteht 
die Umgebung. Das Verständnis muss in der nötigen Tiefe vorher gelegt 
worden sein. Die kommen leider beim beruflichen Arbeiten nicht von 
alleine und viele sind einfach zu komplex und können nicht eingeordnet 
werden, wenn die grundlegenden Zusammenhänge nicht klar sind.

Solche Grundlagen später nach Bedarf nachzulernen, ist aber nicht 
einfach. Bisweilen ist es sogar ziemlich unmöglich, weil sie stark 
aufeinander aufbauen und in kurzer Zeit komprimiert erfasst werden 
müssen, wenn man den dazugehörigen Unterbau von der parallelen Vorlesung 
dazu noch im Kopf hat. Solches Wissen muss didaktisch klug aufgebaut 
werden, sonst weiß man nicht, wo man beim Selbstudium anfangen soll. Und 
es ist nunmal eine Tatsache, dass man ab 30 nicht mehr so leicht lernt, 
wie mit 20, daher ist es unerlässlich, die komplizierte Mathe hinter all 
dem früh und kompakt zu erfassen. Man hat dann später noch Aufwand 
genug, um sich in ein neues Verfahren reinzudenken, dass man nicht 
kennt. Es funktioniert aber, weil man Analogien wiedererkennt.

Wenn ich mir aber vorstelle, ich müsste mir z.B. jetzt die gesamte 
erweiterte Mathe selber erarbeiten, die wir im HSII gegenüber der FH 
hatten (und das waren die wirklich interessanten 50%!, gegenüber dem in 
den ersten Semestern) dann würde ich ganz sicher kapitulieren. Habe 
letztens mal meine alten Unterlagen Mikroelektronik wiedergefunden: Auf 
der ersten Seite wird erstmal die Schrödingergleichung dazu verwendet, 
um Energieniveaus zu definieren, mit denen man dann später durch 
Vereinfachungen zu Bestimmungsgleichungen für die Vorgänge in den 
Kristallen kommen kann. Die Formeln für den MOS-Transistor mit allen 
Abhängigkeiten von Dotierungen, Temperatur, Spannung und Geometrie gehen 
trotzdem über 2 volle DIN-A4-Seiten. Das bringst du dir nicht mal eben 
selber bei.

Weniger komplexe Dinge lernt man dann durchaus, auch wenn es ein völlig 
neues Thema ist.

[J. S. (engineer)]

Hans Hämmerle schrieb:
> selbst durchgekämpft und ausprobiert

Sicher. Es ist aber schon so, dass man da weniger komplexe Dinge macht. 
Programmieren auf dem Niveau von Schuldkindern hat seine Grenzen, auch 
wenn es trickreiches gibt. Da geht es auch viel um Sachwissen. Und da 
ist Zeit der entscheidende Faktor!

In der hat man die vielen kleinen Schnipsel aufgesammelt und die 
Anfängerfehler gemacht, die Studenten, die das nicht getan haben, später 
in den Laboren im Weg rumlagen und sie zum Stolpern brachten.

http://gki.informatik.uni-freiburg.de/teaching/ss14/gki/lecture_de.html

Klar kenne ich das nicht alles. Aber Vieles erkenne ich direkt aus der 
Regelungstechnik (Estimationstheorie) und der Nachrichtentechnik 
(Heuristik) wieder. Die Begriffe sind z.T. sogar identisch und dürften 
von dort übernommen worden sein. Dazu gibt es eine ganze Menge 
Begrifflichkeiten, die definierte Bedeutungen haben und das Thema 
strukturieren helfen. Ohne das Abzuwerten, ist das Sachwissen, das man 
durch Zeiteinsatz lernen kann, ebenso wie die jeweils benutzte 
Formelsprache. Von der logischen Wertigkeit und dem Strukturwissen, ist 
das eigentlich leicht einzuordnen:

Letztlich rankt es sich ja wieder um die Thematik, Vorgänge zu 
klassifizieren und Aufwände beim Suchen von Lösungen sowie die Qualität 
von Ergebnissen irgendwie mit Gütekriterien zu belegen und damit 
mathematisch bewertbar zu machen, um die Ergebnisse zu optimieren, sie 
an Randbedingungen anzupassen und dazu noch die Algorithmen dahin 
vereinfachen und beschleunigen zu können.  Ich sehe da starke Analogien 
zur FEM in der Mechanik, der nichtlinearen Regelungstechnik, dem 
simulierten anealing bei Platzierungsproblemen und der Optimierung von 
Testmustermengen bei Chips mittels abstrakter 
Schaltungsknotenfehleranalyse. All diese Felder wollen Problemlösungen 
finden und zusätzlich auch noch per autoadaptiver Regelschleife den Weg 
zur Problemlösung finden, oder wenigstens optimieren. Ein nicht 
unerheblicher Teil dessen, was heute unter "KI" zusammengefasst wird, 
gab es durchaus schon vor 30 Jahren und es wurde auch umgesetzt. Dass 
das Thema boomt liegt vor allem auch in der Verfügbarkeit der Maschinen.

Ich finde Transformationen von Räumen in andere mathematische Räume mit 
Prüfung der Machbarkeit und deren Lösung in noch dazu anderen 
Koordinatensystemen deutlich anspruchsvoller, weil nicht direkt 
begreifbar und oft nicht vorstellbar.

[Richard B. (r71)]

Lothar M. schrieb:
> warum beharren Ballonfahrer eigentlich so vehement darauf, dass
> sie nicht fliegen.

Ein Ballonfahrer bewegt sich mit der Luft (er steht),
nicht durch die Luft (der fliegt).

[Informationsverarbeiter (Gast)]

Richard B. schrieb:
> Lothar M. schrieb:
>> warum beharren Ballonfahrer eigentlich so vehement darauf, dass
>> sie nicht fliegen.
>
> Ein Ballonfahrer bewegt sich mit der Luft (er steht),
> nicht durch die Luft (der fliegt).

Schön, dass wir so wichtige Dinge noch am Freitag klären konnten.

Ich werfe aber noch ein, dass der Ballon eben nicht in der Luft steht, 
sondern sich durch sie hindurch bewegt, weil die Ballonmasse träge ist. 
Das heisst, der schiebt sich durchaus schneller durch die Luft, wenn die 
sich ändert, oder auch langsamer.

Der Ballon ist sozusagen ein Tiefpass und mittelt die Geschwindigkeit 
der Luft. Da der Korb Luftwirbel erzeugt, wird diese Geschwindigkeit 
unterhalb des Mittels der Luftgeschwindigkeit liegen.

Der Ballon fliegt also nicht aktiv durch die Luft und er fährt auch 
nicht, sondern der schwimmt, wie Treibgut im Wasser.

Ballonbenutzer TREIBEN in der Luft.

[Informationsverarbeiter (Gast)]

Hans Hämmerle schrieb:
> Thomas U. schrieb:
>> Auf die trifft 200% genau das zu, was W.S. und J.S. schreiben: Es fehlen
>> die Grundlagen und sie müssen aufholen. Sie bremsen die anderen ab und
>> haben den Hochschulzugang mit völlig anderen Kursen erworben,
>
> Grad das ist das Problem, zu glauben in der Schule lerne man
> VHDL-Denken.

Ich stelle jetzt einfach einmal die Frage, wo man das VHDL-Denken lernt? 
VHDL ist eine Sprache mit ganz bestimmten Eigenheiten, z.B. indirekt 
formulierten Zeitschritten. Reicht da das blosse Kennen digitaler 
Hardware?

Übrigens ein sehr guter Artikel von Thomas:
Beitrag "Re: Technische Grundlagen und Studentenflut"

100% d'accord!

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

Informationsverarbeiter schrieb:
> Ich stelle jetzt einfach einmal die Frage, wo man das VHDL-Denken lernt?

Nicht das Wo sondern das Wie ist entscheidend. Und das ist wie bei allem 
anderem im Leben auch: Ueben, ueben, ueben.

Am besten einfach mal loslegen und wenn man stolpert, dann nachforschen 
wo Defizite und Wissensluecken sind und diese aufarbeiten. Kann man 
vielleicht am ehesten mit Klavierspielen vergleichen. Einfach drauf 
losklimpern, dann erste einfache Melodien lernen und je besser man 
werden will, deto tiefer muss man zwangsweise auch das Instrument und 
die Notentheorie dahinter verstehen.

[Richard B. (r71)]

Informationsverarbeiter schrieb:
> Schön, dass wir so wichtige Dinge noch am Freitag klären konnten.

Eigentlich habe ich andere Infos gesucht...

EDIT: Ich habe gerade ein Mojo 3 bzw. CYC1000 bestellt.

[Thomas W. (diddl)]

Richard B. schrieb:
> EDIT: Ich habe gerade ein Mojo 3 bzw. CYC1000 bestellt.

Der Mojo und die Tutorials da auf der Seite von Alchitry haben mir sehr 
geholfen.

Der lehrt da zwar Verilog, aber der Umstieg auf VHDL ist dann sehr 
angenehm.

[Mike (Gast)]

Man kann sich VHDL vorstellen wie eine textuelle Art einen Schaltplan zu 
zeichnen. Signale sind dabei die Verbindungen und Ports die 
Anschlussbeinchen von Komponenten. In den Komponenten steckt dann die 
Beschreibung der Komponente, welche wiederrum aus Flipflops und 
Logik-Gattern zusammengesetzt ist.Heraus kommt dann eine Schaltung. Das 
ganze ist hirarchisch organisiert, wobei Schaltungen in Schaltungen 
stecken können (beliebig verschachtelt)

Es gibt sogar Programme, die einen Schaltplan in VHDL umwandeln. Hier 
sieht man schön die starke Verwandschaft beider Welten.

Allerdings gibt es innerhalb der Strukturen, welche man in VHDL abbilden 
kann durchaus "Programme". Wenn man zum Beispiel eine State-Machine 
aufbaut, werden innerhalb dieser durchaus programmartig nacheinander 
(Clock-Snychron) Schritte abgearbeitet oder Berechnungen durchgeführt. 
Man muss aber immer bedenken, dass diese Struktur letztlich eine 
Schaltung darstellt.

[Sigi (Gast)]

Mike schrieb:
> Signale sind dabei die Verbindungen

Nein, wird zwar oft so beschrieben, sie haben
aber mit (einfachen) Verbindungen kaum etwas
zu tun. VHDL ist eine Beschreibungssprache,
die nicht nur für nur für Hardwarebeschreibung,
sondern auch für Verifikation, Programmierung
und vieles mehr entwickelt wurde. Darin sind
Signale, ähnlich wie auch Variablen, abstrakte
Konzepte, beschrieben durch die VHDL-Specs.

[Hans (Gast)]

Sigi schrieb:
> Mike schrieb:
>> Signale sind dabei die Verbindungen

Signale sind LOGISCHE Verbindungen, also Zuweisungen.
Es sind also zunächst keine Leitungen.
Daher verschwinden sie auch gerne mal.

[T.U.Darmstadt (Gast)]

Hans Hämmerle schrieb:
> Ich behaupte inzwischen die Generation C64 ist näher an den
> Hardware-grundlagen, weil die sich die Grundlagen auf Eigeninitiative,
> also an der Schule vorbei, angeeignet haben

Das ging damals aber auch noch, bei der sehr überschaubaren Hardware.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Mike schrieb:
> Signale sind dabei die Verbindungen
Allerdings können die dermaßen deklarierten "Verbindungen" auch einen 
Zustand oder Wert speichern...  :-o

[Hans (Gast)]

Lothar M. schrieb:
> Mike schrieb:
>> Signale sind dabei die Verbindungen
> Allerdings können die dermaßen deklarierten "Verbindungen" auch einen
> Zustand oder Wert speichern...  :-o

Ich bin erstaunt, Lothar. Ein Signal kann zunächst nichts speichern. 2 
Signale, vor und nach einem FF können das.

[Christoph Z. (christophz)]

Hans schrieb:
> Ich bin erstaunt, Lothar. Ein Signal kann zunächst nichts speichern. 2
> Signale, vor und nach einem FF können das.

Hier sind wir genau am Kern dieses Threads. Ein VHDL Signal muss nicht 
mit einem Kabel verwechselt werden.

Je nach dem, wie man ein System in VHDL modelliert, ist das FF im VHDL 
Signal versteckt, oder man kann es auch so schreiben, dass zwei Signale 
verwendet werden. Das ist eine Stilfrage.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Hans schrieb:
> Ein Signal kann zunächst nichts speichern. 2 Signale, vor und nach einem
> FF können das.
Diese "Signale" auf der Hardware sind eben keine "Signale" im Quellcode. 
Ein Signal in VHDL hat also prinzipiell keinerlei Entsprechung in der 
Realität. Wenn ein "Signal" getaktet ist oder als ein Latch beschrieben 
wird, dann speichert es und es wird ein Flipflop/Latch daraus gemacht. 
Wenn ein Signal nur zum Routing verwendet wird, dann wird es meist vom 
Synthesizer beliebig wegoptimiert, zusammengefasst, verdoppelt oder 
sonstwas damit gemacht.

Ich nehme mal diesen Quellcode:

library ieee;
use ieee.std_logic_1164.all;

entity xxx is
  port(
    clk   : in  std_logic;
    i     : in  std_logic;
    o     : out std_logic); 
end entity xxx;

architecture behavioral of xxx is

signal a,b,c,d,e,f,g,h : std_logic;

begin
 a <= i;       
 b <= a;
 c <= b;
 d <= c;
 e <= d when rising_edge(clk);
 f <= e when rising_edge(clk);
 g <= f; 
 h <= g; 
 o <= h; 
end architecture behavioral;

Hier bleibt nach dem Synthesizer nur das namentliche Signal e übrig.
Die Signale a..d werden ersatzlos gestrichen, i geht direkt an das erste 
von 2 nacheinander geschalteten Flipflops, die namentlich e und f 
heißen. Und zwischen den beiden FFs ist eine Verbindung, die 
einfallsreicherweise ebenfalls e heißt. Die VHDL-Signale f..h tauchen in 
der Hardware nirgends mehr auf.

Deshalb ist für mich ein getaktetes Signal speichernd und ich sehe im 
Geiste dieses Signal nicht als Verbindungsdraht, sondern als Flipflop. 
Das ist das, was ich als "in Hardware denken" bezeichne: ich denke mir 
die nötigen Bauteine und schreibe den VHDL-Code so, dass der Synthesizer 
mir diese mit VHDL beschriebene Schaltung generiert.

Und wenn man sich dann abschließend den Technologieschaltplan anschaut, 
dann sieht man auch gleich, dass das erste FF hier dank Nichtverwendung 
von e im Design auch gleich noch wegoptimiert und in ein einstufiges 
Schieberegister (das platzsparenderweise in der LUT vor dem FF des CLB 
implementiert wurde) umgesetzt wurde.

Man sollte sich in der Lernphase diese aus der VHDL Beschreibung 
entstandenen Schaltpläne ruhig ab&zu mal ansehen und schauen, ob man die 
gewünschte Schaltung darin wiederfindet...

[J. S. (engineer)]

Christoph Z. schrieb:
> Hier sind wir genau am Kern dieses Threads. Ein VHDL Signal muss nicht
> mit einem Kabel verwechselt werden.
Sehr richtig, die grafischen Eingabesystem suggerieren aber genau das. 
Vlt kommt es daher. Ein Signal ist mehr etwas Theoretisches, also eine 
Art Meldung. Eine logische Datenleitung.

Lothar M. schrieb:
> Man sollte sich in der Lernphase diese aus der VHDL Beschreibung
> entstandenen Schaltpläne ruhig ab&zu mal ansehen und schauen, ob man die
> gewünschte Schaltung darin wiederfindet...
Das kann in der Tat nicht schaden. Allerdings entziehen sich viele 
Konstrukte (gerade die Mathematischen) und inplizite Schleifen 
geometrischer Betrachtungen auf Schalplannieveau.

[J. S. (engineer)]

Noch ein kleiner Einwurf noch zu dem Strang "KI" in diesem thread:

Carl schrieb:
> Oder wer kennt sich hier schon mit den algoritmischen Methoden der KI
> aus?
Ich linke mal meine "Schach-KI", die ich gerade in einem anderen Thema 
schrieb und die auch hier hin gepasst hätte. Diese hatte ich angeregt 
durch ein solches, o.g. ->Unix-Praktikum mal angesetzt.

Beitrag "Re: Schachcomputer Eigenbau?"

Das -> goal in diesem Fall war die Definition der richtigen 
Gewichtungswerte für die Stellung. Der KI-Aspekt dabei wäre nun, per 
Schleifenoptimierung die genannten Werte zu optimieren und die Lösungen 
zusätzlich von Menschen bewerten zu lassen.

Mit Bezug zum VHDL-Denken stelle ich die Frage, wie man es in VHDL lösen 
könnte. (und ob das ein Vorteil wäre)

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Jürgen S. schrieb:
> Allerdings entziehen sich viele Konstrukte (gerade die Mathematischen)
> und inplizite Schleifen geometrischer Betrachtungen auf
> Schalplannieveau.
Durchaus. Deshalb schrieb ich "Lernphase". Denn einer, der komplexere 
Schaltungen mit VHDL beschreibt, hat das "VHDL-Denken" soweit 
hoffentlich schon verinnerlicht...  ;-)