Multicycle MIPS FSM

Du versuchst wohl gerade, eine FSM mit einem Befehl zu identifizieren, 
der von einer Stufe zur nächsten wandert und denkst dir diese Stufe als 
Zustand. Aber das wäre der Zustand eines Befehls, keiner Maschine oder 
Stufe. Gleichzeitig denkst du dir Pipelining dazu.

Das Beispiel passt dazu. Diese FSM beschreibt den Ablauf eines 
Multicycle-Befehls in einer Maschine ohne Pipelining. Sie ist damit aber 
nicht in der Lage, eine Maschine zu steuern, deren Pipeline mehrere 
Befehle gleichzeitig in unterschiedlichen Pipeline-Stufen zulässt.

Worum geht es also? Mit oder ohne Pipelining? Multicycle impliziert ja 
nicht automatisch Pipelining.

Mit Pipelining kannst du zwar theoretisch Befehlsabläufe über FSMs 
modellieren, aber damit keine Maschine steuern. Weshalb das nur 
umgekehrt geht, also FSMs der Pipeline-Stufen sich letztlich die Befehle 
durchreichen.

GinTonic schrieb:
> Multicycle bedeutet ja, dass mein Datenpfad zerlegt wird.
> Damit würde ein Befehl z.B. 5 kürzere Takte brauchen statt einen langen.

Korrekt. Aber ohne Pipelining ist die Maschine stets nur mit einem 
Befehl beschäftigt und die Komponenten der Maschine sind die meiste Zeit 
arbeitslos. Der Abstand zweier Befehle entspricht damit der Anzahl 
Zyklen eines Befehls.

> Und Pipelining bedeutet, dass möglichst in jedem Takt ein neuer Befehl
> angefangen wird?

Richtig. Erst damit werden die Komponenten effektiv ausgelastet und die 
Latenz aufeinanderfolgender Befehle kann sich auf einen Zyklus 
reduzieren. Nur hast du dann Abhängigkeiten entweder zu berücksichtigen 
- oder musst sie MIPS-typisch einfach wegdefinieren.

> Dann brauche ich für Pipelining mit x Stufen auch x FSMs oder?

Ohne das in dieser Form jemals modelliert zu haben würde ich das schon 
so sehen. Wobei man das auch als eine Art hierarchische FSM betrachten 
kann, die aus einzelnen Unter-FSMs besteht. Weiss nicht, wie man das 
offiziell betrachtet.