Was wird denn bei "cast" und "convert" von VHDL Datentypen anders gemacht? Danke :D
Bliad B. schrieb: > Was wird denn bei "cast" und "convert" von VHDL Datentypen anders gemacht? Für die Konvertierung existieren Funktionen. Du kannst z.B. einen String in ein Bitmuster konvertieren, dann wird aus einer "0" auf einmal "00110000". Ode aus einem "a" ein "01100001". Es ändert sich also der Typ und die Länge. Beim Cast wird z.B. einem Vektor einfach nur ein neuer Typ zugewiesen. Die Elemente des Vektors haben dabei den selben Datentyp und bleiben an der selben Stelle und in der selben Reihenfolge. Und jetzt kommt der Witz: ein Integer ist in VHDL eine Zahl im Wertebereich zwischen -2147483647 (die -2147483648 fällt unter den Tisch) und 2147483647 und in dieser Weise eben noch kein Vektor mit 32 Bit. Deshalb muss der Interger explizit Bit für Bit in einen Vektor umgerechnet werden. Sieh dir einfach mal die entsprechenden Konvertierungsfunktionen im Quelltext an (z.B. to_unsigned() und to_signed() in der numeric_std).
Tatsächlich gibt es in VHDL keine casts. Das Wort "cast" kommt im IEEE-Standard nicht ein einziges Mal vor. Korrekt im Sinne des Standards wäre "type conversion" und "conversion function".
Du meinst vermutlich den Inhalt dieser Grafik: https://www.bitweenie.com/wp-content/uploads/2013/02/vhdl-type-conversions.png Im allgemeinen bzeichnet man die Umwandlung von signed/unsigned in einen std_logic_vector und andersrum als Cast. Hierbei bleibt die binäre repräsentation der Zahl erhalten. Ein unsigned und ein std_logic_vector haben beide eine bit-breite. Der "Cast" verändert jetzt nur die Interpretation dieser Bits. Ein unsigend ist eine Zahl ohne Vorzeichen, ein Signed ist eine Zahl mit Vorzeichen (2er Komplement) und der std_logic_vektor assoziiert keine Zahlenrepräsentation mit seinem Inhalt. Die Konvertierungen mit den to_* Funktionen wandeln deinen Datentyp (bspw. unsigned) in einen anderen Datentyp bspw. integer um. Dabei handelt es sich um mehr als eine simple Interpretation eines n bit breiten Wortes. Hierbei wird tatsächlich die Zahl auf eine andere "Abstraktionsebene" konvertiert. Ein integer hat im Gegensatz zu signed/unsigned keine assoziierte Bitbreite. Der integer
1 | signal my_int : integer range 1000 to 1001; |
könnte beispielsweise in Hardware tatsächlich nur durch ein einziges bit dargestellt werden (0 = 1000; 1 = 1001). Die umwandlung in einen unsigned würde dann dementsprechend einen 10 bit breiten unsigned benötigen.
M. H. schrieb: > Du meinst vermutlich den Inhalt dieser Grafik Eine eher verwirrende Grafik. Da steht zwischen Numbers und Bitvectors eine Konversion. Also etwas, das mich an VHDL schon immer gestört hat. Denn eigentlich besteht zwischen einem Bitvektor und einer (positiven) Integer-Zahl keinerlei binärer Unterschied, denn Bitvektoren werden ja zumeist dadurch vereinbart, daß man einen Wertigkeitsbereich angibt. Damit haben die im Vektor enthaltenen Bits eine Wertigkeit und damit ist der Bitvektor tatsächlich eine Zahl. Und damit sollte man rechnen können. Eigentlich. Bliad B. schrieb: > Was wird denn bei "cast" und "convert" von VHDL Datentypen anders > gemacht? Du kommst von der C Programmierung, gelle? Ein cast ist, wenn man mit einem Zeiger auf etwas zeigt und sagt "das soll ein (irgend_ein_Datentyp) sein". Einne Konversion ist, wenn man etwas hat, das man in eine andere Form bringen will. Also z.B. aus einem Integer einen Float machen oder aus einem Float eine druckbare Zeichenkette. W.S.
W.S. schrieb: > Denn eigentlich besteht zwischen einem Bitvektor und einer (positiven) > Integer-Zahl keinerlei binärer Unterschied, denn Bitvektoren werden ja > zumeist dadurch vereinbart, daß man einen Wertigkeitsbereich angibt. > Damit haben die im Vektor enthaltenen Bits eine Wertigkeit und damit ist > der Bitvektor tatsächlich eine Zahl. Und damit sollte man rechnen > können. Eigentlich. Ja, sobald du auch sagst, ob es signed/unsigned ist, kannst du damit rechnen (numeric std). Wenn du Vorzeichen, Komastelle, Rundungsmodus etc. definierst (sfixed/ufixed std), dann kannst du auch damit rechnen. Ob deine Integer-Zahl jetzt auf deinem PC binär gleich aussieht wie dein unsigned Vektor ist eine Annahme und ist für die Hardwarebeschreibung ja auch komplett irrelevant. > Du kommst von der C Programmierung, gelle? Du bist dir auch zu viele "bequeme" Abkürzungen von C gewohnt (Zahlen sind auch Buchstaben oder Pointer oder ...). Genau solche Dinge (Annahmen, implizites Wissen, unterschiedliches Verhalten auf unterschiedlichen Targets) sind es, die uns Jahrzehnte später jeden Tag als Security Probleme oder zickige Software auf die Füsse fallen. Ja, ich gebe dir recht, das in VHDL für einfache conversions und rechnereien oft zu viel geschrieben werden muss (Kommt schon mal vor, dass ein cast, resize und conversion function in einer Zeile steht). Aber wenn es mal da steht, dann läuft und ist eindeutig. Ich finde das mittlerweile angenehmer, genau zu wissen, welcher Datentyp jetzt genau wo ist. JavaScript das nur float und keine integer kennt ist für mich z. B. ziemlich suspekt :-)
W.S. schrieb: > Denn eigentlich besteht zwischen einem Bitvektor und einer (positiven) > Integer-Zahl keinerlei binärer Unterschied Das gilt nur, wenn man sich die Zahlenwelt auf die gängige Binärdarstellung reduziert. Aber man könnte statt implizit den Wert 10 als Binärvektor mit 0 = 0000, 1 = 0001, 2 = 0010, 3 = 0011, 4 = 0100, 5 = 0101 usw. zu interprezieren ja auch einen Graycode als Zahlenbasis haben, dann ist Integer 0 = 0000, 1 = 0001, 2 = 0011, 3 = 0010, 4 = 0110, 5 = 0111 usw. Und schon ist dieser Integer eben was ganz anderes als das, was so allgemein verbreitet ist. M. H. schrieb: > Du meinst vermutlich den Inhalt dieser Grafik: > https://www.bitweenie.com/wp-content/uploads/2013/02/vhdl-type-conversions.png Die kenne ich... ;-) http://www.lothar-miller.de/s9y/archives/14-Numeric_Std.html Markus F. schrieb: > Korrekt im Sinne des Standards wäre "type conversion" und "conversion > function". Ja, das hört sich aber irgendwie austauschbar an. Und die "type conversion" ist eben genau das, was man anderweitig als "cast" kennt: es wird nichts am Vektor oder der Zahl geändert, sie wird nur anders interpretiert.
:
Bearbeitet durch Moderator
W.S. schrieb: > Denn eigentlich besteht zwischen einem Bitvektor und einer (positiven) > Integer-Zahl keinerlei binärer Unterschied, denn Bitvektoren werden ja > zumeist dadurch vereinbart, daß man einen Wertigkeitsbereich angibt. > Damit haben die im Vektor enthaltenen Bits eine Wertigkeit und damit ist > der Bitvektor tatsächlich eine Zahl. Und damit sollte man rechnen > können. Eigentlich. Ein Bitvektor ist ein Array aus Bits. Nichts anderes. Mit einem Array aus Bits kann man nicht rechnen. Natürlich kann man ein Array aus Bits als Zahl interpretieren. Auf 100 verschiedene Arten und Weisen: signed, unsigned, Byte big oder little endian, reverse bit order oder irgend was anderes, noch nie da gewesenes oder eine Kombination aus allem zusammen. VHDL hat (m.E. aus gutem Grund) beim Typkonzept die Philosophie von Ada übernommen: da muß man hinschreiben, was man meint, implizite Konvertierungen gibt es nicht (bzw. nur zwischen "closely related types"). Man kann auf zwei Arten damit umgehen: weiterhin nicht darüber nachdenken, welchen Typ man eigentlich meint und stattdessen den simpelsten nehmen. Dann tippt man sich mit Konvertierungen tot, weil man gegen diese Philosophie arbeitet. Oder man akzeptiert dieses Konzept, macht sich Gedanken, was man eigentlich will und meint, schreibt genau diesen Typ hin und stellt plötzlich fest, daß man weitgehend ohne Konvertierungen auskommt.
Lothar M. schrieb: > Aber man könnte statt... ja auch einen Graycode als Zahlenbasis haben, > dann ist ... > Und schon ist dieser Integer eben was ganz anderes als das, was so > allgemein verbreitet ist. Da hast du dir selber ein Ei gelegt, denn ein Graycode ist keine Zahl, denn sämtliche Bits in einem solchen Code sind so, daß sich von einem Zustand zu einem benachbarten Zustand genau 1 Bit ändert. Es gibt also keinen Wertigkeits-Unterschied. Und damit ist das per se keine Zahl. Kann also nicht als das von dir gedachte Gegenbeispiel dienen. Ganz prinzipiell: Ein Vektor ist ein Gebilde, was mehrere voneinander unabhängige Werte hat: z.B. ein geometrischer Vektor mit (X,Y,Z) als kartesische Koordinaten oder mit (R,phi,psi) als Länge und zwei Winkeln ggü. den Koordinaten. Verallgemeinert ist ein Vektor ein Gebilde mit mehreren voneinander unabhängigen Dimensionen. Und ein Bitvektor ist genau genommen ein Gebilde mit mehreren unabhängigen Bits. Aber in VHDL wird sowas im allgemeinen durch Angabe eines Wertigkeitsbereiches deklariert, was eine Relation zwischen den Bits beinhaltet. Also eine Wertigkeit der Bits untereinander - und damit sind die Bits nicht mehr voneinander unabhängig, spannen also keine Dimensionen auf. Es wäre anders, wenn die Deklarationen grundsätzlich anders wären, z.B. etwa so: Bitvektor : (EinName, EinAndererName, NochEinName, .... usw.) Aber so ist es eben nicht. W.S.
Markus F. schrieb: > Ein Bitvektor ist ein Array aus Bits. Nichts anderes. Mit einem Array > aus Bits kann man nicht rechnen. Markus, mit einem Array aus Bits kann man rechnen - unter der Voraussetzung, daß es eine Wertigkeit der Bits untereinander gibt. Und das ist bei der in VHDL üblichen Deklaration von Bitvektoren der Fall. Nur dann, wenn keines der enthaltenen Bits irgend eine Relation zu einem anderen enthaltenen Bit besitzt, ist ein Rechnen ausgeschlossen. Lies bitte meine Antwort an Lothar. Schlußendlich: Daß bei Bitvektoren das Rechnen ausgeschlossen wird, ist nichts anderes als eine Zickigkeit von VHDL. Es ist logisch unbegründet. W.S.
W.S. schrieb: > Markus, mit einem Array aus Bits kann man rechnen - unter der > Voraussetzung, daß es eine Wertigkeit der Bits untereinander gibt. Und > das ist bei der in VHDL üblichen Deklaration von Bitvektoren der Fall. Falsch. Die Wertigkeit von Bits in einem BIT_VECTOR ist in VHDL nirgendwo definiert. Dafür gibt es SIGNED und UNSIGNED. Da ist das klar festgelegt und deswegen kann man damit auch rechnen. Wie ich oben schon sagte: nimm' den Typ, der zu dem, was Du machen willst, am besten paßt. Man kann auch mit dem Hammer eine Schraube in die Wand hauen, rächt sich aber meist.
Markus F. schrieb: > Falsch. Die Wertigkeit von Bits in einem BIT_VECTOR ist in VHDL > nirgendwo definiert. Grmpf... Betrachte mal sowas: signal karlheinz : bit_vector(0 to 7); oder signal ottokar : bit_vector(15 downto 8); An diesen Stellen sieht man allerdeutlichst die vereinbarte Wertigkeit. Es wäre etwas anderes, wenn da stände: signal karlheinz : bit_vector(8); oder signal ottokar : bit_vector(8); So geht es aber eben nicht. Du hast in die Tasten gegriffen, bevor du gründlich nachgedacht hast. Gelle? Mir scheint, daß ein wesentlicher Teil des Problems darin besteht, daß die Lehre dieser Programmiersprache zu schludrig ist. Ganze Heerscharen von Trittbrettfahrern fühlen sich berufen, ihre persönliche Version von Tutorial zu VHDL in die Welt zu setzen. Das Blöde daran ist, daß zum einen der eine vom anderen abschreibt und daß alle zusammen zu oberflächlich sind. Genau deshalb landet man als Leser immer wieder beim bit_vector als ultimativem Signalformat. Also beim so ziemlich unbenutzbarsten Ding. In der Folge geiern ganze Heerscharen von derart geschulten Programmierern nach Konvertierungen. Eben um etwas tun zu können, was weitaus wichtiger ist als der ganze Bitvektor, nämlich RECHNEN. Markus F. schrieb: > Wie ich oben schon sagte: nimm' den Typ, der ... Nee, ich nehme in solchen Fällen lieber Verilog. Ist zwar auch nicht besser im Allgemeinen, aber weniger zickig im Speziellen. W.S.
W.S. schrieb: > Da hast du dir selber ein Ei gelegt Ich sehe nur, dass für dich eine Zahl eben immer im binären Sytem mit einer Bitgewichtung anhand der Bitposition dargestellt wird: 2^7, 2^6, 2^5, ... 2^0. Das ist aber eben nur 1 mögliche Darstellung. Es gibt auch andere. > denn ein Graycode ist keine Zahl Es gibt Absolutwertgeber, die ihren Zählerstand als Graycode ausgeben. Dort sind dann bei "Codierung" z.B. die Integerzahlenwerte 0..7 diesen Codes entsprechend unterschiedlich zugeordnet: https://www.wikiwand.com/de/Absolutwertgeber Und da sieht eine 5 im Graycode eben anders aus als eine 5 im Binärcode. Trotzdem ist es in beiden Fällen eine 5. Und um dann auf einem Binärcode-Rechner komfortabler arbeiten zu können, muss man diese Gray-5 in eine Binär-5 umwnadeln: http://www.lothar-miller.de/s9y/archives/69-Graycode-Umwandlung.html > Ganz prinzipiell: Ein Vektor ist ein Gebilde, was mehrere voneinander > unabhängige Werte hat: z.B. ein geometrischer Vektor mit (X,Y,Z) als > kartesische Koordinaten oder mit (R,phi,psi) als Länge und zwei Winkeln > ggü. den Koordinaten. So wie ein Vektor aus vielen unabhängigen std_logic wie z.B. ein Konfigurationswort in einem Prozessor oder sonstwo.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Und um dann auf einem Binärcode-Rechner komfortabler arbeiten zu können, > muss man diese Gray-5 in eine Binär-5 umwnadeln: oder eben einen Satz von überladenen Arithmetik-Funktionen bereitstellen, die mit einem "graycode Subtyp" direkt rechnen können.
Lothar M. schrieb: > Und da sieht eine 5 im Graycode eben anders aus als eine 5 im Binärcode. > Trotzdem ist es in beiden Fällen eine 5. Nö. Den Graycode mußt du erstmal mittels Tabelle o.ä. in eine Zahl wandeln, nämlich in die Nummer der zutreffenden Position in der Tabelle. So etwa wie "das fünfte Bild im Album". Errechnen kannst du ihn jedenfalls nicht. Begreife mal, daß es nicht ohne Grund Graycode heißt anstelle Grayzahl. Aber ich will mich nicht mit euch streiten. Wenn ihr alles, was euch grad paßt, als Zahl definiert, dann ist das wie bei C, wo es an gar vielen Stellen heißt "hier ist das eben so! Basta." Logik oder mathematische Präzision ist was anderes. W.S.
Zahl hat erstmal nichts mit einem Stellenwertsystem zu tun. Ja, wir sind das so gewohnt, aber das ist kein Muss. Siehe die römischen Zahlen. Jetzt ist das so, dass ein std_logic_vector erstmal nur ein Array aus Bits ist. Ob das ein Stellenwertsystem zur Basis 2 ist oder nicht ist nicht definiert. Es ist auch nicht definiert welches Bit welche Wertigkeit hat. Das ist einfach nur eine Reihe an Bits. Wenn man damit rechnen will, dann sollte man mitteilen wie diese Reihe an Bits interpretiert werden soll. Dafür gibt es unsigned(), signed(), ... Leider hat(te) es sich eingebürgert implizit anzunehmen, dass Arrays aus Bits gleichzeitig immer eine Zahl im Binärsystem sind und man damit einfach rechnen kann. Das stimmt aber eben nicht. Es gibt verschiedenste Möglichkeiten Zahlen darzustellen nur mit 1 und 0. Graycode ist ein Beispiel. Das Zweierkomplement wäre ein anderes Beispiel. Welcher Zahl entspricht denn das Array "11010110"? 214? 42? 155? Da fehlt schlicht Information. Klar kann man das auch so jetzt einfach als Binärzahl ansehen, aber dann liegt man eben manchmal falsch. Um das zu vermeiden sagt man eben explizit als was das Array interpretiert werden soll.
Markus F. schrieb: VHDL hat (m.E. aus gutem Grund) beim Typkonzept die Philosophie von Ada übernommen: da muß man hinschreiben, was man meint, implizite Konvertierungen gibt es nicht (bzw. nur zwischen "closely related types"). Genau das ist eine der Eigenschaften, die ich an VHDL im Gegensatz zu Verilog mag: Man braucht wenig implizites Wissen, es steht einfach da!
W.S. schrieb: > Betrachte mal sowas: > signal karlheinz : bit_vector(0 to 7); > oder > signal ottokar : bit_vector(15 downto 8); > > An diesen Stellen sieht man allerdeutlichst die vereinbarte > Wertigkeit. Und wo ist jetzt das LSB bzw. das MSB? Leider bekommst du zwei Antworten, wenn du zwei Leute fragst die jeweils für z.B IBM und z. B. Intel Arbeiten. (Das war lustig zu lernen in der Zeit als Xilinx noch OPB und PLB als on-chip Busse eingesetzt hat). Pull Request: ♻ Signal type changed due to experience
1 | -- type Weltbild is (Schwarz, Weiss); |
2 | -- signal Welt : Weltbild; |
3 | ++ signal Welt : real; |
Gustl B. schrieb: > Jetzt ist das so, dass ein std_logic_vector erstmal nur ein Array aus > Bits ist. Ob das ein Stellenwertsystem zur Basis 2 ist oder nicht ist > nicht definiert. Es ist auch nicht definiert welches Bit welche > Wertigkeit hat. Das ist einfach nur eine Reihe an Bits. Wenn man es so deklarieren würde, daß es nur ein Platz für N Bits sei, also z.B. signal karlheinz : bit_vector(8); womit Platz für 8 Bits veeinbart worden wäre, dann hättest du Recht. Aber gerade in VHDL hat es sich eingebürgert, einen Bereich für Stellenwerte anzugeben: signal karlheinz : bit_vector(0 to 7); und damit ist das nicht nur eine bunte Versammlung von Bits, sondern eine solche, bei denen die Bits einen relativen Wert zueinander haben. Hier von 2^0 bis 2^7. Und das ist eine Zahl. Sowas wieder zu negieren, indem man das Dekret erläßt, daß das eben KEINE Zahl sein soll, sondern nur die o.g. bunte Versammlung von Bits, ist nur eine selbst verursachte Beschränkung der solcherart kreierten Programmiersprache. Nochwas prinzipielles zum Rechnen: Ein wesentlicher Grundbaustein jeglichen Rechnens ist die Addition. Konstrukte, die keine Addition ermöglichen, sind zum Rechnen prinzipiell ungeeignet. Nun weiß man bereits als Grundschüler, daß 1+1=2 ist. Ein Bit kann hingegen nur von 0 bis 1 zählen, folglich ist für die Addition ein Übertrag in die nächsthöhere Stelle erforderlich. Die Existenz des Übertrages ist aber gebunden daran, daß es eine Wertigkeit zwischen den beteiligten Bits gibt. Sonst hat der Übertrag kein Ziel. Wenn man nun wie Lothar eine Codierung wie Graycode als Argument heranzieht, dann zeigt man ungewollt, daß man mit dem Graycode eben nicht rechnen kann, weil der nur eine einzige Bit-Transition zwischen benachbarten Zuständen zuläßt. Aber die Addition beinhaltet immer zwei mögliche Bit-Transitionen, nämlich das Resultatbit und das Übertragsbit. Tja, die Mathematik (und auch deren numerische Schwester) sind Despotinnen. Sie haben IMMER Recht und wer sich dem nicht bedingungslos unterordnet, der wird mit einer Hausnummer bestraft. Und wenn man bei einer Programmiersprache sagt "das ist hier eben so!", dann ist das nur die Umschreibung dessen, was man woanders unter einem Bug in der Sprachkonstruktion verstehen würde. W.S.
W.S. schrieb: > Wenn man nun wie Lothar eine Codierung wie Graycode als Argument > heranzieht, dann zeigt man ungewollt, daß man mit dem Graycode eben > nicht rechnen kann, weil der nur eine einzige Bit-Transition zwischen > benachbarten Zuständen zuläßt. Natürlich kann ich beim Graycode auch Schritte auslassen. Es wird dadurch niemand Schaden erleiden. Der Vorteil, den der Graycode bei einer Subtraktion oder Addition von 1 hat, geht dann eben verloren. Hier mal als Impuls ein ganz einfaches (und recht ineffizientes) Zahlensystem, das jedes Kind mit seinen Fingern nachvollziehen kann: nimm die Anzahl der 1 vor der 0 als Wertigkeit:
1 | 0 = 0 |
2 | 1 = 10 |
3 | 2 = 110 |
4 | 3 = 1110 |
5 | 4 = 11110 |
6 | 5 = 111110 |
7 | 6 = 1111110 |
8 | 7 = 11111110 |
9 | 8 = 111111110 |
10 | 9 = 1111111110 |
Das lässt sich dann auch leicht addieren, indem man die Einsen links von der 0 aneinanderhängt und mit einer 0 terminiert: 4 + 5 = 11110 + 111110 = 1111111110 = 9 Das ist so ähnlich wie eine Addition mit Händen: 4 Finger links und 5 Finger rechts gibt 9 Finger. Also kann ich mit diesem Zahlensystem basierend auf 0 und 1 auch ganz leicht rechnen und kann natürliche Zahlen inklusive der 0 darstellen. > signal karlheinz : bit_vector(0 to 7); > und damit ist das nicht nur eine bunte Versammlung von Bits, sondern > eine solche, bei denen die Bits einen relativen Wert zueinander haben. Doch, es ist ein bunte Ansammlung von Bits, du kannst mit einem einen bit_vector an sich nicht rechnen. Erst, wenn du den '+' Operator überlädst und eine Funktion bereitstellst, die zwei bit_vector-en irgendwie addieren kann, dann hast du eine Addition. Wie diese Addition die Bits gewichtet, das ist vorerst noch nicht definiert. Die Addition muss aber eben nicht zwingend die naheliegendste aller Methoden anwenden. Ich kann die Additionsfunktion für den bit_vector auch so schreiben, dass er das Fingersystem beherrscht und die Anzahl der Einsen den Integerwert darstellt. > Und wenn man bei einer Programmiersprache sagt "das ist hier eben so!", > dann ist das nur die Umschreibung dessen, was man woanders unter einem > Bug in der Sprachkonstruktion verstehen würde. Aber in Verilog ist es wie in C eben implizit so, dass eine Integerzahl immer als Binärzähl interpretiert und dargestellt wird. Ich kann dort gar keine Darstellung im obigen "Fingersystem" definieren. Ist das jetzt so ein Bug, wie du ihn meinst? Aber seis drum, mag ein jeder nach seiner Fasson glücklich werden.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > 0 = 0 > 1 = 10 > 2 = 110 > 3 = 1110 > 4 = 11110 > 5 = 111110 > 6 = 1111110 > 7 = 11111110 > 8 = 111111110 > 9 = 1111111110 Meinst du jetzt die Längenänderung als Zahl? Das führt zum Chaos, denn die Länge (bzw. die Anzahl von Einsen) als proportional zur Zahl ist rein theoretisch zwar möglich, bedarf aber des Abzählens - und ist praktisch nur Murks. Stell dir mal ein FPGA vor, was auf solche Weise die Zahl 4711 oder etwas noch größeres behandeln kann. Kurzum, Konstrukte wo man erstmal irgend etwas abzählen muß, bevor man mit der abgezählten Anzahl rechnen kann, taugen nicht mal als Ausrede. Mir kommt da der Witz von der Hausfrau und ihrem Schulbuben mit seinen Hausaufgaben in den Sinn: "Mama, wieviel ist 11-3?" "Also paß auf, mein Fritzchen: Wenn du 11 Taschenrechner auf den Tisch legst und ich nehme davo drei weg, wieviele Taschenrechner bleiben dann übrig?" Lothar M. schrieb: > Aber in Verilog ist es wie in C eben implizit so, dass eine > Integerzahl immer als Binärzähl interpretiert und dargestellt wird. Ich > kann dort gar keine Darstellung im obigen "Fingersystem" definieren. Ist > das jetzt so ein Bug, wie du ihn meinst? Nö. Und da das Fingerabzählen ist so albern, daß wir es jetzt außen vor lassen sollten. Wenden wir uns stattdessen der weiter oben genannten Grafik wieder zu: Nicht nur, daß dort verwirrendermaßen zwischen "Numbers" und "Bitvectors" nur über eine "Conversion Function" übergegangen wird, auch die "Signed" und "Unsigned" Typen haben nichts mit "Numbers" zu tun, denn sie gehören dem Bitvektor-Bereich an - und nicht dem Bereich der "Numbers". Das ist Unsinn, denn ein Vorzeichen (oder dessen Abwesenheit) setzen voraus, daß die übrigen Bits in der Meute irgend einer Ordnung gehorchen und eben NICHT nur eine bunte Gruppe von Bits sind. Insofern sehen ich die Anwendbarkeit von Konversionen und Casts bei VHDL eigentlich nicht als gegeben an. Das ist C-Denke und ganz offensichtlich nicht VHDL-Denke. Aber das Nicht-Rechnen-Dürfen bei Bitgruppen, die von ihrer Deklaration her eine innere Rangordnung haben, ist denoch ein Fehlkonstrukt von VHDL. W.S.
Lothar M. schrieb: > Aber seis drum, mag ein jeder nach seiner Fasson glücklich werden. Lothar, lass' gut sein. Er hat doch schon gesagt, daß er's nicht kapieren will und stattdessen Verilog nimmt.
W.S. schrieb: > Meinst du jetzt die Längenänderung als Zahl? Muss nicht. Man könnte das eben wie mit den 10 Fingern auch machen. Als Beispiel hat das Array immer 10 Bits. Und die Anzahl der Einsen von rechts sagt welcher Wert das ist. "0000111111" = 6 "0000000111" = 3 Auch damit kann man rechnen, aber anders, das ist kein Stellenwertsystem. Ich hatte als Beispiel schon die römischen Zahlen genannt. Auch damit kann man rechnen und es ist kein Stellenwertsystem. W.S. schrieb: > Aber das Nicht-Rechnen-Dürfen bei Bitgruppen Du darfst mit Bitgruppen rechnen. Überlade deine Funktionen oder verwende geeigente Packages. Aber das ist dann auch dein Fehler wenn das Ergebnis falsch ist. Wenn du SLV = SLV + SLV rechnest, was wird dann gemacht? Woher weiß die Funktion + ob deine SLVs vorzeichenbehaftet sind oder im Zweierkomplement, ...? Und weil man das nur durch das Angucken eines SLVs nicht wissen kann sollte man das der Funktion mitteilen. C = std_logic_vector(unsigned(A) + unsigned(B)); Das sagt nur der Funtion +, dass die beiden Summanden vom Typen unsigned sind. Aus meinder Sicht ist das auch gut so, denn einem Array aus Bits kann man nicht ansehen wie die Bits eine Zahl bilden. Weil man das nicht kann, kann es auch keine generischen Funktionen wie + geben, die mit SLVs funktionieren und immer richtig rechnen. In praxis kommen schon recht häufig Array aus Bits vor die keine Binärzahl ohne Vorzeichen darstellen. Viele AD-Wandler liefern Zweierkomplemet. Das ist also wirklich relevant, dass es verschiedene Interpretationsarten von Array aus Bits gibt. Was vielleicht ein Verständnisproblem ist ist das (7 downto 0) oder (0 to 7). Das könnte eine Wertigkeit implizieren. Aber dem ist nicht so. Wie sollte man einen "Haufen an Bits ohne Wertigkeit" auch anders schreiben? W.S. schrieb: > signal karlheinz : bit_vector(8); Und weiter? Wie würdest du jetzt auf die einzelnen Bits zugreifen? Man braucht also irgendwie eine Adressierbarkeit der Einträge. Auch bei Arrays in C kann man die einzelnen Elementa adressieren. Versuche dir so ein Array aus Bits wie ein Bündel aus Drähten vorzustellen. Nur dass man in einer Sprache wie VHDL eben die Drähte durchnummeriert damit man sie wiederfinden kann. Man könnte die Bits auch im Kreis anordnen, also irgendwie signal karlheinz : bit_vector(8); und dann hat man alle 45° ein Bit. karlheinz(225) würde dann also ein Bit zurückliefern. Könnte man machen, ist aber irre umständlich. Und auch dann könnte man sagen: Da gibt es eine implizierte Reihenfolge, denn in der Schule lernt man, dass man bei 0° beginnt und gegen den Uhrzeigersinn weiterzählt. Jedenfalls hat man sich entschieden die Bits in einer Reihe anzuordnen und durchzunummerieren um sie zu adressieren. Aber nur weil das so ist, gibt es noch keine Wertigkeit. Irgendwie muss man Bits eben anordnen und adressierbar machen.
:
Bearbeitet durch User
Gustl B. schrieb: > Muss nicht. Man könnte das eben wie mit den 10 Fingern auch machen. Also um z.B. bis zu 4711 darstellen zu können, braucht man 4712 FF im FPGA? (eine für die abschließende 0) Ich meine, wir sind hier im Esoterischen angekommen. Kein praktisch denkender Mensch würde auf solche Ideen kommen. Kannste glauben. Mein Fazit: das betreffende Bild taugt nix, allenfalls zum Verwirren von Lernenden. Und daß VHDL Leute dazu bringt sowas als Erklärung zu malen, ist ein Übel. W.S.
W.S. schrieb: > Also um z.B. bis zu 4711 darstellen zu können, braucht man 4712 FF im > FPGA? (eine für die abschließende 0) Das war nur ein Beispiel. W.S. schrieb: > Kein praktisch denkender Mensch würde auf solche Ideen kommen. Oh doch. Nicht im FPGA, aber wenn Menschen mit ihren Fingen zählen, dann meist genau so. Und das obwohl sie im Binärsystem schon an einer Hand bis 31 oder als signed von -16 bis +15 zählen könnten. W.S. schrieb: > Mein Fazit: das betreffende Bild taugt nix, allenfalls zum Verwirren von > Lernenden. Deshalb hatte ich ja noch mehr geschrieben ... das Array aus Bits kann ja auch eine Zahl im Zweierkomplement enthalten oder sonst wie, egal. Jedenfalls ist es falsch immer anzunehmen, dass man damit rechnen kann ohne die Darstellung zu kennen. Das funktioniert nicht und das kann auch nicht funktionieren weil eben die Rechenfunktion nicht weiß ob die Arrays bei der Rechnung unsigned, signed, ... sind. Daher ist der cast wichtig wenn man direkt mit slvs rechnen will.
Gustl B. schrieb: > Und weiter? Wenn es Mode wäre, den Bits Namen zu geben, dann könnte man die Bits bei ihrem Namen nehmen. z.B. bit_vector(otto,ida,emil,gustl, ... usw); Wenn man eine Konvention aufgestellt hat, daß die Bits der Reihe nach durchnummeriert werden, um sie zu adressieren, dann reicht der bit_vector(8); bequem aus, um die Bits von 0 bis 7 zu nummerieren. Ungefähr so, wie das auch bei C gemacht wird. Und da dann diese Nummern nur zum Ansprechen des Bits benutzt werden, kann man sie auch immer von 0 an aufsteigend durchzählen. Eine Angabe "15 downto 8" ist da völlig überflüssig. Bei Pascal hat man die Möglichkeit, in Arrays den Indexbereich an beiden Enden festzulegen, aber dort hat man es (wie in C) mit Elementen des Arrays zu tun, die ihr eigenes Format haben: ottokar : array[7 .. 14] of double; In beiden Fällen (array in C oder in Pascal) haben die Array-Elemente ein eigenes Format und sind nicht nur einzelne Bits. Das macht einen großen Unterschied zu VHDL aus. Wenn man aber wie in VHDL zwei Enden angibt, dann ist das entweder eine schiere Gedankenlosigkeit in der Sprachdefinition oder ein Wertebereich. Und nun such es dir aus, welches du bevorzugst. Rein von der praktischen Seite her wären mir individuell mit Namen versehene Bits sympatischer als alle per Konvention numerierten Bits. W.S.
W.S. schrieb: > In beiden Fällen (array in C oder in Pascal) haben die Array-Elemente > ein eigenes Format und sind nicht nur einzelne Bits. Das macht einen > großen Unterschied zu VHDL aus. Nun, auch in VHDL kannst du ein Array aus unsigned bauen. Dann haben die Elemente ebenfalls ihren eigenen Typen. Und selbst beim std_logic_vector haben die Elemente ihren eigenen Typen, nämlich std_logic. In C wäre das ein Array aus Boolean. W.S. schrieb: > Wenn man aber wie in VHDL zwei Enden angibt, dann ist das entweder eine > schiere Gedankenlosigkeit in der Sprachdefinition oder ein Wertebereich. Ich sehe das als Array, in dem die Elemente eine Nummer haben und man kann eben festlegen welcher Wertebereich für die Nummerierung verwendet werden soll. Und ob das aufsteigend oder absteigend nummeriert werden soll. Wieso soll auch jedes Array ein Element 0 haben? Vielleicht will ich ein Array mit Adressen 8,9,10 und 11. Macht sogar Sinn, denn vielleicht will ich zum Adressieren drei nicht zusammenhängende Bits eines 4-Bit breiten Busses verwenden. Bei W.S. schrieb: > signal karlheinz : bit_vector(8); wären die Adressen immer festgelegt auf 0 ... 7. W.S. schrieb: > bit_vector(otto,ida,emil,gustl, ... usw); Das gibt es doch auch in VHDL mit enumerated Types.
Gustl B. schrieb: > Wieso soll auch jedes Array ein Element 0 haben? Vielleicht will ich ein > Array mit Adressen 8,9,10 und 11. Macht sogar Sinn, denn vielleicht will > ich zum Adressieren drei nicht zusammenhängende Bits eines 4-Bit breiten > Busses verwenden. Gegenfrage: Wieso nicht? Immerhin soll es ja nur zur eindeutigen Benennung des Bits (oder des Drahtes..) dienen. Ob du nun als Namen eine 3 verwendest oder ein 'ottokar' ist doch der Maschine egal. Und da du nun schon mehrere nicht zusammenhängende Bits in einen bit_vector gestopft hast, können deine drei nicht zusammenhängenden Bits auch oskar, lisa und karl heißen. Irgendwie drehen wir uns im Kreis: zuerst werden Grenzen des Bitvektors angegeben (0 to 7), die einen Wertebereich darstellen, dann wird verneint, daß es sich um einen Wertebereich handelt, dann wird gesagt, daß es nur Nummern zum Auswählen des Bits sind, dann ist es auf einmal wichtig, daß die Nummern zum Auswählen des Bits eine numerische Zuordnung zu bestimmten Adreßbits erfordern und damit dann doch eine Wertigkeit der Bits im Bitvektor darstellen. Also was denn nun? Je mehr ich hier lesen muß, desto unsinniger erscheint mir das Konstrukt "Bitvektor" in VHDL. Zum Rechnen eignet er sich nicht, denn das ist mutwillig unterbunden. Wozu also dann? W.S.
W.S. schrieb: > können deine > drei nicht zusammenhängenden Bits auch oskar, lisa und karl heißen. Klar, spricht nichts dagegen, außer dass es sehr umständlich ist. Vielleicht sind Hausnummern ein gutes Beispiel. AUch Häuser in einer Straße sind quasi ein Array aus Häusern. Die haben keine Wertigkeit oder so. Aber man nummeriert sie. Klar, man könnte das mit den Hausnummern auch lassen, aber dann wäre das für die Post sehr schwer. Denn mit Hausnummern gibt es eine Reihenfolge. Wenn man das Haus mit der Nummer 5 sieht, dann weiß man dass die 4 und 6 nicht weit sind. Wenn man aber statt Nummern Wörter verwendet, dann gibt es erstmal keine Reihenfolge. Es wäre also schwieriger Häuser anhand ihres Namens zu finden. In einem Array kannst du auch den Bits Namen geben. Das sind die Enums. VHDL kann das. Aber die Adressierung ist dann eben schwer. testvector = bit_vector(otto,ida,emil,gustl, ... usw); bit = testvector(otto) Wenn das mit zahlen durchnummeriert ist, dann kann man da in einer Schleife alle Elemente des Vectors durchgehen. for i in 0 to 7 loop end loop; Bei Namen wäre das ein for i in otto to gustl loop end loop; Aber weil Namen eben im Gegensatz zu ganzen Zahlen keinen eindeitigen Vorgängen und Nachfolger haben geht das nicht. Was ist der nächste Name nach otto? Ist das ida, emil oder gustl? W.S. schrieb: > zuerst werden Grenzen des Bitvektors > angegeben (0 to 7), die einen Wertebereich darstellen Nein. 0 to 7 ist nicht der Wertebereich. Das ist der Bereich der Indizes. Es gibt also 8 Elemente. Der Wertebereich hängt davon ab wie die Bits eine Zahl bilden. 0 to 7 könnte Zahlen von 0 bis 255 darstellen. Oder auch von -128 bis 127. Und mit anderen Darstellungen auch noch weitere Varianten. W.S. schrieb: > dann ist es auf einmal > wichtig, daß die Nummern zum Auswählen des Bits eine numerische > Zuordnung zu bestimmten Adreßbits erfordern und damit dann doch eine > Wertigkeit der Bits im Bitvektor darstellen. Das ist nicht wichtig, aber es ist praktisch. Arrays sind erstmal nur eine Anordnung von Elementen. Und in Elementen speichert man Werte. Ein slv ist ein Array aus std_logic. Man kann Arrays aber auch aus Integern, Unsigned, ... machen und auch 3D Arrays. Am Ende ist das Speicher. Und wie das so ist, wenn man etwas im Speicher ablegt, dann will man das meist an eine bestimmte Stelle ablegen und später auch von einer bestimmten Stelle wieder lesen. Das nennt sich Adressieren. Und es ist auch üblich Speicher zu organisieren in zusammenhängende Bereiche die dann am Block nacheinander geschrieben und gelesen werden. Und genau dazu sind Zahlen sinnvoll als Adresse. Man kann an einer Adresse im Speicher anfangen und dann nacheinander weitere nachfolgende Adressen ansprechen. for i in 8 to 15 loop a := a xor speicher(i); end loop; Mit Namen ginge das wieder nicht. W.S. schrieb: > Zum Rechnen eignet er sich nicht, denn das ist > mutwillig unterbunden. Wozu also dann? Klar kannst du damit rechnen. Verwende ein passendes Package oder überlade die benötigte Funktion. Auch wenn man nicht direkt damit rechnen kann ist der sinnvoll. Das ist ein Bithaufen. Wenn man rechnen will muss man eben casten, also mitteilen wie der Bithaufen interpretiert werden soll.
:
Bearbeitet durch User
W.S. schrieb: > Irgendwie drehen wir uns im Kreis: zuerst werden Grenzen des Bitvektors > angegeben (0 to 7), die einen Wertebereich darstellen, dann wird > verneint, daß es sich um einen Wertebereich handelt Es ist der Wertebereich der Indizes, nicht des Vektors. In VHDL hat ein Bitvektor eben erstmal keine Bedeutung. Welche sollte es auch sein? Unsigned? Zweierkomplement? Einerkomplement? Sign-Magnitude? BCD? Warum sollte eines davon das „richtige“ sein? W.S. schrieb: > Ob du nun als Namen eine 3 verwendest oder ein > 'ottokar' ist doch der Maschine egal. Dafür gibt es eigentlich records. Und ja, der Maschine ist es Schlußendlich egal, wird am Schluß der Synthese alles zu binärer Logik mit zwei Spannunspegeln. All diese Regeln sind da um es dem Entwickler zu erleichtern ein korrektes Ergebnis zu erreichen. Es ist ein anderer Ansatz als in den meisten anderen Sprachen aber wenn man sich darauf einläßt sehr mächtig. Und weil es schon mehrfach im Thread falsch war, std-logic-Vector hat weder etwas mit Bits noch mit Boolean zu tun. Std-logic ist 9-wertige Logic, nicht 2-wertige Boolesche Logik. Auch deshalb kann man std-Logic-Vektoren und darauf aufbauende wie signed und unsigned nicht einfach nach Integer casten. Und ja, die meisten VHDL-Tutorials sind grottenschlecht und auf dem Stand von VHDL-87 oder VHDL-93.
Gustl B. schrieb: > Klar, spricht nichts dagegen, außer dass es sehr umständlich ist. OK, die etwaige Umständlichkeit lassen wir hier mal außen vor. Schließlich ist das hier eigentlich eine Diskussion über die Umwandlung einer Typdarstellung in eine andere (integer --> float oder so) versus die Zuweisung einer "Halde von Bits" zu einem bekannten Datentyp. Vulgo "convert" versus "cast". > Vielleicht sind Hausnummern ein gutes Beispiel. Ach nee, denn schließlich führt das Übersetzungsprogramm eine Namensliste und da ist es wurscht, ob das Bit nun 13 oder otto heißt. Es ist nur für uns Menschen unterschiedlich gut/schlecht zu lesen. Und wenn das Bit nicht 15, sondern MEMRQ heißt, dann ist das für uns Menschen sogar leichter zu lesen und zu verstehen. Gustl B. schrieb: > Wenn das mit zahlen durchnummeriert ist, dann kann man da in einer > Schleife alle Elemente des Vectors durchgehen. Das ist aber nur der menschlichen Faulheit geschuldet. Das Übersetzungsprogramm faltet sowas immer auf - solange wir es mit programmierbarer Logik zu tun haben. Bei Quellen für alle Arten von Turingmaschinen ist das zumeist eine echte Schleife. > Aber weil Namen eben im Gegensatz zu ganzen Zahlen keinen eindeitigen > Vorgängen und Nachfolger haben geht das nicht. Was ist der nächste Name > nach otto? Ist das ida, emil oder gustl? Ähem, wenn Bits einen eindeutigen Vorgänger und Nachfolger haben, dann ist damit auch ein Wertebereich abgesteckt. Das widerspricht dem Postulat, daß es genau DAS bei einem Bitvektor (über den wir hier diskutieren) nicht gibt. Bzw. geben darf. Gustl B. schrieb: > Nein. 0 to 7 ist nicht der Wertebereich. Das ist der Bereich der > Indizes. Es gibt also 8 Elemente. Wozu dann (0 to 7) ? eine einfache 8 hätte komplett ausgereicht. Wenn es nur zum Abzählen ist, dann reicht ein Zählen von 0 beginnend immer aus. Dann hat ein (15 downto 8) auch keine Daseinsberechtigung. Im Umkehrschluß heißt das, daß die Nennung von Grenzwerten 0 bis 7 oder so eben DOCH eine Bedeutung hat, die über das schiere Abzählen hinaus reicht. Bloß daß man das hier mutwillig unter den Tisch fallen läßt. Mittlerweile sehe ich das so, daß das Sprachelement "bit_vector" nur eine Ergänzung, vulgo ein Lückenbüßer ist, damit man neben wohldefinierten mehrbittigen Datentypen auch etwas "generisches" hat, also etwas "downgegradetes" um es mal so denglisch zu nennen. So etwa wie der "pointer" in Pascal oder der "void*" in C. Das sind Zeiger, mit denen man zwar irgendwo hin zeigen kann, aber nicht ausdrücken, auf was man zeigt. Aber in der Praxis ist es wenig hilfreich, nur mit dem Finger wohin zu zeigen und "DA!" zu rufen. Damit man damit etwas anfangen kann, muß man auch dazusagen, was DA ist: "DA ist ein Löwe!" - Mit anderen Worten sieht es so aus, daß der "bit_vector" eine Art Halbfabrikat ist: Man muß immer dazusagen, was damit gemeint ist, also casten. Womit wir wieder beim Thema sind. Und das Herumnörgeln an der miesen Grafik https://www.bitweenie.com/wp-content/uploads/2013/02/vhdl-type-conversions.png sollten wir jetzt auch beenden. Was z.B. soll da ein "signed Bitvector" sein, wenn es keine Zahl sein darf? Ich schiebe die Schuld an solchen Verwirrstiftungen zur Hälfte auf die Trittbrett-Autoren, die mit wenig Mathekenntnissen eben auch ein Tutorial zu VHDL schreiben wollen und zur anderen Hälfte auf die Erfinder von VHDL, die offenbar eine Programmiersprache erfinden wollten, mit der man die gesamte Welt vom Urknall bis zum Jahre 1e38 behandeln kann und die damit nur einen Wust an Hakeligkeit erschaffen haben, den auch hundert schlechte Tutorials nicht beseitigen können. W.S.
W.S. schrieb: > Gustl B. schrieb: >> Wenn das mit zahlen durchnummeriert ist, dann kann man da in einer >> Schleife alle Elemente des Vectors durchgehen. > > Das ist aber nur der menschlichen Faulheit geschuldet. Lol aber genau da sind wir bei Umständlichkeit. Iteriere doch mal über ein Array dessen Indizes keine Zahlen sondern irgendwelche Wörter sind. W.S. schrieb: >> Aber weil Namen eben im Gegensatz zu ganzen Zahlen keinen eindeitigen >> Vorgängen und Nachfolger haben geht das nicht. Was ist der nächste Name >> nach otto? Ist das ida, emil oder gustl? > > Ähem, wenn Bits einen eindeutigen Vorgänger und Nachfolger haben, dann > ist damit auch ein Wertebereich abgesteckt. Nein, nicht die Bits, sondern die Indizes. Die Zahlen (7 downto 0) sind die Indizes der Elemente des Arrays. Und da hat der Index 0 ganz klar den Nachfolger 1. Man kann also die schön der Reihe nach durchlaufen. Bei (Otto, Emil, Karsten, Thorben) geht das nicht. Da kannst du nicht die 4 Indizes nacheinander durchlaufen weil die Indizes keine Reifenfolge haben. W.S. schrieb: > Wozu dann (0 to 7) ? eine einfache 8 hätte komplett ausgereicht. Wenn es > nur zum Abzählen ist, dann reicht ein Zählen von 0 beginnend immer aus. > Dann hat ein (15 downto 8) auch keine Daseinsberechtigung. Doch hat es. Man kann eben selbst bestimmen welcher Wertebereich für die Indizes verwendet wird. Und das ist bei der Adressierung interessant. signal a : std_logic_vector(7 downto 0); signal b : std_logic_vector(15 downto 8); signal c : std_logic; for i in 0 to 15 loop if i < 8 then c <= a(i); else c <= b(i); end if; end loop; W.S. schrieb: > Was z.B. soll da ein "signed Bitvector" > sein, wenn es keine Zahl sein darf? Doch, ein Signed ist eine Zahl. Und Unsigned auch. Aber eben auch gleichzeitig ein Array aus Bits die man adressieren kann. Ein std_logic_vector kann auch eine Zahl sein, muss aber nicht. Man kann ihn immer als Zahl interpretieren. Und zwar auf verschiedene Arten. "1000" kann man als Unsigned, Signed, Ufixed, Fixed, ... interpretieren. Aber eine Unsigned ist per Definition der Typ Unsigned. Da gibt es keinen Interpretationsspielraum, weil die schon so definiert wurde. Man kann sie aber umdefinieren. signal zahl : unsigned(3 downto 0) := "1010"; Das ist also ganz klar die Dezimalzahl 10. Wenn man das jetzt uminterpretieren will als Zahl mit Vorzeichen, dann gibt es zwei Möglichkeiten: 1. Die aktuelle Interpretation aufheben, also in ein Array an Bits umwandeln und dann neu interpretieren: signed(std_logic_vector(zahl)) 2. In eine Integer konvertieren und dann wieder zurückkonvertieren: to_signed(to_integer(zahl),4) Integer ist aber kein Array. Ja, auch das wird als eine Reihe an Bits gespeichert, aber wie die Bits angeordnet werden sieht man nicht. Man kann auch die einzelnen Bits nicht adressieren. signal zahl : integer range 0 to 15 := 0; Wird vermutlich in 4 Bits gespeichert. Aber ein zahl(3) um das MSB zu bekommen geht nicht. Dazu muss man die Integer in ein Arrayformat konvertieren. to_unsigned(zahl,4)(3) funktioniert.
W.S. schrieb: > Ich schiebe die Schuld an solchen Verwirrstiftungen zur Hälfte auf die > Trittbrett-Autoren, die mit wenig Mathekenntnissen eben auch ein > Tutorial zu VHDL schreiben wollen und zur anderen Hälfte auf die > Erfinder von VHDL, die offenbar eine Programmiersprache erfinden > wollten, mit der man die gesamte Welt vom Urknall bis zum Jahre 1e38 > behandeln kann und die damit nur einen Wust an Hakeligkeit erschaffen > haben, den auch hundert schlechte Tutorials nicht beseitigen können. > W.S. VHDL ist übrigens auch keine Programmiersprache. Allein das dürfte schon dafür sorgen, dass manche Konzepte dort Sinn ergeben, die bei Programmiersprachen keinen ergeben.
Eins N00B schrieb: > VHDL ist übrigens auch keine Programmiersprache. Diese Hybris seitens der FPGA-Leute kenne ich. Zumeist antworte ich auf solche Einlassungen, daß die derzeit meistverwendete Hardware-Beschreibungssprache das Englisch ist. Denn das wird derzeit wohl in den meisten Manuals zur Hardware (sprich Chips) geschrieben. VHDL ist hingegen eine Programmiersprache, ob das den betreffenden Leuten nun paßt oder nicht. Das Kennzeichen für Programmiersprachen ist, daß sie zu dem Zweck geschaffen wurden, daß jemand seine Vorstellungen über eine Funktionalität derart ausdrücken kann, daß dies maschinell weiterverarbeitbar ist, so daß am Ende ein funktionierendes "Ding" bei herauskommt. Ganz egal, ob das nun parallel arbeitet oder sequentiell. W.S.
Ich habe mir jetzt nochmals das erwähnte Diagramm angeschaut. Das Diagramm ist falsch und wahrscheinlich Teil des Problems. Die rechte Hälfte sind eben keine Bitvektoren. Bit ist die Kurzform von Binary Digit, also 2 unterschiedliche Werte. Ein Std-Logic, Grundelement von SLV, unsigned und signed hat aber neun Werte x, u, h, l, 0, 1, z, -, w und nicht alle Kombinationen lassen sich sinnvoll in eine Zahl umwandeln. Ein besseres ist https://www.doulos.com/media/1486/numeric_std_conversions.gif Std-logic kam übrigens erst später zu VHDL dazu und ist einfach ein Package mit einem Enum mit diesen 9 Werten und dazu passend überladenen Operatoren. In den Anfangstagen von VHDL gab es mehrere konkurrierende Packages für mehrwertige Logik, u.a. auch eines mit den 3 Werten 0, 1, z. Erst nachdem sich std-Logic durchgesetzt hatte wurde es zuerst eine offizielle Ergänzung zum VHDL-Standard und später Teil des Standards.
Gustl B. schrieb: > Doch, ein Signed ist eine Zahl. Eigentlich ist das mein Reden seit langem, aber wenn du dir dieses obskure Bild anschaust, dann gehören signed und unsigned zu den Bitvektoren (mit denen man nicht rechnen kann/darf) und nicht zu den Zahlen. Ansonsten gilt, daß Elemente eines "Dinges" dann quasi nebeneinander stehen, wenn sich deren Indizes um 1 unterscheiden. Gustl B. schrieb: > Und da hat der Index 0 ganz klar den Nachfolger 1. Nein, verwechsle mal nicht die Cookies mit der Schachtel, wo sie drin liegen sollen, bzw. die Häuser mit der drangeschriebenen Hausnummer. Es sind die indizierten Elemente selber, die den Nachfolger haben. Der Index bezeichnet nur das jeweilige Element selber. Gustl B. schrieb: > Doch hat es. Man kann eben selbst bestimmen welcher Wertebereich für die > Indizes verwendet wird. Und das ist bei der Adressierung interessant. Wieso soll das bei der Adressierung, also bei der Einzelverwendung eines Bits interessant sein? Rein praktisch sehe ich da durchaus einen Sinn, wenn man beim Schreiben mit Namen hantiert, die einen Bezug zum System haben wie A0 bis A7 oder MEMWR oder so. Aber vom Prinzip her kommt es bei den Bits eines Bitvektors nur drauf an, das gewünschte Bit eindeutig bezeichnen zu können. Alles weitere ist wohl nur der menschlichen Bequemlichkeit geschuldet, wie z.B. sowas wie "for (alles was ich meine)...", bei dem das eigentliche Ausrollen dem Übersetzungsprogramm überlassen wird. W.S.
W.S. schrieb: > VHDL ist hingegen eine Programmiersprache, ob das den > betreffenden Leuten nun paßt oder nicht. Du musst die Geschichte von VHDL bedenken. Beschreibungsprache ist hier im Sinne von Dokumentation gemeint. Allerdings so stark formalisiert das man diese Beschreibung auch simulieren kann im Sinne von „ausführbare Spezifikation“. Denn das amerikanische Militär hatte das Problem Hunderter elektronischer Systeme die auf ebenso vielen Weisen schlecht dokumentiert waren. Um das zu vereinheitlichen hat es VHDL entwickeln lassen, so wie Jahre zuvor ADA wegen vergleichbarer Probleme im Softwarebereich. Erst später kam dann die Idee dazu, wenn man schon so eine formale Spezifikation hat, kann man doch davon automatisch eine Hardware generieren lassen die diese Spezifikation erfüllt. Die Tatsache dass Synthese nicht von Anfang an berücksichtigt wurde ist auch der Grund warum es so viele Features gibt die sich nicht synthetisieren lassen und jeder Hersteller ein unterschiedliches Subset für die Synthese unterstützt.
Christoph Z. schrieb: > Und wo ist jetzt das LSB bzw. das MSB? > Leider bekommst du zwei Antworten, wenn du zwei Leute fragst die jeweils > für z.B IBM und z. B. Intel Arbeiten. lustig, ich war mal bei IBM. Bei den Grossrechnern war die Nomenklatura von 0..31 (also noch vor der 64-bit-Zeit in den 90ern), bei allen anderen (z.B. Intel, da war ich auch mal; aber bei IBM auch bei z.B. POWER) wars 31..0. War halt historisch so gewachsen... Und mal davon ab: Ein standard_logic_vector oder meinentwegen auch bit_vector hat doch mit Zahlen erstmal nix zu tun. Kann doch auch jedes Bit einfach ein "select" fuer einen bestimmten Adressbereich (aka Mux) sein...
vhdlerimruhestand schrieb: > Und mal davon ab: Ein standard_logic_vector oder meinentwegen auch > bit_vector hat doch mit Zahlen erstmal nix zu tun. Kann doch auch jedes > Bit einfach ein "select" fuer einen bestimmten Adressbereich (aka Mux) > sein... Oder einer der Klingeltöne, wenn der Osterhase vor der Tür steht. Man kann die 8 Bits eines Bytes zum Rechnen benutzen (hat schon vor vielen Jahren jeder Homecomputer vorgemacht) oder sie aus einem Statusregister lesen und dann bitweise verwenden. Kurzum: Du kommst zu spät. W.S.
W.S. schrieb: > Eins N00B schrieb: > >> VHDL ist übrigens auch keine Programmiersprache. > > Diese Hybris seitens der FPGA-Leute kenne ich. > Zumeist antworte ich auf solche Einlassungen, daß die derzeit > meistverwendete Hardware-Beschreibungssprache das Englisch ist. Denn das > wird derzeit wohl in den meisten Manuals zur Hardware (sprich Chips) > geschrieben. VHDL ist hingegen eine Programmiersprache, ob das den > betreffenden Leuten nun paßt oder nicht. Das Kennzeichen für > Programmiersprachen ist, daß sie zu dem Zweck geschaffen wurden, daß > jemand seine Vorstellungen über eine Funktionalität derart ausdrücken > kann, daß dies maschinell weiterverarbeitbar ist, so daß am Ende ein > funktionierendes "Ding" bei herauskommt. Ganz egal, ob das nun parallel > arbeitet oder sequentiell. > W.S. Was heißt „Hybris“? Man schreibt keine Programme in VHDL. Du weißt bestimmt, was ein Programm ist, in Hardwarebeschreibung verdrahtest du Digitaltechnik. Das ist schon ein ziemlicher Unterschied. Oder gehörst du zu den Menschen, die auch HTML Programmieren?
Blechbieger schrieb: > ist auch der Grund warum es so viele Features gibt die sich nicht > synthetisieren lassen und jeder Hersteller ein unterschiedliches Subset > für die Synthese unterstützt. Haben einige Features nicht auch ziemlich großen nutzen in Testbenches?
Blechbieger schrieb: > Beschreibungsprache ist hier > im Sinne von Dokumentation gemeint. Mag sein, daß die amerikanischen Armeeleute so etwas in ihrem Sinn gehabt haben. Aber etwas im Sinn haben und etwas gemacht zu haben, sind zwei unterschiedliche Dinge. Heutzutage hat es sich bei den FPGA-Leuten eingebürgert, zu ihrer Programmiersprache eben Hardware-Beschreibungs-Sprache zu sagen, weil es bombastischer klingt. Solche Effekte kann man überall beobachten: Da wird vom Schraubendreher geschwafelt anstelle das Wort Schraubenzieher zu verwenden, was seit Jahrhunderten in der deutschen Sprache üblich ist. Oder die sattsam bekannte Rechtschreibreform, nach der das Wort "wenden" von der Wand kommt und nicht vom Umdrehen und folglich mit ä geschrieben werden sollte. Oder das jetzt moderne Gendern. Oder die extreme Prüderie im 19. Jahrhundert, die solche Stilblüten wie "Beinkleid" hervorgebracht hatte, weil den Leuten das Wort "Hose" noch schlimmer vorkam als heutzutage "Neger". Apropos zum Schraubendreher: Das ist ein Metallwerker der mit einer entsprechenden Maschine (Drehbank) auf spanende Weise Schrauben anfertigt. Aber jetzt sind wir wohl endgültig vom Thema "cast" und "convert" abgekommen. W.S.
Eins N00B schrieb: > Man schreibt keine Programme in VHDL. Du vielleicht nicht, aber man kann das machen und es wird gemacht, VHDL ist turingvollständig. W.S. schrieb: > aber wenn du dir dieses > obskure Bild anschaust, dann gehören signed und unsigned zu den > Bitvektoren (mit denen man nicht rechnen kann/darf) und nicht zu den > Zahlen. Da gebe ich dir Recht! Diese Unterscheidung ist an dieser Stelle falsch. Integer ist nur eine Zahl. Ja, wird auch in Bits abgespeichert, aber die Bits sind nicht adressierbar. STD_LOGIC_VECTOR ist nur eine Anzahl an Bits, der man aber nicht ansieht welcher Zahlentyp das ist. Signed, Unsigned, UFixed, SFixed sind Zahlen und gleichzeitig auch Array aus Bits. Man kann die Elemente adressieren, aber es ist gleichzeitig auch bekannt wie diese Bits als Zahl zu interpretieren sind. W.S. schrieb: > Nein, verwechsle mal nicht die Cookies mit der Schachtel, wo sie drin > liegen sollen, bzw. die Häuser mit der drangeschriebenen Hausnummer. Es > sind die indizierten Elemente selber, die den Nachfolger haben. Der > Index bezeichnet nur das jeweilige Element selber. Nein, sehe ich anders. Bei einem Vector (7 downto 0) sind das 8 Elemente mit den Indizes aus dem Zahlenbereich [0 ... 7]. W.S. schrieb: > Aber vom Prinzip her kommt es bei den Bits eines > Bitvektors nur drauf an, das gewünschte Bit eindeutig bezeichnen zu > können. Exakt. Aber so eine Bezeichnung, oder Adressierung wird oft errechnet mit einer Funktion. Das geht mit Namen nicht. Stell dir vor du möchtest nur jedes 4te Bit adressieren. Dann kannst du for i in range 0 to 7 loop: b <= a(i*4); end loop; schreiben. ABer mit Namen geht das nicht, denn mit Namen kann man nicht rechnen. W.S. schrieb: > Alles weitere ist wohl nur der menschlichen Bequemlichkeit geschuldet, Ja natürlich. Wobei was heißt Bequemlichkeit? Man will das eben so effizient und einfach gestalten wie möglich. Und ich als Entwickler will da keine Eigennamen tippen müssen, das kostet Lebenszeit die ich lieber für andere Dinge ausgebe.
Ich muss echt mal Gustl für seine Geduld loben. Aber glaube der Kollege W.S. kann und will es nicht verstehen. Wenn er für sich die Definition eines Casts, einer Programmiersprache oder Schraubendrehers ändern möchte möge er das tun und seine Ansicht verdrehen. aber solle er sich nicht wundern, wenn er dafür belächelt wird. Die Erde ist flach. Gute Nacht.
Blechbieger schrieb: > Die Tatsache > dass Synthese nicht von Anfang an berücksichtigt wurde ist auch der > Grund warum es so viele Features gibt die sich nicht synthetisieren > lassen und jeder Hersteller ein unterschiedliches Subset für die > Synthese unterstützt. Nun, das ist ein bekanntes Problem, mit dem hier in diesem Forum schon viele Leute aufgekreuzt sind. Da bin ich komplett bei dir. Ich sehe allerdings keinen einfachen Weg, um das zu vermeiden, ohne daß man die gesamte Programmiersprache umstülpt, was wiederum die allermeisten Leute nicht wollen und auch nicht können. Insofern ist das etwas, mit dem man leben muß oder sich anderen Möglichkeiten zuwenden muß. Verilog zum Beispiel - aber da gibt es genauso viele Fallgruben. Die liegen bloß woanders. Vom Regen in die Traufe? Ja, so ähnlich. Ansonsten bin ich sehr skeptisch, wenn jemand eine eierlegende Wollmilchsau anpreist und immer dann ruft "du mußt dich bloß an meine Sau anpassen", wenn man mit eben dieser Sau an eine Stelle kommt, wo man nicht tun kann, was man tun muß um die Funktionalität zu kriegen, die man braucht. W.S.
Gustl B. schrieb: > Da gebe ich dir Recht! Diese Unterscheidung ist an dieser Stelle falsch. Da sind wir jetzt zwei, die den Stein des Anstoßes beim Namen nennen. Wenn sich jetzt Lothar bequemt, das endlich auch so zu sehen, dann wären wir drei. Mir ist es so langsam auch ziemlich fad, Unlogik in jedem Detail widerlegen zu müssen. Dieser Thread ist schon zu lang geworden. Ganz generell gesagt: VHDL ist meiner Ansicht nach für den FPGA-Programmierer zu weitläufig gefaßt, so daß es zuviel Zeugs gibt, was da vor allem stört, weil es entweder nicht synthesefähig ist oder bei gründlicher Betrachtung sich im Detail als unlogisch erweist. Mechaniker würden ein solches Detail "überbestimmt" nennen. Sowas neigt in jeder Form zum Klemmen. Wenn man VHDL täglich schreibt und schon genug Erfahrung durch Auf-Die-Nase-Fallen gesammelt hat, dann weiß man um die meisten Fallgruben und tanzt automatisch drum herum. Aber all die Leute, die nur mit den üblichen schlechten Tutorials auskommen müssen, tappen überall hinein. Fazit: es braucht gerade bei VHDL bessere Lehrbücher, denn diese Programmiersprache hat so etwas bitter nötig. W.S.
W.S. schrieb: > Fazit: es braucht gerade bei VHDL bessere Lehrbücher, denn diese > Programmiersprache hat so etwas bitter nötig. Wieviele Lehrbücher und welche hast Du schon gelesen? Mein Verdacht ist nämlich, daß es eigentlich keiner besseren Lehrbücher bedarf, sondern nur besserer Lehrbuchleser.
Gustl B. schrieb: > Eins N00B schrieb: > >> Man schreibt keine Programme in VHDL. > > Du vielleicht nicht, aber man kann das machen und es wird gemacht, VHDL > ist turingvollständig. Aber die Programme sind dann nicht synthetisierbar, oder? Testbenches könnten durchaus Programme sein, wenn ich so drüber nachdenke.
W.S. schrieb: > VHDL ist meiner Ansicht nach für den > FPGA-Programmierer zu weitläufig gefaßt, so daß es zuviel Zeugs gibt, > was da vor allem stört, weil es entweder nicht synthesefähig ist oder > bei gründlicher Betrachtung sich im Detail als unlogisch erweist. Nein, das Zeug kann man durchaus brauchen, nämlich für Testbenches. Und wenn du es nicht brauchst, dann nimm es nicht her. Eins N00B schrieb: > Aber die Programme sind dann nicht synthetisierbar, oder? > Testbenches könnten durchaus Programme sein, wenn ich so drüber > nachdenke. Was ist schon ein Programm? Ist ein Programm eine Art Binary das auf einer CPU/Automaten ausgeführt wird? Das kann man komplett in VHDL machen. Du baust ein Design, in das Design steckst du eine CPU und ebenfalls in das Design steckst du die Initialisierung für den Programmspeicher, also das Binary mit Maschinencode für die CPU. Das war vielleicht einmal eine Hochsprache wie C, ist aber zu dem Zeitpunkt schon ein Haufen an Bits die einen Speicherbereich im FPGA beschreiben. Und das kann man in VHDL machen. Dann hast du alles schön in VHDL gemacht und es ist ein Programm enthalten und das ist sogar synthetisierbar. Oder ist ein Programm schon ein Verhalten das komplexe Dinge tut? Auch das gibt es in VHDL. Leute haben in reinem VHDL schon Webserver geschrieben ganz ohne CPU. Oder muss ein Programm auf einer CPU in einem PC ohne FPGA laufen? Also in der Simulation oder direkt ohne Simulator? Das geht ebenfalls, mit VHDL kann man in der Simulation aus Dateien lesen, Daten verarbeiten und wieder schreiben. Ich finde die Unterscheidung nicht so einfach und am Ende ist das vielleicht auch egal. Wenn ein FPGA ein bestimmtes Verhalten zeigt, dann sieht man dem von außen nicht an ob da noch eine CPU mit Programm drinnen ist oder ob das alles ohne Programm in einer HDL geschrieben ist.
Gustl B. schrieb: > Eins N00B schrieb: >> Aber die Programme sind dann nicht synthetisierbar, oder? >> Testbenches könnten durchaus Programme sein, wenn ich so drüber >> nachdenke. > > Was ist schon ein Programm? > > Ist ein Programm eine Art Binary das auf einer CPU/Automaten ausgeführt > wird? > > Das kann man komplett in VHDL machen. Du baust ein Design, in das Design > steckst du eine CPU und ebenfalls in das Design steckst du die > Initialisierung für den Programmspeicher, also das Binary mit > Maschinencode für die CPU. Das war vielleicht einmal eine Hochsprache > wie C, ist aber zu dem Zeitpunkt schon ein Haufen an Bits die einen > Speicherbereich im FPGA beschreiben. Und das kann man in VHDL machen. > Dann hast du alles schön in VHDL gemacht und es ist ein Programm > enthalten und das ist sogar synthetisierbar. > > Oder ist ein Programm schon ein Verhalten das komplexe Dinge tut? > > Auch das gibt es in VHDL. Leute haben in reinem VHDL schon Webserver > geschrieben ganz ohne CPU. > > Oder muss ein Programm auf einer CPU in einem PC ohne FPGA laufen? Also > in der Simulation oder direkt ohne Simulator? > > Das geht ebenfalls, mit VHDL kann man in der Simulation aus Dateien > lesen, Daten verarbeiten und wieder schreiben. > > Ich finde die Unterscheidung nicht so einfach und am Ende ist das > vielleicht auch egal. Wenn ein FPGA ein bestimmtes Verhalten zeigt, dann > sieht man dem von außen nicht an ob da noch eine CPU mit Programm > drinnen ist oder ob das alles ohne Programm in einer HDL geschrieben > ist. Afaik ist ein Programm eine Abfolge von Anweisungen (kann erstmal auch ein Kochrezept sein). Ein Computerprogramm dann eines, welches von einem Computer ausgeführt werden kann, also meistens aus Maschinencode besteht (ob ich Skripte dazuzählen würde, müsste ich nochmal überdenken). Also ja, Abfolge von Anweisungen für einen Automaten trifft das ganz gut. Insofern ist eine in VHDL beschriebene Schaltung ja erstmal kein Programm. Diese Unterscheidung ist imo auch recht wichtig, damit man beim Lernen von Hardware-Beschreibungssprachen seine „Programmiererdenke“ hinter sich lässt. Wenn man VHDL nutzt, um ein Programm an die richtige Stelle im Speicher zu schieben, würde ich allerdings nicht davon sprechen, dass man das Programm in VHDL schreibt, oder wird C auch zur Hardware-Beschreibungssprache, weil ich die FPGA-Firmware mit einem Mikrocontroller aus Flash auf den FPGA schiebe? Dass das Programm in VHDL-Code enthalten ist, trifft es aber. Komplexes Verhalten erfordert keine Programme (oder arbeiten Menschen „nur“ Programme ab?). Die Verschaltung von Analogrechnern würde ich zB auch nicht als Programm bezeichnen. Rein theoretisch müsste man einen Webserver doch auch (unter der Vernachlässigung von Taktlimitationen) in diskreten Logikbausteinen aufbauen können, oder? Wäre das dann auch ein Programm? Da Testbenches ja auch eine Abfolge von Anweisungen sein können (zB um Signalverläufe zu beschreiben), erscheint es mir nur sinnvoll, dass die Sprache Programme (Testcases) enthalten kann. Trifft das dann auch auf processes zu? Du hast schon recht, so einfach ist das nicht :/ Die Frage, wie wichtig das Detail ist, ob das Verhalten eines Systems über Hardware-Beschreibung oder Programme beschrieben wird, würde ich abhängig von dem „Zoomlevel“ machen, mit dem man auf das System schaut. Wenn man sich gerade mit Details seiner Implementation herumschlägt, ist das mitunter ziemlich wichtig (insbesondere für Anfänger, wie mich), wenn man das System als Blackbox betrachtet, hingegen wieder nicht, sofern die Beschreibung ausreicht. Analog dazu, dass die Wahl der Programmiersprache, in der man ein Programm schreibt, auch ab einer bestimmten Systemebene nicht mehr relevant ist.
Eins N00B schrieb: > Gustl B. schrieb: > > Insofern ist eine in VHDL beschriebene Schaltung ja erstmal kein > Programm. Diese Unterscheidung ist imo auch recht wichtig, damit man > beim Lernen von Hardware-Beschreibungssprachen seine > „Programmiererdenke“ hinter sich lässt. > Nein, man laesst keine Programmierdenke hinter sich. Man programmiert genau so anders als in C wie mit Occam oder Haskell. Je nach Zielarchitektur (ASIC, FPGA, DoD-Simulation) programmiert man einfach relativ unterschiedlich und muss sich den Vorstellungen des Synthesetools/Simulationstools anpassen. Das ist leider, was VHDL im Rahmen der Designphase zur maroden alten Kuh macht. Und zum 100sten Mal: Ab dem Punkt, an dem if/else oder eine Schleife benutzt wird, ist es nach Gesichtspunkten der Akademie eine Programmiersprache, siehe Gustls Stichwort 'Turing', andere: 'Ada' (nicht ADA). Warum VHDL keine Beschreibungssprache (wie XML, o.ae.) ist, wurde hier schon oefters dargelegt hat. Wer das nicht verstanden hat, kann hier so oft gebetsmuehlenartig wiederholen "Mein Dozent/das Internet sagt..." wie er will: bei mir fliegt man damit durch. Schon in der Simulation laeuft ein Programm ab. Es laeuft einfach anders/ereignisgetrieben ab, anders als bei einem linearen Funktional-Konstrukt. Wer sich mit den Architekturen von Simulatoren beschaeftigen will, kann der OpenSource GHDL oder MyHDL (Python) in die Karten gucken. Dito mit Synthese (yosys-Plugins). Interessanterweise ist es gerade die Programmiersprache Python, die sich in Richtung einer selbstverifizierenden Beschreibungssprache biegen laesst (VHDL kann das nicht)
Strubi schrieb: > Eins N00B schrieb: >> Gustl B. schrieb: > >> >> Insofern ist eine in VHDL beschriebene Schaltung ja erstmal kein >> Programm. Diese Unterscheidung ist imo auch recht wichtig, damit man >> beim Lernen von Hardware-Beschreibungssprachen seine >> „Programmiererdenke“ hinter sich lässt. >> > > Nein, man laesst keine Programmierdenke hinter sich. Man programmiert > genau so anders als in C wie mit Occam oder Haskell. Je nach > Zielarchitektur (ASIC, FPGA, DoD-Simulation) programmiert man einfach > relativ unterschiedlich und muss sich den Vorstellungen des > Synthesetools/Simulationstools anpassen. > Das ist leider, was VHDL im Rahmen der Designphase zur maroden alten Kuh > macht. „Programmiere“ ich dann auch HTML einfach nur unterschiedlich? > Und zum 100sten Mal: Ab dem Punkt, an dem if/else oder eine Schleife > benutzt wird, ist es nach Gesichtspunkten der Akademie eine > Programmiersprache, siehe Gustls Stichwort 'Turing', andere: 'Ada' > (nicht ADA). Turing-Vollständigkeit ist mir als Kriterium für „Programmiersprache“ nicht bekannt. Ist Haskell dann weniger Programmiersprache, da man da ohne ifs und Schleifen auskommt? Und nach dem Kriterium „Turing-Vollständigkeit“, ist PowerPoint auch eine Programmiersprache, trotzdem würde ich es nicht so bezeichnen. (auch wenn es sich wohl als eine benutzen lässt). > Warum VHDL keine Beschreibungssprache (wie XML, o.ae.) ist, wurde hier > schon oefters dargelegt hat. Wer das nicht verstanden hat, kann hier so > oft gebetsmuehlenartig wiederholen "Mein Dozent/das Internet sagt..." > wie er will: bei mir fliegt man damit durch. Ist mir latte, ob man dich damit überzeugt. Wenn du Quellen oder Argumente nennst, die (für mich) nachvollziehbar und logisch schlüssig aufzeigen, dass VHDL keine Beschreibungssprache (und nicht nur keine reine Beschreibungssprache) ist, lasse ich mich da gerne überzeugen. > Schon in der Simulation laeuft ein Programm ab. Es laeuft einfach > anders/ereignisgetrieben ab, anders als bei einem linearen > Funktional-Konstrukt. Wer sich mit den Architekturen von Simulatoren > beschaeftigen will, kann der OpenSource GHDL oder MyHDL (Python) in die > Karten gucken. Dito mit Synthese (yosys-Plugins). In der Simulation läuft natürlich ein Programm, wie möchte man sonst auf einem Prozessor etwas simulieren? Wenn du ein (mechanisches oder elektrisches) System mit einem Satz an Differentialgleichungen beschreibst und diese auf einem Computer simulierst, sind die Differentialgleichungen dann auch Programme? > Interessanterweise ist es gerade die Programmiersprache Python, die sich > in Richtung einer selbstverifizierenden Beschreibungssprache biegen > laesst (VHDL kann das nicht) Möchtest du auf MyHDL hinaus? Da habe ich mich noch nicht mit beschäftigt.
Eins N00B schrieb: > Wenn du ein (mechanisches oder elektrisches) System mit einem Satz an > Differentialgleichungen beschreibst und diese auf einem Computer > simulierst, sind die Differentialgleichungen dann auch Programme? Wenn Du ein (mechanisches oder elektrisches) System mit einem Bündel Drähte auf einem Analogrechner zusammenstöpselst, sind die Drähte dann auch Programme? Immer wenn W.S. in einem Thread auftaucht, geht das Getrolle auf hohem Niveau los. Leider.
Eins N00B schrieb: > > „Programmiere“ ich dann auch HTML einfach nur unterschiedlich? > Nein. HTML ist ganz klar keine Programmiersprache, da die primaeren semantischen Elemente Tags sind. > Turing-Vollständigkeit ist mir als Kriterium für „Programmiersprache“ > nicht bekannt. Ist Haskell dann weniger Programmiersprache, da man da > ohne ifs und Schleifen auskommt? > Auch streng funktionale Programmierung faellt unter Programmierung. In kurz: Turing > Funktional > Programmiersprache. Bitte Hausaufgaben machen, wildes Herumgestocher in Spitzfindigkeiten hilft nicht weiter. > Ist mir latte, ob man dich damit überzeugt. Wenn du Quellen oder > Argumente nennst, die (für mich) nachvollziehbar und logisch schlüssig > aufzeigen, dass VHDL keine Beschreibungssprache (und nicht nur keine > reine Beschreibungssprache) ist, lasse ich mich da gerne überzeugen. > Ich grabe nicht die alten Threads aus. Guck Dir den Pfad von Ada zu VHDL an, lies dich zum Thema Semantik von Programmiersprachen ein, und es wird klar. Die 'Nachweispflicht' liegt grundsaetzlich bei dem, der schreit "Beschreibungssprache". Das fossilierte 'D' in VHDL reicht leider nicht. > >> Interessanterweise ist es gerade die Programmiersprache Python, die sich >> in Richtung einer selbstverifizierenden Beschreibungssprache biegen >> laesst (VHDL kann das nicht) > > Möchtest du auf MyHDL hinaus? Da habe ich mich noch nicht mit > beschäftigt. Nein, das MyHDL 'kernel' kann das nicht, amaranth und myhdl.v2we schon eher.
Duke Scarring schrieb: > Eins N00B schrieb: >> Wenn du ein (mechanisches oder elektrisches) System mit einem Satz an >> Differentialgleichungen beschreibst und diese auf einem Computer >> simulierst, sind die Differentialgleichungen dann auch Programme? > Wenn Du ein (mechanisches oder elektrisches) System mit einem Bündel > Drähte auf einem Analogrechner zusammenstöpselst, sind die Drähte dann > auch Programme? Nein und genau das ist mein eigentlicher Punkt. Strubi schrieb: > Eins N00B schrieb: >> >> „Programmiere“ ich dann auch HTML einfach nur unterschiedlich? >> > > Nein. HTML ist ganz klar keine Programmiersprache, da die primaeren > semantischen Elemente Tags sind. Was ist eine Programmiersprache dann? Und kennst du XSLT? >> Turing-Vollständigkeit ist mir als Kriterium für „Programmiersprache“ >> nicht bekannt. Ist Haskell dann weniger Programmiersprache, da man da >> ohne ifs und Schleifen auskommt? >> > > Auch streng funktionale Programmierung faellt unter Programmierung. > In kurz: Turing > Funktional > Programmiersprache. > Bitte Hausaufgaben machen, wildes Herumgestocher in Spitzfindigkeiten > hilft nicht weiter. > >> Ist mir latte, ob man dich damit überzeugt. Wenn du Quellen oder >> Argumente nennst, die (für mich) nachvollziehbar und logisch schlüssig >> aufzeigen, dass VHDL keine Beschreibungssprache (und nicht nur keine >> reine Beschreibungssprache) ist, lasse ich mich da gerne überzeugen. >> > > Ich grabe nicht die alten Threads aus. Guck Dir den Pfad von Ada zu VHDL > an, lies dich zum Thema Semantik von Programmiersprachen ein, und es > wird klar. Die 'Nachweispflicht' liegt grundsaetzlich bei dem, der > schreit "Beschreibungssprache". Das fossilierte 'D' in VHDL reicht > leider nicht. Wow. VHDL-Syntax ist von Ada inspiriert. Macht das CSS auch zu einer Programmiersprache, weil die Syntax C ähnelt? Warum sollte die Nachweispflicht grundsätzlich bei mir liegen? Ich habe oben mein Argument dargelegt, Wiki und die Quellen, die ich so kenne, stimmen mir zu. „Google doch“ ist kein Argument. Du nennst ja selbst Quellen, die dir nicht zustimmen, ohne selbst Argumente zu nennen. Naja, wenn du dich nicht nachvollziehbar ausdrücken möchtest, dann halt nicht 🤷♂️ >> >>> Interessanterweise ist es gerade die Programmiersprache Python, die sich >>> in Richtung einer selbstverifizierenden Beschreibungssprache biegen >>> laesst (VHDL kann das nicht) >> >> Möchtest du auf MyHDL hinaus? Da habe ich mich noch nicht mit >> beschäftigt. > > Nein, das MyHDL 'kernel' kann das nicht, amaranth und myhdl.v2we schon > eher. Na gut, da bin ich wirklich raus.
Hier braucht man echt nochmal Geduld.. > Was ist eine Programmiersprache dann? Und kennst du XSLT? XSLT ist auch keine Programmiersprache, sondern a priori XML - Also Beschreibungssprache. Wie gesagt, schon wenn ein 'for x in range(u)' oder aehnlich in dieser Semantik vorliegt und eine sequentielle Abfolge oder bedingter Fluss (if..else) moeglich ist, gilt eine Sprache nach Gesichtspunkten der Informatik als Programmiersprache. Viel mehr gibt es dazu nicht zu sagen. Auch wenn man umgekehrt in XML ein `<for i="2">...</for>` ausdruecken kann, macht es das nicht zu einer PS (Wikipedia: 'Programmiersprache'). Bei einer vollstaendigen Beschreibungssprache definiert man nativ (in der eigenen Sprache) die Regeln fuer eine Transpilierung in ein Zielformat, usw. - genau das was VHDL nicht kann, aber XML (mit sub-Dialekten XSLT, XSD, ...) schon. So am Rande: man kann aus VHDL auch nach Design-Regeln synthetisierbares XML machen (via GHDL). Da merkt man dann nur mal, wie unsinnig komplex VHDL sein kann, und warum kaum ein Toolhersteller noch gross Lust hat, neue VHDL Standards in m*n Varianten zu implementieren.
Eins N00B schrieb: > Duke Scarring schrieb: >> Eins N00B schrieb: >>> Wenn du ein (mechanisches oder elektrisches) System mit einem Satz an >>> Differentialgleichungen beschreibst und diese auf einem Computer >>> simulierst, sind die Differentialgleichungen dann auch Programme? >> Wenn Du ein (mechanisches oder elektrisches) System mit einem Bündel >> Drähte auf einem Analogrechner zusammenstöpselst, sind die Drähte dann >> auch Programme? > > Nein und genau das ist mein eigentlicher Punkt. Ob ich nun einen EPROM neu beschreibe, oder die Kabel neu stecke: Ich kann die Funktion des Rechners im Nachhinein ändern. Das wäre für mich eine mögliche Definition von 'programmieren'. Ich sehe das pragmatisch: Ich kann eine bestimmte Funktion (Wurzel ziehen, tiefpassfiltern, FFT) als diskrete (unveränderliche) Hardware bauen. Die ist dann nicht programmierbar. Ich kann das im FPGA realisieren. Dort ist es konfigurierbar. Oder ich bemühe eine CPU dafür, dann ist es wirklich programmierbar. Die Maschine hier kannst Du mit einem Hammer programmieren: https://www.youtube.com/watch?v=9sUsiYnHwqI Hier ist eingangs der zugehörige Programmspeicher zu sehen: https://www.youtube.com/watch?v=UonuYrruap4 Letztendlich muß ich ein irgendwie geartetes Problem lösen und nutze dafür die geeigneten Werkzeuge. Die Ansicht, was jeweils geeignet ist, variiert erfahrungsgemäß stark. Duke
Eins N00B schrieb: >>> >>>> Interessanterweise ist es gerade die Programmiersprache Python, die sich >>>> in Richtung einer selbstverifizierenden Beschreibungssprache biegen >>>> laesst (VHDL kann das nicht) >>> Was genau hast du da im Auge, was sich in VHDL nicht machen lässt?
Duke Scarring schrieb: > Ob ich nun einen EPROM neu beschreibe, oder die Kabel neu stecke: Ich > kann die Funktion des Rechners im Nachhinein ändern. Das wäre für mich > eine mögliche Definition von 'programmieren'. Hier ein interessantes Paper, in dem es darum geht, ob jetzt Colossus programmierbar oder eben nur konfigurier bar war: https://www.tomandmaria.com/Tom/Writing/ColossusProgrammabilityWeb.pdf Hab jetzt schon mehrere Paper von Tom gelesen (z. B. über das erste Programm von Hr. Neumann...), immer was interessantes zum Mitnehmen dabei.
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.