Forum: FPGA, VHDL & Co. Wie kann man diese State mal erklärend schreiben?


von peter (Gast)


Lesenswert?

Hallo, guten Tag.
Wer kann mir mal diese State erklären mit einer offenen Beschreibung?

Danke.
Gruss

--------------------------------
type rx_state_t is (IDLE, BUSY, READY);
signal rx_state : rx_state_t := IDLE;
---------------------------------

von Myxo M. (myxom)


Lesenswert?

IDLE = 0
BUSY = 1
READY = 2


signal rx_state : rx_state_t := IDLE;
Vorbelegen der Variable mit '0'.

in Pascal: typisierte Konstanten

: Bearbeitet durch User
von peter (Gast)


Lesenswert?

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

von Myxo M. (myxom)


Lesenswert?

peter schrieb:
> Die Reihenfolge in der Klammer bestimmt den Wert?

Yep.

von peter (Gast)


Lesenswert?

Danke.

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

Danke.

von daniel__m (Gast)


Lesenswert?

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

von Myxo M. (myxom)


Lesenswert?

Danke @daniel_m, du hast es akademisch wie die Bundesregierung erklärt.

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.

von Schlumpf (Gast)


Lesenswert?

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.

von Myxo M. (myxom)


Lesenswert?

Schlumpf schrieb:
> nur
> die Werte IDLE, BUSY, READY annehmen kann

Und wie bitte drückst du das aus? Eine numerische Maschine kann die 
Wörter lesen? Ein Sprachprogramm vielleicht.

Typisierte Konstanten sind nur eine Vereinfachung für den Programmierer, 
dessen Vorteil du offensichtlich noch nicht inhaliert hast.

von Schlumpf (Gast)


Lesenswert?

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.

von Myxo M. (myxom)


Lesenswert?

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

von Schlumpf (Gast)


Lesenswert?

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

von Myxo M. (myxom)


Lesenswert?

Schlumpf schrieb:
> Exakt. Und wenn du dann mal in deinen Simulator schaust, wird da
> drinstehen, dass rx_state den Wert IDLE oder BUSY hat.
In ISE 10.x kann man beobachten, dass die Zustände mit ihren definierten 
Namen benannt werden.
Das ist offensichtlich, wie auch in Turbo Pascal, dem guten 
Debugging-Interpreter zu verdanken.

> Es wird aber nicht drinstehen, dass rx_state den Wert 0 oder 1 hat.
Nichtsdestotrotz werden typisierte Konstanten letztendlich als 
numerische Werte verarbeitet, egal ob µC oder logic array.
Verzeih mir, dass ich zu tief eingestiegen bin.

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

Tauch' dein Schrubber mal in 'Hohes-C' - dann wird alles gut...

von Schlumpf (Gast)


Lesenswert?

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

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


Lesenswert?

Myxo Matrose schrieb:
> In ISE 10.x kann man beobachten, dass die Zustände mit ihren definierten
> Namen benannt werden.
Es ist in jedem Simulator schon immer so.
> Das ist offensichtlich, wie auch in Turbo Pascal, dem guten
> Debugging-Interpreter zu verdanken.
Nein. Es ist der Definition des Datentyps zu verdanken.
Natürlich beginnt die Enumeration links mit 0 und natürlich arbeitet der 
Simulator intern mit irgendwelchen Indices, aber wie das Ganze letztlich 
in Hardware umgesetzt wird, ob binär (wie oben vermutet) oder One-Hot 
oder Gray oder..., das sollte man am bestem dem Synthesizer überlassen.

Und wenn der Synthesizer die Zustände z.B. One-Hot codiert:
IDLE  = "001"
BUSY  = "010"
READY = "100"
Dann ist es sehr gut, dass der Simulator nicht die Enumerationwerte 
anzeigt. Denn 0,1 und 2 passen da gar nicht mehr mit 001, 010 und 100 
zusammen.

Siehe auch dort:
http://www.lothar-miller.de/s9y/categories/37-FSM

> Das ist offensichtlich, wie auch in Turbo Pascal, dem guten
> Debugging-Interpreter zu verdanken.
Sieh dir mal die Definition des Datentyps std_logic an. Dort werden 
schon immer in jedem Simulator die Werte U,X,Z,0,1... angezeigt, und 
nicht ihre Enumerationwerte 0..8
Und weil der Simulator das mit dem std_logic schon so macht, dann macht 
er es mit jedem anderen auf die selbe Art definierten Datentyp auch so.

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

> Verzeih mir, dass ich zu tief eingestiegen bin.
Immerhin hast du jetzt auch noch was gelernt.

: Bearbeitet durch Moderator
von berndl (Gast)


Lesenswert?

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

von Schlumpf (Gast)


Lesenswert?

Danke Lothar ;-)

von Myxo M. (myxom)


Lesenswert?

Lothar Miller schrieb:
>> Das ist offensichtlich, wie auch in Turbo Pascal, dem guten
>> Debugging-Interpreter zu verdanken.
> Nein. Es ist der Definition des Datentyps zu verdanken.
> Natürlich beginnt die Enumeration links mit 0

Danke Lothar.
Ich kenne die Auswirkungen derariger Hilfskonstrukte.
Bin ein alter Pascaliner :-)
Ich weiß, dass die Jungs von Borland die namentliche Enumration 
eingeführt haben, um dem Programmierer ihre Arbeit zu erleichtern. Schön 
ist das z.B. in CASE-Abfragen.

Lothar Miller schrieb:
> Immerhin hast du jetzt auch noch was gelernt.

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.

: Bearbeitet durch User
von Schlumpf (Gast)


Lesenswert?

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

von berndl (Gast)


Lesenswert?

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?

von Fpgakuechle K. (Gast)


Lesenswert?

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,

von Fpgakuechle K. (Gast)


Lesenswert?

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,

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


Lesenswert?

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?

von Schlumpf (Gast)


Lesenswert?

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?

von M.O. (Gast)


Lesenswert?

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

Falsch
Der Compiler wird eine Fehlermeldung schmeißen.

von Fpgakuechle K. (Gast)


Lesenswert?

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,

von Fpgakuechle K. (Gast)


Lesenswert?

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,

von Schlumpf (Gast)


Lesenswert?

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

von Fpgakuechle K. (Gast)


Lesenswert?

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,

von Schlumpf (Gast)


Lesenswert?

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.

von Fpgakuechle K. (Gast)


Lesenswert?

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,

von Fpgakuechle K. (Gast)


Lesenswert?

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,

von Schlumpf (Gast)


Lesenswert?

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.

von Fpgakuechle K. (Gast)


Lesenswert?

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,

von Schlumpf (Gast)


Lesenswert?

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.

von Fpgakuechle K. (Gast)


Lesenswert?

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,

von Schlumpf (Gast)


Lesenswert?

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?

von Fpgakuechle K. (Gast)


Lesenswert?

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.

von Schlumpf (Gast)


Lesenswert?

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!

von Matthias (Gast)


Lesenswert?

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

von Schlumpf (Gast)


Lesenswert?


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.