Statemachine Asynchron

[Sebastian (Gast)]

Hallo,

hab' grad ein kleines CPLD-Projekt. Hauptbestandteil ist eine 
Statemachine. Mit folgenden prinzipiellen Ablauf:

S1: Setze Out-Pins -- Sicherheitsschaltung stimulieren
S2: Teste In-Pins  -- Sicherheitsschaltung prüfen

Jetzt habe ich folgendes Problem, wenn ich in S1 bin setze ich dort die 
Output-Pins, leider werden diese aber erst im nächsten Takt am Ausgang 
tatsächlich gesetzt.
Mir wäre es viel, viel lieber wenn diese Outputpin sofort gesetzt 
würden, wenn ich in den S1 State komme.

Hier mal ein Snippet
(count_outi ist zu testzwecken mein Outputpin)

when OPIN_P1 =>
   count_outi := "001";  --> erscheint erst mit nächsten Takt am Ausgang
   state <= IPIN_P1;

when IPIN_P1 =>            --> Also hier werden Ausgänge erst gesetzt
   if SPG_TR1 = '0' then   --> Hier wird aber dann schon Input-pin 
getestet
     state <= OPIN_P2;
   else
     state <= ERR;
   end if;
   count_outi := "000";

Klar ich könnte jetzt noch einen zwischen State einführen. Ist aber 
nicht sehr elegant und verschwenderisch. Wie kann ich erreichen dass 
unter OPIN_P1 sofort der Ausgang gesetzt wird.

Im RTL sieht man auch ganz schön das der Ausgang über die Clock geführt 
wird. Genau das will ich aber nicht.

Im Anhang ist mein reduzierter Code. Ich freue mich auf Eure Vorschläge.
Sebastian.

[Falk B. (falk)]

@ Sebastian (Gast)

>Jetzt habe ich folgendes Problem, wenn ich in S1 bin setze ich dort die
>Output-Pins, leider werden diese aber erst im nächsten Takt am Ausgang
>tatsächlich gesetzt.

Dann setze die Pis schon beim Übergang.
Und lass den Murks mit der Variable!

>Klar ich könnte jetzt noch einen zwischen State einführen. Ist aber
>nicht sehr elegant und verschwenderisch. Wie kann ich erreichen dass
>unter OPIN_P1 sofort der Ausgang gesetzt wird.

Alle Verzeigungen ZU OPIN_P1 setzen gleichzeitig den Ausgang.

MFG
Falk

[Torben (Gast)]

Hallo,

ich haette keine kruze Frage dazu, wenn die Statemaschine erst zum 
nächsten Takt die I/Os setzt, dann ist es immer noch synchron oder 
nicht?

[Falk B. (falk)]

Sicher.

[Sebastian (Gast)]

>Dann setze die Pis schon beim Übergang.
>Und lass den Murks mit der Variable!

Ja da ran habe ich auch schon gedacht. Aber ich finde es sieht irgendwie 
unübersichtlicher im Code aus. Wenn ich Aktionen im vorherigen State 
schon starte.

Obwohl eigentlich ist es logisch, wenn man im OPIN_P1 State ist müssen 
schon alle Pins gesetzt sein. Somit muss der Anstoss des Setzens im 
vorherigen State passieren. Und bei der Transition in den OPIN_P1 
passieren.

Trotzdem unübersichtlicher, aber logisch.

Danke für die Denkanstösse.

Sebastian

PS: Asynchron ist natürlich verkehrt. Diese Statemachine kann nur 
synchron sein.

[Falk B. (falk)]

@ Sebastian (Gast)

>Ja da ran habe ich auch schon gedacht. Aber ich finde es sieht irgendwie
>unübersichtlicher im Code aus. Wenn ich Aktionen im vorherigen State
>schon starte.

Der einzig Ausweg wäre, die Ausgänge kombinatorisch aus dem State zu 
dekodieren. Das geht in den meisten Fällen. Aber nicht bei 
Taktausgängen, Strobes, etc.

Taktung FPGA/CPLD

MFG
Falk

[Falk B. (falk)]

Ach ja, ne kleine Anekdote aus dem Nähkästchen.

Die Worte "Statemachine" und "Asynchron" in einem Atemzug zu nennen ist 
KEINE gute Idee. Das hat mich damals bei meinem Prof unbeliebt gemacht. 
Er hat mir dann sogar ne Diplomarbeit verweigert (Ok, das war am Ende 
nur der Tropfen, der das Fass zum Überlaufen brachte). 8-0

MFG
Falk