Statemachine Asynchron

Gast #706655
Lesenswert?

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.
Angehängte Dateien:
#706704
Lesenswert?

@ 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
Gast #706785
Lesenswert?

>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.
#706797
Lesenswert?

@ 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
#706804
Lesenswert?

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

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren