Einfacher VHDL Zähler

[Name (Gast)]

Hallo,
gibt es nach der Synthese (also auf dem FPGA) ein Unterschied zwischen

process(CLK)
BEGIN

A<=A+1;
IF(A=10)THEN
A<=0
END IF;
END PROCESS

und

PROCESS (CLK)
IF(A<10)THEN
A<=A+1;
ELSE
A<=0;
END IF
END PROCESS

In der Simulation läuft der 1. Counter nur einmal bis 10 und bleibt 
stehen, der 2. läuft ohne Probleme.

[Klaus F. (kfalser)]

Erst einmal ist das Beispiel schon grundfalsch, weil die Zeile

 
if rising_edge(clk) then

fehlt.
Ein Zähler in einem FPGA zählt nämlich nur an der steigenden/fallenden 
Flanke.
Die Beispiele müßten also

process(CLK)
BEGIN
   if rising_edge(clk) then
      A<=A+1;
      IF(A=10)THEN
         A<=0
      END IF;
   end if;
END PROCESS

ausschauen.

Zu deiner Frage :
Zwischen der 1. Variante und der 2. ist ein Riesenunterschied, weil die 
1. Variante von 0 bis 10 zählt und weiter und der 2. von 0 bis 9 und 
weiter.

Falls Du

signal A : integer range 0 to 10;

definiert hast, dann bricht der Simulator bei
A <= A + 1 mit einem Fehler ab weil A den Wert 11 annehmen kann.
Das hängt damit zusammen, dass VHDL den Wert eines Signals erst am Ende 
aktualisiert.

A <= A + 1;          -- A von 9 auf 10 
if A = 10 then       -- A ist noch 9, deshalb Bedingung noch falsch 
                     -- Der Zähler läuft noch eine Runde

A <= A + 1;          -- A von 10 auf 11 --> Fehler, Simulator bricht ab
if A = 10 then       -- A ist 10, diesmal wäre die Bedingung erfüllt, 
                     --   aber der Punkt wird nicht erreicht, da 
                     --   Simulation abgebrochen.

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

Klaus Falser schrieb:
> Erst einmal ist das Beispiel schon grundfalsch, weil ...
... jede VHDL Beschreibung mit den verwendeten Bibliotheken begint. 
Immer. Zwingend.

Name schrieb:
> In der Simulation läuft der 1. Counter nur einmal bis 10 und bleibt
> stehen, der 2. läuft ohne Probleme.
Jaja, in der Simulation schon. Aber in der Realität wird dich der 
Synthesozer darauf hinweisen, dass das Signal A in der Sensitivliste 
fehlt, und CLK zu viel ist. Und dann wird er eine Warnung ausgeben, weil 
er eine kombinatorische Schleife gemacht hat:
http://www.lothar-miller.de/s9y/archives/42-Kombinatorische-Schleifen.html

Sieh dir einfach mal an, wie jeder Andere einen Zähler beschreibt. Und 
dann denk darüber nach, warum alle Anderen das genau so machen...
http://www.lothar-miller.de/s9y/archives/80-Hello-World!.html

Und dann merke dir: man kann 100% des VHDL-Befehlumfangs für die 
Simulation verwenden. Aber bestenfalls 5% für reale Hardware in einem 
FPGA.

Und zum Thema Zähler (Klaus Falser hat schon was dazu geschrieben): mach 
dir unbedingt klar, wie scih Signale in Prozessen verhalten. Die haben 
nämlich eine sehr angenehme Eigenschaft: der Wert eines Signals ändert 
sich während des ganzen Prozesses nicht! Erst am Ende des Prozesses 
erhält das Signal den Wert, der ihm zuletzt zugewiesen wurde. Tolle 
Sache...

[W.S. (Gast)]

Lothar Miller schrieb:
> Immer. Zwingend.

Und?
Und was steht dort drin?
Gibt es irgendwelche Header-Dateien, die den Inhalt besagter 
Bibliotheken lesbar beschreiben?
Kann man das irgendwo nachlesen?
Und wenn, wo genau?
Und auf welche Ausdrücke in dieser Programmiersprache muß man 
verzichten, wenn man auf diese ominösen Bibliotheken verzichtet?

Ich sag's mal so: Eine Bibliothek zu einer Programmiersprache wird 
entweder völlig implizit vom Compiler verwendet, wei dieser einen in der 
Sprachdefinition enthalteten Ausdruck eben NUR mittels einer 
Bibliotheksroutine in's Zielsystem übersetzen kann - oder es ist eine 
Bibliothek, die in eben derselben Sprache geschrieben wurde und 
lediglich Hilfsfunktionen enthält, die man sich prinzipiell auch selber 
in seine Quelle schreiben könnte.

Im ersteren Falle wäre NICHT die Angabe einer Bibliothek, sondern die 
Angabe des Zielsystems erforderlich (z.B. "use Spartan3A-TQ144" oder so) 
und im zweiten Falle muß es ZWINGEND eine Art Header-Datei geben, um die 
Bibliotheksinhalte im aktuellen Programm bekanntzugeben. Und wenn man 
diese nicht benötigt (wie z.B. bei einem simplen Zähler), dann kann man 
die ganze Bibliothek getrost weglassen.

Also was ist nun damit und warum, Verehrtester?

Ich verstehe schon, daß man sich als Guru seines Faches in der 
Unbedarftheit der Anderen sonnen kann, sowas ist menschlich.

Aber für den Rest der Welt wäre es hilfreicher, wirklich SINNVOLLE 
Vorlagen zu veröffentlichen als sich darüber auszulassen, "wie jeder 
Andere einen Zähler beschreibt". Ich z.B. benutze dafür Verilog. Und 
wenn ich mich an das längst verschollene ABEL zurückzuerinnern versuche, 
dann ging das dort sinngemäß etwa so:
  Zaehler:= (Zaehler+1) & (Zaehler<10);
Deine Bemerkung über "wie jeder Andere einen Zähler beschreibt" bedarf 
also einer dezenten Relativierung, mein Lieber.

Gerade VHDL ist von solch beknackter Formalität, daß es einen graust - 
ich entsinne mich, in einem Draft zum Standard ne Bemerkung über 
generelle statische Parameter o.ä. gelesen zu haben, wo stand daß man 
dort hinschreiben könne, was einem beliebt. Klasse sowas!

Fazit: Besser ist es allemal, ein richtig funktionierendes Beispiel zu 
liefern, wenn man sich als Fach-Guru selbst versteht.

W.S.

[bko (Gast)]

@W.S:
Langer Rede kurzer Sinn: Du magst VHDL nicht, schreibst aber auch kein
hilfreiches Beispiel dazu. Lkmillers Beispiel-VHDL hingegen 
funktioniert.

W.S. schrieb:
(...)
> Fazit: Besser ist es allemal, ein richtig funktionierendes Beispiel zu
> liefern, wenn man sich als Fach-Guru selbst versteht.
>
> W.S.

[Klaus F. (kfalser)]

@W.S:
Oi, oi, oi, da ist heute aber einer ein bischen schlecht gelaunt.

Ich denke zwar auch, dass Lothar da ein wenig zu streng war, weil

library ieee;
use ieee.std_logic_1164.all;

in den Code-Schnipseln hier fast nie geschrieben wird, aber Deine 
Schimpfereien hat er doch nicht verdient.

Die Bibliotheken, bzw. den Quelltext dazu, kann man übrigens leicht 
finden, Google genügt.
Verzichten muss man dann halt auf die in der Bibliothek definierten 
Typen, im Beispiel oben wären das dann std_logic und std_ulogic.
Im Prinzip kann man trotzdem ein VHDL Programm schreiben, aber es ist 
unpraktisch.
Wie Loriot so schön sagte:
"Ein Leben ohne Möpse ist möglich, aber sinnlos"

[Peter X. (peter_x)]

Wenn man des gockelns mächtig ist, stößt man u.a. auf folgende Site:

http://dl1dsn.de/projects/counter/counter.htm

Da kann denn der letzte nachvollziehen, wie man counter in VHDL 
formuliert.

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

W.S. schrieb:
> Lothar Miller schrieb:
>> Immer. Zwingend.
> Und?
> Und was steht dort drin?
Für solch grundlegende Fragen empfiehlt sich der Kauf eines Buches zum 
Thema.

> Gibt es irgendwelche Header-Dateien, die den Inhalt besagter
> Bibliotheken lesbar beschreiben? Kann man das irgendwo nachlesen?
Ja, klar: man kann sich einfach direkt den Quellcode der besagten 
Bibliotheken/Packages ansehen. Dort steht das drin:
http://www.csee.umbc.edu/portal/help/VHDL/numeric_std.vhdl
http://www.csee.umbc.edu/portal/help/VHDL/std_logic_arith.vhdl
http://www.csee.umbc.edu/portal/help/VHDL/std_logic_unsigned.vhdl
http://www.csee.umbc.edu/portal/help/VHDL/std_logic_signed.vhdl

> Und auf welche Ausdrücke in dieser Programmiersprache muß man
> verzichten, wenn man auf diese ominösen Bibliotheken verzichtet?
Auf fast alle. Denn schon der allseits verwendete std_logic ist kein 
generischer VHDL-Datentyp:
http://www.csee.umbc.edu/portal/help/VHDL/std_logic_1164.vhdl

> Fazit: Besser ist es allemal, ein richtig funktionierendes Beispiel zu
> liefern, wenn man sich als Fach-Guru selbst versteht.
Ich hatte doch das "Hello-World!" verlinkt. Da ist das gewünschte 
Beispiel nach einem einzigen Klick erreicht. Sogar incl. Erklärung, 
warum es genau so gemacht wird. Aber, falls es jemand noch nicht 
gesehen hat, hier nochmal:
http://www.lothar-miller.de/s9y/archives/80-Hello-World!.html

Peter Xuang schrieb:
> Da kann denn der letzte nachvollziehen, wie man counter in VHDL
> formuliert.
Zu den dort verwendeten Bibliotheken ieee.std_logic_unsigned.all und 
ieee.std_logic_arith.all empfehle ich den 
Beitrag "IEEE.STD_LOGIC_ARITH.ALL obsolete" und die Suche 
http://www.mikrocontroller.net/search?query=std_logic_arith+obsolete

Und zur numeric_std das hier:
http://www.lothar-miller.de/s9y/categories/16-Numeric_Std

Klaus Falser schrieb:
> Die Bibliotheken, bzw. den Quelltext dazu, kann man übrigens leicht
> finden, Google genügt
Allemal einen Bookmark wert:
http://www.csee.umbc.edu/portal/help/VHDL/stdpkg.html

[Markus F. (mfro)]

Lothar Miller schrieb:
> Auf fast alle. Denn schon der allseits verwendete std_logic ist kein
> generischer VHDL-Datentyp:

Die Gelegenheit, eine Frage zu stellen, die mir schon lang auf der Zunge 
liegt:

warum zum Teufel (und wenn ja, wann?) sollte ich überhaupt einen 
STD_LOGIC_VECTOR verwenden?

Als ich mit VHDL angefangen habe, habe ich ihn verwendet, weil er in 
allen möglichen Beispielen drinstand.

Mich dann - wie die meisten wahrscheinlich - mit Typkonvertierungen 
vorwärts und rückwärts rumgeschlagen (dabei den ein oder anderen Fluch 
losgelassen) und irgendwann erstaunt festgestellt: überall dort, wo ein 
STD_LOGIC_VECTOR stehen kann, tut's auch ein UNSIGNED-Vektor. Deutlich 
weniger nervig.

Und mit dem kann man tatsächlich "richtig" umgehen. Probleme mit 
Konstantenzuweisungen, Vergleichen und einfacher Arithmetik sind 
plötzlich keine mehr.

Wo brauche ich eigentlich einen STD_LOGIC_VECTOR, wo's ein 
UNSIGNED-Vektor nicht genauso täte?

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

Markus F. schrieb:
> Wo brauche ich eigentlich einen STD_LOGIC_VECTOR, wo's ein
> UNSIGNED-Vektor nicht genauso täte?
Der std_logic ist der Standard-Übergabetyp. Man findet ihn mindestens 
im Port der Top-Level Entity und natürlich auch im Design bei einzelnen 
Signalen...

Auch ich caste einen std_logic_vector schnellstmöglich in etwas 
Handhabbares (Signed oder Unsigned Vektor oder gleich einen Integer). 
Innerhalb eines Designs kannst du die Ports dann natürlich auch mit 
komplexen oder eigenen Datentypen gestalten.

[Markus F. (mfro)]

Lothar Miller schrieb:
> Man findet ihn mindestens
> im Port der Top-Level Entity

aber auch dort kann ich doch ohne erkennbare (zumindest für mich) 
Nachteile genauso gut einen UNSIGNED-Vektor hinschreiben?

[Klaus F. (kfalser)]

Markus F. schrieb:
> Lothar Miller schrieb:
>> Man findet ihn mindestens
>> im Port der Top-Level Entity
>
> aber auch dort kann ich doch ohne erkennbare (zumindest für mich)
> Nachteile genauso gut einen UNSIGNED-Vektor hinschreiben?

Das sind eigentlich 2 verschiedene Dinge:
- Std_logicv_vector ist für die Darstellung eines Bündels von 
elektrischen Signalleitungen.
- Mit Unsigned/Signed weisst Du diesen Signalleitungen zusätzlich eine 
Bedeutung zu, d.h. sie stehen für eine binäre Zahl mit den 
entsprechenden Wertigkeiten.
Aber nicht jedes Bündel von Signalleitungen ist eine binäre Zahl, z.B. 
das Statusregister eines Prozessors.

[Markus F. (mfro)]

Klaus Falser schrieb:
> Aber nicht jedes Bündel von Signalleitungen ist eine binäre Zahl, z.B.
> das Statusregister eines Prozessors.

natürlich nicht.

Aber es würde  m.E. gerade Anfängern sehr helfen, wenn ihnen einer 
verraten würde, daß STD_LOGIC_VECTOR ein reichlich unhandlicher Datentyp 
ist, den man eigentlich gar nicht braucht und nur verwenden sollte, wenn 
man explizit vorhat, ihn nicht als binäre Zahl aufzufassen?

[Lattice User (Gast)]

VHDL 2008:

ieee.numeric_std_unsigned

[W.S. (Gast)]

Markus F. schrieb:
> warum zum Teufel (und wenn ja, wann?) sollte ich überhaupt einen
> STD_LOGIC_VECTOR verwenden?
>
> Als ich mit VHDL angefangen habe, habe ich ihn verwendet, weil er in
> allen möglichen Beispielen drinstand.

JAHAHAHA!!!!!

Genau dieses Thema hatten wir vor kurzem, bis die Fetzen flogen. Ich 
hatte Lothar damals schon drauf hingewiesen, daß die gesamte 
Anfänger-Literatur sowohl im Netz als auch an unseren hiesigen Fach- und 
Hochschulen in exakt DIESEM Punkt ausgesprochen lausig ist.

Jeder dieser Nachaffen, der sich zu einem Tutorial für VHDL berufen 
gefühlt hat, hat von seinem Vorgänger abgekupfert und so ekelt sich der 
STD_LOGIC_VECTOR von einem Tutorial zum nächsten - und die elendiglichen 
Folgen davon (daß man beim Versuch, damit zu rechnen) sind, daß man 
zuerst auf die Nase fällt und dann mit weiteren Tutorials über das 
möglichst komplizierte Konvertieren bedacht wird.

Alles NICHT hilfreich, alles NICHT zielführend. Und die zugehörigen 
Standards sind ebenfalls NICHT lehrreich. Natürlich kann man das besser 
- aber eben nur, wenn man es bereits kann. Oder wenn man - wie in dem 
Witz über's Gehen über den See Genezareth (den ich mir hier aber mal 
verkneife) - weiß wo die Trittsteine im Wasser liegen. Vom Lesen der 
Standards oder der lausigen Tutorials oder der ebenso lausigen 
Beispielquellen findet man die Trittsteine nicht und ersäuft.. oder 
schwenkt zu Verilog um, was auf andere Art eklig ist.. oder verwendet 
gar Schematics, was in diesem Forum zum einhelligen Aufkreischen führt.

Lothar Miller schrieb:
>> Und auf welche Ausdrücke in dieser Programmiersprache muß man
>> verzichten, wenn man auf diese ominösen Bibliotheken verzichtet?
> Auf fast alle.

Das heißt im Umkehrschluß, daß VHDL eine fast völlig ausdruckslose 
Programmiersprache ist, die nur dadurch benutzbar wird, daß man 
Bibliotheken mit Routinen einbindet - aber wie sind dort die Dinge 
ausgedrückt, die zwar nötig, aber in der Sprache per se nicht vorhanden 
sind?

Lothar, du merkst wohl an dieser Stelle, daß dein Versuch einer 
logischen Erklärung in einen circulus vitiosus mündet, nach dem Schema 
"wenn der Topf aber nun ein Loch hat". Ich hab in meinem esten Beitrag 
schon auf diesem Punkt herumgehackt und deine Antwort war unzureichend.

Wahrscheinliche wäre es wesentlich zielführender, zu sagen:
"Leute, schreibt den Sermon
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
use ... usw.
einfach hin, macht euch keine weiteren Gedanken drüber und sucht nicht 
nach einer rationalen Erklärung, denn die gibt es nicht. Allenfalls kann 
man vermuten, daß es sich die Erfinder von VHDL eben so ausgedacht 
haben, daß man das tun muß - vermutlich aus dem Beweggrunde, daß diese 
Programmiersprache damit eventuell noch viel universeller sein könnte, 
als man es zum Redaktionsschluß sich hat vorstellen können."
Amen.

Aber all den Abertausenden, die VHDL erlernen wollen und in ihren 
Projekten eben auch rechnen wollen oder müssen, ist damit noch lange 
nicht gedient. Die werden nach wie vor mittels des STD_LOGIC_VECTOR's in 
die Prärie geschickt.

Ach was, trotzdem frohe Weihnachten.

W.S.

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

W.S. schrieb:
> Lothar, du merkst wohl an dieser Stelle, daß dein Versuch einer
> logischen Erklärung in einen circulus vitiosus mündet
Ich muss gestehen: das ist mir egal. Ich bekomme mein Zeug mit VHDL 
beschreiben, du bekommst dein Zeug mit Verilog beschrieben und jeder ist 
glücklich.

> Ich hab in meinem esten Beitrag schon auf diesem Punkt herumgehackt und
> deine Antwort war unzureichend.
Es ist nicht mein Anspruch, VHDL zu verteidigen oder zu verbessern. Ich 
arbeite einfach damit. Und ich bin froh, dass es dort eben keine 
impliziten Annahmen und Konvertierungen wie bei Verilog (oder C) gibt, 
sondern dass jeder kleine Furz im VHDL-File selbst ausgedrückt werden 
muss.

W.S. schrieb:
> Gerade VHDL ist von solch beknackter Formalität, daß es einen graust
Man muss nicht jede beknackte Formalität auch verwenden. Ich verweise 
einfach dorthin: 
http://www.lothar-miller.de/s9y/archives/88-VHDL-vs.-Verilog-am-Beispiel-einer-Stoppuhr.html
Da ist dann ein Link, der zur passenden Diskussion hier zurückführt... 
;-)

> Ach was, trotzdem frohe Weihnachten.
Dito.

[berndl (Gast)]

W.S. schrieb:
> Markus F. schrieb:
>> warum zum Teufel (und wenn ja, wann?) sollte ich überhaupt einen
>> STD_LOGIC_VECTOR verwenden?
>>
>> Als ich mit VHDL angefangen habe, habe ich ihn verwendet, weil er in
>> allen möglichen Beispielen drinstand.
>
> JAHAHAHA!!!!!
>
> Genau dieses Thema hatten wir vor kurzem, bis die Fetzen flogen. Ich
> hatte Lothar damals schon drauf hingewiesen, daß die gesamte
> Anfänger-Literatur sowohl im Netz als auch an unseren hiesigen Fach- und
> Hochschulen in exakt DIESEM Punkt ausgesprochen lausig ist.

Meine Guete, welche Laus ist dir denn ueber die Leber gelaufen...

Deine Aussage bzgl. Literatur und auch Hochschulskripten muss man wohl 
zaehneknirschend akzeptieren, da gebe ich dir recht. Aber das liegt 
nicht an der HDL sondern an den bornierten Profs, die vor 20+ Jahren mal 
damit 'was gemacht' haben und genau auf diesem Niveau von damals stehen 
geblieben sind (meiner Meinung nach).

>
> Jeder dieser Nachaffen, der sich zu einem Tutorial für VHDL berufen
> gefühlt hat, hat von seinem Vorgänger abgekupfert und so ekelt sich der
> STD_LOGIC_VECTOR von einem Tutorial zum nächsten - und die elendiglichen
> Folgen davon (daß man beim Versuch, damit zu rechnen) sind, daß man
> zuerst auf die Nase fällt und dann mit weiteren Tutorials über das
> möglichst komplizierte Konvertieren bedacht wird.
>
> Alles NICHT hilfreich, alles NICHT zielführend.

Die miesen Tutorials ueber eine sehr fein, klar, deutlich ausformulierte 
HDL sind dann also das Problem der HDL? Uebrigens, urspruenglich war das 
rechnen gar nicht im Fokus, damals musste man ja auch noch jeden bloeden 
Akku aus einem Sack Halb/Volladdierer zusammentackern. Da musste man 
nicht 'a <= b + c;' schreiben. Das kam erst spaeter mit den Synopsys 
Libraries

> Und die zugehörigen
> Standards sind ebenfalls NICHT lehrreich.

Welche Standards meinst du? Ernsthafte Frage.

> Natürlich kann man das besser
> - aber eben nur, wenn man es bereits kann. Oder wenn man - wie in dem
> Witz über's Gehen über den See Genezareth (den ich mir hier aber mal
> verkneife) - weiß wo die Trittsteine im Wasser liegen. Vom Lesen der
> Standards oder der lausigen Tutorials oder der ebenso lausigen
> Beispielquellen findet man die Trittsteine nicht und ersäuft.. oder
> schwenkt zu Verilog um, was auf andere Art eklig ist.. oder verwendet
> gar Schematics, was in diesem Forum zum einhelligen Aufkreischen führt.
>
> Lothar Miller schrieb:
>>> Und auf welche Ausdrücke in dieser Programmiersprache muß man
>>> verzichten, wenn man auf diese ominösen Bibliotheken verzichtet?
>> Auf fast alle.
>
> Das heißt im Umkehrschluß, daß VHDL eine fast völlig ausdruckslose
> Programmiersprache ist, die nur dadurch benutzbar wird, daß man
> Bibliotheken mit Routinen einbindet - aber wie sind dort die Dinge
> ausgedrückt, die zwar nötig, aber in der Sprache per se nicht vorhanden
> sind?

Prinzipiell hast du damit sogar recht. Die Libs sind auch in VHDL 
geschrieben, damit kannst du ohne "Compilererweiterung" deinen 
Sprachumfang erweitern. Ist doch prima! Und falls du 
Halbleiterhersteller bist und deinen Kunden spezielle HW anbieten 
willst, dann kannst du einfach deine eigene Lib ausliefern, die tut dann 
mit jedem VHDL Compiler (naja, prinzipiell).

>
> Lothar, du merkst wohl an dieser Stelle, daß dein Versuch einer
> logischen Erklärung in einen circulus vitiosus mündet, nach dem Schema
> "wenn der Topf aber nun ein Loch hat". Ich hab in meinem esten Beitrag
> schon auf diesem Punkt herumgehackt und deine Antwort war unzureichend.
>
> Wahrscheinliche wäre es wesentlich zielführender, zu sagen:
> "Leute, schreibt den Sermon
> use IEEE.STD_LOGIC_1164.ALL;

Was ist so schwer daran zu akzeptieren, dass da halt der "universelle" 
Datentyp definiert und beschrieben ist? Und dass der so nette 
Sachen/Werte wie '0, 1, H, L, Z, ...' annehmen kann die einem die 
HW-Beschreibung und vor allem auch Simulation leichter machen. Hint: Es 
gibt doch auch 'bit' und 'bit_vector' und glaube mir, ich habe in den 
letzten Jahren noch immer sehr oft Sachen von Hochschulen (auch Profs! 
vom Institut) gesehen, die das immer noch verwenden. Das ganze im Mix 
mit std_logic, unsigned, signed, undundund. Dummheit der HDL? Ich denke 
eher nicht...

> use IEEE.NUMERIC_STD.ALL;

Damit wurde der Funktionsumfang um so schicke Sachen wie signed/unsigned 
und vieles mehr erweitert. Die Lib ist in VHDL geschrieben und du kannst 
die Source sogar nachlesen.

> use ... usw.
> einfach hin, macht euch keine weiteren Gedanken drüber und sucht nicht
> nach einer rationalen Erklärung, denn die gibt es nicht. Allenfalls kann
> man vermuten, daß es sich die Erfinder von VHDL eben so ausgedacht
> haben, daß man das tun muß - vermutlich aus dem Beweggrunde, daß diese
> Programmiersprache damit eventuell noch viel universeller sein könnte,
> als man es zum Redaktionsschluß sich hat vorstellen können."
> Amen.

Auch da steckt ein Koernchen Wahrheit drin. Stell' dir mal vor, du 
wolltest einen VHDL-Simulator schreiben. Dochdoch, solche Chaoten gibt 
es (z.B. GHDL). Das Konzept mit in VHDL geschriebenen Libraries erlaubt 
es dir, diese Libs einfach einzubinden, du musst nicht das Rad wieder 
neu erfinden/nachprogrammieren. Hat doch was, oder?

>
> Aber all den Abertausenden, die VHDL erlernen wollen und in ihren
> Projekten eben auch rechnen wollen oder müssen, ist damit noch lange
> nicht gedient. Die werden nach wie vor mittels des STD_LOGIC_VECTOR's in
> die Prärie geschickt.
>
> Ach was, trotzdem frohe Weihnachten.
>
> W.S.

Ich weiss ja, dass die VHDL nicht gefaellt. Aber erstens mal ist es 
schon eine sehr alte HDL und zweitens ist die Sprache irre maechtig und 
erweiterbar. Das fuehrt im Umkehrschluss halt auch zu einer gewissen 
Komplexitaet wenn man das erste Mal damit konfrontiert wird.

[Sigi (Gast)]

W.S. schrieb:
> Jeder dieser Nachaffen, der sich zu einem Tutorial für VHDL berufen
> gefühlt hat, hat von seinem Vorgänger abgekupfert und so ekelt sich der
> STD_LOGIC_VECTOR von einem Tutorial zum nächsten - und die elendiglichen
> Folgen davon (daß man beim Versuch, damit zu rechnen) sind, daß man
> zuerst auf die Nase fällt und dann mit weiteren Tutorials über das
> möglichst komplizierte Konvertieren bedacht wird.

Gut, dass mit dem Nachaffen stimmt schon bei vielen, aber ebenfalls
viele wissen schon genau, warum sie das machen. Dafür gibt es eine
Reihe von Gründen. Einer davon ist z.B. Abstraktion: warum muss die
darüberliegende Komponente wissen, was hinter den Signalen an
Bedeutung steht. Dort werden einfach Signale wie bei der Post
weitergereicht (die Post muss sich ja auch nicht um den Inhalt
scheren!). Und wenn statt STD_LOGIC mal STD_LOGIC_VECTOR für ein
Bündel von Signalen verwendet wird, dann sagt man einfach mal danke
für die ersparte Schreibarbeit.
Und das gilt erst recht für die finalen Port-Signale, die ja in
Leiterbahnen münden. Denn was interessiert sich dann der PCB-Designer
für deren Sinn? Der hat andere Aufgaben.

> ... Und die zugehörigen> Standards sind ebenfalls NICHT lehrreich. ...

Müsssen sie das überhaupt?

[FPGA-Neuling (Gast)]

Markus F. schrieb:
> Mich dann - wie die meisten wahrscheinlich - mit Typkonvertierungen
> vorwärts und rückwärts rumgeschlagen (dabei den ein oder anderen Fluch
> losgelassen) und irgendwann erstaunt festgestellt: überall dort, wo ein
> STD_LOGIC_VECTOR stehen kann, tut's auch ein UNSIGNED-Vektor. Deutlich
> weniger nervig.

Wie sollte man Deiner Meinung nach einen Port beschreiben, der aus einem 
16 Bit Adress und 32 Datenbus besteht? Bei den Daten macht unsigned wohl 
nicht immer Sinn, oder?