Hallo,
ich habe eine Verständnissfrage und hoffe das mir die jemand beantworten
könnte. Ich habe ein Flashscontroller geschrieben der auch funzt, wollte
es jetzt erweitern und bin auf ein Problem gestoßen.
Ich habe einen Zustandsautomat hier ein Ausschnitt:
Meine Frage wie kann ich mich auf den Vorherigen Zustand beziehen, bzw.
was müsste ich tun um im Zustand Warten_0 zu schauen ob ich vom
Grundzustand oder vom Add_Zahlen Zustand gekommen bin?
Gruß
Igor
Bei deiner FSM werden die Ausgangssignale Kombinatorisch erzeugt.
Das kann Glitsches geben, was eventuell stört wenn die Signale nach
außen gehen.
Du kannst die Signale auch in den getakteten Prozess hineinziehen, dann
fällt auch das Zwischensignal mit dem alten Zustand weg.
Lothar Miller schrieb:
> Der logische nächste Schritt wäre dann die 1-Prozess-Schreibweise> ..> Die hat auch noch andere Vorteile gegenüber der 2- oder gar> 3-Prozess-Schreibweise ;-)
.. und den Nachteil, dass die Ausgangssignale zum State jeweils 1 Takt
verzögert sind ;-)
> .. und den Nachteil, dass die Ausgangssignale zum State jeweils 1 Takt> verzögert sind ;-)
Naja, das was in der SM auscodiert ist, wird vor dem Takt ausgewertet
und mit der Taktflanke aktualisiert (wie bei FFs halt so üblich). So
kommt ein 2-Prozess-Denker natürlich schlagartig an 1 Takt Latency...
> .. und den Nachteil, dass die Ausgangssignale zum State jeweils 1 Takt> verzögert sind ;-)
Dafür aber garantiert glitchfrei ;-)
@ Lothar Miller
Die 2-Prozess-Schreibweise hat aber noch einen anderen Vorteil. Man kann
den Next_State nutzen um z.B. RAM-Blöcke zu adressieren. So kann man
schon im nächsten Schritt auf dessen Daten zugreifen ohne einen
Wartetakt zu benötigen. Das beschleunigt das ganze in zeitkritischen
Applikationen.
> So kann man schon im nächsten Schritt auf dessen Daten zugreifen> ohne einen Wartetakt zu benötigen.
Für mich wird andersrum ein Schuh draus: In der 1 Prozess-Schreibweise
bereite ich schon bei der Zustandstransition (also genau eine Taktflanke
früher) die Adresse vor.
> Das beschleunigt das ganze in zeitkritischen Applikationen.
Wenn ich 3 Taktzyklen Zeit habe, um etwas zu tun, dann sind das 3 Takte,
ob ichs mit 2 oder 1 Prozess beschreibe...
Ich bin kein Gegner der 2-Pozess-Schreibweise, mir fällt nur die
1-Prozess-Darstellung leichter... ;-)
Mir faellt eigentlich immer nur ein Fall ein, in dem die
Mehrprozessschreibweise Vorteile hat:
- Deine FSM Ablaufsteuerung ist relativ einfach, aber die notwendige HW
pro State ist recht kompliziert oder komplex. Ein eigener Prozess kann
dann die komplizierte oder komplexe Logik etwas 'entwirren' und
verstaendlicher machen.
Beispiel: Eine FSM die mehr oder weniger geradeaus laeuft, aber z.B.
viele verschiedene Opcodes bzw. Funktionen hat. Dann kann es manchmal
sehr angenehm sein, wenn du die eigentliche Logik auf eine
Bildschirmseite bringst. Auch wenn du dafuer z.B. Decoder mehrfach
hinschreiben musst. Die Mehrfachdekoder werden i.A. sowieso
rausoptimiert, also kein Problem mit der Laufzeit. Aber bei Aenderungen
bist du halt immer an mehreren Stellen im Code unterwegs. Und da
vergisst man bei komplexeren Sachen gerne mal eine Stelle... Und ja, man
kann bei solchen verschachtelten Sachen auch in 1-Prozess Schreibweise
durch umschreiben (andere Reihenfolge der 'case' Statements) eine
zumindest optische Vereinfachung erreichen. Solange es die Tools
packen......
> Ich bin kein Gegner der 2-Pozess-Schreibweise, mir fällt nur die> 1-Prozess-Darstellung leichter... ;-)
Meist nutze ich die 2-Prozess-Darstellung. Der größte Nachteil dabei ist
sicherlich alles konsisten zu halten. Vor allem die Sensitivitylist kann
schon mal sehr unübersichtlich werden und bedarf großer Disziplin in der
Pflege.
> ... In der 1 Prozess-Schreibweise> bereite ich schon bei der Zustandstransition (also genau eine Taktflanke> früher) die Adresse vor.
Keine Frage. Geht wunderbar. Um beim Beispiel zu bleiben: So lange die
Adressbildung innerhalb des FSM-Prozesses abgehandelt wird, ist das dann
noch leserlich. Kleine Statemachines sind sicherlich in der 1
Prozess-Schreibweise übersichtlicher. Sobald aber eine gewisse
Komplexität überschritten wird und die Adressbildung in einem anderen
Prozess landet wird es sehr unübersichtlich. Beispiel: