VHDL Richtlinien

P. K. schrieb:
> Feel free!

Schön gesagt :-) Wer sollte das auch verbieten (es sei denn man hat 
firmeninterne Codingrichtlinien).

Mit Zustandsautomat ist aber eigentlich eher was verzweigtes gemeint und 
dann auch etwas komplizierter. Unterschiedliche Aufgaben gruppiert man 
immer in unterschiedlichen Prozessen. Auch der Optimierung der 
Simulation wegen.

Wenn sie aber eng zusammen hängen, fragt man sich wozu 2 FMs gebaut 
werden und nicht eine?

Mark schrieb:
> Hallo Zusammen,
> darf man zwei Zustandsautomaten in dem selben Process verwenden?

Man kann sogar das gesamte design in einen einzigen process schreiben 
(solange man nur einen Takt und evtl. reset hat), das ist aber keine 
gute Idee. Oft wird sogar schon eine einzelne fsm auf zwei process oder 
mehrere Processe aufgeteilt.

Früher hatten die Synthesetools Probleme bei großen FSM's mit Zählern, 
da ging ihnen der Arbeitsspeicher beim Optimieren aus. Da hat man wohl 
versucht alle FF in einem process auf einmal zu optimieren.
Mglw. setzt auch der Synthese style guide deines Tools Grenzen.

Gegenfrage, was ist der Vorteil mehrere FSM in einem Process zu 
schreiben?

MfG,

Lothar Miller schrieb:
> Dort sind auch zwei FSM verschachtelt. Das basiert auf dem

Das wäre aus meiner Sicht EINE zusammengehörige FSM und daher noch 
sinnvollerweise zusammen zu schreiben. So ist es auch nach unseren 
internen Coding Vorgaben geregelt.

Aber Dinge die nichts mit andender direkt zu tun haben gehören 
auseinander. Die FSM werden bei uns auch in den Dokumenten bezeichnet, 
nummeriert und beschrieben - samt Ablaufdiagramm

Lothar Miller schrieb:
> Wie ist das dann mit em besagten Zähler, der nach 100 Takten einen
> Zustand weiterschaltet? Der müsste dann konsequenterweise auch
> auscodiert werden und die "eine" FSM 100 Zustände mehr bekommen...

Kann ich mithalten... Eine Sensornachbildung (Sensor hat natuerlich 
einen kleinen uC im Package). Die 1. FSM hat jetzt mal ganz grob das 
Verhalten (auch bei PON) nachgebildet. Dann der Teil wenn das Ding mal 
laeuft: Die Opcodes. Innerhalb dieser Opcodes dann noch Pipelining...

Wenn man sich das dann mal ganz genau ueberlegt, dann strukturiert man 
das in eine FSM. Und damit haben:
* Alle Aktionen eines Opcodes, und
* Die Steuerung der FSM
jeweils auf eine Bildschirmseite gepasst (es waren eine ganze Menge 
Opcodes).

Haette ich das in getrennte Prozesse ausgelagert, dann haette ich wohl 
2x woechentlich die PageUp/Down Tasten auswechseln muessen...

Ich denke: Es kommt halt immer darauf an... (was jetzt gerade sinnvoll 
ist, und ja, manchmal macht dann umschreiben auch Sinn)

Vielen Dank für eine bereitschaft zum Helfen. Ich muss 2 FSMs nehmmen, 
weil der 1. FSM mit einem Clock-Enable arbeite muss und der andere muss 
ohne.

Mark schrieb:
> Vielen Dank für eine bereitschaft zum Helfen. Ich muss 2 FSMs nehmmen,
> weil der 1. FSM mit einem Clock-Enable arbeite muss und der andere muss
> ohne.

Notiz für nächste Revision Codierstyle:

FSM's mit unterschiedlichen CE an State-FF nicht in einem gemeinsamen 
Prozess kapseln.

MfG

kannst du mir sagen, warum darf ich das nicht tun?

Mark schrieb:
> kannst du mir sagen, warum darf ich das nicht tun?

Du darfst es. Es trifft nur nicht Fpga Kuechles persönlichen Geschmack 
(und möglicherweise den von anderen auch nicht). Es geht also nur um die 
Frage, was andere und du selber als übersichtlich und gut lesbar 
empfindest.

Olga schrieb:
> Mark schrieb:
>> kannst du mir sagen, warum darf ich das nicht tun?
>
> Du darfst es. Es trifft nur nicht Fpga Kuechles persönlichen Geschmack
> (und möglicherweise den von anderen auch nicht). Es geht also nur um die
> Frage, was andere und du selber als übersichtlich und gut lesbar
> empfindest.

Moin,

mit Empfindung und Geschmack hat das weniger zutun als mit persönlicher 
Erfahrung. Mit dem richtigen codestyle tretten weniger Fehler auf oder 
werden schneller gefunden und dritte können sich schneller darin 
zurechtfinden.

Hier konkret:

1) Ein If über ein längliches case construct wird leicht übersehen und 
hier gibt es ZWEI längliche case: eins mit und eins ohne ce-IF. Da sind 
Verständnissfehler vorprogrammiert.

2) ce-fsm sind Fehleranfälliger als fsm die jeden Takt weiterschalten:
 Bei ersten genügt es das das Eingangssignal kürzer als die ce-periode 
ist um nicht sicher gesehen zu werden -und so verlorengeht.

Folglich muss man bei jeden Einganssignal sicherstellen das es lang 
genug aktiv ist. Einen vollständigen Test darauf erreicht man in dem man 
diese ce-fsm in eine eigene Entity "kapselt" und deren fsm eingänge (die 
die die zustandsübergange triggern) per assert überwacht. Bei einer 
Mischform "verpasst" man schon ein signal das dann ungünstigerweise aus 
der nicht-ce domain kommt und kürzer als die ce-periode ist. Das führt 
dann je nach Phasenlage zu Zustandswechsel oder nicht.
Kritische Stellen immer vollständig identifizieren und angepasst testen.


3) Die Abfolge der if elsif end if bestimmt bspw. bei Xilinx ob das FF 
otpimal genutzt wird, also auch R und S input und nicht nur D u. CE. Bei 
einer Mischform (die ce-fsm wird aud ce-FF) aufgebaut ist das nicht 
unbedingt gegeben, die Syntheserealisierung kann also langsamer sein als 
nötig.
 Siehe 
http://www.xilinx.com/support/documentation/white_papers/wp275.pdf


Wie olga schon bemerkte, man kann verschiedene FSM in einen process 
packen, aber nach meiner Erfahrung schiesst man sich dabei selbst ins 
Knie.

MfG,