Forum: FPGA, VHDL & Co. Unterschied zwischen cast und convert bei VHDL Datentypen?


von Bliad B. (bliad_b)


Lesenswert?

Was wird denn bei "cast" und "convert" von VHDL Datentypen anders 
gemacht?
Danke :D

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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).

von Markus F. (mfro)


Lesenswert?

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".

von M. Н. (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Christoph Z. (christophz)


Lesenswert?

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 :-)

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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
von Markus F. (mfro)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Markus F. (mfro)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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
von Markus F. (mfro)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Gustl B. (-gb-)


Lesenswert?

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.

von vhdlerimruhestand (Gast)


Lesenswert?

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!

von Christoph Z. (christophz)


Lesenswert?

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;

von W.S. (Gast)


Lesenswert?

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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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
von W.S. (Gast)


Lesenswert?

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.

von Markus F. (mfro)


Lesenswert?

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.

von Gustl B. (-gb-)


Lesenswert?

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
von W.S. (Gast)


Lesenswert?

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.

von Gustl B. (-gb-)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Gustl B. (-gb-)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Gustl B. (-gb-)


Lesenswert?

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
von Blechbieger (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Gustl B. (-gb-)


Lesenswert?

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.

von Eins N00B (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Blechbieger (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Blechbieger (Gast)


Lesenswert?

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.

von vhdlerimruhestand (Gast)


Lesenswert?

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...

von W.S. (Gast)


Lesenswert?

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.

von Eins N00B (Gast)


Lesenswert?

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?

von Eins N00B (Gast)


Lesenswert?

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?

von W.S. (Gast)


Lesenswert?

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.

von Gustl B. (-gb-)


Lesenswert?

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.

von raX (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Markus F. (mfro)


Lesenswert?

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.

von Eins N00B (Gast)


Lesenswert?

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.

von Gustl B. (-gb-)


Lesenswert?

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.

von Eins N00B (Gast)


Lesenswert?

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.

von Strubi (Gast)


Lesenswert?

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)

von Eins N00B (Gast)


Lesenswert?

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.

von Duke Scarring (Gast)


Lesenswert?

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.

von Strubi (Gast)


Lesenswert?

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.

von Eins N00B (Gast)


Lesenswert?

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.

von Strubi (Gast)


Lesenswert?

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.

von Duke Scarring (Gast)


Lesenswert?

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

von Messtechniker (Gast)


Lesenswert?

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?

von Christoph Z. (christophz)


Lesenswert?

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
Noch kein Account? Hier anmelden.