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; ---------------------------------
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
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
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.
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.
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.
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.
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 ;-).
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 :-)
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...
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..
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
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...
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
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: > 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?
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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.