Hallo Zusammen, ich bin dabei eine State Maschine mit VHDL zu programmiern. Jetzt stellt sich mir die Frage, gibt es irgendwelche Faktoren wann man Mealy und wann Moore verwendet, oder ist das reine Geschmacksache ? Was ist mit einer Mischung aus beidem ? Ist das üblich oder eher schlechter Programmierstil ? Und wenn ja, warum ? Gruß Krater
Mealy ist halt der allgemeinste Fall bei dem deine Ausgabe sowohl von der Eingabe als auch vom vorherigen Zustand abhängt. Bei Moore hängt deine Ausgabe ja nur noch vom aktuellen Zustand ab. Wenn du also beim Übergang in einen Zustand immer das selbe ausgeben würdest, egal wie die Eingabe war, dann Moore, sonst Mealy. Was meinst du genau mit Mischung aus beidem?
Deine Antwort hilft mir leider nicht viel weiter, der Unterschied ist mir schon bewußt, ich frag mich bloß obs einen Grund (z.B. Platzverbrauch oder größere Anzahl benötigter Takte) gibt bei dem man die eine Art Automat dem anderen bevorzugt. Hier ist das was ich mit Mischung meine: (Der Code hat natürlich keine sinnvoll angedachte Funktion) fsm:process(clk) begin if rising_edge(clk) then case state is when STATE1 => sig1<='0'; -- Moore if ls='1' then state<=STATE2; sig2<='1'; -- Mealy else state<=STATE1; sig2<='0'; end if; when STATE2 => sig1<='0'; sig2<='1'; state<=STATE3; when STATE3 => sig1<='1'; sig2<='0'; state<=STATE1; end process;
Also prinzipiell ist es egal wann du welche Art von Automaten benutzt, weil im prinzip kann man von der einen form zur anderen konvertieren. Beim Mealy Automatenbrauch man meistens aber weniger zustände um ein System zu beschreiben. Wohingehen der Mooreautomat leichter zum nachvollziehen ist. Also würde ich sagen, wenn du sehr wenig speicher (Zustände zur verfüghung hast solltest du zum mealyautomaten zurück greiffen, aber wenn du genug ressourcen zur verfüghung hast solltest du beruhigt zum mooreautomaten greiffen. Gruß BlabLa
> Jetzt stellt sich mir die Frage, gibt es irgendwelche Faktoren wann man Mealy und > wann Moore verwendet, oder ist das reine Geschmacksache ? Hängt i.A. vom jeweiligen Problem ab, welcher Automat besser passt. Faustregel: Die beste Lösung ist diejenige, die die Anforderungen erfüllt und am offensichtlichsten ist, d.h. am einfachsten zu dokumentieren. > Was ist mit einer Mischung aus beidem ? Mischung innerhalb von einem Automaten geht ja per Definition nicht. Der eine Automat so, der andere so: Ja, wenn dadurch der Code einfacher wird und immer noch die Anforderungen erfüllt. > Ist das üblich oder eher schlechter Programmierstil ? Und wenn ja, warum ? Frage 100 Entwickler zum Thema Programmierstil und du bekommst 200 Antworten von denen 250 nicht fundiert sind. Guter Programmierstil ist eine Wissenschaft für sich, in die man sich über viele Jahre reinarbeiten muss. In Bezug auf Moore/Mealy ist mir da keine einfache Aussage bekannt - deshalb empfehle ich o.g. "Default-Regel" zur Dokumentierbarkeit.
Ich würde gerne Morin zustimmen: Welchen Automatentyp man wählt, hängt in allererster Linie von den Anforderungen ab. Bei einem Moore-Automat gibt es numal per definitionem keinen kombainarorischen Pfad von den Eingängen zu den Ausgängen. Wenn man so einen Pfad braucht, dann Mealy, sonst Moore. Es gibt übrigens noch den Medwedew-Automat, und das ist mein persönlicher Favorit. Das Fehlen des Schaltnetztes nach dem Zustandsregister hat mir schon öfter beim Erreichen einer hohen Systemfrequenz geholfen.
Mealy hat eine geringere fmax. Da der Ausgang abhängig ist vom Eingang geht der Logikpfad beim Register vor der FSM los und hört beim Register nach der FSM auf. Ich versuchs mal zu malen: (OO <- Logikwolke) (-- <- Verbindung) (Die eigentliche FSM fehlt im Bild, da die für die Sachlage unerheblich ist) Mealy: Input Output Logik Register I |---OO---+----| FSM Reg |----OO---| Register O | | +--------------------+ Moore: Register I |---OO--------| FSM Reg |----OO---| Register O Der Pfad bei Mealy ist von Register I bis O, bei Moore nur von FSM Reg bis O
Exakt! Mealy hat bei VHDL nichts zu suchen. Man formuliert entweder alle Funktionen als Ergbnis von Kombinatorik und stopft sie dann ins FF oder man definiert alles alles nach den FFs. Mischungen führen nur dazu, daß Kombinatorik teilweis vor und nach den FFs steckt und ungünstig verteilt wird. Dass erfordert dann gate level resynthesis, um es zielsicher zu beheben.
Ich hab grad so ein ähnliches Problem: Ich schreibe eine FSM zur Ansteuerung von DRAMs. Wenn nun die CPU den Buszyklus beendet (hat), würde es bis zum nächsten State dauern, bis die FSM den Zyklus am RAM beendet. Deswegen hab ich mir überlegt, das als Mealy-Automat zu realisieren. Sprich: Die FSM durchläuft alle States, aber sobald die CPU den Zyklus beendet, beendet die FSM ebenfalls den DRAM-Zugriff sofort und "wartet" nicht erst auf das Erreichen des nächsten (Prefetch) State. Ob das so korrekt ist? Bisher hab ich nur Simulationen gefahren. Der Testaufbau steht noch aus... MfG Bogo
Kann man machen, hilft aber nix, wenn du die Precharge-Time einhalten willst. Da muss ja ein minimaler Wert garantiert werden, und das geht nur, wenn es über definierte Zustände läuft. D.h. die Statemachine muss so oder das Ende synchronisieren, wenn das Timing passen soll. Der Refresh muss ja auch reinpassen und alle Timings erfüllen. Mach lieber deinen FSM-Takt schneller, wenn es da so zeitkritisch ist oder versuche, CPU und DRAM-Controller definiert synchron laufen zu lassen. Ganz persönliche Erfahrung: Mit so asynchronen Schweinereien kann man gerade bei DRAMs in der Realität ganz mächtig auf die Nase fallen. Da gehts dann mal je nach Mondstand stundenlang oder auch nicht. Die realitätsnahe Simulation von solchen Effekten ist nicht einfach, da haben schon viel erfahrenere Personen/Firmen Projekte und Chips vergeigt.
Oh, na klar, ich meinte natürlich Precharge und nicht Prefetch. Die CPU hat ein asynchrones Businterface (68k). Es kann sein, dass sie direkt nach einem DRAM Zugriff auf andere Teile am Bus zugreifen möchte. Daher wollte ich das DRAM direkt mit Ende des CPU Buszugriffs vom Bus trennen. Die FSM geht danach so oder so in den Precharge State, so dass ein direkt folgender DRAM Zugriff warten muss. Refresh wird per Zähler ausgelöst und endet ebenfalls im Precharge Starte.
Beitrag #5120331 wurde von einem Moderator gelöscht.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.