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ß
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
1
waituntilraising_edge(clk);
halte ich für kontraproduktiv. Ich bevorzuge
1
processXYZ(clk)
2
begin
3
ifrising_edge(clk)then
4
5
endif;
6
endprocess;
einfach weil man es grafisch schon viel besser erfassen kann und die
Schreibweise viel expliziter ist. Lothars Schreibweise errinnert mit an
BASIC mit
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)
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:
1
processXYZ(clk)
2
begin
3
ifrising_edge(clk)then
4
:
5
endif;
6
if(irgendeinebedingung)then
7
:
8
endif;
9
endprocess;
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... ;-)
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.
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?
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!...
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
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ß!
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).
>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
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
