1-Prozess-Schreibweise für Steuereinheit

[Morin (Gast)]

Moin.

Ich habe folgendes Problem: Ich versuche, ein komplexes Modul in mehrere 
einfache Untermodule herunterzubrechen, die von einer zentralen FSM 
gesteuert werden. Im konkreten handelt es sich um eine Softcore-CPU, 
aber ich denke, das Problem betrifft allgemein alle Module, in denen 
Untermodule Steuersignale von einer Steuereinheit bekommen sollen.

Ich schreibe FSMs im allgemeinen in Ein-Prozess-Schreibweise auf. im 
Falle der Steuereinheit würde das etwa so aussehen:

process (clk) begin
  if reset = '1' then
    ...
  else
    case currentState is
      when STATE_ONE =>
        ... (*)
      when STATE_TWO =>
        ...
      ...
    end case;
  end if;
end process;

(*) hier finden dann Fallunterscheidungen und Berechnungen anhand von 
Einganssignalen statt; der nächste Zustand wird bestimmt und gesetzt; 
Ausgangssignale (d.h. die Steuersignale) werden bestimmt und gesetzt.

Wenn ich diese Steuersignale in die Submodule leite, ergibt sich ein 
Problem mit dem Zeitlichen Ablauf:

Taktperiode N: Steuereinheit liest Eingangssignale (Eingangssignale des
  komplexen Moduls sowie Ausgänge der Submodule)
Taktflanke nach N: Steuereinheit setzt Steuersignale
Taktperiode N+1: Submodule verarbeiten Steuersignale
Taktflanke nach N+1: Submodule ändern Zustand
Taktperiode N+2: Steuereinheit liest Ausgänge der Submodule
...

Die Steuereinheit muss also während jeder Taktperiode nicht die Aktionen 
der Submodule für die kommende, sondern für die darauf folgende 
Taktflanke bestimmen. Das bedeutet konkret entweder eine (eigentlich 
unnötige, künstliche) Verzögerung der ganzen Berechnung um einen Takt, 
oder eine sehr viel komplexere Steuereinheit, welche die Aktionen der 
Submodule schon einen Takt früher bestimmt.

Nun ist die Frage, wie man damit umgeht. Mir sind zwei Möglichkeiten 
eingefallen, aber ich würde gern auch mal eure Meinung dazu hören.

Möglichkeit 1: Ich gebe die 1-Prozess-Schreibweise auf. Mit einem 
kombinatorischen Prozess kann die Steuereinheit den Submodulen direkt 
sagen, was bei der kommenden Taktflanke passieren soll. Das könnte dann 
entweder
- eine gemischte 1/2-Prozess-Schreibweise sein (Ausgangssignale während 
kombi-Prozess oder Clocked-Prozess setzen, Zustandsänderung im 
Clocked-Prozess), oder
- eine reine klassische 2-Prozess-Schreibweise (ein Prozess berechnet
rein kombinatorisch asynchrone Ausgänge, snychrone Ausgänge und den Next 
State, der andere Prozess wechselt synchron die synchronen Ausgänge un 
den Zustand).

Möglichkeit 2: Ich gebe die Submodule als solche auf und Packe das 
gesamte komplexe Modul in eine Entity, mit entsprechend vielen Signalen 
und reiner 1-Prozess-Schreibweise.

[Klaus F. (kfalser)]

Es gibt in diesem Forum zwar einen Advokaten für die 1-Prozess 
Schreibweise, ich persönlich bevorzuge aus den oben genannten Gründen 
(Verzögerung um einen Takt) die 2-Prozess Schreibweise, wobei ich das 
Berechnen der sychronen Ausgänge meist in den getakteten Prozess ziehe.

[Morin (Gast)]

Okay, danke.

[Monty Python (Gast)]

>Ich schreibe FSMs im allgemeinen in Ein-Prozess-Schreibweise auf
Xilinx hat da ein gutes Seminar dazu, warum man es in 2 Prozesse 
aufteilen sollte. Es zwingt zu einer Formulierung, die alle Kombinatorik 
auf eine Seite der Register räumt und verhindert Limitierung der 
Geschwindigkeit bie ungünstiger Formulierung.

[Marc S. (nightguardian)]

@Monty

Kannst du dich zufällig noch an den Namen dieses Seminars erinnern? Die
Suche hat jetzt nicht allzu viel ergeben.

Danke

[Martin G. (Firma: Leckermittag.de) (morin)]

Wenn der Fred eh nochmal aufgewärmt wird...

Ich habe die Warnungen in den Wind geschlagen und es mit 1-Prozess 
versucht. Das Resultat entspricht der Theorie: XST verzettelt sich bei 
der Synthese. Wo eigentlich ein Block-RAM stehen sollte, werden 1000 FFs 
inferiert, diese nochmal verdoppelt und danach sich darüber Beschwert, 
dass Klon und Original dasselbe Signal treiben. Keinerlei Hinweis, 
warum kein Block-RAM rauskommt.

Ich habe dann in den sauren Apfel gebissen und alles in 2-Prozess neu 
geschrieben (dank Unit-Test-Cases war das auch halbwegs handhabbar).

Ich denke momentan auch darüber nach, mit mehr als 2 Prozessen zu 
arbeiten. Natürlich immer so, dass jedes Signal nur von einem Prozess 
getrieben wird. Ich erhoffe mir dadurch eine verständlichere 
Beschreibung, da viele Zustände immer dieselben oder einen von wenigen 
Default-Werten an bestimmte Ausgänge zuweisen, und nur in einzelnen 
Zuständen andere Werte kommen. Zur Info: Meine FSM hat ca. 30 Zustände 
und ca. 15-20 Ausgabesignale.

[alex (Gast)]

Ich würde sagen, man muss sich erstmal entscheiden, welche Art der FSM 
man implementieren möchte. Ein Paar Menschen haben sich darüber Gedanken 
gemacht und so gibt es heutzutage drei Arten von FSMs: Mealy, Moor und 
Medwedjev o.ä. Alles andere ist Gefrickel und wird entweder nicht 
funktionieren oder meistens funktionieren und manchmal nicht...
Und je nachdem, welche FSM man implementiert, ergibt sich die Anzahl der 
VHDL Prozesse, oder?

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

> Wo eigentlich ein Block-RAM stehen sollte, werden 1000 FFs inferiert,
> diese nochmal verdoppelt und danach sich darüber Beschwert,
> dass Klon und Original dasselbe Signal treiben.
Da muß ich jetzt aber mal auch noch auftreten...  ;-)

> Das Resultat entspricht der Theorie: XST verzettelt sich bei der Synthese.
> Keinerlei Hinweis, warum kein Block-RAM rauskommt.
Da würde aber der Synthese-Guide weiterhelfen...
Dort ist genau beschrieben, wie etwas genau beschrieben werden soll, 
damit die Synthese das als eine passende Komponente erkennt und in eine 
solche umsetzt. Und bei einem BRAM ist es ganz einfach: die Lese-Adresse 
muß getaktet sein. Wenn nicht, gibt es ein Distributed RAM. So einfach 
ist das...  :-o
Mehr dazu: http://www.lothar-miller.de/s9y/archives/20-RAM.html#extended
Und das hat rein gar nichts mit irgendwelchen 1-, 2- oder 
x-Prozess-Schreibweisen zu tun. Ich selber beschreibe auch in der 1- 
oder 2-Prozess-Schreibweise. Die Praxis hat mich gelehrt, dass die 
1-Prozess-FSM viel einfacher zu debuggen sind.

> Moor und Medwedjev
Moore und Medvedev

[Martin G. (Firma: Leckermittag.de) (morin)]

> Da würde aber der Synthese-Guide weiterhelfen...

Das Problem damit ist, dass der Guide nur im Allgemeinen formulieren 
kann, "wie man es macht". Er kann mir nicht in meinem speziellen Fall 
sagen, was falsch war. Synchrones Lesen alleine reicht ja nicht -- ich 
denke, das Problem war, dass der von mir beschriebene Speicher mehr als 
2 Ports gehabt hätte, wobei dann wieder nicht klar war, ob er mehr als 2 
Ports haben musste, oder ob das Synthesetool nur keine bessere Lösung 
gefunden hatte.

Nur steht so etwas in keinster Weise in der Fehlermeldung. Diese 
beschwert sich dann lieber darüber, dass irgendwelche Register, die in 
meinem HDL-Code gar nicht vorkommen (sondern die sich das Synthesetool 
ohne Angabe von Gründen ausgedacht hatte), dasselbe Signal treiben.

Einen sauberen Block-RAM konnte ich nur in einer Richtung am Horizont 
sehen, nämlich indem ich ihn in ein separates Modul auslagere. Dazu 
brauche ich dann wieder asynchron aus dem aktuellen Zustand generierte 
Steuersignale, und schon sind wir wieder bei der 2-Prozess-Schreibweise. 
Dann habe ich mich entschlossen, es damit einheitlich und sauber 
aufzuschreiben.

Ich halte es grundsätzlich für möglich, dass man mit vernünftigen Tools 
auch mit 1-Prozess zum Erfolg kommt. Das ist für mich jetzt schwer zu 
sagen.

> Ich würde sagen, man muss sich erstmal entscheiden, welche Art der FSM
> man implementieren möchte. Ein Paar Menschen haben sich darüber Gedanken
> gemacht und so gibt es heutzutage drei Arten von FSMs: Mealy, Moor und
> Medwedjev o.ä. Alles andere ist Gefrickel und wird entweder nicht
> funktionieren oder meistens funktionieren und manchmal nicht...
> Und je nachdem, welche FSM man implementiert, ergibt sich die Anzahl der
> VHDL Prozesse, oder?

Vielleicht könntest du das etwas näher erklären. Meine FSM ist eine 
Moore- oder Mealy-FSM, je nachdem welche Signale du dazuzählt und welche 
nicht. Ich fasse Prozesse zusammen oder splitte sie auf, baue an die 
Ausgabesignale Register dran und wieder weg, wie es gerade nötig ist. 
Macht kaum Probleme, das Design bleibt korrekt im Sinne der Unit-Tests. 
Das alles ist weit von dem Grauen entfernt, welches von den 
Synthesetools ausgeht...

[Marc S. (nightguardian)]

Mhm, schade - keine Antwort. Zufällig sonst einer ne Ahnung von welchem 
Xilinx-Seminar/Webinar er gesprochen hat?

Gruß

[Anguel S. (anguel)]

Vielleicht meinte er "Basic HDL Coding Techniques - Part 2" auf
http://www.xilinx.com/training/free-video-courses.htm#FPGA

IMHO sollte man aber als Ganzes von den Xilinx Seminaren/Webinaren sowie 
von der Doku nicht allzuviel praktisches erwarten. Die kostenlosen RELs 
im Web finde ich unglaublich schlecht. Ältere RELs haben so eine 
Sound-Qualität, dass das erste Telefon besser gewesen sein muss. 
Peinlich, dass man sowas ins Netz stellt und dass sich sowas die Leute 
seit Jahren ansehen müssen. Außerdem findet man immer wieder bei Xilinx, 
dass die schön irgendwelche Guidelines empfehlen, die dann aber in deren 
Code so nicht befolgt werden. Nur meine Meinung...

Marc Schmitt schrieb:
> Mhm, schade - keine Antwort. Zufällig sonst einer ne Ahnung von welchem
> Xilinx-Seminar/Webinar er gesprochen hat?
>
> Gruß