Moin, ich hab ne kurze Frage zur Beschreibung von FSMs. Angenommen ich habe vier Zustände S0 bis S3. Sollte man dann in einem case(state) die Zustände S0 bis S3 explizit auswerten (Variante 1) oder S0 bis S2 explizit und S3 über ein 'others' abfangen (Variante 2)? Könnte es nicht bei Variante 1 zu dem Fall kommen, dass ein Bitkipper im Zustandsregister in einen 'illegalen' Zustand führt? In Variante 2 müsste dieser Fall ansich abgefangen werden, allerdings müsste der Ressourcenbedarf leicht ansteigen.
O_o schrieb: > Könnte es nicht bei Variante 1 zu dem Fall kommen, dass ein Bitkipper im > Zustandsregister in einen 'illegalen' Zustand führt? Dann gibt es ganz andere Probleme.
aehm, was von deiner in einer HDL beschriebenen FSM uebrig bleibt bestimmen ueblicherweise die Synthesetools... (einfach mal den Report dazu mal genau durchlesen, du kannst ja auch Einstellungen in deiner Toolchain vorgeben)
O_o schrieb: > Sollte man dann in einem case(state) die Zustände S0 bis S3 explizit > auswerten (Variante 1) oder S0 bis S2 explizit und S3 über ein 'others' > abfangen (Variante 2)? Wenn dein Typ genau mit den Zuständen s0..3 definiert ist, und du alle vier möglichen Zustände in der FSM abfrägst, gibt es keine "anderen" Zustände mehr, die mit "when others" abgefragt werden könnten: http://www.lothar-miller.de/s9y/categories/25-when-others ABER ACHTUNG Wie diese FSM mit 4 Zuständen realisiert wird, steht auf einem ganz ANDEREN Blatt, nämlich in den Syntheseeinstellungen. Dort kannst du z.B. One Hot, Binär, Gray, oder sonst ein Encoding auswählen. Und dann gibt es in der realen Hardware (=CPLD, FPGA) durchaus noch andere Zustände: in diesem Fall bei One Hot mit 4 Bits also 12 undefinierte Bitkombinationen (alles, wo mehr als 1 Eins gesetzt ist). Und du kannst solche ungültigen Zustände dann auch ganz einfach erreichen, z.B. über nicht synchronisierte Signale, die direkt in die FSM gehen: http://www.lothar-miller.de/s9y/archives/64-State-Machine-mit-asynchronem-Eingang.html
Lothar Miller schrieb: > ABER ACHTUNG > Wie diese FSM mit 4 Zuständen realisiert wird, steht auf einem ganz > ANDEREN Blatt, nämlich in den Syntheseeinstellungen. Dort kannst du z.B. > One Hot, Binär, Gray, oder sonst ein Encoding auswählen. Und dann gibt > es in der realen Hardware (=CPLD, FPGA) durchaus noch andere Zustände: > in diesem Fall bei One Hot mit 4 Bits also 12 undefinierte > Bitkombinationen (alles, wo mehr als 1 Eins gesetzt ist). Und du kannst > solche ungültigen Zustände dann auch ganz einfach erreichen, z.B. über > nicht synchronisierte Signale, die direkt in die FSM gehen: > http://www.lothar-miller.de/s9y/archives/64-State-... Der zweite Link ist wirklich interessant. Super erklärt! Mal angenommen alle Signale sind synchron, dann könnten doch Glitches trotzdem zu diesem Verhalten führen, oder?! Und wenn man dann in einem Zustand landet, der auf einen Handshake wartet ist Ende im Gelände. Demnach müsste jeder Zustand, der durch andere (externe) Signale weitergeschaltet wird mit einer Timeoutüberwachung versehen werden.
Wo sollen denn Glitches in einem synchronen Design herkommen? Da wird doch immer nur der (stabile) Zustand bei der nächsten Taktflanke ausgewertet. Da kommts höchstens zu komischen Zuständen, wenn die Taktfrequenz höher ist als das was die Logikstufen hergeben. Aber die Implementierungstools sagen dir bei richtigen Constraints schon, wenn es zu schnell wird.
Christian R. schrieb: > Wo sollen denn Glitches in einem synchronen Design herkommen? z.B durch kapazitive oder induktive Einkopplungen
Innerhalb des FPGA? Wenn das passiert, ist am gesamten Design bzw. an der Umgebung was grundlegendes falsch.
Naja, Bitkipper durch Strahlung sind auch auf der Erde möglich, wenn auch sehr selten.
Christian R. schrieb: > Wo sollen denn Glitches in einem synchronen Design herkommen? Natürlicht glitcht ein synchrones Design: jedesmal, wenn sich nach einem Takt der Pegel eines Flipflops ändert und eine passende Kombinatorik dahinter geschaltet ist. Aber das ist der Knackpunkt: Es wird > immer nur der (stabile) Zustand bei der nächsten Taktflanke ausgewertet. Kurz&bündig: bis zur nächten Taktflanke muss sich diese Glitcherei erledigt haben, denn sonst ist das Design zu übertaktet. Georg A. schrieb: > Naja, Bitkipper durch Strahlung sind auch auf der Erde möglich, wenn > auch sehr selten. Ja, sagen wir mal in homöopathischen Dosen. Wenn man Actel (jetzt Microsemi) glauben kann/will tritt das allerdings wesentlich häufiger auf... ;-) > Naja, Bitkipper durch Strahlung sind auch auf der Erde möglich Und dann kommt es immer noch darauf an, ob dadurch "nur" ein Datenbit umkippt (was auch in jedem RAM-Baustein passieren kann/wird) oder ob eine Konfigurationsspeicherzelle im FPGA umkippt und so z.B. eine fehlerhafte Verdrahtung erzeugt.
Georg A. schrieb: > Naja, Bitkipper durch Strahlung sind auch auf der Erde möglich, Da würde ich mir erst Sorgen drüber machen, wenn Deine Mimik am Reaktor sitzt, im Flugzeug fliegt oder auf dem Weg zum Mond ist. Duke
Thread beobachten
Seitenaufteilung abschaltenBitte 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.