FSM größe abschätzen

[hugo (Gast)]

Hi Leute,
ich möchte für eine RS485 Schnittstelle das komplette Protokoll in die 
FPGA-Hardware auslagern. Also Adresse senden.. Befehl senden... Antwort 
einlesen. Und das mit verschiedenen Befehlen, und verschieden langen 
Antworten.
Wie kann ich am besten abschätzen, wie viele Register und LUTs ich dafür 
verschwende?
Gibt es irgendwie eine Formel mit der ich die Anzahl der Register 
bestimmen kann wenn ich eine FSM aufbaute, mit so uns so viele Eingänge, 
Ausgänge und Zustände?
Ob das sinn macht oder nicht, sei mal dahingestellt, brauche nur eine 
Abschätzung...
mfg michi

[Level up (Gast)]

kommt auf die FSM codierung an. aus hist. Gründen verwendet man oft 
One-Hot. Dort gilt Anzahl der FF für Zustandsvektor = Anzahl der states 
= Anzahl Fanin, Ausgangskombinatorik.

Bei nicht so verschwenderischen Codierungen wie sequential,binary,gray
gilt Anzahl der FF = aufgerundeter log dualis (anzahl Zustände)

also:

Zuständen   FF
5- 8         3
9-16         4
17-31        5

etc.

MfG,

[hugo (Gast)]

Bei one-hot, spare ich mir die Vergleichslogik in jedem Zustand. Also 
für jeden Zustand 1 FF.

Ich hab ausgerechnet:
77 Register für die Eingangsdaten
46 Register für die Ausgangsdaten

19 Zustände.

Dann komme ich auf insgesamt 142 Register.

Kann ich auch abschätzen wie viel LUTs ich für die Kombinatorik 
verbrauche?

[lkmiller (Gast)]

>Kann ich auch abschätzen wie viel LUTs ich für die Kombinatorik verbrauche?
Einfach mal Synthetisieren. Das gibt schon recht gute Zahlen ;-)
Das Schätzen ist müßig, denn da brauchts dann hinterher noch ein paar 
FFs für irgendwelche Baudratenteiler, Wait-Cycles, Flags, usw, usf..., 
wer weiß das vorher schon.

Also: Nicht so viel rechnen, einfach entscheiden.
Es gibt so viele Protokoll-Controller auf FPGA-Basis, die können nicht 
alle falsch entschieden haben.

Schon ein kleines Lattice-MachXO FPGA für 5$ hat >600 FFs, und die sind 
pinkompatibel nach oben.
Eine Faustregel ist es, bei FPGAs nicht mit Registern zu sparen, da sind 
sowieso zuviele da. Am ehesten klemmt es bei der Logik, aber da kann man 
die Tools schon mal etwas quälen, und die bekommen auch bei einem 99% 
vollen Design ohne weiteres noch Änderungen unter.

[Alter Rammler (Gast)]

>Eine Faustregel ist es, bei FPGAs nicht mit Registern zu sparen,

Das stimmt nur bedingt:
 Beitrag "parallel -> seriell: Schieberegister oder Multiplexer?"

Ferner sind bei einigen FPGA-Architecturen FF und LUT (Kombinatorik) in 
einem Grundelement (Slice) kombiniert, was nicht selten dazu führt das 
man nur eins von beiden benutzen kann, aber beide "verbraucht" (related 
Logic bei Xilinx). Ebenso kann man bei einem falschen Reset (asynchron 
bei Spartan3) gleich zwei LUT nebenher verbraten. Besser wirklich nur 
das einzubauen, was wirklich benötigt wird und nicht FF oder LUT's 
zählen sondern Logigelemente (Xilinx:Slice; Altera: LE (?))

[Alter Rammler (Gast)]

<Bei one-hot, spare ich mir die Vergleichslogik in jedem Zustand. Also
<für jeden Zustand 1 FF.

Unbedingt austesten, nach meinen Erfahrungen ist OneHot oft größer als 
Binary (Xilinx: Spartan2-3E,Virtex5). Aber vielleicht ist das auch vom 
Synthesetool abhängig.