Wie kann man diese State mal erklärend schreiben?

Also wird hier schon der Wert vergeben beim Statebefehl:
type rx_state_t is (IDLE, BUSY, READY);
Die Reihenfolge in der Klammer bestimmt den Wert?

IDLE = 0
BUSY = 1
READY = 2

Danke.
Gruss

Danke.

WEnn ich jetzt : signal rx_state : rx_state_t := Busy ; schreibe.
Wie ist da die Reihenfolge?

Danke.

Myxo Matrose schrieb:
> IDLE = 0
> BUSY = 1
> READY = 2

nicht immer!

Die Abbildung von Enums auf eine physikalische Repräsentation ist 
variabel und nur in wenigen Fällen wichtig (sonst kann man ja gleiche 
die Repräsentation nehmen, in Kombination mit Konstanten evtl.).

Bei Verwendung hier werden die Enums auf die States einer State-Maschine 
abgebildet und die kann auch schon mal "one-hot" oder "gray" oder noch 
ganz anders kodiert sein (bestimmt die Synthese selbst, wenn sie darf).

zurück zum TO:

Die "type" Zeile legt fest, wieviele Werte es geben soll und wie diese 
heißen sollen.

Die Deklarationszeile definiert ein Signal welches diese Werte aufnehmen 
können soll und wenn es sich um Register handelt, mit welchen Wert diese 
Register beim Laden des FPGAs gesetzt werden sollen.

grüße

Myxo Matrose schrieb:
> lediglich wird 'signal rx_state' mit
> '1' vorbelegt.

Falsch!

rx_state KANN gar nicht mit einer 1 vorbelegt werden, da rx_state nur 
die Werte IDLE, BUSY, READY annehmen kann.
Verwechsel das bitte nicht mit einem Array oder sowas in der Art!

Erst bei der Synthese muss zwangsläufig jeder Wert durch einen binär 
darstellbaren Wert repräsentiert werden.

Myxo Matrose schrieb:
> dessen Vorteil du offensichtlich noch nicht inhaliert hast.

Is recht... :-)
Wenn du der Meinung bist, dass in dem geschilderten Fall "BUSY" nur eine 
Alias für "1" ist, dann glaub das einfach.

Myxo Matrose schrieb:
> Ich glaube dem Simulator, nicht einem Individuum mit blauer Zipfelmütze

Exakt. Und wenn du dann mal in deinen Simulator schaust, wird da 
drinstehen, dass rx_state den Wert IDLE oder BUSY hat.
Es wird aber nicht drinstehen, dass rx_state den Wert 0 oder 1 hat.

Ich glaube meinem Simulator mehr, als einem skorbut-geplagtem 
Deckschrubber :-)

Myxo Matrose schrieb:
> Nichtsdestotrotz werden typisierte Konstanten letztendlich als
> numerische Werte verarbeitet, egal ob µC oder logic array.

Richtig!
Dein *.vhd-File liegt auch binär auf der Festsplatte rum.
Es geht hier aber um die Syntax. Und du behauptest:

Myxo Matrose schrieb:
> peter schrieb:
>> WEnn ich jetzt : signal rx_state : rx_state_t := Busy ; schreibe.
>> Wie ist da die Reihenfolge?
>
> Die Reihenfolge ändert sich nicht, lediglich wird 'signal rx_state' mit
> '1' vorbelegt

Wenn das so ist, dann ergibt also BUSY + READY = 3 oder IDLE < READY = 
true?

Vielleicht interpretiert dein Compiler aber auch einfach ONE-HOT und 
repräsentiert dannn IDLE mit 001, BUSY mit 010 und READY mit 100.. oder 
doch wieder ganz anders?
ERGO: Die Darstellung der ENUM-Werte in Binäre Werte erfolgt erst zum 
Zeitpunkt der Synthese. Und für die Darstellung gibt es zig verschiedene 
Möglichkeiten. Daher ist es einfach nur falsch, wenn du pauschal in die 
Welt posaunst, dass
signal rx_state : rx_state_t := Busy das signal rx_state mit '1' 
vorbelegt

Vielleicht macht das dein komischer Complier so, aber das ist nicht 
VHDL, sondern eine Interpretation deines Compilers, Synthesizers, oder 
was auch immer.

Ich weiss, das wirst du nicht verstehen. Aber ich erwarte das auch nicht 
von dir, dass du das begreifst.
Mir geht es nur darum, dass sich der TO von deinem verzapften Unsinn 
nicht irre leiten lässt und später irgendwann die Frage auftaucht, warum 
der Compiler bei
IF rx_state = '1' THEN..
nen Fehler schmeißt

PS.. Achtern hast du noch nicht geschrubbt..

Lothar hat wie eigentlich immer recht...

Nur mal so als Denksportaufgabe: Versuche doch mal jemand, einen selbst 
definierten type (bzw. das signal) auf ein paar LEDs auszugeben. Das 
wird ohne explizite Decodierung nicht funktionieren...

Danke Lothar ;-)

Myxo Matrose schrieb:
> Bin ein alter Pascaliner :-)

Süß

Myxo Matrose schrieb:
> Ich weiß, dass die Jungs von Borland die namentliche Enumration
> eingeführt haben, um dem Programmierer ihre Arbeit zu erleichtern.

Wusste gar nicht, dass Borland auch VHDL-Compiler machte... Ich bin doch 
hier im FPGA-Forum oder nicht? Oder beschreibt man Hardware neuerdings 
in Pascal?
Oder bist du einfach nur der Meinung, weil dein Borland-Pascal-Compiler 
Enums aufsteigend durchnumeriert, dies alle Compiler der Welt genauso 
machen?

Myxo Matrose schrieb:
> Ich habe nichts dazugelernt.

DIESE Aussage glaube ich dir sofort!

kopfschüttel

Myxo Matrose schrieb:
> Ich habe nichts dazugelernt.
Sorry, das merkt man

> Seit ich damals meinen Pascal Compiler (für
> DOS) unter Turbo Pascal geschrieben habe, begleitet mich dieses
> nützliche feature. Und ich bin mir nicht sicher, ob es sowas auch in C
> gibt.
Und dir ist auch sonnenklar, dass HW Synthese nix mit Software Compiler 
zu tun hat?

Myxo Matrose schrieb:

> Ich habe nichts dazugelernt. Seit ich damals meinen Pascal Compiler (für
> DOS) unter Turbo Pascal geschrieben habe, begleitet mich dieses
> nützliche feature. Und ich bin mir nicht sicher, ob es sowas auch in C
> gibt.

Gibt es, heisst enum
http://www.proggen.org/doku.php?id=c:type:enum

ADA das immer mal wieder als Vorbild für VHDL genannt wird, kennt 
ebenfalls enums -> 
http://en.wikibooks.org/wiki/Ada_Programming/Types/Enumeration#Enumeration_literals

Java dagegen hat diesen typ erst nachträglich erhalten:
http://de.wikipedia.org/wiki/Aufz%C3%A4hlungstyp

BTW boolean ist auch ein Aufzählungstyp (wie std_logic).

MfG,

Schlumpf schrieb:

> Exakt. Und wenn du dann mal in deinen Simulator schaust, wird da
> drinstehen, dass rx_state den Wert IDLE oder BUSY hat.
> Es wird aber nicht drinstehen, dass rx_state den Wert 0 oder 1 hat.

das kommt darauf an  was du simulierts. Nach der Sythese also bei der 
Simulation der Netzliste finden sich kein IDLE oder Busy sondern nur 
numerische Werte.

MfG,

Fpga Kuechle schrieb:
> das kommt darauf an  was du simulierts. Nach der Sythese also bei der
> Simulation der Netzliste finden sich kein IDLE oder Busy sondern nur
> numerische Werte.

War ja auch nie die Rede von der Simulation einer synthetisierten 
Netzliste.
Und ich habe ja auch ganz am Anfang gesagt, dass bei der Synthese 
natürlich eine Abbildung auf eine binäre Darstellung erfolgen muss.

Schlumpf schrieb:
> Erst bei der Synthese muss zwangsläufig jeder Wert durch einen binär
> darstellbaren Wert repräsentiert werden.

Ob das tatsächlich so ist, wie du sagst, und in der Netzliste dann nur 
noch die Information über die enumierierten Werte vorliegt, kann ich 
nicht sagen. Da habe ich nie drauf geachtet.
Könnte mir aber vorstellen, dass das dann wirklich nicht mehr geht.
Denn wenn die binäre Darstellung der Werte mehr Werte zulässt, als 
"aufgezählt" sind (z.B. bei einer one hot-Codierung), müssten immer alle 
"unbenutzen" binären Kombinationen auch "benannt" werden, um den 
Simulatior nicht durcheinander zu bringen.

Denn was soll der Simulator darstellen, wenn im Umschaltmoment von IDLE 
nach BUSY kurz der "ungültige" Wert "111" anliegt?

Myxo Matrose schrieb:
> Die Reihenfolge ändert sich nicht, lediglich wird 'signal rx_state' mit
> '1' vorbelegt.

Falsch
Der Compiler wird eine Fehlermeldung schmeißen.

Lothar Miller schrieb:
> Fpga Kuechle schrieb:
>> Nach der Sythese also bei der Simulation der Netzliste finden sich kein
>> IDLE oder Busy sondern nur numerische Werte.
> Sind das dann die enumerierten Werte? Und wie ist das beim std_logic?

Schau mal in den Synthesereport, bei XST *.syr . Das beantwortet die 
erste Frage. bei mir steht da jedenfalls:

Analyzing FSM <FSM_1> for best encoding.
Optimizing FSM <keyboardVhdl_fk_1/scan_seq_q/FSM> on signal 
<scan_seq_q[1:3]> with gray encoding.
----------------------
 State    | Encoding
----------------------
 idle     | 000
 incoming | 001
 extended | 011
 released | 010
 complete | 110
----------------------


Bei std_logic weiss ich es grad nicht. 'U' (Unititialized) wird wohl 
bleiben, 'X' könnte entwchwinden da die Hauptursache dafür "multiple 
Sources" bei der synthese zum Abbruch führt. Bei Post-Mapping solte dann 
nur noch '1' und '0' aud std_logic rumschwirren - das ist aber nur eine 
Vermutung.

MfG,

Schlumpf schrieb:

> Denn wenn die binäre Darstellung der Werte mehr Werte zulässt, als
> "aufgezählt" sind (z.B. bei einer one hot-Codierung), müssten immer alle
> "unbenutzen" binären Kombinationen auch "benannt" werden, um den
> Simulatior nicht durcheinander zu bringen.

Nicht benannt, aber behandelt. Deshalb schreibt man immer einen 
OTHERS-Zweig
auch wenn alle enum-states im case behandelt werden.

> Denn was soll der Simulator darstellen, wenn im Umschaltmoment von IDLE
> nach BUSY kurz der "ungültige" Wert "111" anliegt?

Ich nehme an das er mit "Out of range" abbricht wenn ein wert ausserhalb 
des Wertebereichs berechnet wird.

MfG,

Fpga Kuechle schrieb:
> Deshalb schreibt man immer einen
> OTHERS-Zweig auch wenn alle enum-states im case behandelt werden.

Dachte ich auch immer.. bis mir ich mir mal die Warnigs durchgelesen 
habe und da stand dann sinngemäß drin:

"OTHERS-State wird nicht implementiert, da er sowieso nicht vorkommen 
kann."

Ist ja auch richtig in einem synchronen Design :-)

berndl schrieb:

>> Seit ich damals meinen Pascal Compiler (für
>> DOS) unter Turbo Pascal geschrieben habe, begleitet mich dieses
>> nützliche feature. Und ich bin mir nicht sicher, ob es sowas auch in C
>> gibt.
> Und dir ist auch sonnenklar, dass HW Synthese nix mit Software Compiler
> zu tun hat?


Doch VHDL und PASCAL haben als "Comutersprachen" eine ganze Menge 
gemeinsam
wie das prinzipielle Konzept der Lexik und Grammatik und der Verwendung 
von Typen. Beide kennen einen Aufzählungstyp, bei beiden gibt es regeln 
zur Wertigkeit innerhalb eines enums. Und bei beiden wird der 
Aufzählungstyp bei der "Übersetzung" durch einen numerische 
repräsentation ersetzt.
Da ist es völlig legitim anhand von Analogien zu lernen.

MfG,

Fpga Kuechle schrieb:
> Ich nehme an das er mit "Out of range" abbricht wenn ein wert ausserhalb
> des Wertebereichs berechnet wird.

Dann müsste er aber ständig abbrechen, oder nicht?

Bei jedem mal, wenn der Zustand gewechselt wird schalten die Register 
z.B. von 001 nach 010. Das wäre für mich noch kein Grund für einen 
Fehler, wenn da dann kurzzeitig 011 anliegt, solange bis zur nächsten 
Flanke des Taktes alles wieder eingeschwungen ist. Und ich würde auch 
erwarten, dass der Simulator deswegen nicht abbricht.

Schlumpf schrieb:

> Ist ja auch richtig in einem synchronen Design :-)

Nur so lange man sich nicht mit spontan kippenden FF durch kosmische 
Strahlung wie bei Avionik auseinandersetzen muß. Oder was ist mit 
plötzlichen Spannungseinbrüchen an der Core-Spannung des FPGA.

Auch Sicherheitsanforderungen verlangen ggf. das man FSM bullet-proof 
realisiert. also dafür sorgt das eine ausgeflippte FSM keinen Schaden 
anrichtet und wieder in einen sicherer Zustand überführt wird.

> Fpga Kuechle schrieb:
>> Deshalb schreibt man immer einen
>> OTHERS-Zweig auch wenn alle enum-states im case behandelt werden.
>
> Dachte ich auch immer.. bis mir ich mir mal die Warnigs durchgelesen
> habe und da stand dann sinngemäß drin:
>
> "OTHERS-State wird nicht implementiert, da er sowieso nicht vorkommen
> kann."

Doch illegale states können vorkommen, nur eben recht selten. Und deine 
sinngemäße Überstzung glaube ich erst mal nicht, letzlich tut die fsm 
auch was bei illegalen states man weiss aber nicht genau was, wenn man 
es nicht explizit angibt.

Zu denken mit OTHERS ist alles bzgl illegaler states behandelt ist 
natürlich falsch, das hast du natürlich recht. Da hilft eigentlich nur 
eine Post-simulation mit Fehlerinjektion um gewünschtes Verhalten 
nachzuweisen.

MfG,

Schlumpf schrieb:
> Fpga Kuechle schrieb:
>> Ich nehme an das er mit "Out of range" abbricht wenn ein wert ausserhalb
>> des Wertebereichs berechnet wird.
>
> Dann müsste er aber ständig abbrechen, oder nicht?
>
> Bei jedem mal, wenn der Zustand gewechselt wird schalten die Register
> z.B. von 001 nach 010. Das wäre für mich noch kein Grund für einen
> Fehler, wenn da dann kurzzeitig 011 anliegt, solange bis zur nächsten
> Flanke des Taktes alles wieder eingeschwungen ist. Und ich würde auch
> erwarten, dass der Simulator deswegen nicht abbricht.

Wenn de simulator mit std_logic statt mit enum arbeitet wird er 
natürlich nicht abbrechen sondern eben den zustandsvector mit diesem 
enumtechnisch illeaglen Wert belegen resp anzeigen. Zustandsübergang 
aund Ausgangsvektorlogik werden dann diesen illegalen Wert 
ausdecodieren. Was dann passiert ist entweder im others-zweig definiert 
oder toolspezifisch.

MfG,

Fpga Kuechle schrieb:
> sondern eben den zustandsvector mit diesem
> enumtechnisch illeaglen Wert belegen resp anzeigen

Genau auf das wollte ich die ganze Zeit schon hinaus.

Schlumpf schrieb:
> Könnte mir aber vorstellen, dass das dann wirklich nicht mehr geht.
> Denn wenn die binäre Darstellung der Werte mehr Werte zulässt, als
> "aufgezählt" sind (z.B. bei einer one hot-Codierung), müssten immer alle
> "unbenutzen" binären Kombinationen auch "benannt" werden, um den
> Simulatior nicht durcheinander zu bringen.

Schlumpf schrieb:

> Genau auf das wollte ich die ganze Zeit schon hinaus.
>
> Schlumpf schrieb:
>> Könnte mir aber vorstellen, dass das dann wirklich nicht mehr geht.
>> Denn wenn die binäre Darstellung der Werte mehr Werte zulässt, als
>> "aufgezählt" sind (z.B. bei einer one hot-Codierung), müssten immer alle
>> "unbenutzen" binären Kombinationen auch "benannt" werden, um den
>> Simulatior nicht durcheinander zu bringen.

Das stimmt so aber nicht, der Simulator kommt in der 
Verhaltenssimulation nicht durcheinander wenn die illegalen Zustanden 
nicht durch Elemente des enum "benannt" sind. Er stellt halt nur nicht 
das reale verhalten der (synthetisierten) Schaltung dar.

MfG,

Fpga Kuechle schrieb:
> Das stimmt so aber nicht, der Simulator kommt in der
> Verhaltenssimulation nicht durcheinander

Habe ich auch nie behauptet!
Ich redete die ganze Zeit von der Post-Synthese-Simulation und nicht von 
der Verhaltenssimulation.

Fpga Kuechle schrieb:
> Er stellt halt nur nicht
> das reale verhalten der (synthetisierten) Schaltung dar.

Wie gesagt, ich rede NICHT von der Verhaltenssimulation!
Wenn er die "benannten" Elemente beibehält (wie auch immer), dann stellt 
sich mir die Fragen, was er im Umschaltmoment darstellt?
Also

IDLE------???-----BUSY

Wenn er die binäre Repräsentation der Werte darstellt, löst sich das 
Problem von selber:

001------011------010

Nicht mehr und nicht weniger wollte ich schon die ganze Zeit zum 
Ausdruck bringen. Es war lediglich ein Gedanke, warum NACH der Synthese 
eine Darstellung der "benannten" Elemente vermutlich nicht mehr sinnvoll 
möglich ist.

Schlumpf schrieb:
> Fpga Kuechle schrieb:
>> Das stimmt so aber nicht, der Simulator kommt in der
>> Verhaltenssimulation nicht durcheinander
>
> Habe ich auch nie behauptet!
> Ich redete die ganze Zeit von der Post-Synthese-Simulation und nicht von
> der Verhaltenssimulation.

Zitat deine postings vom 10:54 ->

> War ja auch nie die Rede von der Simulation einer synthetisierten
> Netzliste.

Was nun??! Meinst du Post-Synthese Simulation oder Pre-Synthese 
Simulation?
Oder stammen diese Aussagen von unterschiedlichen Schlümpfen?

Du springst hier ständig zwischen den Beschreibungsformen hin und her 
ohne anzugeben was du gerade meinst. Bspw im posting 11:00 vom 11.10:

>Myxo Matrose schrieb:
>> lediglich wird 'signal rx_state' mit
>> '1' vorbelegt.

>Falsch!

> rx_state KANN gar nicht mit einer 1 vorbelegt werden, da rx_state nur
> die Werte IDLE, BUSY, READY annehmen kann.
> Verwechsel das bitte nicht mit einem Array oder sowas in der Art!

Du argumentierts hier gegen eine Aussage die sich auf die numerische 
Representation des Aufzählungstyp bezieht mit der typdeklaration aus der 
Verhaltensbeschreibung (und damit vor Abbildung auf die num. 
Repräsentation).

MfG,

Alles gut, reg dich ab..

DU warst derjenige, der irgendwann das Ruder von der 
Verhaltenssimulation zur Post-Synthese Simulation rumgerissen hat!

Schlumpf schrieb:
> Fpga Kuechle schrieb:
>> das kommt darauf an  was du simulierts. Nach der Sythese also bei der
>> Simulation der Netzliste finden sich kein IDLE oder Busy sondern nur
>> numerische Werte.
>
> War ja auch nie die Rede von der Simulation einer synthetisierten
> Netzliste.
> Und ich habe ja auch ganz am Anfang gesagt, dass bei der Synthese
> natürlich eine Abbildung auf eine binäre Darstellung erfolgen muss.

Bist zu diesem Zeitpunkt war IMMER die Rede von der 
Verhaltenssimulation.

Dann hast du gesagt, dass es darauf ankomme, was man simuliert.
Und schwupps, waren wir bei der POST-Synthese. Oder wolltest du mit 
"kommt drauf an, was man simuliert" auf was anderes hinaus?

Ich sagte jedenfalls zu diesem Zeitpunkt, dass bis dahin nie die Rede 
von einer synthetisierten Netzliste gewesen sei. Was ja auch der Fall 
war.
Aber ab dem Zeitpunkt hast du die synthetisierte Netzliste ins Spiel 
gebracht mit Themen wie "robuste Codierung von FSM" und warum das 
OTHERS-Statement deiner Meinung nach so wichtig sei etc (die, abgesehen 
davon, mit der eigentlichen Fragestellung gar nichts zu tun hatten).

Ab diesem Moment waren wir bei dem von DIR eingeleiteten Thema der 
Repräsentation der ENUM-Typen in einer POST-Synthese Simulation.
Bis zu dem Zeitpunkt, wo  DU heut um 12:26 urplötzlich wieder von der 
Verhaltenssimulation redest.

Also bitte Küchle, wer von uns beiden springt hier hin und her?

Schlumpf schrieb:

> Also bitte Küchle, wer von uns beiden springt hier hin und her?

Vorschlag zur Güte: Beide!

MfG,

BTW: Beiträge sind verständlicher wenn man statt Simualtion exakt
Verhaltens-/Post-Synthese/ etc schreibt. dann braucht man keinen kontext 
bemühen um zu verstehen worauf sich die Aussage nun bezieht.

Fpga Kuechle schrieb:
> Vorschlag zur Güte: Beide!

Darauf kann ich mich einlassen ;-)

Und mit deinem Vorschlag hast du recht. Wäre vielleicht gescheit 
gewesen, wenn man in diesem Zusammenhang immer explizit ausdrückt, auf 
was man sich bezieht. Das macht es zumindest den Lesern leichter, die 
nicht die ganze Zeit aktiv an der Diskussion beteiligt waren.
Guter Vorschlag!

Myxo Matrose schrieb:
> Schlumpf schrieb:
> Wenn du der Meinung bist, dass in dem geschilderten Fall "BUSY" nur eine
> Alias für "1" ist, dann glaub das einfach.
>
> Ich glaube dem Simulator, nicht einem Individuum mit blauer Zipfelmütze
> ;-).

Schlümpfe haben keine blaue Zipfelmütze...

Matthias schrieb:
> Schlümpfe haben keine blaue Zipfelmütze...

Der Exekutive-Schlumpf schon :-)

http://de.wikipedia.org/wiki/Polizeiuniform_%28Deutschland%29#mediaviewer/File:HH_Polizeihauptmeister_MZ.jpg