Hallo Forum,
Ich probiere, meine State Machine vernuenftig durchzutesten. Die State
Machine selbst ist als Typ definiert:
1
typeT_AUTO_GATING_STATESis
2
(
3
state1,
4
state2,
5
state3,
6
state4
Bei der Implementierung der State Machine ist es ja nunmal von vorteil,
statt nur der 4 definierten Faelle auch alle undefinierten Faelle
abzufangen, durch Verwendung des "when others =>" (im falle eines case).
Nun die Frage: Ich will natuerlich testen dass die State machine sich
vorschriftsmaessig wieder faengt wenn sie im OTHERS state ist,
allerdings kann ich diesen Fehlerfall ja schlecht herbeisimulieren. Ich
dachte daran, in Modelsim via FORCE die state machine auf einen nicht
definierten Zustand zu setzen, was aber scheinbar nicht wirklich
hinhaut. Ich dachte an sowas wie
force sim:/top_level/entity/sub_entity/signal_of_state_machine others
100 ms
sodass Modelsim die state machine nach 100 ms Simulation eben in
besagten OTHERS zustand zwingt, was aber nicht geht, da
Error: (vsim-4026) Value "others" does not represent a literal of the
enumeration type.
Hat da jemand eine Idee wie man das machen kann?
Danke
Ich weiss nicht, ob das geht.
Ich hatte mal den Fall, da kam der State wirklich in einen
"Others"-Fall.
Das kam durch Metastabilität am Eingang, den ich nicht sauber abgefangen
hatte.
Das System kam dann aber nie wieder aus dem "Others"-Fall heraus, trotz
einer
State <= Reset
Anweisung.
Von daher bin ich sehr vorsichtig mit dem when others Fall, weil der
nicht so funktioniert hat, wie z.B. der switch() default: in C
Ich meine auch, man kann es so nicht testen.
Bei meinem Problem damals gab es sogar Unterschiede, wenn ich das für
eine Altera und einen Xilinx (jeweils mit den Herstellertools)
synthetisiert habe.
bsp: deine Statemachine würde one-hot codiert werden bei der Synthese.
dann müsste es für alle 12 nichtgenutzten Fälle eine Schaltung geben die
wieder resettet.
Das wird meines Wissens nach aber nicht automatisch synthetisiert, wenn
dieser Zustand nicht auch irgentwo erreicht wird.
Stattdessen sind dann 2 Zustände aktiv und man kann nur hoffen das sich
dies wieder selbst fängt.
Würde mich aber auch interessieren wie man den Fall testen kann, vor
allem jedoch in der Hardware.
Matthias schrieb:> Bei der Implementierung der State Machine ist es ja nunmal von vorteil,> statt nur der 4 definierten Faelle auch alle undefinierten Faelle> abzufangen, durch Verwendung des "when others =>" (im falle eines case).
Du verwechselt Modell und Implementierung.
Bei der Simulation mit ModelSim kann eine Variable vom Type
T_AUTO_GATING_STATES nur genau einen dieser 4 Zustände annehmen, es gibt
also wirklich keine others.
Wird das ganze in Hardware umgesetzt, dann macht die Synthese daraus
einen Vektor von Bits. Je nach Codierung, die der Compiler verwendet
(One-Hot oder Binary) können das 4 oder 2 bits sein.
Im Falle von Binary gibt es in diesem Fall wieder keine überflüssigen
Codes, weil man mit 2 Bit genau 4 Zustände abbilden kann. Hättest Du 5
States, dann schaut die Welt schon anders aus ...
Wählst Du oder der Compiler One-hot Kodierung, dann wird der
Zustandsvektor auf 4 Bits abgebildet, in diesem Fall gibt es ungültige
Zustände im implementierten System.
Du kannst dies alles aber nicht mit ModelSim vorher testen, weil dein
Modell noch nichts von der späteren Umsetzung weiss.
Ein sicheres Verhalten der implementierten FSM kann man nur erreichen,
indem man den Compiler durch Optionen anweist, zusätzliche Logik zum
Erkennen ungültiger Zustände zu generieren und dann einen sicheren State
anzuspringen.
PS : Das ist nicht das selbe, wie das Einfügen eines when others Pfades.
Auch für den Compiler hat Dein Type nur genau 4 Zustände.
Klaus und Lothar:
Vielen Dank fuer die Erklaerung. Das hab ich noch nicht gewusst, klingt
soweit aber logisch. Dann kann ich mir das in Modelsim ja sparen und
fuer die Synthese schau ich mir dann die entsprechenden Texte an.
Vielen dank!
Wenn es um die Simulation eines Störfalls geht, könnte man von einer
anderen Stelle das Signal fremdsetzen, um ein UUUU / XXXXX zu
generieren, sodass sich die fsm verlaufen kann.
Ratgeber schrieb:> sodass sich die fsm verlaufen kann.
Eine FSM mit x Zuständen, die alle mit case abgefragt werden, kann sich
in der Simulation nicht verlaufen. Bzw wird sie sich in der Simulation
garantiert anders "falsch verhalten" als in der Realität. Denn die
Simualtion kümmert sich nicht darum, WIE die FSM realisiert wird (One
Hot, Gray, Binär, Sicher...).
Von daher ist es m.E. eigentlich sinnlos, einen Fall zu simulieren, der
nie auftreten kann...
abc schrieb:> bsp: deine Statemachine würde one-hot codiert werden bei der Synthese.>
...
> Würde mich aber auch interessieren wie man den Fall testen kann, vor> allem jedoch in der Hardware.
Post-synthesise: Simulation der backannotierten Synthese Netzliste. Der
projektnavigator von Xilinx sollte im Process-fenster die Option
"Post-synhtesis simulation" anbieten.
Backannotierung ist hier kurz erklärt:
http://www.xilinx.com/itp/data/alliance/dev/dev15_1.htm
MfG,
Thread beobachten
Seitenaufteilung abschalten