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.
@ 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
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?
>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.
@ 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
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.