FPGA state machine

Und was hilft mir deine infantile Aussage?

Gordon N. (Gast)
>Ich will mal wissen ob das nur bei mir so ist aber bisher enden meine
>FPGA VHDL Projekte immer damit state machines zu erstellen. Wieso nicht
>einen Prozessor verwenden? Die paar Rechenoperationen mache ich dann mit
>Pipelines.

Bei mir läuft das auch so ähnlich. Ich habe schon ein wenig mit 
Softcores experimentiert, aber die brauchen oft zu viel Resourcen. 
Besser ist es, wenn man sich mit der Statemachine eine Grundlage für 
einfache, selbstgebaute Softcores erstellt. Dann kann man nur speziell 
die Befehle einbauen, die man braucht. Zusätzlich ist noch ein einfacher 
Assembler z.B. mit Python nützlich, damit man die Opcodes nicht von Hand 
erstellen muss.
Auch nützlich ist es, standardmässig einen SPI-Schnittestellenblock zu 
haben, um einfach debuggen zu können.

Gordon N. schrieb:
> Wieso nicht
> einen Prozessor verwenden?

Warum keine Tunnelbohrmaschine verwenden, um eine Schraube in die Wand 
zu drehen? Statemachines sind das Mittel der Wahl, um digitale 
Schaltungen zu steuern. Wenn du jede Statemachine im FPGA durch einen 
Prozessor ersetzen willst, explodiert das FPGA-Design vor lauter 
nutzloser Logik. Ein Prozessor braucht Speicher, Software, ein 
Rechenwerk und noch eine Menge anderes Zeug. Eine Statemachine braucht 
nur ein Register und ein oder zwei Schaltnetze, und sie tut mit 
minimalem Aufwand genau das, was sie soll.

> Die paar Rechenoperationen mache ich dann mit
> Pipelines.

Welche paar Rechenoperationen? Eine Statemachine macht keine 
Rechenoperationen, sie erzeugt Sequenzen von Steuersignalen in 
Abhängigkeit von den Eingängen. Ich habe den Eindruck, du hast nicht 
ganz verstanden, was eine Statemachine ist und wozu sie gut ist.

Bei mir sind auch immer ein Menge State-Machines drin. Das ist einfach 
die Basis, wenn man zeitliche Abhängigkeiten hat.

Wenn es zu kompliziert, dann hänge doch einfach einen kleinen Prozessor 
dran. Und mache die Dinge dann dort, wo es passender ist.

Alternativ gibt es Softcores oder SOCs. Alles eine Frage des Aufwandes 
und Preises.

Christoph Z. schrieb:
> Und wie strukturierst du dann deine Software, damit sie lesbar und
> wartbar bleibt? Genau, oft schreibt man da auch wieder State Machines
> :-)

Guter Einwand, aber im Endeffekt programmiert man implizit auch dann 
eine Statemachine, auch wenn die Software unlesbar und unwartbar ist :-) 
Also die FSM nach den bekannten Entwurfsmethoden direkt in Hardware zu 
bauen ist der effizienteste Weg.