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
> 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.
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...
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.)
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:
1 | :
|
2 | signal as, bs, cs : std_logic; |
3 | :
|
4 | variable av, bv, cv : std_logic; |
5 | :
|
6 | process begin |
7 | wait until rising_edge(clk); |
8 | |
9 | bv := av; |
10 | cv := bv; |
11 | |
12 | bs <= as; |
13 | cs <= bs; |
14 | |
15 | 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:
1 | signal a, b, c, d : std_logic; |
2 | |
3 | process begin |
4 | wait until rising_edge(clk); |
5 | |
6 | b <= a; |
7 | c <= b; |
8 | d <= c; |
9 | |
10 | end process; |
11 | |
12 | |
13 | process begin |
14 | wait until rising_edge(clk); |
15 | |
16 | d <= c; |
17 | c <= b; |
18 | b <= a; |
19 | |
20 | 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
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.
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.
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?
Ein Code mit State machines verwirrt mich irgendwie ein bisschen, weil es mir schwer fällt sie als Schaltung vorzustellen.
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)
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
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
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
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:
1 | process(clk, ...) |
2 | begin
|
3 | if rising_edge(clk) then |
4 | ...
|
5 | end if; |
6 | 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.
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
Beispiel: Außerhalb eines process ist alles "gleichzeitig".
1 | architecture Behavioral of xxx is |
2 | signal a, b, c : std_logic; |
3 | begin
|
4 | a <= b; |
5 | a <= c; |
6 | 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:
1 | architecture Behavioral of xxx is |
2 | signal a, b, c : std_logic; |
3 | begin
|
4 | process begin |
5 | a <= b; |
6 | a <= c; |
7 | end process; |
8 | 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:
1 | architecture Behavioral of xxx is |
2 | signal a, b, c : std_logic; |
3 | begin
|
4 | a <= c; |
5 | end Behavioral; |
In einem process, der sequenzielle Logik beschreibt, kommt der Takt mit ins Spiel:
1 | architecture Behavioral of xxx is |
2 | signal a, b, c : std_logic; |
3 | begin
|
4 | process begin |
5 | wait until rising_edge(CLK); |
6 | a <= b; |
7 | end process; |
8 | 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.
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)
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... ;-)
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.
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.
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.
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?
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'.
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.
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
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.
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.
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".
>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
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.
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.
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.
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...
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.
Angehängte Dateien:
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?
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).
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.
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.
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? ;-)
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.
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.
>BTW: warum beharren Ballonfahrer eigentlich so vehement darauf, dass >sie nicht fliegen. Obwohl das von unten/aussen irgendwie ganz ähnlich >aussieht? >;-) Ja, das ist in der Tat der gleich Quatsch.
Hans Hämmerle 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.
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.
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
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).
W.S. schrieb: > Je paralleler, desto weniger > Gatterlaufzeiten hat man nacheinander Seit wann gibt es eine graduelle Abstufung der Parallelität?
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.
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.
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!
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.
> 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 :-)
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
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
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
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.
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
1 | process
|
2 | begin .. |
3 | wait until rising_edge( clk ); |
4 | ...
|
anstatt
1 | process(clk) |
2 | begin
|
3 | if (clk'event and clk='1') then |
4 | ..
|
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).
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, ...
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 ;)
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...:
1 | process (a) begin |
2 | :
|
3 | :
|
4 | end process; |
...exakt das selbe wie das hier:
1 | process begin |
2 | wait until a; |
3 | :
|
4 | :
|
5 | end process; |
Allerdings bietet im Fall "kombinatorischer Prozess" die Sensitivliste einen Vorteil, denn wie würde man sowas mit wait until schreiben:
1 | process (a, b, c, d) begin |
2 | :
|
3 | :
|
4 | 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
"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.
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.
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!
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).
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.
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.
Schlumpf schrieb: > dann beutet das Verb "programmieren" Es mag schon durchaus sein, das "programmieren" alles Mögliche bedeutet. Aber der Begriff ist eben für den (sagen wir mal beispielsweise) "Betriebswirt" mit einer ziemlich speziellen Vorgehensweise vorbelegt. Und auch für Softwareentwickler ist das Wort "programmieren" sehr mit einer bestimmten Arbeitsstrategie (die nach meiner Beobachtung erstaunlich viel mit "Try&Error" zu tun hat) verwandt. Und diese allgemein bekannten und mit dem Wort "programmieren" verbundenen Denkweisen und Strategien führen eben bei der FPGA-Entwicklung viele in die Irre. Einige davon tauchen dann hier mit ihren Fragen nach syntaktischen Feinheiten auf und/oder klammern sich an formalen Definitionen der Sprache fest. Ganz nach dem Motto: "Wenn ich diese Zeile dann fehlerfrei durch den Compiler/Synthesizer bekomme, dann muss das aber laufen!"
Schlumpf 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/
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.
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.
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.
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.
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.
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.
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.
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.
W.S. schrieb: > Hier geht es nicht um's Verstehen von FPGA's, sondern um die noch immer > offensichtlich zu miese Literatur zum Verstehen von und dem richtigen > Umgang mit VHDL. Es gibt gute Literatur zu VHDL, schon seit Jahrzehnten, musst halt nur die FPGA-Experten nach Empfehlung fragen: https://www.youtube.com/watch?v=kobf8IOB0oA Aber bei manchen leser ist halt Hopfen und Malz verloren.
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.
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
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...
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
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.
Der Versuch einer Zusammenfassung: "Idee-->Vorstellung wie eine RTL Struktur dazu aussieht (Abstrahierte Hardware Sicht)-->VHDL-->Toolchain-->Reale Hardware"
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.
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.
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).
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
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.
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.
Andreas S. schrieb: > Nachdem mehrere Baugruppen durch ähnliche Vorgaben ziemlich verhunzt > wurden, konnte ich bei dem Kunden durchsetzen, dass der Produktmanager > nur noch Spezifikationen erstellen darf und seine Detailkonzepte nur als > Ideen oder Vorschläge anzusehen sind. Glücklich, wenn man sich da durchsetzen kann. Leider stecken in vielen Firmen selbsternannte FPGA-Experten, die aus der Softwareecke kommen oder sonst woher. Die denken schwarz-weisß, haben bisweilen total absurde Vorstellungen, die darauf gründen, dass sie entweder persönlich wo reingefallen sind oder was aufgeschappt haben, oder ihnen irgendwas von Mathworks unter die Nase gerieben wurde. Dann meiden sie Dinge oder propagieren sie wie von Gott gegeben. Daraus resultieren die abenteuerlichsten Vorgaben, die unweigerlich zu Konflikten führen, wenn der Entwickler anders denkt, oder nur andeutet, anders zu denken. Ich hatte vor Jahren ein Einstellungsgespräch bei einer Firma im Ländle, die sich mit militärischer Signalverarbeitung befasst und u.a. Funkgeräte baut. Die suchte dringend nach fähigen Entwicklern und hat so hohe Ansprüche, dass sie nach eigenen Aussagen schon mehrfach welche wieder freisetzen mussten. Dort traf ich im zweiten Gespräch auf den leitenden FPGA-Entwickler, der mir seine Vorstellungen von einem guten FPGA-Design erklärte und meine Meinung dazu hören wollte. Die habe ich ihm mitgeteilt und verdeutlicht, dass seine Art der Verifikation so eher wenig Sinn macht, nicht allviel überprüft, oft unlogisch und unnötig ist, während andere Dinge ausgelassen würden, die wichtiger sind, obwohl leicht und automatisiert machbar. Der hatte den Sinn und Zweck von Verifikation nicht verstanden und meinte, mit allein den constraints passe das schon. Diskusions und Vorgehensweisen waren recht antiquiert, erinnerten mich irgendwie an DDR-Mentalität. Viele der Leitenden sind self-made-Entwickler, haben das nie richtig gelernt, sondern sich selber angeeignet und leben in einer Scheinwelt, die sie sich zusammengereimt haben. Da spielt auch mit, dass moderne Verfahren noch nicht gelehrt wurden, als die an den Hochschulen waren. Wenn dann nicht regelmäßig Personen reinkommen, die sie in der Spur halten, driften die komplett weg. Schwierig wird es natürlich, wenn infolge der Diskrepanzen erst gar keine gut Ausgebildeten und Erfahrenen reingenommen werden und sogar welche kündigen, um dem Quark zu entfliehen. Da hält man sich dann lieber fern und verzichtet auf den Job. Im Nachhinein habe ich auch erfahren, dass der Leiter sowieso jemanden anderen aus einer anderen Abteilung haben wollte, aber nicht einstellén durfte. Der Grund war interessant: Der Typ war angeblich mit einer Chinesin zusammen und galt daher als unzuverlässig. Er könnte intern durch die Gesinnungsprüfung fallen.
Peter B. schrieb: > So etwas muss im Hauptprogramm enthalten sein , so das man das > Zeitverhalten nicht noch erst mit einem neuen Programm suchen muss wo > "lachnummer" wieder neue Fehler entstehen können. Wenn ich mich erinnere, was Herr Bierbach vor rund 2 Jahren so hier im Forum geschrieben hat, als er erstmal aufgetaucht ist und das Forum mit Anfängerfragen zugeplärrt hat, verwundert mich diese Haltung nicht. Die Unsinnigkeit der Forderung und damit zugleich die Sinnhaftigkeit von Modelsim erschließlich sofort, wenn man den Vergleich von ASM zu VHDL in der richtigen Weise zieht: C und ASM werden auch durch modellierung simuliert. In ASM nennt sich das tracen und haben wir schon am C64 mit einem Disassembler gemacht. In C lassen sich ebenfalls Simulatoren einsetzen. Das macht nur kaum jemand, weil sich C stufenförmig entwickeln lässt und mitsamt den vorcompilierten Libs recht rasch in ein ablauffähiges Programm übersetzen lässt, welches man laufen lassen kann. Da ist viel mit realem Tempo und Debugger machbar (und auch der braucht noch etwas Extra Code). In FPGAs geht das so nicht. Das tun manche zwar, indem sie Code reinhacken und ohne Simulation austesten. Sie fühlen sich großartig, weil sie was Tolles zu können glauben (siehe den S.pezial I.ntegrations T.yp in meinem Beitrag eins weiter oben) aber sie verkennen, dass das extram umständlich und langsam ist, und dass sie viele mögliche Fehler übersehen, weil sie sie im Test gar nicht abbilden (können).
Weltbester FPGA-Pongo schrieb im Beitrag #5857056: > Der Grund war interessant: Der Typ war angeblich mit einer > Chinesin zusammen und galt daher als unzuverlässig. Er könnte intern > durch die Gesinnungsprüfung fallen. Bei geheimschutzbetreuten Projekten, die eine Sicherheitsüberprüfung (Ü1/2/3) der eingesetzten Mitarbeiter benötigen, erstreckt sich diese auch auf den/die Lebenspartner(in). Mir sind auch zwei Fälle bekannt, in denen die Geheimschutzermächtigung ausschließlich auf Grund der Nationalität der jeweiligen Ehefrau bzw. Freundin versagt wurde. Bei so etwas hat der Arbeitgeber auch wenig mitzureden, sondern die Überprüfung und Ermächtigung erfolgen durch das Bundeswirtschaftsministerium, das ggf. mit anderen Behörden (Verfassungsschutz, usw.) zusammen arbeitet.
Andreas S. schrieb: > Weltbester FPGA-Pongo schrieb im Beitrag #5857056: >> Der Grund war interessant: Der Typ war angeblich mit einer >> Chinesin zusammen und galt daher als unzuverlässig. > > Bei geheimschutzbetreuten Projekten, die eine Sicherheitsüberprüfung > (Ü1/2/3) der eingesetzten Mitarbeiter benötigen, erstreckt sich diese > auch auf den/die Lebenspartner(in). Sicher? M.W. wird der Lebenspartner o.ä. erst für Ü2 und Ü3 mitüberprüft: https://www.juraforum.de/lexikon/sicherheitsueberpruefung Ü1 ist Pillepalle. >> Er könnte intern >> durch die Gesinnungsprüfung fallen. Nicht Gesinnungs- sondern Sicherheitsüberprüfung. Und ja, bei emotionaler und sexualler Abhängigkeit von einer Chinesin besteht schon das Risiko, das diese geleitet von (Rot-)Chinesischem Patriotismus, den von ihr abhängigen manipuliert. Oder im Sinne eines kleinen Nebenerwerbs Informationen abschöpft.
Zyniqer schrieb: > Oder im Sinne eines kleinen Nebenerwerbs > Informationen abschöpft. Das erfordert aber die Mitwirkung des bei der Firma beschäftigten Eheparters, denn nur er könnte ja seine ausländische Frau einschleusen oder einweihen. Damit reduziert sich die Thematik darauf, nicht jedem x-beliebigen Mitarbeiter alles zugänglich zu machen und zugleich es zu verungmöglichen, dass Frauen mit in die Abteilung kommen. Insoweit jemand mit etwas Wichtigem betraut ist, muss man sich ohnehin drauf verlassen, dass er nicht mitnimmt und das ist Vertrauenssache. Zwar kann man jemandem untersagen, daheim darüber zu sprechen, aber ob ob er sich dran hält, hängt nicht an der Nationalität der Partnerin. Es könnte jeder Spionage betreiben und direkt oder indirekt Informationen an Verwandte und Freund weitergeben und das gilt auch für fremde Mächte. Lustigerweise ist es z.B. keinesweg untersagt, als Deutscher seine Firma zu verlassen, nach Russland oder China zu gehen und dort als Angestellter zu arbeiten und so sein Wissen zu nutzen. Rheinmetall suchte vor Kurzem Ingenieure für die Panzerfirma in Firma in Ismir. Das ist viel wahrscheinlicher, als dass einer während einer Tätigkeit parallel seine Firma torpediert. Noch wahrscheinlicher ist es, irgendwo nach Verlassen in einer Firma zu arbeiten, die von Chinesen gekauft wird. Nehmen wir z.B. Robotikentwicklung bei KUKA: Einer der hauptverantworllichen Projektleiter für das HMI- und GUI-Thema kam von Rohde und Schwarz und war im A400M-Projekt aktiv. Der kennt alles, angefangen von Kosten, Abläufen, Methoden und Protokolle. Ein anderer, der weite Teile der Software und somit auch Teile der FPGA-Technologie betreut, kam von Eurocopter aus Donauwörth. Der kennt die redundanten Steuercodes für die Motorensicherheitsabschaltung. Andere kamen von der MTU und von Diehl. Auf die haben die Chinesen legal Zugriff und als Arbeitgeber sogar Anspruch auf das Wissen. Es kommt also auf die Einzelperson an, ob da jemand loyal bleibt oder nicht. Hat nichts mit der Frau zu tun. Zyniqer schrieb: > Ü1 ist Pillepalle. Die ganze Sache ist Pillepalle! Die Rüstungsfirmen selbst beschäftigen doch massenhaft Ausländer, die beste Kontakte nach daheim haben. EADS, ESG, Rheinmetall und MTU z.B. beschäftigen etliche Russen und Russlanddeutsche. Die telefonieren wärend der Arbeitszeit mit der Oma in Nowosibirsk und bereiten ihren halbjährigen Heimatbesuch vor, erzählen über das, was die Leute von Putin denken und verteidigen seine Haltung gegenüber Deutschland. Alles schon gehört. Auch Iraner, Pakistani und Inder habe ich schon an der Software arbeiten sehen. Nicht umsonst ist die Projektsprache oft genug Englisch. Ausserdem beschäftigen sie Freiberufler. Diese fluktuieren noch viel stärker, als die Angestellten und schleppen Wissen von a nach b.
Carl schrieb: > Es scheint mir einen Paradigmenwechsel beim Coding zu geben: Der Trend > geht weg von der Empfindlichkeitsliste hin zu Langsam: Die Frage ob rising_edge oder Clock'event zu verwenden ist, ist eine Sache - die Frage ob mit oder ohne Parameterliste, eine andere. Wenn bei der Umsetzung ein Signal nicht in der Liste steht, wird die Abhängigkeit für das spätere Anspringen driekt erst gar nicht erzeugt und nicht erst nicht dann nicht, wenn die Funktion betreten und analysiert wurde. Zudem ist das in einigen Fällen nicht durch Analyse eliminierbar, wenn Verknüpfungen zwischen Signalen bestehen und es nicht ohne Simulation klar ist, dass es keine funktionelle zeitliche Überlappung gibt (wie das die Synthese erkennen kann, wenn sie alles ausgerollte hat). Dann wird das jeweils zu Ausführungszeit entschieden und man hat den unnötigen Aufwand. Die andere Fragestellung, ob "clock'event" oder "rising_edge" ist nicht zu beantworten, denn die sind nicht vollständig gegeneinander austauschbar. Das ist speziell bei physikalischen Sims zu unterscheiden. Dazu haben wir bereits aber threads gehabt. Siehe auch die Libraries und möglichen Belegungen der Signale. Schlumpf schrieb: > Aber alle diese Ebenen beschreiben Hardware (in unterschiedlichsten > Abstraktionsstufen) Naja, eine Schleife beschreibt zunächst nur einen Vorgang, den der Compiler ausführen soll. Da kommen gfs. 10 Leitungsverbindungen, 10 platzierte Cores, aber auch 10 Berechnungsansätze oder Iterationen heraus, die ein Ergebnis liefern, welches weiter verwendet wird. Besonders die Hilfsrechnungen mit Variablen produzieren eher Vorgaben für Hardware und bei state machines sind wir zugegeben sehr weit weg von Hardware. Daher wäre die korrekte Beschreibung "Beschreiben der Funktion der Hardware", also f(H). Dem trägt man in VHDL bekanntlich durch Einführung der Begriffe structural und bahavioral Rechnung. Da diese aber meist bedeutungsfrei oder gar sinnentstellend in der Architektur rumhängen, in welcher bunt gemixt allesmögliche formuliert wird, herrscht da eben leider keine Ordnung.
Schlumpf schrieb: > Daher sage ich (dass es tief genug einsinkt): > > "Hardware-->VHDL": So wird ein Design stabil. Sorry, aber das ist Babylon pur. Du sagst "Hardware", meinst damit aber etwas grundsätzlich anderes als du sagst. So werden dich eben 99.9% aller Studenten deftig mißverstehen. Die sagen sich dann irgendwann - um überhaupt mental durchzukommen - "laß den ollen Zausel quatschen, wir hören ihm nicht weiter zu und verlassen uns fürderhin auf unsere eigene Empirie". Warum können die Leute sich bloß nicht exakt audrücken und beharren allweil darauf, zu ihrer Idee einer Logik "Hardware" zu sagen? Wenn ich mir z.B. nen CORDIC selber ausdenken will, dann denke ich zu allererst an den eigentliche Algorithmus (reinweg Gedanken), dann daran, wie ich ein dafür geeignetes Zahlenformat hinkriege (auch nur Gedanken), dann ob ich HW-multiplizierer zur Verfügung habe oder diesen Mist zu Fuß machen muß, dann wieviele Stufen ich tatsächlich benötige, den Rest kann man ja - wenn man sich nicht dämlich anstellt - ja prima verwenden, um die Stufenanzahl und damit die Taktanzahl für den ganzen Durchlauf drastisch zu reduzieren. Das ist alles nur reines gedankliches Durchgehen dessen, was zum Realisieren der Idee vom CORDIC nötig ist, also Software. Wo bleibt da die Hardware? Fast nirgendwo. An die LUT's denkt man da noch garnicht, allenfalls was man an fertig verdrahteten Baugruppen im Chip zur Verfügung hat. Die Hardware kommt wirklich erst ganz zum Schluß. Ich ärgere mich immer über Leute, die irgend einen Spezial-Jargon daherreden, der zwar bekannte Wörter verwendet, damit aber völlig andere Dinge meint. Ist modernes Rotwelsch. Sowas wie "wo der Bartel den Most herholt" übersetzt sich nur für den Spitzbuben zu "wo das Brecheisen die Geldscheine herholt" W.S.
W.S. schrieb: > Warum können die Leute sich bloß nicht exakt audrücken und beharren > allweil darauf, zu ihrer Idee einer Logik "Hardware" zu sagen? Weil es einen Dualismus des Wortes "digitale Logik" gibt: 1) Logische Funktionen zur Informationsverarbeitung, definiert durch u.a. die Boolsche Algebra, Inkarnation: Und, Oder, Invertiert, Gleich, Ungleich 2) Logikbausteine der Elektronik zum Schaltungsdesign mit TTL und CMOS auf Gatterebene, Inkarnation durch Buffer, Inverter, Pins und eben die Gatter Damit besteht an einigen Stellen eine Identität zwischen der Beschreibung von VHDL und Schaltungstechnik, an anderen nicht. Das bekommen manche halt nicht gebacken. Richtig ist, beim inneren FPGA-Design, das nichts mit Physik zu tun hat, von Logikdesign zu sprechen, also dem Verknüpfen von Informationen und den Strom, Spannungen und auch Pegel außer Acht zu lassen. Daher sollte man es auch tunlichst unterlassen, von low-aktiven Signalen zu sprechen, die es real nicht gibt. Richtig ist ferner, beim äußeren FPGA-Design, wenn es um Pins und Ports und die Pegel geht, von Hardwareentwicklung zu sprechen. Hier z.B. ( und nur hier!) treten lo-aktive Pins auf. Diese Dinge sind aber eigentlich klar und eindeutig beschrieben und werden an Universitäten auch so gelehrt. Leider passen Viele nicht richtig auf und vermischen Definitionen. Kurze Zusammenfassung von Susi: 1) Funktionelles Design -> Software (Ablauf), Variablen, Funktionen, Methoden, Vorgänge sind z.B. "true / false" finden also statt oder nicht. 2) Logik Design -> Software mit Bezug zur Hardware (Gatterlogik), Signale sind 0 und 1 3) Physisches Design -> Hardware als Software beschrieben (Ports, PLL, Pegel) Leitungen sind "low high" Alle 3 werden durch VHDL bedient. Leitungen gibt es im FPGA aber keine! Die werden nicht beschrieben. W.S. schrieb: > Das ist alles nur reines gedankliches Durchgehen dessen, was zum > Realisieren der Idee vom CORDIC nötig ist, also Software. JA! Aber: > Wo bleibt da die Hardware? Fast nirgendwo. Solange du nur funktionelles VHDL und Cores entwickelst, nimmst du keine Rücksicht auf Hardware. Stimmt. Das ist aber nur die Hälfe der Aufgaben beim FPGA-design. > Die Hardware kommt wirklich erst ganz zum Schluss. Sie kommt bei der Synthese. Spätestens dann, wenn das Logikdesign in die Hardware reingeworfen wird. Siehe meine Unterscheidung oben zum physischen design. Entwicklung heißt aber auch Kosten, Rechenpower und Elektronik im Auge behalten. Diese wirken sich gleich zu Beginn auf die Konzepte aus und damit z.B. die Frage, ob dein Cordic wirklich die ideale Lösung ist oder man einen Sinus oder ATAN gfs doch in Hardware, also einem RAM baut.
:
Bearbeitet durch User
Jürgen S. schrieb: > Weil es einen Dualismus des Wortes "digitale Logik" gibt: Ja, siehste. Ich sprach eigentlich von der Idee einer Logik. Also von der Idee, ein Funktionieren in die Tat umzusetzen. Nicht von digitaler Logik oder gar von schnöden TTL-Schaltkreisen. Die Idee von einer Logik - wie sind hier ja Im FPGA/VHDL-Bereich - ist die gewünschte Funktion, also z.B. ein digital funktionierendes Radio mit dem ich dann auf Kurzwelle Radio Eriwan empfangen kann. Man kann das nun verfeinern in digitale Baugruppen bis herunter zu den Basisfunktionen AND, OR usw. Aber das ist alles Idee bis hin zu dem Zustand, daß man die Idee technisch abbilden kann, es ist also Software. Alles, alles, alles. Ich merke immer wieder, daß eben grad die Leute, die in FPGA-Gefilden arbeiten oder lehren, immense Schwierigkeiten haben, sich auszudrücken. Deshalb werden sie von anderen Leuten, die nicht aus exakt dem gleichen Umfeld kommen, schlichtweg nicht oder komplett fehlverstanden. Ebenso haben sie - wie wir hier gesehen haben - auch in umgekehrter Richtung ihre Schwierigkeiten, zu verstehen was andere Leute ihnen sagen. Das ist offenbar genau so wie Rotwelsch und zugleich Spitzbube zu lernen. Nur eines von beiden geht offensichtlich nicht. Oder? Ich sehe da nur ein trauriges Fazit: Die zugehörige Lehre ist nach wie vor von miserabler Qualität und sollte deutlich verbessert werden. Aber dazu gehört eben auch, daß die FPGA-Rotwelsch sprechenden Leute, die zwar ihre Erfahrungen haben, diese jedoch nur in ihrem Rotwelsch ausdrücken können, sich bemühen sollten, normales Sprechen wieder zu erlernen, damit sie lehren können. W.S.
W.S. schrieb: > Ich merke immer wieder, daß eben grad die Leute, die in FPGA-Gefilden > arbeiten oder lehren, immense Schwierigkeiten haben, sich auszudrücken. > diese jedoch nur in ihrem Rotwelsch > ausdrücken können, sich bemühen sollten, normales Sprechen wieder zu > erlernen, damit sie lehren können. Sehr weit ausgeholt. Ich stimme dieser oft zitierten Meinung der angeblichen Nichtbefähigung von Entwicklern hinsichtlich ihres Ausdrucksvermögens inhaltlich bedingt zu, weise aber im konkreten Zusammenhang auf 2 klitzekleine Dinge hin: 1) Wenn wir uns in einem thread bewegen, der "VHDL Denken" heißt, dann haben wir eine genaue Vorstellung, was "Logik" meinen könnte. 2) Ich habe nicht ohne Grund weiter oben die 3 Ebenen des Entwickelns von Schaltungen aufgegriffen und dort im Punkt 1 von der funktionellen Logik gesprochen. Dort findest du das, was du mit dem "von der Idee einer Logik." meinst. Logisch? :D Im Übrigen bewegten wir uns beim aktuellen Tenor der Diskussion um die Frage "Software" <-> Hardware. (Lesefähigkeiten :D) Gute Nacht
Mich hat seinerzeit als Anfänger, der VHDL für die Hardwareentwicklung einzusetzen hatte, schon sehr gewundert, dass es in einem FPGA ein "after xx ns" gibt. "Wie soll das gehen?" habe ich mich zurecht gefragt und dann herausgefunden, dass sowas simples wie
1 | led <= not led after 500 ms; -- blinken |
eben doch nicht geht. Oder eben nur im Simulator. Dort aber anstandslos. So wie auch das hier
1 | :
|
2 | if rising_edge(button) or falling_edge(trigger) then |
3 | wait for 10 ms; |
4 | :
|
tadellos im Simulator läuft. Ich kann mit solchen Konstrukten also tatsächlich irgendwelche Abläufe "programmieren", bekomme die aber niemals mit einer FPGA-Toolchain auf lauffähige Hardware umgesetzt. Oder andersrum: diese Konstrukte "beschreiben" eine Hardware, die ich so nicht ins FPGA bekomme. W.S. schrieb: > Jürgen S. schrieb: >> Weil es einen Dualismus des Wortes "digitale Logik" gibt: > Ja, siehste. Ich sprach eigentlich von der Idee einer Logik. Also von > der Idee, ein Funktionieren in die Tat umzusetzen. Nicht von digitaler > Logik oder gar von schnöden TTL-Schaltkreisen. Irgendwie scheint mir diese Diskussion samt Haarspalterei um den Begriff "Logik" bezeichnend für die Problematik zu sein. Man versucht unbedingt, Begriffe, die bereits anderweitig vorbelegt sind, auf das neue Aufgabengebiet umzubiegen. Für mich ist nämlich die Logik lediglich ein Hilfsmittel wie Bleistift und Paier, um meine Idee zu realisieren: "Meine Idee ist, eine Funktion zu bekommen, also brauche ich logischerweise Dieses und Jenes." Ich brauche aber in diesem sehr abstrakten und durchaus logischen Denkprozess noch keine Logik im Sinne eines digitalen Schaltkreises. Auf diese Doppeldeutigkeit wird dann schon in der ersten Zeile des "Logik"-Wikipedia-Artikels (https://de.wikipedia.org/wiki/Logik) hingewiesen. In einem Thread, der sich mit "VHDL für FPGAs" befasst, sollte aber klar sein, dass mit "Logik" nicht die eher philosophische oder symbolische Logik wie in Wikipedia beschrieben gemeint ist, sondern dass hier mit "Logik" kombinatorische Schaltungen, die mit Logikgattern umgesetzt werden sollen, gemeint sind (https://de.wikipedia.org/wiki/Logikgatter). W.S. schrieb: > Aber das ist alles Idee bis hin zu dem Zustand, daß man die Idee > technisch abbilden kann, es ist also Software. > Alles, alles, alles. Ist dann per dieser Definition auch eine beliebige mechanische Zeichnung eine Art "Software"? Und sind dann logischerweise die Konstrukteure auch "Programmierer"?
:
Bearbeitet durch Moderator
W.S. schrieb: > Jürgen S. schrieb: >> Weil es einen Dualismus des Wortes "digitale Logik" gibt: > > Ja, siehste. Ich sprach eigentlich von der Idee einer Logik. Also von > der Idee, ein Funktionieren in die Tat umzusetzen. Nicht von digitaler > Logik oder gar von schnöden TTL-Schaltkreisen. ... > Ich merke immer wieder, daß eben grad die Leute, die in FPGA-Gefilden > arbeiten oder lehren, immense Schwierigkeiten haben, sich auszudrücken. > > Deshalb werden sie von anderen Leuten, die nicht aus exakt dem gleichen > Umfeld kommen, schlichtweg nicht oder komplett fehlverstanden. > > Ebenso haben sie - wie wir hier gesehen haben - auch in umgekehrter > Richtung ihre Schwierigkeiten, zu verstehen was andere Leute ihnen > sagen. Naja jedes Fachgebiet hat so seine eigene Begrifflichkeit, weil jedes Fachgebiet seine eigene Werkzeuge und Mittel hat die geforderte Applikation zu erstellen. Und es ist selbstverständlich, das die Beschreibung der Realisierung eben auf der Beschreibung der Anordnung der benutzen Mittel beruht. Das ist kein Rotwelsch, das ist einfach Domain-KnowHow (https://en.wikipedia.org/wiki/Domain_knowledge). Man kann eben keine Domain beherrschen ohne sich die Domain-Begriffe anzueignen. Ist halt wie bei der sexuellen Aufklärung von Heranwachsenden. So grob kann man das mit sterilen, poetischen Vergleichen wie Bienen und Blüten umschreiben, aber ums wirklich anwendbar muss man ins 'Vulgäre' wechseln. Unabhängig davon, ob irgendwelche Elfenbeinturm-Luftikuse davon einen 'Knacks' wegbekommen oder nicht: https://www.youtube.com/watch?v=gjd6KWFi5NM
Lothar M. schrieb: > Ich kann mit solchen Konstrukten also tatsächlich irgendwelche Abläufe > "programmieren", bekomme die aber niemals mit einer FPGA-Toolchain auf > lauffähige Hardware umgesetzt. Was ja nun letztendlich nur eine Einschränkung des Werkzeugs (Synthese) ist (die Sprache an sich kann's ja). Ein C-Programmierer, der mit Fliesskommazahlen rechnen will, schreibt auch ganz selbstverständlich 3.0 * 2.5 hin, obwohl er (hoffentlich) weiß, daß sein mickriger 8051 gar keine Fliesskommaeinheit hat und der C-Compiler eine Softwareemulation dafür einfügen muß. Er nimmt einfach hin, daß sein Programm dadurch deutlich größer, langsamer und möglicherweise ungenauer wird. VHDL-Synthese ist einfach (noch?) nicht so weit. Gut oder schlecht? Wer sich jedenfalls von Anfang an beim Design auf das beschränkt, was die Synthese hergibt und nur in Schaltkreisen denkt, wird die Fähigkeiten der (Programmier-) Sprache VHDL nur zu einem sehr geringen Teil ausnutzen.
Markus F. schrieb: > Wer sich jedenfalls von Anfang an beim Design auf das beschränkt, was > die Synthese hergibt und nur in Schaltkreisen denkt, wird die > Fähigkeiten der (Programmier-) Sprache VHDL nur zu einem sehr geringen > Teil ausnutzen. Ja mei, als FPGA-Hardwareentwickler ist es nun mal der Job Hardware zu bauen die tut. Da sind alle anderen Aspekte eher störend. Und auch in der Softwareentwicklung wird mit Coding Standards/Styleguides die Möglichkeiten der Nutzung aller Sprachelemente bewusst eingeschränkt, bspw.: https://www.gnu.org/prep/standards/html_node/Writing-C.html Ziel der VHDL-Verwendung ist nun mal nicht möglichstweite Ausnutzung aller Möglichkeiten sondern sauberes Engineering. Also wartungsfreundlicher (vom Team verständlichen) Code schreiben, der möglichst 'robust' und frei an 'Trittfallen' und Randeffekten ist.
Markus F. schrieb: > obwohl er (hoffentlich) weiß, daß sein mickriger 8051 gar keine > Fliesskommaeinheit hat und der C-Compiler eine Softwareemulation dafür > einfügen muß. Ja, lustigerweise wissen das sogar frisch fertig studierte technische(!) Informatiker nicht mal. Persönlich kenne ich da einen Fall, wo für einen Abschlaussarbeit bestimmte Funktionen in einen STM32 reinzupacken waren. Ich hatte das Projekt zu betreuen und die Rechenleistung des µCs als "für die Aufgabe mit Reserven gut ausreichend" befunden. Dann gings erst mal vielversprechend und überraschend zügig los, bis der werdende Bachelor kam und sagte: "Das Design passt nicht rein! Und das Ding ist zu langsam!" Puh, Hitzewallungen und hektische Kontrolle der Abschätzung, aber keinen offensichtlichen Fehler in meinen Überlegungen gefunden. Also haben wir den Code mal tiefergehend zusammen angeschaut und ich habe ihm im erzeugten Assemblercode mal gezeigt, was da umständlich und ressourcenfressend umgesetzt wird. Letztlich hat sich herausgestellt, dass da tatsächlich noch in alle Richtungen (Speicher und Timing) viel Platz ist. Ihm wurde die Abhängigkeit von Hardware und Software in den vorausgegangenen 3 Jahren offenbar nicht hinreichend verdeutlicht. Er hat "Programmieren" irgendwie losgelöst von "Hardware" betrachtet, oder ihm war die Verbindung und die Auswirkungen nicht klar. Und auch, dass ein Zähler besser nicht als float umgesetzt und dann mit einem festen Wert verglichen wird, weil das "theoretisch" dann&wann schief geht, war ihm bekannt, weil es im Studium auch angesprochen wurde. Aber eben nur in der "Theorie". Und mental ist es offenbar verankert, dass "theoretische" Dinge praktisch nie vorkommen... Markus F. schrieb: > Wer sich jedenfalls von Anfang an beim Design auf das beschränkt, was > die Synthese hergibt und nur in Schaltkreisen denkt, wird die > Fähigkeiten der (Programmier-) Sprache VHDL nur zu einem sehr geringen > Teil ausnutzen. Er wird aber mit diesen (höchstens) 10% seine Hardware mit der (Beschreibungs-) Sprache VHDL so darstellen können, dass der Synthesizer sie ins FPGA bekommt. Und es ist eben einfacher, erst mal mit diesen dafür nötigen 10% anzufangen, und dann das, was man aus den restlichen 90% für die Simulation braucht, noch zusätzlich zu lernen, als 100% von VHDL zu lernen und dann mühsam herauszufinden, welche 90% man nicht primär für das Hardwaredesign verwenden kann.
Lothar M. schrieb: > Er > hat "Programmieren" irgendwie losgelöst von "Hardware" betrachtet, oder > ihm war die Verbindung und die Auswirkungen nicht klar. Das ist aber bei den meisten Softwareentwicklern so, jedenfalls außerhalb des Embedded-Bereiches. Der typische Business-ITler, der in Java irgendwelche Web-Microservices programmiert, ist von der Hardware so weit weg, dass sie ihm nur bewusst wird, wenn sie mal ausfällt. Was ja grundsätzlich nicht verkehrt ist. Bei sehr komplexen Aufgaben ist eines hohes Maß an Abstraktion notwendig, sonst kommt man nicht in endlicher Zeit ans Ziel. Aber wenn ein SW-Entwickler, der bisher auf diesem Abstraktionsniveau gearbeitet hat, jetzt einen uC programmieren soll, dann wird's echt lustig. Kenne ich von vielen Leuten, die aus der Matlab-Welt kommen und ihre zweifellos eleganten Algorithmen auf eine embedded-Plattform portieren sollen. Blut, Schweiß und Tränen. Von VHDL und FPGA ganz zu schweigen. Umgekehrt ist es aber zugegeben auch nicht anders. Wenn ich hin und wieder mal Scilab zur Hand nehme oder C++ mit openMP oder in Python programmiere und daran denke, was da "behind the scenes" alles abläuft, dann wird mir schwindelig und ich versuche unbewusst, die gleichen Optimierungstechniken anzuwenden wie beim Baremetal-C-Code auf einem uC mit ein paar kByte Speicher. Was dann meistens völlig ins Leere läuft. Man muss einfach lernen, sich auf das jeweilige Abstraktionsniveau einstellen, auf dem man arbeitet.
Lothar M. schrieb: > Ich kann mit solchen Konstrukten also tatsächlich irgendwelche Abläufe > "programmieren", bekomme die aber niemals mit einer FPGA-Toolchain auf > lauffähige Hardware umgesetzt. > Oder andersrum: diese Konstrukte "beschreiben" eine Hardware, die ich so > nicht ins FPGA bekomme. Klar und das muss auch so sein, wenn man sich vor Augen führt, dass ich mit VHDL eben nicht Abläufe beschreibe/programmiere, die auf dem FPGA laufen, sondern Abläufe beschreibe/programmiere, die in der Synthesesoftware laufen. Eigentlich ist es ein einfacher Gedankengang, zu erkennen, dass irgendwelche waits oder loops dann in der Software laufen und es egal ist, ob es sich um Synthese oder Simulaiton handelt. Man muss halt genauer hindenken, was passiert, wenn ich eine Simulation warten lasse und eine Synthese warten lasse. Im ersten Fall bekomme ich eine Zeitverzogerung, die sich auf das Simulationsverhalten auswirkt, im zweiten allerhöchsten eine langsamere Synthese. Man darf alsom getrost davon ausgehen, dass die Synthese ein wait richtigerweise überliest. Und das gleiche kriege ich, wenn ich die beiden Softwareprogramme in eine Schleife schicke: Die Simulation looped ein paar mal und führt das aus, was drin steht und die Synthese tut das auch. Steht dann ein generate drin, bekomme ich in der Simulation n Stücke meines Codes aufgezogen und in der Synthese auch. Steht aber in der loop nur eine einzige Zuweisung drin, dann wird die in der Simulation 10x ausgeführt (wenn sie nicht wegoptmiert wird) und in der Synthese 10x redundant ausgeführt - führt eben zu einer einzigen, wenn sie nicht irgendwie divergiert. Wenn ich einem Menschen 10x sage, "verlege eine Leitung" habe ich am Ende gfs auch nur eine einzige Leitung. ************************************************************************ Um den Programmierern den Denkanstoss zu geben, weise ich daher immer auf den Zusammenhang von VHDL zu einer ScriptSprache hin. Mit einem TCL kann man auch die Synthese steuern und wenn da drin steht, etwas 5x zu tun, gibt es eben 5 Cores, 5 Leitungen bzw auch 5 FPGAs, oder eben auch 5x das Gleiche oder 5x exakt Dasselbe. Kein Mensch kommt dann auf die Idee, anzunehmen, dass der FPGA 5x etwas tun wird. Es ist der FPGA-Erbauer, der mit VHDL angewiesen wird, 5x etwas zu tun. Hat man das mal verinnerlicht, fallen 75% der Anfängerfragen zu der Bedeutung und Funktion bestimmter VHDL-Befehle direkt weg.
Lothar M. schrieb: >> obwohl er (hoffentlich) weiß, daß sein mickriger 8051 gar keine >> Fliesskommaeinheit hat und der C-Compiler eine Softwareemulation dafür >> einfügen muß. > Ja, lustigerweise wissen das sogar frisch fertig studierte technische(!) > Informatiker nicht mal. Tja. Die auch hier in diesem Forum übliche Ausrede für Nichtwissen solcher Art ist "man muß das Rad ja nicht nochmal erfinden.." Offensichtlich ist eben auch die Lehre bzw. das Studium innerlich versaut. Warum fängt man bei Informatik/Ingenieurs-Fächern nicht mit den Grundlagen an? Also: - zu allererst Schaltungen per TTL und Stromlaufpläne - dann Assembler mit eine möglichst alten und einfach zu verstehenden Plattform (z.B. Z80) - dann Gleitkommaformat erläutern und Softwarepaket für die 4 Grundrechenarten durchkauen, bis es auch der Letzte kapiert hat, was es so alles braucht, bis ein u:= d*3.1415; als Maschinencode im Controller ist. - und dann erst irgendwelche höheren Angelegenheiten, höhere Programmiersprachen und so. Warum also wird von den Lehranstalten den Lernenden der notwendige Grundlagenstoff nicht in der gehörigen Tiefe und Reihenfolge beigebracht? Das ist doch ein Manko der Lehranstalten! Ich würde die Studenten zu allererst mal ein CPLD mit Schematics des Webpacks von Xilinx programmieren lassen (wobei sie sich wohl über eben dieses Schematics zunächst schwarz ärgern werden) und dann erst ihnen erzählen, daß man das Gleiche auch verbal mit Hilfe einer entsprechenden Programmiersprache machen kann. So herum! Dann kommt vermutlich auch eher das RICHTIGE Verständnis für programmierbare Logik und deren Programmierung auf. Mein Fazit: Die Ahnungslosigkeit der Absolventen ist der mangelnden Qualität des Lehrkörpers geschuldet, die sich zwar wie hier über die Bildungslücken der Absolventen lustig machen, aber zuvor es nicht geschafft haben, selbige zu schließen bzw. erst garnicht aufkommen zu lassen. W.S.
>- dann Assembler mit eine möglichst alten und einfach zu verstehenden >Plattform (z.B. Z80) Oder noch besser: Erst mal mit Röhren und dann Transistoren.
Carl schrieb: > Oder noch besser: Erst mal mit Röhren und dann Transistoren. Mumpitz, es geht um integrierte Digitaltechnik, da brauchts von der Röhre garnichts und vom Transistor nur ein vereinfachtes Schaltermodel. Jetzt ist erst Montag vormittag und nicht sonderlich heiß. Versucht doch bitte ernsthaft zu bleiben oder bleibt fern!
>Mumpitz, es geht um integrierte Digitaltechnik, da brauchts von der >Röhre garnichts und vom Transistor nur ein vereinfachtes Schaltermodel. Es geht auch anders: Beitrag "Reparaturanfrage CPU-Modellrechner Phywe"
Hier muss ich nochmal einhaken: W.S. schrieb: > Warum also wird von den Lehranstalten den Lernenden der notwendige > Grundlagenstoff nicht in der gehörigen Tiefe und Reihenfolge > beigebracht? Das ist doch ein Manko der Lehranstalten! Kommt auf die Lehranstalt an! Und auch auf die Zeit! Bei uns (Universität Siegen) wurde das sehr wohl gemacht. Im C++ Kurs, im OS9-Kurs, im Unix-Kurs und auch im Bereich der Entwicklung mit GALs hatte man die Chance, genau das zu kapieren. Allerdings hatten die meisten das schon vorher kapiert, weil sie, wie ich, von Kindheit an mit 8-Bit-Computern rumprogrammiert hatten - im Gegensatz zu den Jahrgängen der 70er und frühen 80er, die als Kinder keine Heimcomputer hatten. Es könnte wohl sein, dass man Vieles davon dann im guten Glauben bei den 90-Jahre-Studenten auch vorausgesetzt hat und später immer mehr übergangen hat, dabei aber verkannte, dass diese spätere Generation nicht mehr so viel gebastelt hat wie wir. Die sind meistens weiter oben eingestiegen, was Computer anging. Die PCs waren einfach auch nicht dazu angetan zu Programmieren. Dann kam die "Hochschulreform" Mitte Ende der 90er und man hat "entrümpelt". Beim Zusammenkürzen- oder wie ich es nannte: "Verstümmelung der Ingenieursstudiengänge" - hat man dann viele Grundlagen wie technische Mechanik und Physik für die technischen Informatiker und Elektroniker mit Richtung Datenverarbeitung einfach rausgenommen. Dasselbe passierte mit den Grundlagen der Mikroelektronik. Wir haben noch gelernt, wie ein Transistor auf Physikebene funktioniert, wie man durch Vereinfachungen zu den reduzierten Gleichungen kommt, die man in Ersatzschaltungen findet (differentielle Stromverstärkung etc.). Wir hatten auch noch die Innereien von OPs. Die mehr informatiklastigen Studiengänge wurden davon weitgehend befreit, damit sie eher die Regelstudienzeiten einhalten konnten. Dann kamen Anfang der 2000er auch noch die bachelor-Studiengänge und es wurde nochmal massiv zusammengekürzt! Alles, was vorher Diplom II war (universitärer Studiengang) ist weggefallen und Teile davon wurden als Zusatzqualifikation "Master" verkauft, den die bachelor machen konnten, welche aber auch schon ein stark reduziertes Studium haben, im Vergleich zu dem Diplom I (FH) vorher. Ich schätze den heutigen bachelor auf maximal 75% des vormaligen FH-Ingenieurs der 80er und frühen 90er. Den Master auf maximal 80% des Diplom-Ingenieurs aus der Zeit. Im Ausbildungsmenge x Ausbildungsqualität kommt das genau so hin, auch wenn es sich martialisch viel anhört. Da spielt auch mit, dass heute sehr viel mehr Menschen Technik studieren und dies nur dadurch möglich ist, dass man von unten her durch Senkung des Abiturniveaus und Zugang für nicht-Abiturienten aufgefüllt hat (auch wenn das Manche nicht gerne hören werden). Und es spielt mit, dass einige Hochschulen ganze Semester aussparen, die Studies in die Firmen schicken und dies als Praxissemester verkaufen, wodurch das Studium angeblich praxisnäher wird. Dabei wird praktisch nur Lehrzeit weggenommen, wie wir damals zu 100% hatten, weil wir unsere halbes Jahr Minimalpraktium über die Ferien verteilt gemacht haben. Gerade dieser Punkt ist nicht nur Augenwischerei sondern auch noch schädlich für die Studies, weil sie in diesem "Praxissemester" kaum etwas tun können, was sie später machen- und wenn, dann nicht in der Qualität, weil sie Vieles noch nicht richtig können. Da wird dann - gerade mit VHDL - erst mal viel falsch drauflos programmiert, ohne irgendwelche komplexen Inhalte verstanden zu haben, die erst am Ende des Studiums kommen, oder gekommen wären, wenn man ein richtiges Diplom hätte. Der Sachverhalt beim Master ist leider auch der, dass ein System, welches von Anfang an auf 4 Jahre ausgelegt ist, viel methodischer und stabiler aufgesetzt werden kann, als wenn ich eine 2+2 Lösung mit Zwischenanschluss anbieten will, wo erst mal löchriges oberflächliches Wissen vermittelt wird, um hinterher die Lücken zu stopfen. Dass das System nicht viel taugt und ineffektiv ist, konnte man gerade an unserer Uni sehr gut beobachten, weil es dort möglich war, mit einem FH-Diplom einer anderen Hochschule anzurücken und das fehlende Hauptstudium nachzuholen, was mutmaßlich schnell gehen sollte, soweit Inhalte real schon bekannt sind. So ganz schnell ging es bei den meisten dann doch nicht, viele packten es überhaupt nicht obwohl nur FH-ler mit mindestens 2.0 und besser zugelassen waren und wenn sie es packten, hatten sie insgesamt mehr Zeit aufgewendet. Darüber ist man sich in den Hochschulen inzwischen auch einig und bietet nicht ohne Grund teilweise das echte Diplom wieder an.
Lothar M. schrieb: > Markus F. schrieb: >> obwohl er (hoffentlich) weiß, daß sein mickriger 8051 gar keine >> Fliesskommaeinheit hat und der C-Compiler eine Softwareemulation dafür >> einfügen muß. > Ja, lustigerweise wissen das sogar frisch fertig studierte technische(!) > Informatiker nicht mal. Lustigerweise hatten wir genau so einen 8051er Programmierkurs. Ein Sommersemester lang, allemöglichen Sachen, inklusive Pseudo-Multi-Tasking-System mit 4 Prozessen parallel, die sich nicht gegenseitig aufhalten. Reader-Writer-Problem komplett in Assembler! Dafür wäre heute keine Zeit mehr! Selbst die C-Kurse wurden zusammengestrichen. Zu unserer Zeit gab es ein Script, in dem C erklärt wurde mit der Aufgabe, dass diejenigen, die das noch nicht können, es sich beibringen mögen - unter Zuhilfenahme von Büchern wie K & R aus der Bib. Fertig! In den Kursen selbst wurden dann Inhalte, Strukturen und Methoden gelehrt. Compilerbau, Verkettete Listen, Mehrdimensionale Datenverwaltung, Treiber, Multithreading, System 5 IPC. Die Syntax dazu, erklärte sich so beiläufig. Heute lernen die bachelor gerade das C++ selbst und dazu etwa die halbe Menge an Inhalten in etwa 75% der Zeit, wie wir damals. Klar kommt dann auch nur die Hälfte bei raus! Die Master machen dann in der Richtung kaum noch was. Stattdessen klicken sie ganze SOC-Systeme zusammen programmieren dann einfache Sachen. Für mehr reicht die Zeit einfach nicht. Ein breit gefächertes Spektrum an Anwendungen, das es ermöglicht, einen Blick zu bekommen, wann man wie programmiert, wann man was einsetzt, das fehlt. Es fehlt die Vernetzung des Wissens durch Parallelen aus anderen Gebieten wie Mechanik und Elektrik und damit die Transferleistung. Wie soll ein Softwareentwickler einen Bezug zu etwas bekommen, wenn er nie damit gearbeitet hat? ... wenn er die Dinge, die passieren und die das System, das er erstellt, erfassen und steuern soll, nicht einordnen kann, weil ihm die Theorie dazu fehlt? So bleibt er dann nur ein halber Programmierer, dem man sagen muss, was er programmieren soll. Das heutige Studium ist viel zu oberflächlich! Angesichts der gestiegenen Komplexität müsste es aber eher tiefgründiger und damit sogar länger sein. Stattdessen hat man sich an die Billigausbildung anderer Staaten angepasst.
:
Bearbeitet durch User
>Das heutige Studium ist viel zu oberflächlich! Angesichts der >gestiegenen Komplexität müsste es aber eher tiefgründiger und damit >sogar länger sein. Stattdessen hat man sich an die Billigausbildung >anderer Staaten angepasst. Ich weiß nicht. In letzter Zeit hatte ich ein wenig mit FH-Studenten zu tun und mein Eindruck war so schlecht nicht. Es ist ja auch so, dass sich die Technik wandelt und immer neuere Methoden hinzukommen. Also muss man auch einen Teil weg lassen, den die früheren Studenten gelernt hatten. Oder wer kennt sich hier schon mit den algoritmischen Methoden der KI aus? Das Wissen darüber werden die heutigen Studenten in naher Zukunft brauchen und es wird auch schon viel an den Hochschulen gelehrt.
Carl schrieb: > Also muss man auch einen Teil weg lassen, den die > früheren Studenten gelernt hatten. Irgendwie ja, aber irgendwie auch nicht, denn die konkreten Algorithmen muss man sich ohnehin erst hinterher antun und wenn man grundsätzlich verstanden hat, wie man Algorithmen sinnvoll übersetzt, welche Fallstricke es gibt und wie man vorgeht, dann kann man das mit jeder Mathematik. Was die dann im Einzelfall macht, ist von der Anwendung abhängig. Direkt anwenden kann man das Wissen so ohnehin nicht, weil das meistens in der Industrie schon jemand realisiert und eingebaut hat. Man muss also immer Hinzulernen. Wenn aber die basics fehlen, stimmt das Gerüst nicht und ist nicht belastbar. Das Thema KI z.B. besteht ja nicht nur aus Algorithmen, sondern auch und vor Allem in der Erfassung von Information. Dazu gehören die Sensoren und Aktoren sowie die physikalische Umgebung, in der ein Roboter sich bewegen soll.
>Man muss also immer Hinzulernen. Wenn aber die basics fehlen, stimmt das >Gerüst nicht und ist nicht belastbar. Die Frage ist halt, was das Grundgerüst ist und was man davon weg lassen kann. Und man muss weg lassen, oder sind dir hier alle Techniken bekannt?: http://gki.informatik.uni-freiburg.de/teaching/ss14/gki/lecture_de.html
Jürgen S. schrieb: > Dann kam die "Hochschulreform" Mitte Ende der 90er und man hat > "entrümpelt". Danke für diesen ausführlichen Beitrag - wenngleich er mich auch ausgesprochen melancholisch stimmt. Als Geräteentwickler in der Industrie habe ich im Laufe der Jahre durchaus gesehen, daß der Nachwuchs von Jahr zu Jahr immer unbedarfter wurde und mittlerweile an fast allen Stellen aus eigener Kraft nicht weiter kommt, weil das Grundlagenwissen fehlt. Aber daß es an den Uni's derart zugeht, ist zum Grausen kriegen. Wo führt das hin? Industriebrache Deutschland? Innovationen und kluge Ideen ab demnächst nur noch aus Fernost? Hierzulande nur noch Leute, deren einzige Fähigkeit im Wischen über's Phone oder Steckbrett per Arduino besteht und die dediziert zu klein im Kopf sind, um echte Hochtechnologie selbst gestalten (und nicht nur benutzen) zu können? Und ja, das Problem hat dann die Industrie, wenn da Jungspunde daherkommen, eine tolle Urkunde in der Tasche, aber nur Oberflächliches drauf haben, jedoch mit 63k/a einsteigen wollen, ohne daß da ein Gegenwert am Jahresende herumkommt - im Gegensatz zum Ö.D. kann unsereiner nicht ewig auf verkaufbare Ergebnisse warten. Es ist ein Jammertal. Auch für diejenigen, die deshalb wieder entlassen werden müssen und nicht begreifen können WARUM. Sind ja zumeist sympathische Leute.. OK, ich reg mich auf über lausiges Darbieten von VHDL in der Lehre, während eigentlich die Lausigkeit von viel größerem Maßstab ist. Grmpf... Eines bleibt: Man kann es schaffen, die Lehre zu verbessern. Zeit ist da, auch öffentliche Gelder. Das ist was Anderes als in der Wirtschaft, wo einem die schieren Verkaufszahlen im Nacken sitzen und man keine Ressourcen hat, die Versäumnisse der Hochschulen auszuwetzen. W.S.
Jürgen S. schrieb: > Im C++ Kurs, im > OS9-Kurs, im Unix-Kurs und auch im Bereich der Entwicklung mit GALs > hatte man die Chance, genau das zu kapieren. Allerdings hatten die > meisten das schon vorher kapiert, weil sie, wie ich, von Kindheit an mit > 8-Bit-Computern rumprogrammiert hatten - im Gegensatz zu den Jahrgängen > der 70er und frühen 80er, die als Kinder keine Heimcomputer hatten. Braucht man einen C++ Kurs und einen OS9- und Unix-Kurs, wenn man eigentlich das strukturierte und logische Denken hätte erlernen sollen? Ich habe da erheblichste Zweifel. Das klingt mir wie die Diskussionen um Kicad: man hat dort zwar die Fundamente falsch oder garnicht gelegt, so daß der User die Zuordnung seiner Schematics zum Layout manuell vornehmen muß - befaßt sich aber mit einem tollen Push&Shove-Autorouter. Nee, sehr frei nach Donald Zoppo: Grundlagen first. Und diejenigen, die in den 70er Jahren geboren wurden, hatten in den frühen 80er Jahren einen ZX81 oder Spectrum oder was aus der 65xxer Riege. Aber abgesehen davon ist es eben immer wieder dasselbe: man darf sich in der Lehre eben nicht drauf verlassen, daß man deren Grundlagen weglassen darf, weil die Studenten einer bestimmten Epoche bereits einige empirische Erfahrungen intus haben. Die NochNichtWissenden wachsen jedes Jahr erneut heran und man muß eben deshalb auch jedes Jahr alle Grundlagen wiederholen. Ich erinnere mich da an meinen Mathekurs an der Uni: zu allererst kam er mir zu poplig vor, weil ich all diese Basics schon an der Schule hatte, aber schon nach 2 Wochen ging es damit steil aufwärts - aber stetig und ohne Sprünge oder Auslassungen. Und das mit dem "zu poplig" hatten wir alle sehr bald sehr zu revidieren. Aber es wurde eben NICHTS einfach so vorausgesetzt, sondern gründlich (aber mit Tempo) vom Urschleim an behandelt. W.S.
W.S. schrieb: > Kicad: man hat dort zwar die Fundamente falsch oder garnicht gelegt, so > daß der User die Zuordnung seiner Schematics zum Layout manuell > vornehmen muß Du wirst alt...
W.S. schrieb: > Und diejenigen, die in den 70er Jahren geboren wurden, hatten in den > frühen 80er Jahren einen ZX81 oder Spectrum oder was aus der 65xxer > Riege. Das war ja meine Generation. Ich sprach von denen, die 10 Jahre früher dran waren. Für die war Programmierung an der Uni neu. Die hatten keinen Heimcomputer und schon gar keinen PC. Die PCs standen damals in einigen wenigen Großfirmen und wurden von internen Mitarbeitern bedient. Daheim hatte keiner was. Selbst die Lehrer hatten nichts. Ich erinnere mich noch sehr gut an meinen Informatiklehrer, der ganz stolz auf seinen ersten VC-20 war und einen Tausender dafür gezahlt hatte. Ich hatte meinen zu 598,- beim Conrad bestellt und mich geärgert, dass er nach 6 Wochen Lieferzeit beim Vobis zu 398,- zu kaufen war. Conrad hat damals auf Nachfrage dann den gleichen Preis gemacht. Davor gab es nur einige PET 2001 an der Schule. An denen haben wir Pascal gelernt. Keine Ahnung, was die gekostet haben. Waren sicher teuer, da mit Bildschirm und Kassette zum Speichern! Und sie hatten mehre KB RAM! :D Was ich sagen will: Meine Generation hatte das Glück, genau passend mit den neuen Technologien aufzuwachsen, ohne was Wichtiges zu verpassen. Wir waren alt genug um noch Elektronik mitzubekommen und jung genug, um schon Computer mitzubekommen. Als ich an die Uni kam, kam z.B. gerade die erste Ausgabe von Kernighan Ritchie mit ANSI-C raus. W.S. schrieb: > Braucht man einen C++ Kurs und einen OS9- und Unix-Kurs, wenn man > eigentlich das strukturierte und logische Denken hätte erlernen sollen? Im Studiengang Technische Datenverarbeitung schon. An irgendwelchen Beispielen muss man die Strukturen ja auch testen. Und man sollte das Gelernte auch real umsetzen können. Im OS9-Labor wurden Treiber mit und für echte Hardware entwickelt und im UNIX das pipelining und multithreading, sowie Lösungen fürs Philosphenproblem real angewendet. Das sind ja die basics, die man braucht. Die Hardware-Basics die du angesprochen hattest, gab es überdies. Wir haben Layouts mit Caddy gemacht, das konnte schon die angesprochene Zuordnung von SCH und Components. Mir ist auch nicht klar, warum das bei KiCAD so gelöst wurde. Ach ja und um wieder näher zum Thema zu kommen: Wir hatten Ende der 80er auch die Chance, als erste mit FPGAs zu arbeiten. Die Firma Xilinx war damals gerade 4 Jahre alt :-)
Jürgen S. schrieb: > Das war ja meine Generation. Ich sprach von denen, die 10 Jahre früher > dran waren. Für die war Programmierung an der Uni neu. Die hatten keinen > Heimcomputer und schon gar keinen PC. Ach, weißt du, ich kenne das alles. Ich hatte zu meiner Studentenzeit so viel Lochband selber wieder aufgewickelt, daß es wohl mindestens zweimal um den Äquator gereicht hätte. Und die damaligen Rechner hatten Kernspeicher, wurden hauptsächlich in Assembler programmiert und per TTY bedient. Kenn ich alles noch. Aber solche Historie ist auch überhaupt nicht das Thema - sondern ob sich eine Hochschule sträflicherweise darauf verläßt, daß die Studenten Vorkenntnisse besitzen, die deutlich über das Maß hinausgehen, was zum Abitur erforderlich ist. Ich hatte mal zum Schreiben von Dokumentationen den Rat bekommen, eine Dokumentation so zu schreiben, als ob sie für einen alten Advokaten bestimmt sei. Das ist ein außerordentlich GUTER Ratschlag. Der Kernpunkt ist, so zu schreiben (oder zu lehren), daß jemand ohne spezifische Vorkenntnisse (ausgenommen diejenigen, die eben zu einem Qualitäts-Abitur gehören), aber mit einem wachen und scharfen Verstand, mit schneller Auffassungsgabe und mit logischem Denkvermögen aus dem Dargebotenen alles davon verstehen kann. Jürgen S. schrieb: >> Braucht man einen C++ Kurs und einen OS9- und Unix-Kurs, wenn man >> eigentlich das strukturierte und logische Denken hätte erlernen sollen? > Im Studiengang Technische Datenverarbeitung schon. An irgendwelchen > Beispielen muss man die Strukturen ja auch testen. Ich bin da anderer Meinung. Ist sowas Inhalt von fakultativen Zusatzkursen oder Teil des Studienplanes? Wenn ersteres, dann OK, wenn letzteres, dann nicht. Wenn man einen Kurs über irgend ein "Ding" (egal ob hard- oder soft-) durchführt, dann läuft das immer nur darauf hinaus, das "Ding" vorzustellen und dazu zu sagen "das ist hier eben so". Selbst die Frage nach der Ableitung, also das Warum mündet immer nur in "weil das eben hier so ist". So etwas ist KEIN Beitrag zu einem wirklichen Ingenieurs-Studium, sondern eher ein Training für Kundendienstler, die in ihrem Arbeitsumfang keine kreative Tätigkeit haben wie der Ingenieur, der Architekt und so, sondern die zu Kunden fahren, um dort die "Dinge" in Ordnung zu bringen, zu reparieren oder zu warten, die von der Firma an den Kunden ausgeliefert worden sind. Der Ingenieur braucht den kreativen und mit breitem Basiswissen versehenen Geist und der Kundendienstler die tiefere Kenntnis des Dinges, was er zu betreuen hat. Das ist ein himmelweiter Unterschied. Jürgen S. schrieb: > Wir hatten Ende der 80er > auch die Chance, als erste mit FPGAs zu arbeiten Tja, ich hatte damals noch mit Einmal-PAL's zu tun. Irre Stromschlucker! Später dann mit GAL's, womit ich einiges gemacht hatte - die digitalen Teile der Meßtechnik, aber auch sowas wie ne VGA für die damaligen EL-Displays. Später dann vor allem CPLD's. Auch privat. Ist schon ganz nett, wenn man das Frontend für seinen Frequenzzähler am Basteltisch mit einem kleinen 32er Coolrunner machen kann und damit bis über 720 MHz kommt. Da wird die Analogtechnik davor wieder zum Flaschenhals des Systems. Aber ich sehe schon aus deinen Worten, daß es im Argen liegt - sowohl in der Lehre seitens der Lehrenden und deren Vorständen als auch bei den Studenten, die offenbar an einer Art Saturiertheit kranken und deswegen auf Gründlichkeit im Denken keinerlei Wert mehr legen. Final ist das ein Zeichen der Dekadenz einer Gesellschaft, so daß es Andere sind, die mittlerweile auf der Überholspur sind. Sowas hatte die Menschheit schon früher - aber Geschichtskenntnisse sind ja auch rar geworden. Bin neulich drüber gestolpert, wo jemand Biedermeier mit Jugendstil in einen Topf geworfen hat. Viel weiter als "jaja, war früher mal" reichen auch da die Kenntnisse nicht. W.S.
Moin, https://www.heise.de/newsticker/meldung/Von-Sokrates-zum-Smartphone-Warum-Menschen-auf-die-Jugend-schimpfen-4063892.html SCNR, WK
Lol,der Artikel ist Klasse. Ich hab Tränen gelacht. Dabei haben die Kids nur den gleichen Unsinn im Kopf wie wir damals, sie nutzen eben dafür nur die Mittel von heute, die wir ihnen an die Hand gegeben haben. Wenn sich ein paar davon wirklich daneben benehmen, geht das fast immer auf das Konto der dekadenten Alten. Die meisten sind ganz OK. Es dauert halt a bisserl, bis der Schädel komplett gebootet hat.
Vancouver schrieb: > Lol,der Artikel ist Klasse. Tatsächlich nett, beleuchtet das Thema aber vor allem soziologisch. Sicher ist ein Teil des Niedergangs der Jugend reine Interpretationssache der Älteren, aber: 1) Abgänger von Universitäten sind keine Jugendliche, deren Hirn neu booten müsste. Der Bootvorgang, wie du es nennst, läuft in der Pubertät und sollte schon seit 10 Jahren abgeschlossen sein. Deshalb sehe ich in den 25ern erwachsene Menschen. Nicht wenige haben da bereits Kinder. Der Artikel trifft also auf Studenten nicht wirklich zu. 2) Die Altersentwicklung ist nicht linear, man lernt im hohen Alter langsamer und reift auch langsamer. Daher ist ein 25er einigermassen weit entsickelt und es sollte bei einen Absolventen eine gewisse Reife vorliegen, wenn er in den Job kommt. Und egal, wie die Jungen gestrickt sind: Wenn Dank G8 Abitur und verkürzer Studiengänge die Menschen 2-3 jahre jünger sind, dann sind sie auch entsprechend weniger reif, wenn sie starten. Die Probleme die da entstehen sind bereits in anderen Artikeln soziologisch untersucht. Ich war nebenbei 27, als ich abging. Da gab es noch sowas wie Bund. 3) Der Versuch, den jungen Absolventen in der gleichen Zeit mehr reinzuprügeln, muss scheitern! Ich zähle mich daher nicht zu den Kritikern an den Jungen- sondern an unseren Bildungspolitikern. Ich sehe es an meiner Tocher: Die Reife, sich mit politischen Themen zu befassen, liegt vor. Ihr Leben kann sie managen und Verantwortung übernehmen, im Rahmen ihrer Möglichkeiten. Aber was das Studium angeht, rennt sie hilflos von einer Vorlesung in die andere, hat kaum Zeit, alles vorzubereiten und kommt gerade so mit. Sie hat Stress ohne Ende. Stress, der unter anderem auch davon kommt, dass es zu wenige Wohnungen und zuviele Studenten gibt. Sie muss weit und lange fahren und die Busse und Bahnen sind voll gestopft. In der Mensa und der Bibliothek muss sie 25min anstehen, bevor sie rein- oder rauskommt und etwas bekommt. Mit dem Auto fahren geht auch nicht, weil Darmstadt komplett zu und Strassen dicht. Parkplätze in 2km Entfernung vom Campus. >Re: VHDL Denken-wie? Wann soll sie Ruhe finden, um zu denken und die Hausarbeiten zu machen? Im Bus gibt es nicht einmal einen Sitzplatz. 4) Diese enorme und nicht benötigte Zahl von Abbrechern und Studienprobierern (> 40%!!!!!) kann auf Dauer keine Gesellschaft vertragen. Sie kosten viel Geld, nehmen den anderen die Studienplätze weg und belegen die Wohnungen und Verkehrsmittel. Hinzu kommt, dass sie am Ende frustriert und unzufrieden sind mit ihrem Lebenswert und sich die Zeit nicht bezahlt macht. Am Ende fehlen dann Arbeitskräfte auf anderen Gebieten. Oder sie schaffen es gerade so und füllen die Klasse 3 Jobs auf, bei denen unbedingt Studierte genommen werden müssen, die dann Technikeraufgaben machen, ohne sie dafür angemessen zu entlohnen. Da kommt dann auch ein Rentenproblem auf uns zu! Ich halte es ebenfalls für nötig, das Studium und Abitur zu reformieren, damit den Jungen früher gezeigt wird, wo sie stehen und dass sie für ein technisches Studium nicht geeignet sind. Da muss mehr gefiltert werden. Ich denke auch, dass eine frühere Spezialisierung nötig ist. Im Studiengang Biologie meiner Tochter, hängen eine Reihe von Typen rum, die nicht einmal einen Bioleistungskurs hatten, geschweige denn einen Matheleistungskurs, der für die Richtung Bioinformatik aber sehr hilfreich wäre. Auf die trifft 200% genau das zu, was W.S. und J.S. schreiben: Es fehlen die Grundlagen und sie müssen aufholen. Sie bremsen die anderen ab und haben den Hochschulzugang mit völlig anderen Kursen erworben, in einem Fall Musik, Deutsch und Sport. Irgendie stimmt da etwas nicht. W.S. schrieb: > auf Gründlichkeit im Denken keinerlei Wert mehr legen. Inzwischen geht meine Kleine freitags in gar keine Vorlesung mehr, sondern räumt die Kurse nach hinten, um Zeit zu haben, etwas Sinnvolles zu bearbeiten. Sind dann 3h täglich nutzlose Fahr- und Wartezeiten gespart.
Thomas U. schrieb: > Auf die trifft 200% genau das zu, was W.S. und J.S. schreiben: Es fehlen > die Grundlagen und sie müssen aufholen. Sie bremsen die anderen ab und > haben den Hochschulzugang mit völlig anderen Kursen erworben, Grad das ist das Problem, zu glauben in der Schule lerne man VHDL-Denken. Ich behaupte inzwischen die Generation C64 ist näher an den Hardware-grundlagen, weil die sich die Grundlagen auf Eigeninitiative, also an der Schule vorbei, angeeignet haben. Da hat im 64'er Magazin jeden Programmiererkurs durchgelesen, anderen Nerds (oder Papas) Löcher in den Bauch gefragt, Hacks auf gut Glück ausprobiert, Nächte vor der Kiste verbracht, ... . Es braucht halt eine gewisse portion Ehrgeiz, den Drang etwas zu verstehen, um durch "opferung" von freizeit, das Mehrfache an lenpensum durchzuarbeiten, nicht nur die gesellschaftlich akzeptierte Minimal-portion.
Hans Hämmerle schrieb: > um durch "opferung" von freizeit, Wieso Opferung? Die nächtlichen Z80-Assembler-Hacks waren die Vollendung der Freizeit :-) Ich erinnere mich noch an meine Assembler-Divisionsroutine, die ich mit ~15 geschrieben habe. Hat Tage gedauert, bis das richtig lief, mit nichts als einer Befehlsreferenz als Literatur und keinem Menschen in der Nähe, der auch nur annähernd verstanden hätte, was ich eigentlich machen wollte. Das war auf einem Triumph-Adler Alphatronic unter CP/M. Das Glücksgefühl damals war unbeschreiblich (das hat natürlich auch keiner verstanden).
Vancouver schrieb: > Ich erinnere mich noch an meine Assembler-Divisionsroutine, die ich mit > ~15 geschrieben habe. Hat Tage gedauert, bis das richtig lief, mit > nichts als einer Befehlsreferenz als Literatur und keinem Menschen in > der Nähe, der auch nur annähernd verstanden hätte, was ich eigentlich > machen wollte. Schätze man muss den Jungelchens heute noch erklären, was eine Befehlsreferenz ist und das man das tatsächlich ohne Makro-Assembler und Mnemonics zusammbrachte: http://www.manmrk.net/tutorials/TRS80/docs/z80chrt.gif Thats it, alles was man zu assemblerprogrammierung braucht. Und nein, das ist kein Unicode-Unfall, das ist (Nerd-) lesbar! Für den 6502 dann sogar in Farbe: http://2.bp.blogspot.com/-4P2vylzFAyo/T1GDduB1klI/AAAAAAAAAKg/3XgPvJ7e0Ro/s1600/refcard.jpg Und auf A4 ohne Lupe lesbar (ja damals waren die Augen noch schärfer)
Hans Hämmerle schrieb: > ohne Makro-Assembler und > Mnemonics Ich hatte tatsächlich schon einen Macroassembler. Ich musste in bisschen überlegen, wie der hieß: http://altairclone.com/downloads/manuals/Microsoft%20M80%20Assembler.pdf Ich stelle gerade mit Entsetzen fest, dass der von Microsoft war. Aber die waren damals noch ein unbeschriebenes Blatt... Aber seien wir mal ehrlich: Mit dem Zeug haben sich damals auch nur ganz wenige beschäftigt. In meiner Klasse war ich einer von zwei, der Rest hatte mit Computern nix am Hut, und Informatik als Schulfach war noch nicht in Sicht. Das ist heute nicht anders. Zwar haben alle ein Smartphone oder einen Daddel-PC, aber was darin abgeht wissen nur ein paar Freaks, und die hängen meistens im Bastelkeller rum und sind daher unsichtbar. Und Informatik in der Schule, das bedeutet Worxcel, HTML und bestenfalls Java oder Python.
Hans Hämmerle schrieb: > Ich behaupte inzwischen die Generation C64 ist näher an den > Hardware-grundlagen, weil die sich die Grundlagen auf Eigeninitiative, > also an der Schule vorbei, Sagen wir mal nicht "an der Schule vorbei" sondern "zusätzlich zur Schule". Wir hatten damals durchaus Informatik und Mathe mit Computern. Nach der PET2001-Ära wurden so um 1984 direkt C64 er angeschafft. Allerdings gab es da nur 2x die Woche Informatik mit insgesamt 3h. Das haben wir neben der Schule beim Spieleprogrammieren an einem Nachmittag getoppt. Carl schrieb: > Und man muss weg lassen, oder sind dir hier alle Techniken bekannt?: > http://gki.informatik.uni-freiburg.de/teaching/ss14/gki/lecture_de.html Es sind mehrere Aspekte: 1) Man musste deshalb weglassen, weil früher die Studiengänge ausgedehnter waren, was dazu geführt hat, dass viele zu weit überzogen hatten. Unser Schnitt lag bei 13,2 Semester für ein Studium, das in 8+1 hätte absolviert werden sollen. Das hat so gut wie nie einer geschafft und wenn, dann nur mit einer theoretischen DA und dem Minimum an Fächern. Zusatzkurse, die man aus Interesse belegt hat, sind dann keinesfalls möglich. 2) Man musste weglassen, weil man ein bachelor-System aufgezogen hat, das in weniger Zeit, als der durchschnittliche FHler hatte, einen Studienabschluss produzieren sollte. Da alle zunächst den B machen und dann einen M draufsetzen, haben wir besagtes 2 Stufensystem. Das lässt sich aber in Breite und Tiefe hinsichtlich der Didaktik niemals so optimal verteilen, wie zwei paralle Studiengänge, die von vorn herein auf kurz und lang angelegt sind. 3) Ja, man muss auch weglassen, um Neues bringen zu können. Zustimmung! Fragt sich aber, ob man damit etwas verlieren muss. Das Einüben von Mathematik im C-Programm oder im VHDL kann an klassischer Regelungstechnik die Motoren steuert, genau so geübt werden, wie an einer FFT oder einem KI-Adaptions-Algorithmus. Das bedingt noch nicht, daß man Grundlagen verlieren muss. Die Grundlagen von Mathe, Elektro und Physik müssen sitzen. Jedenfalls beim Ingenieur (wir diskutieren ja VHDL). Das KI kann man diesbezüglich zumindest teilweise auch als Informatikthema werten. Die haben aber von Haus aus schon weniger Mechanik und Physik. Was hier aber konkret kritisiert wurde, ist ja das Fehlen der jeweiligen studiengangspezifischen Basics. Und zum Thema VHDL und Hardware sehe ich definitiv die Mechanik und die Physik. Natürlich wird ein Ingenieur für Signalverarbeitung keine T-Träger für den Bau durchrechnen und er wird auch keine Festkörperschwingungen berechnen. Die Formeln und die Denke, die man sich bei der Typisierung und Charakterisierung solcher Systeme aber aneignet, lassen sich hervorragend übertragen und in Simulationssysteme überführen. Es sind ja am Ende immer wieder dieselben DGLs, die auftauchen und damit dieselbe Art von Filterung und Problemchen. Und: Egal, ob ein Informatiker oder Mathematiker ganz oder teilweise ein theoretisches Gebiet abdecken kann oder sollte und damit viele technische Grundlagen für die SW erstmal gar nicht braucht, bleibt es ein Fakt, dass alles, was die meisten Mathematiker und Mathematiker in der Industrie produzieren, irgendwann in einem technischen Gerät landet. Und diese Geräte machen immer das gleiche: Es fließt mechanische oder elektrische Energie (= Information!) hinein, wird verrechnet und kommt hinten wieder raus. Als Bewegung, als Bild oder als Ton oder als Wert. Und da ist sofort die Physik im Spiel und als Zwischenschritt an jeder Ecke die Elektronik mit ihren Feldern, den Schwingungen, dem Rauschen, Zufall und allem was dazu gehört. Je mehr man davon hat, desto solider ist das Wissen. Wenn das Fundament stimmt, kannst du dir praktisch alles draufladen, was du lernen möchtest. Du brauchst nur die Mathe dahinter zu verstehen. Wenn aber in FHs oder jetzt dem bachlor viel theoretische Mathe, Physik und Elektrotechnik fehlt, dann sind die Denkstrukturen nicht da, viele der heutigen komplexen Anwendungen zu verstehen. Ich sehe das sowohl bei industriellen Projekten als auch Studienarbeiten immer wieder, dass zwar aufwändige mathematische und signaltechnische Arbeiten abgeliefert werden, diese aber an den Notwendigkeiten völlig vorbei gehen, weil sie mit der realen Welt nicht zu tun haben. Die massenhaften Sound- und Tonprojekte an den Hochschulen sind so ein Beispiel. Nichts davon kann ein Musiker verwenden, weil die Annahmen und Vorgaben schon falsch waren. Auf Bildverarbeitungs- und Regeltechnikthemen trifft es ebenso zu. Das was real wirklich Probleme macht, wird gar nicht erfasst und auch nicht weggeregelt, weil die Problemstellung nicht realitätsbezogen war.
Jürgen S. schrieb: > Hans Hämmerle schrieb: >> Ich behaupte inzwischen die Generation C64 ist näher an den >> Hardware-grundlagen, weil die sich die Grundlagen auf Eigeninitiative, >> also an der Schule vorbei, > > Sagen wir mal nicht "an der Schule vorbei" sondern "zusätzlich zur > Schule". Wir hatten damals durchaus Informatik und Mathe mit Computern. Njein, schon Zeit nach der Schule zusätzlich, aber eben nicht wie in der Schule, also runtergeschluckt was in der Schule vorgekaut, sondern eben selbst durchgekämpft und ausprobiert und nicht heulend weggerannt wenn was nicht nach Schema F wie unterrichtet tat.
Und mit Bezug zum eigentlichen Thema: Klar, um VHDL zu denken und zu schreiben, braucht man erst einmal kein Elektronikwissen und schon gar keine Physik. Um aber mit dem VHDL irgendwas Interessantes zu machen, außer den Strukturen selbst (also Vernetzung von Components, Instanziierung von Modulen, Bildung von Zählern und Ergebnissen) braucht es starke Bezüge zu den Inhalten und das Verständnis für die Wirkungsketten. Wenn man mit der Digitaltechnik, Transistoren und Bauteilen hantiert hat, dann erklären sich eben solche Zusammenhänge, was da passiert und wenn man dann noch Halbleitertechnik kennt, dann hat man auch eine Idee, warum etwas passiert. Natürlich braucht Otto-Normal-Elektroniker keine Energiebänder, Besetzungsstatistik, Ladungsträgerbeweglichkeit und Lebensdauer, um eine Schaltung zu bauen, wenn die Randbedingungen klar sind. Wenn du aber so etwas mal formuliert und berechnet hast, dann prägen sich die vielen Details ein, die ansonsten verborgen blieben und man erkennt sie wieder, wenn sie einem begegnen. Man kann vorhersehen und einschätzen, wann eine simple Formel versagen wird, oder wann bei einem Test irgendetwas anderes herauskommt, als es im Buch steht. Und genau das passiert sofort, sobald man neue Schaltungen, Verfahren und Methoden in eine Elektronik umsetzen will. Wie oben schon angedeutet, sind es am Ende immer Messketten und das gilt auch für Schaltungen in FPGAs. Die Art dem Umsetzung mag bisweilen trivial sein, aber das was eingebaut werden muss, um sicher zu messen, zu rechnen und mit dem Reinkommenden umzugehen, muss irgendwann von irgendwem designed werden. Mit VHDL oder C oder MATLAB löst man keine Konzeptproblem oder versteht die Umgebung. Das Verständnis muss in der nötigen Tiefe vorher gelegt worden sein. Die kommen leider beim beruflichen Arbeiten nicht von alleine und viele sind einfach zu komplex und können nicht eingeordnet werden, wenn die grundlegenden Zusammenhänge nicht klar sind. Solche Grundlagen später nach Bedarf nachzulernen, ist aber nicht einfach. Bisweilen ist es sogar ziemlich unmöglich, weil sie stark aufeinander aufbauen und in kurzer Zeit komprimiert erfasst werden müssen, wenn man den dazugehörigen Unterbau von der parallelen Vorlesung dazu noch im Kopf hat. Solches Wissen muss didaktisch klug aufgebaut werden, sonst weiß man nicht, wo man beim Selbstudium anfangen soll. Und es ist nunmal eine Tatsache, dass man ab 30 nicht mehr so leicht lernt, wie mit 20, daher ist es unerlässlich, die komplizierte Mathe hinter all dem früh und kompakt zu erfassen. Man hat dann später noch Aufwand genug, um sich in ein neues Verfahren reinzudenken, dass man nicht kennt. Es funktioniert aber, weil man Analogien wiedererkennt. Wenn ich mir aber vorstelle, ich müsste mir z.B. jetzt die gesamte erweiterte Mathe selber erarbeiten, die wir im HSII gegenüber der FH hatten (und das waren die wirklich interessanten 50%!, gegenüber dem in den ersten Semestern) dann würde ich ganz sicher kapitulieren. Habe letztens mal meine alten Unterlagen Mikroelektronik wiedergefunden: Auf der ersten Seite wird erstmal die Schrödingergleichung dazu verwendet, um Energieniveaus zu definieren, mit denen man dann später durch Vereinfachungen zu Bestimmungsgleichungen für die Vorgänge in den Kristallen kommen kann. Die Formeln für den MOS-Transistor mit allen Abhängigkeiten von Dotierungen, Temperatur, Spannung und Geometrie gehen trotzdem über 2 volle DIN-A4-Seiten. Das bringst du dir nicht mal eben selber bei. Weniger komplexe Dinge lernt man dann durchaus, auch wenn es ein völlig neues Thema ist.
:
Bearbeitet durch User
Hans Hämmerle schrieb: > selbst durchgekämpft und ausprobiert Sicher. Es ist aber schon so, dass man da weniger komplexe Dinge macht. Programmieren auf dem Niveau von Schuldkindern hat seine Grenzen, auch wenn es trickreiches gibt. Da geht es auch viel um Sachwissen. Und da ist Zeit der entscheidende Faktor! In der hat man die vielen kleinen Schnipsel aufgesammelt und die Anfängerfehler gemacht, die Studenten, die das nicht getan haben, später in den Laboren im Weg rumlagen und sie zum Stolpern brachten. http://gki.informatik.uni-freiburg.de/teaching/ss14/gki/lecture_de.html Klar kenne ich das nicht alles. Aber Vieles erkenne ich direkt aus der Regelungstechnik (Estimationstheorie) und der Nachrichtentechnik (Heuristik) wieder. Die Begriffe sind z.T. sogar identisch und dürften von dort übernommen worden sein. Dazu gibt es eine ganze Menge Begrifflichkeiten, die definierte Bedeutungen haben und das Thema strukturieren helfen. Ohne das Abzuwerten, ist das Sachwissen, das man durch Zeiteinsatz lernen kann, ebenso wie die jeweils benutzte Formelsprache. Von der logischen Wertigkeit und dem Strukturwissen, ist das eigentlich leicht einzuordnen: Letztlich rankt es sich ja wieder um die Thematik, Vorgänge zu klassifizieren und Aufwände beim Suchen von Lösungen sowie die Qualität von Ergebnissen irgendwie mit Gütekriterien zu belegen und damit mathematisch bewertbar zu machen, um die Ergebnisse zu optimieren, sie an Randbedingungen anzupassen und dazu noch die Algorithmen dahin vereinfachen und beschleunigen zu können. Ich sehe da starke Analogien zur FEM in der Mechanik, der nichtlinearen Regelungstechnik, dem simulierten anealing bei Platzierungsproblemen und der Optimierung von Testmustermengen bei Chips mittels abstrakter Schaltungsknotenfehleranalyse. All diese Felder wollen Problemlösungen finden und zusätzlich auch noch per autoadaptiver Regelschleife den Weg zur Problemlösung finden, oder wenigstens optimieren. Ein nicht unerheblicher Teil dessen, was heute unter "KI" zusammengefasst wird, gab es durchaus schon vor 30 Jahren und es wurde auch umgesetzt. Dass das Thema boomt liegt vor allem auch in der Verfügbarkeit der Maschinen. Ich finde Transformationen von Räumen in andere mathematische Räume mit Prüfung der Machbarkeit und deren Lösung in noch dazu anderen Koordinatensystemen deutlich anspruchsvoller, weil nicht direkt begreifbar und oft nicht vorstellbar.
Lothar M. schrieb: > warum beharren Ballonfahrer eigentlich so vehement darauf, dass > sie nicht fliegen. Ein Ballonfahrer bewegt sich mit der Luft (er steht), nicht durch die Luft (der fliegt).
Richard B. schrieb: > Lothar M. schrieb: >> warum beharren Ballonfahrer eigentlich so vehement darauf, dass >> sie nicht fliegen. > > Ein Ballonfahrer bewegt sich mit der Luft (er steht), > nicht durch die Luft (der fliegt). Schön, dass wir so wichtige Dinge noch am Freitag klären konnten. Ich werfe aber noch ein, dass der Ballon eben nicht in der Luft steht, sondern sich durch sie hindurch bewegt, weil die Ballonmasse träge ist. Das heisst, der schiebt sich durchaus schneller durch die Luft, wenn die sich ändert, oder auch langsamer. Der Ballon ist sozusagen ein Tiefpass und mittelt die Geschwindigkeit der Luft. Da der Korb Luftwirbel erzeugt, wird diese Geschwindigkeit unterhalb des Mittels der Luftgeschwindigkeit liegen. Der Ballon fliegt also nicht aktiv durch die Luft und er fährt auch nicht, sondern der schwimmt, wie Treibgut im Wasser. Ballonbenutzer TREIBEN in der Luft.
Hans Hämmerle schrieb: > Thomas U. schrieb: >> Auf die trifft 200% genau das zu, was W.S. und J.S. schreiben: Es fehlen >> die Grundlagen und sie müssen aufholen. Sie bremsen die anderen ab und >> haben den Hochschulzugang mit völlig anderen Kursen erworben, > > Grad das ist das Problem, zu glauben in der Schule lerne man > VHDL-Denken. Ich stelle jetzt einfach einmal die Frage, wo man das VHDL-Denken lernt? VHDL ist eine Sprache mit ganz bestimmten Eigenheiten, z.B. indirekt formulierten Zeitschritten. Reicht da das blosse Kennen digitaler Hardware? Übrigens ein sehr guter Artikel von Thomas: Beitrag "Re: Technische Grundlagen und Studentenflut" 100% d'accord!
Informationsverarbeiter schrieb: > Ich stelle jetzt einfach einmal die Frage, wo man das VHDL-Denken lernt? Nicht das Wo sondern das Wie ist entscheidend. Und das ist wie bei allem anderem im Leben auch: Ueben, ueben, ueben. Am besten einfach mal loslegen und wenn man stolpert, dann nachforschen wo Defizite und Wissensluecken sind und diese aufarbeiten. Kann man vielleicht am ehesten mit Klavierspielen vergleichen. Einfach drauf losklimpern, dann erste einfache Melodien lernen und je besser man werden will, deto tiefer muss man zwangsweise auch das Instrument und die Notentheorie dahinter verstehen.
Informationsverarbeiter schrieb: > Schön, dass wir so wichtige Dinge noch am Freitag klären konnten. Eigentlich habe ich andere Infos gesucht... EDIT: Ich habe gerade ein Mojo 3 bzw. CYC1000 bestellt.
Richard B. schrieb: > EDIT: Ich habe gerade ein Mojo 3 bzw. CYC1000 bestellt. Der Mojo und die Tutorials da auf der Seite von Alchitry haben mir sehr geholfen. Der lehrt da zwar Verilog, aber der Umstieg auf VHDL ist dann sehr angenehm.
Man kann sich VHDL vorstellen wie eine textuelle Art einen Schaltplan zu zeichnen. Signale sind dabei die Verbindungen und Ports die Anschlussbeinchen von Komponenten. In den Komponenten steckt dann die Beschreibung der Komponente, welche wiederrum aus Flipflops und Logik-Gattern zusammengesetzt ist.Heraus kommt dann eine Schaltung. Das ganze ist hirarchisch organisiert, wobei Schaltungen in Schaltungen stecken können (beliebig verschachtelt) Es gibt sogar Programme, die einen Schaltplan in VHDL umwandeln. Hier sieht man schön die starke Verwandschaft beider Welten. Allerdings gibt es innerhalb der Strukturen, welche man in VHDL abbilden kann durchaus "Programme". Wenn man zum Beispiel eine State-Machine aufbaut, werden innerhalb dieser durchaus programmartig nacheinander (Clock-Snychron) Schritte abgearbeitet oder Berechnungen durchgeführt. Man muss aber immer bedenken, dass diese Struktur letztlich eine Schaltung darstellt.
Mike schrieb: > Signale sind dabei die Verbindungen Nein, wird zwar oft so beschrieben, sie haben aber mit (einfachen) Verbindungen kaum etwas zu tun. VHDL ist eine Beschreibungssprache, die nicht nur für nur für Hardwarebeschreibung, sondern auch für Verifikation, Programmierung und vieles mehr entwickelt wurde. Darin sind Signale, ähnlich wie auch Variablen, abstrakte Konzepte, beschrieben durch die VHDL-Specs.
Sigi schrieb: > Mike schrieb: >> Signale sind dabei die Verbindungen Signale sind LOGISCHE Verbindungen, also Zuweisungen. Es sind also zunächst keine Leitungen. Daher verschwinden sie auch gerne mal.
Hans Hämmerle schrieb: > Ich behaupte inzwischen die Generation C64 ist näher an den > Hardware-grundlagen, weil die sich die Grundlagen auf Eigeninitiative, > also an der Schule vorbei, angeeignet haben Das ging damals aber auch noch, bei der sehr überschaubaren Hardware.
Mike schrieb: > Signale sind dabei die Verbindungen Allerdings können die dermaßen deklarierten "Verbindungen" auch einen Zustand oder Wert speichern... :-o
Lothar M. schrieb: > Mike schrieb: >> Signale sind dabei die Verbindungen > Allerdings können die dermaßen deklarierten "Verbindungen" auch einen > Zustand oder Wert speichern... :-o Ich bin erstaunt, Lothar. Ein Signal kann zunächst nichts speichern. 2 Signale, vor und nach einem FF können das.
Hans schrieb: > Ich bin erstaunt, Lothar. Ein Signal kann zunächst nichts speichern. 2 > Signale, vor und nach einem FF können das. Hier sind wir genau am Kern dieses Threads. Ein VHDL Signal muss nicht mit einem Kabel verwechselt werden. Je nach dem, wie man ein System in VHDL modelliert, ist das FF im VHDL Signal versteckt, oder man kann es auch so schreiben, dass zwei Signale verwendet werden. Das ist eine Stilfrage.
Angehängte Dateien:
-
SignaleRTLSchem.PNG
4,8 KB -
SignaleTechSchem.PNG
15 KB
Hans schrieb: > Ein Signal kann zunächst nichts speichern. 2 Signale, vor und nach einem > FF können das. Diese "Signale" auf der Hardware sind eben keine "Signale" im Quellcode. Ein Signal in VHDL hat also prinzipiell keinerlei Entsprechung in der Realität. Wenn ein "Signal" getaktet ist oder als ein Latch beschrieben wird, dann speichert es und es wird ein Flipflop/Latch daraus gemacht. Wenn ein Signal nur zum Routing verwendet wird, dann wird es meist vom Synthesizer beliebig wegoptimiert, zusammengefasst, verdoppelt oder sonstwas damit gemacht. Ich nehme mal diesen Quellcode:
1 | library ieee; |
2 | use ieee.std_logic_1164.all; |
3 | |
4 | entity xxx is |
5 | port( |
6 | clk : in std_logic; |
7 | i : in std_logic; |
8 | o : out std_logic); |
9 | end entity xxx; |
10 | |
11 | architecture behavioral of xxx is |
12 | |
13 | signal a,b,c,d,e,f,g,h : std_logic; |
14 | |
15 | begin
|
16 | a <= i; |
17 | b <= a; |
18 | c <= b; |
19 | d <= c; |
20 | e <= d when rising_edge(clk); |
21 | f <= e when rising_edge(clk); |
22 | g <= f; |
23 | h <= g; |
24 | o <= h; |
25 | end architecture behavioral; |
Hier bleibt nach dem Synthesizer nur das namentliche Signal e übrig. Die Signale a..d werden ersatzlos gestrichen, i geht direkt an das erste von 2 nacheinander geschalteten Flipflops, die namentlich e und f heißen. Und zwischen den beiden FFs ist eine Verbindung, die einfallsreicherweise ebenfalls e heißt. Die VHDL-Signale f..h tauchen in der Hardware nirgends mehr auf. Deshalb ist für mich ein getaktetes Signal speichernd und ich sehe im Geiste dieses Signal nicht als Verbindungsdraht, sondern als Flipflop. Das ist das, was ich als "in Hardware denken" bezeichne: ich denke mir die nötigen Bauteine und schreibe den VHDL-Code so, dass der Synthesizer mir diese mit VHDL beschriebene Schaltung generiert. Und wenn man sich dann abschließend den Technologieschaltplan anschaut, dann sieht man auch gleich, dass das erste FF hier dank Nichtverwendung von e im Design auch gleich noch wegoptimiert und in ein einstufiges Schieberegister (das platzsparenderweise in der LUT vor dem FF des CLB implementiert wurde) umgesetzt wurde. Man sollte sich in der Lernphase diese aus der VHDL Beschreibung entstandenen Schaltpläne ruhig ab&zu mal ansehen und schauen, ob man die gewünschte Schaltung darin wiederfindet...
:
Bearbeitet durch Moderator
Christoph Z. schrieb: > Hier sind wir genau am Kern dieses Threads. Ein VHDL Signal muss nicht > mit einem Kabel verwechselt werden. Sehr richtig, die grafischen Eingabesystem suggerieren aber genau das. Vlt kommt es daher. Ein Signal ist mehr etwas Theoretisches, also eine Art Meldung. Eine logische Datenleitung. Lothar M. schrieb: > Man sollte sich in der Lernphase diese aus der VHDL Beschreibung > entstandenen Schaltpläne ruhig ab&zu mal ansehen und schauen, ob man die > gewünschte Schaltung darin wiederfindet... Das kann in der Tat nicht schaden. Allerdings entziehen sich viele Konstrukte (gerade die Mathematischen) und inplizite Schleifen geometrischer Betrachtungen auf Schalplannieveau.
Noch ein kleiner Einwurf noch zu dem Strang "KI" in diesem thread: Carl schrieb: > Oder wer kennt sich hier schon mit den algoritmischen Methoden der KI > aus? Ich linke mal meine "Schach-KI", die ich gerade in einem anderen Thema schrieb und die auch hier hin gepasst hätte. Diese hatte ich angeregt durch ein solches, o.g. ->Unix-Praktikum mal angesetzt. Beitrag "Re: Schachcomputer Eigenbau?" Das -> goal in diesem Fall war die Definition der richtigen Gewichtungswerte für die Stellung. Der KI-Aspekt dabei wäre nun, per Schleifenoptimierung die genannten Werte zu optimieren und die Lösungen zusätzlich von Menschen bewerten zu lassen. Mit Bezug zum VHDL-Denken stelle ich die Frage, wie man es in VHDL lösen könnte. (und ob das ein Vorteil wäre)
Jürgen S. schrieb: > Allerdings entziehen sich viele Konstrukte (gerade die Mathematischen) > und inplizite Schleifen geometrischer Betrachtungen auf > Schalplannieveau. Durchaus. Deshalb schrieb ich "Lernphase". Denn einer, der komplexere Schaltungen mit VHDL beschreibt, hat das "VHDL-Denken" soweit hoffentlich schon verinnerlicht... ;-)
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.