Hallo, ich wollte nur einmal wissen, ob irgendwas dagegen spricht, eine State Machine wie folgt zu beschreiben process (Clk) variable state : integer := 0; begin if (Clk'event and Clk = '1') then if (Reset = '1') then state := 0; else case state is when 0 => x <= '0'; state := 1; when 1 => x <= '1'; state := 0; when others => state := 0; end case; end if; end if; end; Diese Beschreibung funktioniert ja, ist allerdings wesentlich kürzer als in den Templates vorgegeben und für mich auch übersichtlicher, da alles in einem Process. Die Moore State Machine setzt sich in meinem Template aus drei Prozessen zusammen. Hat dies gegenüber meiner Variante irgend welche Vorteile? Danke für Hilfe.
> auch übersichtlicher, da alles > in einem Process. Es gibt die 1-Prozess Methode und die 2-Prozess Methode, Lothar Miller beschreibts ganz gut: http://www.lothar-miller.de/s9y/archives/43-Ein-oder-Zwei-Prozess-Schreibweise-fuer-FSM.html Einen groben Schnitzer hast dir aber erlaubt: Der Zustandsspeicher sollte ein Signal sein, keine Variable. Gruß
Mach dir einmal die Unterschiede zwischen variable und signal klar, dann kommst du schon selber drauf.
Die variable gilt nur für den process... auf dem board funktionierts so jedenfalls. Kann die State Machine dadurch ihren state verliehren?
Siehe: http://www.mikrocontroller.net/articles/VHDL#Grundregeln_f.C3.BCr_synthetisierbaren_VHDL-Code > Variablen nur dann verwenden, wenn man genau verstanden hat was der > Unterschied zu einem Signal ist, und sich das Problem nicht auch mit > Signalen lösen lässt
> Kann die State Machine dadurch ihren state verliehren? Nein, aber du kannst ihn ausserhalb des Prozesses nicht verwenden. Und das macht irgendwelche concurrent-Abfragen oder Zuweisungen unmöglich. Siehe auch den Beitrag "Variable vs Signal" BTW:
1 | variable state : integer := 0; |
Dadurch macht der Synthesizer deine Zustandsvariable (weil integer) erst mal 32 Bit breit. Und später muß das Ganze dann mühevoll wieder herausoptimiert werden... Wenn schon diese explizite Zustandsdefinition, dann mit range
1 | variable state : integer ragne 0 to 1 := 0; |
Besser ist aber die Zustrandsdefinition über einen type.
das "warum" ist schon richtig, man kann auch mit variablen states beschreiben (die werden also zu FFs) :-) . das hat nichts mit variable und signal zu tun. also signale: - kannst du innerhalb + ausserhalb eines processes verwenden - das update erfolgt erst am ende des aktuellen "delta" steps variablen: - nur innerhalb einen process - update sofort ja und wie werden variablen states? indem es einen pfad im getakteten process gibt der die variable liest bevor die geschrieben wird. und das ist hier der fall. btw1: nicht das man das so machen muss oder das dies gut ist, aber manchmal kann man das gebrauchen. btw2: die beschreibung sieht zwar lang aus aber was solls mfg
> variablen: > - update sofort Aber Achtung: es ist nicht so, dass dieser sofort übernommene Wert irgendwo sichtbar wäre (jaja, ok im Simulator vielleicht...). Übernommen und damit sichtbar wird der aktuelle Wert einer Variablen (wie bei Signalen auch) erst bei der nächsten Taktflanke. Alles was zwischen zwei Taktflanken passiert, kann "nur" Kombinatorik sein.
servus, >Übernommen >und damit sichtbar wird der aktuelle Wert einer Variablen (wie bei >Signalen auch) erst bei der nächsten Taktflanke. zuweisungen an variablen sind sofort im simulator sichtbar. da ist nichts mit taktflanke oder delta. durch die synthese veraendert sich nicht die semantik von vhdl (sonst waere ja die simualtion etwas sinnlos). das was sich veraendern kann ist das "delta" verhalten (und damit das timing zwischen den flanken) . >Alles was zwischen zwei >Taktflanken passiert, kann "nur" Kombinatorik sein. im prinzip##mfg
> zuweisungen an variablen sind sofort im simulator sichtbar.
Aber eben "nur" dort. In der Hardware gibt es keine solche
Zwischenwerte, wie Variablen sie annehmen können. Insbesondere gibt es
die Reihenfolge aus der Prozessbeschreibung nicht.
Wenn ich sowas in VDHL beschreibe:
1 | process (input) |
2 | variable x := integer; |
3 | begin
|
4 | if (input(0)='1') then |
5 | x <= 111; |
6 | end if; |
7 | if (input(1)='1') then |
8 | x <= 222; |
9 | end if; |
10 | if (input(2)='1') then |
11 | x <= 333; |
12 | end if; |
13 | end process; |
Hier wird, wenn input = "111" ist, in der Hardware der Variablen x niemals der Wert 111 oder 222 zugewiesen, wie das im Simulator durchaus zu sehen ist. Weil die letzte Zuweisung im Prozess gilt, gibt es in der Hardware nur den Wert 333.
Nehmen wir mal diese simple Beschreibung:
1 | library IEEE; |
2 | use IEEE.STD_LOGIC_1164.ALL; |
3 | use IEEE.NUMERIC_STD.ALL; |
4 | |
5 | entity BadVariable is |
6 | Port ( input : in STD_LOGIC_VECTOR (2 downto 0); |
7 | y : out STD_LOGIC_VECTOR (2 downto 0); |
8 | z : out STD_LOGIC_VECTOR (2 downto 0)); |
9 | end BadVariable; |
10 | |
11 | architecture Behavioral of BadVariable is |
12 | begin
|
13 | process (input) |
14 | variable x : std_logic_vector(2 downto 0); |
15 | begin
|
16 | z <= x; |
17 | x := "000"; |
18 | if (input(0)='1') then |
19 | x := "001"; |
20 | end if; |
21 | if (input(1)='1') then |
22 | x := "011"; |
23 | end if; |
24 | if (input(2)='1') then |
25 | x := "111"; |
26 | end if; |
27 | y <= x; |
28 | end process; |
29 | end Behavioral; |
Was passiert hier mit z, wenn input z.B. von 001 nach 011 wechselt? Im Simulator behält (=speichert) z den vorherigen Wert von x. Also ist hier z=001 und y=011. In der realen Hardware werden aber keinerlei Speicherglieder implementiert. Schon schön böse, diese Variablen, oder?
ja und, bei variablen ist jede zuweisung im simulator sichtbar (ob dieser wert nach der synthese irgendwo sichbar ist steht auf einem anderen blatt) - bei signalen ist nur das letzte assignment sichtbar (welches am ende des aktuellen delta cycles ausgefuehrt wird). regards
>Schon schön böse, diese Variablen, oder?
mir ist schon bewusst, dass zwischen simulation und synthese
unterschiede sind :-)
die ganzen templates, etc dienen eigentlich nur dazu simulation&synthese
resultat moeglichst gleich zu halten bzw ueberhaupt eine (sinnvolle)
hardware zu beschreiben.
mfg/
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.