Ein- oder Zwei-Prozess-Darstellung für FSM

[Manu (Gast)]

Hallo Guys,

Ich hab zwei BeispielCode mittels StateMachine (von Lothar Miller 
http://www.lothar-miller.de/s9y/categories/37-FSM-Schreibweisen) 
angeschaut und durchgeführt, also die 1.Statemachine wird in 
Zwei-Prozess-Darstellung und die 2.Statemachine in 
Ein-Prozess-Darstellung geschrieben:

1.  begin
      process begin
      wait until rising_edge(clk);
      state   <= next_state;
      counter <= next_counter;

      if(state=idle) then
         delay <= 0;
      end if;

      if(state=work) then
         if (delay < 9) then
            delay <= delay+1;
         else
            delay <= 0;
         end if;
      end if;
   end process;

   process (state, rst, start, stop, delay, counter)
   begin
      next_counter <= (others=>'0');
      case state is
         when reset => next_state   <= idle;

         when idle  => if (start='1') then
                          next_state <= work;
                       end if;

         when work  => if (delay = 9) then
                          next_counter <= counter+1;
                       end if;

                       if (stop='1') then
                          next_state <= done;
                       end if;


         when done  => if (stop='0') then
                          next_state <= idle;
                       end if;
      end case;
      if (rst='1') then
         next_state <= reset;
      end if;
   end process;
   dout <= std_logic_vector(counter);
end Verhalten;

2. begin
      process begin
      wait until rising_edge(clk);
      case state is
         when reset => counter <= (others=>'0');
                       state   <= idle;

         when idle  => delay   <= 0;
                       if (start='1') then
                          state <= work;
                       end if;

         when work  => if (delay < 9) then
                          delay <= delay+1;
                       else
                          delay   <= 0;
                          counter <= counter+1;
                       end if;

                       if (stop='1') then
                          state <= done;
                       end if;

         when done  => if (stop='0') then
                          state <= idle;
                       end if;
      end case;
      if (rst='1') then
         state <= reset;
      end if;
   end process;
   dout <= std_logic_vector(counter);
end Verhalten;

Bei zweitem Programm (Ein-Process) kommen gar keine Warnungen(Latch oder 
kombinatorische Schleife) nach der Synthese, aber ihre Frequenz hat sich 
im Vergleich mit dem ersten Programm(Zwei-Process) deutlich reduziert.
Wie kann man die Frequenz von "Ein-Process-Statemachine" erhöhen?

Danke sehr!!

gruß

[Hagen R. (hagen)]

versuche mal

....
2. begin
      process begin
      wait until rising_edge(clk);

      counter <= counter;
      state <= state;
      delay <= delay;

      case state is
...

Also alle Signale vor dem case sich selber zuzuweisen. davon abgesehen 
solltest du bei jedem Prozess auch die benutzten Parameter mit angeben. 
Für die Synthese spielt das letzendlich keine Rolle aber für die 
Simulation kann es entscheidend sein.

Und übrigens: ich schätze Lothars Kompetenz aber diese Schreibweise mit 
dem

wait until raising_edge(clk);

halte ich für kontraproduktiv. Ich bevorzuge

process XYZ(clk)
begin
  if rising_edge(clk) then

  end if;
end process;

einfach weil man es grafisch schon viel besser erfassen kann und die 
Schreibweise viel expliziter ist. Lothars Schreibweise errinnert mit an 
BASIC mit

if XYZ then goto Exit;
print();

Gruß hagen

[Hagen R. (hagen)]

ach nochwas: generell sollte am Ende mit beiden FSMs das gleiche 
rauskommen.

[berndl (Gast)]

ich wuerde mir sogar in der 2-Prozess Schreibweise den 2. process (die 
Kombinatorik) sparen und gleich mit 2 concurrent 'with XXX select ...' 
arbeiten. Wird dann zwar hingeschrieben 'breiter', dafuer aber nicht so 
'tief' und m.M. nach besser zu lesen. Also 1 statement fuer next_state 
und 1 statement fuer next_counter.

Aber viel einfacher in den allermeisten Faellen ist die 1-Prozess 
Schreibweise... (imho)

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Manu schrieb:
> Wie kann man die Frequenz von "Ein-Process-Statemachine" erhöhen?
Hast du da mal Zahlen?
> Wie kann man die Frequenz von "Ein-Process-Statemachine" erhöhen?
Man kann mal nachsehen, woher diese "langsame" Arbeitsweise kommt. Dafür 
gibt es z.B. den RTL-Schaltplan und die statische Timinganalyse.

Hagen Re schrieb:
> diese Schreibweise mit dem
> wait until raising_edge(clk);
> halte ich für kontraproduktiv. Ich bevorzuge
> process XYZ(clk)
> begin
>   if rising_edge(clk) then
>
>   end if;
> end process;
>
> einfach weil man es grafisch schon viel besser erfassen kann
Allerdings kann dabei sowas ganz leicht passieren:

process XYZ(clk)
begin
   if rising_edge(clk) then
      :
   end if;
   if (irgendeinebedingung) then
      :
   end if;
end process;

Und das ist (zumindest) lästig.

Es stimmt schon: die wait until Schreibweise ist für die Synthese 
ungewöhnlich. In einer Testbench ist sie allerdings allgegenwärtig. 
Warum sollte man sie dann nicht auch für die Synthese verwenden, jetzt, 
wo die Synthesizer das so langsam können?

Hagen Re schrieb:
> Lothars Schreibweise errinnert mit an BASIC ...
Ich verbitte mir ausdrücklich jede Verknüpfung meines Namens mit dieser 
unsäglichen Programmiersprache...  ;-)

[Hagen R. (hagen)]

Lothar Miller schrieb:
> Es stimmt schon: die wait until Schreibweise ist für die Synthese
> ungewöhnlich. In einer Testbench ist sie allerdings allgegenwärtig.
> Warum sollte man sie dann nicht auch für die Synthese verwenden, jetzt,
> wo die Synthesizer das so langsam können?
>
> Hagen Re schrieb:
>> Lothars Schreibweise errinnert mit an BASIC ...
> Ich verbitte mir ausdrücklich jede Verknüpfung meines Namens mit dieser
> unsäglichen Programmiersprache...  ;-)

;-)

Ich kann deine Argumente sehr gut verstehen, hätte schreiben sollen das 
ich es nicht _mag_. Es ist eine Stilfrage und da ich schon sehr sehr 
früh (20 Jahre) mich der OOP verschrieben habe kommt es zu meinem 
geschmacklichen Vorlieben.

>Allerdings kann dabei sowas ganz leicht passieren:
>Und das ist (zumindest) lästig.

oder es ist erwünscht, laut Sprachstandard muß sowas zulässig sein. Ich 
sehe also keinen Widerspruch wenn es um die Möglichkeiten von VHDL geht, 
der Fehler der da gemacht wird sitzt zwischen den Ohren.

Egal, das tut nichts zum Thread beitragen.

Mein Vorschlag mit den Selbstzuweisungen zielt darauf ab das ich die 
Erfahrung gemacht habe das die Synthesetools (arbeite bevorzugt mit 
Altera Quartus) mit oder ohne andere Resultate liefern. Kann das einer 
von euch bestätigen ? Vielleicht täusche ich mich ja ?

Gruß hagen

PS: übrigens benutze ich nur die Ein-Process FSMs.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Hagen Re schrieb:
>>Allerdings kann dabei sowas ganz leicht passieren:
>>Und das ist (zumindest) lästig.
> oder es ist erwünscht, laut Sprachstandard muß sowas zulässig sein.
Wird auch korrekt synthetisiert. Aber mit passiert sowas meinte ich, 
dass es eben nicht gewollt war. Und dann bekommt man eine unvollständige 
Sensitivliste und die Simulation passt nicht zur Hardware...

> Mein Vorschlag mit den Selbstzuweisungen zielt darauf ab das ich die
> Erfahrung gemacht habe das die Synthesetools (arbeite bevorzugt mit
> Altera Quartus) mit oder ohne andere Resultate liefern.
Kann ich so nicht auf Anhieb bestätigen (habe allerdings auch nicht 
bewusst darauf geachtet...).
Hast du da ein (kleines) Beispiel? Oder passiert sowas "erst" bei recht 
komplexen Designs? Ändert sich dann der Ressourcenverbrauch bzw. woran 
erkennst du Unterschiede?

[berndl (Gast)]

Lothar Miller schrieb:
>> Mein Vorschlag mit den Selbstzuweisungen zielt darauf ab das ich die
>> Erfahrung gemacht habe das die Synthesetools (arbeite bevorzugt mit
>> Altera Quartus) mit oder ohne andere Resultate liefern.
> Kann ich so nicht auf Anhieb bestätigen (habe allerdings auch nicht
> bewusst darauf geachtet...).
> Hast du da ein (kleines) Beispiel? Oder passiert sowas "erst" bei recht
> komplexen Designs? Ändert sich dann der Ressourcenverbrauch bzw. woran
> erkennst du Unterschiede?

Also meine aktuelle Erfahrung (mit Lattice, Altera und Xilinx) ist, dass 
die Toolchains sowas sehr gut aufloesen koennen. Ich arbeite mit Designs 
um 100MHz (Cyclone III, Spartan3x, ECP2/3; also im wesentlichen 90nm 
FPGAs), das kriegen die aber alle gut auf die Reihe. Fuer mich das 
Fazit: Schreibs geradeaus hin, die Tools werdens schon richten!...

[Hagen R. (hagen)]

Lothar Miller schrieb:
> Hast du da ein (kleines) Beispiel? Oder passiert sowas "erst" bei recht
> komplexen Designs? Ändert sich dann der Ressourcenverbrauch bzw. woran
> erkennst du Unterschiede?

Beispiel wird schwierig da das eine Auftragsarbeit ist. Und ja ist ein 
komplexes Design ein CycloneIII c120 ist fast voll ca. 110000LEs und 
fast alle BRAMs aber nur 9 DSP Blöcke, 1GB DDR2 auf zwei Bänken ist auch 
noch dran. Wir benutzen den Altera DDR2 Memory Controller und der muß 
ebenfalls lizensiert sein. Achso 3 der 4 PLLs werden benutzt und 
insgesamt sind es 4 unterschiedliche Clock Domains. Habe aber bei jedem 
Clockcrossing die Daten mit Dual Ported FIFOs synchronisiert, deswegen 
der hohe BRAM Verbrauch.

Ich konnte es damals nicht soweit reduzieren das es reproduzierbar ist 
und Trial&Error mit so großem Design will keiner machen, dauert Stunden 
für eine Synthese (habe mir extra ein 8'fach Core Rechner gekauft)

Letztendlich bin ich dann eher ein Pragmat, habs bei allen meinen FSM 
einfach aus "Verzweiflung" wie oben gemacht und danach war das Design 
schneller und verbrauchte auch weniger LEs. Mir gings damals nur darum 
die Timings zu erfüllen.

Logisch betrachtet sehe ich es so: macht man wie ich es vorschlug darf 
es keinen Schaden anrichten aber es sollte eigentlich keine Unterschiede 
ausmachen.

Eine Besonderheit des Designs ist ein riesiges Shiftregister, das aber 
konzeptionell so von mir geplant war. Das lässt sich auch nicht anders 
lösen für die geforderte Aufgabe.

Tja das sind zwar einige Infos aber wirklich helfen werden die wohl 
nicht.

Gruß hagen

[Manu (Gast)]

Danke euch alle.

Hagen Re schrieb:
> versuche mal
>
> ....
> 2. begin
>       process begin
>       wait until rising_edge(clk);
>
>       counter <= counter;
>       state <= state;
>       delay <= delay;
>
>       case state is
> ...
Das hab ich schon mal versucht, aber die Frequenz hat sich auch noch 
nicht erhöht. Aber danke dir noch mal!!

Gruß!

[Olaf .. (ope-)]

ich werfe mal einen Beitrag von Clifford E. Cummings in den Raum (ich 
hatte vor einiger Zeit mal mit Verilog (PSoC) zu tun): 
http://www.sunburst-design.com/papers/CummingsICU2002_FSMFundamentals.pdf

Interessant ist Kap. 9 /pg. 23, wo er die verwendeten Resourcen 
vergleicht - nun ist die Frage: viele Resourcen = langsame Pfade? Ohne 
es wieder intensiv gelesen haben trifft er keine Ausagen dazu (für mich 
waren damals die Resourcen wichtig).

Auch wenn es Verilog ist, ist es als VHDL'er gut zu lesen (zumal die 
Struktur die Gleiche ist).

[SuperWilly (Gast)]

>Logisch betrachtet sehe ich es so: macht man wie ich es vorschlug darf
>es keinen Schaden anrichten aber es sollte eigentlich keine Unterschiede
>ausmachen.

Ich kann mir nicht vorstellen, dass die "überflüssige" 
Halte-Default-Zuweisung einen Unterschied macht. FÜr mich hört sich das 
eher nach einem anderen Seed-Value an, der "zufällig" zu einem besseren 
Timing-Ergebnis führt.

VG, SuperWilly

[Hagen R. (hagen)]

SuperWilly schrieb:
>>Logisch betrachtet sehe ich es so: macht man wie ich es vorschlug darf
>>es keinen Schaden anrichten aber es sollte eigentlich keine Unterschiede
>>ausmachen.
>
> Ich kann mir nicht vorstellen, dass die "überflüssige"
> Halte-Default-Zuweisung einen Unterschied macht. FÜr mich hört sich das
> eher nach einem anderen Seed-Value an, der "zufällig" zu einem besseren
> Timing-Ergebnis führt.
>
> VG, SuperWilly

Jup wäre eine Erklärung, ich habe auch eaxkt an diesem Seed rumprobiert, 
aber erst mit meinen Änderungen hat es dann vom Timing her funktioniert.

Gruß hagen