Aufzählungstypen in VHDL - Ampelsteueung

[maxpower (Gast)]

Hallo, ich habe nun ein anderes Problem.

Es geht diesmal um die Definiton eines Signal trafficlight. Folgende 
Werte können angenommen werden : Red, RedYellow, Yellow, Green.
Das Signal trafficlight soll mit case-when decodiert werden, um die 
Outputs red_output, yellow_output und green_output bei entsprechender 
Belegung von trafficlight zu steuern.

type trafficlight is (Red, RedYellow, Yellow, Green);
signal trafficlight_state_o : trafficlight;

--Output function
red_output <= ...;
yellow_output <= ...;
green_output <= ...;

case trafficlight_state_o is
  when Red => ...
  when RedYellow => ...
  when Yellow => ...
  when Green => ...
  when others => ...
end case

Der Code ist noch unvollständig. Ist sie aber von der Syntaxform her 
richtig?

MfG
maxpower

[Klaus (Gast)]

maxpower schrieb:
> Der Code ist noch unvollständig. Ist sie aber von der Syntaxform her
> richtig?

?????

Das verrät dir dein Compiler (Synthesetool, Simulator, ...) deiner Wahl.

[Andreas B. (andreas_b77)]

Im Prinzip stimmt es, wobei ich jetzt nicht sicher bin bei der Angabe 
von "when others" wenn schon alle möglichen Fälle angegeben sind.

Man sollte aber auf "when others" verzichten falls man im case nicht nur 
ein paar Fälle aus vielen behandeln will, was bei einer State Machine 
ungewöhnlich wäre. Wenn man dann irgendwann ein Zustand hinzufügt und im 
case vergisst, bekommt man eine Fehlermeldung. Mit others dagegen kommt 
keine Meldung – schließlich wird der neue Zustand unter others 
behandelt.

[maxpower (Gast)]

Bei drei Variablen Red, Yellow, Green (Signalen) gibt es ja 2^3=8 
Zustände.
Aber nur 4 Zustände treten in der Realität auf. Die nicht beachteten 
Zustände werden durch Benutzung von when others zusammengefasst. Oder 
habe ich das falsch verstanden mit when others?

[Klaus (Gast)]

Meine Güte, das steht in jedem VHDL Buch...

Aber in Kurzform: Nein, es gibt nicht 2^3 Zustände. Aus VHDL Sicht hat 
trafficlight_state_o genau 4 Zustände: (Red, RedYellow, Yellow, Green) 
Genau so, wie du es definiert hast. In welche Bitmuster das 
Synthesetool diese 4 Zustände codiert, braucht dich erstmal nicht zu 
interessieren.

[maxpower (Gast)]

Wie würde der Code vollständig lauten?

type trafficlight is (Red, RedYellow, Yellow, Green);
signal trafficlight_state_o : trafficlight;

--Output function
red_output <= '1';
yellow_output <= '0';
green_output <= '0';

case trafficlight_state_o is
  when Red => red_output <= '1';
  when RedYellow => red_output or yellow_output <= '1';
  when Yellow => yellow_output <= '0';
  when Green => green_output <= '0';
  when others => trafficlight_state_o <= error;
end case

So vielleicht?

[Klaus (Gast)]

Du lädst dir jetzt auf der Stelle einen VHDL Simulator runter und 
probierst das mal selber aus! :P

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

maxpower schrieb:
> Bei drei Variablen Red, Yellow, Green (Signalen) gibt es ja 2^3=8
> Zustände.
> Aber nur 4 Zustände treten in der Realität auf.
Mach dir keine Sorgen, wie der Synthesizer das realisiert...
http://www.lothar-miller.de/s9y/categories/25-when-others

> Bei Variablen ... (Signalen)
Diese Begriffe sind grundlegend unterschiedlich, sie dürfen nicht 
alternativ verwendet werden. Vergiss das Wort Variable als 
VHDL-Anfänger.
Siehe den Beitrag "Variable vs Signal"

[maxpower (Gast)]

Hallo Lothar, danke für deine Antworten. Die sind goldwert.

Zu Aufgabe 5:
proc1 benötigt mehr Hardware, da ein Latch benötigt wird. Die Schaltung 
ist unvollständig, da zwei ustände fehlen, d.h. "10" und "11" müssten 
vorkommen. proc2 ist ein Schaltnetz, speichert also nicht. Der 
Unterschied ist in Zeile 7, dadurch sind die beiden fehlenden Zustände 
abgedeckt und der Input hängt nicht mehr vom Output ab.

Zur Ampel:
Ist mein Code denn richtig? Ich würde ihn gerne simulieren, aber habe 
keine Software dafür in der Hand. Die von Xilinx ist einige GB groß und 
ich müsste extra ein Account dafür anlegen, um sie runterzuladen. 
Vielleicht kannst du mein Code verifizieren.

Da du die Aufgaben parat hast, kannst du mir verraten, was du zur 
Aufgabe 6 sagst? Meine Antwort wäre, dass keine Glitches verursacht 
werden, da es nach wie vor ein Schaltnetz beschreibt und diese i.d.R 
frei von allen Verzögerungen sind. Aber ist das wirklich das, was 
gefragt ist?

MfG
maxpower

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

maxpower schrieb:
> Ist mein Code denn richtig?
Zuallererst ist er unvollständig. Und deswegen nicht simulierbar.
Und dann ist z.B. error ein keyword und darüber hinaus kein Zustand 
vom Typ trafficlight.

Zudem kann so eine Zuweisung nicht funktionieren:
  red_output or yellow_output <= '1';
Soll er da rot oder gelb eine 1 zuweisen? Oder wie?

> keine Software dafür in der Hand. Die von Xilinx ist einige GB groß und
> ich müsste extra ein Account dafür anlegen, um sie runterzuladen.
Von nix kommt nix.
Sieh es vernünftig: die Software hat vor wenigen Jahren noch richtig 
Geld gekostet, heute kostet sie nur noch ein wenig Downloadzeit...

Du wirst nur dann lernen, wenn du das Zeug selber simulierst. Ich 
werde die Ampel sicher zum Laufen bekommen. Dir ist damit aber nicht 
geholfen...

maxpower schrieb:
> Da du die Aufgaben parat hast, kannst du mir verraten, was du zur
> Aufgabe 6 sagst?
Ein letztes Mal noch. Ich mag diese geheime Betreuung nicht, weil sie 
anderen im forum nicht weiterhilft...

Die Aufgabe fragt, ob zusätzliche Glitches erzeugt werden, abhängig 
davon, ob ein kombinatorischer Prozess mit Defaultzuweisungen oder aber 
mit einem auscodierten if-then-else Baum beschrieben wird.
> Meine Antwort wäre, dass keine Glitches verursacht werden, da es
> nach wie vor ein Schaltnetz beschreibt und diese i.d.R frei von
> allen Verzögerungen sind.
Diese Ansicht ist grundlegend falsch. Jede Kombinatorik mit mehr als 1 
Eingang kann und jede mehrstufige Kombinatorik wird Glitches haben.
Gerade Schaltnetze haben Durchlaufzeiten (jede durchlaufene LUT im FPGA 
braucht ein paar hundert ps, und jede Verbindung im FPGA hat 
Laufzeiten). Und diese Durchlaufzeiten verursachen Glitches.
Nur in der Verhaltenssimulation werden zur Vereinfachnung alle 
Logikgruppen als verzögerungsfrei angesehen...

Die richtige Antwort lautet:
Es lässt sich nicht mit Bestimmtheit sagen, weil es dem Synthesizer 
freigestellt ist, wie er eine VHDL-Beschreibung in Hardware 
implementiert. Die Faustformel: "jede if-Abfrage ist eine zusätzliche 
Logikebene, deshalb müssen verschachtelte if-Abfragen vermieden werden" 
ist spätestens nach dem ersten Synthesedurchlauf hinfällig. Ab dann 
arbeitet der Synthesizer intern eh' nur noch mit Logiktabellen...

[maxpower (Gast)]

Wie soll ich den Code zum Laufen bringen, wenn er, wie du anfangs 
schreibst, nicht simulierbar ist?

Zu Aufgabe 6:

Ist deine Antwort wortwörtlich zu nehmen, dass du schreibst, dass sie 
gar nicht beantwortbar ist? Wie hängen die Aufgaben 5 und 6 miteinander 
zusammen? Als Tipp wird gegeben, dass die Antwort zur Aufgabe 5 bedacht 
werden soll.

MfG
maxpower

[Schlumpf (Gast)]

@ maxpower:

Lässt du dir hier "hinterum" deine Hausaufgaben lösen? :-)

maxpower schrieb:
> Wie soll ich den Code zum Laufen bringen, wenn er, wie du anfangs
> schreibst, nicht simulierbar ist?

Der Code ist nicht simulierbar, weil Fehler drin sind.. Diese Fehler 
bekommst du angezeigt, wenn du dir die Mühe machst, und dir einen 
Simulator/Compiler aus dem Netz lädst.

Warum sträubst du dich so, einen Simulator zu laden, den Code zu 
compilieren, die Fehlermeldungen zu lesen, zu verstehen und dabei zu 
lernen?

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

Schlumpf schrieb:
> Der Code ist nicht simulierbar, weil Fehler drin sind.
Das auch. Aber er ist schon deshalb nicht simulierbar, weil der ganze 
VHDL-Header mit use und die entity sowie die ganzen Typdeklarationen 
und die architecture fehlen...

maxpower schrieb:
> Als Tipp wird gegeben, dass die Antwort zur Aufgabe 5 bedacht werden soll.
Ja, habe ich gesehen. In der Aufgabe 5 wird aber (vermutlich 
unerwünschterweise) ein Latch gebaut. Ein Latch hat aber nicht 
grundlegend etwas mit einer if-Abfrage zu tun. Ich kann ein Latch auf 
zig verschiedene Weisen beschreiben. Und idR. ist keine davon erwünscht 
oder gut.

> Wie hängen die Aufgaben 5 und 6 miteinander zusammen?
1. Sie stehen hintereinander.
2. In der Aufgabe 6 wird angeraten, die Lösung der Aufgabe 5 nochmal zu 
überdenken...

> Ist deine Antwort wortwörtlich zu nehmen, dass du schreibst, dass
> sie gar nicht beantwortbar ist?
Korrekt. Ohne weitere Information (wie denn diese if-Verschachtelungen 
aussehen sollen) ist keine bessere Aussage möglich.

BTW: Falls du die Lösungen für diese Aufgaben bekommst, würden die mich 
doch sehr interessieren...

BTW2: wenn ich mir die Eieruhrenaufgabe 7 so ansehe, dann wundert mich 
nicht, warum VHDL als "umständliche" Sprache angesehen wird. Kurz: es 
ist nicht die Sprache, die umständlich ist, es ist meist das der 
Beschreibung zugrundeliegende Konzept, das umständlich ist...
Eine Stoppuhr ist sowas ähnliches wie eine Eieruhr:
http://www.lothar-miller.de/s9y/archives/88-VHDL-vs.-Verilog-am-Beispiel-einer-Stoppuhr.html

[maxpower (Gast)]

type trafficlight is (Red, RedYellow, Yellow, Green);
signal red_output, yellow_output, green_output: trafficlight;

--Output function
red_output <= '1';
yellow_output <= '0';
green_output <= '0';

case red_output is
  when Red => red_output <= '1';
  when Red | Yellow => red_output and yellow_output <= '1'
  when Yellow => yellow_output <= '0';
  when Green => green_output <= '0'
end case;

case yellow_output is
  when Red => red_output <= '0';
  when Red | Yellow => red_output and yellow_output <= '1'
  when Yellow => yellow_output <= '1';
  when Green => green_output <= '0'
end case;

case green_output is
  when Red => red_output <= '0';
  when Red | Yellow => red_output and yellow_output <= '0'
  when Yellow => yellow_output <= '0';
  when Green => green_output <= '1'
end case;

Ich glaube selber nicht daran, dass das stimmt.
Wahrscheinlich habe ich mich nun endgültig unbeliebt gemacht bei euch.

[Schlumpf (Gast)]

hast dir mittlerweile einen Simulator besorgt?

[maxpower (Gast)]

Dein Ratschlag bringt mir absolut nichts.
Die Aufgabe ist so gestelllt, dass kein Simulator verwendet werden muss.

[Schlumpf (Gast)]

maxpower schrieb:
> Dein Ratschlag bringt mir absolut nichts.

Es war kein Ratschlag sondern eine Frage...
Und selbst wenn du es als Ratschlag interpretieren willst, dann kannst 
du gar nicht beurteilen, ob er dir nichts bringt, da du keinen Dunst 
hast, was der Simulator dir alles verraten würde..

maxpower schrieb:
> Die Aufgabe ist so gestelllt, dass kein Simulator verwendet werden muss.

Die Aufgabe ist aber sicher so gestellt, dass man VHDL verwenden muss.
Ich nehme an, dass es sich dabei um eine Aufgabe aus der Schule / 
Studium handelt. Daher gehe ich davon aus, dass hier nichts gefordert 
ist, was nicht auch in Unterricht / Vorlesung behandelt wurde oder 
zumindest die Grundlagen dafür geschaffen wurden.
Wenn du diese ganz offensichtlich nichtmal im Ansatz begiffen hast, dann 
kann das verschiedene Ursachen haben, auf die ich hier nicht näher 
eingehen will.
Aber eines ist klar:
Du bist dir zu fein, einen Simulator zu verwenden (warum auch immer) und 
behauptest, dass die Aufgabe ohne Simulator lösbar sei.
Richtig, das ist sie auch.. aber offensichtlich nicht für dich.
Denn genau die Fragen, die du hier im Forum stellst, würde dir eine 
Simulation beantworten.. nein, nicht ganz richtig, denn den Quark, den 
du da hinschreibst, führt dazu, dass der Simulator sich sogar weigern 
wird, mit der Simulation zu beginnen. ABER, er würde dich freundlich 
darauf hinweisen, was an diesem völlig verkorksten Code syntaktisch 
falsch ist.
Hättest du den Code soweit bereinigt, dass er syntaktisch stimmt, dann 
würde die Simulation starten und du würdest sehen, wo deine semantischen 
Fehler sind.
Aber genau das willst du ja nicht. Du willst lieber, dass wir dir hier 
deinen Code korrigieren und bist aber nicht ansatzweise bereit, deinen 
Teil dazu beizutragen.
Kurzum: Wenn du wegen einer verpatzten Prüfung deinen Abschluss nicht 
schaffst, dann ist das in deinem Fall mehr als gerechtfertigt.
In einer Prüfung wird das Wissen und Können abgefragt und beides scheint 
bei dir in Punkto VHDL gegen Null zu tendieren.
Dazu kommt erschwerend die Tatsache, dass du nicht bereit bist, dich 
Schlau zu machen und dazuzulernen. Die Tips der anderen kategorisch 
ablehnst, die dir helfen sollen, das ganze zu verstehen und nicht nur 
abzupinseln.
Dein Codevorschlag zeigt mir jedenfalls, dass du nichtmal im Ansatz 
begreifst, was du da tust, sondern nur wirr irgendwelchen Mist 
zusammentippst, in der Hoffnung, dass dir hier irgendjemand sagt, dass 
es so nicht geht und wie es dann richtig geht.

maxpower schrieb:
> Wahrscheinlich habe ich mich nun endgültig unbeliebt gemacht bei euch.

Richtig.. das hast du.. aber nicht, weil du kein VHDL kannst, sondern 
weil jegliche Hilfe zur Selbsthilfe ablehnst und einfach nur die fertige 
Lösung präsentiert haben willst.
Weil du zeigst, dass du es gar nicht verstehen WILLST, sondern einfach 
nur ne Lösung brauchst. Und sowas werden die wenigstens hier 
unterstützen.
Wie gesagt: wer so drauf ist, fällt zurecht durch die Prüfung. Und das 
ist auch der Sinn und Zweck einer Prüfung.

[Fpgakuechle K. (Gast)]

maxpower schrieb:
>

type trafficlight is (Red, RedYellow, Yellow, Green);
> signal red_output, yellow_output, green_output: trafficlight;
> 
> --Output function
> red_output <= '1';
> yellow_output <= '0';
> green_output <= '0';
> 
> case red_output is
>   when Red => red_output <= '1';
>   when Red | Yellow => red_output and yellow_output <= '1'
>   when Yellow => yellow_output <= '0';
>   when Green => green_output <= '0'
> end case;


>

Semicolons sind unvollständig;

red_output ist vom typ trafficlight, kann also nie '0' und '1' annehmen 
wie zugewiesen.

Eine Zuweisung hat immer ein Ziel nicht zwei und das Schlüsselwort "and" 
steht nie auf der linken Seite einer Zuweisung.

Für eine FSM benötigt man 3 Vectoren: Eingang, Ausgang, Zustand. Einen 
Aufzählungstypen verwendet man für den Zustandsvektor, für die anderen 
ist std_logic eine gute Wahl.

Diese 3 Vektoren sind durch zwei Gleichungen verknüpft

output       <= F(zustand  ,Input)
zustand_t+1  <= G(zustand_t,Input)

(BTW: Varianten wie Mealy und Moore lasse ich hier unbeachtet).

In deiner VHDL-beschreibung müssen diese 3 Vektoren deklariert und 
beschrieben sein.  Case läuft über die Elemente von Zustand und in den 
einzelnen Zweigen werden zustand_t+1 und output gesetzt, wobei der input 
über If-Anweisungen einfliesst.

Derzeit fehlt der Input komplett , während output und zustand total 
verquirlt sind.


Vorschlag:
tippe irgend eine VHDL-Ampelsteuerung ab ( z.B 
http://jjd983.50webs.com/docs/digital/adv%20dig%20Lab_30%20traffic%20light%20controller.pdf) 
und modifiziere diese dann
(typendeklarationen , signalnamen). Vielleicht helfen dir die Videos auf 
youtube weiter: bspw. http://www.youtube.com/watch?v=6_Rotnw1hFM.

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

maxpower schrieb:
> Ich glaube selber nicht daran, dass das stimmt.
Natürlich nicht, denn jede VHDL-Beschreibung fängt mit use an. Ich 
hatte das schon mal angesprochen im 
Beitrag "Re: Aufzählungstypen in VHDL - Ampelsteueung"

Fpga Kuechle schrieb:
> Eine Zuweisung hat immer ein Ziel nicht zwei und das Schlüsselwort "and"
> steht nie auf der linken Seite einer Zuweisung.
Ich meine, sowas ähnliches auch schon mal angedeutet zu haben, dort im 
Beitrag "Re: Aufzählungstypen in VHDL - Ampelsteueung"

maxpower schrieb:
> Die Aufgabe ist so gestelllt, dass kein Simulator verwendet werden muss.
Es geht nicht darum, ob einer verwendet werden muss, sondern ob einer 
verwendet werden darf...

maxpower schrieb:
> Wahrscheinlich habe ich mich nun endgültig unbeliebt gemacht bei euch.
Dein Verhalten zeugt von einer gewissen Lernresistenz, zumindest aber 
von von der Tendenz, gutgemeinte Ratschläge von Profis nicht 
anzunehmen, und es stattdessen selber besser wissen zu wollen. Du kaust 
nur dein eigenes Zeug wieder und legst es danach nochmal zur 
Begutachtung vor. Da macht das Antworten keinen Spass mehr und vor 
allem: es bringt nichts...

Nochmal: ohne Verwendung einer Toolchain (oder allerwenigstens eines 
Simulators) wird das nichts.

[Fpgakuechle K. (Gast)]

Lothar Miller schrieb:

> Nochmal: ohne Verwendung einer Toolchain (oder allerwenigstens eines
> Simulators) wird das nichts.

Manchmal liegt so eine Software-"scheu" weniger an den Studenten als an 
den Hochschullehrern. Noch in den neunzigern wurde da einiges 
ausschließlich "per Hand" gemacht (Karnaugh-tafel) und auch heute noch 
posaunen Professoren das die Ausbildung an CAD oder CAE-Tools nicht zu 
den Aufgaben einer Hochschule gehört. Das muß dann die Einarbeitungszeit 
in den Job oder Hobbyaktivitäten nachholen.
Meines Erachtens sollte jede ET-Fakultät ein betreuten workstationpool 
betrieben, an dem jeder jederzeit mit den tools rumspielen kann.

[maxpower (Gast)]

type trafficlight is (Red, RedYellow, Yellow, Green);
signal trafficlight_state_o : trafficlight;

case trafficlight_state_o is
  when Red       =>       red_output <= '1';
                          yellow_output <= '0';
                          green_output <= '0';  
  when RedYellow =>       red_output <= '1';
                          yellow_output <= '1';
                          green_output <= '0';
  when Yellow    =>       red_output <= '0';
                          yellow_output <= '1';
                          green_output <= '0';
  when Green     =>       red_output <= '0';
                          yellow_output <= '0';
                          green_output <= '1';
end case;

Das sollte es sein.

[Fpgakuechle K. (Gast)]

maxpower schrieb:
>

type trafficlight is (Red, RedYellow, Yellow, Green);
> signal trafficlight_state_o : trafficlight;
> 
> case trafficlight_state_o is
>   when Red       =>       red_output <= '1';
>                           yellow_output <= '0';
>                           green_output <= '0';
>   when RedYellow =>       red_output <= '1';
>                           yellow_output <= '1';
>                           green_output <= '0';
>   when Yellow    =>       red_output <= '0';
>                           yellow_output <= '1';
>                           green_output <= '0';
>   when Green     =>       red_output <= '0';
>                           yellow_output <= '0';
>                           green_output <= '1';
> end case;
>

>
> Das sollte es sein.

Das ist aber nur die output decodierung, es fehlt entity komplett, 
architecture corpus, process corpus, Steuerung der Zustandsübergängen, 
....
Ein expliziter start-Wert resp. Initialisierung für traffivlight_state_o 
wäre auch nicht schlecht.

MfG,

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

Fpga Kuechle schrieb:
> Das ist aber nur die output decodierung
Man kann es offenbar nicht oft genug wiederholen...

[Schlumpf (Gast)]

Lothar Miller schrieb:
> Man kann es offenbar nicht oft genug wiederholen...

Na ja. Ihm ging es ja nur um die Aufzählungstypen. Daher nehm ich mal 
an, dass das nur ein Ausschnitt seines Codes ist. Oder hier taucht bald 
ein Fred auf:"Ampelsteuerung: Ablauf so richtig?"

[Fpgakuechle K. (Gast)]

Schlumpf schrieb:
> Lothar Miller schrieb:
>> Man kann es offenbar nicht oft genug wiederholen...
>
> Na ja. Ihm ging es ja nur um die Aufzählungstypen. Daher nehm ich mal
> an, dass das nur ein Ausschnitt seines Codes ist. Oder hier taucht bald
> ein Fred auf:"Ampelsteuerung: Ablauf so richtig?"

Ich glaub, die Aufgabe hat er nicht selbst sondern sein Professor 
gestellt, und meines Erachtens didaktisch suboptimal für VHDL-Designs. 
Man sollte hier also nur den enum-typ und das case-construct 
kennenlernen und nicht die Beschreibung einer FSM? Das ist meines 
Erachtens der falsche Ansatz. Damit lernt man keinen Digitalentwurf.

MfG

[Schlumpf (Gast)]

Fpga Kuechle schrieb:
> Ich glaub, die Aufgabe hat er nicht selbst sondern sein Professor
> gestellt, und meines Erachtens didaktisch suboptimal für VHDL-Designs.
> Man sollte hier also nur den enum-typ und das case-construct
> kennenlernen und nicht die Beschreibung einer FSM? Das ist meines
> Erachtens der falsche Ansatz. Damit lernt man keinen Digitalentwurf.

Nein, so war das nicht gemeint.
Natürlich hat er die Aufgabe nicht selber gestellt, sondern das ist ne 
Art Hausaufgabe oder Übungsaufgabe.
Ich meinte das eher ironisch bezüglich der Kommentare, dass das ja noch 
lange keine Ampelsteuerung sei.
Wollte damit nur sagen, dass er ja auch nicht darum gebeten hat, ihm zu 
zeigen, wie eine Ampelsteuerung funktioniert, sondern lediglich darum, 
ihm zu sagen, ob der Aufzählungstyp syntaktisch richtig ist..

maxpower schrieb:
> Der Code ist noch unvollständig. Ist sie aber von der Syntaxform her
> richtig?

Aber sicher wird seine Frage nach dem "Rest" für eine Ampelsteuerung 
nicht lange auf sich warten lassen... :-)