Hallo guten Tag,
ich versuche eine Mealy Maschine zum Laufen zu bringen, die Muster eines
Datensstroms erkennen soll.
* Zuerst möchte ich "0x5a50dad0d1d2d3d4" (64 Bit) erkennen
* wenn ich das separat in einem process mache klappt das ohne weiteres
* Das ist auch relativ einfach, da bei rising edge dieses Signal
auftauchen kann
```
testcheck : process (Daten)
WHEN WAIT_FOR_ADR1 =>
-- check first addres
case FRAME_PART1v2 is
when X"5a50dad0d1d2d3d4" => DETECTED_ADR1 <= '1';
when others =>
end process testcheck;
```
* Mit meiner State Machine klappt das nicht
* Sie scheint zu spät zu prüfen oder so
* Erst wenn ich die "next state output "logic sensibel mache detektiert
sie dieses Muster...
* Wird nicht bei clk-rising edge der "next_state" aktualisiert und
deswegen gleichzeitig die FSM aufgerufen?
* Dort müsste doch erkannt werden, dass zu diesem Zeitpunkt dieser
Vektor (0x5a50dad0d1d2d3d4) anliegt!
* Bei dem Mealy Beispiel von Xilinx stand noch ein x neben dem
current_state. Ich könnte das für den Input verwenden...
Finde ich aber seltsam aber ok.
Wenn sich die state machine gerade in diesem Zustand befindet und dafür
sensibel sein muss ...
```
--- hier übergebe ich meine Eingangsdaten:
FRAME_PART1v2 <= m_axis_tdata;
-- Das ist meine "reset logic"
-- sie wird bei jedem m_axis_clk ausgeführt
-- current state wird dabei immer aktualisert
SYNC_PROC2 : PROCESS (m_axis_clk)
BEGIN
IF rising_edge(m_axis_clk) THEN
IF (axi_reset = '1') THEN
-- reset..
current_state <= IDLE;
ELSE
current_state <= next_state;
END IF;
END IF;
END PROCESS;
-- next state & Output logic:
-- dadurch, dass current_state bei jedem risign edge aktualisiert wird,
-- wird zeitgleich(?) die next state output logic ausgeführt.
-- es soll eine bestimmte Adresse in dem signal "FRAME_PART1v2"
detektiert werden.
-- dann soll DETECTED_ADR1 auf 1 gesetzt werden.
-- allerdings klappt das nicht
-- habe dann einfach m_axis_clk in die Sensibilitätsliste eingefügt..
und dann geht es
-- könnte evtl. noch den datenstream selber in in die
Sensibilitätsliste einfügen . Im xilinx beispiel war dort ein x... habe
ich weggemacht :D
NEXT_STATE_DECODE : PROCESS (current_state,m_axis_clk)
BEGIN
CASE (next_state) IS
WHEN IDLE =>
next_state<= WAIT_FOR_ADR1;
-- do nothing
WHEN WAIT_FOR_ADR1 =>
-- check first addres
case FRAME_PART1v2 is
when X"5a50dad0d1d2d3d4" => DETECTED_ADR1 <= '1';
when others =>
end case;
```
Signalisierer schrieb:> die FSM aufgerufen?
Du hast die falsche Denkweise und "programmierst" Hardware.
Denn in der Hardware wird nichts "aufgerufen", eine FSM wird nicht
"aufgerufen". Jedes Flipflop, das deine VHDL-Beschreibung in einem FPGA
oder einem ASIC erzeugt, ist immer da. Und bei der entsprechenden Flanke
wird einfach der Pegel vom Eingang des Flipflops auf dessen Ausgang
abgespeichert.
Signalisierer schrieb:
In dieser Sensitivliste sind unnötigerweise "current_state" und
"m_axis_clk" drin. Dafür fehlen aber "next_state" und "FRAME_PART1v2".
Deshalb wird deine Simulation nicht zur erzeugten Hardware passen.
Das sagt dir der Synthesizer aber auch...
Über die Sensitivliste kannst du lediglich das Verhalten der Simulation
steuern. Der Synthesizer kümmert sich nicht um die Sensitivliste. Er
wird deshalb die Signale "next_state" und "FRAME_PART1v2" schlicht
ignorieren.
Signalisierer schrieb:> Erst wenn ich die "next state output "logic sensibel mache detektiert> sie dieses Muster...
Wer detektiert da was zu spät? Wie stellst du das fest? Im Simulator? Im
echten Leben? Kann man da mal irgendwelche
Grafiken/Screenshots/Messungen sehen?
Vielen Dank für das Feedback!
Habe nicht beachtet wie eine Sensitivitätsliste synthetisiert wird.
Sehe gerade einen Beitrag:
>Christian R. (supachris)>30.05.2013 22:18>Die Sensitivitätsliste ist ausschließlich für den Simulator relevant>und gibt an, welche Signale auf Änderungen überwacht werden sollen.>Jedes mal wenn sich ein Signal aus der Liste ändert, wird das Ergebnis>des Prozesses vom Simulator neu berechnet. Trotzdem sollte man die Liste>immer ordentlich beschreiben, da sonst Simulation und Realität nicht>übereinstimmen. In deinem Fall müsste dann x in die Liste, denn bei>einer Änderung von x soll sofort der Ausgang neu berechnet werden. Der>Synthese ist die Liste egal, die spuckt in der Regel nur eine Warnung>aus, wenn sie nicht vollständig ist.
* Habe mich außerdem an diesem Beispiel orientiert.
* Muss eigentlich nicht synthetisierbar sein
* Möchte es aber trotzdem als Übung machen
* Möchte außerdem eine passende State-Machine wählen um AXI-Stream zu
checken
- In der Simulation passt das schon einigermaßen
https://www.xilinx.com/support/documents/university/Vivado-Teaching/HDL-Design/2015x/VHDL/docs-pdf/lab10.pdf
* Ich weiß jetzt gerade gar nicht, was ich wählen soll.
* 1 Prozess klingt gut
* Aber ich hätte überhaupt kein Problem Kombinatorik und Synchrones zu
trennen
Wollte eigentlich mit einem Zähler arbeiten, der bei jeden Takt prüft,
ob das aktuelle Signal einen validen Code enthält.
* Also 64 Bit Signal = valide dann counter++ bei rising edge
- 64 Bit kann dabei auch konstant bleiben.
- Kombinatorisch nicht erkennbar, weil Takt einzige Änderung.
* Also angenommen ich möchte bei dem Xilinx Beispiel bleiben.
- Mit 2 Prozessen.
* Wo soll ich dann diesen Counter hinschreiben?
- In den ersten oder in den 2ten Prozess.
- Oder einen neuen Prozess dafür erstellen?
Lothar M. schrieb:> synchrone FSM in der 1-Prozess-Schreibweise
axi-s ist ja synchron zum Takt..
von daher könnte das sogar passen für einen simplen pattern checker
oder?
Signalisierer schrieb:> Also angenommen ich möchte bei dem Xilinx Beispiel bleiben.> Mit 2 Prozessen.> Wo soll ich dann diesen Counter hinschreiben?> In den ersten oder in den 2ten Prozess.
Du musst nach reiner Lehre den Counter aufteilen in Register z.B.
namens "cnt" und einen Addierer, der "cnt_next" ausrechnet.
Das wollte ich vorhin eigentlich auch noch verlinken, da steht das drin:
http://www.lothar-miller.de/s9y/archives/43-Ein-oder-Zwei-Prozess-Schreibweise-fuer-FSM.html
Ah vielen Dank für den Link!
Würde das nämlich mindestens gerne nachvollziehen :D
(Habe vorhin schon mal nach "FSM" in dem Suchfeld gesucht, aber es kam
nichts!)
Was meinst du damit:
Lother M. schrieb:
> ein synchroner und ein kombinatorischer Prozess gemergt in einer> process-Umgebung.
Die kurze Schreibweise dafür ist "Murks!"
Hab das sogar bei meinem pattern generator ( nicht der gerade erwähnte
pattern checker) auf deine Weise gemacht:
#### Hier der Ausschnitt:
Anmerkungen:
* Der SYNC_PROC ist einfach nur da, weil ich das aus dem Beispiel hatte
und nicht wusste, ob ich das mit reinbringen soll oder nicht...
* next_state und state passen hier aber von der Namensgebung evtl.
nicht..
* sm_pr : PROCESS (m_axis_clk) beschreibt dann die states..
* Funktioniert auch soweit ich das nachvollziehen konnte..
Signalisierer schrieb:> Was meinst du damit
Man schreibt entweder einen kombinatorischen Prozess ohne Takt, oder
man schreibt einen synchronen Prozess, wo neben dem Takt
schlimmstenfalls nur noch ein Reset in der Sensitivliste steht.
Aber man fasst nicht die Kombinatorik und die Register einer
2-Prozess-Beschreibung hintereinander im selben Prozess zusammen.
Man braucht kein next Städte und current state. Es reicht ein state
signal, was du in deinem synchronen Prozess änderst. Sonst hast du immer
zwei Zyklen Verzögerung.
