Im zweiten Fall (ich hoffe ich habe das jetzt korrekt vereinfacht und
aufgeschrieben!) habe ich also nicht nur state, sondern auch noch
s_state.
Bis, auf dass man die zweite Lösung unglaublich umständlich lesen kann
und statt einem gut lesbaren Prozess zwei Prozesse hat...
Kann mir jemand sagen, welchen Vorteil die zweite Variante haben soll?
Ich habe bisher noch jede meiner FSM in der ersten Variante beschreiben
können und bin es so gewohnt und kann mir auch denken, dass ein solches
Design einfacher zu lesen und zu verstehen ist. Wozu dann die
umständliche zweite Vairante?
Vielen Dank!
Marc M. schrieb:> Wozu dann die> umständliche zweite Vairante?
Weil an den Hochschulen die 1-, 2- und 3-Prozess-Schreibweise gelehrt
wurde (noch wird?).
Da entscheidet man sich als angehender Ingenieur erstmal für den
Mittlweg :-)
Ich bin inzwischen entschieden dafür, Quellcode auf maximal
verständliche Weise zu schreiben. Wenn ich nicht den Gaisler-Stil (bitte
keine Diskussion darüber) nehme, dann würde ich auch die
1-Prozess-Schreibweise bevorzugen.
Duke
Marc M. schrieb:> Kann mir jemand sagen, welchen Vorteil die zweite Variante haben soll?
Zum grössten Teil ist das Geschmackssache, mMn werden
wohl die meissten Projekte in der 1-Prozess-Variante
geschrieben (meine Hobbyprojekte schreibe ich aber in
der 2er-Variante, Lesbarkeit ist da nur eine Frage der
Gewohnheit).
Es gibt aber in einigen Fällen einen Grund für die
2er-Schreibweise, den bei der 1er-Variante hat man
nunmal nur Zugang zu registrierten Signalen (d.h.
uU Latenzprobleme).
Im zweiten Fall hat man den Überblick, was sequentiell ist und was rein
kombinatorisch ist. Das ist ganz angenehm, wenn man den Prozess nicht
auf einer Bildschirmseite überblicken kann.
Das kann z.B. vorteilhaft sein, wenn man zu lange Pfade zwischen den
Registern sucht. Die sucht man dann nämlich nur im kombinatorischen
Teil.
Marc M. schrieb:> Kann mir jemand sagen, welchen Vorteil die zweite Variante haben soll?
Sie trennt die Kombinatorik von den Registern. Man berechnet also im
kombinatorischen Prozess einen Wert, der dann an die Flipflopeingänge
angelegt wird und beim nächsten Takt auf die Ausgänge übernommen wird.
Dort steht er dann wieder bereit zur Berechnung neuer Eingangssignale.
Es ist eigentlich wie wenn du 2 Spachen (oder auch nur Dialekte) hast:
du kannst deinem Kommunikationspartner (Synthesizer, Kollege) einen
Sachverhalt auf deutsch (2-Prozess-Schreibweise) erklären, oder du
sprichst englisch (1-Prozess-Schreibweise) mit ihm. Auf beide Arten ist
bei gleicher Sprachkenntnis eine gleich reibungslose Kommunikation mit
gleich gutem Ergebnis möglich. Der Synthesizer beherrscht beide Sprachen
problemlos.
Wenn du aber vorrangig deutsch sprichst, dann kannst du einen Engländer
mit einem holprigen Englisch ganz hübsch in die Irre führen. Und
natürlich andersrum auch. Wenn du dem Engländer sagst: "i will pick you
up at half eight" (und damit "halb acht" im Sinne von 7:30 Uhr meinst),
dann wirst du ihn unschön aus den Träumen reißen, weil er nämlich "halb
nach acht" gehört hat.
Wenn also einer, der die 1-Prozess-Schreibweise gewohnt ist, in ein
2-Prozess-Design einen Zähler einbaut, dann kann ihm leicht sowas
passieren:
http://www.lothar-miller.de/s9y/archives/42-Kombinatorische-Schleifen.html> Wozu dann die umständliche zweite Vairante?
Kurz: Gewohnheit. Einmal gelernt, immer so gemacht.
Ich nehme hier jetzt üblicherweise die dritte Variante:
http://www.lothar-miller.de/s9y/archives/16-Takt-im-Prozess.html
Das ist ein guter Punkt! Man sollte sich das einmal vergegenwärtigen und
dann bei einer Beschreibungsweise bleiben. Ich habe glaube ich noch nie
etwas mit 3 Prozessen gemacht.
Ok, also ist es wie vermutet und es ist einfach eine Sache der
Gewohnheit und es gibt keine gravierenden Vor- und Nachteile. Danke für
die Antworten!
Ich habe ein Projekt mit einer 2-Prozess-FSM übernommen und komme damit
gar nicht klar, weil ich die vergangenen Jahre alles in einem Prozess
behandelt habe. Daher habe ich Verständnisprobleme mit der FSM und es
ist einfach nicht intuitiv für mich zu lesen.
Nun überlege ich, diese dicke FSM in einen Prozess zu überführen. Das
birgt natürlich das Risiko, dass ich etwas falsch mache und das Modul
nicht mehr so funktioniert wie erwartet. Auf der anderen Seite habe ich
im Falle des Erfolges eine für mich gut lesbare FSM, mit der ich
vernünftig weiterarbeiten kann und habe die FSM mit Sicherheit komplett
verstanden.
Gibt es Tools (mal abgesehen von einer kompletten
Verifikation/Testbench), die zwei FSM vergleichen kann?
Ich erinnere mich da ein Xilinx Tool, dass automatisiert FSM-Diagramme
erstellen kann? Vielleicht wäre das ein Weg, beide Ergebnisse ohne
aufwendige Simulation zu vergleichen?
Oder entsteht nach der Synthese bei der 1-Prozess und 2-Prozess
Schreibweise auch immer die gleiche RTL bei der Synthese? Dann wäre das
vielleicht ein Weg zur Vergleichbarkeit?
Vielen Dank!
Marc M. schrieb:> Gibt es Tools (mal abgesehen von einer kompletten> Verifikation/Testbench), die zwei FSM vergleichen kann?> Ich erinnere mich da ein Xilinx Tool, dass automatisiert FSM-Diagramme> erstellen kann? Vielleicht wäre das ein Weg, beide Ergebnisse ohne> aufwendige Simulation zu vergleichen?> Oder entsteht nach der Synthese bei der 1-Prozess und 2-Prozess> Schreibweise auch immer die gleiche RTL bei der Synthese? Dann wäre das> vielleicht ein Weg zur Vergleichbarkeit?
Simulation aufwendig?
Ich nehme für sowas immer die Twinwave-Variante von GTKwave um mal eben
die Wellenformen zu vergleichen, aber eigentlich sollte dein Regresstest
(Testbench) so gut sein, dass ein Bock sofort auffallen würde..
Der RTL-Viewer deines Tools müsste ansonsten das Gleiche für beide
Varianten anzeigen, aber darauf würde ich mich nicht verlassen, auch
nicht auf die Netzliste.
Marc M. schrieb:> Das birgt natürlich das Risiko, dass ich etwas falsch mache und das> Modul nicht mehr so funktioniert wie erwartet.
Dein Hauptproblem wird Latency sein. Einfach nur einen Takt um die
Kombinatorik "herumwickeln" geht auf jeden Fall nicht...
> Oder entsteht nach der Synthese bei der 1-Prozess und 2-Prozess> Schreibweise auch immer die gleiche RTL bei der Synthese?
Schon ein vertauscher Parameter bei einem AND gibt u.U. ein anderes
Syntheseergebnis...
Sieh dir dort mal das obere und das untere Bild an:
http://www.lothar-miller.de/s9y/archives/52-Kompakte-Flankenerkennung.html
Und jetzt überleg mal, was die Synthese aus zwei komplett
unterschiedlich geschriebenen FSM macht, wenn schon zwei zusätzliche
Inverter durch das Vertauschen zweier AND-Parameter entstehen :-O
Lothar M. schrieb:> Schon ein vertauscher Parameter bei einem AND gibt u.U. ein anderes> Syntheseergebnis...
Das finde ich jetzt krass. Warum ist das so?
Ist das funktionell wirklich Dasselbe? Ich meine, Ich hätte schon mal
gesehen, dass mache Tools mit dem Rang nicht umgehen können und:
not a and b einmal als
not (a and b) und einmal als
(not a) and (not b) interpretieren.
Angeblich hat es da in der Anfangszeit mit der HLS bei Vivado ein
Problemgegeben, wenn man es wie in C geschrieben hat.
Auch bei embedded MATLAB hatte ich schon Effekte.
Ich schreibe seither immer und alles mit Klammern!
Andreas F. schrieb:> not a and b einmal als> not (a and b) und einmal als> (not a) and (not b) interpretieren.
Das darf nicht sein. Das wäre ja ein Fehler...
> Lothar M. schrieb:>> Schon ein vertauscher Parameter bei einem AND gibt u.U. ein anderes>> Syntheseergebnis...> Das finde ich jetzt krass.
Sieh dir das verlinkte Beispiel auf meiner HP an.
[Zitat]
Wenn statt
rise <= not sr(3) and sr(2);
fall <= not sr(2) and sr(3);
die folgende (genau funktionsgleiche) Beschreibung
rise <= not sr(3) and sr(2);
fall <= sr(3) and not sr(2);
verwendet wird, kommt
[/Zitat]
was Anderes dabei raus, was aber trotzdem genauso die richtige Funktion
hat.
> Warum ist das so?
Ein Freiheitsgrad des Synthesizers.
Das Ergebnis ist ja nur anders, es ist aber nicht falsch...
Man kann bei der Generation der Netzliste angeben, welche Form er
verwenden soll (optimized, rebuilt). Je nachdem, bekommt man deshalb
einmal eine anders erstellte (gfs überbeschriebene!) Version der
Schaltung.
Entscheidend ist hinterher das Syntheseergebnis und der Verbrauch von
LUTs und der ist Derselbe. Das sage ich mal so, wissend, dass es
chaotische Schaltungsbeschreibungen gibt, die von der Synthese nicht
entflochten werden können.
Ansonsten kommt in der Tat dasselbe raus. Daher weise ich ja auch immer
sehr gerne darauf hin, dass weder die optische RTL-Schaltung noch die
NETLIST wirklich und tatsächlich das beschreiben, was im FPGA real
gebaut wird, sondern sie beschreiben nur ersatzweise eine von mehreren
möglichen Schaltung, die dasselbe leisten. Daher ist der Blick in die
aus einem VHDL generierte optische Schaltung auch nur begrenzt
aussagefähig.
Gerade bei state machines gibt es da enormen Spielraum. Früher haben
sich die Tools bemüht, alles zu optimieren und kleinzubacken, was
unterschiedlichen Tools sehr unterschiedlich gut gelungen ist - heute
wird platzverschwendend "one hot" codiert, um sich schnell schaltend und
störsicher zu machen.
Bei unseren internen Designrules ist vorgeschrieben, dass es im
VHDL-Code von FSMs immer einen explizit formulierten Folgezustandsvektor
geben muss, also das s_state im obigen Beispiel. Das hat den Vorteil,
dass man z.B. Mealy-FSMs leichter debuggen kann, indem man den
Folgevektor auf einen Logicanalyzer legt. Bei sehr großen FSMs packen
wir die Übergangsfunktion sogar in eine eigene Komponente.
Im Prinzip also der 2-Prozess-Style, aber es sind Abwandlungen erlaubt
bzw. erwünscht:
1. Beide Prozesse können in einen einzigen Prozess verpackt werden (also
Berechnung und Zuweisung des Folgezustandsvektors), solange sie
weiterhin syntaktisch unterscheibar sind. Wird selten benutzt.
2. Der Kombinatorische Teil sollte ohne Prozess beschrieben werden, wenn
das sinnvoll möglich ist, also dann im Allgemeinen mit einem großen
when-Statement.
Allgemein gilt bei uns die Regel, dass auf kombinatorische Prozesse
möglichts verzichtet werden sollte, weil sich unvollständige
Sensitivity-Listen immer als Fehler auswirken und man sich nach den dann
enstehenden Latches einen Wolf sucht.
Aber das ist ein Thema, über dann man sich totdiskutieren kann, wie wir
hier schon oft gesehen haben.
Also bitte keine Aufregung, das sind nur unsere Designrules.
Vancouver schrieb:> 1. Beide Prozesse können in einen einzigen Prozess verpackt werden (also> Berechnung und Zuweisung des Folgezustandsvektors), solange sie> weiterhin syntaktisch unterscheibar sind. Wird selten benutzt.
Den kombinatorischen und den registrierten Teil "hintereinander" im
selben Prozess? Das wäre ein sehr "überraschender" und "extravaganter"
Stil...
Gefällt mir auch nicht so richtig, vor allem, weil der eine Prozess
kombinatorisch und der andere synchron ist. Macht wie gesagt auch kaum
jemand, aber es funktioniert.
Vancouver schrieb:> weil der eine Prozess kombinatorisch und der andere synchron ist.
Das ist ja dann die 2-Prozess-Schreibweise. Nein, ich dachte da eher an
so eine "verquirlte" 1-Prozess-Schreibweise:
Thread beobachten
Seitenaufteilung abschalten