mikrocontroller.net

Forum: FPGA, VHDL & Co. VHDL Denken-wie?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Fred (Gast)
Datum:

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

Autor: $$$ (Gast)
Datum:

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

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

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

Autor: Random .. (thorstendb) Benutzerseite
Datum:

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

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

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

: Bearbeitet durch Moderator
Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

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

Autor: Schlumpf (Gast)
Datum:

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

Beitrag #5845032 wurde vom Autor gelöscht.
Autor: Fred (Gast)
Datum:

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

Autor: Fred (Gast)
Datum:

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

Autor: Schlumpf (Gast)
Datum:

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

Autor: Michael B. (laberkopp)
Datum:

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

: Bearbeitet durch User
Autor: Random .. (thorstendb) Benutzerseite
Datum:

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

: Bearbeitet durch User
Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

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

: Bearbeitet durch Moderator
Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

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

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

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

: Bearbeitet durch Moderator
Autor: Schlumpf (Gast)
Datum:

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

Autor: Schlumpf (Gast)
Datum:

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

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

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

Autor: Schlumpf (Gast)
Datum:

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

Autor: Marcus H. (mharnisch) Benutzerseite
Datum:

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

Autor: Frage (Gast)
Datum:

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

Autor: Markus W. (elektrowagi78) Benutzerseite
Datum:

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

Autor: PittyJ (Gast)
Datum:

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

Autor: Carl (Gast)
Datum:

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

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

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

: Bearbeitet durch Moderator
Autor: Vancouver (Gast)
Datum:

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

Autor: Schlumpf (Gast)
Datum:

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

Autor: Strubi (Gast)
Datum:

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

Autor: Carl (Gast)
Datum:

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

Autor: Christophz (Gast)
Datum:

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

Autor: Hans Hämmerle (Gast)
Datum:

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

Autor: Schlumpf (Gast)
Datum:

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

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

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

Autor: Schlumpf (Gast)
Datum:

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

Autor: Carl (Gast)
Datum:
Angehängte Dateien:

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

Autor: Fred (Gast)
Datum:

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

Ja, danke dir.

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

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

Autor: W.S. (Gast)
Datum:

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

Autor: W.S. (Gast)
Datum:

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

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?
;-)

Autor: Schlumpf (Gast)
Datum:

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

Autor: Hans Hämmerle (Gast)
Datum:

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

Autor: Carl (Gast)
Datum:

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

Autor: Hans Hämmerle (Gast)
Datum:

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

Autor: Fred (Gast)
Datum:

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

Autor: Carl (Gast)
Datum:

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

Autor: berndl (Gast)
Datum:

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

Autor: Robert K. (Firma: Medizintechnik) (robident)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Je paralleler, desto weniger
> Gatterlaufzeiten hat man nacheinander

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

Autor: W.S. (Gast)
Datum:

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

Autor: Weltbester FPGA-Pongo (Gast)
Datum:

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

Autor: Schlumpf (Gast)
Datum:

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

Autor: Schlumpf (Gast)
Datum:

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

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

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

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

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

: Bearbeitet durch User
Autor: Jürgen S. (engineer) Benutzerseite
Datum:

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

: Bearbeitet durch User
Autor: Jürgen S. (engineer) Benutzerseite
Datum:

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

: Bearbeitet durch User
Autor: Jürgen S. (engineer) Benutzerseite
Datum:

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

Autor: Carl (Gast)
Datum:

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

Autor: Markus F. (mfro)
Datum:

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

Autor: C. A. Rotwang (Gast)
Datum:

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

Autor: Markus F. (mfro)
Datum:

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

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

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

: Bearbeitet durch Moderator
Autor: Hallo (Gast)
Datum:

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

Autor: Hans Hämmerle (Gast)
Datum:

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

Autor: Schlumpf (Gast)
Datum:

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

Autor: Yalu X. (yalu) (Moderator)
Datum:

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

Autor: Schlumpf (Gast)
Datum:

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

Autor: Dussel (Gast)
Datum:

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

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

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

Autor: Schlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich stimme dir 100%ig zu, Lothar und sehe es genau so.

Autor: Hans Hämmerle (Gast)
Datum:

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

Autor: Markus F. (mfro)
Datum:

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

Autor: Hans Hämmerle (Gast)
Datum:

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

Autor: W.S. (Gast)
Datum:

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

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

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

Autor: Markus F. (mfro)
Datum:

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

Autor: Hans Hämmerle (Gast)
Datum:

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

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

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

Autor: Vancouver (Gast)
Datum:

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

Autor: Hans Hämmerle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
Youtube-Video "Books for Learning FPGA Design"

Aber bei manchen leser ist halt Hopfen und Malz verloren.

Autor: Schlumpf (Gast)
Datum:

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

Autor: Peter B. (funkheld)
Datum:

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

Autor: FPGA zum Spass (Gast)
Datum:

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

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

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

: Bearbeitet durch Moderator
Autor: C. A. Rotwang (Gast)
Datum:

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

Autor: Christophz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Versuch einer Zusammenfassung:

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

Autor: Vancouver (Gast)
Datum:

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

Autor: VHDL hotline (Gast)
Datum:

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

Autor: Schlumpf (Gast)
Datum:

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

Autor: Dussel (Gast)
Datum:

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

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

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

Autor: Markus F. (mfro)
Datum:

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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

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