Wann Mealy, wann Moore ?

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.

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

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.